Händler und Dienstleister sind in zunehmendem Umfang in Geschäftsabläufe ein- bezogen, welche über mehrere Kanäle ausgeführt werden. Im herkömmlichen Rahmen besucht z. B. ein Kunde ein Kaufhaus, sucht einzukaufende Gegenstände aus und verlässt (checks out), d. h. kauft die Gegenstände an der Registrierkasse des Händlers. Der Kunde zahlt typischerweise für die Gegenstände bar, mit Kre- ditkarte oder Scheck.

Ein Händler kann jedoch möglicherweise den Umsatz durch Verbessern der Kun- denfreundlichkeit beim Einkaufen von Waren und Dienstleistungen erhöhen. Als ein Beispiel können Kunden, welche Gegenstände über das Internet einkaufen, auch wünschen, die eigentliche Transaktion ebenso über das Internet durchzu- führen. Dadurch, dass Kunden Waren über das Internet einkaufen können, ohne physisch ein Kaufhaus betreten zu haben, kann ein Händler Umsätze steigern und mehr Zuspruch (good will) finden. Wird die Transaktion jedoch nicht richtig und zeitig durchgeführt, kann der Händler tatsächlich Umsätze und good will einbü- ßen.

Eine weitere Händlern zur Verfügung stehende Kundenfreundlichkeit besteht dar- in, Kunden selbst dann Einkäufe zu ermöglichen, wenn der Kunde kein Barged, keine Kreditkarte oder keinen Scheck bei sich trägt. Z. B. erlauben bekannte Sys- teme einem Kunden Einkäufe mittels drahtloser Geräte (z. B. ein Mobiltelefon, ein PDA (Personal Digital Assistent)) durchzuführen. Wie beim Internet können durch Bereistellen solcher Annehmlichkeiten für den Kunden Umsätze gesteigert und good will verbessert werden, doch wenn die Transaktion nicht richtig und zeitig durchgeführt wird, können Umsätze und good will verloren gehen.

Händler möchten deshalb üblicherweise Kunden mit mehreren Bezahlungsoptio- nen und mehreren Zugängen ausstatten, über welche Waren und Dienstleistun- gen eingekauft werden können. Diese Händler sind jedoch im Anbieten derartiger Flexibilität zurückhaltend, bis die Transaktion richtig und rechtzeitig ausgeführt werden kann.

Darüber hinaus existieren Altsysteme zum Durchführen von Transaktionen und erhebliche Investitionen wurden für den Aufbau der Altsysteminfrastruktur getä- tigt.

Händler sind typischerweise zurückhaltend beim Investieren in Systeme, welche den Ersatz solcher Altsysteme notwendig machen, wenn der zum Erzielen eines Rückflusses derartiger Investitionen erforderliche Zeitaufwand zu hoch ist. Das bedeutet, wenn ein Händler ein existierendes Altsystem durch ein vollkommen neues System ersetzen muss, um Bezahlungen über ein drahtloses Gerät zu er- möglichen, wird der Händler nicht Willens sein, eine solche Investition vorzu- nehmen.

Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren und eine Anord- nung zur vereinfachten Abwicklung von Zahlungsverkehr unter Nutzung eines Te- lekommunikationsnetzes anzugeben, welches den in verschiedenen Ländern be- stehenden gesetzlichen Vorschriften und etablierten und bewährten Verfahrens- abläufen des Geldverkehrs Rechnung trägt.

In erheblichem Maße müssen auch private Zahlungsvorgänge, die über einen kommerziellen Dienstanbieter abgewickelt werden, diesen etablierten Regeln fol- gen. An einer Abwicklung derartiger privater Zahlungsvorgänge mit modernsten technischen Mitteln-also insbesondere über das Internet bzw. die Telekommu- nikationsnetze-besteht speziell im Zusammenhang mit der weiteren Durchset- zung des elektronischen Geldverkehrs und im Zusammenhang mit dem nicht- gewerblichen Verkauf von Produkten oder Dienstleistungen (darunter Informatio- nen) zwischen Privatleuten zunehmender Bedarf. Die bisher vorgeschlagenen und in Ansätzen auch in der Praxis verfügbaren Datenübertragungsverfahren, die die- sem Zweck gewidmet sind, sind aufgrund unzureichender Zuverlässigkeit und Si-

cherheit und/oder unbequemer Handhabung zur Befriedigung eines entsprechen- den Massenbedarfs noch nicht geeignet.

Der Erfindung liegt daher auch die Aufgabe zugrunde, ein Verfahren und eine Anordnung zur vereinfachten Abwicklung von privatem Zahlungsverkehr ("P2P = Person-to-Person) unter Nutzung eines Telekommunikationsnetzes anzugeben, welches den in verschiedenen Ländern bestehenden gesetzlichen Vorschriften und etablierten und bewährten Verfahrensabläufen des Geldverkehrs Rechnung trägt.

In einer Hinsicht betrifft die vorliegende Erfindung ein Protokoll zum Ausführen von Transaktionen zwischen mehreren Kunden und Händlern. Das Protokoll steu- ert den Meldungsfluss und die Ausführung von in diesen Meldungen beinhalteten Instruktionen über ein Bezahlungssystem hinweg, welches herkömmliche wie auch nicht herkömmliche Bezahlungsmethodiken ermöglicht. Das Protokoll bietet eine Vielzahl von Vorteilen einschließlich dem, dass komplexe Transaktionen in einer vernünftigen Zeit und mit einer akzeptablen Kundenerfahrung abgeschlos- sen werden können.

Insbesondere und in einer spezifischen Ausführungsform umfasst das Protokoll verschiedene Unterprotokolle. Jedes Unterprotokoll verfügt über seinen eigenen definierten Umfang mit einer klaren Abgrenzung zu anderen Unterprotokollen. In einer beispielhaften Ausführungsform enthält das Protokoll zwei Unterprotokolle.

Ein Unterprotokoll ist das Geldbörsen (Wallet) server, Zentralprozessorplattform und Bezahlungs (Payment) serverprotokoll, manchmal auch als das interoperable mobile Bezahlungsprotokoll (IMPP) bezeichnet. Das andere Unterprotokoll ist das Bezahlungsserver und Händlerserverprotokoll, manchmal auch als das offene Be- zahlungsprotokoll (OPP) bezeichnet. Das OPP steuert den Informationsaustausch zwischen einem Geldbörsenserver, einem Händlersystem und einem Bezahlungs- server. In der beispielhaften Ausführungsform kann ein Händlersystem alternativ auf einen Bezahlungsserver über das Händler API eher als über das OPP zugrei- fen.

Das IMPP wird durch eine Zentralprozessorplattform (CPP) unterstützt, welche eine zentrale Instanz zum Weiterleiten (Routen) von Meldungen und anderen be-

zahlungsbezogenen Verarbeitungen nutzt. Die CPP verwaltet zentrale Angebots- daten und findet in bestimmten Szenarien den Geldbörsenserver eines Kunden während der Bezahlungseinleitung heraus. Weiterhin stellt die CPP das Weiterlei- ten von Bezahlungsmeldungen in beiden Richtungen zwischen einem Geldbörsen- server und einem Bezahlungsserver zur Verfügung.

Der Geldbörsenserver enthält Kernkundendaten, welche zur Authentifizierung und Bezahlung wie auch eine Transaktionshistorie erforderlich sind. In Übereinstim- mung mit dem IMPP wird der Geldbörsenserver während der Bezahlungseinlei- tungsphase angesteuert (triggered) und verschickt in der Folge Bezahlungsmel- dungen an den Bezahlungsserver durch das CPP. Wenn sich der Transaktionssta- tus bei einem Erwerber ändert, verschickt der Bezahlungsserver Benachrichti- gungsmeldungen an den Geldbörsenserver durch das CPP. Darüber hinaus kann jede Partei Nachfragemeldungen senden, um den Status einer Transaktion zu ak- tualisieren und zu überprüfen.

Der Bezahlungsserver hält die Kundenkerndaten zu Bezahlung und Transaktions- historiendaten. Der Bezahlungsserver empfängt auch Bezahlungsmeldungen von dem CPP und verarbeitet die Meldungen. Insbesondere verschickt der Bezah- lungsserver in Übereinstimmung mit dem IMPP eine Meldung an den Befugten auf Erwerberseite und löst eine Ergebnismitteilung an das CPP und das Händlersys- tem aus. Der Bezahlungsserver versendet und empfängt die benötigte Informati- on an/von dem Händlersystem während der verschiedenen Phasen des Bezah- lungsprozesses.

Alle transaktionsbezogenen Meldungen und Meldungsattribute werden nicht in je- dem der drei Server gespeichert, d. h. dem Geldbörsenserver, dem Bezahlungs- server und der CPP. Z. B. werden Erzeugungsdaten für die OfferID nur in der CPP gespeichert.

Der Begriff"Händlersystem"bezieht sich auf ein Einkaufssystem (z. B. einen kommerziell erhältlichen Handels (Commerce) server) und Bezahlungsstecker (plug- in) -Komponenten, welche in einer lokalen Händlerdomäne eines 3D-Modell-kon- formen Bezahlungssystems verfügbar sind. In Übereinstimmung mit dem OPP sendet und empfängt das Händlersystem die benötigte Information an/von dem

Bezahlungsserver während der verschiedenen Phasen des Bezahlungsprozesses.

Die Übertragung von Meldungen zwischen dem CPP und dem Bezahlungsserver werden über das IMPP abgewickelt.

Das IMPP erleichtert es Händlern, Kunden die Option zur Verfügung zu stellen, Bezahlungen durch Verwenden mobiler Geräte in einer verlässlichen, richtigen und rechtzeitigen Art und Weise durchzuführen. Zusätzlich wird die Integration mit existierenden Altsystemen durch Bereitstellen eines Gateways ermöglicht, durch welches standardisierte, offene Protokolle (z. B. das IUTP-Protokoll) zum Kommunizieren mit dem System genutzt werden können. Z. B. übersetzt das Ga- teway mit dem IUTP-Protokoll IUTP-Meldungen in IMPP-Meldungen und Daten- ströme. Händler brauchen deshalb Altsysteme nicht ersetzen und sich einfach an die Plattform anbinden (plug-in), auf welcher das IMPP implementiert ist.

Die Erfindung schließt in einem weiteren Aspekt den wesentlichen Gedanken ein, ein weitgehend universelles Zahlungsverfahren auf der Grundlage eines her- kömmlichen Bankkontos ("Postpaid") oder elektronischen Guthabens ("Prepaid") anzugeben, welches insbesondere für eine Zahlungsabwicklung im sogenannten B2C (Business-to-Consumer) -Bereich wie auch im P2P (Person-to-Person)-Bereich anwendbar ist, also den Einkauf in realen und virtuellen Geschäften, die Bezah- lung in gastronomischen oder kulturellen Einrichtungen etc. und die"Übersen- dung"von Geldbeträgen im privaten Bereich ermöglicht.

Sie schließt weiter den Gedanken ein, hierzu die Möglichkeiten eines TK-Netzes zu nutzen, und zwar insbesondere die Möglichkeit einer weitgehenden Abwicklung in nahezu Echtzeit (Real Time). Weiter gehört zur Erfindung der zentrale Gedan- ke der Bereitstellung und Verwendung einer eindeutigen Kennung-des Kontext- Identifikators-zur transaktionsübergreifenden Kennzeichnung von durch einen Anbieter offerierten Waren oder Dienstleistungen (insbesondere eines ganzen "Warenkorbes") für die Abwicklung aller mit dem Anbieten und Bezahlen verbun- denen Datenübertragungs-und-verarbeitungsvorgänge, insbesondere die ver- lässliche Autorisierung der Bezahlung.

In einer ersten Ausführungsvariante der Erfindung wird mit der Generierung des Kontext-Identifikators keine Gültigkeitsdauer festgelegt, so dass er potentiell un-

begrenzt gültig ist. Hierfür kann der Begriff"statische OfferID"gebraucht wer- den. Sie wird insbesondere für die Bezahlung von über Fernsehkanäle angebote- nen Waren bzw. Dienstleistungen ("TV Shopping") sowie für die an Ausgabeau- tomaten (Vending Machines = VM) angebotenen Produkte über ein TK-Netz unter Einsatz eines TK-Endgerätes genutzt werden.

In einer alternativen Ausführung der Erfindung wird mit der Generierung des Kontext-Identifikators eine Gültigkeitsdauer definiert und er bei deren Ablauf au- tomatisch ungültig gemacht. Hierbei kann man von einer"dynamischen OfferID" sprechen. Sie wird für verschiedene sonstige Einkaufs-und Bezahlvorgänge ge- nutzt werden, insbesondere für einzelne Einkaufsaktionen in virtuellen Shops oder realen Läden bzw. Kaufhäusern.

In beiden Fällen kann der Kontext-Identifikator auf Anforderung des Anbieters der Waren oder Dienstleistungen gelöscht bzw. zerstört werden. Zum Ungültig- machen des Kontext-Identifikators wird bei Ablauf der Gültigkeitsdauer oder auf Anforderung des Anbieters ein Eliminierungssignal an den Anbieter gesandt, um diesen auf das Ungültigwerden des fraglichen Identifikators hinzuweisen.

Die Informationsübertragung des Kontext-Identifikators an den-potentiellen- Abnehmer bzw. Kunden (Customer) erfolgt in einer ersten Variante als invariante optische Anzeige, insbesondere Beschriftung auf einem Schaufensterdisplay oder Ausgabeautomaten oder Aufdruck auf einem Prospekt oder Katalog oder derglei- chen. In anderen Varianten erfolgt die Übermittlung des Kontext-Identifikators an potentielle Abnehmer als variable optische Anzeige auf einer elektrooptischen Anzeigeeinrichtung oder durch Sprachausgabe oder ein akustisches Signal. Mit diesen verschiedenen Übermittiungsarten wird den spezifischen Einkaufssituatio- nen der Industriegesellschaft Rechnung getragen, wo neben den traditionellen Ladeneinkauf und die insbesondere als Getränke-, Zigaretten-und Süßigkeitenau- tomaten etablierten Ausgabeautomaten längst das Internet-Shopping und TV- Shopping getreten ist.

Für die Mehrzahl der bestehenden Vertriebskanäle ist es von Vorteil, wenn der Kontext-Identifikator in einem Broadcast-Verfahren außerhalb des Telekommuni- kationsnetzes, insbesondere durch Rundfunk-oder Fernsehübertragung oder Ver-

sand bzw. Verteilung von Druckschriften oder E-Mail-Broadcast, während der Gül- tigkeitsdauer an eine Vielzahl potentieller Abnehmer übermittelt wird. In letzter Zeit haben aber die unmittelbar über ein Telekommunikationsnetz angebotenen Möglichkeiten zum Bezug von Waren oder Dienstleistungen (Informationen ! ) er- heblich an Bedeutung gewonnen. Hierfür ist eine Variante von Vorteil, bei der der Kontext-Identifikator, insbesondere in einem Broadcast-Verfahren, in einer Kurz- nachricht oder per WAP über das Telekommunikationsnetz an das Telekommuni- kations-Endgerät des Abnehmers übermittelt und dort angezeigt wird.

Bevorzugt laufen die Schritte der Anfrage nach einem Kontext-Identifikator durch den Anbieter und der Zusendung eines solchen an den Anbieter bzw. Händler (Merchant) als im wesentlichen automatisierte Datenübertragungen zwischen dem Systemverwaltungsserver und einem Händler-Server oder Anbieter-Daten- endgerät über ein Daten-und/oder Telekommunikationsnetz, insbesondere das Internet, ab. Dies gilt sowohl für das Internet-Shopping als auch bei der Inan- spruchnahme des vorgeschlagenen Systems durch"klassische"Handelseinrich- tungen.

In einem typischen Szenario wird nach dem Schritt der Übermittlung des Kontext- Identifikators an den Abnehmer der Kontext-Identifikator durch den Abnehmer über das Telekommunikationsnetz an einen Kunden-Server des Netzbetreibers oder eines Dienstanbieters im Telekommunikationsnetz übermittelt, durch den Kunden-Server, Dienstserver oder Händler-Server eine Anfragenachricht zur Ein- holung eines verbindlichen Angebots an den Anbieter gesandt, durch den Anbie- ter ein Angebotsdatensatz an den Kunden-Server übersandt und der Angebotsda- tensatz vom Kunden-Server an das Telekommunikations-Endgerät des potentiel- len Abnehmers übermittelt und dort im Rahmen einer Menüführung zur Bestäti- gung der Transaktion angezeigt. Hierbei wird die Datenübertragung in den Schrit- ten der Anfrage nach einem verbindlichen Angebot und der Übersendung der An- gebotsdaten über den Systemverwaltungsserver ausgeführt, welcher insbesonde- re Such-und Routing-Funktionen zwischen Netzbetreiber bzw. Dienstanbieter und Anbieter ausführt.

Der Kontext-Identifikator (OfferID) kann vollständig durch einen geeigneten Ge- nerator bei einem Systemverwaltungsserver des vorgeschlagenen Systems gene-

riert werden, er kann aber alternativ auch vollständig extern erzeugt und im Rahmen der Anfrage durch den Anbieter zur Bestätigung an den Systemverwal- tungsserver übermittelt werden. Insbesondere für"Kataloganbieter"ist eine Vari- ante von Vorteil, bei der der Kontext-Identifikator einen ersten und einen zweiten Abschnitt aufweist, wobei der erste Abschnitt ein durch den Systemverwaltungs- server generierter oder verwalteter Anbieter-Identifikator und der zweite Ab- schnitt ein durch den Anbieter generierter oder verwalteter Waren-oder Waren- gruppen-Identifikator ist und das Verfahren eine Übermittlung des zweiten Ab- schnitts an den Systemverwaltungsserver, die Verknüpfung von erstem und zwei- tem Abschnitt im Systemverwaltungsserver und die Zusendung oder Bestätigung des gesamten Kontext-Identifikators an den Abnehmer bzw. diesem gegenüber umfasst.

Dem Anbieter können somit gewissermaßen"Nummernbänder"zugeordnet wer- den, wobei er seine eigene Katalognummer hinter einem seine Identität als An- bieter repräsentierenden Abschnitt ("Präfix") weiterhin benutzt. Hierdurch lässt sich die Verwendung von Kontext-Identifikatoren bei Katalog-Szenarien wesent- lich vereinfachen. Die Kombination des ersten Abschnitts (Präfix) mit dem zwei- ten Abschnitt (Katalognummer) kann-nach Vergabe des Präfix durch die Sys- temverwaltung-auch durch den Anbieter selbst erfolgen, wobei die Verantwor- tung für die Eindeutigkeit des Kontext-Identifikators dann natürlich bei diesem liegt.

Üblicherweise wird der über den Kontext-Identifikator informierte Abnehmer die- sen an seinem Telekommunikationsendgerät manuell oder ggf. auch per Sprach- eingabe selbst eingeben. Die oben erwähnten Möglichkeiten der Ausgabe des Identifikators an den Abnehmer können aber in einen automatischen Eingabevor- gang münden, der natürlich fehlerresistenter als die manuelle Eingabe ist. Der Identifikator wird hierzu in oder an einem Telekommunikationsendgerät, insbe- sondere durch eine mit diesem verbundene Kamera oder einen Scanner, des Ab- nehmers aus einem optischen oder akustischen Signal in ein elektrisches Signal umgewandelt.

Die wesentlichen erfindungsgemäßen Vorrichtungsaspekte und ihre vorteilhaften Fortbildungen ergeben sich weitgehend bereits aus den oben erläuterten Verfah-

rensaspekten in ihrer Abbildung auf eine Systemstruktur, so dass sie hier nicht nochmals im einzelnen erläutert werden.

In organisatorischer Hinsicht ist das vorgeschlagene System in einer Mehrzahl verschiedener Konfigurationen realisierbar, wobei es technisch grundsätzlich um einen Systemverwaltungsserver zentriert ist, dem im Normalfall ein Kunden- Server (nachfolgend auch Valid Server) sowie ein Händler-Server (Payment Ser- ver) zugeordnet und mit dem diese durch Nachrichtenübertragungskanäle ver- bunden sind. Wenn in diesem Zusammenhang von"einem"Händler-bzw. Kun- den-Server die Rede ist, so ist hierunter im folgenden jeweils auch eine Mehrzahl von Servern verschiedener Dienstanbieter, Geldinstitute etc. zu verstehen, die im Gesamtsystem eine entsprechende Funktion haben.

In einer ersten Systemgestaltung befinden sich sämtliche genannten Server bei einem Telekommunikationsunternehmen bzw. kundenorientierten Dienstanbieter, welcher sowohl Anbieter als auch Abnehmer an das System anbindet. In einer zweiten Systemkonfiguration betreibt das Telekommunikationsunternehmen (nachfolgend auch als abgekürzt als Telco) bzw. der Kunden-Dienstanbieter zwar Kunden-und Händler-Server, der Systemverwaltungsserver wird jedoch von ei- nem getrennten Unternehmen (nachfolgend auch als Opco bezeichnet) betrieben und im wesentlichen nur für die Generierung des Kontext-Identifikators sowie die laufende Ermittlung des zuständigen Händler-Servers benötigt. Die relevanten In- formationen zur Zuordnung der für eine bestimmte Transaktion zuständigen Händler-und Kunden-Server liegen hierbei insbesondere beim Systemverwal- tungsserver.

In einer dritten Konfiguration gibt es separate Kunden-und Händler-Dienstanbie- ter, die jeweils auch nur den zugehörigen Server betreiben, während das Sys- tembetriebsunternehmen (Opco) den Systemverwaltungsserver betreibt. Hierbei ist ein erstes Szenario denkbar, bei dem (wie bei der vorgenannten Variante) der Systemverwaltungsserver im wesentlichen nur den Kontext-Identifikator erzeugt oder bestätigt und zum späteren Auffinden des Händler-Servers dient. In einem zweiten Szenario trägt der Systemverwaltungsserver verarbeitungs-wie übermitt- lungstechnisch im wesentlichen die Transaktion. Schließlich ist auch eine System- konfiguration sinnvoll, bei der das Betriebsunternehmen sowohl den Systemver-

waltungsserver als auch den Händler-Server betreibt, während lediglich Kunden- Server durch das Telco bzw. den Kunden-Dienstanbieter betrieben werden.

Die zweite und dritte der oben genannten Systemkonfigurationen, wo es ein selbstständiges Systemverwaltungsunternehmen und somit eine sogenannte"Op- co-Domäne"gibt, sind vorteilhaft für die Realisierung eines sehr großen, insbe- sondere globalen, Systems mit Anbindung sehr vieler Anbieter und Abnehmer. Sie ermöglichen nämlich eine zentrale Datenhaltung der relevanten Daten (OfferID und Serveradressen) sehr vieler Nutzer, die über eine Vielzahl von Händler-Ser- vern und/oder Kunden-Servern elektronische Transaktionen abwickeln.

Zur Realisierung einer seiner wichtigsten Funktionen hat der Systemverwaltungs- server eine Codeerzeugereinheit zur Generierung des Kontext-Identifikators im Ansprechen auf eine empfangene Anfrage und eine Codesendeeinrichtung zur Übersendung des generierten Kontext-Identifikators direkt oder mittelbar an das anfragende Anbieter-Endgerät. In einer Modifikation zu einer oben bereits er- wähnten speziellen Verfahrensführung ("Kataloganbieter") dient die Codeerzeu- gereinheit lediglich zur Erzeugung eines ersten Identifikator-Abschnittes, der ei- nen Anbieter kennzeichnet, und in einer weiteren Abwandlung sind statt der Co- deerzeugereinheit Mittel zum Empfang und zur Eindeutigkeitsprüfung eines ex- tern generierten Codes sowie zur Ausgabe eines Bestätigungssignals zur Bestäti- gung der Eindeutigkeit (und damit Brauchbarkeit) einer fremderzeugten OfferID vorgesehen.

Speziell zur Erzeugung und Handhabung der oben erwähnten dynamischen Of- ferID hat der Systemverwaltungsserver der Codeerzeugereinheit zugeordnete Zeitgebermittel und Zeitdauer-Speichermittel zur Zuordnung und Speicherung ei- ner Gültigkeitsdauer zu jedem Kontext-Identifikator sowie eine mit den Zeitge- ber-und Zeit-Speichermitteln verbundene Zeitdauer-Vergleichereinheit zur Überwachung des Ablaufes einer festgelegten Gültigkeitsdauer und zur Ausgabe eines Eliminierungssignals zum Ungültigmachen des Kontext-Identifikators bei Ablauf aufweist. Es versteht sich, dass im Falle der Verwendung statischer Of- ferIDs an die Stelle dieser Komponenten eine Löscheinheit tritt, die auf eine von extern erhaltene Löschanforderung anspricht und den Identifikator eliminiert.

Eine wesentliche Funktionskomponente der vorgeschlagenen Systemarchitektur stellt weiterhin ein Datenhaltungssystem (OfferID Repository) zur Speicherung und Verwaltung aller gültigen Kontext-Identifikatoren und von diesen im System zugeordneten Informationen, insbesondere zahlungsverkehrsrelevanten Daten und Kennzeichnungen stattgefundener Datenübertragungsvorgänge, dar. Mit des- sen Hilfe lassen sich beispielsweise für jede Transaktion die zuständigen Kunden- bzw. Händler-Server ermitteln. Die im vorangehenden Absatz erwähnten und dort dem Systemverwaltungsserver zugeschriebenen Komponenten zur Verwaltung dy- namischer OfferIDs können auch dem Repository zugeschrieben werden ; An das TK-Netz sind gemäß einem weiteren wesentlichen Aspekt der Erfindung einerseits die TK-Endgeräte der das Netz nutzenden Abnehmer bzw. Kunden (Customer) und andererseits mindestens ein Kunden-Server des Betreibers des TK-Netzes oder eines kundenorientiert arbeitenden Dienstanbieters angeschlossen. Zur Er- findung gehört weiter der Gedanke der Bereitstellung eines Systemverwaltungs- servers zur Verwaltung und zum Routing der transaktionsnotwendigen Daten im Bezug auf die Abnehmer-wie auch die Anbieter-Seite, der netzmäßig mit mindes- tens einem Händler-Server eines händlerorientiert arbeitenden Dienstanbieters verknüpft ist. Hier wird es sich typischerweise um Datennetzverbindungen han- deln, die mit dem TK-Netz zur Anbindung der Kunden verknüpft sein können, aber nicht notwendigerweise müssen. Schließlich gehört zur Erfindung der Ge- danke der Bereitstellung von geeigneten Datenverkehrsleitmitteln zum Routing der im Rahmen von Angebots-und Bezahlvorgängen zwischen den Beteiligten auszutauschenden Datensätze.

Die Hauptkomponente des vorgeschlagenen Systems bildet also ein Systemver- waltungsserver, der in einer sinnvollen praktischen Ausführung mit einer Mehr- zahl von Kunden-Servern in mehreren Telekommunikationsnetzen, insbesondere Mobilfunknetzen, im wesentlichen dauerhaft verbunden ist. Zudem ist in einer praktikablen Systemkonfiguration der Systemverwaltungsserver mit einer Mehr- zahl von Händler-Servern verbindbar, wobei jeder Händler-Server wiederum mit einer Mehrzahl von Anbieter-Endgeräten verbunden oder verbindbar ist, und er weist einen Händler-Speicher zur Speicherung von Identifizierungs-und Adress- daten der angeschlossenen Anbieter auf.

In einer weiteren bevorzugten Ausführungsform sind der Systemverwaltungsser- ver und/oder der oder die Händler-Server in einem Telekommunikationsnetz, ins- besondere Mobilfunknetz, angeordnet, und einer oder mehrere hiervon bilden ei- ne Funktionseinheit mit dem Kunden-Server oder Kunden-Servern.

In organisatorischer Hinsicht ist das vorgeschlagene System im übrigen in einer Mehrzahl verschiedener Konfigurationen realisierbar, wobei es technisch grund- sätzlich um einen Systemverwaltungsserver zentriert ist, dem im Normalfall ein Kunden-Server (nachfolgend auch Valid Server) sowie ein Händler-Server (Pay- ment Server) zugeordnet und mit dem diese durch Nachrichtenübertragungskanä- le verbunden sind. Wenn in diesem Zusammenhang von"einem"Händler-bzw.

Kunden-Server die Rede ist, so ist hierunter im folgenden jeweils auch eine Mehrzahl von Servern verschiedener Dienstanbieter, Geldinstitute etc. zu verste- hen, die im Gesamtsystem eine entsprechende Funktion haben.

In einer ersten Systemgestaltung befinden sich sämtliche genannten Server bei einem Telekommunikationsunternehmen bzw. kundenorientierten Dienstanbieter, welcher sowohl Anbieter als auch Abnehmer an das System anbindet. In einer zweiten Systemkonfiguration betreibt das Telekommunikationsunternehmen (nachfolgend auch als abgekürzt als Telco) bzw. der Kunden-Dienstanbieter zwar Kunden-und Händler-Server, der Systemverwaltungsserver wird jedoch von ei- nem getrennten Unternehmen (nachfolgend auch als Opco bezeichnet) betrieben und im wesentlichen nur für die Generierung des Kontext-Identifikators sowie die laufende Ermittlung des zuständigen Händler-Servers benötigt. Die relevanten In- formationen zur Zuordnung der für eine bestimmte Transaktion zuständigen Händler-und Kunden-Server liegen hierbei insbesondere beim Systemverwal- tungsserver.

In einer dritten Konfiguration gibt es separate Kunden-und Händler-Dienstanbie- ter, die jeweils auch nur den zugehörigen Server betreiben, während das Sys- tembetriebsunternehmen (Opco) den Systemverwaltungsserver betreibt. Hierbei ist ein erstes Szenario denkbar, bei dem (wie bei der vorgenannten Variante) der Systemverwaltungsserver im wesentlichen nur den Kontext-Identifikator erzeugt oder bestätigt und zum späteren Auffinden des Händler-Servers dient. In einem zweiten Szenario trägt der Systemverwaltungsserver verarbeitungs-wie übermitt-

lungstechnisch im wesentlichen die Transaktion. Schließlich ist auch eine System- konfiguration sinnvoll, bei der das Betriebsunternehmen sowohl den Systemver- waltungsserver als auch den Händler-Server betreibt, während lediglich Kunden- Server durch das Telco bzw. den Kunden-Dienstanbieter betrieben werden.

Die zweite und dritte der oben genannten Systemkonfigurationen, wo es ein selbstständiges Systemverwaltungsunternehmen und somit eine sogenannte"Op- co-Domäne"gibt, sind vorteilhaft für die Realisierung eines sehr großen, insbe- sondere globalen, Systems mit Anbindung sehr vieler Anbieter und Abnehmer. Sie ermöglichen nämlich eine zentrale Datenhaltung der relevanten Daten (OfferID und Serveradressen) sehr vieler Nutzer, die über eine Vielzahl von Händler-Ser- vern und/oder Kunden-Servern elektronische Transaktionen abwickeln.

Zur Realisierung einer seiner wichtigsten Funktionen hat der Systemverwaltungs- server eine Codeerzeugereinheit zur Generierung des Kontext-Identifikators im Ansprechen auf eine empfangene Anfrage und eine Codesendeeinrichtung zur Übersendung des generierten Kontext-Identifikators direkt oder mittelbar an das anfragende Anbieter-Endgerät. In einer Modifikation zu einer oben bereits er- wähnten speziellen Verfahrensführung ("Kataloganbieter") dient die Codeerzeu- gereinheit lediglich zur Erzeugung eines ersten Identifikator-Abschnittes, der ei- nen Anbieter kennzeichnet, und in einer weiteren Abwandlung sind statt der Co- deerzeugereinheit Mittel zum Empfang und zur Eindeutigkeitsprüfung eines ex- tern generierten Codes sowie zur Ausgabe eines Bestätigungssignals zur Bestäti- gung der Eindeutigkeit (und damit Brauchbarkeit) einer fremderzeugten OfferID vorgesehen.

Speziell zur Erzeugung und Handhabung der oben erwähnten dynamischen Of- ferID hat der Systemverwaltungsserver der Codeerzeugereinheit zugeordnete Zeitgebermittel und Zeitdauer-Speichermittel zur Zuordnung und Speicherung ei- ner Gültigkeitsdauer zu jedem Kontext-Identifikator sowie eine mit den Zeitge- ber-und Zeit-Speichermitteln verbundene Zeitdauer-Vergleichereinheit zur Überwachung des Ablaufes einer festgelegten Gültigkeitsdauer und zur Ausgabe eines Eliminierungssignals zum Ungültigmachen des Kontext-Identifikators bei Ablauf aufweist. Es versteht sich, dass im Falle der Verwendung statischer Of- ferIDs an die Stelle dieser Komponenten eine Löscheinheit tritt, die auf eine von

die Stelle dieser Komponenten eine Löscheinheit tritt, die auf eine von extern er- haltene Löschanforderung anspricht und den Identifikator eliminiert.

Eine wesentliche Funktionskomponente der vorgeschlagenen Systemarchitektur stellt weiterhin ein Datenhaltungssystem (OfferID Repository) zur Speicherung und Verwaltung aller gültigen Kontext-Identifikatoren und von diesen im System zugeordneten Informationen, insbesondere zahlungsverkehrsrelevanten Daten und Kennzeichnungen stattgefundener Datenübertragungsvorgänge, dar. Mit des- sen Hilfe lassen sich beispielsweise für jede Transaktion die zuständigen Kunden- bzw. Händler-Server ermitteln. Die im vorangehenden Absatz erwähnten und dort dem Systemverwaltungsserver zugeschriebenen Komponenten zur Verwaltung dy- namischer OfferIDs können auch dem Repository zugeschrieben werden.

Zur zweckmäßigen und zeitnahen Ausführung der eigentlichen finanziellen Trans- aktion ist insbesondere mindestens ein Kontenverwaltungsserver dem oder einem Telekommunikationsnetz direkt zugeordnet, und dieser wirkt mit dem Systemver- waltungsserver und/oder mit dem Kunden-Server zur Ausführung einer Bezah- lung, insbesondere unter Zugriff auf ein Prepaid-Guthaben, zusammen. Anderer- seits kann der oder mindestens ein Kontenverwaltungsserver außerhalb des netz- internen Steuerungsbereiches des oder jedes Telekommunikationsnetzes ange- ordnet und insbesondere direkt mit dem Telekommunikations-Endgerät des Ab- nehmers verbindbar sein.

Zur Gewährleistung einer systemautarken Steuerung aller Transaktionen (unab- hängig von externen Triggern, die bei einer sehr großen Anzahl gleichzeitig ab- laufender Transaktionen leicht zu Störungen führen könnten) weist der System- verwaltungsserver einen Ablaufprogrammspeicher zur Speicherung mindestens eines Transaktions-Ablaufprogrammes der Datenkommunikation zwischen dem oder jedem Kunden-Server und den Anbieter-Endgeräten bzw. dem oder jedem Händler-Server auf.

Wesentliche Aspekte der wichtigsten Verfahrensabläufe im vorgeschlagenen Sys- tem sind bereits aus den obigen Erläuterungen des Systemaufbaus ableitbar, so dass die korrespondierenden Verfahrensaspekte nachfolgend nicht nochmals er- schöpfend dargelegt werden. Es wird im weiteren auf einige prägende Verfah-

rensgedanken der Erfindung bzw. ihrer bevorzugten Ausführungen näher einge- gangen.

In einer besonders vorteilhaften Systemgestaltung ist die Bereitstellung und Ver- wendung einer eindeutigen Kennung-des Kontext-Identifikators-zur transakti- onsübergreifenden Kennzeichnung von durch einen Anbieter offerierten Waren oder Dienstleistungen (insbesondere eines ganzen"Warenkorbes") für die Ab- wicklung aller mit dem Anbieten und Bezahlen verbundenen Datenübertragungs- und-verarbeitungsvorgänge, insbesondere die verlässliche Autorisierung der Be- zahlung, vorgesehen.

In einer ersten Ausführungsvariante der Erfindung wird mit der Generierung des Kontext-Identifikators keine Gültigkeitsdauer festgelegt, so dass er potentiell un- begrenzt gültig ist. Hierfür kann der Begriff"statische OfferID"gebraucht wer- den. Sie wird insbesondere für die Bezahlung von über Fernsehkanäle angebote- nen Waren bzw. Dienstleistungen ("TV Shopping") sowie für die an Ausgabeau- tomaten (Vending Machines = VM) angebotenen Produkte über ein TK-Netz unter Einsatz eines TK-Endgerätes genutzt werden.

In einer alternativen Ausführung der Erfindung wird mit der Generierung des Kontext-Identifikators eine Gültigkeitsdauer definiert und er bei deren Ablauf au- tomatisch ungültig gemacht. Hierbei kann man von einer"dynamischen OfferID" sprechen. Sie wird für verschiedene sonstige Einkaufs-und Bezahlvorgänge ge- nutzt werden, insbesondere für einzelne Einkaufsaktionen in virtuellen Shops oder realen Länden bzw. Kaufhäusern.

In beiden Fällen kann der Kontext-Identifikator auf Anforderung des Anbieters der Waren oder Dienstleistungen gelöscht bzw. zerstört werden. Zum Ungültig- machen des Kontext-Identifikators wird bei Ablauf der Gültigkeitsdauer oder auf Anforderung des Anbieters ein Eliminierungssignal an den Anbieter gesandt, um diesen auf das Ungültigwerden des fraglichen Identifikators hinzuweisen.

Die Informationsübertragung des Kontext-Identifikators an den-potentiellen- Abnehmer bzw. Kunden (Customer) erfolgt in einer ersten Variante als invariante optische Anzeige, insbesondere Beschriftung auf einem Schaufensterdisplay oder

Ausgabeautomaten oder Aufdruck auf einem Prospekt oder Katalog oder derglei- chen. In anderen Varianten erfolgt die Übermittlung des Kontext-Identifikators an potentielle Abnehmer als variable optische Anzeige auf einer elektrooptischen Anzeigeeinrichtung oder durch Sprachausgabe oder ein akustisches Signal. Mit diesen verschiedenen Übermittiungsarten wird den spezifischen Einkaufssituatio- nen der Industriegesellschaft Rechnung getragen, wo neben den traditionellen Ladeneinkauf und die insbesondere als Getränke-, Zigaretten-und Süßigkeitenau- tomaten etablierten Ausgabeautomaten längst das Internet-Shopping und TV- Shopping getreten ist.

Für die Mehrzahl der bestehenden Vertriebskanäle ist es von Vorteil, wenn der Kontext-Identifikator in einem Broadcast-Verfahren außerhalb des Telekommuni- kationsnetzes, insbesondere durch Rundfunk-oder Fernsehübertragung oder Ver- sand bzw. Verteilung von Druckschriften oder E-Mail-Broadcast, während der Gül- tigkeitsdauer an eine Vielzahl potentieller Abnehmer übermittelt wird. In letzter Zeit haben aber die unmittelbar über ein Telekommunikationsnetz angebotenen Möglichkeiten zum Bezug von Waren oder Dienstleistungen (Informationen ! ) er- heblich an Bedeutung gewonnen. Hierfür ist eine Variante von Vorteil, bei der der Kontext-Identifikator, insbesondere in einem Broadcast-Verfahren, in einer Kurz- nachricht oder per WAP über das Telekommunikationsnetz an das Telekommuni- kations-Endgerät des Abnehmers übermittelt und dort angezeigt wird.

Bevorzugt laufen die Schritte der Anfrage nach einem Kontext-Identifikator durch den Anbieter und der Zusendung eines solchen an den Anbieter bzw. Händler (Merchant) als im wesentlichen automatisierte Datenübertragungen zwischen dem Systemverwaltungsserver und einem Händler-Server oder Anbieter- Datenendgerät über ein Daten-und/oder Telekommunikationsnetz, insbesondere das Internet, ab. Dies gilt sowohl für das Internet-Shopping als auch bei der In- anspruchnahme des vorgeschlagenen Systems durch"klassische"Handelseinrich- tungen.

In einem typischen Szenario wird nach dem Schritt der Übermittlung des Kontext- Identifikators an den Abnehmer der Kontext-Identifikator durch den Abnehmer über das Telekommunikationsnetz an einen Kunden-Server des Netzbetreibers oder eines Dienstanbieters im Telekommunikationsnetz übermittelt, durch den

Kunden-Server, Dienstserver oder Händler-Server eine Anfragenachricht zur Ein- holung eines verbindlichen Angebots an den Anbieter gesandt, durch den Anbie- ter ein Angebotsdatensatz an den Kunden-Server übersandt und der Angebotsda- tensatz vom Kunden-Server an das Telekommunikations-Endgerät des potentiel- len Abnehmers übermittelt und dort im Rahmen einer Menüführung zur Bestäti- gung der Transaktion angezeigt. Hierbei wird die Datenübertragung in den Schrit- ten der Anfrage nach einem verbindlichen Angebot und der Übersendung der An- gebotsdaten über den Systemverwaltungsserver ausgeführt, welcher insbesonde- re Such-und Routing-Funktionen zwischen Netzbetreiber bzw. Dienstanbieter und Anbieter ausführt.

Der Kontext-Identifikator (OfferID) kann vollständig durch einen geeigneten Ge- nerator bei einem Systemverwaltungsserver des vorgeschlagenen Systems gene- riert werden, er kann aber alternativ auch vollständig extern erzeugt und im Rahmen der Anfrage durch den Anbieter zur Bestätigung an den Systemverwal- tungsserver übermittelt werden. Insbesondere für"Kataloganbieter"ist eine Vari- ante von Vorteil, bei der der Kontext-Identifikator einen ersten und einen zweiten Abschnitt aufweist, wobei der erste Abschnitt ein durch den Systemverwaltungs- server generierter oder verwalteter Anbieter-Identifikator und der zweite Ab- schnitt ein durch den Anbieter generierter oder verwalteter Waren-oder Waren- gruppen-Identifikator ist und das Verfahren eine Übermittlung des zweiten Ab- schnitts an den Systemverwaltungsserver, die Verknüpfung von erstem und zwei- tem Abschnitt im Systemverwaltungsserver und die Zusendung oder Bestätigung des gesamten Kontext-Identifikators an den Abnehmer bzw. diesem gegenüber umfasst.

Dem Anbieter können somit gewissermaßen"Nummernbänder"zugeordnet wer- den, wobei er seine eigene Katalognummer hinter einem seine Identität als An- bieter repräsentierenden Abschnitt ("Präfix") weiterhin benutzt. Hierdurch lässt sich die Verwendung von Kontext-Identifikatoren bei Katalog-Szenarien wesent- lich vereinfachen. Die Kombination des ersten Abschnitts (Präfix) mit dem zwei- ten Abschnitt (Katalognummer) kann-nach Vergabe des Präfix durch die Sys- temverwaltung-auch durch den Anbieter selbst erfolgen, wobei die Verantwor- tung für die Eindeutigkeit des Kontext-Identifikators dann natürlich bei diesem liegt.

Üblicherweise wird der über den Kontext-Identifikator informierte Abnehmer die- sen an seinem Telekommunikationsendgerät manuell oder ggf. auch per Sprach- eingabe selbst eingeben. Die oben erwähnten Möglichkeiten der Ausgabe des Identifikators an den Abnehmer können aber in einen automatischen Eingabevor- gang münden, der natürlich fehlerresistenter als die manuelle Eingabe ist. Der Identifikator wird hierzu in oder an einem Telekommunikationsendgerät, insbe- sondere durch eine mit diesem verbundene Kamera oder einen Scanner, des Ab- nehmers aus einem optischen oder akustischen Signal in ein elektrisches Signal umgewandelt.

In einer weiteren Hinsicht schließt die Erfindung den wesentlichen Gedanken ein, ein weitgehend universelles System zur Abwicklung finanzieller Transaktionen auf der Grundlage eines herkömmlichen Bankkontos ("Postpaid") oder elektronischen Guthabens ("Prepaid") anzugeben, welches insbesondere für eine Zahlungsab- wicklung im P2P-Bereich anwendbar ist, also die"Übersendung"von Geldbeträ- gen im privaten Bereich erlaubt.

Sie schließt weiter den Gedanken ein, hierzu primär ein TK-Netz zu nutzen, und zwar insbesondere die Möglichkeit einer weitgehenden Abwicklung in nahezu Echtzeit (Real Time). An das TK-Netz sind einerseits die TK-Endgeräte der das Netz nutzenden Teilnehmer und andererseits mindestens ein Transaktionsserver des Betreibers des TK-Netzes oder eines kundenorientiert arbeitenden Dienstan- bieters angeschlossen.

Eine Person-to-Person-Zahlung im Sinne der vorliegenden Erfindung setzt das Vorliegen eines für eine elektronische Guthabentransferierung geeigneten Kontos "Wallet Account"sowohl auf Seiten des Zahlers als auch des Zahlungsempfängers voraus. Die Implementierung kann einerseits in einem Zwei-Schritt-Ablauf durch (1) Zahlung an einen"Händler" (P2P-Engine) und (2) Kreditierung auf ein Zah- lungsempfängerkonto seitens des"Händlers"oder andererseits-nutzerfreundli- cher-durch Integration der P2P-Engine bei einem Kontoverwaltungsserver des Zahlers implementiert werden. Für die P2P-Engine steht nachfolgend im wesentli- chen der deutsche Terminus"Transaktionsserver", während der ebenfalls bereits erwähnte Kontoverwaltungsserver im Englischen auch als"Payment Instrument"

(PI) bezeichnet werden kann. Der Verfahrensablauf der beiden Varianten wird in den Figuren genauer beschrieben.

Zur Auslösung des P2P-Zahlungsvorganges kontaktiert der Zahler mittels seines TK-Endgerätes über ein TK-Netz (insbesondere Mobilfunknetz) oder mittels seines Datenendgerätes über ein Datennetz (speziell das Internet) den Transaktionsser- ver bzw. die P2P-Engine und spezifiziert eine Adresse oder einen anderen Identi- fikator des Empfängers und den Zahlungsbetrag. Wahlweise können zusätzlich- im internationalen Zahlungsverkehr-die Zahlungswährung und eine Textnach- richt (z. B. zum Zahlungszweck) eingegeben werden. Bei dem durch den Zahler angesprochenen Transaktionsserver oder einem m t diesem verbundenen weite- ren Transaktionsserver wird aus einem aus der Zahler-Eingabe erstellten ersten Zahlungsanweisungs-Datensatz ein letztlich die Gutschrift beim Zahlungsempfän- ger bewirkender zweiter Zahlungsanweisungs-Datensatz gebildet. Hierbei erfolgt (sofern nicht bereits bei der Eingabe geschehen) die Spezifikation eines Konten- identifikators des Zahlungsempfängers.

Werden die elektronisch geführten Konten von Zahler und Zahlungsempfänger auf verschiedenen Kontenverwaltungsservern geführt, schließt die Transformation zwischen erstem und zweitem Zahlungsanweisungs-Datensatz typischerweise die Ermittlung der Serveradresse des (zweiten) Kontenverwaltungsservers des Zah- lungsempfängers und eine an diesen gerichtete Anfrage nach dem Kontenidentifi- kator des Zahlungsempfängers ein. Nach deren Beantwortung kann die Gutschrift des Zahlungsbetrages ausgeführt werden.

In den Zahlungsvorgang ist in jedem Falle eine Authentisierung des Zahlers unter Zugriff auf Teilnehmerdaten, die ihn als Teilnehmer eines TK-Netzes identifizie- ren, vorgesehen. Sofern der Zahlungsvorgang von seinem TK-Endgerät (Mobil- funk-Endgerät) ausgelöst wird, nutzt die Authentisierung dessen MSISDN zu einer ab-initio-Authentisierung. Wird der Zahlungsvorgang hingegen von einem Daten- endgerät aus angestoßen, so ist ein Bestätigungsschritt unter Zugriff auf das TK- Netz, dessen Teilnehmer der Zahler ist, vorgesehen. Eine Bestätigungs-Anfrage ist im übrigen optional auch als zusätzlicher Schritt des erstgenannten Verfahrens vorgesehen.

Im internationalen Zahlungsverkehr hat der erste Zahlungsanweisungs-Datensatz einen ersten Währungscode und der zweite Zahlungsanweisungs-Datensatz einen zweiten, vom ersten verschiedenen Währungscode, und bei der Erstellung des zweiten Zahlungsanweisungs-Datensatzes wird eine Umrechnung aus der Betragsinformation des ersten Zahlungsanweisungs-Datensatzes in eine Betrags- information des zweiten Zahlungsanweisungs-Datensatzes aufgrund eines vorge- speicherten Umtauschverhältnisses ausgeführt. Die hierfür benötigte Hard-und Softwareausstattung wird vom Systembetreiber bzw. Dienstanbieter bereitge- stellt, und man kann sie sich in einem Umrechnungs-Server oder als zusätzliche Funktionalität eines der beteiligten Kontenverwaltungsserver realisiert denken.

Das anzuwendende Umtauschverhältnis wird vom Transaktionsserver des Sys- tembetreibers bereitgestellt, oder dieser führt auch-als Zusatzfunktionalität- die Umrechnung durch.

Die Datenübermittlungen werden von dem und zu dem Telekommunikations-End- gerät des Zahlers für eine Zahlung sämtlich per Kurznachricht gemäß SMS, Da- tenfile-Übertragung gemäß WAP oder über IVR-Sprachkommunikation ausgeführt.

Hierbei ist die SMS-Variante-speziell ohne zusätzliche Bestätigung-eher für niedrige Beträge (darunter"Micropayments") sinnvoll. Bei der WAP-Variante ist die P2P-Engine in Art eines inzwischen bekannten"WAP-Shop"ausgeführt. Vor- teilhaft dürfte jedenfalls eine Vermeidung von Wechseln im Zugriffsmedium wäh- rend der Teilschritte des Auslösens der Zahlung, der Authentisierung und der Bestätigung des Guthabenübertrages sein.

Neben der bereits angesprochenen Authentisierung des Zahlers ist vorzugsweise bei höheren Geldbeträgen auch eine solche des Zahlungsempfängers anhand von im System (insbesondere beim Transaktionsserver oder zweiten Kontenverwal- tungsserver) gespeicherten Nutzerdaten vorgesehen. Dies stellt eine wichtige Maßnahme gegen die Fehileitung erheblicher Zahlungen dar. Im übrigen ist auch eine Verfahrensführung von Vorteil, bei der der Zahler über eine geeignete Aus- führung des ersten Transaktionsservers-oder auch eine spezielle Schnittstelle zu seinem Kontenverwaltungsserver-einen Löschvorgang bezüglich der Zah- lungs-Datenübertragung auslösen, die Zahlung also stornieren kann.

In einer weiteren Option ist eine Benachrichtigung des Zahlungsempfängers über den vorgesehenen Guthaben-Übertrag vorgesehen, und in einer speziellen Fort- bildung kann dieser weiterhin ein spezielles Zahlungsinstrument (einen Konten- verwaltungsserver) spezifizieren, zu dem die elektronische Zahlung gelenkt wer- den soll. Es sind also in diesem Sinne auch aktuelle Eingriffe in den Zahlungsvor- gang seitens des Empfängers möglich.

Weiterhin ist zur Realisierung eines für den Systembetreiber bzw. Dienstanbieter wirtschaftlichen Betriebes die nachrichten-bzw. datenseitige Implementierung von Transaktionsgebühren (nachfolgend gefasst unter den Begriff"Abwicklungs- Betragsinformation) vorgesehen. Hierbei können die Transaktionskosten zu Las- ten des Zahlers oder Zahlungsempfängers gehen oder zwischen beiden aufge- spalten werden. Es wird zusammen mit der Abwicklungs-Betragsinformation dem zweiten Zahlungsanweisungs-Datensatz eine entsprechende Kennzeichnung dar- über hinzugefügt wird, ob das Zahlerkonto oder Zahlungsempfängerkonto oder beide anteilig zu belasten sind.

Zur Sicherung einer wirtschaftlich tragfähigen Ausführung internationaler Zah- lungsvorgänge zwischen Währungen, für die kein fixes Umrechnungsverhältnis besteht, ist ein sogenannter Spread im Datenübertragungsablauf zu implementie- ren. Hierzu wird bei der Umrechnung der Betragsinformation des ersten Zahlung- sanweisungs-Datensatzes (in der ersten Währung) in diejenige des zweiten Zah- lungsanweisungs-Datensatzes (in der zweiten Währung) eine entsprechende Spread-Information eingerechnet. Diese ist insbesondere in einer dem Transakti- onsserver oder Systemverwaltungs-Server zugeordneten Datenbasis gespeichert.

Wesentliche Anordnungsaspekte des vorgeschlagenen Systems ergeben sich be- reits aus den oben hervorgehobenen Verfahrensaspekten, so dass insoweit Wie- derholungen entbehrlich sind. Es versteht sich nach obigem, dass Transaktions- server eine wesentliche Komponente des vorgeschlagenen Systems darstellen und diese-je nach konkreter Systemausführung-mit TK-Endgeräten und wahlweise zusätzlich Datenendgeräten der Zahler sowie-direkt oder mittelbar über weitere Transaktionsserver-mit Kontenverwaltungsservern auf Zahler-und Zahlungs- empfänger-Seite kommunizieren. Kernstück des Systems ist in bevorzugter Aus- führung ein Systemverwaltungsserver, der mit mehreren Transaktionsservern im

wesentlichen dauerhaft verbunden ist und im übrigen eine Funktionseinheit mit einem Transaktionsserver bilden kann. Der Systemverwaltungsserver ist einem TK-Netz oder auch mehreren TK-Netzen (insbesondere Mobilfunknetz (en)) zuge- ordnet. Diese Zuordnung gilt in bevorzugter Systemausführung auch für den (bzw. mindestens einen) Kontenverwaltungsserver.

Der Systemverwaltungsserver hat typischerweise einen Ablaufprogrammspeicher zur Speicherung mindestens eines Transaktions-Ablaufprogrammes der Daten- kommunikation zwischen dem Telekommunikations-Endgerät eines Zahlers und dem Kontenverwaltungsserver bzw. dem Transaktionsserver oder den Transakti- onsservern, und ihm ist zweckmäßigerweise ein dediziertes Datenhaltungssystem zur Speicherung und Verwaltung aller gültigen Nutzerdaten und, insbesondere von zahlungsverkehrsrelevanten Daten und Kennzeichnungen stattgefundener Da- tenübertragungsvorgänge zugeordnet.

Figur 1 zeigt ein Blockdiagramm eines Herausgeber-und Erwerbersystems.

Figur 2 stellt einen Bezahlungsfluss in dem in Figur gezeigten System dar.

Figur 3 stellt eine Ausführungsform des interoperablen mobilen Bezahlungsproto- kolls (IMPP) dar.

Figur 4 stellt eine beispielhafte Architektur eines IMPP-Unterprotokolls dar.

Figur 5 stellt eine WOPP-Meldungsverarbeitung dar.

Figur 6 stellt eine Verarbeitung für eine Web-WAP-Makrobezahlung (Macropay- ment) dar.

Figur 7 stellt eine Verarbeitung für eine Web-WAP-Mikrobezahlung (Micropay- ment) dar.

Figur 8 stellt eine Verarbeitung für eine WAP-WAP-Makrobezahlung (Macropay- ment) dar.

Figur 9 stellt eine Verarbeitung für eine Web-WAP-Adressübertragung ohne Be- zahlung dar.

Figur 10 stellt eine Verarbeitung für eine Automaten-Makrobezahlung dar.

Figur 11 stellt eine Verarbeitung für eine statische OfferID-Erzeugung dar.

Figur 12 stellt ein IMPP Statusmodell für direkte Makrobezahlungen dar.

Figur 13 stellt ein IMPP Statusmodell für Makrobezahlungsgutschriften (Macro- payment credits) dar.

Figur 14 stellt ein IMPP Statusmodell für verzögerte Makrobezahlungen dar.

Figur 15 stellt ein IMPP Statusmodell für teilweise Makrobezahlungen dar.

Figur 16 stellt ein IMPP Statusmodell für direkte Mikrobezahlungen dar.

Figur 17 stellt ein IMPP Statusmodell für verzögerte Mikrobezahlungen dar.

Figur 18 stellt ein IMPP Statusmodell für Mikrobezahlungsgutschriften (Micropay- ment credits) dar.

Figur 19 stellt eine IMPP Meldungsstruktur dar.

Figur 20 stellt eine Verarbeitung zur Versionsabsprache im Kontext von IMPP dar.

Figur 21 stellt ein OfferID Statusdiagramm dar.

Figur 22 stellt eine Verarbeitung für eine beispielhafte Währungsumrechnung dar.

Figur 23 stellt eine Verarbeitung für Mikrobezahlungsausgleich und-abrechnung (Micropayment clearing and settlement) dar.

Figur 24 stellt ein Ausgleichsdatenstatusdiagramm dar.

Figur 25 stellt eine Verarbeitung zur Gebührenverteilung dar.

Figur 26 stellt eine Verarbeitung zur Rechnungsstellung dar.

Figur 27 stellt eine Hintergrundverarbeitung (back-office processing) dar.

Fig. 28 zeigt eine schematische Übersichtsdarstellung wesentlicher Komponenten bzw. Schichten sowie Prozessabläufe eines erfindungsgemäßen Systems.

Fig. 29A bis 29C zeigen eine schematische Ablaufdarstellung (Sequence Diagram) sowie eine Liste der Schrittfolge einer Ausführungsform des erfindungsgemäßen Verfahrens (Web-WAP-Scenario).

Fig. 30A bis 30C zeigen eine schematische Ablaufdarstellung (Sequence Diagram) sowie eine Liste der Schrittfolge einer weiteren Ausführungsform des erfindungs- gemäßen Verfahrens (WAP-WAP-Scenario).

Fig. 31A bis 31C zeigen eine schematische Ablaufdarstellung (Sequence Diagram) sowie eine Liste der Schrittfolge einer weiteren Ausführungsform des erfindungs- gemäßen Verfahrens (Push-Fall-Back-Scenario).

Fig. 32A und 32B zeigen eine schematische Ablaufdarstellung (Sequence Dia- gram) sowie eine Liste der Schrittfolge bei der Erzeugung einer statischen Offe- rID im Kontext eines Ausgabeautomaten/TV-Shopping-Szenarios.

Fig. 33A und 33B zeigen eine schematische Ablaufdarstellung (Sequence Dia- gram) sowie eine Liste der Schrittfolge bei der Löschung einer statischen OfferID im gleichen Kontext.

Fig. 34A bis 34C zeigen eine schematische Ablaufdarstellung (Sequence Diagram) sowie eine Liste der Schrittfolge einer weiteren Ausführungsform des erfindungs- gemäßen Verfahrens (Ausgabeautomaten/TV-Shopping-Szenario).

Fig. 35A und 35B zeigen ein schematisches Ablaufdiagramm (Sequence Diagram) sowie eine Liste von Schritten beim Ablauf einer Clearing-Prozedur bei der Trans- aktion größerer Geldbeträge (Makro Payment).

Fig. 36A bis 36C zeigen eine schematische Ablaufdarstellung (Sequence Diagram) sowie eine Liste der Schrittfolge einer weiteren Ausführungsform des erfindungs- gemäßen Verfahrens (Micro-Payment-Szenario mit"Stored Value Accounts").

Fig. 37 zeigt eine schematische synoptische Darstellung aus Systemstruktur und Verfahrensschritten bei einer ersten Verfahrensvariante.

Fig. 38 zeigt eine Liste der Verfahrensschritte bei dieser ersten Variante.

Fig. 39 zeigt eine schematische synoptische Darstellung aus Systemstruktur und Verfahrensschritten bei einer zweiten Verfahrensvariante und Fig. 40 zeigt eine Liste der Verfahrensschritte bei dieser zweiten Variante.

Vorliegend wird ein interoperables mobiles Bezahlungsprotokoll (IMPP) im Zu- sammenhang mit einem System beschrieben, welches Nachrichtenübermittiung zwischen einer Herausgeberdomäne und einer Erwerberdomäne vorsieht. Sowohl mobile Geräte als auch nicht mobile Geräte können in Verbindung mit dem IMPP benutzt werden. Das IMPP ist nicht auf einen Einsatz im Zusammenhang mit dem hier beschriebenen spezifischen System begrenzt und kann in anderen Systemen mit Architekturen, welche von der hier beschriebenen Systemarchitektur abwei- chen, genutzt werden.

Der Begriff"interoperabel"bezieht sich auf die Interoperationen, welche zwi- schen der Herausgeberdomäne und der Erwerberdomäne ausgeführt werden. Der Begriff"Herausgeberdomäne" (manchmal hier auch als"Herausgeber"bezeich- net), wie hier verwendet, bezieht sich auf Geldbörsenherausgeber (wallet issues).

Bezahlungsmittel werden autorisiert durch z. B. Banken oder sind Wertspeicher- karten. Ein Herausgeber erklärt einen Kunden für gültig und der Kunde verfügt über Bezahlungsmittel in seiner Geldbörse. Bei einigen Transaktionen, z. B. Mik- robezahlung, kann ein telco oder ISP ein Herausgeber sein. Der Begriff"Erwer-

berdomäne" (manchmal hier als ein"Erwerber"bezeichnet), wie hier benutzt, be- zieht sich auf Institutionen, welche von Händlern transaktionsbezogene Daten erwerben und diese Daten an ein Ausgleichsnetzwerk zur Berechtigung senden.

Die hier benutzten Begriffe"Kunde"und"Käufer"betreffen die Besitzer von Be- zahlungsmitteln (z. B. Kreditkarten), welche Einkäufe bei einem Händler tätigen.

Der Begriff"Händler"bezieht sich auf diejenigen, welche Waren zum Verkauf an- bieten und/oder Dienstleistungen für einen Kunden gegen Bezahlung durch den Kunden zur Verfügung stellen. Der Begriff"Geldbörsen (wallet) server" bezieht sich auf ein sicheres Repositorium (secure repository) für Bezahlungsberechti- gungsnachweise von Karteninhabern, welche einem Kunden erlauben, eine ent- fernte (remote) Bezahlungstransaktion von irgendeinem der mehreren Geräte ab- zuschließen. Der Begriff"Bezahlungs (payment) server" bezieht sich auf einen Ser- ver, welcher Bezahlungsanfragen aus der Herausgeberdomäne (z. B. eines Kun- den-oder Geldbörsenservers) an Händler akzeptiert. Ein Bezahlungsserver kann auch Bereitstellungsfähigkeiten für Händler aufweisen.

Nachfolgend wird ein allgemeiner Überblick in Form einer Beschreibung eines Systems gegeben, welches elektronische Transaktionen ermöglicht, einschließlich mittels Geräten wie an Netzwerke gekoppelte Computer (z. B. Weitbereichsnetz- werken (wide area networks) wie dem Internet) und drahtloser Geräte (z. B. mo- bile Telefone) ausgeführte Transaktionen. Dem Überblick über das System fol- gend sind Details hinsichtlich des IMPP beschrieben. Zusätzlich wird eine detail- lierte Beschreibung der Verarbeitung geliefert, welche unter Steuerung des IMPP in dem beispielhaften System auftritt.

Das System setzt voraus, dass ein Herausgeber Verträge mit Konsumenten hat und deren Konten (Account) Informationen handhabt. Die Konteninformationen umfassen Bezahlungs-und Sicherheitsinformationen. Der Händleraquisiteur (Er- werberdomäne) verfügt über Verträge mit Händlern und stellt Bezahlungsdienst- leistungen zur Verfügung. Eine Zentralprozessorplattform (interop domain) ver- waltet die Interoperabilität und bietet zentrale Dienstleistungen wie Transakti- onsausgleich und Abrechnung an. Diese Architektur hält herkömmliche Händler- und Händleraquisiteursarbeitsabläufe (work flows) aufrecht und erweitert die existierende Bezahlungsinfrastruktur um mobile Bezahlungen.

Unter besonderer Bezugnahme auf Figur 1 umfasst das System eine Zentralpro- zessorplattform (CPP), welche mit einem Geldbörsenserver und einem Bezah- lungsserver kommuniziert. Die CPP führt sowohl Realzeit (real time) und Nicht- Realzeit (non-real time) Verarbeitung durch. Zum Beispiel vollzieht die CPP Wei- terleitungs (Routing, OfferID) -, Such (look-up)-, Währungsumrechnungs-und Transaktionsverwaltungsfunktionen in Realzeit (real time). Nicht-Realzeit-Ver- arbeitung umfasst z. B. Mikrobezahlungsabrechnung und Ausgleich, Gebührenbe- arbeitung und Rechnungsstellung und Anlagenausschüttung.

Die CPP umfasst eine Weiterleitungsmaschine (routing engine) zum Weiterleiten von transaktionsbezogenen Nachrichten zwischen Geldbörsenservern und Bezah- lungsservern in Übereinstimmung mit dem IMPP. Insbesondere unterbricht die Weiterleitungsmaschine das IMPP und leitet Anfragen weiter, welche Bezahlungs- transaktionen wie auch Antworten zwischen externen Parteien einschließen.

Transaktionen (Makro-und Mikrobezahlungen) erfolgen deshalb durch die Wei- terleitungsmaschine.

Die CPP umfasst ebenso einen Währungsumrechnungsserver, welcher mit einer Umrechnungskursdatei gekoppelt ist, einen Angebotsidentifikations (OfferID) ser- ver, welcher mit einem OfferID Repositorium (repository) verbunden ist, einen Such (look-up) server, welcher mit einem Geldbörsenserver (WS)/Zahlungsser- ver (PS) -Verzeichnis verbunden ist und einen Negativdateiserver, welcher mit ei- ner Kunden-und Händiernegativdatei verbunden ist. Die CPP umfasst weiterhin eine Endstück (back end)-Bearbeitungsfunktionalität wie Mikrobezahlungsaus- gleich und-abrechnung und Gebührenabrechnung und-verwaltung. Insbesondere umfasst die CPP einen Gebührenabrechnungs-und-verwaltungsserver und einen Mikrobezahlungsserver, welche mit einem Transaktionsprotokoll (lock) gekoppelt sind. Der Gebührenabrechnungs-und-verwaltungsserver ist mit einer Neuunter- nehmensregeldatenbank gekoppelt, welche Regeln zur Gebührenabrechnung und Ausschüttung von Anlagen an Unternehmen enthält, welche neu in dem System sind. Der Gebührenabrechnungs-und-verwaltungsserver ist auch an eine Daten- bank gekoppelt, welche Abrechnungsdaten enthält.

Die Weiterleitungsmaschine der CPP hört IMPP-Nachrichten ab, wodurch es meh- reren Geldbörsenservern ermöglicht wird, mit mehreren Bezahlungsservern über eine zentrale Instanz zu kommunizieren. Durch das Weiterleiten von Bezahlungs- transaktionen durch die CPP hat das Hinzufügen zusätzlicher Teilnehmer keinen Einfluss auf die existierende Installation und vereinfacht das Hinzufügen zusätzli- cher Teilnehmer.

Mobile Bezahlungen, Anfragen und Antworten werden zwischen Geldbörsenser- ver-und Bezahlungsserverinstanzen weitergeleitet. Andere CPP-Komponenten, welche zentralisierte Aufgaben wie den OfferID-Generator, Suchdienst und FX- Server ausführen, werden durch die Weiterleitungsmaschine in Anspruch genom- men, um die Bezahlungsprozesse zu unterstützen. Die Transaktionsprotokollein- träge werden so erzeugt, dass diese den gesetzlichen Erfordernissen entsprechen und gekoppelte (offline mode) Prozesse wie Gebührenabrechnung ermöglichen.

Die CPP verarbeitet auch Adresswechselanfragen, Altersprüfanfragen und Anfra- gen zum Wechsel des Bezahlungsinstruments. Qualitätskennungen werden zu- sammen mit Anfragen/Antworten übertragen, welche das Qualitätsniveau der zugrundeliegenden Daten angeben.

Die CPP-Weiterleitungsmaschine empfängt externe Benachrichtungen über Mak- robezahlungsberechtigungen und vervollständigt die Transaktionsprotokolle und tauscht Benachrichtigungen über alle Statusänderungen zwischen den anderen einbezogenen Parteien aus, um die Transaktionsprotokolle des WS, MS und der Encorus-Prozessorplattform konsistent zu halten.

Mit Mikrobezahlungen wird die Berechtigung zwischen WI und Anbietern von Mik- robezahlungsmitteln durchgeführt. Die Berechtigungen werden deshalb mit den Bezahlungsmeldungsflüssen an den Bezahlungsserver übertragen. Bei einer in Gang befindlichen Bezahlungstransaktion behält die Weiterleitungsmaschine Transaktionsdatensätze (transaction records) bei und speichert alle Informatio- nen über eine Transaktion zusammen mit einer eindeutigen TransaktionsID (tran- sactionID).

Die Suche nach dem Bezahlungsserver und in eine Transaktion einbezogenen Händler wird auf Basis einer OfferID (OID) oder RangeID durchgeführt. Durch

Ausführen der Suche auf Basis einer OfferID wird die BasketID aufgelöst und zu- sammen mit der OID an den MC übertragen, um den Einkaufskorb (shopping basket) zu erfragen. Der spezielle Händler bestimmt, ob die OID oder die Bas- ketID zum Identifizieren des Einkaufskorbs benutzt werden. Durch Ausführen der Suche auf Basis einer RangeID wird die Kombination aus RangeID und Händlerka- talognummer an den MC übertragen, um den Einkaufskorb zu erfragen.

Die Teilnehmerliste enthält alle MSISDNs und Pseudonyme (alises) der Kunden, welche für mobile Bezahlung eingetragen sind. Für jedes MSISDN/Pseudonym wird die HeimgeldbörsenserverID (home wallet server ID) ebenso gespeichert.

Die MSISDNs/Pseudonyme, welche nicht eingetragen sind, können bei der Verar- beitung durch die CPP frühzeitig abgewiesen werden.

Die OfferID identifiziert einen Einkaufskorb. Um die Korbinformationen in einem übergreifenden (cross) -WI/MA-Szenario zu identifizieren wird die OfferID zentral erzeugt. Die OfferID kann für die mobilen Bezahlungsszenarios sowohl für Mikro- als auch für Makrobezahlungen benutzt werden. In den meisten Fällen werden OfferIDs über ein mobiles Gerät mit begrenzten Fähigkeiten hinsichtlich Größe des Displays und Benutzbarkeit der Tastatur eingegeben.

Der OfferID-Generator erzeugt eine OfferID auf Anfrage und das OfferID-Reposi- torium speichert erzeugte OfferIDs zusammen mit zusätzlichen Daten für Such- zwecke und verwaltet die OfferID-Lebensdauer (life time). Nachfolgende Bezah- lungstransaktionen können dieselbe OfferID für Bezahlungstransaktionen (z. B.

VM, TV Einkauf (shopping)) nutzen. Statische OfferIDs können durch die Händler auf Monats-oder Jahresbasis"gemietet"werden. Dynamische OfferIDs kenn- zeichnen ein temporäres Angebot, weisen eine bestimmte Lebensdauer auf und werden durch einen einzelnen Kunden genutzt. Eine dynamische OfferID wird au- tomatisch gelöscht, sobald eine Transaktion abgeschlossen oder die maximale Lebensdauer überschritten ist.

Das OfferID-Repositorium speichert Informationen über eine angefragte OfferID.

Wenn Altersprüfungen, Adresswechsel oder GI-Datentransfer anfragt ist, werden die relevanten Kennungen in dem OfferID-Repositoriumsdatensatz gesetzt. Das OfferID-Repositorium überwacht auch die ausgegebenen OfferIDs und setzt einen

OfferID-Status auf"gesperrt" (black-out), sobald die damit verbundene Lebens- dauer ausläuft. Das OfferID-Repositorium unterstützt auch manuelle Löschungs- anfragen. Die Suchdienste nutzen das OfferID-Repositorium, um den damit ver- knüpften Bezahlungsserver aufzufinden.

Die Händlernegativdatei hindert eingetragene Händler entweder daran, sich für mobile Bezahlung bei irgendeinem Händleraquisiteur einzutragen oder irgendeine Transaktion im eingetragenen Zustand einzuleiten. In der Händlernegativdatei werden die ID, die URL und der Händlername zusammen mit einer Zeitangabe gespeichert.

Die Käufernegativdatei hindert eingetragene Käufer entweder daran, sich für mo- bile Bezahlung an irgendeinem Geldbörsenserver einzutragen oder irgendeine Transaktion im eingetragenen Zustand einzuleiten. In der Käufernegativdatei werden die ID, der Name, der Vornahme, das Geburtsdatum und die MSISDN zu- sammen mit einer Zeitangabe gespeichert.

Da internationale Transaktionen durch CPP abgewickelt werden, stellt CPP eine zentrale Auslandswechselkursakquisition (foreign exchange (FX) rate acquisition), eine Kursdifferenzverwaltung (spread management) und einen Währungsumrech- nungsdienst zur Verfügung. Die CPP berechnet Beträge in Kundenwährung (wenn diese verschieden von der Händlertransaktionswährung sind). Der FX-Server spei- chert Auslandswährungswechselkurse und führt Währungsumrechnungen zur Ab- rechnung von internationalen Mikrobezahlungen und Gebührenabrechnungen.

Der Geldbörsenserver (WS) kommuniziert mit Käufergeräten z. B. über gerätespe- zifische Gateways wie WAP und SMS-Gateways und speichert käufer-und trans- aktionsbezogene Daten wie MSISDN, Rechnungs-und Versandadresse, Kreditkar- tennummern. Der Geldbörsenserver stellt Kundenbetreuungsfunktionalitäten zur Verfügung und wickelt die Bezahlungsprotokollverarbeitung ab. Der Geldbörsen- server sendet Berechtigungsanfragen an ein Mikrobezahlungsmittel (, uPI) weiter.

Jeder Geldbörsenherausgeber stellt wenigstens ein Mikrobezahlungsmittel bereit, welches entweder durch den Herausgeber betrieben wird oder an dem Geldbör- senserver einer dritten Partei aufgenommen wird. Das uPI kann verschiedenen

Typs sein, z. B. ein dediziertes Wertspeicherkontensystem, ein Telco-Vorauszah- lungs (prepaid) konto oder eine Telco-Telefonbörse.

Der Bezahlungsserver PS verarbeitet das IMPP-Protokoll zwischen CPP und Händ- leraquisiteur und verarbeitet ein offenes Bezahlungsprotokoll (OPP (open pay- ment protocol)) in Richtung einer Händlerkomponente. Der PS ist über ein Bezah- lungsgateway mit Makrobezahlungsbefugten (z. B. Kreditkartenbezahlungsbefug- ten) verbunden, um Berechtigungsanfragen weiterzuleiten. Die Händlerkompo- nente (MC (merchant component)) ist in dem Einkaufssystem des Händlers inte- griert, um ein OPP zu ermöglichen.

Üblicherweise und vor der Bezahlungstransaktion greift ein Käufer auf ein Ge- schäft eines Händlers zu, z. B. über einen spezifischen Einkaufskanal (z. B. WEB, WAP, IVR, TV) oder liest Hinweise und Produktangebote an einem Verkaufsauto- maten. Zum Bestätigen der Bezahlungen nutzt der Käufer sein mobiles Telefon, um mit einem Geldbörsenserver Verbindung aufzunehmen (Zugriffsszenario (pull Szenario)) oder wird durch einen Geldbörsenserver angerufen (Anschubszenario (push szenario)). Die Berechtigung wird durch das Mobiltelefonnetzwerk zur Ver- fügung gestellt und die Berechtigung zur Bezahlung für irgendeinen Typ eines Bezahlungsmittels (z. B. Mikrobezahlungsmittel, Kreditkarte, Debitkarte) kann durchgeführt werden.

Insbesondere und unter Bezugnahme auf Figur 2 legt ein 3-Domänen-Modell ei- nen Prozess für elektronische Bezahlungen fest. Der Begriff"Herausgeberdomä- ne"bezieht sich auf Herausgeber und Eigentümer von Bankkarten oder anderen Bezahlungsmitteln (z. B. Herausgebern und Kunden) und auf diejenigen, welche im Auftrag der Herausgeber handeln (z. B. der Geldbörsenserver). Der Begriff "Akquisiteurdomäne"betrifft diejenigen, welche Bezahlungen aus einer Heraus- geberdomäne akquirieren. Der Begriff"Interoperabilitätsdomäne"betrifft die Schnittstelle zwischen der Herausgeber-und Akquisiteurdomäne zum Ermöglichen von Interoperationen (d. h. Abläufen zwischen der Herausgeberdomäne und der Akquisiteurdomäne) für elektronische Bezahlungen.

Der übliche Bezahlungsfluss wird weiter unten als eine Schrittfolge und mit Bezug auf Figur 2 beschrieben. Der unten beschriebene Bezahlungsfluss basiert auf ei-

nem Einkauf, welcher über ein Netzwerk wie einem Weitbereichsnetzwerk (z. B. dem Internet) ausgeführt wurde. Natürlich sind auch andere Bezahlungsflüsse möglich und die weiter unten fortgeführte Beschreibung stellt nur ein Beispiel dar.

Schritt 0. Einkaufen. Ein Kunde blättert (kauft ein) in einem Angebot von Wa- ren/Dienstleistungen eines Händlers. Im Ergebnis wird ein Auftrag in dem Ein- kaufssystem des Händlers gespeichert.

Schritt 1. Initiieren der Bezahlung. Am Schluss des Einkaufens klickt der Kunde auf einen Verweis (Link) in dem Geschäft, welcher den Kunden an den Geldbör- senserver weiterleitet. Die URL enthält Informationen, welche den Geldbörsen- server in die Lage versetzen, den Kontext der Bezahlung (z. B. Händler-URL und Auftragsidentifikation) zu bestimmen. Der Kunde stellt dem Händler die URL des Geldbörsenservers zur Verfügung (z. B. kann der Kunde die URL aus einer Herun- terzieh (drop-down) -Liste auswählen), so dass der Händler die richtige URL für den Verweis zusammenstellen kann. Demzufolge kann der Geldbörsenserver we- nigstens den Händler und den Auftrag identifizieren.

Schritt 2. Berechtigung. Der Kunde loggt sich in den Geldbörsenserver ein. Die Berechtigung wird durch den Geldbörsenserver durchgeführt (welcher in vielen Fällen gleich dem Herausgeber ist). Ist der Kunde einmal berechtigt, behält der Kunde Zugriff auf die Kundendaten.

Schritt 3. Erlangen der Auftragsinformation. Der Geldbörsenserver ruft die Auf- tragsinformation (Auftragsbeschreibung, Zahlungsbetrag) von dem Händler ab.

Der Händler gibt ebenfalls die URL seines Bezahlungsservers und die akzeptierten Bezahlungsarten zurück. Der Geldbörsenserver zeigt dem Kunden die Auftragsda- ten an.

Schritt 4. Auswahl des Bezahlungsmittels. Der Geldbörsenserver stellt, basierend auf der Liste der vom Händler akzeptierten Bezahlungsarten und den gespeicher- ten Bezahlungsmitteln des Käufers, eine Liste verfügbarer Bezahlungsarten/Mittel dar, aus welcher der Käufer wählen kann. Der Geldbörsenserver ruft die Auf- tragsdetails und die akzeptierten Bezahlungsarten ab.

Schritt 5. Prüfen des Bezahlungsmittels. Der Geldbörsenserver tritt zuerst mit dem Herausgeber in Verbindung, um zu überprüfen, ob das ausgewählte Bezah- lungsmittel gültig ist. Der Herausgeber kann weitere Daten (neben einer einfa- chen Ja/Nein-Antwort) an diesem Punkt (z. B. bei einem einmaligen Token, wel- cher speziell für die kommende Bezahlung verwendet wird) zurückgeben.

Schritt 6. Bezahlung. Der Geldbörsenserver sendet im Auftrag des Kunden eine Bezahlungsanfrage an den Bezahlungsserver.

Schritt 7. Überprüfen des Auftrags. Der Bezahlungsserver tritt mit dem Einkaufs- system des Händlers in Verbindung, um zu überprüfen, ob die von dem Geldbör- senserver empfangenen Auftragsdaten authentisch sind. Der Bezahlungsserver empfängt alle Daten, welche zum Verarbeiten der Bezahlung benötigt werden.

Schritt 8. Erfassung. Der Bezahlungsserver leitet die Bezahlungsdaten an den Ak- quisiteur weiter. Der Erfassungsschritt kann asynchron ausgeführt werden, wenn eine hinausgeschobene Belieferung verwendet wird.

Schritt 9. Ausgleich. Der Akquisiteur tätigt eine physische Bezahlung, d. h. der Akquisiteur führt die Bezahlungsanfrage über ein Geldinstitut in einer nachge- stellten (back end) Operation aus. Der Ausgleich kann asynchron (z. B. in Stapeln (batches)) erfolgen. Das Ausgleichsnetzwerk verarbeitet die Transaktion und das Geld wird auf das Konto des Händlers überführt.

Schritt 10. Benachrichtigung. Der Bezahlungsserver benachrichtigt den Händler über den Erfolg der Transaktion. Die Benachrichtigung kann auch asynchron er- folgen.

Schritt 11. Lieferanfrage. Der Geldbörsenserver versorgt den Händler mit der Lie- feradresse. Dieser Schritt kann an anderen Punkten der Meldungsfolge durchge- führt werden, z. B. vor der Bezahlung oder später, asynchron.

Viele Meldungen können berechtigungsähnliche Elemente mit sich führen. Z. B. prüft bei einer SET-Erfassungsanfrage (Capture Request) das SET-Gateway die

Unterschrift des Karteninhabers. Gegenwärtige Bezahlungssysteme können auch einige dieser Meldungen weglassen oder die Art und Weise, wie bestimmte In- formationen verarbeitet werden, kann verschieden sein, z. B. kann die Benach- richtigung durch den Käufer an den Händler zurückgeleitet werden oder in eini- gen Fällen völlig weggelassen werden. Die Schritte können auch miteinander ver- flochten oder weiter aufgespalten sein.

Protokoll Das Protokoll umfasst verschiedene Unterprotokolle. Jedes Unterprotokoll verfügt über seinen eigenen festgelegten Umfang mit klaren Grenzen zu anderen Unter- protokollen.

In einer beispielhaften Ausführungsform wird ein Unterprotokoll als das interope- rable mobile Bezahlungsprotokoll (IMPP) bezeichnet und für Meldungen zwischen und über den Geldbörsenserver OpCo und das Bezahlungsserverprotokoll genutzt.

Das andere Unterprotokoll ist das offene Bezahlungsprotokoll für den Informati- onsaustausch zwischen dem Bezahlungsserver und dem Händlersystem.

Das IMPP legt die Kommunikation zwischen den folgenden Komponenten durch die OpCo-Domäne fest.

Geldbörsenserver OpCo Bezahlungsserver Händlersystem Eine beispielhafte Ausführungsform des IMPP ist in einem in Figur 3 dargestellten Modell beschrieben. Das IMPP führt eine zentrale Instanz zum Meldungsweiterlei- ten und anderer bezahlungsbezogener Verarbeitungen ein, welche hier auch manchmal als die OpCo-Domäne bezeichnet werden. Das OpCo hält die zentralen Angebotsdaten und findet in bestimmten Szenarien den Geldbörsenserver des Kunden während der Bezahlungseinleitung heraus. Weiterhin stellt das OpCo (über die CPP) das Weiterleiten von Bezahlungsmeldungen in beiden Richtungen zwischen einem Geldbörsenserver und einem Bezahlungsserver zur Verfügung.

Bezugnehmend auf Figur 3 enthält der Geldbörsenserver Kernkundendaten, wel- che zur Berechtigung und Bezahlung vorrangig sind, genauso wie eine Transakti- onshistorie.

Der Geldbörsenserver wird während der Bezahlungseinleitungsphase angesteuert (triggered) und sendet nachfolgend Bezahlungsmeldungen an den Bezahlungsser- ver über das OpCo. Der Geldbörsenserver wird durch das OpCo benachrichtigt, wenn sich der Status einer Bezahlungstransaktion geändert hat und kann den Status einer bestimmten Transaktion abfragen, um die Transaktionshistorie zu aktualisieren.

Der Bezahlungsserver hält die Händler-Kerndaten für die Bezahlung und die Transaktionshistorie. Der Bezahlungsserver empfängt auch Bezahlungsmeldungen von dem OpCo und verarbeitet die Meldungen. Insbesondere sendet der Bezah- lungsserver Meldungen an die Bezahlungsbefugte auf Seiten des Akquisiteurs und löst Ergebnisbenachrichtigungen an das OpCo und das Händlersystem aus. Der Bezahlungsserver sendet und empfängt die erforderliche Information an/von dem Händlersystem während der verschiedenen Phasen des Bezahlungsprozesses.

Der Begriff"Händlersystem"betrifft ein Einkaufssystem und Bezahlungs- stecker (plug-in)-Komponenten, welche auf der lokalen Domäne eines 3D-Modell- konformen Bezahlungssystems des Händlers bereitgestellt werden. Das Händler- system sendet und empfängt die erforderlichen Informationen an/von dem Be- zahlungsserver während der verschiedenen Phasen des Bezahlungsprozesses. Das Händlersystem stellt eine lokale technische Indikation des Bezahlungssystems in das Einkaufssystem des Händlers zur Verfügung, oft ergänzt durch einen Ein- kaufsstecker (shopping plug-in).

Im weiteren erfolgt eine Beschreibung des Verfahrens oder Protokolls, welches in Verbindung mit den Nachrichten zwischen dem Geldbörsenserver und dem Bezah- lungsserver in Verbindung mit einer Transaktion verwendet wird, wie in Figur 3 dargestellt.

Schritt 1. Einkaufen. Ein Kunde sucht (kauft ein) Waren/Dienstleistungen und ein Auftrag wird in dem Einkaufssystem des Händlers gespeichert.

Schritt 2 und 3. Initialisieren des Angebotskontextes. Am Ende des Einkaufs klickt der Kunde auf einen Verweis in dem Geschäft, welcher das Senden des Ange- botskontextes von dem Einkaufssystem an den Bezahlungsserver auslöst. Die An- frage wird durch den Bezahlungsserver an das OpCo weitergeleitet. Der Ange- botskontext wird gespeichert und die diesbezügliche OfferID wird an den Bezah- lungsserver und an das Händlersystem in der Antwort zurückgesendet. Der Ange- botskontext umfasst Informationen, welche anzeigen, ob eine Alterprüfung durchgeführt werden soll und ob eine Lieferadresse von dem Händler gefordert wird.

Schritt 4. Anzeigen der OfferID. Der Käufer bekommt entweder die OfferID ange- zeigt, um die Interaktion über den (verschiedenen) Bezahlungskanal weiterzufüh- ren, oder der Käufer wird an seinen Geldbörsenserver über das OpCo (mit dem- selben Bezahlungskanal, nicht gezeigt) weitergeleitet. Das Herausfinden der Geldbörsen/Bezahlungsserver-URL wird innerhalb von OpCo und URL durchge- führt, wenn dies erforderlich ist. Die URL ist nicht erforderlich, wenn der Geld- börsenserver die Adresse des Bezahlungsservers nicht braucht. Bei dem IMPP kann der Bezahlungskanal von dem Einkaufskanal verschieden sein. Es wird dem Käufer genügend Information geliefert, um den Auftrag identifizieren zu können und der CPP das Erzeugen eines Bezahlungsaufrufs zu ermöglichen.

Schritt 5. Eingeben der OfferID. Der Käufer wird gebeten, die von dem Geschäft empfangene OfferID in seine Geldbörse einzugeben. Der Käufer wird am Geldbör- senserver durch das MSISDN des Mobiltelefons des Käufers in dem Bezahlungs- kanal identifiziert und berechtigt.

Schritt 6. Bezahlungsaufruf. Der Geldbörsenserver leitet die OfferID an das OpCo und erhält die Bezahlungsaufrufinformation zurück. Dies umfasst, ob eine Alters- prüfung durchgeführt werden soll und ob eine Lieferadresse von dem Händler ge- fordert wird. Der Käufer wird berechtigt und erhält Zugang zu seinen Daten.

Schritt 7. Übertragen des Angebots. Der Geldbörsenserver sucht die Auftragsin- formationen (z. B. Auftragsbeschreibung, letztendlicher Zahlungsbetrag) heraus.

Schritt 8. Die Daten werden durch das OpCo an den zugehörigen Bezahlungsser- ver weitergeleitet.

Schritt 9. Der Bezahlungsserver fragt Auftragsdetails von dem Händler ab. Das Händlersystem gibt ebenfalls die akzeptierten Bezahlungsarten zurück. Der Geld- börsenserver zeigt dann dem Kunden die letztendlichen Auftragsdaten an. Der Meldungsaustausch verläuft durch das OpCo, aber nicht direkt zu dem Händler wie in dem 3D-Modell. Der Geldbörsenserver braucht deshalb die Netzwerkadres- se des Händlers nicht zu kennen. Der Geldbörsenserver leitet ebenfalls die Lie- feradresse an den Händler zum Neuberechnen des letztendlichen Zahlungsbetrags und das Ergebnis einer möglicherweise von dem Händler gewünschten Altersprü- fung weiter. Der Geldbörsenserver empfängt die Auftragsdetails und die akzep- tierten Bezahlungsarten. Die zu verwendenden Bezahlungsmittel werden ausge- wählt und für gültig erklärt.

Schritt 10. Auswählen des Bezahlungsmittels. Der Geldbörsenserver stellt, basie- rend auf der Liste der akzeptierten Bezahlungsarten des Händlers und gespei- cherter Bezahlungsmittel des Kunden, eine Liste verfügbarer Bezahlungsar- ten/Mittel dar, aus welcher der Kunde wählen kann.

Schritt 11. Vorberechtigung. Der Geldbörsenserver tritt mit der Bezahlungsbefug- ten auf der Seite des Herausgebers in Verbindung, um zu überprüfen, ob die ausgewählten Bezahlungsmittel gültig sind, um Limitprüfungen durchzuführen und um eine Bezahlung im Falle eines Neufirmenschemas, welches zur interope- rablen Mikrobezahlung konform ist, vor zu berechtigen.

Schritte 12 und 13. Berechtigen der Bezahlung. Der Geldbörsenserver sendet im Auftrag des Kunden eine Bezahlungsanfrage an das OpCo. Dies kann das Ergeb- nis einer Vorberechtigung im Falle von schemakonformen Mikrobezahlungen um- fassen. Das OpCo leitet die Anfrage an den zugehörigen Bezahlungsserver weiter.

Der Bezahlungsserver empfängt alle Daten, welche zur Verarbeitung der Bezah- lung benötigt werden.

Schritt 14. Gegenprüfung des Angebots. Der Bezahlungsserver tritt mit dem Ein- kaufssystem des Händlers in Verbindung, um zu prüfen, ob die von dem Geldbör- senserver empfangenen Auftragsdaten authentisch sind.

Schritt 15. Berechtigung. Der Geldbörsenserver leitet die Bezahlungsdaten im Fal- le von Makrobezahlungen an die Bezahlungsbefugte auf Seiten des Akquisiteurs weiter oder prüft im Falle von schemakonformen Mikrobezahlungen das Ergebnis der Vorberechtigung. Beide Schritte 11 oder 16 werden sich gegenseitig aus- schließend durchgeführt, um eine Bezahlung durch OpCo zu berechtigen. Das Ausgleichsnetzwerk verarbeitet die Transaktion.

Schritt 16. Abrechnung. Die Bezahlungsbefugte auf Seiten des Akquisiteurs nimmt die physikalische Bezahlung vor, d. h. verarbeitet die Anfrage in den fi- nanztechnischen Endkomponenten (financial back-ends). Das Ausgleichen kann asynchron (z. B. in Stapeln (batches)) ausgeführt werden. Der Geldbörsenserver benachrichtigt den Händler über den Erfolg der Transaktion. Eine derartige Be- nachrichtigung kann auch asynchron erfolgen. Der Händler weiß deshalb, ob die Bezahlung erfolgreich war und ist in der Lage, mit der Lieferung der Waren zu beginnen.

Schritt 17. Lieferung. Das Ergebnis der Bezahlung wird dem Kunden angezeigt.

Ist die laufende Bezahlung abgeschlossen, kann der Kunde die Interaktion mit dem Geschäft fortführen. Für den Kunden ist ein Bezahlungsbeleg typischerweise wichtig, insbesondere um den Zugriff auf den digitalen Inhalt unmittelbar nach der Bezahlung zu beginnen. Die Waren werden in dem Einkaufskanal oder asyn- chron geliefert. Der Geldbörsenserver empfängt einen Bezahlungsbeleg im Auf- trag des Käufers.

Schritt 18 bis 19. Erfassung. Abhängig von dem Bezahlungssystem auf Seiten des Akquisiteurs können zurückgestellte oder aufgeteilte Beträge erfasst werden und die Bezahlung wird (teilweise) zurückerstattet oder ein Guthaben wird durch den Händler asynchron vergeben. Diese Aktion kann durch Händler in den Einkaufs- systemen ausgelöst werden und wird an den Bezahlungsserver weitergeleitet. Die Erfassungsanfrage wird durch den Bezahlungsserver an die Bezahlungsbefugte

auf Seiten des Akquisiteurs weitergeleitet. Das Geld wird dem Händler verbucht und nach Abrechnung übertragen.

Schritte 20 bis 23. Statusbenachrichtigungen und Anfragestatus.

Unter jetziger Bezugnahme auf Figur 4 verwaltet die OPP den Informationsaus- tausch zwischen dem Geldbörsenserver, dem Händlersystem und dem Bezah- lungsserver. Das IMPP verwaltet die Kommunikation zwischen diesen Komponen- ten und der OpCo-Domäne. Das OPP legt zusätzliche Meldungen zum Informati- onsaustausch über IMPP fest und das OPP verwaltet den Informationsaustausch über die OpCo-Domäne, welcher von dem speziellen Einkauf und einem Bezah- lungskanal oder einer Kombination von beiden abhängt. Das OPP hängt teilweise von dem unterstützten Bezahlungs-und Einkaufsszenario ab. Das OPP legt den Informationsaustausch zwischen den einbezogenen Komponenten über die OpCo- Domäne durch Verwenden des IMPP fest. Das OPP verwaltet nicht die Kommuni- kation innerhalb der Herausgeber-und der Akquisiteurdomäne. Der OPP-Mel- dungsfluss ist in der"Bezahlungseinleitungs (Payment initiation) "-Phase und der "Nachbezahlungs (Post-Payment) "-Phase des 3D-Modells beschrieben.

Die"Bezahlungseinleitungs"-Phase des Modells beschreibt das Auffinden des Geldbörsenservers und die Weckrufmeldung. Die"Nachbezahlungs"-Phase be- schreibt den Benachrichtigungs-und Lieferungsprozess. Das OPP verwaltet nicht die Kommunikation zwischen dem Kunden und dem Händlersystem, da diese Kommunikation durch den Händler oder das Einkaufssystem festgelegt wird. Das OPP verbirgt die Bezahlung, das Einkaufen und Szenario spezifische Daten, so dass das zugrunde liegende IMPP keine Rücksicht auf diese Daten nehmen muss.

Das OPP benutzt das zugrunde liegende Protokoll, um die Meldungen zwischen dem Geldbörsenserver und dem Bezahlungsserver auszutauschen. Das bedeutet, dass der Geldbörsenserver und der Bezahlungsserver keine direkte Netzwerk- kommunikation unterstützen. Alle Kommunikation zwischen dem Geldbörsenser- ver und dem Bezahlungsserver werden von dem gleichen IMPP verwaltet, welches die gesamte Kommunikation zwischen den drei Komponenten Geldbörsenserver, Prozessplattform und Bezahlungsserver verwaltet. Deshalb müssen Meldungspaa- re von dem OPP in zusätzlichen Meldungen gekapselt werden, um diese über das

zugrundeliegende Unterprotokoll zu übertragen. Für den Geldbörsenserver (WS Übertragung (WSTransfer)) und den Bezahlungsserver (PS Übertragung (PSTrans- fer)) eingeleiteten Austausch sind zwei neue Meldungspaare notwendig. Die Mel- dungspaare sind weiter unten beschrieben.

Weckrufanfrage und Antwortmeldung : Die Weckrufanfrage wird durch das Händ- lersystem abgegeben, um eine Geldbörsenserversuche in bestimmten Bezah- lungsszenarien einzuleiten. Diese Anfrage wird an die Prozessorplattform gesen- det, welche die Bezahlung durch den entsprechenden Heimgeldbörsenserver (Home Wallet Server) des Kunden einzuleiten. Der Weckrufprozess hängt von der Kombination aus Einkaufs-und Bezahlungskanal ab.

Lieferanfrage und Antwortmeldung : Die Lieferanfrage wird durch den Geldbör- senserver abgegeben, um das Händlersystem über eine abgeschlossene Bezah- lungstransaktion zu informieren. Das Händlersystem kann diese Benachrichtigung nutzen, um den Lieferprozess einzuleiten. Der Lieferprozess hängt von dem Be- zahlungs-und Einkaufsszenario ab.

Wiederaufnahme Anfrage und Antwort Meldung : Die Wiederaufnahme Anfrage wird durch den Geldbörsenserver abgegeben, um eine unterbrochene Lieferung von Onlineinhalten abzuschließen.

Das IMPP verwaltet die bezahlungsspezifische Kommunikation zwischen dem Geldbörsenserver, dem Händlersystem der Prozessorplattform und dem Bezah- lungsserver. Das OPP verwaltet den Informationsaustausch über die OpCo-Do- mäne, welche von einem speziellen Einkaufs-und Bezahlungskanal oder einer Kombination von beiden abhängt. Das IMPP ist unabhängig von dem unterstütz- ten Bezahlungs-und Einkaufsszenario.

Das IMPP führt die folgenden Funktionen durch : Es stellt eine Markenübertragung zwischen Kunde und Händler, Betragsneuberechnung durch das Händlersystem zur Verfügung ; es stellt Auftragsinformationsaustausch zur Verfügung ; es stellt Altersprüfungsfähigkeiten zur Verfügung ; es stellt Adressaustausch mit und ohne Bezahlung zur Verfügung ; es stellt einen Erweiterungsmechanismus zum Austau- schen zusätzlicher Informationen in dem festgelegten Meldungsfluss zur Verfü-

gung ; es stellt Bezahlungsberechtigungen einschließlich"Soforterfassung (capture now) "-Einrichtungen für Makro-und Mikrobezahlungen zur Verfügung ; es stellt eine OfferID-Verwaltung zur Verfügung ; und es stellt einen Erweiterungsmecha- nismus für den Austausch von zusätzlichen Meldungen über die CPP zur Verfü- gung. Die Integration und Kommunikation zwischen einem Kunden und dem Geldbörsenserver und zwischen einem Händler und dem Bezahlungsserver ist un- abhängig von dem IMPP. Das IMPP nimmt keine Rücksicht auf die Kombination von verschiedenen Einkaufs-und Bezahlungskanälen. Aus der Kombination von verschiedenen Einkaufs-und Bezahlungskanälen resultierende Probleme werden durch den OPP-Teil des Protokollstapels (stacks) verwaltet. Das IMPP stellt eine Protokollschicht (protocol layer) zur Verfügung, um die globale Kommunikation zwischen Geldbörsenservern und Bezahlungsservern über eine einzelne Prozes- sorplattform zu verwalten.

Das OPP und IMPP berücksichtigen Bezahlung, Einkauf, Kunde, Händler oder Tel- co-spezifische Erfordernisse. Das IMPP hält einen Mechanismus zum Übertragen von Meldungen aus höheren Protokollschichten über die CPP zur Verfügung. Ver- schiedene Geldbörsenserver oder Bezahlungsserveranbieter sind in der Lage, die Funktion in eine höhere Protokollschicht ohne direkte Kommunikation zwischen Geldbörsenserver und Bezahlungsserver außerhalb des IMPP auszudehnen. Anbie- ter von Geldbörsenservern oder Bezahlungsservern implementieren das IMPP für die Kommunikation über die CPP.

Das IMPP bearbeitet Nachrichten zwischen allen einbezogenen Komponenten über die OpCo-Domäne. Es deckt dabei nicht die Kommunikation innerhalb der Her- ausgeber oder der Akquisiteurdomäne ab. Das IMPP verarbeitet die in der"Auf- tragsaustausch (order exchange)"-Phase und"Bezahlungs"-Phasen eines 3D-Be- zahlungsphasenmodells beschriebenen Meldungsflüsse.

IMPP-Meldungen sind gemäß verschiedenartiger Bereiche klassifiziert. Insbeson- dere werden alle Meldungspaare in einem Bezahlungsbereich als OpCo interpre- tiert. Normalerweise werden diese Meldungen von dem Geldbörsenserver abge- geben, um eine Bezahlungstransaktion auszuführen. Die OpCo empfängt die Mel- dung und interpretiert ihren Inhalt zum Transaktionsprotokollieren oder zur Ge- bührenverwaltung. Normalerweise werden die Meldungen an den Bezahlungsser-

ver zur speziellen Verarbeitung weitergeleitet. Die entsprechende Meldungsant- wort wird über die CPP an den Geldbörsenserver gesendet. In manchen speziellen Szenarien nimmt die CPP die eintreffende Anfrage auf und sendet eine Antwort zurück an den Geldbörsenserver. Die CPP interpretiert alle Meldungen innerhalb dieses Bereiches. Andere Bereiche umfassen einen Erweiterungsbereich, einen Benachrichtigungsbereich und einen Angebotsbereich.

Figur 5 stellt IMPP-Meldungen dar und jeder Meldungstyp würde darunter erklärt.

Insbesondere wird die PayPurchase-Anfrage durch den Geldbörsenserver abgege- ben, um einen Einkauf über IMPP einzuleiten. Diese Anfrage wird über die CPP an den Bezahlungsserver gesendet. Die CPP wirkt als Proxy für dieses Meldungspaar.

Die PayInquire-Anfrage wird durch den Geldbörsenserver gegeben, um eine An- frage über IMPP einzuleiten. Diese Anfrage wird über die CPP an den Bezahlungs- server gesendet. Die CPP wirkt als Proxy für dieses Meldungspaar.

Die PayStateUpdate-Anfrage wird durch den Bezahlungsserver abgegeben, um den Transaktionsstatus auf dem Geldbörsenserver zu aktualisieren. Diese Anfrage wird über die CPP an den Geldbörsenserver gesendet.

Die WSTransfer-Anfrage wird durch den Geldbörsenserver abgegeben, um eine Übertragung von zusätzlichen Informationen über IMPP einzuleiten. Diese Anfra- ge wird über die CPP an den Bezahlungsserver gesendet. Die CPP wirkt als ein Proxy für dieses Meldungspaar. Das WSTransfer-Meldungspaar kann zum Über- tragen von Meldungen aus einer höheren Protokollschicht über IMPP genutzt werden. Der Inhalt dieses Meldungspaars wird als anonymes Datum durch die CPP verarbeitet.

Die PSTransfer-Anfrage wird durch den Geldbörsenserver abgegeben, um eine Übertragung von zusätzlichen Informationen über IMPP einzuleiten. Diese Anfra- ge wird über die CPP an den Bezahlungsserver gesendet. Die CPP wirkt als ein Proxy für dieses Meldungspaar. Dieses PSTransfer-Meldungspaar kann zum Über- tragen von Meldungen aus einer höheren Protokollschicht über IMPP genutzt werden. Der Inhalt dieses Meldungspaars wird als anonymes Datum durch die CPP verarbeitet.

Die WSNotify-Anfrage wird durch den Geldbörsenserver abgegeben, um die CPP über zusätzliche Informationen zu benachrichtigen. Die CPP verarbeitet die An- frage und erwidert mit einer entsprechenden Antwort. Zum Beispiel wird diese Anfrage genutzt, um die CPP über die Unterbrechung des Meldungsflusses durch den Kunden zu informieren. Auf diese Art und Weise ist die CPP in der Lage, die Situation innerhalb der CPP, z. B. das Löschen der dynamischen OfferID in dem Kontext-Repositorium abzuwickeln.

Die PSNotify-Anfrage wird von dem Bezahlungsserver abgegeben, um die CPP über zusätzliche Informationen zu benachrichtigen. Die CPP verarbeitet die An- frage und erwidert mit einer entsprechenden Antwort. Zum Beispiel wird diese Anfrage genutzt, um die CPP über eine Unterbrechung des Meldungsflusses zu in- formieren.

Die OfferCreateContext-Anfrage wird von dem Bezahlungsserver abgegeben, um eine neue OfferID in dem Kontext-Repositorium zu erzeugen. Nach Verarbeitung der Anfrage in dem entsprechenden OfferID-Server, wird eine Antwortmeldung an den Bezahlungsserver zurückgesendet. Dieses Meldungspaar ist für den Geldbör- senserver nicht sichtbar.

Die OfferDestroyContext-Anfrage wird von dem Bezahlungsserver abgegeben, um einen OfferID-Eintrag in dem Kontext-Repositorium zu löschen. Nach Verarbei- tung der Anfrage in dem entsprechenden OfferID-Server, wird eine Antwortmel- dung an den Bezahlungsserver zurückgesendet. Dieses Meldungspaar ist für den Geldbörsenserver nicht sichtbar.

Die OfferModifyContext-Anfrage wird von dem Bezahlungsserver gegeben, um ei- nen OfferID-Eintrag in dem Kontext-Repositorium zu ändern. Nach Verarbeitung der Anfrage in dem entsprechenden OfferID-Server, wird eine Antwortmeldung an den Bezahlungsserver zurückgesendet. Dieses Meldungspaar ist für den Geldbör- senserver nicht sichtbar.

Figur 6 stellt eine gültige Meldungsfolge für das Protokoll dar. Figur 7 stellt eine OfferID-Meldungsfolge dar. Die Währungsumrechnung wird auf der Seite des

Geldbörsenservers durchgeführt. Figur 8 stellt eine WAP-WAP-Mikrobezahlungs- folge dar. In Figur 8 liegen zwei Umleitungen vor, insbesondere eine Umleitung an die CPP, welche durch den Händler eingeleitet wurde, und eine an den Heim- geldbörsen-Server (home wallet server), welche durch die CPP eingeleitet wurde.

Figur 9 stellt eine WAP-WAP-Adressenübertragung ohne Bezahlungsfolge und Fi- gur 10 eine Verkaufsautomaten-Makrobezahlungsfolge dar. Figur 11 stellt eine statische OfferID-Erzeugungsfolge dar.

Die OfferID weist die folgenden Stati auf.

Startstatus (SS (Start state)) : Registrierter Status (RS (Registered state)) : Erzeugter statischer Status (CSS (Created Static state)) : Erzeugter dynamischer Status (CDS (Created Dynamic state)) : Gesperrter Status (DS (Disabled state)) : SS RS CSS CDS DS SS R CS CD RS UR M CS CSS M DA CDS D DS EA Die folgenden Aktionen können zum Ändern des OfferID-Status vorgenommen werden.

Registrieren (R (Register)) : Nicht Registrieren (UR (Unregister)) : Statisches Erzeugen (CS (Create static)) : Dynamisches Erzeugen (CD (Create dynamic)) : Ändern (M (Modify)) : Löschen (D (Destroy)) : Aktivieren (EA (Enable)) : Deaktivieren (DA (Disable)) :

Die dynamischen Transaktionsmodelle für Makrobezahlung haben gemeinsam, dass der Eigentümer des Transaktionsstatus der Bezahlungsserver ist. In dem in Figur 12 dargestellten Statusmodell werden die Transaktionsstati und Übergänge für eine umgehende Makrobezahlung benutzt, oft als"Verkaufs (Sales)"-Trans- aktionen bezeichnet. Kein gesonderter Schritt zum finanzieren der Bezahlung wird auf Seiten des Händlers/Akquisiteurs durchgeführt. Status WS OpCo PS Bezahlung erzeugt Init : Init : PayPurchaseReq () PayPurchaseReq () Set : Notify : Notify : PayPurchase- PayPurchaseRes() PayPurchaseRes() Req() Ackn. : Ackn. : PayAuthorizeReq () PayAuthorizeReq () Bezahlung durchgeführt Notify : Notify : Set : PayAuhtorizeRes() PayAuthorizeRes() PayAuthorize- Req () Sync. : InquiryRes () Sync. : InquiryRes () Bezahlung fehige- schlagen Notify : Notify : Set : PayAuthorizeRes () PayAuthorizeRes () PayAuthorize- Req () Sync. : InquiryRes () Sync. : InquiryRes () Bezahlung aufge- hoben Notify : WSNotifyReq () Notify : PSNotifyReq () Set : internal (durch PS) Ackn. : WSNotifyRes () Ackn. : PSNotifyRes () triggered or or or ("Automatische Init : WSNotifyReq () Init : PSNotifyReq () Set : Aufhebung Notify : WSNotifyRes () Notify : PSNotifyRes () PSNotifyReq () (Autoreversal)"Sync. : InquiryRes () Sync. : InquiryRes () durch WS)

Das in Figur 13 dargestellte Statusmodell beschreibt die Transaktionsstati und Übergänge, welche für eine Makrobezahlungsgutschrift benutzt werden. Es wird von Händlern verwendet, um eine Gutschrift auf ein Makrobezahlungsmittel aus- zugeben. Dies wird durch Händler getätigt, um eine Bezahlung zurückzuerstatten, nachdem die eigentliche Transaktion schon abgerechnet wurde. Status WS OpCo PS Gutschrift erzeugt Notify : WSNotifyReq () Notify : PSNotifyReq () Set : internal Ackn. : WSNotifyRes () Ackn. : PSNotifyRes () triggered Gutschrift Notify : WSNotifyReq () Notify : PSNotifyReq () Set : internal ausgeführt Ackn. : WSNotifyRes () Ackn. : PSNotifyRes () triggered Gutschrift fehlge-Notify : WSNotifyReq () Notify : PSNotifyReq () Set : internal schlagen Ackn. : WSNotifyRes () Ackn. : PSNotifyRes () triggered

Das in Figur 14 darstellte Statusmodell beschreibt die Transaktionsstati und Übergänge, welche bei verzögerter Makrobezahlung benutzt werden. Dies wird verwendet, wenn der Händler eine berechtigte Bezahlung mit einiger Verzöge- rung, z. B. wenn die Waren versandt werden, erfasst. Wenn nur teilweise Versen- dung möglich ist, kann die teilweise Erfassung einmalig oder fortlaufend ange- wendet werden. Der Kunde kann den detaillierten Bezahlungsstatus in seiner Geldbörse verfolgen. Eine Statusmaschine wird für die Lebensdauer der anfängli- chen Transaktion zur Verfügung gestellt und einer andere Statusmaschine wird für die Lebensdauer von teilweisen Transaktionen zur Verfügung gestellt. Status WS OpCo PS Bezahlung erzeugt Init : Init : PayPurchaseReq () PayPurchaseReq () Set : Notify : Notify : PayPurchase- PayPurchaseRes() PayPurchaseRes() Req() Ackn. : Ackn. : PayAuthorizeReq () PayAuthorizeReq () Bezahlung durchgeführt Notify : Notify : PayAuthorizeRes () PayAuthorizeRes () Set : PayAuthorize- Sync. : InquiryRes () Sync. : InquiryRes () Req () Bezahlung fehige- schlagen Notify : Notify : Set : PayAuthorizeRes () PayAuthorizeRes () PayAuthorize- Req() Sync. : InquiryRes () Sync. : InquiryRes () or or or Notify : WSNotifyReq() |Notify : WSNotifyReq() Set : internal Ackn. : WSNotifyRes () Ackn. : WSNotifyReq() triggered Bezahlung aufge- hoben Notify : WSNotifyReq () Notify : PSNotifyReq () Set : internal (durch PS) Ackn. : WSNotifyRes () Ackn. : PSNotifyRes() triggered or or or ("Automatische Init : WSNotifyReq() Init : PSNotifyReq() Set : Aufhebung Notify : WSNotifyReq() Notify : PSNotifyReq() |PSNotifyReq() (Autoreversal)"Sync. : InquiryRes () Sync. : InquiryRes () durch WS) Bezahlung erfasst Notify : WSNotifyReq() |Notify : PSNotifyReq() Set : internal triggered Ackn. : WSNotifyRes () Ackn. : PSNotifyRes () Bezahlung geteilt Notify : WSNotifyReq () Notify : PSNotifyReq () Set : internal triggered Ackn. : WSNotifyRes () Ackn. : PSNotifyRes () Bezahlung abge- schlossen Notify : WSNotifyReq () Notify : PSNotifyReq () Set : internal triggered Ackn. : WSNotifyRes () Ackn. : PSNotifyRes ()

Figur 15 stellt ein Statusmodell für teilweise Makrobezahlung dar. Eine teilweise Makrobezahlungstransaktion hat ihre eigene Lebensdauer und die Geldbörse des Käufers wird über alle Teilbezahlungsrelevanten Ereignisse benachrichtigt. Status WS OpCo PS Teilbezahlung er- zeugt Notify : WSNotifyReq () Notify : PSNotifyReq() Set : internal triggered Ackn. : WSNotifyRes () Ackn. : PSNotifyRes () Teilbezahlung er- fasst Notify : WSNotifyReq() Notify : PSNotifyReq() Set : internal triggered Ackn. : WSNotifyRes () Ackn. : PSNotifyRes () Teilbezahlung fehl- geschlagen Notify : WSNotifyReq() Notify : PSNotifyReq() Set : internal triggered Ackn. : WSNotifyRes () Ackn. : PSNotifyReq() Teilbezahlung aufgehoben Notify : WSNotifyReq () Notify : PSNotifyReq () Set : internal triggered Ackn. : WSNotifyRes () Ackn. : PSNotifyRes ()

Die dynamischen Transaktionsmodelle für Mikrobezahlung haben gemeinsam, dass der Eigentümer des Transaktionsstatus der Geldbörsenserver ist, aufgrund der Tatsache, dass das kundenseitige Abrechnungssystem die Bezahlung bis zur Abrechnung aufrecht erhält.

Figur 16 stellt das Statusmodell für die Transaktionsstati und Übergänge dar, welche für eine umgehende Mikrobezahlung, z. B. eine Niedrigwerttransaktion be- nutzt werden, welche an einem Verkaufsautomaten eingeleitet wurde. Status WS OpCo PS Bezahlung Setzen : intern Benachrichtigen : Benachrichtigen : erzeugt ausgelöst PayPurchaseReq () PayPurchaseReq () Bestätigen : Bestätigen : PayPurchaseRes () PayPurchaseRes () Bezahlung Setzen : intern Benachrichtigen : Benachrichtigen : durchgeführt ausgelöst PayAuthorizeReq () PayAuthorizeReq () Bestätigen : Bestätigen : PayAuthorizeRes () PayAuthorizeRes () Bezahlung Setzen : intern Benachrichtigen : Benachrichtigen : PSNo- fehlgeschlagen ausgelöst WSNotifyReq () tifyReq () PayAuthorize- Res () Bestätigen : WSNotify-Bestätigen : PSNoti- Res () fyRes () Bezahlung Setzen : intern Benachrichtigen : Benachrichtigen : PSNo- aufgehoben ausgelöst WSNotifyReq () tifyReq () Bestätigen : WSNotify-Bestätigen : PSNotify- Res () Res ()

Figur 17 stellt ein Statusmodell für die Transaktionsstati und Übergänge dar, welche bei verzögerten Mikrobezahlungen benutzt werden. Dies wird benutzt, wenn der Händler eine berechtigte schemakonforme Mikrobezahlung nur teilweise oder mehrere Male mit sehr geringen Erfassungsbeträgen ("Sofort (Instant)"-Be- zahlung, z. B. "Bezahlen nach Zeit (pay per time) "oder"Bezahlen nach Umfang (pay per volume)"Geschäfte) erfasst. Status WS OpCo PS Bezahlung Setzen : intern Benachrichtigen : Benachrichtigen : erzeugt ausgelöst PayPurchaseReq () PayPurchaseReq () Bestätigen : Bestätigen : PayPurchaseRes () PayPurchaseRes () Bezahlung Setzen : intern Benachrichtigen : Benachrichtigen : berechtigt ausgelöst PayAuthorizeReq () PayAuthorizeReq () Bestätigen : Bestätigen : PayAuthorizeRes () PayAuthorizeRes () Bezahlung Setzen : WSNo-Einleiten : PSNoti-Einleiten : PSNotifyReq () erfasst tify fyReq () Benachrichtigen : Req () Benachrichtigen : PSNotifyRes () WSNotifyRes () Synchronisieren : Inqui- Synchronisieren : In-ryReq () quiryReq () Bezahlung fehl-Setzen : intern Benachrichtigen : Benachrichtigen : PSNo- geschlagen ausgelöst, WSNotifyReq () tifyReq () Bestätigen : WSNotify-Bestätigen : PSNoti- oder Res () fyRes () Setzen : oder oder PayAuthorize- Res () Benachrichtigen : Benachrichtigen : PayAuthorizeRes () PayAuthorizeRes () Synchronisieren : In-Synchronisieren : In- quiryReq () quiryReq () Bezahlung Setzen : intern Benachrichtigen : Benachrichtigen : PSNo- aufgehoben ausgelöst WSNotifyReq () tifyReq () Bestätigen : WSNotify-Bestätigen : PSNotify- Res () Res () oder oder oder Setzen : PayAuthorize-Benachrichtigen : Benachrichtigen : Res () PayAuthorizeRes () PayAuthorizeRes () Synchronisieren : In-Synchronisieren : In- quiryReq () quiryReq ()

Figur 18 stellt ein Statusmodell für Transaktionsstati und Übergänge dar, welches zum Ausführen einer Mikrobezahlungsgutschrift benutzt wird. Dies wird durch Händler genutzt, um eine Gutschrift auf ein Kundenmikrobezahlungsmittel zu übertragen. Die Händler brauchen dies, um eine Bezahlung zurückzuerstatten, nachdem die eigentliche Transaktion schon abgerechnet wurde. Status WS OpCo PS Gutschrift Setzen : WSNotify-Einleiten : PSNotify-Einleiten : PSNotify- erzeugt Req () Req () Req () Benachrichtigen : Benachrichtigen : WSNotifyRes () PSNotifyRes () Synchronisieren : In-Synchronisieren : In- quiryReq () quiryReq () Gutschrift Setzen : WSNotify-Einleiten : PSNotify-Einleiten : PSNotify- durchgeführt Req () Req () Req () Benachrichtigen : Benachrichtigen : WSNotifyRes () PSNotifyRes () Synchronisieren : In-Synchronisieren : In- quiryReq () quiryReq () Gutschrift Setzen : WSNotify-Einleiten : PSNotify-Einleiten : PSNotify- aufgehoben Req () Req () Req () Benachrichtigen : Benachrichtigen : WSNotifyRes () PSNotifyRes () Synchronisieren : In-Synchronisieren : In- quiryReq () quiryReq () Gutschrift fehl-Setzen : WSNotify-Einleiten : PSNotify-Einleiten : Notify- geschlagen Req () Req () Req () Benachrichtigen : Benachrichtigen : WSNotifyRes () PSNotifyRes () Synchronisieren : In-Synchronisieren : In- quiryReq () quiryReq ()

Die IMPP-Meldungsstruktur besteht aus einer Zweischichtstruktur, nämlich einem Meldungsumschlag (message wrapper) und (eine HTTP-Anfrage oder-Antwort) und einer Meldung (einer XML-Einheit (entity)). Eine IMPP-Meldung wird syn- chron verarbeitet und weist ein XML-Meldungselement (Anfrage/Antwort-Paar) auf, welches in der entsprechenden HTTP-Anfrage und Erwiderung enthalten (wrapped) ist. Dieses Anfrage/Antwort-Paar stellt eine vollständige Protokollum- wandlungseinheit (protocol conversation unit) dar. Wenn eine IMPP-Meldung ein- fach durch eine bestimmte technische Funktion an eine andere Einheit weiterge- leitet wird, wird nur der Meldungsumschlag durch die weiterleitende Einheit ver- arbeitet. Die Meldung selbst kann unverarbeitet bleiben, um zusätzliche Verarbei- tung oberhalb von XML-Syntax-Analyse (parsing) und Schreiben (writing) zu ver- meiden.

Der Meldungsumschlag ist von dem genutzten Protokoll abhängig, welches HTTP/1.0 ist. Folglich ist der Transportumschlag (transport wrapper) ein gültiger

HTTP/1. 0-Anfragekopf/Antwortkopf gemäß RFC822. Das genutzte HTTP-Anfrage- verfahren (verb) ist POST.

Anfrage Attribut M # Typ Format Bemerkung Anfrage-Leitung X 1 RFC1945 POST SP URI SP URI ist der Pfad einer der (Request-Line) HTTP/1.0 CRLF PayPurchaseURL, PayReqURL, InquiryURL, NotifyURL etc. Verbindung : X 1 RFC822 Keep-Alive CRLF Inhalts-Typ : X 1 RFC822 Application/xml ; SP charset="utf-8" CRLF Inhalts-Länge : X 1 RFC822 nn CRLF nn ist die Länge der Mel- dung nach diesem Anfra- gekopf (request header) in bytes Inhalts-X 1 RFC822 Binär CRLF Binär für XML über HTTP, Übertragungs-kann auch base64 für an- Codierung dere sein, eingeschränk- (Content-Transfer-ter Transport (restricted Encoding) : transport) Neue Leitung X 1 RFC822 CRLF Separator zwischen Kopf (New-Line) (header) und Rumpf (body) Rumpf (Body) X 1 RFC822 Antwort Attribut M # Typ Format Bemerkung Status-Leitung X 1 RFC1945 HTTP/1. 0 StatusCode Reason ist der (Status-Line) Statuskode SP http Statuskode und Ur- Grund CRLF sachenausdruck für die Meldung, entweder 200 OK oder 50x (im Falle ei- nes Transportfehlers) Verbindung : X 1 RFC822 Keep-Alive CRLF Inhalts-Typ : X 1 RFC822 Application/xml ; SP charset="utf-8" CRLF Inhalts-Länge : X 1 RFC822 nn CRLF nn ist die Länge der Mel- dung nach diesem Anfra- gekopf (request header) in bytes Inhalts-X 1 RFC822 Binär CRLF Binär für XML über HTTP, Übertragungs-kann auch base64 für an- Codierung dere sein, eingeschränk- (Content-Transfer-ter Transport (restricted Encoding) : transport) Neue Leitung X 1 RFC822 CRLF Separator zwischen Kopf (New-Line) (header) und Rumpf (body) Rumpf (Body) X 1 RFC822

Figur 19 stellt eine IMPP-Meldungsstruktur dar. Die Anfrage und die Antwort auf eine Meldung sind beide als eine serialisierte XML-Struktur dargestellt. Das XML- Basiselement (root element) <ImppMessage> enthält ein XML'element only'E- lement <Header> und genau eine Anfrage oder ein Antwort XML'element only' Element. Das <Header> Element enthält die Subelemente Id (für Meldung- Idempotenz) und Version.

Dokumenttypvereinbarung Elementdefinition < ! ELEMENT ImppMessage (Header, (...)) > Elementdefinition < ! ELEMENT Header (id, Version) > Eine generische Beispiel-Meldung ist die folgende :

<ImppMessage> <Header> </Header> <PayPurchaseRequest> i __...--><BR> </PayPurchaseRequest><BR> </ImppMessage>.

Infolge der Meldungsstruktur kann eine hergestellte Verbindung nach Austausch einer vollständigen Protokollumwandlungseinheit (protocol conversation unit) wiederverwendet werden, um einen TCP connect/accept/close overhead auszu- schließen und die Effizienz zu steigern. Das HTTP-keep-alive-Protokoll wird be- nutzt, um eine Abstimmung zwischen den einbezogenen technischen Funktionen auf Anwendungsebene zu erreichen. Eine schon hergestellte Verbindung kann in derselben Richtung wiederverwendet werden, d. h. innerhalb derselben Client/Server-Rollenzuweisung (role allocation).

Die Anwendungen des Geldbörsenservers und Bezahlungsservers verarbeiten An- erkennung (non-repudiation). Es können entweder entsprechende Attribute in den Protokollelementen oder erweiterte Elemente/Attribute genutzt werden. Das VPN verarbeitet die Verschlüsselung (encryption) jeder Kommunikation zwischen Geldbörsenservern und OpCo wie auch zwischen Bezahlungsservern und OpCo.

Das VPN stellt nur Verbindungen zwischen zwei Parteien her, welche eine erfolg- reiche gegenseitige Berechtigung durchgeführt haben. Die Versendung von An- wendungsdaten erfordert die Beendigung des Berechtigungsprozesses.

Das Protokoll legt auch einen Mechanismus zur Versionsabsprache (version nego- tiation) zwischen den technischen Funktionen fest, ist aber unabhängig von den angewendeten konkreten Versionskompatibilitätsregeln. Das Protokoll umfasst das Senden der benutzten Protokollversion in dem Meldungskopf.

Innerhalb einer Protokollmeldungsfolge wird nur eine Version benutzt. Der Versionsabsprachefluß ist symmetrisch und es kommt nicht darauf an, ob der Geldbörsenserver, der Bezahlungsserver oder das OpCo selbst eine Folge einlei-

tet. Darüber hinaus wird ein entsprechender Fehlercode festgelegt, um eine Ver- sionsunverträglichkeit anzuzeigen. Wenn das OpCo in Folge einer Versionsunstim- migkeit eine Meldung nicht an den Empfänger weiterleiten kann, wird dies als technischer Fehler behandelt.

Der Versionsabspracheprozess ist in Figur 20 dargestellt und weiter unten be- schrieben.

Schritt 1. Eine Bezahlungskomponente sendet eine IMPP-Anfrage an das OpCo unter Verwenden der höchsten IMPP-Version, welche durch den Ab- sender unterstützt wird.

Schritt 2. Das OpCo prüft die Version und verarbeitet das Ergebnis.

Schritt 3. a) Prüfung OK : Die Anfrage wird an den Empfänger weitergeleitet. b) Prüfung nicht OK : Das OpCo sendet eine Fehlermeldung zurück, welche die durch das OpCo unterstützten IMPP-Versionen ent- hält. c) Nochmaliges Senden : Die Bezahlungskomponente sende die IMPP-Anfrage nochmals unter Verwenden der höchsten gemein- samen Version oder stoppt mit einem Fehler.

Schritt 4. Die Bezahlungskomponente prüft die Version und bearbeitet das Er- gebnis.

Schritt 5. a) Prüfung OK : Die Antwort wird an das OpCo zurückgesendet. b) Prüfung nicht OK : Eine Fehlermeldung wird an das OpCo zurück gesendet, welche die durch den Empfänger unterstützten IMPP- Versionen enthält.

Schritt 6. a) Das OpCo erzeugt einen Mittelwert zwischen eigenen und durch

den Empfänger unterstützten Versionen und sendet ! 7-, 2 Fehler- meldung an den Absender zurück, welche diese Information ent- hält. b) Das OpCo sendet die normale Antwort an den Absender zurück. c) Nochmaliges Senden : Die Bezahlungskomponente sendet die IMPP-Anfrage nochmals unter Verwenden der höchsten gemein- samen Version oder stoppt mit einem Fehler.

Aus der Perspektive eines IMPP-Teilnehmers treten IMPP-Flüsse in Paaren auf.

Jede von einem anfragenden Teilnehmer übermittelte Meldung wird von einem antwortendem Teilnehmer erwidert. Der Fehlerfluss (im Unterschied zu anderen Flüssen) wird hinsichtlich des Anfragenden und Antwortenden festgelegt, da die- ser genutzt wird, wenn der Antwortende die eingehende Meldung nicht verläss- lich identifizieren kann. Eine Fehler zeigt an, dass eine Antwortender eine Mel- dung abweist, weil ein Formatfehler vorliegt oder Inhaltsprüfungstests fehige- schlagen sind. Der Antwortende sendet einen Fehler (eher einen negativen Ant- wortcode), wenn der Antwortende irgendeinem der Felder der eingehenden Mel- dung nicht trauen kann. Üblicherweise wird ein Fehler genutzt, um dem Absender einer Meldung direkt zu antworten, wenn es nicht möglich ist, den Fehler eindeu- tig auf einen fehlerhaften Wert eines Feldes einzugrenzen. Die Fehlermeldung wird nicht benutzt, um normale Geschäftsergebnisse wie eine abgelehnte Berech- tigung anzuzeigen. Geschäftsergebnisse werden durch explizite Codes in standar- disierten Antwortmeldungen angezeigt.

Fehler in dem IMPP-System können aus einer Anzahl von verschiedenen Quellen resultieren. Zum Beispiel können IMPP-Meldungen grammatikalisch bestimmbar (parseable), aber durch nicht befolge der Anforderungen des Protokolls fehige- bildet (malformed) sein, Werte können falsch oder Meldungen können beschädigt sein, üblicherweise als Ergebnis von Übertragungsfehlern.

Hinsichtlich doppelter Meldungen erscheint genug Information im Klartext des Meldungsumschlags, so dass herausgefunden werden kann, ob eine Meldung eine Neuübertragung ist oder nicht. Die Reaktion des Empfängers auf eine doppelte

Meldung hängt von der Indempotenz-Eigenschaft (im Detail weiter unten be- schrieben) des Meldungstyps, der Anzahl von verdoppelten Meldungen, der Quel- le der doppelten Meldungen und von der beobachteten Frequenz zwischen nach- folgenden doppelten Meldungen ab. Wenn ein System Verdacht schöpft, dass es Überschwemmungs-oder Werbebemüllungsangriffen ausgesetzt ist, können dop- pelte Meldungen ignoriert werden.

Eine beschädigte Meldung ist eine Meldung, welche nicht grammatikalisch be- stimmbar (cannot be parsed) ist. Üblicherweise sollte eine möglicherweise be- schädigte Meldung nicht empfangen werden, weil die Nachrichtentransportme- chanismen veranlassen werden, dass beschädigte Daten zurückgesendet werden.

Wird eine beschädigte Meldung jedoch empfangen, wird eine entsprechende Feh- lermeldung zurückgegeben, welche anzeigt, dass eine beschädigte Meldung emp- fangen wurde und eine Anfrage/Antwortpaarkennung der Meldung zur Verfügung stellt, wenn diese verfügbar ist. Es wird akzeptiert, die Meldung völlig zu ignorie- ren, wenn nicht genügend Daten entnommen wurden, um in der Lage zu sein darauf zu antworten. Hinsichtlich fehigebildeter Meldungen wird eine entspre- chende Fehlermeldung von dem AbAbsender zurückgegeben, wenn eine Meldung grammatikalisch bestimmbar ist, aber ansonsten aufgrund von außerhalb eines Bereichs liegenden Werten oder inkonsistenten Optionen falsch ist.

Eine Anwendung erzeugt keine Fehlermeldung als Antwort auf eine andere Feh- lermeldung. Alle IMPP-Komponenten senden eine Fehlermeldung, wenn ein auf niedriger Ebene (low-level) liegender Verarbeitungsfehler auf eine IMPP-Antwort- meldung auftritt. Jede Meldung, welche nicht als IMPP-Meldung erkannt wird, wird ignoriert. Die IMPP-Komponenten vermeiden üblicherweise das Senden von Fehlermeldungen auf demselben Kanal wie Anfragemeldungen.

