DE10104713A1 - Verfahren und Vorrichtungen zum Zugreifen auf Nachrichten - Google Patents

Verfahren und Vorrichtungen zum Zugreifen auf Nachrichten

Info

Publication number
DE10104713A1
DE10104713A1 DE2001104713 DE10104713A DE10104713A1 DE 10104713 A1 DE10104713 A1 DE 10104713A1 DE 2001104713 DE2001104713 DE 2001104713 DE 10104713 A DE10104713 A DE 10104713A DE 10104713 A1 DE10104713 A1 DE 10104713A1
Authority
DE
Germany
Prior art keywords
message
mms
user agent
manipulation
information
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
DE2001104713
Other languages
English (en)
Inventor
Josef Laumen
Andreas Schmidt
Markus Trauberg
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
Original Assignee
Siemens AG
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 filed Critical Siemens AG
Priority to DE2001104713 priority Critical patent/DE10104713A1/de
Priority to EP02702291A priority patent/EP1356645A2/de
Priority to JP2002563667A priority patent/JP2004526352A/ja
Priority to PCT/EP2002/000571 priority patent/WO2002063839A2/de
Priority to US10/068,702 priority patent/US20030086438A1/en
Publication of DE10104713A1 publication Critical patent/DE10104713A1/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

Abstract

Es wird ein Verfahren vorgestellt, das es ermöglicht, eine vorzugsweise über ein Mobilfunksystem und/oder das Internet versendete erste Nachrichten, insbesondere einer multimedialen Nachricht, vorzugsweise vom MMS-Typ, mittels einer nach der ersten Nachricht versendeten zweiten Nachricht zu manipulieren, beispielsweise zurückzurufen oder zu ändern. Gleichfalls wird eine Sende- und/oder Empfangseinheit mit Mitteln zum Erstellen, Versenden, Empfangen und/oder Verarbeiten einer ersten Nachricht offenbart, welche Mittel zum Einstellen, Versenden, Empfangen und/oder Verarbeiten einer zweiten Nachricht mit einem Manipulationsauftrag zum Manipulieren der zuvor gesendeten ersten Nachricht umfaßt. Zudem wird ein Kommunikationssystem mit mindestens einem Netzwerkelement beschrieben, welches Mittel zum Empfangen, Verarbeiten und/oder Weiterleiten einer zweiten Nachricht mit einem Manipulationsauftrag umfaßt, welcher sich auf eine empfangene und ggf. schon weitergeleitete erste Nachricht bezieht, um einen manipulierenden Zugriff auf die erste Nachricht zu veranlassen oder zu vermitteln.

Description

