GB2570786A - Distributed ledger for retailing and issuing public transport tickets - Google Patents

Abstract

A computer implemented method of transacting, retailing and issuing public transport tickets in a network comprising a distributed ledger, e.g. blockchain, comprises adding an administration contract to the distributed ledger. The administration contract, may employ smart contract functionality, and comprises, creating one or more flow contracts and assigning flow contracts to transport operators. The flow contracts are created as functions of origin and destination stations, transport mode, whether travel flow is reversible, and a transport operator. Separate contracts are provided to convert tickets stored in the distributed ledger into tickets in operator format. The flow contract maintains an internal dataset of pricing rules that are used to calculate fares. The method further comprises: signing data to the ticket, such as a barcode encrypted with the issuer private key; communicating the collection contract to an oracle to interface with an off-chain signing service; retaining sharing of private keys onto a public blockchain; passing a ticket payload and public address of the ticket to the oracle; signing the ticket payload with an off-chain private key and then the public key of the ticket owner; and adding the encrypted ticket payload to an owner’s wallet.

Description

DISTRIBUTED LEDGER FOR RETAILING AND

ISSUING PUBLIC TRANSPORT TICKETS

Field of the Invention

The present invention relates to system and method for public transport operators to upload fares onto a distributed ledger, allowing them to be retailed and issued using a smart contract. Retailers can use one or more fares from a number of operators to create a ticket using the smart contract. The smart contract apportions the appropriate revenue to each operator as the transaction is executed and the resulting ticket is stored on the distributed ledger.

More specifically separate contracts are provided to convert tickets stored in the distributed ledger into tickets in the native format of the operator

Background to the invention

Ledgers have been at the heart of record keeping in commerce and exchange of goods and services since ancient times. These ledgers have been controlled centrally or in some hierarchical form. In modern days computer based databases, which are based mainly on centralised data storage provide the infrastructure for record keeping.

A recent form of ledger that does not require central administrator or centralised data storage called a distributed ledger (also called a shared ledger, or referred to as distributed ledger technology) works by using a consensus of replicated, shared, and synchronized digital data geographically spread across multiple sites, countries, or institutions. One form of distributed ledger design is the blockchain system, which can be either public or private. But not all distributed ledgers have to necessarily employ a chain of blocks to successfully provide secure and valid achievement of distributed consensus: a blockchain is only one type of data structure considered to be a distributed ledger.

All participants within a network can have their own identical copy of the ledger. Any changes to the ledger are reflected in all copies in very short amounts of times, or in some cases almost instantaneously. The security and accuracy of the assets stored in the ledger are maintained cryptographically through the use of ‘keys’ and signatures to control who can do what within the shared ledger. Entries can also be updated by one, some or all of the participants, according to rules agreed by the network.

There are many networks that are spread and need to be interoperable, and for which networks centralised ledgers cannot work and in fact hinder interoperability. One of these is the transport network.

Privatised public transport networks are common across Europe and Northern America but they are often created in an isolated manner so that neighbouring transport operators work independently from each other. Typically, each operator is given control over a specific mode of transport and a specific geographical region. They have their own ticket formats with their own rules and restrictions, meaning that passengers travelling across operators have to navigate multiple retailers and purchase separate tickets.

While privatisation of public transport networks is becoming more commonplace, the implementation usually varies. The UK rail network was privatised in 1993 under the condition that it continued to offer passengers interoperable tickets that are valid across multiple operators. Other countries, like Spain, Germany and Poland do not offer interoperable tickets and a ticket must be purchased for travel on each operator's network. Both methods of privatisation result in problems for operators and passengers that can be solved using a distributed ledger or a blockchain.

The present invention seeks to provide a solution for public transport tickets that integrates operators from different geographical regions and different modes of transport onto a single network. Making use of blockchain technology and smart contracts, the platform provides a single source of truth for all ticket created, offers real time financial settlement between retailers and operators, and allows customers to purchase tickets for travel across multiple operators in a single transaction.

Summary of the Invention

