WO2007073777A1

WO2007073777A1 - Method of managing services in a communication network

Info

Publication number: WO2007073777A1
Application number: PCT/EP2005/057178
Authority: WO
Inventors: Alberto Baravaglio; Laurent Walter Goix; Massimo Valla
Original assignee: Telecom Italia S.P.A.
Priority date: 2005-12-27
Filing date: 2005-12-27
Publication date: 2007-07-05

Abstract

It is disclosed a method of managing a service addressed to a user of a communication network. The user is provided with a terminal. The method comprises: requesting to access the service by means of the terminal; downloading at the terminal a first descriptor (FD) which describes at least one event (E) occurring at the terminal and at least a consequent action (A) following the at least one event (E), the at least one consequent action (A) comprising downloading a second descriptor (UID, SCD), triggering the at least one event (E); executing the at least one consequent action (A). The second descriptor comprises at least an instruction for generating and rendering a user interface to the user, or it comprises at least an instruction for interacting with the communication network.

Description

"METHOD OF MANAGING SERVICES IN A COMMUNICATION

NETWORK"

Technical field The present invention generally relates to the field of communication networks. More particularly, the present invention relates to a method of managing services addressed to users of a communication network and to a terminal adapted to implement such a method. Background art A communication network is a network for providing a plurality of users with a number of services. For instance, a communication network may be a telephone network, either fixed or mobile, which provides its users with voice services such as calls, conference calls, automatic answering, or the like. On the other hand, a communication network may be a data network which provides its users with data services such as E-mail, e-commerce, or the like. Each user is connected to the communication network through a respective terminal, allowing him to access services.

In a communication network, a service is typically based on a client- server mechanism, wherein the server role is played by network apparatuses which are termed "application servers", whilst the client role is played by the terminals. For providing a given service, an application server typically executes a server-side service application which is specific for that service. Similarly, for accessing the service, a terminal typically executes a client-side service application which is adapted to interact with the server-side service application specific for that service.

A service may typically require, on one hand, a number of terminal- network interactions (i.e. an interaction between a terminal and an application server or any other remote network apparatus involved into the service, including other terminals), and, on the other hand, a number of terminal-user interactions.

At the terminal side, terminal-network interactions may comprise generating and transmitting request messages to the network for requesting information and receiving response messages from the network providing the requested information, or performing actions such as activating audio-video communications or playing audio-video streams, or listening for incoming request messages. Such request and response messages are formatted and transmitted according to a protocol which depends on the network type and the terminal type. For instance, in case of a GSM mobile telephone network, request and response messages may be SMS (Short Message Service) messages, as well as USSD (Unstructured Supplementary Services Data) messages, or the like. In case of a fixed IP telephone network, request and response messages may be based, for instance, on SIP (Session Initiation Protocol).

At the terminal side, terminal-user interactions generally comprise generating and rendering user interfaces to the user. Such user interfaces may allow the terminal to provide the user with information received from the network; on the other hand, such user interfaces may allow the terminal to receive information from the user. Different types of user interfaces are possible, depending on the terminal type. For instance, on mobile telephones with a display, examples of user interfaces are HTML (HyperText Markup Language) interfaces, SVG (Scalable Vector Graphics) interfaces, VoiceXML (Voice Extensible Markup Language) interfaces, or the like.

Methods of managing services addressed to users in a communication network are known in the art. Such methods basically depend on the type of communication network. For instance, in a mobile telephone network, when a user requests to access a given service, the whole client-side service application of such a given service is downloaded at the user terminal, which then executes it. Therefore, the whole client-side service application is statically stored in a memory of the terminal. In the art, other solutions are known, for instance document US 2004/0240408 describes a method for the development and deployment of applications suitable for mobile devices. The applications are dynamically generated by an application engine utilizing unique control information stored in a mobile application descriptor. The mobile application descriptor comprises information indicative of the client's user interface, application database structures, and application logic instructions. The application engine in the mobile device receives the mobile application descriptor from a server device and in accordance with the information embedded therein dynamically generates a set of dynamic mobile application base components. These base components include application database structure definitions, user interface definition, application logic modules and the like. The application engine further provides the option for the user to submit requests for application data, to obtain the desired application data, and to insert the received application data into an application database built in accordance with the application database structure definitions in the mobile application descriptor.

Object and summary of the invention

The Applicant has observed that, up to now, the solutions proposed in the art are not completely satisfactory.

For example, with reference to those solutions which provide for downloading the whole client-side application, the Applicant has observed that, first of all, for each new service, development of a whole new client-side service application is required. Moreover, as the service implementation depends on the network type and terminal type, different versions of a same client-side service application must be developed for each service, each version being suitable for a certain type of network and terminal. Moreover, when a user requests to access a service, the whole client-side service application is downloaded on his terminal, even though only a part of it will be actually employed. This disadvantageously implies a high memory use at the terminal and bandwidth consumption.

