Zhang, Xuezhi

Patent Trials and Appeals Board

Dec 30, 2020

2019003776 (P.T.A.B. Dec. 30, 2020)

UNITED STATES PATENT AND TRADEMARK OFFICE
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www.uspto.gov
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
12/762,298 04/16/2010 Xuezhi Zhang 3151
95766 7590 12/30/2020
Xuezhi Zhang
402 Building 28, Cuishan Lantian Yuan
Huanan Country Garden, Yingbin Road Panyu District
Guangzhou, Guangdong, 511442
CHINA
EXAMINER
WONG, LUT
ART UNIT PAPER NUMBER
2121
NOTIFICATION DATE DELIVERY MODE
12/30/2020 ELECTRONIC
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address(es):
xzhang@crystalsoftcorp.com
zhang.anthony@live.cn
zhang.anthony@live.com
PTOL-90A (Rev. 04/07)

UNITED STATES PATENT AND TRADEMARK OFFICE

BEFORE THE PATENT TRIAL AND APPEAL BOARD

Ex parte XUEZHI ZHANG

Appeal 2019-003776
Application 12/762,298
Technology Center 2100

Before JENNIFER L. McKEOWN, MATTHEW J. McNEILL and
MICHAEL T. CYGAN, Administrative Patent Judges.

CYGAN, Administrative Patent Judge.

DECISION ON APPEAL
STATEMENT OF THE CASE
Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the
Examiner’s decision to reject claims 5–6, 8–12, 14–15, and 17–21, which
are all of the pending claims in the application. Appeal Br. 25–27 (Claims
App.). We have jurisdiction under 35 U.S.C. § 6(b).
We AFFIRM-IN-PART.

1 We use the word “Appellant” to refer to “applicant” as defined in
37 C.F.R. § 1.42. Appellant identifies the real party in interest as inventor
XUEZHI ZHANG. Appeal Br. 2.
Appeal 2019-003776
Application 12/762,298

2
CLAIMED SUBJECT MATTER
The claimed invention generally relates to commands for computers
or other electronic appliances. Appeal Br. 2. Specifically, to conditional
commands, which are executed only when certain conditions are satisfied or
after some other commands have been executed. Id. The claimed invention
also relates to conditional buttons, which are keyboard buttons for electronic
appliances that are usually grayed out when the conditions for their
execution are not met. Id.
Independent claim 5 is illustrative:
5. A method, comprising:
receiving a conditional command or the command of a
conditional button from a user interface; wherein the
conditional command is activated or enabled for execution
when the condition for its execution is not met;
performing a conditional test embedded in the command
to determine if the condition for executing the command is met;
displaying automatically help embedded in the command
and pertinent to a current situation, according to a status check
or conditional test embedded in the command if there are more
than one situations, if the condition is not met; and
executing the command if the condition is met.
Appeal Br. 25 (Claims App.).
Independent claim 14 recites a storage medium having limitations
similar to that of claim 5. Appeal Br. 26. Dependent claims 6, 8–12, 15,
and 17–21 each incorporate the limitations of their respective independent
claims. Id. at 25–27. Claims 1–4, 7, 13, 16, and 22 were cancelled during
prosecution. Id. at 25–27.
Appeal 2019-003776
Application 12/762,298

3
REFERENCES
Name Reference Date
Sukaviriya et al.
(Sukaviriya)
“Automatic Generation of
Textual, Audio, and
Animated Help in UIDE:
The User Interface Design
Environment”
1994
Kinnucan, Jr.
(Kinnucan)
US 7,636,887 B1 Dec. 22, 2009

REJECTIONS
Claims 5 and 14 are rejected under 35 U.S.C. § 102(a)(1) as being
anticipated by Sukaviriya.
Claims 5–6, 8–12, 14–15, 17–21 are rejected under 35 U.S.C. § 103 as
being obvious over the combination of Appellant’s Admitted Prior Art and
Kinnucan.
OPINION
1. Anticipation
We have reviewed the Examiner’s anticipation rejection (Final Act.
17–20, Ans. 35–55) in light of Appellant’s contentions that the Examiner
has erred (Appeal Br. 17–24, Reply Br. 55–83). We are not persuaded by
Appellant’s contention of Examiner error in rejecting claims 5 and 14 under
35 U.S.C. § 102(b) over Sukaviriya. We begin with claim 5.
At issue is whether Sukaviriya discloses the “displaying . . .” step of
claim 5, i.e., “displaying automatically help embedded in the command and
pertinent to a current situation, according to a status check or conditional test
Appeal 2019-003776
Application 12/762,298

