DE10151213A1

DE10151213A1 - Verfahren zum Genehmigen von Zahlungen in einem Kommunikationsnetz

Info

Publication number: DE10151213A1
Application number: DE10151213A
Authority: DE
Inventors: Karsten Luettge
Original assignee: Siemens AG
Current assignee: Nokia Solutions and Networks GmbH and Co KG
Priority date: 2001-10-15
Filing date: 2001-10-15
Publication date: 2003-04-24
Anticipated expiration: 2021-10-16
Also published as: WO2003036527A2; WO2003036527A3; US20040249751A1; JP2005506636A; DE10151213B4

Abstract

Die Erfindung betrifft ein Verfahren zum Genehmigen von Zahlungen in einem Kommunikationsnetz, bei dem nach Abforderung eines zu bezahlenden Dienstes durch ein Kommunikationsendgerät eines Dienstnutzers von dem Kommunikationsendgerät zur Genehmigung einer den Dienst betreffenden Zahlung eine Genehmigungsnachricht zu einem Zahlungsdienstleister übertragen wird, daraufhin von dem Zahlungsdienstleister eine individuelle Genehmigungskennung in einem Speicher abgelegt wird, die Genehmigungskennung zu der Diensterbringereinrichtung übertragen wird, daraufhin von der Diensterbringereinrichtung eine die Genehmigungskennung enthaltende Zahlungsanforderungsnachricht an den Zahlungsdienstleister gesendet wird und von dem Zahlungsdienstleister die Zahlung als genehmigt erkannt wird, wenn die Genehmigungskennung der Zahlungsanforderungsnachricht in dem Speicher vorliegt.

Description

Die Erfindung betrifft ein Verfahren zum Genehmigen von Zahlungen in einem Kommunikationsnetz. Mit zunehmender Etablierung des "E-Commerce" werden immer häufiger kostenpflichtige Dienste (z. B. Lieferung von Informationen, Daten oder Waren) über Kommunikationsnetze angeboten. Als derartige Kommunikationsnetze werden beispielsweise das Internet oder Telekommunikationsnetze (Mobilfunknetze, Festnetze) genutzt. Zur Bezahlung der Dienste werden Verfahren beispielsweise für das sog. "Mobile Payment" oder "Internet Payment" benötigt. Mit "Mobile Payment" ist das bargeldlose Bezahlen unterwegs unter Nutzung des Handys, mit "Internet Payment" das bargeldlose Bezahlen von Dienstleistungen, die über das Internet bezogen oder zumindest bestellt werden, gemeint.
Gerade kleinere Dienstanbieter führen die relativ aufwendigen Zahlungsvorgänge nicht selbst aus, sondern bedienen sich der Hilfe von Zahlungsdienstleistern, sog. "Payment Service Providern". An derartigen Zahlungsvorgängen sind also i. allg. ein Dienstnutzer (Kunde, Consumer), ein Dienstanbieter (Service Provider, Merchant) und der Zahlungsdienstleister beteiligt. Es muß hierbei insb. sichergestellt werden, dass vor Ausführung eines Zahlungsvorganges durch den Zahlungsdienstleister dieser Zahlungsvorgang von dem Dienstnutzer genehmigt (authorisiert) wird (Zahlungs-Authorisierung).
Es ist Aufgabe der vorliegenden Erfindung, ein Verfahren anzugeben, mit dem auf einfache und zuverlässige Art und Weise von einem Zahlungsdienstleister zu organisierende Zahlungen von einem Dienstnutzer genehmigt werden können.
Diese Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren zum Genehmigen von Zahlungen in einem Kommunikationsnetz, bei dem nach Abforderung eines zu bezahlenden Dienstes durch ein Kommunikationsendgerät eines Dienstnutzers

