Purchasing and payment methods and techniques based on blockchain technology

Abstract

A system for purchasing travel documents and for paying tolls and / or parking fees is based on the use of Blockchain technology. It comprises a VTS Server (10), a Blockchain Server Node (15) synchronized with a Blockchain network (100) and a plurality of Smartphone user devices (20(i)). An application (APP(i), APPAuto(i)) for managing purchases towards at least one Transport company or Operator (40(j), 50(k)) is present on every Smartphone user device (20(i)). The Smartphone user device (20(i)) is provided with a first public address (addAPP(i), addAPPAuto(i)) and said Transport company or Operator (40(j), 50(k)) is provided with a second public address (add40(j), addAPPAuto(k)). The Blockchain Server Node (15) is connected to the Blockchain (100) by means of a connection (30) in Peer to Peer mode, P2P, and locally saves and stores (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. The 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 user of the Smartphone (20(i)) and, in the event of sufficient value, creates and delivers, to the application (APP(i), APPAuto(i)), a pass or Token which allows the use of the Transport network and which generates a transaction (TE) on the Blockchain (100), in which the VTS Server (10) authorizes the transaction by means of the user private key (KEYpr(i)) saved (15w) in the Blockchain Server Node (15). The transaction (TE) transfers the content, or part of it, from a first wallet (20w(i)) belonging to the Smartphone user (20(i)) and associated with a first public address (addAPP(i), addAPPAuto(i))) to a second wallet (40w(j)) belonging to the Transport company or Operator (40(j), 50(k)) and associated with a second public address (add40(j), add50(k)).

Description

[0001] PURCHASING AND PAYMENT METHODS AND TECHNIQUES BASED ON BLOCKCHAIN TECHNOLOGY

[0002] * * * * *

[0003] FIELD OF THE INVENTION

[0004] The present invention relates to a system for purchasing, managing and validating public transport travel documents based on the use of Blockchain technology.

[0005] Such a solution may also be used for payments for highway tolls, payments for parking in closed parking lots and for access to Limited Traffic Zones (LTZ).

[0006] PRIOR ART

[0007] The Applicant has a Virtual Ticketing System (VTS) Framework for managing dematerialized travel documents, both dematerialized card subscriptions and impersonal travel documents (tickets and booklets).

[0008] Although the Virtual Ticketing System has been integrated with various services offered by Payment Service Providers (PSP), it is always up to the end user (i.e., the Transport company) to activate such payment services.

[0009] Moreover, the Payment Service Providers are the payment service providers via the Internet, i.e., subjects acting as financial intermediaries for the payments made by means of the Internet channel, and conventionally each Payment Service Provider retains a portion of the transaction as a commission.

[0010] Such an approach, pursued by large Transport companies, is not feasible for small operators (small businesses) because the complexity of the operations to be carried out to activate the payments and the contracts to be formalized could be such as not to justify the benefits from the sale of the travel documents (especially on Payment Service Provider side).

[0011] In terms of user experience, also, having to use a credit card (or the like) to purchase a ticket every time is not the most convenient, especially on public means of transport.

[0012] To overcome the aforesaid problem, other suppliers of applications, APPs, have implemented the following approach, i.e., every once in a while the user tops up (for example, in Euros) a wallet on their APP and then uses such a credit to purchase actual travel documents.

[0013] However, such an approach might not be applicable to all company realities due to the actual banking legislation because the operator of the APP containing the wallet acts as a bank, i.e., holds money on behalf of third parties. As is known, special authorizations that are not simple to obtain are required in order to be able to “hold” money on behalf of third parties.

[0014] Methods for paying tolls using Blockchain technology are known in the prior art.

[0015] In particular, document KR20200093919A describes a technology for paying road tolls for users of vehicles travelling through toll points, where a vehicle license plate number is extracted from an image captured by at least one camera installed at a payment point of the toll, and then the electronic wallet of a user is identified using the vehicle license plate number.

[0016] Document KR20200019588A describes a system provided with a payment terminal installed on transport means and adapted to communicate with a movable terminal of a user using the transport means. In this case, the movable user terminal communicates via sales equipment (local to the transport means) with the system for purchasing travel documents in cryptocurrency.

[0017] SUMMARY OF THE INVENTION

[0018] The object of the invention has been achieved by a system as defined in claim 1 .

[0019] The present invention relates to a system for purchasing travel documents and for paying tolls and / or parking fees based on the use of Blockchain technology. The system comprises a VTS Server, a Blockchain Server Node synchronized with a Blockchain network, and a plurality of Smartphone user devices. An application for managing purchases towards at least one Transport company and Operator is present on every Smartphone user device.

[0020] The Smartphone user device is provided with a first public address and the Transport company or Operator is provided with a second public address. The Blockchain Server Node is connected to the Blockchain through a Peer to Peer mode connection and locally saves and stores a copy of the Blockchain, the first public addresses associated with each user and the private keys of the users. The VTS Server creates the public addresses for each application associated with a user, calculates the current balance of the user and, in the event of sufficient value, creates a pass which generates a transaction on the Blockchain and authorizes the latter by means of the user private key saved in the Blockchain Server Node. The transaction transfers the content, or part thereof, from the first wallet belonging to the user and associated with a first public address, to a second wallet belonging to the Transport company or Operator 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 as an access point for the Blockchain, and it is natively connected to the Blockchain by means of the Blockchain Server Node to natively operate thereon, creating internal public addresses, and it is configured to create and manage the payment transactions on the Blockchain.

[0021] The Blockchain Server Node contains therein a local copy of the whole Blockchain, after the first synchronization.

[0022] In greater detail, the payment transactions from the first wallet to the second wallet belonging to the Transport company are recorded on the Blockchain Server Node by the VTS Server and then automatically replicated by the Blockchain Server Node on the other nodes of the Blockchain network by means of the P2P connection.

