throbber

`
`Patent Owner Symantec Corporation
`Patent Owner Symantec Corporation
`
`Case No. |PR2013-00150
`
`U.S. Patent No. 7,093,086
`
`Case No. IPR2013-00150
`U.S. Patent No. 7,093,086
`
`Hearing: May 5, 2014
`
`1
`
`

`

`‘086 Patent - Challenged Claims
`
`Claim 1: A computer readable medium storing a plurality of instructions comprising
`instructions which, when executed:
`capture a state of a first virtual machine executing on a first computer system,
`(i)
`the state of the first virtual machine corresponding to a point in time in the
`execution of the first virtual machine, wherein the first virtual machine
`comprises at least one virtual disk storing at least one file used by at least one
`application executing in the first virtual machine, and wherein the state of the
`first virtual machine comprises the at least one file; and
`copy at least a portion of the state to a destination separate from a storage
`device to which the first virtual machine is suspendable, wherein suspending
`the first virtual machine is performed responsive to a suspend command.
`
`(ii)
`
`Claim 11: The computer readable medium as recited in claim 1 wherein (i) comprises
`creating a new log of uncommitted updates for each virtual disk in the first virtual
`machine and creating a memory area to capture writes to a memory of the first
`virtual machine, such that the first virtual machine can continue executing during (ii).
`
`2
`
`

`

`“Capture A State Of A First Virtual Machine
`Executing On A First Computer System”
`
`“To create a backup … the
`computer system may capture
`the state in cooperation with a
`virtual machine kernel which
`controls execution of the virtual
`machines, while the machine
`continues to execute” (Col. 2:55-60)
`
`3
`
`

`

`“Capture A State Of A First Virtual Machine
`Executing On A First Computer System”
`
`Backup program makes a
`“request for the current
`state of the virtual machine,
`as would be provided if the
`virtual machine were
`suspended, without actually
`suspending the virtual
`machine” (Col. 11:38-41)
`
`4
`
`

`

`“Capture A State Of A First Virtual Machine
`Executing On A First Computer System”
`
`In response to the image data request, the VM
`kernel 18 may create the "new" COW file 74A
`for each virtual disk (whether persistent or
`non-persistent) in the virtual machine. The new
`COW file 74A may be used for subsequent
`updates to the corresponding virtual disk. In
`this manner, the state of the COW files 74
`(which contain the updates prior to the image
`data request, back to at least the previous
`image data request or suspension of the virtual
`machine) and the virtual disk files 72 may
`remain constant even if the virtual machine
`16A continues to execute, since subsequent
`updates are directed to the new COW files 74A.
`… Therefore, the COW files 74 and the virtual
`disk files 72 may be backed up by the backup
`program 42 without the files being changed
`during the backup. (Col. 11:42-57)
`
`5
`
`

`

`“Copy At Least A Portion Of The State”
`To A Separate Destination
`
`The backup program “cop[ies] the
`virtual machine image data thus
`generated, (i.e. not in response to
`a suspend of the virtual machine
`16A but by collecting the state of
`the virtual machine 16A at a
`given point in time) while the
`virtual machine 16A is allowed to
`continue executing ...” (Col. 12:4-8)
`
`6
`
`

`

`Advantages Of Backing Up “While Executing”
`
`Petitioner’s Expert explains:
`Q. And are there advantages to backing up the virtual machine while it can still be
`executing?
`A. The main advantage is you don't need to suspend the virtual machine. There‘s
`applications that may be executing in the virtual machine do not see any disruption,
`they can continue to execute while the backup is taking place. (Shenoy 1st Dep., 63:12-20, Rep.,
`p. 4; emphasis added)
`
`Patent Owner’s Expert explains:
`•
`“The ability to have the virtual machine continue to execute during this process
`maintains accessibility to the virtual machine and avoids the need to continually
`interrupt the virtual machine”
`“especially helpful when the backup is intended to be performed often and
`periodically for several virtual machines” (Green Resp. Dec., ¶ 49; Resp., p. 14)
`
`•
`
`7
`
`

