WO2014203256A1

WO2014203256A1 - Rideshare system and method of use thereof

Info

Publication number: WO2014203256A1
Application number: PCT/IL2014/050555
Authority: WO
Inventors: David REIDER
Original assignee: Reider David
Priority date: 2013-06-20
Filing date: 2014-06-19
Publication date: 2014-12-24

Abstract

A system is provided for assigning one or more passengers, from among a group of requesters, to a driver for a journey to a destination. Each requester has a requested itinerary having an origin and destination, and each driver has an itinerary having an origin and destination defining a route therebetween. The system is configured to match requesters and drivers with itineraries having compatible origin and destination points, and facilitate the driver to optimize his itinerary to be compatible with additional requesters.

Description

RIDESHARE SYSTEM AND METHOD OF USE THEREOF

FIELD OF THE INVENTION

The present disclosure is directed toward systems configured to arrange rideshares, especially those configured to operate over a computer network.

SUMMARY OF THE INVENTION

According to one aspect of the presently disclosed subject matter, there is provided a system for assigning one or more passengers, from among a group of requesters, to a driver for a journey to a destination, each requester having a requested itinerary having an origin and destination, and each driver having an itinerary having an origin and destination defining a route therebetween, the system being configured to:

• match requesters and drivers with itineraries having compatible origin and destination points; and

• facilitate the driver to optimize his itinerary to be compatible with additional requesters.

The system may be configured to consider a pickup tolerance of a driver, wherein the additional requesters are within the pickup tolerance of the route.

The pickup tolerance may comprise a distance a driver is willing to deviate from this route, and/or it may comprise an amount of time a driver is willing to deviate from his route.

The system may be configured to allow a driver to add one or more secondary origins to his route.

The system may be configured to consider a meeting tolerance of a requester, wherein the origin and/or destination of the requester is considered to be any location within the meeting tolerance of an origin and/or destination defined by the requester. The meeting tolerance may comprise a distance a requester is willing to travel from his specified origin to meet a driver, and/or it may comprise an amount of time a requester is willing to travel from his specified origin to meet a driver.

The system may be further configured to communicate with a routing server to determine the route. The system may comprise the routing server.

According to another aspect of the presently disclosed subject matter, there is provided a computer-implemented method for assigning one or more passengers, from among a group of requesters, to a driver for a journey to a destination, each requester having a requested itinerary having an origin and destination, and each driver having an itinerary having an origin and destination defining a route therebetween, the method including:

• matching requesters and drivers with itineraries having compatible origin and destination points; and

• the driver optimizing his itinerary to be compatible with additional requesters.

The method may comprise considering a pickup tolerance of a driver, wherein the additional requesters are within the pickup tolerance of the route.

The method may further comprise a driver adding one or more secondary origins to his route.

The method may be configured to consider a meeting tolerance of a requester, wherein the origin and/or destination of the requester is considered to be any location within the meeting tolerance of an origin and/or destination defined by the requester.

The method may comprise considering a meeting tolerance of a requester, the origin and/or destination of the requester is considered to be any location within the meeting tolerance of a defined origin and/or destination.

The meeting tolerance may comprise a distance a requester is willing to travel from his specified origin to meet a driver, and/or the meeting tolerance may comprise an amount of time a requester is willing to travel from his specified origin to meet a driver. The method may further comprise communicating with a routing server to determine the route.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to understand the presently disclosed subject matter and to see how it may be carried out in practice, an embodiment will now be described, by way of a non-limiting example only, with reference to the accompanying drawing, in which:

Fig. 1 is a schematic illustration of a system according to the presently disclosed subject matter; and

Fig. 2 schematically illustrates optimization of a driver's route by the system illustrated in Fig. 1.

DETAILED DESCRIPTION

The present disclosure is related toward a rideshare system. The system enables a driver to enter details about an impending trip, and for those seeking to be passengers to enter details about rides they are seeking. The system enables a driver to select passengers from among suitable requesters. The suitable requesters may be those whose origin point matches that of the driver, or whose origin point lies along or close to the route which the driver will be following. The system may be utilized to assist in arranging one or more types of right shares, for example recurring rides, onetime rides, or real-time rides.

As illustrated in Fig. 1, the rideshare system 10 comprises a central computing device 12 and a plurality of terminals 14. The computing device 12 and terminals 14 are configured to communicate with each other over a network 16, which may be any suitable communications network facilitating exchange of information, inter alia, between the computing device 12 and the various terminals 14. Typically, the network 16 is the internet, but it will be appreciated that the system 10 could be configured to communicate using any other suitable network, or a combination of two or more networks.

