EP3766032A1 - Registrieren von elektronischen zahlungsmitteln - Google Patents

Registrieren von elektronischen zahlungsmitteln

Info

Publication number
EP3766032A1
EP3766032A1 EP19716061.7A EP19716061A EP3766032A1 EP 3766032 A1 EP3766032 A1 EP 3766032A1 EP 19716061 A EP19716061 A EP 19716061A EP 3766032 A1 EP3766032 A1 EP 3766032A1
Authority
EP
European Patent Office
Prior art keywords
payment
mobile terminal
user
authorization
transmitted
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.)
Ceased
Application number
EP19716061.7A
Other languages
English (en)
French (fr)
Inventor
Thomas Tarantino
Sascha Behlendorf
Klaus Finkenzeller
Michael Baldischweiler
Stefan Kluge
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.)
Giesecke+Devrient Mobile Security Germany GmbH
Original Assignee
Giesecke+Devrient Mobile Security Germany GmbH
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 Giesecke+Devrient Mobile Security Germany GmbH filed Critical Giesecke+Devrient Mobile Security Germany GmbH
Publication of EP3766032A1 publication Critical patent/EP3766032A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108—Remote banking, e.g. home banking
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q20/4014—Identity check for transactions

Definitions

  • the present invention is directed to a method for registering electronic means of payment as well as to a registration arrangement which is set up accordingly. Furthermore, a computer program product with control commands is proposed, which implement the proposed method or operate the proposed registration arrangement.
  • registration takes place at a service provider together with registration data.
  • registration data may include, for example, a public key and a secret key.
  • a public key can be, for example, a user ID or even a credit card number.
  • a secret information is typically deposited, for example, a PIN number or even a password.
  • the physical terminal is then maintained in accordance with conventional methods, and a data exchange takes place in such a way that the service provider can identify the payment of the person and has access to bank information, for example via an established user account.
  • various terminals are known, wel che should fit into such a payment process.
  • a wearable here is a garment or a piece of jewelry, such. B. a bracelet, which the user carries with him and identified for example by means of incorporated electronics.
  • B. a bracelet which the user carries with him and identified for example by means of incorporated electronics.
  • fitness bracelets which have a processor, a non-volatile memory and a touch display. In this case, it is possible to integrate an interface into such a wearable in such a way that a user can authenticate himself wirelessly to a payment terminal.
  • the user must have a first account available from a manufacturer and in turn have to provide another account for further terminals or for terminals of other manufacturers.
  • This is in particular nachtei lig, since the user is prevented from a simple payment process and thus typically would always pay for the same device.
  • nachtei lig since the user is prevented from a simple payment process and thus typically would always pay for the same device.
  • the user has the choice, between several terminals, which in uniform You can access one single account or authorize a payment transaction here.
  • a method for registering electronic payment means is proposed.
  • a payment medium identifier of at least one payment instrument is transmitted to a mobile terminal in each case.
  • a deposit each of a means of payment at a central authorization point and a Autorisie ren a request by the central authorization point the request is initiated by at least one means of payment, which has transmitted a payment medium identifier.
  • the mobile terminal carries out the deposit.
  • An electronic means of payment is any means of payment which, by means of data exchange, allows a payment transaction to be carried out or merely initiated.
  • This may be, for example, a loan Act trading, which is readable with a Heilschnitstelle.
  • each payment medium typically has a clear payment title identifier.
  • This may be a credit card number for a credit card, but may also include a serial number for a wearable, for example.
  • the credit card which is electronically readable, or a wearable to an electronic Zahlungsmitel.
  • a payment terminal is provided with which the user should pay, for example, at a cash register. He now holds any of his registered funds to this terminal and thus initiates a payment process.
  • the payment medium (s) In order for this to take place independently of the means of payment operated by the user, it is necessary for the payment medium (s) to be registered for the time being in order to allow unified access to the account information.
  • a transmission of a payment title of at least one payment medium takes place. If, for example, a user has several credit cards and a so-called wearable, he transmits this to a mobile terminal. Thus, the user transmits multiple credit card identifiers and an identifier of the card
  • the user can use his own mobile device, for example a smartphone, in a particularly advantageous manner.
  • the user can be provided with an application or control commands which allow an air interface in such a way to address that the means of payment or the means of payment are transmitted to the mobile terminal.
  • This process can be performed iteratively such that all means of payment are known to the mobile terminal.
  • the means of payment are each known by a unique means of payment.
  • a PIN specific to the means of payment can be requested by the user.
  • the PIN may for example be contained in a packaging of the means of payment.
  • a central authentication point it is also possible to deposit the means of payment of the transmitted data at a central authentication point.
  • the mobile terminal in this case a smartphone, transmits the collected means of payment identification to the authorization site by means of mobile radio.
  • the central authorization point is aware of all means of payment identification with which a user wants to pay.
  • all payment means identifiers can be assigned to means of payment which an individual user operates.
  • an authorization of a request can be made by the central authorization point, wherein the request is initiated by at least one payment means. If, for example, a user holds his payment medium at a payment terminal, he initiates a corresponding payment request. Such a payment request is submitted or transmitted to the authorization office, and the latter can now transfer the deposited funds. Search identifiers and recognizes that a particular, held cash is assigned to a particular user.
  • a payment terminal transmits the request to the authorization point, and this authorization point then recognizes on the basis of the deposited payment code identifiers which user now wants to pay.
  • the user is an operator of the electronic means of payment.
  • a user can also be identified by means of a user account.
  • the term of a user is by no means to be understood as limiting, but rather all means of payment are to be assigned to a user account through which payment is to be made.
  • the user registers his credit card or even his wearable under his name and creates an account for this purpose.
  • all Zahlungsmit tel can be assigned by their means of payment a user account, which has more information, such. For example, a payment information. In this case, it is possible to deposit the public and secret keys in the user account, or to also provide this information when transmitting or depositing same.
  • an authorization of the request For example, the request is a payment request, which was initiated by a means of payment.
  • the user holds a credit card in front of a payment terminal, whereby the credit card has already been registered, ie deposited.
  • the authorization center now looks to which user is assigned to this credit card and then au- tarra the payment process.
  • the user may, for example, at the authentication site a individual payment IDs of his means of payment via his mobile terminal, e.g. a smartphone without having to physically dispose of the means of payment.
  • his mobile terminal e.g. a smartphone
  • the properties of the means of payment assigned to a user can be flexibly configured via the central authentication point. For example, so-called payment limits can be deposited for the respective means of payment, a time-limited use of the means of payment can be determined, a release of the means of payment can be determined upon resale of the means of payment, the means of payment is activated and / or deactivated, a name of the payment means is displayed.
  • means of payment a photograph of the means of payment may be stored and / or restrictions on a place and / or a group of goods may be defined.
  • the at least one means of payment exists as a physical means of payment.
  • the at least one means of payment is a credit card, a wearable, a token
  • Keychain a sticker and / or a mobile device.
  • This has the advantage that common means of payment can be reused in accordance with the proposed method, and in particular that the means of payment can be embedded in already existing system architectures.
  • it is not necessary, for example, to create a new credit card for the user since he can already deposit an existing credit card or many existing credit cards by means of the mobile terminal at the authorization center.
  • the user it is possible for the user to register a credit card as well as a key fob, which has corresponding electronic components, with the authorization center, ie the corresponding electronics of the key fob or the credit card are read out, transmitted to the mobile terminal and transmitted by deposited there at the authorization office.
  • the authorization comprises grouping the at least one payment means.
  • This has the advantage that a large number of means of payment can be registered and the means of payment can be grouped in such a way that a group of means of payment can always be assigned to a user or a user account. In this way, the means of payment can be used to determine which means of payment has been registered for which user, and authorization or debiting takes place only with regard to the user to whom the means of payment is also assigned.
  • the means of payment each transmitted by the mobile terminal is assigned to the mobile terminal.
  • the payment medium identification respectively transmitted by the mobile terminal is assigned to exactly one user account. This has the advantage that just a clear identification of the payment transactions is possible, which can potentially be0 a variety of means of payment can be used. Thus, according to the invention, it is possible for the user to operate multiple means of payment, but always to initiate a debit from a user account.
  • the over-5 is each one of a currency identifier over an air interface
  • the payment medium identifier is transmitted and / or deposited together with security information.
  • security information can be, for example, public and secret keys.
  • security numbers such as a PIN or even a password.
  • the payment means holds a set of control commands and authorizes requests initiated by a subset of control commands.
  • the means of payment for example a smart card, holds various applications, and the user can positively describe which applications may participate in a payment process or initiate a payment request.
  • these smartcards need merely be adapted so that the user determines which of the applications of the smartcard may be registered with the authorization center.
  • another subset of control commands of at least one payment means is blocked for authorization.
  • This has the advantage that, if several applications are deposited on the payment, even individual applications can be locked.
  • the subset of applications that are authorized to authorize and the subset of those that are not authorized to authorize is disjuncted.
  • a user operates a so-called fitness bracelet, which holds several applications before.
  • a so-called smartwatch is used.
  • shopping platforms can be unlocked in such a way that they can participate in the method according to the invention, but applications can also be blocked, which are then not authorized.
  • this application can be excluded from the authorization. Furthermore, it is possible for the user to operate a banking application by means of his smartphone or his smartwatch, which can then be activated for authorization.
  • a blocking of a means of payment is carried out by means of its transmitted means of payment identification.
  • This has the advantage that a user can block individual means of payment. If the user has indicated, for example, in previous procedural steps that a certain credit card is to be deposited with the authorization center, and this credit card is lost, then the latter can also transmit the means of payment identification and thus cancel the credit card. lock credit card. Thus, while a deposit of payment funds is possible, it is also possible to remove these funds again from the list and thus to block the means of payment. This is particularly advantageous because the user can manage his means of payment himself.
  • a cash management unit is provided between the authorization site and the mobile terminal.
  • This has the advantage that between the smartphone, so the mobile device, and the authorization point for example, a server can be interposed, the further processing takes over processing steps.
  • multiple devices can be managed, and the authorization can then be requested by the cash management unit.
  • the cash management unit thus serves to receive the cash register IDs.
  • the mobile terminal communicates with the authorization center by means of a mobile radio network.
  • a mobile network between the mobile terminal and the authorization center can be arranged.
  • the mobile terminal it is possible for the mobile terminal to set up a data connection with a network operator or with components provided by a network operator, and thus deposit the means of payment identification at the authorization site via the air interface.
  • a simple method is created with which the user can independently deposit his means of payment at an authorization office.
  • the object is also achieved by a registration arrangement for registering electronic means of payment, with a first interface unit configured to transmit in each case a means of payment identification of at least one payment means to a mobile terminal.
  • a second interface unit is provided, which is set up for storing the respective one payment medium identifier at a central authorization point.
  • the central authorization center is arranged to authorize a request, wherein the request is initiated by at least one payment medium which has transmitted a payment medium identifier, wherein the mobile terminal carries out the deposit.
  • the object is further achieved by a computer program product with control commands which implement the proposed method or which are set up to operate the proposed registration arrangement.
  • FIG. 1 shows a registration arrangement according to an aspect of the present invention
  • Fig. 2 a method for registering according to one aspect of the vorlie invention.
  • Fig. 1 shows a registration arrangement in which two means of payment find use.
  • a means of payment for example, a key fob, the corresponding communication electronics has or even a so-called fitness bracelet.
  • the mobile terminal is shown here as a smartphone.
  • An authorization place which communicates with a cash management unit marked in the middle above.
  • Means of payment As credit cards are permanently personalized at production or in the field. A secure user-controlled transfer of his data to other means of payment, eg. B. Wear Ables, smartphone and the like, is not possible. Typically, each means of payment has its own data.
  • This problem is solved by the invention as follows.
  • the smartphone reads data from the tender and sends it to the background system to register the tender with the background system so that the user can make a payment with the tendered bank account. Previously booked funds are deregistered.
  • the user can unsubscribe any means of payment at the background system or at the authorization center with his smartphone.
  • the user determines which means of payment are active. Furthermore, he can use one and the same data on several means of payment. Thus, in particular, an advantageous solution for a wearable technology is provided.
  • a user does not have controlled transmission of his own data, such as data.
  • B. card data, PAN, PIN, applications, keys and the like, to another terminal can perform.
  • a card beneficial payment devices in various forms, eg As credit cards, wearable manufacturer A, wearable manufacturer B, mobile devices or the like and would like to use this alternately with the same card data.
  • each device has its own card identification, e.g. B. own Primary Account Number, own keys and the like.
  • the user should be given the opportunity to use his card data, flexible, independent but controlled on different payment terminals and at the same time to prevent misuse of data by third parties.
  • a device eg. B. a smartphone is installed.
  • Said device can be connected via a contactless interface, for. NFC, Bluetooth or the like.
  • a central background system or an authorization point is required, which is connected to the respective devices via one of the interfaces mentioned. The user should be able to use this system to flexibly log in and out of his various payment devices in the aforementioned background system and then to be able to use these for the respective payment transaction. The details of this acquisition and withdrawal process are described below by way of example.
  • the user holds the desired means of payment to the device, which has a corresponding contactless interface, for. B. NFC, Bluetooth, low-energy or the like, and on which the application for managing the map data or devices is running.
  • a connection to the background system or the authorization center between the device with the contactless interface and the system itself must already be established at this time.
  • From the payment terminal device-specific data can then read sen and transmitted to the background system, eg. As a TAN, cardholder name and the like.
  • the read-out data are then transmitted to the background system in order to "deposit" or register the respective present device there, for example if the payment device is a display card, multi-application device. In this registration step, the user can also specify which of his applications on the payment terminal should be actively switched in.
  • this information is then stored and the user can use the new Payments that have already been activated can now be automatically logged out of the system.
  • each payment system can be mapped on the side of a so-called payment token.
  • the user can also use the procedure described in such a way that one or more means of payment are logged off again. This can also be done by non-physical presence of the means of payment using the application. The chosen means of payment will be logged out in the background system.
  • the user has the opportunity to flexibly control which of his payment means are active or inactive. Furthermore, he will be able to requires the same card data, also called payment identity, to be used on one or more means of payment.
  • Fig. 2 shows a method for registering electronic Zahlungsmit stuffs, wherein in a first step 100, a transmission of each one Zah lungsstoffkennung of at least one payment means to a mobile terminal takes place.
  • a subsequent method step 101 the respective one of the means of payment identification is deposited at a central authorizing office.
  • an authorization request is made by the central authorization point, wherein the request is initiated by at least one payment means which has transmitted a payment means identifier.
  • the mobile terminal in this case performs the deposit 101.
  • the initiation of the payment request or the inquiry in step 103 can take place in such a way that this can be done at any time.
  • authorization 102 it is necessary that the means of payment identification is already deposited.
  • steps 100 and 101 may be performed iteratively such that all of the means of payment identification of the existing means of payment is first transmitted and then deposited.
  • the transmission itself can also be iterative, and in a single further procedural Step 101 is a deposit 101 of all previously transmitted payment identifiers.
  • a blocking of payment means takes place. For example, if a user wishes to unsubscribe from a form of payment because, for example, he has lost his credit card, he can also transmit this to the authorization center, and this then deletes the means of payment identification, thereby avoiding misuse.
  • a secure yet technically simple method of securely managing multiple payment means, each physically present, is proposed.

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)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

