WO1998054682A1

WO1998054682A1 - Generation and delivery of travel-related, location-sensitive information

Info

Publication number: WO1998054682A1
Application number: PCT/US1998/010960
Authority: WO
Inventors: David S. Booth
Original assignee: Booth David S
Priority date: 1997-05-30
Filing date: 1998-05-29
Publication date: 1998-12-03
Also published as: TW392135B; AU7703598A

Abstract

A system wherein, generally, geolocation data, map database information, and processing techniques effect the generation and use of map database information, especially to provide custom travel-related information such as dynamic route planning and guidance. The system typically generates the map database information from the movement of vehicles by passively geolocating and tracking at least one vehicle carrying a mobile transmitter. The generated information may be stored in a database of location-sensitive data for other purposes. Custom travel-related information is provided to a vehicle by passively geolocating the vehicle's mobile transmitter (typically a cellular phone), selecting relevant travel-related information from a database of location-sensitive data, and sending the selected information to the vehicle's mobile receiver (typically a cellular phone). Using a database of location-sensitive data that was derived, in part, by passively geolocating vehicles' mobile transmitters, custom travel-related information is also provided to a third party user who is not necessarily in a vehicle.

Description

GENERATION AND DELIVERY OF TRAVEL-RELATED, LOCATION-SENSITIVE INFORMATION

BACKGROUND OF THE DISCLOSURE

1. Field of the Invention This invention relates generally to travel systems, and, more particularly, to methodologies and concomitant circuitry for automatically generating map database data using geolocation information obtained by passively geolocating vehicular traffic, for reconciling generated map database data against a pre-existing map database, and for deploying a map database to provide travel-related information. 2. Description of the Background

Research investigations into technology for locating vehicular traffic have culminated in the development and deployment of numerous commercial systems and products based on such technology. Aspects of these investigations pertinent to the subject matter of the present invention are summarized below from the following points of view: (a) map database systems; (b) vehicle location systems; and (c) systems combining map database and vehicle location systems to provide travel information. The systems of (a)- (c) overlap in many respects, and the primary emphasis of the discussion for each of the systems follows from the topical heading of each sub-section; in this manner these overlaps will be readily understood and appreciated by those with ordinary skill in the art. (a) Map Database Systems

An example of one type of commercial map database system is an in-vehicle navigation system recently introduced by some automobile manufacturers and rental car agencies - such a system guides the driver of the car equipped with the navigation system to a desired destination. The in-vehicle system is generally composed of: (1) a global positioning system (GPS) receiver carried by the vehicle; (2) an in-vehicle computer system responsive to the GPS receiver, with the computer system being configured with a map database covering a pre-determined area (typically the area within a radius of the car rental agency, that is, the anticipated area of use by the car rental driver); (3) a device for inputting to the computer the desired destination; and (4) a small video monitor mounted on the dashboard to display the computer- selected route to the desired destination on the local map.

While such an in-vehicle system does provide a convenience to a traveler unfamiliar with a local area, the system is somewhat expensive because costly equipment must be replicated for each vehicle. Moreover, if a rental car is driven outside the anticipated radius covered by the local map, and the map database is not changed to reflect the new local area, then the system is virtually useless. Because the system is totally self-contained within the vehicle, there is no feasible way to download a map database representative of the current travel area. Most importantly, however, is the obvious fact that guidance systems of this type are highly dependent upon updates to the local map database. For instance, if the map database itself is not updated regularly and/or an updated map database is not loaded into the in-vehicle computer, then, for example, the proposed route may be circuitous if a freeway has recently been constructed but it is not included in the map database, or the suggested route may inadvertently use a road that is temporarily closed for construction because an updated map database has not been loaded into the on-board computer.

DeLorme, a map maker, has addressed the issue of regularly updating its map databases, but in a fundamentally different context. DeLorme provides a commercial map database product on CD-ROM, along with trip-planning software, whereby a user of the CD-ROM product may have a trip automatically determined, prior to a planned trip, by the software - the user inputs the starting point and the destination point, and a computer accessing the CD-ROM outputs the route in paper format. To update the map database, DeLorme provides access to its World Wide Web site for current information such as weather forecasts, road construction, and other road information of importance to the computer-generated route. However, updates are only as current as the latest information loaded by the Web site administrator. The updated information may be as old as hours or days; it is clear that such information is not being dynamically updated.

Of course, as alluded to above, even if maps were capable of being updated instantaneously, in-vehicle guidance systems still are expensive because each vehicle carries sophisticated electronic devices. Accordingly, to provide maximal utility to the rental car driver, a meritorious advance in the art would provide an up-to-date map with dynamic adjustments for road conditions, and even anticipated road conditions — such as rush hour traffic.

(b) Vehicle Location Systems Many travel-related systems and techniques depend on the ability to track a vehicle's location, as briefly alluded to above, and such tracking can be performed either at the vehicle or at a remote site. It is advantageous to track the vehicle, along with other vehicles, from at least one remote central site since tracking information provided by the plurality of vehicles may be synergistically utilized. There are several techniques available for remotely tracking the location of a vehicle; conventionally, such techniques are broadly categorized as "active" or "passive" geolocation.

"Active" geolocation techniques require the vehicle to take an active part in allowing a central site to determine the location of the vehicle. Active geolocation techniques generally require the vehicle to carry special equipment or initiate a special action whose purpose is to allow the vehicle to be geolocated by a central site.

One technique for active geolocation uses a GPS receiver, which performs geolocation using timing signals received from satellites. A GPS receiver, carried in a vehicle, can be connected to a transmitter that transmits the vehicle's location to a receiver at a central site. Although the transmission of geolocation data from the vehicle to the central site may be accomplished using a transmitter that was not intended specifically for geolocation, such as a cellular phone, this GPS technique is still considered to be active geolocation because the technique requires the vehicle to carry a GPS receiver. Another technique for active geolocation uses a special-purpose transmitter carried with the vehicle, that is intended to allow the vehicle to be geolocated. This is considered to be active geolocation because the primary intent of such a special-purpose transmitter is to allow the vehicle to be remotely geolocated.

"Passive" geolocation techniques allow a vehicle's location to be determined by a central site without the vehicle's specific assistance, and typically without the vehicle's specific knowledge. Passive techniques do not require the vehicle to carry any special equipment whose primary purpose is to allow the vehicle to be geolocated.

Methods have now been developed to passively geolocate a cellular phone or other mobile transmitter that was not designed specifically for geolocation purposes. Cellular phones have rapidly gained wide popularity, and are commonly used and carried in vehicles. This preponderance of vehicles carrying cellular phones and other mobile transceivers has led to new capabilities for collecting and delivering travel information.

Such methods automatically record the location of a mobile cellular telephone using the standard signals transceived by the mobile cellular phone itself, that is, without requiring or relying upon any additional components or signals, because the standard mobile cellular phone generates sufficient identifying information in the standard transceived signals to record its location. As applied to a vehicular system, this means that no additional in-vehicle components are required to locate a cellular mobile telephone (hence, the vehicle) other than the standard mobile cellular telephone itself. Thus, the meritorious advance fostered by these techniques is the ability to locate the cellular telephone using an arrangement which is located remotely from the mobile cellular telephone — and, therefore, the vehicle carrying the cellular phone.

One technique for locating a cellular phone determines the approximate location of the phone by noting the cell site in which the phone is currently operating. The cellular phone system operates by dividing geographic areas into "cells" which cover a geographic area. The layout of FIG. 1 (from the patent of Stilp, as discussed in more detail below) shows several hypothetical cells covering a given geographic area; the different shading of the cells represents that each cell employs one of seven distinct frequencies for transceiving. The cells may be irregularly shaped, but each one represents a particular operating area that is typically governed by a single antenna site ("cell site"). As a cellular phone travels, it communicates with a cell site that governs the cell in which the phone is located - a prior art arrangement is shown in FIG. 2 (again from Stilp). To allow uninterrupted communications, the cellular phone system monitors the location of the active cellular phone, and uses a protocol to hand off the call from one cell site to the next as the mobile phone travels out of one cell and into another. Thus, the cellular phone system can determine the approximate geographic location of the phone by noting the cell site in which the phone is currently operating. This can be accomplished even when the cellular phone is in "Standby" mode — it does not require an active call in progress. Other conventional methods of passive geolocation, which provide a better resolution as to the location of the mobile phone, observe a mobile transmitter's radio frequency ("RF") transmissions. Various techniques are used, such as measuring the time difference of arrival (TDOA) or angle of arrival (AO A) of the phone's RF transmissions at a plurality of receivers at known locations. Representative of passive techniques for automatically and remotely locating a cellular telephone is the subject matter disclosed by U.S. Patent No. 5,317,323 issued to Kennedy et al, U.S. Patent No. 5,327,144 issued to Stilp et al (Stilp), and U.S. Patent No. 5,465,289 issued to Kennedy. Considering the system of Stilp as illustrative of passive geolocation methods, the cellular telephone location system employs at least three cell site systems to, in effect, resolve the location of the cellular mobile telephone via "triangularization". The cellular telephone system as described by Stilp is repeated in FIG. 3, and the details on the description of Stilp are incorporated herein by reference. By way of brief overview, the system of Stilp uses three or more cell site systems 12. Each cell site includes an antenna as part of system 12. The cell site systems are coupled to a central site via telecommunications paths 14. The central site 16 is further coupled to database 20, which may be remotely located from the central site and made available to customers (e.g., elements 22, 24, 10b). Locations of multiple mobile cellular telephones are determined by each phone initiating periodic signal transmissions over one of a prescribed set of control channels. The central site system processes the signal transmissions to thereby generate the differences in times of arrival of the signal transmissions and, on the basis of the times of arrival, determines the location of the cellular telephones originating the cellular telephone signals.

The pedagogical insight provided by the teachings and suggestions of Stilp with respect to the operation of a conventional cellular system, especially as set forth in Stilp' s background, serve as one point of reference for the departure from the art in accordance with the subject matter of the present invention.

(c) Travel Information Systems

Another common need in systems that provide travel-related information is the ability to represent road segments and travel time information in a form that is convenient for algorithmic use, for example, to be able to compute the fastest route from a source to a destination. A compilation of road segments and, optionally, travel time information, determines a map database for the covered geographical area. A graph representation for road segments composing the map database is often convenient for use by algorithms that provide traveler information services. Graph theory is a well-developed branch of computer science and mathematics, and has established many well-known algorithms for solving common graph problems. For example, there are several well-known graph algorithms for computing the fastest route from a source to a destination.

In graph theory, a "directed graph" is a set of directed links and a set of nodes. A "node" represents an idealized physical position, and would typically have some kind of map coordinates associated with it. A "link" in a directed graph is a directed connection from one node (the "FromNode") to another node (the "ToNode"). A link represents a travel path on one or more road segments, leading from the position indicated by the FromNode and going to the position indicated by the ToNode. The link may also be labeled with additional information, such as the name(s) of the road segment(s) that this link represents, the travel time required to traverse this link, and the width of the road segment(s) that this link represents, as shown in FIG. 4 wherein nodes 107a, 107b, 107c and 107d and links 106a, 106b and 106c compose a directed graph. In FIG. 4, link 106b connects from its FromNode 107a to its ToNode 107b; link 106c connects from its FromNode 107b to its ToNode 107c; and link 106a connects from its FromNode 107b to its ToNode 107d. Dashed box 105a represents the width of the road segment corresponding to link 106a.

Travel-related systems have been developed that use databases to store location- sensitive information such as travel times or traffic conditions for specific areas or road segments. Such databases can be characterized as providing either "static" or "dynamic" information. "Dynamic" location-sensitive information is location-sensitive information that is derived from real-time or near-real-time observations of current travel conditions. Dynamic information is intended to represent current travel conditions, as opposed to average or typical travel conditions. "Static" location-sensitive information is location-sensitive information that reflects assumed travel conditions and does not make use of current observations or measurements of current travel conditions. Static information is usually intended to represent typical travel conditions, as opposed to current travel conditions.

Representative of techniques addressing the tailoring of route information for each individual driver of an automobile traveling within a pre-determined geographical area is the subject matter disclosed in U.S. Patent No. 5,523,950 issued to Peterson. As disclosed in Peterson, stationary sensors are physically and regularly placed along each roadway in a local area over which vehicular traffic will be routed. The sensors measure the velocity/speed of each automobile passing each sensor, and this measured speed is, in turn, transmitted to a centralized database. The system of Peterson is more fully described with reference to FIG. 5 (FIG. 3 of Peterson). In FIG. 5, which is a stylized grid for a region, the interconnecting points for a variety of route segments are represented by similar letters A' , B' , etc. Accordingly, the various route segments may be similarly represented as A'-B' , C'-D', etc. Similarly, with A' and E' respectively representing point of origin and destination, then alternate paths of travel could be represented as A'-B'-C'-D'-E' and A'-I'-H'-F'-E' . Rate of travel sensors (SI, S2, etc.) in one direction, based on such technology positioned along each of the route segments throughout the entire grid.

The individual sensors are interconnected with the central computer 12 so that central computer 12 has continuing access to instant rates of travel for all of the route segments in the grid. The central computer, using an appropriate algorithm, may calculate and transmit information of the shortest elapsed time routes for origin- destination combinations to respective users.

The pedagogical insight provided by the teachings and suggestions of Peterson with respect to the operation of a conventional cellular system and the delivery of elapsed ti e information serve as another point of reference for the departure from the art in accordance with the subject matter of the present invention.

As may now be readily appreciated from the foregoing discussion of the prior art, the prior art is devoid of teachings or suggestions for using geolocation data derived from movement of standard cellular telephones to automatically and dynamically generate up- to-date map databases.

Moreover, once it is recognized that it is possible to automatically and dynamically generate map database data representative of the accessible highways and roadways, it is further contemplated that a map database containing such data can be used to address a myriad of highway traffic conditions and problems, as well as providing optimal guidance information to travel from a given source to a desired destination. For instance, there is a need to "reconcile" a vehicle's reported coordinate position against an existing map database of road location information to determine the location of the vehicle relative to the locations of known roads. SUMMARY OF THE INVENTION

Shortcomings and limitations of the prior art are obviated, in accordance with the present invention, by methodologies and concomitant circuitry wherein, generally, geolocation data, map database information, and processing techniques effect the generation and use of the map database, especially to provide custom travel-related information.

Broadly, in accordance with one aspect of the present invention, a system for generating map database information from the movement of vehicles includes: (i) a source of vehicle geolocation data obtained by passively geolocating at least one of the vehicles carrying a mobile transmitter; and (ii) a processor for processing the vehicle geolocation data by applying a prescribed algorithm to select a tracking sequence representative of at least two reported positions of at least one of the vehicles, and then to estimate the location of at least one road segment to thereby generate the map database information. Moreover, in another embodiment, the processor further includes reconciliation means for reconciling the tracking sequence with road location data stored in a map database. In addition, the processor further includes estimation means for estimating a travel path of a vehicle along one or more road segments corresponding to the tracking sequence.

Broadly, in accordance with another aspect of the present invention, a system for providing custom travel-related information to a vehicle is cooperatively arranged with a map database of location-sensitive information relevant to one or more geographic areas. The system includes: (i) a geolocator for passively geolocating the mobile transmitter, (ii) a selector for selecting travel-related information from the map database by applying a selection algorithm based on a reported location of the vehicle to produce the custom travel-related information, and (iii) a delivery system for delivering the custom travel- information to the mobile receiver.

Broadly, in accordance with yet another aspect of the present invention, a system for providing custom travel-related information to a remotely located user is arranged cooperatively with a map database of location-sensitive information relevant to one or more geographic areas. The system includes: (i) a selector for selecting travel-related information from the map database by applying a selection algorithm based on one or more locations to produce the selected travel-related information, and (ii) a delivery system for delivering the selected travel-information to the user at the remote location.

Accordingly, the inventive subject matter provides a way to automatically generate map database information and provide custom travel-related information to remote users, either carried by a vehicle or not carried by a vehicle. In each aspect, the system is centralized in the sense that it is operated at one or more central locations.

The methodologies and concomitant circuitry exploit certain capabilities of cellular phones and other mobile transmitters and receivers, namely: (1) the ability to passively geolocate a vehicle from the RF transmissions and communications of its cellular phone or other mobile transmitter; (2) the ability to transmit information from a vehicle to the central system using the vehicle's cellular phone or radio transmitter; and (3) the ability to transmit information from the centralized system to a vehicle using the vehicle's cellular phone or radio receiver. These capabilities, working together, create the ability to collect and deliver useful travel information without relying on additional special geolocation or communications equipment in the vehicle. The use of passive geolocation of a vehicle's cellular phone or other mobile transmitter, as opposed to other means for vehicle geolocation, provides some special features, namely:

(1) generally, the vehicle is not required to carry any special equipment other than an ordinary cellular phone, which many vehicles already carry;

(2) the generated map database information reflects roads that are actually used, as opposed to roads that may physically exist but are closed to traffic;

(3) the generated map database information can automatically reflect current roads, as opposed to roads that no longer exist or do not yet exist, because the information can be generated from current vehicle travel patterns;

(4) systematic geolocation errors that occur in generating the map database may be self-canceling when the map database is later used in determimng a vehicle's location. For example, if vehicle locations are incorrectly but consistently reported on a certain road segment, a map database may be produced that incorrectly indicates the position of that road segment. However, when a vehicle on that same road segment is later geolocated, if the geolocation error is consistent, then the vehicle's reported location will still correctly indicate the road segment on which said vehicle is traveling;

(5) the resulting map database can automatically indicate the direction of travel of each road segment, in contrast with satellite photo or other physically-based maps; (6) the resulting map database can reflect either current or historic travel time information for each road segment, or both; and

(7) the travel time information is based on measurements of vehicles' actual travel times, rather than assumptions based on speed limits and distances.

BRIEF DESCRIPTION OF THE DRAWINGS The teachings of the present invention can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 depicts a prior art cellular grid in which a cellular phone system is deployed;

FIG. 2 depicts a prior art cellular system for transceiving and cell hand-off;

FIG. 3 depicts a prior art cellular system for passively geolocating mobile telephones; FIG. 4 depicts a directed graph of nodes and links;

FIG. 5 depicts a prior art cellular system for sensing vehicle movement and for providing elapsed travel time information to individual users;

FIG. 6 depicts a high-level block diagram of the geolocation system, processing system, and map system in accordance with the present invention; FIG. 7 shows a Vehicle traveling along a roadway, a reported VehicleLocation position, and a RadiusOfAccuracy pertaining to the VehicleLocation position;

FIG. 8 shows a Vehicle traveling along a road and several VehicleLocation positions from a TrackingSequence;

FIG. 9 is a flow diagram for an illustrative Processing Algorithm; FIG. 10 and FIG. 11 each show a TrackingSequence represented by a series of connected positions through which a Vehicle has traveled;

FIG. 12 is a composite of the TrackingSequences of FIG. 10 and FIG. 11;

FIG. 13 depicts the results of overlaying numerous TrackingSequences, including the TrackingSequences of FIG. 10 and FIG. 11; FIG. 14 shows smoothed VehicleLocation positions derived from the reported positions of FIG. 9 by weighted average;

FIG. 15 shows successive VehicleLocation positions obtained by discarding some internal records;

FIG. 16 shows a cluster of VehicleLocation points in close proximity; FIG. 17 depicts the VehicleLocation points of FIG. 16 after points in close proximity are eliminated; FIG. 18 illustrates a directed graph representation obtained from VehicleLocation data of FIG. 17;

FIG. 19 shows a road link, a reported VehicleLocation position, and a corresponding RoadPosition; FIG. 20 shows the result of dividing the link of FIG. 19 into two links using a reported VehicleLocation;

FIG. 21 shows an alternative to FIG. 20 wherein a link of FIG. 19 is divided into two links, each connected to a node coinciding with the VehicleLocation;

FIG. 22 shows an exemplary directed graph containing RoadPositions corresponding to a TrackingSequence, as well as one TravelPath;

FIG. 23 shows the same directed graph with an alternative TravelPath;

FIG. 24 shows the reconciliation of ambiguous RoadPosition data;

FIG. 25 shows a technique for partitioning a travel time over road links using an expected travel time for each of the road links as a weight in partitioning the travel time; FIG. 26 shows several road links with expected link travel time;

FIG. 27 shows the road links of FIG. 26 along with Road Positions corresponding to VehicleLocations in a TrackingSequence;

FIG. 28 shows the road links of FIG. 26 and the result of splitting the road links according to expected travel times; FIG. 29 shows the results of recombining the road links of FIG. 28 into the original road links from FIG. 26;

FIG. 30 shows a hypothetical TrackingSequence following the path of an airplane that flies across two roadways;

FIG. 31 shows a hypothetical TrackingSequence following the path of an off -road vehicle that drives off of a roadway;

FIG. 32 shows a series of road links, in bold, representing a road, and a number of observed TrackingSequences representing travel along the road; FIG. 33 depicts the road links of FIG. 32 after adjusting their positions to better match the average positions of the observed TrackingSequences.

FIG. 34 depicts road links, in bold, representing a road's physical location, as determined from aerial photography, with the dashed lines representing a logical road location as estimated from geolocation data reported by the Geolocator;

FIG. 35 shows an alternative representation for VehicleLocation positions as node names within a directed graph;

FIG. 36 depicts a high-level block diagram of a geolocation system, map system, a selection processor, and guidance system in accordance with another aspect of the present invention;

FIG. 37 is a flow diagram for an illustrative embodiment of a SelectionAlgorithm;

FIG. 38 depicts the estimation of the direction or anticipated future path of a Vehicle using the Vehicle's current and previous road positions;

FIG. 39 depicts the use of a stored profile history of a Vehicle's route; FIG. 40 depicts a high-level block diagram of a map system, a selection processor, and a guidance system in accordance with still another aspect of the present invention;

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.

DETAILED DESCRIPTION After considering the following description, those skilled in the art will clearly realize that the teachings of my invention can be readily utilized to generate location- sensitive map database information, and that such information can be stored in a database. Moreover, those skilled in the art will readily appreciate that, once such a map database of location-sensitive information is produced, by these or other methods, it is feasible to deliver custom travel-related information to a Vehicle. In addition, the map database may be used to provide custom travel-related information to a third party. Finally, it is readily contemplated from the above description that the techniques engender the very creation of a map database. By way of terminology, in this description, the terms "road", "roadway", "street", or "highway" are intended to indicate any designated public or private road, street, highway, freeway, thoroughfare or other passageway on which a vehicle is intended to travel. Furthermore, although this description frequently refers to "travel times", it should be understood to also cover any implementation that instead uses a simple encoding from which such travel time information can be easily derived — for example, by representing travel speed over a known distance.

FIRST MAJOR EMBODIMENT:

GENERATING MAP DATABASE INFORMAΗON The description is this section commences with an elucidation of an illustrative embodiment that automatically generates location-sensitive map database information. More complex embodiments that provide other capabilities follow in the sequel.

With reference to FIG. 6, system 100 is composed of the following components: (a) source 101 of vehicle geolocation data, referred to as the Geolocator; (b) map database information storage device 102, referred to as the MapDatabase; and (c) interposed processor 103, referred to as the Processing Algorithm. (Although these components are set forth as discrete elements for discussion purposes, it will be readily appreciated that one or more elements may be merged into a single component; for example, storage device 102 and processor 103 may be only one physical component, such as a computer, performing the functionality desired of storage device 102 and processor 103.)

It is initially presumed, by way of concreteness but without loss of generality, that the vehicle geolocation data is provided in real time by passively geolocating at least one vehicle 104 carrying a mobile transmitter. System 100 operates by receiving geolocation data from the Geolocator 101 and applying the ProcessingAlgorithm 103 to the received data, in conjunction with map database data supplied by MapDatabase 102.

