[go: up one dir, main page]

WO2004021663A1 - Verfahren sowie vorrichtung zur datenquellenspezifischen kennzeichnung von push-nutzdaten - Google Patents

Verfahren sowie vorrichtung zur datenquellenspezifischen kennzeichnung von push-nutzdaten Download PDF

Info

Publication number
WO2004021663A1
WO2004021663A1 PCT/DE2003/002535 DE0302535W WO2004021663A1 WO 2004021663 A1 WO2004021663 A1 WO 2004021663A1 DE 0302535 W DE0302535 W DE 0302535W WO 2004021663 A1 WO2004021663 A1 WO 2004021663A1
Authority
WO
WIPO (PCT)
Prior art keywords
push
mms
data
pnu
message
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.)
Ceased
Application number
PCT/DE2003/002535
Other languages
English (en)
French (fr)
Inventor
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
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of WO2004021663A1 publication Critical patent/WO2004021663A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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
    • 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]

Definitions

  • messages or data can be downloaded to a user's subscriber device from a component of the network in an uncontrollable manner for the user. Even if a notification message arrives at the subscriber device of the respective user that data or messages are held ready for retrieval on the network side, it remains too opaque for the user as to who the sender of this notification and the provider of this data actually is. This makes wrong decisions when downloading data by the respective user possible and there is also a risk of misuse of such notification messages.
  • the invention is based on the object of demonstrating a way in which it can be ensured for the respective user of a subscriber device of a communication network that push data or push messages provided on the network side come from a data source which is trustworthy for the respective user. This object is achieved with the aid of the following method according to the invention:
  • Method for data source-specific identification of push user data in a communication network which is sent from at least one push initiator via at least one push proxy gateway to at least one push client without being requested to do so by using the push initiator or push Proxy gateway part or all of the push user data can be provided with at least one signature using an asymmetrical cryptography method.
  • the data source-specific identification of the respective push message using an asymmetrical cryptography method in the push initiator and / or push proxy gateway largely ensures that only such data or messages are selectively conveyed to the communication unit of the respective user which come from a known, trusted data source.
  • the invention further relates to a communication network with at least one device for data source-specific identification of push messages according to the inventive method.
  • FIG. 1 shows a schematic representation of a pull mode in the transmission of data between a server and a client
  • Figure 2 is a schematic representation of a push mode in the transmission of data between one
  • WAP Wireless Application Protocol
  • FIG. 4 shows a schematic representation of the functionality of the push proxy gateway according to FIG. 3 in detail
  • FIG. 6 shows an exemplary push message "MMS notification" in textual coding for notifying a communication unit in a communication network of the presence on the network of retrievable data or messages, in particular multimedia data, and
  • FIGs 7, 8 different examples of the push message , MMS Notification "in textual coding according to Figure 6 with a digital signature for data source-specific identification according to the invention.
  • This pull function is designated in FIG. 1 by PLM.
  • This push mode is designated by PSM in FIG. 2.
  • WAP Wireless Access Protocol
  • WAP forum the push procedure for the transmission of data between a server and a client, which is located on a mobile device, in particular a radio communication device.
  • the respective server i.e.
  • the network component that provides the user data to be transmitted and possibly additional control commands is referred to as the so-called push initiator. It sends the user data (possibly including the additional control commands) to a push proxy gateway, which sends the data it sends
  • a gateway takes over an interface function for the transmission connection between the respective server and its associated receiving units receiving push messages.
  • a push proxy gateway also evaluates any existing control commands for the delivery of the user data in push mode and controls the correct execution of the user data transmission between the push proxy gateway and the respectively assigned push client, ie the respective receiving unit of the push messages or push data sent.
  • This push functionality of a push proxy gateway can expediently be integrated into a conventional, "normal" WAP gateway.
  • WAP gateway and push proxy gateway it is also possible to use two separate functional units, namely WAP gateway and push proxy gateway, to be provided with a clear division of tasks in the respective communication network.
  • FIG. 3 schematically illustrates a push architecture in WAP for the distribution of push messages in a radio communication network.
  • a push initiator PI sends push messages PNA, which contain control information in addition to push user data PNU, via at least one transmission path UPI to an assigned push proxy gateway PPG, which further delivers the push user data PNU im
  • WAP PAP Push Access Protocol
  • HTTP Hypertext Transfer Protocol
  • OTA Over The Air
  • the interface in the transmission connection UPI between the push initiator PI and the push proxy gateway PPG which is based on the WAP PAP protocol, is designated by SB.
  • the interface for the transmission of the push user data PNU between the push proxy gateway PPG and the push client PC with the aid of the push OTA protocol OTAP is indicated in FIG. 3 by the reference symbol SA.
  • the interface SA in particular also includes an air interface between a base station that sends push useful data and one or more radio communication devices in their radio cell.
  • FIG. 4 schematically illustrates how push user data PNU through a WAP gateway WAPG with an integrated push proxy
  • the push initiator P1 is provided as the sending communication unit of the server SV.
  • the push client PC is preferably part of a radio communication device, in particular a mobile terminal device UE, such as a mobile radio telephone.
  • the push initiator P1 of the server SV makes the push messages PNA to be sent conform to the WAP PAP protocol PAP by transferring them to its lower transmission protocol layers LLB.
  • the push messages PNA transmitted in such a modified manner via the interface SB are evaluated by the lower layers LLB of the WAP-PAP protocol in the WAP gateway WAPG and, with the aid of the gateway WAPG, to the lower layers LLA of the WAP- OTA protocol OTAP adapted to its format.
  • the push client PC in the user equipment UE can use the lower protocol layers LLA and its WAP-OTA protocol OTAP to correctly receive and evaluate the received push user data PNU.
  • MMS Multimedia Messaging Service
  • SMS Short Message Service
  • SMS Short Message Service
  • SMS Short Message Service
  • MMS Multimedia Message Service
  • a multimedia message can accordingly be composed of several multimedia elements of different file types (for example audio or still picture) and / or file formats (for still picture for example GIF or JPEG).
  • FIG. 5 shows the simplified network architecture according to 3GPP for the multimedia messaging service. It includes, for example, two multimedia messaging service relays / servers RSA, RSB of two different multimedia messaging service providers SPA, SPB.
  • the MMS relay / server RSA transmits push user data PNU to the communication units of a multiplicity of subscriber devices, in particular radio communication devices, of the communication network CN, the remaining components of which have been omitted in FIG. 5 for the sake of clarity.
  • FIG. 5 shows the simplified network architecture according to 3GPP for the multimedia messaging service. It includes, for example, two multimedia messaging service relays / servers RSA, RSB of two different multimedia messaging service providers SPA, SPB.
  • the MMS relay / server RSA transmits push user data PNU to the communication units of a multiplicity of subscriber devices, in particular radio communication devices
  • FIG. 5 shows only a single subscriber device UA of this group of subscriber devices, which is coupled to the relay / server RSA via an interface MM1.
  • one or more subscriber devices ÜB in particular radio communication devices, are assigned to the second MMS relay / server RSB of the second provider or service provider SPB with the aid of the interface MM1.
  • the two relay / servers RSA, RSB can communicate via an additional interface MM4, using the so-called SMTP (Simple Mail Transfer Protocol) in particular in UMTS.
  • a communication unit in the form of a so-called MMS user agent is implemented in the respective subscriber device, such as UA, which is to receive and evaluate the push user data PNU from the MMS relay / server RSA.
  • MMS user agent is understood to be a sequence procedure that implements the multimedia messaging service.
  • This MMS user agent can preferably be provided on a radio communication device, in particular a mobile device, or on an additional device connected to a mobile device, such as a laptop or the like.
  • the communication unit or the push client of the respective push user data PNU receiving subscriber devices such as UA in Figure 5 first of all from the assigned MMS relay / server such as RSA by means of a so-called notification or inquiry message 'MMS Notification' about the arrival of a new multimedia message on the MMS relay / server, which can be downloaded there
  • the assigned MMS relay / server such as RSA
  • a lot of additional information (such as Sender, topic, etc.) for a multimedia message, which can be used by the MMS user agent of the recipient as a decision-making aid for the download.
  • the interface MM1 between the MMS Relay / Server RSA and the MMS User Agent of the subscriber device UA in Figure 5 is particularly by the WAP specifications WAP-205-MMS Architecture Overview; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0, WAP-206 MMS Client Transaction; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0, WAP-209-MMS Encapsulation; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0 defined in more detail.
  • WAP-205-MMS Architecture Overview WAP Multimedia Messaging Service (MMS) Specification Suite 2.0, WAP-206 MMS Client Transaction
  • WAP Multimedia Messaging Service (MMS) Specification Suite 2.0 defined in more detail.
  • the 'MMS notifications' are sent to the recipient in push mode according to the WAP push protocol (cf. specifications WAP-250, Push Architectural Overview, Version 03-July-2001, WAP-247, Push Access Protocol, Version 29-April-2001, WAP-235, Push Over The Air Protocol, Version 25-April-2001), ie the user data to be transmitted are first sent to a notification message 'MMS Notification' by the respective MMS relay / server as a push initiator, preferably wired to the push Transfer proxy gateway PPG.
  • WAP push protocol cf. specifications WAP-250, Push Architectural Overview, Version 03-July-2001, WAP-247, Push Access Protocol, Version 29-April-2001, WAP-235, Push Over The Air Protocol, Version 25-April-2001
  • the interface MM1 in Figure 5 corresponding to the 3GPP MMS architecture contains the two interfaces SA and SB for the push functionality according to the push architectures of Figures 3, 4.
  • a simple way of transmitting the data of the respective “MMS Notification” notification message about the presence of push messages to the receiving subscriber devices affected by this is that the data to be transmitted of the “MMS Notification” notification message are in a short Message or several short messages of the Short Messaging Service (SMS) are sent to the end device of the respective recipient.
  • SMS Short Messaging Service
  • a 'MMS Notification' formatted according to WAP-209-MMS Encapsulation; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0 is used in the case of MMS as a carrier for the push functionality with UDH (User Data Headers) - and WSP (Wellness Session Protocol) - header fields and written in the 140 byte transport container of the SMS (Short Message Service).
  • MMS Multimedia Messaging Service
  • UDH User Data Headers
  • WSP Wellness Session Protocol
  • SMS Short Message Service
  • the data received via SMS could, however, also simply be a correctly formatted data record with which an 'MMS notification' notification message is to be simulated, and which is actually from a sender (push initiator) other than the MMS relay / server actually expected
  • This other sender could use the URI (ie the reference to a storage space which is actually intended for the download of the multimedia message) in a simulated 'MMS Notification' notification message to download unwanted content such as advertising to the mobile terminal of the respective communication network participant.
  • This so-called 'spamming' is particularly annoying for the respective recipient in the case of 'immediate retrieval' in the multimedia messaging service (MMS), because in this mode his terminal automatically resolves the reference in the 'MMS notification' notification message and the download process to download the multimedia message from the assigned MMS relay / server independently, ie without user prompt.
  • MMS multimedia messaging service
  • push-user data is identified in a data source-specific manner by the fact that these push-user data are stored in the multimedia messaging relay / server or be partially or completely provided with at least one signature in the push proxy gateway using an asymmetrical cryptography method.
  • a push message is sent, its push payload data is provided with a unique identifier that allows authentication of the sending relay / server.
  • 'MMS Notification' - Notification messages about content provided by other providers They can thus be recognized and ignored in advance in the respective MMS user agent, which corresponds to filtering out or sorting out unwanted data. This largely avoids downloading unwanted content from the respective server.
  • the sender of a push message is checked by verifying a digital signature.
  • the multimedia messaging relay / server and / or the downstream push proxy gateway signs with a private cryptographic key
  • the signature generated in particular in the form of a so-called hash value, is sent from the relay / server and / or the push proxy gateway to the terminal of the respective receiver 5 in push mode
  • the public, cryptographic key of the asymmetrical cryptography procedure of the MMS provider is used in the terminal device to verify the Usage data supplied signature used.
  • the terminal device it can be checked in the telecommunications terminal of a recipient whether the data received in push mode actually comes from his own MMS provider, ie the terminal now has practically reliable origin filter functionality.
  • the mechanisms of asymmetric cryptography in the multimedia messaging relay / server and / or push proxy gateway are therefore used for reliable checking of push user data on the receiving end, in particular for checking 'MMS notification' messages arriving in push mode. to partially or completely sign the user data to be transmitted in the push mode.
  • the signature of the respective push user data / push message is selected either in the push initiator of the multimedia messaging relay / server or in its assigned push proxy gateway with a private key of the service provider or network operator performed while the verification of the signature in the respective telecommunication terminal with the matching public key of the service provider or • network operator takes place
  • This public key can be external either in an internal memory area of the respective terminal or in a.
  • SIM Subscriber Identity Module
  • UICC Universal Integrated Circuit Card
  • There are memory areas on these cards that can only be written or updated by the network operator, and those for which the user also has write and read rights.
  • the service provider or network operator can easily increase the key length in this way in order to be able to meet new security requirements.
  • FIG. 6 shows an example of an 'MMS Notification' message in textual coding in the MMS.
  • MMS Multimedia Messaging Service
  • SMS Short Message Service
  • the data source-specific identification of the "MMS Notification" notification message in the MMS which is sent to the downloadable push messages from the MMS relay / server for downloading to one or more addressed communication units of subscriber devices, can expediently be carried out in the following four different ways:
  • the signature is appended to the URI reference as an extension, which is illustrated, for example, by the MMS notification message MNl * from FIG.
  • an MMS provider such as SPA from FIG. 5, would like to transmit the 'MMS notification' message shown in FIG. 6 to one of its customers, it signs the entry, ie the field value of the header field 'X-MMS content, for security reasons -Location 'http: // siemens .de / sal / mms-id with its private cryptographic key.
  • This signature is, for example, a hash value HW, which is added as an addition or extension to the previous field value (ie the actual URL) of the header field X-MMS-Content-Location at the end.
  • this hash value HW is then separated from the rest of the field value (ie from the actual URI) of the X-MMS content location header field.
  • the signature HW is then verified with the help of the public cryptographic key of the MMS provider in the terminal itself.
  • the public cryptographic key of the MMS provider can be read in, for example, from an external storage unit.
  • the signing of the field value of the header field X-MMS content location generates a hash value HW.
  • HW hash value
  • this is now not appended to the field value of the header value X-MMS-Content-Location, but in a specially defined header field X-MMS-Signature in the MMS notification- Notice message included.
  • MMS notification message MN1 ** provided with the private key from FIG. 8 the header field with the signature is added at the end of the message.
  • the complete push payload data with a signature of an asymmetrical cryptography method.
  • the push useful data was an 'MMS notification' notification message in the MMS
  • the entire 'MMS notification' notification message is thus provided with the private key of an asymmetrical cryptography method as a whole.
  • the signature is expediently carried out in the respective MMS relay / server.
  • To encrypt the entire push user data it is expedient to provide at least one header field for the signature, which is placed in front of the signed push user data.
  • the push payload itself remains unchanged. If the respective push useful data is formed in particular by an 'MMS notification' notification message, a hash value HW is generated as in the first exemplary embodiment.
  • Example 4 Furthermore, it may be expedient to send the respective push message together with control commands from the push initiator of the respective MMS relay / server by means of the WAP PAP to the assigned push proxy gateway for the signature there, ie the signature of the respective one Push user data only takes place in the push proxy gateway.
  • the push useful data itself remain unchanged on the interface side of the PAP, ie in the area of the interface SB in accordance with the architecture of FIGS. 3, 4.
  • the respective push user data are therefore only from the respective push proxy gateway and not from the
  • control commands for the control entity are expediently defined, that is, an XML-coded data record which precedes the actual push user data in the WAP PAP.
  • the signing process with the help of an asymmetrical cryptography process in the respective MMS relay / server e.g. in accordance with the exemplary embodiments 1 to 3, the advantage that there is generally more computing power available than in a gateway and that the push useful data transported via the two interfaces SA, SB of FIG. 4 can also be identified in a data-specific manner without gaps. As a result, security gaps are better avoided compared to embodiment 4. This is because the push user data sent via both interfaces SA, SB are provided with a private key of an asymmetrical cryptography method for both interfaces, i.e. the signature remains unchanged.
  • SIR SIR session initiation request
  • the push client could then use a WSP or HTTP connection between the tel Set up the device and the push initiator.
  • WSP and HTTP connections would also allow a somewhat reliable authentication of the push initiator, they would have the disadvantage, in particular, that a WSP or HTTP is specifically for each transmission of user data in push mode (for example in the form of an MMS notification) -Connection must be established- te. Particularly in the case of roaming, this is usually associated with high additional costs for the recipient and is therefore generally not acceptable in practice.
  • the method according to the invention for data-specific identification of push useful data advantageously enables the respective 'MMS notification' notification message in at least one short message together with the signature, in particular the hash value, without SIR and subsequent WSP or HTTP connection establishment , the asymmetrical cryptography process can be accommodated.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Virology (AREA)
  • Computing Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Zur datenquellenspezifischen Kennzeichnung von Push-Nutzdaten (PNU), die im Multimedia Messaging Service eines Kommunikationsnetzwerks (CN) von einem Push-Initiator(PI) über ein Push-Proxy-Gateway (PPG) an mindestens eine Kommunikationseinheit (UA) geschickt werden, wird im Push-Initiator (PI) und/oder im Push-Proxy-Gateway (PPG) ein Teil der oder die gesamten jeweiligen Push-Nutzdaten (PNU) mit Hilfe eines asymmetrischen Kryptographieverfahrens signiert.

