WO2011141062A1 - Bezahlsystem, verfahrung zur erzeugung mindestens eines codepaares zur autorisierung eines abbuchungsvorgangs und verfahren zur durchführung eines bezahlvorgangs - Google Patents

Bezahlsystem, verfahrung zur erzeugung mindestens eines codepaares zur autorisierung eines abbuchungsvorgangs und verfahren zur durchführung eines bezahlvorgangs Download PDF

Info

Publication number
WO2011141062A1
WO2011141062A1 PCT/EP2010/056571 EP2010056571W WO2011141062A1 WO 2011141062 A1 WO2011141062 A1 WO 2011141062A1 EP 2010056571 W EP2010056571 W EP 2010056571W WO 2011141062 A1 WO2011141062 A1 WO 2011141062A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction code
terminal
hash value
transaction
code
Prior art date
Application number
PCT/EP2010/056571
Other languages
English (en)
French (fr)
Inventor
Carlo A. Trugenberger
Albertus Geldenhuys
Original Assignee
Novelty Group Limited
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 Novelty Group Limited filed Critical Novelty Group Limited
Priority to PCT/EP2010/056571 priority Critical patent/WO2011141062A1/de
Publication of WO2011141062A1 publication Critical patent/WO2011141062A1/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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; 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/22—Payment schemes or models
    • G06Q20/26—Debit schemes, e.g. "pay now"
    • 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/385—Payment protocols; Details thereof using an alias or single-use codes