[0023] The VTS Server manages the lifecycle of the first public addresses associated with the Smartphone users for creation, phone change and calculation of the current balance; it manages the lifecycle of the payments for every Smartphone by calculating the amount due by performing the Euro / crypto conversion and withdrawing any commission to be paid in the wallet of the service provider on Software as a Service systems - SAAS; it selects and optimizes the cryptocurrency transactions so as to cover the amount due, minimizing the number of transactions to be used to limit costs of the same transaction; and it creates and manages the economical transactions by calculating the various components and then correctly signing with the private key associated with the Smartphone.

[0024] Moreover, the Blockchain Server Node is configured to manage the Peer to Peer connection to the Blockchain and the synchronization of the local data with the public data, and vice versa; to manage the local cryptocurrency wallet containing the set of private keys of the Smartphones; and to execute the commands sent by the VTS Server.

[0025] The application downloaded onto the Smartphone has a public address on the Blockchain and the user tops up the wallet with cryptocurrencies in standard mode. The travel documents may be purchased via cryptocurrencies before the fruition of the trip itself and used later. Otherwise, the travel documents may be purchased via “on demand” cryptocurrencies where, by means of a single gesture, the user expresses the will to take a trip, pays for it via cryptocurrencies and validates it by means of a validator operating in Bluetooth Low Energy.

[0026] Alternatively, the travel documents may be purchased via cryptocurrencies and paid later, where the amount to be paid via cryptocurrencies is managed in best fare mode.

[0027] The system allows paying for the travel documents by means of the simultaneous management of several Blockchains for a simple and multi-wallet management of the payment or travel documents by users.

[0028] The system allows paying travel documents both in autonomous mode and in Mobility As A Service mode, MAAS, where the system automatically separates “at the root” the amount due to the Transport operator from the one due to the service provider as commissions.

[0029] The system allows payments in deferred mode so as to optimize the size of the Blockchain transactions and subsequently reduce the costs due to the same transactions.

[0030] The system provides the option of optimizing the transactions and writing them on the Blockchain when a given value is reached such as an expense threshold or a time threshold.

[0031] BRIEF DESCRIPTION OF THE FIGURES

[0032] Hereafter in this description, reference will be made to the drawings shown in the accompanying figures, in which:

[0033] - Figure 1 shows the architecture of the system according to the invention.

[0034] The parts according to the present description are represented in the drawings, when suitable, employing conventional symbols, showing only the specific details that lead to understanding the embodiments of the present invention, so as not to highlight details that will be immediately apparent to the person skilled in the art, with reference to the description provided below.

[0035] DETAILED DESCRIPTION OF THE INVENTION

[0036] The solution according to the present invention will now be described with the help of the drawings.

[0037] First, it is convenient to briefly describe blockchain technology. A Blockchain 100 is a distributed ledger which records economical transactions between anonymous subjects by means of public addresses.

[0038] Such a ledger is distributed and replicated on all the server nodes participating in the Blockchain network 100 in Peer to Peer mode (P2P). Thereby, no node has control over the infrastructure and nobody can alter or falsify the contents of such a distributed ledger because every node has an updated copy of Blockchain 100.

[0039] An economical transaction TE on Blockchain 100 consists in recording that the content of a container (for example, called IITXO in the Bitcoin world, i.e. , Unspent Transaction Output) containing a number NN of cryptocurrencies (or fractions thereof) has changed ownership from public address A, i.e., from a wallet A, to public address B, i.e., to a wallet B. In general, several incoming UTXOs may be combined with one another, within the same transaction, to reach the amount due. In the case of amount over the amount due, any change from the payment transaction can be diverted to the original wallet, wallet A.

[0040] With reference to Figure 1 , in the solution herein proposed, the architecture consists of the following macro-components: a VTS Server 10, a Blockchain Server Node 15, a plurality of Smartphones 20, and a P2P connection 30 between the Blockchain Server Node 15 and Blockchain 100. An APP for communicating with the VTS Server 10 is downloaded and available on every Smartphone 20. Essentially, the APP is the client’s registration to the service offered, for example, by a Transport company 40. Each time an APP is downloaded onto the VTS Server 10, an entity associated with the owner user of Smartphone 20 is created.

[0041] The solution proposed herein uses the APP downloaded and installed on Smartphone 20 of the user to purchase / pay for travel documents directly by a VTS Server 10, without any interaction with intermediate equipment and / or with the same transport means during the step of purchasing and paying for travel documents. In particular, there is no longer the need to use a “validator” on board transport means, rather application APP(i) is capable of purchasing, validating and using the travel documents without interacting with further payment and / or validation terminals. Therefore, application APP(i) downloaded and installed on Smartphone 20 of the user purchases and pays for the travel documents directly from the VTS Server 10 without interacting with payment and / or validation terminals during the step of purchasing and paying for the travel documents. The solution proposed herein is also based on these three basic concepts.

[0042] Every VTS Server 10 is also a node of the reference Blockchain network 100 (Bitcoin, Ethereum, Dogecoin, ... ).

[0043] In particular, it is a task of the VTS Server 10 to create and manage the transactions TE (by means of IITXO transactions, for example) for the pertaining public addresses.

[0044] Every smartphone 20(i) associated with a client by means of APP(i) has its own public address addAPP(i) of the Blockchain network 100. The VTS Server 10 manages both the public address addAPP(i) of Smartphone 20(i) and the payment transactions TE to the Transport company 40 (for example, by calculating the amount due by combining mutually opportune UTXOs).

[0045] Every Transport company 40 has its own public address add40, again of the Blockchain network 100. Such an address add40 could be managed by the VTS Server 10 or by an external crypto-exchange.

[0046] In order for the solution to work, the VTS Server 10 must be able to act as a node of the Blockchain network 100.

