Ex Parte Corrie

Patent Trial and Appeal Board

Feb 23, 2017

13460556 (P.T.A.B. Feb. 23, 2017)

United States Patent and Trademark Office
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O.Box 1450
Alexandria, Virginia 22313-1450
www.uspto.gov
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
13/460,556 04/30/2012 Benjamin J. CORRIE A828.01 3416
36378 7590
VMWARE, INC.
DARRYL SMITH
3401 Hillview Ave.
PALO ALTO, CA 94304
EXAMINER
DARE, RYAN A
ART UNIT PAPER NUMBER
2136
NOTIFICATION DATE DELIVERY MODE
02/27/2017 ELECTRONIC
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address(es):
ipteam @ vmware. com
ipadmin@vmware.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte BENJAMIN J. CORRIE
Appeal 2016-004048
Application 13/460,556
Technology Center 2100
Before JOSEPH L. DIXON, JAMES R. HUGHES, and ERIC S. FRAHM,
Administrative Patent Judges.
FRAHM, Administrative Patent Judge.
DECISION ON APPEAL
Appeal 2016-004048
Application 13/460,556
STATEMENT OF THE CASE
Appellant appeals under 35 U.S.C. § 134(a) from a rejection of claims
1—21. We have jurisdiction under 35 U.S.C. § 6(b).
We reverse.
The invention relates to managing memory in a host computer
executing a virtual machine (“VM”) (Spec. 17). Claim 1, reproduced
below, is illustrative of the claimed subject matter:
1. A method for managing memory of a runtime environment
executing in a virtual machine, the method comprising:
receiving cache data from an application executing in the
runtime environment and storing the received cache data in one
or more objects within heap memory of the runtime environment;
determining, by operation of a memory management
agent, a first target size for memory to be reserved within heap
memory of the runtime environment;
identifying at least one of the objects stored in the heap
memory that store cache data for the application;
replacing at least some portion of the cache data stored in
the identified object with a first value; and
notifying a hypervisor that at least one machine physical
memory page associated with the identified object and having the
first value, can be re-claimed.
REFERENCE
The prior art relied upon by the Examiner in rejecting the claims on
appeal is:
Ben-Yehuda US 2012/0233435 A1 Sept. 13, 2012
2
Appeal 2016-004048
Application 13/460,556
REJECTION
The Examiner made the following rejection:
Claims 1—21 stand rejected under 35 U.S.C. § 102(e) as being
anticipated by Ben-Yehuda.
ANALYSIS
Appellant contends “no data of the Regular objects 200 of Ben-
Yehuda is replaced with a first value, as recited in Appellant’s claim 1” and
“there is no disclosure in Ben-Yehuda that the Java balloon objects 210 have
their data replaced with a first value” (App. Br. 11). We are persuaded by
Appellant’s argument for the foregoing reasons.
Ben-Yehuda describes a memory management method in which a
“hypervisor 112 basically acts as an operating system (OS) for the host
machine 100 and provides a runtime environment for one or more virtual
machines (VMs)” (Ben-Yehuda, 122). A VM can host a guest operating
system (“OS”) 124, which in turn runs guest software, for example
application 126 (see Ben-Yehuda, 122; see also Fig. 1). “[Application 126
may be a Java Virtual Machine (JVM) and the memory management data
structure may be implemented as heap 222 which includes a pool of memory
available in a heap free space 260” (Ben-Yehuda, 124). The guest OS 124
allocates memory to application 126, but some memory may be reserved by
way of a memory reservation mechanism called a “balloon” (Ben-Yehuda, 1
23). “[T]he hypervisor 112 may set a target balloon size for the VM balloon
driver 230 to make a guest OS 124 balloon inflate by allocating guest
physical pages within the guest OS 124, for example” (Ben-Yehuda, 124).
3
Appeal 2016-004048
Application 13/460,556
The guest OS 124 determines if the OS needs to page out guest
physical memory to satisfy the VM balloon driver 230 allocation
requests.
If the guest has plenty of free guest physical memory,
inflating the guest balloon will induce no paging and will not
impact guest performance!/] However, if the guest is already
under memory pressure, the guest OS 124 decides which guest
physical pages to be paged out to the virtual swap device, in order
to satisfy the balloon driver’s allocation requests. . . .
In the cases where the above guest ballooning mechanism
is not sufficient to reclaim memory, the hypervisor 112 may be
forced to create a separate swap file for the guest OS 124 so that
the hypervisor 112 may directly swap out guest physical memory
to that swap file, which frees host physical memory for other
guests.
(Ben-Yehuda, Tflf 25—27). Further, regarding the “balloon” mechanism, Ben-
Yehuda describes the following:
Conceptually, the java balloon refers to a portion of the
heap 222 that is allocated to the java balloon objects 210 to
reserve memory space for the hypervisor 112 or provide for the
guest OS 124 unused memory 220. The rest of the heap free
space 260 may be made available for regular objects 200
instantiated by the JVM (i.e., application 126) for other purposes.
(Ben-Yehuda, 131; see also Fig. 2).
Accordingly, we find Ben-Yehuda discloses that a guest OS running
on a VM can allocate heap memory to an application, such as a JVM, and
the application can use the memory to instantiate regular objects for use by
the application (see Ben-Yehuda, Tflf 22—24, 31). However, if Ben-Yehuda’s
hypervisor causes a guest OS balloon to inflate, a portion of the heap
memory is allocated to Java balloon objects, which may result in the guest
OS swapping out certain memory to satisfy the balloon allocation request, or
4
Appeal 2016-004048
Application 13/460,556
may result in the hypervisor directly swapping out memory from the guest
OS (see Ben-Yehuda, H 2A-27, 31).
Although Ben-Yehuda discloses swapping out guest OS memory that
stores regular objects, the Examiner does not specifically identify which part
of Ben-Yehuda’s memory management method meets the claim 1 limitation
“replacing at least some portion of the cache data stored in the identified
object with a first value.” Rather, the Examiner provides a general citation
to paragraphs 24 to 27 of Ben-Yehuda without providing any mapping
between this disclosure and the elements of claim 1 (Final Act. 3). In the
Answer, the Examiner addresses the “replacing” limitation, but only with
respect to the “cache data” language (see Ans. 3). The Examiner does not
address the language “replacing . . . data stored in the identified object with a
first value” (see id.). Absent a specific mapping to Ben-Yehuda for the
claimed “first value” that replaces the “identified object,” we find the
Examiner has not shown Ben-Yehuda discloses “replacing at least some
portion of the cache data stored in the identified object with a first value.”
Further, we decline to speculate whether this limitation would have been
obvious over Ben-Yehuda’s swapping of guest OS memory absent findings
by the Examiner regarding obviousness.
We are, therefore, constrained by the record to find the Examiner
erred in rejecting independent claim 1, independent claims 8 and 15, which
recite commensurate limitations, and dependent claims 2—7, 9-14, and 16—
21 for similar reasons.
5
Appeal 2016-004048
Application 13/460,556
CONCLUSION
The Examiner erred in rejecting claims 1—21 under 35 U.S.C.
§ 102(e).
DECISION
For the above reasons, the Examiner’s rejection of claims 1—21 is
reversed.
REVERSED
6