Ex Parte Baker et al

Patent Trial and Appeal Board

May 14, 2014

12055477 (P.T.A.B. May. 14, 2014)

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/055,477 03/26/2008 Christopher John Baker GB920070027US1 7857
75949 7590 05/14/2014
IBM CORPORATION
C/O: VanCott Bagley, Cornwall & McCarthy
36 South State Street
Suite 1900
Salt Lake City, UT 84111
EXAMINER
YEN, SYLING
ART UNIT PAPER NUMBER
2166
MAIL DATE DELIVERY MODE
05/14/2014 PAPER
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.
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
____________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________________

Ex parte CHRISTOPHER JOHN BAKER, IAN JAMES MITCHELL,
CATHERINE MARY MOXEY, ARTHUR JAMES NEIL, and
JONATHAN ANDREW SCOTT
____________________

Appeal 2011-012812
Application 12/055,477
Technology Center 2100
____________________

Before HUBERT C. LORIN, MICHAEL C. ASTORINO, and
NINA L. MEDLOCK, Administrative Patent Judges.

MEDLOCK, Administrative Patent Judge.

DECISION ON APPEAL
Appeal 2011-012812
Application 12/055,477

2
STATEMENT OF THE CASE
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s final
rejection of claims 1-23. We have jurisdiction under 35 U.S.C. § 6(b).

STATEMENT OF THE DECISION
We REVERSE.1

THE CLAIMED INVENTION
Appellants’ claimed invention relates to “the field of data processing
and in particular to dynamically modifying the allocation of program
libraries available to an application server” (Spec., para. [0001]).
Claim 1, reproduced below, is illustrative of the subject matter on
appeal:
1. A method of dynamically modifying the set of
locations available to an application server from which
programs may be loaded, the method comprising:
allocating a ranking to a predefined library identifying a
set of locations from which programs may be loaded;
creating a new library resource specifying a set of one or
more locations from which the application server may load
programs;
allocating a ranking to the new library resource; and
dynamically installing the new library resource without
restarting the application server, including adding the new
library resource to a list of installed libraries including the
predefined library and determining a search order of the
installed libraries as a function of their respective allocated
rankings.

1 Our decision will refer to Appellants’ Appeal Brief (“App. Br.,” filed
April 26, 2011) and Reply Brief (“Reply Br.,” filed August 10, 2011), and
the Examiner’s Answer (“Ans.,” mailed June 16, 2011).
Appeal 2011-012812
Application 12/055,477

3

THE REJECTIONS
The following rejections are before us for review:
Claims 1-4, 9-11, 16-19, and 21-23 are rejected under 35 U.S.C.
§ 102(a) as anticipated by “Setting the Class Path” (retrieved at
http://web.archive.org/web20070205174023/http:// java.sun.com/javase/6/
docs/technotes/tools/windows/classpath.html, accessed July 9, 2010)
(hereinafter “Sun”).
Claims 5-8, 12-15, and 20 are rejected under 35 U.S.C. § 103(a) as
unpatentable over Sun and Moberg (US 6,698,015 B1, iss. Feb. 24, 2004).

ANALYSIS
Independent claim 1 and dependent claims 2-4
We are persuaded by Appellants’ argument that the Examiner erred in
rejecting claim 1 under 35 U.S.C. § 102(a) because Sun fails to disclose
“dynamically installing the new library resource without restarting the
application server . . . ,” as recited in claim 1 (App. Br. 11-15 and Reply
Br. 4-8).
The Examiner cites Sun at page 1, paragraph 1; page 1, paragraph 6
through page 2, paragraph 2; and page 5, paragraph 6, as disclosing the
argued feature (Ans. 6-7 and 21-22). We have carefully reviewed the cited
portions of Sun, on which the Examiner relies, and we agree with Appellants
that there is nothing in these portions of Sun that discloses “dynamically
installing the new library resource without restarting the application server,
including adding the new library resource to a list of installed libraries . . .
and determining a search order of the installed libraries . . .” as recited in
claim 1.
Appeal 2011-012812
Application 12/055,477

4
Sun describes the “class path,” i.e., the path that the Java runtime
environment searches for classes and other resource files (see Sun, p. 1,
“Synopsis”), and explains that the class path tells JDK (Java Development
Kit) tools and other applications where to find third-party and user-defined
classes, i.e., in which file or directory (see Sun, p. 2, “Description,”
explaining that classes can be stored either in directories (folders) or in
archive files). The class path also specifies the order in which file system
directories are searched for a needed class or resource file (see Sun, p. 6,
“Specification order,” explaining that the order in which one specifies
multiple class path entries is important, and that the Java interpreter looks
for classes in the directories in the order the directories appear in the class
path variable).
Sun describes that the class path is set, i.e., changed, using either the
“classpath option” when calling a JDK tool, or by setting the “CLASSPATH
environment variable,” and further describes that the class path need only be
set when a class is loaded that is (a) not in the current directory or any of its
subdirectories, and (b) not in a location specified by the extensions
mechanism (see Sun, p. 2, “Description”).
The Examiner asserts that because Sun describes that new library
resources are loaded in the Java “runtime” environment, the associated
application remains running, and need not be restarted, while new library
resources are loaded:
As described in Sun, users (i.e.[,] you) can set the class path for
user-defined classes, new library resources besides those Java
extension classes, to be loaded in the Java runtime environment.
Since the new library resources are loaded in the Java runtime,
the associated application remains running while loading
(e.g.[,] installing) the new library resources. Therefore, the
Appeal 2011-012812
Application 12/055,477

