GB2367979A

GB2367979A - Mobile Service Request System

Info

Publication number: GB2367979A
Application number: GB0024637A
Authority: GB
Inventors: Oliver Lynch
Original assignee: WAPACAB COM Ltd
Current assignee: WAPACAB COM Ltd
Priority date: 2000-10-06
Filing date: 2000-10-06
Publication date: 2002-04-17
Also published as: GB0024637D0

Abstract

A mobile service request system, for example, a taxi requesting and booking system, is disclosed. A request is received from a user via mobile telecommunication apparatus (410) and is passed for attention to a service provider local to the location from which the request was made. This system removes from the user the need to know where best to direct their request. The service can be contacted from a wide geographical area through a single request point, such as a single specified telephone number or an Internet URL. A request is then sent (428) to one or more mobile service providers (such as taxi drivers) who are given the opportunity to accept the request (438). Once the request is accepted, the system allocates a mobile service provider to the request and informs the user and mobile service provider accordingly (442).

Description

MOBILE SERVICE REQUEST SYSTEM The present invention relates to a mobile service reservation system. It has a particular application to a system for requesting taxi services.

Mobile telephony has been very widely adopted, largely due to the convenience that it affords. One weakness that many users will have experienced is that it is often difficult for a user to find an appropriate telephone number for locally-based services. For example, when a user arrives at an unfamiliar railway station, they are unlikely to know the number of a local taxi service. Even if the user does know the number of one or more taxi services, they do not have access to real-time information regarding the whereabouts of an available taxi, so they do not know whom to call in order to minimise their wait for a taxi. (Note: as used herein, the term"taxi service"is intended to include private hire services, and other similar transport services that may be provided in accordance with local legislation.) An aim of this invention is to employ mobile telephony technology to automate the process of requesting locally-based mobile services such as a taxi service.

From a first aspect, the invention provides a mobile service request system in which a request received from a user via mobile telecommunication apparatus is passed for attention to a service provider local to the location from which the request was made.

This system removes from the user the need to know where best to direct their request.

Advantageously, the service can be contacted from a wide geographical area (for example, a city, a country, or larger) through a single request point, such as a single specified telephone number or an Internet URL. This means that a user need know (and, conveniently, store in their telephony apparatus) a minimum of contact information.

Most typically, the telecommunication apparatus used by a user to access the service will incorporate mobile telephony apparatus, such as a GSM telephone (possibly, a personal digital assistant that incorporates GSM telephony apparatus). In such embodiments, the

system is preferably provided with apparatus that enables it to determine automatically the location of the user. For example, the system may interact with the mobile telephony network to determine the network cell from which the user has made the request.

Alternatively, the user's apparatus may obtain its position from the Global Positioning System (GPS) and relay this information to the service provider. If such positional information is not available automatically to the system, it may be provided by the user manually. For example, in a country such as the UK that has a detailed postcode structure, the user may inform the system of the postcode at which they are located.

Especially in cases where the user's apparatus is (or incorporates) a GSM or other mobile telephone, the user may make the request by sending a message using the short message service of a mobile telephony system. If the user's apparatus is equipped to send and receive messages using the Wireless Application Protocol (WAP) the user may make the request by accessing a WAP page. If the user's apparatus is equipped to access the Internet, the user may make the request by accessing a worldwide web page.

The system may act to meet a user's request as soon as possible. Alternatively, a user may make a request that a service be provided some time in the future (for example, the user may order a taxi for a planned journey). In the latter case, the system will typically pass the request on to service delivery units (for example, taxi drivers) within the geographical region and wait for one of them to confirm the booking.

In a system embodying this aspect of the invention, the service provider typically includes a service controller and a plurality of mobile service delivery units. For example, in the case of a taxi service, the service controller may include a computer that relays messages to service delivery units that are each constituted by a car and its driver (s).

The service controller in a system embodying the last-preceding paragraph may be operative to receive a service request from a user and offer the request as a job to a plurality of service delivery units. This provides an increased chance of a successful allocation of the job to a service delivery unit. After offering the request, such a system typically awaits a response to the offer from a service delivery unit prior to allocating the job to a unit. It may be that the service controller receives a response from a plurality of delivery units, in which case the service controller advantageously executes a decision algorithm to determine

