EP1356645A2 - Verfahren und vorrichtung zur manipulation übertragener nachrichten - Google Patents

Verfahren und vorrichtung zur manipulation übertragener nachrichten

Info

Publication number
EP1356645A2
EP1356645A2 EP02702291A EP02702291A EP1356645A2 EP 1356645 A2 EP1356645 A2 EP 1356645A2 EP 02702291 A EP02702291 A EP 02702291A EP 02702291 A EP02702291 A EP 02702291A EP 1356645 A2 EP1356645 A2 EP 1356645A2
Authority
EP
European Patent Office
Prior art keywords
message
mms
manipulation
network element
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02702291A
Other languages
English (en)
French (fr)
Inventor
Markus Trauberg
Andreas Schmidt
Josef Laumen
Belhassen Jerbi
Sabine Van Niekerk
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Priority to EP02702291A priority Critical patent/EP1356645A2/de
Publication of EP1356645A2 publication Critical patent/EP1356645A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/18—Commands or executable codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/23—Reliability checks, e.g. acknowledgments or fault reporting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/234—Monitoring or handling of messages for tracking messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58—Message adaptation for wireless communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements

Definitions

  • 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.
  • the invention relates to corresponding telecommunication devices, network elements and software programs.
  • GSM Global System for Mobile Communications
  • SMS Short Message Service
  • MMS Multimedia Messaging Service
  • MMS Multimedia Messaging Service
  • MMS Multimedia Messaging Service
  • PUSH mode push / bring mode
  • PULL mode pulse / pull Mode
  • MMS can only be implemented using WAP (WAP - Wireless Application Protocol).
  • WAP WAP - Wireless Application Protocol
  • 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.
  • MMS Multimedia Messaging Service
  • 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.
  • 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.
  • the receiving application UAB 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 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.
  • 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.
  • 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.
  • 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.
  • MMS service provider A MMS service provider B
  • MMS service provider B MMS service provider B
  • 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.
  • SMTP Simple Mail Transfer Protocol
  • IP Internet Protocol with reference number 20
  • PLMN Public Land Mobile Network
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • MM ie sending application
  • MMS VAS MMS voice over IP
  • 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.
  • conditional recall (“Conditional Recall” or “Conditional Cancel") or “Conditional Replace” called.
  • 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.
  • 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.
  • WAP-209-MMS Encapsulation Release 2000
  • Wireless application protocol Wireless application protocol
  • WAP multimedia messaging service Message encapsulation
  • MMS Proposed SCD 1.0 MMS Proposed SCD 1.0.
  • the corresponding binary coding as described below for exemplary embodiments, is the subject of the present invention.
  • MMS multimedia message service
  • FIG. 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
  • Fig. 7 newly introduced header field X-Mms original message status; 8 newly introduced header field X-Mms-Original - Message-ID;
  • the following, known sequence of sending and receiving a first message MM A by switching a first and a second MMS service provider 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.
  • 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.
  • 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).
  • ID3 should be globally unique.
  • ID3 contains information regarding the service provider A, the ID1 and the time of the ID conversion.
  • the transmitter-side network element RSA 2 must have the information or the possibility to undo this conversion, for example for delivery reports.
  • 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.
  • 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.
  • ID4 can be converted by the transmitter-side network element RSA 2 into an interim ID (ID6), which identifies MM B between the systems.
  • 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.
  • 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.
  • ID5 an internal ID
  • 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.
  • identification numbers ID1 and ID3, ID3 and ID2, and ID1, ID2 and ID3 are identical.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • MMSE A the area of responsibility of the service provider A
  • MMSE B 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.
  • the deletion of MM A and MM B can be initiated by the responsible network element RS.
  • 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.
  • 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.
  • the deletion of the MM A can take place directly in the reception application UAB, provided that this supports the callback service feature.
  • 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.
  • 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).
  • MM A can also be deleted on the RSA network element.
  • 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.
  • 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):
  • Network element RSA MMS Relay / Server A
  • Send application UAA MMS User Agent A
  • Network element RSA MMS Relay / Server A
  • RSB MMS Relay / Server B
  • 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
  • UAB MMS User Agent B
  • Network element RSB MMS Relay / Server B
  • Network element RSA MMS Relay / Server A
  • 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).
  • 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.
  • 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.
  • a second message 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.
  • 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.
  • 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.
  • 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:
  • a standard condition "default value" is advantageously assumed.
  • 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.
  • 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).
  • MMSE A Multimedia Messaging Service Environment A
  • 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.
  • 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.
  • the recall can only take place in the cases numbered above with 2, 3 and 4.
  • 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.
  • 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.
  • 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
  • the sender preferably receives a feedback with the information that the MM could not be called back because a notification has already been sent
  • 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.
  • Network element RSA MMS Relay / Server A
  • UAA MMS User Agent A
  • Network element RSA MMS Relay / Server A
  • network element RSB MMS Relay / Server B
  • Network element RSB MMS Relay / Server B
  • UAB MMS User Agent B
  • Receiving application UAB (MMS User Agent B) - network element RSB (MMS Relay / Server B) (after notification):
  • Network element RSB MMS Relay / Server B
  • Network element RSA MMS Relay / Server A
  • 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).
  • 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.
  • the sender of an MM with a recall order can preferably be given the opportunity to request a response.
  • 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”.
  • 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 ").
  • appropriate field values should preferably be added.
  • a callback command without a header field X-Mms -Recall -Cond stands for "Recall even after Reading”.
  • the sending application UAA can additionally be informed whether the service provider A has accepted the sender's callback request (MMS User Agent A).
  • MMS User Agent A the sender's callback request
  • 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).
  • the transmission application UAA can additionally be informed according to the invention whether the service provider A supports the conditional callbacks.
  • 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)
  • 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.
  • 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.
  • 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).
  • 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.
  • 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).
  • 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.
  • ⁇ 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.
  • M-NotifyResp. reg from receiving application UAB to network element RSB
  • 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.
  • 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".
  • 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.
  • the i ⁇ v encapsulation standard see above
  • X-Mms status 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.
  • 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” ,
  • the header field X-Mms-Status expanded in section A.4 should also be inserted here.
  • the sender sending application UAA
  • the sender 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).
  • 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.
  • other new field values are preferably defined:
  • 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:
  • 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.
  • 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.
  • 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
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • the settings of the user, the settings of the service provider and / or the network operator, changing, in particular replacing, MM A 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.
  • 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.
  • sending application UAA, network element RSA, network element RSB and receiving application UAB is additionally exchanged between the entities involved (sending application UAA, network element RSA, network element RSB and receiving application UAB) :
  • Network element RSA MMS Relay / Server A
  • Send application UAA MMS User Agent A
  • Network element RSA MMS Relay / Server A
  • Network element RSB MMS Relay / Server B
  • 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
  • UAB MMS User Agent 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).
  • URI message reference
  • 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.
  • 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.
  • 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
  • UAB MMS User Agent B
  • MM A is identified using the individual message identification number (Message ID). or:
  • Receiving application UAB (MMS User Agent B) ⁇ network element RSB (MMS Relay / Server B) (after delivery of an MM):
  • 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):
  • 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”.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • the change according to the invention can only be made in the above with 2, 3 and 4 numbered cases.
  • 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.
  • 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.
  • 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
  • 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.
  • MMSEs multimedia messaging service environments
  • 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.
  • Network element RSA MMS Relay / Server A
  • UAA MMS User Agent A
  • Network element RSA MMS Relay / Server A
  • RSB MMS Relay / Server B
  • Network element RSB MMS Relay / Server B
  • RSA MMS Relay / Server A
  • MMS user agent or MMS proxy / server is again spoken of, which also means MMS client or MMS proxy / relay.
  • 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.
  • 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.
  • the sender of an MM with a change order is preferably given the option of requesting confirmation.
  • 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”.
  • 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.
  • appropriate field values should preferably be added.
  • 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.
  • the new field value ⁇ Octetl48> for "Change successful before notification" is preferably defined.
  • a newly defined header field with the appropriate designation X-Mms-Replaced-URI and the hexadecimal coding 0x82 (decimal: 130) is added.
  • 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.
  • the one defined in section A.3 is redefined in accordance with an advantageous variant of the invention
  • 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.
  • the WAP message informs M-Notification.
  • the receiving application UAB should replace the arrival of the message MM B , which change MM A.
  • 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.
  • 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”.
  • 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.
  • 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.
  • 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).
  • 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:
  • X-Mms-Replace-Status 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:
  • 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.
  • 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.
  • 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).
  • X-Mms-Message-Type m-send-req
  • X-Mms-Transaction-ID 10
  • X-Mms- Version 1.0
  • 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
  • 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:
  • 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.
  • 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.
  • X-Mms -Request -Report with which a response can be requested about the recall request placed.
  • 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.
  • X-M s message type m-send-req X-Mms transaction ID: 16 X-Mms version: 1. 0
  • 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.
  • 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 ).
  • the recipient does not even have to be informed.
  • 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.
  • the WAP message M-Notification can be used:
  • 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.
  • 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.
  • 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.
  • X-Mms-Recall -ID BBBB.3333@mms- relay02. Siemens.
  • 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.
  • the value BBBB. 3333 @ mms-relay02. Siemens. De was selected in this exemplary embodiment (corresponds to ID2 of MM A in FIG. 2 ).
  • X-Mms message type m-notifyresp-req
  • X-Mms transaction ID 25
  • X-Mms version 1.
  • the reception application UAB sends the MAP NotifyResp with the WAP. req a feedback back to the network element RSB.
  • the header field X-Mms status from the encapsulation standard (see above), which has been expanded in this invention, is advantageously used.
  • the MM A on the receiving application UAB could be deleted, which is expressed by the field value “recall successful”.
  • 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.
  • 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)
  • 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 ".
  • a new MM B is sent to the same recipient as the previously sent MM A that is to be changed or replaced.
  • the header field with the expedient designation X-Mms-Replace-ID is advantageously used, in which the "Message-ID" of the MM A is entered.
  • 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).
  • X-Mms message - Type m-send-req X-Mms transaction ID: 32 X-Mms version: 1. 0
  • 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.
  • the two WAP messages have the transaction identity number IDD32.
  • 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.
  • 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.
  • this notification should preferably by means of the WAP message M-Notification.
  • 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.
  • 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.
  • X-Mms message type m-notifyresp-req
  • X-Mms transaction ID 35
  • X-Mms version 1.
  • 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
  • de X-Mms-Message-Class Personal X-Mms-Message-Size: 45
  • X-Mms-Expiry 3600
  • 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.
  • M-Retrieve is displayed in the WAP message.
  • 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).
  • 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.
  • 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”.
  • the transaction ID ⁇ Transaction-ID) here : 48
  • 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.
  • the receiving application UAB confirms the correct receipt of MM B, preferably with the WAP message M-NotifyResp. req.
  • the X-Mms-Status header field expanded in this invention is preferably used.
  • 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”.
  • 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.
  • 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).
  • 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.
  • 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).
  • FIG. 7 shows the header field presented in this alternative.
  • 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.
  • 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).
  • M-NotifyResp. ind or M-Acknowledgment. ind to service provider B
  • M- Delivery. ind from service provider A.
  • 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.
  • conf is assigned to the MM A sent an unique identification number (AAAA.llll@mms-relay01.siemens.de).
  • This message ID 1 serves to identify the MM A when recalling and replacing, according to the report of the 3GPP TSG-T2 SWG3 MMS.
  • 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.
  • the network element RSA determines that it has forwarded the MM to be deleted to another network element RSB.
  • 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).
  • the header field X-Mms-Supported-Feature contains the entry “conditional recall feature supported”, which was newly defined in this invention.
  • 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
  • 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.
  • 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".
  • X-Mms -Message-Type m-notifyresp- ind
  • X-Mms -Transaction-ID 20
  • X-Mms - Version 1. 0
  • the WAP message contains M-
  • the header field X-Mms-Status then has the value ⁇ Octetl44> for "Callback failed because MM was read”.
  • the M-NotifyResp. And WAP message looks like this:
  • the network element RSA can use the WAP message M-Delivery. Send a feedback back to the UAA sending application.
  • 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).
  • 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
  • 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.
  • X-Mms message type m-send-req X-Mms transaction ID: 32 X-Mms version: 1. 0
  • Case 1 Receiving application UAB downloaded MM A based on a notification.
  • 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
  • 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.
  • 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”.
  • X-Mms -Message -Type m- send- conf X-Mms -Transaction-ID: 32 X-Mms - Version: 1. 0 X-Mms response status: ok
  • 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.
  • 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 3 Additional insertions in the WAP message M-Send. conf.
  • Table 8 Additional insertions in the WAP message M-Delivery. ind.
  • Receiver-side network element (MMS Relay / Server B RSB)

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Es wird ein Verfahren vorgestellt, das es ermöglicht, eine vorzugsweise über ein Mobilfunksystem und/oder das Internet versendete erste Nachricht, insbesondere eine multimediale Nachricht, vorzugsweise vom MMS-Typ, mittels einer zeitlich nach der ersten Nachricht versendeten zweiten Nachricht zu manipulieren, beispielsweise zurückzurufen oder zu ändern. Hierdurch wird die Bedienerfreundlichkeit für die Nutzer solcher Systeme erhöht. Ausserdem wird die Möglichkeit der bedingten Manipulation einer solchen ersten Nachricht vorgestellt. Des weiteren werden entsprechende Telekommunikationseinrichtungen, Netzwerkelemente sowie Softwareprogramme vorgeschlagen.

Description

