WO2009118045A1

WO2009118045A1 - Methods and apparatuses for providing services

Info

Publication number: WO2009118045A1
Application number: PCT/EP2008/053684
Authority: WO
Inventors: José Luis AGÚNDEZ DOMINGUEZ; Jesús RENERO QUINTERO
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2008-03-27
Filing date: 2008-03-27
Publication date: 2009-10-01

Abstract

Method and apparatuses for providing services to users of a telecommunications system. A server receives (110) user-defined data from a terminal of a user sent via a data synchronization protocol message from said terminal. The server stores (120), in relationship with user data, service adaptation data for adapting a service that can be provided to said user based on received user-defined data. The user-defined data can be received via SyncML and comprise non-hierarchical sequence of keywords in the form of tags. Service adaptation data of a user can be provided (170) to a further server providing a service matching a service preference stated by the service adaptation data. By reusing existing data synchronization dialogs that synchronize data in a terminal with data in a system, service adaptation is achieved in a simplified manner.

Description

METHODS AND APPARATUSES FOR PROVIDING SERVICES

FIELD OF THE INVENTION

The present invention relates to methods, apparatuses and computer programs for providing services to users of a telecommunications system.

BACKGROUND

Technical frameworks for providing services to users of telecommunications system have evolved substantially in recent years. The evolution has been driven, among other significant factors, by two targets: providing service ubiquity, and ease service adaptation. In this context, the term "service" is no limited to -say- traditional telecommunications services, such as voice or messaging communications (e.g. Short Message Service, SMS), or their high-layer processing (e.g. customized call delivery/routing controlled by application servers) , but also encompasses new kind of services already envisaged to be provided from, or through, state-of-the-art telecommunications systems, such as: positioning services, location based information services, customized information services, multimedia services, web-based services, etc, and services comprising combinations thereof.

The first target required some servers of the telecommunications systems to be adapted, so that a virtual layered architecture of a telecommunications system is achieved. In short, such a layered architecture comprises: "access networks", comprising servers and links (e.g. of different wired and/or wireless technologies) facilitating user terminals to primarily connect to the system; a "service network", comprising service servers arranged to provide some final services; and a "core network", comprising servers that provide inter-connection control between different access networks, terminals and service networks .

A layered architecture is thus intended for decoupling: some services that can be provided to the users, from the terminals they can use and, therefore, from the type of access used to connect a terminal to the telecommunications system (e.g.: a Local Area Network LAN, a Wireless LAN, a GSM or UMTS radio access, etc) . The ownership of a layered system can belong to the same network operator, or belong to different ones. In particular, layered architectures are also intended for allowing mixed business scenarios comprising, for example, a traditional network operator (such as a GSM or UMTS operator) owning access and core networks, and one or more companies (commonly referred as "service providers") making up the service network. In this scenario, it is also envisaged that a service server of the service network can belong to the (traditional) network operator, which can thus become a service provider too.

