WO2001050725A1

WO2001050725A1 - System and method for providing value-added services (vas) in an integrated telecommunications network using a downloadable plug-in module

Info

Publication number: WO2001050725A1
Application number: PCT/SE2000/002582
Authority: WO
Inventors: Christophe Gourraud
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2000-01-06
Filing date: 2000-12-19
Publication date: 2001-07-12
Also published as: AU2718601A; AR026788A1; EP1245108A1

Abstract

A system and method of providing on-demand Value-Added Services (VAS) in an integrated telecommunications network including an IP-based PSN portion. A downloadable VAS plug-in module (302) is provides for use with an IP terminal disposed in the network. The interface functionality of the VAS plug-in module conforms to an IP Telephony API (106) such that the module is configured to operate as an IP telephony client application towards an IP telephony protocol stack (102) on the terminal. The VAS plug-in module is also configured to operate as the IP telephony protocol stack with respect to the IP telephony client (104). The functionality of the VAS plug-in includes intelligence for local decision processing, including decision making and decision enforcement, so that when a service request (502) is received (504) in the VAS plug-in, an appropriate service-related decision is effectuated without having to engage the IP telephony client or the IP network. Locally available decision capability (508, 518) includes capability for accessing a local service, a remote service via a remote service node, a Mobile Agent service, et cetera. If the service request is not to be acted upon locally, the VAS plug-in passes (512, 522) the request to an appropriate node in the IP network if the request is generated by the IP telephony client, or to the IP telephony client if the request emanates from the IP network.

Description

SYSTEM AND METHOD FOR PROVIDING VALUE-ADDED SERVICES (VAS) IN AN INTEGRATED TELECOMMUNICATIONS NETWORK USING A DOWNLOADABLE PLUG-IN MODULE

REFERENCE TO RELATED PATENT APPLICATIONS

The present patent application incorporates by reference the subject matter disclosed in the following co-assigned patent application: "System and Method for Providing Nccess to Service Nodes from Entities Disposed in an Integrated

Telecommunications Network," filed 12/27/1999, Ser. No.:09/472,410 (Attorney

Docket No.: 1000-0143), in the names of Roch Glitho and Christophe Gourraud.

BACKGROUND OF THE INVENTION Technical Field of the Invention

The present invention relates to integrated telecommunication systems and, more particularly, to a system and method for providing Value-Added Services in an integrated telecommunications network via a plug-in module that is downloadable to a user terminal from a third party service provider. The exemplary integrated telecommunications network may comprise a packet-switched network (PSN) portion coupled to a circuit- switched network (CSN) portion. Also, the network may comprise a PSN portion only. For example, a network portion using the Internet Protocol (IP) may comprise such a PSN portion. Furthermore, for instance, the CSN portion may comprise a wireless telephony network portion having a service architecture that is derived from, or based upon, the Intelligent Network (IN) service architecture.

Description of Related Art

Coupled with the phenomenal growth in popularity of the Internet, there has been a tremendous interest in using packet-switched network (PSN) infrastructures (e.g., those based on IP addressing) as a replacement for, or as an adjunct to, the existing circuit-switched network (CSN) infrastructures used in today's telephony. From the network operators' perspective, the inherent traffic aggregation in packet- switched infrastructures allows for a reduction in the cost of transmission and the infrastructure cost per end-user. Ultimately, such cost reductions enable the network operators to pass on the concomitant cost savings to the end-users. Some of the market drivers that impel the existing Voice-over-IP (VoIP) technology are: improvements in the quality of IP telephony; the Internet phenomenon; emergence of standards; cost-effective price-points for advanced services via media-rich call management, et cetera. Some of the emerging standards in this area are the well known H.323 protocol, developed by the International Telecommunications Union (ITU), Session Initiation Protocol (SIP) or Internet

Protocol Device Control (IPDC) by the Internet Engineering Task Force (IETF), or Simple/Media Gateway Control Protocol (SGCP or MGCP). Using these IP standards, devices such as personal computers can interoperate seamlessly in a vast inter-network, sharing a mixture of audio, video, and data across all forms of packet- based networks which may interface with circuit-switched network portions.

