throbber
IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`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

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


Or .

Accessing this document will incur an additional charge of $.

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

Accept $ Charge
throbber

Still Working On It

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

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

throbber

A few More Minutes ... Still Working

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

Thank you for your continued patience.

This document could not be displayed.

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

Your account does not support viewing this document.

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

Your account does not support viewing this document.

Set your membership status to view this document.

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

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

Become a Member

One Moment Please

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

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

Your document is on its way!

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

Sealed Document

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

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


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket