Ex Parte Chauvel et al

Patent Trial and Appeal Board

Mar 18, 2013

10631185 (P.T.A.B. Mar. 18, 2013)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte GERARD CHAUVEL, SERGE LASSERRE,
and DOMINIQUE D’INVERNO
____________

Appeal 2010-006785
Application 10/631,185
Technology Center 2100
____________

Before DENISE M. POTHIER, JEREMY J. CURCURI, and
BARBARA A. BENOIT, Administrative Patent Judges.

POTHIER, Administrative Patent Judge.

DECISION ON APPEAL
STATEMENT OF THE CASE
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1-20.1 We have jurisdiction under 35 U.S.C. § 6(b). We
affirm-in-part and enter a new ground of rejection under 37 C.F.R.
§ 41.50(b).

1 Throughout this opinion, we refer to the Appeal Brief (App. Br.) filed
September 4, 2009; (2) the Examiner’s Answer (Ans.) mailed December 9,
2009; and (3) the Reply Brief (Reply Br.) filed February 2, 2010.
Appeal 2010-006785
Application 10/631,185

2
Invention
Appellants’ invention relates to a memory management technique for
a processor-based system. See generally Spec. ¶ 0002. Claims 1, 11, and 17
are reproduced below with the disputed limitations emphasized:
1. A method of managing memory, comprising:
determining stack trend information using current and future stack
operating instructions; and
reducing data traffic between various levels of a memory based on the
trend information.

11. A computer system, comprising:
a processor;
a memory coupled to the processor;
a stack that exists in memory and contains stack data;
a memory controller coupled to the memory;
trend logic;
wherein the processor executes instructions;
wherein the trend logic provides trend information about the stack to
the controller; and
wherein the trend information about the stack is based on at least one
future instruction.

17. A method, comprising:
issuing a write request to a cache memory, wherein the cache memory
includes multiple cache lines;
determining whether the write request refers to a predetermined word
within a dirty cache line; and
determining whether to write the dirty cache line to main memory
based on whether the size of a stack is increasing or decreasing.

The Examiner relies on the following as evidence of unpatentability:
Shen US 5,687,336 Nov. 11, 1997
Ebrahim US 5,893,121 Apr. 6, 1999
O’Connor US 6,026,485 Feb. 15, 2000
Flake US 7,065,613 B1 June 20, 2006
(filed June 6, 2003)
Appeal 2010-006785
Application 10/631,185

3
Charles M. Kozierok, The Memory Controller 12 (2001), available at
http://www.pcguide.com/ref/ram/timingController-c.html [hereinafter The
PC Guide].

The Rejections
Claims 11 and 13 are rejected under 35 U.S.C. § 102(b) as anticipated
by Shen.3 Ans. 3-5.
Claims 17-20 are rejected under 35 U.S.C. § 102(e) as anticipated by
Flake. Ans. 5-6.
Claims 1-4, 6-10, 15, and 16 are rejected under 35 U.S.C. § 103(a) as
unpatentable over Shen and Flake. Ans. 6-14.
Claims 12 and 14 are rejected under 35 U.S.C. § 103(a) as
unpatentable over Shen and O’Connor. Ans. 15-16.
Claim 5 is rejected under 35 U.S.C. § 103(a) as unpatentable over
Shen, Flake, and Ebrahim. Ans. 16-17.

THE ANTICIPATION REJECTION OVER SHEN
Regarding claim 11, the Examiner finds that Shen discloses the trend
information about a stack is based on at least one future instruction. See
Ans. 4 (citing col. 3, l. 65–col. 4, l. 7; col. 4, ll. 11-15, 36-60; Figs. 2, 4), 23.
Appellants argue that Shen fails to teach the recited trend information is
based on a future instruction given that the new stack pointer is not
determined until the end of the pipeline. App. Br. 14.

2 One printed page of this reference was provided, and this page is numbered
page one.
3 The Examiner uses The PC Guide as extrinsic evidence for this and the
§ 103 Shen/Flake rejection to show specific characteristics. See MPEP
§ 2131.01.
Appeal 2010-006785
Application 10/631,185

