PROCESSING SYSTEM FOR PROCESSING CRYPTOCURRENCIES AND METHOD FOR PROCESSING CRYPTOCURRENCIES

Abstract

The present disclosure provides a processing system for processing a number of cryptocurrencies, the processing system comprising a merchant terminal configured to generate transaction information as a basis for the generation of transactions with one of the cryptocurrencies, and an automatic transaction handling processor configured to process transactions generated based on the transaction information and to automatically split and/or redistribute transferred coins and/or assets based on a predetermined transfer policy. Further, the present disclosure provides a respective method.

Claims

1. Processing system for processing a number of cryptocurrencies, the processing system comprising: a merchant terminal configured to generate transaction information as a basis for the generation of transactions with one of the cryptocurrencies, and an automatic transaction handling processor configured to process transactions generated based on the transaction information and to at least one of automatically split or redistribute at least one of transferred coins or assets based on a predetermined transfer policy.

2. The processing system according to claim 1, comprising: a client terminal configured to provide a cryptographic key required for performing the transaction based on the generated transaction information, and a transaction processor configured to perform the transaction of at least one of coins or assets of the respective one of the cryptocurrencies as indicated by the transaction information based on the cryptographic key provided by the client terminal, wherein the automatic transaction handling processor is especially configured to process transactions generated by the transaction processor.

3. The processing system according to claim 1, wherein the merchant terminal comprises a user interface configured to receive user input and to output respective user information, wherein the user input refers to an amount of at least one of a fiat currency or to an amount of at least one of coins or assets of the cryptocurrency that is to be used for the transaction or additional information.

4. The processing system according to claim 1, wherein at least one of (i) the transaction information comprises a wallet address of a wallet of the operator of the merchant terminal for a cryptocurrency that is used for the transaction and especially to which the automatic transaction handling processor has access or (ii) the transaction information comprises an amount of at least one of coins or of assets in said cryptocurrency.

5. The processing system according to claim 2, wherein the client terminal comprises a memory, the memory storing at least a secret cryptographic key for a client wallet of the cryptocurrency that is to be used for the transaction.

6. The processing system according to claim 2, wherein the client terminal comprises a setting memory configured to store user settings, and wherein the client terminal is configured to provide at least some of the stored user settings to the merchant terminal, wherein the setting memory is configured to store automatic transaction user settings, and wherein the client terminal is configured to at least one of provide the automatic transaction user settings to the merchant terminal or to verify whether requirements defined by the automatic transaction user settings are fulfilled by the transaction.

7. The processing system according to claim 1, wherein at least one of: (i) the predetermined transfer policy specifies how new transactions are automatically generated by the automatic transaction handling processor based on the incoming transaction performed by the transaction processor, (ii) a specific transfer policy is provided for each of multiple merchant terminals for multiple terminals operated by the same operator, (iii) in each case a specific transfer policy is provided for different times or time ranges, (iv) a standard transfer policy is used for the transaction if no specific transfer policy applies to the transaction; or (v) the predetermined transfer policy indicates a target currency for at least one of the redistribution or the splitting of the incoming transaction.

8. (canceled)

9. (canceled)

10. The processing system according to claim 1, comprising a wallet generator, that is configured to generate for the operator of the merchant terminal a system wallet and a storage wallet, wherein at least one of: (i) tithe system wallet is provided as at least one of a multi-signature wallet or as a hierarchical deterministic wallet, or (ii) the storage wallet is provided as at least one of a multi-signature wallet or as a hierarchical deterministic wallet, and wherein the processing system further comprises a wallet storage, that is configured to store for the operator of the merchant terminal the system wallet and the storage wallet.

11. The processing system according to claim 10, comprising at least one of: (i) directive verification processor, that comprises at least one of one private key of two private keys for the system wallet, to which the processing system has access, or one private key of a single key for the storage wallet, to which the processing system has access, and that is configured to verify if a transaction conforms to predetermined directives prior to releasing the one private key for performing a transaction, (ii) comprising an offline paper wallet generator, wherein the offline paper wallet generator is configured to print out optical codes on a piece of paper for a wallet or address that comprises a predetermined amount of at least one of coins or assets, or (iii) comprising a contract generator configured to automatically create smart contracts based on an address provided by the user of the client terminal and the transaction information.

12. (canceled)

13. (canceled)

14. A method for processing a number of cryptocurrencies, the method comprising: generating transaction information on a merchant side as a basis for the generation of transactions with one of the cryptocurrencies, and processing, on a server side, the transactions generated based on the transaction information and at least one of automatically splitting or redistributing at least one of transferred coins or assets based on a predetermined transfer policy.

15. The method of claim 14, the method further comprising: providing a cryptographic key required for performing the transaction based on the generated transaction information on the client side, and performing the transaction of at least one of coins or assets of one of the cryptocurrencies as indicated by the transaction information based on the cryptographic key provided on the client side.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0234] For a more complete understanding of the present disclosure and advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings. The disclosure is explained in more detail below using exemplary embodiments which are specified in the schematic figures of the drawings, in which:

[0235] FIG. 1 shows a block diagram of an embodiment of a processing system according to the present disclosure;

[0236] FIG. 2 shows a block diagram of an embodiment of a merchant terminal according to the present disclosure;

[0237] FIG. 3 shows a block diagram of another embodiment of a merchant terminal according to the present disclosure;

[0238] FIG. 4 shows another block diagram of the embodiment of a merchant terminal according to the present disclosure of FIG. 3;

[0239] FIG. 5 shows another block diagram of the embodiment of a merchant terminal according to the present disclosure of FIG. 3;

[0240] FIG. 6 shows another block diagram of the embodiment of a merchant terminal according to the present disclosure of FIG. 3;

[0241] FIG. 7 shows a block diagram of another embodiment of a merchant terminal according to the present disclosure;

[0242] FIG. 8 shows a block diagram of another embodiment of a merchant terminal according to the present disclosure;

[0243] FIG. 9 shows a block diagram of an embodiment of a client terminal according to the present disclosure;

[0244] FIG. 10 shows a block diagram of another embodiment of a client terminal according to the present disclosure;

[0245] FIG. 11 shows a block diagram of another embodiment of a client terminal according to the present disclosure;

[0246] FIG. 12 shows a block diagram of another embodiment of a client terminal according to the present disclosure;

[0247] FIG. 13 shows a block diagram of another embodiment of a client terminal according to the present disclosure;

[0248] FIG. 14 shows a block diagram of another embodiment of a client terminal according to the present disclosure;

[0249] FIG. 15 shows a block diagram of another embodiment of a client terminal according to the present disclosure;

[0250] FIG. 16 shows a block diagram of an embodiment of an automatic transaction handling processor according to the present disclosure;

[0251] FIG. 17 shows a block diagram of an embodiment of an exchange rate service and an exchange service according to the present disclosure;

[0252] FIG. 18 shows a block diagram of an embodiment of an exchange rate optimizer according to the present disclosure;

[0253] FIG. 19 shows a block diagram of an embodiment of a transaction verification controller according to the present disclosure;

[0254] FIG. 20 shows a block diagram of an embodiment of a fork detection system according to the present disclosure;

