WO1999029083A1 - Method and apparatus for dynamic domain names - Google Patents

Abstract

A system of connecting to the Internet (10) is provided, where logical addresses are dynamically associated with physical IP addresses, depending upon the value of parameters, such as time of day, day of week, load, and user profile information. Upon receiving a domain name (logical address), IN Services (32) can determine a physical address through which a connection with a web browser or a digital/wireline/wireless connection can be made. A dynamic ILS (64) is provided to dynamically route telephone calls over the Internet (10), or other data network, or PSTN (14), including wireline and wireless calls, based on one or more parameters.

Description

METHOD AND APPARATUS FOR DYNAMIC DOMAIN NAMES

BACKGROUND OF THE INVENTION

1. TECHNICAL FIELD This invention relates in general to Internet communications and, more particularly, to a method and apparatus for providing dynamic domain names.

2. DESCRIPTION OF THE RELATED ART

Over the last several years, the Internet has enjoyed unprecedented success, both as a means to distribute information globally and as a means for communicating between a set group. The importance of the Internet spans educational, commercial and government sectors.

The primary tool for addressing a site on the Internet is through domain names. Domain name registration is currently regulated through an independent entity, InterNic. For example, the domain name "www.fredspizza.com" could be registered with InterNic for use with a pizza parlor's web site. After the domain name is registered, it is associated with a physical address (IP address) of the Internet site at a domain name server. When a user enters a domain name to reach an Internet site, the IP address associated with the domain name is retrieved. The user also has an IP address; this address may be a permanently assigned IP address, or it may be allocated dynamically by the user's ISP when the user logs on to the Internet. The IP addresses of the users and the web site are used to communicate address data packets between one another.

One advantage of domain names is that they can be re-associated with a new physical address by editing the database at the domain name server. Thus, if a site changes its physical address, it can have its domain name re-associated with the new physical address at the domain name server and users will be directed to the new physical address transparently.

Domain names, however, have some limitations. One limitation is the one-to- one correspondence between a domain name and a physical address, which can be problematic for popular Internet sites, or any Internet site which is capacity limited. Since a domain name corresponds to a single Internet address, the present system does not accommodate situations where the owner of the domain name would like to direct users to multiple sites depending upon certain criteria.

Similarly, users of digital telephony on the Internet rely on an ILS (Internet Service Locator) in order to communicate with other Internet users. An ILS maintains a list of users who are currently logged into the Internet and have their digital telephony programs running. The ILS provides an association between a name (or e- mail address) and an IP address (even if a user has a dynamic IP address). The user may log in with a comment field, such as "for family only", but the reality is that the user may be called by anyone with access to the ILS for as long as the user is logged in with the ILS. Accordingly, many users only log in after they have arranged the specifics of a call with another party. This greatly diminishes the usefulness of digital telephony.

Therefore, a need has arisen for handling connections to IP addresses in a flexible manner. BRIEF SUMMARY OF THE INVENTION

In the present invention, network services are provided wherein a logical address is received from a user at an network access provider. Database circuitry determines a physical address associated with the logical address, where said logical address can be associated with more than one physical address, based on one or more current parameters.

The present invention provides significant advantages over the prior art. First, an ISP can set certain domain names to be dynamic, i.e., capable of pointing to any one of a plurality of IP addresses depending upon one or more parameters, such as time of day, user telephone number, user address, and other user profile information. The ISP can sell the services to companies which need the flexibility of directing a domain name to a site depending upon the current values of certain parameters. The mapping is transparent to the ISP's users. For use in an ILS, users can set restraints on the dates and times that they can be called, by whom they can be called, on what devices they can be reached, or on other conditions or combinations of conditions.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

Figure 1 illustrates a block diagram showing prior art connections to the

Internet, using static domain name lookup;

Figure 2a illustrates a simplified block diagram showing ISP circuitry;

Figure 2b illustrates a hierarchy of domain name servers in a DNS system;

Figure 3 illustrates an embodiment of an Internet architecture using dynamic domain name lookup;

