Ex Parte Deboer et al

Patent Trial and Appeal Board

Feb 27, 2013

10718297 (P.T.A.B. Feb. 27, 2013)

UNITED STATES PATENT AND TRADEMARK OFFICE
________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
________________

Ex parte TIMOTHY GERRIT DEBOER, TIMOTHY MARC
FRANCIS, DEREK TAI-WAH KOO, SHELDON BRADLEY
WOSNICK, and ELSON SIU CHUNG YUEN
________________

Appeal 2010-009378
Application 10/718,297
Technology Center 2400
________________

Before BRUCE R. WINSOR, JEREMY J. CURCURI, and
JAMES B. ARPIN, Administrative Patent Judges.

CURCURI, Administrative Patent Judge.

DECISION ON APPEAL
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1-33 and 35. Claim 34 is canceled. App. Br. 4. We have
jurisdiction under 35 U.S.C. § 6(b).
Claims 28-31 and 35 are rejected under 35 U.S.C. § 101 as directed to
non-statutory subject matter. Ans. 5-6.
Claims 1-33 and 35 are rejected under 35 U.S.C. § 103(a) as obvious
over Christfort (US 2002/0078168 A1; published June 20, 2002) and Uszok
Appeal 2010-009378
Application 10/718,297

2
(US 2004/0205772 A1; published Oct. 14, 2004; filed March 21, 2001).
Ans. 7-19.
We affirm.

STATEMENT OF THE CASE
Appellants’ invention relates to an extensible mechanism for
executing code on one of one or more servers and in association with one of
one or more client applications. In accordance with a model of the
extensible mechanism, the execution of server side code is partitioned into
three stages. Abstract. Claim 29 is illustrative and reproduced below:
29. A computer readable media storing instructions to be
executed by a processor of a computer system, said processor of the
computer system executing an integrated development environment
(IDE) for generating code for executing in a client-server
environment, said instructions defining an extensible mechanism for
executing said code on a server that, when deployed on said computer
system, adapts said IDE for handling new code types to:
process an input object identifying code for executing on one of
a plurality of servers, said processing using a view list of at least one
input object element, each input object element processing a type of
code identified by the input object to output a deployable object;
process the deployable object using a server list of at least one
server element to determine the one of the plurality of servers for
executing the code, each server element enabling the deployable
object to execute on a particular server and outputting a launchable
object; and
process the launchable object using a launcher list of at least
one client element to determine a client for launching the code on the
one of the plurality of servers.

ISSUES
Under 35 U.S.C. § 101, has the Examiner erred by rejecting claims
28-31 and 35 as directed to non-statutory subject matter?
Appeal 2010-009378
Application 10/718,297

3
Under 35 U.S.C. § 103(a), has the Examiner erred by finding that
Christfort and Uszok, collectively, teach all claim limitations, as recited in
claim 29?

ANALYSIS
THE NON-STATUTORY SUBJECT MATTER REJECTION
The Examiner’s Answer designates a new ground of rejection of
claims 28-31 and 35 as being directed to non-statutory subject matter. Ans.
4-6; see 37 C.F.R. § 41.39(b) (2010). By filing the Reply Brief, rather than
reopening prosecution, Appellants have chosen to maintain the Appeal. See
37 C.F.R. § 41.39(b)(2). Appellants’ Reply Brief does not present any
persuasive arguments or explanation as to why claims 28-31 and 35 are
patent eligible under 35 U.S.C. § 101. See Reply Br. 2-5. We, therefore,
summarily sustain the Examiner’s rejection of claims 28-31 and 35 under 35
U.S.C. § 101. Cf. MPEP § 1205.02 (“If a ground of rejection stated by the
examiner is not addressed in the appellant's brief, that ground of rejection
will be summarily sustained by the Board.”).