[0255] FIG. 21 shows a block diagram of an embodiment of a wallet storage and a wallet generator according to the present disclosure; and

[0256] FIG. 22 shows a block diagram of an embodiment of a directive verification processor according to the present disclosure.

[0257] In the figures like reference signs denote like elements unless stated otherwise.

DETAILED DESCRIPTION OF THE DRAWINGS

[0258] FIG. 1 shows a block diagram of a processing system 100. The processing system 100 comprises a merchant terminal 101, a client terminal 103, a transaction processor 105 that is coupled to the merchant terminal 101 and the client terminal 103, and an automatic transaction handling processor 108 that is coupled to the transaction processor 105 via a network 107, e.g. the internet 107 and comprises a predetermined transfer policy 109.

[0259] With the processing system 100 a merchant and a client or customer may use cryptocurrencies to perform trades. The merchant may for example sell the client goods and/or services.

[0260] The processing system 100 supports the settlement of such trades via cryptocurrencies. To this end, the merchant terminal 101 provides transaction information 102. The transaction information 102 may e.g. be generated based on an input by the merchant. Such an input may for example refer to an amount to be paid by the client. The amount may e.g. be provided by the merchant to the merchant terminal 101 as amount of a fiat currency or as amount of a cryptocurrency. If the amount is provided by the merchant as an amount of fiat currency, the merchant terminal may allow the merchant to select a cryptocurrency that is to be used for settling the debts of the client. The cryptocurrency to be used and the amount of coins and/or assets to be transferred may then be provided in the transaction information 102. Further, the address for the receiving wallet, also called system wallet, of the merchant may also be provided in the transaction information 102. The transaction information 102 may then be provided to the transaction processor 105. It is understood, that the merchant terminal 101 may generate the transaction information 102 autonomously. In another embodiment, the merchant terminal 101 may provide the required information, like e.g. the selected cryptocurrency and the amount to be paid, to a backend of the processing system 100, e.g. to a sever or a service hosted on a server. The backend may then provide the transaction information 102 to the merchant terminal 101 for forwarding to the transaction processor 105. The transaction information 102 generated in the backend may e.g. comprise the receiving address, the amount of coins and other details. It is further understood, that the generated transaction information 102 may e.g. be shown to the merchant for confirmation, e.g. on a user interface of the merchant terminal 101.

[0261] A wallet usually comprises one or multiple pairs of keys that in combination form a deposit for coins and/or assets of the respective cryptocurrency. A pair of keys comprises a public key, which forms the address and is publicly known. The pair of keys further comprises the private or secret key that is only known to the owner of the respective pair of keys. The private key is required to sign transactions. If the signature matches the public key, a transaction is assumed to be valid and the transfer of the respective amount of coins and/or assets from the respective address is stored in the blockchain.

[0262] The client may be in possession of one or multiple wallets. The respective cryptographic keys 104 may be stored in the client terminal 103. Therefore, to settle a debt, the client may use the client terminal 103 to provide the respective cryptographic keys 104 to the transaction processor 105.

[0263] The transaction processor 105 may then create a transaction 106 based on the transaction information 102 and the cryptographic key 104, and provide the transaction 106 to the network 107 of the respective cryptocurrency. It is understood, that the network 107 not necessarily is a dedicated network. Instead the network 107 of the cryptocurrency may e.g. be an overlay network that is formed of all nodes of the cryptocurrency network on top of another network, like e.g. the internet.

[0264] The processing system 100 further comprises the automatic transaction handling processor 108. The automatic transaction handling processor 108 allows to automatically process incoming data or transactions of all cryptocurrencies that may possibly be used with the processing system 100.

[0265] The automatic transaction handling processor 108 further processes the incoming transaction 106 generated by the transaction processor 105. Processing may refer to detecting the transaction 106 and to automatically splitting and/or redistributing transferred coins and/or assets based on the predetermined transfer policy 109, e.g. an outgoing transaction 110, and optionally further outgoing transaction 111.

[0266] The automatic transaction handling processor 108 may forward the incoming coins and/or assets to a predetermined address, e.g. in transaction 110. However, the automatic transaction handling processor 108 may also split the incoming transaction, i.e. the automatic transaction handling processor 108 may automatically process the incoming data and perform a data conversion to provide two outgoing transactions 110, 111.

[0267] In an embodiment, the transaction 110 may serve to forward coins and/or assets to a wallet of the merchant to which only the merchant has access, e.g. the merchant wallet.

[0268] The outgoing transaction 111 may serve to forward a specific part of the coins and/or assets that have been transferred in transaction 106 to another wallet, e.g. a wallet of the operator of the processing system 100.

[0269] The automatic transaction handling processor 108 in any case will split and/or redistribute the incoming coins and/or assets based on the transfer policy 109. The transfer policy 109 may also be provided at least in part by the merchant terminal 101 and/or the client terminal 103.

[0270] The transfer policy 109 specifies how new transactions 110, 111 are automatically generated by the automatic transaction handling processor 108 based on the incoming transaction 106 performed by the transaction processor 105.

[0271] The transfer policy 109 may also indicate a target currency for the redistribution and/or splitting of the incoming transaction 106. Such a target currency may be a cryptocurrency, e.g. the cryptocurrency that is used for transaction 106 or another cryptocurrency. Further, the target currency may also specify a fiat currency. Below it will be explained in detail how the automatic transaction handling processor 108 may exchange different currencies either with an integrated exchange or via an external exchange or exchange service.

[0272] The transfer policy 109 may also be based on tracking information of the user of the client terminal 103 and/or of the operator of the merchant terminal 101 and/or of the merchant terminal 101. Such information may be provided either as additional information in the transaction 106 or via a dedicated interface between the merchant terminal 101 or the client terminal 103 and the automatic transaction handling processor 108.

[0273] A specific transfer policy 109 may for example be provided for each of multiple merchant terminals 101. Multiple merchant terminals may pertain to multiple merchants. In addition, or as alternative, multiple terminals may pertain to a single merchant. Further, in each case a specific transfer policy 109 may be provided for different times or time ranges.

[0274] A standard transfer policy 109 may be used for the transaction 106, if no specific transfer policy 109 applies to the respective transaction 106.

[0275] FIG. 2 shows a block diagram of a possible merchant terminal 201 in a front view. The merchant terminal 201 comprises a user interface 215. The user interface 215 comprises a keyboard 216 and a display 217.

[0276] The keyboard 216 serves for receiving user input 219 from user 218, e.g. the merchant. The display 217 serves for providing user information 220 to the user 218.

[0277] The merchant terminal 201 as shown in FIG. 2 may for example be embodied as a dedicated device. Such a device may serve exclusively as a merchant terminal as described herein. It is however understood, that the merchant terminal 201 may also be provided e.g. as an application running on a smartphone or a tablet PC or any other computer. As alternative or in addition, the merchant terminal 201 may also be provided e.g. integrated into a POS system. In such embodiments, the keyboard 216 may also be substituted by respective inputs on a touchscreen of the respective device, as will be seen below.

[0278] It is understood, that although not shown, the merchant terminal 201 may comprise additional elements, like e.g. a network interface like a WIFI or Ethernet interface, a short distance interface, like e.g. a RFID or NFC interface, a further screen, e.g. for displaying information to the client, and the like.

[0279] With the merchant terminal 201, the user 218 may for example input an amount of a fiat currency to be paid and/or select a cryptocurrency to be used for the transaction via the keyboard 216.

[0280] The display 217 may for example be used to display information to the user 218. Such information may e.g. refer to the amount to be paid, the cryptocurrency to be used for the transaction, an exchange rate between the cryptocurrency and a predetermined fiat currency, and the like.

[0281] When all required information has been provided to the merchant terminal 201 by the user 218, the user 218 may provide the respective transaction information, e.g. in the form of a visual code, like e.g. a QR code, on the display. In addition, or as alternative, the user 218 may provide the transaction information e.g. via a network interface, via a RFID or NFC interface or via a wired interface.

[0282] FIG. 3 shows a block diagram of another merchant terminal 301. The merchant terminal 301 is provided as a computing device with an application that is executed on the computing device. FIG. 3 focuses on the user interface, which is provided as touchscreen, and especially with a keyboard 316, and with a display 315. It is understood, that the display 315 and the keyboard 316 are provided as sections on the touchscreen.

[0283] It can be seen, that the user interface may further comprise elements, like e.g. a logo, an indication of battery power, wireless network strength (at the top), and general buttons like, back, accept, or menu (at the bottom). It is understood, that these elements may for example be provided by an operating system that is executed on the computing device.

[0284] The keyboard 316 shows numbers, which allow the user to input the price in € that is to be paid by a client. Further, an enter button “✓” and a cancel button “C” are shown. In an embodiment, the user may also tap the “€” symbol in the section of the display 315 and change to another fiat currency, like e.g. $ or the like. If the user enters an amount and accepts via the enter button “✓”, the user interface changes to the user interface shown in FIG. 4.

[0285] FIG. 4 shows another block diagram of the merchant terminal 301, with the user interface after a user enters and accepts an amount of a fiat currency to be paid. The display 315 still shows the amount to be paid in the respective fiat currency, here Euro. It is understood, that the user in some embodiments, may change the fiat currency by tapping the “€” symbol, as explained above.

[0286] In the keyboard section 316 of the user interface a list of different cryptocurrencies is shown, that are supported by the processing system for performing payments. In FIG. 4 exemplarily the following cryptocurrencies are shown: Bitcoin, Litecoin, Byteball, Ethereum, Ripple. It is understood, that this selection of cryptocurrencies is just exemplary and that any other type and number of cryptocurrencies may be shown in other embodiments.

[0287] In the example of FIG. 4 the cryptocurrency “Litecoin” is selected. Below the “Litecoin” entry, the amount to be payed is shown in Euro. Further, the exchange rate of 1 € to Litecoin is shown. Finally, the amount to be payed is shown in Litecoins, here 0,4213522 LTC.

[0288] If the user selects Litecoin for payment, e.g. by double tapping the Litecoin entry, the user interface may change to the exemplary user interface shown in FIG. 5.

[0289] In FIG. 5 the user interface comprises only the display 315. The display 315 shows a QR code that comprises all information required to perform a transaction. It is understood, that the user interface as shown in FIG. 5 may e.g. be used if the client wants to perform the transaction with his own device, e.g. with a smartphone that may scan the QR code with its camera.

[0290] The QR code on the display 315 may comprise for example the wallet address of the merchant wallet to which the transaction should be destined. In addition, the QR code may also comprise the amount of respective coins and/or assets that should be transferred. It is understood, that any other additional information may be embedded in the QR code. Such information may e.g. comprise tracking information for tracking the merchant's activities or for a cashback program or the like.

[0291] In another embodiment, the merchant terminal 301 may also output the transaction information via other interfaces, e.g. via a network interface like a WIFI or Ethernet interface, via a short distance like a RFID or NFC interface, or a wired interface or the like.

[0292] The client scans the QR code or receives the QR code via another interface in his device, e.g. his smartphone. He may then verify the transaction information, e.g. on the display of the smartphone, and then perform the transaction. In this case, the transaction processor may be integrated into a wallet application running on the client's device.

[0293] While the transaction is being created and processed in the cryptocurrency network, the display 315 may shown the status as “waiting”.

[0294] FIG. 6 shows the merchant terminal 301 after the transaction is being received. The display 315 still shows the QR code. However, after the transaction is received, the status below the QR code also shows “received” and a receipt of the transaction may e.g. be printed by the user by tapping the “print” button. Blow the print button a new transaction may be initiated via the “new payment” input.

[0295] It is understood, that specific settings may be provided in the merchant terminal or a respective service of the processing system, that specify how a transaction should be validated or rated as received. If in the used cryptocurrency, i.e. in the underlaying blockchain, forks may occur, a transaction may for example only be accepted if a specific number of blocks, e.g. 3, 4, 5, 6 or 7 blocks, have been created after the block comprising the transaction.

[0296] FIG. 7 shows a block diagram of a merchant terminal 401. The merchant terminal 401 comprises a merchant terminal controller 425 that is coupled to a user interface 415, to a transaction output interface 428, and to a first communication interface 426.

[0297] As explained above, the user interface 415 may e.g. comprise a display and a keyboard, a touchscreen, or any other type of user interface. The user interface 415 serves for receiving user input 419 from the user and for providing user information 420 to the user.

[0298] The transaction output interface 428 serves for outputting the transaction information 402. The transaction output interface 428 may be any type of interface that allows providing the transaction information 402 to the user terminal and/or the transaction processor. Such an interface may e.g. comprise a RFID interface, an NFC interface, a WIFI interface, a Bluetooth interface, an optical interface or the like.

[0299] The first communication interface 426 may e.g. be a network interface that allows the merchant terminal controller 425 to communicate e.g. via a data network like a local network or the internet.

[0300] During operation the merchant terminal controller 425 may for example receive user input 419 via the user interface 415 regarding an amount in a fiat currency and the cryptocurrency to be used for the transaction. The merchant terminal controller 425 may then automatically retrieve exchange information regarding the exchange rate of the cryptocurrency that is to be used for the transaction with regard to a reference fiat currency or a different cryptocurrency via the first communication interface 426. The merchant terminal controller 425 may also retrieve transaction fee information 427 regarding transaction fees for the transaction. The merchant terminal controller 425 may then e.g. calculate the total amount of coins and/or assets of the respective cryptocurrency to be paid and sum up the fees. This information, e.g. the total costs in the respective cryptocurrency, may then be provided to the user as user information 420 via the user interface 415. It is understood, that the user, i.e. the merchant, may also provide information about whether the fees should be paid by the merchant or the client.

[0301] If the user, i.e. the merchant, agrees to the transaction, the merchant terminal controller 425 generates the corresponding transaction information 402. The transaction information 402 comprises every piece of information that is required by the transaction processor to generate the transaction. The transaction information 402 for example may comprise a wallet address of a wallet of the operator of the merchant terminal 401 for the cryptocurrency that is used for the transaction. This wallet may e.g. be a wallet to which the automatic transaction handling processor has access, as will be described below. In addition, the transaction information 402 comprises the amount of coins and/or of assets in said cryptocurrency.