4
embedded in the command if there are more than one situations, if the
condition is not met.” Appeal Br. 18.
The Examiner finds that limitation is disclosed by Sukaviriya’s
display of a pop up help dialog box in response to a user attempting to select
a “Weg OK” button, where a conditional test determines whether pre-
conditions are satisfied such that the widget should be enabled. Final Act.
18. The Examiner further points to Sukaviriya’s description of “current
interface programming practice where semantic conditions are embedded in
callback routines of widgets,” and “questions being embedded as part of an
application interface.” Id at 19 (citing Sukaviriya section 3). The Examiner
further finds support in Sukaviriya’s description of HelpTalk:
Currently, HelpTalk generates answers to only two types of
questions: “Why is this widget disabled?” and “How can one
invoke this widget?” Through the representation, a widget is
associated with actions represented in the UIDE’s knowledge
base of the application interface. . . . these questions . . . could
be embedded as part of an application interface. The way in
which these questions are embedded depends solely on the
designer’s preference.
Sukaviriya, p. 46, Section 3; Ans. 37. The Examiner further explains that
this description of Sukaviriya means that the help message is displayed only
if the Weg OK button is disabled. Ans. 38. The Examiner further explains
that the UIDE (User Interface Design Environment) combines information
from different yet combined components to provide context-sensitive help.
Id. at 40.
Appellant first argues that Sukaviriya’s help is not embedded in the
command. Appeal Br. 18–19. Appellant argues that the help is produced by
the “HelpTalk” system that is separate from the application program. Id.
Appeal 2019-003776
Application 12/762,298

5
Appellant argues that claim 5 requires help to be embedded in the
conditional command in the sense that the help must be inside the same
program/software product as the conditional command. Id. at 19. Appellant
thus argues that Sukaviriya does not disclose the “embedded” limitation,
because Sukaviriya’s help is instead generated by a separate element, the
UIDE technical specifications. Id. Appellant further argues that
“embedding help in the Blackboard outside the program” is a different
technical limitation than “[e]mbedded in the commands.” Reply Br. 58.
Appellant points to Sukaviriya’s Fig. 6, which shows the “Application
Program” in a separate box from the “HelpTalk” box, as reproduced below:

Figure 6 shows an “Application Program” oval connected by a line to a box
containing a UIDE Knowledge Base having an Application Model, an
Interface Model, and associated Blackboards. The UIDE Knowledge Base
box is connected by an arrow to a “HelpTalk” box, which is connected to a
screen interface through an Animation Server. The UIDE Knowledge Base
is also connected to the screen interface through a User Interface Controller.
A portrayal of a human face gazes at the screen interface.
We agree with the Examiner’s finding that Sukaviriya’s help is
embedded in the command. As highlighted by the Examiner, Sukaviriya
Appeal 2019-003776
Application 12/762,298

6
discloses details of “HelpTalk.” Ans. 39 (“This paper only presents
HelpTalk, the help generation part of the project”)(quoting Sukaviriya 44).
The Examiner further identifies HelpTalk as providing the conditional test
associated with the conditional button. Ans. 38 (“Attempting to select the
button labeled ‘Weg OK’ . . . causes the help dialog box to pop up.
HelpTalk detects two unsatisfied pre-conditions for the corresponding
action.”) (quoting Sukaviriya 46). Based on the structure and context of
Sukaviriya, the Examiner finds the help to be embedded in the command.
Final Act. 19; Ans. 37.
Appellant characterizes Sukaviriya in a manner consistent with the
Examiner’s findings. Appellant points to HelpTalk as “produc[ing] all the
help,” (Appeal Br. 18) and that the help messages “are generated from
technical specifications in HelpTalk (Appeal Br. 21)(emphasis added).
Appellant further points to HelpTalk as containing the conditional button,
stating that the “help message is displayed when a user attempt[s] to select
the disabled ‘WegOK’ button in HelpTalk.” Id. at 18.
The Examiner’s finding is consistent with the Specification. The
Specification describes that conditional commands and conditional buttons
may be “embedded with various intelligent descriptions, operation guides,
and/or help,” such that operation guides or help are displayed when the
conditions for execution are not satisfied. Spec. ¶ 16. The Specification
neither defines nor describes “embedded” as requiring any further computer
architectural feature. The Specification, thus, describes an embedded help as
being displayed as the result of a conditional command. Id. Thus, we
determine that the Examiner’s finding is consistent with the Specification.
Appeal 2019-003776
Application 12/762,298