Die Erfindung betrifft ein Verfahren zum Zugreifen auf eine erste Nachricht, insbesondere eine multimediale Nachricht vorzugsweise vom MMS-Typ, wobei die erste Nach­ richt mittels einer Sendeapplikation einer Sendeeinheit an eine Empfangsapplikation einer Empfangseinheit gesen­ det wird.
Des weiteren betrifft die Erfindung eine Sende- und/oder Empfangseinheit mit Mitteln zum Erstellen, Versenden, Empfangen und/oder Verarbeiten einer ersten Nachricht, insbesondere einer multimedialen Nachricht vorzugsweise vom MMS-Typ.
Zudem betrifft die Erfindung ein Kommunikationssystem, insbesondere Funkkommunikationssystem, mit mit Sende- und/oder Empfangseinheiten kommunizierfähigen Netzwerk­ elementen, welche Mittel zum Empfangen und Weiterleiten von Nachrichten, insbesondere multimedialen Nachrichten vorzugsweise vom MMS-Typ, umfassen.
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 Servi­ ce (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 Sys­ tem Aspects; Service Aspects; Stage 1; Multimedia Messa­ ging Service (MMS). Nachrichten mit multimedialen Inhal­ ten werden im folgenden zur besseren Abgrenzung von den Textnachrichten des SMS nur noch kurz MMs (MM - Multime­ dia 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 zwi­ schen dem sogenannten PUSH-Modus (Drück-/Bring-Modus), bei dem eine ankommende mm unverzüglich dem Empfänger zu­ gestellt wird, und dem sogenannten PULL-Modus (Zieh-/Hol- Modus), bei dem der Empfänger zunächst über eine neu ein­ getroffene mm informiert wird und daraufhin selbst ent­ scheiden kann, wann er diese mm auf sein Endgerät herun­ terlädt, unterschieden wird. Diese bekannten Zusammenhän­ ge sind in Fig. 1 verdeutlicht.
Nach dem bisherigen Stand der Technik ist eine Implemen­ tierung von MMS lediglich über WAP (WAP - Wireless Appli­ cation Protocol) realisierbar. Zur Überbrückung der Luft­ schnittstelle zwischen einem MMS-tauglichen Endgerät und dem WAP Gateway ist die Benutzung des WAP WSP (WSP - Wi­ reless 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, Release 2000, Third Generation Partnership Project, Technical Specifi­ cation Group Services and System Aspects, Service Aspects, Stage 1, Multimedia Messaging Service (MMS); 3G TS 23.140 version 4.0.0, Release 4, Third Generation Partnership Project, Technical Specification Group Termi­ nals, Multimedia Messaging Service (MMS), Functional Description, Stage 2.
Fig. 2 zeigt ein sogenanntes Transaktions-Fluß- (Transaction Flow)Diagramm nach heutigem Stand der Tech­ nik gemäß 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, in dem der Austausch der WAP Nachrichten zwischen den drei beteiligten Instanzen (MMS User Agent A, MMS Relay und MMS User Agent B) beim Versand und Empfang einer MM dargestellt ist. Unter MMS User Agent versteht man eine Applikation auf einem Mobil­ funkgerät oder auf einem an ein Mobilfunkgerät ange­ schlossenen Gerät (z. B. Laptop, o. ä.), die MMS reali­ siert. Ein MMS Relay ist ein Netzwerkelement im Zustän­ digkeitsbereich des MMS Service Providers, das den MMS User Agents die MMS-Funktionalität zur Verfügung stellt.
Im folgenden wird anhand des bekannten Transaktions-Fluß- Diagramms in Fig. 2 ("User Agent A schickt MMA an User Agent B") der Austausch der WAP Nachrichten beschrieben. Dabei wird zunächst vereinfachend davon ausgegangen, daß MMS User Agent A und MMS User Agent B den MMS vom glei­ chen MMS Service Provider in Anspruch nehmen: Die im MMS User Agent A erzeugte MMA wird mit der WAP Nachricht M- Send.req an das MMS Relay geschickt. Daraufhin erhält das MMS User Agent A die WAP Nachricht M-Send.conf zurück, mit der der korrekte Empfang der MMA vom MMS Relay bestä­ tigt wird. In ihr ist auch eine vom MMS Relay festgeleg­ te, möglicherweise individuelle, Identifikationsnummer ID1 für die abgeschickte MMA enthalten. Danach informiert das MMS Relay das MMS User Agent B mit der WAP Nachricht M-Notification.ind über den Speicherplatz (URI - Uniform Resource Identifier) der neu eingetroffenen und zum Her­ unterladen (Download) bereitliegenden MMA. Das MMS Relay erhält daraufhin z. B. mit der WAP Nachricht M- NotifyResp.req eine Bestätigung, daß die Benachrichtigung über die eingetroffene MMA (M-Notification.ind) erfolg­ reich zugestellt worden ist. Zu diesem Zeitpunkt hat das MMS Relay noch keine Nachrichten-ID für die zum Herunter­ laden bereitliegende mm vergeben. Beim Austausch der bei­ den WAP Nachrichten M-Notification.ind und M- NotifyResp.req wird nur eine für diese Benachrichtigung individuelle Transaktions-Identitätsnummer (Transaction- ID) ausgetauscht. Das MMS User Agent B fordert dann mit Hilfe der WAP Nachricht WSP GET, mit der der URI an das MMS Relay geschickt wird, die Auslieferung der MMA an. Mit der WAP Nachricht M-Retrieve.conf wird dem MMS User Agent B daraufhin vom MMS Relay die gewünschte MMA zuge­ stellt. Hierbei wird die MMA über die vom MMS Relay ver­ gebene, möglicherweise individuelle, Identifikationsnum­ mer ID2 identifiziert. Mit der WAP Nachricht M- Acknowledge.ind wird der korrekte Empfang der MMA vom MMS User Agent B 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 MMS Relay dem nachkommen, indem die WAP Nachricht M-Delivery.ind an das MMS User Agent A geschickt wird.
Fig. 3 zeigt eine bekannte mögliche MMS Architektur, bei der die beiden am Austausch einer mm beteiligten MMS User Agents (MMS User Agent A mit Bezugszeichen 1 und MMS User Agent B mit Bezugszeichen 11) den MMS von verschiedenen MMS Service Providern (MMS Service Provider A und MMS Service Provider B) in Anspruch nehmen. In diesem Fall ist eine Weiterleitung der mm zwischen den MMSEs (MMSE - Multimedia Messaging Service Environment) der beteiligten MMS Service Provider nötig. Das Bezugszeichen 4 kenn­ zeichnet die MMSE des Service Providers A und das Bezugs­ zeichen 14 die MMSE des Service Providers B. Die Weiter­ leitung einer mm zwischen zwei MMSEs und hierbei genauer zwischen der Sendeapplikation MMS Relay A mit Bezugszei­ chen 2 und der Empfangsapplikation MMS Relay B mit Be­ zugszeichen 12) geschieht über SMTP (SMTP - Simple Mail Transfer Protocol), s. 3G TS 23.140 version 4.0.0, Re­ lease 4, Third Generation Partnership Project, Technical Specification Group Terminals, Multimedia Messaging Ser­ vice (MMS) Functional Description, Stage 2, z. B. durch das Internet (IP - Internet Protocol mit Bezugszeichen 20). Das Protokoll SMTP ist in Fig. 3 mit dem Bezugszei­ chen 22 bezeichnet. Das Mobilfunknetz wird in Fig. 3 wie allgemein üblich als PLMN (PLMN - Public Land Mobile Net­ work) 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, dem MMS User Agent B mit Bezugszeichen 11, zugestellt werden soll. Wird davon Gebrauch gemacht, ist eine Zwischenspei­ cherung der MM im MMSEA 4 (genauer: einem Speicher MMS Server A mit Bezugszeichen 3) des Absenders (MMS User Agent A) 1 bis zum Erreichen dieser Frist vorgesehen, s. Report of the 3GPP TSG-T2 SWG3 MMS Ad Hoc Meeting #5 in Sophia Antipolis, France 10-12 October 2000; T-doc: T2M00092; chapter 7; 3GPP TSG-T2 SWG3. Erst danach wird die MM an das MMSEB 14 des Empfängers (MMS User Agent B) 11 übermittelt. Weiterhin kann beim Editieren einer jeden mm auch eine gewünschte Gültigkeitsdauer angegeben wer­ den. Die Speicherung einer mm bis zum Ablauf der Gültig­ keit bzw. bis zum vorherigen Download der MM durch den MMS User Agent B 11 soll im MMSEB 14 (genauer: in einem Speicher MMS Server B mit Bezugszeichen 13) des Empfän­ gers 11 stattfinden, s. Report of the 3GPP TSG-T2 SWG3 MMS Ad Hoc Meeting #5 in Sophia Antipolis, France 10-12 October 2000; T-doc: T2M00092; chapter 7; 3GPP TSG-T2 SWG3.
Bei den eingangs genannten Verfahren und Vorrichtungen ist eine Nachricht vom Absender bzw. Auftraggeber bear­ beitbar, solange sie sich noch in der Sendeapplikation MMS User Agent A 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 Versendung von elektronischer Post (Emails) ü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 Absen­ ders/Empfängers orientiertere Bearbeitung bzw. Beeinflus­ sung von Nachrichten ermöglicht wird.
Diese Aufgabe wird bei dem Verfahren der eingangs genann­ ten Art dadurch gelöst, daß eine zweite Nachricht mit ei­ nem 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 Sende- und/oder Empfangseinheit der eingangs genannten Art gelöst Mittel zum Erstellen, Versenden, Empfangen und/oder Verarbeiten einer zweiten Nachricht, wobei die zweite Nachricht einen Manipulationsauftrag zum Manipulieren einer zuvor gesen­ deten ersten Nachricht umfaßt. Unter dem Begriff Sende- und/oder Empfangseinheit werden insbesondere Mobilfunkte­ lefone sowie mit dem Internet verbundene Kommunikations­ einheiten einschließlich Computer verstanden. Die erfin­ dungsgemäßen Mittel zum Erstellen, Versenden, Empfangen und/oder Verarbeiten der zweiten Nachricht umfassen - ne­ ben den gerätetechnischen Voraussetzungen - insbesondere Softwarelösungen, die nachfolgend genauer vorgestellt werden und bevorzugt Modifikationen von WAP-Nachrichten mit veränderten und/oder neu definierten Kopffeldern dar­ stellen bzw. diese verarbeiten können.
Zudem wird diese Aufgabe bei einem Kommunikationssystem der eingangs genannten Art dadurch gelöst, daß mindestens eines der Netzwerkelemente Mittel zum Empfangen, Verar­ beiten und/oder Weiterleiten einer zweiten Nachricht mit einem Manipulationsauftrag umfaßt, welcher sich auf eine empfangene und ggf. schon weitergeleitete erste Nachricht bezieht, um einen manipulierenden Zugriff auf die erste Nachricht zu veranlassen oder zu vermitteln. Im Sinne dieser Erfindung wird unter einem Kommunikationssystem ein System mit Netzwerkelementen verstanden, die eine Kommunikation zwischen mehreren Sende- und/oder Empfangs­ einheiten, insbesondere mehreren Mobiltelefonen und/oder ans Internet angeschlossenen Rechnern, ermöglichen. Das Kommunikationssystem einschließlich Funkkommunikations­ systeme wird üblicherweise von Service Providern betrie­ ben. Die erfindungsgemäßen Mittel zum Empfangen, Verar­ beiten und/oder Weiterleiten der zweiten Nachricht schließen außen den notwendigen Hardware-Elementen insbe­ sondere Sofware ein, die im folgenden genauer beschrieben wird und bevorzugt Modifikationen von WAP-Nachrichten mit ensprechend angepaßten oder neu definierten Kopffeldern 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 Er­ findung bei der Versendung von Nachrichten über Funk, ü­ ber Mobilfunksysteme, zwischen Mobilfunksystemen, insbe­ sondere über ein Inter-Operator-IP-backbone, zwischen Mo­ bilfunknetzen 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 Sende­ applikation einer Sendeeinheit über mindestens ein Netz­ werkelement 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 Sende­ einheit 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 Ser­ vice Providers und mindestens ein empfängerseitiges Netz­ werkelement eines Service Providers an die Empfangsappli­ kation gesendet. Hierbei können das mindestens eine sen­ derseitige Netzwerkelement und das mindestens eine emp­ fängerseitige Netzwerkelement dem Zuständigkeitsbereich eines einzigen Service Providers angehören oder sogar - im einfachsten Fall - identisch sind.
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 Netz­ werkelement, 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 sender­ seitigen oder des empfängerseitigen Service Providers ma­ nipuliert, vorzugsweise ohne die Empfangsapplikation über die Manipulation zu benachrichtigen. Ist die Benachrich­ tigung über die erste Nachricht schon an die Empfangssei­ te hingegen erfolgt, aber ist diese erste Nachricht noch nicht heruntergeladen, wird vorzugsweise die erste Nach­ richt im Zuständigkeitsbereich des senderseitigen Service Providers ohne Informieren der Empfangsapplikation mani­ puliert, oder die Manipulation erfolgt im Zuständigkeits­ bereich des empfängerseitigen Service Providers, wobei bevorzugt die Empfangsapplikation über die Manipulation und deren Zeitpunkt informiert wird.
Die erfindungsgemäße Manipulation ist nicht auf die bei­ den Dienstmerkmale Zurückrufen und Ändern beschränkt. Auch Aufträge zu einer nachträglichen Weiterleitung (For­ warding), ein nachträgliches Anhängen der zweiten Nach­ richt an die erste Nachricht, usw. wird im Sinne dieser Erfindung unter einer Manipulation verstanden. Im folgen­ den werden der Rückruf- und der Änderungs-Auftrag genauer beschrieben.
Gemäß der Erfindung kann das Zurückrufen (im Rahmen die­ ser Offenbarung mit "Recall" bezeichnet) einer MM zumin­ dest immer noch solange möglich sein, bis sie der Empfän­ ger in einen anderen Ordner verschoben, an einen anderen Empfänger weitergeleitet oder geöffnet hat.
Das nachträgliche Ändern (im Rahmen dieser Offenbarung mit "Replace" bezeichnet) einer MM hingegen ist vorteilhafterweise auch dann noch möglich, wenn der Empfänger die MM schon "angefaßt" hat. In diesem Fall wird der Emp­ fänger vorzugsweise umgehend über eine nachträgliche Än­ derung der entsprechenden M informiert, entweder durch eine Benachrichtigung (Notification), damit er den Down­ load der aktualisierten mm nachträglich selbst einleiten kann (Pull-Modus), oder gleich durch eine automatische Zustellung der aktualisierten mm (Push-Modus).
Des weiteren ist Gegenstand der Erfindung die Implemen­ tierung des erfindungsgemäßen Verfahrens in WAP durch die Modifikation von vorhandenen Header-Feldern oder das Hin­ zufügen von neu definierten Header-Feldern in die betrof­ fenen WAP Nachrichten des WAP-MMSEncapsulation Standards, s. WAP-209-MMSEncapsulation, Release 2000; Wireless Ap­ plication Protocol; WAP Multimedia Messaging Service; Message Encapsulation; MMS Proposed SCD 1.0.
Ebenso ist das entsprechende binäre Encoding, wie weiter unten für ein Ausführungsbeispiel 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 Multimedia Messaging Service (MMS) Transak­ tions-Diagramm nach dem Stand der Technik;
Fig. 3 eine schematische Darstellung einer Multimedia Messaging Architektur nach dem Stand der Tech­ nik;
Fig. 4 ein Multimedia Messaging Service (MMS) mit ei­ ner Manipulationsmöglichkeit einer ersten Nach­ richt gemäß der vorliegenden Erfindung;
Fig. 5 eine Codierung von neu definierten Kopffeldern (Header-Felder);
Fig. 6 Ergänzungen im bekannten Kopffeld X-Mms-Status;
Fig. 7 neu eingeführtes Kopffeld X-Mms-Original- Message-Status; und
Fig. 8 neu eingeführtes Kopffeld X-Mms-Original- Message-ID.
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 Service Providers (Service Provider A und Service Provider B) ausgegangen: Nach dem Verschicken der ersten Nachricht MMA wird der Sendeapplikation MMS User Agent A 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 MMS Relay A des Service Providers A erzeugt und kennzeichnet die MMA innerhalb der sendersei­ tigen Schnittstelle MMS User Agent A/MMS Relay A ein­ deutig. Bei der empfängerseitigen Zustellung der MMA vom Netzwerkelement MMS Relay B des Service Providers B zur Empfangsapplikation MMS User Agent B durch die WAP Nach­ richt M-Retrieve.conf wird ebenfalls eine Message-ID (ID2 in Fig. 2) übermittelt. Diese Identifikationsnummer ID2 wird möglicherweise vom MMS Relay B neu erzeugt und dient zur eindeutigen empfängerseitigen Kennzeichnung der MMA innerhalb der Schnittstelle MMS Relay B/MMS User Agent B.
Zur Übermittlung der MMA zwischen dem senderseitigen MMS Relay A und dem empfängerseitigen MMS Relay B kann ID1 in eine Interim-Identifikationsnummer (ID3) umgewandelt wer­ den, welche die MMA zwischen den verschiedenen Systemen identifiziert. Insbesondere sollte ID3 global eindeutig sein. Z. B. enthält ID3 Informationen hinsichtlich des Service Providers A, der ID1 sowie dem Zeitpunkt der ID- Umwandlung. Dazu muß das senderseitige MMS Relay A die Information bzw. die Möglichkeit besitzen, diese Umwand­ lung wieder rückgängig zu machen, z. B. für Auslieferungs­ berichte. Um intern übersichtliche IDs zu benutzen, kann ID3 vom empfängerseitigen MMS Relay B in die oben erwähn­ te interne ID2 umgewandelt werden, welche die MMA zum Empfänger MMS User Agent B identifiziert. Dazu muß wie­ derum das empfängerseitige MMS Relay B 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 Service Providern Systemen kann ID4 vom senderseitigen MMS Relay A umgewandelt werden in eine In­ terim-ID (ID6), welche MMB zwischen den Systemen identi­ fiziert. Insbesondere sollte ID6 global eindeutig sein, z. B. eine Kombination von Informationen hinsichtlich des Service Providers A, ID4 und Zeitpunkt der Umwandlung enthalten. Dazu muß das senderseitige MMS Relay A die In­ formation bzw. die Möglichkeit besitzen, diese Umwandlung wieder rückgängig zu machen, z. B. für Auslieferungsbe­ richte. Um intern übersichtlichere IDs zu benutzen, kann ID6 vom empfängerseitigen MMS Relay B umgewandelt werden in eine interne ID (ID5), welche MMB zum Empfänger MMS User Agent B identifiziert. Dazu muß das empfängerseitige MMS Relay B die Information bzw. die Möglichkeit besit­ zen, 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 realisie­ ren, weist ID4 eine Referenz zu ID1, ID6 eine Referenz zu ID3 und ID5 eine Referenz zu ID2 auf. Die Benachrichti­ gungen der Empfangsapplikation MMS User Agent B über MMA und MMB verweisen zudem auf zwei Speicherplätze URI1 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 Netzwerkelemente ist vorteilhafterweise in der Lage, eine eindeutige, um­ kehrbare Umwandlung von IDs vorzunehmen und die Informa­ tionen hierüber zu verwalten.
Im folgenden werden die Manipulationsmöglichkeiten "Rück­ ruf" und "Ändern" beispielhaft beschrieben, worunter un­ ter dem letzteren Begriff im Sinne dieser Erfindung bei­ spielsweise eine Aktualisierung der ersten Nachricht MMA verstanden wird, insbesondere durch Ersetzen der ersten Nachricht durch die zweite Nachricht. Allgemein sind je­ doch alle Kombinationen der gemäß dieser Erfindung offen­ barten Optionen für alle Arten von Manipulationen reali­ sierbar, 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 in­ formiert werden soll, ob der Empfänger über einen Manipu­ lationswunsch des Absenders informiert werden soll, ob die zweite Nachricht im PULL- oder im PUSH-Modus zuge­ stellt werden soll, ob die Änderung auf einem sendersei­ tigen oder empfängerseitigen Netzwerkelement oder auf der Empfangsapplikation MMS User Agent B erfolgen soll, ob der Absender und/oder der Empfänger über den Erfolg der Manipulation benachrichtigt werden soll, usw.
A. Rückruf-Dienstmerkmal
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 verschi­ cken, daß die zuvor verschickte, erste Nachricht MMA wie­ der zurückgerufen werden soll.
Dies kann erfindungsgemäß bevorzugt dadurch realisiert werden, indem der Absender die neue MMB verfaßt, die ei­ nen 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 ver­ schickte 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 MMS Relay A des Absenders. Hier wird zweckmäßigerweise überprüft, ob die MMA mit der ID1 noch im Zuständigkeitsbereich des Service Providers A (MMSEA) ist, oder ob sie schon an das MMSEB des Service Providers B weitergeleitet worden ist. Ersteres ist z. B. der Fall, wenn der vom Absender gewähl­ te 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 über­ schritten hat und noch nicht dem MMS User Agent B zuge­ stellt worden ist. Sobald die MMA in einem MMSE der be­ teiligten MMS Service Provider ausfindig gemacht wird, kann das Löschen von MMA und MMB vom zuständigen MMS Re­ lay eingeleitet werden.
Falls das MMS User Agent B 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 Service Provi­ ders B befinden sollte, kann nach dieser Erfindung das MMS User Agent B mit einer erneuten Benachrichtigung (No­ tification) davon in Kenntnis gesetzt werden, daß die MMA vom Service Provider 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 Service Pro­ vider B nach dieser Erfindung die Möglichkeit, dem MMS User Agent B das Datum der Ausführung des Rückruf-Befehls zu übermitteln.
Sollte die MMA schon an den Empfänger ausgeliefert worden sein, so kann das MMS User Agent B des Empfängers mit der o. g. erneuten Benachrichtigung (Notification) davon in Kenntnis gesetzt werden, daß der Absender die MMA zurück­ rufen möchte. Das Löschen der MMA kann nach dieser Erfin­ dung direkt im MMS User Agent B stattfinden, sofern die­ ses das Rückruf-Dienstmerkmal unterstützt. Je nach Imple­ mentierung dieses Dienstmerkmals im Endgerät, den Ein­ stellungen des Benutzers, den Einstellungen des MMS Ser­ vice Providers 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 je­ doch, nur solche MMs nach der Auslieferung zu löschen, welche noch nicht vom Empfänger "angefaßt" worden sind. Die MMB mit der Rückruf-Information muß dem MMS User A­ gent B 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 MMS Relay B vor der rück­ zurufenden MMA erreicht, muß dieser auch nicht über eine vom Absender eingeleitete Rückruf-Aktion informiert werden. Statt dessen wartet das MMS Relay B vorzugsweise, bis es die zum Rückruf referenzierte MMA erhält und löscht diese beim Eintreffen, ohne den Empfänger zu be­ nachrichtigen (vorausgesetzt, das MMS Relay B unterstützt das Rückruf-Dienstmerkmal). Alternativ kann die Löschung von MMA auch schon auf dem MMS Relay A erfolgen.
Der Auftraggeber des Rückrufs (MMS User Agent A) wird ge­ mäß der vorliegenden Erfindung über den Ausgang und das Datum der Ausführung der von ihm eingeleiteten Aktion vorzugsweise informiert, wenn die beteiligten MMS Service Provider dies ermöglichen.
Um das gerade beschriebene Dienstmerkmal Rückruf umsetzen zu können, schlägt die vorliegende Erfindung vor, daß ei­ ne oder mehrere der folgenden Informationen zusätzlich zwischen den beteiligten Instanzen (MMS User Agent A, MMS Relay A, MMS Relay B und MMS User Agent B) ausgetauscht werden:
MMS User Agent A → MMS Relay A (beim Versenden einer MM)
  • - Kennzeichnung, daß es sich bei einer MMB um einen Rückruf-Befehl handelt.
  • - Identifikationsnummer der MMA, die zurückgerufen wer­ den soll.
  • - Information, daß der Absender eine Rückmeldung über den Ausgang der von ihm initiierten Rückruf-Aktion an­ fordert.
MMS Relay A → MMS User Agent A (bei der Bestätigung nach dem Versendens einer MM)
  • - Mitteilung des Service Providers, ob dieser das Rück­ ruf-Dienstmerkmal unterstützt.
MMS Relay A → MMS Relay 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 wer­ den 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 MMS Relay A und MMS Relay B ist davon abhängig, ob diese Informatio­ nen beim Versenden der MMB vorhanden waren.
MMS Relay B → MMS User Agent B (bei der Benachrichtigung über eine eingetroffene MM), vorzugsweise in einer Nach­ richt
  • - Information, wann der Rückruf ausgeführt wurde.
  • - Information, daß eine zuvor durch eine Benachrichti­ gung angekündigte MMA nun nicht mehr zum Download be­ reitliegt. Identifizierung der MMA, die im MMSEB ge­ lö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 dem MMS User Agent B anhand der Nachrichten-ID
  • - MMS User Agent B → MMS Relay B (nach der Benachrich­ tigung):
  • - 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 das EMS User Agent B 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 be­ reits heruntergeladene MMA zurückgerufen wurde und da­ her nicht mehr im dem MMS User Agent B zugängigen Speicher des Endgeräts (oder angeschlossenener Gerä­ te/Speicherkarten) vorliegt.
MMS Relay B → MMS Relay A (nur dann nötig, wenn Absender und Empfänger zu unterschiedlichen EMSEs gehören und wenn der Absender eine Rückmeldung angefordert hat)
  • - Information, ob der Rückruf-Auftrag erfolgreich ausge­ führt werden konnte.
  • - Information, wann der Rückruf-Auftrag ausgeführt wor­ den ist.
  • - Information, ob der Rückruf-Auftrag automatisch durch­ gefü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 zu­ rückgerufen wurde und daher nicht mehr im dem MMS User Agent B zugängigen Speicher des Endgeräts (oder an­ geschlossenener Geräte/Speicherkarten) vorliegt.
  • - Identifikationsnummer der MMA, die zurückgerufen wurde
MMS Relay A → MMS User Agent A (beim Bericht)
  • - Information, ob der Rückruf-Auftrag erfolgreich ausge­ führt werden konnte.
  • - Information, wann der Rückruf-Auftrag ausgeführt wor­ den ist.
  • - Information, ob der Rückruf-Auftrag automatisch durch­ gefü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 zu­ rückgerufen wurde und daher nicht mehr im dem MMS User Agent B zugängigen Speicher des Endgeräts (oder an­ geschlossenener Geräte/Speicherkarten) vorliegt.
  • - Identifikationsnummer der MMA, die zurückgerufen wur­ de.
Nachfolgend werde mögliche Modifikationen der WAP Nach­ richten für das Rückruf-Dienstmerkmal näher erläutert: Um das Rückruf-Dienstmerkmal in die WAP Implementierung von MMS einzufügen, schlägt die vorliegende Erfindung eine Modifikation der WAP Nachrichten M-Send.req, M-Send.conf, M-Notification.ind, M-NotifyResp.req und M-Delivery.ind vor. In ihnen können nach dieser Erfindung verschiedene Header-Felder ergänzt bzw. modifiziert werden. Nach WAP- 203-WSP, Version 4-May-2000, Wireless Application Proto­ col, Wireless Session Protocol Specification, Chapter 8.4: "Header Encoding" besteht jedes Header-Feld aus ei­ nem (kodierten) Feld-Namen und einem (kodierten) Feld- Wert. Dabei existieren insgesamt vier Möglichkeiten den Feld-Wert zu codieren, wobei das erste Oktet des Feld- Wertes über die Art und Länge der Codierung entscheidet (siehe Tabelle 1 im Anhang).
A.1. WAP Nachricht M-Send.req (vom MMS User Agent A zum MMS Relay A)
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än­ ger. Zu diesem Zwecke kann in der WAP Nachricht M- Send.req, mit der die MMB verschickt wird, ein Header- Feld ergänzt werden, das die Identifikationsnummer derje­ nigen MM trägt, die der Absender zurückrufen möchte (ID1 von MMA aus Fig. 2). Es wird vorgeschlagen, daß dieses Header-Feld den Namen X-Mms-Recall-ID und die hexadezima­ le Codierung 0 × 7F (dezimal: 127) trägt. Message-IDs wer­ den konform zum Encapsulation-Standard (WAP-209- MMSEncapsulation, Release 2000; Wireless Application Pro­ tocol; WAP Multimedia Messaging Service; Message Encapsu­ lation; MMS Proposed SCD 1.0) vorzugsweise als Text- String codiert. 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 vorge­ schlagen, ein Header-Feld mit der zweckmäßigen Bezeich­ nung X-Mms-Request-Report und der hexadezimalen Codierung 0 × 85 (dezimal: 133) in die WAP Nachricht M-Send.req ein­ zuführen. Die Feld-Werte dieses Header-Feldes sind bevor­ zugt konform zum Encapsulation-Standard (s. o.) mit dem <Octet128< für "Rückmeldung wird gewünscht" und <Oc­ tet129< für "Rückmeldung ist nicht erwünscht" codiert.
A.2 WAP Nachricht M-Send.conf (vom MMS Relay A zum MMS User Agent A)
Mit dieser WAP Nachricht kann dem MMS User Agent A gemäß der vorliegenden Erfindung zusätzlich mitgeteilt werden, ob der Service Provider A den Rückruf-Auftrag des Absen­ ders (MMS User Agents A) angenommen hat. Dazu wird vor­ teilhafterweise vorgeschlagen, ein neues Header-Feld mit den Namen X-Mms-Supported-Feature und der hexadezimale Codierung 0 × 83 (dezimal: 131) in die WAP Nachricht M- Send.conf einzufügen. Vorzugsweise werden als Feld-Werte konform zum Encapsulation-Standard (s. o.) das <Octet128< für eine Auftragsbestätigung und das <Octet130< für eine negative Rückmeldung benutzt (vergleiche Fig. 5).
A.3 WAP Nachricht M-Notification.ind (vom MMS Relay B zum MMS User Agent B)
Ist das MMS User Agent B bereits über eine zum Download bereitliegende MMA informiert worden, kann gemäß der vor­ liegenden Erfindung in der WAP Nachricht M- Notification.ind ein neu definiertes Header-Feld mit der zweckmäßigen Bezeichnung X-Mms-Recalled-URI und der hexa­ dezimalen Codierung 0 × 80 (dezimal: 128) zum Einsatz kom­ men. Mit seiner Hilfe kann dem MMS User Agent B mitge­ teilt werden, daß die MMA mit dem angegebenen URI nicht mehr länger zum Download bereit liegt, weil sie der Ab­ sender wieder zurückgerufen hat. Der Feld-Wert dieses neu definierten Header-Feldes wird bevorzugt konform zum En­ capsulation-Standard (s. o.) als Text-String codiert. Um den MMS User Agent B über den Zeitpunkt des Löschens informieren zu können, kann gemäß dieser Erfindung ein neu definiertes Header-Feld mit der zweckmäßigen Bezeich­ nung X-Mms-Date-of-Execution und der hexadezimalen Codie­ rung 0 × 84 (dezimal: 132) ergänzt werden. Die Feld-Werte für dieses Header-Feld werden bevorzugt nach dem Encapsu­ lation-Standard (s. o.) als Long-Integer codiert.
In der URI der Benachrichtigung kann gemäß der vorliegen­ den Erfindung auf den Speicherplatz einer Standard-Text- Nachricht (z. B.: "Diese MM wurde vom Absender wieder ge­ löscht.") verwiesen werden, mit der das MMS Relay B auch ein MMS User Agent B über einen ausgeführten Rückruf- Auftrag informieren kann, wenn dies das Rückruf- Dienstmerkmal nicht unterstützt (also die neuen Header- Felder nicht erkennt) und versucht, eine MM von dem in der Benachrichtigung ausgewiesenen Speicherplatz herun­ terzuladen.
Falls die MMA, die zurückgerufen werden soll, bereits an das MMS User Agent B ausgeliefert worden ist, kann erfin­ dungsgemäß die WAP Nachricht M-Notification.ind das in Abschnitt A.1 definierte Header-Feld mit dem Namen X-Mms- Recall-ID beinhalten. Das MMS User Agent B 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).
A.4 WAP Nachricht M-NotifyResp.req (vom MMS User Agent B zum MMS Relay B)
Gemäß der vorliegenden Erfindung wird vorteilhafterweise vorgeschlagen, in der WAP Nachricht M-NotifyResp.req op­ tional ein neues Header-Feld einzufügen, mit dessen Hilfe dem MMS Relay B mitgeteilt werden kann, ob das MMS User Agent B die Meldung über einen erfolgreich ausgeführten Rückruf-Auftrag verstanden hat. Zu diesem Zweck wird vor­ zugsweise das aus anderen WAP Nachrichten bekannte Header-Feld X-Mms-Status benutzt und ein neuer Feld-Wert de­ finiert: Es wird vorgeschlagen, daß das <Octet136< die Bedeutung "Recall-Feature supported" hat.
Falls die rückzurufende MMA bereits an das MMS User Agent B ausgeliefert worden war, wird gemäß einer vorteilhaften Variante der vorliegenden Erfindung vorgeschlagen, in der WAP Nachricht M-NotifyResp.req das im Encapsulation- Standard (s. o.) definierte Header-Feld X-Mms-Status ein­ zufügen, mit dem dem MMS Relay mitgeteilt werden kann, ob der Rückruf-Auftrag des Absenders erfolgreich auf dem MMS User Agent B ausgeführt werden konnte oder nicht. Dazu ist allerdings auch hier eine Erweiterung dieses Header- Feldes notwendig: Die Rückmeldung wird bevorzugt mit den beiden neuen Feld-Werten <Octet132< für "Rückruf-Auftrag wurde erfolgreich ausgeführt" und <Octet133< für "Rück­ ruf-Auftrag konnte nicht ausgeführt werden" realisiert.
A.5 WAP Nachricht M-Delivery.ind (vom MMS Relay A zum MMS User Agent A)
Weiterhin wird vorgeschlagen, vorzugsweise das in Ab­ schnitt A.4 erweiterte Header-Feld X-Mms-Status auch hier einzufügen. Mit seiner Hilfe kann dem Absender (MMS User Agent A) mitgeteilt werden, ob sein Rückruf-Auftrag er­ folgreich ausgeführt werden konnte oder nicht, wenn auch hier die neuen Feld-Werte <Octet132< für "Rückruf-Auftrag wurde erfolgreich ausgeführt" und <Octet133< für "Rück­ ruf-Auftrag konnte nicht ausgeführt werden" benutzt wer­ den (vergleiche Fig. 5). Außerdem kann der Absender über das Datum der Ausführung seines Rückruf-Auftrages mit Hilfe des in Abschnitt A.3 definierten Header-Feldes mit der zweckmäßigen Bezeichnung X-Mms-Date-of-Execution in­ formiert werden.
B) Ändern-Dienstmerkmal
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 er­ setzen, 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 Identifizie­ rung der MMA wird vorteilhaferweise die ID1 der zuvor verschickten und jetzt zu verändernden MMA benutzt. Die MMB mit der Änderungs-Information gelangt zunächst zum MMS Relay A. Hier wird überprüft, ob die MMA mit der ID1 noch im Zuständigkeitsbereich (MMSEA) des Service Provi­ ders A ist, oder ob sie sich schon im MMSEB des Service Providers B befindet. Beides ist möglich, je nach dem, ob vom Absender der MMA ein Zeitpunkt für die frühestmögli­ che Auslieferung oder eine Gültigkeitsdauer angegeben worden ist. Sobald die MMA in einem MMSE der beteiligten MMS Service Provider ausfindig gemacht worden ist, kann das Ändern der MMA durch die MMB vom zuständigen MMS Re­ lay 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 Service Provider hat gemäß dieser Erfindung die Möglich­ keit, den MMS User Agent B über einen gegebenenfalls aus­ geführten Änderungs-Vorgang und/oder über das Datum der Ausführung des Änderungs-Vorgangs ("diese mm wurde aktua­ lisiert am. . .") in Kenntnis zu setzen.
Hat der Empfänger (MMS User Agent B) der MMA noch keine Benachrichtigung über die MMA erhalten, etwa weil die MMB mit dem Änderungs-Auftrag das MMS Relay B vor der zu än­ dernden MMA erreicht, muß dieser auch nicht zwingend über eine vom Absender eingeleitete Änderungs-Aktion infor­ miert werden. Statt dessen kann das MMS Relay B warten, bis es die zu ändernde MMA erhält und ändert, insbesonde­ re ersetzt, diese beim Eintreffen durch die MMB (voraus­ gesetzt, das MMS Relay B unterstützt das Rückruf-Dienst­ merkmal). Der MMS Service Provider kann nach dieser Er­ findung das MMS User Agent B bei der Zustellung der MMB davon in Kenntnis setzen, daß sie eine vom Absender nach­ träglich geänderte MM ist und wann diese Änderung ausge­ führt worden ist.
Falls das MMS User Agent B des Empfängers schon über die für ihn im MMSEB bereitliegende MMA mittels einer Benach­ richtigung (Notification) informiert worden ist und sich die MMA noch im Zuständigkeitsbereich des Service Provi­ ders B befinden sollte, kann gemäß dieser Erfindung das MMS User Agent B mit einer erneuten Benachrichtigung (No­ tification) davon in Kenntnis gesetzt werden, daß der Ab­ sender 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 das MMS User Agent B zunächst eine Benachrichtigung vom Service Provider B erhalten, daß ei­ ne MMB zum Ersatz der MMA vorliegt, oder die MMB mit dem Änderungs-Auftrag kann dem MMS User Agent B 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 im MMS User Agent B stattfinden, sofern dies das Ändern-Dienstmerkmal unterstützt. Je nach Implementierung dieses Dienstmerkmals im Endgerät, den Einstellungen des Benutzers, den Einstellungen des Service Providers 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 ab­ hä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 automa­ tisch (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 zumin­ dest noch darüber informiert werden, daß der Absender mit MMB die zuvor verschickte MMA ändern wollte.
Der Absender/Auftraggeber (MMS User Agent A) kann gemäß einer vorteilhaften Variante der Erfindung über den Aus­ gang und das Datum der Ausführung der von ihm eingeleite­ ten Änderungs-Aktion informiert werden, wenn die betei­ ligten MMS Service Provider dies unterstützen.
Die Identifikation von MMA auf der Empfangsapplikation MMS User Agent B) kann insbesondere anhand einer Nach­ richtenreferenz erfolgen, welche vorzugsweise ein URI ist, unter dessen Speicherplatz eine Standard-Text- Nachricht des empfängerseitigen Service Providers B abge­ speichert ist. Die URI setzt sich bevorzugt aus der Iden­ tifikationsnummer ID1 von MMA oder aus von einer empfän­ gerseitigen Netzwerkelement (MMS Relay B) festgelegten zweiten Identifikationsnummer (ID2) zusammen.
Um das gerade beschriebene Dienstmerkmal Ändern, insbe­ sondere Ersetzen, umsetzen zu können, wird gemäß der vor­ liegenden Erfindung vorgeschlagen, daß eine oder mehrere der folgenden Informationen zusätzlich zwischen den be­ teiligten Instanzen (MMS User Agent A, MMS Relay A, MMS Relay B und MMS User Agent B) ausgetauscht werden:
MMS User Agent A → MMS Relay A (beim Versenden einer MM)
  • - Kennzeichnung, daß es sich bei einer MMB um einen Än­ derungs-Befehl handelt.
  • - Identifikationsnummer der MMA, die geändert werden soll.
  • - Information, daß der Absender eine Rückmeldung über den Ausgang der von ihm eingeleiteten Änderungs-Aktion anfordert.