which of the plurality of service delivery units is to be allocated the job. This can ensure that the user's request can be met as promptly as possible. Such an algorithm may, for example, include one or more of : determining the nearest delivery unit to complete the job, or determining the shortest time taken for a service delivery unit to arrive at a starting point for the job.

A system embodying this aspect of the invention may further include one or more request points that provide telecommunication apparatus that a user can use to make a request. This can provide a readily-accessible system for people who do not have access to personal telecommunication apparatus.

From another aspect, the invention provides a computer system programmed to operate as a service controller in a system embodying either of the last two preceding paragraphs.

An embodiment of the invention will now be described in detail, by way of example, with reference to the accompanying drawings, in which: Figure 1 is a block diagram showing components that constitute a system embodying the invention that handles requests for a taxi service; Figure 2 is a block diagram showing interaction between the components of the system of Figure 1; Figure 3 is a flow diagram illustrating a procedure for logging a taxi onto the system of Figure 1; Figure 4 is a flow diagram illustrating a procedure for requesting a taxi on the system of Figure 1; Figure 5 is a flow diagram illustrating a procedure for allocating a taxi to an immediate user request for a taxi on the system of Figure 1; Figure 6 is a flow diagram illustrating a procedure for processing a user request for a future reservation of a taxi on the system of Figure 1; Figure 7 illustrates allocation of a job to a taxi geographical regions defined by postcodes ; and Figure 8 illustrates allocation of a job to a taxi geographical regions defined by mobile telephony cell.

With reference first to Figure 1, a system embodying the invention will now be described.

The system of this embodiment handles requests and allocations for a taxi service, however, it is to be understood that application of this invention is not limited to such applications.

The system comprises a service controller 10 that includes a server computer system 12.

The server 12 has connections to the Internet 14, a GSM mobile telephone network 16, and has access to a service database 18. The service controller 10 can also communicate with equipment carried in individual taxis 20.

The service computer system 12 executes controller software. The functional component parts of the software will be described with reference to Figure 2.

The core part of the software is constituted by an operator module 30. This module communicates with an allocation module 32, an access module 34, a data warehouse 36, and a maintenance module 38. Additionally, the software includes a billing system 40 that is in communication with the data warehouse 36, and a plurality of service access point adapters 42 (referred to as"SAPAs").

The data warehouse maintains a list of taxi drivers that have registered with the system. In many jurisdictions, each driver is licensed to operate by a local licensing authority. Each driver is authorised to pick up a passenger only from within the area covered by an authority that has granted a licence to that driver. The system operates to ensure that a request is sent only to a driver that is authorised to operate in the location from which the request has originated. To this end, the system maintains geographically co-ordinated databases of drivers. In this embodiment, there are two principle databases, within the data warehouse 36, referred to as the"home location registers" (HLR) and several"visited location registers" (VLR).

The data warehouse contains a HLR for each geographical region. The geographical region is determined either by the local authority responsible for licencing taxis and minivans within that area, or by the system operator, according to commercial and practical considerations. The maximum area covered will however always be equal to or less than

the area covered by the local authority responsible for licensing. There is a"instance"for each vehicle registered in the system. The instance has"attributes"that hold the information associated with the vehicle instance, including"n"number of drivers. Each driver must be licensed to operate in the area covered by the HLR as a minimum. The instance is logged in only one HLR. but is also registered in every VLR. The reason for this is that a passenger may have a destination outside the HLR of the taxi and it is envisaged that taxis may be registered in many areas, thus allowing them to drop at destinations outside their normal area, and then be given priority to accept fares that have destinations that move them back towards their HLR area.

In addition to the fixed data identifying the driver, the vehicle, the extent of authorisation, and so forth, the HLR contains real-time information describing the status of the vehicle.

For example the HLR may contain the following information for each vehicle: Location: GPS style location information specifying the whereabouts of the vehicle (resolution dependant on the level of equipment available in the vehicle).

The geographical cell within which the Taxi is operational.

Postcode location derived from above or entered by the driver.

Status--whether the Taxi is: Logged on Logged off Paused Busy Cleared Barred Active Cell: Specifies in which geographical cell the taxi is presently located.

Valid Cell Transceivers: Specifies from which transceivers the driver is allowed to receive requests for the HLR region covered. This may be determined by legal or other criteria.

There is a VLR for each geographical region maintained by the system. Each VLR holds information on all taxis registered in the HLR that are authorised to operate within the region to which the VLR relates. The VLR also contains the information set forth above for each driver. Each HLR has a VLR covering the identical area, and vice versa. When a driver is registered with the system, his vehicle is entered into one HLR and every VLR.

If the vehicle already has an existing"instance", then the driver is added to its attributes.

Each taxi accesses the system using an appropriate telecommunications system. Various types of telecommunications equipment can be provided appropriate for the level and type of operation for an individual vehicle.

Examples of telecommunications equipment are as follows: Mobile (GSM) Telephone SMS capable : This can be considered to be a minimum requirement. and allows the system to send and receive appropriate messages to allow successful taxi allocation, and can present location information to the service system 12 (in the form of translating the cell transceiver into a physical location).

Mobile Phone WAP enabled : This apparatus allows the system to send and receive appropriate messages to allow successful taxi allocation. and can present location information to the service system 12 (in the form of translating the cell transceiver into a physical location). As compared with a mobile telephone described above, this apparatus allows a much improved user interface for the driver.

PDA used in conjunction with one of the above or on a packet assembler/disassembler (a PAD), and installed with a WAP browser and a GPS location system : This apparatus allows the service system 12 to send and receive appropriate messages to allow successful taxi allocation, and will present location information to the system (in the form of translating the cell transceiver into a physical location). Such apparatus can also inform the service system 12 of much more accurate GPS information. allowing allocation of the taxi on a more carefully selected geographical basis. This apparatus also provides a yet further improved user interface compared to alternatives described above.

Before a taxi is eligible to receive allocation information from the system, it must first log on. The process of logging on and logging off will be described with reference to Figure 3.

The process of logging on starts when a logging on request is initiated when the service system 12 receives a request from a driver through one of the service access point adapters (Step 310). The request is handled by the access module 34.

The access module 34 first determines whether the driver making the request is present in

the HLR (Step 312). If it is, then the access module 34 determines whether the request is to log on or to log off (Step 314), and changes the status of the driver recorded in the database, as appropriate (Step 316,316'). Once the status update has been recorded, the driver is sent an acknowledgement (Step 320) to confirm that the request has been processed.

If Step 312 determines that the driver is not in the HLR, then the access module 34 goes on to determine whether the driver is present in the VLR (Step 322). If it is, then the access module 34 determines whether the request is to log on or to log off (Step 324), and changes the status of the driver recorded in the database, as appropriate (Step 326,326'). Once the status update has been recorded, the driver is sent an acknowledgement (Step 320) to confirm that the request has been processed. If the access module 34 determines that the driver is present in neither the HLR nor the VLR, the request is refused (i. e. the driver is not registered on the system), and an appropriate message is sent to the driver (Step 328). The access module 34 also checks to ensure that the driver is not recorded as"barred"in the HLR or VLR. If the driver is barred, the request to log on is refused, and the cause is sent to the driver.

Once logged on, the taxi is marked in the HLR or VLR as paused. In the paused state, the service system 12 exchanges only"booking"messages with the taxi.

The service system maintains the taxi in a paused state until it receives"cleared"message from the taxi. It is then marked as"cleared". Once in the cleared state, the taxi is eligible to be sent service request messages as will be described below.

To place a request for a taxi, a user contacts the service system 12 using a connection device of preference. The request is received by the connection adapter 42 appropriate to the type of connection device used. In each case, the user's request must include details of the user's location in a manner that is accessible to the service system 12. The following describes alternative access apparatus that a user might use, and the manner in which location information might be passed to the service system 12. It will be understood that this is not an exhaustive list and that alternative devices will become available with further developments in technology.

Interactive digital television (terrestrial and satellite). Location information is already available from the existing billing system for the television subscription system.

Mobile telephones : Using SMS and/or WAP technology for access, location information can be made available to the service system from the telephone network operators.

Alternatively, if the telephone apparatus is equipped with GPS receiving apparatus, GPS location data can be forwarded to the service system 12. Alternatively, the user may enter the location information, for example by using a postcode.

Internet : Using a World Wide Web platform, a user can pre-set the address to which a taxi will be sent on first accessing the system. This location information can be sent automatically thereafter.

Wireless Application Protocol : The user's current location information is available from the mobile telecommunications network. Default locations for pick up points can also be set by user to allow automation. Alternatively, the user may enter the location information, for example by using a postcode.

Service Request Points : A specifically designed taxi request system can be installed in locations accessible to the public, for example pubs and clubs. Location is preset to the access point's location, and a two action function (e. g. lifting a cover and pressing a request button) is required to send a request for a taxi to the system, in order to prevent false requests being sent. The stored location information stored on a SIM card will be sent to the service system 12. These request points can communicate using any appropriate telecommunications media.

PSTN Connected (including wireles. s) : On digital systems, users can ensure that their calling line identifier is available. The system will use this to look for the associated pickup point. This too can have a default and pre-sets that are selected by the user using either voice recognition, or keyed entry via a tone or pulse recognition system.

On analogue systems. the user can be identified by entering a pre-arranged system access code and password using pulse or tone recognition systems. The user can then select a default pick up point, a preset pick up point. or enter a new pick up point using either a voice recognition system or by telephone keypad alphanumeric successive approximation to achieve a valid address for the pick-up point.

Satellite Communications Systems : The service system can receive a request from a satellite communications systems that interconnects with terrestrial networks, and that is capable of sending user definable information to the terrestrial networks. The data sent may, for example, include SMS, direct voice connection, data (switched) connection, or data packet connection e. g. X. 25.

With reference to Figure 4, once the user has connected to the service system 12 using their chosen communication apparatus, the user sends a service request message 410. This message is received by the access module 34 and handed on to the operator module 30 for processing. The request message contains at least the following fields: Current Location information (CL) As Soon As Possible (ASAP) Taxi Request Selected Group (SG) Booked Taxi Request Booked Taxi Pick Up Point (BP) Booked Taxi Pick Up Time (BT) The default SG consists of all taxis registered on the system. Certain users (e. g. women travelling at night) may however prefer to use only drivers they know or, for example, they may be in a group and prefer to travel only in seven seat vehicles. The user can select groups based on any available"attributes"of the taxi"instances". by either including or excluding taxis based on their own criteria or criteria offered by the system.

The operator module 30 first verities that the originating point of the message has not been barred, for whatever reason (Step 412). If there is a bar in place, the user is sent a message accordingly (Step 414) and the process is stopped.

The operator module 30 next verifies that the pick-up address and drop address are valid (Step 416). If either is not valid, the user is sent a message accordingly (Step 418) and the process is stopped.

Next, the operator module 30 attempts to allocate a taxi to fulfil the user's request. To do this, the operator module selects one of two algorithms based on whether the request is for an immediate (ASAP) pickup or to book a future journey (Step 420). The former case will now be described; the latter will be described later.

The operator module 30 then invokes a selection algorithm (Step 422) to be executed by the allocation module 32. This algorithm will now be described with reference to Figure 5.

The allocation module 32 receives the pick-up address (Step 510) and selects all taxis that meet the required SG setting. From this pool of taxis it determines a number n of taxis which are the closest taxis to the user (Step 514,516). The distance is based on a radius from the user's BP or PUA, as determined (Step 512) from the GPS information, the cell of origin (COO) or the postcode, whichever is more appropriate to the information supplied by the user. Within a predetermined limit, the radius is always expanded so that at least three taxis are given the request i. e. n ; : : 3.

The COO provides enough information to achieve a PUA and it can be used to preselect the first few digits of a postcode, or as a predefined radius ensuring that only drivers operating in the same cell, who meet the SG requirements, are forwarded the request. In some locations an area defined by varying elements of the postcode rather than a radius, may be used to define the area within which operating taxis will receive the request.

Once the n taxis have been selected, the allocation module 32 invokes route planner software to determine which taxi is the closest in time to the pick-up point, and creates a sorted list (Step 518) of the n taxis based on this information. It may be that no taxi can be found on the system within a predetermined distance (Step 520). If this is the case, the algorithm returns a value of 0 (Step 522). Otherwise, the first n entries in the sorted list are selected (Step 524) and the algorithm returns the list of n taxis (Step 526).

If the algorithm returns 0 (Step 424), the allocation module 32 advises the user that no taxi is available (Step 426) and terminates the allocation process.

The allocation module 32 then sends"request"messages to each taxi that is in a cleared state (Step 428), with a number identifying their ranking in the sorted list, and awaits a response (Step 430). Any taxi that has received the request message may accept the request by returning a"request accept"message. If more than one taxi responds to accept the request, the allocation module 32 gives priority to the taxi that is closest to the user (Step 432). If no taxis reply with in a predetermined time, then the request has failed, the n taxis polled are moved out of the selected list, and the process is repeated with the next n nearest taxis to the pick-up point. Should this second request fail, then the system will automatically allocate a taxi to the job (Step 434). The allocation module 32 then sends an "allocation"message to the taxi that it has selected for the job (Step 436). The system then awaits the selected taxi to acknowledge (Step 438) by sending a"request accept"message.

Should acknowledgement not be received from the taxi within a timeout period, the allocated taxi will be logged off the system (Step 440) and a technical barring set against it until the reason for non-acknowledgement is determined. In addition, the user will be sent a message to advise that no taxis are available at present.

Once the taxi has sent the"request accept"message and the allocation module 32 has received it, the allocation module 32 will send an"allocation"message to the taxi, and to the user (Step 442). The pick up point will be derived from the GPS style location information, or postcode. The contact telephone number for the taxi and the user are swapped and sent to each other. Therefore, after the job has been allocated, if the ETA is exceeded, then the driver can advise the user that there has been a delay, or the user can contact the taxi driver to ask why there is a delay, and a new ETA. In addition, if the taxi is equipped with GPS equipment. this can be configured to send location messages to the allocation module 32 on request. This enables the user to request updates on the progress of the taxi.

The various messages exchanged between the allocation module and the taxi include the following fields: Allocation : Request Failed (contains a message why the request failed) Request accepted Contact number Pick Up Point address Estimated Time of Arrival Request Accept : Accept Request Acknowledge : Acknowledge The algorithms for taxi allocation are adjustable, for example, in dependence on region, and time of day.

If at Step 420, described above, the request is determined to be for a future journey, a booking algorithm is executed, as will be described with reference to Figure 6.

The booking algorithm first attempts to calculate a price for the job to be offered to the user by looking up the pick-up address and the drop address with a database (Step 610). If a price is found in the database (Step 612), the system sends a message to the user informing them of the price (Step 614) and requesting that the user accept or reject the offered price.

The user's response is awaited for a timeout period (Step 616). If no response is received, or the customer rejects the offered price, the booking process is terminated (Step 618). If the customer accepts the price (or if no price was found in the database search) the system proceeds to process the booking request.

A booking request is sent to all drivers that have an entry in the HLR which covers the pick-up address or the delivery address (Step 620), and then awaits a response. If a response is received (Step 622), the first respondent is selected by the system (Step 624). If no response is received, the system selects a driver to handle the job (Step 628). The selected driver is assigned the job (Step 630) and is then sent an"allocation"message. The system then awaits the selected taxi to acknowledge (Step 632) by sending a"request accept" message. Should acknowledgement not be received from the taxi within a timeout period. the allocated taxi will be logged off the system (Step 634) and a technical barring set against it until the reason for non-acknowledgement is determined. The process then repeats from Step 628.

Once a driver has accepted the job, the user is sent a message confirming that the job has been accepted and informing them of the telephone number of the driver (Step 636).

After accepting a booking, the driver can optionally set the system to generate a reminder call a predetermined time before the booked time. In any case, the driver will automatically be placed in a"busy"state at the specified booking time. The driver may manually put the system into the"busy"state prior to the booked time. to allow traveling time to the BP.

Once the passenger has been dropped at the destination, the driver sends a"cleared" message, so that he can accept further requests.

Various embodiments of the invention may employ a variety of different systems to determine the location of the user and determine which drivers are eligible to respond to any given request. This is necessary to determine which drivers should be sent details of an incoming request. The system can, for example, use GPS, postcodes or cell methods for geographical allocation of requests.

An example of a geographical allocation method based on the use of postcodes is illustrated in Figure 7. A geographical region 706 includes five separate areas 708 defined by postcodes. In this example, the areas 708 are designated A, B, C, D and E. The user's pick up address (PUA) or Booked Taxi Pick Up Point (BP) 710 is located in an area E defined by a postcode. Adjacent areas A, B, C, D are defined by different postcodes. The request may be transmitted either to all available taxis in area E or, alternatively, to all available taxis in that area and the adjacent areas. This latter option may for example be achieved by using an algorithm that identifies all postcode areas lying within a predetermined radius of the PUA. In the example shown in Fig. 7, the selected radius 712 overlaps postcode areas A, B, C and E, and the request will therefore be transmitted to available taxis in those areas, but not area D.

Postcode information may also be used by taxis to define their positions. and this information may either be used in combination with the user's postcode location as a basis for allocation, or it may be converted into a map reference for use in an allocation system based on distance from the user.

An example of a geographical allocation method based on the use of cell of origin (COO) information is illustrated in Figure 8. In this example, a geographical region 806 contains three communication cells 808, designated cells A, B and C. The user's booking request either contains COO information (if the request is made using a mobile phone) or the appropriate COO is determined from the location information received. In this latter case, the COO information represents the cell in closest proximity to the user's PUA or BP 810.

The request is transmitted to all available taxis within the same cell, and optionally also taxis in adjacent cells, as determined by the software algorithms.

If the PUA 810 lies in an area where two cells overlap, the cell that provides the strongest signal is designated the COO, although the request may also transmitted to taxis in the overlapping cells. For example, in Figure 8, the PUA 810 lies within cells A and C, and taxis within both of those areas will be advised of the request. However, cell A is designated the COO, since that cell provides the stronger signal.

Any portions 812 of the cells 808 that lie outside the geographical region 806 are designated non-operational, and any calls originating from outside the region 806 will not be forwarded to taxis that are licensed to operate only within that region. The system maintains a record of which cells lie within the region, and it determines from the location information contained within the request whether the PUA or BP lies within that region.

An algorithm then selects the cell or cells that are closest to the job.

Claims

CLAIMS 1. A mobile service request system in which a request received from a user via mobile telecommunication apparatus is passed for attention to a service provider local to the location from which the request was made.
2. A system according to claim 1 that can be contacted from a geographical area being at least the size of a city or a country through a single request point.
3. A system according to claim 2 in which the request point is a specified telephone number.
4. A system according to claim 2 in which the request point is an Internet URL.
5. A system according to any preceding claim accessible from mobile telephony apparatus.
6. A system according to claim 5 in which the telephony apparatus is a GSM telephone.
7. A system according to any preceding claim further including location apparatus that enables it to determine automatically the location of the user.
8. A system according to claim 7 operative to interact with a mobile telephony network to determine the network cell from which the user has made a request.
9. A system according to claim 7 in which the user's apparatus is operative to obtain its position from the Global Positioning System (GPS).
10. A system according to any preceding claim in which the user may make a request by sending a message using the short message service of a mobile telephony system.
11. A system according to any preceding claim in which the user may make the request by accessing a WAP page.
12. A system according to any preceding claim in which the user may make the request

by accessing a worldwide web page.

CD
13. A system according to any preceding claim that operates to meet a user's request as soon as possible.
14. A system according to any preceding claim in which a user may make a request that a service be provided some time in the future.
15. A system according to any preceding claim in which the service provider includes a service controller and a plurality of mobile service delivery units.
16. A system according to claim 15 in which the service controller includes a computer that relays messages to service delivery units.
17. A system according to claim 15 or claim 16 in which each service delivery unit is constituted by a vehicle and its driver.
18. A system according to any one of claims 15 to 17 in which the service controller is operative to receive a service request from a user and offer the request as a job to a plurality of service delivery units.
19. A system according to claim 18 in which the system awaits a response to the offer from a service delivery unit prior to allocating the job to a unit.
20. A system according to claim 19 in which the system, on receiving a response from a plurality of delivery units, executes a decision algorithm to determine which of the plurality of service delivery units is to be allocated the job.
21. A system according to claim 20 in which the decision algorithm includes one or more of : determining the nearest delivery unit to complete the job, or determining the shortest time taken for a service delivery unit to arrive at a starting point for the job.
22. A system according to any preceding claim further including one or more request points that provide telecommunication apparatus that a user can use to make a request.
23. A computer system programmed to operate as a service controller in a system according to any one of claims 18 to 21.
24. A taxi allocation and booking system substantially as herein described with reference to the accompanying drawings.