THE OBVIOUSNESS REJECTION
Claims 1, 12, 13, and 19-33
We agree with the Examiner’s position, with regard to claim 29, that
Christfort and Uszok, collectively, teach all of the claim limitations. Ans. 7-
9. The Examiner relies on Uszok’s bot developer kit (SDK) for teaching the
recited extensible mechanism. Ans. 8-9 (citing Uszok, ¶129). The
Examiner relies on Christfort’s developing applications online for teaching
the recited processing an input object to output a deployable object. Ans. 7-
Appeal 2010-009378
Application 10/718,297

4
8 (citing Christfort, ¶22). The Examiner relies on Christfort’s hosting and
accessing of applications for teaching the recited processing the deployable
object and outputting a launchable object. Ans. 8 (citing Christfort, ¶¶62,
94-95). The Examiner relies on Christfort’s deploying a shared hosted
application for teaching the recited processing the launchable object. Ans. 8
(citing Christfort, ¶93).
Appellants argue that Christfort and Uszok do not teach instructions
defining an extensible mechanism for executing the code on a server that,
when deployed on the computer system, adapts the integrated development
environment for handling new code types. App. Br. 16. Appellants argue
that Christfort and Uszok do not teach processing an input object identifying
code for executing on one of a plurality of servers, the processing using a
view list of at least one input object element, each input object element
processing a type of code identified by the input object to output a
deployable object. App. Br. 17; see also Reply Br. 2-3. Appellants argue
that Christfort and Uszok also do not teach processing the deployable object
using a server list of at least one server element to determine the one of the
plurality of servers for executing the code, each server element enabling the
deployable object to execute on a particular server and outputting a
launchable object. App. Br. 18; see also Reply Br. 3-4. Appellants argue
that Christfort and Uszok do not teach processing the launchable object
using a launcher list of at least one client element to determine a client for
launching the code on the one of the plurality of servers. App. Br. 20; see
also Reply Br. 4.
The Examiner finds that Uszok (¶129) states that “[a] bot developer
kit (SDK) can be arranged to generate bot code to implement any of a
Appeal 2010-009378
Application 10/718,297

5
selection of predetermined protocols.” Appellants, however, have not
persuaded us that Uszok’s bot developer kit (SDK) which may be arranged
to implement any of a selection of protocols does not teach instructions
defining an extensible mechanism for executing said code on a server that,
when deployed on the computer system, adapts the IDE for handling new
code types, as recited in claim 29. Regarding Appellants’ argument (App.
Br. 17) that no modification of the IDE/SDK itself is performed in Uszok,
we find this argument unavailing because the claim language does not
preclude a finding that arranging the bot developer kit SDK teaches adapting
the IDE for handling new code types.
The Examiner also finds that Christfort (¶22) states that
[t]he user submits the application code by selecting an object on
the interface, such as a submit button. The application code is
stored at a server that is remote from the client and from where
the application code may be executed in response to a request
for service from an end user.
Appellants have not persuaded us that Christfort’s user submitted application
code and its subsequent execution does not teach processing an input object
to output a deployable object, as recited in claim 29. Regarding Appellants’
arguments (App. Br. 18) that Christfort makes no mention of a view list for
processing input objects and does not mention anything about processing an
input object for the purpose of subsequently identifying code to be executed
by a server, we find these arguments unavailing because processing using a
view list of at least one input object element to output a deployable object,
as recited in claim 29, is met by Christfort’s submission of the application
code to result in executable code stored at the server.
Christfort (¶62) also states “[t]he function of the host is to install and
maintain applications, such as on host server 110, that are developed by
Appeal 2010-009378
Application 10/718,297