7
We determine that the Examiner’s finding is further supported by
examples in Sukaviriya and the Specification. Sukaviriya describes an
example of how specific help sentences are displayed responsive to a
conditional determination. Sukaviriya 50 (providing the example “exist ([a],
[b]) True: ‘Object (a) of type (b) exists.’ False: ‘There is no object of type
(b),’” where b may be, for example, “[GATE]”). The description would be
generated by HelpTalk and “displayed in a dialog box as a text string.” Id.
Sukaviriya’s description is consistent with that provided in an exemplary
embodiment of the Specification, describing pseudo-code for a command
that contains “Case DVD: Display ‘The remote control is set to control
DVD, press the TV button to control TV.’ Case VCR: Display ‘The remote
control is set to control VCR, press the TV button to control DVD.’” Spec.
8–9. An exemplary described embodiment, even if it is the sole
embodiment, is not limiting on the claims where the claims do not recite
such limitations. See Superguide Corp. v. DirecTV Enterprises, Inc., 358
F.3d 870, 875 (Fed. Cir. 2004). However, the similarities in the nature of
Sukaviriya’s example of displaying help in response to a conditional
command and the Specification’s example of embedding help in a
conditional command further support the Examiner’s finding that Sukaviriya
discloses help embedded in a conditional command.
In view of the Appellant’s characterization of Sukaviriya, the
Specification, and consistent with the examples provided therein, we agree
with the Examiner’s characterization of Sukaviriya as providing, via
HelpTalk, a conditional button associated with a conditional test that, where
Appeal 2019-003776
Application 12/762,298

8
unsatisfied, automatically generates a help explanation embedded therein.
Final Act. 18–20.
Appellant argues that Sukaviriya’s help is not embedded in the
conditional command, because HelpTalk, which generates the help, is
separated from the application program. Appeal Br. 19 (citing Sukaviriya
Fig. 6, p. 49). Appellant further argues that Sukaviriya’s blackboards, which
contain facts that allow HelpTalk to complete context-sensitive help
messages, are also separated from the application program. Id. at 18 (citing
Sukaviriya Fig. 6, p. 49). However, the plain language of the claim requires
only that the help is embedded in the conditional command. As discussed
above, in Sukaviriya, both the help and the conditional command are located
in HelpTalk. Thus, as explained by the Examiner, HelpTalk’s separation
from the application program is not persuasive to show that the help (located
in HelpTalk) is not embedded in the conditional command (also located in
HelpTalk). See Ans. 37 (“whether adaptive help is separated from software
product is irrelevant . . . to the claim at issue.”). Accordingly, we are not
persuaded by Appellant that the Examiner errs in finding Sukaviriya to
describe help embedded in a conditional command.
Appellant further argues that “the help message will not be displayed
if the message and the routine displaying it are embedded in the disabled
button itself which cannot activate.” Id. at 18–19. Appellant cites to
Figure 2 of Sukaviriya, showing a “help message displayed when a user
attempt[s] to select the disabled “Weg OK” button in HelpTalk.” Id. at 18.
Figure 2 is shown below:
Appeal 2019-003776
Application 12/762,298

9

The text accompanying Figure 2 describes the figure as follows:
HelpTalk's response to the user's attempt to select the disabled
"Weg OK" button in an InterCity Express (ICE) train
reservation system. In this application, user can repeatedly
select cities of origin and destination until the route is
satisfactory. The "Weg OK" button becomes enabled when
both origin and destination cities have been selected.
Appellant asserts, “[a]nything inside a disabled command cannot be
executed.” Id. at 59. Appellant further points to Sukaviriya’s statement that
user is “attempting to select a command,” not selecting a command. Id. at
67. Appellant further argues that Sukaviriya’s use of “automatically” refers
not to how help is displayed to users, but instead, to “the automatic
generation of textual help from the technical specification in the knowledge
base.” Id. at 69.
We are not persuaded by Appellant’s argument that Sukaviriya does
not describe automatic display of help to users. The Examiner points to
Appeal 2019-003776
Application 12/762,298