To fully elucidate the operation of system 100, each system element and the interaction of each element with the other elements are now described in more detail.

The Geolocator is responsible for providing tracking data on the locations of a vehicle ("Vehicle"), determined at different times by passively geolocating the Vehicle's mobile transmitter. A "tracking interval" is the period of time during which the Vehicle's location is tracked. Use of passive geolocation of a Vehicle's mobile transmitter, as opposed to other techniques of vehicle geolocation, provides some special benefits that will be appreciated later. For generating location-sensitive map database information, the Geolocator must provide sufficient location data to indicate a sequence of at least two locations through which a Vehicle has traveled during the tracking interval. Each Vehicle location datum ("VehicleLocation") indicates or implies the instantaneous position of the Vehicle. The position may be represented by a point position, but it could be represented in other ways also. For example, a position could be represented by an area (a circle, rectangle or some other area designation) in which the Vehicle was estimated to be located at the time of geolocation.

In addition to indicating a Vehicle's position, a VehicleLocation may also be considered to include additional information such as the absolute or relative time at which the Vehicle was geolocated ("TimeStamp"), a measure of how accurate the reported position is thought to be, or a code that identifies the Vehicle that was tracked ("VehiclelD"). The VehiclelD could be the Vehicle's cellular phone number, for example. However, for privacy reasons it may be preferable to use an arbitrarily assigned code. The measure of accuracy might be a radius of accuracy ("RadiusOf Accuracy"), for example. With reference to FIG. 7, there is shown Vehicle 108, traveling along a roadway 109, a reported VehicleLocation position 110 of Vehicle 108, and a RadiusOf Accuracy 111 pertaining to VehicleLocation position 110.

A "TrackingSequence" is a collection of two or more time-ordered VehicleLocation records pertaining to one Vehicle during one tracking interval. The time ordering of the VehicleLocation records may be indicated by the order in which the VehicleLocation records are delivered, by a Time Stamp associated with each VehicleLocation record, or by any other means sufficient to indicate a time ordering among the records.

The Geolocator must provide VehicleLocation data suitable for tracking at least one Vehicle through at least two VehicleLocations. However, in a preferred embodiment, the Geolocator could provide VehicleLocation data on more than one Vehicle, in which case the Geolocator must provide sufficient information to allow the ProcessingAlgorithm to distinguish between the VehicleLocation records of different TrackingSequences. The way this is accomplished is immaterial to system 100. However, one way it could be done is to include a unique TrackingSequence identifying code with each VehicleLocation record. This identifying code could be derived from the VehiclelD, for example.

Table 1 shows several possible VehicleLocation records. Each row in Table 1 represents a VehicleLocation record, including a VehiclelD, a position (e.g., x,y coordinate) and a TimeStamp.

Table 2 shows the same VehicleLocation records as Table 1 , but the rows of Table 2 have been sorted by VehiclelD, so that the VehicleLocation records for VehiclelD 12023861234 are grouped together as a TrackingSequence, and the VehicleLocation records for VehiclelD 13017729988 are also grouped together as another TrackingSequence.

Although different TrackingSequences may pertain to different vehicles, different TrackingSequences may also be obtained from tracking the same Vehicle during different tracking intervals.

The Geolocator may either provide real-time or non-real-time VehicleLocation data. In one embodiment, the Geolocator provides real-time VehicleLocation data to the MapDatabase. (For example, the Geolocator may periodically report the VehicleLocation of one or more vehicles.) From the data produced by the Geolocator, the ProcessingAlgorithm can select a TrackingSequence for a Vehicle, such as by re-ordering the data according to the TimeStamp, as illustrated in Table 3. By plotting and connecting the sequence of positions indicated in the

TrackingSequence, the approximate travel path of the Vehicle emerges, as illustrated in FIG. 8. If the Vehicle's travel was along roads, and the TrackingSequence contains sufficiently frequent and accurate VehicleLocation data, then this travel path indicates the approximate positions of the roads on which the Vehicle has traveled. FIG. 8 shows vehicle 112 traveling along a road 113, and several VehicleLocation positions 114a-k from the TrackingSequence of Table 3.

The ProcessingAlgorithm is illustrated in the flow chart of FIG. 9. The ProcessingAlgorithm begins at Start block 901 and inputs VehicleLocation data from the Geolocator via processing block 902, selects one or more TrackingSequences via processing block 903, optionally processes them further in block 904, as discussed later, and either outputs or stores the results as indicated by processing block 905. The end of processing is indicated by Done block 906. In one embodiment, the ProcessingAlgorithm may output the result of its computations for use by external devices or storage in an external database. In another embodiment, the ProcessingAlgorithm may store the result of its computations in a location-sensitive information database that is a part of system 100, for example, in MapDatabase 102 of FIG. 6. In one embodiment (not shown in FIG. 6), system 100 could also provide access to the MapDatabase for use by other devices or users at remote locations. In general, VehicleLocation data coming from the Geolocator 101 will represent data for multiple TrackingSequences. Individually, each TrackingSequence represents a series of connected positions through which the Vehicle has traveled, as depicted visually in FIG. 10 and FIG. 11. FIG. 10 shows a TrackingSequence 116 comprising many VehicleLocation positions, a few of which are labeled as VehicleLocation positions 115a- d. FIG. 11 shows another TrackingSequence 117 comprising many VehicleLocation positions that are not individually labeled in FIG. 11.

When multiple TrackingSequences are accumulated and considered together, a composite map is obtained, as depicted visually in FIG. 12, which is a composite of FIG. 10 and FIG. 11, that is, FIG. 12 shows TrackingSequence 116 and TrackingSequence 117 plotted together.

If the Geolocator produces sufficiently frequent, precise and accurate VehicleLocation data, and if a sufficient number of TrackingSequences are accumulated, a rough map of the area's roads emerges, as illustrated in FIG. 13, which shows several TrackingSequences plotted together, including TrackingSequence 116. By selecting TrackingSequences from the VehicleLocation data produced by the Geolocator 101, system 100 has generated map database information independent of any pre-existing information, such as map database data with roads and road names. The map database information may either be stored as a stand-alone database, or outputted to another device for deployment.

I. Variations of the First Major Embodiment

There are many possible variations of system 100 described above that can be implemented by adding additional functions, as performed via processing block 904 of FIG. 9, to the ProcessingAlgorithm. Such functions can be applied individually or in various combinations. Several possible additional functions that the ProcessingAlgorithm might perform are now described.

A.) DATA SMOOTHING:

One additional function the ProcessingAlgorithm might perform would be data smoothing on the VehicleLocation data for each TrackingSequence. Data smoothing is not necessarily desirable if other data massaging techniques will also be applied, because it necessarily involves a loss of information, but it can be helpful in obtaining a more visually understandable plot of the resulting VehicleLocation data.

To perform data smoothing, a prescribed algorithm can be applied to identify and correct for seemingly random variations in the VehicleLocation data. For example, for each pair of successive positions in a TrackingSequence, a new position could be computed as a weighted average of the successive positions and the original position.

Other methods of smoothing could be used instead. FIG. 14 shows smoothed positions 118a-k, which were derived from reported positions 114a-k of FIG. 8 by weighted average. FIG. 14 also shows Vehicle 112 and road 113. B.) CONSOLIDATION OF DATA:

Another function the ProcessingAlgorithm could perform is to consolidate VehicleLocation data. A prescribed algorithm can be applied to reduce the number of VehicleLocation records in a TrackingSequence. For example, successive VehicleLocation records whose positions are in a sufficiently straight line could be consolidated by discarding some internal records, as illustrated in FIG. 15. Table 5 shows the VehicleLocation records from Table 4, with records 2, 5, 7 and 10, representing positions 118b, 118e, 118g and 118j, shown shaded to indicate that they have been selected for deletion. Table 6 shows the result of deleting records 2, 5, 7 and 10, representing positions 118b, 118e, 118g and 118j, from Table 5. The

VehicleLocation records of Table 6 are shown in FIG. 15, which shows Vehicle 112 on road 113 and remaining VehicleLocation positions 118a, 118c, 118d, 118f, 118h, 118i and 118k.

CM. CONSOLIDATION OF SUB-SEQUENCES: Another function the ProcessingAlgorithm can perform is to apply a prescribed algorithm to consolidate a sub-sequence of VehicleLocation records whose positions are sufficiently close together. This typically occurs when a Vehicle is stopped. For example, in Table 7, records 7-27 form a cluster of points in close proximity.

The points of Table 7 are illustrated in FIG. 16, which shows a cluster 120 of points in close proximity, corresponding to records 7-27 of Table 7.

One way to consolidate a sub-sequence of VehicleLocation records whose positions are sufficiently close together is to discard some of them. For example, each successive point in a TrackingSequence that is within some radius of the previous retained point is discarded. Table 8 shows the VehicleLocation records remaining after deleting rows 2, 3, 5, 7-27, 29, 30, 32 and 33 from Table 7.

FIG. 17 shows the VehicleLocation positions of Table 8. FIG. 16 and FIG. 17 also show the VehicleLocation positions 119a-f that were not discarded in this process.

P.) CONVERSION TO A DIRECTED GRAPH:

Another function the ProcessingAlgorithm can perform is the conversion of the VehicleLocation data into a directed graph representation. FIG. 18 illustrates a directed graph representation of the data from Table 8. FIG. 18 shows nodes 121a-f, corresponding respectively to points 119a-f of FIG. 17. FIG. 18 also shows links 122a-e connecting nodes 121a-f. For the purposes of this discussion, assume that the graph is represented as a list of nodes and a list of links. However, it should be apparent to one skilled in the art that there are several well-known ways to represent a graph, and the specific representation is not an essential aspect of system 100. Table 9 shows a list of nodes for FIG. 18. Each row in Table 9 is derived from the corresponding VehicleLocation in Table 8, and represents one node.

Table 10 shows a list of links for FIG. 18. Each row in Table 10 represents one link, connecting from the FromNode to the ToNode. A link was generated for each pair of adjacent VehicleLocation records within a TrackingSequence. The direction of the link from the FromNode to the ToNode indicates the direction in which the Vehicle traveled, as indicated by the ordering of the VehicleLocation records in the TrackingSequence.

Table 10 also shows the TravelTime for each link, which is the difference between the TimeStamps of the VehicleLocation records corresponding to the FromNode and ToNode of the link. This TravelTime data is useful for services that compute the fastest route from a source location to a destination location, for example.

These discussions have demonstrated how the ProcessingAlgorithm can perform additional functions to produce more useful data from selected TrackingSequences, and, in particular how the ProcessingAlgorithm can convert TrackingSequence data into data representing a directed graph. π. Reconciling VehicleLocation Data Against an Existing Map Database

Another function the ProcessingAlgorithm might perform is that of reconciling new VehicleLocation data against an existing map database of known roads - in other words, to determine the relationship between a Vehicle's reported position(s) and the locations of known roads. The primary purposes of this reconciliation are to determine the Vehicle's instantaneous position on a road segment, and/or to determine the Vehicle's travel path along one or more road segments.

The process of reconciliation requires a map database. Such a database could be externally supplied, or in another embodiment it could be a map database that was generated by system 100. In fact, in a preferred embodiment, such a database could be automatically updated continuously by system 100. For simplicity, it is assumed that the map database data is represented by a directed graph, i.e. , a set of nodes and directed links in which each link represents a road segment or "road link". However, other representations are possible also. One purpose of reconciling a VehicleLocation datum against an existing map database is to estimate the position, along a road link, that corresponds to the VehicleLocation that was reported by the Geolocator. A position along a road link in the graph is called a "RoadPosition". If each road segment is represented as a sequence of one or more connected links in a graph, then for convenience, a RoadPosition can be represented as an additional node that divides a link (the "original link") into two links (the "new links") at an appropriately interpolated location that represents a position along the corresponding road segment. The interpolated location for the new node can be selected using a prescribed algorithm incorporating trigonometric formulas. For example, select the new node position as the position on a straight line, leading from the FromNode to the ToNode, that is closest to the VehicleLocation position for which a RoadPosition is to be selected. In addition, if the original link had a travel time associated with it, then the travel time could be divided between the two new links using an appropriate formula. For example, the travel time could be prorated according to the travel distance that each of the new links represents. FIG. 19 shows a road link 124 from node 123a to node 123b; a reported

