EP2543010A1

EP2543010A1 - Mobile radio-based transaction system

Info

Publication number: EP2543010A1
Application number: EP11707339A
Authority: EP
Inventors: Patrick Ams
Original assignee: Individual
Current assignee: Individual
Priority date: 2010-03-03
Filing date: 2011-02-24
Publication date: 2013-01-09
Also published as: DE102010047257A1; DE102010047257A8; AR080126A1; WO2011107237A1

Abstract

The invention relates to a mobile radio-based transaction system, comprising at least one mobile telephone (36), at least one transaction terminal (34) and at least one system server (38) for processing a cashless monetary transaction. Within a multi-level security system (10), in a second level (14) the location of a user or of the client (36) within a mobile radio network (32) is compared and/or the location of the subscriber in a satellite positioning system (30) is determined. In a first level (12), a two-factor authentication (18, 62, 64, 66) is performed. A further security verification, for example via biometric features, can be added in an optional third level.

Description

Mobile-based transaction system

PRIOR ART US 2009/0222353 A1 and GB 2 362 012 A disclose payment systems which are cashless and for the implementation of which a mobile telephone is used.

The above outlined solutions according to US 2009/0222353 AI and according to GB 2 362 012 A have the disadvantage that the transactions executed according to these systems can be subject to considerable uncertainty. This is due to the fact that the verification routines according to the solutions GB 2 362 012 A and US 2009/0222353 AI are not or only in a single pass for plausibility are examined. Disclosure of the invention

The present invention has for its object to provide a highly secure, cashless payment and transaction system for one or more users available.

According to the invention, a cashless payment system is proposed, 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. The payment process is now based on an authentication process by means of a barcode or other optical / graphi see or electromagnetic, such as the NFC method (NFC = Near Field Communication) or sound-based identification signal for the mobile phone or a PDA (Personal Digital Assistant ) or another communication device. Furthermore, 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 , In the event of failure of a radio network connection, e.g. within well insulated buildings, 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. An identification signal (e.g., NFC) 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.

In a third step, 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. Alternatively, 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.

In a further step, 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. For confirmation, 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. Alternatively, the user can also enter a PIN code on the mobile phone or PDA before the barcode is generated. Upon confirmation, 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 above briefly sketched, essentially three-stage transaction process is underlaid with different levels of security. Thus, in a first security level, 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. Alternatively, as described above, the generation of the barcode within the mobile phone or PDA or a differently configured communication means.

In a second security level, a location system, such as the Global Positioning System (GPS) or another satellite-based location system, the location of the user with the place where the identification is desired, be it a cash register another identification terminal, to be reconciled. In addition to the GPS, 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. Within the second security level for executing the three-stage transaction process outlined above, 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.

Within this second level of security, 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. As an alternative to the satellite-based location 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.

In another, and deposited third security level, theft protection is implemented. 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). In a first embodiment of an anti-theft protection to be implemented, the entry of a ΡΓΝ is required upon confirmation of the transaction. Alternatively, it is possible to operate a separate activation module, which the user always carries with him, which can be represented for example by a Bluetooth dongle or an RFID chip. In a further, third possible embodiment of 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. closing There is a possibility for identification in that an identification is carried out on the basis of personal identification features, for example a scan of fingerprints or the iris of the eye is carried out on the corresponding transaction terminal. A comparison of the data scanned on the transaction terminal with the data stored on the central server quickly leads to a meaningful identification or non-identification.

In a further advantageous embodiment of the inventively proposed cashless payment system, 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. In this case, 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. In this case, e.g. a point-of-sale terminal as a data radio connection to the server. Alternatively, 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.

Following the solution proposed by the invention, 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. In this regard, it should be noted that 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.

In a further advantageous embodiment of a settlement of transactions, 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. For this purpose, 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. To do this, a user can create a single-user open account or create a multiple user account. In a multi-user account, which may be particularly interesting for companies, government agencies and families, 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.

Especially in the field of IT, various two-factor authentication systems have become established in recent years, providing users with e.g. secure access to company networks or software applications. For this purpose, 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. 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.

Basically, these systems can differentiate between three different types:

A time control

With this type, servers and clients always calculate new passwords at fixed time intervals. Although 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. B event control

For event-driven procedures, 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.

C request-response procedure

There are no synchronization problems in the case of the request-response procedure. In this method, 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 implementation of two-factor authentication in the transaction system, keyword "knowledge" and "ownership", is as follows:

In a first variant, 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.

In a further advantageous embodiment variant, 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. In a further advantageous embodiment, the application generates on the mobile phone, which represents the client, a barcode from the personal user ID and a one-time password. As described above, 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. To speed up the transaction, the input of the PIN can be waived up to a predetermined amount. Alternatively, the PIN can also be entered at the beginning in the mobile phone, for example, to start the generation of the barcode. In addition, 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. To further implement this protection mechanism, 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.

In a further, third security level next to the first two security levels implemented as standard outlined above, a user-related security level can be called in. For this purpose either biometric features of the user can be adjusted, e.g. Finger or hand prints, iris or face, or information from a passport. Alternatively, here also a Bluetooth dongle can be used, which unlocks the application in the client or optionally an RFID card.

Due to the fact that in particular in buildings often limited radio connections prevail, the transaction terminal provides an alternative connection in this case. For this purpose, 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.

In all variants of 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 possible even if e.g. the transaction terminal has no reading unit for barcodes or is damaged.

In the present context, the application with mobile telephone and barcode is understood to mean an application with the mobile telephone and with NFC (near-field communication). The NFC process is the contactless payment method currently favored by credit card companies. Near-Fild Communication (NFC) refers to a transmission standard that is used for the contactless exchange of data over short distances. By means of NFC the exchange of various information such as e.g. Enable phone numbers, images, MP3 files, or digital permissions between two devices that are kept close together. 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.

With the NFC method, 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.

In the case of the NFC standard, an alternative to barcodes is, in particular, when two devices are cryptographically secured and communicate with one another, as is generally the case with payment applications.

Short description of the drawing

With reference to the drawing, the invention will be described below in more detail.

It shows:

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

bilfunknetz, a transaction terminal and a system server,

Figure 3 shows a further embodiment of a communication scheme between

Mobile network, transaction terminal and system server,

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

Figure 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.

Figure 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. variants

The illustration according to FIG. 1 shows the structure of the multilevel safety system in a schematic manner. In the present context, NFC, i. Near-field communication is synonymous and used interchangeably with the term barcode.

Within 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. Within the first level 12, the two-factor authentication 18 takes place. Within the second level 14, 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.

Optionally, 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. For this purpose, either biometric features of the user (client) can be adjusted within the third level. The biometric features may be, for example, fingerprints or handprints, the iris of the eye or the features of the face. Alternatively, information from an official identity document can be stored in the third level. Alternatively, 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. Since these are short-range radio technologies, the connection will automatically abort if Bluetooth dongle or RFID are no longer near the client. If this is the case, the application is blocked and a request for a barcode is not possible. The illustrations according to FIGS. 2 and 3 show variants of the implementation of the mobile radio-based transaction system proposed according to the invention. 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 enumerated components are in all three figures, i. Figures 2, 3 and 4, identical.

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. During the course of the current transaction, 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. If the two locations, i. E. the location where the user of the at least one mobile phone 36 resides and the location of the transaction terminal 34 where the particular transaction is currently in progress do not match, the transaction is rejected. Within the location comparison which takes place in the second level 14 of the multilevel security system 10, 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.

In addition to these system-side security measures, which are implemented in the second level 14 of the multilevel security system 10, 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. However, since satellite reception is often difficult in terms of in-building shielding when using a positioning system 30, in which case only one location determination over the mobile network 32 within which the at least one mobile 36 and thus inevitably the user is communicating would be possible or at fixed times, site comparisons 16 are preferable, but require relatively high energy input.

With reference to Figures 2 and 3, the two-factor authentication 18 which operates within the first level 12 of the multilevel security system 10 will be described in more detail below.

In the embodiment of the mobile radio-based transaction system proposed according to the invention, 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. From this, 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. This is confirmed by the user, ie in the present case the client of the at least one mobile phone 36, in the context of a sixth connection step 54 with a personal PIN , After the confirmation, 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.

In the embodiment variant of the mobile radio-based transaction system proposed according to the invention, 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 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. As part of the fourth connection step 50, 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. To speed up the transaction, the PIN can not be entered as part of the confirmation up to a predetermined amount. In the context of the sixth connection step 54, 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. Since restricted radio links predominate in buildings, the at least one transaction terminal 34 provides an alternative connection for this case. For this purpose, 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. To this end, the client builds a protected connection, for example a so-called virtual private network (VPN), to the system server 38. 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. In this case the server sends a "challenge" to the client, eg a numerical value. The client then 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. FIG. 6 shows a further embodiment, which is advantageous in particular when the user's mobile phone has, for example, logged on into a roaming network, eg during a stay abroad. In this embodiment variant, the mobile phone 36 generates a barcode based on the user ID and a one-time password. In addition, as part of the multi-layer security system, 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. In addition, 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. Calculated based on the one-time password system the central system server 38 parallels the client 36 the individual one-time password of this client 36. As in the other embodiments, 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. For this purpose, 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. By reading the bar code 100 by the mobile phone 36, it is possible to send the scanned data by means of a first data transmission 104 to the server 38. Here, in addition to the necessary payment data from the scanned barcode 100 also the user ID and a one-time password is transmitted. 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. In a positive review, ie determination that both the payment data to a registered at the server 38 payee, ie a company 1 10, and that the one-time password correctly is, as part of a second data transmission 106, this payment data sent to a credit institution 1 12. If necessary, 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.

LIST OF REFERENCE NUMBERS

10 multi-level security system

12 first level

14 second level

16 Site matching (satellite or network location)

18 two-factor authentication

20 third level

22 biometric features

30 GNSS Location System (Global Navigation Satellite System)

32 mobile network

34 transaction terminal

36 mobile phone

38 system servers

40 first position data transmission

42 second position data transmission

44 first connection (info one time password OTP, location) 46 second connection (barcode) 48 third connection (scanning barcode)

50 fourth connection (transmission of transaction data)

52 fifth connection (payment request)

54 sixth connection (confirmation with PIN)

56 seventh connection (confirmation

Transaction)

58 normal connection

60 separate connection

62 timed two-factor

Authentication

64 event-driven two-factor authentication 66 challenge response Method Two-factor authentication

Scan the barcode generated in the mobile phone (with information about user ID, one-time password, location)

Enter PIN at the transaction terminal

Transmission of transaction information

Confirmation of the transaction user

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

Firmenrechnung

1. Data transmission to

Server 38

2. Data transmission to credit institution 1 12

Release of the transfer company, company name

credit institution

Claims

claims

1. Mobile-based transaction system with at least one mobile telephone (36), at least one transaction terminal (34) and at least one system server (38) for processing a cashless payment transaction, characterized in that within a multi-level security system (10) in a first level (12) a two-factor authentication (18) and in a second level (14) a location comparison between a location of a subscriber of a mobile radio network (32) and the location of the subscriber within a navigation system, in particular a global navigation satellite system (GNSS) - system (30) is made.

2. Mobile-based transaction system according to claim 1, characterized in that the two-factor authentication (18) in the first level (12) either time-controlled or event-driven or based on the request-response method is performed.

3. Mobile-based transaction system according to one of the preceding claims, characterized in that in the context of a timed two-factor authentication (62) of at least one system server (38) and its client, in particular a software application on a mobile phone (36), in set new passwords at specified time intervals.

4. Mobile-based transaction system according to one of the preceding claims, characterized in that within the timed two-factor authentication (18) generated one-time passwords are valid for a precisely defined time interval, in particular in a time interval between 1 minute to a maximum of 15 minutes.

5. Mobile-based transaction system according to one of the preceding claims, characterized in that in the first level (12) an event-driven two-factor authentication (64) is performed, wherein the at least one Systeniserver (38) takes place on the client side calculation and accept one-time passwords within a tolerance range, except for one-time passwords already in use.

6. Mobile-based transaction system according to one of the preceding claims, characterized in that in the context of an event-driven two-factor authentication (64) a one-time password is calculated, the event both the request of a barcode and the local proximity of a client (36 ) to a transaction terminal (34), for which either the position of the client (34) determined via (40) and (42) is compared with the position of the transaction terminal (34), or the transaction terminal (34) sends out a continuous short distance radio signal which triggers the event.

7. Mobile-based transaction system according to one of the preceding claims, characterized in that the two-factor authentication (66) within the first level (12) of the multilevel security system (10) is carried out as part of a "challenge-response" in which the at least one system server (38) specifies a task on the basis of which the client (36), in particular the software application of a mobile telephone (36), calculates a one-time password.

8. Mobile-based transaction system according to one of the preceding claims, characterized in that the client, in particular a software application of a mobile phone (36), receives a value of the at least one system server (38) as an input and based on this input calculates a one-time password ,

9. A mobile-based transaction system according to one of the preceding claims, characterized in that in the second level (14) of the multilevel security system (10) location alignment of the client, in particular the software application of a mobile phone (36), a barcode of the requests at least one system server (38), the client transmits the current location to the at least one system server (38).

