WO2014122492A1

WO2014122492A1 - Service-based, interoperable, combined fee payment system, particularly for passenger cars

Info

Publication number: WO2014122492A1
Application number: PCT/HU2014/000015
Authority: WO
Inventors: Péter Kapolka; Sándor Zsolt KARDOS
Original assignee: Péter Kapolka
Priority date: 2013-02-09
Filing date: 2014-02-07
Publication date: 2014-08-14

Abstract

A service-based, interoperable, combined fee payment system, particularly for passenger cars comprises a client (1) disposed aboard vehicles, a domain server (4) for each country, wireless data connections between the clients (1) and the domain servers (4), the domain servers (4) having bank connections (7) and POS terminals (3) connected thereto. The system further comprises an EETS server (5) adapted for communicating (6) with the domain servers (4). The client (1) provides a platform having a GSM/GPRS unit, a GPS unit, and a secure storage (secure element) comprising: an application adapted for controlling the operation of the platform and for managing toll routes, an updatable database of toll roads stored in non-volatile memory. The domain servers (4) comprise secure storage elements and user databases ordered on the basis of the vehicle registration numbers of current clients.

Description

Service-based, interoperable, combined fee payment system, particularly for passenger cars

Technical field of the invention The invention relates to a service-based, interoperable, combined fee payment system, particularly for passenger cars that allows the payment of fees and charges related to using public roads by vehicles in an optimal manner, utilising a single technical platform (single apparatus). Field of application

The invention may be applied in multiple countries for collecting the toll fees for toll road sections, toll zones (congestion charges), as well as parking fees in a distance- or usage time-based manner. The system may be integrated in the foreseen European EETS system, as described in Directive 2004/52/EC.

Technical Background

Currently applied fee payment systems utilise toll gates (DSRC) or GPS-driven, distance-based toll fee payment (applying electronic OBU). Systems applying toll gates are inflexible, and are expensive to install and maintain. Due to the high price of the OBU, GPS-based systems are suitable mostly for lorries and trucks. In such systems toll collection is performed by the OBU (On Board Unit) built into the vehicle, as well as by the central server of the system. In some of the countries the toll collection is based on the total distance travelled.

It should also be considered that toll collecting systems currently in operation in the countries of the EU have been implemented independently of one another on a national basis, contain different technical solutions, and are applicable mainly for commercial vehicles.

These systems are either not interoperable or have limited interoperability (such as the German/Austrian "double country" OBU), and therefore often a new OBU has to be installed in a vehicle when an international border is crossed. Settling international transactions is cumbersome, involving a great deal of communication among many participants.

For instance, the system described in US 20010025251 A1 , communicates via RF radio with roadside communication devices in addition to utilising GPS data, the necessary decisions being made based on information obtained from these different sources.

The introduction of the e-Call system known per se is preferred and its larger scale use is foreseen in the EU countries as well. An up to date on board unit should be equipped with a firmware suitable for performing these functions. For new vehicles the due date for introduction of the new services is October 2015.

In inner city toll zones (e.g. in Stockholm and London), as well as in case of toll bridges, the most widespread solution applies toll gate payment systems (utilising LPR cameras). In Singapore, the applied OBU communicates over wireless, with the gates charging the card inserted in the OBU. These systems have an

"entrance fee" -type payment logic, where the fee may be different at different times of the day. One of the problems related to such systems is that, for instance in Budapest, a single-zone toll charging system would require 1000 cameras, the more optimal multi-zone variant requiring as many as 6000 (plus the necessary communication equipment).

