WO2018203827A1

WO2018203827A1 - System and method for managing vehicular road usage

Info

Publication number: WO2018203827A1
Application number: PCT/SG2018/050202
Authority: WO
Inventors: Syam Sasidharan Nair; Shubhrendu KHOCHE; Chee Leong Liew
Original assignee: Mastercard Asia/Pacific Pte. Ltd.
Priority date: 2017-05-02
Filing date: 2018-04-26
Publication date: 2018-11-08
Also published as: SG10201703583YA

Abstract

There is provided a system and method for managing vehicular road usage, wherein distance and location traversed by a vehicle are determined by an in-vehicle processing unit. A vehicular road usage surcharge is determined by the in- vehicle processing unit. Payment information is sent to a central server. Subsequent payment of the surcharge is performed by a payment processing system using a digital wallet account associated with a user of the vehicle. The user can decide to vary road usage habits/patterns depending on a frequency and/or quantum of payments carried out via the digital wallet. Correspondingly, vehicular volume is also affected.

Description

SYSTEM AND METHOD FOR MANAGING VEHICULAR ROAD USAGE Cross-Reference to Related Applications

The disclosure of the specification of Singaporean Patent Application No. 10201703583Y, is incorporated herein by reference. Background of the Invention

The present invention relates to a system and method for managing vehicular road usage.

Description of the Prior Art

Many cities globally typically encounter issues in relation to traffic congestion. The congestion causes inhabitants in the cities to suffer from substantial delays in their daily lives. Overall work productivity drops and inconveniences increase, leading to adverse effects on the economies of the cities.

In order to tackle this problem, some cities resort to the use of tolls to manage traffic volume traversing within high traffic areas like business districts. Some examples of such cities include London (which has implemented a congestion charge) and Singapore (which has implemented a system called electronic road pricing, or ERP), whereby traffic entering into the business districts is levied a surcharge.

Taking Singapore as an example, the electronic road pricing system relies on use of static gantries to levy the surcharges as vehicles pass under the gantries. Typically, payment for the surcharges is carried out as the vehicles pass under the gantries, and a driver of each vehicle needs to maintain positive credit in a payment card in order to carry out payment of the surcharges. In addition, the locations of the gantries are fixed and the boundaries for levying surcharges must therefore be static as a consequence.

It is appreciated that existing solutions for dealing with traffic congestion can be enhanced. It is generally desirable to improve consumer experiences when making payment for vehicular road usage surcharges. Summary of the Present Invention

In a first aspect, there is provided a system for managing vehicular road usage, the system including one or more electronic processing devices configured to: determine, at an in- vehicle processing device, journey parameters indicative of a distance and at least one location traversed by a vehicle; determine, at the in-vehicle processing device, payment information indicative of a payment amount representing a vehicular road usage surcharge in accordance with the journey parameters; transmit, to a central server, the payment information; determine, at a payment processing system, a pairing of user account information with the in-vehicle processing device; and use, at the payment processing system, the user account information to thereby cause the vehicular road usage surcharge to be paid from a digital wallet account associated with the user account information.

There is also provided a method for managing vehicular road usage, the method including, in one or more electronic processing devices: determining, at an in-vehicle processing device, journey parameters indicative of a distance and at least one location traversed by a vehicle; determining, at the in-vehicle processing device, payment information indicative of a payment amount representing a vehicular road usage surcharge in accordance with the journey parameters; transmitting, to a central server, the payment information; determining, at a payment processing system, a pairing of user account information with the in-vehicle processing device; and using, at the payment processing system, the user account information to thereby cause the vehicular road usage surcharge to be paid from a digital wallet account associated with the user account information.

In a further aspect, there is provided an in-vehicle processing device for managing vehicular road usage, the device including one or more electronic processing devices configured to: determine journey parameters indicative of a distance and at least one location traversed by a vehicle; determine payment information indicative of a payment amount representing a vehicular road usage surcharge in accordance with the journey parameters; and transmit, to a central server, the payment information.

In a final aspect, there is provided a non-transitory computer readable storage medium embodying thereon a program of computer readable instructions which, when executed by one or more processors of an in-vehicle device in communication with a central server, cause the in-vehicle device to perform a method for managing vehicular road usage, the method being embodied in the steps of: determining journey parameters indicative of a distance and at least one location traversed by a vehicle; determining payment information indicative of a payment amount representing a vehicular road usage surcharge in accordance with the journey parameters; and transmitting, to a central server, the payment information.

It will be appreciated that the broad forms of the invention and their respective features can be used in conjunction, interchangeably and/or independently, and reference to separate broad forms is not intended to be limiting. Brief Description of the Drawings

A non-limiting example of the present invention will now be described with reference to the accompanying drawings, in which: -

Figure 1 is a flow chart of an example of a method for managing vehicular road usage;

Figure 2 is a schematic diagram of an example of a system for managing vehicular road usage;

Figure 3 is a schematic diagram showing components of an example user device of the system shown in Figure 2;

Figure 4 is a schematic diagram showing components of an in-vehicle processing device of the system shown in Figure 2;

Figure 5 is a schematic diagram of an example of a central server of the system shown in Figure 2;

Figure 6 is a schematic diagram showing components of an example payment processing system of the system shown in Figure 2;

Figures 7A to 7B is a flowchart of a specific example of a method for managing vehicular road usage;

Figure 8 is a flowchart of an example of a method of account setup with the central server before the system shown in Figure 2 is used;

Figure 9 is a specific implementation of a method of account setup; and

Figure 10 is a specific implementation of a method for managing vehicular road usage. Detailed Description

An example of a method for managing vehicular road usage will now be described with reference to Figure 1. For the purpose of illustration, it is assumed that the method is performed at least in part using one or more electronic processing devices such as a suitably programmed microcontroller forming part of an in-vehicle processing device and in communication with one or more servers and user devices, such as mobile phones, portable computers, tablet computers, or the like. The in-vehicle processing device can be removable from the vehicle if it is configured to be used outside of the vehicle. The server and user devices are also typically in communication with a payment system which may comprise any suitable computer system such as a server that is capable of processing payments made by the user and which may include a number of processing devices associated with each of an issuer, acquirer, card network and payment gateway, or alternatively, the payment processing system may include any one or more of these entities and this will be discussed further below.

The term in-vehicle processing device is intended to cover any electrical device that acts as a "brain" for controlling at least some functionalities of a vehicle. It can be removable from the vehicle if it is configured for use in such a manner. The in-vehicle processing device will typically include one or more electronic processing devices such as a suitably programmed microcontroller.

Moreover, throughout the following paragraphs, whilst specific reference is made to a central server, typically, the central server is administered by an entity which manages vehicular infrastructure, and can be a government agency or the like.

Furthermore, throughout the following paragraphs, the term "vehicular road usage surcharge" can refer to at least one of the following scenarios of, for example, a surcharge for traversing to a pre-defined location that is chargeable at a juncture of arrival at the pre-defined location, a surcharge for distance traversed by the vehicle determined at a pre-defined interval like every day/week/month, and so forth. In this example, at step 100 the in-vehicle processing device determines journey parameters of the vehicle operated by a user. The in-vehicle processing device may determine a distance and a location(s) traversed by the vehicle, in any suitable way, including for example by use of a positioning system (such as the Global Positioning System (GPS) or GLONASS). At step 110, a vehicular road usage surcharge quantum indicative of usage of the vehicle in accordance with a distance and a location(s) traversed by the vehicle with respect to a road network is then determined. This step may be performed by the in-vehicle processing device or alternatively, by a central server which is administered by the entity which manages vehicular infrastructure. The central server may be cloud based. In this step, the location of the vehicle is derived, for example, from the positioning system, whereby the location is with respect to a road network (such as a street, road, area, postcode and the like). The road network information will typically be provided in the form of a map which may be stored locally in the in-vehicle processing device or obtained from or stored in the central server or database associated therewith. Pre-defined locations in the road network will have an associated access surcharge whenever the vehicle traverses to the pre-defined locations. The associated access surcharges can vary depending on a time, date and vehicle type that the vehicle traverses the pre-defined locations. For example, there can be graduated access surcharges during the different time windows in a day, ranging from $0.00 to $5.00 for passenger cars, whilst the graduated access surcharges range from $0.00 to $10.00 for commercial-use vehicles like vans and lorries. There can also be graduated usage surcharges for the distance travelled by the vehicle. For example, a first vehicle that travels for more than 100km per day is charged a rate of $0.05 per kilometre, whilst a second vehicle that travels less than 30km per day is charged a rate of $0.01 per kilometre.

At step 120, in response to determining the vehicular road usage surcharge for the vehicle, the method further includes, determining user account information associated with an account of the user. The user account information may be indicative of a payment card or bank account of the user and may be associated with a mobile application executing on the user device. The user account information may be stored in a digital payment wallet linked to the mobile application. Typically, the central server will retrieve the account information from the user device, for example from the digital payment wallet. At step 130, the account information and payment information is provided to a payment processing system to thereby cause the vehicular road usage surcharge to be paid from the user account. Typically, this step is performed by the central server which is configured to handle payment transactions with the payment processing system, comprising for example a payment service provider, acquirer, card network and issuer. In at least one example, the above method causes the vehicular road usage surcharge to be paid automatically during instances such as, for example, at a pre-defined date, arrival of the vehicle at a pre-defined location, and so forth. Typically, the payment process is performed automatically and seamlessly without involvement of the user after an initial set-up process of linking the user account to the central server.

