3
`
`,
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD IN THE UNITED
`
`V STATES PATENT AND TRADEMARK OFFICE
`
`Trial No.:
`
`IPR 2013—00085
`
`In re:
`
`US. Patent No. 7,945,539
`
`Patent Owners:
`
`PersonalWeb Technologies, LLC & Level 3 Communications
`
`Petitioner:
`
`EMC Corp.
`
`Inventors:
`
`David A. Farber and Ronald D, Lachman
`
`For: DISTRIBUTING AND ACCESSING DATA IN A DATA PROCESSING
`
`SYSTEM
`
`*
`
`*
`
`>I<
`
`*
`
`*
`
`*
`
`*
`
`*
`
`*
`
`*
`
`*
`
`August 6, 2013
`
`PATENT OWNER’S RESPONSE PURSUANT TO 37 C.F.R. § 42.120
`
`EMC/VMware v, PersonalWeb
`
`IPR2013—00083
`
`EMCVMW 1079
`
`2020057
`
`

`

`Patent Owner’s Response (US. Pat. No. 7,945,539)
`
`IPR 2013-00085
`
`TABLE OF CONTENTS
`
`Page
`
`INSTITUTED GROUNDS .............................................................................. l
`
`.II.
`
`CLAIM CONSTRUCTIONS ASSUMED AND USED BY PATENT
`
`OWNER HEREIN ........................................................................................... l
`
`III.
`
`LAW REGARDING ANTICIPATION .......................................................... 3
`
`IV.
`
`CLAIMS 10 AND 21 ARE NOT OBVIOUS OVER KANTOR .................... 3
`
`A.
`
`B.
`
`Kantor as allegedly modified fails to disclose segment
`identifiers based at least in part on a first, given function offonly
`the data in respective segments of the data item ................................... 3
`
`Petitioner’s allegations of obviousness cannot cure the
`deficiencies in Kantor, and furthermore it would not have been
`obvious to have modified Kantor to have also applied a CRC to
`compressed versions of files in a ZIP file ........................................... 13
`
`C It: would not “have been obvious tohave modified Kantor so: that
`
`read; and d0wn10ad BB S commands would. accept contents-
`signatures to identify files on which to operate .................................. ‘1 5"
`
`CLAIM 34 IS NOT OBVIOUS OVER KANTOR IN VIEW OF
`
`LANGER ....................... ................................................................................. 22
`
`A.
`
`B.
`
`C.
`
`Kantor as allegedly modified fails to disclose: dividing a‘ data
`item into a. plurality of segments and determining a
`corresponding segment identifier for each of the segments ........ ,. ....... 23“
`
`Kantor as allegedly modified fails to disclose determining
`segment identifiers after dividing as required by claim 34 ................. 34
`
`Kantor as allegedly modified fails to disclose determining
`segment identifiers for segments of the data item, where the
`segment identifiers are True Names of the data making up the
`segments, as required by claim 34 ...................................................... 35
`
`D.
`
`Kantor :a's allegedly modified fails to disclose determining a
`
`2020057
`
`

`

`Patent Owner’s Response (US. Pat. No. 7,945.539)
`
`IPR 2013-00085
`
`True Name of the second data item, and providing the second
`data item in response to an access request .......................................... 37
`
`VI.
`
`CLAIMS 10 AND 21 ARE NOT ANTICIPATED BY LANGER ............... 40
`
`VII.
`
`_
`CLAIM 34 IS NOT OBVIOUS OVER LANGER IN VIEW OF
`WOODHILL ................................................................................................... 43
`
`VIII.
`
`CLAIMS 10 AND 21 ARE NOT OBVIOUS OVER WOODHILL IN
`
`VIEW OF FISCHER
`
`............................................................................... 47
`
`A. Woodhill as allegedly modified by Fischer fails to disclose
`using segment identifiers to request segments .................................... 47
`
`B.
`
`It would not have been obvious to have modified the Binary
`Object Identifiers in Woodhill to be a hash of the “contents
`identifiers” ........................................................................................... 5 l
`
`SECONDARY CONSIDERATIONS ........................................................... 54
`
`X.
`
`KANTOR AND LANGER ARE NOT “PRINTED PUBLICATIONS” ...... 54
`
`XI.
`
`CONCLUSION........................................i...................................................... 6O
`
`PATENT OWNER’S EXHIBIT LIST
`
`CERTIFICATE OF SERVICE
`
`2020057
`
`