The Applicant has tackled the problem of how to provide users with a wide range of communication services which can be downloaded to the user terminal in a flexible way, minimizing the amount of downloaded data and the terminal-network interactions.

It is therefore an object of the present invention to provide a method of managing services addressed to users in a communication network which overcomes the aforesaid problems. In particular, the main object of the present invention is providing a method of managing services addressed to users in a communication network which minimizes the amount of data to be downloaded and stored at a terminal for accessing a service.

Besides, another object of the present invention is providing a method of managing services addressed to users in a communication network which allows to develop client-side service applications which are terminal-independent.

A further object of the present invention is providing a method of managing services addressed to users in a communication network which allows to provide the users with a wider range of services in comparison to known methods, with a more flexible set of network- terminal and terminal-user interactions.

According to the invention, the client-side service application is divided into a plurality of descriptors, which are classified according to the task they are adapted to perform. A flow descriptor comprises a sequence of instructions so that a terminal, for each event occurring at the terminal during the service execution, is capable of taking a consequent action. A user interface descriptor comprises a sequence of instructions so that a terminal generates and renders a user interface. A service component descriptor comprises a sequence of instructions so that a terminal listens for specific requests coming from the network or generates and transmits a request message for requesting information to the network. The flow descriptor comprises links to user interface descriptors and/or to service component descriptors. The client-side service application is therefore modular.

According to a first aspect, the present invention provides a method of managing a service addressed to a user of a communication network. The user is provided with a terminal. The method comprises: requesting to access the service by means of the terminal; downloading at the terminal a first descriptor which describes at least one event occurring at the terminal and at least a consequent action following the at least one event, the at least one consequent action comprising downloading a second descriptor, triggering the at least one event; and executing the at least one consequent action. The second descriptor may comprise at least an instruction for generating and rendering a user interface to the user, or it may comprise at least an instruction for interacting with the communication network.

The user interface could be either a graphic interface or an acoustic interface or a graphic and acoustic interface. Interacting with the communication network may comprise transmitting a message to the communication network or listening for a message from the communication network or activating audio-video communications or activating audio-video streams.

The at least one event occurring at the terminal may include receiving information from the communication network or receiving information from the user.

The first descriptor may describe at least one further event occurring at the terminal and at least a further consequent action following the further event. The further consequent action comprises downloading at the terminal a further descriptor. The further descriptor may comprise at least an instruction for generating and rendering a further user interface to the user, or it may comprise at least an instruction for further interacting with the communication network.

Preferably, requesting to access the service is preceded by receiving and storing at the terminal information indicative of the availability of the service from the communication network. Alternatively, requesting to access the service is preceded by looking for information indicative of the availability of the service into the communication network by the terminal, and storing the information indicative of the availability of the service at the terminal.

The information indicative of the availability of the service may comprise at least a link to the first descriptor.

Profitably, the second and further descriptors are terminal independent. The first descriptor and the second and further descriptors may be stored in a cache memory at the terminal.

According to a second aspect, the present invention provides a terminal of a communication network which is adapted to provide a service to a user. The terminal comprises: a first module for downloading from the communication network a first descriptor and a second descriptor, the first descriptor describing at least one event occurring at the terminal and at least a consequent action following the at least one event, the at least one consequent action comprising downloading the second descriptor; a second module for executing the first descriptor; and a third module for executing the second descriptor. The third module, by executing the second descriptor, generates and renders a user interface to the user, or it interacts with the communication network.

The terminal may further comprise a fourth module for receiving information indicative of the availability of the service from the communication network and a memory device for storing the information.

The terminal may further comprise a fifth module for looking for information indicative of the availability of the service into the communication network and a memory device for storing the information.

Profitably, the first descriptor describes at least one further event occurring at the terminal and at least a further consequent action following the further event, the further consequent action comprising downloading at the terminal a further descriptor. The further descriptor may comprise at least an instruction for generating and rendering a further user interface to the user, or it may comprise at least an instruction for further interacting with the communication network.

According to a third aspect, the present invention provides a communication network which is adapted to provide a service to a users, each user being connected to the communication network by means of a respective terminal. The communication network comprises: at least one server for providing the service; at least one descriptor repository for storing at least a first and a second sequence of instructions relating to the service; and at least a terminal as set forth above.

The present invention will become more clear by reading the following description, given by way of example and not of limitation, to be read with the accompanying drawings, wherein: - Figure 1 is a flow chart which schematically shows development of a new service and notification of such a new service to the users of a communication network, according to an embodiment of the present invention;

- Figure 2 is a block diagram which schematically shows a client-side service application according to an embodiment of the present invention;

- Figure 3 is a block diagram of a client-side service application execution environment stored at a terminal according to an embodiment of the present invention; - Figure 4 schematically shows a notification of a new service according to an embodiment of the present invention;

- Figure 5 schematically shows a request of accessing a service by a user according to an embodiment of the present invention;

