WO2020188292A1

WO2020188292A1 - Vehicle discovery system

Info

Publication number: WO2020188292A1
Application number: PCT/GB2020/050742
Authority: WO
Inventors: Darren Richard TENNEY; Samuel Alan JONES; David Christopher BENNETT; Matthew John BRERETON
Original assignee: Tandemip Limited
Priority date: 2019-03-19
Filing date: 2020-03-19
Publication date: 2020-09-24
Also published as: GB201903763D0

Abstract

Aspects of the present invention relate to a computer-implemented method of identifying one or more available vehicles in response to a user generated query, comprising: receiving, at an input of a server, a request for a vehicle, the request comprising a first geographic location; receiving, at the input, location information for a plurality of different vehicles; determining at a processor of the server, for each one of the plurality of different vehicles, a search zone calculated with respect to a vehicle's location in dependence on a first variable distance parameter, the search zone defining a set of geographic locations; and identifying, at the processor, one or more of the plurality of different vehicles whose search zone comprises the first geographic location; and forwarding, from an output of the server, a list of the one or more identified vehicles for display to a user terminal

Description

VEHICLE DISCOVERY SYSTEM

TECHNICAL FIELD

The present disclosure relates to a vehicle management system. Aspects of the invention relate to a method of identifying available vehicles in response to a user generated query, and a corresponding system for identifying available vehicles.

BACKGROUND

Ride hailing applications and traditional taxi companies all utilise booking allocation processes to enable them to appropriately allocate a taxi cab /car to any given requesting passenger. These processes are limited by many different factors, one of which is the legal licensing structure that taxi cabs and operating companies must comply with.

A legal structure involves three different levels of licensing: (1) operator licence - this allows the company to take a booking from the public and then allocate that booking to a driver and vehicle; (2) vehicle licence - this is issued by the authority governing the taxi cab operation in a particular region and ensures that the vehicle meets certain standards; and (3) driver licence - this ensures the driver is fit to transport a member of the public. All 3 licences have to be from the same licensing district to enable legal compliant transport. In the UK alone, there are currently 350 licensing districts. For a ride hailing company or a taxi company to operate across the entirety of the UK they would need licences and bases in all 350 districts.

The problem is made worse by restrictions on allocation of passenger journeys: specifically, a company in one district cannot allocate a journey request received to a licensed driver and vehicle that is licensed in a different district even if they are the same company. For example, consider a booking taken (either by phone call or by an application) for a driver licensed with a company in District A to transport a passenger to District B. The driver is subsequently not allowed to wait for a booking in District B once their original passenger has been dropped off (since they are not licensed in District B); instead, the driver must return to their own licensing District A.

In addition to compliance with legal licensing standards, the booking allocation processes must also take into account the‘zoning’ rules that are applied by the mapping software used by ride hailing and taxi companies. Specifically, to ensure appropriate allocation of taxicab resources to potential passengers, each licensing district in which a particular company operates is further broken down by the company’s mapping software into virtual‘zones’. When a driver enters a particular zone, they are added to a list of available drivers in which the drivers are ranked in order of entry into that zone - the most recent driver to enter the zone is placed at the bottom of the list. When a passenger requests a journey with that company, the driver at the top of the list is initially offered the job. This is done to ensure fair booking allocation to the drivers within the company.

However, this allocation process means that drivers are not always located in an optimal location relative to the requesting passenger when the request is placed with the company - the drivers will almost certainly have moved around within the zone since they entered it initially and were added to the list. This results in an inefficient system, causing a large amount of what is colloquially referred to in the art as‘dead time’ - i.e. the time spent by a taxi cab driving to a passenger’s desired pickup location. A significant amount of fuel is also usually needlessly expended by cabs in driving to a passenger’s pickup location during this dead time. This has significant economic ramifications for cab drivers since the fuel expended driving to a pickup location is typically not chargeable to the passenger. There are also significant environmental ramifications associated with dead time, especially in densely populated metropolitan areas, where high fuel emissions and fuel consumption is undesirable.

These issues are further compounded by the fact that drivers will go back to the zone which they feel produces the best chance of receiving a booking. This process leaves black spots across a district and also adds to pollution as drivers will move from zone to zone trying to win the most work.

In any given district, there can be anywhere between 15 companies (for a small district) and 300 companies (for a large city like London) all using the above methods to allocate bookings to their drivers. The scale of the problem is therefore enormous.

It is an aim of the present invention to address one or more of the disadvantages associated with the prior art. In particular it is an object of the present invention to provide an improved vehicle management system.

SUM MARY OF THE INVENTION

According to a first aspect of the present invention there is provided a computer-implemented method of identifying one or more available vehicles in response to a user generated query, comprising: receiving, at an input of a server, a request for a vehicle, the request comprising a first geographic location; receiving, at the input, location information for a plurality of different vehicles; determining, at a processor of the server, for each one of the plurality of different vehicles, a search zone calculated with respect to a vehicle’s location in dependence on a first variable distance parameter, the search zone defining a set of geographic locations; and identifying, at the processor, one or more of the plurality of different vehicles whose search zone comprises the first geographic location; and forwarding, from an output of the server, a list of the one or more identified vehicles for display to a user terminal.