5
associated application does not need to be restarted while
loading the new library resources.

(Ans. 22, citing Sun, page 1, paragraph 1; page 1, paragraph 6 through page
2, paragraph 2, emphasis added).

As described above, Sun teaches that the class path can be changed
when a new class is loaded that is not in the current directory or its
subdirectories. However, we can find nothing in the cited portions of Sun
that discloses that this change in the class path can be implemented without
restarting the application server, i.e., that the class path can be changed
while the application server is running.
The Examiner takes the position that Sun inherently discloses this
feature, and relies on Shafron (US 2007/0156856 A1, pub. July 5, 2007) to
support the inherency argument. Pointing to paragraph [0065], the
Examiner, thus, maintains that Shafron teaches that when library resources
are loaded and dynamically integrated into an application at runtime, there is
no need to restart the application (Ans. 27; see also id. at 7, citing Shafron,
para. [0065]).
Shafron describes at paragraph [0065] that, rather than having an
entire library of resources hard-coded into a user application 70, the
resources are “advantageously downloaded and dynamically integrated into
the application 70 at runtime.” In other words, each time the application is
launched (i.e., “at runtime”), the resources are updated. Therefore, “there is
no need to restart the application 70 upon the application 70 being
internationalized, customized, updated, and/or patched” (see id.).
We agree with Appellants that application 70 in Shafron must still be
restarted in order to be updated. However, the application need not be
Appeal 2011-012812
Application 12/055,477

6
restarted as soon as the updates are available because the updates will be
incorporated automatically, i.e., “downloaded and dynamically integrated
into the application,” the next time the application is launched, i.e., “at
runtime” (Reply Br. 7).
In view of the foregoing, we will not sustain the Examiner’s rejection
of claim 1 under 35 U.S.C. § 102(a). For the same reasons, we also will not
sustain the Examiner’s rejection of claims 2-4, which depend from claim 1.
Independent claim 9 and dependent claims 10 and 11
Claim 9 recites a program loader for an application server comprising,
inter alia,
a resource installer for
receiving a new library resource definition relating
to a new program library, said new library resource
definition identifying a set of one or more locations of
programs and a ranking of the new library resource, and
in response to receiving said new library resource
definition, adding the new library resource to the list of
program libraries, and
determining a search position of the new library
resource in accordance with its allocated ranking.

App. Br., Clm. App’x.

We are persuaded by Appellants’ argument that the Examiner erred in
rejecting claim 9 under 35 U.S.C. § 102(a) because Sun fails to disclose a
“resource installer,” as called for in claim 9 (Reply Br. 10-12).
Citing Sun at page 1, paragraph 1; and page 1, paragraph 6 through
page 2, paragraph 2, the Examiner asserts that Sun teaches that new library
resources are loaded in the Java runtime environment. The Examiner, thus,
concludes that the Java runtime environment provides a facility,
Appeal 2011-012812
Application 12/055,477

7
e.g., a resource installer, to load the library resources to the application in the
Java runtime (Ans. 31).
The difficulty with the Examiner’s argument, as Appellants point out,
is that the Examiner does not indicate how or where Sun teaches or suggests
the claimed “list of program libraries,” i.e., “a resource installer for, . . . in
response to receiving said new library resource definition, adding the new
library resource to the list of program libraries,” as recited in claim 9 (Reply
Br. 10-11).
The Sun class path tells Java where to look in the filesystem for third-
party and user-defined classes, i.e., the location (directory) in the filesystem
where the class is stored. Sun, thus, discloses loading classes from a
location indicated by the class path. But we can find nothing in the cited
portions of Sun that discloses maintaining a list of program libraries to
which new resources are added by a resource installer (Reply Br. 10-11).
Nor, for that matter, does the Examiner point to any such disclosure.
Instead, the Examiner makes the conclusory statement that “[t]he disclosures
[of Sun] reasonably describe the argued limitation of ‘a resource installer’”
(Ans. 32).
In view of the foregoing, we will not sustain the Examiner’s rejection
of claim 9 under 35 U.S.C. § 102(a). For the same reasons, we also will not
sustain the Examiner’s rejection of claims 10 and 11, which depend from
claim 9.
Independent claims 13 and 16 and dependent claims 17-19 and 21-23
Independent claims 13 and 16 include language substantially identical
to the language of claim 1. Therefore, we will not sustain the Examiner’s
rejection of claims 13 and 16 under 35 U.S.C. § 102(a) for the same reasons
Appeal 2011-012812
Application 12/055,477

8
as set forth above with respect to claim 1. For the same reasons, we also
will not sustain the Examiner’s rejection of claims 17-19 and 21-23, which
depend from claim 16.
Dependent claims 5-8, 12-15, and 20
Each of claims 5-8, 12-15, and 20 depends from one of independent
claims 1, 13, and 16. The Examiner has not established on this record that
Moberg cures the deficiencies of Sun as set forth above with respect to the
independent claims.
Therefore, we will not sustain the Examiner’s rejection of claims 5-8,
12-15, and 20 for the same reasons as set forth above with respect to the
independent claims from which they respectively depend.

DECISION
The Examiner’s rejection of claims 1-4, 9-11, 16-19, and 21-23 under
35 U.S.C. § 102(a) is reversed.
The Examiner’s rejection of claims 5-8, 12-15, and 20 under
35 U.S.C. § 103(a) is reversed.

REVERSED

tkl