10
Sukaviriya’s receiving the command of a conditional Weg OK button, where
the Weg OK command (to confirm a route selection) is executed if specified
conditions (both an origin city and destination city were chose) are met.
Final Act. 17–20; Ans. 38. Where the specified conditions are not met, help
is automatically displayed, explaining why the Weg OK button has not
operated in the desired manner. Ans. 37. Any interaction with the Weg OK
button automatically causes one of those two actions, depending on whether
the specified conditions are met; i.e., by performance of a conditional test.
Id. at 38 (citing Sukaviriya section 3, Fig. 2).
Nor are we persuaded by Appellant’s argument that Sukaviriya’s Weg
OK button is termed “disabled,” and cannot perform an embedded test and
display embedded help because “anything inside a disabled command cannot
be executed.” Reply Br. 59. Although Sukaviriya describes the button as
disabled, the claim requires that the conditional command, not the button
itself, be activated or enabled for execution. Furthermore, Appellant’s focus
on the “disabled” term in Sukaviriya does not explain how any act in the
claimed method is missing from the acts described in Sukaviriya. Elements
must be arranged as required by the claim, but this is not
an ipsissimis verbis test, i.e., identity of terminology is not required. In re
Bond, 910 F.2d 831 (Fed. Cir. 1990). Instead, the Examiner’s
characterization of Sukaviriya’s operation is consistent with Appellant’s
explanation of a conditional button; i.e., one that is “always operable, but it
will cause no action if pressed down when conditions for their execution
are not satisfied because there is not any implementation for cases when
conditions for their execution are not satisfied.” Reply Br. 3.
Appeal 2019-003776
Application 12/762,298

11
Accordingly, we are not persuaded that the Examiner erred in finding
Sukaviriya to disclose help embedded in a command.
Appellant presents further arguments not reflected in the claim
language. Appellant argues that Sukaviriya’s method is not pertinent to any
situation because it is pertinent to various situations, and therefore “not
general and natural language that are preferred by the general public as in
the present invention.” Id. at 70. Appellant further argues that Sukaviriya’s
method only applies to user interfaces designed and created within the tool
UIDE, whereas the present invention applies to all situations. Id. at 73–74.
Because these arguments and not commensurate with the scope of claim 5,
we are not persuaded.
Accordingly, we sustain the rejection of claim 5, and claim 14 not
separately argued. See 37 C.F.R. § 41.37(c)(1)(iv).

2. Obviousness
We have reviewed the Examiner’s obviousness rejections (Final
Act.8–17, Ans. 13–35) in light of Appellant’s contentions that the Examiner
has erred (Appeal Br.9–17, Reply Br. 2–55). We are persuaded by
Appellant’s contention of Examiner error in rejecting claims 5–6, 8–12, 14–
15, and 17–21 under 35 U.S.C. § 103.
We begin with the “displaying automatically help” limitation in claim
5. Appellant argues that Kinnucan, which the Examiner relies upon to teach
that limitation, requires the user to request the help information rather than
automatically displaying the help information to the user. Appeal Br. 9
(citing Kinnucan 6:55–57 (“Clicking the Help button . . . displays an
Appeal 2019-003776
Application 12/762,298

12
adaptive HTML help document”)). The Examiner finds Kinnucan to teach
automatically displaying help because the claimed limitation does not
exclude user action to invoke help. Ans. 13.
We do not agree with the Examiner that the scope of “displaying
automatically help” includes a user making a request for a help document.
For this reason, we do not sustain the Examiner’s obviousness rejection of
claim 5. All of the other claims rejected as being obvious contain the same
“displaying automatically help” language, either expressly or through
incorporation of the limitations in claims from which they depend.
Consequently, we do not sustain the Examiner’s obviousness rejection of
claims 5–6, 8–12, 14–15, and 17–21.
We further determine that the Examiner’s rejection of claim 5 is in
error for two additional reasons. We turn first to the claim language, “help
embedded in the command,” where the command is a conditional command
or the command of a conditional button. Appellant argues that the Examiner
points not to help embedded in a conditional command, but instead to a help
document that contains embedded scripts. Appeal Br. 9. The Examiner
points to language from Kinnucan that purports to “clearly disclose[] the
claimed limitation where adaptive help with conditional scripts are
embedded”). Ans. 15 (citing Kinnucan 5:25–35).
We are persuaded by Appellant’s argument. The claim does not recite
a help document having embedded conditional scripts, but instead, help that
is displayed automatically responsive to a condition of the conditional
command, where the help is embedded in that command. The Examiner
instead points to a help document, which as discussed above, is displayed in
Appeal 2019-003776
Application 12/762,298