To effectuate IP telephony over a PSN, an IP telephony client application is typically provided with the entity (e.g., a computer or an IP-based phone) that is used for accessing, or interacting with, the network. In addition, a suitable Telephony Application Programming Interface (Telephony API) is included so that the functionality of the underlying signaling protocol or protocol stack used for the PSN is abstracted from the standpoint of the IP client software.

IP telephony clients, thus, are typically implemented on top of the Telephony APIs and provide relevant graphic and/or audio interfacing to a user. Additionally, as is well known, certain user services may also be provided in some conventional IP telephony client applications. However, the provisioning of these services in conventional arrangements is beset with several drawbacks and shortcomings. First, services provided in such implementations are typically limited and do not possess advanced features that are highly advantageous to the users. Also, these services are rather static in nature in the sense that users are not provided with the capability to modify, alter, delete, add, or enhance the services on an "as needed" basis. Moreover, where IP client-based services are provided, such services are typically incompatible with, or are not upgradable to, advanced services (e.g., Value-Ndded Services or VNS) and features available from third party service providers within the context of the IP telephony. In addition, in the approach set forth above, providing the same VNS from different (and/or several) terminals for an end-user is rendered rather difficult. Furthermore, the functionality of the conventional IP telephony clients does not allow the provisioning of VNS using the well known Intelligent Network (IN) service architecture. Those skilled in the art should readily realize that there exist tremendous incentives, economic as well as infrastructure-based, for utilizing the existing IN or IN-based service architecture with respect to the provisioning of VAS within the IP telephony framework.

Based upon the foregoing, it should be apparent that there is a need for enhancing the functionality of the IP telephony client implementations so that intelligent processing capability may be included in the IP terminal for the provisioning of VAS, e.g., advanced services accessed from remote application servers. In addition, it would be advantageous to incorporate functionality which leverages the existing IN or IN-based service architecture. It would be of further advantage to provide the capability for modifying and enhancing services and/or features on-demand, independent of the IP network protocols, IP telephony client architectures, etc. The present invention provides such a solution.

SUMMARY OF THE INVENTION

Accordingly, the present invention is directed to a system and method of providing on-demand Value-Ndded Services (VAS) in an integrated telecommunications network using a plug-in module approach. An Internet Protocol (IP)-based terminal places and receives calls via a packet-switched network (PSΝ) portion of the integrated telecommunications network. An IP telephony client application is available on the IP -based terminal for interacting with an IP protocol stack operable with the PSΝ portion. A downloadable VAS plug-in module is disposed between the IP telephony client and the IP protocol stack for intelligently filtering service requests received therein. Accordingly, the plug-in module is configured to operate as the IP telephony client towards the IP protocol stack and as the IP protocol stack towards the IP telephony client, wherein the plug-in module's functionality includes local decision capability for determining whether a service request received therein is to be acted upon locally without having to engage the IP network or the IP telephony client. In an exemplary embodiment, the local decision capability of the VAS plug-in module includes accessing a local service associated with the terminal. In another embodiment, a remote service, e.g., a service logic portion executed at a remote Application Server node. In further exemplary embodiments, well-known IN Service Control Points (SCPs) or other IN-compliant Application Servers may be provided as remote service nodes which may be accessed depending upon the service request. In yet another embodiment, a Mobile Agent service is accessed by the VAS plug-in module.

BRIEF DESCRIPTION OF THE DRAWINGS A more complete understanding of the present invention may be had by reference to the following Detailed Description when taken in conjunction with the accompanying drawings wherein:

FIG. 1 (Prior Art) depicts a conventional IP telephony client arrangement operable with an IP telephony protocol stack used in a PSN-based telecommunications network;

FIG. 2 (Prior Art) depicts the functional components provided in a conventional IP telephony client;

FIG. 3 depicts a functional block diagram of a VAS plug-in module of the present invention usable with IP telephony clients disposed in an integrated telecommunications network that supports remote services;