- von einer dem Dienst zugeordneten Diensterbringereinrichtung eine Kommunikationsadresse eines Zahlungsdienstleisters zu dem Kommunikationsendgerät übertragen wird,
- von dem Kommunikationsendgerät zur Genehmigung einer den Dienst betreffenden Zahlung eine Genehmigungsnachricht zu dem Zahlungsdienstleister übertragen wird,
- daraufhin von dem Zahlungsdienstleister eine individuelle Genehmigungskennung in einem Speicher abgelegt wird,
- die Genehmigungskennung zu dem Kommunikationsendgerät übertragen wird,
- von dem Kommunikationsendgerät die Genehmigungskennung zu der Diensterbringereinrichtung übertragen wird,
- daraufhin von der Diensterbringereinrichtung eine die Genehmigungskennung enthaltende Zahlungsanforderungsnachricht an den Zahlungsdienstleister gesendet wird, und von dem Zahlungsdienstleister die Zahlung als genehmigt erkannt wird, wenn die Genehmigungskennung der Zahlungsanforderungsnachricht in dem Speicher vorliegt.

Vorteilhafterweise wird hierbei die Genehmigungsnachricht zu dem Zahlungsdienstleister übertragen, bevor dieser von der Diensterbringereinrichtung die Zahlungsanforderungsnachricht erhält. Daher kann der Zahlungsdienstleister sehr schnell nach Eintreffen der Zahlungsanforderungsnachricht die Zahlung veranlassen, sofern eine einfach und schnell von ihm durchführbare Speicherabfrage ein Vorliegen der entsprechenden Genehmigungskennung in seinem Speicher ergibt.
Das erfindungsgemäße Verfahren kann so ausgestaltet sein, dass von der Diensterbringereinrichtung die Kommunikationsadresse zusammen mit Zahlungsinformationen zu dem Kommunikationsendgerät übertragen wird,

- daraufhin von dem Kommunikationsendgerät eine Genehmigungs-Startnachricht an den Zahlungsdienstleister übertragen wird,
- von dem Zahlungsdienstleister der Dienstnutzer zu einer Genehmigungshandlung aufgefordert wird, und
- bei erfolgter Genehmigungshandlung von dem Kommunikationsendgerät die Genehmigungsnachricht erstellt wird.