- Figure 6 schematically shows downloading and executing a user interface descriptor according to an embodiment of the present invention;

- Figure 7 schematically shows downloading and executing a service component descriptor according to an embodiment of the present invention; and - Figure 8 schematically shows different steps of a method of managing an exemplifying service according to an embodiment of the present invention.

Detailed description of preferred embodiments of the invention Figure 1 is a flow chart which schematically shows development of a new service and notification of such a new service to the users of a communication network, according to an embodiment of the present invention.

A first step 1 comprises developing a server-side service application for the new service. Such a first step 1 is performed through a Service Creation Environment, which allows to develop the server-side service application either graphically or through a scripting language. Such a server-side service application comprises a sequence of events that may occur at an application server and, for each event, at least one consequent action to be taken by the application server. A server-side service application further describes syntax and format of messages that could be required to be sent by the application server to the terminal while providing the new service. Different methods are known in the art for implementing step 1 , which will not be described in further detail. Then, a second step 2 comprises deploying the server-side service application developed at step 1 , i.e. distributing such a server-side service application to the application servers of the network. At the end of step 2, each application server which has received the server-side service application is able to provide the new service to any user requesting to access it. Different methods are known in the art for implementing step 2, which will not be described in further detail.

Then, a third step 3 comprises developing a client-side service application for the new service. Such a client-side service application must be consistent with the server-side service application developed in step 1. In other words, client-side service application and server-side service application must be capable of interacting the one with the other during service execution.

According to an embodiment of the present invention, as shown in Figure 1 , such a step 3 comprises three sub-steps: - sub-step 3a: development of a flow descriptor;

- sub-step 3b: development of a set of user interface descriptors; and

- sub-step 3c: development of a set of service component descriptors. In the following description and claims, the term "descriptor" will refer to a machine readable description of a sequence of instructions performing a given task, such a machine readable description being compliant with a specific grammar.

Therefore, according to the present invention, the client-side service application is divided into a plurality of descriptors.

According to the present invention, descriptors can be classified according to the type of task they are adapted to perform, as it will be described in detail herein after by referring to Figure 2.

A first type of descriptor, which will be termed "user interface descriptor" UID in the following description, comprises a sequence of instructions so that a terminal generates and renders a user interface. For instance, such a user interface may allow to provide the user with information received by the terminal from the network or with courtesy announcements. Besides, such a user interface may also allow a user to send information or requests of information to the network. Such a user interface may be either a graphic user interface (i.e. a panel or the like), an acoustic user interface (i.e. a voice announcement or the like) or a combination thereof. According to a preferred embodiment of the present invention, such UID descriptors are terminal-independent, i.e. they do not depend on the type of terminal. For instance, such UID descriptors may be developed through HTML or SVG, so that a single UID descriptor can represent an HTML page, or an SVG interface, or the like, by a renderer onboard the terminal. Moreover, UID descriptors can be independent of the type of user interface the terminal supports. For instance, such UID descriptors may be developed through XML and then processed by using XSL (Extensible Stylesheet Language), so that a single UID descriptor can be automatically translated to generate an HTML page, or an SVG interface, or a VoiceXML interface, or the like. XSL is only an example, and other mechanisms may be employed for translating such UID descriptors, such as any conversion language/library installed on the terminal. A second type of descriptor, which will be termed "service component descriptor" SCD in the following description, comprises a sequence of instructions so that a terminal listens for specific requests coming from the network or generates and transmits a request message for requesting information to the network. In particular, a SCD descriptor describes syntax and format of such a request message. According to a preferred embodiment of the present invention, such SCD descriptors are protocol-independent, i.e. they do not depend on the type of protocol supported by the terminal and the network for transmitting each other messages. For instance, the SCD descriptors may be developed through WSDL (Web Service Definition Language), so that a single SCD descriptor can be automatically translated to generate an HTTP message, or an SMS message, or a USSD message, according to the type of protocol supported by terminal and network. WDSL is only an example, and other programming languages may be employed for developing such SCD descriptors (such as XML).

A third type of descriptor, which will be termed "flow descriptor" FD in the following description, comprises a sequence of instructions so that a terminal, for each event E occurring at the terminal itself during the service execution, is capable of taking a consequent action A. In other words, the FD descriptor comprises the client-side service logic.

Examples of events E that may occur at the terminal are: reception of information from the network, reception of requests of information from the user, beginning of service, end of service or the like.

According to embodiments of the present invention, consequent actions A may be either the download and execution of a user interface descriptor UID (for instance, for providing a user with information received by the terminal from the network) or the download and execution of a service component descriptor SCD (for instance, for retrieving from the network information requested by the user). Preferably, for executing such consequent actions A, a flow descriptor FD comprises links to user interface descriptors UID and/or to service component descriptors SCD, as it will be shown in greater detail herein after.

According to a particular embodiment of the present invention, a client-side service application comprises a single flow descriptor FD.