FIG. 4 is a flow chart illustrating the steps of a method of service provisioning using a VAS plug- in module which operates as an Intelligent Filter in accordance with the teachings of the present invention; and

FIGS. 5A and 5B are flow charts illustrating the steps of a local decision method utilizing a VAS plug-in module provided in accordance with the teachings of the present invention. DET AILED DESCRIPTION OF EMBODIMENTS

In the drawings, like or similar elements are designated with identical reference numerals throughout the several views, and the various elements depicted are not necessarily drawn to scale. Referring now to FIG. 1 , depicted therein is a conventional IP telephony client arrangement 100 employed in a PSN-based telecommunications network that operates based on known VoIP protocols. An IP telephony client 104 is provided as a software structure that imparts telephony capabilities to IP-addressable entities such as, e.g., computers. Similar telephony client software may also be used in conjunction with devices such as Smart phones, Internet phones, Information Appliances, etc. (collectively referred to as "terminals") employed for accessing the

PSN-based telecommunications network. In the context of a SIP-based network, an IP telephony client is usually referred to as a User Agent Client (UAC) server.

An IP telephony protocol stack 102 is available within an IP-based terminal (not shown) for effectuating appropriate signaling etc. in accordance with the VoIP protocol employed in the network (e.g., H.323, SIP, and the like). An IP telephony signaling Application Programming Interface (API) 106 is conventionally provided between the IP telephony client 104 and the IP telephony protocol stack 102 for abstracting the functionality of the underlying IP signaling protocol on behalf of the IP client. Several such APIs exist in either standard or proprietary forms. For example, Java Telephony API (JTAPI), which is part of the 3GPP-defined Mobile

Execution Environment (MExE), is emerging as a standard Telephony API. Another standard is the TAPI standard from Microsoft®. Typically, such APIs are written in the C++, Java, or Interface Description Language (IDL).

The IP telephony API 106 is usually comprised of two parts: a first part 108A associated with the IP telephony client application 104 that is used by the IP telephony protocol stack 102 and a second part 108B associated with the IP protocol stack 102 that is used by the IP telephony client application 104. Various software objects in these components interact with one another in a defined manner to provide the interfacing capability between the IP client 104 and the protocol stack 102. In conventional IP telephony client arrangements, the client applications are implemented on top of the TAPIs and generally comprise call control functionality, call management functionality, and basic call services functionality, in addition to the interfacing functionality with respect to the Telephony NPI. The functional aspect of an exemplary IP telephony client application such as the IP client 104 described above is illustrated in FIG. 2. A Call Control (CC) module 202, a Call Management (CM) module and a Call Services (CS) module 206 are interfaced with one another so as to facilitate telephony capabilities within the terminal.

Typically, the functionality of the CS module 206 included for the provisioning of services tends to be rather limited. Even where a set of more advanced services is included, the services associated with the CS module are "fixed" in the sense that they are hardly upgradable to, or compatible with, other advanced services provided by third party service providers within the IP telephony context. Further, the CS functionality of the exemplary IP telephony client application 104 does not lend itself to accessing the existing remote services (e.g., IN or IN-based services), thereby thwarting the advantageous use of several market- tested and market-accepted service logic portions residing in such remote service nodes, e.g., SCPs.

Referring to FIG. 3, depicted therein is a functional block diagram of a VAS plug-in module 302 usable in accordance with the teachings of the present invention for enhancing the functionality of an IP telephony client, e.g., telephony client 104, disposed in an integrated telecommunications network that supports a remote Application Server architecture (e.g., an IN or IN-based service architecture).

Preferably, the VAS plug-in module 302 is provided as a downloadable module that an end-user can retrieve from a selected service provider via an IP-based network (e.g., the Internet) by employing known mechanisms such as File Transfer Protocol (FTP), HyperText Transfer Protocol (HTTP), and the like. Furthermore, retrieval of the downloadable modules may involve some subscription and authentication procedures from the end-user and, accordingly, the downloaded module may therefore include appropriate user-specific information and additional components necessary for the subsequent provisioning of the services to which the end-user has a subscription.

