WO2009054614A1

WO2009054614A1 - Method for interworking between a cpm service and a non-cpm service

Info

Publication number: WO2009054614A1
Application number: PCT/KR2008/005507
Authority: WO
Inventors: Romain Masson
Original assignee: Lg Electronics Inc.
Priority date: 2007-10-04
Filing date: 2008-09-18
Publication date: 2009-04-30

Abstract

Disclosure may be to provide a Converged IP Messaging (CPM) service, and more particularly, a method for interworking between a CPM service and non-CPM service by using newly defined parameters to be used for interworking implementation which have information about a message conversion (translation) and/or a service selection.

Description

METHOD FOR INTERWORKING BETWEEN A CPM SERVICE

AND A NON-CPM SERVICE

Technical Field

[1] The disclosure relates to a Converged IP Messaging (CPM) service, and more particularly, to a method for interworking between a CPM service and a non-CPM service by using newly defined parameters to be needed for service selection (routing decision). Background Art

[2] 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 'All 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.

[3] 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].

[4] 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.

[5] 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 to develop future messaging services or services that employ a messaging aspect by selecting specific capabilities into a single communication scenario.

[6] 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.

[7] The Converged IP Messaging (CPM) Working Group in OMA is responsible for specifying the future IP-based messaging functionalities.

[8] CPM is a messaging framework that aims at consolidating common functionalities of existing messaging services and new features introduced by the convergence of communications brought by SIP-based technologies.

[9] Based on the Requirement Document for CPM, the evolutionary interoperability between future IP-based messaging services and legacy mobile messaging services (e.g. SMS, MMS) is included in the CPM service concept in order to achieve maximum connectivity between end-users (independent of whether they are using the future IP-based messaging services or legacy Mobile Messaging Services). It is, therefore, crucial to define the parameters that will be taken into account when making the routing decision.

[10] The CPM (Converged IP Messaging) working group has been created as part of

OMA (Open Mobile Alliance) in order to specify an enhanced IP-based messaging framework, relying on IMS core network. The first purpose is to create a unified enabler that gathers the functionalities provided by the main existing messaging enablers (e.g. MMS, PoC, IM, etc.). Such application would provide an enhanced and simplified user experience and would ensure the success of IMS deployment.

[11] The main objectives of CPM are to provide the user with the ability as follows:

[12] to communicate without knowing what network access technology is being used;

[13] to have parallel conversations, each involving different Media Types;

[14] to concurrently associate several devices with themselves;

[15] to communicate using several devices (e.g. mobile terminal, PC, PDA) at the same time;

[16] to personalize their services by setting preferences to indicate, for example, which device(s) messages should be sent to;

[17] to store any type of message and Media in the network;

[18] to synchronize their local storage with the network storage; and

[19] to communicate with legacy users who support services such as legacy voice, video and messaging services (e.g. MMS and SMS).

[20] Such service would ensure the success of IMS deployment and hence justify the investment made by the majority of the Service Providers on that respect.

[21] The CPM delegates have completed the Requirement Document as well as the Architecture Document. They are now starting to work on the technical specifications.

[22] As part of CPM, several new concepts related to the way the user is going to communicate are defined. These concepts are 'CPM Conversation', 'CPM Message', 'CPM Session', 'CPM Session History' and 'CPM Thread', the explanation of which concepts will be made as follows: [23] 1) A 'CPM Conversation' is defined as the exchange of CPM Messages and/or CPM

Sessions, associated with each other due to common characteristics, between two or more Participants (e.g. CPM Users or Applications). Basically, it corresponds to a user-level conversation, i.e. an exchange of information between a group of users. [24] 2) A 'CPM Message' is information of a discrete nature that can contain several discrete Media (e.g. text, images, audio-clips, video-clips). [25] 3) A 'CPM Session' represents a logical connection between two or more Principals established for a finite duration. This is not to be confused with a SIP Session.

Basically, a CPM Session can be composed of several SIP Sessions (e.g. in case a user has several devices involved in the session). As part of a CPM Session, users can exchange CPM Messages and/or Continuous media (e.g. continuous voice, video, streaming). [26] 4) A 'CPM Session History' is a stored representation of the content exchanged during a CPM Session. It is a discrete type of element that can be stored in the network store, i.e. the Message and Media store.