MMS Relay A → MMS User Agent A (bei der Bestätigung nach dem Versenden einer MM)
  • - Mitteilung des Service Providers, ob dieser das Än­ dern-Dienstmerkmal unterstützt.
MMS Relay A → MMS Relay B (nur dann nötig, wenn Absender und Empfänger zu unterschiedlichen MMSEs gehören)
  • - Kennzeichnung, daß es sich bei einer MMB um einen Än­ derungs-Befehl handelt.
  • - Identifikationsnummer der MMA, die geändert werden soll.
  • - Information, daß der Absender eine Rückmeldung über den Ausgang der von ihm eingeleiteten Änderungs-Aktion anfordert
Die Übermittlung der Informationen zwischen MMS Relay A und MMS Relay B ist davon abhängig, ob diese Informatio­ nen beim Versenden der MMB vorhanden waren.
MMS Relay B → MMS User Agent B (bei der Benachrichtigung über eine eingetroffene MM), vorzugsweise in einer Nach­ richt
  • - Information, daß der Absender eine zum Download be­ reitliegende MMA durch eine neue MMB geändert hat. Die Identifizierung beider MMs erfolgt anhand der Message References (URIs) zu den betroffenen MMs.
  • - Information, wann die zum Download bereitliegende MMA durch die neue MMB geändert wurde.
    oder:
  • - Information, daß der Absender eine bereits zuvor aus­ gelieferte MMA durch eine neue MMB ändern, insbesondere ersetzen, möchte. Die Identifizierung der MMA, die ak­ tualisiert wird, erfolgt anhand der individuellen Mes­ sage ID und die Identifizierung der MMB, welche die MMA ändern, insbesondere ersetzen, soll, erfolgt anhand der Message Reference (URI).
