System and method for providing service control to a single telephone end terminal from multiple service providers

[0002] The present invention relates to service provision for IP telephony network systems and subscribers to such systems. More specifically, the present invention relates to providing for multiple service providers per subscriber on a single IP telephony network system.

[0003] In current telephone networks, users receive service from a single, licensed monopoly telephone company service provider. This structure is primarily enforced through a physical association between the copper loop that provides network access and the telephone company's switching equipment. The present invention utilizes an IP network capable of supporting multiple service providers and their service offerings from a single terminal or access infrastructure.

[0004] The Telecom Reform Act of 1996 resulted in a government mandate to “unbundle” services within the telephone network. Multiple unbundling points were identified and defined including the copper loop interface at the main distribution frame in the central office and T1 channel bank or TR-303 systems. This gives competing telephone companies a means for providing services to subscribers using the monopoly telephone company's existing loop plant. The competing telephone companies achieve this by “swinging” lines (rewiring) to their equipment.

[0005] This solution has several shortcomings, however. It is subject to line scale granularity meaning the entire phone service for the local loop moves at once. Moving a line requires manual intervention in order to physically rewire connections. This can be prohibitively expensive, especially since it requires explicit cooperation from the incumbent telephone company. Moreover, service access is limited to those firms which are registered local exchange telephone companies.

[0006] Currently, in H.323 processing the zone manager and service control unit (SCU) is a single undivided concept. The present invention promotes the idea of having more than one service provider (SCU) serving a single subscriber. This is done by splitting the zone manager and SCU into separate concepts allowing for an unrelated, even dynamic, allocation of an SCU to a zone.

[0007] By using H.323 capability in a gatekeeper to identify call signaling transfer addresses used for each call, subscriber services can theoretically be provided by different service providers on a per call basis. For example, one subscriber service can be provided by a first service provider while a second subscriber service may be provided by a second service provider, and so on. In practice, service subscription data is based on the address or alias being used to place or receive a call. Since IP telephones can have the ability to register multiple aliases simultaneously, the same phone can receive service from multiple providers simultaneously. In addition, it is possible that some of the aliases used may be part of a private address space such as, for instance, a private branch exchange (PBX) system. This would enable service from a provider that is not a registered public telephone service provider for work-at-home and telecommuting subscribers.

[0008] Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.

[0009] FIG. 1 illustrates one potential IP network architecture for carrying out the present invention.

[0010] FIG. 2 is a message sequence chart illustrating the registration process of the present invention.

[0011] FIG. 3 is a message sequence chart illustrating the messaging involved for an incoming call to a subscriber.

[0012] FIG. 4 is a message sequence chart illustrating the messaging involved for an outgoing call from a party and a call to a party within the same multi-SCU system.

[0013] The present invention is chiefly described in terms of its preferred embodiment, namely, an H.323 Internet protocol (IP) network implementation. However, other embodiments may be utilized such as, for instance, a wireless network or Session Initiation Protocol (SIP) network, without departing from the spirit or scope of the present invention.

[0014] FIG. 1 illustrates one potential IP network architecture implementing the present invention. A first zone 101 is comprised of a plurality of terminals or clients 102 connected to a computer network 104 such as, for instance, a local area network (LAN) or a wide area network (WAN) which is serviced by a first zone manager 106. The terms “client” and “terminal” are used interchangeably throughout this description. Similarly, a second zone 107 is also comprised of a plurality of terminals or clients 108 connected to a computer network 110 such as, for instance, a local area network (LAN) or a wide area network (WAN) which is serviced by a second zone manager 112. The zone managers are responsible for managing the registration state information of the terminals under their domain. Although not illustrated, there may be further zones in the system. Each of the zones has a physical link from its computer network (WAN/LAN) to a larger IP network 114. IP network 114, in turn, is communicable with a directory 116 and a plurality of different service providers in the form of service control units (SCUs) 118.

[0015] An SCU can also possess switching ability creating an integrated intelligent signaling gateway, call agent, and/or media gateway 119. Or, an SCU may be a private branch exchange (PBX) 122 or Central Office (CO) switch 124 with an internal gateway. Gateway 122 is controlled by SCU 1 and gateway 124 is controlled by SCU 2 in FIG. 1. A PBX or CO is a collection of gateways and an SCU in this model. The SCU nodes 118, 119 are also linked to the public switching telephone network (PSTN) 120. It is to be understood that equivalents of each node may be substituted without departing from the spirit or scope of the present invention. For example, in a wireless network a home location register (HLR) performs the same functions as the directory 116.