`

`PersonalWeb Technologies, LLC (“patent owner” or “PO”) hereby responds
`
`to the petition. Petitioner has not met its burden of proving unpatentability by a
`
`preponderance of the evidence, 35 U.S.C. § 316(e), for the following reasons.
`
`I. INSTITUTED GROUNIBS
`
`1.
`
`Whether claims 10 and 21 of the ‘539 patent are unpatentable
`
`under 35 U.S.C. §103(a) as obvious over Kantor (Ex. EMC 1004).
`
`2.
`
`Whether claim 34 of the ‘539 patent is unpatentable under 35
`
`3.
`
`4.
`
`5.
`
`U.S.C. §103(a) as obvious over Kantor and Langer.
`
`Whether claims 10 and 21 of the ‘539 patent are anticipated under
`35 US-C §i 102(b) by Langer (Ex. EMC 1,003).
`
`Whether claim 34 ofthe ‘539 patent is unpatentable under 35
`
`U.S.C. §103(,a’) over Langer and Woodhill (Ex. EMC 1005):.
`
`Whether claims 10 and 21 are unpatentable under §103(a) as
`
`obvious over Woodhill and Fischer (Ex. EMC 1036).
`
`II. CLAIM CONSTRUCTIONS ASSUMED AND USED BY PATENT
`
`OWNER HEREIN
`
`The Board construed the following terms in its Decisions dated May 17,
`
`2013 and June 5, 2013. The Board’s constructions of these terms have been
`
`assumed to be correct for purposes of this IPR and have been used by patent owner
`
`(PO) herein (without prejudice to argue otherwise in other proceedings).
`
`Claim
`
`Board’s Construction
`
`Term
`
`
`
`
`
`1
`
`2020057
`
`

`

`Patent Owner’s Response (U.S. Pat.‘ No. 7,945,539)
`
`IPR 2013-00085
`
`examples in a non-exhaustive list: (1) the contents of a file; (2) a
`
`
`
`
` Sequence ofbits. (‘539 patent, col. 2: 16—17.) As the Board explained
`
`
`in its June 5, 2013 Rehearing Decision in IPR 2013—00082, the
`I
` “sequence of bits” may include any of the following which represent
`
` portion of a file; (3) a page in memory; (4) an object in an object—
`
`oriented program; (5) a digital message; (6) a digital scanned image;
` (7) a part of a video or audio signal; (8) a directory; (9) a record in a
`
`database; (10) a location in memory or on a physical device or the
`
`
`
`
`
`like; (1 1) any other entity which can be represented by a sequence of
`
`bits.
`
`(June 5, 2013 Rehearing Dec. in IPR 2013-00082 at 2-3 [Ex.
`
`2017]; and May 17, 2013 Dec. at 8-9.) This is consistent with the
`
`district court’s August 5, 2013 construction of “data item” in the
`
`related litigations. (Ex. 2021.)
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`other special characters.” (Dec. on Rehearing, June 5, 2013, at 2-3.)
`
`A “substantially unique alphanumeric labelfor a particular data
`item.” (May 17, 2013 Dec. at 11-12.) Moreover, the Board properly
`
`
`
`
`
`
`
`“data
`
`
`A ‘Substantially unique alphanumeric labelfor a particular data
`
`identifier”
`
`
`
`item.” (May 17, 2013 Dec. at 10—11.) Moreover, the Board properly
`
`
`
`construed “alphanumeric” as “consisting of letters or digits, or both,
`
`and sometimes including control characters, space characters, and
`
`
`
`
`
`
`
`other special characters.” (Dec. on Rehearing, June 5, 2013, at 2—3.)
`Additionally, the preambles of claims 10 and 21 are limiting. The bodies of
`
`construed “alphanumeric” as “consisting of letters or digits, or both,
`
`and sometimes including control characters, space characters, and
`
`these claims refer back to the respective preambles, with each preamble being
`
`needed for completeness of the claim. For example, the body of claim 10 refers to
`
`“said plurality of segments” from the preamble, to “said data item” from the
`
`2
`
`2020057
`
`

