Routing system

FIELD OF THE INVENTION

The present invention relates to a graphic user interface client-server routing system and a method of operating a routing system.

BACKGROUND OF THE INVENTION

As rates of personal car ownership increase, road congestion is becoming a greater problem. One solution to combat the problem is car-pooling. It is known to operate server based car pooling systems within large organizations, where a driver stores his route information, including start and destination location as well as time of departure, on a server and potential passengers can then scan for suitable drivers. There are already a number of organizations running private or non-profit car-pooling systems on the Internet. These all operate through a similar text based user interface where drivers specify their start and end locations through which a passenger must either search manually or for whom the car-pool organization searches.

Such systems, however, are not very scalable and it may be difficult for a potential passenger to pick drivers that may in fact be suitable. This is because a driver may input, for example, London and Glasgow as start and end destinations, whereas a passenger travelling from Birmingham to Manchester, may not realize that their journey is a subset of that specified by the driver or, even if they do, it may be too difficult for a passenger to scan all such possibilities for a suitable start time.

Numerous U.S. Patents describe map based routing systems or client-server car-sharing systems including U.S. Pat. No. 4,360,875; U.S. Pat. No. 5,272,638; U.S. Pat. No. 5,604,676 and U.S. Pat. No. 5,758,313. None, however, disclose a system including all of the advantages of the present invention.

DISCLOSURE OF THE INVENTION

Accordingly, the present invention provides a routing system comprising: one or more maps; route defining means instantiable to respond to driver interaction with a map to define a proposed pooling route and to store said pooling route; request defining means instantiable to respond to passenger interaction to define a request for a pooling route; search means instantiable to search stored pooling routes for one or more pooling routes suitable for said request; and addition means responsive to passenger selection of a suitable pooling route to include a passenger on said route.

It will be appreciated that in the present description the term “driver” is used for someone providing information about a proposed route, it may not necessarily be the party actually driving the vehicle, but as far as a passenger is concerned this person may as well be the driver. Similarly, the term “passenger” is used for someone requesting information about a proposed route, and need not be the actual person travelling.

BRIEF DESCRIPTION OF THE DRAWINGS

An embodiment of the invention will now be described with reference to the accompanying drawings, in which:

FIGS. 1 to <b>5</b> show Navigator pages generated by a car-pooling system according to a preferred embodiment of the invention;

FIG. 6 shows a car-pooling system according to a preferred embodiment of the invention; and

FIGS. 7 and 8 illustrate the algorithms for searching the route database.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the preferred embodiment of the invention, both potential car-pool drivers and passengers connect to a car pool web server from a client computer running a web browser. The server may be within a local network, an intranet or visible across the Internet.

The server includes a home page which needs to interact with a driver or passenger to ascertain the details of the route they are to travel. In the present embodiment, this is done by presenting the driver or passenger with a map, FIG. <b>1</b>. For a company operating from one site, only one map may be required, whereas for a large organization, a database of maps may need to be searched to find the map of interest. Searching for a suitable map displayed at a suitable scale is well known and many organizations, for example, Mapquest, provides web sites with such facilities.

In any case, once a driver obtains a required map, by selecting the driver option, the driver can begin to draw the route they plan to travel, FIG. <b>2</b>. It should be seen that because HTTP is a stateless environment and that a series of interactions are required between a driver and the server, a session_ID is preferably allocated to the driver at this point. This session_ID is included in each subsequent URL connecting the driver with the server, so that the server can keep track of the interaction. Use of a session_ID is well known and is disclosed in U.S. Pat. No. 5,708,780, Open Market Inc, and in “HTML &amp; CGI Unleashed” by John December and Mark Ginsburg ISBN 0-672-30745-6, July, 1995.

Preferably, the driver clicks on a series of locations on the map to outline a route. Each time the driver clicks on a location, a URL is generated including the map coordinate. Preferably, the URL is written in CGI format, for example:

http://www.car-pool.com/cgi-bin/d_route?x_coord&amp;y_coord&amp;session_ID

where x_coord and y_coord are the coordinates clicked on by the driver and d_route is a program resident on the web server for adding driver routes to the car-pool database, FIG. <b>6</b>.

