IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`VEEAM 1030
`Veeam v. Symantec
`Case No: IPR2013-00150
`
`
`In re inter partes review of:
`U.S. Patent 7,093,086 to Hans van
`Rietschote.
`Filed: February 14, 2013
`
`For: Disaster Recovery and Backup
`using Virtual Machines
`
`Case Nos. IPR2013-00150
`Atty. Docket: 2907.020IPR0
`
`
`
`
`
`
`Declaration of Dr. Prashant Shenoy in Support of Petitioner’s Reply
`
`
`
`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 proceedings. I understand that these proceedings involve 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.
`
`An updated version of my Curriculum Vitae is attached as Appendix
`
`A to this Declaration, 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.
`
`3.
`
`I understand that the Board instituted inter partes review of claims 1,
`
`11, 12, and 22 of the ’086 Patent on 5 separate grounds. I have reviewed, and I am
`
`familiar with all of the prior art supporting those grounds, as well as the Board’s
`
`Decision on Institution. The grounds of rejection instituted by the Board include
`
`the following:
`
`4.
`
`Claims 1, 11, 12, and 22 are anticipated by Lim et al (“Lim”)
`
`(provided at VEEAM 1004).
`
`5.
`
`Claims 1, 11, 12, and 22 are anticipated by the “VMware ESX Server:
`
`User’s Manual” (“ESX”) (provided at VEEAM 1005).
`
`6.
`
`Claims 1, 11, 12, and 22 are anticipated by “Getting Started Guide:
`
`VMware 2.0 for Linux,” (“GSG”) (provided at VEEAM 1006).
`
`7.
`
`Claims 1, 11, 12, and 22 are anticipated “Checkpoint for Network
`
`Transferable Computer” by Suzaki (“Suzaki”) (English translation provided at
`
`VEEAM 1008).
`
`
`Case: IPR2013-00150
`
`
`
`
`– 2 –
`
`
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`Claims 11 and 22 are obvious over Suzaki in view of “Integrating
`
`8.
`
`Checkpointing and Transaction Processing,” by Wang (“Wang”) (provided at
`
`VEEAM 1010).
`
`9.
`
`I also understand that the Patent Owner has submitted a response
`
`(“Response”) in opposition to the petition filed in February 2013. I have reviewed
`
`the Response as well as Dr. Green’s (Patent Owner’s expert) declaration in support
`
`of the Response, including substitute exhibit C (“Green Dec.”) and his deposition
`
`transcript (“Green Tr.”). I have been asked to provide my technical review,
`
`analysis, and insight regarding the Response and corresponding opinions of Dr.
`
`Green.
`
`The Capture of State While a Virtual Machine is Executing
`
`10.
`
`I understand that both Patent Owner and Dr. Green contend that
`
`claims 1 and 12 require the virtual machine to be executing during the capturing
`
`step. (Response, p. 12; see also Green Dec., ¶¶ 47-49.) I also understand that the
`
`Dr. Green and Patent Owner further contend that state must include both the
`
`contents of memory, hardware state (including the processor state), and
`
`configuration information. (Response, p. 27; see also Green Dec., ¶ 40.) I don’t
`
`agree that the broadest reasonable interpretation of claims 1 and 12 requires that
`
`
`Case: IPR2013-00150
`
`
`
`
`– 3 –
`
`
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`the captured state include the contents of the memory, hardware state (including
`
`processor state), and configuration information because the specification only
`
`describes that state “may” include these items, and the plain language of the claims
`
`only requires the state to include “at least one file.” (’086 patent, 4:28-33; see also
`
`claims 1 and 12.) However, if the Board were to adopt these positions, it is my
`
`opinion that the virtual machine still must be suspended to capture state, at least
`
`temporarily, even for the embodiments in the ’086 patent that involve capturing
`
`state while the virtual machine is executing.
`
`11. Processors typically include a number of memory storage areas
`
`known as registers. (See Green Tr., 237:6-10.) The registers are responsible for
`
`holding data used for processing instructions on the processors, among other
`
`things. Thus, to capture state of a processor one must also capture the state of the
`
`registers. As Dr. Green explained during his cross-examination, processors have
`
`more than one register, and the registers are constantly being changed based on the
`
`current instruction or instructions that are being executed by the processor. (Green
`
`Tr., 254:13-18.) It naturally follows that to capture state one must stop, at least
`
`momentarily, a register from being updated while it is being “captured,” or else the
`
`data could be inconsistent.
`
`
`Case: IPR2013-00150
`
`
`
`
`– 4 –
`
`
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`Instructions typically require at least one register in the processor for
`
`12.
`
`execution, and typically require many. Thus, if an instruction is being executed on
`
`the processor, one would have to capture numerous registers at once, or possibly
`
`all registers to ensure consistency of the processor state because it is very difficult
`
`to determine which registers are currently being used on the processor. This takes
`
`time, and in the meantime, the processor (i.e. virtual processor) would have to be
`
`suspended from execution until all the registers are copied.
`
`13. During his cross-examination Dr. Green explained that one could
`
`capture the processor registers using similar techniques to those that the ’086
`
`patent describes for capturing memory in some of its embodiments. (Green Tr.,
`
`255:3-17.) In other words, one could create a separate area to hold new updates to
`
`the registers. But, creating such an area also takes time, and in the meantime,
`
`updates must be suspended to the processor until the new “area” is created or an
`
`inconsistent state is created on the processor. Further even if such an area were
`
`preallocated (i.e. created before the capture began), the process of instructing the
`
`virtual machine to redirect its updates to the new area also takes a period of time,
`
`during which the virtual machine could not execute.
`
`
`Case: IPR2013-00150
`
`
`
`
`– 5 –
`
`
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`14. The same issues hold true if one were to capture memory contents of a
`
`running virtual machine. For example, with respect to capturing memory contents
`
`while the virtual machine is executing, certain embodiments of the ’086 patent
`
`describe creating a new area in memory to hold updates to the memory. But
`
`creating such an area or setting up redirection of updates to it also takes time, and
`
`during that time period no writes to memory can be occurring or else a consistent
`
`view of memory cannot be captured.
`
`Lim
`
`15. Lim describes capturing the total machine state of a virtual machine as
`
`part of a checkpointing process. Specifically, to capture the state of the virtual
`
`machine, the “[S]tate extraction . . . extracts the machine state and saves it in
`
`storage . . . as the initial checkpoint S0.” (Lim, 18:5-8.)
`
`16. Lim describes its total machine state as “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:26-30 (emphasis added).) I understand that Patent Owner
`
`argues that Lim’s “total machine state” does not include configuration information.
`
`First, it is my opinion that nothing in the ’086 patent limits the broadest reasonable
`
`
`Case: IPR2013-00150
`
`
`
`
`– 6 –
`
`
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`interpretation of state to including configuration information. In fact, despite the
`
`’086 patent describing a laundry list of items that "may" be part of state, the ’086
`
`patent never describes capturing "configuration information" as part of state. (’086
`
`patent, 4:28-33.) Regardless, Lim also describes capturing such configuration
`
`information.
`
`17.
`
`In order for Lim to “uniquely determine the status of all hardware . . .
`
`components,” Lim must have information regarding the type of hardware. For
`
`example, to capture the state of a processor, Lim’s capturing process would need to
`
`know the number of processors in the virtual machine, and their type. As Dr. Green
`
`explained, this type of information is found in the configuration information.
`
`(Green Tr., 258:20-24.) Therefore, because “total machine state” includes “the
`
`entire collection of all information that is necessary and sufficient to uniquely
`
`determine the status of all hardware,” and configuration information is required to
`
`determine the status of all hardware, it is my opinion that Lim’s state includes
`
`“configuration information.”
`
`18. After the state is captured, Lim describes that the state can be copied
`
`to a separate destination over a network: “[T]he state vector of a first virtual
`
`machine VM1 . . . could be transferred over any conventional transmission
`
`
`Case: IPR2013-00150
`
`
`
`
`– 7 –
`
`
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`medium to any other architecturally similar virtual machine VM2 and loaded into
`
`that virtual machine as its initial state. . . .” (Lim, 21:44-49.) By transmitting state
`
`information over a network to a remote destination, Lim discloses copying state
`
`information to a separate storage device.
`
`19. Lim discloses creating a log of uncommitted updates for keeping track
`
`of changes while the virtual machine is executing with the express purpose of
`
`using the log for capturing state. Lim explains that “[i]n the preferred embodiment
`
`. . . , only 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-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.) 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.
`
`
`Case: IPR2013-00150
`
`
`
`
`– 8 –
`
`
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`I understand that Patent Owner and Dr. Green contend that the
`
`20.
`
`“memory area” recited in claims 11 and 22 must correspond to the ’086
`
`specification’s description of “memory COW 112.” (Response, p. 36.) I do not
`
`agree that this is the broadest reasonable interpretation of the claims. But, even if
`
`the Board were to adopt Patent Owner’s narrow construction of “memory area,”
`
`Lim discloses creating memory areas for the express purpose of capturing the
`
`contents of memory using copy-on-write (COW) techniques. Indeed, the memory
`
`areas disclosed in Lim are for storing updates to memory as the virtual machine
`
`continues to execute after a checkpoint.
`
`21. 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.) But 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.) One way Lim describes of accomplishing copy-on-write
`
`is by creating a log of changes: “rather than storing the entire system state at both
`
`the beginning and end of a transaction, a log can be kept of changes to the
`
`computer system state, that is, of any changes to any of the elements of S0,” which
`
`includes the contents of memory because S0 is the total machine state. (Lim,
`
`Case: IPR2013-00150
`
`
`
`
`– 9 –
`
`
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`11:50:54.) In other words, after a checkpoint, subsequent updates that occur while
`
`the virtual machine is executing are stored in a separate log of changes.
`
`22. The log of changes can be stored in memory, and thus constitute a
`
`memory area: “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.) Therefore, since the state
`
`vectors 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” for the express purpose of performing copy-on-write.
`
`23.
`
`I also do not agree with Dr. Green and Patent Owner’s assertion that
`
`the claims 11 and 22 require the virtual machine to be executing during the
`
`copying step. (Response, p. 41; see also Green, ¶¶ 110-115.) Claims 11 and 22
`
`recite “creating a memory area . . . such that the first virtual machine can continue
`
`executing during (ii) [i.e. the copying step].” (’086 patent, claims 11 and 22
`
`(emphasis added).) I place emphasis on the word “can,” because “can” is viewed as
`
`permissive to those having ordinary skill in the art. Thus, it is my opinion that a
`
`person of ordinary skill in the art would find that the broadest reasonable
`
`interpretation of claims 11 and 22 does not actually require the virtual machine to
`
`
`Case: IPR2013-00150
`
`
`
`
`– 10 –
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`be executing, but merely only have the ability to execute. Further, because claims
`
`11 and 22 only limit this “ability” to the copying step, the broadest reasonable
`
`interpretation of claims 11 and 22 requires that the virtual machine have such an
`
`ability to execute during the copying step, and not necessarily during any other
`
`steps.
`
`24. Therefore, Lim discloses that the virtual machine can continue
`
`executing during the copying. For example, 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.
`
`ESX
`
`25. ESX is a product manual for a virtual machine monitor product by
`
`VMware. (ESX, p. 8.) ESX explicitly discloses “a new log of uncommitted
`
`updates” and “creating a memory area to capture writes to memory.” In fact, the
`
`ability to store disk updates in separate files such as redo logs and allocate memory
`
`
`Case: IPR2013-00150
`
`
`
`
`– 11 –
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`as part of an executing virtual machine have long been features common to virtual
`
`machine products such as ESX and VMware workstation prior to the invention of
`
`the ’086 patent.
`
`26.
`
`I understand that Patent Owner contends that because ESX’s redo log
`
`stores “changes,” it does not “permit the virtual machine to resume execution of
`
`the application,” as required by the Board’s construction of “state.” (Response, pp.
`
`17-28.) I disagree. 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.) As a result, any files that are changed while a redo log is
`
`active will be placed in the redo log. Depending on the application, this may be
`
`enough to resume execution of the application. For example, if the application is
`
`the well-known Microsoft Notepad application, merely saving the currently open
`
`file in the redo log would be enough to permit the Windows Notepad application to
`
`resume execution at the point-in-time of the capture, as all it needs is the file.
`
`27.
`
`I also understand that Patent Owner contends in the co-pending
`
`District court litigation that any executing virtual machine creates “memory areas”
`
`because they allocate memory. (Infringe. Contentions, p. 12.) I agree with Patent
`
`
`Case: IPR2013-00150
`
`
`
`
`– 12 –
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`Owner that this is the broadest reasonable interpretation of the claimed “creating a
`
`memory area” in claims 11 and 22. ESX explicitly explains describes that it
`
`allocates memory: “VMware ESX Server provides dynamic control over the
`
`amount of physical memory allocated to each virtual machine.” (ESX, p. 114.)
`
`Therefore, it is my opinion that ESX creates the claimed “memory area.”
`
`28.
`
`I also understand that Patent Owner contends that the ESX redo log is
`
`not the claimed “new log of uncommitted updates” because it is not “new” and
`
`because it is allegedly different then a described embodiment of a “COW file
`
`74A.” (Response, pp. 34-35.) I do not agree. A person of ordinary skill in the art
`
`would not consider the broadest reasonable interpretation of the “new log of
`
`uncommitted updates” to be limited to any particular implementation of a COW
`
`file or redo log.
`
`29. As I understand Patent Owner’s contention, they argue that the ESX
`
`redo log is similar to the ’086 patent’s description of a non-persistent disk’s COW
`
`file, and thus is not the claimed “log of uncommitted updates.” (Response, pp. 34-
`
`35.) But, I note that claim 9 refers to the COW file created with non-persistent
`
`disks, as a “log of uncommitted updates.”
`
`
`Case: IPR2013-00150
`
`
`
`
`– 13 –
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`I also disagree with Patent Owner’s characterization that ESX’s redo
`
`30.
`
`logs are not “new” logs. (Response, p. 35.) If a disk is set to nonpersistent mode,
`
`each time the virtual machine is booted, a new redo log is created. For example,
`
`ESX explains that if a disk is set to nonpersistent, “All changes . . . are discarded
`
`when a virtual machine session is powered down.” (ESX, p. 39.) Thus, once the
`
`virtual machine is powered up again, a new redo log is created to store the changes
`
`for that session. Similarly, if a disk is set to append mode, after the changes are
`
`committed, a new log is created to store on-going changes. (See id.)
`
`31. Finally, I disagree with Patent Owner and Dr. Green’s contention that
`
`ESX’s redo logs cannot be copied while the virtual machine is executing.
`
`(Response, p. 37; see also Green Dec., ¶ 85.) I have reviewed Dr. Green’s
`
`substitute1 Exhibit C titled “Cloning and converting virtual disks with vmkfstools
`
`(1028042),” which describes later versions of the vmkfstools utility than what was
`
`included with ESX 1.0. (See VEEAM 1028.) Dr. Green and Patent Owner
`
`apparently conclude that because a newer version of ESX server’s vmkfstools
`
`software apparently describes that a redo log cannot be copied when the virtual
`
`
`1 Dr. Green erroneously included the wrong Exhibit C in his report. I
`understand that Patent Owner has since asked the Board to substitute the correct
`exhibit. I have provided what I believe was the original exhibit Dr. Green intended
`to include at VEEAM 1028.
`
`Case: IPR2013-00150
`
`
`
`
`2907.020IPR0
`
`
`
`
`– 14 –
`
`
`
`
`
`

`
`
`machine is executing, that implies that a different version described in ESX 1.0
`
`cannot do so. (Response, p. 37-38; Green Dec., ¶¶ 80-85.) But whether or not a
`
`newer version of vmkfstools can copy a redo log while the virtual machine is
`
`executing is of no relevance to the version described in the ESX 1.0 user manual.
`
`In fact, the ESX 1.0 user manual never describes such a limitation: “Using the
`
`vmkfstools program, “[t]he contents of the redo log can be copied to the file
`
`system of the console operating system using the exportraw command.” (ESX, p.
`
`106.) Further, because the newer version explicitly describes the vmkfstools utility
`
`as not being able to copy while the virtual machine is executing, but the ESX 1.0
`
`version does not, leads one to conclude that vmkfstools under ESX 1.0 could copy
`
`while the virtual machine is executing, not the opposite, as Dr. Green and Patent
`
`Owner conclude.
`
`32. Regardless of whether vmkfstools under ESX 1.0 can or cannot copy
`
`a redo log while the virtual machine is executing, ESX 1.0 still describes that the
`
`redo log can be copied while the virtual machine is executing. ESX explains that
`
`after using the vmkfstools program to copy “[t]he contents of the redo log . . . to
`
`the file system of the console operating system . . . . The redo log can then be
`
`transported to a remote site and copied to the SCSI disk . . . .” (ESX, p. 106
`
`(emphasis added).) The console operating system is a separate entity from, and
`
`
`Case: IPR2013-00150
`
`
`
`
`– 15 –
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`executes concurrently with, the virtual machines executing on the virtual machine
`
`host. Thus, even under Patent Owner’s assumption that the virtual machine must
`
`be suspended while the redo log is copied to the console operating system using
`
`vmkfstools, after the vmkfstools copying is complete, the virtual machine can be
`
`either restarted or resumed. At this point, or any point after the vmkfstools
`
`completes its copying, “[t]he redo log can then be transported to a remote site and
`
`copied to the SCSI disk.” (ESX, p. 106.) This could be accomplished with any of
`
`the well-known copying tools that Dr. Green explained a person of ordinary skill in
`
`the art would have known about at the time of the ’086 invention. (Green
`
`Tr.,37:14-20;39:7-41:3.)
`
`Getting Started Guide
`
`33.
`
`I understand that Dr. Green and Patent Owner contend that GSG’s
`
`description of intercepting disk writes and storing them in a redo log file does not
`
`constitute two steps of capturing and copying. (Response, pp. 43-44; Green Dec., ¶
`
`98.) I disagree. GSG explains that REDO logs appear as normal disks to software
`
`running in a virtual machine: “All writes to an undoable disk issued by software
`
`running inside the virtual machines appear to be written to the disk, but are in fact
`
`stored in a temporary file (.REDO).” (GSG, 4-2.) In other words, the VMware
`
`
`Case: IPR2013-00150
`
`
`
`
`– 16 –
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`workstation software intercepts writes unbeknownst to the software running in the
`
`virtual machine and redirects them to the redo log file instead of the disk file.
`
`34. For the VMware workstation software to intercept the data intended to
`
`be written disks, the data naturally must first be stored in a different location than
`
`the disk or it would defeat the purpose of redirecting the writes to the redo log file.
`
`That is, if the data were first written to disk before being written to the redo log, it
`
`would defeat the purpose of only storing updates in the redo log. This “different
`
`location” where the data is first stored is the memory of the computer running the
`
`virtual machine. In fact in the types of architectures (i.e. Intel Pentium or
`
`compatible processor) that the VMware workstation 1.0 product is compatible
`
`with, it is well known that all writes intended for disk must first be stored in
`
`memory (either RAM or processor register memory) because that is how Intel
`
`processors executes disk write instructions.
`
`35. After, the data is intercepted in memory, instructions are issued to
`
`write the data into the redo file by copying the data from memory into redo log file.
`
`Thus, it is my opinion that GSG does indeed describe the two claimed steps of
`
`capturing state and copying state because GSG describes a first step data of
`
`
`Case: IPR2013-00150
`
`
`
`
`– 17 –
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`intercepting data intended to be written to disk (i.e. capturing), and then a second
`
`step of writing the data to a redo file from memory (i.e. copying.)
`
`Suzaki
`
`36.
`
`I understand that Patent Owner contends that Suzaki does not describe
`
`capturing the state of a virtual machine at a single “point-in-time” because it
`
`allegedly describes capturing state on an application-by-application basis.
`
`(Response, p. 47; see also Green Dec, ¶¶ 125-128.) Specifically, Patent Owner
`
`argues that “the Suzaki process separately halts applications and writes their state
`
`to disk” because “[t]he shutdown process patched with SWSUSP calls the bdflush
`
`process and evacuates the buffer marked dirty for all executing processes. . . .”
`
`(Green Dec., ¶¶ 126-127.) I disagree for two reasons.
`
`37. First, the “bdflush” process referenced by Dr. Green is only applicable
`
`to
`
`the hibernation embodiment described
`
`in Suzaki, not
`
`the checkpoint
`
`embodiment. Indeed, after bdflush is called, Suzaki describes that the “shutdown
`
`process executes sync and halts the OS” (Suzaki, p. 4.) In other words, the virtual
`
`machine is suspended. But, Suzaki describes another embodiment where a
`
`“checkpoint” is created, and Suzaki explicitly describes that this checkpoint is at a
`
`single point-in-time: “[a]fter Checkpoint takes a snapshot, the original OS
`
`
`Case: IPR2013-00150
`
`
`
`
`– 18 –
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`continues to run and enables another virtual computer to resume the operation from
`
`the point at which Checkpoint was executed.” (Suzaki, p. 5 (emphasis added).) In
`
`the checkpoint embodiment, Suzaki further discloses that the state can be captured
`
`while the virtual machine continues to execute, explaining that the checkpoint
`
`“makes it possible to take a snapshot of the state information without stopping the
`
`virtual computer.” (Suzaki, p. 5.)
`
`38. Second, as Dr. Green acknowledged during his cross-examination,
`
`nothing restricts Suzaki from only running a single application. (Green Tr., 285:15-
`
`286:10.) Similarly, claims 1 and 12 only require at least one application running in
`
`the virtual machine (’086 patent, claims 1 and 12.) If only a single application were
`
`running under the Suzaki system, then the state of the virtual machine would be
`
`captured at a single point-in-time because only there is only a single application
`
`executing in the virtual machine.
`
`
`Case: IPR2013-00150
`
`
`
`
`– 19 –
`
`
`
`
`
`
`
`2907.020IPR0
`
`
`

`
`
`
`r"ni’llician
`
`In signing this declaration, I recognize that the declaration will be filed as
`
`evidence in a contested case before the Patent Trial and Appeal Board of the
`
`United States Patent and Trademark Office. I hereby declare that all statements
`
`made herein of my own knowledge are true and that all statements made on
`
`information and belief are believed to be true; and further that these statements
`
`were made with the knowledge that willful false statements and the like so made
`
`are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of
`
`the United States Code.
`
`Executed on Fe- 6 24 201 4 at
`
`
`
`Dr. Prashant Shenoy
`
`Case: 1PR2013-00150 (cid:9) (cid:151)20(cid:151)
`
`2907.0201PRO
`
`(cid:9)
`

