Ex Parte Topchiyski

Patent Trial and Appeal Board

Mar 10, 2014

11413800 (P.T.A.B. Mar. 10, 2014)

UNITED STATES PATENT AND TRADEMARK OFFICE
__________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
__________

Ex parte KRASIMIR I. TOPCHIYSKI
__________

Appeal 2011-011629
Application 11/413,800
Technology Center 2100
__________

Before ERIC GRIMES, JEFFREY N. FREDMAN, and
ULRIKE W. JENKS, Administrative Patent Judges.

FREDMAN, Administrative Patent Judge.

DECISION ON APPEAL
This is an appeal1 under 35 U.S.C. § 134 involving claims to a
method, system, and medium for inspecting memory leaks and copying
garbage collection files. The Examiner rejected the claims as obvious. We
have jurisdiction under 35 U.S.C. § 6(b). We reverse.

1 Appellant identifies the Real Party in Interest as SAP AG (App.
Br. 2).
Appeal 2011-011629
Application 11/413,800

2
Statement of the Case
Background
“A memory leak can occur when a program . . . allocates memory to
an object but never (or only partially) deallocates the memory when the
object is no longer needed” (Spec. 3 ¶ 0005). The Specification teaches that
“memory leaks, even seemingly insignificant ones, can become a major
problem. Even the smallest memory leak in code that runs 24/7 may
eventually cause an OOME [out of memory error], which can bring down
the VM [virtual machine] and its applications” (Spec. 3-4 ¶ 0006). The
Specification teaches that “[g]arbage collection as described here includes a
process designed to identify and reclaim blocks of memory that are
dispensed by a memory allocator but are no longer ‘alive’” (Spec. 18 ¶
0039).
The Claims
Claims 1, 4-6, 9, 12, 17, and 20 are on appeal. Claim 1 is
representative and reads as follows:
1. A method comprising:
monitoring a runtime system environment to detect memory
leaks within the runtime system environment having runtime systems,
the monitoring including:
executing a garbage collecting process in a runtime system at
least once to:
release memory allocated within the runtime system for
already inaccessible object instances; and
writing, to a garbage collection file having memory leak
information, memory leak information identifying first objects
causing first memory leaks in the runtime system, the memory
leak information providing a state of the first objects as they
existed prior to causing the first memory leaks, the memory
leak information further including memory space allocated to
Appeal 2011-011629
Application 11/413,800

3
the first objects, pending method calls, and classes associated
with the first objects;
periodically duplicating the garbage collection file into a
duplicate garbage collection file capable of serving as a backup file to
the garbage collection file; and
during runtime, analyzing the duplicate garbage collection file
having the memory leak information relating to the first objects to
identify second objects capable of causing second memory leaks, and
removing the second objects from an application prior to occurrence
of the second memory leaks.

The issue
The Examiner rejected claims 1, 4-6, 9, 12, 17, and 20 under 35
U.S.C. § 103(a) as obvious over Traversat2 and Grey3 (Ans. 3-7).
The Examiner finds that Traversat teaches “periodically duplicating
the garbage collection file into a duplicate garbage collection file, capable of
serving as a backup file to the garbage collection file and that analysis from
runtime is performed from duplicate garbage collection file” (Ans. 4). The
Examiner acknowledges that Traversat does not teach “during runtime,
analyzing the duplicate garbage collection file having the memory leak
information relating to the first objects to identify second objects capable of
causing second memory leaks, and removing the second objects from an
application prior to occurrence of the second memory [leaks]” (Ans. 4).
The Examiner finds that Grey teaches “during runtime, analyzing the
duplicate garbage collection file having the memory leak information
relating to the first objects to identify second objects capable of causing

2 Traversat et al., US 6,865,657 B1, issued Mar. 8, 2005.
3 Grey, J., US 2006/0143537 A1, published Jun. 29, 2006.
Appeal 2011-011629
Application 11/413,800

4
second memory leaks, and removing the second objects from an application
prior to occurrence of the second memory leaks” (Ans. 5).
The Examiner finds it obvious
to use logging to a file memory leak information as well as
state of the memory as taught by Grey in the garbage
collection that includes backing up from virtual to physical
space information during runtime and data mining as taught
[by] Traversat for the predictable result of not only having
the ability to debug during program runtime but also to have
ability of keeping a log file of memory leaks to provide for
better debugging ability during and after garbage collection.

(Ans. 6).
The issue with respect to this rejection is: Does the evidence of record
support the Examiner’s conclusion that Traversat and Grey suggest
“analyzing the duplicate garbage collection file having the memory leak
information relating to the first objects to identify second objects capable of
causing second memory leaks, and removing the second objects from an
application prior to occurrence of the second memory leaks” as required by
claim 1?
Findings of Fact
1. Traversat teaches
A heap may also include structures for managing the
application's code and data in the heap. For example, a heap
may be divided into sections, for example pages or cache
lines. The sections of the heap may be grouped into sets of
two or more sections for some heap processing functions
such as garbage collection.

(Traversat, col. 4, ll. 10-15).
Appeal 2011-011629
Application 11/413,800

5
2. Traversat teaches
A garbage collection method may be provided for the
virtual persistent heap. In one embodiment, the garbage
collection method may be used with small consumer and
appliance devices, for example, Java-enabled devices, which
may have a small amount of memory and may be using flash
devices as persistent storage. In one embodiment, the
garbage collection method may be implemented to provide
good performance where only a portion of the virtual
persistent heap may be cached in the physical heap.

