Ex Parte Bowers

Patent Trial and Appeal Board

Sep 16, 2014

10907759 (P.T.A.B. Sep. 16, 2014)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte MATTHEW ALAN BOWERS
____________

Appeal 2012–001805
Application1 10/907,759
Technology Center 2100
____________

Before DONALD E. ADAMS, MELANIE L. McCOLLUM, and
ULRIKE W. JENKS, Administrative Patent Judges.

JENKS, Administrative Patent Judge.

DECISION ON APPEAL
This is an appeal under 35 U.S.C. § 134 involving claims to a method,
a computer program, and a computer system for generating a user interface
help dialog based on determining the status of system parameters. The
Examiner has rejected the claims as obvious. We have jurisdiction under
35 U.S.C. § 6(b). We reverse.
STATEMENT OF THE CASE
The Specification provides that it is common for certain menu items
to be available only if particular criteria are met, “[t]rivial examples of this

1 Appellant identifies Tektronix International Sales GmbH as the Real Party
in Interest. (App. Br. 1.)
Appeal 2012–001805
Application 10/907,759

2
include the ‘print’ menu item not being available if it is detected that no
printer is connected to the computer system and the ‘copy’ function in a
word processor not being available if no text has been selected.” (Spec.
2: ¶ 3.) The help box for unavailable menu items provides the same
information “as is the case when the menu item is available or no help
facility at all is provided. In either case, no information is provided to the
user that may explain why the menu item in question is not available in the
first place.” (Id.) One aspect of the claimed invention is a “help dialog
[display] having a content dependent on the status of the evaluated system
parameters.” (Id. at ¶ 10.) “Consequently the complete help dialog may
differ for the same command option depending on the status of the computer
system, reflecting the different reasons why the command option is
disabled.” (Id. at ¶ 18.)
Claims 1–7 and 9–13 are on appeal, and can be found in the Claims
Appendix of the Appeal Brief. Claim 1 is representative of the claims on
appeal, and reads as follows (emphasis added):
A method of generating a user interface help dialog for a
computer system, the computer system having a plurality of
system parameters, the plurality of system parameters including
the state of the computer system hardware, the user interface
including a plurality of command options that may be enabled
or disabled and a cursor for indicating one of the command
options, the method comprising:
determining the identity of a single disabled command
option to which the cursor indicates, each command option
having an associated help routine specifying a subset of the
system parameters that relate to the associated command
option, wherein a status of the subset of system parameters
contributes to whether the command option is enabled or
disabled;
Appeal 2012–001805
Application 10/907,759

3
in response to determining the identity of the single
disabled command option, directly determining the status of
each of the system parameters within the subset of the system
parameters, and
generating a help dialog to be displayed to the user the
content of which is dependent on the status of the evaluated
system parameters.
The Examiner has rejected claims 1–7 and 9–13 under 35 U.S.C.
§ 103(a) as unpatentable over Hubbard2 in view of DeStefano3 and McLean.4
The Examiner takes the position that Hubbard teaches “the evaluation
of system parameters to determine a[] help dialog output, but doesn’t
specifically teach that the display help information is customized according
to the specific parameters that are evaluated.” (Ans. 6.) According to the
Examiner the combination of “Hubbard and DeStefano teach displaying the
reasons for grayed-out items based on the state information of managed
devices (seemingly state of software stored on hardware, which appears to
be by association state of the hardware), but don’t specifically teach the
status being based upon the state of hardware itself.” (Id. at 7.) The
Examiner looks to McLean for teaching “graying out unavailable options
and displaying options” once the appropriate hardware becomes available.
(Id. 7.) “All references are directed toward marking menu entries as
unavailable based upon identified related system parameters alluding to
such, and McLean is relied upon to further show the state of the art, where
hardware monitoring to determine command availability is well known.”
(Id. at 26.) The Examiner concludes that based on the combination of

2 Hubbard et al., US 2005/0125744 A1, issued June 9, 2005.
3 DeStefano et al., US 7,020,842 B1, issued Mar. 28, 2006.
4 McLean, US 2002/0099456 A1, published July 25, 2002.
Appeal 2012–001805
Application 10/907,759

