EP1356645A2

EP1356645A2 - Method for accessing messages, corresponding devices and software programs

Info

Publication number: EP1356645A2
Application number: EP02702291A
Authority: EP
Inventors: Markus Trauberg; Andreas Schmidt; Josef Laumen; Belhassen Jerbi; Sabine Van Niekerk
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2001-02-02
Filing date: 2002-01-21
Publication date: 2003-10-29
Also published as: US20030086438A1; WO2002063839A3; WO2002063839A2; JP2004526352A; DE10104713A1

Abstract

The invention relates to a method which enables a first message, particularly a multi-media message, preferably an sms type message, preferably sent via a mobile radio system and/or the internet to be manipulated, called back or altered by means of a second message sent after the first method. User friendliness is increased for the user according to said system. The invention also relates to the possibility of limited manipulation of a first message, as well as corresponding telecommunication devices, network elements and software programs.

Description

Be honest

Methods of accessing messages, devices therefor and software programs

The invention relates to a method for accessing a first message, in particular a multimedia message, preferably of the MMS type, the first message being sent to a receiving application by means of a sending application or a VAS application.

Furthermore, the invention relates to corresponding telecommunication devices, network elements and software programs.

In addition to voice telephony, the mobile radio system GSM (GSM - Global System for Mobile Communications) also offers the option of sending and receiving short text messages of up to 160 characters in length. This service is called SMS (SMS - Short Message Service), see GSM 03.40 version 7.4.0, release 1998; Digital Cellular Telecommunications System, - Technical Realization of the Short Message Service (SMS).

For the next generation UMTS mobile radio system

(UMTS - Universal Mobile Telecommunication System), a multimedia-capable variant of a mobile messaging service is currently being standardized, the so-called MMS (MMS - Multimedia Messaging Service), see 3G TS 22.140 version 4.0.1, release 2000; Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Service aspects; Stage 1; Multimedia messaging service (MMS). Messages with multimedia content For better differentiation from the text messages of the SMS, only short MMs (MM - Multimedia Message; Plural: MMs) are called in the following. In contrast to SMS, there is no restriction to text-only content. With MMS, it will be possible to format texts to suit individual tastes and embed audio and video content in a message. Another news is that the delivery of MMs is known to be between the so-called PUSH mode (push / bring mode), in which an incoming MM is immediately delivered to the recipient, and the so-called PULL mode (pull / pull Mode), in which the recipient is first informed of a newly arrived MM and can then decide for himself when to download this MM to his end device. These known relationships are illustrated in FIG. 1, a network element designated as an MMS server being identified by reference number 12 and a UMTS terminal by reference number 11.

According to the current state of the art, MMS can only be implemented using WAP (WAP - Wireless Application Protocol). To bridge the air interface between an MMS-compatible device and the WAP gateway, the use of the WAP WSP (WSP - Wireless Session Protocol), see WAP-203-WSP, version 4-May-2000; Wireless application protocol, wireless session protocol specification; Chapter 8.4: "Header Encoding", provided, see 3G TS 22.140 version 4.0.1 (see above); 3G TS 23.140 version 4.0.0, Release 4, Third Generation Partnership Project, Technical Specification Group Terminals, Multimedia Messaging Service (MMS), Functional Description, Stage 2. FIG. 2 shows a so-called transaction flow diagram according to the current state of the art according to 3G TS 23.140 version 4.0.0 (see above), in which the exchange of the WAP messages between the three entities involved in sending and receiving an MM is shown, namely a sending application UAA (UAA as abbreviation for MMS User Agent A), network element RS (RS as abbreviation MMS Relay / Server) and a receiving application UAB (UAB as abbreviation for MMS User Agent B). MMS user agent is understood here to mean an application on a mobile radio device or on a device connected to a mobile radio device (for example a laptop, etc.) that realizes MMS. An MMS relay / server is a network element in the area of responsibility or in the MMS environment of the MMS service provider (MMS service provider), which makes the MMS functionality available to the "MMS User Agents" applications.

The exchange of the WAP messages is described below on the basis of the known transaction flowchart in FIG. 2 (“send application UAA sends MM _A to receive application UAB”). It is initially assumed in a simplified manner that the send application UAA 1 and the receive application UAB 12 den Use the MMS from the same MMS service provider. The MM _A generated in the sending application UAA 1 is sent to the network element RS 2, 12 with the WAP message M-Send. Req (since this network element takes over both transmitter-side and receiver-side functions, it is identified by the double reference symbols 2, 12.) The receiving application UAA 1 then receives the WAP message M-Send. conf, with which the correct receipt of the MM _{A is} confirmed by the network element RS 2, 12. In it a, possibly individual, identification number ID1 for the sent MM _A, which is defined by the network element RS 2, 12, is also included. The network element RS 2, 12 then informs the reception application UAB 11 with the WAP message M-notification. and via the storage space (URI - Uniform Resource Identifier; hereinafter the abbreviation URI is used) of the newly arrived MM _A available for download. The network element RS 2, 12 then receives, for example, the MAP NotifyResp with the WAP message. reg a confirmation that the notification about the incoming MM _A (M-Notification. ind) has been successfully delivered. At this time, the network element RS 2, 12 has not yet assigned a message ID for the MM available for download. When exchanging the two WAP messages M-Notification. ind and M-NotifyResp. Reg only an individual transaction identity number (transaction ID) is exchanged for this notification. The receiving application UAB then requests the delivery of the MM _A using the WAP message WSP GET, with which the URI is sent to the network element RS 2, 12. With the WAP message M-Retrieve. conf is then sent to the receiving application UAB 11 by the network element RS 2, 12 the desired MM _A. Here, the MM _{A is identified} via the possibly individual identification number ID2 assigned by the network element RS 2, 12. With the WAP message M-Acknowledge. the correct reception of the MM _{A is} acknowledged by the reception application UAB 11. In the event that the sender has expressed the wish to be notified of successful receipt of the MM _A sent by him, the network element RS 2, 12 can comply with this by the WAP M-Delivery products. and is sent to the receiving application UAB 11.

3 shows a known possible MMS architecture, in which the sending application UAA 1 and receiving application UAB 11 involved in the exchange of an MM make use of the MMS from different MMS service providers (MMS service provider A and MMS service provider B). In this case, it is necessary to forward the MM between the MMSEs (MMSE - Multimedia Messaging Service Environment = multimedia message service environment or MMS environment) of the MMS service providers involved. The reference number 4 identifies the MMSE of the MMS service provider A and the reference number 14 the MMSE of the service provider B. The forwarding of an MM between two MMSEs and more precisely between the transmitter-side network element RSA 2 (RSA as an abbreviation for MMS relay / server A) and the receiving network element RSB 12 (RSB as an abbreviation for MMS Relay / Server B) is done via SMTP (SMTP - Simple Mail Transfer Protocol), see. 3G TS 23.140 version 4.0.0 (see above), e.g. through the Internet (IP - Internet Protocol with reference number 20). The SMTP protocol is designated in FIG. 3 with the reference symbol 22. The mobile radio network in FIG. 3 is referred to as PLMN (PLMN - Public Land Mobile Network) as usual and bears the reference symbol 6 in FIG. 3. Each MM can be assigned a time when editing, at which point the MM at the earliest to the recipient , more precisely to the receiving application UAB 11. If this is used, the MM is temporarily stored in the sender's MMSE _A 4 - more precisely: a memory "MMS Server A" with reference number 3 - until this deadline has been reached, according to Report of the 3GPP TSG-T2 SWG3 MMS Ad Hoc Meeting # 5 in Sun phia Antipolis, France 10-12 October 2000; T-doc: T2M00092; chapter 7; 3GPP TSG-T2 SWG3. Only then is the MM transmitted to the MMSE _B 14 at the receiving end. Furthermore, a desired validity period can also be specified when editing each MM. An MM is to be stored in the receiving application MMSE _B 14 (more precisely: in a memory “MMS Server B” with reference number 13) until the expiry of the MM or until the MM has been downloaded beforehand by the receiving application UAB 11, according to Report of the 3GPP TSG-T2 SWG3 MMS Ad Hoc Meeting # 5.

As can also be seen from the known MMS reference architecture according to FIG. 3, the MMs can not only come from applications UAA or UAB, but also from MMS VAS applications (VAS applications, where VAS = Value Added Services). which is identified in FIG. 3 by reference number 7. It is a network-side facility that offers additional services. In this case, the MM7 interface serves as a communication interface between an MMS VAS application and a network element RS. To date, no mandatory MMS-specific messages have been defined for this interface. Communication here can be based on HTTP (Hypertext Transport Protocol) or SMTP (Simple Mail Transport Protocol). In addition, according to the current state of standardization, it is possible to use an MM1-like coding for this interface.

In the methods and devices mentioned at the outset, a message can be processed by the sender or client as long as it is still in the sending application UAA is located. Once the message has been sent, there is no longer any possibility of influencing or accessing it. This problem exists not only when sending messages over the air, but also when sending electronic mail (e-mails) over the Internet and other messaging systems.

It is an object of the present invention to further develop the method and the devices of the type mentioned at the beginning in such a way that processing or influencing of messages which is more oriented towards the needs of the sender / recipient is made possible.

This object is achieved in the method of the type mentioned at the outset in that a second message with a manipulation order for manipulating the first message is created, sent, received, forwarded and / or processed in order to initiate manipulating access to the first message or convey.

Furthermore, this object is achieved in a corresponding telecommunications device by the features of claim 35. This includes in particular mobile telephones and communication units including computers connected to the Internet. The means according to the invention for creating, sending, receiving and / or processing the second message include, in addition to the hardware units, such as in particular control units and processor units, in particular software solutions, which are presented in more detail below, and preferably modifications of WAP messages with display changed and / or newly defined header fields or can process them.

In addition, this object is achieved in a corresponding network element by the features of claim 46. For the purposes of this invention, network elements of this type are part of a communication system which enable communication between a plurality of transmitting and / or receiving units, in particular a plurality of mobile telephones and / or computers connected to the Internet. Such one

Communication system - including radio communication systems - is usually operated by service providers. The means according to the invention for receiving, processing and / or forwarding the second message include the necessary ones

Hardware elements, such as in particular control units and processor units, in particular software, which are described in more detail below and preferably represent modifications of WAP messages with appropriately adapted or newly defined header fields or can process them.

A message in the sense of this invention can be a conventional SMS, an MM with multimedia content or another electronic message. The invention is described below with reference to the MM, without this being intended to restrict this type of message. The abbreviation MM _{A is used} below for the first message and the abbreviation MM _B for the second message.

The advantages of the invention are in particular that it enables a first message to be sent after the shutdown. to manipulate, in particular to recall and / or to subsequently change or update it. Such manipulation can, according to the invention, when sending messages via radio, via mobile radio systems, between mobile radio systems, in particular via an inter-operator IP backbone, between mobile radio networks and other message systems, in particular Internet email, and / or be possible over the internet.

In particular, it is possible with the aid of the present invention to manipulate a first message - in particular a multimedia message according to the MMS type - sent by a client by means of a sending application of a sending unit via at least one network element to a receiving application of a receiving unit, after sending the first message, a second message with manipulation information is transmitted from the transmission unit to at least one network element which initiates or mediates manipulative access to the first message.

The first message and the second message are sent via at least one transmitter-side network element of a service provider and at least one receiver-side

Network element of a service provider sent to the receiving application. The at least one transmitter-side network element and the at least one receiver-side network element can belong to the area of responsibility of a single service provider or even - in the simplest case - be identical. Cases of an identity of the reception and the transmission application are also possible.

The manipulating access to the first message is particularly preferably carried out on a transmitter-side network element, on a receiver-side network element and / or on the reception application.

If the receiving application has not yet been informed of the manipulation order, the first message is preferably manipulated either in the area of responsibility of the transmitter-side or the receiver-side service provider, preferably without notifying the reception application of the manipulation. If, on the other hand, the notification about the first message has already been sent to the receiving side, but if this first message has not yet been downloaded, the first message is preferably manipulated in the area of responsibility of the sending service provider without informing the receiving application, or the manipulation takes place in the area of responsibility of the receiving service provider , the receiving application preferably being informed about the manipulation and its time.

The manipulation according to the invention is not limited to the two service features of calling back and changing. Orders for a subsequent forwarding (forwarding), a subsequent attachment of the second message to the first message, etc. are also understood as manipulation in the sense of this invention. The recall and change orders are described in more detail below. According to one embodiment of the invention, the recall (referred to as “recall” in the context of this disclosure) of an MM can at least still be possible until the recipient has moved it to another folder, forwarded it to another recipient or opened it.

According to one embodiment of the invention, the subsequent change (referred to as “replace” in the context of this disclosure with “replace”) is advantageously still possible even if the recipient has already “touched” the MM. In this case, the recipient is preferably informed immediately of a subsequent change in the corresponding MM, either by a notification (notification) so that he can subsequently initiate the download of the updated MM himself (PULL mode), or by automatic delivery the updated MM (PUSH mode).

In a further development of the invention, it is also possible for the sender of an MM, ie sending application (MMS user agent) or MMS VAS application, to call back a previously sent MM under specified conditions or to subsequently change or update it can make. These conditions that can be selected by the sender and that are contained in information elements of the second message can in particular be: Call back an MM only if the recipient has not yet been informed about an MM available for download, or execute a change request even if the MM already does delivered to the recipient's terminal but has not yet been opened. These features are hereinafter referred to as "conditional recall" ("Conditional Recall" or "Conditional Cancel") or "Conditional Replace" called. The term “change” or “replace” is understood in particular to mean replacement, but also any other form of change. The information elements according to the invention are, for example, correspondingly supplemented or newly defined header fields in WAP messages.

The advantage of this aspect of the invention is the realization of a scalability and flexibility of recalling and / or replacing a previously sent MM. These service features increase the attractiveness of the multimedia messaging service (multimedia messaging service).

The sender of a message (MM) - both in the case of unconditional and conditional manipulation orders - can in particular be a “MMS User Agent” sending application or an MMS VAS application. Such a sending application can be an application on a mobile terminal, for example, while an MMS VAS application represents a network-side application that offers value-added services.

The invention furthermore relates to the implementation of the method according to the invention in WAP by modifying existing header fields or adding newly defined header fields to the affected WAP messages of the WAP-MMS encapsulation standard, see. WAP-209-MMS Encapsulation, Release 2000; Wireless application protocol; WAP multimedia messaging service; Message encapsulation; MMS Proposed SCD 1.0. Likewise, the corresponding binary coding, as described below for exemplary embodiments, is the subject of the present invention.

The invention is explained in more detail below with the aid of examples.

Show it:

1 shows a comparison of the PULL and PUSH modes according to UMTS according to the prior art;

2 shows a transaction diagram for a multimedia message service (MMS) according to the prior art;

3 shows a schematic illustration of a multimedia message service architecture according to the prior art;

Fig. 4 shows a multimedia news service with a

Manipulation possibility of a first message according to the present invention;

5 shows a coding of newly defined header fields;

Fig. 6 additions in the known header field X-Mms status;

Fig. 7 newly introduced header field X-Mms original message status; 8 newly introduced header field X-Mms-Original - Message-ID;

Fig. 9 coding of further newly defined header fields, and

Fig. 10 additions in the header field X-Mms-Supported - Feature.

With reference to the upper third of FIG. 4, in the description of the exemplary embodiments, the following, known sequence of sending and receiving a first message MM _A by switching a first and a second MMS service provider (service provider A and service provider B) assumes: After sending the first message MM _A , the sending application UAA 1 of the sender is M-send in the WAP message. conf a message ID for the previously sent MM _A (ID1). This identification number ID1 is generated by the network element RSA 2 of the service provider A and uniquely identifies the MM _A within the transmitter-side interface transmission application UAA 1 / network element RSA 2. When the MM _{A is delivered} from the network element RSB 12 of the service provider B to the receiving application UAB 11 by the WAP message M-Retrieve. conf is also sent a message ID (ID2 in Fig. 2). This identification number ID2 may be newly generated by the network element RSB 12 and serves to uniquely identify the MM _A on the receiver side within the interface network element RSB 12 / receiving application UAB 11.

To transmit the MM _A between the transmitter Network element RSA 2 and the receiver-side network element RSB 12, ID1 can be converted into an interim identification number (ID3), which identifies the MM _A between the different systems (note: in FIG. 4, the positions marked with an asterisk generally indicate such Conversions of the message IDs between the interfaces). In particular, ID3 should be globally unique. For example, ID3 contains information regarding the service provider A, the ID1 and the time of the ID conversion. For this purpose, the transmitter-side network element RSA 2 must have the information or the possibility to undo this conversion, for example for delivery reports. In order to use internally clear IDs, ID3 can be converted by the receiver-side network element RSB 12 into the above-mentioned internal ID2, which identifies the MM _A to the reception application UAB 11. To do this, the receiver-side network element RSB 12 must in turn have the information or the ability to undo this conversion, for example for delivery reports. The MM _A is identified on the receiver side by ID2.

According to the invention, the transmission application, the reception application and / or network elements which mediate between the transmission and reception application now provide the possibility of accessing the previously sent first message MM _A by providing a second message MM _B which provides manipulative access initiates or mediates the first message MM _A.

One way of identifying MM _B is explained below with reference to FIG. 4, in which MM _B identifies the tion number ID4. To transmit MM _B between the different service provider systems, ID4 can be converted by the transmitter-side network element RSA 2 into an interim ID (ID6), which identifies MM _B between the systems. In particular, ID6 should be globally unique, for example contain a combination of information regarding service provider A, ID4 and the time of the conversion. To do this, the transmitter-side network element RSA 2 must have the information or the ability to undo this conversion, for example for delivery reports. To use internally clearer IDs, ID6 can be converted by the receiver-side network element RSB 12 into an internal ID (ID5), which identifies MM _B for the reception application UAB 11. To do this, the receiver-side network element RSB 12 must have the information or the ability to undo this conversion, for example for delivery reports. MM _B is identified on the receiver side by ID5.

In order to implement the necessary connection of MM _A and MM _B , ID4 has a reference to ID1, ID6 a reference to ID3 and ID5 a reference to ID2. The notifications of the receiving application UAB 11 via MM _A and MM _{B also} refer to two memory locations URI1 and URI2.

It is possible that the identification numbers ID1 and ID3, ID3 and ID2, and ID1, ID2 and ID3 are identical. Likewise, ID4 and ID6, ID6 and ID5, and ID4, ID5 and ID6 can be identical.

At least one of the participating transmitter-side and one of the participating receiver-side network elements is advantageously capable of unambiguously, reversibly converting IDs and managing the information about them.

In the following, the manipulation possibilities "callback" and "change" are described by way of example, by which the latter term in the sense of this invention means for example an update of the first message MM _A , in particular by replacing the first message with the second message. In general, however, all combinations of the options disclosed according to this invention can be implemented for all types of manipulations, for example whether and with what information the recipient is notified of a manipulation of a first message, whether information about the type of manipulation is to be made, whether the recipient is informed about a manipulation request of the sender is to be informed whether the second message is to be delivered in PULL or PUSH mode, whether the change is to take place on a transmitter-side or receiver-side network element or on the receiving application UAB, whether the sender and / or the Recipient should be notified of the success of the manipulation, etc.

A. "CALL BACK" FEATURES

According to the invention, a user of the MMS who has sent a first multimedia message MM _A and wants to recall this already sent MM _{A can} send a new, second message MM _B with the information that the previously sent first message MM _A again should be called back. According to the invention, this can preferably be achieved in that the sender writes the new MM _B , which contains a callback command, but preferably no content (content / message body) intended for the recipient, and this to the same recipient as the recipient previously sent MM _A sends. The ID1 of the previously sent MM _A is preferably used as the callback identifier. The MM _B with the callback information first arrives at the sender's network element RSA. It is expediently checked here whether the MM _A with the ID1 is still in the area of responsibility of the service provider A (MMSE _A ) or whether it has already been forwarded to the MMSE _{B of} the service provider B. The former is the case, for example, if the time selected by the sender for the desired delivery of his MM _A has not yet been reached; the latter is the case, for example, if the MM _A has not yet exceeded its validity period and has not yet been delivered to the receiving application UAB. As soon as the MM _{A is found} in an MMSE of the MMS service providers involved, the deletion of MM _A and MM _B can be initiated by the responsible network element RS.

If the receiving application UAB has already been informed of the MM _A available for it in the MMSE _B by means of a notification (notification) and the MM _{A should} still be in the area of responsibility / memory of the service provider B, the receiving application UAB can be renewed according to this invention Notification that the MM _{A has} been deleted by the service provider B and is therefore no longer available for download because the sender has called it back. The MMS has also B offers according to this invention the possibility to transmit the date of execution of the callback command to the receiving application UAB.

If the MM _A has already been delivered to the recipient, the receiving application UAB of the recipient can be informed with the abovementioned new notification that the sender wants to call the MM _A back. According to this invention, the deletion of the MM _A can take place directly in the reception application UAB, provided that this supports the callback service feature. Depending on the implementation of this service feature in the terminal, the settings of the user, the settings of the MMS service provider and / or the network operator, the deletion of the MM _A in the terminal may depend on whether the MM _{A has} already been “touched” by the recipient (eg opened, read) , forwarded, etc.) However, it makes sense to delete only those MMs after delivery that have not yet been "touched" by the recipient. The MM _B with the callback information need not necessarily be sent to the receiving application UAB; it can already be deleted in MMSE _B.

If the recipient (MMS User Agent B) of the MM _A has not yet received a notification about the MM _A , for example because the MM _B with the recall information reaches the network element RSB before the MM _A to be recalled, the latter does not have to be initiated by the sender Recall campaign will be informed. Instead, the network element RSB preferably waits until it receives the MM _A referenced for the callback and deletes it on arrival without notifying the recipient (provided the network element RSB supports the callback service feature). alternatives MM _{A can} also be deleted on the RSA network element.

According to the present invention, the client of the recall (MMS User Agent A) is preferably informed of the outcome and the date of execution of the action initiated by him, if the MMS service providers involved make this possible.

In order to be able to implement the service feature called callback just described, the present invention proposes that one or more of the following information be additionally exchanged between the entities involved (send application UAA, network element RSA, network element RSB and receive application UAB):

Send application UAA (MMS User Agent A) - »Network element RSA (MMS Relay / Server A) (when sending an MM):

• Identification that an MM _B is a callback command.

• Identification number of the MM _A to be called back.

• Information that the sender requests feedback on the outcome of the recall action initiated by him.

Network element RSA (MMS Relay / Server A) - »Send application UAA (MMS User Agent A) (when confirming after sending an MM): • Inform the service provider whether it supports the callback service feature. Network element RSA (MMS Relay / Server A) -> • Network element RSB (MMS Relay / Server B) (only necessary if the sender and recipient belong to different MMSEs)

• Identification that an MM _B is a callback command.

• Identification number of the MM _A to be called back.

The transmission of the information between network element RSA and network element RSB depends on whether this information was present when the MM _B was sent.

Network element RSB (MMS Relay / Server B) - »receiving application UAB (MMS User Agent B) (when notifying about an incoming MM), preferably in a message: • Information when the callback was carried out.

• Information that an MM _A previously announced by a notification is no longer available for download. The MM _A that was deleted in the MMSE _B is identified using the message reference (URI). or:

• Information that an already delivered MM _{A will be called back} by the sender. The MM _A that is called back is identified on the receiving application UAB using the message ID. Receiving application UAB (MMS User Agent B) - network element RSB (MMS Relay / Server B) (after notification):

• Information as to whether the recipient has understood that an MM _A previously announced by a notification is no longer available for download. or:

• Information as to whether the receiving application UAB was able to successfully call back (ie delete) the MM _A or has caused it.

• Information as to whether the recipient has been informed (and / or has agreed to the callback) that an already downloaded MM _{A has been called} back and is therefore no longer available in the memory of the end device (or connected devices / memory cards) accessible to the receiving application UAB.

Network element RSB (MMS Relay / Server B) - »Network element RSA (MMS Relay / Server A) (only necessary if the sender and recipient belong to different MMSEs and if the sender has requested feedback):

• Information as to whether the callback order was successfully executed.

• Information when the callback order was executed.

• Information as to whether the callback order was carried out automatically.

• Information as to whether the recipient has been informed about the recall (and / or has agreed to the recall). • Information that an already downloaded MM _{A has been} recalled and is therefore no longer in the access application UAB accessible memory of the end device (or connected devices / memory cards) is available.

• Identification number of the MM _A that was called back.

Network element RSA (MMS Relay / Server A) - »Receive application UAA (MMS User Agent A) (in the report):

• Information as to whether the callback order was successfully executed. • Information when the callback order was executed.

• Information as to whether the callback order was carried out automatically.

• Information as to whether the recipient has been informed about the recall (and / or has agreed to the recall).

• Information that an already downloaded MM _{A has been called} back and is therefore no longer available in the memory of the terminal device (or connected devices / memory cards) accessible by the receiving application UAB. • Identification number of the MM _A that was called back.

Additional service feature: Conditional recall

This special aspect of the invention is based on the idea of conditional recall / cancel and conditional change or replacement or updating of multimedia messages (conditional replace). According to the invention, the execution of a recall or change order subsequently sent by the sender of an MM is linked to certain conditions. For example, senders may only have a certain MM then call back or update if the recipient has not yet been informed of the arrival. In other cases, he may wish to delete or change it, even if the receiving application UAB has received a notification or if the MM has even been read. Furthermore, a concept for realizing these service features is part of this invention, in which the introduction or adaptation of data fields from the 3GPP MMS specification is necessary, according to 3G TS 23.140 version 4.0.0. New header fields of the WAP messages are defined and other fields are adapted or supplemented.

According to this preferred embodiment of the invention, a second message, hereinafter referred to as MM _B , can be sent with the information that the first message, ie MM _A , should be canceled or recalled under certain conditions. The new MM _{B contains} information on performing the MM _A recall process. According to the invention, the sender of the recall command sets conditions for executing his request. The sending user agent or the VAS application determines in which case the previously sent MM should be deleted or invalidated.

According to the invention, the service provider can limit the use of the recall feature to its own domain or to certain domains of other service providers. This can be done by identifying the address of the recipient, for example his number, mail address or the like. Another option would be to insert an additional flag in the recall command. Furthermore, the conditional recall is based on the processing phase or the processing status of the previously sent message, in particular an MM. In this case, the sender decides in which status the MM should be deleted. Possible conditions for the callback specified by the sender can in particular be:

1. Call back the MM only if the MM is still on the server and the recipient has not yet been informed. In this case, the callback will only take place if no notification has yet been sent.

2. Calling back the MM even if the notification has been sent but the MM has not yet been downloaded.

3. Calling back the MM if the recipient has not yet opened or read it. In this case, the recall can also take place after the download.

4. Recall the MM regardless of the degree of processing of the MM at the recipient. Callback is also attempted here if the recipient has read the MM.

When realizing these service features, a standard condition "default value" is advantageously assumed. For example, it can be agreed that a standard condition corresponds to one of the four cases described above. This default setting can be used, for example - as long as nothing precise has been stated regarding the conditional execution of the callback command - be set such that the call back, for example, only before a notification correct about the existence of an MM. The system could also be designed so that a recall should only take place before the MM to be deleted has been downloaded or even after the MM has been opened or read.

In the following, the transactions for the implementation of the MM status-dependent recall feature are dealt with. An MM _A that has already been sent can therefore be called back later by the sender by writing a new MM _B that contains a conditional callback command, but preferably does not contain any content (message / body) intended for the recipient. This new message is sent to the same recipient as the previously sent MM _A. The identification number (ID 1) of the previously sent MM _A is preferably used as the callback identifier. The MM _B with the callback information first arrives at the sender's network element RSA (MMS Relay / Server A). Here it is checked whether the MM _A with the ID 1 is still in the area of responsibility of the service provider A (Multimedia Messaging Service Environment A, MMSE _A ) or whether it has already been forwarded to the MMSE _{B of} the service provider B. The former is the case, for example, if the time selected by the sender for the desired delivery of his MM _A has not yet been reached; the latter is the case, for example, if the MM _A has not yet exceeded its validity period and has not yet been delivered to the receiving application UAB.

As soon as the MM _{A is found} in an MMSE, the deletion of MM _A and MM _B can be initiated by the responsible network element RS. If the original recipient has forwarded the MM _A addressed to him to another address, the recall command should also be preferred are forwarded accordingly by the network element RSB, so that the callback can take place in the destination-side network element RS. If the network element RSB only has the information that the MM has been forwarded without knowing the destination (for example if the original recipient has forwarded the MM addressed to it to an e-mail address), the sender of the recall command can advantageously be informed of the failure of the recall due to the forwarding. For reasons of confidentiality, it would also be possible to report the failure of the execution without commenting on the reason in this case.

A particularly favorable case for executing the callback command is when the MM has not yet been notified of this message on one of the network elements RSA or RSB and the receiving application UAB has not yet been notified. Such a case could occur, for example, if the MM should be delivered at a certain point in time at the request of the sender, but which has not yet occurred. Here the MM is still on the network element RSA of the sender. The MM can also be stored on the network element RSB, if e.g. the end device of the recipient is switched off and the validity period of the MM has not been exceeded. In these two cases, the MM can be deleted regardless of the selected deletion conditions. All four recall conditions described above cover this situation.

If the receiving application UAB has already been informed of the MM _A available for it in MMSE _B by means of a notification (notification) and the MM _{A is} still in the area of responsibility / memory of the service provider Should B be located, according to this invention, the recall can only take place in the cases numbered above with 2, 3 and 4. In case 1 of the conditional recall, the sender preferably receives a notification explaining that the recipient has already been informed about the MM previously sent and that the recall could not be carried out. For the other cases (2, 3 and 4) the receiving application UAB can be informed with a renewed notification (notification) that the MM _{A has} been deleted by the service provider B and is therefore no longer available for downloading because the Sender called them back. Another option would be to inform the recipient of the recall process and only when he requests the MM to inform him that it is no longer available or that it has been called back.

If the MM _A has already been delivered to the recipient, it can only be recalled for case 4 (recall, regardless of the processing level) and possibly for case 3 (recall if MM has not yet been opened / read) , The receiving application UAB is - preferably only for cases 3 and 4 - notified with a new notification that the sender wants to call the MM _A back. This notification preferably contains the conditions for deletion.

The deletion of the MM _A can therefore take place directly in the receive application UAB, provided that this supports the callback feature. If the case is 3, the MM is only deleted if the terminal determines that the MM has not yet been opened or read. de. In case 4, the deletion is initiated regardless of this. In both cases, the MM _{B of} the receiving application UAB does not have to be delivered. It can already be deleted in MMSE _B , since the notification is the trigger for deletion. For cases 1

(Callback before notification) and 2 (callback only before downloading) the callback cannot take place. The sender preferably receives a feedback with the information that the MM could not be called back because a notification has already been sent

(Case 1) or because the MM has already been downloaded

(Case 2).

According to the invention, a further possibility for realizing the deletion process is to deliver the MM _B with the callback information up to the receive application UAB. The deletion is then triggered in the recipient's terminal device by the MM _B and not by the notification resulting from the MM _B. This case will not be dealt with in more detail below.

The client of the recall (sending application UAA or VAS application) is preferably informed in all cases described about the outcome and, if applicable, the date of execution of the action initiated by him, especially if he requests it and the MMS service providers involved also enable this.

In order to be able to implement the "conditional callback" service feature just described, it is proposed according to the invention that one or more of the following information additionally be sent between the entities involved (sending application UAA, MMS network element RSA, MMS network element). RSB and receiving application UAB). The current 3GPP specifications 3G TS 22.140 version 4.0.1 (see above), 3G TS 23.140 version 4.0.0 (see above), WAP specifications WAP-209-MMS Encapsulation, Release 2000 (see above), WAP-203-WSP, version serve as the basis 4-May-2000 (see above) and Report of the 3GPP TSG-T2 SWG3 MMS Ad Hoc Meeting # 5 (see above). The differences and additions compared to the unconditional recall are discussed in more detail below:

Send application UAA (MMS User Agent A) -> network element RSA (MMS Relay / Server A) (when sending an MM): • Conditions for executing the callback:

- Call back only before notification. - Call back only before downloading, even after sending a notification.

- Call back only if the MM was not opened / read.

- Callback regardless of the degree of processing of the MM (even after reading the MM _A ).

Network element RSA (MMS Relay / Server A) - Send application UAA (MMS User Agent A) (when confirming after sending an MM): • Notification of the service provider whether this supports the conditional callback feature. Here the system could differentiate between support for "callback" and "conditional callback".

Network element RSA (MMS Relay / Server A) → network element RSB (MMS Relay / Server B) (only necessary if sender and recipient belong to different MMSEs): • Conditions for performing the recall:

- Call back only before notification.

- Call back only before downloading, even after sending a notification - Call back only if the MM was not read.

- Callback regardless of the degree of processing of the MM (even after reading).

Network element RSB (MMS Relay / Server B) - »Receive application UAB (MMS User Agent B) (when notifying about the received MM _B ):

• Conditions for performing the recall:

- Call back only before downloading, even after sending a notification. This condition is only communicated if the MM has not been downloaded.

- Call back only if the MM was not read.

Receiving application UAB (MMS User Agent B) - network element RSB (MMS Relay / Server B) (after notification):

• Information as to whether the conditional recall request could be successfully executed.

• In the event of failure, a corresponding message with a possible reason.

Network element RSB (MMS Relay / Server B) - Network element RSA (MMS Relay / Server A) (only necessary if the sender and recipient belong to different MMSEs and if the sender has requested feedback): • Information as to whether the conditional recall request could be executed successfully.

• In the event of failure, a corresponding message with a possible reason.

Network element RSA (MMS Relay / Server A) -> Send application UAA (MMS User Agent A) (for the report):

• Information as to whether the conditional recall request could be executed successfully. • In the event of failure, a corresponding message with a possible reason.

Adjustments to the WAP messages

Possible modifications of the WAP messages for the service feature “callback” are explained in more detail below. It should be said that in the WAP specifications the MMS user agent corresponds to the MMS client and instead of the MMS relay / server the MMS proxy / relay is mentioned. WAP-203-WSP, Version 4-May-2000 (see above), if the MMS User Agent is mentioned here, it should also include the MMS Client. The same applies to the terms MMS Relay / Server and MMS Proxy / Relay For the sake of clarity, only the terms MMS User Agent and MMS Relay / Server are used below.

In order to insert the "callback" service feature into the WAP implementation of MMS, a modification of the WAP messages M-Send. Req, M-Send. Conf, M-

Notification. ind, M-NotifyResp. ind and M-Delivery. and suggested. According to the invention, various header fields (header fields) are supplemented or modified therein. ed. According to WAP-203-WSP (see above), each header field consists of a coded field name and a coded field value. There are a total of four options for coding the field value, the first octet of the field value deciding on the type and length of the coding (see Table 1).

A.I. WAP message M-Send. req (from transmission application UAA to network element RSA)

The sender of an MM _A should express that he wants to call his MM _A back. This is done by sending another MM _B to the same recipient. For this purpose, M-Send. req, with which the MM _{B is} sent, a header field is added that bears the identification number of the MM that the sender wants to call back (ID1 of MM _A from FIG. 2). It is proposed that this header field be named X-Mms -Recall -ID and the hexadecimal code 0x7F (decimal: 127). Message IDs are encoded in accordance with the encapsulation standard (WAP-209-MMS Encapsulation, Release 2000; Wireless Application Protocol; WAP Multimedia Messaging Service; Message Encapsulation; MMS Proposed SCD 1.0), preferably as a so-called text string. In addition, the sender of an MM with a recall order can preferably be given the opportunity to request a response. For this purpose, it is proposed to insert a header field with the appropriate designation XM s -Request -Report and the hexadecimal coding 0x85 (decimal: 133) in the WAP message M-Send. introduce req. The field values of this header field preferably conform to the encapsulation standard (see above) with the <Oc- coded tetl28> for "feedback is requested" and <Octetl29> for "feedback is not desired".

Furthermore, it is proposed to add a new header field in the event of a conditional recall, which transmits these conditions for the execution of the recall command. A header field with the exemplary designation X-Mms-Recall-Cond is proposed for this purpose, which preferably has the hexadecimal coding 0x86 (decimal: 134). This header field is preferably used with the <Octetl28> for recall only before notification ("Recall only before notification"), with the <Octetl29> for recall only before downloading, even after sending a notification ("Recall only fore downloading "), with the <Octetl30> for the recall if the MM is not read (" Recall only before reading ") and with the <0ctetl31> for recall regardless of the degree of processing of the MM - even after reading - (" Recall even after Reading "). When introducing further conditions, appropriate field values should preferably be added. As an alternative to the introduction of <Octetl31>, it can also be agreed that a callback command without a header field X-Mms -Recall -Cond stands for "Recall even after Reading".

A.2 WAP message M-Send. conf (from the network element RSA to the transmission application UAA)

With this WAP message, the sending application UAA according to the present invention can additionally be informed whether the service provider A has accepted the sender's callback request (MMS User Agent A). For this purpose, it is advantageously proposed to use a new header field the name X-Mms -Supported- Feature and the hexadecimal coding 0x83 (decimal: 131) in the WAP message M-Send. insert conf. The <Octetl28> for an order confirmation and the <Octetl30> for negative feedback are preferably used as field values in accordance with the encapsulation standard (see above) (cf. FIG. 10).

In addition, the transmission application UAA can additionally be informed according to the invention whether the service provider A supports the conditional callbacks. For this purpose, it is suggested here that the field values of the X-Mms supported feature be supplemented with the hexadecimal coding 0x83 (decimal: 131), for example with the value <Octetl31>. This value stands for the support of the conditional recall. If the MM _{A is} still stored on the network element RSA and the receiving application UAB has not yet been notified, the MM is preferably deleted and the sending application UAA is preferably informed about this execution. For this purpose, the header field X-Mms status for the WAP message M-Send is proposed according to the invention. conf add. The new field value <Octetl38> for "Callback successful, before notification" is preferably defined. Furthermore, it is proposed here to define the new field value <Octetl42> for "Callback failed because notification was sent". This coded value informs the sending application UAA, which wanted to have carried out case 1 of the conditional callback (callback only before the notification) that the MM _A could not be deleted if the notification was already sent. This case can occur if the sending application UAA and the receiving application UAB are assigned to the same network element RS, here the network element RSA. A.3 WAP message M-Notification. ind (from the network element RSB to the reception application UAB)

If the receiving application UAB already has a

Downloadable MM _{A can be} informed, according to the present invention in the WAP message M-Notification. a newly defined header field with the appropriate name X-Mms -Recalled-URI and the hexadecimal coding 0x80 (decimal: 128) are used. With its help, the receiving application UAB can be informed that the MM _A with the specified URI is no longer available for download because the sender has called it back. The field value of this newly defined header field is preferably encoded in accordance with the encapsulation standard (see above) as a text string.

In order to be able to inform the receiving application UAB about the time of deletion, a newly defined header field with the appropriate designation X-Mms -Date-of -Execution and the hexadecimal coding 0x84 (decimal: 132) can be added in accordance with this invention , The field values for this header field are preferably encoded as long integers according to the encapsulation standard (see above).

According to the present invention, the storage space of a standard text message (for example: "This MM was deleted by the sender again") can be referenced in the URI of the notification, by means of which the network element RSB also uses a receiving application UAB can inform about a executed callback order if this does not support the callback service feature (i.e. the new one Header fields not recognized) and tries to download an MM from the space indicated in the notification.

If the MM _A that is to be called back has already been delivered to the receiving application UAB, the WAP message M notification can be made according to the invention. and include the header field defined in section Al with the name X-Mms-Recall -ID. The receiving application UAB can then immediately initiate the deletion of the MM _A using the message ID (ID2 from FIG. 2) (provided it supports the callback service feature).

If the MM _A to be deleted has been downloaded from the receiving application UAB, the receiving application UAB is preferably informed of the conditions for deleting the MM _A in the event of conditional recall. The header field XM s -Recall -Cond with the hexadecimal coding 0x86 (decimal: 134) is preferably used for this purpose. In this case, only the coded values <Octetl30> for the callback if the MM is not read ("Callback before reading") and <Ocetl31> for the callback regardless of the processing level of the MM ("Callback also after reading" ) needed. <0c- tetl28> for callback only before notification and <Ocetl29> for callback only before downloading, even after sending a notification, are not required here, because in this example the MM _A is deleted before sending the notification should take place.

A.4 WAP message M-NotifyResp. reg (from receiving application UAB to network element RSB) According to the present invention, it is advantageously proposed that M-NotifyResp in the WAP message. req optionally insert a new header field, with the help of which the network element RSB can be informed whether the receiving application UAB has understood the message about a successfully executed callback request. For this purpose, the header field X-Mms-Status known from other WAP messages is preferably used and a new field value is defined: It is proposed that the <Octetl36> has the meaning "feature callback supported".

If the MM _A to be recalled had already been delivered to the reception application UAB, an advantageous variant of the present invention proposes M-NotifyResp in the WAP. req to insert the iπv encapsulation standard (see above) header field X-Mms status, with which the network element RS can be informed whether the callback request of the sender could be successfully executed on the receiving application UAB or not. However, an extension of this header field is also necessary here: The feedback is preferably implemented with the two new field values <Octetl32 for "Callback request was successfully executed" and <Octetl33> for "Callback request could not be executed" ,

In the event of a conditional recall, in addition to the field values <Octetl32> for "Callback successful" and <Octetl33> for "Callback failed", as well as the field values suggested above <Octetl38> for "Callback successful" Notification "and <Octetl42> for "Callback failed because notification was sent" (see A.2) suggested the following field values:

- <Octetl40> for "Callback successful before MM was read"

- <0ctetl41> for "Callback successful after reading MM"

- <Octetl44> for "Callback failed because MM was read" - <Octetl45> for "Callback failed because MM was deleted".

Thanks to these messages, the sender of the recall command can then be informed of the exact outcome of his order.

A.5 WAP message M-Delivery. ind (from network element RSA to sending application UAA)

It is also suggested that the header field X-Mms-Status expanded in section A.4 should also be inserted here. With its help, the sender (sending application UAA) can be informed whether or not his callback request was successfully executed, even if the new field values <Octetl32> for "Callback request was successfully executed" and <Octetl33> for "Callback order could not be executed" can be used (see Fig. 6). In addition, the sender can be informed of the date of the execution of his callback order using the header field defined in Section A.3 with the appropriate designation X-Mms -Date-of-Execution. In addition, other new field values are preferably defined:

- <Octetl39> for "Callback successful, before downloading"

- <Octetl43> for "Callback failed because MM has already been downloaded"

Thus, the different field values of the header field X-Mms-Status within the WAP message M-

Delivery. a notification to the sender as to whether and under what circumstances his callback order was executed.

Another way to send a conditional sender

According to the invention, to inform the recall command about the execution of the order can be realized by defining a new header field which is used in the corresponding WAP messages. A header field with the exemplary name X-M s -Recall -Status is proposed. This header field can serve as a replacement for the extended header field X-Mms-Status in the cases described above. The latter can then continue to be used in the form defined in WAP-209-MMS Encapsulation, Release 2000 (see above). The new header field X-Mms -Recall -Status preferably only contains information on the execution of the recall request. The hexadecimal coding 0x88 (decimal: 136) is suggested for the X-M s - Recall status. The possible field values that cover the different execution scenarios are, for example:

- <Octetl28> for "callback successful" - <Octetl29> for "Callback successful, before notification"

- <Octetl30> for "Callback successful before downloading" - <Octetl31> for "Callback successful before MM was read"

- <Octetl32> for "Callback successful after reading MM"

- <Octetl33> for "Callback failed" - <Octetl34> for "Callback failed because notification was sent"

- <Octetl35> for "Callback failed because MM was downloaded"

- <Octetl36> for "Callback failed because MM was read"

- <Octetl37> for "Callback failed because message was deleted"

- <Octetl38> for "Callback failed, message not found" - <Octetl39> for "Callback failed, message forwarded".

For other reasons or conditions, the field values and codes can be supplemented accordingly.

B. CHANGE SERVICE FEATURES

According to this invention, a user of the MMS who has sent a multimedia message MM _A and would like to change the MM already sent later can send a new MM _B together with the information that this MM _{B should} change, especially replace, a previously sent MM _A. The explanations below apply very generally to changes to a first message MM _A , for example also to the subsequent attachment of a file to a previously sent MM _A.

A change in MM _A can be implemented by the sender composing a new MM _B that contains a change command and sending it to the same recipient as the previously sent MM _A. To identify the MM _A , the ID1 of the previously sent and now to be changed MM _A is advantageously used. The MM _B with the change information first arrives at the network element RSA. Here it is checked whether the MM _A with the IDl is still in the area of responsibility (MMSE _A ) of the service provider A or whether it is already in the MMSE _{B of} the service provider B. Both are possible, depending on whether the sender of the MM _{A has} specified a time for the earliest possible delivery or a period of validity. As soon as the MM _{A has been found} in an MMSE of the MMS service providers involved, the MM _B can be initiated by the responsible network element RS to change the MM _A. This action is preferably implemented in practice by deleting the old MM _A and forwarding the new MM _B to the

Receiver. According to this invention, the MMS service provider has the possibility of informing the reception application UAB of a change process which may have been carried out and / or of the date of the execution of the change process ("this MM was updated on ..."). If the recipient (receiving application UAB) of the MM _A has not yet received a notification about the MM _A , for example because the MM _B with the change request reaches the network element RSB before the MM _A to be changed, the latter does not necessarily have to be informed of a change action initiated by the sender become. Instead, the network element RSB can wait until it receives the MM _{A to be changed} , and changes, in particular replaces, it upon arrival by the MM _B (provided the MMS network element RSB supports the callback service feature). According to this invention, the MMS service provider can inform the receiving application UAB when the MM _B is delivered that it is an MM subsequently changed by the sender and when this change was carried out.

