WO2008100019A1

WO2008100019A1 - Method for providing cpm service using device profile

Info

Publication number: WO2008100019A1
Application number: PCT/KR2008/000072
Authority: WO
Inventors: Romain Masson; Patrick Fischer
Original assignee: Lg Electronics Inc.
Priority date: 2007-02-14
Filing date: 2008-01-07
Publication date: 2008-08-21

Abstract

Disclosure may be to provide a Converged IP Messaging (CPM) service using a Device Profile, wherein a user is allowed to access and retrieve a readable list of his/her registered devices by defining a “Device Profile” which has device information and preference information to be set by the user.

Description

METHOD FOR PROVIDING CPM SERVICE USING DEVICE

PROFILE

Disclosure of Invention Technical Solution

[1] The present application claims the priority benefits of U.S. Provisional Application

No. 60/889,915 filed on February 14, 2007. The entire contents of these applications are herein fully incorporated by reference.

[2] The disclosure relates to a Converged IP Messaging (CPM) service, and more particularly, to a method for providing a CPM service using a Device Profile.

[3] In general, CPM service refers to a messaging service to be provided by converging and managing one or more messages from all kinds of existing messaging services like a session based messaging service (e.g., PoC, IM, Voice Call and Chat), a push based messaging service (e.g., SMS, MMS and Offline IM) or a pull based messaging service (e.g., Voice Mail, MM Box and Email). The CPM service may provide users with an enhanced IP-based messaging, relying on IMS (Internet Protocol Multimedia Subsystems) core network. The IMS refers to a core network technology related to 'Al l IP' which integrates (unifies) wired and wireless communication environments. The IMS was introduced by a Third Generation Partnership Project (3GPP) which develops global specifications of a wireless communication. The IMS adapts an infrastructure for providing an IP multimedia service.

[4] The CPM defines a converged IP-based messaging enabler which accommodates different user experiences such as deferred and immediate messaging, session-based messaging and conferencing. It interacts with other OMA enablers such as Presence [OMA Presence] and XDM [OMA XDM].

[5] The CPM enabler is designed to support the "converged" environment that includes the convergence of different user-experiences as well as the convergence of different user-equipment choices, network choices, and convergence of the network elements needed to support messaging in the future.

[6] The CPM enabler provides the convergence of multi-media communication services while leveraging standardized service functionalities from existing communication enablers like Instant Messaging (OMA SIMPLE IM) or Push to talk over Cellular (OMA POC). Service convergence brings together different service capabilities - existing as well as new features - under the umbrella of an enabler which allows develop future messaging services or services that employ a messaging aspect by selecting specific capabilities into a single communication scenario. [7] The CPM enabler is intended to specify its service capabilities as common reusable capabilities that support building of a range of IP-based services needing messaging functionality.

[8] Fig. 1 illustrates a general architecture of a network for providing CPM service.

[9] As illustrated in Fig. 1, a CPM Client 10 allows the end user to initiate and access a

CPM service by interacting with other CPM components such as the CPM Conversation Server or the Message and Media Storage.

[10] A CPM Conversation Server 20 acts as the main logic and control unit of the CPM enabler. The CPM Conversation Server 20 uses the services both from other CPM components and external entities for the realisation of a CPM service.

[11] A Message and Media Storage 30 is the Network Storage for messages and media which includes both management and storage functionalities. It can be accessed both directly and indirectly by other CPM components such as CPM Client and CPM Conversation Server.

[12] A Converged Address Book 40 provides the central unit for user address book handling which includes synchronization of address books in the case of multiple device ownership and interacts with other components to consolidate all information relating to user address.

[13] A CPM User Preference 50 provides functions such as storing, modifying and retrieving of user preferences relating to the CPM services. It can be accessed by other CPM components such as CPM Client and CPM Conversation Server.

[14] An Interworking Function 60 provides the communication with external Non-CPM

Communication Services. It is a kind of a gateway through which CPM connects to Non-CPM communication services.

[15] A Third Party Applications 70 is applications which using CPM to deliver value- added services.

[16] Supporting Enablers 80 are entities used by the CPM Enabler to support the CPM

Service. Examples are XDM, STI, CBCS, Presence, and DM.

