PURCHASE AND PAYMENT METHODOLOGIES AND TECHNIQUES BASED ON BLOCKCHAIN ​​TECHNOLOGY

Description

Title: “METHODOLOGIES AND TECHNIQUES FOR PURCHASE AND PAYMENT BASED ON BLOCKCHAIN ​​TECHNOLOGY” * * * * * FIELD OF INVENTION The present invention relates to a system for purchasing, managing and validation of public transport travel tickets based on the use of the blockchain technology. This solution can also be used for toll payments motorways, payments for parking in closed car parks and for access to restricted areas limited traffic (ZTL). FRONT TECHNIQUE The Applicant has a Virtual Ticketing System (VTS) Framework for the management of dematerialized securities, both subscriptions on dematerialized cards and impersonal securities (tickets and carnets). Even though the Virtual Ticketing System has been integrated with the various services offered by the Payment Service Provider (PSP) is always the end user (i.e. the payment company) transport) which must activate these payment services. Furthermore, Payment Service Providers are the providers of payment services via internet, or the entities that act as financial intermediaries in payments carried out via the internet channel, and typically each Payment Service Provider a portion of the transaction is reserved as a premium. This approach, followed by the large transport companies, is not viable for the small operators (small businesses) as the complexity of the operations to be carried out to activate payments and contracts to be formalized, it could be such as not to justify the benefits due from the sale of securities (especially on the Payment side) Service Provider). Even from a user experience point of view, having to use a credit card credit (or similar) every time you buy a ticket is not exactly the best of comfort especially on public transport. To overcome the above problem, other APP application providers have adopted the following approach, i.e. the user tops up (for example in euros), a every now and then, a wallet on their APP and then use that credit for the purchase real titles. This approach, however, may not be applicable in all situations. companies due to the current banking regulations as the APP manager that contains the wallet acts like a bank, that is, it holds money on account third parties. As is known, in order to be able to "safeguard" money on behalf of third parties, certain special authorizations, not easy to obtain. SUMMARY OF THE INVENTION The purpose of the invention has been achieved by a system as defined in claim 1. The present invention relates to a system for purchasing travel tickets and for the toll and / or parking payment based on the use of Blockchain technology. The system includes a VTS Server, a Blockchain Server Node synchronized with a Blockchain network and a plurality of Smartphone user devices. On each Smartphone user device has an application for managing the purchases from at least one transport company and one manager. The Smartphone user device is equipped with a first public address and the Company transport or the Manager is equipped with a second public address. The Blockchain Server Node is connected via a Peer to Peer connection to the Blockchain, and stores and locally maintains a copy of the Blockchain, i first public addresses associated with each user and the users' private keys. VTS Server creates public addresses for each application associated with a user, calculates the user's current balance and creates, if there is sufficient currency, a pass that generates a transaction on the Blockchain and authorizes it through the user's private key stored in the Blockchain Server Node. The transaction transfers the content, or part of it, from the first wallet owned by the user and associated with a first public address to a second wallet owned by the Company or Manager and associated with a second public address. In particular, the VTS Server is a node of the reference Blockchain network and uses the Blockchain Server Node node as an access point to the Blockchain, and is natively connected to the Blockchain via the Blockchain Server Node node for operate natively on it by creating internal public addresses and is configured to create and manage payment transactions on the Blockchain. The Blockchain Server Node, after the first synchronization, contains inside it a local copy of the entire Blockchain. More specifically, payment transactions from the first wallet to the second wallet of Transport company properties are recorded on the Blockchain Server Node from the VTS Server and then automatically replicated, from the Blockchain Server Node on the other nodes of the Blockchain network via P2P connection. The VTS Server manages the lifecycle of the first public addresses associated with users of Smartphones for creation, phone change and current balance calculation; manages the payment lifecycle for each Smartphone by calculating the amount due making euro / crypto conversions and taking care to withdraw any premiums from pay into the service provider's wallet on Software as a Service -SAAS systems; selects and optimizes cryptocurrency transactions to cover the amount due, minimizing the number of transactions to be used to limit costs of the transaction itself; and creates and manages economic transactions taking care of calculate the various components and then sign correctly with the private key associated with the Smartphone phone. Additionally, the Blockchain Server Node is configured to handle the Peer to Peer connection. Peer to Blockchain and synchronization of local data with public data and vice versa; manage the local cryptocurrency wallet that contains the set of keys private Smartphones); and execute commands sent by the VTS Server. The application downloaded on the Smartphone has a public address on the Blockchain and the user tops up his wallet with cryptocurrencies in real time standard. Travel tickets can be purchased via cryptocurrencies, in advance of for the enjoyment of the trip itself and used subsequently. Alternatively, travel tickets can be purchased using cryptocurrencies, “on demand” in which, through a single gesture, the user exercises the will to carry out a travel, pay for it via cryptocurrency and validate it via a validator that works in Bluetooth Low Energy. Alternatively, travel tickets can be purchased using cryptocurrencies and paid after the fact where the amount to be paid via cryptocurrencies is managed in best fare or best rate mode. The system allows the payment of travel tickets through the management simultaneous management of multiple Blockchains for simple, multi-wallet management of travel ticket payments by users. The system allows the payment of travel tickets both in autonomous and in automatic mode. Mobility As A Service, MAAS, mode, in which the system separates "at the root", in automatic mode, the amount due to the transport operator from the one due to the service provider as a fee. The system allows for deferred payments so as to optimize the size of transactions on Blockchain and consequently reduce the costs due to the transactions themselves. The system provides the possibility to optimize transactions and write them on the Blockchain when a certain value is reached such as a spending threshold or a time threshold. BRIEF DESCRIPTION OF THE FIGURES In the following of this description reference will be made to the drawings shown in the attached figures, in which: - Figure 1 shows the architecture of the system according to the invention. The parts according to this description have been represented in the drawings, where appropriate, with conventional symbols, showing only those specific details that are relevant to the understanding of the embodiments of this invention, so as not to highlight details that will be immediately evident to expert technicians of the art, with reference to the description given here. DETAILED DESCRIPTION OF THE INVENTION The solution according to this will now be described with the help of drawings. invention. First of all, it is worth briefly describing the technology blockchain. A Blockchain 100 is a distributed ledger that records economic transactions between anonymous subjects via public addresses (public addresses). This registry is distributed and replicated across all server nodes participating in the network. Blockchain 100 in Peer to Peer (P2P) mode. This way no node has the control of the infrastructure and no one can alter or falsify the content of such distributed ledger, as each node has an updated copy of the Blockchain 100. An economic transaction TE on Blockchain 100 consists of recording that the contents of a container (for example called UTXO in the Bitcoin world, i.e. Unspent Transaction Output – i.e. Unspent Transaction Output) containing an NN number of cryptocurrencies (or fractions thereof) are passed as property from public address A, i.e. from wallet A, to public address B, i.e. a wallet B. In general, multiple incoming UTXOs can be combined together, within the same transaction, to reach the amount due. Any remainder of the payment transaction, in the case of an amount higher than the amount due, is hijackable in the original wallet wallet A. With reference to Figure 1, in the solution proposed here the architecture is composed from the following macro-components: a VTS 10 Server, a Blockchain Server Node 15, a plurality of Smartphones 20, and a P2P Connection 30 between the Blockchain Server Node 15 and the Blockchain 100. On every Smartphone 20 is downloaded and an APP is available for communication with the VTS 10 Server. The APP is in substance the customer's registration to the service offered, for example by a company transport 40. Every time an APP is downloaded on the VTS 10 Server a entity associated with the user who owns the Smartphone 20. The solution proposed here is also based on these three basic concepts. Each VTS 10 Server is also a node of the reference Blockchain 100 network (Bitcoin, Ethereum, Dogecoin, …). In particular, it is the task of the VTS 10 Server to create and manage TE transactions. (via UTXO transactions, for example) for the public addresses belonging to him. Each Smartphone 20(i) associated with a customer via the APP(i) application has of its own public addAPP(i) address of the Blockchain 100 network. It is the VTS Server 10 which manages both the public address addAPP(i) of the Smartphone 20(i) and the TE payment transactions to Transport Company 40 (for example by calculating the amount due by combining the appropriate UTXOs). Each Transport Company 40 has its own public address add40 always of the Blockchain 100 network. This add40 address could be managed by the Server VTS 10 or from an external crypto exchange. For the solution to work the VTS 10 Server must be able to act as a node of the Blockchain Network 100. In fact, to access a Blockchain 100, that is, to create wallets, public addresses, create financial transactions, manage the balances of the various wallets, have the list of transactions made, check the status of payments, etc. you need to connect to the Blockchain 100. To perform the above operations the VTS 10 Server has two possibilities among which choose: use an external paid manager or become one yourself a node of the Blockchain 100 network. The solution proposed here involves using the second possibility, that is, doing so that the VTS Server 10 becomes a node of the Blockchain 100. There are open source implementations that allow connection to the Reference Blockchain, such open source implementations are in use on thousands of nodes in the world for years such as Bitcoin Core or Dogecoin Core. Referring to Figure 1, the VTS 10 Server uses the Blockchain Server node Node 15 as an access point (proxy) to Blockchain 100. In the solution described here, being natively connected to Blockchain 100, via the Blockchain Server Node 15 node which acts as a proxy, the VTS Server 10, operates natively on it, thus being able to create internal public addresses and transactions of payment on the reference Blockchain 100. The Blockchain Server Node 15 node, downstream of the first synchronization, contains inside it a local BC copy of the entire Blockchain 100 (kept synchronous). This way, the system is immune to network failures and any search on the Blockchain 100 happens via a local copy. TE payment transactions from the customer's APP(s) 20w(i) wallet to the wallet of the Transport Company 40 are immediately registered on the Blockchain Server Node 15 from the VTS 10 Server and then automatically replicated from the Blockchain Server node Node 15, on the other nodes of the Blockchain network 100 (via P2P connection 30) once they are confirmed by the mining network. TE payment transactions, recorded on the local Blockchain Server Node 15 cost a few cents or less, depending on the cryptocurrency selected, and they do not require an intermediary or middle-man to be executed. The VTS 10 Server has the dual task of relating to both the Smartphone 20 of the user through the APP application for ticketing purposes (as already happens today) than with the Blockchain Node 15 as explained in the following description. It is therefore the VTS 10 Server which, in addition to the ticketing functions already present, carries out the following other useful features for this solution: - manages the life cycle of the addAPP public addresses associated with the Smartphone users 20 (creation, phone change, current balance calculation Smartphone 20 on Blockchain 100); - manages the payment lifecycle for each Smartphone 20 (calculates the amount due by making the euro / crypto conversions) and taking care to withdraw (at the source) any additional fees to be paid into the service provider's wallet on software systems as a Service – SAAS; - chooses and optimizes cryptocurrency TE transactions (associated UTXOs to the Smartphone 20) in order to cover the amount due, minimising the number of UTXO transactions to be used (to limit transaction costs; in fact, each transaction has a cost which is also linked to the number of UTXOs used); And - creates and manages TE (UTXO) economic transactions taking care of calculate the various components and then sign correctly with the private key KEYpr associated with the Smartphone 20 phone (i.e. the user registered via the APP). The Blockchain Server Node 15 node is a standard component of the Blockchain (and example Bitcoin Core) which performs the following functions: - Peer to Peer connection to Blockchain 100 and synchronization of local data with public data and vice versa; - management of the local 15w cryptocurrency wallet (set of keys private Smartphones 20); and - execution of commands sent by the VTS 10 Server. Each APP(s) downloaded onto a Smartphone 20(i), and activated as such, will have a own public addAPP(i) address on the independent Blockchain 100. This public addAPP(i) address is created automatically by the VTS 10 Server via the JSON-RPC interface protocol within the associated 15w local wallet to Blockchain Server Node 15 which interfaces with Blockchain 100. In practice, the various crypto systems (for example Bitcoin Core) allow you to have a single 15w local wallet on the server and N independent addAPP(s) public addresses (addAPP1, addAPP2, … addAPPn). To each public address addAPP(i) corresponds to a private key KEYpr(i) that the VTS 10 Server manages on behalf of the Smartphone 20(i). Even the transport companies 40 or transport operators have their own public add40 address on Blockchain 100. This add40 address does not It must necessarily be created by the VTS 10 Server locally, but it can be It's a good idea to use an existing address configured on the Control Center. Corporate CCA, created on an external system (Binance, Coinbase, …) as explained below. Blockchain Server Node 15 is responsible for creating the physical local wallet 15w (wallet.dat), encrypted and protected by a passphrase, which is intended to keep secret the set of private keys KEYpr(i). This 15w physical local wallet does not contain cryptocurrencies and / or balances of Smartphone 20(i). This information, i.e. the balance associated with each Smartphone 20(i), is contained only within the Blockchain 100 and is calculated on the fly by the VTS Server 10 via call to Blockchain Server Node 15 using the address public addAPP(s) of Smartphone 20(s). The phase of recharging and purchasing securities, which is based on these initial considerations, is described below. Here are reported the steps to be performed on a generic APP(s) for the phase of top up wallet and purchase securities on a smartphone 20(i). The APP(i) therefore has a public addAPP(i) address on the Blockchain (public address) and this addAPP(i) address is generated one-time by the VTS 10 Server when first connecting the APP(s) to the VTS 10 Server. VTS 10 Server stores the address value in the local DBloc database public addAPP(s) (non-sensitive information) to handle cases where the user uninstall the APP by mistake and / or change your Smartphone 20(x). In particular, if the user installs the APP again, because he deleted it by mistake or because changed phone, the VTS 10 Server recognizes the device (via a special DeviceId managed by the VTS 10 Server itself) and retrieves the public address addAPP(i) associated with that user registered on the APP and reassigns it to them. The VTS 10 Server ensures that if you change your phone (Android to Android or IOS on IOS), the DeviceId is maintained (the Google “cloud” is used or Apple to associate the Google / Apple user with the DeviceId). In case the transfer takes place on "mixed" devices (Android on IOS or IOS on Android) the system provides a specific “data movement” function which “migrates” content from DeviceIdOld to DeviceIdNew. This function uses the user email (after verification by sending OTP) as “ID of the person” to then identify the “set of devices” available for the move. The idea is to manage the “Public Address Crypto” among the data that migrates from DeviceIdOld to DeviceIdNew. The private keys KEYpr(i) are instead stored only in the 15w wallet of the Blockchain Server Node 15 and are not known to the VTS Server 10. The user charges his wallet 20w (with cryptocurrencies) in full mode standard, that is, the APP shows the QR Code of the public address addAPP on the screen and / or allows you to copy its alphanumeric value where needed; an example of public address is: «DNnGtXk9khadE7EKCmQzxjnehenX92PKAv». To recharge the 20w wallet you can use any method compatible with the Blockchain 100 chosen. You can purchase cryptocurrencies and associate them with the user(s) via his / her address public addAPP(s). Buying cryptocurrencies is seen as a TE transaction and for example if a user (i) buys for 20€ in his wallet 20w(i) he finds himself the equivalent of, for example, 4.5 Dogecoins, or a value of €19 (which corresponds to the initial money minus the costs of the transition on the Blockchain 100 and the cost retained by the service provider who performed the cryptocurrency purchase). Every time a user (x) tops up his wallet w(x) and every time he uses the funds in his wallet w(x), a TE transaction occurs which has costs. In particular, The TE transaction has a cost when it is written to the Blockchain 100. Therefore, This solution provides the ability to optimize TE transactions and write them on Blockchain 100 when a certain value is reached (for example spending €10) or when a certain amount of time passes (for example a week). So user (x) can make different transactions TE1(x), TE2(x), TE3(x) etc. and when the total number of transactions reaches a certain threshold (of currency or time) TE(x)tot is written to Blockchain 100. This deferred payment method is managed by the VTS 10 Server and allows therefore the decrease in the number of TE transactions (per user) and consequently the costs of the TE transactions themselves. The deferred payments described above, in addition to allowing for cost containment, They also allow the implementation of policies by the VTS 10 Server tariffs with payment at a later date, known in literature as best fare tariffs as we will see later. The VTS 10 Server must keep track of the different TE(i) transactions and also the exchange rate on the day of the TE(i) transaction, so that the correct calculation can be made of the due and also to be able to inform the user about the payments made in the currency local (e.g. in euros). Transport Companies 40 or Transport Operators are not involved in this phase and / or do not have to ask for any banking authorization as the economic transactions take place entirely on the Blockchain and not in the circuits banking. Cryptocurrencies topped up by user (x) do not go into the VTS 10 Server wallet, but are simply registered within the Blockchain 100 in the name of the APP(x) downloaded on Smartphone 20(x). When user (x) wants to make a purchase of a travel ticket on the VTS 10 Server, the latter verifies the balance associated with that user (x) via the public address addAPP(x) asking the Blockchain Server Node 15 which scans the local copy BC of Blockchain 100 and responds. If the user's (x) wallet is 20w(x), net of transactions not yet recorded on the Blockchain (see payments made in deferred mode), has capacity, the sale proceeds and a TE transaction is stored from the user's wallet (x) to the 40w wallet of the transport company 40. As explained above, this transaction can occur immediately or in a deferred manner. This option is managed from VTS 10 Server based on the chosen local configuration. The payment phase of the travel ticket is then managed by the VTS 10 Server that executes a transaction on the Blockchain 100 (via the Blockchain Server Node 15) of this type: Move «xx.xxx» cryptocurrencies or fractions thereof, from WalletA 20w(i) (of the smartphone 20(i)) to WalletB 40w (of transport company 40). The local Blockchain Server Node 15 node allows the VTS Server 10 to operate on the Blockchain 100 network (Bitcoin or Dogecoin or others) natively allowing fast and cheap transactions. The cost of the transaction depends on the Blockchain used. In general, for economic and / or technology diffusion and / or commercial reasons, Simultaneous interaction with multiple different Blockchains may be required (e.g. Bitcoin, Dogecoin, Ethereum, …) for which the system described here is designed to be able to manage, right from the start, a use in multi-blockchain mode, that is, a only 10 VTS Servers and N number of different Blockchain Server Node 15 servers. It is The task of the VTS 10 Server is to manage and convey payments on the correct Blockchain. The transport company 40 never pre-collects anything on behalf of third parties, the user in fact has a own virtual wallet 20w and the status of that 20w wallet is not written in the servers of the transport company 40, but in the Blockchain 100. Using this solution it becomes simple to implement multi-systems operator (see MAAS systems or Mobility As A Service) as each company 40(j) would have its own 40w(j) wallet so no policies need to be made clearing a posteriori as each sale ends up directly in the 40w(j) wallet destination thanks to the VTS 10 Server that manages TE transactions. Please note that the local DBloc database of the VTS 10 Server does not contain wallet balances. 20w(i) of the users and / or the private keys KEYpr(i) of the users themselves for which it does not is a possible point of attack by external hackers and / or does not require additional hardening compared to what is already present on corporate servers today. In fact, to move cryptocurrencies, you need to have access to the private key. KEYpr(i) of the real 20w(i) wallet. These KEYpr(i) keys are securely stored within a dedicated local file (e.g. «Wallet.dat») managed directly, in a manner secure, from Blockchain Server Node 15. This security is therefore guaranteed by the Blockchain Server Node 15 itself. The Blockchain Server Node 15, in its various implementations, is open source and installable on both Windows and Linux systems. The Blockchain Server Node 15 also has the encrypted backup function of the 15w local wallet that is saved, at pre-set intervals, in a protected environment and managed through backup policies. This is to prevent data loss and / or a attack on the server hosting the Blockchain Server Node 15, could inhibit access to the local wallet 15w and therefore to all the virtual wallets 20w(i) of the APP(s) thus making related cryptocurrencies are unusable. This backup function is also managed, in automatic, from the VTS 10 Server itself. The payment system described here allows for two different business models in based on the economic size of the transport company involved: a) Customer 40a (large transport company) purchases the entire infrastructure described here and if you install it in-house (i.e. you own the servers and take care of their installation) and maintains and governs the network infrastructure to ensure access to the network P2P). In this case the Applicant sells the system and provides technical assistance; b) Customer 40b (small transport company) does not purchase and / or own the server or system (see network infrastructure), but a service. In this case the Applicant, in addition to receiving an annual fee as a subscription to the service, reserves a percentage of sales as a premium. In the second case of the “Software As A Service” approach, SAAS, the VTS 10 Server when making payments, it already separates the premium from the amount paid, that is: - VTS 10 Server copies 95% of the amount into the Company's 40w(b) Wallet 40b, who then cashes out through a bank (increasingly traditional banks will offer this service) or a crypto exchange (Binance, Coinbase, eToro, Nexo, Gemini, …); - VTS Server 10 copies 5% (for example) as a premium percentage in the Private wallet of the Applicant who occasionally withdraws such amounts as indicated above. The virtual wallet 20w(i) associated with the public address addAPP(i) associated with the Smartphone 20(i) is a real wallet active on Blockchain 100, so it is possible also the following use cases. The end user changes his mind (regret) and wants to remove his credit (not still spent) from the system (see refund amount in cryptocurrencies). In this case the user simply needs to enter a public address of another wallet using his APP registered to the user on the reference Blockchain through, for example, the simple framing with the APP(s) of a QR Code (QRC) that contains it. The APP(s) via the Software Developer Kit SDK provided by the Applicant, passes addAPP(i) public address of this 20w(i) wallet to the VTS 10 Server running then the wallet emptying transaction 20w(i), i.e. the entire amount residue associated with the APP(s) and calculated by the VTS 10 Server is moved from the public address addAPP(i) of the Smartphone device 20(i) to the one entered by the user, for example via QR Code. This is possible because the VTS Server 10 calls the Blockchain Server Node 15 which owns the private key KEYpr(i) pertaining to the user's public address. The user uses the APP to pay for third-party goods using the remaining credit on the APP same. Just scan the Merchant seller's QR code and ask for the amount to the user, check the capacity and make a TE transaction via the Server pair VTS 10 - Blockchain Server Node 15. The solution described here also allows for a method of purchasing securities. travel in “on demand” mode. In this mode it is possible to automatically purchase the ticket on board the means of transport at the exact moment of its use. In this mode (on demand) the validator on the means of transport shows a QR code on the screen which contains a unique identifier ID associated with the validator device, date and time of the last code update, GPS position at the last update and, possibly, the data of the means of transport, information on the tariff in force in that moment on the medium (e.g. ID_urban tariff – suburban etc) and the address public add40 of the payment recipient, i.e. the Transport Company 40. In this case the APP(y) present on the Smartphone 20(y) can, in a single gesture, without an explicit purchase operation by the user who simply with the APP(y) frames a QR code shown on the validator monitor, the APP(y) having access to the data in the QR Code, automatically proceeds to the purchase of a suitable travel ticket on the VTS 10 Server, performs the payment for the travel ticket via Blockchain100, using the user's credit and then start the journey same (validation). Everything happens automatically and in a simplified manner for the user. who simply gets on the vehicle, scans a QR code and travels. The outcome of the validation, which took place on the VTS 10 Server, is communicated by the APP(y) to the validator via a Bluetooth Low Energy (BLE) protocol using a technology already patented by the Applicant. The “best fare” usage method is now described in detail. fare) in which the user travels on the transport network and the amount due is then calculated (and collected) a posteriori according to the most advantageous rate for the user same. This way of using the system is possible thanks to the fact that the 20w(i) wallet associated with the Smartphone 20(i), for the end user, it is a “diode” i.e. it is simple add credit, but it is impossible to get it out without the authorization of the VTS 10 server itself. This is because to get an equivalent value in cryptocurrencies out of a wallet 20w(i) necessarily needs the private key KEYpr(i) of the 20w(i) wallet itself and the only one The VTS 10 Server owns it (via the 15w wallet of the Blockchain Server Node 15). The user will then be able to use the APP to purchase other travel tickets and / or pay on third-party systems, but the VTS 10 Server will still be able to handle some of the of the amount of user credit as a trust threshold. This possibility is a fundamental requirement to be able to implement a payment policy, later, of the “best fare” type as described in the remainder of the document. The following describes how to use the solution to manage a mode of payment, a posteriori, of the best fare type. As an initial requirement, the user loaded credit into the wallet and requested the how to use the best rate type. In this mode the system (VTS 10 Server) delivers to the user APP(s) a “pass” or token that allows the use of the transport network. That is, the Server VTS 10 delivers to the APP(s) a special Token that allows validation across the entire transport network. This Token, once validated by the user, produces "traces" of use that are then examined a posteriori by the VTS 10 Server at the end of the period observation (e.g. end of day, weekend or end of month) to calculate the amount due. Since VTS Server 10 has access, via Blockchain Server Node 15, to the user credit he will be able to withdraw the amount due after the period of observation. To prevent the user from travelling on public transport other than what is on the To its credit the VTS 10 Server implements two different controls: - blocks an amount (trust threshold) on the user's credit for to be able to proceed with the payment later. This measure prevents the user can spend the credit (for other purposes) before the calculation is made due; and - prevents the user from using the free circulation ticket when the The remaining credit is below a certain threshold. This is possible because the server VTS 10 has full control over the tokens that can be used by users so it can temporarily disable a user token when the credit runs low below a certain threshold and then re-enable it when the user adds more credit to his wallet. The Applicant's current validators must not be modified, at the software level, for the management of this new way of using (best fare through cryptocurrencies) in it will be enough to configure and enable a free circulation ticket (e.g. via QR Dynamic code), this title will then be managed centrally by the VTS 10 Server as described above. The function described above, in conjunction with the use of title materialization of free-flow travel via Calypso-HCE technology allows the management of the technique described here, i.e. use of best-fare technology through payments with cryptocurrency even on devices not provided by the Applicant as the free circulation permit, materialized on a Calypso-HCE emulation card, can be managed remotely from the VTS 10 Server as described above, i.e. enabled and / or disabled based on the remaining credit on the user's APP(s). Finally, the described system can also be used for the following use cases: a) payment of motorway tolls, b) payment for parking in "closed" car parks, for example by barriers or bars, c) payment for passages in limited traffic zones, ZTL. In these cases, the 50(k) manager of the highway, the closed parking lot and the ZTL have a public add50(k) address in the Blockchain 100 network. In case a) of paying motorway tolls (Cripto Telepass), this solution It requires the use of a specific APPAuto(x) user dedicated to car tolls (e.g. highways) and the provision of a dedicated VTS 10 Server server (dedicated and / or in SAAS). In this case, payments are made as described below. The user installs a specific APPAuto(x) on the Smartphone 20(x) and configures it with the license plate of your vehicle TAR(x). Also in this case the APPAuto(x) has associated a public address addAPPAuto(x) in the Blockchain 100 network. The user purchases cryptocurrencies through the mechanism already described in priority in order to have a credit associated with that Smartphone 20(x) (wallet on his APPAuto(x)). The manager (for example of the motorways) has his own crypto wallet (not necessarily on VTS Server 10). At the entrance toll booth, the user passes under a special antenna (BLE beacon) which requests the Smartphone 20(x) to send a pass by passing the wallet ID public of the operator. Smartphone 20(x), having received the incoming request, contacts the VTS 10 Server asking if the user (i.e. the wallet associated with APPAuto(x)) has the necessary credit for the transit (a sort of trust threshold). If so, the VTS 10 Server pre-allocates an amount to the user's wallet (as for the case of a “best fare” type of payment at a later date). Once the entry authorization has been received from the VTS 10 Server, the Smartphone 20(x) responds positively to the incoming request (response to the antenna) applicant) indicating his / her TAR(x) license plate (given that APPAuto(x) knows). transit control system records the authorization and opens the barrier to allow transit the user. At the exit gate the same thing happens (BLE beacon) as the gate antenna transmits a signal that is received by APPAuto(x) which records it on the Server VTS 10 outputs and then responds to the barrier (via BLE) which opens the barrier. At the end of the period the system (of the manager) that calculates the transits notifies a request for payment to the VTS 10 Server indicating the TAR(x) license plate and the toll amount (for example For example, it is possible to account for the outward and return journey at the end of the day.) The Server VTS 10 performs the payment, i.e. executes a transaction (blockchain), between the two wallet (user and manager). In case of lack of outgoing transit, the manager requests the maximum amount from the Server VTS 10, as happens at the toll booths if you show up without an entry ticket, you pay the full fare from the start of the motorway section. In case b) of payment for parking in closed car parks (with barriers) the payment (crypto) is made upon exit or at the exit column from the parking lot. In this case too the user has installed a specific APPAuto(y) on the Smartphone 20(y) and configure it with the TAR(y) license plate of your vehicle. Also in in this case the APPAuto(y) has associated a public address addAPPAuto(y) in the Blockchain Network 100. The user purchases cryptocurrencies through the mechanism already described in order to have a credit associated with that Smartphone 20(y) (wallet associated with the APPAuto(y)). The parking manager has its own crypto wallet (not necessarily on the VTS 10 Server). The user, at the entrance column, passes under a special antenna (beacon BLE) that requests the Smartphone 20(y) to send a pass. The Smartphone 20(y), having received the incoming request, contacts the VTS 10 Server asking if the user (wallet associated with APPAuto(y)) has the credit needed for parking maximum expected (trust threshold). If so, the VTS 10 Server pre-allocates an amount to the user's wallet (as for the case of a “best fare” type of payment at a later date). Once the entry authorization has been received from the VTS 10 Server, the Smartphone 20(y) responds positively to the incoming request (response to the antenna) applicant) indicating his / her license plate TAR(y) (given that APPAuto(y) knows). Parking control system records the authorization and opens the barrier. In the exit column the APPAuto(y) responds immediately to the request (BLE beacon) indicating its license plate TAR in the (BLE) response. The parking management system notifies the payment request to the VTS Server 10 indicating in the request the amount to be paid (based on the hourly rate and time spent in the parking lot, the vehicle's license plate TAR(y) and the parking wallet ID. The VTS 10 Server, through the TAR(y) license plate, identifies the wallet (APPAuto (y)) and executes the payment transaction between the user wallet and the one associated with the operator parking Following the positive response (crypto transaction) the exit column opens the bar. In case c) of payment for passages in limited traffic zones ZTL with open gates. The user installs a special APPAuto(z) on the Smartphone 20(z) and configures it with the TAR(z) license plate of your vehicle. Also in this case the APPAuto(z) has associated a public address addAPPAuto(z) in the Blockchain 100 network. The user purchases cryptocurrencies through the mechanism already described in priority in order to have a credit associated with that Smartphone 20(z) (wallet on your APPAuto(z)). The manager of the limited traffic zones has its own crypto wallet (not necessarily on VTS Server 10). The user passes through one of the ZTL gates under a special antenna (BLE beacon) which requests Smartphone 20(z) to send a pass. Smartphone 20(z), Upon receiving the incoming request, it contacts the VTS 10 Server asking if the user (wallet APPAuto(z)) has the maximum required credit provided by the trust threshold. If so, the VTS 10 Server pre-allocates an amount to the user's wallet (as for the case of a “best fare” type of payment at a later date). Once the entry authorization has been received from the VTS 10 Server, the Smartphone 20(z) responds positively to the incoming request to the requesting antenna indicating your license plate TAR(z) (given that APPAuto(z) knows). The system that manages the ZTL zone associates the TAR(z) license plate (read by the BLE) with the one read by the traffic control system (ZTL camera). The same thing occurs at the exit ZTL gate. The system that calculates the amount due requests payment from the VTS 10 Server after the observation period (crypto transaction between user wallet and that of the manager / Municipality). In this case, compared to the two previous examples, the threshold can be eliminated trustee as it is always possible to issue a fine in the event of access to the ZTL and failure to pay. The user has the history of tolls made in the ZTL in his APPAuto(z). The above description of embodiments of the invention is capable of show the invention from a conceptual point of view so that others, using the known technique, they will be able to modify and / or adapt these forms in various applications specific implementations without further research and without departing from the concept inventive and, therefore, it is intended that such adaptations and modifications will be considered as equivalents of the specific embodiments. The means and materials for carrying out the various functions described may be of various types. nature without thereby departing from the scope of invention. It is understood that the expressions or terminology used are purely for information purposes. descriptive and, therefore, non-limiting. Naturally, without prejudice to the principle of the invention, the construction details and the forms of implementation may vary widely from what is described and illustrated purely by way of example, without thereby departing from the scope of this invention. Where the construction features and techniques mentioned in the following claims are followed by reference signs or numbers, such reference signs were introduced with the sole aim of increasing the intelligibility of the claims themselves and, consequently, they do not have any limiting effect on the interpretation of each element identified, purely by way of example, from such reference signs.

