DE102011122767A1 - Method of payment with at least one electronic means of payment - Google Patents

Abstract

The invention relates to a method for payment with at least one electronic means of payment (5, 6, 7, 8, 9, 10), wherein on a server system at least one means of payment verification is stored with a payment value and a verification key, wherein each valid means of payment (5, 6, 7, 8, 9, 10) is associated with at least one payment verification record, the currency key (5, 6, 7, 8, 9, 10) being stored in a storage location, the storage location being available to a payer, with the following Steps: Connection establishment between a data processing system of a payee and the server system, connection establishment between a data processing system of the debtor and the server system, assignment of the payee and the payer, transmission of the cash key (5, 6, 7, 8, 9, 10) the server system, - Ü verifying the validity of the funds key (5, 6, 7, 8, 9, 10), - changing the verification key and creating a new, assigned cash key (5, 6, 7, 8, 9, 10), in case that the transmitted and validated currency key (5, 6, 7, 8, 9, 10) is valid, or - deleting the verification key and creating a new verification key and a new, assigned cash key (5, 6, 7, 8, 9, 10), in case the transmitted and verified payment key (5, 6, 7, 8, 9, 10) is valid, - the new tender key (5, 6, 7, 8, 9, 10) being stored at a further storage location available to the payee is or is. On the one hand the method is suitable for the digital space, on the other hand a complete traceability of the payment path is excluded and at the same time the procedure is easy for the user to handle.

Description

The invention relates to a method for payment with at least one electronic means of payment.

Various methods are known in the art:
With the advent of electronic data processing, more and more systems have become established that replace banknotes and coins with non-cash alternatives. Thus, cards were introduced, which are equipped for example with magnetic stripes, memory chips or printed coding. In principle, two design variants can be distinguished.

On the so-called money cards a monetary value is stored. The payment transaction deducts from this value. Well-known representatives of this kind are the so-called electronic purses as well as the telephone cards. Registration of the cardholder is not necessary. Who holds the card in his hands, can dispose of the credit.

For credit cards, however, the identity of the holder is deposited on the card. The disposals with the card are settled with him. The knowledge of the personal data is essential for this. There are also credit cards that are kept on credit only for credit reasons, and so-called debit cards that do not grant payment terms. This does not change the documentation of the identity of the cardholder.

The tendency towards non-cash payment is accelerated by the rapid expansion of the Internet. The current boom of Internet-enabled, mobile phone devices with additional computer functionality, so-called smartphones, is accelerating this trend significantly. The Internet is thus a constant companion. Conventional commerce is moving more and more into the digital space and is calling for payment methods that are at home there and that meet both the requirements of the medium and the user-friendliness.

All current payment methods commonly used on the Internet have in common that a current account is maintained for the paying subscriber - of whatever kind. This principle applies to both the credit card payment as well as other forms of payment on the Web.

This increasingly cash is replaced by book money.

The system-inherent characteristics of bank account maintenance include the permanent recording of the transaction data as well as the identification of the parties involved in a payment transaction. Extensive account movements not only allow a web user to generate his or her digital movement profile, but also determine their consumption habits and thus spy on their main interests and personal preferences. The use of these sensitive personal data deeply penetrates the privacy of those affected. In addition, there is a risk that the information obtained will be used against their interests. Therefore, privacy advocates urgently to leave as few traces as possible on the Internet. This would include above all the payment with an anonymous electronic means of payment instead of by transfer.

By Directive 2000/46 / EC, the European Union had already in 2000 created the legal basis for the legal implementation at national level of the introduction of electronic money (e-money) as an electronic substitute for coins and banknotes. The emission rights were delegated to the credit institutions. This electronic means of payment or money is also referred to as network money.

Countless images of banknotes and coins circulate in the form of images in the usual formats such as: Jpeg, png, gif, tif, and ico, and these graphics can easily be duplicated as often as you like. Therefore, their use is limited to illustrative purposes; a use as electronic means of payment is understandably eliminated in the prior art.

In the prior art, the so-called eCash method is known. A customer transfers funds from his bank account to his eCash account. It creates encrypted files with certain value stores that are stored on your computer. The administration of these electronic coins takes over a special utility, the electronic purse (cyberwallet or e-wallet). When shopping on the Internet then the seller these files from the computer of the buyer are transmitted. Upon payment, the digital means of payment is immediately checked for validity by the seller or the bank. The seller can now arrange the shipment of the ordered goods or the execution of the corresponding service.

First, a customer must open an eCash account with an eCash-licensed bank and install eCash software on their machine. The eCash account connects to an actual bank account. The loading or unloading of an eCash account can only be done from this bank account. If the customer wants to transfer an amount into eCash, the electronic purse generates files in the amount of the desired amount. Each file is assigned a specific value that does not change anymore. She also receives a serial number from the purse. These files are therefore also referred to as electronic coins (cybercoins). The bank checks the balance. If it is sufficient, each file is provided with a key of the bank, each key corresponding to a certain value; the corresponding amount is deducted from the real bank account.

Subsequently, the files are sent back to the customer, that is to the wallet. This process corresponds approximately to the charging of a chip card at a loading terminal. The files are now coded both by the wallet with the customer key, as well as by the bank with their key. The purse now removes the key attached to it. This process is called blinding. By blinding the absolute anonymity should be maintained. Each file consists of the serial number and the information about the value and is encrypted with the key of the bank. When issuing eCash, the customer sends files whose value matches the amount requested by the seller. Payment on the Internet using the eCash software is possible in real time. At the click of a mouse, the seller's software generates a payment request, which he sends to the customer's purse. This lets the customer confirm the transaction and sends files of the desired amount to the seller. He in turn forwards the electronic coins to the bank. There, the bank key is removed, the value of the coin is credited to the eCash account of the seller. The now decrypted serial number is saved.

The naming of this invention gives the impression that it is cash - although the fixed connection of the system with a real bank account converts so-called bank deposits into eCash. The merchant also needs an eCash account for his credit entry.

Actually, eCash is more like a bank guarantee than a cash system. Also, this system is compelling booking-based, thus not anonymous, also complicated in technology and application. Above all, the user is forced to install special software on his computer. Thus, the eCash process could not prevail on the market.

Other approaches follow similar concepts, where the storage of money is done with elaborate encryption methods at the user to ensure that the extensive security requirements are met:
Furthermore, the prior art discloses an electronic currency called Bitcoin. It is generated remotely based on a computer network. Bitcoin combines features of cash with those of international electronic transfers. The network is formed from the computers of all participants who run a free open source software. The possession of monetary units can be proven by the possession of cryptographic keys. Each transaction of monetary units between participants in the network is recorded in a public database supported by the entire network and provided with strong digital signatures. This ensures that funds are spent only once.

The concept raises legal, economic and technical issues due to its novel combination of hitherto incompatible features, which are being debated.

Bitcoin devices are largely tamper-proof by using strong encryption techniques. Each amount of money can be spent only once, because any transfer of money is irrevocably recorded in the network. The system combines a relatively quick confirmation of transactions within ten to sixty minutes at a low cost per transaction of around $ .007. Ownership of funds is evidenced by the contents of an electronic purse containing cryptographic keys. The signature with these keys is a prerequisite for the inclusion of a transaction in the network-wide directory. The keys as such need not be used in this procedure be revealed. The purse, however, must be protected against loss by spying and malicious software.

Payments are made to pseudonymous addresses, which the software can arbitrarily recreate for each recipient. An identification of trading partners should be prevented. The system does not guarantee complete anonymity because the chain of all transactions is recorded publicly in the transaction history and a link to further information is possible in principle.

Beyond the support of payment processes, Bitcoin has the character of an electronic currency. The price of the unit results solely from the supply of available bitcoins and their demand in trading. Monetary units can be bought and sold in exchange for currencies such as US dollars or euros. The currency unit's price is sometimes volatile and has risen sharply since the system started.

The market capitalization of all units is slightly less than 100 million US dollars (as of June 22, 2011). The amount of monetary units can not be influenced centrally and has a fixed upper limit built into the software. New currency units may be earned by participants in the peer-to-peer network in the use of processing power for the confirmation and signature of transactions.

The concept of Bitcoin was proposed in 2008 in a white paper by Satoshi Nakamoto. However, the concept of anonymous digital money, based on asymmetric cryptosystems such as RSA, has been known for decades. Bitcoin is based on the advanced idea of a cryptographic currency, described by Wei Dai as b-money in 1998 and Nick bitco as bit gold. Nakamoto, about whom little is known, withdrew from development at the end of 2010. The project will be continued by some developers led by Gavin Andresen. The software project is anchored in the open source community. Several of the developers, such as Jeff Garzik, are also involved in contributing to the Linux kernel.

Bitcoin conceptually combines certain features of transfers with the limited money feature, as is the case with commodity money. Bitcoin is mathematically limited in quantity, unlike the commodity money (Kurantgeld), which is limited by its material content (precious metal content) (according to the amount of mineable ore). Kurantgeld is therefore measured by the pure metal value, but is only physically transportable. Bitcoin thus represents a new form of money. The properties of Bitcoin are derived from the mathematical process used.

Counterfeiting of units or transactions is inefficient and therefore practically impossible due to the asymmetric cryptographic techniques used because of the time and technical effort required.

Payments can be made quickly and inexpensively directly between the parties without the involvement of financial institutions, thereby circumventing the comparatively high fees of incumbent service providers. The confirmation of a transaction currently costs (depending on the implementation of the client software) 0.0005 BTC. If voluntarily raised, it speeds up the confirmation process by giving it a higher priority in the calculation by other members of the network. The fee is credited to the network node that creates the confirmation signature. In particular, the method should prevent the network from being overloaded by very many very small transactions. In the long term, these transaction fees are intended as a reward for maintaining the network by providing computing power.

The system is completely decentralized due to the peer-to-peer structure, similar to systems such as BitTorrent. Influence on the money supply would require all participants to use modified software, as otherwise a non-universally recognized offshoot of the protocol and payment unit would arise.

One problem with introducing Bitcoin as currency is the initial distribution of money. Modern state and private currencies are, in contrast to Bitcoin, covered by a promise of payment of the issuing body. Since Bitcoin as a new means of payment initially has no confidence and the exchange is guaranteed by no body, but it had originally no quantifiable value. A usability was due to the lack of offers of goods against exchange of currency initially not available. For this reason, it was initially irrational for market participants to buy the new currency units.

In the case of Bitcoin, new units are distributed according to a principle that rewards the support of the network by providing computing power. Due to the increasing value of the credit, this represents a high reward in the case of an extension of the use and thus a substantial incentive.

Basically, Bitcoin builds on the already possible anonymity on the Internet. So that transactions can not be assigned, neither IP addresses nor Bitcoin addresses may be assigned to a person. Since the payee wants to receive customers in some way, he must at least partially give up his anonymity. As described in more detail below, all transactions between two addresses are publicly logged and permanently stored throughout the network. Subsequent recipients of partial amounts may report the last owner to authorities who can then track the chain of transactions. Alternatively, customer devices could also be confiscated or generally monitored.

To use Bitcoin, a user must first download a software application from the Sourceforge platform and install it on their computer or smartphone, the so-called Bitcoin client. At startup, the program connects to the Internet and downloads all previous transactions.

Clicking on a button then generates Bitcoin recipient addresses. The counterpart private key to this address is automatically stored in a file named "wallet.dat". The recipient address can be z. B. by e-mail, but also use to send themselves newly acquired Bitcoins.

The participants use a program (client) to dial into the unstructured peer-to-peer network. The program automatically informs about all previous transfers and generates addresses for payment receipt.

Money transfers take place as transactions between such addresses. These addresses represent the public keys of an asymmetric key pair. The payee announces the public part to the sender of the payment. The private key is known only to the subscriber who generated the key pair. This ensures that only the owner of the private key can authorize a transaction. At the same time, the loss of the private key also means the loss of the associated bitcoins.

To prevent a participant from spending the same bitcoins multiple times (double-spending), transactions across the entire peer-to-peer network are propagated using the flooding algorithm.

The transactions are first digitally signed within the network, which is not done with a private key, but includes the solution of a new cryptographic task. The task involves the reversal of a one-way function: It can only be solved with great computational effort, but its correct solution can be checked with much less effort. When a client solves such a task, it must cryptographically join the solution to a block along with transactions from other clients. After that, he receives from the other network nodes the recognition of a reward in the form of some newly generated Bitcoins.

The amount of these reward units is limited. Bitcoin uses the elliptic curve cryptosystem EGDSA in the 256-bit configuration secp256k1 to sign data.

The block now published in the system defines the transactions contained in it bindingly. In the case of the signature, it is additionally linked with other blocks, that is, the system works in a similar way to a large group of notaries who repeatedly check each other's signatures under a series of documents and confirm them with further signatures.

Since the block chain and the confirmed transactions are publicly available, Bitcoin is not completely anonymous. If a user announces his address, then one can track all transactions of this address. To limit traceability, Bitcoin supports multi-address handling in an electronic purse, the wallet.

The already mentioned solution of compute-intensive cryptographic tasks is called mining. Through this, the clients participate in the generation of new bitcoins and thus carry out the money creation decentralized.

Tasks are designed so that, on average, every 10 minutes, a random client involved in mining finds a solution first. The probability of a participant finding the right solution is proportional to the computing power used. Every two weeks, the clients adjust the level of difficulty of the tasks, so that the system continues to find an answer every 10 minutes to a task, despite increased or decreased total computing power.

Solutions that do not meet the current level of difficulty will not be accepted by other clients. A client solving a task is currently generating 50 BTC. The number of bitcoins generated is halved every four years, so that there can be a maximum of about 21 million bitcoins, of which about 6.4 million were generated by the beginning of June 2011.

As an incentive for the producer of a block to confirm a foreign transaction, the remittance sender may additionally pay him a transaction fee. The transaction fee should also be an incentive to solve cryptographic tasks and thus generate blocks when the planned amount of units is reached and no new bitcoins can be generated. Furthermore, the transaction fee is to regulate the number of transactions according to the capacity.

Although Bitcoin is often referred to as electronic cash, it can not be considered money because it is not issued by a government-authorized, read-only agency. In addition, the use of Bitcoin requires software that must be installed on the user's computer. In addition, Bitcoin does not guarantee the desired anonymity, as each individual payment transaction is openly visible and traceable to all participants in the Bitcoin network.