When the server receives the URL including the first pair of coordinates for a session_ID, it stores the coordinates in a route attribute in a car-pool object, then returns the map and superimposes a dot marking the first location on the route. When the user clicks on the next location a URL of the same form to the one above is generated, d_route stores the next coordinate in the above object in the car-pool database, and returns a map on which two dots marking the selected locations are linked by a line superimposed on the map, FIG. <b>2</b>.

It will be seen that in a system where maps can be displayed across many areas and at different scales, it may prove easier to search the database later if coordinates are stored in the database in world-coordinates rather than as coordinates within a specific map.

The driver preferably indicates the route is complete by clicking on a suitable screen control, in this case a “Finished Route” button, which in-turn notifies the server. In the preferred embodiment, the server responds by supplying an on-line form which the driver can now fill-in, FIG. <b>3</b>. The form includes fields including the number of pool spaces available; travel details including start time, start date and journey frequency, for example, once, daily, weekly, week-days; car details such as model, color and registration; and an e-mail address so that the driver can be contacted later. Other fields could also be provided so that drivers may also give estimated travel time to help the server calculate the estimated position of the car on the route at any given time. This information is again saved in the car-pool database.

Passengers on the other hand select the “Passenger” button on the home page displaying the required map, FIG. 1, before jumping to a passenger page, FIG. <b>4</b>. The passenger is then prompted to click on a point on the map to specify a start location for their route. A URL is then generated of the form:

http://www.car-pool.com/cgi-bin/p_route?x_coord&amp;y_coord&amp;session_ID

This launches a p_route program on the server which stores the coordinates as the start location of the journey and replies by returning the map with a superimposed circle indicating the start location. The user is then prompted to click on another point on the map to specify the end location and the process is repeated with p_route returning a map also including a square indicating the end location.

The passenger is then prompted to optionally enter a time/date they will be at their start location on the route; a maximum walking distance; and a maximum wait time. If the time and date are not entered, then all routes entered in the car-pool database will be searched. If maximum walking distance (or “travel to the pick-up point” distance) or wait are not specified, then default values can be used.

The passenger is prompted when satisfied with the entered information to click on the “Find Route” button. This generates a URL causing the p_route program to search the car pool database for previously entered routes.

The searching is preferably done by measuring a distance D between each of the start and end locations specified by the passenger with vectors linking each coordinate in a route specified by the driver with the next. This calculation is based on simple trigonometry taking into account the scale and, where necessary, origin of the map(s) on which the coordinates were plotted.

FIG. 7 shows an example of such a calculation in more detail. The slope θ of any vector in a route can be calculated from the start and end point coordinates Sx,Sy &amp; Ex,Ey of the vector. The length of a line from the passenger provided coordinate Px,Py parallel to an axis intersecting the vector can be calculated from observing similar triangles, thus

<maths><formula-text>N=M·(B/(B+A)) and Ix=Ex+N and D=(Ix−Px)·Cos θ.</formula-text></maths>

It will be seen, however, that this calculation, which doesn't even include exception checking, if carried out for every vector in the car-pool database may require a large amount of intense calculation and produce unacceptably slow performance. A simple check to avoid many such calculations is to store the maximum and minimum x and y coordinates of any route. In the example of FIG. 8, where a route comprises points P<b>1</b> . . . P<b>6</b>, these maximum and minimum points bound a box with diagonal vertices P<b>1</b>x, P<b>1</b>y &amp; P<b>6</b>x, P<b>5</b>y. Similarly, by adding and subtracting the walking distance from both passenger start and end points, only one point P is shown, in both x and y directions, respective squares, having a width and height equal to twice the walking distance are defined. If neither of the squares around the passenger points P do not overlap the box bounding a route, then this route will not be suitable and it's individual vectors need not be checked as above.

Nonetheless, if both the start end and end locations specified by the user fall within the specified walking distance of the route; if the driver start time/date for the route is before the passenger start time plus the passenger waiting time less an estimation of the travelling distance for the driver to reach the start location specified by the passenger (to prevent excess passenger waiting); if the driver start time/date and estimated travel time are after the passenger start time (to prevent any driver waiting); and there are enough spaces available in the car for the date specified—the route is deemed suitable. In this regard it should be noted a check should be made to ensure that the route is in the same direction as the locations specified by the passenger before a route is deemed suitable.