6
either the host provider or other application developers.” Christfort (¶¶94-
95) describes accessing the new application or service. Appellants have not
persuaded us that Christfort’s application hosting does not teach processing
the deployable object and outputting a launchable object, as recited in claim
29. Regarding Appellants’ arguments (App. Br. 19-20) that no processing of
a deployable object is disclosed in Christfort because the target servers are
already known, and that Christfort does not use a deployable object that
determines which one of a plurality of servers will execute the code, we find
this argument unpersuasive because “using a server list of at least one server
element (emphasis added)” is achieved by installing and maintaining
applications on the host server 110.
Christfort (¶93) describes deploying a shared hosted application.
Appellants have not persuaded us that Christfort’s application deployment
does not teach processing the launchable object, as recited in claim
29.Regarding Appellants’ arguments (App. Br. 21-22) that Christfort does
not teach pre-configuring a launcher at a client element to support
launchable objects, we find this argument unpersuasive because “using a
launcher list of at least one client element to determine a client for launching
the code (emphasis added)” is achieved by one client launching the service
application.
Weighing Appellants’ arguments against the Examiner’s findings, we
are not persuaded that the Examiner has erred in rejecting claim 29. We,
therefore, sustain the Examiner’s rejection of claim 29, as well as claims 1,
12, 13, 19-28, and 30-33, which are not argued separately.
Appeal 2010-009378
Application 10/718,297

7
Claim 2
Regarding claim 2, the Examiner relies on Christfort’s developing
applications online, hosting of applications, and deploying a shared host
application for teaching the recited using a view list, a server list, and a
launcher list. Ans. 9-10 (citing Christfort, ¶¶22, 62, 93).We determine,
however, that Appellants’ arguments regarding claim 2 are substantially the
same as Appellants’ arguments regarding claim 29. See App. Br. 22-23. For
the reasons discussed above regarding claim 29, we agree with the
Examiner’s findings and conclusions regarding claim 2.
We are not persuaded that the Examiner has erred in rejecting claim 2.
We, therefore, sustain the Examiner’s rejection of claim 2.
Claims 3-5, 14, 16, and 18
Regarding claims 3-5, 14, 16, and 18, the Examiner relies on
Christfort’s use of XML (eXtensible Markup Language) documents for
teaching the recited view list, server list, and launcher list being extensible to
accommodate additional respective elements. Ans. 10, 13 (citing Christfort,
¶¶22, 62, 93). Appellants argue that “Christfort does not teach any
extensibility feature of a view list, server list, and launcher list, nor does
Christfort teach maintaining such lists.” App. Br. 23. We note that XML
documents are - by definition - extensible. Appellants have not provided
any persuasive rebuttal or persuasive explanation as to why the Examiner’s
explanation is insufficient.
Weighing Appellants’ arguments against the Examiner’s findings, we
conclude that Appellants have not shown error in the Examiner’s
obviousness rejection of claims 3-5, 14, 16, and 18. We, therefore, sustain
the Examiner’s rejection of claims 3-5, 14, 16, and 18.
Appeal 2010-009378
Application 10/718,297

8
Claims 6 and 7
Regarding claims 6 and 7, the Examiner relies on Christfort’s
developing applications online for teaching the recited analyzing the input
object to determine an input object element and processing the input object
using the determined input object element, and processing user input to
determine the input object element. Ans. 11 (citing Christfort, ¶¶22, 80, 86).
Appellants argue that “the SDK provider in Christfort does not perform any
processing of an input object for the purpose of subsequently identifying
code to be executed by a server.” App. Br. 23.
Appellants have not persuaded us that Christfort’s user submitted
application code and its subsequent execution does not teach the recited
analyzing the input object to determine an input object element and
processing the input object using the determined input object element, and
processing user input to determine the input object element, as recited in
claims 6 and 7. Moreover, regarding Appellants’ arguments (App. Br. 23),
we find these arguments unavailing because the recited limitations in claims
6 and 7 are met by Christfort’s submission of the application code to result
in executable code stored at the server (Christfort, ¶ 22).
Weighing Appellants’ arguments against the Examiner’s findings, we
are not persuaded that the Examiner has erred in rejecting claims 6 and 7.
We, therefore, sustain the Examiner’s rejection of claims 6 and 7.
Claims 8, 9, and 15
Regarding claims 8, 9, and 15, the Examiner relies on Christfort for
teaching the recited limitations. Ans. 11-13 (citing Christfort, ¶¶75-76, 87-
88, 91, 93).