If the receiving application UAB has already been informed of the MM _A available for it in the MMSE _B by means of a notification (notification) and the MM _{A should} still be within the area of responsibility of the service provider B, according to this invention the receiving application UAB can be notified again ( Notification) that the sender has changed their MM _A afterwards and when this change was carried out.

If the MM _A has already been delivered to the recipient, either the receiving application UAB can first receive a notification from the service provider B that an MM _{B has been replaced} to replace the MM _A , or the MM _B with the change request can be sent directly to the receiving application UAB become. Regardless of whether the MM _{B has been delivered} in PUSH mode or in PULL mode, changing, in particular replacing, the MM _{A take place} through the MM _B directly in the receiving application UAB, provided this supports the change service feature. Depending on the implementation of this service feature in the terminal, the settings of the user, the settings of the service provider and / or the network operator, changing, in particular replacing, MM _A (and thus in the case of PULL mode: additionally requesting MM _B ) depend in the terminal on whether the MM _{A has} already been "touched" by the recipient (eg opened, read, forwarded, etc.). It seems sensible to change such MMs automatically (ie without asking the recipient), which have not yet been "touched" by the recipient. If the recipient has already taken the MM _A out of the inbox, forwarded it or read it, he can at least be informed that the sender wanted to change the MM _A previously sent with MM _B.

According to an advantageous variant of the invention, the sender / client (sending application UAA or VAS application) can be informed of the outcome and the date of execution of the change action initiated by him, if the participating MMS service providers support this.

The identification of MM _A on the receiving application UAB can take place in particular on the basis of a message reference, which is preferably a URI, under whose storage space a standard text message from the service provider B on the receiver side is stored. The URI is preferably made up of the identification number ID1 from MM _A or from a receiver-side network element. ment (in particular by the network element RSB) defined second identification number (ID2) together.

In order to be able to implement the service feature just described, in particular replacing, it is proposed according to the present invention that one or more of the following information is additionally exchanged between the entities involved (sending application UAA, network element RSA, network element RSB and receiving application UAB) :

• Identification that an MM _B is a change command.

• Identification number of the MM _A that is to be changed.

• Information that the sender requests feedback about the outcome of the change action initiated by him.

Network element RSA (MMS Relay / Server A) -> Send application UAA (MMS User Agent A) (when confirming after sending an MM): • Notification of the service provider whether this supports the change service feature.

Network element RSA (MMS Relay / Server A) - »Network element RSB (MMS Relay / Server B) (only necessary if the sender and recipient belong to different MMSEs):

• Identification that an MM _B is a change command. • Identification number of the MM _A that is to be changed.

• Information that the sender requests feedback about the outcome of the change action initiated by him

Network element RSB (MMS Relay / Server B) - »receiving application UAB (MMS User Agent B) (when notifying of an incoming MM), preferably in a message: • Information that the sender has a MM _A available for download with a new MM _{B has} changed. Both MMs are identified on the basis of the message references (URIs) for the MMs concerned.

• Information when the MM _A available for download was changed by the new MM _B. or:

• Information that the sender wants to change, in particular replace, a previously delivered MM _A with a new MM _B. The MM _A , which is updated, is identified on the basis of the individual message ID and the MM _B , which is intended to change, in particular replace, the MM _A , is identified using the message reference (URI).

Receiving application UAB (MMS User Agent B) → network element RSB (MMS Relay / Server B) (after notification): • Information as to whether the recipient could be informed about the change order.

If, in the case of PULL mode, the recipient was informed of an existing MM _B with a change request, he can obtain it from the network element RSB using the known mechanisms. In the case of the PUSH mode, the download of the MM _{B is} initiated by the MMS service provider and not by the recipient. In this case, the two previous steps, notification and its confirmation, can be omitted.

Network element RSB (MMS Relay / Server B) - »Receive application UAB (MMS User Agent B) (when delivering an MM):

• Identification that the MM _B contains a change request that is to be executed on the receiving application UAB.

• information which already delivered MM _A amended, in particular replaced, should be. The MM _A is identified using the individual message identification number (Message ID). or:

• Information that the MM _B just delivered is a later changed MM.

• Information on when MM _B was changed by the sender.

Receiving application UAB (MMS User Agent B) → network element RSB (MMS Relay / Server B) (after delivery of an MM):

• Information as to whether the change request could be executed successfully. • Information whether the change order was carried out automatically.

• Information as to whether the recipient has been informed about the change process (and / or has agreed to the change).

Network element RSB (MMS Relay / Server B) -> Network element RSA (MMS Relay / Server A) (only necessary if the sender and recipient belong to different MMSEs and if the sender has requested feedback):

• Information as to whether the change request could be executed successfully.

• Information when the change request was executed. • Information whether the change order was carried out automatically.

• Information whether the recipient has been informed about the change (and / or has agreed to the change).

• Information as to whether an already downloaded MM _{A has} been changed, in particular replaced, or whether the MM _A had not yet been delivered before the change.

• Identification number of the MM _A that was changed, in particular replaced.

Network element RSA (MMS Relay / Server A) → Send application UAA (MMS User Agent A) (for the report):

• Information when the change order was executed.

• Information whether the change order was carried out automatically. Information whether the recipient has been informed about the change (and / or has agreed to the change). Information whether an already downloaded MM _{A has been} changed, in particular replaced, or whether the MM _A had not yet been delivered before the change. Identification number of the MM _A that was changed, in particular replaced.

Additional feature: conditional change

According to a preferred embodiment of the invention, the sender of the change command can specify conditions for carrying out his request. The transmission application UAA or the VAS application determines in which case the previously sent MM is changed. The conditional change can also be referred to as "conditional replace".

According to the invention, the service provider can limit the use of the "change" service feature to the service provider's own or certain domains. This can be done, for example, by identifying the address of the recipient (telephone number, email address or other). Another option would be to use an additional identifier ( Flag) in the Modify command.

The conditional updating is preferably based on the processing phase of the previously sent message (here multimedia message MM). In this case, the sender decides in which state the MM should be deleted. Possible conditions for changing, especially replacing, are: 1. Change the MM only if it is on the server and the recipient has not yet been informed. This means that changes are only made if no notification has yet been sent.

2. Change the MM even when the notification

(Notification) already sent, but the MM has not yet been downloaded.

3. Change the MM if the recipient has not yet opened or read it. In this case, the change can also occur after the download.

4. Change the MM regardless of the degree of processing of the MM at the recipient. The change is also attempted here if the recipient has read the MM.

When realizing this service feature, a standard condition "Default value" is advantageously assumed. For example, it can be agreed that the standard condition corresponds to one of the four cases described above. This default setting can, for example - as long as nothing precise about the conditional execution of the change command The system could also be designed in such a way that such a change should only take place before the MM to be changed has been downloaded or even after opening or reading.

In the following, the transactions for the implementation of the MM status-related service feature "change" are dealt with. An MM _A that has already been sent can therefore be called back later by the sender by composing a new MM _B that contains a conditional change command and a new content (“Content / Message Body”) intended for the recipient. This new message is sent to the same recipient as the previously sent MM _A. The identification number (ID 1) of the previously sent MM _{A is} used as the change identifier (see above). The MM _B with the change information first arrives at the sender's network element RSA. Here it is checked whether the MM _A with ID 1 is still in the area of responsibility of service provider A (MMSE _A ), or whether it has already been forwarded to MMSE _B of service provider B. The former is the case, for example, if the time selected by the sender for the desired delivery of his MM _A has not yet been reached; the latter is the case, for example, if the MM _A has not yet exceeded its validity period and still does has not been delivered to the receiving application UAB.

As soon as the MM _{A is found} in an MMSE, the change of MM _A by MM _B can be initiated by the responsible network element RS. If the original recipient has forwarded the MM addressed to him to another address, the change command should also be forwarded accordingly by the network element RS. If the network element RSB only has the information that the MM has been forwarded without knowing the destination (for example if the original recipient has forwarded the MM addressed to it to an e-mail address), the sender of the change command can be informed of the failure of the call back due to the forwarding be lubricated. For reasons of confidentiality, it would also be possible to report the failure of the execution without commenting on the reason in this case.

A particularly favorable case for executing the change command is when the MM is still on the network element RSA or RSB and the receiving application UAB has not yet been notified of this message. Such a case could occur, for example, if the MM should, at the sender's request, be delivered from a certain point in time that has not yet occurred. Here the MM is still on the network element RSA of the sender. The MM can also be stored on the network element RSB, if e.g. the recipient's end device is switched off and the validity period of the MM has not been exceeded. In these two cases, the MM can be changed regardless of the selected deletion conditions. All four change conditions described above cover this situation.

If the receiving application UAB has already been informed of the MM _A available for it in the MMSE _B by means of a notification (notification) and the MM _{A should} still be in the area of responsibility / memory of the service provider B, the change according to the invention can only be made in the above with 2, 3 and 4 numbered cases. In case 1 of the conditional change, the sender preferably receives a message that the recipient has already been informed about the previously sent MM and that the change could not be made. For the other cases (2, 3 and 4) the receiving application UAB can be informed with a new notification (notification) that the MM _A by the MM _{B was} changed and is therefore no longer available for download. Instead, the recipient can request the new MM _B.

If the MM _A has already been delivered to the recipient, the change can only be made for case 4 (change, regardless of the processing level) and under certain circumstances for case 3 (change, only if MM has not yet been opened / read). The receiving application UAB is - preferably only for cases 3 and 4 - informed with a new notification that the sender wants to change the MM _A. This notification preferably contains the conditions of the change. The update of the MM _A can therefore take place directly in the MMS User Agent B, if this is the case

Service feature "Change" supported. If it is case 3, the MM is preferably only changed if the terminal determines that the MM was not opened or read. For case 4, the change is triggered independently of this The change cannot be made for cases 1 (change before notification) and 2 (change only before downloading) The sender preferably receives a message stating that the MM could not be changed because a notification has already been sent (Case 1) or because the MM has already been downloaded (Case 2).

A further possibility for realizing the change process is, according to the invention, the delivery of the MM _B with the change information up to the receive application UAB. The change is then triggered in the recipient's terminal device by the MM _B and not by the notification resulting from the MM _B. This case is widely not dealt with in more detail.

The client of the change (UAA or VAS application) is preferably informed in all cases described of the outcome and, if applicable, the date of execution of the action initiated by him, especially if he requests it and if the MMS service providers involved make this possible.

Since the conditional change is an MM that is intended to reach the receiving application UAB, MMSEs (multimedia messaging service environments) that do not support this service feature treat the new MM _B preferably as a simple MM. It therefore becomes the receiving application UAB - without replacing the MM _A - achieve as a new MM. The sender is also preferably informed of this.

In order to be able to implement the "conditional change" service feature just described, it is proposed according to the invention that one or more of the following information is additionally exchanged between the entities involved (transmit application UAA, network element RSA, network element RSB and receive application UAB) the current 3GPP specifications 3G TS 140 version 4.0.1 (see above) and 3G TS 23.140 version 4.0.0 (see above) and WAP specifications WAP-209-MMS Encapsulation; Release 2000 (see above), WAP-203 WSP (see above) and Report of the 3GPP TSG-T2 SWG3 (see above). The differences and additions compared to the unconditional changes are discussed in more detail below:

Send application UAA (MMS User Agent A) - »network ele- RSA (MMS Relay / Server A) (when sending an MM):

• Conditions for executing the change:

- Change only before notification.

- Change only before downloading, even after sending a notification.

- Change only if the MM was not opened / read.

- Change regardless of the degree of processing of the MM (even after reading the MM _A ).

Network element RSA (MMS Relay / Server A) - Send application UAA (MMS User Agent A) (when confirming after sending an MM):

• Notification from the service provider whether it supports the conditional change feature. Here the system could distinguish between "change" and "conditional change" support.

Network element RSA (MMS Relay / Server A) -> Network element RSB (MMS Relay / Server B) (only necessary if the sender and recipient belong to different MMSEs):

• Conditions for performing the replacement:

- Change only before notification.

- Change only before downloading, even after sending a notification.

- Change only if the MM was not read.

- Change regardless of the degree of processing of the MM (even after reading).

Network element RSB (MMS Relay / Server B) - »Receive application UAB (MMS User Agent B) (when notifying about the received MM _B ): • Conditions for executing the change:

- Change only before downloading, even after sending a notification. This condition is only communicated if the MM has not been downloaded.

- Change only if the MM was not read.

- Change regardless of the degree of processing of the MM (even after reading).

Receiving application UAB (MMS User Agent B) -> network element RSB (MMS Relay / Server B) (after notification):

• Information as to whether the conditional change job could be executed successfully. • In the event of failure, a corresponding message with a possible reason.

Network element RSB (MMS Relay / Server B) - Network element RSA (MMS Relay / Server A) (only necessary if the sender and recipient belong to different MMSEs and if the sender has requested feedback):

• Information as to whether the conditional change job could be executed successfully.

• In the event of failure, a corresponding message with a possible reason.

• In the event of failure, a corresponding message with a possible reason. Adjustments to the WAP messages

Possible modifications of the WAP messages for the change service feature are explained in more detail below. The adaptations and assignments are exemplary and can be varied: in order to introduce the change service feature in the WAP implementation of MMS, a modification of the WAP according to the present invention

News M-Send. req, M-Send. conf, M notification. ind, M-NotifyResp. req, M-Retrieve. conf, M acknowledge. ind and M-Delivery. and suggested. Various header fields are advantageously supplemented or modified in them analogously to the procedure in section A (service feature callback). In the following, MMS user agent or MMS proxy / server is again spoken of, which also means MMS client or MMS proxy / relay.

B.l WAP message M-Send. req (from transmission application UAA to network element RSA)

The sender of an MM should be able to express that he would later like to change, in particular replace, his already sent MM _A with a new MM _B. For this purpose, M-Send is preferred in the WAP message. req, with which the new MM _{B is} sent, supplements a further header field which bears the identification number of the MM which is to be changed, in particular replaced, by MM _B (namely ID1 of MM _A from FIG. 2). It is proposed that this header field be named X-Mms - Replace-ID and the hexadecimal coding 0x81 (decimal: 129). Message IDs conform to the encapsulation Standard (see above) preferably encoded as a text string. In addition, the sender of an MM with a change order is preferably given the option of requesting confirmation. For this purpose, it is proposed that the header field defined in section A1 with the appropriate designation X-Mms-Request-Report with the hexadecimal coding 0x85 (decimal: 133) in the WAP message M-Send. introduce req. The field values of this header field are advantageously coded in accordance with the encapsulation standard (see above) with the <0ctetl28> for "feedback is desired" and <octet29> for "feedback is not desired".

Furthermore, it is proposed to add a new header field that communicates conditions for executing the change command. A header field with the exemplary designation X-Mms-Replace-Cond is proposed for this purpose, which preferably has the hexadecimal coding 0x87 (decimal: 135). This header field is preferably used with the <Octetl28> for replacement only before notification ("Replace only before notification"), with the <Octetl29> for replacement only before downloading, even after sending a notification ("Replace only before downloading "), with <Octetl30> for replacing in the event of non-reading (" Replace only before reading ") and with <0ctetl31> for replacing regardless of the degree of processing of the MM - even after reading - (" Replace even after Reading ") encoded. When introducing further conditions, appropriate field values should preferably be added.

B. 2 WAP message M-Send. conf (from the network element RSA to the transmission application UAA) With this WAP message, the sending application UAA according to the present invention can be informed whether the service provider A has acted or was able to act in accordance with the change request from the sender (sending application UAA). For this purpose, it is proposed to use the header field introduced in section A.2 for the purpose of the callback service feature with the appropriate designation X-Mms-Supported-Feature, preferably also here. The field values are then either the <Octetl29> for "Change characteristic supported" or the <Octetl30> for "No support".