`

`Patent Owner’s Response (US. Pat. No. 7,945,539)
`
`IPR 2013-00085
`
`preamble, and. to “said networ ” from the preamble. As another example, the
`
`body of claim 21 refers to “said plurality of segments” from the preamble and to
`
`“said network of computers” from the preamble.
`
`III. LAW REGARDING ANTICIPATION
`
`“A claim is anticipated only if each and every element as set forth in the
`
`claim is found, either expressly or inherently described, in a single prior art
`
`reference.” Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631
`
`(Fed. Cir. 1987). A feature is “inherent” in a reference only if that feature is
`
`“necessarily presen ” in the reference, “not merely probably or'possibly presen .”
`
`Triniteclndust, Inc. vi. Top~U.S.A. CDFPL, 295 F.3d 1292,. 1295: (Fed. Cir; 2002):.
`
`Furthermore, in order to anticipate, a prior art reference must not only disclose all
`
`elements, of the claim, butm‘us‘t also disclose those elements “arranged as in the
`claim.” Net MoneyIN, Inc. v. VeriSign, 1716;, 545' F.3d 1359, 1369 (Fed. Cir. 2008).
`
`IV. CLAIMS 10 AND 21 ARE NOT OBVIOUS OVER KANTOR
`
`The grounds based on Kantor are discussed first because Kantor is helpful in
`
`providing an understanding ofpackages (e;g., ZIP files) also relevant to Langer.
`
`A. Kantor as alle edl modi zed ails to disclose se
`
`
`least in part on a first given function of only the data in respective
`segments at the data item.
`
`ent'identi zers based at
`
`
`Claim 10 of the ‘539 patent states, inter alia (emphasis added):
`
`"said data item comprising a plurality ofsegments .
`
`.
`
`. the segment
`
`identifier for each particular segment being based, at least in part, on a
`
`2020057
`
`

