`571.272.7822
`
`
`
`
`
`
`
` Paper No. 50
`
` Filed: July 29, 2014
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`VEEAM SOFTWARE CORPORATION,
`Petitioner,
`
`v.
`
`SYMANTEC CORPORATION,
`Patent Owner.
`____________
`
`Case IPR2013-00141
`Patent 6,931,558 B1
`____________
`
`
`Before MEREDITH C. PETRAVICK, THOMAS L. GIANNETTI, and
`TRENTON A. WARD, Administrative Patent Judges.
`
`PETRAVICK, Administrative Patent Judge.
`
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`I. BACKGROUND
`Veeam Software Corporation (“Petitioner”) filed a Petition for inter
`partes review of claims 1–15 of U.S. Patent 6,931, 558 B1 (“the ’558
`patent”) pursuant to 35 U.S.C. §§ 311–319 and 37 C.F.R. §§ 42.1–42.123.
`(Paper 5, “Pet.”). Symantec Corporation (“Patent Owner”) filed a Patent
`Owner Preliminary Response. Paper 9 (“Prelim. Resp.”). Taking into
`account Patent Owner’s Preliminary Response, we determined that there is a
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`reasonable likelihood that the challenged claims are unpatentable. Pursuant
`to 35 U.S.C. § 314, we instituted inter partes review, on August 7, 2013, as
`to claims 1–15 of the ’558 patent. Paper 11 (“Dec.”).
`After institution, Patent Owner filed a Patent Owner Response (Paper
`22, “PO Resp.”) and a contingent Motion to Amend (Paper 23, “Mot. to
`Amend”). Petitioner filed a Reply to the Patent Owner Response. Paper 27
`(“Pet. Reply”). A hearing was held on May 5, 2014, a transcript of which
`appears in the record. Record of Oral Hearing, Paper 49 (“Tr.”).
`
`We have jurisdiction under 35 U.S.C. § 6(c). This decision is a final
`written decision under 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73 as to the
`patentability of the challenged claims. For the reasons discussed below, we
`determine that Petitioner has shown by a preponderance of the evidence that
`claims 1–15 are unpatentable.
`
`
`A. Related Proceedings
`In addition to this proceeding, Petitioner filed a Petition for inter
`
`partes review challenging the patentability of claims 16–23 of the ’558
`patent. See IPR2013-00142, Paper 6. In that proceeding, we instituted inter
`partes review as to claims 17–23 of the ’558 patent. IPR2013-00142, Paper
`11. Further, we instituted inter partes review based on Petitioner’s
`challenges to the patentability of certain claims of Patent Owner’s U.S.
`Patents 7,093,086 (IPR2013-00150) and 7,191,299 (IPR2013-00143). Our
`final decisions in these proceedings are being entered concurrently with this
`decision.
`
`
`
`2
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`The parties indicate that the ’558 patent is involved in a case in the
`
`U.S. District Court for the Northern District of California, Symantec Corp. v.
`Veeam Software Corp. (No. 3:12-cv-00700). Pet. 1; Paper 8, 2.
`
`
`B. The ’558 Patent (Ex. 1001)
`The ’558 patent is titled “Computer Restoration Systems and
`
`Methods” and generally relates to local and wide area interconnected
`computers and data communications networks. More particularly, the patent
`relates to restoration of computer systems backed up on storage managers,
`such as in a network, upon a “crash” or other similar event that prohibits
`normal “boot[-]up” operation. Ex. 1001, col. 1, ll. 10–15.
`
`The ’558 patent explains that the client computer has access to a
`storage manager application, such as a server computer of the network
`operating a storage management software program. Id. at Abstract. All
`client files, including configuration files, as well as application and data
`files, of the client device are saved on the network by the storage manager
`application. Id.
`
`The client device is booted over the network, rather than locally to the
`client device by a boot disk or otherwise. Id. The boot program is loaded to
`the client device, and the client device retrieves configuration and file
`information over the network from the storage manager application. Id.
`The client device configures its disk according to the configuration
`information. Id. All other files and data of the client device at the time a
`failure of the client device are saved on the disk substantially in condition
`and state just prior to the failure and as most recently backed up to the
`storage manager application. Id.
`
`
`
`3
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`
`
`Figure 3 of the ’558 patent is reproduced below:
`
`
`Figure 3 illustrates server computer 104 having server components 300,
`including restore server 302, boot server 304, file server 306, and storage
`manager 308. Id. at col. 3, ll. 32–35; col. 5, ll. 10–15. The restore server
`shown in the Figure above, and described in the text of the patent, is known
`as a bare metal restore (“BMR”) server. Id. at col. 5, ll. 11–12.
`
`
`C. Illustrative Claims
`Independent claims 1, 2, and 11 of the ’558 patent are illustrative of
`the claims at issue:
`1. A device restoration system, for restoring a client device to a
`state prior to a major failure, comprising:
`a server device;
`a network communicatively interconnecting the client
`device and the server device;
`a storage manager accessible to the server device for
`saving the state, wherein the state includes client disk
`configuration information; and
`
`
`
`4
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`
`a network boot in which the server device causes the
`client device to boot.
`
`2. A method of restoring a client device of a network on failure
`of the client device, wherein the network includes a server
`computer, comprising the steps of:
`
`booting the client device via a network boot;
`creating a boot program for operation on the client
`device;
`configuring the client device according to the boot
`program and a saved configuration state including client disk
`configuration information;
`copying a file to the client device in accordance with a
`configuration from the step of configuring.
`
`11. A method of restoring a client device of a network, the
`network including a server device having a storage manager
`application, comprising the steps of:
`backing up configuration data including client disk
`configuration information, as well as application and data files,
`by the storage manager application; and
`restoring the backed up configuration data, as well as
`application and data files, from the step of backing up, to the
`client device over the network.
`
`
`
`D. Grounds of Unpatentability
`We instituted inter partes review of the ’558 patent based upon the
`
`following asserted grounds of unpatentability:
`1. Claims 1–15 are anticipated under 35 U.S.C. § 102 by BMR User
`Guide1;
`
`1 THE KERNEL GROUP, Bare Metal Restore User Guide For Tivoli Store
`Manager: Version 1.4.3 1–142 (2001) (Ex. 1003).
`5
`
`
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`
`2. Claims 1–15 are anticipated under 35 U.S.C. § 102 by BMR
`Webpages2; and
`3. Claims 11 and 14 are anticipated under 35 U.S.C. § 102 by
`Deshayes3.
`Dec. 17.
`
`
`II. DISCUSSION
`A. Claim Construction
`We begin our analysis by determining the meaning of the claims. In
`
`an inter partes review, claim terms in an unexpired patent are given their
`broadest reasonable construction in light of the specification of the patent in
`which they appear. 37 C.F.R. § 42.100(b). Under the broadest reasonable
`construction standard, claim terms are given their ordinary and customary
`meaning as would be understood by one of ordinary skill in the art in the
`context of the entire disclosure. In re Translogic Tech., Inc., 504 F.3d 1249,
`1257 (Fed. Cir. 2007).
`i. Client Disk Configuration Information
`We determined that the broadest reasonable interpretation of “client
`
`disk configuration information” is “information regarding disk partitions,
`volume groups, logical volumes, and/or file systems.” Dec. 7. The broadest
`reasonable interpretation of “client disk configuration information” was
`
`2 THE KERNEL GROUP, Bare Metal Restore User’s Guide: Version 1.1 for
`AIX (May 2000),
`www.web.archive.org/web/20000831083617/http:/www.tkg.com/bmr/docs/
`white.html (last visited Aug. 31, 2000); THE KERNEL GROUP, Disaster
`Recovery and the Tivoli Storage Manager: How Bare Metal Restore Fills
`the Gap (May 2000)
`www.web.archive.org/web/20000831083617/http:/www.tkg.com/bmr/docs/
`white.html (last visited Aug. 31, 2000) (Ex. 1002).
`3 Deshayes, U.S. Patent No. 6,047,294 (Apr. 4, 2000) (Ex. 1005).
`6
`
`
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`proposed by Petitioner (Pet. 7) and adopted by us in the Decision on
`Institution (Dec. 7). Patent Owner maintains that the adopted interpretation
`is improper for the reason set forth in its Preliminary Response (see Prelim.
`Resp. 4–5; see also Dec. 7 (determining that Patent Owner’s argument
`regarding an alleged lexicographic definition of client disk configuration
`data was unpersuasive)), but accepts the Board’s interpretation for the
`purposes of the Patent Owner Response. PO Resp. 3.
`ii. Program
`Patent Owner argues that a computer program is distinct from a
`
`computer script. PO Resp. 19; see Ex. 2011 ¶¶ 60–62 (Testimony of Dr.
`Levy, Patent Owner’s expert, that a script is not equivalent to a program).
`Patent Owner argues that a program is “a sequence of instructions intended
`for execution by a processor, such as a CPU,” while a script is “a sequence
`of commands stored in a file.” Id. According to Patent Owner, a program is
`distinct from a script because a program can be executed directly by a
`processor and a script requires an intervening program. Id. Petitioner
`disputes Patent Owner’s distinction and argues that “[a] script is merely
`another word for a software program that is executed by the computer.”
`Pet. Reply 10–11 (citing Ex. 1007 ¶ 40).
`The ’558 patent does not set forth a lexicographic definition of
`program. See Ex. 1001. We, thus, give the term “program” its ordinary and
`customary meaning as would be understood by one of ordinary skill in the
`art in the context of the entire disclosure. A definition of program is “[a]
`sequence of instructions that can be executed by a computer. The term can
`refer to the original source code or to the executable (machine language)
`version.” MICROSOFT COMPUTER DICTIONARY FIFTH EDITION 424 (2002) (Ex.
`
`
`
`7
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`3001). In contradiction to Patent Owner’s argument, this definition does not
`preclude a program from requiring an intervening program for execution,
`and states that source code, which may require an intervening program for
`execution, can be referred to as a program. Further, we see nothing in the
`disclosure of the ’558 patent that precludes a program from encompassing a
`script. For these reasons, we determine that the broadest reasonable
`interpretation of the term “program” encompasses a script.
`
`
`B. Grounds Based on BMR User Guide (Ex. 1003)
`Petitioner argues that claims 1–15 are anticipated by BMR User
`Guide. Pet. 24–29; Pet. Reply 2–14. “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., Inc.
`v. Union Oil Co. of Cal., 814 F.2d 628, 631 (Fed. Cir. 1987). For the
`reasons discussed below, we determine that Petitioner has demonstrated by a
`preponderance of the evidence that claims 1–15 are anticipated by BMR
`User Guide.
`
`i. BMR User Guide
`As described in BMR User Guide, the BMR product allows a client
`machine to be restored completely from the data saved in an enterprise
`storage management server (“ESM”), without requiring separate system
`backups or reinstalls. Ex. 1003, 1. In the event that the client loses a boot
`disk or suffers some other catastrophic failure, BMR can be used to restore
`the machine to the state at which it was backed up last to the ESM. Id.
`BMR is integrated into ESM, providing the disaster recovery feature that the
`ESM lacks. Id.
`
`
`
`8
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`
`The Figure on page 3 of BMR User Guide, reproduced below, depicts
`the BMR product.
`
`
`The Figure depicts a BMR server, connected to a boot server, a file server,
`and an ESM server. Ex. 1003, 3. The boot server, file server, and ESM
`server are connected to a restore client. Id. The Figure depicts that the boot
`server transmits the boot image to the restore client; the file server transmits
`“OS, BMR, & ESM files needed at restore time” to the restore client; and
`the ESM server transmits all backed-up client files to the restore client. Id.
`
`BMR User Guide describes a client restoration process that is “highly
`automated” and includes the following ten steps:
`1. The user tells the BMR server to prepare to restore the
`client.
`2. The BMR server retrieves the UNIX client’s configuration
`data from the ESM server. NT clients retrieve the client
`configuration file from the ESM server and to control re–
`configuration.
`
`
`
`9
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`
`3. The BMR server creates a customized client boot script and
`makes the appropriate boot image and filesystems available
`to the client.
`4. The client boots from the boot server and starts running its
`customized boot script.
`5. The client mounts the necessary filesystems from the file
`server or SAMBA server.
`6. The client configures its disks, logical volumes, filesystems,
`etc.
`7. The client uses the standard ESM client to restore all its files
`from the ESM server, including the operating system,
`applications, configuration data, and user files.
`8. The client configures its boot record and configuration
`database.
`9. The client reboots itself.
`10. The client performs post-boot cleanup.
`Ex. 1003, 4.
`ii. Independent Claims 1, 2, and 11 and Dependent Claims 4, 10, and 13
`Patent Owner argues that BMR User Guide does not anticipate these
`claims because BMR User Guide does not disclose the claimed 1) client disk
`configuration data, 2) boot program, and 3) network boot caused by the
`server device. PO Resp. 10–21. We will address each of these disputed
`limitations in turn.
`
`a. Client Disk Configuration Information
`Independent claim 1 recites, “a storage manager . . . for saving the
`state, wherein the state includes client disk configuration information.”
`Independent claim 2 recites, “configuring the client device according to . . . a
`saved configuration state including client disk configuration information.”
`Independent claim 11 recites, “backing up configuration data including
`client disk configuration information” and “restoring the backed up
`configuration data.”
`
`
`
`10
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`
`Petitioner points to step 6 “client configures its disks, logical volumes,
`filesystems, etc.[,]” of BMR User Guide’s restoration process as meeting the
`claimed client disk configuration information. Pet. 26–27. Petitioner,
`further, points to BMR User Guide’s disclosure of backing up the state of
`the machine configuration prior to a failure. Id. at 27–28. Petitioner argues
`that, given these disclosures, one of ordinary skill in the art would have
`understood that the saved client configuration data includes client disk
`configuration information, because in order for the client to be recovered
`completely, the saved client configuration must include the client disk
`configuration information. Id. at 26–28; Pet. Reply 6–10; see also Ex. 1007
`¶ 39; Ex. 1013 ¶¶ 11–14 (supporting testimony of Petitioner’s expert, Dr.
`Prashant Shenoy).
`Patent Owner argues that, although BMR User Guide discloses that
`the state of the machine configuration information is saved and discloses,
`separately, a client configuring its disks, logical volume, and file system,
`BMR User Guide fails to disclose, explicitly, that the saved state of the
`machine configuration includes the client disk configuration information.
`PO Resp. 11–17; see also Ex. 2011 ¶¶ 39–46 (supporting testimony of
`Patent Owner’s expert Dr. John Levy). Patent Owner argues that BMR User
`Guide is vague as to where the information used to configure the client’s
`disks, logical volume, and filesystem is stored. See id.
`We are not persuaded by Patent Owner’s argument. BMR User Guide
`discloses a ten step “highly automated” restoration process in which a client
`device is restored after a failure. Ex. 1003, 4. Step 6 of the BMR User
`Guide’s restoration process states “[t]he client configures its disks, logical
`volumes, filesystems, etc.” Id. In order to configure disks, logical volumes,
`
`
`
`11
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`and filesystems during a highly automated restoration process, the client
`must obtain information regarding disks, logical volumes, and filesystems
`(i.e., client disk configuration information) from some previously saved file.
`See Tr. 76 (in response to a question from the panel at the oral hearing,
`counsel for Patent Owner agreed that the information the client would use to
`configure the disks “has to come from some sort of file”). BMR User Guide
`discloses that “all files (including system files) must be backed up to the
`ESM server” and that “BMR also saves the client’s configuration at backup
`time so that an up-to-date snapshot of the machine configuration is always
`saved with the system’s data.” Ex. 1003, 2 (emphases added); see also id. at
`5 (“[i]t is important that every backup captures a complete snapshot of the
`system because BMR restores the machine to the state at which it was last
`backed up”) (emphasis added). BMR User Guide further, discloses:
`Bare Metal Restore (BMR) allows a machine to be completely
`restored from the data that is saved in an Enterprise Storage
`Manager (ESM), without requiring separate system backups or
`reinstalls. . . . Bare Metal Restore can be used to restore the
`machine to the state at which it was last backed up to an ESM
`. . . .
`When you use BMR, your clients are backed up normally to
`their ESM server(s). The only differences are that all of the
`clients’ files are backed up and a program is automatically run
`before the backup is performed to save the state of the machine
`configuration. This information allows BMR to completely
`recover a machine from just the ESM backup.
`Id. at 1 (emphases added). Given these disclosures, we agree with
`Petitioner’s expert Dr. Shenoy that the client disk configuration information
`must have been saved as part of the configuration information during the
`backup. Ex. 1007 ¶ 39.
`
`
`
`12
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`
`For the reasons given above, we determine that BMR User Guide
`discloses that information for configuring disks, logical volumes, and
`filesystems (i.e., client disk configuration information) is saved with the
`configuration information on the ESM.
`b. Boot Program
`Claim 2 recites “configuring the client device according to the boot
`program and a saved configuration state.” Claim 13 recites using a “boot
`program at the client device to perform the step of restoring.”
`Petitioner argues that these limitations are met by BMR User Guide’s
`“boot script.” Pet. 30; Pet. Reply 10–12. Patent Owner argues that BMR
`User Guide’s “boot script” does not meet the claimed “boot program”
`because (1) BMR User Guide does not disclose that the content of the boot
`script allows for configuration of the client device and (2) a script is distinct
`from a program. PO Resp. 17–19.
`As to Patent Owner’s first argument, neither claim 2 nor claim 13
`specifies the content of the boot program or specifies how the boot program
`performs the step of restoring. BMR User Guide discloses that, during the
`restoration process, a customized client boot script is created and run. Ex.
`1003, 4. We determine that this disclosure meets the limitations of claims 2
`and 13. As to Patent Owner’s second argument, as discussed above, we
`determine that the term “program” encompasses a script, and, thus, we
`determine that BMR User Guide’s disclosed boot script (id. at 2) meets the
`claimed boot program.
`For the reasons discussed above, we determine that BMR User Guide
`discloses the claimed boot program as recited in claims 2 and 13.
`
`
`
`13
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`
`c. Network Boot
`Independent claim 1 recites “a network boot in which the server
`device causes the client device to boot.” Dependent claims 4 and 10 each
`recite “the step of booting is performed by a boot server of the network.”
`Petitioner argues that these limitations are met by BMR User Guide’s
`disclosure of a boot server network-booting a client. Pet. 28 (citing Ex.
`1003, 2); Pet. Reply 12–13. Patent Owner argues that, although BMR User
`Guide describes a network boot, BMR User Guide does not describe that the
`server device or boot server causes the network boot, because BMR User
`Guide describes that a human operator is required to perform multiple steps
`prior to the initiation of a network boot. PO Resp. 19–21. Patent Owner’s
`argument implies that these limitations preclude the intervention of a human
`operator, in any capacity, during a network boot. See id.
`We see nothing in these limitations that would preclude a human
`operator from performing steps prior to the initiation of a network boot.
`BMR User guide discloses that the boot server performs a “network boot” to
`boot the client device prior to restoration. Ex. 1003, 2. Further, BMR User
`Guide states: “BMR uses the standard bootp or bootparam protocol to
`network-boot the client from the boot server.” Id. at 2. These are the same
`protocols that the ’558 patent uses as the network boot. Ex. 1001, col. 6,
`ll. 59–62 (“[t]he network boot performed by the client computer 106 in such
`manner uses the standard ‘bootp’ and/or ‘bootparams’ protocols to network
`boot the client computer 106 from the boot server 304”).
`For the reasons discussed above, we determine that BMR User Guide
`discloses a boot server causing or performing a network boot.
`
`
`
`14
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`
`iii. Dependent Claims 5, 6, 8, 12, 14, and 15
`
`Patent Owner makes no arguments regarding the additional limitations
`recited in dependent claims 5, 6, 8, 12, 14, and 15. Upon review of the
`Petitioner’s evidence and analysis (Pet. 16-18, 12-23), we determine that
`Petitioner has shown by a preponderance of the evidence that the dependent
`claims are unpatentable.
`iv. Separately Argued Dependent Claims
`a. Claim 3
`Claim 3 depends from claim 2 and further recites, “wherein the steps
`of booting, creating, configuring, and copying are performed through
`communications over the network between the client device and the server
`computer.” Patent Owner argues that “Petitioner does not even attempt to
`address how . . . the BMR [User] Guide disclose[s] that each of the steps of
`booting, creating, configuring, and copying [are] performed over the
`network between the client device and the server computer.” PO Resp. 22.
`Petitioner, however, relies upon the depiction in the Figure on page 3 of
`BMR User Guide, reproduced above, of each of the BMR, Boot, File, and
`ESM servers communicating with the client across a network. Petitioner
`also relies upon BMR User Guide’s statement that restoration time is
`determined by network speed. Pet. 31–32 (citing Ex. 1003, 4). Patent
`Owner does not dispute the substance of Petitioner’s statement regarding the
`disclosure of a network in the Figure of page 3. Further, BMR User Guide
`includes several references to IP addresses, network interfaces, and gateways
`connecting the various serves and clients. E.g., see Ex. 1003, 5–9. These
`further support the disclosure of a network.
`
`
`
`15
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`For the reasons discussed above, we determine that BMR User Guide
`
`discloses the additional limitation of claim 3.
`b. Claim 7
`Claim 7 depends from claim 2 and further recites, “wherein the step of
`copying is performed by a storage manager server of the network.” Patent
`Owner argues that BMR User Guide does not describe the additional
`limitation of claim 7 because step 5 of the restoration process discloses
`mounting file systems from the file server and not from the storage manager
`server. PO Resp. 22–23. Patent Owner’s argument, however, is not
`persuasive for it fails to account for step 7 of the restoration process, which
`states that all files are restored (i.e., copied) from the ESM server. Ex. 1003,
`4; see Pet. 32–33; Pet. Reply 14; see also Ex. 1003, 3 (Figure depicting ESM
`server communicating all backed-up client files to the restore client).
`For the reasons discussed above, we determine that BMR User Guide
`discloses the additional limitation of claim 7.
`c. Claim 9
`Claim 9 depends from claim 8, which depends from claim 2. Claim 9
`recites, additionally, “wherein the step of storing is performed by a standard
`storage manager application and includes backup of the configuration state
`of the client computer.” Patent Owner argues that BMR User Guide does
`not disclose backing up a configuration state that includes client disk
`configuration information. PO Resp. 23. For the same reasons as discussed
`above with respect to claim 2, we determine that BMR User Guide discloses
`the additional limitation of claim 9.
`
`
`
`
`16
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`
`C. Ground Based on BMR Webpages (Ex. 1002)
`
`
`BMR Webpages discloses essentially the same BMR product as the
`BMR User Guide, which we determined anticipates claims 1–15. However,
`BMR User Guide is a more complete description of the product from the
`Web Pages. We do not find claims 17-23 to be anticipated by the BMR
`Webpages.
`
`
`D. Ground Based on Deshayes (Ex. 1005)
`Petitioner argues that independent claim 11 and dependent claim 14
`are anticipated by Deshayes. Pet. 48–52; see Pet. Reply 14–15. For the
`reasons discussed below, we determine that Petitioner has demonstrated by a
`preponderance of the evidence that claims 11 and 14 are anticipated by
`Deshayes.
`
`i. Claim 11
`
`Claim 11 recites “backing up configuration data including client disk
`configuration information” and “restoring the backed up configuration data.”
`The parties dispute whether Deshayes discloses both of these steps.
`Petitioner argues that Deshayes’ disclosure of saving level volume
`information during a backup procedure and later using this information in a
`restore meets these limitations. Pet. 50–52; Pet. Reply 14–15. Petitioner
`cites to Deshayes’ statement that the backup process includes identifying
`“the logical volume manager level information is determined for the
`information to be backed up” to meet the client disk configuration
`information. Id. at 50 (citing Ex. 1005, col. 10, ll. 13–14). Patent Owner
`argues that the cited statement of Deshayes discloses identifying information
`to be backed up, not backing up the logical volume manager level
`
`
`
`17
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`information. PO Resp. 23–25. Further, Patent Owner argues that the
`volume location information is not later restored because it is used to
`determine how the data stored on the backup storage system corresponds to
`physical, virtual, and logical memory structure of the client during the
`restoration. Id. at 25.
`We are not persuaded by Patent Owner’s argument. Deshayes
`describes a method for backing up and restoring data between storage
`system 52 and backup storage system 54. See Ex. 1005, Abstract.
`Deshayes’ Figure 9 is reproduced below:
`
`
`Figure 9 depicts the preparation of discovery data table (DDTAB) file 98.
`Id. at col. 6, ll. 46–47. Deshayes discloses determining the volume locations
`(i.e., client disk configuration information) of information to be backed up
`and entering this information into DDTAB file 98. Id. at col. 10, ll. 7–19.
`18
`
`
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`DDTAB file 98 is sent from client 50 to backup storage system 54. Id. at
`col. 10, ll. 64–66. Deshayes also discloses that this DDTAB file 98 is later
`used for restoring the client. Id. at col. 11, ll. 10–19. We, thus, determine,
`contrary to the Patent Owner’s argument, that Deshayes discloses backing
`up the volume locations. Further, Deshayes states “[t]hus, when a restore is
`later requested, the backup storage system will have a record specifying
`where the data is stored on the backup storage system 54 memory system
`and how that is intended to correspond to the physical, virtual and logical
`memory structure of the client 50 and storage system 52.” Id. at col. 11,
`ll. 14–19. We see no limitations in claim 11 that restrict how the client disk
`configuration information is restored or preclude the client disk
`configuration information from being used in the restore process in the
`manner disclosed in Deshayes.
`We, thus, determine that Deshayes discloses both the backing-up and
`restoring of configuration data that includes client disk configuration
`information.
`
`ii. Claim 14
`Patent Owner makes no separate arguments contesting the additional
`limitation recited in dependent claim 14. Upon review of the Petitioner’s
`evidence and analysis (Pet. 23), we determine that Petitioner has shown by a
`preponderance of the evidence that the dependent claims are unpatentable.
`E. Motion to Amend
`Patent Owner filed a contingent Motion to Amend the claims under
`
`37 C.F.R. § 42.121. Petitioner filed an Opposition to the Motion to Amend
`(Paper 28, “Am. Opp.”), and Patent Owner filed a Reply to the Motion to
`Amend (Paper 37, “Am. Reply”).
`
`
`
`19
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`
`Patent Owner proposes to substitute claims 24–26 for challenged
`independent claims 1, 2, and 11 and to substitute claim 27 for challenged
`dependent claim 12. To the challenged claims, Patent Owner’s Motion to
`Amend proposes to add four limitations: 1) that the client device is reset by a
`controlling device, 2) that the client disk configuration information
`comprises partitions, volume groups, logical volumes, and files systems,
`3) that the configuration files are mounted at the client device from a file
`server, and 4) that the client device is booted via a standard network boot.
`Patent Owner argues that each of these additional limitations isnot disclosed
`in the prior art of record, and, therefore, the proposed substitute claims are
`not anticipated by the cited prior art. See Mot. to Amend, 11–14; Am.
`Reply, 2–4. Petitioner argues that Patent Owner’s Motion to Amend is
`deficient because it fails to consider all prior art references cited in this
`proceeding and fails to demonstrate that the substitute claims are obvious
`over the cited prior art. See Am. Reply, 3–11.
`We shall address each of the proposed additional limitations in turn.
`For the reasons discussed below, Patent Owner’s Motion to Amend is
`denied.
`
`i. Controlling Device for Resetting the Client Device
`
`Substitute claim 24 adds “a controlling device connected to the client
`device, for resetting the client device” to challenged claim 1. Mot. to
`Amend, 2. Substitute claims 25 and 26 add “resetting the client device using
`a controlling device connected to the client” to challenged claims 2 and 11.
`Id. at 2–3. Patent Owner argues that none of BMR Webpages, BMR User
`
`
`
`20
`
`
`
`IPR2013-00141
`Patent 6,931,558 B1
`
`Guide, Deshayes, or DRAC4 anticipates these substitute claims because none
`of these prior art references describes a controlling device for resetting the
`client device. Id. at 7–9, 11, 13. Patent Owner also argues that this
`limitation is “significant,” and generally states that none of the prior art
`known to it “used such a device in connection with the claimed device
`restoration system of substitute claim 24 or the claimed method of restoring
`a client device of substitute claims 25 and 26 of the ’558 patent.” Id. at 11–
`12.
`Patent Owner, however, fails to demonstrate that the substitute claims
`
`are patentable because of the addition of a controlling device for resetting
`the client. Patent Owner bears the burden of proof in demonstrating
`patentability of the proposed substitute claim over the prior art of record and
`also prior art known to Patent Owner, and, thus, entitlement to add these
`proposed substitute claims to its patent. See Idle Free Systems, Inc. v.
`Bergstrom, Inc., Case IPR2012-00027, slip op. at 7 (PTAB June 11, 2013
`(Paper 26) (“Id