WO2005067325A1 - Verfahren zur wiedererlangung von einer auf einem mms-client nicht verfügbaren verknüpfung auf eine auf einem mms-server abgelegte multimedia nachricht durch einen mms-client - Google Patents

Verfahren zur wiedererlangung von einer auf einem mms-client nicht verfügbaren verknüpfung auf eine auf einem mms-server abgelegte multimedia nachricht durch einen mms-client Download PDF

Info

Publication number
WO2005067325A1
WO2005067325A1 PCT/EP2004/052595 EP2004052595W WO2005067325A1 WO 2005067325 A1 WO2005067325 A1 WO 2005067325A1 EP 2004052595 W EP2004052595 W EP 2004052595W WO 2005067325 A1 WO2005067325 A1 WO 2005067325A1
Authority
WO
WIPO (PCT)
Prior art keywords
mms
message
mua
multimedia
request message
Prior art date
Application number
PCT/EP2004/052595
Other languages
English (en)
French (fr)
Inventor
Andreas Schmidt
Markus Trauberg
Sabine Van Niekerk
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2005067325A1 publication Critical patent/WO2005067325A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58—Message adaptation for wireless communication

Definitions

  • GSM Global System for Mobile Communications
  • SMS Short Message Service
  • MMS MMS - Multimedia Messaging Service
  • 3GPP TS22.140, version 6.0.0 and TS23.140, version 6.0.0, among others MMS - Multimedia Messaging Service
  • This service can be used in various mobile radio systems, such as GSM,
  • GPRS General Package Radio Services
  • EDGE EDGE - Enhanced Data Rates for GSM Evolution
  • UMTS UMTS - Universal Mobile Telecommunications System
  • MMS multimedia message
  • a characteristic feature of MMS is that a distinction is made between the so-called push mode and the pull mode when one or more multimedia messages are delivered to the MMS receiver.
  • the push mode a distinction is made between the so-called push mode and the pull mode when one or more multimedia messages are delivered to the MMS receiver.
  • Receiver notification a link to the corresponding multimedia message, which is located on the associated MMS-Ne zwerkelement. This link is referred to as a URI (URI - Uniform Resource Identifier).
  • URI Uniform Resource Identifier
  • the MMS recipient keep the links of the multimedia messages that he would like to download at a later time. If an MMS receiver or a user accidentally deletes an MMS receiver notification and / or the link before the associated multimedia message is downloaded, he later no longer has the option of accessing this multimedia message.
  • a similar problem arises when the MMS recipient notification or the linkage of a multimedia message is first stored in a first terminal. The MMS receiver now changes its terminal device and would like to access the corresponding multimedia messages using a second terminal device. This situation arises, for example, when an MMS receiver takes out its mobile radio SIM card (SIM - Subscriber Identity Module) from a first mobile radio telephone and inserts it into a second mobile radio telephone. If the mobile phone SIM card does not offer MMS support, the MMS recipient notifications or the links to the multimedia messages are only available in the first mobile phone. This means that they are not available in the second mobile phone. The same
  • SIM card SIM - Subscriber Identity Module
  • the first device is a laptop and the second device is a PDA (PDA -Personal Digital Assistant).
  • PDA PDA -Personal Digital Assistant
  • the invention is based on the object of providing a simple and efficient possibility for regaining at least one missing link to one or more multimedia messages in MMS.
  • Method for regaining at least one missing link to one or more multimedia messages stored on an MMS server by an MMS client by means of the MMS client sending at least one to the MMS server Request message is sent with the request to send at least one missing link to one or more multimedia messages, and by the MMS server after receiving the request message at least one associated response message to the
  • MMS client is sent that contains at least one of the missing links to the one or more multimedia messages.
  • the MMS client can regain one or more missing links to one or more multimedia messages at any time if required.
  • the method can be expanded in terms of the number of links that can be transmitted to the MMS client.
  • the fact that both a single link as well as several links simultaneously are transmitted in a single reply message results in a uniform query. ge Vietnamese. Due to the uniform query structure of the method, several missing links can thus be combined in a single response message and thus transmitted in a bandwidth-efficient manner.
  • the invention also relates to a communication device with a module for regaining at least one missing link to one or more multimedia messages stored on an MMS server by an MMS client, with a transmission unit for sending at least one request message with the request to send at least one missing link to one or more multimedia messages and with a receiving unit for receiving at least one associated response message sent by the MMS server after receiving the request message, which contains at least one of the missing links to the one or more multimedia messages.
  • the invention relates to a network component with a module for regaining at least one missing link to one or more multimedia messages stored on an MMS server by an MMS client, with a receiving unit for receiving at least one request message with the request to send at least one Missing link to one or more multimedia messages that are still available on the network side with a logic unit for creating, at least one associated response message with at least one missing link to one or more multimedia messages after receiving the request message, and with a sending unit for sending at least one associated reply message to the MMS client.
  • a network component with a module for regaining at least one missing link to one or more multimedia messages stored on an MMS server by an MMS client, with a receiving unit for receiving at least one request message with the request to send at least one Missing link to one or more multimedia messages that are still available on the network side with a logic unit for creating, at least one associated response message with at least one missing link to one or more multimedia messages after receiving the request message, and with a sending unit for sending at least one associated reply message to the MMS client
  • FIG. 1 in a schematic representation of an MMS server and an MMS client, as well as the message flow for the pull mode, wherein the MMS client is shown a link to a multimedia message by means of a notification message and this loads the multimedia message from the MMS server .
  • FIG. 2 shows a schematic representation of an MMS server and an MMS client, as well as the message flow according to a first exemplary embodiment of the method according to the invention, the MMS client having at least one link to at least one multimedia
  • FIG. 3 in tabular form according to the OMA-compliant coding some of the OMA-MMS header fields for an MMS message (PDU - Protocol Data Unit) with a name "M-Resend-Notification. Conf” and “M-Resend-Notification” . req "for the message flow for FIG. 2,
  • FIG. 4 in tabular form the request message in the message from FIG. 2 according to 3GPP syntax with a name "MMl_resend_notification. REQ" and its information elements
  • Figure 5 in tabular form the response message in
  • FIG. 8 in tabular form in accordance with the OMA-compliant coding shows a possible expansion of the field with the name “X-Mms-Priority-Filter” of the request message in the message flow from FIG.
  • FIG. 1 shows a section of an MMS architecture according to the current state of the art from the perspective of 3GPP.
  • MMS MMS - Multimedia Messaging Service
  • 3GPP 3GPP - Third Generation Partnership Project
  • TS22.140 version 6.3.0
  • 3GPP 3GPP - Third Generation Partnership Project
  • a multimedia message MM can comprise several MM elements of different file types, such as audio or video, and file formats, such as GIF or JPG.
  • the MMS service can be used in various mobile radio systems such as For example, GSM (Global System for Mobile), GPRS (GPRS - General Package Radio Services) or UMTS (UMTS - Universal Mobile Telecommunications System) can be used.
  • GSM Global System for Mobile
  • GPRS GPRS - General Package Radio Services
  • UMTS UMTS - Universal Mobile Telecommunications System
  • An MMS server MRS which is also referred to as an MMS relay / server in 3GPP, is shown on the top left.
  • the MMS server MRS has the following tasks, among others:
  • the MMS server MRS comprises a receiving unit EME1 for receiving control information and / or multimedia messages MM.
  • a sending unit SEE1 is provided for sending control information and multimedia messages MM.
  • a storage unit SER for storing multimedia messages MM and control information.
  • the storage unit SER can optionally be connected to the MMS server MRS on the network side.
  • a logic unit LEE1 controls the MMS server MRS.
  • a connection network VX1 ensures the exchange of information between the individual units SEE1, LEE1, EME1 and SER.
  • the MMS client MUA can also be seen in FIG. In 3GPP, this MMS client MUA is referred to as an MMS user agent. This 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 a mobile radio device, such as a laptop. This has the task of realizing the part of the MMS service that is required, for example, on a mobile radio device. Alternatively, the MMS client MUA can also be used on a fixed network device based on ISDN (Integrated Sub- sc ⁇ ber digital network) or in a computer unit connected to the intranet or internet.
  • ISDN Integrated Sub- sc ⁇ ber digital network
  • the MMS client MUA comprises a receiving unit EME2 for receiving control information and / or multimedia
  • a logic unit LEE2 for controlling the MMS client MUA and a connection network vx2 are provided, which ensure the exchange of information between the individual units SEE2, EME2 and LEE2.
  • this newly arrived multimedia message MM m is stored in a network unit connected storage unit SER.
  • the transmitting unit SEE1 of the MMS server MRS then transmits an MMS receiver notification message NQN to the MMS client MUA.
  • This MMS receiver notification message NQN is called 3GPP as MMS notification and comprises a link VK to at least one multimedia message stored in the network-connected storage element SER.
  • This link VK is also referred to in 3GPP as a URI (Uniform Resource Identifier).
  • the MMS client MUA acknowledges receipt by means of the MMS recipient confirmation message NSN.
  • the MMS client MUA can now either use the link VK to load the multimedia message MM immediately onto its device or to save the MMS receiver notification message NQN and the link VK for later retrieval of the multimedia message MM.
  • This can be stored, for example, on the mobile radio SIM card (SIM - Subscriber Identity Module) or the mobile radio UICC (UICC - Universal Integrated Circuit Card) of the mobile radio device on which the MMS client MUA is located.
  • SIM card SIM - Subscriber Identity Module
  • UICC UICC
  • the MMS receiver notification message NQN also includes a validity period of the multimedia message MM. When the validity period expires, the multimedia message MM together with the associated link VK is deleted from the storage unit SER of the MMS server MRS.
  • the MMS client MUA After receiving the MMS recipient notification message NQN or the link VK to one or more multimedia messages MM, the MMS client MUA later has the option of downloading 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 MRS, which contains at least the link VK to the multimedia message MM to be downloaded. In the event that the requested multimedia message MM is still available on the MMS server MRS, the latter 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".
  • the MMS client MUA sends a request message AN to the by means of its transmitting unit S ⁇ E2 according to the signal flow of FIG MMS server MRS.
  • This request message AN is received by the receiving unit EME1 of the MMS server MRS and evaluated by the logic unit LEE1. If one or more multimedia messages MM are available for the requesting MMS client MUA in the storage device SER, the sending unit SEE1 of the MMS server MRS sends an associated response message WN to the MMS client MUA.
  • This response message WN comprises at least one of the missing links VK. In practice, it may be appropriate for the response message WN to also be one or more complete
  • MMS recipient notification messages contain NQN. These can be a copy of the MMS recipient notification messages NQN which may have been transmitted in the past and which may also be stored in the network-side storage device SER of the MMS server MRS.
  • the MMS client MUA can download one or more multimedia messages MM based on the received links VK.
  • the request message AN can be designated with a name "MMl_resend_notification. REQ” and the associated response message WN with "MMl_resend_notification. RES".
  • the request message AN is expanded by at least one filter criterion that is fulfilled by all multimedia messages MM of the link VK to be transmitted in each case. At least one of the following filter criteria FW is inserted, the respective filter relating to one of the fields of a multimedia message MM:
  • Filter for sender FAD The specification of this filter allows only links VK to multimedia messages MM to be sent that were sent from a specific sender address, and consequently from a specific sender.
  • This filter allows only links VK to multimedia messages MM to be sent that have been sent to a specific recipient address, and consequently to a specific addressee.
  • This filter only takes into account those multimedia messages MM that correspond to a specific priority, for example only the multimedia messages MM that are marked with the priority "high".
  • the filter criteria FW of the following filters are supplemented by, for example, an identifier, such as a flag, which provides information as to whether it is a selection criterion and / or an exclusion criterion:
  • a request message AN may contain both selection criteria and exclusion criteria. For example, a request message AN signals that the multimedia messages MM to be searched for, which are taken into account by the request message AN, contain the word “bahn” in the title, but multimedia messages MM that include the title “Eisenbahn” are excluded.
  • a linking criterion VW contains one or more links VK, which are no longer signaled by means of the response message WN. It is also possible for one or more MMS receiver notification messages NQN to be contained in place of the link VK, which also ensure unambiguous assignment to a specific link VK.
  • filter criterion FW and / or linking criterion VW can be used.
  • the individual filter criteria FW and / or linking criteria VW can be related to one another. Under a relation are logic expressions such as “AND”, “OR” or “EXCLUSIVE-OR” as well as size expressions such as
  • Request message AN contain three different filters for date and / or time FDU, which enables the desired relation "15.12.2003 OR 14.12.2003 OR 1.1.2004" by means of the logic expression "OR”.
  • FIG. 3 contains a possible implementation of the request message AN for the message flow from FIG. 2 with the filters for the filter criterion FW and the linking criterion VW in the form of the syntax according to 3GPP, see technical specifications TS 22.140, version 6.3.0 and TS 23.140, version 6.3. 0th In 3GPP, for example, it is possible to name the request message AN
  • 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”.
  • Transaction ID This information element must be contained in the request message AN and is used to ensure a clear association between the request message AN and the response message WN.
  • This information element must be contained in the request message AN and indicates the version of the MMS interface of the MMS client MUA.
  • Notification filter FVKl The use of this information element within the request message is optional. It corresponds to the linking criterion FVK.
  • Send filter FAD1 The use of this filter criterion is not mandatory. It realizes the filter for sender FAD.
  • Message class filter FMM1 This is an optional information element. It implements the filter for the FMM message type.
  • This information element is optional and implements the filter for date and / or time FDU.
  • this element identifies the information element that corresponds to the filter for priority FPI.
  • Subject filter FTI1 Information element "Subject filter” FTI1: The use of this information element is optional and implements the filter for the title FTI.
  • All optional information elements can also be contained several times in a request message AN.
  • FIG. 4 shows a further embodiment of the request message AN for the message flow from FIG. 2, which uses the syntax according to the OMA standards OMA-WAP-MMS-ENC-vl_1.20021030-C, OMA-WAP-MMS-CTR-vl_l -30021031-V and OMA-WAP-MMS-ARC-vl_l-20021101-C.
  • the request message AN is called "M-Resend-Notification. Req”.
  • the field names of the request message AN can be found in the first column, the corresponding field value in the second column and a brief description of the function of the corresponding field is recorded in the third column. The following field names are contained in this request message AN:
  • This field allows a clear assignment between the request message AN and one or more associated response messages WN. It must be included in every request message AN.
  • the corresponding field value is "Transaction-id-value”.
  • the field value for this field is "MMS-version-value”.
  • This optional field specifies the links VK to one or more multimedia messages MM that are not sent by the MMS server MRS. This corresponds to the linking criterion VW.
  • the link VK can, for example, be the rransaction-ID of a previously sent MMS receiver notification message NQN or the link VK to at least one multimedia message MM, for example the URI (URI - Uniform Resource Identifier).
  • the value "Sender-filter-value" is used as the field value.
  • This optional field defines the filter for the sender FAD. It uses "Sender-filter-value" as the field value.
  • This optional field defines the filter for recipient FAD. It uses "Receiver-filter-value" as the field value.
  • FMM3 This optional field represents the filter for message type FMM. It uses "Message-class-filter-value" as the field value.
  • FDU3 Field name "X-Mms-Date-And-Time-Filter” FDU3: The use of this field is optional. It allows the filter for the date and / or time FDU to be specified. The value "Date-and-time-filter-value" is used as the field value.
  • FPI3 Field name "X-Mms-Priority-Filter” FPI3: The use of this field is optional. This filter is used to implement the FPI priority filter. The corresponding field value is "Priority-filter-value”.
  • This field specifies the filter for title FTI. The use of this field is optional.
  • the value "Sub ect-filter-value" is used as the field value.
  • the optional fields can be used one or more times within the request message AN.
  • FIG. 5 lists a first example which corresponds to the 3GPP syntax (see 3GPP technical specification TS 22.140 version 6.3.0).
  • the response message WN is designated, for example, with the name "MMl_resend_notification .RES".
  • the possible information elements for the reply message WN can be seen in the left column, their use can be found in the middle column and a brief description is listed in the right column.
  • the possible information elements of the response message WN according to 3GPP are as follows:
  • This information element is required in order to uniquely assign a response message WN to an order message AN.
  • the transmission identity "Transaction ID” TA2 of the "Transaction ID "TA1 from FIG. 3 corresponds exactly.
  • the use of this information element is mandatory.
  • MMS Version This information element gives the version number of the
  • This information element contains the status of the request to send the desired links VK to one or more multimedia messages MM, which was initiated by the request message AN.
  • the status indicates, for example, whether the request could be processed successfully by the MMS server MRS or whether certain errors have occurred. This information element must be listed in every reply message WN.
  • This information element reflects the status achieved by the information element "Resend Notification Status” RS2 in the form of a text. The use of this information element is optional.
  • This information element can be contained in the response message WN. If it exists, there is at least one link VK to the multimedia messages MM requested by the request message AN. This is done, for example, in the form of a list of the originally sent MMS recipients
  • Notification messages NQN or in the form of the corresponding URIs (Uniform Resource Identifiers).
  • FIG. 6 shows a second exemplary embodiment of the response message WN for the message flow from FIG. 2 OMA syntax (see, inter alia, OMA specification OMA-MMS- ⁇ NC- vl_2-20030915-C).
  • the response message WN is called "M-Resend-Notification-conf".
  • the name of the corresponding OMA field can be found in the first column with the designation “field name”, in the second column the corresponding field value and in the third column there is a brief description of the respective OMA field.
  • the individual fields of the response message WN to OMA are explained in more detail below:
  • This mandatory field allows a response message WN to be uniquely assigned to a specific request message AN. This is done using the field value
  • MMS-version-value indicates the corresponding version number of the MMS interface of the MMS server MRS.
  • Field name "X-Mms-Resend-Notification-Status” RS This field must be contained in every response message WN. It indicates the status of the response message WN that was achieved by the request message AN. The status is expressed with the field value "Resend-notification-status-value”.
  • This field can contain the links VK to one or more multimedia messages MN.
  • the corresponding MMS recipient notification message NQN according to the OMA standard is called M-Notification. Ind ".
  • M-Notification Ind ".
  • URI Uniform Resource Identifier
  • further details can also be included, such as the priority of the multimedia message MM or the sender address of the multimedia message MM which shows the link VK.
  • the field value "Notification-details-value" is used as the value for this field.
  • a clear group identification signal GN for the message flow of FIG. 2 in all response messages WN that are transmitted on the basis of a request message AN.
  • the corresponding transaction number "Transaction ID" of the request message TA2 can be used as a unique group identification signal GN and inserted into the
  • Transaction ID Field "Transaction ID" TA4 of the corresponding reply message WN. All response messages WN that are generated on the basis of a request message AN thus use the same transaction number TA4.
  • each of the reply messages WN that have the same unique group Wear identification signal GN, to be provided with a consecutive message number NRN and a total number NGA for the message flow from FIG. 2.
  • the total number NGA corresponds to the number of response messages WN with the same group identification signal GN.
  • seven reply messages WN are transmitted with the same group identification signal GN.
  • the first response message WN which the MMS server MRS sends to the MMS client MUA, is provided with the message number NRN equal to "1" and additionally with the total number NGN of "7".
  • the second reply message WN receives the consecutive message number NRN equal to "2" and again as a total number of NGA "7". Because of the consecutive message number NRN and the total number of NGA, the MMS client MUA is able to clearly determine the absence of one or more reply messages WN and possibly to request it again.
  • the response message WN can be obtained directly from an MMS receiver notification message NQN, which has already been transmitted to the MMS client MUA in the past.
  • the MMS server MRS holds, for example, one or more MMS receiver notification messages NQN for still available multimedia messages MM on its storage device SER.
  • Transaction ID Transaction ID
  • a possible coding of some fields of the request message AN and the response message WN according to the OMA-compliant syntax is explained below with reference to FIG.
  • the field name for several fields is recorded in the left column, some of which are also output in the left column of FIGS. 4 and 6.
  • the middle column is a possible hexadecimal coding is entered and the right column contains a possible OMA-compliant coding of the field value as well as a supplementary description.
  • the hexadecimal coding is used in the OMA-MMS syntax to uniquely identify a specific field within the message.
  • the hexadecimal coding 0x34 corresponds to the field with the field name "X-Mms-Notification-Filter" FV ⁇ ⁇ .
  • BNF Bakus wall
  • the hexadecimal coding is 0x35.
  • the hexadecimal coding is 0x36.
  • Class identifier Personnel
  • Automobile Automobile
  • 0x3A is selected as the value for the hexadecimal coding.
  • the value for the hexadecimal coding is set to 0x3B.
  • Error-permanent-service-denied Success ⁇ Octet 128>
  • ND4 The hexadecimal value of 0x3D is selected for this field.
  • a possible representation of the field value for this field is:
  • selection criteria and / or exclusion criteria can be used together in the request message AN.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Verfahren zur Wiedererlangung von mindestens einer fehlenden d.h. zum Beispiel versehentlich auf einem MMS-Client gelöschten, Verknüpfung (VK) auf eine oder mehrere, auf einem MMS-Server (MRS) abgelegte Multimidia Nachrichten (MM) durch den MMS-Client (MUA), sowie ein Kommunikationsgerät und eine Netzwerkkomponente. Zur Wiedererlangung von mindestens einer fehlenden Verknüpfung (VK) auf eine oder mehrere, auf einem MMS-Server (MRS) abgelegte Multimedia Nachrichten (MN) durch den MMS-Client (MUA) wird durch den MMS-Client (MUA) an den MMS-Server (MRS) mindestens eine Aufforderungsnachricht (AN) mit der Aufforderung zum Versenden mindestens einer fehlenden Verknüpfung (VK) auf eine oder mehrere Multimedia Nachrichten (MN) verschickt. Durch den MMS-Server (MRS) wird nach Erhalt der Aufforderungsnachricht (AN) mindestens eine dazugehörige Antwortnachricht (WN) an den MMS-Client (MUA) geschickt, die mindestens eine der fehlenden Verknüpfungen (AN) auf die eine oder die mehrere Multimedia Nachrichten (MN) enthält.

Description

VERFAHREN ZUR WIEDERERLANGUNG VON EINER AUF EINEM MMS-CLIENT NICHT VERFUGBAREN VERKNÜPFUNG AUF EINE AUF EINEM MMS-SERVER ABGELEGTE MULTIMEDIA NACHRICHT DURCH EINEN MMS-CLIENT
Beschreibung
Verfahren zur Wiedererlangung von mindestens einer verlorenen Verknüpfung auf eine oder mehrere auf einem MMS-Server abge- 5 legte Multimedia Nachrichten durch einen MMS-Client, ein Kommunikationsgerät und eine Netzwerkkomponente
Das Mobilfunksystem GSM (GSM - Global System for Mobile Communications) bietet neben der Sprachtelefonie auch die Mög- 10 lichkeit kurze Textnachrichten von bis zu 160 Zeichen Länge zu versenden beziehungsweise zu empfangen. Dieser Service heißt SMS (SMS - Short Message Service) (siehe beispielsweise technische Spezifikation 3GPP TS23.040, Version 6.0.1).
15 Als Nachfolger dieses überaus erfolgreichen Dienstes ist MMS (MMS - Multimedia Messaging Service) eingeführt worden (siehe unter anderem technische Spezifikation 3GPP TS22.140, Version 6.0.0 und TS23.140, Version 6.0.0). Dieser Dienst kann in verschieden Mobilfunksystemen, wie beispielsweise in GSM,
20 GPRS (GPRS - General Package Radio Services) , EDGE (EDGE - Enhanced Data Rates for GSM Evolution) oder UMTS (UMTS - Universal Mobile Telecommunications System) eingesetzt werden. Der MMS-Dienst ermöglicht das mobile Versenden und den mobilen Empfang von Nachrichten mit multimedialen Inhalten,
25 wie beispielsweise Textnachrichten, Sprachnachrichten oder
Bildnachrichten. Diese können ein deutlich größeres Datenvolumen als die SMS-Nachrichten aufweisen. Eine Nachricht in MMS wird als Multimedia Nachricht (MM - Multimedia Message) bezeichnet .
30
Ein charakteristisches Merkmal von MMS ist, dass bei der Zustellung einer oder mehrerer Multimedia Nachrichten an den MMS-Empfänger zwischen dem sogenannten Push-Modus und dem Pull—Modus unterschieden wird. Bei dem Push-Modus wird eine
35 ankommende Multimedia Nachricht unverzüglich vom dafür zuständigen MMS-Netzwerkelement an den MMS-Empfänger, beispielsweise an ein GPRS-Mobilfunkgerät, übertragen. Im söge- nannten Pull-Modus, be dem der MMS-Empfänger zunächst nur über eine am zuständigen MMS-Netzwerkelement eingetroffene Multimedia Nachricht mittels einer MMS-Empfangerbenachπchti- gung informiert wird, kann der MMS-Empfanger daraufhin selbst entscheiden, ob bzw. wann es diese Multimedia Nachricht herunterladen mochte. In der Praxis hat sich gezeigt, dass Kunden und MMS-Dienstleistungsanbieter heutzutage bevorzugt den Pull-Modus in MMS verwenden. Eine Multimedia Nachricht bleibt solange auf dem dafür zustandigen MMS-Netzwerkelement verfug- bar, bis beispielsweise der MMS-Empfanger diese herunterladt oder bis die Gültigkeit der Multimedia Nachricht abgelaufen ist. Alternativ w rd die Multimedia Nachricht durch das zuständige Netzwerkelement geloscht. Um einen Herunterladevorgang einer Multimedia Nachricht durch den MMS-Empfänger mi- tueren zu können, bekommt der MMS-Empfanger in der MMS-
Empfängerbenachrichtigung eine Verknüpfung auf die entsprechende Multimedia Nachricht, die sich auf dem zugehörigen MMS-Ne zwerkelement befindet. Diese Verknüpfung wird als URI (URI - Uniform Ressource Identifier) bezeichnet.
Somit ist es nach dem Stand der Technik zwingend notwendig, dass der MMS-Empfänger die Verkn pfungen der Multimedia- Messages behält, die er zu einem späteren Zeitpunkt herunterladen mochte. Loscht ein MMS-Empfanger oder ein Nutzer bei- spielsweise eine MMS-Empfängerbenachπchtigung und/oder auch die Verkn pfung vor dem Herunterladen der zugehörigen Multimedia Nachricht versehentlich, so besitzt er später keine Möglichkeit mehr, auf diese Multimedia Nachricht zuzugreifen. Eine ähnliche Problematik tritt auf, wenn die MMS-Empfanger- benachrichtigung bzw. die Verknüpfung einer Multimedia Nachricht zunächst in einem ersten Endgerat gespeichert wird. Nun wechselt der MMS-Empfanger sein Endgerät und möchte mittels eines zweiten Endgerats auf die entsprechenden Multimedia Nachrichten zugreifen. Dieser Sachverhalt tritt beispielswei- se auf, wenn ein MMS-Empfänger seine Mobilfunk-SIM-Karte (SIM - Subscriber Identity Module) aus einem ersten Mobilfunktele- fon herausnimmt und in ein zweites Mobilfunktelefon einlegt. Wenn nun die Mobilfunk-SIM-Karte keine MMS-Unterstützung anbietet, sind die MMS-Empfängerbenachrichtigungen, beziehungsweise die Verknüpfungen zu den Multimedia Nachrichten lediglich in dem ersten Mobiltelefon vorhanden. Somit sind diese im zweiten Mobilfunktelefon nicht verfügbar. Der gleiche
Sachverhalt tritt auf, wenn eines der Endgeräte kein Mobilfunktelefon ist, d. h. z.B: das erste Endgerät ist ein Laptop und das zweite Endgerät ist ein PDA (PDA -Personal Digital Assistent) .
Der Erfindung liegt die Aufgabe zu Grunde, eine einfache und effiziente Möglichkeit zur Wiedererlangung von mindestens einer fehlenden Verknüpfung auf eine oder mehrere Multimedia Nachrichten in MMS bereitzustellen.
Diese Aufgabe wird durch folgendes erfindungsgemäße Verfahren gelöst: Verfahren zur Wiedererlangung von mindestens einer fehlenden Verknüpfung auf eine oder mehrere, auf einem MMS- Server abgelegte, Multimedia Nachrichten durch einen MMS- Client, indem durch den MMS-Client an den MMS-Server mindestens eine Aufforderungsnachricht mit der Aufforderung zum Versenden mindestens einer fehlenden Verknüpfung auf eine oder mehrere Multimedia Nachrichten verschickt wird, und indem durch den MMS-Server nach Erhalt der Au forderungsnach- rieht mindestens eine dazugehörige Antwortnachricht an den
MMS-Client geschickt wird, die mindestens eine der fehlenden Verknüpfungen auf die eine oder die mehreren Multimedia Nachrichten enthält .
Durch das er indungsgemäße Verfahren kann der MMS-Client bei Bedarf jederzeit eine oder mehrere fehlende Verknüpfungen auf eine oder mehrere Multimedia Nachrichten wiedererlangen. Das Verfahren ist erweiterbar hinsichtlich der Anzahl an Verknüpfungen, die an den MMS-Client übertragen werden können. Da- durch, dass sowohl eine einzelne Verknüpfung als auch gleichzeitig mehrere Verknüpfungen in einer einzelnen Antwortnachricht übertragen werden, ergibt sich eine einheitliche Abfra- gestruktur. Aufgrund der einhei lichen Abfragestruktur des Verfahrens können also mehrere fehlende Verknüpfungen in einer einzigen Antwortnachricht zusammengefasst werden und somit bandbreiteneffizient übertragen werden. Diese Vorteile ergeben sich auch, wenn der MMS-Client gewechselt wird und dadurch das Wiedererlangen einer oder mehrerer fehlender Verknüpfungen notwendig wird.
Die Erfindung betrifft auch ein Kommunikationsgerät mit einem Modul zur Wiedererlangung von mindestens einer fehlenden Verknüpfung auf eine oder mehrere, auf einem MMS-Server abgelegte Multimedia Nachrichten durch einen MMS-Client, mit einer Sendeeinheit zum Abschicken mindestens einer Aufforderungsnachricht mit der Aufforderung zum Versenden mindestens einer fehlenden Verknüpfung auf eine oder mehrere Multimedia Nachrichten und mit einer Empfangseinheit zur Entgegennahme mindestens einer vom MMS-Server nach Erhalt der Aufforderungsnachricht abgeschickten, zugehörigen Antwortnachricht, die mindestens eine der fehlenden Verknüpfungen auf die eine oder die mehreren Multimedia Nachrichten enthält.
Weiterhin betrifft die Erfindung eine Netzwerkkomponente mit einem Modul zur Wiedererlangung von mindestens einer fehlenden Verknüpfung auf eine oder mehrere, auf einem MMS-Server abgelegte Multimedia Nachrichten durch einen MMS-Client, mit einer Empfangseinheit zum Entgegennehmen mindestens einer Aufforderungsnachricht mit der Aufforderung zum Versenden mindestens einer fehlenden Verknüpfung auf eine oder mehrere Multimedia Nachrichten, die in einer Speichereinrichtung netzwerkseitig noch verfügbar sind, mit einer Logikeinheit zum Erstellen, mindestens einer dazugehöriger Antwortnachricht mit mindestens einer fehlenden Verknüpfung auf eine oder mehrere Multimedia Nachrichten nach Erhalt der Aufforderungsnachricht, sowie mit einer Sendeeinheit zum Verschicken mindestens einer zugehörigen Antwortnachricht an den MMS- Client . Sonstige Weiterbildungen der Erfindung sind in den Unteransprüchen wiedergegeben .
Die Erfindung und ihre Weiterbildungen werden nachfolgend an- hand von Zeichnungen näher erläutert.
Es zeigen:
Figur 1 in schematischer Darstellung einen MMS-Server und einen MMS-Client, sowie den Nachrichtenfluss für den Pull-Modus, wobei dem MMS-Client eine Verknüpfung auf eine Multimedia Nachricht mittels einer Benachrichtigungsnachricht angezeigt wird und dieser die Multimedia Nachricht vom MMS-Server lädt,
Figur 2 in schematischer Darstellung einen MMS-Server und einen MMS-Client, sowie den Nachrichtenfluss nach einem ersten Ausführungsbeispiel des er indungsgemäßen Verfahrens, wobei der MMS-Client mindestens eine Verknüpfung auf mindestens eine Multimedia
Nachricht mittels einer Aufforderungsnachricht anfragt und ihm mindestens eine der benötigten Verknüpfungen mittels mindestens einer Antwortnachricht zugesandt wird,
Figur 3 in tabellarischer Form gemäß der OMA-konformen Kodierung einige der OMA-MMS-Kopffelder für eine MMS- Nac richt (PDU - Protocol Data Unit) mit einem Namen "M—Resend—Notification . conf" und "M-Resend- Notification. req" für den Nachrichtenfluss für Figur 2,
Figur 4 in tabellarischer Form die Aufforderungsnachricht im Nachrichten luss von Figur 2 nach 3GPP-Syntax mit einem Namen "MMl_resend_notification. REQ" und ihre Informationselemente, Figur 5 in tabellarischer Form die Antwortnachricht im
Nachrichten luss von Figur 2 nach 3GPP-Syntax mit einem Namen "MMl_resend_notification.RES" und ihre Informationselemente,
Figur 6 in tabellarischer Form die Aufforderungsnachricht im Nachrichten luss von Figur 2 nach OMA-MMS-Syntax mit einem Namen "M-Resend-Noti ication. req" und ihre Felder,
Figur 7 in tabellarischer Form die Antwortnachricht im
Nachrichtenfluss von Figur 2 gemäß OMA-MMS-Syntax mit einem Namen "M-Resend-Notification. conf" und ihre Felder, und
Figur 8 in tabellarischer Form gemäß der OMA-konformen Kodierung eine mögliche Erweiterung des Feldes mit dem Namen "X-Mms-Priority-Filter" der Aufforderungsnachricht im Nachrichtenfluss von Figur 2 nach OMA-MMS-Syntax mit dem Namen "M-Resend-
Notification . req" .
Elemente mit gleicher Funktion und Wirkungsweise sind in den Figuren 1 mit 8 mit denselben Bezugszeichen versehen.
In Figur 1 ist ein Ausschnitt einer MMS-Architektur nach heutigem Stand der Technik aus Sicht von 3GPP dargestellt . Hiermit wird ein MMS-Dienst (MMS - Multimedia Messaging Service) , siehe technische Spezifikationen 3GPP (3GPP - Third Generati- on Partnership Project) TS22.140, Version 6.3.0 und 3GPP
TS23.140, Version 6.3.0, realisiert. Dieser ermöglicht das Versenden und Empfangen von Nachrichten mit multimedialen Inhalten. Eine solche Nachricht wird als Multimedia Nachricht MM bezeichnet und kann mehrere MM-Elemente von unterschiedli- chen Dateitypen, wie beispielsweise Audio oder Video, und Dateiformate, wie beispielsweise GIF oder JPG, umfassen. Der MMS-Dienst kann in verschiedenen Mobilfunksystemen wie bei- spielsweise GSM (Global System for Mobile), GPRS (GPRS - General Package Radio Services) oder auch UMTS (UMTS - Universal Mobile Telecommunications System) eingesetzt werden.
Auf der linken oberen Seite ist ein MMS-Server MRS, der in 3GPP auch als MMS-Relay/Server bezeichnet wird, dargestellt. Der MMS-Server MRS hat unter Anderem folgende Aufgaben:
- Speicherung von eingehenden Multimedia Nachrichten MM, die beispielsweise von einem anderen MMS-Server kommen,
- Verarbeitung und Austausch von Kontrollinformationen mit einem MMS-Client MUA,
- Empfangen und Senden von Multimedia Nachrichten MM von und/oder an einen MMS-Client MUA.
Der MMS-Server MRS umfasst eine Empfangseinheit EME1 zum Entgegennehmen von Kontrollinformationen und/oder Multimedia Nachrichten MM. Daneben ist eine Sendeeinheit SEE1 zum Versenden von Kontrollinformationen und Multimedia Nachrich- ten MM vorgesehen. Es gibt eine Speichereinheit SER zum Ablegen von Multimedia Nachrichten MM und Kontrollinformationen. Die Speichereinheit SER kann gegebenenfalls netzwerkseitig an den MMS-Server MRS angebunden sein. Eine Logikeinheit LEE1 steuert den MMS-Server MRS. Schließlich gewährleistet ein Verbindungsnetzwerk VX1 den Informationsaustausch zwischen den einzelnen Einheiten SEE1, LEE1, EME1 und SER.
In Figur 1 ist auch der MMS-Client MUA zu sehen. In 3GPP wird dieser MMS-Client MUA als MMS-User-Agent bezeichnet. Dieser ist beispielsweise als Softwareprogramm auf einem Mobilfunkgerät nach GSM-Standard oder UMTS-Standard oder auf einem an ein Mobilfunkgerät angeschlossenes Gerät, wie beispielsweise einem Laptop, implementiert. Dieser hat die Aufgabe, den Teil des MMS-Dienstes zu realisieren, der beispielsweise auf einem Mobilfunkgerät benötigt wird. Alternativ kann der MMS-Client MUA auch auf einem Festnetzgerät nach ISDN (Integrated Sub- scπber Digital Network) oder in einer an das Intranet oder Internet angeschlossenen Rechnereinheit implementiert werden.
Der MMS-Client MUA umfasst eine Empfangseinheit EME2 zum Ent- gegennehmen von Kontrollinformationen und/oder Multimedia
Nachrichten MM sowie eine Sendeeinheit SEE2 zum Versenden von Kontrollinformationen. Zusätzlich ist eine Logikeinheit LEE2 zum Steuern des MMS-Clients MUA und ein Verbindungsnetzwerk vx2 vorgesehen, das den Informationsaustausch zwischen den einzelnen Einheiten SEE2, EME2 und LEE2 gewährleistet.
Im Folgenden wird die Zustellung einer Multimedia Nachricht MM an den MMS-Client MUA nach dem sogenannten Pull-Modus anhand von Figur 1 näher erläutert . Nach Emp ang einer neuen Multimedia Nachricht MM im Zuständigkeitsbereich des MMS-
Servers MRS, beispielsweise von einem zweiten MMS-Server MRS, wird diese neu eingetroffene Multimedia Nachricht MM m einer netzwerkseitig angebundenen Speichereinheit SER abgelegt. Daraufhin übertragt die Sendeeinheit SEE1 des MMS-Servers MRS eine MMS-Empfanger—Benachrichtigungsnachricht NQN an den MMS- Client MUA. Diese MMS-Empfänger-Benachπchtigungsnachricht NQN w rd n 3GPP als MMS-Notification bezeichnet und umfasst eine Verknüpfung VK auf mindestens eine im netzwerkseitig angebundenen Speicherelement SER abgelegten Multimedia Nach— rieht MM. Diese Verknüpfung VK wird in 3GPP auch als URI (U- niform Resource Identifier) bezeichnet. Nach Erhalt der MMS- Empfänger-Benachrichtigungsnachricht NQN quittiert der MMS- Client MUA den Empfang mittels der MMS-Empfanger-Bestati- gungsnachricht NSN . Der MMS-Client MUA kann nun entweder mit Hilfe der Verknüpfung VK die Multimedia Nachricht MM sofort auf sein Gerat laden oder die MMS-Empfanger-Benachπchti- gungsnachricht NQN als auch die Verknüpfung VK für ein spateres Abrufen der Multimedia Nachricht MM abspeichern. Dies kann beispielsweise auf der Mobilfunk-SIM-Karte (SIM - Sub- scriber Identity Module) oder der Mobilfunk-UICC (UICC - Universal Integrated Circuit Card) des Mobilfunkgerates, auf dem sich der MMS-Client MUA befindet, abgespeichert werden. Im Pull-Modus wird die Multimedia Nachricht MM im MMS-Server MRS bis zum Ablauf der Gültigkeit gespeichert. Die MMS-Empfänger- Benachrichtigungsnachricht NQN umfasst auch eine Gültigkeitsdauer der Multimedia Nachricht MM. Bei Ablauf der Gültig- keitsdauer wird die Multimedia Nachricht MM samt zugehöriger Verknüpfung VK aus der Speichereinheit SER des MMS-Servers MRS gelöscht.
Nach Erhalt der MMS-Empfänger-Benachrichtigungsnachricht NQN beziehungsweise der Verknüpfung VK auf eine oder mehrere Multimedia Nachrichten MM hat der MMS-Client MUA später die Möglichkeit, eine oder mehrere Multimedia Nachrichten MM vom MMS-Server MRS herunterzuladen. Wie in Figur 1 ersichtlich, schickt dazu der MMS-Client MUA eine MM-Anforderungsnachricht RQN zu dem MMS-Server MRS, die mindestens die Verknüpfung VK auf die zu herunterladende Multimedia Nachricht MM enthält. Für den Fall, dass die angeforderte Multimedia Nachricht MM auf dem MMS-Server MRS noch verfügbar ist, schickt dieser mittels einer MM-Antwortnachricht RSN die angeforderte Multi- media Nachricht MM zum anfragenden MMS-Client MUA. Dieser Vorgang wird auch als "Herunterladen" bezeichnet.
Für den Fall, dass die MMS—Empfänger-Benachrichtigungsnachricht NQN, beziehungsweise die Verknüpfung VK auf eine oder mehrere Multimedia Nachrichten MM dem MMS-Client MUA fehlen, besteht für den MMS-Client MUA zunächst keine Möglichkeit, die benötigten Multimedia Nachrichten MM vom MMS-Server MRS herunter zuladen . Dieser Sachverhalt tritt auch auf, nachdem eine oder mehrere Verknüp ungen VK auf eine oder mehrere Mul- timedia Nachrichten MM, die dem MMS-Client MUA bereits in der Vergangenheit zugestellt wurden, durch versehentliches Löschen verloren wurden.
Zur Wiedererlangung von mindestens einer Verknüpfung VK auf mindestens eine Multimedia Nachricht MM schickt der MMS- Client MUA entsprechend dem Signalfluss von Figur 2 mittels seiner Sendeeinheit SΞE2 eine Anforderungsnachricht AN an den MMS-Server MRS. Diese Anforderungsnachricht AN wird durch die Empfangseinheit EMEl des MMS-Servers MRS entgegengenommen und durch die Logikeinheit LEE1 ausgewertet. Falls eine oder mehrere Multimedia Nachrichten MM für den anfragenden MMS-Client MUA in der Speichereinrichtung SER zur Verfügung stehen, schickt die Sendeeinheit SEE1 des MMS-Servers MRS eine dazugehörige Antwortnachricht WN an den MMS-Client MUA. Diese Antwortnachricht WN umfasst mindestens eine der fehlenden Verknüpfungen VK. In der Praxis kann es zweckmäßig sein, dass die Antwortnachricht WN auch eine oder mehrere vollständige
MMS-Empfänger-Benachrichtigungsnachrichten NQN enthält . Diese können eine Kopie der möglicherweise in der Vergangenheit ü— bertragenen MMS-Ξmpfänger-Benachrichtigungsnachrichten NQN sein, die gegebenenfalls auch in der netzwerkseitigen Spei- chereinrichtung SER des MMS-Servers MRS abgespeichert sind. Nach Erhalt der dazugehörigen Antwortnachricht WN kann der MMS-Client MUA anhand der empfangenen Verknüpfungen VK eine oder mehrere Multimedia Nachrichten MM herunterladen. Gemäß der 3GPP-Syntax kann die Aufforderungsnachricht AN mit einem Namen "MMl_resend_notification. REQ" und die dazugehörige Antwortnachricht WN mit "MMl_resend_notification. RES" bezeichnet werden.
In der Praxis kann es jedoch vorteilhaft sein, mittels der Aufforderungsnachricht AN nicht alle Verknüpfungen VK der auf dem MMS-Server MRS enthaltenen Multimedia Nachrichten MM anzufordern, sondern eine gezielte Auswahl zu treffen. Gemäß einer weiteren alternativen Weiterbildung der Erfindung wird der Anforderungsnachricht AN durch mindestens ein Filterkri- terium erweitert, das von allen Multimedia Nachrichten MM der jeweilig zu übertragenen Verknüpfung VK erfüllt wird. Hierbei wird mindestens eines der folgenden Filterkriterien FW eingefügt, wobei sich der jeweilige Filter auf eines der Felder einer Multimedia Nachricht MM bezieht:
a) Filter für Absender FAD: Die Angabe dieses Filters erlaubt es, dass nur Verknüpfungen VK zu Multimedia Nachrichten MM geschickt werden, die von einer bestimmten Absenderadresse, folglich von einem bestimmten Absender, versandt wurden.
b) Filter für Empfänger FEM:
Die Angabe dieses Filters erlaubt es, dass nur Verknüpfungen VK zu Multimedia Nachrichten MM geschickt werden, die an eine bestimmte Empfängeradresse, folglich an einen be- stimmten Adressaten, versandt wurden.
c) Filter für Nachrichtentyp FMM:
Durch die Angabe des Nachrichtentyps FMM werden nur diejenigen Verknüpfungen VK berücksichtigt, bei denen die zuge- hörige Multimedia Nachricht MM einer bestimmten Klasse zugehört, beispielsweise der Klasse "Werbung".
d) Filter für Datum und/oder Uhrzeit FDU:
Mit diesem Filter ist es möglich, bei der Auswahl der durch die Antwortnachricht WN zu übertragenden Verknüpfungen nur diejenigen Multimedia Nachrichten MM zu berücksichtigen, die an einem bestimmten Datum und/oder Uhrzeit verschickt wurden, beispielsweise am 15. Dezember 2003.
e) Filter für Priorität FPI :
Durch diesen Filter werden nur diejenigen Multimedia Nachrichten MM berücksichtigt, die einer bestimmten Priorität entsprechen, beispielsweise nur die Multimedia Nachrichten MM, die mit der Priorität "hoch" gekennzeichnet sind.
f) Filter für Titel FTI :
Durch Angabe dieses Filters werden nur diejenigen Multimedia Nachrichten MM berücksichtigt, die einen bestimmten Titel oder auch ein besonderes Schlüsselwort im Titel ent- halten. Für die Praxis kann es auch vorteilhaft sein, durch die Filterkriterien FW nicht nur bestimmte Kriterien auszuwählen, sondern auch bestimmte Kriterien auszuschließen. Hierzu werden die Filterkriterien FW der folgenden Filter durch bei- spielsweise eine Kennung wie zum Beispiel ein Flag ergänzt, das Aufschluss darüber gibt, ob es sich um ein Auswahlkriterium oder/und ein Ausschlusskriterium handelt :
- Filter für Absender FAD - Filter für Empfänger FEM
- Filter für Nachrichtentyp FMM
- Filter für Datum und/oder Uhrzeit FDU
- Filter für Priorität FPI
- Filter für Titel FTI
Somit ist es möglich, dass eine Aufforderungsnachricht AN sowohl Auswahlkriterien als auch Ausschlusskriterien enthält. Beispielsweise wird durch eine Aufforderungsnachricht AN signalisiert, dass die zu suchenden Multimedia Nachrichten MM, die durch die Aufforderungsnachricht AN berücksichtigt werden, im Titel das Wort "bahn" enthalten, aber Multimedia Nachrichten MM, die den Titel "Eisenbahn" einschließen, ausgeschlossen werden.
Daneben kann es zweckmäßig sein, nur diejenigen Verknüpfungen VK auf eine oder mehrere Multimedia Nachrichten MM anzufordern, die auf dem MMS-Client MUA nicht verfügbar sind. Hierzu enthält ein Verknüpfungskriterium VW eine oder mehrere Verknüpfungen VK, die nicht mehr mittels der Antwortnachricht WN signalisiert werden. Es ist auch möglich, dass an Stelle der Verknüpfung VK eine oder mehrere MMS-Empfänger-Benachrich- tigungsnachrichten NQN enthalten sind, die auch eine eindeutige Zuordnung auf eine bestimmte Verknüpfung VK gewährleisten.
Gegebenenfalls ist es auch möglich, mehr als ein Filterkriterium FW und/oder Verknüpfungskriterium VW in einer Aufforde- rungsnachricht AN zu verwenden. Hierzu können die einzelnen Filterkriterien FW und/oder Verknüpfungskriterien VW miteinander in Relation gebracht werden. Unter einer Relation sind hierbei Logikausdrücke wie beispielsweise "UND", "ODER" oder "EXKLUSIV-ODER" als auch Größenausdrücke wie zum Beispiel
"GRÖSSER", "GRÖSSER-GLEICH", "KLEINER" oder "KLEINER-GLEICH" zu verstehen. Im vorliegenden Ausführungsbeispiel sind diejenigen Multimedia Nachrichten MM zu berücksichtigen, die an drei verschiedenen Tagen abgeschickt wurden, wie zum Beispiel am 14.12.2003, 15.12.2003 und am 1.1.2004. Somit kann die
Aufforderungsnachricht AN drei verschiedene Filter für Datum und/oder Uhrzeit FDU enthalten, die mittels des Logikausdrucks "ODER" die gewünschte Relation "15.12.2003 ODER 14.12.2003 ODER 1.1.2004" ermöglicht.
Figur 3 enthält eine mögliche Implementierung der Aufforderungsnachricht AN für den Nachrichtenfluss von Figur 2 mit den Filtern für das Filterkriterium FW und dem Verknüpfungskriterium VW in Form der Syntax nach 3GPP, siehe technische Spezifikationen TS 22.140, Version 6.3.0 und TS 23.140, Version 6.3.0. In 3GPP ist es beispielsweise möglich, die Aufforderungsnachricht AN mit dem Namen
"MMl_resend_notification .REQ" zu versehen. Im Folgenden wird näher auf die einzelnen Informationselemente der Figur 3 ein- gegangen, wobei die erste Spalte den Namen des entsprechenden Informationselementes angibt, die zweite Spalte die Nutzung des entsprechenden Informationselementes innerhalb der Auf¬ forderungsnachricht AN wiedergibt, und die dritte Spalte eine Kurzbeschreibung enthält :
- Informationselement "Message Type" MT1 :
Dieses Informationselement muss in der Aufforderungsnachricht AN enthalten sein und identifiziert diese Nachricht als Aufforderungsnachricht, also als Nachricht mit dem Na- men "MMl_resend_notification. REQ" .
Informationselement "Transaction ID" TA1 : Dieses Informationselement muss in der Aufforderungsnachricht AN enthalten sein und wird dazu benutzt, eine eindeutige Zuordnung zwischen der Aufforderungsnachricht AN und der Antwortnachricht WN zu gewährleisten.
Informationselement "MMS-Version" MV1 :
Dieses Informationselement muss in der Aufforderungsnachricht AN enthalten sein und gibt die Version des MMS- Interface des MMS-Client MUA an.
Informationselement "Notification filter" FVKl : Die Benutzung dieses Informationselements innerhalb der Aufforderungsnachricht ist optional. Es entspricht dem Verknüpfungskriterium FVK.
Informationselement "Sender filter" FAD1: Die Verwendung dieser Filterkriteriums ist nicht verpflichtend. Es realisiert das Filter für Absender FAD.
- Informationselement "Recipient filter" FEM1 :
Die Verwendung dieser Filterkriteriums ist nicht verpflichtend. Es realisiert das Filter für Empfänger FEM.
- Informationselement "Message class filter" FMM1 : Dies ist ein optionales Informationselement. Es realisiert den Filter für Nachrichtentyp FMM.
- Informationselement "Date and time filter" FDU1 :
Dieses Informationselement ist optional und realisiert das Filter für Datum und/oder Uhrzeit FDU.
- Informationselement "Priority filter" FPIl:
Die Benutzung dieses Elementes ist optional . Es identifiziert das Informationselement, das dem Filter für Priori- tat FPI entspricht.
- Informationselement "Subject filter" FTI1: Die Benutzung dieses Informationselementes ist optional und realisiert den Filter für den Titel FTI .
Alle optionalen Informationselemente können auch mehrmals in einer Aufforderungsnachricht AN enthalten sein.
In Figur 4 ist eine weitere Ausführungsform der Aufforderungsnachricht AN für den Nachrichtenfluss von Figur 2 zu sehen, die der Syntax nach den OMA-Standards OMA-WAP-MMS-ENC- vl_1.20021030-C, OMA-WAP-MMS-CTR-vl_l-30021031-V und OMA-WAP- MMS-ARC-vl_l-20021101-C entspricht. In OMA wird die Aufforderungsnachricht AN mit dem Namen "M-Resend-Notification. req" bezeichnet . In Figur 4 sind in der ersten Spalte die Feldnamen der Aufforderungsnachricht AN zu finden, in der zweiten Spalte der entsprechende Feldwert und in der dritten Spalte ist eine kurze Beschreibung der Funktion des entsprechenden Feldes verzeichnet. In dieser Aufforderungsnachricht AN sind folgende Feldnamen enthalten:
- Feldname "X-Mms-Message-Type" MT3 :
Dieses Feld charakterisiert eindeutig den PDU-Typ (PDU - Protocol Data Unit) mit dem Namen "M-Resend- Notification . req" und muss in der Au forderungsnachricht AN enthalten sein. Der Feldwert nach OMA—Syntax lautet: "Message-type-value = m-resend-notification-req" .
Feldname "X-Mms-Transaction-ID "TA3:
Dieses Feld erlaubt eine eindeutige Zuordnung zwischen der Auf orderungsnachricht AN und einer oder mehrerer dazuge- höriger Antwortnachrichten WN. Es muss in jeder Anforderungsnachricht AN enthalten sein. Der entsprechende Feldwert lautet "Transaction-id-value" .
Feldname "X-Mms-MMS-Version" MV3 : Dieses Feld enthält die Versionsnummer des MMS-Interface des MMS-Clients MUA und muss in der Aufforderungsnachricht AN enthalten sein. Der Feldwert für dieses Feld ist "MMS- version-value" .
- Feldname "X-Mms-Notiflcation-Filter" FVK3 : Dieses optionale Feld gibt diejenigen Verknüpfungen VK auf eine oder mehrere Multimedia Nachrichten MM an, die vom MMS-Server MRS nicht geschickt werden. Dies entspricht dem Verknüpfungskriterium VW. Als Verknüpfung VK kann hierbei beispielsweise die rransaction-ID einer vorher geschickten MMS-Empfänger-Benachrichtigungsnachricht NQN benutzt werden oder auch auf die Verknüpfung VK auf mindestens eine Multimedia Nachricht MM beispielsweise der URI (URI - Uniform Ressource Identifier) . Als Feldwert wird der Wert "Sender-filter-value" verwendet .
Feldname "X-Mms-Sender-Filter" FAD3:
Dieses optionale Feld definiert den Filter für den Absender FAD. Es benutzt als Feldwert "Sender-filter-value" .
- Feldname "X-Mms-Recipient-Filter" FEM3 :
Dieses optionale Feld definiert den Filter für Empfänger FAD. Es benutzt als Feldwert "Receiver-filter-value" .
- Feldname "X-Mms-Message-Class-Filter" FMM3 : Dieses optionale Feld repräsentiert den Filter für Nachrichtentyp FMM. Es verwendet als Feldwert "Message-class- filter-value" .
- Feldname "X-Mms-Date-And-Time-Filter" FDU3 : Die Verwendung dieses Feldes ist optional. Es erlaubt die Angabe des Filters für Datum und/oder Uhrzeit FDU. Als Feldwert wird der Wert "Date-and-time-filter-value" verwendet .
- Feldname "X-Mms-Priority-Filter" FPI3: Die Verwendung dieses Feldes ist optional. Mit Hilfe dieses Filters wird das Filter für Priorität FPI realisiert. Der entsprechende Feldwert lautet "Priority-filter-value" .
- Feldname "X-Mms-Subject-Filter" FTI3:
Dieses Feld gibt den Filter für Titel FTI an. Die Benutzung dieses Feldes ist optional. Als Feldwert wird der wert "Sub ect-filter-value" eingesetzt.
Die optionalen Felder können einmal oder mehrmals innerhalb der Aufforderungsnachricht AN verwendet werden.
Im Folgenden werden zwei Ausführungsbeispiele für eine Antwortnachricht WN für den Nachrichtenfluss von Figur 2 aufge- zeigt. In Figur 5 ist ein erstes Beispiel aufgelistet, das der 3GPP-Syntax (siehe 3GPP Technische Spezifikation TS 22.140 Version 6.3.0) entspricht. Hierbei wird die Antwortnachricht WN beispielsweise mit dem Namen "MMl_resend_notification .RES" bezeichnet. In Figur 5 sind für die Antwortnachricht WN in der linken Spalte die möglichen Informationselemente zu sehen, in der mittleren Spalte ist deren Benutzung zu finden und in der rechten Spalte ist eine kurze Beschreibung aufgelistet. Die möglichen Informationselemente der Antwortnachricht WN nach 3GPP lauten folgender- maßen:
- Informationselement "Message Type" MT2 :
Die Verwendung dieses Informationselementes ist verpflichtend. Es wird verwendet, um diese Nachricht eindeutig als 3GPP-Antwortnachricht WN mit dem Namen
"MMl_resend_notification .RES" zu markieren.
Informationselement "Transaction ID" TA2 :
Dieses Informationselement wird benötigt, um eine Antwort- nachricht WN eindeutig einer Auf orderungsnachricht AN zuzuordnen, in der Praxis ist es zweckmäßig, dass die Übertragungsidentität "Transaction ID" TA2 der "Transaction ID" TA1 aus Figur 3 exakt entspricht. Die Verwendung dieses Informationselementes ist verpflichtend.
Informationselement "MMS Version" MV2 : Dieses Informationselement gibt die Versionsnummer des
MMS-Interface des MMS-Servers MRS an. Dieses muss in jeder Antwortnachricht WN enthalten sein.
- Informationselement "Resend notification Status" RS2 : Dieses Informationselement enthält den Status der Aufforderung zum Versenden der gewünschten Verknüpfungen VK auf eine oder mehrere Multimedia Nachrichten MM, der durch die Aufforderungsnachricht AN initiiert wurde. Der Status zeigt beispielsweise an, ob die Aufforderung erfolgreich durch den MMS-Server MRS abgearbeitet werden konnte oder ob bestimmte Fehler aufgetreten sind. Dieses Informationselement muss in jeder Antwortnachricht WN aufgeführt sein.
Informationselement "Resend notification Status text" RT2 : Dieses Informationselement gibt den durch das Informationselement "Resend Notification Status" RS2 erreichten Status in Form eines Textes wieder. Die Verwendung dieses Informationselementes ist optional .
Informationselement "Notification details" ND2 :
Dieses Informationselement kann in der Antwortnachricht WN enthalten sein. Wenn es vorhanden ist, gibt es mindestens eine Verknüpfung VK zu den durch die Aufforderungsnachricht AN angefragten Multimedia Nachrichten MM wieder. Dies geschieht beispielsweise in Form einer Liste der ursprünglich geschickten MMS-Empfänger-
Benachrichtigungsnachrichten NQN oder in Form der entsprechenden URI ' s (Uniform Ressource Identifiers) .
In Figur 6 ist ein zweites Ausführungsbeispiel für die Antwortnachricht WN für den Nachrichtenfluss aus Figur 2 OMA- Syntax (siehe unter anderem OMA-Spezifikation OMA-MMS-ΞNC- vl_2-20030915-C) zu sehen. In OMA wird die Antwortnachricht WN mit dem Namen "M-Resend-Notification-conf" bezeichnet. In Figur 6 ist in der ersten Spalte mit der Bezeichnung "Feldname" der Name des entsprechenden OMA-Feldes zu finden, in der zweiten Spalte der entsprechende Feldwert und in der dritten Spalte ist eine kurze Beschreibung des jeweiligen OMA-Feldes vorhanden. Im Folgenden werden die einzelnen Felder der Antwortnachricht WN nach OMA näher erläutert :
- "X-Mms-Message-Type" MT :
Die Benutzung dieses Feldes ist verpflichtend. Es ermöglicht eine OMA—Nachricht eindeutig als Anforderungsnachricht WN mit dem Namen "M—Resend-Notification . conf" zu i- dentifizieren. Nach OMA-Syntax wird als Feldwert "Message- type-value = m-resend-notification-conf " verwendet.
Feldname "X-Mms-Transaction-ID" TA4 :
Dieses verpflichtende Feld erlaubt es, eine Antwortnachricht WN eindeutig einer bestimmten Au forderungsnachricht AN zuzuordnen. Dies geschieht mittels des Feldwertes
"Transaction-ID-Value", der in der Praxis zweckmäßiger Weise dem "X-Mms-Transaction-ID" TA3, siehe Figure 5, der Aufforderungsnachricht AN "M-Resend-Notification . reg" entspricht .
Feldname "X-Mms-MMS-Version" MV4 :
Dies ist ein verpflichtendes Feld. Der Feldwert "MMS- version-value" gibt die entsprechende Versionsnummer des MMS-Interface des MMS-Servers MRS an .
Feldname "X-Mms-Resend-Notification-Status" RS : Dieses Feld muss in jeder Antwortnachricht WN enthalten sein. Es gibt den Status der Antwortnachricht WN an, der durch die Aufforderungsnachricht AN erreicht wurde. Der Status wird mit dem Feldwert "Resend-notification-status- value" ausgedrückt. Feldname "X-Mms-Resend-Notification-Text" RT4: Dieses Feld enthält eine textuelle Beschreibung für das Feld mit dem Feldnamen "X-Mms-Resend-Notification-Status" RS4. Die Verwendung dieses Feldes ist optional und wird bei Verwendung durch den Feldwert "Resend-notifiation- status-text-value" ausgedrückt.
Feldname: "X-Mms-Notification-Details" ND4 :
Dieses Feld kann die Verknüpfungen VK auf eine oder mehre- re Multimedia Nachrichten MN enthalten. Die entsprechende MMS-Empfänger-Benachrichtigungsnachricht NQN nach OMA- Standard wird mit einem Namen M-Notification . ind" bezeichnet. Alternativ ist es auch möglich, dass ein URI (Uniform Ressource Identifier) vorhanden ist. In Ergänzung zu der Verknüpfung VK können auch weitere Angaben enthalten sein wie beispielsweise die Priorität der Multimedia Nachricht MM oder die Absenderadresse der Multimedia Nachricht MM, auf die die Verknüpfung VK zeigt . Als Wert für dieses Feld wird der Feldwert "Notification-details-value" verwendet.
Gemäß einer weiteren alternativen Ausführungs form kann es zweckmäßig sein, mehr als eine Antwortnachricht WN aufgrund einer Aufforderungsnachricht AN an den MMS-Client MUA zu verschicken. Hierbei ist es vorteilhaft, in allen Antwortnach- richten WN, die aufgrund einer Aufforderungsnachricht AN übermittelt werden, ein eindeutiges Gruppen-Identi ikations- signal GN für den Nachrichtenfluss von Figur 2 zu verwenden. So kann beispielsweise die entsprechende Transaktionsnummer "Transaction ID" der Aufforderungsnachricht TA2 als eindeuti- ges Gruppen-Identifikationssignal GN angewendet und in das
Feld "Transaction ID" TA4 der entsprechenden Antwortnachricht WN eingetragen werden. Somit benutzen alle Antwortnachrichten WN, die aufgrund einer Aufforderungsnachricht AN erzeugt werden, die gleiche Transaktionsnummer TA4.
Zusätzlich kann es in der Praxis vorteilhaft sein, jede der Antwortnachrichten WN, die das gleiche eindeutige Gruppen- Identifikationssignal GN tragen, mit einer fortlaufenden Nachrichtennummer NRN und einer Gesamtanzahlnummer NGA für den Nachrichtenfluss aus Figur 2 zu versehen. Hierbei entspricht die Gesamtanzahlnummer NGA der Anzahl an Antwortnach- richten WN mit dem gleichen Gruppenidentifikationssignal GN. Beispielsweise werden sieben Antwortnachrichten WN mit dem gleichen Gruppenidentifikationssignal GN übermittelt. Dabei wird die erste Antwortnachricht WN, die der MMS-Server MRS an den MMS-Client MUA schickt, mit der Nachrichtennummer NRN gleich "1" und zusätzlich mit der Gesamtanzahl NGN von "7" versehen. Die zweite Antwortnachricht WN erhält die fortlaufende Nachrichtennummer NRN gleich "2" und als Gesamtanzahl NGA wiederum "7". Aufgrund der fortlaufenden Nachrichtennummer NRN und der Gesamtanzahl NGA ist es dem MMS-Client MUA möglich, das Fehlen einer oder mehrerer Antwortnachrichten WN eindeutig festzustellen und möglicherweise erneut anzufordern.
Gemäß einer weiteren vorteilhaften AusführungsVariante kann die Antwortnachricht WN direkt aus einer MMS-Empfänger-Be- nachrichtigungsnachricht NQN gewonnen werden, die bereits in der Vergangenheit an den MMS-Client MUA übertragen worden ist. Der MMS-Server MRS hält beispielsweise eine oder mehrere MMS—Empfänger-Benachrichtigungsnachrichten NQN für noch ver- fügbare Multimedia Nachrichten MM auf seiner Speichereinrichtung SER vor. Mit kleinen Modifikationen, beispielsweise Anpassung der Transaktionsnummer "Transaction ID" TA4, ist es möglich, diese modifizierte MMS-Empfänger-Benachrichtigungs- nachricht NQN als Antwortnachricht WN auf die Aufforderungs- nachricht AN an den MMS-Client MUA zu schicken.
Nachfolgend wird anhand der Figur 7 eine mögliche Codierung einiger Felder der Aufforderungsnachricht AN und der Antwortnachricht WN nach der OMA-konformen Syntax erläutert. In Fi- gur 7 ist in der linken Spalte der Feldname für mehrere Felder verzeichnet, die auch in der linken Spalte von Figur 4 und 6 teilweise ausgegeben sind. In der mittleren Spalte ist eine mögliche hexadezimale Codierung eingetragen und in der rechten Spalte ist eine mögliche OMA-konforme Codierung des Feldwerts als auch eine ergänzende Beschreibung enthalten. Die hexadezimale Codierung wird in der OMA-MMS-Syntax verwen- det, um ein bestimmtes Feld innerhalb der Nachricht eindeutig zu identifizieren. Beispielsweise entspricht die hexadezimale Codierung 0x34 dem Feld mit dem Feldnamen "X-Mms-Notifica- tion-Filter" FV~κ. Im Folgenden wird auf die OMA-konforme Codierung einiger Felder in Bakus-Mauer-Form (BNF) näher einge- gangen:
- Feldname "X-Mms-Notification-Filter" FVK3 :
Die hexadezimale Codierung für dieses Feld ist 0x34. Der entsprechende Wert für dieses Feld ist "Notification- filter-value = Text-string | Uri-value" .
Feldname "X-Mms-Sender-Filter " FAD3:
Der Feldwert für dieses Feld ist "Sender-filter-value = Encoded-string-value " . Die hexadezimale Codierung beträgt 0x35.
Feldname "X-Mms-Recipient-Filter" FEM3 :
Der Feldwert für dieses Feld ist "Recipient- ilter-value = Encoded—string-value " . Die hexadezimale Codierung beträgt 0x36.
Feldname "X-Mms-Message-Class-Filter" FMM3 : Der Wert für die hexadezimale Codierung beträgt 0x37. Der zugehörige Feldwert umfasst " Message—class-filter-value = Class-identifier | Token-text
Class-identifier = Personal | Advertisment | Information | Auto" .
Feldname "X-Mms-Date-And-Time-Filter" FDU3 : Der Wert für die hexadezimale Codierung ist 0x38. Dieses Feld kann durch folgenden Feldwert beschrieben werden: "Date-and-time-filter= Value-length (Absolute-token Date- value | Relative-token Delta-seconds-value) Absolute-token = <Octet 128> Relative-token = <Octet 129>"
Feldname "X-Mms-Priority-Filter" FPI3:
Als Wert für die hexadezimale Codierung wird 0x3A gewählt. Dieses Feld kann durch folgenden Feldwert beschrieben werden: "Priority-filter-value = Low | Normal I High Low = <Octet 128> Normal = <Octet 129> High = <Octet 130>"
- Feldname "X-Mms-Subject-Filter" FTI3:
Der hexadezimale Codierwert ist 0x39. Dieses Feld wird durch den Feldwert "Subject-Filter-Value = Encoded-String- Value repräsentiert".
- Feldname: "X-Mms-Resend-Notification-Status " RS4 :
Der Wert für die hexadezimale Codierung wird zu 0x3B gesetzt . Der Wert für dieses Feld wird durch folgende Beschreibung repräsentiert: "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>"
Feldname: "X-Mms-Resend-Notification-Text" RT4 : Der Wert für die hexadezimale Codierung beträt 0x3C. Der Wert für dieses Feld wird durch "Resend-notification- status-text-value = Encoded-string-value" repräsentiert.
Feldname: "X-Mms-Notification-Details" ND4 : Für dieses Feld wird der hexadezimale Wert zu 0x3D gewählt. Eine mögliche Darstellung des Feldwertes für dieses Feld ist:
"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 . ) "
Es ist nicht erforderlich, dass alle der hier aufgeführten Felder für den Feldwert mit dem Feldnamen "X-Mms-Notifica- tion-Details" auch enthalten sind. Zumindest das Feld mit dem Namen "X-Mms-Content-Location" , das die Angabe der URI (Uniform Resource Identifier) enthält, die der Verknüpfung VK auf eine Multimedia Nachricht MM entspricht, ist zweckmäßiger Weise vorhanden.
Weiter kann es in der Praxis auch vorteilhaft sein, ein oder mehrere Filterkriterien FW innerhalb einer Aufforderungsnachricht AN dadurch zu erweitern, dass neben möglichen Auswahl- kriterien auch mögliche Ausschlusskriterien definiert werden. Hierzu wird im Folgenden eine beispielhafte Realisierung anhand des OMA-MMS-Feldes "X-Mms-Priority-Filter" FPI3 nach OMA-Syntax vorgestellt. Dieses Beispiel ist so zu verstehen, dass eine Anwendung nicht nur auf dieses spezifische Feld, sondern auf alle anderen Filterkriterien FW anwendbar ist. In Figur 8 ist in der linken Spalte der Feldname des entsprechenden Feldes zusehen, in der mittleren Spalte eine mögliche hexadezimale Darstellung des entsprechenden Kopffeldes und in der rechten Spalte eine mögliche Darstellung des Feldwertes . Der Feldname "X-Mms-Priority-Filter" FPI3 kann beispielsweise durch den Wert 0x3A hexadezimal codiert werden. Als möglicher Feldwert für dieses Kopffeld kann folgende Darstellung benutzt werden:
"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>".
Mit dieser Erweiterung der Filterkriterien FW können Auswahlkriterien oder/und Ausschlusskriterien in der Aufforderungsnachricht AN gemeinsam verwendet werden.