In the IP client arrangement 300 shown herein, the VAS plug-in module 302 is disposed between the IP telephony client 104 and the underlying IP protocol stack

102, and its functionality includes intelligent modification and filtering of the normal processing of calls effectuated via the functional modules of the IP telephony client application 104. Accordingly, suitable interfaces are provided between the VNS plug- in module 302 and the IP telephony client application 104 (interface 304B and interface 306B). In addition, interfaces 304A and 306N are provided between the VAS plug-in module 302 and the IP telephony protocol stack 102.

In accordance with the teachings of the present invention, the interfacing between the VNS plug-in module 302 and the IP telephony client application 104 is provided as a known Telephony NPI, e.g., TAPI 106. Similarly, the interfacing between the VAS plug-in module 302 and the IP telephony protocol stack 102 is also provided as Telephony API 106. Those skilled in the art should readily recognize that by conforming to the functionality of the IP Telephony API and modifying relevant configuration data, the VAS plug-in 302 is operates as an "IP protocol stack" towards the IP telephony client application 104. Analogously, the VNS plug-in 302 is operates as an "IP telephony client application" towards the IP protocol stack 102. The intelligent functionality of the VNS plug-in module preferably provides appropriate processing capabilities on the IP terminal with respect to decision making, decision enforcement, or both, in connection with call setup, call control and service access/provisioning for the user. Accordingly, the VAS plug-in module 302 is able to process the user's decisions before they are actually transmitted to the VoIP network. On the other hand, it is aware of network-originating events before they are made available to the user. Additionally, it is able to interact with the IP telephony client, directly with the end-user via a graphic user interface 322 if needed, as well as generate appropriate signaling to the network.

In an exemplary scenario, an IP terminal having the VAS plug-in module of the present invention receives an incoming call while the user is away or otherwise not available. The intelligent functionality of the VAS plug-in module is aware of the user's unavailability and, accordingly, makes and implements a decision to forward the call to a C-number without having to interact with the IP telephony client application or the user. Those skilled in the art should appreciate that various types of VAS plug-in modules may be provided within the scope of the present invention depending upon the nature of services involved. Some services may reside on the IP terminal itself, which may have been bundled with the specific VNS plug-in shipped to the user. Alternatively, the services may have been created by the user or retrieved from a remote server by a suitable VNS Ndministration Tool 308 operable with the IP terminal. The VNS Ndministration Tool 308 may also be used for configuring the services downloaded from the remote server, e.g., a service provider's Web page. These services are thus locally available, i.e., executable within the IP terminal using the enhanced processing capabilities of the VNS plug-in, and may conveniently be referred to as Local Services 312. Further, some of the services may reside in a remote location such as IΝ-based SCP that is accessible from the IP terminal via a suitable IP interface. In addition, the VNS plug-in module may include functionality to provide services which may be available via Application Servers. Such services are collectively depicted in FIG. 3 as Remote Services 314. Although not shown herein, those skilled in the art should recognize that services may also be available as Mobile Agents that interact with the VAS plug-in module of the present invention.

N service management module 310 is provided in a functional relationship with the VAS plug-in module 302 for effectuating service creation, subscription, removal, etc., preferably in a dynamic manner, with respect to the services described hereinabove. FIG. 4 depicts a flow chart that describes the various steps involved in a service provisioning process using the VAS plug-in module in accordance with the teachings of the present invention. A suitable VAS plug-in module that conforms to the IP Telephony API available on a terminal (step 402) is provided, for example, by bundling it with the IP terminal purchased from the equipment provider etc. or by downloading the requisite software from a service provider's Web location. The VAS plug-in software is configured as an IP telephony protocol stack with respect to an IP telephony client application on the terminal (step 404). Also, the functionality of the VNS plug-in module is configured such that it operates as the IP telephony client application towards the IP protocol stack (step 406). Thereafter, the intelligent functionality of the VNS plug-in module operates as an enhanced message filter

