WO2011107237A1 - Mobilfunkbasiertes transaktionssystem - Google Patents

Mobilfunkbasiertes transaktionssystem Download PDF

Info

Publication number
WO2011107237A1
WO2011107237A1 PCT/EP2011/000910 EP2011000910W WO2011107237A1 WO 2011107237 A1 WO2011107237 A1 WO 2011107237A1 EP 2011000910 W EP2011000910 W EP 2011000910W WO 2011107237 A1 WO2011107237 A1 WO 2011107237A1
Authority
WO
WIPO (PCT)
Prior art keywords
mobile
transaction
user
location
client
Prior art date
Application number
PCT/EP2011/000910
Other languages
English (en)
French (fr)
Inventor
Patrick Ams
Original Assignee
Patrick Ams
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 Patrick Ams filed Critical Patrick Ams
Priority to EP11707339A priority Critical patent/EP2543010A1/de
Publication of WO2011107237A1 publication Critical patent/WO2011107237A1/de

Links

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/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • 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/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224—Transactions dependent on location 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile 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/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • 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
    • G06Q20/4014—Identity check for transactions
    • 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
    • G06Q20/4014—Identity check for transactions
    • G06Q20/40145—Biometric identity checks
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1025—Identification of user by a PIN code
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0846—Network architectures or network communication protocols for network security for authentication of entities using passwords using time-dependent-passwords, e.g. periodically changing passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/065—Continuous authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information

