AT13122U1 - Verfahren und programmlogik zum verarbeiten von elektronischen zahlungsanweisungen über ein telefonnetz - Google Patents

Abstract

Verfahren zum Verarbeiten von elektronischen Zahlungsanweisungen (1) über ein Telefonnetz (4), an das zumindest ein Kontoserver (7) und ein Proxyserver (10) angeschlossen sind, mit den Schritten:Zuordnen (13, 15, 19) eines eindeutigen Codes (Cd) zu einem Tripel (9) aus Empfängerkonto-, Zahlungsbetrag- und Verwendungszweck-Daten (B, €, A) im Proxyserver;Bereitstellen (16, 21) des Codes (Cd) für einen Benutzer (2) an einem Benutzertelefon (2'), das eine Absenderkennung (MS) hat;Eingeben (23) des Codes (Cd) in das Benutzertelefon (2') und Senden (23 - 25) des Codes (Cd) und der Absenderkennung (MS) über das Telefonnetz (4) an den Proxyserver (10);Ermitteln (26) des dem Code (Cd) zugeordneten Tripels (9) im Proxyserver (10); und Senden (29) des Tripels (9) und entweder der Absenderkennung (MS) oder daraus abgeleiteter Senderkonto-Daten (A) an den Kontoserver (7) als Zahlungsanweisung (1).

Description

österreichisches Patentamt AT13 122U1 2013-06-15

Beschreibung [0001] Die vorliegende Erfindung betrifft ein Verfahren und eine Programmlogik zum Verarbeiten von elektronischen Zahlungsanweisungen über ein Telefonnetz.

[0002] Für Bezahlvorgänge über Telefonnetze sind zahlreiche Lösungen bekannt. Diese erfordern häufig eine aufwändige Vor-Registrierung des Benutzers oder die langwierige Eingabe aller für eine Zahlungsanweisung relevanter Daten, wie Senderkonto, Empfängerkonto, Zahlungsbetrag und Verwendungszweck. Dies ist gerade mit kleinformatigen mobilen Endgeräten für Mobiltelefonnetze mühsam und daher von geringer Benutzerakzeptanz. Die Erfindung setzt sich zum Ziel, eine einfache und bedienungsfreundliche Lösung zur Verarbeitung von elektronischen Zahlungsanweisungen über Telefonnetze, insbesondere Mobiltelefonnetze, zu schaffen.

[0003] Dieses Ziel wird in einem ersten Aspekt der Erfindung mit einem Verfahren der einleitend genannten Art erreicht, mit den Schritten: [0004] Zuordnen eines eindeutigen Codes zu einem Tripel aus Empfängerkonto-, Zahlungsbetrag- und Verwendungszweck-Daten im Proxyserver; [0005] Bereitstellen des Codes für einen Benutzer an einem Benutzertelefon, das eine Absen-derkennung hat; [0006] Eingeben des Codes in das Benutzertelefon und Senden des Codes und der Absenderkennung über das Telefonnetz an den Proxyserver; [0007] Ermitteln des dem Code zugeordneten Tripels im Proxyserver; und [0008] Senden des Tripels und entweder der Absenderkennung oder daraus abgeleiteter Sen-derkonto-Daten an den Kontoserver als Zahlungsanweisung.

[0009] Mit Hilfe des erfindungsgemäßen Verfahrens kann der Benutzer an seinem Endgerät durch Eingabe eines einzigen Codes, welcher die lange Datenfolge von Empfängerkonto-, Zahlungsbetrag- und Verwendungszweck-Daten ersetzt, die Zahlung tätigen. Das Endgeräte, z.B. Mobiltelefon, ist dabei bereits durch seine Absenderkennung im System identifiziert. Besonders günstig ist es, wenn der Code numerisch und maximal achtstellig ist, sodass er leicht zu merken ist und auch über eine herkömmliche Telefon-Zifferntastatur eingegeben werden kann. Zahlungsempfänger wie Behörden, Versicherungen od.dgl. können diesen Code beispielsweise auf eine Rechnung oder einen Erlagschein aufdrucken und in Papierform dem Zahlungspflichtigen übermitteln, welcher den Code lediglich in sein Mobiltelefon einzugeben braucht. Dies bedeutet eine ungemeine Erleichterung für den Endbenutzer zur Durchführung von Zahlungsanweisungen im täglichen Leben. Dazu ist keinerlei gesonderte Vorregistrierung des Benutzers erforderlich, da der Code alle überweisungsrelevanten Daten wie Empfängerkonto, Zahlungsbetrag und Verwendungszweck referenziert und durch die automatische Absenderkennung des Benutzertelefons komplettiert wird.