According to an aspect of the invention there is provided a computer-implemented method for transacting, retailing and issuing public transport tickets in a network comprising a distributed ledger, comprising:

adding an administration contract to the distributed ledger;

the administration contract comprising;

creating one or more flow contracts; assigning flow contracts to transport operators;

wherein the flow contracts are created as functions of an origin station, a destination station, a mode of transport, a boolean condition that determines if travel flow is reversible, a transport operator.

The transport operator may be a flow contract owner.

The flow contract may maintain an internal dataset of pricing rules that are used to calculate fares between two points.

The flow contract owner may further periodically update the dataset using a function provided by the flow contract to modify its internal state.

The administration contract may further comprise;

maintaining a list of flow contracts it has created;

indexing the flow contracts by origin and destination; and presenting transport operators with services between the origin station and destination station to a retailer or customer that queries the list of flow contracts.

The retailer may further perform the steps of;

querying the flow contracts;

selecting and build a list of fares on offer;

accounting for internal variables to reflect localised fare calculation rules; providing an interface that returns a set fares.

The retail contract may be provided by the network, comprising taking a set of fares from one or more transport operators, a set of passengers and the account of the retailer;

executing the retail contract;

transferring funds from a retailer account into an operator accounts; storing one or more tickets in an electronic wallets.

The method may further comprise:

generating a collection contract;

registering the transport operators ticketing formats;

exchanging the passenger’s digital ticket with a token or a ticket collection reference;

maintaining a list of valid collection contracts;

invoking the collective contracts to create a native ticket.

The method may further comprise:

signing data to the ticket, such as a barcode encrypted with the private key of the issuer;

communicating the collection contract to an oracle to interface with an offchain signing service;

retaining sharing of private keys onto a public blockchain;

passing a ticket payload and public address of the ticket to the oracle;

signing the ticket payload with an off-chain private key and then the public key of the ticket owner;

adding the encrypted ticket payload to the owners wallet.

According to another aspect of the invention there is provided a system for managing transactions, retailer and issuance of public transport tickets in a network comprising a distributed ledger, the system comprising:

one or more processors that communicate over the network and add an administration contract to the distributed ledger;

create one or more flow contracts;

assign flow contracts to transport operators;

wherein the flow contracts are created as functions of an origin station, a destination station, a mode of transport, a boolean condition that determines if travel flow is reversible, a transport operator.

The transport operator may be a flow contract owner and the the flow contract is arranged to maintain an internal dataset of pricing rules that are used to calculate fares between two points.

The flow contract owner may have means to periodically update the dataset using a function provided by the flow contract to modify its internal state.

The administration contract may further comprise;

means to maintain a list of flow contracts it has created;

means to index the flow contracts by origin and destination;

means to present transport operators with services between the origin station and destination station to a retailer or customer; and means to query the list of flow contracts.

The retailer may further comprise;

means to query the flow contracts;

means to select and build a list of fares on offer;

means to account for internal variables to reflect localised fare calculation rules;

means to provide an interface that returns a set fares.

The retail contract provided by the network may comprise;

means to take a set of fares from one or more transport operators, a set of passengers and the account of the retailer;

means to execute the retail contract;

means to transfer funds from a retailer account into an operator accounts;

means to store one or more tickets in an electronic wallets.

The system may further comprise:

means to generate a collection contract;

means to register the transport operators ticketing formats;

means to exchange the passenger’s digital ticket with a token or a ticket collection reference;

means to maintain a list of valid collection contracts;

means to invoke the collective contracts to create a native ticket.

The system may further comprise;

means to signing data to the ticket, such as a barcode encrypted with the private key of the issuer;

means to communicate the collection contract to an oracle to interface with an off-chain signing service;

means to retain sharing of private keys onto a public blockchain;

means to pass ticket payload and public address of the ticket to the oracle;

means to sign the ticket payload with an off-chain private key and then the public key of the ticket owner;

means to add the encrypted ticket payload to the owners wallet.

According to a further aspect of the invention there is provided a non-transitory computer-readable medium comprising a computer program adapted to handle the methods disclosed in the invention.