[17] Non-CPM Communication Services represent the set of services with which CPM is able to interwork. Examples of these Non-CPM Communication Services are SMS, MMS, IMPS, and Internet email.

[18] The CPM service has not provided a user with mechanism to access and retrieve, from one of his/her devices, a list of his/her registered devices and the available media on them.

[19] This disclosure is to provide new technical ideas that a user is allowed to access and retrieve a readable list of his/her registered devices by defining a "Device Profile" which has device name and preference information to be set by the user.

[20] This disclosure basically provides, firstly mechanism in which a user may access and retrieve a readable list of the device's addresses for the user's devices, and secondly mechanism in which a user defines and sets a Preference for each device to thus access and retrieve. These mechanisms of this disclosure are implemented with the defined "Device Profile" having information on the device's name and Preferences for the devices used by the user.

[21] Therefore, this disclosure is to provide a method for providing a Converged IP

Messaging (CPM) service using a device profile, the method comprising: receiving, by a server, from a terminal an access request for a list of devices registered for the CPM service; retrieving, by the server, a device profile in response of the request; and sending, by the server, to the terminal the list of device names of devices registered for the CPM service based on the retrieved device profile.

[22] Preferably, the server additionally sends a preference list of the registered devices.

[23] Preferably, the method further comprising: creating the device profile by the terminal's user; storing, by the terminal, the device profile in the terminal's memory; and sending, by the terminal, to the server the device profile every time of a registering process performed between the terminal and server.

[24] Preferably, the method further comprising: storing the device profile in the server's database, or updating the previously stored device profile with it.

[25] This disclosure is also to provide a method for performing synchronization of a device profile in a Converged IP Messaging (CPM) service, the method comprising: receiving, from a terminal, a changed terminal-side device profile; and synchronizing a server-side device profile with the received terminal-side device profile by using a device identifier.

[26] Preferably, the method the synchronizing step includes: extracting client IDs from the received terminal-side device profile; mapping the extracted client IDs with corresponding server IDs; and updating data of the server-side device profile with the changed data of the received terminal-side device profile from the terminal.

[27] Preferably, the device profile is composed of "device identifier" field, "device name" field and "preference" field of each device with respect to the devices.

[28] Preferably, the terminal can be used by one or more users each of which creates his own device profile.

[29] Preferably, the device identifier includes a client ID assigned to each registered device by the terminal and a server ID corresponding to the client ID assigned by the server.

Brief Description of the Drawings

[30] The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, il- lustrate embodiments of the invention and together with the description serving to explain the principles of the invention.

[31] In the drawings :

[32] Fig. 1 illustrates a general architecture of a network for providing a CPM service;

[33] Fig. 2 is a view illustrating a signal flow between a terminal and a server in accordance with a first embodiment of the present invention.

[34] Fig. 3 is an exemplary SIP REGISTER METHOD to be sent from the terminal to the server;

[35] Fig. 4 is a schematic diagram illustrating a database structure in the server;

[36] Fig. 5 is a view illustrating a conflict case in which two devices have the same device name at a time of registration;

[37] Fig. 6 is a view illustrating a signal flow between a terminal and a server in accordance with a second embodiment of the present invention;

[38] Fig. 7 is a schematic diagram illustrating synchronization of Device Profiles between the terminal and the server;

[39] Fig. 8 is another exemplary SIP REGISTER METHOD to be sent from the terminal to the server. Mode for the Invention

[40] This invention may be applied to wired/wireless communications systems related to a

CPM service. However, this invention may not be limited thereto, but be applicable to any type of systems and devices to adapt the fundamental ideas of this invention.

[41] It is assumed that a user participating in CPM service has already taken a user's address (e.g., a SIP URI) in a network side at the time of registering the CPM service.

[42] In IMS network, a user is able to register several devices (i.e., clients) in network side (i.e., server). In case the user has a single device, when the user registers the device in a network server providing a CPM service, the network server has access to a device's address (e.g., its IP address) and the user's address (e.g., a SIP URI). The device's address is linked (associated) with the user's address. The network server, therefore, can access and retrieve the device's address of the registered device by using the user's address.