Definitions

  • the present invention has for its object to provide a highly secure, cashless payment and transaction system for one or more users available.
  • a cashless payment system in which instead of the previously used credit card, usually a credit card or a debit card made of plastic material, the mobile phone occurs.
  • NFC Near Field Communication
  • PDA Personal Digital Assistant
  • transactions can also be carried out between two users, reciprocal scanning of the mobile phones or PDAs or other communication devices being conceivable.
  • Authentication or identification via a barcode or NFC method, or via another optical / graphical or electromagnetic or sound-based identification signal in combination with a mobile Telephone or a PDA can also be used for other purposes, such as a customer card or to identify employees.
  • the transaction process proposed according to the invention starts with a bar code or another optical or graphic, electromagnetic or sound-based signal being requested by a user manually or automatically via the mobile telephone, the personal digital assistant (PDA) or another communication device .
  • PDA personal digital assistant
  • a wireless connection is established with the transaction terminal, which ensures a secure connection of the mobile phone, PDA or other communication device to the central system server.
  • This secure wireless connection established in the absence of a wireless network connection requests a barcode or other identification over that connection.
  • the barcode or other optical / graphic or electromagnetic information is generated by the central system server and sent to the requesting mobile or PDA or other requesting communication device.
  • the bar code or an alternative optical / graphic or electromagnetic signal is sent to the transaction terminal, e.g. a modified card reader, as it is widely used today, scanned or read.
  • the generated read or scanned identification is transmitted together with transaction information to the central system server.
  • the barcode can also be displayed as a number combination on the display of the mobile phone. As a result, the use of the mobile-based transaction system is also possible if the transaction terminal has no reading unit for barcodes or this is damaged.
  • this central system server which has generated the barcode or the other identification, checks the identification, the transaction information, security criteria, such as location and time, and possibly other restrictions, such as a possibly existing transaction limit, such as an account limit at a bank.
  • the central system server sends the transaction request via the radio network connection or, if it does not arrive via the protected wireless connection, via the transaction terminal to the requesting user. This confirms the transaction or rejects it. Upon confirmation, the transaction is executed and sent as executed to the transaction terminal. If rejected by the user (user), the transaction is aborted.
  • the transaction process can also be represented as follows.
  • the bar code or the other optical / graphic or electromagnetic information or identification signal is generated directly in the mobile phone or the PDA or a differently configured communication device.
  • the bar code or an alternative optical / graphic or electromagnetic signal is then scanned or read at the transaction terminal, such as a modified card reader, as it is widely used today.
  • the generated read or scanned identification is transmitted together with transaction information to the central system server.
  • this central system server which in the same way generates the barcode as the mobile phone, checks the identification transmitted by the transaction terminal, the transaction information, security criteria, e.g. Place and time, and possibly other restrictions, e.g. a possibly existing transaction limit, e.g. an account limit with a bank.
  • the central system server returns the transaction request to the transaction terminal for confirmation.
  • the user confirms the transaction or rejects it.
  • the user may e.g. enter a PIN number at the transaction terminal.
  • the entry of a PIN number at the transaction terminal may be made either directly after scanning the bar code or only after the central system server has verified the identification, transaction information and security criteria transmitted by the transaction terminal.
  • the user can also enter a PIN code on the mobile phone or PDA before the barcode is generated.
  • the transaction is executed and sent as executed to the transaction terminal. If rejected by the user (user), the transaction is aborted. This transaction process is particularly advantageous when the user resides abroad and thus incur high fees for data communication between the central system server and the mobile phone.
  • the bar code generated by the central system server or alternatively the other graphic / optical or electromagnetic signal is generated in the system server and the validity of the generated bar code or the alternative identification is limited in time.
  • the time limit may e.g. limited to 300 seconds.
  • the generation of the barcode within the mobile phone or PDA or a differently configured communication means may be used.
  • a location system such as the Global Positioning System (GPS) or another satellite-based location system
  • GPS Global Positioning System
  • a determination of the location of the user (user) via the radio network in question such as the network in which the mobile phone provides communication services. If the location of the user and the location of the identification do not match, the transaction is rejected. Furthermore, a rejection of the transaction takes place when the distance between two or more identification locations is too large to be covered in a defined period of time.
  • the location of the user can be determined either on demand, ie arbitrarily, continuously or at well-defined time intervals, which provides the plausibility of a comparison of the location, ie the location of the user with the location in which the identification is to be made, in addition plausibilized and the meaningfulness increased drastically.
  • the satellite-based location system such as e.g. the Global Positioning System (GPS), or another satellite positioning system, to determine the location of the user.
  • GPS Global Positioning System
  • the location of the user can be determined via the radio network in which the user's mobile phone or PDA is integrated via the corresponding radio network or mobile radio network. If the user is within or outside a defined geographic location, depending on the point of view, the requested transaction may be rejected.
  • the definition is the localization of the user, who must be either inside or outside a defined geographic location to perform the plausibility check of the requested transaction.
  • the theft protection primarily relates to the theft of the communication device, ie in this case the theft of the mobile phone or the PDA (Personal Digital Assistant).
  • the entry of a ⁇ is required upon confirmation of the transaction.
  • the theft protection implemented above within security level 3 it is possible to display a photo of the user on the transaction terminal. This means that the central server sends a photograph of the user deposited there to the relevant transaction terminal carrying out the identification on site.
  • the solvency can also be obtained if there is no wireless connection between the mobile phone or the PDA or another electronic communication device to a regular radio network.
  • a data radio connection e.g. Bluetooth, which establishes a connection to the point-of-sale terminal via which a direct connection to the central server, which was not accessible via the regular radio network, is established.
  • a point-of-sale terminal as a data radio connection to the server.
  • the embodiment variant described above can also be used here, in which a barcode is generated in the mobile telephone or PDA or another communication device and then scanned. In this embodiment can be completely dispensed with a direct connection between the mobile phone and server.
  • transactions can also be performed between multiple users by scanning the bar code or the other graphic or visual identification feature interchangeably. All that is required is that the mobile phone or Personal Digital Assistant has a camera.
  • the security is given again by the position, since when scanning a barcode from a device A to a device B both devices must have the same position.
  • the central server can send a barcode or another suitable optical or electromagnetic signal to a website with the involvement of the Internet.
  • the user just scans this barcode, which is displayed on the monitor of a transaction terminal, from the screen of the same.
  • the user uses his mobile phone, which sends the scanned barcode to the central server. This in turn sends the payment request to the mobile phone, where it is still to be confirmed by the user before the transaction is executed.
  • the proposed transactions according to the invention can be carried out both in single and multi-user mode.
  • a user can create a single-user open account or create a multiple user account.
  • multiple user accounts can be managed through a master account.
  • the user can use a correspondingly configured website on the Internet to manage the user account, be it a single user account or a multi-user account, and set geographical and temporal limits.
  • the user can set transaction limits for locations and times that are valid for both a single-user account and a multi-user account.
  • the bar code or an NFC signal may e.g. be exchanged as an image file between each party or in the form of data, which can then be converted by the client into a barcode.
  • Security Levels 1 through 3 described above allow two-factor authentication based on the knowledge and ownership factors. With reference to a debit card, it should be stated here that the factor “knowledge” is formed by personal identification number (PIN) and the factor “possession” by the "EC card". Only the combination of the two factors makes it possible to withdraw money from the ATM or pay at EC terminals.
  • PIN personal identification number
  • a one-time password is generated, which authorizes the user in connection with the PIN.
  • the one-time password is generated either via a handy password generator (client) or with the interposition of software.
  • client a handy password generator
  • the prerequisite for the one-time password procedure is that both parties, i. Client and server, have a common, secret password. From this shared secret password now a series of one-time passwords (One Time Passwords: OTP's) generated.
  • servers and clients always calculate new passwords at fixed time intervals.
  • the server performs the same calculation as the client, the server generally accepts and calculates multiple one-time passwords within a tolerance range. This allows for the fact that the built-in token clock may not be one hundred percent synchronous. Nevertheless, each one-time password has a precisely defined time interval for its validity, generally between 1 and a maximum of 15 minutes.
  • the server performs the same computation that has already occurred on the client side, as in the timed procedure, and again, the server computes and accepts several one-million passwords in a tolerance range, except for one-time passwords already used. This is because the owner occasionally could not use a generated password. This procedure is much gentler for the batteries of a corresponding device (tokens). It is also possible to operate the process without permanent power supply by simply saving the last value used and thus already depreciated.
  • the server issues a task, i. the request that the client needs to answer (answer).
  • the client thus contains a value of the server as input and calculates a one-time password based thereon.
  • the application sends on the mobile phone, the client representing, in addition to the user ID and a one-time password to the server. From this, the server generates a barcode, which it sends back to the client. The barcode is then scanned at the transaction terminal and sent to the server along with the transaction data. The server then sends a payment request to the client, which is confirmed by the user by entering ⁇ . To speed up the transaction, the input of the PIN can be waived up to a predetermined amount.
  • the application sends the user ID to the server on the mobile telephone which represents the client. From this, the server generates data for a barcode, which in turn is sent back to the client. The client extends this barcode data with a one-time password and generates the final barcode. This is then scanned at the transaction terminal and transmitted to the server together with the transaction data. The server compares the data of the barcode with the previously sent data and the one-time password. Thereafter, the server sends a payment request to the client, which is acknowledged by the user by entering the PIN. The PIN can be entered either at the client or at the transaction terminal. To speed up the transaction, the input of the PIN can be waived up to a predetermined amount.
  • the application generates on the mobile phone, which represents the client, a barcode from the personal user ID and a one-time password.
  • the central system server calculates the same one-time password in parallel.
  • the generated barcode is then scanned at the transaction terminal and transmitted to the server together with the transaction data.
  • the server compares the one-time password contained in the barcode data with the one-time password calculated for that user. If both one-time passwords match, and the verification of further security criteria (transaction limit, position determination) was positive, the server then sends a payment request either to the client or to the transaction terminal, which the user confirms by entering the PIN.
  • the PIN can be entered either at the client or at the transaction terminal.
  • the input of the PIN can be waived up to a predetermined amount.
  • the PIN can also be entered at the beginning in the mobile phone, for example, to start the generation of the barcode.
  • another security check can be installed within this level. Since the calculation of the one-time password occurs in parallel in the mobile phone as well as in the system server, this can also be used to check the identity of the server.
  • the server sends a one-time password to the mobile during the transaction process. Since this must match the one-time password calculated by the mobile phone at this time, the mobile phone can securely verify that it is a "real" system server.
  • a user-related security level can be called in.
  • biometric features of the user can be adjusted, e.g. Finger or hand prints, iris or face, or information from a passport.
  • a Bluetooth dongle can be used, which unlocks the application in the client or optionally an RFID card.
  • the transaction terminal provides an alternative connection in this case.
  • the client application establishes a data radio connection between the transaction terminal, such as Bluetooth, which is either a constant Connects to the authorization server, such as over the Internet, or establishes a dial-up connection for authorization.
  • the client application then communicates with the server via this data channel.
  • the determination of location is in this case provided by the transaction terminal, the remaining components of the security check run as described above.
  • the barcode can also be displayed as a number combination on the display of the mobile phone.
  • the use of the mobile-based transaction system is possible even if e.g. the transaction terminal has no reading unit for barcodes or is damaged.
  • the application with mobile telephone and barcode is understood to mean an application with the mobile telephone and with NFC (near-field communication).
  • NFC near-field communication
  • the NFC process is the contactless payment method currently favored by credit card companies.
  • NFC Near-Fild Communication
  • NFC refers to a transmission standard that is used for the contactless exchange of data over short distances.
  • NFC serves as an access key to content and services such as cash-based payments, ticket orders, online entertainment and access control.
  • the necessary security functions are generally integrated in the NFC hardware.
  • the mobile in the context of the invention, the mobile as
  • Payment device are used in which the users of the mobile phone keep this close to a payment terminal, so that just the near-field communication can take place.
  • the payment function on a mobile phone requires integration of this into existing SIM card infrastructures.
  • the NFC technology is based on the combination of smart card and contactless connection techniques.
  • the NFC operates in a frequency range of 13.56 megahertz and offers a maximum data transfer rate of 424 kBit / sec. At a range of only 10cm. This is desirable so that contact can be interpreted as consent to a transaction.
  • NFC is standardized by ISO 14443, 18092, 21481 ECMA 340, 352, 356, 362 and ETSI TS 102 and 190 respectively.
  • the communication between NFC-capable devices, ie mobile phone and payment terminal can be both active-passive and active-active (peer-to-peer) in contrast to the conventional contactless technology in this frequency range, which generally runs only active-passive .
  • the use of the NFC method thus creates a connection
  • the NFC standard is largely compatible with widely used smart card infrastructure used based, for example, on ISO / IEC 14443-A and ISO / IEC 14443-B, respectively.
  • the NFC standard can be used as a substitute for barcodes, for example when electronic ticket purchase or as proposed by the invention, for processing payment transactions, especially where where the necessary amounts of data can not be transmitted in a meaningful number of barcodes.
  • FIG. 1 shows the basic structure of the multilevel safety system proposed according to the invention
  • Figure 2 shows a first embodiment of a communication between a
  • Figure 3 shows a further embodiment of a communication scheme between
  • FIG. 4 shows an embodiment variant of a communication between a system server, a mobile telephone and a transaction terminal, wherein the transaction terminal maintains a normal connection to the system server and a different radio connection to the mobile telephone and
  • FIG. 5 shows the basic structure of the invention proposed
  • Multi-level security system with three different two-factor authentication methods.
  • FIG. 6 shows an embodiment variant when the mobile telephone calculates the one-time password and the barcode without a direct connection to the system server.
  • FIG. 7 shows a variant embodiment, which allows the mobile phone to check the authenticity of the system server and
  • FIG. 8 shows a mobile telephone which is used to transmit a barcode of an invoice to a bank.
  • FIG. 1 shows the structure of the multilevel safety system in a schematic manner.
  • NFC i. Near-field communication is synonymous and used interchangeably with the term barcode.
  • the inventive mobile radio-based transaction system for processing a cashless payment transaction secure transactions are ensured by various security mechanisms on several levels 12, 14, 20.
  • the first level 12 and the second level 14 with their processes carried out there enable the generation of highly secure transactions.
  • the two-factor authentication 18 takes place.
  • a location match 16 is made between the user's location, i. the current location of a mobile phone 36 that communicates with a mobile network 32 with the location of a transaction terminal 34 where a current transaction is currently in progress.
  • the multilevel security system 10 includes another third tier 20 besides the first tier 12 and the second tier 14. While the first two tier 12, 14 are implemented by default, security may be enhanced by the additional, user-related third tier 20.
  • biometric features of the user client
  • the biometric features may be, for example, fingerprints or handprints, the iris of the eye or the features of the face.
  • information from an official identity document can be stored in the third level.
  • a Bluetooth dongle can also be used here, which activates the application in the client or an RFID card. The client checks whether a Bluetooth dongle or the RFID card are in the immediate vicinity, such as in the user's pocket or keychain.
  • the mobile-based transaction system comprises, as shown in Figure 2, a mobile network 32 in which the user is involved by using the at least one mobile phone 36, a transaction terminal 34 at a gas station in a department store or at an airport, for example at least one system server 38.
  • the location matching 16 to be carried out in the second level 14 of the multilevel security system 10 according to FIG. 1 is such that the client, i. the user of the at least one mobile phone 36 requests a barcode from the at least one system server 38. With this request, he also sends, among other data, his current location, i. the location at which the respective user uses the respective at least one mobile phone 36 at the moment and at that moment.
  • the determination of this location can be carried out either from a first position data transmission 40, which is performed by the GPS system 30, or from a location of the at least one mobile telephone 36 and thus its user within the mobile network 32.
  • the location of the same is determined via an identification of the at least one transaction terminal 34, at which the current transaction is in progress.
  • the transaction is rejected.
  • a comparison of the location of the implementation of the respective current transaction with the location of a previously performed transaction can be compared to a certain extent as a second component. Based on the assumption that the user of the at least one mobile phone 36 can change his location only with a certain speed, transactions whose spatial distance is not plausible with the time interval are rejected.
  • the user ie the user, can zer of at least one mobile phone 36, make further location-dependent restrictions. These include, for example, geographic restrictions regarding the web interface. There is the possibility that the user logs on via his website into his webaccount. There, the user can then mark, for example, on a road map areas in which the use is to be allowed or should be prohibited. In this approach, different patterns of expression are possible, for example, postcodes, cities, states or other areas of use can be approved or not allowed by appropriate coding.
  • the location comparison 16 which takes place on the second level 14 of the multilevel security system 10 can either be carried out continuously or at predetermined times, for example every 10 minutes.
  • a location comparison 16 can also be made in the second level 14 if a corresponding request is sent to the at least one system server 38.
  • site comparisons 16 are preferable, but require relatively high energy input.
  • the user ie the client in the form of the at least one mobile telephone 36, sends a one-time password and the current location to the at least one user ID in the context of a first connection 44 System server 38.
  • the location may be determined via either the cellular network 32 or a satellite-based navigation system 30.
  • the at least one system server 38 generates a barcode, which is reported back to the user of the at least one mobile telephone 36, ie the client, within a second connection step 46.
  • the barcode is then sent within a third connection 48 to the at least one transaction terminal 34 or scanned by this and transmitted from there, compare position 34, in the context of a fourth connection step 50 to the at least one system server 38, see position 50 in Figure 2.
  • the System server 38 compares the barcode transmitted in connection 50 with the barcode transmitted in connection 46. If both barcodes are identical, the at least one system server 38 sends a payment request, compare fifth connection 52, to the client, ie the user of the at least one mobile phone 36.
  • a seventh connection step 56 proceeds, after which the confirmation of the transaction from the at least one system server 38 to the at least one transaction terminal 34 is confirmed.
  • the components 30, 32, 34, 36 and 38 are identical, as are the connection steps 44 to 56.
  • the differences between the embodiment variant shown in FIG. 2 and the embodiment variant illustrated in FIG will be briefly described below.
  • the client i. the user of the at least one mobile telephone 36 sends a user ID and location information to the at least one system server 38 as part of the first connection step 44. In the context of the second connection step 46, this generates a barcode from the data which is returned to the user of the at least one telephone 36 is returned in the context of the second connection step 46.
  • the client i. the user of the at least one mobile telephone 36 sends a user ID and location information to the at least one system server 38 as part of the first connection step 44. In the context of the second connection step 46, this generates a barcode from the data which is returned to the user of the at least one telephone 36 is returned in the context of the second connection step 46.
  • the client i.
  • the user of the at least one mobile phone 36 extends that barcode data by a one-time password and generates the final barcode received from the client, i. the user of the at least one mobile telephone 36 is transmitted to the at least one transaction terminal 34 in the context of the third connection step 48.
  • the transaction data and the final barcode are scanned at the at least one transaction terminal 34 and reported back to the at least one system server 38 in the context of the fourth connection step 50.
  • the at least one system server 38 then compares the data of the final barcode with the previously sent data and the one-time password. Thereafter, the at least one system server 38 sends a payment request to the client as part of the fifth connection step 52, i. the user of the at least one mobile phone 36.
  • This request is received from the client, i. the user of the at least one mobile phone 36, confirmed by entering a PIN, which can be done at the transaction terminal 34 or to the mobile phone 36 itself.
  • a PIN can not be entered as part of the confirmation up to a predetermined amount.
  • the confirmation of the transaction in the context of the seventh connection step 56 takes place from the at least one system server 38 directly to the at least one transaction terminal 34 at which the transaction is currently being performed.
  • FIG. 4 shows a schematic representation of a changed data flow in the event of poor radio coverage.
  • the at least one transaction terminal 34 provides an alternative connection for this case.
  • the client application ie the user of the at least one mobile telephone 36
  • establishes a data radio connection ie a separate connection 60 to the transaction terminal 34, for example via Bluetooth.
  • This transaction terminal 34 either establishes or implements a constant connection to the system server 38 via a normal connection 58 over the Internet.
  • the user of the application ie the client, ie the user of the at least one mobile telephone 36, then communicates with the at least one system server 38 via the "normal" data connection 58.
  • the client builds a protected connection, for example a so-called virtual private network (VPN), to the system server 38.
  • VPN virtual private network
  • the location is determined in this case by the at least one transaction terminal 34, the remaining components of the security check in the context of the two-factor authentication 18 as described in connection with Figures 2 and 3 already described.
  • FIG. 5 shows the multilevel security system 10 proposed according to the invention and in particular three possible variants of the two-factor authentication in the second level 14.
  • the first option is the time-controlled variant (62), in which the client and server calculate new one-time passwords at defined time intervals , In this case, the one-time password calculation can be implemented by software in the client application. The generated one-time password can then be used directly and does not have to be reentered by the user.
  • the second option (64) is event-driven two-factor authentication. In this case, the client does not calculate the one-time password at defined time intervals, but only when an event occurs, e.g. if the user requests a barcode or triggers the calculation manually. In comparison to the first-mentioned variant (62), the event-driven variant (64) is more resource-efficient.
  • the third variant (66) is the challenge response or challenge-response method.
  • the server sends a "challenge" to the client, eg a numerical value.
  • the client fulfills the task, eg it performs a calculation based on the transmitted numerical value of the server and sends the result back to the server. Since the server is doing the same computation, it knows the result and can compare it to the client's sent response. For all three options, either the authorization takes place at this level if the one-time password (variant 62, 64) or the answer (variant 66) is correct or the transaction is rejected.
  • the mobile phone 36 generates a barcode based on the user ID and a one-time password.
  • further information such as position data 32, 30, can be integrated into the barcode.
  • This barcode is then scanned 68 at the transaction terminal 34.
  • the user 76 may enter a PIN code at the transaction terminal 34.
  • the transaction information is then transmitted 72 through the transaction terminal 34 to the central system server 38.
  • the central system server 38 parallels the client 36 the individual one-time password of this client 36.
  • the central system server 38 can now check the submitted transaction information and confirm or reject the transaction.
  • the confirmation or rejection is then transmitted 74 from the central system server 38 to the transaction terminal 34.
  • Figure 7 shows the possible verification of the authenticity of the system server 38 by the mobile phone or PDA or other communication means 36.
  • the system server 38 generates a one-time password and sends it either via a data connection or short message (SMS) 78 directly to the mobile phone 36th or, in the absence of a radio connection, to the transaction terminal 34.
  • the user 76 can then compare the one-time password sent by the server 38 with the one-time password calculated by the mobile phone 80. This allows the user to check and prevent the authenticity of the system server 38. that eg Scammers creep into the system and manipulate transactions. If the one-time password is sent directly from the server 38 to the mobile phone, the check can be carried out within the mobile phone 36 without further action by the user. This authenticity check is possible with all three described one-time password variants 62, 64, 66.
  • FIG. 8 shows a mobile telephone with which a barcode can be scanned, which contains details of an invoice and which is transmitted via the server to a bank. From Figure 8 shows that in this embodiment of the mobile radio-based transaction system by means of the mobile phone 36 and the handling of this user 76, a scanning of a bar code 100 cf. Position 48 in Figure 8 is done.
  • the barcode 100 is located on an invoice 102.
  • the barcode 100 contains payment information such as the name of a company 10, the account number, bank code, Swiftcode, Iban, invoice number, invoice amount, payment destination, Sconti and the like.
  • the server 38 checks both the payment data and the user ID and the one-time password.
  • the check of the one-time password takes place in the first level 12 of the multi-level security system 10.
  • this payment data sent to a credit institution 1 12.
  • the credit institution 1 12 releases a transfer by means of a release 108, so that the invoice amount, which is located on the company invoice 102, can be transferred to the company 10 issuing the invoice 102, optionally taking into account details also stored in the barcode 100, such as Term of payment, discounts etc.
  • GNSS Location System Global Navigation Satellite System
  • first connection info one time password OTP, location
  • second connection barcode
  • third connection scanning barcode
  • One-time password for checking the authenticity of the server 38 Comparison of the one-time password sent by the server 38 with the one-time password Barcode calculated by the mobile phone 36

Abstract

Die Erfindung bezieht sich auf ein mobilfunkbasiertes Transaktionssystem mit mindestens einem Mobiltelefon (36), mindestens einem Transaktionsterminal (34) sowie mit mindestens einem Systemserver (38) zur Abwicklung eines bargeldlosen Zahlungsverkehrs. Innerhalb eines Mehrebenen-Sicherheitssystems (10) erfolgt in einer zweiten Ebene (14) ein Standortabgleich des Standortes eines Benutzers bzw. des Clients (36) innerhalb eines Mobilfunknetzes (32) und/oder die Ortung des Teilnehmers in einem Satelliten-Positionssystem (30). In einer ersten Ebene (12) wird eine Zwei-Faktoren-Authentifizierung (18, 62, 64, 66) vorgenommen. In einer optionalen dritten Ebene kann noch eine weitere Sicherheitsüberprüfung, z.B. über biometrische Merkmale eingefügt werden.

Description

Mobilfunkbasiertes Transaktionssystem
Stand der Technik Aus US 2009/0222353 AI und GB 2 362 012 A sind Zahlungssysteme bekannt, welche bargeldlos erfolgen und zu deren Implementierung ein Mobiltelefon benutzt wird.
Den obenstehend skizzierten Lösungen gemäß US 2009/0222353 AI und gemäß GB 2 362 012 A wohnt der Nachteil inne, dass die gemäß dieser Systeme abgewickelten Transaktio- nen mit einer erheblichen Unsicherheit behaftet sein können. Dies hat seine Ursache darin, dass die Überprüfungsroutinen gemäß der Lösungen GB 2 362 012 A bzw. US 2009/0222353 AI nicht oder nur in einem einmaligen Durchlauf auf Plausibilität untersucht werden. Offenbarung der Erfindung
Der vorliegenden Erfindung liegt die Aufgabe zugrunde, ein hochsicheres, bargeldloses Zahlungs- und Transaktionssystem für einen oder mehrere Benutzer zur Verfügung zu stellen.
Erfindungsgemäß wird ein bargeldloses Zahlungssystem vorgeschlagen, bei dem an Stelle der bisher eingesetzten Kreditkarte, in der Regel eine Kreditkarte oder eine EC- Karte aus Kunststoffmaterial, das Mobiltelefon tritt. Der Bezahlvorgang erfolgt nun anhand eines Authentifizierungsprozesses mittels eines Barcodes oder eines anderen opti- schen/grafi sehen oder elektromagnetischen wie z.B. das NFC-Verfahrtens (NFC = Near Field Communication) oder auf Schall basierenden Identifikationssignais für das Mobiltelefon bzw. einen PDA (Personal Digital Assistant) oder für ein anderes Kommunikationsgerät. Weiterhin können auch zwischen zwei Nutzern Transaktionen ausgeführt werden, wobei gegenseitiges Einscannen der Mobiltelefone bzw. PDAs oder anderer Kommunika- tionsgeräte denkbar ist. Die Authentifizierung bzw. die Identifikation über einen Barcode oder per NFC-Verfahren, oder über ein anderes optisches/grafisches oder elektromagnetisches oder auf Schall basierendes Identifikationssignal in Kombination mit einem Mobilte- lefon oder einem PDA kann auch für andere Zwecke genutzt werden, so z.B. als Kundenkarte oder zum Identifizieren von Mitarbeitern.
Der erfindungsgemäß vorgeschlagene Transaktionsprozess beginnt damit, dass ein Bar- code oder ein anderes diesem entsprechendes optisches oder grafisches, elektromagnetisches oder auf Schall basierendes Signal von einem Benutzer manuell oder automatisch über das Mobiltelefon, den Personal Digital Assistant (PDA) oder ein anderes Kommunikationsgerät angefordert wird. Bei einem NichtZustandekommen einer Funknetzwerkverbindung, so z.B. innerhalb gut nach außen isolierter Gebäude, wird eine drahtlose Verbin- dung mit dem Transaktionsterminal aufgebaut, welches eine gesicherte Verbindung des Mobiltelefons, des PDAs oder des anderen Kommunikationsgerätes mit dem zentralen Systemserver sicherstellt. Über diese bei fehlender Funknetzwerkverbindung hergestellte sichere drahtlose Verbindung wird ein Barcode oder eine andere Identifikation über diese Verbindung angefordert.
Der Barcode oder das andere optische/grafische oder elektromagnetische Informationsbzw. Identifikationssignal (z.B. NFC) wird vom zentralen Systemserver generiert und an das anfordernde Mobiltelefon bzw. den anfordernden PDA bzw. das anders ausgestaltete anfordernde Kommunikationsgerät gesandt. Der Barcode oder ein alternatives opti- sches/grafisches oder elektromagnetisches Signal wird am Transaktionsterminal, so z.B. einem modifizierten Kartenlesegerät, wie es heute vielfältig zum Einsatz kommt, gescannt bzw. ausgelesen. Die generierte ausgelesene bzw. gescannte Identifikation wird zusammen mit Transaktionsinformationen an den zentralen Systemserver übermittelt. Der Barcode kann auch als Zahlenkombination auf dem Display des Mobiltelefons dargestellt werden. Hierdurch ist die Nutzung des mobilfunkbasierten Transaktionssystems auch dann möglich, wenn das Transaktionsterminal keine Leseeinheit für Barcodes besitzt bzw. diese beschädigt ist.
In einem dritten Schritt überprüft dieser zentrale Systemserver, der den Barcode bzw. die andere Identifikation generiert hat, die Identifikation, die Transaktionsinformationen, Sicherheitskriterien, so z.B. Ort und Zeit, und eventuell andere Restriktionen, so z.B. ein möglicherweise bestehendes Transaktionslimit, so z.B. ein Kontolimit bei einem Kreditinstitut. Der zentrale Systemserver sendet die Transaktionsanfrage über die Funknetzverbindung oder bei NichtZustandekommen über die geschützte drahtlose Verbindung über das Transaktionsterminal an den anfordernden Benutzer (User). Dieser bestätigt die Transaktion oder lehnt sie ab. Bei Bestätigung wird die Transaktion ausgeführt und als ausgeführt an das Transaktionsterminal gesendet. Bei Ablehnung durch den Benutzer (User) erfolgt ein Abbruch der Transaktion. Alternativ kann der Transaktionsprozess auch wie folgt dargestellt werden. Der Barcode oder das andere optische/grafische oder elektromagnetische Informations- bzw. Identifikationssignal wird direkt im Mobiltelefon bzw. dem PDA bzw. einem anders ausgestalteten Kommunikationsgerät generiert. Der Barcode oder ein alternatives optisches/grafisches oder elektromagnetisches Signal wird dann am Transaktionsterminal, so z.B. einem modifizierten Kartenlesegerät, wie es heute vielfältig zum Einsatz kommt, gescannt bzw. ausgelesen. Die generierte ausgelesene bzw. gescannte Identifikation wird zusammen mit Transaktionsinformationen an den zentralen Systemserver übermittelt.
In einem weiteren Schritt überprüft dieser zentrale Systemserver, der auf die gleiche Art und Weise den Barcode generiert wie das Mobiltelefon, die vom Transaktionsterminal übermittelte Identifikation, die Transaktionsinformationen, Sicherheitskriterien, so z.B. Ort und Zeit, und eventuell andere Restriktionen, so z.B. ein möglicherweise bestehendes Transaktionslimit, so z.B. ein Kontolimit bei einem Kreditinstitut. Der zentrale Systemserver sendet die Transaktionsanfrage an das Transaktionsterminal zur Bestätigung zurück. Der Benutzer bestätigt die Transaktion oder lehnt sie ab. Zur Bestätigung kann der Benutzer z.B. eine PIN-Nummer am Transaktionsterminal eingeben. Die Eingabe einer PIN- Nummer am Transaktionsterminal kann entweder direkt nach dem Scannen des Barcodes erfolgen oder erst nachdem der zentrale Systemserver die vom Transaktionsterminal übermittelte Identifikation, die Transaktionsinformationen und Sicher-heitskriterien überprüft hat. Alternativ kann der Benutzer auch am Mobiltelefon bzw. PDA einen PIN-Code eingeben bevor der Barcode generiert wird. Bei Bestätigung wird die Transaktion ausgeführt und als ausgeführt an das Transaktionsterminal gesendet. Bei Ablehnung durch den Benutzer (User) erfolgt ein Abbruch der Transaktion. Dieser Transaktionsprozess ist insbesondere dann vorteilhaft, wenn sich der Benutzer im Ausland aufhält und somit hohe Gebühren für die Datenkommunikation zwischen dem zentralen Systemserver und dem Mobiltelefon anfallen würden.
Der obenstehend kurz skizzierte, im Wesentlichen dreistufig ablaufende Transaktionsprozess ist mit verschiedenen Sicherheitsstufen unterlegt. So wird in einer ersten Sicherheits- stufe der vom zentralen Systemserver generierte Barcode oder alternativ das andere grafische/optische oder elektromagnetische Signal im Systemserver generiert und die Gültigkeit des generierten Barcodes oder der alternativen Identifikation zeitlich begrenzt. Die zeitliche Begrenzung kann z.B. auf 300 Sekunden limitiert sein. Alternativ erfolgt, wie zuvor beschrieben, die Generierung des Barcodes innerhalb des Mobiltelefons bzw. PDA oder einem anders ausgestalteten Kommunikationsmittel.
In einer 2. Sicherheitsstufe kann über ein Ortungssystem, wie z.B. das Global Positioning System (GPS) oder ein anderes satellitengestütztes Ortungssystem, der Standort des Benutzers (Users) mit dem Ort, an dem die Identifikation gewünscht ist, sei es eine Kasse, sei es ein anderes Identifikationsterminal, abgeglichen werden. Neben dem GPS kommt auch eine Ermittlung des Standortes des Benutzers (Users) über das Funknetz in Frage, so z.B. über das Netz, in dem das Mobiltelefon Kommunikationsdienstleistungen erbringt. Stimmen der Standort des Benutzers und der Ort der Identifikation nicht überein, wird die Transaktion abgelehnt. Weiterhin erfolgt eine Ablehnung der Transaktion dann, wenn die Entfernung zwischen zwei oder mehreren Identifikationsorten zu groß ist, um in einer definierten Zeitspanne zurückgelegt werden zu können. Innerhalb der 2. Sicherheitsstufe zur Abwicklung des vorstehend skizzierten dreistufigen Transaktionsprozesses lässt sich der Standort des Benutzers entweder bei Bedarf, d.h. willkürlich, kontinuierlich oder in wohldefinierten Zeitabständen ermitteln, was die Plausibili- tät eines Abgleiches des Standortes, d.h. des Aufenthaltsortes des Benutzers mit dem Ort, an dem die Identifikation erfolgen soll, zusätzlich plausibilisiert und die Aussagefähigkeit drastisch erhöht.
Innerhalb dieser zweiten Sicherheitsstufe lässt sich über das satellitengestützte Ortungssystem, wie z.B. das Global Positioning System (GPS), oder ein anderes satellitengestütztes Ortungssystem der Standort des Benutzers ermitteln. Alternativ zum satellitengestützten Ortungssystem kann der Standort des Benutzers über das Funknetz, in dem das Mobiltelefon oder der PDA des Benutzers eingebunden ist, über das dementsprechende Funknetz bzw. Mobilfunknetz ermittelt werden. Befindet sich der Benutzer - je nach Sichtweise - innerhalb oder außerhalb eines definierten geographischen Ortes, kann die angeforderte Transaktion abgelehnt werden. Definitionssache ist die Lokalisierung des Benutzers, der sich entweder innerhalb oder außerhalb eines definierten geographischen Ortes befinden muss, um die Plausibilisierung der angeforderten Transaktion durchzuführen.
In einer weiteren, und hinterlegten 3. Sicherheitsstufe ist ein Diebstahlschutz implementiert. Der Diebstahlschutz bezieht sich vor allem auf den Diebstahl des Kommunikations- gerätes, d.h. im vorliegenden Falle auf den Diebstahl des Mobiltelefons oder den des PDAs (Personal Digital Assistant). In einer ersten Ausführungsmöglichkeit eines zu implementierenden Diebstahlschutzes wird die Eingabe einer ΡΓΝ bei Bestätigung der Transaktion gefordert. Alternativ dazu besteht die Möglichkeit, ein separates Freischaltmodul, welches der Benutzer stets bei sich trägt, zu betätigen, welches z.B. durch ein Bluetooth-Dongle oder ein RFID-Chip dargestellt sein kann. In einer weiteren, dritten Ausführungsmöglichkeit des obenstehend innerhalb der Sicherheitsstufe 3 implementierten Diebstahlschutzes besteht die Möglichkeit, ein Foto des Benutzers auf dem Transaktionsterminal anzuzeigen. Dies bedeutet, dass der zentrale Server ein dort hinterlegtes Foto des Benutzers an das betreffende, die Identifikation vor Ort durchführende Transaktionsterminal sendet. Schließ- lieh besteht eine Möglichkeit zur Identifikation darin, dass eine Identifikation anhand persönlicher Identifikationsmerkmale durchgeführt wird, so z.B. ein Scannen von Fingerabdrücken oder der Iris des Auges an dem entsprechenden Transaktionsterminal vorgenommen wird. Ein Vergleich der am Transaktionsterminal eingescannten Daten mit den Daten, die auf dem zentralen Server gespeichert sind, führt sehr schnell zu einer aussagekräftigen Identifikation oder Nicht-Identifikation.
In einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäß vorgeschlagenen bargeldlosen Zahlungssystems kann die Zahlungsfähigkeit auch dann erhalten werden, wenn keine Funkverbindung zwischen dem Mobiltelefon bzw. dem PDA oder einem anderen elektronischen Kommunikationsgerät zu einem regulären Funknetz besteht. In diesem Falle wird über eine Datenfunkverbindung, so z.B. Bluetooth, eine Verbindung zum Kassenterminal hergestellt, über welches dann eine direkte Verbindung mit dem zentralen Server, der über das reguläre Funknetz nicht erreichbar war, hergestellt wird. In diesem Falle dient z.B. ein Kassenterminal als Datenfunkverbindung zum Server. Alternativ kann auch hier die zuvor beschriebene Ausführungsvariante eingesetzt werden, bei der ein Barcode im Mobiltelefon bzw. PDA oder einem anderen Kommunikationsgerät generiert und dann gescannt wird. Bei dieser Ausführungsvariante kann gänzlich auf eine direkte Verbindung zwischen Mobiltelefon und Server verzichtet werden.
Der erfindungsgemäß vorgeschlagenen Lösung folgend, können auch Transaktionen zwischen mehreren Benutzern durch gegenseitiges Einscannen des Barcodes oder des anderen grafischen oder optischen Identifikationsmerkmals ausgeführt werden. Dazu besteht lediglich das Erfordernis, dass das Mobiltelefon bzw. der Personal Digital Assistant eine Kame- ra aufweist. In dieser Hinsicht ist zu festzuhalten, dass die Sicherheit wieder durch die Position gegeben ist, da beim Scannen eines Barcodes von einem Gerät A auf ein Gerät B beide Geräte die gleiche Position haben müssen.
In einer weiteren vorteilhaften Ausführungsmöglichkeit einer Abwicklung von Transaktio- nen, kann unter Einbindung des Internets der zentrale Server einen Barcode oder ein anderes geeignetes optisches oder elektromagnetisches Signal an eine Website senden. Der Benutzer scannt eben diesen Barcode, der am Monitor eines Transaktionsterminals dargestellt ist, vom Bildschirm desselben ab. Dazu benutzt der Benutzer sein Mobiltelefon, welches den eingescannten Barcode an den zentralen Server sendet. Dieser wiederum sendet die Zahlungsanfrage an das Mobiltelefon, wo diese noch vom Benutzer zu bestätigen ist, bevor die Transaktion ausgeführt wird.
Die erfindungsgemäß vorgeschlagenen Transaktionen können sowohl im Einzel- als auch im Mehrbenutzermodus durchgeführt werden. Dazu kann ein Benutzer ein Einzelbenutzer- konto eröffnen oder auch ein Mehrbenutzerkonto anlegen. Bei einem Mehrbenutzerkonto, welches insbesondere für Firmen, Behörden und Familien interessant sein kann, können über ein Hauptkonto mehrere Benutzerkonten verwaltet werden. Der Benutzer kann über eine dementsprechend konfigurierte Website im Internet das Benutzerkonto, sei es ein Ein- zelbenutzer-, sei es ein Mehrbenutzerkonto, verwalten, geographische und zeitliche Limitierungen setzen. Der Benutzer kann für Orte und Zeiten Transaktionslimitierungen setzen, die sowohl für ein Einzelbenutzerkonto als auch ein Mehrbenutzerkonto gültig sind.
Der Barcode oder ein NFC-Signal kann z.B. als Bilddatei zwischen den einzelnen Parteien ausgetauscht werden oder in Form von Daten, die dann vom Client in einen Barcode umgewandelt werden können. Die obenstehend beschriebenen Sicherheitsstufen 1 bis 3 ermöglichen eine Zwei-Faktoren-Authentifizierung auf Basis der Faktoren "Wissen" und "Besitzen". Unter Verweis auf eine EC-Karte sei hier ausgeführt, dass der Faktor "Wissen" durch persönliche Geheimzahl (PIN) und der Faktor "Besitzen" durch die "EC-Karte" ge- bildet wird. Nur durch die Kombination der beiden Faktoren ist es möglich, am Geldautomaten Geld abzuheben oder an EC-Terminals zu bezahlen.
Insbesondere im IT-Bereich etablierten sich in den vergangenen Jahren verschiedene Zwei- Faktoren- Authentifizierungssysteme, die Nutzern z.B. sicheren Zugang zu Firmennetzwer- ken oder Software-Anwendungen geben. Dazu wird ein Einmal-Passwort generiert, welches in Verbindung mit der PIN den Nutzer autorisiert. Das Einmal-Passwort wird entweder über einen handlichen Passwort-Generator (Client) oder unter Zwischenschaltung einer Software generiert. Voraussetzung für das Einmal-Passwort-Verfahren ist, dass beide Beteiligten, d.h. Client und Server, ein gemeinsames, geheimes Kennwort haben. Aus diesem gemeinsamen geheimen Kennwort wird nun eine Reihe von Einmal-Passwörtern (One Time Passwords: OTP's) erzeugt.
Grundsätzlich kann bei diesen Systemen zwischen drei verschiedenen Typen differenziert werden:
A Zeitsteuerung
Bei diesem Typ berechnen Server und Client in festgestellten Zeitintervallen immer neue Passwörter. Obwohl der Server jeweils dieselbe Berechnung wie der Client ausführt, ak- zeptiert und berechnet der Server im Allgemeinen innerhalb eines Toleranzbereiches mehrere Einmal-Kennwörter. Dadurch kann dem Umstand Rechnung getragen werden, dass die im Token eingebaute Uhr eventuell nicht hundertprozentig synchron geht. Dennoch hat jedes Einmal-Kennwort ein genau definiertes Zeitintervall für seine Gültigkeit, im Regelfall zwischen 1 bis maximal 15 Minuten. B Ereignissteuerung
Bei ereignisgesteuerten Verfahren führt der Server wie beim zeitgesteuerten Verfahren dieselbe Berechnung aus, die auf der Client-Seite bereits stattgefunden hat, und auch hier berechnet und akzeptiert der Server in einem Toleranzbereich mehrere Einmai- Kennwörter, ausgenommen bereits verwendete Einmal-Kennwörter. Der Grund dafür liegt darin, dass der Besitzer gelegentlich ein generiertes Kennwort nicht verwenden könnte. Dieses Verfahren ist viel schonender für die Batterien eines entsprechenden Gerätes (To- ken). Es besteht auch die Möglichkeit, das Verfahren ohne permanente Stromversorgung zu betreiben, indem einfach der letzte verwendete und damit ohnehin entwertete Wert gespeichert wird.
C Anforderungs-Antwort- Verfahren
Synchronisationsprobleme gibt es im Falle des Anforderungs-Antwort-Verfahrens nicht. Bei diesem Verfahren gibt der Server eine Aufgabe, d.h. die Anforderung vor, die der Client beantworten muss (Antwort). Der Client enthält also einen Wert des Servers als Eingabe und berechnet darauf basierend ein Einmal-Kennwort.
Die Implementierung der Zwei-Faktoren-Authentifizierung in das Transaktionssystem, Stichwort "Wissen" und "Besitz", erfolgt wie folgt:
In einer ersten Variante sendet die Applikation auf dem Mobiltelefon, den Client darstel- lend, neben der Nutzer-ID auch ein Einmal-Passwort an den Server. Daraus generiert der Server einen Barcode, den er wieder an den Client sendet. Der Barcode wird dann am Transaktionsterminal gescannt und zusammen mit den Transaktionsdaten an den Server verschickt. Der Server sendet dann eine Zahlungsanfrage an den Client, die vom Nutzer durch Eingabe der ΡΓΝ bestätigt wird. Zur Beschleunigung der Transaktion kann bis zu einem zuvor festgelegten Betrag auf die Eingabe der PIN verzichtet werden.
In einer weiteren vorteilhaften Ausführungsvariante sendet die Applikation auf dem Mobiltelefon, welches den Client darstellt, die Nutzer-ID an den Server. Daraus generiert der Server Daten für einen Barcode, der wiederum an den Client retour gesendet wird. Der Client erweitert diese Barcode-Daten durch ein Einmal-Passwort und generiert den endgültigen Barcode. Dieser wird dann am Transaktionsterminal gescannt und zusammen mit den Transaktionsdaten an den Server übermittelt. Der Server vergleicht die Daten des Barcodes mit den zuvor gesendeten Daten und dem Einmal-Passwort. Danach sendet der Server eine Zahlungsanfrage an den Client, die vom Benutzer durch Eingabe der PIN bestätigt wird. Die PIN kann entweder am Client oder am Transaktionsterminal eingegeben werden. Zur Beschleunigung der Transaktion kann bis zu einem zuvor festgelegten Betrag auf die Eingabe der PIN verzichtet werden. In einer weiteren vorteilhaften Ausführungsvariante generiert die Applikation auf dem Mobiltelefon, welches den Client darstellt, einen Barcode aus der persönlichen Benutzer- ID und einem Einmal-Kennwort. Wie zuvor beschrieben, berechnet der zentrale Systemserver parallel das gleiche Einmal-Kennwort. Der generierte Barcode wird dann am Transaktionsterminal gescannt und zusammen mit den Transaktionsdaten an den Server übermit- telt. Der Server vergleicht das in den Daten des Barcodes enthaltene Einmal-Passwort mit dem für diesen Benutzer berechneten Einmal-Passwort. Stimmen beide Einmal-Passwörter überein und die Überprüfung weiter Sicherheitskriterien (Transaktionslimit, Positionsbestimmung) war positiv, sendet der Server danach eine Zahlungsanfrage entweder an den Client oder an das Transaktionsterminal, die vom Benutzer durch Eingabe der PIN bestä- tigt wird. Die PIN kann entweder am Client oder am Transaktionsterminal eingegeben werden. Zur Beschleunigung der Transaktion kann bis zu einem zuvor festgelegten Betrag auf die Eingabe der PIN verzichtet werden. Alternativ kann die PIN auch schon zu Beginn im Mobiltelefon eingegeben werden, um z.B. die Generierung des Barcodes zu starten. Zusätzlich kann innerhalb dieser Ebene eine weitere Sicherheitsüberprüfung eingebaut werden. Da die Berechnung des Einmal-Kennwortes parallel im Mobiltelefon als auch im Systemserver erfolgt, kann hierdurch auch die Identität des Servers überprüft werden. Um diesen Schutzmechanismus zusätzlich zu implementieren, sendet der Server während des Transaktionsprozesses ein Einmal-Kennwort an das Mobiltelefon. Da dieses mit dem vom Mobiltelefon zu diesem Zeitpunkt berechneten Einmal-Kennwort übereinstimmen muss, kann das Mobiltelefon sicher überprüfen, ob es sich um "echten" Systemserver handelt.
In einer weiteren, dritten Sicherheitsebene neben den ersten beiden vorstehend skizzierten standardmäßig implementierten Sicherheitsebenen kann eine nutzerbezogene Sicherheits- ebene eingezogen werden. Hierzu können entweder biometrische Merkmale des Benutzers abgeglichen werden, so z.B. Finger- oder Handabdrücke, Iris oder Gesicht, oder Informationen aus einem Ausweisdokument. Alternativ dazu kann hier auch ein Bluetooth-Dongle eingesetzt werden, welches die Anwendung im Client freischaltet oder aber gegebenenfalls eine RFID-Karte.
Aufgrund des Umstandes, dass insbesondere in Gebäuden oftmals eingeschränkte Funkverbindungen vorherrschen, stellt das Transaktionsterminal in diesem Fall eine Alternativverbindung bereit. Hierzu stellt die Client-Applikation eine Datenfunkverbindung zwischen dem Transaktionsterminal her, so z.B. Bluetooth, welche entweder eine konstante Verbindung zum Autorisierungsserver unterhält, so z.B. über das Internet, oder zur Autorisierung eine Wählverbindung aufbaut. Über diesen Datenkanal kommuniziert dann die Client-Applikation mit dem Server. Die Standortbestimmung ist in diesem Falle durch das Transaktionsterminal gegeben, die restlichen Bestandteile der Sicherheitsüberprüfung lau- fen wie vorstehend beschrieben ab.
In allen Ausführungsvarianten kann der Barcode auch als Zahlenkombination auf dem Display des Mobiltelefons dargestellt werden. Hierdurch ist die Nutzung des mobilfunkba- sierten Transaktionssystems auch dann möglich, wenn z.B. das Transaktionsterminal keine Leseeinheit für Barcodes besitzt bzw. diese beschädigt ist.
Im vorliegenden Zusammenhang wird gleichbedeutend der Applikation mit Mobiltelefon und Barcode noch eine Applikation mit dem Mobiltelefon und mit NFC (Near-Field- Communication) verstanden. Das NFC-Verfahren ist das gegenwärtig von den Kreditkar- ten-Unternehmen favorisierte Verfahren für kontaktloses Zahlen. Unter Near-Fild- Communication (NFC) wird ein Übertragungsstandard bezeichnet, der zum kontaktlosen Austausch von Daten über kurze Strecken dient. Mittels NFC soll der Austausch verschiedener Information wie z.B. Telefonnummern, Bildern, MP3-Dateien oder digitalen Berechtigungen zwischen zwei Geräten ermöglichen, die nahe aneinander- gehalten werden. NFC dient als Zugriffsschlüssel auf Inhalte und für Services wie bargeldlöse Zahlungen, Ticketbestellung, Online-Unterhaltung sowie auch für die Zugangskontrolle. Die notwendigen Sicherheitsfunktionen sind im Allgemeinen in der NFC-Hardware integriert.
Mit dem NFC-Verfahren kann im erfindungsgemäßen Zusammenhang das Mobiltelefon als
Zahlungsgerät benutzt werden, in dem die Benutzer des Mobiltelefons dieses nahe an ein Zahlungsterminal halten, so dass eben die Near-Field-Communication erfolgen kann. Die Zahlfunktion an einem Mobiltelefon erfordert eine Integration dieser in bestehende SIM- Karten-Infrastrukturen. Die NFC-Technik basiert auf der Kombination aus Smart-card und kontaktlosen Verbindungstechniken. Die NFC arbeitet in einem Frequenzbereich von 13,56 Megaherz und bietet eine Datenübertragungsrate von maximal 424 kBIT/Sek. Bei einer Reichweite von nur 10cm. Dies ist gewünscht, damit eine Kontaktaufnahme als Zustimmung zu einer Transaktion ausgelegt werden kann. NFC ist durch die ISO 14443, 18092, 21481 ECMA 340, 352, 356, 362 bzw. ETSI TS 102 und 190 standardisiert.
Die Kommunikation zwischen NFC-technikfähigen Geräten, d.h. Mobiltelefon und Zahlungsterminal kann sowohl aktiv-passiv, als auch aktiv-aktiv sein (Peer-to-Peer) im Gegensatz zur herkömmlichen Kontaktlos-Technik in diesem Frequenzbereich, der im allgemeinen nur aktiv-passiv abläuft. Die Nutzung des NFC-Verfahrens stellt somit eine Verbin- dung zu RFID-Umgebung dar. Der NFC-Standard ist größtenteils kompatibel mit weithin verwendeter verwendeter Smartcard-Infrastruktur basierend beispielsweise auf ISO/IEC 14443-A bzw. ISO/IEC 14443-B. Der NFC-Standard kann als Ersatz für Barcodes, z.B. beim elektronischen Ticketkauf oder wie erfindungsgemäß vorgeschlagen, zur Abwicklung von Zahlungstransaktionen eingesetzt werden, insbesondere da wo die nötigen Datenmengen nicht mehr in einer sinnvollen Anzahl von Barcodes übertragen werden können.
Bei NFC-Standard bietet sich alternativ zu Barcodes insbesondere dann an, wenn zwei Geräte kryptografisch gesichert, miteinander kommunizieren wie das bei Bezahlanwendungen in der Regel der Fall ist.
Kurze Beschreibung der Zeichnung
Anhand der Zeichnung wird die Erfindung nachstehend eingehender beschrieben.
Es zeigt:
Figur 1 den prinzipiellen Aufbau des erfindungsgemäß vorgeschlagenen Mehrebenen-Sicherheitssystems,
Figur 2 eine erste Ausführungsvariante einer Kommunikation zwischen einem
bilfunknetz, einem Transaktionsterminal und einem Systemserver,
Figur 3 eine weitere Ausführungsvariante eines Kommunikationsschemas zwischen
Mobilfunknetz, Transaktionsterminal und Systemserver,
Figur 4 eine Ausfuhrungsvariante einer Kommunikation zwischen einem Systemserver, einem Mobiltelefon und einem Transaktionsterminal, wobei das Transaktionsterminal eine normale Verbindung zum Systemserver aufrechterhält und eine davon verschiedene Funkverbindung zum Mobiltelefon und
Figur 5 den prinzipiellen Aufbau des erfindungsgemäß vorgeschlagenen
Mehrebenensicherheitssystems mit drei unterschiedlichen Zwei-Faktoren- Authentifizierungsverfahren.
Figur 6 eine Ausführungsvariante wenn das Mobiltelefon das Einmal-Kennwort und den Barcode ohne direkte Verbindung zum Systemserver berechnet.
Figur 7 eine Ausführungsvariante, die es dem Mobiltelefon ermöglicht, die Echtheit des Systemservers zu überprüfen und Figur 8 ein Mobiltelefon welches zur Übermittlung eines Barcodes einer Rechnung an ein Kreditinstitut benutzt wird. Ausführungsvarianten
Der Darstellung gemäß Figur 1 ist in schematischer Weise der Aufbau des Mehrebenen- Sicherheitssystems zu entnehmen. Im vorliegenden Zusammenhang wird NFC, d.h. Near-Field-Communication gleichbedeutend und austauschbar mit dem Begriff Barcode verwendet.
Innerhalb des erfindungsgemäß vorgeschlagenen mobilfunkbasierten Transaktionssystems zur Abwicklung eines bargeldlosen Zahlungsverkehrs werden sichere Transaktionen durch verschiedene Sicherheitsmechanismen auf mehreren Ebenen 12, 14, 20 gewährleistet. Die erste Ebene 12 und die zweite Ebene 14 ermöglichen mit ihren dort durchgeführten Prozessen die Erzeugung hochsicher ablaufender Transaktionen. Innerhalb der ersten Ebene 12 erfolgt die Zwei-Faktoren- Authentifizierung 18. Innerhalb der zweiten Ebene 14 erfolgt ein Standortabgleich 16 zwischen dem Standort des Nutzers, d.h. dem aktuellen Standort eines Mobiltelefons 36, welches mit einem Mobilfunknetz 32 kommuniziert, mit dem Standort eines Transaktionsterminals 34, an dem gerade eine aktuelle Transaktion abzuwickeln ist.
Optional umfasst das Mehrebenen-Sicherheitssystem 10 neben der ersten Ebene 12 und der zweiten Ebene 14 eine weitere, dritte Ebene 20. Während die ersten beiden Ebenen 12, 14 standardmäßig implementiert sind, kann die Sicherheit durch die weitere, nutzerbezogene dritte Ebene 20 erweitert werden. Dazu können innerhalb der dritten Ebene entweder biometrische Merkmale des Benutzers (Client) abgeglichen werden. Bei den biometrischen Merkmalen kann es sich z.B. um Finger- oder Handabdrücke, die Iris des Auges oder die Züge des Gesichtes handeln. Alternativ dazu können in der dritten Ebene Informationen aus einem amtlichen Ausweisdokument hinterlegt sein. Alternativ kann hier auch ein Blue- tooth-Dongle eingesetzt werden, welches die Anwendung im Client freischaltet oder aber eine RFID-Karte. Der Client überprüft, ob ein Bluetooth-Dongle bzw. die RFID-Card sich in der näheren Umgebung, so z.B. in der Hosentasche oder am Schlüsselbund, des Nutzers befinden. Da es sich hierbei um Kurzstreckenfunktechnologien handelt, bricht die Verbindung automatisch ab, wenn Bluetooth-Dongle bzw. RFID sich nicht mehr in der Nähe des Clients befinden. Ist dies der Fall, wird die Anwendung blockiert und eine Anforderung eines Barcodes ist nicht möglich. Den Darstellungen gemäß der Figuren 2 und 3 sind Ausfuhrungsvarianten der Implementierung des erfindungsgemäß vorgeschlagenen mobilfunkbasierten Transaktionssystems zu entnehmen. Das mobilfunkbasierte Transaktionssystem umfasst, vergleiche Darstellung gemäß Figur 2, ein Mobilfunknetz 32, in welchem der Benutzer durch Benutzung des mindestens einen Mobiltelefons 36 eingebunden ist, ein Transaktionsterminal 34 an einer Tankstelle in einem Kaufhaus oder an einem Flughafen, um ein Beispiel zu nennen, sowie mindestens einen Systemserver 38.
Die aufgezählten Komponenten sind in allen drei Figuren, d.h. den Figuren 2, 3 und 4, identisch.
Der in der zweiten Ebene 14 des Mehrebenen-Sicherheitssystems 10 gemäß Figur 1 durch- zuführende Standortabgleich 16 erfolgt derart, dass der Client, d.h. der Benutzer des mindestens einen Mobiltelefons 36, einen Barcode von dem mindestens einen Systemserver 38 anfordert. Mit dieser Anforderung sendet er neben anderen Daten auch seinen aktuellen Standort, d.h. den Standort, an dem der jeweilige Benutzer das jeweilige mindestens eine Mobiltelefon 36 gerade und in diesem Moment benutzt. Die Ermittlung dieses Standortes kann entweder aus einer ersten Positionsdatenübermittlung 40, die von dem GPS-System 30 vorgenommen wird, durchgeführt werden oder aus einer Ortung des mindestens einen Mobiltelefons 36 und damit dessen Benutzers innerhalb des Mobilfunknetzes 32 gewonnen werden. Während des Ablaufs der aktuellen Transaktion wird über eine Identifikation des mindestens einen Transaktionsterminals 34, an dem die aktuelle Transaktion jeweils gera- de abläuft, der Standort desselben ermittelt. Stimmen die beiden Standorte, d.h. der Standort, an dem sich der Benutzer des mindestens einen Mobiltelefons 36 aufhält, und der Standort des Transaktionsterminals 34, an dem die jeweilige Transaktion gerade abzuwickeln ist, nicht überein, so wird die Durchführung der Transaktion abgelehnt. Innerhalb des in der zweiten Ebene 14 des Mehrebenen-Sicherheitssystems 10 ablaufenden Standortvergleiches kann - gewissermaßen als zweiter Baustein - ein Vergleich des Standortes der Durchführung der jeweils aktuellen Transaktion mit dem Standort einer vorher durchgeführten Transaktion verglichen werden. Basierend auf der Annahme, dass der Benutzer des mindestens einen Mobiltelefons 36 nur mit einer bestimmten Geschwindigkeit seinen Standort ändern kann, werden Transaktionen, deren räumlicher Abstand nicht mit dem zeitlichen Abstand plausibilisierbar ist, abgelehnt.
Neben diesen systemseitigen Sicherheitsvorkehrungen, die in der zweiten Ebene 14 des Mehrebenen-Sicherheitssystems 10 implementiert sind, kann der Benutzer, d.h. der Benut- zer des mindestens einen Mobiltelefons 36, weitere standortabhängige Einschränkungen vornehmen. Dazu zählen z.B. geographische Beschränkungen hinsichtlich des Web- Interfaces. Es besteht die Möglichkeit, dass sich der Nutzer via Website in seinen Webaccount einloggt. Dort kann der Nutzer dann z.B. auf einer Straßenkarte Bereiche markieren, in denen die Nutzung erlaubt sein soll bzw. untersagt werden soll. Bei dieser Vorgehensweise sind verschiedene Ausprägungsmuster möglich, so z.B. können Postleitzahlen, Städte, Bundesländer oder andere Benutzungsgebiete über entsprechende Codierungen zugelassen oder nicht zugelassen werden. Der auf der zweiten Ebene 14 des Mehrebenen-Sicherheitssystems 10 ablaufende Standortvergleich 16 kann entweder kontinuierlich durchgeführt werden oder zu vorher festgelegten Zeitpunkten, so z.B. alle 10 Minuten. Ein Standortabgleich 16 kann in der zweiten Ebene 14 auch dann vorgenommen werden, wenn eine entsprechende Anfrage an den mindestens einen Systemserver 38 gesandt wird. Da jedoch der Satellitenempfang hinsichtlich der Abschirmung innerhalb eines Gebäudes bei Einsatz eines Positionssystems 30 oftmals schwierig ist und in diesem Falle nur eine Standortbestimmung über das Mobilfunknetz 32, innerhalb dessen das mindestens eine Mobiltelefon 36 und damit zwangsläufig der Benutzer kommuniziert, möglich wäre, sind die kontinuierlichen oder zu festgelegten Zeitpunkten erfolgten Standortabgleiche 16 vorzuziehen, die jedoch einen relativ hohen Energieein- satz erfordern.
Anhand der Figuren 2 und 3 wird die Zwei-Faktoren-Authentifizierung 18, die innerhalb der ersten Ebene 12 des Mehrebenen-Sicherheitssystems 10 abläuft, nachstehend eingehender beschrieben.
In der in Figur 2 dargestellten Ausführungsform des erfindungsgemäß vorgeschlagenen mobilfunkbasierten Transaktionssystems sendet der Benutzer, d.h. der Client in Gestalt des mindestens einen Mobiltelefons 36, im Rahmen einer ersten Verbindung 44 neben einer Nutzer-ID ein Einmal-Passwort und den aktuellen Standort an den mindestens einen Sys- temserver 38. Der Standort kann entweder über das Mobilfunknetzwerk 32 oder ein satellitengestütztes Navigationssystem 30 ermittelt werden. Daraus generiert der mindestens eine Systemserver 38 einen Barcode, der innerhalb eines zweiten Verbindungsschrittes 46 an den Nutzer des mindestens einen Mobiltelefons 36, d.h. den Client, zurückgemeldet wird. Der Barcode wird anschließend innerhalb einer dritten Verbindung 48 an das mindestens eine Transaktionsterminal 34 gesandt oder von diesem gescannt und von dort, vergleiche Position 34, im Rahmen eines vierten Verbindungsschrittes 50 an den mindestens einen Systemserver 38 übermittelt, vergleiche Position 50 in Figur 2. Der Systemserver 38 vergleicht den in Verbindung 50 übermittelten Barcode mit dem in Verbindung 46 übermittelten Barcode. Sind beide Barcodes identisch, sendet der mindestens eine Systemserver 38 eine Zahlungsanfrage, vergleiche fünfte Verbindung 52, an den Client, d.h. den Benutzer des mindestens einen Mobiltelefons 36. Diese wird von dem Benutzer, d.h. im vorliegenden Falle des Clients des mindestens einen Mobiltelefons 36, im Rahmen eines sechsten Verbindungsschrittes 54 mit einer persönlichen PIN bestätigt. Nach der Bestätigung ver- läuft ein siebter Verbindungsschritt 56, wonach die Bestätigung der Transaktion vom mindestens einen Systemserver 38 an das mindestens eine Transaktionsterminal 34 bestätigt wird.
In der in Figur 3 dargestellten Ausführungsvariante des erfindungsgemäß vorgeschlagenen mobilfunkbasierten Transaktionssystems sind die Komponenten 30, 32, 34, 36 und 38 identisch, ebenso wie die Verbindungsschritte 44 bis 56. Die Unterschiede zwischen der in Figur 2 dargestellten Ausführungsvariante und der in Figur 3 dargestellten Ausführungsvariante werden nachstehend kurz beschrieben. Der Client, d.h. der Benutzer des mindestens einen Mobiltelefons 36, sendet im Rahmen des ersten Verbindungsschrittes 44 eine Nut- zer-ID sowie Standortinformationen an den mindestens einen Systemserver 38. Im Rahmen des zweiten Verbindungsschrittes 46 generiert dieser aus den Daten einen Barcode, der wieder an den Benutzer des mindestens einen Telefons 36 im Rahmen des zweiten Verbindungsschrittes 46 zurückgemeldet wird. Der Client, d.h. der Benutzer des mindestens einen Mobiltelefons 36, erweitert diese Barcodedaten durch ein Einmal-Passwort und generiert den endgültigen Barcode, der vom Client, d.h. dem Benutzer des mindestens einen Mobiltelefons 36, im Rahmen des dritten Verbindungsschrittes 48 an das mindestens eine Transaktionsterminal 34 übermittelt wird. Im Rahmen des vierten Verbindungsschrittes 50 werden die Transaktionsdaten sowie der endgültige Barcode an dem mindestens einen Transaktionsterminal 34 gescannt und im Rahmen des vierten Verbindungsschrittes 50 an den mindestens einen Systemserver 38 zurückmeldet. Der mindestens eine Systemserver 38 vergleicht dann die Daten des endgültigen Barcodes mit den zuvor gesendeten Daten und dem Einmal-Passwort. Danach sendet der mindestens eine Systemserver 38 eine Zahlungsanfrage im Rahmen des fünften Verbindungsschrittes 52 an den Client, d.h. den Benutzer des mindestens einen Mobiltelefons 36. Diese Anfrage wird vom Client, d.h. dem Benutzer des mindestens einen Mobiltelefons 36, durch Eingabe einer PIN bestätigt, was am Transaktionsterminal 34 oder an dem Mobiltelefon 36 selbst erfolgen kann. Zum Beschleunigen der Transaktion kann bis zu einem zuvor festgelegten Betrag auf die Eingabe der PIN im Rahmen der Bestätigung verzichtet werden. Im Rahmen des sechsten Verbindungsschrittes 54 erfolgt die Bestätigung der Transaktion im Rahmen des siebten Verbin- dungsschrittes 56 von dem mindestens einen Systemserver 38 unmittelbar an das mindestens eine Transaktionsterminal 34, an dem die Transaktion gerade durchgeführt wird.
Figur 4 zeigt in schematischer Wiedergabe einen geänderten Datenfluss bei mangelhafter Funkabdeckung. Da insbesondere in Gebäuden eingeschränkte Funkverbindungen vorherrschen, stellt das mindestens eine Transaktionsterminal 34 für diesen Fall eine Alternativverbindung bereit. Hierzu stellt die Client-Applikation, d.h. der Benutzer des mindestens einen Mobiltelefons 36, eine Datenfunkverbindung, d.h. eine gesonderte Verbindung 60 zum Transaktionsterminal 34 z.B. über Bluetooth her. Dieses Transaktionsterminal 34 baut entweder eine konstante Verbindung zum Systemserver 38 im Wege einer normalen Verbindung 58 auf oder implementiert diese über Internet. Über die "normale" Datenverbindung 58 kommuniziert dann der Benutzer der Applikation, d.h. der Client, d.h. der Benutzer des mindestens einen Mobiltelefons 36, mit dem mindestens einen Systemserver 38. Hierzu baut der Client eine geschützte Verbindung, so z.B. ein so genanntes Virtual Private Network (VPN), zu dem Systemserver 38 auf. Die Standortbestimmung erfolgt in diesem Falle durch das mindestens eine Transaktionsterminal 34, die restlichen Bestandteile der Sicherheitsprüfung im Rahmen der Zwei-Faktoren- Authentifizierung 18 verlaufen wie im Zusammenhang mit den Figuren 2 und 3 bereits beschrieben ab.
Figur 5 zeigt das erfindungsgemäß vorgeschlagene Mehrebenensicherheitssystem 10 und insbesondere drei mögliche Ausprägungen der Zwei-Faktoren-Authentifizierung in der zweiten Ebene 14. Die erste Möglichkeit stellt die zeitgesteuerte Variante dar (62), bei der Client und Server in definierten Zeitabständen neue Einmal-Passwörter berechnen. Hierbei kann die Einmalpasswort-Berechnung softwaremäßig in die Clientapplikation implementiert werden. Das generierte Einmal-Passwort kann dann direkt weiterverwendet werden und muss nicht erneut vom User eingegeben werden. Die zweite Möglichkeit (64) ist die ereignisgesteuerte Zwei-Faktoren-Authentifizierung. Hierbei berechnet der Client das Einmal-Passwort nicht in definierten Zeitabständen sondern erst bei Eintritt eines Ereignisses, z.B. wenn der User einen Barcode anfordert bzw. die Berechnung manuell auslöst. Im Vergleich zu erstgenannter Variante (62) ist die ereignisgesteuerte Variante (64) ressourcenschonender.
Die dritte Variante (66) ist das Herausforderungs-Antwort bzw. Challenge-Response- Verfahren. Hierbei sendet der Server eine "Herausforderung" an den Client, z.B. einen Zahlenwert. Der Client erfüllt dann die Aufgabe, z.B. führt er eine Berechnung basierend auf dem gesendeten Zahlenwert des Servers aus, und sendet das Ergebnis an den Server zurück. Da der Server die gleiche Berechnung ausführt, kennt er das Ergebnis und kann es mit der gesendeten Antwort des Clients vergleichen. Bei allen drei Möglichkeiten erfolgt entweder die Autorisierung auf dieser Ebene wenn das Einmal-Passwort (Variante 62, 64) bzw. die Antwort (Variante 66) korrekt ist oder die Transaktion wird abgelehnt. Figur 6 zeigt eine weitere Ausführungsvariante, die insbesondere dann vorteilhaft ist, wenn sich das Mobiltelefon des Benutzers z.B. in ein Roaming-Netzwerk eingebucht hat, z.B. bei einem Aufenthalt im Ausland. Bei dieser Ausführungsvariante generiert das Mobiltelefon 36 auf Basis der Nutzer-ID und eines Einmal -Passwortes einen Barcode. Zusätzlich können im Rahmen des mehrschichtigen Sicherheitssystems weitere Informationen, wie z.B. Positionsdaten 32, 30, mit in den Barcode integriert werden. Dieser Barcode wird dann am Transaktionsterminal 34 gescannt 68. Zusätzlich kann der Benutzer 76 am Transaktionsterminal 34 einen PIN-Code eingeben 70. Die Transaktionsinformationen werden dann durch das Transaktionsterminal 34 an den zentralen Systemserver 38 übermittelt 72. Basierend auf dem Einmal-Passwort-System berechnet der zentrale Systemserver 38 paral- lel zu dem Client 36 das individuelle Einmal-Passwort dieses Clients 36. Wie auch in den anderen Ausführungsvarianten kann der zentrale Systemserver 38 nun die übermittelten Transaktionsinformationen überprüfen und die Transaktion bestätigen oder ablehnen. Die Bestätigung oder Ablehnung wird dann vom zentralen Systemserver 38 an das Transaktionsterminal 34 übermittelt 74.
Figur 7 zeigt die mögliche Überprüfung der Echtheit des Systemservers 38 durch das Mobiltelefon bzw. PDA oder ein anderes Kommunikationsmittel 36. Hierzu generiert der Systemserver 38 ein Einmal-Kennwort und sendet es entweder über eine Datenverbindung oder Kurznachricht (SMS) 78 direkt an das Mobiltelefon 36 oder, bei fehlender Funkver- bindung, an das Transaktionsterminal 34. Der Benutzer 76 kann dann das vom Server 38 gesendete Einmal-Kennwort mit dem vom Mobiltelefon errechneten Einmal-Kennwort vergleichen 80. Hierdurch kann der Benutzer die Echtheit des Systemservers 38 überprüfen und verhindern, dass z.B. Betrüger sich in das System einschleichen und Transaktionen manipulieren. Wird das Einmal-Kennwort direkt vom Server38 an das Mobiltelefon ge- sendet, kann die Überprüfung innerhalb des Mobiltelefons 36 ohne weitere Aktion des Benutzers erfolgen. Diese Echtheitsüberprüfung ist mit allen drei beschriebenen Einmal- Kennwort Varianten 62, 64, 66 möglich.
Figur 8 zeigt ein Mobiltelefon, mit welchem ein Barcode eingescannt werden kann, der Details einer Rechnung enthält und der über den Server an ein Kreditinstitut übermittelt wird. Aus Figur 8 geht hervor, dass in dieser Ausführungsvariante des mobilfunkbasierten Transaktionssystems mittels des Mobiltelefons 36 bzw. des dieses handhabenden Benutzers 76, ein Scannen eines Barcodes 100 vgl. Position 48 in Figur 8 erfolgt. Der Barcode 100 befindet sich auf einer Rechnung 102. Der Barcode 100 enthält Zahlungsinformationen wie z.B. den Namen einer Firma 1 10, die Kontonummer, Bankleitzahl, Swiftcode, Iban, Rechnungsnummer, Rechnungsbetrag, Zahlungsziel, Sconti und dergleichen mehr. Durch Einlesen des Barcodes 100 durch das Mobiltelefon 36 besteht die Möglichkeit, die eingescannten Daten mittels einer ersten Datenübermittlung 104 an den Server 38 zu übersenden. Hierbei wird neben den notwendigen Zahlungsdaten aus dem eingelesenen Barcode 100 ebenfalls die Benutzerkennung sowie ein Einmal-Kennwort übermittelt. Vom Server 38 werden sowohl die Zahlungsdaten als auch die Benutzerkennung und das Einmal-Kennwort überprüft. Die Überprüfung des Einmal-Kennwortes erfolgt in der ersten Ebene 12 des Mehrebenensicherheitssystems 10. Bei positiver Überprüfung, d.h. Feststellung, dass sowohl die Zahlungsdaten zu einem beim Server 38 registrierten Zahlungsempfänger, d.h. einer Firma 1 10 gehören, als auch dass das Einmal-Kennwort korrekt ist, werden im Rahmen einer zweiten Datenübermittlung 106 diese Zahlungsdaten an ein Kreditinstitut 1 12 übersandt. Das Kreditinstitut 1 12 gibt gegebenenfalls eine Überweisung durch eine Freigabe 108 frei, so dass der Rechnungsbetrag, der sich auf der Firmenrechnung 102 befindet an die die Rechnung 102 ausstellende Firma 1 10 überwiesen werden kann, gegebenenfalls unter Berücksichtigung ebenfalls im Barcode 100 hinterlegter Details wie z.B. Zahlungsziel, Skonti etc. .
Bezugszeichenliste
10 Mehrebenen-Sicherheitssystem
12 erste Ebene
14 zweite Ebene
16 Standortabgleich (Satellitenoder Netzwerkortung)
18 Zwei-Faktoren- Authentifizierung
20 dritte Ebene
22 biometrische Merkmale
30 GNSS-Ortungssystem (Global Navigation Satellite System)
32 Mobilfunknetz
34 Transaktionsterminal
36 Mobiltelefon
38 Systemserver
40 erste Positionsdatenübermittlung
42 zweite Positionsdatenübermittlung
44 erste Verbindung (Info one time password OTP, Standort) 46 zweite Verbindung (Barcode) 48 dritte Verbindung (Scannen Barcode)
50 vierte Verbindung (Übermittlung von Transaktionsdaten)
52 fünfte Verbindung (Zahlungsanfrage)
54 sechste Verbindung (Bestätigung mit PIN)
56 siebte Verbindung (Bestätigung
Transaktion)
58 normale Verbindung
60 gesonderte Verbindung
62 zeitgesteuerte Zwei-Faktoren-
Authenti fizierung
64 ereignisgesteuerte Zwei- Faktoren-Authentifizierung 66 Herausforderungs-Antwort- Verfahren Zwei-Faktoren- Authentifizierung
Scannen des im Mobiltelefon generierten Barcode (mit Info über Benutzer-ID, One-Time- Password, Standort)
Eingabe PIN am Transaktionsterminal
Übermittlung der Transaktionsinformationen
Bestätigung der Transaktion Benutzer
Einmal-Passwort zur Echtheitsüberprüfung des Servers 38 Vergleich des vom Server 38 gesendeten Einmal-Passworts mit dem vom Mobiltelefon 36 errechneten Einmal-Passworts Barcode
Firmenrechnung
1. Datenübermittlung an
Server 38
2. Datenübermittlung an Kredit institut 1 12
Freigabe der Überweisung Firma, Firmenname
Kreditinstitut

Claims

Patentansprüche
1. Mobilfunkbasiertes Transaktionssystem mit mindestens einem Mobiltelefon (36), mindestens einem Transaktionsterminal (34) sowie mindestens einem Systemserver (38) zur Abwicklung eines bargeldlosen Zahlungsverkehrs, dadurch gekennzeichnet, dass innerhalb eines Mehrebenen-Sicherheitssystems (10) in einer ersten Ebene (12) eine Zwei-Faktoren- Authentifizierung (18) und in einer zweiten Ebene (14) ein Standortabgleich zwischen einem Standort eines Teilnehmers eines Mobilfunknetzes (32) und dem Standort des Teilnehmers innerhalb eines Navigationssystems, insbesondere eines globalen Navigationssatellitensystems (GNSS)- Systems (30) vorgenommen wird.
2. Mobilfunkbasiertes Transaktionssystem gemäß Anspruch 1 , dadurch gekennzeichnet, dass die Zwei-Faktoren- Authentifizierung (18) in der ersten Ebene (12) entweder zeitgesteuert oder ereignisgesteuert oder basierend auf dem Anforderungs-Antwort- Verfahren vorgenommen wird.
3. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass im Rahmen einer zeitgesteuerten Zwei-Faktoren- Authentifizierung (62) der mindestens eine Systemserver (38) und dessen Client, insbesondere eine Software-Applikation auf einem Mobiltelefon (36), in festgelegten Zeitintervallen neue Passwörter berechnen.
4. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass im Rahmen der zeitgesteuerten Zwei-Faktoren- Authentifizierung (18) generierte Einmal-Kennwörter für ein genau definiertes Zeitintervall gültig sind, insbesondere in einem Zeitintervall zwischen 1 Minute bis maximal 15 Minuten.
5. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in der ersten Ebene (12) eine ereignisgesteuerte Zwei-Faktoren-Authentifizierung (64) vorgenommen wird, wobei der mindestens eine Systeniserver (38) eine auf der Client-Seite stattgefundene Berechnung durchführt und in einem Toleranzbereich Einmal-Kennwörter akzeptiert, ausgenommen bereits verwendete Einmal-Kennwörter.
6. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass im Rahmen einer ereignisgesteuerten Zwei- Faktoren-Authentifizierung (64) ein Einmal-Passwort errechnet wird, wobei das Ereignis sowohl die Anforderung eines Barcodes als auch die örtliche Nähe eines Clients (36) zu einem Transaktionsterminal (34) ist, wofür entweder die Position des Clients (34) ermittelt über (40) und (42) mit der Position des Transaktionsterminals (34) verglichen werden, oder das Transaktionsterminal (34) ein kontinuierliches Kurzstreckenfunksignal aussendet, welches das Ereignis auslöst.
7. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Zwei-Faktoren-Authentifizierung (66) innerhalb der ersten Ebene (12) des Mehrebenen-Sicherheitssystems (10) im Rahmen einer "challenge-response" durchgeführt wird, bei dem der mindestens eine Systemserver (38) eine Aufgabe vorgibt, auf deren Basis der Client (36), insbesondere die Software- Applikation eines Mobiltelefons (36), ein Einmal-Passwort errechnet.
8. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Client, insbesondere eine Software- Applikation eines Mobiltelefons (36), einen Wert des mindestens einen Systemservers (38) als Eingabe erhält und auf dieser Eingabe basierend ein Einmal-Kennwort berechnet.
9. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei dem in der zweiten Ebene (14) des Mehrebenen-Sicherheitssystems (10) erfolgenden Standortabgleich der Client, insbesondere die Software- Applikation eines Mobiltelefons (36), einen Barcode von dem mindestens einen Systemserver (38) anfordert, der Client dem mindestens einen Systemserver (38) seinen aktuellen Standort übermittelt.
10. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der aktuelle Standort im Rahmen des Standortabgleiches in der zweiten Ebene (14) aus den Daten eines Satellitenpositionssystems (30) oder aus einem Mobilfunknetz (32) gewonnen wird.
1 1. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass während einer Transaktion der Standort des Transaktionsterminals (34), an dem die aktuelle Transaktion vorgenommen wird, ermittelt wird.
12. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei Nichtübereinstimmung des Standortes des mindestens einen Transaktionsterminals (34), an dem die aktuelle Transaktion vorgenommen wird, mit dem Standort des Teilnehmers des Mobilfunknetzes (32), der entweder aus einer Ordnung innerhalb des Mobilfunknetzes (32) oder mittels eines Satellitenpositionssystems (30) ermittelt wird, die Transaktion abgelehnt wird.
13. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass im Rahmen des in der zweiten Ebene ( 14) durchgeführten Standortabgleiches der Standort des Ablaufs der aktuellen Transaktion mit dem Standort einer vorher vorgenommenen Transaktion verglichen wird und Transaktionen, deren räumlicher Abstand nicht mit einem zeitlichen Abstand korreliert, abgelehnt werden.
14. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Standort des Mobiltelefons (36) zu vorher festgelegten Zeitpunkten in regelmäßigen Zeitintervallen ermittelt wird oder auf Anfrage an den mindestens einen Systemserver (38) übermittelt wird.
15. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Benutzer des mindestens einen Mobiltelefons (36) (Client) neben einer Nutzer-ID auch ein Einmal-Passwort an den mindestens einen Systemserver (38) übermittelt, aus dem der mindestens eine Systemserver (38) einen Barcode generiert, der an den Benutzer des mindestens einen Mobiltelefons (36) zurückgesandt wird.
16. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der generierte Barcode an dem mindestens einen Transaktionsterminal (34) gescannt und zusammen mit den Daten der aktuellen Transaktion an den mindestens einen Systemserver (38) übertragen wird.
17. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der mindestens eine Systemserver (38) eine Anfrage an den Benutzer des Mobiltelefons (36) übermittelt, die von diesem durch Eingabe einer PTN bestätigt wird.
18. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass im Rahmen der Abwicklung einer Zahlung unter- halb eines zuvor festgelegten Betrages auf die Bestätigung des Benutzers des mindestens einen Mobiltelefons (36) durch Eingabe einer PIN verzichtet wird.
19. Mobilfünkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Benutzer des Mobiltelefons (36) (Client) eine Nutzer-ID an den mindestens einen Systemserver (38) übermittelt, aus welcher der mindestens eine Systemserver (38) Daten für einen Barcode generiert, der an den Benutzer des mindestens einen Mobiltelefons (36) zurückgesandt wird,
wobei die Daten zur Generierung des Barcodes durch ein Einmal-Passwort erweitert sind und diese Kombination den endgültigen Barcode darstellt.
20. Mobilfünkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der endgültige Barcode an dem mindestens einen Transaktionsterminal (34) gescannt wird und zusammen mit den Daten der aktuellen Transaktion an den mindestens einen Systemserver (38) übermittelt wird.
21. Mobilfünkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der mindestens eine Systemserver (38) die Daten des endgültigen Barcodes mit den zuvor gesendeten Daten und dem Einmal-Passwort vergleicht und der mindestens eine Systemserver (38) eine Zählungsanfrage an den Benutzer des mindestens einen Mobiltelefons (36) übermittelt, die von dem Benutzer durch Eingabe einer ΡΓΝ zu bestätigen ist.
22. Mobilfünkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die PIN entweder an dem mindestens einen Mobiltelefon (36) oder an dem mindestens einen Transaktionsterminal (34) eingegeben wird.
23. Mobilfünkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der innerhalb der zweiten Ebene (14) ablaufende Standortvergleich und die innerhalb der ersten Ebene (12) ablaufende Zwei- Faktoren-Authentifizierung (18) durch eine dritte Ebene (20) ergänzt sind, in der biometrische Merkmale, insbesondere Finger- oder Handabdrücke, die Iris des Auges oder die Konturierung des Gesichtes, abgeglichen werden oder Informationen aus einem amtlichen Ausweisdokument.
24. Mobilfünkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in der dritten Ebene (20) ein Bluetooth-Dongle eingesetzt wird, der die Anwendung im Client freischaltet, oder aber eine RFID- arte eingesetzt wird.
25. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das mindestens eine Transaktionsterminal (34) eine gesonderte Verbindung (60) zu dem mindestens einen Mobiltelefon (36) des Benutzers im Rahmen einer Datenfunkverbindung herstellt, wobei das mindestens eine Transaktionsterminal (34) entweder eine konstante Verbindung zum mindestens einen Systemserver (38) unterhält (Internet) oder zur Autorisierung eine Wähl Verbindung aufbaut.
26. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Verbindung zwischen dem Client (36), insbesondere einer Software-Applikation eines Mobiltelefons (36), und dem Systemserver (38) über eine geschützte Verbindung, insbesondere ein Virtual Private Network (VPN) aufgebaut wird.
27. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Software-Applikation eines Mobiltelefons (36) ein Einmal-Passwort berechnet und aus diesem zusammen mit anderen Benutzerdaten einen Barcode generiert, welche dann an einem Transaktionsterminal (34) gescannt und an den Systemserver (38) übermittelt wird.
28. Mobilfunkbasiertes Transaktionssystem gemäß einem der vorhergehenden Ansprüche dadurch gekennzeichnet ist, dass ein Systemserver (38) ein Einmal-Passwort an ein Mobiltelefon (36) oder ein Transaktionsterminal (34) sendet, welches mit einem gleichzeitig im Mobiltelefon (36) berechneten Einmal-Passwort verglichen werden kann um die Echtheit des Systemservers (38) zu überprüfen.
PCT/EP2011/000910 2010-03-03 2011-02-24 Mobilfunkbasiertes transaktionssystem WO2011107237A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP11707339A EP2543010A1 (de) 2010-03-03 2011-02-24 Mobilfunkbasiertes transaktionssystem

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
DE102010010165 2010-03-03
DE102010010165.6 2010-03-03
DE102010047257.3 2010-10-01
DE102010047257A DE102010047257A1 (de) 2010-03-03 2010-10-01 Mobilfunkbasiertes Transaktionssystem
ARP20110100366 2011-02-03
ARP110100366A AR080126A1 (es) 2010-03-03 2011-02-03 Sistema de transacciones en base a telefonia celular

Publications (1)

Publication Number Publication Date
WO2011107237A1 true WO2011107237A1 (de) 2011-09-09

Family

ID=44503071

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/000910 WO2011107237A1 (de) 2010-03-03 2011-02-24 Mobilfunkbasiertes transaktionssystem

Country Status (4)

Country Link
EP (1) EP2543010A1 (de)
AR (1) AR080126A1 (de)
DE (1) DE102010047257A1 (de)
WO (1) WO2011107237A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103886283A (zh) * 2014-03-03 2014-06-25 天津科技大学 用于移动用户的多生物特征图像信息融合方法及其应用

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102012006947A1 (de) 2012-04-10 2013-10-10 Authentidate International Ag Verfahren zur bargeldlosen Zahlung am Point of Sale
DE102013013490A1 (de) 2013-08-15 2015-02-19 Afc Rechenzentrum Gmbh Verfahren zur bargeldlosen Abwicklung von Zahlungen aus tragbaren Telekommunikatonsgeräten an Kassen mit einer Telekommunikationsverbindung
DE102014002602B4 (de) 2014-02-24 2021-10-21 Giesecke+Devrient Mobile Security Gmbh Verfahren zum Autorisieren einer Transaktion sowie Verwendung einer Uhr und eines Kassensystems in diesem Verfahren
DE102017211913A1 (de) 2017-07-12 2019-01-17 Robert Bosch Gmbh Verfahren zum Steuern eines elektronischen Gerätes
DE102018210427A1 (de) 2017-07-14 2019-01-17 Robert Bosch Gmbh Verfahren zur klassifikation von zeitreihen

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10005487A1 (de) * 2000-02-08 2001-08-09 Siemens Ag Verfahren zur Nutzeridentitätskontrolle
GB2362012A (en) 2000-03-29 2001-11-07 Ibm Payment for goods and services using a portable communications terminal
WO2008035148A1 (en) * 2006-09-21 2008-03-27 Sony Ericsson Mobile Communications Ab System and method for utilizing a portable network device to initiate and authorize a payment transaction
US20080133373A1 (en) * 2006-11-30 2008-06-05 Motorola, Inc. Method to select payment when using a wireless communication device
US20090068982A1 (en) * 2007-09-10 2009-03-12 Microsoft Corporation Mobile wallet and digital payment
US20090222353A1 (en) 2002-12-20 2009-09-03 John Guest Payment system
WO2009148387A1 (en) * 2008-06-06 2009-12-10 Telefonaktiebolaget L M Ericsson (Publ) Secure card services
US20100012715A1 (en) * 2008-07-21 2010-01-21 Gilbarco Inc. System and method for pairing a bluetooth device with a point-of-sale terminal

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE20008345U1 (de) * 2000-05-09 2000-08-17 Mueller Angelika Kommunikationsgerät mit Fingerabdrucksensor
US20020161708A1 (en) * 2001-02-01 2002-10-31 Gero Offer Method and apparatus for performing a cashless payment transaction
WO2002086808A1 (fr) * 2001-04-17 2002-10-31 Mobilty Co., Ltd. Systeme et procede de protection d'informations
DE10162531A1 (de) * 2001-12-19 2003-07-10 Siemens Ag Verfahren und System zur Abwicklung von Nutzungsberechtigungsüberprüfungs- und/oder Zahlungsvorgängen mittels eines Mobiltelefonie-Endgeräts, Mobiltelefonie-Endgerät, Abfragestation, Steuerungsprogramm für ein Mobiltelefonie-Endgerät und Steuerungsprogramm für eine Abfragestation
US20090112767A1 (en) * 2007-10-25 2009-04-30 Ayman Hammad Escrow system and method

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10005487A1 (de) * 2000-02-08 2001-08-09 Siemens Ag Verfahren zur Nutzeridentitätskontrolle
GB2362012A (en) 2000-03-29 2001-11-07 Ibm Payment for goods and services using a portable communications terminal
US20090222353A1 (en) 2002-12-20 2009-09-03 John Guest Payment system
WO2008035148A1 (en) * 2006-09-21 2008-03-27 Sony Ericsson Mobile Communications Ab System and method for utilizing a portable network device to initiate and authorize a payment transaction
US20080133373A1 (en) * 2006-11-30 2008-06-05 Motorola, Inc. Method to select payment when using a wireless communication device
US20090068982A1 (en) * 2007-09-10 2009-03-12 Microsoft Corporation Mobile wallet and digital payment
WO2009148387A1 (en) * 2008-06-06 2009-12-10 Telefonaktiebolaget L M Ericsson (Publ) Secure card services
US20100012715A1 (en) * 2008-07-21 2010-01-21 Gilbarco Inc. System and method for pairing a bluetooth device with a point-of-sale terminal

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103886283A (zh) * 2014-03-03 2014-06-25 天津科技大学 用于移动用户的多生物特征图像信息融合方法及其应用

Also Published As

Publication number Publication date
AR080126A1 (es) 2012-03-14
DE102010047257A1 (de) 2011-09-08
EP2543010A1 (de) 2013-01-09
DE102010047257A8 (de) 2012-05-24

Similar Documents

Publication Publication Date Title
EP2949094B1 (de) Verfahren zur authentisierung eines nutzers gegenüber einem automat
EP2543010A1 (de) Mobilfunkbasiertes transaktionssystem
DE10224209A1 (de) Autorisierungseinrichtung-Sicherheitsmodul -Terminal-System
EP2528045A1 (de) Verfahren und Diensterechner sowie System zur kartenlosen Authentifizierung
DE102011100144A1 (de) Sicheres drahtloses Zahlungssystem und Verfahren zu dessen Anwendung
DE102011116489A1 (de) Mobiles Endgerät, Transaktionsterminal und Verfahren zur Durchführung einer Transaktion an einem Transaktionsterminal mittels eines mobilen Endgeräts
EP3215974B1 (de) Verfahren zum bereitstellen eines zugangscodes auf einem portablen gerät und portables gerät
EP1456822B1 (de) Verfahren und system zur abwicklung von nutzungsberechtigungsüberprüfungs- und/oder zahlungsvorgängen mittels eines mobiltelefonie-endgeräts, einer abfragestation und eines steuerungsprogramms
EP2561484B1 (de) Verfahren zur handhabung von elektronischen tickets
DE102013212627B4 (de) Elektronisches Transaktionsverfahren und Computersystem
EP2996299B1 (de) Verfahren und Anordnung zur Autorisierung einer Aktion an einem Selbstbedienungssystem
EP2949096A1 (de) Bereitstellung von positionsdaten mittels eines distance-bounding protokolls
DE102009041002A1 (de) Verfahren zur personengebundenen, ortsunabhängigen, bargeldlosen Zahlungsabwicklung und zum ortsunabhängigen Erwerb und Nachweis von personengebundenen Berechtigungen unter Verwendung von Mobilfunkgeräten
DE102007024144B3 (de) Verfahren und Anordnung zur schnellen Kurzanmeldung eines Benutzers an einem Diensleistungsportal mittels einer mobilen Kommunikationseinrichtung
DE102010036037A1 (de) Verfahren zur Durchführung bargeldioser Zahlungstransaktionen und Transaktionsystem zur Durchführung des Verfahrens
EP3561753A1 (de) Datenübertragungs- und verarbeitungsverfahren und anordnung hierfür
DE102013022434B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022433B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022436B3 (de) Elektronisches Transaktionsverfahren und Computersystem
EP1729254B1 (de) Verfahren und System zur Datenübertragung
DE102006007236A1 (de) Verfahren zum Identifizieren von Personen und zum Autorisieren von Vorgängen sowie Endgerät zur Durchführung des Verfahrens
DE202022100435U1 (de) Intelligentes Management-Sicherheitssystem zum Schutz vor Betrug beim Zugang zu einer mobilen Einheit mit Authentifizierungsmöglichkeiten
EP4332919A1 (de) Entwertervorrichtung für ein personentransportsystem
EP3416120A1 (de) Anordnung und verfahren zur nutzerauthentifizierung und zugriffs-autorisierung
DE102013022435B3 (de) Elektronisches Transaktionsverfahren und Computersystem

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11707339

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2011707339

Country of ref document: EP