The present invention provides a computer-implemented method that is implemented on a server comprising an input, processor and output that ensures that only the vehicles that are appropriately located relative to the user (e.g. sufficiently close [by distance or time] to the user such that their search zone encompasses the user’s desired pickup location) are identified for display on the user’s terminal. This reduces the amount of dead time involved in any given journey with a consequent improvement in the associated economic and environmental ramifications of dead time. The term“search zone’’ effectively relates to a predefined area or region around the vehicle’s location within which the vehicle driver is willing to travel to pick up the user. It should also be noted that the search zone may take various different forms: the simplest being a circular area defined by a single radius; other forms of the search zone include a bounding box, or an irregular area defined with respect to the vehicle geographical location. Furthermore, whilst the search zone would generally be two- dimensional (i.e. define an area) in implementations involving vehicles such as taxis, it may also take the form of a three-dimensional search‘volume’. The“first geographic location” may comprise a desired pickup location for a user or a destination location.

The computer-implemented method may comprise receiving, at the input, a selection from the user terminal, the selection indicating one of the one or more vehicles comprised in the list whose search zone comprises the first geographic location; and outputting, from the output, a confirmation signal to the selected vehicle, the confirmation signal comprising the first geographic location.

The computer-implemented method may further comprise receiving, at the input, the request for the vehicle, the request comprising a second variable distance parameter defined by the user; determining, at the processor, a second search zone calculated with respect to the user’s location in dependence on the second variable distance parameter, the second search zone defining a second set of geographic locations; identifying, at the processor, one or more of the plurality of different vehicles whose search zone comprises the first geographic location, and whose position is comprised in the second search zone; and forwarding, from the output, a list of the one or more identified vehicles for display to the user terminal. In such embodiments a double search zone is provided in which the user defines a search zone and the vehicle defines a search zone and potential fares relate to those vehicles whose position lies within the user’s search zone, and whose search zone comprises the desired user pickup location.

Advantageously, the use of a pair of search zones or regions limits the number of vehicles that are identified as being‘available’ for provision to the requesting user. This results in a corresponding decrease of the number of database records that need to be processed to obtain details of the‘available’ vehicles, which details are also provided to the user. The above-described computer-implemented method is therefore rendered more computationally efficient by a reduction in the number of records that need to be processed in response to each vehicle request. It is also noted that there is a“green” advantage associated with the present invention, and in particular with the double search zone embodiment, in that only vehicles that are appropriately located relative to the user are identified to the user.

Each vehicle may be associated with a database record specifying one or more first parameters associated with the vehicle, and the computer-implemented method may comprise receiving, at the input, the request for a vehicle, the request comprising a user- defined second parameter; identifying, at the processor, one or more vehicles whose database record comprises one or more first parameters consistent with the user-defined second parameter; and forwarding, from the output, the list of one or more identified vehicles for display to the user terminal.

The one or more first parameters may comprise, for example, pricing information that will be used to determine the cost of the journey, the estimated time that will be required for the vehicle to reach the user’s desired pickup location, or geographic information that will be associated with the licensing particulars of the vehicle (i.e. specific districts in which the vehicle is licensed to operate). Advantageously, matching pre-defined user and vehicle parameters with one another enables the most appropriate selection of vehicles to be provided to the user.

The user-defined second parameter may comprise a second geographic location, and at least one of the one or more first parameters may comprise information indicative of a geographic area of operation of the associated vehicle, and the computer-implemented method may comprise identifying, at the processor, the one or more vehicles whose geographic area of operation comprises the second geographic location. In the event that the first geographic location comprises a pickup location then the second geographic location may comprise the destination location and this feature may enable a determination to be made whether the vehicle can drop off a fare at the specified destination location in light of cab licensing restrictions. In the event that the first geographic location comprises the desired destination location then the second geographic location may define the desired pickup location.

The second geographic location may comprise a user-desired destination location.

Each vehicle may be associated with a database record specifying a geographic area of operation associated with the vehicle, and the computer-implemented method may comprise determining, at the processor, for each identified vehicle whose search zone comprises the first geographic location, if the vehicle’s associated geographic area of operation comprises the first geographic location; and forwarding, from the output, a list of the identified one or more vehicles whose associated geographic area of operation comprises the first geographic location, for display to the user terminal.

The geographic area of operation effectively corresponds to the region/district in which the vehicle is licensed to operate, and to pick up passengers. The above-described computer- implemented method therefore ensures that before the list of selected vehicles is provided to the user, a check is performed by the back-end server to ensure that only vehicles that are licensed to operate in the district containing the desired pickup and/or destination location(s) will be selected. This ensures that the user is only provided with a selection of vehicles that are definitely able to (legally) carry out the booked journey should they be chosen.

The first geographic location may comprise a user-desired pickup location.

The location information for the plurality of different vehicles may be received at periodic temporal intervals, and the steps of determining the search zone for each one of the plurality of different vehicles and identifying, at the processor, the one or more vehicles may be repeated periodically; and the computer-implemented method may comprise updating the forwarded list periodically.

The above-described computer-implemented method ensures that the list of selected vehicles is constantly refreshed and updated, to take into account dynamically changing properties of the vehicle. For example, if a vehicle is in motion whilst the user is making their decision, that vehicle may have travelled a sufficient distance during this time so as to no longer be within the appropriate distance of the user (as defined by the vehicle’s search zone). Such a vehicle would therefore no longer be eligible to conduct the journey, even if they were selected by the user. If an unavailable vehicle were selected by the user, this could delay the allocation process since the back-end server may have to carry out the entire method again; in some cases, it may even require the user to re-submit their original enquiry, which would be undesirable and time-consuming for both the user and the server. Advantageously, the periodic refresh and iteration of the step of assessing the search zone of vehicles relative to the user’s location means that there will be a much reduced chance of the user accidentally selecting an unavailable vehicle.