VehicleLocation position 125; and a corresponding RoadPosition 126.

FIG. 20 shows the result of dividing link 124 of FIG. 19 into two links, link 127a and link 127b. Links 127a and 127b have replaced the previous link 124. VehicleLocation position 125 is shown in FIG. 20. FIG. 20 also shows a new node 123c, which represents RoadPosition 126 corresponding to VehicleLocation position 125.

If it is assumed, for example, that the TravelTime for link 124 is 10 minutes, and the distance from node 123a to node 123b is 10 miles, and the distance from node 123a to node 123c is 4 miles, and the distance from node 123c to node 123b is 6 miles; then assign a prorated TravelTime of 4 minutes to link 127a and a prorated TravelTime of 6 minutes to link 127b. In other words, when link 124 is split into links 127a and 127b, the TravelTime of link 124 is distributed among links 127a and 127b.

Another way to select the new node position for the RoadPosition corresponding to VehicleLocation position 125 is to directly use the reported VehicleLocation position, as illustrated in FIG. 21, which shows a new node 123d that is coincident with VehicleLocation position 125. In FIG. 21 two new links, link 128a and link 128b, replace previous link 124 of FIG. 19. FIG. 21 also shows existing nodes 123a and 123b, which are unchanged from FIG. 19. Other techniques of selecting a new node position, such as interpolating a position along a spline curve, are also possible.

To avoid generating an excessive number of links, adjacent links can be combined, provided that the node that connects said links does not also connect any other links that need to be retained. For example, if said links are in a sufficiently straight line and represent sufficiently similar travel speeds, then it may be desirable to combine them. To do so, the travel times of said links can be added to produce a travel time for a new replacement link. This is essentially the reverse of the process for splitting a link. For example, assume that in FIG. 20 the TravelTime for link 127a is 4 minutes and the

TravelTime link 127b is 6 minutes, then replace links 127a and 127b with link 124 (FIG. 19), assigning a TravelTime of 10 minutes (the sum of the TravelTimes of links 127a and 127b) to link 124.

From a sequence of RoadPositions, the Vehicle's "TravelPath" can be constructed, namely, a sequence of road links indicating the presumed movement of the Vehicle along the corresponding roads. This is illustrated in FIG. 22. FIG. 22 shows a directed graph of nodes 129a-h and links 130a-h. Nodes 129a, 129b, 129c and 129d represent a sequence of RoadPositions corresponding to a TrackingSequence. FIG. 22 shows one possible TravelPath as the sequence of links 130a, 130b and 130c. FIG. 23 again shows a directed graph of nodes 129a-h and links 130a-h. Nodes

129a, 129b, 129c and 129d again represent a sequence of RoadPositions corresponding to a TrackingSequence. However, FIG. 23 shows another possible TravelPath, comprising the sequence of links 130a, 130d, 130e, 130f, 130h and 130c.

A TravelPath can be selected from a sequence of RoadPositions by applying an algorithm to estimate the most likely route from each RoadPosition to the next. For example, the most likely route might be assumed to be the fastest or shortest known route. With the map database represented as a directed graph of links and nodes, the fastest or shortest route can be readily computed using any of several well-known shortest path algorithms. However, depending on the graph and the frequency of VehicleLocation data, there might be only one non-repetitive path from a given RoadPosition to the next. For example, in the directed graph of FIG. 23, there is only one path from node 129f to node 129h, and that is the path comprising links 130f and 130g.

In some cases, a Vehicle's RoadPosition (as indicated by a VehicleLocation) may be ambiguous: more than one road segment may apply to the same position. This can happen, for example, if one road on a bridge crosses above another road without connecting. However, this can also happen if different road segments are within the RadiusOf Accuracy or area that is reported for the Vehicle's position, as illustrated in FIG. 24. FIG. 24 shows two VehicleLocation positions 136a and 136b in sequence, each with a RadiusOfAccuracy 137a and 137b, and corresponding RoadPositions 138a and 138b (as determined later), respectively. Road links 140a-h connect nodes 139a-i. RoadPositions 138a and 138b are coincident with nodes 139h and 138i, respectively. In this case, the RoadPosition of VehicleLocation 136a is ambiguous because RadiusOfAccuracy 137a includes three road segments: road links 140a, 140d and 140e. Similarly, the RoadPosition of VehicleLocation position 136b is ambiguous because

RadiusOfAccuracy 137b includes five road segments: road links 140a, 140b, 140c, 140h and 140d.

(As an aside, although each node in a directed graph represents a single idealized position, more than one node can occupy the same position without being connected. This could occur, for example, if one node were representing a position on a road on a bridge, and another node were representing the same two-dimensional position on a road crossing under the bridge. There are also other circumstances in which this can occur.)

Ambiguous RoadPosition data could be ignored, or sometimes it can be disambiguated by other means, such as by examining one or more previous VehicleLocations in the TrackingSequence, as was illustrated in FIG. 24, to select the most likely RoadPosition from among more than one current candidate. This can be done by estimating the likelihood of the TravelPath implied by the sequence of RoadPositions or VehicleLocations through which the Vehicle has traveled.

As a Vehicle's TravelPath becomes known, this TravelPath information can be used to record traffic or travel time information for the road links indicated in the

TravelPath. For example, a count of the number of Vehicles observed traversing each link during some specified interval can be retained. This could be used, for example, to automatically collect tolls or measure traffic flow. It can also be used to decide whether a hypothesized new road segment is valid, as discussed later. Another use of a Vehicle's TravelPath is to store a history of the Vehicle's travel routes, for use later. This could include, for example, a profile of a user's usual routes to work and home. This could be done automatically by recording the TravelPath of the Vehicle, over a period of days for example, or it could be done at the user's request.

In short, the process of reconciling VehicleLocation data against an existing map database can allow this system to determine the TravelPath of a Vehicle along known road segments.

HI. Collecting Travel Time Information

One important use of a Vehicle's TravelPath is to record travel time information for specific road links. Travel time data for the road links in a Vehicle's TravelPath can be estimated by applying a prescribed algorithm or mathematical formula to prorate, among the road links, the travel times that are indicated by the associated TrackingSequence. The travel times between RoadPositions corresponding to VehicleLocations in a TrackingSequence need not correspond directly to consecutive nodes in the Vehicle's TravelPath, because, as previously noted, links along a path can be split or combined as needed.

For example, if two successive VehicleLocations in a TrackingSequence are far enough apart that they imply a TravelPath containing several road links, as illustrated in FIG. 25, and the travel time between said VehicleLocations was measured as t, then the travel time t can be divided among said road links. One way to do this is to use an expected travel time for each of the road links as a weight in dividing up travel time t, as illustrated in FIG. 25. The expected travel time for a road link may be computed using previously recorded travel times, an assumed speed limit for the road segment, or other means. Other algorithms or formulas could also be used to divide travel time t among said road -inks.

FIG. 25 shows road links 141a-e connecting nodes 142a-f. Each road link is labeled with its expected travel time, weight, and a prorated measured travel time, as set forth in Table 11.

On the other hand, if VehicleLocations in a TrackingSequence are close enough together that two successive VehicleLocations imply a path that is shorter than a single road link, then VehicleLocations in said TrackingSequence can be consolidated as necessary, as previously discussed. The following example illustrates this process, showing how closely-spaced VehicleLocation data can still be used to measure travel times for specific road segments. FIG. 26 shows three road links 132a-c connecting nodes 131a-d. Each link is further labeled with an expected link travel time.

FIG. 27 again shows road links 132a-c connecting nodes 131a-d, but also shows a sequence of RoadPositions 133a-d corresponding to VehicleLocations in a TrackingSequence. Each RoadPosition is further labeled with a TimeStamp so that the travel time between RoadPositions can be computed.

FIG. 28 again shows nodes 131a-d, but road links 132a-c of FIG. 27 have been split into road links 134a-g in FIG. 28, using additional nodes 135a-d corresponding to RoadPositions 133a-d of FIG. 39. In FIG. 28, road links 134a-g are further labeled with expected travel times derived from the original expected travel times of road links 132a-c of FIG. 27. In FIG. 28, road links 134b-f are also labeled with the prorated measured travel times computed by prorating the travel times between RoadPosition nodes 135a-d. (Since the measured travel time between RoadPosition nodes 135b and 135c did not need to be prorated, its "Prorated measured travel time", as indicated in FIG. 28, is actually its measured travel time.) FIG. 29 shows the result of recombining road links 134a-g of FIG. 28 back into original road links 132a-c. The prorated measured travel times of road links 134c-e of FIG. 28 have been combined to produce the resulting prorated measured travel time of road link 132b in FIG. 28. In FIG. 28, road links 132a-c connect nodes 131a-d, just as in FIG. 26, but we have now computed a measured travel time for road link 132b from a sequence of RoadPositions corresponding to VehicleLocation data in a TrackingSequence.

Having collected travel time information for specific road segments as just described, system 100 could output the resulting information or store such information in a database. In a preferred embodiment, such information would be stored in MapDatabase 102 of FIG. 6.

IV. Collecting Historic Travel Time Data to Model Travel Conditions

The preceding section has illustrated how VehicleLocation data from the Geolocator can be used to measure travel times for specific road segments. By accumulating travel time data for specific road segments, statistical means can be used to develop models of travel conditions, which can be used to predict current travel times in the absence of real-time data, or to predict future travel times — for example, by computing an average travel time over a given road link at different times throughout a typical weekday we can predict the travel time required to traverse said road -ink on a future weekday. Table 12 shows hypothetical average travel times for a specific road link during several different times of a typical weekday morning.

Historic data could be used to generate travel time models that reflect rush hours, weekend traffic changes, holiday travel conditions, good or bad weather traffic conditions, seasonal traffic differences, and other factors that have a statistically significant effect on travel times.

In general, we can use historic travel time data to develop a road link travel time prediction function, ExpectedLmkTravelTi-me(lirikID, timeAndDate), that computes the expected travel time required to traverse road link linklD at any particular time timeAndDate. (In this description, any mention of a particular time should be assumed to include or imply a date also, if necessary.)

This ExpectedLinkTravelTime function can be used by the ProcessingAlgorithm and updated dynamically as new data is received from the Geolocator or other sources. Furthermore, this function could also be programmed to make use of externally- supplied information on other scheduled or unscheduled events that may affect travel times, such as road construction, a big concert ending, or a road closure for a parade. For example, a road closure can be represented by a very high travel time, i.e. , a travel time that surpasses the expected road re-opening time.

One simple way to implement the ExpectedLinkTravelTime function would be to employ, for each road -ink, a base table of average weekday travel times, as previously illustrated in Table 12. Other tables could be used to apply adjustments for travel-time- affecting factors, such as bad weather or weekend travel. Table 13 illustrates a hypothetical table of rainy weather adjustments.

Of course, many other statistical techniques can be used to develop function ExpectedLinkTravelTime, and there are many other ways such a function could be implemented. The exact implementation of function ExpectedLinkTravelTime is not an essential aspect of this system.

Finally, the timeAndDate parameter of the ExpectedLinkTravelTime function might either represent the time when the Vehicle leaves the link's FromNode, or the time when the Vehicle arrives at the link's ToNode, or some average thereof. If the system that uses the resulting graph needs to estimate an arrival time at a destination, given a source location and departure time, then the timeAndDate parameter might represent the time when the Vehicle leaves the link's FromNode. However, if the resulting graph will be used to estimate a departure time from a source location, necessary to arrive at a destination at a particular time, then the timeAndDate parameter could instead represent the time when the Vehicle arrives at the link's FromNode, so that the graph search algorithm can work backwards from the destination to the source location to estimate the necessary departure time, as will be discussed later. If both tasks need to be performed, then two different versions of the ExpectedLinkTravelTime function could be used. However, depending on the link times involved, and the required precision of the result, it may be unnecessary to make this distinction, and a single ExpectedLinkTravelTime function may suffice.