[0047] Indeed, to access a Blockchain 100, i.e. , to create a wallet, to public addresses, to create economical transactions, to manage balances of the various wallets, to have the list of transactions made, to check the status of payments, etc., a connection must be made to Blockchain 100.

[0048] In order to carry out the aforesaid operations, the VTS Server 10 can select from two options: using a paid external operator or becoming, itself, a node of the Blockchain network 100.

[0049] The solution herein proposed provides using the second option, i.e., ensuring the VTS Server 10 becomes a node of Blockchain 100.

[0050] Open source implementations allowing the connection to the reference Blockchain exist; such open source implementations have been used for years on thousands of nodes worldwide, such as Bitcoin Core or Dogecoin Core, for example.

[0051] With reference to Figure 1 , the VTS Server 10 uses the Blockchain Server Node 15 as access point (proxy) to Blockchain 100.

[0052] In the solution herein described, given that it is natively connected to Blockchain 100 by means of the Blockchain Server Node 15 which serves as a proxy, the VTS Server 10 natively operates on it, therefore being able to create internal public addresses and payment transactions on the reference Blockchain 100.

[0053] The Blockchain Server Node 15 contains therein a local copy BC of the whole Blockchain 100 (kept synchronous) after the first synchronization. Thereby, the system is immune to network crashes and every search on Blockchain 100 occurs via a local copy.

[0054] The payment transactions TE from wallet 20w(i) of APP(i) of the client to the wallet of the Transport company 40 are recorded immediately 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 (by means of the P2P connection 30) once they are confirmed by the miner network.

[0055] The payment transactions TE, recorded on the local Blockchain Server Node 15, cost a few cents or less, depending on the cryptocurrency selected, and do not require an intermediary or middle-man to be performed.

[0056] The VTS Server 10 serves the dual role of interacting both with Smartphone 20 of the user via application APP for ticketing purposes (as already occurs today) and with the Blockchain node 15, as explained hereinafter in the description.

[0057] Thus, the VTS Server 10, in addition to ticketing functions already present, performs the following functions useful to this solution: it manages the lifecycle of the first public addresses addAPP associated with the users of the Smartphone 20 (creation, phone change, calculation of Smartphone 20 current balance on Blockchain 100); it manages the lifecycle of the payments for every Smartphone 20 (it calculates the amount due by performing the Euro / crypto conversion) and withdraws (from the source) any commission to be paid in the wallet of the service provider on Software as a Service systems - SAAS; it selects and optimizes the cryptocurrency transactions TE (IITXO associated with Smartphone 20) so as to cover the amount due, minimizing the number of IITXO transactions to be used (to limit the costs of the same transaction; indeed, every transaction has a cost that is also associated with the number of UTXOs employed); and it creates and manages the economical transactions TE (IITXO) by calculating the various components and then correctly signing with the private key KEYpr associated with the Smartphone 20 (i.e. , the user registered by means of the APP).

[0058] The Blockchain Server Node 15 is a standard component of the Blockchain (e.g., Bitcoin Core) which performs the following functions:

[0059] Peer to Peer connection to Blockchain 100 and synchronization of the local data with the public data, and vice versa; it manages the local cryptocurrency wallet 15w (together with the private keys of the Smartphones 20); and it executes the commands sent by the VTS Server 10.

[0060] Every APP(i) downloaded on a Smartphone 20(i), and activated this way, will have its own public address addAPP(i) on the independent Blockchain 100.

[0061] Such a public address addAPP(i) is automatically created by the VTS Server 10 by means of the JSON-RPC interface protocol in the local wallet 15w associated with the Blockchain Server Node 15 that interfaces with Blockchain 100.

[0062] Essentially, the various crypto systems (e.g., Bitcoin Core) allow having a single local wallet 15w on the server and N independent public addresses addAPP(i) (addAPPI , addAPP2, ... addAPPn). Every public address addAPP(i) corresponds to a private key KEYpr(i) that the VTS Server 10 manages on behalf of Smartphone 20(i).

[0063] Also, the Transport companies 40 or Transport operators have their own public address add40 on Blockchain 100. Such an address add40 does not necessarily need to be locally created by the VTS Server 10, rather an existing address configured on the Corporate Control Center, CCA, created on an external system (Binance, Coinbase, ...) may be perfectly used, as explained below.

[0064] The Blockchain Server Node 15 has the task of creating the physical local wallet 15w (wallet.dat), which is encrypted and protected by a passphrase, which serves to keep confidential the set of private keys KEYpr(i).

[0065] Such a physical local wallet 15w does not contain the cryptocurrencies and / or balances of the Smartphones 20(i). Such information, i.e., the balance associated with every Smartphone 20(i), is contained only in Blockchain 100 and is calculated on the go by the VTS Server 10 by means of a call to the Blockchain Server Node 15 using the public address addAPP(i) of Smartphone 20(i). The step of topping up and purchasing travel documents, which is based on these initial considerations, is described below.

[0066] Below are the steps performed on a genericAPP(i) for the step of topping up a wallet and purchasing travel documents on a Smartphone 20(i).

[0067] APP(i) has a public address addAPP(i) on the Blockchain and such a public address addAPP(i) is generated once by the VTS Server 10 during a step of first connection of APP(i) to the VTS Server 10.

[0068] The VTS Server 10 saves the value of the public address addAPP(i) (non-sensitive information) in the local database DBIoc to manage cases where the user uninstalls the APP by mistake and / or changes Smartphone 20 (x). In particular, if the user installs APP again because they cancelled it by mistake or because they changed telephone, the VTS Server 10 recognizes the device (by means of a special Deviceld managed by the same VTS Server 10) and recovers the public address addAPP(i) associated with such a user registered with APP and reassigns it to the user.

[0069] The VTS Server 10 ensures that if a telephone (Android on Android or IOS on IOS) is changed, the Deviceld is kept (the Google or Apple “cloud” is used to associate the Google / Apple user with the Deviceld).

[0070] In the case where the transfer occurs on “mixed” devices (Android on IOS or IOS on Android), the system provides a special “data shifting” function that “migrates” the content from the DeviceldOld to DeviceldNew.

[0071] This function uses the user email (upon verification by sending an OTP) as “ID of the person” to then identify the “set of devices” available for the movement.

[0072] The idea is to manage the “Crypto Public Address” among the data being migrated from DeviceldOld to DeviceldNew.

[0073] The private keys KEYpr(i) instead are kept only in wallet 15w of the Blockchain Server Node 15 and are unknown to the VTS Server 10.

[0074] The user tops up the wallet 20w (with cryptocurrencies) in standard mode, i.e. , the APP screen shows the QR Code of the public address addAPP and / or allows copying its alphanumeric value where needed; an example of public address is: «DNnGtXk9khadE7EKCmQzxjnehenX92PKAv».

[0075] Any method compatible with the selected Blockchain 100 may be used to top up wallet 20w. It is possible to purchase cryptocurrencies and associate them with the user (i) by means of their public address addAPP(i). The purchase of cryptocurrencies is seen as a transaction TE and, for example, if a user (i) purchases for €20, they will have the equivalent of e.g. 4.5 Dogecoin in their wallet 20w(i), i.e. , a counter-value of €19 (corresponding to the initial money less the costs of the transaction on Blockchain 100 and the cost withheld by the service supplier that purchased the cryptocurrencies).

[0076] A transaction TE having costs occurs every time a user (x) tops up the wallet w(x) and every time a user uses the funds in the wallet w(x). In particular, the transaction TE has a cost when it is written on Blockchain 100. Therefore, this solution provides the option of optimizing the transactions TE and writing them on Blockchain 100 when a given value is reached (e.g., an outlay of €10) or when a determined time has lapsed (e.g., one week). Therefore, the user (x) may carry out several transactions TE1 (x), TE2(x), TE3(x) etc. and when a determined (value or time) threshold is reached, the total of the transactions TE(x)tot is written on Blockchain 100.

[0077] This deferred payment mode is managed by the VTS Server 10 and therefore allows decreasing the number of transactions TE (per user) and subsequently, the costs of the same transactions TE.

[0078] In addition to allowing the costs to be contained, the deferred payments described above also allow the VTS Server 10 to implement fare policies with later payment, in literature called best fares, as seen below.

[0079] The VTS Server 10 must save the different transactions TE(i) and also the exchange rate for the day of the transaction TE(i) so as to be able to correctly calculate the amount due and also inform the user on the payments made in the local currency (e.g., Euros).

[0080] The Transport companies 40 or Transport operators are not involved in this step and / or are not required to ask for any bank authorization because the economical transactions occur completely on the Blockchain and not in banking circuits.

[0081] The cryptocurrencies topped up by the user (x) do not go into the wallet of the VTS Server 10, rather they are simply recorded in the Blockchain 100 in the name of APP(x) downloaded onto Smartphone 20(x). When user (x) wants to purchase a travel document on the VTS Server 10, the latter verifies the balance associated with such a user (x) by means of the public address addAPP(x) by requesting it from the Blockchain Server Node 15 which scans the local copy BC of Blockchain 100 and responds.

[0082] If wallet 20w(x) of user (x) has room, net of the transactions not yet recorded on the Blockchain (see payments made in deferred mode), the sale proceeds and a transaction TE from the wallet of user (x) towards wallet 40w of the Transport company 40 is saved. As explained above, such a transaction may occur immediately or in deferred mode. This option is managed by the VTS Server 10 based on the local configuration selected.

[0083] The step of paying for the travel document is then managed by the VTS Server 10 which carries out a transaction on Blockchain 100 (by means of the Blockchain Server Node 15) of this type:

[0084] Move «xx.xxx» cryptocurrencies, or fractions thereof, from WalletA 20w(i) (of Smartphone 20(i)) to WalletB 40w (of the Transport company 40).

[0085] The local Blockchain Server Node 15 allows the VTS Server 10 to operate on the Blockchain network 100 (Bitcoin or Dogecoin or others) in native manner, allowing quick and affordable transactions. The cost of the transaction indeed depends on the Blockchain used.

[0086] In general, for economical and / or commercial reasons and / or for reasons relative to spreading the technology, the simultaneous interaction with several different Blockchains (e.g. Bitcoin, Dogecoin, Ethereum, ... ) may be required, whereby the system herein described is designed to be able to manage, right from the start, a use in multi-blockchain mode, i.e., one single VTS Server 10 and a number N of different Blockchain Server Nodes 15. The VTS Server 10 has the task of managing and directing the payments on the correct Blockchain.

[0087] The Transport company 40 never pre-collects anything from third parties; the user indeed has the virtual wallet 20w and the status of such a wallet 20w is not written in the servers of the Transport company 40, but in Blockchain 100.

[0088] Implementing multi-operator systems (see MAAS systems, i.e., Mobility As A Service) using this solution becomes simple, because every Transport company 40w(j) would have their own wallet, 40w(j) whereby retroactive clearing policies do not have to be implemented because every sale finishes directly in the destination wallet 40w(j) by virtue of the VTS Server 10 managing the transactions TE.

[0089] It should be noted that the local database DBIoc of the VTS Server 10 does not contain the balances of the wallets 20w(i) of the users and / or the private keys KEYpr(i) of the same users, whereby it is not a possible attack point by external hackers and / or it does not require additional hardening with respect to that already present on company servers to date.

[0090] Indeed, access to the private key KEYpr(i) of the true wallet 20w(i) is required to move the cryptocurrencies. Such keys KEYpr(i) are securely saved in a suitable local file (e.g., «Wallet.dat») directly managed in a secure manner by the Blockchain Server Node 15. This security is then ensured by the same Blockchain Server Node 15.