The first and second parameters may comprise any one of a geographic region of operation; an estimated cost for a journey; an estimated time for the vehicle to arrive at the first and/or second geographic location.

According to a second aspect of the present invention there is provided a server for identifying one or more available vehicles in response to a user generated query, the server comprising: at least one input configured to receive a request for a vehicle, the request comprising a first geographic location; and location information for a plurality of different vehicles; a processor configured to: determine, for each one of the plurality of different vehicles, a search zone calculated with respect to a vehicle’s location in dependence on a first variable distance parameter, the search zone defining a set of geographic locations; and identify one or more of the plurality of different vehicles whose search zone comprises the first geographic location; an output configured to forward a list of the one or more identified vehicles for display to a user terminal

The processor may be configured to: receive the request for the vehicle, the request comprising a second variable distance parameter defined by the user; determine a second search zone calculated with respect to the user’s location in dependence on the second variable distance parameter, the second search zone defining a second set of geographic locations; identify one or more of the plurality of different vehicles whose search zone comprises the first geographic location, and whose position is comprised in the second search zone; and the output is configured to forward a list of the one or more identified vehicles for display to the user terminal.

The at least one input may be arranged to receive the location information for the plurality of different vehicles at periodic temporal intervals, and the processor may be arranged to determine the search zone for each one of the plurality of different vehicles and identify the one or more vehicles periodically; and the processor may be arranged to update the forwarded list periodically. The at least one input may be arranged to receive a request to vary a parameter related to a vehicle.

The invention extends to a user terminal comprising an input arranged to receive a user generated query for a vehicle and to receive a list of one or more identified vehicles from the server for identifying one or more available vehicles in response to a user generated query, a processor arranged to receive the user request and to forward, via an output, the user request to the server for identifying available vehicles.

The invention also extends to a vehicle terminal comprising an input arranged to receive notification of a user to pickup, a processor arranged to process received inputs from the server/system for identifying one or more available vehicles in response to a user generated query and/or inputs received via the input from the vehicle user and an output arranged to output vehicle related parameters to the server/system for identifying one or more available vehicles in response to a user generated query.

The invention extends to a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of the first aspect of the invention. The invention extends to a computer-readable data carrier having stored thereon the computer program as described above.

Within the scope of this application it is expressly intended that the various aspects, embodiments, examples and alternatives set out in the preceding paragraphs, in the claims and/or in the following description and drawings, and in particular the individual features thereof, may be taken independently or in any combination. That is, all embodiments and/or features of any embodiment can be combined in any way and/or combination, unless such features are incompatible. The applicant reserves the right to change any originally filed claim or file any new claim accordingly, including the right to amend any originally filed claim to depend from and/or incorporate any feature of any other claim although not originally claimed in that manner.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 is a schematic illustration of a system, comprising a user, one or more hire vehicles, and a backend server, in accordance with an embodiment of the invention, and used to identify available hire vehicles for the user;

Figure 2 is a schematic plan view of an intersection, a user, and three vehicles, and illustrates each hire vehicle may vary its search radius, which is used by the backend server of Figure 1 in identifying available hire vehicles;

Figure 3 is a process flow chart illustrating a method adopted by the system of Figure 2 for identifying available vehicles for the user of Figure 1 ;

Figures 4 to 9 are screenshots illustrating various aspects of the present invention, when embodied and implemented in a proprietary mobile application. Specifically, the screenshots in Figures 4 and 5 illustrate aspects of the mobile application that would be displayed to a potential passenger using the application, whilst Figures 6 to 8 illustrate aspects of the mobile application that would be displayed to a driver using the application.

DETAILED DESCRIPTION

Embodiments of the present invention are directed to an improved vehicle discovery system and method, and may be used to identify vehicles for hire for a user, dependent on both the user’s desired pickup location and the hire vehicles’ geographic locations relative to the desired pickup location. Identification of vehicles may also factor in cab licensing restrictions.

The present method and system are particularly advantageous for use by cabs, and so in the ensuing description the embodiments of the invention will be described with respect to this illustrative, non-limiting implementation. Within the context of the present disclosure, the term cab is used to refer to any vehicle for hire. In some embodiments the cab may comprise a driver, or be a self-driving vehicle. Accordingly, non-limiting examples of cab, as used within the present context, are: Hackney carriages; private hire vehicles, taxibuses, limousines, and autonomous self-driving vehicles.

However, the embodiments described herein could instead be equally applicable to other implementations that are not necessarily associated with taxi cabs or with passenger pick-up. For example, parcel pickup and delivery, and/or the use of autonomous or driverless vehicles, could also benefit from implementation of some of these embodiments. An exemplary use scenario describing how methods and systems in accordance with embodiments of the present invention may be used, will now be described with reference to the schematic system diagram of Figure 1.

Figure 1 provides an overview of a system used in accordance with embodiments of the invention, to identify available cabs in response to a user request. A user 1 wishing to secure a cab for transportation to a desired destination location, inputs the desired destination location into a mobile device, such as a smartphone 3. The smartphone 3 may be configured with an application arranged to generate a request message for processing by a remote server 5. The request message may comprise information associated with the user’s pickup location and information associated with the desired destination location. It may also comprise certain other parameters specified by the user, such as desired pickup time or number of passengers that are to be picked up. The request message is forwarded to the remote server 5 from the user’s smartphone 3, via a shared communications network 7, which may comprise a mobile telecommunications network 9.

