Reshaped UDDI for intranet use

BACKGROUND OF THE INVENTION

P-0001[0001] 1. Field of the Invention

P-0002[0002] The present invention relates generally to methods and systems for obtaining service information, and more particularly, to obtaining service information using UDDI (Universal Description, Discovery, and Integration) over an Intranet Network (hereinafter simply referred to as “the Intranet”).

P-0003[0003] 2. Prior Art

P-0004[0004] The rapid and growing adoption of XML technology in the Internet world gives Web services architecture, consisting of Universal Description, Discovery and Integration (UDDI), Simple Object Access Protocol (SOAP), and Web Services Definition Language (WSDL) great potential of being the new generation distributed computing paradigm. Although similar to other existing distributed computing models such as CORBA and DCOM, XML-based Web services possess many advantages including interoperability, light-weighting, firewall-friendliness, etc. Moreover, they are backed by major companies like IBM, Microsoft and Ariba which ensures that it will receive a great deal of attention.

P-0005[0005] Currently there are home networking protocols known in the art such as UPnP, which is designed to enable simple and robust connectivity among stand-alone devices and PCs from many vendors. However, this protocol only works within the bound of the home environment. Home devices are envisioned to be able to talk to the outside through the Internet.

P-0006[0006] As discussed above, UDDI is one essential component in the Web services architecture. UDDI itself is becoming a standard in the Internet domain. It has the potential to enable businesses to quickly, easily and dynamically find and transact business with one another using their preferred applications. The UDDI Community is a group of companies actively engaged in developing and deploying the standard.

P-0007[0007] UDDI has a business registry consisting of three parts:

P-0008[0008] White Pages provide company contact information,

P-0009[0009] Yellow Pages categorize business by standard taxonomies, and

P-0010[0010] Green Pages document the technical information about available services.

P-0011[0011] To the outside world, UDDI provides two sets of interfaces: one for service registration and one for service discovery. Those entities that wish to make their services available on the Web must register information about themselves and service descriptions using service registration interfaces. These entities are referred to as “Service Providers.” Those entities that need to utilize services available on the Web must use service discovery interfaces to find the desired services from a UDDI registry. They are referred to as “Service Users.”

P-0012[0012] It is easy to understand UDDI by looking at how it works in the grand scheme of Web services. As shown in FIG. 1, the process starts with a service provider <b>100</b> contacting a UDDI registry <b>102</b> to register its services. To deal with the heterogeneous nature of the Internet services, WSDL <b>104</b> provides a general-purpose XML language for describing service interfaces, protocol bindings, and the deployment details of network services. It is a useful complement to the UDDI standard. Information about a service provider <b>100</b> and WSDL description location are saved in the UDDI registry <b>102</b>. A service user <b>106</b> discovers needed services by means of keywords or UDDI browsing. Once a desired service is found, UDDI <b>102</b> returns service access Information to the service user <b>106</b> so that it can invoke the service provider access point using parameters conforming to the WSDL description. All messaging in this process is accomplished with SOAP <b>108</b>, which carries implementation-neutral XML-formatted messages.

P-0013[0013] UDDI is designed for the business and enterprise environment and is accessed over the Internet, while home networking is designed for home use. Although proven useful for their intended purposes, UDDI and home networking suffer from the following problems:

P-0014[0014] Finding and remembering each other is not easy: First, when a new device is plugged into the home Intranet, it needs to find other devices. For example, a user wants to send the output from a CD player to several speakers in different rooms. The user must enter the service information (including the IP address of a device, descriptions of services provided by the device) of other devices and do the necessary configuration to establish a relationship between the new CD player and these devices. However, this may be a complex task for users with limited computer knowledge. Moreover, it is not easy to determine how the new device should interact with another device (for example what parameters are acceptable in a service request) because devices from different manufacturers may require different parameters in a service request. Second, even if the user is capable of accomplishing the above task, it is still a time-consuming task to enter service information every time the user wants to use other services. Such service information must be stored in client devices and updated every time another new service is added or an existing service is removed.

P-0015[0015] Home devices don't know how to find services outside home: Sometimes the services that are looked for are not available at home and it is desired to go outside and “service hunt” using the Internet. In addition, due to the limited relevant knowledge typical users have, they want to make this service hunting process transparent to users. For example, when we play an audio CD on a CD player, it is desirable for the CD player to find the lyrics corresponding to the song it is playing and display the lyrics on a TV screen. Because it is unlikely for a CD player to hold the lyrics of every song, the player has to retrieve the lyrics in “real-time.” Typically the lyrics retrieval service is not available within the home. The Internet becomes the only source for this kind of services.

