Zahlungsmittelschlüssel"

Die Erfindung betrifft ein Verfahren zur Bezahlung mit mindestens einem elektronischen Zahlungsmittelschlüssel.

Es sind verschiedene Verfahren im Stand der Technik bekannt:

Mit der Verbreitung der elektronischen Datenverarbeitung haben sich immer mehr Systeme etabliert, die das Bezahlen mit Banknoten und Münzen durch unbare Alternativen ersetzen. So wurden Karten eingeführt, die beispielsweise mit Magnetstreifen, Speicherchips oder aufgedruckter Codierung ausgestattet sind. Dabei lassen sich prinzipiell zwei Gestaltungsvarianten unterscheiden.

Auf den so genannten Geldkarten ist ein Geldwert gespeichert. Beim Zahlungsvorgang wird von diesem Wert abgebucht. Bekannte Vertreter dieser Gattung sind die so genannten elektronischen Geldbörsen sowie die Telefonkarten. Eine Registrierung des Karteninhabers ist dabei nicht notwendig. Wer die Karte in Händen hält, kann über das Guthaben verfügen.

Bei den Kreditkarten dagegen wird die Identität des Inhabers auf der Karte hinterlegt. Die Verfügungen mit der Karte werden mit ihm abgerechnet. Die Kenntnis der Personalangaben ist dafür unerlässlich. Dabei kursieren auch Kreditkarten, die aus Bonitätsgründen nur auf Guthabenbasis geführt werden, und so genannte Debitkarten, die keine Zahlungsziele gewähren. Dies ändert aber nichts an der Dokumentation der Identität des Karteninhabers.

Die Tendenz zu unbaren Zahlungsmodi wird durch die rasante Expansion des Internets noch rapide beschleunigt. Die gegenwärtige Konjunktur internetfähiger, mobiler Telefongeräte mit zusätzlicher Computerfunktionalität, so genannte Smartphones, beschleunigt diesen Trend signifikant. Das Internet wird damit zum ständigen Begleiter. Der konventionelle Handel verlagert sich mit wachsendem Tempo in den digitalen Eaum und fordert Zahlungsmethoden, die dort zu Hause sind und sowohl den Anforderungen des Mediums als auch

BESTÄTIGUNGSKOPIE der Anvvenderfreundlichkeit gerecht werden.

Alle im Internet gegenwärtig gängigen Bezahlverfahren haben gemein, dass für den zahlenden Teilnehmer - in welcher Art auch immer - ein Kontokorrent geführt wird. Dieses Prinzip gilt sowohl für die Kreditkartenzahlung wie auch für andere Bezahlformen im Web.

Damit wird zunehmend Bargeld von Buchgeld abgelöst.

Zu den systemimmanenten Eigenschaften banküblicher Kontoführung gehört die dauerhafte Aufzeichnung der Vorgangsdaten sowie die Identifizierung der an einer Zahlungstransaktion beteiligten Parteien. Aus umfangreichen Kontobewegungen lässt sich für einen Web-User nicht nur sein digitales Bewegungsprofil generieren, sondern auch seine Konsumgewohnheiten ermitteln und damit seine Interessenschwerpunkte und persönlichen Präferenzen ausspähen. Mit der Verwertung dieser sensiblen personenbezogenen Daten wird tief in die Privatsphäre der Betroffenen eingedrungen. Zudem besteht die Gefahr, dass die gewonnenen Informationen gegen ihre Interessen verwendet werden. Deshalb empfehlen Datenschützer eindringlich, so wenig wie möglich Spuren im Internet zu hinterlassen. Dazu würde vor allem auch die Zahlung mit einem anonymen elektronischen Zahlungsmittel statt durch Überweisungsverfahren gehören.

Mit der Richtlinie 2000/46/EG hat die Europäische Union schon im Jahre 2000 die rechtliche Grundlage für die gesetzliche Umsetzung auf nationaler Ebene zur Einführung von elektronischem Geld (E-Geld) als elektronischem Ersatz für Münzen und Banknoten geschaffen. Dabei wurde das Emissionsrecht an die Kreditinstitute delegiert. Dieses elektronische Zahlungsmittel bzw. Geld wird auch als Netzgeld bezeichnet.

Im Internet kursieren unzählige Abbildungen von Banknoten und Münzen in Bildform in den gängigen Formaten wie z.B. jpeg, png, gif, tif und ico, wobei sich diese Grafiken mühelos beliebig oft duplizieren lassen. Deshalb beschränkt sich ihr Einsatz auf illustrative Zwecke; eine Verwendung als elektronisches Zahlungsmittel scheidet im Stand der Technik verständlicherweise aus.

Im Stand der Technik ist das so genannte eCash-Verfahren bekannt. Dabei transferiert ein Kunde Guthaben von seinem Bankkonto auf sein eCash-Konto. Dabei werden verschlüsselte Dateien mit gewissen Wertespeichern erzeugt, die auf seinem Computer gespeichert werden. Die Verwaltung dieser elektronischen Münzen übernimmt ein spezielles Dienstprogramm, die elektronische Geldbörse (Cyberwallet oder E-Wallet). Beim Einkauf im Internet werden dem Verkäufer dann diese Dateien vom Rechner des Käufers übermittelt. Bei der Bezahlung wird das digitale Zahlungsmittel durch den Verkäufer bzw. die Bank sofort auf Gültigkeit geprüft. Der Verkäufer kann nun den Versand der bestellten Ware oder die Ausführung der entsprechenden Dienstleistung veranlassen.

Zunächst muss ein Kunde bei einer für eCash lizenzierten Bank ein eCash- Konto eröffnen und eine eCash-Software auf seinem Rechner installieren. Das eCash-Konto wird mit einem tatsächlichen Bankkonto verbunden. Die Beladung oder Entladung eines eCash-Kontos kann nur von diesem Bankkonto aus erfolgen. Möchte der Kunde einen Betrag in eCash transferieren, erzeugt die elektronische Geldbörse Dateien in Höhe des gewünschten Betrages. Jeder Datei wird dabei ein bestimmter Wert zugeordnet, der sich nicht mehr verändert. Außerdem erhält sie von der Geldbörse eine Seriennummer. Diese Dateien werden daher auch als elektronische Münzen (Cybercoins) bezeichnet. Die Bank überprüft das Guthaben. Ist es ausreichend, wird jede Datei mit einem Schlüssel der Bank versehen, wobei jeder Schlüssel einem bestimmten Wert entspricht; die entsprechende Summe wird vom echten Bankkonto abgebucht.

Anschließend werden die Dateien an den Kunden, das heißt an die Geldbörse zurückgeschickt. Dieser Vorgang entspricht in etwa dem Aufladen einer Chipkarte an einem Ladeterminal. Die Dateien sind nunmehr sowohl von der Geldbörse mit dem Kundenschlüssel, als auch von der Bank mit deren Schlüssel kodiert. Die Geldbörse entfernt jetzt den von ihr angebrachten Schlüssel. Dieses Verfahren wird Blinding genannt. Durch das Blinding soll die absolute Anonymität gewahrt werden. Jede Datei besteht damit aus der Seriennummer und der Information über den Wert und ist mit dem Schlüssel der Bank verschlüsselt. Beim Ausgeben von eCash schickt der Kunde Dateien, deren Wert dem vom Verkäufer angeforderten Betrag entspricht. Die Bezahlung im Internet mit Hilfe der eCash-Software ist in Echtzeit möglich. Auf Mausklick generiert die Software des Verkäufers eine Zahlungsaufforderung, die er an die Geldbörse des Kunden schickt. Diese lässt den Kunden die Transaktion bestätigen und sendet Dateien in Höhe des gewünschten Betrages an den Verkäufer. Dieser wiederum leitet die elektronischen Münzen an die Bank weiter. Dort wird der Bankschlüssel entfernt, der Wert der Münze wird dem eCash-Konto des Verkäufers gutgeschrieben. Die nun entschlüsselte Seriennummer wird gespeichert.

Die Namensgebung dieser Erfindung vermittelt den Eindruck, dass es sich um Bargeld handelt - obwohl durch die fixe Verbindung des Systems mit einem echten Bankkonto lediglich sogenannte Giraleinlagen in eCash konvertiert werden. Auch der Händler benötigt also für seine Gutschriftbuchung ein eCash- Konto.

Eigentlich entspricht eCash somit eher einer Bankgarantie als einem Bargeldsystem. Auch ist dieses System zwingend buchungsbasiert, dadurch nicht anonym, außerdem in Technik und Anwendung kompliziert. Vor allem wird der Anwender gezwungen, auf seinem Rechner eine besondere Software zu installieren. So konnte sich das eCash-Verfahren nicht am Markt durchsetzen.

Andere Ansätze verfolgen ähnliche Konzepte, wobei die Speicherung des Geldes mit aufwendigen Verschlüsselungsverfahren beim Anwender erfolgt, um sicherzustellen, dass die umfangreichen Sicherheitsanforderungen erfüllt werden:

Ferner ist im Stand der Technik eine elektronische Währung bekannt, die den Namen Bitcoin erhielt. Sie wird dezentral auf der Basis eines Computernetzwerks erzeugt. Bitcoin verbindet Eigenschaften von Bargeld mit solchen von internationalen elektronischen Überweisungen. Das Netzwerk wird gebildet aus den Rechnern aller Teilnehmer, die eine kostenlose Open-Source-Software ausführen. Der Besitz von Geldeinheiten kann durch den Besitz von kryp- tographischen Schlüsseln nachgewiesen werden. Jede Transaktion von Geldeinheiten zwischen Teilnehmern des Netzwerks wird in einer öffentlichen, vom gesamten Netzwerk unterstützten Datenbank aufgezeichnet und mit starken digitalen Signaturen versehen. Dies stellt sicher, dass Geldbeträge nur einmal ausgegeben werden.

Das Konzept wirft wegen seiner neuartigen Verbindung bisher unvereinbarer Eigenschaften rechtliche, wirtschaftliche und technische Fragen auf, die strittig diskutiert werden.

Bitcoin-Einheiten sind durch die Verwendung starker Verschlüsselungsverfahren weitgehend fälschungssicher. Jeder Geldbetrag kann nur einmal ausgegeben werden, weil jegliche Übermittlung von Geld unwiderruflich im Netzwerk verzeichnet wird. Das System verbindet eine relativ schnelle Bestätigung von Transaktionen innerhalb von zehn bis sechzig Minuten mit geringen Kosten pro Transaktion von rund 0,007€. Der Besitz von Geldbeträgen wird durch den Inhalt einer elektronischen Geldbörse nachgewiesen, welche kryptographische Schlüssel enthält. Die Signatur mit diesen Schlüsseln ist Voraussetzung für die Aufnahme einer Transaktion ins netzwerkweite Verzeichnis. Die Schlüssel als solche müssen bei diesem Verfahren nicht offenbart werden. Die Geldbörse muss jedoch gegen Verlust durch Ausspähen und Schadsoftware geschützt werden.

Zahlungen finden an Pseudonyme Adressen statt, welche die Software für jeden Empfänger beliebig neu erzeugen kann. Eine Identifizierung der Handelspartner soll dadurch verhindert werden. Eine vollständige Anonymität garantiert das System nicht, da die Kette aller Transaktionen öffentlich in der Transaktionsgeschichte verzeichnet wird und eine Verknüpfung mit weiteren Informationen prinzipiell möglich ist.

Über die Unterstützung von Bezahlvorgängen hinaus hat Bitcoin den Charakter einer elektronischen Währung. Der Preis der Einheit ergibt sich allein aus dem Angebot an verfügbaren Bitcoins und der Nachfrage derselben beim Handel. Geldeinheiten können ähnlich wie Aktien an Börsen gegen Währungen wie US-Dollar oder Euro gegen Gebot gekauft und verkauft werden. Der Kurs der Währungseinheit unterliegt gelegentlich kräftigen Schwankungen und ist seit dem Start des Systems sehr stark gestiegen.

Die Marktkapitalisierung aller Einheiten beträgt etwas weniger als 100 Millionen US-Dollar (Stand: 22. Juni 2011). Die Menge an Geldeinheiten ist nicht zentral beeinflussbar und hat eine in der Software eingebaute feste Obergrenze. Neue Währungseinheiten können von Teilnehmern des Peer-to- Peer-Netzwerks bei der Aufwendung von Rechenleistung für die Bestätigung und Signatur von Transaktionen verdient werden.

