-verf ahren Die Erfindung betrifft ein automatisiertes Bezahlsystem und -verfahren, be vorzugt unter Verwendung eines mobilen Endgerätes eines Kunden.

Der Prozess des Bezahlens in Restaurants hat sich in der Vergangenheit nicht wesentlich verändert. Gäste betreten ein Restaurant, sind dort in der Regel nicht bekannt, und bestellen und konsumieren Speisen und/ oder Getränke. Am Ende, nachdem sie alle Produkte irreversibel konsumiert haben, erhalten sie die Rechnung und begleichen diese, wobei zusätzlich in der Regel in vie len Kulturkreisen noch ein freiwilliges Trinkgeld gezahlt wird. Es können Barzahlung, Kredit- oder Debit-Kartenzahlung zum Einsatz kommen - auch Zahlverfahren mit einem Mobiltelefon. In eher selteneren Fällen findet ein Bezahlen per Überweisung statt, z.B. wenn eine größere Gruppe im Rahmen eines Festes bewirtet wurde und die Rechnung später zugestellt und begli chen wird oder der Gastronom aus Kostengründen auf die elektronischen Zahlmethoden verzichtet. Diese Zahlprozesse sind etabliert, weltweit akzep- tiert und unterscheiden sich dabei von Land zu Land und Kultur zu Kultur nur wenig.

Dennoch gibt es Nachteile, die gemeinhin als lästig empfunden werden: Um die Rechnung zu begleichen ist ein mehrstufiger Prozess unter Beteili gung des Personals des Restaurants notwendig (Zahlwunsch beim Kellner anzeigen, Rechnung zur Überprüfung erhalten, Zahlmethode auswählen, Rechnung begleichen). Der Bezahlvorgang kann je nach Auslastung und Servicekapazität des Res taurants unerwünscht lang dauern, und das Lokal kann in dieser Zeit nicht verlassen werden, was nicht selten zu Ärger oder auch Streitigkeiten führt. Auch wird auch der Tisch, an dem der Gast auf Zahlung wartet, unnötig lange blockiert. Es gibt Rechtsprechung, die das Verhalten regelt, falls kein Kellner zum Kassieren in adäquater Zeit erscheint.

Möchte ein Gast andere Gäste einladen, entsteht oft eine etwas peinliche Si tuation beim Bezahlen. Einen Abend mit eingeladenen Gästen zu verbringen, ist häufig eine Motivation für einen Restaurantbesuch. Der Einladende wird versuchen, den Bezahlvorgang möglichst diskret mit dem Kellner abzu schließen, und die Eingeladenen schauen gegebenenfalls dabei dezent weg. Um dies zu vermeiden, versucht der Einladende oft einen günstigen Moment zu finden, um die Rechnung entfernt vom Tisch unbemerkt von den Eingela denen zu begleichen.

Wenn mehrere Gäste die Rechnung aufteilen, dauert der Bezahlprozess sehr lange und kann zu Konfusion führen. Oftmals wünschen Gäste eines Tisches getrennte Rechnungen, die den individuellen Konsum abbilden. In diesem Fall muss der Kellner die Rechnung nach Gästen separieren, getrennt kassie ren und sicherstellen, dass alle Posten abgedeckt sind. Dies ist ein sehr um ständlicher, damit langwieriger Prozess und führt nicht selten zu Verwir rung, insbesondere wenn am Ende Posten übrigbleiben, die dann nachträg lich verrechnet werden müssen.

Die EP 2081140 Al sowie die EP 2592584 Al betreffen die Absicherung von Drahtlosbezahlvorgängen, die unter Verwendung eines mobilen Endgerätes, beispielsweise eines Mobilfunkgerätes, sowie ortsfester Positionsgeber, bei spielsweise RFID- oder NFC-Tags, durchgeführt werden. Die WO 2014/105226 Al offenbart ein System, bei dem ein Kunde sich in einem Warenhaus automatisch zur Abwicklung kontaktloser Zahlungs verfahren anmelden kann, wobei ebenfalls ortsfeste Tags eingesetzt werden. Eine Wei terbildung dieses Systems ist in der WO 2015/034755 Al beschrieben. Aus der WO 2016/ 053975 Al ist ebenfalls ein kontaktloses Bezahlverfahren be kannt, mit dem ein Benutzer mittels eines Endgerätes, beispielsweise eines Mobiltelefons, eine von einem Verkäufer angeforderte Zahlung freigeben kann. In allen Fällen ist die Mitwirkung des Kunden erforderlich.

Die ideale Vorstellung eines Restaurantbesuches ist es, Prozesse, die störend sind, zu eliminieren. Dazu gehört der Bezahlvorgang mit Mitwirkung des Gastes. Die Einschaltung von Mobiltelefonen und Funkkommunikation mit Datenbanken behebt (s.o.) diese Problematik nicht. Dasselbe gilt bei Einkäu fen, die mehrere einzelne Kaufvorgänge umfassen.