`

`Backing up “while executing” is
`Challenging/Complex
`
`Petitioner’s Expert admitted:
`
`Q. But one -- but from an implementation standpoint, that would be a
`little bit more difficult than if you would have suspended the virtual
`machine. Am I understanding your testimony correctly?
`* * *
`THE WITNESS: The backup processes -- the backup programs in the two
`scenarios would be clearly different. In the scenario where the virtual
`machine does not need to be suspended the backup program would
`need additional functionality in order to capture the backup state. So it
`would be more challenging or more complex may be a better way to put
`it. (Shenoy 1st Dep., 64:14–65:4; Green Resp. Dec., ¶ 39; Resp., p. 7, 21; emphasis added)
`
`8
`
`

`

`Claim 11 Requires Creating a “New Log Of
`Uncommitted Updates” And A “Memory Area”
`
`The ‘086 Specification explains:
`• A new COW file and memory
`COW are created (Col. 11:42-44; 11:53-62,
`Resp., p. 35, Green Resp. Dec., ¶ 27)
`• For example, disk “updates are
`directed to the new COW file”
`(new log of uncommitted
`updates) (Col. 11:45-46; 12:4-12)
`• The “new log of uncommitted
`updates” and “memory area”
`preserves the state of VM so
`that it can be retrieved and
`copied while the VM continues
`executing (Col. 11:45-52, Rep., p. 3)
`
`9
`
`VM updates
`
`diskupdates
`
`updates
`memory
`
`

`

`Claim 11 Requires Creating a “New Log Of
`Uncommitted Updates” And A “Memory Area”
`
`Petitioner’s Expert explains:
`
`THE WITNESS: So the backup program is trying to make a
`backup without suspending the virtual machine. So in order
`to do that it creates memory COW 112 and it creates a new
`COW file 74A such that all changes that are being made to
`memory go to the memory COW. All changes that are now
`being made to disk go to the new COW file 74A. As a result,
`memory in box 110 and the disk file 72 in the old COW 74
`do not see any new modifications. Those can be used by
`the backup program. (Shenoy 1st Dep., 72:20-73:5, Rep., p. 3; emphasis added)
`
`10
`
`

`

`The ‘086 Patent Discloses Two Different
`Processes to Backup A Virtual Machine
`
`Suspend VM to Capture State
`
`Capture State while VM continues executing
`
`“Suspend
`Virtual
`Machine”
`
`“without
`actually
`suspending
`the virtual
`machine”
`(Col: 11:31-41)
`
`Col. 2:62-65, 3:42-7:37; FIGS. 1-2
`
`Col. 2:56-60; 11:31-14:6; FIGS. 6-8
`
`(Resp., pp. 8-9; Green Resp. Dec., ¶¶ 44-46)
`
`11
`
`

`

`The ‘086 Patent Discloses Two Different
`Processes to Backup A Vitrual Machine
`
`Dr. Shenoy repeatedly testified that the backup process of Figure 2 is
`different than that of Figure 6:
`
`A. Those are two different ways of performing backup. (Shenoy 1st Dep., 63:8-9)
`
`***
`THE WITNESS: The backup processes -- the backup programs in the two scenarios would be
`clearly different. (Shenoy 1st Dep., 64:21-23)
`
`***
`Q. And the distinction you were just making is that the backup program in Figure 1 is going
`to be different than the backup program in Figure 6; correct?
`A. Yes.
`Q. And the reason for that?
`A. In this embodiment the backup program can perform backups without suspending the
`virtual machine. So it has to be a different type of a backup program. (Shenoy 1st Dep., 68:22-
`69:6)
`
`(Rep., p. 4; Green Resp. Dec., ¶ 39; Resp.. p. 7, 21)
`
`12
`
`

`

`Capturing State While The VM Is Executing
`
`Patent Owner’s Expert explains that:
`
`Instead, a skilled artisan would understand that an "executing"
`virtual machine in the sense of the '086 Patent is simply one that
`executes according to the plain language meaning of the term —
`i.e., a machine that continues to perform computation and
`input/output processing in the normal manner that it would if the
`capture/copy procedure were not taking place. This explicitly rules
`out capture procedures that interrupt the machine for non-
`standard operations and durations, i.e., prevent it from operating
`normally.
`
`(Rep., p. 4; Green Rep. Dec., ¶¶ 28-32)
`
`13
`
`

`

`The Prior Art
`
`Rejection Grounds
`
`VMware Refs
`
`•
`
`Lim
`
`• ESX & GSG
`
`• Suzaki
`
`• Suzaki + Wang
`
`§102
`
`§102
`
`§102
`
`§103
`
`Cl. 1, 11, 12 & 22
`
`Cl. 1, 11, 12 & 22
`
`Cl. 1 & 12
`
`Cl. 11 & 22
`
`(Decision, pp. 2-3, 24)
`
`14
`
`

`

`State of the Art
`
`Systems that suspend to
`record state
`
`e.g., VMware (Lim, ESX,
`GSG); Suzaki
`
`Systems that record only a
`portion of VM state
`
`
`ManuallyManually
`
`transferringtransferring
`
`select filesselect files
`
`e.g., VMware (Lim, ESX,
`GSG); Suzaki
`
`Systems that record state
`over a period (not single
`point) of time
`
`e.g., Suzaki
`
`(Resp., p. 7, Green Resp. Dec., ¶¶ 26-40, Green Rep. Dec. ¶ 38, Col. 1:12-67)
`
`15
`
`