[0010] Gemäß einer besonders bevorzugten Ausführungsform der Erfindung werden der Code und die daraus folgende Zahlungsanweisung im Proxyserver archiviert und dieser Code für eine neuerliche Zuordnung zu einem neuen Tripel wieder freigegeben, sobald die Zahlungsanweisung vom Kontoserver verarbeitet worden ist. Codes brauchen damit nur für „unbeglichene Forderungen", umfassend ein Tripel aus Empfängerkonto, Zahlungsbetrag und Verwendungszweck, vergeben und bevorratet werden; sobald eine Forderung durch eine entsprechende Zahlungsanweisung beglichen wurde, kann derselbe Code wieder neu zugeordnet werden. Dadurch kann die Codelänge besonders kurz gehalten werden, z.B. auch nur 6- oder 7-stellig.

[0011] Gemäß einem weiteren Merkmal der Erfindung kann das Benutzertelefon zu einem eingegeben Code das zugeordnete Tripel vom Proxyserver erhalten und auf einer Anzeige dem Benutzer zur Bestätigung anzeigen, um die Sicherheit und Transparenz für den Benutzer zu erhöhen.

[0012] In weiterer Ausgestaltung der Erfindung kann der Code auch als gedruckter zweidimen- 1 /8 österreichisches Patentamt AT13 122U1 2013-06-15 sionaler Barcode dem Benutzer bereitgestellt und mittels eines Barcodelesers in das Benutzertelefon eingegeben werden. Dadurch kann der Benutzer - wenn sein Telefon entsprechend ausgestattet ist, beispielsweise mit Hilfe einer Kamera und entsprechender Barcodelese-Software - den Code einfach abfotografieren, anstelle ihn über die Tastatur einzugeben. Für Benutzer mit herkömmlichen Telefonen ohne Barcodeleser bleibt der Code weiterhin über die Tastatur eingebbar.

[0013] Eine weitere bevorzugte Ausführungsform der Erfindung zeichnet sich dadurch aus, dass jedem potentiellen Zahlungsempfänger ein eigener Pool von Codes zugewiesen und die Zuordnung eines Codes aus diesem Pool zu einem Tripel vom Zahlungsempfänger angestoßen wird. Große Zahlungsempfänger wie Behörden, Versicherungen usw. können dadurch die Zuordnungen der Codes zu den Zahlungsanweisungs-Tripel selbst verwalten.

[0014] Bevorzugt erfolgt das Senden des Codes und der Absenderkennung über das Telefonnetz an den Proxyserver mittels einer SMS-Nachricht, was aufgrund der hohen Verbreitung von SMS-fähigen Mobiltelefonen eine breite Einsetzbarkeit in GSM-, UMTS- oder LTE-Netzen ermöglicht. Alternativ kann das Senden des Codes und der Absenderkennung über das Telefonnetz mittels einer Smartphone-App des Benutzertelefons erfolgen, welche App dem Benutzer Zusatzinformationen in internetfähigen Telefonnetzumgebungen liefern kann.

[0015] Besonders günstig ist es, wenn nach erfolgreicher Verarbeitung der Zahlungsanweisung im Kontoserver eine Bestätigungsnachricht über das Telefonnetz an das Benutzertelefon gesandt wird, bevorzugt mittels einer SMS-Nachricht.

[0016] In einem weiteren Aspekt schafft die Erfindung auch eine Programmlogik, welche das geschilderte Verfahren implementiert.

[0017] Die Erfindung wird nachstehend anhand von in den beigeschlossenen Zeichnungen dargestellten Ausführungsbeispielen näher erläutert. In den Zeichnungen zeigt: [0018] Fig. 1 Hardwarekomponenten zur Durchführung des erfindungsgemäßen Verfahrens; [0019] Fig. 2 eine erste Ausführungsform des Verfahrens der Erfindung in Form eines Se quenzdiagramms; und [0020] Fig. 3 eine alternative Ausführungsform des Verfahrens der Erfindung anhand eines

Ausschnitts von Fig. 2.