4
references one of ordinary skill in the art “would have been motivated to
make such a combination because this allows a user system to base
availability of screen elements on the availability of the hardware device that
supports their operation.” (Id. at 7.)
Does the preponderance of evidence of record support the Examiner’s
conclusion that the claims are obvious?

Findings of Fact
FF1. Hubbard disclosed:
The GUI program 120 tracks manipulation of the pointing
device 114 and moves a cursor on the display 110 in
accordance therewith. Should the cursor be detected hovering
over an unavailable menu item, the unavailability reason code
associated with that menu item (as provided by the managed
device 106 and retained in the menu table 145) may be used as
an index to locate a textual message in the unavailability reason
table 147.
(Hubbard 3: ¶ 43; see also Ans. 5.)
FF2. Hubbard disclosed:
Managed device 106 may determine the reason code for a menu
item presently disabled in accordance with the present state of
the managed device 106 or other aspects of the system 100.
The reason code determination may therefore be dynamic and
reflect present conditions of the system 100 or of the device
106. As the system status changes or the device status changes,
a disabled menu item may be enabled or the reason for
disabling (i.e., the reason code) may be changed. Such changes
may be communicated between the management system 102
and the managed device 106 through well known asynchronous
communication and event processing techniques.
(Hubbard 4: ¶ 45; see also Ans. 5, 23.)
App
App

repro
(Hub
menu
infor
“[W
help
menu
Ans.
eal 2012–0
lication 10
FF3. H
duced bel
In this il
two item
menu ite
as a pull
down m
displaye
unavaila
menu ite
tooltip b
bard 4: ¶
item (i.e
mation in
]hen a curs
ful messag
item and
6.)
01805
/907,759
ubbard dis
ow:
lustration,
s: CONFI
m 402 has
down men
enu 412 is
d in a diffe
ble. A cur
m, and an
ox 408.
51; see als
., “save” m
tooltip box
or is detec
e is displa
/or possibl
closed a h
a menu 40
G 402 and
been sele
u 412. A
a “save” m
rent font a
sor 406 ha
unavailab
o Ans. 5–6
enu item 4
408.” (H
ted hoveri
yed indica
e remedia
5
elp dialog
0 has been
POWER
cted, causi
mong the m
enu item
nd grayed
s been det
ility reason
.) “[A] u
04) to gen
ubbard 5:
ng over an
ting a reas
l actions.”
box as sho
displaye
401. The
ng display
enu item
404 which
–out to in
ected hov
has been
ser may rig
erate the
¶ 52; see
unavailab
on for una
(Hubbard
wn in Fig

d consistin
CONFIG
of a subm
s of the pu
has been
dicate that
ering over
displayed
ht click th
reason/rem
also Ans.
le menu i
vailability
5: ¶ 55; s
. 4,
g of
enu
ll
it is
this
in a
e disabled
edy
6.)
tem, a
of the
ee also

Appeal 2012–001805
Application 10/907,759

6
FF4. DeStefano disclosed a computer program for providing
“dynamic assistance for disabled user interface resources. Code for
disabling controls is identified. A state of the identified control is changed
from disabled to disabled with assistance. Assistance text is provided to
explain why control is disabled. Code is provided for correcting the
condition for disabling control.” (DeStefano col. 2, ll. 7–12; see also
Ans. 6.)
FF5. McLean disclosed
When the user interface device provides this scan interface to a
user, the network manager 73a registers a device listener
requesting that it be informed by the JINI look–up service 11 of
the availability on the network of a suitable printer and, when it
is advised by the JINI look–up service that a suitable printer is
available, then the COPY button is . . . made active indicating
to the user that he can generate a copy of the scanned
document. As another possibility, the COPY button may not be
present at all until the network manager is advised of the
existence of a suitable printer.
[0124] Such a device listener may also be registered by the
network manager where, for example, the processor–controlled
machine being controlled is a digital camera, in which case, for
example, a PRINT button will be greyed–out or not present
until the device listener determines the existence of a suitable
printer.
(McLean 11: ¶¶ 123–124; see also Ans. 7.)