Typically, the digital payment wallet generates payment data which is transmitted to the payment processing system. The payment data comprises, for example, the amount of the payment, a tokenized version of a primary account number (PAN) of a desired payment instrument, an expiry date of the payment instrument, and other information required to generate an authorization request for a transaction (for example, formatted according to the IS08583 standard). The authorization request comprises PAN or token, as well as encrypted transaction details may be in the form of an EMV cryptogram, sometimes known as an authorization request cryptogram or ARQC. The ARQC is typically generated according to the EMV specification, or according to an implementation thereof, such as M/Chip Advance of Mastercard International Incorporated.

The central server then submits an authorization request to, for example, a payment service provider (PSP) or the acquirer, the authorization request comprising the PAN, or the token, and the cryptogram. The acquirer or PSP then routes the authorization request, based on the PAN/token, to the payment processing system and the payment processing system then identifies, based on the PAN or token, the issuer to which the request should be routed. In the case of a tokenized transaction, prior to sending the authorization request to a transaction processing system of the issuer (the issuer processor), the token is mapped back to the PAN with which it is associated by sending a request to a token service provider (TSP) such as Mastercard Digital Enablement Service (MDES). Once received by the issuer processor, the ARQC is validated against a corresponding ARQC generated by the issuer (in known fashion according to the EMV standard or an implementation thereof, such as M/Chip of Mastercard International Incorporated). On successful validation, an authorization response comprising data indicating success or otherwise of the transaction request, and an authorization response cryptogram (ARPC), is generated by the issuer and sent back to the acquirer via the payment network (with the PAN being re-mapped to the token by the TSP, as appropriate, prior to being transmitted to the acquirer). The authorization response is then transmitted to the central server, and the ARPC is transmitted to the digital payment wallet, where it is validated against a corresponding ARPC generated by the digital payment wallet. Success, or otherwise, of the validation is transmitted from the digital payment wallet back to the central server, which confirms completion of the authorization request.

After a user has paid for the vehicular road usage surcharge, the central server may generate a notification that the vehicular road usage surcharge has been paid, and provide the notification to the in-vehicle processing device. The in-vehicle processing device may responsive to receiving the notification, generate a representation of the notification and cause the representation to be displayed to the user. In this way, the user is informed that the surcharge has been paid without any intervention. An excessive number of notifications may assist in making drivers more attentive to their driving behaviour pertaining to vehicular road usage.

The method may therefore further include generating a notification indicative of a warning that the vehicle has traversed slightly less than a pre-defined distance within a pre-defined time period. The in-vehicle processing device may then generate a representation of the notification and display the representation to the user so that the user is aware that a higher rate of the vehicular road usage surcharge is forthcoming. In one example, a visual warning notification may be provided, however, alternatively an audible warning may be provided or a combination of both. Any number of warnings may be provided depending on the preferred implementation. For example, the notification may be triggered approximately 10km before the pre-defined distance. Accordingly, it will be appreciated that at least in one example, the above described process provides a number of advantages. By moving the knowledge of vehicular road usage costs to the end-user (i.e. the driver), the end-user receives clear visibility of payable costs regarding vehicular road usage, and correspondingly, the end-user may be inclined to minimise unnecessary vehicular use in order to minimise costs. This can also lead to reduction of pollution emitted by vehicles. Furthermore, substantial cost savings can also be made by the entity which manages vehicular infrastructure. For example, the entity will no longer be required to purchase, install, maintain or monitor equipment and administrative processes designed to administer to levying vehicular road usage surcharges. Moreover, from an administrative perspective, as the vehicular road usage surcharge is deducted automatically from the user's account, there would be additional savings in no longer having to administer fines for non-payment or late payment of the road usage surcharge to users and to subsequently chase up on whether the fines have been paid. In addition to monetary benefit, there would also be a human resources benefit as the entity staff can be reallocated to perform other tasks.

In addition, as a user would be able to monitor their own vehicular road usage behaviour by the costs payable for the vehicular road usage surcharges, it is likely that over time, the user's attitude towards vehicular road usage will change favourably, which may lead to an overall reduction in traffic on roads at specific times and correspondingly, pollution by vehicles would also be reduced.

From a user's perspective, they would be incentivised to use the system because of the convenience of payment for vehicular road usage surcharges being carried out on their behalf with little effort being expended on their part (primarily during a setting up portion, which will be described in greater detail at a later portion). A number of further features will now be described.

In one example, the distance traversed and the location(s) traversed are determined using location data derived from a positioning system. Typically, the positioning system will be a global satellite system enabling the position of the vehicle and time to be determined to within an accuracy of several metres and nanoseconds respectively. From this, the vehicle distance traversal and location can be derived from known techniques as will be well understood in the art. In one example, the positioning system is the Global Positioning System (GPS) and the on-board processing device includes a GPS receiver. The GPS receiver may be an in-built unit in an in- vehicle processor or alternatively it may be a separate in-built vehicle GPS unit. When GPS is used, the indication of distance traversed and location(s) traversed may be determined using known techniques for deriving such information from GPS data including for instance location information (latitude/longitude measurements), time and Doppler shift.