Appeal 2010-009378
Application 10/718,297

9
Appellants argue that
[t]he cited sections of Christfort teach creating code that will
work on any client device. In contrast, claims 8, 9, and 15 recite
processing a deployment object that enables a server to enable a
server side application to run on that server. Christfort does not
teach any analysis of server side elements or teach wherein such
analysis is used for enabling a deployable object.
App. Br. 23. Nevertheless, we find these arguments unpersuasive because
processing user input to determine a server element, analyzing the server
element, and processing the deployable object using the server element (as
recited in claims 8 and 9), as well as using a server list of at least one server
element (as recited in claim 15) is met by Christfort’s installing and
maintaining applications on the host server 110. See Ans. 8 (citing
Christfort, ¶62).
Weighing Appellants’ arguments against the Examiner’s findings, we
are not persuaded that the Examiner has erred in rejecting claims 8, 9, and
15. We, therefore, sustain the Examiner’s rejection of claims 8, 9, and 15.
Claim 10, 11, and 17
Regarding claims 10, 11, and 17, the Examiner relies on Christfort for
teaching the recited limitations. Ans. 12-13 (citing Christfort, ¶¶91, 94-95).
Appellants argue that
[t]he cited sections of Christfort only teach creating server side
applications that can run on any type of client. In contrast,
claims 10, 11, and 17 recite identifying a client application by
analyzing a launchable object to determine the client element to
process the launchable object. Christfort does not teach any
analysis of a launchable object to determine a client application
for processing the launchable object.
App. Br. 23-24. Nevertheless, we find these arguments unpersuasive because
processing user input, analyzing a launchable object, and processing the
Appeal 2010-009378
Application 10/718,297

10
launchable object (as recited in claims 10 and 11), as well as using a
launcher list of at least one client element (as recited in claim 17) is met by
one client launching the service application. See Ans. 8 (citing Christfort,
¶93).
Weighing Appellants’ arguments against the Examiner’s findings, we
are not persuaded that the Examiner has erred in rejecting claims 10, 11, and
17. We, therefore, sustain the Examiner’s rejection of claims 10, 11, and 17.
Claim 35
Regarding claim 35, the Examiner maps Uszok’s selection of a
compatible version of a bot for download to the recited instruction steps of
perform a compatibility test and display a result of the compatibility test to a
user. Ans. 19 (citing Uszok, ¶73). Appellants argue that Uszok only teaches
verifying runtime properties are compatible with botMaster capabilities, and
no mention is made in Uszok of testing the compatibility as recited in claim
35. App. Br. 24. In response, the Examiner explains, “the compatibility of
the bot code is downloaded and verified. The bot code is treated as object
code and it is tested for compatibility prior to processing the bot code.” Ans.
29. We agree with the Examiner.
Uszok (¶73) states “[r]untime properties are verified for compatibility
with botMaster capabilities (e.g. presence of required plug-ins, GUI version
etc.) If any of these steps fail, the bot is not downloaded. Assuming all is
well, the Bot code is downloaded and verified.” Consequently, we are
unpersuaded that Uszok’s verification of runtime properties (compatibility
test) and either downloading or not downloading (displaying the result),
when combined with Christfort, does not teach performing a compatibility
test and displaying a result, as recited in claim 35.
Appeal 2010-009378
Application 10/718,297

11
Weighing Appellants’ arguments against the Examiner’s findings, we
are not persuaded that the Examiner has erred in rejecting claim 35. We,
therefore, sustain the Examiner’s rejection of claim 35.

ORDER
The Examiner’s decision rejecting claims 28-31 and 35 under
35 U.S.C. § 101 is affirmed.
The Examiner’s decision rejecting claims 1-33 and 35 under
35 U.S.C. § 103 is affirmed.
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).

AFFIRMED

rwk