Die vorliegende Erfindung betrifft ein Verfahren zum Betrieb eines Zugangsberechtigungssystems.

Insbesondere betrifft die Erfindung Zugangsberechtigungssysteme, die mit elektronischen Medien arbeiten, welche unter dem Stichwort Smart Card oder e-Ticketing bekannt sind. Beispiele sind Systeme für Parkraumbewirtschaftung, Zugangssysteme für Sport-, Kultur- und Freizeitanlagen, Fahrausweissysteme und ähnliche.

Man unterscheidet bei diesen Systemen zwischen karten basierten und kontobasierten Systemen. Bei den kartenbasierten Systemen sind wesentliche Daten, welche die Benutzung des Zugangssystems ermöglichen und registrieren, auf der Karte gespeichert. Im Wesentlichen ist die Zugangsberechtigung elektronisch auf die Karte geschrieben. Beim Betreten eines System-Bereiches wird anhand dieser auf der Karte vorhanden Daten und anhand des Tarifmodells, das in einem Eingangskontrollgerät abgebildet ist, systemseitig beurteilt, ob die Karte zur Nutzung des Systems berechtigt, und das Ergebnis dem Benutzer angezeigt. Typischerweise wird dabei auch auf die Karte zurückgeschrieben. Kartenbasierte Systeme können mit proprietären Karten ausgeführt werden, die oft nur bei einem Betreiber gültig sind, oder mit standardisierten Karten, die für mehrere Betreiber gelten. Beispiele für standardisierte kartenbasierte Systeme sind aus dem Bereich der Fahrausweise das britische ITSO Scheme oder das deutsche (((e- Ticketing, früher auch als VDV-Kernapplikation bekannt. Aufgrund der Tatsache, dass nur dezidierte Karten mit bestimmten Dateninhalten und Sicherheitsstandards akzeptiert werden, werden diese Systeme„Closed Loop" genannt. Ein koniobasiertes„Open Loop" oder„Open Payment" System unterscheidet sich von karten basierten Systemen in drei Prinzipien:

• Die Karte, mit der sich der Nutzer Zugang zum System verschafft, ist nur ein Identifikationsmedium. Beim Zugang zum System identifiziert sich der Benutzer an einem Endgerät (z.B. Durchgangssperre, Entwerter, Buskasse, Einfahrtschranke) mit diesem Medium, welches einen maschinenlesbaren systemweit eindeutigen Kenner enthält. Es werden systembedingt keine Informationen auf das Medium zurückgeschrieben. Gleiches gilt, falls das Identifikationsmedium zum Verlassen des Systems an einem Endgerät benutzt wird.

• Alle Informationen zum Identifikationsmedium und zu seiner Benutzung werden im Hintergrundsystem {"back office") des Zugangsberechtigungssystems in einem Konto vorgehalten und ausgewertet. Insbesondere alle Preisberechnungen für die Benutzung des Systems sowie die nachgelagerte bargeldlose Verrechnung werden im Hintergrundsystem durchgeführt.

• Potenziell können sehr unterschiedliche Arten von Identifikationsmedien in einem solchen System benutzt werden, zum Beispiel vom Betreiber eigens herausgegebene Smart Cards, Kreditkarten, Studentenausweise oder andere Kartentypen, die als technisch auslesbare Identifikationsmedien in Frage kommen. Insbesondere können alle Medien genutzt werden, die nach ISO 14443 kontaktlos kommunizieren, auch in Formaten, die nicht als Karten ausgeführt sind, sondern z.B. als Schlüsselanhänger, Ausweis, Smart-Phone oder in anderen Formaten. Aber auch alle irgendwie maschinell auslesbaren Datenträger wie Magnetkarten, 1- und 2-dimensionale Strichcodes sind als Identifikationsmedien möglich.

Da das kontobasierte System auf jegliche spezifische Dateninhalte der Identifikationsmedien verzichtet, kann jeder Datenträger, der technisch von den Endgeräten gelesen werden kann und der systemweit eindeutig identifiziert werden kann, als Medium genutzt werden. Darum werden diese Systeme auch„Open Loop" oder„Open Payment" Systeme genannt.

Auf diesen Prinzipien basierend werden verschiedene Betriebsmodelle für ein Open Payment System unterschieden, welche von den Tarifstrukturen, akzeptierten Karten und Zahlmethoden abhängen. Wesentliche Betriebsparameter sind:

• Art der Nutzungsberechtigung: Muss eine Nutzungsberechtigung vor Eintritt ins System gekauft und dem Konto gutgeschrieben werden, oder kann der Preis nach Ende der Nutzung ermittelt werden?

• Welche Zahlmethoden sind verfügbar, wie zum Beispiel Bargeld, Girokarten, Kreditkarten, Bankeinzug oder Überweisung?

• In welchen Fällen ist die Registrierung eines Nutzers nötig? Diese kann z.B. nötig werden, sobald Mehrfach- oder Zeitkarten (z.B. Monatskarten) oder Vergünstigungen (z.B. Behindertenausweis) für den Zugang zum System benutzt werden.

• Wie stimmt man die Benutzbarkeit des Systems (Einfachheit der Benutzung, Fehlertoleranz des Systems) mit dem kommerziellen Risiko (Missbrauch und Zahlungsausfall) ab?

Der letzte Punkt betrifft die Nutzerakzeptanz des Systems. Es besteht der Bedarf, die Benutzbarkeit eines Open Payment Systems mit dem kommerziellen Risiko in eine sinnvolle Balance zu bringen.

Ein technisches Problem der Open Payment Verfahren im Stand der Technik besteht darin, dass sie auf schnelle Datenzugriffe vom Endgerät (z.B. Durchgangssperre, Entwerter, Buskasse, Einfahrtschranke) zum Hintergrundsystem angewiesen sind, denn wenn der Nutzer sich mit seinem Identifikationsmedium am Endgerät identifiziert, muss das System in Echtzeit am Hintergrundsystem die Gültigkeit des Mediums abfragen und eine Antwort erhalten. Echtzeit bedeutet dabei gemäß gängigen Anforderungen, dass zum Beispiel eine Durchgangssperre binnen 500 Millisekunden nach Lesen eines Mediums öffnen soll.

Das bedeutet im Bezug auf das Netzwerk und das Hintergrundsystem, dass sie

• praktisch immer verfügbar sein müssen

• sehr kurze Antwortzeiten garantieren müssen • viele gleichzeitige Zugriffe auf das Hintergrundsystem ermöglichen müssen.

Für reale Netzwerke mit einigen hundert oder einigen tausend Endgeräten ist das nicht lückenlos erfüllbar, insbesondere dann, wenn auch mobile Endgeräte eingebunden sind, die über Mobilfunknetze mit dem Hintergrundsystem verbunden sind.

Im Stand der Technik wird deswegen der Ansatz gewählt, bestimmte Gültigkeitsdaten für die Identifikationsmedien, welche die Endgeräte in Echtzeit vom Hintergrundsystem abfragen müssten, in kurzen Zeitabständen innerhalb des gesamten Systems per Broadcasting über alle Endgeräte zu verteilen. Die Gültigkeitsabfrage für ein Medium erfolgt damit nicht mehr online vom Endgerät zum Hintergrundsystem, sondern lokal im Endgerät anhand der dort gespeicherten Gültigkeitsdaten. Damit kann das Endgerät auch die geforderten schnellen Antwortzeiten einhalten, da es für die Autorisierung eines Mediums ausschließlich lokal arbeitet.

Im Stand der Technik wird dazu in WO 2012/088582 für ein Fahrausweissystem der Ansatz gewählt, dass Registrierungsdatensätze für ein Identifikationsmedium von 153 bit Länge (gemäß WO 2012/088582, Table 1 ) vom Hintergrundsystem an alle Endgeräte verteilt werden. Weiter werden für jeden Eintritt in das System Validierungsdatensätze von 251 bit Länge (gemäß WO 2012/088582, Table 2) von dem Endgerät, an welchem der Eintritt in das System erfolgte, an das Hintergrundsystem verteilt und von dort an alle Endgeräte im Broadcast-Verfahren weitergeleitet. Das Endgerät, an dem das Medium das System wieder verlässt, kennt damit auch die Eintrittsdaten zu dieser Fahrt und kann den Fahrpreis lokal berechnen. Dieser Ansatz hat systeminhärent den Nachteil, dass für jede Transaktion ein Datensatz von 251 bit Länge über alle Geräte verteilt wird. Schon für kleine Systeme summiert sich das laut der Beschreibung in WO 2012/088582 zu einem Datenvolumen von 610 GByte / Monat und für große Systeme zu 170.000 GByte / Monat (gemäß WO 2012/088582, Table 4).

Ausgehend vom vorbeschriebenen Stand der Technik liegt der vorliegenden Erfindung die A u f g a b e zugrunde, die erforderliche regelmäßige systemweite Versendung großer Datenmengen zu vermeiden und trotzdem kurze Autorisierungszeiten für Open Payment- Identifikationsmedien in Zugangsberechtigungssystemen zu gewährleisten.

Zur technischen L ö s u n g der vorgenannten Aufgabe wird mit der Erfindung ein Verfahren mit den Merkmalen des Anspruches 1 vorgeschlagen. Weitere Vorteile und Merkmale der Erfindung ergeben sich aus den Unteransprüchen.

Gemäß der Erfindung wird ein Zugangsberechtigungssystem betrieben, welches System ein Rechnernetzwerk umfasst, mit wenigstens einem ein Hintergrundsystem bildenden Zentralrechner und wenigstens einem mit diesem über ein Datennetzwerk verbundenen Rechner in wenigstens einem in einem Zugangsbereich angeordneten Endgerät, weiches Endgerät wenigstens zum Auslesen von Identifikationsmedien mit jeweils einem systemweit eindeutigen maschinenlesbaren Kenner ausgelegt ist. Erfindungsgemäß wird im Hintergrundsystem eine eine Positiv-/Negativliste darstellende Datentabelle geführt. In dieser ist zu jedem für den Systembetrieb notwendigen Kenner ein die Gültigkeit bzw. die Ungültigkeit repräsentierender Wert zugeordnet. Die Positiv-/Negativliste wird an Endgeräte übermittelt und von diesen gespeichert. Von einem Endgerät wird nach Auslesen eines Kenners anhand der Positiv-/Negativliste der Gültigkeitszustand des zugehörigen Identifikationsmediums bestimmt und über eine Zugangsgewährung entschieden.

Das erfindungsgemäße Verfahren hat den Vorteil, ein Open Payment Zugangsberechtigungssystem so zu gestalten, dass es gleichzeitig folgende Einsatzbedingungen erfüllt:

• Einfachheit: Die Gültigkeit eines einem Endgerät präsentierten Identifikationsmediums wird ausschließlich gegen lokal gespeicherte Positiv- und/oder Negativlisten geprüft. Das Endgerät führt keine weiteren Prüfungen oder Berechnungen aus und kann dem Nutzer das Ergebnis der Prüfung unmittelbar mitteilen. Insbesondere nimmt das Endgerät keinerlei Tarifberechnungen vor.

• Schnelligkeit: Für ein Identifikationsmedium, mit dem sich der Nutzer Zugang zum System verschaffen will, wird an einem Endgerät binnen weniger als 500 Millisekunden lokal entschieden und an den Nutzer ausgegeben, ob der Zugang gewährt oder verweigert wird.

• Robustheit: Da eine Transaktion am Endgerät nur mit lokalen Daten durchgeführt wird, ist es für das fragliche Endgerät bei der Transaktion nicht relevant, ob es eine Datenverbindung zum Hintergrundsystem hat oder nicht. • Verstetigung des Datenverkehrs: Verglichen mit solchen Verfahren, die immer online arbeiten, ist beim erfindungsgemäßen Verfahren die mittlere Netzwerklast etwa gleich, da auch das erfindungsgemäße Verfahren die Transaktionsdaten von den Endgeräten an das Hintergrundsystem senden muss.

Da im erfindungsgemäßen System das Endgerät jedoch nicht in Echtzeit (also nicht während der Transaktion) mit dem Hintergrundsystem kommunizieren muss, kann der Datenverkehr zwischen Endgeräten und Hintergrundsystem verstetigt werden. Die Lastspitzen im Datennetzwerk werden deutlich geringer, und die Netzwerkkapazität kann mit weniger Reserve näher an der Durchschnittslast ausgelegt werden.

• Verringerung des Datenvolumens im Netzwerk: Verglichen mit Verfahren, die immer Transaktionsdaten im Broadcasting-Verfahren an alle Endgeräte verteilen, ist das im Netzwerk verteilte Datenvolumen beim erfindungsgemäßen Verfahren deutlich geringer.

Wenn zum Beispiel in einem Fahrausweissystem im Stand der Technik gemäß WO 2012/088582 eine Monatskarte an 20 Arbeitstagen je viermal benutzt wird (zwei Einstiege und zwei Ausstiege pro Tag), dann entstehen in einem Monat 80 Transaktionen zu je 251 bit Länge, die an alle Endgeräte im System per Broadcasting verteilt werden. Das verteilte Datenvolumen für eine Monatskarte liegt in der Größenordnung von monatlich 20.000 bit.

Wenn ein Nutzer in einem erfindungsgemäßen Fahrausweissystem zu seinem Identifikationsmedium eine Monatskarte kauft, dann setzt das Hintergrundsystem dieses Medium auf die Positivliste und verteilt diese Änderung einmal an alle Endgeräte. Das verteilte Datenvolumen liegt in der Größenordnung von einmalig 64 bit. Falls die Monatskarte im Abonnement ohne Unterbrechung verlängert wird, fällt gar kein weiterer Datenverkehr an, und der Eintrag auf der Positivliste bleibt einfach erhalten.

• Gleitende Risikominimierung: Solange die Endgeräte kontinuierlich und zeitnah mit Änderungen der Positiv- und Negativlisten aktualisiert werden, werden sie immer den Kenntnisstand des Hintergrundsystems haben und die richtige Entscheidung über Akzeptanz oder Zurückweisung eines Identifikationsmediums treffen.

Wenn ein Endgerät die Datenverbindung zum Hintergrundsystem verliert, dann wird die Richtigkeit seiner Entscheidungen nicht sofort zu Null, sondern die Aktualität der lokalen Positiv- und Negativlisten driftet langsam vom Stand im Hintergrundsystem ab, so lange bis die Datenverbindung wieder hergestellt ist und die lokalen Listen aktualisiert sind.

Der Verlust einer Datenverbindung zwischen Endgerät und Hintergrundsystem vermindert also langsam die Genauigkeit der Entscheidungen am betroffenen Endgerät; die Entscheidungsfähigkeit als solche bleibt für das Endgerät aber erhalten.

Das erfindungsgemäße Verfahren bewirkt die Erreichung eines ausgewogenen Verhältnisses zwischen einerseits dem schnellen und robusten Antwortverhalten der Endgeräte und andererseits einem minimierten finanziellen Risiko für den Betreiber. Im Wesentlichen vereint das Verfahren drei Prinzipien:

• Die Gültigkeit eines einem Endgerät präsentierten Identifikationsmediums wird ausschließlich gegen lokal gespeicherte Positiv- und/oder Negativlisten geprüft.

Das Endgerät führt keine weiteren Prüfungen oder Berechnungen aus und kann dem Nutzer das Ergebnis der Prüfung unmittelbar mitteilen. Insbesondere nimmt das Endgerät keinerlei Tarifberechnungen vor. Für ein als gültig geprüftes Medium zeichnet das Endgerät einen Transaktionsdatensatz auf und sendet diesen zeitnah - typischerweise binnen Minuten - an das Hintergrundsystem.

• Die Gültigkeit eines Identifikationsmediums wird nur im Hintergrundsystem bestimmt und kann auch nur dort geändert werden.

Dies geschieht auf Basis der eingegangenen Transaktionsdaten und einer entweder erfolgreichen oder erfolglosen Verrechnung.

• Dann - und nur dann - wenn sich die Gültigkeit eines Identifikationsmediums ändert, erfolgt eine Änderung an der zentralen Positiv- oder Negativliste, und nur diese Änderung muss an die Endgeräte verteilt und dort gespeichert werden.

In der nachfolgenden Tabelle wird anhand dreier beispielhaft genannter verschiedener Arten von Identifikationsmedien deutlich, in welcher Weise die Positiv- und Negativlisten in einem erfindungsgemäßen System genutzt werden, die hier gezeigten Anwendungsfälle sind typisch und beispielhaft, aber nicht abschließend. Die Änderung der Gültigkeit eines Mediums ist dabei die Ausnahme, so dass die üstenänderungen, die im System an die Endgeräte verteilt werden müssen, kein großes Kommunikationsaufkommen verursachen:

[kein Vorgang: Karte dem

gültig

System bisher nicht bekannt]

Kontaktlose Erfolgreiche Verrechnung von

gültig

Kreditkarte Nutzungen

(Open Payment Erfolglose Verrechnung von

wird ungültig Eintrag Medium) Nutzungen

Begleichung offener

wird gültig Löschung Rechnungen

Kauf des Mediums ungültig

Kauf einer Monatskarte ungültig

Beginn des Monats wird gültig Eintrag

Proprietäre

Kauf einer 2. Monatskarte gültig

Karte

Beginn des 2. Monats gültig

des Betreibers

Ende des 2. Monats wird ungültig Löschung

Kauf einer 3. Monatskarte wird gültig Eintrag

Karte„verloren" gemeldet wird ungültig Löschung

Rechnungen

Eine bevorzugte Ausführungsform ist gekennzeichnet durch das schnelle Aktualisieren und Verbreiten von Positiv- und Negativlisten, was erfindungsgemäß in folgenden Schritten durchgeführt wird:

Die erfolgreiche Benutzung eines Identifikationsmediums wird von den Endgeräten als Transaktion aufgezeichnet, und die Transaktionsdaten werden an das Hintergrundsystem gesandt. Diese Transaktionsdaten kennzeichnen mindestens, wann und wo das Medium das System betreten hat; ein weiterer Transaktionsdatensatz zur Kennzeichnung, wann und wo das Medium das System verlassen hat, kann bevorzugt dann erzeugt werden, wenn das Verlassen durch eine Durchgangssperre oder Ausfahrtschranke erfolgt. Es gibt aber auch Systeme, deren Architektur und Tarifgestaltung eine Registrierung des Austritts nicht erfordern. Im Hintergrundsystem stellt ein Prozess für Transaktionshandhabung und Tarifberechnung aus den Transaktionsdaten eine Nutzung zusammen und vergleicht diese Nutzung mit den Berechtigungen, die auf dem zum Medium gehörigen Konto abgelegt sind. Wenn keine Berechtigung vorliegt, versucht ein Abrechnungsprozess am Hintergrundsystem die Nutzung gegen das zu dem Identifikationsmedium hinterlegte Zahlmedium (Giro- oder Kreditkartennummer) zu verrechnen. Kann die Nutzung weder mit einer hinterlegten Berechtigung noch mit einem hinterlegten Zahlmedium verrechnet werden, so wird das Identifikationsmedium auf die Negativliste gesetzt.

Jedes Endgerät erhält per Datenfernübertragung vom Hintergrundsystem Neueinträge und Löschungen - also inkrementelle Updates - für die Positiv- und Negativlisten, sobald am Hintergrundsystem Änderungen an diesen Listen vorgenommen werden. Als Variante ist es möglich, dass jedes Endgerät seinen letzten Aktualisierungsstand bezüglich der Positiv- und Negativlisten kennt und zyklisch beim Hintergrundsystem die seitdem vorliegenden Änderungen abruft. Dies hat den Vorteil, den Datenverkehr zwischen dem Hintergrundsystem und den Endgeräten gleichmäßiger zu verteilen. Als weitere Variante ist es denkbar, in bestimmten Zeitabständen, zum Beispiel einmal täglich oder einmal wöchentlich, jeweils eine vollständige aktuelle Negativ- und Positivliste an alle Feldgeräte zu senden, damit eine durchgängige Datenkonsistenz im System sichergestellt ist.. Als weitere Variante ist es denkbar, für individuelle Geräte oder Gerätegruppen eigens anpasste Positiv- und Negativlisten einzurichten, so dass der Kommunikationsaufwand - im Sinne von Volumen und Häufigkeit der Kommunikation - nochmals optimiert werden kann und/oder bestimmte Tarifmodelle mittels der angepassten Positiv- und Negativlisten abgebildet werden. Letzteres kann zum Beispiel in einem zonenbasierten Fahrausweissystem der Fall sein.

Jedenfalls hat als Resultat dieser Vorgehensweise jedes Endgerät eine lokale Kopie der aktuellen Positiv- und Negativliste gespeichert, gegen die es ein vom Benutzer präsentiertes Identifikationsmedium prüft und lokal darüber entscheidet, ob das Medium akzeptiert oder zurückgewiesen wird.

Die Positiv- und Negativlisten werden dabei wie folgt genutzt:

• Positiv- Listen enthalten die Kenner der Medien, die dem System bekannt sind, das heißt vom Betreiber herausgegebene proprietäre Karten und im System registrierte Identifikationsmedien.

Beispiel: Wenn ein Endgerät ein Identifikationsmedium präsentiert bekommt und es als das Medium proprietäre Karte erkennt, wird das Gerät auf seiner lokal gespeicherten Positivliste nach dieser Karte suchen und die Karte bei erfolgreicher Suche akzeptieren.

• Negativ-Listen enthalten die Kenner jener Open-Payment-Medien, die eine negative Benutzerhistorie im Zugangssystem haben.

Beispiel: Eine kontaktlose Kreditkarte, die im erfindungsgemäßen System genutzt wurde und für die keine Verrechnung durchgeführt werden konnte, wird auf die Negativliste gesetzt - zumindest so lange, bis die offene Forderung beglichen ist. Wenn ein Endgerät ein Identifikationsmedium präsentiert bekommt und es als kontaktlose Kreditkarte erkennt, wird das Gerät auf seiner lokal gespeicherten Negativliste nach dieser Karte suchen und die Karte bei erfolgreicher Suche ablehnen. Wenn sie nicht auf der lokalen Negativliste gefunden wird, wird eine Kreditkarte vom Endgerät akzeptiert.

Es ist dabei zu beachten, dass kontaktlose Kreditkarten, die ja als Open-Payment Medien nicht am System angemeldet werden brauchen, sondern ad-hoc als Zugangsberechtigung genutzt werden können, nicht auf Positivlisten geführt werden können, da die Vielzahl der weltweit genutzten Kreditkarten dem Zugangssystem nicht a priori bekannt sein kann. Open-Payment Medien werden nach einer fehlgeschlagenen Verrechnung am Hintergrundsystem auf die Negativliste gesetzt; weiterhin ist es möglich, dass das Hintergrundsystem von Banken und/oder Zahlungssystem-Anbietern Sperrlisten (Listen mit gesperrten Kredit- und/oder Girokarten) importiert, in systemeigene Negativlisten konvertiert und an die Endgeräte verteilt.

Im weiteren bedeutet dieses Prinzip, dass eine kontaktlose Kreditkarte, die im Zugangssystem mehrfach und ohne Beanstandung benutzt wird, zwar ein dem systembekanntes Identifikationsmedium ist, aber dennoch auf gar keiner Liste geführt wird - weder auf der Negativ- noch auf der Positivliste.

Positiv- und Negativlisten enthalten damit nicht alle Kenner zu allen im Zugangssystem bekannten Identifikationsmedien, sondern nur die für den Systembetrieb gemäß dem erfindungsgemäßen Verfahren notwendigen Kenner. Typischerweise sind dies auf der Positiv-Liste die Kenner der zugelassenen registrierten Medien und auf der Negativ-Liste die Kenner nicht-zugelassenen nicht-registrierten Medien.

Weitere Vorteile und Merkmale der Erfindung ergeben sich aus der folgenden Beschreibung anhand der Figuren. Dabei zeigen:

Fig. 1 : eine Flussdiagramm-Darstellung der Abläufe an einem Eintrittssystem unter

Verwendung einer kontaktlosen Kreditkarte und

Fig. 2: eine Flussdiagramm-Darstellung der Abläufe für die Fahrpreisermittlung und

Abrechnung nach Verwendung einer kontaktlosen Kreditkarte.

Figuren 1 und 2 erläutern das erfindungsgemäße Verfahren beispielhaft weiter anhand einer Transaktion in einem erfindungsgemäßen Fahrausweissystem mit einer kontaktlosen Kreditkarte, der anschließenden Abrechnung der durchgeführten Reise und der Entscheidung, ob die Karte auf die Negativliste gesetzt wird.

Figur 1 zeigt beispielhaft und schematisch, dass eine kontaktlose Kreditkarte 1 an einem Entwerter 2 zum Eintritt in das System benutzt wird. Der Kartenhandhabungs-Prozess 21 liest die Kartendaten aus und erkennt, dass eine Karte vom Typ Kreditkarte vorliegt. Für Kreditkarten wird in der lokalen Negativliste 22 gesucht, ob diese Karte dort eingetragen ist. Falls ein Eintrag vorliegt, wird dem Kunden auf der Anzeige 23 eine entsprechende Meldung (z.B.„Karte ungültig") mitgeteilt. Falls kein Eintrag gefunden wird, wird dem Kunden auf der Anzeige 23 angezeigt, dass die Karte gültig ist. In diesem Fall werden die Kartendaten an den Transaktionsaufzeichnungsprozess 24 weiter geleitet, der die Nutzung genau dieser Karte zusammen mit Gerätenummer, Gerätestandort, Datum, Uhrzeit und anderen relevanten Daten als vollständigen Transaktionsdatensatz in lokalen Transaktionsspeicher 25 abgelegt. Ein Transaktions-Upload-Prozess sendet diese Transaktton sobald wie möglich per Daten-Upload 3 an das Hintergrundsystem 4.

Im Hintergrundsystem 4 wird die Transaktion von einem zentralen Entgegennahme- Prozess 41 entgegengenommen und in die zentrale Karten- und Transaktionsdatenbank 42 eingetragen. Ein Prozess für Fahrpreisberechnung und Abrechnung 43 setzt die zur benutzten Karte gehörigen Transaktionen zu einer Fahrt und ggf. mehrere Fahrten zu einer Reise zusammen und rechnet sie mit dem Kreditkartenherausgeber ab (Details dazu sind in Figur 2 beschrieben). Falls die Abrechnung nicht möglich ist, wird die verwendete Karte als ein neuer Eintrag in die zentrale Negativliste 44 aufgenommen, welche vom Listen-Download-Prozess 45 im Broadcast-Verfahren 5 an alle Endgeräte verteilt wird. Am Entwerter 2 nimmt der lokale Listen-Update-Prozess die neuen Listeinträge entgegen und speichert sie in den lokalen Positiv- und Negativlisten 22.

Figur 2 zeigt beispielhaft und schematisch den Ablauf für die Fahrpreisermittlung und Abrechnung von Reisen, die mit einer kontaktlosen Kreditkarte getätigt wurden. Aus der zentralen Karten- und Transaktionsdatenbank 42 entnimmt der Fahrpreisberechnungsprozess 43.1 die zu einer Kreditkartennummer gehörigen noch nicht verrechneten Transaktionen und setzt diese zu Fahrten zusammen, die mit dieser Kreditkarte getätigt wurden. Ggf. werden mehrere Fahrten zu einer Reise zusammengesetzt, und letztlich wird immer ein Fahrpreis ermittelt. Der Fahrpreis wird vom Autorisierungsprozess 43.2 mit dem Kreditkartenherausgeber 43.3 {außerhalb des Fahrausweissystems) verrechnet. Ein Auswertung 43.4 leitet zwei mögliche Reaktionen auf diese Verrechnung ein: die Verrechnung war möglich, d.h. die Kreditkarte wurde für den Reisepreis positiv autorisiert - dann ist die Reise bezahlt und keine weitere Aktion nötig 43.5; oder die Verrechnung war nicht möglich, d.h. die Kreditkarte wurde für den Reisepreis nicht autorisiert - dann wird die offene Forderung registriert 43.6 und die Karte als neuer Eintrag auf die zentrale Negativliste gesetzt 43.7.

B e z u g s z e i c h e n l i s t e

1 Kontaktlose Kreditkarte („Open Payment" Karte)

2 Entwerter

21 Kartenhabungs-Prozess

22 Lokale Positiv- und Negativlisten

23 Kundenanzeige des Entwerters

24 Transaktionsaufzeichnungs-Prozess

25 Lokaler Transaktionsspeicher

26 Transaktions-Upload-Prozess

27 Listen-Update-Prozess

3 Daten-Upload vom Entwerter an das Hintergrundsystem

4 Hintergrundsystem („Back Office")

41 Transaktions-Entgegennahme-Prozess

42 Zentral Karten- und Transaktions-Datenbank

43 Prozesse für Fahrpreisberechnung und Abrechnung

43.1 Fahrpreisberechnung

43.2 Autorisierung der Karte

43.3 Kreditkartenherausgeber (außerhalb des Fahrausweissystems)

43.4 Autorisierung erfolgreich?

43.5 OK. Kein Listeneintrag.

43.6 Nicht OK: Registriere offene Zahlung.

43.7 Nicht OK: Setze Karte auf Negativliste.

44 Zentrale Positiv- und Negativliste

45 Listen-Download-Prozess

5 Daten-Broadcast vom Hintergrundsystem an die Endgeräte