Furthermore, in the event of a conditional change, it is suggested that the field values of the X-Mms supported feature be supplemented with the hexadecimal coding 0x83 (decimal: 131) with the value <Octetl32>. This value stands for the support of the conditional change or replacement. If the MM _{A is} still stored on the network element RSA and the receiving application UAB has not yet been notified, the MM is changed and the sending application UAA is preferably informed about this execution. For this purpose, it is proposed according to the invention that the header field X-Mms status for the WAP message M-Send. conf add. The new field value <Octetl48> for "Change successful before notification" is preferably defined. Furthermore, it is proposed here to define the new field value <Octetl52> for "Change failed because notification was sent". This coded value informs the sending application UAA, which wanted to have executed case 1 of the conditional replacement (change only before the notification), that the MM _A could not be updated because the notification was already sent. This case can occur when the send application UAA and receive application UAB are assigned to the same network element RS, that is to say network element RSA. Furthermore, further new field values are preferably defined: <Octetl49> for "Change successful before downloading", and

<Octetl53> for "Change failed because MM was downloaded".

The latter case can occur if the sender has requested case 2 of conditional change (change before downloading).

B.3 WAP message M-Notification. ind (from the network element RSB to the reception application UAB)

According to this invention in the WAP message M notification. but preferably a newly defined header field with the appropriate designation X-Mms-Replaced-URI and the hexadecimal coding 0x82 (decimal: 130) is added. With its help, the receiving application UAB can be informed after a notification has already been given that the MM _A is no longer available for download under the specified URI because the sender has replaced it with a new MM _B with a different URI. The field value of this newly defined header field is advantageously encoded in accordance with the encapsulation standard (see above) as a text string. In order to be able to inform the reception application UAB of the time of the update, the one defined in section A.3 is redefined in accordance with an advantageous variant of the invention

Header field with the appropriate designation X-Mms -Date-of- Execution added. If the MM _A to be changed, in particular to be replaced, is already on the receiving application UAB, the WAP message advantageously contains M notification. and supplemented the header field newly defined in section B1 with the appropriate designation X-Mms -Replace - ID and the hexadecimal coding 0x81 (decimal: 129). The receiving application UAB recognizes from this that the MM _B available for download contains a change command for the MM _A with the corresponding message identification number. The download of the MM _B can then be initiated either in the PUSH mode or in the PULL mode, depending on the settings of the user, the settings of the MMS service provider and / or the network operator.

As mentioned, the WAP message informs M-Notification. In particular, the receiving application UAB should replace the arrival of the message MM _B , which change MM _A. For the conditional change, the receiving application UAB must be informed about the conditions of the change. The newly defined header field X-Mms -Replace -Cond with the hexadecimal coding 0x87 (decimal: 135) is preferably used for this. In this case, only the coded values <Octetl30> are required for changing, only if the MM has not been read, and <Octetl31> for changing regardless of the degree of processing of the MM (even after reading). <Octetl28> for changing only before notification and <Octetl29> for changing only before downloading - even after sending a notification - are not required here, since in both cases the MM should be changed before the notification is sent , If the conditions for changing the MM _{A are} met, this MM can already be deleted even before MM _B arrives in the receiving application UAB.

B.4 WAP message M-NotifyResp. ind (from receiving application UAB to network element RSB)

According to the invention, M-NotifyResp is proposed in the WAP message. and insert the X-Mms-Status header field defined in the Encapsulation standard (see above). So that the network element RS can be informed whether the change request from the sender was successfully carried out in PUSH mode or not, an extension of this header field is also necessary here (analogous to the procedure in Section A, Callback service feature): Avoidance in this invention is preferably implemented with the two new field values <0ctetl34> for "change request was successfully executed" and <0ctetl35> for "change request could not be carried out".

In addition to the previously suggested field values <0ct-tetl34> and <0ctetl35> as well as the above-suggested field values <0ctetl48> for "Change successful before notification" and <0ctetl52> for "Change failed because notification was sent" following field values suggested:

- <Octetl50> for "Change successful before MM was read"

- <Octetl51> for "Change successful after MM has been read"

- <Octetl54> for "Change failed because MM was read"

- <Octetl55> for "Replace failed because MM has been deleted ".

Thanks to these notifications, the sender of the change command can then be informed of the exact outcome of his order.

B.5 WAP message M-Retrieve. conf (from the network element RSB to the reception application UAB)

If the MM _A to be changed could already be changed in the MMSE _B by the MM _B , then according to the present invention, M-Retrieve is available in the WAP message. conf, with which MM _{B is} transmitted to the reception application UAB, preferably the extended header field X-Mms status defined in the encapsulation standard (see above) with the field value <Octetl34> for "change successful" and that in Section A.3 to insert a newly defined header field with the appropriate designation X-Mms-Date-of-Execution, so that the network element RSB can signal to the receiving application UAB that the MM _{B is} a subsequently changed MM and when the change request of the Sender in the area of responsibility of MMSE _{B has been} executed.

If the MM _{A to be changed is} already on the receiving application UAB, it is advantageous according to the present invention to use M-Retrieve in the WAP message. conf also add the name X-Mms -Replace -ID to the header field defined in section B1. It can be used to initiate the change of the MM _A on the receive application UAB using the message ID (see FIG. 2) if the receive application UAB supports the change service feature. Otherwise the recipient is only informed shows that the sender wanted to change the MM _A with the new MM _B.

In the event of conditional changes, it is proposed to advantageously add the header field X-M s -Replace-Cond defined above to this message. The field values <Octetl30> for "Replace only if the MM was not read" and <Octetl31> for "Replace regardless of the degree of processing of the MM", i.e. even after reading. This informs the receiving application UAB in which case the old MM should be replaced.

B.6 WAP message M-acknowledge. ind (from the reception application UAB to the network element RSB)

According to this invention, an advantageous further development proposes M-Acknowledgment in the WAP message. and insert the X-Mms-Status header field defined in the Encapsulation standard (see above). So that the network element RS can be informed whether the change request from the sender could be successfully carried out in PULL mode or not, an extension of this header field is also necessary here (analogous to the procedure in Section A, callback service feature): The response will be in this invention advantageously realized with the two new field values <0ctetl34> for "change request was successfully executed" and <Octetl35> for "change request could not be carried out".

The field values <Octetl49>, _< θc- tetl50>, <Octetl51>, <Octetl53>, <0ctetl54> and <Oc- tetl55> can be used (see above).

B.7 WAP message M-Delivery. ind (from network element RSA to the sending application UAA)

It is also proposed to insert the X-Mms-Status header field expanded in Sections B.4 and B.6 here. With its help, the sender (sending application UAA) can be informed whether his change request could be successfully carried out or not, if the above-mentioned new field values are also used here, whereby some or all of the values described above can occur. In addition, the sender is advantageously informed of the date of the execution of his change request using the header field defined in section A.3 with the appropriate designation X-Mms - Date-of-Execution.

Another possibility of informing the sender of a conditional change command about the execution of the change request can be realized according to the invention by defining a new header field which is used in the corresponding WAP messages. A header field with the exemplary name X-Mms -Replace -Status is proposed. This header field can serve as a replacement for the extended header field X-Mms-Status in the cases described above. The latter can also be used in the form defined in WAP-209-MMS Encapsulation, Release 2000 (see above). The new header field preferably only contains information on the execution of the change request. The hexadecimal coding 0x89 (decimal: 137) is proposed for the X-Mms -Replace- status. The possible field values that the different execution scenarios are, for example:

- <Octetl28> for "Change successful" - <Octetl29> for "Change successful before notification"

- <Octetl30> for "Change successful before downloading"

- <Octetl31> for "Change successful before MM was read"

- <Octetl32> for "Change successful after reading MM"

- <Octetl33> for "Change failed"

- <Octetl34> for "Change failed because notification was sent"

- <Octetl35> for "Change failed because MM was downloaded"

- <Octetl36> for "Change failed because MM was read" - <Octetl37> for "Change failed because message was deleted"

- <Octetl38> for "Change failed, message not found"

- <Octetl39> for "Change failed, message forwarded".

Another alternative to the X-Mms-Replace-Status together with the header field X-Mms -Replace- Status introduced above would be a new header field according to the invention the feedback can be used to execute the change and recall command. A header field with the exemplary name X-Mms - operation status is proposed for this. This header field can have the hexadecimal coding 0x90 (decimal: 138), together with the following field values:

- <Octetl28> for "execution successful"

- <Octetl29> for "execution successful, before notification"

- <Octetl30> for "Execution successful, before downloading"

- <0ctetl31> for "Execution successful before MM was read" - <Octetl32> for "Execution successful after MM was read"

- <Octetl33> for "execution failed"

- <0ctetl34> for "Execution failed because notification was sent" - <Octetl35> for "Execution failed because MM was downloaded"

- <Octetl36> for "Execution failed because MM was read"

- <Octetl37> for "Execution failed because message was deleted"

- <Octetl38> for "execution failed, message not found"

- <Octetl39> for "execution failed, message forwarded".

FIG. 5 again shows seven, advantageously newly introduced header fields including the codes of field name and field value. 6 shows the header field X-Mms-Status expanded by new field values. 7 and 8 show the header fields of the alternative implementation options (exemplary embodiments 3 and 4, see below). The corresponding additions in the header fields of the corresponding WAP messages are listed in Tables 2 to 8 at the end of the description. It is quite possible that only individual additions are made in these header fields.

In the case of conditional manipulation, FIG. 9 shows the newly introduced header fields Mms -Recall -Cond, X-Mms-Replace-Cond, X-Mms -Recall - Status, X-Mms-Replace-Status and X-Mms - Operation status including the encoding of field name and field value. 10 shows the header field X-Mms-Supported- Feature, which has been expanded by new field values. The header field X-M s status shown in FIG. 6 also contains new field values related to the conditional manipulation.

C. BINARY CODING

C.l Unconditional for recall or change

In the following exemplary embodiments, the header fields used in the WAP messages are dealt with in detail, without first providing for conditions for the recall or modification of a first message. The following scenario is assumed as an example: Send application UAA sends an MM _A consisting of a text and a JPEG image to a recipient and wants to call them back later (Example 1) or by Replace a new MM _B (example 2).

M-Send.req (sending application UAA - »network element RSA)

X-Mms-Message-Type: m-send-req X-Mms-Transaction-ID: 10 X-Mms- Version: 1.0

Date: Thu, 26 Oct 2000 12:12:19 +0100 From: abc @ si emens. de To: xyz@siemens.de

Subject: mul timedia message a Content-Type: multipart / related; boundary = "- = NextPart 000"

_ = _ NextPart_000_

Content-Type: text / plain; name = ' ^Λ meeting. txt "Con ten t - Transfer fer-Encodin: quoted -prin tabl e

Hello xyz, here is the desired agenda for our next meeting. Greetings, abc

__ = _ NextPart_000_ Content-Type; image / jpeg; name = "agenda. jpg"

Content transfer encoding: base64 Content ID: <1725782>

__ = _ NextPart_000_ - -

The sending application UAA of the user with the address ajbc@siej7iens.de sends an MM _A consisting of one Text (MIME content type "text / piain") and a JPEG image (MIME content type "image / jpeg") to the receiving application UAB of the user with the address xyz@siemens.de. The WAP message M-Send used for this purpose. For example, req carries the transaction identity number

ID10. The network element RSA then issues an individual identification number for the sent MM _A and confirms with the WAP message M-Send. conf that the WAP message M-Send. req has been transferred to the RSA network element without errors:

M-Send. conf (network element RSA -> send application UAA):

X-Mms -Message-Type: m-send-conf X-Mms - Transaction ID: 10 X-Mms - Version: 1. 0 X-Mms response status: ok

Message ID: AAAA. Illl @ mms-relay01. Siemens. de

In the two WAP messages M-Send. req and M-Send. conf uses the same transaction identity number (transaction ID). The WAP message M-Send. conf with the message identification number on the sending application UAA clearly the associated WAP

News M-Send. req can be assigned, creating the individual identification number AAAA. 111 l @ mms- relay01. Siemens. de the sent MM _A can be assigned. The network element RSA has for the MM _A in this example for the interface transmission application UAA /

Network element RSA the individual identification number AAAA. Illl @ mms-relay01. Siemens. de assigned, it is in the header field Message-ID. Example 1: Callback (unconditional)

The sender of MM _A would like to call them back (two hours later). This is done according to the invention with the help of a new MM _B that is sent to the same recipient as the MM _A that is to be recalled. At this point, M-send advantageously comes in the WAP. req the header field redefined in accordance with the present invention with the appropriate designation X-Mms -Recall -ID, in which the message ID of the MM _A to be recalled is entered (IDl in FIG. 2). The WAP message also contains M-Send. req advantageously the header field, likewise redefined in accordance with the present invention, with the expedient designation X-Mms -Request -Report, with which a response can be requested about the recall request placed. In the WAP message M-Send. In a callback request, req preferably only contains the header fields and no further multimedia content (“message body”). As in the following, the newly defined header fields are framed.

M-Send. req (transmission application UAA - »network element RSA)

X-M s message type: m-send-req X-Mms transaction ID: 16 X-Mms version: 1. 0

Date: Thu, 26 Oct 2000 14:12:19 +0100 From: abc @ sal. si emens. de To: xyz @ sal. si emens. de

X-Mms -Recall -ID: AAAA. llll @ mms- relayOl. Siemens. de X-Mms -Request -Report: Yes

Subject: recall of mul timedia message a Content-Type: text / plain

Also the receipt of the WAP message M-Send. req with the callback command in MM _B is advantageously sent immediately by the network element RSA with a WAP message M-Send. conf acknowledged. It contains the message identification number assigned by the network element RSA for the MM _B (here: AAKA. 2222 @ mms-relay01. Siemens. De). Furthermore, it advantageously contains the header field X-Mms-Supported-Feature newly defined according to the present invention, with the aid of which the sending application UAA can be used to indicate whether the service provider A supports the callback service feature (as shown here) or not.

M-Send. conf (network element RSA - »transmission application UAA):

X-Mms -Message - Type: m-send-conf X-Mms -Transaction-ID: 16 X-Mms - Versi on: 1. 0 X-Mms -Response- Status: ok Message-ID: AAAA .2222 @ mms -relay01. Siemens. de

X-Mms Supported Feature: recall

When exchanging WAP messages on the receiving side (interface between network element RSB and receiving application UAB), a distinction must be made as to whether the receiving application UAB

1. has not yet been informed of an MM that has arrived, or 2. has been notified but the MM has not yet retrieved it, or

3. the MM has already received.

In the first and second case, the MM _A and also the MM _B that contains the callback command can be deleted in the area of responsibility of the service provider B (MMSE _B ). In the first case, the recipient does not even have to be informed. In the second case, however, the receiving application UAB should preferably be able to be informed by the service provider B that the MM _{A is} no longer available for downloading when the sender has subsequently called it back. According to this invention, the WAP message M-Notification. can be used:

2nd case: M-Notifi cation. ind (network element RSB -> receive application UAB):

X-Mms -Message -Type: m-notification-ind

X-Mms transaction ID: 20

X-Mms - Version: 1. 0

From: abc @ sal. si emens. de

X-Mms-Message-Class: Personal X-Mms-Message-Size: 42

X-Mms-Expiry: 3600