The server 5 may comprise a processor 1 1 , and memory 13, configured to process the received request message and to generate an associated search query, for searching an operatively connected hire vehicle database 15. The hire vehicle database 15 (interchangeably referred to as the cab database) comprises one or more database records 17, associated with all cabs 19, 21 , 23 implementing the present method. In this regard, cabs that implement the present method, and are available for hire by a user using their smartphone 3 as described, may also be referred to as cab subscribers. Each cab subscriber 19, 21 , 23 may have an associated database record 17 maintained in the hire vehicle database 15, accessible to the remote server 5.

Each database record 17 may comprise data associated with or corresponding to the associated cab 19, 21 , 23, including current geographical location data of the cab, in addition to preference data defined by the cab subscriber. Such preference data includes parameters that can be customised by and are specific to the cab subscriber. For example, such parameters may include the number of passengers that the cab subscriber is willing to transport, whether the cab subscriber is able to provide disabled access, and any specific location and/or timing restrictions regarding pickup/drop-off that the cab subscriber may have.

The database records 17 enable the server 5 to determine and monitor the current geographical location of each subscribed cab 19, 21 , 23. One way in which this may be achieved, is by using existing in-built GPS functionality comprised in each subscribed cab 19, 21 , 23, or similarly by using in-built GPS functionality associated with a smartphone of a driver of a subscribed cab 19, 21 , 23. Provided that the subscribed cab’s GPS location data is periodically provided to the server 5, then it is possible to monitor the subscribed cab’s location.

To aid the server 5 in distinguishing between the subscribed cabs 19, 21 , 23, each cab 19, 21 , 23 may be associated with a unique identifier, which is provided in all data exchanges with the server 5, thereby enabling the server 5 to uniquely identify, and distinguish between different subscribed cabs 19, 21 , 23. In turn, the unique identifier may also be used to identify and maintain each subscribed cab’s 19, 21 , 23 associated database record 17.

Each subscribed cab 19, 21 , 23 may define and select service customisation parameters unique to it, which customisation parameters may be stored in the subscribed cab’s associated database record 17. For example, each subscribed cab 19, 21 , 23 may define a maximum search threshold radius, which defines the maximum distance the cab is willing to drive from its current geographical location to pick up the user 1. In addition, each cab may also establish their pricing. For example, the pricing may be expressed in terms of a cost per unit distance charged to the user 1 should the user hire the cab for a journey.

These customisation parameters may also be altered dynamically by the driver to reflect changing conditions experienced by the driver at their particular location. For example, the driver may alter their maximum search threshold radius depending on their location and/or on the time of day - specifically, they may reduce their radius when operating in a more densely populated area or during peak pickup periods; they may also increase their radius during quiet periods or when operating in a more rural area.

Once the server 5 has received the request message from the user 1 , the server 5 generates a query message for querying the cab database 15, in order to identify available cabs and associated costs for taking the user 1 to their desired destination location. In particular, the query message is used to identify specific vehicle database records 17 of available subscribed cabs 19, 21 , 23, which satisfy the parameters of the query message, and in particular the parameters (such as pickup and/or destination location and details) established by the user 1 in their request message.

Once the available vehicles satisfying the parameters of the query message have been identified, information associated with identified cabs, including fare information, is returned to the user’s 1 smartphone 3 for display. Examples of how this information may be displayed to the user will be provided subsequently with reference to Figures 4 to 9.

In certain embodiments the user 1 is provided with a list of available cabs that satisfy the parameters defined in the user’s request message, and the associated cost for completing the user’s desired journey. (The available cabs may also be presented with reference to their estimated time of arrival at the user’s location/pickup location. The parameters that the available cabs may satisfy may also include legal compliance parameters.) The user may then select the preferred listing from the displayed results, and a data confirmation message confirming the user’s selection is sent back to the server 5. The server 5 subsequently sends a confirmation message to the selected vehicle using its unique identifier. Alternatively, the user’s selection may be directly forwarded to the selected vehicle, in which case means for directly contacting the identified vehicles (e.g. the vehicle driver’s mobile phone number or a proxy telephone number to maintain the privacy of the driver) are provided by the server 5, when returning the results of the user’s query to the user’s smartphone 3 for display. The selected cab is informed of the user’s selection, and proceeds to pick up the user at the defined pickup location, and subsequently delivers the user to the desired destination location.

Figure 2 provides a visual representation of how the query message generated by the server 5 is used to query the cab hire database 15, so as to determine the appropriate cab subscribers for a particular query.

In particular, Figure 2 is a plan view illustration of the user 1 standing at a first geographical location 25, and desiring to hire a cab. As described previously, the user 1 inputs the desired destination location in their smartphone 3, and issues the request message to the server 5. Various options for inputting this information may be provided, for example, using a GPS location associated with the current location of the smartphone 3, entering the name of a location that has been pre-programmed into the application or searching for a location (e.g. by postcode or zipcode). The server 5 then generates the corresponding query message and identifies the database records 17 associated with the available cabs 27, 29, 31. As mentioned previously, each subscribed cab may define their maximum search threshold radius. These are respectively denoted Ri, R₂, R3 in Figure 2, and each radius traces out a cab search zone (also referred to interchangeably as a search region), defining the maximum area within which they are willing to drive to pick up a passenger. For example, the first available cab’s 27 search zone/region is denoted 33, the second available cab’s 29 search zone/region is denoted 35, and the third available cab’s 31 search zone/region is denoted 37. The search of the cab database records 17 therefore comprises identifying the available cabs 27, 29, 31 whose associated search zones/regions comprise or intersect with the defined pickup location of the user 1 - the cabs 27, 29, 31 that satisfy this requirement are referred to as the‘available cabs’.