`

`Lim (U.S. Patent 6,795,966)
`
`• A VMware reference for
`“checkpointing computer
`systems” (title)
`• Deploys checkpoint to other
`architecturally similar VMs
`(Resp., p. 25, Lim col. 21:44-49, Shenoy 1st Dep.
`128:6-19)
`
`16
`
`

`

`Lim Suspends Operation Of The
`VM To Capture State
`
`•
`
`•
`
`Petitioner states:
`“To capture the state … ‘the [virtual] machine is interrupted and its
`operations suspended (using normal interrupt techniques). (Pet., p. 8)
`“to capture the state of the virtual machine, ‘at the conclusion of a
`particular (virtual) machine instructions, the machine[‘s] …
`operation is suspended … [T]hen … The machine state [is
`extracted]…” (Pet., pp. 10-11)
`• Petitioner admits that “ Lim does not explicitly disclose [that the
`virtual machine can continue to execute during the capturing step] ...
`” (Opp., p. 11)
`
`Petitioner’s Expert states:
`A. Yes. So there are two embodiments. In both cases, you need to
`interrupt the virtual processor. (Shenoy 2nd Dep., 39:19-21, Obs. 3)
`
`17
`
`

`

`Lim Suspends Operation Of The
`VM To Capture State
`
`The virtual machine monitor is then
`used as a checkpointing mechanism a)
`for interrupting the virtual processor;
`b) for sensing a checkpoint request for
`the virtual machine; and c) for
`generating at least one checkpoint,
`each checkpoint comprising a list of the
`total state of the virtual machine” (Col.
`6:45-52, emphasis added)
`
`18
`
`

`

`Lim Doesn’t Disclose The Claimed “New Log
`Of Uncommitted Updates Or Memory Area”
`
`Petition states:
`By disclosing the creation of change vectors, Lim discloses creating a new log of
`uncommitted updates as claimed.
`(Pet., p. 14)
`
`•
`
`Lim still requires interruption (i.e., suspension) in order to capture state by
`“construct[ing] the state change vector.” (Lim 25:5-9, Resp., p. 40, Green Mot. Dec., ¶ 154)
`
`Dr. Shenoy admits that Lim does not expressly disclose that the VM “can continue
`executing during [copy step] (ii)”
`Q. So the answer is, it's possible for Lim to transmit the vector while the virtual machine is
`interrupted, correct?
`A. Since, as we've just discussed, Lim is silent on what is happening when the virtual machine
`state is being transferred, it is certainly possible for the virtual machine to be interrupted. I
`also say it's possible when the virtual machine is not running, and could be running. I mean,
`all of those possibilities could be true, because it's silent on that matter. (Shenoy 2nd Dep., 58:18-
`61:16; 61:5-16; Resp., p. 40, Obs. 4)
`
`19
`
`

