WO2000072559A1

WO2000072559A1 - Method and system for introducing new services into a network

Info

Publication number: WO2000072559A1
Application number: PCT/US2000/011759
Authority: WO
Inventors: Richard James Malcolm; Daniel Francis Tell; Thomas James Joyner; William S. Pierce
Original assignee: Motorola, Inc.
Priority date: 1999-05-20
Filing date: 2000-05-01
Publication date: 2000-11-30
Also published as: AR024048A1; AU4687400A

Abstract

A method for introducing new features into a network is provided, the method including having a user identifier associated with a subscriber, providing a service dependent call model (111), and a response to receiving the user identifier, accessing service logic associated with the service dependent call model that has been customized for the subscriber.

Description

METHOD AND SYSTEM FOR INTRODUCING NEW SERVICES INTO A

NETWORK

Related Applications

The following applications are related to this application and are filed on the date herewith. The disclosure of each of these related applications is incorporated by reference: S/N Pocket Number CE08072R) titled "METHOD FOR CHANGING COMMUNICATION IN A COMMUNICATION SYSTEM, AND COMMUNICATION SYSTEM THEREFOR"; S/N (Docket Number CE08136R) titled "METHOD FOR ESTABLISHING COMMUNICATION IN A PACKET NETWORK"; S/N (Docket Number CE08135R) titled "METHOD FOR RETRANSMITTING A DATA PACKET IN A PACKET NETWORK"; S/N (Docket Number CE08170R) titled "COMMUNICATION NETWORK METHOD AND APPARATUS"; S/N ocket Number CE08169R titled "METHOD AND SYSTEM FOR PROCESSING INTELLIGENT NETWORK COMMANDS IN A COMMUNICATIONS NETWORK"; S/N pocket Number CE08182R titled "METHOD AND SYSTEM FOR NETWORK SERVICE NEGOTIATION IN A TELECOMMUNICATIONS SYSTEM"; S/N (Docket Number CE08186R) titled "METHOD AND APPARATUS FOR ROUTING PACKET DATA IN A COMMUNICATIONS SYSTEM"; S/N pocket Number CE08193R) titled "SESSION BASED BILLING IN A COMMUNICATION SYSTEM".

Field of the Invention

This invention relates generally to communications networks, and, more particularly, to a method and system for introducing new services into a communication network.

Background of the Invention

The intelligent network concept was developed as a means of introducing new features into a network without having to modify existing switching equipment, as such modifications were expensive and difficult. However, today's intelligent network architectures have several drawbacks. Those developed for wireline systems, such as the advanced intelligent network (AIN) or the ITU CS- l/CS-2 intelligent network do not adequately support mobility, since triggering mechanisms are based on subscription data in the local exchange. Those that support mobility (WIN/INAP) do so by moving feature control to a centralized point in the network (e.g., to the home location register (HLR) or to service control points (SCP)). This increases the expense and complexity of the network equipment. Typically, intelligent network specifications define their own standardized message protocol between the switch and the SCP or the HLR, leading to two difficulties. One difficulty is that the standards process inevitably leads to a prptocol that supports only those capabilities common to all equipment providers, so it is often difficult or impossible to develop features based on more advanced capabilities. Furthermore, the intelligent network protocol is an integral part of the switching equipment, making it virtually impossible to use the same switching equipment for integrated wireline and wireless service.

Another drawback to current intelligent network approaches is that they are network-centric models that are not well suited to intelligent endpoints, since intelligent networks put all service intelligence in the network itself. In the future, internet protocol based telephony will push more and more intelligence to the edges of the network, which is inconsistent with the intelligent network approach. However, wireless handsets, because of their stringent power requirements, complex connection management algorithms, and limited access to network bandwidth, will lag behind fixed systems in this regard.

Another problem with the present intelligent network is that services are typically tied to a particular instrument, phone line, or subscriber unit. This has the disadvantage of preventing the customer from having his or her own services provided while using another subscriber unit. For example, if the customer owns several subscriber units, the customer may wish to switch between them for various reasons and have the same service logic follow the customer from one unit to the next. In another example, the customer may wish to borrow or rent a subscriber unit and quickly and easily have all of his or her user defined services available. Thus, there is a need for an improved method and system for introducing new services into a communication network. In addition, there is a need for a network architecture that can support intelligent end points as well as terminals with limited call control capabilities for both wireline and wireless systems. In addition, there is a need for a network architecture that allows new services to be introduced without involving the network provider.

