CN100466824C - Method for restoring a link to a multimedia message stored on an MMS server that is unavailable on the MMS client via the MMS client - Google Patents

Abstract

For restoring via the MMS client (MUA) at least one missing, i.e. for example accidentally deleted on the MMS client to one or more multimedia messages (MM) stored on the MMS server (MRS) A method of linking (VK), and a communication device and network component. In order to restore at least one missing link (VK) to one or more multimedia messages (MM) stored on the MMS server (MRS) via the MMS client (MUA), send a message to the MMS server via the MMS client (MUA) (MRS) sends at least one request message (AN) with a request to send at least one missing link (VK) to one or more multimedia messages (MM). After receiving the request message (AN), at least one associated response message (WN) is sent to the MMS client (MUA) by the MMS server (MRS), and the response message contains missing information to one or more multimedia messages ( MM) at least one of the links (AN).

Description

Method for restoring a link to a multimedia message stored on an MMS server that is unavailable on the MMS client via the MMS client

technical field

The invention relates to a method, a communication device and a network component for restoring a link to one or more multimedia messages stored on an MMS server by an MMS client.

Background technique

The mobile radio system GSM (GSM—Global System for Mobile Communications) offers, in addition to voice telephony, the possibility of sending or receiving short text messages of up to 160 characters in length. This service is called SMS (SMS-Short Message Service) (see for example technical specification 3GPP TS 23.040, version 6.0.1).

MMS (MMS-Multimedia Messaging Service) was introduced as a successor to this well-established service (see also Technical Specifications 3GPP TS 22.140, Version 6.0.0 and TS 23.140, Version 6.0.0). This service can be used in different mobile radio systems, for example in GSM, GPRS (GPRS - General Packet Radio Service), EDGE (EDGE - Enhanced Data Rates for GSM) or UMTS (UMTS - Universal Mobile Telecommunications System) . The MMS service can realize mobile sending and mobile receiving of messages with multimedia content (such as text messages, voice messages or image messages). These messages may have a much larger data volume than SMS messages. Messages in MMS are also called Multimedia Messages (MM - Multimedia Messages).

A characteristic feature of MMS is the distinction between the so-called push and pull modes when transmitting one or more multimedia messages to an MMS recipient. In push mode, incoming multimedia messages are transmitted without delay by the responsible MMS network element to the MMS recipient (for example, to a GPRS mobile radio). In the so-called pull mode, the MMS recipient is initially informed only of multimedia messages arriving at the responsible MMS network element by means of MMS recipient notifications, so that the MMS recipient can decide for himself whether or when it wants to download the multimedia message. It has been shown in practice that customers and MMS service providers currently preferably use the pull mode in MMS. The multimedia message remains available on the responsible MMS network element until, for example, the MMS recipient downloads the multimedia message, or until the validity of the multimedia message expires. Alternatively, the multimedia message is deleted by the responsible network element. In order to be able to initiate the download process of the multimedia message via the MMS recipient, the MMS recipient receives a link to the corresponding multimedia message located on the corresponding MMS network element in the form of an MMS recipient notification. This link is called a URI (URI - Uniform Resource Identifier).

Therefore, it is urgently required according to the prior art that the MMS receiver retains a link to the multimedia message it wants to download at a subsequent moment. If the MMS recipient or the user inadvertently deletes, for example, the MMS recipient notification and/or also deletes the link before downloading the corresponding multimedia message, he will then no longer be able to access the multimedia message. A similar problem arises if the MMS recipient notification or the link to the multimedia message is first stored in the first terminal. The MMS recipient now changes his terminal and wants to access the corresponding multimedia message by means of a second terminal. This fact arises, for example, if the MMS recipient removes his mobile radio SIM card (SIM—Subscriber Identity Module) from a first mobile radio telephone and inserts it in a second mobile radio telephone.

If the mobile radio SIM card does not currently provide MMS support, the MMS recipient notification or link to the multimedia message only exists in the first mobile phone. Therefore, the MMS recipient notification or link to the multimedia message is not available in the second mobile radiotelephone. The same fact applies if one of the terminals is not a mobile radio telephone, ie, for example, the first terminal is a laptop and the second a PDA (PDA—Personal Digital Assistant).

Contents of the invention

The object underlying the invention is to provide a simple and efficient possibility of restoring at least one missing link to one or more multimedia messages in the form of MMS.

This task is solved by the following method according to the invention: a method for recovering at least one missing link to one or more multimedia messages stored on an MMS server by means of an MMS client, by means of said MMS The client sends to said MMS server at least one request message with a request for sending at least one missing link to one or more multimedia messages, and by: after receiving said request message Sending at least one corresponding response message to the MMS client via the MMS server, the response message containing at least one of the missing links to one or more multimedia messages, the request message being sent by the MMS client This is supplemented by a link criterion, which specifies at least one link to at least one multimedia message which is not taken into account by the MMS server when selecting the link to be transmitted.

The MMS client can restore one or more missing links to one or more multimedia messages at any time by means of the method of the invention. The method is scalable in the number of links that can be transmitted to MMS clients. A consistent request structure results from the transmission of not only a single link but also multiple links simultaneously in a single reply message. Based on the consistent request structure of the method, multiple missing links can then be combined in a single reply message and thus be transmitted bandwidth-efficiently. These advantages also result if the MMS client is replaced and therefore it is not necessary to restore one or more missing links.

The invention also relates to a communication device having a sending unit for sending at least one request message with a request to send at least one missing to one or more multimedia messages, wherein the request message is sent by the The MMS client is supplemented by link criteria, wherein at least one link to at least one multimedia message is specified that is not considered by the MMS server when selecting a link to be transmitted, and has a link for receiving at least one A receiving unit for a corresponding response message sent by the MMS server after receiving the request message, the response message containing at least one of the missing links to one or more multimedia messages.

Furthermore, the invention relates to a network component with a receiving unit for receiving at least one request message with a request to send at least one missing to one or more multimedia messages, the one or more multimedia messages The message is still available in the storage device on the network side, wherein the request message is supplemented by the MMS client via linking criteria, wherein the linking criteria to at least one multimedia message are specified in the selection to be transmitted. At least one link not considered by said MMS server when linking, with logic for generating at least one corresponding reply message with at least one missing link to one or more multimedia messages after receipt of said request message A unit, and a sending unit for sending at least one corresponding response message to the MMS client.

Description of drawings

In the following, the present invention and its improvements will be further described according to the accompanying drawings.

Figure 1 shows in schematic form an MMS server and an MMS client, and the message flow for pull mode, where the link to the multimedia message is notified to the MMS client by means of a notification message, and the client loads the multimedia message from the MMS server ,

Figure 2 shows in schematic form the MMS server and the MMS client, and the message flow according to the first embodiment of the method of the present invention, wherein the MMS client requests at least one link to at least one multimedia message by means of a request message, and at least one of the required links is sent to the MMS client by means of at least one reply message,

FIG. 3 shows in tabular form the MMS messages (PDUs—Protocol Data Units) with the names “M-Resend-Notification.conf” and “M-Resend-Notification.req” for the message flow of FIG. 2 according to OMA-compliant coding Several OMA-MMS header fields,

Figure 4 shows in tabular form the request message with the name "MM1_resend_notification.REQ" according to 3GPP syntax and its information elements in the message flow in Figure 2,

FIG. 5 shows in tabular form the response message with the name "MM1_resend_notification.RES" and its information elements according to the 3GPP syntax in the message flow of FIG. 2,

Figure 6 shows in tabular form the request message with the name "M-Resend-Notification.req" and its fields according to the OMA-MMS syntax in the message flow of Figure 2,

Figure 7 shows in tabular form the response message with the name "M-Resend-Notification.conf" and its fields according to the OMA-MMS syntax in the message flow of Figure 2, and

Fig. 8 shows in the form of a table according to the code according to OMA the request message with the name "X-Mms-Priority-Filter" according to the OMA-MMS syntax in the message flow of Fig. A possible extension of the " field.

In FIGS. 1 to 8 , elements with the same function and mode of action are assigned the same reference symbols.

Detailed ways

FIG. 1 shows a fragment of an MMS structure according to the current state of the art from the perspective of 3GPP. Thereby, the MMS service (MMS—Multimedia Messaging Service) (see Technical Specifications 3GPP (3GPP—Third Generation Partnership Project) TS 22.140, Version 6.3.0 and 3GPP TS 23.140, Version 6.3.0) is implemented. The MMS service enables the sending and receiving of messages with multimedia content. Such a message is also called a Multimedia Message MM and may comprise multiple MM elements of different file types (eg audio or video) and file formats (eg GIF or JPG). The MMS service can be used in various mobile radio systems, for example in GSM (Global System for Mobile), GPRS (GPRS—General Packet Radio Service) or also in UMTS (UMTS—Universal Mobile Telecommunications System).

Shown at the top left is the MMS server MRS, which is also called MMS relay/server in 3GPP. In addition, the MMS server MRS has the following tasks:

- storage of arriving multimedia messages MM, e.g. from other MMS servers,

- process and exchange verification information with the MMS client MUA,

- Receiving and sending multimedia messages MM from and/or to the MMS client MUA.

The MMS server MRS comprises a receiving unit EME1 for receiving verification information and/or multimedia messages MM. Furthermore, a sending unit SEE1 is provided for sending verification information and multimedia messages MM. There is a storage unit SER for storing multimedia messages MM and check information. The storage unit SER can optionally be connected to the MMS server MRS on the network side. Logical unit LEE1 controls the MMS server MRS. Finally, the connection network VX1 ensures the exchange of information between the individual units SEE1, LEE1, EME1 and SER.

It can also be seen in Figure 1 that the MMS client MUA. In 3GPP, this MMS client MUA is called MMS User Agent. The MMS client MUA is implemented, for example, as a software program on a mobile radio device according to the GSM standard or UMTS standard or on a device connected to the mobile radio device (eg a laptop). The MMS client has the task of implementing the parts of the MMS service that are required, for example, on the mobile radio. Alternatively, the MMS client MUA can also be implemented on an ISDN (Integrated Subscriber Digital Network) or in a computer unit connected to an intranet or the Internet.

The MMS client MUA comprises a receiving unit EME2 for receiving verification information and/or a multimedia message MM, and a sending unit SEE2 for sending verification information. Furthermore, there is a logic unit LEE2 for controlling the MMS client MUA and a connection network VX2 which ensures the exchange of information between the individual units SEE2, EME2 and LEE2.

Next, according to FIG. 1, the transmission of the multimedia message MM to the MMS client MUA according to the so-called pull mode will be further explained. After a new multimedia message MM has been received in the domain of the MMS server MRS, for example by a second MMS server MRS, this newly arrived multimedia message MM is stored in the network-connected storage unit SER. Next, the sending unit SEE1 of the MMS server MRS transmits the MMS recipient notification message NQN to the MMS client MUA. This MMS recipient notification message NQN is called MMS notification in 3GPP and includes a link VK to at least one multimedia message MM stored in a storage element SER connected on the network side. This link VK is also called URI (Uniform Resource Identifier) in 3GPP. After receiving the MMS Recipient Notification message NQN, the MMS client MUA confirms the receipt by means of the MMS Recipient Confirmation message NSN. The MMS client can now either immediately load the multimedia message MM on its device by means of the link VK, or temporarily store the MMS recipient notification message NQN and the link VK for later calling the multimedia message MM. This can be stored, for example, on a mobile radio SIM card (SIM—Subscriber Identity Module) or a mobile radio UICC (UICC—Universal Integrated Circuit Card) of the mobile radio equipment in which the MMS client MUA is located. In pull mode, the multimedia message MM is stored in the MMS server MRS until the validity expires. The MMS recipient notification message NQN also includes the validity period of the multimedia message MM. On expiry of the validity period, the multimedia message MM is deleted from the storage unit SER of the MMS server MRS together with the corresponding link VK.

After receiving an MMS recipient notification message NQN or a link VK to one or more multimedia messages MM, the MMS client MUA can later download one or more multimedia messages MM from the MMS server MRS. As can be seen in FIG. 1 , the MMS client MUA sends an MM request message RQN to the MMS server, the corresponding request message containing at least a link VK to the multimedia message MM to be downloaded. In case the requested multimedia message MM is still available on the MMS server MRS, the MMS server MRS sends the requested multimedia message MM to the requesting MMS client MUA by means of an MM reply message RSN. This process is also called "downloading".

In case the MMS recipient notification message NQN or the link VK to one or more multimedia messages MM does not reach the MMS client MUA, it is firstly impossible for the MMS client MUA to download the required multimedia messages MM from the MMS server MRS. This factual situation also arises after one or more links VK to one or more multimedia messages MM which have been sent to the MMS client MUA in the past have been lost due to inadvertent deletion.

In order to restore at least one link VK to at least one multimedia message MM, the MMS client MUA sends a request message AN to the MMS server MRS by means of its sending unit SEE2 according to the signal flow in FIG. 2 . The request message AN is received by the reception unit EME1 of the MMS server MRS and analyzed by the logic unit LEE1. If one or more multimedia messages MM are available to the requesting MMS client MUA in the storage device SER, the sending unit SEE1 of the MMS server MRS sends a corresponding reply message WN to the MMS client MUA. This reply message WN contains at least one of the missing links VK. In fact, it may also be reasonable that the reply message WN also contains one or more complete MMS recipient notification messages NQN. The MMS recipient notification message NQN may be a copy of the MMS recipient notification message NQN transmitted possibly in the past and also temporarily stored in the network-side storage device SER of the MMS server MRS. After receiving the corresponding reply message WN, the MMS client MUA can download one or more multimedia messages MM according to the received link VK. According to 3GPP syntax, a request message AN may be denoted by the name "MM1_resend_notification.REQ" and a corresponding reply message WN by "MM1_resend_notification.RES".

In practice, however, it is advantageous that instead of requesting all links VK of the multimedia messages MM contained on the MMS server MRS with the aid of the request message AN, a targeted selection is made. According to another alternative development of the invention, the request message AN is expanded by at least one filter criterion, wherein all multimedia messages MM of the link VK to be transmitted correspond to this filter criterion. Here, at least one of the following filter criteria FW is introduced, wherein the corresponding filter relates to one of the fields of the multimedia message MM:

a) Filter FAD for sender:

The specification of this filter enables the transmission of only links VK to multimedia messages MM which are sent from a specific sender address and thus from a specific sender.

b) Filter FEM for receiver:

The designation of this filter is such that only the link VK to the multimedia message MM is sent to the specific recipient address and thus to the specific recipient.

c) Filter FMM for message type:

By specifying the message type FMM only considers the link VK in which the corresponding multimedia message belongs to a specific class (for example class "advertisement").

d) Filter FDU for date and/or time:

This filter makes it possible to take into account only those multimedia messages MM which were sent on a specific date and/or time (for example on December 15, 2003) when selecting the link to be transmitted via the reply message WN.

e) Filter FPI for priority:

Only those multimedia messages MM corresponding to a specific priority are considered by this filter, for example only multimedia messages marked with priority "high".

f) Filter FTI for title:

By specifying this filter only multimedia messages MM are considered which contain certain titles or also special keywords in the titles.

In fact, it may also be advantageous that by means of the filter criteria FW not only selects certain criteria, but also excludes certain criteria. For this purpose, the filter criterion FW of the following filter is supplemented, for example, by a flag (eg label) which specifies whether a selection criterion and/or an exclusion criterion is involved:

-Filter FAD for sender

- Filter FEM for receiver

- Filter FMM for message types

- Filter FDU for date and/or time

- Filter FPI for priority

- Filter FTI for headers

Therefore, the request message AN may contain not only selection criteria but also exclusion criteria. For example, it is signaled by the request message AN that the multimedia message MM to be sought in consideration by the request message AN contains the word "track" in the title, but multimedia messages MM containing the title "railway" are excluded.

Furthermore, it may be reasonable to only request such links VK to one or more multimedia messages MM that are not available on the MMS client MUA. For this purpose, the link criterion VW contains one or more links VK, which are no longer signaled by means of the response request WN. Instead of a link VK, it is also possible to contain one or more MMS recipient notification messages NQN, which also guarantee a unique assignment to a specific link VK.

If necessary, it is also possible to use more than one filter criterion FW and/or link criterion VW in the request message AN. For this purpose, the individual filter criteria FW and/or link criteria VW can be associated with one another. Here "association" should be understood not only as a logical representation (such as "and", "or" or "exclusive or"), but also as a size representation (such as "greater than", "greater than - equal to", "less than" or "less than-equal"). In this embodiment, multimedia messages MM sent on three different days (eg on 2003.12.14, 2003.12.15 and 2004.1.1) should be considered. Thus, the request message AN may contain three different filter FDUs for date and/or time, which by means of the logical expression "or" enable the desired association "2003.12.15 or 2003.12.14 or 2004.1.1" .

FIG. 3 contains a possible implementation of the request message AN for the message flow of FIG. 2 with a filter in the form of a filter criterion FW and a link criterion VW in accordance with the syntax of 3GPP (see Technical Specifications TS 22.140, Version 6.3.0 and TS23. 140, version 6.3.0). In 3GPP, eg the request message AN might have the name "MM1_resend_notification.REQ". The individual information elements of Figure 3 will be further explored below, wherein the first column specifies the name of the corresponding information element, the second column shows the application of the corresponding information element within the request message AN, and the third column contains a short description:

- Information element "Message Type" MT1:

This information element must be contained in the request message AN and identifies this message as a request message, ie as a message with the name "MM1_resend_notification.REQ".

- Information element "Transaction ID" TA1:

This information element must be contained in the request message AN and is used to ensure a unique assignment between the request message AN and the reply message WN.

- Information element "MMS-Version" MV1:

This information element must be included in the request message AN, and specifies the version of the MMS interface of the MMS client MUA.

- Information element "Notification filter" FVK1:

Application of this information element within a request message is optional. This information element corresponds to the linking criterion FVK.

- Information element "Sender filter" FAD1:

Application of this filter criterion is not mandatory. This information element implements the filter FAD for the sender.

- Information element "Recipient filter" FEM1:

Application of this filter criterion is not mandatory. This information element implements the filter FEM for the receiver.

- Information element "Messge class filter" FMM1:

This is an optional information element. This information element implements a filter FMM for an information type.

- Information element "Date and time filter" FDU1:

This information element is optional and implements a filter FDU for date and/or time.

- Information element "Priority filter" FPI1:

Application of this element is optional. This information element identifies the information element corresponding to the filter FPI for priority.

- Information element "Subject filter" FTI1:

Application of this information element is optional and implements a filter FTI for headers.

All optional information elements can also be contained multiple times in the request message AN.

Another embodiment of the request message AN for the message flow of FIG. 2 can be seen in FIG. 4, which corresponds to the -MMS-CTR-v1_1-30021031-V" and "OMA-WAP-MMS-ARC-v1_1-20021101-C" syntax. In OMA, the request message AN is indicated by the name "M-Resend-Notification.req". In Fig. 4, the field names of the request message AN can be found in the first column, the corresponding field values can be found in the second column, and a short description of the function of the corresponding field is recorded in the third column. Include the following field names in the request message AN:

- Field name "X-Mms-Message-Type" MT3:

This field uniquely characterizes the PDU type (PDU - Protocol Data Unit) with the name "M-Resend-Notification.req" and must be included in the request message AN. Field values according to OMA syntax are:

"Message-type-value=m-resend-notification.req".

-Field name "X-Mms-Transaction-ID" TA3:

This field allows a unique assignment between a request message AN and one or more corresponding reply messages WN. But MUST be included in every request message AN. The corresponding field value is "Transaction-id-value".

-Field name "X-Mms-MMS-Version" MV3:

This field contains the version number of the MMS interface of the MMS client MUA and must be included in the request message AN. The field value of this field is "MMS-version-value".

- Field name "X-Mms-Notification-Filter" FVK3:

This optional field specifies a link VK to one or more multimedia messages not sent by the MMS server MRS. This corresponds to the linking criterion VW. Here, eg the Transaction-ID of a previously sent MMS recipient notification message NQN can be used as link VK, or eg a URI (URI - Uniform Resource Identifier) as link VK to at least one multimedia message MM. The value "Sender-filter-value" is used as the field value.

-Field name "X-Mms-Sender-Filter" FAD3:

This optional field defines the filter FAD for the sender. Also used as field value "Sender-filter-value".

-Field name "X-Mms-Recipient-Filter" FEM3:

This optional field defines the filter FAD for the receiver. Also used as field value "Receiver-filter-value".

- Field name "X-Mms-Message-Class-Filter" FMM3:

This optional field indicates the filter FMM for the message type. Also used as field value "Message-class-filter-value".

-Field name "X-Mms-Date-And-Time-Filter" FDU3:

Application of this field is optional. It allows specifying filter FDUs for date and/or time. The value "Date-and-time-filter-value" is used as the field value.

-Field name "X-Mms-Priority-Filter" FPI3:

Application of this field is optional. The filter FPI for prioritization is realized by means of this filter. The corresponding field value is "pritority-filter-value".

-Field name "X-Mms-Subject-Filter" FTI3:

This field specifies the filter FTI used for the title. Application of this field is optional. The value "Subject-filter-value" is used as the field value.

Optional fields may be used one or more times within the request message AN.

In the following, two exemplary embodiments of the reply message WN for the message flow of FIG. 2 are shown. A first example is listed in Figure 5, which corresponds to the 3GPP syntax (see 3GPP Technical Specification TS 22.140, Version 6.3.0). Here, the response message WN is represented by the name "MM1_resend_notification.RES", for example. In FIG. 5, for the reply message WN, possible information elements can be seen in the left column, their application in the middle column, and a short description in the right column. Possible information elements of the reply message WN according to 3GPP are as follows:

- Information element "Message Type" MT2:

Application of this information element is mandatory. This information element is used in order to uniquely label this message as a 3GPP Response Message WN with the name "MM1_resend_notification.RES".

- Information element "Transaction ID" TA2:

This information element is required in order to uniquely assign the response message WN to the request message AN. In fact, it is reasonable that the transfer identity "Transaction ID" TA2 corresponds exactly to the "Transaction ID" TA1 in Figure 3. Application of this information element is mandatory.

- Information element "MMS Version" MV2:

This information element specifies the version number of the MMS interface of the MMS server MRS. This information element must be included in every reply message WN.

- information element "Resend notification status" RS2:

This information element contains the status of the request for sending the desired link VK to one or more multimedia messages MM, which status was initiated by the request message AN. This status indicates, for example, whether the request was successfully processed by the MMS server MRS or whether some error occurred. This information element must be referenced in every reply message WN.

- Information element "Resend notification status text" TR2:

This information element reproduces in textual form the status achieved by means of the information element "ResendNotification Status" RS2. Application of this information element is optional.

- information element "Notification details" ND2:

This information element can be contained in the reply message WN. If this information element is present, at least one link VK to the multimedia message MM requested by the request message AN is reproduced. This takes place, for example, in the form of a list of initially sent MMS recipient notification messages NQN or in the form of corresponding URIs (Uniform Resource Identifiers).

A second exemplary embodiment of the response message WN according to the OMA syntax of the message flow of FIG. 2 can be seen in FIG. 6 (see also the OMA specification OMA-MMS-ENC-v1_2-20030915-C). In OMA, the reply message WN is denoted by the name "M-Resend-Notification.conf". In Figure 6, in the first column, the name of the corresponding OMA field can be found with the name "field name", the corresponding field value can be found in the second column, and the short name of the corresponding OMA field is in the third column describe. Each field of the response message WN according to the MOA is further described below:

- "X-Mms-Message-Type" MT4:

Application of this field is mandatory. It is able to uniquely identify the OMA message as a request message WN with the name "M-Resend-Notification.conf". According to OMA syntax, "Message-type-value=m-resend-notification-conf" is used as a field value.

-Field name "X-Mms-Transaction-ID" TA4:

This obligatory field allows a unique assignment of the response message WN to a specific request message AN. This is done by means of the field value "Transaction-ID-Value", which actually reasonably corresponds to "X-Mms-Transaction-ID" TA3 (see Figure 5), request message AN "M-Resend-Notification.req ".

- Field name "X-Mms-MMS-Version" MV4:

This is a required field. The field value "MMS-version-value" specifies the corresponding version number of the MMS interface of the MMS server MRS.

- Field name "X-Mms-Resend-Notification-Status" RS4:

This field MUST be included in every reply message WN. It specifies the status of the response message WN, which is achieved by the request message AN. The status is indicated by the field value "Resend-notification-status-value".

-Field name "X-Mms-Resend-Notification-Text" RT4:

This field contains a text description for the field with field name "X-Mms-Resend-Notification-Status" RS4. Application of this field is optional, and when used is indicated by the field value "Resend-notification-status-text-value".

- Field name: "X-Mms-Notification-Details" ND4:

This field may contain links VK to one or more multimedia messages MN. The corresponding MMS recipient notification message NQN according to the OMA standard is denoted by the name "M-Notification.ind". Alternatively, there may also be a URI (Uniform Resource Identifier). In addition to the link VK, other specifications (such as the priority of the multimedia message MM to which the link VK points or the address of the sender of the multimedia message MM) can also be included. The field value "Notification-details-value" is used as the value of this field.

According to another alternative embodiment, it is expedient to send more than one response message WN to the MMS client MUA based on the request message AN. Here, it is advantageous to use a unique group-identification signal GN for the message flow of FIG. 2 in all reply messages WN transmitted on the basis of the request message AN. Thus, for example, the corresponding transaction number "Transaction ID" of the request message TA2 is used as the unique group identification signal GN and entered in the field "Transaction ID" TA4 of the corresponding response message WN. Therefore, all reply messages WN generated based on the request message AN use the same transaction number TA4.

Furthermore, it is practically advantageous if each of the reply messages WN carrying the same unique group identification signal GN is assigned a consecutive message number NRN and a total number NGA for the message flow of FIG. 2 . Here, the total number NGA corresponds to the number of reply messages WN with the same group identification signal GN. For example, seven reply messages WN are transmitted with the same group identification signal GN. Here, the first reply message WN sent by the MMS server MRS to the MMS client MUA has a message number NRN equal to "1" and additionally a total number NGN of "7". The second reply message WN receives a consecutive message number NRN equal to "2" and again "7" as a total number NGA. Based on the consecutive message numbers NRN and the total number NGA, the MMS client MUA is enabled to uniquely determine the absence and possibly re-request of one or more reply messages WN.

According to a further advantageous embodiment variant, the reply message WN can be obtained directly from the MMS recipient notification message NQN which was transmitted to the MMS client MUA in the past. The MMS server MRS presets, for example, one or more MMS recipient notification messages NQN for the multimedia messages MM still available on its storage device SER. With a small modification, eg matching of the transaction number "transaction ID" TA4, this modified MMS recipient notification message NQN can be sent to the MMS client MUA as a reply message WN to the request message NQN.

A possible encoding of several fields of the request message AN and the response message WN according to the OMA-compliant syntax is described below with reference to FIG. 7 . In FIG. 7 , the field names of a plurality of fields are shown in the left column, which are also partially given in the left columns of FIGS. 4 and 6 . Enter the possible hexadecimal encodings in the middle column, and the possible OMA-compliant encodings of field values and supplementary notes in the right column. Hexadecimal encoding is employed in the OMA-MMS syntax to uniquely identify certain fields within a message. For example, the hexadecimal code 0x34 corresponds to a field with the field name "X-Mms-Notification-Filter" FVK. Below, the OMA-compliant encoding of several fields is described in more detail in Backus-Naur Form (BNF):

- Field name "X-Mms-Notification-Filter" FVK3:

The hex code for this field is 0x34. The corresponding value of this field is "Notification-filter-value=Text-string|Uri-value".

-Field name "X-Mms-Sender-Filter" FAD3:

The field value of this field is "Sender-filter-value=Encoded-string-value". The hex code is 0x35.

- Field name "X-Mms-Recipient-Filter" FMM3:

The field value of this field is "Recipient-filter-value=Encoded-string-value". The hex code is 0x36.

- Field name "X-Mms-Message-Class-Filter" FMM3:

The hex encoded value is 0x37. The corresponding field value includes "Message-class-filter-value=class-identifier|Token-textClass-identifier=personal|Advertisment|Information|Auto".

-Field name "X-Mms-Date-And-Time-Filter" FDU3:

The hex encoded value is 0x38. This field can be described by the following field values:

"Date-and-time-filter=Value-length(Absolute-token Date-

value|Relative-token Delta-seconds-value)

Absolute-token=<Octet 128>

Relative-token=<Octet 129>"

-Field name "X-Mms-Priority-Filter" FPI3:

0x3A was chosen as the hex-encoded value. This field can be described by the following field values:

"Priority-filter-value=Low|Normal|High

Low＝<Octet 128>

Normal=<Octet 129>

High=<Octet 130>"

-Field name "X-Mms-Subject-Filter" FTI3:

The hex encoded value is 0x39. This field is represented by the field value "Subject-Filter-Value=Encoded-String-Value".

- Field name: "X-Mms-Resend-Notification-Status" RS4:

The hex encoded value is set to 0x3B. The value of this field is represented by the following description:

"Resend-notification-status-value=Success|Error-

transient-failure|Error-permanent-failure|Error-

permant-service-denied

Success=<Octet 128>

Error-transient-failure=<Octet 192>

Error-permanent-failure=<Octet 224>

Error-permant-service-denied=<Octet 225>"

- Field name: "X-Mms-Resend-Notification-Text" RT4:

The hex coded value is 0x3C. The value of this field is represented by "Resend-notification-status-text-value=Encoded-string-value".

- Field name: "X-Mms-Notification-Details" ND4:

Choose a hexadecimal value of 0x3D for this field. Possible representations of field values for this field are:

"Notification-details-value=Value-length(X-Mms-Content-

LocationField From-Field Subject-Field X-Mms-Ddelivery-

Report-Field X-Mms-Message-Class-Field X-Mms-Priority-

Field X-Mms-Message-Size-Field X-Mms-Expiry-Field ect.)"

All fields referred to here are not necessarily included for the field value with the field name "X-Mms-Notification-Details". There is reasonably at least a field with the name "X-Mms-Content-Location" which contains the description of the URI (Uniform Resource Identifier) corresponding to the link VK to the multimedia message MM.

Furthermore, in practice it may also be advantageous to extend one or more filter criteria FW within the request message AN in such a way that, in addition to possible selection criteria, possible exclusion criteria are also defined. For this, an exemplary implementation is described below based on the OMA-MMS field "X-Mms-Priority-Filter" FPI3 according to the OMA syntax. This example should be understood in such a way that the application can be applied not only to specific fields, but also to all other filter criteria FW. In Figure 8, the field name of the corresponding field can be seen in the left column, the possible hexadecimal representation of the corresponding header field can be seen in the middle column, and the field A possible representation of the value. The field name "X-Mms-Priority-Filter" FPI3 can be hexadecimal-coded by the value 0x3A, for example. The following representations can be used as possible field values for this header field:

"Priority-filter-value=Pos-neg-value(Low|Normal|High)

Pos_neg-value=Positive|Negative

Positive=<Octet 128>

Negative=<Octet 129>

Low＝<Octet 128>

Normal=<Octet 129>

High=<Octet 130>".

With this expansion of the filter criteria FW, selection criteria and/or exclusion criteria can be used jointly in the request message AN.

Claims (13)

1. For recovering at least one missing link (VK) to one or more multimedia messages (MM) stored on the MMS server (MRS) by the MMS client (MUA), the method is: Send at least one request message (AN) to the MMS server (MRS) by the MMS client (MUA) with a link for sending at least one missing to one or more multimedia messages (MM) (VK) request, After receiving said request message (AN), at least one corresponding reply message (WN) is sent to said MMS client (MUA) by said MMS server (MRS), which contains the missing to one or at least one of a plurality of links (VK) of multimedia messages (MM), The request message (AN) is supplemented by the MMS client (MUA) by a linking criterion (VW), wherein by means of the linking criterion (VW) it is stated that to at least one multimedia message (MM) selected to be transmitted The link (VK) is at least one link (VK) that is not considered by said MMS server (MRS). 2. The method according to claim 1, characterized in that the missing link (VK) to the corresponding multimedia message (MM) has been transmitted to the MMS client at least once by the MMS server in the past ( MUA). 3. The method according to one of the preceding claims, characterized in that the MMS client (MUA) is used in a mobile radio device according to the GSM standard or UMTS standard, or in a fixed network according to the IDSN standard equipment, or to be used in computer units connected to an intranet or the Internet. 4. The method according to claim 1, characterized in that the request message (AN) is expanded by the MMS client (MUA) via at least one filter criterion (FW), wherein the corresponding link to be transmitted ( All multimedia messages (MM) of VK) comply with the filter criteria. 5. The method as claimed in claim 4, characterized in that the selection and/or exclusion criteria are defined by corresponding filter criteria (FW). 6. The method according to one of claims 4 to 5, characterized in that the filter criterion (FW) comprises at least one of the following fields about the multimedia message (MM): - sender address (FAD3), - recipient address (FEM3), - message type (FMM3), - date and/or time (FDU3), - priority (FPI3), - Title (FTI3). 7. The method as claimed in one of claims 4 to 5, characterized in that the corresponding linkage criteria (VW) and/or the corresponding filter criteria (FW) are associated with one another by means of a logical representation and/or a size representation. 8. Method according to the preceding claim 1, characterized in that a unique group identification signal (GN) is added to all reply messages (WN) to the corresponding MMS client (MUA) by the MMS server (MRS) ), the reply message is sent based on the request message (AN). 9. Method according to claim 1 above, characterized in that consecutive message numbers (NRN) and total quantity numbers (NGA) are added to all reply messages (WN) by the MMS server (MRS), wherein The total quantity number (NGA) corresponds to the total number of reply messages (WN) which were sent based on the corresponding request message (AN). 10. A method according to claim 1, characterized in that the request and/or response messages (AN, WN) used in the method are described by the syntax of the 3GPP Multimedia Messaging Service. 11. The method as claimed in claim 1, characterized in that the request and/or response messages (AN, WN) used in the method are described by the syntax of the OMA Multimedia Message Service. 12. A communication device (MUA) having a module for restoring at least one missing link (VK) to one or more multimedia messages (MM) stored on an MMS server (MRS) via an MMS client (MUA), - having a sending unit (SEE2) for sending at least one request message (AN) with a request to send at least one missing to one or more multimedia messages (MM), wherein said request message (AN ) is supplemented by the MMS client (MUA) by a link criterion (VW), wherein the link (VK) to at least one multimedia message (MM) is specified by the link criterion (VW) when selecting the link (VK) to be transmitted at least one link (VK) not considered by said MMS server (MRS), and - have a receiving unit (EME2) for receiving at least one corresponding reply message (WN) sent by the MMS server (MRS) after receiving said request message (AN), said reply message containing the missing to At least one of the links (VK) of one or more multimedia messages (MM). 13. A network element having a module for recovering at least one missing link (VK) to one or more multimedia messages (MM) stored on the MMS server (MRS) via the MMS client (MUA), - having a receiving unit (EME1) for receiving at least one request message (AN) with a request to send at least one missing to one or more multimedia messages (MM), said one or more multimedia messages (MM) The message is still available in the storage means (SER) on the network side, wherein the request message (AN) is supplemented by the MMS client (MUA) by linking criteria (VW), wherein by the linking criteria (VW ) to specify at least one link (VK) to at least one multimedia message (MM) that is not considered by said MMS server (MRS) when selecting a link (VK) to be transmitted, -Have a logical unit for generating at least one corresponding reply message (WN) having at least one missing link (VK) to one or more multimedia messages (MM) after receiving said request message (AN) (LEE1), and - Having a sending unit (SEE1) for sending at least one corresponding reply message (WN) to said MMS client (MUA).

Images