By using the criteria above to eliminate unsuitable routes, a list of suitable routes can be generated and stored temporarily, preferably indexed by the session_ID for the passenger. Preferably, P_route then returns a map on which the suitable routes are overlaid, FIG. <b>5</b>. The user is prompted to select a route by clicking on the map. Again a URL is generated and the coordinates are compared with those of the suitable routes to determine which has been selected. In this case, the search compares the distance between the selected coordinates and the vectors comprising the suitable routes to find to which route the selected coordinates lie closest.

The details for the closest route are returned and displayed on the navigator screen. The passenger is prompted, if satisfied, to enter their details including their name; their exact proposed pick-up point; and their e-mail address, so that they may be contacted later and to click the “Add Passenger” button. In a commercial system, the user may be asked to provide credit card payment details. To assist in cases of ambiguity, both passengers and/or drivers could be asked to provide their sex which may assist passengers and drivers in accepting proposals for pooling.

This and the fact the driver has provided car registration details also add to the security of the system in that both parties can be sure the other can be identified if anything happens during the journey, and this inherent security provides one of the main advantages over straight-forward hitch hiking, where a driver many never be able to identify a passenger.

Clicking on the “Add Passenger” button generates a URL which calls a program Add_pass on the server and passes the program the list of the passengers details as well as an identifier of the route selected. (This could be the original session_ID for the driver).

If the driver has provided an e-mail address, he can then be automatically contacted with a proposal to pick-up the passenger. If the driver replies acknowledging acceptance of the proposal, then the passenger can be automatically contacted to confirm acceptance of the proposal. This confirmation may even include the driver's e-mail address, enabling the passenger to communicate with the driver directly to sort out further details, if required. It should be seen that in order to prevent fraud by persons who may wish only to gather e-mail addresses, it may be prudent not to send the passenger's e-mail address to the driver, and to let a passenger decide if they wish to communicate via e-mail with a driver, once the driver has accepted their proposal.

A variation of the preferred embodiment takes advantage of the fact that potential passengers provide relatively precise information to the car-pooling system. It is therefore possible for passengers to access the system via telephone connection to a voice-recognition module which is in turn connected to the car-pool database. The module could prompt the passenger to provide start and destination locations which could then be translated to computer readable form and converted to map coordinates. The user could then give the remaining information either orally or by pressing telephone keypad buttons to provide information such as a credit card number, start time/date etc enabling the module to search the database as before. In this embodiment, information about suitable routes would have to be played back to the passenger who could select a route either by pressing a pre-determined keypad button or by replying with a pre-determined word. Acknowledgement of a driver's acceptance of the passenger could be provided by placing a telephone call to the passenger's phone number and playing a pre-recorded or computer generated message.

It will be seen that with widespread use, the present invention could significantly benefit road users. The cost savings to potential travellers could even be off-set against the initial purchase cost of a palmtop computer, sufficient to allow connection to any web sites offering the car-pooling facility or in the second embodiment any telephone costs involved in connecting to the system.

It will be seen that the present invention is both highly scalable and portable. The invention can be added to any organizations web site simply by providing the appropriate maps and adding links from the organization's existing web pages.

It will be seen that because the passenger and drivers routes and start/end locations are only placed over maps, the system does not require maps to be in any particular format. All that is required is that the scale, and the origin of the map in world coordinates should be known and this again makes the invention adaptable for implementation on web sites which may store maps in different formats.

It is not a disadvantage of the invention that the driver is not forced to follow a road accurately when setting out a route, as the walking distance factor provided by a passenger provides enough tolerance to mitigate any undesirable effects of this feature. This can also be seen as an advantage when a driver is specifying routes on a large scale map. Take, for example, a driver specifying a route from London to Glasgow. The driver may not care to divide the route into many sections following each part of the route exactly. A passenger, however, compensates for this lack of accuracy by increasing their “walking” time. Thus, a passenger pooling on a journey of 10 miles may only want to walk 0.25 miles, whereas a passenger looking for a lift of over 500 miles, may be willing to travel 30 miles to make a connection. The exact pick-up point can be negotiated once the driver has accepted the passenger on the basis of the passenger's initially proposed pick-up point.

The invention is further adaptable to enable public transport companies to include their routes on maps. Journeys need not be bookable directly through the car-pooling system, but information could be provided on available public transport timetables where no car-pooling alternative is available. Similarly, tourist companies could use the system to provide tour information or freight companies could use the system to provide delivery route information for persons wishing to send parcels, in this case the parcels are regarded as “passengers”.