Ex Parte Levine et al

Board of Patent Appeals and Interferences

Jun 25, 2009

11083248 (B.P.A.I. Jun. 25, 2009)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte FRANK ELIOT LEVINE, MILENA MILENKOVIC, and
ROBERT J. URQUHART
____________

Appeal 2009-002176
Application 11/083,248
Technology Center 2800
____________

Decided:1 June 25, 2009
____________

Before JOSEPH F. RUGGIERO, CARLA M. KRIVAK, and KARL D.
EASTHOM, Administrative Patent Judges.

EASTHOM, Administrative Patent Judge.

DECISION ON APPEAL

1 The two-month time period for filing an appeal or commencing a civil
action, as recited in 37 C.F.R. § 1.304, begins to run from the decided date
shown on this page of the decision. The time period does not run from the
Mail Date (paper delivery) or Notification Date (electronic delivery).
Appeal 2009-002176
Application 11/083,248

2
STATEMENT OF THE CASE
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s final
rejection of claims 1-20 (Br. 4). We have jurisdiction under 35 U.S.C.
§ 6(b).
We affirm.
According to Appellants, the invention employs traces to obtain
performance data for a data processing system. A trace contains information
about the process. The trace information varies depending on the profiling
or analysis performed, and may include data about the execution of a code or
records about events generated during execution of a code. In response to
detecting a trace event, if identifiers for the trace event match recorded
identifiers for a record of previously recorded trace events, a count in the
record is increased. (Spec. 1:3rd ¶; Spec. 2:last ¶ to Spec. 3:end of 1st ¶;
Spec. 6).
Claim 1, illustrative of the invention, follows:
1. A method in a data processing system for generating trace data, the
method comprising:
responsive to detecting a trace event generated by a processor,
determining whether an identifier for the detected trace event matches a
recorded identifier in a record for a set of trace events previously generated
by the processor;
responsive to determining that the identifier for the detected trace
event matches a recorded identifier in the record for the set of trace events
previously generated by the processor, increasing a count in the record; and
storing the record.
The Examiner relies on the following prior art references:
Martin US 3,906,454 Sep. 16, 1975
Shah US 6,148,437 Nov. 14, 2000
Appeal 2009-002176
Application 11/083,248

3
Hussain US 6,658,416 B1 Dec. 2, 2003

The Examiner rejected:
Claims 1, 7, 9, 13, and 19 under 35 U.S.C. § 102(b) based upon
Martin;
Claims 2, 5, 10, 14, and 17 under 35 U.S.C. § 103(a) based upon
Martin and Shah; and
Claims 3, 4, 6, 8, 11, 12, 15, 16, 18, and 20 under 35 U.S.C. § 103(a)
based upon Martin and Hussain.
ISSUES
Appellants’ and the Examiner’s arguments and rejections present the
following issues:
Did Appellants demonstrate that the Examiner erred in finding that
Martin discloses 1) detecting trace events, 2) responsive to the detection,
determining whether an identifier for the trace event matches a recorded
identifier, and 3) responsive to the match, increasing a record count?

FINDINGS OF FACT (FF)
Appellants’ Disclosure
1. “The information in a trace may vary depending on a particular
profiling or analysis that is to be performed” (Spec. 3:1st ¶). Appellants
generally refer to various types of traces to track events in a computer (see
generally Spec. 2 to Spec. 5:“Description of Related Art”). “For example, a
trace tool may log every entry into, and every exit from, a module,
subroutine, method, function, or system component” (Spec. 3:2nd ¶).
Appeal 2009-002176
Application 11/083,248

4
2. “By keeping counts of events, rather than generating a record for
every event, this mechanism reduces the amount of trace data placed into a
trace” (Spec. 20:2nd ¶).
3. “A record is a unit of information related to an event” (Spec. 3:1st
¶).
Martin
4. Martin’s system monitors hardware and software events to
determine system efficiency and reliability (col. 1, ll. 14-17, ll. 46-49). “[A]
hardware event is the occurrence of a discrete happening or change of state
of one of the hardware elements of the data processing system. A software
event . . . is the execution of a selected command or instruction in the
programmed sequence of such commands and instructions.” (Col. 1, ll. 24-
26).
5. “[M]onitored data entries are directed by program instructions
inserted in the instruction stream. Each such monitored event includes
identification information as well as parameter values.” (Col. 1, ll. 53-57).
“This event may comprise, for example, the beginning of execution of
particular subroutine loop entrance or exit, or any other programmed events
which it is desired to monitor” (col. 5, ll. 64-67). Only select pieces of data
reflecting the operation of the monitored computer 10 are stored (col. 5, ll.
43-46; Fig. 1).
6. Software and hardware events are counted (col. 4, ll. 14-16; col.
18, ll. 22-33).
7. The system counts software and stores events from computer 10
that have been matched by matcher section 14 in further accordance with
Appeal 2009-002176
Application 11/083,248

5
store logic 22 (col. 4, ll. 56-66; col. 18, ll. 22-32; Fig. 1; see also col. 16, l.
51 to col. 17, l. 12; col. 19, ll. 22-25; Fig. 20).
8. Martin’s matcher section 14 operates as follows:
The matcher logic section 14 compares each data word
delivered to it with the initialization constants supplied to it on
leads 16 and determines whether or not the received software
event data work is acceptable for storage or for a control
function. Matcher logic section 14 controls store control filters
15 to initiate, terminate and otherwise control storage of those
data words which are to be permanently stored in the monitor.
Initialization constants are supplied to store control filters 15 on
leads 17 to further determine which particular software events
are to be stored.

(Col. 4, ll. 56-66).

PRINCIPLES OF LAW
“[T]he examiner bears the initial burden, on review of the prior art or
on any other ground, of presenting a prima facie case of unpatentability.” In
re Oetiker, 977 F.2d 1443, 1445 (Fed. Cir. 1992). “[A]fter the PTO
establishes a prima facie case of anticipation . . . , the burden shifts to
appellant to prove that the subject matter shown to be in the prior art does
not possess the characteristic relied upon.” In re King, 801 F.2d 1324, 1327
(Fed. Cir. 1986)(internal quotation omitted). “It is axiomatic that
anticipation of a claim under § 102 can be found only if the prior art
reference discloses every element of the claim.” Id. at 1326. “A reference
anticipates a claim if it discloses the claimed invention ‘such that a skilled
artisan could take its teachings in combination with his own knowledge of
the particular art and be in possession of the invention.’” In re Graves, 69
Appeal 2009-002176
Application 11/083,248

6
F.3d 1147, 1152 (Fed. Cir. 1995) (quoting In re LeGrice, 301 F.2d 929, 936
(CCPA 1962) (emphasis deleted).
“[T]here must be some articulated reasoning with some rational
underpinning to support the legal conclusion of obviousness.” In re Kahn,
441 F.3d 977, 988 (Fed. Cir. 2006). “‘On appeal to the Board, an applicant
can overcome a rejection by showing insufficient evidence of prima facie
obviousness . . . .’” Id. at 985-986 (quoting In re Rouffet, 149 F.3d 1350,
1355 (Fed. Cir. 1998).

ANALYSIS
Claims 1, 7, 9, 13, and 19
Appellants, focusing on claim 1, contend that Martin does not
anticipate claims 1, 7, 9, 13, and 19.2 First, Appellants “dispute” that “the
events being monitored in Martin can be construed as trace events” (Br. 10).
However, as the Examiner reasoned, without response by Appellants,
Appellants do not provide any special definition for a trace event (Ans. 8).
Appellants also do not explain why Martin’s events are not trace events.
Appellants disclose monitoring a wide variety of selected trace events which
vary depending on the process monitored (see FF 1). Martin similarly
discloses monitoring selected software and hardware events having
programmed identification information therein to monitor computer 10
processes for efficiency and reliability (FF 4-6).

2 Appellants group claims 1, 7, 9, 13, and 19 together and rely on arguments
presented for claim 1 (see Br. 9, 14). Accordingly, claim 1 is selected to
represent the group. See 37 C.F.R. § 41.37(c)(1)(vii).

Appeal 2009-002176
Application 11/083,248

7
Therefore, Martin reasonably supports the Examiner’s finding (Ans.
8-9) that Martin’s specifically monitored hardware and software events
constitute trace events. Appellants’ mere “dispute,” without more, does not
demonstrate error in the Examiner’s prima facie case of anticipation. “The
problem in this case is that the appellants failed to make their intended
meaning explicitly clear.” In re Morris, 127 F.3d 1048, 1056 (Fed. Cir.
1997). “It is the applicants’ burden to precisely define the invention, not the
PTO’s.” Id.
Second, Appellants initially stated that Martin discloses counting only
software events (Br. 12). However, as the Examiner reasoned (Ans. 9, 10),
Martin discloses counting both hardware and software events (FF 6, 7) and
Appellants claim does not preclude counting hardware events.
Subsequently, (Br. 13), Appellants agreed that Martin does disclose counting
software events, but maintained that “Martin still does not disclose or
suggest counting matches between an identifier for detected trace events and
an identifier for trace events previously generated by a processor.”
Appellants’ latter argument appears to be based on their assertion that
Martin’s “matcher logic section . . . compares a data word with initialization
constants supplied to the logic section” (Br. 10). In other words, Appellants’
argument reduces to the assertion that counting matches to the initialization
constants in Martin does not amount to counting matches for trace events
previously generated by a processor as required by claim 1.
In response to Appellants’ argument, the Examiner found:
While initialization constants may be set for an event before the
event occurs, once an event occurs one time, the initialization
constants correspond to an “identifier in a record for a set of
trace events previously generated by the processor.” Therefore,
Appeal 2009-002176
Application 11/083,248

8
the matcher logic section would determine whether the event
identification signals, which correspond to “an identifier for the
detected trace event,” match the initialization signals, which
correspond to “an identifier in a record for a set of trace events
previously generated by the processor.”

(Ans. 9).

Appellants do not challenge the Examiner’s findings or reasoning.
According to Appellants, “[a] record is a unit of information related to an
event” (FF 3). As such, Martin’s initialization constants (see FF 8)
correspond to “a recorded identifier in a set of trace events previously
generated for the processor,” because as the Examiner reasoned (Ans. 9),
“once an event occurs one time,” the event has been previously generated by
the computer 10 processor (see FF 5). For example, Martin’s “particular
subroutine loop entrance or exit” with its embedded “identification
information” necessarily repeats itself (see id.), thereby creating repeated
“identifier[s] for the detected trace.” Each identifier or several identifiers,
match to initialization constants, and upon matching, the constants constitute
“a recorded identifier . . . for the set of trace events previously generated by
the processor.”3
Finally, Appellants similarly assert (Br. 14), without clear
explanation, that Martin does not disclose: “responsive to determining that

3 The breadth of claim 1 allows for two alternative interpretations: 1)
Martin’s identification information constitutes the recited “identifier,” while
Martin’s initialization constants constitute the recited “recorded identifier;”
and 2) (vice versa) Martin’s identification information constitutes the recited
“recorded identifier,” while Martin’s initialization constants constitute the
recited “identifier.”
Appeal 2009-002176
Application 11/083,248

