Dynamic ride matching system

[0001] This application claims priority to currently pending U.S. Provisional Patent Application 60/822,590, entitled, “Dynamic Ride Matching System”, filed Aug. 16, 2006, the contents of which are herein incorporated by reference.

[0002] This invention relates to transportation management systems. More specifically, this invention relates to a dynamic ride matching system that matches drivers and passengers using a novel ride matching method.

[0003] This invention includes a method of matching individuals in an online community with others they could potentially carpool with based on preferences entered by the users and the similarities in their planned trips. In the traditional ride matching (carpooling) system, the user is asked the source and destination addresses for the trip, along with the days and times when the trip will take place. The addresses are converted into x and y coordinates. The list of potential matches is narrowed down to those that fit the trip schedule and a radial search is conducted around the source and destination points. Because this is a proven technique, the invention focuses on addressing the limitations of this approach. The main limitations that are addressed are: 1) limited trip schedules—existing methods are designed for regular weekly trips (e.g. Monday thru Friday) and cannot accept other recurrence patterns; 2) focus on the end points—existing methods search for matches by looking at the end points, but this ignores potential carpoolers that lie on the driver's route; and 3) reliance on straight-line distances—existing methods base driving distance calculations on straight-line distances instead of using the actual street network and straight-line estimates can vary greatly from the true distance when dealing with barriers such as rivers or highways.

[0004] The ride matching method addresses many of the limitations associated with traditional dynamic ride matching applications. The method is unique in its ability to accept trips with schedules that cannot be expressed in terms of a simple recurrence pattern (e.g. Monday thru Friday work schedule). It can handle one-time and occasional trips. It is also distinct in its use of spatial analysis techniques to locate matches. Specifically, the use of a shortest path solver enables the ride matching method to perform a search along the path of a user's trip, in addition to the customary radial search around the endpoints. The shortest path solver is also used to calculate the driving distance between the user and a match. This provides a more accurate measurement than the straight-line distance used by other method, especially in the presence of barriers.

[0027] The present invention utilizes a geodatabase consisting of regular database tables and feature classes. Feature classes are tables that hold geographic shapes. The method requires a shortest path solver that determines the shortest path between two points in a street network.

[0028] The inputs for the method include a series of tables that describe the user's trip and the trips previously input by other users. In practice, additional fields may be added to the tables to support the user interface. The tables include the Trips Table (FIG. 9), the Locations Table (FIG. 10), the Trip Schedules Table (FIG. 11), and the Matches Table (FIG. 16). The feature classes include the Points Feature Class (FIG. 12), the Shortest Path Feature Class (FIG. 13), and the Carpool Shortest Path Feature Class (FIG. 17).

[0029] Trips Module: In one embodiment, the invention stores a plurality of parameters relating to the trips to be taken by the users. In a preferred embodiment, these parameters are stored in a Trips Table (10). A description of each of the attributes of the Trips Table (10) is shown in FIG. 9. The Trips Table (10) describes the trips that are taken by the users. When calling the method, a Trip ID (11) must be supplied to distinguish the user's trip. The Trip ID (11) is the primary key of the Trips Table (10) and acts as a foreign key for the other inputs. Each user should be assigned a User ID (12) to exclude his/her other trips from consideration. The user's beginning location is stored in the table as the Source Location (14) and the user's ending location is stored as the Destination Location (15). A trip can consist of a maximum of two legs: Leg 1 refers to the initial trip from source to destination; Leg 2 (optional) is the return trip from the destination back to the source. The user's preference of one-way or roundtrip is indicated by the Roundtrip (16) attribute. The Recurring (17) attribute indicates whether the trip occurs once or on a regular basis. The earliest and latest times a user is willing to leave the Source Location (15) are stored as the Earliest Depart Time—Leg 1 (18) and Latest Depart Time—Leg 1 (19), respectively. The earliest and latest times a user is willing to arrive at the Destination Location (15) are stored as the Earliest Arrive Time—Leg 1 (20) and the Latest Arrive Time—Leg 1 (21), respectively. If a user has chosen a roundtrip, the earliest and latest depart times that the user can leave for the return trip are stored as the Earliest Depart Time—Leg 2 (22) and the Latest Depart Time—Leg 2 (23), respectively, and the earliest and latest times that the user can arrive at the original source for the return trip are stored as the Earliest Arrive Time—Leg 2 (24) and the Latest Arrive Time—Leg 2 (25), respectively. For the Carpool Type (13) attribute, the user can choose ‘driver’, ‘passenger’, or ‘no preference’. A value of ‘driver’ indicates that the user is only willing to carpool as the driver, a value of ‘passenger’ indicates that the user is only willing to carpool as the passenger, and a value of ‘no preference’ indicates that the user is willing to carpool as either the passenger or the driver. The first and last dates of the trip are stored as the Start Date (26) and End Date (27). Once the ride matching method determines the shortest path from source to destination, the Driving Time (28) and Driving Distance (29) of the shortest path are stored in the table for use in future runs of the method.