[0302] The merchant terminal controller 425 then outputs the transaction information 402 via the transaction output interface 428. The transaction information 402 may then be received by the client terminal, which is required to either perform the transaction or provide the required cryptographic key for performing the transaction.

[0303] In the client terminal, the client may review the transaction and initiate the transaction if he accepts the details provided with the transaction information 402.

[0304] In case the transaction is performed in the client terminal, the transaction processor is provided in the client terminal, e.g. as part of a wallet application. In case that the transaction is not provided in the client terminal, the transaction processor may e.g. be provided in the merchant terminal or as dedicated device, that may be accessible e.g. via a network connection. In this case, the client terminal may—e.g. after receiving the user's consent—provide the respective cryptographic key for performing the transaction.

[0305] It is understood, that in embodiments the user interface 415 and the transaction output interface 428 may both be the same interface, if the transaction information 402 is provided as visual code. However, it is possible that two separate displays are provided in the merchant terminal 401. A first display may be provided as the user interface 415 and a second display may be provided as the transaction output interface 428.

[0306] It is understood, that the transaction information 402 may be provided as human readable information instead of a code. This is especially useful, if the client terminal is for example a paper wallet or a mere memory or memory token without any display or user input. The user may then read the transaction information 402 and for example insert his memory card or token or provide his paper wallet to a scanner of the merchant terminal 401 if he accepts the transaction information 402.

[0307] FIG. 8 shows a block diagram of merchant terminal 501. The merchant terminal 501 of FIG. 8 comprises the transaction information as a visual code 502. The visual code 502 may e.g. be provided on a sticker or patch and may comprise the transaction information that is required to perform a transaction e.g. from a client terminal.

[0308] The transaction information embedded in the visual code 502 may for example comprise a wallet address of a wallet of the merchant, i.e. a wallet that pertains to the merchant and to which the automatic transaction handling processor has access. This wallet may be the above-mentioned system wallet.

[0309] A client may therefore scan the visual code with his client terminal. In the client terminal the client may then input the respective amount of coins and/or assets of the respective cryptocurrency and initiate a transaction.

[0310] The processing system may then e.g. inform the merchant about a transfer that is received by this address and about the amount of coins and/or assets, and optionally the respective value in a fiat currency, that have been received. This information may e.g. be passed to the merchant via another channel, e.g. via SMS, an email, a messenger message or the like.

[0311] However, as alternative, the transaction information embedded in the visual code 502 may also comprise the wallet address of a dedicated wallet of the operator of the processing system. The processing system may then e.g. automatically transfer any coins and/or assets incoming to this address as respective amount of a fiat currency to a bank account of the merchant.

[0312] As further alternative, the transaction information embedded in the visual code 502 may comprise information that may be provided as additional information in the transaction. Such additional information may e.g. be the number of a bank account of the merchant. The destination address for the transaction may in this case e.g. be the address of a wallet of the operator of the processing system. The operator may use the same wallet for multiple merchants. Any incoming transaction may then be analyzed by an element of the processing system for the additional information comprising a bank account number. Incoming coins and/or assets may then be transferred as respective amount of fiat currency to the bank account number as indicated in the additional information.

[0313] As will be shown in more detail below, the merchant terminal 501 may also comprise a display and dynamically create the visual code 502. Such a merchant terminal 501 may also comprise a network interface and e.g. retrieve a new address for every transaction or additional information for every transaction.

[0314] Using such a simple or even passive merchant terminal 501 allows any merchant to easily participate in the cryptocurrency market. Clients willing to pay with a cryptocurrency may already have a wallet application installed e.g. on their smartphone or the like and use the transaction information in the visual code 502 with the respective wallet application.

[0315] FIG. 9 shows a block diagram of a client terminal 503. The client terminal 503 comprises a memory token 530 with a memory 531 that is coupled to a communication interface 533. The memory 531 comprises at least the secret cryptographic key 532 that corresponds to a wallet or address of the client.

[0316] The memory 531 may be a tamper resistant memory with special features that prevent a malicious attacker from retrieving the secret cryptographic key 532 from the memory 531. Such a memory may e.g. comprise elements that erase the contents of the memory when an electronic or physical attack is detected. Further, the memory 531 may for example comprise encryption and decryption units for automatically encrypting and decrypting the contents of the memory 531. The key for encrypting and decrypting may e.g. be provided via the communication interface 533 or via dedicated means, like e.g. a fingerprint scanner on the memory token 530 or the like.

[0317] The communication interface 533 may be a contact-based communication interface 533, like e.g. a smartcard or memory card contact terminal. The communication interface 533 may also be a wireless interface, like e.g. a RFID or NFC interface.

[0318] FIG. 10 shows a block diagram of another client terminal 603. The client terminal 603 is based on the client terminal 503 and comprises a transaction processor 635 that is coupled to the memory 631 and to the communication interface 633. This means that the memory 631 is not directly coupled to the communication interface 633.

[0319] With the client terminal 603 the secret cryptographic key 632 is not provided from the memory 631 to the communication interface 633. Instead, the transaction processor 635 receives the information required to create the transaction, e.g. transaction information 602, creates the transaction 606 with the secret cryptographic key 632 and outputs the transaction 606 via the communication interface 633.

[0320] Using a “smart” client terminal 603, i.e. a client terminal 603 with the transaction processor 635 included, allows performing transactions without the need to transfer the secret cryptographic key 635 to another entity in the processing system.

[0321] FIG. 11 shows a block diagram of another client terminal 703. The client terminal 703 is provided as a memory card 736. The memory card is a contact-based memory card and therefore comprises a contact-based communication interface 733. The communication interface 733 is coupled to a memory 731 that comprises at least the secret cryptographic key 732 and possibly also the public cryptographic key (not separately indicated) of a pair of keys for a wallet of a cryptocurrency.

[0322] The memory card 736 may be in the form of cards as used e.g. for credit cards or the like. The memory card 736 may therefore have standard size and the communication interface 733 may e.g. be a standard contact-based or contact-type interface to the memory 731 in the memory card 736.

[0323] Therefore, in a counterpart, e.g. the merchant terminal, a respective card reader or card slot may be provided. Such a card reader or card slot may comprise respective contacts, e.g. spring-loaded contacts that contact the single contacts of the communication interface 733 when the memory card 736 is inserted into the card reader.

[0324] It is understood, that the contents of the memory 731, especially the cryptographic key 732, may be encrypted. Such an encryption prevents the use of the cryptographic key 732 without the owner's consent. The encryption may e.g. be performed based on a pin, a password, a fingerprint or any other security feature, and may e.g. be performed with the AES encryption algorithm or any other adequate encryption algorithm.

[0325] It is understood, that to this end, an encryption and decryption processor may be provided in the memory card 736.

[0326] It is understood, that although a contact-based or contact-type memory card 736 is shown in FIG. 11, the client terminal 703 may also be provided as a wireless smartcard, e.g. with an NFC or RFID interface or the like.

[0327] FIG. 12 shows a block diagram of another client terminal 803. The client terminal 803 comprises a smartcard 837. In the smartcard 837 a memory 831 is provided that stores the cryptographic key 832. Further, a transaction processor 835 is coupled to the memory 831. The transaction processor 835 is further coupled to a wireless communication interface 833.

[0328] The wireless communication interface 833 may for example be a RFID or NFC interface for wirelessly communicating with the smartcard 837, e.g. via a merchant terminal.

[0329] As with the client terminal 703, the cryptographic key 832 is stored inside of the client terminal 803, in the memory 831. However, the transaction processor 835 is arranged between the memory 831 and the wireless communication interface 833. Therefore, the cryptographic key 832 is not required to be transmitted via the wireless communication interface 833. Instead, at least some of the cryptographic functions required to perform a transaction may be performed directly in the transaction processor 835.

[0330] The transaction processor 835 may for example perform signature functions or encryption functions based on the cryptographic key 832 stored in the memory 831. To this end, e.g. the merchant terminal, may provide even transaction data to the transaction processor 835 via the wireless communication interface 833. The transaction data may for example comprise the data that needs to be signed or encrypted in order to provide a valid transaction. The transaction processor 835 may then e.g. output the signature for the transaction data via the wireless communication interface 833.

[0331] In another possible embodiment, the transaction processor 835 may receive the transaction information via the wireless communication interface 833. The transaction processor 835 may then create the transaction data by itself and perform the respective cryptographic functions. In this embodiment the transaction processor 835 may for example output the transaction data and the respective signature via the wireless communication interface 833.

[0332] The output from the smartcard 837 may then e.g. be received by the merchant terminal and may be provided to the respective cryptocurrency network, where the transaction may then be processed.

[0333] It is understood, that although the client terminal 803 is described with the wireless communication interface 833, in other embodiments a wired or contact-type interface may also be provided.

[0334] FIG. 13 shows a block diagram of another client terminal 903. The client terminal 903 comprises a smartphone 938. It is understood, that instead of a smartphone any other computing device, like e.g. a tablet PC, a notebook, a desktop computer or the like, may be provided for the client terminal 903.

[0335] The smartphone 938 comprises a memory 931 that is coupled to a processor 940. Further, the memory 931 comprises the cryptographic key 932 and an application 939.

[0336] In the client terminal 903 the function of the transaction processor may be provided by the application 939. The application 939 may therefore provide all functions that are mentioned in this document regarding the transaction processor.

[0337] It is understood, that such an application 939 may also provide additional functions, like e.g. an address or wallet management and the like. Such an application may generally be called a wallet application. It is further understood, that such an application may for example be executed by an operating system. Such an operating system may provide basic functionality to applications, like e.g. hardware access to interfaces like user interfaces, communication interfaces, or storage device like memories, hard disks and the like.

[0338] It is further understood, that the application 939 may also be a remote or web-based application. Such applications may be loaded by the operating system or another program, like e.g. a browser, into the memory 931 and may be executed after downloading. Web-based applications may especially be provided as script-based applications, e.g. a JavaScript based application and may be executed in the environment of a web-browser.

[0339] In an embodiment, the application 939 may further comprise encryption and decryption functions and the cryptographic key 932 may be stored in an encrypted format in the cryptographic key 932. As explained above any encryption algorithm may be used, like e.g. AES or the like. The security token or key, that is necessary to decrypt the encrypted cryptographic key 932 may for example be provided to the application 939 by a user via a user interface of the smartphone 938 or via a sensor, like e.g. a fingerprint sensor or a camera of the smartphone 938.

[0340] FIG. 14 shows a block diagram of another client terminal 1003. The client terminal 1003 comprises a memory 1031 that stores the cryptographic key 1032. The memory 1031 is coupled to a communication interface 1033 that allows the memory 1031 to output the cryptographic key 1032 on request. The client terminal 1003 further comprises a user interface 1041 that is coupled to the memory 1031.

[0341] The user interface 1041 is configured to receive from a user a user's consent 1042 and/or transaction information input 1043.

[0342] The user's consent 1042 may in an embodiment be required to enable the memory 1031 to provide the cryptographic key 1032 via the communication interface 1033. To allow a user to provide his consent 1042, the user interface 1041 may e.g. comprise a simple button. As alternative, the user interface 1041 may comprise a keypad for inputting a pin, a sensor like a fingerprint sensor or an iris scanner or the like. The user interface 1041 may then provide the enable signal to the memory 1031 after the user provides the required input.

[0343] It is understood, that the client terminal 1003 may comprise further elements, like e.g. a processor and that the processor may be coupled to the user interface 1041, the memory 1031 communication interface 1033, and may perform the required functions, like verifying the user's consent and then outputting the cryptographic key 1032 via the communication interface 1033. Such a processor may also perform the functions of a transaction processor.

[0344] If a processor is provided, the processor may also receive the transaction information input 1043 from the user via the user interface 1041. The processor may then create the data that is necessary for or that forms the transaction based on the transaction information input 1043 provided by the user and perform the required cryptographic functions.

[0345] FIG. 15 shows a block diagram of another client terminal 1103. The client terminal 1103 comprises a memory 1131 that stores a cryptographic key 1132. In addition, the client terminal 1103 comprises a setting memory 1145, wherein the setting memory 1145 and the memory 1131 are both coupled to a communication interface.

[0346] The setting memory 1145 stores user settings 1146. Such user settings 1146 may refer to preferences of the client, like e.g. to a preferred cryptocurrency. The client terminal 1103 may for a transaction output at least some of the stored user settings 1146, e.g. to the merchant terminal. The merchant terminal may then perform the respective selections, e.g. of the cryptocurrency, and create respective transaction information.

[0347] As an option, the setting memory 1145 may also store automatic transaction user settings 1147. The automatic transaction user settings 1147 enable automatic and therefore quick transactions, without specific consent of the user.

[0348] However, to prevent arbitrary transactions being performed from the clients' wallets, the automatic transaction user settings 1147 may provide specific details or requirements that have to be fulfilled in order to allow an automatic transaction taking place.

[0349] For example, a user may set a maximum amount of coins or assets for one or more cryptocurrencies that he consents to be automatically transferred in a transaction. The user may also set a maximum number of transactions for a predetermined amount of time. This automatic transaction user settings 1147 therefore define how many transactions may automatically be performed in the respective amount of time. The user may also define, with which cryptocurrency or cryptocurrency automatic transactions may be performed at all. It is understood, that the user may set any combination of the above automatic transaction user settings 1147.

[0350] A client may therefore for example specify that transaction to an amount of about 10€ in one or more cryptocurrencies that he specifies may be performed once every 10 minutes or every hour or the like. Any other combination of requirements is also possible.

[0351] It is understood, that the client terminal 1103 may for example comprise a processing device coupled between the memory 1131, the setting memory 1145 and the communication interface 1133. The processor may then verify that a transaction conforms to the automatic transaction user settings 1147 and only provide the cryptographic key 1132 or sign the respective transaction data or the like if the transaction conforms to the automatic transaction user settings 1147.

[0352] It is understood, that all the above elements described in conjunction with the client terminal may be feely combined. For example, the client terminal may comprise an application being executed on a computing device like a smartphone and the application may comprise the setting memory 1145 with user settings 1146 and/or automatic transaction user settings 1147. In addition, or as alternative, such a client terminal may also comprise the user interface for acquiring the user's consent, e.g. in the form of an input field on a touchscreen of the computing device. Further, such a client terminal may comprise a wired or wireless communication interface for communication with e.g. a merchant terminal. Such communication may be a direct communication e.g. via Bluetooth or the like or an indirect communication e.g. via a WIFI access point and a data network.

