Ex Parte Davis et al

Board of Patent Appeals and Interferences

May 26, 2010

10265844 (B.P.A.I. May. 26, 2010)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte DOUGLAS B. DAVIS,
JAMES M. MATHEWSON II,
BRAD B. TOPOL,
and KEITH A. WELLS
____________

Appeal 2009-004883
Application 10/265,844
Technology Center 2100
____________

Decided: May 26, 2010
____________

Before HOWARD B. BLANKENSHIP, JAY P. LUCAS, and
THU A. DANG, Administrative Patent Judges.

BLANKENSHIP, Administrative Patent Judge.

DECISION ON APPEAL
STATEMENT OF THE CASE
This is an appeal under 35 U.S.C. § 134(a) from the Examiner’s final
rejection of claims 1-20, which are all the claims in the application. We
have jurisdiction under 35 U.S.C. § 6(b).
We affirm.
Appeal 2009-004883
Application 10/265,844

2

Invention
Appellants’ invention relates to a container selector for use in a Web
services architecture. The selector can include an application container
query tool operably configured to query individual application containers for
a list of supported libraries and associated configuration information. A
comparator can be programmed to compare the list with another list of
requisite libraries and associated configuration information specified for use
by a requested Web service. A Web service clone requestor can be operably
configured to request an instantiation of the Web service within a particular
application container. Specifically, the particular container can be a new
container where the comparator cannot identify an existing container having
libraries and associated configuration information which match the requisite
libraries and associated configuration information. Otherwise, the container
can be a container in the list where the comparator can identify an existing
container having libraries and associated configuration information which
matches the requisite libraries and associated configuration information.
Abstract.

Representative Claim
1. A container selector for use in a Web services
architecture, the container selector comprising:
an application container query tool operably configured to
query individual application containers in a Web services host which
can be accessed through the Web services architecture for a list of
supported libraries and associated library configuration information;
Appeal 2009-004883
Application 10/265,844

3
a comparator programmed to compare said list with another list
of requisite libraries and associated library configuration information
specified for use by a requested Web service; and,
a Web service clone requester operably configured to request an
instantiation of said Web service within an application container in
said Web services host selected from the group consisting of
a new application container where said comparator
cannot identify an existing application container having
libraries and associated library configuration information which
matches said requisite libraries and associated library
configuration information, and
a specified application container where said comparator
can identify an existing application container having libraries
and associated library configuration information which matches
said requisite libraries and associated library configuration
information.

Prior Art
Brown 2003/0110242 A1 Jun. 12, 2003

Examiner’s Rejections
Claims 1-20 stand rejected under 35 U.S.C. § 102(e) as being
anticipated by Brown.

Appeal 2009-004883
Application 10/265,844

4
Claim Groupings
In view of Appellants’ arguments in the Appeal Brief, we will decide
the appeal on the basis of claim 1. See 37 C.F.R. § 41.37(c)(1)(vii).

ISSUE
Have Appellants shown that the Examiner erred in finding that Brown
discloses all the limitations of claim 1?

FINDINGS OF FACT
1. Brown discloses a Web service container that manages Web
services at a network node by providing an adaptive model for dynamic
configuration of a plurality of Web service containers distributed throughout
a network such as the Internet or an intranet. Containers can communicate
with each other via the network to determine contextual information such as
the identity of each other, the capabilities of each other, the operating system
or platforms of each others, and the contents of the container (i.e., the
available Web services at that location). By providing a container
framework and the ability to exchange contextual information, the dynamic
reconfiguration apparatus allows servers as well as clients to dynamically
exchange Web services software as well as contextual information, such as
current workload, so that servers and clients are virtually limitlessly
reconfigurable based on context. Abstract.
2. The dynamic reconfiguration apparatus enables one server with
a Web services container to send Web services software to another server
with a Web services container in order to allow that other server to begin
providing that service. The first server, for instance, can reconfigure itself
Appeal 2009-004883
Application 10/265,844

