WO2002058359A1 - Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz - Google Patents

Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz Download PDF

Info

Publication number
WO2002058359A1
WO2002058359A1 PCT/EP2001/014617 EP0114617W WO02058359A1 WO 2002058359 A1 WO2002058359 A1 WO 2002058359A1 EP 0114617 W EP0114617 W EP 0114617W WO 02058359 A1 WO02058359 A1 WO 02058359A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
data
characterized
mms
method according
identification signal
Prior art date
Application number
PCT/EP2001/014617
Other languages
English (en)
French (fr)
Inventor
Andreas Schmidt
Markus Trauberg
Josef Laumen
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00Arrangements for user-to-user messaging in packet-switching networks, e.g. e-mail or instant messages
    • H04L51/24Arrangements for user-to-user messaging in packet-switching networks, e.g. e-mail or instant messages with notification on incoming messages
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/04Network-specific arrangements or communication protocols supporting networked applications adapted for terminals or networks with limited resources or for terminal portability, e.g. wireless application protocol [WAP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00Arrangements for user-to-user messaging in packet-switching networks, e.g. e-mail or instant messages
    • H04L51/38Arrangements for user-to-user messaging in packet-switching networks, e.g. e-mail or instant messages in combination with wireless systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W8/00Network data management
    • H04W8/26Network addressing or numbering for mobility support

Abstract

Bei einer Datenübertragung in einem Mobilfunknetz, insbesondere einer Übertragung von Text- und/oder Bilddaten mit und ohne Ton innerhalb Multimedia messages (MM), wird den Daten zumindest ein Identifikationssignal für einen Datensatz oder mehrere Datensätze zugeordnet und dieses oder diese Identifikationssignal(e) an den Empfänger der Daten übertragen.

Description


  



  Beschreibung VERFAHREN UND   MOBILTELEKOMMUNIKATIONSGERÄT    ZUR DATENÜBERTRAGUNG IN EINEM
MOBILFUNKNETZ Die Erfindung betrifft ein Verfahren zur Datenübertragung in einem Mobilfunknetz nach dem Oberbegriff des Anspruchs 1 sowie ein mobiles Telekommunikationsgerät nach dem Oberbegriff des Anspruchs 26, ein   Computerprogrammerzeugnis    nach Anspruch 30, sowie ein Funkkommunikationssystem nach Anspruch 32.



  Bisherige Mobilfunknetze, wie etwa das nach dem GSM-Standard arbeitende Netz, eröffnen noch recht eingeschränkte Möglichkeiten zur Übertragung von Textdaten. So können etwa bis zu 160 Zeichen umfassende Kurznachrichten übertragen werden.



  Diese Einrichtung wird als SMS (Short Message Service) bezeichnet. Für die Kosten des Versands derartiger   Textnach-    richten hat der Datenversender aufzukommen.



  Zukünftig soll auch eine Übertragung von Multimediadaten, insbesondere stehenden oder bewegten Bildern mit oder ohne Ton, möglich sein. Es ist mit einer erheblichen Ausweitung der Datenübertragungsmengen und der Datentypen innerhalb solcher Übertragungen zu rechnen, was mit erhöhter Übertragungszeit und einer Kostensteigerung einhergeht.



  Der Erfindung liegt das Problem zugrunde, die Kontrolle der Datenübertragung für Teilnehmer eines Mobilfunknetzes zu vereinfachen.



  Die Erfindung löst dieses Problem durch ein Verfahren mit den Merkmalen des Anspruchs   1,    sowie durch ein   Mobiltelekommuni-    kationsgerät mit den Merkmalen des Anspruchs 26, ein Compu  terprogrammerzeugnis    mit den Merkmalen des Anspruchs 30, sowie durch ein Funkkommunikationssystem nach Anspruch 32. Hin sichtlich vorteilhafter Ausgestaltungen wird auf die Ansprüche 2 bis 25,27 bis 29 und 31 verwiesen.



  Mit dem   erfiridungsgemässen    Verfahren ist eine Information an den Datenempfänger über Charakteristika der zum Empfang bereitstehenden Daten möglich, was diesem die Kontrolle hier über erleichtert.



  Bei Vorabzusendung des oder der Charakteristika der zu übersendenden Daten angebenden Identifikationssignal (e) ist die Kontrolle bereits vor Empfang der eigentlichen Daten ermöglicht, wobei besonders vorteilhaft dem Empfänger anhand der so erhaltenen Information eine Auswahlmöglichkeit eröffnet ist, ob er die bereitstehenden Daten jetzt oder später oder gar nicht empfangen möchte. Wenn auch die Wahlmöglichkeit eines teilweisen Empfangs einer Multimedia message (MM) vorgesehen ist, kann der Empfänger beispielsweise nur für ihn wichtige Kurzinformationen, die eine kurze Übertragungszeit benötigen, herunterladen und eventuell zugehörige speicherintensive Bildbestandteile oder ähnliches später oder gar nicht herunterladen.



  Wenn das dafür eingesetzte Identifizierungssignal Information über die Grösse eines zu empfangenden Datensatzes enthält, kann der Empfänger daran ermitteln, wieviel Zeit er für die Übertragung und/oder das Studium der Daten rechnen muss und ob er diese Zeit jetzt oder zu einem späteren Zeitpunkt oder gar nicht aufbringen will.



  Wenn das Identifizierungssignal Information über den Namen eines Datensatzes enthält, kann der Empfänger daran ermitteln, aus welchem Themenkomplex die Daten stammen. Auch daran kann er vorteilhaft auswählen, ob er diesen oder diese Datensatz oder Datensätze jetzt oder zu einem späteren Zeitpunkt oder gar nicht empfangen will. 



  Besonders vorteilhaft kann im Identifikationssignal auch Information über den Datentyp gegeben sein, so dass der Empfänger weiss, ob es sich beispielsweise um Bilddaten, Textdaten   und/oder    Musikdaten handelt.



  Kontrolle und Transparenz sind damit entscheidend verbessert.



  Weitere Vorteile und Merkmale der Erfindung ergeben sich aus in den Zeichnungen neu dargestellten und nachfolgend be  schriebenen    Ausführungsbeispielen des Gegenstandes der Erfindung.



  Es zeigen : Fig.   1    eine schematische Abbildung von einer Datenübertra gung zugeordneten Sendungen gemäss dem WAP-Standard  (Wireless application protocoll) zwischen der Ebene des Versenders und der des Providers einerseits und der Ebene des Providers und der des Empfängers an dererseits, Fig. 2 die Header-Felder einer nach dem in Fig.   1    gezeig ten WAP-Standard gesendeten Nachricht M-Send. req, wobei die erfindungsgemäss neu eingefügten Header
Felder grau unterlegt sind, Fig. 3 eine Spezifizierung des Typs der in Fig. 2 gezeig ten und in den grau unterlegten Feldern abgelegten
Informationen sowie des zusätzlich im   Statusbericht    auftretenden Feldes über den Erhalt der versandten
Daten, Fig. 4 eine Darstellung der Zuweisung der Header-Felder aus Fig.

   2 zu den binären Codes, wobei die erfin dungsgemäss neu eingefügten Header-Felder grau un terlegt sind,  Fig. 5 eine ähnliche Darstellung wie Fig. 2 der nach dem in Fig.   1    gezeigten WAP-Standard gesendeten Nach richt M-Notification. ind (MNI), Fig. 6 eine ähnliche Darstellung wie Fig. 2 der nach dem in Fig.   1    gezeigten WAP-Standard gesendeten Nach richt M-Retrieve. conf (MRC), Fig. 7 eine ähnliche Darstellung wie Fig. 2 der nach dem in Fig.   1    gezeigten WAP-Standard gesendeten Nach richt M-Acknowledge. ind (MAI), Fig. 8 eine ähnliche Darstellung wie Fig. 2 der nach dem in Fig.   1    gezeigten WAP-Standard gesendeten Nach richt M-Delivery. ind. (MDI), Figuren 9-17 und 23-25 jeweils exemplarisch   den.

   Inhalt    verschiedener In formationssignale für die Übertragung von Multime dianachrichten zwischen mehreren Komponenten eines
Funkkommunikationssystems nach dem erfindungsgemä  ssen Verfahren, Figur 18 das Encoding eines einzigen Header-Feld-Namens, Figur 19 Encoding (Kodierung) der neuen Parameternamen und
Parameterwerte im einzigen Headerfeld nach Figur 9, Figur 20 Zuweisung binärer Codes zu den Feldnamen der Para meter im einzigen Headerfeld nach Figur 9, Figur   21A,    21B das einzige Header-Felder einer Multimedia
Service (MMS) Sendeanfrage (in WAP Message M 
Send. req ;), und Figur 22 das zur Sendeanfrage MSreq nach Figur 12A, 12B zuge hörige Header-Felder der MMS Empfängerbenachrichti gung (M-Nind ;

   in WAP Message M-Notification. ind ;) Elemente mit gleicher Funktion und Wirkungsweise sind in den Figuren 1 mit 13 jeweils mit denselben Bezugszeichen versehen.



  Im Ausführungsbeispiel ist die Anwendung der Erfindung auf ein Datenübertragungsschema 1 für den WAP-Standard, wie es in der Übertragung von insbesondere Bilddaten und formatierten Textdaten im UMTS-Standard (Universal mobile telecommunication standard) Verwendung finden wird, beschrieben. Es versteht sich, dass die Erfindung auch auf andere Standards übertragbar ist.



  Im UMTS-Standard ist vorgesehen, zusätzlich zum bisherigen SMS einen sogenannten MMS (Multimedia Messaging Service) für die Übertragung von Nachrichten, auch als Multimedia messages (MMs) bezeichnet, vorzusehen. Damit können auch formatierte Texte und Bilder mit und ohne Ton übertragen werden. Die im SMS vorhandene Beschränkung auf eine Nachrichtenlänge von 160 Zeichen entfällt. Eine Übertragung von Audio-und Videonachrichten ist möglich.



  MMS ist über die Nutzung von WAP realisierbar. Dabei wird für die Funkübertragung von Daten, etwa von Multimedia Messages (MMs), das in Fig.   1    dargestellte Protokollschema (WAP WSP : Wireless Session Protocoll) angewandt. Dieses umfasst eine Ebene 2 eines Datenversenders (auch als MMS User Agent A bezeichnet), eine Ebene 3 eines Providers (, dessen Netzelement, das den Service ausführt, auch als MMS Relay bezeichnet wird) und eine Ebene 4 eines Empfängers (auch als MMS User  Agent B bezeichnet). Die Ebene 2 des Datenversenders umfasst zumindest ein Telekommunikationsgerät 5, ebenso umfasst die Ebene 4 des Empfängers ein Telekommunikationsgerät 6. Diese Telekommunikationsgeräte 5,6 können beispielsweise als übliche Handies oder als Geräte mit weiteren Eingabe-oder Anzeigefunktionen, wie etwa Laptops, ausgebildet sein.



  Eine im Telekommunikationsgerät 5 des Versenders erfasste oder über dieses weiterzuleitende Multimedia message abgekürzt (MM) kann einen oder mehrere Einheiten (Datensätze 7), beispielsweise einzelne Bilder, Filmsequenzen, Texte oder ähnliches, enthalten. Die MM wird zunächst als Anfrage-Sendung 9 (diese trägt im WAP-Protokoll den Namen M-Send. req) an den Provider (Ebene 3) versandt.



  Von dort wird die eingegangene Sendung 9 mit der Rücksendung 10 (M-send. conf) an den Versender (Ebene 2) quittiert.



  Zeitlich darauffolgend wird vom Provider (Ebene 3) die Information 11 (M-Notification. ind) an den Empfänger (Ebene 4) gesandt, mit der dieser darüber informiert wird, dass für ihn eine Nachricht beim Provider 3 zum Herunterladen bereitliegt.



  Hierüber erhält der Provider 3 beispielsweise automatisch die quittierende Rückmeldung 12 (M-NotifyResp. req) vom Telekommunikationsgerät 6 des Empfängers (Ebene 4).



  Erst auf Anforderung durch den Empfänger mit der Sendung 13 (WSP GET. req) wird vom Provider die MM mit der Sendung 14 (Mretrieve. com) an den Empfänger weitergeleitet.



  Die Nachricht 15 (M-Acknowledge. ind) quittiert den Empfang der MM.



  Die abschliessende Nachricht 16 (M-Delivery. ind) gibt eine Empfangsbestätigung an den Versender 2 zurück. 



  Zur Verwaltung der Sendungen 9,10,11,12,14,15,16 dienen die sog. Header-Felder, also der eigentlichen MM vorangestellte Felder, in denen Informationen über die Herkunft, Sendezeit, Dateigrösse und weitere Details enthalten sein können.



  Erfindungsgemäss ist die Anzahl der Header-fields erhöht, um zumindest ein weiteres Feld 17,18,19,20,21,22,23 als Informationsfeld (er) über charakterisierende Parameter der MM informieren zu können und darin ein oder mehrere Identifizierungssignal (e) für diese (n) Parameter dem Empfänger 4 zusenden zu können.



  Im Ausführungsbeispiel sind dafür (sh. Fig. 4) die mit   0x80    bis   0x86    im Hexadezimalsystem adressierten Felder 17,18,19, 20,21,22,23 vorgesehen, um die Information über die Parameter, die weiter unten noch näher beschrieben werden, aufzunehmen. Auch eine andere Anzahl und/oder Adressierung der zusätzlichen Header-Fields ist möglich.



  Die zusätzlichen genannten Header-Fields 17,18,19,20,21, 22,23 sind zumindest in der Nachricht 11 (M Notification. ind), mit der der Empfänger 4 über das Bereitstehen einer MM informiert wird, beigefügt. Auch die Nachricht 9 (M-Send. req) kann, wenn die zusätzlichen Parameter vom Versender 2 generiert werden, die zusätzlichen Header Fields 17,18,19,20,21,22,23 enthalten (Fig. 2), ebenso die eigentliche MM-Zustellung 14 (M-Retrieve. conf) (sh. Fig.



  5) oder weitere der Nachrichten 10,12,13,15,16.



  Unter einem Datensatz 7 einer MM wird im folgenden ein einzelner Bestandteil einer MM verstanden, der durch seinen Typ (z. B. Standbild) und sein Format (z. B. JPEG) definiert ist, wobei im MMS auch eine Formatkonvertierung durch das MMS Relay 3 vorgesehen ist, durch die gewährleistet wird, dass auch  Telekommunikationsgeräte 6 eines Empfängers 4, die nur bestimmte Formate eines Typs unterstützen, auch nur mit diesen Formaten bedient werden. Beispielsweise kann ein Telekommunikationsgerät 6 nur Standbilder im JPEG-Format anzeigen, was es im Rahmen seiner Anmeldung dem MMS Relay 3 mitgeteilt hat.



  Das MMS Relay 3 konvertiert dann alle für diesen Empfänger eingehenden Standbilder in das JPEG-Format, wodurch sich im allgemeinen die Dateigrösse ändert. Dieser Aspekt ist für eine spätere Betrachtung der nach dieser Erfindung neuen Header Felder relevant.



  Als Identifikationssignal können beispielsweise die folgenden Informationen über einen Datensatz 7 enthalten sein. Auch eine andere Anzahl von Informationen, etwa nur eine Auswahl aus den aufgeführten, kann vorgesehen sein. Die Informationen werden dem Empfänger einer MM optional bei Verwendung des WAP-Standards (Fig. 1) in der Benachrichtigung 11 (M Notification. ind), und damit vor Übertragung der eigentlichen Daten in der Multimedia message, zur Verfügung gestellt.



  Mögliche Parameter von zu übertragenden Daten, insbesondere einer MM, über die der Empfänger vorab informiert wird, sind :
1. die Anzahl der enthaltenen Datensätze 7 der MM (auch implizit durch die Beschreibung der einzelnen Elemente der MM),
2. die jeweilige Grösse (in Octets) eines Datensatzes 7,
3. der jeweilige Typ und das Format eines Datensatzes 7,
4. die jeweilige Content ID (Content IDentification) eines
Datensatzes eventuell auch relativ zu der Content    ID/Message    ID der gesamten MM,
5. der jeweilige Name eines Datensatzes,
6. das Subjet der gesamten MM,
7. die Verbindung eines Elements zu einem oder mehreren anderen Datensätzen 7 der MM, 
8.

   die Verbindung der gesamten MM oder eines/mehrerer Da tensätze 7 zu einer oder mehreren URLs/URIs ausserhalb der MM und bei einem solchen externen Link optional die
Grösse der zu ladenden Daten des/der aufgelösten externen
Links.



  Mit Hilfe der neuen Header-Felder 17,18,19,20,21,22,23 kann die Methode der"detailed Notification"im MMS umgesetzt und der Komfort des MMS für den Benutzer deutlich erhöht werden. Schon vor dem Laden einer MM und damit voraussichtlich schon bevor Kosten für den Benutzer entstehen, wird dieser über die Inhalte und die Zusammensetzung der MM detailliert informiert und kann entsprechend handeln, etwa dadurch, dass er nur einzelne Datensätze 7 der MM herunterlädt und weitere ablehnt.



  Eine MM besteht grundsätzlich aus einem Header und abhängig vom Typ der MM zusätzlich aus einem Datenteil (WAP : Body).



  Der Header umfasst allgemeine Informationen der MM und setzt sich aus definierten Header-Feldern zusammen. Der Datenteil der Message enthält ein oder mehrere Elemente beliebigen Typs (z. B. Texte, Bilder, Töne...), die in beliebiger Reihenfolge dem Header folgen. Falls eine Präsentationsbeschreibung im Datenteil enthalten ist, soll in einer WAP-Message zu Beginn des Datenteils ein sogenannter Start-Parameter auf diese Präsentationsbeschreibung hinweisen.



  Jedes Header-Feld besteht aus einem Feld-Namen, gefolgt von einem Feld-Wert, der aus mindestens einem Octet besteht. Die Zuweisung von hexadezimalen Werten zu den Feld-Namen ist in Fig. 4 aufgeführt.



  Um die Benachrichtigung 11 an den Empfänger   4 mit    den gewünschten Informationen anzureichern, bestehen grundsätzlich zwei Möglichkeiten : Entweder werden die Informationen vom Provider 3 oder vom Versender 2 erstellt. Auch eine Mischform ist möglich. Im einzelnen sind hierfür die folgenden Abläufe möglich : Die Informationen werden aus der am MMS Relay 3 mit der Nachricht 9 eintreffenden MM extrahiert, d. h. teilweise aus Header-Feldern unverändert übernommen und teilweise aus dem Datenteil der. MM berechnet (z. B. die Angabe der Grösse eines Datensatzes 7).



  Vorteilhaft bei diesem Vorgehen ist die zu erwartende Konsistenz zwischen den beschreibenden Header-Informationen der Nachricht 11 und den tatsächlichen Inhalten 14 (in WAP : M Retrieve. conf), die auf Anforderung des Empfängers 4 (User Agent B) an diesen übertragen werden. Der Realisierungsaufwand beim Versender 2, und damit i. d. R. im mobilen Endgerät, bleibt gering. Ein weiterer Vorteil besteht hinsichtlich der Genauigkeit der Grössenangabe, wenn Formatkonvertierung stattfindet. Bei MMS ist vorgesehen, dass vor Auslieferung der Daten eine Anpassung des Inhalts an z. B. Fähigkeiten des empfangenden MMS User Agents 4 (wie unterstützte Codecs, Display-Grösse des Endgeräts etc.) oder Vorlieben des Empfängers (wie automatische Beschränkung auf eine maximale Grösse) durch den Service Provider 3 stattfinden kann.

   Das MMS Relay 3 kann dem Empfänger 4 die Grösse des Inhalts nach Datenanpassung mitteilen. Dies ist eine Information, die der Versender 2 nicht besitzt. Nachteilig ist der beim MMS-Relay 3 zusätzliche Aufwand zur Generierung der Informationen für diese "detailed Notification", der durch das notwendige"Parsen" der MM und die Extraktion der entsprechenden Informationen entsteht.



  Die Informationen können statt dessen bereits vom Versender 2 generiert und als Header-Felder 17 ; 18 ; 19 ; 20 ; 21 ; 22 ; 23 in die Nachricht 9 zum Versenden einer MM (in WAP : M-Send. req) explizit integriert werden. Vorteilhaft ist die unveränderte Verarbeitung der MM im MMS Relay 3, das nicht den Inhalt der  MM analysieren muss. Die Realisierung der mit den neuen Header-Feldern 17 ; 18 ; 19 ; 20 ; 21 ; 22 ; 23 eröffneten Möglichkeiten im Terminal 5 kann vom Hersteller bestimmt werden. Es besteht darüber hinaus die Möglichkeit, Endgeräte mit unterschiedlichen Komfortmerkmalen anzubieten. Weiterhin kann der MMsendende Teilnehmer 2 sein Wissen über die interne und externe Verknüpfung der MM-Elemente dem MM-Empfänger in Form von detaillierten Informationen mitteilen, welche vom MMS-Relay 3 lediglich weitergeleitet werden.

   Eine Generierung der Header Felder im MMS Relay 3, die Wissen über die interne und externe Verknüpfung der Datensätze 7 erfordert, wäre dort nur durch aufwendiges Parsen der MM möglich. Nachteilig ist die Erweiterung von Header-Feldern mit teilweise redundanten Informationen.



  Vorteilhaft werden die Informationen daher teilweise im sendenden User Agent 2 und teilweise im MMS Relay 3 generiert, was auf Seiten des MMS Relay 3 auch die Aktualisierung bereits vorhandener, vom Versender 2 generierter Header-Felder erfordert.



  Für diese Mischform der Generierung zusätzlicher Informationen kann folgende Aufteilung der im folgenden erklärten Informationen vorgesehen sein : Generierung im sendenden User Agent 2 :   X-Mms-Content-ID    : In der bisherigen WAP-Spezifikation fehlen die Möglichkeiten, den Datensätzen 7 eigene zu sätzliche Header-Felder zuzuordnen (z. B. mit jeweiligem
Namen und Typ) und mehrere Datensätze 7 hierarchisch an zuordnen. Für eine transparente Konvertierung einer MM in eine Internet-Mail (Format gemäss RFC 822 mit Erweiterun gen gemäss MIME (Multipurpose Internet Mail Extensions)) werden daher die hier folgenden Voraussetzungen vorge schlagen : Die zu jeder Extension einer E-Mail möglicher weise zusätzlich im Datenteil der E-Mail codierten Infor mationen (Name, Typ,...) sind transparent auch in einer
MM enthalten.

   Eine Content-ID im Header der MM, die jedem
Datensatz 7 eindeutig zugeordnet ist, kann als Verweis genutzt werden. Der Start-Parameter im Message-Body   (=   
Datenstrukturabschnitt, der eigentliche Mitteilungsinfor mation (en) enthält) muss als Feld definiert sein, das die
Content-ID (= Inhaltsidentifikator) CI des Präsentations    beschreibungsobjektes    enthält und damit den Zugriff auf dieses Objekt ermöglicht. Mit diesen Vereinbarungen ist eine transparente Übertragung einer MM von einem MMS
Relay zu einem beliebigen Empfänger sowohl direkt über ein anderes MMS-Relay als auch über das Internet per E
Mail möglich. Eine eindeutige Zuordnung zu dem Datensatz oder den Datensätzen 7 in der MM ist unbedingt für die erste Übertragung vom sendenden User Agent 2 zum MMS Re lay 3 erforderlich.



     X-Mms-Content-Type    : bezeichnet den Typ und das Format des Datensatzes 7. Diese sollten bereits beim Versenden eingetragen werden, da der Datensatz 7 nicht unbedingt einen Dateinamen wie in einer E-Mail erhält und dann nicht über die Dateierweiterung (Extension) einem Format zugeordnet werden kann. Eine Aktualisierung dieses Feldes durch das MMS Relay 3 ist nur bei einer Format-und/oder
Typkonvertierung erforderlich. Der X-Mms-Content-Type wird durch den Wert oder das Signal CTV angezeigt und be stimmt.



     X-Mms-content-Size    : Grösse des Datensatzes 7. Dieser wird durch Wert bzw. Inhalt CSV angezeigt und bestimmt.



     X-Mms-Content-Name    : Name des Datensatzes 7. Dieser Name ist nur dem sendenden User Agent 2 bekannt und muss daher von ihm eingesetzt werden. Ihm ist der Inhalt CNV zuge ordnet. 



     X-Mms-External-Link-Flag    : Zeigt an, dass der Datensatz 7 eine Verknüpfung auf Inhalte ausserhalb der MM enthält.



   Wenn diese Information vom sendenden User Agent 2 einge setzt wird, ist eine Inhaltsanalyse des Datensatzes 7 durch das MMS Relay 3 entbehrlich. Ihm ist inhaltlich der
Wert oder die Zeichenfolge ELF zugeordnet.



     X-Mms-External-Link-Size    : Damit wird die Grösse eines verknüpften Inhalts ausserhalb der MM angegeben. Dies wird durch den Inhalt ELS angezeigt. Da der   Datenumfang    eines externen Inhalts nicht an der Verknüpfung selbst abzule sen ist, ist diese Information für einen Nutzer von gro  ssem Interesse. Sie kann direkt bei der Generierung der MM im sendenden MMS User Agent 2 erzeugt werden. Alternativ ist eine Generierung durch das MMS-Relay 3 möglich, er fordert jedoch neben der Analyse der gesamten MM auch den
Zugriff auf in Referenz angeführte Objekt zwecks Grössen bestimmung.



     X-Mms-Content-Related-URI    : Die Information CRV dieses
Feldes zeigt den Ort eines anderen Elements, auf das der
Datensatz 7 Bezug nimmt, an. Beispielsweise enthält ein
Datensatz 7 eine Präsentationsbeschreibung, die sich auf andere Elemente mit Audio-, Video-oder anderen Inhalten der MM bezieht. Die Generierung dieser Informationen er fordert einerseits Wissen über die internen Bezüge der E lemente einer MM, das auf Seiten des sendenden MMS User
Agents 2 vorhanden ist, und andererseits Wissen bezüglich der Positionen der MM-Elemente beim MMS-Relay/Server 3 bzw. beim Empfänger 4. Die Informationen können auf Sei ten des sendenden MMS User Agents 2 in Header-Feldern co diert werden und sind durch das MMS-Relay 3 auf Basis der dann aktuellen Positionen zu korrigieren/aktualisieren und anschliessend im empfangenden MMS User Agent 4 auszu werten.



  Generierung bzw. Aktualisierung im MMS Relay 3 :   X-Mms-Content-ID    : Wird bei Veränderungen Content-ID durch das MMS Relay angepasst.



     X-Mms-Content-Type    : Falls das MMS Relay 3 den Typ und/oder das Format eines Datensatzes 7 ändert, erfolgt die entsprechende Aktualisierung des Content-Type.



     X-Mms-Content-Size    : Grösse des Datensatzes 7, angegeben in Octets. Nur falls das MMS Relay 3 Typ   und/öder    Format des Datensatzes ändert, erfolgt eine Aktualisierung der die Content-Size betreffenden Information.



  Mit den differenzierten Informationen, die ein Benutzer 4 mit der Nachricht 11 (WAP : M-Notification. ind) erhalten hat, ist über den beispielsweise softwareseitig in einem Menü implementierten und über ein Eingabemittel, etwa eine Tastatur, zu bedienenden Auswahlschalter 25 ein Zugriff auch auf einzelne Datensätze 7 möglich. So kann ein partielles Download durch eine Downloadanforderung mit der Content-ID eines jeweils gewünschten Datensatzes 7 (beispielsweise eines Fotos ohne gleichzeitige Mitübertragung des Begleittextes) in WAP mit dem Befehl 13 : WSP GET. req veranlasst werden.



  Um dieses zu ermöglichen, muss das grundsätzliche Problem gelöst werden, dass die zusätzlichen Header-Felder teilweise in einer MM mehrfach verwendet werden müssen (WAP : z. B. X-Mms Content-Name für jeden Datensatz 7 der MM). Stehen mehrere Header-Felder in einem inhaltlichen Zusammenhang, was bei der Beschreibung eines Datensatzes der Fall ist, muss auch eine syntaktische Zuordnung definiert sein.



  Grundsätzlich ist im WAP-Standard die Reihenfolge der Header Felder unerheblich. Eine Veränderung der Reihenfolge der Informationen Name, Grösse, Typ und/oder URI mehrerer Datensätze 7 würde damit eine Veränderung bzw. Verfälschung der Beschreibungen der Datensätze 7 bewirken, wenn man die Zuord nung der Informationen von der Reihenfolge der Header Elemente abhängig machte, was der einzig gangbare Weg ist, da eine hierarchische Struktur der Header-Elemente in WAP nicht vorgesehen ist.



  Andererseits steht die Aussage der Irrelevanz der Header Element-Reihenfolge im Widerspruch zu der Aussage, dass HTTP Header, die Listen enthalten, in mehrere WSP-Header mit jeweils nur einem einzigen Element umgewandelt werden sollen, wobei die Reihenfolge der Einträge erhalten bleiben soll. Um diesen Widerspruch aufzulösen, wird eine Systematik entworfen, die die Signifikanz der Reihenfolge der Header-Elemente voraussetzt.



  Zur Abgrenzung der Beschreibungen einzelner Datensätze 7 muss ein definiertes Header-Feld die Beschreibung eines Datensatzes 7 beginnen, der alle nachfolgenden Header-Felder zugeordnet werden, bis entweder das Ende des Headers der Message erreicht ist oder ein nächstes Header-Feld des definierten Typs den Beginn der Beschreibung eines weiteren Datensatzes 7 markiert.



  Als definiertes Header-Feld für die Beschreibung eines Datensatzes 7 dient das Feld 17 : X-Mms-Content-ID, da es die eindeutige Adresse des Elements enthält. Die Beschreibung eines Datensatzes 7 wird grundsätzlich durch dieses Feld eingeleitet, worauf die weiteren Felder optional und in beliebiger Reihenfolge erscheinen können.



  Alternativ zu der Systematik mit eindeutigen Marken für die Message-Elemente-den   Content-IDs-und    den entsprechenden Verweisen im Header ist auch eine Systematik möglich, die mit der Angabe eines Offsets bis zu dem beschriebenen Datensatz im Datenteil der MM arbeitet. Nachteilig sind dabei allerdings zum einen die Gefahr, den Offset nicht korrekt zu berechnen bzw. bei einer möglichen Formatkonvertierung im MMS  Relay 3 nicht korrekt anzupassen, und zum anderen die fehlende Möglichkeit, eine logische Beziehung zwischen einer Beschreibung eines Datensatzes 7 in der Benachrichtigung 11 und in der tatsächlichen Übersendung 14 der MM herzustellen. Die Informationen müssten dann in der zugestellten Multimedia Message noch einmal enthalten sein.



  Der Versender (Ebene 2) kann an seinem Telekommunikationsgerät 5 eine hardwareseitig oder insbesondere softwareseitig und über die ohnehin vorhandene Tastatur zu bedienende Eingabemöglichkeit betätigen, um damit in den Header-Feldern 17, 18,19,20,21,22,23 die zusätzlichen Informationen oder einen Teil dieser Informationen (s. o.) zu hinterlegen. Diese werden als Bestandteil eines Identifizierungssignals für einen oder mehrere Datensätze 7 der MM mit der Sendung 9 (in WAP : M-Send. req) (Fig. 1) an den Provider (Ebene 3) gesandt.



  Die Bestätigung des Versands durch das MMS-Relay 3 (in WAP mit der Nachricht 10 : M-Send. conf) bleibt unverändert, da die einzige wesentliche Information die optional vom MMS-Relay 3 vergebene Message-ID ist.



  Der Empfänger 4 erhält dann die Nachricht 11 (in WAP M Notification. ind), dass für ihn eine MM mit einem oder mehreren Datensätzen 7 zum Herunterladen bereitliegt. Diese Benachrichtigung 11 enthält wiederum alle zusätzlichen Header Felder 17,18,19,20,21,22,23 zur Beschreibung der Datensätze 7 aus dem Header der Nachricht 9 zu ihrem Versenden (in WAP : M-Send. req). Diese Information kann dem Empfänger optisch (über das Anzeigemittel 24, beispielsweise das Display) oder akustisch mitgeteilt werden.



  Die Bestätigung 12 (WAP : M-NotifyResp. ind) des Empfangs der Notification 11 bleibt unverändert.



  Nachdem der Empfänger 4 der MM detailliert über deren Inhalt informiert ist, kann er die gesamte MM (in WAP : durch das  Kommando 13 : WSP Get. req) herunterladen. Alternativ ist nach dieser Erfindung auch ein Zugriff auf ein einzelnes Element der MM möglich. Hierzu wird beispielweise als URI die Content-ID eines Datensatzes 7 der MM in das Kommando zum Download eingesetzt. Ohne Zustimmung des Empfängers 4 wird ein Herunterladen der MM (Übersendung der Sendung 14 an den Empfänger) nicht freigegeben. Auch ist es möglich, dass der Empfänger 4 die MM erst zu einem späteren, billigeren Zeitpunkt übermittelt bekommen will.



  Die eigentliche Datensendung 14 kann die beschreibenden Header-Felder 17,18,19,20,21,22,23 enthalten. Dies ist jedoch nicht zwingend, wie in Fig. 7 dargestellt.



  Schliesslich schickt das MMS-Relay 3, wenn vom Versender 2 gewünscht, eine Mitteilung 16 über den Status der Zustellung der MM (in WAP : M-Delivery. ind) an diesen. Neben den bisher schon bekannten Möglichkeiten"Expired"   (verfallen),"Retrie-    ved"   (zugestellt),"Rejected"      (abgelehnt),"Deffered"    (verzögert)"kann erfindungsgemäss auch"Partly-retrieved" (partiell zugestellt) im Statusfeld auftreten. Es wird angezeigt, welcher Datensatz 7 zugestellt wurde.

   Der entsprechende Abschnitt der Nachricht 16 könnte wie folgt lauten :        >     7.2.22 Status field (Status-Feld) Status-value = Expired | Retrieved | Rejected   1 Deferred 1 Partly-retrieved    Expired = Octet 128 >  Retrieved   =  < Octet    129 >  Rejected   =  < Octet    130 >  Deferred    < Octet 131 >     Partly-retrieved =  < Octet 132 >       <       Die ebenfalls neuen Felder 22,23 X-Mms-External-Link-Flag (optional) und  X-Mms-External-Link-Size (optional) können in den Nachrichten 9 zum Versand der MM (WAP : M Send. req) und in der Nachricht 11 an den Empfänger 4 (WAP : M Notification. ind) die im Inhalt der MM enthaltenen Links auf Inhalte ausserhalb der MM anzeigen.

   Je nach Position im MM Header zeigt das Feld 22 : X-Mms-External-Link-Flag einen Link auf externe Inhalte innerhalb der gesamten MM oder innerhalb eines bestimmten Datensatzes 7 der MM an. Das Feld 23 : X-Mms External-Link-Size beschreibt optional die Grösse des Inhalts in Octets. Damit kann der Empfänger der Notification bereits abschätzen, welches zusätzliche Datenvolumen zu dem der MM selbst noch herunterzuladen ist.



  Das vorgestellte Verfahren kann in eine Software zum Betreiben des jeweiligen Kommunikationsstandards, etwa UMTS, integriert sein. Die Telekommunikationsgeräte 5,6 sind dann mit einer entsprechenden Software versehen.



  Im folgenden ist ein konkreter Ablauf der erfindungsgemässen Übermittlung einer MM nach dem WAP-Standard (Fig. 1) dargestellt : Es wird beispielhaft folgendes Szenario angenommen : Versender 2 (Markus Trauberg) verschickt eine MM mit einem Text mit mehreren Datensätzen 7, nämlich einem MP3-Audio, einem JPEG Bild, einem MPEG-4-Video und einer SMIL-Präsentationsbeschreibung, an zwei Empfänger 4 (Andreas Schmidt und Josef Laumen). Zur komfortablen und differenzierten Nutzung durch die Empfänger 4 fügt er Beschreibungen von Parametern der Datensätze 7 der MM ihrem Header bei. Die Daten werden in den Nachrichten 9 (M-Send. req) und 11 (M-Notification. ind) an die Empfänger übertragen. Empfänger 4 Andreas Schmidt lädt die komplette MM auf sein Endgerät 6, während Empfänger 4 Josef Laumen nur an dem Text interessiert ist und nur diesen auf sein Endgerät 6 lädt.

   Die folgenden MMs werden zwischen den Einheiten übertragen : MM wird an zwei Adressaten verschickt. Dann kann das Nach  richtenprotokoll    wie in Figur 9 abgebildet sein.



  In der MM sind im Header die zusätzlichen Informationsblöcke über die MM-Elemente codiert. Darin werden auch die Beziehungen zwischen den Datensätzen 7 der MM beschrieben : So enthält die Beschreibung der presentation-description Verweise auf die darin externen Elemente image/jpeg, audio/mp3 und video/mpeg4 in Form der entsprechenden Content-IDs.



  Die Beschreibung des Textes enthält die Information, dass ein Verweis auf ein externes Objekt enthalten ist, das 8245 Byte Daten umfasst.



  Die Quittierung der oben aufgeführten Sendeanfrage 9 (M Send. req) des Versenders 2 erfolgt mit der Nachricht 10 (M Send. conf) vom MMS Relay 3. Diese Nachricht 10 enthält keine zusätzlichen neuen Felder, wie an ihrer folgenden Aufstellung sichtbar ist, die in Figur 10 abgebildet ist.



  Das MMS Relay 3 bestätigt mit Nachricht 10, dass die Anfrage 9 fehlerfrei zum MMS Relay 3 übertragen worden ist. Es wird die   Transaction-ID&num;1    benutzt, um die Nachricht 10 beim Versender 2 eindeutig der dazugehörigen Anfrage 9 (M-Send. req) und damit der gesendeten MM zuzuordnen. Weil in der Nachricht 9 in dem Feld X-Mms-Delivery-Report ein Zustellungsreport angefordert wurde, weist das MMS Relay 3 der MM eine Message-ID zu und übermittelt diese hier an den Versender 2.



  Im weiteren wird die Nachricht 11 an die Empfänger 4 übertragen : M-Notification. ind (MMS   Relay-    MMS User Agent   B) :     Im MMS ist vorgesehen, einen Empfänger einer MM über neue Nachrichten, die für ihn vorliegen, zu informieren. Die Nachricht 11 (M-Notification. ind) dient der Benachrichtigung der Adressaten über zum Download bereitliegende MM. Folglich existieren in diesem Beispiel zwei Benachrichtigungen an die Empfänger Andreas Schmidt und Josef Laumen. Jede enthält eine eigene Transaction-ID. Die Information über den Speicherplatz der MM steht bei beiden in dem Feld X-Mms-Content-Location.



  Figur 11 gibt den Inhalt der M-Notification-ind exemplarisch wieder.



  Neben den üblichen Feldern zu Beginn der Nachricht 11 können nun alle beschreibenden Elemente der Nachricht 9 in die Nachricht 11 übernommen werden. Zusätzlich werden, wie oben anhand der Mischform beschrieben, durch das MMS Relay 3 noch die Informationen X-Mms-Content-Type und X-Mms-Content-Size aus den Informationen des Body der Nachricht 9 generiert. Der Empfänger 4 kennt nach Erhalt der Nachricht 11 sowohl die Adresse der MM (wie bisher) als auch die Zusammensetzung aus den einzelnen Datensätzen 7 und deren Content-IDs. Ein Zugriff ist daher auch separat auf einzelne Datensätze 7 der MM möglich.



  Der korrekte Empfang der Benachrichtigung wird anschliessend von dem Empfänger 4 der MM mit der Nachricht 12 (M NotifyResp. ind) bestätigt, indem die entsprechende Transaction-ID der Nachricht 11 zusammen mit einer Statusmeldung zurück zum MMS Relay 3 geschickt wird.



  Der Download der MM wird durch das Kommando 13 (WSP GET. req) veranlasst. Die MM wird darauf vom MMS Relay 3 in der Nachricht 14 (M-Retrieve. conf) zum Empfänger 4 gesendet. 



  Da die Informationen über die einzelnen Elemente bereits mit der Nachricht 11 übertragen wurden, kann der Download der gesamten MM wie bisher mit der Nachricht 14 erfolgen, ohne dass zusätzliche Felder im Header dieser Nachricht 14 eingefügt werden müssen. Die zusätzlichen Informationen in den Headern der einzelnen Datensätze 7 hingegen sollten auch in der Nachricht 14 enthalten sein, da sie wichtige Informationen über die MM-Datensätze 7 enthalten.



  Im folgenden sind zwei mögliche Reaktionen der Empfänger 4 beispielhaft dargestellt : Empfänger Andreas Schmidt lädt die gesamte MM.



  Empfänger Josef Laumen lädt nur den Textteil der MM auf sein Empfangsgerät 6.



  Im ersten Fall wird die Nachricht 14 wie in Figur 12 abgebildet codiert : Der Empfänger 4 Andreas Schmidt quittiert den erfolgreichen Empfang der MM anschliessend Nachricht 15 (M-Acknowledge. ind).



  Mit der darin enthaltenen Transaction-ID ist am MMS Relay 3 die Zuordnung zu der gesendeten MM entsprechend dem Informationssignal M-Acknowledge. ind von Figur 13 möglich.



  Als letzter Schritt der Transaktion wird schliesslich die Nachricht 16 (M-Delivery. ind) entsprechend Figur   14 vom    MMS Relay 3 an den Versender 2 übermittelt : Der zweite Empfänger Josef Laumen hingegen entscheidet sich dafür, nur den Textteil der Nachricht 14 zu laden. Dazu setzt er in die Nachricht 13 (WSP GET. req) die   Content-ID    des Textteils ein :"000714.1412.1markus. trauberg". Er erhält diesen Textteil mit der Nachricht 14 (M-Retrieve.   conf),    die gegen  über der Version an Andreas Schmidt deutlich verändert ist und deren Inhalt in Figur 15 exemplarisch wiedergegeben ist.



  Die Nachricht 14 wurde gegenüber ihrer kompletten Version, wie sie an Andreas Schmidt geschickt wurde, um die nicht erwünschten Datensätze 7 reduziert. Ausserdem wurde das Feld   nEntries    entsprechend angepasst.



  Die Nachricht 15 (M-Acknowledge. ind), die in Figur 16 dargestellt ist, entspricht fast komplett der Version an Andreas Schmidt, enthält aber eine eigene Transaction-ID : Als letzter Schritt erfolgt wieder die Benachrichtigung des Versenders 2 über den Status der Zustellung. Sie enthält den Status der partiellen Zustellung ("Partly-retrieved") und ist inhaltlich in Figur 17 dargestellt.



  Neben den vorstehend beschriebenen Möglichkeiten zur detaillierten Benachrichtigung von Empfängern von Multimedia Nachrichten (MMs) im Multimedia Messaging Service (MMS) besteht eine weitere, zweckmässige Option, die Vorteile gegenüber den bereits vorgestellten Varianten hat. Diese vorteilhafte Option wird nachfolgend beschrieben.



  Kern dieser Modifikation ist die Realisierung der Idee, den jeweiligen Empfänger detailliert über den Inhalt der jeweiligen MM zu informieren, wobei lediglich ein einziges, neu definiertes Header-Feld genutzt wird, für das neue Parameter eingeführt werden. Das neue Header-Feld enthält dabei alle Parameter, d. h. Informationen über ein zu beschreibendes Element der MM. Unter Element bzw. Datensatz einer MM wird in dieser Erfindungsmeldung ein einzelner Bestandteil einer MM verstanden, der insbesondere durch seinen Typ (z. B. Standbild) und sein Format (z. B. JPEG (= joint photographics expert group)) definiert ist. 



  Die folgende Liste enthält die bereits zu den vorausgehenden Varianten vorgeschlagenen Informationen, die dem Empfänger einer MM optional in einer Empfängerbenachrichtigung im MMS (M-Nind ; in WAP :   M-Notification. ind)    zur Verfügung gestellt werden können. Dazu gehören :

   "die Anzahl der enthaltenen Elemente der MM (auch implizit durch die Beschreibung der einzelnen Elemente der MM),       die Grösse (in Octets) eines Elements,       der Typ und das Format eines Elements,       die Content ID (Content IDentification) eines Elements
Name bzw.

     Bezeichner des    jeweiligen Headerfeldes des je weiligen Identifikationssignals),       der Name eines Elements,       die Verbindung eines Elements zu einem oder mehreren ande ren Elementen der MM,       die Verbindung der gesamten MM oder eines/mehrerer Elemen te zu einer oder mehreren URLs/URIs (uniform resource    link/identifier)    ausserhalb der MM und bei einem solchen externen Bezug optional die Grösse der zu ladenden Objekte des/der aufgelösten externen Bezüge.



  Die Definition der entsprechenden Header-Felder zur optionalen Erweiterug der MMS Empfängerbenachrichtigung (M-Nind; in WAP: M-Notification.ind) und gegebenenfalls auch der MMS Sendeanfrage (M-Sreq ; in WAP :   M-Send.    req) und der MMS Zustellnachricht (M-Rconf ; in WAP : M-Retrieve. conf) sind im beim nachfolgenden Ausführungsbeispiel beschrieben.



  Eine MM besteht grundsätzlich-wie in den vorausgehenden Ausführungsbeispielen aufgezeigt-aus einem Header und abhängig vom Typ der Nachricht ggf. zusätzlich aus einem Datenteil (WAP : Body). Der Header   umfasst    allgemeine Informationen der Nachricht und setzt sich aus ein oder mehreren, definierten Header-Feldern zusammen. Der etwaige Datenteil der Messa ge enthält ein oder mehrere Elemente beliebigen Typs, die in beliebiger Reihenfolge dem Header folgen. Falls eine Präsentationsbeschreibung im Datenteil enthalten ist, soll z. B. in einer WAP-Nachricht zu Beginn des Datenteils ein so genannter Start-Parameter auf diese Präsentationsbeschreibung zweckmä ssigerweise hinweisen.



  Figur 1 zeigt dabei in einem Nachrichtenflussdiagram den prinzipiellen Ablauf einer   Nachrichtenübermittlung    von der Nutzerapplikation des sendenden Nutzers 2 (User Agent A = M UAA) über die MMS Verbindungseinheit 3 (MMS Relay=M-SR) zur Nutzerapplikation des empfangenden Nutzers 4 (User Agent B   -(M-UA¯B)).   



  Die je nach Nachrichten-Typ möglichen bzw. erforderlichen Header-Felder in WAP sind für die hier betrachteten Nachrichten-Typen in den Tabellen entsprechend der Figuren 21 A/21B und 22 dargestellt. Diese wurden WAP-209-MMSEncapsulation, Release 2000 ; Wireless Application Protocol ; WAP Multimedia Messaging Service ; Message Encapsulation ; MMS Proposed SCD 1.0 entnommen. Nach WAP-203-WSP, Version 4-May-2000 ; Wireless Application Protocol, Wireless Session Protocol Specification ; Chapter 8.4 :"Header Encoding"besteht jedes Header-Feld aus einem Feld-Namen, gefolgt von einem Feld-Wert, der aus mindestens einem Octet besteht. Die Zuweisung von hexadezimalen Werten zu den Feld-Namen der WAP Messages ist in der Tabelle entsprechend Figur 20 aufgeführt.



  Diese weitere Option beruht auf der zu den vorausgehenden Ausführungsbeispielen eingeführten Definition eines Header Feldes zur eindeutigen Kennzeichnung eines Elementes einer MM, dem Header-Feld   X-Mms-Content-ID,    das im Body der MM dem Element der MM als Header-Feld voransteht und das Element eindeutig kennzeichnet. 



  Abweichend von den vorausgegangenen Vorschlägen basiert die Beschreibung eines Elementes der MM hier auf einem einzigen Header-Feld X-Mms-Content-ID, das in den Header der MM zur Benachrichtigung des Empfängers integriert wird, und das die nötigen Informationen (für die Benachrichtigung des Empfängers z. B. über Anzahl, Typ, Grösse, Format der für ihn bereitgehaltenen Datensätze der MM) durch einen oder mehrere Parameter aus der folgenden Liste beschreibt.



         Name beschreibt den Namen des MM-Elements ;       Type beschreibt den Typ und das Format des MM-Elements ;