Figure 4 illustrates an embodiment of the IP Services of Figure 3;

Figure 5 illustrates an embodiment for connecting an Internet digital phone to the public switched telephone network;

Figure 6 illustrates an embodiment showing connections to an ISP bypassing the PSTN for voice and Internet services;

Figure 7 illustrates block diagram of a communications system using a dynamic ILS;

Figure 8 illustrates a prior art ILS Internet site;

Figure 9 illustrates a block diagram of a dynamic ILS; and

Figure 10 illustrates a flow diagram for the dynamic ILS . DETAILED DESCRIPTION OF THE INVENTION

The present invention is best understood in relation to Figures 1 - 10 of the drawings, like numerals being used for like elements of the various drawings.

Figure 1 illustrates a block diagram showing connections to the Internet (or other public network) in a simplified form. The Internet 10 is similar to a giant local area network (LAN), allowing different users to communicate with each other. There are various ways to connect with the Internet. Many users connect to the Internet via an Internet Service Provider (ISP) 12. ISPs can be local to a community or can be large nationwide services, such as America On Line (AOL), which has points of presence (POPs) throughout the world. Typically users connect to the ISPs 12 through the public switched telephone network (PSTN) 14, which is connected to both their computers 16 and phones 18. In some cases, users may connect to an ISP using lines outside of the PSTN.

Larger companies may have a direct Internet connection. In this case, the company owns the equipment to make the connection to the Internet and shares the equipment with its internal users. Rather than connect through the PSTN 14, users connect to the Internet through the company's LAN 20. Phone service, however, is generally made through the PSTN 14, normally via a private branch exchange (PBX) 22.

Unlike the PSTN, which is a circuit-switched system, the Internet is a packet- switched system. Data is sent in packets, each packet having a destination address. Currently, physical Internet addresses, also known as an IP (Internet Protocol) addresses, consist of four numbers (each of which can be represent by a byte), separated by periods. An example of a physical Internet address is "255.5.234.81." Routers (see Figure 2a) receive data packets and pass the packet along in accordance with the IP address associated with the packet. Routers use routing algorithms, which are constantly updated according to available resources and capacities, to efficiently route each data packet to its destination address.

A global domain name server (DNS) system 24 contains associations between domain names and physical addresses. Information linking domain names and physical addresses is stored at various levels through the Internet . When a user addresses an Internet site by domain name, the physical IP address is obtained through a DNS cache or through the global DNS 24. That address is attached to data packets sent to the Internet site. The user accessing the Internet site also has an IP address (which may be a permanent IP address or a dynamic IP address which is assigned by the ISP at the time of connection to the ISP).

Generally, the protocol used to transfer the packets is the transmission control protocol (TCP). TCP breaks down long data transmissions into packets and reassembles the packets at the receiving end. Other protocols, such as UDP (user datagram protocol) may also be used in some circumstances.

Figure 2a illustrates a simplified block diagram of an ISP. Data is received over the PSTN at a modem bank 26 or other interface. A web server 28 interfaces with the Internet as an access point. A router 30 connects the web server 28 to the Internet 10. This basic structure would also be used for a direct connection, such as the one shown in Figure 1 to LAN 20, although the modem bank 26 would be replaced with network circuitry.

Figure 2b illustrates a hierarchical view of the existing DNS system. The DNS is a distributed database based on hierarchy. At the top of the hierarchy is the root domain (represented by a ".") with all sub-domains extending from the root domain. Each sub-domain, shown as the "EDU", "GOV" and "COM" sub-domains, can contain host or other sub-domains. Th EDU sub-domain, for example, is shown with a PURDUE sub-domain, and the COM sub-domain is shown with a DSC and a MICROSOFT sub-domain. In practice, the first tier sub-domains, EDU, GOV, COM and others typically have thousands of sub-domains. The DSC sub-domain is shown with a SPD sub-domain.