[0021] Unter Bezugnahme auf die Fig. 1 und 2 befasst sich das vorliegende Verfahren mit der Verarbeitung von Zahlungsanweisungen 1 (Fig. 2) zwischen einem Zahlungssender 2 mit einem Benutzertelefon 2' und einem Zahlungsempfänger 3 mit einem Rechner 3' über eine Telefonnetz (Fig. 1). Das Telefonnetz 4 kann ein Mobiltelefonnetz (public land mobile network, PLMN) und/oder ein Festtelefonnetz (public switched telephone network, PSTN) sein. Das Telefonnetz 4 kann ferner über entsprechende Gateways 5 mit Datennetzen und/oder dem Internet 6 in Verbindung stehen.

[0022] An das Telefonnetz 4 ist - direkt oder in dem gezeigten Beispiel über das Internet 6 - ein Kontoserver 7 angeschlossen, welcher in herkömmlicher Art und Weise für jeden Zahlungssender 2 ein Senderkonto A und für jeden Zahlungsempfänger 3 ein Empfängerkonto B in einer Datenbank 8 führt. Der Kontoserver 7 kann der Rechner einer externen Bank sein, ein Kundenkontoserver des Telefonnetzes 4 selbst oder ein zwischen dem Telefonnetz 4 und einer externen Bank angesiedelter Clearing-Server (intermediary), beispielsweise auch ein Kunden- oder Kreditkartenkonto-Server im Internet 6.

[0023] Ziel der Verarbeitung der Zahlungsanweisung 1 ist es, einen Zahlungsbetrag € von einem Senderkonto A des Zahlungssenders 2 auf ein Empfängerkonto B des Zahlungsempfängers 3 zu transferieren, unter gleichzeitiger Angabe eines Zahlungs- bzw. Verwendungszwecks D, welcher beliebige alphanumerische Daten enthalten kann, beispielsweise eine Rechnungsnummer, Vorgangsnummer, Steuernummer, Strafzettel-Nummer, einen bloßen Text wie „Spende" usw. Die Zahlungsanweisung 1 setzt sich somit (zumindest) aus Daten zur Angabe des Senderkontos A, des Empfängerkontos B, des Zahlungsbetrags € und des Verwendungs- 2/8 österreichisches Patentamt AT13 122U1 2013-06-15 zwecks D zusammen.

[0024] Zur Verarbeitung der Zahlungsanweisungen 1 werden in weiterer Folge (zumindest) die Daten Empfängerkonto B, Zahlungsbetrag € und Verwendungszweck D zu einem Tripel {B, €, D} bzw. 9 zusammengefasst, das z.B. von Seiten des Zahlungsempfängers 3 aus vorbereitet werden kann und beispielsweise dessen Forderung gegenüber dem Zahlungssender 2 repräsentiert. Das Tripel 9 wird vom Zahlungsempfänger 3 in einem Proxyserver 10, genauer dessen Datenbank 11 hinterlegt. Der Proxyserver 10 kann direkt oder über das Datennetz bzw. Internet 6 an das Telefonnetz 4 angeschlossen sein und steht damit auch direkt bzw. indirekt mit dem Kontoserver 7 in Verbindung.

[0025] Unter Bezugnahme speziell auf Fig. 2 werden in einem ersten Schritt 12 die entsprechenden Tripel 9 vom Zahlungsempfänger 3 dem Proxyserver 10 zur Verfügung gestellt, beispielsweise bei Entstehen einer Forderung in die Datenbank 11 eingespeist. Der Proxyserver 10 ordnet daraufhin im Schritt 13 jedem Tripel {B, €, D} 9 einen eindeutigen Code Cd in seiner Datenbank 11 zu. Die Codes Cd sind systemweit eindeutig und bevorzugt kurz, z.B. maximal 12-stellig, insbesondere maximal 10-stellig oder besonders bevorzugt maximal 6- bis 8-stellig. Die Codes Cd können alphanumerisch sein, sind jedoch bevorzugt numerisch, sodass sie auch über eine herkömmliche Zifferntastatur eines Mobiltelefons eingegeben werden können. Mit 14 ist der Prozess im Proxyserver 10 bezeichnet, über den die Zuordnung 15 zwischen Code Cd und Tripel {B, €, D} 9 gespeichert bzw. aufrechterhalten wird.