Another project that enables cash-like payments without the customer's internet connection is called Bitbills. These consist of plastic cards in the ISO 7810 Format containing a Bitcoin address key pair with amounts between 1 and 20 BTG. On the back of the public key is printed. The nominal amount of the cards will be charged to the card through a payment to this address. The amount actually on the card can be displayed at any time on the website blockexplorer.com, which evaluates the public block chain. The secret key is hidden under a hologram, which is pasted on the front. The removal of the hologram releases the key and destroys the card. The card is valid only as long as the hologram is intact. If you want to spend the amount on the card, you have to remove the hologram and import the secret key into a Bitcoin Wallet. The cost of the card itself was in early July. 2011 between 0.30 and 0.70 BTC (between 4.50 and 10.5 USD).

Bitbills are a combination of prepaid card and Bitcoin with the disadvantages already mentioned above.

From the generic DE 10 2009 034 436 A1 is a method of payment with monetary amounts in the form of electronic records known. The debtor has a first record, whereby the debtor has received this first record from a central entity, such as a financial institution. The first record contains a currency key and a record value, the record value corresponding to a cash value credited to a current account. The record also contains identification data of the debtor or owner and a signature, the signature of the central entity, namely the financial institution is generated. The payer can send this first record to a payee. The payee uses the identification data to verify that the first record is from the payee. Thereafter, the payee must create a second record with the record code, the second record containing the payee's identification data. The payee must now transfer the second record to the financial institution. The financial institution checks on the one hand the identification data of the second data record and on the other hand, whether the means of payment is valid. If the record code is valid, then the financial institution creates a signature on the second record. The signed second record is transferred from the financial institution to the payee. This procedure replaces a record with a new record, invalidating the old record. However, this procedure also does not relate to electronic cash, but to a bank-based payment method. This process requires a large number of transactions and is cumbersome.

Unlike account-based systems, electronic cash systems are IT objects, called eToken, that carry all the necessary information, including its value. Particular attention is paid to the cryptographic protocols and algorithms that are used to secure the payment system itself as well as to secure individual transactions within the scope of an ePayment system design. Their safety and robustness determine the practical benefits of such systems. Many existing methods for the realization of conditional anonymity are based on the principle of blind ciphers (Schnorr signature, blind ElGamal, Blinding by David Chaum) in combination with the so-called secret splitting to the previously granted anonymity in a multiple use (multiple-spending) of eToken to be able to cancel. But now there are significant disadvantages associated with such as the no longer existing multiple use ability of the unchanged eTokens used. In order to obtain this essential taxonomy factor, it is proposed in the literature to employ methods which use statistical methods to detect systematic counterfeit currency transitions.

As a rule, payment transactions with physical cash take place in the personal presence of the participants, whereby the individual steps of the process are carried out step by step in rapid succession. The real-time moment is of fundamental importance here. If disruptions occur during the payment process, the party that feels disadvantaged has the opportunity to complain and, if necessary, intervene. This repertoire gives the participants a sense of the ability to act and thus of security. Electronic cash payment methods in the prior art do not take this situation into consideration.

So is from the published in 2000 DE 1 985 995 9 A a procedure for a transfer of money or assets and money or assets for which the procedure does not require the collection of personal data. The debtor receives from a bank, for example, by mail, a card, on the card, an identification code or key currency is printed. The identification code is hidden by a cover layer and can be exposed by scrubbing the cover layer. However, the debtor must first contact the payee electronically. The debtor sends the identification code by electronic means, for example by e-mail as a payment offer. The information transferred contains all the data that the recipient needs in order to bring the means of payment into its final power of disposition in the next step via an exchange, for example the bank. The payee must now check the coverage of the payment offer or the validity of the identification code by entering the identification code at a bank.

Sending the security code from the payer to the payee is a security breach that renders the process useless in practice. Although the connection to the bank / exchange can be designed compellingly tap-proof. However, the debtor and the payee can not be forced to use tap-proof procedures for data transmission among themselves. However, if this data transmission is overheard by an unauthorized person, he may, if he timely arrives at the claimant at the exchange, acquire the means of payment unlawfully.

In addition, the payment transaction is not limited to a transaction between the payer and the payee. After receipt of the means of payment, the payee first has to go to an agency that verifies the validity of the means of payment. The intervention of this third party interrupts the interaction between the payer and the payee for an unpredictable period of time. A liquid flow of the payment process in real time, as it is known from the payment with physical cash, is not achieved in this way.

With the spread of mobile telephony, methods have also been described which enable payment by mobile phone.

http://www.mgovernment.org/resurces/euromgov2005/PDF/29_S049HK-S04.pdf discloses a system that includes a core protocol layer in conjunction with a special hardware functionality that is implementable in an application programmable integrated circuit. By combining them with signed electronic coins, various certificate services and the digital wallet, an electronic cash system can be designed. However, it requires its own transmission protocol, which would first have to be standardized and introduced, and special hardware components to be distributed.

Currently there is an increasing number of systems that provide access to the Internet and the services based on it. Under different operating systems new web browsers are developed in addition to the classics, for which regularly new versions are published. So far, it has only been possible to rigorously enforce minimum standards.

Ultimately, the success or failure of problem solving for the Internet and its services is generally decided by its user-friendliness. Cumbersome or difficult-to-understand offers are not accepted by the Internet user, while simply conceived and comprehensively presented applications are gladly taken up and even recommended to other users. Many users reject new systems on the grounds that they are troublesome with the installation of necessary software or have new, undesirable security risks.

Money embodies purchasing power, which at first glance is expressed in an incorruptible numerical value. However, this deliberately rational characteristic is usually in striking contrast to the emotional relationship of its owner. Values such as security, trust and reliability play a dominant role. The human need for control requires transparency about the whereabouts and stock of available money. In addition, uncertainty and fear of loss inevitably create discomfort.

Electronic money, which depends on the installation of individual software elements, would inevitably be unrecognizable due to the widespread system diversity of a non-negligible part of the existing systems as such. This inevitably disrupts the user. If he has to worry about his money, his confidence in the means of payment will be shaken.

Therefore, the known in the prior art methods are not yet optimally formed. In the prior art, there is no known secure method and associated electronic means of payment which are suitable for the Internet and allow a similarly uncomplicated and anonymous payment as with cash, without introducing specific hardware components or distributing software programs. The task is so difficult, above all, because the central weakness with electronic cash is the risk of improper duplication.

The invention is therefore based on the object, a method for payment with at least one valid electronic payment key in such a way and to design that the method is on the one hand for the digital space, but on the other hand, a complete traceability of the payment excludes and at the same time easy for the user to handle.

