Patent Application
20070252678
The present invention relates to automatic toll systems, and more precisely to a method, apparatuses and a system for processing the debiting of a toll for a vehicle.
Currently, automatic toll systems for vehicles, also known as “tele-toll systems”, are becoming widely used as they provide advantages for the users, who does not need to stop their vehicles to manually pay a toll, as well as advantages for toll operators, which can benefit from a reliable toll control and toll debiting technique.
A tele-toll system usually comprises a plurality of reading stations and one or more toll control servers performing toll control and toll debiting functions, and its operation involves an automatic identification of a vehicle traveling through a toll road and the ascription of the debit of the corresponding toll fee to an associated payment account.
In short, reading stations collect toll events by reading toll identifiers from vehicles that pass by their respective reading area, which are further processed by toll control servers. The toll identifier obtainable from a vehicle can vary depending on the technology used by the reading stations of a tele-toll system. For example, it can comprise an alphanumeric sequence of characters obtainable from the license plate of a vehicle, or comprise a code obtainable from another kind of support carried by the vehicle. Short-range radio frequency is a technology commonly used in reading stations to read a toll identifier from a vehicle, although other technologies, such as image capturing followed by optical character recognition, can be utilized in replacement or in addition to it. For this purpose, vehicles that use a tele-toll system usually carry an on board equipment (OBE) that comprises a radio transponder arranged to receive an interrogation signal from a reading station and to transmit a response a signal that conveys the toll identifier of the vehicle.
A user who wants to benefit from the tele-toll payment feature provided by a tele-toll operator installs on his vehicle an OBE arranged to emit a particular toll identifier, and signs an agreement that grants the ascription of debits of toll events comprising said toll identifier to a payment account (usually, a bank account of the user).
The toll events reported from a reading station are processed by a toll control server. Primarily, a toll control server may perform a validity check for the obtained toll identifier, for example, to determine whether the obtained toll identifier is valid (e.g. it has been previously provisioned as a valid toll identifier by the tele-toll operator, it has associated a valid payment account, etc). Accordingly, a further action may be taken based on an unsuccessful result of said check, such as: block the pass of the vehicle by means of a barrier, issue a warning signal to request the vehicle to stop, take a picture of the vehicle comprising its license plate, etc. Independently of the result of the aforementioned check, a toll control server may store data of the toll event into a toll event log, which, for a given toll identifier, may contain information about the time and/or locations in which toll events comprising said identifier have taken place.
A further task for a toll control server is to ascribe the debit of the toll events reported by one or more reading stations. This task may be performed by the same toll control server that performs the aforementioned validity check, or by another toll control server specialized in this particular task; being this an implementation option that may depend, for example, on whether on-line or off-line debit processing applies. For example, the balance of a payment account, or the accounting information of toll events to be debited to said account, may be on-line updated at reception from a reading station of a toll event comprising the toll identifier it relates to. Alternatively, toll events collected during a given period of time, may be off-line processed so as to ascribe the debit of the total toll fees for that period to the corresponding payment accounts.
Tele-toll is an advantageous solution for users who drive most of the times the same vehicle and who are frequent users of toll roads. However, the characteristics of current tele-toll solutions may do not suit with some situations, which delays a wider deployment and use of tele-toll systems. For example, a user may be reluctant to sign a tele-toll agreement if he use just occasionally toll roads. Even for a frequent user of toll roads who have installed an OBE on his vehicle, it may be inconvenient to lend his vehicle to other person during a given period since, although said other person may be willing to pay for toll events incurred by the vehicle in said period, it may be difficult, or embarrassing, to determine the amount to be paid. Also, a car rental company might want to install OBEs on its vehicles, so as to offer the advantages of tele-toll payment to its clients as a value-added feature. However, the car rental company might experience some difficulties to collect the toll fees due from a client, since the payment account of said company will likely be debited with the tolls events incurred by said client once he gave back the car and paid the car rental fee.
Therefore, it is an object of the present invention to provide a method and apparatuses for tele-toll payment which alleviates the aforementioned disadvantages.
The aforementioned object is achieved by a method as claimed in claim 1. This object is also achieved by an apparatus as claimed in claim 11 or by a system as claimed in claim 28. Embodiments of the invention are set out in the dependent claims.
In one aspect, the invention relates to a method for processing the debiting of a toll event comprising a toll identifier obtained from a vehicle. In another aspect, the invention relates to a toll control server for controlling the debiting of a toll event comprising a toll identifier obtained from a vehicle. The method and toll control server according to the invention are characterized in that a voucher assertion is stored in relationship with a toll identifier obtainable from a vehicle. When a toll event reported from a reading station and comprising a toll identifier obtained from a vehicle is going to be processed, it is checked whether a voucher assertion exists in relationship with the obtained identifier. If so, the payment of the toll event is ascribed to a second payment account whose existence is asserted by the existence of said voucher assertion. Otherwise, the toll event is ascribed to a first payment account that can be the default one for ascribing the debits of toll events for said identifier.
By controlling the ascription of debits of toll events as described herein, a flexible payment of toll events for a vehicle may be thus be obtained, wherein the same payment account is not necessarily always charged with all the toll events comprising a given toll identifier.
In a simple realization, the voucher assertion may consist on a simple data flag stating the existence of said second payment account, wherein a given second payment account may be related to a plurality of toll identifiers. However, in some cases it may be preferable that a voucher assertion related to a toll identifier further comprises some additional data.
According to various embodiments, the voucher assertion may comprise: a data element stating a time condition, a data element stating a geographical location condition, an identifier of said second payment account, an identifier of a user in a service provider that serves a payment broker service to him, or any combination thereof. The time condition for a voucher assertion may state a period of time in which toll events comprising the toll identifier it relates to are to be ascribed to said second payment account. The geographical location condition for a voucher assertion may state information about one or more geographical locations in which toll events comprising the toll identifier it relates to are to be ascribed to said second payment account. The user identifier in a service provider that acts as payment broker may be usable to identify a payment account of said user in said service provider as said second payment account; wherein, in case said service provider is a telecommunications operator, said user identifier may be usable to identify a communications device of said user connectable to the telecommunications network of said operator.
Accordingly, the existence of a voucher assertion in relationship with a toll identifier does not necessarily imply the ascription of any toll event to said second payment account, but only of those toll events that fits with some requirements which may be set and modified in advance. Further, the voucher assertion may help to identify directly or indirectly said second payment account.
According to one embodiment, the method of the invention comprises a communication between an application server that provides a payment broker service and said toll control server, so as to make said toll control server to store a relationship between a voucher assertion and a toll identifier indicated by said application server in a communication. Therefore, in a further aspect, the invention relates an application server arranged to send to a toll control server a payment authorization request for a toll identifier, said payment authorization request containing a toll identifier obtainable from a vehicle and requesting to ascribe the debit of a toll event that comprises said toll identifier to a second payment account. The method and toll control server of the invention are then further characterized in that any of the following actions is performed at reception of said payment authorization request: a voucher assertion is stored in relationship with a toll identifier indicated in said request, a relationship is established between said toll identifier and a previously stored voucher assertion, or the content of a voucher assertion already stored in relationship with said toll identifier is modified.
According to a further embodiment, a value is set in the time condition data element of a voucher assertion according to the time in which said payment authorization request is received from the application server, wherein said value may determine the start of a period of time in which toll events comprising said toll identifier are to be ascribed to said second payment account. In another embodiment, the content of the data elements that may form the voucher assertion related to a toll identifier may be set and/or modified according to the data content of a received payment authorization request.
According to still a further embodiment, a payment revocation request is sent from an application server to a toll control server requesting to cease the ascription of toll events for a toll identifier to a second payment account; wherein said application server may or may not be the same as the one that might have sent a payment authorization request for said toll identifier. In addition or in replacement of the toll identifier said payment revocation request relates to, a payment revocation request may comprise a data usable to find out the corresponding voucher assertion, and thus, a toll identifier related to it. The reception of a payment revocation request makes the toll control server to, either: remove a voucher assertion stored in relationship with said toll identifier, or break a previously established relationship between said toll identifier and a voucher assertion.
By providing a communication between a toll control server and an application server as described herein, it is possible to dynamically modify or assign the payment account used to ascribe the cost of toll events comprising a given toll identifier, as well as the requirements for ascribing toll events to said account; wherein said modifications may be requested from application server apparatuses of service providers that already holds a payment account for a given user or group of users, or that are entitled to control or authorize the payments to be ascribed to said account.
According to still a further embodiment, the method and application server according to the invention provides a payment broker service to a user that permits said user to send from a communications device a service request for associating a given toll identifier to a given payment account, as said second payment account, or to request the revocation of said association. A service request received from a user may comprise data that can be used by the application server to build up the corresponding payment authorization request or payment revocation request and their respective contents. If the communications device is a mobile communications device, or if the user has a mobile communications device, which is connectable to a telecommunications network of a mobile telecommunications service provider that provides updated geographical location information of mobile communications devices, then, the application server may communicate with a server in said network that provides said kind of information so as to obtain geographical location information of said communications device; thereby, payment authorization requests and/or payment revocation requests may be sent from the application server to one or more toll control servers that control the debiting of toll events for vehicles in a given geographical location, according to the current position of said communications device.
A user may thus request to the application server the ascription of toll events for a given period of time and/or for a given geographical area or areas to a given payment account; wherein toll control servers that control the debiting of toll events for vehicles in the concerned area or areas may be notified from the application server, so as to store or remove a voucher assertion in relationship with a toll identifier of a vehicle driven, occupied or, simply, authorized by said user. Furthermore, a user having a service account with a telecommunications operator may assign through the application server said service account as said second payment account for the payment of toll events for a given toll identifier.
If the user has a mobile communications device connectable to a mobile network, he may be alleviated of having to specify in advance to the application server the geographical area or areas he intends to travel through. If this is the case, the application server may, without requiring further user intervention, periodically obtain the current position of said mobile communications device, so as to send automatically payment authorization requests and/or payment revocation requests to control servers that control the debiting of toll events for vehicles in the concerned area or areas.
Some exemplary embodiments of the invention shall now be described in detail with references to FIGS. 1 to 4.
As described earlier, the basic functional components of a tele-toll system are the reading station and the toll control server. In practical realizations, the system comprises a plurality of reading stations distributed across different geographical locations, each location corresponding to the entry and/or exit point of a toll road. Depending on selected implementation options, the tele-toll system may comprise one or more toll control servers to perform the aforementioned control and/or toll debiting functions. For example, a toll gantry located at the entry or exit point of a toll road may comprise one or more reading stations, wherein the or each reading station of this point is connected to a toll control server assigned to receive toll events of the reader(s) of this toll gantry, or be connected to a centralized toll control server assigned to receive toll events from reading stations situated in a plurality of different geographical locations. Also, depending on construction details, the same machine may comprise one or more readers arranged to obtain toll identifiers from vehicles, and a processor to perform toll control and/or toll debiting functions (e.g. a computer-based machine with the readers connected as peripheral devices).
For the sake of a better explanation of the invention, the tele-toll system shown schematically in
The vehicle V1 mounts an on board equipment (OBE) which comprise a short-range radio transmitter (not detailed in
To perform its functions, the toll control server comprises three functional modules: a communications module (101), a storage module (103), and a processing module (102). The communications module (101) may comprise one or more communication devices (not detailed in
It shall be noticed that for a given toll identifier (T-ID) that may be known by the toll control server, the default (first) payment account may have a value that implies that no user has subscribed yet an agreement to get assigned said toll identifier; therefore, since the payment of any toll event comprising said toll identifier should, in that situation, be assumed by a tele-toll operator, said value may be understood as representing directly or indirectly a payment account of the tele-toll operator as said first payment account.
In a simple embodiment, a voucher assertion (1032) may consist on a simple data flag stating the existence of said alternative payment account. For example, a tele-toll operator may have an agreement with a service provider providing a payment broker service (e.g. a bank, a credit card payment broker, telecommunications operator, etc), which implies the ascription of some toll debits to a generic account afforded by said service provider; wherein said flag in relationship with a toll identifier would imply toll events of said toll identifier to be ascribed to said generic account (as said second payment account). However, the voucher assertion may comprise further data that may be used, not only to assert the existence of a second payment account, but also to identify it, and/or to identify the user to whom said second payment account belongs to, and/or to state certain conditions for toll events to be ascribed to said second payment account.
The particular embodiment illustrated in
The steps performed by a control server (100) at reception of a toll event (405) reported by a reading station (10,11,12) are represented in
In step 211, the processing module (102) verifies whether the toll identifier comprised in the received toll event (405) is stored in the storage module (103). If no match is found, then the toll event may be considered as faulty and a further action may be ordered in step 212 (e.g.: ordering to lower a barrier to block the pass of the vehicle, order to emit a warning signal to request the vehicle to stop, order to take a picture of the vehicle comprising its license plate, etc). Step 212 may also comprise the storage of the faulty toll event in a faulty toll event log. If a match is found in step 211, then the process may continue with the ascription of the due debit for said toll event in two different ways: off-line or on-line processing, as described earlier.
If off-line processing is implemented, then, in step 213 the processing module (102) stores in the storage module (103) the relevant data of the received toll event. Although not shown in
Next steps in the off-line processing flow may take place periodically, wherein step 218 represents the start of the (off-line) processing for the debiting of toll events that have been recorded previously (steps 213). To accomplish with this, the processing module (102) may access to the storage module (103) so as to collect a set of stored entries in the toll event register. Then, the processing a pre-recorded toll event may be executed as for on-line processing, as indicated by the transition flow “A”. In step 214 the processing module (102) checks in the storage module (103) whether a voucher assertion (1032) is stored in relationship with the toll identifier of the processed toll event. If a voucher assertion (1032) is found, then in step 215, the processing module (102) checks whether the toll event meets the condition(s) stated in the related voucher assertion. If any of the conditions checked in step 215 is not meet, or if no voucher assertion is found related to the concerned toll identifier, then the debit of the processed toll event is ascribed to the first payment account (step 217). Otherwise, the debit of the processed toll event is ascribed to the second payment account corresponding to the related voucher assertion (step 216).
For off-line processing, the execution flow continues with the processing of the next recorded toll event, as represented by transition flow “B” and step 219.
Details concerning the actions taken in steps 216 or 217 may vary according to different implementations. In existing tele-toll systems, the step of ascribing the debit of a toll event to a (first, default) payment account (step 217) may comprise the updating of a related accounting balance (which may be also stored in the storage module), for example, by adding the cost of the processed toll event, or deducting the cost of a pre-paid balance; wherein a payment transaction for the total due amount (e.g. in case of post-paid) may take place later with (e.g.) the bank that supports the payments for said account. Alternatively, the step of ascribing the debit of a toll event may comprise the step of communicating directly the debited amount of a toll event to the bank or entity that supports the concerned payment account. Therefore, the step of ascribing a toll event to a second payment account (step 216), may involve similar sub-steps as the ones described above. Consequently, when it is needed to keep an accounting balance (e.g. when post-paid applies), the data structure in the storage module may be adapted so as to allow to record separated accounting balance per payment account, or, at least, to keep track of toll events that shall be ascribed to each payment account. For example, if post-paid applies, a simple realization may be to mark a due toll as ascribed to the corresponding first or second account, or to establish a relationship between them.
The voucher assertion (1032) which is stored in relationship with a toll identifier (T-ID) may be provisioned in the toll control server (100) by the tele-toll operator in a similar way as other data held by said server are currently provisioned (e.g. via configuration commands sent to a toll control server 100). However, further advantages may derive of an automatic communication between one or more toll control servers and one or more application servers of service providers which can mediate in the payment of toll events, so as to achieve a flexible allocation of payment accounts.
Before going into further details, it shall be noticed that a telecommunications network may be logically divided into: access network(s), core network and service network. For example, a modern telecommunications network implementing 3rd generation mobile technology (also known as “Universal Mobile Telecommunications System” UMTS) admits various kind of access network, such as 2ndgeneration radio access network, 3rd generation radio access network, or WLAN (Wireless Local Area Network). The core network comprises all the nodes assumed to perform common control and/or routing functions for any communication, regardless the access network to which any of the end-points of a communication (e.g. user terminal, application server, etc) is connected to. Finally, the service network is considered to be comprised by the plurality of application servers intended to provide services to a plurality of users (or to other application servers); preferably, independently of the kind of communication device utilized by the user (e.g. mobile terminal, fixed or wireless PC, etc) and the kind of access network said communication device is connected to (e.g. WLAN, Internet, 2nd or 3rd generation radio network, etc) For this purpose, some mechanisms (such as “Single Sign On” SSO, or “Identity Federation” as defined by Liberty Alliance -http://www.projectliberty.org-) are being developed to permit a user having a subscription with a service provider, such as a mobile telecommunications provider, to access to the services that may be provided by a plurality of application servers in the service layer.
Reference is now made to
Flow 401 represents the arrival to the application server (300) of a service request from a communications device (34) of a user. Although (as illustrated in
A first example case to illustrate the signaling flows of
If from the information flow(s) of the service request (401) the application server determines that a mobile communications device (34) may be involved (and/or if it is requested to do so), it can periodically obtain (402,406) information about the current geographical location of said mobile communications device from a server (303) that provides geographical location information of mobile communications devices.
Once received a service request (401), the application server builds, based on the content of the request, as well as in further data obtained for said request, payment authorization requests or payment revocation requests (403,407,408) that may be sent to one or more toll control servers (100-1,100-2). In addition to information usable to identify the toll identifier they relate to, and further additional data to control the ascription of debits to a second payment account, payment authorization requests or payment revocation requests may further comprise information that may allow the receiving toll control server to identify and/or authenticate the source of the request, so as to process a received request or to reject it (e.g. the information sent in the requests may be digitally signed by the sender application server).
Flow 403 represents the sending of a payment authorization request that derives from a previous service request (401) to one toll control server (100-1). This may be the case wherein the application server (300) has determined (e.g. based on the content of the service request, and/or based on obtained positioning information 402) that this particular toll control server is to be notified.
For this purpose, the application server (300) may, for example, check data table that relates a toll identifier (or series or identifiers) with identifiers of toll control servers (100-1,100-2) that may be used to address communications to them. Similarly, the application server may check a data table that comprises identifiers of certain geographical areas in relationship with identifiers of toll control servers entitled to ascribe debits of toll events collected in said areas. The application server (300) may have said data table(s) or, alternatively, to obtain the aforementioned relationship from another server(s) that store said kind of information. A simple realization could however consist on provisioning the identifiers of one or a plurality of toll control servers (100-1,100-2) into the application server (100); wherein the payment authorization requests and payment revocation requests would be sent to all of them.
In any case, a selective election in the application server (300) of the target toll control server(s) (100-1,100-2) that should receive a payment authorization request or a payment revocation request (e.g. based on time conditions and/or based on geographical conditions, determined by the application server or received from the requesting user), may provide the advantage of diminishing unnecessary signaling between said application server and toll control servers, and may also make redundant the sending of information about time or geographical conditions in said requests.
When the toll control server 100-1 receives the payment authorization request, it runs process 20, which may comprise the storage of a voucher assertion in relationship with the toll identifier indicated in the request (403). The data content of the stored voucher assertion may be shaped according to the value of data elements contained in the received request (e.g. concerning time, geographical location, identifiers, etc). Voucher assertions may have been previously stored in the toll control server 100-1 before this request (403) is received (e.g. as cited earlier via provisioning, or from a previous payment authorization request). This is represented by dashed box 20 previous to the reception of the payment authorization request of flow 403. Therefore, process 20 may also comprise the establishment of a relationship between a previously stored voucher assertion and a toll identifier indicated in the received request. Furthermore, process 20 may also comprise the modification of the content of a previously stored voucher assertion according to the content of the received request. This latest situation may be originated by a service request (401) that modifies some of the conditions previously requested to ascribe the payment of toll events to the second account, or that modifies some other information concerning said payment (e.g. time condition, location condition, user account, user identifier, etc). If no time information is received in a received payment authorization request (402), process 20 may also comprise the setting of a time value for the aforementioned time condition element of the voucher assertion according to the time in which said request has been received; wherein said time value may determine the start of a period of time in which toll events comprising the indicated toll identifier are to be ascribed to the corresponding second payment account.
Flow 404 represents the capture of the toll identifier (T-ID) of a vehicle (V1) passing by the reading area (A11) of reading station 11. Next, the toll event is notified (405) to the toll control server 100-1, which then runs process 21, described earlier in detail with reference to
Following the example case cited earlier, the application server obtains (406) again information about the current geographical location of the monitored mobile communications device, and determines that his user has left the geographical area controlled by toll control server 100-1 and now has entered in a geographical area controlled by toll control server 100-2. Accordingly, in flow 407 a payment revocation request for the concerned toll identifier is sent towards toll control server 100-1, and a payment authorization request is sent in flow 408 towards toll control server 100-2. Toll control server 100-2 shall then run process 20 as described earlier with reference to toll control server 100-1. The payment revocation request (407) may comprise the involved toll identifier or another data that may be usable by the toll control server 100-1 to determine said toll identifier; for example, a data that was previously sent in an earlier payment authorization request, such as the telephone number of the user, or the identifier of his payment account. At reception of the payment revocation request (407), toll control server 100-1 runs process 22, which may comprise: the removal of the voucher assertion related to the concerned toll identifier, or the breaking of the relationship (13) stored for them.
State-of-the-art toll control servers of tele-toll operators, as well as application servers of service providers, are commonly implemented in computer-based machines. In these cases, computer programs having computer-readable program codes are loaded in computer-based servers causing them to behave according to a predefined manner that is in accordance to their specific functionality. Accordingly, those skilled in creating and/or modifying computer programs intended to be loaded in a computer-based toll control server or in a computer-based application server, would, without departing of the teachings of the present invention, readily apply them to create and/or modify computer programs that, when executed in a toll control server or in a computer-based application server, would make said servers to behave according to any of the embodiments described heretofore.
The invention has been described in respect to some exemplary embodiments in an illustrative and non-restrictive manner. Variations can be readily apparent to those of ordinary skill in the art. For this reason, the invention is to be interpreted and limited in view of the claims.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/SE04/01165 | 8/3/2004 | WO | 2/2/2007 |