[0026] In einem anschließenden Schritt 16 wird der Code Cd dem Benutzer bzw. Zahlungssen-der 2 mitgeteilt. Der Schritt 16 kann in beliebiger Art und Weise auch außerhalb des Telefonnetzes 4 oder Internets 6 erfolgen, z.B. durch Aufdrucken des Codes Cd in Papierform auf eine Rechnung, einen Zahlschein, einen Strafzettel, usw., und Übersenden des Papiers von dem Zahlungssender 2, oder auf beliebige elektronische Weise.

[0027] Fig. 3 zeigt eine alternative Ausführungsform der Schritte 12 bis 16 für die Zuordnung des Codes Cd zum Tripel 9 und die Bereitstellung 16 des Codes Cd an den Benutzer 2. Hier wird in einem ersten Schritt 17 jedem potenziellen Zahlungsempfänger 3 ein ganzer Satz {Cds} bzw. 18 von Codes Cd zur Verfügung gestellt, z.B. ein Wertebereich eines numerischen Codes, und der Zahlungsempfänger 3 ordnet selbst das Tripel {B, €, D} 9 einem einzigen Code Cd aus dem Satz {Cds} 18 zu, siehe Schritt 19, z.B. an seinem eigenen Rechner 3'. Anschließend teilt der Zahlungsempfänger 3 sowohl das Tripel 9 als auch den zugeordneten Code Cd dem Proxyserver 10 mit (Schritt 20) . Alternativ kann der Zahlungsempfänger 3 z.B. über eine Webinterface in einem ihm freigegebenen Bereich des Proxyservers 10 die Zuordnung 15 zwischen einem Code Cd seines Satzes {Cds} 18 und einem Tripel {B, €, D} 9 vornehmen, wodurch ebenfalls sowohl ihm als auch dem Proxyserver 10 die Zuordnung 15 bekannt wird.

[0028] Anschließend stellt der Zahlungsempfänger 3 dem Zahlungssender 2 den zugeordneten Code Cd bereit bzw. sendet ihn an diesen (Schritt 21), beispielsweise durch Aufdrucken des Codes Cd auf eine Rechnung oder einen Zahlschein und Übersenden per Post oder sonstige Übermittlung auf elektronischem Wege.

[0029] Zurückkehrend auf Fig. 2 kann nun der Benutzer 2 mit Hilfe seines Benutzertelefons 2' den ihm bereitgestellten bzw. übermittelten Code Cd über das Telefonnetz 4 senden. Das Benutzertelefon 22 ist beispielsweise ein Mobiltelefon, insbesondere nach dem GSM-, UMTS-oder LTE-Standard, bevorzugt SMS-fähig, und insbesondere bevorzugt ein Smartphone, das auch Smartphone-Apps (Softwareprogramme) ausführen kann und über paketvermittelte Datenverbindungen, insbesondere nach dem Internetprotokoll, über das Mobiltelefonnetz 4 und gegebenenfalls das Internet 6 mit dem Proxyserver 10 kommunizieren kann. In der bevorzugten Ausführungsform des Codes Cd als numerischer, maximal 8-stelliger Code genügt aber auch ein einfaches Benutzertelefon 2' mit einer herkömmlichen numerischen Telefontastatur, um den Code Cd einzugeben, z.B. in Form von Tastwahltönen (MFV-Tönen). Ein kurzer numerischer Code ist selbst dann günstig, wenn er in Form einer SMS eingegeben und über das Telefonnetz 4 übermittelt wird, da eine kurze Ziffernfolge einfach zu merken und über eine numerische Telefontastatur einfach einzugeben ist. 3/8 österreichisches Patentamt AT13122U1 2013-06-15 [0030] Das Benutzertelefon 2' verfügt in herkömmlicher Art über eine Absenderkennung, mit der es im Telefonnetz 4 identifizierbar ist, z.B. seine Telefonnummer, IMSI (international mobile subscriber identity), TIMSI (temporary IMSI), IMEI (international mobile equipment identity) usw. Alle diese eindeutigen Identifikationen des Benutzertelefons 2' werden hier als Absenderken-nung MS bezeichnet. Wenn die Absenderkennung MS beispielsweise direkt die Telefonnummer des Benutzertelefons 2' ist und diese direkt mit einem Kundenkonto in einem Teilnehmer-Abrechnungssystem auf dem Kontoserver 7 des Telefonnetzes 4 verknüpft ist, könnte die Absenderkennung MS im einfachsten Fall direkt das Senderkonto A identifizieren.