The computing device 12 comprises computer hardware suitable to run software and communicate via the network 16. It may comprise a single dedicated computer hosting a server configured to execute software necessary for the system 10 and to store data therefor, a single non-dedicated computer hosting such a server (for example, it may host several servers), or several dedicated and/or non-dedicated computers hosting such a server. In the latter example, one computer may be configured for executing the software, while a separate computer is configured for storing necessary data. In addition, the computing device 12 may comprise redundant servers, with two or more computers configured to carry out the same task as one another.

As such, the computing device 12 comprises one or more processors, volatile and non-volatile memory, and other components (not illustrated) required for its operation. It may comprise its own user interface (including user input devices and graphical displays), or it may be configured to be controlled remotely, for example via a network.

In addition, the computing device 12 comprises a network interface, which is configured to facilitate it to communicate with the terminals 14 via the network 16.

The terminals 14 comprise computer hardware suitable to run software and communicate by the network 16. While the plurality of terminals 14 in the system 10 may be of several types, even within a single system, each of the terminals is configured to carry out similar function. As such, each terminal comprises a processor, volatile and non-volatile memory, and other necessary components (not illustrated), as well as network interface configured to facilitate it to communicate with the computing device 12 via the network 16. Each of the terminals 14 further comprises a user interface comprising one or more input devices and a graphical display. The input devices may be one or more of a touchscreen, a mouse and/or keyboard, or any other suitable mechanism.

Non-limiting examples of terminals 14 include smartphones, network-enable personal digital assistant, desktop and/or laptop computers, tablet computers, etc.

In particular, the system 10 comprises software and/or data storage which enable it to carry out a method for arranging right shares, which will be described below. The software may reside and be processed entirely by the computing device 12. Alternatively, the software may be split among the computing device 12 and the various terminals 14, with its processing being carried out by both, mutatis mutandis.

The system 10 may utilize a mapping and/or routing system 18, 20 in order to facilitate some of the tasks. (Although illustrated as being stored and processed within the computing system 12, the mapping and/or routing systems 18, 20 may be at least partially stored and processed within the terminals 14.) The mapping system 18 contains location data, and enables the system 10 to display relevant information, such as origin and destination points. The routing system 20 may work in conjunction with the mapping system 18 to calculate routes between origin and destination points. The system 10 may comprise these systems, and/or it may be configured to utilize appropriate third-party mapping and/or routing systems, such as Google Maps, Google Earth, Bing Maps, Waze, Yahoo! Maps, etc.

In operation, the system 10 operates to assign passengers to a driver for a journey along an itinerary. It will be appreciated that the actions which are described hereinbelow as being performed by the system 10 are performed either by the computing device 12 or the terminal 14. Some of the actions may be performed by either one or both, and it is left to the discretion of the designer of a system in accordance with the present disclosure how such actions are to be implemented, mutatis mutandis.

A driver creates a user account via the terminal 14. As illustrated schematically in Fig. 1, each of the driver user accounts may be stored by the computing device 12 as an individual driver record 22. The driver's user account may contain data which includes information regarding one or more itineraries, as well as biographical data about the driver (for example, one or more of name, age, gender, smoking preference, occupation, etc.), which the system 10 may use in suggesting assignments, or other users may utilize for reference. The information regarding the itineraries may include the origin and destination points, frequency (e.g., recurring, including how often it recurs, one-time, or real-time), time of travel (which may be different for different days of the week), and how many passengers may be accommodated. The system 10 may utilize the routing system 22 in order to calculate one or more routes for each itinerary. In addition, the driver's user account may contain data regarding a "pickup tolerance", i.e., how far he is willing to deviate (either in terms of driving distance or driving time) from his route in order to pick up a passenger.

A requester creates a user account via the terminal 14. As illustrated schematically in Fig. 1, each of the driver user accounts may be stored by the computing device 12 as an individual requester record 24. The requester's user account may contain data which includes biographical information about him, for example as described above, as well as data regarding one or more requested itineraries. The information regarding requested itineraries may include origin and destination points, frequency, time of requested travel, as well as a "meeting tolerance", i.e., how far a driver's origin and/or destination point may be to the requested origin and/or destination, as well as how close in time the two may be, in order for the system 10 to consider the two to be a match. For example, a requester may request a journey leaving from a particular address any particular time, but may indicate that he is willing to meet a driver anywhere within a five block radius of the address and within 15 minutes before or after the time.

The system 10 may be configured to allow a requester to see which drivers' itineraries suit his needs. The system may present only those driver itineraries whose origin, destination, and time of travel match that of the requestor's. The system 10 may optionally present at least some biographical information about each driver to the requesters. The requesters may enter a request via the system 10 to join a particular driver for one or more of his itineraries. A requester who enters such a request is considered by the system 10 to be a "potential passenger" for the respective itinerary. It will be appreciated that the system may allow a requester to enter a request to join multiple drivers for their itineraries occurring at the same time. All requesters who enter requests for a particular itinerary are presented to the driver, via his terminal 14, as a potential passenger, as will be described below.

The system 10 may further be configured to allow a driver to see which requester's requested itineraries are compatible with his itineraries. The system may present only those requesters whose origin, destination, and time of travel match his own. The system 10 may optionally present at least some biographical information about each requester to the driver. The driver may enter an offer via the system 10 to invite a particular requester to join one or more of his itineraries. A driver who enters such a request is considered by the system 10 to be a "potential driver" for the respective requested itinerary. It will be appreciated that the system may allow a driver to enter an offer to invite multiple requesters to join his itinerary. All drivers who enter offers for a particular requested itinerary are presented to the requester, via his terminal 14, as a potential driver, as will be described below.

According to a modification, which the system 10 may use in addition to the above, the system may suggest offers to requesters and/or suggest requests to drivers, based on a determination of compatibility between the driver's itineraries and requested itineraries. In determining compatibility between a driver's itinerary and a requester's requested itinerary, the system may selectively take into account the pickup tolerance of the driver and/or the meeting tolerance of each requester.

When a driver wishes to be select passengers from among the requests he receives, he accesses the system 10, which displays on his terminal 14 a list of his potential passengers. The displaying of the list may include a text-based listing, which may include information regarding requested journeys for each of the potential passengers. The text-based listing may include at least some of the biographical information of each passenger may be displayed as well. The driver may thus consider this information when selecting passengers. For example, a driver may wish to take passengers which match a particular biographical profile (e.g., those in particular industry, etc.).

In addition to text-based listing of the potential passengers, the system may utilize the mapping system to generate a graphical representation of each of the potential passengers. The graphical representation may include, for example, a map generated by the mapping system, the driver's route, and origin points of potential passengers.

Once his potential passengers have been displayed, the driver selects passengers for his itinerary. In the case of a recurring itinerary which the driver intends to take several times a week, the driver may select each potential passenger for some days. It will be appreciated that the system 10 may be configured to allow a requester to select a driver for a requested itinerary from among offers he has received from different drivers similarly to as described above with respect to the driver selecting passengers from among the requests he receives, mutatis mutandis.

In a recurring ride example, a requester may receive on or more offers, each offer relating to itineraries on multiple days. For example, the requester may receive an offer in which a driver invites him to join each of his itineraries on Monday through Wednesday. The system 10 may be configured to allow the requester to partially accept such an offer. In the current example, the requester may accept the offer for Monday and Tuesday, but not for Wednesday.

According to a modification, the system 10 may be configured to allow the driver to manually confirm or decline requests. In addition, it may be configured to automatically accept requests based on predetermined criteria. The criteria may be, for example, requesters pre-selected by the driver, pre-selected biographical information (e.g., a driver may indicate to the system 10 to automatically accept a request from a requester who works in the same company as he does), requests that will bring a higher rate of remuneration, etc.

Once the driver confirms and/or the system 10 automatically accepts requests from potential passengers, the system 10 classifies these requests as allocated, and sends a confirmation message to each of the selected requesters for the confirmed requests. Each requester has the option of accepting or denying the confirmation, or ignoring it. If he receives multiple request confirmations (e.g., requests for different days of the week), he may selectively accept, deny, or ignore each one separately. If the requester denies the confirmation, the system 10 no longer displays it. If the requester accepts the confirmation, the system 10 classifies the allocated requests as activated, and may send a message to the driver indicating such. The message may be delivered through the system interface, or via another means of communication, such as e-mail, short message service (text message), or any other suitable means of communication. Once a request confirmation is accepted and the request is activated, the system 10 may "lock" the request, thereby preventing it from being activated through accepting a confirmation from another driver.

The system 10 may be configured to allow the driver to perform an optimization to identify additional requesters, and to subsequently amend his itinerary to enable him to accommodate one or more of them.