`

`Lim’s COW Techniques Reduce The Size Of The Saved State Vector
`But Don’t Allow The Machine To Execute During The Copy Step
`
`Dr. Shenoy states:
`“the state can include a lot of data, so to increase efficiency, Lim describes
`using copy-on-write techniques such that ‘only updates to the state vectors
`from checkpoint to checkpoint need be stored.’ (Lim, 19:59-61.)” (Shenoy Opp. Dec., ¶
`18)
`
`“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.)” (Shenoy Opp. Dec., ¶ 19)
`
`“Because memory may contain a lot of data, Lim describes using copy-on-
`write techniques to increase efficiency.” (Shenoy 1st Dec., ¶ 19)
`
`20
`
`

`

`VMWare – ESX and GSG References
`
`Describes VMware products for creating and maintaining virtual machines
`executing on a VM kernel
`
`21
`
`

`

`ESX and GSG Suspend Operation of VM
`
`Petitioner states:
`“The ESX server software has a
`suspend that ‘save[s] the current
`state of the virtual machine.’
`(VMware ESX, p. 149)” (Pet., p. 17)
`
`Petitioner’s Expert states:
`“When a virtual machine is
`suspended, its state is written to a
`file with a .std extension.’ (VMware
`ESX, p. 97)” (Shenoy 1st Dec., ¶ 23)
`
`22
`
`

`

`ESX and GSG Suspend Operation of VM
`
`Petitioner states:
`“In VMware GSG, ‘[u]sing Suspend
`and Instant Restore… [y]ou can save
`the current state of your virtual
`machine.’ (VMware GSG, p. 2-5).”
`(Pet., pp. 22-23)
`
`Petitioner’s Expert states:
`“VMware GSG describes how state
`information is saved to disk when
`the virtual machine is suspended.”
`(Shenoy 1st Dec., ¶ 28)
`
`23
`
`

`

`ESX and GSG’s Redo Log File Continuously
`Change During Execution Of VM
`
`Petitioner states:
`
`“the ESX server captures changes intended to be made to the virtual disk
`during a "working session" in a REDO log: "Append mode [] stores changes in
`a redo log. It continually adds changes to the redo log”
`
`With respect to GSG, Petitioner states:
`
`“Writes 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”
`
`(Pet., p. 17 citing to ESX, 24 citing to GSG;
`Exhibits 1005, 1006)
`
`24
`
`

`

`ESX and GSG’s Redo Log File Does Not
`Capture State At A “Point In Time”
`
`Dr. Green explains:
`
`However a person of ordinary skill in the art would also understand
`that a filesystem does not capture all of the state related to a Virtual
`Machine or an application running thereon. A person of such skill
`would recognize that the state of an application running in VMware
`GSG is contained both dually within memory (stored in the
`computer’s RAM), as well as the filesystem of a virtual disk (stored
`on a physical disk drive). The ‘redo’ log cited by Veeam and Dr.
`Shenoy only stores a fraction of this information, i.e., disk state.
`Most critically, this disk information does not correspond to a
`point in time in the VM’s execution. Also, there is no indication
`given in VMware GSG that this state is sufficient to resume the
`application or Virtual Machine.
`
`(Resp., pp. 28, 30-31, 33, Green Resp. Dec., 30-31, 46-47, 92; emphasis added)
`
`25
`
`

`

`ESX & GSG’s Redo Log File Allows A User To Work
`On A Virtual Machine In A Non-Persistent Mode
`
`‘086 Patent’s claimed “new log of
`uncommitted updates”
`
`ESX/GSG redo-log file enables VM to
`operate in “non-persistent” mode (col.
`6:58-62, ESX, p. 58; GSG, pp. 2-5; Resp., pp.
`30, 33, Resp. Dec., ¶¶ 30-31)
`
`In response to the image data request, the
`VM kernel 18 may create the “new ” COW
`file 74A for each virtual disk (whether
`persisten or non-persistent) in the virtual
`machine. (Col. 11:41-45)
`
`(Resp., pp. 34-35, 38-39, Green Resp. Dec. 73-76, 101-103, Obs. 2, 6, Shenoy 1st Dep., 72:20-73:5)
`
`26
`
`

`

`Suzaki
`
`“A system that makes it possible to continue
`working at home without physically bringing
`a computer from your office.”
`
`(Suzaki, p. 2)
`
`27
`
`

`

`Suzaki Requires Suspension To Save State
`
`Petitioner states:
`
`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 "[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. (Pet., p. 32)
`
`Petitioner’s Expert states:
`
`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).) (Shenoy 1st Dec., ¶ 33)
`
`28
`
`

`

