TWI394480B - Method for the recovery of at least one lost link to one or a plurality of multimedia messages stored on an mms server by an mms client, a communication device and a network component - Google Patents

Description

Method, communication device and network component for recovering at least one lost link by an MMS client to one or more multimedia messages stored on an MMS server

The mobile radio system GSM (Global System for Mobile Communications) can simultaneously provide voice telephony technology and transmit and receive essay messages of up to 160 words. This type of service is called SMS (Short Message Service), for example, see the document of Technical Specification 3GPP TS 23.040 version 6.0.1.

The Multimedia Messaging Service (MMS) is a follow-up service initiated under this highly successful service. For example, see Technical Specification 3GPP (3rd Generation Partnership Project) TS22.140 Version 6.0.0. and 3GPP TS23. 140 version 6.0.0. of the document. This service can be used on different mobile radio systems such as GSM, GPRS (Generally Decapsulated Radio Service), EDGE (Enhanced Data Rate for GSM Evolution) and UMTS (Universal Mobile Radiocommunication System). The MMS service allows for the transmission of mobile and mobile reception of messages with multimedia content such as text messages, voice messages and picture messages. The data capacity of such messages is significantly larger than the data capacity of SMS messages. The message in the MMS is called the multimedia message MM.

The characteristic nature of MMS is that when one or more multimedia messages are delivered to the recipient of the MMS, a distinction is made between the so-called push mode and the pull mode. In push mode, the MMS will immediately transfer the incoming multimedia message from the network element responsible for the MMS to an MMS receiver such as a GPRS mobile radio. Initially, only the MMS receiving notification informs that the existing multimedia message arrives in the so-called extraction mode of the network component responsible for the MMS, and then the recipient of the MMS can decide whether or not to download the multimedia message. In fact, the current customer and MMS service has been proven The preference is to use the MMS extraction mode. If the multimedia message can be retained in the network element responsible for the MMS until, for example, the recipient of the MMS downloads or the validity of the multimedia message expires. Alternatively, the multimedia message can be deleted by the network element responsible for the MMS. In order to enable the recipient of the MMS to initiate a download of the multimedia message. The recipient of the MMS will receive a link to the corresponding multimedia message on the affiliate MMS network element in the MMS receipt notification. This type of connection is called a URI (Uniform Resource Identification Code).

Therefore, according to the conventional design, the MMS recipients are basically provided with links to multimedia messages that they may want to download later. If the MMS recipient owns or the user unintentionally deletes an MMS acceptance notification and/or the link, for example, before downloading their affiliated multimedia message, they will no longer be able to access the multimedia message. If the MMS recipient initially informs the MMS of the multimedia message or stores the link in the first terminal, and then wants to use the second terminal to access the corresponding multimedia message after changing the terminal, a similarity occurs. The problem. This situation also occurs when the MMS recipient removes the Mobile Radio Subscriber Identity Module (SIM) card from the first mobile radiotelephone and inserts it into the second mobile radiotelephone. If the mobile radiotelephone SIM card no longer supports MMS, then the MMS accepts the notification or the link only exists in the first mobile radiotelephone. Therefore, the MMS acceptance notification or the link cannot be obtained in the second mobile radiotelephone. The same situation also occurs when one of the terminals is not a mobile radiotelephone, such as when the first terminal is a laptop and the first terminal is a number of assistants. (PDA).

It is an object of the present invention to provide a simple and efficient method for recovering that at least one of one or more multimedia messages within an MMS has lost connectivity.

This object of the invention can be achieved by a method for recovering at least one of one or more multimedia messages stored by an MMS client on an MMS server that has lost connectivity, characterized in that the MMS client will at least A request message with a lost connection requesting to send one or more multimedia messages is sent to the MMS server, and is characterized in that the MMS server will have at least one multimedia message or ones when receiving the request message. At least one of the affiliated reply messages that have lost the link is transmitted to the MMS client.

In the method of the present invention, the MMS client can resume one or more of the lost one or more multimedia messages at any time as needed. The method can be augmented according to the number of links to be delivered to the MMS client. The standard request structure allows us to simultaneously transmit a single link and multiple links in a single reply message. The standard request structure of the method means that a plurality of lost links can be combined in a single reply message and thus can be transmitted in a manner effective only considering its bandwidth. These advantages are also obtained when transforming MMS clients and needing to recover one or more lost links.

The invention also relates to a communication device comprising at least one lost connection module for recovering one or more multimedia messages stored by an MMS client on an MMS server, wherein the communication device comprises: a transmission list a unit for transmitting at least one request message having at least one lost connection requesting to send one or more multimedia messages; and a receiving unit for receiving an MMS server that sends the request message when it receives the request message At least one of the plurality of multimedia messages has lost at least one of the attached reply messages.

The invention also relates to a network component comprising at least one lost connection module for recovering one or more multimedia messages stored by an MMS client on an MMS server, wherein the network component comprises: a receiving unit </ RTI> for receiving at least one request message having at least one link that has been requested to send one or more multimedia messages that has been lost and still available in the storage device on the network side; and a logic circuit unit for generating the reception At least one attached reply message sent to the request message containing at least one of the one or more multimedia messages that has lost the link.

Other development projects of the present invention are listed in various subsidiary projects of the patent application scope.

Figure 1 shows a section in an MMS architecture designed in accordance with recent conventions regarding the 3GPP format. This provides an MMS service (see the technical specifications 3GPP TS 22.140 version 6.3.0. and 3GPP TS 23.140 version 6.3.0.). This allows us to transmit and receive messages with multimedia content. Such a message is referred to as a multimedia message MM and may include a plurality of different file formats such as voice or video and MM components such as GIF or JPG. MMS services can be used in applications such as GSM (Global System for Mobile Communications), GPRS (Generally Blocked Radio Services), and even On different mobile radio systems such as UMTS (Universal Mobile Radiocommunication System).

Shown at the top left is an MMS server MRS, also known as the MMS relay/server in 3GPP. For example, the MMS server MRS can perform the following tasks: - storing, for example, incoming multimedia message MM from another MMS server; - processing and exchanging control information with the MMS client MUA; and - receiving and transmitting multimedia messages to and from the MMS client MUA MM.

The MMS server MRS contains a receiving unit EME1 for receiving control information and/or multimedia messages MM. At the same time, a transmission unit SEE1 for sending control information and/or multimedia messages MM is provided. There is also a storage unit SER for storing multimedia messages MM and control information. In some cases, the storage unit SER can be coupled to the MMS server MRS on the network side. The logic circuit unit LEE1 controls the MMS server MRS. Finally, the connection network VX1 ensures that information can be exchanged between the individual units SEE1, LEE1, EME1 and SER.

An MMS client MUA is also shown in Figure 1. In 3GPP, this MMS client MUA refers to the MMS User Agent. It is implemented, for example, as a software program on a mobile radio device that follows GSM or UMTS or a device such as a laptop connected to a mobile radio. This achieves the task of providing components of the MMS service, i.e., components required on a mobile radio device. Alternatively can also be followed The MMS client MUA is implemented on a fixed network device of the ISDN (Integrated Service Digital Network) or in a computer unit connected to the intranet or the Internet.

The MMS client MUA comprises a receiving unit EME2 for receiving control information and/or multimedia messages MM and a transmission unit SEE2 for sending control information and/or multimedia messages MM. At the same time, a logic circuit unit LEE2 for controlling the MMS server MRS to be connected to the network VX2 is provided to ensure that information can be exchanged between the individual units SEE2, EME2 and LEE2.

An operation of delivering a multimedia message MM to an MMS client MUA following a so-called extraction mode will be described in more detail below with reference to FIG. When receiving a new multimedia message MM, for example, from the second MMS server MRS, in the area of responsibility of the MMS server MRS, the newly arrived multimedia message MM can be stored in the storage unit SER connected to the network side. . Then, the transmission unit SEE1 of the MMS server MRS transmits an MMS reception notification message NQN to the MMS client MUA. The MMS acceptance notification message NQN refers to the MMS notification referred to in the 3GPP and includes a connection VK stored in the storage unit SER connected to the network side to the at least one multimedia message MM. At the same time, this link VK refers to the URI (Uniform Resource Identification Code) in 3GPP. Upon receiving the MMS receipt notification message NQN, the MMS client MUA will acknowledge receipt of the MMS by an MMS receipt confirmation message NSN. Now the MMS client MUA can use the link VK to directly load the multimedia message MM onto its device or store the MMS receipt notification message NQN and link the VK for subsequent retrieval. The multimedia message MM. The multimedia message MM can be stored in a mobile radio SIM (Subscriber Identity Module) card or a mobile radio UICC (Universal Integrated Circuit Card) of the mobile radio device at the MMS client MUA location. In the extraction mode, the multimedia message MM is stored in the MMS server MRS until it is not valid. The MMS receipt notification message NQN also contains the expiration date of the multimedia message MM. When the expiration date expires, the multimedia message MM and its associated link VK are deleted from the storage unit SER of the MMS server MRS.