Hierbei ist insbesondere vorteilhaft, dass der Kontakt zwischen dem Kommunikationsendgerät und dem Zahlungsdienstleister auf Initiative des Kommunikationsendgerätes hergestellt wird (Genehmigungs-Startnachricht). Dies entspricht dem Sicherheitsinteresse des Dienstnutzers, der bezüglich der Zahlung oftmals nicht von einem ihm zunächst unbekannten Zahlungsdienstleister kontaktiert werden möchte.
Das erfindungsgemäße Verfahren kann so durchgeführt werden, dass der Dienstnutzer zu der Genehmigungshandlung aufgefordert wird, indem
vom Zahlungsdienstleister Anzeigedaten zu dem Kommunikationsendgerät übertragen werden, durch die auf einer Anzeige des Kommunikationsendgerätes mindestens Teile der Zahlungsinformationen angezeigt werden und durch die der Dienstnutzer zum Betätigen eines Bedienelementes des Kommunikationsendgerätes aufgefordert wird.
Vorteilhafterweise können zu dieser Übertragung und Anzeige auf Seiten des Kommunikationsendgerätes Mittel und Verfahren benutzt werden, die sowieso zur Durchführung von "E-Commerce"-Verfahren bei dem Kommunikationsendgerät vorhanden sind. So kann die Kommunikation mit einem Kommunikationsendgerät in Form eines Mobiltelefons z. B. unter Nutzung eines "Wireless Application Protocol" (WAP) genannten Kommunikationsprotokolls durchgeführt wird. Moderne Mobiltelefone sind heutzutage zur Benutzung des WAP-Protokolls in der Lage und verfügen über eine Vorrichtung (einen sog. WAP-Browser) zur Anzeige von per WAP übertragenen Daten und Nachrichten.
Mit einem Kommunikationsendgerät in Form eines am Internet angeschlossenen Rechners kann die Kommunikation z. B. unter Nutzung eines "Hypertext Transfer Protocol" (HTTP) genannten Kommunikationsprotokolls - das ist ein standardmässig im Internet benutztes Kommunikationsprotokoll - durchgeführt werden. Auf am Internet angeschlossenen Computern stehen sog. Web-Browser zur Anzeige von per HTTP übertragenen Daten und Nachrichten zur Verfügung.
Daher brauchen vorteilhafterweise zur Realisierung des erfindungsgemäßen Verfahren keine aufwendigen Erweiterungen oder Aufrüstungen an den Kommunikationsendgeräten vorgenommen werden, wodurch sich eine besonders einfache, Dienstnutzerfreundliche und kostengünstige Durchführung des erfindungsgemäßen Verfahrens erreichen lässt.
Bei dem Verfahren können zusammen mit der Genehmigungskennung Genehmigungsdaten in dem Speicher abgelegt werden. Somit können vorteilhafterweise bei dem Zahlungsdienstleister weitere Informationen über die erteilte Genehmigung gespeichert werden.
Bei dem bisher beschriebenen Verfahren kann als Genehmigungsdatum ein Verfallzeitpunkt in dem Speicher abgelegt und von dem Zahlungsdienstleister die Zahlung nur dann als genehmigt erkannt werden, wenn der Verfallzeitpunkt der im Speicher abgelegten Genehmigungskennung nicht überschritten ist.
Dadurch kann vorteilhaft die Sicherheit des Verfahrens erhöht werden, da spät eingehende Zahlungsanforderungsnachrichten (die evtl. auf unberechtigterweise von nicht am Verfahren teilnehmenden Stellen abgefangenen Genehmigungskennungen oder manipulierten Datenübertragungen beruhen, wodurch eine Verzögerung des Eintreffens der Zahlungsanforderungsnachrichten auftreten kann) erkannt und einer Sonderbehandlung zugeführt werden können.
Zur weiteren Erläuterung der Erfindung ist in
Fig. 1 eine schematische Darstellung eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens, und in
Fig. 2 eine Darstellung von Nachrichtenflüssen bei einem Ausführungsbeispiel des erfindungsgemäßen Verfahrens dargestellt.
In Fig. 1 sind ein Kommunikationsendgerät KEG eines Dienstnutzers, eine Diensterbringereinrichtung DEE und ein Zahlungsdienstleister ZDL dargestellt.
Bei dem dargestellten Ausführungsbeispiel des Verfahrens werden Dialoge zur Zahlungs-Authorisierung (Zahlungsgenehmigung) im Internet mittels der WWW- (World Wide Web-) Technologie, d. h. mittels des Hypertext Transferprotokolls (HTTP) und einer geeigneten Auszeichnungssprache (z. B. Hypertext Markup Language HTML) durchgeführt. Das Verfahren kann besonders vorteilhaft dann eingesetzt werden, wenn der zu bezahlende Dienst mittels WWW-Technologie erbracht wird, d. h. wenn der Dienst auf einem HTTP Server implementiert ist und HTTP und HTML für die Kommunikation mit dem Leistungsnutzer (Consumer) benutzt. Der Leistungsnutzer kann in diesem Fall die von ihm für die Dienstabforderung benutzten Einrichtungen und Programme (z. B. einen HTML-Browser) auch zum Genehmigen von Zahlungen einsetzen.
Der Leistungsnutzer kann also seinen normalerweise verwendeten HTML-Browser benutzen, um auf den Dienst der Diensterbringereinrichtung zuzugreifen. Der Diensterbringer (Merchant) setzt in der Diensterbringereinrichtung einen HTTP Server, wie z. B. Apache oder Microsoft IIS, ein, um den zu bezahlenden Dienst zu erbringen. Zwischen beiden besteht eine unter Benutzung des HTTP-Protokolls aufgebaute Verbindung (in der Figur mit "Nutzkanal" bezeichnet); eine derartige Verbindung wird auch als eine "virtuelle Verbindung" bezeichnet. Diese Verbindung wird mittels eines Kommunikationsnetzes KN hergestellt, welches das Internet Protokoll (IP) benutzt ("auf dem Internet Protokoll (IP) aufsetzt"). Über diese Verbindung erbringt der Merchant mittels HTTP den zu bezahlenden Dienst, der beispielsweise in der Zusendung von Daten (wie z. B. Nachrichten oder Börsenkursen) besteht.
Der Zahlungsdienstleister (Payment Service Provider) benutzt ein System, das ebenfalls einen HTTP Server enthält. Zwischen diesem HTTP Server und dem Consumer besteht ebenfalls eine (virtuelle) Verbindung, die über das IP-basierte Kommunikationsnetz KN hergestellt wird; zur Realisierung dieser Verbindung wird ebenfalls das Protokoll HTTP benutzt. Diese Verbindung ist in der Figur mit "Authorisierungskanal" bezeichnet. Über diese Verbindung läuft der Authorisierungsdialog (Genehmigungsdialog) zwischen dem Kommunikationsendgerät und dem Zahlungsdienstleister ab.
Das System des Zahlungsdienstleisters kommuniziert mit dem System (Diensterbringereinrichtung) des Diensterbringers (Dienstleisters) über eine (virtuelle) Verbindung, die in der Figur mit "Bezahlen" gekennzeichnet ist. Über diese Verbindung sendet die Diensterbringereinrichtung Zahlungsanforderungsnachrichten (Zahlungs-Anforderungen) an den Zahlungsdienstleister. Diese Verbindung kann auf beliebige Art und Weise unter Nutzung des Kommunikationsnetzes KN (wie in der Figur dargestellt) oder auch ohne Benutzung des Kommunikationsnetzes KN realisiert werden. Hierzu kann z. B. das sog. "Parlay Content Based Charging API" eingesetzt werden.
Wenn das oben im Zusammenhang mit der Fig. 1 dargestellte Verfahren in Verbindung mit Mobilkommunikationsnetzen (z. B. GSM-Netzen; GSM = Global System for Mobile Communication) eingesetzt werden soll, so sind am prinzipiellen Ablauf keine Änderungen notwendig. Es wird dann lediglich analog zu dem bisher Gesagten an Stelle des HTTP-Protokolls ein "Wireless Application Protocol" (WAP), anstelle der Sprache HTML eine "Wireless Markup Language" (WML) genannte Seitenbeschreibungssprache, anstelle des HTTP-Browsers und des HTTP-Servers ein WAP-Browser und ein WAP-Server verwendet.
Der Zahlungsdienstleister ZDL verfügt über einen Speicher Sp (z. B. eine Datenbank), in dem im Laufe des Verfahrens u. a. eine Genehmigungskennung GK abgespeichert und später wieder gesucht wird. Dies wird ausführlich im Zusammenhang mit der Fig. 2 beschrieben.
In der Fig. 2 sind Nachrichtenflüsse zwischen dem Kommunikationsendgerät KEG des Dienstnutzers, der Diensterbringereinrichtung DEE des Diensterbringers und dem Zahlungsdienstleister ZDL dargestellt. Dazu wird im Kommunikationsendgerät des Dienstnutzers ein WEB-Browser, in der Diensterbringereinrichtung DEE ein HTTP-Server und beim Zahlungsdienstleister ein zweiter HTTP-Server verwendet. Der Ablauf ist für einen Web-Browser erläutert; für einen WAP-Browser ist der Ablauf entsprechend.
Zur Vorbereitung der Nutzung des Dienstes bzw. der Dienstleistung startet der Dienstnutzer zunächst den Browser auf seinem Kommunikationsendgerät. Der Dienstnutzer ruft eine Adresse (die URL = Uniform Resource Locator) des Diensterbringers auf und bekommt in seinem Browser zunächst eine Dienstauswahl präsentiert (in der Figur nicht dargestellt). Der Dienstnutzer wählt in seinem Browser einen Dienst, eine Dienstleistung oder Ware aus und klickt diese an. Der Browser sendet daraufhin eine Nachricht in Form eines HTTP-GET-Request an den HTTP-Server des Diensterbringers (Merchant). Der HTTP-GET-Request (Pfeil 1 "Dienst anfordern") enthält die Auswahl des Dienstnutzers (beispielsweise eine von ihm gewünschte und daher somit bestellte Information). Damit wird durch das Kommunikationsendgerät des Dienstnutzers ein zu bezahlender Dienst von dem Diensterbringer abgefordert und bei der Diensterbringereinrichtung liegt eine Abforderung des Dienstes vor.
Der HTTP-Server des Diensterbringers (d. h. die DEE) erkennt, daß der Dienst oder die Ware (hier: die Information) kostenpflichtig sind und leitet die Authorisierung (Genehmigung) der Zahlung ein. Dazu benutzt er das "Redirect"-Verfahren des HTTP-Protokolls. HTTP Redirect ist ein Verfahren, das Teil des HTTP-Protokolls ist und daher von jedem HTTP Server sowie von jedem Browser unterstützt wird. Bei diesem Verfahren sendet ein HTTP-Server A als Antwort auf eine Anforderungsnachricht (z. B. einen GET-Request) nicht unmittelbar die geforderte Information. Stattdessen antwortet der HTTP-Server A mit einer "Redirect"-Nachricht, d. h. einen Verweis auf einen anderen HTTP-Server B. Der HTTP-Server A erwartet dabei, daß der Browser des Dienstnutzers automatisch, d. h. ohne Zutun des Dienstnutzers, eine neue Anforderungsnachricht an den HTTP-Server B sendet. In der "Redirect"-Nachricht kann der HTTP-Server A zusätzlich Informationen übermitteln, die zusammen mit der neuen Anforderungsnachricht an den HTTP-Server B übermittelt werden sollen. Da das Verfahren im HTTP-Protokoll exakt beschrieben ist, kann der Browser die "Redirect"- Nachricht interpretieren und wird sich so verhalten, wie der HTTP-Server A dies erwartet. Im Ausführungsbeispiel übernimmt der HTTP-Server des Diensterbringers die Rolle "A" und der HTTP-Server des Zahlungsdienstleisters die Rolle "B".
Dazu beantwortet der HTTP-Server des Diensterbringers den HTTP-GET-Request mit einer Nachricht in Form eines "HTTP Redirect" (Pfeil 2) an das Kommunikationsendgerät KEG. In dieser HTTP-Nachricht werden in Form von "Zahlungsinformationen" alle Informationen mitgeliefert, die der Dienstnutzer für die Authorisierung der Zahlung benötigt, z. B. Preis, Bezeichnung der Ware, Identifikation des Händlers, sowie eine Kommunikationsadresse KA des Zahlungsdienstleisters (URL des Payment Service Providers) als "Ziel" des Redirect.
Der Browser des Dienstnutzers interpretiert das "HTTP Redirect" gemäß der HTTP-Protokollspezifikation, d. h. er generiert automatisch einen neuen HTTP-GET-Request und sendet diesen (Pfeil 3 "Authorisierung initiieren") zum HTTP-Server des Payment Service Providers. Dieser neue HTTP-GET-Request (Pfeil 3 "Authorisierung initiieren") bildet hierbei eine Genehmigungs-Startnachricht. Die "Zahlungsinformation", die der Browser in der "HTTP Redirect"-Nachricht erhalten hat (Pfeil 2) werden dabei mitgeliefert, der HTTP-GET-Request (Pfeil 3) enthält also auch die Zahlungsinformationen. Dieser Vorgang ist normalerweise für den Dienstnutzer unsichtbar.
Der HTTP-Server des Zahlungsdienstleisters wertet den HTTP- GET-Request aus. Er generiert aus den erhaltenen Informationen (z. B. den Zahlungsinformationen) ein HTML-Dokument, das eine Aufforderung zu einer Genehmigungshandlung enthält und somit einen "Authorisierungs-Dialog" für den Dienstnutzer beinhaltet. Das Dokument enthält also die Informationen, die für den Dienstnutzer relevant sind, z. B. Preis, Bezeichnung der Ware, Identifikation des Händlers. Außerdem enthält das HTML-Dokument zwei Buttons ("Drucktasten" auf der Anzeige des Kommunikationsendgerätes): "Akzeptieren" und "Zurückweisen". Der Consumer (Dienstnutzer) wird mit der HTML-Seite aufgefordert, zur Genehmigung als Genehmigungshandlung den "Akzeptieren"-Button zu betätigen, was dieser durch Betätigen von Bedienelementen des Kommunikationsendgerätes tun kann.
Diese HTML-Seite wird als Antwort auf die Genehmigungs-Startnachricht (Pfeil 3) an den Browser des Consumers geschickt (Pfeil 4 "Authorisierungs-Seite senden").
Der Browser zeigt auf einer Anzeige des Kommunikationsendgerätes das HTML-Dokument an. Der Dienstnutzer prüft die Informationen. Bei Korrektheit betätigt er den Button "Akzeptieren". Diese Information sendet der Browser mittels einen HTTP-GET-Request an den HTTP-Server des Zahlungsdienstleisters (Pfeil 5 "Zahlung authorisiert"), diese Nachricht stellt eine Genehmigungsnachricht für den Zahlungsdienstleister dar.
Der HTTP-Server des Zahlungsdienstleiters speichert die Genehmigungsnachricht als Zahlungsbestätigung in einem Speicher SP (vgl. Fig. 1) und versieht sie mit einem geeigneten Verfallsdatum (Verfallszeitpunkt), das angibt, wie lange die Genehmigung für die Zahlung gültig ist. Er generiert ein Genehmigungs-Kennzeichen GK (eine Identifikationsnummer für die Zahlungsbestätigung) und speichert auch diese in dem Speicher Sp ab. Der HTTP-Server des Zahlungsdienstleisters beantwortet den GET-Request (Pfeil 5) wiederum mit einem HTTP-Redirect an das Kommunikationsendgerät KEG und liefert dabei dabei folgende Informationen mit: Das Genehmigungs-Kennzeichen GK und die URL des Diensterbringers als Ziel des Redirect (Pfeil 6 "HTTP Redirect"); die URL des Merchant stellte eine Kommunikationsadresse der Diensterbringereinrichtung DEE dar.
Der Browser im Kommunikationsendgerät des Dienstnutzers interpretiert das HTTP Redirect gemäß HTTP-Spezifikation, d. h. er sendet automatisch einen neuen HTTP-GET-Request (Pfeil 7 "Dienst anfordern (authorisiert)") zum HTTP-Server des Merchant. Dabei wird das Genehmigungs-Kennzeichen GK an den Merchant übermittelt.
Der HTTP-Server des Diensterbringers erkennt an dem Genehmigungs-Kennzeichen GK, daß die Authorisierung der Zahlung bereits stattgefunden hat. Er fordert nun vom Zahlungsdienstleister, die Bezahlung einzuleiten (Pfeil 8 "Zahlung anfordern"); das Genehmigungs-Kennzeichen GK wird dabei mitgeliefert.
Der Zahlungsdienstleister überprüft nun, ob der Dienstnutzer mit der Zahlung einverstanden ist und diese genehmigt hat. Dazu überprüft er die in seinem Speicher abgelegten Zahlungsbestätigungen. Wenn er eine Zahlungsbestätigung mit dem mit der Zahlungsanforderungsnachricht (Pfeil 8) übermittelten Genehmigungs-Kennzeichen findet, und deren Verfallszeitpunkt noch nicht erreicht ist, wird die Zahlung durchgeführt und das dem Diensterbringer bestätigt (Pfeil 9 "Zahlung bestätigt").
Da der Bezahlvorgang erfolgreich war, sendet der HTTP-Server des Diensterbringers eine Antwortnachricht (Pfeil 10 "Dienst erbringen") an das Kommunikationsendgerät. Diese Antwortnachricht bezieht sich auf den HTTP-GET-Request, der durch Pfeil 7 symbolisiert wurde. Diese Antwortnachricht kann bereits den angeforderten Dienst darstellen, falls es sich bei dem Dienst z. B. um eine Lieferung von Informationen handelt. Besteht der Dienst in einem anderen Beispiel in der Lieferung von Konsumgütern, dann enthält die Antwortnachricht z. B. Informationen über die bevorstehende Auslieferung der Güter.
Das erfindungsgemäße Verfahren weist eine Reihe von Vorteilen auf:
Das Verfahren erfordert keine spezifische Software beim Dienstnutzer. Der Standard-Web- oder WAP-Browser, der sowieso zum Zugriff auf den Dienst benutzt wird, wird auch für den Authorisierungs-Dialog benutzt. Das erhöht die Akzeptanz beim Dienstnutzer.
Das erfindungsgemäße Verfahren behält die aus Sicherheitsgründen beim HTTP-Protokoll vorgesehene Einschränkung bei, daß ein Web-Browser keine ankommenden Verbindungen akzeptiert. Daher wird der Aufbau des Authorisierungs-Dialogs nicht vom HTTP-Server des PSP initiiert, sondern in dem erfindungsgemäßen Verfahren wird das HTTP-Redirect-Verfahren benutzt, damit der Web-Browser des Consumers diesen Dialog initiieren kann.
Ein Bediener nimmt den Authorisierungsdialog (den für ihn "sichtbaren" Teil des Genehmigungsverfahrens) als Teil des Dienstes wah r. Das Redirect zum Payment Service Provider ist für ihn nicht unmittelbar sichtbar.
Bei Anwendung des erfindungsgemäßen Verfahrens im Internet ist die Benutzung eines Mobiltelefons nicht erforderlich. Damit ist das Verfahren auch für Consumer anwendbar, die kein Mobiltelefon besitzen, oder wenn Umgebungsbedingungen (z. B. Abschirmung von elektromagnetischen Wellen) den Einsatz eines Mobiltelefons ausschließen.
Bei Anwendung des erfindungsgemäßen Verfahrens im Internet fallen keine zusätzlichen Gebühren an. Der Internetzugang ist für die Dienstnutzung ohnehin erforderlich und verursacht beim Authorisierungs-Dialog keine weiteren Kosten, es fallen insbesondere keine Kosten für Mobiltelefon-Verbindungen an.
Das erfindungsgemäße Verfahren ist einfach und sehr kostengünstig zu realisieren, da für das Verfahren auf Seiten des Kommunikationsendgerätes keine aufwendige Zusatzausstattung notwendig ist und auch auf Seiten des Diensterbringers und des Zahlungsdienstleisters im wesentlichen nur relativ einfach zu realisierende HTTP- oder WAP-Server notwendig sind.
Das Verfahren zum Genehmigen von Zahlungen läßt sich gut mit standardisierten Bezahlverfahren, insbesondere mit "Parlay Content Based Charging" oder "3GPP OSA Content Charging", kombinieren. Weiterführende Informationen über die Parlay- Technik sind im Internet unter der Internetadresse www.parlay.org zu finden.