As has been previously mentioned, it is important to appreciate that each cab’s defined maximum search threshold radius is variable, and may be specified by the associated cab driver. This is typically stored as a parameter in the associated cab database record 17. In addition, it should be appreciated that whilst the search radius is referred to as such and the cab search zone/region is shown as being generally circular in Figure 2, this reference is simply used for ease of illustration. In practice, the search zone/region may not be circular, but could take the form of a bounding box or some other (possibly irregular) shape. There may therefore not necessarily be a single search‘radius’ as such in the conventional mathematical sense. It should also be appreciated that the resultant search zone/region that can overlap with the passenger’s location may not necessarily be circular, but may be restricted for example by other factors that could be defined by external entities (e.g. the licensed area of the cab).

Furthermore, it is to be appreciated that a cab search zone/region is dependent on the associated cab’s current geographical location. As the cab moves, for example whilst it is in motion, the actual geographical area that is covered by the cab’s search zone/region will change. Therefore, the process of identifying available cabs (identifying those cabs whose search zone/region comprises the pickup location of the user 1) comprises querying and analysing a dynamically varying quantity. To help mitigate for this, the current location associated with each subscribed cab is periodically updated to the associated cab database record 17. For example, this may comprise the cab forwarding its location information to the vehicle database 15 one or more times per minute. In certain embodiments, the cabs 27, 29, 31 may be configured with location tracking devices to help maintain accurate up to date location information for each cab.

An advantage associated with enabling each cab to define and to vary its associated maximum search threshold zone/region is to reduce the afore-mentioned‘dead time’ spent by the cab driving to a passenger’s desired pickup location. Specifically, enabling driver control of the maximum search threshold radius Ri, R₂, R3 not only allows drivers to reduce the economic losses associated with this dead time, but also enables drivers to improve their impact on the environment by reducing the amount of fuel expended and the accompanying fuel emissions. This is particularly advantageous in densely populated metropolitan areas, where reducing fuel emissions is an important priority. Figure 3 is a process flow chart illustrating the method carried out by the server 5 in identifying the available cabs 27, 29, 31.

The method is initiated at Step 301 upon receipt of a cab enquiry from the user 1 , and more specifically from the user’s smartphone 3. In certain embodiments, at least some of the method steps may be carried out via or in combination with a dedicated proprietary application locally stored on the user’s smartphone 3. The cab enquiry comprises information enabling the desired destination location and the pickup location to be determined. For example, whilst the desired destination location information is likely to be specified by the user 1 , the pickup location may relate to the user’s current location and may be automatically generated by the user’s smartphone 3 using available location tracking means, such as in-built GPS functionality of the smartphone 3.

The server 5, and in particular the processor 11 may generate a search query specifying at the very least the user’s desired pickup location, and query at Step 303 the cab database 15, in order to identify the cabs 27, 29, 31 whose search zones/regions comprise or intersect with the desired pickup location. At Step 305, the database records 17 of the available cabs 27, 29, 31 are identified. Once the database records 17 of the available cabs 27, 29, 31 have been identified, fare information is obtained at Step 307 for the identified database records 17. This information is then used to estimate the total fare that each available cab 27, 29, 31 will charge the user for the journey to the desired destination location (As an alternative the information may be used to calculate a total fare that each available cab will charge). Once the available cab information has been obtained and the fare estimates calculated, this information is sent from the server 5 to the user’s smartphone 3, where it is displayed for selection on the user’s smartphone 3, at Step 309.

Optionally, the processor 11 may also calculate an estimated time of arrival (ETA) of the vehicle at the pickup location, and forward the calculated ETA to the user for display on their smartphone 3. This will allow the user to make a more informed choice when selecting a vehicle to use. This calculation will be based on an analysis of the cab’s current geographical location in relation to the desired pickup location, and may also take into account current/expected traffic conditions.

At Step 311 it is determined if a predefined time period threshold has expired. Expiry of this time period threshold may be monitored locally by the user’s smartphone 3 running the proprietary application, or it may be monitored remotely by the server 5. The object of monitoring this predetermined time period threshold is to ensure that the user 1 is provided with up-to-date available vehicle information. This is particularly important as the location of the available vehicles 27, 29, 31 varies relative to the user’s desired pickup location, when the vehicles are in motion.

Therefore, to ensure that the displayed available vehicle information is accurate, Steps 303 through 311 are repeated upon expiry of the time period threshold. Repeating Steps 303 through 311 is an iterative process, which is repeated every time the threshold time period expires. This ensures that the query results are refreshed sufficiently frequently to ensure the accuracy of the displayed results. In certain embodiments the time period threshold may be of the order of several seconds. It will be appreciated that as the vehicles will likely be on the move whilst this process is iterated, it is possible for a given vehicle to travel over a sufficient distance in this time period such that that vehicle’s search zone/region no longer comprises/intersects with the desired pickup location at the next iteration of method Steps 303 to 305. Similarly, a vehicle that had previously been too far away from the user 1 to be identified in a previous iteration of Step 305 may have travelled sufficiently close to be identified as available for pickup in a subsequent iteration. Cabs may therefore appear or disappear from the list after each refresh.