MMS User Agent B → MMS Relay B (nach der Benachrichti­ gung)
  • - Information, ob der Empfänger über den Änderungs- Auftrag informiert werden konnte.
Wurde im Fall des PULL-Modus der Empfänger von einer vor­ liegenden MMB mit Änderungs-Auftrag unterrichtet, so kann er diese mittels der bekannten Mechanismen vom MMS Relay B beziehen. Im Fall des PUSH-Modus wird der Download der MMB vom MMS Service Provider (und nicht vom Empfänger i­ nitiiert). In diesem Fall können die beiden vorigen Schritte (Benachrichtigung und deren Bestätigung) entfal­ len.
MMS Relay B → MMS User Agent B (bei der Zustellung einer MM)
  • - Kennzeichnung, daß die MMB einen Änderungs-Auftrag enthält, der auf dem MMS User Agent B ausgeführt wer­ den soll.
  • - Information, welche bereits ausgelieferte MMA geän­ dert, insbesondere ersetzt, werden soll. Die Identifi­ zierung der MMA erfolgt anhand der individuellen Mes­ sage ID.
    oder:
  • - Information, daß die soeben ausgelieferte MMB eine nachträglich geänderte MM ist.
  • - Information, wann MMB vom Absender geändert worden ist.
MMS User Agent B → MMS Relay B (nach der Zustellung ei­ ner MM)
  • - Information, ob der Änderungs-Auftrag erfolgreich aus­ geführt werden konnte.
  • - Information, ob der Änderungs-Auftrag automatisch durchgeführt wurde.
  • - Information, ob der Empfänger über den Änderungs-Vor­ gang informiert wurde (und/oder der Änderung zuge­ stimmt hat).
MMS Relay B → MMS Relay 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 Änderungs-Auftrag erfolgreich aus­ geführt werden konnte.
  • - Information, wann der Änderungs-Auftrag ausgeführt worden ist.
  • - Information, ob der Änderungs-Auftrag automatisch durchgeführt wurde.
  • - Information, ob der Empfänger über die Änderung infor­ miert wurde (und/oder der Änderung zugestimmt hat).
  • - Information, ob eine bereits heruntergeladene MMA ge­ ändert, insbesondere ersetzt, wurde oder aber die MMA vor dem Ersetzen noch nicht ausgeliefert worden war.
  • - Identifikationsnummer der MMA, die geändert, insbeson­ dere ersetzt, wurde.
MMS Relay A → MMS User Agent A (beim Bericht)
  • - Information, ob der Änderungs-Auftrag erfolgreich aus­ geführt werden konnte.
  • - Information, wann der Änderungs-Auftrag ausgeführt worden ist.
  • - Information, ob der Änderungs-Auftrag automatisch durchgeführt wurde.
  • - Information, ob der Empfänger über die Änderung infor­ miert 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, insbeson­ dere ersetzt, wurde.
