DE112013002111T5

DE112013002111T5 - Managen von sich wiederholenden Zahlungen von mobilen Endstellen

Info

Publication number: DE112013002111T5
Application number: DE112013002111.0T
Authority: DE
Inventors: Jukka c/o Bookit Oy ajanvarauspalvelu Salonen
Original assignee: Bookit Ajanvarauspalvelu Oy
Current assignee: Bookit Oy
Priority date: 2012-04-20
Filing date: 2013-04-18
Publication date: 2014-12-31
Also published as: WO2013156686A1

Abstract

Es werden Geräte und Verfahren offenbart, um eine Dienstebereitstellung in einem System zu erleichtern, das umfasst: einen Zahlungsprozessor (9-200), eine Anzahl von Diensteanbietern (9-400, 9-401–9-40n) und einen Vermittler (10-300), der einen Informationsaustausch zwischen dem Zahlungsprozessor und den Diensteanbietern vermittelt, und eine mobile Endstelle (9-620), die durch einen Zahlungskartenhalter (9-600) betrieben wird. In einigen Implementierungen kann eine Dienstebereitstellung in Fällen erleichtert werden, in denen sich der Zahlungsprozessor (9-200) in einer streng regulierten Payment Card Industry(PCI)-normkonformen Umgebung (9-100) aufhalten muss, und die Diensteanbieter Server betreiben, die nicht PCI-normkonform sind.

Description

STAMMDATEN-INFORMATION
Die vorliegende Anmeldung beansprucht Priorität von zwei in unserem Besitz befindlichen US-Patentanmeldungen, nämlich Serial-No. 13/452,311, eingereicht am 20. April 2012, und US-Patentanmeldung Serial-No. 13/529,737, eingereicht am 21. Juni 2012, beide mit dem Titel ”Managing Recurring Payments from Mobile Terminals”.
GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft Telekommunikationen. Insbesondere betrifft die Erfindung Verfahren und Systeme zur Authentifikation und/oder Verifikation via Telekommunikationen.
HINTERGRUND DER ERFINDUNG
Dienste, die über das Internet gebucht oder genutzt werden, nehmen beständig zu. Das Internet ermöglicht, dass man mehrere Online-Dienste nutzt, wie z. B. Dienste, die mit Banken, Gesundheitsdiensten, Reisebüros, Fahrzeugwartung usw. verbunden sind.
Die zunehmende Popularität von mobilen Computer- und Kommunikationsgeräten führt neue Herausforderungen an Dienste auf dem Internet ein. Mobile Endstellen können Benutzern Information liefern, wenn sie benötigt wird und wo sie benötigt wird. Benutzer wünschen allgegenwärtigen Zugriff auf Information und Anwendungen von dem jeweiligen Gerät. Sie wünschen auch auf diese Information zuzugreifen und sie zu aktualisieren, wo auch immer sie sich gerade befinden.
Es ist jedoch wichtig, zu beachten, dass nicht sämtliche Endstellen mobil sein werden. Zukünftige Dienste müssen mit den verschiedensten Endgeräten kommunizieren können, sowohl mit denen, die mobil sind, als auch mit denen, die es nicht sind. Unterschiedliche Endgeräte haben sehr unterschiedliche Fähigkeiten.
Eine Interoperabilität von verschiedenen Diensten und Endgeräten erfordert Standards auf mehreren Niveaus. Es reicht nicht aus, z. B. gemeinsame Kommunikationsprotokolle zu besitzen. Es würde sehr wichtig sein, gemeinsame Begriffe miteinander zu teilen und Einvernehmen darüber zu haben, was in einem gewissen Kontext ein gewisses Datum bedeutet. Jedoch ist es sehr schwierig gewesen, über diese Punkte Einigkeit zu erzielen, da es eine außerordentlich große Anzahl von Unternehmen, Organisationen und anderen Akteuren in diesem Gebiet gibt.
Viele Dienste müssen Buchungen managen können. Sie umfassen zum Beispiel Buchungstermine für Gesundheitsdienste; Buchen von Reisereservierungen für Hotels, Fluggesellschaften und Leihwagen; Buchen von Tickets für Veranstaltungsorte; Buchen von Terminen zur Fahrzeugwartung; Buchen einer Wohnraumpflege; usw.. Es würde sehr nützlich sein, wenn diese Dienste Information voneinander erhalten könnten. Zum Beispiel könnte, wenn ein Kunde Tickets für ein Konzert bucht, er oder sie wünschen, auch einen Tisch in einem Restaurant zu buchen. Es hilft, wenn der Buchungsdienst des Restaurants eine Basisinformation, wie Datum und Name des Kunden, vom Buchungssystem des Theaters erhält. Unglücklicherweise hat es keine Verfahren gegeben, um Information zwischen unterschiedlichen Arten von Buchungssystemen auszutauschen.
Außerdem hatten solche Dienste sowie andere Dienste/Unternehmen, wie zum Beispiel Banken und Kreditkartenunternehmen, lange Zeit das Problem, zu verifizieren, dass der Benutzer, der versucht eine Reservierung, eine Buchung oder einen Kauf zu tätigen, der tatsächliche Benutzer ist, von dem behauptet wird, dass er es ist. Ähnlich würden Kunden gerne wissen, dass die Information, die sie diesen Diensten/Unternehmen zur Verfügung stellen, zum tatsächlichen Unternehmen gelangt, und dass ihre Information sicher ist. Mit Identitätsbetrug, der aus dem Einreichen von persönlicher Information über das Internet resultiert, was für viele Webbenutzer von Wichtigkeit ist, gibt es einen Bedarf an einer sichereren Authentifikationsalternative als im Augenblick vorhanden ist.
Unternehmen und Organisationen, wie zum Beispiel Softwareentwickler und pharmazeutische Unternehmen haben lange Zeit mit dem Piraterieproblem zu tun gehabt. Nicht nur werden solche Entitäten durch verlorengegangene Verkäufe infolge von gefälschten Waren geschädigt, vielmehr können Verbraucher, die unwissentlich gefälschte Waren kaufen, zum Beispiel durch Malware, die durch gehackte Software installiert ist, oder schlechte Qualität und falsch ausgewiesene gefälschte Arzneimittel geschädigt werden. Im Augenblick versuchen solche Unternehmen Verfahren zu entwickeln, bei denen die Authentizität ihrer Produkte durch ihre Kunden entweder vor einem Kauf oder vor einer Verwendung leicht bestimmt werden kann.
Für Dienste, wie z. B. Buchungs- oder Kalenderfunktionen, findet ein Informationsaustausch häufig als Synchronisieren von Buchungs- oder Kalendereinträgen statt. Zu diesem Zweck laufen im Augenblick mehrere wichtige Standardisierungsbemühungen. Zum Beispiel ist SyncML eine Industrieinitiative, um ein einziges gemeinsames Datensynchronisationsprotokoll zu entwickeln und zu fördern.
vCalendar ist ein Austauschformat zur persönlichen Terminierungsinformation. Es ist auf die verschiedensten Kalender- und Terminierungsprodukte anwendbar und ist beim Austauschen von Information über einen breiten Bereich von Transporttechniken nützlich. Eine Anzahl von Anbietern hat die Spezifikation übernommen, weil sie ermöglicht, dass ihre Produkte Kalender- und Terminierungsinformation austauschen. vCalendar ist eine offene Spezifikation auf Grundlage von Industriestandards, wie z. B. die x/Open- und XAPIA-Kalender- und Terminierungs-API (CSA), der internationale ISO-8601-Datums- und Zeitstandard und die verwandten MIME-eMail-Standards. Das vCalendarformat nutzt Daten, die normalerweise in einer Kalender- und Terminierungsanwendung gespeichert sind, wobei der plattformübergreifende Austausch von Information über Gegenstände, wie z. B. Ereignisse und durchzuführende Handlungen, erleichtert wird. Ein Ereignis ist eine Kalender- und Terminierungsentität, die eine bestimmte Zeitdauer auf einem Kalender darstellt. Eine durchzuführende Handlung ist eine Kalender- und Terminierungsentität, die einen Aktionsgegenstand oder eine Zuweisung darstellt. Zum Beispiel kann sie ein Arbeitsgegenstand sein, der einer Einzelperson zugewiesen ist.
vCard automatisiert den Austausch von persönlicher Information, die man typischerweise auf einer herkömmlichen Geschäftskarte findet. vCard wird bei Anwendungen wie z. B. Internetmail, Voicemail, Web-Browsern, Telefonanwendungen, Call-Centern, Videokonferenzen, PIMs (Personal Information Managers), PDAs (Personal Data Assistants), Rufanlagen, Fax, Bürogeräten und Smartcards verwendet. Zusätzlich zum Text kann vCard-Information Elemente wie Bilder, Firmenlogos, Live-Web-Adressen usw. umfassen.
Ein übliches Problem bei all diesen vorhandenen Lösungen besteht darin, dass sie keine gemeinsame Semantik für unterschiedliche Systeme liefern und dass die Übertragung von Information nicht immer so sicher sein mag, oder zumindest nicht als so sicher von Kunden wahrgenommen wird, wie es viele Kunden wünschen mögen. Ein anderes Problem besteht darin, dass Buchungssysteme mehrere unterschiedliche und normalerweise ziemlich komplexe Benutzeroberflächen aufweisen. Wenn ein Kunde wünscht, sowohl einen Termin bei einem Zahnarzt zu vereinbaren als auch ein Taxi zu buchen, das ihn oder sie dorthin bringt, muss der Kunde die gesamte Buchungsinformation beiden Buchungssystemen auf unterschiedliche Weisen eingeben. Während der Zahnarzt ein sicheres Verfahren zur Vornahme von Reservierungen, zur Authentifikation des Kunden, der die Reservierung vornimmt, und zum Empfang von Zahlung für eine Buchung an Ort und Stelle haben mag, mag das Taxiunternehmen dies nicht haben.
Außerdem wird es z. B. zur Herausforderung, Auftraggeberantworten zu managen, wenn man einem Auftraggeber eine Anzahl von Fragen vorgelegt hat. Zum Beispiel ist es vernünftig, SMS-Textmitteilungen zu verwenden, um einen Auftraggeber zu fragen, welche Option er oder sie wählt, weil es in vielen Ländern, wie in Finnland, sehr üblich ist, mit SMS-Textmitteilungen zu kommunizieren, und sie für Bedienpersonen Einkommen erzeugen. Jedoch kann es, wenn ein Auftraggeber auf mehrere Anfragen durch Senden einer Anzahl von Textmitteilungen antwortet, mühselig sein, herauszufinden, welche Antwort einer gewissen Frage entspricht, weil die Antwort nicht automatisch einen Bezug auf die Frage beinhaltet. Wenn z. B. ein Dienst einen Auftraggeber fragt, ob er oder sie, zusätzlich zu einem Flugticket, wünscht, auch ein Taxi und ein Hotelzimmer zu reservieren und der Auftraggeber ”ja” auf eine Frage aber ”nein” auf die andere antwortet, dann weiß der Dienst nicht notwendigerweise, welches Angebot der Auftraggeber akzeptiert hat.
Andere Probleme, wie zum Beispiel, dass Auftraggeber für Verabredungen nicht erscheinen, einen Dienst nicht mehr als einmal nutzen oder lange Intervalle zwischen Nutzung eines Dienstes, können durch die Verwendung von neuen Systemen und Verfahren angegangen werden.
Demgemäß sind Versuche, um finanzielle Transaktionen, bei denen Auftraggeber mobile Endstellen ohne zusätzliche urheberrechtlich geschützte Software verwenden, durch Beschränkungen von gegenwärtigen Mobilkommunikationsprotokollen benachteiligt, wie zum Beispiel der Kurzmitteilungsdienst (SMS). Bemerkenswerterweise liefert das SMS-Protokoll keine standardisierte Weise, um mobile Benutzer zu authentifizieren oder Sessionen zu managen. Ein Fehlen von standardisierten Authentifikationstechniken lässt Systeme ohne Schutz gegen Betrug, während es ein Fehlen von standardisiertem Sessionsmanagement für Diensteanbieter schwierig macht, um zu verfolgen, welche von den Reaktionen der Auftraggeber welchen Fragen von dem Diensteanbieter entsprechen. Andererseits sollten Sessionsmanagement, Betrugsverhinderung und Einführung von neuen Diensten nicht übermäßig komplex sein.
ZUSAMMENFASSUNG DER ERFINDUNG
Es ist ein Ziel der vorliegenden Erfindung, ein oder mehrere der oben identifizierten Probleme zu verringern. Speziell ist es ein Ziel der vorliegenden Erfindung, Verfahren und Gerät bereitzustellen, die Verbesserungen hinsichtlich eines oder mehreres von Sessionsmanagement, Betrugsverhinderung und reibungslose Einführung von Diensten liefern.
Ausführungsformen der Erfindung können in einem System verwendet werden, das einen oder mehrere Zahlungsprozessorcomputer, einen oder mehrere Diensteanbietercomputer und einen oder mehrere Vermittlerserver umfasst oder unterstützt. Zumindest einer von jedem Computer oder Server koordiniert es, Server an einen Benutzer bereitzustellen, der ein Halter von einer oder mehreren Zahlungskarten ist. Einige Ausführungsformen stehen in Beziehung zu dem Zahlungsprozessorcomputer, andere Ausführungsformen stehen in Beziehung zu dem Vermittlerserver, während noch weitere Ausführungsformen in Beziehung zu den Diensteanbietercomputern stehen. Es sollte angemerkt werden, dass, während der Benutzer ein Halter von einer oder mehreren Zahlungskarten ist, ein Bewirken einer Zahlung nicht immer eine Verwendung oder selbst einen Besitz einer körperlichen Karte erfordert und in einigen Fällen eine bloße Information ausreicht, wie zum Beispiel beim Online-Shopping. Während es für ehrliche Verwendungen bequem ist, eröffnet es Möglichkeiten zum Betrug.
Zum Beispiel kann eine spezielle Ausführungsform als ein Verfahren für einen Zahlungsprozessorcomputer implementiert werden, der konfiguriert ist, um Transaktionen zu managen, die in Beziehung zu einem oder mehreren Diensten stehen, die durch Diensteanbieter bereitgestellt werden, die einen ersten Diensteanbieter und einen zweiten Diensteanbieter umfassen, wobei die Transaktionen durch eine oder mehrere Zahlungskarten zu zahlen sind. Das Verfahren umfasst Ausführen der folgenden Handlungen beim Zahlungsprozessor:

– Verarbeiten einer ersten Anforderung, erste sich wiederholende Zahlungen an den ersten Diensteanbieter zu autorisieren, wobei die sich wiederholenden Zahlungen durch eine erste Zahlungskarte der einen oder mehreren Zahlungskarten zu zahlen sind;
– Empfangen einer zweiten Anforderung, zweite sich wiederholende Zahlungen an den zweiten Diensteanbieter zu autorisieren, wobei die zweiten sich wiederholenden Zahlungen durch eine zweite Zahlungskarte der einen oder mehreren Zahlungskarten zu zahlen sind, und wobei die erste und zweite Zahlungskarte dieselbe Zahlungskarte oder gesonderte Zahlungskarten sein können;
– Verwenden eines ersten Vermittlerservers, um eine Bestätigung von dem Halter der Zahlungskarten zu erhalten, dass der zweite Diensteanbieter Dienste dem Halter der Zahlungskarten vorschlagen kann, ansprechend auf die zweite Anforderung;
– Erzeugen eines Tokens, das den zweiten Diensteanbieter identifiziert, wobei das Token die zweite Zahlungskarte nicht global identifiziert, sondern die zweite Zahlungskarte innerhalb Zahlungskarten identifiziert, die an einen Halter der Zahlungskarten ausgegeben sind;
– Senden des erzeugten Tokens zu einem zweiten Vermittlerserver;
– Empfangen einer Annahmemitteilung von dem ersten oder zweiten Vermittlerserver, die anzeigt, dass der Halter der speziellen Zahlungskarte eine mobile Endstelle über ein Mobilnetz verwendet hat, um die zweiten sich wiederholenden Zahlungen an den zweiten Diensteanbieter zu autorisieren, wobei der erste Vermittlerserver und der zweite Vermittlerserver derselbe Vermittlerserver oder verschiedene Vermittlerserver sein können.