4
ISSUE
Under § 102, has the Examiner erred in rejecting claim 11 by finding
that Shen discloses the trend information about the stack is based on at least
one future instruction?

ANALYSIS
Based on the record before us, we find no error in the Examiner’s
rejection of claim 11. Turning to the disclosure for a better understanding of
the recited terms, “trend information” and “future instruction,” we find that
Appellants have not defined these terms. On the other hand, Appellants
describe INST1 through INSTN as future instructions of INST0 within a pipe
and determining trend information based on both the current instruction
(e.g., CURRENT 68) and the future instructions (e.g., FUTURE 70). See
Spec. ¶ 0023. Appellants further describe FUTURE 70 as a signal and that
future stack information determines a net stack trend based on the
instructions (e.g., “iload” and “iadd”) that yield a value (e.g., 2). See id. As
such, trend information about a stack based on a future instruction can
broadly, but reasonably, be construed as a value that represents a stack.
Shen discloses a pipeline processor that executes multiple stack
instructions in a pipeline, and valid bits 50 that indicate the location of valid
stack instructions performed at different stages in the pipeline. Ans. 4, 23
(citing col. 4, ll. 37-44). Each bit thus represents information about a stack
(e.g., location of stack instructions) and collectively the bits also represent
trend information about the stack. Figure 3 also shows multiple valid bits 50
are inputted into logic 20 and its result is added to memory stack 26. See
Ans. 23 (citing col. 5, ll. 1-18); col. 5, ll. 19-22. Similar to Appellants, Shen
Appeal 2010-006785
Application 10/631,185

5
discloses information about various instructions, such as one that is the
current instruction information (e.g., -4) and others that are future instruction
information (e.g., 0, -8, 4, 0). See col. 5, ll. 19-22; see also Fig. 3. Thus,
Shen discloses logic (e.g., 20) that provides trend information4 about the
stack based on at least one future instruction as broadly as recited.
However, we cannot sustain the rejection of claim 13. Claim 13
depends from claim 12, which is rejected based on Shen and O’Connor. See
Ans. 15-16. Because claim 12 requires O’Connor to teach its limitations,
dependent claim 13 should also be rejected based on this grounds. For this
reason, we reverse the rejection of claim 13 but enter a new ground of
rejection, supra.
For the foregoing reasons, Appellants have not persuaded us of error
in the rejection of independent claim 11. The Examiner, however, erred in
rejecting claim 13 based on Shen under § 102.

THE ANTICIPATION REJECTION OVER FLAKE
Regarding independent claim 17, the Examiner finds that Flake
discloses determining whether to write the dirty cache line to main memory
based on whether the stack size is increasing or decreasing. See Ans. 5
(citing col. 6, ll. 13-31). Specifically, the Examiner finds no cache function

4 This recited information (i.e., the trend information) is merely descriptive,
does not functionally affect the computer system, the controller, or the trend
logic, and can be considered non-functional descriptive material that does
not patentably distinguish over the prior art. See Ex parte Nehls, 88
USPQ2d 1883, 1887-89 (precedential) (discussing cases pertaining to
non-functional descriptive material); Ex parte Curry, 84 USPQ2d 1272
(BPAI 2005), aff’d Fed. Cir. No. 2006-1003 (June 12, 2006).

Appeal 2010-006785
Application 10/631,185

6
occurs in Flake when stack objects are being deleting (e.g., the stack is
decreasing) and a dirty line is written from cache to main memory during a
stack-growth write (e.g., the stack is increasing). See Ans. 24-25.
Appellants contend that writing a dirty cache line based on a cache
miss, as taught by Flake, does not teach a causal relationship between an
increasing stack and writing a cache line, such that Flake teaches
determining whether to write the dirty cache line to main memory based on
whether the size of a stack is increasing or decreasing. App. Br. 15.

ISSUE
Under § 102, has the Examiner erred in rejecting claim 17 by finding
that Flake discloses determining whether to write the dirty cache line to
main memory based on whether the size of a stack is increasing or
decreasing?