Brief Description of the Drawings

The invention will now be described by way of example only with reference to the accompanying diagrammatic drawings in which:

Figures 1 to 6 are illustrations of the elements of the system in accordance with the invention;

Figures 7 to 10 illustrate diagrammatically a ticketing method in accordance with the invention.

Detailed Description of the Invention

In order to offer interoperable tickets there must be a common ticket format that all operators adopt. This means there must be a governing body to enforce the standards, usually by an expensive and bureaucratic accreditation process.

Tickets sold that use multiple operators must go through a settlement process to divide the money and allocate it to each operator appropriately. This adds a significant amount of time to an already slow financial process and is a potential source of discrepancies. Typically there is no single source of truth for tickets sold, tickets created, tickets used and money settled. Ticket retailers need to integrate with an issuer which then needs to report tickets issued to the settlement system. Ticket use is not typically factored into the settlement process and it is therefore inherently inaccurate.

Retailers must have and in depth knowledge of all the industry system and standards. There is a high level of trust required to retail in this environment and it can be expensive to earn.

This invention provides a system and method for public transport operators to upload fares onto a distributed ledger, allowing them to be retailed and issued using a smart contract. Retailers can use one or more fares from a number of operators to create a ticket using the smart contract. The smart contract apportions the appropriate revenue to each operator as the transaction is executed and the resulting ticket is stored on the distributed ledger. Separate contracts are provided to convert tickets stored in the distributed ledger into tickets in the native format of the operator.

Isolated Networks

Where there are no interoperable tickets, travel across multiple operators must be arranged separately and results in many transactions that must be managed independently by the passenger.

It is often not possible to offer the passenger a ticket permitting travel across a choice of operators, forcing the passenger to make decisions at the time of purchase rather than the time of travel.

Each operator will typically use their own format of ticket, maintaining its own notion of what the types of ticket are and what restrictions apply. This forces the passenger to become an expert of multiple systems to gain the best value from each.

The concept of a blockchain is as an immutable, distributed sequence of transactions that move digital assets between two parties. The blockchain itself is shared by all members of the network and each transaction is verified by members of the network.

Blockchains also provide the infrastructure for programmable smart contracts. Any business can transaction can be modelled using a smart contract and executed as a transaction in a peer-to-peer network.

Using a blockchain to store ticket transactions it is possible to tie together the retailing, creation, use and settlement of tickets from multiple operators in a single place to ensure a faster, more accurate financial settlement process.

The Planar Network

The Planar Network is a platform that provides retailers, operators and transport authorities the necessary infrastructure to create and retail interoperable tickets regardless of mode of transport or geography.

By storing the network topology on the blockchain it is possible to establish a number of trusted transport operators (Operators) that are permitted to offer contracts for transport between a subsection of the overall transportation network. Each Operator can be assigned its geographical region by a transport authority (Authority). There may be many Authorities on the platform covering a wide range of modes and geographical regions.

Referring to Figure 1, each Authority assigns Operators their geographical region by giving them permission to create Fares on a set of Flows. Flows are predefined subsections of the network consisting of an origin, destination and route code to determine the intermediate stops.

A Fare is an asset created by Operators in order for Retailers to offer travel tickets to the public. Each fare has a minimum set of properties - a Flow, validity duration and price. The ticket creation contract takes a Fare and money as an input and produces a Ticket on the blockchain when it is executed.

Referring to Figure 2, a Ticket has the same properties as the Fare used to create it but it also has an owner (the Passenger) and concrete validity dates (as opposed to a proposed validity duration). In a blockchain ledger a wallet is a public/private key pair. Ownership of assets is assigned to a wallet using its private key to sign messages that can be verified using its public key. This means that only the owner of a wallet can sign off transactions involving that wallet.

Referring to Figure 3, when the passenger requires transport across several Operators a Retailer can negotiate contracts with each Operator and present them all as a single contract to the passenger. Given there are multiple ways to traverse most transport networks the Passenger may be presented with multiple options at varying cost. This gives us a means to integrate Fares from Operators across any mode of transport or geographical region.