In one example, the in-vehicle processing device receives the surcharge information from a central server via a communications network. The surcharge information may be determined from a database or the like which stores information relating to associated access surcharges depending on a time, date and vehicle type that the vehicle traverses the pre-defined locations. Thus, appropriate surcharge information for a particular vehicle type is provided to the in-vehicle processing device, as in some instances, the in-vehicle processing device would provide an indication to the central server with regard to the vehicle type that the in- vehicle processing device is integrated within. In this example, the in-vehicle processing device would then determine the traversed distance and traversed location(s) to determine the vehicular road usage surcharge quantum. Alternatively, the central server determines the vehicular road usage surcharge quantum. The road network information may be at least partially indicative of at least one road network map. In this regard, the in-vehicle processing device typically retrieves a road network map from the central server and then compares the latitude and longitude coordinates with a corresponding point on the map to determine the traversed distance and location(s) of the vehicle with respect to the road network. Having determined this distance and location (for example a street, road, area or position along a route), the corresponding vehicular road usage surcharge can be determined.

An example of a system for managing vehicular road usage will now be described with reference to Figure 2. In this example, the system 200 includes an in-vehicle processing device 210, a user device 220 running a third party application and a payment application/payment component such as a digital payment wallet, a communications network 250, a central server 230 in communication with a database 231, and a payment processing system 240. The communications network 250 can be of any appropriate form, such as the Internet and/or a number of local area networks (LANs) for providing connectivity between the central server 230, user device 220, payment processing device 240 and optionally the in-vehicle processing device 210. It will be appreciated that this network configuration is for the purpose of example only, and in practice the various devices can communicate via any appropriate mechanism, such as via wired or wireless connections, including, but not limited to mobile networks, private networks, such as an 802.11 network, the Internet, LANs, WANs, or the like, as well as via direct or point-to-point connections, such as Bluetooth, or the like.

In one example, the central server 230 includes one or more processing systems, each of which may be coupled to one or more databases 231. The central server 230 is adapted to be used in receiving requests from and responding to the user device 220 and the in-vehicle processing device 210. The user device 220 and the in-vehicle processing device 210 are typically adapted to communicate with the central server 230, allowing requests to be made and responses to be received. The central server 230 may also be adapted to implement payment services, or be connected to a payment processing system 240, such as servers of financial institutions, payment gateways or the like, as will be appreciated by persons skilled in the art.

Whilst the central server 230 is a shown as a single apparatus, it will be appreciated that the merchant processing system can be distributed over a number of geographically separate locations, for example by using processing systems and/or databases 231 that are provided as part of a cloud based environment. However, the above described arrangement is not essential and other suitable configurations could be used.

User Device 220 The user device 220 of any of the examples herein may be a handheld computer device such as a smart phone or a PDA such as one manufactured by Apple™, LG™, HTC™, BlackBerry™, or Motorola™. The user device 220 may include a mobile computer such as a tablet computer or a wearable mobile processing device such as a smart watch. An exemplary embodiment of a user/merchant device 300 is shown in Figure 3. As shown, the device 300 includes the following components in electronic communication via a bus 306:

1. a display 302;

2. non- volatile memory 303;

3. random access memory ("RAM") 304; 4. N processing components 301;

5. a transceiver component 305 that includes N transceivers; and

6. user controls 307.

Although the components depicted in Figure 3 represent physical components, Figure 3 is not intended to be a hardware diagram; thus many of the components depicted in Figure 3 may be realized by common constructs or distributed among additional physical components. Moreover, it is certainly contemplated that other existing and yet-to-be developed physical components and architectures may be utilized to implement the functional components described with reference to Figure 3.

The display 302 generally operates to provide a presentation of content to a user, and may be realized by any of a variety of displays (e.g., CRT, LCD, HDMI, micro-projector and OLED displays). And in general, the non-volatile memory 303 functions to store (e.g., persistently store) data and executable code including code that is associated with the functional components of a browser component and applications, and in one example, a payment application 308 and third party application 309 executing on the user device 220. In one example, the third party application 309 can be provided by the entity managing vehicular infrastructure. In some embodiments, for example, the non-volatile memory 303 includes bootloader code, modem software, operating system code, file system code, and code to facilitate the implementation of one or more portions of the applications 308, 309 as well as other components well known to those of ordinary skill in the art that are not depicted for simplicity. In many implementations, the non-volatile memory 303 is realized by flash memory (e.g., NAND or ONENAND memory), but it is certainly contemplated that other memory types may be utilized as well. Although it may be possible to execute the code from the nonvolatile memory 303, the executable code in the non-volatile memory 303 is typically loaded into RAM 304 and executed by one or more of the N processing components 301. The N processing components 301 in connection with RAM 304 generally operate to execute the instructions stored in non-volatile memory 303 to effectuate the functional components. As one of ordinarily skill in the art will appreciate, the N processing components 301 may include a video processor, modem processor, DSP, graphics processing unit (GPU), and other processing components. The transceiver component 305 includes N transceiver chains, which may be used for communicating with external devices via wireless networks. Each of the N transceiver chains may represent a transceiver associated with a particular communication scheme. For example, each transceiver may correspond to protocols that are specific to local area networks, cellular networks (e.g., a CDMA network, a GPRS network, a UMTS network), and other types of communication networks.

In-Vehicle Processing Device 210

A suitable in-vehicle processing device 210 for use in the system for managing vehicular road usage described in any one of the above examples is shown in Figure 4.

In this example, the in-vehicle processing device 210 includes at least one microprocessor 400, a memory 401, an optional input/output device 402, such as a display, keyboard, touchscreen and the like, and an external interface 403, interconnected via a bus 404 as shown. In this example the external interface 403 can be utilised by the in-vehicle processing device 210 when communicating with peripheral devices, such as the user device 220, communications networks 250, the central server 230, the payment processing system 240, databases, other storage devices, or the like. Although only a single interface 403 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless, Bluetooth™ Low Energy (BLE), Near Field Communication (NFC), or the like) may be provided.

In use, the microprocessor 400 executes instructions in the form of applications software stored in the memory 401 to allow communication with the user device 220, and the central server 230. The applications software may include one or more software modules, and may be executed in a suitable execution environment, such as an operating system environment, or the like.

Accordingly, it will be appreciated that the in-vehicle processing device 210 may be formed from any suitable processing system, such as any electronic processing device, including a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement. Thus, in one example, the processing system 210 is a standard processing system such as an Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g., hard disk) storage, although this is not essential. Typically, the in-vehicle processing device 210 forms part of a computer system built-in or otherwise integrated with the vehicle and may optionally also include a positioning receiver 405 for determining a distance traversed and location(s) of the vehicle. The vehicle processing device 210 may also be pre-loaded with road network maps for use in determining the location of the vehicle and distance traversed with respect to the road network. In addition, the in-vehicle processing device 210 can be loaded with information regarding vehicle type that the in-vehicle processing device 210 is installed in so that the in-vehicle processing device 210 is able to provide information on vehicle type when necessary.

Central Server 230 A central server 230 for use in the system 200 described in any one of the above examples is shown in Figure 5. The central server 230 can be administered by the entity administering the vehicular infrastructure.

In this example, the central server 230 includes at least one microprocessor 500, a memory 501, an optional input/output device 502, such as a display, keyboard, touchscreen and the like, and an external interface 503, interconnected via a bus 504 as shown. In this example the external interface 503 can be utilised by the central server 230 when communicating with peripheral devices, such as the user device 220, communications networks, the payment processing system 240, the in-vehicle processing device 210, databases, other storage devices, or the like. Although only a single interface 503 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless, Bluetooth™ Low Energy (BLE), Near Field Communication (NFC), or the like) may be provided.

In use, the microprocessor 500 executes instructions in the form of applications software stored in the memory 501 to allow communication with the in-vehicle processing device 210, for example to receive vehicular road usage surcharge indication and to provide road network information including vehicular road usage surcharge information, and the payment processing system 240, for example to cause the vehicular road usage surcharge to be paid from the user account. The applications software may include one or more software modules, and may be executed in a suitable execution environment, such as an operating system environment, or the like.

Accordingly, it will be appreciated that the central server 230 may be formed from any suitable processing system, such as any electronic processing device, including a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement. However, the central server 230 may also be formed from a suitably programmed PC, Internet terminal, lap-top, or hand-held PC, a tablet, or smart phone, or the like. Thus, in one example, the central server 230 is a standard processing system such as an Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g., hard disk) storage, although this is not essential.

Payment processing system 240

A suitable payment processing system 240 for use in the system described in any of the above examples is shown in Figure 6.

In this example, the payment processing system 240 is a server (though in practice, the system 240 will comprise multiple such servers) that includes at least one microprocessor 800, a memory 801, an optional input/output device 802, such as a display, keyboard, touchscreen and the like, and an external interface 803, interconnected via a bus 804 as shown. In this example the external interface 803 can be utilised for connecting the payment processing system 240 to peripheral devices in the system 200, such as the central server 230, the communication networks 900, storage devices, or the like. Although a single external interface 803 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless or the like) may be provided.

In use, the microprocessor 800 executes instructions in the form of applications software stored in the memory 801 to allow communication with the payment processing system 240, for example to process payment required at the payment processing system 240. The applications software may include one or more software modules, and may be executed in a suitable execution environment, such as an operating system environment, or the like.