ANALYSIS
Based on the record before us, we find error in the Examiner’s
rejection of claim 17, which recites determining whether to write the dirty
cache line to main memory based on whether the size of a stack is increasing
or decreasing. Flake deletes a group of stack objects by changing a stack
pointer (col. 6, ll. 29-31) after writing the data from cache to main memory.
See col. 6, ll. 29-31 (stating “[t]he next processor operation is a deletion . . .”
(emphasis added)); see also Fig. 6 (step 1 (write 9F) is before step 3
(deleting group)). Thus, this operation does not relate to writing the dirty
cache line to main memory discussed in Flake’s previous paragraph (col. 6,
ll. 13-28), such that we can find that Flake expressly or inherently
Appeal 2010-006785
Application 10/631,185

7
determines whether to write the dirty cache line to main memory (e.g., not to
write) based on the stack size decreasing. Additionally, this example
discusses no cache function occurs when deleting a group of stack objects
and is achieved by changing the stack pointer. See id. Thus, any
determination not to write to main memory occurs during or prior to the
change to the stack pointer or prior to being able to determine whether the
stack size has decreased by using the stack pointer. See id.
The Examiner also relies on Flake’s stack growth write operation to
demonstrate Flake determines whether to write the dirty cache line to main
memory based on the stack size increasing. See Ans. 5, 25 (citing col. 6, ll.
13-28). While Appellants assert Flake teaches writing the cache line after a
cache miss (App. Br. 15), Figure 5 shows that the write replacement line to
main memory occurs or is determined after a miss, picking up the
replacement line, and deciding the replacement line tag does not equal the
unused address. See Fig. 5 (indicating “N” before the box labeled “WRITE
REPLACEMENT LINE TO MAIN MEMORY”); see also col. 5, ll. 38-40.
Thus, in this operation, Flake discloses determining whether to write the
dirty cached line to main memory based on whether the replacement line tag
does not equal the unused address and not based on whether the stack size is
increasing. See id.; see also Fig. 6. The stack-growth write operation in
Flake does not necessarily and adequately disclose determining whether to
write the dirty cache line to main memory based on the stack increasing.
We therefore are constrained to agree with Appellants that there is
insufficient evidence of a relationship between Flake determining or
deciding whether to write the dirty cache line to main memory and the stack
Appeal 2010-006785
Application 10/631,185

8
size increasing or decreasing to find Flake determines whether to write the
cache line based on whether the stack is increasing or decreasing.
For the foregoing reasons, Appellants have persuaded us of error in
the rejection of independent claim 17 and claims 18-20 for similar reasons.

THE OBVIOUSNESS REJECTION OVER SHEN AND FLAKE
Claims 1-4 and 6-10
Representative independent claim 1 differs from claims 11 and 17 and
recites, in part, reducing data traffic between various levels of a memory
based on the trend information. The Examiner finds that Shen teaches the
“determining stack trend information” step (e.g., stack pointer indicating the
stack size has increased or decreased) and Flake, when combined with Shen,
teaches the reducing step (col. 6, ll. 32-33) by skipping reading a line from
main memory based on the stack pointer. Ans. 6-7, 17-19. Appellants assert
that Flake fails to teach the recited reducing step and that determining access
to unused portions of a stack does not determine trend information. App.
Br. 12 (citing col. 5, ll. 38-40).

ISSUE
Under § 103, has the Examiner erred in rejecting claim 1 by finding
that Shen and Flake collectively would have taught or suggested reducing
data traffic between various levels of a memory based on the trend
information?

Appeal 2010-006785
Application 10/631,185