V. Excluding Unwanted Travel Time Data

Another function of the ProcessingAlgorithm might be to exclude anomalous or inapplicable data. For example, the system could ignore travel times pertaining to Vehicles that have stopped for lunch.

This can be done by comparing the travel times associated with the TravelPaths of different Vehicles traversing the same road links during the same period, and excluding travel times that are unusually high. For example, the ProcessingAlgorithm could select the median travel time measured for each road link, for use as the most representative travel time pertaining to said link, thus excluding anomalous times. Or the ProcessingAlgorithm might discard the highest 10%, for example, of measured travel times. Or the ProcessingAlgorithm might discard any travel time that is more than 5 minutes greater than the median of the measured travel times, for example. Other thresholds could also be used, and many other data exclusion policies are possible also.

If the data exclusion policy excludes data from involuntary Vehicle stoppages, such as a Vehicle stopping at a traffic signal, then the resulting travel time data will be optimistically biased. To avoid such bias, it may be desirable to use data exclusion parameters that are liberal enough to cause such data to be retained, but restrictive enough to exclude most voluntary stoppages. This can be achieved by adjusting such parameters higher or lower until the desired data exclusion effect is attained.

VI. Determining the Name of a Road

It has been demonstrated how the ProcessingAlgorithm can reconcile VehicleLocation information against a map database to generate useful travel time information for specific road segments. Some additional uses for reconciling VehicleLocation data against a map database are now described.

One additional reason for reconciling VehicleLocation data against a map database is to determine the name of the road on which a Vehicle is traveling. If the existing map database contains road names associated with road links, a RoadPosition that is computed in the reconciliation process could also be used to determine the road name that should be associated with the Vehicle's position. This reconciliation may be particularly useful in generating a new map database, containing travel time information and road names, from an existing map database that contains road names but does not contain measured travel time information.

Vπ. Excluding Non- Vehicular or Off-Road Travel Data

Another reason for reconciling the new VehicleLocation data against an existing map database of known roads might be to exclude data corresponding to non-vehicular or off-road travel, such as by an airplane or train carrying a cellular phone. There are various ways this can be done. For example, if the distance from a VehicleLocation position to the nearest known road is larger than the VehicleLocation 's RadiusOfAccuracy or an assumed margin of error, then infer that the data does not indicate a Vehicle traveling on a known road, and therefore the data may indicate an airplane or train or a person walking with a cellular phone, for example. Another technique for identifying non- vehicular travel is to estimate the likelihood of possible routes, via known roads, that connect RoadPositions that correspond to VehicleLocation data in a TrackingSequence. This can be done, for example, by computing the minimum travel time, via known roads, between said RoadPositions, and comparing said minimum travel time against the observed travel time. If the observed travel time implies an excessive speed, then the data could be excluded as anomalous or due to airplane travel, as illustrated in FIG. 30. Statistical measures or other methods can also be used to exclude anomalous or irrelevant data. FIG. 30 shows a hypothetical TrackingSequence 143 following the path of an airplane 145 that flies across two roadways 144a and 144b. If system 100 is being used to generate a new map database without the aid of an existing map database, or if it is being used to update an existing map database to reflect new road segments, then a non- vehicular travel path could initially be confused with a new road, as illustrated in FIG. 31. FIG. 31 shows a hypothetical TrackingSequence 146 following the path of an off-road vehicle 148 that drives off of a roadway 147. This can be corrected using manual intervention. For example, each prospective new road segment could be automatically flagged, and manually confirmed or rejected later. Or the ProcessingAlgorithm could look for additional corroborating evidence before accepting the new path as a new road segment. For example, the ProcessingAlgorithm could look for other similar paths in the incoming VehicleLocation data. This can be done by initially assuming that each new path indicates a new road, and then counting how many other Vehicles appear to travel along this hypothesized new road. If enough other Vehicles appear to travel along this same hypothesized new road, then assume that this new road is valid. Vm. Using Geolocation Data to Adjust Node Positions

Another function the ProcessingAlgorithm can perform is to adjust node positions to better match observed geolocation data. This can be done by applying curve fitting algorithms to compute node positions that minimize the deviation of the observed geolocation data from the new node positions, for Vehicles that have traversed said nodes. For example, FIG. 32 shows road links 149a-c connecting nodes 150a-d, and a cluster of hypothetical TrackingSequences 151 representing observed travel that has traversed said road links.

FIG. 33 shows the result of adjusting the positions of nodes 150a-d of FIG. 32 to better match the average positions of the observed geolocation data for these road links. FIG. 33 shows road links 152a-c connecting nodes 153a-d. (Road link 152b is very short, connecting node 153b to node 153c.) Nodes 153a-d of FIG. 33 represent the result of adjusting the positions of nodes 150a-d, respectively, of FIG. 32 to more closely match the positions of TrackingSequences 151.

Even if a road is known to be in a certain physical location, it can be beneficial to determine a logical road location from geolocation data reported by the Geolocator. For example, in FIG. 34, the bold road links 154a-c may represent the road's idealized physical location (for one direction of travel), as determined from aerial photography, and the dashed links 156a-c may represent a logical road location as estimated from geolocation data reported by the Geolocator. This logical road location can be beneficial to use in a map database, because if the same Geolocator is used with the map database in providing services, then the logical road location will more closely match the geolocation data produced by the Geolocator. For example, if the Geolocator tracks a Vehicle to provide route guidance, the VehicleLocation data reported by the Geolocator during tracking will more closely match the logical road location in the map database. In other words, systematic errors in the geolocation data reported by the Geolocator will tend to be self-canceling when the map database is used in conjunction with the same Geolocator. This is a special benefit of using the same Geolocator for both generating the map database and for providing location-based services that use the map database. FIG. 34 shows solid road links 154a-c connecting solid nodes 155a-d, representing the physical location of road 158 (one direction). Dashed road links 156a-c connect hollow nodes 157a-d, representing a logical location of road 158 as determined from geolocation data.

IX. Geolocator Variations There are a number of ways the Geolocator can determine and indicate the location of a Vehicle. In one implementation of the Geolocator, a Vehicle's location might be determined using Time Difference Of Arrival (TDOA) or Angle Of Arrival (AOA) of the Vehicle's RF transmissions. In another embodiment, the approximate location of the Vehicle could be determined by identifying the cell site to which the Vehicle's cellular phone is currently assigned. This will often locate the Vehicle to within a few kilometers, but may not be accurate enough to determine the specific road on which the Vehicle is located. Many other embodiments of the Geolocator are possible also.

In general, the precision of the data that is produced by system 100 will depend on the precision and accuracy of the VehicleLocation data provided by the Geolocator. For greatest usefulness, the Geolocator should produce sufficiently accurate geolocation data to allow system 100 to determine the road on which a Vehicle is traveling. However, this system can still generate useful long-distance travel time information even if the Geolocator is not accurate enough to distinguish individual roads. If the Geolocator is not accurate enough to distinguish individual roads, then each road link in the directed graph may represent a corridor, or group of roads in proximity, and each node may represent an area. The resulting graph can be used to predict travel time from one area to another, for example.

For purposes of the above description, we have assumed for simplicity (but without loss of generality) that the Geolocator provides real-time VehicleLocation data. However, in another embodiment, the Geolocator could supply non-real-time

VehicleLocation data. For example, the Geolocator could store multiple VehicleLocation records in a buffer or database and supply them to the MapDatabase as required at a later time, either singly or in groups. Or, in another embodiment, the Geolocator could contain or access an externally-supplied database of stored VehicleLocations. If the Geolocator provides non-real-time VehicleLocation data, then the

VehicleLocation data must contain sufficient information to indicate the relative time orderings of a Vehicle's VehicleLocation records, so that the ProcessingAlgorithm can select TrackingSequences. This may be accomplished by including a TimeStamp with each VehicleLocation record, as illustrated in Table 3, but it could also be accomplished by indicating the sequence in which the VehicleLocation records for a Vehicle should be inteφreted, for example by indicating a record number for each VehicleLocation record, as also illustrated in Table 3. Other well-known techniques for indicating an ordering among the records are possible also.

Those skilled in the art will appreciate that the Geolocator is only assumed to be capable of providing sufficient VehicleLocation data that was obtained by passively geolocating a Vehicle's cellular phone or other RF transmitter. It is immaterial to this system whether the Geolocator generates said VehicleLocation data itself, receives the VehicleLocation from a geolocation device external to this system, provides the VehicleLocation data from a database that was created locally or remotely, or uses some other means to obtain the necessary data.

X. Other Ways to Represent a Vehicle Position

For purposes of the above discussions, we have assumed that a VehicleLocation position is represented either as a point or a point with a RadiusOfAccuracy. However, there are other ways a Vehicle's position can be represented. A position could also be represented in a form that merely implies a physical location, rather than indicating it directly. For example, a position could be represented by the name or ID of a node within a graph, as illustrated in FIG. 35. FIG. 35 shows several links 203a, 203b, 203c and others not labeled. Link 203a connects from node 204a to node 204b, link 203b connects from node 204c to node 204b, and link 203c connects from node 204d to node 204c. Or, a position could be represented as the ID number of a particular cellular phone cell in which the Vehicle is operating.

If the positions that are reported by the Geolocator do not correspond directly to locations that are represented in the MapDatabase, then it may be necessary to reconcile the VehicleLocation data against the MapDatabase' s location data, in order to determine a Vehicle's position relative to locations represented in the MapDatabase, as previously discussed. For example, if a VehicleLocation position is represented by arbitrary x,y coordinates, but the MapDatabase uses a graph of nodes and links to represent road locations, then the reconciliation process will determine a RoadPosition, within the graph, that corresponds to the reported VehicleLocation position. On the other hand, if the

Geolocator represents positions by node names within the MapDatabase 's graph, then the process of reconciliation is a no-op, because no reconciliation is required.

It should be understood to one skilled in the art that various representations for the Vehicle's position are possible, and the particular representation is not an essential aspect of this system. For puφoses of this discussion, and without loss of generality, assume that the Vehicle's position is represented as a point in an prescribed two-dimensional Cartesian coordinate system, unless otherwise indicated.

SECOND MAJOR EMBODIMENT:

DELIVERING CUSTOM TRAVEL-RELATED INFORMAΗON In another embodiment, illustrated in FIG. 36, a variation of system 100, designated system 1100, provides custom travel-related information to a Vehicle, based on the Vehicle's location. In this embodiment, system 1100 comprises: (a) source 1101 (the "Geolocator") for automatically geolocating a Vehicle; (b) a database 1102 (the "MapDatabase") of location-sensitive information; (c) interposed processor 1104 (the " SelectionAlgorithm") for selecting relevant travel-related information based on the reported location of the Vehicle; (d) and a guidance system 1105 (the "Guide") for delivering said travel information to the Vehicle.

In FIG. 36, Geolocator 1101 determines the location of Vehicle 162. The SelectionAlgorithm 1104 then uses this location data to select travel-related information from MapDatabase 1102 and pass the selected information to the Guide 1105, which sends the selected information to the Vehicle 162.

Geolocator 1101 is used to determine the approximate current location (the "VehicleLocation") of the Vehicle by passively geolocating the Vehicle's mobile transmitter.

MapDatabase 1102 provides location- sensitive information, i.e. , information that is relevant to specific geographic areas. (In a preferred embodiment, the MapDatabase contains such information in a database. However, in another embodiment the MapDatabase simply communicates with an external device or system that would supply such information, such as from a Traffic Control center database, rather than containing such a database itself.)

For example, in one embodiment the MapDatabase may contain information about travel times for specific road segments, or between specific locations. MapDatabase 1102 may also contain information about traffic incidents pertaining to specific geographic areas. The MapDatabase may also contain information about the locations and operating hours of various services, such as service stations, hotels, points of interest, businesses or residences. Or, MapDatabase 1102 may additionally contain information about the kinds of vehicles permitted on certain roads. Such information might be particularly valuable to truckers, for example. Thus, in various embodiments, MapDatabase 1102 is presumed to contain any kind of location-sensitive information, i.e. , information that is relevant to specific geographic areas.

