Zhang, Xuezhi

Patent Trials and Appeals Board

Mar 25, 2021

2019003776 (P.T.A.B. Mar. 25, 2021)

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 03/25/2021
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
03/25/2021 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 REHEARING
STATEMENT OF THE CASE
Appellant1 filed a Request for Rehearing under 37 C.F.R. § 41.52 on
February 21, 2021 (hereinafter “Request” or “Req. Reh’g”), requesting that
we reconsider our Decision on Appeal of December 30, 2020 (hereinafter
“Decision” or “Dec.”) with respect to the rejections under 35 U.S.C. § 102.
In the Decision, we affirmed the Examiner’s anticipation rejection under 35
U.S.C. § 102(b) of claims 5 and 14, and reversed the Examiner’s

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
obviousness rejection under 35 U.S.C. § 103 of claims 5, 6, 8–12, 14, 15,
and 17–21. We reconsidered our Decision on the anticipation rejections of
claims 5 and 14 in light of Appellant’s Request for Rehearing. For the
reasons explained below, Appellant’s arguments do not persuade us that we
misapprehended or overlooked any point of fact or law in rendering our
Decision. Hence, we deny Appellant’s request to modify our Decision.

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 greyed 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.).
Appeal 2019-003776
Application 12/762,298

3
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, but are not addressed on the rehearing request. Id. at 25–27. Claims
1–4, 7, 13, 16, and 22 were cancelled during prosecution. Id. at 25–27.

REFERENCES
Name Reference Date
Sukaviriya et al.
(Sukaviriya)
“Automatic Generation of
Textual, Audio, and
Animated Help in UIDE:
The User Interface Design
Environment”
1994

REJECTION ON REHEARING
Claims 5 and 14 are rejected under 35 U.S.C. § 102(b) as being
anticipated by Sukaviriya.

OPINION
In their Request for Rehearing, Appellant submits that important
appellant arguments made in their Appeal Brief were “either wrongly
interpreted or intentionally omitted.” Req. Reh’g 1. We address each of
the points raised by Appellant in turn.
1. Anticipation requires every element
Appellant argues that the Board’s decision affirming the Examiner’s
anticipation rejection of claims 5 and 14 was based only on one step of each
claim, and ignored the other steps. Req. 2. Appellant argues that the
Board’s decision did not mention the status check or conditional test for the
Appeal 2019-003776
Application 12/762,298

4
current situation being embedded in conditional commands, as argued at
page 19 of the Appeal Brief. Id. In their Appeal Brief, Appellant argued
that Sukaviriya’s status check or conditional test is “inside the blackboard
which is totally separated from the programs/software products . . . and
therefore totally separated from the commands inside programs/software
products.” Appeal Br. 19.
We are not persuaded that we overlooked these elements. In the
Decision, we agreed with the Examiner that components located within the
blackboard or HelpTalk were not considered to be separate elements from
the conditional command or the command of a conditional button from a
user interface. We explained that “the Specification neither defines nor
describes ‘embedded’ as requiring any further computer architectural
feature” beyond that “operation[s] guides or help are displayed when the
conditions for execution are not satisfied.” Dec. 6. We noted that the
Examiner “identifies HelpTalk as providing the conditional test associated
with the conditional button.” Id. We further noted, “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. (citing Appeal Br. 18).
Further, we agreed with the Examiner that the conditional test
determining whether preconditions are satisfied such that the Weg OK
button should be enabled, or preconditions are not satisfied such that a help
dialog box should be displayed was consistent with Sukaviriya’s
descriptions of embedding as “semantic conditions are embedded in callback
routines of widgets,” and “questions being embedded as part of an
application interface.” Dec. 4. Thus, in our Decision, we explained that
Appeal 2019-003776
Application 12/762,298

5
HelpTalk contained each of the help message, the conditional test, and the
conditional button, and that we were not persuaded that locating help
messages or command in HelpTalk caused any element to be separate such
that the Examiner erred in finding those elements to be “embedded” in the
command of the Weg OK button.
We further note that “status check” and “conditional test” are
presented in the alternative. “When a claim covers several structures or
compositions, either generically or as alternatives, the claim is deemed
anticipated if any of the structures or compositions within the scope of the
claim is known in the prior art.” Brown v. 3M, 265 F.3d 1349, 1351 (Fed.
Cir. 2001). Thus, the claim is anticipated if either the “status check” or the
“conditional test” is disclosed by Sukaviriya. Thus, our determination that
“conditional test” is disclosed in the claimed manner by Sukaviriya is
sufficient for anticipation regardless of whether “status check” is also
disclosed.
Accordingly, we are not persuaded that we overlooked Appellant’s
argument that the location of the conditional test inside the blackboard of
Sukaviriya was separate from the commands inside programs or software
products such that the conditional test was not “embedded” within the
command of Sukaviriya’s conditional button.
2. Conditional Command vs. Conditional Button
Appellant argues that Sukaviriya is in the “conditional command”
category, not the “conditional button” category. Req. Reh’g 3, 6. Appellant
characterizes Sukaviriya as dealing with software GUIs, which the
Specification defines as conditional commands. Id. (citing Spec. ¶¶ 5–7).
Appellant argues that Sukaviriya’s button is not a “conditional button”
Appeal 2019-003776
Application 12/762,298

6
because it is not a “real key[] or button[] on [an] electronic device[].” Id. at
6.
Appellant’s argument does not alter our determination of anticipation.
“When a claim covers several structures or compositions, either generically
or as alternatives, the claim is deemed anticipated if any of the structures or
compositions within the scope of the claim is known in the prior art.”
Brown v. 3M, 265 F.3d at 1351. Claims 5 and 14 each recite, “receiving a
conditional command or the command of a conditional button from a user
interface.” Appeal Br. 25 (Claims App.). Because the claims recite a
conditional command or command of a conditional button as alternatives,
only one of those alternatives need be shown in the prior art to anticipate the
claim. Although Sukaviriya uses the term “button” (for example, the “Weg
OK button”) to describe the entity in a user interface from which a command
is received, even if Sukaviriya’s button is read on the conditional command
limitation, one of the alternative claim limitations would still be met. Thus,
although Appellant argues that the conditional button category is
“completely missing in” Sukaviriya (Req. Reh’g 3) (emphasis omitted),
Appellant’s characterization of Sukaviriya’s button as being in the
conditional command category does not show error in our determination of
anticipation of claims 5 and 14.
3. Argument 1 of the Appeal Brief
Appellant provides several arguments based upon Argument 1 of the
Appeal Brief, which we address in turn.
First, Appellant argues that Sukaviriya’s help message and the
conditional tests for its display “must be outside[] the disabled ‘Weg OK’
widget because anything inside a disabled widget cannot be executed.” Req.
Appeal 2019-003776
Application 12/762,298

7
Reh’g 6 (citing arguments made at Appeal Brief 19). Appellant argues that
Sukaviriya instead discloses generating help messages in HelpTalk from the
UIDE Knowledge base that are provided to users through the Animation
Server. Id. at 7 (citing Sukaviriya 49, Fig. 6), 9. Appellant argues that
Figure 6 of Sukaviriya shows information flow, in the direction of arrows,
from the UIDE Knowledge Base to the HelpTalk module, and in turn to the
User interface, but no information flow between the Application Program
and the UIDE Knowledge Base. Id. at 9–10. Appellant argues that the
portrayed information flow in Figure 6 thereby indicates that help
information and context information and related tests are not embedded in
conditional commands (widgets) inside Application Programs. Id. at 10
(citing Sukaviriya 49, Fig. 6).
We are not persuaded that we overlooked these features of Sukaviriya.
We addressed the specific argument that “anything inside a disabled
command cannot be executed” in our Decision. Dec. 10. As discussed
above, in our Decision we were not persuaded that locating help messages or
command in HelpTalk caused any element to be separate such that the
Examiner erred in finding those elements to be “embedded” in the command
of the Weg OK button. Supra, p. 4. Although Appellant argues that the help
message and the routine displaying it must be outside Sukaviriya’s Weg OK
button because it is “disabled,” Sukaviriya clearly describes that the Weg
OK button maintains active help functionality. Dec. 6 (quoting Sukaviriya
46, “Attempting to select the button labeled ‘Weg OK’ . . . causes the help
dialog box to pop up. Help Talk detects two unsatisfied pre-conditions for
the corresponding action”), 10. The button and the command issued
therefrom; i.e., the command to display route information, is “disabled” only
Appeal 2019-003776
Application 12/762,298

8
in that the route information will not display unless the pre-conditions
(selections of origin and destination cities) are satisfied for the route
determination. Dec. 10; Sukaviriya, Fig. 2.
With respect to Appellant’s argument that Sukaviriya’s Figure 6
shows no information flow between the application program and the UIDE
Knowledge base, we are not persuaded that we overlooked this feature of
Sukaviriya in our Decision. We first note that neither claim 5 nor claim 15
recite an “application program.” Rather, in our Decision, we relied on the
help and conditional test in Sukaviriya’s HelpTalk. Dec. 6. As discussed
above, in our Decision we were not persuaded that locating help messages or
command in HelpTalk caused the Examiner to err in finding those elements
to be “embedded” in the command of the Weg OK button. Supra, p. 4.
Second, Appellant argues that widgets (or commands or buttons) and
the modules or commands or codes they represent in Sukaviriya are disabled
when their pre-conditions are not satisfied. Req. Reh’g 7. Appellant cites to
Sukaviriya’s statement that “a widget was enabled only when its pre-
conditions were satisfied.” Id. (citing Sukaviriya 45). Appellant
distinguishes the limitation requiring the conditional command be activated
or enabled for execution when conditions for its execution is not satisfied is
separate from the claim limitation requiring that a help message be
embedded in a conditional command. Id. Appellant further alleges that it
would be against common practice, common sense, and would be “totally
wrong” to find that the module or codes inside the disabled “Weg OK”
button can still be executed, because if a widget is disabled, the module or
codes for the command or button is also disabled. Id. at 7–8 (citing
Sukaviriya 45, Spec. ¶ 7). Appellant further reasons that there would be no
Appeal 2019-003776
Application 12/762,298

9
point to having a disabled widget while commands within the widget are still
executable. Id. at 8.
We are not persuaded that we overlooked this feature of Sukaviriya.
As discussed, Sukaviriya clearly describes that the Weg OK maintains active
help functionality. Dec. 6 (quoting Sukaviriya 46, “Attempting to select the
button labeled ‘Weg OK’ . . . causes the help dialog box to pop up. Help
Talk detects two unsatisfied pre-conditions for the corresponding action”),
10. The button is “disabled” only in that the route information will not
display unless the pre-conditions (selections of origin and destination cities)
are satisfied for the route determination. Dec. 10; Sukaviriya, Fig. 2. The
mere fact that Sukaviriya uses the term “disabled” does not contradict or
nullify the above-cited disclosure.
Appellant appears to be arguing against a generic conventional
disabled command, rather than the actual disclosure of Sukaviriya. We note
Appellant’s Specification provides an example of a conventional command
that is greyed and deactivated. Spec. ¶ 19. In this conventional system,
users must “consult the user manual or the help system” to find out how to
activate that command. Id. Such action requires a search from “among a
vast amount of information” that is “troublesome, time-consuming, and
sometimes futile.” Id. However, unlike Appellant’s conventional greyed,
deactivated command that creates a dead end for the user, Sukaviriya’s
greyed, deactivated command automatically triggers help for the user, based
on a conditional test that determines which unsatisfied condition caused the
command to be deactivated and determining the specific help message to
display to the user to explain how to activate that command.
Appeal 2019-003776
Application 12/762,298

10
Accordingly, we are not persuaded that we overlooked the
functionality of the “disabled” widget of Sukaviriya in light of its express
disclosure of the actions performed when the widget is attempted to be
selected.
Third, Appellant argues that Sukaviriya’s “Weg OK” button is a
conditional command and not a conditional button, in view of the definition
in the Specification. Req. Reh’g 8. Appellant argues that prior art
conditional commands are disabled when conditions for their execution are
not met, which is the case in Sukaviriya. Id. (citing Appeal Br. 20).
Appellant argues that this further verifies that help information and related
conditional tests and/or status checks for displaying it are not embedded in
the “Weg OK” button or any other widgets in Sukaviriya. Id. Appellant
argues that if the help information and conditional tests of Sukaviriya were
embedded in the Weg OK button, then the help would not be able to be
displayed because the button or widget is disabled and prevented from
execution. Id. (citing Appeal Br. 18).
We addressed the distinction between a conditional command and a
conditional button above. Supra, pp. 5–6. We addressed the Appellant’s
“embedded” argument above. Supra, pp. 6–7. We addressed the
Appellant’s “disabled” argument (Dec. 10), and provided further explanation
above. Supra, pp. 8–9.
Fourth, Appellant argues that conditional tests for the pre-conditions
for disabling or enabling widgets are usually performed by a command
update module rather than the widget itself. Req. Reh’g 10. Appellant
states that the command update module is also a callback routine of the
widget. Id. In support, Appellant cites to Sukaviriya’s statement, “current
Appeal 2019-003776
Application 12/762,298

11
interface programming practice where semantic conditions are embedded in
callback routines of widgets.” Id. (citing Decision 4 (stating, “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 the ‘Weg OK’ button,
where a conditional test determines whether pre-conditions are satisfied such
that the widget should be enabled.”)). Appellant argues that a conditional
test, or any other code, inside a disabled widget cannot be performed until it
is enabled. Id. Appellant further states that in the prior art, a disabled
widget is not able to enable itself. Id. at 11. Appellant further draws an
analogy to “tooltips which always display when users move the mouse
pointer over the tool or widget which is either enabled or disabled.” Id. at 12
(emphasis omitted).
Additionally, Appellant argues that the Decision misinterpreted
Sukaviriya’s statement, “They could be embedded as part of the application
interface. The way in which these questions are embedded depends solely
on the designer’s choice.” Req. Reh’g 11. Appellant argues that this
statement refers to embedding questions in the form of help requests, not
help messages or conditional tests, in the application interface. Id.
Appellant alleges that the lack of further detail in Sukaviriya supports
Appellant’s position that the Examiner is merely speculating without
support. Id.
We addressed the Appellant’s “embedded” argument above, finding
no error in the Examiner’s determination that Sukaviriya’s providing a
conditional test in HelpTalk anticipates the claimed “conditional test
embedded in the command.” Supra, pp. 6–7. Appellant’s argument that
Sukaviriya discloses “semantic conditions embedded in callback routines of
Appeal 2019-003776
Application 12/762,298

12
widgets” appears to support the Examiner’s determination, showing those
conditions to be embedded in a portion (the callback routines) of
Sukaviriya’s widgets.
In our Decision, we noted Appellant’s “pseudo-code” for an
exemplary embodiment. Dec. 7 (citing Spec. 8–9). We found that pseudo-
code to be an embodiment not limiting on the claims, but consistent with
Sukaviriya’s example of providing help based on a conditional test. Id.
(citing Sukaviriya 50). In response to Appellant’s argument concerning
embedding in a callback routine, we note that Appellant’s pseudo-code uses
an “if . . . else . . . Case []A . . . Case [B] . . . ” structure in which the help is
provided in various cases of the “else” logic. Spec. 8–9. Appellant has not
explained how a condition embedded in a callback routine differs from the
embedded pseudo-code “Case” and “else” conditions which are called to in
the described embodiment. Thus, Appellant’s additional argument in the
Request does not persuasively explain how embedding a conditional test in a
callback routine is outside the broadest reasonable definition in view of
Appellant’s Specification, of the claimed “conditional test embedded in the
command.”
We addressed the Appellant’s “disabled” argument (Dec. 10), and
provided further explanation above. Supra, pp. 8–9. To the extent that
Appellant here cites analogies of persons, conventional disabled widgets,
and tooltips, these are neither set forth in the claims nor relied upon in
Sukaviriya for anticipation.
Accordingly, we are not persuaded that we have overlooked any
argument or fact raised in Argument 1 of the Appeal Brief.
Appeal 2019-003776
Application 12/762,298

13
4. Argument 2 of the Appeal Brief
Argument 2 alleges that Sukaviriya does not disclose “wherein the
conditional command is activated or enabled for execution when the
condition for its execution is not met,” as recited in claims 5 and 14. Req.
Reh’g 12. Appellant characterizes this as “a new creative approach in the art
contrary to the common practice or customary treatment of disabling
conditional commands when conditions for their execution are not satisfied
in prior art to prevent execution of the commands, which could lead to an
undefined suspension state.” Id. Appellant cites Specification ¶ 7 for
support. Id. Appellant argues that in Sukaviriya, conditional commands are
disabled when pre-conditions are not satisfied. Id. at 13.
We have addressed this argument above in terms of greyed
commands, and provide further clarification here. During patent
examination, claims are “given their broadest reasonable interpretation
construction in light of the specification as it would be interpreted by one of
ordinary skill in the art.” Philips v. AWH Corp., 415 F.3d 1303, 1316 (Fed.
Cir. 2006).
The Specification describes commands (for both computers or other
electric appliances) as conditional commands so long as “they can be
invoked and executed only when certain conditions are satisfied or after
some other commands have been executed.” Spec. ¶ 6. The Specification
further describes disabled commands as those that conventionally are greyed
out and not automatically providing further action, such as help for the user.
Id. ¶ 19. The Specification provides an example of the claimed conditional
commands, in which the command is
Appeal 2019-003776
Application 12/762,298

14
not updated by a command update system and is always
activate[d] for operation. When this command is invoked by
the user, the program flows into a conditional test: “Are there
drawing groups selected?”; if “YES”, the condition is satisfied,
the Group Property dialog box or property sheet is displayed for
the user to modify the group properties of the selected drawing
group or groups. If “NO”, i.e., conditions are not satisfied, the
command cannot be executed directly, the program then flows
to another conditional test . . . . Users proceed to according to
the operation guides and then invoke the “group Properties”
command again. “Are there drawing groups selected?” test will
then be satisfied and the command is executed directly.
Id. ¶ 20.
As noted in the Decision, Sukaviriya provides a conditional command
that is active, but not executed, when its preconditions are not satisfied. Our
decision stated,
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.
Dec. 10. We further noted that Sukaviriya disclosed that the user may
proceed according to the displayed help to “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.” Id. at
9.
Accordingly, Sukaviriya’s conditional command operates in the same
manner as the claimed conditional command, as construed in light of the
Specification. Consequently, Appellant has not persuaded us that we have
overlooked any argument or fact raised in Argument 2 of the Appeal Brief.
Appeal 2019-003776
Application 12/762,298

15
5. Argument 6 of the Appeal Brief
Argument 6 alleges that the Board has not appreciated that
Appellant’s invention “’applies to all situations’ . . . ‘as depicted in the
claims’ . . . for all software and can be used much more widely including
conditional buttons on electronic devices.” Req. Reh’g 13. Appellant
argues that Sukaviriya is limited to the UIDE environment, and cannot be
applied to conditional buttons having real keys, and thus cannot anticipate
the full scope of the claimed invention. Id. at 14.
In our Decision, we addressed the first argument, finding it “not
reflected in the claim language.” Dec. 10. We have addressed Appellant’s
“conditional button” argument above. Supra, pp. 5–6. “When a claim
covers several structures or compositions, either generically or as
alternatives, the claim is deemed anticipated if any of the structures or
compositions within the scope of the claim is known in the prior art.”
Brown v. 3M, 265 F.3d at 1351. Thus, where the claim covers a structure
that may be in a UIDE environment, as Sukaviriya discloses, the claim is
anticipated by Sukaviriya’s disclosure of that structure in the UIDE
environment. Consequently, we are not persuaded that we overlooked any
argument or fact raised in Argument 6 of the Appeal Brief.
6. Argument 3 of the Appeal Brief
Argument 3 alleges that the Board has not appreciated that
Appellant’s invention delivers pertinent help “automatically without users
having to invoke a help command.” Req. Reh’g 15 (citing the
“displaying” step in claims 5 and 14). Appellant argues that in Sukaviriya,
the user must request help before help is provided. Id. Appellant points to
the user’s action in attempting to select the disabled “Weg OK” button,
Appeal 2019-003776
Application 12/762,298

16
which causes the help dialog box to pop up, as the user invoking a help
command. Id.
We addressed this argument in our Decision, stating,
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).
Dec. 10.
Appellant points to the user’s action in Sukaviriya of selecting the
“Weg OK” button as invoking a help command. Req. Reh’g 15. However,
the user is selecting a desired “Weg OK” command – to show a route
between origin and destination – not selecting a particular help question.
Dec. 10; see supra, p. 14. The action by the user in Sukaviriya is equivalent
to the Specification’s example of the user selecting a conditional command
for which the preconditions are not satisfied, thus causing display of the
relevant help guide to the user. Spec. ¶¶ 19–20; supra, pp. 13–14.
Accordingly, we are not persuaded that we overlooked any argument
or fact raised in Argument 3 of the Appeal Brief.
7. Page 22 of the Appeal Brief
Appellant argues that anticipation under § 102 means “every
element[] of a claim is known and taught in a single quoted reference.” Req.
Reh’g 15. Appellant argues that if Sukaviriya had disclosed all of the
elements of Appellant’s claims 5 and 14, then they must have made the
present invention. Id. Appellant argues that, because Sukaviriya created the
Appeal 2019-003776
Application 12/762,298

17
“inferior” HelpTalk, Sukaviriya “did not anticipate the present invention at
all.” Id. at 15–16 (emphasis omitted).
A claim is “deemed anticipated if any of the structures or
compositions within the scope of the claim is known in the prior art.”
Brown v. 3M, 265 F.3d at 1351. Appellant’s argument that no person
associated with Sukaviriya’s publication had ever produced an identical
product to Appellant has not been established in fact, but even if true, would
not prevent anticipation of Appellant’s claimed invention by a disclosure of
a method whose steps lie within the scope of those claims. Consequently,
we are not persuaded that we overlooked any matter of fact or law.

CONCLUSION
Based on the analysis above, we have granted Appellant’s request
to the extent that we have reconsidered our Decision. For the reasons
explained above, however, we decline to modify our Decision.
Outcome of Decision on Rehearing:
Claims
Rejected 35 U.S.C. § Reference(s)/Basis Denied Granted
5, 14 102(b) Sukaviriya 5, 14
Final Outcome of Appeal After Rehearing:
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
Appeal 2019-003776
Application 12/762,298

18
Claims
Rejected 35 U.S.C. § Reference(s)/Basis Affirmed Reversed
Overall
Outcome 5, 14
6, 8–12, 15,
17–21
TIME PERIOD FOR RESPONSE
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). See
37 C.F.R. § 41.50(f).

REHEARING DENIED