P-0016[0016] It is hard to access home devices from the outside: People want to access home facilities when they are in a remote location, such as in the office or on the road. For example, you may want to turn on the air conditioner at home before you leave the office. This can be accomplished with home services. A more advanced usage of home services is called command and control, which consists of sensing, fusing and actuating Web services. In these situations, the only way to access the home services is to use the office workstation, a wireless computer or a PDA. Since home service information usually is not stored in an office computer (or it is not safe to do so), the service may not be invoked from an office computer.

SUMMARY OF THE INVENTION

P-0017[0017] In light of these problems, what is needed is an intermediary to facilitate communication among devices within a home Intranet network and with the Internet. As mentioned above, some existing home networking protocols such as UPnP are designed to solve the first problem, i.e. the discovery and invocation of in-home services. However, they lack the capability to handle service discovery and invocation of services crossing the home boundary as is required to solve the other two problems.

P-0018[0018] Therefore it is an object of the present invention to provide a method and system for obtaining service information over both the Intranet and Internet using UDDI.

P-0019[0019] Accordingly, a method for obtaining service information over an Intranet network is provided. The method comprising: making a service request by a service user to a local server operatively connected to the Intranet network; searching a first database operatively connected to the local server for the service request, the first database containing a listing of local service providers available on the Intranet network; and under predetermined circumstances, also searching the Internet for the service request. Preferably, the predetermined circumstances under which the Internet is searched is if the searching of the first database provides no matches to the service request. Preferably, the method further comprises informing the service user of the results of the searching.

P-0020[0020] The method preferably further comprises: storing a listing of at least a portion of service providers available on the Internet in a second database operatively connected to the local server; and under predetermined conditions and prior to searching the Internet for the service request, searching the second database for the service request. Preferably, the predetermined circumstances under which the second database is searched is if the searching of the first database provides no matches to the service request.

P-0021[0021] The method preferably further comprises: selecting, by the service user, at least one of the results of the search; and returning an indication of the selection of the at least one of the results to a corresponding service provider. The returning preferably comprises returning the indication to a router, which in turn returns the indication to the corresponding service provider. The method preferably further comprises forwarding information regarding the selected at least one of the results back to the service user from the corresponding service provider. Preferably, the forwarding comprises forwarding the information to a router, which in turn forwards the information to the service user. Alternatively, the method further comprises forwarding information regarding the selected at least one of the results from the corresponding service provider to another service provider on the Intranet network.

P-0022[0022] Also provided is a system for obtaining service information over an Intranet network. The system comprises: a local server operatively connected to the Intranet network; a first database operatively connected to the local server, the first database containing a listing of local service providers available on the Intranet network; means for searching the first database for the service request; a communications connection operatively connecting the Intranet network to the Internet; and means for searching the Internet for the service request under predetermined circumstances. The system preferably further comprises a display for displaying results of the search to the service user.

P-0023[0023] Preferably, the system further comprises a second database operatively connected to the Intranet network for storing a listing of at least a portion of service providers available on the Internet, wherein the second database is searched for the service request prior to the Internet being searched for the service request.

P-0024[0024] The system preferably further comprises selecting means for selecting at least one of the results of the Internet search, wherein the communication connection returns an indication of the selection of the at least one of the results to a corresponding service provider. In which case, the system preferably further comprises a router, wherein the indication is sent to the corresponding service provider via the router. Preferably, the communication connection further forwards information regarding the selected at least one of the results back to the service user from the corresponding service provider. In which case, the system further comprises a router, wherein the information is forwarded to the service user via the router.

P-0025[0025] Preferably, the system further comprises a wrapper operatively connected to the local server for forwarding the service request to the local server, receiving a reply therefrom, and informing the service user of the results of the search. The wrapper is also preferably operatively connected to the local server and the Internet for forwarding the service request to the Internet, receiving a reply therefrom, and informing the service user of the results of the Internet search. Still also preferable is if the wrapper is operatively connected to the local server and the second database for forwarding the service request to the second database, receiving a reply therefrom, and informing the service user of the results of the second database search.