If a host "sunlOO" within the SPD sub-domain of DSC ("sunl00.spd.dsc.com") wanted to connect to a host named sun500 in the PURDUE sub-domain ("sun500.purdue.edu"), the browser would initiate a search through the name server for the SPD domain. The name server for the SPD domain would query one of the root name servers for the address of sun500.purdue.edu. The root domain is not responsible for that host, but it does know the address for the EDU domain name servers. It thus returns the IP address of the EDU name server to the querying SPD name server. The SPD name server then queries the EDU name server, which, similarly, responds with the address of the PURDUE name server. When the SPD server queries the PURDUE name server, which knows the address of the sun500.purdue.edu host, the PURDUE name server returns the IP address to the SPD server, which passes the address to the user's browser software for further communications between the two hosts.

It should be noted that a name server is not a router. A name server is a program that stores data about a zone, which can either be a single domain or include sub-domains. It provides the information to translate between domain names and addresses. A router is merely a means of interface between different name servers and different networks. The routers analyze the destination address and determine the best way to get there through the network. Name servers know which specific host they want to connect to by knowing its IP address and the router determines the best path to communicate between the two hosts.

A "resolver" is a program that utilizes the name servers. Resolvers receive a user's request ( a logical host name) and formulate a query to a name server. The query they send to a name server is called a "recursive" query, which transfers control of the host name resolution to the name server. Once the name server has translated the resolver's query into an address (or name), the resolver must interpret the response and send it back to the user (or the program that requested it). Resolvers are configured to know which name servers to connect to and which domains to search.

The control for each of the sub-domains resides in a name server, usually local to that domain. Each name server contains all the information specific to the domain, including the names and IP addresses of the hosts in its domain. Each name server also contains information about which sub-domains are below its domain in the hierarchy. Information for each name server is updated independently of the rest, yet each name server is accessible from anywhere in the network.

BIND (Berkeley Internet Name Domain), is the software that makes the

Domain Name System work. BIND requires that each domain is documented, along with all of its sub-domain and hosts, in a text file with a given structure. BIND reads these files for a working knowledge of what the domain looks like, and processes the queries according to the information in the text files. BIND uses two types of files, database files and configuration files. The database files contain information about which name servers are in the domain and what zones (the domain or domains) which the name server controls. It also lists information on the hosts within the domain. The configuration file is used on startup to indicate which files are to be used with which corresponding domains. The following is an example of a database file which could be used for the DSC domain.

Dsc.com IN SOA nameserver.dsc.com msmith@dsc.com

1998041701 ;serial number

3H ;Refresh after 3 hours

1H ;retry after 1 hour 1W ;expire after 1 week

ID ;minimum time to live (TTL) of 1 day ;Nameservers dsc.com IN NS nameserver.dsc.com spd.dsc.com IN NS nameserver.spd.dsc.com ;addresses nameserver.dsc.com IN A 101.36.2.68 hostl.dsc.com IN A 101.36.2.115 host2.dsc.com IN A 101.36.2.5 nameserver.dsc.com IN A 101.36.4.88

;Aliases www.dsc.com IN CNAME nameserver . dsc.com The zone file set forth above is a typical example of a BIND 8.1 zone file. The first line of information defines the zone or default domain properties. After this Start of Authority ("SO A" record) information, the domains are defined and linked (by a type NS record) to a name server. After that, all hosts in the primary domain (indicated by the first line), including the name server host, are listed and liked (by a type "A" record) with their corresponding IP address.

The SOA filed lists mostly information for a secondary name server. However, the Time To Live (TTL) field is for all data. It tells the querying name server how long to keep the information in its cache before deleting it (thus forcing the name server to repeat the query process on the next occasion where the host is requested).

The zone files are loaded into the computer's memory when the name server daemon is started. Accordingly, the zone files are only read upon startup, and changes to the file require the name server daemon to be restarted. Zone files change only rarely, so this is not normally a problem. A zone file will change if a host name changes, if the host name's corresponding IP address changed, or if another host was added to or deleted from the name server's domain.

Once the zone files are loaded into memory, the name server is ready to respond to queries. The most common query is an address query, such as request to the DSC name server for www.dsc.com. According to the zone file above, it would bind this address as a type "CNAME". The name server then sees the alias for www.dsc.com is nameserver.dsc.com. The nameserver then looks for an entry for nameserver.dsc.com and finds one of type "A" (for address). The DSC name server would then return the corresponding IP address for nameserver.dsc.com, namely 101.36.2.68.

Figure 3 illustrates a first embodiment of the present invention which allows for flexible handling of domain names. The structure of the connections to the Internet shown in Figure 3 is the same as those shown in Figure 1, except that IN (Intelligent Network) Services 32 (individually referenced as IN Services 32a and 32b) have been connected to some of the ISPs 12 (individually referenced as ISPs 12a-d). In Figure 3, ISP 12a is connected to IN Services 32a and ISP 12d is connected to IN Services 32b.

In operation, the IN Services 32 provide additional features to the ISPs 12 to which they connect. For example, an ISP connected to an IN Service could query the IN Services 32 for a physical address associated with a domain name. The IN Services 32 could provide a physical address based on certain owner-selected criteria, rather than the static address lookup provided by the DNS 24.

IN Services 32 intelligently process a domain name based on any number of parameters. A domain name entered by a user subscribing to one of the ISPs 12 coupled to IN Services 32 can be translated with respect to parameters chosen by the owner of the domain name. One such parameter would be time of day. An on-line catalog company, for example, may direct orders during morning hours to a first web site with a first physical address and direct calls during afternoon hours to a second web site with a second physical address.

Intelligent processing of a domain name could be particularly useful in conjunction with digital phones which allow audio (and sometimes video) to be passed over an Internet connection. A digital phone connection over the Internet passes audio/ video data packets between two or more IP addresses. Digital phone connections could be used in a number of commercial settings, such as on-line catalog services, where the customer may need to talk to a representative. The IN Services 32 could direct a digital phone connection to one of a number of available service representatives at various locations. The digital phone connection could be based on time of day, current load, or other parameters, such as the user's ISP or local exchange carrier. This would allow a representative to work out of various locations, including for example, his or her house, with the IN Services directing the digital phone connections to the proper site. An ILS service is discusses in greater detail in connection with Figure 7-10 below.

Another parameter which could be used processing IP addresses is the location of the requesting user. The IN Services could look up the address of a requesting user and connect the user to specific home page or digital phone based on the address. For example, if the user entered "www.pizza.com", the IN Services 32 would access its database of users and find the address of the user, then use that address to find the location of the nearest pizza vendor who had contracted with the ISP.

Other parameters which may be used to determine an IP address from a domain name include day of week, the user's telephone number, and other user profile information, such as age, gender, income and so on. Multiple parameters may be used in determining the IP address associated with a dynamic domain name.

Figure 4 illustrates a more detailed block diagram of one embodiment of the IP Services 32. The IP Services include a domain name server 40 and a service control point (SCP) 42. The SCP 42 may be of the type normally used in telecommunications. The SCP 42 is coupled to a SLEE (service logic execution environment), to an SCE (service creation environment) and to an SMS (system management system).

In operation, when a subscriber to the ISP enters a domain name which is directed to a site which in the zone of the domain name server 40, the domain name server will return an IP address. However, rather than merely storing a static list of domain names and associated IP addresses, the list of names on the domain name . server 40 may include some address which are dynamic. When a request is made for a dynamic domain name, the domain name server 40 returns an IP address determined by the SLEE 43 and SCP 42.

The SLEE 43 and SCP 42 are capable of responding to queries based on multiple parameters. For each dynamic domain name, the SCP 42 would look up the service associated with the domain name and, based on the service and the current value of the parameters associated with the service, return an IP address to complete the Internet connection. If the domain name is not in the list of dynamic domain names, the IP address is determined through the normal, static retrieval procedures.

