Informing recipient device of message content properties

RELATED APPLICATIONS

This application is a continuation of U.S. Pat. No. 8,321,954 (U.S. patent application Ser. No. 11/666,580 filed on Apr. 27, 2007 and US Publication No. 2009-0049559) issued to Miraj MOSTAFA and Titled INFORMING RECIPIENT DEVICE OF MESSAGE CONTENT PROPERTIES, which is a National Stage Entry of PCT Publication No. PCT/FI2004/000646 (Published as WO 2006/048492 with a priority date of Nov. 2, 2004) and Titled INFORMING RECIPIENT DEVICE OF MESSAGE CONTENT PROPERTIES, the entirety of which are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to informing a recipient device of message content properties.

BACKGROUND OF THE INVENTION

Short message services are very popular today. Besides text-based short messages, means are also required for transmitting multimedia data. A multimedia messaging service (MMS) is a service which has been developed for transferring messages with various content types, such as video, audio and images. The 3GPP (3^rdGeneration Partnership Project) specification TS 23.140 v. 6.7.0 <i>“Multimedia Messaging Service </i>(<i>MMS</i>); <i>Functional Description; Stage </i>2”, September 2004, describes the basic functions of the MMS.

A multimedia messaging service may be arranged in an environment comprising different network types. The 3GPP MMS environment may comprise 2G and 3G networks and provides all the necessary service elements for multimedia messaging, such as delivery, storage and notification functionality. An MMS relay/server is responsible for storage and handling of incoming and outgoing messages and for the transfer of messages between different messaging systems. An MMS user agent resides on a mobile terminal transmitting or receiving multimedia messages. The MMS user agent is an application layer function that provides users with the ability to view, compose and handle multimedia messages (MM).

Multiple content types may be transmitted by MMS. An MM describes the content type of the message, for instance “jpeg” in the case of an image in the jpeg format being transmitted. An originator user agent adds an identifier of a MIME (multi-purpose Internet mail extensions) content type of an MM to the MM PDU (packet data unit). The identifier of the MIME content type is transferred by an intermediate MMS relay/server to a recipient user agent.

The 3GPP MMS also supports content adaptation. A number of content classes is specified in an OMA (Open Mobile Alliance) specification “<i>MMS Conformance Document </i>1.2”, Candidate Version 27 Jul. 2004. The content classes illustrated in Table 1 define content categorizations. Each content class defines particular requirements which a user agent must support in order to support the content class. An identifier of one of the content classes may be included in an MM from an originator user agent if the content of the MM is in conformance with requirements of the content class. This content class identifier, as well as other content information, such as an indication of presence of DRM (Digital Rights Management) protection, may be provided by an originator MMS user agent to the MMS relay/server. The MMS relay/server may use this content class information for identifying whether an adaptation is necessary: On the basis of the recipient MMS user agent properties and the received content class the (recipient) MMS relay/server may define if an adaptation is required.

If a recipient terminal wishes to obtain details of the content of a received MM (besides the content type), it needs to perform analysis of the content, i.e. analyse the body part of the MM. This may be very complex process and requires time and processing resources.

BRIEF DESCRIPTION OF THE INVENTION

An object of the present invention is to provide an enhanced content property information solution. The objects of the invention are achieved by methods, network elements and mobile terminals which are characterized by what is stated in the independent claims. Some embodiments of the invention are disclosed in the dependent claims.

According to an aspect of the invention, a content class of a data set for a message to be transmitted to the recipient device is defined. A network element transferring messages to the recipient device specifies at least one information element in a message to the recipient terminal such that the information element comprises an indication of the content class. The message is transmitted to the recipient device.

According to another aspect of the invention, a network element transferring messages to the recipient device may define if a data set for a message to be transmitted to the recipient device comprises an element the usage of which is restricted. The network element specifies at least one information element in a message to the recipient terminal such that the information element comprises an indication of usage restricted content in response to the data set comprising one or more elements the usage of which is restricted. The message is then transmitted to the recipient device.

The term “data set” refers generally to any kind of set of information capable of being transmitted by messaging to the recipient, and may include multiple media types. The term “content class” refers generally to information associated with one or more requirements that the data set fulfils without being limited to content classes specified for the 3GPP MMS. It is also to be noted that the definition of a content class of a data set or definition of application of usage restriction in a data set is to be understood generally to refer to any kind of activity on the basis of which information of the content class or on the application of usage restriction can be obtained. Similarly, the specification of an information element comprising an indication of the content class or an information element comprising an indication of usage restricted content is to be understood generally to refer to any kind of activity producing this information for a message to be transmitted to the recipient device. For instance, this information may be indicated in a received message, and the information may be simply copied to the message to be transmitted.

An advantage of this aspect of the invention is that an indication of a content type and/or an indication of usage right controlled content may be delivered to a recipient terminal. The recipient terminal may, on the basis of the indication, easily detect the content class to which the received content belongs to and/or if the use of the content is restricted. This is important for devices with relatively small memory/processing resources, such as many mobile phones. Further, as less processing of a received message is required, less battery resources are consumed.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following some aspects of the invention will be described in greater detail by means of some embodiments with reference to the accompanying drawings, in which

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating a multimedia messaging system;

<figref idref="DRAWINGS">FIG. 2</figref> is a flow diagram illustrating a method according to an embodiment of an aspect of the invention;

<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram illustrating a method according to an embodiment of an aspect of the invention;

<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram illustrating a method according to an embodiment of another aspect of the invention;

<figref idref="DRAWINGS">FIG. 5</figref> is a flow diagram illustrating a method according to an embodiment of another aspect of the invention; and

<figref idref="DRAWINGS">FIG. 6</figref> is a table describing exemplary headers for multimedia messages.

DETAILED DESCRIPTION OF SOME EMBODIMENTS OF THE INVENTION

Some embodiments of the invention will be described in the following in a system supporting the 3GPP multimedia messaging service (MMS); it should, however, be noted that the application of the invention is not restricted to such systems.

<figref idref="DRAWINGS">FIG. 1</figref> shows an example of architectural elements in an MMS environment. A mobile terminal <b>10</b> comprises an MMS user agent <b>11</b> taking care of MMS related functions in the user terminal <b>10</b>. A mobile phone, a laptop computer equipped with a transceiver, or a PDA (Personal Digital Assistant) device could serve as the terminal <b>10</b>. It is to be noted that the MMS agent <b>11</b> could reside in an external device connected to the terminal <b>10</b>. The MMS agent <b>11</b> is arranged to retrieve multimedia messages by initiating MM delivery and to negotiate terminal capabilities with an MMS server/relay element <b>20</b>. Thus, the MMS agent <b>11</b> needs to be capable of at least receiving multimedia messages. The MMS agent <b>11</b> may further be arranged to compose multimedia messages, submit multimedia messages to the MMS server/relay element <b>20</b>, present multimedia messages, and present notifications of multimedia messages to the user, for instance. The terminal <b>10</b> comprises a transceiver for communicating with a mobile network <b>30</b>. For instance, the mobile network <b>30</b> may be a network supporting GSM services, a network supporting GPRS (General Packet Radio Service) services, a third-generation mobile network, such as a network according to the network specifications of the 3GPP, or a network supporting a plurality of telecommunications techniques. In the case of the 3GPP compliant mobile terminal, the terminal <b>10</b> may also be referred to as a user equipment (UE) or a mobile station (MS).

A network element <b>20</b> comprising the MMS server <b>21</b> and MMS relay <b>22</b> functionality is connected to the mobile network <b>30</b>, or in an alternative embodiment it is included in some network element of the mobile network <b>30</b>. The MMS relay/server <b>21</b>, <b>22</b> may be a single logical element or may be separated into MMS relay and MMS server elements, possibly residing in separate devices. The MMS relay/server element <b>20</b> provides the following functionalities: receiving and sending of multimedia messages, conversion of messages to multimedia message format (for instance from facsimile to MM), conversion of multimedia messages to other message formats, message content retrieval, multimedia message notification to the MMS user agent <b>11</b>, generation of delivery reports, routing of multimedia messages and read-reply reports, address translation, temporary storage of multimedia messages, and digital rights management (DRM) functionalities. The MMS relay/server element <b>20</b> may provide additional functionalities such as generation of charging data records (CDR), negotiation of terminal capabilities, or media type/media format conversion on the basis of the capabilities of the recipient terminal <b>10</b>. The MMS server/relay element <b>20</b> may be connected to other networks, such as the Internet <b>50</b> and other mobile networks <b>30</b>. The MMS environment may also comprise specific data storages <b>40</b>, for instance a message store for temporary storing of multimedia messages and a user database comprising user specific data. One such user database is a home location registry (HLR) of a 3GPP mobile system. The MMS server/relay element <b>20</b> may also be connected to other devices and functions, for instance to MMS value added services (VAS) applications. An IP network <b>50</b> may be used to communicate with roaming MMS user agents <b>11</b> or wired e-mail clients, for instance. Although not shown in <figref idref="DRAWINGS">FIG. 1</figref>, the MMS system may comprise an MMS proxy-relay for transferring multimedia messages. For more details on already specified MMS environment and MMS functions in the user agent <b>11</b> and the MMS server/relay element <b>20</b>, reference is made to the 3GPP specification TS 23.140 v. 6.7.0 <i>“Multimedia Messaging Service </i>(<i>MMS</i>); <i>Functional Description; Stage </i>2”, September 2004, in particular Chapters 5-7.

The mobile terminal <b>10</b> and the MMS server/relay element <b>20</b> comprise memory, a transceiver for arranging data transfer, and a processing unit comprising one or more processors. Computer program codes executed in the processing units may be used for causing these devices <b>10</b>, <b>20</b> to implement means for providing inventive functions relating to arranging utilization of content properties, some embodiments of the inventive functions being illustrated below in association with <figref idref="DRAWINGS">FIGS. 2 to 6</figref>. In one embodiment a modified MMS user agent <b>11</b> and a modified MMS server <b>21</b> and/or relay <b>22</b> perform at least some of the inventive functions illustrated below. The modifications may be implemented by specific program code portions in a software for implementing the MMS user agent <b>11</b> and MMS server <b>21</b> and/or relay <b>22</b>. However, it is to be noted that the inventive functions may be performed by some other entity.

A chip unit or some other type of module for controlling the device <b>10</b> and/or <b>20</b> may, in one embodiment, cause this device <b>10</b> and/or <b>20</b> to perform the inventive functions. The module may form part of the device <b>10</b> and/or <b>20</b> and could be removable, i.e. it could be inserted into another unit or device. Computer program codes can be received via a network and/or be stored in memory means, for instance on a disk, a CD-ROM disk or other external memory means, where from they can be loaded into the memory of the data processing devices <b>100</b>, <b>200</b>. The computer program can also be loaded through a network by using a TCP/IP protocol stack, for instance. Hardware solutions or a combination of hardware and software solutions may also be used to implement the inventive functions.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates a method according to an embodiment of the invention relating to utilization of content classes. The method illustrated in <figref idref="DRAWINGS">FIG. 2</figref> may be applied in an intermediate element transferring messages to a recipient, in the present embodiment in a (recipient) MMS server/relay element <b>20</b> transmitting multimedia messages to a recipient MMS agent <b>11</b>. A content class is associated with one or more requirements, which a data set (forming at least part of the content of a multimedia message) has to fulfil in order to belong to or to be associated with the content class. A predetermined group of content classes is specified in the system such that at least most of transferred multimedia messages would belong to some content class. In step <b>201</b> a message is received. The message may be a multimedia message or other type of message the contents of which are to be transferred as a multimedia message to the recipient terminal <b>10</b>. The message may be received from an originator MMS user agent (<b>11</b>), another (originator) MMS server/relay element (<b>20</b>) if the originator of the message resides in an area of another MMS server/relay element <b>20</b>, or another content provider that may be outside the MMS environment. A content class of the content of the message is defined in step <b>202</b>. It is to be noted that, in an alternative embodiment the content class of only some of the content of the message received in step <b>201</b> could be defined in step <b>202</b>. The content class may be defined in step <b>202</b> on the basis of a content class indication in the received message. Thus, the MMS relay/server element <b>20</b> may be arranged to check an information element indicating the content class in order to define the content class in step <b>202</b>. Alternatively, the content class is defined <b>202</b> on the basis of an analysis of the content or on the basis of a modification to the content. In one example the MMS server/relay element <b>20</b> may perform an adaptation of the content of the received message and specify an appropriate content class for the content as adapted.

An indication of the content class is specified in step <b>203</b> in a message to be transmitted to the recipient terminal <b>10</b>. This step may be part of formation of the MMS PDU comprising the contents of the message as received in step <b>201</b>. In one embodiment a specific header comprising the indication of the content class is added to the PDU in step <b>203</b>. After the preparation of the message, the message may be transmitted to the recipient device, in the present embodiment to the terminal <b>10</b> comprising the MMS agent <b>11</b>. It is to be noted that the transmission may require a specific request from the recipient terminal <b>10</b>, for instance after a notification of the received message from the MMS server/relay element <b>20</b>.

<figref idref="DRAWINGS">FIG. 3</figref> illustrates an embodiment relating to the same aspect as <figref idref="DRAWINGS">FIG. 2</figref>, i.e. to the utilisation of content classes. The method illustrated in <figref idref="DRAWINGS">FIG. 3</figref> may be applied in a recipient device, in the present embodiment in the terminal <b>10</b> comprising the MMS agent <b>11</b>. In step <b>301</b> a multimedia message is received. A content class of the received multimedia message is checked <b>302</b>. In one embodiment the content class is defined by checking the contents of a specific MMS header indicating at least one content class associated with the multimedia message.

The recipient device <b>10</b> may be arranged to adapt the processing of the message content in accordance with the content class defined in step <b>302</b>. The processing is to be understood broadly to cover one or more further actions relating to the message content, for instance storing of the content, presenting the content, or modifying the content. Thus, the content class indicated in the message may have impact on further actions on the message content. In the embodiment of <figref idref="DRAWINGS">FIG. 3</figref>, the processing of the message content is adapted on the basis of a check for support of the content class.

In step <b>303</b> the terminal <b>10</b> checks if the content class is supported. In one embodiment this step <b>303</b> is performed by comparing the content class defined in step <b>302</b> to predetermined content classes specified as supported by the terminal <b>10</b>. The predetermined supported content classes may have been specified on the basis of the properties of the terminal <b>10</b>, for instance screen properties and supported applications in the terminal <b>10</b>, and could be stored in a specific terminal capability file, for instance. If the content class of the received message is supported, the message may be further used <b>304</b> in the terminal <b>10</b> as appropriate. Typically, the content of the message is presented and stored.

In one embodiment, the presentation of a media object may be prepared (in step <b>304</b>, for instance) on the basis of the detected content class, i.e. early processing may be invoked before presentation of the content on the basis of the detected content class. For instance, a video player is invoked for a message the content class of which indicates a content class for video, whereas for a message indicating a text content class no media player is required.

In another embodiment the terminal <b>10</b> is arranged to store the message content in accordance with the identified content class: there could be content class specific storage positions in the terminal <b>10</b>. For instance, contents of a received MM with a content class for images are stored in a specific folder for images. The message content may also be further modified.

If the content class is not supported, in the present embodiment the terminal <b>10</b> is arranged to determine <b>305</b> if an adaptation of the content is available. The adaptation may be used to alter the content of the received message such that the content would be presentable in the recipient terminal <b>10</b>. If no adaptation is available, the message content may be discarded or only some of the content is used. It is to be noted that in step <b>307</b> the message could be stored although it is not possible to present the contents of the message as such. If appropriate adaptation is available, content adaptation into a presentation format or a class supported by the recipient terminal <b>10</b> may be performed in step <b>306</b>.

<figref idref="DRAWINGS">FIGS. 4 and 5</figref> illustrate another aspect of the invention, namely the indication of DRM protection in a message to the recipient. <figref idref="DRAWINGS">FIG. 4</figref> illustrates functions that can be applied in an intermediate device such as the MMS server/relay element <b>20</b>. In step <b>401</b> a multimedia message or another type of message (to be transmitted as multimedia message to a recipient) is received. The content of the message may be checked in step <b>402</b> in order to define if DRM protection is applied for any portion of the message content. For this purpose a body part of the received message may be analysed in step <b>402</b>. In an alternative embodiment a specific header or other type of information element in the received message indicating the presence of DRM protection is checked in step <b>402</b> in order to define if at least part of the message content is DRM protected. If DRM protection is applied on the basis of the check <b>402</b>, <b>403</b>, an indication of DRM protection is specified in step <b>406</b> in a multimedia message to be transmitted to the recipient terminal <b>10</b>. In one embodiment, a specific header comprising an indication of DRM protection is added into an MMS PDU comprising the content of the received message. Alternatively, if DRM protection is not applied in the content of the received message, a multimedia message for the recipient may be prepared <b>404</b> without an indication of DRM protection. In an alternative embodiment the message is prepared in step <b>404</b> such that it specifically indicates that no DRM protection is applied in the message content. After steps <b>404</b> or <b>406</b> the message may be transmitted <b>407</b> to the recipient terminal <b>10</b>.

<figref idref="DRAWINGS">FIG. 5</figref> illustrates functions that can be applied in a recipient device, in the present embodiment in the terminal <b>10</b> comprising the MMS agent <b>11</b>. In step <b>501</b> a multimedia message is received. The recipient terminal <b>10</b> is arranged to check in step <b>502</b> if the message comprises an indication of DRM protection. Similarly as described in association with <figref idref="DRAWINGS">FIG. 3</figref> and step <b>302</b>, there are alternative embodiments for arranging the indication of this content property to the recipient terminal <b>10</b>. In one embodiment, a specific header of the multimedia message is checked in step <b>502</b>.

On the basis of steps <b>502</b>, <b>503</b>, the terminal <b>10</b> may be arranged to adapt one or more further actions on the content or part thereof of the received message in response to the information element indicating data protection. If DRM protection is applied on the basis of check <b>502</b>, <b>503</b>, a DRM activity may be initiated in step <b>504</b>. For instance, the MMS agent <b>11</b> may invoke a DRM client in the terminal <b>10</b> for handling the DRM protected content of the received message. The DRM client may then encode, decode, and/or store the DRM-protected content, for instance. For more details on DRM functions and available usage restrictions provided by these functions, a reference is made to OMA DRM specifications. Thus, the recipient terminal <b>10</b> may be arranged to adapt the further processing of at least some of the message content by initiating a DRM process. In one scenario the message comprises a locked (encrypted) media object such as a music video presentation, which can only be unlocked (decrypted) by an unlocking (decryption) key obtained by a licensing procedure with an external licensing server. The procedure for obtaining the license and the unlocking key may be initiated on the basis of the DRM protection indication in the received message.

Alternatively, if no DRM protection is applied, the message content may be used as appropriate without any specific DRM functions in step <b>505</b>. Typically the message content is presented and stored.

In one embodiment the MMS server/relay element <b>20</b> is arranged to check if the received message (after step <b>201</b> and/or step <b>401</b>) comprises an indication of the content class and/or the DRM protection. This checking may be performed by analysing the header portions of the received MMS submission PDU. If the message comprises such indication, the MMS server/relay element <b>20</b> may be arranged (in step <b>202</b> in the case of the embodiment of <figref idref="DRAWINGS">FIG. 2</figref> or in step <b>404</b> or <b>406</b> of the embodiment of <figref idref="DRAWINGS">FIG. 4</figref>) to copy at least one header comprising such indication from the received submission message to the retrieval/delivery PDU to the recipient terminal <b>10</b>. Thus, the MMS relay/server element <b>20</b> is not required to generate the information by itself, whereby the load on the MMS relay/server element <b>20</b> is not expected to increase. If there is no indication of DRM protection and/or content class, the MMS server/relay element <b>20</b> may be either arranged to analyze the content of the received PDU to determine this information on applied content class and/or DRM protection or omit the indication of content class and/or DRM protection in the retrieval/delivery PDU to be transmitted to the recipient terminal <b>10</b>.

In a similar fashion as in the embodiment above, also the terminal <b>10</b> comprising the MMS user agent <b>11</b> may be arranged to perform a checking step for the indication of the content class and/or the application of DRM protection (in step <b>302</b>/<b>502</b>, for instance). If no indication is available, the terminal <b>10</b> could proceed (instead of step <b>303</b>/<b>503</b>) to analyse the content of the received message in order to identify the content class and/or the application of DRM protection.

In one embodiment an indication of the content class and/or the application of DRM protection is specified in an MMS header of a transmitted MM PDU. Thus the MMS server/relay element <b>20</b> is arranged to add at least one MMS header comprising the indication of the content class and/or the DRM protection. In an alternative embodiment the indication of the content class and/or the application of DRM protection is specified in a notification message informing the recipient terminal <b>10</b> on a received MM. Thus, the content of the received message and the indication may be transferred in separate messages. On the basis of the content class indication and/or indication on the application of DRM protection the recipient terminal <b>10</b> may, instead of the embodiments illustrated above in connection with <figref idref="DRAWINGS">FIGS. 3 and 4</figref>, determine whether to request the transmission of the message content from the MMS server/relay <b>20</b>.

<figref idref="DRAWINGS">FIG. 6</figref> describes exemplary new header fields for 3GPP MMS system. These new header fields may also be specified in OMA MMS specifications. The header field “X-Mms-Content-Class” may be used for indicating the content class value. The value of this header “X-Mms-Content-Class” could, depending on the applied classification, provide information about an applicable media type/format, maximum size, maximum resolution of image/video, applicable presentation mechanism, and/or an applicable DRM-method. The header field “X-Mms-DRM-Content” may be used to indicate the presence of DRM content. This header field could simply have the value ‘Yes’ or ‘No’. The headers are optional, as some messages may not belong to any content class, and some message may not contain any DRM-protected content or are not available for the MMS server/relay element <b>20</b>. It should be noted that there are also many alternative ways for indicating the content class and/or the DRM protection. For instance, a single header could be used. The presence of DRM content could also be further specified, for instance by indicating content elements that are DRM protected.

In another embodiment the content class is pre-associated with more detailed information on the DRM protection method or type. Thus, on the basis of a detected more detailed information, the recipient terminal <b>10</b> may be arranged to adapt further DRM procedures in/after step <b>504</b> of <figref idref="DRAWINGS">FIG. 5</figref>. For instance, the content class may specify the use of prevention of forwarding (Forward Lock), whereby the forwarding of the content is prevented in the terminal <b>10</b>. Other exemplary DRM protection methods, which could be indicated in the DRM header field of <figref idref="DRAWINGS">FIG. 6</figref> or in other kind of DRM indication headers, are Combined Delivery and Separate Delivery. It is to be noted that the applicable usage restriction methods are not limited to the DRM methods but any kind of usage restriction may be indicated to the recipient terminal <b>10</b>. For instance, time specific restrictions, user restrictions, user group restrictions, financial restrictions, device restrictions, or application restrictions could be indicated.

As already mentioned, a content class is associated with or specifies one or more requirements, which a data set (which is part of the content of a multimedia message or the message as a whole) fulfils. The requirements may be specified as appropriate to classify transferred data in order to support interoperability between devices. Thus transferred (payload) data sets with similar properties would be associated with same content class. Some exemplary requirement categories which may be applied and indicated in one embodiment in the header of <figref idref="DRAWINGS">FIG. 6</figref> are: size of content, text format of the content, image format of content, bitmap format of the content, video format of the content, audio format of content, PIM (Personal Information Management) format of the content, DRM protection mode of the content, and presentation format of the content. For instance, a maximum size of ≦30 kB is a requirement for a basic image class. Thus, a message comprising an image cannot be more than 30 kB in order to be associated (for instance by the MMS server/relay element <b>20</b> in step <b>202</b>) with the basic image class. Further, the recipient terminal <b>10</b> is aware of the requirements associated with or specified by different predetermined content classes. After identifying the content class, the terminal <b>10</b> may initiate appropriate further actions on the basis of the content class of the received message. For instance, if a message associated with the basic image class is received, the terminal <b>10</b> may determine if it has enough available memory space for storing the message. If not, the user may be notified and/or available memory space may be increased if possible, for instance.

In one embodiment at least some of the following content classes are utilized to classify the content: text, image-basic, image-rich, video-basic, video-rich, megapixel, content-basic, content-rich. However, the indication of content types is not limited to any specific content types. In one embodiment the properties specified in Chapter 7 of the OMA specification “<i>MMS Conformance Document </i>1.2”, Candidate Version 27 Jul. 2004 are utilized in the classes text, image-basic, image-rich, video-basic, and video-rich. Referring to the embodiment of <figref idref="DRAWINGS">FIG. 6</figref>, the header field “X-Mms-Content-Class” may thus have one of these values. For instance, predetermined specific binary values for each of these content classes may be applied, on the basis of which the MMS user agent <b>11</b> and the MMS relay/server functions <b>21</b>, <b>22</b> define and identify the content classes of multimedia messages.

It should be noted that the embodiments described above could also be applied in any combination thereof. It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.