P-0026[0026] Preferably, the communication connection further forwards information regarding the selected at least one of the results from the corresponding service provider to another service provider on the Intranet network.

P-0027[0027] Still further provided is a method for obtaining service information from an Intranet network. The method comprising: making a service request by a service user from an Internet to a local server operatively connected to the Intranet network; and searching a first database operatively connected to the local server for the service request, the first database containing a listing of local service providers available on the Intranet network.

BRIEF DESCRIPTION OF THE DRAWINGS

P-0028[0028] These and other features, aspects, and advantages of the apparatus and methods of the present invention will become better understood with regard to the following description, appended claims, and accompanying drawings where:

P-0029[0029]FIG. 1 illustrates a schematic of a UDDI based web service model of the prior art.

P-0030[0030]FIG. 2 illustrates a schematic of an example of a basic home networking environment according to the present invention.

P-0031[0031]FIG. 3 illustrates a flowchart of a preferred implementation of the methods of the present invention.

P-0032[0032]FIG. 4 illustrates flowchart branch A of the flowchart of FIG. 1.

P-0033[0033]FIG. 5 illustrates a schematic of a preferred system of the present invention for practicing the methods of FIGS. 1 and 2.

P-0034[0034]FIG. 6 illustrates a UML (Unified Modeling Language) sequence diagram for a first example of the preferred methods of the present invention.

P-0035[0035]FIG. 7 illustrates a UML (Unified Modeling Language) sequence diagram for a second example of the preferred methods of the present invention.

P-0036[0036]FIG. 8 illustrates a UML (Unified Modeling Language) sequence diagram for a third example of the preferred methods of the present invention.

P-0037[0037]FIG. 9 illustrates a UML (Unified Modeling Language) sequence diagram for a fourth example of the preferred methods of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

P-0038[0038] Although this invention is applicable to numerous and various types of Intranet networks, it has been found particularly useful in the environment of home networking. Therefore, without limiting the applicability of the invention to home networking, the invention will be described in such environment.

P-0039[0039] A home networking environment can be viewed as an Intranet connecting various home devices. Home devices can be categorized into three groups according to their primary usage:

P-0040[0040] Entertainment appliances. This group includes TV, VCR, DVD player, etc. The primary usage of these appliances is to receive and display video streaming and audio (collectively referred to as “content”).

P-0041[0041] Data oriented devices. This group of devices includes PCs and handheld devices. The primary usage of these devices is to receive and process data, although some may be consumed as streams.

P-0042[0042] Data acquisition and control devices. This group of devices includes home security systems, cameras, sensors, and actuators for home automation and home healthcare. Their primary usage is to gather data, generate alert/alarm signals, and send commands to turn on/off home appliances.

P-0043[0043] For purposes of this disclosure, the home devices are considered service providers analogous to the service providers discussed above with regard to UDDI in that they all provide a service to a service user. For instance, a TV, VCR, and DVD player provides the service of receiving and displaying content to the service user, and in the case of the VCR, of copying the received content. Similarly, data acquisition and control devices provide the service of home security. However, some devices may also be considered a “service user” such as a television which requests a service from a DVD player (e.g., to display a movie thereon).

P-0044[0044] The main purpose of connecting these devices is to let them interact with one another through a home network, and potentially with services outside the home through a home gateway, which routes data between access networks and home networks. A natural concern for accomplishing this goal is how these different devices, possibly from various vendors can inter-operate with each other and even communicate with services on the Internet.

P-0045[0045]FIG. 2 shows a typical home networking environment with various devices <b>206</b>-<b>214</b> that at least provide services (i.e., act as a service provider) and may also request services (i.e., act as a service user). The communication between a home Intranet <b>200</b> and the Internet <b>202</b> through portal <b>204</b> is ideally two-way. This allows a user to utilize public services from the Internet <b>202</b> when he or she is at home and control home devices <b>206</b>-<b>214</b> when he or she is at a remote location, such as on the road or at the office. Examples of the home devices include a DVD player <b>206</b>, a lighting service <b>208</b>, a personal digital assistant (PDA) <b>210</b>, a television <b>212</b>, and an automatic pet feeding facility <b>214</b>. The use of such devices <b>206</b>-<b>214</b> is well known in the art.

