WO2018203827A1 - Système et procédé de gestion d'utilisation de route de circulation - Google Patents

Système et procédé de gestion d'utilisation de route de circulation Download PDF

Info

Publication number
WO2018203827A1
WO2018203827A1 PCT/SG2018/050202 SG2018050202W WO2018203827A1 WO 2018203827 A1 WO2018203827 A1 WO 2018203827A1 SG 2018050202 W SG2018050202 W SG 2018050202W WO 2018203827 A1 WO2018203827 A1 WO 2018203827A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
payment
road usage
surcharge
vehicular road
Prior art date
Application number
PCT/SG2018/050202
Other languages
English (en)
Inventor
Syam Sasidharan Nair
Shubhrendu KHOCHE
Chee Leong Liew
Original Assignee
Mastercard Asia/Pacific Pte. Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mastercard Asia/Pacific Pte. Ltd. filed Critical Mastercard Asia/Pacific Pte. Ltd.
Publication of WO2018203827A1 publication Critical patent/WO2018203827A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G06Q20/145—Payments according to the detected use or quantity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/06—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems
    • G07B15/063—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems using wireless information transmission between the vehicle and a fixed station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/0042—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for hiring of objects
    • G07F17/0057—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for hiring of objects for the hiring or rent of vehicles, e.g. cars, bicycles or wheelchairs

Definitions

  • the present invention relates to a system and method for managing vehicular road usage.
  • tolls 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.
  • London which has implemented a congestion charge
  • Singapore which has implemented a system called electronic road pricing, or ERP
  • the electronic road pricing system relies on use of static gantries to levy the surcharges as vehicles pass under the gantries.
  • 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.
  • the locations of the gantries are fixed and the boundaries for levying surcharges must therefore be static as a consequence.
  • a system for managing vehicular road usage 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.
  • a method for managing vehicular road usage 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.
  • 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.
  • 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.
  • 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.
  • Figure 10 is a specific implementation of a method for managing vehicular road usage. Detailed Description
  • FIG. 1 An example of a method for managing vehicular road usage will now be described with reference to Figure 1.
  • 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.
  • a payment system 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.
  • 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.
  • the central server is administered by an entity which manages vehicular infrastructure, and can be a government agency or the like.
  • 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.
  • 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).
  • GPS Global Positioning System
  • GLONASS Global Positioning System
  • 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.
  • 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.
  • 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.
  • the central server will retrieve the account information from the user device, for example from the digital payment wallet.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • PAN primary account number
  • 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.
  • PSP payment service provider
  • 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.
  • the token 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).
  • TSP token service provider
  • MDES Mastercard Digital Enablement Service
  • 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).
  • an authorization response comprising data indicating success or otherwise of the transaction request, and an authorization response cryptogram (ARPC)
  • ARPC authorization response cryptogram
  • 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.
  • 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.
  • 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.
  • 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.
  • the end-user 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.
  • the distance traversed and the location(s) traversed are determined using location data derived from a positioning system.
  • 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.
  • the positioning system is the Global Positioning System (GPS) and the on-board processing device includes a GPS receiver.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • LANs local area networks
  • 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.
  • 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.
  • central server 230 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.
  • 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 AppleTM, LGTM, HTCTM, BlackBerryTM, or MotorolaTM.
  • 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:
  • non- volatile memory 303
  • RAM random access memory
  • N processing components 301
  • transceiver component 305 that includes N transceivers.
  • Figure 3 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).
  • 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.
  • the third party application 309 can be provided by the entity managing vehicular infrastructure.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • a suitable payment processing system 240 for use in the system described in any of the above examples is shown in Figure 6.
  • 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.
  • 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.
  • peripheral devices in the system 200 such as the central server 230, the communication networks 900, storage devices, or the like.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the payment processing system 240 sends the user account information and payment information to the third party's acquirer.
  • the acquirer 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.
  • the user enters their vehicle and starts the ignition. This provides power to the in-vehicle processing device 210.
  • the in-vehicle processing device 210 receives surcharge information from the central server 230 via a communications network.
  • 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.
  • 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.
  • journey parameters of the vehicle is determined using the positioning receiver of the in-vehicle processing device 210.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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
  • a payment gateway typically, a payment gateway.
  • 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.
  • PSP payment service provider
  • 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.
  • the token 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).
  • TSP token service provider
  • MDES Mastercard Digital Enablement Service
  • 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).
  • an authorization response comprising data indicating success or otherwise of the transaction request, and an authorization response cryptogram (ARPC)
  • ARPC authorization response cryptogram
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 WalletTM, Apple PayTM, MasterpassTM and the like.
  • 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.
  • the user provides input to the merchant application indicative of their consent to making automatic payment for vehicular road usage surcharges.
  • 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.
  • 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.
  • FIG. 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.
  • the in-vehicle processing device also known as an onboard unit or OBU
  • OBU onboard unit
  • 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.
  • 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.
  • 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.
  • there would also be a human resources benefit as the entity staff can be reallocated to perform other tasks.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un système et un procédé de gestion d'utilisation de route de circulation, la distance parcourue par un véhicule et sa position étant déterminées par une unité de traitement embarquée. Une surcharge d'utilisation de route de circulation est déterminée par l'unité de traitement embarquée. Des informations de paiement sont envoyées à un serveur central. Le paiement ultérieur de la surcharge est effectué par un système de traitement de paiement à l'aide d'un compte de portefeuille numérique associé à un utilisateur du véhicule. L'utilisateur peut décider de modifier des habitudes d'utilisation/parcours de route en fonction d'une fréquence et/ou d'un quantum de paiements effectués par l'intermédiaire du portefeuille numérique. De ce fait, le volume de véhicules est également affecté.