As illustrated in Fig. 2, in the optimization, the system 10 identifies additional requesters 26 whose origin is located sufficiently close to the route 28 of the driver's itinerary, and whose destination is sufficiently close to the destination of the driver. In identifying the additional requesters, the system 10 calculates the compatibility between the additional requesters' travel times and the time at which the driver will arrive at their origin. The system boundaries 30a, 30b on both sides of the driver's route, and identifies the additional requestors whose origin is within an "envelope" 32 defined between the two boundaries 30a, 30b.

The requester's origin may be considered to be "sufficiently close" to the route if it is within the driver's meeting tolerance, i.e., the driver would not have to deviate more than the distance or time given by his meeting tolerance in order to reach it. Likewise, the requester's destination may be considered to be "sufficiently close" to the driver's destination if it is within the requester's pickup tolerance thereof.

Once the additional requesters have been identified, the driver may instruct the system 10 to amend his route to reach some of the additional requesters, thereby adding a secondary origin point. The system 10 changes the itinerary accordingly. Requests and offers may be entered to the system 10 as above, but based on the amended route, and considering both the original origin point, as well as the secondary origin point.

It will be appreciated that the system 10 may allow the driver to add more than one secondary origin to his itinerary.

It will be appreciated that while a method has been described above by which the system 10 allocate passengers to drivers, the optimization could be performed for any suitable method, mutatis mutandis. The optimization disclosed above may enable a driver's offer to be seen by additional potential passengers before those of other drivers.

In addition, the system 10 may be configured to facilitate a payment system, wherein the driver is remunerated, for example to share in the driver's travelling expenses. The payment system is configured to collect funds from passengers, and to transfer them to drivers. The payment may be based on any suitable model, for example a flat fee per ride, which may be set by the system or by the driver, or it may be distance and/or time-based.

According to any example of a payment system, the system 10 may be configured to include safeguards which determine that a passenger has actually taken a ride with the driver before being charged.

The system 10 may further enable a driver and/or a passenger to view the status of any particular journey.

Those skilled in the art to which this invention pertains will readily appreciate that numerous changes, variations and modifications can be made without departing from the scope of the invention mutatis mutandis.

Claims

CLAIMS:

1. A system for assigning one or more passengers, from among a group of requesters, to a driver for a journey to a destination, each requester having a requested itinerary having an origin and destination, and each driver having an itinerary having an origin and destination defining a route therebetween, the system being configured to:

2. The system according to claim 1, being configured to consider a pickup tolerance of a driver, wherein said additional requesters are within the pickup tolerance of said route.

3. The system according to claim 2, wherein said pickup tolerance comprises a distance a driver is willing to deviate from this route.

4. The system according to any one of claims 2 and 3, wherein said pickup tolerance comprises an amount of time a driver is willing to deviate from his route.

5. The system according to any one of the preceding claims, being configured to allow a driver to add one or more secondary origins to his route.

6. The system according to any one of the preceding claims, being configured to consider a meeting tolerance of a requester, wherein said origin and/or destination of the requester is considered to be any location within said meeting tolerance of a defined origin and/or destination.

7. The system according to claim 6, wherein said meeting tolerance comprises a distance a requester is willing to travel from his specified origin to meet a driver.

8. The system according to any one of claims 6 and 7, wherein said meeting tolerance comprises an amount of time a requester is willing to travel from his specified origin to meet a driver.

9. The system according to any one of the preceding claims, being further configured to communicate with a routing server to determine said route.

10. The system according to claim 9, wherein said system comprises said routing server.

11. A computer-implemented method for assigning one or more passengers, from among a group of requesters, to a driver for a journey to a destination, each requester having a requested itinerary having an origin and destination, and each driver having an itinerary having an origin and destination defining a route therebetween, the method including:

12. The method according to claim 11, wherein a pickup tolerance of a driver is considered, said additional requesters being within the pickup tolerance of said route.

13. The method according to claim 12, wherein said pickup tolerance comprises a distance a driver is willing to deviate from this route.

14. The method according to any one of claims 12 and 13, wherein said pickup tolerance comprises an amount of time a driver is willing to deviate from his route.

15. The method according to any one of the preceding claims, wherein a driver adds one or more secondary origins to his route.

16. The method according to any one of claims 11 through 15, wherein a meeting tolerance of a requester is considered, said origin and/or destination of the requester is considered to be any location within said meeting tolerance of a defined origin and/or destination.

17. The method according to claim 16, wherein said meeting tolerance comprises a distance a requester is willing to travel from his specified origin to meet a driver.

18. The method according to any one of claims 16 and 17, wherein said meeting tolerance comprises an amount of time a requester is willing to travel from his specified origin to meet a driver.

19. The method according to any one of the preceding claims, further comprising communicating with a routing server to determine said route.