[0353] FIG. 16 shows a block diagram of an automatic transaction handling processor 1208. The automatic transaction handling processor 1208 comprises a transaction interface 1250 and a local transaction processor 1251 that is coupled to the transaction interface 1250. Further, a memory 1252 is coupled to the local transaction processor 1251. The memory 1252 comprises a predetermined transfer policy 1209 or multiple predetermined transfer policies.

[0354] The transaction interface 1250 may be a communication interface that allows the local transaction processor 1251 to communicate transaction data e.g. with a cryptocurrency network. This means for example, that the local transaction processor 1251 may receive transaction information 1202 or transaction data, i.e. in the form of the transaction of the data of the transaction or a block comprising the transaction that is communicated in the cryptocurrency network. In addition, the local transaction processor 1251 may communicate data into the cryptocurrency network or into multiple cryptocurrency networks. The local transaction processor 1251 may use the transfer policy 1209 and for example initiate respective transactions after receiving one or more transactions from a client wallet. Further, it is understood, that the local transaction processor 1251 may also communicate transaction data e.g. via a channel, like e.g. a channel of the lightning network that is being developed for the bitcoin network. The lightning network is a network that is provided parallel to the bitcoin network and provides channels for performing transactions off-line off the bitcoin network. Such channels may be considered as communication via the cryptocurrency network. At certain points in time, the balances of the channels may then be ausgeglichen via transactions in the bitcoin network.

[0355] This means, that the local transaction processor 1251 may e.g. act like a node in the cryptocurrency network that is capable of receiving data from the cryptocurrency network and capable of providing data into the cryptocurrency network. It is understood, that the local transaction processor 1251 may be a hardware unit or a computer program or a combination of both. The local transaction processor 1251 may for example be provided as an application that is executed by an operating system running on a server or e.g. as a cloud-based application.

[0356] As explained above, the local transaction processor 1251 may have access to a wallet of the merchant, that may e.g. be called the system wallet. The system wallet may for example serve to automatically redistribute and/or split incoming transactions. To this end, the local transaction processor 1251 may for example have direct access to the required cryptographic keys. Such cryptographic keys may e.g. be stored in the memory 1252 or such cryptographic keys may be stored in a wallet storage that may be provided in the processing system and will be explained in detail below. Further, instead of performing the transactions like a node of the respective cryptocurrency network, the local transaction processor 1251 may also access a service that allows performing transactions in the respective cryptocurrency network. It is understood, that such a service as well as the wallet storage may e.g. be provided as services that may be accessed with a specific API (application programming interface) via a network or on the same computer as the local transaction processor 1251.

[0357] The local transaction processor 1251 may therefore analyze or track all transactions that arrive for a merchant and may automatically perform respective redistribution or splitting transactions based on the transfer policy 1209.

[0358] The transfer policy 1209 may for example specify that every single incoming transaction is directly split and/or redistributed. As alternative the transfer policy 1209 may specify that splitting and/or redistributing is only performed after a specific amount of time has passed or after a predetermined number of transactions has been received for the respective merchant, or after a specific amount of coins and/or assets has been received by the respective merchant. Further, the transfer policy may indicate a target currency for the redistribution and/or splitting of the incoming transaction. This means that the local transaction processor 1251 may use different cryptocurrencies for splitting and/or redistributing than used for the initial transaction. To this end, the local transaction processor 1251 may be communicatively coupled to an exchange service, that allows the local transaction processor 1251 to exchange one cryptocurrency for another. The local transaction processor 1251 may e.g. receive the exchange coins, i.e. coins in the target cryptocurrency, from the exchange service to a wallet under his control and then perform the redistribution and/or splitting.

[0359] To reduce the number of required transactions and therefore the network load and e.g. transaction fees, the local transaction processor 1251 may for example indicate the final or target address to the exchange service and only transfer the respective amount of coins and/or assets to the exchange service. This will save the transaction from the exchange to the wallet under possession of the local transaction processor 1251 and the coins and/or assets will arrive more quickly at the final destination.

[0360] Splitting may then e.g. comprise transferring a part of the available coins and/or assets to a first address or wallet and transferring the remaining coins and/or assets to another address or wallet or to multiple addresses or wallets. Redistributing may comprise transferring at least a part of the available coins and/or assets of a merchant to one or multiple addresses.

[0361] A specific transfer policy may for example be provided for each of multiple merchant terminals, especially for multiple terminals operated by the same operator, or for multiple terminals operated by different operators. The transfer policy may also comprise a policy based on tracking information of the user of the client terminal and/or of the operator of the merchant terminal and/or of the merchant terminal itself. Such tracking information may e.g. be embedded as additional information in the transaction. Further, a standard transfer policy may be used for transactions if no specific transfer policy applies to the transaction.

[0362] It is understood, that the transfer policy not necessarily needs to be stored in the local transaction processor 1251. The transfer policy may also be provided at least in part by the merchant terminal and/or the client terminal to the automatic transaction handling processor 1208, e.g. via the transaction interface 1250.

[0363] FIG. 17 shows a block diagram of an exchange rate service 1355 and an exchange service 1360. It is understood, that although shown in a single figure, the exchange service 1360 and the exchange rate service 1355 may also be provided as single entities.

[0364] The exchange rate service 1355 comprises a communication interface 1356 and an exchange rate memory 1358. The exchange rate service 1355 is coupled to a network, e.g. the internet, via the communication interface 1356. The exchange rate service 1355 may therefore receive rate requests 1357 via the network. The exchange rate service 1355 may then look up the respective exchange rates 1359, that may e.g. be stored in the form of a table, from the exchange rate memory 1358 and provide the exchange rates 1359 to the source of the request, e.g. to a merchant terminal, or a client terminal, or an automatic transaction handling processor. In the exchange rate memory 1358 the exchange rates 1359 may be stored for different pairings of cryptocurrencies and/or cryptocurrencies and fiat currencies. In addition, the exchange rates 1359 may be stored for different exchange services 1360.

[0365] It is understood, that the exchange rate service 1355 may comprise additional elements, like e.g. an updating unit or processor that may update the exchange rates 1359 stored in the exchange rate memory 1358. The updating unit or processor may for example contact one or more exchanges via the network and retrieve the required exchange rates and store the requested exchange rates in the exchange rate memory 1358.

[0366] The exchange service 1360 comprises a communication interface 1361 and an exchange processor 1362 that is coupled to the communication interface 1361. The communication interface 1361 is externally coupled to the network in order to receive transactions and/or exchange requests, and in order to send transactions into the network.

[0367] The exchange processor 1362 performs exchanges between different cryptocurrencies and or between cryptocurrencies and fiat currencies, as requested e.g. via transactions 1306 or via exchange requests that arrive at the exchange service 1360.

[0368] If a transaction 1306 is used to request an exchange, this request may be specified in more detail in additional information that may be stored with the transaction. Such additional information may for example comprise a target currency, a user identification, a target address and/or a bank account number.