Der Erfindung liegt deshalb die Aufgabe zugrunde, den Bezahlvorgang bei einer Abfolge von mehreren Kaufvorgängen, z.B. Bestellungen in einem Res taurant, zu vereinfachen, insbesondere, wenn ein mobiles Endgerät und Funkkommunikation zum Einsatz kommt.

Die Erfindung ist in den unabhängigen Ansprüchen definiert. Die abhängi gen Ansprüche beziehen sich auf vorteilhafte Weiterbildungen.

Es ist vorgesehen ein automatisiertes Bezahlverfahren für eine Zahlung eines Kunden an einen Verkäufer für eine Abfolge von mehreren Kaufvorgängen bereit zu stellen. Es werden dazu folgende Schritte in einer Verkäufereinheit, z.B. einem Verkaufsrechner, ausgeführt: a) Einbuchen des Kunden für die Abfolge der mehreren Kaufvorgänge, b) Empfangen von Abrechnungsdaten für jeden der Kaufvorgänge, je weils umfassend einen Kaufumsatz des Kaufvorganges, c) Ausbuchen des Kunden für die Abfolge der Kaufvorgänge, d) Aufaddieren der Kaufumsätze, und e) Erzeugen von Bezahlungsdaten aus den aufaddierten Kaufumsätzen und aus Zahlungsdienstleisterdaten des Kunden, wobei in Schritt c) das Ausbuchen des Kunden mindestens den Schritt e) auslöst, und wobei in Schritt c) das Ausbuchen des Kunden abhängig von verkäu ferindividuellen und/ oder kundenindividuellen Ausbuchungsbasisdaten automatisch ausgeführt wird.

Dabei wird das Ausbuchen automatisch ausgeführt, indem ein Ausbu chungszeitpunkt, zu dem das Ausbuchen auszuführen sein wird, auf Basis der Ausbuchungsbasisdaten bestimmt wird und/ oder indem als Ausbu chungskriterium eine Plausibilität der Abrechnungsdaten auf Basis der Aus buchungsbasisdaten geprüft wird.

Das Ausbuchen erfolgt somit bevorzugt erst, wenn der bestimmte Ausbu chungszeitpunkt erreicht ist und/ oder das Ausbuchungskriterium, Plausibi lität der Abrechnungsdaten der Abfolge der Kaufvorgänge, erfüllt ist. Das Erreichen des zuvor bestimmten Ausbuchungszeitpunktes wird überwacht und kann das Ausbuchen auslösen, insbesondere wenn auch die Plausibilität der empfangenen Abrechnungsdaten gegeben ist.

Der Ausbuchungszeitpunkt kann auf Basis der Ausbuchungsbasisdaten und der Abrechnungsdaten bestimmt werden. Der automatische Ausbuchungs zeitpunkt wird somit einerseits individuell für den Kunden und/ oder den Verkäufer bestimmt, ist jedoch andererseits unabhängig von einem tatsächli chen, ggf. manuellen, aktiven Ausbuchen durch Kunde oder Verkäufer. Das Ausbuchen wird also insbesondere nur dann automatisch ausgeführt, falls der Ausbuchungszeitpunkt erreicht und/ oder das Ausbuchungskrite rium erfüllt ist. Ist dagegen weder der Ausbuchungszeitpunkt erreicht noch das Ausbuchungskriterium erfüllt oder alternativ entweder der Ausbu chungszeitpunkt nicht erreicht oder das Ausbuchungskriterium nicht erfüllt, wird der Kunde nicht automatisch ausgebucht.

Die Plausibilität der Abrechnungsdaten der Abfolge von Kaufvorgängen kann geprüft werden, sobald der bestimmte Ausbuchungszeitpunkt erreicht ist. Alternativ oder ergänzend wird die Plausibilität der Abrechnungsdaten geprüft, sobald Abrechnungsdaten eines Kaufvorganges empfangen werden. Insbesondere kann das Ausbuchen in diesem Fall erfolgen, wenn auf Basis der Ausbuchungsbasisdaten erkannt wird, dass eine das Ausbuchen auslö sende Abfolge von Kaufvorgängen mit plausiblen Abrechnungsdaten vor liegt.

Das automatisierte Verfahren bucht den Kunden, z.B. in Form von Daten über dessen mobiles End gerät, für mehrere Kaufvorgänge in die Verkäufer software ein. Dies stellt einen Check-in dar.