Claims

1. Verfahren zum Genehmigen von Zahlungen in einem Kommunikationsnetz (KN), bei dem nach Abforderung (Pfeil 1) eines zu bezahlenden Dienstes durch ein Kommunikationsendgerät (KEG) eines Dienstnutzers
von einer dem Dienst zugeordneten Diensterbringereinrichtung (DEE) eine Kommunikationsadresse (KA) eines Zahlungsdienstleisters (ZDL) zu dem Kommunikationsendgerät (KEG) übertragen wird (Pfeil 2),
von dem Kommunikationsendgerät (KEG) zur Genehmigung einer den Dienst betreffenden Zahlung eine Genehmigungsnachricht (Pfeil 5) zu dem Zahlungsdienstleister (ZDL) übertragen wird,
daraufhin von dem Zahlungsdienstleister (ZDL) eine individuelle Genehmigungskennung (GK) in einem Speicher (Sp) abgelegt wird,
die Genehmigungskennung (GK) zu dem Kommunikationsendgerät (KEG) übertragen wird (Pfeil 6),
von dem Kommunikationsendgerät (KEG) die Genehmigungskennung (GK) zu der Diensterbringereinrichtung (DEE) übertragen wird (Pfeil 7),
daraufhin von der Diensterbringereinrichtung (DEE) eine die Genehmigungskennung (GK) enthaltende Zahlungsanforderungsnachricht (Pfeil 8) an den Zahlungsdienstleister (ZDL) gesendet wird, und
von dem Zahlungsdienstleister (ZDL) die Zahlung als genehmigt erkannt wird, wenn die Genehmigungskennung (GK) der Zahlungsanforderungsnachricht (Pfeil 8) in dem Speicher (Sp) vorliegt.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass
von der Diensterbringereinrichtung (DEE) die Kommunikationsadresse (KA) zusammen mit Zahlungsinformationen zu dem Kommunikationsendgerät (KEG) übertragen wird (Pfeil 2),
daraufhin von dem Kommunikationsendgerät (KEG) eine Genehmigungs-Startnachricht (Pfeil 3) an den Zahlungsdienstleister (zDL) übertragen wird,
von dem Zahlungsdienstleister (ZDL) der Dienstnutzer zu einer Genehmigungshandlung aufgefordert wird, und
bei erfolgter Genehmigungshandlung von dem Kommunikationsendgerät (KEG) die Genehmigungsnachricht (Pfeil 5) erstellt wird.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der Dienstnutzer zu der Genehmigungshandlung aufgefordert wird, indem vom Zahlungsdienstleister (ZDL) Anzeigedaten zu dem Kommunikationsendgerät (KEG) übertragen werden (Pfeil 4), durch die auf einer Anzeige des Kommunikationsendgerätes (KEG) mindestens Teile der Zahlungsinformationen angezeigt werden und durch die der Dienstnutzer zum Betätigen eines Bedienelementes des Kommunikationsendgerätes (KEG) aufgefordert wird.