Summary of the Invention

According to an aspect of the present invention, the foregoing problems are ameliorated by a method for introducing new features into a network, which includes having a user identifier associated with a subscriber, providing a service dependent call model, and, in response to receiving the user identifier, executing service logic associated with the service dependent call model that has been customized for the subscriber.

In accordance with another aspect of the present invention, a method for introducing services customized for a particular subscriber into a network includes having a user identifier associated with a subscriber, providing a service dependent call model, determining a home service provider address of the subscriber, and in response to receiving the home service provider address, accessing service logic associated with the service dependent call model that has been customized for the subscriber from a node within the network. Other advantages of the present invention will become readily apparent to those skilled in the art from the following description of the preferred embodiments of the invention which have been shown and described by way of illustration. As will be realized, the invention is capable of other indifferent embodiments, and its details are capable of modifications in various respects. Accordingly, the drawings and description are to be regarded as illustrated in nature, and not as restrictive.

Brief Description of the Drawings

The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objects, and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

FIG. 1 generally depicts an embodiment of network architecture in accordance with the present invention;

FIG.2 generally depicts an example of feature server access;

FIG. 3 generally depicts another example of feature server access; and

FIG. 4 generally depicts an embodiment of the present invention wherein a prepaid calling feature that uses triggering and downloadable service logic is shown.

FIG. 5 generally depicts an embodiment of the present invention wherein an example of a personal call screening feature that is invoked on terminations is illustrated.

Detailed Description of the Invention Turning now to the drawings, wherein like numerals designate like components, FIG. 1 illustrates a block diagram showing a subscriber unit's 102 initial access to the system 100. Subscriber unit 102 may be a mobile unit or a fixed unit. Associated with a subscriber is a user identifier which may be assigned to multiple subscriber units such as a cellular phone, a PDA, a fixed handset, a fixed wireless terminal, or other such access devices. The subscriber unit 102 registers in system 100 via control line 104. The initial subscriber access in the system 100 causes a control message to be sent from the access network 106 to the services client 110 via control line 108. Access network 106 may be any access network. A registration request is an example of this type of access in a wireless system.

Services client 110 provides a service logic execution environment, which allows for the execution of dynamic and customizable telephony/computer features and services on behalf of a subscriber and the subscriber's access device (e.g. subscriber unit 102). The service logic execution environment may be a standard run-time environment such as the Java Virtual Machine. Service logic is a block of software and data that when executed or operated on, performs computer and telephony related features and services on behalf of a subscriber and the subscriber's access device. Service logic can execute entirely on the services client 110 or subscriber unit 102, or it can be accessed by and executed on the feature server 124, 130 or the home service provider 118. Service logic is inyoked during the sequencing of calls, and in the preferred embodiment is defined on a per-subscriber basis, and can be either pre-loaded or obtained via download from one or more feature servers 124, 130. Service logic can be used locally to invoke services, such as a subscriber's speed dialing list, or to invoke interactions with external feature servers. For example, service logic that is invoked when a particular digit string is dialed may cause a trigger to a particular feature server that is handling feature setups for the subscriber. The services client 110 provides a common API to service logic for call control, and also provides extended API's that are unique to a particular access type. For example, CDMA specific API's will allow access to data specific to the CDMA air interface. The service logic uses a published API on the services client 110, and may be a simple scripting language or a standard programming language such as Java. The home service provider will also provide a list of feature service addresses in the form of IP address or URLs, that the services client will access in a similar fashion. The services client 110 includes core call model 113. Call model 113 provides a set of triggers and notifications to the service logic, including origination, termination, and location change (registration and handoff). It also provides a set of call control API's to the service logic. For example, deny call, divert call, setup IP call to core network, collect digits from the subscriber, digit string substitution, page subscriber in radio network, provide short message to subscriber, and feature server access are examples of call triggers and call control capabilities provided by call model 113. As described above, the services client 110 can receive and execute service logic from a home service provider associated with a subscriber and also from feature servers which provide specific features. The service logic received from a home service provider or a feature server may also instruct the service client 110 to trigger call control to a feature server in certain points in the call. In addition, the services client 110 acts as a proxy for subscribers that are present in the local network. It supports the download of service logic from the feature server to the serving system. This logic can execute at either the services client 110 or at the subscriber unit 102 itself, depending on the subscriber unit's capabilities.