At Step 313 it is determined if a user selection of one of the displayed results has been received. If no selection has been received, then the method returns to Step 311. If instead a selection has been received, then it is determined if the vehicle corresponding to the user selection is still available, at Step 315. This comprises determining if the user’s desired pickup location still falls within the search zone/region of the selected cab. If the selected cab is no longer available at the time that the user 1 makes their selection, then the method returns to Step 31 1 , and (once the time period threshold has expired) Steps 303 through 311 are repeated where required. If instead it is determined that the selected cab is available, then a fare notification message is sent to the selected cab at Step 317, to notify that the cab has been commissioned by the user 1. The commissioned cab then proceeds to pick up the user 1 at the desired pickup location.

In the above description of the process the method returns from Step 313 to Step 311 and, once the time period threshold has expired, Steps 303 through 311 are repeated. In an alternative arrangement, refreshed data may be pushed from the server 5 to the user’s smartphone 3 indicating the available cab information (including fare estimates calculated) where it is displayed for selection on the user’s smartphone 3, at Step 309. In a further alternative arrangement, the return of the method to Step 31 1 may force a refresh instead of have to wait out the time period threshold. In accordance with certain embodiments of the invention, the server 5 may forward information associated with the geographic locations of users that have issued query messages to subscribed cabs. For example, this information may be presented in the form of a geographic heat map, displaying on a map the geographic location of users requesting cabs (see also Figure 9). In this way subscribed cabs may be made aware of the geographic location with the greatest demand for cabs. This information may then be used by the subscribed cabs to vary their maximum threshold search radii, or any other cab associated parameter such as fares.

Figures 4 to 8 show screenshots illustrating non-limiting examples of the type and format of information that may be displayed to a user (Figure 4 and 5), and to a driver (Figures 6 to 8) utilising a proprietary mobile application that is implementing the method described above.

Referring first to Figure 4, the seven screenshots (labelled A to G) illustrate in chronological order the information that might be displayed to the user 1 throughout the process of requesting and obtaining a cab ride between desired pickup and destination locations. Figure 4A illustrates the beginning of the process where the user inputs the information that forms the cab enquiry used by the server to begin the process 300. Specifically, the user has entered their desired journey parameters, defined by the start (pickup) 401 and end (destination) 403 locations. This information is sent to the server 5 and used to query the cab database for available cabs. Whilst this is occurring (i.e. during method steps 303 to 307 carried out by the server), an intermediate‘processing’ screen (such as that shown in Figure 4B) may be displayed on the user’s smartphone 3 to indicate that processing of the user’s request is taking place. Subsequently, the step of displaying the identified cab(s) occurs - as shown in Figure 4C, the ETA and the pricing of the available cab(s) is displayed to the user.

Once the user has made their vehicle selection, a summary comprising the journey details along with brief details of the vehicle, ETA and pricing is displayed to the user as a confirmation screen (shown in Figure 4D). Once the user has confirmed their selection (i.e. clicked the ‘start journey’ button in Figure 4D), the application may provide the functionality to track the location of the selected vehicle 405 (as shown in Figure 4E), providing details of the vehicle’s location and means for contacting and/or identifying the driver and vehicle. This tracking functionality may also extend to tracking the progress of the journey between pickup 401 and destination 403 locations, after the user has entered the cab - this is shown in the screenshot of Figure 4F. Finally, once the journey has been completed, the user may be provided with a summary of their journey and vehicle details, as illustrated by Figure 4G. This information may subsequently be saved to the user’s profile in that application (if one exists), allowing the user to track details of previous journeys made using the application functionality.

Figure 5 shows screenshots of various aspects of an example user profile that has been created in the application. An overview of these aspects is provided in Figure 5A, with further details of some of these aspects being shown in Figures 5B to 5D. For example, the user profile may contain certain pieces of identifying information relating to the user (such as their name, and contact details, as shown in Figure 5B). This information allows the server 5 to identify users accessing their services. The user’s journey history - i.e. details of each journey that has been carried out using the application services - may also be saved in the user profile, as shown in Figure 5C. Finally, various payment methods may be stored and associated with the user profile: as shown in Figure 5D, details of a specific payment card that the user wishes to use to pay for journeys booked via the application can be saved for efficient booking.

Now referring to Figures 6 and 7, there are shown corresponding screenshots that might be displayed to the driver of a cab subscriber who is using the proprietary mobile application. Figures 6A to 6E illustrate in generally chronological order the information that might be displayed to this driver throughout the process of providing a taxi service between desired pickup and destination locations.

Figures 6A and 6B illustrate various parameters that can be set by the vehicle driver 601 - most notably the pricing and the search radius 603 (along with the associated search zone/region) - when the driver 601 is advertising their availability to take on a job. It will be appreciated that these parameters may be dynamically varied by the driver 601 (as illustrated by the sliding tabs provided in the display) in order to provide a more competitive offer to a potential passenger. A further option that is also available to the driver 601 is to “go unavailable”, which will effectively remove them from consideration for subsequent jobs that are being requested (even if they would have been eligible to accept a job by virtue of the desired pickup location falling within the defined search radius 603).

