DE112016000192B4 - Client-seitige Sicherheit für Transaktionen auf Tokengrundlage - Google Patents

Client-seitige Sicherheit für Transaktionen auf Tokengrundlage Download PDF

Info

Publication number
DE112016000192B4
DE112016000192B4 DE112016000192.4T DE112016000192T DE112016000192B4 DE 112016000192 B4 DE112016000192 B4 DE 112016000192B4 DE 112016000192 T DE112016000192 T DE 112016000192T DE 112016000192 B4 DE112016000192 B4 DE 112016000192B4
Authority
DE
Germany
Prior art keywords
token
transaction
transfer unit
token transfer
resource
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE112016000192.4T
Other languages
English (en)
Other versions
DE112016000192T5 (de
Inventor
Nitin Gaur
Gregory Louis Truty
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112016000192T5 publication Critical patent/DE112016000192T5/de
Application granted granted Critical
Publication of DE112016000192B4 publication Critical patent/DE112016000192B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/321—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wearable devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3672—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes initialising or reloading thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)
  • Telephone Function (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

Verfahren zum Verarbeiten von Transaktionen in einer Tokenübertragungseinheit (200; 304), wobei das Verfahren aufweist:Speichern (318) eines Transaktionstokens (104; 400) mit einem vorgegebenen Transaktionsressourcenwert (402) und einem zugehörigen Validierungsparameter (404);Initiieren (322) eines Transaktionsdienstes mit einem Tokenempfangsterminal (308);Aufrufen (324, 326) eines Tokenzustandsmanagers (225) in Verbindung mit dem Initiieren eines Transaktionsdienstes; undwobei der Tokenzustandsmanagerein Ereignis ermittelt, das dem vorgegebenen Validierungsparameter entspricht, wobei das Ermitteln eines Ereignisses aufweist:Ermitteln eines Status der Verbindungsaktivität eines Ressourcenkontonetzwerks; undErmitteln von Bedingungsregisterdaten, die dem Validierungsparameter zugehörig sind; undAusgeben (330) eines Tokenänderungsaufrufs zum Ändern eines Tokens einer Transaktion, die ausgeführt werden soll, auf Grundlage des ermittelten Ereignisses und des Validierungsparameters.

Description

  • HINTERGRUND
  • Ausführungsformen des Offenbarungsgegenstands beziehen sich im Allgemeinen auf das Gebiet eines Verarbeitens von Zwischendarstellungen bei Computertransaktionen zwischen mehreren Einheiten. Im Besonderen bezieht sich der Erfindungsgegenstand auf ein Bereitstellen einer Client-seitigen Sicherheit für Transaktionen auf Tokengrundlage, die zwischen mehreren Einheiten stattfinden.
  • Magnetstreifenkarten sind seit langem die vorherrschende Art, in der mobile elektronische Transaktionen bereitgestellt werden, bei denen ein Lesegerät in einem Point-of-Sale-(POS-) oder anderweitigen Transaktionsterminal Kontodaten empfängt, die in dem Streifen codiert sind. Diese magnetisch codierten Karten werden für Einkäufe im Einzelhandel, für die Einlösung von Gutscheinen usw. verwendet. Die von einer Karte abgerufenen Kontodaten werden durch den Transaktionsterminal an einen Ressourcenkontoserver gesendet, der als Antwort darauf eine Berechtigung erteilt, Ressourcen von einem vorgegebenen Ressourcenkonto wie z.B. einem Giro- oder Sparkonto zu verwenden.
  • Erhebliche Entwicklungen bei der Kapazität und Flexibilität des Betriebs von mobilen elektronischen Einheiten (z.B. Smartphones) haben Entwicklungen auf dem Gebiet mobiler elektronischer Zahlungen durch tragbare elektronische Einheiten wie beispielsweise Smartphones hervorgebracht. Anstelle der herkömmlichen Magnetstreifen-Lesegeräte kommen bei mobilen elektronischen Transaktionen üblicherweise Hochfrequenz-(HF-)Schnittstellen wie Nahfeld-Kommunikation (Near Field Communication, NFC) zum Einsatz. Mobile Zahlungslösungen beinhalten elektronische oder mobile Zahlungsmittel und elektronische oder mobile Geldbörsen. Obwohl die Entwicklung mobiler Zahlungssysteme unter Verwendung von in jüngster Zeit entwickelter Technologie voranschreitet, bleibt die Sicherheit ein erhebliches Problem für elektronische Transaktionssysteme.
  • Die Druckschrift EP 2 819 080 A1 betrifft ein Telekommunikationssystem, das einen Autorisierungsserver umfasst, um eine schnelle Autorisierung mittels eines mobilen Telekommunikationsgeräts auch in einer Umgebung zu ermöglichen, in der keine stabile mobile Netzwerkverbindung verfügbar ist. Gemäß dem System ist das mobile Gerät so konfiguriert, dass es automatisch ein Autorisierungs-Token vom Autorisierungsserver lange vor dem eigentlichen Autorisierungsereignis anfordert. Wenn keine mobile Netzwerkverbindung verfügbar ist, wird die Anforderung automatisch und wiederholt an den Autorisierungsserver gesendet, bis die mobile Netzwerkverbindung wiederhergestellt ist und der angeforderte Autorisierungscode empfangen wird. Der Autorisierungsserver ist so konfiguriert, dass er das angeforderte Autorisierungs-Token an das mobile Gerät sendet und das Autorisierungs-Token und Informationen über ein Produkt oder eine Dienstleistung von einem Endgerät empfängt. Der Autorisierungsserver validiert das Autorisierungs-Token und autorisiert oder verweigert den Kauf des Produkts oder der Dienstleistung in Abhängigkeit von einem Ressourcenkonto, das mit dem Benutzer des mobilen Geräts verbunden ist. Der Autorisierungsserver überträgt die Autorisierung oder die Verweigerung an das Endgerät.
  • Die Druckschrift US 2012 / 0 239 556 A1 betrifft ein von einem Latenzzahlungsabwicklungsprozessor implementiertes Verfahren zur Umwandlung einer Latenzzahlungsmethodenanforderung in eine Latenzzahlung. Das Verfahren umfasst: Erhalten einer Latenzzahlungsmethodenanforderung mit: einer vom Verbraucher spezifizierten Zahlungsmethode, einem Verbraucherwährungstyp, einem Händlerwährungstyp und einem Händlerpostenwährungsbetrag; Bestimmen einer Latenzzahlungsperiode, die mit der Latenzzahlungsmethodenanforderung verbunden ist; Bestimmen eines Latenzpufferbetrages auf der Grundlage der Latenzzahlungsmethodenanforderung und der Latenzzahlungsperiode; Erzeugen einer Latenzzahlungsanforderung durch Summieren des Latenzpufferbetrages mit dem Währungsbetrag des Händlerartikels und Strukturieren der summierten Beträge gemäß der Latenzzahlungsperiode; und Bereitstellen der Latenzzahlungsanforderung.
  • Die Druckschrift US 8 682 802 B1 betrifft ein computerimplementiertes Verfahren. Das Verfahren umfasst: Empfangen einer Anforderung für ein Einmalzahlungs-Token durch eine oder mehrere Computereinheiten, die einen oder mehrere Hardware-Prozessoren beinhalten, wobei die Anforderung mindestens ein Benutzerkonto, einen Betrag und eine Verfallszeit für das Einmalzahlungs-Token spezifiziert, wobei die Verfallszeit spezifisch für das Einmalzahlungs-Token ist; Verifizieren, durch mindestens eine der einen oder mehreren Computereinheiten, dass auf dem Benutzerkonto ein Geldbetrag verfügbar ist, der mindestens gleich dem in der Anforderung angegebenen Betrag ist; Erzeugen des Einmalzahlungs-Tokens durch mindestens eine der einen oder mehreren Computereinheiten als eine Zahl, die mit dem Benutzerkonto verknüpft ist und zur einmaligen Verwendung vor dem durch die Anforderung für das Einmalzahlungs-Token spezifizierten Zeitablauf verfügbar ist; Übertragen des Einmalzahlungs-Tokens an eine mit dem Benutzerkonto verknüpfte Benutzereinheit, wobei die Benutzereinheit so konfiguriert ist, dass sie einen Bildcode erzeugt, der zumindest teilweise auf dem Zahlungs-Token basiert; Empfangen einer Zahlungsanforderung von einem Empfänger, wobei die Zahlungsanforderung als Reaktion darauf empfangen wird, dass ein mit dem Empfänger verknüpftes Gerät den von dem Benutzergerät präsentierten Bildcode als Teil einer mit dem Einmalzahlungs-Token verknüpften Einlösungsanforderung empfängt, wobei die Zahlungsanforderung verschlüsselt ist und wobei die Zahlungsanforderung mindestens den Einmalzahlungs-Token und einen angeforderten Betrag beinhaltet; Entschlüsseln der Zahlungsanforderung, um zumindest das Einmalzahlungs-Token und den angeforderten Betrag zu identifizieren; und Veranlassen, dass der angeforderte Betrag von dem Benutzerkonto auf ein Konto des Empfängers übertragen wird, zumindest teilweise basierend auf dem Ermitteln, dass das Einmalzahlungs-Token gültig ist und nicht vorangehend als Teil einer anderen Zahlungsanforderung empfangen wurde, dass das Einmalzahlungs-Token nicht abgelaufen ist und dass der angeforderte Betrag den Betrag des Einmalzahlungs-Tokens nicht überschreitet.
  • Die Druckschrift US 2012 / 0 303 432 A1 betrifft ein Verfahren zum Aktualisieren des Wertes eines digitalen Gutscheins mit einem anfänglichen Wert durch ein mobiles Gerät. Das Verfahren umfasst: Empfangen des digitalen Gutscheins mit dem anfänglichen Wert durch das mobile Gerät von einem entfernten Server; Empfangen, durch eine Verarbeitungseinheit des mobilen Geräts, mindestens eines Eingabeparameters; Berechnen, durch die Verarbeitungseinheit, eines neuen Wertes des digitalen Gutscheins auf Grundlage des mindestens einen Eingabeparameters; und Anzeigen des neuen Wertes auf einer Anzeige des mobilen Gerätes.
  • Die Druckschrift CN 104 02 14 69 A betrifft ein Verfahren zur Durchführung einer Zahlungstransaktion zwischen einem mobilen Endgerät und einem Zahlungsterminal in Kommunikation mit einem Zahlungs-Backend-System. Das Verfahren umfasst: (a) Senden einer Mobilterminal-Kennung von dem Mobilterminal an das Zahlungs-Backend-System; (b) Zurücksenden eines Kryptogramms von dem Zahlungs-Backend-System an das mobile Endgerät, wobei das Kryptogramm einen Transaktionsidentifikator in verschlüsselter Form umfasst; (c) Umwandeln des Kryptogramms in ein Proximity-Zahlungstoken, so dass das Proximity-Zahlungstoken den Transaktionsidentifikator in verschlüsselter Form enthält, und Übertragen des Proximity-Zahlungstokens an das Zahlungsterminal über einen Proximity-Kommunikationskanal; (d) Weiterleiten eines Transaktionsdatensatzes, der den Transaktionsidentifikator in verschlüsselter Form und den Betrag der Zahlungstransaktion enthält, von dem Zahlungsterminal an das Zahlungs-Backend-System; und (e) Entschlüsseln des Transaktionsidentifikators in verschlüsselter Form und Verarbeiten der Zahlungstransaktion durch das Zahlungs-Backend-System.
  • KURZDARSTELLUNG
  • Offenbart wird ein Verfahren zum Verarbeiten von Transaktionen in einer Tokenübertragungseinheit wie z.B. einem Smartphone oder einer anderen tragbaren elektronischen Einheit. Das Verfahren beinhaltet ein Speichern eines Transaktionstokens mit einem vorgegebenen Transaktionsressourcenwert und einem zugehörigen Validierungsparameter in dem Arbeitsspeicher der Tokenübertragungseinheit. Eine Transaktionsübertragungsschnittstelle initiiert einen Transaktionsdienst mit einem Tokenempfangsterminal und ruft einen Tokenzustandsmanager auf. Der Tokenzustandsmanager ermittelt ein Ereignis, das dem vorgegebenen Validierungsparameter entspricht, indem er einen Status der Verbindungsaktivität eines Transaktionsressourcennetzwerks ermittelt und indem er Bedingungsregisterdaten ermittelt, die dem Validierungsparameter zugehörig sind. Der Tokenzustandsmanager gibt daraufhin auf Grundlage des ermittelten Ereignisses und des Validierungsparameters einen Transaktionsänderungsaufruf aus.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Die vorliegenden Ausführungsformen werden verständlicher und zahlreiche Gegenstände, Merkmale und Vorteile für den Fachmann offensichtlich, wenn auf die beigefügten Zeichnungen Bezug genommen wird.
    • 1 ist eine allgemeine Systemdarstellung, die Komponenten darstellt, welche gemäß einer Ausführungsform in einem Client-seitigen Tokensicherheitssystem enthalten sind oder damit interagieren können;
    • 2 ist ein Blockschaubild, das eine Tokenübertragungseinheit gemäß einer Ausführungsform veranschaulicht;
    • 3 ist eine Signalverarbeitungsdarstellung, die ein Nachrichtenprotokoll für eine Tokenübertragung gemäß einer Ausführungsform veranschaulicht;
    • 4A ist eine konzeptionelle Darstellung, die ein Tokenkonstrukt gemäß einer Ausführungsform veranschaulicht;
    • 4B ist eine konzeptionelle Darstellung, die Validierungsparameter veranschaulicht, welche gemäß einer Ausführungsform als einem Token zugehörige Tags codiert sind;
    • 5 ist eine konzeptionelle Darstellung einer Transaktionsereignistabelle des Tokenzustandsmanagers gemäß einer Ausführungsform;
    • 6 ist ein allgemeiner Ablaufplan, der Schritte und Funktionen zum Konfigurieren einer Tokenübertragungseinheit veranschaulicht, um gemäß einer Ausführungsform Tokentransaktionen zu verarbeiten;
    • 7 ist ein allgemeiner Ablaufplan, der Schritte darstellt, die zum Verarbeiten einer Tokentransaktion gemäß einer Ausführungsform durchgeführt werden;
    • 8 ist ein Ablaufplan, der Schritte darstellt, die durch einen Tokenzustandsmanager während einer Tokentransaktion gemäß einer Ausführungsform durchgeführt werden; und
    • 9 ist ein Blockschaubild eines Computersystems zum Durchführen der mit Blick auf die 1 bis 8 beschriebenen Funktionen.
  • BESCHREIBUNG DER AUSFÜHRUNGSFORM/EN
  • Die folgende Beschreibung enthält beispielhafte Systeme, Verfahren, Methoden, Befehlsfolgen und Computerprogrammprodukte, die Methoden des vorliegenden Erfindungsgegenstands ausführen. Allerdings sollte klar sein, dass die beschriebenen Ausführungsformen auch ohne diese spezifischen Einzelheiten umgesetzt werden können. In anderen Fällen werden bekannte Befehlselemente, Protokolle, Strukturen und Methoden nicht im Detail gezeigt, um die Beschreibung nicht unverständlich zu machen.
  • Hier beschriebene Ausführungsformen ermöglichen sichere Online- oder Offline-Zahlungen mit mobilen Einheiten unter Verwendung einer Transaktionsressource, die über ein Netzwerk zugänglich ist. 1 ist eine allgemeine Systemdarstellung, die Systeme darstellt, welche gemäß einer Ausführungsform in einem Client-seitigen Tokensicherheitssystem enthalten sind oder damit interagieren können. Die Systeme beinhalten ein Netzwerk 114, das eine Verbindung bereitstellt, über die ein Ressourcentransaktionsserver 110 mit einer drahtlosen Einheit 140 und einem POS-System 133 Daten austauscht. Die Verbindung kann durch mehrere Teilnetzwerke und verschiedene Arten von Netzwerkkomponenten, Verbindungsmedien und Protokollen sowie Übertragungsdienste hergestellt werden, darunter Lichtwellenleiter, Telefonleitungen, Ethernet-802- und Internet-Protokolle. Gemäß einem Aspekt ermöglicht das Netzwerk 114 eine Datenübertragung zwischen der drahtlosen Einheit 140 und dem Ressourcenserver 110, um damit eine Verarbeitung eines vorgegebenen Ressourcenkontos von mehreren (nicht dargestellten) Ressourcenkonten zu unterstützen, die als Kontodaten in einer Kontodatenbank 108 gespeichert werden und durch einen Kontomanager 106 in dem Ressourcenserver 110 verwaltet werden. Gemäß einem weiteren Aspekt ermöglicht das Netzwerk 114 eine Datenübertragung zwischen dem Ressourcenserver 110 und dem POS-System 133, um damit Ressourcentransaktionen wie z.B. eine Überweisung eines Guthabens während einer Kreditkarten-Zahlungstransaktion zu unterstützen, in deren Verlauf der Ressourcenserver 110 codierte Kontodaten, die von dem POS-System 133 wie z.B. der drahtlosen Einheit 140 bereitgestellt werden, auf ihre Berechtigung prüft oder auf andere Art validiert.
  • Der Ressourcenserver 110 und der Kontomanager 106 sind üblicherweise einem Geldinstitut wie z.B. einer Bank oder einem Kreditinstitut zugehörig, das Geldkonten einrichtet und organisiert, die kontoführenden Kunden zugehörig und zugänglich sind. In der dargestellten Ausführungsform beinhaltet der Ressourcenserver 110 eine Netzwerkschnittstelle 112 zum Austauschen von Daten über das Netzwerk 114, um damit eine Übertragung von Ressourcenkontotransaktionen mit dem Kontomanager 106 zu unterstützen. Eine Kontodatenbank 108 speichert Kontodaten - üblicherweise für einzelne Benutzer oder Institute -, die Debit- und Kreditkonten, Transaktionsarten (z.B. online oder offline) sowie Transaktionsmittel (z.B. Kreditkarte, Debitkarte usw.) enthalten können. Während POS-Transaktionen, wie sie z.B. zwischen der drahtlosen Einheit 140 und dem POS-System 133 stattfinden, übernimmt der Kontomanager 106 damit zusammenhängende Aufgaben eines Verfolgens von Kontodaten und eines Überprüfens der Kontodaten. Als Reaktion auf ein Verarbeiten spezifischer Transaktionsdaten (z.B. Kaufbetrag und Kontoidentifizierung), die durch das POS-System 133 gesendet werden, kann der Ressourcenserver 110 während einer Zahlungstransaktion zum Beispiel eine Transaktionsberechtigung an das POS-System 133 senden.
  • Der Ressourcenserver 110 beinhaltet des Weiteren einen Transaktionstokenmanager 102, der mit dem Kontomanager 106 integriert oder auf andere Art und Weise kommunikativ mit diesem verbunden sein kann. Der Tokenmanager 102 erzeugt und verwaltet kontospezifische Transaktionstoken 104 in Zusammenhang mit Konten, die in der Kontodatenbank 108 gespeichert werden. Im vorliegenden Kontext können die Begriffe „Token“ und „Tokenidentifizierung“ synonym verwendet werden, um eine Datenstruktur zu bezeichnen, mit der eine Transaktionsressource dargestellt wird. Im Falle einer Finanztransaktion auf Tokengrundlage werden Token dazu verwendet, sensible Zahlungsdaten durch einen verhältnismäßig eindeutigen Bezeichner zu ersetzen, der sich nur unter Schwierigkeiten oder gar nicht auf mathematische Art und Weise rückerschließen lässt. Die Ressourcendaten (z.B. Kunden- und Kontoidentität sowie Zahlungsdaten) werden durch den Kontomanager 106 zentral gespeichert und verwaltet, der - wie oben erläutert - üblicherweise durch den zugrundeliegenden Ressourcenanbieter oder Ressourcen-Broker betrieben wird.
  • Das POS-System 133 ist in 1 als eine Netzwerkschnittstelle 132 zum Austauschen von Daten über das Netzwerk 114 sowie als ein Prozessor 134 und ein zugehöriger Systemarbeitsspeicher 136 dargestellt. Eine Transaktionsprozessoranwendung 136 wird in einem Arbeitsspeicher 135 gespeichert und durch den Prozessor 134 ausgeführt, um Zahlungstransaktionen z.B. zwischen der drahtlosen Einheit 140 und dem POS-System 133 zu unterstützen. Die Transaktionsprozessoranwendung 136 beinhaltet ausführbaren Code und logische Verarbeitungskonstrukte zum Verarbeiten von Zahlungskontodaten, die in einer Zahlungsschnittstelle wie z.B. einem NFC-Lesegerät/Steuergerät 138 empfangen werden, sowie zum Erzeugen einer entsprechenden Berechtigungsanforderung für das Zahlungskonto, die das POS-System 133 an den Ressourcentransaktionsserver 110 sendet. Genauer gesagt führt das POS-System 133 die Transaktionsprozessoranwendung 136 aus, um Kontodaten von einer Zahlungseinheit zu lesen, um über eine Datenübertragung mit dem Ressourcenserver 110 zu bestätigen, dass berechtigte Kontoressourcen verfügbar sind, um mit dem Ressourcenserver 110 beim Übertragen der Kontoressourcen (z.B. einer Gutschrift) von dem angegebenen Konto auf ein weiteres Konto zusammenzuarbeiten und um die Transaktion aufzuzeichnen.
  • Die drahtlose Einheit 140 beinhaltet eine Netzwerkschnittstelle 141, einen Prozessor 142 und einen zugehörigen Systemarbeitsspeicher 145, der Daten sowie System- und Anwendungssoftware speichert. Die Netzwerkschnittstelle 141 weist Hardware- und Softwarekomponenten auf, um eine Transceiver-Verbindung und eine Protokollverarbeitung zu realisieren, so dass die drahtlose Einheit 140 mit Einheiten, die mit dem Netzwerk verbunden sind, wie z.B. dem Ressourcentransaktionsserver 110 und dem POS-System 133 Daten austauschen kann. Die Netzwerkschnittstelle 141 beinhaltet ein (nicht dargestelltes) drahtloses Netzwerkschnittstellen-Steuergerät und andere Einheiten und Logikkomponenten, um eine Verbindung herzustellen und zu trennen und um Nachrichten über Netzwerke auf HF-Grundlage zu senden und zu empfangen. Der Prozessor 142 und der Arbeitsspeicher 145 können eine zusätzliche Verarbeitungsfähigkeit bereitstellen, die für eine Datenübertragung über das Netzwerk notwendig ist, und des Weiteren die drahtlose Einheit 140 in die Lage versetzen, andere datenverarbeitende Aufgaben durchzuführen, die mit den hier beschriebenen Verfahren in Zusammenhang stehen, beiläufig daraus folgen oder aber nicht damit in Zusammenhang stehen. Bei verschiedenen Ausführungsformen kann die drahtlose Einheit 140 in unterschiedlichen Außenmaßen, Aufmachungen und Formfaktoren enthalten sein. Die mobile Einheit 140 kann ein Handy oder eine andere Art von Mobiltelefon sein, oder es kann sich um eine hochintegrierte tragbare Einheit wie z.B. ein Smartphone oder eine beliebige andere Art von tragbarer elektronischer Einheit mit Netzwerkverbindung handeln.
  • Die drahtlose Einheit 140 beinhaltet des Weiteren ein NFC-Steuergerät 146, um über das NFC-Lesegerätmodul 138 mit dem POS-System 133 Daten auszutauschen. NFC ist eine Form von „kontaktloser“ HF-Datenübertragungstechnologie, die eine Einweg- oder Zweiweg-Datenübertragung zwischen Terminals (Einheiten oder Endgeräten) ermöglicht, die sich in relativ geringer Entfernung (meist wenige Zentimeter) zueinander befinden. Eine Transaktionsdienstverbindung kann hergestellt werden, indem die drahtlose Einheit 140 in der Nähe des oder auf dem NFC-Lesegerät 138 positioniert, hin- und herbewegt oder auf andere Art und Weise bewegt wird. Bei manchen Ausführungsformen kann eine Verbindung auch dadurch hergestellt werden, dass die drahtlose Einheit 140 in direkten Kontakt mit der Oberfläche eines Lesegeräts wie z.B. des NFC-Lesegeräts 138 gebracht wird.
  • 1 stellt des Weiteren eine tragbare elektronische Einheit („Wearable-Einheit“) 120 dar, die wie die drahtlose Einheit 140 einen Prozessor 122, einen zugehörigen Systemarbeitsspeicher 125 und ein NFC-Steuergerät 126 beinhaltet. Eine Wearable-Einheit wie z.B. die Wearable-Einheit 120 ist in einer Hinsicht als eine Art von elektronischer Einheit definiert, die einen Formfaktor aufweist, der für eine wie auch immer geartete Befestigung an einem Benutzer geeignet ist. Eine Wearable-Einheit 120 kann zum Beispiel einen Formfaktor haben, mit dem sie an einem Kleidungsstück oder an einem Körperteil eines Benutzer wie z.B. Handgelenk, Nase oder Ohr usw. befestigt, angeheftet, angehängt oder anderweitig fixiert werden kann. Andere bedeutsame Merkmale, die Wearable-Datenverarbeitungseinheiten gemeinsam haben, beinhalten einen vergleichsweise durchgängigen aktiven Betrieb und einen Formfaktor, der eine fortlaufende und unterbrechungsfreie Zugänglichkeit und Nutzbarkeit der Einheit durch den Benutzer ermöglicht. Formfaktoren von Wearable-Einheiten weisen zum Beispiel Ähnlichkeit mit Brillen (z.B. Google Glasses) oder Armbändern auf. Die Wearable-Einheit 120 kann für allgemeine oder spezielle Verarbeitungs- und Datenübertragungszwecke verwendet werden, die eine komplexere Datenverarbeitungsunterstützung als nur eine vorcodierte Hardwarelogik benötigen.
  • Allgemein gesprochen ermöglichen die dargestellten Systeme und Komponenten Kontoressourcentransaktionen, bei denen ein Benutzer unter Verwendung von Konten, die durch den Benutzer verwaltet werden und ihm zugehörig sind, durch die Komponenten in dem Ressourcenserver 110 zum Beispiel Zahlungen leisten kann. NFC-fähige Einheiten wie z.B. die Wearable-Einheit 120 und die drahtlose Einheit 140 sind Beispiele von Einheiten, die in immer stärkerem Maße für mobile Ressourcentransaktionen wie z.B. mobile POS-(mPOS-)Transaktionen verwendet werden. Grundsätzlich beinhaltet eine NFC-Diensttransaktion zwischen einer mobilen Einheit wie z.B. der Einheit 120 oder 140 und einem POS-Terminal wie z.B. dem POS-System 133, dass das NFC-Steuergerät und die zugehörigen Transaktionsanwendungen ein physisches Mittel zur Transaktionszahlung wie z.B. eine Kreditkarte nachahmen. So kann die drahtlose Einheit 140, die üblicherweise von einem Benutzer in der Hand gehalten wird, mit dem POS-System 133 interagieren, das üblicherweise in einer am Ort vorhandenen Einzelhandels-Transaktionsausrüstung eines Verkäufers enthalten ist, um wie im Folgenden beschrieben eine Zahlungstransaktion zu verarbeiten.
  • Die drahtlose Einheit 140 dient als eine Initiatoreinheit und beginnt daher eine Diensttransaktion, indem sie eine Peer-to-Peer-Diensttransaktion mit dem POS-System 133 anfordert, das als die Zieleinheit dient. Nach der anfänglichen Dienstanforderung werden die betreffenden NFC-Steuergeräte 146 und 138 im Anforderung/Antwort-Modus betrieben, um die Transaktion zu verarbeiten und abzuschließen. Das NFC-Steuergerät 146 tauscht direkt oder indirekt (z.B. über Sicherheitslogik) Daten mit einer (nicht dargestellten) Ressourcentransaktionsanwendung aus, die einem Ressourcenkonto zugehörig ist, das durch den Ressourcenserver 110 verwaltet wird. Die Ressourcentransaktionsanwendung wird in der drahtlosen Einheit 140 gespeichert und von dieser ausgeführt, um auf Geld- oder anderweitige Transaktionstauschwerte zuzugreifen. Während der Transaktion kann die drahtlose Einheit 140 mit dem Zahlungsressourcenserver 110 Daten austauschen, um auf verwendbare Kontodaten zuzugreifen, die dann bei der Transaktion verwendet werden können. Auf ähnliche Weise kann die Wearable-Einheit 120 über ein NFC-Lesegerät/Steuergerät 138 beim Durchführen der Transaktion mit dem POS-System 133 als ein physischer Zahlungs-Proxy verwendet werden. Da die Wearable-Einheit 120 jedoch nicht netzwerkfähig ist (d.h. keine Netzwerkschnittstelle beinhaltet), ist sie darauf angewiesen, Kontodaten von einer auf geeignete Weise gekoppelten netzwerkfähigen Einheit wie z.B. der drahtlosen Einheit 140 zu empfangen, oder sie muss Kontodaten verwenden, die lokal in dem Arbeitsspeicher 125 gespeichert sind. Bei einer Paarung von Einheiten kann die Wearable-Einheit 120 (z.B. über eine Bluetooth-Verbindung) kommunikativ mit der drahtlosen Einheit 140 verbunden sein, die als eine Vermittlereinheit dient, welche Kontodaten von dem Ressourcenserver 110 an die Wearable-Einheit 120 überträgt. Das POS-System 133 empfängt und verarbeitet die Kontodaten von der Wearable-Einheit 120, um die Transaktion abzuschließen. Bei einer internen Speicherung von Kontodaten kann die Wearable-Einheit 120 entweder vorab lokal gespeicherte oder statische Kontodaten bereitstellen.
  • Aus einer verteilten Übertragung, Speicherung und Verwendung von tatsächlichen Kontodaten ergibt sich eine Vielfalt von Problemen mit der Sicherheit von Ressourcenkontodaten. Sowohl für die drahtlose Einheit 140 als auch für die Wearable-Einheit 120 stellt die dargestellte Ausführungsform einen Transaktionsdienst auf Tokengrundlage bereit, der ansonsten auftretende Datensicherheitsprobleme löst. Dabei können die drahtlose Einheit 140 und die Wearable-Einheit 120 Transaktionstoken wie z.B. Token 148 und 128 während Diensttransaktionen mit dem POS-System 133 abrufen, speichern, verarbeiten und senden, so dass nur wenige oder überhaupt keine Kontodaten zwischen den Einheiten 140 bzw. 120 und dem System 133 übertragen werden müssen.
  • 2 ist ein Blockschaubild, das eine Tokenübertragungseinheit 200 gemäß einer Ausführungsform veranschaulicht. In der dargestellten Ausführungsform beinhaltet die Tokenübertragungseinheit 200 eine Netzwerkschnittstelle 202, die z.B. in einer drahtlosen netzwerkfähigen Einheit wie einem Mobiltelefon enthalten sein kann. Dabei sollte allerdings klar sein, dass die mit Blick auf 2 dargestellte und beschriebene Tokenübertragungsfunktionalität auch in einer nicht netzwerkfähigen Einheit wie z.B. der Wearable-Einheit 120 aus 1 enthalten und realisiert sein kann. Des Weiteren ist darauf hinzuweisen, dass die üblicherweise in mobilen elektronischen Einheiten enthaltenen Komponenten und Funktionen wie z.B. Mechanismen für die Benutzereingabe/-ausgabe und Anzeigen in der Einheit 200 enthalten sein können, auch wenn sie hier aus Gründen der Klarheit nicht dargestellt sind. Die Tokenübertragungseinheit 200 beinhaltet des Weiteren einen Host-Prozessor 204 und einen zugehörigen Host-Arbeitsspeicher 210, die zusammenwirken, um verschiedene Programme und Daten auf System- und Anwendungsebene zu verwalten, mit denen die Einheit 200 verschiedene Transaktionsdienstaufgaben durchführen kann, die Ressourcentransaktionskonten zugehörig sind, wie beispielsweise die mit Blick auf 1 beschriebenen Aufgaben. In der dargestellten Ausführungsform beinhaltet die Einheit 200 des Weiteren eine Transaktionsübertragungsschnittstelle in Gestalt einer NFC-Schnittstelle 211. Die NFC-Schnittstelle 211 weist ein NFC-Steuergerät 207 auf, um mit einem POS-System oder einem anderen aktiven NFC-Transaktionsterminal Daten auszutauschen. Die NFC-Schnittstelle 211 beinhaltet auch eine NFC-Antenne 209, um mit anderen NFC-Einheiten wie z.B. einem NFC-fähigen POS-System eine drahtlose Verbindung herzustellen und aufrechtzuerhalten.
  • In Übereinstimmung mit bekannten Methoden für die Arbeitsspeicherverwaltung und -organisation wird der Arbeitsspeicher 210 einem adressierbaren Systemarbeitsspeicher-Bereich 222 und einem adressierbaren Anwendungsebenen-Bereich 217 zugeordnet. Der Systemarbeitsspeicher-Bereich 222 speichert Programme und unterstützende Daten, die Operationen der Einheit 200 und ihrer Komponenten steuern. Die in dem Systemarbeitsspeicher-Bereich 222 gespeicherte Systemsoftware beinhaltet Betriebssystemsoftware, die alle Aktivitäten zwischen den Computerhardware-Einheiten koordiniert, und Dienstprogrammsoftware, die eine spezifische Aufgabe durchführt, welche sich in der Regel auf ein Verwalten eines Computers, seiner Einheiten oder seiner Programme bezieht.
  • In der dargestellten Ausführungsform werden in dem Systemarbeitsspeicher-Bereich 222 ein Betriebssystem 215 und ein Tokenzustandsmanager-Dienstprogramm 225 verwaltet. Das Betriebssystem 215 kann ein flexibles Mehrzweckbetriebssystem wie z.B. das Android-Betriebssystem sein, das in Smartphones verwendet wird, oder es kann sich um ein eingebettetes Betriebssystem mit spezielleren Funktionen handeln, wie es in eine elektronische Wearable-Transaktionseinheit geladen werden kann. Das Betriebssystem 215 weist im Allgemeinen Code zum Verwalten und Bereitstellen von Diensten für Hardware- und Softwarekomponenten in der Einheit 200 auf, um eine Programmausführung zu ermöglichen. Neben anderem Code und anderen Befehlen beinhaltet das Betriebssystem 215 einen Prozessverwaltungscode 232, der Befehle aufweist, um eine Schnittstelle zwischen Anwendungscode und Systemhardware und -software herzustellen. Das Betriebssystem 215 beinhaltet des Weiteren einen Arbeitsspeicher-Verwaltungscode 234, um Arbeitsspeicher zuzuordnen und zu verwalten, der durch die Programme auf Anwendungs- und Systemebene verwendet wird. Das Betriebssystem 215 beinhaltet des Weiteren einen E/A-Systemverwaltungscode 236 mit Einheitentreibern, welche die Hardware des Systems in die Lage versetzen, mit externen Computersystemen Daten auszutauschen.
  • In der dargestellten Ausführungsform wird in entsprechenden Anwendungsarbeitsspeicher-Bereichen 217 und 219 ein Paar von Transaktionsressourcenanwendungen 206 und 208 gespeichert. Die Transaktionsressourcenanwendungen 206 und 208 enthalten jeweils Programmbefehle und Daten, die einem entsprechenden Transaktionsressourcenkonto zugehörig sind. So kann die Transaktionsressourcenanwendung 206 eine Benutzeranwendung sein, die Programmbefehle und Daten enthält, welche einem universell nutzbaren (d.h. „offenen“) Guthabenkonto zugehörig sind, während die Transaktionsressourcenanwendung 208 eine Benutzeranwendung sein kann, die Programmbefehle und Daten enthält, welche einem auf einen angegebenen Einzelanbieter beschränkten (d.h. „geschlossenen“) Guthabenkonto zugehörig sein können. Die Transaktionsressourcenanwendungen 206 und 208 dienen dazu, ein Verarbeiten und Abrufen von Transaktionskontodaten wie z.B. Transaktionstauschwerte (z.B. Geld-Guthabenwerte) zu ermöglichen, die von einem oder mehreren Konten verfügbar sind. Darüber hinaus dienen die Transaktionsressourcenanwendungen 206 und 208 dazu, Transaktionstoken, die für Diensttransaktionen z.B. mit einem POS-System genutzt werden können, anzufordern/abzurufen und zu verarbeiten. Bei der dargestellten Ausführungsform beinhaltet jede der Transaktionsressourcenanwendungen 206 und 208 Befehle und Daten, mit denen sie anhand der Verarbeitungs- und Netzwerkübertragungskomponenten in der Einheit 200 Transaktionstoken anfordern und/oder erzeugen können.
  • Ein Paar von Transaktionstoken, TOKEN_1 und TOKEN_2, wird in Verbindung mit der Transaktionsressourcenanwendung 206 gespeichert, während ein Token TOKEN_3 in Verbindung mit der Transaktionsressourcenanwendung 208 gespeichert wird. Die Transaktionstoken TOKEN_1, TOKEN_2 und TOKEN_3 können von einem oder mehreren Ressourcenkontomanagern wie z.B. dem Kontomanager 106 aus 1 angefordert worden sein, oder sie können lokal erzeugt worden sein. Die Token werden zum Verarbeiten von Verkaufstransaktionen verwendet, um in der Praxis z.B. als Ersatz für Kontodaten zu dienen, die andernfalls von einem POS-System benötigt würden, um ein Konto zu validieren und zu bestätigen, dass für eine gegebene Transaktion genügend Kontoressourcen verfügbar sind. Jedes Token beinhaltet eine Token-ID und einen Transaktionstauschwert. Die Token-ID kann eine pseudozufällig erzeugte Zahl oder ein alphanumerischer Code sein, die/der beim anfänglichen Erzeugen des Tokens zugewiesen und aufgezeichnet wird. Der Transaktionstauschwert ist üblicherweise ein numerischer Geldwert, der in bestimmten Tauscheinheiten angegeben wird. Wie mit Blick auf die 4 und 5 ausführlicher erläutert, beinhalten Token des Weiteren Bedingungs- oder Validierungsparameter bzw. sind diesen auf andere Art logisch zugeordnet, die durch eine beliebige Einheit bestehend aus einem Ressourcenkontomanager, einer Tokenübertragungseinheit wie der Einheit 200 oder einer anderen Vermittlereinheit codiert werden kann, welche die Token erhalten kann, um die Bedingungen zu beschränken, unter denen die Token bei Ressourcentransaktionen genutzt werden können,.
  • Die dargestellte Ausführungsform beinhaltet des Weiteren eine Tokenmanageranwendung 221, die in einem Anwendungsarbeitsspeicher-Bereich 220 gespeichert und aus diesem heraus ausgeführt wird. Der Tokenmanager 221 kann einige oder alle der tokenbezogenen Funktionen durchführen, die andernfalls den Transaktionsressourcenanwendungen 206 und 208 zugewiesen wären. Wie gezeigt, weist der Tokenmanager 221 einen Verwaltungscode 227 auf, der Befehle und Daten enthält, um die Zuordnung von Validierungsparameter zu Token zu ermöglichen, einschließlich einem Zuweisen, Ändern und/oder Entfernen von Validierungsparametern, wobei diese als TAGS_1, TAGS_2 und TAGS_3 dargestellt sind, die TOKEN_1, TOKEN_2 bzw. TOKEN_3 zugehörig sind. Der Tokenmanager 221 kann des Weiteren logische Zuordnungen zu den Tokenstrukturen TOKEN_1, TOKEN_2 und TOKEN_3 umfassen oder beinhalten.
  • Neben dem Tokenabruf und der Tokenverwaltung, die auf einer Anwendungsebene durch den Tokenmanager 221 und/oder die Transaktionsressourcenanwendungen 206 und 208 bereitgestellt werden, beinhaltet die Einheit 200 einen Code für die Tokenverwaltung auf Systemebene, der ein universelles Vorbereiten und Verarbeiten von Tokentransaktionen für Token mit anwendungsspezifischen Attributen ermöglicht. Im Besonderen beinhaltet der Systemarbeitsspeicher-Bereich 222 einen Tokenzustandsmanager 225, der mit dem Betriebssystem 215, dem Tokenmanager 221 und den Transaktionsressourcenanwendungen 206 und 208 zusammenwirkt, um Tokentransaktionen in Übereinstimmung mit Verarbeitungs- und Netzwerkumgebungsfaktoren sowie transaktionsspezifischen Bedingungen vorzubereiten/zu beschränken. Der Tokenzustandsmanager 225 verfügt über einen programmierten Zugriff auf einen Satz von einem oder mehreren Spezialregistern (Special Purpose Registers, SPRs) 224, 226 und 228, die vorgegebene Bedingungen und Parameter dazu speichern, ob und/oder in welchem Maße eine bestimmte Tokentransaktion verarbeitet werden kann. Wie mit Blick auf die 4 bis 8 ausführlicher erläutert, kann der Tokenzustandsmanager 225 die Vorbereitungs-/Parameterdaten in den SPRs 224, 226 und 228 in programmierten Kombinationen verarbeiten, die als „Ereignisse“ bezeichnet werden können. Bei einer Ausführungsform kann das SPR 224 eine Ressourcenverbindungsmarkierung speichern, die angibt, ob ein Netzwerkschnittstellenprogramm wie z.B. ein Webbrowser und/oder ein Client-seitiges Transaktionsressourcen-Anwendungsprogramm in der Einheit 200 mit einem bestimmten, entfernt angeordneten Ressourcenkonto-Schnittstellenprogramm aktiv kommunikativ verbunden ist. Das SPR 224 kann zudem eine Markierung speichern, die eine gegenwärtige Verbindung mit einer vorgegebenen Ressourcenkonto-Netzwerkschnittstelle wie z.B. einem Webdokument oder einer Webseite angibt, die einem bestimmten Benutzerkonto entspricht. Die SPRs 226 und 228 können Daten oder Einzelbitmarkierungen speichern, die der Tokenzustandsmanager 225 verwendet, um zu ermitteln, ob ein Transaktionsänderungsaufruf ausgegeben werden soll.
  • Wie mit Blick auf die 3 bis 8 ausführlicher erläutert, wird der Tokenzustandsmanager 225 während einer Transaktionsdienstanforderung aufgerufen und dient dazu, abhängig vom Verbindungsstatus der Einheit 200 und anderen durch die SPRs vorgegebenen Bedingungen zu ermitteln, ob ein Transaktionsänderungsaufruf ausgegeben werden soll. Bei einer Ausführungsform kann der Tokenzustandsmanager 225 ursprünglich durch eine Transaktionsdatenaustausch-Schnittstelle wie z.B. die NFC-Schnittstelle 211 und während einer Transaktionsdienstanforderung über das Betriebssystem 215 aufgerufen werden. Bei einer weiteren Ausführungsform kann der Tokenzustandsmanager 225 als Reaktion darauf, dass das Betriebssystem 215 eine Verarbeitung einer Diensttransaktionsanforderung durch die NFC-Schnittstelle 211 erkennt, direkt und ursprünglich durch das Betriebssystem 215 aufgerufen werden.
  • 3 ist eine Signalverarbeitungsdarstellung, die ein Tokenübertragungsprotokoll gemäß einer Ausführungsform veranschaulicht. Die an dem beispielhaften Tokenübertragungsprozess funktionell beteiligten Einheiten beinhalten einen Ressourcenkontoserver 306, eine Ressourcenschnittstelleneinheit 302, eine Tokenübertragungseinheit 304 und einen Tokenempfangsterminal 308. Der Ressourcenkontoserver 306 beinhaltet Hardware und Software zum Verwalten von Ressourcenkonten und zum Verarbeiten von Transaktionen Dritter. Die Ressourcenschnittstelleneinheit 302 ist eine netzwerkfähige, tragbare elektronische Einheit wie z.B. ein Smartphone, die ein lokal gespeichertes Ressourcenkontoprogramm beinhaltet, das in Verbindung mit einem Netzwerkzugangsprogramm wie z.B. einem Webbrowser ausgeführt werden kann, um über ein Netzwerk kommunikativ auf den Ressourcenkontoserver 306 zuzugreifen. Die Tokenübertragungseinheit 304 ist eine tragbare elektronische Einheit, die netzwerkfähig sein kann und die mindestens eine direkte NFC-Schnittstelle beinhaltet, durch die sie mit einem Tokenempfangsterminal 308 und der Ressourcenschnittstelleneinheit 302 Daten austauschen kann.
  • Wie gezeigt, beginnt das Protokoll damit, dass die Ressourcenschnittstelleneinheit 302 ein Netzwerkzugangsprogramm 312 z.B. für einen Zugang über einen Webbrowser ausführt, gefolgt von einer Netzwerktransaktion 314, bei der die Ressourcenschnittstelle 302 ein Ressourcenkonto-Anwendungsprogramm installiert, das von dem Ressourcenserver 306 empfangen wird. Das lokal installierte Kontoressourcenprogramm ermöglicht der Ressourcenschnittstelleneinheit 302, auf Ressourcenkontodaten und -anforderungen zuzugreifen, sie zu ändern und sie an den und von dem Ressourcenserver 306 zu senden. Wie weiterhin dargestellt, sendet die Ressourcenschnittstelleneinheit 302 eine Tokenanforderungsnachricht 316 an den Ressourcenserver 306. Die Tokenanforderung 316 kann durch das lokal installierte Ressourcenkonto-Anwendungsprogramm erzeugt und über eine Netzwerkschnittstelle übertragen werden. Der Ressourcenserver 306 antwortet mit einer Tokensendenachricht 318, die mindestens ein Token und zugehörige Kontodaten beinhaltet. Die Ressourcenschnittstelleneinheit 302 speichert das/die Token in lokalem Speicher in Verbindung mit einer entsprechenden Ressourcenkontoanwendung und/oder in Verbindung mit einer separaten Tokenverwaltungsanwendung. Wenn der Ressourcenserver 306 zum Beispiel ein Token ausgibt, das als ein Transaktionselement für ein bestimmtes Kreditkartenkonto verwendet werden soll, kann die Ressourcenschnittstelleneinheit 302 das Token in lokalem Speicher und in Arbeitsspeicher speichern, der einer Ressourcenkontoanwendung zugeordnet ist, die dem Kreditkartenkonto entspricht.
  • Gemäß einem Aspekt der dargestellten Ausführungsform beinhaltet die Ressourcenschnittstelleneinheit 302 des Weiteren eine Tokenmanageranwendung wie den Tokenmanager 221 aus 2, mit dem Transaktionsbedingungs-Tags erzeugt werden können, die einen oder mehrere Validierungsparameter angeben und die Tags einem oder mehreren Token zuweisen. Die Ressourcenschnittstelleneinheit 302 kann die Token zugehörigen Tags während Ressourcentransaktionen auf Tokengrundlage wie beispielsweise mit dem Tokenempfangsterminal 308 verwenden, wie dies mit Blick auf die 5 bis 8 ausführlicher dargestellt und beschrieben wird. Wie in 3 gezeigt, werden die Token und zugehörigen Tags alternativ an die Tokenübertragungseinheit 304 gesendet (z.B. hochgeladen/heruntergeladen), bei der es sich um eine elektronische Wearable-Einheit wie die Einheit 120 aus 1 handeln kann. Die Tokenübertragungseinheit 304 beinhaltet eine NFC-Schnittstelle, die in Verbindung mit einer lokal gespeicherten Ressourcenkontoanwendung verwendet werden kann, um z.B. über eine Transaktionsanforderung 322, die von der Tokenübertragungseinheit 304 an den Tokenempfangsterminal 308 gesendet wird, eine Kontodiensttransaktion zu initiieren.
  • Während einer Phase der Transaktionseinrichtung, die mit der Transaktionsanforderung 322 beginnt, ruft die Tokenübertragungseinheit 304 einen Tokenzustandsmanager wie z.B. den Tokenzustandsmanager 225 aus 2 oder ruft diesen auf andere Art und Weise auf. Wie in 3 dargestellt, kann der Aufruf ein interner Betriebssystemaufruf 326 oder eine NFC-Nachricht 324 (z.B. über Bluetooth) sein, welche die Ressourcenschnittstelleneinheit 302 dazu auffordert, einen lokal gespeicherten Tokenzustandsmanager intern aufzurufen. Nach dem Aufruf und während eines Initialisierungsprotokolls 326, das eine von einem Client angeforderte Aussetzung beinhalten kann, verarbeitet der Tokenzustandsmanager die Token zugehörigen Tags in Verbindung mit System- und Transaktionsbedingungsdaten, die in System registern in der Tokenübertragungseinheit 304 und/oder der Ressourcenschnittstelleneinheit 302 gespeichert sein können. Der Tokenzustandsmanager ermittelt entweder lokal aus der Tokenübertragungseinheit 304 oder entfernt aus der Ressourcenschnittstelleneinheit 302 ein Transaktionsereignis aus der Tag-/Bedingungsverarbeitung und kann die Transaktion auf Grundlage von Transaktionsereignisregeln dann abbrechen, das Token ungültig machen oder das Token ändern, bevor er die Transaktion über eine Transaktionsnachricht 330 fortsetzt. Der Tokenempfangsterminal 308 antwortet auf den Empfang eines geänderten oder aber nicht geänderten Tokens, indem er eine Kontoberechtigungsanforderung 332 an den Ressourcenserver 306 sendet.
  • 4A ist eine konzeptionelle Darstellung, die ein Tokenkonstrukt gemäß einer Ausführungsform veranschaulicht. Das dargestellte Tokenkonstrukt beinhaltet ein Token 400, das durch ein Ressourcenkontoprogramm, welches in einem Ressourcenserver gespeichert ist, oder durch ein Ressourcenkontoprogramm, welches in einer tragbaren elektronischen Einheit gespeichert ist, erzeugt werden kann. Das Token 400 beinhaltet ein Token-ID-Feld 405, das einen pseudozufällig erzeugten numerischen oder alphanumerischen Code enthält, der dazu dient, das Token z.B. durch einen Tokenempfangsterminal zu identifizieren, der die Token-ID an einen Ressourcenkontomanager sendet, welcher die Token-ID mit zentral gespeicherten Kontodaten abgleichen kann. Das Token 400 beinhaltet des Weiteren ein Gesamtwertfeld 406 und ein Feld 408 für eine Beschränkung des Werts pro Transaktion. Das Gesamtwertfeld 406 gibt eine Anzahl von Ressourcenwerteinheiten (z.B. eine Anzahl von US-Dollar) an, die als ein Gesamtguthabenwert dem Token 400 zugewiesen und über Ressourcentransaktionen (z.B. POS-Transaktionen) nutzbar sind. Das Transaktionsbeschränkungsfeld 408 gibt die maximale Anzahl von Ressourceneinheiten an, die bei einer beliebigen einzelnen Ressourcentransaktion verwendet werden dürfen.
  • Wie weiterhin dargestellt, ist ein Satz von Validierungsparametern 404 dem Token 400 logisch zugeordnet. Die Zuordnung eines oder mehrerer Validierungsparameter zu dem Token 400 kann durch eine lokal gespeicherte Ressourcenkontoanwendung oder einen Tokenmanager realisiert werden, wobei Nutzungs-Tags erzeugt werden, welche den/die Validierungsparameter angeben. Die Zuordnung kann erfolgen, indem der Wert des Validierungsparameters in den vorab festgelegten Feldern in eine Tokendatenstruktur eingefügt wird oder indem eine Tag-Datenstruktur, welche die betreffenden Validierungsparameterfelder enthält, mit den Tokendatenstrukturen verkettet wird. Alternativ können die Datenstruktur mit dem Token 400 und die Datenstruktur mit den Validierungsparametern 404 in getrennt benannten und gespeicherten Datenstrukturen verwaltet werden, die auf andere Art und Weise mit Hilfe eines Programms zugeordnet sind, wie z.B. über das Ressourcenkonto-Anwendungsprogramm. Wie mit Blick auf 4B in Verbindung mit 4A ausführlicher gezeigt, beinhalten die Validierungsparameter 404 eine Markierung 410 für die Tokenvalidierung/-annullierung, ein Feld 412 für eine Ressourcenverbindungsannullierung (Resource Connect Invalidate, RCI) und ein Feld 414 für eine Ressourcentrennungs-Annullierungsbedingung (Resource Disconnect Invalidate, RDI). Die Validierungsmarkierung 410 ist üblicherweise eine Einzelbitmarkierung, die durch eine Benutzereingabe in der Ressourcenkontoanwendung oder durch die Funktion eines lokal gespeicherten und ausgeführten Tokenmanagers oder Tokenzustandsmanagers zugesichert und/oder deren Zusicherung aufgehoben werden kann.
  • Das RCI-Feld 412 enthält Daten, die einen oder mehrere bestimmte Umgebungs- oder Transaktionsparameter angeben, die dann verarbeitet werden, wenn ermittelt wird, dass die Host-Tokenübertragungseinheit gegenwärtig (d.h. in Echtzeit) mit einem entfernt angeordneten Ressourcenkontoserver oder einem durch den Ressourcenserver ausgeführten Kontoschnittstellenprogramm kommunikativ verbunden ist. Das veranschaulichte RCI-Feld 412 beinhaltet ein Teilfeld GEO_NOT_US 420 und ein Teilfeld RT_NOT_AUTH 422. Das Teilfeld GEO_NOT_US 420 gibt an, ob sich die Host-Tokenübertragungseinheiten gegenwärtig innerhalb der geografischen Grenzen der Vereinigten Staaten von Amerika befinden, wie dies durch die globale Positionsbestimmungsfunktionalität (GPS-Funktionalität) der Einheit ermittelt werden kann. Das Teilfeld RT_NOT_AUTH 422 gibt einen Ressourcentransaktionstyp (z.B. eine Transaktion, die eine sofortige Berechtigungsprüfung des Empfangsterminals erfordert) oder ein anderes Transaktionsmerkmal (z.B. eine Transaktion, die einen bestimmten Produkttyp beinhaltet) an, für den/das keine Berechtigung zum Verwenden des Tokens vorliegt.
  • Das RDI-Feld 414 enthält Daten, die einen oder mehrere bestimmte Umgebungs- oder Transaktionsparameter angeben, die dann verarbeitet werden, wenn ermittelt wird, dass die Host-Tokenübertragungseinheit gegenwärtig (d.h. in Echtzeit) nicht mit einem entfernt angeordneten Ressourcenkontoserver oder einem durch den Ressourcenserver ausgeführten Kontoschnittstellenprogramm kommunikativ verbunden ist. Das dargestellte RDI-Feld 414 beinhaltet ein Teilfeld GEO_NOT_NYC 424 und ein Teilfeld RT_NOT_AUTH 426. Das Teilfeld GEO_NOT_NYC 424 gibt an, ob sich die Host-Tokenübertragungseinheiten gegenwärtig innerhalb der geografischen Grenzen einer Stadt wie z.B. New York befinden, wie durch die GPS-Funktionalität ermittelt werden kann. Das Teilfeld RT_NOT_AUTH 426 gibt einen Ressourcentransaktionstyp (z.B. eine Transaktion, die eine sofortige Berechtigungsprüfung des Empfangsterminals erfordert) oder ein anderes Transaktionsmerkmal (z.B. eine Transaktion, die einen bestimmten Produkttyp beinhaltet) an, für den/das keine Berechtigung zum Verwenden des Tokens vorliegt.
  • Wie mit Blick auf die 5 bis 8 ausführlicher erläutert, wählt ein Tokenzustandsmanager die in dem RCI-Feld 412 enthaltenen Parameter 420 und 422 oder die in dem RDI-Feld 414 enthaltenen Parameter 424 und 426 als überschreibende Validierungsparameter aus, um mit ihnen zu ermitteln, ob ein Tokenstatus (z.B. Token annullieren) geändert und/oder ob eine initiierte Transaktionsfolge abgebrochen werden soll. Gemäß einem Aspekt der dargestellten Ausführungsformen beruht die Auswahl auf einer Echtzeitermittlung, ob die Host-Tokenübertragungseinheit zum gegenwärtigen Zeitpunkt über ein Netzwerk mit einem Ressourcenkontoprogramm kommunikativ verbunden ist, das dem Ressourcenkonto entspricht, von dem das Token ausgegeben wurde.
  • 5 ist eine konzeptionelle Darstellung einer Transaktionsereignistabelle 500 gemäß einer Ausführungsform. Wie mit Blick auf die 6 bis 8 ausführlicher erläutert, kann ein Tokenzustandsmanager während einer Ressourcentransaktion auf die Ereignistabelle 500 zugreifen, um die Transaktion zu ändern und/oder um das/die betreffende/n Token zu ändern, das/die während der Transaktion genutzt werden kann/können. Die Ereignistabelle 500 beinhaltet Tokenparameter- und Ereignisbedingungswerte, die in Spalten logisch zusammengefasst und innerhalb jeder Reihe logisch zugeordnet sind. Bei der dargestellten Ausführungsform beinhaltet die Ereignistabelle 500 Spalten mit der Bezeichnung PARAMETER, C_REG, REG_VAL, RCI_T1, RDI_T1, RCI_T2 und RDI_T2. Die Felder in der Spalte C_REG geben die Identität einzelner Systemregister an, und die Felder in der benachbarten Spalte REG_VALUE geben Werte an, die in den betreffenden Systemregistern aufgezeichnet werden, z.B. in den SPRs 224, 226 und 228 aus 2. Die Felder in der Spalte RCI_T1 geben Werte an, die als Nutzungsparameter für ein erzeugtes Token_1 eingegeben werden und die anzuwenden sind, wenn ermittelt wurde, dass die Host-Tokenübertragungseinheit mit einer Ressourcenkonto-Netzwerkschnittstelle kommunikativ verbunden ist. Die Felder in der Spalte RDI_T1 geben Werte an, die als Nutzungsparameter für dasselbe Token_1 eingegeben werden und die anzuwenden sind, wenn entweder nicht ermittelt wurde, dass die Host-Tokenübertragungseinheit mit einer Ressourcenkonto-Netzwerkschnittstelle kommunikativ verbunden ist, oder wenn sich herausgestellt hat, dass sie nicht mit der Schnittstelle verbunden ist.
  • Die Spalte PARAMETER beinhaltet mehrere durch eine Anwendung oder ein System änderbare Felder, welche die Arten/Kategorien von Parametern angeben, während entsprechende Bedingungen als Systembedingungen oder vordefinierte, erforderliche Grenzwerte in den entsprechenden Zeilen aufgezeichnet werden. Die dargestellte Spalte PARAMETER gibt als Bedingungsparameter einen Transaktionsressourcenwert MAX_INCREMENT, einen geografischen Standort GEO, eine NFC-Lesegerät-Berechtigungsebene AUTHEN_NFC_ID und eine Körperkontakt-Validierungs-/Annullierungsbedingung BC/BCI an. Wie veranschaulicht, beinhaltet die Zeile MAX_ INCREMENT Felder, die vordefinierte Grenzwerte für den maximalen Ressourcenwert pro Transaktion für die Token T1 und T2 wie z.B. RCI_T1 (500 Einheiten), RDI_T1 (25 Einheiten) und RDI_T2 (20 Einheiten) angeben und die in der Ereignistabelle 500 gespeichert werden, nachdem die entsprechenden Validierungsparameter, die den Token T1 und T2 zugehörig sind, verarbeitet wurden. Die Zeile GEO beinhaltet ein Feld, laut dem ein Bedingungsregister CR_2 einen Bezeichner für einen gegenwärtigen geografischen Standort (LOCAL oder REMOTE) der Host-Tokenübertragungseinheit enthält, und zugehörige Felder, die LOCAL/REMOTE als Transaktionsbeschränkungsparameter für die Token T1 und T2 angeben. Die Zeile AUTHEN_NFC_ID beinhaltet ein Feld, laut dem das Bedingungsregister CR_3 eine NFC-Lesegerät-Berechtigungsebene (der Ebenen LEVEL 1 bis 3) enthält, und zugehörige Felder, die angeben, dass das Token T1 eine Lesegerät-Berechtigung LEVEL 3 benötigt, wenn die Host-Einheit (gemäß Eintrag RCI_T1) verbunden ist, dass es jedoch eine höhere Ebene, LEVEL 2, benötigt, wenn die Einheit (gemäß Eintrag RD_T1) nicht verbunden ist. Entsprechend geben die Validierungsparametereinträge RCI_T2 und RDI_T2 für die Zeile AUTHEN_NFC_ID an, dass für eine Transaktion von Token T2 in der verbundenen Betriebsart eine LEVEL_2-Berechtigung und für eine Transaktion von Token T2 in der nicht verbundenen Betriebsart eine LEVEL_1-Berechtigung notwendig ist. Die Zeile BC/BCI kann in einer Transaktionsereignistabelle für Token enthalten sein, die durch eine elektronische Wearable-Einheit wie z.B. die Einheit 120 übertragen werden, welche mit Blick auf 1 dargestellt und beschrieben wird. Die veranschaulichte Zeile BC/BCI beinhaltet ein Feld C_REG, laut dem das Bedingungsregister CR_4 eine Markierung enthält, die angibt, ob die am Körper tragbare Host-Tokenübertragungseinheit zu diesem Zeitpunkt feststellt, dass sie eine wie auch immer geartete Form von physischem Kontakt mit oder in der Nähe zu einem Benutzer (z.B. Träger) der Einheit aufweist. Die Zeile BC/BCI beinhaltet des Weiteren Felder, die angeben, dass für ein Übertragen von Token T1 oder T2 (gemäß Markierung BC) ein Körperkontakt notwendig ist, wenn die Host-Einheit gegenwärtig nicht mit einer Ressourcenschnittstelle verbunden ist.
  • 6 ist ein allgemeiner Ablaufplan, der Schritte und Funktionen zum Konfigurieren einer Tokenübertragungseinheit veranschaulicht, um gemäß einer Ausführungsform Tokentransaktionen zu verarbeiten. Wie in den Schritten 602 und 604 gezeigt, beginnt der Prozess damit, dass eine Tokenübertragungseinheit oder eine Ressourcenschnittstelleneinheit ein oder mehrere Token anfordert. Bei einer Ausführungsform wird die Anforderung von einer Ressourcenschnittstelleneinheit, die auch eine Tokenübertragungsfunktionalität beinhalten kann, an eine Ressourcenkontomanager-Schnittstelle übertragen. Bei einer weiteren Ausführungsform stammt die Anforderung von einer Tokenübertragungseinheit wie z.B. einer elektronischen Wearable-Einheit, die zwar keinen Netzwerkzugang aufweist, jedoch über eine NFC-Schnittstelle wie Bluetooth verfügt. Bei dieser Ausführungsform wird die Anforderung durch die Wearable-Einheit an eine in der Nähe befindliche Partner-Einheit wie z.B. ein netzwerkfähiges Smartphone gesendet. Wie in Schritt 604 gezeigt, gibt die Anforderung üblicherweise einen Transaktionstauschwert in Geld- oder anderen Guthabenwerteinheiten an.
  • Wie in den Schritten 606 und 608 dargestellt, werden als Reaktion auf die Anforderung ein oder mehrere Token von einem Tokenausgabesystem wie z.B. einem Ressourcenkonto-Verwaltungssystem empfangen und Validierungsparameter wie z.B. den in den 4 und 5 dargestellten Parametern zugewiesen. Die Validierungsparameter können durch eine Benutzerinteraktion mit einer Tokenressourcenmanager-Anwendung oder einem Tokenzustandsmanager auf Systemebene zugewiesen werden. Der Prozess fährt wie in Schritt 610 gezeigt fort, indem ermittelt wird, ob die Host-Einheit, welche die Token empfangen hat, eine lokal gespeicherte Transaktionsressourcenanwendung beinhaltet, in der die zugrundeliegenden Tokenwerte erzeugt wurden. Die Ressourcenanwendung kann zum Beispiel eine proprietäre Kreditkartenanwendung sein, um Kontodaten für ein Konto lokal zu verwenden, aus denen die Token erzeugt wurden. Bei einem positiven Ermittlungsergebnis werden die empfangenen Token mit einer logischen Zuordnung zu den zugewiesenen Validierungsparametern in dem Anwendungsarbeitsspeicher-Bereich gespeichert, welcher der Ressourcenanwendung zugeordnet wurde (Schritt 612). Unabhängig davon, ob die Token in Verbindung mit lokalen Ressourcenkontoanwendungen gespeichert werden, ermittelt ein Tokenzustandsmanager Bedingungen, die den zugewiesenen Validierungsparametern entsprechen (Schritt 614) und lädt die Token zugehörigen Parameter in Verbindung mit den Systembedingungsregistern (Schritt 615) auf eine Art und Weise, dass der Tokenzustandsmanager daraufhin die geladenen Parameterwerte mit entsprechenden Bedingungswerten wie z.B. denjenigen Werten vergleichen kann, die in der Ereignistabelle 500 aus 5 dargestellt sind. Wie in den Schritten 616 und 618 dargestellt, wird die Tokenkonfiguration beendet, indem der Tokenzustandsmanager Unterbrechungsbedingungen setzt, die Transaktionsereignisregeln entsprechen, deren Verwendung mit Blick auf die 7 und 8 ausführlicher beschrieben wird.
  • 7 ist ein allgemeiner Ablaufplan, der Schritte darstellt, die zum Verarbeiten einer Tokentransaktion gemäß einer Ausführungsform durchgeführt werden. Wie in den Schritten 702 und 704 gezeigt, beginnt der Prozess damit, dass eine Tokenmanageranwendung Validierungsparameter-Tags einem Token zuweist und zuordnet. Zwischen den einzelnen Tokentransaktionen fungiert ein Tokenzustandsmanager als ein kontinuierlicher Hintergrundprozess, um in regelmäßigen Abständen Ereignisbedingungsregister wie z.B. die Register CR_2, CR_3 und CR_4 aus 5 zu aktualisieren (Schritte 706, 708 und 710). Wie in den Schritten 706, 712 und 714 dargestellt, werden als Reaktion auf oder in Verbindung mit einer Transaktionsdienstanforderung von der Host-Tokenübertragungseinheit ein Tokenzustandsmanager und/oder ein Tokenmanager auf Anwendungsebene aufgerufen bzw. anderweitig aktiviert. Der Tokenzustandsmanager greift - gegebenenfalls in Abstimmung mit der Tokenmanageranwendung - auf die Token zugehörigen Validierungsparameter zu und liest diese (Schritt 716). Bei einer Ausführungsform greifen der Tokenzustandsmanager und/oder der Tokenmanager auf Anwendungsebene auf die Token zugehörigen Tags zu, um die betreffenden Validierungsparameter zu lesen. Bei einer weiteren Ausführungsform greift der Tokenzustandsmanager aus einer Bedingungstabelle, die wie in 5 und 6 dargestellt und beschrieben konfiguriert ist, auf die Validierungsparameter zu und liest diese.
  • Der Prozess fährt wie in Schritt 718 gezeigt fort, indem der Tokenzustandsmanager ermittelt, ob die Host-Tokenübertragungseinheit gegenwärtig mit einer Ressourcenkonto-Netzwerkschnittstelle kommunikativ verbunden ist. Die Ressourcenkonto-Netzwerkschnittstelle kann eine mit Blick auf die 1 und 2 beschriebene Schnittstelle und im Besonderen ein Internet-Webdokument mit einem einheitlichen Ressourcenbezeichner (Universal Resource Identifier, URI) sein, auf den über ein Kennwort zugegriffen werden kann. Die Ermittlung, ob die Host-Tokenübertragungseinheit verbunden ist, kann ein Lesen eines Systemregisters wie z.B. des SPR 224 aus 2 aufweisen. Als Reaktion auf die Ermittlung, dass die Tokenübertragungseinheit gegenwärtig mit einer Ressourcenkonto-Netzwerkschnittstelle kommunikativ verbunden ist, liest der Tokenzustandsmanager die Validierungsparameter, die auf eine Verbindungsbedingung der Host-Einheit (Schritt 720) anwendbar sind. Wenn in Schritt 718 ermittelt wird, dass die Host-Einheit mit der Ressourcenkonto-Netzwerkschnittstelle gegenwärtig nicht verbunden ist, liest der Tokenzustandsmanager die Validierungsparameter, die auf eine Trennungsbedingung der Host-Einheit anwendbar sind, und wendet diese an (Schritt 722). Wenn ermittelt wird, dass die Host-Einheit mit der Ressourcenkonto-Netzwerkschnittstelle verbunden ist, greift der Tokenzustandsmanager, wie in Schritt 724 gezeigt, auf Bedingungsregisterdaten, die einer Verbindungsbedingung entsprechen, zu und liest sie, oder er liest Bedingungsregisterdaten, die einer Trennungsbedingung entsprechen, wenn ermittelt wird, dass die Host-Einheit mit der Ressourcenkonto-Netzwerkschnittstelle verbunden ist. Bei einer Ausführungsform wird aus einer Bedingungstabelle, die wie in 5 und 6 dargestellt und beschrieben konfiguriert ist, auf die Bedingungsregisterdaten zugegriffen.
  • Um zu ermitteln, ob die Transaktion und/oder das Token geändert werden sollen, vergleicht der Tokenzustandsmanager die Bedingungsregisterdaten mit den entsprechenden Validierungsparametern für eine Host-Verbindung oder den Validierungsparametern für eine Host-Trennung (Schritt 725) und wendet Transaktionsereignisregeln an. Die Transaktionsereignisregeln können Programmbefehle in dem Tokenzustandsmanager aufweisen, die zum Beispiel auf Grundlage von Beziehungen zwischen Feldern einer gegebenen Zeile in der Ereignistabelle 500 aus 5 Transaktions- oder Tokenänderungen veranlassen. So kann eine Transaktionsereignisregel zum Beispiel als Reaktion darauf, dass ein in dem Feld RDI_T1 angegebener Wert MAX_INCREMENT kleiner als ein Transaktionshöchstwert ist, der als Teil des ursprünglich ausgegebenen Tokens angegeben wurde, Befehle aufweisen, die festlegen, dass ein Tokenänderungsaufruf ausgegeben wird, um einen Transaktionshöchstwert zu verringern. In einem weiteren Beispiel kann eine Transaktionsereignisregel Befehle aufweisen, die angeben, dass als Reaktion darauf, dass gegenwärtig eine Kein-Körperkontakt-Bedingung gegeben ist und dass der entsprechende Validierungsparameter eine Körperkontaktanforderung vorgibt, ein Transaktionsabbruch ausgegeben wird. Danach ermittelt der Tokenzustandsmanager auf Grundlage eines Anwendens von Ereignisregeln auf die verglichenen Validierungsparameter und Bedingungsregisterdaten die Transaktionsänderungen und gibt diese aus (Schritt 726), und der Prozess endet (Schritt 728).
  • 8 ist ein Ablaufplan, der Schritte darstellt, die durch einen Tokenzustandsmanager während einer Tokentransaktion gemäß einer Ausführungsform durchgeführt werden. Wie in den Schritten 802 und 804 gezeigt, beginnt der Prozess damit, dass der Tokenzustandsmanager die Bedingungsregisterdaten mit Validierungsparametern verarbeitet, die über Tags oder eine andere logische Zuordnung einem Token zugeordnet wurden. Der Tokenzustandsmanager wendet die Validierungsparameter als Verbindungsereignis- oder Trennungsereignisregeln (RCI- oder RDI-Regeln) an. Der Tokenzustandsmanager annulliert das Token, indem er z.B. die Zusicherung des Parameters VALID 410 aus 4 aufhebt, wenn die auf die entsprechende Ereignisbedingung angewendete resultierende Regel ein Tokenannullierungsereignis anzeigt (Schritte 806 und 808). Das Transaktionsereignis, das ermittelt wird, indem die RCI- oder RDI-Regeln auf die Ereignisbedingungen angewendet werden, kann alternativ ein Tokenänderungsereignis sein, auf das der Tokenzustandsmanager reagiert, indem er das Token über einen Tokenänderungsaufruf entsprechend ändert (z.B. den Tokenwert verringert) (Schritte 810 und 812). Andere an der Transaktion beteiligte Token werden auf ähnliche Art und Weise durch den Tokenzustandsmanager verarbeitet, bis die Transaktion wieder fortgesetzt und abgeschlossen werden kann (Schritte 814, 816 und 818).
  • 9 zeigt ein beispielhaftes Computersystem, das eine Tokenzustandsmanager-Einheit 910 beinhaltet. Das Computersystem beinhaltet einen Prozessor 902 (möglicherweise mit mehreren Prozessoren, mehreren Kernen, mehreren Knoten und/oder unter Ausführung von Multithreading usw.). Das Computersystem beinhaltet einen Arbeitsspeicher 904, der ein Systemarbeitsspeicher (z.B. ein oder mehrere Cachespeicher, ein SRAM, ein DRAM, ein RAM ohne Kondensator (Zero Capacitor RAM, Z-RAM), ein RAM mit zwei Transistoren (Twin Transistor RAM, TT-RAM), ein eDRAM, ein EDO-RAM, ein DDR-RAM, ein EEPROM, ein NRAM, ein RRAM, ein SONOS, ein PRAM usw.) oder eine einzelne bzw. mehrere der weiter oben beschriebenen möglichen Realisierungen von maschinenlesbaren Medien sein kann. Das Computersystem beinhaltet zudem eine Verbindungseinheit 905 (z.B. PCI, ISA, PCI-Express, HyperTransport®, InfiniBand®, NuBus usw.), eine Netzwerkschnittstelle 906 (z.B. eine Ethernet-Schnittstelle, eine Frame-Relay-Schnittstelle, eine SONET-Schnittstelle, eine drahtlose Schnittstelle usw.) und eine oder mehrere Speichereinheiten 908 (z.B. einen optischen, Speicher, einen magnetischen Speicher usw.). Die Tokenzustandsmanager-Einheit 910 beinhaltet eine Funktionalität zum Realisieren von Merkmalen, die weiter oben mit Blick auf die 1 bis 8 beschrieben wurden. Die Tokenzustandsmanager-Einheit 910 kann Operationen zum Konfigurieren von Token und Token zugehörigen Validierungsparametern durchführen. Die Tokenzustandsmanager-Einheit 910 kann Anwendungs- und Systemverwaltungsoperationen durchführen, darunter ein Verarbeiten von Tokentransaktionen in Abhängigkeit davon, ob das Computersystem mit einer Ressourcenkonto-Netzwerkschnittstelle verbunden ist. Jede dieser Funktionalitäten kann teilweise (oder vollständig) in Hardware und/oder in dem Prozessor 902 ausgeführt werden. So kann die Funktionalität zum Beispiel mit einer anwendungsspezifischen integrierten Schaltung, in Logik in dem Prozessor 902, in einem Coprozessor auf einer Peripherie-Einheit oder -Karte usw. realisiert sein. Des Weiteren können Realisierungen weniger Komponenten oder zusätzliche, in 9 nicht veranschaulichte Komponenten beinhalten (z.B. zusätzliche Netzwerkschnittstellen, Peripherie-Einheiten usw.).
  • Der Fachmann weiß, dass Aspekte des vorliegenden Erfindungsgegenstands als ein System, Verfahren oder Computerprogrammprodukt ausgeführt werden können. Entsprechend können Aspekte des vorliegenden Erfindungsgegenstands in Gestalt einer vollständig in Hardware realisierten Ausführungsform, einer vollständig in Software realisierten Ausführungsform (z.B. Firmware, residente Software, Mikrocode usw.) oder in Gestalt einer Ausführungsform vorliegen, die Software- und Hardware-Aspekte vereint, welche zusammenfassend als ein „Modul“ oder „System“ bezeichnet werden können. Zudem können Aspekte des vorliegenden Erfindungsgegenstands in Gestalt eines Computerprogrammprodukts vorliegen, das in einem oder mehreren computerlesbaren Medien ausgeführt ist, auf denen computerlesbarer Programmcode enthalten ist.
  • Dabei kann eine beliebige Kombination aus einem oder mehreren computerlesbaren Medien genutzt werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann z.B. ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem bzw. eine entsprechende Vorrichtung oder Einheit oder aber eine beliebige geeignete Kombination der vorgenannten Elemente sein, ohne jedoch auf diese beschränkt zu sein. Konkretere Beispiele des computerlesbaren Speichermediums würden Folgendes beinhalten (wobei dies eine nicht vollständige Liste darstellt): eine elektrische Verbindung mit einem oder mehreren Leitern, eine tragbare Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), einen löschbaren, programmierbaren Nur-LeseSpeicher (EPROM- oder Flash-Speicher), einen Lichtwellenleiter, einen tragbaren Compact-Disc-Festwertspeicher (CD-ROM), eine optische Speichereinheit, eine magnetische Speichereinheit oder eine beliebige geeignete Kombination der vorgenannten Elemente. In Verbindung mit diesem Dokument kann ein computerlesbares Speichermedium jedes physische Medium sein, das ein Programm enthalten oder speichern kann, welches von oder in Zusammenhang mit einem der Befehlsausführung dienenden System, einer Vorrichtung oder Einheit verwendet wird.
  • Ein computerlesbares Signalmedium kann ein weitergeleitetes Datensignal mit darin enthaltenem computerlesbarem Programmcode enthalten, z.B. als Basisband oder als Teil einer Trägerwelle. Ein derartiges weitergeleitetes Signal kann eine beliebige Vielfalt von unterschiedlichen Formen annehmen, einschließlich, ohne auf diese beschränkt zu sein, eine elektromagnetische Form, eine optische Form oder auch jede geeignete Kombination derselben. Ein computerlesbares Signalmedium kann ein beliebiges computerlesbares Medium sein, das kein computerlesbares Speichermedium ist und das ein Programm übermitteln, weiterleiten oder übertragen kann, welches für die Nutzung durch oder in Verbindung mit einem/einer der Befehlsausführung dienenden System, Vorrichtung oder Einheit vorgesehen ist.
  • Auf einem computerlesbaren Medium enthaltener Programmcode kann unter Verwendung eines beliebigen geeigneten Mediums übertragen werden, einschließlich, ohne auf diese beschränkt zu sein, drahtlose, drahtgebundene, Lichtwellenleiterkabel-, HF- und andere Medien oder eine beliebige Kombination derselben.
  • Computerprogrammcode für das Ausführen von Arbeitsschritten für Aspekte des vorliegenden Erfindungsgegenstands kann in einer beliebigen Kombination von einer oder mehreren Programmiersprachen geschrieben sein, unter anderem eine objektorientierte Programmiersprache wie Java, Smalltalk, C++ oder ähnliche sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Der Programmcode kann vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder aber vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. Im letztgenannten Szenario kann der entfernt angeordnete Computer über eine beliebige Art von Netzwerk, unter anderem ein LAN oder ein WAN, mit dem Computer des Benutzers verbunden sein, oder die Verbindung kann mit einem externen Computer (z.B. über das Internet unter Verwendung eines Internet-Dienstanbieters) hergestellt werden.
  • Aspekte des vorliegenden Erfindungsgegenstands werden unter Bezugnahme auf Darstellungen von Ablaufplänen und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen des vorliegenden Erfindungsgegenstands beschrieben. Dabei dürfte klar sein, dass jeder Block der Ablaufplan-Darstellungen und/oder Blockschaubilder sowie Kombinationen von Blöcken in den Ablaufplan-Darstellungen und/oder Blockschaubildern durch Computerprogrammbefehle realisiert werden kann/können. Diese Computerprogrammbefehle können einem Prozessor eines Universalcomputers, Spezialcomputers oder einer anderweitigen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die Befehle, die über den Prozessor des Computers oder der anderweitigen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, ein Mittel erzeugen, mit dem die Funktionen/Handlungen realisiert werden können, die in dem Block bzw. den Blöcken des Ablaufplans und/oder Blockschaubilds angegeben werden.
  • Diese Computerprogrammbefehle können auch auf einem computerlesbaren Medium gespeichert werden, das einen Computer, eine anderweitige programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten anweisen kann, auf eine bestimmte Art und Weise zu funktionieren, so dass die auf dem computerlesbaren Medium gespeicherten Befehle einen Herstellungsgegenstand hervorbringen, der Befehle aufweist, mit denen die Funktion/Handlung, die in dem Block bzw. den Blöcken des Ablaufplans und/oder Blockschaubilds angegeben ist, realisiert wird.
  • Die Computerprogrammbefehle können zudem in einen Computer, eine anderweitige programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten geladen werden, um zu veranlassen, dass eine Reihe von Betriebsschritten auf dem Computer, der anderweitigen programmierbaren Datenvorrichtung oder den anderen Einheiten ausgeführt wird, so dass die Befehle, die auf dem Computer oder der anderweitigen Datenverarbeitungsvorrichtung ausgeführt werden, Prozesse bereitstellen, mit denen die in dem Block bzw. den Blöcken des Ablaufplans und/oder Blockschaubilds angegebenen Funktionen/Handlungen realisiert werden.