`Suzaki Describes Gradual Checkpointing Of
`Individual Applications (Resp. Dec. 124)
`
`Patent Owner’s Expert explains that Suzaki does not capture state of an entire
`VM at ‘a point in time’:
`
`In simplified terms, the Suzaki process separately halts applications and writes their
`state to disk, followed by the state of the operating system itself. There is no
`indication in Suzaki that the entire system is suspended at a point in time.
`Instead, Suzaki appears to gradually suspend individual applications and then
`subsequently the operating system itself. In other words, as the operating system
`captures state of a particular application, the virtual machine keeps running and
`SWSUSP itself continues changing the state of the system. If the state of another
`application or the operating system is captured, it would be at a different point in
`time and the state would have changed. This approach — which closely resembles
`many of the prior references cited in the '086 patent — can lead to inconsistencies
`in the resulting suspended image. In practice, this can lead to inconsistencies in the
`backup, where some details of the virtual machine are inconsistent, e.g., between
`different applications, or between different applications and the operating system.
`The end result is a virtual machine image that may not accurately reflect machine
`state, or could include corrupt or duplicate data in different locations.
`
`(Resp. Dec., ¶ 127, Resp., pp. 47-49)
`
`29
`
`

`

`Suzaki + Wang:
`Still Lack Material Claim Limitations
`
`• Petitioner admits that Suzaki does not disclose a “new log of
`uncommitted updates for each virtual disk” (Pet., p. 34)
`• Wang’s “UNDO log”
`• tracks “committed” NOT “uncommitted” updates; and
`(Resp. , pp. 57-58; Green Resp. Dec., 154)
`• pertains to a single application and not for an entire
`“virtual disk” (Resp., pp. 58-59; Green Resp. Dec., 154)
`
`30
`
`

