`571-272-7822
`
`Date: March 19, 2015
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`UNIFIED PATENTS, INC.,
`SAP AMERICA INC.,
`Petitioners,
`
`v.
`
`CLOUDING IP, LLC,
`Patent Owner.
`____________
`
`Case IPR2013-00586
`Case IPR2014-00306
`Patent 6,738,799 B2
`____________
`
`Before JAMESON LEE, JUSTIN BUSCH, and RAMA G. ELLURU,
`Administrative Patent Judges.
`
`BUSCH, Administrative Patent Judge.
`
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`I. BACKGROUND
`Unified Patents, Inc. (“Unified”) filed a Petition (Paper 1, “Pet.”)
`
`requesting inter partes review of claims 1, 5–10, 12, 16–21, 23, 24, 30, 31,
`
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`37, and 42 (the “challenged claims”) of U.S. Patent No. 6,738,799 B2 (“the
`’799 Patent”) under 35 U.S.C. §§ 311–319. On March 21, 2014, the Board
`instituted an inter partes review of the challenged claims on six asserted
`grounds of unpatentability (“Dec. on Inst.”). Paper 9. On December 27,
`2013, SAP America, Inc. (“SAP”) filed a petition (the “SAP Petition”),
`asserting the same grounds (against the same claims) as asserted by Unified
`in the Petition. On May 20, 2014, the Board instituted an inter partes review
`of the challenged claims and joined the review based on the SAP Petition
`with this inter partes review. Paper 17. Subsequent to institution and
`joinder of the two reviews, Clouding IP, LLC (“Patent Owner”) filed a
`Patent Owner Response (“PO Resp.”) responding to the petitions filed by
`Unified and SAP (collectively, “Petitioners”). Paper 18. Patent Owner also
`filed a Contingent Motion to Amend (“MTA” or “Mot. to Amend”). Paper
`19. Petitioners filed a Reply (Paper 22, “Pet. Reply”) to the Patent Owner
`Response and an Opposition (Paper 23, “Opp. MTA”) to the Contingent
`Motion to Amend. Patent Owner filed a Reply to Petitioners’ Opposition to
`the MTA (“PO Reply”). Paper 25. Oral hearing was held on October 16,
`2014.1
`
`The Board has jurisdiction under 35 U.S.C. § 6(c). This final written
`decision is issued pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73. For
`the reasons that follow, we determine that Petitioners have shown by a
`preponderance of the evidence that the challenged claims are unpatentable.
`Patent Owner’s Contingent Motion to Amend is denied.
`
`
`
`
`1 The record includes a transcript of the oral hearing (“Hr’g Tr.”). Paper 35.
`2
`
`
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`A. The ’799 Patent (Ex. 1001)
`The ’799 Patent is related to a method for file synchronization using a
`signature list. Ex. 1001, Title. In particular, the ’799 Patent discloses a
`method for synchronizing the local copies of files on client computers to the
`current versions of the files on a network drive. Ex. 1001, 1:24–27.
`According to the ’799 Patent, an object of the method is to provide a
`mechanism by which a user can be provided automatically with a current
`version of a subscription file in an efficient manner. Ex. 1001, 3:36–41.
`This is accomplished by having a server computer monitor network files for
`changes, and then send users email notifications and updates when there is a
`change to the files. Ex. 1001, 3:41–44.
`B. Illustrative Claim
`Of the challenged claims, claims 1, 12, 23, 30, 37, and 42 are
`independent claims. Claim 1 is similar to claim 23, with the exception that
`claim 1 includes an additional limitation (“wherein the new segment . . .”)
`not present in claim 23. Claims 1, 23, and 37 are method claims. Claims 12,
`30, and 42 are computer readable media versions of claims 1, 23, and 37,
`respectively. Thus, claims 1 and 37 are exemplary of the claimed subject
`matter, and are reproduced below (emphases added):
`
`3
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`
`1. A method for a first computer to generate an update
`for transmission to a second computer that permits the second
`computer to generate a copy of a current version of a file
`comprised of a first plurality of file segments from a copy of an
`earlier version of the file comprised of a second plurality of file
`segments, such that each file segment corresponds to a portion
`of its respective file, the method comprising the steps of:
`for each segment of the current version of the file,
`(a) searching an earlier version of a signature list
`corresponding to an earlier version of the file for an old
`segment signature which matches a new segment signature
`corresponding to the segment;
`(b) if step (a) results in a match, writing a command in
`the update for the second computer to copy an old segment of
`the second computer’s copy of the earlier version of the file into
`the second computer’s copy of the current version of the file,
`wherein the old segment corresponds to the segment for which
`a match was detected in step (a); and
`(c) if step (a) results in no match, writing a command in
`the update for the second computer to insert a new segment of
`the current version of the file into the second computer’s copy
`of the current version of the file;
`wherein the new segment of the current version of the
`file is written into the update and the unchanged segment is
`excluded from the update; and
`wherein steps (a) through (c) are performed by the first
`computer, without interaction with the second computer, in
`response to the first computer detecting a change between the
`current version of the file and the earlier version of the file.
`
`
`4
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`
`
`
`37. A method for a first computer to provide updates for
`transmission to a second computer that permits the second
`computer to obtain most recent versions of files, the method
`comprising the steps of:
`(a) determining whether the second computer has a latest
`version of a file, wherein said determining is performed by the
`first computer without interaction with the second computer;
`(b) generating an update, if the second computer does not
`have a latest version of the file, wherein said generating is
`performed by the first computer without interaction with the
`second computer; and
`
`(c) transmitting the update from the first computer to the
`second computer.
`
`
`
`C. Related Proceedings
`Petitioners indicate that the ’799 Patent was the subject of the
`following terminated inter partes reviews before the Board: Oracle Corp. v.
`Clouding IP, LLC, IPR2013-000732 and Oracle Corp. v. Clouding IP, LLC,
`IPR2013-00261. Pet. 4. Petitioners indicate that the ’799 Patent is the
`subject of the following co-pending federal district court cases: Clouding
`IP, LLC v. EMC Corp., et al., Case No. 1:13-cv-01455 (D. Del.); Clouding
`IP, LLC v. Dropbox Inc., Case No. 1:13-cv-01454 (D. Del.); Clouding IP,
`LLC v. SAP AG, et al., Case No. 1:13-cv-01456 (D. Del.); Clouding IP, LLC
`v. Verizon Inc., Case No. 1:13-cv-01458 (D. Del.); Clouding IP, LLC v.
`Rackspace, Hosting Inc., Case No. 1:12-cv-00675 (D. Del.); Clouding IP,
`LLC v. Amazon.com Inc., Case No. 1:12-cv-00641 (D. Del.); Clouding IP,
`LLC v. Oracle Corp., Case No. 1:12-cv-00642 (D. Del.); Clouding IP, LLC
`
`
`2 Petitioners identify IPR2012-00073 as a related matter. Pet. 4. However,
`IPR2013-00073 is the related inter partes review involving the ’799 Patent.
`5
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`v. Google Inc., Case No. 1:12-cv-00639 (D. Del.). Pet. 4. Petitioners
`indicate that the ’799 Patent also was the subject of the following terminated
`federal district court cases: Clouding IP, LLC v. Apple Inc., Case No. 1:12-
`cv-00638 (D. Del.); and Clouding IP, LLC v. Microsoft Corp., Case No.
`1:12-cv-00640 (D. Del.). Pet. 4.
`D. Asserted Grounds of Unpatentability
`The Board instituted inter partes review on the following asserted
`grounds of unpatentability under 35 U.S.C. §§ 102 and 103 (Dec. on Inst.
`29–30):
`
`References
`Williams3
`Williams and Miller4
`Balcha5
`
`Balcha and Miller
`
`Balcha, Miller, and Freivald6
`Balcha and Freivald
`
`
`
`Basis
`§ 102(e)
`§ 103(a)
`§ 102(e)
`
`§ 103(a)
`
`§ 103(a)
`§ 103(a)
`
`Challenged Claim(s)
`1, 12, 23, 24, 30, 31, 37, and 42
`5–10 and 16–21
`37 and 42
`1, 5, 9, 10, 12, 16, 20, 21, 23,
`24, 30, and 31
`6–8 and 17–19
`37 and 42
`
`II. ANALYSIS
`
`A. Claim Construction
`The Board interprets claims of an unexpired patent using the broadest
`reasonable construction in light of the specification of the patent. 37 C.F.R.
`
`
`3 U.S. Patent No. 5,990,810, issued Nov. 23, 1999 (Ex. 1006) (“Williams”).
`4 U.S. Patent No. 5,832,520, issued Nov. 3, 1998 (Ex. 1004) (“Miller”).
`5 U.S. Patent No. 6,233,589 B1, issued May 15, 2001 (Ex. 1003) (“Balcha”).
`6 U.S. Patent No. 5,898,836, issued Apr. 27, 1999 (Ex. 1005) (“Freivald”).
`6
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`§ 42.100(b); see Office Patent Trial Practice Guide, 77 Fed. Reg. 48,756,
`48,766 (Aug. 14, 2012). Claims are to be given their broadest reasonable
`interpretation consistent with the specification, reading the claim in light of
`the specification as it would be interpreted by one of ordinary skill in the art.
`In re Am. Acad. of Sci. Tech. Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004).
`Although the parties argue other terms, for purposes of this decision,
`we find it necessary to construe explicitly only “update,” “writing a
`command . . . to copy,” and “determining whether the second computer has a
`latest version of a file, wherein said determining is performed by the first
`computer without interaction with the second computer.” We provide the
`bases for the construction of each of the explicitly construed terms below.
`1.
` “update”
`Petitioners propose construing “update” as “information for updating
`a file or an up-to-date version of a file.” Pet. 15 (citing Ex. 1010, 10).
`Patent Owner does not propose a construction for “update” in its Patent
`Owner Response.
`The claim term “update” has the following dictionary definition:
`“current information for updating something” or “an up-to-date version,
`account, or report.”7 We do not find an explicit definition in the
`Specification of the ’799 Patent for an update, nor do we find anything in the
`Specification inconsistent with a construction encompassing an up-to-date
`version of a file. Therefore, in the context of file synchronization, we
`construe the claim term “update” broadly, but reasonably, as information for
`updating a file or an up-to-date version of a file.
`
`7 MERRIAM-WEBSTER DICTIONARY, http://www.merriam-
`webster.com/dictionary/update (last visited Feb. 11, 2014) (emphasis added).
`7
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`
`
`
`“writing a command . . . to copy”
`2.
`Each of claims 1, 12, 23, and 30 recites the following claim phrase:
`“writing a command in the update for the second computer to copy an old
`segment of the second computer’s copy of the earlier version of the file into
`the second computer’s copy of the current version of the file.” Ex. 1001,
`claims 1, 12, 23, 30 (emphasis added). Hereinafter, we refer to this claim
`phrase as “writing a command . . . to copy.”
`Petitioners propose construing “a command to copy” as “an
`instruction that causes the computer to duplicate information or data.” Pet.
`15 (citing Ex. 1010, 11). Patent Owner asserts a “plain meaning reading of
`[the writing a command . . . to copy phrase] demands that a command to
`copy be written in the update that is used by the second computer to generate
`a copy of the current version of the file.” PO Resp. 10.
`We note that the recited “writing a command . . . to copy” language
`merely requires that a command, which causes the second computer to copy
`a portion of an earlier version of a file into a current version of the file, be
`written in the update. The claim does not limit the command to a specific
`format. Therefore, we broadly, but reasonably, construe “writing a
`command . . . to copy” as inserting an instruction into the update that causes
`the second computer to duplicate information or data from an earlier version
`of a file into a current version of a file.
`3.
`“determining whether the second computer has a latest
`version of a file, wherein said determining is performed
`by the first computer without interaction with the second
`computer”
`Neither Petitioners nor Patent Owner have proposed explicitly a
`construction of “determining whether the second computer has a latest
`8
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`version of a file, wherein said determining is performed by the first
`computer without interaction with the second computer” (the “determining
`limitation”). We find the language of the determining limitation is
`sufficiently clear that the plain and ordinary meaning is the proper
`construction. Nevertheless, because the determining limitation is central to
`the disputes in this proceeding, we address two key components of the
`determining limitation to explain how an ordinarily skilled artisan would
`have understood the determining limitation when read in the context of the
`Specification of the ’799 Patent at the time of invention. In particular, we
`will discuss how an ordinarily skilled artisan would have understood what
`the latest version of a file is, and what it means for the determination to be
`“performed by the first computer without interaction with the second
`computer.”
`Patent Owner appears to argue that the determining limitation requires
`the first computer to be absolutely certain that the version on the second
`computer is not the most recent version of the file. See, e.g., PO Resp. 7–8
`(arguing that claims 37 and 42 do not allow for the possibility that a more
`recent file would be overwritten by an older file), 38 (distinguishing prior art
`where “computer E1 cannot be certain whether or not computer E2 stores a
`latest version of the subject file”).
`In its arguments against Petitioners’ challenges, Patent Owner
`provides examples of how uncertainty could occur in the prior art. See, e.g.,
`PO Resp. 7 (“Balcha only discloses detecting whether a base file has been
`modified, regardless of when that modification may have occurred relative
`to other copies of the same base file”), 25 (“Freivald is unconcerned with
`
`9
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`whether or not a subscribed client has a latest version of a Web page (or any
`version at all for that matter), and sends notifications whenever qualifying
`changes in a Web page have been detected, regardless of whether the
`modifications reflect the latest version of the file or not”), 38 (“Williams is
`both anticipating and accommodating situations in which computer E2 may
`store a different, but not necessarily a latest, version of a file than computer
`E1”). Patent Owner asserts inappropriate file updating is avoided in claims
`37 and 42 “by determining whether the second computer has a latest version
`of a file and, in this way, establishes that the latest version of the file will not
`be overwritten by changes to a file that occurred previously to the changes of
`the latest version of the base file simply because the files are not the same
`(i.e., one of the files has been modified).” PO Resp. 8. Patent Owner cites
`to Dr. Mohaptra’s Declaration8, which uses the exact same language and
`provides no further explanation as to why the determining limitation should
`be construed to prevent the inappropriate file updating that is allegedly an
`issue only in the prior art. Ex. 2009 ¶ 17.
`Petitioners explain that there is nothing in the’799 Patent that prevents
`a copy of a subject file from being updated on a client, but that an ordinarily
`skilled artisan would have understood that the system was not intended to
`operate in that way. Hr’g Tr. 7:23–8:10. Petitioners further argue that
`claims 37 and 42 recite the determining is done “without interaction with the
`client[/second computer].” Id. at 8:16–18. Moreover, Petitioners explain
`that the ’799 Patent describes the process of the determining limitation
`
`
`8 Dr. Prasant Mohaptra is Patent Owner’s declarant, whose Declaration was
`submitted as Exhibit 2009.
`
`10
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`assuming that the system is operated normally, and that the server can use
`traditional mechanisms (e.g., comparing time stamps) to determine whether
`the second computer has a current version of the file. Id. at 8:16–24. Thus,
`Petitioners implicitly assert that a person having ordinary skill in the art
`would not have understood the determining limitation, which requires the
`determining to be done without interaction with the second computer, to
`require an absolute certainty that the second computer have the latest
`version. Id. at 8:16–13:20. Rather, Petitioners implicitly assert that the
`proper construction of the determining limitation is that the first computer,
`assuming normal operation of the system and using techniques known to
`those of ordinary skill in the art, detects whether there is a difference
`between a current version and an old version of the file at the first computer,
`and updates the second computer if there is a difference. Id.
`With respect to the latest version, a review of the Specification of the
`’799 Patent reveals only one occurrence of the term “latest.” Ex. 1001,
`13:12–14 (“For the next file change, the server will take yet another
`snapshot and compare it against the latest snapshot and so on.”). The ’799
`Patent does, however, consistently refer to updating an old version of a file
`to a current version of a file.
`Although Patent Owner asserts that claims 37 and 42 would not allow
`a newer file to be overwritten by an older file (PO Resp. 7–8), Patent Owner
`does not point to evidence sufficient to support such a restriction. Patent
`Owner does not explain how the recited language requires an
`implementation that prevents issues with transit delays, tampering, or other
`uncertainties with respect to the first computer’s most recent version not
`
`11
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`being as recent as another version of the file. Patent Owner simply points to
`the recited language as the explanation for why claims 37 and 42 do not
`suffer from the same problems as the prior art.
`The closest Patent Owner comes to providing support for its proposed
`construction is its argument, without citation to supporting evidence, that
`claims 37 and 42 use the timestamp of when a change was made (rather than
`when the server received the change) to determine the latest version. Hr’g
`Tr. 29:15–31:13. Patent Owner explains that, even when using the
`timestamp of when a change was made, the server relies “upon a comparison
`of its own time stamps” because “the server does not have the time stamps
`for the client computer.” Hr’g Tr. at 19:12–17 (emphasis added).
`Nevertheless, even accepting the argument that the server uses the
`timestamp of when a change was made, as opposed to received, by the
`server, there are two issues. First, in the example provided by Patent Owner,
`the first computer may receive a second update (where the change was made
`later) prior to receiving a first update (where the change was made earlier)
`due to network latency. Id. at 30:4–9, 30:21–31:9. There is no disclosure in
`the ’799 Patent indicating that an evaluation made by the first computer, in
`the time between receiving the first and second updates, would result in a
`determination that the second update was the latest version. This is
`inconsistent with Patent Owner’s position that the server is always using the
`latest change to provide an update. Second, regardless of when updates are
`made, there is no recited restriction on how the first computer determines
`what version is the current or latest version.
`
`12
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`
`
`
`There are various references throughout the ’799 Patent that discuss
`the first computer, or server, determining whether an update file needs to be
`sent to the second, or client, computer(s). See, e.g., Ex. 1001, Abstract
`(“The server periodically monitors the subscription file to determine if it has
`been altered before generating an update file”), 4:32–34 (“The update file is
`only generated when the server computer determines that the subscription
`file has changed . . . [t]he user determines the periodicity of the checks to
`determine if the file has been altered”), 6:51–55 (“the user then determines
`the polling or monitoring interval for the server to check for changes and
`also what to do when changes occur, i.e., package and send file changes or
`simple notification”). The ’799 Patent also discloses that the server
`periodically monitors files or folders to which clients subscribe for changes
`in order to determine whether an update needs to be generated. See, e.g., id.
`at 3:41–44, 4:32–39, 7:56–57, 9:28–31. One example provided in the ’799
`Patent is that the server “polls files or subfolders at either [sic] user-defined
`intervals for any changes to date, time stamps.” Id. at 6:59–60. Each of
`these descriptions explains that the server (the first computer) makes a
`determination without comparing the subject file (or its timestamp) to the
`version of the file stored at the client (the second computer) (or its
`timestamp).
`In light of the considerations discussed above, we do not see anything
`that would lead us to conclude that the proper construction of the
`determining limitation requires absolutely certainty. From the perspective of
`the first computer, the latest version, as recited in claims 37 and 42, refers to
`the current version accessible by the first computer, as determined by the
`
`13
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`first computer at the time a check is made. Thus, at the point in time when
`the first computer makes its determination, the first computer merely needs
`to determine whether it has already sent its current version to the second
`computer. Considering all of the above, an ordinarily skilled artisan would
`have understood the plain and ordinary meaning of the “determining
`limitation” to be determining, by the first computer using known techniques
`based on information it has access to and without interaction with the second
`computer, whether the last version of the subject file sent to the second
`computer is not the same as the current version of the subject file.
`B. Submitted Evidence
`1. Williams (Ex. 1006)
`Williams describes a fine-grained incremental backup system and
`process. Ex. 1006, 19:26–22:14. Figure 25 of Williams is reproduced
`below:
`
`
`Figure 25 of Williams illustrates the backup process for two network
`computers.
`Williams describes that a file on computer E1 is backed up to
`computer E2, such that both E1 and E2 have a copy of the same version of
`the file, referred to as Y. When the file is modified, computer E1 now has a
`14
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`new (current) version of the file, referred to as X. As shown in Figure 25 of
`Williams, at that time each of the network computers (E1 and E2) has a
`version of the same file (X and Y, respectively). Williams then determines
`the information to send from computer E1 to E2 necessary for E2 to generate
`a copy of X and sends that incremental backup information in a file, referred
`to as D, from computer E1 to computer E2. Computer E2 subsequently may
`generate a copy of the current version of the file, X, by using its prior
`version of the file, Y, and the incremental backup information file, D. Ex.
`1006, 19:29–34, 19:63–20:2.
`For further improvement, Williams indicates that copies of the
`previous versions of the file system should be retained. Ex. 1006, 21:62–65.
`This means that computer E2 should maintain both versions of the file, Y
`(the previous version) and X (the current version) when generating the
`current version. Id. Therefore, computer E2 eventually may store every
`prior version of that file.
`
`As explained in Williams, computer E1 compares the hash of the old
`version of the file, Y, against the hash of current version of the file, X, to
`determine whether the file has changed. Ex. 1006, 19:44–46. If the file has
`changed, computer E1 partitions the current version of the file into
`subblocks, and compares the hashes of these subblocks with the hashes of
`previous version of the file that are stored in shadow file S of computer E1,
`to find all identical hashes. Ex. 1006, 19:48–51. “Identical hashes identify
`identical subblocks in [version] Y that can be transmitted by reference.”
`Ex. 1006, 19:51–52. Computer E1 then transmits the incremental backup
`file D as a mixture of raw subblocks and references to subblocks whose
`
`15
`
`
`
`
`
`
`file, D, coomputer E22
`
`
`
`IPR22013-00586
`
`
`IPR22014-003006
`
`
`Patennt 6,738,7999 B2
`
`
`
`
`
`
`
`hashhes appear in the shaddow file S and whichh are knownn to appearr as
`
`
`
`
`
`
`subbblocks in thhe prior verrsion of the file, Y. EEx. 1006,
`19:52–55.
`X, from
`
`
`
`
`
`To reconnstruct a duuplicate off the currennt version oof the file,
`
`
`
`
`
`
`
`the pprior versioon of the fiile, Y, and incrementtal backup
`
`
`
`
`
`partiitions Y intto subblocks and calcculates thee hashes off subblockss. Ex.
`
`
`
`
`10066, 19:66–200:1. “It th
`
`
`
`
`en processses the incrremental baackup infoormation,
`
`
`
`
`
`copyying subbloocks that wwere transmmitted raw
`
`and lookinng up the r
`
`
`in Y. Ex. 10066, 20:2–5.
`
`
`2. Miller (EEx. 1004)
`Miller d
`
`
`
`
`method annd system ffor using ssmall differrence
`escribes a
`:11–13.
`
`
`
`
`
`
`(“difff”) files too update orr revise largge computter files. EEx. 1004, 1
`the large
`
`
`
`
`
`
`The diff files aare small fiiles that inddicate the ddifferencess between
`
`
`
`compputer files and preexisting commputer filess. Id. at 1:113–15. Figgure 1 of
`
`
`
`
`
`
`
`
`Miller, reproduuced beloww, illustratees how the
`
`process wworks.
`
`eferences””
`
`
`16
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`Figure 1 of Miller illustrates the process of generating a diff file at a first
`computer system by identifying differences between an old file and a new
`file, communicating the diff file to the second computer system over a
`communication path, and generating a copy of the new file at a second
`location using the diff file and a copy of the old file present at the second
`location.
`Miller’s diff file indicates changes between the old file and the new
`file using a minimal number of bytes. Id. at 2:21–24, 31–33. Miller’s diff
`file is comprised of copy and insert commands. Id. at 13:24–30. Miller’s
`first computer system then communicates the diff file to the second
`computer system, using any means for communicating between computer
`systems, including e-mail. Id. at 5:10–17. The second computer system
`then generates a new file, either when invoked explicitly or through receipt
`of a self-extracting execution file, copying segments from its copy of the old
`file and segments from the diff file. Id. at 15:25–43.
`3. Balcha (Ex. 1003)
`Balcha discloses a method for synchronization of files. Ex. 1003,
`1:5–7. In particular, a synchronized file exists on two different servers, and
`changes made to one file must be reflected in the other file. Ex. 1003, 1:42–
`44. Figure 1 of Balcha, reproduced below, illustrates a computer network
`with two servers using file synchronization.
`
`
`
`17
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`
`
`
`As shown in Figure 1 of Balcha, servers (22 & 24) are interconnected
`via a network 26, and each server (22 & 24) maintains a copy of a base file
`(21 & 27) and a base signature file (20 & 28). Ex. 1003, 4:51–53. The base
`files (21 & 27) should be identical, but either base file can be modified at
`either server. Ex. 1003, 4:53–61. Upon detection of a modification to the
`file, the detecting server (e.g., server 22), uses the respective base signature
`file (e.g., base signature file 20) to generate a new delta file, and
`communicates the delta file over network 26 to server 24. Ex. 1003, 4:61–
`66 (emphasis added). Server 24 uses the delta file to update the base file 27,
`and recalculates the base signature file 28. Ex. 1003, 4:66–67. As a
`consequence, the base files on the servers will stay in synchronization with
`minimal transfer of data over network 26. Ex. 1003, 5:1–3.
`Figure 3 of Balcha is reproduced below:
`
`
`
`Figure 3 of Balcha illustrates the relationship of the files.
`Referring to Figure 3 of Balcha, the base signature file (42) contains a
`plurality of cyclic redundancy check (CRC) values derived from the data
`contained in the base file (38). Ex. 1003, 3:1–3, 3:21–28, 7:46–49. When a
`revised version of the base file (44) is created, a revised signature file (48),
`including a plurality of revised bit patterns, is generated from the revised file
`
`18
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`(44). Ex. 1003, 3:4–6, 7:49–53. “Each revised bit pattern is compared to
`the base bit patterns in base signature file 42.” Ex. 1003, 7:57–59
`(emphasis added). “For each revised bit pattern that matches a base bit
`pattern in base signature file 42, it is stored in revised signature file 48,
`along with an offset indicating the location in revised file 44 of the
`beginning of the block of data represented by the revised bit pattern.”
`Ex. 1003, 7:59–63.
`Based on the differences between the base signature file and the
`revised signature file, a delta file reflecting the differences between the base
`file and the revised file is generated. Ex. 1003, 3:7–10, 3:50–54. The delta
`file contains primitives, such as insert, modify, and delete primitives, which
`are commands that can be applied to a previous version of the file to
`generate the revised file. Ex. 1003, 3:54–58.
`4. Freivald (Ex. 1005)
`Freivald describes a change-detection web server that automatically
`checks pages for changes. Ex. 1005, Abstract. Freivald discloses a
`subscription service in which users that wish to be notified of changes to
`Web pages or portions thereof may register those pages. Id. at 7:3–15. An
`associated subscription server, referred to as a minder, periodically checks to
`see if the registered pages have changed and, upon detecting changes,
`notifies the user by sending an email. Id. at 5:18–43.
`5. Update/Synchronization Schemes
`Both parties agree that retain-by-default and discard-by-default are the
`two schemes used in file synchronization or file backup. See, e.g., Pet. 51;
`Ex. 1007 ¶¶ 22–27, 46–48; Hr’g Tr. 17:11–18:4. Briefly, retain-by-default
`
`19
`
`
`
`
`
`
`IPR2013-00586
`IPR2014-00306
`Patent 6,738,799 B2
`
`
`indicates that, when generating a new version of the file, each portion of the
`old version of the file is kept unless the update explicitly indicates removing
`that portion. Conversely, discard-by-default indicates that, when generating
`a new version of a file, each portion of the old version of the file is discarded
`unless the update explicitly indicates keeping that portion. See Ex. 1007, ¶¶
`22–27.
`Although the specific commands inserted into an update file by the
`first computer differ, the operations executed by the second computer upon
`receipt of the update file are the same. Id. ¶¶ 22, 26, 46. Put another way,
`the schemes merely differ in whether the identified blocks are those to be
`kept or those to be discarded, whereas the actual instructions executed at the
`second computer depend on the goal that the second computer is
`programmed to accomplish, not the commands inserted into the update file.
`Id.
`
`In particular, if the second computer is programmed to generate a new
`backup file upon receipt of an incremental update file (retaining the prior
`version backup file), the second computer will interpret the insert
`instructions in the update file to copy the new sections from the update file
`into the new backup file. Id. ¶¶ 25, 37. If the update file uses copy
`commands (discard-by-default scheme), the second computer will interpret
`copy commands in the update file such that the second computer will copy
`the identified sections from the prior version of the backup fi