4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Kommunikation mit dem Kommunikationsendgerät (KEG) unter Nutzung eines "Hypertext Transfer Protocol" genannten Kommunikationsprotokolls durchgeführt wird.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass das Übertragen der Genehmigungs-Startnachricht (Pfeil 3) an den Zahlungsdienstleister (ZDL) mittels einer "Redirect"-Operation (Pfeil 2) des "Hypertext Transfer Protocol" durch einen HTTP-Server der Diensterbringereinrichtung (DEE) initiiert wird.

6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Kommunikation mit dem Kommunikationsendgerät (KEG) unter Nutzung eines "Wireless Application Protocol" genannten Kommunikationsprotokolls durchgeführt wird.

7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zusammen mit der Genehmigungskennung (GK) Genehmigungsdaten in dem Speicher (Sp) abgelegt werden.

8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass als Genehmigungsdaten dienstindividuelle Daten, Preisdaten, Währungsdaten oder Identitätsdaten des Dienstnutzers oder eines Diensterbringers in dem Speicher (Sp) abgelegt werden.

9. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass
als Genehmigungsdaten ein Verfallzeitpunkt in dem Speicher (Sp) abgelegt wird, und
von dem Zahlungsdienstleister (ZDL) die Zahlung nur dann als genehmigt erkannt wird, wenn der Verfallzeitpunkt der im Speicher (Sp) abgelegten Genehmigungskennung nicht überschritten ist.