Claims (37)

  1. Verfahren zum Verarbeiten von Transaktionen in einer Tokenübertragungseinheit (200; 304), wobei das Verfahren aufweist: Speichern (318) eines Transaktionstokens (104; 400) mit einem vorgegebenen Transaktionsressourcenwert (402) und einem zugehörigen Validierungsparameter (404); Initiieren (322) eines Transaktionsdienstes mit einem Tokenempfangsterminal (308); Aufrufen (324, 326) eines Tokenzustandsmanagers (225) in Verbindung mit dem Initiieren eines Transaktionsdienstes; und wobei der Tokenzustandsmanager ein Ereignis ermittelt, das dem vorgegebenen Validierungsparameter entspricht, wobei das Ermitteln eines Ereignisses aufweist: Ermitteln eines Status der Verbindungsaktivität eines Ressourcenkontonetzwerks; und Ermitteln von Bedingungsregisterdaten, die dem Validierungsparameter zugehörig sind; und Ausgeben (330) eines Tokenänderungsaufrufs zum Ändern eines Tokens einer Transaktion, die ausgeführt werden soll, auf Grundlage des ermittelten Ereignisses und des Validierungsparameters.
  2. Verfahren nach Anspruch 1, wobei das Ermitteln eines Ereignisses des Weiteren ein Verarbeiten der Bedingungsregisterdaten mit einem Wert des Validierungsparameters aufweist.
  3. Verfahren nach Anspruch 2, wobei der Validierungsparameter einen ersten Wert beinhaltet, der einem Netzwerktrennungsstatus (414) der Tokenübertragungseinheit zugehörig ist.
  4. Verfahren nach Anspruch 3, wobei der Validierungsparameter des Weiteren einen zweiten Wert beinhaltet, der einem Netzwerkverbindungsstatus (412) der Tokenübertragungseinheit zugehörig ist.
  5. Verfahren nach Anspruch 3, wobei das Verarbeiten des Bedingungsregisterinhalts mit dem Wert des Validierungsparameters aufweist, den zu vergleichenden Wert des Validierungsparameters auf Grundlage dessen auszuwählen, ob die Tokenübertragungseinheit kommunikativ mit einer Ressourcenkonto-Netzwerkschnittstelle verbunden ist.
  6. Verfahren nach Anspruch 1, wobei das Initiieren eines Transaktionsdienstes ein Transaktionsstartprotokoll beginnt, aufweisend: Senden (322) einer Transaktionsdienstanforderung an den T okenem pfangsterm inal; Empfangen (328) einer Transaktionsantwort von dem Tokenempfangsterminal; und Aussetzen (326) des Transaktionsstartprotokolls bis zu dem Ausgeben eines Transaktionsänderungsaufrufs.
  7. Verfahren nach Anspruch 1, wobei der Validierungsparameter durch ein Tokenverwaltungsprogramm zugewiesen wird, das in der Tokenübertragungseinheit ausgeführt wird; und/oder wobei der Tokenzustandsmanager in einem Systemarbeitsspeicher-Bereich (222) der Tokenübertragungseinheit betrieben wird.
  8. Verfahren nach Anspruch 1, wobei der Tokenänderungsaufruf eine Verringerung des Transaktionsressourcenwerts (406, 408) aufweist.
  9. Verfahren nach Anspruch 1, wobei das Ausgeben eines Transaktionsänderungsaufrufs aufweist, dass der Tokenzustandsmanager direkt oder indirekt mit einer Ressourcenkontoanwendung Daten austauscht, um die Transaktionstoken zu aktivieren oder zu deaktivieren.
  10. Computerprogrammprodukt zum Verarbeiten von Transaktionen in einer Tokenübertragungseinheit (200; 304), wobei das Computerprogrammprodukt aufweist: ein computerlesbares Speichermedium, in dem computerlesbare Programmbefehle realisiert sind, wobei die computerlesbaren Programmbefehle konfiguriert sind, um ein Transaktionstoken (104; 400) mit einem vorgegebenen Transaktionsressourcenwert (402) und einem zugehörigen Validierungsparameter (404) zu speichern (318); einen Transaktionsdienst mit einem Tokenempfangsterminal (308) zu initiieren (322); einen Tokenzustandsmanager (225) in Verbindung mit dem Initiieren eines Transaktionsdienstes aufzurufen (324, 326); und wobei der Tokenzustandsmanager Programmbefehle aufweist, um ein Ereignis zu ermitteln, das dem vorgegebenen Validierungsparameter entspricht, wobei die Programmbefehle zum Ermitteln eines Ereignisses Programmbefehle aufweisen, um einen Status der Verbindungsaktivität eines Ressourcenkontonetzwerks zu ermitteln; und Bedingungsregisterdaten zu ermitteln, die dem Validierungsparameter zugehörig sind; und einen Tokenänderungsaufruf zum Ändern eines Tokens einer Transaktion, die ausgeführt werden soll, auf Grundlage des ermittelten Ereignisses und des Validierungsparameters auszugeben (330).
  11. Computerprogrammprodukt nach Anspruch 10, wobei die Programmbefehle zum Ermitteln eines Ereignisses des Weiteren Programmbefehle zum Verarbeiten der Bedingungsregisterdaten mit einem Wert des Validierungsparameters aufweisen.
  12. Computerprogrammprodukt nach Anspruch 11, wobei der Validierungsparameter einen ersten Wert beinhaltet, der einem Netzwerktrennungsstatus (414) der Tokenübertragungseinheit zugehörig ist.
  13. Computerprogrammprodukt nach Anspruch 12, wobei der Validierungsparameter des Weiteren einen zweiten Wert beinhaltet, der einem Netzwerkverbindungsstatus (412) der Tokenübertragungseinheit zugehörig ist.
  14. Computerprogrammprodukt nach Anspruch 12, wobei die Programmbefehle zum Verarbeiten des Bedingungsregisterinhalts mit dem Wert des Validierungsparameters Programmbefehle aufweisen, um den zu vergleichenden Wert des Validierungsparameters auf Grundlage dessen auszuwählen, ob die Tokenübertragungseinheit kommunikativ mit einer Ressourcenkonto-Netzwerkschnittstelle verbunden ist.
  15. Computerprogrammprodukt nach Anspruch 10, wobei die Programmbefehle zum Initiieren eines Transaktionsdienstes Programmbefehle aufweisen, um: eine Transaktionsdienstanforderung an den Tokenempfangsterminal zu senden (322), um ein Transaktionsstartprotokoll zu beginnen; eine Transaktionsantwort von dem Tokenempfangsterminal zu empfangen (328); und das Transaktionsstartprotokoll bis zu dem Ausgeben eines Transaktionsänderungsaufrufs auszusetzen (326).
  16. Computerprogrammprodukt nach Anspruch 10, wobei der Validierungsparameter durch ein Tokenverwaltungsprogramm zugewiesen wird, das in der Tokenübertragungseinheit ausgeführt wird.
  17. Computerprogrammprodukt nach Anspruch 10, wobei der Tokenzustandsmanager in einem Systemarbeitsspeicher-Bereich der Tokenübertragungseinheit betrieben wird.
  18. Computerprogrammprodukt nach Anspruch 10, wobei die Programmbefehle zum Ausgeben eines Transaktionsänderungsaufrufs Programmbefehle in dem Tokenzustandsmanager aufweisen, um direkt oder indirekt mit einer Ressourcenkontoanwendung Daten auszutauschen, um die Transaktionstoken zu aktivieren oder zu deaktivieren.
  19. Tokenübertragungseinheit (200; 304), aufweisend: einen Prozessor (204); und ein computerlesbares Speichermedium (210) mit darin enthaltenen Programmbefehlen, wobei die Programmbefehle durch den Prozessor ausführbar sind, um die Tokenübertragungseinheit zu veranlassen, ein Transaktionstoken (104; 400) mit einem vorgegebenen Transaktionsressourcenwert (402) und einem zugehörigen Validierungsparameter (404) zu speichern (318); einen Transaktionsdienst mit einem Tokenempfangsterminal (308) zu initiieren (322); einen Tokenzustandsmanager (225) in Verbindung mit dem Initiieren eines Transaktionsdienstes aufzurufen (324, 326); und wobei der Tokenzustandsmanager Programmbefehle aufweist, um ein Ereignis zu ermitteln, das dem vorgegebenen Validierungsparameter entspricht, wobei die Programmbefehle zum Ermitteln eines Ereignisses Programmbefehle aufweisen, um einen Status der Verbindungsaktivität eines Ressourcenkontonetzwerks zu ermitteln; und Bedingungsregisterdaten zu ermitteln, die dem Validierungsparameter zugehörig sind; und einen Tokenänderungsaufruf zum Ändern eines Tokens einer Transaktion, die ausgeführt werden soll, auf Grundlage des ermittelten Ereignisses und des Validierungsparameters auszugeben (330).
  20. Tokenübertragungseinheit nach Anspruch 19, wobei die Programmbefehle, mit denen die Tokenübertragungseinheit zum Ermitteln eines Ereignisses veranlasst wird, des Weiteren Programmbefehle zum Verarbeiten der Bedingungsregisterdaten mit einem Wert des Validierungsparameters aufweisen.
  21. Tokenübertragungseinheit nach Anspruch 20, wobei der Validierungsparameter einen ersten Wert beinhaltet, der einem Netzwerktrennungsstatus (414) der Tokenübertragungseinheit zugehörig ist.
  22. Tokenübertragungseinheit nach Anspruch 21, wobei der Validierungsparameter des Weiteren einen zweiten Wert beinhaltet, der einem Netzwerkverbindungsstatus (412) der Tokenübertragungseinheit zugehörig ist.
  23. Tokenübertragungseinheit nach Anspruch 21, wobei die Programmbefehle, mit denen die Tokenübertragungseinheit zum Verarbeiten des Bedingungsregisterinhalts mit dem Wert des Validierungsparameters veranlasst wird, Programmbefehle aufweisen, um den zu vergleichenden Wert des Validierungsparameters auf Grundlage dessen auszuwählen, ob die Tokenübertragungseinheit kommunikativ mit einer Ressourcenkonto-Netzwerkschnittstelle verbunden ist.
  24. Tokenübertragungseinheit nach Anspruch 19, wobei die Programmbefehle, mit denen die Tokenübertragungseinheit zum Initiieren eines Transaktionsdienstes veranlasst wird, Programmbefehle aufweisen, um die Tokenübertragungseinheit zu veranlassen: eine Transaktionsdienstanforderung an den Tokenempfangsterminal zu senden (322), um ein Transaktionsstartprotokoll zu beginnen; eine Transaktionsantwort von dem Tokenempfangsterminal zu empfangen (328); und das Transaktionsstartprotokoll bis zu dem Ausgeben eines Transaktionsänderungsaufrufs auszusetzen (326).
  25. Tokenübertragungseinheit nach Anspruch 19, wobei der Validierungsparameter durch ein Tokenverwaltungsprogramm zugewiesen wird, das in der Tokenübertragungseinheit ausgeführt wird.
  26. Tokenübertragungseinheit nach Anspruch 19, wobei der Tokenzustandsmanager in einem Systemarbeitsspeicher-Bereich der Tokenübertragungseinheit betrieben wird.
  27. Tokenübertragungseinheit nach Anspruch 19, wobei die Programmbefehle, mit denen die Tokenübertragungseinheit zum Ausgeben eines Transaktionsänderungsaufrufs veranlasst wird, Programmbefehle in dem Tokenzustandsmanager aufweisen, um direkt oder indirekt mit einer Ressourcenkontoanwendung Daten auszutauschen, um die Transaktionstoken zu aktivieren oder zu deaktivieren.
  28. Verfahren zum Verarbeiten einer Transaktion in einer Tokenübertragungseinheit (200; 304), wobei das Verfahren aufweist: Speichern (318), durch die Tokenübertragungseinheit, eines Transaktionstokens (104; 400) mit einem vorgegebenen Transaktionsressourcenwert (402) und einem zugehörigen Validierungsparameter (404); Initiieren (322), durch die Tokenübertragungseinheit, eines Transaktionsdienstes mit einem Tokenempfangsterminal (308); Ermitteln, ob die Tokenübertragungseinheit kommunikativ mit einem Ressourcenkontoserver verbunden ist; und in Reaktion auf die Tatsache, dass die Tokenübertragungseinheit kommunikativ mit dem Ressourcenkontoserver verbunden ist: Ermitteln, dass dem Token zugehörige Validierungsparameter mit Bedingungen, die der Transaktion zugehörig sind, übereinstimmen; Abschließen der Transaktion; in Reaktion auf die Tatsache, dass die Tokenübertragungseinheit nicht kommunikativ mit dem Ressourcenkontoserver verbunden ist, Ändern (330) eines Tokens der Transaktion, die ausgeführt werden soll, durch einem Tokenzustandsmanager (225) auf Grundlage von Parametern, die in der Tokenübertragungseinheit gespeichert sind.
  29. Verfahren nach Anspruch 28, ferner aufweisend: Senden (322) einer Transaktionsdienstanforderung an den T okenem pfangsterm inal; Empfangen (328) einer Transaktionsantwort von dem Tokenempfangsterminal; und Aussetzen (326) der Transaktion bis nach dem Ändern der Transaktion.
  30. Verfahren nach Anspruch 28, wobei die Parameter durch ein Tokenverwaltungsprogramm zugewiesen wird, das in der Tokenübertragungseinheit ausgeführt wird.
  31. Verfahren nach Anspruch 28, wobei der Tokenzustandsmanager in einem Systemarbeitsspeicher-Bereich (222) der Tokenübertragungseinheit betrieben wird.
  32. Verfahren nach Anspruch 28, wobei das Ändern der Transaktion direktes oder indirektes Austauschen mit einer Ressourcenkontoanwendung Daten austauscht, um die Transaktionstoken zu aktivieren oder zu deaktivieren, aufweist.
  33. Von Computer lesbares Programmprodukt, das ein von Computer lesbares Medium aufweist, das von Computer ausführbare Anweisungen zum Verarbeiten einer Transaktionen in einer Tokenübertragungseinheit (200, 304) aufweist, wobei die Anweisungen aufweisen: Anweisungen zum Speichern (318), durch die Tokenübertragungseinheit, eines Transaktionstokens (104; 400) mit einem vorgegebenen Transaktionsressourcenwert (402) und einem zugehörigen Validierungsparameter (404); Anweisungen zum Initiieren (322), durch die Tokenübertragungseinheit, eines Transaktionsdiensts mit einem Tokenempfangsterminal (307), um die Transaktion zu ermöglichen; Anweisungen zum Ermitteln, ob die Tokenübertragungseinheit kommunikativ mit einem Ressourcenkontoserver verbunden ist; Anweisungen zum, in Reaktion auf die Tatsache, dass die Tokenübertragungseinheit kommunikativ mit dem Ressourcenkontoserver verbunden ist, Ermitteln, dass dem Token zugehörige Validierungsparameter mit Bedingungen, die der Transaktion zugehörig sind, übereinstimmen; und Abschließen der Transaktion; Anweisungen zum, in Reaktion auf die Tatsache, dass die Tokenübertragungseinheit nicht kommunikativ mit dem Ressourcenkontoserver verbunden ist, Ändern (330) eines Tokens der Transaktion, die ausgeführt werden soll, auf Grundlage von Parametern, die in der Tokenübertragungseinheit gespeichert sind.
  34. Einheit, aufweisend: einen oder mehrere Prozessoren (204); zumindest ein von Computer lesbares Programmprodukt, das ein oder mehrere von Computer lesbare Medien aufweist, die auf dem einen oder den mehreren Prozessoren ausführbare Anweisungen zum Verarbeiten einer Transaktion in einer Tokenübertragungseinheit (200; 304) aufweisen, wobei die Anweisungen aufweisen: Anweisungen zum Speichern (318), durch die Tokenübertragungseinheit, eines Transaktionstokens (104; 400) mit einem vorgegebenen Transaktionsressourcenwert (402) und einem zugehörigen Validierungsparameter (404); Anweisungen zum Initiieren (322), durch die Tokenübertragungseinheit, eines Transaktionsdiensts mit einem Tokenempfangsterminal (308), um die Transaktion zu ermöglichen; Anweisungen zum Ermitteln, ob die Tokenübertragungseinheit kommunikativ mit einem Ressourcenkontoserver verbunden ist; Anweisungen zum, in Reaktion auf die Tatsache, dass die Tokenübertragungseinheit kommunikativ mit dem Ressourcenkontoserver verbunden ist, Ermitteln, dass dem Token zugehörige Validierungsparameter mit Bedingungen, die der Transaktion zugehörig sind, übereinstimmen; und Abschließen der Transaktion; Anweisungen zum, in Reaktion auf die Tatsache, dass die Tokenübertragungseinheit nicht kommunikativ mit dem Ressourcenkontoserver verbunden ist, Ändern (330) eines Tokens der Transaktion, die ausgeführt werden soll, auf Grundlage von Parametern, die in der Tokenübertragungseinheit gespeichert sind.
  35. Programmprodukt nach Anspruch 33 oder Einheit nach Anspruch 34, wobei die Anweisungen des Weiteren Anweisungen zum Lesen der Parameter aus einer Transaktionsereignistabelle (500) aufweisen, die auf der Tokenübertragungseinheit gespeichert ist.
  36. Verfahren nach Anspruch 28, Programmprodukt nach Anspruch 33 oder Einheit nach Anspruch 34, wobei die Parameter einen ersten Wert beinhalten, der einem Netzwerktrennungsstatus (414) der Tokenübertragungseinheit zugehörig ist.
  37. Verfahren nach Anspruch 36, Programmprodukt nach Anspruch 36 oder Einheit nach Anspruch 36, wobei die Parameter des Weiteren einen zweiten Wert beinhalten, der einem Netzwerkverbindungsstatus (412) der Tokenübertragungseinheit zugehörig ist.
DE112016000192.4T 2015-01-26 2016-01-15 Client-seitige Sicherheit für Transaktionen auf Tokengrundlage Active DE112016000192B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/605,446 2015-01-26
US14/605,446 US9799032B2 (en) 2015-01-26 2015-01-26 Client-side security for tokenized transactions
PCT/IB2016/050189 WO2016120743A1 (en) 2015-01-26 2016-01-15 Client-side security for tokenized transactions

Publications (2)

Publication Number Publication Date
DE112016000192T5 DE112016000192T5 (de) 2017-08-24
DE112016000192B4 true DE112016000192B4 (de) 2023-10-19

Family

ID=56432732

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112016000192.4T Active DE112016000192B4 (de) 2015-01-26 2016-01-15 Client-seitige Sicherheit für Transaktionen auf Tokengrundlage

Country Status (3)

Country Link
US (4) US9799032B2 (de)
DE (1) DE112016000192B4 (de)
WO (1) WO2016120743A1 (de)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9799032B2 (en) 2015-01-26 2017-10-24 International Business Machines Corporation Client-side security for tokenized transactions
US9330383B1 (en) 2015-09-23 2016-05-03 Square, Inc. Message dispatcher for payment system
US10248940B1 (en) 2015-09-24 2019-04-02 Square, Inc. Modular firmware for transaction system
US10108412B2 (en) 2016-03-30 2018-10-23 Square, Inc. Blocking and non-blocking firmware update
US11010765B2 (en) 2016-06-29 2021-05-18 Square, Inc. Preliminary acquisition of payment information
US10817869B2 (en) 2016-06-29 2020-10-27 Square, Inc. Preliminary enablement of transaction processing circuitry
US10417628B2 (en) 2016-06-29 2019-09-17 Square, Inc. Multi-interface processing of electronic payment transactions
US11947978B2 (en) 2017-02-23 2024-04-02 Ab Initio Technology Llc Dynamic execution of parameterized applications for the processing of keyed network data streams
US10831509B2 (en) 2017-02-23 2020-11-10 Ab Initio Technology Llc Dynamic execution of parameterized applications for the processing of keyed network data streams
US10990969B2 (en) 2018-12-21 2021-04-27 Square, Inc. Point of sale (POS) systems and methods for dynamically processing payment data based on payment reader capability
US10762196B2 (en) 2018-12-21 2020-09-01 Square, Inc. Point of sale (POS) systems and methods with dynamic kernel selection
US11049095B2 (en) 2018-12-21 2021-06-29 Square, Inc. Point of sale (POS) systems and methods with dynamic kernel selection
JP7247692B2 (ja) * 2019-03-22 2023-03-29 富士フイルムビジネスイノベーション株式会社 トークン管理装置及びトークン管理プログラム
US20220318551A1 (en) * 2021-03-31 2022-10-06 Arm Limited Systems, devices, and/or processes for dynamic surface marking
US11995904B2 (en) 2021-03-31 2024-05-28 Arm Limited Systems, devices, and/or processes for dynamic surface marking
CN113992593B (zh) * 2021-10-20 2024-03-01 京东科技信息技术有限公司 服务资源调用方法、装置、电子设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120239556A1 (en) 2010-10-20 2012-09-20 Magruder Andrew M Latency payment settlement apparatuses, methods and systems
US20120303432A1 (en) 2011-05-27 2012-11-29 Accenture Global Services Limited System for managing digital vouchers
US8682802B1 (en) 2011-11-09 2014-03-25 Amazon Technologies, Inc. Mobile payments using payment tokens
CN104021469A (zh) 2014-06-13 2014-09-03 捷德（中国）信息科技有限公司 进行支付交易的方法、设备以及系统
EP2819080A1 (de) 2013-06-28 2014-12-31 Sap Se Telekommunikationssystem mit Autorisierungstoken

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005338964A (ja) * 2004-05-24 2005-12-08 Oki Electric Ind Co Ltd 自動取引システム
US8290876B1 (en) 2011-01-12 2012-10-16 Steven Douglas Powell Method and system for securing a third party payment electronic transaction
US10482457B2 (en) 2011-10-17 2019-11-19 Capital One Services, Llc System and method for token-based payments
US8818867B2 (en) 2011-11-14 2014-08-26 At&T Intellectual Property I, L.P. Security token for mobile near field communication transactions
US10373161B2 (en) 2011-12-30 2019-08-06 Paypal, Inc. Offline mobile phone payments
US8984286B2 (en) 2012-06-28 2015-03-17 International Business Machines Corporation Message originator token verification
CN103679443A (zh) 2012-09-18 2014-03-26 中国银联股份有限公司 一种利用手机终端进行的支付方法及其处理系统
US9799032B2 (en) 2015-01-26 2017-10-24 International Business Machines Corporation Client-side security for tokenized transactions

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120239556A1 (en) 2010-10-20 2012-09-20 Magruder Andrew M Latency payment settlement apparatuses, methods and systems
US20120303432A1 (en) 2011-05-27 2012-11-29 Accenture Global Services Limited System for managing digital vouchers
US8682802B1 (en) 2011-11-09 2014-03-25 Amazon Technologies, Inc. Mobile payments using payment tokens
EP2819080A1 (de) 2013-06-28 2014-12-31 Sap Se Telekommunikationssystem mit Autorisierungstoken
CN104021469A (zh) 2014-06-13 2014-09-03 捷德（中国）信息科技有限公司 进行支付交易的方法、设备以及系统

