TRAVEL-TRACKING AND REAL-TIME ROUTING INFORMATION SYSTEM
TECHNICAL FIELD This invention relates to a system and method for responding to inquiries from a traveler using a mobile communicator, suggesting itineraries for the traveler, and providing directions to the traveler.
BACKGROUND ART
Working out public transportation connections going from place to place, and changing the route when delayed in transit is a continuing problem for travelers. The problem can be dealt with manually by making many phone calls to change travel plans.
As mobile communication devices such as mobile telephones are capable of obtaining location information (e.g., GPS) and on-line Internet access, it is becoming possible to utilize those capabilities in a travel planning context. Some routing systems for cars display the route and turns on a map for travel to a location, but those routing systems do not cover differing modes of transportation and locations of a user, as well as handle delays. Previous routing systems do not have the ability to handle advance reservations, or calculate the least expensive or most scenic route.
Allowing notification of delays before it is too late to change an itinerary, and allowing reservations and cancellations based on in-transit information, in real-time and while in transit, would prevent problems and alleviate stress for the modern-day traveler.
DISCLOSURE OF THE INVENTION According to an exemplary embodiment of the invention, a user retrieves an itinerary using a mobile communicator. The user enters a description of travel that includes a start location, a destination, and an attribute into the mobile communicator. The mobile communicator transmits the information to a travel-tracking and real-time-routing information system. The routing system receives the information. In response to receiving
the user's current location, the destination, and the attribute, the system looks up routes in its internal transit database of routes to find those that are available and fit the description. The system checks with external databases to verify timetables and prices. The system sends a suggested itinerary to the user which conforms to the description of travel. The user receives the suggested itinerary on the mobile communicator. The user decides whether to accept the itinerary or request another itinerary, and sends a message to the system using the mobile communicator. If the user accepts the itinerary, the system marks the travel as "active."
According to another exemplary embodiment of the invention, a travel-tracking and real-time routing information system provides travel directions to a user's mobile communicator in the course of active travel. The system divides the active travel itinerary into one or more legs. The system sends a first leg of the travel route to the mobile communicator to be displayed for the user. In the first leg of travel, the system tells the user where to go first, and indicates a mode of travel, departing at a first departing time and arriving at a second arrival time. When the user has accomplished performing the first leg of travel, the user then selects "complete" using the mobile communicator, which then transmits the "complete" signal to the system. The system receives the "complete" signal indicating that the first leg of travel has been completed by the user, and sends to the mobile communicator a second leg of the itinerary in the course of the user=s travel. The system can send a correction or modification to a leg of travel if circumstances warrant a change in time, means, place, or mode of travel, etc. The system can replace an entire leg based on circumstances (e.g., if an airport is closed due to weather, or an airline flight is canceled.)
According to another exemplary embodiment of the invention, a travel-tracking and real-time routing system provides an itinerary to a user in response to a request for an itinerary, and provides travel directions to a user in the course of active travel in response to acceptance of the itinerary by the user. The system includes a transit database, a common interface, mobile communicators, and a processor which are communicatively interconnected. External databases supplement the capabilities of the transit database.
The processor is operative to calculate itineraries using the transit database, interface with mobile communication equipment, gather information from external databases, track a
user=s location, determine delays, perform on-line reservations and cancel them, and monitor transportation (and vehicle) delays from external databases to notify users and update itineraries as necessary.
The mobile communicator is operative to display messages for a user, process data entered by the user, connect to the transit database using the common interface, and send and receive updates to and from the transit database during the course of active travel.
The common interface standardizes the way various types of mobile communication equipment transmit and retrieve itineraries. The common interface includes a location information interface that uses either GPS location (or other location methods) or a number of predefined fields (e.g., address, state, zip, country, free text, etc.) to uniquely define the destination. The common interface includes an itinerary interface. The itinerary interface supports sending the itinerary in a predefined unique format (e.g., unique user itinerary number, arrival/departure, method of transportation, reservation number, free text, GPS location, address, etc.).
Other aspects and advantages of the invention will become apparent from the following detailed description and accompanying drawings, illustrating by way of example the features of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a schematic view of a routing information system in accordance with the principles of the invention;
FIG. 2 is a process flow diagram of retrieving an itinerary in accordance with the principles of the invention;
FIG. 3 is a process flow diagram of providing directions in accordance with the principles of the invention; and
FIG. 4 illustrates an example computer system for implementing the invention.
BEST MODE FOR CARRYING OUT THE INVENTION According to the principles of the invention, when a user of a mobile communicator
wants to travel from point A to point B, a travel-tracking and real-time routing information system calculates the route (which can include public transportation) for the user. If the user is delayed (which can be calculated by the GPS in the mobile communicator, such as a mobile telephone), the mobile communicator can obtain an alternative route. For instance, the system can send a message to the user of the mobile communicator to take one bus instead of another bus. If a train is delayed, the system can attempt to find a faster route. If a bus is canceled, the system can make alternate reservations. When reservations are needed, the system will make them on-line. If the user has set a safety-level, the system can route him around areas that are dangerous (areas with high crime-rates for instance). If the user wants the cheapest route, the system can calculate that, or if the user wants the most scenic route, the system can do that.
The ability to recalculate when unexpected things occur is an advantage of the invention. If a bus is running late, the system can detect the location of the mobile communicator, and based on estimates determine whether the user is running late (i.e., not even near the train station where the connecting train is). The system can then calculate when the next train leaves, or perhaps suggest an alternate bus to take.
The mobile communicator interfaces with a transit database in order to create the travel itineraries. The transit database is preferably standardized to allow a common interface. The database can be connected to any number of external databases such as busses, trains, planes, etc. A processor can connect the transit database to each of these other databases to make reservations, obtain information about delays and time schedules, and obtain the locations of train stations and bus stops as available. The functionality, level of detail, and services provided by the transit database vary based on the level of availability from each of the external databases. As more of the external databases are updated with relevant and useful information, more of the transit database capabilities can be utilized. For example, if a train database knows about delays and informs the transit database, these data can be utilized.
The common interface to the transit database allows mobile communicators, mobile telephones, and other equipment to use the features of the transit database.
The mobile communicator, such as a mobile telephone, is able to communicate with the transit database via the common interface. To determine delays of a user in real time, the mobile communicator is able to locate itself (e.g., using GPS). Alternately, the system can be used without this knowledge. The system also uses information about way points such as bus stops and train stations in order to detect user delays.
An example travel-tracking and real-time routing information system is illustrated schematically in FIG. 1. The routing information system illustrated in FIG. 1 includes a processor 100, a transit database 102, a first mobile communicator 104 communicatively coupled to the transit database 102 by way of a common interface 108, and a second mobile communicator 106 communicatively coupled to the transit database 102 by way of the common interface 108. The transit database 102 is communicatively coupled to a first external database 110 and a second external database 112. The routing information system shown in FIG. 1 provides an itinerary to a user of a mobile communicator in response to a request for an itinerary, and provides travel directions to the user in the course of active travel in response to acceptance of the itinerary by the user. With reference to FIG. 1, the processor 100, the transit database 102, the common interface 108, and the mobile communicators 104, 106 are communicatively interconnected.
The processor 100 is operative to calculate itineraries using the transit database 102, cause the transit database 102 to interface with equipment through the common interface 108, gather information from external databases 110, 112, monitor transportation delays with external databases 110, 112 to notify users and update itineraries, track the user=s location and determine delays, and perform on-line reservations and cancel them.
Each mobile communicator 104, 106 is operative to connect to the transit database 102 using the common interface 108, and send and receive updates to and from the transit database 102 during the course of active travel.
The common interface 108 standardizes the way various types of mobile communication equipment transmit and retrieve itineraries from the transit database 102. The common interface 108 includes a location information interface that uses either GPS location or a number of predefined fields (e.g., address, state, zip, country, free text, etc.) to uniquely
define the destination. The common interface 108 also includes an itinerary interface. The itinerary interface supports sending the itinerary in a predefined unique format (e.g., unique user itinerary number, arrival/departure, method of transportation, reservation number, free text, GPS location, address, etc.).
The routing information system illustrated in FIG. 1 allows a user of a mobile communicator to request an itinerary using the transit database based on a description of travel. For example, when a user wants to travel from point A to point B, the user turns on the mobile communicator, e.g., mobile communicator 104 (FIG. 1), and prepares a request for an itinerary that includes a description of the travel. With reference to FIG. 2, the user enters point A as his start location (e.g., detected by GPS), and then point B as his desired destination. The user opts to travel from point A to point B the least expensive way possible, but to arrive no later than 9:00 PM. Such description of travel that includes a start location, a destination, and those attributes of the travel (i.e., the least expensive way while arriving no later than 9:00 PM) is sent to the routing information system through common interface 108 (FIG. 1) in step 200, which looks up in the transit database 102 (FIG. 1) of routes to find available routes that fit the description in step 202. The system then checks with one or more external databases 110, 112 (FIG. 1) to verify timetables and prices in step 204, and sends a suggested itinerary to the user, which will inexpensively put the user at point B before 9:00 PM in step 206.
The user receives this itinerary on his mobile communicator 104 (FIG. 1), and can accept it, or look over other possibilities (which can be retrieved from the routing information system). In step 208, the user decides whether to accept the itinerary or reject it. If the user accepts the itinerary by entering an Aaccept@ into the mobile communicator 104 (FIG. 1), the mobile communicator 104 transmits the Aaccept@ signal back to the system in step 210.
Optionally, the system may provide a list of itineraries in step 212. The list of itineraries can include, for example, a first itinerary, a second itinerary, and a third itinerary. For example, the list of itineraries can be shown on the display of a mobile communicator (e.g., first mobile communicator 104 in FIG. 1). An example list can state: Altinerary 1 : Arrive 7:46 PM, Price $40. Itinerary 2: Arrive 8:58 PM, Price $45. Itinerary 3: Arrive 9:06
PM, Price $20. To select an itinerary, depress its associated key on the keypad or depress A7@ to reject the itineraries in the list.@ Using this optional feature, the user is able to receive a quick overview of the various itinerary options, and even though one of them would make the user arrive a little late (e.g., 9:06 PM), it would save money. After reviewing the list of itineraries, the user can reject or accept one of the list of itineraries in step 214.
In response to receiving the accept signal from the mobile communicator, the system marks the sent itinerary as Aactive@ in step 216.
The routing information system provides directions to the user of a mobile communicator in response to receiving an acceptance of an itinerary. With reference to FIG. 3, each leg of the travel plan is sent from the routing information system to the user. For instance, in step 300, a mobile communicator, such as mobile communicator 104, receives a first leg of the itinerary that indicates to the user to go to the bus stop at the comer of Madison and Pope, and take bus number fifty-six going downtown, and arriving at 6:34 PM. When boarding the bus, the user can select this leg as Acomplete@ and enter Acomplete@ into the mobile communicator 104 in step 302. The mobile communicator transmits the Acomplete@ signal to the routing information system in step 304. In response to receiving the Acomplete@ signal, the routing information system sends to the mobile communicator 104 of the user a second leg of the itinerary in step 306, which could, for example, display for the user the statement, AGet on the bus at San Diego Train Station arriving at 6:57 PM@. After the user completes the second leg of the itinerary, the user enters Acomplete@ into the mobile communicator in step 308. The mobile communicator sends a Acomplete@ signal through the common interface to the transit database of the routing information system in step 310. hi response to receiving the Acomplete@ signal, the system formulates a third leg of the itinerary and sends the third leg of the itinerary to the mobile communicator of the user in step 312. For example, the third leg could be displayed on the mobile communicator of the user as ATake train to L.A. leaving from platform number three, at 7:09 PM@.
The routing information system described herein is able to react supportively in case of a delay or interruption in travel. For example, if the bus were delayed, the routing information system can detect the location of the mobile communicator, and correct the
arrival time by way of a Acorrection@ signal sent to the mobile communicator. If the bus were delayed so the user could not catch the train, information in the next leg to be sent to the mobile communicator can be changed to reflect the bus delay. The next leg displayed on the mobile communicator for the user could state, AChanged: Take train to L.A. leaving from platform number five, at 7:25 PM@.
In that scenario, if the system knows that the later train requires reservations, the system can send a message to the mobile communicator of the user asking the user to acknowledge making reservations. If the user is delayed again, the system can cancel the reservations. Such transmission and reception between the mobile communicator of the user and the routing information system continues interactively until the user reaches his destination, point B.
If the user decides to terminate the travel, he can enter a Aterminate@ into the mobile communicator, whereupon the mobile communicator sends a Aterminate@ signal to the routing system. In response to receiving the Aterminate@ signal from the mobile communicator, the system removes the Aactive@ mark, and stops monitoring progress of the user.
The routing information system of the present invention may be implemented using hardware, software or a combination thereof and may be implemented in a computer system or other processing system. In an illustrative embodiment, the invention is directed toward one or more computer systems capable of carrying out the functionality described herein. An example computer system 400 is shown in FIG. 4. The computer system 400 includes one or more processors, such as processor 404. The processor 404 is connected to a communication bus 406. Various software embodiments are described in terms of this example computer system. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the invention using other computer systems and/or computer architectures.
Computer system 400 also includes a main memory 408, preferably random access memory (RAM), and can also include a secondary memory 410. The secondary memory 410 can include, for example, a hard disk drive 412 and/or a removable storage drive 414,
representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 414 reads from and/or writes to a removable storage unit 418 in a well-known manner. Removable storage unit 418 represents a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 414. As will be appreciated, the removable storage unit 418 includes a computer usable storage medium having stored therein computer software and/or data.
In alternative embodiments, secondary memory 410 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 400. Such means can include, for example, a removable storage unit 422 and an interface 420. Examples of such include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units and interfaces which allow software and data to be transferred from the removable storage units to computer system 400.
Computer system 400 can also include a communications interface 424. Communications interface 424 allows software and data to be transferred between computer system 400 and external devices. Examples of communications interface 424 can include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, etc. Software and data transferred via communications interface 424 are in the form of signals which can be electronic, electromagnetic, optical or other signals capable of being received by communications interface 424. These signals are provided to communications interface 424 via a communications path 426. This communications path 426 carries signals and can be implemented using wire or cable, fiber optics, a telephone line, a cellular phone link, an RF link and other communications channels.
In this document, the terms "computer program medium" and "computer usable medium" are used to generally refer to media such as removable storage device 418, a hard disk installed in hard disk drive 412, and communications path 426. These computer program products are means for providing software to computer system 400.
Computer programs (also called computer control logic) are stored in main memory 408 and/or secondary memory 410. Computer programs can also be received via
communications interface 424. Such computer programs, when executed, enable the computer system 400 to perform the features of the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 404 to perform the features of the present invention. Accordingly, such computer programs represent controllers of the computer system 400.
In an embodiment where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system 400 using removable storage drive 414, hard drive 412 or communications interface 424. The control logic (software), when executed by the processor 404, causes the processor 404 to perform the functions of the invention as described herein.
In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s). In yet another embodiment, the invention is implemented using a combination of both hardware and software.
While several particular forms of the invention have been illustrated and described, it will also be apparent that various modifications can be made without departing from the spirit and scope of the invention.