Nachfolgend werde mögliche Modifikationen der WAP Nach­ richten für das Ändern-Dienstmerkmal näher erläutert: 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 vor­ geschlagen. In ihnen werden vorteilhafterweise analog zum Vorgehen in Abschnitt A (Rückruf-Dienstmerkmal) verschie­ dene Header-Felder ergänzt bzw. modifiziert:
B.1 WAP Nachricht M-Send.req (vom MMS User Agent A zum MMS Relay A)
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. Be­ vorzugt wird zu diesem Zweck in der WAP Nachricht M- Send.req, mit der die neue MMB verschickt wird, ein wei­ teres Header-Feld ergänzt, das die Identifikationsnummer derjenigen MM trägt, die durch MMB geändert, insbesondere ersetzt, werden soll (nämlich ID1 von MMA aus Fig. 2). Es wird vorgeschlagen, daß dieses Header-Feld den Namen X- Mms-Replace-ID und die hexadezimale Codierung 0 × 81 (dezi­ mal: 129) trägt. Message-IDs werden konform zum Encapsu­ lation-Standard (s. o.) vorzugsweise als Text-String co­ diert. Außerdem wird dem Absender einer MM mit Änderungs- Auftrag vorzugsweise die Möglichkeit gegeben, eine Rück­ meldung anzufordern. Dazu wird vorgeschlagen, das in Ab­ schnitt A.1 definierte Header-Feld mit der zweckmäßigen Bezeichnung X-Mms-Request-Report in die WAP Nachricht M- Send.req einzuführen. Die Feld-Werte dieses Header-Feldes werden vorteilhafterweise konform zum Encapsulation- Standard (s. o.) mit dem <Octet128< für "Rückmeldung wird gewünscht" und <Octet129< für "Rückmeldung ist nicht er­ wünscht" codiert.
B.2 WAP Nachricht M-Send.conf (vom MMS Relay A zum MMS User Agent A)
Mit dieser WAP Nachricht kann dem MMS User Agent A gemäß der vorliegenden Erfindung mitgeteilt werden, ob der Ser­ vice Provider A dem Änderungs-Auftrag des Absenders (MMS User Agents A) entsprechend gehandelt hat bzw. handeln konnte. Dazu wird vorgeschlagen, das in Abschnitt A.2 zum Zwecke des Rückruf-Dienstmerkmals eingeführte Header-Feld mit der zweckmäßigen Bezeichnung X-Mms-Supported-Feature vorzugsweise auch hier zu nutzen. Als Feld-Werte kommen dann entweder das <Octet129< für "Replace-Feature suppor­ ted" oder das <Octet130 < für "no support" zum Einsatz.
B.3 WAP Nachricht M-Notification.ind (vom MMS Relay B zum MMS User Agent B)
Nach dieser Erfindung wird in der WAP Nachricht M- Notification.ind vorzugsweise ein neu definiertes Header- Feld mit der zweckmäßigen Bezeichnung X-Mms-Replaced-URI und der hexadezimalen Codierung 0 × 82 (dezimal: 130) er­ gänzt. Mit seiner Hilfe kann dem MMS User Agent B nach einer bereits erfolgten Benachrichtigung mitgeteilt wer­ den, daß die MMA unter dem angegebenen URI nicht mehr länger zum Download bereit liegt, weil sie der Absender durch eine neu MMB mit einem anderen URI ersetzt hat. Der Feld-Wert dieses neu definierten Header-Feldes wird vor­ teilhafterweise konform zum Encapsulation-Standard (s. o.) als Text-String codiert. Um den MMS User Agent B über den Zeitpunkt der Aktualisierung informieren zu können, wird gemäß einer vorteilhaften Variante der Erfindung das in Abschnitt A.3 neu definierte Header-Feld mit der zweckmä­ ßigen Bezeichnung X-Mms-Date-of-Execution ergänzt.
Wenn sich die zu ändernde, insbesondere zu ersetzende, MMA schon auf dem MMS User Agent B befindet, wird vorteilhafterweise gemäß dieser Erfindung in der WAP Nach­ richt M-Notification.ind das in Abschnitt B.1 neu defi­ nierte Header-Feld mit der zweckmäßigen Bezeichnung X- Nms-Replace-ID und der hexadezimalen Codierung 0 × 81 (de­ zimal: 129) ergänzt. Das MMS User Agent B erkennt daran, daß die zum Download bereitliegende MMB einen Änderungs- Befehl für die MMA mit der entsprechenden Message-ID be­ inhaltet. Der Download der MMB kann daraufhin je nach den Einstellungen des Benutzers, den Einstellungen des MMS Service Providers und/oder des Netzbetreibers entweder im Push-Modus oder im Pull-Modus eingeleitet werden.
B.4 WAP Nachricht M-Retrieve.conf (vom MMS Relay B zum MMS User Agent B)
Wenn die zu ändernde MMA schon im MMSEB durch MMB geändert werden konnte, bietet sich gemäß der vorliegenden Erfin­ dung an, in der WAP Nachricht M-Retrieve.conf, mit der MMB an den MMS User Agent B übermittelt wird, vorzugswei­ se das Encapsulation-Standard (s. o.) definierte erweiter­ te Header-Feld X-Mms-Status mit dem Feld-Wert <Octet134< für "replace successful" und das in Abschnitt A.3 neu de­ finierte Header-Feld mit der zweckmäßigen Bezeichnung X- Mms-Date-of-Execution einzufügen. Dadurch kann das MMS Relay B dem MMS User Agent B signalisieren, daß die MMB eine nachträglich geänderte MM ist und wann der Ände­ rungs-Auftrag des Absenders im Zuständigkeitsbereich des MMSEB ausgeführt worden ist.
Wenn sich die zu ändernde MMA schon auf dem MMS User A­ gent B befindet, ist es gemäß der vorliegenden Erfindung vorteilhaft, in der WAP Nachricht M-Retrieve.conf eben­ falls das in Abschnitt B.1 definierte Header-Feld mit dem Namen X-Mms-Replace-ID zu ergänzen. Mit ihm kann das Än­ dern der MMA auf dem MMS User Agent B mit Hilfe der Mes­ sage-ID eingeleitet werden (s. Fig. 2), falls das MMS U­ ser Agent B das Ändern-Dienstmerkmal unterstützt. Andern­ falls wird dem Empfänger dadurch nur angezeigt, daß der Absender die MMA durch die neue MMB ändern wollte.
B.5 WAP Nachricht M-Acknowledge.ind (vom MMS User Agent B zum MMS Relay B)
Gemäß dieser Erfindung wird in einer vorteilhaften Wei­ terbildung vorgeschlagen, in der WAP Nachricht M- Acknowledgement.ind das im Encapsulation-Standard (s. o.) definierte Header-Feld X-Mms-Status einzufügen. Damit dem MMS Relay mitgeteilt werden kann, ob der Änderungs- Auftrag des Absenders im PULL-Modus erfolgreich ausge­ führt werden konnte oder nicht, ist auch hier eine Erwei­ terung dieses Header-Feldes (analog zu dem Vorgehen in Abschnitt A, Rückruf-Dienstmerkmal) notwendig: Die Rück­ meldung wird in dieser Erfindung vorteilhafterweise mit den beiden neuen Feld-Werten <Octet134< für "Änderungs- Auftrag wurde erfolgreich ausgeführt" und <Octet135< für "Änderungs-Auftrag konnte nicht ausgeführt werden" reali­ siert.
B.6 WAP Nachricht M-NotifyResp.ind (vom MMS User Agent B zum MMS Relay B)
Gemäß dieser Erfindung wird vorgeschlagen, in der WAP Nachricht M-NotifyResp.ind das im Encapsulation-Standard (s. o.) definierte Header-Feld X-Mms-Status einzufügen. Damit dem MMS Relay mitgeteilt werden kann, ob der Ände­ rungs-Auftrag des Absenders im PUSH-Modus erfolgreich ausgeführt werden konnte oder nicht, ist auch hier eine Erweiterung dieses Header-Feldes (analog zu dem Vorgehen in Abschnitt A, Rückruf-Dienstmerkmal) notwendig: Die Rückmeldung wird in dieser Erfindung vorzugsweise mit den beiden neuen Feld-Werten <Octet134< für "Änderungs- Auftrag wurde erfolgreich ausgeführt" und <Octet135< für "Änderungs-Auftrag konnte nicht ausgeführt werden" reali­ siert.
B.7 WAP Nachricht M-Delivery.ind (vom MMS Relay A zum MMS User Agent A)
Weiterhin wird vorgeschlagen, das in Abschnitt B.5 erwei­ terte Header-Feld X-Mms-Status auch hier einzufügen. Mit seiner Hilfe kann dem Absender (MMS User Agent A) mitge­ teilt werden, ob sein Änderungs-Auftrag erfolgreich aus­ geführt werden konnte oder nicht, wenn auch hier die neu­ en Feld-Werte <Octet134< für "Änderungs-Auftrag wurde er­ folgreich ausgeführt" und <Octet135< für "Änderungs- Auftrag konnte nicht ausgeführt werden" benutzt werden (vergleiche Fig. 5). Außerdem wird der Absender vorteil­ hafterweise über das Datum der Ausführung seines Ände­ rungs-Auftrages mit Hilfe des in Abschnitt A.3 definier­ ten Header-Feldes mit der zweckmäßigen Bezeichnung X-Mms- Date-of-Execution informiert.
Fig. 5 zeigt noch einmal die sieben, vorteilhafterweise neu eingeführten Header-Felder einschließlich der Codie­ rungen von Feld-Name und Feld-Wert. In Fig. 6 ist das um neue Feld-Werte erweiterte Header-Feld X-Mms-Status dar­ gestellt. In den Fig. 7 und 8 sind die Header-Felder der alternativen Realisierungsmöglichkeiten (Ausführungsbei­ spiele C und D, s. u.) dargestellt. Die um die entsprechenden Header-Felder ergänzten WAP Nachrichten sind im Anhang in den Tabellen 2 bis 8 aufgelistet. Alle Verände­ rungen und Ergänzungen in den Tabellen zum heutigen Stand der Technik sind dabei dick eingerahmt.
Binäre Codierung
In den folgenden Ausführungsbeispielen wird detailliert auf die in den WAP Nachrichten benutzten Header-Felder eingegangen. Dabei wird beispielhaft folgendes Szenario angenommen: MMS User Agent A verschickt eine MMA beste­ hend aus einem Text und einem JPEG-Bild an einen Empfän­ ger und will diese später zurückrufen (Beispiel A) bzw. durch eine neue MMB ersetzen (Beispiel B).
M-Send.req (MMS User Agent A → MMS Relay A)
Das MMS User Agent A des Benutzers mit der Adresse abc@siemens.de verschickt eine MMA bestehend aus einem Text (MIME content type "text/plain") und einem JPEG-Bild (MIME content type "image/jpeg") an das MMS User Agent B des Benutzers mit der Adresse xyz@siemens.de. Die zu die­ sem Zweck benutzte WAP Nachricht M-Send.req trägt bei­ spielsweise die Transaction-ID10. Das MMS Relay 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 MMS Relay übertragen worden ist.
M-Send.conf (MMS Relay A → MMS User Agent A)
In den beiden WAP Nachrichten M-Send.req und M-Send.conf kommt die gleiche Transaction-ID zum Einsatz. Damit kann die WAP Nachricht M-Send.conf mit der Message-ID am MMS User Agent A eindeutig der dazugehörigen WAP Nachrichten M-Send.req zugeordnet werden, wodurch die individuelle Identifikationsnummer AAAA.1111@mms-relay01.siemens.de der verschickten MMA zugeordnet werden kann. Das MMS Re­ lay A hat für die MMA in diesem Beispiel für die Schnitt­ stelle MMS User Agent A/MMS Relay A die individuelle Identifikationsnummer AAAA.1111@mms-relay01.siemens.de vergeben. Sie steht im Header-Feld Message-ID.
Beispiel A Rückruf
Der Absender der MMA möchte diese (zwei Stunden später) wieder zurückrufen. Dies geschieht nach dieser Erfindung 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 Msend.req das gemäß der vorliegenden Er­ findung neu definierte Header-Feld mit der zweckmäßigen Bezeichnung X-Mms-Recall-ID zum Einsatz, in das die Mes­ sage-ID der MMA, die zurückgerufen werden soll, eingetra­ gen wird (ID1 in Fig. 2). Außerdem enthält die WAP Nach­ richt M-Send.req vorteilhafterweise das ebenfalls gemäß der vorliegenden Erfindung neu definierte Header-Feld mit der zweckmäßigen Bezeichnung X-Mms-Request-Report, mit dem eine Rückmeldung über den erteilten Rückruf-Auftrag angefordert werden kann (wie in diesem Beispiel gezeigt). In der WAP Nachricht M-Send.req sind bei einem Rückruf- Auftrag vorzugsweise nur die Header-Felder und kein wei­ terer multimedialer Inhalt ("Message-Body") enthalten.
M-Send.req (MMS User Agent A → MMS Relay A)
Auch der Empfang der WAP Nachricht M-Send.req mit dem Rückruf-Befehl in MMB wird vorteilhafterweise vom MMS Re­ lay umgehend mit einer WAP Nachricht M-Send.conf quit­ tiert. In ihr ist die vom MMS Relay vergebene Message-ID für die MMB (hier: AAAA.2222@mms-relay01.siemens.de) ent­ halten. Ferner enthält sie vorteilhafterweise das gemäß der vorliegenden Erfindung neu definierte Header-Feld X- Mms-Supported-Feature mit dessen Hilfe dem MMS User Agent A angezeigt werden kann, ob der Service Provider A das Rückruf-Dienstmerkmal unterstützt (wie hier gezeigt) oder nicht.
M-Send.conf (MMS Relay A → MMS User Agent A)
Beim Austausch von WAP Nachrichten auf der Empfangsseite (Schnittstelle zwischen MMS Relay B und MMS User Agent B) muß unterschieden werden, ob der MMS User Agent B
  • 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 können die MMA und auch die MMB, die den Rückruf-Befehl enthält, im Zuständigkeitsbe­ reich des Service Providers B (MMSEB) gelöscht werden. Im ersten Fall muß der Empfänger davon nicht einmal in Kenntnis gesetzt werden. Im zweiten Fall sollte der MMS User Agent B hingegen durch den Service Provider B vor­ zugsweise darüber informiert werden können, daß die MMA nicht mehr länger zum Download 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-Notification.ind (MMS Relay B → MMS User Agent B)