Verfahren zum Registrieren von elektronischen Zahlungsmitteln sowie eine Registrierungsanordnung, die entsprechend eingerichtet ist. Ferner wird ein Computerprogrammprodukt mit Steuerbefehlen vorgeschlagen, welche das vorgeschlagene Verfahren implementieren bzw. die vorgeschlagene Registrierungsanordnung betreiben.

Description

Registrieren von elektronischen Zahlungsmitteln
Die vorliegende Erfindung ist gerichtet auf ein Verfahren zum Registrieren von elektronischen Zahlungsmitteln sowie auf eine Registrierungsanord nung, die entsprechend eingerichtet ist. Ferner wird ein Computerpro- grammprodukt mit Steuerbefehlen vorgeschlagen, welche das vorgeschlage ne Verfahren implementieren bzw. die vorgeschlagene Registrierungsanord nung betreiben.
Typischerweise verwenden Benutzer mehrere Endgeräte, mit denen sie bei- spielsweise Zahlungen vornehmen wollen. Hierbei erfolgt gemäß bekannter Verfahren eine Registrierung bei einem Dienstanbieter mitsamt Registrie rungsdaten. Solche Registrierungsdaten können beispielsweise einen öffent- liehen Schlüssel und einen geheimen Schlüssel umfassen. Ein öffentlicher Schlüssel kann hierbei beispielsweise eine Benutzerkennung oder aber auch eine Kreditkartennummer sein. Zusätzlich wird typischerweise eine geheime Information hinterlegt, beispielsweise eine PIN-Nummer oder aber auch ein Passwort. Bei einem Zahlvorgang wird dann gemäß herkömmlicher Verfah- ren das physische Endgerät vorgehalten, und es erfolgt ein Datenaustausch derart, dass der Dienstanbieter die Zahlung der Person identifizieren kann und beispielsweise über ein eingerichtetes Benutzerkonto Zugriff auf Bankin formationen hat. Gemäß weiterer bekannter Verfahren sind diverse Endgeräte bekannt, wel che sich in einen solchen Bezahlprozess einfügen sollen. So ist davon auszugehen, dass mit der zunehmenden Technisierung ein Benutzer mehrere Geräte besitzt, mit denen er eine einheitliche Kontoinformation bzw. Bezahlin formation bereitstellen will. Es sind diverse neue Arten von mobilen Endge- räten im Umlauf, wie z. B. sogenannte Wearables. Ein Wearable ist hierbei ein Kleidungsstück bzw. ein Schmuckstück, wie z. B. ein Armband, welches der Benutzer mit sich führt und sich beispielsweise mittels eingebrachter Elektronik identifiziert. Insbesondere kennt der Fachmann hierbei sogenann te Fitness- Armbänder, die einen Prozessor, einen nicht-flüchtigen Speicher und ein Touch Display aufweisen. Hierbei ist es möglich, in ein solches Wearable auch eine Schnittstelle derart zu integrieren, dass sich ein Benutzer kabellos an einem Bezahlterminal authentisieren kann. Somit besteht ein Be darf, eine besonders sichere und komfortable Hardwareumgebung bereitzustellen, die es dem Benutzer ermöglicht, diese neuartigen tragbaren Rechner in bestehende Systemarchitekturen einzubringen.
Hierbei besteht das Problem, dass ein Benutzer stets eine geringe Anzahl von Bezahlkonten bzw. nur ein Bezahlkonto vorhält. Da nun aber dieser Benutzer eine Vielzahl von mobilen Endgeräten mit sich führt, ist es gemäß dem Stand der Technik besonders nachteilig, dass er durch diese mehreren Endgeräte potenziell auch mehrere Identitäten hat, die er verwalten muss. So sind typi scherweise Benutzerkonten herstellergebunden und erlauben es dem Benut zer nicht, eine plattformübergreifende Identifizierung durchzuführen.
Daher muss der Benutzer gemäß bekannter Verfahren für einzelne mobile Endgeräte bzw. für mobile Endgeräte von einem Hersteller ein erstes Konto bereithalten und für weitere Endgeräte bzw. für Endgeräte anderer Herstel ler wiederum ein weiteres Konto bereithalten. Dies ist insbesondere nachtei lig, da der Benutzer an einem einfachen Bezahlvorgang gehindert wird und somit typischerweise stets über das gleiche Endgerät bezahlen würde. Hier- bei ist es besonders wünschenswert, dass eine Möglichkeit besteht, dass ein Benutzer mehrere Endgeräte betreiben kann und hierbei lediglich eine ein zelne Kontoinformation verwalten muss. Damit wäre es möglich, dass der Nutzer die Wahl hat, zwischen mehreren Endgeräten, welche in einheitlicher Weise auf ein einziges Konto Zugriff haben bzw. hier einen Zahlungsvorgang autorisieren können.
Es ist somit eine Aufgabe der vorliegenden Erfindung, ein Verfahren bereit- zustellen, welches es einem Benutzer ermöglicht, mehrere physische Zahl mittel vorzuhalten, aber dennoch in einfacher und sicherer Weise ein Bezah len ermöglicht. Hierbei wird insbesondere gefordert, dass dies mit wenig technischem Aufwand unter Berücksichtigung bestehender Hardwarean ordnungen erfolgt. Es ist ferner eine Aufgabe der vorliegenden Erfindung, eine entsprechend eingerichtete Registrierungsanordnung bereitzustellen mitsamt einem Computerprogrammprodukt zum Implementieren des vor geschlagenen Verfahrens bzw. zum Betreiben der Registrierungsanordnung.
Die Aufgabe wird gelöst mit den Merkmalen des Patentanspruchs 1. Weitere vorteilhafte Ausgestaltungen sind in den Unteransprüchen angegeben.
Demgemäß wird ein Verfahren zum Registrieren von elektronischen Zah lungsmitteln vorgeschlagen. Hierbei erfolgt ein Übermitteln jeweils einer Zahlungsmittelkennung von mindestens einem Zahlungsmittel an ein mobi- les Endgerät. Daraufhin erfolgt ein Hinterlegen der jeweils einen Zahlungsmittelkennung bei einer zentralen Autorisierungsstelle sowie ein Autorisie ren einer Anfrage durch die zentrale Autorisierungsstelle, wobei die Anfrage durch mindestens ein Zahlungsmittel initiiert wird, welches eine Zahlungs mittelkennung übermittelt hat. Das mobile Endgerät führt hierbei die Hinter- legung durch.
Ein elektronisches Zahlungsmittel ist jegliches Zahlungsmittel, welches mit tels Datenaustausch ermöglicht, dass ein Bezahlvorgang durchgeführt bzw. lediglich initiiert wird. Hierbei kann es sich beispielsweise um eine Kredit- karte handeln, welcher mitels einer Luftschnitstelle auslesbar ist. Hierbei ist es besonders vorteilhaft, dass typischerweise jedes Zahlungsmitel eine ein deutige Zahlungsmitelkennung aufweist. Dies kann bei einer Kreditkarte eine Kreditkartennummer sein, kann aber auch beispielsweise bei einem Wearable eine Seriennummer umfassen. Somit handelt es sich bei der Kre ditkarte, welche elektronisch auslesbar ist, oder einem Wearable um ein elektronisches Zahlungsmitel.
Zum Bezahlen hält der Benutzer das physische Zahlungsmitel bereit und initiiert einen Bezahlvorgang. Hierbei kennt der Fachmann weitere Kompo nenten, welche erfindungsgemäß Verwendung finden. Beispielsweise wird ein Bezahlterminal vorgesehen, mit dem der Benutzer beispielsweise an einer Kasse bezahlen soll. Er hält nunmehr irgendeines seiner registrierten Zah lungsmittel an dieses Terminal und initiiert somit einen Bezahl vor gang.
Damit dies unabhängig von den vom Benutzer betriebenen Zahlungsmiteln erfolgen kann, ist es notwendig, dass das Zahlungsmitel bzw. die mehreren Zahlungsmitel vorerst registriert werden, um einen einheitlichen Zugriff auf die Kontoinformation zu erlauben.
Hierzu erfolgt in einem vorbereiteten Verfahrensschrit ein Übermiteln je- weils einer Zahlungsmitelkennung von mindestens einem Zahlungsmitel. Hat beispielsweise ein Benutzer mehrere Kreditkarten und ein sogenanntes Wearable, so übermittelt er dies an ein mobiles Endgerät. Somit übermitelt der Benutzer mehrere Kreditkartenkennungen und eine Kennung des
Wearables als Zahlungsmitelkennung. Hierbei kann der Benutzer in besonders vorteilhafter Weise sein eigenes Mobilgerät, beispielsweise ein Smart- phone, verwenden. Hierzu kann dem Benutzer eine Applikation bzw. Steu erbefehle bereitgestellt werden, die es erlauben, eine Luftschnitstelle derart anzusprechen, dass die Zahlungsmittelkennung bzw. die Zahlungsmittelkennungen an das mobile Endgerät übermittelt werden. Dieser Vorgang kann iterativ derart durchgeführt werden, dass alle Zahlungsmittel dem mobilen Endgerät bekannt sind. Die Zahlungsmittel sind jeweils durch eine ein- deutige Zahlungsmittelkennung bekannt. Ferner kann zur Übermittlung und Registrierung der Zahlungsmittelkennung eines Zahlungsmittels eine für das Zahlungsmittel spezifische PIN vom Benutzer abgefragt werden. Die PIN kann beispielsweise in einer Verpackung des Zahlungsmittels enthalten sein. Somit ist es auch möglich, die Zahlungsmittelkennungen der übermittelten Daten bei einer zentralen Authentisierungsstelle zu hinterlegen. Dies kann beispielsweise derart erfolgen, dass das mobile Endgerät, hier ein Smartpho- ne, die gesammelten Zahlungsmittelkennungen an die Autorisierungsstelle mittels Mobilfunk übermittelt. Nach diesem Verfahrensschritt sind der zent- ralen Autorisierungsstelle alle Zahlungsmittelkennungen bekannt, mit denen ein Benutzer bezahlen will. Hierbei ist es besonders vorteilhaft, dass alle Zah- lungsmittelkennungen Zahlungsmitteln zugeordnet werden können, die ein einzelner Benutzer betreibt. Somit ist es auch möglich zu erkennen, dass, falls ein bestimmtes Zahlungsmittel für einen Zahlungsvorgang verwendet wer- den soll, dieses von einem bestimmten Benutzer ist. Somit erfolgt auch eine
Zuordnung von mehreren Zahlungsmitteln an einen Benutzer.
Ist dies erfolgt, so kann ein Autorisieren einer Anfrage durch die zentrale Autorisierungsstelle erfolgen, wobei die Anfrage durch mindestens ein Zah- lungsmittel initiiert wird. Hält beispielsweise ein Benutzer sein Zahlungsmit tel an einem Bezahlterminal vor, so initiiert er eine entsprechende Bezahlan frage. Eine solche Bezahlanfrage wird der Autorisierungsstelle vorgelegt bzw. übermittelt, und diese kann nunmehr die hinterlegten Zahlungsmittel- kennungen durchsuchen und erkennt, dass ein bestimmtes, vorgehaltenes Zahlungsmittel einem bestimmten Benutzer zuzuordnen ist.
Hierbei kann es notwendig sein, weitere Daten zu übermitteln, die das Auto- risieren ermöglichen. Hierbei kann es sich beispielsweise um geheime Schlüssel wie z. B. eine PIN-Nummer oder ein Passwort handeln. Somit übermittelt ein Bezahlterminal die Anfrage an die Autorisierungsstelle und diese Autorisierungsstelle erkennt dann aufgrund der hinterlegten Zah- lungsmittelkennungen, welcher Benutzer nunmehr bezahlen will.
Der Benutzer ist hierbei ein Betreiber der elektronischen Zahlungsmittel. Generell kann ein Benutzer auch mittels einem Benutzerkonto identifiziert wer den. Somit ist es besonders vorteilhaft, anstatt einem Benutzer das Konzept des Benutzerkontos zu verwenden. Somit ist es möglich, alle verwendeten Zahlungsmittel jeweils einem Benutzerkonto zuzuordnen. Hierdurch ist also der Begriff eines Benutzers keinesfalls einschränkend zu verstehen, sondern vielmehr sind alle Zahlungsmittel einem Benutzerkonto zuzuordnen, durch das bezahlt werden soll. Beispielsweise registriert der Benutzer seine Kredit- karte oder aber auch sein Wearable unter seinem Namen und legt hierzu ein Benutzerkonto an. Somit ist es besonders vorteilhaft, dass alle Zahlungsmit tel durch ihre Zahlungsmittelkennung einem Benutzerkonto zugeordnet werden können, welches weitere Information aufweist, wie z. B. eine Be- zahlinformation. Hierbei ist es möglich, in dem Benutzerkonto die öffentlichen und geheimen Schlüssel zu hinterlegen, oder aber auch diese Informa- tionen bei dem Übermitteln bzw. Hinterlegen gleich mit bereitzustellen.
Ein Autorisieren erfolgt nur für diejenigen Zahlungsmittel, die bereits positiv eine Zahlungsmittelkennung hinterlegt haben. Hierbei ist es beispielsweise möglich, eine Liste von Zahlungsmittelkennungen zu führen, die Aufschluss darüber gibt, bezüglich welchem Benutzer bzw. welchem Benutzerkonto welche Zahlungsmittelkennungen zugeordnet sind. Somit erfolgt ferner eine Überprüfung, ob die Zahlungsmittelkennung vorhanden ist und ob diese einem Benutzer zuzuordnen ist. Daraufhin erfolgt ein Autorisieren der An- frage. Beispielsweise handelt es sich bei der Anfrage um eine Zahlungsanfra ge, welche von einem Zahlungsmittel initiiert wurde. Beispielsweise hält der Benutzer eine Kreditkarte vor ein Zahlungsterminal, wobei die Kreditkarte bereits registriert, d. h. hinterlegt wurde. Die Autorisierungsstelle sieht nunmehr nach, welchem Benutzer diese Kreditkarte zugeordnet ist und au- torisiert daraufhin den Bezahlvorgang. Hält der Benutzer ferner ein weiteres Zahlungsmittel, beispielsweise an einem anderen Terminal, vor, so wird ebenfalls hinterfragt, ob dieses andere Zahlungsmittel bereits hinterlegt wurde, worauf wiederum ein Autorisieren erfolgt, falls eine Zahlungsmittel kennung übermittelt wurde. Wurde keine Zahlungsmittelkennung übermit- telt, so ist das entsprechende Zahlmittel auch nicht registriert und es folgt eben keine Autorisierung.
Ferner kann der Benutzer beispielsweise bei der Authentisierungsstelle ein zelne Zahlungsmittelkennungen seiner Zahlungsmittel über sein mobiles Endgerät, z.B. ein Smartphone, deaktivieren, ohne dass das Zahlungsmittel körperlich vorliegen muss.
Darüber hinaus können über die zentrale Authentisierungsstelle ferner die Eigenschaften der einem Benutzer zugeordneten Zahlungsmittel flexibel konfiguriert werden. Beispielsweise können für das jeweilige Zahlungsmittel sogenannte Zahlungslimits hinterlegt werden, eine zeitlich befristete Benut zung des Zahlungsmittels bestimmt werden, eine Freigabe des Zahlungsmit tels bei einem Wiederverkauf des Zahlungsmittels bestimmt werden, das Zahlungsmittel aktiviert und/ oder deaktiviert werden, ein Name des Zah- lungsmittels vergeben werden, ein Foto des Zahlungsmittels gespeichert werden und/ oder Beschränkungen hinsichtlich eines Orts und/ oder einer Warengruppe definiert werden. Gemäß einem Aspekt der vorliegenden Erfindung liegt das mindestens eine Zahlungsmittel als ein physisches Zahlungsmittel vor. Dies hat den Vorteil, dass eine besonders hohe Sicherheit gewährleistet wird, da sowohl das mobi- le Endgerät als auch das Zahlungsmittel als separate Geräte vorliegen. Somit ist es möglich, Angriffe auszuschließen, welche rein softwarebasiert sind und ein gewisses Zahlungsmittel imitieren. Ferner ist es somit schwieriger, Daten auszulesen, da ein physisches Zahlungsmittel typischerweise nicht stetig mit einem Netzwerk gekoppelt ist.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist das mindes- tens eine Zahlungsmittel eine Kreditkarte, ein Wearable, ein Token, ein
Schlüsselanhänger, ein Sticker und/ oder ein mobiles Endgerät. Dies hat den Vorteil, dass gängige Zahlungsmittel gemäß dem vor geschlagenen Verfahren wiederverwendet werden können, und insbesondere, dass die Zahlungsmit tel in bereits bestehende Systemarchitekturen eingebettet werden können. Somit ist es beispielsweise nicht notwendig, dem Benutzer eine neue Kredit karte zu erstellen, da er bereits eine bestehende Kreditkarte bzw. viele beste hende Kreditkarten mittels des mobilen Endgeräts bei der Autorisierungs- stelle hinterlegen kann. Beispielsweise ist es möglich, dass der Benutzer so wohl eine Kreditkarte als auch einen Schlüsselanhänger, welcher entspre- chende elektronische Komponenten aufweist, bei der Autorisierungsstelle registriert, d. h. die entsprechende Elektronik des Schlüsselanhängers bzw. der Kreditkarte wird ausgelesen, an das mobile Endgerät übermittelt und von dort aus bei der Autorisierungsstelle hinterlegt. Somit ist es möglich, eine Bezahlanfrage sowohl von einer Kreditkarte als auch von einem Schlüs- selanhänger einheitlich derart durch die Autorisierungsstelle zu autorisieren, dass diese einem einzigen Benutzerkonto zuzuordnen sind. Dies erfolgt er- findungsgemäJß dadurch, dass lediglich diejenigen Zahlungsmittel autorisiert werden bzw. die Anfrage von lediglich denjenigen Zahlungsmittel autori- siert werden, für die eine Zahlungsmittelkennung bereits übermittelt ist. So- mit hat der Benutzer die Möglichkeit, alle seine Zahlungsmittel mittels der Zahlungsmittelkennung bei der Autorisierungsstelle zu hinterlegen. Möchte nunmehr ein anderer Benutzer mit seinem Zahlungsmittel zahlen, so erfolgt keine Autorisierung, falls diese Zahlungsmittelkennung nicht übermittelt wurde. Wurde sie jedoch übermittelt, so ist diese neue Zahlungsmittelken- nung eben auch einem neuen Benutzer zuzuordnen, und es kann zielgenau von demjenigen Benutzerkonto abgebucht werden, auf das das jeweilige Zahlungsmittel zugelassen ist. Gemäß einem weiteren Aspekt der vorliegenden Erfindung umfasst das Au torisieren ein Gruppieren des mindestens einen Zahlungsmittels. Dies hat den Vorteil, dass eine Vielzahl von Zahlungsmitteln registriert werden kön nen und die Zahlungsmittel derart gruppiert werden können, dass eine Gruppe von Zahlungsmitteln stets einem Benutzer bzw. einem Benutzerkon- to zuzuordnen ist. Auf diese Art kann mittels der Zahlungsmittelkennung festgestellt werden, welches Zahlungsmittel für welchen Nutzer registriert wurde, und es erfolgt ein Autorisieren bzw. ein Abbuchen nur bezüglich demjenigen Benutzer, dem das Zahlungsmittel auch zugeordnet ist. Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist die durch das mobile Endgerät jeweils übermittelte Zahlungsmittelkennung dem mobilen Endgerät zuzuordnen. Dies hat den Vorteil, dass eine Personalisierung nicht lediglich bezüglich dem Benutzerkonto stattfinden muss, sondern vielmehr können alle Zahlungsmittelkennungen, welche von einem speziellen Endge- rät übermittelt wurden, auch genau diesem speziellen Endgerät zugeordnet werden. Somit authentifiziert sich der Benutzer mittels seines mobilen End- geräts, und es können alle Zahlungsmittel, welche ihre Zahlungsmittelken- nung an das mobile Endgerät übermittelt haben, auch diesem mobilen End- 5 gerät zugeordnet werden. Beispielsweise liegt einem Netzbetreiber eine In- formation bezüglich dem mobilen Endgerät vor, und es können alle Zah lungsvorgänge mit denjenigen Zahlungsmitteln durchgeführt werden, wel- che dem mobilen Endgerät zuzuordnen sind. Beispielsweise ist es somit möglich, dass ein mobiles Endgerät, wie ein Smartphone, mehrere Zahlt) lungsmittel registriert, und somit es dem Netzbetreiber möglich ist, von der Telefonrechnung des Smartphonenutzers die jeweiligen Zahlungsanfragen abzubuchen. Somit kann sich der Nutzer stets mit einer Vielzahl von Zah lungsmittel ausweisen, wobei die Abrechnung stets über sein mobiles End gerät erfolgt.
5
Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist die durch das mobile Endgerät jeweils übermittelte Zahlungsmittelkennung genau einem Benutzerkonto zuzuordnen. Dies hat den Vorteil, dass eben eine eindeutige Identifizierung der Zahlungsvorgänge möglich ist, wobei potenziell eine0 Vielzahl von Zahlungsmitteln zum Einsatz kommen kann. Somit ist es erfin dungsgemäß möglich, dass der Benutzer mehrere Zahlungsmittel betreibt, diese jedoch stets eine Abbuchung von einem Benutzerkonto veranlassen.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird das Über-5 mittein jeweils einer Zahlungsmittelkennung über eine Luftschnittstelle
durchgeführt. Dies hat den Vorteil, dass beispielsweise eine Nearfield- Kommunikation zwischen dem Zahlungsmittel und dem mobilen Endgerät durchgeführt werden kann. So kann der Benutzer in einfacher Art und Weise ohne technischen Aufwand seine Zahlungsmittel an seinem Smartphone hin- terlegen. Beispielsweise ist es auch möglich, eine Kreditkarte abzufotografieren und beispielsweise mittels Texterkennung die entsprechenden Daten, wie z. B. eine Kreditkartennummer, zu hinter legen. Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird die Zah lungsmittelkennung mitsamt einer Sicherheitsinformation übermittelt und/oder hinterlegt. Dies hat den Vorteil, dass auch weitere Informationen bereitgestellt werden können, die dem Autorisieren dienen. Dies können beispielsweise öffentliche und geheime Schlüssel sein. Beispielsweise ist es mög- lieh, auch entsprechende Sicherheitsnummern, wie -beispielsweise eine PIN oder aber auch ein Passwort zu hinterlegen. Somit kann der Benutzer mit seinem physischen Zahlungsmittel bezahlen, und es kann auch eine Autori- sierung unter Verwendung der Autorisierungsdaten erfolgen. Somit sind seitens des Benutzers keine weiteren Eingaben erforderlich.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung hält das Zah lungsmittel eine Menge von Steuerbefehlen vor, und es werden Anfragen autorisiert, die von einer Teilmenge von Steuerbefehlen initiiert sind. Dies hat den Vorteil, dass beispielsweise der Benutzer angeben kann, welche Ap- plikationen auf dem Zahlungsmittel autorisiert werden dürfen und welche nicht. Beispielsweise hält das Zahlungsmittel, beispielsweise eine Smartcard, diverse Applikationen vor, und der Benutzer kann hierbei positiv beschrei ben, welche Applikationen an einem Zahlungsvorgang bzw. einem Initiieren einer Zahlungsanfrage teilnehmen dürfen. So ist es gemäß bekannten Ver- fahren möglich, eine Vielzahl von Softwarekomponenten auf einer Smartcard zu installieren. Erfindungsgemäjß müssen diese Smartcards lediglich dahin gehend angepasst werden, dass der Benutzer bestimmt, welche der Applika- tionen der Smardcard bei der Autorisierungsstelle registriert werden dürfen. Diese kör en dann am erfindungsgemäßen Verfahren teilnehmen, wobei weitere nicht vertrauenswürdige Applikationen nicht an der Autorisierung teilnehmen dürfen.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird eine weite- re Teilmenge von Steuerbefehlen mindestens eines Zahlungsmittels für die Autorisierung gesperrt. Dies hat den Vorteil, dass, falls auf dem Zahlungs mittel mehrere Applikationen hinterlegt sind, auch einzelne Applikationen gesperrt werden können. Hierbei ist die Teilmenge der Applikationen, die autorisieren dürfen und die Teilmenge von denen, die nicht autorisieren dür- fen, disjunct. Beispielsweise betreibt ein Benutzer ein sogenanntes Fitness- armband, welches mehrere Applikationen vor hält. Dies ist ebenfalls möglich, falls eine sogenannte Smartwatch zum Einsatz kommt. Hierbei lassen sich Einkaufsplattformen freischalten, derart, dass diese am erfindungsgemäßen Verfahren teilnehmen können, aber es können auch Anwendungen gesperrt werden, die dann nicht autorisiert werden. Speichert beispielsweise ein Be nutzer eine zurückgelegte Laufstrecke ab, und stellt diese Applikation eine Zahlungsanfrage, so handelt es sich typischerweise um einen Angriff auf die Kontoinformation. Somit kann diese Applikation von der Autorisierung ausgeschlossen werden. Ferner ist es möglich, dass der Benutzer mittels sei- nes Smartphones bzw. seiner Smartwatch eine Banking- Applikation betreibt, die dann für die Autorisierung freigeschaltet werden kann.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird ein Sperren eines Zahlungsmittels mittels dessen übermittelten Zahlungsmittelkennung durchgeführt. Dies hat den Vorteil, dass ein Benutzer einzelne Zahlungsmittel sperren kann. Hat der Nutzer beispielsweise in vorherigen Verfahrens schritten angegeben, dass eine gewisse Kreditkarte bei der Autorisierungs- stelle hinterlegt werden soll, und geht diese Kreditkarte verloren, so kann diese eben auch die Zahlungsmittelkennung übermitteln und somit die zu- gehörige Kreditkarte sperren. Während also ein Hinterlegen von Zahlungs mitteln möglich ist, so ist es auch möglich, diese Zahlungsmittel wieder von der Liste zu entfernen und die Zahlungsmittel somit zu sperren. Dies ist ins besondere deshalb vorteilhaft, da der Benutzer seine Zahlungsmittel selbst verwalten kann.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird zwischen der Autorisierungsstelle und dem mobilen Endgerät eine Zahlungsmittel verwaltungseinheit vorgesehen. Dies hat den Vorteil, dass zwischen dem Smartphone, also dem mobilen Endgerät, und der Autorisierungsstelle bei spielsweise ein Server zwischengeschaltet werden kann, der weitere Verar beitungsschritte übernimmt. Jedoch können mehrere Geräte verwaltet wer den, und die Autorisierung kann dann von der Zahlungsmittelverwaltungs einheit angefragt werden. Die Zahlungsmittelverwaltungseinheit dient somit der Entgegennahme der Zahlungsmittelkennungen.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung kommuniziert das mobile Endgerät mittels eines Mobilfunknetzes mit der Autorisierungs stelle. Dies hat den Vorteil, dass neben weiteren möglichen Komponenten ein Mobilfunknetzwerk zwischen dem mobilen Endgerät und der Autorisie rungsstelle angeordnet werden kann. So ist es beispielsweise möglich, dass das mobile Endgerät eine Datenverbindung mit einem Netzwerkbetreiber bzw. mit Komponenten, die von einem Netzwerkbetreiber bereitgestellt sind, aufbaut, und somit über die Luftschnittstelle die Zahlungsmittelkennungen bei der Autorisierungsstelle hinterlegt. Somit wird ein einfaches Verfahren geschaffen, mit dem der Benutzer selbstständig seine Zahlungsmittel bei ei ner Autorisierungsstelle hinterlegen kann. Die Aufgabe wird auch gelöst durch eine Registrierungsanordnung zum Re gistrieren von elektronischen Zahlungsmitteln, mit einer ersten Schnittstel leneinheit eingerichtet zum Übermitteln jeweils einer Zahlungsmittelken nung von mindestens einem Zahlungsmittel an ein mobiles Endgerät. Ferner ist eine zweite Schnittstelleneinheit vorgesehen, welche eingerichtet ist zum Hinterlegen der jeweils einen Zahlungsmittelkennung bei einer zentralen Autorisierungsstelle. Die zentrale Autorisierungsstelle ist eingerichtet zum Autorisieren einer Anfrage, wobei die Anfrage durch mindestens ein Zahlungsmittel initiiert wird, welches eine Zahlungsmittelkennung übermittelt hat, wobei das mobile Endgerät das Hinterlegen durchführt.
Die Aufgabe wird ferner gelöst durch ein Computerprogrammprodukt mit Steuerbefehlen, welche das vorgeschlagene Verfahren implementieren bzw. welche eingerichtet sind, die vorgeschlagene Registrierungsanordnung zu betreiben.
Im Folgenden wird die Erfindung beispielhaft anhand der beigefügten Figuren beschrieben. Es zeigt. Fig. 1: eine Registrierungsanordnung gemäß einem Aspekt der vor lie- genden Erfindung; und
Fig. 2: ein Verfahren zum Registrieren gemäß einem Aspekt der vorlie genden Erfindung. Fig. 1 zeigt eine Registrierungsanordnung, in der zwei Zahlungsmittel Ver wendung finden. Ein Zahlungsmittel ist beispielsweise ein Schlüsselanhänger, der entsprechende Kommunikationselektronik aufweist oder aber auch ein sogenanntes Fitnessarmband. Das mobile Endgerät ist vorliegend als ein Smartphone gezeigt. Links oben ist in der vorliegenden Fig. 1 eine Autorisie- rungsstelle eingezeichnet, die mit einer Zahlungsmittelverwaltungseinheit kommuniziert, die in der Mitte oben angezeichnet ist.
Zahlungsmittel, z. B. Kreditkarten, werden bei Produktion oder im Feld fest personalisiert. Eine sichere durch einen Nutzer kontrollierte Übertragung seiner Daten auf andere Zahlungsmittel, z. B. Wear ables, Smartphone und dergleichen, ist nicht möglich. Typischerweise besitzt jedes Zahlungsmittel seine eigenen Daten. Dieses Problem löst die Erfindung wie folgt. Der Nutzer soll mittels einer Applikation auf seinem Smartphone seine ver schiedenen Zahlungsmittel an einen Hintergrundserver bzw. ein Hinter grundsystem an- bzw. abmelden und für die jeweilige Zahlung nutzen können. Zur Anmeldung liest das Smartphone Daten aus dem Zahlungsmittel und sendet diese an das Hintergrundsystem, um das Zahlungsmittel bei dem Hintergrundsystem anzumelden, damit der Nutzer mit dem angemeldeten Zahlungsmittel eine Zahlung ausführen kann. Vorher eingebuchte Zah lungsmittel werden abgemeldet. Bei der Abmeldung kann der Benutzer mit tels seines Smartphones beliebige Zahlungsmittel bei dem Hintergrundsys tem bzw. bei der Autorisierungsstelle abmelden.
Hierdurch bestimmt der Nutzer, welche Zahlungsmittel aktiv sind. Ferner kann er ein- und dieselben Daten auf mehreren Zahlungsmitteln nutzen. Somit ist insbesondere eine vorteilhafte Lösung für eine Wearable- Technologie bereitgestellt.
Somit ist es ein Einsatzszenario der vorliegenden Erfindung, dass typischer weise ein Benutzer keine kontrollierte Übertragung seiner eigenen Daten, wie z. B. Karten-Daten, PAN, PIN, Applikationen, Schlüssel und dergleichen, auf ein anderes Endgerät durchführen kann. Beispielsweise besitzt ein Card- holder Zahlungsgeräte, in verschiedenen Ausprägungen, z. B. Kreditkarten, Wearable von Hersteller A, Wearable von Hersteller B, mobile Endgeräte oder dergleichen und möchte diese abwechselnd mit den gleichen Karten- Daten nutzen. Typischerweise besitzt jedoch jedes Gerät seine eigene Karten- Identifizierung, z. B. eigene Primary Account Number, eigene Schlüssel und dergleichen. Somit soll dem Nutzer die Möglichkeit gegeben werden, seine Karten-Daten, flexibel, selbstständig aber kontrolliert auf verschiedenen Zahlungsendgeräten nutzen zu können und gleichzeitig Missbrauch der Daten durch Dritte vorzubeugen.
Besonders vorteilhaft ist es, eine Applikation vorzuhalten, welche auf einem Gerät, z. B. einem Smartphone, installiert ist. Das genannte Gerät kann über eine Kontaktlos-Schnittstelle, z. B. NFC, Bluetooth oder dergleichen verfü gen. Des Weiteren wird ein zentrales Hintergrund-System bzw. eine Autori- sierungsstelle benötigt, welche über eine der genannten Schnittstellen mit den jeweiligen Geräten verbunden ist. Der Nutzer soll mit diesem System in die Lage versetzt werden, seine verschiedenen Zahlungsgeräte flexibel im genannten Hintergrund-System an- und abzumelden und diese dann für den jeweiligen Zahlungsvorgang nutzen zu können. Wie dieser An- und Abmel- devorgang im Detail aussieht, wird im Folgenden beispielhaft beschrieben.
Der Nutzer hält das gewünschte Zahlungsmittel an das Gerät, welches eine entsprechende Kontaktlos-Schnittstelle, z. B. NFC, Bluetooth, Low-Energy oder dergleichen zur Verfügung stellt, und auf dem die Applikation zur Verwaltung der Kartendaten bzw. Geräte läuft. Eine Verbindung zum Hin tergrund-System bzw. zur Autorisierungsstelle zwischen dem Gerät mit der Kontaktlos-Schnittstelle und dem System selbst muss zu diesem Zeitpunkt bereits etabliert sein. Aus dem Zahlungsendgerät können dann gerätespezifische Daten ausgele sen und an das Hintergrundsystem übermittelt werden, z. B. eine TAN, Cardholder-Name und dergleichen. Die ausgelesenen Daten werden an- schließend an das Hintergrund-System übermittelt, um dort das jeweils vor- liegende Gerät„einzubuchen" bzw. zu registrieren. Sollte es sich bei dem Zahlungs-Gerät z. B. um eine Display- Karte, Multiapplikation-Karte ham- deln, so kann der Nutzer in diesem Registrierungsschritt zudem ausführen, welche seiner auf dem Zahlungsendgerät befindlichen Applikationen aktiv geschalten werden sollen. Im Hintergrund-System bzw. der Autorisierungs- stelle wird diese Information dann gespeichert, und der Nutzer kann mit dem neu aktivierten Zahlungsmittel nun bezahlen. Vorher registrierte Zah lungsmittel können automatisch am System abgemeldet werden.
Analog hierzu kann dem Benutzer auch die Möglichkeit gegeben werden, mehrere Zahlungsmittel mit den gleichen Karten-Daten zu verknüpfen, so fern die Geräte alle physisch vorliegen. Diese Mehrfachverknüpfung muss dann entsprechend vom Hintergrund-System bzw. von der Autorisierungs- stelle gehandhabt werden. Beispielsweise kann jedes Zahlungsmittel system seitig über ein sogenanntes Payment-Token abgebildet werden.
Ferner kann der Nutzer auch das beschriebene Vorgehen derart nutzen, dass eine oder mehrere Zahlungsmittel wieder abgemeldet werden. Dies kann auch durch nicht-physisches Vorliegen des Zahlungsmittels mithilfe der Ap plikation erfolgen. Das gewählte Zahlungsmittel wird dann im Hintergrund- System wieder abgemeldet.
Der Nutzer erhält die Möglichkeit, flexibel zu steuern, welche seiner Zah lungsmittel aktiv bzw. inaktiv sind. Des Weiteren wird er in die Lage ver- setzt ein- und dieselben Karten-Daten, auch Zahlungsidentität genannt, auf ein oder mehreren Zahlungsmitteln zu nutzen.
Eine Notwendigkeit dieses flexible Zahlungsidentitäts- bzw. Zahlungsendge- rät-Management oder auch das Zahlungsmittel-Management wird u. a.
dadurch notwendig, dass die Anzahl von sogenannten Wearables steigt. So- mit sollte der Nutzer selbst in der Lage sein, seine Karten-Daten z. B. auf ein neues T-Shirt zu laden, ohne seine Ban um eine Over-the-Air- Personalisierung bitten zu müssen.
Fig. 2 zeigt ein Verfahren zum Registrieren von elektronischen Zahlungsmit teln, wobei in einem ersten Schritt 100 ein Übermitteln jeweils einer Zah lungsmittelkennung von mindestens einem Zahlungsmittel an ein mobiles Endgerät erfolgt. In einem darauffolgenden Verfahrensschritt 101 erfolgt ein Hinterlegen der jeweils einer Zahlungsmittelkennung bei einer zentralen Au- torisierungsstelle. In Verfahrensschritt 102 erfolgt ein Autorisieren einer An frage durch die zentrale Autorisierungsstelle, wobei die Anfrage durch min destens ein Zahlungsmittel initiiert wird, welches eine Zahlungsmittelkennung übermittelt hat. Das mobile Endgerät führt hierbei das Hinterlegen 101 durch. Das Initiieren der Zahlungsanfrage bzw. der Anfrage in Schritt 103 kann derart erfolgen, dass dies zu jeder Zeit erfolgen kann. Für ein Autori sieren 102 ist es jedoch erforderlich, dass die Zahlungsmittelkennung bereits hinterlegt ist. Ferner ist es möglich, einzelne Schritte iterativ auszuführen. Beispielsweise können die Schritte 100 und 101 derart iterativ ausgeführt werden, dass nach und nach alle Zahlungsmittelkennungen der vorhandenen Zahlungsmittel zuerst übermittelt und dann hinterlegt werden. Somit kann auch das Über mitteln an sich iterativ erfolgen, und in einem einzigen weiteren Verfahrens- schritt erfolgt ein Hinterlegen 101 von allen zuvor übermittelten Zahlungs- mittelkennungen.
In einem optionalen Verfahrensschritt 104 erfolgt ein Sperren von Zah- lungsmittein. Möchte beispielsweise ein Benutzer ein Zahlungsmittel abmelden, weil er beispielsweise seine Kreditkarte verloren hat, so kann er dies ebenfalls an die Autorisierungsstelle übermitteln, und diese löscht dann die Zahlungsmittelkennung, wodurch ein Missbrauch vermieden wird. Somit wird ein sicheres und dennoch technisch einfaches Verfahren zur sicheren Verwaltung von mehreren Zahlungsmitteln, welche jeweils physisch vorliegen, vorgeschlagen.