[0369] If for example the target currency comprises a cryptocurrency and a target address is given, the exchange processor 1362 may generate a respective transaction in the target currency to the target address with the respective amount of coins and/or assets. If no target address is given but a user identification is given, the exchange service may have the target address (and other user specific details) stored in a memory and retrieve the target address from the memory based on the user identification.

[0370] If the target currency is a fiat currency and a bank account number is provided in the additional data, the exchange processor 1362 may transfer a respective amount of the target currency to the target bank account. If no target bank account number is given but a user identification is given, the exchange service may have the bank account number (and other user specific details) stored in a memory and retrieve the bank account number from the memory based on the user identification.

[0371] It is understood, that the exchange rate service 1355 and the exchange service 1360 may both be provided as dedicated devices, e.g. servers. However, as alternative, the exchange rate service 1355 and the exchange service 1360 may be provided as computer program components, that may e.g. be services like web-services and provide a respective API for accessing their functions.

[0372] FIG. 18 shows a block diagram of an exchange rate optimizer 1465. The exchange rate optimizer 1465 serves for finding the optimum exchange rate or the optimum exchange 1469 to be used for a transaction. It is to be understood, that the optimum exchange rate or optimum exchange 1469 may not necessarily refer to the exchange with the lowest transaction fees or best exchange rate. Instead, the optimum exchange rate or exchange 1469 may also be selected based e.g. on an estimated duration for the transaction, i.e. the current load of the exchange.

[0373] The exchange rate optimizer 1465 comprises a communication interface 1466 and an optimization processor 1468 that is coupled to the communication interface 1466. Via the communication interface 1466 the optimization processor 1468 may receive optimization requests 1467, e.g. from a merchant terminal, from a client terminal or from an automatic transaction handling processor.

[0374] The optimization processor 1468 may for example store and/or request via an exchange rate service exchange rates for a plurality of possible exchanges between cryptocurrencies and between cryptocurrencies and fiat currencies.

[0375] An optimization request 1467 may comprise a source and a target currency (crypto or fiat currencies). The optimization processor 1468 may then perform the solving of an optimization problem that may be formulated as finding the best exchange (e.g. the cheapest with regard to fees, or the most balanced with regard to fees, speed, reliability, security, juridical requirements, availability in respective countries, etc.) or exchange route.

[0376] The optimum exchange 1469 or exchange route 1470 is then provided by the optimization processor 1468 as response to the optimization requests 1467.

[0377] It is understood, that the exchange rate optimizer 1465 may be provided as dedicated device, e.g. a server. However, as alternative, the exchange rate optimizer 1465 may be provided as computer program component, that may e.g. be a service like a web-service and may provide a respective API for accessing the respective functions.

[0378] FIG. 19 shows a block diagram of a transaction verification controller 1571. The transaction verification controller 1571 comprises a communication interface 1572 and a monitor 1573 that is coupled to the communication interface 1572. The communication interface 1572 is coupled to the network.

[0379] The transaction verification controller 1571 serves for monitoring the status of a transaction 1506. The status of a transaction 1506 may refer to whether the transaction 1506 is received in the cryptocurrency network, whether the transaction is included in a block of the respective blockchain or if a predetermined number of transactions have been created after the block that contains the transaction 1506.

[0380] The monitor 1573 may be any device or unit that has access to the respective cryptocurrency network and may retrieve open transactions and created blocks from the cryptocurrency network. Therefore, the monitor 1573 may e.g. implement the communication interface or communication functions of a node of the respective cryptocurrency network. Further, the monitor 1573 may implement a parser or analyzer function that verifies if specific criteria are fulfilled, like e.g. the transaction being present in the cryptocurrency network, the transaction being included in a block of the respective blockchain, and the number of blocks being created after the blocks containing the transaction.

[0381] The monitor 1573 may e.g. report a transaction 1506 as received or pending, if it is received in the cryptocurrency network but not included in a block. The monitor 1573 may report the transaction 1506 as processed if the transaction 1506 is included in a block. The monitor 1573 may report a transaction 1506 as received or finished, if a predetermined number of blocks, e.g. 5, have been created in the blockchain after the block containing the transaction 1506. It is understood, that the measure 1574 may e.g. be a numerical measure 1574, e.g. comprising 0 for not received, 1 for received, 2 for processed, 3 for finished. It is understood, that the measure 1574 may for example also comprise a value between 0 and 100, the chances of success of the transaction 1506, a risk of failure of the transaction 1506, an estimate of the time for finalization of the transaction, possible other risks or the like.

[0382] It is understood, that the transaction verification controller 1571 may be provided as dedicated device, e.g. a server. However, as alternative, the transaction verification controller 1571 may be provided as computer program component, that may e.g. be a service like a web-service and may provide a respective API for accessing the respective functions.

[0383] FIG. 20 shows a block diagram of a fork detection system 1675. The fork detection system 1675 may e.g. be coupled to the transaction verification controller 1571 and provide the transaction verification controller 1571 with an indication of whether a fork is present in a blockchain or not. This may allow the transaction verification controller 1571 to dynamically adapt the number of blocks necessary to accept a transaction 1506 as finished.

[0384] The fork detection system 1675 serves for monitoring a blockchain for the occurrence of a fork. Miners of a blockchain will usually be provided at spots, i.e. in countries, with low energy costs. Therefore, the miners of a cryptocurrency network will usually be located in specific spots or locations. Such locations are shown as miner locations 1680, 1681, 1682. The miner locations 1680, 1681, 1682 are coupled to the network, e.g. the internet. It is understood, that although shown as circles, the miner locations 1680, 1681, 1682 may refer to a region like a country or any geographically limited region where the number of miners is relatively high compared to the mean density of miners over the globe or over the network. It is understood, that the term region may also refer to a network region, i.e. to nodes in a network that are interconnected by connections faster than other regions in the network. In terms of the network, a region may for example comprise miners in Europe, Asia and America which are interconnected by very fast communication links.

[0385] To identify a fork in a blockchain, the fork detection system 1675 comprises three nodes 1677, 1678, 1679 which are coupled to a central server 1676, where each of the nodes 1677, 1678, 1679 is provided at one of the miner locations 1680, 1681, 1682.

[0386] The nodes 1677, 1678, 1679 will therefore quickly receive any new blocks that are created in the respective miner locations 1680, 1681, 1682. Every one of the nodes 1677, 1678, 1679 then forwards any new blocks to the central server 1676. The central server 1676 then compares the received blocks and provides a fork warning if two blocks of the same block number comprise different content.

[0387] If for example in miner location 1680 and miner location 1681 a block 100 is created at approximately the same time with different content, the node 1677 will first receive the block 100 from miner location 1680, and node 1678 will first receive the block 100 from miner location 1681.

[0388] The central server 1676 will receive both blocks and detect the differences. Consequently, the central server 1676 will provide a fork warning.

[0389] It is understood, that the function of the central server 1676 may also be implemented in one of the nodes 1677, 1678, 1679.

[0390] FIG. 21 shows a block diagram of a wallet storage 1785 and a wallet generator 1788. It is understood, that although shown in the same figure, the wallet storage 1785 and the wallet generator 1788 may be provided independently of each other.