10. Mobile-based transaction system according to one of the preceding claims, characterized in that the current location in the context of the location adjustment in the second level (14) from the data of a satellite positioning system (30) or from a mobile network (32) is obtained.

1 1. A mobile-based transaction system according to one of the preceding claims, characterized in that during a transaction, the location of the transaction terminal (34) on which the current transaction is made is determined.

12. Mobile-based transaction system according to one of the preceding claims, characterized in that in case of disagreement of the location of the at least one transaction terminal (34) on which the current transaction is made, with the location of the subscriber of the mobile network (32), either of an order is determined within the mobile network (32) or by means of a satellite positioning system (30), the transaction is rejected.

13. Mobile-based transaction system according to one of the preceding claims, characterized in that in the context of the second level (14) carried out location comparison of the location of the expiry of the current transaction with the location of a previously made transaction is compared and transactions whose spatial distance not correlated to a temporal distance, be rejected.

14. Mobile-based transaction system according to one of the preceding claims, characterized in that the location of the mobile telephone (36) is determined at predetermined times at regular time intervals or transmitted on request to the at least one system server (38).

15. Mobile-based transaction system according to one of the preceding claims, characterized in that the user of the at least one mobile phone (36) (client) in addition to a user ID also transmits a one-time password to the at least one system server (38) from which the at least a system server (38) generates a bar code which is returned to the user of the at least one mobile telephone (36).

16. Mobile-based transaction system according to one of the preceding claims, characterized in that the generated bar code is scanned at the at least one transaction terminal (34) and transmitted together with the data of the current transaction to the at least one system server (38).

17. Mobile-based transaction system according to one of the preceding claims, characterized in that the at least one system server (38) transmits a request to the user of the mobile phone (36), which is confirmed by the latter by entering a PTN.

18. Mobile-based transaction system according to one of the preceding claims, characterized in that in the course of processing a payment under Half a predetermined amount is waived the confirmation of the user of at least one mobile phone (36) by entering a PIN.

19. A mobile-based transaction system according to one of the preceding claims, characterized in that the user of the mobile telephone (36) (client) transmits a user ID to the at least one system server (38), from which the at least one system server (38) data for a Generates a barcode which is returned to the user of the at least one mobile phone (36),

wherein the data for generating the bar code is extended by a one-time password and this combination represents the final bar code.

Mobile-based transaction system according to one of the preceding claims, characterized in that the final barcode is scanned at the at least one transaction terminal (34) and transmitted together with the data of the current transaction to the at least one system server (38).

Mobile-based transaction system according to one of the preceding claims, characterized in that the at least one system server (38) compares the data of the final bar code with the previously sent data and the one-time password and the at least one system server (38) sends a count request to the user of the at least one mobile telephone (36) to be confirmed by the user by entering a ΡΓΝ.

Mobile-based transaction system according to one of the preceding claims, characterized in that the PIN is entered either at the at least one mobile telephone (36) or at the at least one transaction terminal (34).

23. Mobilfünkbasiertes transaction system according to any one of the preceding claims, characterized in that within the second level (14) running site comparison and within the first level (12) running two-factor authentication (18) supplemented by a third level (20) in which biometric features, in particular fingerprints or handprints, the iris of the eye or the contouring of the face, are calibrated or information from an official identity document.

24. A mobile-based transaction system according to one of the preceding claims, characterized in that in the third level (20) a Bluetooth dongle is used, which activates the application in the client, or an RFID type is used.

25. Mobile-based transaction system according to one of the preceding claims, characterized in that the at least one transaction terminal (34) establishes a separate connection (60) to the at least one mobile telephone (36) of the user in the context of a data radio connection, wherein the at least one transaction terminal (34 ) either maintains a constant connection to the at least one system server (38) (Internet) or establishes a dial-up connection for authorization.

26. Mobile-based transaction system according to one of the preceding claims, characterized in that the connection between the client (36), in particular a software application of a mobile phone (36), and the system server (38) via a secure connection, in particular a virtual private network (VPN) is established.

27. Mobile-based transaction system according to one of the preceding claims, characterized in that a software application of a mobile phone (36) calculates a one-time password and from this together with other user data generates a barcode which is then scanned at a transaction terminal (34) and to the system server (38) is transmitted.

28. Mobile-based transaction system according to one of the preceding claims, characterized in that a system server (38) sends a one-time password to a mobile phone (36) or a transaction terminal (34), which with a simultaneously in the mobile phone (36) calculated one-time password can be compared to verify the authenticity of the system server (38).