DE202021000532U1

DE202021000532U1 - Bezahlsystem mit Möglichkeit einer transaktionsspezifischen Rechtesteuerung

Info

Publication number: DE202021000532U1
Application number: DE202021000532.3U
Authority: DE
Original assignee: Individual
Current assignee: Individual
Priority date: 2021-02-12
Filing date: 2021-02-12
Publication date: 2022-02-03
Anticipated expiration: 2031-02-13

Abstract

System zur Eingabe und Verarbeitung von rechtegesteuerten Zahlungen Das System umfasst die Möglichkeit zur Erstellung und zum Einsatz von rechtegesteuerten Zahlungen unter Nutzung einer virtuellen bzw. physischen Bezahlkarte und einer Applikation zum Abgleich des Zahlungswunsches mit den hinterlegten Rechten. Im System kann ein Nutzer eine beliebige Transaktion an einem Zahlungsverkehrsterminal bzw. Online mit seiner Bezahlkarte inkl. rechtegesteuerter Zahlungen durchführen. Dabei wählt der Kunde beim Bezahlvorgang entweder die Bezahlart manuell im System aus oder es erfolgt verschiedener Parameter eine Systemseitige Auswahl des Bezahlweges. Für spezifische Zahlungen kann darüber hinaus auch eine Erfassung eines Belegs im Nachgang zur Transaktion notwendig sein, dies ist beispielsweise bei geschäftlichen Transaktionen der Fall. Hierbei wird im Nachgang die autorisierte Zahlung mit dem Zahlungsbeleg Systemseitig abgeglichen. Zur Durchführung einer rechtegesteuerten Zahlung müssen mehrere Parameter entsprechenden den Möglichkeiten der Rechteeinschränkung Systemseitig geprüft werden. Hier bei wird in einem ersten Schritt bei der Zahlung automatisch geprüft, ob eine passende mögliche rechtebasierte Zahlungsfreigabe vorliegt und diese bei vorliegen der entsprechenden Bedingungen genutzt. Dabei werden im System alle rechtegesteuerten Zahlungen des Nutzers gespeichert und bei jeder Zahlung automatisch geprüft. Dabei werden Systemseitig die notwendigen Daten des mobilen Endgerätes beim Bezahlvorgang, der Bezahlkarte und der entsprechenden rechtegesteuerten Zahlungen geprüft. Im System werden dabei die jeweiligen Rechte der Zahlungen bei Erfassung einer rechtebasierten Zahlung erfasst - dies umfasst im vorliegenden System die Möglichkeit, die Zahlungen auf die folgenden Bereiche einzuschränken:
• Orte
• Zeitpunkte und Zeitspannen
• Händler
• Branchen
• Eigene Einschränkungen
• Einschränkung der Möglichkeit zur Online- bzw. Offlinezahlung Dabei werden im System die relevanten Parameter gespeichert und bei jeder Transaktion entsprechend auf Gültigkeit geprüft. Alle Prüfungen erfolgen dabei innerhalb des Systems und erst bei Vorlage einer gültigen rechtegesteuerten Transaktion wird diese Systemseitig bestätigt und je nach Zahlungsart in einem Vier-Parteien-Bezahlsystem bzw. in einem Drei-Parteien-Bezahlsystem abgewickelt. Rechtebasierende Zahlungen sind somit nur innerhalb des Systems rechtebasierend und werden außerhalb des Systems nach erfolgter Prüfung zu regulären Transaktionen, Somit sind in diesem Ansatz auch keine Händlerseitigen Anpassungen oder Anpassungen bei Clearinghäusern und Banken zur Durchführung der Transaktionen notwendig.

Description

Zusammenfassung: Ein System zur Bezahlung von Waren und Dienstleistungen mit der Möglichkeit zur transaktionsspezifischen Rechtesteuerung. Zum Beispiel kann eine Transaktion eines Nutzers (A) erstellt werden und dabei mit spezifischen Rechten ausgestattet sein, wie der Einschränkung auf eine bestimmte Zeit und einen bestimmten Ort, an welchem die Transaktion durch einen anderen Nutzer (B) zur Zahlung einer Ware oder Dienstleistungen genutzt werden kann. Wenn über die Bedingungen der Transaktion Einigkeit zwischen den Nutzern besteht, wobei beide Mitglieder des Bezahldienstes seien müssen, kann die Bezahlung über das System abwickelt werden und dem transaktionsgebenden Nutzer in Rechnung gestellt werden. Die Bezahlung einer Ware oder Dienstleistungen durch einen Nutzer (B) kann dabei in Abhängigkeit von den Rechten der Transaktion sowohl online mittels virtueller Karte oder auch physisch mittels virtueller Karte auf einem mobilen Endgerät erfolgen, weiterhin sind Transfers und Überweisungen mit transaktionsspezifischen Rechten möglich.
Beschreibung
Technisches Gebiet
Die vorliegende Erfindung betrifft allgemein das technische Gebiet von transaktionsbasierten Zahlungen und in verschiedenen spezifischen Beispielen wird ein System zur Ermöglichung zur Einschränkung von Transaktionen und der Definition von Einsatzrechten zur Durchführung von Bezahlungen zu Lasten Dritter, sowohl bei physischen, als auch bei online-basierenden Transaktionen beschrieben.
Hintergrund
Das Bezahlen von Waren und Dienstleistungen ist ein zentraler Bestandteil unseres täglichen wirtschaftlichen Handelns. Beschränkte sich das Bezahlen zunächst rein auf den Austausch von Geld in Form von Bargeld, hat mit Beginn der 1970er Jahr der elektronische Zahlungsverkehr zunehmend an Bedeutung gewonnen. Seit den 2010er Jahren konnten sich darüber hinaus Bezahlverfahren mit mobilen Endgeräten unter Nutzung z. B.: der NFC-Schnittstellen eines Smartphones etablieren. Im Unterschied zu baren Transaktionen setzt der Austausch von Zahlungen im elektronischen Zahlungsverkehr die Einbindung von entsprechenden regulierten Banken oder banknahen Dienstleistern voraus. Diese wickeln dabei die eigentliche Transaktion zwischen den Beteiligten Parteien ab. In 2021 stehen dem Nutzer somit sowohl Offline, als auch Online eine Vielzahl verschiedener Zahlungsmöglichkeiten zur Verfügung, welche jedoch stets auf dem System des Transfers einer direkt Zahlung von einem Zahlungsgeber zu einem Zahlungsempfänger bestehen.
Stand der Technik
Mit Zahlungen per Smartphone wird seit den 2010er Jahren versucht, dass bezahlen am Point-of-Sale (POS) im analogen Handeln, sowie online weiter zu vereinfachen und zu beschleunigen. Die eigentliche Transaktion der Zahlung hat sich durch den Einsatz der Technik jedoch nicht weiterentwickelt und beruht weiterhin über auf dem direkten Transfer von Geld von einer Person zu einer anderen unter Einbeziehung der notwendigen Kreditinstitute bzw. banknahen Dienstleister. Das sogenannte Zahlungsverfahren (Payment-Schema) regelt dabei die am Prozess Beteiligten und den Ablauf der Transaktion. Die bestehenden Mobile Payment Lösungen funktionieren dabei wie folgt: 1. Der Nutzer hinterlegt in seinem Smartphone eine bestehende Kontoverbindung oder Kreditkarte zur Zahlung 2. Bei der Zahlung wird das mobile Endgerät an das Zahlungsterminal gehalten und es findet ein Austausch der Transaktionsdaten mittels Datenaustausch über Funk - bspw. über Near-Field-Communication (NFC) statt. 3. Die Zahlung wird über die betroffene Bank des Zahlungsgebers an den Zahlungsempfänger transferiert. Das eigentliche Zahlungsverfahren (Payment-Schema) unterscheidet sich dabei nicht grundlegend von einer Zahlung mittels Debitkarte, bspw. einer Maestro-Karte oder einer Kreditkarte. Eine Einschränkung der Zahlung auf spezifische Anwendung, bestimmte Uhrzeiten, Verwendungszwecke oder andere Eigenschaften ist jedoch mit dem aktuellen Stand der Technik nicht möglich. Mit diesem Gebrauchsmusterantrag wird eine Technologie beschrieben, welche die Möglichkeit zur spezifischen Einschränkung von Zahlungen und den Zahlungsablauf beschreibt.
Zu lösende technische Herausforderung
Das Dokument beschreibt ein technisches System mit welchem Zahlungen innerhalb des geschlossenen Systems eingeschränkt und kontrolliert werden können. Das System setzt dabei auf die heutigen gängigen Bezahlverfahren auf und kombiniert diese mit der Technologie zu einem neuen Bezahlsystem.
Offenbarung der Erfindung
Die Erfindung wird durch die beigefügten unabhängigen Ansprüche definiert. Zusätzliche Merkmale und Vorteile der hier offenbarten Konzepte sind in der folgenden Beschreibung dargelegt. Teilweise werden sie auch durch die Beschreibung nahegelegt oder können aus der Praxis der beschriebenen Technologien gelernt werden. Die Merkmale und Vorteile der Konzepte lassen mittels der in den beigefügten Ansprüchen herausgestellten Instrumenten und Kombinationen umsetzen und erzielen.
Die vorliegende Offenbarung beschreibt ein System und eine Anordnung zur Einschränkung von Zahlungen auf spezifische Merkmale. Die Zahlungen kann in dem System dabei auf die folgenden Parameter beschränkt werden:

• Geographischer Ort (Umkreis oder genauer Ort)
• Spezifische Zeit oder Zeitspanne
• Freigabe bestimmter Rechnungen / Zahlungen mit Nachweis
• Bestimmte Dienstleistungen / Händler / Branchen
• Bestimmte Webadresse
• Auswahl Online / Offline-Zahlungen
• Definition Betragshöhe
• Wiederkehrende Zahlung oder einmalige Transaktion
• Währung der Transaktion
• Bestimmte Empfängerdaten für eine Überweisung - mindestens die Kontonummer (im SEPA-Rauffi: IBAN) und Daten der Bank (im SEPA-Raum optional: BIC)

Der Nutzer hat dabei die Möglichkeit nur einzelne Einschränkungen durchzuführen oder auch mehrere Einschränkungen parallel zu wählen - bspw. durch die Auswahl einer Uhrzeit und eines bestimmten Ortes.
Die Technologie kann dabei sowohl bei Zahlungen am Zahlungsverkehrspunkt (engl. „PoS“), als auch bei reinen Onlinetransaktionen und Geldtransfers / Überweisungen durchgeführt werden.
Der Nutzer muss sich einmalig auf einer Plattform anmelden und registrieren. Das System gleicht dabei einem Autorisierungsprozess einer Bank und setzt die Vorlage und Speicherung der essentiellen persönlichen Daten nach der aktuellen Gesetzgebung voraus, dies umfasst aktuell u.a. die Meldeadresse und eine Ausweisung mittels Ausweisdokument. Dieser Prozess dauert nur wenige Minuten.
Nach der Registrierung des Kunden wird ein eigenes Konto eröffnet. Dieses Konto umfasst ein Zahlungsverkehrskonto und eine virtuelle Kreditkarte bzw. Debitkarte zur Bezahlungen von Warte und Dienstleistungen.
Der Nutzer koppelt sein nun eröffnetes Konto der Lösung mit einem eigenen Zahlungsmittel, z. B.: einem Konto oder einer eigenen Kreditkarte. Dieses Konto wird als mögliches Abrechnungskonto benötigt und ermöglicht die Nutzung der Lösung auch als klassische (Mobile) Payment Lösung.
Nach der Einrichtung stehen dem Nutzer die Möglichkeiten der Lösung offen. Jeder Nutzer kann innerhalb des Systems einem anderen Nutzer Rechte zur Nutzung seiner Konten mittels einer rechtegesteuerten Transaktion einräumen oder diese beanspruchen.
Figurenliste
Um bestmöglich darzustellen, wie die oben beschriebenen Ausführungsformen umgesetzt werden, und um weitere Vorteile und Merkmale der Offenbarung zu definieren, folgt nachstehend eine detailliertere Beschreibung, die durch die beigefügten Zeichnungen veranschaulicht wird. Diese Zeichnungen geben nur exemplarische Ausführungsformen der Erfindung wieder und sind daher nicht als in ihrem Umfang einschränkend aufzufassen; die Beispiele werden anhand der beigefügten Zeichnungen mit zusätzlichen Angaben und Details beschrieben und erläutert:

1 zeigt eine beispielhafte Umsetzung in einem Vier-Parteien-Bezahlsystem.
2 zeigt eine beispielhafte Umsetzung in einem Drei-Parteien-Bezahlsystem.
3A zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät.
3B zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät Eingabe Ortsbeschränkung.
3C zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät- Eingabe Zeitbeschränkung.
3D zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät- Eingabe Händlerbeschränkung.
3E zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät - Eingabe Branchenbeschränkung.
3F zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät - Eingabe Besondere Ereignisse / Aktionsbeschränkungen.
3G zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät - Eingabe Online / Offline Beschränkungen.
3H zeigt eine beispielhafte Ausführung der Eingabemaske einer rechtegesteuerten Transaktion auf einem mobilen Endgerät - Bestätigung mittels 2-Faktor Authentifizierung.
4 zeigt die Einrichtung einer Bezahlung mit transaktionsspezifischer Rechtesteuerung.
5 zeigt die Bezahlung am Zahlungspunkt (engl. „Point-of-Sale“) mit einer rechtegesteuerten Transaktion.
6 zeigt die Onlinebezahlung mit einer rechtegesteuerten Transaktion.
7 zeigt ein Ablaufdiagramm einer Transaktion nach 4.
8 zeigt eine Datentabelle einer Transaktion.
9 zeigt die Zusammenführung mehrerer rechtegesteuerter Transaktionen zu einer gemeinsamen Transaktion.
10 zeigt ein Ablaufdiagramm einer Transaktion nach 4 mit der Notwendigkeit eines Belegnachweises zur Zahlung.
11 zeigt eine Beispielhafte Umsetzung bei einem Geldtransfer / Übertrag / Überweisung.
12 zeigt ein Ablaufdiagramm bei einer Transaktion nach FIG: 11.

1 Darstellung des Bezahlsystems am Beispiel eines Vier-Parteien-Bezahlsystems.

(101) Mobiles Endgerät inkl. Lösungs-Applikation (Nutzer A) - mit Hilfe der mobilen Applikation und unter Nutzung einer virtuellen Bezahlkarte wird eine Bezahlung an einem Kartenterminal getätigt. Optional kann in der mobilen Applikation der Beleg der Transaktion mittels eines Fotos erfasst werden und mit der Transaktion verknüpft werden. Weiterhin erfasst das Gerät nach Zustimmung des Nutzers den genauen geographischen Standort und die Geräteuhrzeit.
(102) OCR-Server - Bei Nutzung der Beleg-Archivierung wird der fotografierte Beleg an den OCR-Server zur Erkennung der Daten gesendet und dort analysiert.
(103) System Server - Der System Server stellt das zentrale Kommunikationselement dar und übernimmt dabei die zentralen Koordination für die Freigabe der Zahlungen. Der System Server verarbeitet dabei die von der mobilen Applikation oder dem Portal übertragenen Bezahldaten, sowie geographischen Daten und die Geräteuhrzeit. Eine Kommunikation des System Servers erfolgt dabei mit der Rechnungs-Datenbank (engl. „Invoice Database“) (106) zum Abgleich der Bezahldaten nach Abschluss der Transaktion, dabei wird in der Rechnungs-Datenbank der Zahlbeleg mit der hinterlegten Zahlungen abgeglichen. Bei einer Zahlung mit den Bankdaten einer Drittperson mittels einer rechtegesteuerten Transaktion wird über den PUSH Server (126) der Zahlbeleg an das Benutzerkonto von Nutzer B (Mobile Device 125 / Webportal 128) gesendet. Weiterhin kommuniziert der System Server mit dem Transaktionsserver (107) zum Abgleich der Bezahranfrage mit bestehenden rechtegesteuerte Transaktionen und Erlaubnissen. Daneben verfügt der System Server über eine zentralen Schnittstelle - Dritt API (129) zur Übergabe von Daten an mögliche Drittsysteme. Für die Hinterlegung von eigenen Bankdaten und Kreditkartendaten des Nutzers A und zur Verknüpfung mit dem Nutzer A verfügt der System Server darüber hinaus auch über eine direkte Verbindung zum Zahlungsserver (114).
(104) Kundendatenbank (engl. „Customer Database“) - Vom System Server wird über die Kundendatenbank abgefragt, ob es sich bei der Anfrage um ein gültiges Konto handelt und gleicht diese mit den hinterlegten Nutzerdaten ab. Alle relevanten Nutzer-Stammdaten werden dabei in der Kundendatenbank gespeichert. Im Falle einer nichterfolgreichen Abfrage wird über den System Server an den PUSH Server (126) eine Nachricht gesendet, dass die Transaktion aufgrund fehlender Kundendaten nicht möglich ist.
(105) Betrugsdatenbank (engl. „Fraud Database“) - Nach einer erfolgreichen Abfrage der Kundendaten in der Kundendatenbank wird eine Abfrage der Betrugsdatenbank durchgeführt. In dieser werden bekannte Betrugsfälle und Betrugsversuche sowohl von Händlern, als auch von Kunden gespeichert. Im Falle eines Betrugsfalls werden die Daten der Anfrage in der Datenbank gespeichert und über den System Server (103) an den Push Server (126) eine Zahlungsablehnung gemeldet. Diese Ablehnung wird dem Nutzer A inklusiver einer kurzen Nachricht in der Applikation (101) angezeigt.
(106) Rechnungs-Datenbank - In der Rechnungs-Datenbank werden alle Rechnungsbelege gespeichert, sowohl als Bilddatei, wie auch in die ausgelesenen Informationen als Datenbankeinträge gespeichert.
(107) Transaktionsserver - Auf dem Transaktionsserver werden alle rechtegesteuerte Transaktionen gespeichert und verarbeitet. Der Transaktionsserver spricht dabei sowohl mit dem System Server (103), als auch dem Zahlungsserver (114). Der Transaktionsserver gleicht alle relevanten Informationen der Zahlungsanfrage mit den hinterlegten Datenbanken ab, hierzu zählen die folgenden Datenbanken: Location Database (108), Händler-Datenbank (109), Kunden-Ortsdaten-Datenbank (110), Branchen Datenbank (111) und rechtegesteuerte Transaktion Database (112).
(108) Location Database - Die Location Database gleicht die Daten abgespeicherter rechtegesteuerte Transaktion-Zahlungen mit Hinterlegung eines Ortes ab und überprüft dabei die Daten Ortsdaten mit einem unabhängigen Geolocation Server (113) auf Übereinstimmungen. Weiterhin wird mit Hilfe des Geolocation Servers (113) ein regelmäßiger Abgleich von Ortsdaten von Händlern aus Händler-Datenbank (109) durchgeführt.
(109) Händler-Datenbank - In der Händler-Datenbank sind Händler, Dienstleiter und sonstige Unternehmungen mit Bezahlmöglichkeiten gelistet bei welchem eine rechtegesteuerte Transaktion-Bezahlmöglichkeit eingerichtet wurde. Die Bezahldaten werden dabei standartgemäß mit hinterlegten, erlaubten Zahlungen bei spezifischen Händlern hinterfragt und bei Bedarf autorisiert.
(110) Kunden-Ortsdaten-Datenbank - Mit Hilfe der Kunden-Ortsdaten-Datenbank werden die Ortsdaten des Nutzers gespeichert und zur Verbesserung der Genauigkeit von Transaktionen, wiederkehrenden Zahlungen und aus Sicherheitsgründen gespeichert. Weiterhin erfolgt hier ein regelmäßiger Abgleich der gemeldeten Ortsdaten mit dem Geolocation Server (113) .
(111) Branchen Datenbank - Die Branchen Datenbank enthält eine Liste von Industrien/ Branchen und gleicht die regelmäßig mit der Händler-Datenbank (110) ab. Weiterhin werden die Bezahldaten auch hier mit einer bestehenden rechtegesteuerte Transaktion überprüft, so dass bspw. ein Kunden an einer beliebigen Tankstelle mit der rechtegesteuerte Transaktion zahlen kann.
(112) rechtegesteuerte Transaktion Database - In der rechtegesteuerte Transaktion Database werden alle rechtegesteuerte Transaktion Dateien von Nutzern gespeichert, inklusive ihrer Gültigkeit und aller relevanten Datenfeldern. Dabei erfolgt ein regelmäßiger Abgleich mit den anderen Datenbanken des Transaktionsservers, über diesen erfolgt dabei die Kommunikation.
(113) Geolocation Database - Die Geolocation Database ist ein unabhängiger Server eines anderen Anbieters, welcher dem Abgleich von Geodaten dient. Er kommuniziert dabei sowohl direkt mit der mobilen Applikation (101), wie auch mit der Kunden-Ortsdaten-Datenbank (110) und der Location Database (108).
(114) Zahlungsserver - Der Zahlungsserver dient der eigentlichen Durchführung der Bezahlung. Er kommuniziert dabei mit dem Transaktionsserver (107), dem PAYTN Zahlungsverkehrs-Knotenpunkt (117) und dem Push Server (126). Auf Basis der Informationen der Vorsysteme wird eine der hinterlegten Bankdaten der Bankkonto Datenbank (115) bzw. Kreditkarten in der Kreditkarten Datenbank (116) als Bezahlverfahren ausgewählt und über das PAYTN Zahlungsverkehrs-Knotenpunkt (117) durchgeführt. In Abhängigkeit der Nutzung einer rechtegesteuerte Transaktion wird dabei ein eigenes Konto oder eine eigene Kreditkarte des Nutzers A oder eine Konto bzw. eine Karte eines spezifischen, andern Nutzers - Nutzer B -für die Durchführung der Zahlung genutzt.
(115) Bankkonto Datenbank - In der Bankkonto Datenbank werden alle Bankverbindungen der Kunden gespeichert. Die Kommunikation erfolgt ausschließlich mit dem Zahlungsserver (114). Alle Transaktionsdaten werden hier ebenfalls innerhalb des Systems gespeichert (116) Kreditkarten Datenbank - In der Kreditkarten Datenbank werden alle Kreditkartendaten der Nutzer gespeichert und hinterlegt. Weiterhin besteht die Möglichkeit eine sogenannte „Smart Pre-Authorization Credit Line“ für den Kunden auf Antrag zu hinterlegen. Mit Hilfe dieser Kurzzeitkreditlinie mit einer freidefinierbaren, von der Bonität des Kunden abhängigen Kurzzeit-Kreditlinie mit einer Laufzeit unter 48 Stunden können Zahlungen sofort autorisiert werden und bis zu 48 Stunden nach Zahlungen entweder Systemseitig oder Händisch einer rechtegesteuerte Transaktion oder einem Bankkonto bzw. einer Kreditkarte zur Zahlung zugeordnet werden. Es besteht ausschließlich eine Kommunikation zum Zahlungsserver (114).
(117) Zahlungsverkehrs-Knotenpunkt - Das Zahlungsverkehrs-Knotenpunkt stellt Schnittstelle zu Banksystemen dar und dient der Kommunikation mit Banken und Finanzinstituten. Es handelt sich dabei um eine Plattform, welche verschiedene definierte Kommunikationsschnittstellen zu Banken nutzt, hierzu zählt bspw. die Kommunikation mittels PSD2 oder auch FinTS als Standard in Deutschland. Das Zahlungsverkehrs-Knotenpunkt kommuniziert sowohl mit den Schnittstellen der Banken (119 oder 130), wie auch mit dem Zahlungsserver (114).
(118) Fee Server - Der Fee Server dient der Speicherung von Transaktionsentgelten von Finanzinstituten und Banken. Er kommuniziert dabei mit dem Zahlungsserver (114) zum Abgleich der Zahlungen mit den eingehenden Transaktionsgebühren, welche über das Zahlungsverkehrs-Knotenpunkt (117) gemeldet werden.
(119) Bank Zahlungsverkehrs-Knotenpunkt Ausstellende Bank-Das Bank Zahlungsverkehrs-Knotenpunkt stellt eine standardisierte Schnittstelle einer Bank oder eines Finanzinstitutes dar und dient der Kommunikation zwischen dem Zahlungsverkehrs-Knotenpunkt (117) und dem zu belastenden Kundenkontos eines Nutzers bei einem spezifischen Institut.
(120) Finanz-Prozessor / ACH Server - Ausstellende Bank - Der Server dient der Verarbeitung der Kundenzahlung des spezifischen Instituts und dem Abgleich der Kundendaten.
(121) Bank Zahlungsverkehrs-Knotenpunkt - Annehmende Bank - Das Bank Zahlungsverkehrs-Knotenpunkt stellt eine standardisierte Schnittstelle einer Bank oder eines Finanzinstitutes dar und dient der Kommunikation zwischen dem Bank Zahlungsverkehrs-Knotenpunkt Ausstellende Bank (119) und dem Bank Zahlungsverkehrs-Knotenpunkt - Annehmende Bank (121) und damit der empfangenden Bank dar.
(122) Finanz-Prozessor / ACH Server - Annehmende Bank - Der Server dient der Verarbeitung der Kundenzahlung des spezifischen Instituts und dem Abgleich der Kundendaten.
(123) POS Operating Server - Der Server dient der Verarbeitung der Kundenzahlung des Händlers und ist mit dem Annehmende Bank Zahlungsverkehrs-Knotenpunkt (121 oder 130) verbunden.
(124) POS Terminal - Bezahlterminal bei einem Händler zur Durchführung von Kartenzahlungen.
(125) Mobile Endgerät inkl. Lösungs-Applikation (Nutzer B) - Im Falle einer Zahlung mittels rechtegesteuerte Transaktion wird der Kunde dessen Konto bzw. Karte belastet wurde über die Transkation informiert und erhält eine Push Nachricht vom Push Server (126).
(126) Push Server - Der Push Server stellt einen Kommunikationsserver dar der standardisierte verschlüsselte Informationen zu einer Zielapplikation von Nutzern (101, 125 oder 128) in Abhängigkeit von der Transaktion sendet.
(127) Webportal (Nutzer A) - Ergänzende Möglichkeit der Transaktionsansicht und Einstellung von Zahlungen über ein Webportal.
(128) Webportal (Nutzer B) - Ergänzende Möglichkeit der Transaktionsansicht und Einstellung von Zahlungen über ein Webportal.
(129) Dritt API - Schnittstelle zur Kommunikation und zum Datenaustausch mit anderen Drittsystemen.
(130) Online Zahlungsverkehrs-Knotenpunkt - Bei einer Zahlung über das Internet wird statt eines POS-Terminalsein Online Zahlungsverkehrs-Knotenpunkt des Händlers für die Durchführung der Bezahlung genutzt.

2 (Drei-Parteien-System).
Darstellung des Bezahlsystems am Beispiel eines Drei-Parteien-Systems (200).

(201) Mobiles Endgerät inkl. Lösungs-Applikation (Nutzer A) - mit Hilfe der mobilen Applikation und unter Nutzung einer virtuellen Bezahlkarte wird eine Bezahlung an einem Kartenterminal getätigt. Optional kann in der mobilen Applikation der Beleg der Transaktion mittels eines Fotos erfasst werden und mit der Transaktion verknüpft werden. Weiterhin erfasst das Gerät nach Zustimmung des Nutzers den genauen geographischen Standort und die Geräteuhrzeit.
(202) OCR-Server - Bei Nutzung der Beleg-Archivierung wird der fotografierte Beleg an den OCR-Server zur Erkennung der Daten gesendet und dort analysiert.
(203) System Server - Der System Server stellt das zentrale Kommunikationselement dar und übernimmt dabei die zentralen Koordination für die Freigabe der Zahlungen. Der System Server verarbeitet dabei die von der PAYTN Applikation übertragenen Bezahldaten, sowie geographischen Daten und die Geräteuhrzeit. Eine Kommunikation des System Servers erfolgt dabei mit der Rechnungs-Datenbank (206) zum Abgleich der Bezahldaten nach Abschluss der Transaktion, dabei wird in der Rechnungs-Datenbank der Zahlbeleg mit der hinterlegten Zahlungen abgeglichen. Bei einer Zahlung mit den Bankdaten einer Drittperson mittels einer rechtegesteuerte Transaktion wird über den PUSH Server (226) der Zahlbeleg an das Benutzerkonto von Nutzer B (Mobile Device 225 / Webportal 228) gesendet. Weiterhin kommuniziert der System Server mit dem Transaktionsserver (207) zum Abgleich der Bezahlanfrage mit bestehenden rechtegesteuerte Transaktionen und Erlaubnissen. Daneben verfügt der System Server über eine zentralen Schnittstelle Dritt API (229) zur Übergabe von Daten an mögliche Drittsysteme. Für die Hinterlegung von eigenen Bankdaten und Kreditkartendaten des Nutzers A und zur Verknüpfung mit dem Nutzer A verfügt der System Server darüber hinaus auch über eine direkte Verbindung zum Zahlungsserver (214).
(204) Kundendatenbank - Vom System Server wird über die Kundendatenbank abgefragt, ob es sich bei der Anfrage um ein gültiges Konto handelt und gleicht diese mit den hinterlegten Nutzerdaten ab. Alle relevanten Nutzer-Stammdaten werden dabei in der Kundendatenbank gespeichert. Im Falle einer nichterfolgreichen Abfrage wird über den System Server an den PUSH Server (226) eine Nachricht gesendet, dass die Transaktion aufgrund fehlender Kundendaten nicht möglich ist.
(205) Fraud Database - Nach einer erfolgreichen Abfrage der Kundendaten in der Kundendatenbank wird eine Abfrage der Fraud Datenbank durchgeführt. In dieser werden bekannte Betrugsfälle und Betrugsversuche sowohl von Händlern, als auch von Kunden gespeichert. Im Falle eines Betrugsfalls werden die Daten der Anfrage in der Datenbank gespeichert und über den System Server (203) an den Push Server (226) eine Zahlungsablehnung gemeldet. Diese Ablehnung wird dem Nutzer A inklusiver einer kurzen Nachricht in der Applikation (201) angezeigt.
(206) Rechnungs-Datenbank - In der Rechnungs-Datenbank werden alle Rechnungsbelege gespeichert, sowohl als Bilddatei, wie auch in die ausgelesenen Informationen als Datenbankeinträge gespeichert.
(207) Transaktionsserver - Auf dem Transaktionsserver werden alle „enriched Transactions“ (rechtegesteuerte Transaktion) gespeichert und verarbeitet. Der Transaktionsserver spricht dabei sowohl mit dem System Server (203), als auch dem Zahlungsserver (214). Der Transaktionsserver gleicht alle relevanten Informationen der Zahlungsanfrage mit den hinterlegten Datenbanken ab, hierzu zählen die folgenden Datenbanken: Location Database (208), Händler-Datenbank (209), Kunden-Ortsdaten-Datenbank (210), Branchen Datenbank (211) und rechtegesteuerte Transaktion Database (212).
(208) Location Database - Die Location Database gleicht die Daten abgespeicherter rechtegesteuerte Transaktion-Zahlungen mit Hinterlegung eines Ortes ab und überprüft dabei die Daten Ortsdaten mit einem unabhängigen Geolocation Server (213) auf Übereinstimmungen. Weiterhin wird mit Hilfe des Geolocation Servers (213) ein regelmäßiger Abgleich von Ortsdaten von Händlern aus Händler-Datenbank (209) durchgeführt.
(209) Händler-Datenbank - In der Händler-Datenbank sind Händler, Dienstleiter und sonstige Unternehmungen mit Bezahlmöglichkeiten gelistet bei welchem eine rechtegesteuerte Transaktion-Bezahlmöglichkeit eingerichtet wurde. Die Bezahldaten werden dabei standartgemäß mit hinterlegten, erlaubten Zahlungen bei spezifischen Händlern hinterfragt und bei Bedarf autorisiert.
(210) Kunden-Ortsdaten-Datenbank - Mit Hilfe der Customer Loaction Database werden die Ortsdaten des Nutzers gespeichert und zur Verbesserung der Genauigkeit von Transaktionen, wiederkehrenden Zahlungen und aus Sicherheitsgründen gespeichert. Weiterhin erfolgt hier ein regelmäßiger Abgleich der gemeldeten Ortsdaten mit dem Geolocation Server (113).
(211) Branchen Datenbank - Die Branchen Datenbank enthält eine Liste von Industrien/ Branchen und gleicht die regelmäßig mit der Händler-Datenbank (110) ab. Weiterhin werden die Bezahldaten auch hier mit einer bestehenden rechtegesteuerte Transaktion überprüft, so dass bspw. ein Kunden an einer beliebigen Tankstelle mit der rechtegesteuerte Transaktion zahlen kann.
(212) rechtegesteuerte Transaktion Database - In der rechtegesteuerte Transaktion Database werden alle rechtegesteuerte Transaktion Dateien von Nutzern gespeichert, inklusive ihrer Gültigkeit und aller relevanten Datenfeldern. Dabei erfolgt ein regelmäßiger Abgleich mit den anderen Datenbanken des Transaktionsservers, über diesen erfolgt dabei die Kommunikation
(213) Geolocation Database - Die Geolocation Database ist ein unabhängiger Server eines anderen Anbieters, welcher dem Abgleich von Geodaten dient. Er kommuniziert dabei sowohl direkt mit der mobilen Applikation (201), wie auch mit der Kunden-Ortsdaten-Datenbank (210) und der Location Database (208).
(214) Zahlungsserver - Der Zahlungsserver dient der eigentlichen Durchführung der Bezahlung. Er kommuniziert dabei mit dem Transaktionsserver (207), dem PAYTN Zahlungsverkehrs-Knotenpunkt(217) und dem Push Server (226). Auf Basis der Informationen der Vorsysteme wird eine der hinterlegten Bankdaten der Bankkonto Datenbank (215) bzw. Kreditkarten in der Kreditkarten Datenbank (216) als Bezahlsystem ausgewählt und über das PAYTN Zahlungsverkehrs-Knotenpunkt (217) durchgeführt. In Abhängigkeit der Nutzung einer rechtegesteuerte Transaktion wird dabei ein eigenes Konto oder eine eigene Kreditkarte des Nutzers A oder eine Konto bzw. eine Karte eines spezifischen, andern Nutzers - Nutzer B - für die Durchführung der Zahlung genutzt.
(215) Bankkonto Datenbank - In der Bankkonto Datenbank werden alle Bankverbindungen der Kunden gespeichert. Die Kommunikation erfolgt ausschließlich mit dem Zahlungsserver (214). Alle Transaktionsdaten werden hier ebenfalls innerhalb des Systems gespeichert.
(216) Kreditkarten Datenbank - In der Kreditkarten Datenbank werden alle Kreditkartendaten der Nutzer gespeichert und hinterlegt. Weiterhin besteht die Möglichkeit eine sogenannte „Smart Pre-Authorization Credit Line“ für den Kunden auf Antrag zu hinterlegen. Mit Hilfe dieser Kurzzeitkreditlinie mit einer freidefinierbaren, von der Bonität des Kunden abhängigen Kurzzeit-Kreditlinie mit einer Laufzeit unter 48 Stunden können Zahlungen sofort autorisiert werden und bis zu 48 Stunden nach Zahlungen entweder Systemseitig oder Händisch einer rechtegesteuerte Transaktion oder einem Bankkonto bzw. einer Kreditkarte zur Zahlung zugeordnet werden. Es besteht ausschließlich eine Kommunikation zum Zahlungsserver (214).
(217) Zahlungsverkehrs-Knotenpunkt - Das Zahlungsverkehrs-Knotenpunkt stellt Schnittstelle zu Banksystemen dar und dient der Kommunikation mit Banken und Finanzinstituten. Es handelt sich dabei um eine Plattform, welche verschiedene definierte Kommunikationsschnittstellen zu Banken nutzt, hierzu zählt bspw. die Kommunikation mittels PSD2 oder auch FinTS als Standard in Deutschland. Das Zahlungsverkehrs-Knotenpunkt kommuniziert sowohl mit den Schnittstellen der Banken (219 oder 230), wie auch mit dem Zahlungsserver (214).
(218) Fee Server - Der Fee Server dient der Speicherung von Transaktionsentgelten von Finanzinstituten und Banken. Er kommuniziert dabei mit dem Zahlungsserver (214) zum Abgleich der Zahlungen mit den eingehenden Transaktionsgebühren, welche über das Zahlungsverkehrs-Knotenpunkt (217) gemeldet werden.
(219) Bank Zghlungsverkehrs-Knotenpunkt - Franchaise - Das Bank Zahlungsverkehrs-Knotenpunkt stellt eine standardisierte Schnittstelle einer Bank oder eines Finanzinstitutes dar und dient der Kommunikation zwischen dem Bank Zahlungsverkehrs-Knotenpunkt und dem Zahlungsverkehrs-Knotenpunkt (117).
(220) Finanz-Prozessor / ACH Server - Franchaise - Der Server dient der Verarbeitung der Kundenzahlung des spezifischen Instituts und dem Abgleich der Kundendaten.
(221) POS Operating Server - Der Server dient der Verarbeitung der Kundenzahlung des Händlers und ist mit dem Zahlungsverkehrs-Knotenpunkt der annehmenden Bank (121 oder 130) verbunden.
(222) POS Terminal - Bezahlterminal bei einem Händler zur Durchführung von Kartenzahlungen.
(223) Mobile Endgerät, inkl. Lösungs-Applikation (Nutzer B) - Im Falle einer Zahlung mittels rechtegesteuerte Transaktion wird der Kunde dessen Konto bzw. Karte belastet wurde über die Transkation informiert und erhält eine Push Nachricht vom Push Server (126).
(224) Push Server - Der Push Server stellt einen Kommunikationsserver dar der standardisierte verschlüsselte Informationen zu einer Zielapplikation von Nutzern (101, 125 oder 128) in Abhängigkeit von der Transaktion sendet.
(225) Webportal (NutzerA) - Ergänzende Möglichkeit der Transaktionsansicht und Einstellung von Zahlungen über ein Webportal.
(226) Webportal (Nutzer B) - Ergänzende Möglichkeit der Transaktionsansicht und Einstellung von Zahlungen über ein Webportal.
(227) Dritt API - Schnittstelle zur Kommunikation und zum Datenaustausch mit anderen Drittsystemen.
(228) Online Zahlungsverkehrs-Knotenpunkt - Bei einer Zahlung über das Internet wird statt eines POS-Terminals ein Online Zahlungsverkehrs-Knotenpunkt des Händlers für die Durchführung der Bezahlung genutzt.

3A Eingabemaske einer rechtegesteuerte Transaktion-Zahlung in ein mobiles Endgerät.

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten.
(301) Eingabemaske initiale Eingabe - Beispielhafte Darstellung einer Eingabemaske mit den notwendigen Informationen zur Durchführung einer Transaktion. Dies umfasst die Auswahlmöglichkeit des Abbuchungskontos, die Anzeige des aktuellen Guthaben / der aktuellen Verfügbarkeit, eine Auswahl des Empfängers, der Betragshöhe und des Verwendungszwecks. Weiterhin besteht ergänzend die Möglichkeit die Zahlungen nach Ort, Zeit, bestimmten Händlern / Unternehmen, Branchen, Aktionen oder auch nach Online- und Offline-Bezahlmöglichkeiten einzuschränken.

3B zeigt eine beispielhafte Ausführung der Eingabemaske einer mobilen rechtegesteuerte Transaktion - Eingabe Ortsbeschränkung.

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten.
(302) Eingabemaske Ortsbeschränkung - Beispielhafte Darstellung einer Eingabemaske mit den notwendigen Ortsinformationen und zur Einstellung von möglichen Radien / Umkreisen um einen Ort.

3C zeigt eine beispielhafte Ausführung der Eingabemaske einer mobilen rechtegesteuerte Transaktion - Eingabe Zeitbeschränkung.

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten.
(303) Eingabemaske Zeitbeschränkung - Beispielhafte Darstellung einer Eingabemaske mit den notwendigen Zeitinformationen.

3D zeigt eine beispielhafte Ausführung der Eingabemaske einer mobilen rechtegesteuerte Transaktion - Eingabe Händlerbeschränkung.

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten.
(304) Eingabemaske Händlerbeschränkung - Beispielhafte Darstellung einer Eingabemaske mit den notwendigen Händlerinformationen.

3E zeigt eine beispielhafte Ausführung der Eingabemaske einer mobilen rechtegesteuerte Transaktion - Eingabe Branchenbeschränkung.

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten.
(305) Eingabemaske Branchenbeschränkung - Beispielhafte Darstellung einer Eingabemaske mit den notwendigen Brancheninformationen.

3F zeigt eine beispielhafte Ausführung der Eingabemaske einer mobilen rechtegesteuerte Transaktion - Eingabe Besondere Ereignisse / Aktionsbeschränkungen.

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten.
(306) Eingabemaske Zeitbeschränkung - Beispielhafte- Darstellung einer Eingabemaske mit den notwendigen Ereignissen / Aktionen.

3G zeigt eine beispielhafte Ausführung der Eingabemaske einer mobilen rechtegesteuerte Transaktion - Eingabe Online / Offline Beschränkungen.

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten.
(307) Eingabemaske Online / Offine Beschränkung - Beispielhafte, Darstellung einer Eingabemaske mit den notwendigen Informationen.

3H zeigt eine beispielhafte Ausführung der Zusammenfassungsseite einer mobilen rechtegesteuerte Transaktion-Zahlung und Bestätigung mittels 2-Faktor Authentifizierung.

(103) System Server - Beispielhafte Darstellung eines System Servers zur Speicherung der Daten und zur Abfragen von Stammdaten.
(126) Push Server - Beispielhafte Darstellung eines Push Servers zur Übermittelung eines 2-Faktors zur Freigabe der Zahlung.
(308) Zusammenfassung rechtegesteuerte Transaktion - Beispielhafte Darstellung einer Zusammenfassungsmaske mit den notwendigen Informationen
(309) Eingabeseite 2-Faktor-Authentifizierung - Beispielhafte Darstellung einer Bestätigung einer Zahlung mittels zweitem Faktor.

4 zeigt die Bezahlung mit einer rechtegesteuerten Transaktion und das Zusammenspiel zwischen Nutzer (Warenempfänger), System und Nutzer (Zahlender).

(401) Ein Nutzer erwirbt eine Ware oder Dienstleistung und ist Empfänger dieser Handlung.
(402) Zur Zahlung wählt der Kunde eine spezifische, eingeschränkte Transaktion aus und nutzt diese für den Bezahlvorgang.
(403) Überprüfung ob die Bedingungen ausgewählte, eingeschränkte aus (402) bzw. (405) vorliegen. Wenn ja, dann wird der Prozess bei (404) fortgesetzt. Liegen die Bedingungen bei der Zahlung nicht vor, wird das eigenen Konto des Nutzers belastet (406).
(404) Wenn alle Bedingungen der rechtegesteuerten Transaktion erfüllt sind, wird das Konto des Transaktionsgebers belastet.
(405) Der Nutzer wählt für die Zahlung die virtuelle Standardeinstellung des Bezahlsystems
(406) Das System überprüft Standardgemäß, ob eine passende eingeschränkte Transaktion vorliegt, wenn ja schließt Prozessschritte (403) an, andernfalls wird das eigene Konto (407) belastet.
(407) Sofern keine eingeschränkte Zahlung vorliegt wird das eigenen Konto des Nutzers (Warenempfängers) belastet.