Die folgenden Felder sind für Fehler (error) festgelegt.

ErrorCode : Nummerierter Code, welcher die Fehlerbedingung definiert.

ErrorDescription : Eine freie Beschreibung der Fehlerursache.

ErrorObjectID : Die Objektkennung einer nicht-unterstützten kritischen Erweite- rung, welche den Fehler auslöste.

ErrorMessage : Die Meldung, welche den Fehler erzeugte. Error code Beschreibung BadMessageHeader Der Meldungskopf kann nicht verarbei- tet werden. MessageNotSupported Dieser gültige Meldungstyp wird durch den Empfänger nicht unterstützt. MessageTooBig Die Meldung ist zum Verarbeiten beim Empfänger zu groß. MessageTooNew Das Datum der Meldung ist zum Verar- beiten beim Empfänger zu neu. MessageTooOld Das Datum der Meldung ist zum Verar- beiten beim Empfänger zu neu. ParsingXMLFailure Ein Fehler trat während der grammati- kalischen Bestimmung der XML-Struktur der Meldung auf. UnknownETxID Eine unbekannte EtxID wurde empfan- gen. UnknownMSG Eine unbekannte Meldung wurde emp- fangen. UnknownMSID Eine unbekannte BezahlungsserverID wurde empfangen. UnknownOID Eine unbekannte Angebotskennung wurde empfangen. UnknownWSID Eine unbekannte GeldbörsenserverID wurde empfangen. UnrecognizedExtension Die Meldung enthält eine kritische Er- weiterung, welche beim Empfänger nicht verarbeitet werden kann. Das Er- rorObjectID-Feld erkennt die Erweite- rung. UnspecifiedFailure Die Ursache für den Fehler erscheint nirgends in dieser Liste. VersionTooNew Die Versionsnummer der Meldung ist zum Verarbeiten beim Empfänger zu neu. VersionTooOld Die Versionsnummer der Meldung ist zum Verarbeiten beim Empfänger zu alt. WrapperMsgMismatch Die Inhalte des Meldungsumschlags sind zum inneren Inhalt der Meldung inkonsistent.

Das IMPP-Protokoll basiert auf Anfrage/Antwortpaaren durch das gesamte Proto- koll hindurch. Die Fehlermeldung geht nicht konform mit diesem Paradigma, weil diese eine Antwort auf entweder eine Anfrage oder eine Antwort sein kann. Der frühere Fall stellt keine Schwierigkeit dar. In dem späteren Fall jedoch können Schwierigkeiten auftreten, wenn der zugrunde liegende Transport auf einem An- frage/Antwortparadigma basiert, wie in einem World Wide Web-Browser. In die- sem Fall kann die Fehlermeldung als eine Anfragemeldung gesendet werden und das Protokoll wird keine Antwortmeldung (das zugrunde liegende Protokoll kann zeitabgeschaltet (time out) sein) fordert. Für eine als Ergebnis der operativen Beschränkungen eines World Wide Web-Browsers gesendeten Fehlermeldung kann eine Benutzererlaubnis erforderlich sein.

Der HTTP-Meldungskopf enthält einen Statuscode, welcher den Verarbeitungssta- tus der entsprechenden Meldungseinheit als Ganzes angibt. Jeder Geschäftsfehler wird unabhängig von dem Meldungsstatus durch die Bestandteile angezeigt. Die folgenden Statuscode sind als eine bestimmte Meldung definiert, welche die 5xx Statuscodebereiche des HTTP-Standards zum Anzeigen von anwendungsspezifi- schen Fehlern nutzen. Errorcode Beschreibung 200 OK Wird im Fall einer erfolgreichen Verar- beitung einer Meldung als Ganzes ge- setzt, unabhängig davon, ob ein Ge- schäftsfehler aufgetreten ist (d. h."Cre- dit Card expired"). 501 Weiterleitungsfehler Wird im Fall einer unbekannten Zielad- resse in der Anfrage zurückgegeben. 502 Version nicht unterstützt Wird im Fall einer nicht unterstützten Protokollversion in der Anfrage zurück- gegeben. Wenn OpCo dies von dem letztendlichen Empfänger der Meldung empfängt, wird dies auch an den AbAb- sender zurückberichtet. 503 Inhaltstyp nicht unterstützt Wird im Fall eines nicht unterstützten Inhaltstyps in der HTTP-Anfrage zu- rückgegeben. 504 Inhaltscodierung nicht unterstützt. Wird im Fall einer nicht unterstützten Inhaltskodierung in der HTTP-Anfrage zurückgegeben. 505 Übertragungsfehler, später noch Zum nochmaligen Senden im Fall eines einmal versuchen übertragungstechnischen Problems. 506 Meldungsidempotenzverletzung Wird gesetzt, wenn die Idempotenzprü- fung einer bestimmten Meldung auf- grund eines geänderten Anfrageinhalts im Fall einer Anfrage fehlschlägt, wel- che schon in der Idempotenzdatenbasis gespeichert ist. 507 ungültige Meldung Wird gesetzt, wenn der Meldungsrumpf nicht grammatikalisch bestimmt werden konnte, die Idempotenz geprüft und an das Verarbeitungssystem aufgrund ei- nes fehlerhaften Formats des Rumpfes (z. B. XML parse error) übergeben wur- de. 508 nicht spezifizierter Verarbeitungs-Wird gesetzt, wenn der Meldungsrumpf fehler grammatikalisch nicht bestimmt werden konnte, Idempotenz geprüft und an das Verarbeitungssystem aufgrund irgend- eines anderen Fehlers als dem 501-507 (z. B. XML rate error) übergeben wurde.

Im Fall eines Statuscodes verschieden von 200, wird der XML-Rumpf der HTTP- Antwort weggelassen. Darüber hinaus werden die anwendungsunabhängigen Sta- tuscodes wie durch HTTP festgelegt für alle HTTP-spezifischen Ausgaben (z. B.

400 Schlechte Anfrage (Bad Request)) verwendet.

Wenn eine Operation beliebig oft ausgeführt werden kann, ohne dass ein Scha- den entsteht, wird diese als idempotent bezeichnet. Aus der Perspektive des IMPP ist Idempotenz eine Eigenschaft, wie ein Empfänger auf eine Meldung ant- wortet. Jede Anfrage im IMPP, welche keine Antwort empfängt, wird wiederge- sendet, weil dem Absender nicht bekannt ist, ob die Anfrage oder Antwort verlo- ren ging. Die übertragene Meldung ist bitweise identisch der ursprünglichen An- fragemeldung. Üblicherweise ist eine doppelte Meldung keine Fehlerbedingung.

Das IMPP-Protokoll arbeitet in Umgebungen, in denen die Meldungsabgabe nicht garantiert ist. Wenn eine IMPP-Anwendung keine Antwort in einer vernünftigen Zeitspanne (festgelegt durch die Anwendung oder möglicherweise in Antwort auf eine Benutzerfrage) empfängt, sendet sie die Meldung erneut. Wenn die empfan- gene IMPP-Anwendung feststellt, dass sie vorher die gleiche Meldung verarbeitet hat, ruft sie die vorherige Antwort ab und sendet die vorherige Antwort wieder.

Wenn der Absender einer Meldung die Antwort nicht empfängt, ist es üblicher- weise nicht möglich zu bestimmen, ob die Anfrage oder die Antwort verloren ging. Um diesen Zustand weiter zu komplizieren, kann die ursprüngliche Anfrage schlicht irgendwo in dem Netzwerk verzögert worden sein und dann möglicher- weise kurz vor dem Eintreffen der zurückübertragenen Anfrage bearbeitet worden sein. Deshalb ermöglicht das Protokoll dem Absender, die Anfrage mit der Garan- tie zu wiederholen, dass das Ergebnis ohne Rücksicht darauf, ob die Anfrage oder die Antwort verloren ging, dasselbe sein wird. Nicht alle IMPP-Meldungen erfor- dern Idempotenz. Das IMPP enthält Meldungen, welche so gestaltet worden, dass sie zu jeder Zeit gesendet werden können, so dass es für einen Empfänger nicht notwendig ist, jede Anfrage zum Feststellen zu speichern, ob ein Duplikat emp- fangen wurde. Die IMPP-Produkte garantieren Idempotenz des Protokolls durch Überprüfen einer Transaktionskennung und Erzeugen eines Zeitstempels (time- stamp) in dem Meldungskopf. Z. B. lehnt ein Bezahlungsserver Versuche ab, Pay- Authorization-Anfragen eines Geldbörsenservers zu wiederholen. Der Bezahlungs- server erkennt diese Versuche durch Überprüfen des Meldungskopfs der Pay-

Authorization-Anfrage. Wenn eine IMPP-Komponente erkennt, dass sie böswilli- gen Überschwemmungs-oder Werbebemüllungsangriffen ausgesetzt ist, welche keine oder mehr idempotente IMPP-Meldungstypen einbezieht, ist es nicht not- wendig, auf diese Meldungen in dieser Situation zu antworten.

Die IMPP-Komponente kann jedes Verfahren nutzen, um idempotente Anfragen zu erkennen. Ein mögliches Verfahren besteht darin, den SHA-1-Hash des Meldung- kopfs aller Meldungen zu speichern. Wenn ein Duplikat erkannt wird, kann der Hash des Meldungskopfs erzeugt und zum Aufsuchen eines gespeicherten Idem- potenz-Eintrags verwendet werden. Bei dieser Herangehensweise muss die IMPP- Komponente eine vollständige Kopie jeder eintreffenden Anfrage aufbewahren, kann. jedoch eine bitweise identische Antwort erzeugen. Eine bitweise Antwort wird hier als eine neue Antwort mit derselben Information erzeugt. Wenn mehre- re Antworten auf eine idempotente Anfrage empfangen werden, kann der Emp- fänger alle solche Antworten nach der ersten ignorieren.

Eine IMPP-Komponente ist nicht zum Beantworten von Meldungen erforderlich, wenn sie erkennt, dass sie böswilligen Überschwemmungs-oder Werbebemül- lungsangriffen ausgesetzt ist, welche mit einem oder mehr IMPP-Meldungstypen einhergehen. Die IMPP-Komponenten können ihre eigenen Kriterien zum Erken- nen solcher Angriffe aufbauen.

Im folgenden werden Beschreibung oder ähnliche Szenarien, welche idempotente Meldungsflüsse einschließen, behandelt. Diese Szenarien beschreiben zwei Über- tragungen derselben Anfrage, abhängig jedoch von den Bedingungen zur Zeit des Versagens kann die Anfrage mehrere Male wiederholt werden. Kombinationen von diesen Szenarien sind auch möglich. Verzögerte Anfrage oder Antwort : Eine idempotente Anfrage wird gesendet, doch die Abgabe entweder der Anfrage oder der Antwort wird verzögert, so dass der Empfänger keine rechtzeitige Antwort empfängt. Die Anfrage wird nochmals übertragen, die empfangene IMPP-Kompo- nente verarbeitet die erste Anfrage und überträgt die Antwort zurück, wenn sie die zweite Antwort empfängt.

Verlorene Anfragen : Eine idempotente Anfrage wird gesendet, doch die Abgabe der Meldung geschieht aufgrund eines Netzwerkversagens nicht. Die Anfrage wird nochmals übertragen.

Verlorene Antwort : Eine idempotente Anfrage wird gesendet und darauf geant- wortet, doch die Abgabe der Antwort geschieht aufgrund eines Netzwerkversa- gens nicht. Die Anfrage wird nochmals übertragen. Die empfangene IMPP-Kom- ponente verarbeitet die erste Anfrage und überträgt dann die Antwort zurück, wenn sie eine zweite Anfrage empfängt.

Es ist notwendig, einen Mechanismus zur Verfügung zu stellen, welcher IMPP- Bezahlungsmeldungen erweitert. Da in der IMPP-Meldung kein Platz vorgesehen ist, um diese Informationen aufzunehmen, wird eine Protokollerweiterung ver- wendet. Der zum Erweitern von IMPP-Meldungen verwendete Mechanismus gleicht der Art und Weise, in der X. 509-Zertifikate erweitert werden. Insbesonde- re wird ein Erweiterungsfeld zur Verfügung gestellt, welches eine Folge von Er- weiterungsdaten enthält. Die Erweiterungsdaten zeigen den Typ der Erweiterung und die Kritikalität (criticality) der Erweiterung an.

Eine Erweiterung weist drei Komponenten auf. Insbesondere eine Objektkennung, welche die Erweiterung eindeutig identifiziert. Diese Kennung erlaubt IMPP-Kom- ponenten eine Erweiterung zu erkennen und Daten zu verarbeiten. Ein Kritikali- tätskennzeichen zeigt an, ob der Empfänger die Erweiterung zum Verarbeiten der Meldung versteht, welche die Erweiterung enthält. Die Daten stellen die zusätzli- che Geschäftsinformation zur Verfügung, welche das Festlegen der Erweiterung notwendig macht. Die Auslegung der Daten wird durch die Organisation festge- legt, welche die Erweiterung erstellt hat.

Das Kritikalitätskennzeichen ist ein boolischer Wert. Eine Erweiterung wird als kritisch eingeschätzt, wenn dieser Wert True ist. Anderenfalls wird die Erweite- rung als unkritisch eingeordnet. Der Standardwert (default value) ist False. Wenn eine Erweiterung kritisch ist, erkennen und verarbeiten Empfänger der Meldung die Erweiterung. Wenn eine Erweiterung unkritisch ist, können Empfänger, wel- che die Erweiterung nicht verarbeiten können, die Daten sicher ignorieren.

Ein Satz von Informationsobjekten wurde für jede Datenstruktur erzeugt, welche eine Erweiterung enthalten kann. Diese Sätze legen die Erweiterungen fest, wel- che in der Datenstruktur zum Verarbeiten erlaubt sind.

IMPP-Anwendungen passen in eine von zwei Kategorien. Insbesondere in eine Anwendung, welche keine Meldungserweiterungen unterstützt und in eine An- wendung, welche einige ausgewählte Sätze von Meldungserweiterungen unter- stützt. Eine IMPP-Komponente, welche keine Meldungserweiterungen unterstützt, erkennt das Vorhandensein einer Erweiterung in einer Meldung und überprüft das Kritikalitätskennzeichen. Ist die Erweiterung kritisch, verarbeitet die IMPP-Kom- ponente die Meldung nicht und weist sie mit einem Fehlercode unrecognizedEx- tension zurück. Ist die Erweiterung unkritisch, kann die Anwendung die Daten in der Erweiterung ignorieren und den Rest der Meldung weiterverarbeiten. Eine Anwendung, welche Meldungserweiterungen unterstützt, erkennt das Vorhanden- sein einer Erweiterung in einer Meldung und verarbeitet die Erweiterung wie folgt.

1. Wenn die Anwendung die Objektkennung für diese Meldung unterstützt, wer- den die Daten in der Erweiterung verarbeitet.

2. Wenn die Anwendung die Objektkennung für diese Meldung nicht unterstützt und die Erweiterung kritisch ist, verarbeitet die Anwendung die Meldung nicht und weist sie mit einem Fehlercode unrecognizedExtension zurück.

3. Wenn die Anwendung die Objektkennung für diese Meldung nicht unterstützt und die Erweiterung unkritisch ist, kann die Anwendung die Daten in der Erweite- rung ignorieren und den Rest der Meldung weiterverarbeiten.

Das OpCo ist die letztendliche Entscheidungsinstanz darüber, ob ein gegebenes Datenelement innerhalb einer Meldung verschlüsselt wird. Das OpCo kann die Nutzung irgendeiner Erweiterung ablehnen, welche Daten enthält, die die Integri- tät des IMPP beeinträchtigen können. Jede Erweiterung wird durch ihren Erweite- rungsnamen, Eigentümernamen und eine eindeutige Erweiterungskennung identi- fiziert. Eine IMPP-Komponente kann entscheiden, eine kritische Erweiterung zum Übertragen zusätzlicher Informationen in dem normalen IMPP-Meldungsfluss zu

benutzen. Wenn die empfangende IMPP-Komponente die Daten ohne die Erweite- rung nicht versteht und diese deshalb nicht verarbeiten kann, sollte die Meldung abgelehnt werden.

Hinsichtlich der Transaktionen ist das Transaktionsmanagement verteilt, d. h. ein in eine Transaktion einbezogener Geldbörsenserver und Bezahlungsserver kom- munizieren unter Verwendung von IMPP-Meldungen. Beide Server enthalten einen Statusmechanismus, z. B. Warten auf Antworten, Überprüfen von Unterbrechun- gen (time-out) und Senden von Abfrage-und Wiederherstellungsmeldungen im Fall von Fehlern. Die CPP hält ebenfalls Statusinformationen aufrecht, da IMPP- Meldungen durch die CPP weitergeleitet werden. Der"Eigentümer"einer Transak- tion ist die Partei, welche für die primären Statusübergänge während der Le- bensdauer einer bestimmten Transaktion verantwortlich ist. Der genutzte Syn- chronisationsmechanismus hängt von der technischen Eigentümerschaft der Transaktion ab. Es existieren verschiedene mögliche Eigentümerschaften für ver- schiedene durch IMPP unterstützte Bezahlungsmodelle, wie weiter unten be- schrieben ist. Bezahlungsmodell Eigentümer des Transaktionsstatus Direkte Makrobezahlung Bezahlungsserver Verzögerte Makrobezahlung Bezahlungsserver Guthaben Makrobezahlung Bezahlungsserver Direkte Mikrobezahlung Geldbörsenserver Verzögerte Mikrobezahlung Geldbörsenserver Gutschrift Mikrobezahlung Geldbörsenserver Das IMPP stellt die entsprechenden Meldungen oder Meldungsfolgen zum Unter- stützen des Bezahlungsmodells zur Verfügung. Es existieren wenigstens zwei ver- schiedene Möglichkeiten, um Transaktionen über IMPP zu synchronisieren.

1. Benachrichtigen (Notify)/Bestätigen (Acknowledge) : Die Verteilung von Informa- tionen über einen Statusübergang wird durch den Eigentümer der Transaktion durchgeführt.

2. Synchronisieren (Synchronize) : Die Verteilung von Informationen über einen Statusübergang wird durch einen entfernten (remote) Teilnehmer der Transaktion ausgelöst (triggered).

Benachrichtigen/Bestätigen ist verfügbar, wenn es in dem entsprechenden Proto- kollfluss unterstützt wird. Wenn verfügbar, wird nur eine Benachrichtigung pro Übergang durchgeführt. Folglich werden unbestätigte Benachrichtigungen durch den Eigentümer nicht berücksichtigt. Die Synchronisation ist für entfernte Teil- nehmer verfügbar, um Übergänge in einen finalen Status mehrmals abzufragen.

Die Stati und deren Übergänge werden aus der Protokollperspektive genau be- schrieben, welche eine Abstraktion von der Implementation in den Bezahlungs- komponenten bedeutet. Wenn eine Komponente die"Historie (history)"eines Status benötigt, d. h. den Übergang, welcher zu einem Status führt, kann die Komponente anstatt dessen einen'zusammengesetzten Status (composite state)' aufrechterhalten. Darüber hinaus legt jede Bezahlungskomponente ihren eigenen Weg fest, um Transaktionen zu löschen, d. h. um eine bestimmte Transaktion aus einem letztendlichen Geschäftsstatus in einen letztendlichen technischen Status zu überführen. Dies wird asynchron durchgeführt und ist nicht durch IMPP-Proto- kollmeldungen gedeckt.

Die Übergangsphasen sind weiter unten beschrieben. Tx-Phase Auslöse-und Verteilungsmechanismen für Statusübergänge Setzen (Set) wenn der Statusübergang bei dem Ei- gentümer der Transaktion durch Verar- beitung einer IMPP-Meldung, der zuge- hörigen Protokollmeldung durchgeführt wird Benachrichten (Notify) die von dem Eigentümer benutzte IMPP- Meldung, um den entfernten Teilnehmer über den Übergang zu benachrichtigen Bestätigen (Acknowledge) die von dem entfernten Teilnehmer be- nutzte IMPP-Meldung zum Bestätigen des Statusübergangs Synchronisieren (Synchronize) die von dem entfernten Teilnehmer be- nutzte IMPP-Meldung, um den Status- übergang wieder zu synchronisieren

Bezahlungsverarbeitung Weiter unten wird eine detaillierte Beschreibung von Prozessen gegeben, welche durch die beispielhafte Ausführungsform der CPP durchgeführt werden. Insbe- sondere wird die übliche Verarbeitung beschrieben genauso wie die Verarbeitung, welche mit OfferIDs, Negativdateien, Geldumrechnung, Transaktionsprotokollie- ren, Mikrobezahlungsausgleich und-abrechnung und Gebührenmanagement ver- bunden ist.

Für Mobilbezahlungen werden alle Anfragen und Antworten zwischen Geldbörsen- server und Bezahlungsserverinstanzen weitergeleitet. Andere CPP-Komponenten, welche zentralisierte Aufgaben ausführen, wie der OfferID-Generator, der Such (look-up)-Dienst und der FX-Server, werden von der Weiterleitungsmaschine benutzt, um den Bezahlungsprozess zu unterstützen. Transaktionsprotokolleinträ- ge werden erzeugt, um rechtliche Erfordernisse zu erfüllen und entkoppel- te (offline)-Modus-Prozesse wie Gebührenrechnungsstellung zu ermöglichen. Ad- ressänderungsanfragen, Altersprüfanfragen und Anfragen zum Wechsel des Be- zahlungsmittels werden zusammen mit regulären Bezahlungsanfragen genauso unterstützt. Qualitätskennzeichen werden zusammen mit diesen Anfragen/Ant- worten übertragen und zeigen den Qualitätsgrad der zugrundeliegenden Daten an.

\ Die Weiterleitungsmaschine empfängt externe Benachrichtigungen über Makrobe- zahlungsberechtigungen und-erfassungen, vervollständigt die Transaktionsproto- kolle und Austauschbenachrichtigungen hinsichtlich Statuswechseln zwischen den anderen einbezogenen Parteien, um die Transaktionsprotokolle von WS, MS und CPP konsistent zu halten.

Mit den Mikrobezahlungen wird die Berechtigung zwischen WI und dem Anbieter des Mikrobezahlungsmittels durchgeführt. Deshalb werden Berechtigungs-Tokens mit dem Bezahlungsmeldungsfluss an den Bezahlungsserver übertragen. Für ge-

rade stattfindende Transaktionen hält die Weiterleitungsmaschine Transaktions- datensätze aufrecht, in welchen alle Information über eine Transaktion zusam- men mit einer eindeutigen TransactionID (TX_ID) gespeichert ist.

In Umleitungsszenarien stellt die Weiterleitungsmaschine eine Umleitungskompo- nente zur Verfügung, welche'Umleitungen (redirects) 'verarbeitet, bei denen der Browser des Kunden von der Händler-URL zu ihrer oder seiner Heimgeldbörsen- URL über ein CPP-URL und direkt zurück zu der Händler-URL nach Abschluss der Transaktion umgeleitet wird. Die Umleitungskomponente stellt eine zentrale Um- leitungs-URL zur Verfügung, welche Händler üblicherweise nutzen können, um die OfferID anzuzeigen. Darüber hinaus kann der Käufer MSISDN/Pseudo- nym/Alias in einer vertrauten Umgebung eingeben, um Anschub- (push) oder Rückfall (fall-back) szenarien (wenn MSISDN nicht erkannt werden kann) zu er- möglichen. Um Vorwärtsszenarien zu unterstützen, leitet die Umleitungskompo- nente das Pseudonym des Käufers an den Geldbörsenserver weiter. Der WS löst dann einen IVR-Ruf (call) oder WAP-Anschub an den Käufer aus. Die Umleitungs- komponente sollte nicht für nicht-mobile Kundenberechtigung (Web-Web Szena- rio) genutzt werden, z. B. mit Pseudonym-PIN, weil die Kundenberechtigung in der Verantwortung des Geldbörsenservers liegt.

Bei WAP-WAP-Szenarien unterstützt die Weiterleitungsmaschine'Umleitungen (redirects) ', bei denen der Browser des Kunden von der Händler-URL zu seiner Heimgeldbörsen-URL über ein OpCo-URL umgeleitet und direkt zurück zu der Händler-URL nach Abschluss der Transaktion umgeleitet wird. Die CPP stellt eine zentrale URL bereit, um die OfferID anzuzeigen. Deshalb braucht der Händler die Anzeige der OfferID nicht in den Einkaufsfluss zu integrieren. Darüber hinaus stellt diese URL Eingabefelder für MSISDN/Pseudonym zur Verfügung, um einen Anschub einzuleiten.

Transaktionen zwischen Händlern und Kunden, welche der gleichen Firma ange- hören, z. B. MNO, werden als"unter uns (on-us) "-Transaktionen bezeichnet, auf welche spezielle Regeln angewendet werden können. Wenn'unter uns'-Transak- tionen zwischen einem Geldbörsenserver und einem MA-Server bewirkt werden, welche durch dieselbe Firma in einem Land betrieben werden, können diese Transaktionen ohne Weiterleiten durch das OpCo verarbeitet werden.

Die CPP identifiziert ein'unter uns'-Szenario und gibt eine entsprechende Antwort an den WS zurück. Bei Abschluss der Berechtigungsphase wird die CPP durch den PS benachrichtigt, um die OfferID zu entfernen und die'unter uns'-Beziehungen zwischen WS-und PS-Instanzen (betrifft beide Varianten) zu speichern. Jede Transaktion durch die CPP wird geprüft, um zu erkennen, ob der Typ der Trans- aktion'unter uns'ist, wobei in diesem Fall das'unter uns'-Kennzeichen innerhalb des Transaktionsdatensatzes gesetzt wird (betrifft beide Varianten). Bei Erken- nung einer'unter uns'-Transaktion wird der eingeleitete Bezahlungsfluss durch Senden der PS-Suchinformation an den WS beendet.

Alle Anfragen, welche ursprünglich von entweder dem Geldbörsenserver oder Be- zahlungsserver stammen, werden zusammen mit der ID des entsprechenden Geldbörsenservers oder Bezahlungsservers protokolliert. Das Protokollieren von 'unter uns'-Transaktionen wird so wie das für Schema-Transaktionen getätigt, je- doch wird das'unter uns'-Kennzeichen gesetzt.

Der Suchdienst führt auf Anfrage Suchen nach dem Geldbörsenserver und Bezah- lungsserver aus. Basierend auf einer OfferID stellt der Suchdienst den entspre- chenden Bezahlungsserver mittels Durchsuchen des OfferID-Repositoriums fest.

In der entgegengesetzten Richtung kann der Heimgeldbörsenserver durch Zugrei- fen auf die Teilnehmerliste abgerufen werden.

Die Suche nach dem in eine Transaktion eingebundenen PS und Händlers wird basierend auf der OfferID oder RangeID getätigt. Durch Ausführen der Suche ba- sierend auf einer OfferID wird die BasketID aufgelöst und zusammen mit der OID an den MC übertragen, um den Einkaufskorb anzufragen. Der Händler entscheidet dann, ob die OID oder die BasketID zum Identifizieren des Einkaufskorbs genutzt wird. Durch Ausführen der Suche basierend auf einer RangeID wird die Kombina- tion aus RangeID und Händlerkatalognummer an den MC übertragen, um den Einkaufskorb abzufragen.

Die Teilnehmerliste enthält alle MSISDNs und Pseudonyme des Käufers, welcher für mobile Bezahlung eingetragen ist. Für jedes MSISDN/Pseudonym wird die HeimgeldbörsenserverID ebenfalls gespeichert. Die MSISDNs/Pseudonyme, wel-

che nicht eingetragen sind, können in dem Prozess auch frühzeitig durch die CPP abgewiesen werden.

Die Geldbörsenserverinstanzen nutzen Online-Anfragen oder erzeugen eine flache (flat) Datei, welche alle neuen oder geänderten Teilnehmer enthält und übertra- gen die Datei an das OpCo, um die Teilnehmerliste zu aktualisieren. Pseudonyme werden an dem WS in Übereinstimmung mit den Pseudonym-Erzeugungsregeln (alias generation rules) (3 Ziffern identifizieren das WI, 8 Ziffern als KäuferID und eine-Prüfsummenziffer) erzeugt.

OfferIDs Die OfferID-Serverkomponente der CPP umfasst den OfferID-Generator, welcher eine OfferID auf Anfrage erzeugt und das OfferID-Repositorium, welches erzeug- te OfferIDs zusammen mit zusätzlichen Daten für Suchzwecke speichert und de- ren Lebensdauer verwaltet. Das OfferID-Nummerierungssystem stellt sicher, ab- hängig von der Anzahl der zu einer bestimmten Zeit benutzten OfferIDs, dass die Anzahl der genutzten Ziffern variieren kann, um immer die kleinstmögliche An- zahl zur Verfügung zu stellen. Für einige mobile Bezahlungsszenarien ist die Grö- ße der OfferID überhaupt nicht kritisch (z. B. Bankknoten). Abhängig von der an- gefragten Lebensdauer stellt die folgende Tabelle die minimale Länge einer OID dar : <=1 Stunde kürzest verfügbar (Minimum 4 Ziffern) 1 Stunde-1 Tag [kürzest verfügbar (Minimum 4 Ziffern) ] +2 > 1 Tag [kürzest verfügbar (Minimum 4 Ziffern) ] +4 Umleitung 16 Ziffern Die Länge der OfferIDs (obige Tabelle) ist konfigurierbar. Abhängig von dem Ver- trag mit einem Händler können bestimmte Bereiche von OfferIDs für einen Händ- ler reserviert werden. Der Händler zahlt eine Benutzungsgebühr für den Bereich und kann jede (Katalog-) Nummer nach dem Bereichskennzeichen nutzen, um die ID für sein Angebot abzubilden. Durch Nutzen dieses Mechanismus kann der Händler existierende Katalognummern durch einfaches Aufaddieren seines spezi- fischen Händlerpräfixes (prefix) wiederverwenden.

Prüfsummentests ermöglichen es dem Geldbörsenserver umgehend eine OfferID zu überprüfen und zusätzliche Nutzereingaben anzufragen, ohne mit der CPP kommunizieren zu müssen. Die Wahrscheinlichkeit versehentlich einen anderen aktiven Einkaufskorb durch fehlerhaftes Eingeben einer falschen OfferID zu iden- tifizieren sollte niedrig genug sein, um das Risiko tolerierbar zu machen. Wenigs- tens eine einzelne falsche Ziffer, zusätzliche/fehlende Ziffern und verwechselte Ziffern können erkannt werden. Die Prüfsummenziffer ist für RangeIDs nicht ver- fügbar.

OfferID/RangeID-Struktur Präfix n Zifferninhalt Prüfsumme Präfix n Ziffern RangeID M Ziffern Händlerinhalt Der Präfix (nicht notwendigerweise eine ganze Ziffer) führt bestimmte Steuerin- formationen mit, bei der es wichtig ist, diese von der OfferID direkt ohne Zugriff auf das OID-Repositorium abzurufen. Üblicherweise existiert keine HändIerID, welche mit der OID kodiert ist. Die einzige Ausnahme betrifft RangeIDs, bei wel- chen die OID aus einem Bereichskennzeichen und einer händlerspezifischen Er- weiterung besteht.

Bei Installationen in verschiedenen Regionalen wird die CPP_ID in den OfferID- Präfix kodiert, um eine OID-Weiterleitung zu ermöglichen. Der OfferID-Generator erzeugt auf Anfragen OfferIDs. Es können statische und dynamische OfferIDs er- zeugt werden. OfferIDs werden einmalig ausgegeben. Nachfolgende Bezahlungs- transaktionen können dieselbe OfferID für Bezahlungstransaktionen nutzen (z. B.

VM, TV-Einkauf). Statische OfferIDs werden von den Händlern auf monatlicher oder jährlicher Basis'gemietet (rented)'. Wenn die Mietdauer abläuft, schaltet die OID in den Status'Sperre (black-out)', aus welchem die OID wieder aktiviert werden kann, wenn der Händler die Mietvereinbarung weiterführt. Der Händler muss die parallele Benutzung der statischen OID handhaben.

OfferIDs kennzeichnen ein temporäres Angebot mit einer bestimmten Lebensdau- er und werden exklusiv durch einen einzelnen Kunden genutzt. Eine OfferID wird automatisch gelöscht, sobald eine Transaktion beendet oder die maximale Le- bensdauer überschritten wird. Bankknotenszenarien benutzen z. B. eine dynami- sche OfferID mit einer verlängerten Lebensdauer. Wenn ein Kunde eine Transak- tion nach Eingeben der OfferID abbricht, wird die OID nicht gelöscht. Alle Of- ferIDs können jedoch auf Anfrage explizit gelöscht werden.

Hinsichtlich dynamischer OfferIDs wird eine OfferID durch den Händler auf An- frage nach dynamischen OfferIDs festgelegt. Nach Ablauf der Lebensdauer wird der Status auf'Sperre (black-out)'gesetzt. Die maximale Lebensdauer wird einen Monat betragen. Während der Sperrdauer können OIDs nicht nochmals ausgege- ben werden. Die Sperrdauer ist konfigurierbar und hängt von der Lebensdauer der OID ab : abgeschlossen 1 Stunde 0 bis 10 Minuten 1 Stunde 10 bis 16 Minuten 6 Stunden 1 Stunde bis 24 Stunden 1 Tag 1 Tag bis 7 Tage 1 Woche 1 Woche minus 4 Wochen 2 Wochen 1 Monat bis 12 Monate 1 Monat Beim Erfragen einer OID kann der Händler bestimmte Attribute setzen, um den Typ der Anfrage anzuzeigen (Zahlung, Altersprüfung, Adressübertragung, PI- Übertragung von Details). Mit einer Anfrage für eine OID kann der Händler eine Markenliste herausgeben, um Markenübereinstimmung (brand matching) mit PI- Detailübertragungen zu unterstützen. Die Einkaufs-BasketID kann mit der OfferID verbunden sein.

Zum Erzeugen statischer OfferIDs wird die OfferID durch den Händler auf Anfra- ge nach einer statischen OfferID festgelegt. Nach Ablauf der Mietdauer wird der OfferID-Status auf'Sperre'geschaltet. Die minimale Mietdauer ist 1 Monat. Die Mietdauer beginnt mit dem Erzeugen der OID, nicht mit Aktivierung. Die Anfrage nach einer einzelnen OID kann durch das MC durchgeführt werden (genauso für

dynamische OIDs). Weil die Einkaufs-BasketID mit der Anfrage übertragen wird, ist die statische OID automatisch nach der Anfrage aktiviert. Der Händler kann eine Stapelerzeugung von OfferIDs gemäß dem CPP-Nummerierungsschema er- fragen. Diese Anfrage wird durch die Händlerselbstbedienung durchgeführt und nicht direkt durch die Händlerkomponente. Als Folge davon empfängt der Händler eine Datei, welche alle erzeugten OIDs und das Ablaufdatum der Mietdauer ent- hält.

Mit den RangeIDs erhält der Händler die Möglichkeit, existierende Katalognum- mern mit dem mobilen Bezahlungsschema wiederzuverwenden. Auf Anrage nach einer RangeID spezifiziert der Händler die Nummer von UnterIDs, welche er be- nutzen will. Während der Suche wird der Händler identifiziert. Die Kombination von RangeID und Katalognummer wird an den Händler weitergeleitet, um den Einkaufskorb zu erhalten.

Das OfferID-Repositorium enthält alle Informationen über erfragte OfferIDs.

Wenn Altersprüfungen, Adressaustausch oder PI-Datentransfer gefragt ist, wer- den die relevanten Kennzeichen (flags) in dem OfferID-Repositoriumsdatensatz gesetzt. Das OfferID-Repositorium überwacht die ausgegebenen OfferIDs und setzt Stati auf'Sperre', sobald eine zugehörige Lebensdauer abläuft. Das OfferID- Repositorium unterstützt auch das manuelle Löschen von Anfragen. Der Such- dienst benutzt das OfferID-Repositorium, um zugehörige Bezahlungsserver zu er- fragen.

Um die statische OID mit einem anderen Korb zu verbinden oder die Anfragety- pen zu verändern unterstützt das OfferID-Repositorium die Deaktivierung von OIDs. Durch das MC ist die Deaktivierung nur für einzelne OIDs erlaubt. Dieses Merkmal kann auch genutzt werden, wenn ein Artikel vorübergehend nicht erhält- lich ist oder der Händler eine verlängerte Sperrdauer haben möchte. Die Miet- dauer wird durch die Deaktivierung nicht verlängert. Wenn mehrere OIDs deakti- viert werden müssen, wird das MSS genutzt.

Das Repositorium unterstützt die Änderung statischer OIDs (d. h. Verknüpfen an- derer BasketIDs, Änderungsanfragetypen oder Verlängerung der Mietdauer). Das Repositorium unterstützt die Stapeländerung (batch modification) von statischen

OIDs (d. h. Verknüpfung anderer BasketIDs, Änderungsanfragetypen oder Verlän- gerung der Mietdauer). Diese Anfrage wird durch das MSS durchgeführt.

Eine einzelne OID kann aktiviert werden. Es können auch mehrere OIDs durch das MSS aktiviert werden. Um eine solche Aktivierung vorzunehmen, lädt der Händler eine Liste von BasketIDs zusammen mit allen anderen Anfrageparame- tern. Nach Erzeugung des OID-Blocks empfängt der Händler eine Zuordnungsda- tei (location file).

Das OfferID-Repositorium löscht automatisch OIDs, wenn die Lebensdauer ab- läuft oder wenn eine Transaktion beendet ist. Ein Käuferabbruch resultiert nicht in einem Löschen der OID. Das OID-Repositorium erlaubt auch das Löschen von OIDs im einfachen (single) und Stapel (batch) -Modus. Bei dynamischen OIDs re- sultiert ein Löschen in einer unmittelbaren Beseitigung, während bei statischen OIDs das Löschen den OID-Status auf'Sperre (black-out)'setzt.

Durch das MSS kann der Händler eine OID mit dem Status'Sperre'wieder her- stellen. Statische OIDs müssen gesperrt werden, wenn der Mietvertrag abläuft.

Während der Sperrdauer ist der Händler in der Lage, die OID durch Erfragen ei- ner Verlängerung der Mietdauer durch das MSS zu reaktivieren.

Negativdateien Der Negativdatei-Dienst stellt eine zentrale und gemeinsame (consolidated) Da- tenbasis zur Verfügung, um Händler wie auch Kunden zu sperren. Die Geldbör- senserver-und Bezahlungsserver-Instanzen können auf Basis einer Anfrage ge- gen die Datenbank prüfen genauso wie ihre lokalen Negativdatei-Verzeichnisse mit dem Negativdatei-Dienst an der Prozessorplattform synchronisieren.

Durch die CPP kann ein einzelner Händler zu der Negativdatei zusammen mit ei- nem Zeiteintrag zugefügt werden. Zusätzlich kann die Negativdatei überprüft werden, um festzustellen, ob ein Datensatz hinsichtlich eines einzelnen Händlers existiert. Ein Händlerakquisiteur kann diese Prüfung von außerhalb auslösen. Zu- sätzlich kann ein einzelner Händler aus der Negativdatei entfernt werden. Eine Liste von Händlern kann auch in eine Negativdatei importiert werden. Wenn ein

Händler schon in der Negativdatei geführt ist, wird der zugehörige Datensatz übersprungen. Händlerdateisätze in der Datei können auch zur Beseitigung ge- kennzeichnet werden. Während des Importierens werden diese Händler aus der Negativdatei entfernt. Eine Händlernegativdatei kann auch exportiert werden.

Z. B. kann eine Datei heruntergeladen (downloaded) oder an einen Händlerakqui- siteur übertragen werden, um eine lokale Negativdatei zu aktualisieren.

Ein einzelner Käufer kann zu der Negativdatei zusammen mit einem Zeiteintrag in dem Datensatz hinzugefügt werden. Die Negativdatei kann überprüft werden, um festzustellen, ob sie einen Datensatz über einen einzelnen Käufer enthält. Ein Geldbörsenausgeber kann diese Prüfung von außerhalb auslösen. Die CPP kann auch jede Transaktion gegen die innere (internal) Negativdatei prüfen. Ein ein- zelner Käufer kann aus der Negativdatei entfernt werden. Auch kann eine Liste von Käufern in die Negativdatei importiert werden. Wenn ein Käufer schon in der Negativdatei geführt ist, kann der zugehörige Datensatz der Datei übersprungen werden. Käuferdatensätze in der Datei können auch zur Beseitigung gekenn- zeichnet werden. Während des Imports werden diese Käufer aus der Negativdatei entfernt. Eine Datei, welche alle negativen Dateidatensätze enthält, die nach ei- ner gewissen Zeit erzeugt wurden, kann exportiert werden. Diese Datei kann dann heruntergeladen oder an einen Geldbörsenausgeber übertragen werden, um eine lokale Negativdatei zu aktualisieren.

Alle Änderungsaktionen der Negativdatei werden protokolliert. Die historischen Negativdateidaten werden gespeichert und ein Status (z. B. eingetragen (listed), gesperrt (blocked), inaktiv (inactive), gelöscht (deleted)) wird beibehalten. Nach einer gewissen Periode (d. h. drei Jahren) werden gelöschte Einträge physisch aus den Negativdateidatensätzen entfernt.

Währungsumrechnung Das System unterstützt drei verschiedene Währungen : Die Währung, welche der Transaktion zugrunde liegt ; die Registrierungswährung der Käufer am WI ; und die Währung, welche das MA mit der CPP abrechnet. Für internationale Mikrobe- zahlungen wird der Betrag einer Transaktion von der Transaktionswährung zu der WI-Abrechnungswährung (Binnenwährung des Käufers) vor der Berechtigung des

Kunden und Abzug (deduction) von dem SVA umgerechnet. Da beide Währungen dem Kunden angezeigt werden und das SVA basierend auf dem zugrundeliegen- den Kurs abgezogen wird, können Währungsrisiken existieren, welche durch zu- sätzliche Kursaufschläge abgedeckt werden.

Das OpCo beinhaltet ein Währungsrisiko bei Berechtigung einer pPI, wenn der Ausgleich mit dem MA nicht am selben Tag ausgeführt werden kann. In diesen Fällen kann das OpCo eine Aufschlag auf den Währungskurs aufrechnen.

Die Währungsumrechnungstabelle speichert Währungskurse. Ein Datensatz wird für jedes Währungspaar (EUR/GBP) und (GBP/EUR) erzeugt. Die Zeitmarke spei- chert die Information der letzten Aktualisierung des Datensatzes. Zusätzliche Sta- tusinformationen können in dem'Status'-Feld (z. B. abgelaufen (expired), gültig (valid)) gespeichert werden. Die Währungsumrechnungstabelle wird auf einer vorbestimmten regelmäßigen Basis durch Kontaktaufnehmen mit einem Umrech- nungskursdienstanbieter und Importieren der aktualisierten Umrechnungskurse in die Umrechnungstabellen aktualisiert. Der Zeitstempel und Status werden eben- falls aktualisiert.

Das Statusfeld der Währungsumrechnungstabelle wird auf'abgelaufen (expired) ' geschaltet, wenn das Währungspaar eine bestimmte Anzahl von Tagen (d. h. ei- nen Tag, konfigurierbar) aktualisiert wurde. Abgelaufene Währungspaare haben keinen Einfluss auf die Währungsumrechnung.

Die Umrechungstabelle kann in eine Datei exportiert werden, welche durch den Geldbörsenanbieter oder die OpCo-Finanzabteilung heruntergeladen werden kann. Die Kurse umfassen die OpCo-Aufschlag. Eine Beispieltabelle ist unten ge- zeigt.

Währungskode Händler (ISO) Währungskode Kunde (ISO) Format (Dezimalen) Umrechnungsfaktor Zeitstempel Status (aktuell (current), abgelaufen (expired))

Hinsichtlich der Aufschlagstabellen werden zusätzliche OpCo-Aufschläge in einer zusätzlichen Tabelle (d. h. einer Aufschlagstabelle) gespeichert. Ein Datensatz wird für jedes Währungspaar (EUR/GBP) und (GBP/EUR) erzeugt. Der Zeitstempel speichert die Information der letzten Aktualisierung des Datensatzes. Zusätzliche Statusinformationen können in dem'Status'-Feld (z. B. abgelaufen (expired), gül- tig (valid)) gespeichert werden. Administratoren können Aufschlagsprozente für Währungspaare durch Übertragen einer flachen Datei (flat file) an den FX-Server aktualisieren, welche dann in die Aufschlagstabelle importiert werden. Ein Bei- spiel einer Aufschlagstabelle wird im folgenden gezeigt : Währungskode Händler (ISO) Währungskode Kunde (ISO) Aufschlagsprozentsatz Aufschlagsbetrag Üblicherweise wandelt die CPP Beträge basierend auf Umrechnungskursen und CPP-Aufschlag um und überträgt die Beträge in TX-Währung, umgewandelter Währung und Umwandlungskurs. Durch diesen Prozess kann die Umrechnungs- kurssynchronisation weggelassen werden, da der aktuellste Umrechnungskurs benutzt wird. Die Währungsumrechnung geschieht gemäß den Regeln der europä- ischen Zentralbank (ECB European Central Bank)). Wenn Einheiten nationaler Währung in EUR ausgedrückt werden, umfasst der Betrag sechs Zahlen vor und/oder nach dem Dezimalpunkt. Bei Umrechnung der Währungen in EUR wer- den Zwischenergebnisse auf ein Minimum von 3 Dezimalstellen (nach dem Dezi- malpunkt) berechnet. Währungsbeträge, welche in EUR ausgewiesen sind, wer- den auf den nächsten Eurocent auf-oder abgerundet.

Eine Schnittstelle zu einem Anbieter von internationalen Währungsumrechnungs- kursen (d. h. Reuters, Bloomberg, Bridge oder Telerate) ist eingeführt. Die Fi- nanzabteilung der WIs oder OpCo's kann eine exportierte Umrechnungskursdatei herunterladen.

Es werden Administrationseinrichtungen für OpCo-Administratoren und die Fi- nanz-oder Wertpapierabteilung des OpCo zur Verfügung gestellt. Diese Einrich-

tungen umfassen z. B. das Verwalten des Ablaufs zum Holen von Umrechungskur- sen über die festgelegte Schnittstelle zu dem Umrechnungskursanbieter, das Festlegen von Regeln zum Aktualisieren des Status, das Anschauen und manuelle Editieren von Umrechnungskursen, das Anschauen und manuelle Editieren von Umrechnungskursaufschlägen und das Anschauen des Wechselprotokolls und der historischen Daten. Um die umgehende Benachrichtigung des verantwortlichen Administrators sicherzustellen, alarmieren den Administrator bestimmte Ereignis- auslöser (event trigger). Z. B. lösen die folgenden Ereignisauslöser Meldungen an den Administrator aus : Fehler : Import der Währungskurse fehlgeschlagen Fehler : Export der Dateien fehlgeschlagen Warnung : Umrechnungskurs abgelaufen Warnung : Umrechnung mit abgelaufenem Umrechnungskurs nach Voreinstellung durchgeführt Der Administrator empfängt Alarme als eine Meldung in der Administrator-GUI.

Zusätzlich kann er wählen, ebenfalls Alarme durch E-Mail oder SMS zu empfan- gen. Der Administrator benutzt die Administrator-Service-GUI, um Zugang zu de- taillierten Fehlerlisten/berichten zu erhalten. Detaillierte Fehlermeldungen wer- den nicht mit einer Benachrichtigung übertragen.

Darüber hinaus werden alle Änderungen der Währungsumrechnungskurse proto- kolliert. Historische Daten werden für rechtliche Zwecke gespeichert (10 Jahre).

Bei Rücküberstattungen wird der FX aus dem TX-Protokoll festgelegt und nicht aus der Datei für historische Daten. Das Transaktionsprotokoll dient als Basis für Gebührenabrechnung und Streitabwicklungen. Mehrere Protokollebenen werden auf Anfragebasis unterstützt. Z. B. : Protokollieren aller Ereignisse mit allen Attributen Protokollieren der Ereignisse nur mit Schlüsselattributen Protokollieren nur der Ereignisse Protokollieren nur der Fehler.

Die Protokolldateien werden zur Verarbeitung bis zu drei Monate gespeichert.

Danach werden die Transaktionsprotokolle für 10 Jahre archiviert. Bei allen ope- rationalen Prozessen werden gesetzliche Anforderungen befolgt, z. B. das Daten- schutzgesetz. Eine NewCo-Datenschutzstrategie sollte festgelegt und für alle NewCo-Teilnehmer verbindlich gemacht werden, um das Käufervertrauen zu stei- gern.

Mikrobezahlungsausgleich und-abrechnung Der CPP-Ausgleichs-und Abrechnungs- (C&S)-Dienst verarbeitet durch Händlerak- quisiteure eingeleitete Ausgleichsanfragen, sammelt durch das MA abzurechnende und mit dem pPI-Anbieter auszugleichende Beträge. Zusätzliche Abrechnungsda- tensätze und Angaben werden erzeugt, um Abrechnungsdetails allen uPI-Anbie- tern (WI und MAs) zur Verfügung zu stellen. Der Finanzmitteltransfer wird an ei- nem Hauptbuchungssystem ausgelöst. Für Händlerakquisiteure unterstützt der Ausgleichs-und Abrechnungsdienst sowohl Einheitswährungsabrechnung wie auch Multiwährungsabrechnung. Bei Multiwährungsabrechnung wird das MA in verschiedenen TX-Währungen abgerechnet. Für jede MA zeigt der Hauptdatenda- tensatz alle Abrechnungswährungen des MA und ob der MA für Einfach-oder Mul- tiwährungsabrechnungen gewählt wurde, an.

Die Aufgabe des Ausgleichs und der Abrechnung kann in den folgenden Schritten, wie in Figur 23 dargestellt und weiter unten beschrieben, aufgeteilt werden : 1. Vorverarbeitung (Vermittlung und Abstimmung) 2. Ausgleich mit MA (Sammlung hinsichtlich MA) 3. Ausgleich mit uPI-Anbieter (Sammiung hinsichtlich luPI-Anbieter) 4. Buchung (Einleiten der Abrechnung) 5. Abweisungs-und Rückführungsprozess (Fehlerverarbeitung) 6. Streitverarbeitung 7. Täuschungserkennung 8. Verwaltung Wenn ein Ausgleichsdatensatz durch den Ausgleichs-und Abrechnungsprozess läuft, nimmt er verschiedene Stati wie in Figur 24 dargestellt an. Vorverarbeitung

(Vermittlung und Abstimmung) ist ein linearer Prozess. Sammeln hinsichtlich der PIs und MAs können parallel durchgeführt werden. Das Ergebnis des Prozesses ist in einem Abrechnungsbericht (einschließlich Fehlerkodes) und einer'Sammel- tabelle (Aggregation table)'dokumentiert, welche zum Buchen im Hauptbuch ge- nutzt wird.

Der Händlerakquisiteur leitet C&S durch Senden der Erfassungs-/Berechtigungs- Token enthaltenden Ausgleichsdatei an den CPP-C&S-Dienst ein. Gemäß des Aus- gleichsablaufs bringt der C&S-Dienst die MA-Ausgleichsdatei mit den intern ge- sammelte Transaktionsprotokollen in Einklang. Ein'Abrechnungsbericht (Settle- ment Report) 'wird erzeugt, um den Händler über alle Transaktionen zu informie- ren, welche abgerechnet werden sowie über alle zurückgewiesenen Transaktio- nen.

Ein TX-Ausgleichsdatensatz enthält die AkquisiteursID, BezahlungsmittelID, Tran- saktionsID, Beträge und den Verarbeitungsstatus wie unten beschrieben : MAID PPI_ID TXID Berechtigungszeit und-datum Berechtigungs (Erfassungs)-Token Erfassungszeit und-datum Transaktionswährung Betrag (in TX-Währung) Käuferwährung Betrag (in Käuferwährung) FX-Kurs Kennzeichen'Ausgleichsdatei empfangen'+ Zeitstempel Kennzeichen'Abstimmung abgeschlossen'+ Zeitstempel Abstimmungsstatus (Akzeptiert/Zurückgewiesen), Fehlerkode Kennzeichen'gesammelt hinsichtlich MA'+ Zeitstempel Kennzeichen'gesammelt hinsichtlich PI'+ Zeitstempel Kennzeichen'gebucht für MA-Abrechnung'+ Zeitstempel Kennzeichen'gebucht für PI-Abrechnung'+ Zeitstempel

Kennzeichen'Bericht an MA'+ Zeitstempel Kennzeichen'Bericht an PI'+ Zeitstempel Transaktionsdaten von den MAs werden zu Gültigkeitsprüfungszwecken mit den zur selben Zeitspanne gehörenden internen CPP-TX-Protokollen verglichen. Da- tensätze, welche nicht übereinstimmen, werden in einer Fehlerdatei gesammelt.

Die Fehlerdatei dient als Basis für Fehlererkennung und die Teile, welcher einer speziellen MA zuzurechnen sind, werden in den Abrechnungsbericht der MA ko- piert. Es sind vier Klassen übereinstimmender Ergebnisse möglich.

TX Übereinstimmung TX Unverträglichkeit : Unverträglichkeit zwischen Daten, welche zu derselben TX in der Abrechnungsdatei und in dem EPP TX-Protokoll gehören.

Überschuss TX : Die Abrechnungsdatei des MA enthält eine Erfassung, welche kein Gegenstück in dem EPP TX-Protokoll hat.

Fehlende TX : Das EPP TX-Protokoll enthält eine Erfassung, welche ein Gegen- stück in der Abrechnungsdatei der MA hat. (Der Protokolldatensatz ist mit"feh- lendes TX"markiert, wenn eine Erfassung zum Ausgleich nicht innerhalb einer bestimmten Zeit, z. B. einer Woche eingegangen ist ;"Abfallsammlung (garbage collection)").

Der Ausgleich mit dem MA-Anbieter erfolgt gemäß dem MA-Ausgleichsablauf. In Einklang gebrachte Transaktionsdatensätze der Vorverarbeitungsprozedur werden hinsichtlich jedes Händlerakquisiteurs gesammelt. Der Sammelprozess führt zu einem MA-Abrechnungsbericht und stellt die Basis für die MA-Abrechnung bereit (Sammeltabelle (aggregation table)).

Erfolgreich in Einklang gebrachte Transaktionen werden hinsichtlich jeder MA und jeder Abrechnungs (Transaktions) währung gesammelt. Die Sammeltabelle spei- chert Beträge, welche über eine bestimmte Abrechnungsperiode gesammelt wur- den. Das Format der Sammeltabelle wird im folgenden gezeigt : MAID Beginn der Abrechnungsperiode (Datum und Zeit) Ende der Abrechnungsperiode (Datum und Zeit)

Tabellenerzeugungszeitstempel Abrechnungswährung Gesamtanzahl von gesammelten Transaktionen Absoluter Abrechnungsbetrag (in TX-Währung) , uPI_ID 1 Anzahl der Transaktionen für uPI 1 Abrechnungsbetrag für uPI 1 uPIID 2 Anzahl der Transaktionen für uPI 2 Abrechnungsbetrag für uPI 2 Kennzeichen'gebucht für MA-Abrechnung'+ Zeitstempel Kennzeichen'berichtet an MA+ Zeitstempel Bei jeder Abrechnungswährung wird eine getrennte Sammeltabelle errechnet. Die Sammeltabelle stellt die Basis für das Buchen (Anleitung der Abrechnung) dar und ein Teil des Abrechnungsberichts wird an das MA gesendet. Der Abrech- nungsbericht enthält Ergebnisse der Abstimmungs-und Sammlungsschritte (ein- schließlich Fehlermeldungen) hinsichtlich eines speziellen Händlerakquisiteurs.

Gemäß dem Berichtsablauf wird der Abrechnungsbericht in dem entsprechenden MA-Verzeichnis gespeichert (voraussichtlich täglich).

Das Ausgleichen mit dem uPI-Anbieter geschieht gemäß dem PI-Ausgleichsablauf.

In Einklang gebrachte Transaktionsdatensätze aus der Vorverarbeitungsprozedur werden hinsichtlich jedes Bezahlungsmittel-Anbieters gesammelt. Der Sammel- prozess führt zu PI-Abrechnungsberichten und stellt die Basis für die PI- Abrechnung (Sammeltabelle) zur Verfügung. In Einklang gebrachte Datensätze werden hinsichtlich jedes PI gesammelt. Die Sammeltabelle speichert Beträge, welche über eine bestimmte Abrechnungsperiode gesammelt wurden.

PPI_ID Beginn der Abrechnungsperiode (Datum und Zeit) Ende der Abrechnungsperiode (Datum und Zeit) Tabellenerzeugungszeitstempel Gesamtanzahl gesammelter Transaktionen

Gesamtabrechnungsbetrag (in TX-Währung) Kennzeichen'gebucht für PI-Abrechnung'+ Zeitstempel Kennzeichen'berichtet an PI'+ Zeitstempel Die Sammeltabelle stellt die Basis für das Buchen (Einleitung der Abrechnung) dar und ein Teil des Abrechnungsberichts wird an den PI-Anbieter gesendet. Der Abrechnungsbericht enthält Ergebnisse der Abstimmungs-und Sammelschritte (einschließlich Fehlermeldungen) hinsichtlich eines Bezahlungsmittel-Anbieters.

Gemäß dem Berichtsablauf wird der Abrechnungsbericht in dem entsprechenden PI-Verzeichnis gespeichert (voraussichtlich täglich). Der CPP-C&S-Dienst löst das G/L-System dahingehend aus, die physischen Finanzmittelübertragungen an den MA und von dem uPI-Anbieter einzuleiten. Das OpCo rechnet Bruttobeträge mit dem PI-Anbieter ab (Autobezahlung). Gebühren werden getrennt abgerechnet.

Die CPP blättert zur PI-Buchung durch die PI-Sammeltabelle und erzeugt eine fla- che Datei (flat file) mit Buchungsdatensätzen (z. B. direkte Debitanfragen) zur Stapeleingabe an ein G/L-System (z. B. SAP FI) und setzt das Kennzeichen für die zugehörigen Protokolldatensätze und die Sammeltabelle. Bei dem MA buchen blättert die CPP durch die MA-Sammeltabelle und erzeugt eine flache Datei mit Buchungsdatensätzen zur Stapeleingabe an ein G/L-System (z. B. SAP FI) und setzt das Kennzeichen für die zugehörigen Protokolldatensätze und die Sammel- tabelle. In dem Fall, indem MA eine Multiwährungsabrechnung wünscht, wird ein getrennter Bezahlungslauf für jede Abrechnungswährung eingeleitet.

Das G/L druckt Rechnungen und Anweisungen und leitet Finanzmittelübertragun- gen ein. Die Finanzmittelübertragung kann einem anderen Ablauf folgen als das Buchen, z. B. abhängig von dem abzurechnenden Wert. Der Abstimmungsschritt kennzeichnet fehlerhafte Transaktionen, welche in einer Fehler-TX-Datei gespei- chert werden. Es wird versucht, Fehler manuell zu berichtigen. Ergebnisse dieses Fehlerberichtigungsschritts (z. B.'berichtigt (corrected)','zurückgewiesen (rejec- ted) ') werden in den entsprechenden MA-Abrechnungsbericht aufgenommen. Ab- gewiesene Datensätze werden mit Fehlerkodes gekennzeichnet.

Um Insidertäuschungen zu erkennen, werden Berichte erzeugt, um die korrekte Verarbeitung von abrechnungsbezogenen Daten zu verfolgen und verdächtiges Verhalten zu erkennen (z. B. das Löschen von Sammeltabellen, manuelle Buchun-

gen, Protokolldateimanipulation). In einem späteren Stadium können intelligente Täuschungserkennungsaigorithmen angewendet werden, um Negativdateien zu aktualisieren, z. B. Benutzerprofilüberprüfungen : Erkennen von ungewöhnlichem Benutzerverhalten, verdächtige Anstiege im Umsatz eines Benutzers, Bezahlungs- ortüberprüfungen : Überprüfen, ob Bezahlungen von weit entfernten Orten inner- halb einer kurzen Zeit ausgingen.

Ein Ablaufmechanismus löst die Vermittlung, die Abstimmung und MA-und luPI- Ausgleich aus. Der Buchungsschritt kann, abhängig von einer Schwelle für einen Minimalabrechnungsbetrag, für jeden MA oder uPI geplant werden. Der Bu- chungsablauf und die Schwelle für den Minimalabrechnungsbetrag sind in dem Hauptdatendatensatz gespeichert. Der Administrator überwacht des korrekte Ab- laufen und löst manuell Verarbeitungsschritte aus, wenn dies notwendig ist.

Alle mobilen Bezahlungstransaktionen werden durch die CPP weitergeleitet, was einen Protokolleintrag in der Protokolldatei zur Folge hat. Diese Protokolldatei stellt die Basis für das Erzeugen von Transaktionsgebührenrechnungen und-be- richten dar. Die resultierenden Rechnungsberichte werden dann in einem Konten- verwaltungssystem gebucht, um die Abrechnung einzuleiten. Verschiedene Ereig- nisse wie z. B. eine OfferID-Anfrage, Berechtigung an der PI oder eine Erfassung werden mit verschiedenen Gebühren belastet. Der Händlerakquisiteur belastet den Händler mit einer mobilen Händlerdienstleistungsgebühr (mobile MSC). Die mobile MSC abzüglich einer MA-Gebühr wird durch die CPP beansprucht und wei- ter unter den Anteilseignern verteilt. Die Figur 25 stellt die Gebührenverteilung dar.

Ein Stapelprozess (z. B. täglich, wöchentlich, monatlich) wird für die Rechnungs- stellung von Transaktionsgebühren durchgeführt, da die Anzahl von Transaktio- nen sehr hoch sein kann, d. h. im Bereich von mehreren Millionen pro Tag. Die Aufgabe der Gebührenverarbeitung kann in die folgenden Schritte aufgespalten werden, wie in Figur 26 dargestellt.

1. Vermittlung 2. Bewertung 3. Rechnungsstellung

4. Berichten (Exportieren von Dateien, welche Rechnungsdetails enthalten) 5. Buchen (Einleiten von Abrechnungen, Ausgabe von Anweisungen/Rechnungs- darstellung) 6. Abweisungs-und Rückgabeprozesse (Fehlerbehandlung) 7. Streitbehandlung 8. Täuschungserkennung 9. Verwaltung Bei jedem Schritt werden Daten in einem besonderen Bestand gehalten und mit in"vollständige (plain)","vermittelt (mediated) ", "bewertet (rated)"oder"ver- rechnet (billed)"bezeichnet. Der Bewertungskatalog enthält Ereignisdefinitionen und Preisgestaltung-/-bewertungsinformationen. Im Berechnungskatalog werden Regeln für spezielle Gebühren (z. B. monatliche Beitragsgebühren) und Abschläge gespeichert. Gespeicherte Prozeduren legen Bearbeitungs-und Rechnungsperio- den fest und lösen die verschiedenen Verarbeitungsschritte aus. Das Rechnungs- detail-Repositorium enthält die verrechneten Ereignisse und stellt die Basis für detaillierte Berichte wie EPA (elektronische Bezahlungsanweisung (electronic payment advice)) dar. Rechnungen werden an das G/L gesendet, um die Abrech- nung einzuleiten (Zahlungslauf).

Ein Vermittlungsmodul verfolgt die Protokolldateien, welche von verschiedenen Protokolldateiquellen empfangen werden. Die Hauptquelle besteht aus den tägli- chen Protokolldateien von dem Weiterleitungsmodul der Prozessorplattform. An- dere Quellen umfassen Daten, welche noch nicht verarbeitet werden konnten, z. B. berichtigte Datensätze aus den abgewiesenen und rückgegebenen Prozessen.

Die Daten werden gefiltert und möglicherweise neu formatiert.

Der Begriff"Bewertung (rating) "bedeutet, jedem Ereignis einen Preis zuzuord- nen. Eine Bewertungstabelle wird zum Festlegen der Preise für jede Ereignisklas- se genutzt. Die Bewertungstabelle wird erzeugt, bevor der Bewertungsprozess gestartet wird und bleibt unverändert während wenigstens einer Rechnungsperi- ode.

Für jeden Rechnungs-oder Anweisungsempfänger kann eine individuelle Bewer- tungstabelle genutzt werden, abhängig von den individuellen Geschäftsvereinba- rungen zwischen OpCo, NewCo, den MAs, PI-Anbietern und den WIs.

Die Gebührenstruktur ist so gestaltet, dass sie allgemein ausreichen, um alle Ge- bühren abzudecken, welche üblicherweise in der Transaktionsrechnungsstellung auftreten. Die Transaktionspreisgestaltung kann von der tatsächlichen Anzahl von Transaktionen und dem durchschnittlichen Wert der Händler-oder Händlerakqui- siteurszahlungstransaktionen abhängen. Ein allgemeiner Ansatz, um solch eine Gebührenstruktur abzudecken, besteht in einer Preistabelle in Matrixform.

Parameter, welche die Preistabelle bestimmen, sind : Ereignistyp (OfferID-Anfrage, Adressprüfung, Erfassung, etc.) Bezahlungskanal (WAP, IVR, SMS) Einkaufskanal (Web, WAP, IVR, TV, Verkaufsautomat, etc.) Bezahlungsinstrument (uPI, Visa, MasterCard, Direktdebit, etc.) Regionalklasse (Kunde und Händler in derselben/in verschiedenen Regionen) : un- ter uns (Interner Operator (intra-operator)), Zuhause (domestic (national)), innerregio- nal (z. B. America, EMEA, ASPA), überregional Risikoklasse des Handels/Händlers Die Abrechnungswährung (eine getrennte Preistabelle für jede Währung kann verwendet werden, wenn ein MA für Multiwährungsabrechnung gewählt wurde).

Ereignisse, welche bewertet werden, umfassen : Statische/dynamische OfferID-Erzeugung (allocateOfferID, initOfferID) Informationsanfragen (adressREQ, agecheckREQ, PIDetailREQ) Bezahlungsberechtigung (AuthorizePaymentRequest) Mikrobezahlungserfassung <BR> <BR> <BR> <BR> Mikrobezahlungserstattung<BR> <BR> <BR> <BR> <BR> <BR> Mikrobezahlungsgutschrift IMPP-Erweiterungsmeldungen (volumenbezogen, z. B. pro Meldung oder pro Kilo- byte)

Andere zentrale Dienste (tbd.) (Bezahlungseinleitung, d. h. PayPurchase Anfrage) (Währungsumrechnung) (WS und PS Suche) (Fehlermeldungen) Der Rechnungsstellungsprozess sammelt alle bewerteten Ereignisse hinsichtlich eines Kontos (empfangbar oder bezahlbar) in einem einzelnen Rechnungsstel- lungsdatensatz. Wiederkehrende Teilnahmegebühren oder spezielle Gebühren werden aufaddiert und Abschläge abgezogen. Spezielle Gebühren und Abschläge können für jeden Anweisungsempfänger variieren. Die bewerteten Ereignisse werden durch Rechnung zusammengestellt (empfangbare Abrechnungen/bezahl- bare Abrechnungen) und die Gebühren werden gesammelt. Ein mehrere Unterge- bühren enthaltendes bewertetes Ereignis ist Teil von mehreren Rechnungen. Ab- schläge oder andere Gebühren (z. B. Teilnahmegebühren) werden zu jeder Rech- nung hinzuaddiert. Die Rechnungen enthalten den zu rechnenden gesammelten Betrag (gutgeschrieben oder eingezogen).

Die Rechnungsdetailberichte enthalten die Datensätze, welche zum Berechnen ei- ner Rechnung für einen besonderen Empfänger verwendet werden. Die Dateien der Rechnungsdetailberichte werden dem Teilnehmer auf Anfrage zugesendet.

Die Rechnungsanweisungen enthalten gesammelte Positionen in einer Rechnung.

Das Formatieren und Ausgeben von Anweisungen unterliegt dem Hauptbuchungs- system.

Das Buchen leitet den Gebühreneinzug und die Verteilung über das Hauptbu- chungssystem ein. Rechnungen werden"gebucht (booked) "gekennzeichnet, so- bald das Buchen eingeleitet wurde. Am Ende des Rechnungsstellungszyklus wer- den alle Rechnungen an das Hauptbuch übertragen (Bezahlungslauf).

Sobald Rechnungsdetails"ausgegeben (delivered)"oder Rechnungen mit"ge- bucht (booked) "gekennzeichnet sind, werden die Daten in einem Massenspeicher archiviert. Archivierte Transaktionsprotokolle und Rechnungsdateien stellen die Basis für das Beilegen von Streitfällen dar. Die CPP stellt eine Zugriffsschnittstel- le zu den protokollierten Transaktionsdetails und Rechnungsdetails für die streit-

verwaltende Behörde zur Verfügung, z. B. ein Kundenbetreuungszentrum. Streit- fälle betreffend Gebühreneinzug und-verteilung (Finanzmittelübertragungen) werden durch nachgelagerte Dienste (back office) verwaltet. Täuschungserken- nungsberichte sollten auch deshalb erzeugt werden, um das korrekte Verarbeiten von rechnungsbezogenen Daten zu verfolgen und verdächtiges Verhalten (z. B. das Löschen von Rechnungsdateien, manuelle Buchungen, Protokolldateimanipu- lationen) aufzufinden.

Die Wertpapierabteilung verwendet ein Hauptbuchungs (G/L)-System, um Bu- chungen zum Gebühreneinzug und-verteilung und Mikrobezahlungsabrechnungen zu verwalten. Der Ausgleichs-und Abrechnungsdienst und die Gebührenrech- nungsmaschine leiten Buchungen am G/L-System ein. Buchungen sind an Emp- fangskunden und Bezahlungskunden des OpCo, NewCo, alle WIs, PI-Anbieter und MAs möglich. Wiederkehrende Buchungen werden für jeden Mikrobezahlungsab- rechnungszyklus und für jede Rechnungsstellungsperiode (täglich, wöchentlich oder monatlich) getätigt. Für jede Buchung (Mikrobuchungsabrechnung oder Ge- bührenrechnungsstellung) wird eine Anweisung gedruckt und jeden Empfänger versendet. Physische Finanzmittelübertragungen an/vom MA, an/vom WI und an NewCo-Bankkonten werden eingeleitet. Die Mikrobezahlungsabrechnung mit MAs sollte nicht erfolgen, bevor die Bezahlung von den uPIs empfangen wurde. Unre- gelmäßigkeiten im Finanzmittelfluss werden verfolgt und berichtet, und Aufrufe werden automatisch erzeugt, wenn Finanzmittelübertragungen verspätet sind.

Der G/L-Operator kann Berichte über Bargeldfluss und ausstehende Bargeldüber- tragungen (für die Bargeldverwaltung) anfragen. Rückübertragungen können im Fall inkorrekter Buchungen z. B. durch inkorrekte Gebührenrechnungen manuell eingeleitet werden.

Alle operationalen Tätigkeiten werden protokolliert (um eine unabhängige Rech- nungsprüfung und Täuschungserkennung möglich zu machen). Informationen über Anteilseigner (Händlerakquisiteure, Geldbörsenausgeber, Bezahlungsmittel- anbieter, NewCo und OpCo) werden zentral in der CPP gespeichert. Verschiedene Komponenten fragen Daten an, um ihre Verarbeitungsaufgaben durchzuführen.

Der Administrator erzeugt und ändert Hauptdateneinträge und ändert den Status der Daten (aktiv/inaktiv).

MA Hauptdaten Name Verbindungsdaten (Adresse, Telefon, E-Mail, etc. ) ID Bezahlungsserveradresse (URL) Interne G/L-Buchungskontonummer Bankkontonummer Rechnungsstellungs-und Abrechnungsabläufe (möglicherweise mehrere) Rechnungswährungen Status (registriert, aktiv, inaktiv, gelöscht) WI Hauptdaten Name Verbindungsdaten (Adresse, Telefon, E-Mail, etc. ) ID Geldbörsenserveradresse (URL) Interne G/L-Buchungskontonummer Bankkontonummer Rechnungsstellungs-und Abrechnungsabläufe Abrechnungswährung Status (registriert, aktiv, inaktiv, gelöscht) PI-Anbieter-Hauptdaten Name Verbindungsdaten (Adresse, Telefon, E-Mail, etc. ) ID Serveradresse (URL) Interne G/L-Buchungskontonummer Bankkontonummer Rechnungsstellungs-und Abrechnungsabläufe Abrechnungswährung Status (registriert, aktiv, inaktiv, gelöscht) NewCo-Hauptdaten Name

Verbindungsdaten (Adresse, Telefon, E-Mail, etc. ) Interne G/L-Buchungskontonummer Bankkontennummer Rechnungsstellungs-und Abrechnungsabläufe (möglicherweise mehrere) Abrechnungswährungen Status (registriert, aktiv, inaktiv, gelöscht) OpCo-Hauptdaten Name Verbindungsdaten (Adresse, Telefon, E-Mail, etc. ) Interne G/L-Buchungskontonummer Bankkontonummer Rechnungsstellungs-und Abrechnungsabläufe (möglicherweise mehrere) Abrechnungswährungen Status (registriert, aktiv, inaktiv, gelöscht) Der Administrationsdienst kapselt die mannigfaltigen Administrationseinrichtun- gen der verschiedenen Komponenten, stellt ein einzelnes Einschreiben (single- sign-on) für den Administrationsnutzer und Protokolle aller Benutzeraktivitäten zur Verfügung. Die folgenden Administrationsaufgaben werden zentral durchge- führt, da sie für alle CPP-Komponenten gültig sind.

Softwareaktualisierungen, Systemneustarts, Hardware-und Netzwerk- Einrichtung Die Festlegung von Rollen und Rechten, Installationen von Benutzern (Administratoren, Operatoren), Zuweisung von Rollen zu Benutzern Der Sicherheitsverwalter (security manager) verfügt exklusiven Zugang zu Sicherheits-und Systemprotokollen, um die Systemoperationen zu überprüfen und Insidertäuschungen zu erkennen Der Hauptdatenadministrator erzeugt und ändert Hauptdateneinträge und ändert den Status der Anteilseigner (z. B. aktiv/inaktiv),

Die Kundenbetreuungsrolle weist diese Zugriffsrechte auf die Hauptda- ten, Transaktionsprotokolle, Rechnungsstellungsdetails und Abwick- lungsberichte zu.

Die Kunden-und Händlergültigkeitsprüfung während des Registrierungsprozesses wird zentral durchgeführt. Für jeden Kunden sendet das WS eine Prüfanfrage an die CPP. Die CPP führt die Gültigkeitsprüfung durch Überprüfen von Informatio- nen wie Name, Adresse, Alter durch. Nach Beendigung wird das Prüfungsergebnis an das WS zusammen mit einem Qualitätskennzeichen gesendet, welches den für die Gültigkeitsprüfung benutzten Dienst anzeigt (dies kann auf Vereinbarungen zwischen CPP und WI/MA basieren).

In Fig. 28 sind schematisch die verschiedenen Schichten eines interoperablen Mobile-Payment-Protokolls IMPP gezeigt, welches zwischen einem Händler-Server (Merchant Server) und einem Kunden-Server (Wallet Server) auf einer Verarbei- tungsplattform (Processing Platform) abläuft. Grundsätzlich hat das Protokoll eine Kern-bzw. Basisschicht (IMPP Core Layer) und eine Erweiterungsschicht (IMPP Extension Layer), wobei zur ersteren der eigentliche Zahlungsverkehrsbereich (Payment range), der Kontext-Identifikator-Bereich (OfferID range) und der Be- nachrichtungsbereich (Notification range) gehören. Die Erweiterungsschicht um- fasst optional Anfragen und Antworten zwischen den Kunden-und Händler-Ser- verinstanzen. Sie ermöglicht auch eine kommunikative Anbindung von dritten Kunden-Servern. Die Kommunikation zwischen Abnehmer und Kunden-Server ei- nerseits sowie Anbieter und Händler-Server andererseits liegt außerhalb dieses Protokolls.

Die Ablaufdiagramme und Verfahrensschritt-Listen der Figuren 29A bis 29C, 30A bis 30C, 31A bis 31C, 34A bis 34C und 36A bis 36C für wesentliche Typen von Transaktionen bzw. Bezahlvorgängen sind selbsterklärend.

Dies gilt auch für die in Fig. 32A und 32B sowie 33A und 33B dargestellten Abläu- fe bei der Erzeugung und der Löschung bzw. Zerstörung einer statischen OfferID.

Hierzu wird insbesondere auch auf die weiter oben gegebene allgemeine Erläute- rung zur Handhabung des Kontext-Identifikators hingewiesen.

Die in Fig. 35A und 35B dargestellten Schritte und Aspekte eines Clearing-Ablau- fes sind davon abhängig, ob ein sogenannter Merchant Acquirer involviert ist o- der nicht. Sie folgen den organisatorischen Geflogenheiten etablierter Clearing- Prozeduren im herkömmlichen Geldverkehr.

Die Figuren 37 bis 40 sind durch ihre Beschriftung im wesentlichen selbsterklä- rend, so dass eine zusätzliche verbale Beschreibung nicht erforderlich ist. Hierbei gelten folgende Abkürzungen : EPP Encorus Processing Platform (Systemverwaltungsserver) FX Foreign Exchange (Währungsumrechnung) MA Merchant Acquirer (ein Dienstanbieter) OpCo Systembetreiber PI Payment Instrument PS Payment Server (bei Transaktionsserver) P2P Person-to-Person SVA Stored value account (Guthabenkonto) Telco Telekommunikationsbetreiber TX Übertragung WI Wallet Issuer (ein Dienstanbieter) WS Wallet Server (ein Transaktionsserver) Obwohl die Erfindung im Umfang verschiedener Ausführungsformen beschrieben wurde, wird der Fachmann erkennen, dass die Erfindung unter Abänderungen, innerhalb des Sinns und Umfangs der Ansprüche, umgesetzt werden kann.