[43] In case the user gets (uses) one or more devices to be registered, when he/she registers them in network server, a device's address for each of the devices may be given beyond the user's address (or account). Each of registered devices, therefore, has a different device's address therebetween. The network server may access the user's address to thus access and retrieve a list of the device's addresses for the one or more devices registered in the network server. Hence, the device's addresses are not readable (understandable) because they are a digit code or a binary code in format. If the user requests the list of the currently registered devices, the network server can provide the IP addresses of the registered devices which the user is not understandable because they are not a letter (word, or alphabet) but a binary code in format.

[44] The fundamental concept of this invention is, firstly to create a "Device Profile" including a readable name of each device, registered in a network server, as well as Preference of each device, with which a user is allowed to edit each device name of one or more devices registered or to be registered instead of each device's address thereof, secondly to allow the user to define and set Preference (or priority) of each of one or more devices, and thirdly to provide a list of the devices currently registered in the server when the user requests it. That is, by using the Device Profile, the user can access and retrieve a list of his/her devices registered in the server to thus recognize which device of the registered devices is available for a specific service, provided with both a list of device names and a set of Preferences from the Device Profile.

[45] Here, the "readable name" of each device refers to a device name, which is a string of letters (e.g., alphabet or word), on a display of the user's terminal (device) or the server's specific display.

[46] The "Preference", set by the user with respect to each registered device, refers to a kind of priority or indicator with which the user is allowed to designate a registered device as a dedicated device to receive a preferred service (e.g., text-based messages) of CPM. That is, the Preference denotes information (or parameter) for defining a user's preferred way of using the CPM Services (e.g., receive video stream sessions on device 1, receive text-based messages on device 2, etc.) when the terminal is registered to CPM. Otherwise, the preference denotes information (or parameter) for indicating a filtering rule associated with an entity (e.g., Message & Media Storage in Fig. 1), if it is, the preference may have information related to a filtering rule of storing therein.

[47] The basic concept of this invention may be implemented by first and second embodiments hereafter. More particularly, the embodiments of this invention may be classified according to the method of managing a Device Profile between a network server and terminal (device).

[48] Furthermore, a terminal used for explaining the embodiments according to this invention will first be described hereafter.

[49] A terminal can be called a device and able to implement a CPM service. It denotes a mobile communication terminal which inclusively includes devices such as mobile phones, cellular phones, or user equipment (UEs). Also, the terminal may include every wire or wireless device capable of using a CPM service based on an IMS network.

[50] However, the terms aforementioned and to be mentioned are assumed to explain the embodiments of the present invention more conveniently, but may not restrict or limit the scope of the present invention.

[51] Hereinafter, configurations and operations in the preferred embodiments of this invention will be described with reference to the accompanying drawings. [52] Fig. 2 is a view illustrating a signal flow between a terminal (device) and a server (CPM server) in accordance with a first embodiment of the present invention. In the first embodiment of this invention, Device Profile may be created by a user and stored in a terminal (device) only, and thereafter transferred from the terminal to a server every time of a registering process therebetween. In Fig. 2, it is assumed that the user has one or more devices to intend to register in the server.

[53] As illustrated in Fig. 2, the user may create (edit) a Device Profile with the devices to be registered in the server (Sl). The Device Profile is composed of one or more device names (i.e., readable device name, for example "my fancy phone"), dedicated to each of the one or more devices to be registered, as well as a set of Preferences indicating a preferred service to each device. For example, it is assumed that the terminal's user has 4 different device (e.g., mobile phone, MP3, notebook and PC) to be registered in the server. The user may create a Device Profile as the following Table 1 :

[54] Table 1 [Table 1]

[55] For one example, the user may create a Device Profile like Table 1. It is learned in Table 1 that the user names his Mobile Phone as "my fancy phone" (as a device name) and set Preference of the device (mobile phone) as Text-based messaging, Pictures and voice mail. The user, therefore, may receive one or all of Text-based messaging, Pictures and voice mail originated from an originating terminal (counterpart, caller) to "my fancy phone" (user's mobile phone). For another example in Table 1, the user named his MP3 as "my music" (as a device name) and set Preference of the device (MP3) as Session-based messaging (e.g. instant messages) only. The user, therefore, may receive instant messages originated from an originating terminal (counterpart, caller) to MP3 (it is assumed that MP3 has a function of receiving Session-based messaging). Meanwhile, the Device Profile may be also modified and deleted with a dedicated application or a specific processor equipped with the terminal.

[56] Moreover, the user may create a Device Profile including one or more filtering rules independently applicable to each device as shown in exemplary Table 1. The filtering rules may be set different each other which indicate preference of a device belonging to the user. As shown in Filtering Rule of Table 1, each of Condition A - D refers to each Preference set to each device (i.e., Mobile Phone, MP3, Notebook and PC). For one example, if Filtering Rule is set as Condition A for a device (e.g., Mobile Phone), the preference of the device corresponds to Text-based messaging, Pictures and voice mail. For another example, if Filtering Rule is set as Condition B for a device (e.g., MP3), the preference of the device corresponds to Session-based messaging. A new Filtering Rule may also be made (created) by combining one or more condition from Condition A ~ D, to thus be applied to a user's device (e.g., Mobile Phone).

[57] In completion of creating the Device Profile, the created Device Profile may be stored in a memory equipped with the terminal. The Device Profile may be unique or linked to a user account including information on subscription to a CPM service. Here, the user account may be stored and managed in a network side in the method that a network server allocates a different and unique user's address (account) to each user.

[58] At each registration, the terminal may send the Device Profile to a server (S2). There may be several methods to send the Device Profile according to a kind of registration between the terminal and the server.

[59] For one example, in case of a SIP registration, the only device name of the Device

Profile can be sent via SIP METHOD message. That is, the device name can be sent from the terminal to the server in SIP registration process in which the device name is inserted into a Header part (e.g., "Contact field" as shown in Fig. 3) of SIP REGISTER METHOD. Alternatively, the device name or Device Profile itself may be inserted in a Body part of SIP REGISTER METHOD.

[60] For anther example, in case of XCAP (XML Configuration Access Protocol) protocol, the Device Profile may be sent from the terminal to the server within an XML document. Details for XCAP are described in documents and drawings related to IETF XCAP to thus be omitted for a brief explanation of this disclosure.

[61] If the user has not specified any Device Profile, several implementation may be possible as follows: 1) the terminal may request the user to create a Device Profile (e.g., device names and Preferences) before a registering process; 2) before a registering process, the terminal may request the user to partially create a Device Profile (e.g., only device name) with allocating default values to the other fields (e.g., a field of Preference) of the Device Profile; 3) in case the terminal may send the registration command (message) with all fields of Device Profile set as "Unknown", the server may handle this case relying on the Operator's Policy.

[62] On the network side (i.e., server), the server may receive the Device Profile and then store it in a memory corresponding to the user's account in a database thereof (S3). Furthermore, the received Device Profile may be stored in one of the various entities of the server, for example CPM Conversation Server 20, Message & Media Storage 30, Converged Address Book 40 in Fig. 1 or an alternative and different entity independent to entities shown in Fig. 1. The server may combine (link) the received Device Profile with the user's account and maintain both the list of device name of the registered devices and a set of Preferences in the database dedicated for the user as shown in Fig. 4. Referring to Fig. 4, it may be a case in that the user's account in the database has two Device Profiles, one of which is the one already received from Step S3.

[63] Meanwhile, the device capabilities may be sent within the Device Profile during the registration procedures. In such case, the database of the server may also maintain the device capabilities as part of the Device Profile. Herein, the device capability denotes information related to a capability for a device to properly support and implement a CPM service, examples of which are a supported codec, an application, protocol, a media format and so on by one terminal.

[64] There may be a case in which the user requests a list of the device names of the registered devices stored in the server. In this case, the terminal may send a command (e.g. Request Message) to the server asking for the list (S4). The server may search and extract the Device Profile stored in the database dedicated for the user using the user's account, retrieve the list of device names from the Device Profile (S5). The server, therefore, send the retrieved list, which includes one or more device names registered in the server, via a message (e.g., as Body of SIP METHOD or as a message of XCAP, etc.) to the terminal (S6). At the Step S6, a format of the device names included in the list is not binary code but letter readable (understandable). The user, therefore, may recognize which of his/her devices are currently registered in the server.

[65] If the user deregisters one or more device, the server could or should remove the

Device Profile from the database.

[66] Fig. 5 is a view illustrating a conflict case in which two devices have the same device name at a time of registration.

[67] Referring to Fig. 5, when a user intends to register two different devices (Device A and Device B as shown in Fig. 5) with the same device name (e.g., "my computer"), the server may face a conflict situation. In this situation, the server's implementation may be possible as follows:

[68] 1) the server may reject the registration request from Device A and send an error message to Device B stipulating that the suggested device name (i.e., "my computer") has been already used;

[69] 2) the server may accept the registration request from Device B and deregister

Device A while sending a warning message to Device B indicating Device A has been deregistered;

[70] 3) the server may accept the registration request from Device A and send a warning

(e.g., "two devices presently registered with the same device name")

[71] Fig. 6 is a view illustrating a signal flow between a terminal (device) and a server

(CPM server) in accordance with a second embodiment of the present invention. Fig. 6 may be called a case of synchronized Device Profile: in this embodiment, 1) one or more Device Profiles dedicated for each user can be created in one terminal; 2) Device Profile may be stored in both terminal and a server; 3) After each Device Profile created for each user may be sent and stored in the server, it may be synchronized to update changed or modified data between the terminal and the server. It is assumed in Fig. 6 that multiple users (e.g., User 1 and User 2) can use the same terminal (e.g., Device A or Device B in Fig. 7) and create unique Device Profile for himself/herself.

[72] In the second embodiment of the present invention, Device Profile is composed of 3 fields, "Device Name", "Preference" associated with each device and in addition "Device Identifier". Here, Device Identifier, used by the server (network) denotes a fixed identifier to uniquely identify a device. Device Identifier may be classified to "Client ID", which is managed by (oriented to) the user's terminal side, and "Server ID", which is managed by (oriented to) the server side. Client ID may be a number assigned to an object (i.e., device) in a database, values of which are only unique locally, i.e., to each device provided by database of the terminal. The terminal (Client) may assign to each device Client ID which is a locally unique, non-reusable identifier. Client IDs are unique per device and per application. Meanwhile, Server ID may be a number assigned to an object (i.e., each Client ID) in a database, values of which is never reused and unique as long as they exist in some mapping table like Table 3.

[73] Table 2 is an exemplary table to indicate Client ID and device name. At Table 2, each device name readable, set for each of user's devices as shown like Table 1, are assigned to Client ID. Table 3 is an exemplary table to indicate ID mapping between Client ID and Server ID.

[74] Table 2 [Table 2]

[75] Table 3 [Table 3]

[76] As illustrated in Fig. 6, when each of users (e.g., User 1 and User 2) may create his/ her unique Device Profile in the terminal and send it to the server, the server may store it in the database of the server (SlO).

[77] Each of users (e.g., User 1 and User 2) may create (edit) a Device Profile for his/her one or more devices to be registered in the server (Sl 1). Step Sl 1 in Fig. 6 is ap- plicable to Step Sl in Fig. 2. Each user, therefore, may create his/her own Device Profile in the terminal using a readable Device Name field and its Preference field associated with each device to be registered by each user. Each of the created Device Profile may be stored in a memory built in terminal (e.g., a memory allocated as a "User Account 1" for user 1 and a "User Account 2" for user 2 as shown in Fig. 7) designated for each user. Device Profiles stored in the terminal may be stored and maintained (managed) depending on each user's account (i.e., User Account 1 for user 1 and User Account 2 for user 2 in Fig. 7). It is assumed that a Device Profile stored in the terminal is referred to as a terminal-side Device Profile. In the terminal, each Device Profile may be unique or linked to each User Account. There can be one Device Profile per User Account on one terminal (device). For one example, Table 2 may be an example in which each device name of User l's Device Profile is assigned to a unique Client ID.

[78] Each Device Profile created by each user may be sent to the server at a registration procedure like Step S2 of Fig. 2 (S 12). Meanwhile the Device Identifier (Client ID) may be provided by the terminal each time the terminal performs a registration procedure between the terminal and the server. For one example, in case of a SIP registration, the Device Identifier may be sent within a Header or a Body of a SIP REGISTER METHOD as shown in Fig. 8 where the Device Identifier (Client ID) is inserted in the Contact field of the Header thereof.

[79] The server may receive the Device Profiles for all users (or some of them), which is sent via a registration requesting message of Step S 12 in Fig. 6, and then store them in a server database (S 13) with performing a mapping procedure in which each Client ID is mapped to each Server ID unique. In Step S 13, the server may correlate the Device Identifier with each user's account (e.g., User l's account or User 2's account) assigned by the server. The server, then, may be able to identify the Device Profile and one or more would-be registering devices which are included in the user's database. The server may then apply the user's preference to each registered device on a basis of Preferences specified in the corresponding Device Profile.

[80] It is assumed that a Device Profile stored in the server is referred to as a server-side

Device Profile to distinguish with the terminal-side Device Profile for convenient explanation of the second embodiment. As a result of Step SI l thru Step S 13, it is learned that the terminal- side Device Profiles are equally matching (mapping) to the server-side Device Profiles.

[81] If there is occurred any change in one or more terminal-side Device Profiles in a case where each user (or both) edits or modifies them, or new user creates a new Device Profile, synchronization procedure may be performed between the terminal and the server (S20). Hereinafter, more details for synchronization procedure of Step S21 ~ S23 will be described with reference to Fig 7. Fig 7 is an exemplary embodiment in which several users (i.e., User 1 and User 2) can use each device (i.e., Device A and Device B) and User l's Device Profiles (e.g., both Device Profile Al in Device A and Device Profile Bl in Device B) are changed (modified).

[82] In case of any change in a configuration of the terminal-side Device Profiles (e.g., both Device Profile Al in Device A and Device Profile Bl in Device B created by User 1), each terminal (Device A and Device B) may (or should) send a command (i.e., updating request message) to the server in order to update (synchronize) the configuration of the server-side Device Profile matching (mapping) to the terminal-side Device Profile changed in each terminal (S21 and S22). That is, "Device Profile A" in the server will be synchronized with "Device Profile Al" from Device A. And "Device Profile B" in the server will be synchronized with "Device Profile B2" from Device B. For example, a possible implementation would be to use the DataSync protocol to synchronize the terminal-side Device Profile with the server-side Device Profile.

[83] The server may receive the changed Device Profiles (e.g., User l's Device Profile Al from Device A and User l's Device Profile Bl from Device B) to thereby update the server-side Device Profile (i.e., Device Profile A and B in the server as shown in Fig. 7) with them (S23).

[84] Hereinafter, more details for synchronization procedure of Step S21 ~ S23 will be described with reference to Table 1 thru Table 3. For one example, it is assumed that the device name of MP3 in User l's Device Profile is changed from "my music" to "my music phone". In this case, since User l's Device Profile is changed, synchronization procedure will be performed using a synchronizing protocol (e.g., so called the DataSync protocol). Client ID's value (i.e., "33" in Table 2) corresponding to the changed device name for MP3 may be sent to the server in format of Device Profile via a commanding message (i.e., updating request message).

[85] After the server receives the Device Profile and extracts the value of Client ID therein, it may perform to map the Client ID's value (i.e., "33" in Table 3) to the uniquely corresponding Server ID (i.e., "3030303" in Table 3). The server may, then, access data (i.e., device name "my music") of a server database assigned for the Server ID (i.e., "3030303" in Table 3). Next, the server may perform to update the changed Device Profile by changing the device name from "my music" to "my music phone." These procedures indicate synchronization between the terminal-side Device Profile and the server-side Device Profile in case of any change occurred in the terminal-side Device Profile. Meanwhile, unique Server ID may be implemented with IMEI, MAC address or a random identifier.

[86] There may be a case in which the user requests a list of the device names of the registered devices stored in the server. In case User 1 requests his created Device Profiles in server (i.e., Device Profile A and B in User 1 's database in server in Fig. 7), the terminal may send a command (e.g. Request Message) to the server asking for the list (S4'). The server may search and extract Device Profile A and B stored in the database by using the Device Identifier and User l's account, retrieve a list of the registered device names from User 1 's Device Profiles (S5'). The server, therefore, send the retrieved list, which includes one or more device names registered in the server, via a message (e.g., as Body of SIP METHOD or as a message of XCAP, etc.) to the terminal (S6'). At the Step S6', a format of the device names included in the list is not a binary code but a letter readable (understandable). The user, therefore, may recognize which of his/her devices are currently registered in the server.

[87] If a user (e.g., User 1 or User 2) tries to register without having defined a Device

Profile (i.e., terminal-side Device Profile), the terminal's action (implementation) may be possible as follows:

[88] 1) the terminal may request the user to define a Device Profile;

[89] 2) the terminal may send a registration request (e.g., as a SIP REGISTER METHOD message) without any Device Identifier. In this case several scenarios are possible: (1) the server may reply with the user's list of Device Profiles stored therein. The terminal may display the list of Device Profiles so that the user has the ability to select one or to define a new one. In case the user selects one Device Profile, the server and the terminal should create a new Device Profile. The Device Name and Preferences are copied from the selected profile and a new Device Identifier is allocated to this Device Profile; (2) in case the server may define a default Device Profile to use, it may handle this case relying on the Operator's Policy.

[90] As described above, the present invention may provide a scheme to manage all the devices registered in a CPM service in which the present invention defines a Device Profile as well as its configuration and its features (implementation) between the terminal and the server. In addition, in the present invention, a user is able to manage (access, modify, copy, delete, etc.) all the devices in a Device Profile with setting its preference of each device.

[91] Furthermore, the present invention may allow a user to access and retrieve information on his/her devices registered in the server, for instance a readable list of his/ her device names and/or a set of Preferences designated for each device on a basis of the Device Profile.

[92] Besides, the present invention may provide a scheme in which the terminal-side

Device Profiles may be kept synchronized with the server-side Device Profiles.

[93] As described above, this disclosure has been explained with reference to the embodiments which are merely exemplary. It will be apparent to those skilled in the art that various modifications and variations can be made in this disclosure. Thus, it is intended that this disclosure cover modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims

[I] A method for providing a Converged IP Messaging (CPM) service using a device profile, the method comprising: receiving, by a server, from a terminal an access request for a list of devices registered for the CPM service; retrieving, by the server, a device profile in response of the request; and sending, by the server, to the terminal the list of device names of devices registered for the CPM service based on the retrieved device profile.

[2] The method of claim 1, wherein the server additionally sends a preference list of the registered devices.

[3] The method of claim 1, a format of the device names is a readable letter.

[4] The method of claim 1, further comprising: creating the device profile by the terminal's user; storing, by the terminal, the device profile in the terminal's memory; and sending, by the terminal, to the server the device profile every time of a registering process performed between the terminal and server.

[5] The method of claim 4, further comprising: storing the device profile in the server's database, or updating the previously stored device profile with it.

[6] The method of claim 1, wherein the device profile is composed of "device name" field and "preference" field of each device with respect to the devices.

[7] The method of claim 1, wherein the device profile is composed of "device identifier" field, "device name" field and "preference" field of each device with respect to the devices.

[8] The method of claim 1, wherein the device profile additionally includes information on device capabilities and/or filtering rules.

[9] The method of claim 1, wherein the device profile is linked to a user account including information on subscription to the CPM service.

[10] A method for performing synchronization of a device profile in a Converged IP

Messaging (CPM) service, the method comprising: receiving, from a terminal, a changed terminal-side device profile; and synchronizing a server-side device profile with the received terminal-side device profile by using a device identifier.

[I I] The method of claim 10, the synchronizing step includes: extracting client IDs from the received terminal-side device profile; mapping the extracted client IDs with corresponding server IDs; and updating data of the server-side device profile with the changed data of the received terminal-side device profile from the terminal. [12] The method of claim 11, wherein data of device name field and/or data of preference field in the server-side device profile are updated. [13] The method of claim 10, wherein the device profile is composed of "device identifier" field, "device name" field and "preference" field of each device with respect to the devices. [14] The method of claim 10, wherein the terminal can be used by one or more users each of which creates his own device profile. [15] The method of claim 10, wherein the device identifier includes a client ID assigned to each registered device by the terminal and a server ID corresponding to the client ID assigned by the server. [16] The method of claim 15, wherein the client ID of device identifier is sent from the terminal to the server within a Header or a Body of a SIP REGISTER

METHOD. [17] The method of claim 10, wherein the server-side device profile has sent from the terminal at a registration procedure between the terminal and server and stored therein.