In the preferred embodiment, a database type "DYN" is used in the name server 40. With a dynamic DNS system, a standard lookup that finds an entry of type "DYN" will initiate a service in a SLEE ;and wait for a response on a pre-designated port. For example, if support.dsc.com was added to the sample database file set forth above, the file would look like:

Dsc.com IN SOA nameserver.dsc.com msmith@dsc.com

1998041701 ;serial number 3H ;Refresh after 3 hours 1H ;retry after 1 hour

1W ;expire after 1 week

ID ;minimum time to live (TTL) of 1 day

;Nameservers dsc.com IN S nameserver.dsc.com spd.dsc.com IN NS nameserver.spd.dsc.com

;addresses nameserver.dsc.com IN A 101.36.2.68 hostl.dsc.com IN A 101.36.2.115 host2.dsc.com IN A 101.36.2.5 nameserver.dsc.com IN A 101.36.4.88 support.dsc.com IN DYN 101.101.101.101

;Aliases www.dsc.com IN CNAME nameserver.dsc.com

When a query is sent to the name server 40 requesting translation on support.dsc.com, the name server 40 would find the entry of type "DYN" and initiate a pre-designated service using the SLEE 43 and SCP 42. The 101.101.101.101 is a dummy IP address and would not be returned to the requesting name server. The name server 40 would listen to a preset port for an answer from the SLEE 43 and SCP 42. The name server 40 would receive an IP address, which it would return as a response to the requesting name server. With a dynamic domain name request, the name server 40 would return a time to live of "0" in order to prevent associations between dynamic domain names and IP addresses from being cached.

An advantage of the dynamic DNS name server 40 described above is its ability to interface to both a SLEE and the Internet. Any service that can be created on an execution environment can apply its logic to Internet based calls or queries. For example, the SLEE 43 may be programmed to direct queries to support.dsc.com to a different web site, depending upon any number of criteria, such as the current load on the various web servers, the time or day, or customer information. From the information available at the time of the request, the SLEE could determine which web server should receive the connection, and return that IP address to the requesting party.

The creation of services on the SCP 42 can be made using service creation environment (SCE), of the type used in the telecommunications field. A description of the interaction between the SCE and the SCP 42 is described in World Wide Web Interface to Telecom Service Creation Environment, U.S. Ser. No. 08/918,383 to Lee, Jr. et al, filed August 26, 1997, which is incorporated by reference herein.

Where an ISP has multiple points of presence (POP), each POP can have its own IN Services 32. A Service Management System (SMS), also used in the telephony field, can be used to maintain information on the various SCPs.

The embodiment described above provides significant advantages over the prior art. First, an ISP can set certain domain names to be dynamic, i.e., capable of pointing to any one of a plurality of IP addresses depending upon one or more parameters, such as time of day, user telephone number, user address, and other user profile information. The ISP can sell the services to companies or individuals which need the flexibility of directing a domain name to a site depending upon the current values of certain parameters. The mapping is transparent to the ISP's users.

A second embodiment of the IN Services 32 is shown in Figure 5. This embodiment allows phone calls from the PSTN to be connected to an Internet digital phone. An SSP (Service Switching Point) 44 is coupled between the SCP 42 and the PSTN 12. The PSTN is further coupled to various routers through packet converters 46.

In operation, when a phone call through the PSTN is placed to a user who is currently using his or her phone line to make a modem connection to the Internet, the calling party will receive a busy signal. At this point, the PSTN can query the SCP 42 associated with the user (the called party) to determine whether the user is currently connected to the Internet and, if so, determine the user's current IP address. Using current software techniques used in digital phone packages such as MICROSOFT NETMEETING, the digital phone of the user can be "rung" by sending a request to the user's IP address. When the user answers the digital phone, the packet converter 46 converts voice signals from the PSTN to data packets to be sent to the user's digital phone software over the Internet and converts received data packets from the user's digital phone software to voice signals sent to the calling party. The PSTN, in the preferred embodiment, will translate the voice signals at a router location physically near the user to maximize audio quality. Connections between the Internet, or other network, and the PSTN are also discussed in connection with U.S. Ser. No. 60/089,021, entitled "Programmable Telecommunications Interface", to Lee, Jr. et al, filed June 12, 1998 and U.S. Ser. No. 60/096,512, filed August 14, 1998, entitled "Programmable Telecommunications Interface" to Lee, Jr. et al, both of which are incorporated by reference herein.

