LOCATION SERVICE FOR THE INTERNET
BACKGROUND The present invention relates to networks. More particularly, the present invention relates to a location service for the Internet.
The Internet is a network which allows users at different locations to communicate with each other. As the use of the Internet continues to expand, users are increasingly connecting to the Internet at different locations. For example, a user may have an Internet connection at work and another Internet connection at home. Further, mobile devices for connecting to the Internet are quickly becoming a reality. However, each of these different locations and methods for accessing the Internet require a user to have a different address for each method for accessing the Internet, e.g. , an address for the work Internet connection, a second address for the home Internet connection, and a third address for an Internet connection through a mobile device. These different addresses are an inherent feature of the Internet protocol.
Typically, when a user requests access to information on the Internet, for example a web page, the user will enter an alphanumeric address associated with the information's location, e.g. , www.xyxyxyxy.com. The alphanumeric address is sent from the users device to a Domain Name Server (DNS) which sends the users device the Internet Protocol (IP) address , e.g. , 111.111.111.111, which corresponds to the alphanumeric address. The IP address provides information relating to the location of a domain on the Internet. In the example above where the alphanumeric address is www.xyxyxyxy.com, the domain would be xyxyxyxy.com. The user's device then uses the IP address to request information from the desired destination. In order to respond to the users information request the users device will send the IP address where the user is currently located.
In addition to IP addresses, it would be desirable to provide other information which is related to a user's location. For example, user A who is
connected to the Internet may want to make a telephone call to user B at user B's current location. User A may want to know whether user B is currently located at user B's office telephone number, user B's home telephone number, or user B's mobile telephone number. Accordingly, it would be desirable to provide a user addressing scheme that spans over different networks and provides different types of location information.
Most applications today for providing user information or location information rely on static information, use a proprietary protocol or use a proprietary application program interface (API) which results in limited scalability in the Internet architecture. One method of providing location information over the Internet is through dynamic updates of the DNS. The dynamic DNS update protocol is used for updating DNSs when a host changes its IP address. The dynamic DNS update protocol involves caching of DNS records across the DNS hierarchy. This caching of DNS records requires several hours for the DNS updates to propagate through the Internet. Further, DNS is only used for mapping machine names and not user names. Accordingly, the location of a particular user cannot be provided using dynamic DNS update protocol. Another method for obtaining user information is called session initiation protocol (SIP). SIP does not have a user-addressing scheme, but instead relies upon external schemes such as a Computing and Communications Service Office (CCSO) Nameservers (Ph), Finger and Whois servers. These SIPs rely upon accessing a database on a remote server. However, there is no support built into IP for locating these remote servers. Instead, the user requesting the information must know the location of the databases. Further, these databases do not use a unique identifier which can provide consistency in the user address space across the Internet. For example, if information about John Smith is requested from an SIP server, the SIP server may have many John Smith's in the database. This lack of consistency will lead to scalability problems if the number of SIP servers increase.
Yet another method of locating user information is the instant message service known as ICQ (I Seek You). ICQ uses a user addressing at its lowest level by using ICQ numbers. However, the ICQ numbers do not have an addressing hierarchy. The lack of an addressing hierarchy results in poor scalability features. Further, ICQ does not address the security aspects of the ICQ numbers.
There is an increasing amount of applications which use the Internet which require knowledge of a users location. For example, suppose user A is connected to the Internet by a modem and wants to play a game with user B who is also connected Internet. Using conventional addressing schemes, users A and B would have to use a second application, i.e. , other than the game application, to exchange IP addresses.
Typically, each of these users has a dynamic IP address which is assigned each time the user logs onto the Internet. When the user wishes to play a game with another user across the Internet, the game will prompt the user for the IP address of the other user with whom the game will be played. IP addresses are not well understood by most users of the Internet. This lack of familiarity with IP addresses results in many telephone calls to technical support services of software companies inquiring about IP addresses and how to obtain them.
Operating on the Internet today is a system called the Public Key Infrastructure (PKI). The PKI is system which relies upon a third party between communicating units which issue certificates for a variety of uses, e.g. , for encryption of messages between two parties. Currently there is no mechanism which provides global distribution of public certificates to other people who need them to communicate in a secure manner with the certificate owner. One solution is known as the Lightweight Directory Access Server. However, to access the Lightweight Directory Access Server, the user needs to know the server name or IP address.
Accordingly, it would be desirable to provide location information which relies upon unique identifiers for each user. Further, it would be desirable to provide a method and apparatus for providing location information which does not have the scalability problems in the above-mentioned user information systems. In addition, it
would be desirable to provide a location information method and apparatus which uses a hierarchical user address scheme. It would also be desirable to provide a location information method and apparatus which allows secure update of the user information. Further, it would be desirable to provide location information associated with devices connected to the Internet or services provided over the Internet. Further, it would be desirable to provide methods and apparatus for exchanging public key certificates for secure communications.
SUMMARY These and other problems, drawbacks and limitations of conventional techniques are overcome according to the present invention by using a unique user identifier which is based on the Internet domain name architecture. Each domain name server can have a User Location Server (ULS) which contains information associated with users of the domain. The ULS can access the user location information from a ULS database.
Accordingly, it is an objective of the present invention to provide a user location system which uses a unique user identifier which is based on the Internet domain name structure.
It is another objective of the present invention to provide a secure method for updating the information contained in a ULS.
It is also an objective of the present invention to allow ULS information to be accessed from non-IP networks.
It is another objective of the present invention to provide location information associated with devices connected to the Internet or services provided over the Internet.
Yet another objective of the present invention is to provide an efficient mechanism for providing public key certificates.
In accordance with one aspect of the present invention, the foregoing and other objects are achieved by a method and/or an apparatus for providing location
information. An address of a location database is requested from an address provider. The address of the location database is provided to the requesting device. A query, including a unique identifier, is sent to the location database. Location information is returned from the location database. In accordance with another aspect of the present invention, the forgoing and other objects are achieved by a method and/or an apparatus for updating a location database. An address of a location database is requested from an address provider. An address of the location database is provided to the requesting device. A query, including a unique identifier, is sent to the location database. An authentication is performed with the location database. Updated information is sent to the location database and the location database is updated.
In accordance with another aspect of the present invention, the forgoing and other objects are achieved by a method and/or an apparatus for accessing location information stored in a first network from a second network, wherein the first network operates according to a first protocol and the second network operates according to a second protocol. A query, including a unique identifier, is sent from the second network requesting location information to a gateway in the second protocol. The query is converted in the gateway from the second protocol to the first protocol . Another query is sent from the gateway to an address provider. An address of the location database is returned to the gateway. The query is forwarded to the location database. Location information is returned to the gateway. The location information is forwarded from the gateway to the second network.
BRIEF DESCRIPTION OF THE DRAWINGS
The objects and advantages of the invention will be understood by reading the following detailed description in conjunction with the drawings in which:
FIG. 1 illustrates an exemplary network architecture for providing user location information;
FIG. 2 illustrates an exemplary method for accessing user location information;
FIG. 3 illustrates an exemplary method for updating user location information; FIG. 4 illustrates an exemplary network architecture for accessing user location information from a non-IP network;
FIG. 5 illustrates an exemplary method for accessing user location information from a non-IP network;
FIG. 6 illustrates a plurality of locations for a ULS subscriber; FIG. 7 illustrates using the ULS database for the location of services on the
Internet according to an exemplary embodiment of the present invention; and
FIG. 8 illustrates using ULS database for playing a game over the Internet according to an exemplary embodiment of the present invention.
DETAILED DESCRIPTION
The present invention is directed to providing user location information on the Internet. In general, the present invention accomplishes this by providing a ULS server associated with a DNS. The user location information is accessed using a unique user identifier. In so doing, user location information can be easily accessed. Further, the user location information is easily scalable within the Internet architecture.
In the following, the present invention is described as a user location information system for the Internet. However, one skilled in the art will recognize that the present invention is applicable to other types of networks.
Figure 1 illustrates an exemplary network architecture for accessing user location information. Accordingly, user 120 can access DNS 110 to retrieve the address of the ULS 130. Using the address information provided by DNS 110, user 120 then accesses the ULS 130 to obtain the location information associated with a ULS subscriber. For ease of discussion a user whose information is stored in a ULS database will be referred to herein as a ULS subscriber. The ULS 130 stores and retrieves user location information in ULS database 140. One skilled in the art will recognize that although figure 1 illustrates ULS 130 and ULS database 140 as separate network elements, the ULS 130 and the ULS database 140 can be combined into a single network element. Further, one skilled in the art will recognize that the ULS 130 and ULS database 140 can be implemented as a component in the DNS 110.
According to exemplary embodiments of the present invention, user location information can be accessed using only a ULS subscriber's e-mail address. Since a subscribers 's e-mail address indicates the domain associated with the subscriber, and in turn the DNS associated with the subscriber, the ULS server and the ULS database associated with the ULS subscriber can be easily accessed by a user requesting information. For example, suppose a user wishes to find out the location of John Smith. The user knows that John Smith has an e-mail address of johnsmith@work.com. In this example "work.com" is the domain name associated with John Smith. Accordingly, by accessing the "work.com" DNS a user can retrieve information about the location of John Smith. Of course, one skilled in the art will recognize that other unique user identifiers can be used in the present invention, as long as there is a correspondence between the unique user identifier and the hierarchical domain structure of the Internet. Figure 2 illustrates an exemplary method for accessing a ULS subscriber's location information. In step 205 the user sends a query to the DNS responsible for the domain associated with the ULS subscriber. In the John Smith example described above, the DNS would be in the "work.com" domain. Accordingly, in step 205 the user would send a query to the DNS associated with the "work.com" domain regarding
the location, e.g. , IP address, of the ULS associated with the "work.com" domain. In step 210 the DNS returns the address of the ULS associated the "work.com" domain to the requesting user. In step 215 the user queries the ULS with the user's e-mail address identifier, e.g. , johnsmith. In step 220 the ULS sends a query to the ULS database. The query to the ULS database requests the database to return the location information associated with the unique user identifier, e.g. , the location information associated with johnsmith. In step 225 the ULS database returns the location information associated with the ULS subscriber to the ULS. In step 230 the ULS returns the requested location information to the user. The ULS database can contain a variety of information relating to a ULS subscriber's location. For example, the ULS database can contain the ULS subscriber's work phone number, home phone number, mobile phone number, home address, work address. In addition, the ULS database can contain the ULS subscriber's IP address associated with the ULS subscriber's work domain, the IP address associated with the ULS subscriber's home domain and the IP address associated with the ULS subscriber's mobile device domain. Further, as will be described in more detail below, the ULS database can contain the ULS subscriber's public key certificates.
Figure 3 illustrates an exemplary method for updating the ULS database. In step 305 the user sends a query to the DNS responsible for the domain associated with the ULS subscriber's unique user identifier. For example, the query is sent to
"work.com" domain if the ULS subscriber's e-mail address is johnsmith@work.com. In step 310 the DNS returns the address of the responsible ULS. In step 315 the user sends a query to the ULS requesting a ULS update for the particular ULS subscriber. In step 320 the ULS and the user perform a challenge-response authentication. In step 325 the ULS determines if the authentication is successful. If the authentication is unsuccessful, in accordance with the "No" path out of decision step 325, then the ULS denies the user access to the database and the ULS update information is discarded by the ULS in accordance with step 330. If the authentication is successful, in accordance with the "Yes" path out of decision step 325, then the ULS
grants the user access to the particular ULS database record in accordance with step 335. Although step 320 describes an exemplary challenge-response authentication procedure, one skilled in the art will recognize that other authentication schemes can be used in place of the challenge-response authentication procedure described in step 320. Further, although figure 3 illustrates that a user is denied access after one authentication attempt, one skilled in the art will recognize that the system can allow for several attempts before denying access to the ULS database.
After the user has been granted access to the database record the ULS updates the ULS database using the updated information sent from the user in accordance with step 340. In step 345 the ULS sends an update confirmation to the user. One skilled in the art will recognize that if the ULS is implemented in the DNS the user may not have to send separate queries to the DNS and to the ULS.
Figure 4 illustrates an exemplary network architecture for accessing user location information from a non-IP network. According to this embodiment of the present invention, a device which is connected to a non-IP network, such as a mobile telephone 410 which is connected to a base station using wireless application protocol (WAP), can be connected to the Internet 430, and in turn the ULS 435, via a WAP to Internet gateway 420. The WAP to Internet gateway 420 is responsible for, among other things, conversion between IP and the non-IP protocol and for formatting the information in a manner suitable for the WAP device. It is anticipated that future versions of WAP will be IP compatible. Accordingly, the gateway will not need to perform the protocol conversion, but it will still need to perform the formatting for the WAP device.
Figure 5 illustrates an exemplary method for accessing user location information from a non-IP network. In step 505, the device which is part of a non-IP network connects to an Internet gateway. In step 510 the user sends a ULS query to the gateway. In step 515 the gateway queries the DNS responsible for the domain associated with the ULS subscriber. In step 520 the DNS returns the address of the ULS associated with the DNS to the gateway. In step 525 the gateway sends a ULS
query to the ULS. In step 530 the ULS queries the ULS database to retrieve the database record associated with the ULS subscriber.
In step 535 the database provides the ULS with the requested information. In step 540 the ULS returns the requested information to the gateway. In step 545 the gateway converts the information into a protocol associated with the non-IP network and forwards the requested information to the user. One skilled in the art will recognize that if the ULS is implemented in the DNS the user does not have to send a separate query to the DNS and to the ULS.
The update information sent to the ULS database can be the user's telephone number, an IP address associated with the user's computer etc. However, the database can store information relating to several different user locations, and the user location update procedure can be used to inform the database where the user is currently located.
Now that the general operation of the ULS has been described, examples of different operations performed using the ULS will be presented below. Figure 6 illustrates an exemplary network and different ULS subscriber locations. According to the embodiment of figure 6, the ULS database in the ULS/DNS 615 contains information associated with a ULS subscriber's home 620, mobile 630 and work 640 locations. Although ULS/DNS 615 is illustrated in figure 6 as a single node for ease of illustration, one skilled in the art will recognize that the ULS and DNS can be implemented as separate network elements in a similar manner to that described above. Assume now that John Smith is the ULS subscriber associated with locations 620, 630 and 640 and that John Smith has the e-mail address johnsmith@work.com. If John Smith is logged onto his computer at work 640, the computer will update the DNS/ULS associated with the domain "work.com" that John Smith is currently located at work. If user 610 sends a ULS query to DNS/ULS associated with the "work.com" domain, the DNS/ULS will return to user 610 John Smith's work phone number and the IP address associated with John Smith's work computer.
If John Smith leaves the office and turns on his mobile telephone 630, the mobile telephone 630 will perform a ULS update procedure to reflect that John Smith is now located at his mobile telephone. Accordingly, if user 610 sends a ULS query to DNS/ULS associated with the "work.com" domain, the DNS/ULS will return the telephone number of John Smith's mobile telephone 630. If John Smith's mobile telephone 630 operates according to IP then the DNS/ULS will also return the IP address currently associated with John Smith's telephone. Similarly, if John Smith logs onto his computer at home 620, the computer will perform a ULS update procedure to reflect that John Smith is now located at home 620. Accordingly, if user 610 sends a ULS query to DNS/ULS associated with the "work.com" domain, the DNS/ULS will return John Smith's home telephone number and the IP address associated with John Smith's home computer.
Although the example above describes logging onto a computer and turning on a mobile telephone as events which trigger ULS updates, the present invention is not limited to such events for triggering ULS updates. For example, assuming that John Smith has a mobile telephone, handheld organizer, pager, or other device which operates according to the Bluetooth protocol, John Smith's location information in the ULS database can be automatically updated. Bluetooth protocol is a wireless short range networking protocol which is known in the art. The exact details of Bluetooth protocol are not necessary for an understanding of the present invention, however, for more information regarding Bluetooth protocol, the interested reader should refer to U.S. Patent Application Serial No. 09/438,326 "Wireless Voice-Activated Remote Control Device" filed on November 12, 1999, which is herein incorporated by reference. Information regarding the Bluetooth protocol can also be found on the Internet at www.bluetooth.com. According to this embodiment, when John Smith arrives at work, his Bluetooth device, wirelessly and automatically, connects with a device at his work which is connected to the Internet. The Bluetooth device, again wirelessly and automatically, performs a ULS update procedure via the device connected to the Internet. Accordingly, John Smith's ULS database record can be
automatically updated with his current location with no interaction by John Smith. In other words, the Bluetooth device can automatically perform the authentication function described in connection with the ULS update procedure without requiring John Smith to enter his password. According to another aspect of the present invention, the ULS can be used to provide public key certificates to users. According to exemplary embodiments of the present invention public certificates can be stored in the ULS database. Alternatively, a public certificate database can be associated with a user's domain in a similar manner to the ULS database. According to either of these embodiments, a user only needs to know a ULS subscriber's e-mail address to access the public key certificates. This allows users who do not know each other, or who want to establish a secure communication for the first time, to communicate securely.
Although the present invention has been described above as providing information associated with a user, for example, a person, the ULS database can also be used to provide information which is associated with devices and services. One type of service which can be performed on the Internet is remote education, also known as distance learning. Figure 7 illustrates a plurality of nodes in a remote education system in accordance with an exemplary embodiment of the present invention. Assume that John Smith is a professor who gives a lecture in the morning from computer 740 and in the evening John Smith's lecture is rebroadcast from computer 750, wherein computer 740 and computer 750 have different IP addresses. By using the ULS 730 and associating a unique identifier with this remote education service, a person who wishes to access this service can do so without knowing both IP addresses. Assume that the lecture service has a unique identifier ofjohnsmithcourse@lecture.com. A person who wishes to access this lecture need not know whether the broadcast is associated with the IP address of the computer 740 or the IP address of the computer 750. The program running on the users computer 710, for example, a web browser, will prompt the person who wishes to see the lecture for the location of the lecture. The person will input the unique identifier johnsmithcourse@lecture.com. The web browser will send
an query to a DNS 720 requesting the address of the "lecture.com" ULS 730. When the web browser receives the address of the ULS 730, the web browser will query the ULS 730 regarding the location of the "johnsmithcourse" . Depending upon when the ULS query is sent, the ULS will return the IP address of either computer 740 or computer 750.
According to another embodiment of the present invention the ULS can be used to supply IP addresses for users who wish to play an online game against each other. Assume that gameplayerl 810 and gameplayer2 820 wish to play a game together over the Internet. In order for these two users to play a game with each other over the Internet, each user must have the other users IP address. In accordance with exemplary embodiments of the present invention, the ULS can be used to supply the IP address of one of the gameplayers. Gamplayerl 810 would request from DNS2 850 the address of the ULS associated with gameplayer2 820 using the unique identifier of gameplayer2 820. Using the address supplied by DNS2 850, gameplayerl 810 would then send a ULS query to ULS2 860. ULS2 860 would supply the IP address of gameplayer2 820. Using the IP address provided by ULS2 860 gameplayerl 810 would initiate the game with gameplayer2 820 by sending the IP address associated with gameplayerl 810's computer. Once both gameplayerl 810 and gameplayer2 820 have each others IP addresses, they can begin playing a game with each other over the Internet.
The present invention can also be used to provide location information for devices. For example, assume that a user has posted a web page on the Internet and is running, for example, CGI scripts, Java Applets, etc. , off of the user's computer. Further assume that the user's computer is connected to the Internet over a dial-up telephone line and that the user's computer is only connected to the Internet for several hours a day. Each time the user's computer connects to the Internet the user's computer is assigned a new IP address. However, a DNS cannot provide information relating to dynamically assigned IP addresses. In accordance with exemplary embodiments of the present invention, when the user's computer connects to the
Internet and is assigned an IP address, the user's computer performs a ULS update to update the ULS database with the new IP address. When the web page is accessed a query will be sent to the ULS, using a unique identifier associated with the user's computer, to determine the IP address associated with the user's computer. Now that the web page has the IP address of the user's computer, the web page can access the CGI scripts which reside on the user's computer.
The present invention has been described with reference to several exemplary embodiments. However, it will be readily apparent to those skilled in the art that it is possible to embody the invention in specific forms other than those of the exemplary embodiments described above. This may be done without departing from the spirit of the invention. These exemplary embodiments are merely illustrative and should not be considered restrictive in any way. The scope of the invention is given by the appended claims, rather than the preceding description, and all variations and equivalents which fall within the range of the claims are intended to be embraced therein.