5 zeigt die Onlinebezahlung mit einer rechtegesteuerten Transaktion.

(501) Ein Nutzer erwirbt eine Ware oder Dienstleistung und ist Empfänger dieser Handlung.
(502) Zur Zahlung wählt der Kunde ein mobiles Bezahlverfahren mittels hinterlegter virtueller Kreditkarte bspw. Apple Pay.
(503) Zur Zahlung hinterlegt der Kunde seine virtuellen Kreditkartendaten der Lösung und gibt diese Kartendaten zur Belastung an.
(504) Die Zahlungsdaten der virtuellen Kreditkarte werden durch das System auf ihre Gültigkeit und Verfügbarkeit geprüft. Zur Autorisierung kann die Bestätigung mittels eines weiteren Faktors möglich sein - Mehr-Faktor-Authentifizierung. Ist diese gegeben wird der Prozess bei (506) zur Überprüfung einer vorliegenden eingeschränkt Zahlung fortgesetzt. Sind die Daten nicht gültig, ist das Konto gesperrt oder liegt ein anderer die Zahlung verhindernder Grund vor wird die Zahlung abgelehnt (505).
(505) Ablehnung der Transaktion und Beendigung des Prozesses .
(506) Das System überprüft Standardgemäß, ob eine passende eingeschränkte Transaktion vorliegt, wenn ja schließt Prozessschritte (507) an, andernfalls wird das eigene Konto (509) belastet.
(507) Überprüfung ob die Bedingungen ausgewählte, eingeschränkte der Transaktion vorliegen. Wenn ja, dann wird der Prozess bei (508) fortgesetzt. Liegen die Bedingungen bei der Zahlung nicht vor, wird das eigenen Konto des Nutzers belastet (509).
(508) Wenn alle Bedingungen der rechtegesteuerten Transaktion erfüllt sind, wird das Konto des Transaktionsgebers belastet.
(509) Sofern keine eingeschränkte Zahlung vorliegt wird das eigenen Konto des Nutzers (Warenempfängers) belastet.

6 zeigt die Bezahlung am Point of Sales mit einer rechtegesteuerten Transaktion mit einem Belegnachweis.

(601) Ein Nutzer erwirbt eine Ware oder Dienstleistung und ist Empfänger dieser Handlung.
(602) Zur Zahlung wählt der Kunde eine spezifische, eingeschränkte Transaktion aus und nutzt diese für den Bezahlvorgang.
(603) Überprüfung ob die Bedingungen ausgewählte, eingeschränkte aus (602) bzw. (605) vorliegen. Liegt keine eingeschränkte Zahlung vor wird der Prozess bei (607) mit der Belastung des eigenen Kontos fortgesetzt. Bei Erfüllung aller Bedingungen wird endet der Prozess mit der Abbuchung von einem Fremdkonto (604). Für den Fall das die Fremdkonto-Belastung erst nach Belegnachweis autorisiert werden kann wird der Prozess bei (608) fortgesetzt.
(604) Wenn alle Bedingungen der rechtegesteuerten Transaktion erfüllt sind, wird das Konto des Transaktionsgebers belastet.
(605) Der Nutzer wählt für die Zahlung die virtuelle Standardeinstellung des Bezahlverfahrens.
(606) Das System überprüft Standardgemäß, ob eine passende eingeschränkte Transaktion vorliegt, wenn ja schließt Prozessschritte (403) an, andernfalls wird das eigene Konto (407) belastet.
(607) Sofern keine eingeschränkte Zahlung vorliegt wird das eigenen Konto des Nutzers (Warenempfängers) belastet.
(608) Die Zahlung des Kunden wird auf der virtuellen Kreditkarte vorautorisiert und zunächst genehmigt - ein Beleg muss innerhalb einer zu definierten Frist hinzugefügt werden (609).
(609) Der Nutzer muss entweder per integrierter Kamera des Geräts ein Photo des Belegs machen oder diesen als Anhang in das System laden, so dass der Beleg mit den Bedingungen der Zahlungen (610) im nächsten Schritt überprüft werden kann.
(610) Der Beleg wird automatisch auf die Bedingungen der Zahlung überprüft. Liegen diese vor, wird das Fremdkonto (604) belastet und der Beleg dem Zahler übermittelt. Liegen die Bedingungen nicht vor, wird das eigene Konto belastet (607).

7 zeigt den Datenfluss der Einrichtung einer rechtegesteuerten Transaktion.

(701) Auswahl des Empfänger-Namen-der Empfänger-Name stellt dabei den Benutzernamen des Empfängers im System dar oder alternative die Mobiltelefonnummer oder E-Mail bzw. ein anderes den Empfänger eindeutig im System zu identifizierendes Merkmal.
(702) Eingabe des Betragshöhe der Transaktion - hier wird die Währung des Nutzers als Default-Währung genutzt.
(703) Auswahl ob es sich um eine einmalige, mehrmalige oder dauerhafte Transaktion handelt. Bei einer einmaligen Transaktion handelt es sich um eine Transaktion die in der ausgewählten Betragshöhe einmalig zu einem Kauf berichtigt. Bei einer mehrmaligen Transaktion kann eine Transaktion unter Einhaltung der Berechtigungen beliebig häufig bis zur Erreichung des Betrags wiederholt werden. Bei einer dauerhaften Transaktion wird durch den Nutzer eine Art Kreditfunktion in dieser Höhe gewährt, welche abhängig von der gewählten Zeit immer wieder bis zur Erreichung der Betragshöhe in einer definierten Zeitspanne zur Verfügung steht. Die kleinste mögliche Zeiteinheit stellt dabei eine Minuteneinheit dar und kann dann variabel über Stunden, Tage, Wochen, Monate oder Jahre angepasst werden.
(704) Auswahl oder Änderung der Währung der Transaktion - per Default ist die Währung des Zahlenden hinterlegt.
(705) Verpflichtende Bezeichnung der Transaktion. Diese Bezeichnung dient der Übersichtlichkeit und wird Anzeige bei der Transaktion stets angezeigt, zum Beispiel in der Übersichtseite der Transaktionen.
(706) Freitext-Feld mit bis zu 400 Zeichen zur (Detail-)Beschreibung der Transaktion.
(707) Hier wählt von welchem Zahlungsmittel die Transaktion gezahlt wird.
(708) Auswahlmöglichkeit in wie weit zusätzlich Rechte eingeschränkt werden sollen. Bei einer Rechte-Einschränkung geht der Prozess bei (709) weiter, soll die Zahlung einfach als Transaktion ohne bestimmte Rechte-Einschränkung durchgeführt werden, ist der Prozessschritt Freigabe (716) der nächste Schritt.
(709) Hier kann der Nutzer auswählen an welchen Orten die Transaktion gültig sein soll. Die Erfassungsmöglichkeit stellt sowohl einzelnen Orte, mehrere Orten, wie auch definierten Strecken dar. Es besteht jeweils auch die Möglichkeit zusätzliche einen Radius innerhalb dessen die Zahlung möglich ist, einzustellen. Anbei eine Veranschaulichung an einem Beispiel: Der Nutzer wählt die Adresse „Musterstraße 1, Musterstadt“ mit einem Radius von 4km aus und ermöglicht damit eine Zahlung an dieser Anschrift und in einer Luftlinie von 4 km aus, an welchem die Bedingung zur Zahlung erfüllt ist.
(710) Durch Auswahl der Zeit kann die Gültigkeit und Anwendung der Transaktion ebenfalls eingeschränkt werden. Zu den Auswahlmöglichkeiten zählen, das Datum, Tage, Monate, Jahre, zu definierende Zeitspannen und die Uhrzeit. Der Nutzer hat die Möglichkeit sowohl den Start- und Endpunkt der Einschränkung auszuwählen, wie auch mehrere Ereignisse zu verknüpfen und einen übergreifenden Start- und Endpunkt zu wählen. An einem Beispiel ist dies verständlicher: Der Nutzer gibt an, dass eine Zahlung immer Montags von 8 - 9 Uhr möglich ist und wählt zusätzlich als übergreifenden Start- und Endpunkt, dass diese Regelung vom 01.01. bis zum 31.03. gültig ist.
(711) Eine weitere Möglichkeit der Rechtsteuerung besteht in der Eingabe bestimmter Bedingung die zur Auswahl erfüllt sein müssen. Zu diesen Rechten zählen beispielhaft die Freigabe der Zahlung erst nach erneuter Freigabe durch den Nutzer, die Freigabe der Zahlung erst nach Upload eines Zahlungsnachweises oder die sofortige Freigabe der Zahlung und einen Widerruf der Zahlung wenn nicht innerhalb einer spezifischen Zeit eine Zahlungsnachweis geuploaded wird. Die zeitversetzte Freigabe setzt eine Kreditfunktion oder Vorfinanzierung über ein anderes Konto auf dem Empfänger-Konto zur Zahlung der Transaktion voraus.
(712) Weiterhin besteht die Möglichkeit verschiedene systemseitige Ereignisse / Beispieleinstellungen für bestimmte Events zu übernehmen. Zu diesen Ereignissen zählen Geburtstag, Hochzeitstag oder sonstige spezifische Events. Hier wird der Nutzer zusätzlich an das spezifische Event systemseitig erinnert.
(713) Durch die Auswahl bestimmter Händler kann die Zahlungsmöglichkeit auf diese Orte eingeschränkt werden. Überprüft wird diese u.a. durch den Abgleich der Händlerliste mit den geographischen Daten des Endgeräts bei einer mobilen Transaktion.
(714) Weiterhin besteht die Auswahlmöglichkeit bestimmter Branchen für Zahlungen. In diesem Fall werden automatische Händler der bestehenden Branche bei der Zahlung autorisiert.
(715) Zuletzt besteht die Möglichkeit der Auswahl ob die Zahlung Online, nur-Offline oder Online + Offline durchgeführt werden kann. Zusätzlich kann der Kunde bestimmte Websiten zur Freigabe einrichten oder sperren. Per Default ist die Auswahl „nur-Offline“.
(716) Abschluss des Prozesses durch Bestätigung der Auswahl - anschließend erfolgt eine 2-Faktor-Authenfizierung der Transaktion, ähnlich dem in 3H dargestellten Beispiel.

8 zeigt die Felder einer bespielhaften Transaktion.
9 zeigt die Zusammenführung mehrere rechtegleicher Transaktionen zu einer gemeinsamen Transaktion.

(901) Der Nutzer verfügt über verschiedene eingeschränkte Zahlungen mit gleichen Rechten.
(902) Der Nutzer wählt mehrere dieser Transaktionen aus und möchte diese zu einer Gesamttransaktion zusammenführen, beispielweise bei einem Geburtstagsgeschenk.
(903) Systemseitig werden die Einzelrechte der Transaktionen überprüft und abgeglichen. Sofern die Transaktionen kombinierbar sind werden die Einzelrechte in einer Datenbank gespeichert und mit der neuen übergreifenden Transaktion verknüpft (906) und dem Nutzer eine neue zusammengeführte Transaktion übermittelt (905). Sind die Transaktionen nicht kombinierbar wird die Zusammenführung abgelehnt (904) bzw. einzelne Transaktionsbestandteile abgelehnt.
(904) Dem Nutzer werden die einzelnen abgelehnten Transaktionen angezeigt.
(905) Dem Nutzer wird die neue Transaktion angezeigt. Diese Transaktion wird regelmäßig auf Veränderungen der einzelnen Transaktionen geprüft (906).
(906) In der Systemdatenbank werden sowohl die Recht der einzelnen Transaktion, wie auch die Rechte der neuen gemeinsamen Transaktion gespeichert. Dem Nutzer wird nur noch die neue Gesamttransaktion (905) angezeigt, die Einzeltransaktionen bleiben lediglich Systemseitig bestehen und werden regelmäßig auf ihre Gültigkeit überprüft. Bei einer Zahlung mit der neuen Transaktion kann der Nutzer jedoch wählen, ob er eine bestimmte (Unter-) Transaktion belasten möchte oder den Rechnungsbetrag in einer beliebig zu wählenden Form aufteilt.

10 zeigt die Bezahlung einer Überweisung unter Nutzung einer rechtegesteuerten Zahlung.

(1001) Der Nutzer wählt im Menü eine Überweisung als gewünschte Handlung aus.
(1002) Auswahl einer bestimmten rechtegesteuerten Transaktion zur Überweisung - Vorausfüllung aller relevanten Informationen. Anschließend kommt es zur Überprüfung der Rechteeinhaltung (1003).
(1003) Überprüfung ob die Rechte einer spezifischen Transaktion für die Überweisung eingehalten wurden und anschließend Abschluss der Zahlung durch Eingabe einer Autorisierung (1004).
(1004) Die Autorisierung einer Überweisung erfolgt durch einen weiteren Faktor. In Abhängigkeit ob eine Fremde-Transaktionserlaubnis vorliegt (1006 bzw. 1002) und diese erfolgreich bestätigt wurde in Prozessschritt (1003) wird die entsprechende spezifische Transaktion als Mittel für die Zahlung hinterlegt und das entsprechende Fremdkonto (1008) belastet. Andernfalls kann der Nutzer nur eines seiner eigenen Bankverbindungen auswählen und die Bezahlung durchführen (1007).
(1005) Der Nutzer gibt mindestens eine IBAN, einen Empfängername und eine Betragssumme, der Verwendungszweck und das Mittel der Überweisung (z. B.: Regulär oder als Instant Payment Zahlung) sind optional. Anhand dieser Informationen wird das Vorhandensein einer passenden rechtegesteuerten Zahlung geprüft (1006).
(1006) Standardgemäß wird bei jeder Überweisung überprüft ob die Merkmale der Überweisung mit einer bestehenden rechtegesteuerten Transaktion übereinstimmen. Ist dies der Fall wird eine Überprüfung der Bedingungen angestoßen (1003), andernfalls wird die Zahlung zur Freigabe mittels Eingabe eines weiteren Faktors (1004) freigegeben.
(1007) Im Falle einer nichtvorliegenden spezifischen Transaktion wird ein eigenes Konto des Nutzers belastet.
(1008) Sofern alle Bedingungen einer spezifischen Transaktion für eine Überweisung erfüllt sind wird ein Fremdkonto belastet.

11 zeigt eine Beispielhafte Umsetzung bei einem Geldtransfer / Übertrag / Überweisung.

(1101) Der Nutzer erfasst in der mobilen Applikation eine Überweisung an einen andere Empfänger (1122). Neben der händischen Erfassung einer Bezahlung kann ein Überweisungsträger oder Zahlungsauftrag mittels Photo erfasst werden und durch Sendung an den OCR Server (1112) abgeglichen werden und somit die notwendigen Zahlungsdaten erfasst werden. Die Transaktion wird bei der Erfassung an den Systemserver (1103) übermittelt.
(1102) Der Nutzer erfasst in der Web-Applikation eine Überweisung an einen anderen Empfänger (1122). Die Transaktion wird bei der Erfassung an den Systemserver (1103) übermittelt.
(1103) Der Systemserver prüft die Transaktionen auf die Korrektheit der Kundendaten (1104) und gegen die Betrugsdatenbank (1105). Im Falle einer Fehlermeldung wird der Kunde über eine abgebrochene Transaktion über den PUSH Server (1115) informiert. Andernfalls wird die Transaktion an den Transaktions-Server (1106) übergeben.
(1104) Die Kunden-Datenbank enthält alle wesentlichen Kundendaten des Nutzers.
(1105) In der Betrugs-Datenbank werden auffällige IBANs und Betrugsfälle gespeichert.
(1106) Der Transaktions-Server überprüft ob für die Transaktion eine passende rechtegesteuerte Transaktion vorliegt, hierzu wird die IBAN / BIC-Datenbank nach passenden Einträge überprüft. Bei einer passenden Transaktion wird die dort hinterlegte Bankverbindung an den Zahlungsserver (1109) übertragen, andernfalls wird die Standard-Kontoverbindung des Nutzers an den Zahlungsserver (1109) übergeben. Die Transaktion wird in der Transaktions-Datenbank.(1107) gespeichert.
(1107) In der Transaktions-Datenbank wird jede Zahlung dauerhaft gespeichert und so für den Nutzer jederzeit einsehbar.
(1108) In der IBAN / BIC Datenbank werden alle relevanten Informationen eine rechtegesteuerten Transaktion gespeichert.
(1109) Der Zahlungsserver dient der Verarbeitung der Zahlungen und zur Übergabe der Zahlung an das Zahlungsverkehrs-Knotenpunkt (1114) zur Kommunikation mit den Fremdbanken. Weiterhin wird nach der Hinterlegung der korrekten Bankverbindung aus der Bankaccount Datenbank (1110) oder der Kreditkarten-Datenbank (1111) eine Nachricht an den PUSH Server (1115) zur Sendung einer Zahlungsfreigabe gesendet. Bei Nutzung einer Bankverbindung eines anderen Nutzers durch Nutzung einer rechtegesteuerten Transaktion wird der entsprechende Nutzer über die Transaktion auf dem mobilen Endgerät (1116) oder dem Portal (1117) informiert.
(1110) In der Bankaccount-Datenbank sind alle relevanten Daten einer Bankverbindung gespeichert.
(1111) In der Kreditkarten-Datenbank sind alle relevanten Kreditkartendaten eines Nutzers gespeichert.
(1112) Der OCR Server dient der Erkennung und Erfassung eines physischen Zahlungsaufträgs aus der mobilen Applikation (1101). Der Beleg wird auf der Rechnungs-Datenbank (1113) gespeichert.
(1113) In der Rechnungs-Datenbank werden alle über ein mobiles Endgerät erfassten Zahlungsaufträge erfasst.
(1114) Das Zahlungsverkehrs-Knotenpunkt verbindet die Lösung mit allen Drittbänken und anderen Zahlungsverkehrsdienstleistern mittels Standard-Schnittstellen.
(1115) Der PUSH Server erfüllt mehrere Zwecke. Er sendet zum einen den Nutzer einen transaktionsspezifischen Code zur Ausführung einer Zahlung als Zweitfaktor. Weiterhin wird der aktuelle Status der Zahlung über den PUSH Server an die mobile Applikation (1101) übertragen.
(1116) Sofern ein Nutzer eine Fremdbankverbindung mittels einer rechtegesteuerten Transaktion nutzt, wird der entsprechende Zahlender in der mobilen Applikation über die Transaktion informiert.
(1117) Sofern ein Nutzer eine Fremdbankverbindung mittels einer rechtegesteuerten Transaktion nutzt, wird der entsprechende Zahlender im Portal über die Transaktion informiert.
(1118) Standard-Schnittstelle der Bank des Zahlungspflichtigen zur Kommunikation mit dem Zahlungsverkehrs-Knotenpunkt (1114) und der Kommunikation mit der Bank des Zahlungsempfängers (1120).
(1119) Zentraler Bank-Server der Bank des Zahlungspflichtigen.
(1120) Standard-Schnittstelle der Bank des Zahlungsempfänger zur Kommunikation mit der Bank des Zahlungspflichtigen (1118).
(1121) Zentraler Bank-Server der Bank des Zahlungsempfängers.
(1122) Zahlungsbeleg für den Zahlungsempfänger.