[0031] In den Schritten 23 und 24 werden der vom Benutzer in das Benutzertelefon 2' eingegebene Code Cd zusammen mit der Absenderkennung MS des Benutzertelefons 2' über das Telefonnetz 4 an den Proxyserver 10 gesandt. In jenen Fällen, in denen die Absenderkennung MS nicht gleich direkt das Senderkonto A des Zahlungssenders 2 identifiziert, kann in einem zwischenliegenden Schritt 25 anhand der Absenderkennung MS das zugeordnete Senderkonto A herausgesucht werden, z.B. aus einer Kundendatenbank im Telefonnetz 4 oder eines daran angeschlossenen Teilnehmer-Abrechnungssystems. Der Schritt 25 kann auch direkt im Proxyserver 10 ablaufen, wenn dieser über die entsprechenden Zuordnungsinformationen zwischen Absenderkennung MS und Senderkonto A verfügt.

[0032] Nach den Schritten 23 bis 25 verfügt der Proxyserver 10 somit über den vom Benutzer eingegebenen Code Cd und Information über dessen Senderkonto A. Im Schritt 26 wird nun im Proxyserver 10 das dem Code Cd im Prozess 14 zugeordnete Tripel {B, €, D} 9 ermittelt.

[0033] In den optionalen Schritten 27 und 28 kann das Tripel 9 zur Aufforderung, die Zahlungsanweisung nochmals zu bestätigen, an das Benutzertelefon 2' zurückgesandt und auf diesem angezeigt werden, z.B. als SMS oder im Rahmen einer Smartphone-App. Im Schritt 28 sendet der Benutzer eine solche Bestätigung vom Benutzertelefon 2' an den Proxyserver 10 zurück, welcher diese abwartet und erst dann mit der Verarbeitung der Zahlungsanweisung 1 fortsetzt. Langt die Bestätigung von Schritt 28 innerhalb eines vorgegebenen Zeitraums nicht ein, werden der Code Cd und die Zahlungsanweisung 1 verworfen.

[0034] Der Proxyserver 10 verfügt nun über alle Daten, um eine vollständige Zahlungsanweisung 1 umfassend das Tripel 9 mit Empfängerkonto B, Zahlungsbetrag € und Verwendungszweck D und die Angabe über das Senderkonto A zusammenzustellen. Im Schritt 29 sendet der Proxyserver 10 die komplettierte Zahlungsanweisung [{B, €, D}, A] 1 an den Kontoserver 7. Der Kontoserver 7 führt daraufhin im Schritt 30 die Zahlungsanweisung 1 aus und bucht den Zahlungsbetrag € vom Senderkonto A auf das Empfängerkonto B unter Angabe des Verwendungszwecks D um.

[0035] Optional kann der Kontoserver 7 vor Ausführung der Zahlungsanweisung 1 im Schritt 30 nochmals über das Telefonnetz 4 eine Bestätigung des Zahlungssenders 2 am Benutzertelefon 2' einholen, siehe Schritte 30' und 30", z.B. mittels Sprachaufforderung und Tastwahleingabe, Austauschs weiterer SMS oder im Rahmen der geschilderten Smartphone-App. Die vom Benutzer im Schritt 30" eingegebene Bestätigung kann dabei auch ein für das Zahlungstransaktionssystem des Kontoservers 7 spezifischer PIN-Code sein, welcher vom Kontoserver 7 entsprechend verifiziert wird, um die Ausführung der Zahlungsanweisung 1 zu autorisieren.

[0036] Wenn die Zahlungsanweisung 1 im Schritt 30 erfolgreich ausgeführt wurde, kann der Kontoserver 7 in den Schritten 31 und 32 optional Bestätigungsmeldungen an das Benutzertelefon 2' des Zahlungssenders 2 und/oder an den Rechner 3' des Zahlungsempfängers B senden.