Some tickets allow the Passenger a choice of multiple operators. In this situation the money from the ticket sale could be put in escrow until the Passenger travels and their actual choice of Operator is recorded. It is not always possible to report accurate Passenger movements, in the event no information is received the money in escrow could be apportioned using a fall-back algorithm to split the money between likely Operators.

Financial Settlement

Using a digital representation of currency (fiat or otherwise) allows the allocation of money to be tied to the creation of Tickets. As the ticket creation contract is executed it generates a transaction on the blockchain in which digital currency from the Retailer is exchanged with the Operator(s) for the right to travel on their services. The transaction generates a Ticket which represents the passenger’s right to travel on the Operator's services.

This moves the system from one that tries to reconcile money taken from ticket sales with recorded ticket creation after the event has occurred to a real-time system where money is settled as tickets are created.

Retailing an Operator’s tickets requires a high level of trust because retailing tickets is intrinsically linked to creating tickets. Creating a ticket creates a liability for the operator to transport a passenger so Operators are very careful with who they trust to retail tickets.

Typically, this trust is earned through an accreditation process and a financial bond. The accreditation process is there to ensure that tickets are created correctly and ticket sales are reported accurately. The bond is there to ensure the Retailer can give the Operator the money they’re owed for any ticket sales.

The accreditation process and financial bond both add a significant cost to any Retailer looking to enter the market.

Using a blockchain and smart contracts there is no need for this trust, allowing new Retailers to enter the market at a lower cost.

Retailers can only create tickets by executing the smart contract provided by the network with fares created by the Operators. This smart contract cannot be incorrectly executed so the Retailer is not at risk of incorrectly creating tickets or misrepresenting sales.

As the Passenger acts through the Retailer their retail experience is unchanged. They would only be aware of the traditional card transaction with the Retailer and would not need to own any digital currency, as seen in Figure 4.

Refund transactions are the reverse of a Ticket sale. The Operator gives digital currency back to the Retailer in exchange for cancellation of the Passenger’s Ticket. The Retailer is then responsible for exchanging the digital currency into local currency for the Passenger. Typically each transport network has its own rules to define when and how much of a Ticket may be refunded. These rules can be established by the Authority and built into the refund contract that is executed on the network. The refund itself might be a full or partial refund of the Ticket or might even be part of an exchange transaction that also contains a Ticket sale.

Passenger Travel

After the Ticket sale process has occurred the Passenger’s wallet is the owner of a Ticket on the blockchain. This Ticket is not a physical coupon but a digital asset that gives them the right to travel on one or more Operators’ services.

The Passenger does not have to be aware that they have a digital wallet on the blockchain network and as there is no practical upper limit to the number of wallets available, a new wallet can be created for one-off transactions.

Where the Passenger has an account with a Retailer their wallet could be reused between transactions and would therefore hold multiple Tickets, as well as a history of expired Tickets.

The Retailer would be responsible for creating and providing access to their Passengers’ wallet. As the wallet is just a private key it can be exported in a portable format to be used with other Retailers or supporting applications (e.g. smartphone wallet applications).

All transport networks have a well-entrenched infrastructure of gates, ticket scanning and validation mechanisms. It’s not feasible to immediately upgrade the existing infrastructure to directly query the blockchain for ticket validation. Instead, an integration layer must be provided to create ticket coupons in each network's existing formats to ensure that existing infrastructure will continue to work.

Some networks may offer the passenger multiple ticket formats depending on the geographical region and operators involved. These can range from physical coupons to digital barcodes or smartcards.

Physical coupons are typically self-verifying in that their validity can be checked without a connection to a central database. In order to prevent fraud, physical coupons rely on there only ever being one version of that ticket in existence at any time.

Digital tickets are validated either using a connection to a central database that is checked in real-time or a hot-listing mechanism where tickets that have already been scanned are stored locally.

Referring to Figure 5, by adding a number of Ticket Distributors to the network we can implement a collection process where the Distributors act as an intermediary to create ticket coupons in the networks native formats.

If one of these formats relies on their only being one copy of the coupon the Ticket can be marked as collected so that Distributors could not create additional coupons.

This would allow the Passenger to defer the decision about which ticket format they would like to use until the time of travel, as opposed to being forced to choose before purchase.

Referring to Figure 6, the Ticket Distributors could be physical printing machines at the station connected to the blockchain network or they could be a web service for existing systems to integrate with. When the Passenger decides on their preferred coupon format they would inform the Retailer (or third party application) who would create a collection contract with a Ticket Distributor. The Distributor could offer to deliver the coupons by post, place them in a vending machine for collection or return a barcode.

Where the passenger is travelling across multiple operators with different formats the Ticket can be part collected by multiple Distributors. Each Distributor providing travel coupons (native tickets) for the parts of the journey it understands.

A network fully integrated with the blockchain would not require physical coupons or tokens and by extension would not require Distributors. It would operate on a proof of identity model where each validation point would run a node on the network and access the blockchain to check whether the identity presented owns a valid Ticket for travel.

All tickets have a unique identifier that can be reported back to the network upon use. Using this identifier we can approximate (exact use is often impossible) what Tickets have been used on what services. This ensures tickets are used the correct number of times and also provides accurate settlement information where multiple use of multiple Operators is possible.

Having a portable ticket wallet that can store tickets for travel across multiple operators greatly simplifies the practicalities of traveling across a multi-operator network. All tickets can be accessed via a single app or collected using the networks existing infrastructure.

The passenger doesn’t have to choose what format the tickets coupons are in before they purchase, the ticket can live in their digital wallet until they collect them as a native format.

The Planar Network is a distributed system that provides a platform for retailing, creation and distribution of travel tickets. A distributed ledger is used as the single source of truth for all tickets created and used within the system. This distributed ledger is shared between all participants of the network (operators, retailers and distributors) allowing them to interact with each other autonomously.

All modes of transport and geographical regions are supported and fares multiple operators may be retailed together in a single transaction allowing the customer to purchase tickets for an end to end multi-modal journey from a single retailer.

The Planar Network does not require any physical infrastructure - ticket distributors provide an interoperability layer allowing tickets created on the platform to be converted to each operator’s native format removing the need for additional gate validation or scanning devices.

Ticketing process in accordance with the invention

Setup - An administration contract is added to the distributed ledger. This contract provides a method of creating the flow contracts and assigning them to transport operators. This is defined as:

f(O, D, M R TO) C

Where:

O is the origin station

D is the destination station

Λ/is the mode of transport (e.g. train, bus, ferry, plane)

R is a boolean that determines if the flow is reversible

TO is the transport operator (owner of the flow contract)

C is the flow contract

The flow contract maintains an internal dataset of pricing rules that are used to calculate fares between two points. For a distance based flow this might be cost per kilometre or for a point to point fare it might be a specific cost for a particular ticket type.

The flow owner (transport operator) can periodically update this dataset using a function provided by the contract to modify its internal state.

Querying - Referring to Figure 7, the administration contract maintains a list of flow contracts it has created, indexed by origin and destination. A retailer or customer can query this list to find a number of operators that might offer transport services between a particular origin and destination. The flow lookup function is described as:

f(O, D,M\ 0)^{C}

Where:

O is the origin station

D is the destination station

M | 0 is the mode of transport or null

C is a flow contract

Once the list of relevant flow contracts has been returned the retailer can query each of them to build a list of fares on offer. The operation of flow contracts may vary internally to reflect localised fare calculation rules (e.g. point to point / distance based) but they all must provide an interface that returns a set fares, defined as:

f(O, D, {P}, OD, RD \ 0) {F}

Where:

O is the origin station

D is the destination station {P} is a set of passengers

OD is the outward date

RD 0 is the return date or null

F is a fare