Das Konzept von Bitcoin wurde 2008 in einem Whitepaper von Satoshi Nakamoto vorgeschlagen. Das Konzept anonymen digitalen Geldes, basierend auf asymmetrischen Kryptosystemen wie RSA, ist allerdings seit Jahrzehnten bekannt. Bitcoin basiert auf der weiterführenden Idee einer kryptographischen Währung, die 1998 von Wei Dai als b-money und von Nick Szabo als bit gold beschrieben wurde. Nakamoto, über den nur sehr wenig bekannt ist, hat sich Ende 2010 aus der Entwicklung zurückgezogen. Das Projekt wird von einigen Entwicklern unter der Leitung von Gavin Andresen fortgeführt. Das Softwareprojekt ist in der Open Source-Community verankert. Mehrere der Entwickler, wie beispielsweise Jeff Garzik, sind auch mit Beiträgen am Linux-Kernel beteiligt.

Bitcoin verbindet konzeptgemäß bestimmte Eigenschaften von Uberweisungen mit der Eigenschaft der begrenzten Geldmenge, wie es bei Warengeld der Fall ist. Bitcoin ist mathematisch in der Menge begrenzt, anders als das Warengeld (Kurantgeld), welches durch seinen Materialgehalt (Edelmetallgehalt) begrenzt wird (entsprechend der Menge an abbaubarem Erz). Kurantgeld bemisst sich daher auch durch den reinen Metallwert, ist jedoch nur physisch transportierbar. Bitcoin stellt somit eine neue Form von Geld dar. Die Eigenschaften von Bitcoin leiten sich aus dem verwendeten mathematischen Verfahren ab. Eine Fälschung von Einheiten oder Transaktionen ist durch die verwendeten asymmetrischen kryptographischen Verfahren wegen des erforderlichen zeitlichen und technischen Aufwands ineffizient und deshalb praktisch ausgeschlossen.

Zahlungen können ohne Mitwirkung von Finanzinstituten schnell und kostengünstig direkt zwischen den Beteiligten abgewickelt werden, wodurch die vergleichsweise hohen Gebühren der etablierten Dienstleister umgangen werden. Die Bestätigung einer Transaktion kostet gegenwärtig (abhängig von der Implementation der Client-Software) 0.0005 BTC. Wenn sie freiwillig erhöht wird, beschleunigt sie den Bestätigungsvorgang durch eine höhere Priorität bei der Berechnung durch andere Mitglieder des Netzwerks. Die Gebühr wird demjenigen Netzknoten, welcher die Bestätigungs-Signatur erstellt, gutgeschrieben. Das Verfahren soll insbesondere verhindern, dass das Netzwerk gezielt durch sehr viele sehr kleine Transaktionen überlastet wird. Auf lange Sicht sind diese Transaktionsgebühren als Belohnung für den Erhalt des Netzes durch Bereitstellung von Rechenleistung geplant.

Das System ist aufgrund der Peer-to-Peer-Struktur völlig dezentral, ähnlich Systemen wie BitTorrent. Eine Einflussnahme auf die Geldmenge würde erfordern, dass alle Teilnehmer eine veränderte Software verwenden, da sonst ein nicht allgemein anerkannter Ableger von Protokoll und Zahlungseinheit entstehen würde.

Ein Problem bei der Einführung von Bitcoin als Währung ist die anfängliche Verteilung von Geld. Moderne staatliche und private Währungen sind, im Gegensatz zu Bitcoin, durch ein Zahlungsversprechen der ausgebenden Stelle gedeckt. Da Bitcoin als neues Zahlungsmittel anfangs kein Vertrauen genießt und der Rücktausch von keiner Stelle garantiert wird, hatte es jedoch ursprünglich keinen bezifferbaren Wert. Auch eine Nutzbarkeit war aufgrund der fehlenden Angebote von Waren gegen Tausch der Währung zunächst nicht vorhanden. Aus diesem Grund war es anfangs irrational für Marktteilnehmer, die neuen Währungseinheiten zu kaufen. Im Fall von Bitcoin werden neue Einheiten nach einem Prinzip verteilt, das die Unterstützung des Netzwerks durch zur Verfügung stellen von Rechenleistung belohnt. Aufgrund des steigenden Wertes des Guthabens stellt dies im Fall einer Ausweitung der Nutzung eine hohe Belohnung und somit einen substantiellen Anreiz dar.

Grundsätzlich baut Bitcoin auf der bereits möglichen Anonymität im Internet auf. Damit Transaktionen nicht zuordenbar sind, dürfen weder IP-Adressen noch Bitcoin-Adressen einer Person zugeordnet werden können. Da der Zahlungsempfänger auf irgendeine Weise Kunden erhalten will, muss er zumindest teilweise seine Anonymität aufgeben. Wie im Folgenden genauer beschrieben, sind alle Transaktionen zwischen zwei Adressen öffentlich protokolliert und werden dauerhaft im gesamten Netzwerk gespeichert. Spätere Empfänger von Teilbeträgen können den jeweils letzten Besitzer bei Behörden melden, welche dann die Kette der Transaktionen verfolgen können. Alternativ könnten auch Geräte der Kunden beschlagnahmt oder generell überwacht werden.

Zur Verwendung von Bitcoin muss ein Nutzer zunächst eine Softwareanwendung von der Plattform Sourceforge herunterladen und auf seinem Computer oder Smartphone installieren, den so genannten Bitcoin-Client. Beim Starten verbindet sich das Programm mit dem Internet und lädt alle bisherigen Transaktionen herunter.

Durch Anklicken einer Schaltfläche lassen sich dann Bitcoin- Empfängeradressen generieren. Der als Gegenstück benötigte private Schlüssel zu dieser Adresse wird automatisch in einer Datei mit dem Namen "wallet.dat" gespeichert. Die Empfängeradresse kann man z.B. per E-Mail weitergeben, aber auch benutzen, um sich selbst neu erworbene Bitcoins zuzusenden.

Die Teilnehmer wählen sich mit einem Programm (Client) in das unstrukturierte Peer-to-Peer-Netzwerk ein. Das Programm informiert sich automatisch über alle früheren Überweisungen und erzeugt Adressen für den Zahlungsempfang. Geldüberweisungen finden als Transaktionen zwischen solchen Adressen statt. Diese Adressen stellen die öffentlichen Schlüssel eines asymmetrischen Schlüsselpaars dar. Den öffentlichen Teil gibt jeweils der Zahlungsempfänger dem Absender der Zahlung bekannt. Der private Schlüssel ist nur dem Teilnehmer bekannt, der das Schlüsselpaar erzeugt hat. Dadurch ist sichergestellt, dass nur der Besitzer des privaten Schlüssels eine Transaktion autorisieren kann. Gleichzeitig bedeutet der Verlust des privaten Schlüssels auch den Verlust der dazugehörigen Bitcoins.

Um zu verhindern, dass ein Teilnehmer dieselben Bitcoins mehrfach ausgibt (Double Spending), werden Transaktionen im gesamten Peer-to-Peer-Netz mit dem Flooding-Algorithmus verbreitet.

Die Transaktionen werden dabei zuerst innerhalb des Netzwerks digital signiert, was nicht mit einem privaten Schlüssel erfolgt, sondern die Lösung einer neuen kryptographischen Aufgabe beinhaltet. Die Aufgabe beinhaltet die Umkehrung einer Einwegfunktion: Sie ist nur mit hohem Rechenaufwand zu lösen, aber ihre korrekte Lösung mit viel weniger Aufwand überprüfbar. Wenn ein Client eine solche Aufgabe löst, muss er die Lösung zusammen mit Transaktionen von anderen Clients kryptographisch zu einem Block verknüpfen. Nachdem das gelungen ist, erhält er von den anderen Netzwerkknoten die Anerkennung einer Belohnung in Form einiger neu erzeugter Bitcoins.

Die Menge dieser Belohnungseinheiten ist allerdings beschränkt. Bitcoin verwendet zur Signierung von Daten das Elliptische-Kurven-Kryptosystem ECDSA in der 256-Bit-Konfiguration secp256kl.

Der nun im System veröffentlichte Block legt die in ihm enthaltenen Transaktionen verbindlich fest. Er wird bei der Signatur zusätzlich mit anderen Blöcken verkettet, das heißt, das System arbeitet ähnlich wie eine große Gruppe von Notaren, die immer wieder gegenseitig ihre Unterschriften unter einer Folge von Dokumenten prüfen und mit weiteren Unterschriften bestätigen.

Da die Blockkette und die bestätigten Transaktionen öffentlich einsehbar sind, ist Bitcoin nicht vollständig anonym. Gibt ein Benutzer seine Adresse bekannt, so kann man sämtliche Transaktionen dieser Adresse nachverfolgen. Um die Rückverfolgbarkeit einzuschränken, unterstützt Bitcoin den Umgang mit mehreren Adressen in einer elektronischen Geldbörse, dem Wallet.

Das schon erwähnte Lösen von rechenaufwendigen kryptographischen Aufgaben nennt man Mining. Durch dieses beteiligen sich die Clients an der Erzeugung neuer Bitcoins und führen somit auch die Geldschöpfung dezentral durch.

Die Aufgaben werden so ausgelegt, dass im Schnitt alle 10 Minuten ein zufälliger Client, der am Mining beteiligt ist, als erstes eine Lösung findet. Die Wahrscheinlichkeit eines Teilnehmers, die richtige Lösung zu finden, ist proportional zu der eingesetzten Rechenleistung. Alle zwei Wochen passen die Clients den Schwierigkeitsgrad der Aufgaben an, damit das System trotz gestiegener oder gesunkener Gesamtrechenleistung weiterhin im Schnitt alle 10 Minuten zu einer Aufgabe eine Lösung findet.

Lösungen, die dem aktuellen Schwierigkeitsgrad nicht entsprechen, werden von anderen Clients nicht akzeptiert. Ein Client, der eine Aufgabe löst, erzeugt derzeit 50 BTC. Die Anzahl der erzeugten Bitcoins halbiert sich alle vier Jahre, sodass es maximal ca. 21 Millionen Bitcoins geben kann, von denen bis Anfang Juni 2011 etwa 6,4 Mio. erzeugt worden sind.

Als Anreiz für den Erzeuger eines Blocks, eine fremde Transaktion zu bestätigen, kann der Überweisungssender zusätzlich eine Transaktionsgebühr an ihn zahlen. Durch die Transaktionsgebühr soll auch dann ein Anreiz bestehen, kryptographische Aufgaben zu lösen und somit Blöcke zu erzeugen, wenn die geplante Menge an Einheiten erreicht wird und keine neuen Bitcoins mehr erzeugt werden können. Des Weiteren soll durch die Transaktionsgebühr die Anzahl an Transaktionen entsprechend der Kapazität geregelt werden.

Zwar wird Bitcoin gerne als elektronisches Bargeld bezeichnet, jedoch kann es nicht als Geld betrachtet werden, da es nicht von einer staatlich autorisierten Stelle mit Rücknahmegarantie emittiert wird. Außerdem benötigt man auch für die Verwendung von Bitcoin eine Software, die auf dem Rechner des Anwenders installiert werden muss. Zudem garantiert Bitcoin nicht die erwünschte Anonymität, da jede einzelne stattfindende Zahlungstransaktion für alle Teilnehmer des Bitcoin-Netzwerks offen einsehbar und rückverfolgbar ist.

Ein weiteres Projekt, welches bargeldähnliche Zahlungen ohne Internetverbindung des Kunden ermöglicht, hat den Namen Bitbills. Diese bestehen aus Plastikkarten im ISO 7810 Format, die ein Bitcoin-Adressen Schlüsselpaar mit Beträgen zwischen 1 und 20 BTC enthalten. Auf der Rückseite ist der öffentliche Schlüssel aufgedruckt. Der nominale Betrag der Karten wird durch eine Zahlung an diese Adresse auf die Karte geladen. Der auf der Karte tatsächlich vorhandene Betrag kann jederzeit auf der Webseite blockexplo- rer.com angezegeigt werden, welche die öffentliche Block-Kette auswertet. Der geheime Schlüssel befindet sich verdeckt unter einem Hologramm, welches auf der Vorderseite aufgeklebt ist. Die Entfernung des Hologramms legt den Schlüssel frei und zerstört die Karte. Die Karte ist nur so lange gültig, wie das Hologramm intakt ist. Wenn man den Betrag auf der Karte einlösen möchte, muss man das Hologramm entfernen und den geheimen Schlüssel in ein Bitcoin Wallet importieren. Die Kosten für die Karte selbst betrugen Anfang Juli 2011 zwischen 0.30 und 0.70 BTC (zwischen 4,50 und 10.5 USD).