Conventional parking meters applied for charging parking fees are costly to install and maintain, and are usually not deployed as densely as desired. In order to utilise a more modern mobile parking (GSM/SMS) system the nearest parking meter has also to be located by the user such that the GSM phone number or identification code may be read, with the cost of the 4 text messages per parking also making the solution more expensive. First-generation parking fee collection systems applied parking meters installed adjacent each parking space. Although second-generation meters cover entire parking zones, they are essentially still nothing more than automated parking ticket dispensers. They have the disadvantage that they cannot provide for service- based charging, as motorists usually leave before the end of the paid-for parking time (i.e. the motorists are overcharged), and they only have coarse positional resolution. It is cumbersome to obtain an invoice suitable for accounting purposes. Motorists search for empty parking spaces on a trial-and-error basis, which causes time and fuel waste. Another serious problem is that the system does not have a unified time base (clocks of the meters and the parking wardens are not

synchronised), since in borderline cases a difference of a few seconds may become decisive of paying a fine. Patent specification P1000698 discloses a modern parking system applying NFC.

Disclosure of the Invention

The object of the invention is to provide a fee payment system that is interoperable between multiple countries, gives a solution for the payment of the above described three types of fees utilising the same technical platform, and is economically feasible even for passenger cars. This object is achieved by a system as defined int he independent claims. Further advantageous embodiments are described by the dependent claims. The system may be used in a convenient manner, the automatic charging and payment process being performed without using cash or requiring the vehicle to stop, the fees - proportional to the travelled distance - being established utilising a centrally managed fare system, and the charges being collected, expediently in a pre-paid manner, from a secure element of the mobile unit (client) disposed in the vehicle, or, in case post-paid charging is applied, from the owner's bank account.

According to an existing directive issued by an EU specialist committee (EETS), it is a long-term goal that a unified solution working in all EU countries is provided. Once the unified interoperable system operates, it becomes possible to drive from e.g. London to Budapest paying the toll fees in all countries in an automatic manner, without being required to stop.

The essential feature of the invention is that the clients disposed aboard vehicles have their own databases containing toll road sections and toll zones, as well as a capability for accurate positioning and timing, being connected (via wireless connection) to one or more dedicated servers corresponding to the country they are in at the moment. Each country participating in the system has at least one server (domain server), the domain server comprising a map database containing the fare table of the toll roads and toll zones, as well as the parking zones and parking fees of the given country, a user database, and a secure storage (a so- called secure element). The domain servers are connected to their respective banks as well as to a common, central EETS server. POS terminals located in the given country are in communication with the bank corresponding to the domain server.

The clients (thick clients) - physically implemented e.g. as smartphones

comprising GPS receivers, or devices integrated in the infocentre of the vehicle - run an application allowing event-oriented communication. The "events" generated by the clients are received and processed by the domain server that sends a response to the current client after the event is processed. Communication is performed utilising GSM/GPRS technology by encrypted, handshake-based message exchange, applying the known PKI (Public Key Infrastructure) method. The "event" may be triggered by entering or leaving a toll route (or region and/or toll zone), by zone change, by the start or end of a parking event, or by other events (such as automatic emergency alarm, SOS, help, etc.)

According to an advantageous feature of the invention, the "purse" storing the balance associated with the vehicle is implemented in the client, utilising a secure storage element. This is typically an ln2Pay MicroSD card (or a cardlet disposed in a SIM card) that implements PKI encryption. In the prepaid case, this payment solution allows any domain server to top up the balance stored in the secure element of the user (client) with the amount paid by the user during a

customization operation (at a POS terminal), or, in case of a given "event", to subtract from the balance a sum corresponding to the calculated fee, which action may then be repeated by any other domain server. In the postpaid case this is not necessary, since the vehicle is identified by the domain server only by its registration number, the account being actually kept only by the corresponding national toll service provider. An account is, of course, also kept in the prepaid case. The balance stored in the secure elements is only for accounting purposes and may be regarded as a kind of cache, the domain servers being required to periodically settle accounts with their own banks in order for actual bank transfers to take place to credit the collected fees of the services provided by them. Information on the domain servers of the countries involved (IP/port addresses or DNS information) is stored in the client's database. The domain server is selected freely by the client. Domain servers comprise:

- fare tables for toll road sections and toll zones, information on parking zones of the home country (polygon coordinates, parking times and fees)

- in the user database, data on the activated, registered vehicles

- TCP/IP (GSM/GPRS or ADSL) connections for the communication.

In practice, each domain server applied in the present invention consists of a Toll Charger and a group of subordinated Toll Service Providers, but for the sake of simplicity, these entities are collectively treated as a single domain server. The EETS server is in communication with the domain servers, the basic functions thereof being the supervising of the domain servers and blacklist management.

Instead of applying a dedicated OBU installed in the vehicle, the mobile client is implemented as a mobile phone (smartphone) of the owner, or as a system embedded in the infocentre of the vehicle that is running a purpose-developed application. Applying this solution the OBU need not be installed, reducing system price and installation time. In case a phone is applied, it should be placed in the driver's field of vision, mounted in a secure manner. Typically, the inputs SOS, emergency request, balance inquiry, or the settings related to vehicle category may be activated by the driver. The current event, as well as the current status of the vehicle, are kept displayed by the mobile client.

The application run by the mobile client typically utilises the peripherals of the phone: the GPS and GSM functions, the display, memory, accelerometer, and the secure element. A database containing data on motorways and/or toll routes (typically in the form of shape files with name and country code, or polygons describing international borders), and, separately, polygons describing toll zones, is stored in the memory of the device. The databases may be updated remotely.

Vehicle registration data are stored by the system in a uniform manner, beginning with a code corresponding to the country of registration (utilising e.g. the three- letter Olympic code: HUNxxxxxx).

In addition to the triple payment functions, additional functions, such as SOS, technical assistance request, automatic emergency alarm (e-call) based on information received from own accelerometer or from the vehicle's airbag, balance inquiry, driving period elapsed alarm, may also be provided. In addition to the e- call function, two further log - necessary for an emergency case reconstruction - are generated continuously: the track and velocity information of the last 1 minute, the velocity and orientation angle information of the last 10 second are written to a non-volatile storage (black-box fuction). If connected to the CAN bus of the vehicle, further essential information (brake pedal, light, signalling) may be stored as well.

Zones may expediently have a multi-zone configuration since, although single zone configurations are widely used, their application is suboptimal. Description of Embodiments shown in the Drawing

As it is shown in the accompanying drawing, the vehicle 1 travelling on toll routes of the countries C1 , C2, C3, and C4 is in contact with the domain server 4 of the corresponding country. The POS terminals 3 communicate with a bank 7 communicating with the domain server 4, while the central EETS server 5 is in communication with all of the domain servers 4.

In a first use scenario the owner of the vehicle has to register the registration number of the vehicle using a POS terminal 3. The required data of the client 1 (country code, registration number, vehicle category, name, address, bank account number, total km value of the distance meter, etc.) are entered in the database of the domain server 4, and the daily counter is deleted. In case the owner of the vehicle is the resident of the current country (local vehicle), the owner may enter into an agreement with the (postpaid) system's service provider, and if necessary, he or she receives or buys a mobile phone, and then the user's data are stored in the server 4 of the user's home country. If the registration is made utilising a POS terminal 3 in a foreign country, the user's data are sent by the domain server 4 to the domain server 4 of the user's home country. In case the user registers for a temporary account, a certain amount of money has to be paid at the time of registration (prepaid case). The new balance is recorded first at the bank 7, and then it passed to the database of the domain server 4.

After the top-up payment is made, when a connection is initiated by the client 1 - either by pressing the "Balance" button or by entering a toll road 2 - the amount is confirmed by the domain server 4 to the client 1 , wherein the new, topped-up balance is stored in the secure element. All further payments are made from the "purse" located in the client 1. A registered user may top up his or her balance from a bank account over the Internet by transferring money to the bank 7 of the domain server 4, which the bank 7 passes on to the domain server 4. The top-up is passed on the client 1 from the domain server 4 the next time the client logs in. By default, the "Zone" and/or "Parking" functions are not used by the client 1.