9
ANALYSIS
Based on the record before us, we find no error in the Examiner’s
rejection of claim 1. Appellants argue Flake alone fails to teach reducing
data traffic between levels of memory based on the trend information (App.
Br. 12), but notably the Examiner relies upon Shen’s teaching of stack trend
information (e.g., the stack pointer) in combination with Fluke’s teaching of
the stack pointer to teach and suggest the recited reducing step. See Ans. 6-
7, 17-19. Attacking references individually does not show nonobviousness
where the rejection, as is here, is based on combinations of references. See
In re Merck & Co., Inc., 800 F.2d 1091, 1097 (Fed. Cir. 1986).
The Examiner finds that Shen’s stack pointer indicates the final value
of the stack and reflects the general movement of the stack size. Ans. 17;
see also col. 4, ll. 41-47, 56-59; col. 5, ll. 1-14. Given that the “trend
information” has not been defined (see generally Spec.) and even relates to
the size of the stack in one example (see Spec. ¶ 0023), we find the
Examiner’s position that the stack pointer’s value can be trend information
reasonable. The Examiner further finds that Flake teaches deleting stack
objects when the no cache function or write to memory occurs and growing
the stack during a write operation to main memory. Ans. 18 (citing col. 6,
ll. 29-44). Focusing on the “stack-growth write” operation, we agree that
this operation includes setting the stack pointer (col. 6, ll. 32-34) before
determining whether to skip the write of an old data line and the read of a
line from the main memory (col. 6, ll. 40-45), and thus the pointer impacts
this inaction (e.g., a reduction of data traffic between levels of memory).
This skip operation that reduces traffic between various levels of memory is
Appeal 2010-006785
Application 10/631,185

10
thus based, at least in part, on trend information related to a stack pointer.
See Ans. 18-19.
Notably, while we reach the opposite conclusion for claim 17 related
to Flake, claim 17 differs in scope from claim 11 and was more narrowly
limited to determining whether to write a dirty cache line to main memory
based on whether the stack size is increasing or decreasing.
Lastly, while Appellants argue that determining unused portions of
cache in Flake is not a stack operation (App. Br. 12), we find this argument
is not commensurate in scope with the claims. Also, while Appellants take
issue with the Examiner’s statement that Flake teaches a “pop” operation
and argues this teaches away from Flake’s column 6, lines 56-60 (see Reply
Br. 1), we are not persuaded. As discussed above, when addressing the
“stack-growth” operation, which does not relate to any “pop” operation,
Flake teaches reducing data traffic between memory levels based on trend
information as broadly as recited.
For the foregoing reasons, Appellants have not persuaded us of error
in the rejection of independent claim 1 and claims 2-4 and 6-10 not argued
separately.

Claim 15
Independent claim 15 recites the trend information is used to restrict
writing dirty cache lines from cache memory to main memory when the
trend information indicates the stack is decreasing. Repeating a similar
argument to that in connection with claim 1, Appellants contend Flake fails
to teach the trend information is used to restrict writing dirty cache lines
Appeal 2010-006785
Application 10/631,185

11
from cache memory to main memory when the trend information indicates
the stack is decreasing. App. Br. 13. We disagree.
This recitation in claim 15 also differs from claim 17 in that that trend
information is used to restrict writing dirty cache lines from cache memory
to main memory when the trend information indicates the stack is
decreasing. The Examiner finds that Flake teaches or suggests this
limitation when discussing a processor operation that deletes a group of
stack objects by changing the stack pointer without any cache function. See
Ans. 12, 20 (citing col. 6, ll. 29-31). We find this position reasonable. That
is, Flake teaches changing the stack pointer at or during the time of (e.g.,
when) deleting the stack objects and at and during the time that no cache
function occurs. See col. 6, ll. 29-31; see also step 4 in Fig. 6. Given this
teaching, we agree that Flake at least suggests restricting cache functions,
including writing a cache line from cache to main memory, during the time
or when trend information (e.g., a stack pointer’s value) indicates the stack is
decreasing (e.g., stack pointer’s value is changed to reflect decrease). See id.
Appellants also quote from column 6, lines 56-62, in Flake but does
not elaborate on how this discussion demonstrates Flake fails to teach or
suggest the disputed limitation. App. Br. 13. Without sufficient
explanation, we are not persuaded. For the foregoing reasons, Appellants
have not persuaded us of error in the rejection of independent claim 15.
While not separately argued, to the extent that claim 7 is similar in scope to
claim 15, we also rely on the above discussion.

Appeal 2010-006785
Application 10/631,185