Retail - Referring to Figure 8, a retail contract is provided by the network that takes a set of fares from one or more transport operators, a set of passengers and the account of the retailer. When executed the contract will transfer the necessary funds from the retailer account into the operators’ accounts and store one or more tickets in the passengers wallets. The term retailer covers both third party retailers acting on behalf of a customer and customers interacting directly with the retail contract. The retail contract is a function described as:

f({F}, {P}, R) - {T}

Where:

{F} is a set of fares {P} is a set of passengers {R} is the account of the retailer {T} is a set of tickets

Ticket Storage - The network provides an Non-fungible Token Standard #721 ERC721 compliant contract to store tickets. 1 This gives passengers access to any tickets they have purchased, as well as the ability to transfer ownership of tickets. Each ticket is considered an non-fungible asset that the passenger has exclusive access to. The origin, destination, route, number of passengers and price are stored.

Collection - Referring to Figure 9, each transport network brings its own infrastructure and ticketing formats. As such, each ticket format requires its own collection contract. The collection contract is responsible for exchanging a passenger’s digital ticket with a token, be it a physical ticket, digital ticket, or a ticket collection reference.

All tickets maintain a list of valid collection contracts that may be invoked to create a native ticket. As the return value of the contract may be a range of values (i.e. a collection reference, a barcode payload or postal delivery reference) the interface is described as:

f({T}) - {R}

Where:

{F} is a set of fares {R} is a set of collection references or ticket payloads

Ticket formats that only allow a ticket to be collected a single time use the internal state of the collection contract to maintain a record of which tickets have already been collected to prevent duplication collections.

A number of collection contracts are provided but it is an open market and authorized third party agents or ticket issuers can also provide collection contracts. It is at the discretion of the operator offering the fares to decide which issuers can produce tickets valid for their network.

Some issuers charge a transaction fee to execute the collection contracts to cover costs like postal delivery or other fulfilment media costs.

Signed Data - Referring to Figure 10, there are some ticket formats that require the ticket payload to contain signed data, such as a barcode encrypted with the private key of the issuer. In this case the collection contract must make use of an oracle to interface with an off-chain signing service to avoid or retain putting private keys onto a public blockchain.

The collection contract passes the ticket payload and public address of the ticket owner to the oracle that signs the payload with the off-chain private key and then the public key of the ticket owner, adding the encrypted ticket payload to the owners wallet.

Encrypting the payload with the issuers private key ensures that the ticket has been created by a valid issuer. Gates and ticket scanners store the issuers public key and verify that the ticket is valid. Encrypting it with the public key of the owner ensures that only the owner can decrypt the payload (using their private key) and present it to gates and validation devices.

Other variations and modifications will be apparent to the skilled person. Such variations and modifications may involve equivalent and other features which are already known and which may be used instead of, or in addition to, features described herein. Features that are described in the context of separate embodiments may be provided in combination in a single embodiment. Conversely, features which are described in the context of a single embodiment may also be provided separately or in any suitable sub-combination. It should be noted that the term comprising does not exclude other elements, the term a or an does not exclude a plurality, a single feature may fulfil the functions of several features recited in the claims and reference signs in the claims shall not be construed as limiting the scope of the claims. It should also be noted that the Figures are not necessarily to scale; emphasis instead generally being placed upon illustrating the principles of the present disclosure.

Claims (19)

1. A computer-implemented method for transacting, retailing and issuing public transport tickets in a network comprising a distributed ledger, comprising:

adding an administration contract to the distributed ledger;

the administration contract comprising;

creating one or more flow contracts;

assigning flow contracts to transport operators;

wherein the flow contracts are created as functions of an origin station, a destination station, a mode of transport, a boolean condition that determines if travel flow is reversible, a transport operator.

2. A computer-implemented method in accordance with claim 1, wherein the transport operator is a flow contract owner.

3. A computer-implemented method in accordance with claims 1 or 2, wherein the flow contract maintains an internal dataset of pricing rules that are used to calculate fares between two points.

4. A computer-implemented method in accordance with any of the previous claims, wherein the flow contract owner periodically updates the dataset using a function provided by the flow contract to modify its internal state.

5. A computer-implemented method in accordance with any of the previous claims, wherein the administration contract further comprises;

maintaining a list of flow contracts it has created;

indexing the flow contracts by origin and destination; and presenting transport operators with services between the origin station and destination station to a retailer or customer that queries the list of flow contracts.

6. A computer-implemented method in accordance with any of the previous claims, wherein the retailer further performs the steps of;

querying the flow contracts;

selecting and build a list of fares on offer;

accounting for internal variables to reflect localised fare calculation rules; providing an interface that returns a set fares.

7. A computer-implemented method in accordance with any of the previous claims, further comprising a retail contract provided by the network, comprising taking a set of fares from one or more transport operators, a set of passengers and the account of the retailer;

executing the retail contract;

transferring funds from a retailer account into an operator accounts;

storing one or more tickets in an electronic wallets.

8. A computer-implemented method in accordance with claim 7, further comprising generating a collection contract;

registering the transport operators ticketing formats;

exchanging the passenger’s digital ticket with a token or a ticket collection reference;

maintaining a list of valid collection contracts;

invoking the collective contracts to create a native ticket.

9. A computer-implemented method in accordance with claims 7 or 8, further comprising;

signing data to the ticket, such as a barcode encrypted with the private key of the issuer;

communicating the collection contract to an oracle to interface with an offchain signing service;

retaining sharing of private keys onto a public blockchain;

passing a ticket payload and public address of the ticket to the oracle;

signing the ticket payload with an off-chain private key and then the public key of the ticket owner;

adding the encrypted ticket payload to the owners wallet.

10. A system for managing transactions, retailer and issuance of public transport tickets in a network comprising a distributed ledger, the system comprising:

one or more processors that communicate over the network and add an administration contract to the distributed ledger;

create one or more flow contracts;

assign flow contracts to transport operators;

wherein the flow contracts are created as functions of an origin station, a destination station, a mode of transport, a boolean condition that determines if travel flow is reversible, a transport operator.

11. A system in accordance with claim 10, wherein the transport operator is a flow contract owner.

12. A system in accordance with claims 10 or 11, wherein the flow contract is arranged to maintain an internal dataset of pricing rules that are used to calculate fares between two points.

13. A system in accordance with any of the previous claims, wherein the flow contract owner has means to periodically update the dataset using a function provided by the flow contract to modify its internal state.

14. A system in accordance with any of the previous claims, wherein the administration contract further comprises;

means to maintain a list of flow contracts it has created;

means to index the flow contracts by origin and destination;

means to present transport operators with services between the origin station and destination station to a retailer or customer; and means to query the list of flow contracts.

15. A system in accordance with any of the previous claims, wherein the retailer further comprises;

means to query the flow contracts;

means to select and build a list of fares on offer;

means to account for internal variables to reflect localised fare calculation rules;

means to provide an interface that returns a set fares.

16. A system in accordance with any of the previous claims, wherein the retail contract provided by the network comprises;

means to take a set of fares from one or more transport operators, a set of passengers and the account of the retailer;

means to execute the retail contract;

means to transfer funds from a retailer account into an operator accounts;

means to store one or more tickets in an electronic wallets.

17. A system in accordance with claim 16, further comprising means to generate a collection contract;

means to register the transport operators ticketing formats;

means to exchange the passenger’s digital ticket with a token or a ticket collection reference;

means to maintain a list of valid collection contracts;

means to invoke the collective contracts to create a native ticket.

18. A system in accordance with claims 16 or 17, further comprising;

means to signing data to the ticket, such as a barcode encrypted with the private key of the issuer;

means to communicate the collection contract to an oracle to interface with an off-chain signing service;

means to retain sharing of private keys onto a public blockchain;

means to pass ticket payload and public address of the ticket to the oracle;

means to sign the ticket payload with an off-chain private key and then the public key of the ticket owner;

means to add the encrypted ticket payload to the owners wallet.

19. A non-transitory computer-readable medium comprising a computer program adapted to handle the methods of claims 1 to 9.