Similarly, a call originating at a digital phone could connect through the PSTN to another user's telephone. In this scenario, if the digital phone could not make a connection through the Internet (for example, if the called party was not currently connected to the Internet), the digital phone could pass the voice data packets to a router, preferably located proximate the called party (the user could supply the telephone number). Data packets from the calling party would be translated into voice signals and voice signals from the called party would be translated to voice data packets via a converter 46 associated with the selected router. The SCP 42 could maintain a list of IP addresses associated with various area codes to direct the packets to the proper router.

This embodiment of the invention provides significant advantages to Internet users who share a telephone line between a modem and a telephone. In this embodiment, phone calls can be originated and received through the PSTN during an Internet session.

Figure 6 illustrates a third embodiment where user connections to an ISP can take place apart from the PSTN. In this embodiment, users of an ISP have phones 18 and computers 16 connected to the ISP through an ATM multiplexer 48 and an ATM switch. ATM switch is also coupled to the PSTN 14 and to other ATM switches. Although Figure 6 illustrates a single ATM multiplexer 48 and ATM switch 50, in most cases, there will be multiple multiplexers 48 and switches 50 used to implement a network of connections to the ISP 12.

In operation, this embodiment allows the ISP to connect to users as a competitive local exchange carrier without using the PSTN. Telephone connections can be made to destinations on the PSTN through links from the ATM switch 50 to the PSTN. Telephone connections to destinations on the same switch, or to other ATM switches in the network, can be made without using the PSTN.

The IN Services 32 are used by the ATM switches 50 to route calls based on certain parameters, such as time of day and day of week, and to verify customer information. The IN Services 32 could determine, for example, the services to which the customer subscribed (voice mail, connection speeds and so on) and whether the customer's payments were current. The information would normally be stored in an SCP 42; in some cases, a single SCP 42 could maintain the information for both the Internet services and the phone services, in other cases, the information would be split between two or more SCPs 42.

This embodiment provides significant advantages. First, the ISP could offer customers greater connection speeds than are available over the PSTN. Second, the ISP could offer customers additional services, such as local and long distance phone services, voice mail, and video conferencing, along with high bandwidth Internet connection services.

Figure 7 illustrates a dynamic ILS (Internet locator service) which could provide enhanced telephony services over the Internet and/ or PSTN and mobile lines. An ILS is used with digital phone services, such as NETMEETING. When a user initiates his or her digital telephone package, the software logs the user into an ILS. There are many ILS services on the Internet, and the user may log into the service of his choice, indicating that he is available to receive a call. The user can access lists of other callers which are currently logged in. An example of an existing ILS is shown in Figure 8. A user selects a logical address (a name or an e-mail address) from the list and presses "Call" to make a connection to a physical address associated with the logical address.

While, in theory, a user could maintain a list of IP addresses to which digital calls are made, in practice, many users who connect through an ISP have dynamic IP addresses; i.e., the ISP has a set number of IP addresses which it assigns randomly to subscribers as they log in. Once the subscriber terminates the session, the association between the subscriber and the IP address is broken. Thus, in order to determine an address for a person with a dynamic IP address, ILS services are needed.

Referring again to Figure 7, a requesting digital phone 60 is attempting to make a connection to the destination digital phone 62 through the Internet. The dynamic ILS 64 can determine an IP address based on a number of factors, similar to those discussed in connection with the dynamic DNS system above. Hence, when a user selects a name from an ILS list and presses "Call", the dynamic ILS determines the physical address of the receiving party based on one or more parameters. For example, a user may only want to receive calls during certain hours of the day. Further, the user may only want to receive calls from certain people during those hours. The dynamic ILS is optionally coupled to the PSTN (wireline) and mobile (wireless) phone systems as well to provide enhanced features discussed below.