• – Verbindungsaufbau zwischen einer Datenverarbeitungsanlage eines Zahlungsempfängers und dem Serversystem,
• – Verbindungsaufbau zwischen einer Datenverarbeitungsanlage des Zahlungspflichtigen und dem Serversystem,
• – Zuordnen des Zahlungsempfängers und des Zahlungspflichtigen,
• – Übermitteln des Zahlungsmittelschlüssels an das Serversystem,
• – Überprüfen der Gültigkeit des Zahlungsmittelschlüssels,
• – Ändern des Verifizierungsschlüssels sowie Erstellen eines neuen, zugeordneten Zahlungsmittelschlüssels, im Fall dass der übermittelte und überprüfte Zahlungsmittelschlüssel gültig ist, oder
• – Löschen des Verifizierungsschlüssels sowie Erstellen eines neuen Verifizierungsschlüssels und eines neuen, zugeordneten Zahlungsmittelschlüssels, im Fall dass der übermittelte und überprüfte Zahlungsmittelschlüssel gültig ist,
• – wobei der neue Zahlungsmittelschlüssel an einem dem Zahlungsempfänger zur Verfügung stehenden, weiteren Speicherort gespeichert wird oder ist.

This object is achieved according to the invention by a method for payment with at least one electronic means of payment, wherein on a server system at least one payment verification record is stored with a payment value and a verification key, wherein each valid means of payment key is associated with at least one payment verification record, wherein the means of payment key stored in a memory location where the location is available to a debtor, with the following steps:

• Establishing a connection between a payment processor's data processing system and the server system,
• - establishing a connection between a data processing system of the debtor and the server system,
• - assign the payee and the payer,
• Transferring the cash key to the server system,
• - checking the validity of the tender key,
• - Changing the verification key and creating a new, assigned cash key, in case the submitted and verified cash key is valid, or
• - deleting the verification key and creating a new verification key and a new, assigned payment key, in case the submitted and verified payment key is valid,
• - wherein the new means of payment is stored at a the payee available, another storage location or is.

The payment verification data record can each have one or more directories and / or files and / or data records and / or links. The payment verification set server system is under the control of the issuer or issuers. Issuer can be a financial institution. The payment verification record becomes centralized on one or more servers managed. The payment verification record has at least one unique verification key. The verification key is preferably determined according to the random number principle.

The currency key forms a reference to the payment verification record. This reference can be unique, meaning that each payment key has exactly one payment verification record associated with it. Alternatively, however, a payment key may be associated with a plurality of payment verification records. The currency key serves as authorization means.

By reference are meant all possibilities of reference. A reference may consist in the mere identity of a unique string, but also in a reference, a link, a link, or any other form of referencing.

The currency key may in particular comprise or consist of one or more files, data records, links and / or directories. The currency key is subject to the power of the owner, d. H. At the beginning of the proceedings, the cash key is subject to the power of disposal of the debtor and, at the end of the procedure, to the power of disposal of the payee.

The means of payment is initially stored in a storage location of the debtor and assigned in particular to a data processing system of the debtor or the payee. These data processing systems can be designed as personal computers, laptops, smartphones, mobile phones or the like. The currency key is stored at the storage location on a storage means, such as a hard disk, a USB stick, a CD of a DVD or the like., The data processing system. These data processing systems can also be referred to as a client.

The means of payment key corresponds in particular identically to the associated verification key of the server-side means of payment verification record or is preferably assigned to the verification key via a corresponding function, provided that the means of payment means is valid. By checking the assignability of the cash key to the verification key (s), it is checked that the cash key is valid or invalid. For example, if a payment verification record exists with a verification key associated with the tender key, then the tender key is valid. If there is no associated payment verification record, then the currency key is invalid.

The method has a function provided by a server system for depicting the payment process. This function and the server system are in particular under the control of the issuer.

The payee and the payer connect to the server system. The connection to the server system can be established in particular via an Internet connection. The connection to the server system is preferably via an encrypted connection.

After establishing the connection, the payer and the payee are assigned. In particular, the server system makes the corresponding payment processes available to a large number of persons.

The payee starts a new payment process on the server system. The payment process is presented to the debtor and the payee quasi-synchronously. This representation takes place on the one hand via the connection between the data processing system of the payee and the server system and on the other hand via the connection between the data processing system of the debtor and the server system. Since different connections are used, the presentation can be described as quasi-synchronous.

In particular, an identification feature is assigned to this payment process, for example a unique number. The start of the payment process is displayed to the connected payer. The payer is selected by the payer on the server system. In particular, the payee can notify the debtor of the identification feature, so that the debtor can select the desired payment process.

The identification feature can be represented via an optoelectronic interface, in particular by means of a bar code, wherein at least the Internet address of the server system is transmitted with the associated payment process. The barcode may contain further information.

The payee may provide the payer with the bar code, in particular a QR code, the QR code including, among other things, the identification feature. The identification feature is presented to the debtor as a QR code, wherein the QR code has an Internet address of the server system with the associated payment process. The debtor can use the QR code shown on the cash register, for example, in his shop with his smartphone - d. H. his data processing system - read opto-electronically and is connected with his smartphone with the corresponding Internet address of the server system with the associated payment process.

Furthermore, the identification feature can be transmitted via a wireless interface. The identification feature can be transmitted via a radio interface, in particular via Near Field Communication (NFC), wherein at least the Internet address of the server system is transmitted with the associated payment process.

The payment process may be presented to the parties as creating and selecting a "cash register". However, there are other names and representations, such as "transaction", "payment process" and the like.

The fact that the payer has joined the payment process is displayed to the payee. The fact that the payee also joined the payment process is displayed to the payer.

The amount to be paid is provided by the payee and entered and displayed to the payer. After that, the debtor has the opportunity to pay the requested amount. For this purpose, the currency key is transmitted from the data processing system of the debtor to the server system.

For example, the currency key may consist of a file or be contained in a file with further information. The file is designed in particular as an image file, wherein the currency key is stored in the metadata, in particular a comment segment of the image file. This file or the currency key is transmitted or uploaded by the debtor to the server system.

Alternatively, the currency key can be steganographically embedded in a file. The currency key is stored hidden in the file. The file contains obvious information, such as a text and / or image and / or audio information, in which obvious. Information of the means of payment is hidden. The obvious information serves as the bearer of the hidden cash key. The obvious information includes a signal and noise, with the currency key being hidden in the noise.

Further, the currency key may be embedded as a digital watermark in a file. Digital watermarks have in common with steganography that public information is used as the bearer, with the watermark embedded in the public information. The digital watermark is particularly robust. The currency key can not be removed from the file unnoticed. The watermark should not be destroyed by converting it to another file format.

The currency key may alternatively be contained in a file, the file additionally having a digital watermark. The watermark can be used to mark the file as a valuable object.

The currency key is then checked for validity. For this purpose, an associated payment verification record is accessed. The payment verification record also contains a key, a verification key. There are now different ways in which the validity of the payment key can be stored and checked on the server system. In particular, each payment medium key can have a payment means identification feature, for example a serial number. This means of payment identification may be part of the tender key and the verification key or may be stored in a separate data field. in the The payment verification data record with the identical identification feature is now stored the verification key. It is checked whether the verification key of the payment medium verification record and the cash key can be assigned. The currency key is valid if the two keys match or can be mapped to the verification key through a unique function of the cash keys, otherwise the cash key is invalid. In a preferred embodiment, the unique allocation of the cash flow key via the unique function. Therefore, the two keys need not be identical for the currency key to be valid. This feature may include, for example, encryption. The safety of the process is thereby increased.