P-0046[0046] Referring now to FIGS. 3, 4, and <b>5</b> in combination, there is illustrated a flowchart and schematic of a preferred implementation of a method and system for obtaining service information over an Intranet network <b>200</b>, such as a home networking environment, the configuration and operation of which are well known in the art. The term “obtaining service information” is used in a general sense to mean not only obtaining information regarding services, as is discussed in Example 1 below, but to control home devices, as is discussed in the remaining Examples below. The method is generally referred to by reference numeral <b>100</b>.

P-0047[0047] At step <b>102</b>, a service request by a service user is made to a local server <b>300</b> operatively connected to the Intranet network, which is preferably a home networking environment, but may also be a business Intranet. The local server <b>300</b> has a local or internal UDDI (and is alternatively referred to as such). A first database <b>302</b> operatively connected to the local server <b>300</b> is searched at step <b>104</b> for the service request. The first database <b>302</b> contains a listing of local service providers available on the Intranet network <b>200</b>.

P-0048[0048] Within the home Intranet <b>200</b>, there are services intended for internal use because most of the devices <b>206</b>-<b>214</b>, if not all, are private. In order to use these services, a local UDDI registry must be set up for use within the Intranet. In other words, all internal services are registered and discovered from this local UDDI registry and stored in the first database <b>302</b>. The local UDDI registry should be compatible with an external or public UDDI registry <b>310</b> on the Internet <b>202</b> such as those from IBM and Microsoft in order to be able to request global services and receive requests from outside the intranet network <b>200</b>. The local registry should also be an agent/proxy/filter that delegates or relays requests targeted to the public UDDI <b>310</b>. That is, service users inside the Intranet network <b>200</b> can also send a request to external services on the Internet <b>202</b> such as an office desktop <b>312</b>, a sports Star Finder Service <b>314</b>, a map service <b>316</b>, and flight track services from competing airlines <b>318</b>, <b>320</b>. In this situation, service users request external services the same way they do to request local ones. Hence the local UDDI registry, as a proxy or agent, forwards requests to the public UDDI <b>310</b> or rejects such requests (in case of parental control, for example), receive responses from the public UDDI <b>310</b> and relays them back to the service user who makes the request. A service user on the Intranet network <b>200</b> may or may not be aware that some services actually come from outside the Intranet network <b>200</b>. Also, the local UDDI <b>300</b> can modify the “look and feel” of an Internet service to comply with that of local services.

P-0049[0049] Under predetermined circumstances, the Internet <b>202</b> is also searched for the service request. The predetermined circumstances are discussed below with regard to portion A of FIG. 3 and shown in detail in FIG. 4. At step <b>118</b>, the service user is informed of the results of the search, if necessary, preferably by displaying the results of the search.

P-0050[0050] At step <b>120</b>, the service user selects at least one of the results of the search. If such results are displayed, for instance on a computer monitor, the user selects the results by any means known in the art such as by mouse clicking on one of the results from a list of the results. At step <b>122</b>, an indication of the selection of the results is returned to a corresponding service provider. Preferably, the indication is first returned to a router <b>304</b> which in turn returns the indication to the corresponding service provider. The router <b>304</b> is preferred to relay all service requests and responses between the Internet <b>202</b> and the Intranet <b>200</b> transparently. Therefore, a service request is sent to the router <b>304</b> first. The router <b>304</b> checks a message header (URL) and determines if the request is targeted at the Internet <b>202</b> or the Intranet network <b>200</b>, and forwards the request accordingly. When the result comes back, the router <b>304</b> forwards it back to the service user or to a service provider on the Internet network <b>200</b>. The router <b>304</b> can have a list of services that need to be blocked or refused authorization. Another function of the router <b>304</b> is to perform authentication when service requests come from the Internet <b>202</b> into the Intranet network <b>200</b>.

P-0051[0051] At step <b>124</b>, information regarding the selected results are forwarded back to the service user from the corresponding service provider. The information is preferably first forwarded to the router <b>304</b> which in turn forwards the information to the service user. Alternatively, information regarding the selected results is forwarded from the corresponding service provider to another service provider (acting as a service user) on the Intranet network <b>200</b>.