`

`Patent Owner’s Response (U.S. Pat. No. 7,945,539)
`
`IPR 2013-00085
`
`first given function ofthe data comprising saidparticular segment and
`
`only the data in saidparticular segment.”
`
`Claim 21 has essentially the same limitation. The plain language in each of claims
`
`10 and 21 requires that the segments are part of the data item, and that the segment
`
`identifiers are based at least on a first given function of only the data in the
`
`respective Segments of the data item. (Dewar Decl., 1H] 23—24 [EX. 2020].) Kantor
`
`fails to disclose this, and instead teaches away from this as Kantor never applies
`
`the alleged first functi0n to any segment of the alleged data item. (Dewar Decl,
`
`1]] 23-36 [EX. 2020] .) In Kantor, the allegedfirstfunction (CRC) is not applied to
`
`any part 0ftlze alleged data item (ZIPfile). Id. Instead, in Kantor the CRC is
`
`applied to uncdmpres's‘ed files befarevthey are compressed and. packaged into the
`
`ZIP to form the alleged first data item. (Clark Dep. '65, ’67 [EL 2016]; Dewar
`
`Decl., 1H] 25-26 [Ex. 2020].) Therefore, in Kantor the CRC is never applied to the
`
`compressed “inner files” (f‘fileSP’) that are parts ofthe ZIP file in. determining
`
`Kantor’s “zipfile contents signature” (“zc-s”). Id. The CRC in Kantor is applied to
`
`different bit sequences. (uncompressed files) than the bit sequences (compressed
`
`files) that make up the ""files”i(alleged' segments) in the ZIP file (alleged data
`
`item). (Dewar Decl., 1] 26 [Ex. 2020].) Stated another way, a CRC value in a ZIP
`
`file is not determined based on a CRC of the sequence of bits in the compressed
`
`file in the ZIP — instead, it is based on a CRC of the sequence ofbits in the
`
`uncompressed file which is not part of the ZIP file. Id. Because the alleged first
`
`function (CRC) in Kantor is not applied. to any part of the alleged. data item (ZIP
`
`4
`
`2020057
`
`

`

`Patent Owner’s Response (US. Pat. No. 7,945,539)
`
`IPR 2013—00085
`
`file), the alleged. segment identifiers (CRC values stored. in the ZIP file) in Kantor
`
`V
`
`are not based at least on a CRC of only the data in the respective segments (inner
`
`“files”) of the data item (ZIP file). Id. Kantor cannot meet the above-identified
`
`subject matter of claims 10 and 21, and petitioner’s obviousness allegations cannot
`
`' cure this fundamental deficiency in Kantor.
`
`It was well known in early 1995 that a ZIP file included much more than the
`
`individual or inner “files” therein.
`
`(EX. 2004; Clark Dep. 54-60 [Ex 2016]; Dewar
`
`Decl., 11 27 [EX. 2020].) The ZIP file standard. from 1990 confirms that a ZIP file
`
`includes, in addition to the inner “file-s” therein, other parts including local
`
`headers, a central directory, compression data, time and date data, file names,
`
`comments, file attributes, offset/order data, CRC values, uncompressed Size
`
`(length): data, and compressed size data. (Dewar Decl, "1[ 27'[EX. 2020]..) Kantor
`
`'acknowledgesl‘this. (Id; and Kantor at page 2 of Preface, 9, and 55.) The CRC
`
`values, compression data, uncompressed size (length) data, and compressed. size
`
`data in a ZIP file are contained in the local headers and central directory of the ZIP
`
`file, which are separate from the individual files in the ZIP file. (Ex. 2004; Clark
`
`Dep. 56-60. [EL 2016],; Dewar Decl, 11 27 [Ex. 2020].)
`
`Petitioner relies solely on Kantor as allegedly anticipating the above-
`
`identified subject matter of claims 10 and 21. Petitioner-refers to Kantor’s “zipfile
`
`contents signature” (“203” or “2”) procedure which reads pre-calculated CRC
`
`values from the ZIP file, and adds them together mod2"32. ,(Kantor, page 2 of
`
`5
`
`2020057
`
`

`

`Patent Owner’s Response (Us. Pat. No. 7,945,539)
`
`IPR 2013-00085
`
`Preface, 9, 55.) Petitioner contends that:
`
`(i) the “data item” in Kantor is a ZIP file,
`
`(ii) the “segments” in Kantor are the individual files in the ZIP file, (iii) the “first
`
`given function” in Kantor is a CRC, (iv) the “first identifier” for the data item in
`
`Kantor is the “zipfile contents signature” (“zcs” or “2”), and (V) the “second given
`
`function” in Kantor is the modulo addition 2"32 applied to the CRC values. (Pet.
`
`47—49.) However, Kantor fails to disclose that the alleged segment identifiers
`
`(CRC values) are based at least on a first given function (CRC) of only the data in
`
`the respective alleged segments (files) of the alleged data item (ZIP file), because
`
`in, Kantor the CRC is never applied. to any segment of the ZIP file in determining.
`
`the “205.”
`
`(Dewar'D‘eclq 1H] 25—26 [EX. 2020].)
`
`The “files” in a ZIP file are almost always compressed. (Clark Dep. 55, 67
`
`[Ex. 2016]; Dewar Decl, 1] 28 [‘EX. 2020].) Kantor confinns that: the “files” in the
`
`ZIP files in Kantor are compressed, as Kantor repeatedly refers to compression
`
`data in the ZIP files. (Kantor, page 2 of Preface, and pages 9, 55; Dewar Decl, 1]
`
`28 [Ex. 2020].) And petitioner’s expert admits that the files within Kantor’s ZIP
`files are compressed.
`(EX. EM’C 1009, Q] 35.) However, the CRC values (alleged
`
`“segment identifiers”) and uncompressed size (length) values in a ZIP file are
`
`determined before the files are compressed and thus before they are packaged into
`
`the ZIP file. (Clark Dep. 65, 67, 76-77 [Ex. 2016];‘Dewar Decl, 1] 28 [Ex._ 2020] .)
`
`Fer each “file” that is going to be packaged into a ZIP file, a CRC function is
`
`, applied to the uncompressed version thereof to determine its CRC value (alleged
`
`2020057
`
`

`

`\
`
`Patent Owner’s Response (US. Pat. No. 7,945,539)
`
`-
`
`IPR 2013-00085
`
`“segment identifier”) before the file is compressed. and thus before the file is
`
`packaged into the ZIP. Id. Petitioner’s expert confirms this basic flaw in Kantor:
`
`Q. So it's your understanding that the CRC value in the local header
`
`was calculated by applying a CRC to the inner file before that file was
`
`compressed and packaged into the ZIP file?
`
`MS. VREELANDi Objection outside the scope.
`
`A.
`
`I think that's right.
`
`(Clark Dep. 67 [EX. 2016].) And petitioner’s expert confirmed that the CRCs in
`
`the 1990 ZIP standard are the same as those in Kantor. Id. at 63.
`
`This is done for each “file” that is going to be stored in a ZIP file. (Dewar
`
`Decl, {I 28 [EX...2020].‘) Then, after the. CRC values (alleged “Segment
`
`identifiers”) and uncompressed size values have been determined based on
`
`uncompressed files, the “files” are compressed and packaged into the ZIP :file in
`
`compressed form along with their respectivevCRC.’ values, uncompressed length
`
`(size) values, comments, etc. Id. Inside the ZIP file, the CRC values and
`
`uncompressed length values are stored in the local headers and central directory
`
`which are separate from the compressed t‘files” (alleged “segments”).
`
`(161.; EX.
`
`2004; Clark Dep. 54—60, 64, 67, 88-89 [Ex. 2016].) Thus, the uncompressed files
`
`from which the CRC values and uncompressed size (length) values are determined
`
`. are different than the compressed files (alleged “parts” of the data item) that are
`
`ultimately stored in the ZIP file. (Dewar Decl, {I 29 [Ex. 2020].) It was known in
`
`the art at the time of the invention that the bit sequence of an uncompressed
`
`2020057
`
`

`

`Patent Owner’s Response (U.S. Pat. No. 7,945,539)
`
`IPR 2013-00085
`
`version of a given “file” is much different than the bit sequence of a compressed
`
`version of that same “file.” Id. Compression changes the bit sequence. Id.
`
`Therefore, in Kantor the CRC function is applied to one sequence of bits for a
`
`given “file” (i.6., the uncompressed version, which is not part of the ZIP file and
`
`thus not part of the alleged data item) in order to determine the CRC value, and
`
`another sequence of bits (i.e., the compressed version — an alleged “segrnent”) is
`
`stored in the ZIP file which is the alleged “data item.” Id.
`
`Applying a given CRC function, the uncompressed version of a "file" will
`
`have one CRC value; While the compressed version of that "file" will haveiza.
`
`different CRC Value. (Dewar Decl, 1} 30 [Ex. 2020].) This is because the two
`
`versions have much different sequences of bits. Id. Therefore, the uncompressed ‘
`
`and compressed versions cannot be, treated as the same thing with respect'to; the
`
`. claims. Id; This emphasizes that the uncompressed version to which the CRC
`
`function is applied in Kantor is much different than the compressed version which
`
`in Kantor is part of the ZIP file (the alleged “data item”).- Id. This applies to all
`
`“files” in a ZIP file. Id. The alleged segment identifiers (CRC values) in Kantor
`
`are not based in any respect on segments 0fthe alleged data item (ZIP file) —
`
`instead, they are based on bit sequences very different therefrom. Id.
`
`Kantor explains in detail how he calculates a “zipfile contents signature” -
`
`.(“zcs”). (E.g., Kantor, 55.) In particular, Kantor states (emphasis added):
`
`“2 = make a "Zipfile contents signature" for (each) Zipfile.
`
`8
`
`2020057
`
`

`

`Patent Owner’s Response (US. Pat. No. 7,945,539)
`
`IPR 2013-00085
`
`This is done by [Mg the 32_bit CRC‘s for all the files in the zipfile,
`
`adding them together mod 2A32, Legging all the
`
`uncompressed_filefilengths listed in the zipfile, adding them together
`mod 2‘32, and then putting the two pieces together to make a special
`
`zipfile_contents_signature (zcs). This zcs does not depend on the
`
`names, dates, compression ratios, order of appearance, zipped paths,
`
`nor comments, of files appearing in the zipfile, nor on the zipfile‘s
`
`name, date, nor zipfile comment. It is a powerful tool for finding
`
`duplication. This has special features, discussed in the introduction.”
`
`(Kantor at 55.) Thus, Kantor reads the CRC values from the ZIP file and reads the
`
`uncompressed file lengths (Sizes) from the ZIP file, and uses thesepre—eal‘culated
`
`values to determine the “zipfile contents: signature” '(,“Izcis:”);;f0r'th'ei ZIP file.
`
`(Dewar Decl., 1] 31 [Ex. 2020].) Importantly, Kantor never applies a CRC function
`
`to the compressed version of any “file” in the ZIP file indetermining the zcs. Id.
`
`Instead, as explained, above, the CRC values (alleged “segment identifiers”) were
`
`previously determined by applying. the CRC fimetion to uncompressed versions of
`
`the files. (Id; and Clark Dep. 65, 67, 76-77 [Ex. 2016].) Of course, the
`
`uncompressed versions to which the CRC is applied. are :not part of the alleged data
`
`item in Kantor (128., they are not part of the ZIP file).
`
`(Dewar Decl., 1] 31 [Ex.
`
`2020].) It is also noted that the uncompressed file lengths and modulo additions in
`
`(Kantor are also not applied to the compressed version of any “file” in the ZIP file
`
`in determining the zcs. Id.
`
`2020057
`
`

`

`Patent Owner’s Response (US. Pat. No. 7,945,539)
`
`‘
`
`IPR 2013-00085
`
`Therefore, in Kantor the CRC (alleged first given function) is not applied to
`
`any segment of the ZIP file in determining the “203” -— instead, the CRC is applied
`
`to different bit sequences (the uncompressed versions of the files) before they are
`
`compressed and packaged into the ZIP file. (Clark Dep. 65, 67 [Ex. 2016]; Dewar
`
`Deal, 11 32 [Ex. 2020].) And no other alleged function is applied to inner files in
`
`the ZIP in determining the “zcs.” Id. Accordingly, Kantor fails to disclose
`
`segment identifiers based at least on a first given function of only the data in the
`
`respective segments of the data item as required by claims 10 and 21. Id. Stated
`
`another way, Kantor fails: to disclose that a segment identifier is determined based
`
`on at least a first given function of‘the sequence of"bits in the segment of the data
`
`item as called for in claims 10 and 21. (Dewar Decl., 1} 32 [Ex. 2020].) Moreover,
`in Kantorthe uncompressed Version ofthe file. to “which the CRC is applied will
`
`have many more bits than the compressed version of the file which is part of the
`
`ZIP file, thereby emphasizing that the CRC value (alleged segment identifier) for a
`
`given file cannot be based on a CRC of “only the data” in the compressed version
`
`which is the alleged segment of the data item. Id. Kantor does not meet this
`
`subjectmatter of claims 10 and 21, and petitioner’s allegations of obviousness
`
`cannot cure these deficiencies in Kantor.
`
`Moreover, while petitioner does not mention this, the uncompressed versions
`
`of the “files” do not somehow collectively form a “data item” before they are
`
`packaged into the ZIP file because the separate uncompressed files do not
`
`1 0
`
`2020057
`
`

`

`Patent Owner’s Response (U.8. Pat. No. 7,945,539)
`
`IPR 2013-00085
`
`represent a “sequence of bits” which is the construction, of a “data item.” (Dewar
`
`Decl., 1} 33 [EX. 2020].) To one of ordinary skill in the art, it cannot reasonably be
`
`said that a plurality of separate standalone files make up a “data item” or a
`
`“sequence of bits.” Id. Petitioner apparently recognizes this, as petitioner
`
`contends that the “data item” in Kantor is the ZIP file itself.
`
`Additionally, while petitioner does not mention it, the “segments” in claims
`
`10 and 21 cannot correspond to just the CRC values in a ZIP file in Kantor.
`
`(Dewar Decl., 1] 34 [Ex. 2020].) If one were to take this approach, there would be
`
`no ““segment identifiers” for the respective CRC values obtained by applying a first
`given function to only "the data ofthe CRC values. Id. Moreover, there would be
`
`no second given function ofthe plurality of segment identifiers as required by
`
`“claims 10 and .21., because? there would be no such segment identifiers. I'd. Thus,
`
`such an approach also would not work with respect to meeting the above-identified
`
`requirements of claims 10 and 21 for which petitioner relies on Kantor.
`
`Furthermore, while petitioner does not mention it, PO also points out that
`
`Kantor’s “y” procedure also fails to meet the subject matter of claims 10 and 21.
`
`(Dewar Decl., 1t 35 [EX. 2020].) For the “y” procedure (the procedure referred to
`
`as “y = make csfor zipfile as z'fiylaz'nfile” on page 55 of Kantor), Kantor explains
`
`that “unlike” the “z” or “zcs” procedure relied on by petitioner, the “y” procedure .
`
`calculates a CRC value based on “every byte in the zipfile.” Id. However,
`
`Kantor’s “y” procedure (i) does not treat a ZIP file as multiple parts, (ii) does not
`
`11
`
`2020057
`
`

`