Die kundenindividuellen und/ oder verkäuferindividuellen Ausbuchungsba sisdaten sind natürlich bereits vor dem Schritt des Einbuchens gespeichert. Sie können der Verkäufereinheit bzw. der Verkäufersoftware, die auf der Verkäufereinheit ausführbar oder auf einem Server aufrufbar ist, bereitge stellt werden.

Zusätzlich sind oder werden Zahlungsdienstleisterdaten für den Kunden hinterlegt, z.B. per Übertragung vom mobilen Endgerät zur Verkäufersoft- ware. Dies kann schon im Vorfeld passiert sein (Subskription). Dann werden wiederholt Kaufvorgänge ausgeführt. Für jeden der Kaufvor gänge werden Abrechnungsdaten, umfassend Kaufumsätze des jeweiligen Kaufvorgangs, in der Verkäufersoftware erzeugt. Die Abrechnungsdaten können Abrechnungsobjekte (z.B. bestellte Produkte/ Dienstleistungen), Preise der Abrechnungsobjekte, Bestellzeitpunkte etc. umfassen. Sie werden anhand vorbestimmter Kriterien auf Plausibilität geprüft, und es wird ein er warteter Abschlusszeitpunkt der Abfolge von Kaufvorgängen, vorzugsweise auch auf Basis der Abrechnungsdaten, ermittelt. Die Kaufumsätze werden insbesondere nur aus denjenigen Abrechnungsdaten übernommen und auf addiert, deren Plausibilitätsprüfung erfolgreich war. Ist der erwartete Ab schlusszeitpunkt erreicht, werden automatisch, d.h. ohne zwingend nötige Mitwirkung des Kunden, Belastungsdaten aus den aufaddierten Kaufumsät zen und den Zahlungsdienstleisterdaten erzeugt und damit die Bezahlung aller berücksichtigten Kaufumsätze vorgenommen. Zugleich erfolgt ein Aus buchen des Kunden bzw. dessen mobilen Endgeräts aus der Verkäufersoft- ware.

Das automatisiertes Bezahlsystem umfasst die Identifikationseinheit des Kunden, also insbesondere das mobile Endgerät, auf dem eine lauffähige Kundensoftware und gegebenenfalls die Zahlungsdienstleisterdaten gespei chert sind, den Verkäuferrechner, auf dem die lauffähige Verkäufersoftware gespeichert ist oder von dem die auf einem Server laufende Verkäufersoft- ware aufrufbar ist, und der eine Schnittstelle zur Übertragung von Bezahlda ten an einen Zahlungsdienstleister aufweist. Die Kundensoftware und die Verkäufersoftware sind bei Ausführung, auf dem End gerät bzw. dem Ver käuferrechner oder dem Server, zur Durchführung des genannten Verfah rens ausgebildet. Durch das erfindungsgemäße System bzw. Verfahren kann ein Gast ein Res taurant aufsuchen, bestellen, essen und trinken und dann ohne weiteres ge hen. Der Bezahlvorgang findet komplett automatisiert im Hintergrund statt. Dennoch erhält der Kunde bevorzugt eine elektronische Abrechnung seiner Leistungen und Zahlungen, die er während oder auch erst nach dem Besuch einsehen und kontrollieren kann. Dies ist idealerweise aber gar nicht nötig, da Fehler vom System proaktiv weitgehend ausgeschlossen sind.

Durch das System/ Verfahren ist der Bezahlvorgang komplett in den Hinter grund gerückt. Lediglich das Trinkgeld kann noch eine Interaktion erfor dern. Je nach Sicher heitsbedürfnis des Kunden können in seltenen Fällen Si cherheitsinteraktion erforderlich sein, aber auch (bei entsprechendem Ver trauen) dem Restaurant zur Behebung überlassen werden.

Das Sy stem /Verfahren vereinfacht den Bezahlvorgang vor allem durch ei nen hohen Grad der Automatisierung. Dadurch verschiebt sich grundsätz lich das Risiko des Geschäftsprozesses weg vom Anbieter hin zum Kunden. Bisher lag das gesamte Risiko beim Anbieter, da dieser erst beim abschlie ßenden Bezahlen die Bonität seines Kunden prüfen konnte. Diese ist insbe sondere in der Gastronomie bei Zechprellerei problematisch. Durch die Er findung gibt der Kunde bereits im technisch unterstützen Check-in-Prozess sein Einverständnis zur Zahlung in diesem Restaurant. Um den Kunden vor Fehlbuchungen zu schützen, sind absichernde Maßnahmen vorgesehen.

Diese umfassen eine Plausibilitätsprüfung bei der Bestellung/ Lieferung und eine Vorhersage eines Check-out-Zeitpunktes für einen zeitgesteuerten, auto matischen Check-out.

Plausibilitätsprüfung Nachdem der Kunde an seinem Tisch eingecheckt ist, wird jede Bestellung auf Plausibilität geprüft. Dies schützt den Kunden vor Fehlbuchungen. Dazu werden vorbestimmte Kriterien herangezogen. Z.B. wären die Bestellung ei nes Hauptgerichts, nachdem bereits ein Dessert bestellt wurde, oder die Be stellung neuer Getränke, wenige Minuten nachdem bereits Getränke für alle Gäste bestellt wurden, unplausibel und vom System/ im Verfahren abzu lehnen. Es können auch Kriterien herangezogen werden, die das System von den individuellen Kunden gelernt hat - z.B. Kunde trinkt keinen Alkohol, ist Vegetarier, konsumiert keinen Nachtisch etc. Bestellungen, die in der Plausi bilitätsprüfung aussortiert wurden, resultierten in einem Warnhinweis und erfordern eine gesonderte Quittierung durch Bedienung und/ oder Gast.

Die Plausibilitätsprüfung kann auf fix eingestellten Regeln basieren oder auch vom System selbsttätig auf Basis des individuellen Konsumentenver haltens gelernt werden. Es kann auch eine Kombination aus beiden Ansätzen vorliegen. Als Basis dieser selbstlernenden Algorithmen können z.B. mul- tivariate Klassifikatoren mit Bayes'schen Schätzungen verwendet werden, um die Wahrscheinlichkeit für die Korrektheit einer Bestellung abzuschät zen. Solche Algorithmen sind dem Fachmann z.B. aus Empfehlungssystemen bekannt: „Kunden, die Artikel A gekauft haben, interessieren sich auch für Artikel B". Jedoch ist hier die Logik umzukehren: „Kunden, die Produkt A bestellt haben, bestellen in der Regel nicht Produkt B".

Vorhersage des Check-out-Zeitpunktes

Wenn der Gast das Restaurant verlässt, soll er automatisch ausgecheckt wer den, so dass dann keine weitere Buchung zu Lasten des Kunden mehr mög lich ist. Dies schützt ihn zusätzlich vor Fehlbuchungen, da der Kellner keine anderen Bestellungen, z.B. die des nächsten Gastes, absichtlich oder verse hentlich dem vorherigen Gast zuordnen kann. Um den Zeitpunkt des Check out vorherzusagen, also zu schätzen, wann das Ende der Abfolge an Kauf vorgängen, mithin das Ende des Kundenbesuchs zu erwarten ist, werden be vorzugt kundenunabhängige Daten (z.B. typische Verweildauer im Restau rant, Uhrzeit, Standardbestellabläufe) und/ oder kundenindividuelle Daten (z.B. welche Produkte wurden bisher bestellt, Kundenhistorie) verwendet. Auf Basis dieser Daten wird bevorzugt mithilfe eines Modells, insbesondere unter Verwendung maschinellen Lernens, ein erwarteter Zeitpunkt ge schätzt, zu dem der Gast das Restaurant verlassen hat, also die Abfolge von mehreren Kaufvorgängen abgeschlossen sein wird. So ist z.B. nach Bestel lung eines Desserts und ggf. Kaffees der Zeitpunkt des Check-outs erwar tungsgemäß nicht mehr weit entfernt, während nach der Bestellung eines Aperitifs der Gast vermutlich noch länger im Restaurant verweilen wird. Analoges gilt für Kaufvorgänge in einem Nicht-Restaurantumfeld. Ist der er wartete Zeitpunkt erreicht, wird der Gast automatisch ausgecheckt.

Dabei ist es von Vorteil, dass die Vorhersage nicht allzu präzise sein muss, da der geschätzte Zeitpunkt zwischen der letzten Bestellung und kurz nach dem Weggang des Gastes liegen sollte. Im Falle einer Fehleinschätzung kann der Gast manuell aus- bzw. wieder eingecheckt werden. Dies bedarf optional einer Bestätigung durch den Gast, um ein fehlerhaftes oder gar betrügeri sches Wiedereinchecken eines richtigerweise ausgecheckten Gastes zu ver hindern.

Bevorzugt wird ein Wiedereinchecken protokolliert, wodurch im Zweifelsfall nicht die gesamte Zeche streitig wäre, sondern nur der Teil ab dem Wieder einchecken. Es wird in Ausführungsformen aus den Daten eine Zeitspanne berechnet, nach der keine weitere Bestellung mehr erwartet wird oder die Wahrschein lichkeit für eine weitere Bestellung unter einen Schwellwert sinkt. Dazu kön nen z.B. Klassifikationsbäume eingesetzt werden oder auch Regressionsver fahren. Wenn innerhalb dieser vorhergesagten Zeitspanne eine weitere Be stellung eingegangen ist, wird die Berechnung aktualisiert. Andernfalls ist der vorhergesagte Zeitpunkt erreicht, wenn die Zeitspanne abgelaufen ist.

Zusätzlich gibt es optional folgende Sicherheitsmechanismen gegen betrüge rische Absichten oder Fehlbelastungen:

1. Es ist eine lokale Präsenz erforderlich. Sie wird durch die Anwesenheit des Smartphones überprüft (z.B. Scannen des QR-Codes, Kontakt zu einem Bluetooth Beacon, Geolocation des Smartphones). Ggf. reicht auch die (nicht- stornierte) Reservierung als Beleg für die Anwesenheit des Kunden.

2. Es kann ein Maximalbetrag vorgesehen werden, der nicht überschritten werden kann und nur nach Überprüfung eines Sicherheitsmerkmals, z.B. Eingabe eines Passworts oder Überprüfung eines biometrischem Merkmals, verändert werden kann. Der Maximalbetrag kann auch vom System kunden individuell festgelegt werden. Der Kunde selbst könnte auch im System eine Vorautorisierung für einen Betrag X vornehmen, z.B. im Moment der Reser vierung. Für das jeweilige Restaurant kann dabei auch vom System ein Default-Betrag vorgeschlagen werden.

3. Eine Option, die die Sicherheit noch weiter erhöht, ist eine „Ve tofrist" für jede Bestellung, die beginnt, sobald eine Push-Nachricht über die Bestellung an das mobile Endgerät abschickt wurde. Dabei wird jede Bestel lung erst nach Ablauf dieser Widerspruchsfrist (z.B. zwei oder drei Minuten) aktiviert und gebucht. In dieser Zeit kann der Kunde über sein Smartphone widersprechen und die Bestellung rückgängig machen. In der Küche wird optional der Veto Status jeder Bestellung angezeigt. Der Küchenchef kann dann auf eigenes Risiko die Zubereitung vor Ablauf der Frist beginnen oder bis zu deren Ablauf mit Zubereitung oder Auslieferung warten. In der Praxis dürfte es eher selten _V orkommen, dass die Küche innerhalb von zwei oder drei Minuten nach Eingang einer Bestellung bereits mit der Zubereitung der Bestellung beginnt. Das Veto erfordert natürlich, dass der Kunde mit seinem Smartphone auf die Pushnachricht reagiert.

Die Erfindung erreicht eine vollständige Verlagerung des Bezahlvorgangs in den Hintergrund, ohne dass an irgendeinem Zeitpunkt eine Bestätigung des Kunden, insbesondere eine (manuelle) Rechnungsprüfung notwendig wäre. Dennoch sind Sicherheitsmechanismen eingeführt, die den Kunden vor ab sichtlichen oder (was wesentlich wahrscheinlicher ist) versehentlichen Fehl buchungen schützen. Die Erfindung sieht dazu vor, den Plausibilitätscheck jeder Bestellung automatisch durchzuzuführen und das Verlassen des Res taurants (und damit den Zeitpunkt des Check-outs) vorherzusagen.

Sowohl für das Verfahren als auch für das System ist der Einsatz eines mobi len Endgerätes, das dem Kunden zugeordnet ist, ein bevorzugter Aspekt, denn mithilfe dieses mobilen Endgerätes kann der automatisierte Bezahlvor gang besonders einfach abgewickelt werden. Voraussetzung ist, dass der Kunde an einem elektronischen Zahlungssystem teilnimmt, wie es beispiels weise durch den Anbieter PayPal, Inc. bereitgestellt ist. Auch der Verkäufer (in den genannten Beispielen das Restaurant) nimmt an diesem Bezahlsys tem teil, das letztlich den Geldtransfer abwickelt. Derartiges ist dem Fach mann natürlich bekannt. Soweit die Erfindung hier unter Bezugnahme auf die Bezahlung in einem Restaurant beschrieben und erläutert wird, ist dies rein exemplarisch. Die Er findung ist vielmehr auf alle Bezahlvorgänge gerichtet, bei denen über einen längeren Zeitraum mehrere einzelne Produkte oder Dienstleistungen in einer Abfolge von Kaufvorgängen bezogen und am Ende gesammelt bezahlt wer den. Soweit also von einem Gast die Rede ist, ist dies nur als Beispiel für ei nen Kunden zu verstehen, und die Bestellung von Speisen und Getränken ist lediglich exemplarisch für den mehrfachen Kauf einzelner Waren oder Dienstleistungen.

Unter „automatisch" wird in dieser Beschreibung verstanden, dass keine Freigabe durch einen Benutzer angefordert und/ oder abgewartet wird.

Die Erfindung ist auf ein Verfahren zum Bezahlen in einem solchen Umfeld gerichtet. Sie erfasst gleichermaßen ein entsprechendes System bestehend aus den im entsprechenden Systemanspruch definierten Vorrichtungen. So weit nachfolgend die Beschreibung anhand des Bezahlverfahrens erläutert wird, darf dies ebenfalls nicht als Einschränkung aufgefasst werden. Viel mehr kann, wie auch an den Ausführungsbeispielen erläutert, das System das entsprechende Bezahlverfahren abwickeln.

Nachfolgend wird die Erfindung anhand von Ausführungsbeispielen unter Bezugnahme auf die beigefügten Zeichnungen, die ebenfalls erfindungswe sentliche Merkmale offenbaren, noch näher erläutert. Diese Ausführungsbei spiele dienen lediglich der Veranschaulichung und sind nicht als einschrän kend auszulegen. Beispielsweise ist eine Beschreibung eines Ausführungs beispiels mit einer Vielzahl von Elementen oder Komponenten nicht dahin gehend auszulegen, dass alle diese Elemente oder Komponenten zur Imple mentierung notwendig sind. Vielmehr können andere Ausführungsbeispiele auch alternative Elemente und Komponenten, weniger Elemente oder Kom ponenten oder zusätzliche Elemente oder Komponenten enthalten. Elemente oder Komponenten verschiedener Ausführungsbespiele können miteinander kombiniert werden, sofern nichts anderes angegeben ist. Modifikationen und Abwandlungen, welche für eines der Ausführungsbeispiele beschrieben wer den, können auch auf andere Ausführungsbeispiele anwendbar sein. Zur Vermeidung von Wiederholungen werden gleiche oder einander entspre chende Elemente in verschiedenen Figuren mit gleichen Bezugszeichen be zeichnet und nicht mehrmals erläutert. In den Figuren zeigen:

Fig. 1 ein Ablaufdiagramm einer Ausführungsform eines Bezahlverfah rens in einem Restaurant und

Fig. 2 eine Schemadarstellung eines Systems, mit dem das Bezahlverfah ren ausgeführt wird.

Wie weiter oben bereits geschildert, wird ein Bezahlverfahren anhand eines Restaurantbesuchs beschrieben, ohne dass dies einschränkend ist.

Fig. 1 zeigt ein Ablaufdiagramm einer ersten Ausführungsform eines Bezahl verfahrens. Fig. 2 zeigt die zugehörigen Systemelemente. Der Gast wird sich vorbereitend bei einem Zahlungsdienstleiser registrieren, mit dem auch das Restaurant zusammenarbeitet. Weiter läuft auf dem End gerät des Kunden eine App (Softwarepaket), die mit einem Rechner 4 des Restaurants zusam menwirkt.

Das Verfahren besteht aus drei Blöcken A bis C:

A - Check-in: Zu Beginn wird der Gast im Rechner 4 des Restaurants regis triert (Schritt Sl), bevorzugt mit seinem mobilen Endgerät (alternativ kann auch ein anderes Mittel verwendet werden, wie eine Chipkarte oder eine ma schinenlesebarer Code, z.B. ein QR-Code). Durch die Registrierung stehen dem Rechner 4 Zahlungsdienstleisterdaten des Gastes zur Verfügung, z.B. durch Übertragung vom mobilen Endgerät 8 zum Verkaufsrechner 4. In der Regel wird der Gast einem Ort im Restaurant zugewiesen. Bei Verwendung des mobilen Endgerätes können Nachrichten zwischen Rechner 4 und End gerät 8 ausgetauscht werden.

B - Bestell-/ Liefer-Phase: Anschließend bestellt und konsumiert der Gast (Schritte S2-S7).

C - Check-out : Abschließend erfolgt automatisch das Zusammenstellen und Begleichen der Rechnung und der Gast verlässt in etwa zeitgleich das Lokal (Schritt S8).

Check-in (Schrit Sl)

Wenn der Gast das Restaurant 2 betritt, hat er bevorzugt bereits einen Tisch reserviert (z.B. per App/ Webseite) und kann vom Kellner an diesem Tisch eingecheckt werden.

Alternativ wählt er einen freien Tisch und checkt sich selbst an diesem Tisch mittels eines dort angebrachten QR-Codes 10 oder automatisch mit Hilfe ei nes Bluetooth Beacons 12 automatisch ein. Ggf. muss auf Grund einer zu ge ringen räumlichen Auflösung des Beacons 12 die Tischnummer jedoch sepa rat erfasst werden.

Folgende Check-in-Abläufe sind denkbar: Der Gast ist bereits zuvor reserviert auf einen bestimmten Tisch. Der Kellner bringt den Gast zu diesem Tisch und der Gast checkt sich selbst per QR-Code 10 am Tisch ein. Dieser Ablauf erreicht eine hohe Prozesssicherheit durch Plausibilitätsabgleich zwischen Reservierung und Check-in.

Der Gast checkt sich beim Kellner ein, z.B. zeigt er einen ihn individualisie renden QR-Code, der vom Kellner gescannt wird, um die Registrierung im Verkaufsrechner 4 zu erreichen. Alternativ könnte der Kellner auch dem Gast einen individuellen QR-Code zeigen, mittels dessen sich der Gast ein checkt. In beiden Varianten sind Fehler in der Zuordnung Tisch/ Gast ver mieden.

Das Restaurant bucht den Gast direkt auf einen für diesen reservierten Tisch. Dann ist keine Mitwirkung des Gastes nötig.

Der Check-in ordnet damit bevorzugt den Gast einem Tisch/ Ort im Restau rant zu. Dann liegt automatisch auch der „Lieferort" für die Speisen, Ge tränke oder Waren fest.

Bestell-/Liefer-Phase (Schritte S2-S7)

Der Gast bestellt ganz traditionell beim Kellner (Schritt S2) und dieser bucht die Speisen/ Getränke im Verkaufsrechner 4 für den Gast.

Um Fehlbuchungen zu vermeiden, ist optional eine Plausibilitätskontrolle gemäß den Schritten S3, S4 vorgesehen, die z.B. auf intelligenten Algorith men oder Modellen oder Standardvorgaben basieren kann, und dabei gege benenfalls auch kundenspezifische Daten verwendet: Erscheint in einer Plau- sibilitätsprüfung (Schritt S3) die im Schritt S2 aufgegebene Bestellung un plausibel (Schritt S4, „-"-Zweig), wird der Kellner darauf hingewiesen und muss die Korrektheit der Buchung bestätigen (Schritt S9), sonst wird sie au tomatisch verworfen. Ggf. muss der Gast über sein mobiles Endgerät mitwir- ken, so dass eine unplausible Buchung einer expliziten Bestätigung durch den Kunden bedarf. Möglichkeiten für diese Plausibilitätskontrolle werden später noch erläutert.

Nur wenn die Plausibilitätsprüfung erfolgreich war (Schritt S4, ,,+ -Zweig), wird die Buchung auf die Rechnung boniert und der Gast erhält optional eine die Bestellung bestätigende Push-Nachricht auf sein Mobiltelefon 6, die aber keine Interaktion erfordert.

Check-out

Wenn der Gast fertig gegessen und getrunken hat, verlässt er das Restaurant und wird automatisch ausgecheckt (Schritte S7, S8). Dabei wird die Rech nung automatisch erstellt und über das hinterlegte Bezahlverfahren abge rechnet. Er bekommt dann optional eine entsprechende Pushnachricht mit der Möglichkeit, Trinkgeld zu geben.

Das automatische Auschecken wird in Ausführungsformen zeitgesteuert auf Basis der Bestellungen eingeleitet, so dass ein Ausbuchungszeitpunkt festle- gelegt wird. Es wird für jeden Kunden dessen erwarteter Zeitpunkt des Ver lassene des Restaurants geschätzt (Schritt S6) - also nicht lediglich eine Stan dardzeitspanne im Sinne eine Time-Out gewartet. Es wird das bisherige Ver halten des Kunden und/ oder von anderen Kunden berücksichtigt. Da der Zeitpunkt nicht sehr präzise sein muss (er sollte nach der letzten Bestellung des Gastes und nicht später als kurz nach Verlassen des Lokals liegen), ist die Schätzung einfacher, und Fehler wie zu frühes oder zu spätes Auschecken sind einfach zu vermeiden. War der gewählte Zeitpunkt zu früh, kann der Gast entweder wieder eingecheckt werden (durch den Kellner oder den Gast selbst), d.h. das Verfahren beginnt im Schritt S1 erneut. Ist der geschätzte Zeitpunkt erreicht (Schritt S7, ,,+"-Zweig), wird der Gast automatisch ausge bucht, und die Rechnung wird geschlossen (Schritt S8) und beim Zahlungs dienstleister zum Begleichen eingestellt. In Ausführungsformen wird auf grund von Standardvorgaben, die entweder global (z.B. mittlere Aufenthalts dauer aller Kunden) oder kundenindividuell (z.B. mittlere Aufenthaltsdauer des betroffenen Kunden) sein können, der Ausbuchungszeitpunkt festgelegt.

War der Zeitpunkt nicht erreicht (Schritt S7, „-"-Zweig), wird zum Schritt S2 (weitere Bestellung möglich) zurückgesprungen. Im Schritt S6 wird also wie derholt der Zeitpunkt des erwartenden Besuchsendes geschätzt bzw. eine frühere Schätzung fortgeschrieben.

Sowohl der Gast kann sich in Ausführungsformen auch nach Verlassen in der App selbst auschecken, als auch der Kellner den Gast im System aus checken, wenn er feststellt, dass der Gast gegangen ist.

Optional wird im Rahmen des Schritts S8 gefragt, ob ein Trinkgeld gegeben werden soll. Optional ist ein Trinkgeld bereits vorkonfiguriert und muss nicht explizit angegeben werden.

Anschließend wird im Schritt S8 der Gesamtbetrag ermittelt (also die Rech nung erstellt) und über die hinterlegte Bezahlmethode abgerechnet, d.h. es wird ein Bezahldatensatz generiert und an den Zahlungsdienstleister über mittelt, um den sich ergebenden Geldbetrag einzuziehen. Für die Umsetzung des Verfahren installiert der Kunde bevorzugt in seinem Mobiltelefon 8 die App und hinterlegt dort Daten für einen Zahlungsdienst leister (PayPal, Kreditkarte, Instant Payments, ...). Wenn er ein Lokal 2, das die App unterstützt, betritt, wird er beim Öffnen der App automatisch oder nach Mitwirkung der Kellners mit dem Verkaufsrechner 4 des Lokals 2 ver bunden (Check-in). Das kann automatisch z.B. über Geolokation, einen Blue- tooth-Beacon, das WLAN oder auch einen QR-Code, der an jedem Tisch an gebracht ist, erfolgen.

Fig. 2 zeigt schematisch als Blockschaltbild ein System zur Abwicklung der beschriebenen Verfahren. Das System sieht mehrere Einheiten vor, die in ei nem Gastiaum 2, der ein konkretes Beispiel für einen Verkaufsraum ist, an geordnet sind. Zum einen umfasst das System den Verkaufsrechner 4, in den der Kellner die Bestellungen des Gastes boniert. Der Verkaufsrechner 4 ist über eine nicht weiter bezeichnete Datenverbindung mit einem externen Zentralrechner 6 verbunden, der vom Zahlungsdienstleister, beispielsweise PayPal, Inc. zur Verfügung gestellt wird. Dieser Zentralrechner ist nicht Be standteil des Systems - wie auch der Gastraum 2 nicht. Es kommt lediglich darauf an, dass der Verkaufsrechner 4 Belastungsdaten übermitteln kann, um einen Zahlungsvorgang über den Betrag der Schlussrechnung beim Zent ralrechner 6 anzufordern. Dies kann sogar später, also bezogen auf den Gas taufenthalt offline erfolgen.

Weiter befindet sich im Gastraum 2 mindestens ein Mobiltelefon 8 eines Gas tes, das ein Beispiel für ein mobiles Endgerät ist. Es hat ebenfalls Verbindung zum Zentralrechner 6, wobei die Verbindung während des Bezahlverfahrens gar nicht zwingend vorgehalten werden muss. Entscheidend vielmehr ist es, dass der Gast beim Zahlungsdienstleister registriert ist und dem Verkaufs rechner 4 die entsprechenden Daten, welche dieser zum Ausgleich der Schlussrechnung über den Zahlungsdienstleisters benötigt, zur Verfügung stellt.

Optional umfasst das System auch den QR-Code 10 und/ oder den Trans- ponder 12, über die im Schritt S2 erleichtert oder sogar vollautomatisch das Einbuchen in die Restaurantsoftware möglich ist (Check-in), insbesondere umfassend eine Zuordnung des Gastes zum jeweiligen Tisch.

Auf dem Verkaufsrechner 4 sowie dem Mobiltelefon 8 läuft jeweils ein Soft- warepaket, wobei diese Softwarepakete so ausgestaltet sind, dass in Kommu nikation zwischenVerkaufsrechner 4, Mobiltelefon 8 (gegebenenfalls QR- Code 10 und/ oder Transponder 12) und Zentralrechner 6 im Gastraum 2 das eingangs geschilderte Verfahren ausgeführt werden kann. Dieses Software paket kann auch eine Server basierte Webanwendung sein, für die keine In- stallation notwendig ist.

Um Missbrauch bei Diebstahl des Smartphones 8 vorzubeugen, könnte der Eincheckvorgang (Schritt S2) mit Hilfe eines biometrischen Merkmals oder eines Passwortes abgesichert werden. Gegebenenfalls sind im System Maxi- malwerte, die pro Eincheckvorgang/Tag ausgegeben werden können, vor eingestellt. Optional hängt der Maximalwert von einem Sicherheitsniveau der entsprechend klassifizierten Check-In Methode ab. Bezug sz e ic he nli ste

2 Gastraum 4 V erkauf srechner

6 Zentralrechner 8 Mobiltelefon

10 QR-Code

12 Transponder S1-S9 Schritt