HK1091058B - Method, device and system for handling a message addressed to a client terminal - Google Patents

Description

Method, device and system for processing message addressed to client terminal

Technical Field

The present invention relates to messaging in a telecommunication system, and in particular to the handling of messages addressed to a client terminal, for example MMS (multimedia messaging service) messages.

Background

MMS (multimedia messaging service) provides a mechanism for sending back and forth, for example, drawings, photos, music or voice clips (clips) and video clips to and from client terminals connected to a telecommunication system. The system is similar to SMS (short message service), which can exchange text messages, but MMS can also be used for other types of content. MMS systems operate on a "store and forward" principle, in which messages are stored and may be formatted at an MMSC (multimedia messaging service center) when sent between users.

An MMS relay/server (or MMSC) is a network element or application that is under the control of an MMS (multimedia messaging service) provider. The unit transmits messages, provides specific operations to the mobile environment, and provides storage services. In a client terminal, such as a mobile phone, MMS messages are processed by an MMS client module. The MMS client provides the content of the MMS message to the presentation layer so that the user can view the message.

In writing the specification, the use of MMS to transfer data back and forth for applications running on top of MMS clients is discussed in 3GPP (third generation partnership project) and Java community (JSR 205 expert group). In the "Wireless Messaging API (WMA) for Java^TMThe Proposed system is defined in 2 Micro Edition ", Version 2.0, advanced Final Draft, Draft0.10a, 23.10.2003, JSR 205 expert group.

In the proposed system MMS messages are used as carriers for application data and the MMS client is controlled to deliver the message content including the application data to the respective application without processing the content itself and vice versa. In the following, the term "upper level" application is used to refer to an application that runs on top of the operating system, as a separate application from the MMS client, but uses MMS messages as a carrier for transferring application data. Additional header fields in the MMS message PDU (protocol data unit), such as an application ID header field, are used to identify the source and destination applications of the MMS message content. Through these new header fields, the MMS client is able to recognize the content of a message destined for an "upper layer" application and forward the content to the corresponding "upper layer" application.

The proposed system is expected to be approved as the 3GPP TS 23.140 standard.

Disclosure of Invention

Now, the solution proposed by Java Community has found a problem. I.e. the solution is not backward compatible with MMS clients, which do not support the proposed new header fields and "upper layer" applications.

As mentioned above, according to this proposal, it is not assumed that an MMS client receiving a message carrying an application ID header field processes/represents such a message, but rather forwards the content of the MMS message to the target "upper layer" application without any modification. However, it is possible that an MMS client that does not know the header field of the new application ID may have processed/presented the message itself. This may impair the intended handling/presentation behavior of the MMS client and subsequently cause user annoyance or law violation involving copyrighted material.

Such problems are expected to be prevalent during the introduction of "upper layer" application support when most MMS clients in use do not support this new feature and thus cannot properly process MMS message content destined for the "upper layer" application. Especially in person-to-person communications (e.g. different games), the sender may not or cannot check whether the recipient supports the "upper layer" application.

In addition, since it is expected that new applications using MMS as a carrier for transmitting application data will continue to be developed, there may eventually be problems that are currently found in MMS client compatibility. Thus, it is possible in the future that a MMS message received by an MMS client includes a header field with an application ID that it does not recognize (i.e., the MMS client receives content destined for an "upper layer" application that it does not support). In this case, the MMS client cannot forward the content to the correct "upper layer" application, and therefore, it is not certain how MMS operates in such a situation. Thus, the solution proposed by the Java community also has problems in terms of forwarding compatibility.

This problem is now solved by providing the network elements (e.g. MMS relay/server) participating in the messaging with information about which "upper layer" applications the destination user terminal supports, if any, and modifying the message to suit the capabilities of the user terminal, if possible.

Thus, according to a first aspect of the present invention, there is provided a method of processing a message addressed to a client terminal, the client terminal comprising a messaging client for processing the message, wherein the method comprises:

receiving a message addressed to the client terminal, the message comprising content destined for an "upper level" application, the "upper level" application being an application separate from the messaging client,

capability information about the client terminal is obtained,

checking whether the capability information includes information on "upper layer" applications supported by the client terminal, and

one or more actions responsive to the inspection phase are performed.

According to a second aspect of the present invention there is provided a network element for processing a message addressed to a client terminal comprising a messaging client for processing said message, wherein said network element comprises:

means for receiving a message addressed to the client terminal, the message comprising content destined for an "upper layer" application, the "upper layer" application being an application separate from the messaging client,

means for obtaining capability information about the client terminal,

for checking whether the capability information includes information on an "upper layer" application supported by the client terminal, an

Means for performing one or more actions responsive to the inspection phase.

The network element according to the invention may be, for example, an MMS (multimedia messaging service) relay/server or an MMSC (multimedia messaging service center).

According to a third aspect of the present invention there is provided a signal carrying capability information about a client terminal, the client terminal comprising a messaging client for processing messages, the capability information comprising information about "upper layer" applications supported by the client terminal, the "upper layer" applications being applications separate from the messaging client but using messages of the messaging client as a carrier for transporting application data.

The signal may be provided through a capability information storage unit such as a UAProf (user agent profile) server or through a client terminal.

According to a fourth aspect of the present invention there is provided a client terminal comprising a messaging client for processing messages, wherein the client terminal comprises means for providing information on the capabilities of the messaging client, the information on the capabilities of the messaging client comprising information on "upper layer" applications supported by the client terminal, the "upper layer" applications being applications separate from the messaging client but using the messaging client's messages as a carrier for transporting application data.

According to a fifth aspect of the present invention, there is provided a system comprising a destination client terminal including a messaging client for processing messages, and a network element for processing messages addressed to the client terminal, the destination client terminal and the network element being adapted to communicate with each other over a communications link, wherein the network element comprises:

means for receiving a message addressed to a destination client terminal, the message comprising content destined for an "upper layer" application, the "upper layer" application being an application separate from a messaging client of the destination client terminal,

means for obtaining information about capabilities of the destination client terminal,

means for checking whether said capability information comprises information about "upper layer" applications supported by the destination client terminal, and

means for performing one or more actions responsive to the inspection means.

According to a sixth aspect of the invention, there is provided a computer program executable in a network element according to claim 28.

According to a seventh aspect of the present invention there is provided a computer program executable in a client terminal unit according to claim 30.

The dependent claims relate to specific embodiments of the invention. The subject matter contained in the dependent claims relating to specific aspects of the invention can also be applied to other aspects of the invention.

The present invention provides a messaging system specific (e.g. MMS specific) solution for solving the backward and forward compatibility problems of applications involving the use of MMS (or some other message) as a carrier for the delivery of application data. The presented solution is therefore not dependent on the specific application. The solution according to embodiments of the present invention is advantageous for improving the user experience, since the handling/presentation of such content of MMS messages, which is not desired to be handled/presented by MMS clients, is reduced or avoided.

In some embodiments of the invention, the exact "upper level" application to which the destination client terminal supports the message content is verified. Thus, these embodiments are amenable to future development of new applications in the future.

Drawings

Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:

fig. 1 shows a simplified block diagram of an MMS messaging system;

FIG. 2 shows a signaling diagram for illustrating an embodiment of the present invention;

FIG. 3 is a flow chart illustrating operation of a network element according to an embodiment of the invention;

FIG. 4 shows a network element according to an embodiment of the invention;

FIG. 5 illustrates a profile information storage unit according to an embodiment of the present invention; and

fig. 6 illustrates a client terminal according to an embodiment of the present invention.

Detailed Description

In the following, the invention is described in connection with MMS messages and "upper layer" applications using or being able to use MMS as a carrier for transmitting application data. However, the invention is not limited to MMS systems, but can be applied in any other suitable messaging system using peer-to-peer "upper layer" applications.

One example of a suggested "upper layer" application is a Java application, but the invention may also be applied in connection with any other suitable "upper layer" application. Suitable application types include, for example, native Symbian OS (operating system) applications, native Microsoft Smartphone applications and applications on smart cards, for example, USAT applications (UMTS SIM application toolkit).

According to an embodiment of the invention, the MMS characteristics component of the UAProf (user agent profile) information is used to indicate which "upper layer" applications are supported by a specific MMS client or client terminal comprising an MMS client and/or whether such "upper layer" applications are fully supported. The UAProf specification includes schemas that contain attributes that describe, for example, client hardware, browser user agents, and network characteristics. Some attributes apply to MMS client characteristics and include attributes such as maximum supported size, maximum image resolution, supported content type, supported character set, supported language, and supported transport encoding. The use of MMS properties components for UAProf information is defined, for example, in Multimedia messaging service Client Transactions, version 1.2, candidate version 2003/9/16, open mobile alliance, OMA-MMS-CTR-v1_ 2-20030916-C.

According to this embodiment, a new attribute (or attributes) is introduced in the MMS properties component of the UAProf message. The new attributes indicate whether and/or which "upper" applications are supported at all. This provides the network (e.g. MMS relay/server or MMSC) with means for knowing whether the recipient MMS client supports "upper level" application features (or in particular certain applications), so that if it is found that the recipient MMS client does not support "upper level" application features or a particular target application, the network can e.g. modify, redirect or discard the message, or send an error report to the recipient and/or the sender of the MMS message (depending on the default actions of the service provider or user settings in the user profile).

For new MMS characteristics component attributes, at least three options can be identified:

1) a new attribute. The attribute indicates whether the MMS client supports the feature. The attribute type is expected to be "Boolean", and the possible "Boolean" attribute value is true/false or 0/1.

2) A new attribute. A possible attribute value is an application ID corresponding to an "upper layer" application supported by the MMS client. The presence of any value of the application ID indicates that the MMS client supports this feature. The attribute is desirably of the type "Literal bag" comprising a list of strings identifying different applications supported by the user terminal.

3) Two new attributes. The first new attribute indicates whether the MMS client supports this feature and the second new attribute lists the value of the application ID corresponding to the application supported by the user terminal. The attribute types are "Boolean" and "live bag", respectively, with possible "Boolean" attribute values being true/false or 0/1.

It must be noted that other attributes, attribute types and/or attribute combinations may also be used in accordance with the present invention.

Fig. 1 shows a simplified block diagram of an MMS messaging system. The system includes an MMS relay/server that acts as an intermediary in the transmission of MMS messages between the content/service provider 102, the client terminal 101 and the client terminal 100. The MMS relay/server is also connected to the UAProf server. It has to be noted that the system shown in fig. 1 is simplified and that a real system comprises a variety of other units. For example, the path between the MMS relay/server and the client terminal typically comprises a fixed line and a wireless part and may be implemented by a number of different units. Furthermore, other connections as shown in fig. 1 may be routed through different units in a practical system. The operation of the system of FIG. 1 is further discussed below in conjunction with FIG. 2.

Fig. 2 shows a signaling diagram for illustrating an embodiment of the present invention. An MMS message 200 to be delivered to a destination is sent by the source. The destination may be, for example, client terminal 100 of fig. 1, and the source may be client terminal 101 or content/service provider 103 of fig. 1. The MMS message 200 contains content destined for an "upper layer" application in the destination. The content may originate from a peer "upper level" application in the client terminal 101 (the MMS client of the client terminal 101 sending the MMS message) or from the content/service provider system 103.

The MMS message 200 is received at an MMS relay/server. Upon receiving the MMS message, the MMS relay/server sends a notification 201 of the received MMS message to the destination. The notification carries information about the received message, such as the source, subject, category, size, priority, and expiration date of the message. Upon receiving the notification 201, the destination sends (immediately or later) a request to the MMS relay/server to retrieve the MMS message 202 (MM 1_ notification.req and MM1_ retrieve.req messages implemented substantially in accordance with standard MMS for notification of the retrieval message and use of the request). The retrieval request also contains capability information identifying the capabilities of the destination device MMS client so that the MMS relay/server can modify the MMS message to suit the capabilities of the destination device. The capability information may be, for example, a pointer to a profile information source element, in this case a UAProf server. The pointer may be, for example, a URL (same resource locator). It is also possible that the MMS relay/server already knows the source of the capability information or that the MMS relay/server obtains the capability information from some other means than a specific profile information source unit. For example, the capability information may be obtained from a static table, or derived based on the device type or model number of the purpose.

The maintenance and updating of capability information in the UAProf server is done according to prior art methods and is therefore not discussed further here.

Once the MMS relay/server learns the source of the capability information, it sends a request for capability information related to the destination 203 to the UAProf server, which responds with the capability information 204. In phase 205 the MMS relay/server processes the MMS message. When the MMS relay/server receives the MMS message for the first time or when it receives a request from the destination to retrieve the message 202, it may have identified that the MMS message or part of its content is destined for an "upper level" application, or this may now occur at stage 205. Based on the capability information or characteristics of the MMS message, the MMS relay/server conditionally forwards the MMS message 206 to the destination with or without modification thereto (however, if the destination is not compatible with the content of the MMS message, the MMS message may not be sent to the destination at all). Different alternatives for handling messages containing "upper layer" application data are further described below in connection with fig. 3. Fig. 3 is a flow chart illustrating operation of a network element that is a messaging medium (e.g., the MMS relay/server of fig. 1 and 2) in accordance with an embodiment of the present invention.

First, the network element receives a content containing an application destined for an "upper layer" in a destination device, stage 300. For example, by following the Java Community recommendation described above: "WirelessMessaging API (WMA) for Java^TM2 Micro Edition ", Version 2.0, advanced Final Draft, Draft0.10a, 23/10/2003, new header fields introduced in JSR 205 expert group, identifying messages containing such.

Then, in phase 301, the network element obtains capability information about the destination device to which the message is destined. As described above in connection with fig. 2, the network element may request capability information from an appropriate source. Based on the capability information, the network element checks in stage 302 whether the destination device supports an "upper layer" application.

If the destination device supports an "upper layer" application, the procedure proceeds to stage 303, where it is checked whether the destination device supports the exact application for which the content in the message is destined.

If the destination device does support the "upper layer" application, the message is forwarded to the destination device without any modification thereto in stage 304. However, the network element may format the message in an appropriate manner if desired, but such formatting is not required due to the "upper layer" application content in the message.

If it is concluded in stage 302 or 303 that the destination device does not support an "upper layer" application at all or that the destination device does not support a related "upper layer" application, respectively, the procedure proceeds to stage 305. Here, the message may be discarded as not suitable for the destination device, or it may be modified so as to be suitable for the destination device and then forwarded to the destination device. Alternatively, the message may be redirected to some other destination, or the network element may simply stop the process of processing the message. The network element may also send an error report to the destination device informing the user that someone is trying to send it content that is not compatible with the device it is using. In addition to or instead of sending a notification to the destination, an error report may also be sent to the source of the message, e.g. another client terminal or content provider. In addition, the service provider providing the MMS message service may decide to handle in some other way the situation where the destination device does not support the destination application (in connection with sending an error report, e.g. the actual message may be discarded). Furthermore, in a network or content provider setting, a user profile or preferences/settings of the destination user (or sender) may have an impact on how the message is handled.

Now, as an example, a way of modifying a message in case the destination device does not support the target application is given. Even if the client does not have a "upper level" application involved, it may have some other "upper level" application that may be able to do some processing of the data contained in the message. For example, if the data contained in the message is text data in an XML (extensible markup language) format, it may be displayed in a general text editor. Thus, for example, in stage 305, the network element may modify the message so that it will be passed to some other "upper layer" application than the application to which it was originally destined.

It must be noted that the flow chart shown in fig. 3 may be modified in any suitable way. For example, stages 302 and 303 can be easily combined into one inspection stage depending on the implementation of the capability information. Furthermore, stages 303 or 302 may also be excluded from the flow entirely. Also, the actions of the MMS relay/server, MMSC or other network element in response to the capability information may be made implementation/service provider specific. In its user profile, the user may be provided with the possibility to set preferences for handling incompatible message content. The possible values of preference may be, for example, deleting, redirecting or modifying the message. However, a service provider may want to define what types of applications it is to support (person-to-person and/or content provider-to-person). To this end, the service provider may set certain default values/options in the user profile.

Fig. 4 shows a network element 400 according to an embodiment of the invention. Such a network element may be, for example, an MMS relay/server or an MMSC or some other network element that stores and forwards messages to a client device.

The network unit 400 comprises a processing unit 401 and an input/output module 403 connected to the processing unit 401. The processing unit 401 is also connected to a memory 402. The memory includes computer software executable in the processing unit 401.

According to the software, the processing unit controls the network element to receive a message addressed to the client terminal, the message comprising content destined to an "upper layer" application in the client terminal. The network element is controlled to obtain a capability message relating to the client terminal, to check whether the capability message contains application information about "upper layer" applications supported by the client terminal, and to perform a specific action depending on the result of the check. The specific action performed by the network element may be, for example, one of the following: modify the message, discard the message, redirect the message, send an error message, forward the message to the client terminal as is or with modification.

Fig. 5 illustrates a profile information storage unit 500 according to an embodiment of the present invention. The profile information storage unit may be, for example, a UAProf server.

The profile information storage unit 500 includes a processing unit 501 and an input/output module 503 connected to the processing unit 501. The processing unit 501 is also connected to a memory 502. The memory 502 comprises computer software executable in the processing unit 501, the UAProf information containing information about the capabilities of the various client terminals. In particular, the UAProf information in the memory 502 comprises application information about "upper level" applications supported by different client terminals, an "upper level" application being an application that uses or is able to use the messaging client's messages as a carrier for communicating application data.

According to the software, the processing unit controls the profile information storage unit to provide capability information of the specific client terminal upon request, and in particular, controls the profile information storage unit to provide application information relating to an "upper layer" application associated with the specific client terminal upon request.

Fig. 6 illustrates a client terminal 600 according to an embodiment of the invention. The client terminal may be, for example, a mobile phone, a personal information appliance, a laptop computer with communication capabilities or other communication device.

The client terminal 600 comprises an MMS client 601, an "upper" application 602, which uses messages of the MMS client as a carrier for transferring application data, and a radio unit 603. The MMS client receives and sends data to and from other devices via the radio unit 603 and passes the data back and forth to the application 602. The client terminal further comprises a memory (not shown), a processing unit (not shown) responsible for the computing operations performed in the client terminal, a user interface (not shown), typically comprising a display, a speaker and a keyboard by means of which the user can use the client terminal 600.

The memory of the client terminal includes software executable in the client terminal. The MMS client of the client terminal is controlled in accordance with software to provide information about the capabilities of the MMS client, including information about "upper layer" applications supported by the client terminal. This information may be provided, for example, as a pointer to a profile information store or as easy-to-use capability information.

The foregoing describes specific embodiments and examples of the present invention. It is obvious to a person skilled in the art that the invention is not restricted to details of the embodiments presented above, but that it can be implemented in other embodiments using equivalent means without deviating from the characteristics of the invention. The scope of the invention is only limited by the appended patent claims.

Claims (21)

1. A method for processing a message addressed to a client terminal, the client terminal comprising a messaging client for processing the message, the method comprising:

receiving a message addressed to the client terminal, the message comprising content destined for an upper layer application, the upper layer application being a separate application from the messaging client,

capability information about the client terminal is obtained,

checking whether the capability information includes information on upper layer applications supported by the client terminal, an

One or more actions responsive to the inspection phase are performed.

2. The method of claim 1, wherein the step of obtaining capability information comprises

Receiving a pointer to a profile information storage device from a client terminal, an

Retrieving the capability information from the profile information storage device.

3. The method of claim 1, wherein the step of obtaining capability information comprises

Easy-to-use capability information is received from a client terminal.

4. The method of claim 1, wherein the action comprises at least one of: modify the message, discard the message, redirect the message, send an error report, forward the message to the client terminal as is or with modification.

5. The method of claim 1, wherein, if the client terminal does not support any upper layer applications, the action comprises at least one of: the message is forwarded to the client terminal modified, the message is redirected, an error report is sent and a discard message is sent.

6. A method according to claim 1, wherein, if the client terminal does not support a particular upper layer application to which the message content is destined, the action comprises at least one of: the message is forwarded to the client terminal modified, the message is redirected, an error report is sent and a discard message is sent.

7. The method of claim 1, wherein, if the client terminal supports a certain upper layer application, the action comprises at least one of: the message is forwarded to the client terminal as is and the message is forwarded to the client terminal with modifications.

8. A method according to claim 1, wherein said action is to forward the message as is to the client terminal if said client terminal supports the particular upper layer application to which said message content is destined.

9. The method of claim 1, wherein the message originates from another upper layer application.

10. The method of claim 1, wherein the message originates from a content/service provider system.

11. The method of claim 1, wherein the message is an MMS multimedia messaging service message.

12. The method of claim 1, wherein the capability information is UAProf user agent profile information.

13. The method according to claim 1, wherein said information about upper layer applications comprises a "live bag" type attribute, said attribute comprising an application identification of the upper layer application supported by the client terminal.

14. A method according to claim 1, wherein said information about upper layer applications comprises a Boolean type attribute indicating whether a messaging client of the client terminal supports the upper layer applications.

15. A network element for processing a message addressed to a client terminal, the client terminal comprising a messaging client for processing the message, the network element comprising:

means for receiving a message addressed to a client terminal, the message comprising content destined for an upper layer application, the upper layer application being a separate application from a messaging client,

means for obtaining capability information about the client terminal,

means for checking whether the capability information includes information on upper layer applications supported by the client terminal, and

means for performing one or more actions responsive to the examining.

16. A network element according to claim 15, wherein the network element is an MMS multimedia messaging service relay/server or an MMSC multimedia messaging service centre.

17. A client terminal comprising a messaging client for processing a message, wherein the client terminal comprises

Means for providing information on capabilities of a messaging client, the information on capabilities of the messaging client comprising information on upper layer applications supported by the client terminal, the upper layer applications being separate applications from the messaging client but using messages for the messaging client as a carrier for transporting upper layer application data.

18. A client terminal according to claim 17, wherein said information about the capabilities of the messaging client is provided as a pointer to a profile information storage.

19. A client terminal according to claim 17, wherein said information about the capabilities of the messaging client is provided as easy-to-use capability information.

20. A system comprising a destination client terminal including a messaging client for processing messages and a network element for processing messages addressed to the client terminal, the destination client terminal and the network element being adapted to communicate with each other over a communication link, wherein the network element comprises:

means for receiving a message addressed to a destination client terminal, the message comprising content destined for an upper layer application, the upper layer application being an application separate from a messaging client of the destination client terminal,

means for obtaining capability information regarding the destination client terminal,

means for checking whether the capability information includes information on upper layer applications supported by the destination client terminal, and

means for performing one or more actions responsive to the inspection means.

21. The system of claim 20, wherein the destination client terminal comprises means for providing information about capabilities of the messaging client including information about upper layer applications supported by the destination client terminal.