P-0052[0052] For better performance, the local UDDI <b>300</b> may also ‘cache’, certain service descriptions in a second database <b>306</b> from a public UDDI <b>310</b> so that some inquires to the public UDDI <b>310</b> may be expedited by checking the cache. The second database <b>306</b> (alternately referred to as a “cache”) is attached to the local UDDI <b>300</b> and preferably has the same data structure as the public UDDI <b>310</b>, but has limited storage space containing a subset of the most frequently used service descriptions from the public UDDI <b>310</b>. Algorithms to refresh/update cache (second database) based on recent service requests are quite mature in the art (for example, caching in operating systems). Referring now to FIG. 4, at step <b>106</b>, it is determined whether any matches to the service request where found in the first database <b>302</b>. If yes (<b>106</b>-yes), it is determined if the second database <b>306</b> is to be searched for the service request. The second database <b>306</b> is operatively connected to the local server <b>300</b>.

P-0053[0053] Under predetermined conditions and prior to searching the Internet <b>202</b> for the service request, the second database <b>306</b> is searched for the service request. Preferably, the predetermined circumstances under which the second database <b>306</b> is searched is if the searching of the first database <b>302</b> provides no matches to the service request, shown schematically at step <b>106</b>-No. However, even if the search of the first database <b>302</b> results in matches to the service request shown schematically as step <b>108</b>-yes, the second database <b>306</b> can be searched. For instance, the second database <b>306</b> can be searched if less than a predetermined number of search results are returned from the search of the first database <b>302</b>. If searching of the second database is desired, it is done so at step <b>110</b>. If not, the method proceeds along path <b>108</b>-no to step <b>118</b> where the service user is informed of the results, if necessary.

P-0054[0054] After searching of the second database <b>306</b>, if desired, it is determined if the searches of the first and second databases <b>302</b>, <b>306</b> produced any matches at step <b>112</b>. If yes (<b>112</b>-yes), it is further determined if the Internet <b>202</b> should be searched for the service request at step <b>114</b>. If not, the method proceeds to step <b>118</b> where the service user is informed of the results. If no results have been produced from the search of the first and second databases (<b>112</b>-No) or results have been produced and it is desired to search the Internet <b>202</b> nonetheless (<b>114</b>-yes), the method proceeds to step <b>116</b> where the Internet <b>202</b> is searched for the service request. Thus, as can be seen by the preferred implementation of the method of FIGS. 3 and 4, the predetermined circumstances under which the Internet <b>202</b> is searched is if the searching of at least the first database and preferably also the second database provides no matches to the service request. Those skilled in the art will appreciate that other predetermined circumstances are possible, such as searching the Internet <b>202</b> for the service request where the searches of the first and/or second databases <b>302</b>, <b>306</b> produce less than a predetermined number of results.

P-0055[0055] Referring back to FIG. 5, the system also preferably includes a UDDI wrapper <b>308</b>. The UDDI wrapper <b>308</b> (alternatively referred to as a “service locator”) is configured on top of the local UDDI <b>300</b> and provides the same set of APIs as the local UDDI <b>300</b>. Users are preferably required to send a request to the UDDI wrapper <b>308</b> rather than accessing the local UDDI <b>300</b> directly. Once a user sends a request to a wrapper API, the UDDI wrapper <b>308</b> forwards the request to the local UDDI <b>300</b>. If the response shows that the service description is in the local UDDI <b>300</b>, the UDDI wrapper <b>308</b> returns this information to the service user who makes the service request. Otherwise, under the predetermined conditions, the UDDI wrapper <b>308</b> contacts the public UDDI <b>310</b> and returns whatever information it receives. This process is preferably transparent to the service user. Thus, the UDDI wrapper <b>308</b> is operatively connected to the local server <b>300</b> for forwarding the service request to the local server <b>300</b>, receiving a reply therefrom, and informing the service user of the results of the search. The UDDI wrapper <b>308</b> is also preferably operatively connected to the Internet <b>202</b> for forwarding the service request to the Internet <b>202</b>, receiving a reply therefrom, and informing the service user of the results of the Internet search. Still further, the wrapper is also preferably operatively connected to the external or second database <b>306</b> for forwarding the service request to the external database <b>306</b>, receiving a reply therefrom, and informing the service user of the results of the external database search.

P-0056[0056] As will be discussed more fully below by way of the Examples, the communication connection can also forward information regarding the selected results from the corresponding service provider to another service provider on the Intranet network <b>200</b>. Thus, the service request can be to the DVD player <b>206</b> to play a particular movie on a particular television <b>212</b> on the home networking environment <b>200</b>. In which case, the DVD content (the information) is forwarded from the DVD player (service provider) to the Television <b>212</b> (another service provider). Of course, information may also be sent to the service user, such as a conformation that the service request has been received and has been or will be fulfilled.