In einem anderen Aspekt kann die Erfindung als ein Zahlungsprozessorcomputer implementiert sein, der konfiguriert ist, um die oben spezifizierten Handlungen auszuführen. Zum Beispiel kann der Zahlungsprozessorcomputer als ein Servercomputer implementiert sein, der konfiguriert ist, um mit dem Vermittlerserver über ein Telekommunikationsnetz zu kommunizieren. Der Zahlungsprozessorcomputer umfasst einen Speicher und eine oder mehrere Verarbeitungseinheiten. Der Speicher speichert Programminstruktionen, deren Ausführung in der einen oder den mehreren Verarbeitungseinheiten eine Ausführung der Handlungen verursacht, die in Verbindung mit dem Verfahren spezifiziert sind. Für großvolumige Implementierungen kann der Zahlungsprozessorcomputer mehrere Verarbeitungseinheiten und eine Lastausgleichseinheit umfassen, um eine Verarbeitungslast unter den mehreren Verarbeitungseinheiten zu verteilen.
Bei einigen Implementierungen erfüllt der Zahlungsprozessorcomputer Spezifikationen, die durch das Payment Card Industry (”PCI”) Security Standards Council ausgegeben sind, während der Vermittlerserver außerhalb der Spezifikationen arbeitet. Diese Implementierung erleichtert eine Einführung von neuen Diensten, weil Transaktionen, die in Beziehung zu den neuen Diensten stehen, durch den Vermittlerserver gemanagt werden können, der die PCI-Spezifikationen nicht erfüllen muss.
Zum Beispiel können der Zahlungsprozessorcomputer und Vermittlerserver eine gemeinsame Authentifikation des Halters der Zahlungskarten bereitstellen. Bei einer Implementierung wird der Halter der Zahlungskarten durch den Zahlungsprozessorcomputer unter Verwendung einer ersten Endstelle und eines ersten Satzes von Authentifikationsinformation authentifiziert. Der Halter der Zahlungskarten zeigt eine zweite Endstelle an, die auch durch den Halter der Zahlungskarten betrieben wird, und der Benutzer der zweiten Endstelle wird unter Verwendung der zweiten Endstelle und eines zweiten Satzes von Authentifikationsinformation authentifiziert. Die erste Anforderung wird von einer ersten Endstelle empfangen und zeigt eine zweite Endstelle an, wobei die erste Endstelle und zweite Endstelle ein gemeinsames körperliches Gerät teilen können oder sich in getrennten körperlichen Geräten aufhalten können, aber die erste Endstelle und zweite Endstelle verwenden unterschiedliche Authentifikationsinformation. In einem veranschaulichenden aber nichtbeschränkenden Beispiel wird die erste Endstelle unter Verwendung von einem oder mehreren authentifiziert von: einer Kombination von Benutzeridentifizierung und Passwort; einem programmierten Mikrochip und einem PIN-Code, während die zweite Endstelle unter Verwendung einer nicht vorhersagbaren Antwortadresse zum Senden einer Mitteilung zur zweiten Endstelle authentifiziert werden kann. Wenn der Benutzer der zweiten Endstelle imstande gewesen ist, auf die Mitteilung zu reagieren, bedeutet dies, dass die zweite Endstelle die Mitteilung von dem Vermittlerserver empfangen hat. Sonst könnte der zweiten Endstelle oder ihrem Benutzer die nichtvorhersagbare Antwortadresse nicht bekannt sein. Angesichts der Tatsache, dass die Mitteilung zur zweiten Endstelle gesendet wird, die in der ersten Anforderung von der ersten Endstelle identifiziert wird, ist jegliche betrügerische Aktion nur möglich, wenn beide Authentifikationsinformationen, die von der ersten Endstelle und der zweiten Endstelle verwendete, gestohlen sind, bevor der Diebstahl detektiert wird und die Zahlungskarten suspendiert werden.
Eine andere spezielle Ausführungsform ist ein Verfahren für einen Vermittlerserver, der konfiguriert ist, um Transaktionen zu managen, die zu einem oder mehreren Diensten in Beziehung stehen, die durch einen oder mehrere Diensteanbieter bereitgestellt werden und durch einen oder mehrere Zahlungskarten zu zahlen sind. Das Verfahren umfasst eine Ausführung der folgenden Handlungen beim Vermittlerserver:

– Empfangen einer Annahmemitteilung, die anzeigt, dass ein Halter einer speziellen von der einen oder den mehreren Zahlungskarten eine mobile Endstelle über ein Mobilnetz betrieben hat, um sich wiederholende Zahlungen an den ersten Diensteanbieter zu autorisieren;
– Senden einer Anforderung an die mobile Endstelle, die durch den Halter der speziellen Zahlungskarte betrieben wird, wobei die Anforderung eine Erlaubnis anfordert, um zweite sich wiederholende Zahlungen an den zweiten Diensteanbieter zu autorisieren, wobei die zweiten sich wiederholenden Zahlungen durch eine zweite Zahlungskarte von der einen oder den mehreren Zahlungskarten zu zahlen sind, wobei eine Assoziation zwischen Diensten des ersten Diensteanbieters und Diensten des zweiten Diensteanbieters vorhanden ist und wobei die erste und zweite Zahlungskarte dieselbe Zahlungskarte oder verschiedene Zahlungskarten sein können;
– Empfangen einer Bestätigung von der mobilen Endstelle, die durch den Halter der Zahlungskarten betrieben wird, dass der zweite Diensteanbieter Dienste an den Halter der Zahlungskarten vorschlagen kann;
– Übertragen der Bestätigung zu einem Zahlungsprozessorcomputer;
– Empfangen eines Tokens von dem Zahlungsprozessorcomputer und Speichern des Tokens, wobei das Token den zweiten Diensteanbieter identifiziert, wobei das Token die zweite Zahlungskarte nicht global identifizieren kann, sondern die zweite Zahlungskarte innerhalb von Zahlungskarten identifiziert, die an einen Halter der Zahlungskarten ausgegeben sind. In einem anderen Aspekt kann die Erfindung als ein Vermittlerserver implementiert werden, der konfiguriert ist, um die Handlungen, die oben spezifiziert sind, auszuführen.

Eine noch andere Ausführungsform kann als ein Verfahren implementiert werden, umfassend eine Ausführung der folgenden Handlungen bei dem Diensteanbietercomputer:

– Empfangen von Information, die anzeigt, dass ein Halter einer speziellen Zahlungskarte sich wiederholende Zahlungen für einen oder mehrere Dienste autorisieren kann, die durch einen Diensteanbieter bereitgestellt werden, der für den Diensteanbietercomputer verantwortlich ist;
– Senden eines Vorschlags für einen Dienst zu einem Vermittlerserver, der sich wiederholende Zahlungen auf sich zieht, die durch die spezielle Zahlungskarte zu zahlen sind;
– Empfangen einer Annahmemitteilung von dem Vermittlerserver, die anzeigt, dass der Halter der speziellen Zahlungskarte eine mobile Endstelle über ein Mobilnetz verwendet hat, um sich wiederholende Zahlungen an den speziellen Diensteanbieter zu autorisieren. In einem anderen Aspekt kann die Erfindung als ein Diensteanbietercomputer implementiert werden, der konfiguriert ist, um die Handlungen, die oben spezifiziert sind, auszuführen.

Weitere Aspekte der Erfindung umfassen einen konkreten Computerprogrammträger, der Computerprogramminstruktionen realisiert, um die verschiedenen Computer und Server zu instruieren, um die oben identifizierten Handlungen auszuführen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Im folgenden Abschnitt werden spezielle Ausführungsformen der Erfindung in Verbindung mit veranschaulichenden aber nichtbeschränkenden Beispielen in größerer Einzelheit beschrieben. Ein Bezug wird zu den folgenden Beispielen vorgenommen:
1 stellt einen Vermittler dar, der zwischen einem Diensteanbieter und einer repräsentativen mobilen Endstelle Dienste vermittelt, wobei der Dienst, der bereitgestellt wird, ein Buchungsdienst ist;
2 stellt eine Version des Vermittlers dar, der imstande ist, mehrere Diensteanbieter zu versorgen;
3 stellt eine detailliertere Ansicht des in 2 dargestellten Systems dar;
die 4 und 5 sind Signalisierungsdiagramme, die typische Gebrauchsfälle in einem wie in den 1 bis 3 dargestellten System wiedergeben;
6 stellt ein Beispiel für eine dynamische Dialogmatrix dar, die auf eine Frage und Antwort angewandt wird;
7 stellt die detaillierten Phasen des Buchungsprozesses dar, was ein Beispiel für einen Dienst ist, der von einem Diensteanbieter angeboten wird;
8 stellt ein veranschaulichendes Beispiel für eine dynamische Dialogmatrix dar;
9A ist ein Blockdiagramm eines Systems, das konfiguriert ist, um Zahlungen von mobilen Endstellen zu autorisieren;
die 9B und 9C sind Signalisierungsdiagramme, die typische Gebrauchsfälle in dem in 9A dargestellten System veranschaulichen;
die 10A bis 10D veranschaulichen weitere Variationen für die Ausführungsformen, die in Verbindung mit den 9A–9C beschrieben sind; und
11 stellt schematisch ein beispielhaftes Blockdiagramm für die verschiedenen informationsverarbeitenden und/oder vermittelnden Server in den früher beschriebenen Systemen dar.
AUSFÜHRLICHE BESCHREIBUNG VON EINIGEN SPEZIELLEN AUSFÜHRUNGSFORMEN
Dieser detaillierte Abschnitt beginnt mit einer Beschreibung von Sessionsmanagement und Authentifikation mit Bezug auf die 1 bis 8. Es ist ersichtlich, dass die Techniken für Sessionsmanagement und Authentifikation, wie in Verbindung mit den 1 bis 8 beschrieben, auf einen weiten Bereich von Diensten anwendbar sind. Zum Beispiel stehen die 9A bis 9C und 10A bis 10D in Beziehung zur Bereitstellung von Diensten in einem System, in dem Zahlungen durch einen Zahlungsprozess verarbeitet werden, der einen strikten Satz von Zertifikationserfordernissen erfüllen muss. 11 steht in Beziehung zu einer beispielhaften Hardwarebeschreibung für die verschiedenen Server und Vermittler.
Die hierin offenbarten Techniken können verwendet werden, um einen weiten Bereich von finanziellen Diensten und Transaktionen bereitzustellen, einschließlich aber nicht beschränkt auf: Buchen eines primären Dienstes; Buchen eines in Beziehung stehenden Dienstes, der zu dem primären Dienst in Beziehung steht; Durchführen einer Zahlung für die primären und/oder in Beziehung stehenden Dienste. Eine veranschaulichende aber nicht erschöpfende Liste von Diensten umfasst Transportation, Unterbringung, Ernährung, Unterhaltung, Dienste, die zur Gesundheit oder zu äußeren Erscheinungen in Beziehung stehen, Konsultation oder andere Dienste. Vom Gesichtspunkt der zu lösenden technischen Probleme, nämlich Sessionsmanagement, Authentifikaktion, Betrugsverhinderung und/oder Mühelosigkeit einer Dienstebereitstellung, braucht keine Unterscheidung zwischen Diensten und körperlichen Objekten gemacht zu werden. Mit anderen Worten, Erwerbung (Kaufen, Verleihen, Leasen) eines Objekts ist ein Beispiel für einen Dienst, der durch einen mobilen Benutzer angefordert ist und durch einen Diensteanbieter angeboten wird.
Die Diensteanbieter sind diejenigen, mit denen Auftraggeber Termine, Reservierungen oder andere Buchungen vereinbaren wollen, und umfassen die Ressourcen, die dazu bestimmt sind, dass das Buchungssystem sie zuweist. Diensteanbieter führen ein Geschäft mittels Diensteanbieter-Buchungsdienste durch. Wie in dieser Anmeldung verwendet, ist der Vermittler ein netzbasierter Dienst, der für die Diensteanbieter-Buchungsdienste über das Netzwerk verfügbar ist, der zusätzliche Semantik, Übersetzungs- und Synchronisations-Dienste bereitstellt, die zur Übermittlung der Information benötigt werden, die für einen Auftraggeber benötigt wird, um eine Transaktion mit einem Diensteanbieter zu vervollständigen. Die Diensteanbieter-Buchungsdienste und der Vermittler sind vorzugsweise Anwendungen, die auf Netzwerkservern laufen, wie z. B. das Internet oder ein privates Intranet. Im Allgemeinen umfasst ein System eine Mehrzahl von Diensteanbietern und Diensteanbieter-Buchungssystemen (die Diensteanbieter-Buchungsdienste implementieren), aber es ist möglich, dass man für nur einen Diensteanbieter ein einfaches Buchungssystem besitzt, in welchem Fall der Vermittler und Diensteanbieter in eine einzige Anwendung engintegriert sein könnten.
Auftraggeber umfassen vorzugsweise Auftraggeber, die auf Mobiltelefonen kommunizieren, die kurze Textmitteilungen empfangen können, wie z. B. Short Message Service(SMS)-Mitteilungen.
Natürlich wird ein System, das SMS-Mitteilungen handhaben kann, auch andere Auftraggeber mit größeren Fähigkeiten handhaben. In einigen Implementierungen kommuniziert der Vermittler mit Mobiltelefonauftraggebern mittels eines SMS-Gateways. Wie wohlbekannt, werden SMS-Gateways durch Mobilnetzwerkbetreiber betrieben. Der Vermittler kommuniziert unter Verwendung von Dialogen mit Auftraggebern. In einigen Implementierungen sind die Dialoge Kurzmitteilungen, die dem Auftraggeber Information darbieten und eine einfache Antwort ermöglichen. Die Dialoge stellen Benutzer vorzugsweise vor einfache Wahlentscheidungen, wie z. B. eine Selektion zwischen ”ja” und ”nein” oder eine einfache Selektion aus einer geordneten Liste. Dialoge können auch Einwegdialoge sein, wie z. B. um eine Reservierung zu quittieren. Eine Transaktion kann typischerweise eine Folge von Dialogen beinhalten, die jeweils eine einfache Antwort einschließen. Dialoge umfassen eine asynchrone Kommunikation durch Mitteilungen. Das wie beschriebene System macht es möglich, Buchungen zwischen unterschiedlichen Diensteanbietersystemen zu koordinieren, um einem Bedarf eines Auftraggebers zu entsprechen, z. B. eine Koordinierung einer Fluggesellschaftsbuchung mit einem Transport zum Flugplatz.
1 ist ein Diagramm eines einfachen Systems, bei dem die Bezugsziffer 100 einen Vermittler bezeichnet, Bezugsziffer 102 ein Buchungssystem eines Diensteanbieters bezeichnet, das in Kommunikationsverbindung mit dem Vermittler 100 über ein Datennetz steht, wie z. B. das Internet. Bezugsziffer 104 bezeichnet eine Benutzerendstelle, die einen Dialog mit dem Vermittler 100 über ein Mobilnetz aufweist. 2 stellt eine Mehrzahl von Diensteanbieter-Buchungssystemen dar, die mit einem Vermittler über ein Netzwerk kommunizieren. 3 stellt einen Vermittler 100 dar, der mit verschiedenen Diensteanbietersystemen und Benutzern mit Telefongeräten kommuniziert, die Dialoge übertragen.
Ein auf Vernunft gegründeter Kundendialog ist vom Standpunkt des Auftraggebers eine wünschenswerte Verbesserung, weil Diensteanbieter ihre eigenen Dialoge in Verbindung mit jedem Buchungsereignis erzeugen können. Ein Dialog steht in enger Beziehung mit einer gewissen Buchungssituation. Ein Dialog kann im richtigen Augenblick automatisch aktiviert werden, oder der Auftraggeber kann den Dialog nach Bedarf aktivieren, oder eine andere Entität im System kann eine Mitteilung zum Dialogprozess des Vermittlers senden, um den Dialog zu aktivieren. Der Dialogprozess kann dann eine Anfrage zu einer anderen Entität im System senden oder informiert den Auftraggeber, und fragt möglicherweise Wahlentscheidungen eines Auftraggebers an. Mit Hilfe dieser Dialogart kann der Auftraggeber in mehreren Buchungssystemen unter Verwendung nur einer Benutzeroberfläche Reservierungen tätigen. Der Dialogprozess stellt eine Verbindung zu entfernten Buchungssystemen über ein geeignetes Datennetz her, wie z. B. durch das Internet oder Mobilnetze.
Ein Vermittlerdienst kann Buchungsinformation zwischen Diensteanbieter-Buchungssystemen übertragen. Z. B. kann, nachdem eine Buchung in ein Fluggesellschafts-Buchungssystem eingegeben ist, ein Taxi-Buchungssystem dem Auftraggeber eine Mitfahrgelegenheit zum Flugplatz anbieten. In dieser Anwendung ist eine Buchung eine Zuweisung einer einzigen Ressource (entweder die Fluggesellschaftsbuchung oder das Taxi in dem vorhergehenden Beispiel), während eine Reservierung die Vereinigung der Buchungen für sämtliche Ressourcen für dasselbe Ereignis ist (die Fluggesellschaftsbuchung plus die Taxibuchung in dem vorhergehenden Beispiel). Der Dialog zwischen dem Auftraggeber, dem Vermittler und den Buchungssystemen sowie gespeicherte Kundenprofile gewährleisten, dass der Auftraggeber den auf Vernunft gegründeten Dienst, den er oder sie benötigt, nicht dagegen aufdringliche Werbung bekommt.
Ein Auftraggeber kann Reservierungen tätigen sowie sie unter Verwendung von vielen Arten von Kommunikationseinrichtungen, einschließlich aber nicht beschränkt auf das Internet, eMail und mobile Endstellen, bestätigen, ändern und stornieren. Der Auftraggeber kann auch einen Kalender, der durch den Vermittler oder einen Diensteanbieter bereitgestellt wird, mit einem Kalender in einem Endgerät synchronisieren, wobei Synchronisationsfunktionen des Vermittlers verwendet werden.
Ein Diensteanbieter kann Auftraggeber daran erinnern, Reservierungen auf einer regelmäßigen Basis vorzunehmen und folglich eine Kundenloyalität erhöhen. Ein Vermittler kann Diensteanbietern helfen, ihre Buchungssysteme zusammen zu bringen, um umfassendere Dienste bereitzustellen, ohne dass ihr Geschäft unnötig ausgeweitet wird. Wegen der Internationalisierung ist der Vermittler imstande, z. B. viele Sprachen, Zeitzonen, Währungen und Datenformate zu unterstützen.
Das System, das mindestens einen Vermittler, einen Dialogprozess, einen Diensteanbieter und ein Diensteanbieter-Buchungssystem umfasst, kann sich auf einem der folgenden Niveaus befinden:

1. Es gibt einen vorbestimmten Satz von Dialogen im System. Ihr Inhalt und die möglichen Wahlentscheidungen werden im voraus festgelegt. Z. B. bietet, wenn ein Auftraggeber einen Flug bucht, ein Dialog immer gewisse andere Buchungen an. Frühere Aktionen des Auftraggebers werden nicht berücksichtigt.
2. Es gibt eine unbegrenzte Anzahl von dynamischen oder ”intelligenten” Dialogen, die z. B. basieren auf: einem Profil, das ein Auftraggeber oder eine Auftraggeberin selbst erzeugt hat, Aufzeichnungen über Benutzungen in der Vergangenheit und dem Ort des Auftraggebers. Eine einfache Logik unterstützt Entscheidungen. Es ist ein Expertensystem von niedrigem Niveau.
3. Das System kann Entscheidungen selbst fällen und kann eine Entscheidungsfindung des Auftraggebers unterstützen. Auf diesem Niveau kann ein Dialogprozess ein Expertensystem von hohem Niveau umfassen. Es kann als ein Agent wirken und mit mehreren Diensteanbietern verhandeln, um das beste Angebot zu bekommen, ohne dass der Auftraggeber direkt einbezogen wird.