Bei Bitbills handelt es sich um eine Kombination aus Guthabenkarte und Bitcoin mit den oben bereits erwähnten Nachteilen.

Aus der gattungsgemäßen DE 10 2009 034 436 AI ist ein Verfahren zum Bezahlen mit geldwerten Beträgen in Form elektronischer Datensätze bekannt. Der Zahlungspflichtige besitzt einen ersten Datensatz, wobei der Zahlungspflichtige diesen ersten Datensatz von einer zentralen Instanz - beispielsweise einem Geldinstitut - erhalten hat. Der erste Datensatz enthält einen Zahlungsmittelschlüssel und einen Datensatzwert, wobei der Datensatzwert einem auf einem Kontokorrentkonto gutschreibbaren Geldwert entspricht. Der Datensatz enthält ferner Identifizierungsdaten des Zahlungspflichtigen bzw. Besitzers sowie eine Signatur, wobei die Signatur von der zentralen Instanz, nämlich dem Geldinstitut erzeugt wird. Der Zahlungspflichtige kann diesen ersten Datensatz an einen Zahlungsempfänger versenden. Der Zahlungsempfänger verifiziert anhand der Identifizierungsdaten, dass der erste Datensatz vom Zahlungsempfänger stammt. Danach muss der Zahlungsempfänger einen zweiten Datensatz mit dem Datensatzcode erstellen, wobei der zweite Datensatz die Identifizierungsdaten des Zahlungsempfängers enthält. Der Zahlungsempfänger muss nun den zweiten Datensatz an das Geldinstitut übertragen. Das Geldinstitut überprüft zum einen die Identifizierungsdaten des zweiten Datensatzes und zum anderen, ob das Zahlungsmittel gültig ist. Falls der Datensatzcode gültig ist, dann erstellt das Geldinstitut eine Signatur über den zweiten Datensatz. Der signierte zweite Datensatz wird vom Geldinstitut an den Zahlungsempfänger übertragen. Bei diesem Verfahren wird ein Datensatz durch einen neuen Datensatz ersetzt, wobei der alte Datensatz für ungültig erklärt wird. Auch dieses Verfahren bezieht sich aber nicht auf elektronisches Bargeld, sondern auf ein kontengebundenes Zahlungsverfahren. Dieses Verfahren benötigt eine Vielzahl von Transaktionen und ist umständlich.

Im Gegensatz zu kontobasierten Systemen handelt es sich bei elektronischen Bargeldsystemen um IT-Objekte, so genannte eToken, die alle notwendigen Informationen einschließlich ihres Wertes in sich tragen. Besonderes Augenmerk gilt den kryptografischen Protokollen und Algorithmen, die im Rahmen einer Ausgestaltung von ePayment-Systemen sowohl zur Absicherung des Zahlungsverkehrssystems selbst, als auch zur Sicherung einzelner Transaktionen zur Anwendung kommen. Ihre Sicherheit und Robustheit entscheidet über den praktischen Nutzen solcher Systeme. Viele existierende Verfahren zur Realisierung bedingter Anonymität basieren auf dem Prinzip der blinden Chiffren (Schnorr Signatur, blinder ElGamal, Blinding von David Chaum) in Kombination mit dem so genannten Secret Splitting, um bei einer mehrfachen Verwendung (Multiple Spending) von eToken die ursprünglich gewährte Anonymität aufheben zu können. Damit sind nun aber erhebliche Nachteile verbunden, wie beispielsweise die nicht mehr vorhandene Mehrfachverwendungsfähigkeit der eingesetzten unveränderten eTokens. Um diesen wesentlichen Taxonomy-Faktor zu erhalten, wird in der Literatur vorgeschlagen, Verfahren einzusetzen, die statistische Methoden zur Erkennung systematischer Falschgeld-Transitionen verwenden.

Zahlungsabwicklungen mit physischem Bargeld finden in aller Regel in persönlicher Anwesenheit der Beteiligten statt, wobei die einzelnen Schritte des Vorgangs Zug um Zug in rascher zeitlicher Abfolge abgewickelt werden. Dabei kommt dem Echtzeitmoment eine fundamentale Bedeutung zu. Treten beim Zahlungsprozess Störungen auf, hat die Partei, die sich benachteiligt fühlt, die Möglichkeit zu reklamieren und notfalls einzuschreiten. Dieses Repertoire vermittelt den Beteiligten ein Gefühl der Handlungsfähigkeit und damit der Sicherheit. Elektronische Barzahlungsverfahren im Stand der Technik berücksichtigen diese Situation nicht.

So ist aus der im Jahre 2000 veröffentlichten DE 1 985 995 9 A ein Verfahren für einen Geld- oder Vermögenstransfer und Geld- oder Vermögenseinheiten dafür bekannt, wobei das Verfahren keine Erhebung personenbezogener Daten erfordert. Der Zahlungspflichtige erhält von einer Bank beispielsweise per Post eine Karte, wobei auf der Karte ein Identifizierungscode bzw. Zahlungsmittelschlüssel aufgedruckt ist. Der Identifizierungscode bzw. Zahlungsmittelschlüssel ist von einer Deckschicht verborgen und kann durch Abrubbeln der Deckschicht freigelegt werden. Dabei hat aber der Zahlungspflichtige auf elektronischem Wege zunächst den Zahlungsempfänger zu kontaktieren. Der Zahlungspflichtige schickt den Identifizierungscode auf elektronischem Wege beispielsweise per E-Mail als Zahlungsangebot. Die übergebenen Informationen enthalten dabei alle Daten, die der Empfänger benötigt, um im nächsten Schritt über eine Vermittlungsstelle beispielsweise die Bank das Zahlungsmittel in seine endgültige Verfügungsgewalt zu bringen. Der Zahlungsempfänger muss nun die Deckung des Zahlungsangebotes bzw. die Gültigkeit des Identifizierungscodes durch Eingabe des Identifizierungscodes bei einer Bank prüfen.

Das Senden des Sicherheitscodes vom Zahlungspflichtigen an den Zahlungsempfänger stellt eine Sicherheitslücke dar, die das Verfahren in der Praxis unbrauchbar macht. Zwar kann die Verbindung zur Bank/Vermittlungsstelle zwingend abhörsicher ausgelegt werden. Der Zahlungspflichtige und der Zahlungsempfänger können aber nicht gezwungen werden, ebenfalls abhörsichere Verfahren für die Datenübertragung untereinander zu gebrauchen. Wird diese Datenübertragung aber von einem Unbefugten belauscht, kann er sich, wenn er dem Berechtigten bei der Vermittlungsstelle zeitlich zuvorkommt, das Zahlungsmittel widerrechthch aneignen.

Zudem beschränkt sich der Zahlungsvorgang nicht auf eine Transaktion zwischen dem Zahlungspflichtigen und dem Zahlungsempfänger. Nach Entgegennahme des Zahlungsmittels hat der Zahlungsempfänger erst noch eine Vermittlungsstelle aufzusuchen, die die Gültigkeit des Zahlungsmittels überprüft. Die Einschaltung dieser dritten Partei unterbricht die Interaktion zwischen dem Zahlungspflichtigen und dem Zahlungsempfänger für eine nicht absehbare Zeitspanne. Ein flüssiger Ablauf des Zahlungsprozesses in Echtzeit, wie er aus der Zahlung mit physischem Bargeld bekannt ist, wird auf diesem Wege nicht erreicht.

Mit zunehmender Verbreitung mobiler Telefonie wurden auch Verfahren beschrieben, die das Bezahlen mit dem Mobiltelefon ermöglichen. http://www.mgovernment.org/resurces/euromgov2005 PDF/29_S049HK-S04.pdf offenbart ein System, das eine Core-Protokoll-Ebene in Verbindung mit einer speziellen Hardwarefunktionalität enthält, die in einer anwendungsspezifisch programmierbaren, integrierten Schaltung realisierbar ist. Durch deren Kombination mit signierten elektronischen Münzen, diversen Zertifikatsdiensten und dem digitalen Portmonee lässt sich daraus ein elektronisches Bargeldsystem konzipieren. Es erfordert allerdings ein eigenes Übertragungsprotokoll, das erst noch zu standardisieren und einzuführen wäre, und spezielle, zu verbreitende Hardwarekomponenten.

Gegenwärtig existiert eine wachsende Anzahl von Systemen, die den Zugang zum Internet und den darauf basierenden Diensten ermöglichen. Unter verschiedenen Betriebssystemen werden neben den Klassikern immer neue Web-Browser entwickelt, für die regelmäßig neue Versionen veröffentlicht werden. Dabei gelang es bislang lediglich, Mindeststandards stringent durchzusetzen.

Uber den Erfolg oder Misserfolg von Problemlösungen für das Internet und dessen Dienste entscheidet in letzter Konsequenz in aller Regel die Anwenderfreundlichkeit. Umständliche oder schwer nachvollziehbare Angebote werden erfahrungsgemäß vom Internet-Benutzer nicht angenommen, während einfach konzipierte und verständlich dargebotene Applikationen gerne aufgegriffen und sogar an andere Nutzer weiterempfohlen werden. Zahlreiche Anwender lehnen neue Systeme mit der Begründung ab, dass ihnen die Installation notwendiger Software lästig sei bzw. neue, unerwünschte Sicherheitsrisiken in sich berge.

Geld verkörpert Kaufkraft, die auf den ersten Blick in einem unbestechlichen Zahlenwert ausgedrückt ist. Diese gezielt rationale Eigenschaft steht aber in der Regel in einem auffälligen Kontrast zum emotionalen Verhältnis seines Besitzers. Werte wie Sicherheit, Vertrauen und Zuverlässigkeit spielen dabei eine dominante Rolle. Das menschliche Kontrollbedürfnis verlangt nach Transparenz über den Verbleib und den Bestand des verfügbaren Geldes. Darüber hinaus erzeugen Unsicherheit und Verlustängste unweigerlich Unbehagen.

Elektronisches Geld, das von der Installation individueller Softwareelemente abhängt, würde wegen der verbreiteten Systemvielfalt unvermeidbar von einem nicht zu vernachlässigenden Teil der vorhandenen Systeme als solches nicht erkannt werden können. Dadurch wird der Anwender zwangsläufig verunsichert. Muss er um sein Geld bangen, wird sein Vertrauen in das Zahlungsmittel erschüttert.

Daher sind die im Stand der Technik bekannten Verfahren noch nicht optimal ausgebildet. Im Stand der Technik ist kein sicheres Verfahren und zugehöriges elektronisches Zahlungsmittel bekannt, das sich für das Internet eignet und eine ähnlich unkomplizierte und anonyme Zahlung wie mit Bargeld ermöglicht, ohne dass dafür spezifische Hardwarekomponenten eingeführt oder Softwareprogramme verbreitet werden müssen. Die Aufgabenstellung gestaltet sich vor allem deshalb so schwierig, weil die zentrale Schwachstelle bei elektronischem Bargeld in der Gefahr einer missbräuchlichen Vervielfältigung besteht.

Der Erfindung liegt daher die Aufgabe zu Grunde, ein Verfahren zur Bezahlung mit mindestens einem gültigen, elektronischen Zahlungsmittelschlüssel derart weiterzubilden und auszugestalten, dass das Verfahren sich einerseits für den digitalen Raum eignet, andererseits aber eine lückenlose Rückverfolgung des Zahlungswegs ausschließt und gleichzeitig für den Anwender einfach zu handhaben ist.

Diese Aufgabe wird erfindungsgemäß durch ein Verfahren zur Bezahlung mit mindestens einem elektronischen Zahlungsmittelschlüssel gelöst, wobei auf einem Serversystem mindestens ein Zahlungsmittelverifizierungsdatensatz mit einem Zahlungswert und mit einem Verifizierungsschlüssel gespeichert ist, wobei jedem gültigen Zahlungsmittelschlüssel mindestens ein