Claims

P a t e n t a n s p r ü c h e 1. Verfahren zum Registrieren von elektronischen Zahlungsmitteln, mit den Schritten:
Übermitteln (100) jeweils einer Zahlungsmittelkennung von rnindes- tens einem Zahlungsmittel an ein mobiles Endgerät;
Hinterlegen (101) der jeweils einen Zahlungsmittelkennung bei einer zentralen Autorisierungsstelle; und
Autorisieren (102) einer Anfrage durch die zentrale Autorisierungs- stelle, wobei die Anfrage durch mindestens ein Zahlungsmittel initiiert (103) wird, welches eine Zahlungsmittelkennung übermittelt hat, dadurch ge kennzeichnet, dass das mobile Endgerät das Hinterlegen (101) durchführt.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das min- destens eine Zahlungsmittel als ein physisches Zahlungsmittel vorliegt.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das mindestens ein Zahlungsmittel als eine Kreditkarte, ein Wearable, ein Token, ein Schlüsselanhänger, ein Sticker und/ oder ein mobiles Endgerät vorliegt.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Autorisieren (102) ein Gruppieren des mindestens einen Zahlungsmittels umfasst.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch ge kennzeichnet, dass die durch das mobile Endgerät jeweils übermittelte Zah lungsmittelkennung dem mobilen Endgerät zuzuordnen ist.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch ge kennzeichnet, dass die durch das mobile Endgerät jeweils übermittelte Zah- lungsmittelkennung genau einem Benutzerkonto zuzuordnen ist.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch ge- kennzeichnet, dass das Übermitteln (100) jeweils einer Zahlungsmittelken- nung über eine Luftschnittstelle durchgeführt wird.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch ge kennzeichnet, dass die Zahlungsmittelkennung mitsamt einer Sicherheitsin- formation übermittelt und / oder hinterlegt wird.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch ge kennzeichnet, dass das Zahlungsmittel eine Menge von Steuerbefehlen vor hält und Anfragen autorisiert (102) werden, die von einer Teilmenge von Steuerbefehlen initiiert (103) sind.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch ge kennzeichnet, dass eine weitere Teilmenge von Steuerbefehlen mindestens eines Zahlungsmittels für die Autorisierung gesperrt (104) wird.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch ge- kennzeichnet, dass ein Sperren (104) eines Zahlungsmittels mittels dessen übermittelten Zahlungsmittelkennung durchgeführt wird.
12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zwischen der Autorisierungsstelle und dem mobilen Endgerät eine Zahlungsmittelverwaltungseinheit vorgesehen wird.
13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch ge kennzeichnet, dass das mobile Endgerät mittels eines Mobilfunknetzes mit der Autorisierungsstelle kommuniziert.
14. Registrierungsanordnung zum Registrieren von elektronischen Zah- lungsmittein, mit: einer ersten Schnittstelleneinheit eingerichtet zum Übermitteln jeweils einer Zahlungsmittelkennung von mindestens einem Zahlungsmittel an ein mobiles Endgerät; einer zweiten Schnittstelleneinheit eingerichtet zum Hinterlegen der jeweils einen Zahlungsmittelkennung bei einer zentralen Autorisierungsstel- le; und - die zentrale Autorisierungsstelle eingerichtet zum Autorisieren einer
Anfrage, wobei die Anfrage durch mindestens ein Zahlungsmittel initiiert wird, welches eine Zahlungsmittelkennung übermittelt hat, dadurch ge- kennzeichnet, dass das mobile Endgerät das Hinterlegen durchführt.
15. Computerprogrammprodukt mit Steuerbefehlen, welche das Verfah ren gemäß einem der Ansprüche 1 bis 13 implementieren.
EP19716061.7A 2018-03-15 2019-03-11 Registrieren von elektronischen zahlungsmitteln Ceased EP3766032A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102018002122.0A DE102018002122A1 (de) 2018-03-15 2018-03-15 Registrieren von elektronischen Zahlungsmitteln
PCT/EP2019/000076 WO2019174783A1 (de) 2018-03-15 2019-03-11 Registrieren von elektronischen zahlungsmitteln