[0391] The wallet storage 1785 may comprise a simple memory 1787 that may store wallets, like e.g. the system wallet and the storage wallet of a merchant. It is understood, that the term “storing” with reference to a wallet refers to storing the respective cryptographic keys, especially the secret cryptographic key, addresses, settings and any other relevant data, like metadata about the users and/or the wallets. It is further understood, that the wallet storage 1785 may also comprise a local database or a remote database, e.g. as a service of the processing system.

[0392] The wallet storage 1785 may in an embodiment store the respective keys in encrypted form and may comprise an encryption and/or decryption unit that performs the encryption and decryption of the cryptographic keys.

[0393] Although not shown, an authentication mechanism may be implemented in the wallet storage 1785 and/or the wallet generator 1788 or may be provided as a service via the network. The wallet storage 1785 and/or the wallet generator 1788 may then only provide data to or exchange data with authenticated peers.

[0394] Therefore, for example the automatic transaction handling processor may request from a merchant the respective authentication credentials and may then request the respective cryptographic keys from the wallet storage 1785 to perform respective transactions. The automatic transaction handling processor may also store the cryptographic keys to the system wallets in the wallet storage 1785 and may request these as required to perform the splitting and/or redistribution of coins and/or assets.

[0395] In the processing system the initial creation of the wallets, e.g. the system wallet and the merchant wallet of a new merchant, may e.g. be performed manually by the respective merchant. However, as alternative, the wallet generator 1788 may generate the respective wallets automatically on request. It is understood, that a single wallet, i.e. a pair of a public and a private cryptographic key may in some cases be used only once. Therefore, the wallet generator 1788 may generate new cryptographic keys as required during the operation of the processing system. Merchant terminals or client terminals may for example request new wallets, addresses or cryptographic keys for every transaction.

[0396] It is understood, that the merchant terminals, client terminals and the automatic transaction handling processor may also authenticate with the wallet generator 1788 as explained above for the wallet storage 1785.

[0397] FIG. 22 shows a block diagram of a directive verification processor 1792. The directive verification processor 1792 may comprise at least one private key 1795 of the two private keys to which the processing system has access for the system wallet, if the system wallet is provided as a 2-of-4 wallet. This means, that the other private key may be stored e.g. in the above-mentioned wallet storage. As alternative, both private keys to the system wallet may be stored in the directive verification processor 1792. It is understood, that the explanations regarding the directive verification processor 1792 may also be applied to the storage wallet.

[0398] The directive verification processor 1792 verifies if a transaction conforms to predetermined directives or policies as mentioned above prior to releasing the private key 1795 for performing the respective transaction.

[0399] With the directive verification processor 1792 it can therefore be made sure, that no arbitrary transactions are performed but that only those transactions that conform to the directives are performed e.g. from the system wallet.

[0400] The directives may e.g. comprise a receiving address to which the transaction has to be destined, a maximum amount of coins and/or assets, a specific cryptocurrency, and the like.

[0401] It is understood, that the directive verification processor 1792 may be provided as dedicated device, e.g. a server. However, as alternative, the directive verification processor 1792 may be provided as computer program component, that may e.g. be a service like a web-service and may provide a respective API for accessing the respective functions. Further, the directive verification processor 1792 may be communicatively coupled to an authentication service and only serve authenticated users.

[0402] Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations exist. It should be appreciated that the exemplary embodiment or exemplary embodiments are only examples, and are not intended to limit the scope, applicability, or configuration in any way. Rather, the foregoing summary and detailed description will provide those skilled in the art with a convenient road map for implementing at least one exemplary embodiment, it being understood that various changes may be made in the function and arrangement of elements described in an exemplary embodiment without departing from the scope as set forth in the appended claims and their legal equivalents. Generally, this application is intended to cover any adaptations or variations of the specific embodiments discussed herein.

[0403] The present disclosure provides a processing system 100 for processing a number of cryptocurrencies, the processing system 100 comprising a merchant terminal 101, 201, 301, 401, 501 configured to generate transaction information 102, 402, 502, 602, 802, 1202, a client terminal 103, 503, 603, 703, 803, 903, 1003, 1103 1903 configured to provide a cryptographic key 104532, 632, 732, 832, 932, 1032, 1132, required for performing a transaction 106, 606, 806, 1206, 1306; 1506 based on the generated transaction information 102, 402, 502, 602, 802, 1202, a transaction processor 105635, 835 configured to provide the transaction 106, 606, 806, 1206, 1306; 1506 as indicated by the transaction information 102, 402, 502, 602, 802, 1202 based on the cryptographic key 104532, 632, 732, 832, 932, 1032, 1132, provided by the client terminal 103, 503, 603, 703, 803, 903, 1003, 1103 1903, and an automatic transaction handling processor 108, 1208, configured to process transactions 106, 606, 806, 1206, 1306; 1506 generated by the client terminal 103, 503, 603, 703, 803, 903, 1003, 1103 1903 and to automatically split and/or redistribute transferred funds based on a predetermined transfer policy 109.

TABLE-US-00001 List of reference signs 100 processing system 101, 201, 301, 401, 501 merchant terminal 102, 402, 502, 602, 802, 1202 transaction information 103, 503, 603, 703, 803, 903, 1003 client terminal 1103 client terminal 104, cryptographic key 105, transaction processor 106, 606, 806, 1206, 1306; 1506 transaction 107 cryptocurrency network 108, 1208, automatic transaction handling processor 109, 1209, predetermined transfer policy 110, 111 outgoing transactions 215, 315, 415 user interface 216, 316 keyboard 217 display 218 user 219, 419 user input 220, 420 user information 425 merchant terminal controller 426 first communication interface 427 status, exchange and/or transaction fee information 428 transaction output interface 530, 630 memory token 531, 631, 731, 831, 931, 1031, 1131 memory 532, 632, 732, 832, 932, 1032, 1132 secret cryptographic key 533, 633, 733, 833, 1033, 1133 communication interface 635, 835 transaction processor 736 memory card 837 smartcard 938 smartphone 939 application 940 processor 1041 user interface 1042 user's consent 1043 transaction information input 1145 setting memory 1146 user settings 1147 automatic transaction user settings 1250 transaction interface 1251 local transaction processor 1252 memory 1355 exchange rate service 1356 communication interface 1357 rate request 1358 exchange rate memory 1359 exchange rates 1360 exchange service 1361 communication interface 1362 exchange processor 1363 cryptocurrency 1364 fiat currency 1465 exchange rate optimizer 1466 communication interface 1467 optimization request 1468 optimization processor 1469 optimum exchange 1470 exchange route 1571 transaction verification controller 1572 communication interface 1573 monitor 1574 measure 1675 fork detection system 1676 central server 1677, 1678, 1679 node 1680, 1681, 1682 miner location 1785 wallet storage 1786 communication interface 1787 memory 1788 wallet generator 1789 communication interface 1790 system wallet 1791 storage wallet 1792 directive verification processor 1793 memory 1794 communication interface 1795 private key S1, S2, S3, S4 method steps S11, S12, S13, S14 method steps S21, S22, S23, S24 method steps S31, S32, S33, S34 method steps