These functions have to be validated for each country prior to their use, which is accomplished by the country's domain server 4 after the user enters the country.

In case, for instance, all three functions are enabled, then - provided the vehicle is moving - the client 1 automatically searches for a nearby zone centre in the database corresponding to the given country. If a zone centre is found within a given distance, the "Zone" function is activated, otherwise the "Toll roads" function is applied. When the vehicle is not moving, the "Parking" function is activated, the system's display showing icons and other information corresponding to the currently activated function.

According to a fundamental feature of the client 1 , in case the vehicle is moving, events are generated automatically utilising the client's own database, whereas in case of parking the driver's manual input triggers the corresponding event. Then, based on the request received from the client 1 , it is decided by the server 4 whether the vehicle is in a pay parking space.

In case of all events a datagram corresponding to the event is sent by the client 1 to the domain server 4. The message contains the registration number of the vehicle, the current event, balance, position, date, as well as further important information. The received message is logged and confirmed by the domain server 4. A copy of the messages sent and received is stored in the non-volatile memory of the client 1.

In case of an initiation event (such as entering a toll road, toll zone, or beginning to park the vehicle) the status is registered by the domain server 4 and a response is sent to the client 1. In the countries, where the toll is paid according to the distance travellec, the mobile client sends to data to the domain server on a daily basis (after midnight, or at the first stop after midnight, or after passing a country border): the total distance and the (daily) distance travelled since the last recording in kilometer. The payment is made on the basis of the latter, and then the client increases the total distance value by the daily distance and deletes the daily distance storage. The basis of the payment is the kilometer fee which is valid in the current country that may change according to the vehicle category and the time interval of the day. The distance travelled is measured on the basis of GPS data, and may be completed with dead reckoning.

If the balance is low, a warning is issued by the domain server 4, while if the balance is negative, the login request is rejected. The balance of the current client 1 may be checked by the domain server 4 from time to time. In case of a completion event (end of toll road section, leaving toll zone, end of parking) the corresponding fee is calculated by the domain server 4 and is sent to the client 1. The fee is then subtracted from the balance by the client 1.

For toll road sections and toll zones the client 1 displays the name of the given entity as retrieved from the database.

The system also provides for the so-called "free flow" functionality. For instance, a toll road 2 section leading towards the border of country C4 ends before the border, and therefore messages corresponding to a completion event (leaving toll section) are exchanged with the domain server 4. As the driver travels on, entering the toll road 2 section in country C3, a message exchange corresponding to an initiation event (entry) is performed with the domain server 4 of the country C3. The client keeps communicating with the domain server 4 of country C3 as long as the vehicle remains in the country C3.

When an "initiate parking" request is made, the domain server checks whether the vehicle is in a pay parking space, verifies the authorisation of the user, calculates the fee and determines the parking time limit, records the event applying the registration number, and sends a confirmation message.

In case the vehicle is in a paid parking space, the client's display shows the status message corresponding to "parking in progress", as well as the time limit (if applicable). A prepaid card may be used in case the card holds a balance sufficient for paying the fee calculated using the time limit. If no fee has to be paid at the given time and/or location, or the user cannot be found in the database, the client is informed accordingly.

At the end of a parking session a message is sent to the domain server 4 either automatically, triggered by a position change of given magnitude combined with the signal of the acceleration sensor, or manually, by issuing an "end of parking" command. The server then calculates the parking time and fee, records the location and time data in the database, and also sends the data to the client 1. The "parking in progress" icon is then deleted from the display of the client , and the current parking time and parking fee is displayed. At the end of a given billing period (e.g. once a month) the charges incurred in the given period (e.g. month) for the given vehicle (identified by its vehicle registration number) are sent by all domain servers 4 to the domain server 4 of the vehicle's home country. A monthly (detailed) statement may then be sent to the vehicle owner.

For lorries and trucks the vehicle category (based on the number of axles) may be modified by the driver.

Using GPS positioning, the client 1 calculates the distance travelled, and stores it in a storage for accumulated/total distance and daily distance. In case private use mode is selected, the mileage travelled in private use mode is recorded in a separate storage. The mileage values of the distance storages are sent to the domain server 4 of the vehicle's home country from time to time.

The continuous driving time is calculated and recorded by the client 1 using accelerometer and GPS speed readings. If the threshold value specified for the given vehicle category is reached, visual and audible warnings are issued to alert the driver that a compulsory rest period should be started. The rest period is also measured, recorded, and displayed.

When the data input corresponding to a "find nearby empty parking space" request becomes activated, the client 1 receives data from the domain server on the available parking spaces within a given radius, and displays them on a map on its graphic display.

When the "request for help" input of the client 1 becomes activated, a message containing the corresponding event is sent to a dedicated server.

The client 1 is accessible over digital transceiver (Bluetooth or WiFi), which allows for direct communication with the vehicle by an authorised person (parking warden or control station) for controlling purposes. The own address of the digital transceiver located in the vehicle comprises also the registration number of the vehicle.

Vehicles travelling on toll routes and in toll zones may expediently be monitored applying LPR cameras in communication with the domain server 4, or utilising handheld devices of the wardens. The camera monitoring apparatus or the monitoring device of the warden receives status information of the vehicle from the database of the server.

In the countries or zones with road toll payment based on the travelled distance, the roadside cameras for the recognition of the registration number, communicate with two time delayed messages comprising the registration number with the radio equipment of the vehicle. The accumulated and the daily distance is included in both responses. If the received two daily storage values show an increment which corresponds to the velocity and the time, the toll system of the vehicle operates correctly.

Monitoring of the parking:

Parking may be monitored by a parking warden by retrieving from the domain server 4 the registration numbers of nearby parked vehicles to an application running on a GPS-enabled mobile phone together with the corresponding parking time limits. The list may then be applied for checking the parked vehicles. The parking status of a given client 1 may also be retrieved from the database of the domain server 4 by the parking warden by scanning or entering the registration number of a parked vehicle utilising his/her mobile phone.

The client 1 may be in Bluetooth connection with the airbag system and/or anti- theft system of the vehicle. In this case, airbag activation or accelerometer sensor signal results in sending an accident alarm (e-call) to the domain server 4, while the activation of the anti-theft system triggers a theft alarm that is also sent to the server. As the physical position and alarm status of the client 1 is known by the domain server 4, the subsystems required for reacting to the alarm (ambulance service, vehicle security service) may be quickly alerted.

The fee payment system according to the invention may be applied advantageously especially for passenger cars, because:

- the payment of three different types of fee is provided automatically, applying a single device

- it has minimal infrastructure requirements

- it is cheap since, due to the application of functionalities integrated in a mobile phone or in the infocentre of the vehicle as a client, the costs of the OBU and installation can be saved

- the system provides interoperability (EETS) and free-flow functionality

- as the "purse" located in the client 1 is applied as a secure element, no on-line connection is required between the vehicle and the bank 7

- registration and top-up of the prepaid balance may be performed utilising any one of the several POS terminals 3 installed in the countries covered by the system,

- all components of the system utilise the uniform time base of the UTC time provided by the GPS

- the database of the client 1 may be updated remotely, and thereby the system may be flexibly extended or modified

- for trucks and lorries, the vehicle category reported by the client 1 may be set to the actual value by the driver

- in the event of an accident, an automatic emergency call (E-call) is made, or in case the emergency request is activated an alarm is sent that is confirmed by a dedicated server which may also make an automatic call to the client to contact the driver

- it provides the functionality of a black-box which may be basically used in assisting the reconstruction of an accident

- the driver is notified automatically when his/her balance is getting low, or, in case of limited-time pay parking, when the paid-for time is running out