`

`POSITA Would Not Have
`Combined Suzaki With Wang
`
`One would not have combined Suzaki’s non-transactional OS with Wang’s transactional log.
`
`“Dr. Shenoy cites Wang et al., and argues that a person of ordinary skill in the art
`would combine Suzaki’s invention with Wang et al.’s transaction logging to show
`the features of the Challenged Claims. This is not so. One challenge with such a
`system is to identify precisely which portions of the disk comprise the state of
`the Virtual Machine at a specific point in time, and which portions represent
`blocks that are likely to be modified by a still-running virtual machine (and
`hence avoid copying these blocks). This requires the copying process to have
`detailed knowledge about the precise contents of the Virtual Disk and page files.
`However no mechanism is provided in Suzaki or Wang et al. to deliver this
`information to the mechanisms that copy VM state from one location to another.
`Moreover, it would not be apparent to one of ordinary skill in the art how this
`could be done because the Wang et al. transaction logs are implemented within
`individual applications running on the virtual machine and no interface is
`provided for communicating these details to a backup program such as SWSUSP.
`Moreover, this interface would need to be implemented consistently across all
`running applications. Developing a functioning system for coordinating many such
`applications running individual transaction logs is a challenging problem, and to
`my knowledge no virtual backup system has succeeded in solving it.” (Green
`Resp. Dec., ¶ 144; Resp., pp. 54-55; emphasis added)
`
`31
`
`

`

`POSITA Would Not Have
`Combined Suzaki With Wang
`
`One would not have known how to modify Suzaki’s OS, which would
`require a substantial undertaking to attempt to combine with Wang
`
`•
`
`•
`
`“An alternative could be to modify Suzaki’s operating
`system to accommodate Wang et al.’s transactional
`logs. However, in my opinion, incorporating Wang et
`al.’s transactional logs would require a substantial
`modification or redesign of Suzaki’s operating system
`(Linux).”
`“These challenges do not arise in the Suzaki invention,
`as the checkpointing process treats the VM swap file as
`an opaque and fixed (non-changing) data store that can
`simply be “copied and pasted” into a new location.
`Thus, in my opinion, it would not have been obvious
`how one would cleanly integrate Wang et al.’s internal
`transaction logging process with the system described
`by Suzaki.” (Resp. Dec., ¶ 145-146; Resp., pp. 55-57; emphasis
`added)
`
`32
`
`

`

`POSITA Would Not Have
`Combined Suzaki With Wang
`
`Suzaki’s disclosure is sufficient to implement the checkpointing function.
`
`“While Suzaki does not specify every aspect of the checkpointing
`process, the unspecified portions represent mundane engineering
`details. For example, given the description above as well as the
`extant operating systems and tools such as, one could presumably
`re-implement every single aspect of the invention by extending
`SWSUSP to identify the dirty pages in memory and place them on
`the disk. While the precise details of such a re-implementation
`might be subtly different from that of Suzaki (for example, the order
`of copying the pages from memory to disk might differ), the
`resulting invention would be in every meaningful sense the same. A
`person of ordinary skill in the art would be more than capable of
`working out such routine details without undue experimentation.
`Thus the checkpointing function of Suzaki is complete and
`specified: a skilled artisan would see no need to seek out any other
`implementation details, much less import exotic functionality such
`as Wang et al.’s transactional logs.” (Resp. Dec., ¶ 153; Resp., pp. 52-53;
`emphasis added)
`
`33
`
`

`

`Motion to Amend – Substitute Claim 31
`
`Claim 31 (substitute for claim 1): A computer
`readable medium storing a plurality of
`instructions comprising instructions for a backup
`program which, when executed, interfaces with a
`separately executing virtual machine kernel to:
`
`(i)
`
`capture a state of a first virtual machine
`executing on a first computer system, the
`state of the first virtual machine
`corresponding to a point in time in the
`execution of the first virtual machine, wherein
`the first virtual machine comprises at least
`one virtual disk storing at least one file used
`by at least one application executing in the
`first virtual machine, and wherein the state of
`the first virtual machine comprises the at least
`one file; and
`(ii) copy at least a portion of the state to a
`destination separate from a storage device to
`which the first virtual machine is suspendable,
`wherein suspending the first virtual machine
`is performed responsive to a suspend
`command.
`
`(see also Col. 11:32-40; 12:61-13:21, Mot., p. 4, Rep., p. 2)
`
`34
`
`

`

`Motion to Amend – Substitute Claim 33
`
`Claim 33 (substitute for claim 12):
`Added Features:
`• … , wherein the first virtual machine
`can continue executing during
`capture and copy steps;
`• determine whether additional virtual
`machines that have not been backed
`up are present on the first computer
`system; and
`• Repeat capture and copy steps for
`said additional virtual machines
`
`“without
`actually
`suspending the
`virtual
`machine”
`(Col: 11:31-41)
`
`“while the
`virtual
`machine 16°
`is allowed to
`continue
`executing”
`(Col: 12:4-12)
`
`35
`
`

`

`Motion to Amend – Substitute Claims
`
`36
`
`VM updates
`
`diskupdates
`
`updates
`memory
`
`•
`
`•
`
`Claim 32 (substitute for claim 11): The computer readable
`medium as recited in claim 1 wherein (i) comprises creating a
`new log of uncommitted updates for each virtual disk in the
`first virtual machine and creating a memory COW area to
`capture writes to a memory of the first virtual machine, and
`wherein the instructions, when executed, write updates
`subsequent to (i) to each virtual disk in the first virtual
`machine to the new log and write updates subsequent to (i)
`to the memory of the first virtual machine to the memory
`COW area during execution of the first virtual machine, such
`that the first virtual machine can continue executing during (i)
`and (ii).
`
`Claim 34 (substitute for claim 22): The apparatus as recited in
`claim 12 33 computer readable medium as recited in claim 1
`wherein (i) comprises creating a new log of uncommitted
`updates for each virtual disk in the first virtual machine and
`creating a memory COW area to capture writes to a memory
`of the first virtual machine, and wherein, subsequent to (i),
`the first computer system is configured to write updates to
`each virtual disk in the first virtual machine to the new log
`and write updates to the memory of the first virtual machine
`to the memory COW area during execution of the first virtual
`machine such that the first virtual machine can continue
`executing during (ii).
`
`

`

`State Of The Art
`
`Techniques that require
`suspension/interruption to record state
`
`e.g., VMware (Lim, ESX, GSG); Suzaki; Li
`
`Techniques that record only
`a portion of VM state
`
`e.g., VMware (Lim, ESX,
`GSG); Suzaki; Li
`
`
`Manual, time-Manual, time-
`
`consumingconsuming
`
`processes toprocesses to
`
`record and/orrecord and/or
`
`copycopy
`
`Systems that record state
`over a period (not single
`point) of time
`
`e.g., Suzaki; Li
`
`Backup ‘agents’ (custom code)
`for each application
`
`Resp., p. 7, Mot., pp. 13-15, Green Mot. ¶¶ 26-50, Green Rep. Dec. ¶ 38, Col. 1:12-67
`
`37
`
`

`

`Li Reference
`
`“This short note presents
`four algorithms for
`checkpointing and restarting
`parallel programs running on
`shared-memory
`multiprocessors.” (Li, p. 874)
`
`38
`
`

`

`Li Freezes The Operation Of The Computer
`
`The copy-on-write checkpointing
`algorithm works as follows: First,
`it freezes the processors and
`copies their CPU states to the
`separate address space. Also, it
`sets the page protection bits of all
`pages in main memory to be
`“read-only.” Next it unfreezes the
`processors and starts a separate
`copier thread that copies pages to
`the new address space and rests
`the pages protection to “read-
`write.” (Li, p. 875)
`
`39
`
`

`

`Li Freezes The Operation Of The Computer
`
`• Petitioner admits that neither ‘Lim’ nor ‘Lim + Li’ allow the
`virtual machine to continue executing during the capture
`step.
`
`(Opp., p. 11)
`
`• Petitioner’s Expert acknowledged that Li’s process does
`NOT store updates in the new address space. (Li, p. 875, Green Rep.
`Dec., ¶¶ 15-20, Shenoy 2nd Dep., 116:3-117:1, Rep., p. 4)
`
`40
`
`

`

`Li Records The State Of An Application
`
`Dr. Green explains that:
`
`•
`
`Li is an “application
`checkpointing mechanism”
`Like Hipp, Li ignores state
`information
`(Green Rep. Dec., ¶¶ 22-23, Rep., p. 5)
`
`•
`
`41
`
`

`

`POSITA Would Not Have
`Combined Lim With Li
`
`Dr. Green explains that one would not perform Li’s checkpointing
`process on Lim’s monitor; Li cannot capture state needed for Lim’s VM.
`
`“it does not follow that the techniques of Li would be applied to a
`virtual machine monitor solely because the latter “is a process”.
`Indeed, the Lim patent does not describe applying its checkpointing
`techniques to the virtual machine monitor at all, but rather, it
`describes capturing state of the virtual machine itself. The
`difference is that the virtual machine monitor is a software
`component of the VM kernel that is responsible for executing and
`providing a hardware interface for virtual machines. Lim, col. 15-17.
`Performing the Li checkpoint on the virtual machine monitor
`would be unusual, since the monitor will likely contain
`substantially more state than just the memory of the virtual
`machine. Moreover, since virtual machine monitors frequently
`reference external state maintained by an operating system or
`kernel, such as file pointers and hardware states, Li’s techniques
`would not be appropriate and the state captured would not be
`sufficient to resume the virtual machine. Li, p. 876.” (Green Rep.
`
`Dec., 25;Dec., 25; Rep., p. 5)
`
`42
`
`

`

`POSITA Would Not Have
`Combined Lim With Li
`
`Dr. Green explains that POSITA would not have incorporated Li’s
`COW techniques into Lim’s VM checkpointing process:
`
`“Because Li ignores states common to virtual machines, it is my
`opinion, that one of ordinary skill would not have looked to the
`Li reference to incorporate COW memory areas into virtual
`machines. Also, one of ordinary skill would not have consulted
`Li in order to learn how to keep a virtual machine executing
`during capture and copy of its state, because these solutions
`require suspension of the checkpointed program or process.”
`(Green Rep. Dec., ¶ 44; Rep., p. 5)
`
`43
`
`

`

`POSITA Would Not Have
`Combined Lim With Li
`
`Dr. Green explains that one would not implement Li’s checkpointing
`process requiring a specific type of multi-processor computers to Lim’s
`hardware-independent process.
`“it is important to point out that one of ordinary skill in the art
`would not necessarily have been motivated to implement a
`process that reduces the interruption time, if the cost of
`implementing said process was to limit the invention to only
`working on specific multi-processor computers, while also
`explicitly excluding the use of file pointers and other critical
`operating system or kernel state. Lim specifically notes that the
`invention should be independent of the hardware used. Lim, col.
`6:4-21, col. 16:62-64. Moreover, even when multiple processors
`are available, Li’s techniques would only reduce the interruption,
`not eliminate it. Nor would it even reduce the interruption to a
`level that is comparable with the various routine interruptions
`that occur during normal program execution (see Section VII).
`The ‘086 Patent, on the other hand, does not require such
`interruption regardless of whether a single or several processors
`are used.” (Green Rep. Dec., ¶ 26; Rep., p. 5)
`
`44
`
`

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