Zahlungsmittelverifizierungsdatensatz zugeordnet ist, wobei der

Zahlungsmittelschlüssel an einem Speicherort gespeichert ist, wobei der

Speicherort einem Zahlungspflichtigen zur Verfügung steht, mit den folgenden Schritten:

+ Verbindungsaufbau zwischen einer Datenverarbeitungsanlage eines

Zahlungsempfängers und dem Serversystem,

+ Verbindungsaufbau zwischen einer Datenverarbeitungsanlage des

Zahlungspflichtigen und dem Serversystem,

+ Zuordnen des Zahlungsempfängers und des Zahlungspflichtigen,

+ Übermitteln des Zahlungsmittelschlüssels an das Serversystem,

+ Überprüfen der Gültigkeit des Zahlungsmittelschlüssels,

+ Ändern des Verifizierungsschlüssels sowie Erstellen eines neuen,

zugeordneten Zahlungsmittelschlüssels, im Fall dass der übermittelte und überprüfte Zahlungsmittelschlüssel gültig ist, oder

+ Löschen des Verifizierungsschlüssels sowie Erstellen eines neuen Verifizierungsschlüssels und eines neuen, zugeordneten

Zahlungsmittelschlüssels, im Fall dass der übermittelte und überprüfte

Zahlungsmittelschlüssel gültig ist,

+ wobei der neue Zahlungsmittelschlüssel an einem dem Zahlungsempfänger zur Verfügung stehenden, weiteren Speicherort gespeichert wird oder ist.

Der Zahlungsmittelverifizierungsdatensatz kann jeweils eine oder mehrere Verzeichnisse und/oder Dateien und/oder Datensätze und/oder Verknüpfungen aufweisen. Das Serversystem mit dem Zahlungsmittelverifizierungsdatensatz unterliegt der Verfügungsgewalt des oder der Emittenten. Emittent kann ein Geldinstitut sein. Der Zahlungsmittelverifizierungsdatensatz wird auf einem oder mehreren Servern zentral verwaltet. Der

Zahlungsmittelverifizierungsdatensatz weist mindestens einen eindeutigen Verifizierungsschlüssel auf. Der Verifizierungsschlüssel ist vorzugsweise nach dem Zufallszahlenprinzip ermittelt.

Der Zahlungsmittelschlüssel bildet eine Referenz auf den Zahlungsmittelverifizierungsdatensatz. Diese Referenz kann eindeutig sein, das heißt jedem Zahlungsmittelschlüssel ist genau ein

Zahlungsmittelverifizierungsdatensatz zugeordnet. Es können jedoch alternativ einem Zahlungsmittelschlüssel mehrere

Zahlungsmittelverifizierungsdatensätze zugeordnet sein. Der

Zahlungsmittelschlüssel dient dabei als Autorisierungsmittel.

Unter Referenz werden alle Möglichkeiten der Bezugnahme verstanden. Eine Referenz kann in der bloßen Identität einer einmalig vergebenen Zeichenfolge bestehen, aber auch in einem Verweis, einer Verlinkung, einer Verknüpfung oder irgendeiner anderen Form der Referenzierung.

Der Zahlungsmittelschlüssel kann insbesondere eine oder mehrere Dateien, Datensätze, Verknüpfungen und/oder Verzeichnissen aufweisen bzw. aus diesen bestehen. Der Zahlungsmittelschlüssel unterhegt der Verfügungsgewalt des Inhabers, d.h. zu Beginn des Verfahrens unterliegt der Zahlungsmittelschlüssel der Verfügungsgewalt des Zahlungspflichtigen und am Ende des Verfahrens der Verfügungsgewalt des Zahlungsempfängers.

Der Zahlungsmittelschlüssel ist zu Beginn an einem Speicherort des Zahlungspflichtigen gespeichert und insbesondere einer

Datenverarbeitungsanlage des Zahlungspflichtigen bzw. des Zahlungsempfängers zugeordnet. Diese Datenverarbeitungsanlagen können als Personal Computer, Laptop, Smartphone, Handy oder dergleichen ausgebildet sein. Der Zahlungsmittelschlüssel ist dabei am Speicherort auf einem Speichermittel, beispielsweise einer Festplatte, einem USB-Stick, einer CD einer DVD oder dgl., der Datenverarbeitungsanlage gespeichert. Diese Datenverarbeitungsanlagen können auch als Client bezeichnet werden.

Der Zahlungsmittelschlüssel stimmt insbesondere mit dem zugehörigen Verifizierungsschlüssel des serverseitigen

Zahlungsmittelverifizierungsdatensatzes identisch überein oder ist vorzugsweise über eine entsprechende Funktion dem Verifizierungsschlüssel zuordenbar, sofern der Zahlungsmittelschlüssel gültig ist. Durch Uberprüfung der Zuordenbarkeit des Zahlungsmittelschlüssels zu den Verifizierungsschlüssel(n) wird überprüft, ob der Zahlungsmittelschlüssel gültig oder ungültig ist. Wenn beispielsweise ein

Zahlungsmittelverifizierungsdatensatz mit einem dem Zahlungsmittelschlüssel zugeordneten Verifizierungsschlüssel existiert, dann ist der Zahlungsmittelschlüssel gültig. Wenn kein zugehöriger

Zahlungsmittelverifizierungsdatensatz existiert, dann ist der Zahlungsmittelschlüssel ungültig.

Das Verfahren weist eine insbesondere von einem Serversystem bereitgestellte Funktion zur Abbildung des Bezahlvorganges auf. Diese Funktion und das Serversystem stehen insbesondere unter der Verfügungsgewalt des Emittenten.

Der Zahlungsempfänger und der Zahlungspflichtige bauen eine Verbindung mit dem Serversystem auf. Die Verbindung zum Serversystem kann insbesondere über eine Internetverbindung aufgebaut werden. Der Verbindungsaufbau mit dem Serversystem erfolgt vorzugsweise über eine verschlüsselte Verbindung. Nach dem Verbindungsaufbau erfolgt eine Zuordnung des Zahlungspflichtigen und des Zahlungsempfängers. Das Serversystem stellt insbesondere einer Vielzahl von Personen die entsprechenden Bezahlvorgänge zur Verfügung.

Durch den Zahlungsempfänger wird ein neuer Bezahlvorgang auf dem Serversystem gestartet. Der Bezahlvorgang wird dem Zahlungspflichtigen und dem Zahlungsempfänger quasi-synchron dargestellt. Diese Darstellung erfolgt zum einen über die Verbindung zwischen der Datenverarbeitungsanlage des Zahlungsempfängers und dem Serversystem und zum anderen über die Verbindung zwischen der Datenverarbeitungsanlage des Zahlungspflichtigen und dem Serversystem. Da unterschiedliche Verbindungen genutzt werden, kann die Darstellung als quasi-synchron bezeichnet werden.

Diesem Bezahlvorgang ist insbesondere ein Identifikationsmerkmal zugewiesen, beispielsweise eine eindeutige Nummer. Das Starten des Bezahlvorgangs wird dem verbundenen Zahlungspflichtigen angezeigt. Von dem Zahlungspflichtigem wird der Bezahlvorgang auf dem Serversystem ausgewählt. Insbesondere kann der Zahlungsempfänger dem Zahlungspflichtigen das Identifikationsmerkmal mitteilen, damit der Zahlungspflichtige den gewünschten Bezahlvorgang auswählen kann.

Das Identifikationsmerkmal kann über eine optoelektronische Schnittstelle, insbesondere mittels eines Strichcodes, dargestellt werden, wobei zumindest die Internetadresse des Serversystems mit dem zugehörigen Bezahlvorgang übermittelt wird. Der Strichcode kann weitere Informationen enthalten.

Der Zahlungsempfänger kann dem Zahlungspflichtigen den Strichcode, insbesondere einen QR-Code bereitstellen, wobei der QR-Code unter anderem das Identifikationsmerkmal enthält. Das Identifikationsmerkmal wird dem Zahlungspflichtigen als QR-Code dargestellt, wobei der QR-Code eine Internetadresse des Serversystems mit dem zugehörigen Bezahlvorgang aufweist. Der Zahlungspflichtige kann den beispielsweise in einem Geschäft an der Kasse abgebildeten QR-Code mit seinem Smartphone - d.h. seiner Datenverarbeitungsanlage - optoelektronisch einlesen und wird mit seinem Smartphone mit der entsprechenden Internetadresse des Serversystems mit dem zugehörigen Bezahlvorgang verbunden.

Ferner kann das Identifikationsmerkmal über eine drahtlose Schnittstelle übermittelt werden. Das Identifikationsmerkmal kann über eine Funkschnittstelle übermittelt werden, insbesondere über Near Field Communication (NFC), wobei zumindest die Internetadresse des Serversystems mit dem zugehörigen Bezahlvorgang übermittelt wird.

Der Bezahlvorgang kann den Beteiligten als das Erstellen und Auswählen einer „Kasse" dargestellt werden. Es bieten sich hierzu jedoch auch andere Bezeichnungen und Darstellungen, wie „Transaktion", „Bezahlvorgang" und dgl. an.

Dass der Zahlungspflichtige dem Bezahlvorgang beigetreten ist, wird dem Zahlungsempfänger angezeigt. Dass der Zahlungsempfänger dem Bezahlvorgang ebenfalls beigetreten ist, wird dem Zahlungspflichtigen angezeigt.

Der zu zahlende Betrag wird durch den Zahlungsempfänger bereitgestellt bzw. eingegeben und dem Zahlungspflichtigen angezeigt. Danach erhält der Zahlungspflichtige die Möglichkeit, den geforderten Betrag zu bezahlen. Hierzu wird der Zahlungsmittelschlüssel von der Datenverarbeitungsanlage des Zahlungspflichtigen auf das Serversystem übermittelt.

Der Zahlungsmittelschlüssel kann beispielsweise aus einer Datei bestehen oder in einer Datei mit weiteren Informationen enthalten sein. Die Datei ist insbesondere als Bild-Datei ausgebildet, wobei der Zahlungsmittelschlüssel in den Metadaten, insbesondere einem Kommentarsegment der Bilddatei, gespeichert ist. Diese Datei bzw. der Zahlungsmittelschlüssel wird von dem Zahlungspflichtigen auf das Serversystem übermittelt bzw. hochgeladen.

Alternativ kann der Zahlungsmittelschlüssel steganographisch in eine Datei eingebettet werden. Der Zahlungsmittelschlüssel ist dabei verborgen in der Datei gespeichert. Die Datei enthält dabei offensichtliche Informationen, beispielsweise einen Text und/oder Bild- und/oder Audio-Informationen, wobei in diesen offensichtlichen Informationen der Zahlungsmittelschlüssel verborgen ist. Die offensichtlichen Informationen dienen als Träger des verborgenen Zahlungsmittelschlüssels. Die offensichtlichen Informationen weisen ein Signal und ein Rauschen auf, wobei der Zahlungsmittelschlüssel im Rauschen verborgen enthalten ist.

Ferner kann der Zahlungsmittelschlüssel als digitales Wasserzeichen in einer Datei eingebettet werden. Digitale Wasserzeichen haben mit der Steganographie gemein, dass eine öffentliche Information als Träger verwendet wird, wobei das Wasserzeichen in die öffentliche Information eingebettet wird. Das digitale Wasserzeichen ist insbesondere robust. Der Zahlungsmittelschlüssel kann nicht unbemerkt aus der Datei entfernt werden. Das Wasserzeichen sollte auch nicht durch Umwandeln in ein anderes Dateiformat zerstört werden.

Der Zahlungsmittelschlüssel kann alternativ in einer Datei enthalten sein, wobei die Datei zusätzlich ein digitales Wasserzeichen aufweist. Das Wasserzeichen kann dazu dienen die Datei als Wertgegenstand zu kennzeichnen.

Der Zahlungsmittelschlüssel wird dann auf Gültigkeit überprüft. Dazu wird auf einen zugehörigen Zahlungsmittelverifizierungsdatensatz zugegriffen. Der Zahlungsmittelverifizierungsdatensatz enthält dazu ebenfalls einen Schlüssel, nämlich einen Verifizierungsschlüssel. Es gibt nun unterschiedliche Möglichkeiten, wie auf dem Serversystem die Gültigkeit des Zahlungsmittelschlüssels gespeichert und überprüft werden kann. Insbesondere kann jeder Zahlungsmittelschlüssel ein Zahlungsmittel-