In einem beispielhaften Verwendungsfall bucht ein Auftraggeber einen Dienst von einem Diensteanbieter. Die Buchung kann unter Verwendung einer Endstelle durchgeführt werden, die mit dem Vermittlerdienst verbunden ist. Zuerst stellt der Auftraggeber unter Verwendung eines Dialogs eine Verbindung mit dem Vermittlerdienst her. Der Auftraggeber gibt eine Reservierungsanfrage zum Dialogprozess ein, der die Anfrage zum Vermittler sendet. Der Vermittler fragt unter Verwendung von Begriffen und einer Terminologie, die diese Dienste interpretieren können, mögliche Reservierungen vom Informationssystem des Diensteanbieters an. Die Anfrage beruht auf Präferenzen des Auftraggebers. Der Auftraggeber offenbart einige Präferenzen, die in Beziehung zu der spezifischen Buchung stehen, wenn er oder sie die Reservierungsanfrage zum Dialog eingibt. Zusätzlich kann der Dialogprozess und der Vermittlerdienst allgemeine Präferenzen des Auftraggebers gespeichert haben und sie verwenden, so dass der Auftraggeber nicht jedes Mal sämtliche Präferenzen eingeben muss.
Bei einigen Implementierungen kann ein Management der Anfrage und der Buchungen auf komplizierte Zustandsmodelle basiert werden. Jeder Buchungsprozess beinhaltet mehrere Phasen, die durch Zustände beschrieben werden, die seinen Status über seine Lebensdauer verfolgen. Zum Beispiel weist, wenn sich der Vermittler über eine Reservierung von einem Diensteanbieter erkundigt hat, der entsprechende Eintrag in jedem System einen Zustand auf, dass die Buchung unerledigt, aber nicht bestätigt ist. Wenn die Systeme keine gemeinsame Übereinkunft darüber aufweisen, was ein gewisser Zustand bedeutet, übersetzt der Vermittler es ihnen. Ein bevorzugter Buchungsprozess einschließlich der Phasen und Zustände ist in Beispiel 1 beschrieben.
Zusätzlich zur Anfrage von Reservierungen von dem Diensteanbieter kann der Vermittler Buchungen in mehreren Systemen des Diensteanbieters synchronisieren. Die Synchronisation beruht auf Regeln, die in dem Vermittlerdienst spezifiziert sind. Z. B. kann eine Regel sein, dass ”wenn ein Auftraggeber eine Buchung für ein Fluggesellschaftsticket anfragt, dann frage auch Buchungen für Taxis zum Flugplatz an.” Deshalb kann eine Anfrage vom Auftraggeber im Vermittlerdienst vervielfacht werden, was zu einer Anzahl von Anfragen führt. Die Diensteanbieter antworten dem Vermittler, wenn sie imstande sind, einen angeforderten Dienst bereitzustellen, und sie können einige Zusatzinformation hinzufügen, wie über Sitze oder Zeitablauf. Der Vermittler vereinigt gesammelte Information und sendet sie zum Dialogprozess, der dem Auftraggeber eine einfache Liste von Optionen zeigt. Z. B. kann der Dialogprozess drei Optionen für einen Flug aufzeigen und fragen, ob der Auftraggeber auch wünscht, ein Taxi zu reservieren, das tatsächlich bereits vorläufig vom Vermittler gebucht ist. Der Auftraggeber fällt seine oder ihre Entscheidung, indem die Optionen aus der einfachen Liste von Alternativen gewählt werden. Der Dialogprozess sendet Information über die Wahlentscheidung des Auftraggebers zum Vermittler, der die Buchungen in Übereinstimmung mit den Wahlentscheidungen des Auftraggebers bestätigt und die unnötigen Reservierungen storniert.
4 stellt ein Ablaufdiagramm einer Anfrage CINQ1 dar, die von einem Auftraggeber unter Verwendung eines zum Vermittler gesendeten Dialogs DINQ1 erzeugt wurde. Der Vermittler initiiert die Anfrage MINQ1, die CINQ1 und DINQ1 entspricht, zum Buchungssystem 1, einem Diensteanbieter-Buchungssystem. Schließlich kommt eine Antwort DANS1 zum Auftraggeber zurück, wobei eine Wahl angeboten wird, auf die mit einer Selektion CSEL1 reagiert wird, was zu einer Buchung durch den Auftraggeber auf dem Buchungssystem 1 führt. Der Vermittler erkennt den potenziellen Bedarf an einem komplementären Dienst vom Buchungsdienst 2 und initiiert eine Anfrage, MINQ2, zum Buchungssystem 2, die schließlich zu einem Vorschlag führt, der mehrere zum Auftraggeber rückgeführte Wahlentscheidungen, DANS2, einschließt, aus denen eine Selektion, CSEL2, vorgenommen wird, was zu einer komplementären Buchung auf dem Buchungssystem 2 führt.
Die Buchungen können ebenso auf andere Weisen getätigt werden, z. B. indem der Diensteanbieter telefonisch angerufen wird oder indem das Büro des Diensteanbieters vor Ort besucht wird. In diesem Fall kann der Diensteanbieter den Vermittler über Buchungen des Auftraggebers informieren, so dass der Vermittler den Auftraggeber über andere Optionen informieren kann. Zum Beispiel könnte ein Zahnarzt dem Vermittler erzählen, dass der Auftraggeber einen Termin gebucht hat, so dass der Vermittler anbieten kann, auch ein Taxi zu buchen.
Auch ist es möglich, eine Gedächtnisstütze zum Vermittlerdienst hinzuzufügen, so dass der Vermittler zu einer gewissen Zeit anfragt, ob der Auftraggeber eine neue Buchung zu machen wünscht. Zum Beispiel kann der Vermittler eine Anzeige zum Auftraggeber senden, dass es ein Jahr her ist, seit der Auftraggeber zum letzten Mal einen Termin bei seinem oder ihrem Zahnarzt hatte, und fragen, ob der Auftraggeber wünscht, einen neuen Termin zu vereinbaren. Diese Anzeige kann bereits einige Optionen für den Termin enthalten. Der Vermittler hat den Kalender des Auftraggebers überprüft, wenn er oder sie dies ermöglicht hat, so dass die gegebenen Optionen für den Auftraggeber bequem sind. Der Dialog stellt die Optionen auf eine einfache und leicht zu handhabende Weise dar. Der Auftraggeber braucht bloß zu wählen, welche Option für ihn oder sie die beste ist, oder ob er oder sie wünscht, neue Optionen zu bekommen oder die Buchung aufzuschieben. 5 ist ein Zeitfolgediagramm für eine Situation, wo die ursprüngliche Anfrage, MINQ1, durch den Vermittler initiiert wurde.
Beispiel 1 Ein beispielhaftes Buchungssystem
Mit Bezug nun auf 3, wird eine beispielhafte Umgebung, in der die Erfindung zum Management von Buchungen verwendet werden kann, unten beschrieben. Bei der gegenwärtig beschriebenen Implementierung ist der Vermittler 100 so ausgelegt, dass er mit verschiedenen dienstespezifischen Systemen, die allgemein durch die Bezugsziffer 122 bezeichnet sind, eine Schnittstelle bildet. Diese Systeme können verwendet werden, um die früher beschriebenen Dienste (einschließlich körperliche Waren) bereitzustellen. In einer typischen Implementierung bildet der Vermittler 100 eine Schnittstelle mit den dienstespezifischen Systemen 122 über ein Datennetz, wie zum Beispiel das Internet. Der Vermittler 100 bildet weiter eine Schnittstelle mit Auftraggeberendstellen, wie zum Beispiel mobilen Endstellen, die Textmitteilungen über ein Mobilnetz empfangen können. Auf einem logischen Niveau kann eine Schnittstellenbildung des Vermittlers 100 mit den verschiedenen dienstespezifischen Systemen 122 und anderen Parteien mittels generischer XML-Definitionen erreicht werden. Für den beispielhaften Fall eines Managements von Buchungsreservierungen kann der Vermittler 100 vCard- und vCalendar-Standards unterstützen, da sie von vielen größeren Buchungs- und Kalendersystemen verwendet werden.
In der gegenwärtig beschriebenen Implementierung kommuniziert der Vermittler 100 mit den mobilen Endstellen und ihren Benutzern unter Verwendung des Short Message Service (SMS) über ein SMS-Gateway zur asynchronen Kommunikation. Der Vermittler 100 kann einen Kundendialogprozess 124 umfassen, der konfiguriert ist, um die Dynamic Dialog Matrix(DMM)-Technik zu verwenden, die verwendet werden kann, um eine Authentifikation und/oder ein Sessionsmanagement zu erleichtern, wie in größerer Einzelheit in Verbindung mit den 4 bis 8 beschrieben wird.
Eine klare Unterscheidung muss zwischen den Buchungsprozessen der letzten Diensteanbietern und denen des Vermittlers gemacht werden. Der Buchungsprozess der letzten Diensteanbieter deckt bloß normales Buchen hinsichtlich Zeit- und Ressourcenreservierung ab. Die Buchungsprozesse des Vermittlers umfassen Buchen, Arbeit und Finanzierung. Beide Prozesse führen zum selben Punkt. Bei einer typischen Implementierung umfasst der Prozess des Vermittlers sieben Phasen wie folgt:
Phasen (Statushandhabung)
Die Phasen stellen eine Kopplung (analog zu einer Verbindung oder einem Gummiband) zwischen den Ressourcen her. In jeder Phase des Vermittlerprozesses werden die mit dem Buchen in Beziehung stehenden Daten verbessert, um die Erfordernisse der fraglichen Phase widerzuspiegeln. Für die Status und Werte betrachte man bitte die untere Tabelle. Die Phasen werden in der folgenden Erörterung in größerer Einzelheit beschrieben.
1. Anmelden
Anmelden bedeutet Initialisierung eines Vermittlerprozesses und eines Buchungsprozesses. Infolge der Initialisierung wird ein Eintrag in die Datenbank mit grundlegender Information eingefügt. Er erscheint nicht in einem Kalender, da es keine Terminierungsinformation gibt. Er kann in einer separaten Aufgabenliste des Besitzers als eine offene Aufgabe angezeigt werden.
2. Anfordern
In der Anforderungsphase wird eine Buchungsanforderung zu den Ressourcen gesandt, die für die zuvor angemeldete Aufgabe erforderlich sind. Da es kein Terminieren gibt, was in den meisten Fällen wesentlich sein wird, kann diese Phase zusammen mit der Terminierungsphase durchgeführt werden.
3. Terminieren
Dem Besitzer und den Ressourcen wird ein Terminplan gegeben. Als ein Teil und ein Ergebnis des Terminierens werden die folgenden Daten benötigt:

a) vorgeschlagener Anfangszeitpunt (ISO-Zeitstempel-w/Zeitzone)
b) vorgeschlagene Anfangsstelle (Koordinaten)
c) vorgeschlagener Endzeitpunkt (ISO-Zeitstempel-w/Zeitzone)
d) vorgeschlagene Endstelle (Koordinaten)

4. Bestätigen
Zeit und Stelle, wie sie durch die Ressourcen akzeptiert sind, die akzeptiert haben. Daten, die mit dieser Phase in Beziehung stehen:

a) akzeptierter Anfangszeitpunkt (ISO-Zeitstempel-w/Zeitzone)
b) akzeptierte Anfangsstelle (Koordinaten)
c) akzeptierter Endzeitpunkt (ISO-Zeitstempel-w/Zeitzone)
d) akzeptierte Endstelle (Koordinaten)

Standardmäßig werden die Daten aus den Anforderungs- und/oder Terminierungsphasen kopiert. In der Praxis können, wenn die geplante Zeit nicht benötigt wird, dieselben Datenstrukturen dafür verwendet werden, und Status zeigt die aktuelle Bedeutung der Daten an.
5. Bearbeiten
Die Ressourcen führen die gebuchte Aufgabe durch. Mit dieser Phase in Beziehung stehenden Daten bestehen aus unterschiedlichen Merkmalen und ihren Werten, die zu der aktuellen Aufgabe in Beziehung stehen. Zusätzlich werden die folgenden statischen Strukturen benötigt:

a) aktueller Startzeitpunkt (ISO-Zeitstempel-w/Zeitzone)
b) aktuelle Startstelle (Koordinaten)
c) aktueller Endzeitpunkt (ISO-Zeitstempel-w/Zeitzone)
d) aktuelle Endstelle (Koordinaten)
e) Produkte, die verwendet werden, Extras, Kilometerleistung, ... Standardmäßig werden die Daten aus der Bestätigungsphase kopiert.

6. Buchführen
An diesem Punkt werden alle Daten, die in den Datenstrukturen bei vorhergehende Phasen gespeichert wurden, analysiert und für Fakturierungszwecke verarbeitet. Die mit dieser Phase in Beziehung stehenden Daten: Buchführungsdaten. Getrennt zu definieren.
7. Beendigen

Die Aufgabe ist beendigt worden. Vom Standpunkt der Vermittlerprozesse ist es irrelevant, ob der Aufgabe ein Erfolg beschieden war oder nicht. Erfolg oder Misserfolg der Aufgabe ist relevant für die Buchführungsphase, in der die finanziellen Aktionen zum Organizer gehandhabt werden. In dieser Phase wird Systemverwaltung (Datenbankinhalte; temporäre Dateien, usw.) ausgeführt, um den Vermittlerprozess zu beendigen. Die folgende Tabelle zeigt Daten, die in jeder Phase verfügbar sind. Die Buchungsphase ist mit ”XX”.

Anmelden	X					XX
Anfordern	X	X				XX
Terminieren	X	X	X			XX
Bestätigen	X	X	X	X		xx
Bearbeiten	x	x	X	X	X	XX
Buchführen	X	X	X	X	X	X
Beendigen	X	X	X	X	X	X	X
Phase/Daten	Identifizieren	Ressourcen	Vorgeschlagene Zeit	Akzeptierte Zeit	Aufgaben-bearbeitung berichtet	Buchführen	Schließen

Phasenstatus, Werte und Übergänge

Die folgende Tabelle beschreibt die Phasen, ihre Status und Werte zusammen mit einem Übergang zur nächsten logischen Phase auf Grundlage der erhaltenen Werte. Zusätzlich sind entsprechende vCalendarstatus dargestellt, wenn zutreffend.

Phase	Status	Nächste Phase	vEvent	vTodo
Anmelden		Anfordern
Anfordern		Terminieren	Gesendet	Gesendet
Terminieren	Unerledigt	Bestätigen	Benötigt Aktion	Benötigt Aktion
Terminieren	Terminiert	Bestätigen	Benötigt Aktion	Benötigt Aktion
Terminieren	Neuterminiert	Bestätigen	Benötigt Aktion	Benötigt Aktion
Bestätigen	Akzeptiert	Bearbeiten	Bestätigt	Akzeptiert
Bestätigen	Abgelehnt	Buchführen	Abgelehnt	Abgelehnt
Bestätigen	Vorläufig	Buchführen	Vorläufig
Bestätigen	Delegiert	Anfordern	Delegiert	Delegiert
Bestätigen	Neuterminieren angefordert	Buchführen oder Terminieren
Bestätigen	Im Gange	Bearbeiten
Bearbeiten	im Gange	Bearbeiten
Bearbeiten	Verzögert	Bearbeiten
Bearbeiten	Gestartet	Bearbeiten
Bearbeiten	n% fertig	Bearbeiten
Bearbeiten	Bereit	Buchführen
Buchführen		Beendigen
Beendigen	<Kopiert von Phase vor Buchführen>	n/a

Angehaltene, neugestartete und stornierte interne Phasen wirken für alle relevanten Phasen an einem beliebigen Punkt wie folgt:

<Phase y> Angehalten <Status x>

<Phase y> Neugestartet <Status x>

<Phase y> Stomiert Buchführung
7 stellt die Arbeitsflussübergänge von Phase zu Phase dar. Für Bedingungen, siehe die obige Tabelle. Auch beachte man bitte, dass ein Storniert-Status immer zur Buchführung führt.
Bestätigen der (ganzen) Reservierung
Damit die ganze Reservierung erfolgreich ist, müssen alle Ressourcen, die die Reservierung akzeptierten, dieselbe Terminierung aufweisen. Zusätzlich gibt es Ressourcen in unterschiedlichen Funktionen, und mit der Bearbeitungsphase in Beziehung stehende Daten können stark variieren. Die unterschiedlichen Status der ganzen Reservierung sind:

a) ”Keine Antworten” (0) für ”Niemand hat auf die Anforderung, die vom Organizer gemacht wurde, geantwortet”
b) ”Keine Ablehnungen” (1) für ”Nicht alle Eingeladenen haben schon geantwortet. Diejenigen, die geantwortet haben, haben akzeptiert”
c) ”Alles Akzeptierungen” (2) für ”Alle Eingeladenen haben bestätigt”
d) ”Einige Ablehnungen” (3) für ”Einige der Eingeladenen haben abgelehnt”
e) ”Alles Ablehnungen” (4) für ”Sämtliche Eingeladenen haben abgelehnt”.

Die folgende Entscheidungstabelle hilft beim Auswerten des Status der ganzen Buchung. ”Vielleicht” bedeutet, dass diese Bedingung allein ein wahres oder falsches Ergebnis nicht unstreitig spezifiziert.

Buchungsstatus/Bestätigungen	Niemand antwortete	Niemand akzeptierte	Einige akzeptierten	Alle akzeptierten	Niemand lehnte ab	Einige lehnten ab	Alle lehnten ab
Keine Antworten	Wahr	Vielleicht			Vielleicht
Keine Ablehnungen	Wahr	Vielleicht	Vielleicht	Wahr	Wahr
Keine Akzeptierungen	Wahr	Wahr			Vielleicht	Vielleicht	Wahr
Alles Akzeptierungen			Wahr	Wahr	Vielleicht
Einige Akzeptierungen			Wahr	Vielleicht	Vielleicht	Vielleicht
Alles Ablehnungen		Vielleicht					Wahr
Einige Ablehnungen		Vielleicht	Vielleicht			Wahr	Vielleicht

Auf Grundlage der Information und Entscheidungstabelle oben muss der Organizer/die Anwendung die Entscheidung darüber fällen, was mit der Reservierung zu machen ist. Dies kann eine automatische Entscheidung sein, die durch das System auf Grundlage von voreingestellten Regeln gefällt wird oder durch den Organizer von Hand vorgenommen wird.
6 stellt ein Beispiel für die dynamische Dialogmatrix dar, die auf eine Frage und Antwort angewandt wird. Eine Anwendung sendet eine Diensteanforderung zu einem Benutzer an einen Vermittler B. Der Vermittler B nimmt eine Zufalls-B-Adresse aus einer Gruppe von verfügbaren B-Adressen auf, wobei er Reaktionen von dem Benutzer empfangen kann. Nach Definieren der B-Adresse sendet der Vermittler B eine Frage zum Benutzer A, wobei die Frage aus einer Liste von Wahlen bestehen kann, aus der der Benutzer A die Antwort auswählen kann. Der Benutzer A empfängt die Frage in seiner Endstelle und sendet eine Antwort auf diese Frage an die B-Adresse. Der Vermittler B empfängt die Antwort des Benutzers in der B-Adresse. Nach Empfangen der Antwort von dem Benutzer A verarbeitet der Vermittler B die Antwort. Zuerst validiert der Vermittler B die A-Adresse (die die Adresse des Benutzers ist). Im Fall, dass die A-Adresse nicht der A-Adresse entspricht, an die die Mitteilung gesendet wurde, kann der Vermittler B die Anwendung informieren, dass keine Antwort empfangen wurde. Im Fall, dass die A-Adresse der A-Adresse entspricht, an die der Vermittler B eine Frage gesendet hat, verifiziert der Vermittler B die B-Adresse (die Antwortadresse, bei der die Antwort empfangen wurde). Entsprechend, im Fall, dass die B-Adresse keine gültige B-Adresse für den Benutzer ist, kann der Vermittler B die Anwendung informieren, dass keine Reaktion empfangen wurde. Im Fall, dass auch die B-Adresse der B-Adresse entspricht, von der die Mitteilung gesendet wurde, bringt der Vermittler B die Antwort C mit der Liste von verfügbaren Wahlen für diese Mitteilung in Übereinstimmung. Wenn die Antwort der verfügbaren Liste von Wahlen nicht entspricht, kann der Vermittler B eine Fehlerinformationen zur Anwendung senden oder eine neue Frage an den Benutzer A senden. Wenn die Antwort der verfügbaren Liste von Wahlen entspricht, die zum Benutzer gesendet wurde, sendet der Vermittler B eine Rückdienstereaktion an die Anwendung.
Das wie in Verbindung mit 6 beschriebene System kann eine Mehrzahl von B-Teilnehmeradressen, wie zum Beispiel Telefonnummern, aufweisen, aus denen der Vermittler B eine Teilnehmernummer wählen kann, an die die Mitteilung an den Benutzer A gesendet wird. Weiter weist der Benutzer A vorzugsweise ein Mobiltelefon auf, das eine Mobilteilnehmernummer aufweist, an die die Mitteilung gesendet wird, und von der der Benutzer A auf die Frage reagieren kann. Die Mitteilungen zu und von dem Vermittler B werden über das Telekommunikationsnetz gesendet.
Ein Hauptproblem, das durch die dynamische Dialogmatrix gelöst wird, ist die Herausforderung, Auftraggeberantworten zu managen, wenn einem Auftraggeber eine Anzahl von Fragen aufgegeben worden ist und der Auftraggeber SMS-Textmitteilungen oder eine ähnliche Technologie verwendet, wobei eine Antwort nicht automatisch einen expliziten Bezug auf die Anfrage einschließt. Eine Anfrage schließt immer eine gewisse Art von Adresse oder Identifizierung des Empfängers ein. Im Fall der SMS-Textmitteilung ist dies die sogenannte B-Teilnehmernummer. Andererseits wird die A-Teilnehmernummer des Senders oder Calling Line Identity (CLI) oder eine ähnliche Identifizierung ebenfalls an jede Textmitteilung angehängt. Deshalb kann der Auftraggeber oder B-Teilnehmer normalerweise leicht auf eine Mitteilung unter Verwendung der Antwort- oder Erwiderungs-Funktion des Mobilgeräts antworten. Wenn ein Vermittlerdienst, der Anfragen zu einem Auftraggeber sendet, unterschiedliche A-Teilnehmernummern bei unterschiedlichen Anfragen verwendet, ist es möglich, zwischen Antworten zu unterscheiden, was darauf beruht, zu welcher Nummer der Auftraggeber Antworten sendet. Wenn z. B. ein Vermittler einem Auftraggeber eine Anfrage ”Benötigen sie auch ein Taxi?”, wobei eine A-Teilnehmernummer A1 verwendet wird, und dann Anfragen ”Benötigen Sie ein Hotelzimmer?” von der A-Teilnehmernummer A2 sendet, geht beispielsweise die Antwort des Auftraggebers auf die erste Frage an Nummer A1, und die zweite Antwort geht an Nummer A2. Unter Verwendung einer Dialogmatrix verfolgt ein Vermittler Anfragen und Antworten. In der Matrix gibt es eine Spalte für jeden Auftraggeber und eine Reihe für jede A-Teilnehmernummer, die der Vermittler verwendet. Augenscheinlich könnte es eine Reihe für jeden Auftraggeber geben und entsprechend ebenso eine Spalte für jede A-Teilnehmernummer. Nach Senden einer Anfrage von einer gewissen A-Teilnehmernummer zu einem Auftraggeber wird der Status und die Antwort in der entsprechenden Zelle der Matrix gespeichert. Infolgedessen kann der Vermittler herausfinden, ob der Auftraggeber auf eine gewisse Anfrage geantwortet hat und was die Antwort war. Auch ist es möglich, die Matrix zu verwenden, um Information über das Verhalten des Auftraggebers zu sammeln und sie zum Beispiel für Marketingzwecke zu verwenden. Ein Vermittler benötigt nur eine beschränkte Anzahl von A-Teilnehmernummern. Eine Dialogmatrix kann auch verwendet werden, um herauszufinden, welche A-Teilnehmernnummern verwendet werden können, wenn die nächste Anfrage zu einem gewissen Auftraggeber gesendet wird.
Die Verwendung der dynamischen Dialogmatrix wie oben beschrieben ist in 7 veranschaulicht. Die dynamische Dialogmatrix ist auch ein starke, aber sehr einfache Sicherheitsmaßnahme zur Authentifikation eines Mobiltelefonbenutzers, der nur die Fähigkeit aufweist, Mitteilungen zu senden und zu empfangen. Es besteht für einen Dienst das Problem, die Identität eines Senders zu bestätigen. Ein Weg zu versuchen, den Benutzer zu identifizieren, besteht darin, die Adresse des Senders zu überprüfen. Normalerweise weisen SMS, eMail und andere ähnliche Mitteilungen die Adresse des Senders angehängt auf. Diese Adresse kann zum Beispiel die A-Teilnehmernummer des Senders oder die Calling Line Identity (CLI) oder die eMail-Adresse oder IP-Adresse sein. Jedoch ist es ziemlich leicht, eine Senderadresse zu fälschen. Aus der Sicht des Diensteanbieters ist die Abwärtsstrecke von einem Diensteanbieter zu einem Benutzer normalerweise verhältnismäßig zuverlässig, und es ist für andere schwierig, Mitteilungen abzufangen oder zu ändern, aber die Aufwärtsstrecke von einem Benutzer zu einem Diensteanbieter ist viel anfälliger, und es ist nicht allzu schwierig, eine falsche Senderadresse zu geben. Eine wohlbekannte Lösung für das obige Problem besteht darin, Verschlüsselungstechnologien zu verwenden, um die Kommunikationen zu sichern, wobei Public-Key-Infrastrukturen (PKI) gute Beispiele sind. Z. B. kann ein Benutzergerät mit einem Mikrochip, beispielsweise einer sicheren SIM-Karte in GSM-Geräten, ausgerüstet sein, um Mitteilungen unter Verwendung des privaten Schlüssels des Benutzers zu verschlüsseln. Der Diensteanbieter kann dann sicher sein, dass die Mitteilung vom Benutzer stammt, wenn sie unter Verwendung des öffentlichen Schlüssels des Benutzers entschlüsselt werden kann. Jedoch erfordert diese Lösung spezielle Geräte, die bisher nicht sehr üblich, kostengünstig oder standardisiert sind. Wenn man auf eine solche Lösung angewiesen ist, wird die Anzahl von möglichen Benutzern signifikant beschränkt.
Eine Verwendung der DDM liefert eine neue Lösung. Wenn der Dienst eine Anforderung zum Mobiltelefonbenutzer sendet, enthält jede Anforderung eine unterschiedliche, vorzugsweise zufällig gewählte Antwortnummer. Folglich ist eine zulässige Antwort nur diejenige, die zu der richtigen Antwortadresse gesendet wird.
Ein Beispiel ist für eine Authentifikation eines Benutzers, der einen Kauf tätigt, z. B. ein Softwareprodukt ”ABC” kauft. Der Benutzer initiiert zuerst eine Kaufanforderung zum Unternehmen/Dienst, z. B. direkt im Softwareprogramm über eine Internet-Webseite oder über ein mobiles Gerät. Das Unternehmen/der Dienst kennt dann den Benutzernamen und mögliche andere Identifizierungsinformation und sendet eine Anfrage zu einem Kreditkartenunternehmen, um eine Zahlung anzufordern. Das Kreditkartenunternehmen sendet dann eine Anforderung zu einem Vermittler, um den Kauf zu authentifizieren. Der Vermittler kennt den Benutzer und die Mobilnummer des Benutzers und sendet eine Mitteilung, z. B. SMS oder MMS, zur bekannten Telefonnummer des Benutzers. Ein Beispiel einer Mitteilung könnte sein:
”Lieber Herr Auftraggeber, ihre Kreditkarte wurde verwendet, um das Produkt ABC am 27. März 2010 für 299 EUR zu kaufen. Bitte antworten sie:
j – um die Zahlung auf VISA xxxx xxxx xxxx 123 zu akzeptieren
n – um die Zahlung zurückzuweisen oder
f – um einen Betrug auf ihrer Kreditkarte zu berichten”.
Indem auf die Mitteilung von der bekannten Mobilnummer des Benutzers mit einer akzeptablen Reaktion reagiert wird, wird zugelassen, dass der Vermittler zum Kreditkartenunternehmen reagiert, wenn der Benutzer den Kauf autorisiert oder es nicht tut. Danach kann das Kreditkartenunternehmen die Zahlung autorisieren und das Unternehmen/den Dienst informieren. Zusätzlich gibt es, wenn der Vermittler die Mitteilung von einer zufällig gewählten Antwortnummer sendet, wie oben erörtert, eine zusätzliche Schicht einer Authentifikation. Weil es für einen betrügerischen Benutzer möglich ist, eine Mobilnummer eines Kreditkartenhalters zu bestimmen und eine Mitteilung von der Nummer vorzutäuschen, würde es außerordentlich unwahrscheinlich für sie sein, zu wissen, von welcher Antwortnummer die Authentifikationsmitteilung stammen würde. Das obige kann auch z. B. bei Geldüberweisungen zwischen einer Bank eines Benutzers und dem Unternehmen/Dienst verwendet werden.
Ein zusätzliches Element von Sicherheit kann unter Verwendung einer semantischen Analyse erzielt werden. Z. B. wusste, wenn der Benutzer gebeten wird, zu sagen, wieviel Gegenstände geordert sind, und die Antwort ”j” oder ”ja” ist, der Benutzer augenscheinlich nicht, was die Frage war und die Mitteilung war keine Antwort für die Anfrage.
Ein solches System kann auch ein Sicherheitsniveau für den Benutzer bereitstellen. Der Vermittler kann das Unternehmen/den Dienst durch ein beliebiges akzeptables Verfahren authentifizieren und nur Authentifikationsmitteilungen senden, sobald das Unternehmen/der Dienst authentifiziert worden ist. Dann werden sie, wenn der Benutzer ihre Mobilnummer nicht bereitstellt, wenn sie ihre Identifikationsinformation bereitstellen, wenn sie eine Authentifikationsmitteilung bekommen, selbst von einer Nummer, die sie nicht erkennen, wissen, dass der Vermittler das Unternehmen/den Dienst authentifiziert hat.
Während das gegenwärtige Beispiel hinsichtlich des Vermittlers erklärt worden ist, der eine Mitteilung sendet, könnte die Mitteilung durch eine sekundäre Entität auf die Anforderung des Vermittlers gesendet werden. Z. B. kann der Vermittler, wenn der Vermittler eine Anforderung empfängt, um eine Transaktion zu authentifizieren, der Vermittler dann die Bank des Benutzers mit den notwendigen Transaktionsdetails versehen und anfordern, dass die Bank das notwendige Authentifikationsverfahren sendet. Ein anderes Beispiel würde sein, wenn der Vermittler eine Anforderung zur Bank für gewisse Identifizierungsinformation des Benutzers, zum Beispiel die Mobilnummer, sendet, so dass sie mit Senden der tatsächlichen Anfrage selbst oder durch einen tertiären Diensteanbieter weitermachen kann, der das Senden der aktuellen Mitteilung handhabt.
Außerdem kann, obwohl die vorliegende Erfindung beschrieben worden ist, wobei die Transaktion der Kauf eines Produkts und die Authentifikation des Benutzers für eine Zahlung ist, dasselbe System und ein ähnliches Verfahren für andere Transaktionen verwendet werden, wie zum Beispiel die Authentifikation des gekauften Produkts.
Die Verwendung einer dynamischen Dialogmatrix (DDM) ermöglicht eine Authentifikation und Verifikation von Produkten, Diensten und Transaktionen auf Grundlage einer Mehrzahl von Kombinationen von Daten. Auf Grundlage von so wenig wie zwei Informationen von der DDM kann eine Entität verifiziert werden.
Auf Grundlage von mehreren Informationen von der DDM kann ein höherer Grad an Verifikation erzielt werden.
Eine DDM, die für Verifikationszwecke verwendet wird, kann enthalten oder Zugriff haben auf mehreres von einigem oder allem von dem Folgenden: Antwortadressen, die zum Senden von Mitteilungen verwendet werden, Antwortadressen, für welche Mitteilungen empfangen werden, Benutzeradressen, Fragen, akzeptable Antworten auf Fragen, Reihenfolge eines Empfangens von Antworten und Verifikationsinformation (z. B. Produktschlüssel, ID-Codes). Der springende Punkt der DDM besteht darin, dass sie eine Verifikation zwischen einem Unternehmen/Dienst und einem Benutzer durch einen Vermittler (und möglicherweise durch eine andere Partei) durch Anpassen von Information, die jede Entität kennt und die die anderen nicht kennen sollten, ermöglicht. Einige Beispiele sind wie folgt:
Wenn ein Benutzer eine Softwareeinheit aus dem Internet herunterlädt, möchten sie gerne wissen, dass die Software legitim ist, das heißt nicht raubkopiert oder gehackt, während Softwareentwickler gerne sichergehen wollen, dass Benutzer zahlen, um ihre Programme zu aktivieren. Deshalb wird vor einer Verwendung der Benutzer aufgefordert, einen Produktschlüssel einzugeben. Der Benutzer sendet eine Mitteilung, z. B. ein SMS, zu einer Nummer mit einem Produkt-ID-Code. Wenn der ID-Code gültig ist und nicht kürzlich registriert worden ist, dann erhält der Benutzer eine Mitteilung mit dem Produktschlüssel. Deshalb passt die DDM den benutzereingegebenen Produkt-ID-Code an einen Indikator an, wenn er registriert worden ist, um zu verifizieren, ob ein Produktschlüssel ausgegeben werden sollte. Ein ähnlicher Prozess könnte in Verbindung mit dem Zahlungsprozess, der oben beschrieben ist, arbeiten. Sobald der Kauf der Software authentifiziert ist, wie oben beschrieben, dann kann eine zusätzliche Mitteilung mit dem geeigneten Produktschlüssel gesendet werden. Ein ähnliches Verfahren und System kann verwendet werden, um die Legitimität von praktisch jeglichem Produkt wie zum Beispiel Arznei- oder Markenprodukten, zu verifizieren. Wenn das Produkt einen Code, der auf die Verpackung gedruckt ist, und eine bekannte Nummer aufweist, die in Verbindung mit dem Produkthersteller oder der Verifikation steht, dann kann ein Verbraucher eine Mitteilung zu der bekannten Nummer mit dem Produktcode senden, um eine Anzeige zu empfangen, ob der Code gültig ist und ob er zuvor überprüft worden ist. Vorteile für dieses System sind, dass, wenn Raubprodukte keinen Code aufweisen, der auf dem Produkt gedruckt ist, oder einen ungültigen Code aufweisen, dann weiß der Benutzer es sofort. Zusätzlich kann, wenn mehrere Benutzer denselben Code überprüfen, dann der Produkthersteller oder der Verifizierer überprüfen, ob der Code durch eine Herstellung eines Raubprodukts reproduziert worden ist. Ein weiterer Vorteil für das System besteht darin, dass der Produkthersteller unmittelbar eine Anfrage zurück zum Benutzer senden kann, wenn bestimmt worden ist, dass das Produkt ein Raubprodukt ist oder als Raubprodukt verdächtigt ist. Eine Anfrage kann darin bestehen, zu fragen, wo/wann das Produkt gekauft wurde, was der Kaufpreis war und/oder andere Information, die verwendet werden kann, um die Entität zu identifizieren, die für die Piraterie oder Verteilung von Raubwaren verantwortlich ist.
Der Prozess kann auch so sein, dass der Benutzer einen Code zu der bekannten Nummer sendet, um eine Information zu empfangen, wenn das Produkt authentisch oder ein Raubprodukt ist. Danach fragt der Hersteller einen weiteren Code oder eine ähnliche Information vom Benutzer an. Wenn zwei Informationen verwendet werden (und möglicherweise eine andere Senderidentität, als diejenige, zu der der Benutzer die erste Mitteilung sandte), um das Produkt zu authentifizieren, wird das Sicherheitsniveau erhöht.
Die 9A bis 9C veranschaulichen, wie eine Ausführungsform der Erfindung verwendet werden kann, um sich wiederholende mobile Zahlungen zu autorisieren. Speziell ist 9A ein Blockdiagramm einer Ausführungsform der Erfindung, die verwendet werden kann, um mobile Zahlungen zu autorisieren, während die 9B und 9C Signalisierungsdiagramme sind, die Ereignisabläufe in dem in 9A dargestellten System veranschaulichen.
Wie hierin verwendet, bezieht sich eine mobile Zahlung auf eine Zahlungstransaktion, die über ein Mobilnetz bewirkt wird.
Einige der in 9A dargestellten Elemente sind in einer PCI-normkonformen Umgebung 9-100 dargestellt, wobei ”PCI” für Payment Card Industry steht. Normgerechtigkeits-Spezifikationen für die PCI-normkonforme Umgebung 9-100 sind durch das PCI Security Standards Council gegenwärtig auf der Adresse www.pcisecuritystandards.org veröffentlicht.
Die Elemente in der PCI-normkonformen Umgebung 9-100 umfassen einen Zahlungsprozessor 9-200, seine zugehörige Datenbank 9-202 und mindestens einen Großhändler 9-250 als eine legale Entität. Die Datenbank 9-202 speichert allgemeine Rechnungs- und Adressinformation 9-210 über die Benutzer und Großhändler. Während man der Meinung ist, dass eine Speicherung von solcher Information eine gute Systemverwaltung zur Rechnungsprüfung oder dergleichen ist, ist sie genau genommen für die vorliegende Erfindung nicht wesentlich. Einige der Großhändler 9-250 betreiben jeweilige Onlineläden oder Diensteanbieter 9-400, 9-401 bis 9-40n außerhalb der PCI-normkonformen Umgebung 9-100. Wenn ein repräsentativer Diensteanbieter erörtert wird, wird im Allgemeinen die Bezugsziffer 9-400 verwendet, während die Bezugsziffern 9-401 bis 9-40n verwendet werden können, wenn auf individuelle Diensteanbieter Bezug genommen werden muss.
Andere Elemente außerhalb der PCI-normkonformen Umgebung 9-100 umfassen einen Vermittler 9-300 und eine Anzahl von Benutzern, von denen ein repräsentativer durch die Bezugsnummer 9-600 bezeichnet ist. Der Vermittler 9-300 ist eine Version der Vermittler 100, die früher beschrieben sind, wobei die vorliegende Version angepasst ist, um zwischen Entitäten sowohl innerhalb als auch außerhalb der PCI-normkonformen Umgebung 9-100 zu vermitteln.
In der vorliegenden Erfindung weist der Benutzer 9-600 mehrere Funktionen auf. Zuerst ist der Benutzer ein Kunde des Prozessors 9-200 und demgemäß ein Halter von einer oder mehreren Zahlungskarten, von denen eine durch die Bezugsziffer 9-610 bezeichnet ist. Während die Bezugsziffer 9-610 die Zahlungskarte bezeichnet, bezeichnet die Bezugsziffer 9-612 die Information auf der Zahlungskarte 9-610, die ausreicht, um die Zahlungskarte global zu identifizieren. Mit anderen Worten ermöglicht eine Kenntnis der kompletten Information 9-612 jeden, der diese Kenntnis besitzt, Zahlungen vorzunehmen (ehrliche oder betrügerische), mit denen der Halter der Zahlungskarte 9-610 belastbar sein kann. Der Benutzer 9-600 ist auch ein Teilnehmer eines Mobilteilnehmernetzes 9-500 und ein Benutzer von mindestens einer mobilen Endstelle 9-620.
Wenn das System gemäß 9 in Gebrauch gesetzt wird, sind die folgenden Annahmen und Bedingungen in Kraft.

1. Es gibt eine anfängliche Vertrauensbeziehung zwischen dem Zahlungsprozessor 9-200 und Vermittler 9-300. Zum Beispiel kann die Vertrauensbeziehung durch legale Kontrakte hergestellt sein, die zwischen den Bedienpersonen (als legalen Entitäten) des Prozessors 9-200 und Vermittlers 9-300 unterzeichnet sind, und die legalen Entitäten instruieren den Prozessor 9-200 und Vermittler 9-300 (als Netzwerkknoten) einander zu vertrauen. Wie hierin verwendet, kann eine ”anfängliche Vertrauensbeziehung” z. B. bedeuten, dass der Prozessor 9-200 den Vermittler 9-300 autorisierte, Transaktionen innerhalb eines Satzes von anfänglichen Grenzen zu verarbeiten. Während eines Betriebs des Systems können die Grenzen erhöht werden.
2. Es gibt eine anfängliche Vertrauensbeziehung zwischen jedem Diensteanbieter 9-401–9-40n und dem Zahlungsprozessor 9-200. Es gibt auch eine anfängliche Vertrauensbeziehung zwischen jedem Diensteanbieter 9-401–940n und dem Vermittler 9-300.
3. Es gibt eine anfängliche Vertrauensbeziehung zwischen dem Zahlungsprozessor 9-200 und dem Benutzer 9-600 als einem Halter von einer oder mehreren Zahlungskarten 9-610.
4. Es gibt eine anfängliche Vertrauensbeziehung zwischen dem Vermittler 9-300 und dem Benutzer 9-600 als einem mobilen Teilnehmer, der die mobile Endstelle 9-620 benutzt.

Der Satz von anfänglichen Vertrauensbeziehungen hat jedoch einige Lücken. Zunächst ist es, weil der Prozessor 9-200 in der PCI-normkonformen Umgebung 9-100 arbeiten muss, unerlässlich, dass die komplette Kreditkarteninformation 9-612 (das heißt Information, die ausreicht, um betrügerische Käufe vorzunehmen) nicht nach außerhalb der PCI-normkonformen Umgebung getragen wird. Dies bedeutet zum Beispiel, dass, obwohl dem Mediator 9-300 so vertraut wird, dass er Zahlungskartentransaktionen zwischen Diensteanbietern und mobilen Benutzern (als Zahlungskartenhalter) vermittelt, der Vermittler im Stande sein muss, ohne Information zu arbeiten, die die Zahlungskarten der Benutzer global identifiziert. Weiter ist es eine offene Frage, was jede (alle) Zahlungskarte(n) 9-610 und mobile(n) Endstelle(n) 9-620 verbindet.
Es ist eine andere offene Frage, wie die verschiedenen Diensteanbieter 9-401 bis 9-40n oder eine Untermenge von ihnen, die untereinander in Beziehung stehende Dienste bereitstellen, autorisiert werden können, um einem Benutzer 9-600, der mobile Transaktionen von einem Diensteanbieter autorisiert hat, Dienste anzubieten.
Ein elementarer Gebrauchsfall, der eine anfängliche Transaktion zu einem einzelnen Diensteanbieter umfasst, wird als Nächstes in Verbindung mit 9B beschrieben. In Schritt 9-2 führt der Benutzer 9-600 eine Registrierung zur Webseite des Prozessors 9-200 aus. In der Registrierung autorisiert der Benutzer 9-600 einen beispielhaften Diensteanbieter 9-401, Dienste anzubieten, die der Zahlungskarte 9-610 des Benutzers in Rechnung gestellt werden können. Zum Beispiel kann die Registrierung über das Internet ausgeführt werden, indem irgendeine internetfähige Endstelle verwendet wird, die dieselbe Endstelle wie die mobile Endstelle 9-620 des Benutzers sein kann oder nicht. Bei der Registrierung kann der Benutzer z. B. durch Verwenden einer Bankauthentifikation authentifiziert werden. Bei einigen Implementierungen kann die anfängliche Registrierung 9-2 eine Bankauthentifikation oder irgendeine andere Form von starker Authentifikation erfordern, während nachfolgende Verwendungen, wie zum Beispiel Konfigurationsänderungen, eine geringere Authentifikation erfordern können, wie zum Beispiel eine Benutzer-ID/Passwort-Kombination, die während der anfänglichen Registrierung 9-2 ausgegeben wird.
Der Benutzer gibt für den Diensteanbieter 9-401 wirkungsvoll eine Erlaubnis, um dem Benutzer 9-600 Dienste anzubieten, indem auf die Zahlungskarte 9-610 Bezug genommen wird. In Schritt 9-4 speichert der Prozessor 9-200 Information über die Erlaubnis, die durch den Benutzer 9-600 gegeben worden ist. Zum Beispiel kann der Prozessor 9-200 ein Informationstupel 9-212 speichern, das die wahre Identität, Mobilidentität, Zahlungskartennummer des Benutzers und die Identität des Diensteanbieters umfasst. Wiederum wird das Informationstupel 9-212 als eine gute Systemverwaltung für Rechnungsprüfungszwecke betrachtet, während es genau genommen nicht absolut notwendig ist, um Zahlungen zu bewirken.
In Schritt 9-6 erzeugt der Prozessor 9-200 ein ”Token” 9-214, das dem Vermittler 9-300 anzeigt, dass das Informationstupel 9-212 realisiert worden ist. Für die Zwecke der vorliegenden Erfindung ist das Token 9-214 eine gefilterte oder verringerte Version des Informationstupels 9-212, das die Erlaubnis, die durch den Benutzer 9-600 an den Diensteanbieter gegeben worden ist, vollständig identifiziert. Zum Beispiel darf die volle Identifizierungsinformation 9-612 über die Zahlungskarte(n) des Benutzers nicht an Entitäten außerhalb der PCI-normkonformen Umgebung übermittelt werden. Statt der vollen Identifizierungsinformation 9-612 enthält das Token 9-614 genügend Information, um eine spezielle Zahlungskarte 9-610 zum Benutzer/Kartenhalter 9-600 zu identifizieren. Im gegenwärtigen Kontext ist solche Information als ”PaymentCardREF” in den Zeichnungen dargestellt, da dieses Informationselement den Vermittler in den Stand versetzt, die spezielle Zahlungskarte 9-610 mit dem Benutzer/Kartenhalter 9-600 in Bezug zu setzen. In dem dargestellten Beispiel kann das ”PaymentCardREF”-Informationselement einen Wert von ”VISA_4567” aufweisen, wodurch es die spezielle Zahlungskarte unter den Zahlungskarten des gegenwärtigen Benutzers identifiziert, aber die Zahlungskarte nicht global identifizieren kann. In Schritt 9-8 sendet der Herausgeber/Zahlungsprozessor 9-200 das Token 9-214 zu dem Vermittler 9-300. In einem fakultativen Schritt 9-10 sendet der Herausgeber/Zahlungsprozessor das Token zum Diensteanbieter 9-401.
In Schritt 9-20 detektiert der Diensteanbieter 9-401 eine Gelegenheit, ein Diensteangebot zur mobilen Endstelle 9-620 des Benutzers 9-600 zu senden. Es gibt für den Diensteanbieter 9-401 viele Wege, eine solche Gelegenheit zu detektieren. Zum Beispiel kann der Diensteanbieter 9-401 detektieren, dass der Benutzer dabei ist, gewisse Dienst(e) von dem Diensteanbieter anzufragen oder hat sie von ihm angefragt, und der Diensteanbieter kann dem Benutzer gewisse in Beziehung stehende Dienst(e) anbieten. Alternativ oder zusätzlich kann der Benutzer 9-600 zur Webseite des Diensteanbieters navigieren und Information über Dienste anfragen, wodurch zugelassen wird, dass Diensteangebote zur mobilen Endstelle des Benutzers gesendet werden. In Schritt 9-22 sendet der Diensteanbieter 9-401 einen Dienstevorschlag zum Vermittler 9-300. Der Dienstevorschlag 9-22 enthält einen Identifizierer des Tokens 9-214, das in Schritt 9-6 erzeugt wurde. Der Dienstevorschlag 9-22 enthält außerdem Details des Angebots, wie zum Beispiel, was angeboten wird und zu welchem Preis und so weiter. In Schritt 9-24 überarbeitet der Vermittler 9-300 das Angebot und leitet es zur mobilen Endstelle 9-620 des Benutzers weiter. Zusätzlich zu den Details des Angebots enthält das überarbeitete Angebot 9-24 das ”PaymentCardREF”-Informationselement, das nur die Zahlungskarte zum Benutzer/Kartenhalter 9-600 identifiziert, sie aber nicht global identifizieren kann. Während das überarbeitete Angebot 9-24 zur mobilen Endstelle 9-620 des Benutzers gesendet wird, braucht der Diensteanbieter 9-401 die mobile ID nicht zum Vermittler 9-300 zu senden, weil die mobile ID von dem Token 9-214 erhalten werden kann, das in Schritt 9-8 zum Vermittler gesendet wurde.
In Schritt 9-26 reagiert der Benutzer 9-600 von seiner mobilen Endstelle 9-620 aus. Unter der Annahme, dass die DDM-Technik, die woanders in dieser Patentanmeldung beschrieben ist, verwendet wird, muss der Benutzer 9-600 zum Beispiel nur ein ”J” für ”Ja” und irgendetwas anderes (einschließlich keine Antwort) für ”Nein” senden. Ähnlich kann das Angebot eine Liste von Wahlen (z. B. A, B, C, D) enthalten, aus der der Benutzer eine auswählt, indem ein ”A” für die Wahl A geantwortet wird. Selbst wenn mehrere Diensteanbieter 9-401–9-40n jeweils mehrere Angebote senden, verfolgt die DDM-Technik, welche Antwort von dem Benutzer welchem Diensteangebot von welchem Diensteanbieter entspricht. In Schritt 9-28 verwendet der Vermittler 9-300 die DDM-Technik und identifiziert dadurch, auf welches Diensteangebot der Benutzer reagiert. In den fakultativen Schritten 9-30 und 9-32 kann der Vermittler 9-300 eine Annahme von dem Herausgeber/Diensteanbieter 9-200 anfordern, der beispielsweise eine Kreditüberprüfung ausführen kann. Wenn das Ergebnis der Kreditüberprüfung positiv ist, liefert der Herausgeber/Diensteanbieter 9-200 eine Annahme auf die Anfrage des Vermittlers. Der Austausch von Mitteilungen 9-30 und 9-32 dient zwei Zwecken. Erstens leitet der Vermittler Informationen über die Annahme des Benutzers zum Herausgeber/Zahlungsprozessor 9-200 für Belastungszwecke weiter, und zweitens fragt der Vermittler den Herausgeber/Zahlungsprozessor 9-200 an, um jegliche Kredit- oder Sicherheitsüberprüfungen zu führen, die mit der Politik des Herausgebers/Zahlungsprozessors normkonform sind. In Schritt 9-34 befördert der Vermittler 9-300, vorausgesetzt, dass das Ergebnis der Überprüfung(en) positiv ist, die Annahme des Benutzers zum Diensteanbieter 9-401.
In Schritt 9-36 kann der Vermittler, der Herausgeber/Diensteanbieter und/oder der Diensteanbieter eine Bestätigung zum mobilen Benutzer/Kartenhalter 9-600 senden. Genau genommen wird die Bestätigung als gutes Benehmen und gute Systemverwaltung betrachtet, ist aber nicht absolut wesentlich, um den angeforderten Dienst bereitzustellen. In einigen Implementierungen kann der Schritt 9-30 bis ... in unterschiedlichen Reihenfolgen und/oder durch unterschiedliche Entitäten ausgeführt werden. Wie aus der Zeichnung ersichtlich ist, weiß nach Schritt 9-34 jeder von dem Vermittler, Herausgeber/Diensteanbieter und/oder Diensteanbieter gleich gut, dass alles in Ordnung ist, und jegliche Entität kann die Bestätigung zum mobilen Benutzer senden.
Während die obigen Schritte 9-2 bis 9-34 ausreichen, um sich wiederholende Zahlungen hinsichtlich eines mobilen Benutzers/einer mobilen Endstelle und eines Diensteanbieters zu realisieren, gibt es einen Wunsch, ein Kombinieren von Diensteanbietungen von mehreren in Beziehung stehenden Diensteanbietern erleichtern.
Zum Beispiel nehme man an, dass der Diensteanbieter 9-401 eine Fluggesellschaft ist. Unter dieser Annahme kann der Gelegenheits-detektierende Schritt 9-20 so implementiert werden, dass die Fluggesellschaft ein Beispiel für einen Großhändler 9-250 innerhalb der PCI-normkonformen Umgebung 9-100 ist, und diese Entität informiert den Diensteanbieter 9-401, der ein Beispiel für einen Onlineladen außerhalb der PCI-normkonformen Umgebung 9-100 ist.
In einigen Gebrauchsfällen kann der Fluggesellschaft-Onlineladen die Gelegenheit 9-20 nutzen, um zusätzliche Dienste anzubieten, in welchem Fall die Zahlungen, wie in Verbindung mit 9B beschrieben, verarbeitet werden können (anfängliche vorbereitende Schritte 9-2 bis 9-8, sich wiederholende Schritte 9-22 bis 9-34). In einem veranschaulichenden, aber nichterschöpfenden Beispiel kann der erste Dienst ein Fluggesellschaftsticket sein, während die zusätzlichen Dienste umfassen können eines oder mehreres von einem Sitzplatzupgrade, benutzerwählbaren Sitz, Shuttleservice oder irgendeinem zusätzlichen Dienst, der durch den Diensteanbieter 9-401 bereitgestellt wird, indem das Token verwendet wird, das in den Schritten 9-6 ... 9-8 erzeugt ist.
In anderen Gebrauchsfällen kann es wünschenswert sein, um einem Benutzer 9-600 von in Beziehung stehenden Diensteanbietern Dienste anzubieten, wobei der Vermittler 9-300 kein Token für die Kombination von Benutzer und Diensteanbieter aufweist. In solchen Fällen sollte eine Anzahl von Problemen gelöst werden. Zum Beispiel, welchen Diensteanbietern, die mit dem ursprünglichen Diensteanbieter 9-401 in Beziehung stehen, sollte es erlaubt sein, verwandte Dienste anzubieten? Wie hierin verwendet, bedeutet der ursprüngliche Diensteanbieter den Diensteanbieter, bei dem der Vermittler ein Token für diesen Diensteanbieter und den Benutzer aufweist. Während eine nützliche Information über verwandte Dienste häufig für einen Kunden wertvoll ist, ist es unvernünftiges Spamming nicht. Eine andere offene Frage ist, welche Entität zwischen Diensteanbietern, die dem Benutzer verwandte Dienste anbieten können, und Diensteanbietern, die das nicht können, unterscheiden sollte. Noch eine andere offene Frage ist, welche Information bei der Unterscheidung zwischen den Diensteanbietern verwendet werden soll, und wie.
Bei einigen Implementierungen bestimmt der Vermittler 9-300, welche in Beziehung stehenden Diensteanbieter Angebote zum Benutzer 9-600 in einer Situation senden können, in der ein Token für den Benutzer 9-600 und einen ursprünglichen Diensteanbieter 9-401 vorhanden ist. Im gegenwärtigen Kontext bedeutet der ursprüngliche Diensteanbieter denjenigen, von dem der Benutzer einen oder mehrere Dienste angefragt hat.
Es gibt viele unterschiedliche Techniken, durch die der Vermittler 9-300 bestimmen kann, welche in Beziehung stehenden Diensteanbieter verwandte Angebote zum Benutzer 9-600 senden können. Zum Beispiel können die Bedienpersonen der verschiedenen Diensteanbieter (als Großhändler/legale Entitäten 9-250) über einen Satz von anfänglichem Vertrauensniveau und einem Satz von anfänglichen Regeln übereinstimmen, und diese Sätze von Regeln werden an den Vermittler übergeben. In einer ehrgeizigeren Implementierung kann der Vermittler 9-300 das Vertrauensniveau und/oder die Regeln dynamisch einstellen. Zum Beispiel kann der Vermittler 9-300 das Vertrauensniveau und/oder die Regeln auf Grundlage von impliziter und/oder expliziter Rückkopplung von den Benutzern einstellen. In einem veranschaulichenden Beispiel von impliziter Rückkopplung überwacht der Vermittler 9-300 die Annahmeraten von Diensteangeboten von den Diensteanbietern und erhöht oder verringert das Vertrauensniveau abhängig davon, ob die Annahmerate mit einem gewissen statischen oder dynamischen Schwellenwert übereinstimmt oder nicht übereinstimmt. Eine Beschränkung dieser Technik ist, dass das Vertrauensniveau von Diensteanbietern auf Annahme des Angebots gegründet ist, aber die tatsächliche Qualität des Diensts nicht ausgewertet wird. In einem veranschaulichenden Beispiel von expliziter Rückkopplung überwacht der Vermittler 9-300 eine Rückkopplung von den Benutzern, die von der Annahme von Diensteangeboten getrennt ist. Eine solche getrennte Rückkopplung, die von den mobilen Endstellen oder Webendstellen des Benutzers eingegeben werden kann, kann die tatsächliche Qualität des Dienstes berücksichtigen.
Angenommen, dass der Diensteanbieter 2, der mit der Bezugsziffer 9-402 bezeichnet ist, einer ist, der die vermittlerimplementierten Kriterien erfüllt, so dass dem Diensteanbieter 2 erlaubt wird, Angebote an den Benutzer 9-600 zu senden, der vom Diensteanbieter 1 bereits Angebote angenommen hat (und eine Erzeugung eines Tokens für diesen Diensteanbieter 1 akzeptiert hat).
Es wird nun auf 9C Bezug genommen. Die Schritte 9-20 bis 9-34 sind bereits in Verbindung mit 9B beschrieben worden, und eine Doppelbeschreibung wird weggelassen. Die Schritte 9-20 bis 9-34 werden zur Bequemlichkeit des Benutzers in 9C mit abgekürzten Legenden wiederholt.
Der zweite größere Abschnitt in 9C, das heißt die Schritte 9-42 bis 9-56, stehen in Beziehung zur Erzeugung eines Tokens für sich wiederholende Zahlungen von dem Benutzer 9-600 zum Diensteanbieter 2, 9-402. Was diese Schritte bewerkstelligen, ist größtenteils analog zur Erzeugung des Tokens für sich wiederholende Zahlungen vom Benutzer 9-600 zum Diensteanbieter 1, 9-402, das in Verbindung mit 9B beschrieben wurde (siehe die Schritte 9-2 bis 9-8 für Details). Die tatsächliche Implementierung ist jedoch unterschiedlich. In der Tokenerzeugungsphase von 9C, die Schritte 9-42 ... 9-56, ist es nicht der Benutzer 9-600, der die Initiative aufweist, sondern der Vermittler 9-300. Demgemäß braucht der Benutzer mobile Zahlungen für jeden einzelnen Diensteanbieter nicht explizit zu registrieren. Andererseits ist eine Erzeugung des Tokens für den Benutzer und den Diensteanbieter 2 auch nicht vollständig jenseits der Steuerung des Benutzers. In einer bevorzugten Implementierung wird die Erlaubnis eines Benutzers, ein Token für in Beziehung stehende Diensteanbieter zu erzeugen, angefordert, aber eine Unbequemlichkeit für den Benutzer sollte auf das Minimum beschränkt werden. Die Schritte 9-42 bis 9-56 veranschaulichen eine Weise, dieses zu erreichen.
Als ein Ergebnis von Schritt 9-26 weiß der Vermittler 9-300, dass der Benutzer 9-600 mobile Zahlungen für Dienste von Diensteanbieter 1, 9-401, autorisiert hat. Der Vermittler 9-300 verwendet nun diese Information und veranlasst in Schritt 9-42 den Prozessor 9-200, eine Erlaubnis anzufragen, ein Token für die Kombination von Benutzer 9-600 und Diensteanbieter 2, 9-402, zu erzeugen. In Schritt 9-44 fragt der Prozessor 9-200 eine Erlaubnis von dem Benutzer 9-600 an, das Token zu erzeugen. In Schritt 9-46 leitet der Vermittler 9-300 die Anfrage zur mobilen Endstelle 9-620 des Benutzers 9-600 weiter. Im vorliegenden Beispiel akzeptiert der Benutzer die Erzeugung des Tokens und sendet eine bestätigende Reaktion (z. B. ”J”) in Schritt 9-48. In Schritt 9-50 wird die Erlaubnis des Benutzers, das Token zu erzeugen, zum Prozessor 9-200 weitergeleitet, der einen Bericht erzeugt, der die Erlaubnis des Benutzers in Schritt 9-52 anzeigt. In Schritt 9-54 erzeugt der Zahlungsprozessor das aktuelle Token, das in Schritt 9-56 zum Vermittler gesendet wird. Die drei letzten Schritte dieser Phase, nämlich die Schritte 9-52 bis 9-56 sind ähnlich zu den entsprechenden Schritten 9-4 bis 9-6, in denen das erste Token in 9B erzeugt wurde.
Der Unterschied zu den Schritten 9-4 bis 9-6 von 9B besteht darin, dass in 9B der Benutzer 9-600 den Tokenerzeugungsprozess nicht initiieren muss, sich nicht authentifizieren muss, jegliche Details bereitstellen muss. Stattdessen ist es der Vermittler, der den Tokenerzeugungsprozess auf Grundlage der Kenntnis initiiert, dass der Benutzer vom Diensteanbieter 1 einen Dienst angefordert hat (und eine Inrechnungsstellung von ihm akzeptiert hat), für den der Vermittler in Beziehung stehende Diensteanbieter kennt. Der Vermittler besitzt nicht sämtliche erforderliche Information für den Tokenerzeugungsprozess, noch braucht er sie zu besitzen. Stattdessen muss der Vermittler nur wissen, dass ein Token für die Kombination des Benutzers 9-600 und Diensteanbieters 2, 9-402, erzeugt werden sollte oder dass eine Erlaubnis für seine Erzeugung von dem Benutzer angefordert werden sollte. Die restlichen Details für die Erlaubnis des Benutzers und das Token, am wichtigsten die Zahlungskartenidentifikationsinformation 9-612, sind dem Prozessor 9-200 bekannt.
Es lohnt sich auch, hier anzumerken, dass sich der Benutzer authentifizieren muss und/oder spezifizieren muss, welche Angebote von mehreren simultanen Diensteangeboten von einem oder mehreren Diensteanbietern angenommen werden und welche abgelehnt werden. Es ist möglich, die DDM-Technik, die früher in dieser Patentanmeldung beschrieben ist, zu verwenden, um eine Authentifikation bereitzustellen und/oder um Benutzerreaktionen an Diensteangebote anzupassen. Bei einigen Implementierungen kann die DDM-Technik weggelassen werden, zumindest für Transaktionen von geringem Wert und/oder in Verbindung mit Benutzern mit guter Vergangenheit.
Als Ergebnis des Tokenerzeugungsprozesses, der in Schritt 9-56 zum Vermittler gemeldet wurde, wird Diensteanbieter 2, 9-402, nun von der Erzeugung des Tokens in Kenntnis gesetzt. Dieser Inkenntnissetzungsschritt 9-58 lässt absichtlich die Frage offen, welche Entität die Inkenntnissetzung sendet. Abhängig von einer Implementierung kann die Inkenntnissetzung von dem Prozessor 9-200 oder dem Vermittler 9-300 gesendet werden, da sie beide dieselbe Information verfügbar haben.
Die Schritte 9-62 bis 9-76, in denen der Diensteanbieter 2, 9-402, ein Angebot zum Benutzer 9-600 sendet und der Benutzer annimmt, sind analog zu den entsprechenden Schritten 9-22 bis 9-34, wobei der alleinige Unterschied der Diensteanbieter ist. Im ersten Fall (die Schritte 9-22 bis 9-34) war es der Diensteanbieter 1, während es im letzteren Fall (die Schritte 9-62 bis 9-76) der Diensteanbieter 2 war.
Die 10A bis 10D veranschaulichen weitere Variationen für die Ausführungsformen, die in Verbindung mit den 9A–9C beschrieben sind. In den 10A bis 10D sind Elemente mit Bezugsnummern, die mit ”10-” beginnen, hier zum ersten Mal beschrieben. Die übrigen Elemente sind in Verbindungen mit früheren Zeichnungen beschrieben worden, und eine doppelte Beschreibung ist weggelassen. Elemente mit Bezugsnummern 9-xxx und 10-xxx, wobei ”xxx” über die Zeichnungen gleich ist, stehen im Allgemeinen mit ähnlichen oder entsprechenden Elementen in Beziehung, und es werden nur die Unterschiede zu dem entsprechenden Element 9-xxx beschrieben.
Speziell stellt 10A eine Implementierung dar, bei der sich der Vermittler, der nun durch Bezugsziffer 10-300 bezeichnet wird, innerhalb der PCI-normkonformen Umgebung 9-100 aufhält (”PCI” = Payment Card Industry, siehe Beschreibung von 9A). Diese Implementierung macht es für die anderen Parteien, wie zum Beispiel die Bedienpersonen des Herausgebers oder Zahlungsprozessors 9-200 und/oder der Großhändler 9-250 oder Diensteanbieter 9-400, leichter, dem Vermittler zu trauen.
Der Vermittler 10-300 entspricht im Allgemeinen dem Vermittler 9-300, der in Verbindung mit den 9A–9C beschrieben ist. Der Unterschied zu der früheren Implementierung ist, dass sich der Vermittler 10-300 innerhalb der PCI-normkonformen Umgebung 9-100 aufhält und natürlich sämtliche PCI-Infrastrukturspezifikationen und Zertifikationen erfüllt. Die Signalisierungsdiagramme, die in den 9B und 9C dargestellt sind, sind direkt auf die Implementierung, die in 10A dargestellt ist, anwendbar.
Die Tatsache, dass sich der Vermittler 10-300 im Innern der PCI-normkonformen Umgebung aufhält und die PCI-Spezifikationen und Zertifikationen erfüllt, kann die verschiedensten unterschiedlichen Implementierungen aufweisen, einschließlich einige oder sämtliche der Folgenden:

– Der Vermittler kann durch eine legale Entität implementiert und betrieben werden, dessen Angestellte einer Sicherheitsüberprüfung ausgesetzt sind.
– Der Vermittler, oder mindestens kritische Teile von ihm, werden durch eine oder mehrere sehr vertrauenswürdige Parteien programmiert oder überwacht, und die Unversehrtheit des Vermittlers wird mit kryptographischen Techniken verifiziert. Zum Beispiel können durch eine vertrauenswürdige Entität verifizierte Zertifikate verwendet werden. Alternativ oder zusätzlich können einige kritische Teile des Vermittlers Firmware sein, die auf eine Weise codiert sind, die zu mobilen SIM-Karten ähnlich ist, die unter Verwendung eines Challenge-Response-Mechanismus authentifiziert werden. Im Falle einer SIM-Karte, die durch eine mobile Bedienperson bereitgestellt wird, wird dem Authentifikationsalgorithmus, der auf der SIM läuft, typischerweise eine 128-Bit-Zufallszahl (RAND) als eine Herausforderung zugewiesen. Die SIM durchläuft einen Bedienperson-spezifischen vertraulichen Algorithmus, der die RAND und einen geheimen Schlüssel Ki, der auf der SIM gespeichert ist, als Eingabe nimmt und eine 32-Bit-Antwort (SRES) und einen 64-Bit-langen Schlüssel Kc als Ausgang erzeugt. Dasselbe Authentifikationsschema kann auf eine solche Weise verwendet werden, dass der Herausgeber/Zahlungsprozessor (als eine legale Entität) als die mobile Bedienperson in dem SIM-Kartenbeispiel wirkt. Mit anderen Worten, die ganze Software des Vermittlers oder eine kritische Untermenge davon kann durch Experten, die durch den Herausgeber/Zahlungsprozessor als vertrauenswürdig eingestuft sind, kodiert oder mindestens geprüft sein. Die Software, die die kritischen Teile der Vermittlerfunktionalität und den Challenge-Response-Mechanismus umfasst, kann in Firmware kodiert sein, von der sie der Vermittler (als Proxyserver) ausführen kann. 10B ist ein Signalisierungsdiagramm, das eine Abweichung von dem in 9C dargestellten Signalisierungsdiagramm darstellt. Verglichen mit dem früheren Signalisierungsdiagramm sind einige Aufgaben des Vermittlers nun zu dem Herausgeber oder Zahlungsprozessor 9-200 delegiert. In dem früheren Signalisierungsdiagramm von 9C führt der Vermittler zwei Arten von Aufgaben durch. In Schritt 9-42 initiiert der Vermittler eine Prozedur, die zu einer Erzeugung eines Tokens für die Kombination von einem Benutzer N und Diensteanbieter 2 führt, vorausgesetzt, dass bereits ein Token für denselben Benutzer N und einen in Beziehung stehenden Diensteanbieter 1 existiert. In Schritt 9-64 vermittelt der Vermittler ein Diensteangebot vom Diensteanbieter 2 zum Benutzer N und leitet die Annahme vom Benutzer N zum Diensteanbieter 2 und zum Herausgeber oder Zahlungsprozessor weiter. Nun nehme man für einen Augenblick an, dass die Bedienperson des Herausgebers von Zahlungsprozessor 9-200 der Bedienperson oder dem Vermittler 9-300, 10-300 nicht traut. Wenn die Bedienperson des Vermittlers betrügerisch war, würde der Vermittler diese zwei Aufgaben (die eine, die in Schritt 9-42 beginnt, und die eine, die in Schritt 9-64 beginnt) auf betrügerische Weise auszuführen haben. Mit anderen Worten, der betrügerische Vermittler muss beide Mitteilungen 9-50 (”Erlaubnis, um ein Token für Diensteanbieter 2 zu erzeugen”) und 9-70 (”Vorschlag OK”) zum Herausgeber oder Zahlungsprozessor 9-200 ohne die Zustimmung des Benutzers 9-600 senden.

In dem Signalisierungsdiagramm von 10B erhält der Herausgeber/Zahlungsprozessor 9-200 direkt die Erlaubnis, das Token für Benutzer N 9-600 und Diensteanbieter 2 zu erzeugen, wodurch der Vermittler im Tokenerzeugungsschritt umgangen wird. Der Herausgeber/Zahlungsprozessor 9-200 schlägt dem Benutzer im Schritt 10-44 eine Tokenerzeugung vor und erhält die Erlaubnis des Benutzers in Schritt 10-48. Schritt 10-44 entspricht den Schritten 9-44 und 9-46 von 9C, während Schritt 10-48 den Schritten 9-48 und 9-50 entspricht, abgesehen von der Tatsache, dass der Vermittler umgangen wird, zumindest für diesen speziellen Fall.
Weil der Herausgeber/Zahlungsprozessor 9-200 eine Partei ist, der von jeder der anderen Entitäten vertraut wird, macht die Tatsache, dass die Autorisierung, das Token zu erzeugen, durch den Herausgeber/Zahlungsprozessor erhalten wurde, es für den Herausgeber/Zahlungsprozessor und die anderen Entitäten leichter, dem Vermittler zu trauen.
In einer Variation des Signalisierungsdiagramms von 10B kann der Vermittler den Tokenerzeugungsschritt ähnlich zu dem in 9C dargestellten Fall vermitteln (die Schritte 9-48 bis 9-56), aber in dieser Variation erhält der Herausgeber/Zahlungsprozessor 9-200 direkt die Autorisierung des Benutzers für einige oder sämtliche der einzelnen Transaktionen. Was dies bedeutet, ist, dass der Vermittler in den Schritten 9-64 bis 9-72 für einige oder alle Transaktionen umgangen wird. Zum Beispiel kann der Herausgeber/Zahlungsprozessor entscheiden, den Vermittler für einige oder alle von den folgenden Fällen zu umgehen:

– eine zufällige Auswahl von allen Transaktionen;
– alle Transaktionen, deren Wert einen gegebenen Schwellenwert überschreitet;
– eine zufällige Auswahl aus Transaktionen über einen gegebenen Schwellenwert;
– eine Anzahl von ersten Transaktionen für den Vermittler, Benutzer und/oder Diensteanbieter;
– eine Anzahl von ersten Transaktionen für eine Kombination von Benutzer und Diensteanbieter.

In einem sehr ehrgeizigen Schema weisen einige oder sämtliche Parteien außer dem Herausgeber/Zahlungsprozessor, nämlich der Vermittler, Benutzer und Diensteanbieter, einen niedrigen anfänglichen Vertrauenswert auf. Für eine beliebige Partei wird der anfängliche niedrige Vertrauenswert für eine beliebige erfolgreich beendete Transaktion erhöht. Eine Transaktion von hohem Wert erhöht den Vertrauenswert der Parteien der Transaktion mehr als es eine Transaktion von niedrigem Wert tut. Der Vertrauenswert kann sich verringern durch Zeit, verzögerte Zahlungen oder andere Formen von verdächtigem Verhalten. Wenn eine beliebige Partei einer Transaktion einen niedrigen Vertrauenswert aufweist oder eine Kombination der Vertrauenswerte der Parteien der Transaktion niedrig ist, entweder auf einer absoluten Skala oder im Vergleich mit dem Wert der gegenwärtigen Transaktion, kann der Herausgeber/Zahlungsprozessor entscheiden, den Vermittler zu umgehen und die Autorisierung des Benutzers direkt zu erhalten.
Das Signalisierungsdiagramm von 10C stellt eine unterschiedliche Abweichung von demjenigen dar, das in 9C dargestellt ist. Im Signalisierungsdiagramm von 10C sind die Schritte 9-42 bis 9-56 ähnlich zu denjenigen, die in 93 und 9C dargestellt sind. Dies bedeutet, dass der Vermittler 9-300 für einen Erhalt der Erlaubnis zur Tokenerzeugung von dem mobilen Benutzer 9-600 verantwortlich ist. 10C unterscheidet sich von 9C darin, dass eine Bestätigungsüberprüfung 10-74, 10-76 zwischen dem Herausgeber/Zahlungsprozessor 9-200 zum mobilen Benutzer 9-600 der Endbestätigung 9-76 von dem Herausgeber/Zahlungsprozessor 9-200 zum mobilen Benutzer 9-600 vorhergeht. Mit anderen Worten kann der Herausgeber/Zahlungsprozessor 9-200 zumindest für einige von den einzelnen Transaktionen den Vermittler 9-300 umgehen und die Autorisierung des Benutzers direkt erhalten, um einige oder alle von den einzelnen Transaktionen zu erhalten.
Das Signalisierungsdiagramm von 10D stellt eine noch weitere Abweichung von demjenigen dar, das in 9C dargestellt ist. Im vorliegenden Fall sind zwei Vermittler, die durch Bezugszahlen 10-301 und 10-302 bezeichnet sind, implementiert worden. Jeder von den zwei Vermittlern kann den Vermittlern 9-300, 10-300 entsprechen, die früher beschrieben sind. Mit anderen Worten kann sich jeder Vermittler oder beide von ihnen innerhalb oder außerhalb der PCI-normkonformen Infrastruktur 9-100 aufhalten. Die Mitteilungen und Handlungen 10-xxx, die in 10D ausgeführt werden, sind identisch mit Mitteilungen und Handlungen 9-xxx, die in 9C ausgeführt werden, abgesehen von der Tatsache, dass Mitteilungen und Handlungen bis zu und einschließlich Mitteilung 10-50 in Beziehung zu dem Vermittler 1 stehen, während Mitteilungen und Handlungen, die bei der Mitteilung 10-50 beginnen, in Beziehung zu dem Vermittler 2 stehen. In dem Signalisierungsdiagramm von 10D vermittelt der erste Vermittler 10-301 den Prozess, die Erlaubnis des mobilen Benutzers zu erhalten, um das Token für die Kombination von dem Benutzer und Diensteanbieter 2 zu erzeugen, während der zweite Vermittler 10-302 den Prozess managt, die Erlaubnis des mobilen Benutzers zu erhalten, um einzelne Transaktionen durchzuführen.
Nun, vorausgesetzt, dass die zwei Vermittler 10-301 und 10-302 durch wechselseitig unabhängige Bedienpersonen betrieben werden, macht es die Aufteilung von Aufgaben zwischen den zwei Vermittlern für die anderen Parteien leichter, den Vermittlern 10-301 und 10-302 zu vertrauen. Dies ist deshalb der Fall, weil eine einzelne betrügerische Bedienperson tatsächlich aus betrügerischen Arbeitsweisen keinen Nutzen ziehen kann. Angenommen, dass die Bedienperson des ersten Vermittlers 10-301 betrügerisch war, und Autorisierungen für eine Tokenerzeugung signalisierte, ohne tatsächlich die Erlaubnis des mobilen Benutzers zu besitzen. Diese Art von betrügerischer Arbeitsweise würde nahezu unmittelbar detektiert werden, weil die Bestätigungen für die einzelnen Transaktionen durch den zweiten Vermittler vermittelt werden, der durch eine andere Bedienperson als der erste Vermittler betrieben wird. Ähnlich kann der zweite Vermittler nicht betrügerisch handeln, es sei denn, die Transaktion umfasst einen Diensteanbieter, für den der mobile Benutzer bereits sich wiederholende Zahlungen über den ersten Vermittler autorisiert hat. Was dies bedeutet, ist, dass ein Nutzenziehen aus betrügerischem Verhalten eine Kooperation von drei Entitäten erfordert, nämlich mindestens einem Diensteanbieter plus den Bedienpersonen der zwei Vermittler.
Zusätzlich zur Aufteilung eines Vermittelns einer Aufgabe zwischen den zwei Vermittlern 10-301, 10-302 kann der Herausgeber/Zahlungsprozessor 9-200 zumindest für einige Erlaubnisse und Transaktionen einen oder beide Vermittler umgehen und Bestätigungen direkt von den mobilen Benutzern erhalten, wie in Verbindung mit 10B und 10C beschrieben.
Gewisse fakultative Maßnahmen können ergriffen werden, um das Risiko von betrügerischem Verhalten weiter zu reduzieren. Zum Beispiel kann das Token eine Anzahl von mit ihm verbundenen Beschränkungen aufweisen. Die Beschränkungen können für die Lebensdauer des Tokens und/oder für den Wert von finanziellen Transaktionen, die durch Verwenden des Tokens gemacht werden, gelten. Die Lebensdauerbeschränkungen können in Kalenderzeit definiert sein, wie zum Beispiel eine Gültigkeitsperiode, die an einem vorbestimmten Tag endet, oder in einer Anzahl von Verwendungen, wie zum Beispiel ein Token, das für n Transaktionen verwendet werden kann, wobei n eine ganze Zahl ist. Alternativ oder zusätzlich kann der Wert von finanziellen Transaktionen, die vorgenommen werden, indem das Token verwendet wird, beschränkt sein. Zum Beispiel kann jede einzelne Transaktion auf ein oberes Limit beschränkt sein oder das Token kann ungültig werden, sobald es verwendet worden ist, um Transaktionen mit einer Gesamtsumme über einem gegebenen Wert auszuführen. Die Beschränkungen, die mit den Tokens verbunden sind, können durch den Herausgeber/Zahlungsprozessor 9-200, den (die) Vermittler 9-300, 10-301, 10-302 und/oder die Diensteanbieter 9-401, 9-402 zur Geltung gebracht werden.
11 stellt schematisch ein beispielhaftes Blockdiagramm für die verschiedenen informationsverarbeitenden- und/oder -vermittelnden Server in den früher beschriebenen Systemen dar. Zum Beispiel kann eine solche Serverarchitektur, die im Allgemeinen durch eine Bezugsziffer 11-100 bezeichnet ist, verwendet werden, um die Vermittler 100 und/oder die Server für die dienstespezifischen Systeme 122 zu implementieren, wofür ein Beispiel das Buchungssystem 102 ist. Die beiden größeren funktionellen Blöcke des Datenbankserversystems SS sind ein Servercomputer 11-100 und ein Speichersystem 11-190. Der Servercomputer 11-100 umfasst eine oder mehrere Zentraleinheiten CP1 ... CP_n, die im Allgemeinen durch die Bezugsziffer 11-110 bezeichnet sind. Ausführungsformen, die mehrere Zentraleinheiten 11-110 umfassen, sind vorzugsweise mit einer Lastausgleichseinheit 11-115 versehen, die eine Verarbeitungslast zwischen den mehreren Zentraleinheiten 11-110 ausgleicht. Die mehreren Zentraleinheiten 11-110 können als gesonderte Prozessorkomponenten oder als körperliche Prozessorkerne oder virtuelle Prozessoren in einem einzigen Komponentengehäuse implementiert werden. Der Servercomputer 11-100 umfasst weiter eine Netzschnittstelle 11-120 zum Kommunizieren mit verschiedenen Datennetzen, die im Allgemeinen durch ein Bezugszeichen DN bezeichnet sind. Die Datennetze DN können lokale Netze, wie zum Beispiel ein Ethernet-Netz, und/oder weiträumige Netze, wie zum Beispiel das Internet, umfassen. Angenommen, dass der Servercomputer 11-100 als ein Vermittler 100 wirkt, kann er einem oder mehreren dienstespezifischen Systemen 122 über das Datennetz DN dienen. Die Bezugsziffer 11-125 bezeichnet eine Mobilnetzschnittstelle, durch die der Servercomputer 11-100 mit verschiedenen Teilnehmernetzen AN kommunizieren kann, die wiederum den mobilen Endstellen MT dienen, die durch Endbenutzer oder Auftraggeber verwendet werden.
Der Servercomputer 11-100 der vorliegenden Ausführungsform kann auch eine lokale Benutzeroberfläche 1-140 umfassen. Abhängig von einer Implementierung kann die Benutzeroberfläche 11-140 lokale Eingabe-Ausgabe-Schaltungsanordnung für eine lokale Benutzeroberfläche umfassen, wie zum Beispiel eine Tastatur, Maus und Anzeige (nicht dargestellt). Alternativ oder zusätzlich kann ein Management des Servercomputers 11-100 ferngesteuert implementiert werden, indem die Netzschnittstelle 11-120 und jegliche internetfähige Endstelle verwendet wird, die eine Benutzeroberfläche bereitstellt. Die Natur der Benutzeroberfläche hängt davon ab, welche Art von Computer verwendet wird, um den Servercomputer 11-100 zu implementieren. Wenn der Servercomputer 11-100 ein Spezialrechner ist, mag er keine lokale Benutzeroberfläche benötigen, und der Servercomputer 11-100 kann ferngesteuert gemanagt werden, wie beispielsweise von einem Webbrowser über das Internet. Ein solches Fernmanagement kann über dieselbe Netzschnittstelle 11-120 bewerkstelligt werden, die der Servercomputer für einen Verkehr zwischen sich selbst und den Auftraggeberendstellen verwendet.
Der Servercomputer 11-100 umfasst auch Speicher 11-150 zum Speichern von Programminstruktionen, Betriebsparametern und Variablen. Bezugsziffer 11-160 bezeichnet ein Programmpaket für den Servercomputer 11-100.
Der Servercomputer 11-100 umfasst auch Schaltungsanordnung für verschiedene Taktgeber, Programmunterbrechungen und dergleichen, und diese sind im Allgemeinen durch Bezugsziffer 11-130 wiedergegeben. Der Servercomputer 11-100 umfasst weiter eine Speicherschnittstelle 11-145 zum Speichersystem 11-190. Wenn der Servercomputer 11-100 ausgeschaltet wird, kann das Speichersystem 11-190 die Software speichern, die die Verarbeitungsfunktionen implementiert, und beim Hochfahren wird die Software in den Halbleiterspeicher 11-150 eingelesen. Das Speichersystem 11-190 behält auch ein Funktionieren und Variablen über Abschaltperioden bei. Bei großvolumigen Implementierungen, das heißt Implementierungen, bei denen ein einziger Servercomputer 11-100 einer großen Anzahl von Auftraggebern über jeweilige mobile Endstellen MT dient, kann das Speichersystem 11-190 verwendet werden, um die dynamischen Dialogmatrizen, die mit den Auftraggebern und mobilen Endstellen MT verbunden sind, zu speichern. Die verschiedenen Elemente 11-110 bis 11-150 wechselsprechen über einen Bus 11-105, der Adresssignale, Datensignale und Steuersignale überträgt, wie Fachleuten wohlbekannt ist.
Die erfinderischen Techniken können wie folgt in dem Servercomputer 11-100 implementiert werden. Das Programmpaket 11-160 umfasst Programmcodeinstruktionen zum Instruieren des Satzes von Prozessoren 11-110, um die Funktionen des erfinderischen Verfahrens auszuführen, wobei die Funktionen ein Ausführen der Dienstebereitstellungs- und/oder Vermittlermerkmale gemäß der Erfindung und/oder ihrer Ausführungsformen umfassen.

Claims

