EP4371052A1 - Automatisiertes bezahlsystem und -verfahren - Google Patents

Automatisiertes bezahlsystem und -verfahren

Info

Publication number
EP4371052A1
EP4371052A1 EP22736141.7A EP22736141A EP4371052A1 EP 4371052 A1 EP4371052 A1 EP 4371052A1 EP 22736141 A EP22736141 A EP 22736141A EP 4371052 A1 EP4371052 A1 EP 4371052A1
Authority
EP
European Patent Office
Prior art keywords
data
customer
purchase
payment method
booking
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22736141.7A
Other languages
English (en)
French (fr)
Inventor
Philipp EDLER
Tilo FRITZHANNS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient Currency Technology GmbH
Original Assignee
Giesecke and Devrient Currency Technology GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient Currency Technology GmbH filed Critical Giesecke and Devrient Currency Technology GmbH
Publication of EP4371052A1 publication Critical patent/EP4371052A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/12—Hotels or restaurants
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G06Q20/145—Payments according to the detected use or quantity
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules

Definitions

  • the invention relates to an automated payment system and method, preferably using a customer's mobile terminal device.
  • EP 2081140 A1 and EP 2592584 A1 relate to the protection of wireless payment transactions that are carried out using a mobile terminal device, for example a mobile radio device, and stationary position sensors, for example RFID or NFC tags.
  • WO 2014/105226 A1 discloses a system in which a customer automatically proceeds to process contactless payment in a department store can register, also using fixed tags. A further development of this system is described in WO 2015/034755 A1.
  • a contactless payment method is also known from WO 2016/053975 A1, with which a user can release a payment requested by a seller using a terminal device, for example a mobile phone. In all cases, the cooperation of the customer is required.
  • the invention is therefore based on the object of simplifying the payment process for a sequence of several purchases, e.g. orders in a restaurant, particularly when a mobile terminal device and radio communication are used.
  • the following steps are carried out in a sales unit, e.g for the sequence of purchase transactions, d) adding up the purchase transactions, and e) generating payment data from the total purchase transactions and from the customer's payment service provider data, wherein in step c) the customer's debiting triggers at least step e), and wherein in step c) the customer's debiting is dependent on seller-specific and/or customer-specific basic write-off data is executed automatically.
  • the write-off is carried out automatically by determining a write-off time at which the write-off is to be carried out based on the basic write-off data and/or by checking the plausibility of the accounting data based on the basic write-off data as a write-off criterion.
  • the booking out is therefore preferably only carried out when the specific booking out time has been reached and/or the booking out criterion, plausibility of the billing data of the sequence of purchase transactions, has been met. Reaching of the previously determined log-off time is monitored and can trigger the log-off, in particular if the billing data received is also plausible.
  • the write-off time can be determined on the basis of the basic write-off data and the billing data.
  • the automatic write-off time is thus on the one hand determined individually for the customer and/or the seller, but on the other hand is independent of an actual, possibly manual, active write-off by the customer or seller.
  • the write-off is only carried out automatically if the write-off time has been reached and/or the write-off criterion has been met. If, on the other hand, neither the time of booking out has been reached nor the booking-out criterion has been met, or alternatively either the time of booking out has not been reached or the booking-out criterion has not been met, the customer will not be automatically booked out.
  • the plausibility of the billing data of the sequence of purchase transactions can be checked as soon as the specific write-off time has been reached. Alternatively or additionally, the plausibility of the billing data is checked as soon as billing data for a purchase transaction are received.
  • the booking out can take place in this case if it is recognized on the basis of the basic booking out data that there is a sequence of purchase transactions with plausible billing data that triggers the booking out.
  • the automated procedure books the customer, e.g. in the form of data via his mobile device, into the seller software for several purchase transactions. This constitutes a check-in.
  • the customer-specific and/or seller-specific log-out base data are of course already stored before the log-in step. They can be made available to the seller unit or the seller software, which can be executed on the seller unit or called on a server.
  • payment service provider data is or will be stored for the customer, eg by transmission from the mobile device to the seller software. This may have happened in advance (subscription). Then purchase operations are repeatedly carried out. For each of the purchase processes, billing data, including purchase sales of the respective purchase process, are generated in the vendor software.
  • the billing data can include billing objects (e.g. ordered products/services), prices of the billing objects, order times, etc. They are checked for plausibility using predetermined criteria, and an expected completion time of the sequence of purchase transactions is determined, preferably also on the basis of the billing data. In particular, the purchase sales are only taken from those billing data and added up for which the plausibility check was successful.
  • debit data is automatically generated from the total purchase transactions and the payment service provider data, ie without the customer having to be involved, and all purchase transactions taken into account are paid for.
  • the customer or his mobile end device is logged out of the seller software.
  • the automated payment system includes the customer's identification unit, i.e. in particular the mobile device on which executable customer software and, if applicable, the payment service provider data are stored, the seller computer on which the executable seller software is stored or from which the seller software running on a server can be called up is, and has an interface for the transmission of payment data to a payment service provider.
  • the customer software and the seller software are designed to carry out the process mentioned when they are run on the end device or the seller's computer or the server.
  • the system/procedure simplifies the payment process primarily through a high degree of automation. This fundamentally shifts the risk of the business process away from the provider to the customer. Previously, the entire risk lay with the provider, as they could only check the creditworthiness of their customers when they made the final payment. This is particularly problematic in gastronomy when cheating on a drink. As a result of the invention, the customer agrees to pay in this restaurant as early as the technically supported check-in process. Safeguarding measures are in place to protect customers from incorrect bookings.
  • each order is checked for plausibility. This protects the customer from incorrect bookings. Predetermined criteria are used for this. For example, ordering a main course after a dessert has already been ordered or ordering new drinks a few minutes after drinks have already been ordered for all guests would be implausible and should be rejected by the system/in the process. Criteria can also be used that the system has learned from the individual customers - eg customer does not drink alcohol, is vegetarian, does not consume dessert, etc. Orders that were sorted out in the plausibility check resulted in a warning and require a separate acknowledgment by waiter and/or guest.
  • the plausibility check can be based on fixed rules or it can be learned automatically by the system based on individual consumer behavior. There can also be a combination of both approaches.
  • self-learning algorithms e.g. multivariate classifiers with Bayesian estimates can be used to estimate the probability of an order being correct.
  • Such algorithms are known to the person skilled in the art, e.g ".
  • an expected time is estimated, preferably with the aid of a model, in particular using machine learning, at which the guest has left the restaurant, ie the sequence of multiple purchases will be completed. For example, after ordering a dessert and possibly a coffee, the check-out time is not far away, as expected, while after ordering an aperitif, the guest will probably stay longer in the restaurant. The same applies to purchase transactions in a non-restaurant environment.
  • the expected time is reached, the guest is automatically checked out.
  • the advantage here is that the forecast does not have to be too precise, since the estimated time should be between the last order and shortly after the guest left.
  • the guest can be checked out or checked in again manually. This optionally requires confirmation by the guest in order to prevent a guest who has checked out correctly from checking in incorrectly or even fraudulently.
  • a check-in is preferably logged, which means that in case of doubt the entire bill would not be disputed, but only the part from the check-in again.
  • a period of time is calculated from the data after which no further order is expected or the probability of a further order falling below a threshold value. For this purpose, for example, classification trees or regression methods can be used. If another order is received within this predicted period of time, the calculation is updated. Otherwise, the predicted time is reached when the time period expires.
  • a local presence is required. It is verified by the presence of the smartphone (e.g. scanning the QR code, contact with a Bluetooth beacon, geolocation of the smartphone). If necessary, the (non-cancelled) reservation is sufficient as proof of the customer's presence.
  • a maximum amount can be provided, which cannot be exceeded and can only be changed after a security feature has been checked, e.g. entering a password or checking a biometric feature.
  • the maximum amount can also be determined individually by the system.
  • the customer himself could also carry out a pre-authorization in the system for an amount X, e.g. at the time of reservation.
  • the system can also suggest a default amount for the respective restaurant.
  • An option that increases security even further is a "veto period" for each order, which begins as soon as a push message about the order has been sent to the mobile device.
  • Each order is only canceled after this objection period has expired (e.g. two or three minutes) activated and booked.
  • the customer can object via his smartphone and cancel the order.
  • the veto status of each order is optionally displayed in the kitchen. The chef can then, at his own risk, begin preparation before the deadline or wait until the deadline to prepare or deliver. In practice, it is very rare for the kitchen to start preparing the order within two or three minutes of receiving it. Of course, the veto requires the customer to respond to the push message with their smartphone.
  • the invention achieves a complete relocation of the payment process to the background without a confirmation from the customer, in particular a (manual) invoice verification, being necessary at any point in time. Nevertheless, security mechanisms have been introduced to protect customers from intentional or (which is much more likely) accidental incorrect bookings.
  • the invention provides for the plausibility check of each order to be carried out automatically and for the leaving of the restaurant (and thus the time of the check-out) to be predicted.
  • the use of a mobile end device that is assigned to the customer is a preferred aspect for both the method and the system, because the automated payment process can be handled particularly easily with the help of this mobile end device.
  • the prerequisite is that the customer participates in an electronic payment system, such as that provided by PayPal, Inc., for example.
  • the seller (the restaurant in the examples given) also participates in this payment system, which ultimately handles the money transfer.
  • this is known to the skilled man.
  • the invention is described and explained here with reference to payment in a restaurant, this is purely by way of example. Rather, the invention is aimed at all payment processes in which several individual products or services are obtained in a sequence of purchase processes over a longer period of time and paid for collectively at the end.
  • a guest is mentioned, this is only to be understood as an example of a customer, and the ordering of food and drinks is only an example of the multiple purchase of individual goods or services.
  • the invention is directed to a method of paying in such an environment. It also covers a corresponding system consisting of the devices defined in the corresponding system claim. Insofar as the description is explained below using the payment method, this should also not be interpreted as a restriction. As also explained in the exemplary embodiments, the system can handle the corresponding payment method much more.
  • Fig. 1 is a flowchart of an embodiment of a method of payment in a restaurant
  • Fig. 2 is a schematic representation of a system with which the Beiereverfah ren is executed.
  • 1 shows a flow chart of a first embodiment of a payment method.
  • 2 shows the associated system elements.
  • the guest will preparatoryly register with a payment service provider with whom the restaurant also works.
  • An app (software package) also runs on the customer's end device and interacts with a computer 4 in the restaurant.
  • the procedure consists of three blocks A to C:
  • a - Check-in At the beginning, the guest is registered in the restaurant's computer 4 (step S1), preferably with his mobile device (alternatively, another means can also be used, such as a chip card or a machine-readable code, e.g. a QR code).
  • the guest is usually assigned a location in the restaurant.
  • messages can be exchanged between computer 4 and terminal 8.
  • the guest enters restaurant 2 he has preferably already reserved a table (e.g. via app/website) and can be checked in by the waiter at this table.
  • a table e.g. via app/website
  • he chooses a free table and checks himself in at this table using a QR code 10 attached there or automatically using a Bluetooth beacon 12 .
  • the table number may have to be recorded separately due to insufficient spatial resolution of the beacon 12 .
  • the guest checks himself in with the waiter, e.g. he shows a QR code that individualizes him, which is scanned by the waiter in order to register in the sales computer 4 .
  • the waiter could also show the guest an individual QR code, which the guest uses to check in. In both variants, errors in table/guest assignments are avoided.
  • the restaurant books the guest directly onto a table reserved for them. Then no participation of the guest is necessary.
  • the check-in thus preferentially assigns the guest to a table/place in the restaurant.
  • the "delivery location" for the food, drinks or goods is then automatically determined.
  • step S2 The guest orders quite traditionally from the waiter (step S2) and the waiter books the food/drinks in the sales computer 4 for the guest.
  • a plausibility check is optionally provided according to steps S3, S4, which can be based, for example, on intelligent algorithms or models or standard specifications and, if necessary, also uses customer-specific data: Appears in a plausibility sibility check (step S3), the order placed in step S2 is implausible (step S4, "-" branch), the waiter is made aware of this and must confirm the correctness of the booking (step S9), otherwise it is automatically rejected. the guest must participate via his mobile device, so that an implausible booking requires explicit confirmation by the customer Possibilities for this plausibility check will be explained later.
  • step S4 Only if the plausibility check was successful (step S4, ,,+ branch) is the booking credited to the bill and the guest optionally receives a push message confirming the order on his mobile phone 6, but this does not require any interaction.
  • step S7, S8 When the guest has finished eating and drinking, he leaves the restaurant and is automatically checked out (steps S7, S8).
  • the invoice is created automatically and settled using the stored payment method. He then optionally receives a corresponding push message with the option of giving a tip.
  • the automatic check-out is initiated in a time-controlled manner on the basis of the orders, so that a check-out time is defined.
  • the expected time of leaving the restaurant is estimated for each customer (step S6)—that is, not just a standard period of time in the sense of a time-out is waited for.
  • the previous behavior of the customer and/or other customers is taken into account. Since the time does not have to be very precise (it should be after the guest's last order and no later than shortly after leaving the restaurant), the Easier to estimate, and avoid errors like checking out too early or late. If the time selected was too early, the guest can either be checked in again (by the waiter or by the guest himself), ie the method starts again in step S1.
  • step S7 If the estimated time is reached (step S7, "+” branch), the guest is automatically booked out and the bill is closed (step S8) and the payment service provider is set to pay.
  • the time of booking out is specified.
  • step S7 If the time was not reached (step S7, "-" branch), the system jumps back to step S2 (further orders possible). In step S6, the time of the expected end of the visit is repeatedly estimated or an earlier estimate is updated.
  • the guest can also check himself out after leaving the app, and the waiter can check the guest out in the system when he finds that the guest has left.
  • step S8 an optional question is asked as to whether a tip should be given.
  • a tip is already preconfigured and does not have to be specified explicitly.
  • step S8 the total amount is determined (i.e. the invoice is created) and billed using the stored payment method, ie a payment data record is generated and sent to the payment service provider in order to collect the resulting amount of money.
  • the customer preferably installs the app in his mobile phone 8 and stores data there for a payment service provider (PayPal, credit card, instant payments, ). If he enters a restaurant 2 that supports the app, he is automatically connected to the sales computer 4 of the restaurant 2 (check-in) when the app is opened, or with the cooperation of the waiter. This can be done automatically, for example via geolocation, a Bluetooth beacon, the WLAN or a QR code that is attached to every table.
  • the system schematically shows a system for processing the described method as a block diagram.
  • the system provides for several units arranged in a guest room 2, which is a concrete example of a sales room.
  • the system includes the sales computer 4, in which the waiter makes a note of the guest's orders.
  • the sales computer 4 is connected to an external central computer 6, which is provided by the payment service provider, for example PayPal, Inc., via an unspecified data connection.
  • This central computer is not part of the system - neither is guest room 2. All that matters is that the sales computer 4 can transmit debit data in order to request a payment transaction for the amount of the final invoice from the central computer 6 . This can even take place offline later, i.e. in relation to the guest's stay.
  • At least one mobile phone 8 of a guest TES which is an example of a mobile device. It also has a connection to the central computer 6, with the connection not necessarily having to be maintained during the payment process. Rather, it is crucial that the guest is registered with the payment service provider and the sales computer 4 the relevant data, which this to compensate for Final invoice required by the payment service provider.
  • the system also includes the QR code 10 and/or the transponder 12, which in step S2 facilitates or even fully automatically logs into the restaurant software (check-in), in particular including an assignment of the guest to the respective table .
  • a software package runs on the sales computer 4 and the mobile phone 8, with these software packages being designed in such a way that in communication between the sales computer 4, mobile phone 8 (possibly QR code 10 and/or transponder 12) and central computer 6 in the guest room 2 method described above can be carried out.
  • This software package can also be a server-based web application that does not require any installation.
  • the check-in process (step S2) could be secured using a biometric feature or a password. If necessary, maximum values that can be output per check-in process/day are preset in the system. Optionally, the maximum value depends on a security level of the correspondingly classified check-in method.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

Die Erfindung betrifft ein automatisiertes Bezahlverfahren für eine Zahlung eines Kunden an einen Verkäufer für eine Abfolge von mehreren Kaufvorgängen, wobei folgende Schritte in einer Verkäufereinheit ausgeführt werden: 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 zumindest den Schritt e) auslöst, und das Ausbuchen des Kunden abhängig von vorab gespeicherten verkäuferindividuellen und/ oder kundenindividuellen Ausbuchungsbasisdaten ausgeführt wird, wobei das Ausbuchen automatisch ausgeführt wird, indem vorab ein Ausbuchungszeitpunkt, zu dem das Ausbuchen ausgeführt wird, auf Basis der Ausbuchungsbasisdaten bestimmt wird und/ oder als Ausbuchungskriterium eine Plausibilität der Abrechnungsdaten auf Basis der Ausbuchungsbasisdaten geprüft wird.

Description

Automatisiertes Bezahlsystem und
-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 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 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

Claims

P a t e n t a n s p r ü c h e 1. Automatisiertes Bezahlverfahren für eine Zahlung eines Kunden an einen Verkäufer für eine Abfolge von mehreren Kaufvorgängen, wobei fol gende Schritte in einer Verkäufereinheit ausgeführt werden: 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, dadurch gekennzeichnet, dass das Ausbuchen des Kunden mindestens den Schritt des Erzeugens der Bezahlungsdaten auslöst, und - abhängig von vorab gespeicherten verkäuferindividuellen und/ oder kundenindividuellen Ausbuchungsbasisdaten das Ausbuchen automatisch ausgeführt wird, indem ein Ausbuchungszeitpunkt, zu dem das Ausbuchen auszufüh ren sein wird, auf Basis der Ausbuchungsbasisdaten bestimmt wird und/ oder als Ausbuchungskriterium eine Plausibilität der Abrechnungs daten auf Basis der Ausbuchungsbasisdaten geprüft wird.
2. Automatisiertes Bezahlverfahren nach Anspruch 1, wobei der Ausbu chungszeitpunkt auf Basis der Ausbuchungsbasisdaten und der Abrech nungsdaten bestimmt wird.
3. Automatisiertes Bezahlverfahren nach Anspruch 1 oder 2, wobei das Ausbuchen erst erfolgt, wenn der bestimmte Ausbuchungszeitpunkt erreicht ist und/ oder das Ausbuchungskriterium, Plausibilität der Abrechnungsda ten der Abfolge der Kaufvorgänge, erfüllt ist.
4. Automatisiertes Bezahlverfahren nach einem der obigen Ansprüche, wobei
- die Plausibilität der Abrechnungsdaten der Abfolge von Kaufvorgängen ge prüft wird, sobald der bestimmte Ausbuchungszeitpunkt erreicht ist, oder
- die Plausibilität der Abrechnungsdaten geprüft wird, sobald Abrechnungs daten eines Kaufvorganges empfangen werden, wobei vorzugsweise das Ausbuchen erst erfolgt, wenn auf Basis der Ausbuchungsbasisdaten eine das Ausbuchen auslösende Abfolge von Kaufvorgängen mit plausiblen Abrech nungsdaten erkannt wird.
5. Automatisiertes Bezahlverfahren nach einem der obigen Ansprüche, wobei das Einbuchen des Kunden mittels einer Identifikations-Einheit des Kunden ausgeführt wird, insbesondere mittels eines mobilen Endgerätes, ei ner Chipkarte und/ oder eines maschinenlesbaren Codes, wie eines QR- Codes.
6. Automatisiertes Bezahlverfahren nach einem der obigen Ansprüche, wobei bereits vor dem Schritt des Einbuchens gespeichert sind:
- die vorab gespeicherten kundenindividuellen und/ oder verkäuferindividu ellen Ausbuchungsbasisdaten, und/ oder - die Zahlungsdienstleisterdaten des Kunden.
7. Automatisiertes Bezahlverfahren nach einem der obigen Ansprüche, wobei die vorab gespeicherten Ausbuchungsbasisdaten und/ oder die Zah lungsdienstleisterdaten bereitgestellt werden, insbesondere anhand einer Kunden-ID abgerufen werden, optional von einem externen Server.
8. Automatisiertes Bezahlverfahren nach einem der obigen Ansprüche umfassend wiederholtes Durchführen der folgenden Teilschritte im Schritt b) bei den einzelnen Kaufvorgängen der Abfolge bl) Empfangen der Abrechnungsdaten, umfassend Kaufumsätze eines einzelnen der Kaufvorgänge, b2) Ermitteln des Ausbuchungszeitpunkts in Form eines erwarteten Abschlusszeitpunktes der Abfolge von Kaufvorgängen auf Basis der Abrechnungsdaten.
9. Automatisiertes Bezahlverfahren nach einem der obigen Ansprüche, wobei das Plausibilitätsprüfen der Abrechnungsdaten anhand vorbestimm ter Kriterien durchgeführt wird und in Schritt d) automatisch ein Aufaddie ren der Kaufumsätze aus denjenigen Abrechnungsdaten vorgenommen wird, deren Plausibilitätsprüfung erfolgreich war.
10. Automatisiertes Bezahlverfahren nach einem der obigen Ansprüche, wobei die Ausbuchungsbasisdaten als verkäuferindividuelle Daten eine typi sche Verweildauer in einer Verkaufsstelle, in der die Abfolge der mehreren Kaufvorgänge ausgeführt werden, und/ oder Standardbestellabläufe umfas sen und/ oder als kundenindividuelle Daten eine Historie bereits erworbener Produkte, eine Historie vergangener Abfolgen von Kaufvorgängen und/ o- der eine mit den Abrechnungsdaten verbundene Personenanzahl umfassen.
11. Automatisiertes Bezahlverfahren nach einem der obigen Ansprüche, wobei zur Bestimmung des Ausbuchungszeitpunkts auf Basis der Abrech nungsdaten eine Zeitspanne berechnet wird, nach der kein weiterer Kaufvor gang mehr erwartet wird oder die Wahrscheinlichkeit für einen weiteren Kaufvorgang unter einen vorbestimmten Schwellwert sinkt.
12. Automatisiertes Bezahlverfahren nach einem der obigen Ansprüche, wobei der Ausbuchungszeitpunkt nach jedem Kaufvorgang aktualisiert wird.
13. Automatisiertes Bezahlverfahren nach einem der obigen Ansprüche, wobei die Ausbuchungsbasisdaten unter Verwendung von Methoden des maschinellen Lernens, wie beispielsweise eines Klassifikationsbaums oder ei nes Regressionsverfahrens, ermittelt werden.
14. Automatisiertes Bezahlverfahren nach einem der obigen Ansprüche, wobei eine Bestellung für einen einzelnen Kaufvorgang erst nach Ablauf ei ner Widerspruchsfrist, in der der Kunde über ein mobiles End gerät (8) wi dersprechen und die Bestellung rückgängig machen kann, aktiviert und ge bucht wird.
15. Automatisiertes Bezahlverfahren nach einem der obigen Ansprüche, wobei nach jedem Kaufvorgang eine Nachricht an mindestens ein mobiles Endgerät (8) übermittelt wird, welche die Abrechnungsdaten mindestens teilweise enthält.
16. Automatisiertes Bezahlsystem umfassend eine mobile Identifikations- Einheit (8), insbesondere mobiles End gerät, auf dem eine lauffähige Kun densoftware aufrufbar ist, einen Verkäuferrechner (4), auf dem eine lauffä- hige Verkäufersoftware aufrufbar ist und der eine Schnittstelle zur Übertia- gung von Bezahldaten an einen Zahlungsdienstleister aufweist, wobei die Kundensoftware und die Verkäufersoftware, insbesondere bei Ausführung auf dem Endgerät bzw. dem Verkäuferrechner (4) oder einem Server, zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 13 ausgebil det sind.
EP22736141.7A 2021-07-15 2022-06-13 Automatisiertes bezahlsystem und -verfahren Pending EP4371052A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021003664.6A DE102021003664A1 (de) 2021-07-15 2021-07-15 Automatisiertes Bezahlsystem und -verfahren
PCT/EP2022/025275 WO2023284995A1 (de) 2021-07-15 2022-06-13 Automatisiertes bezahlsystem und -verfahren