Claims

Patentansprüche
1. Verfahren zur Wiedererlangung von mindestens einer fehlen- den Verknüpfung (VK) auf eine oder mehrere, auf einem MMS- Server (MRS) abgelegte Multimedia Nachrichten (MM) durch einen MMS-Client (MUA) , indem durch den MMS-Client (MUA) an den MMS-Server (MRS) mindestens eine Aufforderungsnachricht (AN) mit der Aufforderung zum Versenden mindestens einer fehlenden Verknüpfung (VK) auf eine oder mehrere Multimedia Nachrichten (MM) verschickt wird, und indem durch den MMS-Server (MRS) nach Erhalt der Aufforderungsnachricht (AN) mindestens eine dazugehörige Antwort- nachricht (WN) an den MMS-Client (MUA) geschickt wird, die mindestens eine der fehlenden Verknüpfungen (VK) auf die eine oder die mehreren Multimedia Nachrichten (MM) enthält.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die fehlende Verknüpfung (VK) auf die jeweilige Multimedia Nachricht (MM) in der Vergangenheit durch den MMS-Server (MRA) bereits mindestens einmal an einen MMS-Client (MUA) ü- bertragen wurde.
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der MMS-Client (MUA) in einem Mobilfunkgerät nach GSM- Standard oder UMTS—Standard, oder in einem Festnetzgerät nach IDSN-Standard oder in einer am Intranet oder Internet angeschlossenen Rechnereinheit verwendet wird.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass durch den MMS-Client (MUA) die Aufforderungsnachricht
(AN) durch mindestens ein Filterkriterium (FW) , das von allen Multimedia Nachrichten (MM) der jeweilig zu übertragenden Verknüpfung (VK) erfüllt wird, und/oder Verknüpfungskriterien (VW) erweitert wird.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass durch das jeweilige Filterkriterium (FW) Auswahl- und/oder Ausschlusskriterien definiert werden.
6. Verfahren nach mindestens einem der Ansprüche 4 mit 5, dadurch gekennzeichnet, dass das Filterkriterium (FW) mindestens eines der folgenden Felder in Bezug auf die Multimedia Nachricht (MM) umfasst: - Absenderadresse (FAD3) ,
Empfängeradresse (FEM3) , - Nachrichtentyp (FMM3) ,
Datum und/oder Uhrzeit (FDU3) ,
Priorität (FPI3) ,
Titel (FTI3) .
7. Verfahren nach mindestens einem der Ansprüche 4 mit 6, dadurch gekennzeichnet, dass durch das Verknüpfungskriterium (VW) mindestens eine Verknüpfung (VK) auf mindestens eine Multimedia Nachricht (MM) angegeben wird, die bei der Auswahl der zu übertragenden Verknüpfungen (VK) von dem MMS-Server (MRS) unberücksichtigt bleibt.
8. Verfahren nach mindestens einem der Ansprüche 4 mit 7, dadurch gekennzeichnet, dass das jeweilige Verknüpfungskriterium (VW) und/oder das jeweilige Filterkriterium (FW) mittels Logikausdrücke und/oder Größenausdrücke in Relation zueinander gebracht werden.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in alle Antwortnachrichten (WN) an den jeweiligen MMS- Client (MUA) , die aufgrund einer Aufforderungsnachricht (AN) verschickt werden, durch den MMS-Server (MRS) ein eindeutiges Gruppenidentifikationssignal (GN) eingefügt wird.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in alle Antwortnachrichten (WN) eine fortlaufende Nachrichtennummer (NRN) und eine Gesamtanzahlnummer (NGA) durch den MMS-Server (MRS) eingefügt werden, wobei die Gesamtanzahlnummer (NGA) der Gesamtanzahl an Antwortnachrichten (WN) entspricht, die aufgrund der jeweiligen Aufforderungsnachricht (AN) verschickt werden.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren durch die Syntax des 3GPP Multimedia Messaging Service beschrieben wird.
12. Verfahren nach mindestens einem der Ansprüche 1 mit 10, dadurch gekennzeichnet, dass das Verfahren durch die Syntax des OMA Multimedia Messaging Service beschrieben wird.
13. Kommunikationsgerät (MUA) mit einem Modul zur Wiedererlangung von mindestens einer fehlenden Verknüpfung (VK) auf eine oder mehrere, auf einem MMS-Server (MRS) abgelegte Mul¬ timedia Nachrichten (MM) durch einen MMS-Client (MUA) , insbesondere nach mindestens einem der vorhergehenden Ansprüche, mit einer Sendeeinheit (SEE2) zum Abschicken mindestens einer Aufforderungsnachricht (AN) mit der Aufforderung zum Versenden mindestens einer fehlenden Verknüpfung (VK) auf eine oder mehrere Multimedia Nachrichten (MM) und mit einer Empfangseinheit (EME2) zur Entgegennahme mindestens einer vom MMS- Server (MSR) nach Erhalt der Aufforderungsnachricht (AN) abgeschickten, zugehörigen Antwortnachricht (WN) , die mindes- tens eine der fehlenden Verknüpfungen (VK) auf die eine oder die mehreren Multimedia Nachrichten (MM) enthält.
14. Netzwerkkomponente (ARS) mit einem Modul zur Wiedererlan- gung von mindestens einer fehlenden Verknüpfung (VK) auf eine oder mehrere, auf einem MMS-Server (MRS) abgelegte Multimedia Nachrichten (MM) durch einen- MMS—Client (MUA), insbesondere nach mindestens einem der Ansprüche 1 mit 12, mit einer Empfangseinheit (EMEl) zum Entgegennehmen mindes- tens einer Aufforderungsnachricht (AN) mit der Aufforderung zum Versenden mindestens einer fehlenden Verknüpfung (VK) auf eine oder mehrere Multimedia Nachrichten (MM) , die in einer Speichereinrichtung (SER) netzwerkseitig noch verfügbar sind, mit einer Logikeinheit (LEE1) zum Erstellen mindestens einer dazugehörigen Antwortnachricht (WN) mit mindestens einer fehlenden Verknüpfung (VK) auf eine oder mehrere Multimedia Nachrichten (MM) nach Erhalt der Aufforderungsnachricht (AN) , sowie mit einer Sendeeinheit (SEE1) zum Verschicken mindestens einer zugehörigen Antwortnachricht (WN) an den MMS- Client (MUA) .
PCT/EP2004/052595 2004-01-02 2004-10-20 Verfahren zur wiedererlangung von einer auf einem mms-client nicht verfügbaren verknüpfung auf eine auf einem mms-server abgelegte multimedia nachricht durch einen mms-client WO2005067325A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004001012A DE102004001012A1 (de) 2004-01-02 2004-01-02 Verfahren zur Wiedererlangung von mindestens einer fehlenden Verknüpfung auf eine oder mehrere, auf einem MMS-Server abgelegte, Multimedia Nachrichten durch einen MMS-Client, sowie ein Kommunikationsgerät und eine Netzwerkkomponente
DE102004001012.9 2004-01-02