Figures 6C and 6D are roughly equivalent to the screenshots shown in Figures 4E and 4F. Figure 6C shows the information that might be displayed to the driver 601 once the user 1 has selected their vehicle for the journey but prior to the driver 601 arriving at the user’s desired pickup location 605; it also provides a navigation option to the driver, allowing them to navigate the appropriate route for the journey. Once the driver 601 arrives at the desired pickup location 605, the“passenger on board” option can be selected, and the application will then transition to the next phase - as shown in Figure 6D - enabling the vehicle to be tracked during the booked journey. Finally, once the journey has been completed (and the driver has indicated this by selecting the“complete” option), the driver may be provided with a summary of their journey details, as illustrated by Figure 6E.

Figure 7 shows screenshots of various aspects of an example driver profile that has been created in the application. An overview of these aspects is provided in Figure 7A, with further details of some of these aspects being shown in Figures 7B and 7C. For example, as with the user profile illustrated in Figure 5A, the driver profile of Figure 7B may contain certain pieces of identifying information relating to the driver and their vehicle (such as the driver’s name, contact details, driving credentials, and identifying credentials etc.). Such information allows the server 5 to identify drivers using the system. Figure 7C displays example settings that can be defined and changed by the driver, which are used to generate the dynamically-changeable parameters displayed in Figure 6A and 6B.

Figure 8 illustrates an example of how a driver 601 of a vehicle may dynamically vary their maximum threshold search radius 803 in order to have the opportunity to win additional work. As may be seen in Figure 8A, the displayed image for the driver in question shows their current maximum threshold search radius 803 (the search zone/region805 is shown as a circle centred on the vehicle’s current location); the desired pickup location 807 of a user enquiry - indicated by the circle near“Duddeston” - is also illustrated. It is apparent from the left-hand side of Figure 8A that the driver’s current search zone/region 805 does not comprise the desired pickup location 807 of the user, and therefore the driver 601 is not considered eligible or available - the user therefore is not given the option to book that driver 601 for their journey.

However, as is illustrated in the left-hand side of Figure 8B, the driver 601 may dynamically vary their search radius 809 such that the associated search zone/region 811 just intersects with//encompasses the desired pickup location 807. The server 5 will then (at the next refresh) determine that the cab is available to pick up the passenger, and will include that vehicle’s pricing and ETA details in the list of available options displayed to the user. This is illustrated in the right-hand side of Figures 8A and 8B, where the corresponding screen that is displayed to the potential passenger is shown - after the driver 601 has expanded their search radius 809 in Figure 8B to intersect with the desired pickup location 807, the pricing and ETA associated with that driver 601 is then displayed as an option to the requesting user for selection. In some embodiments of the invention, in addition to using a maximum threshold search radius 803, 809 (and associated search zone/region 805, 811) associated with the each vehicle and determining if that search radius 803, 809 intersects with the user’s desired pickup location 807, an additional search radius associated with the user themselves can also be used to select available vehicles. This additional search radius (which may be referred to as the‘user search radius’) may be centred on the user’s desired pickup location 807, and defines a corresponding‘user search zone/region- i.e. the area within which the user is willing to accept an offer from a vehicle. This will also roughly correspond to the maximum amount of time that a user is willing to wait for a selected vehicle to reach their desired pickup location.

In such embodiments, the defined user search radius may be sent to the server 5 as part of the enquiry in Step 301. In this case, the server will then only identify in Step 305 available cabs as being those which have a vehicle search radius that intersects or comprises the actual pickup location with the user’s search radius - i.e. the user’s and vehicle’s search zones/regions overlap with one another. The use of such a ‘double-radius’ approach represents an increase in computational efficiency since it reduces the number of cab database records 17 that need to be processed by the server 5 in Step 307. This approach is also beneficial to the requesting user since it means that they will only be presented with a selection of cabs that they would realistically select.

In some embodiments, additional processing steps may be carried out by the server 5 in the course of implementing Steps 303 to 307 of the method shown in Figure 3. For example, the server may check the licence of the vehicles identified in Step 305 (i.e. extract the licence data from the database record of a vehicle) and confirm whether (a) the driver of that vehicle is licensed to pick up passengers at all, and/or (b) whether the vehicle is licensed to operate in the zone in which the desired pickup location is located. Alternatively, this licensing information may be obtained via access by the server 5 to database records that are stored and maintained by the relevant licensing authority in that zone.

Figure 9 illustrates a further example of how a driver of a vehicle may dynamically vary their maximum threshold search radius in order to have the opportunity to win additional work. As may be seen in Figure 9A the displayed image for the driver 601 in question shows their current maximum threshold search radius 901 (the search zone/region 903 is shown as a circle centred on the vehicle’s current location); the desired pickup location of nearby users - indicated by the hotspots 905, 915 near the“Chinese Quarter” and also“Coventry Road” - is also illustrated. It is apparent that the driver’s current search zone/region 903 does not comprise any of the desired pickup locations 905, 915 of the users, and therefore the driver 601 is not considered eligible or available - the users therefore are not given the option to book that driver 601 for their journey.

In Figure 9B, the driver 601 of the vehicle has expanded their search radius 907 such that the hotspot 905 near the“Chinese Quarter” is now within the vehicle’s search zone 909. The driver’s current pricing plan is shown at the bottom of Figure 9B and their average listing position on user’s devices is shown in the top right corner (a listing position of 8.6 is shown). It is also noted that the driver 601 is listed in 3 lists indicating that the hotspot 905 actually encompasses three potential pickups.