In one embodiment, MapDatabase 1102 contains location-sensitive information pertaiiiing to areas that do not necessarily correspond to individual roads, such as areas corresponding to cell sites of a cellular phone system, or grid areas on a map. For example, MapDatabase 1102 simply maintains a table that associates current location- sensitive information with cell sites, as illustrated in Table 14.

To select travel-related information that is relevant to a Vehicle's current or anticipated location, the SelectionAlgorithm simply uses the cell site of the Vehicle's location to look up the associated location-sensitive information in the table. For example, if the Vehicle is located in CellSitelD #9002, then the associated location- sensitive information in Table 14 includes "Construction at Market St. and 46 St. " and "Mobil station at Market St. and 47th Street, open 6am- 10pm daily".

The SelectionAlgorithm selects travel-related information that is relevant to the Vehicle's current or anticipated location. The SelectionAlgorithm operates as shown in flow chart 3600 of FIG. 37. The SelectionAlgorithm begins at Start block 3601, receives a VehicleLocation from the Geolocator as invoked by processing block 3602, applies a prescribed algorithm via block 3603 to select relevant travel-related information ("Travellnfo") from the MapDatabase, based on the VehicleLocation, and uses the Guide to output the Travellnfo to the Vehicle, as depicted by processing block 3604. The processing flow terminates at Done block 3605.

At a minimum, the SelectionAlgorithm computes or selects Travellnfo that is deemed relevant to the Vehicle, given a VehicleLocation. Such Travellnfo may comprise a route plan to a predetermined destination, information about a change to a previously selected route plan, an estimated time of arrival at a predetermined destination, information about a change from a previously estimated time of arrival, guidance toward a destination, a reminder of an upcoming exit or road change, traffic conditions in the Vehicle's current or anticipated vicinity, the location of gas stations or other services, or any other travel-related information that is relevant to a particular geographic area. The SelectionAlgorithm output is used by the Guide to deliver the selected

Travellnfo to the Vehicle. This Travellnfo may be in any format that is convenient for both the SelectionAlgorithm and the Guide. In one embodiment, the Travellnfo may be represented as text, for example "30 MINUTE DELAYS AT WALT WHITMAN BRIDGE ON EASTBOUND 76". In another embodiment, the Travellnfo may represent audio data, for example, an audio recording of "30 minute delays at Walt Whitman Bridge on Eastbound 76".

The Guide converts the selected Travellnfo to a format that is acceptable to the Vehicle's mobile receiver, if necessary, and sends the result to the Vehicle. In one preferred embodiment, the Guide converts the Travellnfo from text to speech and delivers the result to the Vehicle via a cellular phone connection, as a synthesized voice. For example, the Guide tells the user of the Vehicle, via cellular phone, "30 minute delays at Walt Whitman Bridge on Eastbound 76", or "Go East on Chestnut Street for 1.6 miles", or "Travel 3 more blocks . . . 2 more blocks . . . one more block . . . Next right on Park Avenue. " In another embodiment the Travellnfo is sent as a text message to display on a pager carried by the Vehicle.

In one preferred embodiment, the Vehicle's mobile transmitter, by which the Vehicle is geolocated, and the Vehicle's receiver, by which the Vehicle receives selected Travellnfo, are embodied in a cellular phone, thus requiring no other special equipment in the Vehicle. In another embodiment, the Vehicle's receiver may be embodied in a pager. Many other embodiments are also possible.

The above description has shown how system 1100 can provide custom travel- related information to a Vehicle. For concreteness, and without loss of generality, system 1100 has been described as providing travel-related information to a single Vehicle. However, it should be obvious to one skilled in the art that in a preferred embodiment system 1100 is generally arranged to service multiple Vehicles or users by separately keeping track of the processing state pertaining to each Vehicle or user. Additional variations to system 1100 are now discussed.

I. Specifying User Options

Often it is desirable to allow a user to further customize the travel-related information that system 1100 selects and delivers, rather than just customizing the information based on Vehicle location.

To do so, system 1100 allows inputs, options or preferences to be specified, either by the user or by another device or person. For example, the user selects from a menu of various options using the touch tone cellular phone buttons, or the user specifies preferences orally, over the phone, to a speech recognition system or to an operator who inputs the information to system 1100. In another embodiment, the user's options are also stored as a profile of common preferences or defaults, for use on other occasions. One such input might be a desired destination or set of destinations. Another example might be a category of roads to use or avoid, such as super-highways or roads disallowing trucks. Another example might be to select a specific route from among various options. Yet another example might be a desired category of location-sensitive information, such as "Service Stations", "Hotels" or "Traffic Incidents". Such categories could be indicated in the MapDatabase 1102, as illustrated in Table 15, for example. Each row in Table 15 represents a record of location-sensitive information. The

"Category" column indicates what kind of information the record describes. The " CellS itelD" column indicates the area to which the information in this row pertains. The "Position" column indicates a more precise location of the incident or service. (Such Position information is used, for example, to guide a Vehicle to the location of a desired service, as discussed below.) Finally, the "Location-sensitive Information" column holds the body of the location- sensitive information. π. Providing Route Plan Information

One of the most preferred embodiments of system 1100 provides custom route plan information and other travel time related information to Vehicles. The following describes how such information can be provided.

In this embodiment, MapDatabase 1102 contains travel times and locations for specific road segments. MapDatabase 1102 contains static location- sensitive information, but in a preferred embodiment, it also includes dynamic location-sensitive information reflecting current travel conditions. Using MapDatabase 1102, SelectionAlgorithm 1104 applies a prescribed algorithm to select a route to one or more destinations. For example, if MapDatabase 1102 uses a directed graph to represent road segments, as previously discussed, then an algorithm could select the fastest route to the user's destination. Other criteria could also be used to select a preferred route. Using the same or other techniques, SelectionAlgorithm 1104 could also estimate the Vehicle's arrival time at the destination by summing the travel times incurred along the route to the destination. If each link also indicates the length of the road segment that it represents, then the travel distance to the destination can be computed by summing the lengths incurred along the route to the destination. (Of course, the length need not be explicitly represented on each link. The length could simply be implied by the end point locations of the road segment, or by any other suitable means.)

There are many algorithms, well known in the field, for finding the fastest route, in a graph, from a source location to a destination. One example is shown in Appendix A. This algorithm is based on Dijkstra's Algorithm, a well-known shortest path algorithm, and works forward through the graph, from source to destination. Given a source node, a destination node and a departure time from the source node, this algorithm finds the fastest route to the destination and computes the estimated arrival time at the destination.

Once SelectionAlgorithm 1104 has selected a route plan to the destination, Guide 1105 delivers this information, or a subset thereof, to Vehicle 162. This completes the description of how system 1100 provides custom route plan information to a Vehicle. Further additional variations of system 1100 are now described.

iπ. Estimating a Necessary Departure Time

A shortest-path algorithm to estimate the arrival time of a Vehicle at a destination, given the departure time at the source, was previously discussed. What if the Vehicle needs to arrive at the destination at a particular time, and wants to know when to depart from the source? It is easy to modify a typical shortest-path algorithm to compute the necessary departure time from a source location, given the desired arrival time at a destination. Basically, the algorithm just works in the opposite direction, working through the graph from the destination back to the source location. This is illustrated in the algorithm of Appendix B, which is a straightforward modification of the algorithm of Appendix A.

V. Updating the MapDatabase

In one preferred embodiment, SelectionAlgorithm 1104 automatically updates the data in MapDatabase 1102, as previously described for ProcessingAlgorithm 103 (shown in FIG. 6), using data from the Geolocator. MapDatabase 1102 may also be updated from other external sources also, either manually or automatically. For example,

ProcessingAlgorithm 103 is arranged to merge travel time or traffic data that is obtained from other sources.

V. Predicting a Vehicle Location

In another embodiment, SelectionAlgorithm 1104 uses the recent travel path of Vehicle 162 to more accurately estimate the current road position of Vehicle 162, as previously discussed, or to estimate the direction or anticipated future position of Vehicle 162, as illustrated in FIG. 38. FIG. 38 shows road links 164a-c connecting nodes 163a-d. A Vehicle's recent travel path 165 connects RoadPositions that are coincident with nodes 163a-c. The Vehicle was last geolocated at node 163c, but based on the recent travel path 165, the Vehicle's travel is anticipated to continue along travel path 166 and its next RoadPosition is anticipated to be at node 163d.

Or, SelectionAlgorithm 1104 uses a previously stored route in order to anticipate the future position of Vehicle 162. For example, such a stored route might have been previously selected by a guidance application. Or, such a stored route might be one of several commonly used routes, known in the geographic area. Or, system 1100 stores a profile history of the Vehicle's usual route to work or home, as discussed previously. This is illustrated in FIG. 39.

FIG. 39 shows road links 167a-c connecting nodes 168a-d. A Vehicle was most recently geolocated at node 168c. Based on stored route 169, the Vehicle's next RoadPosition is anticipated to be at node 168d.

VI. Real-time Route Guidance

In another preferred embodiment, system 1100 provides real-time travel-related information, such as route guidance, to the user of a Vehicle, as the Vehicle travels. For example, in a guidance application, system 1100 tracks the Vehicle's movement and notifies the Vehicle of the next action to take at each approaching intersection, exit or other decision point. Or, system 1100 performs route selection repeatedly as the Vehicle travels, and notifies the user of any recommended changes to a previously selected route, based on the Vehicle's current position. If system 1100 makes use of dynamic location- sensitive information, then the Vehicle's recommended route can then be automatically changed in response to changes in travel conditions. System 1100 also notifies the Vehicle if the Vehicle appears to be going the wrong direction. This can be done by tracking the Vehicle's progress to see if it deviates from the selected route. One practical way to do this is have the SelectionAlgorithm watch for an increase, beyond a prescribed threshold, in the estimated travel distance from the specified destination.

VQ. Dispatching Vehicles

In another embodiment, system 1100 assists in dispatching any of several Vehicles to a specific location, in response to a request. This is used, for example, in taxi dispatching, to select the taxi that can arrive at the customer's location the soonest. For example, a customer might use a cellular or conventional phone to call an automatic taxi dispatcher. The location of each available taxi could be tracked by geolocating each taxi's cellular phone, or by other means. The customer's location might also be determined by geolocating the customer's cellular phone, or, in the case of a conventional telephone, by looking up the location in a database, such as is done currently for emergency "911" calls. System 1100 estimates the travel time required for each available taxi to reach the customer's location, and dispatches the taxi with the earliest estimated arrival time. System 1100 also automatically patches the customer through to the taxi driver, establishing a voice connection from the customer to the driver, by telephone or radio, so that the customer and driver could discuss any necessary details of the pickup.

Alternatively, such a dispatching system automatically records special instructions from the customer, such as "I have four large suitcases" or "I am at the back of the building at 1500 Locust Street", and sends them to the taxi driver, via radio or cellular phone.

In another embodiment, such a dispatching system is also arranged to estimate the next available taxi even among occupied taxis, by estimating the time when each occupied taxi will become available, and then proceeding as previously described. This can be done by estimating the arrival time of each occupied taxi at its destination, and adding an estimated passenger unloading time. Of course, these techniques can be applied to many other dispatching applications as well. In another embodiment, system 1100 is further arranged to assist in dispatching emergency vehicles, either automatically or semi-automatically. By tracking the locations of available emergency vehicles, and by manually or automatically determining the location of the emergency, such a system automatically estimates the potential arrival time of each available emergency vehicle, and selects or recommends the one that could arrive at the scene the soonest. Furthermore, such a system automatically guides the emergency Vehicle to the scene, as previously described.

Vm. Route Selection for Emergency and Other Special Vehicles