Identifikationsmerkmal, beispielsweise eine Seriennummer aufweisen. Dieses Zahlungsmittehdentifikationsmerkmal kann Teil des Zahlungsmittelschlüssels und des Verifizierungsschlüssels sein oder in einem separaten Datenfeld abgespeichert sein. Im Zahlungsmittelverifikationsdatensatz mit dem identischen Identifikationsmerkmal ist nun der Verifizierungsschlüssel gespeichert. Es wird überprüft, ob der Verifizierungsschlüssel des Zahlungsmittelverifikationsdatensatzes und der Zahlungsmittelschlüssel zuordenbar sind. Der Zahlungsmittelschlüssel ist gültig, wenn die beiden Schlüssel übereinstimmen oder über eine eindeutige Funktion der Zahlungsmittelschlüssel auf den Verifizierungsschlüssel abbildbar ist, ansonsten ist der Zahlungsmittelschlüssel ungültig. In einer bevorzugten Ausgestaltung erfolgt die eindeutige Zuordnung des Zahlungsmittelschlüssels über die eindeutige Funktion. Die beiden Schlüssel müssen daher nicht identisch sein, damit der Zahlungsmittelschlüssel gültig ist. Diese Funktion kann beispielsweise eine Verschlüsselung umfassen. Die Sicherheit des Verfahrens ist dadurch erhöht.

Es ist möglich, dass einem Zahlungsmittelschlüssel mehrere Zahlungsmittelverifizierungsdatensätze zugeordnet sind. Diese Zahlungsmittelverifizierungsdatensätze weisen dabei vzw. den gleichen Verifizierungsschlüssel auf. Der Zahlungspflichtige kann dann durch Übermittlung eines Zahlungsmittelschlüssels auf mehrere Zahlungsmittelverifizierungsdatensätze zum Zwecke der Bezahlung zugreifen. Übermittelt der Zahlungspflichtige einen Zahlungsmittelschlüssel mit mehreren zugeordneten Zahlungsmittelverifizierungsdatensätzen, so werden nur diejenigen Verifizierungsschlüssel geändert oder gelöscht, welche zur Bezahlung des durch den Zahlungsempfänger geforderten Betrages erforderlich sind.

Wenn der Zahlungsmittelschlüssel ungültig ist, dann wird angezeigt, dass der Zahlungsmittelschlüssel ungültig ist. Der Betrag kann nicht mit einem ungültigen Zahlungsmittelschlüssel getilgt werden.

Wenn der übermittelte und danach überprüfte Zahlungsmittelschlüssel gültig ist, dann wird der Verifizierungsschlüssel geändert oder gelöscht. Wenn der Verifizierungsschlüssel gelöscht wurde, wird ein neuer Verifizierungsschlüssel erstellt. Ferner wird ein neuer Zahlungsmittelschlüssel erstellt, wobei der neue Zahlungsmittelschlüssel dem neuen bzw. geänderten Verifizierungsschlüssel zugeordnet ist. Insbesondere ist der Zahlungsmittelschlüssel mittels der Funktion dem Verifizierungsschlüssel zuordenbar.

Der neue oder geänderte Verifizierungsschlüssel wird vorzugsweise durch eine Zufallszahl erzeugt. Der Zahlenraum ist hinreichend groß, aus dem die Zufallszahl stammt, so dass mit der nötigen Wahrscheinlichkeit ausgeschlossen werden kann, dass der Zahlungsmittelschlüssel durch Ausprobieren von Kombinationen erraten werden kann. Der neue Zahlungsmittelschlüssel wird in einer Ausgestaltung vom Serversystem erstellt und vom Serversystem an den Zahlungsempfänger übermittelt.

Durch das Ändern des Verifizierungsschlüssels wird ein neuer Zahlungsmittelschlüssel erstellt. Alle Kopien des ursprünglichen Zahlungsmittelsschlüssels werden in Zukunft nicht mehr als gültig angenommen, da der Verifizierungsschlüssel geändert worden ist. Es ist denkbar, dass der neue Zahlungsmittelschlüssel ein neues Zahlungsmittelidentifikationsmerkmal erhält oder dass der neue Zahlungsmittelschlüssel das Zahlungsmittelidentifikationsmerkmal des ursprünglichen Zahlungsmittelschlüssels behält.

Durch die Ersetzung des Verifikationsschlüssels wird die Fälschungssicherheit des Zahlungsmittelschlüssels gewährleistet. Sobald ein Zahlungsempfänger ein Exemplar des Zahlungsmittelschlüssels erhält, verfügt der Zahlungsempfänger nicht über die Kenntnis darüber, in wie vielen Ausfertigungen dieses Exemplar mittlerweile vorliegt. Beispielsweise könnte es von einem Vorinhaber - dem Zahlungspflichtigen - vielfach dupliziert worden sein und so zu Zahlungszwecken parallel an etliche andere Zahlungsempfänger weitergegeben worden sein. Es besitzt jedoch nur der neue Zahlungsmittelschlüssel Gültigkeit.

Andernfalls würde der Zahlungsmittelschlüssel eine unkontrollierte Vermehrung und damit eine inflationäre Entwertung der Geldmenge herbeiführen. Sobald aber der Zahlungsempfänger den neuen Zahlungsmittelschlüssel über das Serversystem bzw. dem Bezahlvorgang vom Zahlungspflichtigen erhält bzw. sobald der Zahlungsempfänger einen neuen Zahlungsmittelschlüssel vorgeschlagen hat und dieser neue Zahlungsmittelschlüssel vom Serversystem akzeptiert wurde, wurde der Verifizierungsschlüssel geändert und damit werden alle Kopien des alten Zahlungsmittelschlüssels ungültig. Von dem neuen Exemplar des Zahlungsmittelsschlüssels kann der Zahlungsempfänger sicher sein, dass nur er als Zahlungsempfänger diesen neuen Zahlungsmittelschlüssel besitzt. Nur der Zahlungsempfänger bestimmt darüber, wie viele Duplikate er von dem neuen Zahlungsmittelschlüssel anfertigt.

Der neue Zahlungsmittelschlüssel wird in einer Ausgestaltung nun vom Serversystem an den Zahlungsempfänger übermittelt. Dies kann dadurch realisiert werden, dass der Zahlungsempfänger den Zahlungsmittelschlüssel in Form einer Datei herunterladen kann. Der neue Zahlungsmittelschlüssel enthält dabei den geänderten Zahlungsmittelschlüssel. Der geänderte oder neue Zahlungsmittelschlüssel wird dann an einem dem Zahlungsempfänger zur Verfügung stehenden, weiteren Speicherort gespeichert.

Beim Erstellen des neuen Zahlungsmittelschlüssels kann in alternativer Ausgestaltung der neue Zahlungsmittelschlüssel vom Zahlungsempfänger vorgeschlagen werden. Der neue Zahlungsmittelschlüssel wird von der Datenverarbeitungsanlage des Zahlungsempfängers an das Serversystem übermittelt, wobei der Zahlungsmittelschlüssel über die Funktion in einen neuen Verifizierungsschlüssel umgewandelt und auf dem Serversystem gespeichert wird. Der geänderte oder neue Zahlungsmittelschlüssel kann bereits an einem dem Zahlungsempfänger zur Verfügung stehenden, weiteren Speicherort gespeichert sein oder falls dies noch nicht der Fall ist, kann der geänderte oder neue Zahlungsmittelschlüssel dann an einem dem Zahlungsempfänger zur Verfügung stehenden, weiteren Speicherort gespeichert werden.

Der Zahlungsmittelschlüssel kann mit einer Bild-, einer Audio- und/oder einer Videoinformation verknüpft sein. Dies kann dadurch realisiert sein, dass eine Bild-, eine Audio- und/oder eine Videoinformation in einer Datei in einem Dateiformat mit zusätzlichen Metadaten, beispielsweise mit mindestens einem Kommentarsegment, gespeichert ist, wobei der oder die Zahlungsmittelschlüssel in den Metadaten bzw. in dem oder in den Kommentarsegmenten der Datei hinterlegt ist/sind.

Alternativ kann der Zahlungsmittelschlüssel des Zahlungspflichtigen und/oder des Zahlungsempfängers eine Bild-, eine Audio- und/oder eine Videoinformation aufweisen. D.h. der Zahlungsmittelschlüssel umfasst die Bild-, eine Audio- und/oder eine Videoinformation und gegebenenfalls weitere Informationen.

Dem Zahlungsempfänger wird der Eingang des neuen Zahlungsmittelschlüssels durch Darstellung eines Geldmittels, insbesondere einer Münze oder einer Banknote dargestellt. Herkömmliches Geld in physischer Form von Münzen oder Banknoten ist bekanntlich im täglichen Gebrauch der permanenten Gefahr ausgesetzt, verloren, verlegt oder entwendet zu werden. Beim elektronischen Zahlungsmittelschlüssel nach der vorliegenden Erfindung dagegen kann diesem Risiko dadurch vorgebeugt werden, dass der Inhaber jedes Exemplar des Zahlungsmittelsschlüssels in mehrfacher Ausfertigung an unterschiedlichen Orten deponiert. Kommt ihm nun eine Ausfertigung abhanden, kann er auf eine andere zurückgreifen.

Die Schritte des Bezahl Vorgangs werden sowohl dem Zahlungspflichtigen als auch dem Zahlungsempfänger im Wesentlichen gleichzeitig dargestellt. Die Darstellung erfolgt insbesondere quasi-synchron. Der Zahlungsempfänger und der Zahlungspflichtige sind mit dem Serversystem insbesondere über eine Internet- Verbindung verbunden. Zur Darstellung des Bezahlvorganges können die bekannten Übertragungsprotokolle benutzt werden, so dass keine zusätzliche Software auf den Datenverarbeitungsanlagen des Zahlungsempfängers und/oder des Zahlungspflichtigen installiert werden muss.

Die gegenwärtig vor allem im Internet üblichen elektronischen Zahlungsmethoden werden über Buchungsverfahren abgewickelt, bei denen die Identität der beteiligten Parteien dokumentiert wird. Der hier verwendete elektronische Zahlungsmittelschlüssel ist insbesondere anonym, d.h. der Zahlungsmittelschlüssel enthält keine Informationen über den Besitzer. Der Zahlungsmittelschlüssel lässt keinerlei Rückschlüsse auf die Identität seines Inhabers zu. Insbesondere ist weder die Hinterlegung personenbezogener Daten des Inhabers noch einer Kunden- oder Kontonummer erforderlich.

Es ist dazu weder die Installation einer individuellen Software erforderlich noch die Anschaffung einer zusätzlichen Hardwarekomponente, sondern es werden Elemente verwendet, die einen hohen Verbreitungsgrad besitzen und eine breite Akzeptanz genießen, sowie darüber hinaus eine Handhabungsweise bieten, die konventionellem Bargeld ähnelt, dieses dabei aber an Anwenderfreundlichkeit übertrifft, und zudem die Verwendung hinreichender Sicherheitsstandards erzwingt.

Bei der vorliegenden Erfindung liegt der Zahlungsmittelverifizierungsdatensatz auf dem Serversystem des Emittenten und enthält einen oder mehrere Verifizierungsschlüssel, die insbesondere nach dem Zufallszahlenprinzip erzeugt wurden. Der Inhaber verfügt über den Zahlungsmittelschlüssel in Form einer Eeferenz auf einen oder mehrere Zahlungsmittelverifizierungsdatensätze, beispielsweise in Form einer Bild-, Audio- oder Videodatei, in der der oder die Verifizierungsschlüssel hinterlegt sind.

Die Bildinformation kann insbesondere ein Geldmittel darstellen. Unter einem Geldmittel werden alle Medien verstanden, deren überwiegende Zweckbestimmungen in der Übertragung von Werten besteht, insbesondere Münzen wie zum Beispiel Geldmünzen, Gedenkmünzen, Spielchips, Jetons oder ähnliches sowie Wertpapiere wie beispielsweise Banknoten, Gutscheine, Bons, Billets, Tickets oder ähnliches und Zahlungsanweisungen wie etwa Schecks, Wechsel oder ähnliches.