`Patent Owner’s Response (US. Pat. No. 7,945,539)
`
`[PR 2013-00085
`
`determine segment identifiers for respective segments of the ZIP file, (iii) does not
`
`apply any first given function to only data of a particular segment of the data item,
`
`(iv) cannot be used to request particular segments of the ZIP file because there are
`
`no identifiers for particular segments of the ZIP file, and (v) has no second given
`
`function that is applied to a plurality of segment identifiers. Id. For each of these
`
`reasons, Kantor’s “y” procedure is unrelated to claims 10 and 21. And again,
`
`petitioner’s allegations of obviousness cannot cure these deficiencies in Kantor’s
`
`“y” procedure. Additionally, while petitioner does not mention this, PO also
`
`points out that it would be fundamentally- improper to switch between the different
`
`“‘2” and “y” procedures of"Kantor'in an attempt to meet the portions ofClaims ‘10
`
`and 21 for which petitioner cites Kantor. (Dewar Decl., 1] 36 [EX. 2020].) It is
`
`_ well established that in order to meet. a claim a'reference must .not only disclose the
`
`elements of the claim, but must also disclose those elements “arranged or
`
`combined in the same way as in the claim.” Net MoneyIN, Inc. v. VeriSz‘gn, Ina,
`
`‘ 545 F.3d 1359, 1369-71 (Fed. Cir. 2008). One cannot do this by citing to different
`
`procedures in a reference that are used for different purposes. Id. Neither the “z”
`
`procedure nor the “y” procedure of Kantor meets the portions of claims 10 and 21
`
`for which petitioner’cites Kantor, as explained above. (Dewar Decl., 1] 36 [Ex.
`
`2020].) Moreover, these two procedures of Kantor are not reasonably or logically
`
`combinable. Id. Kantor explains that his system solves the “problem” of ZIP files
`
`being added to the system based on changes in names, dates, compression ratios,
`
`12
`
`2020057
`
`

`