Principle of Law
“[O]bviousness requires a suggestion of all limitations in a claim.”
CFMT, Inc. v. Yieldup Int’l Corp., 349 F.3d 1333, 1342 (Fed. Cir. 2003)
(citing In re Royka, 490 F.2d 981, 985 (CCPA 1974)).
Appeal 2012–001805
Application 10/907,759

7
Analysis
The Examiner interprets the claim as requiring “a system in which
subsequent to a user’s selection of a disabled command option, acquired
system parameters statuses associated with the disabled command option
are used to diagnose the problem and provide a help dialog.” (Ans. 16.)
Appellant contends that the Examiner’s claim interpretation is in error
as the plain meaning of the claim requires “that the status of each of the
system parameters is directly determined in response to (i.e., subsequent to)
determining the identity of the single disabled command option.” (Reply
Br. 3) According to Appellant, it is unclear from the Examiner’s
interpretation whether the Examiner means “to include embodiments in
which pre–acquired system parameters could be used subsequent to a user’s
selection of the disabled command option to diagnose the problem.” (Reply
Br. 2.)
“[D]uring examination proceedings, claims are given their broadest
reasonable interpretation consistent with the specification.” In re Hyatt, 211
F.3d 1367, 1372 (Fed. Cir. 2000). The claim language at issue is
“determining the identity of a single disabled command option to which the
curser indicates” and “in response to determining the identity of the single
disabled command option, directly determining the status of each of the
system parameters within a subset of the system parameters” as recited in
claim 1.
The Specification provides that “[t]he user typically selects the
desired command by placing a displayed cursor using a cursor control
device, such as a mouse or trackball, over the menu item or button and
Appeal 2012–001805
Application 10/907,759

8
operating a selection switch on the cursor control device e.g. ‘clicking’ using
a mouse button.” (Spec. 1: ¶ 1.) According to the Specification:
In operation a user controls the cursor on the GUI to place it
over a desired command option, typically displayed as an entry
in a drop-down menu. If the command option is unavailable, in
which case it is still displayed but is greyed-out or dimmed, the
identity of the command option is determined by the OS
[operating system] and is communicated to the help processor
8. Each command option has an associated help routine HRn
stored in the help routine library and the help processor
retrieves the help routine associated with the command option
identified by the OS. Each help routine specifies one or more
parameters of the system 6 that relate to the associated
command option and which are to be evaluated by the help
processor 8.
(Spec. 6: ¶ 18).
Consistent with the Specification, we find that the limitation of
“determining the identity of a single disabled command option to which the
curser indicates”, as recited in claim 1, encompasses placing the curser on a
menu item that is not available for activation. This unavailable menu item is
visually distinct from the other live (active) menu items, and selection of the
item occurs by hovering over the item with a cursor or by clicking on the
item with a mouse button. This selection, according to the Specification,
will notify the operating system to communicate with the help processor and
run the help routine. Accordingly, we interpret the limitation of
“determining the identity” to be the act of selecting a non-active menu item
with the cursor.
The Specification further provides that “[t]he help processor evaluates
the status of the system parameters according to the retrieved help routine.”
(Spec. 7: ¶ 18). “Each help routine specifies one or more parameters of the
Appeal 2012–001805
Application 10/907,759

9
system 6 that relate to the associated command option and which are to be
evaluated by the help processor 8.” (Spec. 6–7: ¶ 18). Consistent with the
Specification, we find that the limitation “in response to determining the
identity of the single disabled command option, directly determining the
status of each of the system parameters . . .” as recited in the claim is the act
of selecting a non-active menu item which in turn activates the help routine
that runs a diagnostic of the system parameters associated with that menu
item. We interpret the limitation of “directly determining” to be the
evaluation of system parameters that is initiated with the start of the help
routine which in turn is activated by selecting a non-active menu item.
Appellant contends that Hubbard “does not directly determine the
status of system parameters related to an unavailable menu item in response
to the cursor hovering over the unavailable menu item.” (App. Br. 9)
[Hubbard] do[es] not disclose that the system determines the
“system parameter” (e.g., the presence or absence of edits since
the last “Save” command) by determining the identity of the
disabled command option (e.g., “Save”) but, rather, that the
system determines a reason code (see Hubbard et al. at
paragraph 0048) that is itself dependent on the “system
parameter.”. . . Instead, the system determines a reason code,
which is previously set (i.e., recorded in the menu table)
according to whether such edits have been made.
(Reply Br. 5.)
We find that Hubbard disclosed selecting an item by hovering a curser
over a menu item (FF1). In response to hovering over a non-available menu
item Hubbard provides information about the unavailability reason code
associated with the menu item in the form of a tool tip box (FF 1, 3).
Hubbard also discloses that the reason code can change (i.e. be dynamic)
Appeal 2012–001805
Application 10/907,759