13
response to user action and not in response to a condition of the conditional
command. Consequently, the Examiner has not shown Kinnucan to teach or
suggest “displaying automatically help embedded in the command.” Nor
has the Examiner shown this limitation to be taught or suggested by the
other applied art in the combination, referred to as Appellant’s admitted
prior art (APA).
Accordingly, the Examiner has not shown this limitation to be taught
by the combination of references applied in the obviousness rejection, and
the obviousness rejection of claim 5 is in error for this reason. Because all
of the other claims rejected as being obvious contain the same “help
embedded in the command” language, either expressly or through
incorporation of the limitations in claims from which they depend. For this
additional reason, we do not sustain the Examiner’s obviousness rejection of
claims 5–6, 8–12, 14–15, and 17–21.
We turn finally to the Examiner’s reliance on APA, in the form of the
’298 Specification’s originally filed Figure 2 and paragraphs 4–8. Final Act.
8, 16. Appellant states that Figure 2 contained some elements of prior
technology, but also erroneously contained steps labeled “Conditional Test”
and “Consult Manual,” which were not in the prior technology. Appeal Br.
10. Appellant explains that those steps were “drawn to the Applicant’s own
thinking in the process of making the present invention.” Id. Appellant cites
to MPEP 2129 for the proposition that, “even if labeled as ‘prior art,’ work
of the same inventive entity may not be considered prior art against the
claims.” Id. at 10–11.
Appeal 2019-003776
Application 12/762,298

14
The Examiner acknowledges that MPEP recites, “[i]in the absence of
another credible explanation, examiners should treat such subject matter as
the work of another.” Ans. 17 (quoting MPEP 2129). The Examiner finds
that the original Specification labels Figure 2 as “prior technology,” and that
there is no evidence or suggestion that such prior technology is Appellant’s
own work. Id. at 17–18.
We are persuaded by Appellant’s explanation. The Specification as
filed stated, “Figure 2 is the flow chart for conditional buttons for the prior
technology.” Spec. 3 (April 16, 2010). Appellant has explained that Figure
2 contains both prior technology and two of Appellant’s own conditional
steps. Appeal Br. 10. Appellant, who is the sole inventor, has signed the
document containing this explanation, thus certifying the veracity of
statements therein subject to the penalties set forth under 18 U.S.C. § 1001.
Id. at 30; 37 C.F.R. § 11.18(b)(1).
Under Appellant’s explanation, the Specification may be understood
as stating that Figure 2 is the flow chart for conditional buttons, which are
Appellant’s own work, for (as applied to) the prior technology. In view of
Appellant’s explanation, we determine that the Examiner has not shown
Figure 2, in its entirety, to be the prior work of another. Nor has the
Examiner shown an alternate statutory basis for finding Figure 2 to be prior
art. Consequently, the Examiner has erred in finding Figure 2 to be prior art
by Applicant’s admission. See Riverwood Inter. Corp. v. R. A. Jones & Co.,
Inc., 324 F. 3d 1346, 1354 (Fed. Cir. 2003) (finding “the proposition that a
reference can become prior art by admission[ to be] inapplicable when the
subject matter at issue is the inventor’s own work”). Because all of the
Appeal 2019-003776
Application 12/762,298

15
claims rejected as being obvious rely on the Examiner’s finding that Figure
2 is prior art, we do not sustain the Examiner’s obviousness rejection of
claims 5–6, 8–12, 14–15, and 17–21. Because we have determined, for the
abovementioned reasons, that the rejections are in error, we need not address
Appellant’s further arguments concerning these claims.

CONCLUSION
For the above-described reasons, we sustain the Examiner’s rejection
of claims 5 and 14 as being anticipated under 35 U.S.C. § 102(b) and reverse
the Examiner’s rejection of claims 5–6, 8–12, 14–15, and 17–21 as being
obvious over the applied references under 35 U.S.C. § 103(a).

DECISION SUMMARY
In summary:
Claims
Rejected
35 U.S.C. § Reference(s)/Basis Affirmed Reversed
5, 14 102(b) Sukaviriya 5, 14
5–6, 8–
12, 14–
15, 17–21
103(a) AAPA, Kinnucan 5–6, 8–12,
14–15,
17–21
Overall
Outcome
5, 14 6, 8–12,
15, 17–21

AFFIRMED-IN-PART