-
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).
-
Aus
der internationalen Patentanmeldung WO 01/45008 A1 ist ein Verfahren
zum Genehmigen einer Online-Transaktion mittels eines Überprüfungsrechner
bekannt, wobei die Online-Transaktion
zwischen einem Rechner eines Käufers
und einem Rechner eines Händlers
abgewickelt wird. Der Rechner des Käufers, der Rechner des Händlers und
der Überprüfungsrechner
tauschen dabei Informationen über
eine Kreditkartennummer, eine Händlernummer und
eine Transaktionssumme aus. Bei diesem Verfahren werden von dem
Rechner des Händlers
Nachrichten über
den Rechner des Käufers
zu dem Überprüfungsrechner
umgeleitet.
-
Aus
der internationalen Patentanmeldung WO 00/55777 A1 ist ein Verfahren
zum Durchführen sicherer
Online-Transaktionen bekannt, bei dem ein Rechner eines Kunden,
ein Rechner eines Händlers, ein
Zahlungssystem und ein Zahlungsgenehmigungssystem zusammenarbeiten.
Nach einer Genehmigung des Zahlungsgenehmigungssystems wird ein
Voucher zu dem Rechner des Kunden übertragen. Ein bestelltes Produkt
wird im Austausch gegen diesen Voucher geliefert.
-
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 Zahlungsdienstleistersystems
zu dem Kommunikationsendgerät übertragen
wird,
- – von
dem Kommunikationsendgerät
zur Genehmigung einer den Dienst betreffenden Zahlung eine Genehmigungsnachricht
zu dem Zahlungsdienstleistersystem übertragen wird,
- – daraufhin
von dem Zahlungsdienstleistersystem 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 das Zahlungsdienstleistersystem
gesendet wird, und
- – von
dem Zahlungsdienstleistersystem 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 das Zahlungsdienstleistersystem übertragen
wird,
- – von
dem Zahlungsdienstleistersystem 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 Zahlungsdienstleistersystem
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, Dienstnutzer freundliche
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 Zahlungsdienstleistersystem
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
-
1 eine
schematische Darstellung eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens,
und in
-
2 eine
Darstellung von Nachrichtenflüssen
bei einem Ausführungsbeispiel
des erfindungsgemäßen Verfahrens
dargestellt.
-
In 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 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 2 beschrieben.
-
In
der 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. 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 wahr. 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.