12
Claim 16
Independent claim 16 recites in pertinent part, the dirty cache line is
written to main memory if the trend information indicates the stack is
increasing. We find claim 16 similar to claim 15 in that the word, “if,” is
similar to “when.” As discussed above, Flake teaches setting the stack
pointer to 9F at the beginning of a stack-growth operation. See Ans. 14
(citing col. 6, ll. 13-16); see also Fig. 6. This setting of the stack pointer
indicates that the stack is increasing in a stack-growth operation.
Subsequently, but still during this stack-growth operation, a dirty line is
written to main memory. See Ans. 14 (citing col. 6, ll. 22-28); see also Fig.
5 (box labeled “WRITE REPLACEMENT LINE TO MAIN MEMORY”).
Given these teachings, we agree that Flake at least suggests the dirty cache
line is written to main memory if (i.e., during the time or when) the trend
information (e.g., the value of the stack pointer) indicates the stack is
increasing as broadly as recited.
Notably, while claim 17 has some similarities to claim 16, claims 15
and 16 are apparatus claims that require writing or restricting writing when
or if the trend information indicates the stack is increasing or decreasing
respectively. These claims thus have a temporal relationship to an action but
do not require a causal correlation between the stack increasing or
decreasing and the action. Claim 17, on the hand, has a causal relationship
between writing a dirty cache line and determining whether a stack is
increasing or decreasing.
For the foregoing reasons, Appellants have not persuaded us of error
in the rejection of independent claim 16.

Appeal 2010-006785
Application 10/631,185

13
REMAINING OBVIOUSNESS REJECTIONS
The Examiner finds that: (1) Shen and O’Connor teach all the
limitations in claims 12 and 14 (Ans. 15-16) and (2) Shen, Flake, and
Ebrahim teach all the limitations of claim 5 (Ans. 16-17). For these
rejections, Appellants refer to the previous arguments of claims 1 and 11.
App. Br. 14. The issues before us, then, are the same as those in connection
with claims 1 and 11, and we refer Appellants to our previous discussion.
For the foregoing reasons, Appellants have not persuaded us of error in the
additional rejection of claims 5, 12, and 14.

NEW GROUND OF REJECTION UNDER 37 C.F.R. § 41.50(b)
Under 37 C.F.R. § 41.50(b), we enter a new ground of rejection under
35 U.S.C. § 103 for claim 13. Claim 13 is rejected under 35 U.S.C. 103(a)
as being obvious over Shen and O’Connor. As stated previously, claim 13
depends from claim 12. Thus, we adopt and include the Examiner’s
undisputed findings and conclusions concerning Shen and O’Connor
collectively teaching the limitations of claim 12. Ans. 15-16. Additionally,
we also adopt the Examiner’s undisputed finding of how Shen teaches the
limitations in claim 13. Ans. 5.

CONCLUSION
Under § 102, the Examiner did not err in rejecting claim 11, but erred
in rejecting claims 13 and 17-20.
Under § 103, the Examiner did not err in rejecting claims 1-10, 12,
and 14-16.
A new ground of rejection has been entered for claim 13 under § 103.
Appeal 2010-006785
Application 10/631,185

14

DECISION
The Examiner’s decision rejecting claims 1-20 is affirmed-in -part.
This decision contains a new ground of rejection pursuant to 37
C.F.R. § 41.50(b). 37 C.F.R. § 41.50(b) provides that “[a] new ground of
rejection . . . shall not be considered final for judicial review.”
37 C.F.R. § 41.50(b) also provides that Appellants, WITHIN TWO
MONTHS FROM THE DATE OF THE DECISION, must exercise one of
the following two options with respect to the new ground of rejection to
avoid termination of the appeal as to the rejected claims:
(1) Reopen prosecution. Submit an appropriate
amendment of the claims so rejected or new evidence relating
to the claims so rejected, or both, and have the matter
reconsidered by the examiner, in which event the proceeding
will be remanded to the examiner. . . .
(2) Request rehearing. Request that the proceeding be
reheard under § 41.52 by the Board upon the same record. . . .
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv).

AFFIRMED-IN-PART
37 C.F.R. § 41.50(b)

babc