Size beschreibt die Grösse des MM-Elements in Bytes ;       External-Link zeigt an, dass das Element eine Verknüpfung auf Inhalte ausserhalb der MM enthält ;
External-Link-Size gibt an, welches Datenvolumen zum Auf lösen der externen Referenz zusätzlich heruntergladen wer den muss ;         Rel a t ed-ID    gibt an, welches Element der MM mit dem Ele ment in Bezug steht und bei einem partiellen Herunteralden der MM ebenfalls geladen werden sollte (Mehrfachverwendung möglich.



  Allgemein ausgedrückt wird also jetzt das Identifikationssignal für einen oder mehrere zugeordnete Datensätze in einem einzigen, zusätzlichen Headerfeld vom jeweiligen Sender wie z. B. einem ersten Mobilfunkgerät und/oder zuständigen Server in einer MMS Empfängerbenachrichtigung zum Empfänger wie z. B. zu einem zweiten Mobilfunkgerät codiert übertragen. Dadurch sind Reihenfolgen-und Zuordnungsprobleme, wie sie etwaig bei der Verwendung mehrerer   Headerfelder    zwischen diesen selbst und/oder den zugeordneten Datensätzen auftreten könnten, von vornherein vermieden. 



  Weiterhin sollen zusätzlich zu den bereits zu den vorausgehenden Ausführungsbeispielen beschriebenen auch folgende Informationen als Parameter codiert werden können :
1. Original-Type beschreibt den Typ des MM-Elements vor der Transcodierung durch die MMS Verbindungseinheit (M
SR) ;
2. Original-Size beschreibt die Grösse des MM-Elements vor der Transcodierung durch die MMS Verbindungseinheit (M
SR) in Bytes ; Durch die Zusammenfassung aller für ein MM-Element relevanten Informationen in einem einzigen Header-Feld, kann auf eine Einhaltung der Header-Reihenfolge, wie sie bei den vorhergehenden Ausführungsbeispielen vorausgesetzt wird, verzichtet werden.



  In Figur 18 ist das zum Zwecke der detaillierten Benachrichtigung des Empfängers einer MM gemäss WAP neu eingeführte, einzige Header-Feld einschliesslich der Codierung von Feld Name und Feld-Wert aufgeführt. Die Tabelle entsprechend Figur 20 enthält die Zuweisung von hexadezimalen Werten zu den Feld-Namen. Die Tabelle entsprechend Figur 19 enthält die Zuweisung von hexadezimalen Werten zu den Parameternamen und weiterhin die zur Codierung der Parameterwerte zu verwendenden Typen. Die um die entsprechenden Header-Felder ergänzten WAP Nachrichten sind in den Tabellen 21A/21B und 22 aufgelistet. Alle Veränderungen und Ergänzungen in den Tabellen zum heutigen Stand der Technik sind dabei eingerahmt.



  Ausführungsbeispiel : Im nun folgenden Ausführungsbeispiel, das auf der Definition der beschriebenen Nachrichten durch das WAP-Forum basiert, wird detailliert auf die in den WAP Nachrichten benutzten Header-Felder eingegangen. Dabei wird beispielhaft folgendes Szenario angenommen :   M-UA¯A    (Markus Trauberg) verschickt eine  Multimedia Message MMA bestehend aus einem Text, einem MP3 Audio, einem JPEG-Bild, einem MPEG-4-Video und einer SMIL (synchronized multimedia integration language) Präsentationsbeschreibung an einen Empfänger   M-UA B    (Andreas Schmidt). Zur komfortablen und differenzierten Nutzung durch den Empfänger werden Beschreibungen der Elemente der MM dem Header der MM gemäss dieser Erfindungsmeldung zugefügt.

   Die Daten werden in den Nachrichten   M-Sreq    und   M-Nind    an den Empfänger übertragen. Empfänger Andreas Schmidt lädt die komplette MM auf sein Endgerät. Die folgenden Nachrichten werden zwischen den Einheiten übertragen.



  MMA wird an einen Adressaten verschickt. Deren Inhalt ist in Figur 23 beispielhaft abgebildet.



  In der Message sind im Header die zusätzlichen Informationsblöcke, d. h. allgemein ausgedrückt die ein oder mehreren Parameter über die MM-Elemente codiert. Darin werden auch die Beziehungen zwischen den Elementen der MM beschrieben : So enthält die Beschreibung der Präsentationsbeschreibung (*. smil) Verweise auf die darin referenzierten Elemente image/jpeg, audio/mp3 und video/mpeg4 in Form der entsprechenden Content-IDs.



  Die Beschreibung des Textes enthält die Information, dass ein Verweis auf ein externes Objekt enthalten ist, das 8245 Byte Daten umfasst.



  Nach dem Stand der Technik wird die Sendeanfrage (WAP   : M-      Send. req)    des MMS User Agent A mit einer Nachricht (in WAP : M Send. conf) vom M-SR quittiert. Im Rahmen dieser EM wird diese Message nicht modifiziert und daher hier nicht aufgeführt.



  M-Nind (M-SR- >    M-UA-B) :     Im MMS (multimedia services) entsprechend 3G TS 23.140 version 3.0.1, Release 1999 ; Third Generation Partnership Project ; Technical Specification Group Terminals ; Multimedia Messaging Service (MMS) ; Functional Description ; Stage 2 und WAP-209 MMSEncapsulation, Release 2000 ; Wireless Application Protocol ; WAP Multimedia Messaging Service ; Message Encapsulation ; MMS Proposed SCD 1.0 ist vorgesehen, einen Empfänger einer MM über neue Nachrichten, die für ihn vorliegen, zu informieren.



  Die Nachricht   M-Nind    (in WAP :   M-Notification. ind)    dient der Benachrichtigung der Adressaten über zum Herunterladen bereitliegende MMs. Ihr Inhalt ist beispielhaft in Figur 24 abgebildet. Folglich existiert in diesem Beispiel eine Empfängerbenachrichtigung an den Empfänger Andreas Schmidt. Die Information über den Speicherplatz der MMA steht dabei in dem Feld X-Mms-Content-Zocation.



  Neben den üblichen Feldern zu Beginn der Nachricht können nun alle beschreibenden, nach dieser Variante neuen Elemente der Nachricht   M-Sreg    in die Nachricht M-Nind übernommen werden.



  Zusätzlich werden durch die M-SR noch die Informationen Type und Size aus den Informationen des Body der Nachricht   M-Sreg    generiert bzw. wird das enthaltene Bild vom Typ image/jpeg in den Typ image/bmp konvertiert, da das Endgerät JPEG-Bilder nicht anzeigen kann. Die entsprechenden Informationen über den ursprünglichen Typ (Original-Type) und die ursprüngliche Dateigrösse (Original-Size) sind im entsprechenden Header-Feld ergänzt worden. Der Empfänger kennt nach Erhalt der detailed Notification sowohl die Adresse der MM (wie bisher) als auch die Zusammensetzung aus den einzelnen Elementen und deren   Content-IDs.    Ein Zugriff ist daher auch separat auf einzelne Elemente der MM möglich.



  Der korrekte Empfang der Benachrichtigung kann anschliessend von dem Empfänger der MMA mit der Nachricht   M-NRind    bestätigt werden, indem die entsprechende Transaction-ID   der M-Nind zu-    sammen mit einer Statusmeldung zurück zum MMS Relay geschickt wird. Dann wird das Herunterladen der MMA durch den Befehl   W-      Greq    veranlasst. Die MM wird darauf vom M-SR in der Nachricht   M-Rconf      zum MM-UA    A gesendet.



  Im Folgenden wird die Nachricht von dem Empfänger Andreas Schmidt komplett auf sein Endgerät heruntergeladen. Die Nachricht   M-Rconf    wird beispielsweise wie in Figur 25 codiert.



  Der Empfänger M-UA B quittiert den erfolgreichen Empfang der MMA anschliessend gemäss Stand der Technik mit der Nachricht Zusammenfassend betrachtet wird somit ein Verfahren zur Übertragung zusätzlicher Informationen zur detaillierten Beschreibung einer Multimedianachricht und der darin enthaltenen MM-Elemente im Multimedia-Messaging-Service (MMS) bereitgestellt. Diese Informationen werden insbesondere mit einem einzigen oder mehreren zusätzlichen Header-Feldern in der jeweiligen MMS Empfängerbenachrichtigung vom jeweilig zuständigen Server wie z. B. M-SR zum empfangenden User Agent übertragen. Die nötigen Informationen werden vorzugsweise vom sendenden User Agent generiert und in der MMS Sendeanfrage von diesem codiert zum zuständigen Server übertragen.

   Zusätzlich oder unabhängig hiervon können die nötigen Informationen auch vom zuständigen Vermittlungs-/Bereitstellungs-Server aus dem Datenteil der jeweilig zu   versendenden    MM extrahiert und dem Empfangenden User Agent in der MMS Empfängerbenachrichtigung codiert übertragen werden. Vorzugsweise kann dem empfangenden User Agent eine oder mehrere der folgenden Informationen über den Inhalt oder einzelne Elemente des Inhalts der zur Zustellung z. B. im zuständigen Server bereitliegenden Nachricht mitgeteilt werden :        Anzahl der in der MM enthaltenen Elemente        Grösse des Elements der MM (in Octets)  'Typ und Format des Elements der MM 
Kennzeichnung des Elements (Content-ID bzw.

   URI)
Name des Elements die Verbindung eines oder mehrerer Elemente zu einem o der mehreren anderen Elementen innerhalb der MM (z. B. zwischen Präsentationsbeschreibung und Präsentations element) die Verbindung eines oder mehrerer Elemente zu Inhalten beliebiger Natur ausserhalb der MM (z. B. zu   HTML/WML-   
Seiten) die jeweilige Grösse der verknüpften externen Elemente, die zusätzlich zur MM selbst geladen werden können (in
Octets) der Typ und das Format des Elements vor einer Transco dierung durch die M-SR die Grösse des Elements vor einer Transcodierung durch die M-SR (in Octets) Insbesondere bildet dabei die Kennzeichnung des Elements (Content-ID bzw. URI) den ersten Eintrag im einzigen Headerfeld oder den Inhalt des ersten Headerfeldes bei mehreren benutzten Headerfeldern pro Element bzw. Datensatz.



  Bevorzugt kann die Beschreibung eines Elements einer MM jeweils mit einem einzigen Feld ausgeführt werden, das per eindeutiger Identifikationsnummer bzw. Bezeichner auf das Element im Datenteil der Multimedianachricht verweist, und das die weiteren Informationen als Parameter auch noch und nicht in separaten Headerfeldern enthält.



  Der Empfänger einer MM kann vorzugsweise, nachdem er eine detaillierte Benachrichtigung erhalten hat, auch nur einzelne Elemente der MM auf sein Endgerät laden. Genauso ist es ggf. möglich, dass die nach dieser Erfindung zusätzlichen Informa tionen der MMS Empfängerbenachrichtigung   (M-Nind)    auch im Header der MMS Zustellnachricht (M-Rconf) ergänzt werden.



  Vorzugsweise kann das zusätzliche Header-Felder-wenn nur ein einziges Headerfeld pro Datensatz verwendet wird-in WAP wie folgt codiert werden : Codierung des Feld-Namens X-Mms-Content-ID im Wertebereich zwischen   00X00    bis   OX7F,    insbesondere als   0x19    gemäss der Tabelle nach Figur 20.



  Codierung des Feld-Wertes von X-Mms-Content-ID gemäss Figur 9.



  Die Informationen als Parameter in diesem einzigen Header Feld können insbesondere nach der Tabelle von Figur 19 codiert werden.



  Hintergrundangaben zu WAP und MMS, insbesondere zu deren einschlägiger Normenliteratur finden sich beispielsweise an folgenden Stellen :   [1]    3G TS 23.140 version 3.0.1, Release 1999 ; Third Ge neration Partnership Project ; Technical Specifica tion Group Terminals ; Multimedia Messaging Service  (MMS) ; Functional Description ; Stage 2   [2]    WAP-209-MMSEncapsulation, Release 2000 ; Wireless
Application Protocol ; WAP Multimedia Messaging Ser vice ; Message Encapsulation ; MMS Proposed SCD 1.0 [3] WAP-203-WSP, Version 4-May-2000 ; Wireless Applica tion Protocol, Wireless Session Protocol Specifica tion ; Chapter 8.4 :"Header Encoding".



     [4]    WAP-Forum   :" WAP    MMS Interworking with Internet E mail ;   WAP-207-MmsInetInterworking" ;    Draft Version
01-Jun-2000.



  [5] 3G TS 22.140 v. 4.0.1 (Juli   2000) :    3rd Generation
Partnership Project ; Technical Specification Group
Services and System Aspects ; Service Aspects ; Stage
1 Multimedia Messaging Service. 



     [6]    RFC822 :"Standard for the Format of ARPA Internet
Text Messages", Crocker D., August 1982. URL :    ftp ://ftp.    isi. edu/in-notes/rfc822. txt.



     [7]    RFC2045 :"Multipurpose Internet Mail Extensions  (MIME) Part One : Format of Internet Message Bo dies", Freed N., November 1996.



   URL : ftp ://ftp. isi. edu/in-notes/rfc2045. txt.



     [8]    RFC2046 :"Multipurpose Internet Mail Extensions  (MIME) Part Two : Media Types", Freed N., November
1996. URL : ftp ://ftp. isi.   edu/in-notes/rfc2046.    txt.



     [9]    RFC2047 :"MIME (Multipurpose Internet Mail Extensi ons) Part Three : Message Header Extensions for Non
ASCII Text", Moore   K.,    November 1996. URL : ftp ://ftp. isi. edu/in-notes/rfc2047. txt.



  Im Rahmen der Erfindungsbeschreibung ist der einfacheren Schreibweise halber im Kontext auf folgende, gängigen Akronyme Bezug genommen wurden, die zum besseren Verständnis mit ihrer vollständigen Bedeutung nachfolgend aufgelistet sind : GSM Global System for Mobile Communication MM Multimedianachricht (Multimedia Message) MMS Multimedia Messaging Service SMS Short Message Service UMTS Universal Mobile Telecommunication System WAP Wireless Application Protocol WSP Wireless Session Protocol MMS spezifische Abkürzungen : M-UA MMS Nutzer Applikation M-SR MMS Verbindungseinheit M-Sreq MMS Sendeanfrage M-Sconf MMS Sendebestätigung M-Nind MMS Empfängerbenachrichtigung M-NRind MMS Empfängerbenachrichtigungsbestätigung  W-Greq MMS Zustellanfrage M-Rconf MMS Zustellnachricht M-Aind MMS   Zustellungsbestätigung    M-Dind MMS Zustellstatusbenachrichtigung

Claims

Patentansprüche
1. Verfahren zur Datenübertragung in einem Mobilfunknetz, insbesondere von Text- und/oder Bilddaten mit und ohne Ton, d a d u r c h g e k e n n z e i c h n e t , daß den Daten zumindest ein Identifikationssignal für einen Datensatz oder mehrere Datensätze zugeordnet und dieses oder diese Identifikationssignal (e) an den Empfänger der Daten ü- bertragen wird oder werden.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t , daß das oder die Identifikationssignal (e) vor Übertragung des oder der durch diese (s) charakterisierten Datensatzes oder Datensätze übertragen wird und optisch oder akustisch anzeigbar ist.
3. Verfahren nach Anspruch 2, d a d u r c h- g e k e n n z e i c h n e t , daß der Empfänger des oder der Identifikationssignal (e) auswählen kann, ob er die Übertragung der durch diese charakterisierten Daten ganz oder teilweise zuläßt.
4. Verfahren nach einem der Ansprüche 1 bis 3, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über die Art eines Datensatzes, insbesondere dessen Datenformat, enthält.
5. Verfahren nach einem der Ansprüche 1 bis4, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über den Namen eines Datensatzes enthält.
6. Verfahren nach einem der Ansprüche 1 bis 5, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über den Inhalt ei¬ nes Datensatzes enthält.
7. Verfahren nach einem der Ansprüche 1 bis 6, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über die Größe ei¬ nes Datensatzes enthält.
8. Verfahren nach einem der Ansprüche 1 bis 7, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über die Anzahl von Datensätzen innerhalb von übertragenen Daten enthält.
9. Verfahren nach einem der Ansprüche 1 bis 8, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über eine Verknüpfung mit zumindest einem Datensatz innerhalb der gesendeten Daten enthält.
10. Verfahren nach einem der Ansprüche 1 bis 9, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über eine Verknüpfung mit zumindest einem Datensatz außerhalb der gesendeten Daten enthält.
11. Verfahren nach einem der Ansprüche 9 oder 10, d a d u r c h g e k e n n z e i c h n e t , daß das Identifikationssignal Information über die Größe desjenigen Datensatzes oder derjenigen Datensätze, mit denen ein übertragener Datensatz verknüpft ist, enthält.
12. Verfahren nach einem der Ansprüche 1 bis 11, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifikationssignal Information über die Kennzeich- nung eines Datensatzes enthält.
13. Verfahren nach einem der Ansprüche 1 bis 12, d a d u r c h g e k e n n z e i c h n e t , daß das Verfahren im Mobile Messaging Service (MMS) angewandt wird und die übertragenen Daten als Mobile Messages (MM) aus- gebildet sind.
14. Verfahren nach einem der Ansprüche 1 bis 13, d a d u r c h g e k e n n z e i c h n e t , daß das Verfahren im Übertragungsstandard UMTS (Universal Mo- bile Telecommunication System) , im GSM (Global System for mo¬ bile communication) , im GPRS (General packet radio service) und/oder im EDGE (Enhanced Data Rates for GSM enviroments angewandt wird.
15. Verfahren nach einem der Ansprüche 1 bis 14, d a d u r c h g e k e n n z e i c h n e t , daß das oder die Identifikationssignal (e) einem oder mehreren Header-Feldern der übertragenen Daten zugeordnet wird oder werden.
16. Verfahren nach einem der Ansprüche 1 bis 15, d a d u r c h g e k e n n z e i c h n e t , daß ein Identifkationssignal in zumindest einem zusätzlichen Header-Feld abgelegt wird.
17. Verfahren nach einem der Ansprüche 1 bis 16, d a d u r c h g e k e n n z e i c h n e t , daß das oder die Identifizierungssignal (e) zumindest teilweise vom Versender generiert und bei Übermittlung einer Multi- media message vom Versender (MMS user agent A) zum Service Provider (MMS relay) übersandt werden.
18. Verfahren nach Anspruch 17, d a d u r c h g e k e n n z e i c h n e t , daß der Versender eines oder mehrere der Header-Felder, X- MMS-Content-ID, X-MMS-Content-Name, X-MMS-Content-Type, X- MMS-External-Link-Flag, X-MMS-External-Link-Size' generiert.
19. Verfahren nach einem der Ansprüche 1 bis 18, d a d u r c h g e k e n n z e i c h n e t , daß das oder die Identifizierungssignal (e) zumindest teilweise aus dem vom Service Provider (MMS Relay) empfangenen Da¬ tensatz selbständig ermittelt wird oder werden
20. Verfahren nach Anspruch 19, d a d u r c h g e k e n n z e i c h n e t , daß das MMS Relay eines oder mehrere der Header-Felder X-MMS- Content-ID, X-MMS-Content-Size, X-MMS-Content-Type generiert oder aktualisiert.
21. Verfahren nach einem der Ansprüche 1 bis 20, d a d u r c h g e k e n n z e i c h n e t , daß das oder die Identifizierungssignal (e) jeweils in der Benachrichtigung an den Empfänger (MMS user agent B) durch das MMS Relay des Service Providers über das Vorhandensein eines oder mehrerer neuen Datensätze einer Multimedia message übertragen wird.
22. Verfahren nach einem der Ansprüche 1 bis 21, d a d u r c h g e k e n n z e i c h n e t , daß dem Telekommunikationsgerät des Empfängers eine Wahleinrichtung zugeordnet ist, mittels der dieser nach zumindest teilweiser Kenntnisnahme des oder der Identifikationssignal (e) eine Bestätigung der Empfangsbereitschaft für den Da- tensatz geben kann, und die Übertragung zum Empfänger erst nach Auslösung der Wahleinrichtung ermöglicht ist.
23. Verfahren nach Anspruch 22, d a d u r c h g e k e n n z e i c h n e t , daß sich die Empfangsbereitschaft nur auf einen Teil der Da- ten bezieht und die Übertragung nur dieses Teils des Daten¬ satzes freigeschaltet wird.
24. Verfahren nach einem der Ansprüche 1 bis 23, d a d u r c h g e k e n n z e i c h n e t , daß das oder die zusätzlichen Identifizierungssignal (e) der
Benachrichtigung über bereitstehende Daten (M-
Notification. ind) und der eigentlichen Datensendung (M-
Retrieve.conf) zugefügt werden.
25. Verfahren nach einem der Ansprüche 1 bis 24, d a d u r c h g e k e n n z e i c h n e t , daß die Bereitschaft zum zumindest teilweisen Empfang der bereitstehenden Daten der vom Empfänger an den Provider gesand- ten Nachricht WSP Get.req zugeordnet ist.
26. Mobiltelekommunikationsgerät (5; 6) zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 25, d a d u r c h g e k e n n z e i c h n e t , daß dem Mobiltelekommunikationsgerät (5; 6) ein Auswahlschalter (25) zur völligen oder teilweisen Bestätigung oder Ablehnung der Empfangsbereitschaft für einen oder mehrere identifizierten Datensatz oder Datensätze (7) zugeordnet ist.
27. Mobiltelekommunikationsgerät nach Anspruch 26, d a d u r c h g e k e n n z e i c h n e t , daß dem Mobiltelekommunikationsgerät (5; 6) ein Anzeigemittel (24) zur optischen oder akustischen Anzeige des oder der I- dentifizierungssignale eines oder mehrerer Datensätze (7) zu- geordnet ist.
28. Mobiltelekommunikationsgerät nach einem der Ansprüche 26 oder 27, d a d u r c h g e k e n n z e i c h n e t , daß der Auswahlschalter (25) softwareseitig implementiert und über ein Eingabemittel anwählbar ist.
29. Mobiltelekommunikationsgerät (5;6), d a d u r c h g e k e n n z e i c h n e t , daß diesem eine Software zur Belegung von Header-Feldern (17;18;19;20;21;22;23) von Datensendungen mit zumindest einem Identifikationssignal zugeordnet ist.
30. Computerprogrammerzeugnis, das ein computerlesbares
Speichermedium umfaßt, auf dem ein Programm gespeichert ist, das es einem Computer ermöglicht, nachdem es in den Speicher des Computers geladen worden ist, innerhalb von Datenübertragung in einem Mobilfunknetz den zu übertragenden Daten zumin- dest ein Identifizierungssignal mit charakterisierenden Angaben zu einem Datensatz (7) oder mehreren Datensätzen (7) an den jeweiligen Empfänger (4) weiterzuleiten.
31. Computerprogrammerzeugnis nach Anspruch 30, d a d u r c h g e k e n n z e i c h n e t , daß dieses ein Verfahren nach einem der Ansprüche 1 bis 25 bei Datenversand in einem Mobilfunknetz durchführt.
32. Funkkommunikationssystem, bei dem mindestens eine Kompo- nente nach einem Verfahren der vorhergehenden Ansprüche arbeitet.
PCT/EP2001/014617 2001-01-18 2001-12-12 Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz WO2002058359A1 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP01101057.6 2001-01-18
EP01101057 2001-01-18
EP01102229.0 2001-01-31
EP01102229 2001-01-31
EP01107278 2001-03-23
EP01107278.2 2001-03-23

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2002558717A JP4358511B2 (ja) 2001-01-18 2001-12-12 移動無線ネットワークにおけるデータ伝送のための方法および移動通信装置
US10466749 US8099081B2 (en) 2001-01-18 2001-12-12 Method and mobile telecommunications device for transmitting data in a mobile radio network
EP20010273297 EP1352500B1 (de) 2001-01-18 2001-12-12 Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz

Publications (1)

Publication Number Publication Date
WO2002058359A1 true true WO2002058359A1 (de) 2002-07-25

Family

ID=27224113

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2001/014617 WO2002058359A1 (de) 2001-01-18 2001-12-12 Verfahren und mobiltelekommunikationsgerät zur datenübertragung in einem mobilfunknetz

Country Status (3)

Country Link
US (1) US8099081B2 (de)
JP (2) JP4358511B2 (de)
WO (1) WO2002058359A1 (de)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1303090A2 (de) 2001-10-09 2003-04-16 Siemens Aktiengesellschaft Verfahren zur Übertragung von Daten
WO2003105425A1 (de) * 2002-06-07 2003-12-18 Siemens Aktiengesellschaft Übertragung vno mms-nachrichten mit konvertierung von datai-typen und/oder -formaten
DE10325889A1 (de) * 2003-06-06 2004-12-23 Siemens Ag Verfahren zum Übertragen von Nachrichten
EP1531639A2 (de) * 2003-11-12 2005-05-18 Vodafone Holding GmbH Verfahren zur Übertragung von Daten auf ein mobiles Endgerät in Mobilfunknetzen
US7010790B2 (en) * 2002-11-20 2006-03-07 Cegetel Modular method and device for the tracing of a multimedia message through a telecommunications network

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10230897A1 (de) * 2002-07-09 2004-01-29 Siemens Ag Nachrichtenübertragungsverfahren und -system
EP1387539A1 (de) * 2002-08-02 2004-02-04 Siemens Aktiengesellschaft Verfahren und System zum Blockieren von unerwünschten Nachrichten
EP1424860A3 (de) * 2002-11-05 2006-01-25 Siemens Aktiengesellschaft Verfahren zur Steuerung eines Multimedia-Nachrichtendienstes zwischen einem Telekommunikationsgerät und einem Telekommunikationsnetz, übereinstimmende Chipkarte und Telekommunikationsgerät
US20040176114A1 (en) * 2003-03-06 2004-09-09 Northcutt John W. Multimedia and text messaging with speech-to-text assistance
KR100517988B1 (ko) * 2003-04-16 2005-09-30 엘지전자 주식회사 Gsm 단말기의 문자메시지 수신 방법
US7783729B1 (en) 2004-03-19 2010-08-24 Single Touch Interactive, Inc. Transmitting mobile device data
US20060031369A1 (en) * 2004-07-01 2006-02-09 Marc Caron Method, system, and edge multimedia messaging service (MMS) relay/server for multi-staged MMS
KR101048432B1 (ko) * 2004-10-05 2011-07-11 엘지전자 주식회사 이동통신 단말기의 파일을 이용한 메시지 전송 방법
EP1810460B1 (de) * 2004-11-02 2009-07-22 Nokia Corporation Informieren einer empfängereinrichtung über nachrichteninhaltseigenschaften
KR101155335B1 (ko) * 2005-01-07 2012-06-11 엘지전자 주식회사 이동통신 단말기의 멀티미디어 메시지 동작방법
KR100764787B1 (ko) * 2005-09-14 2007-10-11 엘지전자 주식회사 액티브 콘텐츠를 송수신하기 위한 방법 및 단말기
US8050660B2 (en) * 2006-03-07 2011-11-01 Motorola Mobility, Inc. Apparatus and method for handling messaging service message adaptation
WO2009116053A3 (en) * 2008-03-18 2009-12-30 Nowpos Online Services Pvt. Ltd. An invention for dispatch of opacity-controlled 'always-on-top' formats on telecommunication devices
EP2175378A1 (de) * 2008-10-13 2010-04-14 Vodafone Holding GmbH Bereitstellung von auf einer Speicherkarte gespeicherten Daten für eine Benutzervorrichtung
US20120149339A1 (en) * 2010-12-10 2012-06-14 MobileIron, Inc. Archiving Text Messages
CN102164353B (zh) 2011-04-13 2013-08-28 青岛海信移动通信技术股份有限公司 一种解析mms信息的方法和设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000064110A1 (en) * 1999-04-19 2000-10-26 Nokia Networks Oy Method for delivering messages

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07175710A (ja) * 1993-12-20 1995-07-14 Canon Inc データ管理方法及び装置
WO1997022936A1 (en) * 1995-12-19 1997-06-26 Motorola Inc. Method and apparatus for rate governing communications
US5724412A (en) * 1996-10-07 1998-03-03 U S West, Inc. Method and system for displaying internet identification on customer premises equipment
US5850511A (en) * 1996-10-28 1998-12-15 Hewlett-Packard Company Computer implemented methods and apparatus for testing a telecommunications management network (TMN) agent
US5987100A (en) * 1997-04-23 1999-11-16 Northern Telecom Limited Universal mailbox
FI108982B (fi) 1998-06-15 2002-04-30 Nokia Corp Sanomapalvelu langattomassa tietoliikennejärjestelmässä
US20010012286A1 (en) * 1999-01-29 2001-08-09 Emmanuel L. Huna Method and apparatus for computer alert of device independent messages
US6647409B1 (en) * 1999-07-13 2003-11-11 Microsoft Corporation Maintaining a sliding view of server based data on a handheld personal computer
US6865609B1 (en) * 1999-08-17 2005-03-08 Sharewave, Inc. Multimedia extensions for wireless local area network
FI111314B (fi) 1999-11-05 2003-06-30 Nokia Corp Multimediasanomanvälityspalvelu
FI111780B (fi) * 1999-12-23 2003-09-15 Nokia Corp Sanomanvälityspalvelu
US7039678B1 (en) * 2000-09-07 2006-05-02 Axis Mobile, Ltd. E-mail proxy
US7031968B2 (en) * 2000-12-07 2006-04-18 Prev-U Israel Ltd. Method and apparatus for providing web site preview information

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000064110A1 (en) * 1999-04-19 2000-10-26 Nokia Networks Oy Method for delivering messages

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
KERVELLA B ET AL: "MHEGAM - A MULTIMEDIA MESSAGING SYSTEM", IEEE MULTIMEDIA,US,IEEE COMPUTER SOCIETY, vol. 4, no. 4, 1 October 1997 (1997-10-01), pages 22 - 29, XP000726939, ISSN: 1070-986X *
MOELLER E ET AL: "The BERKOM multimedia-mail teleservice", COMPUTER COMMUNICATIONS,NL,ELSEVIER SCIENCE PUBLISHERS BV, AMSTERDAM, vol. 18, no. 2, 1 February 1995 (1995-02-01), pages 89 - 102, XP004032505, ISSN: 0140-3664 *
N. BORENSTEIN, N. FREED: "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", NETWORK WORKING GROUP, RFC 1521, XP002170350 *
N. BORENSTEIN; N. FREED: "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", NETWORK WORKING GROUP, RFC 1521

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1303090A2 (de) 2001-10-09 2003-04-16 Siemens Aktiengesellschaft Verfahren zur Übertragung von Daten
EP1303090B1 (de) * 2001-10-09 2016-03-09 Siemens Aktiengesellschaft Verfahren zur Übertragung von Daten
WO2003105425A1 (de) * 2002-06-07 2003-12-18 Siemens Aktiengesellschaft Übertragung vno mms-nachrichten mit konvertierung von datai-typen und/oder -formaten
US8731097B2 (en) 2002-06-07 2014-05-20 Siemens Aktiengesellschaft Transmission of mms messages with the conversion of data types and/or data formats
US7010790B2 (en) * 2002-11-20 2006-03-07 Cegetel Modular method and device for the tracing of a multimedia message through a telecommunications network
US8924578B2 (en) 2003-06-06 2014-12-30 Siemens Aktiengesellschaft Method for transmitting messages in an MMS-based communication system
DE10325889A1 (de) * 2003-06-06 2004-12-23 Siemens Ag Verfahren zum Übertragen von Nachrichten
EP1531639A2 (de) * 2003-11-12 2005-05-18 Vodafone Holding GmbH Verfahren zur Übertragung von Daten auf ein mobiles Endgerät in Mobilfunknetzen
EP1531639A3 (de) * 2003-11-12 2007-11-21 Vodafone Holding GmbH Verfahren zur Übertragung von Daten auf ein mobiles Endgerät in Mobilfunknetzen

Also Published As

Publication number Publication date Type
US20040097248A1 (en) 2004-05-20 application
JP2004517587A (ja) 2004-06-10 application
JP5006864B2 (ja) 2012-08-22 grant
US8099081B2 (en) 2012-01-17 grant
JP2009105931A (ja) 2009-05-14 application
JP4358511B2 (ja) 2009-11-04 grant

Similar Documents

Publication Publication Date Title
Le Bodic Mobile messaging technologies and services: SMS, EMS and MMS
US6865191B1 (en) System and method for sending multimedia attachments to text messages in radiocommunication systems
US7200680B2 (en) Method, apparatus and system for providing multimedia messages to incompatible terminals
US6947738B2 (en) Multimedia messaging service routing system and method
US20030236769A1 (en) Method and device for mobile communication
US6732150B1 (en) Apparatus, and associated method, for providing a client with out-of-band messages
US20030158902A1 (en) Multimedia instant communication system and method
US20040185885A1 (en) Message data in mobile communication systems
US6301245B1 (en) Universal Messaging system providing integrated voice, data and fax messaging services to PC/web-based clients, including a large object server for efficiently distributing voice/fax messages to web-based clients
US20100011077A1 (en) Delivery of email messages with repetitive attachments
US7890586B1 (en) Mass multimedia messaging
US20030045311A1 (en) Message transfer from a source device via a mobile terminal device to a third device and data synchronization between terminal devices
US6775291B1 (en) Wireless internet service method in gateway system
US20040258063A1 (en) Multimedia message processing
US20030193967A1 (en) Method, apparatus and system for processing multimedia messages
Brown et al. SMS: The short message service
US20030086438A1 (en) Method for accessing messages, and associated apparatuses and software programs
US20050021834A1 (en) System for rendering multimedia messages by providing, in a multimedia message, URL for downloadable software to a receiving terminal
US20070142029A1 (en) Message management
US20070249379A1 (en) Methods, systems, and computer program products for transferring a message service payload between messaging entities
US20070192403A1 (en) Method and arrangement for indicating a size restriction of a message
US20040148400A1 (en) Data transmission
US20050243978A1 (en) System and method of interworking messages between mobile communication terminals
US20040029598A1 (en) Method for transmitting short messages over the internet
US7609686B1 (en) Mass multimedia messaging

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN IN JP KR US

AL Designated countries for regional patents

Kind code of ref document: A1

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

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

Ref document number: 2001273297

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10466749

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2002558717

Country of ref document: JP

WWP Wipo information: published in national office

Ref document number: 2001273297

Country of ref document: EP