(Intelligent Filter) with respect to user services (step 408). Referring to FIGS. 5A and 5B, shown therein are flow charts that embodies the intelligent filtering functionality of the VAS plug-in module in an exemplary implementation. The flow chart depicted in FIG. 5A relates to the scenario where a service request is generated by the IP telephony client application (step 502) which is received in the VAS plug-in operating as an "IP telephony protocol stack" (step 504).

Using the built-in intelligence (which may be provided as, for example, suitably modified terminating or originating Call Control State Models having service- architecture-specific Detection Points (DPs) that may be armed based on triggers available from a user data profile as described in the incorporated reference set forth at the beginning of the present patent application), a determination is made whether a Local Service needs to be invoked (decision block 506). If so, an appropriate service logic portion locally available is executed subsequently (step 508). If a remote service is to be invoked, e.g., through an IN SCP node or a remote Application Server (decision block 512), the service request is passed to the remote location for executing suitable service logic thereat (step 514). On the other hand, if the VAS plug-in determines that the service request needs to be transmitted to an appropriate node in the IP network such as a Service Switching Point, e.g., an H.323 gatekeeper, a SIP redirect/proxy server, et cetera, the service request is provided to the IP protocol stack whereby the VAS plug-in module operates as the IP telephony client application. Accordingly, it should be readily recognized that the decision making and decision implementation/enforcement aspects of the VAS plug-in functionality, as embodied by decision blocks 506 and 512, and steps 508 and 514, respectively, are locally available and locally acted upon because of the intelligence provided as part of the plug-in module's functionality. These service-related decision aspects and the software/firmware structures for implementing them may therefore be collectively referred to as "local decision capability" or "local decision capabilities".

It should be apparent to those skilled in the art that the intelligent filtering capabilities of the VAS plug-in functionality described hereinabove are also appropriately involved with respect to requests/events emanating from the network towards the IP telephony client application on the terminal.

FIG. 5B depicts a flow chart illustrating the steps of a local decision method involving a network-related event generated by the protocol stack (step 512). Those skilled in the art should readily realize that the local decision process is essentially the same as the process described hereinabove, except that the VNS plug-in receives the network event (step 514) as an "IP telephony client" and makes a disposition thereof based on the intelligence embodied as the local decision capability. Accordingly, under appropriate analysis, the network event may be passed to the IP telephony client (step 526) for suitable processing.

Based upon the foregoing, it should be readily appreciated that the present invention advantageously provides enhanced capabilities in an IP terminal with respect to the provisioning of VAS. The user can make his IP terminal/appliance more intelligent simply by downloading the present invention's software from any third party service provider, independent of the IP telephony clients and IP protocol stacks bundled with the IP terminal. Also, various advanced services such as, e.g., multimedia/video on demand, etc. may be provided independent of the IP telephony network infrastructure.

Moreover, by utilizing the teachings of the present invention, the IN service logic base that is already installed and market-tested may continue to be re-used even as VoIP network architectures come into existence. Those of ordinary skill in the art should realize that significant incentives exist for network operators to re-use the expensive legacy SCP nodes as they migrate towards integrating the cellular infrastructures with IP-based PSNs.

Further, it is believed that the operation and construction of the present invention will be apparent from the foregoing Detailed Description. While the method and system shown and described have been characterized as being preferred, it should be readily understood that various changes and modifications could be made therein without departing from the scope of the present invention as set forth in the following claims. For example, the provision of the following services may be advantageously effectuated by using the teachings of the present invention: call forwarding, telephone directory-assisted calls, call screening, and a variety of other services enabled by the convergence between telephony, information technology and the Internet. Further, although the present patent application exemplifies the teachings of the present invention in the context of a service triggered by an incoming call, services triggered by outgoing calls (i.e., the end-user initiates the call) may also be provisioned in accordance herewith. For instance, by analyzing the addressed telephone number (i.e., the B-number), the VNS plug-in module may intelligently assist the end-user with respect to contacting the called party. This assistance may involve accessing information related to the called party (e.g., agenda, call preferences, etc.) and successive call attempts at different locations, under the supervision of an invoked service and the end-user. Accordingly, it should be clearly understood that these and other modifications, extensions, substitutions, additions, etc. are contemplated to be within the ambit of the present invention whose scope is defined solely by the following claims.