[0037] Ferner kann in einem optionalen Schritt 33 der soeben verwendete Code Cd freigegeben werden, um für eine neuerliche Zuordnung 15 in den Schritten 13 bzw. 19 zur Verfügung zu stehen. Dadurch kann insgesamt mit einer geringeren Anzahl von Codes Cd und dadurch mit Codes Cd mit einer geringeren Stellenanzahl, z.B. maximal 6- bis 8-stellig, das Auslangen gefunden werden, weil die Codes Cd jeweils nur für ausstehende Forderungen, d.h. noch nicht ausgeführte Zahlungsanweisungen 1 eindeutig sein müssen. Um dabei für Prüfungszwecke die Nachverfolgbarkeit der Zahlungsanweisungen 1 zu gewährleisten, werden bevorzugt alle Codes 4/8 österreichisches Patentamt AT13 122U1 2013-06-15

Cd und alle daraus folgenden Zahlungsanweisungen 1 im Proxyserver 10 mit entsprechenden Zeitstempeln archiviert.

[0038] Die Erfindung ist nicht auf die dargestellten Ausführungsformen beschränkt, sondern umfasst alle Varianten und Modifikationen, die in den Rahmen der angeschlossenen Ansprüche fallen. 5/8

Claims (9)

1. österreichisches Patentamt AT 13 122 Ul 2013-06-15 Ansprüche 1. Verfahren zum Verarbeiten von elektronischen Zahlungsanweisungen (1) über ein Telefonnetz (4), an das zumindest ein Kontoserver (7) und ein Proxyserver (10) angeschlossen sind, mit den Schritten: - Zuordnen (13, 15, 19) eines eindeutigen Codes (Cd) zu einem Tripel (9) aus Empfängerkonto-, Zahlungsbetrag- und Verwendungszweck-Daten (B, €, D) im Proxyserver; - Bereitstellen (16, 21) des Codes (Cd) für einen Benutzer (2) an einem Benutzertelefon (2'), das eine Absenderkennung (MS) hat; - Eingeben (23) des Codes (Cd) in das Benutzertelefon (2') und Senden (23 - 25) des Codes (Cd) und der Absenderkennung (MS) über das Telefonnetz (4) an den Proxyserver (10); - Ermitteln (26) des dem Code (Cd) zugeordneten Tripels (9) im Proxyserver (10); und - Senden (29) des Tripels (9) und entweder der Absenderkennung (MS) oder daraus abgeleiteter Senderkonto-Daten (A) an den Kontoserver (7) als Zahlungsanweisung (1); - wobei der Code (Cd) und die daraus folgende Zahlungsanweisung (1) im Proxyserver (10) archiviert werden, und wobei dieser Code (Cd) für eine neuerliche Zuordnung (15) zu einem neuen Tripel (9) wieder freigegeben wird (33), sobald die Zahlungsanweisung (1) vom Kontoserver (10) verarbeitet worden ist (30).
2. 2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der eindeutige Code (Cd) numerisch und maximal 8-stellig ist.
3. 3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Benutzertelefon (2') zu einem eingegeben Code (Cd) das zugeordnete Tripel (9) vom Proxyserver 10 erhält (27) und auf einer Anzeige dem Benutzer (2) zur Bestätigung (28) anzeigt.
4. 4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der Code (Cd) auch als gedruckter zweidimensionaler Barcode dem Benutzer (2) bereitgestellt und mittels eines Barcodelesers in das Benutzertelefon (2') eingegeben wird.
5. 5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass jedem potentiellen Zahlungsempfänger (3) ein eigener Pool (18) von Codes (Cd) zugewiesen und die Zuordnung eines Codes (Cd) aus diesem Pool (18) zu einem Tripel (9) vom Zahlungsempfänger (3) angestoßen wird.
6. 6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass das Senden (23 - 25) des Codes (Cd) und der Absenderkennung (MS) über das Telefonnetz (4) an den Proxyserver (10) mittels einer SMS-Nachricht erfolgt.
7. 7. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass das Senden (23 - 25) des Codes (Cd) und der Absenderkennung (MS) über das Telefonnetz (4) mittels einer Smartphone-App des Benutzertelefons (2') erfolgt.
8. 8. Verfahren nach einem der Ansprüche 1 bis 1, dadurch gekennzeichnet, dass nach erfolgreicher Verarbeitung (30) der Zahlungsanweisung (1) im Kontoserver (10) eine Bestätigungsnachricht (31) über das Telefonnetz (4) an das Benutzertelefon (2') gesandt wird, bevorzugt mittels einer SMS-Nachricht.
9. 9. Programmlogik, implementierend ein Verfahren nach einem der Ansprüche 1 bis 8. Hierzu 2 Blatt Zeichnungen 6/8