-
Hintergrund
-
Die vorliegende Offenbarung betrifft ein Kassen-implementiertes Verfahren, ein Computerprogrammprodukt zur Verwendung in Verbindung mit einer Kasse und eine Kasse. Die vorliegende Offenbarung betrifft insbesondere eine Technik zum Vornehmen einer Finanztransaktion an einer Kasse.
-
Die Popularität und Funktionalität von tragbaren, elektronischen Geräten hat zu einer erhöhten Anzahl von Anwendungen dieser Geräte geführt. Beispielsweise untersuchen Entwickler die Verwendung von Mobiltelefonen zum Durchführen von Finanztransaktionen an Kassen, wie beispielsweise Registrierkassen.
-
Einige Vorschläge für diese Finanztransaktionen (welche gelegentlich als „mobile Zahlung“ bezeichnet werden) beinhalten ein Verwenden eines Mobiltelefons, um einer Kasse eine Finanzinformation (z. B. eine Finanzinformation, welche üblicherweise in einem Barcode oder einem Magnetstreifen einer Debitkarte oder einer Kreditkarte enthalten ist) über ein bestehendes Peripheriegerät direkt bereitzustellen, wobei das Peripheriegerät (z. B. ein Barcode Scanner oder ein Magnetstreifen-Lesegerät) mit der Kasse gekoppelt ist. Diese Vorschläge können die Interaktion mit dem Kunden während der mobilen Zahlung jedoch signifikant einschränken, was die Einführung der mobilen Zahlung behindern kann.
-
Gemäß anderen Vorschlägen wird die mobile Zahlung alternativ implementiert, indem bestehende Kassen-Hardware und/oder -Software verändert wird. Diese Änderungen werden jedoch die Kosten und die Komplexität der Implementierung der mobilen Zahlung signifikant erhöhen, wodurch die Einführung der mobilen Zahlung ebenfalls eingeschränkt werden könnte.
-
Das Dokument
US 2010 / 0 161 433 A1 offenbart Systeme und Verfahren zum Handhaben von Point-of-Sale-Transaktionen unter Verwendung eines Mobilgeräts. In einer Ausführungsform kann ein Verfahren zum Bereitstellen einer Zahlung über ein Mobilgerät bei einer Transaktion für eine Ware oder Dienstleistung das Empfangen einer Auswahl eines Transaktionskontos auf dem Mobilgerät umfassen, von dem die Zahlung bei einer Transaktion für eine Ware oder Dienstleistung finanziert werden soll. Das Verfahren kann ferner das Generieren und Senden einer Benachrichtigung an ein Netzwerkverarbeitungssystem (NPS) beinhalten. Die Benachrichtigung kann das ausgewählte Transaktionskonto identifizieren. Das NPS kann so konfiguriert werden, dass es das ausgewählte Transaktionskonto für eine oder mehrere zukünftige Transaktionen mit einem NPS-Konto verknüpft. Das Verfahren kann ferner das Senden einer Kundenkennung an ein Point-of-Sale(POS)-System über ein Nahbereichskommunikationsmedium umfassen, um die Transaktion abzuschließen. In einer anderen Ausführungsform werden Verfahren zur Zahlungsabwicklung in einem mobilen E-Commerce-Netzwerk bereitgestellt.
-
Das Dokument
WO 2010 / 080 705 A1 offenbart Verfahren zum Verarbeiten von Quittungen, umfassend: Erhalten von Transaktionsdaten, einschließlich einer Vielzahl von Informationskategorien, die notwendig sind, um eine Kauftransaktion eines Kunden an einem Ladenstandort zu beschreiben; Erhalten von Bilddaten, die eine Quittung darstellen, die der Kauftransaktion des Kunden am Geschäftsstandort entspricht; Erhalt einer E-Mail-Adresse des Kunden; Bereitstellen einer Option zum Ausdrucken der Quittung im Geschäft und einer Option zum Versenden der Quittung per E-Mail an den Kunden; Erhalten einer Auswahl von mindestens einer der bereitgestellten Optionen; wenn die Option zum Drucken ausgewählt ist, Initiieren des Druckens des Bildes am Speicherort; und wenn die Option zum Versenden per E-Mail ausgewählt ist, Senden einer E-Mail an die E-Mail-Adresse des Kunden, wobei die E-Mail das Bereitstellen mindestens einer der Bilddaten und der Transaktionsdaten umfasst.
-
Das Dokument
WO 2009 / 070 114 A1 offenbart, dass elektronische Schecks für Nahbereich-Zahlungen von einem oder mehreren Scheckausstellern ausgestellt werden. Die elektronischen Schecks können mit gewöhnlichen Mobiltelefonen verwendet werden, ohne dass eine benutzerdefinierte Software installiert werden muss. Ein elektronischer Scheck wird von einem Scheckaussteller generiert, wenn ein Kunde mit seinem Mobiltelefon eine bestimmte Webseite besucht. Eine mit dem elektronischen Scheck verknüpfte Scheckreferenz wird in Form eines Barcodes auf dem Mobiltelefon angezeigt. Der Strichcode wird von einem Händler unter Verwendung eines Strichcodelesers gescannt. Der Händler sendet die aus dem Strichcode gewonnenen Informationen an den Scheckaussteller, um eine Zahlung vom Kunden an den Händler zu ermöglichen. Die Prüfreferenz enthält Verifizierungsdaten, um Fälschungen zu vermeiden. Der elektronische Check kann nur einmal verwendet werden. Außerdem kann er nur für einen begrenzten Zahlungsbetrag und nur innerhalb eines kurzen Zeitraums nach seiner Erstellung verwendet werden.
-
Das Dokument
WO 03 / 023 674 A1 offenbart ein System und Verfahren zur Kreditkartenzahlung unter Verwendung von Barcodes und Mobilgeräten. Dieses Dokument offenbart ein Kreditkartenzahlungssystem und -verfahren, das Folgendes umfasst: Anzeigen eines Strichcodes, der Kreditkartenzahlungsinformationen enthält, auf dem Anzeigeteil des Mobiltelefongeräts des Benutzers; Lesen eines solchen Strichcodes mit einem Strichcode-Lesegerät; und Erfassen der Kreditkartenzahlungsinformationen und der Zahlungsbestätigung.
-
Dokument
US 2012 / 0 018 511 A1 offenbart Vorrichtungen, Verfahren und Systeme, die sich auf die Verifizierung von tragbaren Verbrauchergeräten beziehen. Beispielsweise wird ein Verifizierungstoken über eine USB-Verbindung mit einem Computer gekoppelt, um die Netzwerkeinrichtungen des Computers zu verwenden. Das Verifizierungstoken liest dann Identifikationsinformationen von einem tragbaren Verbrauchergerät eines Benutzers, wie einer Kreditkarte. Diese Informationen werden über ein Kommunikationsnetzwerk unter Verwendung der Netzwerkeinrichtungen des Computers an einen Validierungseintrag gesendet. Die Validierungseinheit wendet einen oder mehrere Validierungstests auf die Informationen an, die sie von dem Verifizierungstoken erhält. Dokument
US 2012 / 0 018 511 A1 lehrt weiter, dass wenn eine ausgewählte Anzahl von Tests bestanden wird, die Validierungseinheit einen Geräteverifizierungswert an das Verifizierungstoken sendet.
-
Die Erfindung ist in dem Hauptanspruch und den nebengeordneten Ansprüchen (den unabhängigen Ansprüchen) definiert. Optionale Ausführungsformen der Erfindung sind in den Unteransprüchen beschrieben.
-
Zusammenfassung
-
Die offenbarten Ausführungsformen betreffen eine Kasse („point-of-sale terminal“), welche eine Finanztransaktion vornimmt. Während des Betriebs empfängt die Kasse über ein mit der Kasse gekoppeltes Peripheriegerät einen mit einem Kunden assoziierten Token wobei der Token mittels Nahfeld-Kommunikation empfangen wird. Dieser Token identifiziert den Kunden und das Peripheriegerät ist von einem Kredit-Autorisierungs-Gerät („credit-authorization terminal“) und einem Magnetstreifen-Lesegerät verschieden. Dann führt ein einheitliches Kassen-Dienstobjekt („unified point-of-sale service object“), welches auf der Kasse ausgeführt wird, einen oder mehrere, auf wenigstens dem Token basierende Schritte durch, um mit dem Kunden assoziierte Finanzinformation zu erhalten, wobei das einheitliche Kassen-Dienstobjekt ein Treiber für ein virtuelles Peripheriegerät ist. Darüber hinaus stellt die Kasse die Finanzinformation und eine mit der Finanztransaktion assoziierte Transaktionsinformation einem in der Finanzinformation spezifizierten Finanzinstitut bereit. Als Nächstes empfängt die Kasse von dem Finanzinstitut eine Bestätigung, dass die Finanztransaktion abgeschlossen ist.
-
Der eine oder die mehreren Schritte können umfassen: Bereitstellen des Tokens an einen Dritten, welcher von dem Finanzinstitut verschieden ist; und Empfangen der Finanzinformation von dem Dritten. Beispielsweise kann der Token dem Dritten über ein tragbares, elektronisches Gerät des Kunden bereitgestellt werden. Alternativ oder zudem kann der Token dem Dritten über ein mit der Kasse gekoppeltes Netzwerk bereitgestellt werden.
-
Erfindungsgemäß empfängt die Kasse vor dem Empfangen des Tokens Informationen, welche eine sichere Sitzung mit dem tragbaren, elektronischen Gerät des Kunden initiieren. Diese Information kann mittels drahtloser Kommunikation, Nahfeld-Kommunikation, einem Audio-Kanal und/oder einem Video-Kanal übertragen werden. Erfindungsgemäß wird jedoch die Information, welche eine sichere Sitzung mit dem tragbaren, elektronischen Gerät des Kunden initiiert, mittels mindestens einem aus einem Audio-Kanal und einem Video-Kanal übertragen.
-
Gemäß einiger Ausführungsformen stellt die Kasse vor dem Empfangen des Tokens ferner eine mit der Finanztransaktion assoziierte Transaktionsaufforderung von einer auf der Kasse ausgeführten Kassen-Software an das einheitliche Kassen-Dienstobjekt bereit.
-
Ferner kann das Bereitstellen der Finanzinformation und der mit der Finanztransaktion assoziierten Transaktionsinformation sowie das Empfangen der Bestätigung über ein Kredit-Autorisierung-Gerät-Dienstobjekt, welches ein Treiber für das Kredit-Autorisierungs-Gerät ist, erfolgen. Dieses Kredit-Autorisierungs-Gerät-Dienstobjekt kann mit einem einheitlichen Standard für Kassen kompatibel sein.
-
Weitere Ausführungsformen stellen ein Verfahren bereit, welches wenigstens einige der von der Kasse durchgeführten Schritte umfasst.
-
Weitere Ausführungsformen umfassen ein Computerprogrammprodukt zur Verwendung mit der Kasse. Dieses Computerprogrammprodukt umfasst Anweisungen für wenigstens einige der von der Kasse durchgeführten Schritte.
-
Figurenliste
-
- 1 ist ein Ablaufdiagramm, welches ein Verfahren zum Vornehmen einer Finanztransaktion gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt.
- 2 ist eine Zeichnung, welche das Verfahren der 1 gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt.
- 3 ist ein Blockdiagramm, welches ein System darstellt, welches das Verfahren der 1 und 2 gemäß einer Ausführungsform der vorliegenden Offenbarung durchführt.
- 4 ist ein Blockdiagramm, welches eine Kasse darstellt, welche das Verfahren der 1 und 2 gemäß einer Ausführungsform der vorliegenden Offenbarung durchführt.
- 5 ist ein Blockdiagramm, welches eine Datenstruktur zur Verwendung in der Kasse der 4 gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt.
-
Anzumerken ist, dass gleiche Bezugszeichen einander entsprechende Teile der Figuren bezeichnen. Darüber hinaus sind mehrere Instanzen des selben Teils durch ein gemeinsames Präfix gekennzeichnet, welcher von einer Instanznummer durch einen Bindestrich getrennt ist.
-
Detaillierte Beschreibung
-
Nachfolgend werden Ausführungsformen einer Kasse, einer Technik zum Vornehmen einer Finanztransaktion und ein Computerprogrammprodukt (z.B. Software) zur Verwendung mit der Kasse beschrieben. Während der Finanztransaktion stellt ein Kunde einen den Kunden identifizierenden Token an ein Peripheriegerät (welches von einem Kredit-Autorisierungs-Gerät und einem Magnetstreifen-Lesegerät verschieden ist) bereit, welches mit der Kasse gekoppelt ist. Beispielsweise kann der Kunde den Token mittels eines tragbaren, elektronischen Geräts, z.B. einem Mobiltelefon, bereitstellen. Anschließend führt ein auf der Kasse ausgeführtes, einheitliches Kassen-Dienstobjekt, welches ein Treiber für ein virtuelles Peripheriegerät ist, einen oder mehrere, auf wenigstens dem Token basierende Schritte durch, um mit dem Kunden assoziierte Finanzinformation zu erhalten. Nach dem Bereitstellen der Finanzinformation und einer mit der Finanztransaktion assoziierten Transaktionsinformation an ein in der Finanzinformation spezifiziertes Finanzinstitut empfängt die Kasse von dem Finanzinstitut eine Bestätigung, dass die Finanztransaktion abgeschlossen ist. Beispielsweise kann die Bestätigung über ein Kredit-Autorisierungs-Gerät-Dienstobjekt, welches ein Treiber für das Kredit-Autorisierungs-Gerät ist, empfangen werden.
-
Indem dem Kunden ermöglicht wird, die Finanztransaktion in einer mit einem einheitlichen Standard für Kassen kompatiblen Weise, jedoch ohne Verwenden eines Kredit-Autorisierungs-Geräts oder eines Magnetstreifen-Lesegeräts, vorzunehmen, kann diese Finanztechnik Handelstätigkeiten vereinfachen. Insbesondere kann die Finanztechnik die mobile Zahlung über ein tragbares, elektronisches Gerät (z.B. ein Mobiltelefon) vereinfachen, ohne dass Veränderungen an Kassen-Hardware oder -Software (z.B. in einer Weise, welche mit bestehender Kassen-Hardware und -Software kompatibel ist) vorgenommen werden müssen und ohne die Interaktion mit dem Kunden während der mobilen Zahlung zu beschränken. Auf diese Weise stellt die Finanztechnik eine Software-Lösung bereit, welche mit wenigen oder keinen Ausgaben oder Unannehmlichkeiten für Händler oder Kunden auf breiter Basis eingeführt werden kann.
-
In der nachfolgenden Beschreibung kann ein Nutzer oder ein Kunde umfassen: ein Individuum (z.B. ein bestehender Kunde, ein neuer Kunde, ein Dienstleister, ein Lieferant, ein Vertragspartner, etc.), eine Organisation, ein Betrieb und/oder eine Behörde. Ferner ist unter dem Begriff „Betrieb“ zu verstehen: gewinnorientierte Gesellschaften, gemeinnützige Gesellschaften, Organisationen, Gruppen von Individuen, Einzelunternehmen, Behörden, Partnerschaften, etc.
-
Nun werden Ausführungsformen der Finanztechnik beschrieben, welche von einer Kasse (z.B. der Kasse 400 in 4) ausgeführt werden können. 1 ist ein Ablaufdiagramm, welches ein Verfahren 100 zum Vornehmen einer Finanztransaktion darstellt. Während des Betriebs empfängt die Kasse (z.B. eine Registrierkasse) einen mit einem Kunden assoziierten Token über ein mit der Kasse gekoppeltes Peripheriegerät (Schritt 114). Dieser Token identifiziert den Kunden und das Peripheriegerät ist von einem Kredit-Autorisierungs-Gerät und einem Magnetstreifen-Lesegerät verschieden.
-
Anschließend führt ein auf der Kasse ausgeführtes, einheitliches Kassen-Dienstobjekt einen oder mehrere, auf wenigstens dem Token basierende Schritte durch, um mit dem Kunden assoziierte Finanzinformation zu erhalten (Schritt 116), wobei das einheitliche Kassen-Dienstobjekt ein Treiber für ein virtuelles Peripheriegerät ist. (Das einheitliche Kassen-Dienstobjekt wird gelegentlich als „virtuelles Peripheriegerät für mobile Zahlung“ bezeichnet.) Wie nachfolgend mit Bezug auf 2 beschrieben, können der eine oder die mehreren Schritte umfassen: Bereitstellen des Tokens an einen Dritten, welcher von dem Finanzinstitut verschieden ist; und Empfangen der Finanzinformation von dem Dritten. Beispielsweise kann der Token dem Dritten über ein tragbares, elektronisches Gerät des Kunden bereitgestellt werden. Alternativ oder zudem kann der Token dem Dritten über ein mit der Kasse gekoppeltes Netzwerk bereitgestellt werden.
-
Darüber hinaus stellt die Kasse die Finanzinformation und mit der Finanztransaktion assoziierte Transaktionsinformation einem in der Finanzinformation spezifizierten Finanzinstitut bereit (Schritt 118). Anschließend empfängt die Kasse von dem Finanzinstitut eine Bestätigung, dass die Finanztransaktion abgeschlossen ist (Schritt 120). Beispielsweise können das Bereitstellen der Finanzinformation und der mit der Finanztransaktion assoziierten Transaktionsinformation (Schritt 118) sowie das Empfangen der Bestätigung (Schritt 120) über ein Kredit-Autorisierungs-Gerät-Dienstobjekt erfolgen, welches ein Treiber für das Kredit-Autorisierungs-Gerät ist. Dieses Kredit-Autorisierungs-Gerät-Dienstobjekt wie auch das virtuelle Peripheriegerät für mobile Zahlung können mit einem einheitlichen Standard für Kassen, wie beispielsweise dem „UnifiedPOS“ oder UPOS Standard (der National Retail Federation of Washington, D.C.), kompatibel sein.
-
Gemäß einiger Ausführungsformen empfängt die Kasse vor dem Empfangen des Tokens (Schritt 114) optional eine Information, welche eine sichere Sitzung mit dem tragbaren, elektronischen Gerät des Kunden bei Beginn der Finanztransaktion initiiert (Schritt 110). Diese Information kann mittels drahtloser Kommunikation, Nahfeld-Kommunikation, einem Audio-Kanal und/oder einem Video-Kanal übertragen werden.
-
Gemäß einiger Ausführungsformen stellt die Kasse vor dem Empfangen des Tokens (Schritt 114) ferner optional eine mit der Finanztransaktion assoziierte Transaktionsaufforderung von einer auf der Kasse ausgeführten Kassen-Software an das einheitliche Kassen-Dienstobjekt bereit (Schritt 112). In Erwiderung auf diese Transaktionsaufforderung kann das einheitliche Kassen-Dienstobjekt den Token von dem Peripheriegerät erwarten.
-
Gemäß einer beispielhaften Ausführungsform ist die Finanztechnik unter Verwendung des tragbaren, elektronischen Geräts, der Kasse und wenigstens einem Server implementiert, welche miteinander über ein Netzwerk, beispielsweise einem Mobiltelefonnetzwerk und/oder dem Internet (z.B. mittels einer Client-Server Architektur) kommunizieren. Dies ist in 2 dargestellt, welche ein Ablaufdiagramm ist, welches das Verfahren 100 (1) darstellt. Während dieses Verfahrens stellt ein Nutzer eines tragbaren, elektronischen Geräts 210 den den Nutzer identifizierenden Token bereit (Schritt 216). Beispielsweise kann der Nutzer ein Kunde sein und ein tragbares, elektronisches Gerät 210 kann ein Mobiltelefon sein. Gemäß dieser Ausführungsformen kann der Token mittels drahtloser Kommunikation, Nahfeld-Kommunikation, einem Audio-Kanal und/oder einem Video-Kanal übertragen werden. Alternativ kann der Nutzer den Token in eine Nummerntastatur eingeben oder das tragbare, elektronische Gerät 210 kann ein Bild eines Barcodes, welcher ein dem Token entsprechendes, räumliches Muster umfasst, anzeigen oder bereitstellen.
-
Nach dem Empfangen des Tokens (Schritt 118) über das Peripheriegerät (beispielsweise einem Empfänger für drahtlose Kommunikation, einem Barcodescanner oder der Nummerntastatur) führt das auf der Kasse ausgeführte, einheitliche Kassen-Dienstobjekt den einen oder die mehreren, auf wenigstens dem Token basierenden Schritte durch (Schritt 120), um mit dem Kunden assoziierte Finanzinformation zu erhalten. (Wie nachfolgend mit Bezug auf 3 beschrieben, kann das einheitliche Kassen-Dienstobjekt der Treiber für das virtuelle Peripheriegerät sein.) Beispielsweise kann der Token einem mit dem Dritten (welcher von dem Finanzinstitut verschieden sein kann, welches die Zahlung für den Kunden in der Finanztransaktion vornimmt), beispielsweise einem Anbieter der Finanztechnik, assoziierten Server 214 bereitgestellt werden. Insbesondere kann eine Kasse 212 den Token dem Server 214 über ein Netzwerk bereitstellen (Schritt 222). Alternativ kann der Token dem Server 214 optional über ein tragbares, elektronisches Gerät 210 bereitgestellt werden (Schritte 222, 224 und 226).
-
Darüber hinaus kann der Server 214 nach dem Empfangen des Tokens (Schritt 228) auf die Finanzinformation zugreifen und diese der Kasse 212 bereitstellen (Schritt 230). Beispielsweise kann die Finanzinformation Information zur mobilen Zahlung für den Kunden umfassen, beispielsweise eine Konto-Identifikation, einen verfügbaren Betrag, welcher ausgegeben werden kann, ein Finanzinstitut (z.B. eine Bank), etc.
-
Ferner stellt die Kasse 212 nach dem Empfangen der Finanzinformation (Schritt 232) die Finanzinformation und die mit der Finanztransaktion assoziierte Transaktionsinformation dem in der Finanzinformation spezifizierten Finanzinstitut bereit (Schritt 234). Die Transaktionsinformation kann beispielsweise umfassen: einen Transaktionstag, eine Transaktionszeit, eine Händler-Identifikation, eine Produktkennung und einen Transaktionsbetrag.
-
Die Finanzinformation und die Transaktionsinformation können von einem Server empfangen werden, welcher mit dem Finanzinstitut assoziiert ist (nicht gezeigt), welches anschließend die Finanztransaktion abschließt (z.B. indem eine Zahlung im Auftrag des Kunden an den mit der Kasse 212 assoziierten Händler vorgenommen wird). Nachdem die Finanztransaktion abgeschlossen ist (nicht gezeigt), kann dieser Server die Bestätigung, dass die Finanztransaktion abgeschlossen ist, bereitstellen (nicht gezeigt). Alternativ können die Finanzinformation und die Transaktionsinformation von dem Server 214 empfangen werden (nicht gezeigt), welcher anschließend die Finanztransaktion abschließt (nicht gezeigt) und die Bestätigung bereitstellt (nicht gezeigt).
-
Anschließend empfängt die Kasse 212 die Bestätigung (Schritt 236). Beispielsweise kann die Bestätigung über einen Kredit-Autorisierungs-Gerät-Dienstobjekt, welches ein Treiber für das mit der Kasse 212 gekoppelte Kredit-Autorisierungs-Gerät ist, empfangen werden.
-
Gemäß einiger Ausführungsformen des Verfahrens 100 (1 und 2) können weitere oder weniger Schritte vorhanden sein. Darüber hinaus kann die Reihenfolge der Schritte geändert werden und/der zwei oder mehr Schritte können in einen einzigen Schritt kombiniert werden.
-
Gemäß einer beispielhaften Ausführungsform verwendet die Finanztechnik den UPOS Standard, um mobile Zahlungen in eine Kassen-Software zu integrieren. Die meisten, kommerziell verfügbaren Kassen-Softwares (beispielsweise Kassen-Betriebssysteme) unterstützen den UPOS Standard, welcher die Integration von Peripheriegeräten, beispielsweise einem Kredit-Autorisierungs-Gerät, einem Magnetstreifen-Lesegerät, etc., abdeckt. Die UPOS Architektur basiert auf dem Konzept von Steuerobjekten und Dienstobjekten. Während des Betriebs einer Kasse interagiert die Kassen-Software mit einem oder mehreren Steuerobjekten für Aufgaben, wie beispielsweise Kreditzahlungs-Autorisierung. Ein Steuerobjekt verbindet sich mit dem geeigneten Dienstobjekt, welches die Rolle eines Treibers für ein externes Gerät oder ein Peripheriegerät übernimmt, welches die Aufgabe(n) durchführt und das Ergebnis zurückgibt. Im Beispiel der Kreditzahlungs-Autorisierung ist das Kredit-Autorisierungs-Gerät-Dienstobjekt der Treiber für das Kredit-Autorisierungs-Gerät.
-
In der Finanztechnik werden die mobilen Zahlungen mit der Kassen-Software integriert, indem ein Dienstobjekt verwendet wird, welches ein virtuelles Peripheriegerät treibt. Statt ein Dienstobjekt zum Treiben eines tatsächlichen Peripheriegeräts zu verwenden, wird aus einem Dienstobjekt ein virtuelles Peripheriegerät, welches die zur Erfüllung einer Aufgabe (in diesem Fall die Finanztransaktion) erforderliche Logik implementiert. Diese Logik kann ein direktes Interagieren mit dem tragbaren, elektronischen Gerät des Nutzers und/oder mit einem mit dem Dritten assoziierten Server umfassen, welche die Finanztechnik (d.h. das Bereitstellen der Finanzinformation in Erwiderung auf das Empfangen des Tokens von der Kasse) vereinfachen oder bereitstellen. Auf diese Weise kann die übliche Kassen-Peripheriegerät-Integrationsschnittstelle verwendet werden, um eine Lösung zu ermöglichen, welche lediglich aus einer Software besteht, welche die mobilen Zahlungen vereinfacht und mit einer Mehrzahl von bestehender Kassen-Software und -Hardware funktioniert.
-
Gemäß einer beispielhaften Ausführungsform möchte ein Kunde ein Produkt oder eine Dienstleistung von einem Händler kaufen. Ein Kassierer an einer Kasse kann die gekauften Gegenstände einlesen. Ferner kann der Kassierer optional eine Barcodescanner-Operation anwenden, so wie dies üblicherweise bei einer Kundenkarte getan wird. Daraufhin kann die Kassen-Software eine Transaktionsaufforderung an einen virtuellen Barcodescanner (z.B. das einheitliche Kassen-Dienstobjekt) absenden, welcher von einem Anbieter der Finanztechnik bereitgestellt wird. In Erwiderung auf diese Transaktionsaufforderung kann der virtuelle Barcodescanner den Token von dem Peripheriegerät (wie beispielsweise einem Barcodescanner) erwarten.
-
Anschließend kann der Kunde optional einen Schritt zum Erzeugen einer Sitzung (d.h. einen Schritt, welcher eine Sitzung initiiert) durchführen. Beispielsweise kann die Sitzungserzeugung umfassen: eine Nahfeld-Kommunikation oder eine Audio- oder Videosignal-Übertragung oder -Empfang, welche eine Nahverbindung mit dem einheitlichen Kassen-Dienstobjekt an der Kasse initiiert. Diese Kommunikation zwischen dem tragbaren, elektronischen Gerät und der Kasse kann BlueTooth® (von der BlueTooth Special Interest Group of Kirkland, Washington) und/oder WiFi™ (von der WiFi Alliance of Austin, Texas) verwenden.
-
Anschließend stellt eine auf dem tragbaren, elektronischen Gerät ausgeführte Anwendung zur mobilen Zahlung (welche ebenfalls von dem Anbieter der Finanztechnik bereitgestellt sein kann) einen Token (beispielsweise eine numerische Identifikation) für das Barcodescanner-Dienstobjekt auf der Kasse bereit. Dieser Token identifiziert den Nutzer gegenüber dem Händler und/oder dem Anbieter der Finanztechnik (welche allen auf der Kasse ausgeführten Dienstobjekten über eine sichere Datenverbindung zugänglich sind). Nach dem Empfangen der Finanzinformation von dem Händler und/oder dem Anbieter gibt das Barcodescanner-Dienstobjekt die mit dem Nutzer assoziierte Finanzinformation an die Kassen-Software zurück.
-
Gemäß einiger Ausführungsformen führt der Kassierer optional weitere Schritte zum Vergeben von Treuepunkten, zum Entgegennehmen von Gutscheinen und Angeboten, etc., durch.
-
Ferner kann der Kassierer nach dem Empfangen der Finanzinformation einen Kredit-Autorisierungs-Schritt für den offenen Betrag mittels des Kredit-Autorisierungs-Gerät-Dienstobjekts durchführen. Daraufhin stellt die Kassen-Software eine entsprechende Aufforderung an das Kredit-Autorisierungs-Gerät-Dienstobjekt.
-
Zudem interagiert das Kredit-Autorisierungs-Gerät-Dienstobjekt mit der Anwendung zur mobilen Zahlung auf dem tragbaren, elektronischen Gerät des Nutzers und/oder mit einem Server 214 (2), um eine Zahlungs-Autorisierung sowohl von dem Verbraucher als auch dem Zahlungsdurchführenden (z.B. dem Finanzinstitut) zu erhalten. Diese Autorisierung wird an die Kassen-Software zurückgegeben. Gemäß einiger Ausführungsformen druckt die Kassen-Software optional einen Beleg mittels einem UPOS Drucker-Dienstobjekt, welches Beleg-Information an die Anwendung zur mobilen Zahlung und/oder dem Server 214 (2) zurückgibt.
-
Durch Verwenden eines austauschbaren, einheitlichen Kassen-Dienstobjekt, wie z.B. dem virtuellen Barcodescanner (im Gegensatz zu dem Kredit-Autorisierungs-Gerät oder dem Magnetstreifen-Lesegerät, und im Allgemeinen, Hardware, welche eine Kreditkarte oder eine Debitkarte ausließt und eine Autorisierung empfängt), welcher sich mit dem Server 214 (2) verbinden kann, welcher mit dem Anbieter der Finanztechnik assoziiert ist, kann die Finanztechnik mobile Zahlungen vereinfachen.
-
Eine Vielzahl von Kommunikationstechniken kann dazu verwendet werden, eine Verbindung zwischen der Anwendung zur mobilen Zahlung und dem einheitlichen Kassen-Dienstobjekt bereitzustellen: Nah-Kommunikation (z.B. BlueTooth® und/oder WiFi™), Audio-Kommunikation, Video-Kommunikation, Nahfeld-Kommunikation und/oder drahtlose (lokale) Netzwerke (z.B. in Ausführungsformen, in denen das tragbare, elektronische Geräte und die Kasse Zugriff auf ein drahtloses (lokales) Netzwerk oder Internetprotokolle haben).
-
Nun werden Ausführungsformen des Systems und der Kasse sowie deren Verwendung beschrieben. 3 ist ein Blockdiagramm, welches ein System 300 darstellt, welches das Verfahren 100 (1 und 2) durchführt. In diesem System kann ein Nutzer eines tragbaren, elektronischen Geräts 210 ein Softwareprodukt (z.B. die Anwendung zur mobilen Zahlung), wie beispielsweise eine Software-Anwendung, welche sich auf dem tragbaren, elektronischen Gerät 210 befindet und darauf ausführbar ist, verwenden. (Alternativ kann der Nutzer mit einer Internetseite interagieren, welche von einem Server 214 über ein Netzwerk 312 bereitgestellt wird und welche von einem Browser auf dem tragbaren, elektronischen Gerät 210 dargestellt wird. Beispielsweise kann wenigstens ein Teil der Software-Anwendung ein Anwendungs-Werkzeug sein, welches in der Internetseite eingebettet ist und in einer virtuellen Umgebung des Browsers ausgeführt wird. Daher kann das Anwendungs-Werkzeug dem Nutzer über eine Client-Server Architektur bereitgestellt werden.) Diese Software-Anwendung kann eine alleinstehende Anwendung oder ein Teil einer anderen Anwendung sein, welche sich auf dem tragbaren, elektronischen Gerät 210 befindet und darauf ausführbar ist (z.B. eine Software-Anwendung, welche von dem Server 214 bereitgestellt wird oder welche auf dem tragbaren, elektronischen Gerät 210 installiert und darauf ausführbar ist).
-
Wie zuvor beschrieben, kann während einer Finanztransaktion (z.B. Kaufen eines Produkts von einem Händler) der Nutzer (welcher in der vorangegangenen Beschreibung der Kunde ist) die Software-Anwendung dazu verwenden, einen Token (welcher den Nutzer identifiziert) von einem tragbaren, elektronischen Gerät 210 über ein Netzwerk 312 an eine Kasse 212 bereitzustellen. Wie in 3 gezeigt, kann eine Kassen-Software 310 Steuerobjekte 314 (z.B. ein Kredit-Autorisierungs-Gerät-Steuerobjekt, ein Magnetstreifen-Lesegerät-Steuerobjekt, ein elektronisches-Geldtransfer-Steuerobjekt, etc.) umfassen, welche mittels einer Peripheriegerät-Schnittstelle des UPOS Standards mit Treibern oder Dienstobjekten 316 (z.B. Kredit-Autorisierungs-Dienstobjekt, einem Magnetstreifen-Lesegerät-Dienstobjekt, einem elektronischen-Geldtransfer-Dienstobjekt, etc.) für Peripheriegeräte 318 (z.B. ein Kredit-Autorisierungs-Gerät, ein Magnetstreifen-Lesegerät, etc.) interagieren können. Der Token kann durch ein UPOS Dienstobjekt, z.B. ein Dienstobjekt zur mobilen Zahlung 320 (z.B. dem virtuellen Barcodescanner), welches ein Treiber für ein virtuelles Peripheriegerät ist, empfangen werden.
-
Nach dem Empfangen des Tokens führt das Dienstobjekt zur mobilen Zahlung 320 einen oder mehrere, auf wenigstens dem Token basierende Schritte durch, um mit dem Nutzer assoziierte Finanzinformation zu erhalten. Z.B. kann das Dienstobjekt zur mobilen Zahlung 320 den Token einem Server 214 über ein Netzwerk 312 entweder direkt oder über ein tragbares, elektronisches Gerät 210 bereitstellen, und der Server 214 kann die durch den Token spezifizierten Kunden dazu verwenden, auf die Finanzinformation zu zugreifen und diese an das Dienstobjekt zur mobilen Zahlung 320, und damit der Kasse 212, zurückzugeben.
-
Anschließend kann die Kasse 212 die Finanzinformation und die mit der Finanztransaktion assoziierte Transaktionsinformation an ein in der Finanzinformation spezifiziertes Finanzinstitut bereitstellen. Z.B. kann das Kredit-Autorisierungs-Gerät-Steuerobjekt die Finanzinformation und die Transaktionsinformation dem Kredit-Autorisierungs-Gerät-Dienstobjekt bereitstellen, welches wiederum das Kredit-Autorisierungs-Gerät treibt, welches die Finanzinformation und die Transaktionsinformation über das Netzwerk 312 an den Server 214 oder einen Server 322 (welcher mit dem Finanzinstitut assoziiert ist) bereitstellt. Daher können die Finanzinformation und die Transaktionsinformation direkt an das Finanzinstitut, welches die Finanztransaktion abschließt, bereitgestellt werden oder sie können zuerst dem Anbieter der Finanztechnik (über den Server 214) bereitgestellt werden, welcher mit dem Server 322 über das Netzwerk 312 interagiert, um die Finanztransaktion abzuschließen.
-
Als Nächstes empfängt die Kasse 212 eine Bestätigung von dem Finanzinstitut, dass die Finanztransaktion abgeschlossen ist. Diese Bestätigung kann direkt von dem Server 322 über das Netzwerk 312 oder indirekt von dem Server 214 über das Netzwerk 312 empfangen werden.
-
In dem System 300 kann Information an einem oder mehreren Orten in dem System 300 (z.B. lokal oder entfernt) gespeichert werden. Darüber hinaus können, da diese Daten sensibler Natur sein können, diese Daten verschlüsselt sein. Z.B. können gespeicherte Daten und/oder über das Netzwerk 312 kommunizierte Daten verschlüsselt sein.
-
4 ist ein Blockdiagramm, welches eine Kasse 400, z.B. die Kasse 212 (2 und 3), darstellt, welche das Verfahren 100 (1 und 2) durchführt. Die Kasse 400 umfasst eine oder mehrere Prozessierungseinheiten oder Prozessoren 410, eine Kommunikationsschnittstelle 412, eine Nutzerschnittstelle 414 und eine oder mehrere Signalleitungen 422, welche diese Komponenten miteinander koppeln. Der eine oder die mehreren Prozessoren 410 können paralleles Prozessieren und/oder Multi-Threading unterstützen, die Kommunikationsschnittstelle 412 kann eine persistente Kommunikationsverbindung aufweisen und die einen oder mehreren Signalleitungen 422 können einen Kommunikationsbus bilden. Darüber hinaus kann die Benutzerschnittstelle 414 ein Display 416, eine Tastatur 418 und/oder einen Pointer 420, z.B. eine Maus, aufweisen.
-
Ein Speicher 424 der Kasse 400 kann flüchtigen und/oder nicht-flüchtigen Speicher umfassen. Insbesondere kann der Speicher 424 umfassen: ROM, RAM, EPROM, EEPROM, Flash-Speicher, eine oder mehrere Smart-Karten, ein oder mehrere Magnetscheiben-Speichergeräte und/oder ein oder mehrere optische Speichergeräte. Der Speicher 424 kann ein Betriebssystem 426 speichern, welches Prozeduren (oder einen Satz von Anweisungen) zur Handhabung verschiedener, grundlegender Systemdienste zum Durchführen von Hardware-abhängigen Aufgaben umfasst. Der Speicher 424 kann ferner Prozeduren (oder einen Satz von Anweisungen) in einem Kommunikationsmodul 428 speichern. Diese Kommunikationsprozeduren können zur Kommunikation mit einem oder mehreren Computern und/oder Servern, inklusive Computern und/oder Servern, welche bezüglich der Kasse 400 entfernt angeordnet sind, verwendet werden.
-
Der Speicher 424 kann ferner mehrere Programm-Module (oder Sätze von Anweisungen) umfassen: eine Kassen-Software 310 (oder einen Satz von Anweisungen), Steuerobjekte 314 (oder einen Satz von Anweisungen), Dienstobjekte 316 (oder einen Satz von Anweisungen), ein Dienstobjekt zur mobilen Zahlung 320 (oder einen Satz von Anweisungen), ein Verschlüsselungsmodul 432 (oder einen Satz von Anweisungen) und/oder eine Finanzanwendung 434 (oder einen Satz von Anweisungen). Eines oder mehrere dieser Programm-Module (oder Sätze von Anweisungen) können einen Computerprogrammmechanismus bilden.
-
Während der Finanztransaktion in dem Verfahren 100 (1 und 2) empfängt das Dienstobjekt zur mobilen Zahlung 320 einen Token 436 von einem Kunden. Anschließend führt das Dienstobjekt zur mobilen Zahlung 320 einen oder mehrere, auf wenigstens dem Token 436 basierende Schritte durch, um mit dem Kunden assoziierte Finanzinformation 438 zu erhalten. Beispielsweise kann das Dienstobjekt zur mobilen Zahlung 320 den Token 436 direkt an den Server 214 (2 und 3) oder indirekt mittels dem Kommunikationsmodul 428 und der Kommunikationsschnittstelle 412 bereitstellen. In Erwiderung darauf kann das Dienstobjekt zur mobilen Zahlung 320 die Finanzinformation 438 von dem Server 214 (2 und 3) empfangen.
-
Alternativ kann die Finanzinformation 438 in der Kasse 400 gespeichert werden und über den Token 436 darauf zugegriffen werden. Beispielsweise kann der Token 436 mit einem Bonusprogramm assoziiert sein und die Finanzinformation 438 kann zuvor von dem Kunden bereitgestellt worden sein, als dessen Bonusprogramm-Konto eingerichtet wurde. Gemäß einiger Ausführungsformen verwendet dieser Look-Up-Schritt eine Datenstruktur, welche mit Kunden assoziierte Finanzinformation speichert. Dies ist in 5 gezeigt, welche eine Datenstruktur 500 darstellt, welche Finanzinformation 510 umfasst. Insbesondere kann eine Finanzinformation 510-1 umfassen: einen Token 512-1 und Information zur mobilen Zahlung 514-1 (z.B. eine Konto-Identifikation, einen verfügbaren Betrag, welcher ausgegeben werden kann, ein Finanzinstitut, etc.).
-
Zurückkommend auf 4 kann die Kasse 400 die Finanzinformation 438 und die mit der Finanztransaktion assoziierte Transaktionsinformation 440 an ein in der Finanzinformation 438 spezifiziertes Finanzinstitut 442 direkt oder indirekt bereitstellen. Daraufhin empfängt die Kasse 400 direkt oder indirekt eine Bestätigung 444 von dem Finanzinstitut 442, dass die Finanztransaktion abgeschlossen ist.
-
Weil Information in der Kasse 400 sensibler Natur sein kann, ist gemäß einiger Ausführungsformen wenigstens ein Teil der in dem Speicher 424 gespeicherten Daten und/oder wenigstens ein Teil der mittels des Kommunikationsmoduls 428 kommunizierten Daten über das Verschlüsselungsmodul 432 verschlüsselt.
-
Anweisungen in den diversen Modulen in dem Speicher 424 können implementiert sein in: einer prozeduralen Hochsprache, einer objektorientierten Programmiersprache und/oder in einer Assembler- oder Maschinensprache. Die Programmiersprache kann kompiliert oder interpretiert werden, z.B., konfigurierbar oder konfiguriert sein, um von einem oder mehreren Prozessoren 410 ausgeführt zu werden.
-
Obwohl die Kasse 400 dargestellt ist, als habe sie eine Vielzahl von diskreten Teilen, beabsichtigt 4 eine funktionale Beschreibung der diversen Bestandteile, welche in der Kasse 400 vorhanden sein können, zu geben, anstelle eines strukturellen Schemas der hierin beschriebenen Ausführungsformen. In der Praxis und wie dem Fachmann bekannt, können die Funktionen der Kasse 400 über eine große Anzahl von Servern oder Computern, mit verschiedenen Gruppen von Servern oder Computern, welche bestimmte Untermengen von Funktionen durchführen, verteilt sein. Gemäß einiger Ausführungsformen können einige oder alle der Funktionalitäten der Kasse 400 in einer oder mehreren integrierten Schaltungen (ASICs) und/oder einem oder mehreren digitalen Signalprozessoren (DSPs) implementiert sein.
-
Kassen (z.B. die Kasse 400) sowie Computer und Server in dem System 300 (3) können eine Vielzahl von Geräten, welche in der Lage sind, computerlesbare Daten zu manipulieren oder solche Daten zwischen zwei oder mehr Rechensystemen über ein Netzwerk zu kommunizieren, umfassen: ein PC, ein Laptop, ein Tablet-PC, ein Großrechner, ein tragbares, elektronisches Gerät (z.B. ein Mobiltelefon oder PDA), ein Server und/oder ein Client-Computer (in einer Client-Server Architektur). Darüber hinaus kann das Netzwerk 312 (3) umfassen: das Internet, World Wide Web (WWW), ein Intranet, ein Mobiltelefonnetzwerk, LAN, WAN, MAN, oder eine Kombination von Netzwerken oder anderen Technologien, welche Kommunikation zwischen Rechensystemen ermöglichen.
-
Gemäß einiger Ausführungsformen können ein oder mehrere der Module in dem Speicher 424 mit einer Finanzanwendung 434 assoziiert und/oder in dieser enthalten sein. Diese Finanzanwendung kann umfassen: Quicken™ und/oder TurboTax™ (von Intuit, Inc., Mountain View, Kalifornien), Microsoft Money™ (von Microsoft Corporation, Redmond, Washington), SplashMoney™ (von SplashData, Inc., Los Gatos, Kalifornien), Mvelopes™ (von In2M, Inc., Draper, Utah), und/oder Open-Source Anwendungen, wie z.B. Gnucash™, PLCash™, Budget™ (von Snowmint Creative Solutions, LLC, St. Paul, Minnesota), und/oder andere Planungs-Software, welche dazu geeignet ist, Finanzinformation zu verarbeiten.
-
Darüber hinaus kann die Software-Anwendung 434 mit einer Software assoziiert sein und/oder diese umfassen, z.B.: OuickBooks™ (von Intuit, Inc., Mountain View, Kalifornien), Peachtree™ (von The Sage Group PLC, Newcastle Upon Tyne, Vereinigtes Königreich von Großbritannien), Peachtree Complete™ (von The Sage Group PLC, Newcastle Upon Tyne, Vereinigtes Königreich von Großbritannien), MYOB Business Essentials™ (von MYOB US, Inc., Rockaway, New Jersey), NetSuite Small Business Accounting™ (von NetSuite, Inc., San Mateo, Kalifornien), Cougar Mountain™ (von Cougar Mountain Software, Boise, Idaho), Microsoft Office Accounting™ (von Microsoft Corporation, Redmond, Washington), Simply Accounting™ (von The Sage Group PLC, Newcastle Upon Tyne, Vereinigtes Königreich von Großbritannien), CYMA IV Accounting™ (von CYMA Systems, Inc., Tempe, Arizona), DacEasy™ (von Sage Software SB, Inc., Lawrenceville, Georgia), Microsoft Money™ (von Microsoft Corporation, Redmond, Washington), Tally.ERP (von Tally Solutions, Ltd., Bangalor, Indien) und/oder andere Lohnbuch- oder Rechnungswesen-Software, welche dazu geeignet ist, Lohninformation zu verarbeiten.
-
Das System 300 (3), die Kasse 400 (4) und/oder die Datenstruktur 500 können weniger oder zusätzliche Komponenten umfassen. Darüber hinaus können zwei oder mehr Komponenten in einer einzige Komponente kombiniert sein und/oder ein Teil einer oder mehrerer Komponenten können verändert werden. Gemäß einiger Ausführungsformen kann die Funktionalität des Systems 300 (3) und/oder der Kasse 400 zu einem größeren Anteil in Hardware und zu einem geringeren Anteil in Software implementiert sein oder zu einem geringeren Anteil Hardware und zu einem größeren Anteil in Software implementiert sein, so wie dies bekannt ist.
-
Die vorangegangene Beschreibung beabsichtigt einen Fachmann dazu zu befähigen, die Offenbarung herzustellen und zu verwenden und ist in dem Kontext einer bestimmten Anmeldung und ihrer Anforderungen dargelegt. Darüber hinaus wurde die vorangegangene Beschreibung von Ausführungsformen der vorliegenden Offenbarung lediglich zum Zwecke der Darstellung und Beschreibung präsentiert. Diese beabsichtige nicht, erschöpfend zu sein oder die vorliegende Offenbarung auf die offenbarten Formen zu beschränken. Dementsprechend sind dem Fachmann viele Modifikationen und Variationen offensichtlich und die hier definierten, grundlegenden Prinzipien können in anderen Ausführungsformen und Anwendungen angewendet werden, ohne von dem Gedanken und dem Umfang der vorliegenden Offenbarung abzuweichen. Zudem ist die Beschreibung der vorangegangenen Ausführungsformen nicht dazu gedacht, die vorliegende Offenbarung zu beschränken. Daher ist die vorliegende Offenbarung nicht dazu gedacht, auf die gezeigten Ausführungsformen beschränkt zu sein, sondern mit der bereitest möglichen Auslegung, welche mit ihren offenbarten Prinzipien und Merkmalen konsistent ist, zu verstehen.