In der WAP Nachricht M-Notification.ind kann für die I­ dentifizierung der zurückgerufenen MMA nur der URI be­ nutzt werden, da das MMS Relay zu diesem Zeitpunkt noch keine Message-ID für die zurückgerufene MMA vergeben hat (dies geschieht erst mit dem Download). Die Header-Feld X-Mms-Recalled-URI und X-Mms-Date-Of-Execution unter­ scheiden diese Rückruf-Benachrichtigung von einer "her­ kömmlichen" Benachrichtigung. Das Header-Feld X-Mms- Content-Location verweist in diesem Beispiel auf einen URI, unter dessen Speicherplatz vorteilhafterweise eine Standard-Text-Nachricht des Service Providers B (z. B.: "Die MM ist vom Absender wieder gelöscht worden.") zu finden ist. Damit können auch MMS User Agents, die die neuen Header-Felder des Rückruf-Dienstmerkmals nicht ver­ stehen, nachträglich über einen ausgeführten Rückruf- Auftrag informiert werden.
Mit der WAP Nachrichten M-NotifyResp.req wird der korrek­ te Empfang der WAP Nachricht M-Notification.ind bestätigt. Das Header-Feld X-Mms-Status trägt in diesem Bei­ spiel einen der gemäß der vorliegenden Erfindung neu de­ finierten Einträge (nämlich "recall feature supported"), mit dem das MMS Relay B darüber in Kenntnis gesetzt wer­ den kann, daß das MMS User Agent B die zweite Benachrich­ tigung mit der Information über den Rückruf verstanden hat.
(noch) 2. Fall: M-NotifyResp.req (MMS User Agent B → MMS Relay B)
Wenn aber die MMA, die gelöscht werden soll, bereits an das MMS User Agent B übermittelt worden ist (dritter Fall), beinhaltet vorteilhafterweise die WAP Nachricht M- Notification.ind zweckmäßigerweise nicht die Benachrich­ tigung über den bereits erfolgten Rückruf, sondern den Rückruf-Befehl selbst und zwar in Form des Header-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 I­ dentifikationsnummer (und nicht der URI) benutzt, weil sie (in dem hier beschriebenen dritten Fall) nach dem zu­ vor erfolgten Download sowohl dem MMS Relay B als auch dem MMS User Agent B bekannt ist.
3. Fall: M-Notification.ind (MMS Relay B → MMS User A­ gent B)
Das Header-Feld X-Mms-Content-Location verweist in diesem Beispiel auf einen URI, unter dessen Speicherplatz eine Standard-Text-Nachricht des Service Providers 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 MMS User Agents, die die neuen Header-Felder des Rückruf-Dienstmerkmals nicht verstehen, nachträglich über einen vom Absender verschickten Rück­ ruf-Auftrag informiert werden.
Um hervorzuheben, daß die MMA an dieser Schnittstelle ei­ ne andere Message-ID tragen kann, wurde in diesem Ausfüh­ rungsbeispiel als Wert BBBB.3333@mms-relay02.siemens.de gewählt (entspricht ID2 von MMA in Fig. 2).
(noch) 3. Fall: M-NotifyResp.req (MMS User Agent B → MMS Relay B)
Das MMS User Agent B schickt bei diesem Ausführungsbei­ spiel mit der WAP Nachricht M-NotifyResp.req eine Rück­ meldung zurück an das MMS Relay B. Dazu wird vorteilhaft­ erweise das in dieser Erfindung erweiterte Header-Feld X- Mms-Status aus dem Encapsulation-Standard (s. o.) benutzt. In diesem Ausführungsbeispiel konnte die MMA auf dem MMS User Agent B gelöscht werden, was mit dem Feld-Wert "re­ call successful" ausgedrückt wird. Im MMS Relay B kann von der Transaction-ID (hier: 25) des WAP Nachrichten- Paares auf die Message-ID (hier: BBBB.3333@mms- relay02.siemens.de) der gelöschten MMA geschlossen wer­ den. Dadurch ist das Verfassen einer Rückmeldung möglich, falls dies vom Absender gewünscht und vom Service Provi­ der B unterstützt wird.
M-Delivery.ind (MMS Relay A → MMS User Agent A)
Falls der Absender eine Rückmeldung für den von ihm ini­ tiierten Rückruf-Auftrag wünscht, kann das MMS Relay A mit der WAP Nachricht M-Delivery.ind eine Rückmeldung zu­ rück an das MMS User Agent A schicken. In dem Feld Messa­ ge-ID steht die ID des Rückruf-Auftrages. Für den Status des Rückrufes wird hier ebenfalls vorteilhafterweise das erweiterte Header-Feld X-Mms-Status benutzt, in dem das erfolgreiche Löschen der MMA mit dem Feld-Wert "recall successful" bestätigt wird. Da dem MMS User Agent A der Zusammenhang zwischen der Message-ID des Rückruf- Auftrages und der Message-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 Ser­ vice Provider dies unterstützen).
Beispiel B Ändern
In diesem Beispiel möchte der Absender seine MMA (eine Stunde nach dem Verschicken) aktualisieren: Von den ur­ sprü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 vorteilhaft­ erweise das gemäß der vorliegenden Erfindung neu defi­ nierte Header-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 vorlie­ genden Erfindung neu definierte Header-Feld mit der zweckmäßigen Bezeichnung X-Mms-Request-Report, mit dem eine Rückmeldung über den erteilten Änderungs-Auftrag an­ gefordert werden kann (wie in diesem Beispiel gezeigt).
M-Send.req (MMS User Agent A → MMS Relay A)
Auch der Empfang dieser WAP Nachricht M-Send.req, welche die MMB mit dem Änderungs-Befehl in sich trägt, wird be­ vorzugt vom MMS Relay umgehend mit einer WAP Nachricht M- Send.conf quittiert. In ihr ist zweckmäßigerweise die vom MMS Relay vergebene Message-ID der MMB (hier: AAAA.5555@mms-relay01.siemens.de) und das ebenfalls gemäß der vorliegenden Erfindung neu definierte Header-Feld X- Mms-Supported-Feature enthalten, mit dessen Hilfe dem MMS User Agent A angezeigt werden kann, ob der Service Provi­ der A das Ändern-Dienstmerkmal unterstützt oder nicht. Die beiden WAP Nachrichten tragen in diesem Beispiel die Transaction-ID32.
M-Send.conf (MMS Relay A → MMS User Agent A)
Beim Austausch von WAP Nachrichten auf der Empfangsseite (Schnittstelle zwischen MMS Relay B und MMS User Agent B) muß unterschieden werden, ob der MMS User Agent B
  • 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ändig­ keitsbereich des Service Providers 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 Download darüber in Kenntnis gesetzt wird, daß es sich um eine nachträglich geänderte, insbesondere ersetzte, mm handelt und wann der Änderungs-Auftrag ausgeführt worden ist. Bevorzugt kann im zweiten Fall der Service Provider B den MMS User Agent B sofort nach dem Ausführen des Änderungs-Auftrages im MMSEB darüber informieren, daß der Absender MMA durch ei­ ne neue MMB aktualisiert hat und wann diese Aktualisie­ rung vorgenommen worden ist. Nach dieser Erfindung soll diese Benachrichtigung vorzugsweise mittels der WAP Nach­ richt 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 MMS Relay B zu diesem Zeitpunkt noch keine Message-ID für die MMA vergeben hat (dies geschieht erst mit dem Download der MMA). Die Hea­ der-Felder X-Mms-Replaced-URI und X-Mms-Date-Of-Execution unterscheiden diese Rückruf-Benachrichtigung von einer "herkömmlichen" Benachrichtigung. Das Header-Feld X-Mms- Content-Location zeigt an, wo die MMB mit dem nun aktuel­ len Inhalt auf dem Server zu finden ist.
2. Fall: M-Notification.ind (MMS Relay B → MMS User A­ gent B)
Mit der WAP Nachricht M-NotifyResp.req wird vorteilhaft­ erweise der korrekte Empfang der WAP Nachricht M- Notification.ind vom MMS User Agent B bestätigt, vgl. Fig. 2. Das Header-Feld X-Mms-Status trägt in diesem Bei­ spiel einen gemäß der vorliegenden Erfindung neu defi­ nierten Eintrag (nämlich "replace feature supported") mit dem das MMS Relay B darüber in Kenntnis gesetzt wird, daß das MMS User Agent B die zweite Benachrichtigung mit der Information über den ausgeführten Änderungs-Auftrag ver­ standen hat.
(noch) 2. Fall: M-NotifyResp.req (MMS User Agent B → MMS Relay B)
Wenn aber die MMA, die geändert werden soll, bereits an das MMS User Agent B übermittelt worden ist (dritter Fall), beinhaltet nach dieser Erfindung die WAP Nachricht M-Notification.ind vorteilhafterweise nicht die Benachrichtigung über eine bereits erfolgte Änderung, sondern den Änderungs-Befehl selbst und zwar in Form des Header- Feldes mit der zweckmäßigen Bezeichnung X-Mms-Replace-ID, in dem die Identifikationsnummer der zu ändernden, insbe­ sondere zu ersetzenden, MMA eingetragen wird. Daraufhin kann vom MMS User Agent B der Download der MMB entweder im Push-Modus oder im Pull-Modus mit Hilfe des WSP GET Befehls eingeleitet werden. Das Header-Feld X-Mms- Content-Location verweist in diesem Beispiel auf einen URI, unter dessen Speicherplatz eine Standard-Text- Nachricht des Service Providers 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 MMS User Agents, die die neuen Header- Felder des Rückruf-Dienstmerkmals nicht verstehen, nach­ träglich über einen vom Absender verschickten Rückruf- Auftrag informiert werden.
3. Fall: M-Notification.ind (MMS Relay B → MMS User A­ gent B)
Als Antwort auf den WSP GET Befehl, mit dem der URI an das MMS Relay B geschickt wird, erhält das MMS User Agent B 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 Header-Feld mit der zweckmäßigen Bezeichnung X-Mms-Replace-ID ergänzt werden. Damit kann direkt auf dem MMS User Agent B die MMA durch die MMB geändert, insbesondere ersetzt, werden, falls das MMS User Agent B das Ändern-Dienstmerkmal un­ terstützt. Abhängig vom gewählten Zustellungs-Modus wird in der WAP Nachricht M-Retrieve.conf die Transaction-ID aus der WAP Nachricht M-Notification.ind übernommen (PUSH-Modus) oder eine neue vergeben (PULL-Modus).
(noch) 3. Fall: M-Retrieve.conf (MMS Relay B → MMS User Agent B)
Um hervorzuheben, daß die MMA an dieser Schnittstelle ei­ ne andere Message-ID tragen kann, wurde in diesem Ausfüh­ rungsbeispiel 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 (MMS User Agent B → MMS Relay B)
Erfolgte die Zustellung der MMB im PULL-Modus, schickt das MMS User Agent B vorzugsweise mit der WAP Nachricht M-Acknowledge.ind eine Rückmeldung zurück an das MMS Re­ lay B. Dazu wird das in dieser Erfindung erweiterte Hea­ der-Feld X-Mms-Status benutzt. In diesem Ausführungsbei­ spiel konnte die MMA auf dem MMS User Agent B durch die neue MMB ersetzt werden, was mit dem Feld-Wert "replace successful" ausgedrückt wird. Im MMS Relay B kann von der Transaktions-ID (Transaction-ID) (hier: 48) des WAP Nach­ richten-Paares M-Retrieve.conf und M-Acknoledge.ind auf die Message-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 Ab­ sender verlangt und vom Service Provider 07956 00070 552 001000280000000200012000285910784500040 0002010104713 00004 07837 B unterstützt wird.
Bei Zustellung von MMB im PUSH-Modus
3. Fall: M-NotifyResp.req (MMS User Agent B → MMS Relay B)
Erfolgte die Zustellung der MMB im PUSH-Modus, bestätigt das MMS User Agent B den korrekten Empfang von MMB vor­ zugsweise mit der WAP Nachricht M-NotifyResp.req. Dazu wird bevorzugt das in dieser Erfindung erweiterte Header- Feld X-Mms-Status benutzt. In diesem Ausführungsbeispiel konnte die MMA auf dem MMS User Agent B durch die neue MMB ersetzt werden, was mit dem Feld-Wert "replace suc­ cessful" ausgedrückt wird. Im MMS Relay B kann von der Transaction-ID (hier: 38) des WAP Nachrichten-Triples M- Notification.ind M-Retrieve.conf und M-NotifyResp.req auf die Message-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 Ab­ sender verlangt und vom Service Provider B unterstützt wird.
M-Delivery.ind (MMS Relay A → MMS User Agent A)
Das MMS Relay A kann mit der WAP Nachricht M-Delivery.ind eine Rückmeldung zurück an das MMS User Agent A schicken. In dem Feld Message-ID steht die ID des Änderungs- Auftrages. Für den Status des Änderungs-Auftrages wird hier vorzugsweise ebenfalls das erweiterte Header-Feld X- Mms-Status benutzt, in dem das erfolgreiche Ändern der MMA durch MMB mit dem Feld-Wert "replace successful" bes­ tätigt wird. Da dem MMS User Agent A der Zusammenhang zwischen der Message-ID des Änderungs-Auftrages und der Message-ID der MMA, die zurückgerufen werden sollte, be­ kannt ist, kann dem Absender mitgeteilt werden, ob sein Änderungs-Auftrag erfolgreich ausgeführt werden konnte oder nicht (sofern die beteiligten MMS Service Provider dies unterstützen).
Beispiel C Alternative für das Übermitteln einer Status- Information
In den beiden zuvor beschriebenen Ausführungsbeispielen wird eine Rückmeldung über den Ausgang eines erteilten Rückruf- bzw. Änderungs-Auftrages vom MMS User Agent B zum MMS Relay B (bei Service Provider B) mit den WAP Nachrichten M-NotifyResp.ind (PUSH-Modus) oder M- Acknowledgement.ind (PULL-Modus), bzw. vom MMS Relay A zum MMS User Agent A (bei Service Provider A) mit der WAP Nachricht M-Delivery.ind übertragen. Dazu wurden neue Feld-Werte in das Header-Feld X-Mms-Status eingeführt. Dieses Vorgehen ist zwar effizient, jedoch nicht ganz konform zur bisherigen Nutzung des Header-Feldes X-Mms- Status. Deshalb wird im folgenden ein alternatives Aus­ führungsbeispiel für das Übermitteln einer Rückmeldung beschrieben. Das Absenden sowie das Ausführen eines Rück­ ruf- oder Änderungs-Auftrages bleibt dabei wie in Bei­ spiel A und Beispiel B beschrieben zweckmäßigerweise un­ verändert.
Mit dieser Alternative wird das Header-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 Änderungs-Auftrag beinhaltete) zu informieren und nicht (wie unter Ausfüh­ rungsbeispiel A und B beschrieben) über den Ausgang eines Rückruf- oder Änderungs-Auftrages. Für diesen Fall wird deshalb ein weiteres Header-Feld definiert, mit dem der Absender über den Ausgang seines Rückruf- oder Änderungs- Auftrages in Kenntnis gesetzt werden kann. Es wird vorge­ schlagen, dieses neue Header-Feld mit dem Namen X-Mms- Original-Message-Status zu versehen und ihm die hexadezi­ male Codierung 0 × 86 (dezimal: 134) zu geben. Weiterhin wird vorgeschlagen, z. B. als Feld-Werte <Octet128< für "Die MM wurde erfolgreich zurückgerufen", <Octet129< für "Der Rückruf der mm ist fehlgeschlagen", <Octet130< für "Die MM wurde erfolgreich geändert bzw. ersetzt" und <Octet131< für "Das Ändern bzw. Ersetzen der mm ist fehl­ geschlagen" zu benutzen. Fig. 7 zeigt das in dieser Al­ ternative vorgestellte Header-Feld.
Beispiel D Alternative für das übermitteln einer Rück­ meldung
In den Beispielen A und B wurde die MMA, auf die sich die Rückmeldung bezieht, über das Ergebnis des Rückruf- bzw. Änderungs-Auftrages anhand der Message-ID von MMB und an­ hand 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 Service Provider B), bzw. M- Delivery.ind (von Service Provider A) zu übertragen. Dazu wird vorgeschlagen, ein neues Header-Feld einzuführen, welches beispielsweise die zweckmäßige Bezeichnung X-Mms- Original-Message-ID trägt, und ihm die hexadezimale Co­ dierung 0 × 87 (dezimal: 135) zu geben. Die Feld-Werte die­ ses neuen Header-Feldes beinhalten bevorzugt die Message- ID der Original-MMA und werden gemäß des Encapsulation- Standards (s. o.) als Text-String codiert. Fig. 8 zeigt das in dieser Alternative vorgestellte Header-Feld.
Anhang
Tabelle 1
Möglichkeiten der Feld-Wert-Codierung nach WAP- 203-WSP, Version 4-May-2000; Wireless Application Protocol, Wireless Session Protocol Specification; Chapter 8.4: "Header Encoding"
Tabelle 2
WAP Nachricht M-Send.req (dick eingerahmt: neu nach dieser Erfindung)
Tabelle 3
WAP Nachricht M-Send.conf (dick eingerahmt: neu nach dieser Erfindung)
Tabelle 4
WAP Nachricht M-Notification.ind (dick eingerahmt: neu nach dieser Erfindung)
Tabelle 5
WAP Nachricht M-NotifyResp.req (dick eingerahmt: neu nach dieser Erfindung)
Tabelle 6
WAP Nachricht M-Retrieve.conf (dick eingerahmt: neu nach dieser Erfindung)
Tabelle 7
WAP Nachricht M-Acknowledge.ind (dick eingerahmt: neu nach dieser Erfindung)
Tabelle 8
WAP Nachricht M-Delivery.ind (dick eingerahmt: neu nach dieser Erfindung)