Publications (1)

Publication Number Publication Date
WO2005067325A1 true WO2005067325A1 (de) 2005-07-21

Family

ID=34706769

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/052595 WO2005067325A1 (de) 2004-01-02 2004-10-20 Verfahren zur wiedererlangung von einer auf einem mms-client nicht verfügbaren verknüpfung auf eine auf einem mms-server abgelegte multimedia nachricht durch einen mms-client

Country Status (4)

Country Link
CN (1) CN100466824C (de)
DE (1) DE102004001012A1 (de)
TW (1) TWI394480B (de)
WO (1) WO2005067325A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101621752B (zh) * 2008-07-02 2013-09-11 华为技术有限公司 发送多媒体消息的方法、系统及相应的设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020078228A1 (en) * 2000-12-20 2002-06-20 Jussi Kuisma Arrangement for implementing transmission of multimedia messages
US20030109269A1 (en) * 2000-02-02 2003-06-12 Josef Laumen Method for transmitting messages in a telecommunication network
US20030193951A1 (en) * 2001-12-31 2003-10-16 Ericsson, Inc. Method, apparatus and system for processing multimedia messages

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4123331B2 (ja) * 2001-03-16 2008-07-23 日本電気株式会社 マルチメディア通信システムとマルチメディア通信可能な携帯無線通信端末及びメッセージ送受信方法
US20030172173A1 (en) * 2002-03-11 2003-09-11 Fenton Gregg A. Method, apparatus and system for reformatting a multimedia message for delivery to a terminal during connectionless communications

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030109269A1 (en) * 2000-02-02 2003-06-12 Josef Laumen Method for transmitting messages in a telecommunication network
US20020078228A1 (en) * 2000-12-20 2002-06-20 Jussi Kuisma Arrangement for implementing transmission of multimedia messages
US20030193951A1 (en) * 2001-12-31 2003-10-16 Ericsson, Inc. Method, apparatus and system for processing multimedia messages

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
3GPP: "3GPP TS 23.140 V6.3.0 (2003-09); 3rd Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional description; Stage 2; (Release 6)", 3GPP, September 2003 (2003-09-01), SOPHIA ANTIPOLIS, pages 1 - 174, XP002318339 *
MOSTAFA M-E: "MMS - the modern wireless solution for multimedia messaging", PERSONAL, INDOOR AND MOBILE RADIO COMMUNICATIONS, 2002. THE 13TH IEEE INTERNATIONAL SYMPOSIUM ON SEPT. 15-18, 2002, PISCATAWAY, NJ, USA,IEEE, vol. 5, 15 September 2002 (2002-09-15), pages 2466 - 2472, XP010614171, ISBN: 0-7803-7589-0 *