[0016] Individual clients or terminals in each zone are able to communicate with one another over the IP network. The various parameters controlling services and their associated service provider (SCU) addresses are contained in a subscriber profile stored within the directory 116. Thus, whenever an incoming or outgoing call commences, network logic accesses the subscriber's zone manager 106 and determines which service provider, i.e., SCU address, is responsible for providing that particular service to the subscriber. Zone manager 106 obtains a copy of the registration data (including the SCU address to use for a given service) from the directory during the registration process. The relevant service data is then gathered and exchanged via a sequence of messages. How the call is connected is based on the relevant service data.

[0017] If a wireless implementation is utilized then the directory would be substituted with a home location register (HLR) and the zone manager would be substituted with a visitor's location register (VLR). A more complete description of a wireless implementation is contained in a co-pending application entitled “System, Method, And Computer Program Product For Connectivity Of Wireless Base Station To PSTN Via An IP Data Network” (Ser. No. 09/280,152), the entire contents of which are incorporated herein by reference.

[0018] If a Session Initiation Protocol (SIP) implementation is utilized then SIP proxy servers would be substituted for the zone manager and SCU nodes.

[0019] Services available to telephony subscribers are numerous. The table below illustrates a sampling of services that are offered. Subscribers, via the present invention, have the ability to have multiple different service providers provide their services. It is to be understood that the following table is not intended to be a complete listing of all available services, rather an illustrative sampling of same.

[0020] FIG. 2 is a message sequence chart illustrating the registration process of the present invention in an IP network environment. All messages have been defined using the H.323 protocol. However, other protocols such as SIP, for instance, may be utilized without departing from the spirit or scope of the present invention. The registration process is necessary for each client/terminal address pair, i.e. for each alias supported at each terminal. Thus, when a client registers, the client is registering with all the SCUs that can potentially provide a service to the aliases of that client. FIG. 2 is illustrative of how registration messaging occurs on a per SCU basis. While only two SCUs have been shown, it is understood that an identical registration process occurs for each potentially serving SCU. Initially, the client sends a registration message to its serving zone manager. The zone manager address is determined using the mechanisms defined in the H.323 protocol for gatekeeper discovery. One of the parameters of the registration message is the alias, e.g., directory number (DN), of the terminal. Since it is possible for a client to support multiple aliases, it is necessary for the client to specify which aliases are being registered. Another parameter in the registration message is the client address. The zone manager then sends the registration message to the directory. The directory maintains the subscriber's service profile data and is responsible for determining which SCU will process the call based on the alias in question. In this example, SCU 1 is the responsible SCU. At this point the system may register the alias with that SCU in one of two alternative ways.

[0021] The sequence in FIG. 2 labeled “a” can be termed zone manager registration of an alias since the zone manager sends the registration message to the SCUs. A registration message containing the alias and client address of the terminal is sent from the client to the zone manager when the terminal is turned on. The zone manager then sends the registration message to the directory. In this scenario, an acknowledgment message is sent from the directory back to the zone manager with the address of SCU 1 contained in the message. The zone manager then assumes responsibility for sending the registration message complete with alias and client address to SCU 1. SCU 1 then replies to the zone manager with an acknowledgment containing the address of SCU 1. The zone manager then sends a general acknowledgment message to the client thereby completing the registration process for that alias. This process can be repeated as required for multiple aliases.

[0022] The sequence in FIG. 2 labeled “b” can be termed directory registration of an alias since the directory sends the registration message to the SCUs. A registration message containing the alias and client address of the terminal is sent from the client to the zone manager when the terminal is turned on just as above. The zone manager then sends the registration message to the directory. This time the directory forwards the registration message to SCU 2. An acknowledgment message is returned to the directory. The directory inserts the address of SCU 2 into the acknowledgment and sends it on to the zone manager. The zone manager then sends a general acknowledgment back to the client thereby completing the registration process for that alias. Again, this process can be repeated as needed for multiple aliases.

[0023] It should be noted that messages which register the client address with the SCU can be omitted. Doing so, however, would require the SCUs to consult with the directory prior to each setup message they send in order to determine the current address of the client. This is the mechanism in use today for cellular networks.