The services client 110 queries the home service provider directory server 112 to get the home service provider address of the subscriber unit 102 via control line 114. The home service provider directory server 112 contains a subscriber identity to home service provider address database 113 that will map a subscriber identification number into a home service provider address. The home service provider directory server 112 is a transaction server that processes requests containing a subscriber identification number, maps the subscriber identification number into a home server provider address using the database, and responds to the requesting services client with the home service provider address. The home service provider directory server 112 can service multiple service clients. The home service provider directory server address is a well-known address and is programmed in or derived by the services client 110. In addition, the home service provider directory server 112 provides a means for determining the home service provider associated with a particular subscriber identification number. The home service provider directory server 112 has a well known domain name, allowing it to be located using standard DNS procedures. In addition, it can be accessed using a standard directory protocol like LDAP. The services client 110 can access multiple home service provider directory servers. An intelligent endpoint may provide its home service provider address during the access, making the home service provider directory server access unnecessary.

The home service provider address is returned to services client 110 via control line 116. The services client 110 queries the home service provider (HSP)

118 for the subscriber's service logic via control line 120. HSP 118 contains several databases that are indexed by the subscriber identification number relating to (i) the location of the subscriber (location database 119), (ii) a subset of the service profile of the subscriber (subscriber profile database 121), and (iii) a list of feature servers (feature server list database 123) that will perform other specialized feature control for the subscriber. HSP 118 is also a feature server and may contain service logic that can execute on the HSP server or can be downloaded and executed in the services client 110. Upon registration of the subscriber unit 102, the home service provider 118 will receive the location of the subscriber unit 102 from the services client 110 via control line 122. HSP 118 stores the location of the subscriber unit 102 into its location database 119. The HSP 118 will retrieve the profile of the subscriber from the subscriber profile database 121, retrieve any service logic to be executed (in the preferred embodiment to be executed on the services client), and retrieve a prioritized list of feature server addresses from the feature server list database 123 to be accessed for the subscriber. The HSP 118 will then return this information and service logic to the requesting services client. In addition, the HSP 118 maintains the dynamic location of the services clients for its subscribers, and it provides a list of feature servers that should be accessed when the services client is instantiated in a serving system. The dynamic location of the subscriber is maintained at the HSP 118 for mobility purposes. In addition, the location at the HSP allows for further customization of subscriber features based on the subscriber's current location. For example, a call may be billed at a different rate if the subscriber is located at or near their home. Service logic which performs location sensitive applications can be accessed from the HSP 118 or feature server 124, 130 and introduced into the network without modifications to the core network. In addition, the HSP acts as a repository for common subscriber profile information. The distribution of profile information between the HSP and feature servers is implementation dependent.

The services client 110 accesses the first feature server 124 on the prioritized list via control line 126 to get service logic and data for the subscriber. A feature server provides one or more computer or telephony features for a subscriber and contains a database of subscriber profile information (subscriber profile database 125) specific to the feature being provided. A feature server can provide this service by executing the service logic locally at the feature server or it can provide/download the service logic to a services client in the network or to the subscriber unit, depending on the subscriber unit's capabilities. A feature server can operate with the media of telephony services or simply handle control messages from the services client. Unlike intelligent network protocols, which define a standard interface back to their respective service control points, the feature server can be accessed in one of several ways: (i) by opening a private connection to the feature server for the exchange of control information using standard internet protocols such as TCP/IP; (ii) by accessing the feature server using a standard internet telephony protocol such as H.323. The feature server can subsequently use procedures inherent in these protocols to gain access to the media stream for the call, redirect the call, or end the call; and (iii) through a standard, or "well known" triggering protocol. This is similar to the approach defined in the advanced intelligent network, it is just a specific implementation of the approach described in (i) above. Unlike intelligent network protocols which send triggers to predetermined, centralized control points, the destination of a call trigger to feature servers is dynamic in nature and can be sent to multiple feature servers distributed throughout the network. By allowing the feature server to be accessed in several ways, the service designer is given more flexibility in deciding how much logic executes locally, and how much executes back at the feature server, and also allows multiple triggering protocols to be supported simultaneously. Any number of feature servers that provide telephony services may be supported by the system 100. The feature servers are platforms whose functionality is dependent on the provider of the service. They may be media capable, or simply handle control messages from the services client. In addition, there may be multiple feature servers providing the same features to the network, giving the subscriber options for choosing the provider of certain features.