Description

Beschreibung
Verfahren sowie Vorrichtung zur datenquellenspezifischen Kennzeichnung von Push-Nutzdaten
In Kommunikationsnetzwerken, insbesondere Funkkommunikations- systemen, kann es in der Praxis dazu kommen, dass auf das Teilnehmergerät eines Benutzers Nachrichten bzw. Daten in für den Benutzer unkontrollierbarer Weise von einer Komponente des Netzwerks heruntergeladen werden. Selbst wenn eine Hin- weisnachricht beim Teilnehmergerät des jeweiligen Benutzers eintrifft, dass Daten bzw. Nachrichten netzwerkseitig zum Abruf bereitgehalten werden, bleibt es für den Benutzer zu un- durchsichtig, wer der Absender dieser Benachrichtigung und der Bereitsteller dieser Daten tatsächlich ist. Dadurch sind Fehlentscheidungen beim Herunterladen von Daten durch den jeweiligen Benutzer möglich und auch die Gefahr des Missbrauchs solcher Hinweisnachrichten gegeben.
Der Erfindung liegt die Aufgabe zugrunde, einen Weg aufzuzeigen, wie für den jeweiligen Benutzer eines Teilnehmergeräts eines Kommunikationsnetzwerks sichergestellt werden kann, dass netzwerkseitig bereitgestellte Push-Daten bzw. Push- Nachrichten aus einer für den jeweiligen Benutzer vertrauenswürdigen Datenquelle stammen. Diese Aufgabe wird mit Hilfe folgendem erfindungsgemäßen Verfahren gelöst:
Verfahren zur datenquellenspezifischen Kennzeichnung von Push-Nutzdaten in einem Kommunikationsnetzwerk, die ausgehend von mindestens einem Push-Initiator über mindestens ein Push- Proxy-Gateway an mindestens einen Push-Client ohne dessen vorherige Aufforderung geschickt werden, indem im Push- Initiator oder im Push-Proxy-Gateway ein Teil der oder die gesamten Push-Nutzdaten mit Hilfe eines asymmetrischen Kryptographieverfahrens mit mindestens einer Signatur versehen werden. Durch die datenquellenspezifische Kennzeichnung der jeweiligen Push-Nachricht mit Hilfe eines asymmetrischen Kryptographieverfahrens im Push-Initiator und/oder Push-Proxy-Gateway ist weitgehend sichergestellt, dass an die Koir-munikationsein- heit des jeweiligen Benutzers selektiv nur solche Daten bzw. Nachrichten vermittelt werden, die aus einer dem Benutzer vertrauenswürdigen, bekannten Datenquelle stammen.
Die Erfindung betrifft weiterhin ein Kommunikationsnetzwerk mit mindestens einer Vorrichtung zur datenquellenspezifischen Kennzeichnung von Push-Nachrichten nach dem erfindungsgemäßen Verfahren.
Die Erfindung und ihre Weiterbildungen werden nachfolgend anhand von Zeichnungen näher erläutert.
Es zeigen:
Figur 1 in schematischer Darstellung einen Pull-Modus bei der Übertragung von Daten zwischen einem Server und einem Client,
Figur 2 in schematischer Darstellung einen Push-Modus bei der Übertragung von Daten zwischen einem
Server und einem Push - Client,
Figur 3 eine Push-Architektur gemäß WAP (Wireless Application Protocol) , bei der Push-Nachrichten von einer Absendeeinheit (= Push Initiator Pl) über ein Push-Proxy-Gateway) an eine Nachrichtenempfangseinheit (=Push -Client PC) übertragen werden,
Figur 4 in schematischer Darstellung die Funktionalität des Push-Proxy-Gateways nach Figur 3 im Detail, Figur 5 schematisch in vereinfachter Darstellung eine MMS-Architektur (MMS= Multimedia Messaging Service) nach 3GPP, die zur Durchführung des erfindungsgemäßen Verfahrens modifiziert ist,
Figur 6 eine beispielhafte Push-Nachricht '"MMS Notifi- cation" in textueller Kodierung zur Benachrichtigung einer Kommunikationseinheit in ei- nem Kommunikationsnetzwerk über das netzwerk- seitige Vorliegen von abrufbaren Daten bzw. Nachrichten, insbesondere Multimediadaten, und
Figuren 7, 8 verschiedene Beispiele für die Push-Nachricht ,MMS Notification" in textueller Kodierung nach Figur 6 mit einer digitalen Signatur zur erfindungsgemäßen datenquellenspezifischen Kennzeichnung.
Elemente mit gleicher Funktion und Wirkungsweise sind in den Figuren 1 mit 8 jeweils mit denselben Bezugszeichen versehen.
Figur 1 veranschaulicht schematisch die Übertragung von Daten DA zwischen einem Server SV und einem Client CL im sogenann- ten Pull-Modus, bei dem diese Empfangseinheit CL ein Anforderungssignals AF an den Server SV richtet. Erst aufgrund dieses Anforderungssignals AF hin werden die Daten bzw. Nachrichten vom Server SV an die Empfangseinheit CL heruntergezogen bzw. übermittelt (englisch pull = ziehen) . Diese Pull- Funktion ist in der Figur 1 mit PLM bezeichnet. Im Unterschied dazu werden die Daten bzw. Nachrichten DA im sogenannten Push-Modus vom Server SV ungefragt, d.h. ohne netzwerk- seitiges Anforderungssignal, an die Empfangseinheit PC übermittelt, d.h. sozusagen direkt bzw. unvermittelt weiterge- schoben (englisch push = schieben, stoßen) . Dieser Push-Modus ist in der Figur 2 mit PSM bezeichnet. Auf diese Weise gehen die • Pull-Transaktionen immer vom jeweiligen Client aus, wäh- rend die Push-Transaktionen von Daten immer vom jeweiligen Server initiiert werden. Das Browsen im World Wide Web ist ein typisches Beispiel für die Pull-Technologie. Dort entspricht die Eingabe einer URL (URL = Uniform Resource Loca- tor, was der Adresse eines Speicherplatzes oder einem Hinweis darauf entspricht) in den Browser dem oben erwähnten Anforderungssignal. Derartige Server-/Client-Konstellationen sind in vorteilhafter Weise Bestandteil gängiger Kommunikationsnetzwerke, insbesondere Funkkommunikationssysteme.
In den Spezifikationen WAP-250, Push Architectural Overview, Version 03-July-2001, WAP-247, Push Access Protocol, Version 29-April-2001 sowie WAP-235, Push Over The Air Protocol, Version 25-April-2001 des WAP-Forums (WAP = Wireless Access Pro- tocol) ist das Push-Verfahren für die Übertragung von Daten zwischen einem Server und einem Client definiert, der sich auf einem mobilen Endgerät, insbesondere Funkkommunikationsgerät, befindet. In der Terminologie des WAP-Forums wird der jeweilige Server, d.h. allgemein betrachtet diejenige Netz- werkkomponente, die zu übertragende Nutzdaten und eventuell zusätzliche Steuerbefehle (z.B. über die Art der Zustellung der Nutzdaten im Push-Modus) bereitstellt, als sogenannter Push-Initiator bezeichnet. Er schickt die Nutzdaten (gegebenenfalls inklusive der zusätzlichen Steuerbefehle) an indes- tens ein Push-Proxy-Gateway, das die von ihm abgesandten
Nutzdaten übertragungstechnisch an die unterschiedlichen Protokolle der tieferen Protokollschichten der jeweilig empfangenden Kommunikationseinheit anpasst. Mit anderen Worten heißt das, dass ein solches Gateway eine Schnittstellenfunk- tion für die Übertragungsverbindung zwischen dem jeweiligen Server und dessen zugeordneten, Push-Nachrichten empfangenden Empfangseinheiten übernimmt. Weiterhin wertet ein solches Push-Proxy-Gateway gegebenenfalls auch etwaig vorhandene Steuerbefehle für die Zustellung der Nutzdaten im Push-Modus aus und kontrolliert die korrekte Ausführung der Nutzdatenübertragung zwischen dem Push-Proxy-Gateway und dem jeweilig zugeordneten Push-Client, d.h. der jeweiligen Empfangseinheit der versandten Push-Nachrichten bzw. Push-Daten. Diese Push- Funktionalität eines Push-Proxy-Gateways kann zweckmäßigerweise in ein herkömmliches, 'normales" WAP-Gateway integriert sein. Alternativ dazu ist es aber auch möglich, zwei getrenn- te Funktionseinheiten, nämlich WAP-Gateway und Push-Proxy- Gateway, mit einer klaren Aufgabenteilung im jeweiligen Kommunikationsnetzwerk vorzusehen.
Figur 3 veranschaulicht in schematischer Darstellung eine Push-Architektur in WAP zur Verteilung von Push-Nachrichten in einem Funkkommunikationsnetzwerk. Ein Push-Initiator Pl schickt dabei Push-Nachrichten PNA, die neben Push-Nutzdaten PNU Steuerinformationen enthalten, über mindestens einen Ü- bertragungspfad UPI an ein zugeordnetes Push-Proxy-Gateway PPG, das die weitere Zustellung der Push-Nutzdaten PNU im
Push-Modus über mindestens einen Übertragungspfad UP2 an einen Push-Client PC ausführt und überwacht. An das Push-Proxy- Gateway PPG können dabei eine Vielzahl von Push-Clients angeschlossen sein. Diese sind der zeichnerischen Einfachheit halber in der Figur 3 weggelassen worden. Zwischen dem Push- Initiator Pl und dem Push-Proxy-Gateway PPG wird bei der Ü- bertragung der Push-Nachrichten PNA das sogenannte WAP PAP- Protokoll (PAP = Push Access Protocol) verwendet. Es setzt auf bekannte Standard-Internet-Protokolle wie beispielsweise HTTP (HTTP = Hypertext Transfer Protocol) auf. Ausführliche Angaben zum WAP PAP-Protokoll sind insbesondere in der Spezifikation WAP-247, Push Access Protocol, Version 29-April-2001 gemacht. Einzelheiten zum HTTP-Protokoll finden sich beispielsweise in der Spezifikation RFC 2616, Hypertext Transfer Protocol - HTTP/1.1; June 1999. Etwaig mit den Push- Nachrichten assoziierte zusätzliche Steuerbefehle werden vorzugsweise in der XML-Syntax (XML = Extensible Markup Langua- ge) ausgedrückt. Das Push-Proxy-Gateway PPG überträgt die Push-Nutzdaten PNU unter Berücksichtigung dieser Steuerbefeh- le des Push-Initiators Pl an die Kommunikationseinheit bzw. den Client PC im Teilnehmergerät des jeweiligen Empfängers. Zwischen dem Push-Proxy-Gateway PPG und dem Push-Client-PC wird insbesondere das WAP-Push OTA Protocol (OTA = Over The Air) eingesetzt. Nähere Einzelheiten dazu sind in der Spezifikation WAP-235, Push Over The Air Protocol, Version 25- April-2001 angegeben.
In der Figur 3 ist die Schnittstelle in der Übertragungsverbindung UPI zwischen dem Push-Initiator Pl und dem Push- Proxy-Gateway PPG, die auf dem WAP PAP-Protokoll basiert, mit SB bezeichnet. Die Schnittstelle zur Übertragung der Push- Nutzdaten PNU zwischen dem Push-Proxy-Gateway PPG und dem Push-Client PC unter Zuhilfenahme des Push-OTA-Protokolls OTAP ist in der Figur 3 mit dem Bezugszeichen SA angedeutet. In einem Funkkommunikationsnetzwerk wie z.B. nach dem UMTS- Standard umfasst die Schnittstelle SA insbesondere auch in- destens eine Luftschnittstelle zwischen einer Push-Nutzdaten absendenden Basisstation und ein oder mehreren Funkkommunikationsgeräten in deren Funkzelle.
Figur 4 veranschaulicht schematisch, wie Push-Nutzdaten PNU durch ein WAP-Gateway WAPG mit integrierter Push-Proxy-
Gateway-Funktionalität an die tieferen Protokollschichten der beiden Schnittstellen SA sowie SB von Figur 3, nämlich im einzelnen an das WAP OTA-Protokoll OTAP für die Schnittstelle SA und das WAP Push-Access-Protocol PAP für die Schnittstelle SB, zur Formatanpassung übergeben werden. In der Figur 4 ist dabei der Push-Initiator Pl als Absendekommunikationseinheit des Servers SV vorgesehen. Der Push-Client PC ist als empfangende Kommunikationseinheit vorzugsweise Bestandteil eines Funkkommunikationsgerätes, insbesondere eines mobilen Endge- rätes UE wie z.B. Mobilfunktelefon. Der Push-Initiator Pl des Servers SV macht die zu versendenden Push-Nachrichten PNA konform zum WAP PAP-Protokoll PAP, indem er diese an seine unteren Übertragungs-Protokollschichten LLB übergibt. Die ü- ber die Schnittstelle SB derart modifiziert übertragenen Push-Nachrichten PNA werden von den unteren Schichten LLB des WAP-PAP-Protokolls im WAP-Gateway WAPG ausgewertet und mit Hilfe des Gateways WAPG an die unteren Schichten LLA des WAP- OTA-Protokolls OTAP an dessen Format angepasst. Auf diese Weise kann der Push-Client PC im Teilnehmergerät UE mit Hilfe der unteren Protokollschichten LLA und seines WAP-OTA- Protokolls OTAP die empfangenen Push-Nutzdaten PNU einwand- frei empfangen und auswerten.
Für Mobilfunksysteme der nächsten Generationen (z.B. 2.5G und 3G) , wie z.B. UMTS (UMTS = Universal Mobile Telecommunicati- ons System) , wird zur Zeit eine multimediafähige Variante ei- nes mobilen Nachrichtendienstes standardisiert, der sogenannte MMS-Service (MMS = Multimedia Messaging Service) . Einzelheiten dazu sind detailliert in den Spezifikationen 3GPP TS 22.140 version 5.2.0, Release 5; Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Messaging Service (MMS) ; Service Aspects; Stage 1, sowie in 3GPP TS 23.140 version 5.3.0, Release 5; Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS) ; Func- tional Description; Stage 2 wiedergegeben. Nachrichten mit multimedialen Inhalten werden im Folgenden zur besseren Abgrenzung von den Textnachrichten des SMS (Short Message Service) nur noch kurz MMs (MM = Multimedia Message; MMs= Multimedia Messages (Plural)) genannt. Im Gegensatz zum SMS (SMS = Short Message Service) entfällt dabei die Beschränkung auf reine Textinhalte. Explizite Angaben zum SMS sind in der Spezifikation 3GPP TS 23.040 version 5.2.0, Release 5; Third Generation Partnership Project; Technical Specification Group Terminals; Technical Realization of the Short Message Service (SMS) gemacht. Im Unterschied zum SMS ist es beim MMS in vor- teilhafter Weise möglich, Texte entsprechend dem individuellen Geschmack des jeweiligen Benutzers zu formatieren, sowie Audio- und Videoinhalte in einer Nachricht einzubetten. Eine Multimedia Message (MM) kann demnach aus mehreren Multimedia- Elementen von unterschiedlichen Dateitypen (z.B. Audio- oder Standbild) und/oder Dateiformaten (bei Standbild z.B. GIF o- der JPEG) zusammengesetzt sein. In Figur 5 ist die vereinfachte Netzwerkarchitektur nach 3GPP für den Multimedia Messaging Service schematisch dargestellt. Sie umfasst beispielhaft zwei Multimedia Messaging Service- Relay/Server RSA, RSB zweier verschiedener Multimedia Messa- ging Service Provider SPA, SPB. Der MMS-Relay/Server RSA ü- bermittelt Push-Nutzdaten PNU an die Kommunikationseinheiten einer Vielzahl von Teilnehmergeräten, insbesondere Funkkommu- nikationsgeräten, des Kommunikationsnetzwerks CN, dessen übrige Komponenten in der Figur 5 der Übersichtlichkeit halber weggelassen worden sind. In der Figur 5 ist der zeichnerischen Einfachheit halber lediglich ein einzelnes Teilnehmergerät UA dieser Gruppe von Teilnehmergeräten eingezeichnet, das über eine Schnittstelle MM1 an den Relay/Server RSA angekoppelt ist. In entsprechender Weise sind ein oder mehrere Teilnehmergeräte ÜB, insbesondere Funkkommunikationsgeräte, dem zweiten MMS Relay/Server RSB des zweiten Providers bzw. Dienstanbieters SPB unter Zuhilfenahme der Schnittstelle MM1 zugeordnet. Die beiden Relay/Server RSA, RSB können über eine weitere Schnittstelle MM4 kommunizieren, wobei sie insbeson- dere im UMTS das sogenannte SMTP (Simple Mail Transfer Protocol) nutzen. Im jeweiligen Teilnehmergerät wie z.B. UA ist eine Kommunikationseinheit in Form eines sogenannten MMS User Agents implementiert, der die Push-Nutzdaten PNU vom MMS Relay/Server RSA empfangen und auswerten soll. Unter MMS User Agent wird dabei eine Ablaufprozedur verstanden, die den Multimedia Messaging Service realisiert. Dieser MMS User Agent kann dabei vorzugsweise auf einem Funkkommunikationsgerät, insbesondere Mobilfunkgerät, oder auf einem an ein Mobilfunkgerät angeschlossenen Zusatzgerät wie z.B. Laptop oder Ähnli- chem vorgesehen sein. Ein MMS Relay/Server wie z.B. RSA ist ein Netzwerkelement, das im Zuständigkeitsbereich MMSE (MMSE = Multimedia Messaging Service Environment) des MMS Providers wie z.B. SPA den dortigen anwesenden MMS User Agents die MMS- Funktionalität zur Verfügung stellt.
Im Multimedia Messaging Service wird die Kommunikationsein- heit bzw. der Push-Client des jeweiligen, Push-Nutzdaten PNU empfangenden Teilnehmergeräts wie z.B. UA in Figur 5 zunächst vom zugeordneten MMS -Relay/Server wie z.B. RSA durch eine sogenannte Hinweis- oder Anfragenachricht 'MMS Notification" über das Eintreffen einer neuen Multimedia Message auf dem MMS Relay/Server informiert, die dort zum Herunterladen
(Download) bereit gehalten wird. Eine derartige 'MMS Notification" -Nachricht enthält eine Referenz auf den Speicherplatz der Multimedia Message im Zuständigkeitsbereich des jeweiligen MMS Providers wie z.B. SPA, vorzugsweise in Form eines URI (URI = Uniform Resource Identifier) . Mit Hilfe dieser Referenz kann die Multimedia Message daraufhin entweder sofort in Form eines sogenannten 'immediate retrieval" oder auch zeitlich verzögert in Form eines sogenannten 'deferred retrieval" auf das Endgerät wie z.B. UA in Figur 5 eruntergela- den werden. In einer 'MMS Notification" -Nachricht können viele ergänzende Informationen (wie z.B. Absender, Thema, usw.) zu einer Multimedia Message enthalten sein, die dem MMS User Agent des jeweiligen Empfängers als Entscheidungshilfe für den Download dienen können. Die Schnittstelle MM1 zwischen dem MMS Relay/Server RSA und dem MMS User Agent des Teilnehmergeräts UA in Figur 5 wird insbesondere durch die WAP Spezifikationen WAP-205-MMS Architecture Overview; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0, WAP-206- MMS Client Transaction; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0, WAP-209-MMS Encapsulation; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0 näher definiert.
Bei MMS-Teilnehmern mit mobilen Endgeräten werden die 'MMS Notifications" dem jeweiligen Empfänger im Push-Modus nach dem WAP Push-Protokoll (vgl. Spezifikationen WAP-250, Push Architectural Overview, Version 03-July-2001, WAP-247, Push Access Protocol, Version 29-April-2001, WAP-235, Push Over The Air Protocol, Version 25-April-2001 ) zugestellt, d.h. zu- nächst werden die zu übertragenden Nutzdaten einer Hinweisnachricht 'MMS Notification" vom jeweiligen MMS Relay/Server als Push-Initiator vorzugsweise kabelgebunden an das Push- Proxy-Gateway PPG übertragen. Dieses entscheidet nun seinerseits unter Berücksichtigung eventueller Vorgaben des MMS- Relay/Servers in Form der oben erwähnten Steuerbefehle über die Art der weiteren Zustellung der Hinweisnachricht 'MMS No- tification" über die Luftschnittstelle an den Push-Client auf dem mobilen Endgerät wie z.B. UA in Figur 5. Die Schnittstelle MM1 in Figur 5 entsprechend der 3GPP MMS Architektur beinhaltet dabei für die Push-Funktionalität die beiden Schnittstellen SA bzw. SB entsprechend den Push-Architekturen der Figuren 3, 4.
Eine einfache Möglichkeit, die Daten der jeweiligen Hinweisnachricht 'MMS Notification" über das Vorliegen von Push- Nachrichten an die davon betroffenen Empfangs-Teilnehmer- gerate zu übermitteln, besteht darin, dass die zu übermittelnden Daten der 'MMS Notification"-Hinweisnachricht in einer Short Message oder mehreren Short Messages des Short Messaging Service (SMS) an das Endgerät des jeweiligen Empfängers gesendet werden. Mit anderen Worten heißt das: indes- tens eine Short Message wird als Transportcontainer für die
Zustellung einer 'MMS Notification" verwendet. Eine nach WAP- 209-MMS Encapsulation; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0 formatierte 'MMS Notification" - Hinweisnachricht wird im Fall von MMS als Träger für die Push-Funktionalität mit UDH (User Data Headers)- und WSP (Wi- reless Session Protocol)- Kopf-Feldern versehen und in die jeweils 140 Bytes großen Transportcontainer des SMS (Short Message Service) geschrieben. Eine Short Message (SM) ist insgesamt 160 Bytes lang, besitzt aber selbst einen Kopfteil von 20 Bytes, so dass pro Short Message nur 140 Bytes als
'Payload", d.h. Laderaum für die im Push-Modus zu übertragenden Daten übrig bleiben.
Ohne Sicherheitsmaßnahmen wäre dadurch die Gefahr eines et- waigen Missbrauchs gegeben. Denn der jeweilige Empfänger einer mittels SMS empfangenen und korrekt formatierten 'MMS Notification" -Hinweisnachricht kann nicht erkennen, ob es sich bei den empfangenen Daten tatsächlich um eine Benachrichtigung seines MMS- Providers über eine neu eingetroffene und zum Download bereitliegende Multimedia Message handelt. Die via SMS empfangenen Daten könnten aber auch lediglich ein korrekt formatierter Datensatz sein, mit dem eine 'MMS Notification" -Hinweisnachricht vorgetäuscht werden soll, und der in Wirklichkeit von einem anderen Absender (Push-Initiator) als dem eigentlich erwarteten MMS -Relay/Server stammt. Dieser andere Absender könnte den URI (also die Referenz auf ei- nen Speicherplatz, die eigentlich für den Download der Multimedia Message vorgesehen ist) in einer vorgetäuschten 'MMS Notification"-Hinweisnachricht dazu benutzen, um den Download von unerwünschten Inhalten wie z.B. Werbung auf das mobile Endgerät des jeweiligen Kommunikationsnetzteilnehmers einzu- leiten. Dieses sogenannte 'Spamming" ist besonders im Fall von 'immediate retrieval" im Multimedia Messaging Service (MMS) für den jeweiligen Empfänger ärgerlich, weil sein Endgerät in diesem Modus automatisch die Referenz in der 'MMS Notification" -Hinweisnachricht auflöst und den Download- Prozess zum Herunterladen der Multimedia Message vom zugeordneten MMS -Relay/Server selbständig, d.h. ohne Benutzerabfrage einleitet.
Um nun für die jeweiligen Benutzer eines Teilnehmergerätes eines Kommunikationsnetzwerkes sicherzustellen, dass netzwerkseitig bereitgestellte Daten bzw. Nachrichten aus einer für den jeweiligen Benutzer vertrauenswürdigen Datenquelle stammen, wird eine datenquellenspezifische Kennzeichnung von Push-Nutzdatendadurch vorgenommen, dass diese Push- Nutzdatenim Multimedia Messaging -Relay/Server oder im Push- Proxy-Gateway teilweise oder ganz mit Hilfe eines asymmetrischen Kryptographieverfahrens mit mindestens einer Signatur versehen werden. Auf diese Weise werden bei jedem Versenden einer Push-Nachricht deren Push-Nutzdaten mit einer eindeuti- gen Kennung versehen, die eine Authentifizierung des versendenden Relay/Servers erlaubt. 'MMS Notification" - Hinweisnachrichten auf bereitgestellte Inhalte anderer Provi- der können somit bereits vorab im jeweiligen MMS User Agent erkannt und ignoriert werden, was einem Herausfiltern bzw. einer Aussortierung unerwünschter Daten entspricht. Ein Herunterladen unerwünschter Inhalte vom jeweiligen Server wird 5 dadurch weitgehend vermieden.
' ' Mit anderen Worten heißt das, dass die Überprüfung des Absenders einer Push-Nachricht durch Verifizierung einer digitalen Signatur vorgenommen wird. Dazu signiert der Multimedia Mes- 0 saging -Relay/Server und/oder auch das nachgeschaltete Push- Proxy-Gateway mit einem privaten kryptographischen Schlüssel
a) einen Teil der Push-Nutzdaten (bei MMS z.B. die Referenz auf den Speicherplatz, wo die Daten der Push-Nutzdaten 5 abgelegt sind) der jeweilig versandten oder der zu versendenden Push-Nachricht, oder
b) den gesamten Satz von Push-Nutzdaten (bei MMS z.B. die komplette 'MMS Notification" -Hinweisnachricht) der jewei- 0 lig versandten oder der zu versendenden Push-Nachricht.
Die dabei erzeugte Signatur, insbesondere in Form eines sogenannten Hash-Wertes, wird dabei vom Relay/Server und/oder dem Push-Proxy-Gateway an das Endgerät des jeweiligen Empfängers 5 im- Push-Modus
a) entweder (z.B. in einem neuen Kopffeld) innerhalb der Push-Nutzdaten übertragen (z.B. innerhalb einer 'MMS Notification" -Hinweisnachricht) , oder 0 b) zusätzlich zu den signierten 'Push-Nutzdaten" in einem neuen UDH- oder WSP-Kopffeld an das Endgerät des jeweiligen Empfängers im Push-Modus übertragen.
5 Im Endgerät wird selbst dann der öffentliche, kryptographi- sche Schlüssel des asymmetrischen Kryptographieverfahrens des MMS - Providers zur Verifizierung der in oder mit den Push- Nutzdaten mitgelieferten Signatur benutzt. Auf diese Weise kann im Telekommunikationsendgerät eines Empfängers überprüft werden, ob die im Push-Modus empfangenen Daten tatsächlich von seinem eigenen MMS -Provider stammen, d.h. das Endgerät hat nunmehr praktisch eine verlässliche Herkunftsfilterfunktionalität. Somit wird besonders für den Fall des 'immediate retrieval" des jeweiligen Teilnehmergeräts, insbesondere Funkkommunikationsgeräts, verhindert, dass unerwünschte Inhalte unter Benutzung nicht vertrauenswürdiger URLs automa- tisch (d.h. ohne Abfrage des Benutzers) auf das jeweilige Endgerät geladen werden.
Zur verlässlichen, empfangsseitigen Überprüfung von Push- Nutzdaten, insbesondere zur Überprüfung von im Push-Modus eintreffenden 'MMS Notification"-Hinweisnachrichten, werden also die Mechanismen der asymmetrischen Kryptographie im Multimedia Messaging -Relay/Server und/oder Push-Proxy-Gateway eingesetzt, um die im Push-Modus zu übermittelnden Nutzdaten teilweise oder ganz zu signieren. Die Signatur der jeweiligen Push-Nutzdaten/Push-Nachricht wird dabei wahlweise im Push- Initiator des Multimedia Messaging Relay/Servers oder in dessen zugeordnetem Push-Proxy-Gateway mit einem privaten Schlüssel des Service Providers bzw. Netzwerkbetreibers durchgeführt, während die Verifizierung der Signatur im je- weiligen Telekommunikationsendgerät mit dem passenden öffentlichen Schlüssel des Service Providers bzw. • Netzwerkbetreibers erfolgt. Dieser öffentliche Schlüssel kann entweder in einem internen Speicherbereich des jeweiligen Endgerätes oder in einer externen Speichereinheit abgelegt sein, die mit dem Endgerät über Kabel oder drahtlos verbunden werden kann.
In vorteilhafter Weise lässt sich das Speichern des öffentlichen kryptographischen Schlüssels auf einer intelligenten Speicherkarte, insbesondere einer sogenannten Smartcard wie z.B. einer SIM-Karte (SIM = Subscriber Identity Module) oder einer UICC (UICC = Universal Integrated Circuit Card) mit (U)SIM ((UMTS) subscriber identity module) als externer Spei- chereinheit vornehmen, die in das mobile Endgerät eingelegt oder eingesteckt wird. Auf diesen Karten gibt es nämlich Speicherbereiche, die ausschließlich vom Netzwerkbetreiber beschrieben bzw. aktualisiert werden können, und solche, für die auch der Benutzer Schreib- und Leserechte hat. Die erstgenannten Speicherbereiche, die ausschließlich dem jeweiligen Netzbetreiber reserviert sind, eignen sich besonders gut für das Speichern und nachträgliche OTA-Aktualisieren (OTA = Over The Air) von öffentlichen kryptographischen Schlüsseln. Bei- spielsweise kann der Service Provider bzw. Netzbetreiber auf diese Weise die Schlüssellänge in einfacher Weise erhöhen, um neuen Sicherheitsanforderungen entsprechen zu können. Gemäß einer zweckmäßigen AusführungsVariante wird eine bereits bestehende Applikation auf der SIM-Karte wie z.B. die SAT- Applikation (SAT = SIM Application Tool Kit) oder auf der UICC mit (U) SIM-Karte wie z.B. CAT (Card Application Tool Kit) bzw. (U) SAT-Applikation ( (U) SAT = UMTS SIM Application Tool Kit) zur Verifizierung der Signatur der Push-Nutzdaten benutzt.
Figur 6 zeigt beispielhaft eine 'MMS Notification" - Hinweisnachricht in textueller Kodierung im MMS. In der dazugehörigen binären Kodierung nach WAP-209-MMS Encapsulation; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0 erhält man einen Datenblock von etwa 100 Bytes. Wird diese 'MMS Notification" -Hinweisnachricht als Push-Nutzdaten via SMS an einen Empfänger übermittelt, so werden diesem Datenblock noch einige WSP- und UDH-Kopf-Felder von insgesamt etwa 35 Bytes Länge vorangestellt. Die gesamte zu übertragende Da- tenmenge summiert sich somit in diesem Beispiel auf etwa 135 Bytes, was noch nicht zuviel Payload für eine einzelne Short Message wäre. Bei größeren Datenmengen, insbesondere von mehr als 140 Bytes, werden zweckmäßigerweise mehrere Short Messages entsprechend der Spezifikation 3GPP TS 23.040 version 5.2.0, Release 5; Third Generation Partnership Project; Technical Specification Group Terminals; Technical realization of the Short Message Service (SMS) zur Übertragung der 'MMS Notification" -Hinweisnachricht miteinander verkettet.
Die datenquellenspezifische Kennzeichnung der 'MMS Notification" -Hinweisnachricht im MMS, die zum Herunterladen abholbereiter Push-Nachrichten vom MMS Relay/Server an ein oder mehrere adressierte Kommunikationseinheiten von Teilnehmergeräten geschickt wird, kann zweckmäßigerweise auf folgende vier verschiedene Möglichkeiten vorgenommen werden:
Ausführungsbeispiel 1:
Es wird nur ein Teil der 'MMS Notification"-Hinweisnachricht mit Hilfe des asymmetrischen Kryptographieverfahrens sig- niert. Insbesondere wird die Referenzzeile auf den URI (URI = Uniform Resource Identifier) , der die Verknüpfung zu dem Speicherplatz mit der bereitliegenden Multimedia Message bezeichnet, mit einer Signatur versehen. Dabei folgt die Signatur vorzugsweise im Push-Initiator desjenigen MMS Re- lay/Server, der Multimedia-Nachrichten (MMs=multimedia essa- ges) zum Abruf durch eine Vielzahl zugeordneter MMS User A- gents in Teilnehmergeräten des Kommunikationsnetzes bereithält. Dabei wird die Signatur als Erweiterung bzw. Extension an die URI-Referenz angehängt. Dies veranschaulicht beispiel- haft die MMS Notification-Hinweisnachricht MNl* von Figur 7, die gegenüber der MMS Notification-Hinweisnachricht MNl dahingehend modifiziert worden ist, dass jetzt in der X-MMS- Content-Location-Zeile nach dem URL-Eintrag 'http://siemens.de/sal/mms-id" eine Signatur in Form eines Hashwertes HW angehängt worden ist.
Möchte also ein MMS -Provider wie z.B. SPA von Figur 5 die in Figur 6 dargestellte 'MMS Notification" -Hinweisnachricht an einen seiner Kunden übermitteln, so signiert er aus Sicher- heitsgründen den Eintrag, d.h. den Feldwert des Kopffeldes 'X-MMS-Content-Location' http: //siemens .de/sal/mms-id mit seinem privaten kryptographischen Schlüssel. Das Ergebnis dieser Signatur ist beispielsweise ein Hashwert HW, der als Zusatz bzw. Extension an den bisherigen Feldwert (d.h. dem eigentlichen URL) des Kopffeldes X-MMS-Content-Location am Ende angeheftet wird. Im jeweiligen Empfangsterminal wird dann zunächst dieser Hashwert HW vom restlichen Feldwert (d.h. vom eigentlichen URI) des Kopffeldes X-MMS-Content- Location separiert. Anschließend wird die Signatur HW mit Hilfe des öffentlichen kryptographischen Schlüssels des MMS Providers im Endgerät selbst verifiziert. Der öffentliche kryptographische Schlüssel des MMS Providers kann dazu beispielsweise von einer externen Speichereinheit eingelesen werden.
Ausführungsbeispiel 2:
Auch in diesem Ausführungsbeispiel wird lediglich ein Teil der Push-Nutzdaten mit einer Signatur versehen. Insbesondere wird lediglich der URL der jeweiligen Push-Nachricht mit ei- nem privaten Schlüssel im MMS-Relay/Server kodiert. Allerdings wird jetzt im Unterschied zum Ausführungsbeispiel 1 ein eigenes Kopffeld zur ursprünglichen MMS Notification- Hinweisnachricht MNl wie z.B. MNl von Figur 6 hinzugefügt. Eine solche MMS Notification-Hinweisnachricht MNl, die zu- sätzlich ein eigenes Feld bzw. eine eigene Steuerzeile für die Signatur wie z.B. HW aufweist, ist in der Figur 8 in textueller Kodierung gezeigt und mit MNl** bezeichnet. Sie geht aus der ursprünglichen MMS Notification-Hinweisnachricht MNl von Figur 6 dadurch hervor, dass im MMS Relay/Server in einer eigenen Steuerzeile X-MMS-Signature eine digitale Signatur in Form eines Hashwertes am Ende hinzugefügt worden ist. Analog zu dem im Ausführungsbeispiel 1 beschriebenen Vorgehen erzeugt also das Signieren des Feldwertes des Kopffeldes X-MMS- Content-Location einen Hashwert HW. Dieser wird nun aller- dings nicht an den Feldwert des Kopfwertes X-MMS-Content- Location herangehängt, sondern in einem eigens dafür definierten Kopffeld X-MMS-Signature in die MMS Notification- Hinweisnachricht eingebunden. Bei der mit dem privaten Schlüssel versehenen MMS Notification-Hinweisnachricht MNl** von Figur 8 ist das Kopffeld mit der Signatur am Ende der Nachricht hinzugefügt. Genauso kann es aber auch zweckmäßig sein, dieses Kopffeld mit der Signatur an anderer Stelle in die textuelle Kodierung der MMS Notification-Hinweisnachricht MNl von Figur 6 einzufügen.
Ausführungsbeispiel 3:
Weiterhin kann es zweckmäßig sein, die kompletten Push- Nutzdaten mit einer Signatur eines asymmetrischen Kryptographieverfahrens zu versehen. Handelte es sich bei den Push- Nutzdaten um eine 'MMS Notification" -Hinweisnachricht im MMS, so wird also die gesamte 'MMS Notification" -Hinweisnachricht mit dem privaten Schlüssel eines asymmetrischen Kryptographieverfahrens insgesamt versehen. Auch dabei erfolgt die Signatur zweckmäßigerweise im jeweiligen MMS Relay/Server. Zur Verschlüsselung der gesamten Push-Nutzdaten ist es zweck- mäßig, für die Signatur mindestens ein Kopffeld vorzusehen, das den signierten Push-Nutzdaten vorangestellt wird. Die Push-Nutzdaten selbst bleiben dabei unverändert. Werden die jeweiligen Push-Nutzdaten insbesondere durch eine ' MMS Notification" -Hinweisnachricht gebildet, so wird wie im ersten Ausführungsbeispiel ein Hashwert HW erzeugt. Dieser wird nun allerdings nicht an den Feldwert des Kopffeldes X-MMS- Content-Location wie im Ausführungsbeispiel 1 herangehängt, und auch nicht in einem Kopffeld innerhalb der Push-Nachricht wie im Ausführungsbeispiel 2 transportiert, sondern in eines der UDH- oder WSP-Kopffeider, die den eigentlichen Push- Nutzdaten, wie weiter vorstehend erläutert, vorangestellt. Gegebenenfalls kann es auch zweckmäßig sein, dazu extra neue UDH- oder WSP-Kopffeider zu definieren.
Ausführungsbeispiel 4: Weiterhin kann es zweckmäßig sein, die jeweilige Push- Nachricht zusammen mit Steuerbefehlen vom Push-Initiator des jeweiligen MMS- Relay/Servers mittels des WAP PAP an das zugeordnete Push-Proxy-Gateway zur dortigen Signatur zu schi- cken, d.h. die Signatur der jeweiligen Push-Nutzdaten erfolgt erst im Push-Proxy-Gateway. Die Push-Nutzdaten selbst bleiben auf der Schnittstellenseite des PAP, d.h. im Bereich der Schnittstelle SB entsprechend der Architektur der Figuren 3, 4 unverändert. Es werden also die jeweiligen Push-Nutzdaten erst vom jeweiligen Push-Proxy-Gateway und nicht vom die
Push-Nachricht absendenden MMS -Relay/Server signiert. Dazu werden zweckmäßigerweise zusätzliche Steuerbefehle für die Control Entity, das ist ein in XML-kodierter Datensatz, welcher den eigentlichen Push-Nutzdaten im WAP PAP vorangestellt werden, definiert.
Demgegenüber hat das Signierverfahren mit Hilfe eines asymmetrischen Kryptographieverfahrens im jeweiligen MMS- Relay/Server wie z.B. entsprechend den Ausführungsbeispielen 1 mit 3 den Vorteil, dass dort in der Regel über mehr Rechenleistung als in einem Gateway zur Verfügung steht und zudem die über die beiden Schnittstellen SA, SB von Figur 4 transportierten Push-Nutzdaten lückenlos datenquellenspezifisch gekennzeichnet werden können. Dadurch sind Sicherheitslücken gegenüber dem Ausführungsbeispiel 4 besser vermieden. Denn die über beide Schnittstellen SA, SB geschickten Push- Nutzdaten sind für beide Schnittstellen mit einem privaten Schlüssel eines asymmetrischen Kryptographieverfahrens versehen, d.h. die Signatur bleibt unverändert.
Ggf. kann es auch zweckmäßig sein, sowohl im jeweiligen MMS- Relay/Server und im jeweilig nachgeschalteten Gateway eine asymmetrische Kryptographieverschlüsselung von Push-Nutzdaten vorzunehmen.
Durch die erfindungsgemäße datenquellenspezifische Kennzeichnung von Push-Nutzdaten mit Hilfe eines asymmetrischen Kryp- tographieverfahrens wird somit erreicht, dass lediglich authentifizierte Push-Nutzdaten im Teilnehmergerät weiterverarbeitet werden, während Push-Nutzdaten unautorisierter Absender herausgefiltert und verworfen werden. Da lediglich für authentifizierte Push-Nutzdaten im Push-Modus z.B. im Fall eines Funkkommunikationsnetzes eine WSP (Wireless Session Protocol) oder HTTP-Verbindung (HTTP = Hypertext Transfer Protocol) aufgebaut wird, wird ein unerwünschtes (automatisches) Anfordern von Inhalten , die von unidentifizierbaren Dritten stammen, wirksam unterbunden. Der jeweilige Empfänger von Push-Nutzdaten kann somit stets sicher sein, dass nur Push-Nutzdaten aus einer ihm vertrauenswürdigen Datenquelle zum Anfordern der Inhalte herangezogen werden.
Gegenüber dem erfindungsgemäßen Verfahren wäre besonders folgende Übertragungsmöglichkeit von Nutzdaten im Push-Modus nachteilig: würde eine bestehende WSP- oder HTTP-Verbindung (WSP - Wireless Session Protocol) entsprechend der Spezifikation WAP-230-WSP Wireless Session Protocol Specification, ap- proved version 5-July-2001, (HTTP = Hypertext Transfer Protocol, RFC 2616 'Hypertext Transfer Protocol- HTTP/1.1"; June 1999) zwischen dem jeweiligen Telekommunikationsendgerät und dem zugeordneten MMS Relay/Server zur Übertragung von Daten im Push-Modus verwendet, so würde dazu das Push-Proxy-Gateway zunächst den Aufbau einer WSP- oder HTTP-Sitzung durch das Telekommunikationsendgerät veranlassen. Dies würde durch Ü- bertragung eines SIR (SIR -Session Initiation Request) vom Push-Proxy-Gateway an den Push-Client auf dem Empfangsgerät wiederum mittels SMS durchgeführt werden. Nach Empfang des SIR könnte der Push-Client dann eine WSP oder HTTP-Verbindung zwischen dem Telekommunikationsendgerät und dem Push- Initiator aufbauen. Die WSP- und HTTP-Verbindungen würden zwar eine einigermaßen verlässliche Authentifizierung des Push-Initiators ebenfalls erlauben, hätten aber insbesondere den Nachteil, dass für jede Übertragung von Nutzdaten im Push-Modus (beispielsweise in Form einer MMS Notification) eigens eine WSP- oder HTTP-Verbindung aufgebaut werden müss- te. Dies ist insbesondere im Roaming-Fall mit meist hohen zusätzlichen Kosten für den Empfänger verbunden und deshalb in der Praxis in der Regel nicht akzeptabel.
Das erfindungsgemäße Verfahren zur datenspezifischen Kennzeichnung von Push-Nutzdaten ermöglicht hingegen in vorteilhafter Weise, dass ohne SIR und anschließenden WSP- bzw. HTTP-Verbindungsaufbau die jeweilige 'MMS-Notification" - Hinweisnachricht in mindestens einer Short Message zusammen mit der Signatur, insbesondere dem Hashwert, des asymmetrischen Kryptographieverfahrens untergebracht werden kann.

Claims

Patentansprüche
1. Verfahren zur datenquellenspezifischen Kennzeichnung von Push-Nutzdaten (PNU) in einem Kommunikationsnetzwerk (CN) , die ausgehend von mindestens einem Push-Initiator
(Pl) über mindestens ein Push-Proxy-Gateway (PPG) an mindestens einen Push-Client (PC) ohne dessen vorherige Aufforderung geschickt werden, indem im Push-Initiator (Pl) oder im Push-Proxy-Gateway (PPG) ein Teil der oder die gesamten Push-Nutzdaten (PNU) mit Hilfe eines asymmetrischen Kryptographieverfahrens mit mindestens einer Signatur (HW) versehen werden.
2. Verfahren nach Anspruch 1, dadurch ge ennzeichnet, dass die Signatur (HW) innerhalb der Push-Nutzdaten (PNU) übertragen wird.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Signatur (HW) zusätzlich zu den Push-Nutzdaten (PNU) in mindestens einem eigenen Kopffeld übertragen wird, das den Push-Nutzdaten (PNU) vorausgestellt und/oder nachgeordnet wird.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Push-Nutzdaten (PNU) durch eine 'MMS Notification" -Nachricht (MNl) (MMS = Multimedia Messaging Service) gebildet werden, durch die der Kommunikationseinheit (UA) angezeigt wird, dass eine Multimedianachricht zur Abholung netzwerkseitig bereitgehalten wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Kommunikationseinheit (UA) , an die die jeweiligen Push-Nutzdaten (PNU) vom jeweilig zugeordneten Push- Initiator (Pl) geschickt werden, in einem Teilnehmergerät eines Funkkommunikationsnetzwerks verwendet wird.
6. Kommunikationsnetzwerk (CN) mit mindestens einer Vorrichtung zur datenquellenspezifischen Kennzeichnung von Push- Nutzdaten (PNU) nach einem der vorhergehenden Ansprüche.
PCT/DE2003/002535 2002-08-13 2003-07-28 Verfahren sowie vorrichtung zur datenquellenspezifischen kennzeichnung von push-nutzdaten Ceased WO2004021663A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10237131.8 2002-08-13
DE10237131A DE10237131A1 (de) 2002-08-13 2002-08-13 Verfahren sowie Vorrichtung zur datenquellenspezifischen Kennzeichnung von Push-Nutzdaten

Publications (1)

Publication Number Publication Date
WO2004021663A1 true WO2004021663A1 (de) 2004-03-11

Family

ID=30775237

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2003/002535 Ceased WO2004021663A1 (de) 2002-08-13 2003-07-28 Verfahren sowie vorrichtung zur datenquellenspezifischen kennzeichnung von push-nutzdaten

Country Status (2)

Country Link
DE (1) DE10237131A1 (de)
WO (1) WO2004021663A1 (de)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006005252A1 (en) * 2004-07-09 2006-01-19 Huawei Technologies Co., Ltd. Processing method for push notification in multimedia messaging service
WO2007115448A1 (en) * 2006-03-31 2007-10-18 Zte Corporation A method for realizing multimedia message signature service
WO2009138825A1 (en) * 2008-05-12 2009-11-19 Sony Ericsson Mobile Communications Ab Secure push messages
EP2890074A1 (de) * 2013-12-31 2015-07-01 Gemalto SA Verfahren zur Übertragung von Push-Nachrichten
CN105959279A (zh) * 2016-04-29 2016-09-21 大连理工大学 一种基于加密处理的计算机信息传输系统及方法

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2867651B1 (fr) * 2004-03-09 2006-05-19 Sagem Procede de transmission d'informations par mms et telephones associes
CN100372391C (zh) * 2004-08-16 2008-02-27 华为技术有限公司 一种多媒体消息系统及转发多媒体消息的方法
KR101376883B1 (ko) * 2007-03-05 2014-03-21 엘지전자 주식회사 통지 메시지 이전 방법 및 단말기

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4003386C1 (de) * 1990-02-05 1991-05-23 Siemens Ag, 1000 Berlin Und 8000 Muenchen, De
WO2000079724A2 (en) * 1999-06-18 2000-12-28 Nokia Mobile Phones Limited Wim manufacturer certificate

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4003386C1 (de) * 1990-02-05 1991-05-23 Siemens Ag, 1000 Berlin Und 8000 Muenchen, De
WO2000079724A2 (en) * 1999-06-18 2000-12-28 Nokia Mobile Phones Limited Wim manufacturer certificate

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"WAP Push Architectural Overview", WIRELESS APPLICATION PROTOCOL WAP-250-PUSHARCHOVERVIEW-20010703-P, pages 1 - 24, XP002260861, Retrieved from the Internet <URL:www.wapforum.org> [retrieved on 20031106] *
"Wireless Application Protocol MMS Encapsulation Version 05-Jan-2002", WIRELESS APPLICATION PROTOCOL WAP-209-MMSENCAPSULATION-20020105-A, pages 1 - 39, XP002260862, Retrieved from the Internet <URL:www.wapforum.org> [retrieved on 20021210] *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006005252A1 (en) * 2004-07-09 2006-01-19 Huawei Technologies Co., Ltd. Processing method for push notification in multimedia messaging service
CN100349474C (zh) * 2004-07-09 2007-11-14 华为技术有限公司 一种多媒体消息业务中推送通知的处理方法
RU2339185C1 (ru) * 2004-07-09 2008-11-20 Хуавэй Текнолоджиз Ко., Лтд. Способ обработки уведомления активной доставки в службе мультимедийных сообщений
US7899476B2 (en) 2004-07-09 2011-03-01 Huawei Technologies Co., Ltd. Method for processing push notification in multimedia message service
WO2007115448A1 (en) * 2006-03-31 2007-10-18 Zte Corporation A method for realizing multimedia message signature service
US8069261B2 (en) 2006-03-31 2011-11-29 Zte Corporation Method for realizing multimedia message signature service
WO2009138825A1 (en) * 2008-05-12 2009-11-19 Sony Ericsson Mobile Communications Ab Secure push messages
CN102017567A (zh) * 2008-05-12 2011-04-13 索尼爱立信移动通讯有限公司 安全推送消息
EP2890074A1 (de) * 2013-12-31 2015-07-01 Gemalto SA Verfahren zur Übertragung von Push-Nachrichten
WO2015101544A1 (en) * 2013-12-31 2015-07-09 Gemalto Sa Method for transmitting push messages
CN105959279A (zh) * 2016-04-29 2016-09-21 大连理工大学 一种基于加密处理的计算机信息传输系统及方法

Also Published As

Publication number Publication date
DE10237131A1 (de) 2004-02-26

Similar Documents

Publication Publication Date Title
DE69931344T2 (de) Nachrichtenverarbeitungsverfahren und system in einem telekommunikationssystem
EP1327341A2 (de) Verfahren zum übermitteln von kurznachrichten über das internet
EP1230815A1 (de) Verfahren und system zur ausarbeitung und übermittlung von sms-meldungen in einem mobilfunknetz
DE10239061A1 (de) Verfahren zum Übertragen von Nutzdatenobjekten
EP1358742A2 (de) Verfahren zur nachrichtenversendung aus einem mms-system und einrichtung hierfür
WO2002063839A2 (de) Verfahren und vorrichtung zur manipulation übertragener nachrichten
EP1415488B1 (de) Verfahren zur übertragung von daten
EP1678962B1 (de) Verfahren zum übertragen von verschlüsselten nutzdatenobjekten
EP1632065A1 (de) Verfahren zum übertragen von nachrichten in einem auf mms basierten kommunikationssystem
EP1576848B1 (de) Verfahren zur bereitstellung von kostenpflichtigen diensten sowie nutzeridentifikationsvorrichtung und einrichtung zum bereitstellen der dienste
DE602005004721T2 (de) Verfahren zur Verwaltung von verdoppelten Nachrichtenmeldungen in multimedialen Benachrichtigungsdiensten
EP1680903B1 (de) Verfahren zum bertragen von verschl sselten nutzdateno bjekten
EP1588573A1 (de) Verfahren und system zum einf gen eines multimedia-nachricht -mehrfachelements in eine multimedia-nachricht
WO2004021663A1 (de) Verfahren sowie vorrichtung zur datenquellenspezifischen kennzeichnung von push-nutzdaten
WO2002100063A1 (de) Verfahren zur handhabung einer nachricht mit multimedialem bezug
DE102004037338B4 (de) Kommunikationssystem, Verfahren zum Steuern eines Kommunikationssystems, Server, Verfahren zum Betreiben eines Servers, Kommunikationsendgerät und Verfahren zum Betreiben eines Kommunikationsendgeräts
EP2247086A1 (de) Verfahren, Vorrichtungen und Softwareprogramme zur Informationsflusserweiterung bei der Übertragung einer Nachricht
DE602004002926T2 (de) Auswahl eines datenübertragungsverfahrens
DE102006001503B4 (de) Verfahren und System zum Übermitteln von Zusatzdaten
EP1493295B1 (de) Verfahren zur bertragung von daten, insbesondere mit multim edialen inhalten, in einem mobilfunknetz
EP1832132B1 (de) System und verfahren zur vermittlung von daten zwischen einem datenanbieter und einem mobilfunkendgerät
DE60106473T2 (de) Verfahren und system zur informationsübertragung
EP1520438A1 (de) Mms-nachrichten bertragungsverfahren und -system
DE102005015385A1 (de) Verfahren zum Umleiten mindestens einer Multimedianachricht in einem Mobilfunk-Kommunikationsnetzwerk, Multimedianachricht-Relaiseinrichtungen, Zentral-Mobilfunk-Servereinheit und Mobilfunk-Kommunikationsendgerät-Speicherelement
DE60210180T2 (de) Verfahren zur Nachrichtenübermittlung an eine elektronische Kommunikationseinrichtung

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR

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

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP