Appeal No. 2001-0653
Application 08/820,736
recite any organizational structure which defines over Profiler.
Profiler stores profile information about each module of the
program and each area (routine or procedure) in the module.
Appellants further argue (Br9-10):
Profiler, in particular, is focused only on the
creation of profile data, and not how that data is logically
arranged in storage. As shown, for example, at pages 90-92
of Profiler, profile statistics for a program are stored and
retrieved in .TFS files, each of which organizes profile
data on a program-by-program basis. Moreover, as shown at
pages 47 and 48 of Profiler, the concept of a "module
window" is discussed, explaining how source modules in a
program may be loaded into a module window. Nonetheless,
even though Profiler discusses the possibility of parsing a
program into multiple modules, profile data storage is still
performed in program-wide files. Profiler recognizes the
concept of a module, yet does not disclose or suggest any
mechanism for collecting and storing such information even
on a module-by-module basis, much less on a procedure-by-
procedure basis, as is specifically recited in claim 1.
These arguments are not persuasive. Claim 1 does not recite
how procedure specific data is logically arranged in storage.
Profiler stores profile information about each module of the
program and each area (routine or procedure) in the module as
evidenced by the fact that it can display the profile statistics
according to the module and area (procedure) in the Execution
Profile window (pp. 13-14 & 55-56). The procedure counter and
time areas shown in Figure 4.1 (p. 130) clearly show that
Profiler stores procedure specific data.
- 17 -
Page: Previous 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Next
Last modified: November 3, 2007