On the other hand, according to an embodiment of the present invention, a client-side service application may comprise any number of user interface descriptors UID, wherein each UID descriptor corresponds to a respective user interface that could be required during service execution. For particular services, wherein no terminal-user interaction is required, the client-side service application may comprise no UID descriptors. For instance, for some services (e.g. a call forwarding service) no user interface is required. In other cases, a graphic user interface may be automatically generated from the SCD descriptor, without requiring any UID descriptor.

Similarly, according to an embodiment of the present invention, a client-side service application may comprise any number of service component descriptors SCD, wherein each SCD descriptor corresponds to a respective request message that could be required during service execution. For particular services, wherein no terminal-network interaction is required (e.g. games which can be played on the terminal), the client-side service application may comprise no SCD descriptors.

Therefore, according to embodiments of the present invention, the client-side service application is divided in a plurality of descriptors, or, in other words, the client-side service application is modular. This modularity implies a number of advantages from the point of view of a client-side service application development.

First of all, a same descriptor (for instance a user interface descriptor), once developed for a certain service, may be used also to implement other services which may require, during their execution, a similar user interface. Therefore, when developing a new service, descriptors of already existing services may be reused, so that, in some cases, only few descriptors (or, in the best case, no descriptor) must be developed for a new service.

Moreover, advantageously, if a user interface (or a service component) is required more than once during the execution of a service, developing the client-side service application simply requires to insert a link to the descriptor of such a user interface (or service component) in appropriate points of the flow descriptor.

Moreover, advantageously, modularity facilitates developing network- independent and terminal-independent client-side service applications. Indeed, according to the present invention, the flow descriptor comprises a sequence of instructions which are written in a particular language and which are intrinsically independent both of the techniques supporting user interfaces at the terminal, and of the protocols supporting messages transmission from or to the terminal.

Moreover, according to preferred embodiments of the invention, user interface descriptors may be developed so that they are independent of the techniques supporting user interfaces at the terminal.

Moreover, in case a change in a part of the service is required, modularity advantageously allows to modify only descriptors relative to the part of service to be changed, thus leaving the remaining descriptors unchanged. Finally, modularity advantageously allows to have different specialized designers, each designer being responsible of developing a single type of descriptor.

By still referring to Figure 1 , a latter step 4 comprises notifying the availability of the new service to the terminals of the communication network. This step of notifying may be performed either by means of a "push" operation (notification actively transmitted to the terminals by a notification system) or by means of a "pull" operation (notification actively searched by the terminals at the notification system), as it will be described herein after in further detail by referring to Figure 4. Preferably, according to embodiments of the present invention, a terminal T, for accessing the services offered by the communication network, is equipped with a client-side service application execution environment SAEE, which may be stored in a memory of the terminal T. Such a client-side service application execution environment SAEE is adapted to download and execute the descriptors FD, SCD, UID, thus performing the instructions comprised into such descriptors FD, SCD, UID, as it will be described in further detail herein after.

Figure 3 shows a block diagram of a client-side service application execution environment SAEE stored at a terminal T according to an embodiment of the present invention.

The terminal T, according to embodiments of the present invention, may comprise a fixed telephone, a mobile telephone, a smart phone, a PDA (Personal Digital Assistant), a STB (Set Top Box), a computer or the like. The network, according to embodiments of the present invention, may comprise any type of telephone network (PSTN, PLMN, GSM, UMTS, IP telephone network, etc.) and/or any type of data network (IP network, etc.).

In the following, the single modules of the client-side service application execution environment SAEE will be detailed, starting from a service logic control module SLC:

- service logic control SLC: it executes the flow descriptor FD; i.e., it determines which event E has occurred at the terminal T according to information received from other modules of the SAEE, it determines which consequent action(s) A has to be taken, it commands consequently the other modules of the SAEE, and it also exchange information related to these events and actions between these modules;

- user interface engine Ul-E: it interprets the interface descriptors UID according to the types of user interface supported by the terminal T, it executes such UID descriptors and, according to instructions comprised in such UID descriptors, it commands a user interface renderer Ul-R, as it will be seen herein after;

- operation invoker Ol: it interprets the service component descriptors SCD according to the types of protocol supported by the terminal T, it executes such SCD descriptors and, according to instructions comprised in such SCD descriptors, it commands a resource adaptor RA, as it will be seen herein after; the operation invoker module Ol and the user interface engine module Ul-E could be associated into a single device; optionally, they can be both associated in a single device together with the service logic control SLC;

- downloader D: it downloads the required FD, UID and SCD descriptors from a descriptor repository DR, as it will be seen herein after;

- cache memory C: it stores the downloaded FD, UID and SCD descriptors;

- user interface renderer Ul-R: it generates and renders an appropriate user interface, according to commands received from the user interface engine Ul-E (for instance, the user interface renderer Ul-R of Figure 3 comprises an HTML browser, a SVG browser and a VoiceXML browser; of course, alternatives are possible); the user interface renderer Ul-R is further adapted to receive information from the user through the user interface, and to forward it to the user interface engine Ul-E; the user interface renderer Ul-R may be a set of renderer modules, each of them handling one or more user interface technologies and optionally residing on the terminal T; - resource adaptor RA: it generates and transmits an appropriate request message, according to commands received from the operation invoker Ol (for instance, the resource adaptor RA of Figure 3 supports the HTTP protocol for communicating with an IP network, the SIP protocol for communicating with an IP telephone network IP- T and the SMS service for communicating with a PLMN network; of course, alternatives are possible); the resource adaptor RA is further adapted to receive information from the network by means of either request or response messages, and to forward it to the operation invoker Ol ; the resource adaptor RA may be optionally resident on the terminal T;

- notification listener NL: it is adapted to receive notification information relating to the availability of new services. The notification listener NL may be adapted either to passively receive such notification information from a remote notification system NS (the above cited "push" mechanism) or to actively look for possible notification information at the remote notification system NS (the above cited "pull" mechanism). The content of such notification information will be described in further detail herein after. Such notification information may be formatted and transmitted according to different protocols (for instance, SIP, HTTP, SOAP, or the like);

- local notification information repository LNI: it is a data base wherein notification information relating to available services are stored. The SLC may use the information stored in such local notification information repository LNI for providing the user with a list of available services.

It is remarked that, according to embodiments of the present invention which are not shown in the drawings, the client-side service application execution environment SAEE of a terminal T may also comprise only a few of the above described modules. Optionally, some of the above described modules (for instance, the Ul-R) may reside at the terminal T. For instance, if a terminal T is allowed to perform only services with no terminal-user interaction, the user interface engine Ul- E and the user interface renderer Ul-R may be absent from the environment SAEE of such a terminal T. Similarly, for instance, if a terminal T is allowed to perform only services with no terminal-network interaction, the operation invoker Ol and the resource adaptor RA may be absent from the environment SAEE of such a terminal T.

By referring now to Figures 4, 5 and 6, the operation of the client-side service application execution environment SAEE according to an embodiment of the present invention will be now described in further detail.

In particular, Figure 4 schematically shows a notification of a new service according to an embodiment of the present invention. As already mentioned by referring to Figure 1 , after developing the client-side service application relating to a new service, the availability of such a new service is notified to the terminals, so that a user (upon an appropriate authorization, if needed, or upon an appropriate subscription, if needed) can request to access it. Notification is performed by a notification system NS. For performing notification to a terminal T, the notification system NS sends notification information to the notification listener NL of the terminal T (step 40). Preferably, such notification information is sent by means of an asynchronous notification message. According to a preferred embodiment of the present invention, such notification information may comprise an XML descriptor, which in turn comprises information relating to the new service. For instance, such notification information may comprise one or more of the following: - service name; - text description of the service; and - link to the flow descriptor FD of the service.

Such notification information is stored into the local notification information repository LNI (step 41 ). Optionally, according to embodiments of the present invention which are not shown in the drawings, such notification information (in particular the service name and the service text description) may be provided to the user by means of a user interface (for instance, but not exclusively, a graphic user interface).

Notification according to the present invention has some advantages. Indeed, advantageously, notification simply requires to download and store at the terminal T the notification information, which has a small size, thus occupying a very small memory portion at the terminal T.

After notification, an authorized/subscribing user may request to access one of the available services, included the notified new service. Figure 5 schematically shows a request of accessing a service by a user according to an embodiment of the present invention.

A user U, wishing to access a service, performs an access request by means of his terminal T, for instance by pressing one or more keys of his terminal T, or by selecting the desired service from a list of available services visualized by a suitable graphic user interface. Alternatively, access to a given service can be automatically activated after notification. Such an access request is received by the SLC (step 50), which looks up the local notification information repository LNI and thus retrieves the link to the flow descriptor FD of the requested service (this step is not shown in Figure 5). The SLC asks the downloader D to download the flow descriptor FD of the requested service (step 51 ). The downloader D sends a download request to the descriptor repository DR (step 52). The flow descriptor FD is then downloaded at the terminal T and stored in the cache memory C (step 53). The service starts when the SLC starts executing the flow descriptor FD by triggering the initial event(s).

As already mentioned, according to a preferred embodiment of the present invention, the flow descriptor FD comprises, for each event E that may occur at the terminal T, at least a consequent action A. Such a consequent action A may comprise either generating and rendering a user interface by downloading and executing a user interface descriptor UID, or listening for an incoming request message from the communication network or generating and transmitting a request message to the network by downloading and executing a service component descriptor SCD.

Figures 6 and 7 schematically show downloading and executing a user interface descriptor and a service component descriptor, respectively, according to embodiments of the present invention.

For simplicity, in Figures 6 and 7, Ul-E and Ul-R are represented as a single module UI-R/UI-E, and Ol and RA are represented as a single module OI/RA.

In particular, Figure 6 shows a first step 60, wherein the SLC, upon triggering of an event, reads the flow descriptor FD from the cache memory C and executes it, thus determining that the consequent action comprises downloading and executing a given descriptor UID. The event may be for instance the reception of a response message from the network through the OI/RA. In this case, the user interface may be required for providing the user U with information comprised within such a response message. Alternatively, the user interface may be required for providing the user U with a courtesy announcement, such as, for instance, a request for waiting while the terminal T is retrieving from the network information requested by the user U.

In any case, the SLC commands the downloader D to download the user interface descriptor UID requested by the flow descriptor FD (step 61). The link to the requested descriptor UID is comprised within the descriptor FD. The downloader D checks whether the requested descriptor UID is already stored in the cache memory C (not shown in Figure 6); otherwise, it sends a download request to the descriptor repository DR (step 62). The descriptor UID is then downloaded at the terminal T and stored in the cache memory C (step 63).

The SLC then commands the UI-R/UI-E to execute the descriptor UID (step 64). The UI-R/UI-E reads the descriptor UID from the cache memory C and executes it (step 65), thus generating and rendering a user interface (step 66). Such a user interface, as already mentioned, may be either graphic or acoustic, and it may be HTML-based, SVG- based, VoiceXML-based, or the like. Then, if the user interface allows the user U to perform an action (for instance, to perform a selection from a list displayed by the user interface), the UI-R/UI-E waits until it receives user information from the user U (step 67), and it forwards such user information to the SLC (step 68). The SLC processes such user information for determining, by executing the corresponding event in the flow descriptor FD, which consequent actions have to be taken.

Similarly, Figure 7 shows a first step 70, wherein the SLC, upon triggering of an event, reads the flow descriptor FD from the cache memory C and executes it, thus determining that the consequent action comprises downloading and executing a given descriptor SCD. The event may be for instance the reception of information from the user through the UI-R/UI-E. In this case, for instance, it may be necessary to send a request message for requesting information to the network. In this case, the SLC commands the downloader D to download the service component descriptor SCD requested by the flow descriptor FD (step 71 ). The link to the requested descriptor SCD is comprised within the descriptor FD. The downloader D sends a download request to the descriptor repository DR (step 72). The descriptor SCD is then downloaded at the terminal T and stored in the cache memory C (step 73).

The SLC then commands the OI/RA to execute the descriptor SCD (step 74). The OI/RA reads the descriptor SCD from the cache memory C and executes it (step 75), thus generating and transmitting a request message to the network (step 76). Such a request message, as already mentioned, may be based on different protocols, such as, for instance, SMS, SIP, HTTP or the like. Then, the OI/RA waits until it receives a response message from the network (step 77), and it forwards such a response message to the SLC (step 78). The SLC processes such a response message for determining, by executing the flow descriptor FD, which consequent actions have to be taken. The SLC can either wait for the response from the OI/RA to finish processing the event or continue processing and further being notified through another event from the OI/RA. Therefore, according to the present invention, modularity of the client-side service application allows to have a number of advantages also from the point of view of accessing and executing a service.

In particular, according to the present invention, the amount of data to be downloaded and stored at a terminal T during the execution of a service is minimized, since, upon an access request by a user, only the flow descriptor is initially downloaded and stored. Then, during the execution of flow descriptor, the required user interface descriptors or service component descriptors are downloaded dynamically, as they are invoked by the flow descriptor, and can be either stored in the cache memory C or deleted after usage. In this way, unnecessary parts of the client-side service application are not needlessly downloaded at the terminal T, thus saving both bandwidth of the dedicated channels and memory at the terminal T.

According to the present invention, the client-side server application is divided into independent descriptors, which can be developed and executed independently the one from the other. Moreover, client applications of the known method are protocol-dependent, while, according to preferred embodiments of the present invention, the client- side server application modularity allows to develop each descriptor so that it is protocol-independent.

Figure 8 shows, by way of example and not of limitation, different steps of a method of managing an exemplary service according to an embodiment of the present invention. Such a service allows a user to find movies be showing in a given location. It is assumed, for instance, that such a service is provided in an IP telephone network IP-T, and it is assumed that the service is SIP-based. The exemplary name of the service is "MoviePlanner".

Figure 8 does not show the notification to terminals of the service MoviePlanner, which can be found in the description of Figure 4. Upon notification, each authorized user which has subscribed the MoviePlanner service has the name "MovePlanner" in his list of available services, preferably with a brief description of the service. Moreover, his terminal T is capable of associating the name MoviePlanner with the link to the flow descriptor FD of such a service. A user U wishing to access the MoviePlanner service performs an access request by means of his own terminal T, for instance by pressing one or more keys on his terminal T, or by selecting the MoviePlanner service from the list of available services visualized by a suitable graphic user interface. Such an access request is received by the SLC (step 800), which looks up the local notification information repository LNI and thus retrieves the link to the flow descriptor FD of the MoviePlanner service (this step is not shown in Figure 8). The SLC then asks the downloader D to download the flow descriptor FD of the MoviePlanner service (step 801 ). The downloader D sends a download request to the descriptor repository DR (step 802). The flow descriptor FD is then downloaded at the terminal T and stored in the cache memory C (step 803).

The SLC then reads the flow descriptor FD from the cache memory C, and starts executing it (step 804). The initial event described by the flow descriptor FD indicates the beginning of service execution, which corresponds a consequent action comprising displaying on the terminal display a welcome screenful asking the user U to choose a location wherein he wishes to see the movies be showing from a list of possible locations. For this purpose, the SLC commands the downloader D to download a first user interface descriptor UID, whose name is for instance "InitialUID" and whose link is comprised within the flow descriptor FD (step 805). The downloader D sends a download request to the descriptor repository DR (step 806). The descriptor "InitialUID" is then downloaded at the terminal T and stored in the cache memory C (step 807).

The SLC then commands the UI-R/UI-E to execute the descriptor "InitialUID" (step 808). The UI-R/UI-E reads the descriptor "InitialUID" from the cache memory C and executes it (step 809), thus generating and rendering the welcome screenful on the terminal display (step 810). The user U, through the welcome screenful, selects the desired location. This generates a "FindMovie" request, which is received by the UI-R/UI-E (step 811 ), which forwards it to the SLC (step 812).

Upon reception of such a "FindMovie" request, the SLC, by executing the flow descriptor FD of the MoviePlanner service (step 813), determines that the event of receiving a "FindMovie" request from the user U implies two consequent actions. A first consequent action comprises displaying a waiting screenful on the terminal display for asking the user U to wait until the desired information is retrieved. A second consequent action comprises transmitting a SIP message to the IP telephone network IP-T for requesting a list of movies be showing at the desired location chosen by the user U. More particularly even though not shown in the Figures, such a SIP message may be sent for instance either to an application server associated to the MoviePlanner service or to a remote database comprising information for supporting the MoviePlanner service.

Therefore, for performing the first consequent action, the SLC commands the downloader D to download a second user interface descriptor UID, whose name is for instance "PerformingFindMovieUID" and whose link is comprised within the flow descriptor FD (step 814). The downloader D sends a download request to the descriptor repository DR (step 815). The descriptor "PerformingFindMovieUID" is then downloaded at the terminal T and stored in the cache memory C (step 816). The SLC then commands the UI-R/UI-E to execute the descriptor "PerformingFindMovieUID" (step 817). The UI-R/UI-E reads the descriptor "PerformingFindMovieUID" from the cache memory C and executes it (step 818), thus generating and rendering the waiting screenful on the terminal display (step 819). For executing the second consequent action, the SLC commands the downloader D to download a first service component descriptor SCD whose name is for instance "MovieMateSIP" and whose link is comprised within the flow descriptor FD (step 820). The downloader D sends a download request to the descriptor repository DR (step 821 ). The descriptor "MovieMateSIP" is then downloaded at the terminal T and stored in the cache memory C (step 822).

The SLC then commands the OI/RA to execute the descriptor "MovieMateSIP" (step 823). The OI/RA reads the descriptor "MovieMateSIP" from the cache memory C and executes it (step 824), thus generating and transmitting a SIP message to the IP telephone network IP-T (step 825) and waiting for a response message.

At step 826, the OI/RA receives a SIP response message "FoundMovie" comprising a list of movies be showing at the desired location chosen by the user U, and then it forwards it to the SLC (step 827).

The SLC processes such a "FoundMovie" SIP message and, by executing the flow descriptor FD (step 828), it determines that an event of receiving a "FoundMovie" SIP message from the network implies a consequent action comprising displaying a result screenful on the terminal display for showing to the user U the list of movies be showing at the desired location.

Therefore, the SLC commands the downloader D to download a third user interface descriptor UID, whose name is for instance "SIPresultsUID" and whose link is comprised within the flow descriptor FD (step 829). The downloader D sends a download request to the descriptor repository DR (step 830). The descriptor "SIPresultsUID" is then downloaded at the terminal T and stored in the cache memory C (step 831).

The SLC then commands the UI-R/UI-E to execute the descriptor "SIPresultsUID" (step 832). The UI-R/UI-E reads the descriptor "SIPresultsUID" from the cache memory C and executes it (step 833), thus generating and rendering on the terminal display the result screenful (step 834) showing the list of movies be showing at the desired location to the user U. Therefore, the example described by referring to Figure 8 allows to highlight the already mentioned advantages of the present invention, which will be now briefly recalled:

- upon development of a new service, single descriptors may be developed or modified independently the one from the others; - upon notification of the new service, only small-size notification information about the service are downloaded at the terminal T, thus occupying a reduced amount of memory;