Zusätzlich enthält das Verfahren eine Bezahlungsvorgangsfunktion insbesondere auf dem Serversystem, über die der Zahlungsmittelschlüssel zwischen dem Zahlungsempfängers und dem Zahlungspflichtigen ausgetauscht und dabei geändert wird. Vorzugsweise werden einige, insbesondere alle Schritte des Ubergabevorgangs beiden beteiligten Parteien in Echtzeit quasisynchron dargestellt. Die Bezahlvorgangsfunktion nimmt dazu den Zahlungsmittelschlüssel vom Zahlenden entgegen, ersetzt den oder die Verifizierungsschlüssel durch neue Verifizierungsschlüssel und gibt vorzugsweise den Zahlungsmittelschlüssel an den Zahlungsempfänger weiter. Damit werden alle früheren Kopien des übergebenen Exemplars des Zahlungsmittelsschlüssels ungültig.

Die mit der Erfindung erzielten Vorteile bestehen insbesondere darin, dass der erfindungsgemäße elektronische Zahlungsmittelschlüssel durch eine Referenz auf einen oder mehrere der Zahlungsmittelverifizierungsdatensätze auf dem Serversystem bereitgestellt wird. Damit ist der Zahlungsmittelschlüssel auf dem Rechner des Anwenders sichtbar und er kann auch darüber beliebig verfügen, beispielsweise durch Weitergabe an Dritte. Die Referenz bzw. der Zahlungsmittelschlüssel kann zum Beispiel aus einem Link bestehen. Im minimalistischsten Fall besteht die Referenz lediglich aus einer Zeichenkette, die den Zahlungsmittelschlüssel wiedergibt.

Eine Manipulationsmöglichkeit der Gültigkeit des Zahlungsmittelsschlüssels scheidet ohne Zugriff auf das Serversystem als Referenzpunkt dennoch aus. Lediglich für die Verbindung zu der Funktion des Serversystems, die den Zahlungsvorgang in Echtzeit bei quasi-synchroner Darstellung ermöglicht, sind verschlüsselte Übertragungsmethoden erforderlich. Dabei kann jedoch auf herkömmliche gesicherte Übertragungsverfahren zurückgegriffen werden.

Außerdem befindet sich somit auf der Datenverarbeitungsanlage des Zahlungsmittelschlüssel-Inhabers nur eine sehr geringe Datenmenge, die verhältnismäßig wenig Speicherplatz in Anspruch nimmt. So lassen sich auch auf mobilen Endgeräten mit vergleichsweise kleinem Speicherangebot große Geldmengen bevorraten. Auch wenn die Referenz etwa in einem Action -Attribut eines Form-Tags in der Auszeichnungssprache HTML abgebildet ist, belegt der HTML-Code nur geringfügigen Speicherplatz.

Ein weiterer Vorteil liegt darin, dass der Zahlungsmittelschlüssel beispielsweise als HTML-Code in Gestalt eines Form-Tags oder eines Links in Form eines von Menschen lesbaren Textes und nicht in einem binär verschlüsselten Format vorliegt. Dadurch werden der Umgang mit dem Zahlungsmittelschlüssel und seine Handhabung erleichtert.

Der Bezahlvorgang besteht zudem aus mindestens einer Funktion auf einem Server, der unter der Verfügungsgewalt des Emittenten steht. Dort tauschen die beteiligten Parteien den Zahlungsmittelschlüssel in Echtzeit aus, indem beispielsweise ein Zahlungsmittelschlüssel in Form eines abgebildeten Geldscheins zur Bezahlung hingegeben und ein neuer Zahlungsmittelschlüssel in Form einer Abbildung von Münzen als Wechselgeld zurückgeben werden. Bei Uberzahlung des gewünschten Betrages wird der überbezahlte Restbetrag vom Serversystem in Form von weiteren Zahlungsmittelschlüsseln zurück übermittelt und/oder es wird eine entsprechende Anzahl von Verifizierungsschlüsseln geändert. Diese(r) weitere(n) Zahlungsmittelschlüssel wird/werden insbesondere in der geringsten Stückelung übermittelt. Bei jedem Austausch eines Zahlungsmittelschlüssels ändert die Funktion den Verifizierungsschlüssel und gewährleistet so, dass alle bisherigen Kopien des Zahlungsmittelsschlüssels ungültig werden bzw. der alte Zahlungsmittelschlüssel nicht den entsprechenden

Zahlungsmittelverifizierungsdatensätzen zugeordnet ist.

Der Aufruf der Funktion kann etwa ganz einfach durch Anklicken eines HTML- Links ausgelöst werden, wenn die Referenz als solcher ausgelegt ist. Die Rückgabe kann als Download gestaltet werden, der von der angesprochenen Funktion angeboten wird. Der detaillierte Vorgang wird in Beispiel 1 ausführlich beschrieben.

Vorteilhafte Ausgestaltungen der Erfindung sind in den nachgeordneten Patentansprüchen angegeben.

Eine Fortbildung der Erfindung wird in Patentanspruch 2 beschrieben. Auf dem Client verleiht eine ansprechende illustrative, auditive oder audiovisuelle statt textliche Darstellung des Zahlungsmittelsschlüssels dem erfindungsgemäßen Zahlungsmittelschlüssel eine erhöhte optische oder akustische Attraktivität und erleichtert damit den Umgang mit diesem neuen Medium. Dieses Bild nach Patentanspruch 2 kann, wie in Patentanspruch 3 fortgebildet, auch auf einem Serversystem des Emittenten hinterlegt sein. Dort können einerseits für Exemplare, die aus dem Verkehr genommen und damit ungültig sind, und andererseits für solche, die sich noch gültig in Umlauf befinden, unterschiedliche Darstellungen hinterlegt werden. Für ungültige Exemplare bietet sich etwa ein ausgegrautes Bild, eine passende Tonfolge oder ein Film mit entsprechendem Inhalt an. Auch eine Wiedergabe in praktisch nicht mehr sichtbarer Größe von einem Pixel oder die Stummschaltung einer Tonfolge käme in Frage. Das erleichtert beim Anwender die Ubersicht, welche Exemplare noch Gültigkeit haben und sich in seinem Besitz befinden und welche er bereits zur Zahlung ausgegeben hat.

Für das Bild kann ein Format wie etwa jpeg, png, gif, tif oder ico oder für die Audiosequenz beispielsweise wav, aac, mp3 oder wma oder für die Videosequenz zum Beispiel mpg, avi, mov, mp4 oder wmv verwendet werden. Dadurch ergibt sich der Vorteil, dass sich die Medien auf den Systemen der allermeisten Anwender problemlos nativ als solche darstellen lassen. Denn der kognitive Aspekt spielt im Hinblick auf die Anwenderfreundlichkeit eine tragende Rolle.

So wird zudem praktisch ausgeschlossen, dass der Inhaber über ein Exemplar des Zahlungsmittelschlüssels verfügt, der auf seinem System aber nicht in der erwarteten Weise dargestellt wird. Damit werden Schrecksituationen vermieden, die von Verlustängsten ausgelöst werden, und aufwendige Bemühungen erspart, verloren geglaubtes Geld zurückzuholen. Denn bekanntlich reagieren Benutzer auf technische Störung bei monetären Transaktionen besonders gereizt. Die Ursache kann in dem existenziellen und deshalb so sensiblen Verhältnis der Menschen zu ihrem Geld vermutet werden.

Durch den Rückgriff auf weit verbreitete Standards erhöhen sich auch die Verbreitungschancen des erfindungsgemäßen Zahlungsmittels. So müssen nicht erst technische Voraussetzungen erfüllt und Standardisierungsabsprachen getroffen werden, sondern die Einführung kann ohne weitere Vorbedingungen sofort veranlasst werden. Das Bild des Zahlungsmittelsschlüssels stellt nach der Fortbildung in Patentanspruch 11 ein allgemein bekanntes Geldmittel als Bildinformation dar, als welches es verwendet wird. So kann das Bild zum Beispiel eine Geldmünze, eine Gedenkmünze, einen Spielchip, einen Jeton oder ähnliches oder ein Wertpapier wie beispielsweise eine Banknote, einen Gutschein, einen Bon, ein Billet, ein Ticket oder ähnliches oder eine Zahlungsanweisung wie etwa einen Scheck, einen Wechsel oder ähnliches zeigen. Wird der erfindungsgemäße Zahlungsmittelsschlüssel beispielsweise als Geldmünze oder Banknote verwendet, kann die Abbildung beispielsweise sein konventionelles physisches Äquivalent mit entsprechendem Wert wiedergeben.

Auch werden elektronische Bilder ähnlich wie Geldmünzen oder -scheine als gegenständliche diskrete Objekte wahrgenommen, über die nach vergleichbaren Regeln der Handhabung verfahren werden kann. So können sie zum Beispiel von einem Ort an den anderen verschoben, gezählt, sortiert oder abgelegt werden. Abstrakten Bezahlverfahren dagegen fehlen diese Parallelen.

Somit wird der elektronische Zahlungsmittelschlüssel in bildlicher Gestalt noch stärker mit herkömmlichen Zahlungsmitteln assoziiert und vor allem älteren Verwendern fällt die Umstellung auf die neue elektronische Form noch leichter.

Die Darstellung des Zahlungsmittelsschlüssels kann dagegen aber auch durch die Wiedergabe beliebter Musikstücke erfolgen oder durch das Abspielen von Ausschnitten angekündigter Kinofilme oder von Werbespots. Dadurch wird die Institution Geld um eine Funktionalität erweitert, die über ihre herkömmliche Aufgabe hinausgeht und geeignet ist, seiner elektronischen Variante ein Attraktivitätsmerkmal zu verleihen, das sich für die breite Akzeptanz vor allem beim jüngeren Publikum als entscheidend erweisen kann. Auch bedient diese Ausgestaltung die Forderung nach neuen multimedialen Entwürfen, die im Zuge des Generationenwechsels zu HTML5 augenblicklich formuliert werden.

In Patentanspruch 12 wird die Erfindung weitergebildet, indem der oder die Zahlungsmittelschlüssel im Maschinencode der Bild-, Audio- oder Videodatei abgelegt werden. Dadurch werden die Daten kompakt zusammengefasst und eine weitere Datei für die Aufnahme dieser Informationen wird obsolet.

Patentanspruch 13 führt diesen Ansatz weiter. Der oder die Schlüssel werden als Strichcode, insbesondere als QR-Code in die Bild- oder Videodatei aufgenommen. Die grafische Chiffre wird als„Pixelsalat" sichtbar und kann von optischen Dekodiergeräten gelesen und weiterverarbeitet werden. Dadurch wird die Schwelle zwischen digitaler und realer Welt bei der Verwendung des elektronischen Zahlungsmittelschlüssels überwunden. Der Code kann aber zum Beispiel auch von einer Audiodatei akustisch wiedergegeben und dennoch maschinell gelesen werden. Entsprechende Anwendungen sind aus dem Tonwahlbereich im Stand der Technik bekannt.

Dagegen richtet Patentanspruch 10 schließlich den Blick in die entgegengesetzte Richtung und versteckt den oder die Schlüssel in einer Bild-, Audio- oder Videodatei, indem es Dateisegmente, die für Metadaten vorgesehene sind, zur Ablage verwendet.

Im Folgenden werden mehrere Ausgestaltungen der Erfindung anhand der Zeichnung und der dazugehörigen Beschreibung erläutert. In der Zeichnung zeigt:

Fig. 1 in einer schematischen Darstellung eine erste Bildschirmansicht einer ersten Ausgestaltung des Verfahrens,

Fig. 2 in einer schematischen Darstellung eine zweite Bildschirmansicht der ersten Ausgestaltung des Verfahrens,

Fig. 3 in einer schematischen Darstellung eine dritte Bildschirmansicht der ersten Ausgestaltung des Verfahrens,

Fig. 4 in einer schematischen Darstellung eine vierte Bildschirmansicht der ersten Ausgestaltung des Verfahrens, Fig. 5 in einer schematischen Darstellung eine fünfte Bildschirmansicht der ersten Ausgestaltung des Verfahrens,

Fig. 6 in einer schematischen Darstellung eine erste Bildschirmansicht einer zweiten Ausgestaltung des Verfahrens,