`Patent Owner’s Response (US. Pat. No. 7,945,539)
`
`IPR 2013-00085
`
`orders of appearance, paths, and comments in a ZIP file. (Id, and Kantor at page I
`
`of the Preface.) In order to solve this “problem”, Kantor repeatedly emphasizes
`
`that his identifier used to determine whether to add a newly received ZIP file to the
`
`system, namely the “zip contents identifier” or “zcs”, is “independent from” and
`
`“not based on” parts of ZIP files including information such as names, dates, order,
`
`compression, and comments. (Kantor, page 2 of Preface, 9, and 55; Dewar Decl.,
`
`1} 36 [Ex 2020].) Thus, Kantor intentionally ignores the data and parts in each ZIP
`
`file relating to file names, dates, compression ratios, order of appearance, zipped
`
`paths, comments, and headers in determining “zcs” identifiers, thereby teaching
`
`away from claims 10 and 21. Id; One of‘ordinary skill in the art would not have
`
`ignored these express teachings, and thus would not have modified the “205”
`
`identifier so as to bejust a CRC of.the ZIP file as in. the “y” procedure because this
`
`would not allow Kantor’s identified “problem” to be solved. Id. Still further, even
`
`if this were to have been done (which one of ordinary skill in the art would never
`
`have done or tried as explained above), claims 10 and 21 still would not be met
`
`because the modified identifier technique would not meet the claims for the
`
`reasons explained above in connection with the “y” procedure.
`
`B. Petitioner is allegations of obviousness cannot cure the deficiencies in
`Kantor, and furthermore it would not have been obvious to have modified
`Kantor to have also applied a CRC to compressed versions 01 leGS in a
`ZIP zle.
`
`As explained above, petitioner’s allegations of obviousness cannot cure the
`
`insufficiencies in Kantor explained above regarding claims 10 and 21. Petitioner
`
`l 3
`
`2020057
`
`

