Ex Parte Davis et alDownload PDFBoard of Patent Appeals and InterferencesMay 26, 201010265844 (B.P.A.I. May. 26, 2010) Copy Citation 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 Copy with citationCopy as parenthetical citation