Data processing: vehicles – navigation – and relative location – Navigation – Determination of travel data based on the start point and...
Reexamination Certificate
1999-12-06
2001-06-26
Cuchlinski, Jr., William A. (Department: 3661)
Data processing: vehicles, navigation, and relative location
Navigation
Determination of travel data based on the start point and...
C701S204000, C701S117000, C701S118000, C340S905000, C340S990000, C340S995190
Reexamination Certificate
active
06253146
ABSTRACT:
BACKGROUND OF THE INVENTION
Traffic congestion continues to increase in metropolitan areas. If a driver could be notified when his intended route has unusual congestion then he might be able to find an alternate route that would get him to his destination faster and with less aggravation. Currently, drivers have access to traffic reports periodically provided on broadcast radio stations. These reports contain traffic information for a wide geographic area, requiring the driver to listen carefully for information pertinent to his trip. It is often difficult to assess the information and find a better alternate route while driving. Further, the reports may not be available when needed because of their periodic nature. Some localities have Highway Advisory Radio which continually broadcasts current traffic conditions and others have variable signs on the highways which provide notification of unusual conditions. While these services provide information more frequently, it is still not in a form that can easily be used to determine alternate routes.
SUMMARY OF THE INVENTION
A server platform in the PSTN performs the service of calling the subscriber if the subscriber's customary commuting route is congested. The service makes an initial call when the fastest commute route is congested. It also makes additional calls each time it finds a better alternate route or if the alternate route becomes congested.
The server has a first database of subscriber records organized by the subscriber's customary start time of each commute. The server can accommodate any subscriber commuting pattern. For example, a particular subscriber can have a morning time for a commute to work, an “evening rush-hour” time for a commute from work to night school, and a “night time” commute from night school to home. Each record in the database includes the sequence of street names and the geographic coordinates of each entry and exit point of the segments of each street of the subscriber's customary commuting routes. Each record will also have the subscriber's home telephone number, work telephone number, and vehicle cellular phone number. In addition, a subscriber record can include commuting routes that are taken on specified days of the week, e.g., a Monday route that may be different from a Tuesday route.
The server has a second database of highway records organized by street name. Each record will include the geographic coordinates of segments of the highway and a corresponding field for storing a congestion metric for that respective segment. If a street on the subscriber's customary route is found to be congested, then the server sequentially tests additional streets having geographic coordinates nearby, dynamically searching for an alternate route that has an acceptable level of congestion. In an alternate embodiment, each street segment in the record can also have a corresponding “trial alternate route” field. The trial alternate route is the first alternate route to be tested for congestion by the server when a street that is part of the subscriber's customary commuting route is found to be congested. If the trial alternate route is also found to be congested, then the server sequentially tests additional streets having geographic coordinates nearby, dynamically searching for an alternate route that has an acceptable level of congestion.
The server has a third database of digital voice records for a voice response unit (VRU) in the platform, that have pre-recorded street names, standard descriptions of congestion conditions, and stock phrases needed to announce to the subscriber that the subscriber's customary commuting route is congested. Following an initial call to the subscriber, the server continues to search for better alternate routes having the least congestion and it calls the subscriber again if it finds a better alternate route. Alternately, the server can use text-to-speech (TTS) to avoid pre-recording a prohibitive number of street names.
The server includes a data processor programmed to perform the following sub-functions:
[a] Run a traffic watching daemon that collects congestion measurements for respective segments of highways in the region and stores in each highway record of the second database, a congestion metric for the geographic coordinates of each segment of the respective highway.
[b] Run a clock watching daemon that searches all subscriber records for matches of the time-of-day with the scheduled commuting times in the respective record, and selects those subscriber records having a current match.
[c] Run a call-decision process that analyzes each selected subscriber record identified by the clock watching daemon. Each street name in the subscriber record for the scheduled commute, is used as a search term for the second database of highway records. The geographic coordinates of each entry and exit point of each segment of each street of the subscriber's customary route are used as a search term to access the congestion metric for that respective segment. Each congestion metric value is compared to a threshold value. If any street segment congestion metric exceeds the threshold value, then the server sequentially tests additional streets having geographic coordinates nearby, dynamically searching for an alternate route that has an acceptable level of congestion. The threshold may be user definable, since some subscribers may be willing to tolerate higher levels of congestion than others. For example, different levels of thresholds can be selected from severe, to moderate, to light.
[d] Run a subscriber calling process that responds to a detected traffic congestion condition by accessing the first database of subscriber records to obtain the subscriber's telephone number. The process outputs the telephone number to the VRU. The process forms query terms to apply to the third, VRU database. Recorded phrases are concatenated by the VRU to announce to the subscriber the street segment having the congestion. Also, the VRU announces the alternate route which has been found for the congested street segment. Following an initial call to the subscriber, the server continues to search for better alternate routes having the least congestion and it calls the subscriber again if it finds a better alternate route.
The subscriber calling process accurately describes to the driver why it is suggesting a new route.
An algorithm is used to advise the subscriber of routes that avoid or minimize tolls according to the subscriber's preference. The server has stored the subscriber's specification of the way the subscriber usually chooses his routes to avoid or accept tolls. The algorithm simulates the subscriber's choices of routes according to this specification. The algorithm equates the number of minutes required to detour a toll route, with the value in dollars of that lost time to the subscriber.
The subscriber has the option to specify what it means to be a better alternate route. For example, in addition to toll avoidance, the subscriber can specify a preference for highway driving or local roads, for the most scenic routes, for the fastest routes, for the shortest distance routes, or for routes that goes by certain features, such as a grocery store, and the like.
REFERENCES:
patent: 5438687 (1995-08-01), Suchowerskyj et al.
patent: 5523950 (1996-06-01), Peterson
patent: 5610821 (1997-03-01), Gazis et al.
patent: 5648769 (1997-07-01), Sato et al.
patent: 5745865 (1998-04-01), Rostoker et al.
patent: 5818356 (1998-10-01), Schuessler
patent: 5831552 (1998-11-01), Sogawa et al.
patent: 5862244 (1999-01-01), Kleiner et al.
Hanson Karrie Jo
Katseff Howard Paul
Markowitz Robert Edward
Robinson Bethany Scott
AT&T Corp.
Beaulieu Yonel
Cuchlinski Jr. William A.
LandOfFree
Network-based traffic congestion notification service does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Network-based traffic congestion notification service, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Network-based traffic congestion notification service will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2528785