It is possible for a payment key to have multiple payment verification records associated with it. These payment verification records have vzw. the same verification key. The payer may then access several payment verification records for payment purposes by transmitting a tender key. If the payer transmits a currency key with several associated payment verification records, only those verification keys required to pay for the amount required by the payee are changed or deleted.

If the currency key is invalid, then it indicates that the cash key is invalid. The amount can not be redeemed with an invalid currency key.

If the submitted and subsequently verified currency key is valid then the verification key is changed or deleted. If the verification key has been deleted, a new verification key is created. Furthermore, a new currency key is created, wherein the new cash key is associated with the new or changed verification key. In particular, the currency key can be assigned to the verification key by means of the function.

The new or changed verification key is preferably generated by a random number. The number space is sufficiently large, from which the random number originates, so that it can be ruled out with the necessary probability that the currency key can be guessed by trying out combinations. The new currency key is created by the server system in one embodiment and transmitted by the server system to the payee.

Changing the verification key creates a new tender key. All copies of the original tender key will no longer be considered valid in the future because the verification key has been changed. It is conceivable that the new payment medium key will receive a new payment medium identification feature or that the new payment medium key will retain the payment medium identification feature of the original cash register key.

The replacement of the verification key ensures the counterfeit security of the funds key. Once a payee receives a copy of the cash flow key, the payee does not know how many copies of that cash amount are now available. For example, it could have been duplicated many times by a previous owner - the payer - and thus passed on to a number of other payees in parallel for payment purposes. However, it only has the new currency key validity.

Otherwise, the key would lead to an uncontrolled increase and thus an inflationary devaluation of the money supply. However, as soon as the payee receives the new payment key from the payer via the server system or the payment process, or when the payee has proposed a new cash key and this new cash key has been accepted by the server system, the verification key has been changed and all copies of the old cash key become invalid. From the new copy of the payment medium key, the payee can be sure that only he as the payee owns this new payment key. Only the payee determines how many duplicates he makes from the new currency key.

In one embodiment, the new payment medium key is now transmitted from the server system to the payee. This can be realized by allowing the payee to download the currency key in the form of a file. The new payment key contains the changed payment key. The changed or new currency key is then stored at a further storage location available to the payee.

When creating the new cash key, the new cash key can be proposed by the payee in an alternative embodiment. The new currency key is transmitted from the payee's data processing system to the server system, the cash key being converted into a new verification key via the function and stored on the server system. The changed or new currency key may already be stored at a further storage location available to the payee or, if this is not already the case, the changed or new cash key may then be stored at a further storage location available to the payee.

The currency key may be associated with image, audio and / or video information. This can be realized by storing image, audio and / or video information in a file in a file format with additional metadata, for example with at least one comment segment, the currency key (s) in the metadata or is deposited in the comment segments of the file.

Alternatively, the payment key of the payer and / or the payee may include image, audio and / or video information. Ie. the payment medium key comprises the image, audio and / or video information and optionally further information.

The payee is presented the receipt of the new cash key by displaying a cash, in particular a coin or a banknote. Conventional money in the physical form of coins or banknotes is known to be in daily use in permanent danger of being lost, misplaced or stolen. On the other hand, with the electronic currency key of the present invention, this risk can be prevented by the owner depositing each copy of the cash key in multiple copies at different locations. If he loses a copy now, he can fall back on another.

The steps of the payment process are presented to both the payer and the payee substantially simultaneously. The presentation is in particular quasi-synchronous. The payee and the payer are connected to the server system, in particular via an Internet connection. To represent the payment process, the known transmission protocols can be used, so that no additional software must be installed on the data processing systems of the payee and / or the payer.

Electronic payment methods, which are currently used mainly on the Internet, are handled via accounting procedures that document the identity of the parties involved. The electronic currency key used here is particularly anonymous, d. H. the currency key does not contain information about the owner. The currency key does not allow any conclusions as to the identity of its owner. In particular, neither the deposit of personal data of the holder nor a customer or account number is required.

It requires neither the installation of individual software nor the purchase of an additional hardware component, but uses elements that are widely used and widely accepted, as well as offering a handling similar to conventional cash but offering it Ease of use surpasses and also enforces the use of adequate security standards.

In the present invention, the payment verification record resides on the server system of the issuer and contains one or more verification keys generated in particular according to the random number principle. The holder has the currency key in the form of a reference to one or more payment verification records, for example in the form of an image, audio or video file in which the verification key (s) are deposited.

The image information can in particular represent a financial means. A financial means any media whose primary purpose is the transfer of assets, in particular coins such as coins, commemorative coins, gaming chips, tokens or similar and securities such as banknotes, vouchers, bons, billets, tickets or similar and money orders such as about checks, bills of exchange or similar.

In addition, the method contains a payment transaction function, in particular on the server system, via which the currency key is exchanged between the payee and the payer and thereby changed. Preferably, some, in particular all steps of the transfer process, are displayed quasi-synchronously in real time to both parties involved. The payment transaction function accepts the payment medium key from the payer, replaces the verification key (s) with new verification keys and preferably forwards the payment medium key to the payee. This invalidates all previous copies of the submitted copy of the tender key.

The advantages achieved by the invention are, in particular, that the inventive electronic means of payment key is provided by a reference to one or more of the payment verification data records on the server system. Thus, the currency key is visible on the computer of the user and he can also dispose of it arbitrarily, for example, by passing it on to third parties. The reference or the currency key may consist of a link, for example. In the most minimalistic case, the reference consists only of a string representing the currency key.

A possibility of manipulation of the validity of the means of payment key excretes without access to the server system as a reference point nevertheless. Only for the connection to the function of the server system, which allows the payment process in real time with quasi-synchronous representation, encrypted transmission methods are required. However, conventional secure transmission methods can be used.

In addition, there is thus only a very small amount of data on the data processing system of the payment medium holder, which takes up relatively little storage space. Thus, it is also possible to stockpile large amounts of money on mobile terminals with a comparatively small storage offering. Even if the reference is mapped in an action attribute of a form tag in the markup language HTML, for example, the HTML code takes up only minimal memory space.

Another advantage is that the currency key is present, for example, as HTML code in the form of a form tag or a link in the form of human-readable text rather than in a binary-encrypted format. This facilitates the handling of the means of payment and its handling.

The payment process also consists of at least one function on a server under the control of the issuer. There, the involved parties exchange the currency key in real time, for example, by giving a cash key in the form of a pictured bill for payment and return a new cash key in the form of a representation of coins as change. In case of overpayment of the desired amount, the overpaid balance will be returned by the server system in the form of additional funds keys and / or a corresponding number of verification keys will be changed. This additional key (s) will be transmitted in particular in the smallest denomination. Each time a tenderer key is exchanged, the function alters the verification key, ensuring that all previous copies of the tenderer key become invalid or the old tender key is not associated with the corresponding payment verification records.

Calling the function can be triggered by simply clicking on an HTML link if the reference is designed as such. The return can be designed as a download, which is offered by the mentioned function. The detailed process is described in detail in Example 1.

Advantageous embodiments of the invention are specified in the subordinate claims.

A development of the invention is described in claim 2. On the client, an appealing illustrative, auditory or audiovisual rather than textual presentation of the currency key gives the inventive currency key an increased visual or acoustical appeal and thereby facilitates the handling of this new medium.

This image according to claim 2 may, as further developed in claim 3, also be deposited on a server system of the issuer. There may on the one hand for copies that are taken out of service and thus invalid, and on the other hand for those that are still valid in circulation, different Representations are deposited. For invalid copies, for example, a greyed-out picture, a matching tone sequence or a movie with the appropriate content is recommended. Even a reproduction in practically inconspicuous size of one pixel or the mute of a tone sequence would be in question. This makes it easier for the user to see which copies are still valid and are in his possession and which he has already issued for payment.

For the image, a format such as jpeg, png, gif, tif or ico or for the audio sequence such as wav, aac, mp3 or wma or for the video sequence for example mpg, avi, mov, mp4 or wmv can be used. This has the advantage that the media on the systems of the vast majority of users can be displayed natively as such. The cognitive aspect plays a key role in terms of user-friendliness.

Thus, it is also virtually ruled out that the holder has a copy of the cash key that is not displayed on his system in the expected manner. This avoids frightening situations triggered by fears of loss and spares costly efforts to retrieve lost money. Because, as is known, users respond to technical disruption in monetary transactions particularly irritated. The cause may be suspected in the existential and therefore sensitive relationship of people to their money.

By resorting to widely used standards, the chances of spreading the invention also increase. Means of payment. So not only technical requirements must be met and standardization agreements are made, but the introduction can be promptly initiated without further preconditions.

The image of the means of payment key forms according to the embodiment in claim 11 a well-known funds as image information, as which it is used. For example, the image may be a coin, a commemorative coin, a game chip, a chip, or the like, or a security such as a bill, coupon, receipt, bill, ticket or the like, or a money order such as a check, a bill of exchange or similar show. For example, if the currency key according to the invention is used as a coin or a banknote, the mapping may, for example, represent its conventional physical equivalent of corresponding value.

Also, electronic images similar to coins or coins are perceived as representational discrete objects that can be handled by comparable rules of handling. For example, they can be moved, counted, sorted or stored from one place to another. Abstract payment methods, however, lack these parallels.

Thus, the electronic payment key in pictorial form is associated even more with traditional means of payment and especially older users, the conversion to the new electronic form is even easier.

On the other hand, the presentation of the means of payment key can also be effected by the reproduction of popular pieces of music or by playing back excerpts of advertised feature films or commercials. Thus, the institution of money is extended by a functionality that goes beyond its traditional task and is capable of giving its electronic variant a feature of attractiveness, which may prove to be crucial for the broad acceptance, especially in the younger audience. Also, this embodiment serves the demand for new multimedia designs, which are formulated in the course of the generation change to HTML5 instantaneously.

In claim 12, the invention is further developed by the or the means of payment are stored in the machine code of the image, audio or video file. As a result, the data is compactly summarized and another file for the inclusion of this information is obsolete.

Claim 13 continues this approach. The key or keys are recorded as a bar code, in particular as a QR code in the image or video file. The graphic cipher becomes visible as a "pixel salad" and can be read and processed by optical decoding devices. This overcomes the threshold between the digital and real worlds when using the electronic tender key. However, the code can also be acoustically reproduced by an audio file, for example, and still be read by machine. Corresponding applications are known in the art of tone dialing.

On the other hand, claim 10 ultimately looks in the opposite direction and hides the key (s) in an image, audio or video file by using file segments intended for metadata for storage.

In the following, several embodiments of the invention will be explained with reference to the drawing and the associated description. In the drawing shows:

1 1 is a schematic view of a first screen view of a first embodiment of the method;

2 2 shows a schematic view of a second screen view of the first embodiment of the method,

3 3 shows a schematic view of a third screen view of the first embodiment of the method,

4 1 is a schematic view of a fourth screen view of the first embodiment of the method;

5 1 is a schematic representation of a fifth screen view of the first embodiment of the method;

6 1 is a schematic view of a first screen view of a second embodiment of the method;

7 in a schematic representation, a second screen view of a second embodiment of the method,

8th 3 shows a schematic view of a third screen view of the second embodiment of the method,

9 in a schematic representation, a fourth screen view of the second embodiment of the method,

10 in a schematic representation, a fifth screen view of the second embodiment of the method,

11 1 is a schematic representation of a sixth screen view of the second embodiment of the method,

12 in a schematic representation of a seventh screen view of the second embodiment of the method, and

13 in a schematic representation of an eighth screen view of a second embodiment of the method.

The following may first on the 1 to 5 Be referred.

In the 1 to 6 the steps of a method are shown for payment with at least one valid electronic currency key. In the 1 to 6 is a first screen view 1 with two windows 2 . 3 each represented an Internet browser. The left window 2 shows an Internet connection of a payee with a server system. The right window 3 shows an Internet connection of a debtor with a server system.

The representation of the windows 2 . 3 can be done in particular on two different, spatially separated data processing systems in different screen views. Here, the presentation was chosen on a data processing system with a common screen view to the quasi-synchronous representation in the windows 2 . 3 to clarify. The payee and the payer use the same data processing system for illustration purposes.

The window 2 . 3 each have an area for the payee or "borrower" and an area for the payer "lender".

The server system is contacted here by calling up a website. The website may for example be "http://www.mycunia.de". The server system is in particular under the control of a financial institution.

At the beginning of the method, in a first step, a connection is established between a data processing system of a payee and the server system, and a connection setup between a data processing system of a debtor and the server system.

1 shows the two windows 2 . 3 wherein the respective connection setup has been made by the debtor to the server system and the payee to the server system. Both windows 2 . 3 show first the same content.

Next, in the procedure, the assigning of the payee and the payer takes place. For this purpose, a payment process is provided by the server system in the form of a button "new cash register". The "New Cashier" button is activated by the payee. This creates a new cash register - here the cash register # 2.

2 shows that the payee in window 2 a new view with the new cash register no. 2 is displayed. The payee is provided with an input mask in which the payee can enter the desired amount of money. It is represented by the text "donor absent" to the payee that the debtor or "the lender" of the cash register no. 2 has not yet joined.

In windows 3 the payer will see a selection of the available funds. In the example the attached cash register no. 2 is available. The debtor can join the selected fund - here cash register # 2.

3 shows that the debtor in the window 3 a new view with the new cash register no. 2 is displayed after the debtor has joined cash register no. The debtor is in windows 3 indicated that the "borrower is present" or the payee also gets the cash register displayed. The debtor will also be notified of the amount requested ("Price"), the amount paid ("Paid") and the change ("Back"), followed here by "0.00" as no amount has been requested and paid and therefore still no change is to be refunded.

The requested amount is now in the window by the payee 2 entered. By pressing the "Send" button by the payee, the desired and entered amount is sent.

4 shows the windows 2 . 3 after the required amount or "price" in Example 75 has been entered and sent by the payee. The debtor will be sent the required amount and displayed.

With the button "Pay" the payer can pay the amount. This process is in the 1 to 5 not shown in detail, and automatically takes place in the background.

The currency key is initially stored on the data processing system of the debtor. Alternatively, the currency key may be stored on the server system in an electronic, secured wallet of the payer.