Ein Verfahren umfassend die folgenden Schritte an einem Zahlungsprozessorcomputer (9-200), der konfiguriert ist, um Transaktionen zu managen, die in Beziehung zu einem oder mehreren Diensten stehen, die durch Diensteanbieter (9-400, 9-401–9-40n) bereitgestellt werden, die einen ersten Diensteanbieter (9-401) und einen zweiten Diensteanbieter (9-402) umfassen, wobei die Transaktionen durch eine oder mehrere Zahlungskarten (9-610) zu zahlen sind: – Verarbeiten einer ersten Anforderung (9-2), erste sich wiederholende Zahlungen an den ersten Diensteanbieter (9-401) zu autorisieren, wobei die sich wiederholenden Zahlungen durch eine erste Zahlungskarte der einen oder mehreren Zahlungskarten zu zahlen sind; – Empfangen einer zweiten Anforderung (9-42), zweite sich wiederholende Zahlungen an den zweiten Diensteanbieter (9-402) zu autorisieren, wobei die zweiten sich wiederholenden Zahlungen durch eine zweite Zahlungskarte der einen oder mehreren Zahlungskarten zu zahlen sind, und wobei die erste und zweite Zahlungskarte dieselbe Zahlungskarte oder gesonderte Zahlungskarten sein können; – Verwenden (9-44) eines ersten Vermittlerservers (9-300, 10-300), um eine Bestätigung (9-55) von dem Halter (9-600) der Zahlungskarten zu erhalten, dass der zweite Diensteanbieter (9-402) Dienste dem Halter der Zahlungskarten vorschlagen kann, ansprechend auf die zweite Anforderung; – Erzeugen (9-54) eines Tokens, das den zweiten Diensteanbieter identifiziert, wobei das Token die zweite Zahlungskarte nicht umfassend identifiziert, sondern die zweite Zahlungskarte innerhalb Zahlungskarten identifiziert, die an einen Halter der Zahlungskarten ausgegeben sind; – Senden (9-56) des erzeugten Tokens zu einem zweiten Vermittlerserver; – Empfangen (9-72) einer Annahmemitteilung von dem ersten oder zweiten Vermittlerserver, die anzeigt, dass der Halter der speziellen Zahlungskarte eine mobile Endstelle über ein Mobilnetzwerk verwendet hat, um die zweiten sich wiederholenden Zahlungen an den zweiten Diensteanbieter zu autorisieren, wobei der erste Vermittlerserver und der zweite Vermittlerserver derselbe Vermittlerserver oder verschiedene Vermittlerserver sein können.
Das Verfahren nach Anspruch 1, wobei der Zahlungsprozessorcomputer den ersten oder zweiten Vermittlerserver, dazu veranlasst, das Token zu benutzen, um abzufragen, ob der Halter der spezifischen Zahlung wünscht, widerkehrende Zahlungen an den spezifischen Diensteanbieter zu autorisieren.
Das Verfahren nach Anspruch 1 oder 2, wobei der Zahlungsprozessorcomputer die Integrität des ersten und/oder zweiten Vermittlerservers durch Verwenden von einer oder mehrerer Verschlüsselungstechniken verifiziert.
Das Verfahren nach Anspruch 3, worin die eine oder mehrere Verschlüsselungstechniken „challenge and response” Autorisierung umfassen.
Das Verfahren nach Anspruch 3 oder 4, worin die eine oder mehrere Verschlüsselungstechniken die Verifizierung eines oder mehrerer Zertifikate, die in dem ersten und/oder zweiten Vermittlerserver gespeichert sind, umfassen.
Das Verfahren nach einem der vorhergehenden Ansprüchen, wobei der Zahlungsprozessorcomputer in weniger als allen Fällen die Annahmemitteilung unter Umgehung des ersten und/oder zweiten Vermittlerservers und durch Befragung des Halters der spezifischen Zahlungskarten via mobile Endstelle verifiziert.
Das Verfahren nach Anspruch 6, wobei der Zahlungsprozessorcomputer einige oder alle der folgenden Parameter zur Bestimmung der Fälle verwendet, in denen die die Annahmemitteilung unter Umgehung des ersten und/oder zweiten Vermittlercomputers verifiziert wird: – eine zufällige Auswahl von allen Transaktionen; – alle Transaktionen, deren Wert eine vorgegebene Schwelle übersteigt; – eine zufällige Auswahl von Transaktionen oberhalb eines vorgegebene Schwellwerts; – eine Anzahl erster Transaktionen für den Vermittler, Benutzer und/oder Dienstanbieter; – eine Anzahl erster Transaktionen für eine Kombination von Benutzer und Diensteanbieter.
Das Verfahren nach Anspruch 6 oder 7, wobei der Zahlungsprozessorcomputer einige oder alle der folgenden Parameter zur Bestimmung der Fälle verwendet, in denen die die Annahmemitteilung unter Umgehung des ersten und/oder zweiten Vermittlercomputers verifiziert wird: – Zuweisen eines ersten anfänglichen Vertrauenswertes zu einer Vielzahl von Haltern von Bezahlkarten; – Zuweisen eines zweiten anfänglichen Vertrauenswertes zu einer Vielzahl von Haltern von Bezahlkarten; – Zuweisen eines dritten anfänglichen Vertrauenswertes zu dem ersten und/oder zweiten Vermittlercomputer; – Erneuern einiger oder aller anfänglichen Vertrauenswerte als Antwort auf das Erhalten einer Mitteilung von erfolgreich beendeten Transaktionen, an denen einer der Halter der Bezahlkarten, der Diensteanbieter und/oder der Vermittlerserver, respektive, beteiligt waren.
Das Verfahren nach einem der vorhergehenden Ansprüchen, weiter umfassend das Assoziieren und Durchsetzen von mindestens einer Begrenzung mit dem Token, worin die mindestens eine Begrenzung mindestens eines der Lebensdauer des Tokens und des finanziellen Werts der Transaktionen, die mittels des Tokens vorgenommen werden, begrenzt.
Das Verfahren nach einem der vorhergehenden Ansprüchen, wobei der Zahlungsprozessorcomputer und der erste Vermittlerserver und der zweite Vermittlerserver Spezifikationen die durch das Payment Card Industry Security Standards Council ausgegeben sind, erfüllt.
Das Verfahren nach einem der vorhergehenden Ansprüchen, wobei der Zahlungsprozessorcomputer und der erste Vermittlerserver oder der zweite Vermittlerserver Spezifikationen die durch das Payment Card Industry Security Standards Council ausgegeben sind, erfüllt, während der zweite Vermittlerserver beziehungsweise der erste Vermittlerserver außerhalb dieser Spezifikationen arbeitet.
Das Verfahren nach einem der vorhergehenden Ansprüchen, wobei die erste Anforderung von einer ersten Endstelle empfangen wird, und eine zweite Endstelle anzeigt, worin die erste Endstelle und die zweite Endstelle unterschiedliche Authentifizierungsinformationen verwenden, unabhängig davon, ob die erste Endstelle und zweite Endstelle sich in getrennten körperlichen Geräten befinden, oder sich ein gemeinsames körperliches Gerät teilen.
Das Verfahren nach einem der vorhergehenden Ansprüchen, wobei ein Zusammenhang besteht, zwischen Diensten des ersten Diensteanbieters und Diensten des zweiten Diensteanbieters.
Ein Verfahren umfassend die folgenden Schritte an einem Vermittlerserver (9-300), der konfiguriert ist, um Transaktionen zu managen, die zu einem oder mehreren Diensten in Beziehung stehen, die durch einen oder mehrere Diensteanbieter (9-400, 9-401–9-40n), die einen ersten Diensteanbieter (9-401) und eine zweiten Diensteanbieter (9-402) umfassen, bereitgestellt werden und durch einen oder mehrere Zahlungskarten (9-610) zu zahlen sind: – Empfangen (9-26) einer Annahmemitteilung, die anzeigt, dass ein Halter einer speziellen von der einen oder den mehreren Zahlungskarten eine mobile Endstelle über ein Mobilnetzwerk betrieben hat, um sich wiederholende Zahlungen an den ersten Diensteanbieter (9-401) zu autorisieren; – Senden (9-46) einer Anforderung an die mobile Endstelle, die durch den Halter der speziellen Zahlungskarte betrieben wird, wobei die Anforderung eine Erlaubnis anfordert, um zweite sich wiederholende Zahlungen an den zweiten Diensteanbieter zu autorisieren, wobei die zweiten sich wiederholenden Zahlungen durch eine zweite Zahlungskarte von der einen oder den mehreren Zahlungskarten zu zahlen sind, und wobei die erste und zweite Zahlungskarte dieselbe Zahlungskarte oder verschiedene Zahlungskarten sein können; – Empfangen (9-48) einer Bestätigung von der mobilen Endstelle, die durch den Halter der Zahlungskarten betrieben wird, dass der zweite Diensteanbieter Dienste an den Halter der Zahlungskarten vorschlagen kann; – Übertragen (9-50) dieser Bestätigung zu einem Zahlungsprozessorcomputer (9-200); – Empfangen (9-56) eines Tokens von dem Zahlungsprozessorcomputer (9-200) und Speichern des Tokens, wobei das Token den zweiten Diensteanbieter (9-402) identifiziert, wobei das Token die zweite Zahlungskarte nicht umfassend identifizieren kann, sondern die zweite Zahlungskarte innerhalb von Zahlungskarten identifiziert, die an einen Halter der Zahlungskarten ausgegeben sind.
Das Verfahren nach Anspruch 14, wobei der Vermittlerserver die mobile Endstelle, die von dem Halter der spezifischen Bezahlkarte betrieben wird, unter Verwendung einer nicht-vorhersagbaren Antwortadresse zum Zusenden der Mitteilung authentifiziert.
Das Verfahren nach Anspruch 14 oder 15, wobei der Vermittlerserver eine mehr-dimensionale Datenstruktur zum Verwalten von Dienstangeboten von verschiedenen Diensteanbietern an jedem der ein oder mehreren mobilen Endstellen verwendet, und wobei der Vermittlerserver die Dienstangebote von verschiedenen Diensteanbietern durch Variieren einer Antwortadresse für die Zusendung der Mitteilung identifiziert.
Das Verfahren nach Anspruch 14, 15 oder 16, wobei der Vermittlerserver eine mehr-dimensionale Datenstruktur zum Verwalten von verschiedenen Phasen von mindestens einem Dienstangebot von mindestens einem Diensteanbieter an mindestens eine mobile Endstelle verwendet, und wobei der Vermittlerserver die verschiedenen Phasen durch Variieren einer Antwortadresse für die Zusendung der Mitteilung identifiziert.
Das Verfahren nach einem der Ansprüche 14–17, wobei ein Zusammenhang besteht, zwischen Diensten des ersten Diensteanbieters und Diensten des zweiten Diensteanbieters.
Ein Verfahren umfassend folgenden Handlungen bei dem Diensteanbietercomputer (9-400; 9-401; 9-40n): – Empfangen (9-20) von Information, die anzeigt, dass ein Halter einer speziellen Zahlungskarte sich wiederholende Zahlungen für einen oder mehrere Dienste autorisieren kann, die durch einen Diensteanbieter bereitgestellt werden, der für den Diensteanbietercomputer verantwortlich ist; – Senden (9-22) eines Vorschlags für einen Dienst zu einem Vermittlerserver, der sich wiederholende Zahlungen nach sich zieht, die durch die spezielle Zahlungskarte zu zahlen sind; – Empfangen (9-30) einer Annahmemitteilung von dem Vermittlerserver, die anzeigt, dass der Halter der speziellen Zahlungskarte eine mobile Endstelle über ein Mobilnetzwerk verwendet hat, um sich wiederholende Zahlungen an den speziellen Diensteanbieter zu autorisieren.
Ein Zahlungsprozessorcomputer, der konfiguriert ist, um Transaktionen zu managen, die in Beziehung zu einem oder mehreren Diensten stehen, die durch Diensteanbieter bereitgestellt werden, die einen ersten Diensteanbieter und einen zweiten Diensteanbieter umfassen, wobei die Transaktionen durch eine oder mehrere Zahlungskarten zu zahlen sind, der Zahlungsprozessorcomputer umfassend: – Mittel zum Verarbeiten einer ersten Anforderung, erste sich wiederholende Zahlungen an den ersten Diensteanbieter zu autorisieren, wobei die sich wiederholenden Zahlungen durch eine erste Zahlungskarte der einen oder mehreren Zahlungskarten zu zahlen sind; – Mittel zum Empfangen einer zweiten Anforderung, zweite sich wiederholende Zahlungen an den zweiten Diensteanbieter zu autorisieren, wobei die zweiten sich wiederholenden Zahlungen durch eine zweite Zahlungskarte der einen oder mehreren Zahlungskarten zu zahlen sind, und wobei die erste und zweite Zahlungskarte dieselbe Zahlungskarte oder gesonderte Zahlungskarten sein können; – Mittel zum Verwenden eines ersten Vermittlerservers, um eine Bestätigung von dem Halter der Zahlungskarten zu erhalten, dass der zweite Diensteanbieter Dienste dem Halter der Zahlungskarten vorschlagen kann, ansprechend auf die zweite Anforderung; – Mittel zum Erzeugen eines Tokens, das den zweiten Diensteanbieter identifiziert, wobei das Token die zweite Zahlungskarte nicht umfassend identifiziert, sondern die zweite Zahlungskarte innerhalb Zahlungskarten identifiziert, die an einen Halter der Zahlungskarten ausgegeben sind; – Mittel zum Senden des erzeugten Tokens zu einem zweiten Vermittlerserver; – Mittel zum Empfangen einer Annahmemitteilung von dem ersten oder zweiten Vermittlerserver, die anzeigt, dass der Halter der speziellen Zahlungskarte eine mobile Endstelle über ein Mobilnetzwerk verwendet hat, um die zweiten sich wiederholenden Zahlungen an den zweiten Diensteanbieter zu autorisieren, wobei der erste Vermittlerserver und der zweite Vermittlerserver derselbe Vermittlerserver oder verschiedene Vermittlerserver sein können.
Der Zahlungsprozessorcomputer nach Anspruch 20, wobei der Zahlungsprozessorcomputer dazu konfiguriert ist den ersten oder zweiten Vermittlerserver, zu veranlassen, das Token zu benutzen, um abzufragen, ob der Halter der spezifischen Zahlung wünscht, widerkehrende Zahlungen an den spezifischen Diensteanbieter zu autorisieren.
Der Zahlungsprozessorcomputer nach Anspruch 20 oder 21, wobei der Zahlungsprozessorcomputer und der erste Vermittlerserver und der zweite Vermittlerserver Spezifikationen die durch das Payment Card Industry Security Standards Council ausgegeben sind, erfüllt.
Das Verfahren nach Anspruch 20, 21 oder 22, wobei der Zahlungsprozessorcomputer und der erste Vermittlerserver oder der zweite Vermittlerserver Spezifikationen die durch das Payment Card Industry Security Standards Council ausgegeben sind, erfüllt, während der zweite Vermittlerserver beziehungsweise der erste Vermittlerserver außerhalb dieser Spezifikationen arbeitet.
Das Verfahren nach einem der Ansprüche 20–23, wobei ein Zusammenhang besteht, zwischen Diensten des ersten Diensteanbieters und Diensten des zweiten Diensteanbieters.
Ein Vermittlerserver, der konfiguriert ist, um Transaktionen zu managen, die zu einem oder mehreren Diensten in Beziehung stehen, die durch einen oder mehrere Diensteanbieter, die einen ersten Diensteanbieter und eine zweiten Diensteanbieter umfassen, bereitgestellt werden und durch einen oder mehrere Zahlungskarten zu zahlen sind, der Vermittlerserver umfassend: – Mittel zum Empfangen einer Annahmemitteilung, die anzeigt, dass ein Halter einer speziellen von der einen oder den mehreren Zahlungskarten eine mobile Endstelle über ein Mobilnetzwerk betrieben hat, um sich wiederholende Zahlungen an den ersten Diensteanbieter zu autorisieren; – Mittel zum Senden einer Anforderung an die mobile Endstelle, die durch den Halter der speziellen Zahlungskarte betrieben wird, wobei die Anforderung eine Erlaubnis anfordert, um zweite sich wiederholende Zahlungen an den zweiten Diensteanbieter zu autorisieren, wobei die zweiten sich wiederholenden Zahlungen durch eine zweite Zahlungskarte von der einen oder den mehreren Zahlungskarten zu zahlen sind, und wobei die erste und zweite Zahlungskarte dieselbe Zahlungskarte oder verschiedene Zahlungskarten sein können; – Mittel zum Empfangen einer Bestätigung von der mobilen Endstelle, die durch den Halter der Zahlungskarten betrieben wird, dass der zweite Diensteanbieter Dienste an den Halter der Zahlungskarten vorschlagen kann; – Mittel zum Übertragen dieser Bestätigung zu einem Zahlungsprozessorcomputer; – Mittel zum Empfangen eines Tokens von dem Zahlungsprozessorcomputer und Speichern des Tokens, wobei das Token den zweiten Diensteanbieter identifiziert, wobei das Token die zweite Zahlungskarte nicht umfassend identifizieren kann, sondern die zweite Zahlungskarte innerhalb von Zahlungskarten identifiziert, die an einen Halter der Zahlungskarten ausgegeben sind.
Der Vermittlerserver nach Anspruch 25, wobei der Vermittlerserver konfiguriert ist, zum Authentifizieren der mobile Endstelle, die von dem Halter der spezifischen Bezahlkarte betrieben wird, unter Verwendung einer nicht-vorhersagbaren Antwortadresse zum Zusenden der Mitteilung.
Der Vermittlerserver nach Anspruch 25 oder 26, wobei der Vermittlerserver konfiguriert ist, eine mehr-dimensionale Datenstruktur zum Verwalten von Dienstangeboten von verschiedenen Diensteanbietern an jedem der ein oder mehreren mobilen Endstellen zu verwenden, und wobei der Vermittlerserver die Dienstangebote von verschiedenen Diensteanbietern durch Variieren einer Antwortadresse für die Zusendung der Mitteilung identifiziert.
Der Vermittlerserver nach Anspruch 25, 26 oder 27, wobei der Vermittlerserver konfiguriert ist, eine mehr-dimensionale Datenstruktur zum Verwalten von verschiedenen Phasen von mindestens einem Dienstangebot von mindestens einem Diensteanbieter an mindestens eine mobile Endstelle zu verwenden, und wobei der Vermittlerserver die verschiedenen Phasen durch Variieren einer Antwortadresse für die Zusendung der Mitteilung identifiziert.
Der Vermittlerserver nach einem der Ansprüche 25 – 28, wobei ein Zusammenhang besteht, zwischen Diensten des ersten Diensteanbieters und Diensten des zweiten Diensteanbieters.
Ein Diensteanbietercomputer umfassend: – Mittel zum Empfangen von Information, die anzeigt, dass ein Halter einer speziellen Zahlungskarte sich wiederholende Zahlungen für einen oder mehrere Dienste autorisieren kann, die durch einen Diensteanbieter bereitgestellt werden, der für den Diensteanbietercomputer verantwortlich ist; – Mittel zum Senden eines Vorschlags für einen Dienst zu einem Vermittlerserver, der sich wiederholende Zahlungen nach sich zieht, die durch die spezielle Zahlungskarte zu zahlen sind; – Mittel zum Empfangen einer Annahmemitteilung von dem Vermittlerserver, die anzeigt, dass der Halter der speziellen Zahlungskarte eine mobile Endstelle über ein Mobilnetzwerk verwendet hat, um sich wiederholende Zahlungen an den speziellen Diensteanbieter zu autorisieren.
Ein konkreter Computerprogrammträger, der Computerprogramminstruktionen realisiert, ausführbar in einem Vermittlerserver, der konfiguriert ist, um Transaktionen zu managen, die zu einem oder mehreren Diensten in Beziehung stehen, die durch Diensteanbieter, die einen ersten Diensteanbieter und eine zweiten Diensteanbieter umfassen, bereitgestellt werden, wobei die Transaktionen durch eine oder mehrere Zahlungskarten zu zahlen sind; wobei die Ausführung des Computerprogrammanweisungen die Folgenden Schritte bei einem Vermittlerserver verursacht: – Empfangen einer Annahmemitteilung, die anzeigt, dass ein Halter einer speziellen von der einen oder den mehreren Zahlungskarten eine mobile Endstelle über ein Mobilnetzwerk betrieben hat, um sich wiederholende Zahlungen an den ersten Diensteanbieter zu autorisieren; – Senden einer Anforderung an die mobile Endstelle, die durch den Halter der speziellen Zahlungskarte betrieben wird, wobei die Anforderung eine Erlaubnis anfordert, um zweite sich wiederholende Zahlungen an den zweiten Diensteanbieter zu autorisieren, wobei die zweiten sich wiederholenden Zahlungen durch eine zweite Zahlungskarte von der einen oder den mehreren Zahlungskarten zu zahlen sind, und wobei die erste und zweite Zahlungskarte dieselbe Zahlungskarte oder verschiedene Zahlungskarten sein können; – Empfangen einer Bestätigung von der mobilen Endstelle, die durch den Halter der Zahlungskarten betrieben wird, dass der zweite Diensteanbieter Dienste an den Halter der Zahlungskarten vorschlagen kann; – Übertragen dieser Bestätigung zu einem Zahlungsprozessorcomputer; – Empfangen eines Tokens von dem Zahlungsprozessorcomputer und Speichern des Tokens, wobei das Token den zweiten Diensteanbieter identifiziert, wobei das Token die zweite Zahlungskarte nicht umfassend identifizieren kann, sondern die zweite Zahlungskarte innerhalb von Zahlungskarten identifiziert, die an einen Halter der Zahlungskarten ausgegeben sind.