-
Die Erfindung betrifft ein automatisiertes Bezahlsystem und -verfahren, bevorzugt 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 vielen 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 beglichen wird oder der Gastronom aus Kostengründen auf die elektronischen Zahlmethoden verzichtet. Diese Zahlprozesse sind etabliert, weltweit akzeptiert 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 Beteiligung 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 Restaurants 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 Situation 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 abzuschließ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 Eingeladenen 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 kassieren und sicherstellen, dass alle Posten abgedeckt sind. Dies ist ein sehr umständlicher, damit langwieriger Prozess und führt nicht selten zu Verwirrung, insbesondere wenn am Ende Posten übrigbleiben, die dann nachträglich verrechnet werden müssen.
-
Die
EP 2081140 A1 sowie die
EP 2592584 A1 betreffen die Absicherung von Drahtlosbezahlvorgängen, die unter Verwendung eines mobilen Endgerätes, beispielsweise eines Mobilfunkgerätes, sowie ortsfester Positionsgeber, beispielsweise RFID- oder NFC-Tags, durchgeführt werden. Die
WO 2014/105226 A1 offenbart ein System, bei dem ein Kunde sich in einem Warenhaus automatisch zur Abwicklung kontaktloser Zahlungsverfahren anmelden kann, wobei ebenfalls ortsfeste Tags eingesetzt werden. Eine Weiterbildung dieses Systems ist in der
WO 2015/034755 A1 beschrieben. Aus der
WO 2016/053975 A1 ist ebenfalls ein kontaktloses Bezahlverfahren bekannt, 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äufen, 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 Restaurant, 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ängigen 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, jeweils 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äuferindividuellen und/oder kundenindividuellen Ausbuchungsbasisdaten automatisch ausgeführt wird.
-
Dabei wird das Ausbuchen automatisch ausgeführt, indem ein Ausbuchungszeitpunkt, zu dem das Ausbuchen auszuführen sein wird, auf Basis der Ausbuchungsbasisdaten bestimmt wird und/oder indem als Ausbuchungskriterium eine Plausibilität der Abrechnungsdaten auf Basis der Ausbuchungsbasisdaten geprüft wird.
-
Das Ausbuchen erfolgt somit bevorzugt erst, wenn der bestimmte Ausbuchungszeitpunkt erreicht ist und/ oder das Ausbuchungskriterium, Plausibilitä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 Ausbuchungszeitpunkt wird somit einerseits individuell für den Kunden und/ oder den Verkäufer bestimmt, ist jedoch andererseits unabhängig von einem tatsächlichen, 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 Ausbuchungskriterium erfüllt ist. Ist dagegen weder der Ausbuchungszeitpunkt erreicht noch das Ausbuchungskriterium erfüllt oder alternativ entweder der Ausbuchungszeitpunkt 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 vorliegt.
-
Das automatisierte Verfahren bucht den Kunden, z.B. in Form von Daten über dessen mobiles Endgerät, für mehrere Kaufvorgänge in die Verkäufersoftware ein. Dies stellt einen Check-in dar.
-
Die kundenindividuellen und/ oder verkäuferindividuellen Ausbuchungsbasisdaten 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, bereitgestellt werden.
-
Zusätzlich sind oder werden Zahlungsdienstleisterdaten für den Kunden hinterlegt, z.B. per Übertragung vom mobilen Endgerät zur Verkäufersoftware. Dies kann schon im Vorfeld passiert sein (Subskription).
-
Dann werden wiederholt Kaufvorgänge ausgeführt. Für jeden der Kaufvorgä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 erwarteter Abschlusszeitpunkt der Abfolge von Kaufvorgängen, vorzugsweise auch auf Basis der Abrechnungsdaten, ermittelt. Die Kaufumsätze werden insbesondere nur aus denjenigen Abrechnungsdaten übernommen und aufaddiert, deren Plausibilitätsprüfung erfolgreich war. Ist der erwartete Abschlusszeitpunkt erreicht, werden automatisch, d.h. ohne zwingend nötige Mitwirkung des Kunden, Belastungsdaten aus den aufaddierten Kaufumsätzen und den Zahlungsdienstleisterdaten erzeugt und damit die Bezahlung aller berücksichtigten Kaufumsätze vorgenommen. Zugleich erfolgt ein Ausbuchen des Kunden bzw. dessen mobilen Endgeräts aus der Verkäufersoftware.
-
Das automatisiertes Bezahlsystem umfasst die Identifikationseinheit des Kunden, also insbesondere das mobile Endgerät, auf dem eine lauffähige Kundensoftware und gegebenenfalls die Zahlungsdienstleisterdaten gespeichert sind, den Verkäuferrechner, auf dem die lauffähige Verkäufersoftware gespeichert ist oder von dem die auf einem Server laufende Verkäufersoftware aufrufbar ist, und der eine Schnittstelle zur Übertragung von Bezahldaten an einen Zahlungsdienstleister aufweist. Die Kundensoftware und die Verkäufersoftware sind bei Ausführung, auf dem Endgerät bzw. dem Verkäuferrechner oder dem Server, zur Durchführung des genannten Verfahrens ausgebildet.
-
Durch das erfindungsgemäße System bzw. Verfahren kann ein Gast ein Restaurant aufsuchen, bestellen, essen und trinken und dann ohne weiteres gehen. 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 Hintergrund gerückt. Lediglich das Trinkgeld kann noch eine Interaktion erfordern. Je nach Sicherheitsbedürfnis des Kunden können in seltenen Fällen Sicherheitsinteraktion erforderlich sein, aber auch (bei entsprechendem Vertrauen) dem Restaurant zur Behebung überlassen werden.
-
Das System/Verfahren vereinfacht den Bezahlvorgang vor allem durch einen hohen Grad der Automatisierung. Dadurch verschiebt sich grundsätzlich 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 insbesondere in der Gastronomie bei Zechprellerei problematisch. Durch die Erfindung 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, automatischen 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 eines Hauptgerichts, nachdem bereits ein Dessert bestellt wurde, oder die Bestellung neuer Getränke, wenige Minuten nachdem bereits Getränke für alle Gäste bestellt wurden, unplausibel und vom System/im Verfahren abzulehnen. 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 Plausibilitä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 Konsumentenverhaltens gelernt werden. Es kann auch eine Kombination aus beiden Ansätzen vorliegen. Als Basis dieser selbstlernenden Algorithmen können z.B. multivariate Klassifikatoren mit Bayes'schen Schätzungen verwendet werden, um die Wahrscheinlichkeit für die Korrektheit einer Bestellung abzuschätzen. 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 werden, so dass dann keine weitere Buchung zu Lasten des Kunden mehr möglich ist. Dies schützt ihn zusätzlich vor Fehlbuchungen, da der Kellner keine anderen Bestellungen, z.B. die des nächsten Gastes, absichtlich oder versehentlich dem vorherigen Gast zuordnen kann. Um den Zeitpunkt des Check-out vorherzusagen, also zu schätzen, wann das Ende der Abfolge an Kaufvorgängen, mithin das Ende des Kundenbesuchs zu erwarten ist, werden bevorzugt kundenunabhängige Daten (z.B. typische Verweildauer im Restaurant, 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 geschätzt, zu dem der Gast das Restaurant verlassen hat, also die Abfolge von mehreren Kaufvorgängen abgeschlossen sein wird. So ist z.B. nach Bestellung eines Desserts und ggf. Kaffees der Zeitpunkt des Check-outs erwartungsgemäß 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 erwartete 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ügerisches Wiedereinchecken eines richtigerweise ausgecheckten Gastes zu verhindern.
-
Bevorzugt wird ein Wiedereinchecken protokolliert, wodurch im Zweifelsfall nicht die gesamte Zeche streitig wäre, sondern nur der Teil ab dem Wiedereinchecken.
-
Es wird in Ausführungsformen aus den Daten eine Zeitspanne berechnet, nach der keine weitere Bestellung mehr erwartet wird oder die Wahrscheinlichkeit für eine weitere Bestellung unter einen Schwellwert sinkt. Dazu können z.B. Klassifikationsbäume eingesetzt werden oder auch Regressionsverfahren. Wenn innerhalb dieser vorhergesagten Zeitspanne eine weitere Bestellung 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ügerische 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 (nichtstorruerte) 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 kundenindividuell festgelegt werden. Der Kunde selbst könnte auch im System eine Vorautorisierung für einen Betrag X vornehmen, z.B. im Moment der Reservierung. 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 „Vetofrist“ für jede Bestellung, die beginnt, sobald eine Push-Nachricht über die Bestellung an das mobile Endgerät abschickt wurde. Dabei wird jede Bestellung 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 Vetostatus 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 vorkommen, 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 absichtlichen oder (was wesentlich wahrscheinlicher ist) versehentlichen Fehlbuchungen schützen. Die Erfindung sieht dazu vor, den Plausibilitätscheck jeder Bestellung automatisch durchzuzuführen und das Verlassen des Restaurants (und damit den Zeitpunkt des Check-outs) vorherzusagen.
-
Sowohl für das Verfahren als auch für das System ist der Einsatz eines mobilen Endgerätes, das dem Kunden zugeordnet ist, ein bevorzugter Aspekt, denn mithilfe dieses mobilen Endgerätes kann der automatisierte Bezahlvorgang besonders einfach abgewickelt werden. Voraussetzung ist, dass der Kunde an einem elektronischen Zahlungssystem teilnimmt, wie es beispielsweise durch den Anbieter PayPal, Inc. bereitgestellt ist. Auch der Verkäufer (in den genannten Beispielen das Restaurant) nimmt an diesem Bezahlsystem teil, das letztlich den Geldtransfer abwickelt. Derartiges ist dem Fachmann 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 Erfindung 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 werden. Soweit also von einem Gast die Rede ist, ist dies nur als Beispiel für einen 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. Soweit nachfolgend die Beschreibung anhand des Bezahlverfahrens erläutert wird, darf dies ebenfalls nicht als Einschränkung aufgefasst werden. Vielmehr 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 erfindungswesentliche Merkmale offenbaren, noch näher erläutert. Diese Ausführungsbeispiele dienen lediglich der Veranschaulichung und sind nicht als einschränkend auszulegen. Beispielsweise ist eine Beschreibung eines Ausführungsbeispiels mit einer Vielzahl von Elementen oder Komponenten nicht dahingehend auszulegen, dass alle diese Elemente oder Komponenten zur Implementierung notwendig sind. Vielmehr können andere Ausführungsbeispiele auch alternative Elemente und Komponenten, weniger Elemente oder Komponenten 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 werden, können auch auf andere Ausführungsbeispiele anwendbar sein. Zur Vermeidung von Wiederholungen werden gleiche oder einander entsprechende Elemente in verschiedenen Figuren mit gleichen Bezugszeichen bezeichnet und nicht mehrmals erläutert. In den Figuren zeigen:
- 1 ein Ablaufdiagramm einer Ausführungsform eines Bezahlverfahrens in einem Restaurant und
- 2 eine Schemadarstellung eines Systems, mit dem das Bezahlverfahren ausgeführt wird.
-
Wie weiter oben bereits geschildert, wird ein Bezahlverfahren anhand eines Restaurantbesuchs beschrieben, ohne dass dies einschränkend ist.
-
1 zeigt ein Ablaufdiagramm einer ersten Ausführungsform eines Bezahlverfahrens. 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 Endgerät des Kunden eine App (Softwarepaket), die mit einem Rechner 4 des Restaurants zusammenwirkt.
-
Das Verfahren besteht aus drei Blöcken A bis C:
- A - Check-in: Zu Beginn wird der Gast im Rechner 4 des Restaurants registriert (Schritt S1), bevorzugt mit seinem mobilen Endgerät (alternativ kann auch ein anderes Mittel verwendet werden, wie eine Chipkarte oder eine maschinenlesebarer 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 Endgerä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 (Schritt S1)
-
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 eines Bluetooth Beacons 12 automatisch ein. Ggf. muss auf Grund einer zu geringen räumlichen Auflösung des Beacons 12 die Tischnummer jedoch separat 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 individualisierenden 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 eincheckt. In beiden Varianten sind Fehler in der Zuordnung Tisch/Gast vermieden.
-
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 Restaurant zu. Dann liegt automatisch auch der „Lieferort“ für die Speisen, Geträ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 Algorithmen oder Modellen oder Standardvorgaben basieren kann, und dabei gegebenenfalls auch kundenspezifische Daten verwendet: Erscheint in einer Plausibilitätsprüfung (Schritt S3) die im Schritt S2 aufgegebene Bestellung unplausibel (Schritt S4, „-“-Zweig), wird der Kellner darauf hingewiesen und muss die Korrektheit der Buchung bestätigen (Schritt S9), sonst wird sie automatisch verworfen. Ggf. muss der Gast über sein mobiles Endgerät mitwirken, 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 Rechnung automatisch erstellt und über das hinterlegte Bezahlverfahren abgerechnet. 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 festlegelegt wird. Es wird für jeden Kunden dessen erwarteter Zeitpunkt des Verlassens des Restaurants geschätzt (Schritt S6) - also nicht lediglich eine Standardzeitspanne im Sinne eine Time-Out gewartet. Es wird das bisherige Verhalten 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 ausgebucht, und die Rechnung wird geschlossen (Schritt S8) und beim Zahlungsdienstleister zum Begleichen eingestellt. In Ausführungsformen wird aufgrund von Standardvorgaben, die entweder global (z.B. mittlere Aufenthaltsdauer 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 wiederholt 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 auschecken, 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 Rechnung erstellt) und über die hinterlegte Bezahlmethode abgerechnet, d.h. es wird ein Bezahldatensatz generiert und an den Zahlungsdienstleister übermittelt, 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 Zahlungsdienstleister (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 verbunden (Check-in). Das kann automatisch z.B. über Geolokation, einen Bluetooth-Beacon, das WLAN oder auch einen QR-Code, der an jedem Tisch angebracht ist, erfolgen.
-
2 zeigt schematisch als Blockschaltbild ein System zur Abwicklung der beschriebenen Verfahren. Das System sieht mehrere Einheiten vor, die in einem Gastraum 2, der ein konkretes Beispiel für einen Verkaufsraum ist, angeordnet 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 Bestandteil 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 Zentralrechner 6 anzufordern. Dies kann sogar später, also bezogen auf den Gastaufenthalt offline erfolgen.
-
Weiter befindet sich im Gastraum 2 mindestens ein Mobiltelefon 8 eines Gastes, 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 Verkaufsrechner 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 Transponder 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 Softwarepaket, wobei diese Softwarepakete so ausgestaltet sind, dass in Kommunikation zwischen Verkaufsrechner 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 Softwarepaket kann auch eine serverbasierte Webanwendung sein, für die keine Installation 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 Maximalwerte, die pro Eincheckvorgang/Tag ausgegeben werden können, voreingestellt. Optional hängt der Maximalwert von einem Sicherheitsniveau der entsprechend klassifizierten Check-In Methode ab.
-
Bezugszeichenliste
-
- 2
- Gastraum
- 4
- Verkaufsrechner
- 6
- Zentralrechner
- 8
- Mobiltelefon
- 10
- QR-Code
- 12
- Transponder
- S1-S9
- Schritt
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- EP 2081140 A1 [0007]
- EP 2592584 A1 [0007]
- WO 2014105226 A1 [0007]
- WO 2015034755 A1 [0007]
- WO 2016053975 A1 [0007]