[0091] The Blockchain Server Node 15 in the various implementations is open source and installable both on Windows and Linux systems.

[0092] The Blockchain Server Node 15 further serves the function of encrypted backup of the local wallet 15w which is saved, at preset intervals, in an environment protected and managed by backup policies. This is to prevent a loss of data and / or attack on the server hosting the Blockchain Server Node 15 from inhibiting access to the local wallet 15w, and therefore to all the virtual wallets 20w(i) of the APP(i), making the related cryptocurrencies unusable. Also, this backup function is automatically managed by the same VTS Server 10.

[0093] The payment system herein described allows two different business models based on the economic dimensions of the Transport company involved: a) Client 40a (large transport company) acquires the entire infrastructure herein described and installs it in house (i.e., it owns the servers, takes care of installing and servicing them and manages the network infrastructure to ensure access to the P2P network). In this case, the Applicant sells the system and provides technical assistance; b) Client 40b (small transport company) does not acquire and / or own the servers or the system (see network infrastructure), but a service. In this case, in addition to receiving an annual fee by way of service subscription, the Applicant retains a percentage of the sales as a commission. In the second “Software As A Service”, SAAS, approach, when the VTS Server 10 makes the payments, it already separates the commissions from the amount paid, i.e.:

[0094] - the VTS Server 10 copies 95% of the amount in Wallet 40w(b) of Company 40b, which then cashes out by means of a bank (conventional banks will increasingly offer this service) or a crypto exchange (Binance, Coinbase, eToro, Nexo, Gemini, ... );

[0095] - the VTS Server 10 copies 5% (for example) as a percentage of commissions in the private Wallet of the Applicant which occasionally withdraws such amounts as indicated above.

[0096] The virtual wallet 20w(i) associated with the public address addAPP(i) associated with Smartphone 20(i) is a true wallet active on Blockchain 100, whereby the following cases are also possible.

[0097] The end user changes their mind (regret) and wants to remove their credit (not yet spent) from the system (see returning amount in cryptocurrencies). In this case, it is sufficient for the user, with their APP, to enter a public address of another wallet belonging to the user on the reference Blockchain by means of, for example, using APP(i) to simply scan a QR Code (QRC) containing it.

[0098] APP(i), by means of the Software Developer Kit, SDK, provided by the Applicant, switches from the public address addAPP(i) of this wallet 20w(i) to the VTS Server 10 which then carries out the transaction of emptying wallet 20w(i), i.e., the entire residual amount associated with APP(i) and calculated by the VTS Server 10 is moved from the public address addAPP(i) of the Smartphone device 20(i) to the one entered by the user by means of the QR Code, for example. This is possible because the VTS Server 10 calls the Blockchain Server Node 15 that has the private key KEYpr(i) relative to the public address of the user.

[0099] The user uses the APP to pay third-party goods using the residual credit on the same APP. It is sufficient to simply scan the QR code of the Merchant vendor, request the amount from the user, verify the room and carry out a transaction TE by means of the VTS Server 10-Blockchain Server Node 15 pair.

[0100] The solution herein described also allows purchasing the travel documents in “on demand” mode. In this mode, it is possible to automatically purchase the ticket on board the means of transport on the exact moment it is used. In this mode (on-demand mode), the validator on the means of transport shows, on a screen, a QR code containing a unique identification ID associated with the validator equipment, date and time of the last update of the code, GPS position at the last update and possibly, the data of the means of transport, information on the fare in effect at that time on the means of transport (e.g. ID_urban-suburban fare, etc.) and the public address add40 of the payment recipient, i.e. , the Transport company 40.

[0101] In this case, the APP(y) on Smartphone 20(y) may, in a single gesture, without an explicit purchase operation by the user who, by simply using the APP(y), scans a QR code shown on the validator screen, the APP(y) having access to the data in the QR code, automatically proceed with purchasing a suitable travel document on the VTS Server 10, make the payment for the travel document by means of Blockchain 100 using the user’s credit, and therefore start the same trip (validation). This all occurs in an automatic and simple manner for the user who simply boards the means of transport, scans a QR Code and travels. The outcome of the validation, which occurred on the VTS Server 10, is communicated by the APP(y) to the validator by means of Bluetooth Low Energy (BLE) technology by means of a technology already patented by the Applicant.

[0102] The “best fare” mode of use in which the user travels on the transport network and the amount due is then calculated (and collected) later according to the most advantageous fare for the same user, is now described in detail.

[0103] This mode of use of the system is possible by virtue of the fact that wallet 20w(i) associated with Smartphone 20(i) is a “diode” for the end user, i.e., it is simple to add credit but it is impossible to get it out without the authorization of the same VTS Server 10.

[0104] This is because in order to get an equivalent value in cryptocurrencies out of a wallet 20w(i), the private key KEYpr(i) of the same wallet 20w(i) is necessarily needed and only the VTS Server 10 has it (by means of wallet 15w of the Blockchain Server Node 15).

[0105] Therefore, the user may use the APP to purchase other travel documents and / or pay on third-party systems, but the VTS Server 10 can in any case manage a portion of the amount of the user credit as a fiduciary threshold. Such an option is a fundamental requirement for being able to implement a retroactive payment policy of the “best fare” type, as described in the continuation of the document.

[0106] The use of the solution for managing a retroactive payment mode of the best fare type is described below.

[0107] As an initial requirement, the user has topped up credit in the wallet and has requested the best fare mode of use.

[0108] In this mode, the system (VTS Server 10) delivers, to APP(i), a “pass” or Token allowing the use of the transport network. That is, the VTS Server 10 delivers, to APP(i), a special Token allowing the validation on the whole transport network.

[0109] Once validated by the user, this Token generates “traces” of use which are then examined later by the VTS Server 10 at the end of the period of observation (e.g., end of the day, end of the week or end of the month) to calculate the amount due.

[0110] Given that the VTS Server 10 has access to the user’s credit by means of the Blockchain Server Node 15, it may withdraw the amount due after that period of observation.

[0111] In order to prevent the user from travelling on public means of transport beyond the existing credit, the VTS Server 10 implements two different checks: it blocks an amount (fiduciary threshold) on the user’s credit to then make the payment later. This contrivance prevents the user from spending the credit (for other purposes) before the amount due has been calculated; and it prevents the use of the free circulation travel document by the user when the residual credit is below a given threshold. This is possible because the VTS Server 10 has complete control over the Tokens (passes) usable by the users, whereby it may temporarily disable a user Token when the credit falls below a given threshold and then re-enable it when the user adds credit to the wallet.

[0112] The Applicant’s current validators do not need to be modified at a software level to manage this new mode of use (best fare via cryptocurrencies) because it will be sufficient to simply configure and enable a free circulation travel document (e.g. by means of dynamic QR Code); such a travel document will then be managed at the central side by the VTS Server 10 as described above.

[0113] The function described above, combined with the use of the materialization of the free circulation travel document by means of Calypso-HCE technology, allows managing the technique herein described, i.e. , using the best fare technology by means of payments with cryptocurrencies also on equipment not supplied by the Applicant, because also the free circulation travel document, materialized on Calypso-HCE Emulation Card, may be managed remotely by the VTS Server 10 as described above, i.e. , enabled and / or disabled based on the residual credit on the user APP(i).

[0114] Finally, it is possible to use the system described also for the following use cases: a) payment of highway tolls, b) payment of parking lots “closed” by barriers or bars, for example, c) payment of the pass in Limited Traffic Zones, LTZ.

[0115] In these cases, the operator 50(k) of the highway, of the closed parking lot and of LTZs have a public address add50(k) in the Blockchain network 100.

[0116] In the case a) of payment of highway tolls (Crypto Telepass), this solution provides the use of a special user APPAuto(x) dedicated to vehicle tolls (e.g., highways) and the supply of a dedicated VTS Server 10 (dedicated and / or in SAAS).

[0117] In this case, the payments are made as described below.

[0118] The user installs a special APPAuto(x) on Smartphone 20(x) and configures it with the license plate of their vehicle TAR(x). Also in this case, the APPAuto(x) has associated a public address addAPPAuto(x) in the Blockchain network 100.

[0119] The user purchases cryptocurrencies by means of the mechanism described above so as to have a credit associated with such a Smartphone 20(x) (wallet on their APPAuto(x)). The operator (of the highways, for example) has its own crypto wallet (not necessarily on the VTS Server 10).

[0120] The user passes under a special antenna (BLE beacon) at the entry tollbooth, which antenna requests Smartphone 20(x) to send a pass, via the operator’s public wallet ID. Once it receives the entry request, Smartphone 20(x) contacts the VTS Server 10, asking if the user (i.e., the wallet associated with APPAuto(x)) has the necessary credit to transit (a kind of fiduciary threshold).

[0121] If yes, the VTS Server 10 pre-allocates an amount on the user’s wallet (as in the case of a retroactive payment of the “best fare” type.)

[0122] Once authorization for entry is received from the VTS Server 10, Smartphone 20(x) responds positively to the entry request (responds to the requesting antenna), indicating its license plate TAR(x) (given that APPAuto(x) knows it). The transit control system records the authorization and opens the bar, allowing the user to pass.

[0123] The same thing occurs at the exit tollbooth (BLE beacon), where the gate transmits a signal which is received by the APPAuto(x) that records the exit on the VTS Server 10 and then responds to the barrier (via BLE) which opens the bar.

[0124] At the end of the period, the system (of the operator) calculating the transits sends a payment request to the VTS Server 10 indicating a license plate TAR(x) and the toll amount (for example, it is possible to account for a return trip at the end of the day). The VTS Server 10 makes the payment, i.e., it carries out a transaction (blockchain) between the two wallets (user and operator).

[0125] In the event of exit missing, the operator requests the maximum amount from the VTS Server 10, as occurs at tollbooths when a user shows up without an entry ticket; the full fare from the start of the highway stretch is paid.

[0126] In the case b) of payment for parking in closed parking lots (with barriers), the (crypto) payment is made upon leaving, i.e., on the pay and display ticket machine located at the parking lot exit.

[0127] Also in this case, the user has installed a special APPAuto(y) on Smartphone 20(y) and configures it with the license plate TAR(y) of their vehicle. Also in this case, the APPAuto(y) has a public address addAPPAuto(y) associated in the Blockchain network 100.

[0128] The user purchases cryptocurrencies by means of the mechanism described above so as to have a credit associated with such a Smartphone 20(y) (wallet associated with APPAuto(y)). The parking lot operator has its own crypto wallet (not necessarily on the VTS Server 10).

[0129] The user passes under a special antenna (BLE beacon) on the entry pay and display ticket machine, which antenna requests the Smartphone 20(y) to send a pass. Once it receives the entry request, Smartphone 20(y) contacts the VTS Server 10, asking if the user (wallet associated with APPAuto(y)) has the necessary credit for the maximum parking envisaged (fiduciary threshold).

[0130] If yes, the VTS Server 10 pre-allocates an amount on the user’s wallet (as in the case of a retroactive payment of the “best fare” type.)

[0131] Once authorization for entry is received from the VTS Server 10, Smartphone 20(y) responds positively to the entry request (response to the requesting antenna), indicating its license plate TAR(y) (given that the APPAuto(y) knows). The parking control system records the authorization and opens the bar.