Upon receiving the MMS receipt notification message NQN or the VK with one or more multimedia messages MM, the MMS client MUA may choose to download the one or more multimedia messages MM from the MMS server MRS later. As shown in FIG. 1, the MMS client MUA will send an MM request message RQN containing at least the connection VK to the multimedia message MM to be downloaded to the MMS server MRS for this purpose. If the requested multimedia message MM is still available on the MMS server MRS, the server sends the requested multimedia message MM to the requesting MMS client MUA via an MM reply message RSN. This program is also called "download job".

If the MMS client MUA does not obtain the MMS receiving notification message NQN or the VK with one or more multimedia messages MM, the MMS client MUA cannot initially select the multimedia message MM required for downloading from the MMS server MRS. . This situation also occurs when one or more linked VKs that have previously been delivered to one or more of the multimedia messages MM of the MMS client MUA have been unintentionally deleted.

In order to recover one or more linked VKs of the one or more multimedia messages MM, the MMS client MUA transmits a request message AN to the MMS server via its transmission unit SEE2 according to the signal flow as shown in FIG. MRS. The request message AN is received by the receiving unit EME1 of the MMS server MRS and evaluated by the logic circuit unit LEE1. If the one or more multimedia messages MM requested by the MMS client MUA are available in the storage unit SER, the transmission unit SEE1 of the MMS server MRS transmits an affiliate reply message WN to the MMS client MUA. This reply message WN contains at least one of the lost VKs. In fact, it is expedient to also make the reply message WN contain one or more complete MMS receipt notification messages NQN. Such a message may be a backup of the MMS receipt notification message NQN that was sent in the past and, in some cases, also stored in the network side storage unit SER of the MMS server MRS. Upon receiving the attached reply message WN, the MMS client MUA can download one or more multimedia messages MM using the received link VK. According to the 3GPP format, the request message AN may be referred to as "MM1_re-send_notification.REQ(MM1_resend_notification.REQ)" and the attached reply message WN is referred to as "MM1_re-send_notification.RES(MM1_resend_notification.RES)" .

However, it is actually advantageous not to use the request message AN to request a connection VK with a plurality of multimedia messages MM on the MMS server MRS but to make a clear choice. According to an alternative embodiment further developed by the present invention, the request message AN can be augmented by at least one filter criterion such that the link of all multimedia messages MM to be transmitted in each case satisfies the filter criteria. At least one of the following filter criteria FW is inserted into it, one of which Other filtering criteria are related to one of the areas of a multimedia message MM:

a) Sender filter FAD:

Specifically, such a filter means that only the link VK sent from a specific sender address on each multimedia message MM and thus sent from a specific sender is transmitted.

b) Receiver filter FEM:

Specifically, such a filter means that only the link VKs that each multimedia message MM is sent to a specific recipient address for delivery and thus to a particular recipient are transmitted.

c) Message type filter FMM:

Specifically, the message type filter means that only the linked VK belonging to a specific category such as "advertising" in each subsidiary multimedia message MM is taken into consideration.

d) Date and / or time filter FDU:

With this filter, only those multimedia messages MM sent on a specific date and/or time, for example, December 15, 2003, can be taken into consideration when selecting each link to be transmitted by the reply message WN.

e) Priority sample filter FPI:

With such a filter, it is possible to consider only those multimedia messages MM corresponding to a specific priority, for example, only the multimedia message MM marked as "high priority".

f) Title filter FTI:

Specifically, this filter means that only those multimedia messages MM containing a specific title or even a specific keyword in its title are taken into consideration.

In fact, it is advantageous to use not only the filter criteria FW to select specific criteria but also to exclude specific criteria. For this purpose, for example, the filter criteria FW of the following filters can be augmented by an identifier such as a flag indicating the selection criteria and/or exclusion criteria: - sender filter FAD; - recipient filter FEM; - message type filter FMM; - date and / or time filter FDU; - priority sample filter FPI; - title filter FTI.

Therefore, the request message AN can be made to contain both the selection criteria and the exclusion criteria. For example, the multimedia message MM containing the word "road" in the title will be retrieved from the multimedia message MM covered by the request message AN by the request message AN, but the multimedia message MM containing the title "railway" is excluded.

At the same time, it is expedient to request only those connection VKs that cannot be obtained on the MMS client MUA with one or more multimedia messages MM. In this regard, a link criterion VW contains one or more link VKs that can no longer be indicated by the reply message WN. At the same time, it can be made to contain one or more MMS receiving notification messages NQN while ensuring that a specific link VK can be uniquely assigned to replace the link VK.