`

`Patent Owner’s Response (US. Pat. No. 7,945,539)
`
`IPR 2013-00085
`
`does not contend that it would have been obvious to have modified Kantor’s “zcs”
`
`procedure to have also applied a CRC to the compressed versions of the files in a
`
`- ZIP file, much less to “only” the data in such compressed files.
`
`Moreover, there would have been no logical reason to have modified Kantor
`
`in such a manner. (Dewar Decl, 1H] 37-41 [Ex. 2020].) The ZIP standard requires
`
`that a CRC be applied to uncompressed files. Id. at 1] 38. This occurs before the
`
`files are compressed for storage in a ZIP file. Id; The resulting CRC values are
`
`stored in the ZIP file along with compressed versions of the files. Id. Given that
`
`such CRC values. for uncompressed files are already required by the ZIP standard,
`
`there would have been no logical reason to have modified Kantor to have also
`
`applied a CRC to the compressed versions of the files that are stored in the ZIP
`
`files. Id. Petitionerfs expert confirmed this with his “butwhy” ‘testi‘mony‘which
`
`emphasizes that there would have been no logical reason to have applied the CRC
`
`to the compressed files in the ZIP. (Clark Dep. 75 [Ex. 2016].)
`
`Furthermore, as a matter of common sense, one of ordinary skill in the art
`
`would not have modified Kantor to have applied the CRC to the compressed
`
`versions of the files because this would. have resulted in the contents identifiers in
`
`Kantor being significantly less unique (tie, a much higher probability of two
`
`different files having the same contents identifier). (Dewar Decl, 1] 39 [Ex.
`
`2020].) Kantor teaches away from techniques that would unintentionally result in,
`
`a higher probability of two different files having the same contents identifier,
`
`14
`
`2020057
`
`