Also Published As

Publication number Publication date
US20160217458A1 (en) 2016-07-28
US20200074467A1 (en) 2020-03-05
US10007912B2 (en) 2018-06-26
US20180300721A1 (en) 2018-10-18
US20160217465A1 (en) 2016-07-28
DE112016000192T5 (de) 2017-08-24
US11042875B2 (en) 2021-06-22
US9799032B2 (en) 2017-10-24
US10504115B2 (en) 2019-12-10
WO2016120743A1 (en) 2016-08-04

Similar Documents

Publication Publication Date Title
DE112016000192B4 (de) Client-seitige Sicherheit für Transaktionen auf Tokengrundlage
DE102016100110B4 (de) Verwaltung einer Ressourcenkontoanwendung
US20230410089A1 (en) Instant wallet credit card
CN108648073A (zh) 信贷方法、装置、设备和计算机存储介质
DE112015004037T5 (de) Systeme und Verfahren zum Implementieren dynamischer Hybrid-Wallet-Token
DE112014000702T5 (de) Vorrichtungen und Verfahren für sichere Elementtransaktionen und die Verwaltung von Assets
DE10296919T5 (de) System und Verfahren zur sicheren Rückzahlung
DE10296888T5 (de) System und Verfahren zur sicheren Eingabe und Authentifikation von verbraucherzentrierter Information
DE112014006088T5 (de) Person-To-Person-Payments unter Verwendung elektronischer Vorrichtungen
DE102014102232A1 (de) System zur digitalen Bonuspunkt-Verwaltung
WO2008092770A1 (de) Verfahren und vorrichtung zur elektronischen zahlung
DE112012005291T5 (de) Sichere finanzielle Transaktionen unter Verwendung mehrerer Kommunikationstechnologien
DE212014000188U1 (de) Systeme und Computerprogrammprodukte zur Verwaltung kontaktfreier Transaktionen
DE102018125358A1 (de) Verfahren und Vorrichtungen zum sicheren Verarbeiten von Chipkarten
DE112013000745T5 (de) Verbindung von mobilen Einheiten, um Transaktionen für mobilen Handel zu ermöglichen
DE102013016119B4 (de) Verfahren zur Bezahlung
Pourghomi et al. Ecosystem scenarios for cloud-based NFC payments
DE202018006361U1 (de) Zahlungssystem
EP4266234A1 (de) Verfahren und vorrichtung zur ermöglichung des onboarding von händlern in ein kommerzielles online-ökosystem
DE102020125386A1 (de) Verfahren und systeme für handelszahlungen
EP4105870A1 (de) Verfahren und system zum sammeln von bonuspunkten
DE202021103299U1 (de) System zum Sammeln von Bonuspunkten
Ulvedal The implementation of NFC-based mobile payment in Norway: a case study of the emerging NFC business ecosystem in Norway

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R084 Declaration of willingness to licence