Accordingly, it will be appreciated that the payment processing system 240 may be formed from any suitable processing system, such as any electronic processing device, including a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement. Thus, in one example, the processing system is a standard processing system such as an Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g., hard disk) storage, although this is not essential. In other examples, such as described above, the payment processing system 240 is formed of multiple computer systems interacting, for example, via a distributed network arrangement. As distributed networking is known in the art, it will not be described further in more detail.

In particular, the payment processing system 240 may include or be in communication with a number of processing systems associated with each of an issuer, acquirer, card network and payment gateway, or alternatively, the payment system may be any one or more of these entities.

In one example, the payment processing system 240 sends the user account information and payment information to the third party's acquirer. The acquirer then requests that the card network get an authorization from the user's issuing bank. The card network submits the transaction to the issuer for authorization and the issuing bank then authorizes the transaction if the account has sufficient funds to cover the amount payable. The issuer then routes payment to the acquirer (in subsequent settlement and clearance processes as known in the art) who then deposits the payment into the third party's account.

An example of a method for managing vehicular road usage will now be described in more detail with reference to Figures 7 A to 7B.

In this example, at step 595 the user enters their vehicle and starts the ignition. This provides power to the in-vehicle processing device 210. At step 600, the in-vehicle processing device 210 receives surcharge information from the central server 230 via a communications network. In some instances, the surcharge information is in accordance with vehicle type and can be periodically received whenever there are changes to the surcharge information, or received at pre-defined time intervals.

As the user begins to drive, at step 605, the location of the vehicle with respect to the road network is then determined by the in-vehicle processing device 210 by comparing location coordinates with the road network map obtained from the central server 230.

At step 610, journey parameters of the vehicle is determined using the positioning receiver of the in-vehicle processing device 210. In other examples, as previously mentioned, the journey parameters could be derived from a separate in-built vehicle positioning receiver and provided to the in- vehicle processing device 210. The journey parameters is then used to determine the distance traversed by the vehicle, and the location(s) of the vehicle at step 615 using known techniques familiar to persons skilled in the art. At step 620, the journey parameters are processed at the in-vehicle processing device 210 to determine the vehicular road usage surcharge. The vehicular road usage surcharge is determined from surcharge information provided by the central server 230, whereby the surcharge information is dependent on vehicle type. Payment information indicative of the vehicular road usage surcharge and the in-vehicle processing device 210 ID is then prepared for transmission to the central server 230.

The central server 230 then retrieves the payment information and user account information from the in-vehicle processing device 210 at step 625. The user account information may be indicative of a user's bank account or payment card nominated for use by the user. Typically, the account information is stored in a digital payment wallet, the payment wallet configured to provide the account information to the central server 230 either directly or more typically via a third party application running on the user device 220.

At step 630, the payment information and the user account information are then transmitted from the central server 230 to the payment processing system 240. The payment processing system 240 then determines if the user account information is paired with the in-vehicle processing device 210 at step 635. If yes, the vehicular road usage surcharge is paid from the user account at step 640. Typically this is achieved via communication between the central server 230 and the payment processing system 240. The payment is processed in any suitable manner via request and response messages, for example in a four-party (open) scheme between the central server 230, an acquirer system, card network, issuer system and optionally a payment service provider such as payment gateway; or in a three-party (closed) scheme between the central server 230, a payment network (acting as both issuer and acquirer) and typically, a payment gateway.

Typically, the digital payment wallet generates payment data which is transmitted to the payment processing system. The payment data comprises, for example, the amount of the payment, a tokenized version of a primary account number (PAN) of a desired payment instrument, an expiry date of the payment instrument, and other information required to generate an authorization request for a transaction (for example, formatted according to the IS08583 standard). The authorization request comprises the PAN or token, as well as encrypted transaction details which may be in the form of an EMV cryptogram, sometimes known as an authorization request cryptogram or ARQC. The ARQC is generated according to the EMV specification, or according to an implementation thereof, such as M/Chip Advance of Mastercard International Incorporated.

The central server then submits an authorization request to, for example, a payment service provider (PSP) or the acquirer, the authorization request comprising the PAN, or the token, and the cryptogram. The acquirer or PSP then routes the authorization request, based on the PAN/token, to the payment processing system and the payment processing system then identifies, based on the PAN or token, the issuer to which the request should be routed. In the case of a tokenized transaction, prior to sending the authorization request to a transaction processing system of the issuer (the issuer processor), the token is mapped back to the PAN with which it is associated by sending a request to a token service provider (TSP) such as Mastercard Digital Enablement Service (MDES).