Claims (31)

1. Verfahren zum Zugreifen auf eine erste Nachricht (MMA), insbesondere eine multimediale Nachricht (Multimedia Message, MM) vorzugsweise vom MMS-Typ, wobei die erste Nachricht (MMA) mittels einer Sendeapplikation (MMS User Agent A) einer Sen­ deeinheit an eine Empfangsapplikation (MMS User Agent B) ei­ ner Empfangseinheit gesendet wird, dadurch gekennzeich­ net, daß eine zweite Nachricht (MMB) mit einem Manipulati­ onsauftrag zur Manipulation der ersten Nachricht (MMA) er­ stellt, versendet, empfangen, weitergeleitet und/oder verar­ beitet 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, ins­ besondere Inter-Operator-IP-backbone, zwischen Mobilfunknet­ zen und anderen Nachrichten-Netzen, insbesondere Internet- Email, und/oder über das Internet versendet werden.
3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch ge­ kennzeichnet, daß die erste Nachricht (MMA) und die zweite Nachricht (MMB) über mindestens ein senderseitiges Netzwerk­ element (MMS Relay A) eines Service Providers (Service Provi­ der A) und mindestens ein empfängerseitiges Netzwerkelement (MMS Relay A; MMS Relay B) eines Service Providers (Service Provider A; Service Provider B) an die Empfangsapplikation (MMS User Agent B) gesendet wird.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß das mindestens eine senderseitige Netzwerkelement (MMS Relay A) und das mindestens eine empfängerseitige Netzwerkelement (MMS Relay B) dem Zuständigkeitsbereich (MMSEA) eines einzi­ gen Service Providers (Service Provider A) angehören oder so­ gar identisch sind.
5. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß die Sendeapplikation (MMS User A­ gent A) und die Empfangsapplikation (MMS User Agent B) iden­ tisch sind.
6. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß der manipulierende Zugriff auf die erste Nachricht (MMA) auf einem senderseitigen Netzwerkele­ ment (MMS Relay A), auf einem empfängerseitigen Netzwerkele­ ment (MMS Relay B) und/oder auf der Empfangsapplikation (MMS User Agent B) erfolgt.
7. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß der Manipulationsauftrag den Rück­ ruf bzw. das Löschen der ersten Nachricht (MMA) umfaßt.
8. Verfahren nach einem der Ansprüche 1 bis 6, dadurch ge­ kennzeichnet, daß der Manipulationsauftrag das Ändern der ersten Nachricht (MMA) umfaßt, vorzugsweise durch Ersetzen der ersten Nachricht (MMA) durch die zweite Nachricht (MMB).
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daß die zweite Nachricht (MMB) im Falle eines Änderungs-Auftrages entweder im PUSH-Modus (Drück-/Bring-Modus) oder im PULL- Modus (Zieh-/Hol-Modus) heruntergeladen wird.
10. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch 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 Identifikati­ onsnummer (ID1) verwendet wird, welche die erste Nachricht (MMA) zwischen der Sendeapplikation (MMS User Agent A) und einem senderseitigen Netzwerkelement (MMS Relay A) eindeutig kennzeichnet.
11. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß beim Versenden einer Nachricht ei­ nem senderseitigen Netzwerkelement (MMS Relay A) von der Sen­ deapplikation (MMS User Agent A) eine oder mehrere der fol­ genden 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.
12. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß der Sendeapplikation (MMS User A­ gent A) von einem senderseitigen Netzwerkelement (MMS Relay A) die Information bereitgestellt wird, ob dieses Netzwerk­ element (MMS Relay A) die Manipulation gemäß den vorhergehen­ den Ansprüchen unterstützt und/oder ob dar Manipulations- Auftrag der Sendeapplikation (MMS User Agent A) von dem Ser­ vice Provider (Service Provider A) der Sendeapplikation (MMS User Agent A) angenommen wurde.
13. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß bei Zugehörigkeit der Sendeapplika­ tion (MMS User Agent A) und der Empfangsapplikation (MMS User Agent B) zu unterschiedlichen Zuständigkeitsbereichen (MMSEA, MMSEB) von Service Providern (Service Provider A, Service Provider B) einem empfängerseitigen Netzwerkelement (MMS Re­ lay B) von einem senderseitigen Netzwerkelement (MMS Relay A) 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 mani­ puliert werden soll;
Information, daß der Absender eine Rückmeldung über den Ausgang der von ihm initiierten Manipulation anfordert.
14. Verfahren nach einem der vorhergehenden Ansprüchen, da­ durch gekennzeichnet, daß Netzwerkelemente (MMS Relay A, MMS Relay B) von verschiedenen Service Providern (Service Provi­ der A, Service Provider B) eine eineindeutige, umkehrbare Um­ wandlung von auf die erste und/oder die zweite Nachricht be­ zogene Identifikationsnummern (ID1, ID3; ID4, ID6, ID5) vor­ nehmen und die entsprechenden Informationen vorzugsweise ver­ walten.
15. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß im Falle eines Manipulationsauf­ trags, insbesondere einschließlich eines Löschungsbefehls, bei noch nicht erfolgter Benachrichtigung der Empfangsappli­ kation (MMS User Agent B) über die erste Nachricht (MMA) die­ se erste Nachricht (MMA) im Zuständigkeitsbereich (MMSEA) des senderseitigen Service Providers (Service Provider A) oder im Zuständigkeitsbereich (MMSEB) des empfängerseitigen Service Providers (Service Provider B) manipuliert, insbesondere ge­ löscht, wird, wobei bevorzugt die Empfangsapplikation (MMS User Agent B) über die Manipulation nicht informiert wird.
16. Verfahren nach einem der Ansprüche 1 bis 14, 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) im Zuständigkeitsbereich (MMSEB) des emp­ fangsseitigen Service Providers (Service Provider B) manipu­ liert wird, wobei die Empfangsapplikation (MMS User Agent B) über die Manipulation und über deren Zeitpunkt vorzugsweise informiert wird.
17. Verfahren nach einem der Ansprüche 1 bis 14, 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) im Zuständigkeitsbereich (MMSEA) des sender­ seitigen Service Providers (Service Provider A) manipuliert wird, wobei die Empfangsapplikation (MMS User Agent B) über die Manipulation vorzugsweise nicht informiert wird.
18. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß der Empfangsapplikation (MMS User Agent B) von einem empfängerseitigen Netzwerkelement (MMS Re­ lay B) eine oder ggf. mehrere der folgenden Informationen, vorzugsweise in einer Benachrichtigung, bereitgestellt wer­ den:
Information, daß eine lediglich angekündigte, aber noch nicht ausgelieferte erste Nachricht (MMA) nicht mehr zum Her­ unterladen 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, d. h. einem Speicher­ platz) erfolgt;
Information, daß eine schon ausgelieferte erste Nachricht (MMA) vom Absender manipuliert werden möchte, wobei die Iden­ tifizierung der ersten Nachricht (MMA) auf der Empfangsappli­ kation (MMS User Agent B) vorzugsweise anhand einer Nachrich­ tenreferenz erfolgt, welche vorzugsweise ein URI ist, unter desssen Speicherplatz eine Standard-Text-Nachricht des emp­ fängerseitigen Service Providers (Service Provider B) abge­ speichert ist, wobei die URI bevorzugt aus der Identifikati­ onsnummer (ID1) der ersten Nachricht (MMA) oder von einem empfängerseitigen Netzwerkelement (MMS Relay B) festgelegten zweiten Identifikationsnummer (ID2) zusammengesetzt ist;
Kennzeichnung, daß die zweite Nachricht (MMB) einen Manipu­ lationsauftrag enthält, der auf der Empfangsapplikation (MMS User Agent B) 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.
19. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß einem empfängerseitigen Netzwerk­ element (MMS Relay B) von der Empfangsapplikation (MMS User Agent B) nach ihrer Benachrichtigung über die zweite Nach­ richt (MMB) mindestens eine der folgenden Informationen be­ reitgestellt werden:
Information, ob die Empfangsapplikation (MMS User Agent B) 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;
Information, ob im Falle eines Änderungs-Auftrags die Ände­ rung der bereits heruntergeladenen ersten Nachricht (MMA) au­ tomatisch (PUSH-Modus) oder auf Veranlassung des Empfängers (PULL-Modus) durchgeführt wurde;
Information, welcher Art die vorzunehmende Manipulation ist.
20. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß bei Zugehörigkeit der Sendeapplika­ tion (MMS User Agent A) und der Empfangsapplikation (MMS User Agent B) zu unterschiedlichen Zuständigkeitsbereichen (MMSEA, MMSEB) von Service Providern (Service Provider A, Service Provider B) einem senderseitigen Netzwerkelement (MMS Relay A) von einem empfängerseitigen Netzwerkelement (MMS Relay B) eine oder mehrere der folgenden Informationen bereitgestellt werden:
Information, ob der Manipulationsauftrag erfolgreich ausge­ führt werden konnte;
Information, wann der Manipulationsauftrag ausgeführt wur­ de;
Information, ob der Manipulationsauftrag automatisch ausge­ führt wurde;
Information, ob der Empfänger über die Manipulation infor­ miert wurde und/oder der Manipulation zugestimmt hat und/oder die Manipulation vom Empfänger veranlaßt wurde;
Information, daß die bereits heruntergeladene erste Nach­ richt (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.
21. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß der Sendeapplikation (MMS User A­ gent A) von einem senderseitigen Netzwerkelement (MMS Relay A) eine oder mehrere der folgenden Informationen bereitge­ stellt werden:
Information, ob der Manipulationsauftrag erfolgreich ausge­ führt wurde;
Information, wann der Manipulationsauftrag ausgeführt wur­ de;
Information, ob der Manipulationsauftrag automatisch durch­ gefü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 (ID1) der Nachricht (MMA), die mani­ puliert wurde.
22. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß das Versenden, Empfangen und Mani­ pulieren der Nachrichten (MM) mittels WAP-Nachrichten (Wire­ less Application Protocol) erfolgt.
23. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß die Manipulationsaufträge durch Mo­ difizieren von vorhandenen Kopffeldern (Header-Feldern) und/oder durch Hinzufügen von zusätzlichen Kopffeldern in ge­ eigneten WAP-Nachrichten (WAP messages), insbesondere solche 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, implementiert werden.
24. 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 an­ hand der Identifikationsnummer (ID4) der zweiten Nachricht (MMB) sowie der Transaktions-Identifikationsnummern der ent­ sprechenden WAP-Nachrichten, oder anhand eines zusätzlichen Kopffeldes (Header-Feldes), wobei Feld-Werte des neuen Kopf­ feldes die Identifikationsnummer (ID1) der ersten Nachricht (MMA) enthalten, identifiziert wird.
25. Sende- und/oder Empfangseinheit, insbesondere zur zumin­ dest teilweisen Durchführung des Verfahrens nach einem der vorhergehenden Ansprüche, mit Mitteln zum Erstellen, Versen­ den, Empfangen und/oder Verarbeiten einer ersten Nachricht (MMA), insbesondere einer multimedialen Nachricht (Multimedia Message) vorzugsweise vom MMS-Typ, gekennzeichnet durch Mittel zum Erstellen, Versenden, Empfangen und/oder Verarbei­ ten einer zweiten Nachricht (MMB), wobei die zweite Nachricht (MMB) einen Manipulationsauftrag zum Manipulieren der zuvor gesendeten ersten Nachricht (MMA) umfaßt.
26. Sende- und/oder Empfangseinheit nach Anspruch 25, gekenn­ zeichnet durch Mittel zum Ausführen des Manipulationsauf­ trags.
27. Sende- und/oder Empfangseinheit nach Anspruch 25 oder 26, dadurch gekennzeichnet, daß die Mittel zum Erstellen, Versen­ den, Empfangen und/oder Verarbeiten der zweiten Nachricht (MMB) WAP-Nachrichten, insbesondere solche 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 und M- Delivery.ind mit entsprechend den im Rahmen der Manipulati­ onsaufträge auszutauschenden Informationen modifizierten Kopffeldern (Header-Feldern) und/oder zusätzlichen Kopffel­ dern umfassen.
28. Kommunikationssystem, insbesondere Funkkommunikationssys­ tem, insbesondere zur zumindest teilweisen Durchführung des Verfahrens nach einem der Ansprüche 1 bis 24, mit mit Sende- und/oder Empfangseinheiten, insbesondere solchen nach einem der Ansprüche 25 bis 27, kommunizierfähigen Netzwerkelementen (MMS Relay A; MMS Relay B), welche Mittel zum Empfangen und Weiterleiten von Nachrichten, insbesondere multimedialen Nachrichten (Multimedia Messages) vorzugsweise vom MMS-Typ, umfassen, dadurch gekennzeichnet, daß mindestens eines der Netzwerkelemente (MMS Relay A; MMS Relay B) Mittel zum Empfangen, Verarbeiten und/oder Weiterleiten einer zweiten Nachricht (MMB) mit einem Manipulationsauftrag umfaßt, wel­ cher sich auf eine empfangene und ggf. schon weitergeleitete erste Nachricht (MMA) bezieht, um einen manipulierenden Zugriff auf die erste Nachricht (MMA) zu veranlassen oder zu vermitteln.
29. Kommunikationssystem nach Anspruch 28, gekennzeichnet durch Mittel zum Ausführen des Manipulationsauftrags.
30. Kommunikationssystem nach Anspruch 29, dadurch gekenn­ zeichnet, daß die erste Nachricht (MMA) auf einem Netzwerk­ element (MMS Relay A; MMS Relay B) und/oder auf einer Empfangsaplikation (MMS User Agent B) einer Empfangseinheit manipulierbar ist, insbesondere löschbar und/oder änderbar.
31. Kommunikationssystem nach einem der Ansprüche 28 bis 30, dadurch gekennzeichnet, daß die Mittel zum Empfangen, Verar­ beiten und/oder Weiterleiten der zweiten Nachricht (MMB) WAP- Nachrichten, insbesondere solche 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 und M- Delivery.ind mit entsprechend den im Rahmen der Manipulati­ onsaufträge auszutauschenden Informationen modifizierten Kopffeldern (Header-Feldern) und/oder zusätzlichen Kopffel­ dern umfassen.
DE2001104713 2001-02-02 2001-02-02 Verfahren und Vorrichtungen zum Zugreifen auf Nachrichten Withdrawn DE10104713A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
DE2001104713 DE10104713A1 (de) 2001-02-02 2001-02-02 Verfahren und Vorrichtungen zum Zugreifen auf Nachrichten
EP02702291A EP1356645A2 (de) 2001-02-02 2002-01-21 Verfahren und vorrichtung zur manipulation übertragener nachrichten
JP2002563667A JP2004526352A (ja) 2001-02-02 2002-01-21 メッセージのアクセス方法および該方法に対応する方法ならびにソフトウェアプログラム
PCT/EP2002/000571 WO2002063839A2 (de) 2001-02-02 2002-01-21 Verfahren und vorrichtung zur manipulation übertragener nachrichten
US10/068,702 US20030086438A1 (en) 2001-02-02 2002-02-04 Method for accessing messages, and associated apparatuses and software programs

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE2001104713 DE10104713A1 (de) 2001-02-02 2001-02-02 Verfahren und Vorrichtungen zum Zugreifen auf Nachrichten
EP01115495 2001-06-27

Publications (1)

Publication Number Publication Date
DE10104713A1 true DE10104713A1 (de) 2002-08-08

Family

ID=26008397

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2001104713 Withdrawn DE10104713A1 (de) 2001-02-02 2001-02-02 Verfahren und Vorrichtungen zum Zugreifen auf 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)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10340865B3 (de) * 2003-09-04 2004-07-15 Siemens Ag Verfahren und System zur Handhabung von Daten sowie Automatisierungssystem mit mehreren Automatisierungseinrichtungen

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9736209B2 (en) 2000-03-17 2017-08-15 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
US7088993B2 (en) * 2003-09-24 2006-08-08 Telefonaktiebolaget Lm Ericsson(Publ) Optimized message notification
US7843869B2 (en) * 2003-10-15 2010-11-30 Mitsubishi Denki Kabushiki Kaisha Roadside to vehicle communication system
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
JPWO2008099484A1 (ja) * 2007-02-15 2010-05-27 パイオニア株式会社 通信端末装置、通信管理装置、通信方法、通信プログラムおよび記録媒体
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 緯創資通股份有限公司 即時通訊方法、系統及電子裝置與伺服器
US10693825B2 (en) * 2018-06-06 2020-06-23 T-Mobile Usa, Inc. Systems and methods for editing, recalling, and deleting messages

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
FI973945A (fi) * 1997-10-13 1999-04-14 Nokia Telecommunications Oy 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
AU2001236576A1 (en) * 2000-01-28 2001-08-07 Ibeam Broadcasting Corporation A system and method for performing broadcast-enabled disk drive replication in adistributed data delivery network

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10340865B3 (de) * 2003-09-04 2004-07-15 Siemens Ag Verfahren und System zur Handhabung von Daten sowie Automatisierungssystem mit mehreren Automatisierungseinrichtungen
US8050258B2 (en) 2003-09-04 2011-11-01 Siemens Aktiengesellschaft Method and system for handling data based on the acknowledgement and extraction of data packets

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
EP1356645A2 (de) 2003-10-29