In some cases, more than one filter criterion FW and/or link criteria VW may be used within a request message AN. In this regard, the individual filter criteria FW and/or the link criteria VW can be correlated. Associated here Words refer to logical expressions such as "ie", "or" or "exclusive or" and such terms as "greater than or equal to", "less than" or "less than or equal to". In the embodiment of the present explanation, the multimedia message MM to be considered includes, for example, a multimedia message MM sent on three different dates on December 14, 2003, December 15, 2003, and January 1, 2004. Therefore, the request message AN may contain three different filtering criteria for the date and/or time, that is, the use of the logical language "or" to achieve the required relationship "December 15, 2003 or December 14, 2003 Or January 1, 2004."

Figure 3 contains an available implementation of the request message AN for the message flow of Figure 2, wherein the filter for filtering the criteria FW and/or the connection criterion VW is in the 3GPP format, see Technical Specification TS22 .140 version 6.3.0. and 3GPP TS 23.140 version 6.3.0. In 3GPP, for example, a request message AN named "MM1_Resend_Notification.REQ(MM1_resend_notification.REQ)" may be provided. The individual information elements in Figure 3 will be examined in more detail below, with the first line showing the name of the corresponding information element and the second line indicating the corresponding information element used in the request message AN and the third line. It contains a short description: - information element "message type" MT1: the request message AN must contain this information element and this information element is used to identify the message is a request message in other words is called "MM1_ heavy Send a message to _Notice.REQ(MM1_resend_notification.REQ).

-Information component "transaction identifier" TA1:

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

-Information component "MMS version" MV1:

The information element must be included in the request message AN and this information element is used to indicate the version of the MMS interface on the MMS client MUA.

-Information component "Notification filter" FVK1:

This information element can be selected in the request message AN. This information element can correspond to the link criterion VW.

-Information component "sender filter" FAD1:

The use of this information element is not obligatory. This information element provides a sender filter FAD.

-Information component "Recipient Filter" FEM1:

The use of this information element is not obligatory. This information element provides a recipient filter FEM.

-Information component "message category filter" FMM1:

This information element is an optional information element. This information element provides a message type filter FMM.

- Information element "Date and time filter" FDU1:

This information element is an optional information element and this information element can provide different filter FDUs of date and/or time.

-Information component "Priority Filter" FPI1:

The use of this information element is optional. This identifies the priority filter FPI corresponding to the information element.

-Information component "topic filter" FTI1:

The use of this information element is optional and this information element provides a title filter FTI.

The request message AN can also be used to contain more than one of the above selected information elements.

Figure 4 shows another request message AN for the message flow of Figure 2, which corresponds to the OMA OMA-WAP-MMS-ENC-v1_1.20021030-C, OMA-WAP-MMS -CTR-v1_1.30021031-V and OMA-WAP-MMS-ARC-v1_1.20021101-C format. In OMA, the request message AN refers to a message called "M_Resend_Notification.req (M_Resend_Notification. req)". The first line in Fig. 4 contains the name of the area of the request message AN, the second line contains the corresponding area values and the third line contains a short description of the function of the corresponding area. The name of the area contained in the request message AN is as follows:

- Area name "X-Mms-message-type" MT3:

The request message AN must contain an area that uniquely highlights the PDU (Assignment Data Unit) type whose name is "M_Resend_Notification. req". The area value following the OMA format is: "message-type-value=M_re-send_notification.req (m_resend_notification.req)".

- Area name "X-Mms-Transaction-Identification Code" TA3:

This area allows for a unique assignment between the request message AN and one or more of the ancillary reply messages WN. This area must be included in each request message AN. The corresponding regional value is called: "transaction - knowledge Do not code - value.

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

This area contains the version of the MMS interface on the MMS client MUA and this area must be included in the request message AN. The area value for this area is "MMS-Version-Value".

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

This selected area may indicate a link VK to one or more multimedia messages MM that is not sent by the MMS client MUA. This area corresponds to the link criterion VW. The link VK used herein refers to, for example, a transaction identification code of a previously sent MMS reception notification message NQN or even a link VK refers to, for example, a URI (Uniform Resource Identification Code) of one or more multimedia messages MM. The area value used is the value "Sender - Filter - Value".

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

This selection area defines the sender filter FAD. The area value used in this area is "Sender-Filter-Value".

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

This selection area defines the recipient filter FEM. The area value used in this area is "Recipient-Filter-Value".

- Area name "X-Mms-message-category-filter" FMM3:

This selection area represents the message type filter FMM. The area value used in this area is "Message - Category - Filter - Value".

- Area name "X-Mms-Date-and-Time-Filter" FDU3:

The use of this area is optional. This area allows for the identification of date and/or time filter FDUs. With "Date-and-Time-Filter" - The value is treated as its region value.

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

The use of this area is optional. This area is used to provide the priority filter FPI. The corresponding area value is "Priority - Filter - Value".

- Area name "X-Mms-Theme-Filter" FTI3:

This area can be marked with the title filter FTI. The use of this area is selective.

The request message AN may also contain more than one of the above selected area names. The "topic-filter-value" is used as its region value.

Two embodiments of the explanation of the reply message WN for the message flow of Fig. 2 will be presented below. Figure 5 lists the first example corresponding to the 3GPP format (see the document of the 3GPP Technical Specification TS 22.140 version 6.3.0.). Here, the reply message WN refers to a message such as the name "MM1_Resend_Notification.RES(MM1_resend_notification.RES)". The left row of Figure 5 shows the information elements available for the reply message WN, with the center row showing its application and the right row giving its short description. The available information elements in the reply message WN that follow the 3GPP format are as follows:

-Information component "message type" MT2:

The use of this information element is compulsory. This information element can uniquely mark this message as a 3GPP reply message WN named "MM1_Resend_Notification.RES(MM1_resend_notification.RES)".

-Information component "transaction identifier" TA2:

This information element is necessary to uniquely request a message AN Specify a reply message WN. It is actually expedient to make the transmission identity "transaction identifier" TA2 exactly correspond to the "transaction identifier" TA1 in Fig. 3. The use of this information element is compulsory.

-Information component "MMS version" MV2:

This information element is used to indicate the version of the MMS interface on the MMS client MUA. Each reply message WN must contain this information element.

-Information component "Resend notification status" RS2:

This information element contains the status of requesting the sending of the necessary connection VK with the one or more multimedia messages MM as the request message AN. This status indicates whether the request can be successfully processed by the MMS server MRS or a specific error has occurred. Each reply message WN must refer to this information element.

-Information component "Resend Notification Status" RT2:

This information element indicates the status reached by the "Resend Notification Status" RS2 in text form. The use of this information element is optional.

-Information component "Notification details" ND2:

This information element can be included in the reply message WN. When there is such a information element, the reply message WN can provide at least one link VK requested by the request message AN with the multimedia message MM. The method is achieved by, for example, a list form of the MMS receiving notification message NQN initially sent or a corresponding URI (Uniform Resource Identification Code).

Figure 6 shows the OMA-MMS format in the message stream of Figure 2 (for example, see the OMA specification document OMA-MMS-ENC-v1_2- The second explanation of the reply message WN of 20030915-C) is an embodiment. In OMA, the reply message WN refers to a message such as the name "M_Resend_Notification.conf". The first row titled "Area Name" in Fig. 6 lists the names of the corresponding OMA regions, the second row lists the corresponding region values, and the third row lists the short descriptions of the individual OMA regions. The individual areas of the reply message WN that follow the OMA format will be described in detail below:

- Area name "X-Mms-message-type" MT4:

The use of this area is compulsory. This area allows us to uniquely identify an OMA message as a reply message WN named "M-Resend-Notification.conf". According to the OMA format, "message type - value = m - resend - notification - conf (m-resend-notification-conf)" is taken as its region value.

- Area name "X-Mms-Transaction-Identification Code" TA4:

This mandatory area enables us to uniquely assign a reply message WN to a particular request message AN. This can be used to actually correspond to the "X-Mms-Transaction-Identification Code" TA3 (see Figure 5) of the request message AN "M-Resend-Notification. req". The area value "transaction-identification code-value" is reached.

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

This is a compulsory area. The area "MMS-Version-Value" is used to indicate the version of the MMS interface on the MMS client MUA.

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

This area must be included in each reply message WN. This area It is used to indicate the status of the reply message WN reached by the request message AN. This status is shown as the area value "Resend - Notification - Status - Value".

- Area name "X-Mms-Resend - Notification - This article" RT4:

This area contains a textual description of the area with the area name "X-Mms-Resend - Notification - Status" RS4. The use of this area is optional and is used in the table as the area value "Resend - Notification - Status - This - Value".

- Area name "X-Mms-Notification-Detail" ND4:

This area contains a link VK to one or more multimedia messages MM. The MMS acceptance notification message NQN following the OMA specification refers to the message named "M-notification.ind (M-Notification. ind)". Alternatively, a URI (Uniform Resource Identification Code) may also be present therein. In order to assist in the connection of the VK, it may further include such information as the priority of the multimedia message MM or the sender address of the multimedia message MM, which may be indicated by the connection VK. The area value "notification-detail-value" is used as the value of this area.

According to a further alternative embodiment of the invention, more than one reply message WN can be sent to the MMS client MUA expediently at the strength of the request message AN. It is advantageous here to use a single ethnic group identification signal GN for the message stream of Fig. 2 in all of the reply messages WN transmitted with the strength of the request message AN. Therefore, for example, the corresponding transaction number "transaction identification code" TA2 of the request message AN can be used as the single ethnic group identification signal GN and input into the area "transaction identification code" TA4 of the corresponding reply message WN. In this way, all of the reply messages WN generated by the strength of the request message AN use the same transaction number TA4.

In practice, it is also advantageous to provide each reply message WN with a common single group identification signal GN having a continuous message number NRN and a total number NGA for the message flow of FIG. Here, the total number NGA corresponds to the number of reply messages WN having the same ethnic group identification signal GN. For example, seven reply messages WN are transmitted with the same ethnic group identification signal GN. Therefore, the first reply message WN sent from the MMS server MRS to the MMS client MUA can be assigned as the message number NRN "1" and the total number NGA "7". The second reply message WN is again given as the continuous message number NRN "2" and the total number NGA "7". The continuous message number NRN and the total number NGA allow the MMS client MUA to determine in an unambiguous manner that one or more reply messages WN do not exist and may request them again.

According to a further advantageous embodiment variant of the invention, the reply message WN can be obtained directly from the MMS receipt notification message NQN forwarded to the MMS client MUA. For example, the MMS server MRS will maintain one or more MMS receipt notification messages NQN for the multimedia message MM that are still available in its storage device SER. After making a minor correction such as the transaction number "transaction identifier" TA4, the person can send the corrected MMS receipt notification message NQN to the MMS client MUA as the reply message WN of the request message AN.

An encoding method for use in certain areas of the request message AN and the reply message WN according to the OMA-compliant format will be described below with reference to FIG. The left row of Figure 7 lists the names of the regions available for multiple regions, some of which are given in the left row of Figures 4 and 6. The center line is filled with a usable six-digit encoding method and the right row is Contains an available OMA-compliant coding method and its accompanying instructions. The six-bit encoding method is used in the OMA-MMS format to uniquely identify a particular area within a message. For example, the area of the six-bit code 0x34 corresponding to the area name is "X-Mms-Notification-Filter" FVK. The OMA-compliant coding of certain areas of the BNF form will be examined in more detail below:

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

The six-bit code used for this area is 0x34. The corresponding value of this area is "Notification - Filter - Value = Text String ∣ Uri - Value".

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

The identifier used for this area is "Sender-Filter-Value=Code-String-Value". Its six-bit code is 0x35.

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

The area value for this area is "Recipient-Filter-Value=Code-String-Value". Its six-bit code is 0x36.

- Area name "X-Mms-message-category-filter" FMM3:

The six-bit code used for this area is 0x37. The attached area value includes "message-category-filter-value=category-identification code-representation text category-identity code=personality/advertising-information-automatic".

- Area name "X-Mms-Date-and-Time-Filter" FDU3:

The six-bit code used for this area is 0x38. This area can be explained by the following regional values: "Date-and-Time-Filter=Value Length (Absolute-Representation Date-Value ∣ Relative-Representation △-Second-Value)

Absolute-characterization = <Octet 128>

Relative-characterization = <Octet 129>

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

This area is used for the six-bit encoding with a value of 0x3A. This area can be explained by the following regional values: "Priority - Filter - Value = Below normal high

Low = <Octet 128>

Normal = <Octet 129>

High=<Octet 130>

- Area name "X-Mms-Theme-Filter" FTI3:

The six-bit code value for this area is 0x39. This area can be expressed as the area value "Subject - Filter - Value = Code - String - Value"

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

The value of this area for six-bit encoding is set to 0x3B. The values used for this area can be expressed as follows: "Resend - Notification - Status - Value = Success ∣ Error - Transitional - Fault ∣ Error - Permanent - Fault ∣ Error - Permanent - Compliance - Rejected

Success = <Octet 128>

Error-transitional-fault=<Octet 192>

Error - permanent - failure = <Octet 224>

Error - Permanent - Service - Rejected = <Octet 225>"

- Area name "X-Mms-Resend - Notification - This article" RT4:

This area is used for the six-bit coded value of 0x3C. The value used for this area can be expressed as "Resend - Notification - This - Value = Encoding - String - Value".

- Area name "X-Mms-Notification-Detail" ND4:

This area is used for the six-bit encoding with a value of 0x3D. The available expressions for the region values for this region are as follows: "Notification - Detail - Value = Value Length (X-Mms - Content - Location Region Start - Region Topic - Region X-Mms - Delivery - Report - Region X-Mms - Message - Category - Area X - Mms - Priority - Area X - Mms - Message - Size - Area X - Mms - Term - Area, etc.).

Not all areas listed here must contain an area value with the area name "X-Mms-Notification-Detail". At least the area where the area name is "X-Mms-Content-Location" and contains the detailed information of the URI (Uniform Resource Identification Code) and corresponds to the connection VK with a multimedia message MM is at least expediently present.

In practice, it is also advantageous to extend one or more of the filter criteria FW within a request message AN by defining available exclusion criteria and available selection criteria. In this regard, an explanation implementation method can be proposed by referring to the OMA-MMS area "X-Mms-Priority-Filter" FPI3 in accordance with the OMA format. This example should be understandable so that an application can be applied not only to this particular area but also to all other filtering criteria FW. The left row of Figure 8 shows the region name for each corresponding region, the center row shows the available six-bit expression for the corresponding header region, and the right row shows the available expression for its region value. For example, the area name "X-Mms-Priority-Filter" FPI3 can be encoded as a value of 0x3A in a six-bit manner. The performance of the available zone values for the first region of this file is as follows: "Priority - Filter - Value = Positive - Negative - Value (lower than normal)

Positive-negative value = positive value - negative value

Positive value = <Octet 128>

Negative value = <Octet 129>

Low = <Octet 128>

Normal = <Octet 129>

High=<Octet 130>

The selection criteria and/or exclusion criteria may be used in a request message AN having such an extension consisting of the filtering criteria FW in a conventional manner.

EME1‧‧‧ receiving unit

EME2‧‧‧ receiving unit

LEE1‧‧‧ logic circuit unit

LEE2‧‧‧ logic circuit unit

MRS‧‧MMS server

MUA‧‧‧MMS User Agent

SEE1‧‧‧ transmission unit

SEE2‧‧‧ transmission unit

SER‧‧‧ storage unit

VX1‧‧‧Connected network

VX2‧‧‧Connected network

The invention and its developments will be explained in more detail below with reference to the accompanying drawings.

FIG. 1 is a schematic diagram showing a flow of information of an MMS server and an MMS client in an extraction mode, wherein a link of a multimedia message is displayed to the MMS client by a notification message and is used by the MMS client. The MMS server downloads the multimedia message.

2 is a schematic diagram showing an MMS server and an MMS client performing a message flow according to a first illustrative embodiment of the present invention, wherein the MMS client requests at least one multimedia message by a request message. Linking and transmitting at least one link required by the at least one reply message to the MMS client.

Figure 3 shows some of the names used for MMS messages in the message stream of Figure 2 in accordance with the Open Operations Alliance (OMA)-compliant coding method. "M-Resend - Notification.conf (M-Resend- Notificaiton. Conf)" and "M- The OMA-MMS file header area of the retransmission-request.req (M-Resend-Notificaiton. req) is also a PDU (Assignment Data Unit).

Figure 4 shows the request message in the message stream of Figure 2 in accordance with the 3GPP format name "MM1_Re-send_Notification.REQ(MM1_resend_notification.REQ)" and its information elements in the form of a table.

Figure 5 shows the reply message following the 3GPP format name "MM1_Resend_Notification.RES(MM1_resend_notification.RES)" and its information elements in the message flow of Figure 2 in tabular form.

Fig. 6 shows the request message and the contents of each area in the message stream of Fig. 2 in accordance with the OMA-MMS format name "M_re-send_request.req (M_resend_Notification. req)" in the form of a table.

Figure 7 shows the reply message in the message flow of Figure 2 in accordance with the OMA-MMS format name "M_Resend_conf.conf (M_resend_Notification.conf)" and the contents of each area.

Figure 8 shows the name of the request message following the OMA-MMS format in the message stream of Figure 2 according to the OMA-compliant coding method. The name is "X-Mms-Priority-Filter.conf (X-Mms- The available extension area for Priority-Filter. conf).

The components having the same functions and operation modes are denoted by the same reference numerals in the first to eighth drawings.

no

Claims (13)

A method for recovering at least one lost link (VK) by an MMS client (MUA) to one or more multimedia messages (MM) stored on an MMS server (MRS), characterized by the MMS client (MUA) sends at least one lost link (VK) to one or more multimedia messages (MM) according to the request to send at least one request message (AN) to the MMS server (MRS), the MMS server (MRS) After receiving the request message (AN), transmitting at least one related reply message (WN) to the MMS client (MUA), the reply message (WN) containing at least one of the one or more multimedia messages (MM) The missing link (VK), the MMS client (MUA) supplements the request message (AN) by a link criterion (VW), wherein at least one link (VK) is set by the link criterion (VW) For at least one multimedia message (MM), the multimedia message (MM) remains unconsidered by the MMS server (MRS) when selecting the link (VK) to be transmitted. The method of claim 1, wherein the MMS server (MRS) transmits the lost link (VK) on the individual multimedia message (MM) to the MMS client (MUA) at least once in the past. For example, the method of claim 1 or 2, wherein the MMS is used The terminal (MUA) uses a mobile radio that follows the GSM benchmark or UMTS benchmark, or a fixed-line network device that follows the IDSN benchmark, or a computer unit that is connected to the intranet or the Internet. The method of claim 1 or 2, wherein the MMS client (MUA) augments the request message (AN) by at least one filter criterion (FW), and all of the links (VK) to be transmitted are individually transmitted. The multimedia message (MM) satisfies the filtering criteria (FW). For example, the method of claim 4, wherein the selection criteria and/or exclusion criteria can be defined by individual filtering criteria (FW). The method of claim 4, wherein the filtering criterion (FW) comprises at least one of the following fields regarding the multimedia message (MM): - a sender address (FAD3); - a recipient address (FEM3) ;- Message Type (FMM3); - Date and / or Time (FDU3); - Priority (FPI3); and - Title (FTI3). The method of claim 4, wherein the individual connection criteria (VW) and/or the individual filter criteria (FW) are correlated by a logical representation and/or a size representation. The method of claim 1, wherein the single ethnic group identification signal (GN) is inserted by the MMS server (MRS) into all reply messages (WN) to the individual MMS client (MUA), the reply message ( WN) is sent due to a request message (AN). For example, in the method of claim 1 or 8, wherein a continuous message number (NRN) and a total number (NGA) are inserted into all reply messages (WN) by the MMS server (MRS), wherein the total number is (NGA) corresponds to the total number of reply messages (WN) sent due to individual request messages (AN). The method of claim 1 or 2, wherein the request message (AN) and/or the reply message (WN) used in the method are described by a syntax of a 3GPP multimedia messaging service. The method of claim 1 or 2, wherein the request message (AN) and/or the reply message (WN) used in the method are described by the syntax of the OMA multimedia messaging service. A communication device (MUA) having a module for recovering at least one lost link (VK) to one or more multimedia messages stored on an MMS server (MRS) by an MMS client (MUA) ( MM), in particular, the method of any one of claims 1 to 11, wherein the communication device comprises: a transmission unit (SEE2) transmitting at least one request message (AN) for sending on request At least one missing link (VK) to one or more multimedia messages (MM), wherein the MMS client (MUA) supplements the request message (AN) by a link criterion (VW), wherein the link criterion ( VW) setting at least one link (VK) to at least one multimedia message (MM), the multimedia message (MM) remaining unconsidered by the MMS server (MRS) when selecting the link to be transmitted (VK) And a receiving unit (EME2) for receiving at least one relevant reply sent by the MMS server (MRS) after receiving the request message (AN) A message (WN) containing at least one missing link (VK) on one or more multimedia messages (MM). An internet component (ARS) having a module for recovering at least one lost link (VK) to one or more multimedia messages stored on an MMS server (MRS) by an MMS client (MUA) (MM), in particular, the method of any one of claims 1 to 11, wherein the network component comprises: a receiving unit (EME1) for receiving at least one request message (AN) for Sending at least one lost link (VK) to one or more multimedia messages (MM) on request, the multimedia messages (MM) can still be used in the storage device (SER) on the network side, wherein the MMS client (MUA) The request message (AN) is supplemented by a link criterion (VW), wherein at least one link (VK) is set to at least one multimedia message (MM) by the link criterion (VW), the multimedia message ( MM) remains unconsidered by the MMS server (MRS) when selecting the link to be transmitted (VK); a logical unit (LEE1) will contain at least one missing link after receiving the request message (AN) ( At least one related reply message (WN) of the VK) is constructed to one or more multimedia messages (MM); A transmission unit (SEE1), for sending the at least one associated reply message (WN) to the MMS client (MUA).