Fig. 7 in einer schematischen Darstellung eine zweite Bildschirmansicht einer zweiten Ausgestaltung des Verfahrens,

Fig. 8 in einer schematischen Darstellung eine dritte Bildschirmansicht der zweiten Ausgestaltung des Verfahrens,

Fig. 9 in einer schematischen Darstellung eine vierte Bildschirmansicht der zweiten Ausgestaltung des Verfahrens,

Fig. 10 in einer schematischen Darstellung eine fünfte Bildschirmansicht der zweiten Ausgestaltung des Verfahrens,

Fig. 11 in einer schematischen Darstellung eine sechste Bildschirmansicht der zweiten Ausgestaltung des Verfahrens,

Fig. 12 in einer schematischen Darstellung eine siebte Bildschirmansicht der zweiten Ausgestaltung des Verfahrens, und

Fig. 13 in einer schematischen Darstellung eine achte Bildschirm ansieht einer zweiten Ausgestaltung des Verfahrens.

Im Folgenden darf zunächst auf die Fig. 1 bis 5 Bezug genommen werden.

In den Fig. 1 bis 6 sind die Schritte eines Verfahrens dargestellt zur Bezahlung mit mindestens einem gültigen, elektronischen Zahlungsmittelschlüssel. In den Fig. 1 bis 6 ist eine erste Bildschirm ansieht 1 mit zwei Fenstern 2, 3 jeweils eines Internetbrowsers dargestellt. Das linke Fenster 2 zeigt eine Internetverbindung eines Zahlungsempfängers mit einem Serversystem. Das rechte Fenster 3 zeigt eine Internetverbindung eines Zahlungspflichtigen mit einem Serversystem.

Die Darstellung der Fenster 2, 3 kann insbesondere auf zwei, unterschiedlichen, räumlich getrennten Datenverarbeitungsanlagen in unterschiedlichen Büdschirmansichten erfolgen. Hier wurde die Darstellung auf einer Datenverarbeitungsanlage mit einer gemeinsamen Bildschirmansicht gewählt, um die quasi-synchrone Darstellung in den Fenstern 2, 3 zu verdeutlichen. Der Zahlungsempfänger und der Zahlungspflichtige nutzen hier zur Veranschaulichung dieselbe Datenverarbeitungsanlage.

Die Fenster 2, 3 weisen jeweils einen Bereich für den Zahlungsempfänger bzw. den„Geldnehmer" und einen Bereich für den Zahlungspflichtigen„Geldgeber" auf.

Das Serversystem wird hier durch Aufruf einer Webseite kontaktiert. Die Webseite kann beispielsweise „http://www.mycunia.de" lauten. Das Serversystem steht insbesondere unter der Verfügungsgewalt eines Geldinstituts.

Zu Beginn des Verfahrens erfolgt in einem ersten Schritt nun ein Verbindungsaufbau zwischen einer Datenverarbeitungsanlage eines Zahlungsempfängers und dem Serversystem, und ein Verbindungsaufbau zwischen einer Datenverarbeitungsanlage eines Zahlungspflichtigen und dem Serversystem.

Fig. 1 zeigt die beiden Fenster 2, 3 wobei der jeweilige Verbindungsaufbau vom Zahlungspflichtigen mit dem Serversystem und vom Zahlungsempfänger mit dem Serversystem vorgenommen worden ist. Beide Fenster 2, 3 zeigen zunächst den gleichen Inhalt.

Als nächstes erfolgt im Verfahren das Zuordnen des Zahlungsempfängers und des Zahlungspflichtigen. Hierzu wird ein Bezahlvorgang durch das Serversystem in Form einer Schaltfläche „Neue Kasse" bereitgestellt. Die Schaltfläche „Neue Kasse" wird durch den Zahlungsempfänger betätigt. Hierdurch wird eine neue Kasse - hier die Kasse Nr. 2 - angelegt.

Fig. 2 zeigt, dass dem Zahlungsempfänger in Fenster 2 eine neue Ansicht mit der neuen Kasse Nr. 2 angezeigt wird. Dem Zahlungsempfänger wird eine Eingabemaske bereitgestellt, in der der Zahlungsempfänger den gewünschten Geldbetrag eingeben kann. Es ist durch den Text„Geldgeber abwesend" dem Zahlungsempfänger dargestellt, dass der Zahlungspflichtige bzw. „der Geldgeber" der Kasse Nr. 2 noch nicht beigetreten ist.

In Fenster 3 wird dem Zahlungspflichtigen eine Auswahl der verfügbaren Kassen angezeigt. Im Beispiel ist die angelegte Kasse Nr. 2 verfügbar. Der Zahlungspflichtige kann der ausgewählten Kasse— hier Kasse Nr. 2- beitreten.

Fig. 3 zeigt, dass dem Zahlungspflichtigen im Fenster 3 eine neue Ansicht mit der neuen Kasse Nr. 2 angezeigt wird, nachdem der Zahlungspflichtige der Kasse Nr. 2 beigetreten ist. Dem Zahlungspflichtigen wird in Fenster 3 angezeigt, dass der„Geldnehmer anwesend" ist bzw. der Zahlungsempfänger ebenfalls noch die Kasse angezeigt bekommt. Dem Zahlungspflichtigen wird ferner der geforderte Betrag („Preis"), der bezahlte Betrag („Bezahlt") sowie das Wechselgeld („Zurück") angezeigt, hier jeweils gefolgt von„0.00" da bisher noch kein Betrag gefordert und bezahlt wurde und daher auch noch kein Wechselgeld zu erstatten ist.

Der geforderte Betrag wird nun durch den Zahlungsempfänger im Fenster 2 eingegeben. Durch Betätigung der Schaltfläche „Senden" durch den Zahlungsempfänger wird der gewünschte und eingegebene Betrag gesendet.

Fig. 4 zeigt die Fenster 2, 3 nachdem durch den Zahlungsempfänger der geforderte Betrag bzw.„Preis" im Beispiel 75 eingegeben und gesendet worden ist. Dem Zahlungspflichtigen wird der geforderte Betrag gesendet und angezeigt.

Mit der Schaltfläche „Bezahlen" kann der Zahlungspflichtige den Betrag bezahlen. Dieser Vorgang ist in den Fig. 1 bis 5 nicht im Detail dargestellt, und erfolgt automatisch im Hintergrund.

Der Zahlungsmittelschlüssel ist anfangs auf der Datenverarbeitungsanlage des Zahlungspflichtigen gespeichert. Alternativ kann der Zahlungsmittelschlüssel auf dem Serversystem in einer elektronischen, zugangsgesicherten Geldbörse des Zahlungspflichtigen gespeichert sein.

Auf dem Serversystem ist mindestens ein

Zahlungsmittelverifizierungsdatensatz mit einem Zahlungswert und mit mindestens einem Verifizierungsschlüssel gespeichert. Jedem gültigen Zahlungsmittelschlüssel ist mindestens ein

Zahlungsmittelverifizierungsdatensatz zugeordnet. Sofern der

Verifizierungsschlüssel des Zahlungsmittelverifizierungsdatensatzes und der Zahlungsmittelschlüssel ein Paar bilden bzw. einander zugeordnet werden können, ist der Zahlungsmittelschlüssel gültig.

Der Zahlungsmittelschlüssel (hier nicht dargestellt) wird in einer vereinfachten Version durch Betätigen der Schaltfläche „Bezahlen" bzw. Anklicken der Schaltfläche „Bezahlen" automatisch von der Datenverarbeitungsanlage des Zahlungspflichtigen auf das Serversystem übermittelt. Alternativ wird durch Betätigen der Schaltfläche „Bezahlen" der Zahlungsmittelschlüssel von der elektronischen Geldbörse an das Serversystem übermittelt.

Anhand des Zahlungsmittelverifizierungsdatensatzes wird die Gültigkeit des Zahlungsmittelschlüssels überprüft.

Im Fall dass das übermittelte und überprüfte Zahlungsmittelschlüssel gültig ist, wird der zugehörige Verifizierungsschlüssel geändert oder gelöscht, ein neuer Verifizierungsschlüssel wird erstellt und ein neuer Zahlungsmittelschlüssel mit dem geänderten Schlüssel wird erstellt. Der neue Zahlungsmittelschlüssel kann dabei entweder vom Serversystem erstellt werden und dann an den Zahlungsempfänger übermittelt werden oder vom Zahlungsempfänger vorgeschlagen werden. In diesen Fall wird der Zahlungsmittelschlüssel von der Datenverarbeitungsanlage des Zahlungsempfängers an das Serversystem übermittelt.

Der neue Zahlungsmittelschlüssel wird danach an den Zahlungsempfänger bzw. das Serversystem übermittelt. Der Zahlungsempfänger speichert sodann an einem weiteren Speicherort, insbesondere auf seiner Datenverarbeitungsanlage, den Zahlungsmittelschlüssel. Auf der Datenverarbeitungsanlage des Zahlungsempfängers wird der Zahlungsmittelschlüssel, insbesondere durch Abbildung eines Geldmittels, dargestellt.

Fig. 5 zeigt, dass der Zahlungspflichtige einen Zahlungsmittelschlüssel mit dem zugeordneten Betrag 100.00 gegeben hat und daher 25.00 als Wechsel erhält. Die Beträge sind dabei auf dem Serversystem gespeichert. Der Wechsel in Höhe von 25.00 wird automatisch vom Serversystem durch Ubermitteln eines gültigen Zahlungsmittelschlüssels in Höhe von 25.00 an den Zahlungspflichtigen gegeben.

Im Folgenden darf auf die Fig. 6 bis 13 Bezug genommen werden, in denen das Verfahren ausführlicher dargestellt ist.

Zu Beginn des Verfahrens erfolgt in einem ersten Schritt nun ein Verbindungsaufbau zwischen einer Datenverarbeitungsanlage eines Zahlungsempfängers und dem Server, und ein Verbindungsaufbau zwischen einer Datenverarbeitungsanlage eines Zahlungspflichtigen und dem Server.

Fig. 6 zeigt ähnlich wie Fig. 1 die beiden Fenster 2, 3 wobei der jeweilige Verbindungsaufbau vom Zahlungspflichtigen mit dem Serversystem und vom Zahlungsempfänger mit dem Serversystem vorgenommen worden ist. Beide Fenster 2, 3 zeigen zunächst den gleichen Inhalt.

Als nächstes erfolgt im Verfahren das Zuordnen des Zahlungsempfängers und des Zahlungspflichtigen. Hierzu wird eine Schaltfläche „Neue Kasse" bereitgestellt. Die Schaltfläche „Neue Kasse" wird durch den Zahlungsempfänger betätigt. Hierdurch wird eine neue Kasse - hier die Kasse 1 - angelegt.

Fig. 7 zeigt, dass dem Zahlungsempfänger in Fenster 2 eine neue Ansicht mit der neuen Kasse 1 angezeigt wird. Dem Zahlungsempfänger wird eine Eingabemaske bereitgestellt, in der der Zahlungsempfänger den gewünschten Geldbetrag eingeben kann. Es ist durch den Text„Geldgeber abwesend" dem Zahlungsempfänger dargestellt, dass der Zahlungspflichtige bzw. „der Geldgeber" der Kasse 1 noch nicht beigetreten ist.

In Fenster 3 wird dem Zahlungspflichtigen eine Auswahl der verfügbaren Kassen angezeigt. Im Beispiel ist die angelegte Kasse 1 verfügbar. Der Zahlungspflichtige kann der ausgewählten Kasse - hier Kasse 1 - beitreten.

Fig. 8 zeigt, dass dem Zahlungspflichtigen im Fenster 3 eine neue Ansicht mit der neuen Kasse Nr. 1 angezeigt wird, nach dem der Zahlungspflichtige der Kasse Nr. 1 beigetreten ist. Dem Zahlungspflichtigen wird in Fenster 3 angezeigt, dass der„Geldnehmer anwesend" ist bzw. der Zahlungsempfänger ebenfalls noch die Kasse angezeigt bekommt. Dem Zahlungspflichtigen wird ferner der geforderte Betrag („Preis"), der bezahlte Betrag („Bezahlt") sowie das Wechselgeld („Zurück") angezeigt, hier jeweils gefolgt von„0.00" da bisher noch kein Betrag gefordert und bezahlt wurde und daher auch noch kein Wechselgeld zu erstatten ist.