Similar Documents

Publication Publication Date Title
DE10104713A1 (de) Verfahren und Vorrichtungen zum Zugreifen auf Nachrichten
DE602004005319T2 (de) Nachrichtenverwaltung
AT411312B (de) Verfahren zum übermitteln von kurznachrichten (sms) zwischen rechnern im internet
DE69933760T2 (de) System und verfahren zur implementierung eines beantwortungsdienstes
EP1358742A2 (de) Verfahren zur nachrichtenversendung aus einem mms-system und einrichtung hierfür
DE19958707A1 (de) Verfahren zur Übertragung einer Textnachricht
WO2004109998A1 (de) Verfahren zum übertragen von nachrichten in einem auf mms basierten kommunikationssystem
EP1415488B1 (de) Verfahren zur übertragung von daten
DE102006001503B4 (de) Verfahren und System zum Übermitteln von Zusatzdaten
DE10117894A1 (de) Eingangsbestätigung von Multimedianachrichten
DE10314915A1 (de) Verfahen zur sofortigen Zustellung von Emails an mobile Telekommunikationsendgeräte
EP1525724B1 (de) Verfahren und system zum blockieren von unerwünschten nachrichten
EP1283636B1 (de) Multimedialer Nachrichtendienst mit dienstanbieterübergreifender Antwortvergebührungs-Funktionalität
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
DE102005015385A1 (de) Verfahren zum Umleiten mindestens einer Multimedianachricht in einem Mobilfunk-Kommunikationsnetzwerk, Multimedianachricht-Relaiseinrichtungen, Zentral-Mobilfunk-Servereinheit und Mobilfunk-Kommunikationsendgerät-Speicherelement
DE10241097B4 (de) Verfahren zum Gewinnen von Präsenzdaten
EP1520438A1 (de) Mms-nachrichten bertragungsverfahren und -system
WO1999008424A1 (de) Verfahren und vorrichtung zur generierung von informationen über versendete nachrichten
EP2016742B1 (de) Verfahren und vorrichtung zum aufbau einer themenbezogenen kommunikationsverbindung
DE10223205A1 (de) Verfahren zur Übertragung von Daten
EP1742431B1 (de) Selektive Push-Zustellung von elektronischen Nachrichten
EP1303090B1 (de) Verfahren zur Übertragung von Daten
EP2234350B1 (de) Weiterleitung von Nachrichten in Telekommunikationsnetzen
DE102008046713A1 (de) Verfahren zur Gruppen-Kommunikation zwischen Teilnehmern verschiedener Nachrichtendienste, Kommunikations-Endgerät und Computerprogrammprodukt

Legal Events

Date Code Title Description
8139 Disposal/non-payment of the annual fee