Once received by the issuer processor, the ARQC is validated against a corresponding ARQC generated by the issuer (in known fashion according to the EMV standard or an implementation thereof, such as M/Chip of Mastercard International Incorporated). On successful validation, an authorization response comprising data indicating success or otherwise of the transaction request, and an authorization response cryptogram (ARPC), is generated by the issuer and sent back to the acquirer via the payment network (with the PAN being re-mapped to the token by the TSP, as appropriate, prior to being transmitted to the acquirer). The authorization response is then transmitted to the central server, and the ARPC is transmitted to the digital payment wallet, where it is validated against a corresponding ARPC generated by the digital payment wallet. Success, or otherwise, of the validation is transmitted from the digital payment wallet back to the central server, which confirms completion of the authorization request. In some instances, if the user account information is determined to be not paired with the in- vehicle processing device 210, a notification will need to be provided to the entity administering to vehicular infrastructure to seek payment for the vehicular road usage surcharge by alternative ways at step 645. Typically, at step 650 the in-vehicle processing device 210 is then notified of successful payment of the vehicular road usage surcharge and correspondingly, at step 655, the user is provided with a representation of the notification as generated by the in-vehicle processing device 210.

An example of a process for account setup with the third party before the system is used will now be described in more detail with reference to Figure 7.

In this example, at step 900, the user downloads the third party application to their user device, such as a smartphone. The third party application is by the entity administering to vehicular infrastructure and the application can be for paying vehicular road usage surcharges. At step 910, the user creates a new account with the administrative entity for example providing their name, address, vehicle registration and bank account or payment card details. Typically, the bank or payment card details are provided by associating or linking a digital payment wallet with or to the user account at step 920. Any suitable digital payment wallet may be used including for example Google Wallet™, Apple Pay™, Masterpass™ and the like.

At step 930, the third party application then provides a consent notification to the user requesting that the user provide their consent to participate in the automatic payment scheme for payment of vehicular road usage surcharges. At step 940, the user provides input to the merchant application indicative of their consent to making automatic payment for vehicular road usage surcharges.

As a one-time activity, the user then pairs their user device 220 with the in-vehicle processing device 210 at step 950. This is a manual pairing whereby the user's device 220 picks up a csignal emitted by the in-vehicle processing device 210 and the user selects to pair with the vehicle processing device 210.

At step 960, the user authenticates their payment instrument (i.e. payment card or bank account details) with the payment processing system 240 via the third party application which is in communication with the central server 230. Authentication with the issuer is performed in a conventional manner and involves the user authenticating that the payment instrument belongs to them and providing permission for the payment instrument to be charged by the central server.

The in-vehicle processing device 210 is then updated and provided with the payment instrument validation at step 970 so that future payments can be processed automatically without further input or authentication from the user being required. The user's account with the entity administering the vehicular infrastructure is now setup and ready for use.

Referring now to Figure 9, there is shown a specific implementation of a method of account setup in preparation for the method of Figure 10 to operate in a desired manner. Furthermore, referring to Figure 10, there is shown a specific implementation of a method for managing vehicular road usage, whereby in use, the in-vehicle processing device (also known as an onboard unit or OBU) is able to detect journey parameters and determine vehicular road usage surcharges. Consequently, payment is made automatically for the vehicular road usage surcharges from a user's pre-authenticated digital wallet. Accordingly, it will be appreciated that at least in one example, the above described system and method provides a number of advantages. By moving the knowledge of vehicular road usage surcharges to the end-user (i.e. the driver), the end-user receives clear visibility of payable costs regarding vehicular road usage, and correspondingly, the end-user may be inclined to minimise unnecessary vehicular use in order to minimise costs. This can also lead to reduction of pollution emitted by vehicles. Furthermore, substantial cost savings can also be made by the entity which manages vehicular infrastructure. For example, the entity will no longer be required to purchase, install, maintain or monitor equipment and administrative processes designed to administer to levying vehicular road usage surcharges. Moreover, from an administrative perspective, as the vehicular road usage surcharge is deducted automatically from the user's account, there would be additional savings in no longer having to administer fines for non-payment or late payment of the road usage surcharge to users and to subsequently chase up on whether the fines have been paid. In addition to monetary benefit, there would also be a human resources benefit as the entity staff can be reallocated to perform other tasks.

From a user's perspective, they would be incentivised to use the system because of the convenience of payment for vehicular road usage surcharges being carried out on their behalf with little effort being expended on their part (primarily during a setting up portion, which will be described in greater detail at a later portion).

Throughout this specification and claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated integer or group of integers or steps but not the exclusion of any other integer or group of integers.

Persons skilled in the art will appreciate that numerous variations and modifications will become apparent. All such variations and modifications which become apparent to persons skilled in the art, should be considered to fall within the spirit and scope that the invention broadly appearing before described.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1. A system for managing vehicular road usage, the system including one or more electronic processing devices configured to:

determine, at an in-vehicle processing device, journey parameters indicative of a distance and at least one location traversed by a vehicle;

determine, at the in-vehicle processing device, payment information indicative of a payment amount representing a vehicular road usage surcharge in accordance with the journey parameters;

transmit, to a central server, the payment information;