Definitions

  • Payment system method for generating at least one code pair for authorizing a debit transaction and method for performing a
  • the invention relates to a payment system for handling a payment transaction, a method for generating at least one code for authorizing a
  • Mobile payment transactions or mobile payments are payment transactions in which at least the debtor uses mobile electronic communication technology for initiating, authorizing or realizing the payment. Since around the mid-90s, there are serious efforts to use mobile devices or mobile devices for payment transactions.
  • Mobile terminals may be mobile phones, smart phones, personal digital assistant (PDA). Such mobile devices are characterized by the location-independent availability as well as the simultaneous payment.
  • the system includes a central payment device for handling the debit orders, multiple payment points or "point of sales" (POS) where a corresponding payment process can be performed, and numerous mobile terminals in communication with the central payment device to charge the mobile devices with a certain amount of money and then to perform payment transactions with the credit at the individual payment points, so that the terminal acts as a kind of prepaid card from which funds are debited.
  • POS point of sales
  • roiling codes are implemented, which authorize the respective debit.
  • Rolling codes are based on pseudo-random number generators.
  • a side channel attack on the software of a single lost device can be used to trigger the
  • a payment system which comprises: a transaction code generator means for generating at least one transaction code for authorizing at least one payment transaction;
  • a transmission device for transmitting data to at least one
  • the transaction code generating means is adapted to a) generate the transaction code
  • a payment system which comprises:
  • a transaction code generating means for generating at least one transaction code for authorizing at least one payment operation
  • a transmission device for transmitting data to at least one
  • transaction code generator means is adapted to
  • Hash value to form and g) storing at least the first transaction code fragment, the first hash value, the second hash value and the security code in the memory device.
  • the payment system generates a secure code pair for authorizing a debit transaction, wherein a first part of the code pair is stored in the storage means of the transaction generator means and a second part is stored in a memory of the terminal.
  • the terminal may use the parts of the transaction code deposited there to confirm a debit order, the payment system checking this acknowledgment from the data in the storage device and authorizing the debit only if there is a valid code pair.
  • a particular advantage of the selected division and encryption of the transaction code is that it is very secure against any type of attack. Thus, relevant data can be at least partially transmitted over public communication channels without it being possible to spy on the system.
  • the proposed security mechanisms are very difficult to circumvent, so that all parties (both the seller - ie the holder of the point of payment - and the buyer - ie the owner of the terminal) are sufficiently protected against fraud.
  • the said type of link for example the first transaction code fragment with the second transaction code fragment, can be any type of linkage. This may be, for example, a simple concatenation of two character strings (the first and second transaction code fragments). Alternatively, the strings can be added together bit by bit. For the person working here, further methods should be conceivable, wherein it is essential that at least a part of the information originally contained in the fragments is retained in this link. Preferred are linking functions that preserve the entire information content (e.g., bijective mappings).
  • the hash values should preferably be generated from the associated values by means of a cryptographic hash function.
  • the payment system may include an identification code generating means for generating at least one transaction identification number, wherein the payment system is adapted to store the transaction identification number in connection with the at least one transaction code.
  • the transaction identification number is also transmitted to the terminal.
  • the payment system may include an authorization device for authorizing a payment process, wherein the authorization device is configured to receive from a terminal a tuple comprising at least a second transaction code fragment, a third hash value and a debit amount, and the received data with data from the Memory device to authorize the payment process.
  • the authorization device thus receives the part of the code pair stored in the terminal and uses this to determine whether a particular debiting operation has been authorized by the user of the terminal.
  • the third hash value is preferably generated on the basis of the data stored in the memory of the terminal. For example, the terminal may associate the stored third transaction code fragment with the security code of the terminal and / or the user of the terminal and therefrom, e.g. during the payment process, generate the third hash value. This dynamically generated third hash value is then compared by the authorization device with the second hash value stored in the memory device in order to verify the authenticity of the request.
  • the authorization device can be designed to be an actual
  • Debit amount in particular from a payment point
  • a maximum debit amount in particular from the terminal
  • the terminal can grant a debit up to a certain maximum amount by means of its part of the code pair.
  • the paying agent in turn transmits the exact payment amount, so that the authorization device can determine whether the actually requested debit amount is covered by the maximum debit amount.
  • the risk of the buyer in a corresponding transaction is kept as low as possible. He can issue transaction codes that are valid only for a certain amount of money.
  • the transaction code generator device may be configured to assign a maximum debit amount to the at least one transaction code and to store it in connection with at least the first transaction code fragment, the first hash value, the second hash value and the security code of the storage device. It is possible to set the maximum debit amount associated with a particular code pair online, i. preferably determined by the terminal at the time of payment (dynamic determination of the maximum debit amount). On the other hand, a corresponding maximum debit amount can also already be specified when generating the transaction code and stored in the storage device (static determination of the maximum debit amount). Thus, it is ensured that the disposal amount associated with a particular transaction code is preferably limited from the beginning. The owner of the terminal can thus pass on the transaction code, without having to worry that a charge could occur on his account that exceeds this maximum debit amount.
  • any number of transaction codes can be linked together without the proposed security mechanism becoming unavailable. It is therefore conceivable to combine a transaction code, which is associated with, for example, 25 euros, and a transaction code, which is associated with 5 euros, with one another and to transmit them as a unit to the authorization device.
  • the authorization device checks, based on the transmitted hash values and transaction code fragments, whether they are valid transaction codes. It is not necessary to carry out the verification of the individual transaction codes individually. Thus, the necessary bandwidth in the communication can be kept as low as possible.
  • the user So you can combine multiple transaction codes with each other to release a larger amount of money. This can be particularly advantageous if the terminal communicates not directly, but indirectly via the payment parts with the authorization device,
  • the terminal may be configured to display a predefined number of graphical elements, wherein each of the graphical elements is associated with a differing, in particular integer, amount of money, wherein an input device for selecting at least one of the graphical elements is adapted to determine a maximum debit amount.
  • an input device for selecting at least one of the graphical elements is adapted to determine a maximum debit amount.
  • individual graphic symbols are to be assigned to specific amounts of money. For example, different currency notes can be displayed. The user can then set a particular maximum debit amount based on the selection of each graphical symbol. This type of selection can also be advantageously used in conjunction with the transaction codes which have already been assigned a fixed debit amount in advance (e.g., at the time of generation).
  • the graphical elements or symbols may be associated with individual transaction codes. By selecting several of these graphical elements, the user determines that multiple transaction codes are linked together to authorize the requested maximum amount of debit.
  • This type of input has the advantage of simplifying the interaction between the terminal and the user. It is not necessary to have a complicated input device, e.g. in the form of numerous keys, provide. The terminal can therefore be very compact dimensions. An erroneous input is avoided, since a very manageable number of input options exists.
  • the terminal can be designed to calculate a further hash value on the basis of the particular maximum debit amount and to transmit this together with the particular maximum debit amount to an authorization device.
  • the for calculating all hash values or Hashcodes used function stored both in the memory of the terminal and in the memory device.
  • this hash function can be used to secure any communication between the terminal and the payment system.
  • the debit amount that is authorized by means of a certain transaction code can be transmitted in plain text, but also as a hash value.
  • the authorization device can then verify that the transmitted plaintext value is consistent with the hash value.
  • the debit amount can be linked by the terminal with the security code and a hash value can be derived from this linked value by means of the hash function.
  • This fourth hash value is then transmitted to the authorization device, which also receives the unencrypted debit amount.
  • the authorization device can then calculate a corresponding hash value and determine whether the unencrypted debit amount has been deflected.
  • the terminal may comprise a reading device, in particular a barcode reader, for reading in a payee identification number and / or a debit amount. It is possible that a debit is initiated by a terminal alone, with the payee being identified by a payee identification number. This payment recipient identification number can be entered into the terminal in an advantageous manner if the payment office provides a bar code display for this, which can be scanned by the terminal. This ad can be static or dynamic.
  • the object mentioned at the outset is furthermore achieved by a method for generating at least one code pair for authorization of a debiting procedure.
  • This method may include the following steps:
  • the method comprises the steps:
  • the hash function used here can fulfill criteria similar to those already explained in connection with the payment system. Also in accordance with the said method, the advantageous division of the transaction code or values derived therefrom into a pair of keys which are stored on the one hand by the authorization device and on the other hand by the terminal. The generated code pair can be efficiently used to grant, transfer, and then authorize debit transactions.
  • the method may include the following additional steps:
  • the security code and / or the hash function for storing in the memory of the terminal during a single sign-on procedure over a secure communication connection, for example via SSL / TLS (secure socket iayer / transport layer securtty), transmitted by the authorization device.
  • the authorization device preferably transmits the security code and / or the hash function via a secure communication connection.
  • the further communication between the terminal and the authorization device can be unencrypted.
  • the once-transmitted security code and the hash function once transmitted can be used to generate a plurality of code pairs - transaction codes - and thus to release and secure a large number of transactions.
  • the stated object is likewise achieved by a method for carrying out a payment process, the method comprising generating at least one code pair for authorizing a debiting operation, preferably according to the previously described method, as well as performing a debiting operation.
  • Carrying out the debit procedure breaks down into the following steps: a. Transmitting a debit amount from the terminal and / or a
  • Authorization means compares the third hash value from the terminal with the second hash value, a fourth hash value based on the second Transaktäonscodefragments transmitted from the terminal and the first
  • the data stored on the terminal and in the memory device is used to enable and authorize individual debiting operations.
  • the communication between the terminal and the authorization device can be done essentially unencrypted, since a reconstruction of the hash function and the once transmitted security code is virtually impossible and thus neither the monitoring of the communication nor the
  • Intercepting individual packets or their corruption can be advantageously used to attack the transaction. Since the encryption is always associated with the transmission of additional data, due to the invention bandwidth can be saved on the transmission channels. Furthermore, secure encryption is computationally intensive.
  • Performing the debiting operation may include entering a maximum debiting amount at the terminal and transmitting the maximum debiting amount to the authorizing device, wherein inputting the maximum debiting amount comprises:
  • each of the graphic elements is assigned a differing, in particular integral, amount of money
  • selecting at least one of the graphical elements to determine a maximum amount of debit Preferably, a plurality of items may be selected to determine the maximum amount of debit by adding up the individual amounts of money associated therewith. Further advantageous embodiments will be apparent from the dependent claims.
  • Fig. 1 shows a first embodiment of a central payment device, which in
  • FIG. 2 shows a mobile phone for communication with the central payment device
  • Fig. 3 is a schematic representation of the data exchanges between the central
  • FIG. 4 shows the structure of a transaction code according to the invention; a schematic representation of a first mobile payment process in which relevant data is transmitted from the mobile phone directly to the central payment device; a schematic representation of a second mobile payment process in which relevant data is transmitted directly from the mobile phone to the central payment device; a schematic representation of a third mobile payment process, in which relevant data are transmitted from the mobile mitteis the payment parts to the central payment device; a detailed view of the display device of the mobile phone of Fig. 2; a second embodiment of the central bezel device in communication with a point of payment; and
  • the payment system comprises a central payment device 100 in communicative communication with a plurality of payment points 200.
  • Such payment points can be, for example, commercial payment points which serve to process payment transactions with cash, checks, cash cards and credit cards. In FIG. 1, only one payment point 200 is shown.
  • the central payment device 100 is in communicative communication with a plurality of terminals, e.g.
  • a transaction code F see Fig. 4
  • the user of the mobile telephone 300 has to register once with the payment device 100. It is necessary for the latter to authenticate to the payment device 100 and to provide relevant billing data.
  • a secure connection is established between the payment device 100 and the mobile telephone 300. This secure connection can be secured via Transport Layer Security (TLS).
  • TLS Transport Layer Security
  • At least one hash function H () and an individual security code are transmitted to the mobile telephone 300 via this secure communication connection.
  • a user identification number ID can additionally be transmitted in order to be able to unambiguously identify the mobile telephone 300 during further actions or communication processes.
  • the user identification number is generated by an identification code generator 150 and the security code X by a security code generator 140.
  • the hash function H () is the same for all terminals and is transmitted from the encryption function transmission authority 130 to the mobile telephone 300 (see Fig. 3).
  • the mobile phone 300 stores, as shown in FIG. 2, the transmitted data, namely the hash function H (), the security code X and the user identification number ID in a mobile phone memory 301. Using this data, it is possible to load the mobile body 300 with parts of the code pairs. which make it possible to make secure payment transactions. For further communication between the central Payment device 100 and the Mobilteiefon 300 no secure communication line is necessary.
  • transport layer security has been used to possibly secure a conventional IP communication channel.
  • a mobile data storage in order to ensure secure data exchange between the payment service 100 and the mobile telephone 300.
  • the mobile tray 300 logs on to the payment device 100.
  • a transaction code generating means 120 generates a transaction code F (see Fig. 4). This is in accordance with the embodiment described here in at least three transaction code fragments Fl to F3, namely the first transaction code fragment Fl, the second transaction code fragment F2 and the third transaction code fragment F3 divided.
  • the transaction code generator means 120 associates the first transaction code fragment Fl with the second transaction code fragment F2.
  • a first hash value H (Con (Fl, F2)) is calculated by means of the hash function H ().
  • the transaction code generator means 120 associates the third transaction code fragment F3 with the security code X of the user and forms a second hash value H (Con (F3, X)) by means of the hash function H ().
  • the identification code generator device 150 can now assign an individual transaction code identification number transID to the transaction code F as well as to the generated data.
  • Trans ⁇ Action Code F that is, a data set with the following values is used by the transaction code generator device 120 in an authorization database 112, more precisely in a corresponding table 114 is stored: transaction code identification number transID, the first transaction code fragment Fl, the first hash value H (Con (Fl, F2)), second hash value H (Con (F3, X)), security code X. Furthermore, the second and third transaction code fragments F2, F3 are transmitted to the mobile phone 300 together with the transaction code identification number transID. The mobile phone 300 stores these values in the mobile phone memory 301 (see Fig. 2). According to the same method, a plurality of differing code pairs can be generated and stored in the mobile phone memory 301 and the authorization database 112. After filling the mobile telephone 300 with corresponding data, it is possible to release 300 transactions by means of the mobile telephone.
  • Figures 5 to 7 illustrate some of the possible payment transactions, which can be secured by means of the generated code pairs.
  • different constellations can be distinguished.
  • a preferred inventive payment ⁇ system supports payment transactions, in which relevant data directly (see. The embodiments according to FIGS. 5 and 6) and indirectly (see. The embodiment shown in Fig. 7) to the central payment device 100 to be transmitted.
  • Hybrid embodiments are also conceivable in which part of the information is transmitted directly by the mobile telephone 300 and another part indirectly by using the payment office 200.
  • a payment process as illustrated in FIG. 5 can, for example, proceed as follows.
  • the user of the mobile phone 300 enters a store and wants to buy a variety of items.
  • At the point of payment 200 is calculated that the user has to pay a total of 111 euros.
  • the commodity price Value and a payment site identification number shopID are displayed in the form of a two-dimensional barcode.
  • the user of the mobile phone 300 uses a mobile phone bar code reader 303 to read this bar code.
  • the mobile phone 300 knows the payment point identification number shopID - ie the payee - and the commodity price Value.
  • the mobile telephone 300 now selects a transaction identification number transID with corresponding transaction code fragments F2 and F3 which are to be used to authorize the debiting of the commodity price Value from the user's account.
  • the mobile telephone 300 links the third transaction code fragment F3 with the security code X from the mobile telephone memory 301 and generates a third hash value H (Con (F3, X)) using the hash function H ().
  • the transaction code identification number transID, the second transaction code fragment F2, the third hash value H (Con (F3, X)), the commodity price Value and the payment point identification number shopID are transmitted to the central payment device 100.
  • the central payment device 100 more specifically an authorization device 110, receives it Data and uses the information stored in the authorization database 112 to verify the debit and then authorize.
  • a fourth hash value H (Con (Fl, F2)) is calculated online based on the received second transaction code fragment F2 and the first transaction code fragment F1 stored in the authorization database 112.
  • the authorizer 110 compares the transmitted third hash value H (Con (F3, X)) with the second hash value H (Con (F3, X)) stored in the authorization database 112 and the calculated fourth hash value H (Con (Fl, F2)) the first hash value H (Con (Fl, F2)) stored in the authorization database 112.
  • a debit is only authorized if the respective values match.
  • the mobile telephone 300 communicating with the authorizing device 110 possesses valid transaction code fragments F2 and F3, a valid security code X and a valid hash function H ().
  • the authorization device 110 As far as the authorization device 110 carries out an authorization of the debit, it generates a corresponding confirmation message Conf and sends it to the point of payment 200.
  • Mobile phone bar code reader 303 guaranteed. It should be apparent to those skilled in the art that other means of communication may be used at this point. For example, communication could take place via radio interfaces (e.g., Bluetooth or WiFi or Near-Fieid Communication (NFC) or RFID). Alternatively, the relevant data can also be exchanged orally and entered by the user of the mobile phone 300 in this.
  • radio interfaces e.g., Bluetooth or WiFi or Near-Fieid Communication (NFC) or RFID.
  • NFC Near-Fieid Communication
  • RFID Near-Fieid Communication
  • the commodity price Value and the payment part identification number shopID can be exchanged on different communication channels.
  • the payment point identification number is exchanged by barcode as well as in the exemplary embodiment according to FIG.
  • the user value of the mobile phone 300 is orally read by the user of the value of the goods or read from a display of the point of payment 200. Since entering value of goods Value is sometimes very expensive (see, for example, the goods value of 99.99 euros), a simplified payment and input operation is proposed according to another aspect of the present invention.
  • the user of Mobiitelefons 300 thus knows that the commodity price Value is 99.99 euros. He opens an application of its mobile phone 300, whereupon a display device 306 (see Fig.
  • the mobile tray 300 represents graphical icons 308, 308 '.
  • the first graphical symbol 308 is marked in such a way that it is obvious to the user that this graphical symbol symbolizes 5 euros.
  • the second graphic symbol 308 ' which symbolizes a monetary amount of 10 euros, also has a corresponding designation.
  • the user now taps the second graphical icon 308 '10 times to signal the mobile 300 that he is releasing a maximum debit amount of 100 Euro maxValue.
  • the mobile tray 300 transmits the transaction identification number transID, the second transaction code fragment F2 and the calculated third hash value H (Con (F3, X)). Instead of the exact goods price Vaiue, the maximum debit amount maxValue is transmitted.
  • the authorization device uses the measures described to check whether the payment process is authorized. If this is the case, it communicates this to the point of payment 200 via the confirmation message Conf.
  • the payment part 200 can specify the exact commodity price Value, which is then transferred to it, insofar as this is below the authorized maximum debit amount maxValue.
  • the maximum debit amount maxValue can be protected against a forgery during the transfer.
  • the mobile unit 300 connects the maximum debit amount maxValue with the security code and uses this to determine a fifth hash value H (Con (maxValue, X)) on the basis of the hash function H ().
  • This fifth hash value H (Con (maxValue, X)) is transmitted together with the maximum debit amount maxValue to the payment device 100, which can exclude an unauthorized modification of the maximum debit amount maxValue based on the data received and stored in the authorization database 112.
  • a corresponding sixth hash value is calculated and compared with the fifth hash value.
  • the fifth and sixth hash values are thus a kind of individual checksum, which can only be calculated by the authorized institutions.
  • the user of the mobile telephone 300 is also informed orally of the goods price Value.
  • the method described with reference to FIG. 8 is used to establish a maximum debit amount maxValue.
  • the mobile telephone then generates the data relevant for the payment, namely the transaction code identification number transID, the second transaction code fragment F2, the third hash value, the maximum debit amount maxValue and the fifth hash value for securing the maximum debit amount. These values are transmitted to the payment location 200. There is no direct communication with the central payment device 100, as was the case in the previous perennialspieien.
  • the communication between the mobile phone 300 and the point of payment 200 is ensured by a barcode.
  • the mobile telephone 300 uses its display device 306 to display a two-dimensional barcode containing the said information.
  • the point of payment 200 has a barcode reader which collects said data.
  • the data received from the mobile telephone 300 together with the actual commodity price Value and the payment office identification number shopID are transmitted by the payment parts 200 to the payment device 100, preferably the authorization device 110.
  • the authorization device 110 checks the received data on the basis of the first, second, third and fourth hash values and preferably notifies the mobile telephone 300 immediately that a debit has taken place. This message can be made on the basis of a confirmation message Conf.
  • the entire system is implemented so that the bank account of the user of the mobile phone 300 is already charged with corresponding transaction codes when the mobile phone 300 is being filled.
  • the system can be implemented to mimic a prepaid card.
  • the user therefore states at the time of uploading that he has to deposit 100 euros into his account from his bank account. charging the appropriate payment system.
  • the payment system of the present invention debits the amount from the bank account and then generates an appropriate number of transaction codes F. Thereafter, an application within the terminal may be responsible for ensuring that the user's expenses do not exceed the prepaid amount.
  • the transaction codes F were assigned debit amounts during the payment transaction, be it in the form of actually owed goods prices Value or maximum debit amounts maxValue. According to the invention, however, the allocation of a maximum debit amount maxValue can also take place during the generation of the transaction codes F (static determination of the maximum debit amount).
  • the transaction code generating means 120 may store these associated maximum debit amounts maxValue, for example, in the table 114 of the authorization database 112. Insofar as such assignment already takes place during the generation, a further transmission of these maximum charge amounts maxValue can become obsolete, so that, for example, in the embodiments shown in FIGS. 6 and 7, a corresponding transfer is not necessary. Thus, the communication can be made very efficient.
  • the transmission of the data by barcode takes place, for example, between the mobile telephone 300 and the payment location 200. Also, it can be ensured that in the loss of a mobile phone 300, the damage to the user is limited, since even if the individual transaction codes F can not be locked, they have only a predefined maximum value.
  • the hash tone used is distributive with respect to the connection function used. In this case it is possible to use several transaction codes to settle a value of goods owed Value.
  • the necessary communication effort does not increase linearly at. For example, considering the embodiment described with reference to FIG. 7, it would be necessary to transmit a list of transaction identification numbers transID. However, the remaining data volume would not increase because the second transaction code fragment F2 and the third hash code may be representative of a plurality of second transaction code fragments F2 and second hash codes. This representative value is given for example by a bitwise
  • the hash function H () can be applied.
  • the transaction code F for generating a code pair is divided into three transaction code fragments F1-F3 (eg shown in FIG. 4).
  • a corresponding embodiment is illustrated with reference to FIGS. 9 and 10.
  • a user identification number ID can additionally be transmitted in order to be able to unambiguously identify the mobile telephone 300 during further actions or communication processes.
  • the transaction code generator means 120 When loading the mobile phone 300 with a plurality of code pairs, the mobile phone 300 logs on to the payment device 100. Thereafter, the transaction code generator means 120 generates a transaction code F. This is divided according to the embodiment described here into the first transaction code fragment Fl and the second transaction code fragment F2. As already described, the transaction code generator device 120 links the first transaction code fragment F1 to the second transaction code fragment F2. From this first linked value, the first hash value H (Con (Fl, F2)) is calculated by means of the hash function H (). Furthermore, the transaction code generator means 120 associates the third transaction code fragment F2 with the security code X of the user and, by means of the hash function H (), forms the second hash value H (Con (F2, X)).
  • the identification code generator means 150 can now assign an individual transaction code identification number transID to the transaction code F and to the generated data.
  • For the generated transaction code F is thus from the Trans- action code generating means 120 in the authorization database 112, more precisely in the corresponding table 114 (see Fig. 9), stores a data record having the following values: transaction code identification number transID, first transaction code fragment Fl, first hash value H (Con (Fl, F2 , second hash value H (Con (F2, X)), security code X. Only the second transaction code fragment F2 must be transmitted to the mobile phone 300 together with the transaction code identification number transID and stored in the mobile phone memory 301 (see Fig. 10) This process is repeated several times to generate the plurality of code pairs.
  • the mobile phone 300 associates the second transaction code fragment F2 with the security code X from the mobility store 301 and generates the third hash value H (Con (F2, X)) using the hash function H (). For example, to initiate the debit the transactional code identification number transID, the second transaction code fragment F2, the third hash value H (Con (F2, X)), the commodity price Value and the payment site identification number shopID are transmitted to the central payment device 100.
  • the central payment device 100 more specifically the authorization device 110, receives this data and uses the information stored in the authorization database 112 to verify and then authorize the debit.
  • a fourth hash value H (Con (Fl, F2)) is calculated.
  • the authorizer 110 compares the transmitted third hash value H (Con (F2, X)) with the second hash value H (Con (F2, X)) stored in the authorization database 112 and the calculated fourth hash value H (Con (Fl, F2)) the first hash value H (Con (Fl, F2)) stored in the authorization database 112.
  • a debit is only authorized if the respective values match. If the data does not match, the payment process will be denied.
  • the described hedging mechanism can be applied to all payment processes already shown, in particular to those shown in FIGS. 5-7. Using this mechanism saves memory resources. The exchanged messages require less bandwidth.
  • the point of payment can also be realized by a machine for issuing or producing articles. For example, it may be a coffee machine, which implements the dispensing of a coffee and the execution of an associated payment process. In this case, authorizing a transaction or already obtaining part of a valid code pair may result in the actuation of an actuator, eg, a nozzle for dispensing the coffee. Likewise, another machine after the successful completion of a payment process according to the invention print a ticket. Thus, the method described leads to an immediate technical effect.
  • inventive mobile phone 300 can be claimed independently of the further payment system.
  • identification code generator means Zahiungsstelie

Landscapes

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

Abstract

Die vorliegende Anmeldung betrifft ein Bezahlsystem. Das Bezahlsystem umfaßt eine Transaktionscode-Generatoreinrichtung zur Erzeugung mindestens eines Transaktionscodes zur Autorisierung mindestens eines Bezahlvorgangs, eine Speichereinrichtung und eine Übertragungseinrichtung zur Übertragung von Daten an mindestens ein Endgerät. Die Transaktionscode-Generatoreinrichtung ist dazu ausgebildet, einen Transaktionscode zu erzeugen, den Transaktionscode in mindestens ein erstes Transaktionscodefragment, ein zweites Transaktionscodefragment und ein drittes Transaktionscodefragment aufzuteilen und das erste und zweite Transaktionscodefragment an das mindestens eine Endgerät zu übertragen. Des weiteren ist die Transaktionscode-Generatoreinrichtung dazu bestimmt, das erste und zweite Transaktionscodefragment zu verknüpfen und hieraus einen ersten Hashwert zu bilden, das dritte Transaktionscodefragment mit einem Sicherheitscode des Endgeräts und/oder des Benutzers des Endgeräts zu verknüpfen und hieraus einen zweiten Hashwert zu bilden und zumindest das erste Transaktionscodefragment, den ersten Hashwert, den zweiten Hashwert und den Sicherheitscode in der Speichereinrichtung zu speichern.

Description

Bezahlsystem, Verfahren zur Erzeugung mindestens eines Codepaares zur Autorisierung eines Abbuchungsvorgangs und Verfahren zur Durchführung eines
Bezahlvorgangs
Beschreibung
Die Erfindung betrifft ein Bezahisystem zum Abwickeln eines Bezahlvorgangs, ein Verfahren zur Erzeugung mindestens eines Codes zur Autorisierung eines
Abbuchungsvorgangs sowie ein Verfahren zur Durchführung eines Bezahlvorgangs. Mobile Bezahlvorgänge bzw. mobile Payments (auch M-Payments) sind Bezahlvorgänge, bei denen zumindest der Zahlungspflichtige mobile elektronische Kommunikationstechnik für Initiierung, Autorisierung oder Realisierung der Zahlung einsetzt. Seit etwa Mitte der 90er gibt es ernsthafte Bestrebungen, Mobilgeräte bzw. mobile Endgeräte für Bezahlvorgänge einzusetzen. Mobile Endgeräte können Mobiltelefone, Smart Phones (Handys), Personal Digital Assistant (PDA) sein. Solche Mobilgeräte zeichnen sich durch die ortsunabhängige Verfügbarkeit sowie die gleichzeitige
Nutzungsmöglichkeit von Funk-, Mobilfunk (GSM, GPRS, UMTS, EDGE) und anderen Telekommunikationsdiensten aus. Auch Notebooks und Subnotebooks sind mobile Endgeräte, da sie über entsprechende Kommunikationsschnittstellen (z.B. WLAN) verfügen. Mobile Bezahlvorgänge können beispielsweise an Zahlungsstellen (z.B. Kassen von Kaufhäusern, Tankstellen oder anderen Geschäften) vorgenommen werden. Des weiteren ist es möglich, auf Angebote in Printmedien (z,B. Zeitungen) zu reagieren und unmittelbar eine Bestellung durchzuführen. Auch Bezahlvorgänge im Internet können als mobile Bezahlvorgänge abgewickelt werden. Die WO 007/106906 A2 beschreibt ein Bezahlsystem zum Durchführen derartiger mobiler Bezahlvorgänge. Das System umfaßt eine zentrale Bezahlvorrichtung zum Abwickeln der Abbuchungsaufträge, mehrere Zahlungsstellen oder„point of sales" (POS), an denen ein entsprechender Bezahlvorgang durchgeführt werden kann, und zahlreiche mobile Endgeräte, die in kommunikativer Verbindung mit der zentralen Bezahlvorrichtung stehen. Es ist möglich, die mobilen Endgeräte mit einem bestimmten Geldbetrag zu beladen und dann an den einzelnen Zahlungsstellen Bezahivor- gänge mit dem Guthaben durchzuführen. Das Endgerät fungiert also als eine Art Guthabenkarte, von der Geldbeträge abgebucht werden. Um einem Betrug vorzubeu- gen, werden Roilingcodes implementiert, die die jeweilige Abbuchung autorisieren.
Eine Schwachstelle derartiger Bezahlvorgänge liegt in der unzureichenden Sicherheit, die Roliingcodes bereit stellen können. Rollingcodes basieren auf Pseudozufalls- zahlengeneratoren. Eine Seitenkanalattacke (engl, side Channel attack) auf die Software eines einzigen verlorenen Endgeräts kann dazu verwendet werden, den
Codeschlüssel sowie den erzeugenden Algorithmus zu rekonstruieren, wobei diese Art der Kompromittierung verwendet werden kann, um sämtliche mobile Endgeräte anzugreifen. Sowie wäre das gesamte System kompromittiert. Für äußerst sicherheitsrelevante Systeme, wie beispielsweise Bezahlsysteme, sind Pseudozufallszahlen nicht ausreichend. An dieser Steile müssen nicht deterministische Zufallszahlen verwendet werden, um das System abzusichern.
Weitere Bezahlsysteme sind aus der WO 2007/123856 A2, WO 2008/083022 AI und WO 03/042776 A2 bekannt.
Ausgehend von diesem Stand der Technik ist es Aufgabe der vorliegenden Erfindung, ein sichereres Bezahlsystem bereit zu stellen. Des weiteren sollen ein sicheres Verfahren zur Erzeugung mindestens eines Codepaares zur Autorisierung eines Abbuchungsvorgangs und ein Verfahren zur sicheren Durchführung eines Bezahlvorgangs angegeben werden.
Diese Aufgabe wird erfindungsgemäß durch das Bezahlsystem gemäß Anspruch 1 oder 2 gelöst. Insbesondere wird die Aufgabe durch ein Bezahlsystem gelöst, das umfaßt: - eine Transaktionscode-Generatoreinrichtung zur Erzeugung mindestens eines Transaktionscodes zur Autorisierung mindestens eines Bezahlvorgangs;
- eine Speichereinrichtung;
- eine Übertragungseinrichtung zur Übertragung von Daten an ein mindestens
Endgerät, wobei die Transaktionscode-Generatoreinrichtung dazu ausgebildet ist, a) den Transaktionscode zu erzeugen;
b) den Transaktionscode in mindestens ein erstes Transaktionscodefragment, ein zweites Transaktionscodefragment und ein drittes Transaktionscodefragment aufzuteilen;
c) das zweite und dritte Transaktionscodefragment an das mindestens eine Endgerät zu übertragen;
e) das erste und zweite Transaktionscodefragment zu verknüpfen und hieraus einen ersten Hashwert zu bilden;
f) das dritte Transaktionscodefragment mit einem Sicherheitscode des Endgeräts und/oder des Benutzers des Endgeräts zu verknüpfen und hieraus einen zweiten
Hashwert zu bilden; und
g) zumindest das erste Transaktionscodefragment, den ersten Hashwert, den zweiten Hashwert und den Sicherheitscode in der Speichereinrichtung zu speichern. Andererseits wird die Aufgabe auch durch ein Bezahlsystem gelöst, das umfasst:
- eine Transaktionscode-Generatoreinrichtung zur Erzeugung mindestens eines Transaktionscodes zur Autorisierung mindestens eines Bezahivorgangs;
- eine Speichereinrichtung;
- eine Übertragungseinrichtung zur Übertragung von Daten an mindestens ein
Endgerät;
wobei die Transaktionscode-Generatoreinrichtung dazu ausgebildet ist,
a) den Transaktionscode zu erzeugen;
b) den Transaktionscode in mindestens ein erstes Transaktionscodefragment und ein zweites Transaktionscodefragment aufzuteilen;
c) mindestens das zweite Transaktionscodefragment an das mindestens eine Endgerät zu übertragen;
e) das erste und zweite Transaktionscodefragment zu verknüpfen und hieraus einen ersten Hashwert zu bilden;
f) das zweite Transaktionscodefragment mit einem Sicherheitscode des Endgeräts und/oder des Benutzers des Endgeräts zu verknüpfen und hieraus einen zweiten
Hashwert zu bilden; und g) zumindest das erste Transaktionscodefragment, den ersten Hashwert, den zweiten Hashwert und den Sicherheitscode in der Speichereinrichtung zu speichern.
Unabhängig von der gewählten Implementierung generiert das Bezahlsystem ein sicheres Codepaar zur Autorisierung eines Abbuchungsvorgangs, wobei ein erster Teil des Codepaars in der Speichereinrichtung der Transaktions-Generatoreinrichtung und ein zweiter Teil in einem Speicher des Endgeräts hinterlegt sind. Das Endgerät kann die dort hinterlegten Teile des Transaktionscodes verwenden, um einen Abbuchungsauftrag zu bestätigen, wobei das Bezahlsystem diese Bestätigung anhand der Daten in der Speichereinrichtung überprüft und die Abbuchung nur dann autorisiert, wenn ein gültiges Codepaar vorliegt. Ein besonderer Vorteil der gewählten Aufteilung und Verschlüsselung des Transaktionscodes besteht darin, daß diese gegenüber jeglicher Art von Angriffen sehr sicher ist. So können relevante Daten zumindest teilweise über öffentliche Kommunikationskanäle übertragen werden, ohne daß es möglich ist, das System auszuspionieren. Die vorgeschlagenen Sicherheitsmechanismen können nur sehr schwer umgangen werden, so daß alle Beteiligten (sowohl der Verkäufer - also der Inhaber der Zahiungsstelle - als auch der Käufer - also der Besitzer des Endgeräts) ausreichend vor einem Betrug geschützt sind. Die genannte Art der Verknüpfung, beispielsweise des ersten Transaktionscodefragments mit dem zweiten Transaktionscodefragment, kann jede beliebige Art von Verknüpfung sein. Hierbei kann es sich zum Beispiel um ein einfaches Aneinander- hängen von zwei Zeichenketten (dem ersten und zweiten Transaktionscodefragment) handeln. Alternativ können die Zeichenketten bitweise miteinander addiert werden. Für den hier tätigen Fachmann sollten weitere Verfahren denkbar sein, wobei es wesentlich ist, daß bei dieser Verknüpfung zumindest ein Teil der ursprünglich in den Fragmenten enthaltenen Informationen erhalten bleibt. Vorzuziehen sind Verknüpfungsfunktionen, die den gesamten Informationsgehalt bewahren (z.B. bijektive Abbildungen).
Die Hashwerte sollten vorzugsweise mittels einer kryptografischen Hashfunktion aus dem verknüpften Werten erzeugt werden.
Es ist offensichtlich, daß ein Angriff auf die Speichereinrichtung und das Kopieren von dort gespeicherten Daten nur einen sehr geringen Erfolg darstellen, da es nicht möglich ist, anhand dieser Daten die im Endgerät gespeicherten Daten zu rekonstruieren. Somit kann kein gültiges Codepaar erzeugt werden. Das Bezahlsystem kann eine Identifikationscode-Generatoreinrichtung zur Erzeugung mindestens einer Transaktions-Identifikationsnummer umfassen, wobei das Bezahlsystem dazu ausgebildet ist, die Transaktions-Identifikationsnummer in Verbindung mit dem mindestens einen Transaktionscode zu speichern. Vorzugsweise wird die Transaktions-Identifikationsnummer auch an das Endgerät übertragen. Somit ist es möglich, die jeweiligen Teile eines Codepaars einander in eindeutiger Weise zuzuordnen, so daß die Überprüfung eines Transaktionscodes schnell und sicher durchgeführt werden kann.
Das Bezahlsystem kann eine Autorisierungseinrichtung zur Autorisierung eines Bezahlvorgangs umfassen, wobei die Autorisierungseinrichtung dazu ausgebildet ist, von einem Endgerät ein Tupel, umfassend mindestens ein zweites Transaktionscodefrag- ment, einen dritten Hashwert und einen Abbuchungsbetrag, zu empfangen, und die empfangenen Daten mit Daten aus der Speichereinrichtung zu vergleichen, um den Bezahlvorgang zu autorisieren. Die Autorisierungseinrichtung empfängt also den im Endgerät gespeicherten Teil des Codepaars und verwendet diesen, um festzustellen, ob ein bestimmter Abbuchungsvorgang vom Benutzer des Endgeräts bewilligt wurde. Der dritte Hashwert wird vorzugsweise anhand der im Speicher des Endgeräts ge- speicherten Daten erzeugt. Beispielsweise kann das Endgerät das gespeicherte dritte Transaktionscodefragment mit dem Sicherheitscode des Endgeräts und/oder des Benutzers des Endgeräts verknüpfen und hieraus, z.B. während des Bezahlvorgangs, den dritten Hashwert generieren. Dieser dynamisch generierte dritte Hashwert wird dann durch die Autorisierungseinrichtung mit dem in der Speichereinrichtung gespeicherten zweiten Hashwert verglichen, um die Authentizität der Anfrage zu überprüfen.
Die Autorisierungseinrichtung kann dazu ausgebildet sein, einen tatsächlichen
Abbuchungsbetrag, insbesondere von einer Zahlungsstelle, und einen maximalen Abbuchungsbetrag, insbesondere von dem Endgerät, zu empfangen und zu überprüfen, ob der maximale Abbuchungsbetrag größer oder gleich dem tatsächlichen Abbuchungsbetrag ist. Häufig stellt die Kommuntkation zwischen der Zahlungsstelle und dem Endgerät ein Problem dar, so daß nur wenige Daten unmittelbar ausgetauscht werden können. Unterscheidet man zwischen einem maximalen Abbuchungsbetrag und einem tatsächlichen Abbuchungsbetrag, so ist es möglich, einen unnötigen Da- tenaustausch zwischen diesen Entitäten zu vermeiden. So kann das Endgerät mittels seines Teils des Codepaars eine Abbuchung bis zu einem bestimmten Maximalbetrag bewilligen. Die Zahlungsstelle übermittelt ihrerseits den exakten Zahlungsbetrag, so daß die Autorisierungseinrichtung feststellen kann, ob der tatsächlich geforderte Abbuchungsbetrag durch den maximalen Abbuchungsbetrag gedeckt ist. Somit wird das Risiko des Käufers bei einer entsprechenden Transaktion so gering wie möglich gehalten. Er kann Transaktionscodes herausgeben, die lediglich für einen bestimmten Geldbetrag gültig sind.
Die Transaktionscode-Generatoreinrichtung kann dazu ausgebildet sein, dem mindestens einen Transaktionscode einen maximalen Abbuchungsbetrag zuzuordnen und in Verbindung mit zumindest dem ersten Transaktionscodefragment, dem ersten Hash- wert, dem zweiten Hashwert und dem Sicherheitscode der Speichereinrichtung zu speichern. Es ist möglich, den maximalen Abbuchungsbetrag, der einem bestimmten Codepaar zugeordnet ist, online, d.h. zum Zeitpunkt der Bezahlung vorzugsweise durch das Endgerät festzulegen (dynamische Festlegung des maximalen Abbuchungsbetrags). Andererseits kann ein entsprechender maximaler Abbuchungsbetrag auch bereits beim Erzeugen des Transaktionscodes festgelegt und in der Speichereinrichtung hinterlegt werden (statische Festlegung des maximalen Abbuchungsbetrags). Somit wird sichergestellt, daß der Verfügungsbetrag, der einem bestimmten Transaktionscode zugeordnet ist, vorzugsweise von Anfang an beschränkt ist. Der Besitzer des Endgeräts kann den Transaktionscode also weitergeben, ohne daß er befürchten muß, daß eine Belastung seines Kontos auftreten könnte, die diesen maximalen Abbuchungsbetrag übersteigt.
Im Falle der statischen Festlegung des maximalen Abbuchungsbetrags ist es besonders vorteilhaft, wenn die verwendete Hashfunktion zur Erzeugung der Hashwerte bezüglich der gewählten Verknüpfungsfunktion distributiv ist. Es sollte gelten : H(Y+X) = H(Y) + H(X).
Soweit diese Anforderungen erfüllt sind, können eine beliebige Anzahl von Transaktionscodes miteinander verknüpft werden, ohne daß der vorgeschlagene Sicher- heitsmechanismus nicht mehr greifen würde. Es ist also denkbar, einen Transaktionscode, dem beispielsweise 25 Euro zugeordnet sind, und einen Transaktionscode, dem 5 Euro zugeordnet sind, miteinander zu kombinieren, und als eine Einheit an die Autorisierungseinrichtung zu übertragen. Die Autorisierungseinrichtung prüft dann anhand der übertragenen Hashwerte und Transaktionscodefragmente, ob es sich um gültige Transaktionscodes handelt. Es ist nicht notwendig, die Überprüfung der einzelnen Transaktionscodes einzeln vorzunehmen. Somit kann die notwendige Bandbreite bei der Kommunikation so gering wie möglich gehalten werden. Der Benutzer kann also mehrere Transaktionscodes miteinander kombinieren, um einen höheren Geldbetrag freizustellen. Dies kann besonders vorteilhaft sein, wenn das Endgerät nicht unmittelbar, sondern mittelbar über die Zahlungssteile mit der Autorisierungs- einrichtung kommuniziert,
Das Endgerät kann dazu ausgebildet sein, eine vordefinierte Anzahl von grafischen Elementen anzuzeigen, wobei jedem der grafischen Elemente ein sich unterscheidender, insbesondere ganzzahliger Geldbetrag zugeordnet ist, wobei eine Eingabeeinrichtung zur Auswahl mindestens eines der grafischen Elemente ausgebildet ist, um einen maximalen Abbuchungsbetrag zu bestimmen. Besonders in den Fällen, in denen eine dynamische Festlegung des maximalen Abbuchungsbetrags zu einem bestimmten Transaktionscode erfolgt, ist es wünschenswert, daß eine entsprechende Eingabe manuell beispielsweise seitens des Benutzers erfolgt. Diese Eingabe kann unheimlich vereinfacht werden, wenn hierfür keine Zahlen eingegeben werden müssen, um den Betrag festzulegen.
Erfindungsgemäß sollen einzelne grafische Symbole bestimmten Geldbeträgen zugeordnet werden. Beispielsweise können unterschiedliche Geldnoten angezeigt werden. Der Benutzer kann dann anhand der Auswahl der einzelnen grafischen Symbole einen bestimmten maximalen Abbuchungsbetrag festlegen. Diese Art der Auswahl kann auch vorteilhaft in Verbindung mit den Transaktionscodes verwendet werden, denen bereits vorab (z.B. zum Zeitpunkt der Erzeugung) ein fester Abbuchungsbetrag zugeordnet wurde. In diesem Fall können die grafischen Elemente oder Symbole einzelnen Transaktionscodes zugeordnet sein. Durch eine Auswahl mehrerer dieser grafischen Ele- mente legt der Benutzer fest, daß mehrere Transaktionscodes miteinander verbunden werden, um den geforderten maximalen Abbuchungsbetrag zu autorisieren.
Diese Art der Eingabe hat den Vorteil, dass die Interaktion zwischen dem Endgerät und dem Benutzer vereinfacht wird. Es ist nicht notwendig eine komplizierte Eingabe- einrichtung, z.B. in Form von zahlreichen Tasten, vorzusehen. Das Endgerät kann daher sehr kompakt dimensioniert werden. Eine fehlerhafte Eingabe wird vermieden, da eine sehr überschaubare Anzahl von Eingabemöglichkeiten existiert.
Das Endgerät kann dazu ausgebildet sein, einen weiteren Hashwert anhand des ins- besondere maximalen Abbuchungsbetrags zu berechnen und diesen zusammen mit den insbesondere maximalen Abbuchungsbetrag an eine/die Autorisiserungseinrich- tung zu übermitteln. Vorzugsweise wird die zur Berechnung aller Hashwerte oder Hashcodes verwendete Funktion sowohl im Speicher des Endgeräts als auch in der Speichereinrichtung hinterlegt. Somit kann diese Hashfunktion dazu verwendet werden, jegliche Kommunikation zwischen dem Endgerät und dem Bezahlsystem abzusichern. So kann beispielsweise der Abbuchungsbetrag, der mittels eines be- stimmten Transaktionscodes autorisiert wird, im Klartext, aber auch als Hashwert übertragen werden. Die Autorisierungseinrichtung kann dann nachprüfen, ob der übertragene Klartextwert mit dem Hashwert in Einklang ist. Beispielsweise kann der Abbuchungsbetrag vom Endgerät mit dem Sicherheitscode verknüpft und von diesem verknüpften Wert ein Hashwert mittels der Hashfunktion abgeleitet werden. Dieser vierte Hashwert wird dann an die Autorisierungseinrichtung übermittelt, die ebenfalls den unverschlüsselten Abbuchungsbetrag empfängt. Die Autorisierungseinrichtung kann dann einen korrespondierenden Hashwert berechnen und feststellen, ob der unverschlüsselte Abbuchungsbetrag abgefälscht wurde. Das Endgerät kann eine Leseeinrichtung, insbesondere ein Barcode-Lesegerät, zum Einlesen einer Zahlungsempfänger-Identifikationsnummer und/oder eines Abbuchungsbetrags umfassen. Es ist möglich, daß eine Abbuchung allein durch ein Endgerät initiiert wird, wobei der Zahlungsempfänger anhand einer Zahlungsempfänger- Identifikationsnummer identifiziert wird. Diese Zahiungsempfänger-Identifikations- nummer kann in vorteilhafter Weise in das Endgerät eingegeben werden, wenn die Zahlungsstelle hierfür eine Barcodeanzeige bereit stellt, die von dem Endgerät eingescannt werden kann. Diese Anzeige kann statisch oder dynamisch sein.
Die eingangs genannte Aufgabe wird des weiteren durch ein Verfahren zur Erzeugung mindestens eines Codepaars zur Autorisierung eines Abbuchungsvorgangs gelöst.
Dieses Verfahren kann die folgenden Schritte umfassen:
- Erzeugen eines Transaktionscodes;
- Aufteilen des Transaktionscodes in mindestens ein erstes Transaktionscodefragment, ein zweites Transaktionscodefragment und ein drittes Transaktionscodefragment;
- Erzeugen eines ersten Hashwerts durch ein Verknüpfen des ersten und zweiten Transaktionscodefragments und ein Anwenden einer Hashfunktion hierauf;
- Erzeugen eines zweiten Hashwerts durch ein Verknüpfen des dritten
Transaktionscodefragments und eines Sicherheitscodes eines Benutzers und/oder eines Endgeräts und ein Anwenden der Hashfunktion hierauf;
- Speichern des ersten Transaktionscodefragments, des ersten Hashwerts, des zweiten Hashwerts und des Sicherheitscodes in einer Speichereinrichtung einer Autorisierungseinrichtung;
- Speichern des zweiten Transaktionscodefragments, des dritten
Transaktionscodefragments und des Sicherheitscodes in einem Speicher eines
Endgeräts.
In einer ähnlich gearteten Ausgestaltung umfasst das Verfahren die Schritte:
- Erzeugen eines Transaktionscodes ;
- Aufteilen des Transaktionscodes in mindestens ein erstes Transaktionscodefragment und ein zweites Transaktionscodefragment;
- Erzeugen eines ersten Hashwerts durch ein Verknüpfen des ersten und zweiten Transaktionscodefragments und ein Anwenden einer Hashfunktion hierauf;
- Erzeugen eines zweiten Hashwerts durch ein Verknüpfen des zweiten
Transaktionscodefragments und eines Sicherheitscodes eines Benutzers und/oder eines Endgeräts und ein Anwenden der Hashfunktion hierauf;
- Speichern des ersten Transaktionscodefragments, des ersten Hashwerts, des zweiten Hashwerts und des Sicherheitscodes in einer Speichereinrichtung einer Autorisierungseinrichtung;
- Speichern des zweiten Transaktionscodefragments und des Sicherheitscodes in einem Speicher eines Endgeräts.
Die hier verwendete Hashfunktion kann ähnliche Kriterien erfüllen, wie diese bereits in Verbindung mit dem Bezahlsystem erläutert wurden. Auch gemäß dem genannten Verfahren findet die vorteilhafte Aufteilung des Transaktionscodes bzw. von davon abgeleiteten Werten in ein Paar von Schlüsseln statt, die einerseits durch die Autorisierungseinrichtung und andererseits durch das Endgerät gespeichert werden. Das erzeugte Codepaar kann effizient dazu verwendet werden, Abbuchungsvorgänge zu bewilligen, zu übertragen und diese dann zu autorisieren. Das Verfahren kann folgende zusätzliche Schritte umfassen:
- ein Erzeugen einer Transaktions-Identifikationsnummer,
- ein Speichern der Transaktions-Identifikationsnummer in Verbindung mit dem ersten Transaktionscodefragment, dem ersten Hashwert, dem zweiten Hashwert und dem Sicherheitscode in der Speichereinrichtung, und
- ein Speichern der Transaktions-Identifikationsnummer in Verbindung mit dem zweiten Transaktionscodefragment und/oder dem dritten Transaktionscodefragment und/oder dem Sicherheitscode in dem Speicher des Endgeräts.
Somit kann eine effiziente Zuordnung des aufgeteilten Schiüsseipaars oder Codepaars zueinander anhand der Transaktions-Identifikationsnummer erfolgen.
Vorzugsweise wird der Sicherheitscode und/oder die Hashfunktion zum Speichern in dem Speicher des Endgeräts während eines einmaligen Anmeldeverfahrens über eine sichere Kommunikationsverbindung, beispielsweise über SSL/TLS (secure socket iayer/transport layer securtty), von der Autorisierungseinrichtung übertragen. In einer vorteilhaften Ausführungsform der Erfindung wird also zwischen einem einmaligen Anmeldeverfahren und der Erzeugung der Transaktionscodes unterschieden. Während des Anmeldeverfahrens überträgt die Autorisierungseinrichtung vorzugsweise den Sicherheitscode und/oder die Hashfunktion über eine sichere Kommunikationsver- bindung. Die weitere Kommunikation zwischen dem Endgerät und der Autorisierungseinrichtung kann unverschlüsselt erfolgen. Der einmal übertragene Sicherheitscode und die einmal übertragene Hashfunktion können dazu verwendet werden, eine Vielzahl von Codepaaren - Transaktionscodes - zu erzeugen und somit eine Vielzahl von Transaktionen freizugeben und abzusichern.
Die genannte Aufgabe wird ebenfalls durch ein Verfahren zur Durchführung eines Bezahlvorgangs gelöst, wobei das Verfahren ein Erzeugen mindestens eines Codepaars zur Autorisierung eines Abbuchungsvorgangs vorzugsweise gemäß dem vorher beschriebenen Verfahren sowie ein Durchführen eines Abbuchungsvorgangs umfasst. Das Durchführen des Abbuchungsverfahrens untergliedert sich in die folgenden Schritte: a. Übermitteln eines Abbuchungsbetrags von dem Endgerät und/oder einer
Zahlungsstelle an die Autorisierungseinrichtung;
b. Übermitteln einer Zahlungsempfänger-Identifikationsnummer an die
Autorisierungseinrichtung von dem Endgerät und/oder der Zahlungsstelle;
c. Erzeugen eines dritten Hashwerts durch ein Verknüpfen des zweiten oder dritten Transaktionscodefragments des Codepaars und des Sicherheitscodes des Benutzers oder des Endgeräts und ein Anwenden der Hashfunktion hierauf, wobei dieser Schritt von dem Endgerät durchgeführt wird;
d. Übermitteln des dritten Hashwerts und eines im Speicher des Endgeräts
gespeicherten zweiten Transaktionscodefragments des Codepaars; e. Überprüfen, ob ein gültiges Codepaar verwendet wurde, indem die
Autorisierungseinrichtung den dritten Hashwert von dem Endgerät mit dem zweiten Hashwert vergleicht, einen vierten Hashwert anhand des vom Endgerät übermittelten zweiten Transaktäonscodefragments und des ersten
Transaktionscodefragments aus der Speichereinrichtung berechnet und den ersten Hashwert aus der Speichereinrichtung mit dem vierten Hashwert vergleicht.
Auch hier werden die Daten, die auf dem Endgerät und in der Speichereinrichtung gespeichert sind, dazu verwendet, um einzelne Abbuchungsvorgänge freizugeben und zu autorisieren. Es ergibt sich der bereits genannte Vorteil, daß die Daten aus der Speichereinrichtung nicht ausreichen, um ein gültiges Codepaar zu erzeugen und somit Geld abzubuchen, da das notwendige zweite Transaktionscodefragment lediglich im Endgerät gespeichert ist. Die Kommunikation zwischen dem Endgerät und der Autorisierungseinrichtung kann im wesentlichen unverschlüsselt erfolgen, da eine Rekonstruktion der Hashfunktion und des einmal übermittelten Sicherheitscodes quasi unmöglich ist und somit weder die Überwachung der Kommunikation noch das
Abfangen einzelner Pakete noch deren Verfälschung vorteilhaft dazu eingesetzt werden kann, um die Transaktion anzugreifen. Da das Verschlüsseln stets mit dem Übermitteln von zusätzlichen Daten verbunden ist, kann auf Grund der Erfindung Bandbreite auf den Übertragungskanälen eingespart werden. Des weiteren ist eine sichere Verschlüsselung rechenintensiv.
Das Durchführen des Abbuchungsvorgangs kann ein Eingeben eines maximalen Abbu- chungsbetrags am Endgerät und ein Übermitteln des maximalen Abbuchungsbetrags an die Autorisierungseinrichtung umfassen, wobei das Eingeben des maximalen Abbuchungsbetrags umfaßt:
- ein Anzeigen einer Vielzahl von graphischen Elementen auf einer Anzeigeeinrichtung des Endgeräts, wobei jedem der graphischen Elemente ein sich unterscheidender, insbesondere ganzzahliger Geldbetrag zugeordnet ist,
- ein Auswählen mindestens eines der graphischen Elemente, um einen maximalen Abbuchungsbetrag zu bestimmen. Vorzugsweise können mehrere Elemente ausgewählt werden, um den maximalen Abbuchungsbetrag durch ein Aufsummieren der einzelnen zugeordneten Geldbeträge zu bestimmen. Weitere vorteilhafte Ausführungsformen ergeben sich anhand der Unteransprüche.
Nachfoigend wird die Erfindung mittels mehrerer Ausführungsbeispiele beschrieben, die anhand von Abbildungen näher erläutert werden. Hierbei zeigen:
Fig. 1 eine erste Ausführungsform einer zentralen Bezahlvorrichtung, die in
kommunikativer Verbindung mit einer Zahlungsstelle steht; Fig. 2 ein Mobiltelefon zur Kommunikation mit der zentralen Bezahlvorrichtung aus
Fig. l;
Fig. 3 eine schematische Darstellung des Datenaustausche zwischen der zentralen
Bezahlvorrichtung und dem Mobilteiefon;
Fig. 4 den Aufbau eines erfindungsgemäßen Transaktionscodes; eine schematische Darstellung eines ersten mobilen Bezahlvorgangs, bei dem relevante Daten von dem Mobiitelefon unmittelbar an die zentrale Bezahlvorrichtung übermittelt werden; eine schematische Darstellung eines zweiten mobilen Bezahlvorgangs, bei dem relevante Daten unmittelbar von dem Mobiitelefon an die zentrale Bezahlvorrichtung übermittelt werden; eine schematische Darstellung eines dritten mobilen Bezahlvorgangs, bei dem relevante Daten von dem Mobiltelefon mitteis der Zahlungssteile an die zentrale Bezahlvorrichtung übermittelt werden; eine Detaildarstellung der Anzeigeeinrichtung des Mobiltelefons aus Fig. 2; eine zweite Ausführungsform der zentralen Bezahivorrichtung, die in kommunikativer Verbindung mit einer Zahlungsstelle steht; und
Fig. 10 ein Mobiitelefon zur Kommunikation mit der zentralen Bezahlvorrichtung aus
Fig. 9, In der nachfolgenden Beschreibung werden für gleiche und gleich wirkende Teile dieselben Bezugsziffern verwendet.
Das erfindungsgemäße Bezahlsystem umfaßt eine zentrale Bezahlvorrichtung 100, die mit einer Vielzahl von Zahlungsstellen 200 in kommunikativer Verbindung steht.
Derartige Zahlungsstellen können beispielsweise handelsübliche Zahlungsstellen sein, die zur Abwicklung von Zahlungsvorgängen mit Bargeid, Schecks, Geldkarten und Kreditkarten dienen, In der Fig. 1 wird lediglich eine Zahlungsstelle 200 dargestellt.
Des weiteren steht die zentrale Bezahlvorrichtung 100 in kommunikativer Verbindung mit einer Vielzahl von Endgeräten, z.B. mit dem in Fig. 2 gezeigten obiiteiefon 300. Um einen erfindungsgemäßen Bezahlvorgang mitteis eines Transaktionscodes F (vgl. Fig. 4) durchführen zu können, muß sich der Benutzer des Mobiltelefons 300 einmal bei der Bezahlvorrichtung 100 anmelden. Es ist notwendig, daß dieser sich gegenüber der Bezahlvorrichtung 100 authentifiziert und relevante Abrechnungsdaten angibt. Im Zuge des Anmeldeverfahrens wird eine sichere Verbindung zwischen der Bezahlvor- richtung 100 und dem Mobiltelefon 300 hergestellt, Diese sichere Verbindung kann über Transport Layer Security (TLS) abgesichert werden. Über diese sichere Kommunikationsverbindung werden zumindest eine Hashfunktion H() und ein individueller Sicherheitscode an das Mobiltelefon 300 übertragen. Optional kann zusätzlich eine Benutzeridentifikationsnummer ID übermittelt werden, um das Mobiltelefon 300 bei weiteren Aktionen oder Kommunikationsvorgängen eindeutig identifizieren zu können. Vorzugsweise wird die Benutzeridentifikationsnummer von einer Identifikationscode- Generatoreinrichtung 150 und der Sicherheitscode X von einer Sicherheitscode- Generatoreinrichtung 140 erzeugt. In einem Ausführungsbeispiel der vorliegenden Erfindung ist die Hashfunktion H () für alle Endgeräte die gleiche und wird von der Verschlüsselungsfunktions-Übermittlungseinrächtung 130 an das Mobiltelefon 300 übermittelt (vgl. Fig. 3).
Das Mobiltelefon 300 speichert wie in Fig, 2 gezeigt die übermittelten Daten, nämlich die Hashfunktion H (), den Sicherheitscode X und die Benutzeridentifikationsnummer ID in einem Mobiltelefonspeicher 301. Mittels dieser Daten ist es möglich, das Mobiiteiefon 300 mit Teilen der Codepaare zu beladen, die es ermöglichen, sicher Bezahlvorgänge vorzunehmen. Für die weitere Kommunikation zwischen der zentralen Bezahlvorrichtung 100 und dem Mobilteiefon 300 ist keine sichere Kommunikationsleitung notwendig.
In dem vorbeschriebenen Ausführungsbeispiel wurde die Transport Layer Security verwendet, um möglicherweise einen herkömmlichen IP-Kommunikationskanal abzusichern. Alternativ wäre es auch möglich, einen mobilen Datenspeicher zu verwenden, um einen sicheren Datenaustausch zwischen der Bezahlvorrächtung 100 und dem Mobiltelefon 300 zu gewährleisten. Um das Mobiitelefon 300 zu beladen - es derart mit Daten zu versorgen, daß eine Vielzahl von Abbuchungsvorgängen freigegeben werden kann, meldet sich das Mobilteiefon 300 bei der Bezahlvorrichtung 100 an. Hierauf erzeugt eine Transaktionscode- Generatoreinrichtung 120 einen Transaktionscode F (vgl. Fig. 4). Dieser wird gemäß dem hier beschriebenen Ausführungsbeispiel in mindestens drei Transaktionscode- fragmente Fl bis F3, nämlich das erste Transaktionscodefragment Fl, das zweite Transaktionscodefragment F2 und das dritte Transaktionscodefragment F3 aufgeteilt. Die Transaktionscode-Generatoreinrichtung 120 verknüpft das erste Transaktionscodefragment Fl mit dem zweiten Transaktionscodefragment F2. Beispielsweise können die Zeichenketten einfach aneinander gehängt werden: Con (Fl, F2) = "abba" (Fl = "ab", F2 = "ba"). Von diesem ersten verknüpften Wert wird mittels der Hash- funktion H () ein erster Hashwert H (Con (Fl, F2)) errechnet. Des weiteren verknüpft die Transaktionscode-Generatoreinrichtung 120 das dritte Transaktionscodefragment F3 mit dem Sicherheitscode X des Benutzers und bildet mittels der Hashfunktion H () einen zweiten Hashwert H (Con (F3, X)). Die Identifikationscode-Generatoreinrichtung 150 kann nun dem Transaktionscode F sowie den generierten Daten eine individuelle Transaktionscode-Identäfikationsnummer transID zuordnen. Für den erzeugten Trans¬ aktionscode F wird also von der Transaktionscode-Generatoreinrichtung 120 in einer Autorisierungsdatenbank 112, genauer gesagt in einer entsprechenden Tabelle 114, ein Datensatz mit den folgenden Werten gespeichert: Transaktionscode-Identifika- tionsnummer transID, erstes Transaktionscodefragment Fl, erster Hashwert H (Con (Fl, F2)), zweiter Hashwert H (Con (F3, X)), Sicherheitscode X. Des weiteren wird das zweite und dritte Transaktionscodefragment F2, F3 zusammen mit der Transaktionscode-Identifikationsnummer transID an das Mobiltelefon 300 übermittelt. Das Mobiltelefon 300 speichert diese Werte in dem Mobiltelefonspeicher 301 (vgl. Fig, 2). Nach dem gleichen Verfahren können eine Vielzahl von sich unterscheidenden Codepaaren erzeugt und im Mobiitelefonspeicher 301 und der Autorisierungsdatenbank 112 gespeichert werden, Nach dem Befüllen des Mobiltelefons 300 mit entsprechenden Daten ist es möglich, mittels des Mobiltelefons 300 Transaktionen freizugeben.
Die Figuren 5 bis 7 verdeutlichen einige der möglichen Bezahlvorgänge, die sich mittels der generierten Codepaare absichern lassen. Hierbei können verschiedene Konstellationen unterschieden werden. Ein bevorzugtes erfindungsgemäßes Bezahl¬ system unterstützt Bezahlvorgänge, bei denen relevante Daten unmittelbar (vgl. die Ausführungsbeispiele gemäß Fig. 5 und 6) und mittelbar (vgl. das Ausführungsbeispiel gemäß Fig. 7) an die zentrale Bezahlvorrichtung 100 übermittelt werden. Es sind auch hybride Ausführungsformen denkbar, bei denen ein Teil der Informationen unmittel- bar durch das Mobiitelefon 300 und ein anderer Teil mittelbar unter Verwendung der Zahlungsstelle 200 übertragen werden.
Ein Bezahlvorgang wie in der Fig. 5 verdeutlicht, kann beispielsweise wie folgt ablaufen. Der Benutzer des Mobiltelefons 300 betritt ein Geschäft und möchte eine Vielzahl von Artikeln kaufen. An der Zahlungsstelle 200 wird errechnet, daß der Benutzer insgesamt 111 Euro zu zahlen hat. Um den erfindungsgemäßen mobilen Bezahlvorgang durchführen zu können, wird der Warenpreis Value sowie eine Zahlungsstellen- Identifikationsnummer shopID in Form eines zweidimensionalen Barcodes angezeigt. Der Benutzer des Mobiltelefons 300 verwendet einen Mobiitelefon-Barcodeleser 303, um diesen Barcode einzulesen. Somit kennt das Mobiitelefon 300 die Zahlungsstellen- Identifikationsnummer shopID - also den Zahlungsempfänger - und den Warenpreis Value. Das Mobiltelefon 300 wählt nun eine Transaktions-Identifikationsnummer transID mit entsprechenden Transaktionscodefragmenten F2 und F3 aus, die zur Autorisierung der Abbuchung des Warenpreises Value vom Konto des Benutzers verwendet werden sollen, Das Mobiltelefon 300 verknüpft das dritte Transaktionscodefragment F3 mit dem Sicherheitscode X aus dem Mobiitelefonspeicher 301 und erzeugt unter Verwendung der Hashfunktion H () einen dritten Hashwert H (Con (F3, X)). Um die Abbuchung zu veranlassen, wird die Transaktionscode-Identifikationsnummer transID, das zweite Transaktionscodefragment F2, der dritte Hashwert H (Con (F3, X)), der Warenpreis Value und die Zahlungsstellen-Identifikationsnummer shopID an die zentrale Bezahlvorrichtung 100 übermittelt. Die zentrale Bezahlvorrichtung 100, genauer gesagt eine Autorisierungseinrichtung 110, empfängt diese Daten und nutzt die in der Autorisierungsdatenbank 112 gespeicherten Informationen, um die Abbuchung zu verifizieren und dann zu autorisieren.
Im Zuge des Verifikationsprozesses wird online anhand des empfangenen zweiten Transaktionscodefragments F2 und des in der Autorisierungsdatenbank 112 gespeicherten ersten Transaktionscodefragments Fl ein vierter Hashwert H (Con (Fl, F2)) errechnet. Die Autorisierungseinrichtung 110 vergleicht den übertragenen dritten Hashwert H (Con (F3, X)) mit dem in der Autorisierungsdatenbank 112 gespeicherten zweiten Hashwert H (Con (F3, X)) und den errechneten vierten Hashwert H (Con (Fl, F2)) mit dem in der Autorisierungsdatenbank 112 gespeicherten ersten Hashwert H (Con (Fl, F2)). Eine Abbuchung wird nur dann autorisiert, wenn die jeweiligen Werte übereinstimmen. Somit kann sichergestellt werden, daß das mit der Autorisierungseinrichtung 110 kommunizierende Mobiltelefon 300 im Besitz von gültigen Transaktionscodefragmenten F2 und F3, einem gültigen Sicherheitscode X und einer gültigen Hashfunktion H () ist. Soweit die Autorisierungseinrichtung 110 eine Autorisierung der Abbuchung vornimmt, generiert sie eine entsprechende Bestätigungsnachricht Conf und sendet diese an die Zahlungsstelle 200.
In dem vorbeschriebenen Ausführungsbeispiel wurde eine Kommunikation zwischen der Zahlungsstelle 200 und dem Mobiltelefon 300 mittels eines Barcodes und des
Mobiltelefon-Barcodelesers 303 gewährleistet. Für den hier tätigen Fachmann sollte es offensichtlich sein, daß an dieser Stelle auch andere Kommunikationsmittel eingesetzt werden können. Beispielsweise könnte eine Kommunikation mittels Funkschnittstellen (z.B. Bluetooth oder WiFi oder Near Fieid Communication (NFC) oder RFID) statt- finden. Alternativ können die relevanten Daten auch mündlich ausgetauscht und vom Benutzer des Mobiltelefons 300 in dieses eingegeben werden.
Alternativ können der Warenpreis Value und die Zahlungssteilen-Identifikationsnum- mer shopID auf unterschiedlichen Kommunikationskanälen ausgetauscht werden. In dem in Fig. 6 gezeigten Ausführungsbeispiel wird die Zahlungsstellen-Identifikations- nummer ebenso wie in dem Ausführungsbeispiel gemäß Fig. 5 per Barcode ausgetauscht. Den Warenpreis Value erfährt der Benutzer des Mobiltelefons 300 jedoch mündlich oder liest diesen von einer Anzeige der Zahlungsstelle 200 ab. Da das Eingeben von Warenpreisen Value mitunter sehr aufwendig ist (vgl . beispielsweise den Warenwert von 99,99 Euro), wird gemäß einem weiteren Aspekt der vorliegenden Erfindung ein vereinfachter Bezahl- und Eingabevorgang vorgeschlagen. Der Benutzer des Mobiitelefons 300 weiß also, daß der Warenpreis Value 99,99 Euro beträgt. Er öffnet eine Anwendung seines Mobiltelefons 300, woraufhin eine Anzeigeeinrichtung 306 (vgl. Fig. 2) des Mobilteiefons 300 grafische Symbole 308, 308' darstellt. Das erste grafische Symbol 308 ist dabei derart gekennzeichnet, daß es für den Benutzer offensichtlich ist, daß dieses graphische Symbol 5 Euro symbolisiert. Eine entspre- chende Kennzeichnung hat auch das zweite grafische Symbol 308', das einen Geldbetrag von 10 Euro symbolisiert. Der Benutzer tippt nun 10 Mal auf das zweite grafische Symbol 308', um dem Mobiltelefon 300 zu signalisieren, daß er einen maximalen Abbuchungsbetrag maxValue von 100 Euro freigibt. Wie bereits unter Bezugnahme auf die Fig. 5 beschrieben, übermittelt das Mobilteiefon 300 hierauf die Transaktions- Identifikationsnummer transID, das zweite Transaktionscodefragment F2 und den errechneten dritten Hashwert H (Con (F3, X)). Anstelle des exakten Warenpreises Vaiue wird der maximale Abbuchungsbetrag maxValue übermittelt. Die Autorisierungsein- richtung überprüft anhand der beschriebenen Maßnahmen, ob der Bezahlvorgang autorisiert wird. Sollte dies der Fall sein, teilt sie dies der Zahiungsstelle 200 über die Bestätigungsnachricht Conf mit. Hierauf kann die Zahlungssteiie 200 den exakten Warenpreis Value angeben, der ihr dann, soweit dieser unterhalb des autorisierten maximalen Abbuchungsbetrags maxValue liegt, überwiesen wird.
Optional kann bei der Kommunikatton zwischen dem Mobiltelefon 300 und der Bezahi- Vorrichtung 100 der maximale Abbuchungsbetrag maxValue gegen eine Abfälschung bei der Übertragung abgesichert werden. Hierfür verbindet das Mobilteiefon 300 den maximalen Abbuchungsbetrag maxValue mit dem Sicherheitscode und ermittelt hieraus anhand der Hashfunktion H () einen fünften Hashwert H (Con (maxValue, X)). Dieser fünfte Hashwert H (Con (maxValue, X)) wird zusammen mit dem maximalen Abbuchungsbetrag maxValue an die Bezahlvorrichtung 100 übermittelt, die anhand der empfangenen und in der Autorisierungsdatenbank 112 gespeicherten Daten eine unautorisierte Abänderung des maximalen Abbuchungsbetrags maxValue ausschließen kann. Hierfür wird ein korrespondierender sechster Hashwert berechnet und mit dem fünften Hashwert verglichen. Der fünfte und sechste Haschwert sind also eine Art in- dividuelle Quersumme, die nur von den berechtigten Einrichtungen errechnet werden kann.
In einer weiteren Anwendungsmöglichkeit des erfindungsgemäßen Bezahlsystems (vgl. Fig. 7) wird dem Benutzer des Mobiltelefons 300 ebenfalls mündlich der Waren- preis Value mitgeteilt. Das anhand der Fig. 8 beschriebene Verfahren wird zur Festlegung eines maximalen Abbuchungsbetrags maxValue angewandt. Die graphischen Symbole 308, 308' werden also verwendet, um den maximalen Abbuchungsbetrag maxValue auszuwählen. Hierauf generiert das Mobiitelefon die für die Zahlung relevanten Daten, nämlich die Transaktionscode-Identifikationsnummer transID, das zweite Transaktionscodefragment F2, den dritten Hashwert, den maximalen Abbuchungsbetrag maxValue und den fünften Hashwert zur Absicherung des maximalen Abbuchungsbetrags, Diese Werte werden an die Zahlungsstelle 200 übermittelt. Es erfolgt keine unmittelbare Kommunikation mit der zentralen Bezahlvorrichtung 100, wie dies in den vorhergehenden Ausführungsbeispieien der Fall war. Vorzugsweise wird die Kommunikation zwischen dem Mobiitelefon 300 und der Zahlungsstelle 200 durch einen Barcode gewährleistet. Das Mobiltelefon 300 nutzt seine Anzeigeeinrich- tung 306 zur Anzeige eines zweidimensionalen Barcodes, der die genannten Informationen enthält. Die Zahlungsstelle 200 verfügt über eine Barcode-Leseeinrichtung, die die genannten Daten erfaßt. Danach werden die von dem Mobiltelefon 300 empfangenen Daten zusammen mit dem tatsächlichen Warenpreis Value und der Zahlungs- stellen-Identifikationsnummer shopID durch die Zahlungssteile 200 an die Bezahi- Vorrichtung 100, vorzugsweise die Autorisierungseinrichtung 110, übermittelt. Die Autorisierungseinrichtung 110 überprüft die empfangenen Daten anhand des ersten, zweiten, dritten und vierten Hashwerts und teilt dem Mobiltelefon 300 vorzugsweise unmittelbar mit, daß eine Abbuchung stattgefunden hat. Diese Mitteilung kann anhand einer Bestätigungsnachricht Conf erfolgen.
Für den hier tätigen Fachmann sollte es offensichtlich sein, daß die anhand der Fig. 7 beschriebene Ausführungsform lediglich beispielhaften Charakter hat. So ist es ohne weiteres denkbar, dieses Ausführungsbeispie! so zu modifizieren, daß kein maximaler Abbuchungsbetrag und kein entsprechender fünfter Hashwert von dem Mobiitelefon an die Zahlungsstelle 200 und von der Zahlungsstelle 200 an die zentrale Bezahlvor- richtung 100 übermittelt wird. Auf eine entsprechende Absicherung kann vollständig verzichtet werden oder sie kann durch einen anderen Mechanismus gewährleistet werden. Erfindungsgemäß ist es möglich, daß das Bankkonto des Benutzers des Mobiltelefons 300 erst dann belastet wird, wenn eine Zahlung erfolgt ist. Möglicherweise kann das Bankkonto des Benutzers auch erst zu einem späteren Zeitpunkt belastet werden. Vorzugsweise wird das ganze System so implementiert, daß das Bankkonto des Benutzers des Mobiltelefons 300 bereits beim Befüllen des Mobiitelefons 300 mit ent- sprechenden Transaktionscodes belastet wird. So kann das System so implementiert werden, daß es eine Art Guthabenkarte (prepaid card) nachahmt. Der Benutzer gibt also zum Aufladezeitpunkt an, daß er von seinem Bankkonto 100 Euro in das erfin- dungsgemäße Bezah!system laden möchte. Das erfindungsgemäße Bezahlsystem bucht den Betrag vom Bankkonto ab und generiert hierauf eine angemessene Anzahl von Transaktionscodes F. Danach kann eine Anwendung innerhalb des Endgeräts dafür zuständig sein, daß die Ausgaben des Benutzers nicht den vorausgezahlten Betrag überschreiten.
In dieser Fallkonstellation können ebenfalls Ausgaben getätigt werden, bei denen die maximalen Abbuchungsbeträge maxValue stets größer sind als der tatsächlich geschuldete Warenpreis Value. Die Differenz zwischen diesen Beträgen wird dem Benut- zer nach jedem getätigten Abbuchungsverfahren auf sein Bankkonto gutgeschrieben. Die Bezahlvorrichtung 100 ist also derart ausgebildet, daß sie den Differenzbetrag zwischen dem maximalen Abbuchungsbetrag maxValue und dem tatsächlich geschuldeten Warenpreis Value auf das Bankkonto des Benutzers zurück überweist oder in einer anderen Form auszahlt.
In den vorbeschriebenen Ausführungsbeispielen wurden den Transaktionscodes F während des Bezahivorgangs Abbuchungsbeträge - sei es in Form von tatsächlich geschuldeten Warenpreisen Value oder maximalen Abbuchungsbeträgen maxValue - zugewiesen. Erfindungsgemäß kann aber die Zuweisung eines maximalen Abbu- chungsbetrags maxValue auch während der Erzeugung der Transaktionscodes F erfolgen (statische Festlegung des maximalen Abbuchungsbetrags). Die Transaktionscode- Generatoreinrichtung 120 kann diese zugeordneten maximalen Abbuchungsbeträge maxValue beispielsweise in der Tabelle 114 der Autorisierungsdatenbank 112 speichern. Soweit eine derartige Zuweisung bereits bei der Generierung erfoigt, kann eine weitere Übertragung dieser maximalen Abbuchungsbeträge maxValue gegenstandslos werden, so daß beispielsweise bei den in den Figuren 6 und 7 gezeigten Ausführungsformen eine entsprechende Übermittlung nicht notwendig ist. Somit kann die Kommunikation sehr effizient gestaltet werden. Dies ist besonders dann vorteilhaft, wenn die Übermittlung der Daten per Barcode beispielsweise zwischen dem Mobilte- lefon 300 und der Zahlungsstelle 200 erfolgt. Auch kann sichergestellt werden, daß bei dem Verlust eines Mobiltelefohs 300 der Schaden für den Benutzer begrenzt ist, da selbst wenn die einzelnen Transaktionscodes F nicht gesperrt werden können, diese nur einen vordefinierten maximalen Wert haben. Bei der genannten Ausführungsform ist es besonders vorteilhaft, wenn die verwendete Hashfunktton bezüglich der verwendeten Verbindungsfunktion distributiv ist. In diesem Fall ist es möglich, mehrere Transaktionscodes zu verwenden, um einen geschuldeten Warenpreis Value zu begleichen. Hierbei steigt der nötige Kommunikationsaufwand jedoch nicht linear an. Betrachtet man beispielsweise das anhand der Fig. 7 beschriebene Ausführungsbeispiel, so wäre es zwar notwendig, eine Liste von Transaktions-Identifikationsnummern transID zu übertragen. Das übrige Datenvolumen würde jedoch nicht ansteigen, da das zweite Transaktionscodefragment F2 sowie der dritte Hashcode repräsentativ für eine Vielzahl von zweiten Transaktionscodefragmenten F2 und zweiten Hashcodes sein kann. Dieser repräsentative Wert wird beispielsweise durch ein bitweises
Addieren der einzelnen Transaktionscodefragmente generiert, wobei anschließend die Hashfunktion H() angewandt werden kann. Vorab wurden Ausführungsformen beschrieben, bei der der Transaktionscode F zur Generierung eines Codepaars in drei Transaktionscodefragmente F1-F3 aufgeteilt wird (z.B. in Fig. 4 gezeigt). Es ist jedoch auch möglich, einen Bezahlvorgang auf die erfindungsgemäße Art und Weise abzusichern, wobei lediglich zwei Transaktions¬ codefragmente, nämlich das erste und zweite Transaktionscodefragment Fl, F2 verwendet wird. Eine entsprechende Ausführungsform wird anhand der Figuren 9 und 10 verdeutlicht.
Beim Anmelden des Benutzers wird über die sichere Kommunikationsverbindung zumindest eine Hashfunktion H() und ein individueller Sicherheitscode X an das Mobiltelefon 300 übertragen. Optional kann zusätzlich eine Benutzeridentifikationsnummer ID übermittelt werden, um das Mobiltelefon 300 bei weiteren Aktionen oder Kommunikationsvorgängen eindeutig identifizieren zu können.
Beim Beladen des Mobiltelefons 300 mit einer Vielzahl von Codepaaren, meldet sich das Mobiltelefon 300 bei der Bezahlvorrichtung 100 an. Hierauf erzeugt die Transaktt- onscode-Generatoreinrichtung 120 einen Transaktionscode F. Dieser wird gemäß dem hier beschriebenen Ausführungsbeispiel in das erste Transaktionscodefragment Fl und das zweite Transaktionscodefragment F2 aufgeteilt. Die Transaktionscode- Generatoreinrichtung 120 verknüpft, wie bereits beschrieben, das erste Transaktions- codefragment Fl mit dem zweiten Transaktionscodefragment F2. Aus diesem ersten verknüpften Wert wird mittels der Hashfunktion H () der erste Hashwert H (Con (Fl, F2)) errechnet. Des weiteren verknüpft die Transaktionscode-Generatoreinrichtung 120 das dritte Transaktionscodefragment F2 mit dem Sicherheitscode X des Benutzers und bildet mitteis der Hashfunktion H () den zweiten Hashwert H (Con (F2, X)). Die Identäfikationscode-Generatoreinrichtung 150 kann nun dem Transaktionscode F sowie den generierten Daten eine individuelle Transaktionscode-Identifikationsnummer transID zuordnen. Für den erzeugten Transaktionscode F wird also von der Trans- aktionscode-Generatoreinrichtung 120 in der Autorisierungsdatenbank 112, genauer gesagt in der entsprechenden Tabelle 114 (vgl . Fig, 9), ein Datensatz mit den folgenden Werten gespeichert: Transaktionscode-Identifikationsnummer transID, erstes Transaktionscodefragment Fl, erster Hashwert H (Con (Fl, F2)}, zweiter Hashwert H (Con (F2, X)), Sicherheitscode X. Nur das zweite Transaktionscodefragment F2 muss zusammen mit der Transaktionscode-Identifikationsnummer transID an das Mobiltelefon 300 übermittelt und in dem Mobiltelefonspeicher 301 (vgl. Fig. 10) gespeichert werden. Dieser Vorgang wird zur Erzeugung der Vielzahl von Codepaaren mehrmals wiederholt.
Zur Freigabe einer Transaktion verknüpft das Mobiltelefon 300 das zweite Transaktionscodefragment F2 mit dem Sicherheitscode X aus dem Mobiiteiefonspeicher 301 und erzeugt unter Verwendung der Hashfunktion H () den dritten Hashwert H (Con (F2, X)), Um die Abbuchung zu veranlassen, wird beispielsweise die Transaktsons- code-Identifikationsnummer transID, das zweite Transaktionscodefragment F2, der dritte Hashwert H (Con (F2, X)), der Warenpreis Value und die Zahlungsstellen- Identifikationsnummer shopID an die zentrale Bezahlvorrichtung 100 übermittelt. Die zentrale Bezahlvorrichtung 100, genauer gesagt die Autorisierungseinrichtung 110, empfängt diese Daten und nutzt die in der Autorisierungsdatenbank 112 gespeicherten Informationen, um die Abbuchung zu verifizieren und dann zu autorisieren.
Im Zuge des Verifikationsprozesses wird anhand des empfangenen zweiten Trans- aktionscodefragments F2 und des in der Autorisierungsdatenbank 112 gespeicherten ersten Transaktionscodefragments Fl ein vierter Hashwert H (Con (Fl, F2)) errechnet. Die Autorisierungseinrichtung 110 vergleicht den übertragenen dritten Hashwert H (Con (F2, X)) mit dem in der Autorisierungsdatenbank 112 gespeicherten zweiten Hashwert H (Con (F2, X)) und den errechneten vierten Hashwert H (Con (Fl, F2)) mit dem in der Autorisierungsdatenbank 112 gespeicherten ersten Hashwert H (Con (Fl, F2)). Eine Abbuchung wird nur dann autorisiert, wenn die jeweiligen Werte übereinstimmen. Stimmen die Daten nicht überein, so wird der Bezahlvorgang verweigert.
Der beschriebene Absicherungsmechanismus lässt sich auf alle bereits dargestellten Bezahlvorgänge, insbesondere auf die aus den Fig. 5-7, anwenden. Bei der Verwendung dieses Mechanismus werden Speicherressourcen eingespart. Die ausgetauschten Nachrichten benötigen weniger Bandbreite. Die Zahlungsstelle kann auch durch einen Automaten zum Ausgeben oder Herstellen von Artikeln realisiert werden. Beispielsweise kann es sich um einen Kaffeeautomaten handeln, der die Ausgabe eines Kaffees und die Abwicklung eines zugehörigen Be- zahivorgangs implementiert. In diesem Fall kann die Autorisierung einer Transaktion oder bereits der Erhalt eines Teils eines gültigen Codepaars zur Betätigung eines Aktuators, z.B. eine Düse zur Abgabe des Kaffees, führen. Ebenso kann ein anderer Automat nach dem erfolgreichen Abschluss eines erfindungsgemäßen Bezahlvorgangs einen Fahrschein ausdrucken. Somit führt das beschriebene Verfahren zu einem unmittelbaren technischen Effekt.
An dieser Stelle sei darauf hingewiesen, daß alle oben beschriebenen Teile für sich allein gesehen und in Kombination, insbesondere die in den Zeichnungen dargestellten Details, als Erfindung beansprucht werden. So kann beispielsweise das erfin- dungsgemäß ausgestattete Mobiltelefon 300 unabhängig von dem weiteren Bezahlsystem beansprucht werden.
Bezugszeichenliste F Transaktionscode
Fl - F3 Transaktionscodefragment
ID Benutzeridentifikationsnummer
X Sicherheitscode
H () Hashfunktion
transID Transaktions-Identifikationsnummer
shopID Zahlungsstellen-Identifikationsnummer
Conf Bestätigungsnachricht
Value Warenpreis
maxVaiue maximaler Abbuchungsbetrag
100 zentrale Bezahlvorrichtung
110 Autorisierungseinrichtung
112 Autorisierungsdatenbank
114 Tabelle
120 Transaktionscode-Generatoreinrichtung
130 Verschlüsselungsfunktions-Übermittlungseinrichtung
140 Sicherheitscode-Generatoreinrichtung
150 Identifikationscode-Generatoreinrichtung Zahiungsstelie
Mobiltelefon
Mobiltelefonspeicher
Mobilteiefon-Barcodeleser
Anzeigeeinrichtung, 308' grafisches Symbol

