WO2013034278A2 - Verfahren zur bezahlung mit mindestens einem elektronischen zahlungsmittelschlüssel - Google Patents

Verfahren zur bezahlung mit mindestens einem elektronischen zahlungsmittelschlüssel Download PDF

Info

Publication number
WO2013034278A2
WO2013034278A2 PCT/EP2012/003692 EP2012003692W WO2013034278A2 WO 2013034278 A2 WO2013034278 A2 WO 2013034278A2 EP 2012003692 W EP2012003692 W EP 2012003692W WO 2013034278 A2 WO2013034278 A2 WO 2013034278A2
Authority
WO
WIPO (PCT)
Prior art keywords
key
payment
payee
server system
new
Prior art date
Application number
PCT/EP2012/003692
Other languages
English (en)
French (fr)
Other versions
WO2013034278A3 (de
Inventor
Norbert PILZ
Karl NOSWITZ
Markus Miller
Original Assignee
Dr. Klein Gmbh & Co. Media Kgaa
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 Dr. Klein Gmbh & Co. Media Kgaa filed Critical Dr. Klein Gmbh & Co. Media Kgaa
Publication of WO2013034278A2 publication Critical patent/WO2013034278A2/de
Publication of WO2013034278A3 publication Critical patent/WO2013034278A3/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/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • 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/383—Anonymous user system

Definitions

  • the invention relates to a method for payment with at least one electronic means of payment.
  • 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.
  • eCash 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.
  • 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.
  • the electronic purse 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.
  • each file consists of the serial number and the information about the value and is encrypted with the key of the bank.
  • 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.
  • 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.
  • Bitcoin 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 free open source software. The possession of monetary units can be proved 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.
  • 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 disclosed in this process.
  • the purse must be protected against loss by spying and malicious software.
  • 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 can be earned by participants in the peer-to-peer network in the use of processing power for the confirmation and signature of transactions.
  • Bitcoin conceptually combines certain features of remittances with the property of limited money, 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.
  • 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.
  • 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.
  • 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.
  • a user 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.
  • bitcoin recipient addresses can be generated.
  • the counterpart private key to this address is automatically stored in a file named "wallet.dat”.
  • the recipient address can be e.g. e-mail, but also use to send yourself 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.
  • 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.
  • 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.
  • Bitcoin uses the elliptic curve cryptosystem ECDSA in the 256-bit configuration secp256kl to sign data.
  • the block now published in the system defines the transactions contained in it bindingly.
  • 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.
  • Bitcoin Since the block chain and the confirmed transactions are publicly visible, 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.
  • 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.
  • 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.
  • 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.
  • Bitcoin Although Bitcoin is often referred to as electronic cash, it can not be considered money because it is not authorized by a government Place with redemption guarantee is issued. 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.
  • Bitbills Another project that enables cash-like payments without the customer's internet connection is called Bitbills. These consist of ISO 7810 format plastic cards containing a Bitcoin address key pair with amounts between 1 and 20 BTC. 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 actual amount on the card can be displayed at any time on the website blockexploer.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 at the beginning of July 2011 was 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.
  • 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 instance, 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.
  • 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.
  • 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.
  • DE 1 985 995 9 A discloses a method for a transfer of money and assets and units of money or assets therefor, the method requiring no 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.
  • 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.
  • the payment transaction is not limited to a transaction between the payer and the payee.
  • 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.
  • 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.
  • this object is achieved by a method for payment with at least one electronic means of payment, wherein at least one means of payment verification having a payment value and a verification key is stored on a server system, each valid means of payment being at least one
  • Means of payment is stored in a storage location, wherein the
  • 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 is centrally managed on one or more servers. Of 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, that is, each currency key is exactly one
  • the means of payment serves as authorization means.
  • 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 means of payment is governed by the power of the holder, ie at the beginning of the procedure the means of payment is subject to the power of disposal of the payer and at the end of the procedure the Power of disposal of the payee.
  • the means of payment is initially stored in a storage location of the debtor and in particular one
  • Data processing system assigned to the debtor or the payee 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 can also be referred to as a client.
  • the currency key agrees with the associated server side verification key
  • Payment verification record identical or preferably via a corresponding function to the verification key can be assigned, if the means of payment is valid. By checking the assignability of the cash key to the verification key (s), it is checked whether the cash key is valid or invalid. For example, if a
  • 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 establishment with the server system preferably takes place via an encrypted connection.
  • the payer and the payee are assigned.
  • 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.
  • 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.
  • 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 display the QR code, for example in a shop at the cash register, with his smartphone - ie 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.
  • 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.
  • NFC Near Field Communication
  • the payment process may be presented to the participants as the creation and selection of a "cash register”, but other terms and representations such as “transaction”, “payment process” and the like may be used.
  • 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.
  • the currency key is transmitted from the data processing system of the debtor to the server system.
  • 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.
  • the currency key can be steganographically into a file be embedded.
  • the currency key is stored hidden in the file.
  • the file contains obvious information, such as text and / or image and / or audio information, with the currency key hidden in this apparent information.
  • 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.
  • 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.
  • each currency key is then checked for validity.
  • an associated payment verification record is accessed.
  • the payment verification record also contains a key, a verification key.
  • each currency key can be a cash
  • This payment medium identification feature may be part of the payment medium key and the verification key or may be stored in a separate data field. In 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.
  • a payment key may 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.
  • the verification key is changed or deleted. If the verification key has been deleted, a new verification key is created. In addition, a new currency key is created, with the new cash key being the new or modified verification key assigned. 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.
  • the replacement of the verification key ensures the counterfeit security of the funds 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.
  • the key would lead to an uncontrolled increase and thus an inflationary devaluation of the money supply. But as soon as the payee receives the new payment key from the payer via the server system or the payment process or as soon as the payee receives a new one Has been proposed by the server system and the new key has been accepted by the server system, the verification key has been changed and thus all copies of the old tender 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.
  • 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.
  • 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 in that a picture, an audio and / or a video information in a file in a file format with additional metadata, for example with at least one Comment segment is stored, wherein the one or more of the means of payment in the metadata or in the or in the comment segments of the file is / are / are.
  • the payment key of the payer and / or the payee may include image, audio and / or video information. That 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.
  • 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.
  • 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 debtor are connected to the server system in particular via an Internet connection.
  • 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 means of payment used here is anonymous, ie the means of payment contains no information about the owner. Of the Credits 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.
  • 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 an e-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.
  • 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.
  • 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.
  • some, in particular all steps of the transfer process are displayed quasi-synchronously to both involved parties in real time.
  • the payment function takes this to the Accepting payment key from the payer, replaces the verification key (s) with new verification key (s), and preferably passes the tender key to the payee. This invalidates all previous copies of the submitted copy of the tender key.
  • 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.
  • 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.
  • currency key for example, as HTML code in the form of a form tag or a link in the form of a human-readable text and not in a binary encrypted format is present. 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.
  • 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.
  • the overpaid balance is returned by the server system in the form of additional funds keys and / or a corresponding number of verification keys is changed.
  • This additional key (s) will be transmitted in particular in the smallest denomination.
  • the feature changes the verification key, ensuring that all previous copies of the tenderer key become invalid or the old tender key does not match
  • 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.
  • 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.
  • 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.
  • 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.
  • the mapping may, for example, represent its conventional physical equivalent of corresponding value.
  • 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.
  • 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.
  • 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.
  • this embodiment serves the demand for new multimedia designs, which are formulated in the course of the generation change to HTML5 instantaneously.
  • the invention is further developed by the or the currency key in the machine code of the image, audio or video file be filed.
  • 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, overcoming the threshold between the digital and the real world when using the electronic tender key, but the code can also be acoustically reproduced from an audio file, for example Corresponding applications are known in the art of tone dialing.
  • 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.
  • FIG. 1 is a schematic representation of a first screen view of a first embodiment of the method
  • FIG. 2 shows a schematic representation of a second screen view of the first embodiment of the method
  • FIG. 3 is a schematic representation of a third screen view of the first embodiment of the method
  • 4 is a schematic representation of a fourth screen view of the first embodiment of the method
  • 5 shows a schematic representation of a fifth screen view of the first embodiment of the method
  • FIG. 6 is a schematic representation of a first screen view of a second embodiment of the method
  • FIG. 9 is a schematic representation of a fourth screen view of the second embodiment of the method.
  • FIG. 11 is a schematic representation of a sixth screen view of the second embodiment of the method.
  • FIG. 13 is a schematic view of an eighth screen viewing a second embodiment of the method.
  • FIGS. 1 to 5 reference may first be made to FIGS. 1 to 5.
  • FIGS. 1 to 6 show the steps of a method for payment with at least one valid electronic means of payment key.
  • FIGS. 1 to 6 show a first screen 1 with two windows 2, 3, each of 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 Büdtubansivier.
  • the representation was selected on a data processing system with a common screen view to illustrate the quasi-synchronous representation in the windows 2, 3.
  • the payee and the payer use the same data processing system for illustration purposes.
  • the windows 2, 3 each have an area for the payee or the "borrower" and an area for the payer "financier”.
  • 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.
  • 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.
  • Fig. 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 initially show the same content.
  • a payment process is provided by the server system in the form of a button "new cash register”
  • the "new cash register” button is activated by the payee, which creates a new cash register - here cash register no.
  • Fig. 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.
  • Window 3 shows the payer a selection of the available funds.
  • the attached cash register no. 2 is available.
  • the debtor can join the selected cash register - here cash register no.
  • FIG. 3 shows that the payer in window 3 is shown a new view with the new cash register no. 2 after the debtor has joined cash register no.
  • the debtor is shown in window 3 that the "borrower is present" or the payee also gets the cash register displayed.
  • the debtor is also the amount claimed ("price"), the amount paid ("paid”) and the change ("Back") displayed here followed by "0.00” because no amount has yet been requested and paid and therefore no change is to be refunded.
  • the requested amount is now entered by the payee in window 2.
  • the desired and entered amount is sent.
  • the currency key is initially stored on the data processing system of the debtor.
  • the currency key may be stored on the server system in an electronic, secured wallet of the payer.
  • On the server system is at least one
  • a payment verification record containing a payment value and having at least one verification key stored. Each valid currency key is at least one
  • the tender key is valid.
  • the funds key (not shown here) is transmitted in a simplified version by pressing the button “Pay” or clicking the button “Pay” automatically from the data processing system of the debtor to the server system.
  • the currency key is transmitted from the electronic purse to the server system.
  • 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 Payment key from the data processing system of the payee to the server system transmitted.
  • 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.
  • the means of payment key in particular by mapping a funds presented.
  • Fig. 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.
  • 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.
  • FIGS. 6 to 13 in which the method is shown in more detail.
  • 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.
  • Fig. 6 shows similar to Fig. 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 initially show the same content.
  • Fig. 7 shows that the payee in window 2 a new view with the new cash register 1 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 1 has not yet joined.
  • Window 3 shows the payer a selection of the available funds.
  • the cash register 1 is available.
  • the debtor can join the selected cash register - here cash register 1.
  • FIG. 8 shows that the debtor in window 3 is shown a new view with the new cash register # 1, after which the debtor has joined cash register # 1.
  • the debtor is shown in window 3 that the "borrower is present” or the payee also gets the cash register displayed.
  • the debtor is also the amount claimed ("price"), the amount paid ("paid”) and the change ("Back") displayed here followed by "0.00” because no amount has yet been requested and paid and therefore no change is to be refunded.
  • the requested amount is now entered by payee in window 2.
  • 9 shows the windows 2, 3 after the required amount or "price" has been entered and sent by the payee in example 75. The required amount is sent to the payer and displayed.
  • the currency key is now transmitted to the server system by the payer.
  • the currency key is vzw. saved in a file.
  • the debtor can file with the Select currency key as shown in Figs. 9 and 10.
  • 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.
  • an image file 4 is shown with the image of a bill. This image file 4 serves as a currency key 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.
  • 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, e.g. in a comment segment of the JPEG file, deposited.
  • On the server system is at least one
  • Payment verification record is stored with a payment value and with a verification key. 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 transmitted and verified tender key is valid, the verification key is changed or deleted and a new verification key and a new one Means of payment created.
  • the new tender key is then transmitted to the payee unless the payee has suggested the cash key.
  • the payee stores at a location the new currency key in particular on his
  • the cash key is represented in particular by mapping a cash.
  • FIG. 12 shows that the debtor receives two means of payment keys 6, 7 in the form of image files as bills of exchange. Since the debtor has given a cash key 5 with the amount 100 euros and the payee has demanded 75 euros, the two cash keys 6, 7 have the amount 5 and 20 euros. The change, namely the means of payment 5, 6 in the amount of 25.00 euros are provided by the server system for downloading.
  • the payee receives in his window 2, the possibility of the cash keys 8, 9, 10 in the amount of 20 €, 50 € and 10 € load, as shown in Fig. 12 and 13.
  • the currency key may be a file in text format or stored in such a file in a simple embodiment.
  • This file named banknoteOOl.png contains the string "01234567890abcdef.
  • a server system there is a database with a table of the following structure:
  • 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 quasi-synchronously to the debtor and the payee.
  • 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.
  • 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 participants as the creation and selection of a "cash register", but other terms and representations such as "transaction", "payment process” and the like may be used.
  • 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 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.
  • the file is an image in PNG format, which represents a banknote.
  • 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.
  • the image is not on the client machine, but on the server, and is referenced by an HTML reference:
  • the currency key is part of the name of the image file.
  • the guest of a restaurant wants to pay his bill.
  • a QR code printed on the tabletop.
  • the guest directs the camera of his smartphone to this QR code and launches an app that contacts the payment process on the issuer's server system.
  • the server system in turn informs the internet-enabled POS system of the restaurant that the guest will pay his bill.
  • the payer goes directly to the window, as shown in Fig. 4 or in Fig. 9.
  • 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.
  • a credit institution issues an electronic tender key in the form of mp4 files valued at € 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.

Landscapes

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

Abstract

Die Erfindung betrifft ein Verfahren zur Bezahlung mit mindestens einem elektronischen Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10), wobei auf einem Serversystem mindestens ein Zahlungsmittelverifizierungsdatensatz mit einem Zahlungswert und mit einem Verifizierungsschlüssel gespeichert ist, wobei jedem gültigen Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) mindestens ein Zahlungsmittelverifizierungsdatensatz zugeordnet ist, wobei der Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) an einem Speicherort gespeichert ist, wobei der Speicherort einem Zahlungspflichtigen zur Verfügung steht, mit den folgenden Schritten: + 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 (5, 6, 7, 8, 9, 10) an das Serversystem, + Überprüfen der Gültigkeit des Zahlungsmittelschlüssels (5, 6, 7, 8, 9, 10), + Ändern des Verifizierungsschlüssels sowie Erstellen eines neuen, zugeordneten Zahlungsmittelschlüssels (5, 6, 7, 8, 9, 10), im Fall dass der übermittelte und überprüfte Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) gültig ist, oder + Löschen des Verifizierungsschlüssels sowie Erstellen eines neuen Verifizierungsschlüssels und eines neuen, zugeordneten Zahlungsmittelschlüssels (5, 6, 7, 8, 9, 10), im Fall dass der übermittelte und überprüfte Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) gültig ist, + wobei der neue Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) an einem dem Zahlungsempfänger zur Verfügung stehenden, weiteren Speicherort gespeichert wird oder ist. Das Verfahren eignet sich einerseits für den digitalen Raum, andererseits ist eine lückenlose Rückverfolgung des Zahlungswegs ausgeschlossen und gleichzeitig ist das Verfahren für den Anwender einfach zu handhaben.

Description

„Verfahren zur Bezahlung mit mindestens einem elektronischen
Zahlungsmittelschlüssel"
Die Erfindung betrifft ein Verfahren zur Bezahlung mit mindestens einem elektronischen Zahlungsmittelschlüssel.
Es sind verschiedene Verfahren im Stand der Technik bekannt:
Mit der Verbreitung der elektronischen Datenverarbeitung haben sich immer mehr Systeme etabliert, die das Bezahlen mit Banknoten und Münzen durch unbare Alternativen ersetzen. So wurden Karten eingeführt, die beispielsweise mit Magnetstreifen, Speicherchips oder aufgedruckter Codierung ausgestattet sind. Dabei lassen sich prinzipiell zwei Gestaltungsvarianten unterscheiden.
Auf den so genannten Geldkarten ist ein Geldwert gespeichert. Beim Zahlungsvorgang wird von diesem Wert abgebucht. Bekannte Vertreter dieser Gattung sind die so genannten elektronischen Geldbörsen sowie die Telefonkarten. Eine Registrierung des Karteninhabers ist dabei nicht notwendig. Wer die Karte in Händen hält, kann über das Guthaben verfügen.
Bei den Kreditkarten dagegen wird die Identität des Inhabers auf der Karte hinterlegt. Die Verfügungen mit der Karte werden mit ihm abgerechnet. Die Kenntnis der Personalangaben ist dafür unerlässlich. Dabei kursieren auch Kreditkarten, die aus Bonitätsgründen nur auf Guthabenbasis geführt werden, und so genannte Debitkarten, die keine Zahlungsziele gewähren. Dies ändert aber nichts an der Dokumentation der Identität des Karteninhabers.
Die Tendenz zu unbaren Zahlungsmodi wird durch die rasante Expansion des Internets noch rapide beschleunigt. Die gegenwärtige Konjunktur internetfähiger, mobiler Telefongeräte mit zusätzlicher Computerfunktionalität, so genannte Smartphones, beschleunigt diesen Trend signifikant. Das Internet wird damit zum ständigen Begleiter. Der konventionelle Handel verlagert sich mit wachsendem Tempo in den digitalen Eaum und fordert Zahlungsmethoden, die dort zu Hause sind und sowohl den Anforderungen des Mediums als auch
BESTÄTIGUNGSKOPIE der Anvvenderfreundlichkeit gerecht werden.
Alle im Internet gegenwärtig gängigen Bezahlverfahren haben gemein, dass für den zahlenden Teilnehmer - in welcher Art auch immer - ein Kontokorrent geführt wird. Dieses Prinzip gilt sowohl für die Kreditkartenzahlung wie auch für andere Bezahlformen im Web.
Damit wird zunehmend Bargeld von Buchgeld abgelöst.
Zu den systemimmanenten Eigenschaften banküblicher Kontoführung gehört die dauerhafte Aufzeichnung der Vorgangsdaten sowie die Identifizierung der an einer Zahlungstransaktion beteiligten Parteien. Aus umfangreichen Kontobewegungen lässt sich für einen Web-User nicht nur sein digitales Bewegungsprofil generieren, sondern auch seine Konsumgewohnheiten ermitteln und damit seine Interessenschwerpunkte und persönlichen Präferenzen ausspähen. Mit der Verwertung dieser sensiblen personenbezogenen Daten wird tief in die Privatsphäre der Betroffenen eingedrungen. Zudem besteht die Gefahr, dass die gewonnenen Informationen gegen ihre Interessen verwendet werden. Deshalb empfehlen Datenschützer eindringlich, so wenig wie möglich Spuren im Internet zu hinterlassen. Dazu würde vor allem auch die Zahlung mit einem anonymen elektronischen Zahlungsmittel statt durch Überweisungsverfahren gehören.
Mit der Richtlinie 2000/46/EG hat die Europäische Union schon im Jahre 2000 die rechtliche Grundlage für die gesetzliche Umsetzung auf nationaler Ebene zur Einführung von elektronischem Geld (E-Geld) als elektronischem Ersatz für Münzen und Banknoten geschaffen. Dabei wurde das Emissionsrecht an die Kreditinstitute delegiert. Dieses elektronische Zahlungsmittel bzw. Geld wird auch als Netzgeld bezeichnet.
Im Internet kursieren unzählige Abbildungen von Banknoten und Münzen in Bildform in den gängigen Formaten wie z.B. jpeg, png, gif, tif und ico, wobei sich diese Grafiken mühelos beliebig oft duplizieren lassen. Deshalb beschränkt sich ihr Einsatz auf illustrative Zwecke; eine Verwendung als elektronisches Zahlungsmittel scheidet im Stand der Technik verständlicherweise aus.
Im Stand der Technik ist das so genannte eCash-Verfahren bekannt. Dabei transferiert ein Kunde Guthaben von seinem Bankkonto auf sein eCash-Konto. Dabei werden verschlüsselte Dateien mit gewissen Wertespeichern erzeugt, die auf seinem Computer gespeichert werden. Die Verwaltung dieser elektronischen Münzen übernimmt ein spezielles Dienstprogramm, die elektronische Geldbörse (Cyberwallet oder E-Wallet). Beim Einkauf im Internet werden dem Verkäufer dann diese Dateien vom Rechner des Käufers übermittelt. Bei der Bezahlung wird das digitale Zahlungsmittel durch den Verkäufer bzw. die Bank sofort auf Gültigkeit geprüft. Der Verkäufer kann nun den Versand der bestellten Ware oder die Ausführung der entsprechenden Dienstleistung veranlassen.
Zunächst muss ein Kunde bei einer für eCash lizenzierten Bank ein eCash- Konto eröffnen und eine eCash-Software auf seinem Rechner installieren. Das eCash-Konto wird mit einem tatsächlichen Bankkonto verbunden. Die Beladung oder Entladung eines eCash-Kontos kann nur von diesem Bankkonto aus erfolgen. Möchte der Kunde einen Betrag in eCash transferieren, erzeugt die elektronische Geldbörse Dateien in Höhe des gewünschten Betrages. Jeder Datei wird dabei ein bestimmter Wert zugeordnet, der sich nicht mehr verändert. Außerdem erhält sie von der Geldbörse eine Seriennummer. Diese Dateien werden daher auch als elektronische Münzen (Cybercoins) bezeichnet. Die Bank überprüft das Guthaben. Ist es ausreichend, wird jede Datei mit einem Schlüssel der Bank versehen, wobei jeder Schlüssel einem bestimmten Wert entspricht; die entsprechende Summe wird vom echten Bankkonto abgebucht.
Anschließend werden die Dateien an den Kunden, das heißt an die Geldbörse zurückgeschickt. Dieser Vorgang entspricht in etwa dem Aufladen einer Chipkarte an einem Ladeterminal. Die Dateien sind nunmehr sowohl von der Geldbörse mit dem Kundenschlüssel, als auch von der Bank mit deren Schlüssel kodiert. Die Geldbörse entfernt jetzt den von ihr angebrachten Schlüssel. Dieses Verfahren wird Blinding genannt. Durch das Blinding soll die absolute Anonymität gewahrt werden. Jede Datei besteht damit aus der Seriennummer und der Information über den Wert und ist mit dem Schlüssel der Bank verschlüsselt. Beim Ausgeben von eCash schickt der Kunde Dateien, deren Wert dem vom Verkäufer angeforderten Betrag entspricht. Die Bezahlung im Internet mit Hilfe der eCash-Software ist in Echtzeit möglich. Auf Mausklick generiert die Software des Verkäufers eine Zahlungsaufforderung, die er an die Geldbörse des Kunden schickt. Diese lässt den Kunden die Transaktion bestätigen und sendet Dateien in Höhe des gewünschten Betrages an den Verkäufer. Dieser wiederum leitet die elektronischen Münzen an die Bank weiter. Dort wird der Bankschlüssel entfernt, der Wert der Münze wird dem eCash-Konto des Verkäufers gutgeschrieben. Die nun entschlüsselte Seriennummer wird gespeichert.
Die Namensgebung dieser Erfindung vermittelt den Eindruck, dass es sich um Bargeld handelt - obwohl durch die fixe Verbindung des Systems mit einem echten Bankkonto lediglich sogenannte Giraleinlagen in eCash konvertiert werden. Auch der Händler benötigt also für seine Gutschriftbuchung ein eCash- Konto.
Eigentlich entspricht eCash somit eher einer Bankgarantie als einem Bargeldsystem. Auch ist dieses System zwingend buchungsbasiert, dadurch nicht anonym, außerdem in Technik und Anwendung kompliziert. Vor allem wird der Anwender gezwungen, auf seinem Rechner eine besondere Software zu installieren. So konnte sich das eCash-Verfahren nicht am Markt durchsetzen.
Andere Ansätze verfolgen ähnliche Konzepte, wobei die Speicherung des Geldes mit aufwendigen Verschlüsselungsverfahren beim Anwender erfolgt, um sicherzustellen, dass die umfangreichen Sicherheitsanforderungen erfüllt werden:
Ferner ist im Stand der Technik eine elektronische Währung bekannt, die den Namen Bitcoin erhielt. Sie wird dezentral auf der Basis eines Computernetzwerks erzeugt. Bitcoin verbindet Eigenschaften von Bargeld mit solchen von internationalen elektronischen Überweisungen. Das Netzwerk wird gebildet aus den Rechnern aller Teilnehmer, die eine kostenlose Open-Source-Software ausführen. Der Besitz von Geldeinheiten kann durch den Besitz von kryp- tographischen Schlüsseln nachgewiesen werden. Jede Transaktion von Geldeinheiten zwischen Teilnehmern des Netzwerks wird in einer öffentlichen, vom gesamten Netzwerk unterstützten Datenbank aufgezeichnet und mit starken digitalen Signaturen versehen. Dies stellt sicher, dass Geldbeträge nur einmal ausgegeben werden.
Das Konzept wirft wegen seiner neuartigen Verbindung bisher unvereinbarer Eigenschaften rechtliche, wirtschaftliche und technische Fragen auf, die strittig diskutiert werden.
Bitcoin-Einheiten sind durch die Verwendung starker Verschlüsselungsverfahren weitgehend fälschungssicher. Jeder Geldbetrag kann nur einmal ausgegeben werden, weil jegliche Übermittlung von Geld unwiderruflich im Netzwerk verzeichnet wird. Das System verbindet eine relativ schnelle Bestätigung von Transaktionen innerhalb von zehn bis sechzig Minuten mit geringen Kosten pro Transaktion von rund 0,007€. Der Besitz von Geldbeträgen wird durch den Inhalt einer elektronischen Geldbörse nachgewiesen, welche kryptographische Schlüssel enthält. Die Signatur mit diesen Schlüsseln ist Voraussetzung für die Aufnahme einer Transaktion ins netzwerkweite Verzeichnis. Die Schlüssel als solche müssen bei diesem Verfahren nicht offenbart werden. Die Geldbörse muss jedoch gegen Verlust durch Ausspähen und Schadsoftware geschützt werden.
Zahlungen finden an Pseudonyme Adressen statt, welche die Software für jeden Empfänger beliebig neu erzeugen kann. Eine Identifizierung der Handelspartner soll dadurch verhindert werden. Eine vollständige Anonymität garantiert das System nicht, da die Kette aller Transaktionen öffentlich in der Transaktionsgeschichte verzeichnet wird und eine Verknüpfung mit weiteren Informationen prinzipiell möglich ist.
Über die Unterstützung von Bezahlvorgängen hinaus hat Bitcoin den Charakter einer elektronischen Währung. Der Preis der Einheit ergibt sich allein aus dem Angebot an verfügbaren Bitcoins und der Nachfrage derselben beim Handel. Geldeinheiten können ähnlich wie Aktien an Börsen gegen Währungen wie US-Dollar oder Euro gegen Gebot gekauft und verkauft werden. Der Kurs der Währungseinheit unterliegt gelegentlich kräftigen Schwankungen und ist seit dem Start des Systems sehr stark gestiegen.
Die Marktkapitalisierung aller Einheiten beträgt etwas weniger als 100 Millionen US-Dollar (Stand: 22. Juni 2011). Die Menge an Geldeinheiten ist nicht zentral beeinflussbar und hat eine in der Software eingebaute feste Obergrenze. Neue Währungseinheiten können von Teilnehmern des Peer-to- Peer-Netzwerks bei der Aufwendung von Rechenleistung für die Bestätigung und Signatur von Transaktionen verdient werden.
Das Konzept von Bitcoin wurde 2008 in einem Whitepaper von Satoshi Nakamoto vorgeschlagen. Das Konzept anonymen digitalen Geldes, basierend auf asymmetrischen Kryptosystemen wie RSA, ist allerdings seit Jahrzehnten bekannt. Bitcoin basiert auf der weiterführenden Idee einer kryptographischen Währung, die 1998 von Wei Dai als b-money und von Nick Szabo als bit gold beschrieben wurde. Nakamoto, über den nur sehr wenig bekannt ist, hat sich Ende 2010 aus der Entwicklung zurückgezogen. Das Projekt wird von einigen Entwicklern unter der Leitung von Gavin Andresen fortgeführt. Das Softwareprojekt ist in der Open Source-Community verankert. Mehrere der Entwickler, wie beispielsweise Jeff Garzik, sind auch mit Beiträgen am Linux-Kernel beteiligt.
Bitcoin verbindet konzeptgemäß bestimmte Eigenschaften von Uberweisungen mit der Eigenschaft der begrenzten Geldmenge, wie es bei Warengeld der Fall ist. Bitcoin ist mathematisch in der Menge begrenzt, anders als das Warengeld (Kurantgeld), welches durch seinen Materialgehalt (Edelmetallgehalt) begrenzt wird (entsprechend der Menge an abbaubarem Erz). Kurantgeld bemisst sich daher auch durch den reinen Metallwert, ist jedoch nur physisch transportierbar. Bitcoin stellt somit eine neue Form von Geld dar. Die Eigenschaften von Bitcoin leiten sich aus dem verwendeten mathematischen Verfahren ab. Eine Fälschung von Einheiten oder Transaktionen ist durch die verwendeten asymmetrischen kryptographischen Verfahren wegen des erforderlichen zeitlichen und technischen Aufwands ineffizient und deshalb praktisch ausgeschlossen.
Zahlungen können ohne Mitwirkung von Finanzinstituten schnell und kostengünstig direkt zwischen den Beteiligten abgewickelt werden, wodurch die vergleichsweise hohen Gebühren der etablierten Dienstleister umgangen werden. Die Bestätigung einer Transaktion kostet gegenwärtig (abhängig von der Implementation der Client-Software) 0.0005 BTC. Wenn sie freiwillig erhöht wird, beschleunigt sie den Bestätigungsvorgang durch eine höhere Priorität bei der Berechnung durch andere Mitglieder des Netzwerks. Die Gebühr wird demjenigen Netzknoten, welcher die Bestätigungs-Signatur erstellt, gutgeschrieben. Das Verfahren soll insbesondere verhindern, dass das Netzwerk gezielt durch sehr viele sehr kleine Transaktionen überlastet wird. Auf lange Sicht sind diese Transaktionsgebühren als Belohnung für den Erhalt des Netzes durch Bereitstellung von Rechenleistung geplant.
Das System ist aufgrund der Peer-to-Peer-Struktur völlig dezentral, ähnlich Systemen wie BitTorrent. Eine Einflussnahme auf die Geldmenge würde erfordern, dass alle Teilnehmer eine veränderte Software verwenden, da sonst ein nicht allgemein anerkannter Ableger von Protokoll und Zahlungseinheit entstehen würde.
Ein Problem bei der Einführung von Bitcoin als Währung ist die anfängliche Verteilung von Geld. Moderne staatliche und private Währungen sind, im Gegensatz zu Bitcoin, durch ein Zahlungsversprechen der ausgebenden Stelle gedeckt. Da Bitcoin als neues Zahlungsmittel anfangs kein Vertrauen genießt und der Rücktausch von keiner Stelle garantiert wird, hatte es jedoch ursprünglich keinen bezifferbaren Wert. Auch eine Nutzbarkeit war aufgrund der fehlenden Angebote von Waren gegen Tausch der Währung zunächst nicht vorhanden. Aus diesem Grund war es anfangs irrational für Marktteilnehmer, die neuen Währungseinheiten zu kaufen. Im Fall von Bitcoin werden neue Einheiten nach einem Prinzip verteilt, das die Unterstützung des Netzwerks durch zur Verfügung stellen von Rechenleistung belohnt. Aufgrund des steigenden Wertes des Guthabens stellt dies im Fall einer Ausweitung der Nutzung eine hohe Belohnung und somit einen substantiellen Anreiz dar.
Grundsätzlich baut Bitcoin auf der bereits möglichen Anonymität im Internet auf. Damit Transaktionen nicht zuordenbar sind, dürfen weder IP-Adressen noch Bitcoin-Adressen einer Person zugeordnet werden können. Da der Zahlungsempfänger auf irgendeine Weise Kunden erhalten will, muss er zumindest teilweise seine Anonymität aufgeben. Wie im Folgenden genauer beschrieben, sind alle Transaktionen zwischen zwei Adressen öffentlich protokolliert und werden dauerhaft im gesamten Netzwerk gespeichert. Spätere Empfänger von Teilbeträgen können den jeweils letzten Besitzer bei Behörden melden, welche dann die Kette der Transaktionen verfolgen können. Alternativ könnten auch Geräte der Kunden beschlagnahmt oder generell überwacht werden.
Zur Verwendung von Bitcoin muss ein Nutzer zunächst eine Softwareanwendung von der Plattform Sourceforge herunterladen und auf seinem Computer oder Smartphone installieren, den so genannten Bitcoin-Client. Beim Starten verbindet sich das Programm mit dem Internet und lädt alle bisherigen Transaktionen herunter.
Durch Anklicken einer Schaltfläche lassen sich dann Bitcoin- Empfängeradressen generieren. Der als Gegenstück benötigte private Schlüssel zu dieser Adresse wird automatisch in einer Datei mit dem Namen "wallet.dat" gespeichert. Die Empfängeradresse kann man z.B. per E-Mail weitergeben, aber auch benutzen, um sich selbst neu erworbene Bitcoins zuzusenden.
Die Teilnehmer wählen sich mit einem Programm (Client) in das unstrukturierte Peer-to-Peer-Netzwerk ein. Das Programm informiert sich automatisch über alle früheren Überweisungen und erzeugt Adressen für den Zahlungsempfang. Geldüberweisungen finden als Transaktionen zwischen solchen Adressen statt. Diese Adressen stellen die öffentlichen Schlüssel eines asymmetrischen Schlüsselpaars dar. Den öffentlichen Teil gibt jeweils der Zahlungsempfänger dem Absender der Zahlung bekannt. Der private Schlüssel ist nur dem Teilnehmer bekannt, der das Schlüsselpaar erzeugt hat. Dadurch ist sichergestellt, dass nur der Besitzer des privaten Schlüssels eine Transaktion autorisieren kann. Gleichzeitig bedeutet der Verlust des privaten Schlüssels auch den Verlust der dazugehörigen Bitcoins.
Um zu verhindern, dass ein Teilnehmer dieselben Bitcoins mehrfach ausgibt (Double Spending), werden Transaktionen im gesamten Peer-to-Peer-Netz mit dem Flooding-Algorithmus verbreitet.
Die Transaktionen werden dabei zuerst innerhalb des Netzwerks digital signiert, was nicht mit einem privaten Schlüssel erfolgt, sondern die Lösung einer neuen kryptographischen Aufgabe beinhaltet. Die Aufgabe beinhaltet die Umkehrung einer Einwegfunktion: Sie ist nur mit hohem Rechenaufwand zu lösen, aber ihre korrekte Lösung mit viel weniger Aufwand überprüfbar. Wenn ein Client eine solche Aufgabe löst, muss er die Lösung zusammen mit Transaktionen von anderen Clients kryptographisch zu einem Block verknüpfen. Nachdem das gelungen ist, erhält er von den anderen Netzwerkknoten die Anerkennung einer Belohnung in Form einiger neu erzeugter Bitcoins.
Die Menge dieser Belohnungseinheiten ist allerdings beschränkt. Bitcoin verwendet zur Signierung von Daten das Elliptische-Kurven-Kryptosystem ECDSA in der 256-Bit-Konfiguration secp256kl.
Der nun im System veröffentlichte Block legt die in ihm enthaltenen Transaktionen verbindlich fest. Er wird bei der Signatur zusätzlich mit anderen Blöcken verkettet, das heißt, das System arbeitet ähnlich wie eine große Gruppe von Notaren, die immer wieder gegenseitig ihre Unterschriften unter einer Folge von Dokumenten prüfen und mit weiteren Unterschriften bestätigen.
Da die Blockkette und die bestätigten Transaktionen öffentlich einsehbar sind, ist Bitcoin nicht vollständig anonym. Gibt ein Benutzer seine Adresse bekannt, so kann man sämtliche Transaktionen dieser Adresse nachverfolgen. Um die Rückverfolgbarkeit einzuschränken, unterstützt Bitcoin den Umgang mit mehreren Adressen in einer elektronischen Geldbörse, dem Wallet.
Das schon erwähnte Lösen von rechenaufwendigen kryptographischen Aufgaben nennt man Mining. Durch dieses beteiligen sich die Clients an der Erzeugung neuer Bitcoins und führen somit auch die Geldschöpfung dezentral durch.
Die Aufgaben werden so ausgelegt, dass im Schnitt alle 10 Minuten ein zufälliger Client, der am Mining beteiligt ist, als erstes eine Lösung findet. Die Wahrscheinlichkeit eines Teilnehmers, die richtige Lösung zu finden, ist proportional zu der eingesetzten Rechenleistung. Alle zwei Wochen passen die Clients den Schwierigkeitsgrad der Aufgaben an, damit das System trotz gestiegener oder gesunkener Gesamtrechenleistung weiterhin im Schnitt alle 10 Minuten zu einer Aufgabe eine Lösung findet.
Lösungen, die dem aktuellen Schwierigkeitsgrad nicht entsprechen, werden von anderen Clients nicht akzeptiert. Ein Client, der eine Aufgabe löst, erzeugt derzeit 50 BTC. Die Anzahl der erzeugten Bitcoins halbiert sich alle vier Jahre, sodass es maximal ca. 21 Millionen Bitcoins geben kann, von denen bis Anfang Juni 2011 etwa 6,4 Mio. erzeugt worden sind.
Als Anreiz für den Erzeuger eines Blocks, eine fremde Transaktion zu bestätigen, kann der Überweisungssender zusätzlich eine Transaktionsgebühr an ihn zahlen. Durch die Transaktionsgebühr soll auch dann ein Anreiz bestehen, kryptographische Aufgaben zu lösen und somit Blöcke zu erzeugen, wenn die geplante Menge an Einheiten erreicht wird und keine neuen Bitcoins mehr erzeugt werden können. Des Weiteren soll durch die Transaktionsgebühr die Anzahl an Transaktionen entsprechend der Kapazität geregelt werden.
Zwar wird Bitcoin gerne als elektronisches Bargeld bezeichnet, jedoch kann es nicht als Geld betrachtet werden, da es nicht von einer staatlich autorisierten Stelle mit Rücknahmegarantie emittiert wird. Außerdem benötigt man auch für die Verwendung von Bitcoin eine Software, die auf dem Rechner des Anwenders installiert werden muss. Zudem garantiert Bitcoin nicht die erwünschte Anonymität, da jede einzelne stattfindende Zahlungstransaktion für alle Teilnehmer des Bitcoin-Netzwerks offen einsehbar und rückverfolgbar ist.
Ein weiteres Projekt, welches bargeldähnliche Zahlungen ohne Internetverbindung des Kunden ermöglicht, hat den Namen Bitbills. Diese bestehen aus Plastikkarten im ISO 7810 Format, die ein Bitcoin-Adressen Schlüsselpaar mit Beträgen zwischen 1 und 20 BTC enthalten. Auf der Rückseite ist der öffentliche Schlüssel aufgedruckt. Der nominale Betrag der Karten wird durch eine Zahlung an diese Adresse auf die Karte geladen. Der auf der Karte tatsächlich vorhandene Betrag kann jederzeit auf der Webseite blockexplo- rer.com angezegeigt werden, welche die öffentliche Block-Kette auswertet. Der geheime Schlüssel befindet sich verdeckt unter einem Hologramm, welches auf der Vorderseite aufgeklebt ist. Die Entfernung des Hologramms legt den Schlüssel frei und zerstört die Karte. Die Karte ist nur so lange gültig, wie das Hologramm intakt ist. Wenn man den Betrag auf der Karte einlösen möchte, muss man das Hologramm entfernen und den geheimen Schlüssel in ein Bitcoin Wallet importieren. Die Kosten für die Karte selbst betrugen Anfang Juli 2011 zwischen 0.30 und 0.70 BTC (zwischen 4,50 und 10.5 USD).
Bei Bitbills handelt es sich um eine Kombination aus Guthabenkarte und Bitcoin mit den oben bereits erwähnten Nachteilen.
Aus der gattungsgemäßen DE 10 2009 034 436 AI ist ein Verfahren zum Bezahlen mit geldwerten Beträgen in Form elektronischer Datensätze bekannt. Der Zahlungspflichtige besitzt einen ersten Datensatz, wobei der Zahlungspflichtige diesen ersten Datensatz von einer zentralen Instanz - beispielsweise einem Geldinstitut - erhalten hat. Der erste Datensatz enthält einen Zahlungsmittelschlüssel und einen Datensatzwert, wobei der Datensatzwert einem auf einem Kontokorrentkonto gutschreibbaren Geldwert entspricht. Der Datensatz enthält ferner Identifizierungsdaten des Zahlungspflichtigen bzw. Besitzers sowie eine Signatur, wobei die Signatur von der zentralen Instanz, nämlich dem Geldinstitut erzeugt wird. Der Zahlungspflichtige kann diesen ersten Datensatz an einen Zahlungsempfänger versenden. Der Zahlungsempfänger verifiziert anhand der Identifizierungsdaten, dass der erste Datensatz vom Zahlungsempfänger stammt. Danach muss der Zahlungsempfänger einen zweiten Datensatz mit dem Datensatzcode erstellen, wobei der zweite Datensatz die Identifizierungsdaten des Zahlungsempfängers enthält. Der Zahlungsempfänger muss nun den zweiten Datensatz an das Geldinstitut übertragen. Das Geldinstitut überprüft zum einen die Identifizierungsdaten des zweiten Datensatzes und zum anderen, ob das Zahlungsmittel gültig ist. Falls der Datensatzcode gültig ist, dann erstellt das Geldinstitut eine Signatur über den zweiten Datensatz. Der signierte zweite Datensatz wird vom Geldinstitut an den Zahlungsempfänger übertragen. Bei diesem Verfahren wird ein Datensatz durch einen neuen Datensatz ersetzt, wobei der alte Datensatz für ungültig erklärt wird. Auch dieses Verfahren bezieht sich aber nicht auf elektronisches Bargeld, sondern auf ein kontengebundenes Zahlungsverfahren. Dieses Verfahren benötigt eine Vielzahl von Transaktionen und ist umständlich.
Im Gegensatz zu kontobasierten Systemen handelt es sich bei elektronischen Bargeldsystemen um IT-Objekte, so genannte eToken, die alle notwendigen Informationen einschließlich ihres Wertes in sich tragen. Besonderes Augenmerk gilt den kryptografischen Protokollen und Algorithmen, die im Rahmen einer Ausgestaltung von ePayment-Systemen sowohl zur Absicherung des Zahlungsverkehrssystems selbst, als auch zur Sicherung einzelner Transaktionen zur Anwendung kommen. Ihre Sicherheit und Robustheit entscheidet über den praktischen Nutzen solcher Systeme. Viele existierende Verfahren zur Realisierung bedingter Anonymität basieren auf dem Prinzip der blinden Chiffren (Schnorr Signatur, blinder ElGamal, Blinding von David Chaum) in Kombination mit dem so genannten Secret Splitting, um bei einer mehrfachen Verwendung (Multiple Spending) von eToken die ursprünglich gewährte Anonymität aufheben zu können. Damit sind nun aber erhebliche Nachteile verbunden, wie beispielsweise die nicht mehr vorhandene Mehrfachverwendungsfähigkeit der eingesetzten unveränderten eTokens. Um diesen wesentlichen Taxonomy-Faktor zu erhalten, wird in der Literatur vorgeschlagen, Verfahren einzusetzen, die statistische Methoden zur Erkennung systematischer Falschgeld-Transitionen verwenden.
Zahlungsabwicklungen mit physischem Bargeld finden in aller Regel in persönlicher Anwesenheit der Beteiligten statt, wobei die einzelnen Schritte des Vorgangs Zug um Zug in rascher zeitlicher Abfolge abgewickelt werden. Dabei kommt dem Echtzeitmoment eine fundamentale Bedeutung zu. Treten beim Zahlungsprozess Störungen auf, hat die Partei, die sich benachteiligt fühlt, die Möglichkeit zu reklamieren und notfalls einzuschreiten. Dieses Repertoire vermittelt den Beteiligten ein Gefühl der Handlungsfähigkeit und damit der Sicherheit. Elektronische Barzahlungsverfahren im Stand der Technik berücksichtigen diese Situation nicht.
So ist aus der im Jahre 2000 veröffentlichten DE 1 985 995 9 A ein Verfahren für einen Geld- oder Vermögenstransfer und Geld- oder Vermögenseinheiten dafür bekannt, wobei das Verfahren keine Erhebung personenbezogener Daten erfordert. Der Zahlungspflichtige erhält von einer Bank beispielsweise per Post eine Karte, wobei auf der Karte ein Identifizierungscode bzw. Zahlungsmittelschlüssel aufgedruckt ist. Der Identifizierungscode bzw. Zahlungsmittelschlüssel ist von einer Deckschicht verborgen und kann durch Abrubbeln der Deckschicht freigelegt werden. Dabei hat aber der Zahlungspflichtige auf elektronischem Wege zunächst den Zahlungsempfänger zu kontaktieren. Der Zahlungspflichtige schickt den Identifizierungscode auf elektronischem Wege beispielsweise per E-Mail als Zahlungsangebot. Die übergebenen Informationen enthalten dabei alle Daten, die der Empfänger benötigt, um im nächsten Schritt über eine Vermittlungsstelle beispielsweise die Bank das Zahlungsmittel in seine endgültige Verfügungsgewalt zu bringen. Der Zahlungsempfänger muss nun die Deckung des Zahlungsangebotes bzw. die Gültigkeit des Identifizierungscodes durch Eingabe des Identifizierungscodes bei einer Bank prüfen.
Das Senden des Sicherheitscodes vom Zahlungspflichtigen an den Zahlungsempfänger stellt eine Sicherheitslücke dar, die das Verfahren in der Praxis unbrauchbar macht. Zwar kann die Verbindung zur Bank/Vermittlungsstelle zwingend abhörsicher ausgelegt werden. Der Zahlungspflichtige und der Zahlungsempfänger können aber nicht gezwungen werden, ebenfalls abhörsichere Verfahren für die Datenübertragung untereinander zu gebrauchen. Wird diese Datenübertragung aber von einem Unbefugten belauscht, kann er sich, wenn er dem Berechtigten bei der Vermittlungsstelle zeitlich zuvorkommt, das Zahlungsmittel widerrechthch aneignen.
Zudem beschränkt sich der Zahlungsvorgang nicht auf eine Transaktion zwischen dem Zahlungspflichtigen und dem Zahlungsempfänger. Nach Entgegennahme des Zahlungsmittels hat der Zahlungsempfänger erst noch eine Vermittlungsstelle aufzusuchen, die die Gültigkeit des Zahlungsmittels überprüft. Die Einschaltung dieser dritten Partei unterbricht die Interaktion zwischen dem Zahlungspflichtigen und dem Zahlungsempfänger für eine nicht absehbare Zeitspanne. Ein flüssiger Ablauf des Zahlungsprozesses in Echtzeit, wie er aus der Zahlung mit physischem Bargeld bekannt ist, wird auf diesem Wege nicht erreicht.
Mit zunehmender Verbreitung mobiler Telefonie wurden auch Verfahren beschrieben, die das Bezahlen mit dem Mobiltelefon ermöglichen. http://www.mgovernment.org/resurces/euromgov2005 PDF/29_S049HK-S04.pdf offenbart ein System, das eine Core-Protokoll-Ebene in Verbindung mit einer speziellen Hardwarefunktionalität enthält, die in einer anwendungsspezifisch programmierbaren, integrierten Schaltung realisierbar ist. Durch deren Kombination mit signierten elektronischen Münzen, diversen Zertifikatsdiensten und dem digitalen Portmonee lässt sich daraus ein elektronisches Bargeldsystem konzipieren. Es erfordert allerdings ein eigenes Übertragungsprotokoll, das erst noch zu standardisieren und einzuführen wäre, und spezielle, zu verbreitende Hardwarekomponenten.
Gegenwärtig existiert eine wachsende Anzahl von Systemen, die den Zugang zum Internet und den darauf basierenden Diensten ermöglichen. Unter verschiedenen Betriebssystemen werden neben den Klassikern immer neue Web-Browser entwickelt, für die regelmäßig neue Versionen veröffentlicht werden. Dabei gelang es bislang lediglich, Mindeststandards stringent durchzusetzen.
Uber den Erfolg oder Misserfolg von Problemlösungen für das Internet und dessen Dienste entscheidet in letzter Konsequenz in aller Regel die Anwenderfreundlichkeit. Umständliche oder schwer nachvollziehbare Angebote werden erfahrungsgemäß vom Internet-Benutzer nicht angenommen, während einfach konzipierte und verständlich dargebotene Applikationen gerne aufgegriffen und sogar an andere Nutzer weiterempfohlen werden. Zahlreiche Anwender lehnen neue Systeme mit der Begründung ab, dass ihnen die Installation notwendiger Software lästig sei bzw. neue, unerwünschte Sicherheitsrisiken in sich berge.
Geld verkörpert Kaufkraft, die auf den ersten Blick in einem unbestechlichen Zahlenwert ausgedrückt ist. Diese gezielt rationale Eigenschaft steht aber in der Regel in einem auffälligen Kontrast zum emotionalen Verhältnis seines Besitzers. Werte wie Sicherheit, Vertrauen und Zuverlässigkeit spielen dabei eine dominante Rolle. Das menschliche Kontrollbedürfnis verlangt nach Transparenz über den Verbleib und den Bestand des verfügbaren Geldes. Darüber hinaus erzeugen Unsicherheit und Verlustängste unweigerlich Unbehagen.
Elektronisches Geld, das von der Installation individueller Softwareelemente abhängt, würde wegen der verbreiteten Systemvielfalt unvermeidbar von einem nicht zu vernachlässigenden Teil der vorhandenen Systeme als solches nicht erkannt werden können. Dadurch wird der Anwender zwangsläufig verunsichert. Muss er um sein Geld bangen, wird sein Vertrauen in das Zahlungsmittel erschüttert.
Daher sind die im Stand der Technik bekannten Verfahren noch nicht optimal ausgebildet. Im Stand der Technik ist kein sicheres Verfahren und zugehöriges elektronisches Zahlungsmittel bekannt, das sich für das Internet eignet und eine ähnlich unkomplizierte und anonyme Zahlung wie mit Bargeld ermöglicht, ohne dass dafür spezifische Hardwarekomponenten eingeführt oder Softwareprogramme verbreitet werden müssen. Die Aufgabenstellung gestaltet sich vor allem deshalb so schwierig, weil die zentrale Schwachstelle bei elektronischem Bargeld in der Gefahr einer missbräuchlichen Vervielfältigung besteht.
Der Erfindung liegt daher die Aufgabe zu Grunde, ein Verfahren zur Bezahlung mit mindestens einem gültigen, elektronischen Zahlungsmittelschlüssel derart weiterzubilden und auszugestalten, dass das Verfahren sich einerseits für den digitalen Raum eignet, andererseits aber eine lückenlose Rückverfolgung des Zahlungswegs ausschließt und gleichzeitig für den Anwender einfach zu handhaben ist.
Diese Aufgabe wird erfindungsgemäß durch ein Verfahren zur Bezahlung mit mindestens einem elektronischen Zahlungsmittelschlüssel gelöst, wobei auf einem Serversystem mindestens ein Zahlungsmittelverifizierungsdatensatz mit einem Zahlungswert und mit einem Verifizierungsschlüssel gespeichert ist, wobei jedem gültigen Zahlungsmittelschlüssel mindestens ein
Zahlungsmittelverifizierungsdatensatz zugeordnet ist, wobei der
Zahlungsmittelschlüssel an einem Speicherort gespeichert ist, wobei der
Speicherort einem Zahlungspflichtigen zur Verfügung steht, mit den folgenden Schritten:
+ 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.
Der Zahlungsmittelverifizierungsdatensatz kann jeweils eine oder mehrere Verzeichnisse und/oder Dateien und/oder Datensätze und/oder Verknüpfungen aufweisen. Das Serversystem mit dem Zahlungsmittelverifizierungsdatensatz unterliegt der Verfügungsgewalt des oder der Emittenten. Emittent kann ein Geldinstitut sein. Der Zahlungsmittelverifizierungsdatensatz wird auf einem oder mehreren Servern zentral verwaltet. Der
Zahlungsmittelverifizierungsdatensatz weist mindestens einen eindeutigen Verifizierungsschlüssel auf. Der Verifizierungsschlüssel ist vorzugsweise nach dem Zufallszahlenprinzip ermittelt.
Der Zahlungsmittelschlüssel bildet eine Referenz auf den Zahlungsmittelverifizierungsdatensatz. Diese Referenz kann eindeutig sein, das heißt jedem Zahlungsmittelschlüssel ist genau ein
Zahlungsmittelverifizierungsdatensatz zugeordnet. Es können jedoch alternativ einem Zahlungsmittelschlüssel mehrere
Zahlungsmittelverifizierungsdatensätze zugeordnet sein. Der
Zahlungsmittelschlüssel dient dabei als Autorisierungsmittel.
Unter Referenz werden alle Möglichkeiten der Bezugnahme verstanden. Eine Referenz kann in der bloßen Identität einer einmalig vergebenen Zeichenfolge bestehen, aber auch in einem Verweis, einer Verlinkung, einer Verknüpfung oder irgendeiner anderen Form der Referenzierung.
Der Zahlungsmittelschlüssel kann insbesondere eine oder mehrere Dateien, Datensätze, Verknüpfungen und/oder Verzeichnissen aufweisen bzw. aus diesen bestehen. Der Zahlungsmittelschlüssel unterhegt der Verfügungsgewalt des Inhabers, d.h. zu Beginn des Verfahrens unterliegt der Zahlungsmittelschlüssel der Verfügungsgewalt des Zahlungspflichtigen und am Ende des Verfahrens der Verfügungsgewalt des Zahlungsempfängers.
Der Zahlungsmittelschlüssel ist zu Beginn an einem Speicherort des Zahlungspflichtigen gespeichert und insbesondere einer
Datenverarbeitungsanlage des Zahlungspflichtigen bzw. des Zahlungsempfängers zugeordnet. Diese Datenverarbeitungsanlagen können als Personal Computer, Laptop, Smartphone, Handy oder dergleichen ausgebildet sein. Der Zahlungsmittelschlüssel ist dabei am Speicherort auf einem Speichermittel, beispielsweise einer Festplatte, einem USB-Stick, einer CD einer DVD oder dgl., der Datenverarbeitungsanlage gespeichert. Diese Datenverarbeitungsanlagen können auch als Client bezeichnet werden.
Der Zahlungsmittelschlüssel stimmt insbesondere mit dem zugehörigen Verifizierungsschlüssel des serverseitigen
Zahlungsmittelverifizierungsdatensatzes identisch überein oder ist vorzugsweise über eine entsprechende Funktion dem Verifizierungsschlüssel zuordenbar, sofern der Zahlungsmittelschlüssel gültig ist. Durch Uberprüfung der Zuordenbarkeit des Zahlungsmittelschlüssels zu den Verifizierungsschlüssel(n) wird überprüft, ob der Zahlungsmittelschlüssel gültig oder ungültig ist. Wenn beispielsweise ein
Zahlungsmittelverifizierungsdatensatz mit einem dem Zahlungsmittelschlüssel zugeordneten Verifizierungsschlüssel existiert, dann ist der Zahlungsmittelschlüssel gültig. Wenn kein zugehöriger
Zahlungsmittelverifizierungsdatensatz existiert, dann ist der Zahlungsmittelschlüssel ungültig.
Das Verfahren weist eine insbesondere von einem Serversystem bereitgestellte Funktion zur Abbildung des Bezahlvorganges auf. Diese Funktion und das Serversystem stehen insbesondere unter der Verfügungsgewalt des Emittenten.
Der Zahlungsempfänger und der Zahlungspflichtige bauen eine Verbindung mit dem Serversystem auf. Die Verbindung zum Serversystem kann insbesondere über eine Internetverbindung aufgebaut werden. Der Verbindungsaufbau mit dem Serversystem erfolgt vorzugsweise über eine verschlüsselte Verbindung. Nach dem Verbindungsaufbau erfolgt eine Zuordnung des Zahlungspflichtigen und des Zahlungsempfängers. Das Serversystem stellt insbesondere einer Vielzahl von Personen die entsprechenden Bezahlvorgänge zur Verfügung.
Durch den Zahlungsempfänger wird ein neuer Bezahlvorgang auf dem Serversystem gestartet. Der Bezahlvorgang wird dem Zahlungspflichtigen und dem Zahlungsempfänger quasi-synchron dargestellt. Diese Darstellung erfolgt zum einen über die Verbindung zwischen der Datenverarbeitungsanlage des Zahlungsempfängers und dem Serversystem und zum anderen über die Verbindung zwischen der Datenverarbeitungsanlage des Zahlungspflichtigen und dem Serversystem. Da unterschiedliche Verbindungen genutzt werden, kann die Darstellung als quasi-synchron bezeichnet werden.
Diesem Bezahlvorgang ist insbesondere ein Identifikationsmerkmal zugewiesen, beispielsweise eine eindeutige Nummer. Das Starten des Bezahlvorgangs wird dem verbundenen Zahlungspflichtigen angezeigt. Von dem Zahlungspflichtigem wird der Bezahlvorgang auf dem Serversystem ausgewählt. Insbesondere kann der Zahlungsempfänger dem Zahlungspflichtigen das Identifikationsmerkmal mitteilen, damit der Zahlungspflichtige den gewünschten Bezahlvorgang auswählen kann.
Das Identifikationsmerkmal kann über eine optoelektronische Schnittstelle, insbesondere mittels eines Strichcodes, dargestellt werden, wobei zumindest die Internetadresse des Serversystems mit dem zugehörigen Bezahlvorgang übermittelt wird. Der Strichcode kann weitere Informationen enthalten.
Der Zahlungsempfänger kann dem Zahlungspflichtigen den Strichcode, insbesondere einen QR-Code bereitstellen, wobei der QR-Code unter anderem das Identifikationsmerkmal enthält. Das Identifikationsmerkmal wird dem Zahlungspflichtigen als QR-Code dargestellt, wobei der QR-Code eine Internetadresse des Serversystems mit dem zugehörigen Bezahlvorgang aufweist. Der Zahlungspflichtige kann den beispielsweise in einem Geschäft an der Kasse abgebildeten QR-Code mit seinem Smartphone - d.h. seiner Datenverarbeitungsanlage - optoelektronisch einlesen und wird mit seinem Smartphone mit der entsprechenden Internetadresse des Serversystems mit dem zugehörigen Bezahlvorgang verbunden.
Ferner kann das Identifikationsmerkmal über eine drahtlose Schnittstelle übermittelt werden. Das Identifikationsmerkmal kann über eine Funkschnittstelle übermittelt werden, insbesondere über Near Field Communication (NFC), wobei zumindest die Internetadresse des Serversystems mit dem zugehörigen Bezahlvorgang übermittelt wird.
Der Bezahlvorgang kann den Beteiligten als das Erstellen und Auswählen einer „Kasse" dargestellt werden. Es bieten sich hierzu jedoch auch andere Bezeichnungen und Darstellungen, wie „Transaktion", „Bezahlvorgang" und dgl. an.
Dass der Zahlungspflichtige dem Bezahlvorgang beigetreten ist, wird dem Zahlungsempfänger angezeigt. Dass der Zahlungsempfänger dem Bezahlvorgang ebenfalls beigetreten ist, wird dem Zahlungspflichtigen angezeigt.
Der zu zahlende Betrag wird durch den Zahlungsempfänger bereitgestellt bzw. eingegeben und dem Zahlungspflichtigen angezeigt. Danach erhält der Zahlungspflichtige die Möglichkeit, den geforderten Betrag zu bezahlen. Hierzu wird der Zahlungsmittelschlüssel von der Datenverarbeitungsanlage des Zahlungspflichtigen auf das Serversystem übermittelt.
Der Zahlungsmittelschlüssel kann beispielsweise aus einer Datei bestehen oder in einer Datei mit weiteren Informationen enthalten sein. Die Datei ist insbesondere als Bild-Datei ausgebildet, wobei der Zahlungsmittelschlüssel in den Metadaten, insbesondere einem Kommentarsegment der Bilddatei, gespeichert ist. Diese Datei bzw. der Zahlungsmittelschlüssel wird von dem Zahlungspflichtigen auf das Serversystem übermittelt bzw. hochgeladen.
Alternativ kann der Zahlungsmittelschlüssel steganographisch in eine Datei eingebettet werden. Der Zahlungsmittelschlüssel ist dabei verborgen in der Datei gespeichert. Die Datei enthält dabei offensichtliche Informationen, beispielsweise einen Text und/oder Bild- und/oder Audio-Informationen, wobei in diesen offensichtlichen Informationen der Zahlungsmittelschlüssel verborgen ist. Die offensichtlichen Informationen dienen als Träger des verborgenen Zahlungsmittelschlüssels. Die offensichtlichen Informationen weisen ein Signal und ein Rauschen auf, wobei der Zahlungsmittelschlüssel im Rauschen verborgen enthalten ist.
Ferner kann der Zahlungsmittelschlüssel als digitales Wasserzeichen in einer Datei eingebettet werden. Digitale Wasserzeichen haben mit der Steganographie gemein, dass eine öffentliche Information als Träger verwendet wird, wobei das Wasserzeichen in die öffentliche Information eingebettet wird. Das digitale Wasserzeichen ist insbesondere robust. Der Zahlungsmittelschlüssel kann nicht unbemerkt aus der Datei entfernt werden. Das Wasserzeichen sollte auch nicht durch Umwandeln in ein anderes Dateiformat zerstört werden.
Der Zahlungsmittelschlüssel kann alternativ in einer Datei enthalten sein, wobei die Datei zusätzlich ein digitales Wasserzeichen aufweist. Das Wasserzeichen kann dazu dienen die Datei als Wertgegenstand zu kennzeichnen.
Der Zahlungsmittelschlüssel wird dann auf Gültigkeit überprüft. Dazu wird auf einen zugehörigen Zahlungsmittelverifizierungsdatensatz zugegriffen. Der Zahlungsmittelverifizierungsdatensatz enthält dazu ebenfalls einen Schlüssel, nämlich einen Verifizierungsschlüssel. Es gibt nun unterschiedliche Möglichkeiten, wie auf dem Serversystem die Gültigkeit des Zahlungsmittelschlüssels gespeichert und überprüft werden kann. Insbesondere kann jeder Zahlungsmittelschlüssel ein Zahlungsmittel-
Identifikationsmerkmal, beispielsweise eine Seriennummer aufweisen. Dieses Zahlungsmittehdentifikationsmerkmal kann Teil des Zahlungsmittelschlüssels und des Verifizierungsschlüssels sein oder in einem separaten Datenfeld abgespeichert sein. Im Zahlungsmittelverifikationsdatensatz mit dem identischen Identifikationsmerkmal ist nun der Verifizierungsschlüssel gespeichert. Es wird überprüft, ob der Verifizierungsschlüssel des Zahlungsmittelverifikationsdatensatzes und der Zahlungsmittelschlüssel zuordenbar sind. Der Zahlungsmittelschlüssel ist gültig, wenn die beiden Schlüssel übereinstimmen oder über eine eindeutige Funktion der Zahlungsmittelschlüssel auf den Verifizierungsschlüssel abbildbar ist, ansonsten ist der Zahlungsmittelschlüssel ungültig. In einer bevorzugten Ausgestaltung erfolgt die eindeutige Zuordnung des Zahlungsmittelschlüssels über die eindeutige Funktion. Die beiden Schlüssel müssen daher nicht identisch sein, damit der Zahlungsmittelschlüssel gültig ist. Diese Funktion kann beispielsweise eine Verschlüsselung umfassen. Die Sicherheit des Verfahrens ist dadurch erhöht.
Es ist möglich, dass einem Zahlungsmittelschlüssel mehrere Zahlungsmittelverifizierungsdatensätze zugeordnet sind. Diese Zahlungsmittelverifizierungsdatensätze weisen dabei vzw. den gleichen Verifizierungsschlüssel auf. Der Zahlungspflichtige kann dann durch Übermittlung eines Zahlungsmittelschlüssels auf mehrere Zahlungsmittelverifizierungsdatensätze zum Zwecke der Bezahlung zugreifen. Übermittelt der Zahlungspflichtige einen Zahlungsmittelschlüssel mit mehreren zugeordneten Zahlungsmittelverifizierungsdatensätzen, so werden nur diejenigen Verifizierungsschlüssel geändert oder gelöscht, welche zur Bezahlung des durch den Zahlungsempfänger geforderten Betrages erforderlich sind.
Wenn der Zahlungsmittelschlüssel ungültig ist, dann wird angezeigt, dass der Zahlungsmittelschlüssel ungültig ist. Der Betrag kann nicht mit einem ungültigen Zahlungsmittelschlüssel getilgt werden.
Wenn der übermittelte und danach überprüfte Zahlungsmittelschlüssel gültig ist, dann wird der Verifizierungsschlüssel geändert oder gelöscht. Wenn der Verifizierungsschlüssel gelöscht wurde, wird ein neuer Verifizierungsschlüssel erstellt. Ferner wird ein neuer Zahlungsmittelschlüssel erstellt, wobei der neue Zahlungsmittelschlüssel dem neuen bzw. geänderten Verifizierungsschlüssel zugeordnet ist. Insbesondere ist der Zahlungsmittelschlüssel mittels der Funktion dem Verifizierungsschlüssel zuordenbar.
Der neue oder geänderte Verifizierungsschlüssel wird vorzugsweise durch eine Zufallszahl erzeugt. Der Zahlenraum ist hinreichend groß, aus dem die Zufallszahl stammt, so dass mit der nötigen Wahrscheinlichkeit ausgeschlossen werden kann, dass der Zahlungsmittelschlüssel durch Ausprobieren von Kombinationen erraten werden kann. Der neue Zahlungsmittelschlüssel wird in einer Ausgestaltung vom Serversystem erstellt und vom Serversystem an den Zahlungsempfänger übermittelt.
Durch das Ändern des Verifizierungsschlüssels wird ein neuer Zahlungsmittelschlüssel erstellt. Alle Kopien des ursprünglichen Zahlungsmittelsschlüssels werden in Zukunft nicht mehr als gültig angenommen, da der Verifizierungsschlüssel geändert worden ist. Es ist denkbar, dass der neue Zahlungsmittelschlüssel ein neues Zahlungsmittelidentifikationsmerkmal erhält oder dass der neue Zahlungsmittelschlüssel das Zahlungsmittelidentifikationsmerkmal des ursprünglichen Zahlungsmittelschlüssels behält.
Durch die Ersetzung des Verifikationsschlüssels wird die Fälschungssicherheit des Zahlungsmittelschlüssels gewährleistet. Sobald ein Zahlungsempfänger ein Exemplar des Zahlungsmittelschlüssels erhält, verfügt der Zahlungsempfänger nicht über die Kenntnis darüber, in wie vielen Ausfertigungen dieses Exemplar mittlerweile vorliegt. Beispielsweise könnte es von einem Vorinhaber - dem Zahlungspflichtigen - vielfach dupliziert worden sein und so zu Zahlungszwecken parallel an etliche andere Zahlungsempfänger weitergegeben worden sein. Es besitzt jedoch nur der neue Zahlungsmittelschlüssel Gültigkeit.
Andernfalls würde der Zahlungsmittelschlüssel eine unkontrollierte Vermehrung und damit eine inflationäre Entwertung der Geldmenge herbeiführen. Sobald aber der Zahlungsempfänger den neuen Zahlungsmittelschlüssel über das Serversystem bzw. dem Bezahlvorgang vom Zahlungspflichtigen erhält bzw. sobald der Zahlungsempfänger einen neuen Zahlungsmittelschlüssel vorgeschlagen hat und dieser neue Zahlungsmittelschlüssel vom Serversystem akzeptiert wurde, wurde der Verifizierungsschlüssel geändert und damit werden alle Kopien des alten Zahlungsmittelschlüssels ungültig. Von dem neuen Exemplar des Zahlungsmittelsschlüssels kann der Zahlungsempfänger sicher sein, dass nur er als Zahlungsempfänger diesen neuen Zahlungsmittelschlüssel besitzt. Nur der Zahlungsempfänger bestimmt darüber, wie viele Duplikate er von dem neuen Zahlungsmittelschlüssel anfertigt.
Der neue Zahlungsmittelschlüssel wird in einer Ausgestaltung nun vom Serversystem an den Zahlungsempfänger übermittelt. Dies kann dadurch realisiert werden, dass der Zahlungsempfänger den Zahlungsmittelschlüssel in Form einer Datei herunterladen kann. Der neue Zahlungsmittelschlüssel enthält dabei den geänderten Zahlungsmittelschlüssel. Der geänderte oder neue Zahlungsmittelschlüssel wird dann an einem dem Zahlungsempfänger zur Verfügung stehenden, weiteren Speicherort gespeichert.
Beim Erstellen des neuen Zahlungsmittelschlüssels kann in alternativer Ausgestaltung der neue Zahlungsmittelschlüssel vom Zahlungsempfänger vorgeschlagen werden. Der neue Zahlungsmittelschlüssel wird von der Datenverarbeitungsanlage des Zahlungsempfängers an das Serversystem übermittelt, wobei der Zahlungsmittelschlüssel über die Funktion in einen neuen Verifizierungsschlüssel umgewandelt und auf dem Serversystem gespeichert wird. Der geänderte oder neue Zahlungsmittelschlüssel kann bereits an einem dem Zahlungsempfänger zur Verfügung stehenden, weiteren Speicherort gespeichert sein oder falls dies noch nicht der Fall ist, kann der geänderte oder neue Zahlungsmittelschlüssel dann an einem dem Zahlungsempfänger zur Verfügung stehenden, weiteren Speicherort gespeichert werden.
Der Zahlungsmittelschlüssel kann mit einer Bild-, einer Audio- und/oder einer Videoinformation verknüpft sein. Dies kann dadurch realisiert sein, dass eine Bild-, eine Audio- und/oder eine Videoinformation in einer Datei in einem Dateiformat mit zusätzlichen Metadaten, beispielsweise mit mindestens einem Kommentarsegment, gespeichert ist, wobei der oder die Zahlungsmittelschlüssel in den Metadaten bzw. in dem oder in den Kommentarsegmenten der Datei hinterlegt ist/sind.
Alternativ kann der Zahlungsmittelschlüssel des Zahlungspflichtigen und/oder des Zahlungsempfängers eine Bild-, eine Audio- und/oder eine Videoinformation aufweisen. D.h. der Zahlungsmittelschlüssel umfasst die Bild-, eine Audio- und/oder eine Videoinformation und gegebenenfalls weitere Informationen.
Dem Zahlungsempfänger wird der Eingang des neuen Zahlungsmittelschlüssels durch Darstellung eines Geldmittels, insbesondere einer Münze oder einer Banknote dargestellt. Herkömmliches Geld in physischer Form von Münzen oder Banknoten ist bekanntlich im täglichen Gebrauch der permanenten Gefahr ausgesetzt, verloren, verlegt oder entwendet zu werden. Beim elektronischen Zahlungsmittelschlüssel nach der vorliegenden Erfindung dagegen kann diesem Risiko dadurch vorgebeugt werden, dass der Inhaber jedes Exemplar des Zahlungsmittelsschlüssels in mehrfacher Ausfertigung an unterschiedlichen Orten deponiert. Kommt ihm nun eine Ausfertigung abhanden, kann er auf eine andere zurückgreifen.
Die Schritte des Bezahl Vorgangs werden sowohl dem Zahlungspflichtigen als auch dem Zahlungsempfänger im Wesentlichen gleichzeitig dargestellt. Die Darstellung erfolgt insbesondere quasi-synchron. Der Zahlungsempfänger und der Zahlungspflichtige sind mit dem Serversystem insbesondere über eine Internet- Verbindung verbunden. Zur Darstellung des Bezahlvorganges können die bekannten Übertragungsprotokolle benutzt werden, so dass keine zusätzliche Software auf den Datenverarbeitungsanlagen des Zahlungsempfängers und/oder des Zahlungspflichtigen installiert werden muss.
Die gegenwärtig vor allem im Internet üblichen elektronischen Zahlungsmethoden werden über Buchungsverfahren abgewickelt, bei denen die Identität der beteiligten Parteien dokumentiert wird. Der hier verwendete elektronische Zahlungsmittelschlüssel ist insbesondere anonym, d.h. der Zahlungsmittelschlüssel enthält keine Informationen über den Besitzer. Der Zahlungsmittelschlüssel lässt keinerlei Rückschlüsse auf die Identität seines Inhabers zu. Insbesondere ist weder die Hinterlegung personenbezogener Daten des Inhabers noch einer Kunden- oder Kontonummer erforderlich.
Es ist dazu weder die Installation einer individuellen Software erforderlich noch die Anschaffung einer zusätzlichen Hardwarekomponente, sondern es werden Elemente verwendet, die einen hohen Verbreitungsgrad besitzen und eine breite Akzeptanz genießen, sowie darüber hinaus eine Handhabungsweise bieten, die konventionellem Bargeld ähnelt, dieses dabei aber an Anwenderfreundlichkeit übertrifft, und zudem die Verwendung hinreichender Sicherheitsstandards erzwingt.
Bei der vorliegenden Erfindung liegt der Zahlungsmittelverifizierungsdatensatz auf dem Serversystem des Emittenten und enthält einen oder mehrere Verifizierungsschlüssel, die insbesondere nach dem Zufallszahlenprinzip erzeugt wurden. Der Inhaber verfügt über den Zahlungsmittelschlüssel in Form einer Eeferenz auf einen oder mehrere Zahlungsmittelverifizierungsdatensätze, beispielsweise in Form einer Bild-, Audio- oder Videodatei, in der der oder die Verifizierungsschlüssel hinterlegt sind.
Die Bildinformation kann insbesondere ein Geldmittel darstellen. Unter einem Geldmittel werden alle Medien verstanden, deren überwiegende Zweckbestimmungen in der Übertragung von Werten besteht, insbesondere Münzen wie zum Beispiel Geldmünzen, Gedenkmünzen, Spielchips, Jetons oder ähnliches sowie Wertpapiere wie beispielsweise Banknoten, Gutscheine, Bons, Billets, Tickets oder ähnliches und Zahlungsanweisungen wie etwa Schecks, Wechsel oder ähnliches.
Zusätzlich enthält das Verfahren eine Bezahlungsvorgangsfunktion insbesondere auf dem Serversystem, über die der Zahlungsmittelschlüssel zwischen dem Zahlungsempfängers und dem Zahlungspflichtigen ausgetauscht und dabei geändert wird. Vorzugsweise werden einige, insbesondere alle Schritte des Ubergabevorgangs beiden beteiligten Parteien in Echtzeit quasisynchron dargestellt. Die Bezahlvorgangsfunktion nimmt dazu den Zahlungsmittelschlüssel vom Zahlenden entgegen, ersetzt den oder die Verifizierungsschlüssel durch neue Verifizierungsschlüssel und gibt vorzugsweise den Zahlungsmittelschlüssel an den Zahlungsempfänger weiter. Damit werden alle früheren Kopien des übergebenen Exemplars des Zahlungsmittelsschlüssels ungültig.
Die mit der Erfindung erzielten Vorteile bestehen insbesondere darin, dass der erfindungsgemäße elektronische Zahlungsmittelschlüssel durch eine Referenz auf einen oder mehrere der Zahlungsmittelverifizierungsdatensätze auf dem Serversystem bereitgestellt wird. Damit ist der Zahlungsmittelschlüssel auf dem Rechner des Anwenders sichtbar und er kann auch darüber beliebig verfügen, beispielsweise durch Weitergabe an Dritte. Die Referenz bzw. der Zahlungsmittelschlüssel kann zum Beispiel aus einem Link bestehen. Im minimalistischsten Fall besteht die Referenz lediglich aus einer Zeichenkette, die den Zahlungsmittelschlüssel wiedergibt.
Eine Manipulationsmöglichkeit der Gültigkeit des Zahlungsmittelsschlüssels scheidet ohne Zugriff auf das Serversystem als Referenzpunkt dennoch aus. Lediglich für die Verbindung zu der Funktion des Serversystems, die den Zahlungsvorgang in Echtzeit bei quasi-synchroner Darstellung ermöglicht, sind verschlüsselte Übertragungsmethoden erforderlich. Dabei kann jedoch auf herkömmliche gesicherte Übertragungsverfahren zurückgegriffen werden.
Außerdem befindet sich somit auf der Datenverarbeitungsanlage des Zahlungsmittelschlüssel-Inhabers nur eine sehr geringe Datenmenge, die verhältnismäßig wenig Speicherplatz in Anspruch nimmt. So lassen sich auch auf mobilen Endgeräten mit vergleichsweise kleinem Speicherangebot große Geldmengen bevorraten. Auch wenn die Referenz etwa in einem Action -Attribut eines Form-Tags in der Auszeichnungssprache HTML abgebildet ist, belegt der HTML-Code nur geringfügigen Speicherplatz.
Ein weiterer Vorteil liegt darin, dass der Zahlungsmittelschlüssel beispielsweise als HTML-Code in Gestalt eines Form-Tags oder eines Links in Form eines von Menschen lesbaren Textes und nicht in einem binär verschlüsselten Format vorliegt. Dadurch werden der Umgang mit dem Zahlungsmittelschlüssel und seine Handhabung erleichtert.
Der Bezahlvorgang besteht zudem aus mindestens einer Funktion auf einem Server, der unter der Verfügungsgewalt des Emittenten steht. Dort tauschen die beteiligten Parteien den Zahlungsmittelschlüssel in Echtzeit aus, indem beispielsweise ein Zahlungsmittelschlüssel in Form eines abgebildeten Geldscheins zur Bezahlung hingegeben und ein neuer Zahlungsmittelschlüssel in Form einer Abbildung von Münzen als Wechselgeld zurückgeben werden. Bei Uberzahlung des gewünschten Betrages wird der überbezahlte Restbetrag vom Serversystem in Form von weiteren Zahlungsmittelschlüsseln zurück übermittelt und/oder es wird eine entsprechende Anzahl von Verifizierungsschlüsseln geändert. Diese(r) weitere(n) Zahlungsmittelschlüssel wird/werden insbesondere in der geringsten Stückelung übermittelt. Bei jedem Austausch eines Zahlungsmittelschlüssels ändert die Funktion den Verifizierungsschlüssel und gewährleistet so, dass alle bisherigen Kopien des Zahlungsmittelsschlüssels ungültig werden bzw. der alte Zahlungsmittelschlüssel nicht den entsprechenden
Zahlungsmittelverifizierungsdatensätzen zugeordnet ist.
Der Aufruf der Funktion kann etwa ganz einfach durch Anklicken eines HTML- Links ausgelöst werden, wenn die Referenz als solcher ausgelegt ist. Die Rückgabe kann als Download gestaltet werden, der von der angesprochenen Funktion angeboten wird. Der detaillierte Vorgang wird in Beispiel 1 ausführlich beschrieben.
Vorteilhafte Ausgestaltungen der Erfindung sind in den nachgeordneten Patentansprüchen angegeben.
Eine Fortbildung der Erfindung wird in Patentanspruch 2 beschrieben. Auf dem Client verleiht eine ansprechende illustrative, auditive oder audiovisuelle statt textliche Darstellung des Zahlungsmittelsschlüssels dem erfindungsgemäßen Zahlungsmittelschlüssel eine erhöhte optische oder akustische Attraktivität und erleichtert damit den Umgang mit diesem neuen Medium. Dieses Bild nach Patentanspruch 2 kann, wie in Patentanspruch 3 fortgebildet, auch auf einem Serversystem des Emittenten hinterlegt sein. Dort können einerseits für Exemplare, die aus dem Verkehr genommen und damit ungültig sind, und andererseits für solche, die sich noch gültig in Umlauf befinden, unterschiedliche Darstellungen hinterlegt werden. Für ungültige Exemplare bietet sich etwa ein ausgegrautes Bild, eine passende Tonfolge oder ein Film mit entsprechendem Inhalt an. Auch eine Wiedergabe in praktisch nicht mehr sichtbarer Größe von einem Pixel oder die Stummschaltung einer Tonfolge käme in Frage. Das erleichtert beim Anwender die Ubersicht, welche Exemplare noch Gültigkeit haben und sich in seinem Besitz befinden und welche er bereits zur Zahlung ausgegeben hat.
Für das Bild kann ein Format wie etwa jpeg, png, gif, tif oder ico oder für die Audiosequenz beispielsweise wav, aac, mp3 oder wma oder für die Videosequenz zum Beispiel mpg, avi, mov, mp4 oder wmv verwendet werden. Dadurch ergibt sich der Vorteil, dass sich die Medien auf den Systemen der allermeisten Anwender problemlos nativ als solche darstellen lassen. Denn der kognitive Aspekt spielt im Hinblick auf die Anwenderfreundlichkeit eine tragende Rolle.
So wird zudem praktisch ausgeschlossen, dass der Inhaber über ein Exemplar des Zahlungsmittelschlüssels verfügt, der auf seinem System aber nicht in der erwarteten Weise dargestellt wird. Damit werden Schrecksituationen vermieden, die von Verlustängsten ausgelöst werden, und aufwendige Bemühungen erspart, verloren geglaubtes Geld zurückzuholen. Denn bekanntlich reagieren Benutzer auf technische Störung bei monetären Transaktionen besonders gereizt. Die Ursache kann in dem existenziellen und deshalb so sensiblen Verhältnis der Menschen zu ihrem Geld vermutet werden.
Durch den Rückgriff auf weit verbreitete Standards erhöhen sich auch die Verbreitungschancen des erfindungsgemäßen Zahlungsmittels. So müssen nicht erst technische Voraussetzungen erfüllt und Standardisierungsabsprachen getroffen werden, sondern die Einführung kann ohne weitere Vorbedingungen sofort veranlasst werden. Das Bild des Zahlungsmittelsschlüssels stellt nach der Fortbildung in Patentanspruch 11 ein allgemein bekanntes Geldmittel als Bildinformation dar, als welches es verwendet wird. So kann das Bild zum Beispiel eine Geldmünze, eine Gedenkmünze, einen Spielchip, einen Jeton oder ähnliches oder ein Wertpapier wie beispielsweise eine Banknote, einen Gutschein, einen Bon, ein Billet, ein Ticket oder ähnliches oder eine Zahlungsanweisung wie etwa einen Scheck, einen Wechsel oder ähnliches zeigen. Wird der erfindungsgemäße Zahlungsmittelsschlüssel beispielsweise als Geldmünze oder Banknote verwendet, kann die Abbildung beispielsweise sein konventionelles physisches Äquivalent mit entsprechendem Wert wiedergeben.
Auch werden elektronische Bilder ähnlich wie Geldmünzen oder -scheine als gegenständliche diskrete Objekte wahrgenommen, über die nach vergleichbaren Regeln der Handhabung verfahren werden kann. So können sie zum Beispiel von einem Ort an den anderen verschoben, gezählt, sortiert oder abgelegt werden. Abstrakten Bezahlverfahren dagegen fehlen diese Parallelen.
Somit wird der elektronische Zahlungsmittelschlüssel in bildlicher Gestalt noch stärker mit herkömmlichen Zahlungsmitteln assoziiert und vor allem älteren Verwendern fällt die Umstellung auf die neue elektronische Form noch leichter.
Die Darstellung des Zahlungsmittelsschlüssels kann dagegen aber auch durch die Wiedergabe beliebter Musikstücke erfolgen oder durch das Abspielen von Ausschnitten angekündigter Kinofilme oder von Werbespots. Dadurch wird die Institution Geld um eine Funktionalität erweitert, die über ihre herkömmliche Aufgabe hinausgeht und geeignet ist, seiner elektronischen Variante ein Attraktivitätsmerkmal zu verleihen, das sich für die breite Akzeptanz vor allem beim jüngeren Publikum als entscheidend erweisen kann. Auch bedient diese Ausgestaltung die Forderung nach neuen multimedialen Entwürfen, die im Zuge des Generationenwechsels zu HTML5 augenblicklich formuliert werden.
In Patentanspruch 12 wird die Erfindung weitergebildet, indem der oder die Zahlungsmittelschlüssel im Maschinencode der Bild-, Audio- oder Videodatei abgelegt werden. Dadurch werden die Daten kompakt zusammengefasst und eine weitere Datei für die Aufnahme dieser Informationen wird obsolet.
Patentanspruch 13 führt diesen Ansatz weiter. Der oder die Schlüssel werden als Strichcode, insbesondere als QR-Code in die Bild- oder Videodatei aufgenommen. Die grafische Chiffre wird als„Pixelsalat" sichtbar und kann von optischen Dekodiergeräten gelesen und weiterverarbeitet werden. Dadurch wird die Schwelle zwischen digitaler und realer Welt bei der Verwendung des elektronischen Zahlungsmittelschlüssels überwunden. Der Code kann aber zum Beispiel auch von einer Audiodatei akustisch wiedergegeben und dennoch maschinell gelesen werden. Entsprechende Anwendungen sind aus dem Tonwahlbereich im Stand der Technik bekannt.
Dagegen richtet Patentanspruch 10 schließlich den Blick in die entgegengesetzte Richtung und versteckt den oder die Schlüssel in einer Bild-, Audio- oder Videodatei, indem es Dateisegmente, die für Metadaten vorgesehene sind, zur Ablage verwendet.
Im Folgenden werden mehrere Ausgestaltungen der Erfindung anhand der Zeichnung und der dazugehörigen Beschreibung erläutert. In der Zeichnung zeigt:
Fig. 1 in einer schematischen Darstellung eine erste Bildschirmansicht einer ersten Ausgestaltung des Verfahrens,
Fig. 2 in einer schematischen Darstellung eine zweite Bildschirmansicht der ersten Ausgestaltung des Verfahrens,
Fig. 3 in einer schematischen Darstellung eine dritte Bildschirmansicht der ersten Ausgestaltung des Verfahrens,
Fig. 4 in einer schematischen Darstellung eine vierte Bildschirmansicht der ersten Ausgestaltung des Verfahrens, Fig. 5 in einer schematischen Darstellung eine fünfte Bildschirmansicht der ersten Ausgestaltung des Verfahrens,
Fig. 6 in einer schematischen Darstellung eine erste Bildschirmansicht einer zweiten Ausgestaltung des Verfahrens,
Fig. 7 in einer schematischen Darstellung eine zweite Bildschirmansicht einer zweiten Ausgestaltung des Verfahrens,
Fig. 8 in einer schematischen Darstellung eine dritte Bildschirmansicht der zweiten Ausgestaltung des Verfahrens,
Fig. 9 in einer schematischen Darstellung eine vierte Bildschirmansicht der zweiten Ausgestaltung des Verfahrens,
Fig. 10 in einer schematischen Darstellung eine fünfte Bildschirmansicht der zweiten Ausgestaltung des Verfahrens,
Fig. 11 in einer schematischen Darstellung eine sechste Bildschirmansicht der zweiten Ausgestaltung des Verfahrens,
Fig. 12 in einer schematischen Darstellung eine siebte Bildschirmansicht der zweiten Ausgestaltung des Verfahrens, und
Fig. 13 in einer schematischen Darstellung eine achte Bildschirm ansieht einer zweiten Ausgestaltung des Verfahrens.
Im Folgenden darf zunächst auf die Fig. 1 bis 5 Bezug genommen werden.
In den Fig. 1 bis 6 sind die Schritte eines Verfahrens dargestellt zur Bezahlung mit mindestens einem gültigen, elektronischen Zahlungsmittelschlüssel. In den Fig. 1 bis 6 ist eine erste Bildschirm ansieht 1 mit zwei Fenstern 2, 3 jeweils eines Internetbrowsers dargestellt. Das linke Fenster 2 zeigt eine Internetverbindung eines Zahlungsempfängers mit einem Serversystem. Das rechte Fenster 3 zeigt eine Internetverbindung eines Zahlungspflichtigen mit einem Serversystem.
Die Darstellung der Fenster 2, 3 kann insbesondere auf zwei, unterschiedlichen, räumlich getrennten Datenverarbeitungsanlagen in unterschiedlichen Büdschirmansichten erfolgen. Hier wurde die Darstellung auf einer Datenverarbeitungsanlage mit einer gemeinsamen Bildschirmansicht gewählt, um die quasi-synchrone Darstellung in den Fenstern 2, 3 zu verdeutlichen. Der Zahlungsempfänger und der Zahlungspflichtige nutzen hier zur Veranschaulichung dieselbe Datenverarbeitungsanlage.
Die Fenster 2, 3 weisen jeweils einen Bereich für den Zahlungsempfänger bzw. den„Geldnehmer" und einen Bereich für den Zahlungspflichtigen„Geldgeber" auf.
Das Serversystem wird hier durch Aufruf einer Webseite kontaktiert. Die Webseite kann beispielsweise „http://www.mycunia.de" lauten. Das Serversystem steht insbesondere unter der Verfügungsgewalt eines Geldinstituts.
Zu Beginn des Verfahrens erfolgt in einem ersten Schritt nun ein Verbindungsaufbau zwischen einer Datenverarbeitungsanlage eines Zahlungsempfängers und dem Serversystem, und ein Verbindungsaufbau zwischen einer Datenverarbeitungsanlage eines Zahlungspflichtigen und dem Serversystem.
Fig. 1 zeigt die beiden Fenster 2, 3 wobei der jeweilige Verbindungsaufbau vom Zahlungspflichtigen mit dem Serversystem und vom Zahlungsempfänger mit dem Serversystem vorgenommen worden ist. Beide Fenster 2, 3 zeigen zunächst den gleichen Inhalt.
Als nächstes erfolgt im Verfahren das Zuordnen des Zahlungsempfängers und des Zahlungspflichtigen. Hierzu wird ein Bezahlvorgang durch das Serversystem in Form einer Schaltfläche „Neue Kasse" bereitgestellt. Die Schaltfläche „Neue Kasse" wird durch den Zahlungsempfänger betätigt. Hierdurch wird eine neue Kasse - hier die Kasse Nr. 2 - angelegt.
Fig. 2 zeigt, dass dem Zahlungsempfänger in Fenster 2 eine neue Ansicht mit der neuen Kasse Nr. 2 angezeigt wird. Dem Zahlungsempfänger wird eine Eingabemaske bereitgestellt, in der der Zahlungsempfänger den gewünschten Geldbetrag eingeben kann. Es ist durch den Text„Geldgeber abwesend" dem Zahlungsempfänger dargestellt, dass der Zahlungspflichtige bzw. „der Geldgeber" der Kasse Nr. 2 noch nicht beigetreten ist.
In Fenster 3 wird dem Zahlungspflichtigen eine Auswahl der verfügbaren Kassen angezeigt. Im Beispiel ist die angelegte Kasse Nr. 2 verfügbar. Der Zahlungspflichtige kann der ausgewählten Kasse— hier Kasse Nr. 2- beitreten.
Fig. 3 zeigt, dass dem Zahlungspflichtigen im Fenster 3 eine neue Ansicht mit der neuen Kasse Nr. 2 angezeigt wird, nachdem der Zahlungspflichtige der Kasse Nr. 2 beigetreten ist. Dem Zahlungspflichtigen wird in Fenster 3 angezeigt, dass der„Geldnehmer anwesend" ist bzw. der Zahlungsempfänger ebenfalls noch die Kasse angezeigt bekommt. Dem Zahlungspflichtigen wird ferner der geforderte Betrag („Preis"), der bezahlte Betrag („Bezahlt") sowie das Wechselgeld („Zurück") angezeigt, hier jeweils gefolgt von„0.00" da bisher noch kein Betrag gefordert und bezahlt wurde und daher auch noch kein Wechselgeld zu erstatten ist.
Der geforderte Betrag wird nun durch den Zahlungsempfänger im Fenster 2 eingegeben. Durch Betätigung der Schaltfläche „Senden" durch den Zahlungsempfänger wird der gewünschte und eingegebene Betrag gesendet.
Fig. 4 zeigt die Fenster 2, 3 nachdem durch den Zahlungsempfänger der geforderte Betrag bzw.„Preis" im Beispiel 75 eingegeben und gesendet worden ist. Dem Zahlungspflichtigen wird der geforderte Betrag gesendet und angezeigt.
Mit der Schaltfläche „Bezahlen" kann der Zahlungspflichtige den Betrag bezahlen. Dieser Vorgang ist in den Fig. 1 bis 5 nicht im Detail dargestellt, und erfolgt automatisch im Hintergrund.
Der Zahlungsmittelschlüssel ist anfangs auf der Datenverarbeitungsanlage des Zahlungspflichtigen gespeichert. Alternativ kann der Zahlungsmittelschlüssel auf dem Serversystem in einer elektronischen, zugangsgesicherten Geldbörse des Zahlungspflichtigen gespeichert sein.
Auf dem Serversystem ist mindestens ein
Zahlungsmittelverifizierungsdatensatz mit einem Zahlungswert und mit mindestens einem Verifizierungsschlüssel gespeichert. Jedem gültigen Zahlungsmittelschlüssel ist mindestens ein
Zahlungsmittelverifizierungsdatensatz zugeordnet. Sofern der
Verifizierungsschlüssel des Zahlungsmittelverifizierungsdatensatzes und der Zahlungsmittelschlüssel ein Paar bilden bzw. einander zugeordnet werden können, ist der Zahlungsmittelschlüssel gültig.
Der Zahlungsmittelschlüssel (hier nicht dargestellt) wird in einer vereinfachten Version durch Betätigen der Schaltfläche „Bezahlen" bzw. Anklicken der Schaltfläche „Bezahlen" automatisch von der Datenverarbeitungsanlage des Zahlungspflichtigen auf das Serversystem übermittelt. Alternativ wird durch Betätigen der Schaltfläche „Bezahlen" der Zahlungsmittelschlüssel von der elektronischen Geldbörse an das Serversystem übermittelt.
Anhand des Zahlungsmittelverifizierungsdatensatzes wird die Gültigkeit des Zahlungsmittelschlüssels überprüft.
Im Fall dass das übermittelte und überprüfte Zahlungsmittelschlüssel gültig ist, wird der zugehörige Verifizierungsschlüssel geändert oder gelöscht, ein neuer Verifizierungsschlüssel wird erstellt und ein neuer Zahlungsmittelschlüssel mit dem geänderten Schlüssel wird erstellt. Der neue Zahlungsmittelschlüssel kann dabei entweder vom Serversystem erstellt werden und dann an den Zahlungsempfänger übermittelt werden oder vom Zahlungsempfänger vorgeschlagen werden. In diesen Fall wird der Zahlungsmittelschlüssel von der Datenverarbeitungsanlage des Zahlungsempfängers an das Serversystem übermittelt.
Der neue Zahlungsmittelschlüssel wird danach an den Zahlungsempfänger bzw. das Serversystem übermittelt. Der Zahlungsempfänger speichert sodann an einem weiteren Speicherort, insbesondere auf seiner Datenverarbeitungsanlage, den Zahlungsmittelschlüssel. Auf der Datenverarbeitungsanlage des Zahlungsempfängers wird der Zahlungsmittelschlüssel, insbesondere durch Abbildung eines Geldmittels, dargestellt.
Fig. 5 zeigt, dass der Zahlungspflichtige einen Zahlungsmittelschlüssel mit dem zugeordneten Betrag 100.00 gegeben hat und daher 25.00 als Wechsel erhält. Die Beträge sind dabei auf dem Serversystem gespeichert. Der Wechsel in Höhe von 25.00 wird automatisch vom Serversystem durch Ubermitteln eines gültigen Zahlungsmittelschlüssels in Höhe von 25.00 an den Zahlungspflichtigen gegeben.
Im Folgenden darf auf die Fig. 6 bis 13 Bezug genommen werden, in denen das Verfahren ausführlicher dargestellt ist.
Zu Beginn des Verfahrens erfolgt in einem ersten Schritt nun ein Verbindungsaufbau zwischen einer Datenverarbeitungsanlage eines Zahlungsempfängers und dem Server, und ein Verbindungsaufbau zwischen einer Datenverarbeitungsanlage eines Zahlungspflichtigen und dem Server.
Fig. 6 zeigt ähnlich wie Fig. 1 die beiden Fenster 2, 3 wobei der jeweilige Verbindungsaufbau vom Zahlungspflichtigen mit dem Serversystem und vom Zahlungsempfänger mit dem Serversystem vorgenommen worden ist. Beide Fenster 2, 3 zeigen zunächst den gleichen Inhalt.
Als nächstes erfolgt im Verfahren das Zuordnen des Zahlungsempfängers und des Zahlungspflichtigen. Hierzu wird eine Schaltfläche „Neue Kasse" bereitgestellt. Die Schaltfläche „Neue Kasse" wird durch den Zahlungsempfänger betätigt. Hierdurch wird eine neue Kasse - hier die Kasse 1 - angelegt.
Fig. 7 zeigt, dass dem Zahlungsempfänger in Fenster 2 eine neue Ansicht mit der neuen Kasse 1 angezeigt wird. Dem Zahlungsempfänger wird eine Eingabemaske bereitgestellt, in der der Zahlungsempfänger den gewünschten Geldbetrag eingeben kann. Es ist durch den Text„Geldgeber abwesend" dem Zahlungsempfänger dargestellt, dass der Zahlungspflichtige bzw. „der Geldgeber" der Kasse 1 noch nicht beigetreten ist.
In Fenster 3 wird dem Zahlungspflichtigen eine Auswahl der verfügbaren Kassen angezeigt. Im Beispiel ist die angelegte Kasse 1 verfügbar. Der Zahlungspflichtige kann der ausgewählten Kasse - hier Kasse 1 - beitreten.
Fig. 8 zeigt, dass dem Zahlungspflichtigen im Fenster 3 eine neue Ansicht mit der neuen Kasse Nr. 1 angezeigt wird, nach dem der Zahlungspflichtige der Kasse Nr. 1 beigetreten ist. Dem Zahlungspflichtigen wird in Fenster 3 angezeigt, dass der„Geldnehmer anwesend" ist bzw. der Zahlungsempfänger ebenfalls noch die Kasse angezeigt bekommt. Dem Zahlungspflichtigen wird ferner der geforderte Betrag („Preis"), der bezahlte Betrag („Bezahlt") sowie das Wechselgeld („Zurück") angezeigt, hier jeweils gefolgt von„0.00" da bisher noch kein Betrag gefordert und bezahlt wurde und daher auch noch kein Wechselgeld zu erstatten ist.
Der geforderte Betrag wird nun durch Zahlungsempfänger im Fenster 2 eingegeben.
Fig. 9 zeigt die Fenster 2, 3 nachdem durch den Zahlungsempfänger der geforderte Betrag bzw.„Preis" im Beispiel 75 eingegeben und gesendet worden ist. Dem Zahlungspflichtigen wird der geforderte Betrag gesendet und angezeigt.
Der Zahlungsmittelschlüssel wird nun an das Serversystem von dem Zahlungspflichtigen übermittelt. Der Zahlungsmittelschlüssel ist vzw. in einer Datei gespeichert. Im Fenster 3 kann der Zahlungspflichtige eine Datei mit dem Zahlungsmittelschlüssel auswählen, wie es in Fig. 9 und 10 dargestellt ist.
Die Datei bzw. der Zahlungsmittelschlüssel ist anfangs auf der Datenverarbeitungsanlage des Zahlungspflichtigen gespeichert. In der Datei ist der Zahlungsmittelsschlüssel (nicht dargestellt) gespeichert.
Der Zahlungsmittelschlüssel weist auf der Datenverarbeitungsanlage des Zahlungspflichtigen und/oder auf der Datenverarbeitungsanlage des Zahlungsempfängers eine Bild-, eine Audio- und/oder eine Videoinformation auf und wird als ein Bild, eine Audio- oder eine Videosequenz dargestellt. In Fig. 10 ist eine Bild-Datei 4 mit der Abbildung eines Geldscheins dargestellt. Diese Bild-Datei 4 dient als Zahlungsmittelschlüssel 5.
Die Bild-, die Audio- und/oder die Videoinformation ist in einer Datei in einem Dateiformat mit mindestens einem zusätzlichen Kommentarsegment gespeichert, wobei der oder die Schlüssel in dem oder in den Kommentarsegmenten der Datei hinterlegt sind. Hier ist der Zahlungsmittelschlüssel in einer JPEG-Datei vorhanden, wobei die Bildinformation einen Geldschein, beispielsweise einen 100-Euro-Schein, darstellt. Der Zahlungsmittelschlüssel ist insbesondere in einem Metadatensegment, z.B. in einem Kommentarsegment der JPEG-Datei, hinterlegt.
Auf dem Serversystem ist mindestens ein
Zahlungsmittelverifizierungsdatensatz mit einem Zahlungswert und mit einem Verifizierungsschlüssel gespeichert ist. Jedem gültigen Zahlungsmittelschlüssel ist mindestens ein Zahlungsmittelverifizierungsdatensatz zugeordnet. Sofern die beiden Schlüssel - der Verifizierungsschlüssel des Verifizierungsdatensatzes und der Zahlungsmittelschlüssel - zuordenbar sind, also ein Paar bilden, ist der Zahlungsmittelschlüssel gültig. Anhand des Zahlungsmittelverifizierungsdatensatzes wird die Gültigkeit des Zahlungsmittelschlüssels überprüft. Im Fall dass der übermittelte und überprüfte Zahlungsmittelschlüssel gültig ist, wird der Verifizierungsschlüssel geändert oder gelöscht und ein neuer Verifizierungsschlüssel und ein neuer Zahlungsmittelschlüssel erstellt.
Der neue Zahlungsmittelschlüssel wird danach an den Zahlungsempfänger übermittelt, sofern der Zahlungsempfänger den Zahlungsmittelschlüssel nicht vorgeschlagen hat. Der Zahlungsempfänger speichert an einem Speicherort den neuen Zahlungsmittelschlüssel insbesondere auf seiner
Datenverarbeitungsanlage. Auf der Datenverarbeitungsanlage des Zahlungsempfängers wird der Zahlungsmittelschlüssel insbesondere durch Abbildung eines Geldmittels dargestellt.
Fig. 12 zeigt, dass der Zahlungspflichtige zwei Zahlungsmittelschlüssel 6, 7 in Form von Bild-Dateien als Wechsel erhält. Da der Zahlungspflichtige einen Zahlungsmittelschlüssel 5 mit dem Betrag 100 Euro gegeben hat und der Zahlungsempfänger 75 Euro gefordert hat, haben die zwei Zahlungsmittelschlüssel 6, 7 den Betrag 5 und 20 Euro. Der Wechsel, nämlich die Zahlungsmittelschlüssel 5, 6 in Höhe von 25.00 Euro werden vom Serversystem zum Runterladen bereitgestellt.
Der Zahlungsempfänger erhält in seinem Fenster 2 die Möglichkeit, die Zahlungsmittelschlüssel 8, 9, 10 in Höhe von 20 Euro, 50 Euro und 10 Euro zuladen, wie in Fig. 12 und 13 dargestellt ist.
Im Folgenden werden weitere Beispiele für Zahlungsmittelschlüssel und Ausgestaltungen des Verfahrens erläutert.
Beispiel 1:
Der Zahlungsmittelschlüssel kann in einer einfachen Ausgestaltung eine Datei im Text-Format sein bzw. in einer solchen Datei gespeichert sein. Diese Datei mit der Bezeichnung banknoteOOl.png enthält als Zahlungsmittelschlüssel die Zeichenfolge„01234567890abcdef. Auf einem Serversystem befindet sich eine Datenbank mit einer Tabelle von folgendem Aufbau:
<serialno> <timestamp> <schluessel> 000000000001 2011-01-01 10:23:05 01234567890abcdef
Die Tabelleneinträge bilden die Zahlungsmittelverifikationsdatensätze bzw. hier den Zahlungsmittelverifikationsdatensatz.
Der Zahlungswert ist hier nicht dargestellt, aber trotzdem in dem Verifizierungsdatensatz enthalten.
Der Verifikationsdatensatz auf dem Serversystem bildet eine Repräsentanz des Zahlungsmittelschlüssels. Der Zahlungsmittelschlüssel bildet eine Referenz auf den Verifikationsdatensatz bzw. die Repräsentanz. Der Zusammenhang zwischen Referenz und Repräsentanz ergibt sich aus der Identität der beiden Schlüssel.
Der Zahlungsempfänger kann einen neuen Bezahlvorgang auf dem Serversystem starten. Der Bezahlvorgang wird dem Zahlungspflichtigen und dem Zahlungsempfänger quasi- synchron dargestellt. Diesem Bezahlvorgang ist insbesondere ein Identifikationsmerkmal zugewiesen, beispielsweise eine Vorgangsnummer. Das Starten des Bezahlvorgangs wird dem verbundenen Zahlungspflichtigen angezeigt. Der Zahlungspflichtige kann den Bezahlvorgang auf dem Serversystem auswählen. Insbesondere kann der Zahlungsempfänger dem Zahlungspflichtigen das Identifikationsmerkmal mitteilen, damit der Zahlungspflichtige den gewünschten Bezahlvorgang auswählen kann. Der Bezahlvorgang kann den Beteiligten als das Erstellen und Auswählen einer „Kasse" dargestellt werden. Es bieten sich hierzu jedoch auch andere Bezeichnungen und Darstellungen, wie „Transaktion", „Bezahlvorgang" und dgl. an.
Damit wird die Ausgabe aller Ereignisse, die sich unter der Vorgangs-Nummer auf der Seite der Funktion zutragen, quasi-synchron an den Zahlungspflichtigen und den Zahlungsempfänger ausgeliefert. Die Übertragung von und zu dieser Seite bzw. dem Serversystem erfolgt über ein verschlüsseltes Protokoll und ist damit gegen ein unbefugtes Abhören gesichert. Der Zahlungspflichtige lädt nun die Datei auf das Serversystem hoch. Ihre Bezeichnung wird dort dargestellt, und zwar nahezu zeitgleich für den Zahlungspflichtigen und den Zahlungsempfänger. Die Funktion ersetzt sodann den Verifizierungsschlüssel in der Datei durch einen Anderen einmaligen, der nach dem Zufallszahlenprinzip erzeugt wurde, und bietet dem Zahlungsempfänger die geänderte Datei zum Download an. Die neue Datei beinhaltet nun den neuen Verifizierungsschlüssel„98765432 lOfedcba" und der Datensatz in der Datenbanktabelle lautet jetzt
<serialno> <timestamp> <code>
000000000001 2011-08-01 16:08:44 9876543210fedcba
Vor den Augen des Zahlungspflichtigen und des Zahlungsempfängers verschwindet die Bezeichnung der Datei nun von der Seite. Auf gleiche Weise— nur in umgekehrter Richtung — gibt nun der Zahlungsempfänger „das Wechselgeld" zurück. Der Zahlungsvorgang ist damit abgeschlossen.
Treten während des Zahlungsvorgangs irgendwelche Störungen auf, haben die Beteiligten die Gelegenheit einzugreifen: Moniert beispielsweise der Zahlungsempfänger, der Download des Zahlungsmittelsschlüssels sei missglückt, bietet die Funktion beispielsweise die Möglichkeit, das getauschte Exemplar des Zahlungsmittelschlüssels so lange zu sperren, bis der Sachverhalt aufgeklärt ist.
Beispiel 2:
Die Datei in Beispiel 1 enthält statt der Zeichenfolge einen Link mit einem Query-String, der die Vorgangsnummer und den Zahlungsmittelschlüssel übergibt:
<html>
<body>
<a
href="http://www.server.com/?vorgangsnummer=1234&schluessel=0123456789" >&euro;l</a>
</body>
</html>
Der Zahlungspflichtige kann so durch bloßes Anklicken des HTML-Links die Funktion aufrufen. Der Zahlungsmittelschlüssel wird dabei automatisch übergeben.
Beispiel 3:
Im Unterschied zu Beispiel 1 handelt es sich bei der Datei um ein Bild im PNG- Format, das eine Banknote darstellt. Es besteht neben seiner Signatur aus verschiedenen Blöcken, darunter aus einem vom Blocktyp „tEXt" mit dem Inhalt„01234567890abcdef.
Der Zahlungsmittelschlüssel ist im Kommentarfeld der Bilddatei enthalten. Die Bilddatei bildet den Zahlungsmittelschlüssel.
Beispiel 4:
Im Gegensatz zu Beispiel 3 liegt das Bild nicht auf dem Rechner des Client, sondern auf dem Server, und wird durch einen HTML- Verweis referenziert:
<html>
<body>
<img src="http://www. server.com/0123456789.png" />
</body>
</html>
Der Zahlungsmittelschlüssel ist dabei Bestandteil der Bezeichnung der Bilddatei.
Beispiel 5:
Der Gast eines Restaurants möchte seine Zeche bezahlen. An seinem Platz ist ein QR-Code auf die Tischplatte gedruckt. Der Gast richtet die Kamera seines Smartphones auf diesen QR-Code und startet eine App, die den Bezahlvoi'gang auf dem Serversystem des Emittenten kontaktiert. Das Serversystem wiederum informiert das internetfähige Kassensystem des Restaurants, dass der Gast seine Rechnung bezahlen wird. Der Zahlungspflichtige gelangt direkt zu dem Fenster, wie es in Fig. 4 oder in Fig. 9 dargestellt ist. Der weitere Zahlungsvorgang kann danach insbesondere nun ohne zusätzliches Zutun von Gast oder Kellner durch die App und das Kassensystem selbstständig abgewickelt werden.
Beispiel 6:
Ein Kreditinstitut emittiert einen elektronischen Zahlungsmittelschlüssel in Form von mp4-Dateien mit einem Wert von Euro 1,00 je Stück, wobei die mp4- Dateien einen Ausschnitt aus einem Musikclip enthalten, der beispielsweise gerade in die Hit-Charts aufgestiegen ist. Der Interpret bietet auf seiner Webseite den vollständigen Musikclip für Euro 1,00 zum Download an. Der Inhaber kann seinen elektronischen Zahlungsmittelschlüssel für jeden beliebigen Zahlungszweck verwenden, unter anderem aber auch zum Erwerb des Musikclips.
Bezugszeichenliste
1 Bildschirmansicht
2 Fenster
3 Fenster
4 Bild
5 Zahlungsmittelschlüssel
6 Zahlungsmittelschlüssel
7 Zahlungsmittelschlüssel
8 Zahlungsmittelschlüssel
9 Zahlungsmittelschlüssel
10 Zahlungsmittelschlüssel

Claims

Patentansprüche
1. Verfahren zur Bezahlung mit mindestens einem elektronischen Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10), wobei auf einem Serversystem mindestens ein Zahlungsmittelverifizierungsdatensatz mit einem Zahlungswert und mit einem Verifizierungsschlüssel gespeichert ist, wobei jedem gültigen Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) mindestens ein Zahlungsmittelverifizierungsdatensatz zugeordnet ist, wobei der Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) an einem Speicherort gespeichert ist, wobei der Speicherort einem Zahlungspflichtigen zur Verfügung steht, mit den folgenden Schritten:
+ 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 (5, 6, 7, 8, 9, 10) an das
Serversystem,
+ Überprüfen der Gültigkeit des Zahlungsmittelschlüssels (5, 6, 7, 8, 9, 10),
+ Andern des Verifizierungsschlüssels sowie Erstellen eines neuen, zugeordneten Zahlungsmittelschlüssels (5, 6, 7, 8, 9, 10), im Fall dass der übermittelte und überprüfte Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) gültig ist, oder
+ Löschen des Verifizierungsschlüssels sowie Erstellen eines neuen Verifizierungsschlüssels und eines neuen, zugeordneten Zahlungsmittelschlüssels (5, 6, 7, 8, 9, 10), im Fall dass der übermittelte und überprüfte Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) gültig ist, + wobei der neue Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) an einem dem Zahlungsempfänger zur Verfügung stehenden, weiteren Speicherort gespeichert wird oder ist.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) des Zahlungspflichtigen und/oder des Zahlungsempfängers eine Bild-, eine Audio- und/oder eine Videoinformation aufweist oder mit einer Bild-, einer Audio- und/oder einer Videoinformation verknüpft ist, wobei der Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) als ein Bild, eine Audio- oder eine Videosequenz dargestellt wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass eine Bild-, eine Audio- und/oder eine Videoinformation auf dem Serversystem gespeichert ist und der Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) eine Referenzierung auf diese serverseitige Bild-, Audio- und/oder Videoinformation aufweist.
4. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass beim Erstellen des neuen Zahlungsmittelschlüssels (5, 6, 7, 8, 9, 10) der neue Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) vom Zahlungsempfänger vorgeschlagen wird und der neue Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) von der Datenverarbeitungsanlage des Zahlungsempfängers an das Serversystem übermittel wird, wobei ein dem neuen Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) zugeordneter, neuer oder geänderter Verifizierungsschlüssel auf dem Serversystem gespeichert wird.
5. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der neue Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) vom Serversystem erstellt wird und vom Serversystem an den Zahlungsempfänger übermittelt wird.
6. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass durch den Zahlungsempfänger ein neuer Bezahlvorgang gestartet wird, wobei dem Bezahlvorgang ein Identifikationsmerkmal auf dem Serversystem zugewiesen ist, und wobei der Zahlungspflichtige dem Bezahlvorgang beitritt.
7. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Identifikationsmerkmal über eine optoelektronische Schnittstelle, insbesondere mittels eines Strichcodes, dargestellt wird, wobei zumindest die Internetadresse des Serversystems mit dem zugehörigen Bezahlvorgang übermittelt wird.
8. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Identifikationsmerkmal als Strichcode, insbesondere als QR-Code dargestellt wird, wobei der Strichcode, insbesondere der QR-Code, eine Internetadresse des Serversystems mit dem zugehörigen Bezahlvorgang aufweist.
9. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Identifikationsmerkmal über eine drahtlose Schnittstelle übermittelt wird.
10. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Identifikationsmerkmal über eine Funkschnittstelle übermittelt wird, insbesondere über Near Field Communication (NFC), wobei zumindest die Internetadresse des Serversystems mit dem zugehörigen Bezahlvorgang übermittelt wird.
11. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass von dem Zahlungspflichtigen der Bezahlvorgang auf dem Serversystem ausgewählt wird.
12. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass nach dem Starten des Bezahlvorganges von dem Zahlungsempfänger der gewünschte Betrag an das Serversystem übermittelt wird, wobei der gewünschte Betrag dem Zahlungspflichtigen angezeigt wird.
13. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass eine Bild-, eine Audio- und/oder eine Videoinformation in einer Datei in einem Dateiformat mit zusätzlichen Metadaten, insbesondere einem Kommentarsegment gespeichert ist, wobei der oder die Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) in dem oder in den Metadatensegmenten bzw. Kommentarsegmenten der Datei hinterlegt sind.
14. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) steganographisch in eine Datei eingebettet wird.
15. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) als digitales Wasserzeichen in einer Datei eingebettet wird.
16. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) in einer Datei enthalten ist, wobei die Datei zusätzlich ein digitales Wasserzeichen aufweist.
17. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Bildinformation ein Geldmittel, insbesondere eine Münze wie zum Beispiel eine Geldmünze, eine Gedenkmünze, einen Spielchip, einen Jeton oder ähnliches oder ein Wertpapier wie beispielsweise eine Banknote, einen Gutschein, einen Bon, ein Billet, ein Ticket oder ähnliches oder eine Zahlungsanweisung wie etwa einen Scheck, einen Wechsel oder ähnliches darstellt; und/oder
- die Audiosequenz ein Musikstück oder einen Ausschnitt davon wiedergibt; und/oder
- die Videosequenz einen Spielfilm oder einen Ausschnitt davon wiedergibt.
18. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) in den Bildinformationen oder den Audioinformationen enthalten ist, wobei der Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) in einem maschinenlesbaren Muster kodiert ist.
19. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der oder die Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) in einem Strichcode, insbesondere einem QR-Code oder einem Mehrfrequenzcode kodiert ist/sind.
20. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Verbindungsstatus des Zahlungsempfängers dem Zahlungspflichtigem angezeigt wird und oder der Verbindungsstatus des Zahlungspflichtigen dem Zahlungsempfänger angezeigt wird.
21. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Verbindung des Zahlungsempfängers und/oder des Zahlungspflichtigen zum Serversystem verschlüsselt wird.
22. Zahlungsmittelschlüssel zur Durchführung des Verfahrens nach einer der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Zahlungsmittelschlüssel (5, 6, 7, 8, 9, 10) eine Bild-, eine Audio- und/oder eine Videoinformation aufweist.
PCT/EP2012/003692 2011-09-09 2012-09-04 Verfahren zur bezahlung mit mindestens einem elektronischen zahlungsmittelschlüssel WO2013034278A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE201110122767 DE102011122767A1 (de) 2011-09-09 2011-09-09 Verfahren zur Bezahlung mit mindestens einem elektronischen Zahlungsmittelschlüssel
DE102011122767.2 2011-09-09