Be s ehr e ibung
Verfahren zum Zugreifen auf Nachrichten, entsprechende Vorrichtungen sowie Softwareprogramme
Die Erfindung betrifft ein Verfahren zum Zugreifen auf eine erste Nachricht, insbesondere eine multimediale Nachricht vorzugsweise vom MMS-Typ, wobei die erste Nachricht mittels einer Sendeapplikation oder einer VAS- Applikation an eine Empfangsapplikation gesendet wird.
Des weiteren betrifft die Erfindung entsprechende Telekommunikationseinrichtungen, Netzwerkelemente sowie Softwareprogramme .
Das Mobilfunksystem GSM (GSM - Global System for Mobile Communications) bietet neben der Sprachtelefonie auch die Möglichkeit, kurze Textnachrichten von bis zu 160 Zeichen Länge zu versenden bzw. zu empfangen. Dieser Dienst heißt SMS (SMS - Short Message Service), s. GSM 03.40 Version 7.4.0, Release 1998; Digital Cellular Telecommunications System,- Technical Realisation of the Short Message Service (SMS) .
Für das Mobilfunksystem der nächsten Generation UMTS
(UMTS - Universal Mobile Telecommunication System) wird zur Zeit eine multimediafähige Variante eines mobilen Nachrichtendienstes standardisiert, der sogenannte MMS (MMS - Multimedia Messaging Service), s. 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) . Nachrichten mit multimedialen Inhal- ten werden im folgenden zur besseren Abgrenzung von den Textnachrichten des SMS nur noch kurz MMs (MM - Multimedia Message; Plural: MMs) genannt. Im Gegensatz zum SMS entfällt die Beschränkung auf reine Textinhalte. Beim MMS wird es möglich sein, Texte dem individuellen Geschmack entsprechend zu formatieren sowie Audio- und Videoinhalte in eine Nachricht einzubetten. Eine weitere Neuigkeit ist, daß bei der Zustellung von MMs bekanntermaßen zwischen dem sogenannten PUSH-Modus (Drück-/Bring-Modus) , bei dem eine ankommende MM unverzüglich dem Empfänger zugestellt wird, und dem sogenannten PULL-Modus (Zieh-/Hol- Modus) , bei dem der Empfänger zunächst über eine neu eingetroffene MM informiert wird und daraufhin selbst entscheiden kann, wann er diese MM auf sein Endgerät herun- terlädt, unterschieden wird. Diese bekannten Zusammenhänge sind in Fig. 1 verdeutlicht, wobei mit dem Bezugszeichen 12 ein als MMS Server bezeichnetes Netzwerkelement und mit dem Bezugszeichen 11 ein UMTS Terminal gekennzeichnet ist.
Nach dem bisherigen Stand der Technik ist eine Implementierung von MMS lediglich über WAP (WAP - Wireless Application Protocol) realisierbar. Zur Überbrückung der Luftschnittstelle zwischen einem MMS-tauglichen Endgerät und dem WAP Gateway ist die Benutzung des WAP WSP (WSP - Wireless Session Protocol), s. WAP-203-WSP, Version 4-May- 2000; Wireless Application Protocol, Wireless Session Protocol Specification; Chapter 8.4: "Header Encoding" , vorgesehen, s. 3G TS 22.140 Version 4.0.1 (s.o.); 3G TS 23.140 version 4.0.0, Release 4, Third Generation Partnership Project, Technical Specification Group Terminals, Multimedia Messaging Service (MMS) , Functional Descripti- on, Stage 2. Fig. 2 zeigt ein sogenanntes Transaktions-Flußdiagramm nach heutigem Stand der Technik gemäß 3G TS 23.140 Version 4.0.0 (s.o.), in dem der Austausch der WAP Nachrichten zwischen den drei beteiligten Instanzen beim Versand und Empfang einer MM dargestellt ist, nämlich einer Sendeapplikation UAA (UAA als Abkürzung für MMS User Agent A) , Netzwerkelement RS (RS als Abkürzung MMS Relay/Server) und einer Empfangsapplikation UAB (UAB als Abkürzung für MMS User Agent B) . Unter MMS User Agent versteht man hierbei eine Applikation auf einem Mobilfunkgerät oder auf einem an ein Mobilfunkgerät angeschlossenen Gerät (z.B. Laptop, o.a.), die MMS realisiert. Ein MMS Relay/Server ist ein Netzwerkelement im Zuständigkeitsbe- reich bzw. in der MMS-Umgebung des MMS Dienstanbieters (MMS Service Providers) , das den Applikationen „MMS User Agents" die MMS-Funktionalität zur Verfügung stellt.
Im folgenden wird anhand des bekannten Transaktions- Flußdiagramms in Fig. 2 („Sendeapplikation UAA schickt MMA an Empfangsapplikation UAB") der Austausch der WAP Nachrichten beschrieben. Dabei wird zunächst vereinfachend davon ausgegangen, daß die Sendeapplikation UAA 1 und die Empfangsapplikation UAB 12 den MMS vom gleichen MMS Dienstanbieter in Anspruch nehmen. Die in des Sendeapplikation UAA 1 erzeugte MMA wird mit der WAP Nachricht M-Send. req an das Netzwerkelement RS 2 , 12 geschickt (da dieses Netzwerkelement sowohl senderseitig als auch emp- fangsseitige Funktionen übernimmt, ist es mit dem doppel- ten Bezugszeichen 2, 12 gekennzeichnet) . Daraufhin erhält die Empfangsapplikation UAA 1 die WAP Nachricht M- Send. conf zurück, mit welcher der korrekte Empfang der MMA vom Netzwerkelement RS 2 , 12 bestätigt wird. In ihr ist auch eine vom Netzwerkelement RS 2, 12 festgelegte, möglicherweise individuelle, Identifikationsnummer ID1 für die abgeschickte MMA enthalten. Danach informiert das Netzwerkelement RS 2 , 12 die Empfangsapplikation UAB 11 mit der WAP Nachricht M-Notification . ind über den Speicherplatz (URI - Uniform Resource Identifier; im Folgenden wird die Abkürzung URI verwendet) der neu eingetroffenen und zum Herunterladen (Download) bereitliegenden MMA. Das Netzwerkelement RS 2 , 12 erhält daraufhin z.B. mit der WAP Nachricht M-NotifyResp . reg eine Bestätigung, daß die Benachrichtigung über die eingetroffene MMA (M- Notification . ind) erfolgreich zugestellt worden ist. Zu diesem Zeitpunkt hat das Netzwerkelement RS 2 , 12 noch keine Nachrichten-ID für die zum Herunterladen bereitlie- gende MM vergeben. Beim Austausch der beiden WAP Nachrichten M-Notification . ind und M-NotifyResp . reg wird nur eine für diese Benachrichtigung individuelle Transaktions-Identitätsnummer { Transaction-ID) ausgetauscht. Die Empfangsapplikation UAB fordert dann mit Hilfe der WAP Nachricht WSP GET, mit welcher der URI an das Netzwerkelement RS 2, 12 geschickt wird, die Auslieferung der MMA an. Mit der WAP Nachricht M-Retrieve . conf wird der Empfangsapplikation UAB 11 daraufhin vom Netzwerkelement RS 2, 12 die gewünschte MMA zugestellt. Hierbei wird die MMA über die vom Netzwerkelement RS 2 , 12 vergebene, möglicherweise individuelle, Identifikationsnummer ID2 identifiziert. Mit der WAP Nachricht M-Acknowledge . ind wird der korrekte Empfang der MMA von der Empfangsapplikation UAB 11 quittiert. Für den Fall, daß der Absender den Wunsch geäußert hat, über einen erfolgreichen Empfang der von ihm verschickten MMA benachrichtigt zu werden, kann das Netzwerkelement RS 2 , 12 dem nachkommen, indem die WAP Nachricht M-Delivery. ind an die Empfangsapplikation UAB 11 geschickt wird.
Fig. 3 zeigt eine bekannte mögliche MMS Architektur, bei der die am Austausch einer MM beteiligten Sendeapplikation UAA 1 und Empfangsapplikation UAB 11 den MMS von verschiedenen MMS Dienstanbietern (MMS Dienstanbieter A und MMS Dienstanbieter B) in Anspruch nehmen. In diesem Fall ist eine Weiterleitung der MM zwischen den MMSEs (MMSE - Multimedia Messaging Service Environment = Multimedia- Nachrichtendienst-Umgebung bzw. MMS-Umgebung) der beteiligten MMS Dienstanbieter nötig. Das Bezugszeichen 4 kennzeichnet die MMSE des MMS Dienstanbieters A und das Bezugszeichen 14 die MMSE des Dienstanbieters B. Die Wei- terleitung einer MM zwischen zwei MMSEs und hierbei genauer zwischen dem senderseitigen Netzwerkelement RSA 2 (RSA als Abkürzung für MMS Relay/Server A) und dem emp- fangsseitigen Netzwerkelement RSB 12 (RSB als Abkürzung für MMS Relay/Server B) geschieht über SMTP (SMTP - Simp- le Mail Transfer Protocol), s. 3G TS 23.140 Version 4.0.0 (s.o.), z.B. durch das Internet (IP - Internet Protocol mit Bezugszeichen 20) . Das Protokoll SMTP ist in Fig. 3 mit dem Bezugszeichen 22 bezeichnet. Das Mobilfunknetz wird in Fig. 3 wie allgemein üblich als PLMN (PLMN - Pub- lic Land Mobile Network) bezeichnet und trägt in Fig. 3 das Bezugszeichen 6. Jeder MM kann beim Editieren ein Zeitpunkt zugewiesen werden, zu dem die MM frühestens dem Empfänger, genauer der Empfangsapplikation UAB 11, zugestellt werden soll. Wird davon Gebrauch gemacht, ist eine Zwischenspeicherung der MM im senderseitigen MMSEA 4 - genauer: einem Speicher „MMS Server A" mit Bezugszeichen 3 - bis zum Erreichen dieser Frist vorgesehen, s.o. Report of the 3GPP TSG-T2 SWG3 MMS Ad Hoc Meeting #5 in So- phia Antipolis, France 10-12 October 2000; T-doc: T2M00092; chapter 7; 3GPP TSG-T2 SWG3. Erst danach wird die MM an das empfangsseitige MMSEB 14 übermittelt. Weiterhin kann beim Editieren einer jeden MM auch eine ge- wünschte Gültigkeitsdauer angegeben werden. Die Speicherung einer MM bis zum Ablauf der Gültigkeit bzw. bis zum vorherigen Download der MM durch die Empfangsapplikation UAB 11 soll im empfangsseitigen MMSEB 14 (genauer: in einem Speicher „MMS Server B" mit Bezugszeichen 13) statt- finden, s.o. Report of the 3GPP TSG-T2 SWG3 MMS Ad Hoc Meeting #5.
Wie ebenfalls aus der bekannten MMS Referenzarchitektur gemäß der Fig. 3 zu entnehmen ist, können die MMs nicht nur von Applikationen UAA bzw. UAB, sondern auch von MMS VAS-Applikationen (VAS Applications, wobei VAS = Value Added Services = Mehrwertdienste) stammen, die in der Fig. 3 mit dem Bezugszeichen 7 gekennzeichnet ist. Dabei handelt es sich um eine netzwerkseitige Einrichtung, die Zusatzdienste anbietet. In diesem Fall dient die MM7- Schnittstelle als Kommunikationsschnittstelle zwischen einer MMS VAS-Applikation und einem Netzwerkelement RS . Bis heute wurden für diese Schnittstelle keine mandatori- schen MMS-spezifischen Nachrichten definiert. Die Kommu- nikation hier kann auf HTTP (Hypertext Transport Protocol) oder SMTP (Simple Mail Transport Protocol) basieren. Zudem ist es laut dem aktuellen Stand der Standardisierung möglich, eine MM1-ähnliche Kodierung für diese Schnittstelle zu verwenden.
Bei den eingangs genannten Verfahren und Vorrichtungen ist eine Nachricht vom Absender bzw. Auftraggeber bearbeitbar, solange sie sich noch in der Sendeapplikation UAA befindet. Wenn die Nachricht abgesandt wurde, besteht keine Möglichkeit der Beeinflussung bzw. des Zugreifens mehr. Dieses Problem besteht nicht nur bei der Versendung von Nachrichten über Funk, sondern auch bei der Versen- düng von elektronischer Post (E-mails) über das Internet und anderen Nachrichten-Systemen.
Es ist Aufgabe der vorliegenden Erfindung, das Verfahren und die Vorrichtungen der eingangs genannten Art derart weiterzubilden, daß eine mehr den Bedürfnissen des Absenders/Empfängers orientiertere Bearbeitung bzw. Beeinflussung von Nachrichten ermöglicht wird.
Diese Aufgabe wird bei dem Verfahren der eingangs genann- ten Art dadurch gelöst, daß eine zweite Nachricht mit einem Manipulationsauftrag zur Manipulation der ersten Nachricht erstellt, versendet, empfangen, weitergeleitet und/oder verarbeitet wird, um einen manipulierenden Zugriff auf die erste Nachricht zu veranlassen oder zu vermitteln.
Weiterhin wird diese Aufgabe bei einer entsprechenden Telekommunikationseinrichtung durch die Merkmale des Anspruchs 35 gelöst. Hierunter werden insbesondere Mobil- funktelefone sowie mit dem Internet verbundene Kommunikationseinheiten einschließlich Computer verstanden. Die erfindungsgemäßen Mittel zum Erstellen, Versenden, Empfangen und/oder Verarbeiten der zweiten Nachricht umfassen - neben den Hardwareeinheiten, wie insbesondere Steu- ereinheiten und Prozessoreinheiten - insbesondere Softwarelösungen, die nachfolgend genauer vorgestellt werden und bevorzugt Modifikationen von WAP-Nachrichten mit ver- änderten und/oder neu definierten Kopf-Feldern darstellen bzw. diese verarbeiten können.
Zudem wird diese Aufgabe bei einem entsprechenden Netz- werkelement durch die Merkmale des Anspruchs 46 gelöst. Im Sinne dieser Erfindung sind derartige Netzwerkelemente Teil eines Kommunikationssystems, welche eine Kommunikation zwischen mehreren Sende- und/oder Empfangseinheiten, insbesondere mehreren Mobiltelefonen und/oder ans Inter- net angeschlossenen Rechnern, ermöglichen. Ein solches
Kommunikationssystem - unter Einschluß von Funkkommunikationssystemen - wird üblicherweise von Dienstanbieter bzw. Service Providern betrieben. Die erfindungsgemäßen Mittel zum Empfangen, Verarbeiten und/oder Weiterleiten der zweiten Nachricht schließen außer den notwendigen
Hardware-Elementen, wie insbesondere Steuereinheiten und Prozessoreinheiten, insbesondere Software ein, die im folgenden genauer beschrieben wird und bevorzugt Modifikationen von WAP-Nachrichten mit ensprechend angepaßten oder neu definierten Kopf-Feldern darstellen bzw. diese verarbeiten können.
Eine Nachricht im Sinne dieser Erfindung kann sowohl eine herkömmliche SMS, eine MM mit multimedialen Inhalten oder eine sonstige elektronische Nachricht sein. Im folgenden wird die Erfindung anhand der MM beschrieben, ohne daß hierdurch eine Einschränkung auf diesen Nachrichtentyp erfolgen soll. Für die erste Nachricht wird im folgenden die Abkürzung MMA, für die zweite Nachricht die Abkürzung MMB verwendet .
Die Vorteile der Erfindung liegen insbesondere darin, daß es ermöglicht wird, eine erste Nachricht nach dem Abschi- cken zu manipulieren, insbesondere zurückzurufen und/oder nachträglich eine Veränderung bzw. Aktualisierung an ihr vorzunehmen. Eine solche Manipulation kann gemäß der Erfindung bei der Versendung von Nachrichten über Funk, ü- ber Mobilfunksysteme, zwischen Mobilfunksystemen, insbesondere über ein Inter-Operator-IP-backbone, zwischen Mobilfunknetzen und anderen Nachrichten-Systemen, insbesondere Internet-Email, und/oder über das Internet möglich sein.
Insbesondere ist es mit Hilfe der vorliegenden Erfindung möglich, eine von einem Auftraggeber mittels einer Sendeapplikation einer Sendeeinheit über mindestens ein Netzwerkelement an eine Empfangsapplikation einer Empfangs- einheit gesendete erste Nachricht - insbesondere eine Multimedia Message nach dem MMS-Typ - zu manipulieren, wobei nach Versenden der ersten Nachricht eine zweite Nachricht mit einer Manipulierinformation von der Sendeeinheit an mindestens ein Netzwerkelement übermittelt wird, das einen manipulierenden Zugriff auf die erste Nachricht veranlaßt oder vermittelt.
Die erste Nachricht und die zweite Nachricht werden über mindestens ein senderseitiges Netzwerkelement eines Dienstanbieters und mindestens ein empfängerseitiges
Netzwerkelement eines Dienstanbieters an die Empfangsapplikation gesendet. Hierbei können das mindestens eine senderseitige Netzwerkelement und das mindestens eine empfängerseitige Netzwerkelement dem Zuständigkeitsbe- reich eines einzigen Service Providers angehören oder sogar - im einfachsten Fall - identisch sein. Auch sind Fälle einer Identität der Empfangs- und der Sendeapplikation möglich.
Besonders bevorzugt erfolgt der manipulierende Zugriff auf die erste Nachricht auf einem senderseitigen Netzwerkelement, auf einem empfängerseitigen Netzwerkelement und/oder auf der Empfangsapplikation.
Ist die Empfangsapplikation noch nicht über den Manipula- tionsauftrag informiert worden, wird die erste Nachricht bevorzugt entweder im Zuständigkeitsbereich des senderseitigen oder des empfängerseitigen Dienstanbieters manipuliert, vorzugsweise ohne die Empfangsapplikation über die Manipulation zu benachrichtigen. Ist die Benachrich- tigung über die erste Nachricht hingegen schon an die Empfangsseite erfolgt, aber ist diese erste Nachricht noch nicht heruntergeladen, wird vorzugsweise die erste Nachricht im Zuständigkeitsbereich des senderseitigen Dienstanbieters ohne Informieren der Empfangsapplikation manipuliert, oder die Manipulation erfolgt im Zuständigkeitsbereich des empfängerseitigen Dienstanbieters, wobei bevorzugt die Empfangsapplikation über die Manipulation und deren Zeitpunkt informiert wird.
Die erfindungsgemäße Manipulation ist nicht auf die beiden Dienstmerkmale Zurückrufen und Ändern beschränkt. Auch Aufträge zu einer nachträglichen Weiterleitung (For- warding) , ein nachträgliches Anhängen der zweiten Nachricht an die erste Nachricht, usw. wird im Sinne dieser Erfindung unter einer Manipulation verstanden. Im folgenden werden der Rückruf- und der Änderungsauftrag genauer beschrieben. Gemäß einer Ausführungsform der Erfindung kann das Zurückrufen (im Rahmen dieser Offenbarung mit „Recall" bezeichnet) einer MM zumindest immer noch solange möglich sein, bis sie der Empfänger in einen anderen Ordner ver- schoben, an einen anderen Empfänger weitergeleitet oder geöffnet hat.
Das nachträgliche Ändern (im Rahmen dieser Offenbarung mit „Replace" bezeichnet) einer MM ist gemäß einer Aus- führungsform der Erfindug vorteilhafterweise auch dann noch möglich, wenn der Empfänger die MM schon „angefaßt" hat. In diesem Fall wird der Empfänger vorzugsweise umgehend über eine nachträgliche Änderung der entsprechenden MM informiert, entweder durch eine Benachrichtigung (No- tification) , damit er den Download der aktualisierten MM nachträglich selbst einleiten kann (PULL-Modus) , oder gleich durch eine automatische Zustellung der aktualisierten MM (PUSH-Modus) .
In einer Weiterbildung der Erfindung ist es zudem möglich, daß der Absender einer MM, d.h. Sendeapplikation (MMS User Agent) oder MMS VAS-Applikation, eine zuvor verschickte MM unter Angabe bestimmter Bedingungen wieder zurückrufen oder nachträglich eine Veränderung bzw. Aktu- alisierung an ihr vornehmen kann. Diese vom Absender wählbaren Bedingungen, die in Informationselementen der zweiten Nachricht enthalten sind, können insbesondere sein: Rückruf einer MM nur dann, wenn der Empfänger noch nicht über eine zum Download bereitliegende MM informiert worden ist, oder Änderungsauftrag auch dann ausführen, wenn die MM schon an das Endgerät des Empfängers zugestellt, aber noch nicht geöffnet worden ist. Diese Dienstmerkmale werden im Folgenden „Bedingter Rückruf" („Conditional Recall" oder „Conditional Cancel") beziehungsweise „Bedingtes Ändern" („Conditional Replace") genannt. Unter dem Begriff „Ändern" bzw. „Replace" wird insbesondere das Ersetzen verstanden, aber auch jede sonstige Form des Änderns . Die erfindungsgemäßen Informationselemente sind hierbei beispielsweise entsprechend ergänzte oder neu definierte Kopf-Felder in WAP Nachrichten.
Vorteil dieses Erfindungsaspekts ist die Realisierung einer Skalierbarkeit und Flexibilität des Zurückrufens und/oder des Ersetzens einer zuvor gesendeten MM. Diese Dienstmerkmale erhöhen die Attraktivität des Multimedia- Nachrichtendienstes (Multimedia Messaging Service) .
Der Absender einer Nachricht (MM) - sowohl bei unbedingten als auch bei bedingten Manipulationsaufträgen - kann insbesondere eine Sendeapplikation „MMS User Agent" oder eine MMS VAS-Applikation sein. Eine solche Sendeapplika- tion kann zum Beispiel eine Applikation auf einem mobilen Endgerät sein, während eine MMS VAS Applikation eine netzwerkseitige Applikation darstellt, die Mehrwertdiens- te anbietet.
Des weiteren ist Gegenstand der Erfindung die Implementierung des erfindungsgemäßen Verfahrens in WAP durch die Modifikation von vorhandenen Kopf-Feldern oder das Hinzufügen von neu definierten Kopf-Feldern in die betroffenen WAP Nachrichten des WAP-MMSEncapsulation Standards, s. WAP-209-MMSEncapsulation, Release 2000; Wireless Application Protocol; WAP Multimedia Messaging Service; Message Encapsulation; MMS Proposed SCD 1.0. Ebenso ist die entsprechende binäre Kodierung, wie weiter unten für Ausführungsbeispiele beschrieben, Gegenstand der vorliegenden Erfindung.
Im folgenden wird die Erfindung anhand von Beispielen näher erläutert .
Es zeigen:
Fig. 1 eine Gegenüberstellung des PULL- und PUSH-Modus gemäß UMTS nach dem Stand der Technik;
Fig. 2 ein Transaktions-Diagramm für einen Multimedia- Nachrichtendienst (MMS) nach dem Stand der Technik;
Fig. 3 eine schematische Darstellung einer Multimedia- Nachrichtendienst-Architektur nach dem Stand der Technik;
Fig. 4 einen Multimedia-Nachrichtendienst mit einer
Manipulationsmδglichkeit einer ersten Nachricht gemäß der vorliegenden Erfindung;
Fig. 5 eine Kodierung von neu definierten Kopf- Feldern;
Fig. 6 Ergänzungen im bekannten Kopf-Feld X-Mms- Status;
Fig. 7 neu eingeführtes Kopf-Feld X-Mms -Original - Message -Sta tus; Fig. 8 neu eingeführtes Kopf-Feld X-Mms -Original - Message-ID;
Fig. 9 Kodierung von weiteren neu definierten Kopf- Felder, und
Fig. 10 Ergänzungen im Kopf-Feld X-Mms -Supported - Feature .
Es wird - unter Bezugnahme auf das obere Drittel der Fig. 4 - bei der Beschreibung der Ausführungsbeispiele von dem folgenden, bekannten Ablauf des Versendens und Empfangens einer ersten Nachricht MMA durch Vermittlung eines ersten und eines zweiten MMS Dienstanbieters (Dienstanbieter A und Dienstanbieter B) ausgegangen: Nach dem Verschicken der ersten Nachricht MMA wird der Sendeapplikation UAA 1 des Absenders in der WAP Nachricht M-send . conf eine Message-ID für die zuvor verschickte MMA mitgeteilt (ID1) . Diese Identifikationsnummer ID1 wird vom Netzwerkelement RSA 2 des Dienstanbieters A erzeugt und kennzeichnet die MMA innerhalb der senderseitigen Schnittstelle Sendeapplikation UAA 1 / Netzwerkelement RSA 2 eindeutig. Bei der empfängerseitigen Zustellung der MMA vom Netzwerkelement RSB 12 des Dienstanbieters B zur Empfangsapplikation UAB 11 durch die WAP Nachricht M-Retrieve . conf wird ebenfalls eine Message-ID (ID2 in Fig. 2) übermittelt. Diese Identifikationsnummer ID2 wird möglicherweise vom Netzwerkelement RSB 12 neu erzeugt und dient zur eindeutigen empfängerseitigen Kennzeichnung der MMA innerhalb der Schnittstelle Netzwerkelement RSB 12 / Empfangsapplikation UAB 11.
Zur Übermittlung der MMA zwischen dem senderseitigen Netzwerkelement RSA 2 und dem empfängerseitigen Netzwerkelement RSB 12 kann ID1 in eine Interim- Identifikationsnummer (ID3) umgewandelt werden, welche die MMA zwischen den verschiedenen Systemen identifiziert (Anm. : in der Fig. 4 weisen generell die mit einem Sternchen markierten Stellen auf solche Umwandlungen der Nachrichten-IDs zwischen den Schnittstellen hin) . Insbesondere sollte ID3 global eindeutig sein. Z.B. enthält ID3 Informationen hinsichtlich des Dienstanbieters A, der ID1 sowie dem Zeitpunkt der ID-Umwandlung. Dazu muß das sen- derseitige Netzwerkelement RSA 2 die Information bzw. die Möglichkeit besitzen, diese Umwandlung wieder rückgängig zu machen, z.B. für Auslieferungsberichte. Um intern ü- bersichtliche IDs zu benutzen, kann ID3 vom empfängersei- tigen Netzwerkelement RSB 12 in die oben erwähnte interne ID2 umgewandelt werden, welche die MMA zu der Empfangsapplikation UAB 11 identifiziert. Dazu muß wiederum das empfängerseitige Netzwerkelement RSB 12 die Information bzw. die Möglichkeit besitzen, diese Umwandlung wieder rückgängig zu machen, z.B. für Auslieferungsberichte. Die MMA wird empfängerseitig durch ID2 identifiziert.
Gemäß der Erfindung wird nun von der Sendeapplikation, der Empfangsapplikation und/oder zwischen der Sende- und Empfangsapplikation vermittelnden Netzwerkelementen die Möglichkeit zum Zugriff auf die zuvor versendete erste Nachricht MMA bereitgestellt, indem eine zweite Nachricht MMB bereitgestellt wird, die einen manipulierenden Zugriff auf die erste Nachricht MMA veranlaßt oder ver- mittelt.
Eine Möglichkeit der Identifikation von MMB wird folgend anhand der Fig. 4 erläutert, bei der MMB die Identifika- tionsnummer ID4 trägt. Zur Übermittlung von MMB zwischen den verschiedenen Dienstanbieter-Systemen kann ID4 vom senderseitigen Netzwerkelement RSA 2 umgewandelt werden in eine Interim-ID (ID6) , welche MMB zwischen den Syste- men identifiziert. Insbesondere sollte ID6 global eindeutig sein, z.B. eine Kombination von Informationen hinsichtlich des Dienstanbieters A, ID4 und Zeitpunkt der Umwandlung enthalten. Dazu muß das senderseitige Netzwerkelement RSA 2 die Information bzw. die Möglichkeit besitzen, diese Umwandlung wieder rückgängig zu machen, z.B. für Auslieferungsberichte. Um intern übersichtlichere IDs zu benutzen, kann ID6 vom empfängerseitigen Netzwerkelement RSB 12 umgewandelt werden in eine interne ID (ID5) , welche MMB zur Empfangsapplikation UAB 11 identi- fiziert. Dazu muß das empfängerseitige Netzwerkelement RSB 12 die Information bzw. die Möglichkeit besitzen, diese Umwandlung wieder rückgängig zu machen, z.B. für Auslieferungsberichte. MMB wird empfängerseitig durch ID5 identifiziert .
Um die notwendige Verbindung von MMA und MMB zu realisieren, weist ID4 eine Referenz zu ID1, ID6 eine Referenz zu ID3 und ID5 eine Referenz zu ID2 auf. Die Benachrichtigungen der Empfangsapplikation UAB 11 über MMA und MMB verweisen zudem auf zwei Speicherplätze URIl bzw. URI2.
Es ist möglich, daß die Identifikationsnummern ID1 und ID3, ID3 und ID2 , sowie ID1, ID2 und ID3 identisch sind. Ebenso können ID4 und ID6 , ID6 und ID5, sowie ID4 , ID5 und ID6 identisch sein.
Zumindest eines der beteiligten senderseitigen und eines der beteiligten empfängerseitigen Netzwerkelmenente ist vorteilhafterweise in der Lage, eine eineindeutige, umkehrbare Umwandlung von IDs vorzunehmen und die Informationen hierüber zu verwalten.
Im folgenden werden die Manipulationsmöglichkeiten „Rückruf" und „Ändern" beispielhaft beschrieben, worunter unter dem letzteren Begriff im Sinne dieser Erfindung beispielsweise eine Aktualisierung der ersten Nachricht MMA verstanden wird, insbesondere durch Ersetzen der ersten Nachricht durch die zweite Nachricht. Allgemein sind jedoch alle Kombinationen der gemäß dieser Erfindung offenbarten Optionen für alle Arten von Manipulationen realisierbar, so z.B. ob und mit welchen Informationen der Empfänger über eine Manipulation einer ersten Nachricht benachrichtigt wird, ob über die Art der Manipulation informiert werden soll, ob der Empfänger über einen Manipulationswunsch des Absenders informiert werden soll, ob die zweite Nachricht im PULL- oder im PUSH-Modus zugestellt werden soll, ob die Änderung auf einem sendersei- tigen oder empfängerseitigen Netzwerkelement oder auf der Empfangsapplikation UAB erfolgen soll, ob der Absender und/oder der Empfänger über den Erfolg der Manipulation benachrichtigt werden soll, usw.
A. DIENSTMERKMAL „RUCKRUF'
Gemäß der Erfindung kann ein Benutzer des MMS, der eine erste Multimedia Message MMA abgeschickt hat und diese bereits verschickte MMA wieder zurückrufen möchte, eine neue, zweite Nachricht MMB mit der Information verschicken, daß die zuvor verschickte, erste Nachricht MMA wieder zurückgerufen werden soll. Dies kann erfindungsgemäß bevorzugt dadurch realisiert werden, indem der Absender die neue MMB verfaßt, die einen Rückruf-Befehl, aber bevorzugt keinen für den Empfän- ger bestimmten Inhalt (Content/Message Body) , beinhaltet, und diese an den gleichen Empfänger wie die zuvor verschickte MMA schickt. Als Rückruf-Kennung wird bevorzugt die ID1 der zuvor verschickten MMA benutzt . Die MMB mit der Rückruf-Information gelangt zunächst zum Netzwerkele- ment RSA des Absenders . Hier wird zweckmäßigerweise überprüft, ob die MMA mit der ID1 noch im Zuständigkeitsbereich des Dienstanbieters A (MMSEA) ist, oder ob sie schon an das MMSEB des Dienstanbieters B weitergeleitet worden ist. Ersteres ist z.B. der Fall, wenn der vom Ab- sender gewählte Zeitpunkt für die gewünschte Zustellung seiner MMA noch nicht erreicht worden ist; letzteres ist z.B. der Fall, wenn die MMA noch nicht ihre Gültigkeitsdauer überschritten hat und noch nicht der Empfangsapplikation UAB zugestellt worden ist. Sobald die MMA in einem MMSE der beteiligten MMS Dienstanbieter ausfindig gemacht wird, kann das Löschen von MMA und MMB vom zuständigen Netzwerkelement RS eingeleitet werden.
Falls die Empfangsapplikatin UAB schon über die für ihn im MMSEB bereitliegenden MMA mittels einer Benachrichtigung (Notification) informiert worden ist und sich die MMA noch im Zuständigkeitsbereich/Speicher des Dienstanbieters B befinden sollte, kann nach dieser Erfindung die Empfangsapplikation UAB mit einer erneuten Benachrichti- gung (Notification) davon in Kenntnis gesetzt werden, daß die MMA vom Dienstanbieter B gelöscht worden ist und somit nicht mehr zum Download bereit liegt, weil der Absender sie zurückgerufen hat. Außerdem hat der MMS Dienstan- bieter B nach dieser Erfindung die Möglichkeit, der Empfangsapplikation UAB das Datum der Ausführung des Rückruf-Befehls zu übermitteln.
Sollte die MMA schon an den Empfänger ausgeliefert worden sein, so kann die Empfangsapplikation UAB des Empfängers mit der o.g. erneuten Benachrichtigung (Notification) davon in Kenntnis gesetzt werden, daß der Absender die MMA zurückrufen möchte. Das Löschen der MMA kann nach dieser Erfindung direkt in der Empfangsapplikation UAB stattfinden, sofern dieses das Rückruf-Dienstmerkmal unterstützt. Je nach Implementierung dieses Dienstmerkmals im Endgerät, den Einstellungen des Benutzers, den Einstellungen des MMS Dienstanbieters und/oder des Netzbetreibers kann das Löschen der MMA im Endgerät davon abhängig sein, ob die MMA bereits vom Empfänger „angefaßt" (z.B. geöffnet, gelesen, weitergeleitet, etc.) worden ist. Sinnvoll erscheint jedoch, nur solche MMs nach der Auslieferung zu löschen, welche noch nicht vom Empfänger „angefaßt" wor- den sind. Die MMB mit der Rückruf-Information muß der Empfangsapplikation UAB nicht unbedingt zugestellt werden; sie kann schon im MMSEB gelöscht werden.
Hat der Empfänger (MMS User Agent B) der MMA noch keine Benachrichtigung über die MMA erhalten, etwa weil die MMB mit der Rückruf-Information das Netzwerkelement RSB vor der rückzurufenden MMA erreicht, muß dieser auch nicht über eine vom Absender eingeleitete Rückruf-Aktion informiert werden. Statt dessen wartet das Netzwerkelement RSB vorzugsweise, bis es die zum Rückruf referenzierte MMA erhält und löscht diese beim Eintreffen, ohne den Empfänger zu benachrichtigen (vorausgesetzt, das Netzwerkelement RSB unterstützt das Rückruf-Dienstmerkmal) . Alterna- tiv kann die Löschung von MMA auch schon auf dem Netz- werkelement RSA erfolgen.
Der Auftraggeber des Rückrufs (MMS User Agent A) wird ge- maß der vorliegenden Erfindung über den Ausgang und das Datum der Ausführung der von ihm eingeleiteten Aktion vorzugsweise informiert, wenn die beteiligten MMS Dienstanbieter dies ermöglichen.
Um das gerade beschriebene Dienstmerkmal Rückruf umsetzen zu können, schlägt die vorliegende Erfindung vor, daß eine oder mehrere der folgenden Informationen zusätzlich zwischen den beteiligten Instanzen (Sendeapplikation UAA, Netzwerkelement RSA, Netzwerkelement RSB und Empfangsap- plikation UAB) ausgetauscht werden:
Sendeapplikation UAA (MMS User Agent A) —» Netzwerkelement RSA (MMS Relay/Server A) (beim Versenden einer MM) :
• Kennzeichnung, daß es sich bei einer MMB um einen Rückruf-Befehl handelt.
• Identifikationsnummer der MMA, die zurückgerufen werden soll.
• Information, daß der Absender eine Rückmeldung über den Ausgang der von ihm initiierten Rückruf-Aktion an- fordert .
Netzwerkelement RSA (MMS Relay/Server A) -» Sendeapplikation UAA (MMS User Agent A) (bei der Bestätigung nach dem Versendens einer MM) : • Mitteilung des Dienstanbieters, ob dieser das Rückruf- Dienstmerkmal unterstützt. Netzwerkelement RSA (MMS Relay/Server A) ->• Netzwerkelement RSB (MMS Relay/Server B) (nur dann nötig, wenn Absender und Empfänger zu unterschiedlichen MMSEs gehören)
• Kennzeichnung, daß es sich bei einer MMB um einen Rückruf-Befehl handelt.
• Identifikationsnummer der MMA, die zurückgerufen werden soll.
• Information, daß der Absender eine Rückmeldung über den Ausgang der von ihm initiierten Rückruf-Aktion an- fordert .
Die Übermittlung der Informationen zwischen Netzwerkelement RSA und Netzwerkelement RSB ist davon abhängig, ob diese Informationen beim Versenden der MMB vorhanden waren.
Netzwerkelement RSB (MMS Relay/Server B) —» Empfangsapplikation UAB (MMS User Agent B) (bei der Benachrichtigung über eine eingetroffene MM) , vorzugsweise in einer Nachricht : • Information, wann der Rückruf ausgeführt wurde.
• Information, daß eine zuvor durch eine Benachrichtigung angekündigte MMA nun nicht mehr zum Download bereitliegt. Identifizierung der MMA, die im MMSEB gelöscht worden ist, erfolgt anhand der Nachrichtenrefe- renz (Message Reference; URI) . oder:
• Information, daß eine bereits ausgelieferte MMA vom Absender zurückgerufen wird. Identifizierung der MMA, die zurückgerufen wird, erfolgt auf der Empfangsappli- kation UAB anhand der Nachrichten-ID. Empfangsapplikation UAB (MMS User Agent B) — Netzwerkelement RSB (MMS Relay/Server B) (nach der Benachrichtigung) :
• Information, ob der Empfänger verstanden hat, daß eine zuvor durch eine Benachrichtigung angekündigte MMA nun nicht mehr zum Download bereitliegt . oder:
• Information, ob die Empfangsapplikation UAB den Rückruf (d.h. das Löschen) der MMA erfolgreich durchführen konnte bzw. veranlaßt hat.
• Information, ob der Empfänger darüber informiert wurde (und/oder dem Rückruf zugestimmt hat) , daß eine bereits heruntergeladene MMA zurückgerufen wurde und daher nicht mehr im der Empfangsapplikation UAB zugäng- liehen Speicher des Endgeräts (oder angeschlossener Geräte/Speicherkarten) vorliegt.
Netzwerkelement RSB (MMS Relay/Server B) —» Netzwerkelement RSA (MMS Relay/Server A) (nur dann nötig, wenn Ab- sender und Empfänger zu unterschiedlichen MMSEs gehören und wenn der Absender eine Rückmeldung angefordert hat) :
• Information, ob der Rückruf-Auftrag erfolgreich ausgeführt werden konnte .
• Information, wann der Rückruf-Auftrag ausgeführt wor- den ist.
• Information, ob der Rückruf-Auftrag automatisch durchgeführt wurde .
• Information, ob der Empfänger über den Rückruf informiert wurde (und/oder dem Rückruf zugestimmt hat) . • Information, daß eine bereits heruntergeladene MMA zurückgerufen wurde und daher nicht mehr im der Emp- fangsapplikation UAB zugängigen Speicher des Endgeräts (oder angeschlossener Geräte/Speicherkarten) vorliegt.
• Identifikationsnummer der MMA, die zurückgerufen wurde.
Netzwerkelement RSA (MMS Relay/Server A) -» Empfangsapplikation UAA (MMS User Agent A) (beim Bericht) :
• Information, ob der Rückruf-Auftrag erfolgreich ausgeführt werden konnte . • Information, wann der Rückruf-Auftrag ausgeführt worden ist.
• Information, ob der Rückruf-Auftrag automatisch durchgeführt wurde .
• Information, ob der Empfänger über den Rückruf infor- miert wurde (und/oder dem Rückruf zugestimmt hat) .
• Information, daß eine bereits heruntergeladene MMA zurückgerufen ,wurde und daher nicht mehr im der Empfangsapplikation UAB zugängigen Speicher des Endgeräts (oder angeschlossener Geräte/Speicherkarten) vorliegt. • Identifikationsnummer der MMA, die zurückgerufen wurde.
Zusätzliches Dienstmerkmal: Bedingter Rückruf
Diesem speziellen Erfindungsaspekt liegt die Idee eines bedingten Zurückrufens („Conditional Recall/Cancel") und bedingten nderns bzw. Ersetzens oder Aktualisierens von Multimedia-Nachrichten („Conditional Replace") zugrunde. Erfindungsgemäß wird die Ausführung eines vom Absender einer MM nachträglich verschickten Rückruf- oder Änderungsauftrages an bestimmte Bedingungen geknüpft. Zum Beispiel kann es sein, daß Absender eine bestimmte MM nur dann zurückrufen oder aktualisieren will, wenn der Empfänger noch nicht über das Eintreffen informiert wurde. In anderen Fällen könnte er das Löschen oder das Ändern wünschen, auch wenn die Empfangsapplikation UAB eine Be- nachrichtigung (Notification) erhalten hat oder wenn die MM sogar gelesen wurde. Des weiteren ist ein Konzept zur Realisierung dieser Dienstmerkmale Teil dieser Erfindung, bei dem die Einführung bzw. Anpassung von Datenfelder aus der 3GPP MMS Spezifikation notwendig ist, s.o. 3G TS 23.140 version 4.0.0. Dabei werden neue Kopf-Felder der WAP Nachrichten definiert und andere Felder angepaßt oder ergänzt .
Gemäß dieser bevorzugten Ausführungsform der Erfindung kann eine zweite Nachricht, im folgenden MMB genannt, mit der Information verschickt werden, daß die erste Nachricht, d.h. MMA, unter bestimmten Konditionen annulliert bzw. zurückgerufen werden soll. Die neue MMB beinhaltet Informationen zum Ausführen des Vorgangs des Zurückrufens der MMA. Erfindungsgemäß setzt der Absender des Rückruf- Befehls Bedingungen zum Ausführen seines Wunsches. Dabei legt der sendende User Agent oder die VAS-Applikation fest, in welchem Fall die zuvor gesendete MM gelöscht bzw. ungültig gemacht werden soll.
Der Dienstanbieter kann erfindungsgemäß das Verwenden des Rückruf-Merkmals auf die eigene oder auf bestimmte Domänen anderer Dienstanbieter begrenzen. Dies kann anhand einer Identifizierung der Adresse des Empfängers, bei- spielsweise seiner Rufnummer, Mailadresse o.a., erfolgen. Eine weitere Möglichkeit wäre das Einsetzen einer zusätzlichen Kennzeichnung (Flag) in dem Rückruf-Befehl . Im weiteren basiert der bedingte Rückruf auf die Bearbeitungsphase bzw. den Bearbeitungszustand der zuvor gesendeten Nachricht, insbesondere einer MM. Der Absender entscheidet in diesem Fall, in welchem Zustand der MM diese gelöscht werden soll . Mögliche vom Absender festgelegte Konditionen für den Rückruf können insbesondere sein:
1. Zurückrufen der MM nur, wenn die MM noch auf dem Server liegt und der Empfänger davon noch nicht in Kennt- nis gesetzt wurde. Der Rückruf erfolgt in diesem Fall also nur, wenn noch keine Benachrichtigung (Notification) gesendet wurde.
2. Zurückrufen der MM auch dann, wenn die Benachrichti- gung (Notification) gesendet, aber die MM noch nicht heruntergeladen wurde.
3. Zurückrufen der MM, wenn der Empfänger diese noch nicht geöffnet bzw. gelesen hat. In diesem Fall kann das Zurückrufen auch nach dem Herunterladen erfolgen.
4. Zurückrufen der MM unabhängig vom Bearbeitungsgrad der MM beim Empfänger. Der Rückruf wird hier auch dann versucht, wenn der Empfänger die MM gelesen hat.
Bei der Realisierung dieser Dienstmerkmale wird vorteilhafterweise eine Standardkondition „Default value" angenommen. Zum Beispiel kann vereinbart werden, daß eine Standardkondition einem der oben beschriebenen vier Fälle entspricht. Diese Voreinstellung kann beispielsweise - solange nichts Genaues zum konditionellen Ausführen des Rückruf-Befehls geäußert wurde - derart festgelegt sein, daß das Zurückrufen zum Beispiel nur vor einer Benach- richtigung über das Vorliegen einer MM erfolgen soll. Das System könnte auch so ausgelegt sein, daß ein Zurückrufen nur vor dem Herunterladen der zu löschenden MM oder sogar nach erfolgtem Öffnen bzw. Lesen der MM erfolgen soll.
Im folgenden werden die Transaktionen zur Realisierung vom MM-Status-bedingten Rückruf-Merkmals behandelt. Eine bereits verschickte MMA kann also durch den Absender nachträglich wieder zurückgerufen werden, indem er eine neue MMB verfaßt, die einen bedingten Ruckrufbefehl, aber bevorzugt keinen für den Empfänger bestimmten Inhalt (Content/Message Body) beinhaltet. Diese neue Nachricht wird dem gleichen Empfänger wie die zuvor verschickte MMA gesendet. Als Rückrufkennung wird bevorzugt die Identifi- kationsnummer (ID 1) der zuvor verschickten MMA benutzt. Die MMB mit der Rückruf-Information gelangt zunächst zum Netzwerkelement RSA (MMS Relay/Server A) des Absenders. Hier wird überprüft, ob die MMA mit der ID 1 noch im Zuständigkeitsbereich des Dienstanbieters A (Multimedia Messaging Service Environment A, MMSEA) ist, oder ob sie schon an das MMSEB des Dienstanbieters B weitergeleitet worden ist. Ersteres ist z.B. der Fall, wenn der vom Absender gewählte Zeitpunkt für die gewünschte Zustellung seiner MMA noch nicht erreicht worden ist; letzteres ist z.B. der Fall, wenn die MMA noch nicht ihre Gültigkeitsdauer überschritten hat und noch nicht der Empfangsapplikation UAB zugestellt worden ist.
Sobald die MMA in einem MMSE ausfindig gemacht wird, kann das Löschen von MMA und MMB vom zuständigen Netzwerkelement RS eingeleitet werden. Falls der ursprüngliche Empfänger die an ihn adressierte MMA an eine andere Adresse weitergeleitet hat, soll bevorzugt auch der Ruckrufbefehl vom Netzwerkelement RSB entsprechend weitergeleitet werden, womit das Zurückrufen im zielseitigen Netzwerkelement RS erfolgen kann. Wenn das Netzwerkelement RSB nur die Information hat, daß die MM weitergeleitet wurde, oh- ne das Ziel zu wissen (beispielsweise, wenn der ursprüngliche Empfänger die an ihn adressierte MM an eine E-mail Adresse weitergeleitet hat) , kann der Absender des Rückrufbefehls vorteilhafterweise über den Mißerfolg des Rückrufs aufgrund des Weiterleitens informiert werden. Aus Vertraulichkeitsgründen wäre es auch möglich, den Mißerfolg der Ausführung zu melden, ohne in diesem Fall den Grund zu kommentieren.
Ein besonders günstiger Fall zum Ausführen des Rückrufbe- fehls liegt vor, wenn die MM noch auf einem der Netzwerkelemente RSA oder RSB, und die Empfangsapplikation UAB noch nicht über diese Nachricht benachrichtigt wurde. Ein solcher Fall könnte zum Beispiel auftreten, wenn die MM auf Wunsch des Absenders zu einem bestimmten Zeitpunkt ausgeliefert werden soll, der aber noch nicht eingetreten ist. Hier liegt die MM noch auf dem Netzwerkelement RSA des Absenders . Die MM kann auch auf dem Netzwerkelement RSB gespeichert sein, falls z.B. das Endgerät des Empfängers ausgeschaltet ist und die Gültigkeitsdauer der MM nicht überschritten wurde. In diesen beiden Fällen kann das Löschen der MM unabhängig von den ausgewählten Löschkonditionen erfolgen. Alle vier oben beschriebenen Rückrufkonditionen decken nämlich diese Situation ab.
Falls die Empfangsapplikation UAB schon über die für ihn im MMSEB bereitliegende MMA mittels einer Benachrichtigung (Notification) informiert worden ist und sich die MMA noch im Zuständigkeitsbereich/Speicher des Dienstan- bieters B befinden sollte, kann gemäß dieser Erfindung das Zurückrufen nur in den oben mit 2, 3 und 4 numerierten Fällen erfolgen. Für den Fall 1 des bedingten Rückrufs erhält der Absender vorzugsweise eine Benachrichti- gung mit der Erklärung, daß der Empfänger schon über die zuvor gesendete MM informiert wurde und das Zurückrufen nicht durchgeführt werden konnte. Für die weiteren Fälle (2, 3 und 4) kann die Empfangsapplikation UAB mit einer erneuten Benachrichtigung (Notification) davon in Kennt- nis gesetzt werden, daß die MMA vom Dienstanbieter B gelöscht wurde und somit nicht mehr zum Herunterladen bereit liegt, weil der Absender sie zurückgerufen hat. Eine weitere Möglichkeit wäre, den Empfänger über den Rückruf- Vorgang zu informieren, und erst wenn er die MM anfor- dert, ihm mitzuteilen, daß sie nicht mehr vorhanden ist, oder das sie zurückgerufen wurde.
Sollte die MMA schon an den Empfänger ausgeliefert worden sein, so kann das Zurückrufen nur für den Fall 4 (Zurück- rufen, unabhängig vom Bearbeitungsgrad) und unter Umständen für den Fall 3 (Zurückrufen, wenn MM noch nicht geöffnet/gelesen wurde) erfolgen. Die Empfangsapplikation UAB wird - nur für die Fälle 3 und 4 - vorzugsweise mit einer neuen Benachrichtigung (Notification) davon in Kenntnis gesetzt, daß der Absender die MMA zurückrufen möchte. Diese Benachrichtigung beinhaltet bevorzugt die Konditionen des Löschens.
Das Löschen der MMA kann folglich direkt in der Empfangsapplikation UAB stattfinden, sofern dieses das Rückruf- Merkmal unterstützt. Wenn es sich um den Fall 3 handelt, wird die MM nur dann gelöscht, wenn das Endgerät feststellt, daß die MM noch nicht geöffnet bzw. gelesen wur- de. Für den Fall 4 wird das Löschen unabhängig davon veranlaßt. In beiden Fällen muß die MMB der Empfangsapplikation UAB nicht zugestellt werden. Sie kann schon im MMSEB gelöscht werden, da die Benachrichtigung (Notifica- tion) der Auslöser des Löschens ist. Für die Fälle 1
(Rückruf vor der Benachrichtigung) und 2 (Rückruf nur vor dem Herunterladen) kann der Rückruf nicht erfolgen. Der Absender erhält hierbei vorzugsweise eine Rückmeldung mit der Information, daß die MM nicht zurückgerufen werden konnte, da eine Benachrichtigung schon abgeschickt wurde
(Fall 1) oder weil die MM schon heruntergeladen wurde
(Fall 2) .
Eine weitere Möglichkeit zur Realisierung des Löschvor- gangs ist erfindungsgemäß das Zustellen der MMB mit der Rückruf-Information bis zur Empfangsapplikation UAB. Das Löschen wird dann im Endgerät des Empfängers durch die MMB und nicht durch die aus der MMB entstehende Benachrichtigung (Notification) ausgelöst. Dieser Fall wird im weiteren nicht detaillierter behandelt.
Der Auftraggeber des Rückrufs (Sendeapplikation UAA oder VAS Applikation) wird bevorzugt in allen beschriebenen Fällen über den Ausgang und ggf. das Datum der Ausführung der von ihm eingeleiteten Aktion informiert, insbesondere wenn er dies anfordert und zudem die beteiligten MMS Dienstanbieter dies ermöglichen.
Um das gerade beschriebene Dienstmerkmal „Bedingter Rück- ruf" umsetzen zu können, wird erfindungsgemäß vorgeschlagen, daß eine oder mehrere der folgenden Informationen zusätzlich zwischen den beteiligten Instanzen (Sendeapplikation UAA , MMS Netzwerkelement RSA, MMS Netzwerkele- ment RSB und Empfangsapplikation UAB) ausgetauscht werden. Als Basis dienen die aktuellen 3GPP Spezifikationen 3G TS 22.140 Version 4.0.1 (s.o.), 3G TS 23.140 Version 4.0.0 (s.o.), WAP Spezifikationen WAP-209- MMSEncapsulation, Release 2000 (s.o.), WAP-203-WSP, Version 4-May-2000 (s.o.) sowie Report of the 3GPP TSG-T2 SWG3 MMS Ad Hoc Meeting #5 (s.o.) . Im Folgenden wird näher auf die Unterschiede und Ergänzungen im Vergleich zu dem unbedingten Rückruf eingegangen:
Sendeapplikation UAA (MMS User Agent A) —> Netzwerkelement RSA (MMS Relay/Server A) (beim Versenden einer MM) : • Bedingungen zum Ausführen des Rückrufs :
- Rückruf nur vor Benachrichtigung. — Rückruf nur vor dem Herunterladen, auch nach dem Versand einer Benachrichtigung.
- Rückruf nur, wenn die MM nicht geöffnet/gelesen wurde.
- Rückruf unabhängig vom Bearbeitungsgrad der MM (auch nach dem Lesen der MMA) .
Netzwerkelement RSA (MMS Relay/Server A) - Sendeapplikation UAA (MMS User Agent A) (bei der Bestätigung nach dem Versenden einer MM) : • Mitteilung des Dienstanbieters, ob dieser das bedingte Rückruf-Merkmal unterstützt. Hier könnte das System zwischen der Unterstützung für „Rückruf" und „Bedingter Rückruf" unterscheiden.
Netzwerkelement RSA (MMS Relay/Server A) → Netzwerkelement RSB (MMS Relay/Server B) (nur dann nötig, wenn Absender und Empfänger zu unterschiedlichen MMSEs gehören) : • Bedingungen zum Ausführen des Rückrufs :
- Rückruf nur vor Benachrichtigung.
- Rückruf nur vor dem Herunterladen, auch nach dem Versand einer Benachrichtigung - Rückruf nur, wenn die MM nicht gelesen wurde.
- Rückruf unabhängig vom Bearbeitungsgrad der MM (auch nach dem Lesen) .
Netzwerkelement RSB (MMS Relay/Server B) -» Empfangsap- plikation UAB (MMS User Agent B) (bei der Benachrichtigung über die eingetroffene MMB) :
• Bedingungen zum Ausführen des Rückrufs:
- Rückruf nur vor dem Herunterladen, auch nach dem Versand einer Benachrichtigung. Diese Bedingung wird nur dann mitgeteilt, wenn die MM nicht heruntergeladen wurde .
- Rückruf nur, wenn die MM nicht gelesen wurde.
- Rückruf unabhängig vom Bearbeitungsgrad der MM (auch nach dem Lesen) .
Empfangsapplikation UAB (MMS User Agent B) - Netzwerkelement RSB (MMS Relay/Server B) (nach der Benachrichtigung) :
• Information, ob der bedingte Rückruf-Auftrag erfolg- reich ausgeführt werden konnte.
• Bei Mißerfolg entsprechende Meldung mit einer möglichen Begründung .
Netzwerkelement RSB (MMS Relay/Server B) - Netzwerkele- ment RSA (MMS Relay/Server A) (nur dann nötig, wenn Absender und Empfänger zu unterschiedlichen MMSEs gehören und wenn der Absender eine Rückmeldung angefordert hat) : • Information, ob der bedingte Rückruf-Auftrag erfolgreich ausgeführt werden konnte.
• Bei Mißerfolg entsprechende Meldung mit einer möglichen Begründung.
Netzwerkelement RSA (MMS Relay/Server A) -> Sendeapplikation UAA (MMS User Agent A) (beim Report) :
• Information, ob der bedingte Rückruf-Auftrag erfolgreich ausgeführt werden konnte . • Bei Mißerfolg entsprechende Meldung mit einer möglichen Begründung .
Anpassungen der WAP Nachrichten
Nachfolgend werden mögliche Modifikationen der WAP Nachrichten für das Dienstmerkmal „Rückruf" näher erläutert. Vorausgeschickt sei, daß in den WAP Spezifikationen der MMS User Agent dem MMS Client entspricht und anstatt des MMS Relay/Servers vom MMS Proxy/Relay die Rede ist, s. WAP-203-WSP, Version 4-May-2000 (s.o.). Wenn vorliegend von MMS User Agent die Rede ist, soll damit auch der MMS Client umfaßt sein. Gleichso verhält es sich mit den Begriffen MMS Relay/Server und MMS Proxy/Relay. Der Über- sichtlichkeit halber werden im Folgenden nur die Begriffe MMS User Agent und MMS Relay/Server verwendet .
Um das Dienstmerkmal „Rückruf" in die WAP Implementierung von MMS einzufügen, wird erfindungsgemäß eine Modifikati- on der WAP Nachrichten M-Send. req, M-Send. conf , M-
Notification . ind, M-NotifyResp . ind und M-Delivery. ind vorgeschlagen. In ihnen werden erfindungsgemäß verschiedene Kopf-Felder (Header-Felder) ergänzt bzw. modifi- ziert. Nach WAP-203-WSP (s.o.) besteht jedes Kopf-Feld aus einem kodierten Feld-Namen und einem kodierten Feld- Wert. Dabei existieren insgesamt vier Möglichkeiten den Feld-Wert zu kodieren, wobei das erste Oktett des Feld- Wertes über die Art und Länge der Kodierung entscheidet (siehe Tabelle 1) .
A.l. WAP Nachricht M-Send. req (von Sendeapplikation UAA zum Netzwerkelement RSA)
Der Absender einer MMA soll zum Ausdruck bringen, daß er seine MMA wieder zurückrufen möchte. Dies geschieht durch das Versenden einer weiteren MMB an den gleichen Empfänger. Zu diesem Zwecke kann in der WAP Nachricht M- Send. req, mit der die MMB verschickt wird, ein Kopf-Feld ergänzt werden, das die Identifikationsnummer derjenigen MM trägt, die der Absender zurückrufen möchte (ID1 von MMA aus Fig. 2) . Es wird vorgeschlagen, daß dieses Kopf- Feld den Namen X-Mms -Recall -ID und die hexadezimale Ko- dierung 0x7F (dezimal: 127) trägt. Message-IDs werden konform zum Encapsulation-Standard (WAP-209- MMSEncapsulation, Release 2000; Wireless Application Protocol; WAP Multimedia Messaging Service; Message Encapsu- lation; MMS Proposed SCD 1.0) vorzugsweise als sog. Text- String kodiert. Außerdem kann dem Absender einer MM mit Rückruf-Auftrag bevorzugt die Möglichkeit gegeben werden, eine Rückmeldung anfordern zu können. Dazu wird vorgeschlagen, ein Kopf-Feld mit der zweckmäßigen Bezeichnung X-M s -Request -Report und der hexadezimalen Kodierung 0x85 (dezimal: 133) in die WAP Nachricht M-Send. req einzuführen. Die Feld-Werte dieses Kopf-Feldes sind bevorzugt konform zum Encapsulation-Standard (s.o.) mit dem <Oc- tetl28> für „Rückmeldung wird gewünscht" und <Octetl29> für „Rückmeldung ist nicht erwünscht" kodiert.
Des weiteren wird vorgeschlagen, für den Fall eines be- dingten Rückrufs zusätzlich ein neues Kopf-Feld hinzuzufügen, das diese Bedingungen für das Ausführen des Rückrufbefehls übermittelt . Vorgeschlagen wird hierzu ein Kopf-Feld mit der beispielhaften Bezeichnung X-Mms- Recall -Cond, das vorzugsweise die hexadezimale Kodierung 0x86 (dezimal: 134) trägt. Dieses Kopf-Feld wird vorzugsweise mit dem <Octetl28> für den Rückruf nur vor Benachrichtigung ("Recall only before Notification"), mit dem <Octetl29> für Rückruf nur vor dem Herunterladen, auch nach dem Versand einer Benachrichtigung ("Recall only be- fore Downloading") , mit dem <Octetl30> für den Rückruf im Falle des Nichtlesens der MM ("Recall only before Rea- ding") und mit dem <0ctetl31> für Rückruf unabhängig vom Bearbeitungsgrad der MM - auch nach dem Lesen - ("Recall even after Reading") kodiert. Bei der Einführung weiterer Konditionen sind vorzugsweise entsprechende Feld-Werte hinzuzufügen. Alternativ zur Einführung des <Octetl31> kann auch vereinbart werden, daß ein Rückruf-Befehl ohne Kopf-Feld X-Mms -Recall -Cond für "Recall even after Reading" steht.
A.2 WAP Nachricht M-Send. conf (vom Netzwerkelement RSA zur Sendeapplikation UAA)
Mit dieser WAP Nachricht kann der Sendeapplikation UAA gemäß der vorliegenden Erfindung zusätzlich mitgeteilt werden, ob der Dienstanbieter A den Rückruf-Auftrag des Absenders (MMS User Agent A) angenommen hat . Dazu wird vorteilhafterweise vorgeschlagen, ein neues Kopf-Feld mit dem Namen X-Mms -Supported- Feature und der hexadezimalen Kodierung 0x83 (dezimal: 131) in die WAP Nachricht M- Send. conf einzufügen. Vorzugsweise werden als Feld-Werte konform zum Encapsulation-Standard (s.o.) das <Octetl28> für eine Auftragsbestätigung und das <Octetl30> für eine negative Rückmeldung benutzt (vergleiche Fig. 10) .
Außerdem kann der Sendeapplikation UAA erfindungsgemäß zusätzlich mitgeteilt werden, ob der Dienstanbieter A das bedingte Rückrufen unterstützt. Dafür wird hier vorgeschlagen, die Feld-Werte des X-Mms -Supported -Feature mit der hexadezimalen Kodierung 0x83 (dezimal: 131) beispielsweise mit dem Wert <Octetl31> zu ergänzen. Dieser Wert steht hierbei für die Unterstützung des bedingten Rückrufs. Falls die MMA noch auf dem Netzwerkelement RSA gespeichert ist und die Empfangsapplikation UAB noch nicht benachrichtigt wurde, wird die MM bevorzugt gelöscht und die Sendeapplikation UAA wird bevorzugt über diese Ausführung informiert. Dafür wird erfindungsgemäß vorgeschlagen, das Kopf-Feld X-Mms -Status zur WAP Nachricht M-Send. conf hinzuzufügen. Dabei wird vorzugsweise der neue Feld-Wert <Octetl38> für „Rückruf erfolgreich, vor Benachrichtigung" definiert. Des weiteren wird hier vorgeschlagen, den neuen Feld-Wert <Octetl42> für „Rück- ruf fehlgeschlagen, da Benachrichtigung gesendet wurde" festzulegen. Dieser kodierte Wert informiert die Sendeapplikation UAA, die den Fall 1 des bedingten Rückrufs (Rückruf nur vor der Benachrichtigung) ausgeführt haben wollte, daß das Löschen der MMA nicht erfolgen konnte, wenn die Benachrichtigung schon gesendet wurde. Dieser Fall kann auftreten, wenn die Sendeapplikation UAA und die Empfangsapplikation UAB demselben Netzwerkelement RS, hier also dem Netzwerkelement RSA, zugeordnet sind. A.3 WAP Nachricht M-Notification . ind (vom Netzwerkelement RSB zur Empfangsapplikation UAB)
Ist die Empfangsapplikation UAB bereits über eine zum
Download bereitliegende MMA informiert worden, kann gemäß der vorliegenden Erfindung in der WAP Nachricht M- Notification . ind ein neu definiertes Kopf-Feld mit der zweckmäßigen Bezeichnung X-Mms -Recalled-URI und der hexa- dezimalen Kodierung 0x80 (dezimal: 128) zum Einsatz kommen. Mit seiner Hilfe kann der Empfangsapplikation UAB mitgeteilt werden, daß die MMA mit dem angegebenen URI nicht mehr länger zum Herunterladen bereit liegt, weil sie der Absender wieder zurückgerufen hat. Der Feld-Wert dieses neu definierten Kopf-Feldes wird bevorzugt konform zum Encapsulation-Standard (s.o.) als Text-String kodiert .
Um die Empfangsapplikation UAB über den Zeitpunkt des Lö- schens informieren zu können, kann gemäß dieser Erfindung ein neu definiertes Kopf-Feld mit der zweckmäßigen Bezeichnung X-Mms -Date-of -Execution und der hexadezimalen Kodierung 0x84 (dezimal: 132) ergänzt werden. Die Feld- Werte für dieses Kopf-Feld werden bevorzugt nach dem En- capsulation-Standard (s.o.) als Long-Integer kodiert.
In der URI der Benachrichtigung kann gemäß der vorliegenden Erfindung auf den Speicherplatz einer Standard-Text- Nachricht (z. B.: „Diese MM wurde vom Absender wieder ge- löscht.") verwiesen werden, mit der das Netzwerkelement RSB auch eine Empfangsapplikation UAB über einen ausgeführten Rückruf-Auftrag informieren kann, wenn dieses das Rückruf-Dienstmerkmal nicht unterstützt (also die neuen Kopf-Felder nicht erkennt) und versucht, eine MM von dem in der Benachrichtigung ausgewiesenen Speicherplatz herunterzuladen.
Falls die MMA, die zurückgerufen werden soll, bereits an die Empfangsapplikation UAB ausgeliefert worden ist, kann erfindungsgemäß die WAP Nachricht M-Notification. ind das in Abschnitt A.l definierte Kopf-Feld mit dem Namen X- Mms-Recall -ID beinhalten. Die Empfangsapplikation UAB kann daraufhin umgehend mit Hilfe der Message-ID (ID2 aus Fig. 2) das Löschen der MMA einleiten (vorausgesetzt es unterstützt das Rückruf-Dienstmerkmal) .
Falls die zu löschende MMA von der Empfangsapplikation UAB heruntergeladen wurde, wird im Falle des bedingten Zurückrufens die Empfangsapplikation UAB bevorzugt über die Konditionen zum Löschen der MMA informiert . Hierfür wird bevorzugt das erfindungsgemäß neu definierte Kopf- Feld X-M s -Recall -Cond mit der hexadezimalen Kodierung 0x86 (dezimal: 134) eingesetzt. In diesem Fall werden nur die kodierten Werte <Octetl30> für den Rückruf im Falle des Nichtlesens der MM ("Rückruf vor dem Lesen") und <Oc- tetl31> für den Rückruf unabhängig vom Bearbeitungsgrad der MM ("Rückruf auch nach dem Lesen") benötigt. <0c- tetl28> für Rückruf nur vor Benachrichtigung und <Oc- tetl29> für Rückruf nur vor dem Herunterladen, auch nach dem Versand einer Benachrichtigung, werden hier nicht benötigt, da in diesem Beispiel in beiden Fällen das Löschen der MMA vor dem Versand der Benachrichtigung erfol- gen sollte.
A.4 WAP Nachricht M-NotifyResp . reg (von Empfangsapplikation UAB zum Netzwerkelement RSB) Gemäß der vorliegenden Erfindung wird vorteilhafterweise vorgeschlagen, in der WAP Nachricht M-NotifyResp . req optional ein neues Kopf-Feld einzufügen, mit dessen Hilfe dem Netzwerkelement RSB mitgeteilt werden kann, ob die Empfangsapplikation UAB die Meldung über einen erfolgreich ausgeführten Rückruf-Auftrag verstanden hat. Zu diesem Zweck wird vorzugsweise das aus anderen WAP Nachrichten bekannte Kopf-Feld X-Mms-Status benutzt und ein neuer Feld-Wert definiert: Es wird vorgeschlagen, daß das <Octetl36> die Bedeutung „Merkmal Rückruf unterstützt" hat.
Falls die rückzurufende MMA bereits an die Empfangsappli- kation UAB ausgeliefert worden war, wird gemäß einer vorteilhaften Variante der vorliegenden Erfindung vorgeschlagen, in der WAP Nachricht M-NotifyResp . req das iπv Encapsulation-Standard (s.o.) definierte Kopf-Feld X-Mms- Status einzufügen, mit welchem dem Netzwerkelement RS mitgeteilt werden kann, ob der Rückruf-Auftrag des Absenders erfolgreich auf der Empfangsapplikation UAB ausgeführt werden konnte oder nicht. Dazu ist allerdings auch hier eine Erweiterung dieses Kopf-Feldes notwendig: Die Rückmeldung wird bevorzugt mit den beiden neuen Feld- Werten <Octetl32 für „Rückruf-Auftrag wurde erfolgreich ausgeführt" und <Octetl33> für „Rückruf-Auftrag konnte nicht ausgeführt werden" realisiert.
Für den Fall des bedingten Rückrufs werden zusätzlich zu den Feld-Werten <Octetl32> für „Rückruf erfolgreich" und <Octetl33> für „Rückruf fehlgeschlagen", sowie zu den o- ben vorgeschlagenen Feld-Werten <Octetl38> für „Rückruf erfolgreich, vor Benachrichtigung" und <Octetl42> für „Rückruf fehlgeschlagen, da Benachrichtigung gesendet wurde" (s. A.2) folgende Feld-Werte vorgeschlagen:
- <Octetl40> für „Rückruf erfolgreich, bevor MM gelesen wurde"
- <0ctetl41> für „Rückruf erfolgreich, nachdem MM gelesen wurde"
- <Octetl44> für „Rückruf fehlgeschlagen, da MM gelesen wurde" - <Octetl45> für „Rückruf fehlgeschlagen, da MM gelöscht wurde".
Dank dieser Mitteilungen kann dann der Absender des Rückruf-Befehls über den genauen Ausgang seines Auftrages in- formiert werden.
A.5 WAP Nachricht M-Delivery. ind (vom Netzwerkelement RSA zur Sendeapplikation UAA)
Weiterhin wird vorgeschlagen, vorzugsweise das in Abschnitt A.4 erweiterte Kopf-Feld X-Mms-Status auch hier einzufügen. Mit seiner Hilfe kann dem Absender (Sendeapplikation UAA) mitgeteilt werden, ob sein Rückruf-Auftrag erfolgreich ausgeführt werden konnte oder nicht, wenn auch hier die neuen Feld-Werte <Octetl32> für „Rückruf- Auftrag wurde erfolgreich ausgeführt" und <Octetl33> für „Rückruf-Auftrag konnte nicht ausgeführt werden" benutzt werden (vergleiche Fig. 6) . Außerdem kann der Absender über das Datum der Ausführung seines Rückruf-Auftrages mit Hilfe des in Abschnitt A.3 definierten Kopf-Feldes mit der zweckmäßigen Bezeichnung X-Mms -Date-of-Execution informiert werden. Außerdem werden bevorzugt weitere neue Feld-Werte definiert :
- <Octetl39> für „Rückruf erfolgreich, vor dem Herun- terladen"
- <Octetl43> für „Rückruf fehlgeschlagen, da MM schon heruntergeladen wurde"
Somit ermöglichen die verschiedenen Feld-Werte des Kopf- Feldes X-Mms-Status innerhalb der WAP Nachricht M-
Delivery. ind eine Benachrichtigung des Absenders, ob und unter welchen Umständen sein Rückruf-Auftrag ausgeführt wurde .
Eine weitere Möglichkeit, den Absender eines bedingten
Rückrufbefehls über die Ausführung des Auftrags zu informieren, kann erfindungsgemäß durch die Definition eines neuen Kopf-Feldes realisiert werden, das bei den entsprechenden WAP Nachrichten eingesetzt wird. Vorgeschlagen wird dazu ein Kopf-Feld mit dem beispielhaften Namen X- M s -Recall -Status . Dieses Kopf-Feld kann in den oben beschriebenen Fällen als Ersatz für das erweiterte Kopf- Feld X-Mms-Status dienen. Letzteres kann dann weiterhin in der in WAP-209-MMSEncapsulation, Release 2000 (s.o.) definierten Form eingesetzt werden. Das neue Kopf-Feld X- Mms -Recall -Status beinhaltet vorzugsweise nur Informationen zur Ausführung des Rückruf-Aufträges . Für den X-M s - Recall -Status wird die hexadezimale Kodierung 0x88 (dezimal: 136) vorgeschlagen. Die möglichen Feld-Werte, welche die verschiedenen Ausführungsszenarien abdecken, sind beispielsweise :
- <Octetl28> für „Rückruf erfolgreich" - <Octetl29> für „Rückruf erfolgreich, vor Benachrichtigung"
- <Octetl30> für „Rückruf erfolgreich, vor dem Herunterladen" - <Octetl31> für „Rückruf erfolgreich, bevor MM gelesen wurde"
- <Octetl32> für „Rückruf erfolgreich, nachdem MM gelesen wurde"
- <Octetl33> für „Rückruf fehlgeschlagen" - <Octetl34> für „Rückruf fehlgeschlagen, da Benachrichtigung gesendet wurde"
- <Octetl35> für „Rückruf fehlgeschlagen, da MM heruntergeladen wurde"
- <Octetl36> für „Rückruf fehlgeschlagen, da MM gelesen wurde"
- <Octetl37> für „Rückruf fehlgeschlagen, da Nachricht gelöscht wurde"
- <Octetl38> für „Rückruf fehlgeschlagen, Nachricht nicht gefunden" - <Octetl39> für „Rückruf fehlgeschlagen, Nachricht weitergeleitet" .
Bei weiteren Gründen oder Konditionen können die Feld- Werte und Kodierungen entsprechend ergänzt werden.
B. DIENSTMERKMAL „ÄNDERN"
Ein Benutzer des MMS, der eine Multimedia Message MMA ab- geschickt hat und diese bereits verschickte MM später verändern möchte, kann gemäß dieser Erfindung eine neue MMB zusammen mit der Information verschicken, daß diese MMB eine zuvor verschickte MMA ändern, insbesondere ersetzen, soll. Unten stehende Ausführungen gelten ganz allgemein für Änderungen einer ersten Nachricht MMA, so auch z.B. für das nachträgliche Anhängen einer Datei an eine zuvor versendete MMA.
Eine Änderung von MMA kann dadurch realisiert werden, daß der Absender eine neue MMB verfaßt, die einen Änderungs- befehl beinhaltet, und diese an den gleichen Empfänger wie die zuvor verschickte MMA schickt. Zur Identifizierung der MMA wird vorteilhaferweise die IDl der zuvor verschickten und jetzt zu verändernden MMA benutzt. Die MMB mit der Änderungs-Information gelangt zunächst zum Netzwerkelement RSA. Hier wird überprüft, ob die MMA mit der IDl noch im Zuständigkeitsbereich (MMSEA) des Dienstanbieters A ist, oder ob sie sich schon im MMSEB des Dienstanbieters B befindet. Beides ist möglich, je nach dem, ob vom Absender der MMA ein Zeitpunkt für die frühestmögliche Auslieferung oder eine Gültigkeitsdauer an- gegeben worden ist. Sobald die MMA in einem MMSE der beteiligten MMS Dienstanbieter ausfindig gemacht worden ist, kann das Ändern der MMA durch die MMB vom zuständigen Netzwerkelement RS eingeleitet werden. Praktisch realisiert wird diese Aktion vorzugsweise durch das Löschen der alten MMA und das Weiterleiten der neuen MMB an den
Empfänger. Der MMS Dienstanbieter hat gemäß dieser Erfindung die Möglichkeit, die Empfangsapplikation UAB über einen gegebenenfalls ausgeführten Änderungs-Vorgang und/oder über das Datum der Ausführung des Änderungs- Vorgangs („diese MM wurde aktualisiert am...") in Kenntnis zu setzen. Hat der Empfänger (Empfangsapplikation UAB) der MMA noch keine Benachrichtigung über die MMA erhalten, etwa weil die MMB mit dem Änderungsauftrag das Netzwerkelement RSB vor der zu ändernden MMA erreicht, muß dieser auch nicht zwingend über eine vom Absender eingeleitete Änderungsaktion informiert werden. Statt dessen kann das Netzwerkelement RSB warten, bis es die zu ändernde MMA erhält, und ändert, insbesondere ersetzt, diese beim Eintreffen durch die MMB (vorausgesetzt, das MMS Netzwerkelement RSB unterstützt das Rückruf-Dienstmerkmal) . Der MMS Dienstanbieter kann nach dieser Erfindung die Empfangsapplikation UAB bei der Zustellung der MMB davon in Kenntnis setzen, daß sie eine vom Absender nachträglich geänderte MM ist und wann diese Änderung ausgeführt worden ist .
Falls die Empfangsapplikation UAB schon über die für ihn im MMSEB bereitliegende MMA mittels einer Benachrichtigung (Notification) informiert worden ist und sich die MMA noch im Zuständigkeitsbereich des Dienstanbieters B befinden sollte, kann gemäß dieser Erfindung die Empfangsapplikation UAB mit einer erneuten Benachrichtigung (Notification) davon in Kenntnis gesetzt werden, daß der Absender seine MMA nachträglich geändert hat und wann diese Änderung ausgeführt worden ist .
Sollte die MMA schon an den Empfänger ausgeliefert worden sein, so kann entweder die Empfangsapplikation UAB zunächst eine Benachrichtigung vom Dienstanbieter B erhalten, daß eine MMB zum Ersatz der MMA vorliegt, oder die MMB mit dem Änderungsauftrag kann der Empfangsapplikation UAB unmittelbar zugestellt werden. Unabhängig davon, ob die MMB im PUSH-Modus oder im PULL-Modus zugestellt worden ist, kann das Ändern, insbesondere das Ersetzen, der MMA durch die MMB direkt in der Empfangsapplikation UAB stattfinden, sofern dies das Ändern-Dienstmerkmal unterstützt. Je nach Implementierung dieses Dienstmerkmals im Endgerät, den Einstellungen des Benutzers, den Einstel- lungen des Dienstanbieters und/oder des Netzbetreibers kann das Ändern, insbesondere das Ersetzen, von MMA (und damit im Falle des PULL-Modus : zusätzlich das Anfordern von MMB) im Endgerät davon abhängig sein, ob die MMA bereits vom Empfänger „angefaßt" (z.B. geöffnet, gelesen, weitergeleitet, etc.) worden ist. Sinnvoll erscheint, insbesondere solche MMs automatisch (d.h. ohne Rückfrage mit dem Empfänger) zu ändern, welche noch nicht vom Empfänger „angefaßt" worden sind. Hat der Empfänger die MMA schon aus der Posteingangsbox genommen, weitergeleitet oder gelesen, so kann er zumindest noch darüber informiert werden, daß der Absender mit MMB die zuvor verschickte MMA ändern wollte.
Der Absender/Auftraggeber (Sendeapplikation UAA oder VAS- Applikation) kann gemäß einer vorteilhaften Variante der Erfindung über den Ausgang und das Datum der Ausführung der von ihm eingeleiteten Änderungsaktion informiert werden, wenn die beteiligten MMS Dienstanbieter dies unterstützen.
Die Identifikation von MMA auf der Empfangsapplikation UAB kann insbesondere anhand einer Nachrichtenreferenz erfolgen, welche vorzugsweise ein URI ist, unter dessen Speicherplatz eine Standard-Text-Nachricht des empfänger- seitigen Dienstanbieters B abgespeichert ist. Die URI setzt sich bevorzugt aus der Identifikationsnummer IDl von MMA oder aus von einem empfängerseitigen Netzwerkele- ment (inbesondere vom Netzwerkelement RSB) festgelegten zweiten Identifikationsnummer (ID2) zusammen.
Um das gerade beschriebene Dienstmerkmal Ändern, insbe- sondere Ersetzen, umsetzen zu können, wird gemäß der vorliegenden Erfindung vorgeschlagen, daß eine oder mehrere der folgenden Informationen zusätzlich zwischen den beteiligten Instanzen (Sendeapplikation UAA, Netzwerkelement RSA, Netzwerkelement RSB und Empfangsapplikation UAB) ausgetauscht werden:
Sendeapplikation UAA (MMS User Agent A) -» Netzwerkelement RSA (MMS Relay/Server A) (beim Versenden einer MM) :
• Kennzeichnung, daß es sich bei einer MMB um einen Än- derungsbefehl handelt .
• Identifikationsnummer der MMA, die geändert werden soll .
• Information, daß der Absender eine Rückmeldung über den Ausgang der von ihm eingeleiteten Änderungsaktion anfordert .
Netzwerkelement RSA (MMS Relay/Server A) — > Sendeapplikation UAA (MMS User Agent A) (bei der Bestätigung nach dem Versenden einer MM) : • Mitteilung des Dienstanbieters, ob dieser das Ändern- Dienstmerkmal unterstützt.
Netzwerkelement RSA (MMS Relay/Server A) -» Netzwerkelement RSB (MMS Relay/Server B) (nur dann nötig, wenn Ab- sender und Empfänger zu unterschiedlichen MMSEs gehören) :
• Kennzeichnung, daß es sich bei einer MMB um einen Änderungsbefehl handelt. • Identifikationsnummer der MMA, die geändert werden soll .
• Information, daß der Absender eine Rückmeldung über den Ausgang der von ihm eingeleiteten Änderungsaktion anfordert
Die Übermittlung der Informationen zwischen Netzwerkelement RSA und Netzwerkelement RSB ist davon abhängig, ob diese Informationen beim Versenden der MMB vorhanden waren.
Netzwerkelement RSB (MMS Relay/Server B) -» Empfangsapplikation UAB (MMS User Agent B) (bei der Benachrichtigung über eine eingetroffene MM) , vorzugsweise in einer Nachricht : • Information, daß der Absender eine zum Download bereitliegende MMA durch eine neue MMB geändert hat. Die Identifizierung beider MMs erfolgt anhand der Nachrichtenreferenzen (URIs) zu den betroffenen MMs.
• Information, wann die zum Herunterladen bereitliegende MMA durch die neue MMB geändert wurde . oder :
• Information, daß der Absender eine bereits zuvor ausgelieferte MMA durch eine neue MMB ändern, insbesondere ersetzen, möchte. Die Identifizierung der MMA, die ak- tualisiert wird, erfolgt anhand der individuellen Message ID und die Identifizierung der MMB, welche die MMA ändern, insbesondere ersetzen, soll, erfolgt anhand der Nachrichtenreferenz (URI) .
Empfangsapplikation UAB (MMS User Agent B) → Netzwerkelement RSB (MMS Relay/Server B) (nach der Benachrichtigung) : • Information, ob der Empfänger über den Anderungsauf- trag informiert werden konnte .
Wurde im Fall des PULL-Modus der Empfänger von einer vor- liegenden MMB mit Änderungsauftrag unterrichtet, so kann er diese mittels der bekannten Mechanismen vom Netzwerkelement RSB beziehen. Im Fall des PUSH-Modus wird das Herunterladen der MMB vom MMS Dienstanbieter und nicht vom Empfänger initiiert. In diesem Fall können die beiden vorigen Schritte, Benachrichtigung und deren Bestätigung, entfallen.
Netzwerkelement RSB (MMS Relay/Server B) -» Empfangsapplikation UAB (MMS User Agent B) (bei der Zustellung ei- ner MM) :
• Kennzeichnung, daß die MMB einen Änderungsauftrag enthält, der auf der Empfangsapplikation UAB ausgeführt werden soll .
• Information, welche bereits ausgelieferte MMA geän- dert, insbesondere ersetzt, werden soll. Die Identifizierung der MMA erfolgt anhand der individuellen nach- richtenidentifikationsnummer (Message ID) . oder:
• Information, daß die soeben ausgelieferte MMB eine nachträglich geänderte MM ist.
• Information, wann MMB vom Absender geändert worden ist .
Empfangsapplikation UAB (MMS User Agent B) → Netzwerk- element RSB (MMS Relay/Server B) (nach der Zustellung einer MM) :
• Information, ob der Änderungsauftrag erfolgreich ausgeführt werden konnte. • Information, ob der Anderungsauftrag automatisch durchgeführt wurde .
• Information, ob der Empfänger über den Änderungs-Vorgang informiert wurde (und/oder der Änderung zuge- stimmt hat) .
Netzwerkelement RSB (MMS Relay/Server B) — > Netzwerkelement RSA (MMS Relay/Server A) (nur dann nötig, wenn Absender und Empfänger zu unterschiedlichen MMSEs gehören und wenn der Absender eine Rückmeldung angefordert hat) :
• Information, ob der Änderungsauftrag erfolgreich ausgeführt werden konnte .
• Information, wann der Änderungsauftrag ausgeführt worden ist. • Information, ob der Änderungsauftrag automatisch durchgeführt wurde .
• Information, ob der Empfänger über die Änderung informiert wurde (und/oder der Änderung zugestimmt hat) .
• Information, ob eine bereits heruntergeladene MMA ge- ändert, insbesondere ersetzt, wurde oder aber die MMA vor dem Ändern noch nicht ausgeliefert worden war.
• Identifikationsnummer der MMA, die geändert, insbesondere ersetzt, wurde.
Netzwerkelement RSA (MMS Relay/Server A) → Sendeapplikation UAA (MMS User Agent A) (beim Bericht) :
• Information, ob der Änderungsauftrag erfolgreich ausgeführt werden konnte .
• Information, wann der Änderungsauftrag ausgeführt wor- den ist.
• Information, ob der Änderungsauftrag automatisch durchgeführt wurde . Information, ob der Empfänger über die Änderung informiert wurde (und/oder der Änderung zugestimmt hat) . Information, ob eine bereits heruntergeladene MMA geändert, insbesondere ersetzt, wurde oder aber die MMA vor der Änderung noch nicht ausgeliefert worden war. Identifikationsnummer der MMA, die geändert, insbesondere ersetzt, wurde.
Zusätzliches Dienstmerkmal: Bedingtes Ändern
Gemäß einer bevorzugten Ausführungsform der Erfindung kann der Absender des Änderungsbefehls Bedingungen zum Ausführen seines Wunsches angeben. Dabei legt die Sen- deapplikation UAA oder die VAS-Applikation fest, in welchem Fall die zuvor gesendete MM geändert wird. Das bedingte Ändern kann auch mit „Conditional Replace" bezeichnet werden.
Der Dienstanbieter kann erfindungsgemäß das Verwenden des Dienstmerkmals „Ändern" auf die eigene oder bestimmte Domänen der Dienstanbieter begrenzen. Dies kann beispielsweise anhand einer Identifizierung der Adresse des Empfängers (Rufnummer, Mailadresse oder weiteres) erfolgen. Eine weitere Möglichkeit wäre das Einsetzen einer zusätzlichen Kennzeichnung (Flag) in dem Ändern-Befehl .
Bevorzugt basiert das bedingte Aktualisieren auf der Bearbeitungsphase der zuvor gesendeten Nachricht (hier Mul- timedia Message MM) . Der Absender entscheidet in diesem Fall, in welchem Zustand der MM diese gelöscht werden soll. Mögliche Konditionen für das Ändern, insbesondere Ersetzen, sind: 1. Ändern der MM nur, wenn diese auf dem Server liegt und der Empfänger davon noch nicht in Kenntnis gesetzt wurde. Das Ändern erfolgt also nur, wenn noch keine Benachrichtigung (Notification) gesendet wurde.
2. Ändern der MM auch dann, wenn die Benachrichtigung
(Notification) schon gesendet, aber die MM noch nicht heruntergeladen wurde.
3. Ändern der MM, wenn der Empfänger diese noch nicht geöffnet bzw. gelesen hat. In diesem Fall kann das Ändern auch nach dem Herunterladen auftreten.
4. Ändern der MM unabhängig vom Bearbeitungsgrad der MM beim Empfänger. Das Ändern wird hier auch dann versucht, wenn der Empfänger die MM gelesen hat.
Bei der Realisierung dieses Dienstmerkmales wird vorteil- hafterweise eine Standardkondition „Default value" angenommen werden. Zum Beispiel kann vereinbart werden, daß die Standardkondition einem der oben beschriebenen vier Fälle entspricht. Diese Voreinstellung kann beispielsweise - solange nichts Genaues zum konditionellen Ausführen des Ändern-Befehls geäußert wurde - derart festgelegt werden, daß das Ändern zum Beispiel nur vor der Benachrichtigung erfolgen soll. Das System könnte auch so ausgelegt sein, daß ein solches Ändern nur vor dem Herunterladen der zu ändernden MM oder sogar nach dem Öffnen bzw. Lesen erfolgen sollte.
Im folgenden werden die Transaktionen zur Realisierung vom MM-Status-bedingten Dienstmerkmal „Ändern" behandelt. Eine bereits verschickte MMA kann also durch den Absender nachträglich wieder zurückgerufen werden, indem er eine neue MMB verfaßt, die einen bedingten Änderungsbefehl und einen neuen, für den Empfänger bestimmten Inhalt („Content/Message Body") beinhaltet. Diese neue Nachricht wird dem gleichen Empfänger wie die zuvor verschickte MMA gesendet. Als Änderungskennung wird die Identifikationsnummer (ID 1) der zuvor verschickten MMA benutzt (s.o). Die MMB mit der Änderungsinformation gelangt zunächst zum Netzwerkelement RSA des Absenders. Hier wird überprüft, ob die MMA mit der ID 1 noch im Zuständigkeitsbereich des Dienstanbieters A (MMSEA) ist, oder ob sie schon an das MMSEB des Dienstanbieters B weitergeleitet worden ist. Ersteres ist z.B. der Fall, wenn der vom Absender gewählte Zeitpunkt für die gewünschte Zustellung seiner MMA noch nicht erreicht worden ist; letzteres ist z.B. der Fall, wenn die MMA noch nicht ihre Gültigkeitsdauer überschritten hat und noch nicht der Empfangsapplikation UAB zugestellt worden ist.
Sobald die MMA in einem MMSE ausfindig gemacht wird, kann das Ändern von MMA durch MMB vom zuständigen Netzwerkelement RS eingeleitet werden. Falls der ursprüngliche Emp- fänger die an ihn adressierte MM an eine andere Adresse weitergeleitet hat, soll auch der Änderungsbefehl vom Netzwerkelement RS entsprechend weitergeleitet werden. Wenn das Netzwerkelement RSB nur die Information hat, daß die MM weitergeleitet wurde, ohne das Ziel zu wissen (beispielsweise, wenn der ursprüngliche Empfänger die an ihn adressierte MM an eine E-mail Adresse weitergeleitet hat) , kann der Absender des Änderungsbefehls über den Mißerfolg des Rückrufs aufgrund des Weiterleitens infor- miert werden. Aus Vertraulichkeitsgründen wäre auch möglich, den Mißerfolg der Ausführung zu melden, ohne in diesem Fall den Grund zu kommentieren.
Ein besonders günstiger Fall zum Ausführen des Änderungs- befehls liegt vor, wenn die MM noch auf dem Netzwerkelement RSA oder RSB liegt, und die Empfangsapplikation UAB noch nicht über diese Nachricht benachrichtigt wurde. Ein solcher Fall könnte zum Beispiel auftreten, wenn die MM auf Wunsch des Absenders ab einem bestimmten Zeitpunkt ausgeliefert werden sollte, der noch nicht eingetreten ist. Hier liegt die MM noch auf dem Netzwerkelement RSA des Absenders. Die MM kann auch auf dem Netzwerkelement RSB gespeichert sein, falls z.B. das Endgerät des Empfän- gers ausgeschaltet ist und die Gültigkeitsdauer der MM nicht überschritten wurde. In diesen beiden Fällen kann das Ändern der MM unabhängig der ausgewählten Löschkonditionen erfolgen. Alle vier oben beschriebenen Änderungs- konditionen decken nämlich diese Situation ab.
Falls die Empfangsapplikation UAB schon über die für ihn im MMSEB bereitliegende MMA mittels einer Benachrichtigung (Notification) informiert worden ist und sich die MMA noch im Zuständigkeitsbereich/Speicher des Dienstan- bieters B befinden sollte, kann erfindungsgemäß das Ändern nur in den oben mit 2, 3 und 4 numerierten Fällen erfolgen. Für den Fall 1 des bedingten Änderns erhält der Absender vorzugsweise eine Meldung, daß der Empfänger schon über die zuvor gesendete MM informiert wurde und die Änderung nicht vorgenommen werden konnte. Für die weiteren Fälle (2, 3 und 4) kann die Empfangsapplikation UAB mit einer erneuten Benachrichtigung (Notification) davon in Kenntnis gesetzt werden, daß die MMA durch die MMB geändert wurde und somit nicht mehr zum Herunterladen bereit liegt. Statt dessen kann der Empfänger die neue MMB anfordern.
Sollte die MMA schon an den Empfänger ausgeliefert worden sein, so kann das Ändern nur für den Fall 4 (Ändern, unabhängig vom Bearbeitungsgrad) und unter Umständen für den Fall 3 (Ändern, nur wenn MM noch nicht geöffnet/gelesen wurde) erfolgen. Die Empfangsapplikation UAB wird - nur für die Fälle 3 und 4 - vorzugsweise mit einer neuen Benachrichtigung (Notification) davon in Kenntnis gesetzt, daß der Absender die MMA ändern möchte. Diese Benachrichtigung beinhaltet bevorzugt die Konditionen des Änderns. Das Aktualisieren der MMA kann folglich direkt im MMS User Agent B stattfinden, sofern dieses das
Dienstmerkmal „Ändern" unterstützt. Wenn es sich um den Fall 3 handelt, wird die MM bevorzugt nur dann geändert, wenn das Endgerät feststellt, daß die MM nicht geöffnet bzw. gelesen wurde. Für den Fall 4 wird das Ändern unab- hängig davon getriggert. Für die Fälle 1 (Ändern vor der Benachrichtigung) und 2 (Ändern nur vor dem Herunterladen) kann das Ändern nicht erfolgen. Der Absender erhält bevorzugt eine Rückmeldung mit der Information, daß die MM nicht geändert werden konnte, da eine Benachrichtigung schon verschickt wurde (Fall 1) oder weil die MM schon heruntergeladen wurde (Fall 2) .
Eine weitere Möglichkeit zur Realisierung des Ändernvor- gangs ist erfindungsgemäß das Zustellen der MMB mit der Änderungsinformation bis zur Empfangsapplikation UAB. Das Ändern wird dann im Endgerät des Empfängers durch die MMB und nicht durch die aus der MMB entstehende Benachrichtigung (Notification) ausgelöst. Dieser Fall wird im weite- ren nicht detaillierter behandelt.
Der Auftraggeber der Änderung (Sendeapplikation UAA oder VAS-Applikation) wird bevorzugt in allen beschriebenen Fällen über den Ausgang und ggf. das Datum der Ausführung der von ihm eingeleiteten Aktion informiert, insbesondere wenn er dies anfordert und wenn die beteiligten MMS Dienstanbieter dies ermöglichen.
Da es sich beim bedingten Ändern um eine MM handelt, welche die Empfangsapplikation UAB erreichen soll, behandeln MMSEs (Multimedia Messaging Service Environments) , die dieses Dienstmerkmal nicht unterstützen, die neue MMB vorzugsweise als einfache MM. Sie wird also der Empfangs- applikation UAB - ohne Ersetzung der MMA - als neue MM erreichen. Auch darüber wird der Absender vorzugsweise informiert .
Um das gerade beschriebene Dienstmerkmal „Bedingtes Än- dern" umsetzen zu können, wird erfindungsgemäß vorgeschlagen, daß eine oder mehrere der folgenden Informationen zusätzlich zwischen den beteiligten Instanzen (Sendeapplikation UAA, Netzwerkelement RSA, Netzwerkelement RSB und Empfangsapplikation UAB) ausgetauscht werden. Als Basis dienen die aktuellen 3GPP Spezifikationen 3G TS 140 version 4.0.1 (s.o.) sowie 3G TS 23.140 Version 4.0.0 (s.o.) und WAP Spezifikationen WAP-209-MMSEncapsulation; Release 2000 (s.o.), WAP-203 WSP (s.o.) und Report of the 3GPP TSG-T2 SWG3 (s.o.) . Im Folgenden wird näher auf die Unterschiede und Ergänzungen im Vergleich zu dem unbedingten Ändern eingegangen:
Sendeapplikation UAA (MMS User Agent A) -» Netzwerkele- ment RSA (MMS Relay/Server A) (beim Versenden einer MM) :
• Bedingungen zum Ausführen des Änderns :
- Ändern nur vor Benachrichtigung.
- Ändern nur vor dem Herunterladen, auch nach dem Ver- sand einer Benachrichtigung.
- Ändern nur, wenn die MM nicht geöffnet/ gelesen wurde.
- Ändern unabhängig vom Bearbeitungsgrad der MM (auch nach dem Lesen der MMA) .
Netzwerkelement RSA (MMS Relay/Server A) — Sendeapplikation UAA (MMS User Agent A) (bei der Bestätigung nach dem Versenden einer MM) :
• Mitteilung des Dienstanbieters, ob dieser das bedingte Ändern-Merkmal unterstützt. Hier könnte das System zwischen der Unterstützung vom „Ändern" und „Bedingtes Ändern" unterscheiden.
Netzwerkelement RSA (MMS Relay/Server A) —> Netzwerkele- ment RSB (MMS Relay/Server B) (nur dann nötig, wenn Absender und Empfänger zu unterschiedlichen MMSEs gehören) :
• Bedingungen zum Ausführen des Ersetzens:
- Ändern nur vor Benachrichtigung.
- Ändern nur vor dem Herunterladen, auch nach dem Ver- sand einer Benachrichtigung.
- Ändern nur, wenn die MM nicht gelesen wurde.
- Ändern unabhängig vom Bearbeitungsgrad der MM (auch nach dem Lesen) .
Netzwerkelement RSB (MMS Relay/Server B) -» Empfangsapplikation UAB (MMS User Agent B) (bei der Benachrichtigung über der eingetroffenen MMB) : • Bedingungen zum Ausführen des Änderns:
- Ändern nur vor dem Herunterladen, auch nach dem Versand einer Benachrichtigung. Diese Bedingung wird nur dann mitgeteilt, wenn die MM nicht heruntergeladen wurde .
- Ändern nur, wenn die MM nicht gelesen wurde.
- Ändern unabhängig vom Bearbeitungsgrad der MM (auch nach dem Lesen) .
Empfangsapplikation UAB (MMS User Agent B) — > Netzwerkelement RSB (MMS Relay/Server B) (nach der Benachrichtigung) :
• Information, ob der bedingte Ändern-Auftrag erfolgreich ausgeführt werden konnte . • Bei Mißerfolg entsprechende Meldung mit einer möglichen Begründung.
Netzwerkelement RSB (MMS Relay/Server B) — Netzwerkelement RSA (MMS Relay/Server A) (nur dann nötig, wenn Ab- sender und Empfänger zu unterschiedlichen MMSEs gehören und wenn der Absender eine Rückmeldung angefordert hat) :
• Information, ob der bedingte Ändern-Auftrag erfolgreich ausgeführt werden konnte.
• Bei Mißerfolg entsprechende Meldung mit einer möglichen Begründung.
Netzwerkelement RSA (MMS Relay/Server A) → Sendeapplikation UAA (MMS User Agent A) (beim Bericht) :
• Information, ob der bedingte Ändern-Auftrag erfolgreich ausgeführt werden konnte .
• Bei Mißerfolg entsprechende Meldung mit einer möglichen Begründung . Anpassungen der WAP Nachrichten
Nachfolgend werden mögliche Modifikationen der WAP Nachrichten für das Ändern-Dienstmerkmal näher erläutert . Die Anpassungen und Zuweisungen sind beispielhaft und können durchaus variiert werden: Um das Ändern-Dienstmerkmal in die WAP Implementierung von MMS einzuführen, wird gemäß der vorliegenden Erfindung eine Modifikation der WAP
Nachrichten M-Send. req, M-Send. conf, M-Notification . ind, M-NotifyResp . req, M-Retrieve . conf , M-Acknowledge . ind und M-Delivery. ind vorgeschlagen. In ihnen werden vorteilhafterweise analog zum Vorgehen in Abschnitt A (Dienst- merkmal Rückruf) verschiedene Kopf-Felder ergänzt bzw. modifiziert. Im folgenden wird wieder von MMS User Agent bzw. MMS Proxy/Server gesprochen, womit auch MMS Client bzw. MMS Proxy/Relay gemeint ist.
B.l WAP Nachricht M-Send. req (von Sendeapplikation UAA zum Netzwerkelement RSA)
Der Absender einer MM soll zum Ausdruck bringen können, daß er nachträglich seine bereits verschickte MMA durch eine neue MMB ändern, insbesondere ersetzen, möchte. Bevorzugt wird zu diesem Zweck in der WAP Nachricht M- Send . req, mit der die neue MMB verschickt wird, ein weiteres Kopf-Feld ergänzt, das die Identifikationsnummer derjenigen MM trägt, die durch MMB geändert, insbesondere ersetzt, werden soll (nämlich IDl von MMA aus Fig. 2) . Es wird vorgeschlagen, daß dieses Kopf-Feld den Namen X-Mms - Replace-ID und die hexadezimale Kodierung 0x81 (dezimal: 129) trägt. Message-IDs werden konform zum Encapsulation- Standard (s.o.) vorzugsweise als Text-String kodiert. Außerdem wird dem Absender einer MM mit Änderungsauftrag vorzugsweise die Möglichkeit gegeben, eine Rückmeldung anzufordern. Dazu wird vorgeschlagen, das in Abschnitt A.l definierte Kopf-Feld mit der zweckmäßigen Bezeichnung X-Mms-Request -Report mit der hexadezimalen Kodierung 0x85 (dezimal: 133) in die WAP Nachricht M-Send. req einzuführen. Die Feld-Werte dieses Kopf-Feldes werden vorteilhafterweise konform zum Encapsulation-Standard (s.o.) mit dem <0ctetl28> für „Rückmeldung wird gewünscht" und <Oc- tetl29> für „Rückmeldung ist nicht erwünscht" kodiert.
Weiterhin wird vorgeschlagen, zusätzlich ein neues Kopf- Feld hinzuzufügen, das Bedingungen des Ausführens des Än- derungsbefehls übermittelt. Vorgeschlagen wird hierzu ein Kopf-Feld mit der beispielhaften Bezeichnung X-Mms- Replace-Cond, das vorzugsweise die hexadezimale Kodierung 0x87 (dezimal: 135) auf eist. Dieses Kopf-Feld wird vorzugsweise mit dem <Octetl28> für das Ersetzen nur vor Be- nachrichtigung ("Replace only before Notification"), mit dem <Octetl29> für das Ersetzen nur vor dem Herunterladen, auch nach dem Versand einer Benachrichtigung ("Replace only before Downloading") , mit dem <Octetl30> für das Ersetzen im Falle des Nichtlesens ("Replace only before Reading") und mit <0ctetl31> für das Ersetzen unabhängig vom Bearbeitungsgrad der MM - auch nach dem Lesen - ("Replace even after Reading") kodiert. Bei der Einführung weiterer Konditionen sind vorzugsweise entsprechende Feld- erte hinzuzufügen.
B . 2 WAP Nachricht M-Send . conf (vom Netzwerkelement RSA zur Sendeapplikation UAA) Mit dieser WAP Nachricht kann der Sendeapplikation UAA gemäß der vorliegenden Erfindung mitgeteilt werden, ob der Dienstanbieter A dem Änderungsauftrag des Absenders (Sendeapplikation UAA) entsprechend gehandelt hat bzw. handeln konnte. Dazu wird vorgeschlagen, das in Abschnitt A.2 zum Zwecke des Rückruf-Dienstmerkmals eingeführte Kopf-Feld mit der zweckmäßigen Bezeichnung X-Mms- Supported- Feature vorzugsweise auch hier zu nutzen. Als Feld-Werte kommen dann entweder das <Octetl29> für „Än- dern-Merkmal unterstützt" oder das <Octetl30 > für „keine Unterstützung" zum Einsatz.
Des weiteren wird für den Fall des bedingten Änderns vorgeschlagen, die Feld-Werte des X-Mms -Supported-Feature beispielsweise mit der hexadezimalen Kodierung 0x83 (dezimal: 131) mit dem Wert <Octetl32> zu ergänzen. Dieser Wert steht für die Unterstützung des bedingten Änderns bzw. Ersetzens. Falls die MMA noch auf dem Netzwerkelement RSA gespeichert ist, und die Empfangsapplikation UAB noch nicht benachrichtigt wurde, wird die MM geändert und Sendeapplikation UAA wird vorzugsweise über diese Ausführung informiert. Dafür wird erfindungsgemäß vorgeschlagen, das Kopf-Feld X-Mms-Status zur WAP Nachricht M- Send . conf hinzuzufügen. Dabei wird vorzugsweise der neue Feld-Wert <Octetl48> für „Ändern erfolgreich, vor Benachrichtigung" definiert. Des weiteren wird hier vorgeschlagen, den neuen Feld-Wert <Octetl52> für „Ändern fehlgeschlagen, da Benachrichtigung gesendet wurde" festzulegen. Dieser kodierte Wert informiert die Sendeapplikation UAA, die den Fall 1 des bedingten Ersetzens (Ändern nur vor der Benachrichtigung) ausgeführt haben wollte, daß die Aktualisierung der MMA nicht erfolgen konnte, da die Benachrichtigung schon gesendet wurde. Dieser Fall kann auftreten, wenn Sendeapplikation UAA und Empfangsapplika- tion UAB dem selben Netzwerkelement RS, also Netzwerkelement RSA, zugeordnet sind. Des weiteren werden vorzugsweise weitere neue Feld-Werte definiert: <Octetl49> für „Ändern erfolgreich, vor dem Herunterladen", und
<Octetl53> für „Ändern fehlgeschlagen, da MM heruntergeladen wurde".
Der letztere Fall kann auftreten, wenn der Absender den Fall 2 des bedingten Änderns (Ändern vor dem Herunterladen) verlangt hat.
B.3 WAP Nachricht M-Notification . ind (vom Netzwerkelement RSB zur Empfangsapplikation UAB)
Nach dieser Erfindung wird in der WAP Nachricht M- Notification . ind vorzugsweise ein neu definiertes Kopf- Feld mit der zweckmäßigen Bezeichnung X-Mms -Replaced-URI und der hexadezimalen Kodierung 0x82 (dezimal: 130) er- gänzt. Mit seiner Hilfe kann der Empfangsapplikation UAB nach einer bereits erfolgten Benachrichtigung mitgeteilt werden, daß die MMA unter dem angegebenen URI nicht mehr länger zum Herunterladen bereit liegt, weil sie der Absender durch eine neu MMB mit einem anderen URI ersetzt hat. Der Feld-Wert dieses neu definierten Kopf-Feldes wird vorteilhafterweise konform zum Encapsulation- Standard (s.o.) als Text-String kodiert. Um die Empfangsapplikation UAB über den Zeitpunkt der Aktualisierung informieren zu können, wird gemäß einer vorteilhaften Vari- ante der Erfindung das in Abschnitt A.3 neu definierte
Kopf-Feld mit der zweckmäßigen Bezeichnung X-Mms -Date-of- Execution ergänzt. Wenn sich die zu ändernde, insbesondere zu ersetzende, MMA schon auf der Empfangsapplikation UAB befindet, wird vorteilhafterweise in der WAP Nachricht M- Notification . ind das in Abschnitt B.l neu definierte Kopf-Feld mit der zweckmäßigen Bezeichnung X-Mms -Replace - ID und der hexadezimalen Kodierung 0x81 (dezimal: 129) ergänzt. Die Empfangsapplikation UAB erkennt daran, daß die zum Herunterladen bereitliegende MMB einen Änderungs- befehl für die MMA mit der entsprechenden Nachrichten- Identifikationsnummer beinhaltet. Das Herunterladen der MMB kann daraufhin je nach den Einstellungen des Benutzers, den Einstellungen des MMS Dienstanbieters und/oder des Netzbetreibers entweder im PUSH-Modus oder im PULL- Modus eingeleitet werden.
Wie erwähnt, informiert die WAP Nachricht M- Notification . ind die Empfangsapplikation UAB über das Eintreffen der Nachricht MMB, die MMA ändern, insbeson- der ersetzen, soll. Für das bedingte Ändern muß die Emp- fangsapplikation UAB über die Konditionen des Änderns informiert werden. Hierfür wird vorzugsweise das neu definierte Kopf-Feld X-Mms -Replace -Cond mit der hexadezimalen Kodierung 0x87 (dezimal: 135) eingesetzt. In diesem Fall werden nur die kodierten Werte <Octetl30> für das Ändern, nur wenn die MM nicht gelesen wurde, und <Octetl31> für das Ändern unabhängig vom Bearbeitungsgrad der MM (auch nach dem Lesen) benötigt. <Octetl28> für das Ändern nur vor Benachrichtigung und <Octetl29> für das Ändern nur vor dem Herunterladen - auch nach dem Versand einer Be- nachrichtigung - werden hier nicht benötigt, da in beiden Fällen das Ändern der MM vor dem Versand der Benachrichtigung erfolgen sollte. Falls die Bedingungen zum Ändern der MMA erfüllt sind, kann diese MM schon gelöscht wer- den, auch bevor MMB in der Empfangsapplikation UAB ankommt .
B.4 WAP Nachricht M-NotifyResp . ind (von Empfangsapplika- tion UAB zum Netzwerkelement RSB)
Erfindungsgemäß wird vorgeschlagen, in der WAP Nachricht M-NotifyResp . ind das im Encapsulation-Standard (s.o.) definierte Kopf-Feld X-Mms-Status einzufügen. Damit dem Netzwerkelement RS mitgeteilt werden kann, ob der Änderungsauftrag des Absenders im PUSH-Modus erfolgreich ausgeführt werden konnte oder nicht, ist auch hier eine Erweiterung dieses Kopf-Feldes (analog zu dem Vorgehen in Abschnitt A, Dienstmerkmal Rückruf) notwendig: Die Rück- meidung wird in dieser Erfindung vorzugsweise mit den beiden neuen Feld-Werten <0ctetl34> für „Änderungsauftrag wurde erfolgreich ausgeführt" und <0ctetl35> für „Änderungsauftrag konnte nicht ausgeführt werden" realisiert.
Zusätzlich zu den zuvor vorgeschlagenen Feld-Werten <0c- tetl34> und <0ctetl35> sowie dem oben vorgeschlagenen Feld-Wert <0ctetl48> für „Ändern erfolgreich, vor Benachrichtigung" und <0ctetl52> für „Ändern fehlgeschlagen, da Benachrichtigung gesendet wurde" werden folgende Feld- Werte vorgeschlagen:
- <Octetl50> für „Ändern erfolgreich, bevor MM gelesen wurde"
- <Octetl51> für „Ändern erfolgreich, nachdem MM gele- sen wurde"
- <Octetl54> für „Ändern fehlgeschlagen, da MM gelesen wurde"
- <Octetl55> für „Replace fehlgeschlagen, da MM gelöscht wurde" .
Dank dieser Mitteilungen kann dann der Absender des Änderungsbefehls über den genauen Ausgang seines Auftrages informiert werden.
B.5 WAP Nachricht M-Retrieve . conf (vom Netzwerkelement RSB zur Empfangsapplikation UAB)
Wenn die zu ändernde MMA schon im MMSEB durch MMB geändert werden konnte, bietet sich gemäß der vorliegenden Erfindung an, in der WAP Nachricht M-Retrieve. conf , mit der MMB an die Empfangsapplikation UAB übermittelt wird, vorzugsweise das im Encapsulation-Standard (s.o.) definierte erweiterte Kopf-Feld X-Mms-Status mit dem Feld-Wert <Oc- tetl34> für „Ändern erfolgreich" und das in Abschnitt A.3 neu definierte Kopf-Feld mit der zweckmäßigen Bezeichnung X-Mms-Date-of-Execution einzufügen. Dadurch kann das Netzwerkelement RSB der Empfangsapplikation UAB signali- sieren, daß die MMB eine nachträglich geänderte MM ist und wann der Änderungsauftrag des Absenders im Zuständigkeitsbereich des MMSEB ausgeführt worden ist .
Wenn sich die zu ändernde MMA schon auf der Empfangsap- plikation UAB befindet, ist es gemäß der vorliegenden Erfindung vorteilhaft, in der WAP Nachricht M-Retrieve . conf ebenfalls das in Abschnitt B.l definierte Kopf-Feld mit dem Namen X-Mms -Replace -ID zu ergänzen. Mit ihm kann das Ändern der MMA auf der Empfangsapplikation UAB mit Hilfe der Message-ID eingeleitet werden (s. Fig. 2), falls die Empfangsapplikation UAB das Ändern-Dienstmerkmal unterstützt. Andernfalls wird dem Empfänger dadurch nur ange- zeigt, daß der Absender die MMA durch die neue MMB ändern wollte.
Im Falle des bedingten Änderns wird vorgeschlagen, das oben neu definierte Kopf-Feld X-M s -Replace-Cond vorteilhafterweise dieser Nachricht zuzufügen. Dabei können die Feld-Werte <Octetl30> für „Ersetzen nur, wenn die MM nicht gelesen wurde" und <Octetl31> für „Ersetzen unabhängig vom Bearbeitungsgrad der MM", d.h. auch nach dem Lesen, verwendet werden. Damit wird die Empfangsapplikation UAB informiert, in welchem Fall die alte MM ersetzen werden soll .
B.6 WAP Nachricht M-Äcknowledge . ind (von Empfangsappli- kation UAB zum Netzwerkelement RSB)
Gemäß dieser Erfindung wird in einer vorteilhaften Weiterbildung vorgeschlagen, in der WAP Nachricht M- Acknowledgement . ind das im Encapsulation-Standard (s.o.) definierte Kopf-Feld X-Mms-Status einzufügen. Damit dem Netzwerkelement RS mitgeteilt werden kann, ob der Änderungsauftrag des Absenders im PULL-Modus erfolgreich ausgeführt werden konnte oder nicht, ist auch hier eine Erweiterung dieses Kopf-Feldes (analog zu dem Vorgehen in Abschnitt A, Dienstmerkmal Rückruf) notwendig: Die Rückmeldung wird in dieser Erfindung vorteilhaf erweise mit den beiden neuen Feld-Werten <0ctetl34> für „Änderungsauftrag wurde erfolgreich ausgeführt" und <Octetl35> für „Änderungsauftrag konnte nicht ausgeführt werden" reali- siert.
Des weiteren können die Feld-Werte <Octetl49>, <θc- tetl50>, <Octetl51>, <Octetl53>, <0ctetl54> und <Oc- tetl55> verwendet werden (s.o.).
B.7 WAP Nachricht M-Delivery. ind (von Netzwerkelement RSA zur Sendeapplikation UAA)
Weiterhin wird vorgeschlagen, das in den Abschnitten B.4 bzw. B.6 erweiterte Kopf-Feld X-Mms-Status auch hier einzufügen. Mit seiner Hilfe kann dem Absender (Sendeapplikation UAA) mitgeteilt werden, ob sein Änderungsauf- trag erfolgreich ausgeführt werden konnte oder nicht, wenn auch hier die oben genannten neuen Feld- erte benutzt werden, wobei ein Teil oder alle oben beschriebenen Werte auftreten können. Außerdem wird der Absender vorteilhafterweise über das Datum der Ausführung seines Än- derungsaufträges mit Hilfe des in Abschnitt A.3 definierten Kopf-Feldes mit der zweckmäßigen Bezeichnung X-Mms - Date-of-Execution informiert.
Eine weitere Möglichkeit, den Absender eines bedingten Änderungs-Befehls über die Ausführung des Änderungsauftrags zu informieren, kann erfindungsgemäß durch die Definition eines neuen Kopf-Feldes realisiert werden, das bei den entsprechenden WAP Nachrichten eingesetzt wird. Vorgeschlagen wird dazu ein Kopf-Feld mit dem beispiel- haften Namen X-Mms -Replace -Status . Dieses Kopf-Feld kann in den oben beschriebenen Fällen als Ersatz für das erweiterte Kopf-Feld X-Mms-Status dienen. Letzteres kann weiter in der in WAP-209-MMSEncapsulation, Release 2000 (s.o.) definierten Form eingesetzt werden. Das neue Kopf- Feld beinhaltet vorzugsweise nur Informationen zur Ausführung des Ändern-Aufträges . Für den X-Mms -Replace- Status wird die hexadezimalen Kodierung 0x89 (dezimal: 137) vorgeschlagen. Die möglichen Feld-Werte, welche die verschiedenen AusführungsSzenarien abdecken, sind beispielsweise:
- <Octetl28> für „Ändern erfolgreich" - <Octetl29> für „Ändern erfolgreich, vor Benachrichtigung"
- <Octetl30> für „Ändern erfolgreich, vor dem Herunterladen"
- <Octetl31> für „Ändern erfolgreich, bevor MM gelesen wurde"
- <Octetl32> für „Ändern erfolgreich, nachdem MM gelesen wurde"
- <Octetl33> für „Ändern fehlgeschlagen"
- <Octetl34> für „Ändern fehlgeschlagen, da Benachrich- tigung gesendet wurde"
- <Octetl35> für „Ändern fehlgeschlagen, da MM heruntergeladen wurde"
- <Octetl36> für „Ändern fehlgeschlagen, da MM gelesen wurde" - <Octetl37> für „Ändern fehlgeschlagen, da Nachricht gelöscht wurde"
- <Octetl38> für „Ändern fehlgeschlagen, Nachricht nicht gefunden"
- <Octetl39> für „Ändern fehlgeschlagen, Nachricht weitergeleitet" .
Bei weiteren Gründen oder Konditionen können die Feld- Werte und Kodierungen entsprechend ergänzt werden.
Eine weitere Alternative zum X-Mms-Replace-Status zusammen mit dem oben eingeführten Kopf-Feld X-Mms -Replace- Status wäre erfindungsgemäß ein neues Kopf-Feld, das für die Rückmeldung zur Ausführung des Änderungs- und des Rückrufbefehls eingesetzt werden kann. Vorgeschlagen wird hierfür ein Kopf-Feld mit dem beispielhaften Namen X-Mms - Operation- Status . Dieses Kopf-Feld kann die hexadezimale Kodierung 0x90 (dezimal: 138) haben, zusammen mit folgenden Feld-Werten:
- <Octetl28> für „Ausführung erfolgreich"
- <Octetl29> für „Ausführung erfolgreich, vor Ben- achrichtigung"
- <Octetl30> für „Ausführung erfolgreich, vor dem Herunterladen"
- <0ctetl31> für „Ausführung erfolgreich, bevor MM gelesen wurde" - <Octetl32> für „Ausführung erfolgreich, nachdem MM gelesen wurde"
- <Octetl33> für „Ausführung fehlgeschlagen"
- <0ctetl34> für „Ausführung fehlgeschlagen, da Benachrichtigung gesendet wurde" - <Octetl35> für „Ausführung fehlgeschlagen, da MM heruntergeladen wurde"
- <Octetl36> für „Ausführung fehlgeschlagen, da MM gelesen wurde"
- <Octetl37> für „Ausführung fehlgeschlagen, da Nachricht gelöscht wurde"
- <Octetl38> für „Ausführung fehlgeschlagen, Nachricht nicht gefunden"
- <Octetl39> für „Ausführung fehlgeschlagen, Nachricht weitergeleitet" .
Fig. 5 zeigt noch einmal sieben, vorteilhafterweise neu eingeführte Kopf-Felder einschließlich der Kodierungen von Feld-Name und Feld-Wert. In Fig. 6 ist das um neue Feld-Werte erweiterte Kopf-Feld X-Mms-Status dargestellt. In den Fig. 7 und 8 sind die Kopf-Felder der alternativen Realisierungsmöglichkeiten (Ausführungsbeispiele 3 und 4, s.u.) dargestellt. Die entsprechenden Ergänzungen in den Kopf-Feldern der entsprechenden WAP Nachrichten sind in den Tabellen 2 bis 8 am Ende der Beschreibung aufgelistet. Es ist durchaus möglich, daß auch nur einzelne Ergänzungen in diesen Kopf-Feldern vorgenommen werden.
Für den Fall der bedingten Manipulation zeigt Fig. 9 die neu eingeführten Kopf-Felder Mms -Recall -Cond, X-Mms- Replace-Cond, X-Mms -Recall - Status, X-Mms-Replace-Status und X-Mms -Operation- Status einschließlich der Kodierungen von Feld-Name und Feld-Wert. In Fig. 10 ist das um neue Feld-Werte erweiterte Kopf-Feld X-Mms -Supported- Feature dargestellt. Das in Fig. 6 dargestellte Kopf-Feld X-M s- Status enthält ebenfalls auf die bedingte Manipulation bezogene neue Feld-Werte.
C. BINÄRE KODIERUNG
C.l Ohne Bedingung für Rückruf bzw. Ändern
In den folgenden Ausführungsbeispielen wird detailliert auf die in den WAP Nachrichten benutzten Kopf-Felder eingegangen, ohne daß zunächst Bedingungen für den Rückruf bzw. das Ändern einer ersten Nachricht vorgesehen sind. Dabei wird beispielhaft folgendes Szenario angenommen: Sendeapplikation UAA verschickt eine MMA bestehend aus einem Text und einem JPEG-Bild an einen Empfänger und will diese später zurückrufen (Beispiel 1) bzw. durch ei- ne neue MMB ersetzen (Beispiel 2) .
M-Send.req (Sendeapplikation UAA -» Netzwerkelement RSA)
X-Mms-Message-Type: m-send-req X-Mms -Transaction-ID: 10 X-Mms- Versi on: 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 - Trans fer-Encodin : quoted -prin tabl e
Hallo xyz, hier ist die gewünschte Agenda für unser nächstes Meeting. Gruß, abc
__=_NextPart_000_ Content-Type; image/jpeg; name="agenda. jpg"
Content -Trans fer-Encoding : base64 Content-ID: <1725782>
__=_NextPart_000_ - -
Die Sendeapplikation UAA des Benutzers mit der Adresse ajbc@siej7iens.de verschickt eine MMA bestehend aus einem Text (MIME content type „text/piain") und einem JPEG-Bild (MIME content type „image/jpeg") an die Empfangsapplikation UAB des Benutzers mit der Adresse xyz@siemens.de. Die zu diesem Zweck benutzte WAP Nachricht M-Send . req trägt beispielsweise die Transaktion-Identitätsnummer
ID10. Das Netzwerkelement RSA vergibt daraufhin eine individuelle Identifikationsnummer für die gesendete MMA und bestätigt mit der WAP Nachricht M-Send. conf, daß die WAP Nachricht M-Send. req fehlerfrei an das Netzwerkele- ment RSA übertragen worden ist:
M-Send. conf (Netzwerkelement RSA — > Sendeapplikation UAA) :
X-Mms -Message-Type : m-send-conf X-Mms - Transac tion- ID: 10 X-Mms - Versi on : 1 . 0 X-Mms -Response- Status : ok
Message-ID: AAAA . Illl@mms-relay01 . siemens . de
In den beiden WAP Nachrichten M-Send . req und M-Send . conf kommt die gleiche Transaktion-Identitätsnummer (Transac- tion-ID) zum Einsatz. Damit kann die WAP Nachricht M- Send . conf mit der Nachrichtenidentifikationsnummer an der Sendeapplikation UAA eindeutig den dazugehörigen WAP
Nachrichten M-Send. req zugeordnet werden, wodurch die individuelle Identifikationsnummer AAAA . 111 l@mms- relay01 . siemens . de der verschickten MMA zugeordnet werden kann. Das Netzwerkelement RSA hat für die MMA in diesem Beispiel für die Schnittstelle Sendeapplikation UAA /
Netzwerkelement RSA die individuelle Identifikationsnummer AAAA . Illl@mms-relay01 . siemens . de vergeben, sie steht im Kopf-Feld Message-ID . Beispiel 1: Rückruf (ohne Bedingung)
Der Absender der MMA möchte diese (zwei Stunden später) wieder zurückrufen. Dies geschieht erfindungsgemäß mit Hilfe einer neuen MMB, die an den gleichen Empfänger geschickt wird, wie die MMA, die zurückgerufen werden soll. An dieser Stelle kommt vorteilhafterweise in der WAP Nachricht M-send. req das gemäß der vorliegenden Erfindung neu definierte Kopf-Feld mit der zweckmäßigen Bezeichnung X-Mms -Recall -ID zum Einsatz, in das die Message-ID der MMA, die zurückgerufen werden soll, eingetragen wird (IDl in Fig. 2) . Außerdem enthält die WAP Nachricht M-Send. req vorteilhafterweise das ebenfalls gemäß der vorliegenden Erfindung neu definierte Kopf-Feld mit der zweckmäßigen Bezeichnung X-Mms -Request -Report, mit dem eine Rückmeldung über den erteilten Rückruf-Auftrag angefordert werden kann. In der WAP Nachricht M-Send. req sind bei einem Rückruf-Auftrag vorzugsweise nur die Kopf-Felder und kein weiterer multimedialer Inhalt („Message-Body") enthalten. Wie auch im folgenden sind die neu definierten Kopf- Felder umrahmt .
M-Send. req (Sendeapplikation UAA -» Netzwerkelement RSA)
X-M s -Message -Type : m-send-req X-Mms -Transaction-ID: 16 X-Mms - Versi on : 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
Auch der Empfang der WAP Nachricht M-Send . req mit dem Rückruf-Befehl in MMB wird vorteilhafterweise vom Netzwerkelement RSA umgehend mit einer WAP Nachricht M- Send. conf quittiert. In ihr ist die vom Netzwerkelement RSA vergebene Nachrichtenidentifikationsnummer für die MMB (hier: AAKA . 2222@mms-relay01 . siemens . de) enthalten. Ferner enthält sie vorteilhafterweise das gemäß der vorliegenden Erfindung neu definierte Kopf-Feld X-Mms- Supported-Feature, mit dessen Hilfe der Sendeapplikation UAA angezeigt werden kann, ob der Dienstanbieter A das Rückruf-Dienstmerkmal unterstützt (wie hier gezeigt) oder nicht.
M-Send. conf (Netzwerkelement RSA —» Sendeapplikation 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-Fea ture : recall
Beim Austausch von WAP Nachrichten auf der Empfangsseite (Schnittstelle zwischen Netzwerkelement RSB und Empfangs- applikation UAB) muß unterschieden werden, ob die Empfangsapplikation UAB
1. noch nicht über eine eingetroffene MM informiert worden ist, oder 2. zwar benachrichtigt worden ist, aber die MM noch nicht abgerufen hat, oder
3. die MM schon erhalten hat .
Im ersten und zweiten Fall können die MMA und auch die MMB, die den Rückruf-Befehl enthält, im Zuständigkeitsbereich des Dienstanbieters B (MMSEB) gelöscht werden. Im ersten Fall muß der Empfänger davon nicht einmal in Kenntnis gesetzt werden. Im zweiten Fall sollte die E p- fangsapplikation UAB hingegen durch den Dienstanbieter B vorzugsweise darüber informiert werden können, daß die MMA nicht mehr länger zum Herunterladen für ihn bereit liegt, wenn der Absender sie nachträglich zurückgerufen hat. Dazu kann gemäß dieser Erfindung die WAP Nachricht M-Notification . ind benutzt werden:
2. Fall: M-Notifi cation . ind (Netzwerkelement RSB -> Empfangsapplikation UAB) :
X-Mms -Message -Type: m-notification-ind
X-Mms -Transac tion- ID: 20
X-Mms - Versi on : 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 der WAP Nachricht M-Notification . ind kann für die I- dentifizierung der zurückgerufenen MMA nur der URI benutzt werden, da das Netzwerkelement RS zu diesem Zeitpunkt noch keine „Message-ID" für die zurückgerufene MMA vergeben hat (dies geschieht erst mit dem Herunterladen) . Die Kopf-Feld X-Mms -Recalled-URI und X-Mms -Date-Of - Execution unterscheiden diese Rückruf-Benachrichtigung von einer „herkömmlichen" Benachrichtigung. Das Kopf-Feld X-Mms -Content-Location verweist in diesem Beispiel auf einen URI, unter dessen Speicherplatz vorteilhafterweise eine Standard-Text-Nachricht des Dienstanbieters B (z. B.: „Die MM ist vom Absender wieder gelöscht worden.") zu finden ist. Damit können auch Sende- und/oder Empfangsapplikationen, die die neuen Kopf-Felder des Rückruf- Dienstmerkmals nicht verstehen, nachträglich über einen ausgeführten Rückruf-Auftrag informiert werden.
Mit der WAP Nachrichten M-NotifyResp . req wird der korrekte Empfang der WAP Nachricht M-Notification . ind bestä- tigt. Das Kopf-Feld X-Mms-Status trägt in diesem Beispiel einen der gemäß der vorliegenden Erfindung neu definierten Einträge (nämlich „recall feature supported") , mit dem das Netzwerkelement RSB darüber in Kenntnis gesetzt werden kann, daß die Empfangsapplikation UAB die zweite Benachrichtigung mit der Information über den Rückruf verstanden hat.
(noch) 2. Fall: M-NotifyResp . req (Empfangsapplikation UAB — Netzwerkelement RSB) :
X-Mms -Message -Type : m-notifyresp-req X-Mms -Transaction- ID : 20 X-Mms - Versi on : 1 . 0 X-M s-Status : recall feature supported
Wenn aber die MMA, die gelöscht werden soll, bereits an die Empfangsapplikation UAB übermittelt worden ist (dritter Fall) , beinhaltet vorteilhafterweise die WAP Nachricht M-Notification . ind zweckmäßigerweise nicht die Benachrichtigung über den bereits erfolgten Rückruf, sondern den Rückruf-Befehl selbst und zwar in Form des Kopf- Feldes mit der zweckmäßigen Bezeichnung X-Mms -Recall -ID, in dem die Identifikationsnummer der MMA eingetragen wird, die zurückgerufen werden soll. Hier wird vorzugsweise die Identifikationsnummer (und nicht der URI) benutzt, weil sie (in dem hier beschriebenen dritten Fall) nach dem zuvor erfolgten Herunterladen sowohl dem Netz- werkelement RSB als auch dem Empfangsapplikation UAB bekannt ist.
3. Fall: M-Notification . ind (Netzwerkelement RSB — Emp- fangsapplikation 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 sage -Class : Personal
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 Das Kopf-Feld X-Mms-Content-Location verweist in diesem Beispiel auf einen URI, unter dessen Speicherplatz eine Standard-Text-Nachricht des Dienstanbieters B (z.B.: „Der Absender möchte die MM mit der Message-ID BBBB . 3333@mms- relay02. siemens . de zurückrufen.") zu finden ist. Damit können auch Sende- und/oder Empfangsapplikationen, die die neuen Kopf-Felder des Rückruf-Dienstmerkmals nicht verstehen, nachträglich über einen vom Absender verschickten Rückruf-Auftrag informiert werden.
Um hervorzuheben, daß die MMA an dieser Schnittstelle eine andere „Message-ID" tragen kann, wurde in diesem Aus- führungsbeispiel als Wert BBBB . 3333@mms- relay02. siemens . de gewählt (entspricht ID2 von MMA in Fig. 2) .
(noch) 3. Fall: M-NotifyResp. req (Empf ngsapplikation UAB — Netzwerkelement RSB) :
X-Mms -Message -Type : m-notifyresp-req X-Mms -Transaction-ID : 25 X-Mms- Versi on : 1 . 0
X-Mms-Status : recall successful
Die Empfangsapplikation UAB schickt bei diesem Ausführungsbeispiel mit der WAP Nachricht M-NotifyResp . req eine Rückmeldung zurück an das Netzwerkelement RSB. Dazu wird vorteilhafterweise das in dieser Erfindung erweiterte Kopf-Feld X-Mms-Status aus dem Encapsulation-Standard (s.o.) benutzt. In diesem Ausführungsbeispiel konnte die MMA auf der Empfangsapplikation UAB gelöscht werden, was mit dem Feld-Wert „recall successful" ausgedrückt wird. Im Netzwerkelement RSB kann der Transaction -ID (hier: 25) des WAP Nachrichten-Paares auf die Nachrichtenidentifikationsnummer (hier: BBBB . 3333@mms-relay02. siemens . de) der gelöschten MMA geschlossen werden. Dadurch ist das Verfassen einer Rückmeldung möglich, falls dies vom Absender gewünscht und vom Dienstanbieter B unterstützt wird.
M-Delivery. ind (Netzwerkelement RSA — Sendeapplikation 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, 26. Oct 2000 14 : 14 : 09 +0100
X-Mms-Status : recall successful
Falls der Absender eine Rückmeldung für den von ihm initiierten Rückruf-Auftrag wünscht, kann das MMS Relay/Server A mit der WAP Nachricht M-Delivery. ind eine Rückmeldung zurück an die Sendeapplikation UAA schicken. In dem Feld „ Message -ID" steht die Identifikationsnummmer des Rückruf-Aufträges. Für den Status des Rückrufes wird ,hier ebenfalls vorteilhafterweise das erweiterte Kopf- Feld X-Mms-Status benutzt, in dem das erfolgreiche Lö- sehen der MMA mit dem Feld-Wert „recall successful" bestätigt wird. Da der Sendeapplikation UAA der Zusammenhang zwischen der Nachrichtenidentifikationsnummer des Rückruf-Auftrages und der Nachrichtenidentifikationsnummer der MMA, die zurückgerufen werden sollte, bekannt ist, kann dem Absender mitgeteilt werden, ob sein Rückruf- Auftrag erfolgreich ausgeführt werden konnte oder nicht (sofern die beteiligten MMS Dienstanbieter dies unterstützen) . Beispiel 2: Ändern (ohne Bedingung)
In diesem Beispiel möchte der Absender seine MMA (eine Stunde nach dem Verschicken) aktualisieren: Von den ursprünglichen verschickten zwei Elementen soll nur noch das JPEG-Bild (MIME content type „image/jpeg") erhalten bleiben. Außerdem soll der Betreff in „Agenda für unser Meeting" geändert werden.
Gemäß dieser Erfindung wird eine neue MMB an den gleichen Empfänger geschickt wie die zuvor verschickte MMA, die geändert bzw. ersetzt werden soll. Dazu wird vorteilhafterweise das gemäß der vorliegenden Erfindung neu defi- nierte Kopf-Feld mit der zweckmäßigen Bezeichnung X-Mms- Replace-ID benutzt, in das die „Message-ID" der MMA eingetragen wird. Außerdem enthält vorteilhafterweise die WAP Nachricht M-Send. req das ebenfalls gemäß der vorliegenden Erfindung neu definierte Kopf-Feld mit der zwec - mäßigen Bezeichnung X-Mms -Request-Report , mit dem eine Rückmeldung über den erteilten Änderungsauftrag angefordert werden kann (wie in diesem Beispiel gezeigt) .
M-Send . req ( Sendeappl ikation UAA → Netzwerkelement RSA) :
X-Mms -Message - Type : m-send-req X-Mms -Transaction-ID: 32 X-Mms - Versi on : 1 . 0
Pate ; 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 für unser Meeting Content-Type : mul tipart/related; boundary= " ■ _=_NextPart_023_ "
_=_NextPart_023_
Content-Type : Image/ jpeg; name= " agenda . jpg" Content-Trans fer-Encoding: base64 Content -ID: <1725782>
= NextPart 023 - ■
Auch der Empfang dieser WAP Nachricht M-Send. req, welche die MMB mit dem Änderungsbefehl in sich trägt, wird bevorzugt vom Netzwerkelement RSA umgehend mit einer WAP Nachricht M-Send. conf quittiert. In ihr ist zweckmäßigerweise die vom Netzwerkelement RSA vergebene Nachrichtenidentifikationsnummer (Message-ID) der MMB (hier: AAAA . 5555@mms-relay01 . siemens . de) und das ebenfalls gemäß der vorliegenden Erfindung neu definierte Kopf-Feld X- Mms- Supported- Feature enthalten, mit dessen Hilfe der Sendeapplikation UAA angezeigt werden kann, ob der Dienstanbieter A das Ändern-Dienstmerkmal unterstützt o- der nicht. Die beiden WAP Nachrichten tragen in diesem Beispiel die Transaktion-Identitätsnummer IDD32.
M-Send.conf (Netzwerkelement RSA → Sendeapplikation UAA) :
X-Mms -Message - Type: m- send- conf X-Mms -Transaction-ID: 32 X-Mms - Versi on : 1 . 0 X-Mms-Response-Status : ok
Message-ID: AAAA . 5555@mms-relay01 . siemens . de
X-Mms - Supported-Feature : replace
Beim Austausch von WAP Nachrichten auf der Empfangsseite (Schnittstelle zwischen Netzwerkelement RSB und Empfangsapplikation UAB) muß unterschieden werden, ob die Empfangsapplikation UAB
1. noch nicht über eine eingetroffene MM informiert wor- den ist, oder
2. zwar benachrichtigt worden ist, aber die MM noch nicht abgerufen hat, oder
3. die MM schon erhalten hat.
Im ersten und zweiten Fall kann die MMA im Zuständigkeitsbereich des Dienstanbieters B (MMSEB) durch die MMB geändert, insbesondere ersetzt, werden. Die Erfindung ermöglicht, daß der Empfänger im ersten Fall sowohl bei der Benachrichtigung als auch beim Herunterladen darüber in Kenntnis gesetzt wird, daß es sich um eine nachträglich geänderte, insbesondere ersetzte, MM handelt und wann der Änderungsauftrag ausgeführt worden ist . Bevorzugt kann im zweiten Fall der Dienstanbieters B die Empfangsapplikation UAB sofort nach dem Ausführen des Änderungsauftrages im MMSEB darüber informieren, daß der Absender MMA durch eine neue MMB aktualisiert hat und wann diese Aktualisierung vorgenommen worden ist. Nach dieser Erfindung soll diese Benachrichtigung vorzugsweise mittels der WAP Nachricht M-Notification . ind erfolgen, in der für die Identi- fizierung der geänderten, insbesondere ersetzten, MMA nur der URI benutzt werden kann, da das Netzwerkelement RSB zu diesem Zeitpunkt noch keine Nachrichtenidentifikationsnummer { „Message-ID") für die MMA vergeben hat (dies geschieht erst mit dem Herunterladen der MMA) . Die Kopf- Felder X-Mms -Replaced- URI und X-Mms -Date-Of -Execution unterscheiden diese Rückruf-Benachrichtigung von einer „herkömmlichen" Benachrichtigung. Das Kopf-Feld X-Mms- Content-Location zeigt an, wo die MMB mit dem nun aktuellen Inhalt auf dem Server zu finden ist.
2. Fall: M-Notification . ind (Netzwerkelement RSB → Empfangsapplikation UAB) :
X-Mms -Message - Type : m -noti fi ca ti on - ind
X-Mms -Transaction-ID: 35
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 - Conten t -Loca ti on : ht tp : //mms - relay02. siemens . de /BBBB . 4444
Mit der WAP Nachricht M-NotifyResp . req wird vorteilhafterweise der korrekte Empfang der WAP Nachricht M- Notification . ind von der Empfangsapplikation UAB bestätigt, vgl. Fig. 2. Das Kopf-Feld X-Mms-Status trägt in diesem Beispiel einen gemäß der vorliegenden Erfindung neu definierten Eintrag (nämlich „replace feature supported") , mit dem das Netzwerkelement RSB darüber in Kenntnis gesetzt wird, daß die Empfangsapplikation UAB die zweite Benachrichtigung mit der Information über den ausgeführten Änderungsauftrag verstanden hat .
(noch) 2. Fall: M-NotifyResp . req (Empfangsapplikation UAB -» Netzwerkelement RSB) :
X-Mms -Message-Type : m-notifyresp-req X-Mms -Transaction-ID: 35 X-Mms - Versi on : 1 . 0
X-Mms-Status : replace feature supported
Wenn aber die MMA, die geändert werden soll, bereits an die Empfangsapplikation UAB übermittelt worden ist (dritter Fall) , beinhaltet nach dieser Erfindung die WAP Nach- rieht M-Notification. ind vorteilhafterweise nicht die Benachrichtigung über eine bereits erfolgte Änderung, sondern den Änderungsbefehl selbst und zwar in Form des Kopf-Feldes mit der zweckmäßigen Bezeichnung X-Mms - Replace-ID, in dem die Identifikationsnummer der zu än- dernden, insbesondere zu ersetzenden, MMA eingetragen wird. Daraufhin kann von der Empfangsapplikation UAB das Herunterladen der MMB entweder im PUSH-Modus oder im PULL-Modus mit Hilfe des WSP GET Befehls eingeleitet werden. Das Kopf-Feld X-Mms- Content-Location verweist in diesem Beispiel auf einen URI, unter dessen Speicherplatz eine Standard-Text-Nachricht des Dienstanbieters B (z. B.: „Der Absender möchte die MM mit der Message-ID BBBB . 3333@mms-relay02 . siemens . de nachträglich ändern.") zu finden ist. Damit können auch Empfangsapplikationen, die die neuen Kopf-Felder des Rückruf-Dienstmerkmals nicht verstehen, nachträglich über einen vom Absender verschickten Änderungsauftrag informiert werden. 3. Fall: M-Notification . ind (Netzwerkelement RSB ->• Empfangsapplikation 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 - Con tent-Location : http : //mms - relay02. siemens . de/defaul t-replace-message
X-Mms -Replace -ID: BBBB . 3333@mms- relay02. si emens . de
Als Antwort auf den WSP GET Befehl, mit dem der URI an das Netzwerkelement RSB geschickt wird, erhält die Empfangsapplikation UAB die MMB mit dem geänderten Titel und dem geänderten multimedialen Inhalt (nur noch ein JPEG- Bild) zum Ändern bzw. Ersetzen von MMA in der WAP Nachricht M-Retrieve . conf zugestellt. Auch in der WAP Nachricht M-Retrieve . conf soll vorteilhafterweise das Kopf- Feld mit der zweckmäßigen Bezeichnung X-Mms -Replace -ID ergänzt werden. Damit kann direkt auf der Empfangsappli- kation UAB die MMA durch die MMB geändert, insbesondere ersetzt, werden, falls die Empfangsapplikation UAB das Ändern-Dienstmerkmal unterstützt. Abhängig vom gewählten Zustellungs-Modus wird in der WAP Nachricht M- Retrieve . conf die Transaktions-Identitätsnummer aus der WAP Nachricht M-Notification . ind übernommen (PUSH-Modus) oder eine neue vergeben (PULL-Modus) . (noch) 3. Fall: M-Retrieve. conf (Netzwerkelement RSB — Empfangsapplikation UAB) :
X-Mms -Message - Type : m-re tri eve - conf X-Mms -Transaction-ID: 38 bzw. 48
Message-ID: BBBB.4444@mms-relay02. siemens. de X-Mms- Versi on: 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 für unser Meeting
Content-Type: multipart/related; boundary=" ■ _=_NextPart_023_"
_=_NextPart_023_ Conten -Ty e; image/jpeg; na e-" agenda.jpg"
Content-Trans fer-Encoding : base64 Content-ID: <1725782>
_=_TfextPart_023_--
Um hervorzuheben, daß die MMA an dieser Schnittstelle eine andere Nachrichtenidentifikationsnummer {„Message-ID") tragen kann, wurde in diesem Ausführungsbeispiel als Wert BBBB.3333@mms-relay02.siemens.de gewählt (entspricht ID2 in Fig. 2) .
Bei Zustellung von MMB im PULL-Modus : 3. Fall: M-Acknowledge . ind (Empfangsapplikation UAB —» Netzwerkelernent RSB) :
X-Mms -Message - Type : m -acknowl edge -ind X-Mms -Transaction-ID: 48 X-Mms - Versi on : 1 . 0
X-Mms -Status : replace successful
Erfolgte die Zustellung der MMB im PULL-Modus, schickt die Empfangsapplikation UAB vorzugsweise mit der WAP Nachricht M-Acknowledge . ind eine Rückmeldung zurück an das Netzwerkelement RSB. Dazu wird das gemäß dieser Erfindung erweiterte Kopf-Feld X-Mms-Status benutzt. In diesem Ausführungsbeispiel konnte die MMA auf der Emp- fangsapplikation UAB durch die neue MMB ersetzt werden, was mit dem Feld-Wert „replace successful" ausgedrückt wird. Im Netzwerkelement RSB kann von der Transaktions-ID { Transaction-ID) (hier: 48) des WAP Nachrichten-Paares M- Retrieve . conf und M-Acknoledge . ind auf die Nachrichten-ID (hier: BBBB . 3333@mms-relay02 . siemens . de) der ersetzten MMA geschlossen werden. Dadurch ist das Verfassen einer Rückmeldung möglich, falls dies vom Absender verlangt und vom Dienstanbieter B unterstützt wird.
Bei Zustellung von MMB im PCJSΗ-Modus
3. Fall: M-NotifyResp . req (Empfangsapplikation UAB → Netzwerkelement 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 Erfolgte die Zustellung der MMB im PUSH-Modus, bestätigt die Empfangsapplikation UAB den korrekten Empfang von MMB vorzugsweise mit der WAP Nachricht M-NotifyResp . req. Dazu wird bevorzugt das in dieser Erfindung erweiterte Kopf- Feld X-Mms-Status benutzt. In diesem Ausführungsbeispiel konnte die MMA auf der Empfangsapplikation UAB durch die neue MMB ersetzt werden, was mit dem Feld-Wert „replace successful" ausgedrückt wird. Im Netzwerkelement RSB kann von der Transaktions-ID (hier: 38) des WAP Nachrichten- Triples M-Notification . ind M-Retrieve . conf und M- NotifyResp . req auf die Nachrichten-ID (hier: BBBB . 3333@mms-relay 02. siemens . de) der ersetzten MMA geschlossen werden. Dadurch ist das Verfassen einer Rückmeldung möglich, falls dies vom Absender verlangt und vom Dienstanbieter B unterstützt wird.
M-Delivery. ind (Netzwerkelement RSA -» Sendeapplikation 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, 26 Oct 2000 13 : 12 : 11 +0100
X-Mms-Status : replace successful
Das Netzwerkelement RSA kann mit der WAP Nachricht M- Delivery. ind eine Rückmeldung zurück an die Sendeapplikation UAA schicken. In dem Feld Message-ID steht die ID des Änderungsauftrages. Für den Status des Änderungsauftrages wird hier vorzugsweise ebenfalls das erweiterte Kopf-Feld X-Mms -Status benutzt, in dem das erfolgreiche Ändern der MMA durch MMB mit dem Feld-Wert „replace suc- cessful" bestätigt wird. Da der Sendeapplikation UAA der Zusammenhang zwischen der Nachrichten-ID des Änderungsaufträges und der Nachrichten-ID der MMA, die zurückgerufen werden sollte, bekannt ist, kann dem Absender mitge- teilt werden, ob sein Änderungsauftrag erfolgreich ausgeführt werden konnte oder nicht (sofern die beteiligten Dienstanbieter dies unterstützen) .
Beispiel 3: Alternative für das Übermitteln einer Status- Information (ohne Bedingung)
In den beiden zuvor beschriebenen Ausführungsbeispielen wird eine Rückmeldung über den Ausgang eines erteilten Rückruf- bzw. Änderungsauftrages von der Empfangsapplikation UAB zum Netzwerkelement RSB (bei Dienstanbieter B) mit den WAP Nachrichten M-NotifyResp . ind (PUSH-Modus) o- der M-Acknowledgement . ind (PULL-Modus), bzw. vom Netzwerkelement RSA zur Sendeapplikation UAA (bei Dienstan- bieter A) mit der WAP Nachricht M-Delivery. ind übertragen. Dazu wurden neue Feld- erte in das Kopf-Feld X-Mms- Status eingeführt. Dieses Vorgehen ist zwar effizient, jedoch nicht ganz konform zur bisherigen Nutzung des Kopf-Feldes X-Mms-Status . Deshalb wird im folgenden ein alternatives Ausführungsbeispiel für das Übermitteln einer Rückmeldung beschrieben. Das Absenden sowie das Ausführen eines Rückruf- oder Änderungsauftrages bleibt dabei wie in Beispiel 1 und Beispiel 2 beschrieben zweckmäßigerweise unverändert.
Mit dieser Alternative wird das Kopf-Feld X-Mms-Status (so wie es im Encapsulation Standard (s.o.) ursprünglich vorgesehen ist) weiterhin ausschließlich dazu benutzt, den Absender über den Zustand der zuletzt verschickten MM (also derjenigen, die den Rückruf- oder Änderungsauftrag beinhaltete) zu informieren und nicht (wie unter Ausführungsbeispiel 1 und 2 beschrieben) über den Ausgang eines Rückruf- oder Änderungsauftrages. Für diesen Fall wird deshalb ein weiteres Kopf-Feld definiert, mit dem der Absender über den Ausgang seines Rückruf- oder Änderungsaufträges in Kenntnis gesetzt werden kann. Es wird vorgeschlagen, dieses neue Kopf-Feld mit dem Namen X-Mms- Original -Message-Status zu versehen und ihm die hexadezimale Kodierung 0x86 (dezimal: 134) zu geben. Weiterhin wird vorgeschlagen, z.B. als Feld-Werte <Octetl28> für „Die MM wurde erfolgreich zurückgerufen", <Octetl29> für „Der Rückruf der MM ist fehlgeschlagen", <Octetl30> für „Die MM wurde erfolgreich geändert bzw. ersetzt" und
<Octetl31> für „Das Ändern bzw. Ersetzen der MM ist fehlgeschlagen" zu benutzen. Fig. 7 zeigt das in dieser Alternative vorgestellte Kopf-Feld.
Beispiel 4: Alternative für das Übermitteln einer Rückmeldung (ohne Bedingung)
In den Beispielen 1 und 2 wurde die MMA, auf die sich die Rückmeldung bezieht, über das Ergebnis des Rückruf- bzw. Änderungsauftrages anhand der Message-ID von MMB und anhand der Transaktion-IDs in den WAP Nachrichten M- NotifyResp . ind oder M-Acknowledge . ind identifiziert.
Denkbar ist auch, die Nachrichten-ID derjenigen MMA, die zurückgerufen oder geändert, insbesondere ersetzt, worden ist, direkt mit den WAP Nachrichten M-NotifyResp . ind oder M-Acknowledgement . ind (an Dienstanbieter B) , bzw. M- Delivery. ind (von Dienstanbieter A) zu übertragen. Dazu wird vorgeschlagen, ein neues Kopf-Feld einzuführen, welches beispielsweise die zweckmäßige Bezeichnung X-Mms- Original -Message-ID trägt, und ihm die hexadezimale Ko- dierung 0x87 (dezimal: 135) zu geben. Die Feld-Werte dieses neuen Kopf-Feldes beinhalten bevorzugt die Nachrichten-ID der Original-MMA und werden gemäß dem Encapsulation-Standard (s.o.) als Text-String kodiert. Fig. 8 zeigt das in dieser Alternative vorgestellte Kopf-Feld.
C.2 Mit Bedingung für Rückruf bzw. Ändern
In den nun folgenden Ausführungsbeispielen wird detail- liert auf die in den WAP Nachrichten benutzten Kopf- Felder für das bedingte Rückrufen und Ändern einer ersten Nachricht eingegangen. Dabei wird beispielhaft folgendes Szenario angenommen: Eine MMS VAS-Applikation A verschickt eine MMA an einen Empfänger und will diese später zurückrufen (Beispiel 5) bzw. durch eine neue MMB ersetzen (Beispiel 6) .
Innerhalb der WAP Nachricht M-Send. conf wird der gesendeten MMA eine individuelle Identifikationsnummer (AAAA.llll@mms-relay01.siemens.de) zugeordnet. Diese Nachrichten ID 1 { „Message-ID 1 ") dient dazu, die MMA beim Zurückrufen und Ersetzen zu identifizieren, s.o. Report of the 3GPP TSG-T2 SWG3 MMS.
Beispiel 5: Bedingter Rückruf
Der Absender einer MMA möchte diese (zwei Stunden später) wieder zurückrufen. Dies geschieht mit Hilfe einer neuen MMB, die an den gleichen Empfänger geschickt wird, wie die MMA, die zurückgerufen werden soll . An dieser Stelle wird in der WAP Nachricht M- send. req vorteilhafterweise das Kopf-Feld X-Mms -Recall -ID mit der entsprechenden Nachrichten-ID der zurückzurufenden MMA verwendet, s.
Beispiel 1. Zudem wird hier eine Rückmeldung über den erteilten Rückruf-Auftrag mittels des Kopf-Feldes X -Mms- Request-Report angefordert. Das gemäß dieser Erfindung neu definierte Kopf-Feld mit der Bezeichnung X-Mms- Recall -Cond kommt in der WAP Nachricht -Send.reg zum Einsatz. Der Feld-Wert in diesem Beispiel wird als <0c- tetl30> angenommen. Dieser Wert entspricht dem Wunsch des Absenders, den Rückruf nur zu realisieren, wenn die MMA nicht gelesen wurde, unabhängig davon, ob eine Benach- richtigung gesendet wurde oder ob die MM schon heruntergeladen wurde .
M-Send. req (MMS VAS-Applikation A -» Netzwerkelement RSA) :
X-Mms -Message -Type : m-send-req
X-Mms -Transaction-ID: 16
X-Mms - Versi on : 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 diesem Fall sei angenommen, daß das Netzwerkelement RSA feststellt, daß es die zu löschende MM an ein weiteres Netzwerkelement RSB weitergeleitet hat. Hier wird der Empfang der WAP Nachricht M-Send. req mit dem Rückruf- Befehl in MMB vom Netzwerkelement RSA mit einer WAP Nach- rieht M-Send. conf quittiert (s.a. Fig. 2). In ihr ist die vom Netzwerkelement RS vergebene Message-ID für die MMB (hier: AAAA . 2222@mms-relay01 . siemens . de) enthalten. Ferner enthält das Kopf-Feld X-Mms -Supported-Feature den in dieser Erfindungsmeldung neu definierten Eintrag „Beding- ter-Rückruf-Merkmal unterstützt".
M-Send . conf (Netzwerkelement RSA - MMS VAS-Applikation 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
Hier wird davon ausgegangen, daß das Netzwerkelement RSB feststellt, daß die Empfangsapplikation UAB benachrichtigt wurde und die MM abgerufen hat. Da die Bedingung des Rückrufs noch erfüllt sein kann (MM sollte noch nicht geöffnet/gelesen sein) , wird weiterhin versucht, den Rückruf-Auftrag zu erfüllen. Dabei wird die Empfangsapplikation UAB mittels der WAP Nachricht M-Notification . ind informiert, daß die zuvor heruntergeladene MMA zurückgeru- fen werden soll, wenn sie nicht gelesen wurde. Diese Bedingung wird auch mittels des Kopf-Feldes X-Mms-Recall - Cond mit dem Feld-Wert <0ctetl30> (für das Zurückrufen nur vor dem Lesen) mitgeteilt. Die Identifikation der Nachricht MMA erfolgt hier auch mittels der Identifikationsnummer. Diese Kennung kann sich aber aufgrund des Weiterleitens zu einem anderen Netzwerkelement RS von der Message-ID 1 {AAAA . llll@mms- relay01. siemens . de) unterscheiden, s.o. WAP-209- MMSEncapsulation, Release 2000. In diesem Ausführungsbei- spiel wurde daher eine andere Message-ID gewählt: BBBB . 3333@mms-relay02 . siemens . de .
Das Kopf-Feld X-Mms -Content-Location verweist in diesem Beispiel auf einen URI, unter dessen Speicherplatz eine Standard-Text-Nachricht des Dienstanbieters B (z. B.: „Der Absender möchte die MM mit der Message-ID BBBB . 3333@mms-relay02 . siemens . de zurückrufen.") zu finden ist. Damit können auch Empfangsapplikationen UAB, welche die neuen Kopf-Felder des Rückruf-Merkmals nicht verstehen, nachträglich über einen vom Absender verschickten Rückruf-Auftrag informiert werden.
M-Notification . ind (Netzwerkelement RSB — Empfangsapplikation UAB) :
X-Mms -Message -Type : m-notification-ind X-Mms -Transaction-ID : 20
X-Mms - Versi on : 1 . 0
From : abc@vas . de
X-Mms -Message-Class : Personal
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
Mit der WAP Nachricht M-NotifyResp . ind wird der korrekte Empfang der WAP Nachricht M-Notification . ind bestätigt. Falls die MMA nicht gelesen wurde, kann diese infolge des bedingten Ruckrufbefehls gelöscht werden. Des weiteren berichtet die Empfangsapplikation UAB hier über den Ausgang des Rückruf-Auftrags . Dazu dient der X-Mms-Status Kopf-Feld. Er trägt in diesem Beispiel einen der in die- ser Erfindungsmeldung neu definierten Einträge, nämlich <Octetl40> für „Rückruf erfolgreich, bevor MM gelesen wurde" .
M-NotifyResp . ind (Empfangsapplikation UAB — Netzwerkele- ment 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
Falls die MMA, die zurückgerufen werden soll, bereits geöffnet wurde, wird nicht mehr versucht, diese zu löschen. Statt dessen beinhaltet die WAP Nachricht M-
NotifyResp . ind die Information über den Mißerfolg des RückrufVorgangs , da die MMA schon geöffnet wurde. Das Kopf-Feld X-Mms-Status hat dann den Wert <Octetl44> für „Rückruf fehlgeschlagen, da MM gelessen wurde". Die M- NotifyResp . ind WAP Nachricht sieht dann folgendermaßen aus :
M-NotifyResp . ind (Empfangsapplikation UAB -> Netzwerkele- 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
Falls der Absender eine Rückmeldung für den von ihm ini- tiierten Rückruf-Auftrag wünscht, kann das Netzwerkelement RSA mit der WAP Nachricht M-Delivery. ind eine Rückmeldung zurück an die Sendeapplikation UAA schicken. In dem Feld „Message-ID" steht die ID des Rückruf-Auftrages {AAAA . 2222@mms-relay01 . siemens . de) . Für den Status des Rückrufes wird hier ebenfalls das erweiterte Kopf-Feld X- Mms-Status benutzt, in dem das z.B. erfolgreiche Löschen der MMA mit dem Feld-Wert „Rückruf erfolgreich, bevor MM gelesen wurde" bestätigt wird. Da der Sendeapplikation UAA der Zusammenhang zwischen der Nachrichten-ID des Rückruf-Auftrages und der Nachrichten-ID der MMA, die zurückgerufen werden sollte, bekannt ist, kann dem Absender mitgeteilt werden, ob sein Rückruf-Auftrag erfolgreich ausgeführt werden konnte oder nicht (sofern die beteiligten MMS Dienstanbieter dies unterstützen) .
M-Delivery. ind (Netzwerkelement RSA -» Sendeapplikation UAA) :
X-Mms -Message- Type : m-delivery-ind X-Mms -Message-ID: AAAA . 2222@mms-relay01 . siemens . de X-Mms - Versi on : 1 . 0 To : abc@vas . de Date : Thu, 26. Oct 2000 14 : 14 : 09 +0100 X-Mms-Status : recall successful
Beispiel 6: Bedingtes Ändern bzw. Ersetzen
In diesem Beispiel möchte der Absender seine MMA (eine Stunde nach dem Verschicken) aktualisieren: Von den ursprünglich verschickten zwei Elementen soll nur noch das JPEG-Bild (MIME content type „image/jpeg") erhalten blei- ben. Außerdem soll das Subject in „Agenda für unser Meeting" geändert werden, s. Beispiel 2. An dieser Stelle wird in der WAP Nachricht M-send. req vorteilhafterweise das Kopf-Feld X-Mms -Replace -ID mit der entsprechenden Nachrichten-ID der zu ersetzenden MMA verwendet. Zudem wird hier eine Rückmeldung über den erteilten Änderungs- auftrag mittels des X-Mms- eguest-.Report Kopf-Feldes angefordert . Das in dieser Erfindungsmeldung neu definierte Kopf-Feld mit der beispielhaften Bezeichnung X-Mms- Replace-Cond kommt in der WAP Nachricht M-Send . req zum Einsatz. Der Feld-Wert in diesem Beispiel wird als <Oc- tetl28> angenommen. Dieser Wert entspricht dem Wunsch des Absenders, den Rückruf nur dann zu realisieren, wenn der Empfänger der MMA über diese Nachricht noch nicht benachrichtigt wurde.
M-Send . req (MMS VAS-Applikation A → Netzwerkelement RSA) :
X-Mms -Message -Type : m-send-req X-Mms -Transaction-ID: 32 X-Mms - Versi on : 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 Subj ect : Agenda für unser Meeting
Content-Type : mul tipart/related; boundary= " ■ _=_NextPart_023_ "
Content-Type : Image/ jpeg; name= " agenda . jpg" Content-Trans fer-Encoding : base64 Content-ID: <1725782>
= NextPart 023
Im weiteren werden 2 Fälle betrachtet:
Fall 1: Empfangsapplikation UAB hat MMA aufgrund einer Benachrichtigung (Notification) heruntergeladen.
Fall 2: Die MMA ist noch auf dem Netzwerkelement RSA und es wurde keine Benachrichtigung an die Empfangsapplikation UAB gesendet .
Fall 1:
Da die Benachrichtigung schon gesendet wurde, ist die Bedingung zum Ausführen des Änderungsbefehls nicht mehr erfüllt. Folglich kann und soll das Ersetzen nicht mehr erfolgen. Hier wird der Empfang der WAP Nachricht M- Send . reg mit dem Änderungsbefehl vom MMS Relay/Server mit einer WAP Nachricht M-Send. conf quittiert. In ihr ist die vom MMS Relay/Server vergebene Nachrichten-ID für die MMB (hier: AAAA . 2222@mms-relay01 . siemens . de) enthalten. Fer- ner enthält das Kopf-Feld X-M s -Supported-Feature den in dieser Erfindungsmeldung neu definierten Eintrag „Bedingtes-Ändern-Merkmal unterstützt". Da der Änderungsauftrag nicht ausgeführt werden kann, wird der Auftraggeber mit- tels des Kopf-Feldes X-Mms -Response -Status über den Ausgang seines Auftrages informiert: Der Feld-Wert <0c- tetl52> meldet, daß das bedingte Ersetzen nicht erfolgen konnte, da die Benachrichtigung schon gesendet wurde: „Ändern fehlgeschlagen, da Benachrichtigung gesendet wur- de".
M-Send . conf (Netzwerkelement RSA → MMS VAS-Applikation A) :
X-Mms -Message-Type : m-send-conf X-Mms -Transaction-ID: 32 X-Mms - Versi on : 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
Falls das Netzwerkelement RSA das bedingte Ersetzen nicht unterstützt, wird er die MMB als normale Multimedia Message behandeln und folglich wie üblich dem Empfänger weiterleiten, ohne Rücksicht auf die zu ersetzende MMA zu nehmen .
Fall 2:
Da die Benachrichtigung noch nicht gesendet wurde, ist die Bedingung zum Ausführen des Änderungsbefehls erfüllt Folglich kann das Ersetzen wie gewünscht erfolgen. Die MMA kann auf dem Netzwerkelement RSA gelöscht werden, und der Absender wird mittels des Kopf-Feldes X-Mms -Response - Status über diesen Vorgang informiert. Der Feld-Wert <Oc- tetl52> meldet, daß das bedingte Ersetzen vor dem Versand der Benachrichtigung erfolgt ist: „Ändern erfolgreich, vor Benachrichtigung".
M-Send. conf (Netzwerkelement RSA -» MMS VAS-Applikation A) :
X-Mms -Message -Type : m- send- conf X-Mms -Transaction-ID: 32 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 replace X-Mms-Status : replace successful , before notifi cation
Die neue Nachricht MMB erreicht dann die Empfangsapplikation UAB als normale Multimedia-Nachricht, die durch eine eigene Benachrichtigung angekündigt wird. Der Empfänger wird somit informiert, daß der Absender die zuvor ver- schickte MMA durch eine neue MMB ersetzt hat .
Teil der Erfindung sind neben den beschriebenen Verfahren ebenfalls die entsprechenden Vorrichtungen, insbesondere Telekommunikationsendgeräte und hierbei insbesondere Mobilfunkgeräte sowie die entsprechenden Netzwerkelemente. Ebenso sind die entsprechenden Softwareprogramme von der vorliegenden Erfindung umfaßt.
Tabelle 1: Möglichkeiten der Feld-Wert-Kodierung nach WAP- 203-WSP, Version 4-May-2000; Wireless Application Protocol, Wireless Session Protocol Specification; Chapter 8.4: "Header Encoding" .
Tabelle 2: Zusätzliche Einfügungen in die WAP Nachricht M- Send.req.
Tabelle 3: Zusätzliche Einfügungen in die WAP Nachricht M- Send. conf .
Tabelle 4: Zusätzliche Einfügungen in die WAP Nachricht M- Notification. ind.
Tabelle 5 : Zusätzliche Einfügungen in die WAP Nachricht M- NotifyResp . reg.
Tabelle 6: Zusätzliche Einfügungen in die WAP Nachricht M- Retrieve. conf .
Tabelle 7: Zusätzliche Einfügungen in die WAP Nachricht M- Acknowl edge . ind .
Tabelle 8: Zusätzliche Einfügungen in die WAP Nachricht M- Delivery. ind.
Bezugszeichenliste
1 Sendeapplikation (MMS User Agent A = UAA)
2 Senderseitiges Netzwerkelement (MMS Relay/Server A = RSA)
3 MMS Speicher A (MMS Server A)
4 MMS-Umgebung (= MMSE; eines MMS-Dienstleisters A)
6 Öffentliches Mobilnetzwerk (PLMN = Public Land Mobile Network) 7 VAS-Applikation (VAS = Value Added Service)
11 Empfangsapplikation (MMS User Agent B = UAB)
12 Empfängerseitiges Netzwerkelement (MMS Relay/Server B RSB)
13 MMS Speicher B (MMS Server B) 14 MMSE-Umgebung (= MMSE; eines MMS-Dienstleisters B)
20 IP - Internet Protocol
21 Legacy-Nachrichtensystem (Legacy Messaging System)
22 Einfachpostübertragungsprotokoll (SMTP = Simple Mail Transfer Protocol)

Claims

PATENTANSPRÜCHE
1. Verfahren zum Zugreifen auf eine erste Nachricht (MMA) , insbesondere eine multimediale Nachricht (MM) vorzugsweise vom MMS-Typ, wobei die erste Nachricht (MMA) mittels einer Sendeapplikation (1) oder einer netzwerkseitigen VAS- Applikation (7) an eine Empfangsapplikation (11) gesendet wird, dadurch gekennzeichnet, daß eine zweite Nachricht (MMB) mit einem Manipulationsauftrag zur Manipulation der ersten Nachricht (MMA) erstellt, versendet, empfangen, weitergeleitet und/oder verarbeitet wird, um einen manipulierenden Zugriff auf die erste Nachricht (MMA) zu veranlassen oder zu vermitteln.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die erste Nachricht (MMA) und die zweite Nachricht (MMB) über Funk, über Mobilfunksysteme, zwischen Mobilfunksystemen, insbesondere Inter-Operator-IP-backbone, zwischen Mobilfunknetzen und anderen Nachrichten-Netzen, insbesondere Internet-E- mail, und/oder über das Internet versendet werden.
3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, daß die erste Nachricht (MMA) und die zweite Nachricht (MMB) über mindestens ein senderseitiges Netzwerk- element (2) eines Dienstanbieters (Dienstanbieter A) und mindestens ein empfängerseitiges Netzwerkelement (12) eines Dienstanbieters (Dienstanbieter B) an die Empfangsapplikation (11) gesendet wird.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß das mindestens eine senderseitige Netzwerkelement (2) und das mindestens eine empfängerseitige Netzwerkelement (12) dem Zu- ständigkeitsbereich (4) eines einzigen Dienstanbieters (Dienstanbieter A) angehören oder auch identisch sind.
5. Verfahren nach einem der vorhergehenden Ansprüche, da- durch gekennzeichnet, daß die Sendeapplikation (1) und die
Empfangsapplikation (11) identisch sind.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der manipulierende Zugriff auf die erste Nachricht (MMA) auf einem senderseitigen Netzwerkelement (2) , auf einem empfängerseitigen Netzwerkelement (12) und/oder auf der Empfangsapplikation (11) erfolgt.
7. Verfahren nach einem der vorhergehenden Ansprüche, da- durch gekennzeichnet, daß der Manipulationsauftrag den Rückruf bzw. das Löschen der ersten Nachricht (MMA) umfaßt.
8. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß der Manipulationsauftrag das Ändern der ersten Nachricht (MMA) umfaßt, insbesondere durch Ersetzen der ersten Nachricht (MMA) durch die zweite Nachricht (MMB) .
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daß bei NichtUnterstützung des Ändern-Aufträges seitens mindes- tens eines der beteiligten MMS-Umgebungen (4, 14) der Dienst- anbieter, die zweite Nachricht (MMB) als gewöhnliche Nachricht der Empfangsapplikation (11) zugestellt wird, wobei der Absender vorzugsweise hierüber informiert wird.
10. Verfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, daß die zweite Nachricht (MMB) im Falle eines Änderungsauftrages entweder im PUSH-Modus (Drück-/Bring-Modus) oder im PULL-Modus (Zieh-/Hol-Modus) heruntergeladen wird.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die zweite Nachricht (MMB) mit dem Manipulationsauftrag an den Empfänger der ersten Nachricht (MMA) verschickt wird, wobei zur Kennung bzw. Identifizierung der ersten Nachricht (MMA) vorzugsweise deren Identifikationsnummer (IDl) verwendet wird, welche die erste Nachricht (MMA) zwischen der Sendeapplikation (1) oder der VAS- Applikation (7) und einem senderseitigen Netzwerkelement (2) eindeutig kennzeichnet.
12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß beim Versenden einer Nachricht einem senderseitigen Netzwerkelement (2) von der Sendeapplika- tion (1) oder der VAS-Applikation (7) eine oder mehrere der folgenden Informationen bereitgestellt werden:
- Kennzeichnung, daß es sich bei der Nachricht (MMB) um einen Manipulationsauftrag handelt;
- Identifikationsnummer der ersten Nachricht (MMA) , die mani- puliert werden soll;
- Information, daß der Absender eine Rückmeldung über den Ausgang der von ihm initiierten Manipulation anfordert.
13. Verfahren nach einem der vorhergehenden Ansprüche, da- durch gekennzeichnet, daß der Sendeapplikation (1) oder der
VAS-Applikation (7) von einem senderseitigen Netzwerkelement (2) die Information bereitgestellt wird, ob dieses Netzwerkelement (2) die Manipulation gemäß den vorhergehenden Ansprüchen unterstützt und/oder ob der Manipulations-Auftrag von dem Dienstanbieter (Dienstanbieter A) der Sendeapplikation (1) oder der VAS-Applikation (7) angenommen wurde.
14. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß bei Zugehörigkeit der Sendeapplikation (1) bzw. der VAS-Applikation (7) und der Empfangsapplikation (11) zu unterschiedlichen MMS-Umgebungen (MMSEA, MMSEB) von Dienstanbietern einem empfängerseitigen Netzwerkelement (11) von einem senderseitigen Netzwerkelement (1) eine oder mehrere der folgenden Informationen bereitgestellt werden:
- Kennzeichnung, daß es sich bei der zweiten Nachricht (MMB) um einen Manipulationsauftrag handelt;
- Identifikationsnummer der ersten Nachricht (MMA) , die manipuliert werden soll;
- Information, daß der Absender eine Rückmeldung über den Ausgang der von ihm initiierten Manipulation anfordert.
15. Verfahren nach einem der vorhergehenden Ansprüchen, dadurch gekennzeichnet, daß Netzwerkelemente (2, 12) von verschiedenen Dienstanbietern (Dienstanbieter A, Dienstanbieter B) eine eineindeutige, umkehrbare Umwandlung von auf die ers- te und/oder die zweite Nachricht bezogene Identifikationsnummern (IDl, ID3; ID4 , ID6, ID5) vornehmen und die entsprechenden Informationen vorzugsweise verwalten.
16. Verfahren nach einem der vorhergehenden Ansprüche, da- durch gekennzeichnet, daß im Falle eines Manipulationsauftrags, insbesondere einschließlich eines Löschungsbefehls, bei noch nicht erfolgter Benachrichtigung der Empfangsapplikation (11) über die erste Nachricht (MMA) diese erste Nachricht (MMA) in der MMS-Umgebung (MMSEA) des senderseitigen Dienstanbieters (Dienstanbieter A) oder im Zuständigkeitsbereich (MMSEB) des empfängerseitigen Dienstanbieters (Dienstanbieter B) manipuliert, insbesondere gelöscht, wird, wobei bevorzugt die Empfangsapplikation (11) über die Manipulation nicht informiert wird.
17. Verfahren nach einem der Ansprüche 1 bis 15, dadurch ge- kennzeichnet, daß im Falle eines Manipulationsauftrags bei auf der Empfangsseite erfolgter Benachrichtigung, aber noch nicht heruntergeladener erster Nachricht (MMA) diese erste Nachricht (MMA) in der MMS-Umgebung (MMSEB) des empfangssei- tigen Dienstanbieters (Dienstanbieter B) manipuliert wird, wobei die Empfangsapplikation (11) über die Manipulation und über deren Zeitpunkt vorzugsweise informiert wird.
18. Verfahren nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, daß im Falle eines Manipulationsauftrags bei auf der Empfangsseite erfolgter Benachrichtigung, aber noch nicht heruntergeladener erster Nachricht (MMA) diese erste Nachricht (MMA) in der MMS-Umgebung (MMSEA) des senderseitigen Dienstanbieters (Dienstanbieter A) manipuliert wird, wobei die Empfangsapplikation (11) über die Manipulation vor- zugsweise nicht informiert wird.
19. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Empfangsapplikation (11) von einem empfängerseitigen Netzwerkelement (12) eine oder ggf. mehrere der folgenden Informationen, vorzugsweise in einer Benachrichtigung, bereitgestellt werden:
- Information, daß eine lediglich angekündigte, aber noch nicht ausgelieferte erste Nachricht (MMA) nicht mehr zum Herunterladen bereitliegt, oder durch eine neue Nachricht (MMB) geändert worden ist, wobei die Identifizierung der ersten und/oder der zweiten Nachricht (MMA, MMB) vorzugsweise anhand des URI (Uniform Resource Identifier = Speicherplatz) erfolgt ; - Information, daß eine schon ausgelieferte erste Nachricht (MMA) vom Absender manipuliert werden möchte, wobei die Identifizierung der ersten Nachricht (MMA) auf der Empfangsapplikation (11) vorzugsweise anhand einer Nachrichtenreferenz er- folgt, welche vorzugsweise ein URI ist, unter desssen Speicherplatz eine Standard-Text-Nachricht des empfängerseitigen Dienstanbieters (Dienstanbieter B) abgespeichert ist, wobei die URI bevorzugt aus der Identifikationsnummer (IDl) der ersten Nachricht (MMA) oder von einem empfängerseitigen Netz- werkelement (12) festgelegten zweiten Identifikationsnummer (ID2) zusammengesetzt ist;
- Mitteilung über die Manipulation der ersten Nachricht (MMA) auf Seiten eines Dienstanbieters (Dienstanbieter A oder B) ;
- Mitteilung über die Durchführung einer Manipulation und bei Anforderung des Empfängers über das Nichtzurverfugungstehen der manipulierten Nachricht;
- Kennzeichnung, daß die zweite Nachricht (MMB) einen Manipulationsauftrag enthält, der auf der Empfangsapplikation (11) ausgeführt werden soll; - Information, welche bereits ausgelieferte Nachricht (MMA) manipuliert werden soll;
- Information, wann die Manipulation ausgeführt wurde;'
- Information, daß die ausgelieferte zweite Nachricht (MMB) eine nachträglich geänderte Nachricht ist; - Information, welcher Art die vorzunehmende Manipulation ist .
20. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß einem empfängerseitigen Netzwerk- element (12) von der Empfangsapplikation (11) nach ihrer Benachrichtigung über die zweite Nachricht (MMB) mindestens eine der folgenden Informationen bereitgestellt werden: - Information, ob die Empfangsapplikation (11) verstanden hat, daß die zuvor lediglich angekündigte erste Nachricht
(MMA) erfolgreich manipuliert wurde;
- Information, ob die Manipulation der bereits heruntergela- denen ersten Nachricht (MMA) erfolgreich ausgeführt werden konnte;
- Information, ob der Empfänger darüber informiert wurde und/oder zugestimmt hat, daß die bereits heruntergeladene Nachricht (MMA) manipuliert wurde; - bei Mißerfolg der Grund für die nicht erfolgreiche Ausführung;
- Information, ob im Falle eines Änderungsauftrags die Änderung der bereits heruntergeladenen ersten Nachricht (MMA) automatisch (PUSH-Modus) oder auf Veranlassung des Empfängers (PULL-Modus) durchgeführt wurde;
- Information, welcher Art die vorzunehmende Manipulation ist .
21. Verfahren nach einem der vorhergehenden Ansprüche, da- durch gekennzeichnet, daß bei Zugehörigkeit der Sendeapplikation (1) bzw. der VAS-Applikation (7) und der Empfangsapplikation (11) zu unterschiedlichen MMS-Umgebungen (MMSEA, MMSEB) von Dienstanbietern (Dienstanbieter A, Dienstanbieter B) einem senderseitigen Netzwerkelement (2) von einem empfan- gerseitigen Netzwerkelement (12) eine oder mehrere der folgenden Informationen bereitgestellt werden:
- Information, ob der Manipulationsauftrag erfolgreich ausgeführt werden konnte;
- bei Mißerfolg der Grund für die nicht erfolgreiche Ausfüh- rung;
- Information, wann der Manipulationsauftrag ausgeführt wurde; - Information, ob der Manipulationsauftrag automatisch ausgeführt wurde;
- Information, ob der Empfänger über die Manipulation informiert wurde und/oder der Manipulation zugestimmt hat und/oder die Manipulation vom Empfänger veranlaßt wurde;
- Information, daß die bereits heruntergeladene erste Nachricht (MMA) manipuliert wurde, oder die erste Nachricht (MMA) vor einer Änderung noch nicht heruntergeladen war;
- Interims-Identifikationsnummer (ID3) der Nachricht (MMA) , die manipuliert wurde;
- Information, welcher Art die vorgenommene Manipulation ist.
22. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Sendeapplikation (1) oder der VAS-Applikation (7) von einem senderseitigen Netzwerkelement (2) eine oder mehrere der folgenden Informationen bereitgestellt werden:
- Information, ob der Manipulationsauftrag erfolgreich ausgeführt wurde; - bei Mißerfolg der Grund für die nicht erfolgreiche Ausführung;
- Information, daß eine Manipulation aufgrund eines Weiter- leitens der ersten Nachricht (MMA) an eine unbekannte Adresse nicht durchgeführt werden konnte; - Information, wann der Manipulationsauftrag ausgeführt wurde;
- Information, ob der Manipulationsauftrag automatisch durchgeführt wurde;
- Information, ob der Empfänger über die Manipulation infor- miert wurde und/oder oder der Manipulation zugestimmt hat und/oder der Empfänger diese initiiert hat; - Information, daß die bereits heruntergeladene Nachricht (MMA) manipuliert wurde, oder die erste Nachricht (MMA) vor einer Änderung noch nicht ausgeliefert war;
- Identifikationsnummer (IDl) der Nachricht (MMA) , die mani- puliert wurde.
23. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die zweite Nachricht (MMB) mindestens ein von der Sendeapplikation (1) oder der VAS- Applikation (7) beigeordnetes Informationselement umfaßt, welches mindestens eine Bedingung für die Ausführung des manipulierenden Zugriffs enthält.
24. Verfahren nach Anspruch 23, dadurch gekennzeichnet, daß das mindestens eine Informationselement den manipulierenden
Zugriff entsprechend dem Bearbeitungszustand der ersten Nachricht (MMA) angibt .
25. Verfahren nach Anspruch 23 oder 24, dadurch gekennzeich- net, daß mindestens eine der folgenden Bedingungen von der
Sendeapplikation (1) oder der VAS-Applikation (7) mittels des mindestens einen Informationselement festgelegt wird:
- Manipulation der ersten Nachricht (MMA) nur, wenn die erste Nachricht (MMA) noch auf dem Server liegt und der Empfänger noch nicht über diese Nachricht (MMA) benachrichtigt wurde;
- Manipulation der ersten Nachricht auch dann, wenn die Benachrichtigung gesendet wurde, aber die erste Nachricht (MMA) noch nicht heruntergeladen wurde;
- Manipulation der ersten Nachricht (MMA) , wenn der Empfänger diese noch nicht geöffnet bzw. gelesen hat;
- Manipulation der ersten Nachricht (MMA) unabhängig vom Bearbeitungsgrad.
26. Verfahren nach einem der Ansprüche 23 bis 25, dadurch gekennzeichnet, daß dem Informationselement ein Voreinstellungswert (Default Value) zugeordnet wird, der für eine Manipulation entsprechend dem Voreinstellungswert bei nicht näher präzisierter Bedingung steht.
27. Verfahren nach einem der Ansprüche 23 bis 26, dadurch gekennzeichnet, daß mindestens einer der an der Übermittlung der ersten und der zweiten Nachricht (MMA, MMB) beteiligten Dienstanbieter (Dienstanbieter A und/oder Dienstanbieter B) den Manipulationsauftrag auf die eigene oder auf bestimmte Domänen anderer Dienstanbieter begrenzt, vorzugsweise anhand einer Identifizierung des Empfängers (Rufnummer, Mailadresse, ...) oder durch Benutzung einer zusätzlichen Kennzeichnung.
28. Verfahren nach einem der Ansprüche 23 bis 27, dadurch gekennzeichnet, daß der den Manipulationsauftrag enthaltenden zweiten Nachricht (MMB) , die von der Sendeapplikation (1) o- der der VAS-Applikation (7) an ein senderseitiges Netzwerk- element (2) gesendet wird, eine der folgenden Bedingungen zum Ausführen der Manipulation der ersten Nachricht (MMA) beigeordnet wird:
- Manipulation nur vor Benachrichtigung des Empfängers;
- Manipulation nur vor dem Herunterladen, auch nach dem Ver- sand einer Benachrichtigung;
- Manipulation nur, wenn die erste Nachricht (MMA) noch nicht geöffnet bzw. gelesen wurde;
- Manipulation unabhängig vom Bearbeitungszustand der ersten Nachricht (MMA) .
29. Verfahren nach einem der Ansprüche 23 bis 28, dadurch gekennzeichnet, daß der Sendeapplikation (1) oder der VAS- Applikation (7) von einem senderseitigen Netzwerkelement (2) bei der Bestätigung nach dem Versenden der ersten oder zweiten Nachricht (MMA, MMB) mitgeteilt wird, ob dieses Netzwerkelement (2) die besagte bedingte Manipulation unterstützt und/oder ob der bedingte Manipulations-Auftrag von dem sen- derseitigen Dienstanbieter (Dienstanbieter A) angenommen wurde.
30. Verfahren nach einem der Ansprüche 23 bis 29, dadurch gekennzeichnet, daß bei Zugehörigkeit der Sendeapplikation (1) bzw. der VAS-Applikation (7) und der Empfangsapplikation (11) zu unterschiedlichen MMS-Umgebungen (MMSEA, MMSEB) von Dienstanbietern (Dienstanbieter A, Dienstanbieter B) einem empfängerseitigen Netzwerkelement (12) von einem senderseitigen Netzwerkelement (2) eine oder mehrere der folgenden Be- dingungen hinsichtlich der Manipulation der ersten Nachricht (MMA) durch die zweite Nachricht (MMB) übermittelt werden:
- Manipulation nur vor Benachrichtigung des Empfängers;
- Manipulation nur vor dem Herunterladen, auch nach dem Versand einer Benachrichtigung; - Manipulation nur, wenn die erste Nachricht (MMA) noch nicht geöffnet bzw. gelesen wurde;
- Manipulation unabhängig vom Bearbeitungszustand der ersten Nachricht (MMA) .
31. Verfahren nach einem der Ansprüche 23 bis 30, dadurch gekennzeichnet, daß der Empfangsapplikation (11) von einem empfängerseitigen Netzwerkelement (12) eine oder mehrere der folgenden Bedingungen hinsichtlich der Manipulation der ersten Nachricht (MMA) durch die zweite Nachricht (MMB) übermit- telt werden, vorzugsweise bei der Benachrichtigung über die eingetroffene zweite Nachricht (MMB) :
- Manipulation nur vor Benachrichtigung des Empfängers;
- Manipulation nur vor dem Herunterladen, auch nach dem Ver- sand einer Benachrichtigung;
- Manipulation nur, wenn die erste Nachricht (MMA) noch nicht geöffnet bzw. gelesen wurde;
- Manipulation unabhängig vom Bearbeitungszustand der ersten Nachricht (MMA) .
32. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß das Versenden, Empfangen und Manipulieren der Nachrichten (MM) , einschließlich des bedingten Manipulierens, mittels WAP-Nachrichten (Wireless Application Protocol) erfolgt.
33. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Manipulationsaufträge durch Mo- difizieren von vorhandenen Kopf-Feldern {X-Mms-Status ; M-Mms- Supported-Feature) und/oder durch Hinzufügen von zusätzlichen Kopf-Feldern {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 geeigneten WAP- Nachrichten, insbesondere solche nach dem WAP- MMSEncapsulation Standard und insbesondere in mindestens eine der WAP-Nachrichten M-Send . req, M-Send. conf, M-
Notification . ind, M-NotifyResp . req, M-Retrieve . conf , M- Acknowledge . ind, M-Delivery. ind, implementiert werden.
34. Verfahren nach einem der vorhergehenden Ansprüche, da- durch gekennzeichnet, daß die erste Nachricht (MMA) für eine
Rückmeldung über das Ergebnis des Manipulationsauftrags anhand der Identifikationsnummer (ID4) der zweiten Nachricht (MMB) sowie der Transaktions-Identifikationsnummern der ent- sprechenden WAP-Nachrichten, oder anhand eines zusätzlichen Kopf-Feldes identifiziert wird, wobei Feld-Werte des neuen Kopf-Feldes die Identifikationsnummer (IDl) der ersten Nachricht (MMA) enthalten.
35. Telekommunikationseinrichtung, insbesondere zur zumindest teilweisen Durchführung des Verfahrens nach einem der vorhergehenden Ansprüche, mit Mitteln zum Erstellen, Versenden, Empfangen und/oder Verarbeiten einer ersten Nachricht (MMA) , insbesondere einer multimedialen Nachricht vorzugsweise vom MMS-Typ, gekennzeichnet durch Mittel zum Erstellen, Versenden, Empfangen und/oder Verarbeiten einer zweiten Nachricht (MMB) , wobei die zweite Nachricht (MMB) einen unbedingten oder bedingten Manipulationsauftrag zum Manipulieren der zuvor gesendeten ersten Nachricht (MMA) umfaßt .
36. Telekommunikationseinrichtung nach Anspruch 35, gekennzeichnet durch eine Sendeapplikation (1) oder eine VAS- Applikation (7) sowie einer mit diesen Applikationen (1, 7) verbundenen oder verbindbaren Sendeeinheit .
37. Telekommunikationseinrichtung nach Anspruch 35 oder 36, gekennzeichnet durch eine Empfangsapplikation (11) sowie einer mit der Empfangsapplikation (11) verbundenen oder ver- bindbaren Empfangseinheit.
38. Telekommunikationseinrichtung nach einem der Ansprüche 35 bis 37, gekennzeichnet durch eine Prozessoreinheit zum Auswerten von Benachrichtigungen von einem senderseitigen Netzwerkelement (2) hinsichtlich der Unterstützung von unbedingten und/oder bedingten Manipulationsaufträgen, des erfolgreichen oder erfolglosen Ausführens des Manipulationsauf- träges und/oder der Gründe für ein erfolgloses Ausführen des Manipulationsauftrages .
39. Telekommunikationseinrichtung nach einem der Ansprüche 35 bis 38, gekennzeichnet durch eine Prozessoreinheit zum Auswerten von Benachrichtigungen seitens eines empfängerseitigen Netzwerkelements (12) über Informationen hinsichtlich der Ausführung des unbedingten oder bedingten Manipulationsaufträges .
40. Telekommunikationseinrichtung nach Anspruch 39, gekennzeichnet durch eine Sendeeinheit zum Senden von Benachrichtigungen an ein empfängerseitiges Netzwerkelement (12) hinsichtlich des erfolgreichen oder erfolglosen Ausführens des Manipulationsauftrages und/oder der Gründe für ein erfolgloses Ausführen des Manipulationsauftrages.
41. Telekommunikationseinrichtung nach einem der Ansprüche 35 bis 40, dadurch gekennzeichnet, daß es als Mobiltelefon mit einer Sende- und einer Empfangseinheit ausgebildet ist.
42. Telekommunikationseinrichtung nach einem der Ansprüche 35 bis 40, dadurch gekennzeichnet, daß es als Netzwerkelement ausgebildet ist, auf der sich eine VAS-Applikation (7) befin- det .
43. Telekommunikationseinrichtung nach einem der Ansprüche
35 bis 42, dadurch gekennzeichnet, daß die Mittel derart ausgebildet sind, daß sie die Verarbeitung von WAP-Nachrichten, insbesondere solchen nach dem WAP-MMSEncapsulation Standard und insbesondere die WAP-Nachrichten M-Send. req, M-Send . conf, M-Notification . ind, M-NotifyResp . req, M-Retrieve . conf , M- Acknowledge . ind, M-Delivery. ind, mit entsprechend den im Rah- men der Manipulationsaufträge auszutauschenden Informationen modifizierten Kopffeldern und/oder zusätzlichen Kopffeldern gestatten.
44. Telekommunikationseinrichtung nach einem der Ansprüche 35 bis 43, gekennzeichnet durch Mittel zum Erzeugen eines Informationselements sowie Mittel zum Zuordnen dieses Informationselements durch die Sendeapplikation (1) oder die VAS- Applikation (7) zur zweiten Nachricht (MMB) , wobei das Infor- mationselement mindestens eine Bedingung für die Ausführung des manipulierenden Zugriffs enthält.
45. Telekommunikationseinrichtung nach Anspruch 44, gekennzeichnet durch Mittel zum Ausführen des Manipulationsauf- trags .
46. Netzwerkelement (2; 12), insbesondere eines Funkkommunikationssystems und insbesondere zur netzwerkseitigen Durchführung der Verfahrensschritte nach einem der Ansprüche 1 bis 34, mit Mitteln zum Empfangen und Weiterleiten von einer von Telekommunikationseinrichtungen gemäß einem der Ansprüche 35 bis 45 gesendeten ersten Nachricht (MMA) , insbesondere einer multimediale Nachrichtn, vorzugsweise vom MMS-Typ, gekennzeichnet durch Mittel zum Empfangen, Verarbeiten und/oder Weiterleiten einer zweiten Nachricht (MMB) mit einem Manipulationsauftrag, welcher sich auf die empfangene und ggf. schon weitergeleitete erste Nachricht (MMA) bezieht, um einen manipulierenden Zugriff auf die erste Nachricht (MMA) zu veranlassen oder zu vermitteln.
47. Netzwerkelement nach Anspruch 46, gekennzeichnet durch Mittel zum Empfangen und Weiterleiten und/oder Erzeugen sowie Versenden von Mitteilungen an ein anderes Netzwerkelement (12; 2) und/oder eine senderseitige und/oder eine empfänger- seitige Empfangsapplikation (1; 11) , wobei diese Mitteilungen die von dem Absender festgelegten Bedingungen für die Ausführung eines in der zweiten Nachricht (MMB) spezifizierten Ma- nipulationsaufträges, des erfolgreichen oder erfolglosen Aus- führens des bedingten Manipulationsauftrages und/oder der Gründe für ein erfolgloses Ausführen des bedingten Manipulationsauftrages betreffen.
48. Netzwerkelement nach Anspruch 46 oder 47, gekennzeichnet durch Mittel zum Ausführen des Manipulationsauftrags.
49. Netzwerkelement nach Anspruch 48, dadurch gekennzeichnet, daß die erste Nachricht (MMA) auf einem Netzwerkelement (2; 12) und/oder auf einer Empfangsapplikation (11) einer Empfangseinheit manipulierbar ist, insbesondere löschbar und/oder änderbar.
50. Netzwerkelement nach einem der Ansprüche 46 bis 49, da- durch gekennzeichnet, daß die Mittel zum Empfangen, Verarbeiten und/oder Weiterleiten der zweiten Nachricht (MMB) von WAP-Nachrichten, insbesondere solche nach dem WAP- MMSEncapsulation Standard und insbesondere den WAP- Nachrichten M-Send. req, M-Send. conf, M-Notification . ind, M- NotifyResp . req, M-Retrieve . conf , M-Acknowledge . ind und M- Delivery. ind mit entsprechend den im Rahmen der Manipulationsaufträge auszutauschenden Informationen modifizierten Kopf-Feldern und/oder zusätzlichen Kopf-Feldern, Gebrauch machen.
51. Softwareprogramm, welches auf einer Vorrichtung mit einem Prozessor, insbesondere einer Telekommunikationseinrichtung und insbesondere einer solchen gemäß einem der Ansprüche 35 bis 45, oder einem Netzwerkelement, insbesondere eines solchen gemäß einem der Ansprüche 46 bis 50, derart ablaufen kann, daß das Softwareprogramm mitsamt der Vorrichtung die Verfahrensschritte auf der Seite der Vorrichtung gemäß einem der Ansprüche 1 bis 34 ausführt oder veranlaßt.
52. Softwareprogramm, welches in eine Vorrichtung mit einem Prozessor, insbesondere einer Telekommunikationseinrichtung und insbesondere einer solchen gemäß einem der Ansprüche 35 bis 45 oder einem Netzwerkelement und insbesondere eines solchen gemäß einem der Ansprüche 46 bis 50, ladbar ist, so daß die derart programmierte Vorrichtung einschließlich des Prozessors fähig oder angepaßt ist, die Verfahrensschritte gemäß einem der Ansprüche 1 bis 34 auszuführen oder zu veranlassen.
EP02702291A 2001-02-02 2002-01-21 Verfahren und vorrichtung zur manipulation übertragener nachrichten Withdrawn EP1356645A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP02702291A EP1356645A2 (de) 2001-02-02 2002-01-21 Verfahren und vorrichtung zur manipulation übertragener nachrichten

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
DE10104713 2001-02-02
DE2001104713 DE10104713A1 (de) 2001-02-02 2001-02-02 Verfahren und Vorrichtungen zum Zugreifen auf Nachrichten
EP01115495 2001-06-27
EP01115495 2001-06-27
EP02702291A EP1356645A2 (de) 2001-02-02 2002-01-21 Verfahren und vorrichtung zur manipulation übertragener nachrichten
PCT/EP2002/000571 WO2002063839A2 (de) 2001-02-02 2002-01-21 Verfahren und vorrichtung zur manipulation übertragener nachrichten

Publications (1)

Publication Number Publication Date
EP1356645A2 true EP1356645A2 (de) 2003-10-29

Family

ID=26008397

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02702291A Withdrawn EP1356645A2 (de) 2001-02-02 2002-01-21 Verfahren und vorrichtung zur manipulation übertragener nachrichten

Country Status (5)

Country Link
US (1) US20030086438A1 (de)
EP (1) EP1356645A2 (de)
JP (1) JP2004526352A (de)
DE (1) DE10104713A1 (de)
WO (1) WO2002063839A2 (de)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9246975B2 (en) 2000-03-17 2016-01-26 Facebook, Inc. State change alerts mechanism
US7624172B1 (en) 2000-03-17 2009-11-24 Aol Llc State change alerts mechanism
US7024462B1 (en) * 2000-10-20 2006-04-04 Amacis Limited Electronic message routing
KR100452343B1 (ko) * 2001-12-28 2004-10-12 에스케이텔레텍주식회사 기계어 코드 실행영역을 포함하는 이동통신 단말기용 파일을 기록하는 저장매체 및 그를 이용한 파일 실행방법
US7099680B2 (en) * 2002-05-03 2006-08-29 M/A-Com Private Radio Systems, Inc. Data interface protocol for two-way radio communication systems
AU2002348946A1 (en) * 2002-10-18 2003-06-10 Nokia Corporation Selectively recalling sent messages
US7640306B2 (en) 2002-11-18 2009-12-29 Aol Llc Reconfiguring an electronic message to effect an enhanced notification
DE10314915A1 (de) * 2003-04-01 2004-11-04 T-Mobile Deutschland Gmbh Verfahen zur sofortigen Zustellung von Emails an mobile Telekommunikationsendgeräte
DE10328372A1 (de) * 2003-06-24 2005-01-27 Siemens Ag Verfahren zum effizienten Verwalten von Speicherplatz der Speichervorrichtung eines Funkkommunikationsgeräts sowie zugehöriges Funkkommunikationsgerät
DE10340865B3 (de) 2003-09-04 2004-07-15 Siemens Ag Verfahren und System zur Handhabung von Daten sowie Automatisierungssystem mit mehreren Automatisierungseinrichtungen
US7088993B2 (en) * 2003-09-24 2006-08-08 Telefonaktiebolaget Lm Ericsson(Publ) Optimized message notification
JP4396639B2 (ja) * 2003-10-15 2010-01-13 三菱電機株式会社 路車間通信システム、基地局装置、及び移動局装置
EP1530380A1 (de) * 2003-11-10 2005-05-11 Siemens Aktiengesellschaft Verfahren zum Bereithalten einer Nachricht für einen Empfänger dem Empfänger
DE10352377A1 (de) * 2003-11-10 2005-06-16 Siemens Ag Verfahren zum Bereithalten einer Nachricht für einen Empfänger
KR100584319B1 (ko) * 2003-12-08 2006-05-26 삼성전자주식회사 수신측 문자메시지 삭제 가능한 이동통신단말기 및 그의문자메시지 전송 및 삭제 방법
JP4511167B2 (ja) * 2003-12-26 2010-07-28 株式会社日本総合研究所 通信端末、電子メール送受信方法、および電子メール送受信プログラム
EP1557988A1 (de) * 2004-01-23 2005-07-27 Motorola, Inc. Verfahren und Vorrichtung zur drahtlosen Nachrichtenübertragung
CN100349474C (zh) * 2004-07-09 2007-11-14 华为技术有限公司 一种多媒体消息业务中推送通知的处理方法
KR100696142B1 (ko) * 2004-09-20 2007-03-20 삼성전자주식회사 에스엠에스 메시지 발신 취소 및 수신 메시지 보관 장치및 방법
KR101155335B1 (ko) * 2005-01-07 2012-06-11 엘지전자 주식회사 이동통신 단말기의 멀티미디어 메시지 동작방법
CN100348007C (zh) * 2005-03-02 2007-11-07 北京立通无限科技有限公司 一种通过短信触发gprs自动推送电子邮件到客户端的方法
US9282081B2 (en) * 2005-07-28 2016-03-08 Vaporstream Incorporated Reduced traceability electronic message system and method
KR100710231B1 (ko) * 2005-10-10 2007-04-20 엘지전자 주식회사 멀티미디어 메시지의 예약 전송 취소 방법 및 이를 위한 이동통신 단말기 및 이를 위한 시스템
CN1988512B (zh) * 2005-12-23 2010-10-13 国际商业机器公司 支持基于应用的多媒体消息发送接收的设备、方法和系统
EP1944944A1 (de) * 2007-01-12 2008-07-16 Thomson Licensing System und Verfahren zur Kombination von Zieh- und Schiebebetrieb
CN101595369B (zh) * 2007-02-15 2011-09-28 日本先锋公司 通信终端装置、通信管理装置以及通信方法
US8073122B2 (en) * 2007-06-20 2011-12-06 Microsoft Corporation Message recall using digital rights management
US8589493B2 (en) * 2007-08-17 2013-11-19 International Business Machines Corporation Sending related information to indirect email recipients
FR2941344A1 (fr) * 2009-01-22 2010-07-23 St Nxp Wireless France Procede perfectionne de traitement de minimessages (sms) et appareil de communication sans fil permettant un tel traitement.
US9130779B2 (en) * 2009-06-02 2015-09-08 Qualcomm Incorporated Method and apparatus for providing enhanced SMS/EMS/MMS
US9477947B2 (en) * 2009-08-24 2016-10-25 International Business Machines Corporation Retrospective changing of previously sent messages
CN102045267B (zh) * 2009-10-16 2013-01-09 华为技术有限公司 消息召回的方法及装置
US8625753B1 (en) * 2011-06-03 2014-01-07 Sprint Communications Company L.P. Delivering recallable messages via internet or telephony communicaiton paths
TWI647609B (zh) * 2017-04-14 2019-01-11 緯創資通股份有限公司 即時通訊方法、系統及電子裝置與伺服器
CN119228541A (zh) * 2018-04-27 2024-12-31 区块链控股有限公司 区块链网络划分
US10693825B2 (en) * 2018-06-06 2020-06-23 T-Mobile Usa, Inc. Systems and methods for editing, recalling, and deleting messages
US12323426B2 (en) * 2021-05-13 2025-06-03 Skypod, LLC Parameter-triggered multimedia sharing system

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5623538A (en) * 1995-08-30 1997-04-22 Lucent Technologies Inc. Shared distribution of internal message storage facilities by a plurality of communication terminals
US5918158A (en) * 1996-07-24 1999-06-29 Lucent Technologies Inc. Two-way wireless messaging system
US5940740A (en) * 1996-10-25 1999-08-17 At&T Wireless Services, Inc. Method and apparatus for message transmission verification
US5943398A (en) * 1997-04-02 1999-08-24 Lucent Technologies Inc. Automated message-translation arrangement
US5978836A (en) * 1997-07-28 1999-11-02 Solectron Corporation Workflow systems and methods
EP0896485A3 (de) * 1997-08-07 2000-03-15 Samsung Electronics Co., Ltd. Verfahren zur Manipulation von Kurznachrichten mit übereinstimmender Mobilterminal und Kurznachrichtzentrum
FI973945A7 (fi) * 1997-10-13 1999-04-14 Nokia Corp Lyhytsanomia välittävä tiedonsiirtojärjestelmä
US20010045885A1 (en) * 1998-08-20 2001-11-29 Richard J. Tett System and method retrieving and displaying paging messages
FI112151B (fi) * 1999-12-23 2003-10-31 Nokia Corp Sanoman välitys
WO2001055863A1 (en) * 2000-01-28 2001-08-02 Ibeam Broadcasting Corporation A system and method for performing broadcast-enabled disk drive replication in a distributed data delivery network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO02063839A2 *

Also Published As

Publication number Publication date
WO2002063839A2 (de) 2002-08-15
JP2004526352A (ja) 2004-08-26
US20030086438A1 (en) 2003-05-08
WO2002063839A3 (de) 2003-02-13
DE10104713A1 (de) 2002-08-08

Similar Documents

Publication Publication Date Title
EP1356645A2 (de) Verfahren und vorrichtung zur manipulation übertragener nachrichten
DE602004005319T2 (de) Nachrichtenverwaltung
DE69933760T2 (de) System und verfahren zur implementierung eines beantwortungsdienstes
EP1358742A2 (de) Verfahren zur nachrichtenversendung aus einem mms-system und einrichtung hierfür
EP1609277B1 (de) Verfahren zur sofortigen zustellung von emails an telekommunikationsendgeräte
WO2004109998A1 (de) Verfahren zum übertragen von nachrichten in einem auf mms basierten kommunikationssystem
DE10117894A1 (de) Eingangsbestätigung von Multimedianachrichten
EP1393524A1 (de) Verfahren zur handhabung einer nachricht mit multimedialem bezug
WO2004015939A1 (de) Verfahren und system zum blockieren von unerwünschten nachrichten
EP1283636B1 (de) Multimedialer Nachrichtendienst mit dienstanbieterübergreifender Antwortvergebührungs-Funktionalität
DE102004037338B4 (de) Kommunikationssystem, Verfahren zum Steuern eines Kommunikationssystems, Server, Verfahren zum Betreiben eines Servers, Kommunikationsendgerät und Verfahren zum Betreiben eines Kommunikationsendgeräts
EP1493295B1 (de) Verfahren zur bertragung von daten, insbesondere mit multim edialen inhalten, in einem mobilfunknetz
WO2004021663A1 (de) Verfahren sowie vorrichtung zur datenquellenspezifischen kennzeichnung von push-nutzdaten
EP1508228B1 (de) Verfahren und Vorrichtungen zur Nachrichtenübertragung
EP1867182A2 (de) Umleiten einer multimedianachricht durch eine multimedianachricht-relaiseinrichtung in abhängigkeit einer umleitungs-anforderungsnachricht
WO2004006593A1 (de) Mms-nachrichtenübertragungsverfahren und -system
WO2005046265A1 (de) Verfahren zum bereithalten einer nachricht für einen empfänger
EP1303090B1 (de) Verfahren zur Übertragung von Daten
EP1352500B1 (de) Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz
DE60210180T2 (de) Verfahren zur Nachrichtenübermittlung an eine elektronische Kommunikationseinrichtung
EP2027685A1 (de) Verfahren zur steuerung und benutzerspezifischen anpassung eines multimedia messaging dienstes
WO2001001691A1 (de) Terminal mit einem codierer und decodierer für mpeg4-dateien
EP1502398A1 (de) Verfahren zur erstellung einer repr sentation von mindestens einer multimedia-nachricht, zugeh riges funkkommunikations- netzwerk sowie subsystem
EP1878181A1 (de) Verfahren und kommunikationseinrichtung zur handhabung eines mms-versionskonflikts

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030716

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

RIC1 Information provided on ipc code assigned before grant

Ipc: 7H 04L 12/58 A

Ipc: 7H 04L 29/06 B

Ipc: 7H 04Q 7/22 B

17Q First examination report despatched

Effective date: 20040406

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20050906