Publications (1)

Publication Number Publication Date
EP3766032A1 true EP3766032A1 (de) 2021-01-20

Family

ID=66092278

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19716061.7A Ceased EP3766032A1 (de) 2018-03-15 2019-03-11 Registrieren von elektronischen zahlungsmitteln

Country Status (4)

Country Link
US (1) US20200410473A1 (de)
EP (1) EP3766032A1 (de)
DE (1) DE102018002122A1 (de)
WO (1) WO2019174783A1 (de)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050222961A1 (en) * 2004-04-05 2005-10-06 Philippe Staib System and method of facilitating contactless payment transactions across different payment systems using a common mobile device acting as a stored value device
WO2008008830A2 (en) * 2006-07-11 2008-01-17 Mastercard International Incorporated Wearable contactless payment devices
US9947002B2 (en) * 2008-02-15 2018-04-17 First Data Corporation Secure authorization of contactless transaction
US20160019536A1 (en) * 2012-10-17 2016-01-21 Royal Bank Of Canada Secure processing of data
WO2015058300A1 (en) * 2013-10-25 2015-04-30 Nanopay Inc. Systems, methods and devices for generating secure electronic authentication and payment processing
US20160379215A1 (en) * 2015-06-29 2016-12-29 Mastercard International Incorporated Method and system for supervisory control of payment transactions
US20170076274A1 (en) * 2015-09-16 2017-03-16 First Data Corporation Authentication systems and methods

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PEREZ SARAH: "ZipPay To Launch New Mobile Payments Service Cheaper Than Square | TechCrunch", 9 October 2011 (2011-10-09), pages 1 - 3, XP055934802, Retrieved from the Internet <URL:http://web.archive.org/web/20111009112357/https://techcrunch.com/2011/10/07/zippay-to-launch-new-mobile-payments-service-cheaper-than-square/> [retrieved on 20220623] *