[0132] The APPAuto(y) responds immediately to the request (BLE beacon) in the exit pay and display ticket machine, indicating its license plate TAR in the response (BLE). The parking lot management system sends the payment request to the VTS Server 10 indicating, in the request, the amount to be paid (based on the hourly rate and the time spent in the parking lot, the license plate TAR(y) of the vehicle and the parking lot wallet ID).

[0133] The VTS Server 10 identifies the wallet (APPAuto(y)) by means of the license plate TAR(y) and carries out the payment transaction between the user wallet and the one associated with the parking lot operator.

[0134] After the positive response (crypto transaction), the exit pay and display ticket machine opens the bar.

[0135] In the case c) of payment for passage in Limited Traffic Zones, LTZs, with open gates, the user installs a special APPAuto(z) on Smartphone 20(z) and configures it with the license plate TAR(z) of their vehicle. Also in this case, APPAuto(z) has associated a public address addAPPAuto(z) in the Blockchain network 100.

[0136] The user purchases cryptocurrencies by means of the mechanism described above so as to have a credit associated with such a Smartphone 20(z) (wallet associated with APPAuto(z)). The Limited Traffic Zone operator has its own crypto wallet (not necessarily on the VTS Server 10).

[0137] The user passes under a special antenna (BLE beacon) in one of the LTZ gates, which antenna requests Smartphone 20(z) to send a pass. Once it receives the entry request, Smartphone 20(z) contacts the VTS Server 10, asking if the user (wallet APPAuto(z)) has the necessary maximum credit envisaged by the fiduciary threshold.

[0138] If yes, the VTS Server 10 pre-allocates an amount on the user’s wallet (as in the case of a retroactive payment of the “best fare” type.)

[0139] Once authorization for entry is received from the VTS Server 10, Smartphone 20(z) responds positively to the entry request to the requesting antenna, indicating its license plate TAR(z) (given that the APPAuto(z) knows). The system managing the LTZ area associates license plate TAR(z) (read by BLE) with the one read by the transit control system (LTZ camera). The same occurs at the exit LTZ gate.

[0140] The system that calculates the due amount requests payment from the VTS Server 10 after the period of observation (crypto transaction between user wallet and the one of the Operator / Municipality).

[0141] In this case, with respect to the two examples above, the fiduciary threshold may be eliminated because it is always possible to possibly issue a fine in the case of access to the LTZ and failed payment.

[0142] The user has the history of the LTZ tolls carried out in their APPAuto(z).

[0143] The description of specific embodiments provided above shows the invention from a conceptual point of view so that others, using the prior art, will be able to modify and / or adapt in various applications those specific embodiments without further research and without departing from the inventive concept, and, thus, it is understood that such adaptations and modifications will be considered as equivalents of the specific embodiments.

[0144] Means and materials for achieving the various functions described may be of various nature, without departing from the scope of the invention.

[0145] It is worth noting that terminology or expressions used are only descriptive and therefore non-limiting.

[0146] Obviously, without prejudice to the principle of the invention, the construction details and the embodiments can widely vary with respect to what is described and illustrated above by way of example, without departing from the scope of the present invention.

[0147] When the constructive features and techniques mentioned in the claims below are followed by references signs or numerals, such reference signs were introduced for the sole purpose of increasing the intelligibility of the claims themselves, and therefore, such reference signs have no limiting effect on the interpretation of each element identified, by way of example only, by such reference signs.

Claims