In another embodiment, system 1100 is arranged to use a different route selection method or maintain different travel time data for use by emergency vehicles, such as for police, fire or emergency medical services, because those vehicles may have different travel time characteristics from other vehicles. For example, emergency vehicles may travel faster and go through stop lights and stop signs significantly faster than other cars. A similar approach could be taken for trucks or other major vehicle categories.

To automatically determine the kind of travel time data applicable to a specific kind of Vehicle, a database is maintained which associates each cellular phone number (or other identifying code) and a Vehicle type ("VehicleType"), as illustrated in Table 16, thus allowing the VehicleType to be determined automatically when this system is used to provide a service. Or such a database might associate each cellular phone number (or other identifying code) with a TravelTime multiplier ("TravelTimeMultiplier") that indicates how long this Vehicle normally takes to travel, relative to a nominal Vehicle TravelTime, as illustrated in Table 17. A link travel time can be multiplied by the TravelTimeMultiplier for the Vehicle to estimate the link traversal time for the Vehicle.

IX. Vehicle Notification Another function that system 1100 performs is the notification to Vehicles of relevant information, such as a traffic incident. Or system 1100 notifies a Vehicle before the Vehicle passes an important decision point, such as an exit.

In one preferred embodiment, system 1100 monitors a Vehicle's location, and automatically notifies the Vehicle of Travellnfo deemed relevant to the Vehicle, either at the Vehicle user's implicit or explicit behest, or entirely initiated by system 1100. For example, system 1100 may provide the user with exit reminders, so as to notify the user when the next exit that the user should take, along a previously selected route, is approaching. Or system 1100 may notify the Vehicle of upcoming traffic incidents, or changes to a selected route plan. Such notification is accomplished by calling the Vehicle's cellular phone, transmitting an audible tone or message on a previously established cellular phone call, or by sending a message to the Vehicle's pager, for example.

In another embodiment, the SelectionAlgorithm is arranged to predict the Vehicle's likely route, in the absence of an explicitly specified destination, and to notify the Vehicle of unusual travel conditions relative to the Vehicle's predicted route. For example, the SelectionAlgorithm estimates the Vehicle's direction of travel, using the TravelPath computed from the Vehicle's TrackingSequence, and, as one simple heuristic, assumes that the Vehicle will continue in the same direction along the same road. For example, system 1100 could inform a Vehicle traveling North on route 295 approaching exit 36: "Accident on 295 Northbound at exit 40. Please detour at exit 36." Other more sophisticated techniques of predicting the Vehicle's likely route are also possible. For example, the SelectionAlgorithm uses a previously stored user profile of common routes, such as the user's usual route to work or home, to predict the Vehicle's likely route without requiring explicit destination information. In another embodiment, system 1100 notifies the Vehicle of the existence of a potentially relevant traffic message, and solicits the Vehicle user's agreement to pay a fee in exchange for receiving the traffic message. For example, by cellular phone, system 1100 notifies a Vehicle traveling North on route 295 approaching exit 36: "For $2.99 you can receive this traffic notification message. Press ' 1 ' now if you wish to receive this traffic notification message" . If the user indicates acceptance by pressing " 1 " on his/her cellular phone, then system 1100 sends the message "Accident on 295 Northbound at exit 40. Please detour at exit 36". In another embodiment, system 1100 also solicits or guesses the Vehicle's destination, and re-computes a new route to avoid the obstruction.

THIRD MAJOR EMBODIMENT: THIRD PARTY TRAVEL-RELATED INFORMATION

The preceding two major sections have presented how location-sensitive information can be generated, and how custom selected travel-related information can be delivered to a Vehicle. This section describes how a third party user can obtain travel- related information from such systems as system 100 or system 1100. Such a user might be a dispatcher selecting a route for delivery vehicles, a user at home checking on travel conditions to work, a pedestrian needing a taxi, or a person in distress needing emergency assistance, for example. An embodiment of this variation, designated system 2100, is now described. System 2100 is illustrated in FIG. 40.

System 2100 allows a third party user at a remote location to obtain travel-related information. With reference to FIG. 40, this embodiment comprises: (a) a means 2102 (the "MapDatabase") for accessing location-sensitive information, wherein said information is associated with one or more specific geographic areas, and furthermore said information includes data that was derived from passively geolocating and tracking one or more mobile transmitters; (b) a selection processor 2104 (the " SelectionAlgorithm") for selecting travel-related information, based on one or more locations of interest; and (c) guide system 2105 (the "Guide") for sending selected travel- related information to remote user 2106.

MapDatabase 2102 stores and provides location- sensitive information. In a preferred embodiment, such location- sensitive information is updated dynamically. In particular, in one preferred embodiment, such location-sensitive information is updated, in part, using geolocation data obtained by passively geolocating mobile transmitters, as previously discussed.

SelectionAlgorithm 2104 selects travel-related information relevant to one or more locations and uses Guide 2105 to deliver the selected information to remote user 2106. Guide 2105 may use the cellular phone system, the conventional phone system, pager communication, radio communication, electronic mail, the Internet, or any other means for delivering the selected travel-related information to remote user 2106, who may or may not be carried in a vehicle. In one embodiment, system 2100 allows remote user 2106 to specify inputs, options or preferences, as previously discussed. For example, the user might specify a location of interest. Or, the user might specify a source location and a destination, and system 2100 selects a route from the source location to the destination and sends the information about the selected route, such as directions and travel time, for the fastest route from the source location to the destination location, to the user. System 2100 is also used in dispatching delivery vehicles, for example. Many other kinds of travel- related information could be supplied also, as previously discussed.

In another embodiment, system 2100 estimates the departure time, from a source location, necessary to arrive at a destination at a particular time, and notifies remote user 2106. For example, system 2100 initiates a "wake up" phone call when it is nearing time to leave. Or system 2100 sends an electronic mail message, or a pager message. Or system 2100 notifies user 2106 only if the estimated departure time differs sufficiently from a previously assumed or usual departure time. Or system 2100 notifies user 2106 if the newly selected route differs from a previously selected route, such as the user's usual route to work. Or system 2100 notifies user 2106 of any traffic incidents on the user's usual route to work, for example.

Although various embodiments which incoφorate the teachings of the present invention have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incoφorate these teachings.

Table 9: Nodes of a graph corresponding to VehicleLocation records of Table 8

Table 10: Links of a graph corresponding to

Table 12: Hypothetical average travel times for a specific road link during different times of a typical weekda

Table 13: Hypothetical rainy weather travel time adjustments for a specific road link

Table 14: Table of cell sites and information

Tab le 15: Table of cell sites and information, with categories and positions

Category Cell SitelD Position Location-sensitive Information services 9001 38.362,349.033 Sunoco station at Hartford Rd and US 38, open 24hrs daily delays 9002 38.369,348.967 Construction at Market St and 46 St. services 9002 38.378,348.925 Mobil station at Market St and 47th Street, open 6am- 10pm daily delays 9003 38.385,348.902 30 minute delays on Eastbound 76 at Walt Whitman Bridge delays 9004 38.392,348.870 Accident on 295 Southbound at exit 36

SUBSTn rESHEET(RULE26) APPENDIX A: Fastest Path Algorithm

This algorithm finds the fastest path, in a directed graph, from a source node to a destination node. It is a version of Dijkstra's algorithm. The directed graph is assumed to consist of a set of nodes and a set of directed links, in which each link represents a road segment, and each node represents a physical location.

Each link is assumed to have the following attributes:

FromNode The node from which this link connects.

ToNode The node to which this link connects. The algorithm may also give each node the following attributes: arrivalLink The link, along the currently-fastest path, by which this node was reached. arrivalTime The arrival time at this node, traversing along the currently- fastest path. Each node may also be labeled as "Reached" or "Unreached", at various points as the algorithm progresses.

This algorithm also assumes that there is a function,

ExpectedLinkTravelTime(l,t) that yields the expected incremental travel time required to traverse link 1 starting at time t. If the travel time for link 1 is constant for all times, then this function simply represents an association between a link and a travel time. This function is intended to account for different travel times, for the same road segment, at different times of the day or different days.

This algorithm has the following inputs: sourceNode The source node from which the fastest path to the destination node is desired. destinationNode The destination node. departureTime The anticipated departure time from sourceNode.

This algorithm produces the following outputs: pathToDestination A sequence of links representing the fastest path from the sourceNode to the destinationNode. arrivalTime of destinationNode The estimated time of arrival at the destinationNode.

This algorithm uses the following variables: Variable Explanation

sourceNode The starting node. destinationNode The ending node. departureTime The departure time from the starting node. frontierNodes A set of nodes representing the frontier of our breadth-first search of the graph. These are nodes that have yet to be "expanded". nodeToExpand The next node to be expanded, i.e., we will next search from this node. candidateLink The next link to be traversed in our search, eltt Expected link travel time for candidateLink. cat Candidate arrival time, i.e., arrival time at the ToNode of candidateLink. pathToDestination The list of links comprising the fastest path leading from the sourceNode to the destinationNode. currentNode Current node in constructing the path from thesourceNode to the destinationNode.

The algorithm has the following steps.

1. Get input:

Input sourceNode. Input destinationNode. Input departureTime.

2. Initialize for fastest path search:

Mark all nodes "Unreached" .

SET arrivalTime of sourceNode : = departureTime.

SET frontierNodes : = { sourceNode }. 3. SEARCH LOOP:

Check for an unreachable destination: IF frontierNodes is empty THEN BEGIN

Output "Destination is unreachable from source" . STOP

END

4. Select a node nodeToExpand from frontierNodes such that nodeToExpand has the minimum arrivalTime of all nodes in frontierNodes.

5. Delete nodeToExpand from frontierNodes. 6. See if we have reached the destination:

IF nodeToExpand = = destinationNode

THEN GOTO REACHED_DESΗNAΗON (step 9).

7. (Comment: This step is known as "expanding" node nodeToExpand.) For each link candidateLink whose FromNode is nodeToExpand, do the following: BEGIN

COMMENT: eltt means "expected link travel time".

SET eltt : = ExpectedLinkTravelTime(candidateLink, arrivalTime of nodeToExpand). COMMENT: cat means "candidate arrival time". SET cat : = eltt + arrivalTime of nodeToExpand. IF ToNode of candidateLink is "Unreached" OR cat < arrivalTime of ToNode of candidateLink

THEN BEGIN

SET arrivalTime of ToNode of candidateLink: = cat. SET arrivalLink of ToNode of candidateLink : = candidateLink. IF ToNode of candidateLink is "Unreached"

THEN BEGIN

Mark ToNode of candidateLink as "Reached" . Add ToNode of candidateLink to frontierNodes. END END

END

8. GOTO SEARCH LOOP (step 3).

9. REACHED_DESΗNAΗON:

Initialize for constructing the path from sourceNode to destinationNode: SET pathToDestination : = {}.

SET currentNode : = destinationNode.

10. Construct the path from sourceNode to destinationNode:

WHILE (currentNode ! = sourceNode) BEGIN Insert arrivalLink of currentNode as the first link in pathToDestination.

SET currentNode : = FromNode of arrivalLink of currentNode. END 11. Output the results:

Output pathToDestination.

Output arrivalTime of destinationNode.

12. STOP APPENDIX B: Fastest Path Algorithm (Backwards Version)

This is a modified version of the previous Fastest Path Algorithm. This algorithm also finds the fastest path, in a directed graph, from a source node to a destination node. However, given a destination and a desired arrival time at the destination, this algorithm will also compute the latest possible departure time, from the source, that is required to the destination at the desired arrival time. To do so, this algorithm works backwards through the graph, from destination to source.

The directed graph is assumed to consist of a set of nodes and a set of directed links, in which each link represents a road segment, and each node represents a physical location. Each link is assumed to have the following attributes:

FromNode The node from which this link connects.

ToNode The node to which this link connects.

The algorithm may also give each node the following attributes: departureLink The link, along the currently-fastest path, by which this node was reached. departureTime The departure time at this node, traversing along the currently-fastest path.

Each node may also be labeled as "Reached" or "Unreached", at various points as the algorithm progresses. This algorithm also assumes that there is a function,