The server system stores at least one payment verification record with a payment value and at least one verification key. Each valid currency key is associated with at least one payment verification record. If the verification key of the payment verification record and the tender key form a pair or can be associated with each other, the tender key is valid.

The funds key (not shown here) is automatically saved in a simplified version by pressing the "Pay" button or by clicking the "Pay" button Data processing system of the debtor transmitted to the server system. Alternatively, by pressing the "Pay" button, the currency key is transmitted from the electronic purse to the server system.

Based on the payment verification record, the validity of the cash key is checked.

In the case that the submitted and verified currency key is valid, the associated verification key is changed or deleted, a new verification key is created and a new currency key with the changed key is created. The new currency key can either be created by the server system and then transmitted to the payee or proposed by the payee. In this case, the means of payment key is transmitted from the payee's data processing system to the server system.

The new currency key is then transmitted to the payee or server system. The payee then stores at a further storage location, in particular on its data processing system, the currency key. On the data processing system of the payee, the means of payment key, in particular by mapping a funds presented.

5 shows that the payer has given a cash key with the assigned amount of 100.00 and therefore receives 25.00 as a bill of exchange. The amounts are stored on the server system. The change of 25.00 will be automatically given by the server system by submitting a valid cash amount key of 25.00 to the debtor.

The following may be applied to the 6 to 13 Reference is made in which the method is shown in more detail.

At the beginning of the method, in a first step, a connection is established between a data processing system of a payee and the server, and a connection setup between a data processing system of a debtor and the server.

6 shows similar to 1 the two windows 2 . 3 wherein the respective connection setup has been made by the debtor to the server system and the payee to the server system. Both windows 2 . 3 show first the same content.

Next, in the procedure, the assigning of the payee and the payer takes place. For this purpose, a button "New Cashier" is provided. The "New Cashier" button is activated by the payee. This will create a new cash register - here's the cash register 1 - created.

7 shows that the payee in window 2 a new view with the new cash register 1 is shown. The payee is provided with an input mask in which the payee can enter the desired amount of money. It is represented by the text "donor absent" the payee that the debtor or "the lender" of the cash register 1 not yet joined.

In windows 3 the payer will see a selection of the available funds. In the example, the cash register is created 1 available. The debtor can check the selected cash register - here cashier 1 - to join.

8th shows that the debtor in the window 3 a new view is displayed with the new cash register # 1, after which the debtor has joined the cash register # 1. The debtor is in windows 3 indicated that the "borrower is present" or the payee also gets the cash register displayed. The debtor will also be notified of the amount requested ("Price"), the amount paid ("Paid") and the change ("Back"), followed here by "0.00" as no amount has been requested and paid and therefore still no change is to be refunded.

The requested amount is now in the window by payee 2 entered.

9 shows the windows 2 . 3 after the required amount or "price" in Example 75 has been entered and sent by the payee. The debtor will be sent the required amount and displayed.

The currency key is now transmitted to the server system by the payer. The currency key is vzw. saved in a file. In the window 3 the payer can select a file with the funds key, as shown in 9 and 10 is shown.

The file or the currency key is initially stored on the data processing system of the debtor. The currency key (not shown) is stored in the file.

The payment medium key has image, audio and / or video information on the data processing system of the payer and / or on the data processing system of the payee and is displayed as a picture, an audio or a video sequence. In 10 is a picture file 4 illustrated with the illustration of a bill. This image file 4 serves as a means of payment 5 ,

The image, audio and / or video information is stored in a file in a file format with at least one additional comment segment, the key (s) being stored in the comment segment (s) of the file. Here, the currency key is present in a JPEG file, the image information is a bill, for example, a 100-euro bill. The currency key is particularly in a metadata segment, eg. In a comment segment of the JPEG file.

At least one payment verification record with a payment value and with a verification key is stored on the server system. Each valid currency key is associated with at least one payment verification record. If the two keys - the verification key of the verification record and the cash key - are assignable, ie form a pair, the cash key is valid. Based on the payment verification record, the validity of the cash key is checked. In case the submitted and verified currency key is valid, the verification key is changed or deleted and a new verification key and a new currency key are created.

The new tender key is then transmitted to the payee unless the payee has suggested the cash key. The payee stores at a storage location the new payment key, in particular on its data processing system. On the data processing system of the payee, the cash key is represented in particular by mapping a cash.

12 shows that the payer has two cash keys 6 . 7 in the form of image files gets replaced. Because the debtor has a cash key 5 with the amount has given 100 euros and. the payee has requested 75 euros, have the two cash keys 6 . 7 the amount 5 and 20 euros. The bill of exchange, namely the means of payment 5 . 6 25.00 Euro will be provided by the server system for downloading.

The payee receives in his window 2 the possibility of the payment key 8th . 9 . 10 in the amount of 20 euros, 50 euros and 10 euros, as in 12 and 13 is shown.

In the following, further examples of means of payment and embodiments of the method are explained.

Example 1:

The currency key may be a file in text format or stored in such a file in a simple embodiment. This file, named banknote001.png, contains the string "01234567890abcdef" as the currency key. On a server system there is a database with a table of the following structure: <Serialno> <Timestamp> <Schluessel> 000000000001 2011-01-01 10: 23: 050 1234567890ABCDEF

The table entries form the payment medium verification data records or here the payment medium verification data record.

The payment value is not shown here, but it is still included in the verification record.

The verification record on the server system forms a representation of the tender key. The currency key forms a reference to the verification data record or the representative office. The relationship between reference and representation arises from the identity of the two keys.

The payee can start a new payment process on the server system. The payment process is presented to the debtor and the payee quasi-synchronously. In particular, an identification feature is assigned to this payment process, for example a transaction number. The start of the payment process is displayed to the connected payer. The payer can select the payment process on the server system. In particular, the payee can notify the debtor of the identification feature, so that the debtor can select the desired payment process. The payment process may be presented to the parties as creating and selecting a "cash register". However, there are other names and representations, such as "transaction", "payment process" and the like.

This means that the output of all events that occur under the activity number on the function's page is quasi-synchronized to the payer and the payee. The transmission from and to this side or the server system takes place via an encrypted protocol and is thus protected against unauthorized interception.

The debtor uploads the file to the server system. Their name is displayed there, almost simultaneously for the payer and the payee. The function then replaces the verification key in the file with another one-off, randomly generated, and offers the payee the downloaded file for download. The new file now contains the new verification key "9876543210fedcba" and the record in the database table is now <Serialno> <Timestamp> <Code> 000000000001 2011-08-01 16:08:44 9876543210fedcba

In front of the debtor and the payee, the name of the file disappears from the page. In the same way - only in the opposite direction - now the payee "the change" back. The payment process is completed.

If, during the payment process, any disruptions occur, the parties have the opportunity to intervene. For example, if the payee complains that the download of the funds key has failed, the function offers, for example, the option of blocking the exchanged copy of the cash key until the facts have been clarified.

Example 2:

Instead of the string, the file in Example 1 contains a link with a query string that passes the transaction number and the tender key:

The debtor can thus call the function by simply clicking on the HTML link. The currency key is automatically transferred.

Example 3:

In contrast to example 1, the file is an image in PNG format, which represents a banknote. In addition to its signature, it consists of various blocks, including one of the block type "tEXt" with the content "01234567890abcdef".