determine, at a payment processing system, a pairing of user account information with the in-vehicle processing device; and

use, at the payment processing system, the user account information to thereby cause the vehicular road usage surcharge to be paid from a digital wallet account associated with the user account information.

2. The system of claim 1, wherein the journey parameters are partially determined using data obtained from a positioning system.

3. The system of claim 2, wherein the in-vehicle processing device includes a positioning receiver configured for use in the positioning system.

4. The system of any of claims 1 to 3, further including one or more electronic processing devices configured to:

receive, from the central server, surcharge information for determining the vehicle road usage surcharge via a communications network.

5. The system of any of claims 1 to 4, further including one or more electronic processing devices configured to:

receive, at the central server, the user account information; and

transmit, to the payment processing system, the user account information.

6. The system of any of claims 1 to 5, further including one or more electronic processing devices configured to:

receive, at the in-vehicle processing device, a notification that the vehicular road usage surcharge has been paid; and

generate, at the in-vehicle processing device, a representation of the notification.

7. The system of any of claims 1 to 6, wherein the user account is pre-authenticated with the payment processing system so that the central server is able to cause the vehicular road usage surcharge to be paid from the digital wallet account without further authentication.

8. The system of any of claims 1 to 7, further including one or more electronic processing devices configured to:

associate, using a user device, the in-vehicle processing device with the user account information.

9. The system of any of claims 1 to 8, wherein the vehicular road usage surcharge is dependent on vehicle type.

10. A method for managing vehicular road usage, the method including, in one or more electronic processing devices:

determining, at an in-vehicle processing device, journey parameters indicative of a distance and at least one location traversed by a vehicle;

determining, at the in-vehicle processing device, payment information indicative of a payment amount representing a vehicular road usage surcharge in accordance with the journey parameters;

transmitting, to a central server, the payment information;

determining, at a payment processing system, a pairing of user account information with the in-vehicle processing device; and

using, at the payment processing system, the user account information to thereby cause the vehicular road usage surcharge to be paid from a digital wallet account associated with the user account information.

11. The method of claim 10, further including, in one or more electronic processing devices:

receiving, from the central server, surcharge information for determining the vehicular road usage surcharge via a communications network.

12. The method of either claim 10 or 11, further including, in one or more electronic processing devices:

receiving, at the central server, the user account information; and

transmitting, to the payment processing system, the user account information.

13. The method of any of claims 10 to 12, further including, in one or more electronic processing devices:

receiving, at the in-vehicle processing device, a notification that the vehicular road usage surcharge has been paid; and

generating, at the in-vehicle processing device, a representation of the notification.

14. The method of any of claims 10 to 13, wherein the user account is pre-authenticated with the payment processing system so that the central server is able to cause the vehicular road usage surcharge to be paid from the digital wallet account without further authentication.

15. The method of any of claims 10 to 14, further including, in one or more electronic processing devices:

associating, using a user device, the in-vehicle processing device with the user account information.

16. The method of any of claims 10 to 15, wherein the vehicular road usage surcharge is dependent on vehicle type.

17. An in-vehicle processing device for managing vehicular road usage, the device including one or more electronic processing devices configured to:

determine journey parameters indicative of a distance and at least one location traversed by a vehicle;

determine payment information indicative of a payment amount representing a vehicular road usage surcharge in accordance with the journey parameters; and

transmit, to a central server, the payment information.

18. The device of claim 17, wherein the journey parameters are determined partially using data obtained from a positioning system.

19. The device of either claim 17 or 18, further including one or more electronic processing devices configured to:

receive, from the central server, surcharge information for determining the vehicular road usage surcharge via a communications network.

20. The device of any of claims 17 to 19, further including one or more electronic processing devices configured to:

receive a notification that the vehicular road usage surcharge has been paid; and generate a representation of the notification.

21. The device of any of claims 17 to 20, wherein the vehicular road usage surcharge is dependent on vehicle type.

22. A non-transitory computer readable storage medium embodying thereon a program of computer readable instructions which, when executed by one or more processors of an in- vehicle device in communication with a central server, cause the in-vehicle device to perform a method for managing vehicular road usage, the method being embodied in the steps of: determining journey parameters indicative of a distance and at least one location traversed by a vehicle; determining payment information indicative of a payment amount representing a vehicular road usage surcharge in accordance with the journey parameters; and

transmitting, to a central server, the payment information.

23. The storage medium of claim 22, wherein the journey parameters are determined partially using data obtained from a positioning system.

24. The storage medium of either claim 22 or 23, the method further embodied in the steps of:

25. The storage medium of any of claims 22 to 24, the method further embodied in the steps of:

receiving a notification that the vehicular road usage surcharge has been paid; and generating a representation of the notification.

26. The storage medium of any of claims 22 to 25, wherein the vehicular road usage surcharge is dependent on vehicle type.