Claims

WHAT IS CLAIMED IS :

1. An integrated telecommunications network that effectuates on-demand provisioning of Value-Ndded Services (VNS), comprising: an Internet Protocol (IP)-based terminal for placing and receiving calls via a packet-switched network (PSΝ) portion; an IP telephony client disposed in the IP -based terminal for interacting with an IP protocol stack operable with the PSΝ portion; and a VNS plug-in module configured to operate as the IP telephony client towards the IP protocol stack and as the IP protocol stack towards the IP telephony client, wherein the VNS plug-in module includes local decision means for determining whether a service request received therein is to be acted upon locally.

2. The integrated telecommunications network as set forth in claim 1, wherein the VNS plug-in module is downloaded from a World Wide Web (WWW) location of a service provider.

3. The integrated telecommunications network as set forth in claim 2, further including a remote service node having a plurality of service logic portions associated with at least one of the Value-Ndded Services, wherein the local decision means of the VAS plug-in module includes means for accessing the remote service node based on the service request.

4. The integrated telecommunications network as set forth in claim 3, wherein the remote service node comprises an Intelligent Network (IN)-compliant

Service Control Point.

5. The integrated telecommunications network as set forth in claim 3, wherein the remote service node comprises an Intelligent Network (IN)-compliant Application Server.

6. The integrated telecommunications network as set forth in claim 2, wherein the local decision means of the VAS plug-in module includes means for accessing a local service based on the service request.

7. The integrated telecommunications network as set forth in claim 2, wherein the local decision means of the VAS plug-in module includes means for accessing a Mobile Agent service based on the service request.

8. The integrated telecommunications network as set forth in claim 2, wherein the service request is generated by the IP telephony client towards the PSN portion.

9. The integrated telecommunications network as set forth in claim 2, wherein the service request is generated from the PSN portion towards the IP telephony client.

10. The integrated telecommunications network as set forth in claim 2, wherein the PSN portion comprises an H.323-based network.

11. The integrated telecommunications network as set forth in claim 2, wherein the PSN portion comprises a Session Initiation Protocol (SΙP)-based network.

12. A method of on-demand provisioning of Value- Added Services (VAS) in an integrated telecommunications network having a packet-switched network (PSN) portion, the method comprising the steps of: downloading a VAS plug-in module from a World Wide Web (WWW) location of a service provider; configuring the VAS plug-in module to operate as an IP telephony client towards an IP protocol stack available on a terminal, the IP protocol stack being operable with the PSN portion; configuring the VAS plug-in module to operate as the IP protocol stack towards the IP telephony client; receiving a service request in the VAS plug-in module; and determining in the VAS plug-in module whether the service request is to be acted upon locally.

13. The method of on-demand provisioning as set forth in claim 12, wherein the service request is associated with a local service and the method further comprises executing a service logic portion associated with the local service.

14. The method of on-demand provisioning as set forth in claim 12, wherein the service request is associated with a remote service and the method further comprises accessing a remote service node associated with the remote service.

15. The method of on-demand provisioning as set forth in claim 14, wherein the step of accessing a remote service node includes accessing an Intelligent

Network (IN)-based Service Control Point.

16. The method of on-demand provisioning as set forth in claim 14, wherein the step of accessing a remote service node includes accessing an IN- complaint Application Server.

17. The method of on-demand provisioning as set forth in claim 12, wherein the step of receiving a service request includes receiving a service request that is generated from the PSN portion towards the IP telephony client.

18. The method of on-demand provisioning as set forth in claim 12, wherein the step of receiving a service request includes receiving a service request that is generated by the IP telephony client towards the PSN portion.