(Traversat, col. 5, ll. 13-21).
3. Traversat teaches that a “garbage collection cycle may help
reduce the amount caching by removing currently unused objects from the
virtual heap space and allowing a compaction phase to improve object
locality by compacting correlated objects into the same cacheable section(s)
of the heap” (Traversat, col. 5, ll. 51-55).
4. Traversat teaches that after “storing a checkpoint for application
104, persistent store space 120 may include an entire, up-to-date copy of the
virtual heap 110. Persistent store space 120 may also include checkpointed
copies of the virtual heap for one or more other applications” (Traversat, col.
12, ll. 37-41).
5. Grey teaches “a system and method for performing automatic
heap validity checking and automatic memory leak detection when user-
supplied code modules are called by steps of a test executive sequence”
(Grey 1 ¶ 0002).
6. Grey teaches that
One common type of error that can be caused by user-
supplied code modules is heap corruption. A heap may
Appeal 2011-011629
Application 11/413,800

6
comprise a memory pool or store from which memory can
be dynamically allocated at runtime during execution of a
program. . . . A memory block allocated from the heap
typically remains allocated until it is explicitly de-allocated
either by the programmer or by a garbage collector.

(Grey 2 ¶ 0012).
7. Grey teaches that “test executive software may be operable to
automatically determine one or more heaps that should be checked for
validity” (Grey 10 ¶ 0127).
8. Grey teaches that the “test executive engine 220 may invoke
execution of the user-supplied code module called by the step. . . . the test
executive engine 220 may perform any of various other actions to invoke
execution of the user-supplied code module, depending on the
implementation of the module” (Grey 10 ¶ 0130).
9. Grey teaches that:
automatic memory leak detection may be enabled or turned on
for at least a subset of the test executive steps in the test executive
sequence that call user-supplied code modules. As described below,
for each test executive step for which automatic memory leak
detection is enabled, the test executive engine 220 may be operable to
perform certain actions when the step is executed to check whether
the user-supplied code module called by the step causes a memory
leak.

(Grey 11 ¶ 0142)
Principles of Law
“In proceedings before the Patent and Trademark Office, the
Examiner bears the burden of establishing a prima face case of obviousness
Appeal 2011-011629
Application 11/413,800

7
based upon the prior art.” In re Fritch, 972 F.2d 1260, 1265 (Fed. Cir.
1992).
In addition, “obviousness requires a suggestion of all limitations in a
claim.” CFMT, Inc. v. Yieldup Int’l Corp., 349 F.3d 1333, 1342 (Fed. Cir.
2003).
Analysis
Appellant contends that the independent claims require “analyzing the
duplicate garbage collection file having the memory leak information
relating to the first objects to identify second objects capable of causing
second memory leaks, and removing the second objects from an application
prior to occurrence of the second memory leaks” (see, e.g., claim 1; App. Br.
14). Appellant contends that there “is no assertion in the Final Office Action
of where a teaching or suggestion of the claimed analyzing is taught or
suggested” (App. Br. 14). Appellant contends that “[f]urther, there is no
teaching or suggestion of using any sort of duplicated garbage collection
data” (App. Br. 14).
The Examiner finds that “Traversat teaches check-pointing and
backup to the secondary location, for example from virtual to physical, and
hence reads on the first part of limitation where more than one file is
required. Therefore duplicate log files relating to memory management and
garbage collection are sufficiently taught by Traversat” (Ans. 9).
The Examiner finds:
Further, and in the alternative, the limitation as
claimed is very broad as it recites in pertinent part
“analyzing the duplicate garbage collection file having the
memory leak information relating to the first objects to
identify second objects capable of causing second memory
Appeal 2011-011629
Application 11/413,800

8
leaks.” All that is required is the logs are analyzed to
determine memory leak info for first objects, and that it is
used to “identify second objects capable of causing second
memory leaks,” however, how this operation of analyzing
leads to other objects being identified is not specifically
claimed and thus any broad interpretation is sufficient.
Clearly teachings of Grey and even Traversat are sufficient
as they discuss how detection of memory leaks or heap
corruption affects the other objects in the heap or stack.

(Ans. 10).
We find that Appellant has the better position. Even if Traversat is
relied upon to teach a duplicate garbage collection file, neither Traversat nor
Grey reasonably suggest analyzing this duplicate garbage collection file
during runtime to “identify second objects capable of causing second
memory leaks, and removing the second objects from an application prior to
occurrence of the second memory leaks” as required by claims 1, 9, and 17.
The Examiner’s argument that the limitation may be broadly
interpreted so that any analysis of logs will result in identification of second
objects is not consistent with the claim limitation, which utilizes memory
leak information regarding first objects as a tool to identify second objects
which have not yet caused memory leaks prior to their causing memory
leaks.
Further, neither Traversat nor Grey provide a suggestion to anticipate
second objects which may, at some future time, cause memory leaks.
Instead, Traversat and Grey simply teach identifying and removing actual
objects causing memory leaks (FF 1-9). It is this failure of the prior art to
teach removing “second objects” which have not caused memory leaks but
Appeal 2011-011629
Application 11/413,800

9
which the analysis indicates are capable of causing memory leaks, which
requires reversal of the rejection.
Conclusion of Law
The evidence of record does not support the Examiner’s conclusion
that Traversat and Grey suggest “analyzing the duplicate garbage collection
file having the memory leak information relating to the first objects to
identify second objects capable of causing second memory leaks, and
removing the second objects from an application prior to occurrence of the
second memory leaks” as required by claim 1.
SUMMARY
In summary, we reverse the rejection of claims 1, 4-6, 9, 12, 17, and
20 under 35 U.S.C. § 103(a) as obvious over Traversat and Grey.

REVERSED

lp