Finally, feature severs may allow a subscriber to invoke services on a per use basis to avoid monthly charges of certain features that may not be invoked every month.

Feature server 124 returns the subscriber data and service logic to services client 110 via control line 128. Services client 110 thereafter accesses the next feature server 130 on the prioritized list via control line 132 to get service logic and data for the subscriber. Feature server 130 returns the subscriber data and service logic via control line 134. Finally, the registration acknowledge is returned to the subscriber unit 102 via control lines 136 and 138. The preceding relates to the setup of the local services client proxy for handling unintelligent terminals. An intelligent terminal may be able to supply its own HSP address, obviating the need for accessing the directory server. An intelligent terminal may also store its own service logic and data and so may rely on the HSP and feature server for only a small set of network services, such as call handling when the terminal is powered down.

After the initial access to the system, the feature servers may subsequently be accessed during call processing, the type of access being dependent upon the service logic. There are two ways that a feature server can gain control of a call: either the call must be directly handled by the feature server, or else another entity that is handling the call must trigger to the feature server at points in the call, and accept instructions from the feature server to direct the setup of the call.

FIG. 2 illustrates a first example of feature server access. In this example, service logic directs the services client 110 to make an internet telephony call (e.g., H.323) to the feature sever 124. The service logic passes control to feature server 124 by calling it using H.323. Feature server 124 can then process the call locally, redirect it using H.323 procedures, or potentially trigger out to other feature servers that are outside of the network. This allows media to be delivered to the feature server platform for specialized processing by the platform. It also may simplify the feature server, which need only be compliant with the internet telephony protocol, allowing standard call control APIs (e.g., TAPI) or media control APIs (e.g., S.100) to be used for the feature server application. Note that this approach still allows the feature server to subsequently control and route the call using redirection procedures inherent in the internet telephony protocol.

FIG. 3 shows another example of how a feature server may be accessed using triggering. Service logic that is executing in the services client 110 triggers during call processing and sends a private message to the feature server 124. The underlying mechanism for delivering the message will be a standard IP protocol like UDP or TCP, or a more sophisticated mechanism such as CORBA. The feature server 124 may then respond to the services client 110. This response is interpreted by local service logic (again, supplied by the feature server) that can modify the call processing through a local service API. In this architecture, standardized intelligent network interfaces, such as AIN or WIN can also be supported. Thus, this mechanism allows support of multiple IN interfaces in the same platform, and even allows the particular interface to be chosen on a per call basis.

It should be noted that both examples discussed above methods may be combined in the same call. For example, it is possible for a services client to trigger to a feature server, and subsequently access it using internet telephony protocols, or for a feature server first accessed via internet telephony to redirect a call and then subsequently receive a call trigger. It should also be noted that the execution of service logic and triggering control to a feature server can occur for calls to the subscriber or calls from the subscriber and also in cases where the subscriber is not actively engaged in voice conversation.

The feature server /HSP approach differs from current intelligent network protocols in that it does not assume or require a common repository for subscriber profile information, and it does not define an absolute set of subscriber profile information. This information may be distributed between the HSP, the feature servers, and the subscriber unit itself. HSPs and feature servers exist to provide capabilities and services that are not practical to support in the subscriber unit itself.

Another area where this approach differs from current intelligent networks is feature precedence. The traditional approach to solving the issue of precedence when multiple feature requests collide is to embed the precedence within the service logic. This approach requires every possible combination to be considered in the service logic, with the same rules applied to any subscriber.