PCT/SG2018/050202 2017-05-02 2018-04-26 Système et procédé de gestion d'utilisation de route de circulation WO2018203827A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SG10201703583Y 2017-05-02
SG10201703583YA SG10201703583YA (en) 2017-05-02 2017-05-02 System and method for managing vehicular road usage

Publications (1)

Publication Number Publication Date
WO2018203827A1 true WO2018203827A1 (fr) 2018-11-08

Family

ID=64014502

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2018/050202 WO2018203827A1 (fr) 2017-05-02 2018-04-26 Système et procédé de gestion d'utilisation de route de circulation

Country Status (2)

Country Link
SG (1) SG10201703583YA (fr)
WO (1) WO2018203827A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112950798A (zh) * 2021-02-01 2021-06-11 一汽解放汽车有限公司 一种不停车收费系统及设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999033027A1 (fr) * 1997-12-22 1999-07-01 Combitech Traffic Systems Ab Procede pour debiter automatiquement des frais de peage relatifs a des vehicules
US20020095507A1 (en) * 2001-01-17 2002-07-18 Jerdonek Robert A. Methods for pre-authentication of users using one-time passwords
CN1380630A (zh) * 2002-04-25 2002-11-20 深圳市深港产学研数码科技有限公司 不停车收费方法和系统
US6715082B1 (en) * 1999-01-14 2004-03-30 Cisco Technology, Inc. Security server token caching
US20150088738A1 (en) * 2013-09-24 2015-03-26 Mastercard International Incorporated Transaction Systems, and Related Methods
US20150220916A1 (en) * 2013-08-01 2015-08-06 Intel Corporation Techniques for an in-vehicle electronic wallet

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999033027A1 (fr) * 1997-12-22 1999-07-01 Combitech Traffic Systems Ab Procede pour debiter automatiquement des frais de peage relatifs a des vehicules
US6715082B1 (en) * 1999-01-14 2004-03-30 Cisco Technology, Inc. Security server token caching
US20020095507A1 (en) * 2001-01-17 2002-07-18 Jerdonek Robert A. Methods for pre-authentication of users using one-time passwords
CN1380630A (zh) * 2002-04-25 2002-11-20 深圳市深港产学研数码科技有限公司 不停车收费方法和系统
US20150220916A1 (en) * 2013-08-01 2015-08-06 Intel Corporation Techniques for an in-vehicle electronic wallet
US20150088738A1 (en) * 2013-09-24 2015-03-26 Mastercard International Incorporated Transaction Systems, and Related Methods

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112950798A (zh) * 2021-02-01 2021-06-11 一汽解放汽车有限公司 一种不停车收费系统及设备

Also Published As

Publication number Publication date
SG10201703583YA (en) 2018-12-28

Similar Documents

Publication Publication Date Title
US11651438B2 (en) Risk unit based policies
US11468714B1 (en) Toll payment equipment
JP2022133432A (ja) リスクユニットベースのポリシー
US10810675B2 (en) Providing transit alternatives based on monitored vehicle characteristics
US11645721B1 (en) Usage-based policies
TWI643142B (zh) 用於自助服務付款之設備及方法
US10812457B1 (en) Cryptographically protecting data transferred between spatially distributed computing devices using an intermediary database
US20150199664A1 (en) Methods, systems, and computer readable media for facilitating access to transportation services
WO2018203827A1 (fr) Système et procédé de gestion d'utilisation de route de circulation
KR102034298B1 (ko) 하이패스 결제 시스템 및 그 방법
US20200160315A1 (en) Autonomous vehicle smart parking ticket
AU2016340046A1 (en) Automatic detection of a toll for a vehicle
US10740859B2 (en) Method and system for on-board detection of speeding of a vehicle and payment of an associated fine
JP2020035255A (ja) 管理サーバ、プログラム
US11908247B2 (en) Systems and methods for collecting tolls along a toll road
US20230196340A1 (en) Methods and systems for facilitating collection of road user charges using a digital currency based on a distributed ledger technology
JP6518816B1 (ja) 車両リースと自動車教習所サービスの同時提供に関する情報処理装置及び情報処理方法
CN113470200A (zh) 结算系统、终端装置以及记录介质
JP2019220005A (ja) 車両販売と自動車教習所サービスの同時提供に関する情報処理装置及び情報処理方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18795101

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18795101

Country of ref document: EP

Kind code of ref document: A1