[0030] Locations Module: In one embodiment, the invention stores a plurality of parameters relating to the user's source and destination locations. In a preferred embodiment, these parameters are stored in a Locations Table (30). A description of each of the attributes of the Locations Table (30) is shown in FIG. 10. The Locations Table (30) stores the addresses of source and destination points. Each location is identified by its address which is stored as the Location ID (31). The Location ID (31) is the primary key of the Locations Table (30). Each location is also associated with a particular user, via the User ID (12), and can be associated with several of the user's trips. The table also stores the x- (32) and y- (33) coordinates of each location.

[0031] Scheduling Module: In one embodiment, the invention stores a plurality of parameters relating to the user's required departure and arrival days and times. In a preferred embodiment, these parameters are stored in a Trip Schedules Table (34). A description of each of the attributes of the Trip Schedules Table (34) is shown in FIG. 11. The method is unique in its ability to accept trips with schedules that cannot be expressed in terms of a regular weekly trip. The method's flexibility is due to the fact that a trip's recurrence pattern is translated into a series of trip instances. A trip instance is defined as a specific occurrence of a trip. One-time trips are associated with one instance, while recurring trips are associated with several. For example, a trip that is scheduled for every Friday in March will be associated with 4 records in the Trip Schedules Table (34). One of these records will correspond to the trip that occurs on Friday, March 25. Each trip, identified by the Trip ID (11), is associated with the following time windows: {Earliest Departure—Leg 1 (85), Latest Departure—Leg 1 (86)} and {Earliest Arrival—Leg 1 (87), Latest Arrival—Leg 1 (88)}. A round-trip is also associated with the following time windows: {Earliest Departure—Leg 2 (89), Latest Departure—Leg 2 (90)} and {Earliest Arrival—Leg 2 (91), Latest Arrival—Leg 2 (92)}. Each trip instance is stored as one record in the Trip Schedules Table (34).

[0032] Points Feature Module: In one embodiment, the invention stores a plurality of parameters relating to the coordinates of the user's source and destination points. In a preferred embodiment, these parameters are stored in a Points Feature Class (35). A description of each of the attributes of the Points Feature Class (35) is shown in FIG. 12. The Points Feature Class (35) stores the geocoded source and destination line points of all the trips in the Trips Table (10). The coordinates of this line point are stored as a Shape (37) in the Point Feature Class (35). Each entry is given a unique Object ID (36) which serves as the primary key for the table. Each of the trips is linked to its corresponding entry in the Trips Table (10) by the Trip ID (11), a foreign key. The table also includes a Class (38) attribute which indicates if the point represents the source point or a destination point.

[0033] Shortest Path Feature Module: In one embodiment, the invention stores a plurality of parameters relating to the shortest path between to points. In a preferred embodiment, these parameters are stored in a Shortest Path Feature Class (39). Dijkstra's shortest path method is used to calculate a path from the user's source to destination. This path is based on the actual street network. The path is saved in the Shortest Path Feature Class (39). A description of each of the attributes of the Shortest Path Feature Class (39) is shown in FIG. 13. Each entry is given a unique Object ID (36) which serves as the primary key for the table. The coordinates of the line segment are stored as the Shape (37) and the length of the line segment is stored as the Shape Length (40). Each of the trips is linked to its corresponding entry in the Trips Table (10) by the Trip ID (11), a foreign key.

[0034] FIG. 1 shows an example of the shortest path (41) between a Source (42) and a Destination (43) on a map. FIG. 2A shows the same path (41) without the map as a background. As shown in FIGS. 2B through 2D, the shortest path (41) is split into three segments. The first segment (44), highlighted in FIG. 2B, represents the first 15% of the path (41). The second segment (45), highlighted in FIG. 2C, represents the middle 70% of the path (41). The third segment (46), highlighted in FIG. 2D, represents the final 15% of the path (41).

[0035] The next step is determining those trips in the search space whose source and destination are ‘close’ to that of the user. ‘Close’ is a relative term that, by default, is based on a percentage of the total length of the shortest path. This allows the method to scale to both local and long-distance trips.