5
either partially or totally as a service router to route requests for given Web
services to another server that it has determined can provide that service
either by virtue of having itself sent the Web service software to the other
server or by querying the other server as to the contents of its Web service
containers. ¶ [0017].
3. The concept of recognizing a peer container on the network for
the purpose of interchanging information is termed container discovery.
Containers essentially are peers of each other and, thus, any suitable peer-to-
peer communication mechanism can be used for container discovery.
¶ [0031].
4. Container discovery can be carried out via a peer-to-peer
communication protocol. ¶ [0032].
5. Container discovery provides the ability for containers to share
their contextual information (e.g. the services they are hosting, how busy
they are, where they are located, etc.) and, based on such information,
automatically reconfigure themselves to best handle incoming service
requests from the network. Further, since the code module that implements
a Web service may be dynamically located on the network, that is, moved
between containers, container discovery ultimately facilitates dynamic
reconfiguration of the network itself (e.g. message routes). ¶ [0038].
6. A container can observe local conditions such as its load as well
as external conditions of other containers as discovered through the use of
UDDI and/or peer-to-peer communications, then adapt itself and/or request
other containers to adapt themselves accordingly. ¶ [0049].
7. Figure 5 is a Universal Markup Language (UML) diagram
illustrating routing of a request for a Web service, such as a currency
Appeal 2009-004883
Application 10/265,844

6
conversion service, from a first server 212 to a second server 216. The
SOAP server 501 in the container 214 of server 212 receives a message 411
from a client over the network requesting the currency conversion Web
service. In step 513, SOAP server 501 checks its server context to determine
if its processing threshold has been exceeded. ¶ [0056]; Fig. 5
8. If the processing threshold is exceeded, the next step is 523, in
which SOAP server 501 creates a remote message handler 525. Then, in
step 527, remote message handler 525 consults the container’s peer list 503
to obtain the list of peer containers. In step 529, remote message handler
525 consults the server context 505 of the peers listed in peer list 503 to
determine if any one of them can handle this particular message. ¶ [0057].
9. Assuming that the server context information 505 for one or
more particular peer containers contains insufficient information to
determine whether it can handle the message, in step 531, the server context
505 is sent in message 531 over the network to the SOAP server 507 of the
particular peer container. SOAP server 507 consults its own server context
509 to get and return the additional information (as shown in step 535) to the
SOAP server 507. The additional information is further returned from
SOAP server 507 to server context 505 and then on to the remote message
handler 525. ¶ [0057].
10. Assuming that one of the peer containers to container 218 can
handle the message, remote message handler 525 forwards the message, as
shown at 537, to SOAP server 507 in container 218. SOAP server 507
processes the request and returns the result to the remote message handler
525, as shown in step 539. Remote message handler 525 then returns that
result to the SOAP server 501, as shown in step 541. Finally, the SOAP
Appeal 2009-004883
Application 10/265,844

7
server 501 returns the result to the requesting client, as shown in step 543.
¶ [0058].
11. A business application service in a Palm PilotTM 230 can
instruct a Palm PilotTM container 234 to issue a request 238a to a posting
Web application server container 236 for a copy of a currency conversion
Web service 240. Container 234 can include in the header of that request
information about its local container. For instance, it might include in a first
request for a Web service the information that the requesting device is a
Palm PilotTM with a Java stack. Fig. 4E; ¶ [0078].
12. The Web application server container 236 examines the request
and recognizes that the container 234 that issued the request has identified
that the device on which is it implemented is a Palm PilotTM device. Assume
that the Web application server container 236 has available to it several
implementations of the currency conversion Web service software for
various platforms, including, for example, the PalmTM platform. Fig. 4E;
¶ [0078].
13. Thus, the server can issue a response 238b to the request
informing the client container of this option. The client container can then
choose to download the software or simply have it serviced by the server in
the normal fashion. Fig. 4E; ¶ [0078].
14. Referring to Figure 4E, if the client issues a request 238c to
download the software module, the Web application server container 236
issues a response 238d forwarding a PalmTM version of the currency
conversion software to the palm container. Upon receipt, the palm container
234 loads the code and dispatches all future requests to the local service
240'. Accordingly, Web service software can be exchanged between
Appeal 2009-004883
Application 10/265,844

8
network nodes running different software and/or hardware platforms. This
concept is termed location transparency since the real location and
implementation are transparent to the ultimate consumer of the service. In
addition, this implies a conceptual abstraction of the code representation of a
Web service. That is, it may be acceptable for a service to have multiple
implementations (e.g. one for cell phones and another for Palm devices) that
are hidden within a container. Fig. 4E; ¶ [0078].