ExpectedLinkTravelTime(l,t) that yields the expected incremental travel time required to traverse link 1 ending at time t. If the travel time for link 1 is constant for all times, then this function simply represents an association between a link and a travel time. This function is intended to account for different travel times, for the same road segment, at different times of the day or different days.

This algorithm has the following inputs: sourceNode The source node from which the fastest path to the destination node is desired. destinationNode The destination node. arrivalTime The desired arrival time at destinationNode.

This algorithm produces the following outputs: pathToDestination A sequence of links representing the fastest path from the sourceNode to the destinationNode. departureTime of sourceNode The time required to depart from sourceNode in order to arrive at destinationNode at arrivalTime.

This algorithm uses the following variables: Variable Explanation

sourceNode The starting node. destinationNode The ending node. arrivalTime The desired arrival time at destinationNode. frontierNodes A set of nodes representing the frontier of our breadth-first search of the graph. These are nodes that have yet to be "expanded". nodeToExpand The next node to be expanded, i.e. , we will next search from this node. candidateLink The next link to be traversed in our search. eltt Expected link travel time for candidateLink. cdt Candidate departure time, i.e., the departure time from the

FromNode of candidateLink. pathToDestination The list of links comprising the fastest path leading from the sourceNode to the destinationNode. currentNode The current node in constructing the path from the sourceNode to the destinationNode.

The algorithm has the following steps. 1. Get input:

Input sourceNode. Input destinationNode. Input arrivalTime.

2. Initialize for fastest path search: Mark all nodes "Unreached".

SET departureTime of destinationNode : = arrivalTime. SET frontierNodes : = { destinationNode }.

3. SEARCH LOOP:

Check for an unreachable source: IF frontierNodes is empty

THEN BEGIN

Output "Source is unreachable from destination".

STOP

END 4. Select a node nodeToExpand from frontierNodes such that nodeToExpand has the maximum departureTime of all nodes in frontierNodes.

5. Delete nodeToExpand from frontierNodes.

6. See if we have reached the source:

IF nodeToExpand = = sourceNode THEN GOTO REACHED SOURCE (step 9) .

7. (Comment: This step is known as "expanding" node nodeToExpand.)

For each link candidateLink whose ToNode is nodeToExpand, do the following: BEGIN

COMMENT: eltt means "expected link travel time". SET eltt : = ExpectedLinkTravelTime(candidateLink, departureTime of nodeToExpand). COMMENT: cdt means "candidate departure time".

SET cdt : = departureTime of nodeToExpand - eltt. IF FromNode of candidateLink is "Unreached" OR cdt > departureTime of FromNode of candidateLink THEN BEGIN SET departureTime of FromNode of candidateLink : = cdt.

SET departureLink of FromNode of candidateLink : = candidateLink.

IF FromNode of candidateLink is "Unreached" THEN BEGIN Mark FromNode of candidateLink as "Reached" .

Add FromNode of candidateLink to frontierNodes. END END END 8. GOTO SEARCH_LOOP (step 3).

9. REACHED SOURCE:

Initialize for constructing the path from sourceNode to destinationNode: SET pathToDestination : = {}. SET currentNode : = sourceNode. 10. Construct the path from sourceNode to destinationNode:

WHILE (currentNode ! = destinationNode)

BEGIN

Append departureLink of currentNode as the last link in pathToDestination.

SET currentNode : = ToNode of departureLink of currentNode. END

11. Output the results:

Output pathToDestination.

Output departureTime of sourceNode.

12. STOP

Claims

What is claimed: 1. A system for generating map database information, the system comprising (a) a source of vehicle geolocation data, said vehicle geolocation data being obtained by passively geolocating at least one vehicle carrying a mobile transmitter, (b) a road location data storage, said road location data being composed of road segments, and (c) means for processing said vehicle geolocation data by applying a prescribed algorithm to select, from said vehicle geolocation data, a tracking sequence comprising at least two reported positions for a tracked vehicle, said means for processing including means for reconciling said tracking sequence against the road location data storage to estimate a travel path of the tracked vehicle along one or more road segments corresponding to said tracking sequence.

2. The system of claim 1 wherein said means for processing includes means for estimating the location of at least one road segment from said vehicle geolocation data.

3. The system of claim 1 wherein said vehicle geolocation data includes time stamps, and said means for processing includes means for computing an estimated vehicle travel time for at least one road segment along said travel path with reference to said time stamps.

4. The system of claim 3 further comprising a travel time database for storing travel time data for specific road segments.

5. The system of claim 4 wherein said travel time database is also used as said road location data storage.

6. A system for providing custom travel-related information to a vehicle, the vehicle carrying a mobile transmitter and a mobile receiver, said system comprising a geolocator for passively geolocating the mobile transmitter, means for accessing location-sensitive data, selection means for selecting from said location-sensitive data travel-related information for the vehicle based on a location of the vehicle as reported by said geolocator, and means for delivering selected travel-related information to the vehicle for receipt by the mobile receiver.

7. The system of claim 6 wherein said mobile transmitter and said mobile receiver are embodied in a cellular phone.

8. The system of claim 6 wherein said mobile receiver is embodied in a pager.

9. The system of claim 6 wherein said location-sensitive data includes travel time data for specific road segments.

10. The system of claim 9 further including means for dynamically updating said location-sensitive data based on observed travel conditions.

11. The system of claim 10 wherein said means for dynamically updating includes means for updating said location-sensitive data using geolocation data from said geolocator.

12. The system of claim 6 wherein said selection means selects a preferred route to a specified destination.

13. The system of claim 12 wherein said selection means selects an estimated fastest route to said destination.

14. The system of claim 6 wherein said selection means selects route guidance information.

15. The system of claim 6 wherein said means for delivering includes means for notifying a user of the vehicle, on the basis of an estimated location of the vehicle relative to an anticipated route, before the vehicle passes a decision point at which the user must choose between two or more routes.

16. A system for providing travel-related information to a user at a remote location, the system comprising means for accessing location-sensitive data, said location-sensitive data including data obtained from passively geolocating and tracking one or more mobile transmitters, selection means for selecting travel-related information from said location- sensitive data based on one or more specified locations, and means for delivering selected travel-related information to the user.

17. The system of claim 16 wherein said location-sensitive data includes travel time data.

18. The system of claim 16 further including means for dynamically updating said location-sensitive data based on observed travel conditions.

19. The system of claim 18 wherein said means for dynamically updating includes means for updating said location-sensitive data using geolocation data obtained by passively geolocating mobile transmitters.

20. The system of claim 16 wherein said selection means selects route guidance information.

21. The system of claim 16 wherein said selection means selects a preferred route from a specified source to a specified destination.

22. The system of claim 21 wherein said selection means selects an estimated fastest route from said source to said destination.

23. The system of claim 21 wherein said location- sensitive data is updated dynamically based on observed travel conditions, and said system further comprises: means for storing a user profile, for a user, indicating a previously selected route from a source location to a destination location, and means for notifying the user if a newly selected route, from said source location to said destination location, differs from said previously selected route.

24. The system of claim 21 further comprising means for computing an estimated arrival time of a vehicle at said destination.

25. The system of claim 24 wherein said location-sensitive data is updated dynamically based on observed travel conditions, and said system further comprises means for notifying a user at a remote location if said estimated arrival time differs from a previously estimated arrival time.

26. The system of claim 17 further comprising means for computing an estimated departure time, from a specified source location, required to arrive at a specified destination location at a specified future time.

27. The system of claim 26 further comprising means for notifying a user, at a remote location, when said departure time approaches.

28. The system of claim 26 wherein said location-sensitive data is updated dynamically based on observed travel conditions, and said system further comprises means for notifying a user at a remote location if said estimated departure time differs from a previously estimated departure time.

29. A method for generating map database information comprising the steps of accessing vehicle geolocation data obtained by passively geolocating at least one vehicle carrying a mobile transmitter, and processing said geolocation data by applying a prescribed algorithm: to select a tracking sequence representative of at least two reported positions of said vehicle; and to use said tracking sequence to estimate the location of at least one road segment to thereby generate the map database information.

30. A method for generating map database information, comprising the steps of accessing vehicle geolocation data obtained by passively geolocating at least one vehicle carrying a mobile transmitter, and processing said geolocation data by applying a prescribed algorithm: to select a tracking sequence representative of at least two reported positions of a tracked vehicle; and to reconcile said tracking sequence against stored road location data in order to estimate a travel path of the tracked vehicle, along one or more road segments, corresponding to said tracking sequence, thereby generating the map database information.

31. The method of claim 30 wherein said vehicle geolocation data includes time stamps, and further comprising the step of computing an estimated vehicle travel time for at least one road segment along said travel path.

32. The method of claim 31 further comprising the step of storing travel time data, for specific road segments, in a travel time database.

33. A method for providing custom travel-related information to a vehicle carrying a mobile transmitter and a mobile receiver, the method comprising the steps of passively geolocating the mobile transmitter, accessing a database of location-sensitive data, selecting travel-related information from the database by applying a prescribed selection algorithm to produce the custom travel-related information based on at least one reported location of the vehicle, and delivering the custom travel-information to the mobile receiver.

34. The method of claim 33 wherein said mobile transmitter and said mobile receiver are embodied in a cellular phone.

35. The method of claim 33 wherein said mobile receiver is embodied in a pager.

36. The method of claim 33 wherein said database of location- sensitive data includes travel time data for specific road segments.

37. The method of claim 36 further including the step of dynamically updating said database of location- sensitive data based on observed travel conditions.

38. The method of claim 37 wherein said step of dynamically updating includes the step of updating the location-sensitive data using geolocation data from said geolocator.

39- The method of claim 33 wherein said selection algorithm selects a preferred route to a specified destination.

40. The method of claim 39 wherein said selection algorithm selects an estimated fastest route to said destination.

41. The method of claim 33 wherein said selection algorithm selects route guidance information.

42. The method of claim 33 further comprising the step of notifying the user of the vehicle, on the basis of an estimated location of the vehicle relative to an anticipated route, before the vehicle passes a decision point at which the user must choose between two or more routes.

43. A method for providing travel-related information to a user at a remote location, comprising the steps of accessing a database of location- sensitive data, wherein said location- sensitive data includes data obtained from passively geolocating and tracking one or more mobile transmitters, selecting custom travel-related information from said database by applying a prescribed selection algorithm to produce the custom travel-related information based on at least one specified location, and delivering the selected travel-related information to the user.

44. The method of claim 43 wherein said location-sensitive data includes travel time data.

45. The method of claim 43 further including the step of dynamically updating said database of location-sensitive data based on observed travel conditions.

46. The method of claim 45 wherein said step of dynamically updating includes the step of updating said location-sensitive data using geolocation data obtained by passively geolocating mobile transmitters.

47. The method of claim 43 wherein said selection algorithm selects a preferred route from a specified source to a specified destination.

48. The method of claim 47 wherein said selection algorithm selects an estimated fastest route from said source to said destination.

49. The method of claim 43 wherein said selection algorithm selects route guidance information.

50. The method of claim 47 wherein said location-sensitive data is updated dynamically based on observed travel conditions, and said method further comprises the steps of storing a user profile, for the user, indicating a previously selected route from a source location to a destination location, and notifying the user if a newly selected route, from said source location to said destination location, differs from said previously selected route.

51. The method of claim 47 wherein said selection algorithm computes an estimated arrival time of a vehicle at said destination.

52. The method of claim 51 including the step of dynamically updating said location- sensitive data based on observed travel conditions, and further including the step of notifying the user if said estimated arrival time differs from a previously estimated arrival time.

53. The method of claim 44 wherein said selection algorithm selects an estimated departure time, from a specified source location, required to arrive at a specified destination location at a specified future time.

54. The method of claim 53 further comprising the step of notifying the user, at the remote location, when said departure time approaches.

55. The method of claim 53 further including the step of dynamically updating said location- sensitive data based on observed travel conditions, and further including the step of notifying the user at the remote location if said estimated departure time differs from a previously estimated departure time.