Der geforderte Betrag wird nun durch Zahlungsempfänger im Fenster 2 eingegeben.

Fig. 9 zeigt die Fenster 2, 3 nachdem durch den Zahlungsempfänger der geforderte Betrag bzw.„Preis" im Beispiel 75 eingegeben und gesendet worden ist. Dem Zahlungspflichtigen wird der geforderte Betrag gesendet und angezeigt.

Der Zahlungsmittelschlüssel wird nun an das Serversystem von dem Zahlungspflichtigen übermittelt. Der Zahlungsmittelschlüssel ist vzw. in einer Datei gespeichert. Im Fenster 3 kann der Zahlungspflichtige eine Datei mit dem Zahlungsmittelschlüssel auswählen, wie es in Fig. 9 und 10 dargestellt ist.

Die Datei bzw. der Zahlungsmittelschlüssel ist anfangs auf der Datenverarbeitungsanlage des Zahlungspflichtigen gespeichert. In der Datei ist der Zahlungsmittelsschlüssel (nicht dargestellt) gespeichert.

Der Zahlungsmittelschlüssel weist auf der Datenverarbeitungsanlage des Zahlungspflichtigen und/oder auf der Datenverarbeitungsanlage des Zahlungsempfängers eine Bild-, eine Audio- und/oder eine Videoinformation auf und wird als ein Bild, eine Audio- oder eine Videosequenz dargestellt. In Fig. 10 ist eine Bild-Datei 4 mit der Abbildung eines Geldscheins dargestellt. Diese Bild-Datei 4 dient als Zahlungsmittelschlüssel 5.

Die Bild-, die Audio- und/oder die Videoinformation ist in einer Datei in einem Dateiformat mit mindestens einem zusätzlichen Kommentarsegment gespeichert, wobei der oder die Schlüssel in dem oder in den Kommentarsegmenten der Datei hinterlegt sind. Hier ist der Zahlungsmittelschlüssel in einer JPEG-Datei vorhanden, wobei die Bildinformation einen Geldschein, beispielsweise einen 100-Euro-Schein, darstellt. Der Zahlungsmittelschlüssel ist insbesondere in einem Metadatensegment, z.B. in einem Kommentarsegment der JPEG-Datei, hinterlegt.

Auf dem Serversystem ist mindestens ein

Zahlungsmittelverifizierungsdatensatz mit einem Zahlungswert und mit einem Verifizierungsschlüssel gespeichert ist. Jedem gültigen Zahlungsmittelschlüssel ist mindestens ein Zahlungsmittelverifizierungsdatensatz zugeordnet. Sofern die beiden Schlüssel - der Verifizierungsschlüssel des Verifizierungsdatensatzes und der Zahlungsmittelschlüssel - zuordenbar sind, also ein Paar bilden, ist der Zahlungsmittelschlüssel gültig. Anhand des Zahlungsmittelverifizierungsdatensatzes wird die Gültigkeit des Zahlungsmittelschlüssels überprüft. Im Fall dass der übermittelte und überprüfte Zahlungsmittelschlüssel gültig ist, wird der Verifizierungsschlüssel geändert oder gelöscht und ein neuer Verifizierungsschlüssel und ein neuer Zahlungsmittelschlüssel erstellt.

Der neue Zahlungsmittelschlüssel wird danach an den Zahlungsempfänger übermittelt, sofern der Zahlungsempfänger den Zahlungsmittelschlüssel nicht vorgeschlagen hat. Der Zahlungsempfänger speichert an einem Speicherort den neuen Zahlungsmittelschlüssel insbesondere auf seiner

Datenverarbeitungsanlage. Auf der Datenverarbeitungsanlage des Zahlungsempfängers wird der Zahlungsmittelschlüssel insbesondere durch Abbildung eines Geldmittels dargestellt.

Fig. 12 zeigt, dass der Zahlungspflichtige zwei Zahlungsmittelschlüssel 6, 7 in Form von Bild-Dateien als Wechsel erhält. Da der Zahlungspflichtige einen Zahlungsmittelschlüssel 5 mit dem Betrag 100 Euro gegeben hat und der Zahlungsempfänger 75 Euro gefordert hat, haben die zwei Zahlungsmittelschlüssel 6, 7 den Betrag 5 und 20 Euro. Der Wechsel, nämlich die Zahlungsmittelschlüssel 5, 6 in Höhe von 25.00 Euro werden vom Serversystem zum Runterladen bereitgestellt.

Der Zahlungsempfänger erhält in seinem Fenster 2 die Möglichkeit, die Zahlungsmittelschlüssel 8, 9, 10 in Höhe von 20 Euro, 50 Euro und 10 Euro zuladen, wie in Fig. 12 und 13 dargestellt ist.

Im Folgenden werden weitere Beispiele für Zahlungsmittelschlüssel und Ausgestaltungen des Verfahrens erläutert.

Beispiel 1:

Der Zahlungsmittelschlüssel kann in einer einfachen Ausgestaltung eine Datei im Text-Format sein bzw. in einer solchen Datei gespeichert sein. Diese Datei mit der Bezeichnung banknoteOOl.png enthält als Zahlungsmittelschlüssel die Zeichenfolge„01234567890abcdef. Auf einem Serversystem befindet sich eine Datenbank mit einer Tabelle von folgendem Aufbau:

<serialno> <timestamp> <schluessel> 000000000001 2011-01-01 10:23:05 01234567890abcdef

Die Tabelleneinträge bilden die Zahlungsmittelverifikationsdatensätze bzw. hier den Zahlungsmittelverifikationsdatensatz.

Der Zahlungswert ist hier nicht dargestellt, aber trotzdem in dem Verifizierungsdatensatz enthalten.

Der Verifikationsdatensatz auf dem Serversystem bildet eine Repräsentanz des Zahlungsmittelschlüssels. Der Zahlungsmittelschlüssel bildet eine Referenz auf den Verifikationsdatensatz bzw. die Repräsentanz. Der Zusammenhang zwischen Referenz und Repräsentanz ergibt sich aus der Identität der beiden Schlüssel.

Der Zahlungsempfänger kann einen neuen Bezahlvorgang auf dem Serversystem starten. Der Bezahlvorgang wird dem Zahlungspflichtigen und dem Zahlungsempfänger quasi- synchron dargestellt. Diesem Bezahlvorgang ist insbesondere ein Identifikationsmerkmal zugewiesen, beispielsweise eine Vorgangsnummer. Das Starten des Bezahlvorgangs wird dem verbundenen Zahlungspflichtigen angezeigt. Der Zahlungspflichtige kann den Bezahlvorgang auf dem Serversystem auswählen. Insbesondere kann der Zahlungsempfänger dem Zahlungspflichtigen das Identifikationsmerkmal mitteilen, damit der Zahlungspflichtige den gewünschten Bezahlvorgang auswählen kann. Der Bezahlvorgang kann den Beteiligten als das Erstellen und Auswählen einer „Kasse" dargestellt werden. Es bieten sich hierzu jedoch auch andere Bezeichnungen und Darstellungen, wie „Transaktion", „Bezahlvorgang" und dgl. an.

Damit wird die Ausgabe aller Ereignisse, die sich unter der Vorgangs-Nummer auf der Seite der Funktion zutragen, quasi-synchron an den Zahlungspflichtigen und den Zahlungsempfänger ausgeliefert. Die Übertragung von und zu dieser Seite bzw. dem Serversystem erfolgt über ein verschlüsseltes Protokoll und ist damit gegen ein unbefugtes Abhören gesichert. Der Zahlungspflichtige lädt nun die Datei auf das Serversystem hoch. Ihre Bezeichnung wird dort dargestellt, und zwar nahezu zeitgleich für den Zahlungspflichtigen und den Zahlungsempfänger. Die Funktion ersetzt sodann den Verifizierungsschlüssel in der Datei durch einen Anderen einmaligen, der nach dem Zufallszahlenprinzip erzeugt wurde, und bietet dem Zahlungsempfänger die geänderte Datei zum Download an. Die neue Datei beinhaltet nun den neuen Verifizierungsschlüssel„98765432 lOfedcba" und der Datensatz in der Datenbanktabelle lautet jetzt

<serialno> <timestamp> <code>

000000000001 2011-08-01 16:08:44 9876543210fedcba

Vor den Augen des Zahlungspflichtigen und des Zahlungsempfängers verschwindet die Bezeichnung der Datei nun von der Seite. Auf gleiche Weise— nur in umgekehrter Richtung — gibt nun der Zahlungsempfänger „das Wechselgeld" zurück. Der Zahlungsvorgang ist damit abgeschlossen.

Treten während des Zahlungsvorgangs irgendwelche Störungen auf, haben die Beteiligten die Gelegenheit einzugreifen: Moniert beispielsweise der Zahlungsempfänger, der Download des Zahlungsmittelsschlüssels sei missglückt, bietet die Funktion beispielsweise die Möglichkeit, das getauschte Exemplar des Zahlungsmittelschlüssels so lange zu sperren, bis der Sachverhalt aufgeklärt ist.

Beispiel 2:

Die Datei in Beispiel 1 enthält statt der Zeichenfolge einen Link mit einem Query-String, der die Vorgangsnummer und den Zahlungsmittelschlüssel übergibt:

<html>

<body>

<a

href="http://www.server.com/?vorgangsnummer=1234&schl uessel=0123456789" >&euro;l</a>

</body>

</html>

Der Zahlungspflichtige kann so durch bloßes Anklicken des HTML-Links die Funktion aufrufen. Der Zahlungsmittelschlüssel wird dabei automatisch übergeben.

Beispiel 3:

Im Unterschied zu Beispiel 1 handelt es sich bei der Datei um ein Bild im PNG- Format, das eine Banknote darstellt. Es besteht neben seiner Signatur aus verschiedenen Blöcken, darunter aus einem vom Blocktyp „tEXt" mit dem Inhalt„01234567890abcdef.

Der Zahlungsmittelschlüssel ist im Kommentarfeld der Bilddatei enthalten. Die Bilddatei bildet den Zahlungsmittelschlüssel.

Beispiel 4:

Im Gegensatz zu Beispiel 3 liegt das Bild nicht auf dem Rechner des Client, sondern auf dem Server, und wird durch einen HTML- Verweis referenziert:

<html>

<body>

<img src="http://www. server.com/0123456789.png" />

</body>

</html>

Der Zahlungsmittelschlüssel ist dabei Bestandteil der Bezeichnung der Bilddatei.

Beispiel 5:

Der Gast eines Restaurants möchte seine Zeche bezahlen. An seinem Platz ist ein QR-Code auf die Tischplatte gedruckt. Der Gast richtet die Kamera seines Smartphones auf diesen QR-Code und startet eine App, die den Bezahlvoi'gang auf dem Serversystem des Emittenten kontaktiert. Das Serversystem wiederum informiert das internetfähige Kassensystem des Restaurants, dass der Gast seine Rechnung bezahlen wird. Der Zahlungspflichtige gelangt direkt zu dem Fenster, wie es in Fig. 4 oder in Fig. 9 dargestellt ist. Der weitere Zahlungsvorgang kann danach insbesondere nun ohne zusätzliches Zutun von Gast oder Kellner durch die App und das Kassensystem selbstständig abgewickelt werden.

Beispiel 6:

Ein Kreditinstitut emittiert einen elektronischen Zahlungsmittelschlüssel in Form von mp4-Dateien mit einem Wert von Euro 1,00 je Stück, wobei die mp4- Dateien einen Ausschnitt aus einem Musikclip enthalten, der beispielsweise gerade in die Hit-Charts aufgestiegen ist. Der Interpret bietet auf seiner Webseite den vollständigen Musikclip für Euro 1,00 zum Download an. Der Inhaber kann seinen elektronischen Zahlungsmittelschlüssel für jeden beliebigen Zahlungszweck verwenden, unter anderem aber auch zum Erwerb des Musikclips.

Bezugszeichenliste

1 Bildschirmansicht

2 Fenster

3 Fenster

4 Bild

5 Zahlungsmittelschlüssel

6 Zahlungsmittelschlüssel

7 Zahlungsmittelschlüssel

8 Zahlungsmittelschlüssel

9 Zahlungsmittelschlüssel

10 Zahlungsmittelschlüssel