[27] 5) A 'CPM Thread' is a stored representation of a CPM Conversation.

[28] Fig. 1 illustrates the concepts of CPM Conversation and CPM Thread.

[29] As illustrated in Fig. 1, this diagram illustrates the concepts of CPM Conversation and CPM Thread respectively and the nature of the element they can be composed of. [30] Fig. 2 illustrates a general architecture of a network for providing CPM service.

[31] As illustrated in Fig. 2, The CPM Client 10 is the component which allows the CPM

User to use CPM-based Services by interacting with other CPM functional components such as the CPM Conversation Server. [32] The Message and Media Storage Client 15 manages resources stored at Message and

Media Storage Server in the network as well as resources stored at the Device's local storage. [33] The CPM Controlling Function 20 is responsible for handling CPM Messages and

CPM Sessions that need group functionalities. [34] The CPM Conversation Server 30 acts as the main logic and control unit of the CPM enabler. The CPM Conversation Server 30 is the entity which acts as the network-side contact for the CPM User, including the coordination of the interaction with the multiple CPM Clients the CPM User may have. [35] The Application Control Function 40 provides access to functionalities of the CPM

Controlling Function and of the CPM Conversation Server towards external functional components, for example a gaming application. [36] The Message and Media Storage Server 50 provides management and storage functions for messages and Media in the network, e.g. uploading, downloading, synchronizing, and sharing items. The protocol used between the Message and Media Storage Server 50 and the Message and Media Storage Client 15 is not specified yet.

[37] The Interworking Selection Function 60 is the component responsible of selecting an

Interworking Function that should perform the actual interworking for a CPM Message or CPM Session.

[38] The Interworking Function(s) 70 provides interworking capabilities between CPM- based Services and external Non-CPM Communication Services. It is a kind of a gateway through which CPM connects to Non-CPM communication services. Multiple instances of the Interworking Function may exist in a deployment (e.g. specialized Interworking Functions for the various Non-CPM Communication Services : 1 for SMS, 1 for MMS, etc.).

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

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

[40] Non-CPM Communication Services 90 represent the set of services with which CPM is able to interwork. Examples of these Non-CPM Communication Services are SMS, MMS, IMPS (Instant Message & Presence Service), Instant Messaging, Push To Talk, email, VoIP, Video-over- IP and Internet email.

[41] One of the important features of CPM is the interworking with the legacy systems such as SMS, MMS or IMPS (i.e., Non-CPM Communication Services). It has been agreed in principle that an Interworking Function (IWF) should be part of the CPM framework architecture in order to allow CPM users and non-CPM users to communicate with each other.

[42] In case the a CPM enabler interworks a Non-CPM Communication Service (i.e., legacy system such as SMS, MMS, Instant Messaging, Push To Talk, email, VoIP, Video-over-IP), It is important to make a decision what parameters are needed and defined. This major issue, however, has not been disclosed yet. Disclosure of Invention Technical Solution

[43] CPM is supposed to provide functions to interwork with non-CPM communications services. An important aspect of this interworking functionality is that the CPM user should compose and send messages regardless of the recipient's capabilities, i.e. the CPM user is not supposed to know whether the recipient only has an MMS embedded client on his device or an IMPS client.

[44] From this prospective, the Interworking Selection Function is in charge of deciding which service to interwork with (i.e. SMS, MMS, IMPS or PoC, etc.). This routing decision (or service selection) should be made according to a list of well defined pa- rameters.

[45] This disclosure is to provide new technical mechanisms that CPM interworks a non-

CPM service (e.g., SMS, MMS, Instant Messaging, Push To Talk, email, VoIP, Video- over- IP). These mechanisms of this disclosure are implemented with the defined parameters that have to be considered for making a routing decision (or service selection) between CPM and Non-CPM Communication services.

[46] Therefore, this disclosure is to provide a method for interworking between a CPM service and a non-CPM service in a Converged IP Messaging (CPM) service, the method comprising:

[47] receiving from a first device a CPM message forwarded to a second device; converting the CPM message into a non-CPM service message suitable for the second device; and sending to the second device the converted message.

[48] Preferably, the method further comprising: selecting a service suitable for the second device using information related to interworking implementation.

[49] Preferably, the information is used when a suitable service for the second device is selected by a Interworking Selection Function, and/or

[50] the information is used to convert the CPM message into a non CPM service message.

[51] Preferably, the step of selecting a service is performed by a Interworking Selection

Function.

[52] Preferably, the step of selecting a service further comprises: extracting the information from one or more network entities.

[53] Preferably, the first device is applicable for a CPM service, and the second device is applicable for non-CPM service.

[54] Preferably, the information is a list of parameters to be needed for converting the

CPM message into non-CPM service message and/or selecting a service suitable for the second device.

[55] Preferably, wherein the parameters include at least one of the following:

[56] 'recipient capabilities'; 'recipient availability' ;

[57] 'nature of the message' 'size of the message' ;

[58] 'content of the message' ; 'recipient address type' ;

[59] 'recipient domain' ; 'Content adaptation authorization' ;

[60] 'number of recipients' ; 'type of negotiated media in a CPM Session Invitation' ;

[61] 'Message Subject' ; 'recipient identity'; and

[62] 'type of the continuous media' .

Brief Description of the Drawings

[63] 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, illustrate embodiments of the invention and together with the description serving to explain the principles of the invention.

[64] In the drawings:

[65] Fig. 1 illustrates the concepts of CPM Conversation and CPM Thread.

[66] Fig. 2 illustrates a general architecture of a network for providing CPM service.

[67] Fig. 3 is a CPM Interworking diagram.

[68] Fig. 4 is a view illustrating a signal flow between Joe's terminal (device) and Alice's terminal via network.

[69] Fig. 5 is a diagram illustrating example of service selection.

Mode for the Invention

[70] 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.

[71] Though the present invention may be variously modified and have several embodiments, specific embodiments will be shown in drawings and be explained in detail. However, the present invention is not meant to be limited, but it is intended that various modifications, equivalents, and alternatives are also covered within the scope of the claims.

[72] Although terms of 'first', 'second', etc. are used to explain various components, the components are not limited to such terms. These terms are used only to distinguish one component from another component. For example, a first component may be referred to as a second component, or similarly, the second component may be referred to as the first component within the scope of the present invention.

[73] The term 'and/or' is used to include a combination of a plurality of disclosed items or one of the items.

[74] When it is mentioned that one component is "connected" or "accessed" to another component, it may be understood that the one component is directly connected or accessed to another component or that still other component is interposed between the two components.

[75] Also, when it is mentioned that one component is "directly connected" or "directly accessed" to another component, it may be understood that no component is interposed therebetween.

[76] Terms used herein are to merely explain certain embodiments, not meant to limit the scope of the present invention.

[77] A singular expression includes a plural concept unless there is a contextually distinctive difference therebetween. In this description, the term "include" or "have" is intended to indicate that characteristics, numbers, steps, operations, components, elements, etc. disclosed in the specification or combinations thereof exist. As such, the term "include" or "have" should be understood that there are additional possibilities of one or more other characteristics, numbers, steps, operations, components, elements or combinations thereof.

[78] Unless specifically defined, all the terms used herein including technical or scientific terms have the same meaning as terms generally understood by those skilled in the art.

[79] Terms defined in a general dictionary should be understood so as to have the same meanings as contextual meanings of the related art. Unless definitely defined in the present invention, the terms are not interpreted as ideal or excessively formal meanings.

[80] Hereinafter, certain embodiments of the present invention will be explained in more detail with reference to the attached drawings. The same component or components corresponding to each other will be provided with the same reference numeral, and their detailed explanation will be omitted.

[81] Reference will now be made in detail to some embodiments, examples of which are illustrated in the accompanying drawings.

[82] The present invention provides new technical ideas in which a CPM service in- terworks with a non-CPM service. To do this, a list of parameters shall be defined in order to implement interworking between a CPM user and non-CPM user. Here, the list of parameters indicates (includes) some information to be used to interwork between a CPM service and a non-CPM service. The list of parameters will be used by network side (i.e., Interworking Selection Function) when it converts a CPM message into a non-CPM service message and/or selects a service (e.g., one of legacy system service such as SMS, MMS, IMPS, IM, etc.) suitable (applicable) for a recipient. The list of parameters may be provided by another network entity (for example, HSS) through network side's CPM components (e.g., CPM Conversation Server) or directly by network side's CPM components.

[83] In view of a network side, the fundamental concept of this invention is: firstly to, by network side (i.e., CPM Conversation Server or Interworking Selection Function), analyze a message sent from a CPM user (caller or originating part) using parameters which are achieved from another network entity such as HSS and have information needed to interwork between a CPM service and a non-CPM service; secondly to translate (convert) a CPM message into a non-CPM service message by using (analyzing) the parameters; thirdly to make a service selection in which the network side (i.e., CPM Conversation Server or Interworking Selection Function) changes (transforms) the message in other format suitable for a non-CPM user (or non-CPM service's device) using the parameters; lastly to send to the recipient the message converted (changed or created) into a suitable format (e.g., SMS, or MMS, etc.).

[84] Fig. 3 is a CPM Interworking diagram.

[85] Hereinafter, the basic concept of this invention will be explained with reference to

Fig. 3.

[86] A CPM User should be able to communicate with any non-CPM User. For instance, it is possible for a CPM User to seamlessly exchange messages with an SMS user. An essential requirement in CPM consists in the transparency at the CPM user level, i.e. a CPM User is not supposed to know the capabilities of his/her contacts (i.e., recipient, callee or terminating part). Regardless of the recipient's capabilities, the protocol between the CPM Client and the CPM server remains the same (i.e. CPM protocol based in SIP). In the CPM environment (see Fig. 3), the Interworking Selection Function is responsible for making the service selection decision. This decision has to be made upon well-defined criteria, i.e. parameters.

[87] The invention provides the list of parameters that has to be taken into account when interworking between a CPM service and a non-CPM service (i.e., making the service selection decision and converting a message into another format suitable for a non- CPM user). This list should be defined in order to mandate a server-side vendor to expose adequate inputs to the Interworking Selection Function and create a routing function with a mandatory list of inputs. This will help the Service Providers to design their interworking function when deploying the service. However, a Service Provider willing to deploy the CPM service will have to work in conjunction with the server vendor to define this decision logic with the needed parameters as inputs.

[88] Meanwhile, it is assumed that the CPM user should compose and send messages regardless of the recipient's capabilities. That is, the CPM user is not supposed to know whether the recipient only has an MMS embedded client on his device or an IMPS client. In the present invention, the CPM user may just compose his/her desired message to be sent to a recipient without considering the recipient's capability. The message of the CPM user is delivered from the CPM user to Network (In Fig. 3, shown as CPM environment) via a CPM protocol. Network may perform interworking processes in which network

[89] analyzes the message,

[90] recognizes the feature of it (i.e., the message forwarding to the non-CPM user),

[91] extracts some information (i.e., a list of parameters) to be needed for interworking between a CPM service (or a CPM user) and a non-CPM service (or a non-CPM user),

[92] selects the non-CPM service to interwork with,

[93] converts the message from the CPM format into one of non-CPM service messages

(e.g., SMS, MMS, IMPS, IM, etc.), and

[94] send the converted message to the non-CPM user. [95] The list of parameters newly defined in the present invention may be information on features and characteristics (e.g., size of message, content of message (e.g., picture, video, zip file, or mp3, etc.), recipient domain (CS or PS) and so on) of the message from the CPM user. The parameters should be used when a network entity (e.g., (i.e., CPM Conversation Server or Interworking Selection Function) makes service selection (routing decision). These parameters may be achieved, by network side, from another network entity such as HSS (Home Subscribe Server). Hereinafter, detail explanation of the list parameters will be described.

[96] The list of parameters in the present invention may be defined as follows:

[97] 1. parameter 'recipient capabilities'

[98] This parameter specifies the persistent information about the capabilities of the recipient (callee or terminating part). When network receives this parameter from the CPM user (i.e., caller or originating part), network (i.e., CPM Conversation Server or Interworking Selection Function) may access and retrieve a HSS (Home Subscriber Server) from which it can achieve information of recipient capabilities. The HSS is the master database for a given user. It is the entity containing the subscription-related information to support the network entities actually handling calls/sessions. The HSS stores the following types of information: subscription, identification and numbering; registration; authentication and ciphering; and service profile.

[99] This parameter, 'recipient capabilities', includes capability information related to a recipient's device (i.e., terminating device or terminal). This information comprises:

[100] - the messaging services that the recipient supports, i.e. the services to which the recipient has subscribed;

[101] - the supported media (e.g. H.264 video, codec, text, audio, etc.);

[102] - the recipient's ability to support session-based messaging (e.g. PoC or IM services).

[103] 2. parameter 'recipient availability'

[104] This parameter specifies the recipient capabilities subject to his connectivity (e.g. the recipient supports MMS but is out of GPRS coverage). This parameter is related to connectivity of the recipient (i.e., terminating terminal, device, or UE). In case this parameter indicates that "the recipient supports MMS but is out of GPRS coverage", the recipient is unlikely to receive the message via MMS. Instead, he should be provided with a message in another available format which does not required GPRS connection, e.g. SMS.

[105] 3. parameter 'nature of the message'

[106] This parameter specifies nature (feature or attribute) of a message, sent from the CPM user, which is either discrete or interactive.

[107] In the context of conversation initiation, the CPM user is able to either send a CPM Message (discrete message) or a CPM Session Invitation (message informing the recipient about the intention to start an interactive conversation). Basically, this parameter returns CPM Message or a CPM Session Invitation. Examples of discrete message are such PUSH messages as SMS, MMS, or Email. Meanwhile, examples of interactive one are a type of interactive conversation such as PoC, IMPS or SIMPLE IM.

[108] In case of a CPM Message, the decision logic (logic of service selection) is likely to select services like SMS, MMS, or Email. On the other side, a CPM Session Invitation is expected to be transferred via services such as PoC, IMPS or SIMPLE IM.

[109] 4. parameter 'size of the message'

[110] This parameter specifies a size of the message from a CPM user. The size is a crucial parameter to take into account. For instance, in case of a short text message, the SMS service is very likely to be selected, as being the cheapest messaging service on the market so far. The size parameter can be measured in k bytes or in number of character (in case of text-only CPM Message).

[I l l] 5. parameter 'content of the message '

[112] This parameter specifies content of the message from a CPM user. This parameter is used when a network (CPM Conversation Server or Interworking Selection Function) to perform a service selection. Depending on the content of the message, the service selection can vary. For instance, a message containing a light picture is likely to be delivered via MMS.

[113] This parameter is used to get information such as:

[114] - Whether or not the message contains picture;

[115] - Whether or not the message contains videos;

[116] - Whether or not the message contains unidentified format (e.g. ZIP file);

[117] - The format of the content(s) (e.g. mp3, JPEG, etc.).

[118] 6. parameter 'recipient address type'

[119] This parameter specifies an address type of a recipient (originating or terminating part). According to an address type of the recipient in this parameter, a service (e.g., IMPS, VoIP or etc.) on which the message will be delivered to the recipient should be selected.

[120] That is, a certain address type can be bound to a certain messaging service. For instance, an IMPS address is only used in case the recipient is an IMPS user. In addition to that, certain address type can lead to a potential selection of services. For instance, a Service Provider can decide to link the SIP addresses to services like VoIP, PoC or SIMPLE IM.

[121] Examples of address types are a SIP address (e.g., PoC, IMPS, or etc.), a TEL URI (e.g., SMS, MMS, or etc.), a E.164 number, an IMPS address, an Email address and etc.. [122] 7. parameter 'recipient domain'

[123] This parameter specifies identity of a recipient's domain (CS domain or PS domain). The identity of the recipient's domain is likely to be taken into account when making the service selection. A simple reason for that is that Service Providers usually make agreements for routing, e.g. service decision logic could depend upon the recipient's domain. For instance, in case the recipient can only receive a message via CS domain, this parameter shall set as CS domain. Therefore, when network (i.e., CPM Conversation Server or Interworking Selection Function) receives from a CPM user (originating part or caller) a CPM message with this parameter, the network makes a service selection (routing decision) as CS domain via which the message will be sent to the recipient.

[124] 8. parameter 'Content adaptation authorization'

[125] This parameter specifies rule set of performance to select a service (e.g., SMS, MMS, VoIP, ans etc.) in form of which the message is sent to the recipient. That is, there is a requirement to allow a CPM User to forbid any content adaptiation on his messages. Knowing this, the decision logic has to take this parameter into account, e.g. a CPM Message containing a picture shall not be transmitted via SMS.

[126] 9. parameter 'number of recipients'

[127] This parameter specifies the number of recipients to received a message sent from a CPM user.

[128] The number of recipients can represent an essential parameter in case of having to decide between SMS and MMS interworking.

[129] SMS is designed for 1-to-l communication only. This means that in case one wants to send an SMS to multiple recipients, the SMS Client sends as many SMSs as recipients, each SMS being addressed to a single contact.

[130] In the case of MMS, 1 -to-many communication is supported - the feature is similar to the Email service. In other words, when one wants to send an MMS to multiple contacts, the MMS Client sends a single MMS to the MMS proxy relay (with an indication of the recipients' addresses) and then, the MMS Proxy Relay duplicates and forwards the MMS to the list of recipients. At the user experience level, there is a very important difference between SMS and MMS: in case of MMS, the recipient gets the list of recipients that received the message (as for Email service).

[131] From that perspective, in case of 1 -to-many delivery, a Service Provider (network) is likely to choose the MMS Service in order to keep track of the list of recipients.

[132] 10. parameter 'type of negotiated media in a CPM Session Invitation'

[133] This parameter specifies type of negotiated media in a CPM session invitation. When the CPM User requests a contact to start a session, he sends a CPM Session Invitation. This message is translated at the SIP level to a SIP INVITE request that contains a list of negotiated media with the corresponding supported codec. The information of this parameter can be analyzed to determine the most suitable session-based services, i.e.

PoC, SIMPLE-IM, IMPS, VoIP. [134] 11. parameter 'Message Subject' [135] This parameter specifies a subject of message. This parameter is optional. If network

(Interworking Selection Function) find this parameter, it means that the CPM User intended to specify a certain topic to his message. This parameter is applicable to a

CPM Message or a CPM Session Invitation since a Subject can be attached to CPM

Session. [136] Since not every non-CPM service support message subject, the presence of a subject can help the service decision. For instance, if a subject is attached to CPM Message, it can lead to the use of MMS rather than SMS. [137] 12. parameter 'recipient identity' [138] This parameter specifies a recipient's address. [139] In certain scenarios, it may be useful to consider the recipient's address as an input to the decision logic. A clever implementation would be: [140] - A cache memory located in the network keeps a record of the recent interworking events that took place between the CPM users and their non-CPM contacts. This log contains the last service selections that have been made for each CPM Users' contact.

The log can also store whether the selection has been successful or not. For instance, information in the following form could be found:

[141] Input: text-only CPM Message ; decision: SMS ; Succes: YES. [142] - When the component responsible for service selection receives a message to be forwarded to a non-CPM user, the cache memory is scanned in order to analyze the last decision that has been made for that non-CPM user. [143] - If the current scenario is similar to the last interworking event (same type of message, same media, etc), the same service selection can be applied. [144] 13. parameter 'type of the continuous media' [145] This parameter specifies a type of continuous media of message. [146] In the context of session-based messaging, a CPM User is able to exchange continuous media (e.g. voice, video). [147] The nature of this media can trigger the selection of a service. For instance, if voice is being transferred, the media will be transferred via a PoC service, or VoIP. [148] Hereinafter, the preferred embodiments of the present invention will be described with reference to the accompanying drawings. [149] Fig. 4 is a view illustrating a signal flow between Joe's terminal (device) and Alice's terminal via network. Here, it is assumed that Joe is a CPM user and Alice is a non- CPM user. It is also assumed that network (network entity or network side) has at least one of functional entities such as CPM Conversation Server (CPM CS), Interworking Selection Function and Interworking Function. The Interworking Selections Functions is component (entity) responsible of selecting an Interworking Function that should perform the actual interworking for a CPM Message or CPM Session. This entity is responsible for deciding which service CPM has to interwork with legacy system (i.e., SMS, MMS, IMPS or PoC, etc.)

[150] Fig. 5 is a diagram illustrating example of service selection.

[151] In Figs. 4 and 5, it is assumed that Joe is not supposed to know the capabilities of

Alice. In Figs. 4 and 5, it is also assumed that Joe (i.e., a CPM user) composes a CPM message (this message to be delivered to Alice (i.e., non-CPM user)). The CPM message, composed by Joe, contains: only text; its size is 100 characters; the number of recipients is 1; there is no message subject; its recipient address type is E. 164; and recipient availability is 'registered to the network'.

[152] As illustrated in Figs. 4 and 5, Joe composes a CPM message and sends it to Alice via network. After network receives the CPM message, it analyzes the message. Network recognizes features of the message. In addition, network may analyze some information (i.e., a list of parameters to be need for interworking between Joe (a CPM user) and Alice (a non-CPM user)) which is achieved from another network entity (e.g., HSS). Network may perform interworking process in which it selects a service (e.g., SMS, MMS, or etc.) and converts a message in another format suitable for Alice. As illustrated in Fig. 5, Network may know information (i.e., a list of parameters) related to interwork implementation such as content of message, size of message, number of recipients, message subject, recipient address type, and recipient availability (Sl and S2). Here, the information indicates a list of parameters which has been defined and explained in this invention. Meanwhile, the information (i.e., a list of parameters) may be achieved by network in a manner where network accesses and retrieves another network entity (e.g., HSS).

[153] After extracting some information (i.e., a list of parameters) related to the CPM message from Joe, on the base of this information the Interworking Selection Function selects the best non-CPM service to transfer the message in a suitable format (i.e., SMS) (S3). That is, in this preferred embodiment, the service decision logic may select the SMS service as the more suitable non-CPM communication service to interwork with:

[154] 1) network may analyze Joe's sending message and a list of parameters.

[155] 2) the Interworking Selection Function makes a service selection decision best suitable for Alice (non-CPM user) using the parameters (i.e., information related to interworking between a CPM service and a non-CPM service.

[156] 3) the Interworking Function makes the protocol conversion between CPM and SMS: a) it creates (converts) an SMS from the text body of the CPM Message; b) it extracts from the "To" field of the CPM Message the address of the recipient and translates it into a phone number; c) it forwards the SMS to the SMS Center.

[157] Network (e.g., SMS Center) sends the SMS converted from Joe's message by using (analyzing) the list of parameters. Finally, Alice receives an SMS containing Joe's message (S4).

[158] In case Joe's sending message is adapted to MMS, the Interworking Selection Function may select a service (i.e., MMS) best suitable for Alice. That is, the Interworking Function makes the protocol conversion between CPM and SMS: a) it creates (converts) an MMS from the text body of the CPM Message; b) it extracts from the "To" field of the CPM Message the address of the recipient; c) it forwards the MMS to the MMS Center. Network (e.g., MMS Center) sends the MMS converted from Joe's message by using (analyzing) the list of parameters. Finally, Alice receives an MMS containing Joe's message. The mechanism explained with reference to Figs. 4 and 5 will be applicable to such legacy system as IMPS, IM and so on.

[159] 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

[1] A method for interworking between a CPM service and a non-CPM service in a

Converged IP Messaging (CPM) service, the method comprising: receiving from a first device a CPM message forwarded to a second device; converting the CPM message into a non-CPM service message suitable for the second device; and sending to the second device the converted message. [2] The method of claim 1, further comprising: selecting a service suitable for the second device using information related to interworking implementation. [3] The method of claim 2, wherein the information is used when a suitable service for the second device is selected by a Interworking Selection Function, and/or the information is used to convert the CPM message into a non CPM service message. [4] The method of claim 2, wherein the step of selecting a service is performed by a

Interworking Selection Function. [5] The method of claim 2, wherein the step of selecting a service further comprises: extracting the information from one or more network entities. [6] The method of claim 1, wherein the first device is applicable for a CPM service, and the second device is applicable for non-CPM service. [7] The method of claim 1, wherein the information is a list of parameters to be needed for converting the CPM message into non-CPM service message and/or selecting a service suitable for the second device. [8] The method of claim 7, wherein the parameters include at least one of the following:

'recipient capabilities'; 'recipient availability';

'nature of the message' 'size of the message' ;

'content of the message' ; 'recipient address type' ;

'recipient domain' ; 'Content adaptation authorization' ;

'number of recipients' ; 'type of negotiated media in a CPM Session Invitation' ;

'Message Subject' ; 'recipient identity' ; and

'type of the continuous media' .