[0036] A buffer is a zone of a specified distance around a feature. A map illustrating the buffer zones is shown in FIG. 3. Buffer 1 (47) is applied around the Source (42) with a radius of 15% of the path (41) length. For example, if the total length of the path (41) is 10 miles, the first buffer (47) will represent a radial search of 1.5 miles. Buffer 2 (48) is applied around Segment 2 (45), the middle 70% of the path (41), with a radius of 5% of the path (41) length. For a path (41) of 10 miles, this buffer (48) will represent one-half mile on either side of the path (41). Buffer 3 (49) is applied around the Destination (43) with a radius of 15% of the path (41) length.

[0037] The method creates a match list by performing a spatial query on the Points Feature Class (35) and then using the resulting Trip IDs (11) to query the attributes of the Trips Table (10) and the Trip Schedules Table (34).

[0038] Spatial Query: The method queries the Points Feature Class (35) to locate trips with Source (42) and Destination (43) points within the buffers. The method distinguishes itself in the fact that, in addition to the customary radial search around the endpoints (Buffer 1 (47) & Buffer 3 (43)), it also looks for matches within the middle of the path (Buffer 2 (48)). In the worst case, the method will find the same matches that a traditional method would. In the best case, the method is able to find additional matches by looking along the path (41). Each query results in a list of Trip IDs (11) that can then be used to query the Trips Table (10) and the Trip Schedules Table (34).

[0039] Attribute Query: A round-trip requires that a match be available for both portions of the trip. In a one-way trip, the user is either not returning to the source, not interested in carpooling for the return trip, or not concerned with carpooling with different people on each portion of the trip. A match must follow certain rules which are shown in the Table of FIG. 14. A match is found when two users both require a round-trip (51) or when both users only require a one-way (52) trip. No match is found when one user requires a round-trip and the other requires a one-way (50) trip or vice versa (53).

[0040] Users are given the option of limiting the search to only finding drivers or only finding passengers. If a preference is given, a match must follow certain rules which are shown in the Table of FIG. 15. A match is found when one user requests to be a driver and the other requests to be a passenger (55) or vice versa (56). No match is found when two users both request to be a driver (54) or when both users request to be a passenger (57).

[0041] The Trip Schedules Table (34) is queried to locate overlapping trip instances. A match must have at least one instance which overlaps with an instance of the user's trip.

[0042] Below are examples of different queries (spatial query followed by attribute query):

• • [0043] 1. Source point (42) in Buffer 1 (47), Destination point (43) in Buffer 3 (49)
    • [0044] Relative Direction=Same
    • [0045] Overlapping departure times or overlapping arrival times for Leg 1
    • [0046] If the user and match have roundtrips, look for overlapping departure and arrival date/times for Leg 2
    • [0047] Match roundtrip/one-way preference
    • [0048] Match driver/passenger preference
  • [0049] 2. Source point (42) in Buffer 2 (48), 1 (47), or 3 (49), Destination point (43) in Buffer 3 (49)
    • [0050] Relative Direction=Same
    • [0051] Overlapping arrival date/times for Leg 1
    • [0052] If the user and match have roundtrips, also look for overlapping departure and arrival date/times for Leg 2
    • [0053] Match roundtrip/one-way preference
    • [0054] Match driver/passenger preference
  • [0055] 3. Source point (42) in Buffer 3 (49), Destination point (43) in Buffer 1 (47)
    • [0056] Relative Direction=Opposite
    • [0057] Overlapping departure date/times or arrival date/times for user's Leg 2 and match's Leg 1
    • [0058] If the user and match have roundtrips, look for overlapping departure and arrival date/times for user's Leg 1 and match's Leg 2
    • [0059] Match roundtrip/one-way preference
    • [0060] Match driver/passenger preference
  • [0061] 4. Source point (42) in Buffer 2 (48), 1 (47), or 3 (49), Destination point (43) in Buffer 1 (47)
    • [0062] Relative Direction=Opposite
    • [0063] Overlapping arrival date/times for user's Leg 2 and match's Leg 1
    • [0064] If the user and match have roundtrips, look for overlapping departure and arrival date/times for user's Leg 1 and match's Leg 2
    • [0065] Match roundtrip/one-way preference
    • [0066] Match driver/passenger preference