[0024] Scenario “c” demonstrates client/terminal registration of multiple aliases in a single registration message using the zone manager alias registration process described in scenario “a”. Scenario “c” illustrates two aliases being registered in a single step. However, more aliases could have been included in the registration message if desired. The client sends a registration message containing the two aliases and the client's terminal address to the zone manager. The zone manager sends this registration message on to the directory. The directory determines which SCU serves which alias and returns an acknowledgment to the zone manager containing the addresses of the two SCUs. The zone manager then sends a registration message to each SCU containing the alias for that SCU as determined in the directory as well as the client's terminal address. In this example, the zone manager sends a registration message with alias 1 and the client's terminal address as parameters to SCU 1. SCU 1 responds with an acknowledgment back to the zone manager containing the address of SCU 1. The zone manager also sends a registration message with alias 2 and the client's terminal address as parameters to SCU 2. SCU 2 responds with an acknowledgment back to the zone manager with the address of SCU 2. Once all the SCUs have responded with specific acknowledgments, the zone manager sends a general acknowledgment to the client indicating that all aliases have been registered with their respective SCUs. Alternatively, the zone manager could acknowledge each alias as it receives an acknowledgment from the servicing SCU.

[0025] Once a client has registered an alias, incoming and outgoing calls may be handled according to standard call and feature signaling. FIG. 3 is a message sequence chart illustrating the messaging involved for an incoming call to a subscriber's terminal. A call from outside of the system arrives at the appropriate SCU based on standard PSTN routing procedures. The SCU sends a call setup message to the client using the terminal address acquired during registration. The setup message contains SCU information identifying the SCU responsible for processing the call. The client then sends an authorization request (ARQ) message to the client's zone manager. The zone manager replies with an authorization confirmed (ACF) message. The authorization request (ARQ) and authorization confirmed (ACF) messages serve to authenticate the nodes and grant admission to the call on a per call basis. Each message also contains a parameter identifying the address of the responsible SCU based on the specific alias involved. The call is now processed according to standard call and feature signaling. Scenario “b” is identical to scenario “a” except that a different service provider is used for the call due to the fact that the alias used for the call receives services administered by another SCU.

[0026] FIG. 4 is a message sequence chart illustrating outgoing call processing. Scenario “a” illustrates the messaging involved for an outgoing call to a party potentially in the PSTN. To place this type of outgoing call, an authorization request (ARQ) message is sent from the client to the zone manager containing the alias of the calling terminal. The zone manager responds with an authorization confirmed (ACF) message back to the client including the SCU address of the SCU servicing the call. Upon authentication, a setup message is sent to the proper SCU and the call is placed to the intended party. The call is now processed according to standard call and feature signaling.

[0027] Scenario “b” illustrates placing a call to a party within the same system using SCU 2 for control and terminating on a client address that is serviced by SCU 1. The client sends an authorization request message containing its alias and a destination address to the zone manager. The destination address refers to the called party's terminal alias. The zone manager returns an authorization confirmed message having the address of the SCU serving the caller's alias, SCU 2 in this case. A setup message containing the destination address is then sent from the client to SCU 2. SCU 2 then sends a lookup message having the destination address to the directory. The directory locates the appropriate SCU for the destination address and returns an address message containing the address of the appropriate SCU (SCU 1 in this example) to SCU 2. SCU 2 then sends a setup message containing the destination address to SCU 1. At this point the call is handled according to standard call and feature signaling. This scenario highlights the present invention's ability to have an originating SCU utilize the Directory to discover the proper terminating SCU for a call within the same system.

[0028] By way of example, consider a terminal having two aliases, namely a home directory number and a work directory number. The home directory number is serviced by the local telephone company's SCU for that area code and exchange. The work number, however, is serviced by a local PBX system acting as an SCU. Thus, when the terminal is turned on, the home directory number (alias 1) registers with the telephone company's SCU while the work directory number (alias 2) registers with the local PBX. Thereafter calls to and from the home directory number are processed by the telephone company's SCU and calls to and from the work directory number are processed by the local PBX. Thus a single client/terminal is serviceable by multiple service providers.

[0029] It is to be understood that the present invention illustrated herein is readily implementable by those of ordinary skill in the art as a computer program product having a medium with a computer program embodied thereon. The computer program product is capable of being loaded and executed on the appropriate computer processing device(s) in order to carry out the method or process steps described. Appropriate computer program code in combination with hardware implements many of the elements of the present invention. This computer code is often stored on storage media. This media can be a diskette, hard disk, CD-ROM, or tape. The media can also be a memory storage device or collection of memory storage devices such as read-only memory (ROM) or random access memory (RAM). Additionally, the computer program code can be transferred to the appropriate hardware over some type of data network.

[0030] In the following claims, means-plus-function clauses are intended to cover the structures described herein as performing the recited function and not only structural equivalents but also equivalent structures. Therefore, it is to be understood that the foregoing is illustrative of the present invention and is not to be construed as limited to the specific embodiments disclosed, and that modifications to the disclosed embodiments, as well as other embodiments, are intended to be included within the scope of the appended claims. The invention is defined by the following claims, with equivalents of the claims to be included therein.