The service based call model in conjunction with the support of the HSP and feature servers allows feature precedence to be customized for a given subscriber. The customer has the option to utilize the default specification embedded in the service logic, utilize the feature specification based in the HSP which contains a list of features in order of precedence, use a subscriber provided list at access time (such as stored on a sim card), or have precedence embedded in the custom service logic for the subscriber.

The precedence specification in this case only need consider the services that the subscriber is capable of using, (i.e. has subscribed to). The precedence specification is updated to reflect the addition of or deletion of services or features from the subscriber's profile. The service purchasing procedure will automatically update the specification per the subscriber's preferred method of precedence. The subscriber is free to alter the system generated update.

With reference to FIG. 4, an example of a prepaid calling feature that uses triggering and downloadable service logic is illustrated. Upon initial registration, the services client is loaded with logic from the prepaid calling feature server that sends a message to the services client when the subscriber originates specific calls (i.e., international calls). This triggers a download of additional service logic to do additional call control and timing functions. In particular, the subscriber unit 102 originates a call via control line 404. The setup message is sent from the access network 106 to the services client 110 via control line 408. Prepaid calling logic in the services client 110 recognizes that this is a prepaid calling call. A message is sent to the prepaid calling feature server 410 via control line 412 to report the prepaid calling origination. The prepaid calling feature server 410 looks up the subscriber's account information and returns service logic to services client 110 via control line 414 that will time the call and take action should timeout occur. The call is setup using "normal procedures", wherein services client 110 send a setup message to PSTN gateway 420 via control line 416, which sends a setup message to PSTN 420 via control line 422. PSTN 420 sends an answer message to PSTN gateway 202 via control line 424, which sends an answer message to services client

110 via control line 426. Prepaid calling logic starts timer 430 when the call is answered. When the prepaid calling logic in services client 110 times out, it is programmed to release the call. Because prepaid calling logic is executing locally, it may also have put the original call on hold and originated a new call to the prepaid calling feature server 410, which could have played a special announcement or asked for authorization of a credit card debit. Prepaid calling logic in the services client 110 reports the time remaining to the prepaid calling feature server 410. In this case, prepaid calling logic reports that the time has expired via control line 432. Thereafter, the call is released, wherein services client 110 reports to PSTN gateway 202 that time has expired and the call is to be released via control line 434, which reports to PSTN 420 that the call is to be released via control line 436. In addition, services client 110 reports to access network 106 that time has expired and the call is to be released via control line 438. Access network 106 reports to subscriber unit 102 that time has expired and that the call is to be released via control line 440.

Referring now to FIG. 5, an example of a personal call screening (PCS) feature that is invoked on terminations is illustrated. Upon initial registration, the services client is loaded_.with logic from the personal call screening feature server that will redirect calls to the personal call screening feature server when there is an attempt to terminate to the subscriber. This redirection may be based on certain criteria, such as for unrecognized caller IDs, if the called subscriber is busy, etc., defined in the service logic. In particular, an incoming call to the subscriber arrives at the PSTN gateway 502 from the PSTN 503 via control line 504. An admission request message is sent to the gatekeeper 506 via control line 508. The admission request message contains the subscriber's directory number. The gatekeeper 506 accesses the HSP directory server 510 via control line 512 to obtain the subscriber's HSP address. The HSP address is returned to the gatekeeper 506 via control line 514, and the HSP address is returned to the PSTN gateway 502 via control line 516. The PSTN gateway 502 sets up a call to the subscriber's home service provider (HSP) 520 via control line 518. The HSP 520 redirects the call to the services client associated with the subscriber, wherein a redirect message is sent from HSP 520 to PSTN gateway 502 via control line 522. The PSTN gateway 502 sets up the call to the services client 524 via control line 526. Personal call screening service logic in the services client 524 runs when the termination attempt occurs, and redirects the call to the personal call screening feature server