`

`Patent Owner’s Response (US. Pat. No. 7,945,539)
`
`IPR 2013-00085
`
`thereby discouraging such a modification. (Id, and Kantor, 6—7.) As of early
`
`1995, it was known that the compressed version of a file had significantlyfewer
`
`bits than did the uncompressed version of that file. (Dewar Decl, 1} 39 [Ex.
`
`- 2020].) Therefore, because applying the CRC to compressed files would apply the
`
`CRC to many fewer bits (compared to applying the CRC to uncompressed files),
`
`applying the CRC to the compressed versions of files would result in a much
`
`higher probability of two different files unintentionally having the same CRC value
`
`and the same contents identifier which is taught to be undesirable by Kantor. Id.
`
`Moreover, Kantor. already has an efficient way to. read ’pre-calculated CRC
`
`values that are required by the ZIP standard and were taken from the uncompressed
`
`files, and there would have been no logical reason to have changed it. (Dewar
`
`"Dec-1.,‘1l‘40 [EL 2020].) Kantor’s technique reads the pre—calculated CRC“ values
`
`and pre-calculated uncompressed length values from the ZIP file (these were
`
`already pre-calculated as part of the ZIP standard), which provides for an efficient
`
`approach to calculating zc—s values. Id. One would not have modified Kantor to
`
`have also applied the CRC to compressed versions of the files in the ZIP because
`this would result in additional unnecessary steps and Kantor expressly teaches that
`
`additional time/steps for calculations are undesirable. (Id, and Kantor 7.)
`
`C. It would not have been obvious to have modified Kantor so that read and
`download BBS commands would accept contents-Signatures lo identizi
`(lies on which to operate.
`'
`
`1 5
`
`2020057
`
`

`

`Patent Owner’s Response (US. Pat. No. 7,945,539)
`
`IPR 2013-00085
`
`Petitioner acknowledges that BBS commands, such as download, and read.
`
`commands, were based on conventional filenames at the time of the ‘539
`
`invention. (Ex. 1009 at 1] 40; and Dewar Decl, 1i 42 [Ex. 2020].) However,
`
`petitioner contends (without citing any secondary reference) that:
`
`“[A] person of ordinary skill in the art would have found it obvious to
`
`modify the BBS commands, including the download and/or read
`commands, to permit identifying files based on contents-signatures or
`
`Zipfile cements-signatures. Among other things, this would facilitate
`
`integrity checking by more precisely specifying the file of interest by
`
`its content, and thus improve accuracy.”
`(Pet. 46.) Petitioner alleges} this imodificatiOn in order to meet at least section (B)
`
`in claims 10 and ‘2]. Absent this modification, at: least section (B) of claims 10' and
`
`21 cannot‘be met by Kantor. Contraryto petitioner’s allegation, this would not
`
`have been obvious for several reasons. (Dewar Decl, {HI 42-48 [Ex. 2020].)
`
`First, a significant problem with Kantor’s contents-signature and zipfile
`
`contents-signature technique is that certain different files in Kantor intentionally
`
`have the same contents signature. Indeed, Kantor even warns users of this:
`
`_ “Please be careful
`--~-~--~~N~N
`
`Please bear in mind that a zipfile which contains only one file
`
`will have a zipfile contents signature which is the same as the
`
`file contents signature of the single file which it contains; and a
`
`storage zipfile which has the same file contents as a
`
`16
`
`2020057
`
`

`

`Patent Owner’s Response (US. Pat. No. 7,945,539)
`
`IPR 2013~00085
`
`self_extracting zipfile will have the same zipfile contents
`
`signature.”
`
`(Kantor, 3.) See also Kantor at 51. Accordingly, for certain file categories, Kantor
`
`intentionally designed his contents-signatures so that certain different files would
`
`have the same signature. (Dewar Decl, 1] 44 [Ex. 2020].) This is because Kantor
`intentionally does not apply a hash function to parts ofZIP files containing file
`
`names, dates, compression ratios, order of appearance, zipped paths, comments,
`
`and headers — 'z'.e., because Kantor’s zipfile contents signatures are not based on all
`
`data of the zipfile. Id.
`
`Accordingly, Kantor warns users that at least three different files will by
`
`deslgn have; the. same: signature, (Dewar Deal, 1] 45 [Ex 2020]...) This would, of
`
`course, be repeated many times across a large