In Figure 9C, the vehicle search zone 913 has been expanded further such that both hotspots 905, 915 are encompassed by the vehicle’s search radius 911. It can be seen from the average position indicator that the driver’s vehicle is now listed in four passenger pickup locations. The driver’s pricing plan is unchanged but they are now listed at an average position of 7.1 in the four passenger lists.

In Figure 9D, the driver 601 has responded to the heatmap pricing feedback and has lowered their price which has lifted them to an average position of 1.0 in the four lists that they appear in. This gives the driver a higher chance of winning work all without having to move their vehicle.

It will be appreciated that various changes and modifications can be made to the present invention without departing from the scope of the present application.

Claims

1. A computer-implemented method of identifying one or more available vehicles in response to a user generated query, comprising:

receiving, at an input of a server, a request for a vehicle, the request comprising a first geographic location;

receiving, at the input, location information for a plurality of different vehicles;

determining at a processor of the server, for each one of the plurality of different vehicles, a search zone calculated with respect to a vehicle’s location in dependence on a first variable distance parameter, the search zone defining a set of geographic locations; and identifying, at the processor, one or more of the plurality of different vehicles whose search zone comprises the first geographic location; and

forwarding, from an output of the server, a list of the one or more identified vehicles for display to a user terminal.

2. The computer-implemented method of Claim 1 , comprising:

receiving, at the input, a selection from the user terminal, the selection indicating one of the one or more vehicles comprised in the list whose search zone comprises the first geographic location; and

outputting, from the output, a confirmation signal to the selected vehicle, the confirmation signal comprising the first geographic location.

3. The computer-implemented method of any preceding claim, comprising:

receiving, at the input, the request for the vehicle, the request comprising a second variable distance parameter defined by the user;

determining, at the processor a second search zone calculated with respect to the user’s location in dependence on the second variable distance parameter, the second search zone defining a second set of geographic locations;

identifying, at the processor, one or more of the plurality of different vehicles whose search zone comprises the first geographic location, and whose position is comprised in the second search zone; and

forwarding, from the output, a list of the one or more identified vehicles for display to the user terminal.

4. The computer-implemented method of any preceding claim, wherein each vehicle is associated with a database record specifying one or more first parameters associated with the vehicle, and the method comprises:

receiving, at the input, the request for a vehicle, the request comprising a user-defined second parameter;

identifying, at the processor, one or more vehicles whose database record comprises one or more first parameters consistent with the user-defined second parameter; and

forwarding, from the output, the list of one or more identified vehicles for display to the user terminal.

5. The computer-implemented method of Claim 4, wherein the user-defined second parameter comprises a second geographic location, and at least one of the one or more first parameters comprises information indicative of a geographic area of operation of the associated vehicle, and the method comprises:

Identifying, at the processor, the one or more vehicles whose geographic area of operation comprises the second geographic location.

6. The computer-implemented method of Claim 5, wherein the second geographic location comprises a user-desired destination location.

7. The computer-implemented method of any preceding claim, wherein each vehicle is associated with a database record specifying a geographic area of operation associated with the vehicle, and the method comprises:

determining, at the processor, for each identified vehicle whose search zone comprises the first geographic location, if the vehicle’s associated geographic area of operation comprises the first geographic location; and

forwarding, from the output, a list of the identified one or more vehicles whose associated geographic area of operation comprises the first geographic location, for display to the user terminal.

8. The computer-implemented method of any preceding claim, wherein the first geographic location comprises a user-desired pickup location.

9. The computer-implemented method of any preceding claim, wherein the location information for the plurality of different vehicles is received at periodic temporal intervals, and the steps of determining the search zone for each one of the plurality of different vehicles and identifying the one or more vehicles are repeated periodically; and the method comprises: updating the forwarded list periodically.

10. The computer-implemented method of Claim 5, wherein the first and second parameters comprise any one of:

i. a geographic region of operation

ii. an estimated cost for a journey

iii. an estimated time for the vehicle to arrive at the first and/or second geographic location.

11. A server for identifying one or more available vehicles in response to a user generated query, the server comprising:

at least one input configured to receive a request for a vehicle, the request comprising a first geographic location; and location information for a plurality of different vehicles;

a processor configured to:

determine, for each one of the plurality of different vehicles, a search zone calculated with respect to a vehicle’s location in dependence on a first variable distance parameter, the search zone defining a set of geographic locations; and

identify one or more of the plurality of different vehicles whose search zone comprises the first geographic location;

an output configured to forward a list of the one or more identified vehicles for display to a user terminal

12. A server as claimed in Claim 11 , wherein the processor is configured to:

receive the request for the vehicle, the request comprising a second variable distance parameter defined by the user;

determine a second search zone calculated with respect to the user’s location in dependence on the second variable distance parameter, the second search zone defining a second set of geographic locations;

identify one or more of the plurality of different vehicles whose search zone comprises the first geographic location, and whose position is comprised in the second search zone; and the output is configured to forward a list of the one or more identified vehicles for display to the user terminal.

13. A server as claimed in Claim 11 or 12, wherein the at least one input is arranged to receive the location information for the plurality of different vehicles at periodic temporal intervals, and the processor is arranged to determine the search zone for each one of the plurality of different vehicles and identify the one or more vehicles periodically; and the processor is arranged to update the forwarded list periodically.

14. A server as claimed in any one of Claims 11 to 13, wherein the at least one input is arranged to receive a request to vary a parameter related to a vehicle.

15. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of any one of Claims 1 to 10.

16. A computer-readable data carrier having stored thereon the computer program of Claim 15.