Publications (1)

Publication Number Publication Date
EP4371052A1 true EP4371052A1 (de) 2024-05-22

Family

ID=82361365

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22736141.7A Pending EP4371052A1 (de) 2021-07-15 2022-06-13 Automatisiertes bezahlsystem und -verfahren

Country Status (5)

Country Link
US (1) US20240320647A1 (de)
EP (1) EP4371052A1 (de)
CN (1) CN117642760A (de)
DE (1) DE102021003664A1 (de)
WO (1) WO2023284995A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2025222131A1 (en) * 2024-04-19 2025-10-23 Capital One Services, Llc Artificial intelligence driven virtual card payments

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008004383A1 (de) 2008-01-15 2009-07-16 Giesecke & Devrient Gmbh Verfahren und System zum Schutz einer Transaktion
US8924279B2 (en) * 2009-05-07 2014-12-30 Visa U.S.A. Inc. Risk assessment rule set application for fraud prevention
US8498900B1 (en) * 2011-07-25 2013-07-30 Dash Software, LLC Bar or restaurant check-in and payment systems and methods of their operation
DE102011118374A1 (de) 2011-11-11 2013-05-16 Giesecke & Devrient Gmbh Sichere Drahtlos-Transaktion
KR20140110025A (ko) * 2012-01-30 2014-09-16 이베이 인크. 체크인 기반 지불 프로세스를 제공하기 위한 시스템 및 방법
US20130262198A1 (en) * 2012-03-29 2013-10-03 Alan L. Chung Systems and methods for an intelligent cardless loyalty system
US20130346302A1 (en) * 2012-06-20 2013-12-26 Visa International Service Association Remote Portal Bill Payment Platform Apparatuses, Methods and Systems
US8972296B2 (en) 2012-12-31 2015-03-03 Ebay Inc. Dongle facilitated wireless consumer payments
US10176456B2 (en) * 2013-06-26 2019-01-08 Amazon Technologies, Inc. Transitioning items from a materials handling facility
US9445220B2 (en) 2013-09-06 2016-09-13 Paypal, Inc. Systems and methods for enabling additional devices to check in to bluetooth low energy (BLE) beacons
US10271161B2 (en) * 2014-08-06 2019-04-23 Paypal, Inc. Merchant item and service return processing using wireless beacons
US20160092866A1 (en) 2014-09-29 2016-03-31 Mozido, Inc. Providing frictionless push payments
DE102015111659A1 (de) 2015-07-17 2017-01-19 tarent solutions GmbH Verfahren und Anordnung zum Überwachen und/oder Steuern eines Kaufvorgangs in einem Ladengeschäft
US20170352030A1 (en) * 2016-06-02 2017-12-07 Diip, LLC Anonymous mobile payment system
US10846612B2 (en) 2016-11-01 2020-11-24 Google Llc Actionable suggestions for activities
US20210158430A1 (en) * 2018-07-16 2021-05-27 Accel Robotics Corporation System that performs selective manual review of shopping carts in an automated store
DE102019211903A1 (de) 2019-08-08 2021-02-11 Volkswagen Aktiengesellschaft Elektronischer Assistent

Also Published As

Publication number Publication date
CN117642760A (zh) 2024-03-01
WO2023284995A1 (de) 2023-01-19
DE102021003664A1 (de) 2023-01-19
US20240320647A1 (en) 2024-09-26

Similar Documents

Publication Publication Date Title
US20240046301A1 (en) Maintenance of virtual credit card pool for airline passenger vouchers
DE69821992T2 (de) System und verfahren zum steuern von finanziellen überweisungen über ein drahtloses netzwerk
KR20080032101A (ko) 컴퓨터상의 지불 처리 네트워크 및 예약 시스템 실행방법
US10628900B2 (en) Systems and methods for promotional validation of travel expenses
WO2009062330A1 (de) System und verfahren zum betrieb bzw. zur kontrolle von dienstterminals, sowie dazu geeignete vorrichtungen
DE102011088614A1 (de) Verfahren zur Handhabung von elektronischen Gutscheinen
EP2766861A1 (de) Zustellung von postsendungen durch teilnehmer eines zustelldienstes
DE60011658T2 (de) Verfahren und system zur gebrauchskontrolle von zusatzdienstgeräten
DE102016120792A1 (de) Ausschanksystem
US20160078689A1 (en) Systems and Methods for Valet Parking
WO2023284995A1 (de) Automatisiertes bezahlsystem und -verfahren
WO2017089522A1 (de) Verfahren für die ausgabe von produkten aus einem verkaufsautomatensystem sowie ein verkaufsautomatensystem
US8478251B1 (en) Event response apparatus and method
US10515420B2 (en) Method, system and software program for handling and storing purchase transactions between a user and a point-of-sale
KR100848334B1 (ko) Ｓｍｓ을 이용한 사이버 열차티켓 판매시스템 및 판매방법
US11127094B2 (en) Systems and methods for conditional redemption of transportation credits
WO2017072067A1 (de) Verfahren und system zur zahlungsabwicklung
WO2004055748A1 (de) Einrichtung und verfahren zum vorverkauf und zur ausgabe von tickets mittels automaten
KR20120020912A (ko) 국세청 인증 기반 전자 세금계산서 처리 장치 및 방법
DE102016000321A1 (de) Beschreibung eines Systems und Verfahrens zur individualisierten Preisbildung für Güter und Dienstleistungen, für Einkäufe im stationären Handel und im Internet
DE102013205374A1 (de) Verfahren und System zum Erwerb, zur Bevorratung, Entnahme und Abrechnung von Gütern
CN121120105A (zh) 客运数据采集方法、装置、设备、存储介质及程序产品
CN119379392A (zh) 动态运价退改操作方法及其装置、电子设备
AT517552A1 (de) Verkehrsleitsystem
AU2012203332B2 (en) System, Apparatus and Methods for Providing Discounts Using a Reservation System

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240215

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20251217