EXAMPLES

P-0057[0057] The preferred method and system of the present invention will now be described by way of several Examples. Those skilled in the art will appreciate that the same are given by way of example only and not to limit the scope or spirit of the present invention in any way.

Example 1

P-0058[0058] A first example will now be described with reference to FIG. 6. The service user begins by accessing the UDDI wrapper <b>308</b> to request a Flight Status service at <b>402</b>. The UDDI wrapper <b>308</b> requests the service from the local UDDI <b>300</b> at <b>404</b>. The local UDDI tries to find it locally, but cannot and responds to the UDDI wrapper with a “no” at <b>406</b>. The UDDI wrapper then looks for it at cache <b>306</b> at <b>408</b>. The requested service is not in the cache <b>306</b> and the cache <b>306</b> responds to the UDDI wrapper with a “no” at <b>410</b>. The UDDI wrapper then requests the service from the public UDDI <b>310</b> at <b>412</b>, which returns a list of similar services to the UDDI wrapper <b>308</b> at <b>414</b>. The UDDI wrapper <b>308</b> returns the list to the service user at <b>416</b>. The service user then chooses the United Airline Flight status tracker service <b>318</b> and communicates the request to it at <b>418</b> through the router <b>304</b> at <b>420</b>. The United Airlines Flight status tracker service <b>318</b> then forwards the result to the router <b>304</b> at <b>422</b>, which forwards the result back to the service user at <b>424</b>.

Example 2

P-0059[0059] A second example will now be described with reference to FIG. 7. In the second example, a television <b>502</b>, <b>504</b>, <b>506</b> is considered as both a service provider that provides the service of displaying a video on a screen and as a service user which requests content from a DVD player be displayed thereon. We assume there are multiple televisions <b>502</b>-<b>506</b> (a 14″ Philips <b>502</b>, a 27″ Philips, and a 19″ Sony) in a home having the system illustrated in FIG. 5. A DVD player <b>206</b> is a typical service provider that requires an output device to display what it plays, no matter whether the output device is a computer or a TV. For purposes of this example, it is assumed that the output of a DVD player is operatively connected to all televisions <b>502</b>-<b>506</b> and can therefore be sent to any of the televisions <b>502</b>-<b>506</b> in the home.

P-0060[0060] Since televisions <b>502</b>-<b>506</b> are service providers, they are required to register themselves with the local UDDI <b>300</b> first. This is referred to as a service description process and is preferably done automatically by the televisions <b>502</b>-<b>506</b>. There are at least three options on how to find the local UDDI <b>300</b> the first time the service providers are connected to the home network <b>200</b>. They are:

P-0061[0061] The new device broadcasts its presence to the home network <b>200</b>; once the local UDDI server <b>300</b> hears this message, it responds with its address.

P-0062[0062] The local UDDI server <b>300</b> broadcasts its address information regularly so that any new device connected thereto can receive it (with some delay).

P-0063[0063] The local UDDI server <b>300</b> has a fixed and well-known address.

P-0064[0064] After finding the local UDDI server <b>300</b>, new televisions and other devices can register themselves into the UDDI registry using standard APIs. Registration information can include such information as model number, manufacturer, IP address, access methods, parameters, etc.

P-0065[0065] As mentioned above, it is impractical for normal users with little technical expertise to configure a device such as the DVD player <b>206</b> with information such as the IP addresses of televisions in order to initialize communication with them. Therefore, it is preferred that the DVD player <b>206</b> and other such devices consult the UDDI registry and discover possible TVs and how to invoke them in terms of methods and parameters. The discovery process is similar to the normal business-service discovery process of UDDI.

P-0066[0066] In summary, the televisions <b>502</b>-<b>506</b> connected on the home network <b>200</b> register with the UDDI wrapper <b>308</b> at <b>508</b>, <b>510</b> and <b>512</b>. The UDDI wrapper registers the DVD player with the local UDDI server <b>300</b> at <b>514</b>. After a request is made by the service user to play DVD content on a television, the DVD player contacts the UDDI wrapper <b>308</b> looking for a television at <b>516</b>. The UDDI wrapper <b>308</b> contacts the local UDDI server <b>300</b> looking for televisions registered therewith at <b>518</b>. The local UDDI server <b>300</b> returns information to the UDDI wrapper <b>308</b> indicating the available televisions at <b>520</b>. The UDDI wrapper <b>308</b> then returns the information to the DVD player <b>206</b> at <b>522</b> which may be more specific, such as what are the available televisions of a certain manufacturer or size. The DVD player <b>206</b> then selects one of the televisions <b>504</b> from the supplied list at <b>524</b> and the UDDI wrapper <b>308</b> returns service information for the selected television <b>504</b>, such as its address on the home network <b>200</b> to the DVD player <b>206</b> at <b>526</b>. The DVD player <b>206</b> then contacts the selected television <b>504</b> and plays the selected content thereon.