- the driver is notified when the allowed continuous driving time is reached, and the length of particular driving and rest periods may be retrieved from the system's storage

- integrated protection may be provided by connecting the system to the airbag and/or anti-theft system of the vehicle over Bluetooth

- the domain servers 4 can be managed dynamically; mileage costs, toll zone fees, parking fees and time limits may be re-programmed in a simple manner - communications costs are kept low due to event-oriented communication, because events occur relatively rarely, and event messages are short; an event message exchange is implemented by sending a single GPRS message to the domain server and a corresponding response to the vehicle

- the system does not infringe privacy rights because (except checking) calls may only be initiated by the client 1

- the system is user-friendly, because, upon a request from the driver the nearby free parking spaces may be identified

- road use-related toll amounts may be established based on the distances actually travelled by vehicles, and/or private vehicle use may be documented for vehicles owned by enterprises

- the system provides real-time traffic control data

- a backup of the messages is stored in the non-volatile memory of the clients 1 ; the backup may be read and documented over the Internet or at a service station after authentication

- an on-site check of the client 1 may be performed through the domain server 4 or, when the vehicle is not moving, directly via digital transceiver (Bluetooth or WiFi), preferably applying a camera device that may also be running an LPR- enabled application.

Claims

1. Service-based, interoperable, combined fee payment system, particularly for passenger cars, characterised in that

it comprises a client (1) disposed aboard vehicles, a domain server (4) for each country, wireless data connections between the clients (1 ) and the domain servers (4), the domain servers (4) having bank connections (7) and POS terminals (3) connected thereto, the system further comprising an EETS server (5) adapted for communicating (6) with the domain servers (4), wherein the client (1 ) provides a platform having a GSM/GPRS unit, a GPS unit, and a secure storage element comprising an application adapted for controlling the operation of the platform and for managing toll routes, an updatable database of toll roads stored in non-volatile memory; the domain servers (4) comprising secure storage elements and user databases ordered on the basis of the vehicle registration numbers of current clients.

2. The fee payment system according to Claim 1 , characterised by that the mobile client (1) is a smartphone.

3. The fee payment system according to Claim , characterised by that the mobile client ( ) is integrated into the infocentre of the vehicle.

4. The fee payment system according to Claim 1 , characterised by that the mobile client (1) is an OBU arranged in the vehicle.

5. The fee payment system according to any of Claims 2 to 4, characterised by that the mobile client (1 ) comprises a database containing toll zones, an application adapted for managing toll zones, and the domain server (4) comprises a database containing the fees payable in the toll zones.

6. The fee payment system according to any of Claims 2 to 5, characterised by that the mobile client (1) has an application comprising a parking functionality, and the domain server has a map database of car parks and a database of the charges payable in the car parks.

7. The fee payment system according to any one of Claims 2 to 6,

characterised by that the mobile client (1 ) comprises an acceleration sensor adapted for indicating an accident and an e-call functionality with black-box background.

8. The fee payment system according to any one of Claims 2 to 7,

characterised by that the mobile client (1 ) comprises an input adapted for initiating an emergency request.

9. The fee payment system according to any one of Claims 2 to 8,

characterised by that the mobile client (1) comprises a storage for storing total and daily mileage values, data input means for switching to private use mode, as well as a storage for recording private use total mileage.

10. The fee payment system according to any one of Claims 2 to 9,

characterised by that the mobile client (1) comprises data input means for querying nearby free parking spaces, and a display adapted for displaying data received answering the request from the domain server (4).

11. The fee payment system according to any one of Claims 2 to 0, characterised by that the mobile client (1 ) comprises measurement, storage, and alarm functionality for measuring and recording driving periods and rest periods.

12. The fee payment system according to any one of Claims 2 to 11 , characterised by that the mobile client (1) has a digital transceiver or CAN bus data connection to the vehicle and the airbag and/or to the anti-theft system of the vehicle, and/or to a warden's device.