The currency key is included in the comment field of the image file. The image file forms the currency key.

Example 4:

Unlike example 3, the image is not on the client's machine, but on the server, and is referenced by an HTML reference:

The currency key is part of the name of the image file.

Example 5:

The guest of a restaurant wants to pay his bill. In its place a QR code is printed on the table top. The guest directs the camera of his smartphone to this QR code and launches an app that contacts the payment process on the server system of the issuer. The server system in turn informs the internet-enabled POS system of the restaurant that the guest will pay his bill. The payer gets directly to the window as it is in 4 or in 9 is shown. The further payment process can then be handled independently in particular now without any additional action by the guest or waiter through the app and the POS system.

Example 6:

A bank issues an electronic tender key in the form of mp4 files worth € 1.00 each, with the mp4 files containing an excerpt from a music clip that has just entered the hit charts, for example. The artist offers on his website the complete music clip for Euro 1.00 for download. The holder may use his electronic funds key for any purpose of payment, including but not limited to the purchase of the music clip.

LIST OF REFERENCE NUMBERS

1

screen

2

window

3

window

4

image

5

Cash key

6

Cash key

7

Cash key

8th

Cash key

9

Cash key

10

Cash key

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• DE 102009034436 A1 [0046]
• DE 19859959 A [0049]

Cited non-patent literature

• ISO 7810 [0044]
• http://www.mgovernment.org/resurces/euromgov2005/PDF/29_S049HK-S04.pdf [0053]

Claims (22)

Method of payment with at least one electronic means of payment ( 5 . 6 . 7 . 8th . 9 . 10 ), wherein a server system stores at least one payment verification record with a payment value and a verification key, each valid cash key ( 5 . 6 . 7 . 8th . 9 . 10 ) at least one payment verification record is assigned, the payment medium key ( 5 . 6 . 7 . 8th . 9 . 10 ) is stored in a storage location, wherein the storage location is available to a debtor, comprising the following steps: - establishing a connection between a data processing system of a payee and the server system, - establishing a connection between a data processing system of the debtor and the server system, - assigning the payee and the payer , - Transmitting the cash key ( 5 . 6 . 7 . 8th . 9 . 10 ) to the server system, - check the validity of the cash key ( 5 . 6 . 7 . 8th . 9 . 10 ), - Change the verification key and create a new, assigned payment key ( 5 . 6 . 7 . 8th . 9 . 10 ), in case the submitted and verified 5 . 6 . 7 . 8th . 9 . 10 ), or - Delete the verification key and create a new verification key and a new, assigned payment key ( 5 . 6 . 7 . 8th . 9 . 10 ), in case the submitted and verified 5 . 6 . 7 . 8th . 9 . 10 ), - the new means of payment ( 5 . 6 . 7 . 8th . 9 . 10 ) is or is stored at a further storage location available to the payee. Method according to claim 1, characterized in that the currency key ( 5 . 6 . 7 . 8th . 9 . 10 ) of the payer and / or the payee has image, audio and / or video information or is associated with image, audio and / or video information, the currency key ( 5 . 6 . 7 . 8th . 9 . 10 ) is displayed as an image, an audio or a video sequence. A method according to claim 1 or 2, characterized in that an image, an audio and / or video information is stored on the server system and the currency key ( 5 . 6 . 7 . 8th . 9 . 10 ) has a reference to this server-side image, audio and / or video information. Method according to one of the preceding claims, characterized in that when the new means of payment code is created ( 5 . 6 . 7 . 8th . 9 . 10 ) the new payment key ( 5 . 6 . 7 . 8th . 9 . 10 ) is proposed by the payee and the new payment key ( 5 . 6 . 7 . 8th . 9 . 10 ) is transmitted from the payee's data processing system to the server system, one of the new payment medium keys ( 5 . 6 . 7 . 8th . 9 . 10 ), new or changed verification key is stored on the server system. Method according to one of the preceding claims, characterized in that the new means of payment ( 5 . 6 . 7 . 8th . 9 . 10 ) is created by the server system and is transmitted from the server system to the payee. Method according to one of the preceding claims, characterized in that a new payment process is started by the payee, wherein the payment process, an identification feature is assigned to the server system, and wherein the debtor joins the payment process. Method according to one of the preceding claims, characterized in that the identification feature via an opto-electronic interface, in particular by means of a bar code, is displayed, wherein at least the Internet address of the server system is transmitted with the associated payment process. Method according to one of the preceding claims, characterized in that the identification feature is represented as a bar code, in particular as a QR code, wherein the bar code, in particular the QR code, has an Internet address of the server system with the associated payment process. Method according to one of the preceding claims, characterized in that the identification feature is transmitted via a wireless interface. Method according to one of the preceding claims, characterized in that the identification feature is transmitted via a radio interface, in particular via near field communication (NFC), wherein at least the Internet address of the server system is transmitted with the associated payment process. Method according to one of the preceding claims, characterized in that the payment process on the server system is selected by the debtor. Method according to one of the preceding claims, characterized in that after the start of the payment process by the payee, the desired amount is transmitted to the server system, wherein the desired amount is displayed to the debtor. Method according to one of the preceding claims, characterized in that an image, an audio and / or video information is stored in a file in a file format with additional metadata, in particular a comment segment, wherein the currency key (s) ( 5 . 6 . 7 . 8th . 9 . 10 ) are stored in the or in the metadata segments or comment segments of the file. Method according to one of the preceding claims, characterized in that the currency key ( 5 . 6 . 7 . 8th . 9 . 10 ) is steganographically embedded in a file. Method according to one of the preceding claims, characterized in that the currency key ( 5 . 6 . 7 . 8th . 9 . 10 ) is embedded as a digital watermark in a file. Method according to one of the preceding claims, characterized in that the currency key ( 5 . 6 . 7 . 8th . 9 . 10 ) is contained in a file, the file additionally having a digital watermark. Method according to one of the preceding claims, characterized in that the image information is a monetary means, in particular a coin such as a coin, a commemorative coin, a game chip, a chip or the like or a security such as a banknote, a coupon, a Bon Billet, a ticket or the like or a payment order such as a check, a bill or similar presents; and or The audio sequence reproduces a piece of music or a section thereof; and or - The video sequence plays a movie or a section of it. Method according to one of the preceding claims, characterized in that the currency key ( 5 . 6 . 7 . 8th . 9 . 10 ) is contained in the image information or the audio information, the currency key ( 5 . 6 . 7 . 8th . 9 . 10 ) is encoded in a machine readable pattern. Method according to one of the preceding claims, characterized in that the currency key (s) ( 5 . 6 . 7 . 8th . 9 . 10 ) is encoded in a bar code, in particular a QR code or a multi-frequency code is / are. Method according to one of the preceding claims, characterized in that the connection status of the payee is displayed to the payer and / or the connection status of the payer is displayed to the payee. Method according to one of the preceding claims, characterized in that the connection of the payee and / or the debtor to the server system is encrypted. A means of payment for carrying out the method according to one of the preceding claims, characterized in that the means of payment ( 5 . 6 . 7 . 8th . 9 . 10 ) comprises image, audio and / or video information.

Images