- upon request of accessing a service, only the flow descriptor is downloaded at the terminal T, thus occupying a reduced amount of memory;

- upon execution of the requested service, other descriptors are dynamically downloaded at the terminal T only if required by the flow descriptor, thus avoiding to needlessly download parts of the client-side service application which will not be used during service execution.

Claims

1. A method of managing a service addressed to a user of a communication network, said user (U) being provided with a terminal (T), wherein said method comprises: - requesting to access said service by means of said terminal (T);

- downloading at said terminal (T) a first descriptor (FD) which describes at least one event (E) occurring at said terminal (T) and at least a consequent action (A) following said at least one event (E), said at least one consequent action (A) comprising downloading a second descriptor (UID, SCD),

- triggering said at least one event (E);

- executing said at least one consequent action (A), wherein said second descriptor (UID) comprises at least an instruction for generating and rendering a user interface to said user (U), or wherein said second descriptor (SCD) comprises at least an instruction for interacting with said communication network.

2. The method according to claim 1 , wherein said user interface is a graphic interface or an acoustic interface or a graphic and acoustic interface.

3. The method according to claim 1 , wherein, interacting with said communication network, comprises transmitting a message to said communication network.

4. The method according to claim 1 , wherein interacting with said communication network comprises listening for a message from said communication network.

5. The method according to claim 1 , wherein interacting with said communication network comprises activating audio-video communications or activating audio-video streams.

6. The method according to any claims 1 to 5, wherein said at least one event (E) occurring a said terminal includes receiving information from said communication network.

7. The method according to any of claims 1 to 5, wherein said at least one event (E) occurring a said terminal (T) includes receiving information from said user (U).

8. The method according to any of preceding claims, wherein said first descriptor (FD) describes at least one further event occurring at said terminal (T) and at least a further consequent action following said further event, said further consequent action comprising downloading at said terminal (T) a further descriptor (UID, SCD), wherein said further descriptor (UID) comprises at least an instruction for generating and rendering a further user interface to said user (U), or wherein said further descriptor (SCD) comprises at least an instruction for further interacting with said communication network.

9. The method according to any of preceding claims, wherein said requesting to access said service is preceded by receiving and storing at said terminal (T) information indicative of the availability of said service from said communication network.

10. The method according to any of claims 1 to 8, wherein said requesting to access said service is preceded by looking for information indicative of the availability of said service into said communication network by said terminal (T), and storing said information indicative of the availability of said service at said terminal (T).

11. The method according to claim 10, wherein said information indicative of the availability of said service comprises at least a link to said first descriptor (FD).

12. The method according to any of claims 1 to 1 1 , wherein said second and further descriptors (UID, SCD) are terminal independent.

13. The method according to any of preceding claims, wherein said first descriptor (FD) and said second and further descriptors (UID, SCD) are stored in a cache memory (C) at said terminal (T).

14. A terminal (T) of a communication network which is adapted to provide a service to a user (U), wherein said terminal (T) comprises:

- a first module (D) for downloading from said communication network a first descriptor (FD) and a second descriptor (UID, SCD), said first descriptor describing at least one event (E) occurring at said terminal and at least a consequent action (A) following said at least one event (E), said at least one consequent action (A) comprising downloading said second descriptor (UID, SCD);

- a second module (SLC) for executing said first descriptor (FD); - a third module (Ul-E, Ol) for executing said second descriptor

(UID, SCD), wherein said third module (Ul-E, Ol), by executing said second descriptor (UID), generates and renders a user interface to said user (U), or interacts with said communication network.

15. The terminal according to claim 14, wherein it further comprises a fourth module (NL) for receiving information indicative of the availability of said service from said communication network and a memory device (LNI) for storing said information.

16. The terminal according to claim 14, wherein it further comprises a fifth module (NL) for looking for information indicative of the availability of said service into said communication network and a memory device (LNI) for storing said information.

17. The terminal according to any of claims 14 to 16 wherein said first descriptor (FD) describes at least one further event occurring at said terminal (T) and at least a further consequent action following said further event, said further consequent action comprising downloading at said terminal (T) a further descriptor (UID, SCD), and said device (Ul-E, 01) is adapted for executing said further descriptor (UID, SCD) for generating and rendering a user interface to said user (U) or for interacting with said communication network.

18. The terminal according to any of claims 14 to 17, wherein it further comprises a further memory device (C) for storing said first (FD), said second (UID, SCD) and said further (UID, SCD) descriptors.

19. A communication network which is adapted to provide a service to users (U), each user being connected to said communication network by means of a respective terminal (T), wherein said communication network comprises:

- at least one server for providing said service;

- at least one descriptor repository (DR) for storing at least a first and a second sequence of instructions relating to said service; and

- at least a terminal according to any of claims 14 to 18.

20. The communication network according to claim 19, further comprising a notification system (NS) for notifying to said at least one terminal information indicative of the availability of said service.