`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`DELL INC., EMC CORPORATION, HEWLETT-PACKARD
`ENTERPRISE CO., HP ENTERPRISE SERVICES, LLC, and TERADATA
`OPERATIONS, INC.
`
`Petitioners
`
`v.
`
`REALTIME DATA LLC
`Patent Owner
`____________________
`
`Case IPR2017-00176
`&
`Case IPR2017-00806
`[consolidated]
`Patent No. 7,161,506
`____________________
`
`
`
`
`PATENT OWNER’S RESPONSE
`
`
`
`
`
`
`
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`TABLE OF CONTENTS
`
`
`I. Introduction ......................................................................................................... 1
`II. Background of the ’506 patent and challenged claims ...................................... 2
`III. Petitioners’ Obviousness Theory Cannot Meet Claim 104 Limitation
`[c] .................................................................................................................... 4
`A. Dr. Creusere testified that a POSA would always use Hsu to
`identify data types for Franaszek’s data blocks. .................................. 4
`B. When used, Hsu’s approach always identifies a data type. ................. 7
`C.
`Because Hsu’s approach would always be used to identify data
`types for Franaszek’s data blocks, and would always identify a
`data type for each data block, limitation 104[c] cannot be met. ........ 11
`IV. Petitioners’ Allegations Fail With Respect To Claim 105 Limitation
`[d2] ................................................................................................................ 12
`V. Conclusion ....................................................................................................... 19
`
`
`
`
`
`
`
`
`
`- i -
`
`
`
`
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`EXHIBIT LIST
`
`
`Exhibit No.
`2001
`
`2002
`
`2003
`
`2004
`
`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.
`Transcript of Oral Deposition of Charles D. Creusere, August 4,
`2017, taken in IPR2017-00176 and IPR2017-00179.1
`Declaration of Dr. Kenneth A. Zeger, Ph.D.
`
`
`
`
`
`
`1 Although initially taken in IPR2017-00176 and IPR2017-00179, the parties
`
`have agreed (and the Board has ordered) that the deposition shall be treated as
`
`having also been taken in IPR2017-00806 and IPR2017-00808. See IPR2017-
`
`00176, Paper 28 at 4; IPR2017-00179, Paper 29 at 4; IPR2017-00806, Paper 19 at
`
`4; IPR2017-00808, Paper 18 at 4.
`
`
`
`
`- ii -
`
`
`
`
`
`
`
`IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`Introduction
`Petitioners allege that claims 104 and 105 of the ’506 patent are obvious
`
`I.
`
`over the combination of Franaszek, Hsu, and Sebastian. The testimony of
`
`Petitioners’ own expert, Dr. Creusere, along with Patent Owner’s expert, Dr.
`
`Zeger, now proves otherwise.
`
`Claim 104 limitation [c] requires performing data compression on a data
`
`block for which a data type has not been identified. Dr. Creusere’s testimony
`
`establishes that, to the extent a POSA would combine Franaszek with Hsu at all,
`
`the POSA would make use of Hsu’s teachings to recognize a data type with respect
`
`to every data block in the ensuing combined system. Section III.A, infra. Dr.
`
`Zeger’s testimony further establishes that a POSA would expect Hsu to identify a
`
`data type with respect to each data block, and that Hsu would in fact do so. Section
`
`III.B, infra. Sebastian’s role in the combined system would have no effect to the
`
`contrary. Id. Since Petitioners’ alleged combination would always identify a data
`
`block’s data type, Claim 104 limitation [c] would never be met, and Petitioners’
`
`obviousness theory as to claim 104 fails. Section III.C, infra.
`
`Petitioners theory with respect to Claim 105 is similarly self-defeating.
`
`Claim 105 limitation [d2] requires compressing a data block once limitation [d1] of
`
`that claim has not been met. But Petitioners’ alleged combination would always
`
`
`
`
`
`
`- 1 -
`
`
`
`
`
`perform limitation [d1] and would thus never meet limitation [d2]. Section IV,
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`infra. Petitioners’ only theories as to how the combined system of Franaszek, Hsu,
`
`and Sebastian would purportedly meet limitation [d2] ignore Hsu’s existence
`
`entirely and ascribe teachings to Sebastian that Dr. Creusere admitted Sebastian
`
`does not contain, and that Dr. Zeger explains a POSA would not derive. Id.
`
`Accordingly, as demonstrated by the testimony of both experts in this
`
`proceeding, the arguments set forth herein, and the record as a whole, the Board
`
`should find claims 104 and 105 not unpatentable.
`
`II. Background of the ’506 patent and challenged claims
`Petitioners Dell, EMC, HPE, and Teradata (collectively, “Petitioners”)
`
`challenge claims 104 and 105 of the ’506 patent.2 The ’506 patent relates to data
`
`
`2 Pursuant to the Board’s order of consolidation and coordination, Patent
`
`Owner files this common Patent Owner’s Response to the separate Petitions filed
`
`in IPR2017-00176 (by Petitioners Dell Inc., EMC Corporation, Hewlett-Packard
`
`Enterprise Co., and HP Enterprise Services, LLC) and IPR2017-00806 (by
`
`Petitioner Teradata Operations, Inc.). See IPR2017-00176, Paper 28 at 4; IPR2017-
`
`806, Paper 19 at 4.
`
`
`
`
`
`
`- 2 -
`
`
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`compression and, particularly, the use of “a combination of content dependent data
`
`
`
`compression and content independent data compression.” Ex. 1001, 15:60-63.
`
`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
`[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
`
`
`
`
`
`
`- 3 -
`
`
`
`
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`[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
`[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. Petitioners’ Obviousness Theory Cannot Meet Claim 104 Limitation [c]
`A. Dr. Creusere testified that a POSA would always use Hsu to
`identify data types for Franaszek’s data blocks.
`To meet limitation [d] of claim 104, the Petition proposes that a POSA
`
`would be motivated to modify Franaszek by adding Hsu’s analysis techniques to
`
`identify data blocks’ data types. See IPR2017-00176, Pet. at 31-36; IPR2017-
`
`00806, Pet. at 33-38. At his deposition, Dr. Creusere admitted that a POSA
`
`combining Franaszek with Hsu would always use Hsu to identify a data type and
`
`three redundancy metrics for each of Franaszek’s data blocks.
`
` Q. Okay. Now, with respect to how Franaszek’s system once
`modified by Hsu would actually make use of Hsu’s data type and
`compression metrics, where in the Franaszek flow process would
`Hsu’s data type and compression metrics analysis occur and -- well,
`just – let’s start there.
`
`
`
`
`
`
`- 4 -
`
`
`
`
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`[A.] Well, I mean, a person of ordinary skill in the art, of course,
`would have to -- would have to consider their application what they
`are trying to application. My own personal feeling on this as a person
`of ordinary skill in the art would be that you would do this in --
`around the same flight in block 4A -- in [Franaszek’s] figure 4A, that
`first block, where it says, at the moment data type available and it
`makes that first split.
`My own opinion is that this is where you would add the Hsu concepts,
`so you -- if you had the data type, then you could use that to guide
`Hsu into making a better situation, into making better or to looking at
`fewer possibilities. If you didn't have the data type, you could then
`apply Hsu to finding data type and then follow the path to the right
`in figure 4A, where it says, yes, and move -- and move on.
`
`Id. at 131:13-132:15 (emphasis added).
`
`Dr. Zeger agrees that to the extent a POSA would combine Franaszek with
`
`Hsu at all, a POSA would utilize Hsu’s powerful data type recognition and
`
`redundancy calculation approach as to all data blocks within Franaszek’s system.
`
`Ex. 2004 ¶ 23.
`
`Dr. Creusere’s explanation of how a POSA would combine Hsu into
`
`Franaszek’s Figure 4A is visually depicted below. See Ex. 2004 ¶ 24.
`
`
`
`
`
`
`- 5 -
`
`
`
`
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`FIG. 4A
`
`ND
`
`YPT
`
`E “AWE
`
`SET CML=
`DEFAULT*CML
`
`SET CML=
`CML-TABLE
`(TYPE(B))
`
`IN CML
`
`SET E TD FIRST
`CML ENTRY
`
`ETHUD (E)
`DICTIDNARY
`BASED ?
`
`SET D-LIST=
`_ _
`DEFAULT D LIST
`
`SET M: METHDD<EB
`REMDVEsE FRDM CML
`
`DATA TYPE
`‘VAILABL
`o
`‘
`
`SET D-LIST=
`D"LIST"TABLE
`(TYPE(B))
`
`FDR EACH D
`
`ADD (MD)
`
`WAS E
`LAST ENTRY IN
`CML ?
`
`SET E TU
`NEXT ENTRY
`
`
`
`
`
`
`- 6 -
`
`
`
`
`
`
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`B. When used, Hsu’s approach always identifies a data type.
`At his deposition, Dr. Creusere admitted that using Hsu’s approach will
`
`always identify a result for a block’s data type.
`
`Q. And in Hsu’s approach, of those four pieces of information that
`the data type and the three redundancy metrics [sic], it will always be
`the case that at least one, and likely more of those will be identified
`for a given data block, right?
`A. As regards the three redundancy metrics, those are basically
`statistical analysis calculations, and those can always be calculated for
`any data block. As far as the – as the data type information as output
`by Hsu’s new file routine, that, that’s – that will – that should in my,
`in my opinion, as a person of ordinary skill in the art, my best estimate
`is that will always output something. It will always give you
`something. Now exactly what it outputs under certain circumstances,
`I’m not totally sure of.
`Ex. 2003 at 21:13-22:6 (emphasis added).
`
`Dr. Zeger agrees. Ex. 2004 ¶ 25. On redirect, Dr. Creusere attempted to
`
`qualify his earlier testimony by stating that Hsu’s approach to data type recognition
`
`uses “the UNIX file command,” that “[t]he UNIX file command . . . will return an
`
`indication of data for any kind of unrecognized file type,” and that there is
`
`therefore “a possibility” that Hsu would in fact fail to determine a data type and
`
`simply return “data.” Ex. 2003 at 146:15-148:1.
`
`
`
`
`
`
`- 7 -
`
`
`
`
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`But as Dr. Zeger explains, a POSA would understand Hsu to teach an
`
`approach that will always recognize a data type for each data block, and would not
`
`conclude that Hsu’s reference to UNIX file command indicates otherwise. Ex.
`
`2004 ¶ 27.
`
`Hsu describes a system that avoids any content independent compression
`
`and that instead uses an entirely content-dependent approach. Ex. 2004 ¶ 28. Hsu
`
`teaches the identification of a “block type” (i.e., data type) for each data block
`
`using a “new-file” procedure. Ex. 2004 ¶ 28; Ex. 1005 at 1103-1104. Hsu’s “new-
`
`file” procedure analyzes three 512-byte segments within the block: 512 bytes in the
`
`beginning, 512 bytes in the middle, and 512 bytes in the end. Ex. 2004 ¶ 28; Ex.
`
`1005 at 1103-1104. During that analysis, Hsu’s method looks for “the pattern of
`
`data contained” in each 512 byte segment. Ex. 2004 ¶ 28; Ex. 1005 at 1103-1104.
`
`Hsu compares each segment to a collection of known data patterns from Unix and
`
`other operating systems. Ex. 2004 ¶ 28; Ex. 1005 at 1103-1104.
`
`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. Ex.
`
`2004 ¶ 29; Ex. 1005 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. Ex. 2004 ¶ 29; Ex. 1005 at 1104. Where each of the
`
`
`
`- 8 -
`
`
`
`
`
`
`three segments points to different data types, Hsu uses “the first data type
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`detected.” Ex. 2004 ¶ 29; Ex. 1005 at 1104.
`
`
`
`Ex. 1005 at 1107.
`
`As Table I makes clear, Hsu’s list of ten possible data types does not include
`
`“data,” or any other indication of an unrecognized data type. Ex. 2004 ¶ 30.
`
`Accordingly, the teachings of Hsu itself foreclose the possibility that its approach
`
`will fail to recognize a data type for a data block. Indeed, Hsu specifically explains
`
`that its “new file” approach “compares not only the first 512 bytes of a data set, but
`
`also 512 bytes in the middle of the set and the 512 bytes at the end (if they exist)”
`
`in order to “provide a better indication of the primary data type of a file. . . .” Ex.
`
`2004 ¶ 30; Ex. 1005 at 1104 (emphasis original). Hsu also explains that its
`
`
`
`- 9 -
`
`
`
`
`
`
`approach compares those patterns to a larger set of known patterns than previous
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`versions of UNIX. Ex. 2004 ¶ 30; Ex. 1005 at 1104. Both of those teachings would
`
`lead a POSA to conclude that Hsu teaches an approach that will not only always
`
`recognize and output some data type, but will also be more likely to correctly
`
`recognize the data type. Ex. 2004 ¶ 30.
`
`As Dr. Zeger further explains, based on his continuous experience with
`
`UNIX since the 1980s, he is aware that there were numerous versions of UNIX’s
`
`file command during the 1980s and 1990s. Ex. 2004 ¶ 31. Those versions were not
`
`necessarily consistent. Id. And while some POSAs may have been familiar with
`
`UNIX and its file command as of the 1995 publication date of Hsu or the 2001
`
`priority date of the ’506 patent, a POSA would almost certainly not have been
`
`familiar with how any particular version of UNIX’s file command actually worked.
`
`Id. A POSA reading Hsu would neither know which particular version of UNIX’s
`
`file command Hsu had utilized, nor would he or she have reason to conclude that
`
`Hsu may fail to recognize data types because of its teachings regarding UNIX. Id.
`
`Critically, a POSA would appreciate that Hsu does not state that its approach is in
`
`any way identical to any particular version of UNIX’s file command, but rather
`
`states that “new-file works in similar fashion.” Ex. 2004 ¶ 31; Ex. 1005 at 1104
`
`(emphasis added). As Dr. Zeger also points out, there is no evidence that a POSA
`
`
`
`
`- 10 -
`
`
`
`
`reading Hsu would have had access to either the source code underlying Hsu’s
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`system or the source code the specific version of UNIX on which Hsu had relied.
`
`Ex. 2004 ¶ 31. Accordingly, the POSA would have no reason to look past Hsu’s
`
`own teachings—which demonstrate that Hsu will always identify a data type for
`
`each data block—to conclude that Hsu may sometimes fail to identify a data type
`
`simply because it was based on some unknown version of UNIX with unknown
`
`modifications. Id. Indeed, Hsu gives no suggestion that it will not identify a data
`
`type, nor any teaching or suggestion as to how such a situation would occur or
`
`would be addressed. Id. A POSA would not interpret that silence as an indication
`
`that Hsu has a problem that it does not address. Id. Rather, the POSA would
`
`understand that Hsu simply does not have such a problem. Id.
`
`C. Because Hsu’s approach would always be used to identify data
`types for Franaszek’s data blocks, and would always identify a
`data type for each data block, limitation 104[c] cannot be met.
`Limitation 104[c] can only be met where “a data type of the data block is not
`
`identified.” Ex. 2004 ¶ 32. As Dr. Creusere has testified, a POSA combining
`
`Franaszek with Hsu would always use Hsu to identify a block’s data type. Ex.
`
`2003 at 131:13-132:15. And as Dr. Zeger explains, Hsu will always identify a data
`
`type for any data block. Ex. 2004 ¶¶ 27-31. Accordingly, the combination of
`
`
`
`
`
`
`- 11 -
`
`
`
`
`
`Franaszek and Hsu will always identify a data type for each data block, Ex. 2004 ¶
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`33, and thus can never meet limitation 104[c].
`
`Petitioners’ alternative theory of modifying Franaszek based on Sebastian
`
`would make no difference to that outcome. Ex. 2004 ¶ 34. The Board should
`
`therefore find claim 104 patentable.
`
`IV. Petitioners’ Allegations Fail With Respect To Claim 105 Limitation [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,
`
`Petitioners’ theory again proposes adapting the descriptor-based system of
`
`Franaszek using the teachings from Hsu. See IPR2017-00176, Pet. at 43-44;
`
`IPR2017-00806, Pet. at 46. But the combination of Franaszek and Hsu ultimately
`
`defeats Petitioners’ obviousness theory because, as with claim 104, the ensuing
`
`system would always perform step 105[d1] and would never perform step 105[d2].
`
`Ex. 2004 ¶¶ 35-38.
`
`
`
`
`
`
`- 12 -
`
`
`
`
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`In discussing its theory with respect to element [d1], Petitioners assert 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.” IPR2017-
`
`00176, Pet. at 39; IPR2017-00806, Pet. at 41 (emphasis added). In such
`
`circumstances, Petitioners assert 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.” IPR2017-00176, Pet. at 40;
`
`IPR2017-00806, Pet. at 42. Thus as Petitioners recognize, 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 the data block will always be compressed “with at
`
`least one of said one or more encoders.” Ex. 2004 ¶ 37.
`
`The data analysis approach of Hsu, as discussed previously in Section III,
`
`will always recognize a data type. Ex. 2004 ¶¶ 27-31. Given that Petitioners
`
`propose modifying the system of Franaszek to incorporate the data type analysis
`
`approach of Hsu, and since Dr. Creusere admits that Hsu’s approach would always
`
`be used, Ex. 2003 at 131:13-132:15, 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
`
`
`
`- 13 -
`
`
`
`
`
`
`always compress that data block using those one or more associated encoders. Ex.
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`2004 ¶ 38. Accordingly, in the combined system of Franaszek and Hsu, step
`
`105[d1] will always occur.
`
`That is fatal for Petitioners’ theory as to Claim 105, because step 105[d2]
`
`recites “otherwise compressing said data block with a default data compression
`
`encoder.” By specifying “otherwise,” step [d2] requires a scenario where step [d1]
`
`does not occur. Since step [d1] will always occur in the combined system of
`
`Franaszek and Hsu, step [d2] will never occur.
`
`Petitioners have only two theories as to why step 105[d2] would allegedly be
`
`performed under their proposed combination. Both are incorrect.
`
`First, Petitioners argue that step [d2] could occur because Franaszek
`
`expressly contemplates a scenario where the data type information is not provided
`
`in the type field. See IPR2017-00176, Pet. at 41-42; IPR2017-00806, Pet. at 42-43.
`
`But that assertion deliberately ignores Petitioners’ proposal to modify Franaszek
`
`with Hsu. Petitioners cannot rely on Hsu when it is convenient for some limitations
`
`and then entirely ignore the combination when it is inconvenient for other
`
`limitations. Indeed, Dr. Creusere has acknowledged that Hsu’s approach would
`
`always be used to identify a data type for Franaszek’s data blocks. Ex. 2003 at
`
`131:13-132:15. And he has further testified that once the system of Franaszek has
`
`
`
`
`- 14 -
`
`
`
`
`been modified with Hsu, Hsu’s teachings are part of the overall system. Id. at
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`135:4-7. That ensuing system would always identify a data type. Ex. 2004 ¶¶ 27-
`
`31. Accordingly, step 407 of Franaszek would never be used or performed, and
`
`thus step 105[d2] of the Claim would never be performed. Id. at ¶ 38. Because
`
`Petitioners rely on Hsu for step 105[e]’s analyzing limitation, Petitioners are also
`
`bound by the consequences for purposes of step 105[d2]. Thus, to meet the
`
`“otherwise” limitation of Claim 105, Petitioners cannot ignore Hsu or rely on
`
`aspects of Franaszek that would never be performed in light of Hsu.
`
`Second, Petitioners assert that a POSA could have modified Franaszek such
`
`that—when “a data type has been included in the ‘type’ field, but is not associated
`
`with a particular encoder”—Franaszek would use a default encoder, as purportedly
`
`taught by Sebastian. IPR2017-00176, Pet. at 42-43; IPR2017-00806, Pet. at 44-45.
`
`That theory also fails.
`
`As a threshold matter, Petitioners do not provide actual evidence that a
`
`POSA would have a reason to believe that Franaszek’s system will ever fail to
`
`associate at least one encoder with an identified data type. Ex. 2004 ¶ 40. As Dr.
`
`Zeger explains, Franaszek’s teachings would cause a POSA to conclude that this
`
`scenario would not occur within Franaszek’s system. Id. Petitioners’ expert, Dr.
`
`Creusere, provided the same testimony at his deposition.
`
`
`
`- 15 -
`
`
`
`
`
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`Q. Okay. So your point is simply that Franaszek will have in some
`fashion a list of algorithms that have been predetermined to be the
`appropriate set for a particular data block given the data type
`information that has been provided for that data block?
`A. Yes. Franaszek will have a list of algorithms associated with a
`given type of data, assuming that, assuming that it knows that type of
`data. Franaszek doesn’t address the situation directly, where, where it
`doesn’t know – where there might be type description data. It doesn’t
`know it. But assuming it knows that data, it will have some sort of a
`list associated with that data of possible compression algorithms and it
`will select, it will go through the same process of selecting one of
`those compression algorithms to apply to encode the block.
`Q.
`And to your point just a second ago, Franaszek does not
`contemplate a situation in which it is provided with data type
`information but does not have a list of compression techniques
`associated with that data type. True?
`A.
`From the preferred embodiment of Franaszek, I don’t recall
`any indication that Franaszek contemplates that scenario.
`Ex. 2003 at 14:21-16:1 (emphasis added).
`
`Both parties’ experts thus agree that Franaszek does not have the problem
`
`that Petitioners purport a POSA would be motivated to remedy by modifying
`
`Franaszek based on Sebastian. Ex. 2004 ¶ 40. As the Federal Circuit recently made
`
`clear, a POSA would not be motivated to modify the base reference to incorporate
`
`
`
`
`
`
`- 16 -
`
`
`
`
`
`a solution for a problem that the base reference does not have. In re Schweickert,
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`676 F. App’x 988, 995 (Fed. Cir. 2017) (“This record describes no problem in
`
`Birrell that would be resolved by the semaphore in Cunniff.”). Accordingly, a
`
`POSA would not have been motivated to modify Franaszek based on Sebastian for
`
`the reasons set forth in the Petition. Ex. 2004 ¶ 41.
`
`Moreover, a POSA would not take from Sebastian the teaching that
`
`Petitioners ascribe to it. Petitioners claim 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.” IPR2017-00176, Pet. at 42; IPR2017-00806, Pet. at 44
`
`(emphasis added). But in fact, as Dr. Zeger explains, 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. 2004 ¶¶ 42-43; 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). Sebastian does not contain a
`
`teaching as to a scenario in which its generic filter will be used when a data type
`
`for a data block is not available to it. Ex. 2004 ¶ 43. Indeed, Sebastian does not
`
`even contemplate a scenario in which a data type is not available to its system. Id.
`
`And Dr. Creusere admitted that fact at his deposition. Id.
`
`
`
`
`
`
`- 17 -
`
`
`
`
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`So Sebastian does not have any discussion of a scenario in
`Q.
`which the data type for a data block is not available to it and what it
`would do in that scenario. True?
`A. Not to my recollection. Sebastian is a long patent. To be able to
`say that definitively, I would have to through line by line. But to my
`recollection, that is not something that is – that is covered by
`Sebastian.
`Q. And column 4 in that same section you were looking at, and
`throughout Sebastian, the only scenario in which Sebastian teaches
`using its generic filter is when its system does not already have the
`desired or appropriate compression technique for a particular data
`type. True?
`A.
`Sebastian specifically states that if it doesn’t have a filter that
`matches the source’s data format, then it will use a generic filter. So
`that is as far as it goes on the subject. It doesn’t, to my recollection,
`state other scenarios.
`Ex. 2003 at 27:19-28:16.
`
`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 Petitioners contend, because that is not a scenario Sebastian
`
`contemplates. Ex. 2004 ¶ 44. As Dr. Zeger further explains, that conclusion is not
`
`based on any notion that a POSA is limited to bodily incorporating one prior art
`
`reference into another, but rather based on the reality that a POSA reading
`
`
`
`- 18 -
`
`
`
`
`
`
`Sebastian would simply not have any basis for arriving at the idea of using
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`Sebastian’s generic filter to compress blocks with unrecognized data types. Id.
`
`There is simply no teaching or evidence in Sebastian or elsewhere in this
`
`proceeding to establish that a POSA would have arrived upon that idea. Id.
`
`Because the evidence demonstrates that the combination of Franaszek and
`
`Hsu would never practice limitation 105[d2], and that a POSA would not be
`
`motivated to combine Franaszek with Sebastian for the reasons and in the manner
`
`described in the Petition, the Board should not find claim 105 unpatentable.
`
`V. Conclusion
`For the reasons set forth above, Patent Owner respectfully requests that the
`
`Board find claims 104 and 105 not unpatentable.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`- 19 -
`
`
`
`
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`Respectfully submitted,
`
`/s/ Kayvan B. Noroozi
`
`William P. Rothwell, Reg. No. 72,522
`NOROOZI PC
`2245 Texas Drive, Suite 300
`Sugar Land, TX 77479
`
`Kayvan B. Noroozi, Admitted Pro Hac Vice
`NOROOZI PC
`1299 Ocean Ave., Suite 450
`Santa Monica, CA 90401
`
`Attorneys for the Patent Owner
`
`
`Date: September 22, 2017
`
`
`
`
`
`
`- 20 -
`
`
`
`
`
` IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`CERTIFICATION OF WORD COUNT
`
`
`
`The undersigned hereby certifies that the portions of the above-captioned
`
`PATENT OWNER’S RESPONSE specified in 37 C.F.R. § 42.24 have 3,959
`
`words, in compliance with the 14,000 word limit set forth in 37 C.F.R. §
`
`42.24(b)(2). This word count was prepared using Microsoft Word 365.
`
`
`/s/ William P. Rothwell
`
`William P. Rothwell, Reg. No. 72,522
`NOROOZI PC
`2245 Texas Drive, Suite 300
`Sugar Land, TX 77479
`
`Attorney for the Patent Owner
`
`
`Date: September 22, 2017
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IPR2017-00176
`IPR2017-00806
`PATENT OWNER’S RESPONSE
`
`
`CERTIFICATION OF SERVICE
`
`The undersigned hereby certifies that the foregoing PATENT OWNER’S
`
`RESPONSE and the exhibits thereto were served electronically via e-mail on
`
`September 22, 2017, in their entireties on the following counsel of record for
`
`Petitioner:
`
`IPR2017-00176
`Andrew R. Sommer
`Thomas M. Dunham
`Garth A. Winn
`Vivek V. Krishnan
`
`
`
`IPR2017-00806
`Eliot D. Williams
`Jamie R. Lynn
`Andrew Wilson
`Michelle Eber
`
`Date: September 22, 2017
`
`
`
`
`
`
`
`
`
`
`IPR2017-00176@winston.com
`garth.winn@klarquist.com
`
`
`
`eliot.williams@bakerbotts.com
`jamie.lynn@bakerbotts.com
`andrew.wilson@bakerbotts.com
`michelle.eber@bakerbotts.com
`DLTeradata@bakerbotts.com
`
`
`
`
`/s/ William P. Rothwell
`
`William P. Rothwell, Reg. No. 72,522
`NOROOZI PC
`2245 Texas Drive, Suite 300
`Sugar Land, TX 77479
`
`Attorney for the Patent Owner
`
`
`
`
`
`
`
`
`
`
`