PRINCIPLES OF LAW
Anticipation
“Anticipation requires the presence in a single prior art reference
disclosure of each and every element of the claimed invention, arranged as
in the claim.” Lindemann Maschinenfabrik GmbH v. American Hoist &
Derrick Co., 730 F.2d 1452, 1458 (Fed. Cir. 1984).

ANALYSIS
Appellants contend that Brown does not disclose “an application
container query tool operably configured to query individual application
containers in a Web services host.” Reply Br. 2.
However, Brown discloses a container that can communicate with
other containers via any suitable peer-to-peer communication mechanism to
determine contextual information, such as available Web services in the
other containers. FF 1-6, 9, 12. The phrase “application container query
tool operably configured to query individual application containers”
encompasses a container that requests context information such as available
Appeal 2009-004883
Application 10/265,844

9
Web services from other containers using peer-to-peer communication as
described by Brown.
Appellants contend that Brown does not describe “a list of supported
libraries and associated library configuration information” for the individual
application containers. App. Br. 13; Reply Br. 3-6.
However, “supporting libraries,” as described in paragraph 13 of the
Specification, can refer to supporting application libraries but also to
supporting executable and interpretable applications and other supporting
files and logic.1 The term “associated library configuration parameters” is
described as a version associated with each library. Spec. ¶¶ [0012], [0036],
[0037]. The phrase “a list of supported libraries and associated library
configuration information,” when read in light of the Specification, therefore
encompasses a list of supported applications and associated versions of each
application. Brown describes a list of applications and versions of
applications that are supported by the container, such as a currency
conversion Web service application, including different versions for various
platforms such as the PalmTM platform. FF 8, 12.
Appellants contend that Brown does not describe “a comparator
programmed to compare said list with another list of requisite libraries and
associated library configuration information specified for use by a requested
Web service.” App. Br. 13; Reply Br. 6.
Brown discloses obtaining a list of peer containers, and consulting the
contextual information (which includes available Web services (FF 1, 5), or

1 Appellants use the terms “supported” and “supporting” libraries
interchangeably. See, e.g., App. Br. 2 (“supported libraries 180”); Spec.
¶ [0023] (supporting libraries 180).
Appeal 2009-004883
Application 10/265,844

10
“libraries” (Spec. ¶ [0013])) of the listed peers to determine if any one of
them can handle a particular request for a Web service. FF 8-10. The
claimed “comparator programmed to compare said list with another list of
requisite libraries and associated library configuration information specified
for use by a requested Web service” encompasses a container that consults a
list of containers to determine if any of the containers can handle a request
for a Web service as disclosed by Brown.
Brown also discloses receiving a request for a Web service and
identifying a version of the service that matches the request. FF 11-13. The
claimed “comparator programmed to compare said list with another list of
requisite libraries and associated library configuration information specified
for use by a requested Web service” also encompasses identifying a version
of a Web service that matches the request as disclosed by Brown.
Appellants contend that Brown does not disclose a “Web service
clone requestor operably configured to request an instantiation of said Web
service within an application container … where said comparator can
identify an existing application container having libraries and associated
library configuration information which matches said requisite libraries and
associated library configuration information.” App. Br. 19; Reply Br. 7.
Brown discloses a container that can download software for performing a
Web service from another container, or have the Web service performed by
the other container. FF 13-14. The claimed “Web service clone requestor”
encompasses the container disclosed by Brown that can download the Web
service, including a particular version of the Web service that matches the
requested Web service, from the other container.

Appeal 2009-004883
Application 10/265,844

11
CONCLUSION OF LAW
Appellants have not shown that the Examiner erred in finding that
Brown discloses all the limitations of claim 1.

DECISION
The rejection of claims 1-20 under 35 U.S.C. § 102(e) as being
anticipated by Brown 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). See 37 C.F.R.
§ 41.50(f).

AFFIRMED

msc

CAREY, RODRIGUEZ, GREENBERG & PAUL, LLP
STEVEN M. GREENBERG
950 PENINSULA CORPORATE CIRCLE
SUITE 2022
BOCA RATON FL 33487