9
the identifier for the detected trace event matches a recorded identifier in the
record for the set of trace events previously generated by the processor,
increasing a count in the record.” However, as the Examiner reasoned (Ans.
10), Martin’s counter increases a count in the record responsive to a software
or hardware event match (FF 7, see also FF 6, 8). (Martin’s initialization
constants and identification information correspond to the “recorded
identifier” and “identifier” for reasons explained above (see also supra n.3)).
Therefore, Appellants have not demonstrated Examiner error with
respect to claim 1, nor of claims 7, 9, 13, and 19, not separately argued.
Claims 2, 5, 10, 14, and 17
Appellants rely (Br. 14-16) on the asserted deficiencies of Martin with
respect to claims 1, 9, and 13 to show error in the Examiner’s obviousness
rejection of the claims 2, 5, 10, 14, and 17 based on Martin and Shah.
Accordingly, for the reasons outlined above with respect to claims 1, 9, and
13, Appellants’ nominal arguments fail to demonstrate Examiner error in the
rejection of claims 2, 5, 10, 14, and 17.
Claims 3, 4, 6, 8, 11, 12, 15, 16, 18, and 20
Appellants similarly rely (Br. 16-17) on the asserted deficiencies of
Martin with respect to claims 1, 9, and 13 to show error in the Examiner’s
obviousness rejection of the above claims based on Martin and Hussain.
Accordingly, for the reasons outlined above with respect to claims 1, 9, and
13, Appellants have failed to demonstrate Examiner error in the rejection of
claims 3, 4, 6, 8, 11, 12, 15, 16, 18, and 20.

Appeal 2009-002176
Application 11/083,248

10
CONCLUSION
Appellants did not demonstrate that the Examiner erred in finding that
Martin discloses 1) detecting trace events, 2) responsive to the detection,
determining whether an identifier for the trace event matches a recorded
identifier, and 3) responsive to the match, increasing a record count.

DECISION
We affirm the Examiner’s decision rejecting claims 1-20.
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

gvw

IBM CORP (YA)
C/O YEE & ASSOCIATES PC
P. O. BOX 802333
DALLAS, TX 75380