CLAIMS1 ) A system for purchasing travel documents 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) synchronized with a Blockchain network (100) and a plurality of Smartphone user devices (20(i)), wherein an application (APP(i), APPAuto(i)) for managing purchases towards at least one Transport company or Operator (40(j), 50(k)) is present on every Smartphone user device (20(i)), wherein every Smartphone user device (20(i)) is provided with a first public address (addAPP(i), addAPPAuto(i)) and said Transport company or Operator (40(j), 50(k)) is provided with a second public address (add40(j), addAPPAuto(k)), wherein said Blockchain Server Node (15) is connected to the Blockchain (100) by means of a connection (30) in Peer to Peer mode, P2P, and locally saves and stores (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, it calculates the current balance of the user of the Smartphone (20(i)) and, in the event of sufficient value, it creates and delivers, to the application (APP(i), APPAuto(i)), a pass or Token which allows the use of the Transport network and which generates a transaction (TE) on the Blockchain (100), wherein the VTS Server (10) authorizes the transaction (TE) by means of the user private key (KEYpr(i)) saved (15w) in the Blockchain Server Node (15), wherein said transaction (TE) transfers the content, or part of it, from a first wallet (20w(i)) belonging to the user of the Smartphone (20(i)) and associated with a first public address (addAPP(i), addAPPAuto(i))) to a second wallet (40w(j)) belonging to 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 documents and for paying tolls and / or parking fees according to claim 1 , wherein said VTS Server (10) is a node of the Blockchain reference network (100) and uses the Blockchain Server Node (15) as an access point to the Blockchain (100).3) The system for purchasing travel documents and for paying tolls and / or parking fees according to claim 2, wherein said VTS Server (10) connected natively to the Blockchain (100) by means of the Blockchain Server Node (15)operates natively thereon by creating internal public addresses (addAPP(i)) and it is configured to create and manage the payment transactions (TE) on the Blockchain (100).4) The system for purchasing travel documents and for paying tolls and / or parking fees according to claim 2 or claim 3, wherein said Blockchain Server Node (15) contains therein a local copy (BC) of the whole Blockchain (100), after the first synchronization.5) The system for purchasing travel documents 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)) belonging to 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) by means of the Peer to Peer connection, P2P, (30).6) The system for purchasing travel documents and for paying tolls and / or parking fees according to any one of the preceding claims, wherein the VTS Server (10): manages the lifecycle of the first public addresses (addAPP(i)) associated with the users of the Smartphone (20(i)) for creation, phone change and calculation of the current balance; manages the lifecycle of the payments for every Smartphone (20(i)) by calculating the amount due by performing the Euro / crypto conversion and withdrawing any commissions to be paid into the wallet of the service provider on Software as a Service systems, SAAS; selects and optimizes the transactions (TE) in cryptocurrencies so as to cover the amount due, minimizing the number of transactions to be used to limit the costs of the same transaction; and creates and manages the economical transactions (TE) by calculating the various components and then correctly signing with the private key (KEYpr(i)) associated with the Smartphone (20(i)).7) The system for purchasing travel documents and for paying tolls and / or parking fees according to any one of the preceding claims, wherein the Blockchain Server Node (15) is configured to:manage the Peer to Peer connection to the Blockchain (100) and the synchronization of the local data with the public data, and vice versa; manage the local cryptocurrency wallet (15w) containing the set of private keys (KEYpr(i)) of the Smartphones (20(i)); and execute the commands sent by the VTS Server (10).8) The system for purchasing travel documents and for paying tolls and / or parking fees according to any one of the preceding claims, wherein the application (APP(i), APPAuto(i)) downloaded onto the Smartphone (20(i)) has a public address (addAPP(i), addAPPAuto(i)) on the Blockchain (100) and the user tops up the wallet (20w(i)) with cryptocurrencies in standard mode.9) The system for purchasing travel documents and for paying tolls and / or parking fees according to any one of the preceding claims, wherein said travel documents may be purchased via cryptocurrencies prior to the fruition of the same trip and used later.10) The system for purchasing travel documents and for paying tolls and / or parking fees according to any one of preceding claims 1 -8, wherein said travel documents may be purchased via “on demand” cryptocurrencies where, by means of a single gesture, the user expresses the will to take a trip, pays for it via cryptocurrencies and validates it by means of a validator operating in Bluetooth Low Energy.11 ) The system for purchasing travel documents and for paying tolls and / or parking fees according to any one of preceding claims 1 -8, wherein said travel documents may be purchased via cryptocurrencies and paid for later, where the amount to be paid via cryptocurrencies is managed in best fare mode.12) The system for purchasing travel documents and for paying tolls and / or parking fees according to any one of the preceding claims, wherein the system allows paying for travel documents by means of the simultaneous management of several Blockchains (100) for a simple and multi-wallet management of the payments for travel documents by the users.13) The system for purchasing travel documents and for paying tolls and / or parking fees according to any one of the preceding claims, wherein the system allows paying for travel documents both in autonomous mode and in Mobility As A Service mode, MAAS, where the system automatically separates “at the root”the amount due to the Transport operator from the one due to the service provider as commissions.14) The system for purchasing travel documents and for paying tolls and / or parking fees according to any one of the preceding claims, wherein the system allows paying for highway tolls, parking lots closed by barriers and transits in Limited Traffic Zones, LTZs, via cryptocurrencies, by indicating the license plate (TAR) of the user’s vehicle.15) The system for purchasing travel documents and for paying tolls and / or parking fees according to any one of the preceding claims, wherein the system allows deferred payments so as to optimize the size of the transactions (TE) on the Blockchain (100) and reduce the subsequent costs due to the same transactions.16) The system for purchasing travel documents and for paying tolls and / or parking fees according to claim 15, wherein the system provides the option of optimizing the transactions (TE) and writing them on the Blockchain (100) when a given value is reached such as an expense threshold or a time threshold.17) The system for purchasing travel documents and for paying tolls and / or parking fees according to any one of the preceding claims, wherein the application (APP(i), APPAuto(i)) downloaded and installed on the Smartphone (20) of the user purchases and pays for the travel documents directly from the VTS Server (10) without interacting with payment and / or validation terminals during the step of purchasing and paying for the travel documents.18) A method for purchasing travel documents and for paying tolls and / or parking fees based on the use of Blockchain technology, comprising providing a VTS Server (10), providing a Blockchain Server Node (15) synchronized with a Blockchain network (100), and providing a plurality of Smartphone user devices (20(i)), wherein the method provides the step of installing, on every Smartphone user device (20(i)), an application (APP(i), APPAuto(i)) for managing purchases towards at least one Transport company or Operator (40(j), 50(k)), wherein the method provides the step of providing every Smartphone user device (20(i)) with a first public address (addAPP(i), addAPPAuto(i)) and the method provides the step of providing said Transport company or Operator (40(j), 50(k)) with a second public address (add40(j), addAPPAuto(k)), wherein the method provides the step ofconnecting said Blockchain Server Node (15) to the Blockchain (100) by means of a connection (30) in Peer to Peer mode, P2P, and wherein the method provides the step of locally saving and storing (15w) a copy (BC) of the Blockchain (100), of the first public addresses (addAPP(i), addAPPAuto(i)) associated with each user and of the private keys (KEYpr(i)) of the users, and wherein the method provides the step of creating, by means of said VTS Server (10), the public addresses (addAPP(i), addAPPAuto(i)) for each application (APP(i), APPAuto(i))) associated with a user, the step of calculating the current balance of the user of the Smartphone (20(i)) and, in the event of sufficient value, the step of creating and delivering, to the application (APP(i), APPAuto(i)), a pass or Token which allows using the transport network and which generates a transaction (TE) on the Blockchain (100), wherein the method provides the step of authorizing, by means of the VTS Server (10), the transaction (TE) by means of the private key (KEYpr(i)) of the user saved (15w) in the Blockchain Server Node (15), wherein the method provides the step of carrying out a transaction (TE) where the content, or part of it, is transferred from a first wallet (20w(i)) belonging to the user of the Smartphone (20(i)) and associated with a first public address (addAPP(i), addAPPAuto(i))) to a second wallet (40w(j)) belonging to the Transport company or Operator (40(j), 50(k)) and associated with a second public address (add40(j), add50(k)).

Images