AU2016340046A1 - Automatic detection of a toll for a vehicle - Google Patents
Automatic detection of a toll for a vehicle Download PDFInfo
- Publication number
- AU2016340046A1 AU2016340046A1 AU2016340046A AU2016340046A AU2016340046A1 AU 2016340046 A1 AU2016340046 A1 AU 2016340046A1 AU 2016340046 A AU2016340046 A AU 2016340046A AU 2016340046 A AU2016340046 A AU 2016340046A AU 2016340046 A1 AU2016340046 A1 AU 2016340046A1
- Authority
- AU
- Australia
- Prior art keywords
- toll
- mobile device
- vehicle
- zone
- server
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
Classifications
-
- 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
- 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/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3224—Transactions dependent on location of M-devices
-
- 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
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (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)
- Traffic Control Systems (AREA)
Abstract
This disclosure relates to the automatic detection of a toll for a vehicle (102) and effecting payment of a toll for a vehicle (102). In one embodiment, automatic detection allows for a vehicle (102) to be used in toll zones (107) without the use of a specific tolling device such as an E-Tag or E-Toll. In a second embodiment, a specific tolling device (105) for effecting payment of a toll that enables communication with a mobile device (104) and a toll device associated with a toll zone (107) may be used as a more adaptable specific tolling device that supports multiple users and toll payment options.
Description
"Automatic detection of a toll for a vehicle"
Technical Field [0001] This disclosure relates to the automatic detection of a toll for a vehicle, in particular but not limited to, determining a toll is payable. Aspects of the invention include methods, computer systems and software.
Background [0002] It is common for a toll to be associated with a geographical area known as a toll zone. That is, within some geographical areas, a monetary amount may be charged for certain types of use within that geographical area. Typically a toll zone represents a road, motorway, tunnel or bridge. In each case, a toll may be charged for the vehicular use of the road, motorway, tunnel or bridge. For example, a vehicle that enters the M2 motorway is charged a toll for the use of the vehicle on the M2. However, for the purposes of this disclosure, a toll zone could be any geographical area that is associated with a toll, charge, fine or levy including road tolls, motorway tolls, school zones, road usage charges and other tolls and charges such as those associated with the use of car parks, national parks or waste disposal areas. Road usage charges include payment schemes for the use of all roads within a specific geographical area such as the road usage charges in London, England and Florence, Italy.
[0003] Electronic tolling systems require the use of a specific tolling device such as an E-Tag or E-toll. These tolling devices are usually expected to be installed permanently in the vehicle. However, modern toll gates also typically have licence plate recognition for vehicles that do not possess a specific tolling device. When a vehicle passes through a toll gate and a specific tolling device is not detected, a photograph is taken. The licence plate associated with the vehicle can subsequently be recognised from the photograph.
[0004] Where a vehicle does not possess a tolling device, the toll may not be charged or paid contemporaneously with the use of the toll zone but the toll operator may still charge the owner or user of the vehicle for use of the toll zone. When a toll payment is late, toll operators typically charge to the owner or user of the vehicle an administrative fee in addition to the toll. A substantial administration fee is often payable where the toll was not paid within a three day period. In some cases the administrative fee can represent a 300% increase or more on the actual amount of the toll.
[0005] Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each claim of this application. The present disclosure refers to examples of Australian toll zones but the disclosure is not intended to be limited to Australian toll zones. It is to be understood that adjustments can be made according to the laws and regulations of individual countries where appropriate.
[0006] Throughout this specification the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.
Summary [0007] A computer implemented method for the automatic detection of a toll for a vehicle, the method comprising: receiving information about a plurality of toll zones, wherein each toll zone represents a geographical area; determining a location of a mobile device associated with the vehicle; determining the mobile device is in or near a toll zone; and determining a toll associated with the toll zone and the vehicle is payable.
[0008] The method may further comprise generating an alert indicative of the toll associated with the toll zone and the vehicle.
[0009] The method may further comprise determining a toll amount associated with the toll.
[0010] The method may further comprise generating an alert indicative of the toll amount associated with the toll.
[0011] The method may further comprise sending data representing the toll amount, the vehicle and a payment authorisation to a server for effecting a payment of the toll.
[0012] The method may further comprise sending an indication of the location of the vehicle to a server for storage.
[0013] The method may further comprise determining the location of the mobile device by utilising satellite positioning systems.
[0014] In the method described above, determining the toll is payable may be based on one or more of: the toll zone; the vehicle; date and/or time; direction of travel; other toll zones; previous toll amounts; and distance travelled.
[0015] There is also provided a non-transitory computer readable medium having computer readable instructions for the automatic detection of a toll for a vehicle according to one or more of the methods described above.
[0016] A device for the automatic detection of a toll for a vehicle comprising: a memory to store instructions; a bus to communicate the instructions from the memory; a processor to perform the instructions from the memory communicated via the bus to: receive a plurality of toll zones, wherein each toll zone represents a geographical area; determine a location of a mobile device associated with the vehicle; determine the mobile device is in or near a toll zone; and determine a toll associated with the toll zone and the vehicle is payable.
[0017] The device described above wherein the device is a mobile device, server or a combination of mobile device and server.
[0018] A system for the automatic detection of a toll for a vehicle comprising a mobile device; and a server, that separately or in combination perform the method of any one of the methods described above.
[0019] A computer implemented method for effecting payment of a toll for a vehicle performed by an embedded device, the method comprising: receiving user information associated with one or more users and associated with one or more vehicles; determining active user information; receiving a communication from a toll device associated with a toll zone; and sending information associated with the active user information for effecting a payment of the toll for the toll zone for the vehicle associated with the active user information.
[0020] The method may further comprise generating an alert indicative of the toll zone.
[0021] The method may further comprise determining a mobile device associated with the embedded device and sending information representing the alert to the mobile device such that the alert can be effected on the mobile device.
[0022] The alert described above includes any one or more of: playing a sound; displaying visual indicia on a display; or vibrating.
[0023] There is also provided a non-transitory computer readable medium having computer readable instructions for effecting payment of a toll for a vehicle according to any one or more methods described above.
[0024] An embedded device for effecting payment of a toll for a vehicle comprising: a memory to store instructions; a bus to communicate the instructions from the memory; a processor to perform the instructions from the memory communicated via the bus to: to receive one or more user information associated with one or more vehicles; to determine active user information; to receive a communication from a toll device associated with a toll zone; and to send information associated with the active user information for effecting a payment of the toll for the toll zone for the vehicle associated with the active user information.
[0025] Optional features of the computer method described above are equally optional features of the software and computer system also described here.
Brief Description of Drawings [0026] Examples of the present disclosure will be described with reference to: [0027] Fig. 1 is a schematic of a system for the automatic detection of a toll for a vehicle; [0028] Fig. 2 is a flow diagram of a method for the automatic detection of a toll for a vehicle; [0029] Fig. 3 is an example user interface for a user to login; [0030] Fig. 4 is an example user interface for a user to select a vehicle; [0031] Fig. 5 is an example user interface for the automatic detection of a toll is not payable; [0032] Fig. 6 is an example user interface for the automatic detection of a nearby toll is payable; [0033] Fig. 7 is an example user interface for the automatic detection of a toll of a vehicle in a toll zone is payable.
[0034] Fig. 8 is an example user interface for the automatic detection of a toll amount of a vehicle in a toll zone is payable.
[0035] Fig. 9 is an example user interface for a historical report of payable toll amounts of a vehicle.
[0036] Fig. 10 is a flow diagram of a method for effecting payment of a toll for a vehicle performed by an embedded device.
[0037] Fig. 11 shows an example mobile device.
[0038] Fig. 12 shows an example embedded device [0039] Fig. 13 shows an example server.
Description of Embodiments Overview [0040] The current disclosure relates to the automatic detection of a toll for a vehicle. In one embodiment, this automatic detection allows for a vehicle to be used in toll zones without the use of a specific tolling device such as an E-Tag or E-Toll. This embodiment has the potential to significantly reduce the administration fees that are payable without a specific tolling device. In a second embodiment, a specific tolling device that communicates with a mobile device may be used as a more adaptable specific tolling device that supports multiple users and toll payment options.
[0041] Fig.l illustrates a schematic of a system 100 for the automatic detection of a toll for a vehicle 102. The system includes a mobile device 104 used by a user 106 and associated with a vehicle 102. The mobile device 104 is in communication with a server 120 through a communications network 110 such as the internet. The base station 112 facilitates the communication between the mobile device 104 and the network 110. The mobile device 104 may determine its location or report measurements to the server 120 for the server to determine the location of the mobile device 104.
[0042] Where the location of the mobile device 104 is determined to be near or in a toll zone 107, either the mobile device 104 or server 120 determines whether a toll is payable for the vehicle associated with the mobile device 104. That is, even where a vehicle is in a toll zone 107, a toll may or may not be charged to the vehicle. As a result, a toll may or may not be payable. Whether a toll is payable is based on many factors that include the toll zone; the vehicle; date and/or time; direction of travel of the vehicle; other toll zones; previous toll amounts; and distance travelled.
[0043] As will be described in more detail below, once the mobile device 104 determines a toll zone 107 is nearby to the vehicle or mobile device 104 determines the vehicle is in the toll zone, the mobile device 104 may generate an alert indicative of the toll zone. The user 106 can confirm or deny that a toll is payable by interacting with the mobile device 104. Once the mobile device 104 has received an indication from the user 106, the mobile device 104 may also send user input data indicative of a confirmation from a user 106 that a toll is payable and that a payment should be made for the toll. The mobile device 104 or server 120 may also send data representing the toll, the vehicle and a payment authorisation to a third party payment server 140.
[0044] The methods described below may refer to one vehicle or one user, but this is not intended to be limiting. That is, the methods apply to multiple toll zones, vehicles, users, and servers. As above, a toll zone could be any geographical area that is associated with a toll, charge, fine or levy including road tolls, motorway tolls, school zones, road usage charges and other tolls and charges such as those associated with the use of car parks, national parks or waste disposal areas. Toll zones may have a single toll gate or multiple toll gates, for example, an entry toll gate to indicate the vehicle has entered the toll zone and an exit toll gate, which indicates the vehicle has exited the toll zone.
Mobile Device 104 [0045] The mobile device 104 is any device that has a capacity to determine and communicate its location. Preferably the mobile device 104 is a smartphone with a cellular connection. Preferably the cellular connection is 4G, but the system may also work with other data communication technologies such as 2G and 3G. Where available, the mobile device may also be able to utilise a Wi-Fi or other wireless data connection.
[0046] The mobile device 104 has a user interface to allow interaction with a user 106. Preferably the user interface would be a touch screen and the user may therefore interact with the mobile device 104 by touching the screen. In one example, the mobile device 104 generates a display on the user interface that indicates that the toll is payable. This display is typically a button on the user interface which the user can press to confirm that a toll is payable and a payment should be made for the vehicle.
[0047] The mobile device may also include a user interface that presents information to the user 106. Such information includes road works, school zones, road traffic conditions, whether there is a toll in the vicinity and, based on the current time and direction and route of the vehicle, whether the vehicle is likely to be tolled in the near future.
Embedded device 105 [0048] The embedded device 105 is a device that would typically be embedded in a vehicle. The embedded device 105 would be able to communicate with toll gates 108 as well as mobile devices 104. Examples of communications between the embedded device 105 the mobile device 104 include Bluetooth and Wi-Fi. Examples of communications between the embedded device 105 and the toll gate 108 include Radio Frequency Identification (RFID). With these communications, the embedded device will have a communication path with the toll gates 108 and may optionally be able to be associated with a mobile device 104 in order to communicate that a toll gate had been passed, which may indicate that a toll is to be charged to the user.
[0049] The embedded device will be detected upon passing toll gate using wireless communication with the toll gate 108 directly. This wireless communication includes any type of compatible RFID or similar. Toll gates 108 are typically fitted with RFID interrogators which emit a radiofrequency that will activate the embedded device 105.
[0050] Examples of usable frequencies include Low Frequencies (LF), High Frequencies (HF), Ultra High Frequencies (UHF) and Super High Frequencies (SHF). The frequencies used by the embedded device 105 would depend on the corresponding frequencies used by interrogators associated with the toll gates 108. The embedded device 105 may also use dedicated short-range communications (DSRC) for sending and receiving messages over the communication path established by the wireless communications.
[0051] Typically the embedded device 105 is used for the payment of passing a specific toll gate at a specific time, or combination of toll gates at a specific range of times. These payments can be automatically deducted from payment details stored either by the toll operator or via a third party server. Communications protocols may be established to ensure the correct information is sent and received by the embedded device following the method disclosed here.
Server 120 [0052] The server 120 is preferably a web server that runs a server package such as Apache server. The server 120 listens for connections from the mobile device 104. Once a connection is established with the mobile device 104 the server 120 will be able to provide Web Services which are built and distributed using web development technologies such as PHP HyperText Preproccessor (PHP). The server 120 will typically handle the communications between the data store 130 and the mobile device 104, web terminal 150 and any third party payment server 140.
[0053] It should be noted that although the server 120 is shown as an independent network element in Fig. 1, it need not be a separate device and the functions performed by the server 120 described here may be actually performed by another network element. Further, functions performed by the server 120 may be distributed between multiple network elements in Fig. 1.
[0054] The server 120 may send, from the output port of the server 120 to a communications network 110, information about a plurality of toll zones, wherein each toll zone represents a geographical area.
[0055] Where the mobile device 104 does not determine the location of the mobile device 104 itself, the server 120 may determine the location of the mobile device. The server 120 in such a case may receive the measurements made by the mobile device from satellites 160 or base stations 112. In this case, the server 120 may receive, at an input port of the computer system from the communications network, location measurements from the mobile device 104. The server 120 may then determine the location of the mobile device 104.
[0056] Further, the server 120 stores in memory of the server 120 an association between the user account, the vehicle, the location of the vehicle and payment information. The server 120 may then determine the mobile device 104 is in or near a toll zone. The server 120 may also determine the toll is payable.
Data Store 130 [0057] The server 120 has access to a data store 130 that contains the data necessary for the system 100 to function. The data store 130 may be a database that is an open source database such as MySQL or a proprietary database such as Oracle. In the example illustrated in Fig. 1, the data store 130 is separated into four databases. In this example, the data store contains the user information 132, toll information 134, historical data 136 and payment information 138.
[0058] The four databases may be a part of a database management system (DBMS) such that the records of the different databases are associated with each other, typically using repeated fields that uniquely identify records of a different database or other linking reference, such as in integer primary key that is stored in every record in each of the databases. Each of the four databases may comprise multiple databases or data tables and may be stored in a distributed manner, such as in a cloud storage system using a distributed hash table (DHT).
User information 132 [0059] User information 132 data store contains a unique user identifier associated with user account details. The account details include the name and address of the user as well as the vehicle or vehicles associated with that account. User information 132 data store also includes a combination of user name and password which is used to identify the user 106 as described below. The user information 132 data store may also contain selections of the user of the preferred frequency of payment and the method of payment. The frequency of payment includes either contemporaneous one-off charge per toll, post-payment on a regular basis or post-payment on a threshold basis. The method of payment includes direct debit, prepayment or credit card payments.
Toll information 134 [0060] Toll information 134 data store contains the geographical locations of the toll zones and associated charges. The location of each toll zone may be represented by one or more combinations of numbers representing the latitude and longitude of the toll zone. Each of these combinations of numbers is stored in the database against a toll identifier. The toll identifier is a unique identifier for each toll zone in the data store.
[0061] Importantly, the degree of precision required for information about the geographical location of each toll zone may differ. A number representing latitude and longitude that has six decimal places will be accurate to 100 millimetres. A number with only three decimal places will be accurate to approximately 100 metres. Where a toll zone is a single toll gate in an area with numerous toll zones nearby then a higher degree of precision may be required. In contrast, where the toll zone is relating to a wider area or where there are fewer roads in the surrounding area then a lower degree of precision may be required.
Historical data 136 [0062] When the mobile device 104 or the server 120 determines the location of the mobile device 104, the location of the mobile device 104 may be stored in the historical data 136 data store along with a time stamp of when the location was determined. The historical data 136 data store may also store the toll zones which the vehicle associated with the mobile device 104 has one or more tolls payable. In addition, the determined direction of travel and other associated data may be stored in the historical data 136 data store. This historical data 136 data store allows for the mobile device 104 to access the toll zones through which a vehicle has travelled over a specified time period.
Payment information 138 [0063] The payment information 138 data store contains the toll amount for each vehicle, the toll provider and the associated payment details for making a payment to the toll provider. Each charge is given a unique identifier in the database and is associated with a vehicle licence number and user identifier. The payment information in the payment information 138 data store may be populated automatically through a connection to a third party server 140.
Payment server 140 [0064] In system 100, a payment server 140 is an external server designed to make billing charges from a toll operator available over the network 110. That is, the payment server 140 acts to send the relevant toll payment information to the server 120 which then stores the payment information in the payment information 138 data store . Alternatively, the payment information 138 data store may be populated by a third party server or from data indicating payment information that is sent from the payment server 140.
Web terminal 150 [0065] In system 100, a web terminal is any computer that can connect to the network 110 and communicate with the server 120. The server 120 will verify the user 152 on the web terminal 150 in a similar way as server verifies the user 106 on the mobile device 104. On the web terminal, once the server 120 determines that the user has successfully logged in, the user can modify the user information associated with the account and view historical data for any vehicle associated with the account.
Satellites 160 [0066] The satellites 160 indicate the typical means by which a mobile device 104 may determine its location.
Description of an example for the automatic detection of a toll for a vehicle using a mobile device [0067] In Fig. 2, a method 200 for the automatic detection of a toll for a vehicle is illustrated. The method as depicted can be performed by either the mobile device 104 or the server 120 or a combination of both. It is worth noting that where the server 120 performs the method 200 in part or in full, there may be some additional communication between the server 120 and the mobile device 104. This communication coordinates the information stored at the mobile device 104 and the server 120 and also coordinates the steps in the method 200 that are performed by the mobile device 104 or the server 120 such that the method 200 is performed in sequence. In this embodiment, the embedded device 105 is not required.
[0068] Either the mobile device 104 or the server 120 may receive 210 information about a plurality of toll zones, wherein each toll zone 107 represents a geographical area. The server 120 may receive 210 the plurality of toll zones via a third party server (not depicted), the mobile device 104 may receive 210 information about the toll zones from the server 120. The mobile device 104 or server 120 may determine 220 the location of the mobile device 104. As will be described in more detail below, the mobile device 104 will typically utilise satellite positioning to determine its own location. However, the server 120 may determine 220 the location of the mobile device 104. In this case, the mobile device 104 may take measurements from satellites 160 and send the measurements to the server 120. In the non-limiting examples described below the mobile device 104 performs the method 200.
[0069] Once the location of the mobile device 104 has been determined, the mobile device 104 or the server 120 can determine 230 the mobile device is in or near a toll zone. The mobile device 104 may additionally generate 250 an alert indicative of the toll zone. This alert may be any appropriate form of indicia such as a simple pop up box on the user interface, a specific change in colour in the user interface or an audible sound. The indicia may warn the user 106 that the toll zone 107 is nearby. This is an optional step of the method 200 and is indicated on the diagram with dotted lines.
Once the mobile device 104 is determined to be in or near a toll zone, the mobile device 104 or server 120 may determine 240 a toll is payable. In addition if the mobile device 104 or server 120 determines a toll is payable, the mobile device 104 or server 120 may determine a toll amount 260. Once a toll amount is determined, the mobile device 104 may generate an alert indicative of the toll amount 270 on the user interface. This alert may be a simple pop up box on the user interface or any other appropriate indicia.
[0070] Finally either the mobile device 104 or server 120 may send data representing a payment authorisation to an external server for effecting a toll payment 280. This may occur in two ways: where the payment is automatic (from 240 to 280) and where the user 106 manually confirms the payment of the toll (from 240, 260, 270, 280). In the automatic method, the payment may be effected as soon as the vehicle 102 is determined to be in a toll zone 107 and the toll is determined to be payable.
[0071] In the manual method, the payment may either be a prepayment or post payment. In a prepayment, the user can prepay an amount into an account. The account is charged for each toll that the vehicle utilises. The prepayment account may be topped up automatically via credit card or alternative source of funds. In the post payment method, the payment is only effected after the mobile device 104 receives confirmation from the user 106 that payment should be made.
Associating a mobile device 104 with a vehicle 102 [0072] When mobile device 104 loads up the software application or the web terminal 150 loads a browser pointed to the appropriate URL, a user interface presents a login screen on the mobile device or web terminal 104, 150. An example login screen 300 for the mobile device 104 is shown in Fig. 3. Mobile device 104 receives as an input from the user 106 a combination of user name 320 and password 330 to log in the user. The mobile device 104 sends the information to the server 120 when the user 106 clicks on the login button 340.
[0073] The server 120 processes the user information 132 stored in the data store 130 to verify the user 106 who is logging in, such as by comparing the provided combination of username and password to a stored combination. The server 120 may detect that the user 106 has not logged in before and the server 120 may request a username and password to set up a new account by communicating a registration message to the mobile device 104. If the verification fails the server 120 prompts the user to re-enter their username and password. If verification succeeds, the server 120 proceeds with a session according to the permissions of the user. The server 120 may store the login information in memory such that the verification process only needs to occur once per session. The server 120 may timeout the session after a period of time (for example, 30 minutes) where the mobile device 104 does not communicate with the server 120. The server 120 may also communicate with any other suitable system for authorising a user login.
[0074] The processor of mobile device 104 receives the input data from the user interface, such as via an event handler triggered by an interrupt signal, and sends login information containing the user name and password. The outport port of the mobile device 104 can be any port, and may be the same port as the mobile device 104 uses for an input port. The input port and output port may be a virtual software port, hardware port or a combination of both.
[0075] The user interface generated and sent by the server 120 may be in any suitable form such as web pages and software application (App) interfaces that may be displayed on a mobile device 104 or a web terminal 150. The user interface may be optimised based on the mobile device 104 or the web terminal 150 used, such as type of operating system, browser type and browser version.
[0076] Where the server 120 determines that a user 152 has successfully logged via a web terminal 150, the server 120 generates and sends a user interface to the web terminal 150. This user interface contains an option to enter both information about a vehicle 102 and a mobile device 104 to be associated with that vehicle 102. Similarly, when the server 120 determines that a user 106 has successfully logged in via a mobile device 104, the server 120 may generate and send a user interface for the user 106 to enter information about a vehicle. In this case, it may be assumed as the default option that the mobile device is to be associated with the vehicle 102. Alternatively, it is possible that the mobile device 104 may indicate on the user interface for the user to select another mobile device which may be associated with the vehicle. As a further point, it is worth noting that the user 152 may or may not be the same user 106. For example, a fleet manager, who manages fleets of vehicles from a central location is not the same as the user 106 who is driving the vehicle 102.
[0077] For both the web terminal 150 and the mobile device 104, there may be multiple vehicles associated with a user account. In one example, a server 120 generates a list of vehicles associated with the user account and sends this list to mobile device 104. In such a case, the user 106 may select a vehicle from the displayed list and the server 120 will associate the user account with that vehicle from that point in time. In another example, the user may select a default vehicle and the mobile device 104 and server 120 will proceed with the default vehicle unless otherwise selected.
That is, the vehicle is associated with the mobile device 104 for the purposes of automatically detecting a toll is payable for the vehicle.
[0078] An example illustration of a user selecting a vehicle 102 to associate with the mobile device 104 is shown in Fig. 4. In this example, a user 106 is given a choice of three vehicles 410, 420 and 430 that are associated with the account of the user 106. In this example the user selects vehicle 102, 410 by selecting the radio control button 440. The user 106 can then confirm the selection by pressing the select button 450.
Receiving information about a plurality of toll zones, wherein each toll zone represents a geographical area [0079] The server 120 stores information about the toll zone, information including geographical data in the toll information data store 134. The server 120 may send the plurality of toll zones to the mobile device 104 when the mobile device first connects to the system. The mobile device 104 receives 210 from the server 120 a plurality of toll zones, wherein each toll zone 107 represents a geographical area. Typically the toll zones do not change regularly so the server 120 will not need to continually send the toll information to the mobile device 104. However if a toll zone does change, then updated toll information for the toll zone can be sent to the mobile device 104.
[0080] In one example, the mobile device 104 receive a list of information about toll zones. Each toll zone 107 is identified by a unique identifier and associated with a number representing the latitude of the toll zone and a number representing the longitude of the toll zone. The latitude and longitude combined represents the geographical area the toll zone. In another example, the location of each toll zone may be represented by multiple numbers representing multiple latitude and longitude of the toll zone. Multiple numbers representing multiple latitude and longitude may be used to represent a larger geographical area for a toll zone where for example, the toll zone has more than one toll gate.
[0081] The degree of precision required for the latitude and longitude of each toll zone 107 may differ. A number representing latitude and longitude that has six decimal places will be accurate to 100 millimetres. A number with only three decimal places will be accurate to approximately 100 metres. Where a toll zone is a single toll gate then a higher degree of precision may be required. In contrast, where the toll is relating to a wider area or where there are fewer roads in the area then a lower degree of precision may be required.
Determining the location of the mobile device [0082] Once the mobile device 104 has received the toll information, the mobile device can determine the location of the mobile device 104. The mobile device 104 will typically poll its location between one to five seconds. Most modern smartphones have an in-built GPS embedded device which can be utilised to determine the location. The mobile device 104 may receive signals from satellites 114 to determine the location of the vehicle. The mobile device 104 may then take measurements from these signals to then calculate a location of the mobile device 104. The mobile device 104 may receive signals from GPS (Global Positioning System) or GLONASS (GLObal Navigation Satellite System) or other similar navigation systems. The mobile device 104 may also utilise Assisted GPS in order to determine the location, where satellite assistance data is transmitted over the network 110 from a third party assistance data server such as Google SUPL.
[0083] Alternatively the mobile device 104 may be able to determine a location without the use of satellites 114 and may be able to do so based on cell triangulation from nearby base stations 112. In general, this is less accurate than utilising satellite positioning, but may be used where satellite positioning is not available. For example, GPS typically requires an open-sky view from the mobile device 104. Where the vehicle is in a tunnel or has large buildings obstructing the view, then GPS may not be available. In such a case, cell tower triangulation for determining the location may be employed.
[0084] In either alternative, the location will typically be determined in conjunction with a software application such as Google Maps and Apple Maps. Google Maps and Apple Maps (and other mapping providers) utilise a set of routines and tools known as an Application Programming Interface (API) that facilitate building software applications that incorporate mapping technologies.
[0085] The determined location need not have a high degree of accuracy. Typically the location need only be determined within 5 to 10 metres. The required accuracy of the determined location will generally depend on the number of nearby toll zones and roads. For example, where there are multiple roads within a range of 10 metres associated with differing tolls or toll amounts, then the location may need to be determined with a higher degree of accuracy in order to ensure that the determination that a toll is payable is accurate.
[0086] Where a determined location is not determined with sufficient accuracy, the mobile device 104 may wait until the next poll cycle. As described above, this would typically be in the order of 1 to 5 seconds. Alternatively, the mobile device 104 may take into account other auxiliary factors such as the time or direction of travel of the vehicle to determine whether a further location determination is required. For example, a mobile device 104 in a vehicle travelling through the Lane Cove Tunnel may poll its location and find that there is an insufficient view of GPS satellites to make an accurate GPS determination. The mobile device 104 may then try cell tower triangulation but due to the interference of the signals within the tunnel this method reports a large region of 3 kilometres that the mobile device 104 may be in. This may be insufficient to determine that a toll is payable due to the proximity of an M2 toll gate nearby. As a result, the mobile device 104 may delay determining that a mobile device 104 is in or nearby the Lane Cove Tunnel and may wait till the next poll cycle to make a location determination.
Determining the mobile device is in or near a toll zone [0087] Once the location of the mobile device 104 has been determined, the mobile device 104 or the server 120 can determine whether the mobile device is in or near a toll zone. One example way of achieving this is by measuring the distance from the location of the mobile device 104 to that of the toll zones in the vicinity. The mobile device 104 or server 120 may take into account other factors too such as the direction of travel of the vehicle. If the distance from a toll zone 107 is less than a given margin of error, typically 10 metres, then the mobile device 104 or server 120 may determine the mobile device is in a toll zone. This indication may also be accompanied by a sound or other warning feature to indicate to the driver that the vehicle is in a toll zone.
[0088] If the distance from a toll zone 107 is within a larger margin, for example, one kilometre, then the mobile device 104 or server 120 may determine the mobile device 104 is near a toll zone. Where a mobile device 104 is near a toll zone, the mobile device 104 may indicate on the user interface that a toll zone is nearby. The mobile device 104 may also indicate the amount of the toll. This indication may also be accompanied by a sound or other warning feature to indicate to the driver that the vehicle is approaching a toll zone. This allows the driver to assess whether to continue on the route that may be tolled or to divert onto an alternative route.
[0089] The user interface may change 250 colour or other indicia that indicate that the vehicle is in or near a toll zone. In addition, the user interface and accompanying warning features may have different warning levels where each warning level represents a range of distances from the toll zone. For example, the sounds accompanying the alert may increase in frequency in proportion to the proximity to the toll zone. There may be one beep for within 3 kilometres, two beeps within 2 kilometres and four beeps within 1 kilometre.
[0090] The location of the mobile device 104 typically will continue to be monitored. The warning indicia 250 as outlined above may operate after each poll of the location of the mobile device 104.
Determining a toll is payable [0091] The server 120 or mobile device 104 will then determine 240 a toll associated with the toll zone and vehicle is payable. There are numerous factors that may affect a determination whether a toll is payable. The relevant factors include: the toll zone; the vehicle; date and/or time; direction of travel of the vehicle; other toll zones; previous toll amounts; and distance travelled. The factors are explained below.
[0092] Each toll zone 107 may have different rules for attributing charges to a vehicle. As a result the toll zone that the vehicle utilises may be a significant factor to whether a toll is payable.
[0093] The server 120 or mobile device 104 may determine 260 a toll amount associated with the toll zone 107 and vehicle 102. Some toll zones may have differing charges associated with different types of vehicles. In some cases, some types of vehicles (such as motorcycles) can utilise a toll zone 107 without being charged. Some individual vehicles (such as buses, taxis or rental cars) may also be able to utilise a toll zone without being charged.
[0094] The date and/or time of the vehicle entering the toll zone 107 may be important where the toll zone applies variable time of day tolling (such as the Sydney Harbour Bridge and Sydney Harbour Tunnel tolls).
[0095] In addition, some toll zones may have different charges based on the direction of travel. For example, the Sydney Harbour Bridge only charges a toll for southbound traffic. Northbound traffic is not tolled. Similarly, the Eastern Distributor charges a toll for northbound traffic and southbound traffic is not tolled. Therefore, where a device is within the specified distance of a toll zone 107 the direction of travel may be taken into account in order to determine whether in fact a toll is payable. The direction of travel can typically be measured from a series of locations of the mobile device 104 over time.
[0096] Other toll zones may affect a determination whether a toll is payable. Where a vehicle 102 is determined to have utilised other toll zones within a short period of time, a further toll may not be charged for the toll zone. The other toll zones may include the same toll zone 107 as well. That is, in some cases, if a vehicle has previously utilised a toll zone in the same day for which it was charged, the vehicle may not be charged again for further usage.
[0097] Similarly, the charges of other toll zones may affect whether a toll is payable. In some cases, a threshold limit may apply to the total amount of tolls in a specified period. Therefore if a car is tolled normally at $4 per use but $8 maximum per day then a vehicle may utilise a toll zone 107 multiple times after the second use that day for which the vehicle will not be charged again.
[0098] An example illustration of determining a toll is payable is shown in Fig. 5.
The mobile device 104 shows on the user interface 500, a text box 510 that states that no payable tolls are detected nearby. The textbox could be green to indicate that there are no tolls nearby to the current location of the vehicle. The map of the area 520 indicates generally where the vehicle is located. The cross 530 indicates the current location of the mobile device 104 and by association the vehicle 102. There is a toll gate 540 indicated by a circle with a letter ‘Τ’. In this example, the mobile device 104 has determined that the vehicle 102 did not have a toll payable at the toll gate 540 because the vehicle was travelling in a south bound direction. The direction of travel was measured at the locations indicated by the dots 550. The dots 552 were ignored for a lack of accuracy likely due to the difficulty of obtaining a GPS satellite signal while travelling through the city with large buildings and tunnels blocking the view. Finally, the calculated route 560 is shown by the line.
Confirming a toll is payable [0099] Once the mobile device 104 determines a toll is payable, the mobile device 104 may generate 270 an alert indicative of the toll for a vehicle for the toll zone. Alternatively the server 120 may prompt the mobile device 104 to generate 270 the alert. The user 106 can confirm or deny that a toll is payable by interacting with the mobile device 104. The data store 130 may contain user information 132 that includes account information associated with a user account. Account information includes credit card details, bank account details and an account balance. If the user 106 confirms that a toll is payable or the option for automatic payment of tolls is active, the server 120 can initiate a payment for the toll.
[0100] An example illustration of confirming a nearby toll is payable is shown in Fig. 6. The mobile device 104 has detected that a M5 South West Toll is nearby. This is indicated by the textbox 610. This textbox may be orange to indicate that a toll zone is nearby. There is an additional button 620 which allows a user to confirm a toll is payable. The button 630 allow a user to deny that a nearby toll is payable.
[0101] An example illustration of confirming a toll is payable is shown in Fig. 7. The mobile device 104 has detected that a vehicle is in the M5 South West toll zone. This is indicated by the textbox 710. This textbox may be red to indicate that the vehicle is in the specified toll zone. Similarly the mobile device 104 receives from the button 720 an input from the user to confirm a toll is payable. The button 730 allow a user to deny that a toll is payable for that toll zone.
Confirming a toll amount [0102] The mobile device may also indicate that a toll amount is payable. An example illustration of confirming a toll amount is payable is shown in Fig. 8. In this example, the mobile device 104 has detected that a vehicle is in the M5 South West toll zone. This is indicated by the textbox 810. The textbox 810 may be red to indicate that the toll amount is payable. Similarly to the above the mobile device 104 receives from the button 820 an input from the user to confirm the toll amount is payable. The text on the button 820 may change to “Pay Toll” to indicate that payment should be made for the toll. The button 830 allow a user to deny that toll amount is payable.
Paving a toll [0103] The server 120 stores a setting for the preferred payment method for each user in the user information 132. There are numerous ways in which the payment for the payable toll can take place. Example forms of payment are as follows. Where the server 120 determines that direct debit is appropriate and the user information 132 contains a bank account, the toll can be paid directly by initiating a direct debit transaction. This can be achieved by sending 280 a request to a payment service provider, such as an electronic funds transfer (EFT) service provider. Where the server 120 determines that a credit card payment is appropriate and the user information 132 contains credit card information, the server may request a credit card payment from a banking service provider. An alternative form of payment is where a user has made a prepayment to the toll provider. This can be represented in the user information as an account balance. Where a toll is authorised to be charged, the server 120 sends 280 a request to the third party payment server to deduct the relevant charge from the account balance associated with the user.
[0104] For example, server 120 stores for each account in the database 130 an associated list of vehicles. Once the server 120 determines that the user 106 has successfully logged in with an account, the server 120 may send to the mobile device 104 a list of vehicles associated with the account. The mobile device 104 may receive as an input an indication from the user 106 which vehicle is currently in use. After receiving an indication of a selection of a vehicle 102 with licence number ‘ABC 123’ and the location of the mobile device 104, the server 120 adds a record to the database. The record contains the licence plate ‘ABC 123’ and the current location of the mobile device 104. In addition, if the mobile device 104 determines that a toll is payable, the mobile device may also send a toll identifier and a toll amount to the server 120 as values. The server 120 may keep track of whether the toll has been paid so each record in the database may comprise an additional indicator of whether a toll has been billed or whether it is unbilled. The mobile device 104 may send an additional indication of the confirmation that the toll is payable. Server 120 may send 280 the user information, vehicle and toll information to a third party payment server 140 together to effect the payment of the toll.
[0105] In any of the above examples, payment can be made contemporaneously with the determination that the toll is payable or at some later point. In some cases the payment can be made periodically such as once a month or once the outstanding unpaid tolls reach a certain threshold such as $60. In some cases the payment can be prepaid and an account is debited with each toll (see below). It is to be appreciated that payments can be made in numerous ways and the examples given above are not limiting.
Description of an example for effecting payment of a toll for a vehicle using an embedded device [0106] In Fig. 10, a method 1000 for the automatic detection of a toll for a vehicle is illustrated. The method as depicted can be performed by a combination of the embedded device 105 and either the mobile device 104 or the server 120. Communication may be coordinated by the mobile device 104, the server 120, or a third party such as the party operating the toll gate 108 such that the method 1000 is performed in sequence. In this embodiment, the mobile device 104 is not required.
The embedded device 105 may be set up so that it operates independently of a mobile device 104.
[0107] In an example scenario, when the vehicle 102 passes within range, the toll device such as an RFID interrogator associated with a toll gate 108 will send a command to an embedded device 105 to return a unique identifier. The interrogator associated with the toll gate 108 may receive this unique identifier and communicate it to its own payment server, third party payment server or the server 120 for further processing. Typically, an account is associated with the user 106 and associated with the unique identifier. As a result, whenever the interrogator receives and communicates the unique identifier, the account would be deducted a toll amount, which is based on the vehicle type, time, and other factors described above. In many circumstances the toll amount would not be deducted until the vehicle associated with the embedded device 105 had passed an exit toll gate that enables the calculation of the toll amount. The embedded device 105 may come installed in a vehicle or it can be retrofitted by a user 106 or technician.
Receiving user information associated with one or more users and associated with one or more vehicles [0108] As above, when setting up the embedded device 105, user 106 may log in via the mobile device 104 or web terminal 150 using a combination of user name 320 and password 330. The user interface contains an option to enter information about a vehicle 102, an embedded device 105 and a mobile device 104 to be associated with each other.
[0109] In the case where the user optionally selects an embedded device 105, the server 120 may send a message to the mobile device 104 to communicate with the embedded device 105 so that the appropriate details of the embedded device 105 may then be communicated by the mobile device 104 to the server 120 for storage in the user information 132 data store. The mobile device 104 will also communicate information relating to the payment for the logged in user, or alternatively, any user information that the user selects. The embedded device receives 1010 the user information associated with one or more users and associated with one or more vehicles. The user information received by the embedded device may be as simple as a unique identifier, or it may be a user profile complete with payment information. The embedded device 105 store the received information in internal storage for later use when communicating directly with toll gates such as 108.
Determining active user information [0110] Once the embedded device has received user information associated with one or more users and associated with one or more vehicles, the embedded device 105 will determine 1020 the active user information.
[0111] The embedded device 105 in the preferred embodiment has a data store for a setting for the preferred payment method for each user 106. This may be equivalent to the user information 132, it may be a subset of the user information 132 or it may simply be a unique identifier for the user. In the simplest example, there is only one user and one vehicle associated with the embedded device 105. In this case, this step of determining the active user information is simple and the user would not have to change or modify any options or settings through the user interface on the mobile device 104.
[0112] The embedded device may also support multiple users and can be switched to a specific user through the mobile device 104 by simply clicking on the embedded device activation choice option through the user interface on the mobile device 104. Once the choice is made on the user interface, the mobile device 104 communicates a message to the embedded device 105 to make the selected user information active. The amount of data stored for each user depends on the amount of storage available on the embedded device 105.
[0113] In the preferred embodiment, the embedded device 105 will have an active user at all times. Typically, the embedded device 105 will be able to determine 1020 the active user information by retrieving the active user information from the memory on the embedded device.
Determining a mobile device associated with the embedded device [0114] Optionally, the embedded device may determine 1040 a mobile device 104 associated with the embedded device 105. In the preferred embodiment, during the setup phase, details of a mobile device 104 may also be communicated with the embedded device 105. In this case, embedded device 105 would determine the mobile device associated with the embedded device 105 during setup. Alternatively, the embedded device 105 may be able to scan for a nearby mobile device 104. This is typically available for Bluetooth and Wi-Fi technologies. The user 106 may be able to add multiple mobile devices that are associated with the embedded device through the user interface on the mobile device 104.
[0115] If a mobile device 104 is associated with the embedded device 105, the mobile device 104 may additionally receive an alert indicative of the toll zone. As noted above, a mobile device is not required. As a result, this step 1040 is an optional step of the method 1000 a.
Receiving a communication from a toll device associated with a toll zone [0116] Toll zones typically have a number of toll gates 108 which are fitted with toll devices. The example below utilises a toll gate 108 as an illustration of how a toll device associated with a toll zone 107 may be used and is not intended to be limiting.
[0117] The embedded device 105 would preferably communicate with a toll gate 108 by Radio Frequency Identification (RFID). In this embodiment, the embedded device 105 will be detected upon passing toll gate 108. Toll gates 108 are typically fitted with toll devices that communicate with compatible devices such as the embedded device 105. Examples of a toll device include RFID interrogators which emit a radiofrequency that will activate the embedded device 105. Therefore it is expected that each toll gate 108 would have an interrogator associated with it that enables commands to be sent to compatible devices, such as the embedded device 105, in order to establish user information, or other information that may be required for the payment for the toll zone 107. The frequencies used by the embedded device 105 would depend on the corresponding frequencies used by interrogators associated with the toll gates 108. Communications protocols may be established to ensure the correct information is sent and received by the embedded device. The embedded device 105 and toll gate 108 may for example use dedicated short-range communications (DSRC) for sending and receiving messages.
[0118] Typically the embedded device 105 is used to respond to commands from the toll gate 108 for a unique identifier. So that the user 106 is charged correctly based on the unique identifier used. Typically the user 106 will need to set up the account payments appropriately to be associated with this unique identifier prior to entering a toll zone. The toll operator may allow for the toll to be paid at a later date based on the use of the toll as determined by the unique identifier and the toll gate 108 as well as other identifying features such as date and time.
[0119] Typically one or more entry toll gates would be placed where vehicles enter a toll zone 107 and one or more exit toll gates would be placed where vehicle exit a toll zone. In this case, the server 120 or third party may determine that the vehicle is in a toll zone once the first entry toll gate communicates with the embedded device 105 and may determine that the vehicle is in the toll zone until an exit toll gate communicates with the embedded device 105.
[0120] Due to the typically limited range of RFID, the embedded device in the vehicle 102 is unlikely to be able to detect a toll device associated with toll gate 108 beyond a relatively short range. Current technology allows for communication at a range of approximately 12 metres, but this may be extended with further technological developments.
[0121] In the embodiment where an embedded device 105 is used, the embedded device may communicate directly with a toll device associated with a toll gate without requiring the use of a mobile device 104. In addition, unlike the embodiment above, typically the location of the mobile device is not necessary if the embedded device 105 has communicated with the toll device directly. However, both methods 200 and 100 may be used simultaneously if the user 106 has both an embedded device 105 and mobile device 104.
Generating an alert indicative of the toll zone [0122] Once the embedded device 105 has received a communication from a toll device associated with a toll gate, wherein a toll gate 108 is associated with a toll zone, the embedded device 105 may generate 1050 an alert indicative of the toll zone. Typically this may be a beep or noise, or other sound, or combination of sounds which indicate that the vehicle 102 has passed a toll gate 108 and therefore is in a toll zone. A different alert may be used for an exit toll gate.
[0123] Preferably, the embedded device would have a speaker installed as a speaker would enable an alert generated by the embedded device 105 to be communicated to the user 106. The alerts may be able to be communicated in different ways if the embedded device 105 supports it. For example, the embedded device 105 may also have light emitting diodes (LEDs) that are specific colours that are used to represent when a communication with a toll device associated with a toll gate 108 takes place. The lights may also flash in certain patterns to communicate more complex information.
Sending information representing the alert to the mobile device such that the alert can be effected on the mobile device [0124] Where both a mobile device 104 and embedded device 105 are used, the embedded device 105 may send 1060 information representing an alert to the mobile device 104 such that the alert can be effected on the mobile device 104. This alert may be any information relating to the toll zone 107 that may be relevant to the user 106. The alert on the mobile device 104 may indicate to the driver that the vehicle 102 is in a toll zone and this indication may also be accompanied by a sound or other warning feature.
[0125] The alert on the mobile device 104 may be different types. It may be any appropriate form of indicia such as a simple pop up box on the user interface, a specific change in colour in the user interface or an audible sound. The alerts are similar to and as varied in form as the embodiment described above.
[0126] Where a mobile device 104 is used in the method 1000, the location of the mobile device 104 typically will continue to be monitored. The warning indicia as outlined above may operate after each poll of the location of the mobile device 104.
[0127] If the distance from a toll zone 107 is within a larger margin than 12 metres, for example, one kilometre, then this would likely be out of range of the embedded device 105. Where a mobile device 104 is determined to be near a toll zone 107 (see above), the mobile device 104 may indicate on the user interface that a toll zone is nearby. The mobile device 104 may also indicate the amount of the toll. This indication may also be accompanied by a sound or other warning feature to indicate to the driver that the vehicle is approaching a toll zone 107. This allows the driver to assess whether to continue on the route that may be tolled or to divert onto an alternative route.
Sending information associated with the active user information for effecting a payment of the toll zone for the vehicle associated with the active user information [0128] Finally the embedded device may send 1070 information associated with the active user information for effecting a payment of the toll for the toll zone 107 for the vehicle associated with the active user information. In the simplest example, the embedded device 105 will communicate a unique identifier associated with the active user to the interrogator associated with the toll gate 108. The communication of this unique identifier represents an implied authorisation for effecting the payment of the toll for the toll zone 107 that the toll gate 108 is associated with.
[0129] The embedded device 105 may store user information 132 that includes account information associated with a user account. Account information includes credit card details, bank account details and an account balance. In a simple example, the embedded device 105 may simply use RFID as a unique identifier which would enable the toll operator to automatically deduct a toll payment from an account associated with the unique identifier. Where the user 106 has not selected automatic payment of tolls, the user 106 may confirm the payment of tolls individually and the user 106 can confirm or deny that a toll is payable by interacting with the mobile device 104.
[0130] Where the embedded device contains more than just a unique identifier, the toll gate 108 may be able to receive the additional information as well if it so requests.
[0131] Alternatively, the mobile device 104 or server 120 may determine the appropriate payment authorisation based on the user information. For example, if the user information 132 contains a bank account, the toll can be paid directly by initiating a direct debit transaction. This can be achieved by sending a request to a payment service provider, such as an electronic funds transfer (EFT) service provider. Where the server 120 determines that a credit card payment is appropriate and the user information 132 contains credit card information, the server may request a credit card payment from a banking service provider.
[0132] In other examples, the embedded device 105 sends information associated with the active user information for effecting a payment of passing a specific toll gate that occurs, or occurred, at a specific time. The embedded device 105 may also send information associated with the active user for effecting a payment for the use of combination of toll gates at a specific range of times. These payments can be automatically deducted from payment details stored either by the toll operator or via a third party server or they may be manually approved by the user 106.
Prepayments and automatic payments [0133] There are numerous ways in which the payment for the payable toll can take place. Example forms of payment are as follows. Where the embedded device 105 stores only a user identifier then the toll gate 108 will receive only this user identifier. This user identifier would be sufficient for a payment to be effected based on account details associated with that user identifier. The data representing a payment authorisation may be sent by the toll operator in this scenario. This is essentially an automatic payment as the user’s account is automatically charged without user intervention.
[0134] Another example of the automatic form of payment is where a user 106 has made a prepayment to the toll provider or prepaid an amount to the server 130 into the user account. This can be represented in the user information as an account balance. Where a toll is authorised to be charged, the server 130 may deduct the charge itself or send a request to the third party payment server to deduct the relevant charge from the account balance associated with the user 106.
[0135] In the manual method, the payment may either be a prepayment or post payment. In a prepayment, the user can prepay an amount into an account associated with the user 106. The user 106 is associated with a vehicle 102 and the account is charged for each toll that the vehicle utilises. The prepayment account may be topped up automatically via credit card or alternative source of funds. In the post payment method, the payment is only effected after the mobile device 104 receives confirmation from the user 106 that payment should be made.
[0136] In an example of the automatic payment method, Alice is a courier who often travels through toll zones as part of her job. One night she is driving a car south bound over the Sydney Harbour Tunnel at 6:55pm. The toll for a sedan at this time is the peak hour toll amount of $4. The car later travels north bound over the Sydney Harbour Tunnel at 7:45pm. There is no charge associated with this direction of travel. Finally the same car travels south over the Sydney Harbour Tunnel at 9:32pm. The toll for a car at this time is the non-peak toll amount of $2.50. The total toll for the three trips over the Sydney Harbour Tunnel is $6.50. The user associated with the vehicle has elected for a daily account post-payment. In this case, the system initiates a payment for the total charge at $6.50 at 11:59pm that same day.
[0137] In any of the above examples, payment can be made contemporaneously with the determination that the toll is payable or at some later point. In some cases the payment can be made periodically such as once a month or once the outstanding unpaid tolls reach a certain threshold such as $60. It is to be appreciated that payments can be made in numerous ways and the examples given above are not limiting.
Historical Reports [0138] Server 120 may generate a historical report of locations of the vehicle 102 or other relevant historical data such as toll zones utilised, traffic conditions or roadworks. The historical report may be generated in a number of different ways. In one example, the mobile device 104 receives via the user interface a vehicle licence number from the user. Mobile device 104 then receives a command from the user to generate a report by detecting that the user has clicked the reports button. Server 120 queries the database and generates a report comprising the list of some or all of the tolls associated with that vehicle. Server 120 may query the database to only include the unbilled tolls for the vehicle into the report.
[0139] Alternatively, server 120 may generate a historical report automatically according to predefined criteria. For example, server 120 may determine whether the account has passed a threshold amount of paid or unpaid tolls. Server 120 may also generate the historical report periodically over a set period of time, such as once a month.
[0140] An example historical report is shown in Fig. 9. In this example the vehicle for which the historical report is generated is the vehicle with the licence plate ABC123. This is shown by 910. The month for the report is also indicated at 912. There are a number of entries 920, 930 and 940 each of which represents a date and time of when a vehicle entered a toll zone 107 and the amount of the toll. In this example both the toll zone and the point of entry are indicated. The amount of the toll was also determined. The mobile device 104 calculates a total and indicates this on the user interface at 930.
Example Mobile Device [0141] The user device 104 shown in Fig. 10 includes a processor 1102, a memory 1110 and a network interface device 1106 that communicate with each other via a bus 1104. The user device 104 also contains a location device 1108. The memory stores instructions 1112, 1114, 1116 and 1118 and data for the processes described with reference to Figs. 2 to 9, and the processor performs the instructions from the memory to implement the processes.
[0142] The processor 1102 performs the instructions stored on memory 1110. Processor 1002 receives receiving a plurality of toll zones, wherein each toll zone represents a geographical area from the network interface device 1106. Processor 1102 determines a location of a mobile device associated with the vehicle by enabling the location device 1108 and performs the instructions stored in the location module 1118. The processor 1102 may execute instructions to determine the mobile device is in or near a toll zone. The processor 1102 may execute instructions to determine a toll associated with the toll zone and the vehicle is payable and may also determine the toll amount associated with the toll zone.
Example Embedded device [0143] The embedded device 105 is shown in Fig. 12 includes a processor 1202, a memory 1210, a mobile device interface 1206 and a toll gate interface 1208 that communicate with each other via a bus 1004. The memory stores instructions 1212 1214 and 1216 and data for the processes described with reference to Fig. 10. The processor performs the instructions from the memory to implement the processes.
[0144] The processor 1202 uses the instructions stored in the mobile device interface module to use the mobile device interface 1206 and send and receive information from the mobile device 104. Processor 1202 receives user information associated with one or more user users and associated with one or more vehicles from the mobile device interface 1206. The processor may choose to store the user information using instructions stored in the user module 1212 and the processor uses the instructions stored in the user module 1212 to determine the active user information. Similarly, the processor 1202 receives a communication from a toll device associated with a toll gate 108 via the toll gate interface 1208. The processor 1202 sends information associated with the active user information for effecting a payment of the toll for the toll zone 107 for the vehicle associated with the active user information either via the toll gate interface 1208 or via the mobile device interface 1206. Where the processor 1202 uses the toll gate interface to send the information, the processor 1202 executes instructions in the toll gate interface module 1216. Similarly, where the processor 1202 uses the mobile device interface 1206 to send the information, the processor 1202 executes instructions in the mobile device interface module 1214.
Example Server [0145] The server 120 shown in Fig. 13 includes a processor 1302, a memory 1310 and a network interface device 1308 that communicate with each other via a bus 1306. The memory stores instructions 1312, 1314 and 1316 and data for the processes described with reference to Figs. 2 to 9, and the processor performs the instructions from the memory to implement the processes.
[0146] The processor 1302 performs the instructions stored on memory 1310. Processor 1302 receives receiving a plurality of toll zones, wherein each toll zone represents a geographical area from the network interface device 1308. Processor 1302 may also receive the measurements made by a mobile device 104 and determine a location of a mobile device associated with the vehicle. The processor 1302 may execute instructions to determine the mobile device is in or near a toll zone. The processor 1302 may execute instructions to determine a toll associated with the toll zone and the vehicle is payable and may also determine the toll amount associated with the toll zone.
[0147] It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.
Claims (18)
- CLAIMS:1. A computer implemented method for the automatic detection of a toll for a vehicle, the method comprising: receiving information about a plurality of toll zones, wherein each toll zone represents a geographical area; determining a location of a mobile device associated with the vehicle; determining the mobile device is in or near a toll zone; and determining a toll associated with the toll zone and the vehicle is payable.
- 2. The computer-implemented method according to claim 1 wherein the method further comprises: generating an alert indicative of the toll associated with the toll zone and the vehicle.
- 3. The computer-implemented method according to claim 1 or 2 wherein the method further comprises: determining a toll amount associated with the toll.
- 4. The computer-implemented method according to claim 3 wherein the method further comprises: generating an alert indicative of the toll amount associated with the toll.
- 5. The computer-implemented method according to claim 3 or 4 wherein method further comprises: sending data representing the toll amount, the vehicle and a payment authorisation to a server for effecting a payment of the toll.
- 6. The computer-implemented method according to any one of the preceding claims wherein the method further comprises: sending an indication of the location of the vehicle to a server for storage.
- 7. The computer-implemented method according to any one of the preceding claims wherein the method comprises: determining the location of the mobile device by utilising satellite positioning systems.
- 8. The computer implemented method according to any one of the preceding claims wherein determining the toll is payable is based on one or more of: the toll zone; the vehicle; date and/or time; direction of travel; other toll zones; previous toll amounts; and distance travelled.
- 9. A non-transitory computer readable medium having computer readable instructions for the automatic detection of a toll for a vehicle according to any one of the preceding claims.
- 10. A device for the automatic detection of a toll for a vehicle comprising: a memory to store instructions; a bus to communicate the instructions from the memory; a processor to perform the instructions from the memory communicated via the bus to: receive a plurality of toll zones, wherein each toll zone represents a geographical area; determine a location of a mobile device associated with the vehicle; determine the mobile device is in or near a toll zone; and determine a toll associated with the toll zone and the vehicle is payable.
- 11. The device of claim 10 is a mobile device, server or a combination of mobile device and server.
- 12. A system for the automatic detection of a toll for a vehicle comprising: a mobile device; and a server, that separately or in combination perform the method of any one of claims 1 to 8.
- 13. A computer implemented method for effecting payment of a toll for a vehicle performed by an embedded device, the method comprising: receiving user information associated with one or more users and associated with one or more vehicles; determining active user information; receiving a communication from a toll device associated with a toll zone; and sending information associated with the active user information for effecting a payment of the toll for the toll zone for the vehicle associated with the active user information.
- 14. The computer-implemented method according to claim 13 wherein the method further comprises: generating an alert indicative of the toll zone.
- 15. The computer implemented method according to claim 14 wherein the method further comprises: determining a mobile device associated with the embedded device; and sending information representing the alert to the mobile device such that the alert can be effected on the mobile device.
- 16. The computer implemented method according to claims 14 or 15 wherein the alert includes any one or more of: playing a sound; displaying visual indicia on a display; or vibrating.
- 17. A non-transitory computer readable medium having computer readable instructions for effecting payment of a toll for a vehicle according to any one of the preceding claims.
- 18. An embedded device for effecting payment of a toll for a vehicle comprising: a memory to store instructions; a bus to communicate the instructions from the memory; a processor to perform the instructions from the memory communicated via the bus to: to receive one or more user information associated with one or more vehicles; to determine active user information; to receive a communication from a toll device associated a toll zone; and to send information associated with the active user information for effecting a payment of the toll for the toll zone for the vehicle associated with the active user information.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU2015904216 | 2015-10-15 | ||
AU2015904216A AU2015904216A0 (en) | 2015-10-15 | Automatic detection of a toll for a vehicle | |
PCT/AU2016/050975 WO2017063052A1 (en) | 2015-10-15 | 2016-10-17 | Automatic detection of a toll for a vehicle |
Publications (1)
Publication Number | Publication Date |
---|---|
AU2016340046A1 true AU2016340046A1 (en) | 2018-05-24 |
Family
ID=58516925
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
AU2016340046A Abandoned AU2016340046A1 (en) | 2015-10-15 | 2016-10-17 | Automatic detection of a toll for a vehicle |
Country Status (2)
Country | Link |
---|---|
AU (1) | AU2016340046A1 (en) |
WO (1) | WO2017063052A1 (en) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3032500A1 (en) * | 2014-12-12 | 2016-06-15 | Paytollo, Inc. | Mobile device and navigation device toll paying system and method |
WO2020217451A1 (en) * | 2019-04-26 | 2020-10-29 | 三菱重工機械システム株式会社 | Central server, area server, fee collection system, fee collection method, and program |
US11908247B2 (en) | 2021-06-22 | 2024-02-20 | Toyota Motor Credit Corporation | Systems and methods for collecting tolls along a toll road |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8587454B1 (en) * | 2008-11-18 | 2013-11-19 | Rich Dearworth | System and method for providing electronic toll collection to users of wireless mobile devices |
US20120215594A1 (en) * | 2011-02-18 | 2012-08-23 | Amtech Systems, LLC | System and method for gps lane and toll determination and asset position matching |
US20130090991A1 (en) * | 2011-10-05 | 2013-04-11 | Verizon Patent And Licensing Inc. | Apparatus, system, and method for toll payment via smart phone |
US9317983B2 (en) * | 2012-03-14 | 2016-04-19 | Autoconnect Holdings Llc | Automatic communication of damage and health in detected vehicle incidents |
US20140025444A1 (en) * | 2012-07-23 | 2014-01-23 | Payurtoll LLC | Universal Toll Tag Device and Systems and Methods to Automate Toll Payments |
US20140244365A1 (en) * | 2012-12-29 | 2014-08-28 | DGRT Software LLC | Toll app system |
US9460429B2 (en) * | 2014-08-19 | 2016-10-04 | iDiggApp Inc. | GPS-based toll collection system and method |
-
2016
- 2016-10-17 WO PCT/AU2016/050975 patent/WO2017063052A1/en active Application Filing
- 2016-10-17 AU AU2016340046A patent/AU2016340046A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
WO2017063052A1 (en) | 2017-04-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20210049725A1 (en) | Vehicle traffic and vehicle related transaction control system | |
US11308734B2 (en) | Mobile device and navigation device toll paying system and method | |
US8587454B1 (en) | System and method for providing electronic toll collection to users of wireless mobile devices | |
US20190122447A1 (en) | Methods and systems for payments of services used by vehicles based on time, distance and place | |
CN111104990B (en) | Method, device, server and storage medium for determining traffic route | |
USRE47482E1 (en) | System and method for verifying whether a vehicle is equipped with a functional on-board unit | |
US20170046955A1 (en) | Method and System of Locating and Managing Parking Space | |
US9934682B2 (en) | Systems and methods for monitoring roadways using magnetic signatures | |
KR101861181B1 (en) | System for automatic electronic toll collection based on virtual toll using smartphone | |
US20200258383A1 (en) | Systems and Methods for Monitoring Roadways | |
Nagothu | Automated toll collection system using GPS and GPRS | |
US20220020229A1 (en) | System and method for mobile toll calculation and payment | |
US20220277279A1 (en) | Method, device, and system for providing vehicle sharing service | |
GB2540413A (en) | System for processing parking transactions | |
Kabir et al. | An IoT based intelligent parking system for the unutilized parking area with real-time monitoring using mobile and web application | |
AU2016340046A1 (en) | Automatic detection of a toll for a vehicle | |
AU2020202043A1 (en) | Vehicle parking or vehicle use in a chargeable area | |
JP6954538B2 (en) | Vehicle-passing information processing system and vehicle-passing information processing method | |
KR101888661B1 (en) | Virtual office operating system and method for a mobile communication system for a toll road toll payment | |
JP2019125234A (en) | Service management apparatus and service management method | |
RU2417447C2 (en) | Test method for detecting deviations in geoobjects | |
WO2018203827A1 (en) | System and method for managing vehicular road usage | |
CN107067479A (en) | A kind of system for vehicle of charging | |
Hongfengi et al. | The Research of Intelligent Traffic Congestion Pricing Technology Based on BaiDou Navigation and Token Payment | |
Tyagi et al. | Toll Plaza Automation using GPS |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
MK1 | Application lapsed section 142(2)(a) - no request for examination in relevant period |