Ericsson Review No. 1, 2002 (http : //www. ericsson. com/ericsson/corpinfo/publications /rev iew/2002_01/files/2002012.pdf) discloses an example of a telecommunications system comprising a layered architecture,

The second target required the service servers to be provided with (static and/or dynamic) data related to the served users, such as: preferences, user identity information, geographical location, information about other preferred/subscribed services, etc; so as to build up what is commonly known as user's service profile data. At least part of these data can be used to adapt a service to a user. Adapting a service to a user can comprise, among other: personalizing a service already provided to a user, offering a new one, providing selective advertisement of services and/or products, etc; based on service adaptation data stored in relationship to said user.

A well-known approach to achieve this goal comprises the user contacting the service provider (or network operator) to provide the relevant information to, e.g., subscribe to and/or personalize a particular service. Data based on said information would then later be provided (e.g. via operation and maintenance procedures) as service adaptation data into the involved service server (s) . This approach is not suitable when some user-related data, relevant for a service to be provided, change frequently, since it can introduce significant delays.

This problem can be tackled by adapting service servers so as to make them able to receive user-defined data directly from user terminals, and to store locally service adaptation data, for the corresponding users, based on them.

However, this requires the service server to perform tasks beyond the mere service (s) execution and, thus, increases its complexity and cost. For example, a service server can be adapted to push events/news about certain sport in user terminals (e.g. establishing a Session Initiation Protocol -SIP- based session towards a user terminal through the Internet Protocol Multimedia Subsystem -IMS of a 3^rd Generation mobile system, or pushing the relevant content via Wireless Access Protocol -WAP- over a General Packet Radio Service -GPRS- connection, or via Internet Protocol IP-based television -IPTV) . Thus, in addition to its media forwarding capabilities, the service server would need to implement a user interface suitable for collecting data directly from user terminals. Furthermore, the process can be cumbersome for a final user, as he would have, not only to discover by himself services he could be interested in, but also to communicate individually with, eventually, a plurality of service servers to provide, in some cases, the same (or similar) information.

It should be therefore desirable to provide the users of a telecommunications system with an alternative way of defining data usable for adapting services.

SUMMARY

This object is solved by aspects of the invention as claimed in the independent claims. Embodiments of the invention are set out in the dependent claims.

The invention provides a way to adapt service offering to a user by reusing data synchronization protocol messages, currently used to manage and keep safe copies of data locally stored in a user terminal by synchronizing data stored in the terminal with data stored in the network, such as calendar or contact data. According to aspects of the invention, user-defined data for adapting services are further included in a synchronization protocol message sent from a terminal of a user towards the telecommunications system. The user-defined data are received in a server of the system, which stores, in relationship with user data of said user, service adaptation data for adapting one or more services that can be provided to the user based on the received user-defined data.

The usage of synchronization protocol messages for further adapting services to users provides a simplified solution, since the necessary service adaptation data can be provided from a user terminal to a server of a telecommunications system in an automated manner by reusing a communication channel already used for synchronizing, e.g. periodically, data stored in the terminal with data stored in the telecommunications system serving access to said terminal. Service adaptation data of a user are then used therein for further adapting a plurality of services that can be provided to said user.

Service adaptation data related to a user can comprise part or all user-defined data as received, or data derived therein. Accordingly, a user does not need to contact individual service servers directly for creating and/or maintain his service-related data, or for discovering and being offered with new services he might be interested in, but just provide, via synchronization protocol messages, information usable to define service adaptation data in a server of the telecommunications system. Similarly, a service provider can use service adaptation data provided by a plurality of users to select a subset of said users as targets for adapted advertising of service/products, by filtering preferences inferred from these service adaptation data.

According to embodiments of the invention, the synchronization protocol is the Synchronization Markup Language SyncML, and the user-defined data comprises a non- hierarchical sequence of keywords, which can be alphanumeric tags identifying user preferences applicable for one or more services, or type of services, the user can be interested in. The user-defined data can be input by a user of the terminal and be locally stored therein until a data synchronization message is sent from the terminal to the telecommunication system.

The usage of a standardized synchronization protocol, such as SyncML, simplifies implementation impact in user terminals, since a widely implemented synchronization protocol is reused for that purpose. This feature also minimize implementation impacts for telecommunications network operators, since no new protocols for communicating with user terminals need to be implemented for obtaining user preferences in order to personalize existing services, or offering new ones.

On the other hand, the storage on a server of a telecommunications system of service adaptation data based on simple keywords/tags received from the terminal of a user, provides the operator of said system with a simplified method for adapting own services, as well as services offered by external providers, to said user, since the server can store similar information in relationship with a particular service, which characteristics needs not necessarily to be interpreted on said server.

According to further embodiments of the invention, user- defined data can be locally defined by the user on his terminal, and be stored therein until a request is received from a server of the telecommunications system; wherein these user-defined data are sent towards a server of the system upon reception of said request. The user is thus not required to take the initiative of establishing a communication with the telecommunications system for the purpose of defining service preferences, as his terminal can offer him the possibility to define them off-line instead. Also, the network operator of the telecommunications system is provided with a solution allowing it refreshing service adaptation data related to particular users depending on factors such as current traffic load conditions and/or time-related schemes.

According to a further embodiment of the invention, service adaptation data stored in relationship with a user can be delivered from a server in the telecommunications system to a further server offering a service. According to yet another embodiment, wherein service data related to a service further identify a type of service, said delivery can be preceded by checking first whether service adaptation data of a user matches a type of service of a service. The server storing service adaptation data of users is thus not necessarily forced to interpret complex service-related data about the services that can be provided to the users, since a simple data matching process can suffice by providing said server with information related to services that can match information received from users .

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a flowchart illustrating some steps of a method according to embodiments of the invention.

Figure 2 shows a simplified view of a telecommunications system according to an embodiment of the invention. Figure 3 shows a simplified signaling flow among entities shown in Fig.2 according to embodiments of the invention.

Figure 4 shows a schematic representation of some functional modules of a server or a terminal according to an embodiment of the invention.

DETAILED DESCRIPTION

Exemplary embodiments of the invention shall now be described with reference to figures 1 to 4.

Fig.l shall be used to illustrate steps of a method according to some embodiments of the invention.

Step 110 represents the arrival of a data synchronization protocol message to a server of a telecommunications system. The message is assumed to be sent from a terminal connected to the system and registered for a user, wherein the protocol is, for example, according to SyncML. This protocol (standardized by the "Open Mobile Alliance" OMA - http://www.openmobilealliance.org/) provides a standardized way of synchronizing data between user devices (such as personal computers, mobile phones, personal data assistant, etc) , as well as between user devices and servers in a telecommunications network. One of the typical interactions via SyncML between a user terminal and a telecommunications network is for the general purpose of device management. This allows, for example, downloading or upgrading some software in a user terminal when needed, configuring some parameters in the user terminal for a given service, obtaining terminal capabilities, back-up in a server of the network data stored locally in the terminal, synchronize some of these data, etc.

According to an aspect of the invention, the message of step 110 further comprises, user-defined data for adapting services to the user of the terminal. The user-defined data could have been input by the user in the terminal before the SyncML message of step 110 was sent, and be included therein (among other already SyncML standardized content) by the controlling logic in the terminal when said message is to be sent, e.g., upon request from a server of the telecommunications system.

The user-defined data can comprise, for example, a non- hierarchical sequence of keywords, which can be alphanumeric tags identifying user preferences applicable for one or more services, or type of services, the user can be interested in. Preferably, the user-defined data are not necessarily tied to specific features or services provided from, or through, the telecommunications system, but rather relate to high-level abstract description of user interests. Accordingly, user-defined data, or service adaptation data derived therein (as will be later described) , can be usable for adapting services in a specific-service-independent way, as long as a matching/filtering process using said information takes place on, or before, service provisioning/access .

The usage of keywords/tags for characterizing and/or defining user preferences regarding services provides a user with an easy way of defining service adaptation data on his terminal. For example, the syntax of the keywords/tags can be well-known by the users, or be provided beforehand from the telecommunications system (e.g. from information received from service servers), and are not necessarily related to a specific service, but usable to adapt a plurality of services. Some existing internet services, such as the one provided by http://del.icio.us/, allows users to store and share the bookmarks of those sites (e.g. an internet site providing a given service) they find interesting. Together with the bookmark, the user is invited to add some tags describing the site. "Photography", "Tutorials" , "Music", "Golf", are example of tags. As a result, tags associated to a site result on a non-hierarchical sequence of keywords which can help a user to find a service provided by a site he could be interested in. User-defined data added to data synchronization message 110 can comprise one or more keywords similar to the "tags" referred herein.

The current version of the SyncML protocol is OMA Device Management (DM) 1.2, and it is a preferred embodiment of a data synchronization protocol to convey new kind of content according to the invention. For example, the actual SyncML data structures in which user-defined data could be described are of type DATA, inherited from type ITEM. This way, all the operations already defined in SyncML, such as: Add, Delete, Replace, etc; could be applicable to convey user-defined data in the form of keywords/tags. An excerpt of the SyncML Representation format Document Type Definition, DTD, is included below, in which the ITEM type is defined.

< !ELEMENT Item (Target?, Source?, SourceParent?,

TargetParent?, Meta?, Data?, MoreData?)> In order to describe user-defined data inside DATA field, a preferred format is "Comma-Separated Values" CSV mime-type format, as indicated by IETF RFC 4180. To accomplish with this implementation alternative, a META clause as described below would be used to indicate the new information:

According to the embodiment above, the following example could be part of a client request, using the REPLACE command, to modify the existing user-defined data stored in a server of the telecommunications system:

</Meta> <Item>

Science-fiction, Golf, Soap Operas, Punk </Data> </Item>

On step 120 the user-defined data received on the message of step 110 arrives (directly or indirectly) to a server of the telecommunications system, and service adaptation data are stored therein, in relationship with data related to the corresponding user, and based on the received user- defined data. For example, the server performing step 120 can store the received user-defined data (or update the previously stored user-defined data related to said user) in relationship with an identifier of the user, wherein said identifier can be received on the message of step 110, or be derivable from it, or be obtainable based on it.

Service adaptation data related to a user that are stored (and/or updated) on step 120 can comprise part or all user- defined data as received, or data derived therein. This is an implementation detail that can be adjusted, for example, depending on factors such as the preferred internal representation of certain data in the server (s) having to store and/or process this information. In any case, as stated earlier, service adaptation data stored in relationship with a certain user are based on user-defined data received in relationship with said user.

Step 130 represents an optional embodiment of the invention, wherein a terminal of the user is requested to send eventual updates of user-defined data via further SyncML messages, as in step 110.

The request of step 130 is not necessarily sent immediately after the storage step 120, nor is it necessarily sent from the server performing said storage step. For example, it can be sent periodically or asynchronously, so that it coincides with other SyncML synchronization procedures between the telecommunications system and the user terminal, and/or at time intervals that fits with current traffic load in the system or with operator needs. Apart of the apparent advantages for the operator of the telecommunications system, a further advantage of this embodiment benefits to the end users (as will be later detailed) , who can define (off-line) user-defined data on their terminals, which shall be later collected, via standard SyncML procedures, from a server of the telecommunications system.

The method illustrated in Fig.l continues with subsequent steps illustrating some embodiments describing how service adaptation data related to a user can be utilized for further adapting a service to said user.

Step 140 represents the reception, in a server of the telecommunications system, of information related to a service provided from a service server. Said information can comprise, for example, an identifier of the service server and information related to the service type. Step 150 represents the storage of said information. According to a first embodiment, step 140 can comprise the reception of a data provisioning message, for example, from an operation and maintenance server. According to a second embodiment, step 140 comprises the reception of a message from a service server comprising information of service (s) provided from said service server.

According to an advantageous embodiment, a server in the telecommunications system stores: user data related to their subscribed users (wherein service adaptation data stored on step 120 can belong to this category) , and service data related to the services that can be provided from, or through, said telecommunications system (wherein said data can be received, for example, as illustrated by step 140) . Preferably, the service data comprise information usable to determine a service type, which can be matched before service adaptation data related to users. This allows, for example, a quick process for checking whether a characteristic/feature of a given service match with some user's preferences, so as to personalize said service for some users, offering/prioritizing/advertising/etc said service to certain users, etc.

Step 160 illustrates said checking/matching process. A simple and advantageous realization comprises storing in step 150 service type information with a similar format as user's service adaptation data stored in step 120, which facilitates execution of step 160.

Regardless of whether the embodiment illustrated by steps 140 to 160 takes place or not, service adaptation data of a user can be sent to a service server, as illustrated by step 170. These data can have the same or different format as the one generated in step 120. For example, they can be adapted (e.g. according to a previously agreed data exchange scheme) depending on the destination service server .

The message of step 170 can comprise information related to one or more users, and preferably comprises identifier (s) of the corresponding user(s) .

An advantage for a server storing and/or forwarding service adaptation data is that it is not forced to interpret probably complex service-specific related data, since a simple data matching process (e.g. as described above) can suffice, wherein said server is provided with information related to services, and the corresponding service adaptation data, related to users, that would match them. Accordingly, a simplified processing logic is required in such server, which saves development costs. An advantage for a service server is that it receives, in an automated manner, information usable to adapt one or more services that can be provided therein to a user, e.g. according to his preferences, without the need of establishing a direct communication with the user(s) to collect the relevant information so as to build up the necessary service adaptation data. For example, a first service server can be specialized in pushing text information contents about sport events into terminals of some subscribed users, and a second service server can perform a similar service, but via multi-media content (e.g. via IPTV) . Any of both servers can personalize a service to a user who has expressed, for example, keyword "golf" in the message illustrated by step 110 (e.g. by delivering preferably golf related contents to said user) , or advertise their specific services to said user (e.g. if a specific type of content matches the received user defined preferences) . Accordingly, service servers can be developed without the need of implementing interfaces and/or communication protocols to collect user preferences directly from the user's terminals, so as to adapt services to users .

There are alternative solutions, which can allow adapting a plurality of services to a user in a manner that does not requires the user to contact directly each and every service (e.g. by communicating directly with service servers, or with administration staff of the corresponding service providers) to provide the necessary service adaptation data. An envisaged solution comprises collecting automatically user activity information in respect to some services, processing said information so as to infer a "profile" of said user, and establishing from there the corresponding service adaptation data automatically. However, the data inferred therein can be inaccurate, and such a kind of automated methods invade in some way the user privacy.

In turn, the embodiments of the invention alleviates, on the one hand, the user of having to provide information for a plurality of services, and, on the other hand, does not necessarily invade user privacy; since the user-defined data sent via data synchronization messages from a terminal can easily be under control of its user and, at the end, it is the user the one controlling its content. Furthermore, the user-defined data can be centrally collected by a server, and the corresponding, and more accurate (as user- defined) , service adaptation data distributed to, and/or accessed from, a plurality of service servers, so as to provide a service adapted to a user without the need of communicating directly with him.

In summary, features provided by the embodiments of the invention (e.g. as described with reference to Fig.l) allows a simplified way of achieving service adaptation, which benefits to users (as they can dynamically modify their preferences by defining user-defined data on their terminals, which can be applicable to a plurality of services) , service providers (as they can obtain these data without the need of implementing direct interfaces with the user terminals for collecting preferences) and network operators (as they can reuse synchronization protocol messages, already used for other purposes, for collecting user-defined data for service adaptation usage) . Figure 2 shows a simplified view of a telecommunications system 200 according to an embodiment of the invention that considers a layered architecture as described earlier.

A plurality of terminals (20 to 23) , connectable to a plurality of access networks (schematically represented under numeral 24), are shown in Fig.2. These access networks can comprise, among other, radio access servers of 2^nd Generation (e.g. Global System for Mobile telephony, GSM), 3^rd Generation (e.g. Universal Mobile

Telecommunications System, UMTS), wired or wireless Local Area networks (LAN, WLAN), etc. The so called core network (e.g. comprising servers such as: Mobile Switching Centres MSCs, Serving or Gateways GPRS Support Nodes S/GGSNs, Call Session Control Functions CSCFs, etc) is not shown for simplicity.

In the illustrated example, it is assumed that some of the users of the terminals 20 to 23 are subscribed (or at least can have access to) a service provided by any of the service servers 27 to 29, or are able to receive an advertising related to a service provided by any of these service servers. These service servers, as well as an eventual business support centre server (BSS, 26), can be considered as belonging to the service network layer of the telecommunications system 200. Server 26 can, for example, belong to a network operator owning part (or all) of the access network (s) 24, to which some (or all) the illustrated user terminals 20..23 are subscribed to, and can act as a back end system for running business operations related to service provision with, e.g., internal and/or external service providers owning service servers 27..29. OSA/PARLAY, or other well-known business- to-business interfaces and communication frameworks, can be used to communicate among server 26 with service servers 27..29, so as to provide service provision/adaptation information .

Server 25 represents an embodiment of the invention that considers a modified OMA data synchronization server, which, acts as a server end-point for SyncML signaling exchange with user terminals 20..23, and that is further adapted to accomplish with some features of the invention. For this purpose, server 25 comprises a SyncML signaling exchange and processing functional module (DS SRV) , and a matching engine (ME) functional module. The DS SRV module is modified to, at least, be able to receive the SyncML modified content according to said embodiment of the invention. The ME module can be implemented, if information of service type about services is held, so as to check whether service adaptation data of a user matches with a certain service, and for making available at least part of said service adaptation data to a service server (27..29), for example, through BSS server 26. These functional modules can be implemented by software, hardware and combinations thereof.

According to implementation alternatives, service adaptation data derived from the received user-defined data can be stored in server 25 or 26.

The embodiment shown in Fig.2, and more precisely the description given above with reference to servers 25 and 26, illustrates only one possible alternative to implement features of the invention, which considers the re-use, with some adaptations, of some servers existing in (or envisaged to) some telecommunications systems and their existing (or envisaged) service provision frameworks. However, other alternatives are equally feasible, as would be apparent for the skilled person, wherein, for example: server 25 communicates directly with service servers (27..29), the ME resides in a different server as the one hosting the DS SRV functionality, etc.

Next, a simplified signaling flow among entities shown in Fig.2 shall be described with reference to Fig.3 to illustrate some embodiments of the invention.

In flow 301 the user of terminal 21 (21-U) inputs on his terminal data about its service preferences, and the terminal stores locally the corresponding user-defined data on step 302. The user-data stored by the terminal 21 can comprise user data directly input by the user (e.g. the user types one or more alphanumeric strings/keywords) , or can be derived therefrom. The first case simplifies the logic in the terminal, whilst the second requires a specific application in said terminal which, for example, prompts the user to select one or more keywords by means of a graphical menu. However, an advantage of the later is that the user terminal 21 can have pre-stored information, which could be received from a server in the telecommunications system 200 (e.g. as defined by service servers) .

According to the illustrated embodiment, the next iteration takes place when a data synchronization event is triggered from the telecommunications system side. This provides the advantage of alleviating the user terminal 21 of having to communicate with a server of the telecommunications system 200 every time the user-defined data have changed. Also, it provides advantages for the operator (s) of the telecommunications system, as the frequency of said triggering can be controlled depending, for example, on current traffic load of server (s) in the system, and/or according to time-related schemes.

In flow 303 server 25 requests a synchronization update to user terminal 21, and it is replied in flow 304 with data comprising the latest copy of the user-defined data stored therein. Next server 25 extracts the novel data according to the invention (i.e. user-defined data for service adaptation) , and in step 305, according to the illustrated embodiment, performs a matching process as described earlier with reference to Fig.l, step 160.

Next, according to a first illustrated embodiment, data usable to perform a personalized service offering for the concerned user are delivered from server 25 to BSS server 26 in flow 306. Alternatively, according to a second illustrated embodiment, server 26 can query about these data to server 25 (e.g. periodically, or upon a request from a service server), as shown by flows 308 and 309.

Data in flow 306 (or 309) can comprise data related to one or more users (previous interactions with other users not shown in Fig.3 for simplicity) . The matching process can equally be performed by server 26, in which case, the process of transforming the received user-defined data (as such) into usable service adaptation data (if necessary) can be performed by any of these servers (25, 26) . Service adaptation data of a user can be stored by server 26 (or 25) in relationship with an identifier of said user, and be accessed therein by any service server, so as to adapt a service to him. For example, a service server (28) can query server 26 (or 25) about service adaptation data of a user by presenting an identifier of said user, which can be the same as the one stored by the queried server, or usable to find it. Also a service server (28) can query server 26 (or 25) for users whose service adaptation data matches a certain criteria specified in the request. These alternatives are schematically illustrated in Fig.3 by flows 310 and 311.

Alternatively, or additionally, the matching process (160, 305), regardless on what server it is executed (e.g. wheter in server 25 or server 26), can produce the sending of relevant information to one or more service servers, as illustrated by flow 307. Said relevant information can vary according to various alternative implementations. For example, it can comprise identifiers of one or more users that can be subject of service adaptation with regard to a particular service provided from the destination service server. Also, it can comprise identifiers of one or more users together with, respectively, their corresponding service-adaptation data, or part of it (e.g. the eventually matching parts) . A simplified alternative implementation, which does not necessarily requires the execution of the matching process (160, 305), comprises the sending from server 25 or 26 to a plurality of service servers of service adaptation data of one or more users.

As a result, a service server 28, which, for illustration purposes, can be assumed as devoted to deliver e.g. multimedia content to a plurality of subscribed users, can determine that the user 21-U is (currently) interested in e.g. "golf" events, and could, e.g. when multimedia content of a relevant related event is ready, establish a multimedia communication with his terminal 21, so as to provide the adapted service (corresponding signaling flows not shown in Fig.3 for simplicity) . Similarly, if the service is subject to subscription and/or user consent, service server 28 could send (directly or indirectly) an advertisement to a terminal (21) of the user (21-U) whose preference (e.g. "golf") has been known by server 28, so that said user is aware about a particular service provided from said service server, and/or consent to a further service provision (corresponding signaling flows not shown in Fig.3 for simplicity) .

In Fig.4, a schematic representation of some functional modules of a server 25 or a terminal 21 according to an embodiment of the invention is shown. The embodiment considers in both cases an implementation as computer-based apparatuses .

Any of these entities (server 25 or terminal 21) can, regardless specific construction details, be considered as an apparatus comprising one or more functional modules; each of them arranged to perform a specific (sub) function of the total functionality implemented by said entity. Once the functionality of said entity has been specified, the construction of the functional modules (being these comprised of software, hardware or combination thereof) making up said entity, so to build up a realization of the corresponding physical machine (s), or its modification, is a matter of routine work for those skilled in the art. Explanations given herein with reference to computer-based server 25 can equally apply to server 26, wherein, as referred earlier, the disclosed functionality can be allocated to one server, or be distributed between them. For simplicity, the embodiment illustrated in Fig.4 considers that a single server (e.g. server 25), either, implemented within one single computer machine, or distributed among a plurality of computer machines, is arranged to: receive user-defined data received from a terminal of a user via a data synchronization protocol message, and store in relationship with an identifier of said user service adaptation data based on said user- defined data.

This preferred (computer-based) embodiment has been selected since, nowadays, most of the entities intervening in telecommunications network, either: being user terminals (e.g. mobile terminals, personal computers, etc), or being server nodes (e.g. telecommunication nodes, service servers, etc) , are apparatuses comprising combination of hardware and software for controlling its operation. Sometimes, and specially in what concerns to entities acting as server nodes, its total functionality is distributed among a plurality of physical machines, which co-operate to accomplish with the total functionality said server node is assigned to perform. The alternative of single physical machines is illustrated in Fig.4 for simplicity. The software comprises one or more computer programs having computer readable program code that, when executed by a computer-based apparatus makes it to behave according to a predefined manner, as determined by the specific program instructions in said programs, which can be arranged according to any of the described embodiments of the invention .

Accordingly, the description given herein with reference to Fig.4 shall describe some functional components of a user terminal 21, and of a server of a telecommunications system 25, adapted each to accomplish with the functionality described heretofore, without falling into specific hardware and software construction details, which are well known by those skilled and, consequently, which are not needed to understand the invention.

The simplified internal structure shown in Fig.4 comprises: a processing module 401, a communications module 402, a data storage module 403 and internal communication buses

404 which allow data communication and cooperation between them. In general, when a message is to be sent, the processing module 401 requests the communications module 402 to send the message and provides it with the necessary data, and, when a signaling message is received by the communications module, it transfers the relevant content to the processing module for triggering the necessary processing. In turn, the processing module 401 accesses the data storage module 403 to store/update/check/obtain the necessary data for the operation.

The processing module 401 can comprise one or more processors (only one processor 4010 is shown in Fig.4) which, for example, can be arranged to work in load-sharing or active-backup mode. The operation in, respectively, terminal 21 or server 25, is controlled by computer- readable program code comprising instructions that are executed by processor 4010. The execution of these instructions makes respectively, terminal 21 or server 25, to perform according to embodiments of the invention described before.

As stated earlier, currently, most of the user terminals and servers of telecommunications systems are implemented by computer-based apparatuses. Accordingly, computer programs comprising computer-readable program codes are loaded in computer-based apparatuses causing them to behave according to a predefined manner, as determined by the respective program codes, which are in accordance to the specific functionality specified for the servers/terminals these apparatuses implement. Thus, those skilled in creating and/or modifying computer programs, would, without departing of the teachings of the present invention, readily apply them to create and/or modify computer programs suitable to be loaded in a computer-based terminal, or in a computer-based server of a telecommunications system, so as to make them to behave according to any of the described embodiments.

External communications are performed via communications module 402, illustrated in Fig.4 as comprising two communication devices 4021 and 4022. Depending on different implementation alternatives, a communication device can be suited to accomplish with one or more than one communication types (i.e. communications according to one or more communication protocols and/or signaling interfaces) . For example, with reference to the system 200 of Fig.2, communications from server 25 with server 26 (or with service servers 27..29), and with other servers of the access and/or core network 24 (the latest not detailed in Fig.2) can be implemented partially or totally by communication devices 4021 and/or 4022. Similarly, communications between terminal 21 and entities in the access network, which facilitates also its communication with other servers, can be implemented by communication devices 4021 and/or 4022.

Data storage module 403 stores, respectively, in terminal 21 or server 25, the data needed for the operation their respective separate operation. A data storage module in a computer-based apparatus can comprise one or more data storage devices. In the example illustrated in Fig.4 it comprises storage devices 4031 and 4032. Memory chips and magnetic or optical discs are example of data storage devices. Depending on criteria such as data access speed for certain data, storage reliability, etc, the storage module of, respectively, terminal 21 or server 25 can comprise one or more storage devices of the same or different kind.

Data storage module 403 can store, for example, the computer-readable program to be executed by processor 4010. For example, in terminal 21, the data storage module can comprise locally defined user-defined data until they are sent via a data synchronization message towards server 25, and data storage module in server 25 can comprise a database storing, in relationship, identifiers of users and their corresponding service adaptation data. Said data-base (that can also be external to server 25) can, according to a further embodiment described earlier, comprise service data related to services provided by service servers (27..29) . The invention has been described with respect to some exemplary embodiments in an illustrative and non- restrictive manner. Variations can be readily apparent to those of ordinary skill in the art. For this reason, the invention is to be interpreted and limited in view of the claims .

Claims

1. A method for providing services to users of a telecommunications system, comprising the steps of:

- receiving (110) user-defined data from a terminal of a user via a data synchronization protocol message from said terminal to said telecommunications system,

- storing (120) in a server of the system, in relationship with user data of said user, service adaptation data for adapting a service that can be provided to said user based on the received user- defined data.

2. The method of claim 1 wherein the data synchronization protocol is the Synchronization Markup Language SyncML.

3. The method of claim 1 wherein the user-defined data comprises a non-hierarchical sequence of keywords.

4. The method of claim 1 further comprising the previous step of:

- requesting (130) periodically or asynchronously from a server in the telecommunications system towards a terminal of said user to send said user-defined data.

5. The method of claim 1 further comprising the step of:

- providing (170) from a server in the telecommunications system at least part of said service adaptation data to a further server offering a service.

6. The method of claim 5, further comprising the previous steps of:

- storing (150) service data related to services that can be provided to the users, wherein service data related to at least one service further identify a type of service, and

- checking (160) whether service adaptation data of a user matches a type of service of a service, wherein the step of providing comprises the step of:

- providing at least part of said service adaptation data to a further server offering a service matching said type of service.

7. A server (25, 26) for providing services to users of a telecommunications system, comprising a processor and a storage device in communication with said processor and storing instructions adapted to be executed by said processor to:

- receive user-defined data from a terminal of a user via a data synchronization protocol message from said terminal to said telecommunications system,

- store, in relationship with user data of said user, service adaptation data for adapting a service that can be provided to said user based on the received user-defined data.

8. The server of claim 7 wherein the data synchronization protocol is the Synchronization Markup Language SyncML.

9. The server of claim 7 wherein the user-defined data comprises a non-hierarchical sequence of keywords.

10. The server of claim 7 wherein the storage device further stores instructions adapted to be executed by said processor to request periodically or asynchronously towards a terminal of said user to send said user-defined data.

11. The server of claim 7 wherein the storage device further stores instructions adapted to be executed by said processor to provide at least part of said service adaptation data to a further server offering a service.

12. The server of claim 11, wherein the storage device further stores instructions adapted to be executed by said processor to:

- store service data related to services that can be provided to the users, wherein service data related to at least one service further identify a type of service,

- check whether service adaptation data of a user matches a type of service of a service, and - provide at least part of said service adaptation data to a further server offering a service matching said type of service.

13. A method for providing a user from a terminal with access to a telecommunications system, comprising the steps of:

- exchanging (110) data synchronization protocol messages with a server of said system for synchronizing data stored in said terminal with data stored in the system; characterized in that it further comprises the steps of:

- including in a data synchronization protocol message from said terminal user-defined data for adapting a service to said user based on said user-defined data.

14. The method of claim 13 wherein the data synchronization protocol is the Synchronization Markup Language SyncML.

15. The method of claim 13 wherein the user-defined data comprises a non-hierarchical sequence of keywords.

16. The method of claim 13 further comprising the steps of:

- storing (302) data input by a user on said terminal as said user-defined data,

- receiving (130, 303) from a server a request to send user-defined data, and

- sending (304) at least part of said stored user- defined data included in a data synchronization protocol message.

17. A terminal (21) for providing a user with access to a telecommunications system, comprising a processor and a storage device in communication with said processor and storing instructions adapted to be executed by said processor to:

- exchange data synchronization protocol messages with a server of said system for synchronizing data stored in said terminal with data stored in the system; characterized in that the storage device further stores instructions adapted to be executed by said processor to: - include in a data synchronization protocol message from said terminal user-defined data for adapting a service to said user based on said user-defined data.

18. The terminal of claim 17 wherein the data synchronization protocol is the Synchronization Markup Language SyncML.

19. The terminal of claim 17 wherein the user-defined data comprises a non-hierarchical sequence of keywords.

20. The terminal of claim 17 wherein the storage device further stores instructions adapted to be executed by said processor to:

- store data input by a user on said terminal as said user-defined data,

- receive from a server a request to send user-defined data, and - send at least part of said stored user-defined data included in a data synchronization protocol message.

21. A computer program product comprising computer- readable program code for performing the steps of one of claims 1 to 6 when the computer program product is run on one or more computer-based apparatuses.

22. A computer program product comprising computer- readable program code for performing the steps of one of claims 13 to 16 when the computer program product is run on a computer-based apparatus.