`
`  
`
`Appendix A
`
`

`
`Prashant Shenoy
`
`Department of Computer Science
`140 Governor’s Drive
`University of Massachusetts
`Amherst, MA 01003-4610
`
`URL: http://www.cs.umass.edu/˜shenoy
`E-mail : shenoy@cs.umass.edu
`Phone: (413) 577-0850
`Fax: (413) 545-1249
`
`Research Interests
`Operating and Distributed systems, Sensor networks, Mobile and Multimedia systems, Sustainability
`
`Education
`
`August 1998
`
`Doctor of Philosophy (Ph.D.), Department of Computer Sciences,
`The University of Texas of Austin.
`Dissertation title: Symphony: An Integrated Multimedia File System
`Advisor: Prof. Harrick M. Vin.
`December 1994 Master of Science (M.S) in Computer Sciences
`The University of Texas of Austin.
`Bachelor of Technology (B.Tech), Department of Computer Science and Engineering
`The Indian Institute of Technology, Bombay, India.
`
`July 1993
`
`Work Experience
`• Fall 2011: Visiting Researcher, NICTA, Sydney, Australia
`• 9/2009-present: Professor, Department of Computer Science, University of Massachusetts Amherst.
`• 9/2004-8/2009: Associate Professor, Department of Computer Science, University of Massachusetts Amherst.
`• 9/1998-8/2004: Assistant Professor, Department of Computer Science, University of Massachusetts Amherst.
`• 8/1995-8/1998: Graduate Research Assistant, Department of Computer Sciences, University of Texas at
`Austin.
`• 5/1995-8/1995: Summer Intern, AT&T Bell Laboratories, Murray Hill, NJ.
`• 8/1994-5/1995: Teaching Assistant, Department of Computer Sciences, University of Texas at Austin.
`• 5/1994-8/1994: Summer Intern, Microsoft Research, Redmond, WA.
`
`Honors and Awards
`• Elected as the Fellow of the IEEE, 2013
`• Distinguished member of the ACM, 2009.
`• Keynote Spearker, ACM ICPE 2013 conference
`• Keynote Speaker, ACM GreenMetrics 2013
`
`

`
`• Keynote Speaker, IEEE E6 Energy Workshop, 2012.
`• Keynote speaker, TCS Excellence in Computer Science (TECS) Week, January 2012.
`• Best paper, ACM/IEEE IWQOS symposium, Montreal, 2013
`• Best paper runner-up, ACM eEnergy conference, Berkeley, CA, 2013
`• Best papers of IEEE PerCom 2012 conference (one of three papers chosen for this honor).
`• Best paper, IEEE COMSNETS 2012 conference, India.
`• Best paper, ACM Sigcomm GreenNets 2011 workshop, Toronto, Canada.
`• Our Memory Buddies paper adjudged one of the four best papers of ACM VEE 2009.
`• Best paper, Usenix 2007 annual technical conference.
`• Best Paper, ACM Multimedia 2005, Singapore.
`• Paper co-authored with a student won Best Student Paper, IEEE Autonomic Computing conference (ICAC)
`2005.
`• Best Paper, IEEE Web Information Systems Engineering Conference, 2002. Forwarded to a fast-track issue of
`World Wide Web Journal.
`• Best Paper in Performance/Systems Category and Finalist for overall Best Paper, World Wide Web Conference,
`May 2002. Forwarded to a fast-track issue of IEEE Transactions on Knowledge and Data Engineering.
`• Paper co-authored with a student was Best Student Paper Finalist, ACM Multimedia 2005.
`• Lilly Foundation Teaching Fellowship, August 2001.
`• IBM Faculty Partnership Award, June 2000, June 2001 and June 2003.
`• National Science Foundation (NSF) CAREER Award, April 2000.
`• Best Doctoral Dissertation of 1998-99, Department of Computer Sciences, University of Texas at Austin.
`• MCD Graduate Fellowship, Department of Computer Sciences, University of Texas at Austin, 1993-95.
`• Institute Medal recipient for being the top ranking graduating student, Department of Computer Science and
`Engineering, Indian Institute of Technology, Bombay, July, 1993.
`
`Book Chapters
`
`B1. Michael Zink and Prashant Shenoy, “Caching and Distribution Issues for Streaming Content Distribu-
`tion Networks,” X. Tang, J. Xu, and S T. Chanson (eds), Springer, 2005.
`
`B2. Harrick Vin and Prashant Shenoy, “Storage Architectures for Digital Imagery,” Image Databases:
`Search and Retrieval of Digital Imagery, V. Castelli and L. Bergman (eds), John Wiley, 2002.
`
`B3. Prashant Shenoy and Harrick Vin, “Media Servers,” Readings in Multimedia Computing, K Jeffay and
`H. Zhang (eds), Morgan Kaufman Publishers, August 2001.
`
`

`
`Journal Publications
`
`J1. Tian Guo, Upendra Sharma, Prashant Shenoy, Timothy Wood, Sambit Sahu, ”Cost-aware Cloud Burst-
`ing for Enterprise Applications,” ACM Transactions on Internet Technology (TOIT), 2014 (to appear).
`
`J2. Prashant Shenoy, ”Multimedia Systems Research: The First Twenty Years and Lessons for the Next
`Twenty,” ACM Transactions on Multimedia Computing, Communications and Applications (ACM TOM-
`CCAP), Special Issue on 20 Years of ACM Multimedia, vol 9, no 1s, October 2013.
`
`J3. R. Singh, P. Shenoy, M. Natu, V. Sadaphal and H. Vin, ”Analytical Modeling for What-if Analysis in
`Complex Cloud Computing Applications,” ACM Sigmetrics Performance Evaluation Review, Special
`Issue on Cloud Computing, Vol 40, no 4, pages 53-62, March 2013
`
`J4. A. Mishra, D. Irwin, P. Shenoy, J. Kurose, T. Zhu, ”GreenCharge: Managing Renewable Energy in
`Smart Buildings,” IEEE Journal on Selected Areas in Communications (JSAC), Special Series on Smart
`Grid Communications, 31(7): 1281-1293, July 2013.
`
`J5. B. Li, E. Mazur, Y. Diao, A. McGregor and P. Shenoy, “SCALLA: A Platform for Scalable One-Pass
`Analytics using MapReduce,” ACM Transactions on Database Systems (TODS), 37:4, December 2012.
`Special Issue of Best Papers of Sigmod 20