throbber

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket