Ex Parte Zhang et al

Patent Trial and Appeal Board

Sep 16, 2013

11946416 (P.T.A.B. Sep. 16, 2013)

UNITED STATES PATENT AND TRADEMARK OFFICE
__________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
__________

Ex parte GUOXUAN ZHANG, TOM LAM, and TAM DAO
__________

Appeal 2011-008620
Application 11/946,416
Technology Center 2100
__________

Before FRANCISCO C. PRATS, JEFFREY N. FREDMAN, and
SHERIDAN K. SNEDDEN, Administrative Patent Judges.

FREDMAN, Administrative Patent Judge.

DECISION ON APPEAL
This is an appeal1 under 35 U.S.C. § 134 involving claims to a
computer method for a help utility. The Examiner rejected the claims as
failing to comply with the written description requirement and as
anticipated. We have jurisdiction under 35 U.S.C. § 6(b). We affirm-in-
part.

1 Appellants identify the Real Parties in Interest as Sony Corp. and
Sony Electronics, Inc. (See App. Br. 2.)
Appeal 2011-008620
Application 11/946,416

2
Statement of the Case
Background
“The present invention relates generally to using a help utility
identifier as a parameter in a software application to facilitate extraction of a
help utility from a library of help utilities” (Spec. 1).
The Claims
Claims 1-17 are on appeal. Claim 1 is representative and reads as
follows:
1. A method, comprising:
generating at least one guided help utility for an associated
software application to be run on a computer operating system, the
help utility including a “show me” option and a “do it” option,
wherein if the “show me” option is selected the help utility leads a
user through a task step-by-step, allowing the user to complete a task
for which help is sought, and wherein if the “do it” option is selected a
computer processor automatically executes the task, pausing only
when the user must make a choice;
associating a unique identifier with the guided help utility to
facilitate accessing the utility through the associated software
application;
passing the unique identifier through as a parameter in the
source code of the associated software application; and
invoking the help utility in response to a user selection.

The issues
A. The Examiner rejected claim 7 under 35 U.S.C. § 112, first paragraph
as failing to comply with the written description requirement (Ans. 3-4).
B. The Examiner rejected claims 1-17 under 35 U.S.C. § 102(b) as
anticipated by Finnigan2 (Ans. 4-9).

2 Finnigan et al., 2005/0114785 A1, published May 26, 2005.
Appeal 2011-008620
Application 11/946,416

3
A. 35 U.S.C. § 112, first paragraph – Written Description
The Examiner finds that
Claim 7 recites: ‘using a unique identifier of the help
utility extracted from the source code of an application to
which the help utility pertains’ (emphasis added). There is
no mention of the newly amended limitation in the original
Specification. Thus, the limitations include subject matter
that was not described in the original Specification.

(Ans. 4.)
The issue with respect to this rejection is: Does the evidence of record
support the Examiner’s finding that the claim 7 encompasses new matter?
Findings of Fact
The following findings of fact (“FF”) are supported by a
preponderance of the evidence of record.
1. The Specification teaches:
Next, at block 44 a unique identifier is generated for
each guided help tutorial so that it can be accessed through
the associated software application’s help menu. A help
utility also may be accessed using a desktop “help and
support” shortcut, or by using a general “help and support,
all programs” button, or by selecting a “help and support”
entry on an initially displayed “welcome center” menu that
is discussed further below in reference to Figure 3.
At block 46 the unique identifier for each help utility
is passed through as a parameter in the source code of the
software application with which the particular help utility is
associated. Subsequently, as indicated by block 48 in Figure
2, when a user selects a particular “help” utility the ID of the
utility is used to retrieve the utility from the library.

(Spec. 6.)
Appeal 2011-008620
Application 11/946,416

4
2. The word “extract” is defined as “To decompress. In this
context, extract means to ‘pull out’ the original files from a compressed
archive (ZIP file, RAR file, etc.)” (Computer Desktop Encyclopedia,
http://lookup.computerlanguage.com/host_app/search?cid=C999999&term=
extract&lookup.x=23&lookup.y=19).
3. The phrase “pass through” is defined as “cause or enable to
pass through” (Free Dictionary, http://www.thefreedictionary.com/
pass+through).
Principles of Law
“[I]t is the specification itself that must demonstrate possession. And
while the description requirement does not demand any particular form of
disclosure, ... or that the specification recite the claimed invention in haec
verba, a description that merely renders the invention obvious does not
satisfy the requirement” Ariad Pharms., Inc. v. Eli Lilly and Co., 598 F.3d
1336, 1352 (Fed. Cir. 2010).
Analysis
The Examiner explains that “a unique ID ‘passing through’ as a
parameter in the source code does not mean that the unique ID is ‘extracted’
from the source code because the unique ID is NOT described to be
attached, contained or apart [sic “a part” ?] of the source code” (Ans. 9).
Appellants contend that “[i]f an ID is passed through something, it
strains credulity that if a patent applicant cares to describe passing through
an ID in terms of the ID being ‘extracted’, the skilled artisan would not
understand the applicant to have possessed the ‘extracted’ expression” (App.
Br. 5).
Appeal 2011-008620
Application 11/946,416

5
We find that the Examiner has the better position. The Examiner
provides a specific reason why the terms “extract” and “pass through” have
different meanings. The technical definition of “extract” and the definition
of “pass through” describe different processes (FF 2-3). Appellants provide
no clear or specific reasoning or evidence to support their position that the
skilled artisan would have found that a teaching that “the unique identifier
for each help utility is passed through as a parameter in the source code”
demonstrates descriptive support for “using a unique identifier of the help
utility extracted from source code of an application” language in claim 7.
That is, based on this record, Appellants have not shown that the Examiner
erred in finding that passing an identifier through as a parameter does not
necessarily provide descriptive support for extracting the identifier from the
source code, since “passing through” and “extracting” are not necessarily the
same computer operations (see FF 2, for example).
Conclusion of Law
The evidence of record supports the Examiner’s finding that claim 7
encompasses new matter.
B. 35 U.S.C. § 102(b) over Finnigan
The Examiner finds that:
Finnigan teaches a method, comprising: generating at
least one guided help utility . . . including a “show me”
option and a “do it” option . . . associating a unique
identifier with the guided help utility to facilitate accessing
the utility through the associated software application;
passing the unique identifier through as a parameter in the
source code of the associated software application; and
invoking the help utility in response to a user selection (see
Appeal 2011-008620
Application 11/946,416

6
paras.43-44 ; user command or selection to access and
invoke wizard).

(Ans. 3-4; emphasis omitted.)
The issue with respect to this rejection is: Does the evidence of record
support the Examiner’s finding that Finnigan anticipates the claims?
Findings of Fact
4. Finnigan teaches “[a]ctive Content Wizards (ACWs) related to
helping computer users perform tasks are executed using an ACW
interpreter. In one aspect of the present invention, the interpreter provides
multiple levels of user interaction for a given ACW script” (Finnigan 2 ¶
0023).
5. Finnigan teaches that the
ACW interpreter 230 can provide different levels of user
interaction with the interface. . . . When ACW interpreter
230 waits for the user to interact with the interface, it is
operating in a “show-me” mode. Alternately, when ACW
interpreter 230 simply interacts on behalf of the user, it is
operating in “do it for me” mode. The level of interaction
can be selected by the user, or automatically varied based
upon the system’s evaluation of user interaction with the
user interface.

(Finnigan 6 ¶ 0067.)
6. Finnigan teaches that:
Natural user interface 200 comprises of three components.
These components include a task prediction module 210, a
task database 220 and active content wizard (ACW)
Interpreter 230. Natural user interface 200 also receives an
input user command or query 206 from a user, and provides
an output 250. The query represents a task that the user
desires to perform. Input command 206 is in one
Appeal 2011-008620
Application 11/946,416

7
embodiment a natural language input. However, other inputs
can be used for the input command 206 such as selecting a
hyperlink, selecting a check box, selecting from a list of
words, or providing speech input.

(Finnigan 3 ¶ 0043 (emphasis added).)
7. Finnigan teaches that “task prediction module 210 leverages an
existing help search module to search task database 220 to find matches to
the user command 206” (Finnigan 3 ¶ 0044).
8. Finnigan teaches that “[t]ask prediction module 210 receives a
user input command 206 and converts and/or processes command 206 into a
format that allows for searching of task database 220. Module 210 then
executes a search against task database 220 to obtain information associated
with the task represented by command 206” (Finnigan 3-4 ¶ 0044).
9. Finnigan teaches that “[t]ask prediction module 210 then
returns an active content wizard (ACW) script corresponding to the selected
task to the ACW Interpreter 230” (Finnigan 4 ¶ 0045).
10. The word “hyperlink” is defined as “A link in a hypertext-based
navigational scheme that permits the user to browse from one document to
another, or from one Web site to the next” (Hyperlink. (1999). In Dictionary
of Multimedia and Internet Applications: A Guide for Developers and Users.
Retrieved from http://www.credoreference.com/entry/wdmia/hyperlink).
Principles of Law
“A single prior art reference that discloses, either expressly or
inherently, each limitation of a claim invalidates that claim by anticipation.”
Perricone v. Medicis Pharm. Corp., 432 F.3d 1368, 1375 (Fed. Cir. 2005).
Appeal 2011-008620
Application 11/946,416

8
“It is axiomatic that, in proceedings before the PTO, claims in an
application are to be given their broadest reasonable interpretation consistent
with the specification.” In re Sneed, 710 F.2d 1544, 1548 (Fed. Cir. 1983).
Analysis
Claim 1
Finnigan teaches a method of generating a help utility with “show
me” and “do it” options (FF 4-5). Finnigan teaches that the help utility may
be accessed using a “hyperlink” user command, where a hyperlink is a
unique identifier associated with the help utility that facilitates access to the
help utility (FF 6, 10). Finnigan teaches that the hyperlink user command is
processed by the software (FF 7-8) and activates the help utility in response
to the hyperlink user command (FF 9).
Appellants contend that the “rejections are based on clear error for
alleging anticipation of the independent claims using a reference that
nowhere describes any ID in any source code of any software for which help
is sought” (App. Br. 6). Appellants further contend that “[q]uite plainly, this
cannot be correct this side of Alice in Wonderland: a user-input command is
not a unique ID nor is it stored in source code or extracted or passed through
the source code” (id. at 7).
We are not persuaded. We agree with the Examiner that a
“hyperlink” associated with a help utility, necessarily comprises a unique
identifier which the software application uses to allow navigation from the
page containing the hyperlink to the help utility software. This is inherent in
the very meaning of “hyperlink,” which serves as a specific link to a specific
component. Finnigan’s “hyperlink” is therefore reasonably interpreted as a
Appeal 2011-008620
Application 11/946,416

9
unique identifier which is used by the software to invoke the help utility (FF
6-10).
Claims 2, 3, 10, and 14
Appellants contend that “[p]aragraph 44 tries to find a match for a
user query and says nothing about plural help utilities, much less that each
has an associated software application and unique identifier” (App. Br. 7).
The Examiner finds that “it would have been well known to one of
ordinary skill in the art to know that the selected check box would have a
corresponding element that can be used to index the collection of task
documents in order to retrieve the desired task document” (Ans. 13).
We interpret the Examiner’s argument as finding it would have been
obvious to have “plural” help utilities. However, the instant rejection is one
of anticipation, not obviousness. Thus, while we continue to agree with the
Examiner that the “hyperlink” of Finnigan has a unique identifier which is
used as a parameter by the software application to invoke help utilities (FF
6-10), we are constrained to reverse the rejection of these claims because the
Examiner does not identify any express teaching in Finnigan for “plural”
help utilities as required by claims 2, 3, 10, and 14.
Claim 4
Appellants contend that
nothing in paragraphs 43 or 44 repeated above teach or
suggest sending an identifier of a help utility (Claim 4), as
opposed to simply entering a user query. A user query has
not been demonstrated to mean to the skilled artisan ‘utility
identifier’ nor would one expect such a demonstration to be
made, the one being an apple and the other an orange

(App. Br. 8).
Appeal 2011-008620
Application 11/946,416

10
We are not persuaded. Claim 4 requires selecting a “help” utility
where the identifier is used to retrieve the utility from the library. The
selection by a user of a “hyperlink” is a selection of the “help” utility.
Further, as discussed above, the “hyperlink” necessarily comprises an
identifier which is used by the software to invoke the help utility selected
(FF 6-10).
Claims 5, 12, and 16
Appellants contend that the Examiner’s finding that “paragraph 36 of
Finnigan teaches ‘wireless’ apropos Claim 5 ignores that Claim 5 does not
simply declare the term ‘wireless’ in a vacuum, but rather in a context - a
wireless local area network (LAN) help utility - that the ‘wireless media’ of
paragraph 36 nowhere envisions” (App. Br. 8).
The Examiner finds that “Finnigan’s invention which may be
implemented in a local and wide area network with wireless media teaches
or suggest the recited ‘wireless local area network (LAN) help utility” (Ans.
15).
We find that Appellants have the better position. The Examiner again
appears to be using an obviousness rationale of “suggest” rather than finding
that Finnigan teaches an embodiment where the “help utility” is a wireless
LAN help utility as required by claim 5. The Examiner does not identify a
teaching of the elements required by claim 5 in Finnigan. See In re Arkley,
455 F.2d 586, 587 (CCPA 1972) (“[C]ombining various disclosures not
directly related to each other by the teachings of the cited reference ... may
be entirely proper in the making of a 103, obviousness rejection ... but it has
no place in the making of a 102, anticipation rejection.”)
Appeal 2011-008620
Application 11/946,416

11
Conclusion of Law
The evidence of record supports the Examiner’s finding that Finnigan
anticipates claims 1 and 4.
The evidence of record does not support the Examiner’s finding that
Finnigan anticipates claims 2, 3, 5, and 10-17.
SUMMARY
In summary, we affirm the rejection of claim 7 under 35 U.S.C. § 112,
first paragraph as failing to comply with the written description requirement.
We affirm the rejection of claims 1 and 4 under 35 U.S.C. § 102(b) as
anticipated by Finnigan. Pursuant to 37 C.F.R. § 41.37(c)(1), we also affirm
the rejection of claims 6-9 as these claims were not argued separately.
We reverse the rejection of claims 2, 3, 5, and 10-17 under 35 U.S.C.
§ 102(b) as anticipated by Finnigan.

No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a).

AFFIRMED-IN-PART

cdc