X-Mms content location: http: // mms- relay02. si emens. de / defaul t- recall -message

In the WAP message M-Notification. however, only the URI can be used for the identification of the recalled MM _A , since the network element RS has not yet assigned a "message ID" for the recalled MM _A (this only happens with the download). Fields X-Mms -Recalled-URI and X-Mms -Date-Of - Execution distinguish this recall notification from a "conventional" notification. In this example, the header field X-Mms-Content-Location refers to a URI, under the storage space of which a standard text message from service provider B is advantageous (for example: "The MM has been deleted by the sender.") Send and / or receive applications that do not understand the new header fields of the callback service feature can also be subsequently informed about a executed callback order.

With the WAP messages M-NotifyResp. req becomes the correct receipt of the WAP message M-Notification. ind confirmed. In this example, the header field X-Mms-Status bears one of the entries newly defined according to the present invention (namely “recall feature supported”) with which the network element RSB can be informed that the receiving application UAB is the second notification with the information about the recall.

(still) 2nd case: M-NotifyResp. req (receiving application UAB - network element RSB):

X-Mms -Message -Type: m-notifyresp-req X-Mms -Transaction- ID: 20 X-Mms - Version: 1. 0 XM s status: recall feature supported

However, if the MM _A that is to be deleted has already been transmitted to the receiving application UAB (third case), the WAP message advantageously contains M notification. but expediently not the notification of the callback that has already taken place, but rather the callback command itself, namely in the form of the header field with the appropriate designation X-Mms -Recall -ID, in which the identification number of the MM _A that is called back is entered should. The identification number (and not the URI) is preferably used here, because (in the third case described here) after the previous download, it is known to both the network element RSB and the receiving application UAB.

3rd case: M-Notification. ind (network element RSB - receiving application UAB):

X-Mms-Message-Type: m-notification -ind

X-Mms transaction ID: 25

X-Mms version: 1. 0 From: abc @ sal. Siemens. de

X-Mms -Mes say -Class: Personnel

X-Mms-Message-Size: 42

X-Mms-Expiry: 3600

X-Mms - Conten t -Loca ti on: ht tp: // mms - relay02. si emens. de / defaul t- recall -message

X-Mms-Recall -ID: BBBB.3333@mms- relay02. Siemens. de The header field X-Mms-Content-Location in this example refers to a URI, under whose storage space a standard text message from service provider B (eg: "The sender wants the MM with the message ID BBBB. 3333 @ mms - relay02. siemens. de call back. "). Sending and / or receiving applications that do not understand the new header fields of the callback service feature can also be subsequently informed about a callback order sent by the sender.

In order to emphasize that the MM _A can carry a different "message ID" at this interface, the value BBBB. 3333 @ mms-relay02. Siemens. De was selected in this exemplary embodiment (corresponds to ID2 of MM _A in FIG. 2 ).

(still) 3rd case: M-NotifyResp. req (receiving application UAB - network element RSB):

X-Mms message type: m-notifyresp-req X-Mms transaction ID: 25 X-Mms version: 1. 0

X-Mms status: recall successful

In this exemplary embodiment, the reception application UAB sends the MAP NotifyResp with the WAP. req a feedback back to the network element RSB. For this purpose, the header field X-Mms status from the encapsulation standard (see above), which has been expanded in this invention, is advantageously used. In this exemplary embodiment, the MM _A on the receiving application UAB could be deleted, which is expressed by the field value “recall successful”. In the network element RSB, the transaction ID (here: 25) of the WAP message pair on the message identification number (here: BBBB. 3333 @ mms-relay02. siemens. de) of the deleted MM _A. This makes it possible to write a response if this is requested by the sender and supported by service provider B.

M-delivery. ind (network element RSA - sending application UAA):

X-Mms-Message-Type: m-delivery-ind

X-Mms message ID: AAAA.2222@mms-relay01. Siemens. de

X-Mms version: 1. 0

To: abc @ sal. si emens. de

Date: Thu, Oct 26, 2000 2:14:09 pm +0100

X-Mms status: recall successful

If the sender requests feedback for the callback order initiated by him, the MMS Relay / Server A can use the WAP message M-Delivery. Send a feedback back to the UAA sending application. The identification number of the callback order is in the field "Message -ID". The extended header field X-Mms-Status is also used for the status of the callback, in which the successful deletion of the MM _A with the Field value "recall successful" is confirmed. Since the sending application UAA knows the relationship between the message identification number of the recall order and the message identification number of the MM _A that should be recalled, the sender can be informed whether his recall request was successful or not (provided the MMS involved Service providers support this). Example 2: Change (unconditional)

In this example, the sender wants to update his MM _A (one hour after sending): From the originally sent two elements, only the JPEG image (MIME content type "image / jpeg") should be retained. In addition, the subject in " Agenda for our meeting ".

According to this invention, a new MM _{B is sent} to the same recipient as the previously sent MM _A that is to be changed or replaced. For this purpose, the header field with the expedient designation X-Mms-Replace-ID, according to the present invention, is advantageously used, in which the "Message-ID" of the MM _{A is} entered. In addition, the WAP message advantageously contains M- Send. Req is the header field, also redefined in accordance with the present invention, with the secondary designation X-Mms-Request-Report, with which a response to the change request can be requested (as shown in this example).

M-Send. req (sending application UAA → network element RSA):

X-Mms message - Type: m-send-req X-Mms transaction ID: 32 X-Mms version: 1. 0

Godfather; Thu, 26 Oct 2000 13: 12: 11 +0100 From: abc @ sal. si emens. de

To: xyz @ sal. si emens. de

X-Mms -Replace -ID: AAAA. llll @ mms - relayOl. Siemens. de X-Mms request report: Yes

Subject: Agenda for our meeting Content-Type: mul tipart / related; boundary = "■ _ = _ NextPart_023_"

_ = _ NextPart_023_

Content-Type: Image / jpeg; name = "agenda. jpg" content transfer encoding: base64 content ID: <1725782>

= NextPart 023 - ^■

Also the receipt of this WAP message M-Send. req, which carries the MM _B with the change command, is preferred by the network element RSA immediately with a WAP message M-Send. conf acknowledged. It expediently contains the message identification number (Message-ID) of the MM _B (here: AAAA. 5555 @ mms-relay01. Siemens. De) assigned by the network element RSA and the header field X-Mms-Supported, which is also newly defined according to the present invention - Contain feature with which the sending application UAA can be used to indicate whether service provider A supports or does not support the change service feature. In this example, the two WAP messages have the transaction identity number IDD32.

M-Send.conf (network element RSA → send application UAA):

X-Mms -Message - Type: m- send- conf X-Mms -Transaction-ID: 32 X-Mms - Version: 1. 0 X-Mms response status: ok

Message ID: AAAA. 5555 @ mms-relay01. Siemens. de

X-Mms - Supported-Feature: replace

1. has not yet been informed of an MM that has arrived, or

2. has been notified but the MM has not yet retrieved it, or

3. the MM has already received.

In the first and second case, the MM _A in the area of responsibility of the service provider B (MMSE _B ) can be changed, in particular replaced, by the MM _B. The invention enables the recipient to be informed in the first case, both when the notification and when downloading, that the MM is a subsequently changed, in particular replaced, MM and when the change request was carried out. In the second case, the service provider B can preferably inform the reception application UAB immediately after executing the change order in the MMSE _B that the sender MM _A has been updated by a new MM _B and when this update was carried out. According to this invention, this notification should preferably by means of the WAP message M-Notification. and in which only the URI can be used for the identification of the changed, in particular replaced, MM _A , since the network element RSB has not yet assigned a message identification number {“message ID”) for the MM _A (this happens only with the download of the MM _A ). The header fields X-Mms-Replaced- URI and X-Mms -Date-Of-Execution distinguish this callback notification from a "conventional" notification. The header field X-Mms-Content-Location indicates where the MM _B with the current content can be found on the server.

2nd case: M-Notification. ind (network element RSB → receiving application UAB):

X-Mms -Message - Type: m -noti fi ca ti on - ind

X-Mms transaction ID: 35

X-Mms - Version: 1. 0

From: abc @ sal. si emens. de X-Mms Message Class: Personnel

X-Mms -Message -Size: 45

X-Mms Expiry: 3600

X-Mms - Conten t -Loca ti on: ht tp: // mms - relay02. Siemens. de / BBBB. 4444

With the WAP message M-NotifyResp. req advantageously becomes the correct reception of the WAP message M-notification. and confirmed by the receiving application UAB, cf. Fig. 2. The header field X-Mms-Status carries in this example an entry newly defined according to the present invention (namely "replace feature supported") with which the network element RSB is informed that the receiving application UAB is the understood the second notification with the information about the executed change order.

(still) 2nd case: M-NotifyResp. req (receiving application UAB - »network element RSB):

X-Mms message type: m-notifyresp-req X-Mms transaction ID: 35 X-Mms version: 1. 0

X-Mms status: replace feature supported

However, if the MM _A that is to be changed has already been transmitted to the receiving application UAB (third case), according to this invention the WAP message includes M notification. but advantageously not the notification of a change that has already taken place, but rather the change command itself, specifically in the form of the header field with the appropriate designation X-Mms - Replace-ID, in which the identification number of the MM to be changed, in particular to be replaced, is given _{A is} entered. The downloading of the MM _B can then be initiated by the receiving application UAB either in the PUSH mode or in the PULL mode using the WSP GET command. The header field X-Mms-Content-Location in this example refers to a URI, under whose storage space a standard text message from the service provider B (e.g .: "The sender wants the MM with the message ID BBBB. 3333 @ mms-relay02. Siemens. De later. "). Receiving applications that do not understand the new header fields of the callback service feature can be subsequently informed about a change request sent by the sender. 3rd case: M-Notification. ind (network element RSB -> • receive application UAB):

X-Mms -Message-Type: m-notification-ind X-Mms -Transaction-ID: 38 X-Mms - Versi on: 1. 0 From: abc @ sal. si emens. de X-Mms-Message-Class: Personal X-Mms-Message-Size: 45 X-Mms-Expiry: 3600

X-Mms - Content-Location: http: // mms - relay02. Siemens. de / defaul t-replace-message

X-Mms -Replace -ID: BBBB. 3333 @ mms- relay02. si emens. de

In response to the WSP GET command, with which the URI is sent to the network element RSB, the receiving application UAB receives the MM _B with the changed title and the changed multimedia content (only a JPEG image) for changing or replacing MM _A in the WAP message M-Retrieve. conf delivered. Also in the WAP message M-Retrieve. conf should advantageously be added to the header field with the appropriate designation X-Mms -Replace -ID. The MM _A can thus be changed, in particular replaced, on the receiving application UAB by the MM _B if the receiving application UAB supports the change service feature. Depending on the delivery mode selected, M-Retrieve is displayed in the WAP message. conf the transaction identity number from the WAP message M-Notification. ind accepted (PUSH mode) or a new one assigned (PULL mode). (still) 3rd case: M-Retrieve. conf (network element RSB - receiving application UAB):

X-Mms message - Type: m-re tri eve - conf X-Mms transaction ID: 38 or 48

Message ID: BBBB.4444@mms-relay02. siemens. de X-Mms version: 1.0

Date: Thu, 26 Oct 2000 13:12:11 +0100 From: abc @ sal. si emens. de X-Mms -Message-Class: Personal X-Mms -Message-Size: 42 X-Mms-Expiry: 3600

X-Mms-Replace-ID: BBBB.3333@mms- relay02. Siemens. de Subject: Agenda for our meeting

Content-Type: multipart / related; boundary = "■ _ = _ NextPart_023_"

_ = _ NextPart_023_ Conten -Ty e; image / jpeg; na e- "agenda.jpg"

Content transfer encoding: base64 Content ID: <1725782>

_ = _ _-- TfextPart_023

In order to emphasize that the MM _A can carry a different message identification number (“Message ID”) at this interface, the value BBBB.3333@mms-relay02.siemens.de was selected in this exemplary embodiment (corresponds to ID2 in FIG. 2).

When delivering MM _B in PULL mode: 3rd case: M-Acknowledge. ind (receiving application UAB - »network element RSB):

X-Mms -Message - Type: m -acknowl edge -ind X-Mms -Transaction-ID: 48 X-Mms - Version: 1. 0

X-Mms status: replace successful

If the MM _{B was delivered} in PULL mode, the receiving application UAB preferably sends the WAP message M-Acknowledge. and feedback back to the network element RSB. The X-Mms-Status header field expanded in accordance with this invention is used for this. In this exemplary embodiment, the MM _A on the reception application UAB could be replaced by the new MM _B , which is expressed by the field value “replace successful”. In the network element RSB, the transaction ID {Transaction-ID) (here : 48) of the WAP message pair M-Retrieve. Conf and M-Acknoledge. Ind on the message ID (here: BBBB. 3333 @ mms-relay02. Siemens. De) of the replaced MM _{A can be} concluded feedback is possible if this is requested by the sender and supported by service provider B.

When delivering MM _B in PCJSΗ mode

3rd case: M-NotifyResp. req (receiving application UAB → network element RSB):

X-Mms -Message - Type: m-noti fyresp - req X-Mms - Transaction-ID: 38 X-Mms - Versi on: 1. 0

X-Mms status: replace successful If the MM _{B was delivered} in PUSH mode, the receiving application UAB confirms the correct receipt of MM _B, preferably with the WAP message M-NotifyResp. req. For this purpose, the X-Mms-Status header field expanded in this invention is preferably used. In this exemplary embodiment, the MM _A on the receiving application UAB could be replaced by the new MM _B , which is expressed by the field value “replace successful”. In the network element RSB, the transaction ID (here: 38) of the WAP message Triples M-Notification. And M-Retrieve. Conf and M-NotifyResp. Req on the message ID (here: BBBB. 3333 @ mms-relay 02. siemens. De) of the replaced MM _{A can be} concluded Feedback possible if this is requested by the sender and supported by service provider B.

M-delivery. ind (network element RSA - »transmission application UAA):

X-Mms-Message-Type: m-delivery-ind

X-Mms Message ID: AAAA. 5555 @ mms-relay01. Siemens. de

X-Mms version: 1. 0

To: abc @ sal. si emens. de

Date; Thu, Oct 26, 2000 13:12:11 +0100

X-Mms status: replace successful

The network element RSA can use the WAP message M-Delivery. Send a feedback back to the UAA sending application. The ID of the change request is in the Message ID field. The extended header field X-Mms -Status is preferably used for the status of the change request, in which the successful change of the MM _A by MM _B with the field value "replace suc-" cessful "is confirmed. Since the sending application UAA knows the relationship between the message ID of the change request and the message ID of the MM _A that should be recalled, the sender can be informed whether his change request has been successfully executed or not (if the service providers involved support this).

Example 3: Alternative for the transmission of status information (without condition)

In the two exemplary embodiments described above, feedback about the output of a given recall or change order from the receiving application UAB to the network element RSB (for service provider B) with the WAP messages M-NotifyResp. ind (PUSH mode) or the M acknowledgment. ind (PULL mode), or from the network element RSA to the sending application UAA (with service provider A) with the WAP message M-Delivery. ind transferred. For this purpose, new field values were introduced in the header field X-Mms status. This procedure is efficient, but not entirely in line with the previous use of the X-Mms-Status header field. Therefore, an alternative embodiment for the transmission of a feedback is described below. Sending and executing a recall or change order expediently remains unchanged as described in Example 1 and Example 2.

With this alternative, the X-Mms-Status header field (as originally provided in the Encapsulation Standard (see above)) is still used exclusively to: to inform the sender about the status of the last sent MM (that is, the one that contained the recall or change order) and not (as described in exemplary embodiments 1 and 2) about the outcome of a recall or change order. In this case, another header field is therefore defined, with which the sender can be informed of the outcome of his recall or change orders. It is proposed to give this new header field the name X-Mms-Original-Message-Status and to give it the hexadecimal coding 0x86 (decimal: 134). It is also suggested, for example, as field values <Octetl28> for "The MM was successfully recalled", <Octetl29> for "The recall of the MM failed", <Octetl30> for "The MM was successfully changed or replaced" and

Use <Octetl31> for "Changing or replacing the MM failed". Fig. 7 shows the header field presented in this alternative.

Example 4: Alternative for sending feedback (unconditional)

In Examples 1 and 2, the MM _A , to which the confirmation relates, was based on the result of the recall or change order using the message ID of MM _B and the transaction IDs in the WAP messages M-NotifyResp. ind or M-Acknowledge. ind identified.

It is also conceivable that the message ID of the MM _A that has been recalled or changed, in particular replaced, is sent directly with the WAP messages M-NotifyResp. ind or M-Acknowledgment. ind (to service provider B), or M- Delivery. ind (from service provider A). For this purpose, it is proposed to introduce a new header field, which for example has the appropriate designation X-Mms-Original-Message-ID, and to give it the hexadecimal code 0x87 (decimal: 135). The field values of this new header field preferably contain the message ID of the original MM _A and are encoded according to the encapsulation standard (see above) as a text string. 8 shows the header field presented in this alternative.

C.2 With condition for callback or change

In the exemplary embodiments that follow, the header fields used in the WAP messages for the conditional recall and changing of a first message are discussed in detail. The following scenario is assumed as an example: An MMS VAS application A sends an MM _A to a recipient and wants to call it back later (example 5) or replace it with a new MM _B (example 6).

Within the WAP message M-Send. conf is assigned to the MM _A sent an unique identification number (AAAA.llll@mms-relay01.siemens.de). This message ID 1 ("Message ID 1") serves to identify the MM _A when recalling and replacing, according to the report of the 3GPP TSG-T2 SWG3 MMS.

Example 5: Conditional recall

The sender of an MM _A wants to call it back (two hours later). This is done with the help of a new one MM _B that is sent to the same recipient as the MM _A that is to be called back. At this point, M-Send is sent in the WAP. req advantageously uses the header field X-Mms -Recall -ID with the corresponding message ID of the MM _{A to be} recalled, see

Example 1. In addition, feedback about the issued callback request is requested here using the header field X -MmsRequest Report. The header field redefined in accordance with this invention with the designation X-Mms-Recall -Cond is used in the WAP message -Send.reg. The field value in this example is assumed to be <0c-tetl30>. This value corresponds to the sender's request that the callback only be carried out if the MM _{A has} not been read, regardless of whether a notification has been sent or whether the MM has already been downloaded.

M-Send. req (MMS VAS application A - »network element RSA):

X-Mms -Message -Type: m-send-req

X-Mms transaction ID: 16

X-Mms - Version: 1. 0

Date: Thu, 26 Oct 2000 14:12:19 +0100 From: abc @ vas. de

To: xyz @ siemens. de

X-Mms -Recall -ID: AAAA. Illl @ mms-relay01. Siemens. de

X-Mms request report: Yes

X-Mms -Recall -Cond: Only before reading Subject: recall of mul timedia message a Content-Type: text / piain

In this case, assume that the network element RSA determines that it has forwarded the MM to be deleted to another network element RSB. Here the reception of the WAP message M-Send. req with the recall command in MM _B from the network element RSA with a WAP message M-Send. conf acknowledged (see also Fig. 2). It contains the message ID assigned by the network element RS for the MM _B (here: AAAA. 2222 @ mms-relay01. Siemens. De). In addition, the header field X-Mms-Supported-Feature contains the entry “conditional recall feature supported”, which was newly defined in this invention.

M-Send. conf (network element RSA - MMS VAS application A):

X-Mms -Message -Type: m- send- conf X-Mms-Transaction-ID: 16 X-Mms - Versi on: 1. 0 X-Mms response status: ok Message ID: AAAA. 2222 @ mms-relay01. Siemens. de

X-Mms-Supported-Feature: condi tional recall

It is assumed here that the network element RSB determines that the receiving application UAB has been notified and has called up the MM. Since the callback condition can still be met (MM should not yet be open / read), an attempt is still made to fulfill the callback request. The receiving application UAB uses the WAP message M-Notification. ind informs that the previously downloaded MM _{A should be called} back if it has not been read. This condition is also communicated by means of the header field X-Mms-Recall - Cond with the field value <0ctetl30> (for calling back only before reading). The message MM _A is also identified here by means of the identification number. However, this identifier can differ from message ID 1 {AAAA due to the forwarding to another network element RS. llll @ mms- relay01. Siemens. de), according to WAP-209-MMSEncapsulation, Release 2000. In this exemplary embodiment, a different message ID was therefore chosen: BBBB. 3333 @ mms-relay02. Siemens. de.

The header field X-Mms-Content-Location in this example refers to a URI, under whose storage space a standard text message from service provider B (e.g .: "The sender wants the MM with the message ID BBBB. 3333 @ mms-relay02. Siemens. De. "). Receiving applications UAB that do not understand the new header fields of the callback feature can be subsequently informed about a callback order sent by the sender.

M notification. ind (network element RSB - receiving application UAB):

X-Mms -Message -Type: m-notification-ind X-Mms -Transaction-ID: 20

X-Mms - Version: 1. 0

From: abc @ vas. de

X-Mms Message Class: Personnel

X-Mms-Message-Size: 42 X-Mms-Expiry: 3600

X-Mms content location: http: // mms - relay02. Siemens. de / defaul t-recall -message

X-Mms -Recall -ID: BBBB. 3333 @ mms relay02. Siemens. de X-Mms -Recall -Cond: Only before reading

With the WAP message M-NotifyResp. the correct receipt of the WAP message becomes M-Notification. ind confirmed. If the MM _{A was} not read, it can be deleted as a result of the conditional recall command. Furthermore, the receiving application UAB reports on the outcome of the callback order. The X-Mms status header field serves this purpose. In this example, he carries one of the entries newly defined in this invention disclosure, namely <Octetl40> for "callback successful before MM was read".

M-NotifyResp. ind (receiving application UAB - network element RSB):

X-Mms -Message-Type: m-notifyresp- ind X-Mms -Transaction-ID: 20 X-Mms - Version: 1. 0

X-Mms status: Recall successful, before MM has been read

If the MM _A that is to be recalled has already been opened, no attempt will be made to delete it. Instead, the WAP message contains M-

NotifyResp. and information about the failure of the recall process, since the MM _A has already been opened. The header field X-Mms-Status then has the value <Octetl44> for "Callback failed because MM was read". The M-NotifyResp. And WAP message then looks like this:

M-NotifyResp. ind (receiving application UAB -> network ment RSB):

X-Mms -Message - Type: m-noti fyresp -ind X-Mms -Transaction-ID: 20 X-Mms - Versi on: 1. 0

X-Mms status: Recall failed, since MM has been read

If the sender wants a response for the callback order he initiated, the network element RSA can use the WAP message M-Delivery. Send a feedback back to the UAA sending application. In the "Message-ID" field there is the ID of the callback order (AAAA. 2222 @ mms-relay01. Siemens. De). The extended header field X-Mms-Status is also used here for the status of the callback that the successful deletion of the MM _{A is confirmed} with the field value "Callback successful before MM was read". Since the sending application UAA knows the relationship between the message ID of the recall request and the message ID of the MM _A that should be recalled, the sender can be informed whether his recall request could be successfully executed or not ( if the participating MMS service providers support this).

M-delivery. ind (network element RSA - »transmission application UAA):

X-Mms -Message- Type: m-delivery-ind X-Mms -Message-ID: AAAA. 2222 @ mms-relay01. Siemens. de X-Mms - Version: 1. 0 To: abc @ vas. de Date: Thu, Oct 26, 2000 2:14:09 pm +0100 X-Mms status: recall successful

Example 6: Conditional change or replace

In this example, the sender wants to update his MM _A (one hour after sending): Of the originally sent two elements, only the JPEG image (MIME content type "image / jpeg") should remain. In addition, the subject changed to "Agenda for our meeting", see Example 2. At this point the message is M-send in the WAP. req advantageously uses the header field X-Mms -Replace -ID with the corresponding message ID of the MM _A to be replaced. In addition, feedback about the change request is requested here using the X-Mms-eguest-.Report header field. The header field newly defined in this invention message with the exemplary designation X-Mms-Replace-Cond comes in the WAP message M-Send. req. The field value in this example is assumed to be <Oct2828>. This value corresponds to the sender's request that the callback only be carried out if the recipient of the MM _A has not yet been notified of this message.

M-Send. req (MMS VAS application A → network element RSA):

X-Mms message type: m-send-req X-Mms transaction ID: 32 X-Mms version: 1. 0

Date: Thu, 26 Oct 2000 14:12:19 +0100 From: abc @ vas. de To: xyz @ si emens. de

X-Mms -Recall -ID: AAAA. Illl @ mms-relay01. Siemens. de

X-Mms request report: Yes

X-Mms -Recall -Cond: Only before notification Subject: Agenda for our meeting

Content-Type: mul tipart / related; boundary = "■ _ = _ NextPart_023_"

= NextPart 023

Two further cases are considered:

Case 1: Receiving application UAB downloaded MM _A based on a notification.

Case 2: The MM _A is still on the network element RSA and no notification was sent to the receiving application UAB.

Case 1:

Since the notification has already been sent, the condition for executing the change command is no longer met. As a result, the replacement can and should no longer take place. Here the reception of the WAP message M-Send. reg with the change command from the MMS Relay / Server with a WAP message M-Send. conf acknowledged. It contains the message ID assigned by the MMS Relay / Server for the MM _B (here: AAAA. 2222 ^@ mms-relay01. Siemens. De). FER The header field XMs-Supported-Feature now contains the entry "conditional change feature supported", which is newly defined in this invention. Since the change request cannot be carried out, the customer is informed by means of the header field X-Mms - Response status informs about the outcome of his order: The field value <0c- tetl52> reports that the conditional replacement could not take place because the notification has already been sent: "Change failed because notification was sent".

M-Send. conf (network element RSA → MMS VAS application A):

X-Mms message type: m-send-conf X-Mms transaction ID: 32 X-Mms version: 1. 0 X-Mms -Response -Status: ok Message-ID: AAAA. 2222 @ mms -relayOl. Siemens. de

X- -Mms- -Supported-Feature: condi tional replace

X- -Mms- -Status: replace failed, since. notification was sent

If the network element RSA does not support conditional replacement, it will treat the MM _B as a normal multimedia message and consequently, as usual, forward it to the recipient, regardless of the MM _A to be replaced.

Case 2:

Since the notification has not yet been sent, the condition for executing the change command is fulfilled Consequently, the replacement can be done as desired. The MM _A can be deleted on the network element RSA, and the sender is informed about this process by means of the header field X-Mms -Response - Status. The field value <Octet52> reports that the conditional replacement took place before the notification was sent: "Change successful, before notification".

M-Send. conf (network element RSA - »MMS VAS application A):

X-Mms -Message -Type: m- send- conf X-Mms -Transaction-ID: 32 X-Mms - Version: 1. 0 X-Mms response status: ok

Message ID: AAAA. 2222 @ mms-relay01. Siemens. de

X-Mms-Supported-Feature: condi tional replace X-Mms-Status: replace successful, before notifi cation

The new message MM _B then reaches the reception application UAB as a normal multimedia message, which is announced by a separate notification. The recipient is thus informed that the sender has replaced the previously sent MM _A with a new MM _B.

In addition to the described methods, part of the invention also includes the corresponding devices, in particular telecommunications terminals and in this case in particular mobile radio devices, and the corresponding network elements. The corresponding software programs are also encompassed by the present invention.

Table 1: Possibilities of field-value coding according to WAP-203-WSP, version 4-May-2000; Wireless application protocol, wireless session protocol specification; Chapter 8.4: "Header Encoding".

Table 2: Additional insertions in the WAP message M-Send.req.

Table 3: Additional insertions in the WAP message M-Send. conf.

Table 4: Additional insertions in the WAP message M-Notification. ind.

Table 5: Additional insertions in the WAP message M-NotifyResp. reg.

Table 6: Additional insertions in the WAP message M-Retrieve. conf.

Table 7: Additional insertions in the WAP message M-Acknowledgment. ind.

Table 8: Additional insertions in the WAP message M-Delivery. ind.

LIST OF REFERENCE NUMBERS

1 sending application (MMS User Agent A = UAA)

2 Network element on the transmitter side (MMS Relay / Server A = RSA)

3 MMS memory A (MMS server A)

4 MMS environment (= MMSE; an MMS service provider A)

6 Public mobile network (PLMN) 7 VAS application (VAS = Value Added Service)

11 Receive application (MMS User Agent B = UAB)

12 Receiver-side network element (MMS Relay / Server B RSB)

13 MMS memory B (MMS server B) 14 MMSE environment (= MMSE; an MMS service provider B)

20 IP - Internet Protocol

21 Legacy messaging system

22 Simple Mail Transfer Protocol (SMTP)

Claims

1. Method for accessing a first message (MM _A ), in particular a multimedia message (MM), preferably of the MMS type, the first message (MM _A ) using a transmission application (1) or a network-side VAS application (7) is sent to a receiving application (11), characterized in that a second message (MM _B ) with a manipulation order for manipulating the first message (MM _A ) is created, sent, received, forwarded and / or processed in order to have a manipulating access to to initiate or convey the first message (MM _A ).

2. The method according to claim 1, characterized in that the first message (MM _A ) and the second message (MM _B ) via radio, via mobile radio systems, between mobile radio systems, in particular inter-operator IP backbone, between mobile radio networks and other messages. Networks, in particular Internet e-mail, and / or sent over the Internet.

3. The method according to claim 1 or claim 2, characterized in that the first message (MM _A ) and the second message (MM _B ) via at least one transmitter-side network element (2) of a service provider (service provider A) and at least one receiver-side network element (12) of a service provider (service provider B) is sent to the receiving application (11).

4. The method according to claim 3, characterized in that the at least one transmitter-side network element (2) and the at least one receiver-side network element (12) to the area of responsibility (4) belong to a single service provider (service provider A) or are identical.

5. The method according to any one of the preceding claims, characterized in that the transmission application (1) and the

Receive application (11) are identical.

6. The method according to any one of the preceding claims, characterized in that the manipulating access to the first message (MM _A ) on a transmitter-side network element (2), on a receiver-side network element (12) and / or on the receiving application (11).

7. The method according to any one of the preceding claims, characterized in that the manipulation order comprises the recall or deletion of the first message (MM _A ).

8. The method according to any one of claims 1 to 6, characterized in that the manipulation order comprises changing the first message (MM _A ), in particular by replacing the first message (MM _A ) with the second message (MM _B ).

9. The method according to claim 8, characterized in that when the change request is not supported by at least one of the MMS environments (4, 14) involved in the service provider, the second message (MM _B ) as a normal message of the receiving application ( 11) is delivered, the sender preferably being informed of this.

10. The method according to claim 8 or 9, characterized in that the second message (MM _B ) in the case of a change order either in the PUSH mode (push / bring mode) or in the PULL mode (pull / pull mode) is downloaded.

11. The method according to any one of the preceding claims, characterized in that the second message (MM _B ) is sent with the manipulation order to the recipient of the first message (MM _A ), preferably for identifying or identifying the first message (MM _A ) whose identification number (IDl) is used, which uniquely identifies the first message (MM _A ) between the sending application (1) or the VAS application (7) and a transmitter-side network element (2).

12. The method according to any one of the preceding claims, characterized in that when a message is sent to a transmitter-side network element (2) from the sending application (1) or the VAS application (7) one or more of the following information is provided:

- Marking that the message (MM _B ) is a manipulation order;

- Identification number of the first message (MM _A ) to be manipulated;

- Information that the sender requests feedback about the outcome of the manipulation he initiated.

13. The method according to any one of the preceding claims, characterized in that the transmission application (1) or

VAS application (7) from a transmitter-side network element (2) the information is provided whether this network element (2) supports the manipulation according to the preceding claims and / or whether the manipulation order from the service provider (service provider A) of the transmission application (1 ) or the VAS application (7) was accepted.

14. The method according to any one of the preceding claims, characterized in that if the sending application (1) or the VAS application (7) and the receiving application (11) belong to different MMS environments (MMSE _A , MMSE _B ) from one service provider one or more of the following information is provided by a network element (1) on the receiver side of the network element (11):

- Marking that the second message (MM _B ) is a manipulation order;

- Identification number of the first message (MM _A ) to be manipulated;

15. The method according to any one of the preceding claims, characterized in that network elements (2, 12) from different service providers (service provider A, service provider B) a unique, reversible conversion of identification numbers related to the first and / or the second message (IDl , ID3; ID4, ID6, ID5) and preferably manage the corresponding information.

16. The method according to any one of the preceding claims, characterized in that in the case of a manipulation order, in particular including a deletion command, if the receiving application (11) has not yet been notified of the first message (MM _A ), this first message (MM _A ) manipulated, in particular deleted, in the MMS environment (MMSE _A ) of the transmitter-side service provider (service provider A) or in the area of responsibility (MMSE _B ) of the receiver-side service provider (service provider B), whereby preferably the receiving application (11) is not informed of the manipulation.

17. The method according to any one of claims 1 to 15, character- ized in that in the case of a manipulation order when the notification has been made on the receiving side but has not yet downloaded the first message (MM _A ), this first message (MM _A ) in the MMS environment (MMSE _B ) of the receiving-side service provider (service provider B) is manipulated, the receiving application (11) preferably being informed of the manipulation and its time.

18. The method according to any one of claims 1 to 15, characterized in that in the case of a manipulation order when notification is made on the receiving side but not yet downloaded the first message (MM _A ), this first message (MM _A ) in the MMS environment (MMSE _A ) of the sender-side service provider (service provider A) is manipulated, the receiving application (11) preferably not being informed of the manipulation.

19. The method according to any one of the preceding claims, characterized in that the receiving application (11) from a receiver-side network element (12) one or possibly more of the following information, preferably in a notification, are provided:

- Information that a merely announced but not yet delivered first message (MM _A ) is no longer available for download, or has been changed by a new message (MM _B ), the identification of the first and / or the second message (MM _A , MM _B ) preferably using the URI (Uniform Resource Identifier = storage space); - Information that a first message (MM _A ) that has already been delivered is to be manipulated by the sender, the first message (MM _A ) being identified on the receiving application (11) preferably using a message reference, which is preferably a URI, under whose memory space is a standard text message from the recipient service provider (service provider B), the URI preferably being derived from the identification number (ID1) of the first message (MM _A ) or from a recipient network element (12) specified second identification number (ID2 ) is composed;

- Notification of the manipulation of the first message (MM _A ) on the part of a service provider (service provider A or B);

- notification of the manipulation and, if the recipient so requests, that the manipulated message is not available;

- Identification that the second message (MM _B ) contains a manipulation order that is to be executed on the receiving application (11); - Information about which message (MM _A ) that has already been delivered is to be manipulated;

- Information when the manipulation was carried out; ^'

- Information that the delivered second message (MM _B ) is a subsequently changed message; - Information on the type of manipulation to be carried out.

20. The method according to any one of the preceding claims, characterized in that at least one of the following information is provided to a receiver-side network element (12) by the receiving application (11) after it has been notified of the second message (MM _B ): - Information whether the receiving application (11) has understood that the previously announced first message

(MM _A ) was successfully manipulated;

- Information whether the manipulation of the already downloaded first message (MM _A ) could be carried out successfully;

- Information as to whether the recipient has been informed and / or has agreed that the message already downloaded (MM _A ) has been manipulated; - if unsuccessful, the reason for the unsuccessful execution;

- Information as to whether, in the case of a change order, the change to the already downloaded first message (MM _A ) was carried out automatically (PUSH mode) or at the instigation of the recipient (PULL mode);

- Information on the type of manipulation to be carried out.

21. The method according to any one of the preceding claims, characterized in that if the sending application (1) or the VAS application (7) and the receiving application (11) belong to different MMS environments (MMSE _A , MMSE _B ) from Service providers (service provider A, service provider B) are provided with one or more of the following information for a transmitter-side network element (2) by a receiver-side network element (12):

- Information as to whether the manipulation order was successfully executed;

- if unsuccessful, the reason for the unsuccessful execution;

- Information when the manipulation order was executed; - Information as to whether the manipulation order was executed automatically;

- Information as to whether the recipient has been informed about the manipulation and / or has consented to the manipulation and / or the manipulation was initiated by the recipient;

- Information that the already downloaded first message (MM _A ) has been manipulated or that the first message (MM _A ) had not been downloaded before a change;

- Interim identification number (ID3) of the message (MM _A ) that has been manipulated;

- Information on the type of manipulation carried out.

22. The method according to any one of the preceding claims, characterized in that the transmission application (1) or the VAS application (7) from one transmitter-side network element (2) one or more of the following information is provided:

- Information as to whether the manipulation order was successfully executed; - if unsuccessful, the reason for the unsuccessful execution;

- Information that manipulation could not be carried out due to forwarding the first message (MM _A ) to an unknown address; - Information when the manipulation order was executed;

- Information as to whether the manipulation order was carried out automatically;

- Information as to whether the recipient has been informed about the manipulation and / or has consented to the manipulation and / or the recipient has initiated it; - Information that the already downloaded message (MM _A ) has been manipulated or that the first message (MM _A ) had not yet been delivered before a change;

- Identification number (IDl) of the message (MM _A ) that was manipulated.

23. The method according to any one of the preceding claims, characterized in that the second message (MM _B ) comprises at least one information element associated with the sending application (1) or the VAS application (7), which information element has at least one condition for executing the manipulating access contains.

24. The method according to claim 23, characterized in that the at least one information element is the manipulative

Access indicates according to the processing status of the first message (MM _A ).

25. The method according to claim 23 or 24, characterized in that at least one of the following conditions of the

Sending application (1) or the VAS application (7) is determined by means of the at least one information element:

- manipulation of the first message (MM _A ) only if the first message (MM _A ) is still on the server and the recipient has not yet been notified of this message (MM _A );

- manipulation of the first message even if the notification was sent but the first message (MM _A ) has not yet been downloaded;

- manipulation of the first message (MM _A ) if the recipient has not yet opened or read it;

- Manipulation of the first message (MM _A ) regardless of the degree of processing.

26. The method according to any one of claims 23 to 25, characterized in that the information element is assigned a default value, which stands for a manipulation corresponding to the default value in a condition not specified.

27. The method according to any one of claims 23 to 26, characterized in that at least one of the service providers involved in the transmission of the first and the second message (MM _A , MM _B ) (service provider A and / or service provider B) does the manipulation job on its own or limited to certain domains of other service providers, preferably by identifying the recipient (phone number, email address, ...) or by using an additional identifier.

28. The method according to any one of claims 23 to 27, characterized in that the manipulation order containing the second message (MM _B ) by the sending application (1) or the VAS application (7) to a transmitter-side network element ( 2) is sent, one of the following conditions is associated with the manipulation of the first message (MM _A ):

- manipulation only before notifying the recipient;

- manipulation only before downloading, even after sending a notification;

- Manipulation only if the first message (MM _A ) has not yet been opened or read;

- Manipulation regardless of the processing status of the first message (MM _A ).

29. The method according to any one of claims 23 to 28, characterized in that the transmission application (1) or the VAS application (7) from a transmitter-side network element (2) upon confirmation after the sending of the first or second message (MM _A , MM _B ), it is communicated whether this network element (2) supports said conditional manipulation and / or whether the conditional manipulation order from the sender service provider (service provider A ) was accepted.

30. The method according to any one of claims 23 to 29, characterized in that when the sending application (1) or the VAS application (7) and the receiving application (11) belong to different MMS environments (MMSE _A , MMSE _B ) from Service providers (service provider A, service provider B) transmit one or more of the following conditions regarding the manipulation of the first message (MM _A ) by the second message (MM _B ) to a receiver-side network element (12) from a transmitter-side network element (2):

- manipulation only before notifying the recipient;

- manipulation only before downloading, even after sending a notification; - manipulation only if the first message (MM _A ) has not yet been opened or read;

31. The method according to any one of claims 23 to 30, characterized in that the receiving application (11) from a receiver-side network element (12) one or more of the following conditions with regard to the manipulation of the first message (MM _A ) by the second message (MM _B ) to be sent, preferably when notifying about the second message (MM _B ):

- manipulation only before notifying the recipient;

- Manipulation only before downloading, even after the download sent a notification;

32. The method according to any one of the preceding claims, characterized in that the sending, receiving and manipulation of the messages (MM), including the conditional manipulation, takes place by means of WAP messages (Wireless Application Protocol).

33. The method according to any one of the preceding claims, characterized in that the manipulation orders by modifying existing header fields {X-Mms status; M-Mms-Supported-Feature) and / or by adding additional header fields {X-Mms -Recall - ID; X-Mms Recalled URI; X-Mms-Replace-ID; X-Mms-Replaced- URI; X-Mms Supported Feature; X-Mms-Date-Of-Execution; X-Mms request report; X-Mms -Original - message status; X-Mms Original Message ID; X-Mms Recall -Cond; X-Mms -Replace-Cond; X-Mms Recall Status; X-Mms -Replace- status; X-Mms operation status) in suitable WAP messages, in particular those according to the WAP-MMS encapsulation standard and in particular in at least one of the WAP messages M-Send. req, M-Send. conf, M-

Notification. ind, M-NotifyResp. req, M-Retrieve. conf, M acknowledge. ind, M-Delivery. ind can be implemented.

34. Method according to one of the preceding claims, characterized in that the first message (MM _A ) for one

Feedback on the result of the manipulation order based on the identification number (ID4) of the second message (MM _B ) and the transaction identification numbers of the speaking WAP messages, or is identified using an additional header field, field values of the new header field containing the identification number (IDl) of the first message (MM _A ).

35. Telecommunication device, in particular for at least partially performing the method according to one of the preceding claims, with means for creating, sending, receiving and / or processing a first message (MM _A ), in particular a multimedia message, preferably of the MMS type, characterized by means for creating, sending, receiving and / or processing a second message (MM _B ), the second message (MM _B ) comprising an unconditional or conditional manipulation order for manipulating the previously sent first message (MM _A ).

36. Telecommunications device according to claim 35, characterized by a transmission application (1) or a VAS application (7) and a transmission unit connected or connectable to these applications (1, 7).

37. Telecommunication device according to claim 35 or 36, characterized by a receiving application (11) and a receiving unit connected or connectable to the receiving application (11).

38. Telecommunication device according to one of claims 35 to 37, characterized by a processor unit for evaluating notifications from a transmitter-side network element (2) with regard to the support of unconditional and / or conditional manipulation orders, the successful or unsuccessful execution of the manipulation order. lazy and / or the reasons for unsuccessful execution of the manipulation order.

39. Telecommunication device according to one of claims 35 to 38, characterized by a processor unit for evaluating notifications from a receiver-side network element (12) about information regarding the execution of the unconditional or conditional manipulation order.

40. Telecommunication device according to claim 39, characterized by a transmission unit for sending notifications to a receiver-side network element (12) regarding the successful or unsuccessful execution of the manipulation order and / or the reasons for an unsuccessful execution of the manipulation order.

41. Telecommunication device according to one of claims 35 to 40, characterized in that it is designed as a mobile phone with a transmitting and a receiving unit.

42. Telecommunication device according to one of claims 35 to 40, characterized in that it is designed as a network element on which a VAS application (7) is located.

43. Telecommunication device according to one of the claims

35 to 42, characterized in that the means are designed such that they process WAP messages, in particular those according to the WAP-MMS encapsulation standard and in particular the WAP messages M-Send. req, M-Send. conf, M notification. ind, M-NotifyResp. req, M-Retrieve. conf, M acknowledge. ind, M-Delivery. ind, with according to the allow the information to be exchanged for manipulation orders modified header fields and / or additional header fields.

44. Telecommunication device according to one of claims 35 to 43, characterized by means for generating an information element and means for assigning this information element by the sending application (1) or the VAS application (7) to the second message (MM _B ), the information Mation element contains at least one condition for the execution of the manipulative access.

45. Telecommunication device according to claim 44, characterized by means for executing the manipulation order.

46. Network element (2; 12), in particular a radio communication system and in particular for carrying out the method steps according to one of claims 1 to 34 on the network side, with means for receiving and forwarding a first message sent by telecommunications devices according to one of claims 35 to 45 (MM _A ), in particular a multimedia message, preferably of the MMS type, characterized by means for receiving, processing and / or forwarding a second message (MM _B ) with a manipulation order, which relates to the received and possibly already forwarded first message (MM _A ) relates to manipulating access to the first message (MM _A ) or to mediate.

47. Network element according to claim 46, characterized by means for receiving and forwarding and / or generating and sending messages to another network element (12; 2) and / or a receiving application (1; 11) on the transmitter side and / or on the receiver side, these messages being the conditions specified by the sender for the execution of a manipulation order specified in the second message (MM _B ), the successful or unsuccessful execution of the conditional manipulation order and / or the reasons for unsuccessful execution of the conditional manipulation order.

48. Network element according to claim 46 or 47, characterized by means for executing the manipulation order.

49. Network element according to claim 48, characterized in that the first message (MM _A ) on a network element (2; 12) and / or on a receiving application (11) of a receiving unit can be manipulated, in particular can be deleted and / or changed.

50. Network element according to one of claims 46 to 49, characterized in that the means for receiving, processing and / or forwarding the second message (MM _B ) of WAP messages, in particular those according to the WAP-MMS encapsulation standard and in particular the WAP messages M-Send. req, M-Send. conf, M notification. ind, M-NotifyResp. req, M-Retrieve. conf, M acknowledge. ind and M-Delivery. and use header fields and / or additional header fields modified in accordance with the information to be exchanged as part of the manipulation orders.

51. Software program, which on a device with a processor, in particular a telecommunications device and in particular such according to one of the claims 35 to 45, or a network element, in particular one according to one of claims 46 to 50, can run in such a way that the software program together with the device executes or initiates the method steps on the side of the device according to one of claims 1 to 34.

52. Software program which can be loaded into a device with a processor, in particular a telecommunication device and in particular one according to one of claims 35 to 45 or a network element and in particular one according to one of claims 46 to 50, so that the device programmed in this way including the processor is capable or adapted to perform or cause the method steps according to any one of claims 1 to 34.