`
`In re inter partes review of:
`
`U.S. Patent 7,093,086 to
`van Rietschote
`Filed: Herewith
`For: Disaster Recovery and Backup
`Using Virtual Machines
`
`
`
`Atty. Docket: 2907.020IPR0
`
`
`
`
`
`
`Declaration of Dr. Prashant Shenoy
`in Support of Petition for Inter Partes Review of U.S. Patent No. 7,093,086
`
`
`
`I, Prashant Shenoy, declare as follows:
`
`1.
`
`I have been retained by Sterne, Kessler, Goldstein, and Fox
`
`PLLC on behalf of Veeam Software Corporation (“Veeam”) for the above-
`
`captioned inter partes review proceeding. I understand that this proceeding
`
`involves U.S. Patent No. 7,093,086 (“the ‘086 patent”) entitled “Disaster
`
`Recovery and Backup using Virtual Machines,” and that the ‘086 patent is
`
`currently assigned to Symantec Corporation.
`
`2.
`
`I have reviewed and am familiar with the specification of the
`
`‘086 patent filed on March 28, 2002. A copy of the ‘086 patent is provided
`
`as VEEAM 1001.
`
`
`
`- 2 -
`
`
`I have reviewed and am familiar with the following prior art,
`
`3.
`
`which I understand is used in the Petition for Inter Partes Review of the
`
`‘086 patent:
`
`a. U.S. Patent No. 6,795,966 to Lim (“Lim,” provided as VEEAM
`
`1004);
`
`b. “VMware ESX Server: User’s Manual” (“VMware ESX,”
`
`provided as VEEAM 1005)
`
`c. “Getting Started Guide: VMware 2.0 for Linux” (“VMware
`
`GSG,” provided as VEEAM 1006);
`
`d. An English
`
`translation of “Checkpoint
`
`for Network
`
`Transferable Computer” by Suzaki (“Suzaki,” provided as
`
`VEEAM 1008);
`
`e. “Integrating Checkpointing with Transaction Processing” by
`
`Wang (“Wang,” provided as VEEAM 1010); and
`
`f. U.S. Patent No. 6,917,963 to Hipp (“Hipp,” provided as
`
`VEEAM 1011.)
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`- 3 -
`
`
`I am familiar with the technology at issue as of the March 28,
`
`4.
`
`2002 filing date of the ‘086 patent.
`
`5.
`
`I have been asked to provide my technical review, analysis, and
`
`insight regarding the above-noted references that form the basis for the
`
`grounds of rejection set forth in the Petition.
`
`I.
`
`Qualifications
`
`1.
`
`I have more
`
`than
`
`two decades of
`
`experience
`
`in
`
`distributed/operating systems, networking, and data management. During
`
`that time, I have published over 150 technical papers that have been cited in
`
`other publications more than 5,500 times.
`
`2.
`
`I earned a Bachelor of Technology degree from the Department
`
`of Computer Science and Engineering at the Indian Institute of Technology
`
`in Bombay, India. I later received my Master of Science (M.S.) and Doctor
`
`of Philosophy (Ph.D.) degrees in 1994 and 1998, respectively, in Computer
`
`Science from the University of Texas of Austin.
`
`3. Over the years, I have led research and industry collaboration
`
`projects in areas such as storage and file systems, cloud computing,
`
`virtualization, content distribution, streaming media, database systems,
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`
`RFID and sensor networks, and energy systems. During that time, I have
`
`- 4 -
`
`consulted with both large companies and startups in a technical advisory
`
`role related to product architecture, IP issues, and applied research.
`
`4.
`
`I have been a professor in the Department of Computer Science
`
`at the University of Massachusetts Amherst since 1998. During that time, I
`
`taught graduate courses on virtualization and distributed systems, and
`
`undergraduate courses on operating systems. The courses covered in-depth
`
`discussions of virtualization technologies, as well as material on storage and
`
`file systems.
`
`5. My Curriculum Vitae is attached as VEEAM 1003, which
`
`contains further details on my education, experience, publications, and
`
`other qualifications to render an expert opinion. My work on this
`
`declaration is being billed at a rate of $435.00 per hour, with reimbursement
`
`for actual expenses. My compensation is not contingent upon the outcome
`
`of this inter partes review.
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`II. My Understanding of Claim Construction
`
`- 5 -
`
`
`
`6.
`
`I understand that, at the Patent Office, claims are to be given
`
`their broadest reasonable construction in light of the specification as would
`
`be read by a person of ordinary skill in the relevant art.
`
`III. My Understanding of Anticipation
`
`7.
`
`I understand that a claim is unpatentable if every element is
`
`actually disclosed in a reference as recited in the claims. The disclosure
`
`may be explicit, implicit, or inherent. I understand that a reference is read
`
`from the perspective of a person of ordinary skill in the art at the time of the
`
`invention.
`
`IV. My Understanding of Obviousness
`
`8.
`
`It is my understanding that a claimed invention is unpatentable
`
`if the differences between the invention and the prior art are such that the
`
`subject matter as a whole would have been obvious at the time the invention
`
`was made to a person having ordinary skill in the art to which the subject
`
`matter pertains.
`
`9.
`
`It is my understanding that “obviousness” is a question of law
`
`based on underlying factual issues including the content of the prior art and
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`
`the level of skill in the art. I understand that for a single reference or a
`
`- 6 -
`
`combination of references to render the claimed invention obvious, a person
`
`of ordinary skill in the art must have been able to arrive at the claims by
`
`altering or combining the applied references.
`
`10.
`
`I also understand that when considering the obviousness of a
`
`patent claim, one should consider whether a teaching, suggestion, or
`
`motivation to combine the references exists so as to avoid impermissibly
`
`applying hindsight when considering the prior art. I understand this test
`
`should not be rigidly applied, but that the test can be important to avoid
`
`such hindsight.
`
`11.
`
`In addition, it is my understanding that one must consider
`
`whether or not there is objective evidence of non-obviousness, which is also
`
`referred to as the “secondary considerations of non-obviousness.”
`
`V. Level of Ordinary Skill in the Art
`
`12. Based on the technologies disclosed in the ‘086 patent, one of
`
`ordinary skill in the art would have a B.S. degree in Computer Science or
`
`Engineering, as well as at least 3-5 years of experience in the relevant field.
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`VI. The ‘086 Patent
`
`- 7 -
`
`
`
`13. The ’086 patent relates to the copying of data from computer
`
`systems running virtual machines. In general, a virtual machine is a
`
`software implementation of a physical machine, which includes virtual
`
`hardware capable of running operating systems and other applications.
`
`Virtual machines often include virtual disks which are mapped to physical
`
`disks. Virtual machines have a long history. As early as the 1970s, IBM
`
`sold virtual machine products. In this way, a single physical machine, for
`
`example a mainframe computer, can execute multiple different virtual
`
`machines, thereby utilizing resources of the physical machine more
`
`efficiently.
`
`14. Just as with physical machines, the data on virtual machines can
`
`be copied to a separate destination. For example, the state of a virtual
`
`machine can be copied to replicate aspects of the virtual machine or to back
`
`up the virtual machine, thereby mitigating the impact of an unexpected
`
`crash of the virtual machine or the physical computer in which the virtual
`
`machine is executing. The challenged independent claims 1 and 12 of the
`
`‘086 patent are both directed to capturing state information of a virtual
`
`machine and copying the state information to a separate destination.
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`VII. U.S. Patent No. 6,795,966 to Lim
`
`- 8 -
`
`
`
`15. Lim describes capturing the state of a virtual machine. The
`
`“state is the entire collection of all information that is necessary and
`
`sufficient to uniquely determine the status of all hardware and software
`
`components at the completion of any given processor instruction.” (Lim,
`
`10:27-30.) To capture the state (referred to in Lim as a “state vector”), “the
`
`[virtual] machine is interrupted and its operations suspended. . . . [S]tate
`
`extraction mechanism . . . then extracts the machine state and saves it in
`
`storage . . . as the initial checkpoint [state vector] S0.” (Lim, 18:3-8.)
`
`“[O]nly one state vector–the initial vector S0–need be stored in its entirety;
`
`subsequent states are represented not as entire state vectors, but rather as
`
`vectors of state changes using copy-on-write techniques.” (Lim, 23:52-56.)
`
`16. Lim depicts copying the state information over a network in
`
`FIG. 6, reproduced below. “[T]he state vector of a first virtual machine
`
`VM1 . . . could be transferred over any conventional transmission medium
`
`to any other architecturally similar virtual machine VM2 and loaded into
`
`that virtual machine as its initial state. . . .” (Lim, 21:44-49.) “The
`
`transmission medium could be a . . . network such as the Internet or an
`
`internal network within an enterprise, with the state vector being transferred
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`
`using any conventional format such as FTP.” (Lim, 21:50-54.) FTP is a
`
`- 9 -
`
`well-known data transmission technique.
`
`
`
`17. By transmitting state information over a network, Lim discloses
`
`copying state information to a destination over a network. The destination
`
`can be another virtual machine(s). Such other destination virtual machines
`
`may execute from a state corresponding to the received state information.
`
`(Lim, 21:44-49.)
`
`18. Lim also discloses copying state while the virtual machine is
`
`executing. Lim discloses creating a log of uncommitted updates for a
`
`virtual disk. “In [Lim’s] preferred embodiment . . . , only one state
`
`vector—the initial vector S0—need be stored in its entirety; subsequent
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`
`states are represented not as entire state vectors, but rather as vectors of
`
`- 10 -
`
`state changes using copy-on-write techniques.” (Lim, 23:52-55.) For
`
`example, “[f]or state which is large and changes slowly, such as disk
`
`contents, it is more efficient to keep a log of the changes instead of a copy
`
`of the entire contents.” (Lim, 11:67-12:3 (emphasis added).). Lim further
`
`discloses that the updates can be uncommitted: “[t]his log [of changes] can
`
`then be discarded to roll back the transaction, or it can be saved, or it can be
`
`applied to the first checkpoint to commit the transaction.” (Lim, 11:53-56.)
`
`Until the log is applied (i.e. committed) the changes remain uncommitted
`
`because the log can be simply discarded and the changes would be lost.
`
`19. Lim explains that the total state of the virtual machine is
`
`captured in a state vector or checkpoint. (Lim, 6:48-52). The total state
`
`includes “state information . . . of the virtual memory.” (Lim, 6:42-43.)
`
`Because memory may contain a lot of data, Lim describes using copy-on-
`
`write techniques to increase efficiency.
`
`20. “Copy-on-write is a common technique that allows copies to be
`
`created quickly, using a table of pointers to the actual data, and only
`
`copying the data when it is modified by a user program.” (Lim, 2:37-40.)
`
`Lim describes that memory copy-on-write is a technique that “only updates
`Inter Partes Review of U.S.P. 7,093,086
`2907.020IPR0
`
`
`
`
`to the state vectors from checkpoint to checkpoint need be stored.” (Lim,
`
`- 11 -
`
`19:59-62.)
`
`21. Lim also describes that state vectors can be stored in memory:
`
`“The number of complete state vectors that can be stored at any one time
`
`will therefore be determined by the amount of available storage (for
`
`example, in a dedicated memory partition)” (Lim, 19:51-55). Since state
`
`vector’s store “updates” (i.e. writes to memory), and are also themselves
`
`stored in “a dedicated memory partition,” Lim discloses “creating a
`
`memory area to capture writes to a memory.”
`
`22. Lim discloses that the virtual machine can continue executing
`
`during the copying. Lim explains that the stored state vector is preferably
`
`stored in manner such that it “will persist even after system power is turned
`
`off and back on again later.” (Lim, 19:31-32.) In addition, “any stored state
`
`vector may be loaded into the corresponding virtual machine, or even into a
`
`different virtual machine . . . .” (Lim, 20:40-42.) Since the stored state
`
`vector persists, and can thus be stored indefinitely, it can be copied to
`
`another virtual machine at any time, for example while the virtual machine
`
`is executing.
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`VIII. “VMware ESX Server: User’s Manual”
`
`- 12 -
`
`
`
`23. The VMware ESX server captures state information in two
`
`files–a .std file and a .redo file. “When a virtual machine is suspended, its
`
`state is written to a file with a .std extension.” (VMware ESX, p. 97.)
`
`When the virtual machine is operating, “changes are saved in a redo-log
`
`file.” (VMware ESX, p. 39.) These changes stored in the redo log include
`
`any modification to a virtual disk made during execution of the virtual
`
`machine. (VMware ESX, p. 94.)
`
`24. VMware ESX explains that the redo log can be stored in a
`
`separate storage device from which the virtual machine is suspendable. For
`
`example, VMware ESX explains, “[t]he redo log can . . . be transported to a
`
`remote site.” (VMware ESX, p. 106.) A virtual machine is typically
`
`suspendable to a local disk. Regardless of where the virtual machine is
`
`actually suspendable, since the redo log can be stored remotely, VMware
`
`ESX describes storing the redo log in a separate destination from where the
`
`virtual machine is suspendable. Thus, VMware ESX discloses capturing
`
`state information and copying state information to a separate destination.
`
`25. “[A] virtual machine is configured with its own . . . applications
`
`. . . .” (VMware ESX, p.8.) In addition, the virtual machine also includes a
`Inter Partes Review of U.S.P. 7,093,086
`2907.020IPR0
`
`
`
`
`virtual disk (VMware ESX, p. 39.) The virtual disk includes files stored in
`
`- 13 -
`
`a filesystem: “you can also create a VMFS file system on the partition or
`
`disk. . . .” (VMware ESX, p. 47.) Since VMware ESX explains that the
`
`virtual machine includes applications and files stored on a virtual disk, a
`
`person of ordinary skill in the art would have understood upon reading
`
`VMware ESX that the applications in the virtual machine could access their
`
`files stored on the virtual disk when they are executing.
`
`26. “When a virtual machine is suspended, its state is written to a
`
`file with a .std extension.” (VMware ESX, p. 97.) “This file contains the
`
`entire state of the virtual machine,” including memory state and the files
`
`used by the applications. (VMware ESX, p. 98 (emphasis added).) As
`
`mentioned above, the state may also be captured in a redo file. “The redo
`
`log contains the incremental changes to the disk image,” including changes
`
`to a file used by an application. (VMware ESX, p. 106.)
`
`27. VMware ESX also discloses that the virtual machine can
`
`continue executing while the state information is being copied to a
`
`destination. Specifically, “[t]he vmfkstools program provides additional
`
`functions . . . when you need to import files from and export files to the
`
`console operating system’s file system.” (VMware ESX, p. 104.) Using
`Inter Partes Review of U.S.P. 7,093,086
`2907.020IPR0
`
`
`
`
`the vmfkstools program, “[t]he contents of the redo log can be copied to the
`
`- 14 -
`
`file system of the console operating system using the exportraw command.
`
`The redo log can then [after the exportraw command] be transported to a
`
`remote site and copied to the SCSI disk . . . .” (VMware ESX, p. 106
`
`(emphasis added).) The console operating system is a separate entity from
`
`the virtual machines executing on the virtual machine host. For example,
`
`the console operating system can execute concurrently with the virtual
`
`machines. Thus, after the redo log has been copied to the console operating
`
`system it can be copied to another destination (such as a remote destination)
`
`at any time, particularly when the virtual machine is executing.
`
`IX. “Getting Started Guide: VMware 2.0 for Linux”
`
`28. Similar to Lim and VMware ESX, VMware GSG describes
`
`how state information is saved to disk when the virtual machine is
`
`suspended and how state changes are saved in a redo log during operation.
`
`29. The virtual machine described in VMware GSG provides a
`
`“virtualized x86 PC environment on which a guest operating system and
`
`associated application software can run.” (VMware GSG, p. 4-3.) Also,
`
`VMware GSG discloses that “[a] virtual disk is a file on the host file system
`
`that appears as a physical disk drive to a guest operating system.” (VMware
`Inter Partes Review of U.S.P. 7,093,086
`2907.020IPR0
`
`
`
`
`GSG, p. 4-2.) The virtual disk stores files that are used by applications
`
`- 15 -
`
`executing in the virtual machine.
`
`30. VMware GSG also describes capturing and copying state
`
`information during execution. Specifically, during execution, state is
`
`captured and copied to a REDO log. For example, changes made during a
`
`“working session” are saved in a redo-log file. (VMware GSG, p. 2-5.)
`
`“[W]rites to the disk are logged [] in a redo log file. . . . While the VMware
`
`session is running, disk blocks that have been modified and written to the
`
`redo log are read from there instead of the disk.” (VMware GSG, p. 3-9.)
`
`31. The state can also be copied to a destination separate from
`
`which the virtual machine is suspendable: “The redo log file is placed in the
`
`same directory as the disk file by default. However, the location of the redo
`
`log file can be changed in the Configuration Editor under Misc.” (VMware
`
`GSG, p. 3-9.) Thus, the redo log file is stored on disk. VMware GSG
`
`explains that the virtual machine can be suspended to memory: “If you
`
`suspend to memory, the saved state of the virtual machine is available as
`
`long as the virtual machine is powered on.” (VMware GSG, p. 3-25
`
`(emphasis added).) Thus, since the REDO log which stores state is saved on
`
`the disk, and the virtual machine can be suspended to memory, VMware
`Inter Partes Review of U.S.P. 7,093,086
`2907.020IPR0
`
`
`
`
`GSX discloses copying at least a portion of the state “to as destination
`
`- 16 -
`
`separate from a storage device to which the first virtual machine is
`
`suspendable.”
`
`X.
`
` “Checkpoint for Network Transferable Computer” by Suzaki and
`“Integrating Checkpointing with Transaction Processing” by Wang
`
`32. Suzaki describes “a ‘network transferable computer’ . . . built
`
`on the combination of virtual machine software, VMware, free OS, Linux,
`
`and hibernation software, SWSUSP.” (Suzaki, p. 2.) Suzaki’s “‘[n]etwork
`
`transferable computer’ travels between virtual machines.” (Suzaki, p. 2.)
`
`The “‘[n]etwork transferable computer’ not only transfers a [virtual
`
`machine’s] disk image but can also recreate the same OS environment on
`
`another computer.” (Suzaki, p. 3.) To transfer the OS environment, a
`
`“[c]heckpoint function makes it possible to save current state information
`
`[referred to as a ‘snapshot’] without stopping the execution of the process.”
`
`(Suzaki, p. 5.) Specifically, Suzaki explains that its checkpoints are taken
`
`at the operating system level: “[w]hen the OS executes Checkpoint, a copy
`
`of Disk 1 is taken by Disk 2.” (Suzaki, p. 5.) In this way, by checkpointing
`
`and transferring the state of a virtual machine, Suzaki describes capturing
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`
`state information of a virtual machine and copying the state information to a
`
`- 17 -
`
`separate destination.
`
`33. Suzaki discloses suspending a virtual machine in response to a
`
`suspend command. Suzaki states that suspending the first virtual machine
`
`is performed when SWSUSP is invoked “Linux [is] patched with
`
`hibernation software, SWSUSP, as a guest OS on a virtual machine
`
`provided by VMware.” (Suzaki, p. 4.). SWSUSP can be invoked by issuing
`
`a command or signal to the SWSUSP software. SWSUSP “[m]oves all the
`
`state information to nonvolatile memory such as hard disks and turns off a
`
`computer.” (Suzaki, p. 4.) In the case of the virtual machine, that results in
`
`the virtual machine no longer executing, as it is turned off. Specifically
`
`SWSUSP “calls the bdflush process and evacuates the buffer marked dirty
`
`for all the executing processes to the SWAP area before killing the
`
`executing process by sending SIGKILL.
`
` When the evacuation is
`
`completed, shutdown process executes sync and halts the OS.” (Suzaki, p.
`
`4. (emphasis added).)
`
`34. While Suzaki discloses using a checkpoint function to capture a
`
`state, it appears that Suzaki does not explicitly disclose that the
`
`checkpointing involves the creation of a new log of uncommitted updates.
`Inter Partes Review of U.S.P. 7,093,086
`2907.020IPR0
`
`
`
`
`Beyond modifying the SWSUSP software, Suzaki does not disclose the
`
`- 18 -
`
`specific implementation details of checkpointing, thus a skilled artisan
`
`would have been motivated to seek out those details. Using a log of
`
`uncommitted updates is a well-known way to checkpoint data. For
`
`example, one such checkpointing mechanism is described in Wang.
`
`35. Wang describes “‘checkpointing’ [to] record[] critical memory
`
`and file state at a given point of program execution on stable storage.”
`
`(Wang, p. 304.) Wang further describes a “[t]ransactional Unix-file
`
`manager” that “implement[s] per-application transactional file updates.”
`
`(Wang, p. 306.) Wang states, “[e]very file update operation is intercepted
`
`by libfcp_RM, and an idempotent undo operation is added to the UNDO
`
`log.” (Wang, p. 306.) The updates in this UNDO log remain uncommitted
`
`until an application “call[s an] fcp_prepare()” function, at which point “the
`
`application would…start[] a two-phase commit protocol.” (Wang, p. 306
`
`(emphasis added).) After the changes are committed, the application
`
`continues to execute. (Wang, p. 306.). Thus, Wang discloses including a
`
`checkpointing method that includes creating a new log of uncommitted
`
`updates into a UNIX file manager.
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`- 19 -
`
`
` The UNIX file system modified in Wang is highly analogous
`
`36.
`
`to the Linux file system utilized in Suzaki. Linux is a free Operating
`
`System first developed by Linus Torvalds in 1991. UNIX is a proprietary
`
`Operating System first developed by AT&T Bell Laboratories in 1969.
`
`Linux was developed as a free alternative to the commercial UNIX OS.
`
`Linux is similar to UNIX and is often referred to as a UNIX-like operating
`
`system. Many of the mechanisms in UNIX either have equivalent
`
`counterparts in Linux or can be implemented in Linux using similar
`
`methods.
`
`37. A skilled artisan would be motivated to include Wang’s method
`
`of checkpointing using a log of uncommitted updates to implement the
`
`checkpoint function disclosed in Suzaki to “to ensure consistency and
`
`recoverability of data.” (Wang, p. 304.) Also, Suzaki contemplated the
`
`need to “save current state information without stopping the execution of
`
`the process.” (Suzaki, p. 5.) In software development, methods having
`
`similar functionality often can be substituted for one another. Here, both
`
`the checkpoint function described in Suzaki and the checkpoint function
`
`described in Wang provide “the action of recording critical memory and file
`
`state at a given point of program execution on stable storage.” (Wang, p.
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`
`304.) Also, both the checkpointing process in Wang and Suzaki allow for
`
`- 20 -
`
`applications to continue executing. Including Wang’s checkpointing
`
`method into the checkpoint function disclosed in Suzaki would involve the
`
`use of a log of uncommitted updates and two phase commit to implement
`
`checkpointing and is merely a substitution of one known element for
`
`another to obtain predictable results. The results are predictable because
`
`both methods allow applications to continue to execute while capturing
`
`memory and file state.
`
`XI. U.S. Patent No. 6,917,963 to Hipp
`
`38. Conventionally there are three categories of virtualization:
`
`hardware-level, operating-system level, and application-level.
`
` Hipp
`
`describes operating-system level virtualization: “virtual environment . . .
`
`that surrounds application(s) and resides between the application and the
`
`operating system.”
`
`(Hipp, 3:64-66
`
`(reference numerals omitted).)
`
`Specifically, “[r]esource handles are abstracted to present a consistent view
`
`to the application although the actual system resource handles may change
`
`as an application is snapshot/restored more than once.” (Hipp, 3:66-4:2.)
`
`The virtual environment, application, and operating system are depicted in
`
`Hipp’s FIG. 4, reproduced below:
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`- 21 -
`
`
`
`
`
`
`
`
`
`39. As can be seen in Fig. 4, the resources are abstracted with the
`
`help of the snapshot driver and the preload library. “Preload library 214 is
`
`an application library that interposes upon an application for the express
`
`purpose of intercepting and handling calls and system calls. Once the
`
`library has been preloaded it is attached to the process' address space. . . .
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`
`These calls are made from the application 208 to the operating system API
`
`- 22 -
`
`interfaces 210 via the application snapshot restore framework 200 or the
`
`preload library 214.” (Hipp, 4:6-18.)
`
`40. Hipp describes that the virtual machine includes applications
`
`executing which use at least a file. For example, Fig 4, reproduced above,
`
`depecits two applications (application 1 & 2) executing in the virtual
`
`machine. Hipp describes that “The preload library can save the state of
`
`various resources by intercepting API interface calls and then saves the
`
`state at a pre-arranged memory location.” (Hipp, 4:18-21.) One such API
`
`call is the “the open ( ) system call which allows an application to open a
`
`file for reading is an example of an API interface.” (Hipp, 4:30-32.)
`
`Because Hipp describes that the application can open files via API calls, a
`
`skilled artisen would known that the executing applications use files stored
`
`on disk.
`
`41. Hipp also describes saving state including at least one file.
`
`Hipp describes that “The preload library can save the state of various
`
`resources by intercepting API interface calls and then saves the state at a
`
`pre-arranged memory location.” Hipp refers to this as a “snapshot”, which
`
`is the same as a checkpoint. Hipp also explains that the virtualized system
`Inter Partes Review of U.S.P. 7,093,086
`2907.020IPR0
`
`
`
`
`resource may be “memory, files, sockets, handles, etc.” (Hipp, 7:3
`
`- 23 -
`
`(emphasis added).) Thus, Hipp discloses that the state includes at least one
`
`file.
`
`42. Hipp also describes creating a new log of uncommitted updates
`
`for each disk in the virtual machine. Specifically, Hipp generally discloses
`
`virtualizing system resources. (Hipp, 9:59-62.) One such system resource
`
`may be “files.” (Hipp, 7:3 (emphasis added).) Files are stored on disks, and
`
`techniques used to virtualize resources such as files, could be applied to
`
`storage, thereby creating a virtualized disk. In Hipp, “[a]ccess to memory
`
`and storage is managed in a copy-on-write fashion.” (Hipp, abstract.
`
`(emphasis added.)) For resources, such as memory and storage, that are
`
`“marked for copy-on-write,” “a reference to the original underlying object .
`
`. . is kept, and any modifications to the original force a copy-on-write action
`
`so that the modifications are kept in an application-instance private location
`
`and the two form a composite view that is visible to the application
`
`instance.” (Hipp, 9:36-42.) By storing updates to storage separately in an
`
`“application-instance private
`
`location,” Hipp discloses a
`
`log of
`
`uncommitted updates for the virtual disk because they are never committed
`
`to the virtual disk.
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`
`43. Hipp discloses creating a memory area to capture writes to a
`
`- 24 -
`
`memory of the first virtual machine, such that the first virtual machine can
`
`continue executing. Hipp explains that “[a]ccess to memory . . . is managed
`
`in a copy-on-write fashion.” (Hipp, 7:15-16.) Hipp further explains that “If
`
`a resource is marked for copy-on-write . . . then . . . a reference to the
`
`original underlying object . . . is kept, and any modifications to the original
`
`force a copy-on-write action so that the modifications are kept in an
`
`application-instance private location . . .” (Hipp, 9:36-41 (emphasis
`
`added).) Since the application-instance private location captures the
`
`modifications made to memory, Hipp discloses a memory area to capture
`
`writes to a memory of the virtual machine.
`
`44. Also, Hipp discloses that the virtual machine can continue
`
`executing during copying (ii) as claimed. While Hipp discloses that
`
`processes of an application are terminated once a snapshot is taken (steps
`
`284-286 in FIG. 5), the virtual environment does not terminate, and, thus,
`
`remains executing when the sequence of steps in FIG. 5 is concluded.
`
`When “[t]his sequence of steps is concluded[, the] snapshot image . . . is . . .
`
`made available for transmission [i.e. copying as in step (ii)] to another
`
`computer.” (Hipp, 5:42-45.)
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`XII. Suzaki and Hipp
`
`- 25 -
`
`
`
`45. As explained previously with respect to Suzaki and Hipp,
`
`While Suzaki discloses using a checkpoint function to capture a state, it
`
`appears that Suzaki does not explicitly disclose that the checkpointing
`
`involves the creation of a new log of uncommitted updates. Beyond
`
`modifying the SWSUSP software, Suzaki does not disclose the specific
`
`implementation details of checkpointing, thus a skilled artisan would have
`
`been motivated to seek out those details. Using a log of uncommitted
`
`updates and creating a memory area to capture writes to a memory are both
`
`a well-known ways to checkpoint data.
`
` For example, one such
`
`checkpointing mechanism is described in Hipp.
`
`46. As explained above, Hipp describes snapshotting
`
`(i.e
`
`checkpointing.) In particular, Hipp describes snapshotting in which a new
`
`log of uncommitted updates is created for each virtual disk in the virtual
`
`machine and a memory area to capture writes to a memory is created, such
`
`that the virtual machine can continue executing.
`
`47.
`
`In Hipp, “[a]ccess to memory and storage [including the virtual
`
`disk] is managed in a copy-on-write fashion.” (Hipp, abstract.) Hipp stores
`
`the changes made to memory and disks in a “application-instance private
`Inter Partes Review of U.S.P. 7,093,086
`2907.020IPR0
`
`
`
`
`location.” Thus, Hipp discloses both a “log of uncommitted updates” and
`
`- 26 -
`
`“a memory area to capture writes.”
`
`48. A skilled artisan would be motivated to include Hipp’s method
`
`of snapshotting to implement the checkpoint function disclosed in Suzaki to
`
`ensure the snapshotting “is transparent to running . . . applications.” (Hipp,
`
`3:47-49.) For example, Suzaki contemplated the need to “save current state
`
`information without stopping the execution of the process.” (Suzaki, p. 5.)
`
`In software development, methods having similar functionality often can be
`
`substituted for one another. Here, both the checkpoint function described in
`
`Suzaki and the checkpoint function described in Hipp provide transparent
`
`checkpointing (or snapshotting) of applications. (Hipp, 3:47-49.) Including
`
`Hipp’s snapshotting method into the checkpoint function disclosed in
`
`Suzaki is merely a substitution of one known element for another to obtain
`
`predictable results. The results are predictable because both methods allow
`
`applications to continue to execute while capturing memory and file state.
`
`In addition, both Suzaki and Hipp disclose OS-level checkpoints.
`
`
`
`
`
`Inter Partes Review of U.S.P. 7,093,086
`
`2907.020IPR0
`
`
`
`XIII. Conclusi