Publications (2)

Publication Number Publication Date
WO2013034278A2 true WO2013034278A2 (de) 2013-03-14
WO2013034278A3 WO2013034278A3 (de) 2013-09-06

Family

ID=47002810

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/003692 WO2013034278A2 (de) 2011-09-09 2012-09-04 Verfahren zur bezahlung mit mindestens einem elektronischen zahlungsmittelschlüssel

Country Status (2)

Country Link
DE (1) DE102011122767A1 (de)
WO (1) WO2013034278A2 (de)

Cited By (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9892460B1 (en) 2013-06-28 2018-02-13 Winklevoss Ip, Llc Systems, methods, and program products for operating exchange traded products holding digital math-based assets
US10068228B1 (en) 2013-06-28 2018-09-04 Winklevoss Ip, Llc Systems and methods for storing digital math-based assets using a secure portal
CN109478307A (zh) * 2016-07-29 2019-03-15 区块链控股有限公司 区块链实现的方法和系统
US10269009B1 (en) 2013-06-28 2019-04-23 Winklevoss Ip, Llc Systems, methods, and program products for a digital math-based asset exchange
US10354325B1 (en) 2013-06-28 2019-07-16 Winklevoss Ip, Llc Computer-generated graphical user interface
US10373158B1 (en) 2018-02-12 2019-08-06 Winklevoss Ip, Llc System, method and program product for modifying a supply of stable value digital asset tokens
US10373129B1 (en) 2018-03-05 2019-08-06 Winklevoss Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US10438290B1 (en) 2018-03-05 2019-10-08 Winklevoss Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US10484376B1 (en) 2015-01-26 2019-11-19 Winklevoss Ip, Llc Authenticating a user device associated with a user to communicate via a wireless network in a secure web-based environment
US10540654B1 (en) 2018-02-12 2020-01-21 Winklevoss Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US10693632B1 (en) 2015-03-16 2020-06-23 Winklevoss Ip, Llc Autonomous devices
US10915891B1 (en) 2015-03-16 2021-02-09 Winklevoss Ip, Llc Autonomous devices
US10929842B1 (en) 2018-03-05 2021-02-23 Winklevoss Ip, Llc System, method and program product for depositing and withdrawing stable value digital assets in exchange for fiat
US11139955B1 (en) 2018-02-12 2021-10-05 Winklevoss Ip, Llc Systems, methods, and program products for loaning digital assets and for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
US11200569B1 (en) 2018-02-12 2021-12-14 Winklevoss Ip, Llc System, method and program product for making payments using fiat-backed digital assets
US11282139B1 (en) 2013-06-28 2022-03-22 Gemini Ip, Llc Systems, methods, and program products for verifying digital assets held in a custodial digital asset wallet
US11308487B1 (en) 2018-02-12 2022-04-19 Gemini Ip, Llc System, method and program product for obtaining digital assets
US11334883B1 (en) 2018-03-05 2022-05-17 Gemini Ip, Llc Systems, methods, and program products for modifying the supply, depositing, holding and/or distributing collateral as a stable value token in the form of digital assets
US11475442B1 (en) 2018-02-12 2022-10-18 Gemini Ip, Llc System, method and program product for modifying a supply of stable value digital asset tokens
US11501370B1 (en) 2019-06-17 2022-11-15 Gemini Ip, Llc Systems, methods, and program products for non-custodial trading of digital assets on a digital asset exchange
US11522700B1 (en) 2018-02-12 2022-12-06 Gemini Ip, Llc Systems, methods, and program products for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
US11606219B2 (en) 2016-02-23 2023-03-14 Nchain Licensing Ag System and method for controlling asset-related actions via a block chain
US11621833B2 (en) 2016-02-23 2023-04-04 Nchain Licensing Ag Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system
US11625694B2 (en) 2016-02-23 2023-04-11 Nchain Licensing Ag Blockchain-based exchange with tokenisation
US11727501B2 (en) 2016-02-23 2023-08-15 Nchain Licensing Ag Cryptographic method and system for secure extraction of data from a blockchain
US11755718B2 (en) 2016-02-23 2023-09-12 Nchain Licensing Ag Blockchain implemented counting system and method for use in secure voting and distribution
US11842339B2 (en) 2017-05-15 2023-12-12 Nchain Licensing Ag Secure off-chain blockchain transactions
US11909860B1 (en) 2018-02-12 2024-02-20 Gemini Ip, Llc Systems, methods, and program products for loaning digital assets and for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
US11936774B2 (en) 2016-02-23 2024-03-19 Nchain Licensing Ag Determining a common secret for the secure exchange of information and hierarchical, deterministic cryptographic keys
US11972422B2 (en) 2016-02-23 2024-04-30 Nchain Licensing Ag Registry and automated management method for blockchain-enforced smart contracts

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014014109A1 (de) 2014-09-24 2016-03-24 Giesecke & Devrient Gmbh Transaktionsverfahren
DE102017000167A1 (de) 2017-01-11 2018-07-12 Giesecke+Devrient Mobile Security Gmbh Anonymisierung einer Blockkette

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19859959A1 (de) 1998-12-29 2000-07-06 Manfred Matzel Verfahren für einen Geld- oder Vermögenstransfer und Geld- oder Vermögens-Einheitenkarte hierfür
DE102009034436A1 (de) 2009-07-23 2011-01-27 Giesecke & Devrient Gmbh Verfahren und System zum Bezahlen mit geldwerten Beträgen in Form elektronischer Datensätze

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001015100A1 (en) * 1999-08-26 2001-03-01 Eluv Holdings Ltd. Electronic currency, electronic wallet therefor and electronic payment systems employing them
US6938019B1 (en) * 2000-08-29 2005-08-30 Uzo Chijioke Chukwuemeka Method and apparatus for making secure electronic payments
US20030046534A1 (en) * 2001-08-31 2003-03-06 Alldredge Robert L. Method and apparatus for secured electronic commerce
JP2004005643A (ja) * 2002-05-30 2004-01-08 Internatl Business Mach Corp <Ibm> 定義されたパーティにより検証可能な匿名支払方法
EP1983491A1 (de) * 2007-04-20 2008-10-22 Axalto SA Mobile Gerätekommunikation mittels Strichcodeanzeige

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19859959A1 (de) 1998-12-29 2000-07-06 Manfred Matzel Verfahren für einen Geld- oder Vermögenstransfer und Geld- oder Vermögens-Einheitenkarte hierfür
DE102009034436A1 (de) 2009-07-23 2011-01-27 Giesecke & Devrient Gmbh Verfahren und System zum Bezahlen mit geldwerten Beträgen in Form elektronischer Datensätze

Cited By (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11164251B1 (en) 2013-06-28 2021-11-02 Winklevoss Ip, Llc Computer-generated graphical user interface
US10255635B1 (en) 2013-06-28 2019-04-09 Winklevoss Ip, Llc Systems, methods, and program products for an application programming interface generating a blended digital math-based assets index
US9965805B1 (en) 2013-06-28 2018-05-08 Winklevoss Ip, Llc Systems, methods, and program products for operating exchange traded products holding digital math-based assets
US11580532B1 (en) 2013-06-28 2023-02-14 Gemini Ip, Llc Systems, methods, and program products for a digital math-based asset exchange
US10002389B1 (en) 2013-06-28 2018-06-19 Winklevoss Ip, Llc Systems, methods, and program products for an application programming interface generating a blended digital math-based assets index
US11783417B1 (en) 2013-06-28 2023-10-10 Gemini Ip, Llc Systems for redeeming shares in an entity holding digital math-based assets
US11615404B1 (en) 2013-06-28 2023-03-28 Gemini Ip, Llc Systems, methods, and program products for a digital math-based asset exchange
US11423482B1 (en) 2013-06-28 2022-08-23 Gemini Ip, Llc Systems, methods, and program products for an application programming interface generating a blended digital math-based assets index
US10269009B1 (en) 2013-06-28 2019-04-23 Winklevoss Ip, Llc Systems, methods, and program products for a digital math-based asset exchange
US10325257B1 (en) 2013-06-28 2019-06-18 Winklevoss Ip, Llc Systems and methods for storing digital math-based assets using a secure portal
US10354325B1 (en) 2013-06-28 2019-07-16 Winklevoss Ip, Llc Computer-generated graphical user interface
US11995720B1 (en) 2013-06-28 2024-05-28 Gemini Ip, Llc Systems for purchasing shares in an entity holding digital math-based assets
US11282139B1 (en) 2013-06-28 2022-03-22 Gemini Ip, Llc Systems, methods, and program products for verifying digital assets held in a custodial digital asset wallet
US11568398B1 (en) 2013-06-28 2023-01-31 Gemini Ip, Llc Systems and methods for storing digital math-based assets using a secure portal
US11087313B1 (en) 2013-06-28 2021-08-10 Winklevoss Ip, Llc Systems, methods, and program products for a digital math-based asset exchange
US9892460B1 (en) 2013-06-28 2018-02-13 Winklevoss Ip, Llc Systems, methods, and program products for operating exchange traded products holding digital math-based assets
US11928732B1 (en) 2013-06-28 2024-03-12 Gemini Ip, Llc Computer-generated graphical user interface
US11017381B1 (en) 2013-06-28 2021-05-25 Winklevoss Ip, Llc Systems, methods, and program products for a digital math-based asset exchange
US10650376B1 (en) 2013-06-28 2020-05-12 Winklevoss Ip, Llc Systems and methods for storing digital math-based assets using a secure portal
US10984470B1 (en) 2013-06-28 2021-04-20 Winklevoss Ip, Llc Systems for redeeming shares in an entity holding digital math-based assets
US9965804B1 (en) 2013-06-28 2018-05-08 Winklevoss Ip, Llc Systems, methods, and program products for operating exchange traded products holding digital math-based assets
US9898782B1 (en) 2013-06-28 2018-02-20 Winklevoss Ip, Llc Systems, methods, and program products for operating exchange traded products holding digital math-based assets
US10068228B1 (en) 2013-06-28 2018-09-04 Winklevoss Ip, Llc Systems and methods for storing digital math-based assets using a secure portal
US10929929B1 (en) 2013-06-28 2021-02-23 Winklevoss Ip, Llc Systems for purchasing shares in an entity holding digital math-based assets
US10984472B1 (en) 2013-06-28 2021-04-20 Winklevoss Ip, Llc Systems, methods, and program products for an application programming interface generating a blended digital math-based assets index
US10484376B1 (en) 2015-01-26 2019-11-19 Winklevoss Ip, Llc Authenticating a user device associated with a user to communicate via a wireless network in a secure web-based environment
US11283797B2 (en) 2015-01-26 2022-03-22 Gemini Ip, Llc Authenticating a user device associated with a user to communicate via a wireless network in a secure web-based environment
US10778682B1 (en) 2015-01-26 2020-09-15 Winklevoss Ip, Llc Authenticating a user device associated with a user to communicate via a wireless network in a secure web-based environment
US10915891B1 (en) 2015-03-16 2021-02-09 Winklevoss Ip, Llc Autonomous devices
US11783323B1 (en) 2015-03-16 2023-10-10 Gemini Ip, Llc Autonomous devices
US11362814B1 (en) 2015-03-16 2022-06-14 Gemini Ip, Llc Autonomous devices
US10693632B1 (en) 2015-03-16 2020-06-23 Winklevoss Ip, Llc Autonomous devices
US11755718B2 (en) 2016-02-23 2023-09-12 Nchain Licensing Ag Blockchain implemented counting system and method for use in secure voting and distribution
US11936774B2 (en) 2016-02-23 2024-03-19 Nchain Licensing Ag Determining a common secret for the secure exchange of information and hierarchical, deterministic cryptographic keys
US11625694B2 (en) 2016-02-23 2023-04-11 Nchain Licensing Ag Blockchain-based exchange with tokenisation
US11972422B2 (en) 2016-02-23 2024-04-30 Nchain Licensing Ag Registry and automated management method for blockchain-enforced smart contracts
US11727501B2 (en) 2016-02-23 2023-08-15 Nchain Licensing Ag Cryptographic method and system for secure extraction of data from a blockchain
US11621833B2 (en) 2016-02-23 2023-04-04 Nchain Licensing Ag Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system
US11606219B2 (en) 2016-02-23 2023-03-14 Nchain Licensing Ag System and method for controlling asset-related actions via a block chain
CN109478307A (zh) * 2016-07-29 2019-03-15 区块链控股有限公司 区块链实现的方法和系统
US11842339B2 (en) 2017-05-15 2023-12-12 Nchain Licensing Ag Secure off-chain blockchain transactions
US10540654B1 (en) 2018-02-12 2020-01-21 Winklevoss Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US11200569B1 (en) 2018-02-12 2021-12-14 Winklevoss Ip, Llc System, method and program product for making payments using fiat-backed digital assets
US11522700B1 (en) 2018-02-12 2022-12-06 Gemini Ip, Llc Systems, methods, and program products for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
US10373158B1 (en) 2018-02-12 2019-08-06 Winklevoss Ip, Llc System, method and program product for modifying a supply of stable value digital asset tokens
US11475442B1 (en) 2018-02-12 2022-10-18 Gemini Ip, Llc System, method and program product for modifying a supply of stable value digital asset tokens
US10540653B1 (en) 2018-02-12 2020-01-21 Winklevoss Ip, Llc System, method and program product for modifying a supply of stable value digital asset tokens
US11308487B1 (en) 2018-02-12 2022-04-19 Gemini Ip, Llc System, method and program product for obtaining digital assets
US11909860B1 (en) 2018-02-12 2024-02-20 Gemini Ip, Llc Systems, methods, and program products for loaning digital assets and for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
US11139955B1 (en) 2018-02-12 2021-10-05 Winklevoss Ip, Llc Systems, methods, and program products for loaning digital assets and for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
US11334883B1 (en) 2018-03-05 2022-05-17 Gemini Ip, Llc Systems, methods, and program products for modifying the supply, depositing, holding and/or distributing collateral as a stable value token in the form of digital assets
US11727401B1 (en) 2018-03-05 2023-08-15 Gemini Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US11017391B1 (en) 2018-03-05 2021-05-25 Winklevoss Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US10929842B1 (en) 2018-03-05 2021-02-23 Winklevoss Ip, Llc System, method and program product for depositing and withdrawing stable value digital assets in exchange for fiat
US10540640B1 (en) 2018-03-05 2020-01-21 Winklevoss Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US11720887B1 (en) 2018-03-05 2023-08-08 Gemini Ip, Llc System, method and program product for depositing and withdrawing stable value digital assets in exchange for fiat
US11562333B1 (en) 2018-03-05 2023-01-24 Gemini Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US10438290B1 (en) 2018-03-05 2019-10-08 Winklevoss Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US10373129B1 (en) 2018-03-05 2019-08-06 Winklevoss Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US11501370B1 (en) 2019-06-17 2022-11-15 Gemini Ip, Llc Systems, methods, and program products for non-custodial trading of digital assets on a digital asset exchange

Also Published As

Publication number Publication date
DE102011122767A1 (de) 2013-03-14
WO2013034278A3 (de) 2013-09-06

Similar Documents

Publication Publication Date Title
WO2013034278A2 (de) Verfahren zur bezahlung mit mindestens einem elektronischen zahlungsmittelschlüssel
CN108885761B (zh) 用于区块链上的安全点对点通信的方法
US11893626B2 (en) Method for creating commodity assets from unrefined commodity reserves utilizing blockchain and distributed ledger technology
Dyntu et al. Cryptocurrency in the system of money laundering
Bollen The Legal Status of Online Currencies–Are Bitcoins the Future?
JP2020536322A (ja) 公開分散台帳システムにおける取引プライバシー
US20140337206A1 (en) Electronic Currency System
Tropina Fighting money laundering in the age of online banking, virtual currencies and internet gambling
Lim A facilitative model for cryptocurrency regulation in Singapore
US20170213198A1 (en) Account and server free possession and transfer of entangled electronic money
JP7214170B2 (ja) 暗号通貨を担保として限度が与えられた仮想通貨を用いた電子決済代行方法及びシステム
WO2010089049A1 (de) Mobiles zahlungsverfahren und vorrichtungen
KR20180093387A (ko) 비트코인을 이용한 후원금 지급방법 및 그 방법으로 실행되는 애플리케이션을 기록한 기록매체
Tinn et al. Central bank digital currency with asymmetric privacy
JP6547147B2 (ja) 電子マネーシステム及びその処理方法
Van Hee et al. A new digital currency system
KR20190125806A (ko) 복수의 가상화폐를 이용한 온라인 디지털 콘텐츠 이용 시스템
Hassan Blockchain technology and its potential effect on the banking industry (China Case Study)
JP2024510307A (ja) デジタル通貨プラットフォームサービスを提供する方法、及びそのためのシステム
Wurster Mobile Payment-Risks of a New Technology
DE102006017911B4 (de) Elektronisches Bezahlsystem und Verfahren zum Ausführen eines Bezahlvorgangs
US20150026042A1 (en) System and method for electronic cash-like transactions
Fredrick CRYPTOCURRENCY AND BLOCKCHAIN: HERE WE GO DOWN THE RABBIT HOLE.
Mas Strains of Digital Money
Petrova et al. Prospects for Blockchain Implementation in the Financial Sector

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

Country of ref document: EP

Kind code of ref document: A2

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION NOT DELIVERED. NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 14.07.2014)

122 Ep: pct app. not ent. europ. phase

Ref document number: 12769593

Country of ref document: EP

Kind code of ref document: A2