530, wherein a redirect message is sent from services client 524 to PSTN gateway 502 via control line 528, and a setup message is sent from PSTN gateway 502 to personal call screen feature server 530 via control line 532. The personal call screen feature server 530 is called. As part of the voice over IP call setup, a media path 534 is established from the PSTN gateway 502 to the personal call screen feature server 530. The personal call screening feature server 530 prompts PSTN gateway 502 for additional call information, such as caller name, reason for call, password, etc. using voice recognition to obtain the response. In this case, the call is not allowed. The personal call screening feature server thereafter plays an audio message and releases the call, wherein a call release message is sent from personal call screening feature server 530 to PSTN gateway 502 via control line 536, and a caller release message is sent from PSTN gateway 502 to PSTN 503 via control line 538.

The foregoing description of a preferred embodiment of the invention has been presented for the purpose of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Obvious modifications or variations are possible in light of the above teachings. The embodiment was chosen and described to provide the best illustration of the principles of the invention and its practical application, and to enable one of ordinary skill in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. All such modifications and variations are within the scope of the invention as determined by the appended claims when interpreted in accordance with the breadth to which they are fairly, legally, and equitably entitled.

Claims

ClaimsWhat is claimed is:

1. A method for introducing new features into a network, comprising the steps of:

having a user identifier associated with a subscriber;

providing a service dependent call model; and

in response to receiving the user identifier, accessing service logic associated with the service dependent call model that has been customized for the subscriber.

2. A method as recited in claim 1, including one of:

the step of allowing feature precedence to be customized for a given subscriber; and

the step of dynamically changing a destination of a call trigger.

3. A method as recited in claim 1, wherein the step of accessing comprises one of downloading and transferring control.

4. A method as recited in claim 1, wherein service logic execution occurs in one of:

a feature server, the feature server including a subscriber profile database containing subscriber profile information specific to a feature or service being provided;

a services client, the services client comprising a core call model adapted to access the service logic; and

a home services provider, the home services provider comprising a plurality of databases that are indexed by the user identifier, the plurality of databases including a subscriber location database, a subscriber profile database, and a feature server list database.

5. A method as recited in claim 4, including one of:

the step of downloading the services logic from a feature server to the services client; and

the step of downloading the services logic from a home services provider to the services client.

6. A method as recited in claim 5, wherein the subscriber location database includes information relating to the location of the subscriber, the subscriber profile database includes information relating to a service profile of the subscriber, and the feature server list database includes information relating to a prioritized list of feature servers that are adapted to perform other specialized feature control for the subscriber.

7. A method for introducing services customized for a particular subscriber into a network, comprising the steps of:

having a user identifier associated with a subscriber;

_* providing a service dependent call model;

determining a home service provider address of the subscriber; and

in response to receiving the home service provider address, accessing service logic associated with the service dependent call model that has been customized for the subscriber from a node within the network.

8. A method as recited in claim 7, including one of:

the step of dynamically changing a destination of a call trigger.

9. A method as recited in claim 7, wherein the step of accessing comprises one of downloading and transferring control.

10. A method as recited in claim 7, wherein the node comprises a services client, the services client including a core call model, the services client being adapted to access the service logic and further being adapted to execute the service logic.

11. A method as recited in claim 10, including the step of accessing a feature server, the feature server including a subscriber profile database containing subscriber profile information specific to a feature or service being provided.

12. A method as recited in claim 11, wherein the step of accessing includes one of;'

the services client making an internet telephony call to the feature server; and

the services client using a triggering protocol.

13. A method as recited in claim 7, wherein the step of determining the home service provider address includes querying a home service provider directory server for the home service provider address of the subscriber.

14. A method as recited in claim 13, wherein the step of querying includes processing requests containing the user identifier, mapping the user identifier into a home service provider address, and responding to the query with the home service provider address.

15. A system for introducing new features into a network, comprising the steps of:

means for associating a user identifier with a subscriber;

means for providing a service dependent call model; and

in response to receiving the user identifier, means for accessing service logic associated with the service dependent call model that has been customized for the subscriber.

16., A system for introducing services customized for a particular subscriber into a network, comprising the steps of:

means for associating a user identifier with a subscriber;

means for providing a service dependent call model;

means for determining a home service provider address of the subscriber; and

in response to receiving the home service provider address, means for accessing service logic associated with the service dependent call model that has been customized for the subscriber from a node within the network.