Claims

Ansprüche
L Beza hl System, umfassend :
- eine Transaktionscode-Generatoreinrichtung (120) zur Erzeugung mindestens eines Transaktionscodes (F) zur Autorisierung mindestens eines
Bezahlvorgangs;
- eine Speichereinrichtung (112);
- eine Übertragungseinrichtung zur Übertragung von Daten an mindestens ein Endgerät (300);
dadurch gekennzeichnet, dass
die Transaktionscode-Generatoreinrichtung (120) dazu ausgebildet ist, a) den Transaktionscode (F) zu erzeugen;
b) den Transaktionscode (F) in mindestens ein erstes
Transaktionscodefragment (Fl) und ein zweites Transaktionscodefragment (F2) aufzuteilen;
c) mindestens das zweite Transaktionscodefragment (F2) an das mindestens eine Endgerät (300) zu übertragen;
e) das erste und zweite Transaktionscodefragment (Fl, F2) zu verknüpfen und hieraus einen ersten Hashwert zu bilden;
f) das zweite Transaktionscodefragment (F2) mit einem Sicherheitscode (X) des Endgeräts (300) und/oder des Benutzers des Endgeräts (300) zu verknüpfen und hieraus einen zweiten Hashwert zu bilden; und g) zumindest das erste Transaktionscodefragment (Fl), den ersten Hashwert, den zweiten Hashwert und den Sicherheitscode (X) in der Speichereinrichtung ( 112) zu speichern.
2. Bezahlsystem, umfassend:
- eine Transaktionscode-Generatoreinrichtung (120) zur Erzeugung mindestens eines Transaktionscodes (F) zur Autorisierung mindestens eines
Bezahlvorgangs;
- eine Speichereinrichtung (112);
- eine Übertragungseinrichtung zur Übertragung von Daten an mindestens ein Endgerät (300);
dadurch gekennzeichnet, dass
die Transaktionscode-Generatoreinrichtung ( 120) dazu ausgebildet ist, a) den Transaktionscode (F) zu erzeugen;
b) den Transaktionscode (F) in mindestens ein erstes
Transaktionscodefragment (Fl), ein zweites Transaktionscodefragment (F2) und ein drittes Transaktionscodefragment (F3) aufzuteilen;
c) das zweite und dritte Transaktionscodefragment (F2, F3) an das mindestens eine Endgerät (300) zu übertragen;
e) das erste und zweite Transaktionscodefragment (Fl, F2) zu verknüpfen und hieraus einen ersten Hashwert zu bilden;
f) das dritte Transaktionscodefragment (F3) mit einem Sicherheitscode (X) des Endgeräts (300) und/oder des Benutzers des Endgeräts (300) zu verknüpfen und hieraus einen zweiten Hashwert zu bilden; und
g) zumindest das erste Transaktionscodefragment (Fl), den ersten Hashwert, den zweiten Hashwert und den Sicherheitscode (X) in der Speichereinrichtung (112) zu speichern.
3. Bezahlsystem nach Anspruch 1 oder 2,
gekennzeichnet durch
eine Identifikationscode-Generatoreinrichtung (150) zur Erzeugung mindestens einer Transaktions-Identifikationsnummer (transID), wobei das Bezahlsystem dazu ausgebildet ist, die Transaktions-Identifäkationsnummer (transID) in Verbindung mit dem mindestens einen Transaktionscode (F) zugeordneten Daten zu speichern.
4. Bezahlsystem nach einem der vorhergehenden Ansprüche,
gekennzeichnet durch
eine Autorisierungseinrichtung (110) zur Autorisierung eines Bezahlvorgangs, wobei die Autorisierungseinrichtung (110) dazu ausgebildet ist,
von einem Endgerät (300) ein Tupel, umfassend mindestens ein zweites
Transaktionscodefragment (F2), einen dritten Hashwert und einen
Abbuchungsbetrag, zu empfangen und die empfangenen Daten mit Daten aus der Speichereinrichtung (112) zu vergleichen, um den Bezahlvorgang zu autorisieren.
5. Bezahlsystem nach einem der vorhergehenden Ansprüche,
insbesondere nach Anspruch 4,
dadurch gekennzeichnet, dass
die Autorisierungseinrichtung (110) dazu ausgebildet ist, einen tatsächlichen Abbuchungsbetrag, insbesondere von einer Zahlungsstelie (200), und einen maximalen Abbuchungsbetrag (maxValue), insbesondere von dem Endgerät (300), zu empfangen und zu überprüfen, ob der maximale Abbuchungsbetrag (maxValue) größer oder gleich dem tatsächlichen Abbuchungsbetrag ist.
6. Bezahlsystem nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass
die Transaktionscode-Generatoreinrichtung (150) dazu ausgebildet ist, dem mindestens einen Transaktionscode (F) einen maximalen Abbuchungsbetrag (maxValue) zuzuordnen und in Verbindung mit zumindest dem ersten
Transaktionscodefragment (Fl), dem ersten Hashwert, dem zweiten Hashwert und dem Sicherheitscode (X) in der Speichereinrichtung (112) zu speichern.
7. Bezahlsystem nach einem der vorhergehenden Ansprüche,
insbesondere nach Anspruch 6,
dadurch gekennzeichnet, dass
die zur Erzeugung der Hashwerte verwendete Hashfunktion (H()) distributiv bezüglich einer verwendeten Verknüpfungsfunktion, insbesondere bezüglich der zur Erzeugung des ersten und/oder zweiten Hashwerts verwendeten
Verknüpfungsfunktion, ist.
8. Bezahlsystem nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass das Endgerät (300) dazu ausgebildet ist, eine vordefänierte Anzahl graphischer Elemente (308, 308') anzuzeigen, wobei jedem der graphischen Elemente (308, 308') ein sich unterscheidender, insbesondere ganzzahliger Geldbetrag zugeordnet ist, wobei eine Eingabeeinrichtung zur Auswahl mindestens eines der graphischen Elemente (308, 308') ausgebildet ist, um einen maximalen Abbuchungsbetrag (maxValue) zu bestimmen.
9. ßezahlsystem nach einem der vorhergehenden Ansprüche, insbesondere nach Anspruch 8,
dadurch gekennzeichnet, dass
das Endgerät (300) dazu ausgebildet ist, dass der maximale Abbuchungsbetrag (maxValue) anhand einer Vielzahl von Auswahlen von graphischen Elementen (308, 308') bestimmt wird.
10. Bezahisystem nach einem der vorhergehenden Ansprüche,
insbesondere nach Anspruch 8 oder 9,
dadurch gekennzeichnet, dass
das Endgerät (300) dazu ausgebildet ist, einen vierten Hashwert anhand des insbesondere maximalen Abbuchungsbetrags (maxValue) zu berechnen und diesen zusammen mit dem insbesondere maximalen Abbuchungsbetrag
(maxValue) an eine/die Autorisierungseinrichtung (110) zu übermitteln.
11. Bezahlsystem nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass
das Endgerät (300) eine Eingabeeinrichtung zur Eingabe eines
Abbuchungsbetrags umfasst und dazu ausgebildet ist, ein Tupel, umfassend zumindest ein zweites Transaktionscodefragment (F2), einen dritten Hashwert und einen Abbuchungsbetrag, an eine/die Autorisierungseinrichtung (110) zu übermitteln, um den Bezahlvorgang zu veranlassen.
12. Bezahisystem nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass
das Endgerät (300) eine Leseeinrichtung, insbesondere ein Barcodelesegerät, zum Einlesen einer Zahlungsempfänger-Identifikationsnummer (shopID) und/oder eines Abbuchungsbetrags umfasst.
13. Bezahlsystem nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass
die Autorisierungseinrichtung (110) dazu ausgebildet ist,
von einer Zahlungsstelle (200) ein Tupel, umfassend mindestens ein zweites Transaktionscodefragment (F2), einen dritten Hashwert und einen
Abbuchungsbetrag, zu empfangen und die empfangenen Daten mit Daten aus der Speichereinrichtung (112) zu vergleichen, um den Bezahlvorgang zu autorisieren,
H. Verfahren zur Erzeugung mindestens eines Codepaars zur Autorisierung eines Abbuchungsvorgangs, umfassend die Schritte:
- Erzeugen eines Transaktionscodes (F);
- Aufteilen des Transaktionscodes (F) in mindestens ein erstes
Transaktionscodefragment (Fl) und ein zweites Transaktionscodefragment (F2);
- Erzeugen eines ersten Hashwerts durch ein Verknüpfen des ersten und zweiten Transaktionscodefragments (Fl, F2) und ein Anwenden einer
Hashfunktion (H()) hierauf;
- Erzeugen eines zweiten Hashwerts durch ein Verknüpfen des zweiten
Transaktionscodefragments (F2) und eines Sicherheitscodes (X) eines
Benutzers und/oder eines Endgeräts (300) und ein Anwenden der Hashfunktion (H()) hierauf;
- Speichern des ersten Transaktionscodefragments (Fl), des ersten Hashwerts, des zweiten Hashwerts und des Sicherheitscodes (X) in einer
Speichereinrichtung (112) einer Autorisierungseinrichtung (110);
- Speichern des zweiten Transaktionscodefragments (F2) und des
Sicherheitscodes (X) in einem Speicher eines Endgeräts (300).
15. Verfahren zur Erzeugung mindestens eines Codepaars zur Autorisierung eines Abbuchungsvorgangs, umfassend die Schritte:
- Erzeugen eines Transaktionscodes (F);
- Aufteilen des Transaktionscodes (F) in mindestens ein erstes
Transaktionscodefragment (Fl), ein zweites Transaktionscodefragment (F2) und ein drittes Transaktionscodefragment (F3);
- Erzeugen eines ersten Hashwerts durch ein Verknüpfen des ersten und zweiten Transaktionscodefragments (Fl, F2) und ein Anwenden einer Hashfunktion (H()) hierauf;
- Erzeugen eines zweiten Hashwerts durch ein Verknüpfen des dritten
Transaktionscodefragments (F3) und eines Sicherheitscodes (X) eines
Benutzers und/oder eines Endgeräts (300) und ein Anwenden der Hashfunktion (H()) hierauf;
- Speichern des ersten Transaktionscodefragments (Fl), des ersten Hashwerts, des zweiten Hashwerts und des Sicherheitscodes (X) in einer
Speichereinrichtung (112) einer Autorisierungseinrichtung (110);
- Speichern des zweiten Transaktionscodefragments (F2), des dritten
Transaktionscodefragments (F3) und des Sicherheitscodes (X) in einem
Speicher (301) eines Endgeräts (300).
16. Verfahren nach Anspruch 14 oder 15,
gekennzeichnet durch
- ein Erzeugen einer Transaktions-Identifikationsnummer (transID) und
- ein Speichern der Transaktions-Identifikationsnummer (transID) in
Verbindung mit dem ersten Transaktionscodefragment (Fl) und/oder dem ersten Hashwert und/oder dem zweiten Hashwert und/oder dem
Sicherheitscode (X) in der Speichereinrichtung (112) und
- ein Speichern der Transaktions-Identifikationsnummer (transID) in
Verbindung mit dem zweiten Transaktionscodefragment (F2) und/oder dem dritten Transaktionscodefragment (F3) und/oder dem Sicherheitscode (X) in dem Speicher (301) des Endgeräts (300).
17. Verfahren nach einem der Ansprüche 14 - 16,
dadurch gekennzeichnet, dass
der Sicherheitscode (X) und/oder die Hashfunktion (H()) zum Speichern in dem Speicher (301) des Endgeräts (300), vorzugsweise während eines
Anmeldeverfahrens, über eine sichere Kommunikationsverbindung,
beispielsweise über SSL/TLS, von der Autorisierungseinrichtung (110) übertragen werden.
18. Verfahren zur Durchführung eines Bezahlvorgangs, umfassend die Schritte:
- Erzeugung mindestens eines Codepaars zur Autorisierung eines
Abbuchungsvorgangs, insbesondere gemäß dem Verfahren nach einem der Ansprüche 14 - 17;
- Durchführung eines Abbuchungsvorgangs, umfassend die Schritte: a. Übermitteln eines Abbuchungsbetrags von dem Endgerät und/oder einer Zahlungsstelle (200) an die Autorisierungseinrichtung (110); b. Übermitteln einer Zahlungsempfänger-Identifikationsnummer (shopID) von dem Endgerät (300) und/oder der Zahlungsstelle (200) an die Autorisierungseinrichtung (110);
c. Erzeugen eines dritten Hashwerts durch ein Verknüpfen des zweiten oder dritten Transaktionscodefragments (F3) des Codepaars und des Sicherheitscodes (X) des Benutzers oder des Endgeräts (300) und ein Anwenden der Hashfunktion (H()) hierauf, wobei dieser Schritt von dem Endgerät (300) durchgeführt wird;
d. Übermitteln des dritten Hashwerts und eines im Speicher des Endgeräts (300) gespeicherten zweiten Transaktionscodefragments (F2) des Codepaars;
e. Überprüfen, ob ein gültiges Codepaar verwendet wurde, indem die
Autorisierungseinrichtung den dritten Hashwert von dem Endgerät (300) mit dem zweiten Hashwert aus der Speichereinrichtung (112) vergleicht, einen vierten Hashwert anhand des vom Endgerät (300) übermittelten zweiten Transaktionscodefragments (F2) und des ersten
Transaktionscodefragments (Fl) aus der Speichereinrichtung (112) berechnet und den ersten Hashwert aus der Speichereinrichtung (112) mit dem vierten Hashwert vergleicht.
19. Verfahren nach Anspruch 18,
dadurch gekennzeichnet, dass
die Durchführung des Abbuchungsvorgangs ein Eingeben eines maximalen Abbuchungsbetrags (maxValue) am Endgerät (300) und ein Übermittein des maximalen Abbuchungsbetrags (maxValue) an die Autorisierungseinrichtung (110) umfasst, wobei das Eingeben des maximalen Abbuchungsbetrags
(maxValue) umfasst:
- ein Anzeigen einer Vielzahl von graphischen Elementen (308, 308') auf einer Anzeigeeinrichtung (306) des Endgeräts (300), wobei jedem der graphischen Elemente (308, 308') ein sich unterscheidender, insbesondere ganzzahliger Geldbetrag zugeordnet ist,
- ein Auswählen mindestens eines der graphischen Elemente (308, 308'), um einen maximalen Abbuchungsbetrag (maxValue) zu bestimmen.
20. Verfahren nach Anspruch 18 oder 19,
dadurch gekennzeichnet, dass
das Endgerät mittels einer Eingabeeinrichtung, insbesondere mittels eines Barcodelesegeräts, die Zahlungsempfänger-Identifikationsnummer (shopID) der Zahlungsstelle (200) erfasst und diese an die Autorisierungseinrichtung (110) übermittelt.
PCT/EP2010/056571 2010-05-12 2010-05-12 Bezahlsystem, verfahrung zur erzeugung mindestens eines codepaares zur autorisierung eines abbuchungsvorgangs und verfahren zur durchführung eines bezahlvorgangs WO2011141062A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2010/056571 WO2011141062A1 (de) 2010-05-12 2010-05-12 Bezahlsystem, verfahrung zur erzeugung mindestens eines codepaares zur autorisierung eines abbuchungsvorgangs und verfahren zur durchführung eines bezahlvorgangs

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2010/056571 WO2011141062A1 (de) 2010-05-12 2010-05-12 Bezahlsystem, verfahrung zur erzeugung mindestens eines codepaares zur autorisierung eines abbuchungsvorgangs und verfahren zur durchführung eines bezahlvorgangs

Publications (1)

Publication Number Publication Date
WO2011141062A1 true WO2011141062A1 (de) 2011-11-17

Family

ID=43012469

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2010/056571 WO2011141062A1 (de) 2010-05-12 2010-05-12 Bezahlsystem, verfahrung zur erzeugung mindestens eines codepaares zur autorisierung eines abbuchungsvorgangs und verfahren zur durchführung eines bezahlvorgangs

Country Status (1)

Country Link
WO (1) WO2011141062A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2843605A1 (de) * 2013-08-30 2015-03-04 Gemalto SA Verfahren zur Authentifizierung von Transaktionen
DE102014014109A1 (de) * 2014-09-24 2016-03-24 Giesecke & Devrient Gmbh Transaktionsverfahren

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1992007436A1 (en) * 1990-10-19 1992-04-30 Security Dynamics Technologies, Inc. Method and apparatus for personal identification
US5371797A (en) * 1993-01-19 1994-12-06 Bellsouth Corporation Secure electronic funds transfer from telephone or unsecured terminal
WO1996029667A1 (en) * 1995-03-20 1996-09-26 Sandberg Diment Erik Providing verification information for a transaction
GB2332833A (en) * 1997-12-24 1999-06-30 Interactive Magazines Limited Secure credit card transactions over the internet
WO2000018078A1 (en) * 1998-09-17 2000-03-30 Sopuch David J Secure message exchange method using intermediaries
WO2006092383A2 (en) * 2005-03-02 2006-09-08 International Business Machines Corporation Secure cell phone for atm transactions
WO2008020257A1 (en) * 2006-08-16 2008-02-21 Debitcode Kft. Method and system for fulfilling electronic financial transactions

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1992007436A1 (en) * 1990-10-19 1992-04-30 Security Dynamics Technologies, Inc. Method and apparatus for personal identification
US5371797A (en) * 1993-01-19 1994-12-06 Bellsouth Corporation Secure electronic funds transfer from telephone or unsecured terminal
WO1996029667A1 (en) * 1995-03-20 1996-09-26 Sandberg Diment Erik Providing verification information for a transaction
GB2332833A (en) * 1997-12-24 1999-06-30 Interactive Magazines Limited Secure credit card transactions over the internet
WO2000018078A1 (en) * 1998-09-17 2000-03-30 Sopuch David J Secure message exchange method using intermediaries
WO2006092383A2 (en) * 2005-03-02 2006-09-08 International Business Machines Corporation Secure cell phone for atm transactions
WO2008020257A1 (en) * 2006-08-16 2008-02-21 Debitcode Kft. Method and system for fulfilling electronic financial transactions

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2843605A1 (de) * 2013-08-30 2015-03-04 Gemalto SA Verfahren zur Authentifizierung von Transaktionen
WO2015028664A1 (en) * 2013-08-30 2015-03-05 Gemalto Sa Method for authenticating transactions
US10579987B2 (en) 2013-08-30 2020-03-03 Thales Dis France Sa Method for authenticating transactions
DE102014014109A1 (de) * 2014-09-24 2016-03-24 Giesecke & Devrient Gmbh Transaktionsverfahren
US10839380B2 (en) 2014-09-24 2020-11-17 Giesecke+Devrient Mobile Security Gmbh Transaction process

Similar Documents

Publication Publication Date Title
EP0605070B1 (de) Verfahren zum Transferieren von Buchgeldbeträgen auf und von Chipkarten
DE69624342T2 (de) System und verfahren für elektronische geldüberweisungen unter verwendung eines automatischen bankschalter-kassenautomates zur ausgabe des überwiesenen geldes
EP1178444A1 (de) Elektronischer Zahlungsverkehr mit SMS
WO2011147566A2 (de) Verfahren zum erzeugen eines transaktionssignals
AT512070A1 (de) Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen
AT511626B1 (de) Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen
DE69828722T2 (de) Verarbeitung von Transaktionsdaten
DE10003875A1 (de) Zahlungsausführungsvorrichtung zur bargeldlosen Zahlung und Verfahren zur Ausführung einer bargeldlosen Zahlung
DE19634418A1 (de) Verfahren zur Sicherung der Datenübertragung im elektronischen Zahlungsverkehr
WO2011141062A1 (de) Bezahlsystem, verfahrung zur erzeugung mindestens eines codepaares zur autorisierung eines abbuchungsvorgangs und verfahren zur durchführung eines bezahlvorgangs
EP0806747B1 (de) Verfahren und Anlage zum Transferieren von Geldbeträgen zwischen überschreibbaren Speichern einer Chipkarte
EP1309951B1 (de) Verfahren und anordnung zur übertragung eines elektronischen geldbetrages aus einem guthabenspeicher
DE19860203A1 (de) Verfahren für die sichere Handhabung von Geld- oder Werteeinheiten mit vorausbezahlten Datenträgern
DE60122912T2 (de) Verfahren zum liefern von identifikationsdaten einer bezahlkarte an einen anwender
DE10009710A1 (de) Verfahren zum Austausch von Zahlungsinformationen im internetfähigen bargeldlosen Zahlungsverkehr
WO2002007109A2 (de) Verfahren zur bargeldlosen zahlung und autorisierung
EP2907093B1 (de) Laden und ausgeben eines elektronischen geldbetrags
DE102006017911B4 (de) Elektronisches Bezahlsystem und Verfahren zum Ausführen eines Bezahlvorgangs
DE202019106383U1 (de) Elektronische Zahlungsvorrichtung
WO1998011518A2 (de) System und verfahren für den bargeldlosen zahlungsverkehr
EP1277185B1 (de) Verfahren zur verringerung der risiken von e-commerce-geschäften
EP1371038B1 (de) Verfahren und vorrichtung zum durchführen mindestens eines gegen zahlung eines entgelts abzuwickelnden geschäfts
EP1388138B1 (de) Verfahren und anordnung zum bezahlen von über ein datennetz abrufbaren datenangeboten
DE10229619A1 (de) Verfahren zur Durchführung eines Zahlungsvorganges
DE102010034403A1 (de) Bezahlsystem

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: 10720406

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10720406

Country of ref document: EP

Kind code of ref document: A1