Claims

1) A system for purchasing travel tickets and for paying tolls and / or parking fees based on the use of Blockchain technology, comprising a VTS Server (10), a Blockchain Server Node (15) synchronised with a Blockchain network (100) and a plurality of Smartphone user devices (20(i)), in which on each Smartphone user device (20(i)) there is an application (APP(i), APPAuto(i)) for managing purchases towards at least one Transport Company or a Manager (40(j), 50(k)), in which each Smartphone user device (20(i)) is equipped with a first public address (addAPP(i), addAPPAuto(i)) and said Transport Company or Manager (40(j), 50(k)) is equipped with a second public address (add40(j), addAPPAuto(k)), in which said Blockchain Server Node (15) is connected via a connection (30) in Peer to Peer mode, P2P, to the Blockchain (100), and stores and keeps locally (15w) a copy (BC) of the Blockchain (100), the first public addresses (addAPP(i),addAPPAuto(i)) associated with each user and the private keys (KEYpr(i)) of the users, and wherein said VTS Server (10) creates the public addresses (addAPP(i), addAPPAuto(i)) for each application (APP(i), APPAuto(i))) associated with a user, calculates the current balance of the Smartphone user (20(i)) and, in case of sufficient currency, creates a pass that generates a transaction (TE) on the Blockchain (100), wherein said VTS Server (10) authorizes the transaction (TE) via the private key (KEYpr(i)) of the user stored (15w) in the Blockchain Server Node (15), wherein said transaction (TE) transfers the content, or part of it, from a first wallet (20w(i)) owned by the Smartphone user (20(i)) and associated with a first public address (addAPP(i), addAPPAuto(i))) to a second wallet (40w(j)) owned by the Transport Company or Operator (40(j), 50(k)) and associated with a second public address (add40(j), add50(k))., 2) The system for purchasing travel tickets and for paying tolls and / or parking according to claim 1, wherein said VTS Server (10) is a node of the reference Blockchain network (100) and uses the Blockchain Server Node (15) as an access point to the Blockchain (100). 3) The system for purchasing travel tickets and for paying tolls and / or parking according to claim 2, wherein said VTS Server (10) natively connected to the Blockchain (100) via the Blockchain Server Node (15) operates natively on it by creating internal public addresses (addAPP(i)) and is P023932IT-01 NOTARBARTOLO&GERVASI configured to create and manage payment transactions (TE) on the Blockchain (100). 4) The system for purchasing travel tickets and for paying tolls and / or parking according to claim 2 or claim 3, wherein said Blockchain Server Node (15), downstream of the first synchronisation, contains within it a local copy (BC) of the entire Blockchain (100). 5) The system for purchasing travel tickets and for paying tolls and / or parking fees according to claim 4, wherein the payment transactions (TE) from the first wallet (20w(i)) to the second wallet (40w(j)) owned by the transport company (40(j)) are recorded on the Blockchain Server Node (15) by the VTS Server (10) and then automatically replicated by the Blockchain Server Node (15) on the other nodes of the Blockchain network (100) via the connection (30), Peer to Peer, P2P. 6) The system for purchasing travel tickets and for paying tolls and / or parking according to any of the previous claims, wherein the VTS Server (10): - manages the life cycle of the first public addresses (addAPP(i)) associated with the users of the Smartphones (20(i)) for creation, phone change and calculation of the current balance; - manages the life cycle of payments for each Smartphone (20(i)) by calculating the amount due by making the euro / crypto conversions and taking care of withdrawing any surcharges to be paid in the wallet of the service provider on Software as a Service, SAAS systems; - chooses and optimises the transactions (TE) in cryptocurrency in such a way as to cover the amount due, minimising the number of transactions to be used to limit the costs of the transaction itself;and - creates and manages economic transactions (TE) taking care to calculate the various components and then sign correctly with the private key (KEYpr(i)) associated with the Smartphone (20(i)).; 7) The system for purchasing travel tickets and for paying tolls and / or parking according to any of the previous claims, wherein the Blockchain Server Node (15) is configured to: - manage the Peer to Peer connection to the Blockchain (100) and the synchronisation of local data with public data and vice versa; P023932IT-01 NOTARBARTOLO&GERVASI - manage the local cryptocurrency wallet (15w) which contains the set of private keys (KEYpr(i)) of the Smartphones (20(i)); and - execute commands sent by the VTS Server (10). 8) The system for purchasing travel tickets and for paying tolls and / or parking according to any of the previous claims, wherein the application (APP(i), APPAuto(i)) downloaded on the Smartphone (20(i)) has a public address (addAPP(i), addAPPAuto(i)) on the Blockchain (100) and the user tops up his wallet (20w(i)) with cryptocurrencies in standard mode. 9) The system for purchasing travel tickets and paying for tolls and / or parking according to any of the preceding claims, wherein said travel tickets can be purchased using cryptocurrencies, in advance of the journey itself and used subsequently. 10) The system for purchasing travel tickets and paying for tolls and / or parking according to any of the previous claims 1-8, wherein said travel tickets can be purchased using cryptocurrencies, “on demand” wherein, through a single gesture, the user exercises the will to make a trip, pays for it using cryptocurrencies and validates it using a validator that works in Bluetooth Low Energy. 11) The system for purchasing travel tickets and paying for tolls and / or parking fees according to any of the preceding claims 1-8, wherein said travel tickets can be purchased via cryptocurrencies and paid for subsequently, wherein the amount to be paid via cryptocurrencies is managed in a best fare or best rate manner. 12) The system for purchasing travel tickets and for paying for tolls and / or parking according to any of the preceding claims, wherein the system allows the payment of travel tickets through the simultaneous management of multiple Blockchains (100) for simple and multi-wallet management of travel ticket payments by users. 13) The system for purchasing travel tickets and for paying tolls and / or parking fees according to any of the preceding claims, wherein the system allows the payment of travel tickets both in autonomous mode and in Mobility As A Service (MAAS) mode, wherein the system separates “at the root”, in automatic P023932IT-01 NOTARBARTOLO&GERVASI mode, the amount owed to the transport operator from that owed to the service provider as a premium. 14) The system for purchasing travel tickets and for paying tolls and / or parking fees according to any of the previous claims, wherein the system allows the payment of motorway tolls, parking in barrier-closed parking lots and transit in limited traffic zones, ZTL, via cryptocurrencies by indicating the license plate (TAR) of the user's vehicle. 15) The system for purchasing travel tickets and for paying tolls and / or parking according to any of the preceding claims, wherein the system allows deferred payments in such a way as to be able to optimise the size of the transactions (TE) on Blockchain (100) and consequently reduce the costs due to the transactions themselves. 16) The system for purchasing travel tickets and for paying tolls and / or parking according to claim 15, wherein the system provides the possibility of optimising transactions (TE) and writing them on the Blockchain (100) when a certain value is reached such as a spending threshold or a time threshold.