Ex Parte BowersDownload PDFPatent Trial and Appeal BoardSep 16, 201410907759 (P.T.A.B. Sep. 16, 2014) Copy Citation 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 Copy with citationCopy as parenthetical citation