WO2012027781A1 - Procédé et système pour une opération de taxi - Google Patents

Procédé et système pour une opération de taxi Download PDF

Info

Publication number
WO2012027781A1
WO2012027781A1 PCT/AU2011/001105 AU2011001105W WO2012027781A1 WO 2012027781 A1 WO2012027781 A1 WO 2012027781A1 AU 2011001105 W AU2011001105 W AU 2011001105W WO 2012027781 A1 WO2012027781 A1 WO 2012027781A1
Authority
WO
WIPO (PCT)
Prior art keywords
hire
request
vehicle
passenger
marshalling
Prior art date
Application number
PCT/AU2011/001105
Other languages
English (en)
Inventor
Peter John Gosney
Original Assignee
Peter John Gosney
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Peter John Gosney filed Critical Peter John Gosney
Publication of WO2012027781A1 publication Critical patent/WO2012027781A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations

Definitions

  • the invention relates to a system and method that has particular although not exclusive use for booking and allocating taxis or other chauffeured vehicles for hire.
  • a hirer will contact a particular booking or dispatch company and provide pickup and destination information.
  • the booking company will allocate a vehicle to provide the service.
  • a record can be kept of such bookings.
  • taxis can be hired without booking and typically no detailed record is kept of such hires. It is not uncommon for passengers waiting for a booked taxi to be picked up by another taxi passing by before the booked taxi arrives. This can lead to frustration and loss of revenue for the booked taxi driver due to loss of the fare as well as vacant travelling time to the pickup destination. A person being collected by an unbooked taxi may not even realise that the collecting taxi is not the taxi dispatched to respond to their booking.
  • Taxis can be hailed on the street for hire without booking.
  • a designated area otherwise known as a taxi rank
  • Such taxi ranks are convenient for passengers and taxi drivers alike as both passengers and taxis alike can go to such areas to find customers and service providers respectively.
  • taxis may only be hired from taxi ranks in some areas or at some times, particularly at night. In such hires the passengers are essentially anonymous, particularly where payments are made using cash.
  • a computer implemented chauffeured vehicle hiring system comprising:
  • hire request processor a communication interface, hire request processor and data store, the hire request system being adapted to:
  • the hire record including passenger
  • Some embodiments of the system can further comprise one or more marshalling systems each associated with a vehicle hire marshalling station,
  • each marshalling system being a computer implemented system adapted to enable a marshal to: input hire request references presented by passengers; input vehicle identifiers of chauffeured vehicles which present at the marshalling station for collection of passengers; queue presented hire request references; and record a vehicle identifier of a chauffeured vehicle with the hire request reference for a passenger when the chauffeured vehicle presents for collection of the passenger.
  • An incoming telephone number can be assigned for each marshalling station, whereby the hire request system can identify the marshalling station for a request based on the incoming telephone number used when making the request.
  • Embodiments of the system can be further adapted to receive position data for the passenger's mobile phone and identify the marshalling station for a request based on the received position data.
  • the marshalling system can be further adapted to transmit the recorded vehicle identifier with the hire request reference to the hire request system, and the hire request system is further adapted to update the hire record for the hire request reference with the received vehicle identifier.
  • the hire request system can be further adapted to transmit each hire request reference to a marshalling system associated with the identified marshalling station for the hire request reference, and the marshalling system is adapted to receive the transmitted hire request references.
  • the marshalling system can also be further adapted to match hire request references provided by customers approaching the marshalling station with received hire request references to verify validity of the hire reference request message.
  • the marshalling system can be provided with a display, whereby at least the lead portion of the queue of hire request references can be displayed.
  • the marshalling system can be further adapted to display a vehicle identifier of a vehicle for each displayed hire request once a vehicle is allocated for the hire request.
  • the vehicle identifier can be transmitted to the hire request system by the passenger once a pickup has been made.
  • the hire request system can be further adapted to generate a hire record for a hailed vehicle hire wherein the hire record includes a hired vehicle identifier, where a passenger provides a vehicle identifier to the hire request system with the hire vehicle request.
  • the hire request system can be further adapted to record position data for the passenger's mobile phone in the hire record during the vehicle hire.
  • the position data can be recorded periodically during the vehicle hire.
  • the position data is transmitted to the vehicle hire system by the passenger's phone.
  • the position data is obtained by the hire request system via a communication network.
  • Passenger identification information can be based on any one or more of: caller line identification (CLI); user name; phone identifier, user identifier, application identifier or other identifier that is unique within the system.
  • CLI caller line identification
  • user name phone identifier
  • phone identifier user identifier
  • application identifier other identifier that is unique within the system.
  • the hire request system can be further adapted for data communication with one or more dispatch systems, whereby vehicles to fulfil hire requests may be booked for dispatch.
  • the marshalling system can be further adapted receive one or more vehicle references of vehicles dispatched to the marshalling station and associate a hire request reference, selected based on position in the queue, with each received hire vehicle reference.
  • a method of recording hire of a chauffeured vehicle comprising the steps of:
  • the chauffeured vehicle identifier can be transmitted to the hire request service by the passenger using their mobile phone on pickup by the chauffeured vehicle.
  • the method can further include the step of extracting passenger location information from the call.
  • the method can further include the step of dispatching a chauffeured vehicle to the passenger using the extracted location information.
  • the method can further comprise the step of updating the hire record with position data of the passenger's mobile phone during the chauffeured vehicle hire.
  • a method of hiring a chauffeured vehicle from a vehicle hire marshalling station comprising the steps of:
  • a hire record including passenger identification, marshalling station
  • This method can further include the steps of:
  • the method can further include the steps of:
  • the method can further include the step of the marshalling system matching hire request references provided by customers approaching the marshalling station with received hire request references to verify validity of the hire reference request message.
  • the method can further include the step of displaying by the marshalling system at least a lead portion of the queue of hire request references.
  • the method can further include displaying a vehicle identifier of a vehicle for each displayed hire request once a vehicle is allocated for the hire request.
  • the method can further include transmitting, by the hire request system, booking requests to one or more dispatch systems, whereby vehicles to fulfil hire requests may be booked for dispatch to the marshalling station in response to the booking request.
  • the method can further include the steps of: Receiving, by the marshalling system, one or more vehicle references of vehicles dispatched to the marshalling station; and
  • a software application executable on a mobile phone adapted to facilitate communication between the phone user and a hire request system as described above to send vehicle hire requests and record hire of a chauffeured vehicle.
  • the software application can be further adapted to transmit mobile phone location data to the hire request system periodically during hire of the chauffeured vehicle.
  • Figure 1 is an illustration of an example of a marshalling station application of an embodiment of the present invention.
  • Figure 2 is a block diagram of an example of a system according to an embodiment of the present invention.
  • Figure 3 is an illustration of an example of a hail record application of an embodiment of the present invention.
  • Figures 4a and 4b are flowcharts illustrating a process according to an embodiment of the present invention.
  • Figure 5 illustrates examples of data displayed at a marshalling station.
  • Figure 6 is an example of a sign incorporating a display which can be provided at a marshalling station.
  • Figure 7 is an illustration of an example of a trip tracking application of an embodiment of the present invention.
  • Figure 8 is an illustration of an example of a trip tracking application of an alternative embodiment of the present invention.
  • a chauffeured vehicle hiring system is provided.
  • the chauffeured vehicle hiring system can be used to record both passenger and vehicle identification for hires made through bookings, from marshalling stations or via hail on the street.
  • Some embodiments of the vehicle hiring system are adapted for use with vehicle hire marshalling stations.
  • the system comprises a hire request system 1 10 and optionally one or more marshalling systems 120 each associated with a vehicle hire marshalling station 160.
  • the hire request system 1 10 comprises a communication interface whereby hire requests can be received via a communication network, a hire request processor adapted to process hire requests, and a data store for storing hire records.
  • the hire request system is implemented as software modules executable in a communication network connected computer processor and having a database for storing hire records.
  • the hire request system 1 10 is adapted to:
  • control the communication interface to transmit the hire message to the passenger using passenger identification information extracted from the hire request; and update the hire record with a hire vehicle identifier once a pickup has been made.
  • the passenger identification information can be phone identification information such as caller line identification (CLI), where the mobile phone is adapted with CLI functionality.
  • the user identification information can be based on other information such as a phone identifier, user identifier, application identifier or other identifier that is unique within the system.
  • the user identification may be based on a unique application identifier assigned to the user or other information such as a registered user name.
  • the user identification information (CLI, phone identifier, application identifier etc) can also be used for addressing the return hire message.
  • the hire request may be made by making a phone call to any one of one or more incoming telephone numbers.
  • the communication interface of the hire request system can include computerised call answering functionality adapted to answer a call to one of one or more incoming telephone numbers and extract the CLI information for each incoming call.
  • the hire request may be a message, for example SMS, which can be received and the CLI extracted from the message by the communication interface.
  • the incoming telephone number called or to which a message is sent is dedicated for the service being provided, that of hiring a vehicle, so all calls or messages received at the incoming number are processed by the hire request system as a hire request.
  • the CLI information is extracted from the incoming telephone call or message to identify the passenger making the request.
  • the passenger may be registered with the hire request system and information regarding the user, such as name, addresses and payment data recorded in a user profile which can be looked up using the CLI .
  • Unregistered users may also use the system. As unregistered user will not have a stored user profile the CLI from the incoming call can be used as the passenger identification.
  • a plurality of telephone numbers may be used for making hire requests.
  • Each telephone number 165 can identify a single marshalling station 160 to enable identification of the pickup location.
  • each marshalling station may be allocated a telephone booking number to enable the pick up location to be identified directly from the called number.
  • pick up location may be based on information sent with the hire message. For example, location identification information, such as a rank number or address, may be input by the user. Alternatively GPS coordinates of a current phone position may be transmitted with hire message. The GPS coordinates may be used to determine a pick up location. For example, the pick up location may be the current position, nearest curb side or nearest taxi rank. A message back to the passenger may provide directions to the closest or most convenient taxi rank to the passenger's location.
  • location identification information such as a rank number or address
  • GPS coordinates of a current phone position may be transmitted with hire message. The GPS coordinates may be used to determine a pick up location.
  • the pick up location may be the current position, nearest curb side or nearest taxi rank.
  • a message back to the passenger may provide directions to the closest or most convenient taxi rank to the passenger's location.
  • the hire vehicle identifier for example a vehicle number, may be manually input by the passenger on pickup and transmitted to the hire request system or automatically transmitted to the hire request system by a marshalling system 120 at a marshalling station 160.
  • a marshalling system 120 for example, where a passenger sends a hire request and then waits for pickup at a marshalling station 160 the hire vehicle number can be captured and transmitted from the marshalling station.
  • the passenger books a vehicle and a pickup is made from somewhere other than a marshalling station, say a venue or curb side, the number of the vehicle dispatched may be recorded in the hire record and confirmed once the driver confirms pickup.
  • the passenger may enter the vehicle number into their phone (for example using a key pad or photograph) and transmit this to the hire request system on pickup to record or confirm the vehicle number.
  • the passenger may call a designated telephone number and enter the vehicle number via their telephone keypad when prompted.
  • the hire request and vehicle number of the hailed vehicle may be sent in a single message to generate a hire record identifying the passenger and hire vehicle.
  • the passenger's mobile phone is equipped with location identification functionality, for example GPS (global positioning system) enabled, location data may also be included with the hire message and recorded in the hire record.
  • Embodiments of the invention can be provided with marshalling systems to facilitate vehicle hire and loading at marshalling stations.
  • Each marshalling system 120 is a computer implemented system adapted to enable a marshal 125 to input hire request references presented by passengers 140, 150 and to input vehicle identifiers 175, 185 of chauffeured vehicles 170, 180 which present at the marshalling station 160 for collection of passengers 140, 150.
  • the marshalling system 120 is adapted to queue presented hire request references, and record a vehicle identifier 175, 185 of a chauffeured vehicle with the hire request reference for a passenger 140, 150 when the chauffeured vehicle 170, 180 presents for collection of the passenger 140, 150.
  • the marshalling system 120 in some embodiments can be further adapted to transmit the recorded vehicle identifier 175 with the hire request reference for a passenger 140 to the hire request system 1 10 so the hire request system can update the hire record for the hire request reference with the received vehicle identifier 175.
  • the hire request system 1 10 can be adapted to transmit each hire request reference to a marshalling system 120 associated with the identified marshalling station 160.
  • the marshalling system receives the transmitted hire request references and can match hire request references provided by customers 140, 150 approaching the marshalling station 160 with received hire request references to verify validity of the hire reference request message.
  • the hire request system can also be in data communication with one or more dispatch systems 190A-C, for example via a communication network 135.
  • the hire request system can be adapted to transmit booking requests to one or more dispatch systems 190A-C, whereby vehicles 170, 180 to fulfil hire requests may be booked for dispatched to the marshalling station 160 in response to the booking request.
  • the booking requests may be made via a booking system in communication with the dispatch systems 190A-C.
  • An example of a suitable booking system is described in International patent application publication number WO 2009/100481 by the present applicant, the full disclosure of WO 2009/100481 is incorporated herein by reference.
  • An embodiment of the vehicle hiring system is illustrated in the block diagram of Figure 2.
  • the system 200 comprises a hire request system 210 and an optional marshalling system 220.
  • the marshalling system 220 can be provided for facilitating loading of vehicles and recording hires at marshalling stations such as taxi ranks.
  • the vehicle hiring system can include a plurality of marshalling systems 220 to enable a plurality of marshalling stations to be serviced by the hiring system.
  • one marshalling system 220 will be provided for each marshalling station.
  • more than one marshalling system 220 may be provided for the one marshalling station.
  • embodiments where vehicles are hired by hail or booked for a specified location pickup do not require any marshalling system.
  • the hire request system 210 of this embodiment includes a communication network interface 230, a request controller 240, and data store 250 wherein user records 252 and hire records 255 can be stored.
  • the hire request system 210 may be implemented utilising any suitable combination of software, firmware and hardware.
  • the hire request system is implemented in software executable on a server or personal computer enabled for connectivity to a communication network such as the Internet.
  • the hire request system may be implemented using a hardware and software architecture optimised for the hire request system.
  • the communication network interface 230 is adapted to receive hire requests made by passengers via a communication network. Where the hire requests are made using mobile phones adapted with call line identification functionality to any one of one or more incoming telephone numbers the communication network interface can include an automatic call answering system.
  • the automatic call answering system can answer the call, extract the CLI and any further information, such as a taxi number, transmitted using DTMF tones, and hang up the call. In some embodiments where no additional information is sent with the initial request, the automatic call answering system may be adapted to extract the CLI and terminate the call before answering so the passenger does not incur any call costs.
  • the communication network interface 230 may include or be in data communication with a messaging service for receiving messages, such as SMS or EMS messages transmitted to the incoming telephone numbers.
  • a messaging service for receiving messages, such as SMS or EMS messages transmitted to the incoming telephone numbers.
  • communication network interface may be further adapted to receive hire requests via a data network such as via email or the Internet where the incoming telephone number is identified as part of the message.
  • smart phone applications may enable a user to input a telephone number and automatically send a hire request to the number via SMS or via the Internet for receiving by the communication network interface 230.
  • the communication network interface may extract passenger identification data other than CLI information, for example application identifiers, e-mail addresses, instant messaging identifiers, phone identifiers, user identifiers, IP addresses etc from the incoming message.
  • passenger identification data other than CLI information
  • a mobile phone can be automatically identified using many different means and any such means could be used within embodiments of the present invention.
  • the communication network interface 230 can include a computerised call answering system that answers booking calls made by mobile telephones to any one of a plurality of incoming call lines. Where marshalling stations are used, a telephone number can be used identify a single marshalling station 220. For example, ten incoming telephone numbers can be used to identify ten different marshalling stations.
  • the caller line identification (CLI) information is extracted from the incoming request and can be used to identify the person making the request.
  • the incoming telephone number can be used to identify the relevant marshalling station for the request.
  • the communication network interface can be adapted to extract this information from the incoming request and provide this information to the request controller 240.
  • automatic location identification functionality provided in the mobile phone may be used to identify the location of the passenger.
  • a vehicle booking application may be provided for GPS enabled mobile phones to provide location information with a hire request.
  • the application may also provide a simple user interface to facilitate making of a hire request.
  • Most modern mobile phones are capable of running applications to implement specific functionality.
  • Embodiments of applications to facilitate use of the hire request system of the present invention are envisaged. Such applications may be launched by a user when they wish to request or hail a taxi.
  • the application can automatically determine the telephone number, telephone identifier or internet address information to use for forwarding a request based on the mobile phone location.
  • the location may be provided as location coordinates or a street address.
  • the communication network interface 230 is also adapted for transmitting messages to the person making the hire request using the caller line identification or message address.
  • the communication from the hire request system to the user may use the same mode of communication as the original request or a different mode.
  • a hire request may be made via a telephone call and a message in response to the hire request may be transmitted to the user's mobile phone using SMS, e-mail or instant messaging.
  • the response message includes the hire reference and can include any other relevant information.
  • a GPS location may be provided with a hire message and directions to the allocated marshalling station provided with a hire confirmation message.
  • a response message may state: "Hire confirmed with hire reference number ABC123 proceed 200m east on Current Street to marshalling station XYZ, you are number 8 in the queue.”
  • the request controller 240 is adapted to process and record the hire request.
  • the request controller 240 can be implemented in software executing on a processor, such as a server or personal computer (PC), microprocessor or other processing device.
  • a processor such as a server or personal computer (PC)
  • PC personal computer
  • any suitable hardware, software and firmware architecture may be implemented.
  • some functions of the request controller may be hard wired or implemented in programmable hardware, such as programmable logic controllers (PLC) or the field programmable gate arrays (FPGA), as well as functions being implemented in software for execution on generic hardware such as servers or PCs.
  • PLC programmable logic controllers
  • FPGA field programmable gate arrays
  • the request controller 240 receives the passenger identification and location information or marshalling station identification for a hire request via the communication network interface 230.
  • the request controller 240 is adapted to process the request.
  • the request controller 240 generates a hire request reference for each request and creates a hire record which includes the passenger identification, hire request reference, location information and optionally marshalling station identification.
  • Hire records can be stored in a data store 250.
  • the data store may be a database stored in memory associated with the request controller or accessible by the request controller 240.
  • the data store 250 can also be used for storing user records 252. For example where a user has registered with the hire request system and stored details, these may be stored in the user record. For example, a regular user may store identification and potentially payment details.
  • the request controller 240 prepares a hire message including the hire request reference and this hire message is transmitted back to the user via the communication network interface 230 using the CLI extracted from the hire request.
  • the marshalling station is provided with a marshalling system 220.
  • the marshalling system 220 may be permanently docked or hardwired into a suitable structure, such as a podium or kiosk, at the marshalling station.
  • the marshalling system may be a portable system adapted to be carried by a marshal.
  • the marshalling system may be implemented using any suitable hardware, software and firmware.
  • the marshalling system may be implemented as software executing on a generic processing device, such as personal computer, laptop, or other processing device such as a mobile phone, personal digital assistant (PDA) or tablet computer.
  • dedicated hardware may be used.
  • a marshalling system is hardwired into a podium at a marshalling station
  • robust dedicated hardware may be used, to inhibit damage by elements or vandalism.
  • a mobile telephone, smart phone, personal digital assistant, tablet computer, etc. having suitable processing capability may be used to implement the marshalling system.
  • the marshalling system functionality may be implemented in a software application executable on the smart phone or tablet computer. Broadband wireless communication network connectivity of such devices may used advantageously for communication between the marshalling system and hire request system.
  • the marshalling system includes an input output (I/O) interface 270, marshalling controller 280, and memory 290.
  • I/O input output
  • the marshalling controller 280 may be any suitable processing device.
  • the marshalling controller functionality may be hard wired in an integrated circuit or implemented in programmable hardware such as PLCs or FPGAs.
  • the data store 290 can be implemented using any suitable memory device, for example the memory may be RAM and hard disc of a personal computer, recordable disk, solid state memory, and memory may be removable, such as a USB memory device, disc etc.
  • the I/O interface can implemented using any suitable input and output device or combination thereof.
  • the input interface may include a key pad, keyboard, touch screen, or reader device, such as a bar code reader, infra red or radio frequency input output interface etc.
  • the output may include one or more displays, speakers, lights etc. Any suitable hardware, firmware and software architecture may be used to implement the marshalling system.
  • a user presents the hire reference transmitted to their communication device to the marshal at the marshalling station.
  • the marshal inputs the hire reference using the I/O interface 270.
  • the hire reference can be input by inputting an alphanumeric code using a keypad or touch screen, scanning a bar code, receiving an electronic communication from a short range interface of the phone, such as a Bluetooth interface etc.
  • the marshalling controller 280 places the hire reference in a queue 295 stored in memory 290.
  • the queue or a portion thereof may also be displayed on a display visible to waiting passengers. Thus, passengers can watch their booking progress in the queue.
  • the marshal enters an identifier for each vehicle into the marshalling system as each vehicle arrives. For example, by entering a taxi number or registration number using a keypad or touch screen.
  • the vehicle identification may be automatically entered, for example by photographing the vehicle identification number or using a radio frequency identification ( FID) device on the vehicle to store the vehicle number and using an RFID reader at the marshalling station to read the RFID tag.
  • FID radio frequency identification
  • a bar code on each vehicle may be automatically or manually scanned.
  • the vehicle identifiers may be supplied to the marshalling station via the hire vehicle network.
  • taxis in a standoff area can be managed by a taxi dispatch network.
  • the taxi logs their presence in the standoff area or region with the network, the taxi dispatch network can manage any standoff queuing independent of the marshalling station queue or hire request system.
  • the marshalling system can send a signal to the taxi network or dispatch system to call one or more vehicles to the marshalling station from the standoff.
  • the taxi network can send the vehicle identifiers (taxi numbers) of the vehicles dispatched from the standoff to fulfil the request. In this manner the taxi network or dispatch system manages the vehicles in standoff using whatever desired.
  • the marshalling system or hire request system do not therefore need to be responsible for managing the vehicles in standoff. Once vehicles arrive at the rank from the standoff area the marshal can confirm the order of vehicle identifiers in the marshalling system queue based on each vehicle's in the physical marshalling station vehicle queue.
  • the vehicle identification is associated with a hire reference based on the queue order.
  • the association of vehicle identifier and passenger reference can be confirmed by the marshal and stored in the system as the passengers are loaded into the vehicle. This enables a record of the hirer and vehicle to be maintained for later recovery if there is any need. Knowing the hire transaction is recorded and can be tracked is a strong deterrent for illegal or undesirable behaviour.
  • the communication interface 260 of the marshalling system 220 is an optional component.
  • records of hire references and the vehicle identification of the vehicle used to service the hire request may be downloaded directly from the memory 280 for archiving or review, if required.
  • the hire reference and associated vehicle identification can be transmitted to the hire request system 210 using the communication interface 260.
  • the vehicle identifier for the vehicle servicing the hire request can be added to the hire request record by the request controller 240.
  • a complete record of the hire including the vehicle identifier and identification of the passenger or information to enable the passenger to be identified (the CLI, phone identifier, application identifier, e-mail address etc), can be stored.
  • the data store 250 of the hire request system 210 may also include or be connected to archival storage.
  • hire records of completed hires may be periodically stored to an archive such as optical or magnetic disks, magnetic tape, solid state memory banks etc., to maintain a record of hires.
  • the archived hire records may be maintained for only a limited period of time, for example a given number of weeks, months or years, depending on the system setup. Archiving records for a period of time after a hire is complete enables the hire record to be retrieved for tracking purposes.
  • the hire record can be retrieved from the archive to enable the correct taxi driver to be identified to ask whether or not the lost item was found by the driver. If necessary, by tracing subsequent hire records for the taxi, subsequent passengers for the taxi can also be identified.
  • the archived records can also be made available to law enforcement authorities investigating any alleged assault, robbery or the like during the course of a taxi trip.
  • Making the hire request is similar to utilising a Sirir vehicle booking service as described in International Patent Application Publication No. WO2007/038828 by the present applicant.
  • the full disclosure of WO2007/038828 is herein incorporated by reference.
  • a significant difference between the present hire request system and the vehicle booking service of WO2007/038828 is that in the present hire request system the vehicle for collection of the passenger does not necessarily need to be identified when the hire request is processed and a message providing the hire request reference sent back to the user.
  • Embodiments of the present system can be adapted for use with marshalling stations where vehicles do not need to be pre-booked and passengers are serviced from a queue as vehicles arrive at the marshalling station.
  • vehicles do not need to be pre-booked and passengers are serviced from a queue as vehicles arrive at the marshalling station.
  • taxi ranks where a marshal is present to assist the loading of passengers into taxis.
  • Users can record hire of vehicles using the vehicle request system even though they are being collected from a marshalling station by the next available car.
  • hire requests can be automatically triggered as a person arrives at a marshalling station, for example using Bluetooth or infra red short range radio communication between a passenger's mobile phone and a marshalling system to initiate a hire request.
  • a marshalled taxi rank can assist in maintaining safety of passengers and drivers while at the taxi rank.
  • prior art taxi ranks once a passenger in a taxi leaves the taxi rank any untoward behaviour on the part of the passenger or taxi driver can then be difficult to observe or stop.
  • Embodiments of the present system enable records to be kept of hire requests by passengers and enable the vehicle collecting the passenger to be added to the hire record via the marshalling system once the passenger is collected. This enables tracking of both the vehicles and passengers being carried in the vehicles.
  • the passenger may be traced via mobile phone records. Even in the case of pre-paid mobile phones, the ultimate owner of the prepaid phone can be traced or otherwise identified if necessary. It is envisaged that typically users will wish to register with the hire request system because of the personal securing advantages offered.
  • Embodiments also enable positive recording of the passenger and vehicle identification for hailed vehicles.
  • the system can be used to record the hail by sending a vehicle hire request, once the vehicle is hailed and even after the trip has started, by sending a hire message including the vehicle number.
  • An example of using the hire request system for making a record of a hailed taxi trip is illustrated in Figure 3.
  • a passenger 300 hails a taxi 380 from a curb side. The passenger takes note of the taxi 380 identification number displayed on the door of the taxi or within the vehicle and transmits the vehicle number to the hire request system.
  • the taxi number may be transmitted by SMS message 302, for example a user may send an SMS or other messaging service message to the telephone number of a hire request system 310.
  • a photo of the taxi number may be sent using MMS or EMS message.
  • the hire request system 310 can identify the passenger using CLI information and the vehicle number from the body of the message and a hire record can be generated.
  • the hire record can include the date and time of the message and location data is available from the phone.
  • the passenger can make a phone call to the hire request system 310 and send the taxi number using DTMF tones during the call.
  • the call may be answered by an automatic call answering service.
  • the call answering service may prompt the passenger to input the taxi number once the call is set up if the user has not already entered the taxi number.
  • the caller is identified using CLI information from the incoming call.
  • the hire record is generated including the user CLI information and taxi number. Date, time and any location information data can also be logged.
  • the telephone network base station where the call originated may provide at least rough location data that may be of value to include in the hire record.
  • an application running on a mobile phone or smart phone may be used 308.
  • the application can facilitate capture of the taxi number, for example using a photograph or manual input by the user and sending a message to the hire request system via a communication network.
  • the message may use any suitable messaging technology including but not limited to SMS, MMS, EMS, instant messaging, e-mail or FTP.
  • location identification functionality such as GPS or other navigation system technology
  • location information may also be transmitted with the message to the hire request system.
  • the user can be identified using CLI information, device identification or application registration information.
  • the received information is used by the hire request system to generate a hire record identifying both the passenger and the vehicle in which they are travelling.
  • the hire record is stored in a database 320 and a hire message can be sent to the passenger's mobile phone 330 to confirm the hire has been recorded.
  • a message may be sent to the taxi driver 380 via the taxi network 370 to give the driver notice that the hire has been recorded.
  • a user's profile may be accessible on line, for example via the internet or a smart phone application. Record of the hire may be uploaded to this online profile 340.
  • the on line profile may be accessible to authorised parties by logging on to a web site. For example, parents may be able to log in to see the on-line profile of their children.
  • the on-line profile may also be used by the user to identify the taxi used for a previous trip, if necessary. For example, if a passenger realises the following morning that they left something in the taxi they can use their on-line profile to identify the taxi company and car used. This information can then be used to call the taxi company and arrange retrieval of their lost property.
  • the user's on-line profile may also be set up to forward a message to a third party 360, such as a parent or spouse, when a taxi hire is recorded.
  • the message may be sent via SMS to the third party's phone, by e-mail to a designated e-mail address or using an instant messaging system.
  • Any update information such as trip progress (location information), fare meter information, traffic congestion notices, trip conclusion notification, etc. that may be relevant to the trip may also be forwarded to the authorised third party as the trip progresses.
  • emergency services or law enforcement authorities may be provided with access to view the hire records 350.
  • a secure web portal may be provided to enable police to request information regarding specific hire records in case of emergencies or to investigate crime accusations.
  • a vehicle hire application utilises location data obtained through GPS or other navigation functionality of the phone. This enables a hired taxi's position to be monitored via the passenger's mobile phone, independently of any vehicle tracking system. For example, in areas were GPS tracking of taxis is not enabled, a passenger's trip may be tracked utilising their phone GPS capability. Trip tracking can be performed by continuously to periodically obtaining location data for the passenger's mobile phone. The manner in which this is performed can be dependent on how mobile phone location functionality is implemented in the phone and communication network. For example, for some mobile phones or networks, phone location may be continuously tracked and this tracking data available via the communication network.
  • a person 740 may hail a taxi 750 and, using an application 760 on their mobile phone 745, record the hire in a hire request system 710.
  • a confirmation 765 of the hire record can be sent to the phone 745 using messaging, e.g. SMS, or via the application.
  • Notice of the hire record may also be sent to authorised third parties 770, made accessible to police 772 or via an on line profile 775 for the passenger.
  • the taxi 750 driver may be informed 780 that the hire is being recorded via the taxi network 730.
  • Recording the hire may also authorise the hire request service 710 to obtain location information for the phone 745 from a tracking service 720 via a communication network to enable tracking of the hire.
  • a tracking service 720 via a communication network to enable tracking of the hire.
  • MobileMeTM application for iPhonesTM and iPadsTM which stores the current device location on a network server 720 and enables a user to log onto a web site to identify the location of their device 745.
  • Users 740 may authorise a hire request system 710 to access the location data for the purpose of tracking a taxi trip.
  • an application 760 on the phone may be used to record a taxi hail 750 with the hire request system 710 and provide authorisation for the hire request system 710 to access the user's phone location information on the server 720.
  • the access to the user's phone location information may be for a limited time, for example 10-30 minutes or the anticipated length of the trip. Alternatively the access may be enabled by the hire request and disabled on termination of the trip.
  • the end of the trip may be signalled by the user using the application or automatically triggered in response to another action associated with the hire, such as making a payment for the hire via the hire request system 710.
  • an application executing on the phone 845 may periodically forward location information to the hire request system 810 from the phone 845 during the trip.
  • a user launches the taxi hire request and record application 860 on their phone and enters the taxi number of a hailed taxi 850.
  • a hire request including the taxi number, user identification information and location information is transmitted to the hire request system 810 by the application 860.
  • a hire reference can be transmitted 865 to the phone 845 to confirm the hire is recorded.
  • Notice of the hire record may also be sent to authorised third parties 870, made accessible to police 872 or via an on line profile 875 for the passenger.
  • the taxi 850 driver may be informed 880 that the hire is being recorded via the taxi network 830.
  • the application 860 can be adapted to periodically transmit location data 820a-c to the hire request system 810 with the hire reference for recording in the hire record. For example, GPS coordinates may be transmitted to the hire request system 810 every 60 seconds.
  • the periodic transmission 820a-c can be terminated at the end of the trip, say by the user pushing a TRIP END button or in response to a payment being made. Enabling the user to control the trip end by pushing a button can enable a user to ensure they are safe, such as locked in their home or with friends at their destination, before terminating tracking. Alternatively, in some embodiments tracking may continue for a specified time period, say 2 to 5 minutes, after an action indicative of a trip end, such as making a payment via the hire request system.
  • the frequency of transmission of location data can vary depending on the embodiment implemented.
  • a user may also be able to vary the frequency of location data transmission using application settings.
  • the tracking frequency may be changed in response to entering a PANIC mode in the application. For example, if a passenger feels threatened they may press a PANIC button which can in turn cause tracking frequency to be increased and an alert to emergency services to be generated from the hire request system.
  • the application may also automatically turn on image and sound capture functionality of the phone and transmit sounds and images to the hire request system for recording and, if necessary, making these available to emergency services.
  • a record of the trip and route taken can therefore be recorded for any taxi trip, even when the taxi is not enabled with tracking functionality.
  • the tracking data can be stored in the hire record which may be accessed in emergency circumstances by emergency or law enforcement authorities.
  • authorised third parties such as parents, partners or carers, may also be provided access to hire records for a passenger or provided with messages regarding a vehicle hire and trip progress.
  • a user profile for a minor may be set up such that a message is sent to their parent's mobile phone when a hire record is generated.
  • a position update may also be sent to the parent's mobile so the parent can monitor the trip progress.
  • the frequency of transmission of trip progress may be adjusted for individual users based on personal setting in the hire request system or taxi hire application.
  • a vehicle hire application may include a fare calculator feature, which calculates the approximate fare for the trip based on the route taken and known tariff data.
  • Fare tariffs are typically mandated by local government and therefore can be pre-programmed into a fare calculator.
  • GPS data throughout the trip can be used to determine the trip distance, speed, waiting times etc. from which the fare amount can be predicted similarly to the fare calculation by the taxi meter. The passenger can then use the predicted fare to confirm that the fare showing on the meter is reasonable.
  • Some additional charges may be able to be automatically entered by the fare calculator, such as late night surcharge, airport surcharge, charges for use of toll roads etc based on GPS or time information.
  • the user may also be able to input additional flag fall charges, for example surcharges, luggage fees, extra passenger fees, booking fees, hail fees etc.
  • the fare calculator may present a pick list of possible/allowed additional charges that may be added to the fare. This can enable the user to cross check the fare and any additional charges before paying the driver.
  • Fare prediction information can also be sent to the mobile phone of a third party, for example, the third party may be a parent or carer who is not a passenger but is responsible for paying the fare, for example where the passenger is a child or disabled person.
  • the predicted fare information can be sent to third party as the trip progresses or toward the end of the trip so the third party can be prepared with appropriate money to pay the driver or to verify the fare on the meter when they go to pay the driver.
  • the fare calculator may include a feature which enables a passenger to input the fare showing on the meter and the fare calculator assess whether the fare is reasonable. For example, the fare calculator may determine whether the total amount complies with given defined tariffs and additional charges which may be applied for the trip. A set of warning thresholds may be set and the passenger warned if the difference between the metered fare and predicted fare fall within the warning thresholds.
  • a metered fare within 5% of the predicted fare may give rise to no warnings
  • a metered fare in the range of 5-20% of the predicted fare may give rise to a prompt for the passenger to verify additional charges
  • a metered fare greater than 20% of the predicted fare may give rise to a warning that the fare is unreasonable. It should be appreciated that these thresholds may vary for different embodiments and may be based on discrepancy amounts rather than percentages.
  • a passenger may not want to confront the driver to challenge a fare, so the fare calculator may be adapted to facilitate sending the real and predicted fare data to the hire request system for review.
  • a modest charge may be levied for review of fares.
  • request for review of fares may be sent using premium SMS services and the fee recovered via the telecommunication network service provider.
  • the hire request record includes a record of the trip and the vehicle number
  • the fare can be independently reviewed. In circumstances where a pattern of review requests are received for a specific vehicle this may be referred to a vehicle hire company or ombudsman to follow up. For example, a vehicles meter may be incorrect and require servicing or driver behaviour need to be reviewed.
  • the hire request system may also include financial transaction capability to enable passengers to automatically pay for the hire via the system. This has the advantages of being convenient and secure. Further, where pre-payment for hire services is mandated, automatic payment via the hiring system can avoid the inconvenience of having to estimate trip costs in advance and then adjust or re-negotiate the payment at the end of the trip. The passenger can simply show the taxi driver that automatic payment is approved.
  • the hiring system may also include or be in data communication with a booking system to enable vehicles to be dispatched to marshalling stations where passengers are waiting.
  • This embodiment enables booking of a Sirir vehicle for pick up at a marshalling station.
  • a passenger wishes to hire a taxi. If the passenger is near a marshalling station the passenger can read the phone number for this marshalling station from signs appropriately placed around the marshalling station, and use this number to make a telephone call 410 using their mobile phone to the hiring system. Alternatively the passenger can use a smart phone application to send a hire request.
  • a venue may also provide a booking service, where a hire request can be sent from the venue and a hire request reference either transmitted directly to a patron's phone, if they provided the number, or to a terminal at the venue where a printed receipt can be provided giving the hire reference.
  • the passenger can present the printed receipt at the marshalling station or send a message to the hire request system via their mobile phone using the hire reference to confirm the hire.
  • the patron does not have a mobile phone other information, such as a drivers licence, passport number, or credit card number may be used to provide identification for the patron in the hire request system.
  • the printed hire reference is then shown at the marshalling station so hired vehicle identification can be added to the hire record via the marshalling system.
  • a mobile phone identification of passenger and vehicle can be recorded in the hire request system.
  • the hire request may be made using a message, such as a short messaging service (SMS) message, or via the internet, for example using an application resident on a smart phone.
  • SMS short messaging service
  • the CLI is extracted 412.
  • the targeted marshalling station can also be determined from the telephone number used to make the request.
  • the system checks whether the passenger is a registered user in the system 415. Where the passenger is a registered user, the registered user's details may be extracted from a user profile 420.
  • the user profile may include the user's name, home address, any special needs such as a disability, charge account or credit card details for automated payment for the hire service and a variety of other information.
  • a hire request reference is generated for the hire request 422.
  • the hire request reference may be an alpha-numeric code, a two-dimensional bar code, a reference number, or any suitable identifier that may be transmitted to the user via their mobile phone and read either manually or automatically by the marshalling system.
  • the hire request reference, CLI/phone identification and marshalling station identification are then stored in a hire record 424. Where other details extracted from a user profile are known, these may also be included in a hire record, such as the user's name and a subscriber identification number.
  • a hire message is prepared for sending to the user 426.
  • the hire message must include the hire request reference as this needs to be provided by the passenger to the marshal when the passenger presents at the marshalling station.
  • the hire message may also include information such as a confirmation of the location of the marshalling station.
  • the hire message may be personalised for the passenger, for example by using the passenger's name, and the hire message may also include a request to confirm whether payment for the service will be performed using information stored in the passenger's profile.
  • Confirmation of the hire may also be requested and with the confirmation there may also be a request for confirmation of the number of the passengers.
  • the hire message may be confirmed by simply replying to the SMS message with another SMS including the number of passengers in the message body.
  • the hire message may include "to confirm this hire request please reply, if you wish to use your stored credit card details for payment please include the word YES in your reply, please also include the number of passengers with your reply".
  • the passenger may reply with the message "YES 3" to indicate that yes the payment using the credit card details is approved, and that three passengers will be travelling.
  • a hire request reference is generated 430 and the hire record is created including the CLI, hire request reference and rank identification 432.
  • the hire message is prepared and sent to the passenger using the CLI information 434.
  • the hire request information may also be sent to the marshalling station 436.
  • the hire message may include a request to confirm the hire request by responding to the message via SMS and may also give the passenger the option to request a call back to enable the passenger to subscribe to the service.
  • the hire message may state
  • sending of a hire request may be triggered when a person presents at a marshalling station.
  • a terminal at the marshalling station can be provided to enable a hire message to be transmitted to the hire request system.
  • a user may manually input their mobile phone number or the terminal may be provided with a Bluetooth or IR communication interface to communicate with a user's mobile phone.
  • the hire message may be transmitted via the marshalling station or via the user's phone.
  • the hire message can include the mobile phone number and marshalling station identification.
  • the user may also be asked to input information regarding the number of passengers and any special requirements.
  • a hire message can be transmitted including a hire request reference to the user's mobile phone in response.
  • the hire request may expire after a set period of time, for example half an hour after which the hire request may be flagged as a no-show in the hire request system and if the hire record was sent to the marshalling station the hire record may be deleted at the marshalling station.
  • the passenger presents this to marshal at the marshalling station 450.
  • the marshal enters the hire request reference into the queue of the rank system 455.
  • the passenger shows their mobile phone with the hire message displayed to the marshal.
  • the marshal can read an alpha-numeric reference code from the message and input this to the marshalling system using a keypad, keyboard, touch screen or other input device.
  • the marshal can have a device which captures the bar code, for example, a scanner or takes a photograph of the bar code which is then interpreted by the marshalling system.
  • the hire request reference is entered into a queue of the rank system 455. Once the hire request reference is input to the marshalling system the marshal can direct the passenger to wait in a physical queue.
  • the order of people waiting in the physical queue should reflect the queued hire references.
  • the need for a physical queue may be alleviated.
  • a physical queue may assist in keeping people loading into vehicles in an orderly fashion.
  • the marshalling station may include numbered waiting areas, for example five numbered areas where passengers corresponding to the top five hire references in the queue may be requested to wait for vehicles to arrive.
  • the hire request reference may be sent via a short range wireless communication interface, such as Bluetooth or infra red (I ) interface, directly to the marshalling system from the passenger's mobile phone, without requiring manual intervention by the marshal.
  • a short range wireless communication interface such as Bluetooth or infra red (I ) interface
  • the hire request system is adapted to transmit hire request data to the marshalling system of the marshalling station for which the hire is requested.
  • This hire request data includes the hire request reference and CLI. Where other information, such as a subscriber name is known, this can also be transmitted to the marshalling system.
  • hire reference data is transmitted to the marshalling station
  • this can be used to verify hire references presented by passengers. For example, when a passenger presents a hire request reference at the marshalling station and this is entered into the marshalling system.
  • the marshalling system can look up the hire request reference in a table of hire request data transmitted by the hire request system to verify the validity of the hire request. If the hire request reference is not in the table or is expired, then the hire request is invalid. The passenger will need to request a new hire.
  • the hire request system transmits hire request data for a marshalling station to the marshalling system of the marshalling station.
  • the marshalling system may be adapted to add the received hire references to a queue as they are received. For example, this enables passengers to reserve their queue place by submitting a hire request before they arrive at the marshalling station.
  • the hire request will expire if the passenger has not presented at the marshalling station within a given time period. This can reduce the length of physical queues as it enables a person to arrive just in time.
  • messages may be transmitted to the passengers using the CLI to alert the passengers of their progress in the queue.
  • a display at the marshalling station may also show a top portion of the queue.
  • a sign 600 located at the marshalling station may include a screen 610 showing the lead twelve hire references in the queue. This enables passengers waiting at the marshalling station to watch the progress of the queue. In some embodiments a hire reference may not be allowed to progress to one of the top twelve places in the queue until the passenger has presented at the marshalling station.
  • the marshal When a taxi arrives at the marshalling station 460 the marshal inputs the vehicle identifier into the marshalling system using the I/O interface and is paired with a hire request in the queue 465.
  • a vehicle identifier can be read and entered into the marshalling system.
  • the marshal may enter a vehicle number or vehicle registration number into the system using a keypad, keyboard or touch screen.
  • the vehicle identification may be read from a radio frequency identification tag by a suitable reader.
  • the reader may be installed at the marshalling station to automatically read identification information from an RFID tag as the vehicle approaches the marshalling station, for example, similar to reading of vehicle identification from an RFID tag for automatic road toll payments.
  • the marshal may have a hand held reader which can be used to read a tag or bar code sticker.
  • a sticker having a passive RFID tag or a bar code may be placed in a readily accessible position on the windscreen of the vehicle.
  • the marshal can place the reader near the sticker to automatically read the vehicle identification and enter this into the marshalling system.
  • a camera may capture photographs of vehicle numbers and text recognition used to extract the vehicle number form the photograph to automatically record the vehicle number as the vehicle enters the marshalling station.
  • the marshalling controller 280 is adapted to associate the input vehicle identifier with a hire request reference for a passenger selected from the queue 295.
  • the queue is handled using a first in, first out (FIFO) regime so that the passengers that have waited the longest are allocated to the vehicles as they arrive.
  • FIFO first in, first out
  • the marshalling system I/O interface can include a display which enables the marshal to view the status of at least a top portion of the passenger queue and the vehicles allocated for the passengers.
  • An example of displayed queue and vehicle data is illustrated in Figure 5.
  • the display shows the queue of booking references 510 along with CLI and name of the passenger, where known. As illustrated only the top portion of the queue, for example the top 12 places may be shown.
  • the shown places in the queue may correspond to physical waiting bay numbers where passengers allocated for each vehicle are directed to wait for collection.
  • the vehicle identifiers of vehicles allocated for collecting the passengers can be shown in an adjacent list 520.
  • Two lines of buttons 540, 550 can also be provided. It should be appreciated these buttons 540, 550 may be physical buttons or images of buttons displayed on a touch screen. Each set of buttons is associated with a function.
  • the first line of buttons 540 can be associated with an automatic dial facility to enable the marshal to call or send a message to the passenger's mobile phone using the recorded CLI simply by pushing the button. For example, if a passenger has not taken their position at the appropriate waiting box, the marshal can call the passenger to find out where they are. Alternatively marshal may send a warning message giving the passenger a period of time, for example two minutes, to take their place or they will lose their place in the queue.
  • the row of buttons 550 beside the vehicle references can be used by the marshal to confirm the hire of the vehicle by the referenced passenger 470.
  • the marshal can check the hire references of passengers as they take their queue positions. As taxis arrive at the marshalling station, their vehicle references are read and associated with hire references based on the position in the queue. The marshal can check that the correct passengers are loaded into the correct vehicle and confirm this in the system by pressing the appropriate one of the plurality of buttons 550. This can also trigger the marshalling system to record the hire and transmit the hire record to the hire request system 475.
  • the marshalling system may also display a list 530 of vehicles in "standoff" at a waiting area or on their way to the marshalling station.
  • their "standoff" provisional queue positions can be based on estimated arrival times at the taxi rank or standoff queue order provided from the taxi network. The actual queue positions may be adjusted to actual arrival positions if the taxis arrive at the rank out of order.
  • the marshals of each station can be provided with a facility to "call up" vehicles from the waiting area as needed. The next available cars can be dispatched in response to the call up.
  • the taxi networks can dispatch the taxis from the standoff area in response to the call up, thus alleviating any need for the marshalling system to manage the standoff.
  • the marshalling system may also be able to call up vehicles from the standoff area based on special services, such as wheelchair access, infant seat or extra seat capacity.
  • first out queue handling is typically implemented, such that passengers presenting first at the marshalling station are the first to be collected by a vehicle.
  • the system may enable a marshal to override the queue order or the queue handling regime may include exceptions. For example, if a wheelchair capable taxi arrives and a wheelchair bound passenger is waiting in the queue, the wheelchair passenger may be brought forward in the queue.
  • the queue order override may be performed automatically by the system based on profile information for the vehicle. For example, a vehicle profile identifying the special capability of the vehicle may be pre-stored in memory of the marshalling system, provided to the marshalling system when the vehicle identifier is entered into the marshalling system, or provided to the marshalling system by the taxi network when the taxi is in transit from standoff or dispatch.
  • the marshal may manually enter special capability data, for example by pressing a "wheelchair” button or entering the number of passengers the taxi is licensed to carry.
  • profile or capability data may be embedded in the vehicle identifier, for example a prefix of the vehicle identifier may be used to indicate disabled capability or licensed number of passengers.
  • vehicle identifiers are transmitted to the marshalling system, then any profile information may also be transmitted.
  • the marshalling system may be adapted to automatically reassign queue position of special needs passengers based on the special capability data.
  • Queue exception handling rules may be implemented and may vary in different embodiments. Queue exception rules may also be required to comply with local regulations. For example, in an embodiment queue exception rules may give preference to wheelchair passengers over large groups for wheelchair enabled maxi or minibus style taxis, also referred to as wheelchair access taxi (WAT).
  • WAT wheelchair access taxi
  • the marshal may be provided with the capability of overriding the queue order in special circumstances. This functionality enables a marshal to alter a position in the queue.
  • a second "priority" queue may be maintained for hire requests for special needs customers, such as large groups, groups with infants, disabled passengers, elderly or infirm etc.
  • the marshalling system may also be adapted with functionality to facilitate trip sharing based on passenger destination. For example, by enable the marshal to manually enter trip share data and adjust the queue to enable consolidated groups.
  • the trip share and the identity of the sharing parties can also be updated in the hire record of each of the sharing parties.
  • passengers have indicated destination information, for example registered users indicating a trip home
  • the system may also automatically identify potential trip shares based on destination information and number of passengers. A message may be sent to the potential trip share passengers inviting them to respond if they are prepared to share. If a positive response is received from two or more trip share parties a further message can be sent confirming the trip share and updating their queue position.
  • the trip share parties may also be invited to move to a priority queue area.
  • Queue exception rules may vary between different embodiments of the system. Queue exception rules may also vary between marshalling stations or depending on the time of day. For example, the location of the marshalling station may influence the queue exception rules applied. For example, a marshalling station at a hospital may give priority to discharging patients over hospital visitors and others. In another example, a marshalling station near a school may give priority to parents with school children around school let out times.
  • the marshal can confirm that the correct passenger is getting into the vehicle by checking the hire request reference with that associated with the vehicle before the vehicle leaves the marshalling station 470.
  • the system enables association of the vehicle collecting the passenger with the hire request even when no formal booking of the vehicle has taken place and passengers are loaded into the vehicles on an ad-hoc basis.
  • the marshalling system 220 may only be adapted to associate vehicles with hire request references in response to a command received from the marshal.
  • the marshal may input a hire request reference for a passenger being collected by a vehicle when the passenger is collected and the vehicle identification also entered into the marshalling system.
  • the marshalling controller 280 associates the hire records and vehicle identifies based on the information input by the marshal.
  • the marshalling system is further adapted to transmit 475 the recorded vehicle identifier with the hire request reference to the hire request system via the communication interface 260.
  • the hire request system 210 receives this transmission via the communication network interface 230 and the request controller 240 updates the hire record 255 associated with the hire request reference to add the vehicle identification information.
  • the hire request system can also be adapted to perform a payment transaction for the hire service 485.
  • the hire request is confirmed by the marshal 470 and details of the vehicle servicing the hire is transmitted to the hire request system 475.
  • the hire request system can be adapted to communicate with the vehicle hire company system.
  • the hire request system can obtain hire rate information for fixed rate hires or hire meter information transmitted from the vehicle back to the vehicle hire company system at the conclusion of the trip.
  • the hire request system can automatically perform a payment transaction to pay for the trip service using the passenger's pre-stored credit card details.
  • the hire request system can communicate with the vehicle hire company system to arrange for payment for the trip to be billed to the hire request system's account with the vehicle hire company.
  • the hire request system can then reconcile the bill from the vehicle hire company with individual customer accounts and hire records to charge the appropriate hire fee to each individual's account.
  • the marshalling station for hire of taxis is becoming increasingly popular where there are large numbers of passengers wanting to hire vehicles and also in areas where personal safety is at risk. For example, some areas of the city where many nightclubs and bars are located can be prone to violence, particularly late at night and in the early hours of the morning. In order try and mitigate violence problems such areas may be designated no taxi hail zones, thus forcing taxi patrons to hire taxis from marshalled ranks.
  • passengers and drivers are essentially anonymous to each other when a hire is made from a taxi rank and minimal tracking of the hire is possible.
  • Embodiments of the present invention may be implemented in such areas so that all passengers hiring a taxi from a marshalled taxi rank and the vehicles collecting these passengers will be recorded by the vehicle hiring system, thus enabling records to be kept of all hires.
  • Using embodiments of the present invention designated "taxi by booking only” or “recorded hire request only” zones may be designated.
  • the request system is also associated with a booking or dispatch system
  • the demand for taxis at a particular marshalling station will be known at any one time so that vehicles may be dispatched to the appropriate marshalling station. For example, this may avoid a situation where vehicles may be waiting a vacant marshalling station whereas a nearby marshalling station had a substantial queue of passengers.
  • the present system taxis from the marshalling station that is quiet may be diverted to the busy marshalling station in order to provide better service with passengers and also minimise vacancy time for taxis.
  • Recording the hired vehicle identifier along with the CLI or other phone identifier of the hiring passenger can be used to provide additional security benefits.
  • a number may be programmed into the passenger's phone for use in emergencies which is linked to the hire request system.
  • the emergency number may be embedded in the SMS message confirming the hire request, programmed into the phone, or embedded into a smart phone application in such a manner that the passenger need only press one or a few buttons on the phone to make the emergency call.
  • the call can be made discreetly if the passenger feels threatened.
  • the hire request system can retrieve the hire record using the CLI.
  • the hire request system can then automatically connect the call through to an emergency response centre, for example the local emergency response centre receiving "000" calls in Australia or "91 1 " calls in the United States of America.
  • the emergency response operator can be provided with the details of the hired vehicle, any passenger details, hire details such as the collection origin of the hire, and any destination information provided by the vehicle driver or passenger when booking the hire.
  • the hired vehicle is enabled for location tracking, for example GPS tracking enabled, current location information can also be provided.
  • Location information may also be transmitted from the user's mobile phone or accessed via a phone location service provided via a communication network.
  • the operator can be provided with a significant amount of information regarding the persons involved in the emergency.
  • the information provided through the vehicle hire system can provide enough information to enable emergency services such as police to be dispatched. For example, a taxi carrying a passenger may be stopped at traffic lights and the driver may be attacked by assailants trying to rob the taxi driver of any cash being carried.
  • the passenger may discreetly press the required button to contact emergency services.
  • the call is connected though to the emergency response operator by the vehicle hire system and all information available for the hire request transmitted to the operator for view on the operators screen.
  • the emergency response operator may hear the shouts of the assailant and taxi driver through the phone call. Where the user's mobile phone is enabled with a camera this may also be turned on and images transmitted via the emergency call.
  • the emergency services call centre operator can determine who is involved and may also be able to determine approximately or exactly where the attack is taking place and despatch the appropriate emergency services.
  • Embodiments of the present invention may also be used for hiring and recording trips where premium vehicle hire services are used.
  • a premium service may be where a vehicle will be allocated ahead of time for a hire and guaranteed to turn up to collect the passenger at a specified time or within a specified time frame.
  • a user's registered profile may indicate that the user has a standing authorisation for using a premium service and standing authorisation for the additional fee associate with such service.
  • the hire request system may be adapted to automatically forward a hire request to the service provider for the premium service and record the allocated car in the hire record.
  • a message may be sent to the user requesting confirmation of use of the premium service. If the user replies with "NO” a regular taxi may be ordered. If the user replies with "YES” a car is ordered from the premium service. A message confirming the hire may be sent and a user may also confirm the correct pickup has taken place by return message to the hire request service. The hire can then be tracked similarly to any other hire.
  • a user may be able to request a premium hire service with a hire request.
  • a hire request message may be sent via SMS or a phone application including "VIP" in the message, indicating the user wishes to use the premium service for this hire request only.
  • VIP Voice over IP
  • the vehicle hire request service can be utilised for requesting hire of regular taxis or premium chauffeured vehicle services.
  • Embodiments of the present invention may use a number of different methods for generating revenue from the hire request service.
  • premium SMS or messaging services may be used for messages sent via the system.
  • the cost for the premium message services are charged to the user via their mobile phone bill and paid to the hire request service provider by the message service provider.
  • users may subscribe and pay a fee, for example a monthly fee or usage based fee, for enhanced services.
  • Revenue may also be derived from fees for downloading applications to utilise the service to mobile phones or smart phones.
  • the hire request service may also be funded by government bodies, for example, to ensure access to the service for all users to improve safety for the taxi industry.

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Operations Research (AREA)
  • Physics & Mathematics (AREA)
  • Educational Administration (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Game Theory and Decision Science (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Traffic Control Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention porte sur un système et un procédé de location d'un véhicule avec chauffeur, lesquels système et procédé comprennent l'utilisation, par un passager, d'un téléphone mobile pour entrer en contact avec un service de demande de location de véhicule. Le service est conçu pour recevoir des demandes de location faites par des passagers, extraire des informations d'identification de passager des demandes arrivant, générer une référence de demande de location, créer un enregistrement de location dans un magasin de données comprenant une identification de passager et la référence de demande de location, préparer un message de location comprenant la référence de demande de location, transmettre le message de location au passager à l'aide de l'identification de passager extraite de la demande de location par l'intermédiaire du téléphone mobile de passager, et mettre à jour l'enregistrement de location stocké dans le magasin de données avec un identificateur de véhicule de location une fois qu'une prise en charge a été réalisée.
PCT/AU2011/001105 2010-09-03 2011-08-29 Procédé et système pour une opération de taxi WO2012027781A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US38006610P 2010-09-03 2010-09-03
US61/380,066 2010-09-03

Publications (1)

Publication Number Publication Date
WO2012027781A1 true WO2012027781A1 (fr) 2012-03-08

Family

ID=45772003

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2011/001105 WO2012027781A1 (fr) 2010-09-03 2011-08-29 Procédé et système pour une opération de taxi

Country Status (1)

Country Link
WO (1) WO2012027781A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015099679A1 (fr) * 2013-12-23 2015-07-02 Intel Corporation Système d'autorisation embarqué pour véhicules autonomes
RU2615319C2 (ru) * 2013-11-26 2017-04-04 ДжиТи ГЕТТАКСИ ЛИМИТЕД Система и способ для заказа транспортного средства с помощью устройства связи ближнего действия
CN109214970A (zh) * 2018-08-28 2019-01-15 汪俊霞 一种带有末端精确定位乘客位置的打车系统
US11195245B2 (en) 2017-12-29 2021-12-07 ANI Technologies Private Limited System and method for allocating vehicles in ride-sharing systems
US11928862B2 (en) 2021-09-28 2024-03-12 Here Global B.V. Method, apparatus, and system for visually identifying and pairing ride providers and passengers

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002091330A1 (fr) * 2001-05-10 2002-11-14 Societe De Marques Et De Droits Derives Internationaux - Smddi Procede et systeme de reservation de taxi par boitiers individuels permettant la localisation et l'identification de l'appelant
US20090125340A1 (en) * 2005-10-06 2009-05-14 Peter John Gosney Booking a Chauffeured Vehicle
WO2009100481A1 (fr) * 2008-02-12 2009-08-20 Peter John Gosney Système automatisé de répartition de taxis au moyen de réseaux téléphoniques

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002091330A1 (fr) * 2001-05-10 2002-11-14 Societe De Marques Et De Droits Derives Internationaux - Smddi Procede et systeme de reservation de taxi par boitiers individuels permettant la localisation et l'identification de l'appelant
US20090125340A1 (en) * 2005-10-06 2009-05-14 Peter John Gosney Booking a Chauffeured Vehicle
WO2009100481A1 (fr) * 2008-02-12 2009-08-20 Peter John Gosney Système automatisé de répartition de taxis au moyen de réseaux téléphoniques

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2615319C2 (ru) * 2013-11-26 2017-04-04 ДжиТи ГЕТТАКСИ ЛИМИТЕД Система и способ для заказа транспортного средства с помощью устройства связи ближнего действия
US10424002B2 (en) 2013-11-26 2019-09-24 Gt Gettaxi Limited System and method for ordering a transportation vehicle using a near-field communication device
US11113748B2 (en) 2013-11-26 2021-09-07 Gt Gettaxi Systems Ltd Ordering a transportation vehicle using a near-field communication device
WO2015099679A1 (fr) * 2013-12-23 2015-07-02 Intel Corporation Système d'autorisation embarqué pour véhicules autonomes
US11195245B2 (en) 2017-12-29 2021-12-07 ANI Technologies Private Limited System and method for allocating vehicles in ride-sharing systems
CN109214970A (zh) * 2018-08-28 2019-01-15 汪俊霞 一种带有末端精确定位乘客位置的打车系统
US11928862B2 (en) 2021-09-28 2024-03-12 Here Global B.V. Method, apparatus, and system for visually identifying and pairing ride providers and passengers

Similar Documents

Publication Publication Date Title
US11636714B2 (en) Method and system for managing parking by dual location verification
US11222482B2 (en) System and method for an integrated parking management system
US20170308816A1 (en) Method of processing a transaction for a parking session
US20130073347A1 (en) Vehicular citation management method and system
KR102194533B1 (ko) 주차 미터기 시스템
RU2607043C1 (ru) Управление использованием одного парковочного пространства для нескольких транспортных средств посредством применения множества камер
US20170116790A1 (en) Method and system for an automated parking system
US10121172B2 (en) Parking lot monitoring system
US20120323763A1 (en) Systems and methods for monitoring and managing transportation infrastructure and locations of vehicles therein
US20120233246A1 (en) Safety system for taxi users combining reputation mechanisms and community notifications
US20120245966A1 (en) Parking management systems and methods
AU2752600A (en) Computerized parking facility management system
EP2973434B1 (fr) Système de surveillance pour parc de stationnement
CN111047718A (zh) 一种城市轨道交通安检票务融合系统
WO2012027781A1 (fr) Procédé et système pour une opération de taxi
US20170053250A1 (en) Mobile method for preparing vehicle towing fees
KR20090022201A (ko) 운송 및 운전서비스에 대한 보험서비스 제공 시스템 및방법
US20030076935A1 (en) Face-to-face rendezvous method and system
AU2019271976A1 (en) Allocation system for subordinate
TR201618793A2 (tr) Vale park si̇stemleri̇nde di̇ji̇tal görüntü i̇şlemeye dayali bi̇r yöneti̇m si̇stemi̇
WO2003025865A1 (fr) Systeme et procede destines a encourager le paiement de frais de stationnement
US20220138668A1 (en) On-demand transportation of objects
TR2023003508A2 (tr) Di̇ji̇tal otomoti̇v hi̇zmet platformu
WO2023183250A1 (fr) Système et procédé de communication anonyme avec un abonné de véhicule

Legal Events

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

Ref document number: 11820913

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205N DATED 13/05/2013)

122 Ep: pct application non-entry in european phase

Ref document number: 11820913

Country of ref document: EP

Kind code of ref document: A1