Also Published As

Publication number Publication date
DE102018002122A1 (de) 2019-09-19
WO2019174783A1 (de) 2019-09-19
US20200410473A1 (en) 2020-12-31

Similar Documents

Publication Publication Date Title
DE69736752T2 (de) System und Vorrichtung zum Personalisieren von Chipkarten
AT512070B1 (de) Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen
DE102008000895B4 (de) Verwendung eines mobilen Telekommunikationsgeräts als elektronische Gesundheitskarte
DE10297521T5 (de) Verbraucher-zentrisches kontext-bewußtes Vermittlungsmodell
EP2898483A1 (de) VERFAHREN UND SYSTEM ZUR KONFIGURATION VON KLEINSCHLIEßANLAGEN
WO2016037841A1 (de) Verfahren und vorrichtung zur steuerung eines kassensystems
EP1254436A1 (de) Verfahren zur nutzeridentitätskontrolle
DE102011116489A1 (de) Mobiles Endgerät, Transaktionsterminal und Verfahren zur Durchführung einer Transaktion an einem Transaktionsterminal mittels eines mobilen Endgeräts
EP3246865A1 (de) Verfahren und anordnung zur übermittlung von transaktionsdaten unter nutzung eines öffentlichen datennetzes
EP3254432B1 (de) Verfahren zur berechtigungsverwaltung in einer anordnung mit mehreren rechensystemen
EP1525731B1 (de) Identifikation eines benutzers eines mobilterminals und generierung einer aktionsberechtigung
DE102011079317A1 (de) Mobiles system für finanztransaktionen
EP3766032A1 (de) Registrieren von elektronischen zahlungsmitteln
DE102015011076A1 (de) Transaktionssystem
DE102007024144B3 (de) Verfahren und Anordnung zur schnellen Kurzanmeldung eines Benutzers an einem Diensleistungsportal mittels einer mobilen Kommunikationseinrichtung
EP2369543A1 (de) Mobiles elektronisches Gerät mit Authentifizierungsfunktion zur Nutzung transaktionsbasierter Dienste und dieses umfassendes System
DE202019101478U1 (de) Automatisiertes Steuersystem einer Kette von aufeinanderfolgenden, miteinander verbundenen Transaktionen einer elektronischen Plattform für das Internet-Zahlungssystem
EP1596615B1 (de) Sim-karte mit veränderbarem speicher und methode dafür
DE102023125223A1 (de) Anordnung zur Bereitstellung eines digitalen Schlüssels für ein Fahrzeug auf einem Nutzergerät, Verfahren, Computerprogramm sowie Speichermedium
DE102013000967B4 (de) Verfahren zur Autorisierung einer elektronischen Transaktion
DE10151200A1 (de) System, Verfahren und Computerprogramm-Produkt zur Erzeugung und/oder Verwendung einer mobilen Digitalkarte
WO2007016920A1 (de) Vorrichtung, verfahren und anlagensystem zur interaktion mit einem benutzer sowie verfahren zur aufnahme eines benutzers in eine geschlossene benutzergruppe
DE102021003724A1 (de) Verfahren zur ldentifikation einer Person durch eine Kreditkartennummer und ldentifikationssystem
DE102020119512A1 (de) Verfahren zur Speicherung von verifizierten Identitätsdaten eines Endnutzers, Verfahren zur Bereitstellung von verifizierten Identitätsdaten an eine Akzeptanzstelle, Computerprogrammprodukt
WO2022253424A1 (de) Transaktionssystem für dezentral in einem rechnernetzwerk gespeicherte kryptographische vermögenswerte

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20201015

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RIN1 Information on inventor provided before grant (corrected)

Inventor name: FINKENZELLER, KLAUS

Inventor name: BALDISCHWEILER, MICHAEL

Inventor name: BEHLENDORF, SASCHA

Inventor name: KLUGE, STEFAN

Inventor name: TARANTINO, THOMAS

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20220629

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20221127