Appeal 2007-1048
Application 09/969,334
by task A, which is usually of a fixed size. Both the data
portion 230 and the stack portion 250 are likely to change
memory sizes over the duration of the execution of their
respective program 220. Therefore, in this method, certain
additional memory space is allocated so that stack portion 250
and data portion 230 can grow into it. For efficiency purposes
it would be advisable to have them grow into the same growth
area 240, as shown in FIG. 2.
Trainin col. 2, ll. 21-34.
Trainin thus describes memory allocation for a program 220, usually
of a fixed size. The memory allocation may include a data portion and a
stack portion, which are allowed to grow in size as needed, taking up a
portion of growth area 240 (Fig. 2).
Trainin depicts several storage locations in Figure 2. However, the
rejection does not specify which of the locations are deemed to correspond,
respectively, to the first, second, and third storage locations that are claimed.
We have a problem, as do Appellants, in understanding how the reference is
believed to anticipate the subject matter of claim 23. Nor is it apparent how
all the requirements of the first, second, and third storage locations may be
met by Trainin’s description of the prior art memory allocation.
We conclude that the Examiner has failed to set forth a prima facie
case for anticipation of claim 23. We cannot sustain the rejection of the
claim under 35 U.S.C. § 102(e) over Trainin.
Instant claim 31 is also rejected for anticipation over Trainin, with
reliance on the above-quoted section that addresses prior art memory
allocation.
Appellants argue in response that Trainin makes no mention of a
database in the text. According to Appellants, the term “database” is well
4
Page: Previous 1 2 3 4 5 6 7 Next
Last modified: September 9, 2013