In another service, a user may want to receive calls through the Internet first

(during working hours), through the PSTN second, through a mobile phone third and through voice mail fourth. Thus, if a requesting digital phone made a request for an address to this user, the dynamic ILS 64 would first determine whether the user was currently logged in, i.e., whether the user currently was running his or her digital telephony program. If the user was available (and assuming the calling party met other criteria selected by the destination user) the dynamic ILS would send the IP address of the destination user to the requesting user. In this scenario, even if the destination user was not available on the Internet, his or her name would be shown on the dynamic ILS, since it maintains other ways to contact the destination user. If the destination user was not available through the Internet, the dynamic ILS would query the PSTN (through an SS7 connection) to determine whether the destination user's PSTN line was busy. If the line was not busy, the ILS would return an IP address which would be used to make a connection to a gateway to the PSTN as described above. Optionally, the ILS could ring the destination user's PSTN line to see if there was a pickup. If the PSTN was busy (or there was no pickup), the ILS would check the user's mobile phone could be checked (through an SS7 and MSC connection) to see if the destination user's mobile phone was active and, if so, available. Alternatively, the dynamic ILS could also maintain the information normally associated with an HLR (home locator resource), which maintains a log of the locations of presently active mobile phones in the ILS's internal database (see Figure 9). If the mobile phone was neither inactive or busy, the ILS would return an IP address which would be used to make a connection to a gateway connected to the mobile phone. Otherwise, the ILS would return an IP address which could be used to make a connection to the user's voice mail, which could be resident on either the Internet or the PSTN. Naturally, each of these options could be combined with other criteria. For example, between 7PM and 10PM, the user may decide not to receive calls from anyone other than a specified list of friends and family.

The dynamic ILS 64 could also be used when a phone call originated from the

PSTN (or a mobile phone system). If the PSTN received a call to a certain number, such as 1-800-PIZZA99, the call could be directed by the PSTN switch to a gateway associated with the ILS. The ILS would supply the IP address of a digital phone, or a PSTN or mobile phone, depending upon certain criteria evaluated at the time of the phone call. In this example, the dynamic ILS might connect the caller to the nearest location.

The dynamic ILS could also be used in connection with a VPN (virtual private network) to determine whether a person would have access to the network based on a number of criteria, such as time of day. A VPN uses a public network, such as the Internet or other IP backbone, in place of dedicated WAN (wide area network) links. A VPN can decrease costs and increase functionality over normal WAN structures. A problem in VPN and other network structures, is that the mobility of a user is somewhat constrained. This is a particular problem for portable computer users, who would like to be able to cormect to different network ports. Using the dynamic ILS, a user could log into the ILS when, for example, he or she was using a connection in a conference room. The ILS could perform a mapping of the user's normal IP address to the IP address of the conference room port, so that the user could receive digital telephone calls, e-mail, and so on, at the new port.

Figure 9 illustrates a basic block diagram of a dynamic ILS 64. A SLEE 66 is coupled to an LDAP server 68 and to a database 70. The LDAP server 68 receives LDAP (lightweight directory access protocol) requests, which are used to initiate a service using the SLEE 66 and database 68. The SLEE 66 and database 70 make decisions on what IP address is returned based on criteria defined by a service, such as those criteria discussed above. The SLEE 66 and database 70 could also function as an SCP, HLR and/ or DNS.

Figure 10 illustrates a flow diagram for the dynamic ILS 64. In block 80, an ILS is received in LDAP, or another suitable protocol. The request could be a user status request (log in, log out or change user profile) a destination status request. If, in block 82, the LDAP request is user status request, the database 70 is updated accordingly in block 84. A user status request could involve, for example, a login to set flags in the database indicating that the user was available to receive calls (under certain criteria), or status change request to change criteria (for example, the people allowed to contact the user or the hours in which calls would be received) or a logout to set flags in the database that the user was not receiving calls.

The criteria which may be used with a given service is virtually unlimited. The criteria for a individual could be based on any combination of time of day, day of week, calling party and available phone resources (digital, wireline, wireless, voice mail), to name of few. A commercial user may use those criteria in addition to others (for example, location of the calling party).

Returning to block 80, if the request is for status of a destination party, the database 70 is queried in block 86 for information which is used to determine an IP address according to the user selected criteria. In block 90, the ILS response in sent to the user; if the ILS request in block 80 was a user status request, a confirmation is sent, otherwise the IP address of the destination party is sent.

Although the Detailed Description of the invention has been directed to certain exemplary embodiments, various modifications of these embodiments, as well as alternative embodiments, will be suggested to those skilled in the art. The invention encompasses any modifications or alternative embodiments that fall within the scope of the Claims.

Claims

" CLAIMS

1. Circuitry for providing public network services, comprising: circuitry for receiving a logical address from a user at a network access provider; database circuitry for determining a physical address associated with said logical address, where said logical address can be associated with more than one physical address, based on one or more current parameters.

2. The circuitry of claim 1 wherein one of said parameters comprises a time of day parameter.

0 3. The circuitry of claim 1 wherein one of said parameters comprises a day of week parameter.

4. The circuitry of claim 1 wherein one of said parameters comprises a load parameter.

5. The circuitry of claim 1 wherein one of said parameters comprises a 5 location associated with the user.

6. The circuitry of claim 1 wherein one of said parameters comprises a telephone number associated with the user.

7. The circuitry of claim 1 wherein one of said parameters comprises a profile information associated with the user.

0 8. The circuitry of claim 1 said database circuitry comprises a service control point.

9. The circuitry of claim 1 wherein said physical address comprises a physical address associated with a digital phone for audio communication through the global network.

10. The circuitry of claim 9 wherein one of said parameters comprises a location of an operator associated with said digital phone.

11. A method for providing public network services, comprising: receiving a logical address from a user at an global network access provider; determining a physical address associated with said logical address, where said logical address can be associated with more than one physical address, based on one or more current parameters.

12. The method of claim 11 wherein said determining step comprises the step of determining the physical address based at least partially on a time of day parameter.

13. The method of claim 11 wherein said determining step comprises the step of determining the physical address based at least partially on a day of week parameter.

14. The method of claim 11 wherein said determining step comprises the step of determining the physical address based at least partially on a load parameter.

15. The method of claim 11 wherein said determining step comprises the step of determining the physical address based at least partially on a location associated with the user.

16. The method of claim 11 wherein said determining step comprises the step of determining the physical address based at least partially on a telephone number associated with the user.

17. The method of claim 11 wherein said determining step comprises the step of determining the physical address based at least partially on a profile information associated with the user.

18. The method of claim 11 wherein said determining step comprises the step of determining the physical address based using a service control point.

19. The method of claim 11 wherein said determining step comprises the step of determining a physical address associated with a digital phone for audio communication through the global network.

20. The method of claim 19 wherein said determining step comprises the step of determining the physical address based at least partially on a location of an operator associated with said digital phone.

21. Circuitry for providing telephony locator services, comprising: circuitry for receiving a request from a calling party over a public network for a physical address associated with a logical address of a destination party; database circuitry for determining a physical address associated with said request, where said logical address can be associated with more than one physical address, based on one or more current parameters.

22. The circuitry of claim 21 wherein one of said parameters comprises a time of day parameter.

23. The circuitry of claim 21 wherein one of said parameters comprises a day of week parameter.

24. The circuitry of claim 21 wherein one of said parameters comprises a day of week.

25. The circuitry of claim 21 wherein one of said parameters comprises a location associated with the calling party.

26. The circuitry of claim 21 wherein one of said parameters comprises a telephone number associated with the user.

27. The circuitry of claim 21 and further comprising circuitry for translating between data packets and audio signals.

28. The circuitry of claim 21 wherein said logical address is selected from a list of names.