Example 3

P-0067[0067] A third example will now be described with reference to FIG. 8. Although, the second example may be the most typical scenario in a home Intranet <b>200</b> (i.e., both the service provider and the service users are located within the home) however, sometimes service users are not able to find what they need at home. For example, if the service user is watching a very interesting football game. He or she may think a new football player did a terrific job and wants to know more about him. Therefore, since this type of service is not likely to be found on the home network <b>200</b>, it is necessary to go outside the home network <b>200</b> and search for a possible ‘sports star home page finder’ service.

P-0068[0068] To the service user, this process should be transparent. That is, once a service user sends such a service discovery request, the UDDI wrapper <b>308</b> is responsible for finding this service, no matter if it is local to the home network <b>200</b> or external on the Internet <b>202</b>.

P-0069[0069] As shown in FIG. 8, the UDDI wrapper <b>308</b> receives a service request at <b>602</b> (for a Sports Star Finder service) from the client (in this example, the television <b>502</b> operated by the service user). The UDDI wrapper <b>308</b> first looks at the local UDDI server <b>300</b> at <b>604</b> to see if there is a match. If not (<b>606</b>), the UDDI wrapper <b>308</b> searches the UDDI cache (second database <b>306</b>) at <b>608</b> to see if this service is frequently used and the information is already cached. If still not found (<b>610</b>), the UDDI wrapper <b>308</b> automatically contacts a public UDDI <b>310</b> at <b>612</b>, preferably through the router <b>304</b> at <b>614</b> and looks for the requested service. The results (access point and methods descriptions) are returned to the client <b>502</b> at <b>620</b>, preferably via the router <b>304</b> at <b>616</b> and the UDDI wrapper <b>308</b> at <b>618</b>. The client <b>502</b> selects one of the results at <b>622</b> and communicates the same to the UDDI wrapper <b>308</b>, which in turn contacts the selected service at <b>624</b> and receives the results therefrom from the service at <b>626</b>. The client <b>502</b> is then able to send service requests to the service provider <b>314</b> without knowing where the service provider is located (e.g., internal to the home network <b>200</b> or external on the Internet <b>202</b>).

Example 4

P-0070[0070] A fourth example will now be described with reference to FIG. 9. In general, home services on a home network <b>200</b> are not (directly) available to external entities partly because of security concerns. However, sometimes the owner of a house may need to access home services on his or her home network <b>200</b> because he is on the road or in the office and there may be an urgent need to access a home device on the home network <b>200</b>. For example, Tom has a pet that needs to be fed every day at noon. But Tom is working at his office at this time. Therefore, Tom wants to feed his pet from his office desktop computer.

P-0071[0071] Tom first contacts his home UDDI <b>200</b> from his office desktop <b>312</b> through the home router <b>304</b> at <b>702</b> for the Automatic Pet Feeding service <b>214</b>. After authentication with the router <b>304</b>, Tom is able to send his request to the UDDI wrapper <b>308</b> at <b>704</b> and <b>706</b>. The UDDI wrapper <b>308</b> retrieves the service description from the local UDDI <b>300</b> at <b>708</b> and returns it back to Tom through the UDDI wrapper <b>308</b> at <b>710</b>, the router <b>304</b> at <b>712</b> and to his desktop <b>312</b> at <b>714</b>. Tom then makes an invocation to the automatic Pet Feeding service <b>214</b> at <b>718</b> with parameters of 50 oz bunny food and 20 oz water through the router <b>304</b> at <b>716</b>.

P-0072[0072] While there has been shown and described what is considered to be preferred embodiments of the invention, it will, of course, be understood that various modifications and changes in form or detail could readily be made without departing from the spirit of the invention. It is therefore intended that the invention be not limited to the exact forms described and illustrated, but should be constructed to cover all modifications that may fall within the scope of the appended claims.