[0067] Matches Table: If any Trip IDs (11) are returned from the queries, the matches are stored in the Matches Table (58). A description of each of the attributes of the Matches Table (58) is shown in FIG. 16. Each entry in the Match Table (58) is given a unique Match ID (59) which serves as the primary key for the table. Two trip IDs, Trip ID 1 (60) and Trip ID 2 (61), are stored for two trips that is similar in schedule and path to each other. The Trip ID of the person who should be the driver is stored in the Match Table (58) as the Driver (62). The Total Driving Time (64) attribute stores the total time the driver must travel, including pick-up and drop-off of the passenger. The Direction for Trip 1 (65) indicates if Trip 2 can travel roundtrip, leg 1, or leg 2 and the Direction for Trip 2 (66) indicates the same for Trip 1. The Relative Direction (67) attribute indicate ‘same’ if Trips 1 and 2 are traveling on the same leg or ‘opposite’ if one user is on leg 1 while the other is on leg 2.

[0068] The Total Driving Distance (63) is calculated in three steps as illustrated in FIGS. 4 through 6. Length 1 (72), as illustrated in FIG. 4, is the length of the shortest path from the Driver's Source (68) to the Passenger's Source (69). Length 2 (73), as illustrated in FIG. 5, is the length of the shortest path between the Passenger's Source (69) and the Passenger's Destination (70). Length 3 (74), as illustrated in FIG. 6, is the length of the shortest path from the Passenger's Destination (70) to the Driver's Destination (71). In the case where both the user and the match have stated that they can be drivers or passengers, the driving distance calculation is performed twice—once with the user as the driver, and once with the match as the driver. The combination with the shortest driving time will determine who is designated as the driver.

[0069] Calculating Length 1 (72) and Length 3 (74) using shortest paths has several advantages over relying on the straight-line distance between features. A straight-line distance can be deceiving because it cannot take into account barriers. A barrier can be either natural or man-made and impedes travel. Consider the following scenarios:

• • [0070] Two houses lie on opposite sides of a river. This scenario is illustrated in FIG. 7. To travel from one house, the Barriered-Source (75), to the other house, the Barriered-Destination (76), requires traveling to a bridge and crossing the river (77).
  • [0071] Two houses lie on opposite sides of an interstate. To travel from one house to the other requires traveling to an underpass.
  • [0072] A user's path requires travel on an interstate. A match lies next to the interstate. The straight-line distance from the match to the interstate is negligible. However, the user must actually travel to the nearest exit, pick up the match, and travel back to the interstate before continuing his trip.

[0073] The inclusion of Length 2 (73) in the distance calculation is to favor those matches that lie in the direction of the driver's travel. Consider a scenario, illustrated in FIG. 8, where a Driver (78) and two passengers, Passenger A (79) and Passenger B (80), have the same destination, D (81). The source points of the passengers lie at an equal distance, X (82), on either side of the driver. Lengths 1 (72) and 3 (74), represented by a distance X (82), will be identical for both passengers. However, if Passenger B (80) lies in the direction that the driver would normally travel and Passenger A (79) lies in the opposite direction, these passengers will not have the same Total Driving Distance (63) because Length 2 (73) for Passenger B (80), represented by a distance Y (83), will be smaller than Length 2 (73) for Passenger A (79). The Total Driving Distance (63) for Passenger A (79) is X+(2X+Y)+0. The Total Driving Distance (63) for Passenger B (80) is X+Y+0. All other things being equal, if the driver must choose one passenger, Passenger B (80) is the clear choice because the path deviation is smaller.

[0074] Carpool Shortest Path Feature Class: A description of each of the attributes of the Carpool Shortest Path Feature Class (84) is shown in FIG. 17. The Carpool Shortest Path Feature Class (84) stores the shortest path between two points (source and destination) of the Points Feature Class (35). Each entry is given a unique Object ID (36) which serves as the primary key for the table and the coordinates of the line segment are stored as the Shape (37). The length of the line segment is stored as the Shape Length (40). Each of the trips is linked to its corresponding entry in the Trips Table (10) by the Match ID (11), a foreign key.

[0075] The disclosure of all publications cited above are expressly incorporated herein by reference, each in its entirety, to the same extent as if each were incorporated by reference individually.

[0076] It will be seen that the advantages set forth above, and those made apparent from the foregoing description, are efficiently attained and since certain changes may be made in the above construction without departing from the scope of the invention, it is intended that all matters contained in the foregoing description or shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.

[0077] It is also to be understood that the following claims are intended to cover all of the generic and specific features of the invention herein described, and all statements of the scope of the invention which, as a matter of language, might be said to fall therebetween. Now that the invention has been described,