12 zeigt ein Ablaufdiagramm bei einer Transaktion nach 11.

(1201) Der Nutzer erfasst eine Zahlung durch manuelle Eingabe oder Erfassung mittels Photo und Analyse mittels OCR.
(1202) Auswahl der Betragshöhe für die Überweisung.
(1203) Auswahl ob es sich um eine einmalige oder wiederkehrende Zahlung handelt.
(1204) Auswahl der Währuhg.
(1205) Name der Transaktion / Verwendungszweck.
(1206) Beschreibung der Transaktion (Optionales Feld) für weitere Informationen.
(1207) Das System überprüft das Vorliegen einer passenden, rechtegesteuerten Zahlung.
(1208) Bei Vorliegen einer passenden Transaktion wird ein Fremdkonto ausgewählt und dem Nutzer angezeigt.
(1209) Sofern keine passende, rechtegesteuerte Transaktion vorliegt, wird das eigene Standardkonto ausgewählt - der Nutzer kann dieses auch in ein anderes eigenes Konto ändern.
(1210) Bestätigung der Zahlung und Anzeige aller relevanten Informationen der Zahlungen.
Freigabe der Zahlung mittels eines zweiten Faktors (z. B.: Eingabe eines Codes).
(1212) Das ausgewählte Konto wird belastet.

Beschreibung wenigstens eines Weges zur Umsetzung
Nachstehend wird' eine Ausführungsform eines Systems und einer Anordnung ausführlich erörtert. Auch wenn eine spezifische Umsetzung diskutiert wird, erfolgt dies nur zu Veranschaulichungszwecken. Ein Fachmann wird erkennen, dass andere Komponenten, Konfigurationen und Schritte verwendet werden können, ohne von der Lehre und vom Umfang der Offenbarung abzuweichen.
In 1 ist die Beispielhafte Anordnung von verschiedenen Komponenten in dem Bezahlsystem anzeigt. Das gezeigte mobile Endgerät (101) bzw. die mobile Webseite (127) können dabei tragbar oder stationär sein und können mit weiteren mobilen Endgeräten kombiniert werden.
Die computerausführbare Anweisung wird dabei in das Softwareprogramm auf dem mobilen Endgerät eingegeben und von dort an das System zur Verarbeitung übergeben.
Fachleute werden erkennen, dass weitere Ausführungsformen der Erfindung vorstellbar sind, hierzu zählen andere tragbare Geräte, programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputer und der Gleichen.

Claims

Elektronisches Bezahlsystem mit der Möglichkeit zur Einschränkungen und Regelung der Gültigkeit von Zahlungen.
System zur Eingabe und Verarbeitung von rechtegesteuerten Zahlungen Das System umfasst die Möglichkeit zur Erstellung und zum Einsatz von rechtegesteuerten Zahlungen unter Nutzung einer virtuellen bzw. physischen Bezahlkarte und einer Applikation zum Abgleich des Zahlungswunsches mit den hinterlegten Rechten. Im System kann ein Nutzer eine beliebige Transaktion an einem Zahlungsverkehrsterminal bzw. Online mit seiner Bezahlkarte inkl. rechtegesteuerter Zahlungen durchführen. Dabei wählt der Kunde beim Bezahlvorgang entweder die Bezahlart manuell im System aus oder es erfolgt verschiedener Parameter eine Systemseitige Auswahl des Bezahlweges. Für spezifische Zahlungen kann darüber hinaus auch eine Erfassung eines Belegs im Nachgang zur Transaktion notwendig sein, dies ist beispielsweise bei geschäftlichen Transaktionen der Fall. Hierbei wird im Nachgang die autorisierte Zahlung mit dem Zahlungsbeleg Systemseitig abgeglichen. Zur Durchführung einer rechtegesteuerten Zahlung müssen mehrere Parameter entsprechenden den Möglichkeiten der Rechteeinschränkung Systemseitig geprüft werden. Hier bei wird in einem ersten Schritt bei der Zahlung automatisch geprüft, ob eine passende mögliche rechtebasierte Zahlungsfreigabe vorliegt und diese bei vorliegen der entsprechenden Bedingungen genutzt. Dabei werden im System alle rechtegesteuerten Zahlungen des Nutzers gespeichert und bei jeder Zahlung automatisch geprüft. Dabei werden Systemseitig die notwendigen Daten des mobilen Endgerätes beim Bezahlvorgang, der Bezahlkarte und der entsprechenden rechtegesteuerten Zahlungen geprüft. Im System werden dabei die jeweiligen Rechte der Zahlungen bei Erfassung einer rechtebasierten Zahlung erfasst - dies umfasst im vorliegenden System die Möglichkeit, die Zahlungen auf die folgenden Bereiche einzuschränken: • Orte • Zeitpunkte und Zeitspannen • Händler • Branchen • Eigene Einschränkungen • Einschränkung der Möglichkeit zur Online- bzw. Offlinezahlung Dabei werden im System die relevanten Parameter gespeichert und bei jeder Transaktion entsprechend auf Gültigkeit geprüft. Alle Prüfungen erfolgen dabei innerhalb des Systems und erst bei Vorlage einer gültigen rechtegesteuerten Transaktion wird diese Systemseitig bestätigt und je nach Zahlungsart in einem Vier-Parteien-Bezahlsystem bzw. in einem Drei-Parteien-Bezahlsystem abgewickelt. Rechtebasierende Zahlungen sind somit nur innerhalb des Systems rechtebasierend und werden außerhalb des Systems nach erfolgter Prüfung zu regulären Transaktionen, Somit sind in diesem Ansatz auch keine Händlerseitigen Anpassungen oder Anpassungen bei Clearinghäusern und Banken zur Durchführung der Transaktionen notwendig.
Computerprogrammprodukt zur Eingabe und Erfassung einer solchen Zahlungen nach Anspruch 1 dieses Systems wie beschrieben. Dies umfasst ein System zur Speicherung und zur Abfrage von Stammdaten. Für die Durchführung einer solchen rechtespezifischen Transaktion sind mindestens die folgenden Parameter im Rahmen eines Systems notwendig:, a. Auswahlmöglichkeit des Abbuchungskontos b. Auswahl eines Empfängers c. Betragshöhe d. Verwendungszweck e. Einschränkungsmöglichkeiten, sofern gewünscht in den folgenden Kategorien: i. Ort ii. Zeit iii. Nennung spezifischer Händler / Unternehmen iv. Branchenauswahl v. Aktionen vi. Möglichkeit zur Einschränkung auf reine Online- oder Offline-Transaktionen Die Anwendung wird benötigt, um Zahlungseinschränkungen individuell durch den Zahlungsgeber innerhalb des Systems durchzuführen und damit eine eingeschränkte Zahlung einem Zahlungsempfänger bereitzustellen.