10
depending on current conditions of the system (FF2). “As the system status
changes or the device status changes, a disabled menu item may be enabled
or the reason for disabling (i.e., the reason code) may be changed.” (FF2)
“Menu table 145 is a repository that may contain menu item names and other
parameters for each menu item for a menu or toolbar to be presently
displayed by GUI program 120. Included in the information may be flags
indicating that a corresponding menu item is presently unselectable
(disabled) or selectable (enabled).” (Hubbard 3: ¶ 40.) Thus, the tool tip
box not only provides the reason for the unavailability of a menu item, but
this box may also provide information about remedial actions in order to
activate the unavailable item (FF3).
The Examiner acknowledges that “the menu table itself is not a
system parameter itself, however, the contents of the menu table are system
parameters that are dynamically updated as the conditions of the system or
of the device change.” (Ans. 22.) The Examiner explains, “when a selection
of an unavailable command is identified that the system pulls the dynamic
reasoning for the unavailable command, based upon the relevant conditions
of the system or device.” (Id. at 20–21.) The reason code “may therefore be
dynamic and reflect present conditions of the system or of the device.” (Id.
at 20.)
We find that the Appellant has the better position. Although, we
agree with the Examiner that Hubbard’s device is dynamic in the sense that
the reason code menu is updated in response to changes in the system of the
managed device (FF2), we find insufficient evidentiary support for the
position that this dynamic updating occurs in response to a curser
placement/selection process by a user. The unavailability message as
Appeal 2012–001805
Application 10/907,759

11
displayed in a tool tip box and is based on retrieved information from the
menu table (FF 1, 3). As discussed above, we interpret the limitation of
“directly determining” to be the evaluation of the system parameters that is
gathered upon initiating the help routine by detecting the selection of a non-
available menu item. What is missing from the Examiner’s analysis is some
explanation or direction to persuasive evidentiary support that establishes
that in response to selecting the unavailable menu item Hubbard first updates
the information in the menu table and then pulls that information into the
tool tip box. A finding of obviousness requires a suggestion of all
limitations. CFMT, 349 F.3d at 1342. The missing element in Hubbard is
some indication that the dynamic updating of the menu table is in response
to the user making a selection as opposed to routine, periodic operating
system updates. Here, the Examiner has not directed us to this missing
element and has not provided an articulated reason why this element would
necessarily be present in Hubbard.
The Examiner looks to DeStefano for teaching “that the display help
information is customized according to the specific parameters that are
evaluated” (Ans. 6), and McLean for teaching “the status of [hardware]
being based on the state of the hardware itself” (id. at 7). We agree with the
Appellant’s position that neither reference provides the missing limitation of
“directly determining” the system parameters after identifying the disabled
command (see App. Br. 15–20). A finding of obviousness requires a
suggestion of all limitations, here, the combination of references does not
provide for the limitation of “directly determining” system parameters
associated with a non-active menu item after selection of that menu item.
Appeal 2012–001805
Application 10/907,759

12
As the Examiner has failed to adequately articulate any other rationale
explaining how the combination of references discloses the limitation of
“directly determining the status of parameters” after identifying a disabled
menu item, we are constrained to reverse the rejection that relies on
Hubbard, DeStefano, and McLean.

SUMMARY
We reverse the rejection of claims 1–7 and 9–13 under 35 U.S.C.
§ 103(a) over Hubbard in view of DeStefano and McLean.

REVERSED

lp