Also Published As

Publication number Publication date
CN1902960A (zh) 2007-01-24
TWI394480B (zh) 2013-04-21
TW200537953A (en) 2005-11-16
DE102004001012A1 (de) 2005-07-28
CN100466824C (zh) 2009-03-04

Similar Documents

Publication Publication Date Title
DE602005004721T2 (de) Verfahren zur Verwaltung von verdoppelten Nachrichtenmeldungen in multimedialen Benachrichtigungsdiensten
EP1230815B1 (de) Verfahren und system zur ausarbeitung und übermittlung von sms-meldungen in einem mobilfunknetz
DE69913953T2 (de) Verfahren und vorrichtung zur verarbeitung von elektronischen post
DE60317429T2 (de) Verbindungsfeststellung eines Geräts durch ein Zwischengerät und Informationsübermittlung an dieses Gerät
AT411312B (de) Verfahren zum übermitteln von kurznachrichten (sms) zwischen rechnern im internet
EP1072139B1 (de) Datenverbreitungssystem und datenverbreitungsverfahren
WO2002063839A2 (de) Verfahren und vorrichtung zur manipulation übertragener nachrichten
EP1642229B1 (de) Vorrichtung und verfahren zum benutzerseitigen bearbeiten von elektronischen nachrichten mit datei-anlagen
DE602005001322T2 (de) Speichern, Übertragen und Empfangen von Textnachrichtenketten auf einem drahtlosen Kommunikationsgerät
DE19958707A1 (de) Verfahren zur Übertragung einer Textnachricht
WO2002058359A1 (de) Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz
WO2000035213A1 (de) Verfahren zur übertragung von kurznachrichten
DE60315697T2 (de) Verfahren zum Senden von Multimedianachrichten zwischen unterschiedlichen Multimedia-Nachrichtendiestzentren
WO2003105425A1 (de) Übertragung vno mms-nachrichten mit konvertierung von datai-typen und/oder -formaten
EP2265050B1 (de) Verfahren zum die Übertragen von Kurznachrichten
DE60316978T2 (de) Verfahren zum senden von multimedianachrichten zwischen unterschiedlichen multimedia-nachrichtendienstzentren
WO2004068878A1 (de) Verfahren und system zum einfügen eines multimedia-nachricht-mehrfachelements in eine multimedia-nachricht
EP1393524A1 (de) Verfahren zur handhabung einer nachricht mit multimedialem bezug
EP1356644B1 (de) Nachrichtenübermittlungsvorrichtung und verfahren zur übermittlung von nachrichten
WO2004015939A1 (de) Verfahren und system zum blockieren von unerwünschten nachrichten
EP1493295B1 (de) Verfahren zur bertragung von daten, insbesondere mit multim edialen inhalten, in einem mobilfunknetz
WO2005067325A1 (de) Verfahren zur wiedererlangung von einer auf einem mms-client nicht verfügbaren verknüpfung auf eine auf einem mms-server abgelegte multimedia nachricht durch einen mms-client
WO2004036852A1 (de) Zugriffsbenachrichtigung eines absenders einer elektronischen nachricht
EP2560330A2 (de) Umleiten einer Multimedianachricht durch eine Multimedianachricht-Relaiseinrichtung in Abhängigkeit einer Umleitungs-anforderungsnachricht
WO2004086675A1 (de) Verfahren zur übertragung von nutzdaten inklusive kostenübernahme-informationen in einem kommunikationsnetz

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200480039532.0

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Ref document number: DE

122 Ep: pct application non-entry in european phase