Patent Application
20060061486
1. Field of Invention
This invention relates generally to traffic alert systems and more specifically to improved usability of such systems.
2. Discussion of Related Art
Information is available in many forms to aid motorists planning trips. MICROSOFT® Streets & Trips™ is an example of a mapping program that provides driving directions as well as estimated driving costs and time. The Streets & Trips program also contains an option of downloading current road construction information to allow the program to suggest routes that avoid roads under construction.
Motorists can also obtain information through on-line mapping services. Such services allow a user to specify an origin and a destination of a trip. The mapping service computes a route for the trip, indicating which roads the user should take. The route might be presented to the user as a map or as a list of roads. The MICROSOFT® MAPPOINT® mapping service is an example of an on-line mapping service.
The MAPPOINT® mapping service may be accessed through a control, which is a programming construct that provides an interface to one or more functions, such as those provided by the MAPPOINT® mapping service. The control can be integrated with other software so that the functions accessed through the control are accessed from that software. In this way, the features of the MAPPOINT® mapping service may be incorporated into other web sites without detailed knowledge of its operation.
For example, a web site designer for a retail store can incorporate a control for the MAPPOINT® mapping service in a website for the store to allow customers using the store website to access the mapping service. When a customer accesses the website through a web browser on a client computer, the mapping service control can be downloaded to the client computer. In operation, the control can be configured to create an output display in a field in the web browser window displaying the store website. The customer can interact with the mapping service through the control, such as to get customized driving directions.
Motorists can also receive information from traffic alert systems that proactively send new information when it is available. Traffic alert systems send information to motorists about traffic problems, such as accidents or breakdowns, as the problems occur. An example of a traffic alert system is the MSN® Autos™ traffic alert system.
In one aspect, the invention relates to a traffic alert system that receives a user alert profile that identifies a route of interest to the user. That information is used to create a filter for that user. The system filters information about traffic conditions and communicates appropriate traffic alerts to the user.
In another aspect, the invention is described as a method of operating a traffic alert computer system that includes providing a user interface that enables a user to specify a route to be used to create a filter.
In one aspect, the invention relates to a traffic alert system that includes a computer system adapted to exchange information with at least one user and to receive traffic information from a source of information about traffic conditions. The system includes at least one storage medium. Computer executable instructions in the system can cause the computer system to receive from the at least one user an alert profile comprising at least one route; store filter information in the storage medium based on the alert profile; compare traffic information obtained from the source of information about traffic conditions to the filter information; and communicate a traffic alert to the at least one user when the traffic information indicates a traffic problem matching the filter information based on the alert profile received from the at least one user.
In another aspect, the invention relates to a method of operating a traffic alert computer system, including providing on a user interface at least one filter interface in which a user may specify filter information for traffic alerts. The filter information includes at least one route.
In another aspect, the invention relates to a method of operating a traffic alert system, that includes receiving from a user route information identifying at least one route; comparing the route information to traffic information of traffic problems to filter the traffic information to identify user relevant traffic problems correlated with at least one road in the route; and communicating to a client device an electronic message alerting the user to the user relevant traffic problem.
In another aspect, the invention relates to a method of receiving customized traffic alerts that involves providing a traffic alert system with filter information that specifies at least one criteria defining traffic alerts relevant to a user. This filter information specifies at least one route. Traffic alerts regarding traffic problems correlated to at least one road in the at least one route are then received.
Other aspects of the invention, as well as specific embodiments, are described below.
The accompanying drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every drawing. In the drawings:
Applicants have appreciated that with existing traffic alert systems some users may receive too much information or information of low relevance to the user, which is undesirable.
In accordance with one embodiment of the invention, the usability of a traffic alert system is greatly increased by reducing the total number of alerts that are likely to be sent to each user, but retaining the alerts that are of interest to the user. The user interface of the system allows the user to specify one or more routes and to only receive alerts about traffic problems impacting those routes. In this way, the number of alerts is decreased and the overall quality of the alerts sent to the user is increased.
In one embodiment described below, the aspects of the present invention are implemented on a traffic alert system having an architecture illustrated in
One embodiment is created by modifying an existing traffic alert system. The user interface is modified to allow a user to specify a particular route and the system is modified to filter traffic alerts and to provide to the client only those alerts that indicate a problem impacting the specified route.
Benefits of such features are illustrated by
Output screen includes a map 310. Map 310 is generated in this example by a MICROSOFT® MAPPOINT® mapping service control. Superimposed on the map are incident indicators such as 312, 314 and 316. Output screen 300 shows multiple traffic problems existing in a particular metro area. These traffic problems exist on different roads. For example, the traffic problem represented by incident indicator 312 is on road 320, while the traffic problem represented by incident indicator 314 in on road 322. Some motorists may not be interested in information about both roads 320 and 322. Nonetheless, if both of those roads fall within metro regions a user has specified when establishing an alert profile, a prior art system would send the user alerts concerning both incidents.
As another example, incident indicators 314 and 316 correspond to traffic problems on road 322. However, the locations of the traffic problems corresponding to incident indicators 314 and 316 are far enough apart that many motorists driving on road 322 will not drive on both sections where those traffic problems exist. Thus, some motorists will not benefit from receiving information about both of the traffic problems represented by incident indicators 314 and 316.
This example illustrates that even when a user specifies a region within a metro area, the specified region will include more roads than a user is likely to drive on in any given day. Further, a user might drive through multiple metro regions on a trip. Therefore, to receive all of the traffic alerts which are of interest using a prior art traffic alert system, the user might have to specify multiple metro regions. Thus, even though prior systems included the ability to limit traffic alerts by metro region, Applicants have recognized that users of such systems are receiving a large number of alerts, some of which are not necessary.
Applicants have further appreciated that alerts sent to a mobile device can be particularly disruptive for the user, as each alert has the potential to interrupt the user from performing important tasks. Applicants have further appreciated that receiving a large number of traffic alerts which are not meaningful to the user can condition the user to ignore all alerts from the system. Thus, even when important information is sent in an alert, because of conditioning, the user may ignore the alert.
Applicants have further appreciated that users might incur a charge for each alert, either imposed by the service providing the traffic alert system or for receiving each alert on a mobile phone.
It would be desirable to provide an improved traffic alert system that is more targeted and convenient for users. Such an improved system is described below.
Server 104 is connected over a network 103 to client 101. Network 103 may be the Internet and client 101 may be a standard web browser installed on a stationary computer system, such as a desktop computer.
Server 104 is also connected to a mobile client 111. The connection to mobile client 111 is made over network 103 through a gateway 102. Gateway 102 can be, for example, a gateway to a mobile public switched telephone system. Mobile client 111 might be text messaging software on a cellular telephone.
In a typical application, a user provides information to server 104 through client 101. Such information includes an identification of a region for which the user would like to receive alerts and an electronic address to which alerts should be sent. Based on this information, server 104 generates and sends alerts.
Server 104 is connected to one more or databases. In the illustrated embodiment, a user database 107 and a problem database 108 are shown. User database 107 stores information about users of the traffic alert system that is used to generate alerts. User database 107 might also store billing information about the client to allow charges to be assessed as alerts are provided to the user. Problem database 108 represents a source of information about traffic problems. Problem database 108 could reside on physical storage associated with server 104. Alternatively, the problem data might be provided as a data stream from a third party data provider. In the latter case, database 108 is a logical representation of a source of data rather than physical hardware connected to server 104.
A backend interface 106 on the server interacts with databases 107 and 108 to retrieve and store data. Backend 106 may be a commercially available database program.
Business logic 105 interfaces with client 101 and/or client 111 and backend 106. Business logic 105 receives input from a user through client 101. Business logic 105 processes this information and then, through backend 106, stores the processed information in user database 107.
Multiple users can access the system through the client interfaces. Business logic 105 interfaces to all the clients, but only one such client 101 is shown for simplicity. User database 107 stores information about all the users in a way to create a correspondence between a specific user and the information provided by that user.
Business logic 105 periodically compares information about users stored in user database 107 to information about traffic problems from problem database 108. When business logic 105 identifies a traffic problem that requires an alert to be sent to a particular user, business logic 105 sends a message or traffic alert to that user.
Multiple methods are available for communicating a traffic alert to a user. The alert might be communicated by e-mail sent through network 103 to the client 101. Alternatively, business logic 105 might communicate over network 103 to a gateway 102 that can transmit a text message to a mobile client 111 over the mobile public switched telephone network.
Traffic alert system 100 is constructed as a traditional client-sever based web application. Controls such as drop down list boxes and check boxes are well known. These controls can display information for a user or receive information from the user accessing these controls through the client. Accessing these controls can cause information based on user input to be communicated to the server. In this specific example, the information communicated to the server is an alert profile specifying the situations in which a specific user should receive a traffic alert. The server generates traffic alerts for specific users based on the alert profiles corresponding to those users.
To provide information to business logic 105 through interface 200, a user first selects a metro area using field 201. Field 201 is a drop down list box providing a list of metro areas for which traffic information is available. A user may select a metro area by selecting an entry from the list. The client communicates the selection to server 104.
When the user selects a metro area, business logic 105 populates field 202 with regions within that metro area for which traffic information is available. The user can then specify a metro region from the list of regions in field 202. Window 205 displays metro regions selected by the user.
User interface 200 also provides the user an opportunity to specify a severity filter and a time filter. Section 203 of user interface 200 allows the user to specify the severity of alerts the user wishes to receive. Section 203 includes check boxes 210A, 210B, 210C. Check box 210A corresponds to high severity incident. Check box 210B corresponds to medium severity incident, and check box 210C corresponds to a low severity incident. In the example of
Section 204 of user interface 200 provides the user with an opportunity to specify a time filter. Section 204 includes check boxes 212A and 212B that allows the user to indicate whether the user wishes to receive traffic alerts in the morning and in the afternoon, respectively. When check box 212A is selected, the user may use fields 214A and 214B to specify a starting and ending time, respectively, for receiving traffic alerts in the morning. Fields 214A and 214B are implemented as drop down list boxes. In a similar fashion, check box 212B allows the user to specify a starting and ending time for receiving traffic alerts in the afternoon. When check box 212B is checked, the user may use fields 216A and 216B to specify a starting and ending time, respectively, in the afternoon.
Section 204 further includes check boxes (of which only 218A and 218B are numbered for simplicity) that allow the user to specify days of the week on which the user wishes to receive traffic alerts.
The user interface of
User interface 400 includes a mapping control 402, which may be a control to an existing mapping service, such as the MAPPOINT® mapping service. By accessing control 402, a user may specify an origin and a destination, and control 402 communicates that information to the mapping service. The mapping service then computes a route and provides as an output the roads within the route. This information may be passed through the interface provided by control 402 to client 101. In the interface of
While a mapping service is used to provide information to the user regarding a desired note, it should be appreciated that the invention is not limited in this respect, as the desired rate may be specified in any suitable way (e.g., manually by the user).
Interface 400 has further controls that allow the user to select the displayed route as a route for which the user wishes to receive traffic alerts. Any convenient control can be used to allow the user to select the route. In the illustrated embodiment, interface 400 includes an “Add” control 410. When selected, Add control 410 brings up a dialog box that allows the user to give a name to the designated route. The designated route is then sent by client 101 to server 104 where business logic 105 stores the route information in user database 107 in a record associated with the specific user.
Business logic 105 populates field 405 with names of routes specified by the user. In the example illustrated in
In one embodiment, user interface 400 also can include controls that allow a user to specify other parameters of an alert profile, such as those found in prior art traffic alert systems. Section 403 contains controls that allow the user to specify the severity of the traffic problem in the same way that this information was specified through section 203 of the interface of the prior art system of
Interface 400 also provides a section 404 through which a user may specify an alert schedule. As with section 204 in a prior art interface of
Further, user interface 400 may include a drop down menu box 401. The user, via a client such as 101 or 111, has the option of selecting a metro area from a drop down menu box. Selecting a metro area, although not necessary, eases the process of specifying the addresses for route generation. Any street address indicating the origin or destination of a route will be interpreted by mapping control 402 as being within the specified metro area.
User interface 400 may also include a metro region section, such as section 202 in the prior art. The user's specified route may go through several metro regions. A user may only be interested in receiving alerts from a subset of those metro regions. Therefore choosing a metro region in connection with a route will further filter unnecessary data.
Business logic 105 may be implemented using web based application operating in the client-server configuration shown, and using any suitable file format and programming language (e.g., OPAS or SQL).
At act 502, business logic creates a filter based on the alert profile specified by the user. The filter is stored in user database 107 (
At act 503, business logic 105 obtains traffic problem data. Traffic problem data can be obtained from a traffic problem database 108, or any other source. Traffic problem database may be a physical storage location associated with server 104, or may be a source of data obtained from a third party data provider.
Regardless of the specific source of the traffic problem data, the traffic problem data is repetitively compared to user filters to determine which users should receive alerts. Various methods can be used to schedule these comparisons and the sending of alerts, as the invention is not limited in this respect. Process 500 illustrates a simple scheduling algorithm employing a loop that can be coded into business logic 105, but any convenient scheduling algorithm can be employed.
At act 504, a loop 510 is established over all the users that have alert profiles stored in user database 107. At act 505, the identified traffic problems are compared to the user filters stored for each user at act 502.
At act 506, a determination is made as to whether traffic problem information matches the criteria stored as a filter for a particular user. If the traffic problem matches the filter stored for a particular user, the process proceeds to act 507. In the example illustrated in
At act 507, a traffic alert is sent to the appropriate user. The traffic alert is sent to the user at the electronic address specified for the user when the user profile was created. The electronic address may, for example, be an e-mail address, identify a mobile telephone or other handheld electronic device, or be any other suitable information.
Conversely, if the traffic problem information does not meet the filter criteria for the user, no alert is sent. The process proceeds with loop 510 returning to act 504 where the next user is selected. Loop 510 repeats for that user, and an alert is sent to the user if the traffic problem information matches the traffic alert profile specified by the user.
The process repeats for other users in the same fashion. When loop 510 is completed, the process returns to act 503 where current traffic problem data is obtained. Preferably, traffic problem data is kept current in some fashion such that new traffic problem reports are be continuously or regularly available.
Advantageously, a traffic alert is sent only to a user when the traffic problem data indicates a problem impacting a road in which the user has specified as being of interest. The total number of alerts sent to a user can therefore be significantly decreased. Particularly in the case where alerts are being transmitted to a mobile client 111, reducing the total amount of information transmitted to the client can be a significant benefit.
In addition, the quality of the information is greatly increased. Only reports of problems that are of interest to the particular user are transmitted to that user, thereby increasing the usability of the system.
Having thus described several aspects of at least one embodiment of this invention, it is to be appreciated various alterations, modifications, and improvements will readily occur to those skilled in the art.
As one example, user log-on, account management functions and other interactions traditionally found in applications provided through the Internet are not expressly shown. However, such functions might be readily included.
Also, the system may include some process for keeping traffic reports current. If traffic problem data is stored in a database, preferably entries in the database are removed once they are “stale.” For example, traffic problem data received at server 104 might indicate, in addition to reports of new problems, that previously reported problems have been resolved. Alternatively, a time stamp may be appended to each traffic problem report as it is stored in the database and reports in a database older than some predetermined time may be deleted. A suitable process for processing only current traffic information can be included in the system described above.
Furthermore, user database 107 can be readily modified to store information about alerts sent to users. The information may be used as part of a billing system, if users are charged for each alert they receive. Such information might also be used as a further filter criteria. Business logic 105 may be programmed not to send alerts of traffic problems that have previously been reported to a user or where a user has been previously informed of multiple traffic problems affecting a road. Such filtering might be adaptive based on the severity of the reports. For example, the system may send a report if a higher severity traffic problem that was reported affecting the same road is indicated, but not send a report of a lower severity report when a higher severity report was previously sent.
Also, it was described above that a user may enter a traffic alert profile through a stationary PC. However, any computing device with a connection to server 104, such a as a web enabled mobile phone or a PDA, can be used to enter information. Further, a system can be constructed with an alternative user interface that allows routes to be specified directly from a mobile client device.
As another example, scheduling algorithms other than the one shown in
Further, in the embodiment above, traffic problems were described as impacting a route only when the problem occurred on a road along that route. In an alternate embodiment, the system may be programmed to recognize roads with correlated traffic patterns. For example, roads that represent alternative commuter arteries may be identified as correlated because a problem on one commuter artery is likely to cause many commuters to alter their commute to use the other artery. Thus, an alert might be sent to a user who specified a route including a second commuter artery when a problem is impacting a first commuter artery. In such a scenario, the alert might warn of expected heavier traffic volume along that user's route.
As an example of another variation, it was described above that routes were specified by entering an origin and the destination of the route into a control to a mapping service. Routes might be specified in other ways. For example, a user might specify a metro area and/or a metro region. The mapping program might then provide a map. The user might specify routes by selecting individual roads in the map.
As a further variation, the content of the alert might be customized based on the information in the alert profile specified by the user. For example, once user database 107 contains information about the origin and destination for the user's desired route, business logic 105 can be programmed to, in addition to sending traffic alerts, send information about alternative routes between that origin and destination that do not contain traffic problems.
As a further variation, it is described that a control for a mapping service is interfaced to client 101. Client 101 might alternatively contain an interface to a mapping program, such as MICROSOFT® Streets & Trips™ mapping program, or the client need not determine the specific roads in a route. The client may communicate to the server the origin and destination of the route and the server may access the required information about roads, such as by accessing a mapping service, a mapping program or a database resident on the server or in any other suitable manner.
Client 101 is described above to be resident on a PC connected to the Internet and mobile client 111 is described as being resident on a portable electronic device, such as a mobile phone. However, these are examples only. In one embodiment, client 111 is mobile so that it will be with the user or in the user's car when a traffic alert occurs. However, it is not necessary that client 111 be mobile. For example, client 111 could be implemented as a user's office computer. Likewise, it is not necessary that client 101 be stationary. Either client could be implemented by software running on hardware that includes, but is not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, network PCs, cellular phones, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. Likewise, server 104 may reside on any convenient computer system, such as a single or multiprocessor computer.
The aspects of the invention described herein are not limited in their application to the details of construction and the arrangement of components set forth in the above description or illustrated in the drawings, as these aspects are capable of other embodiments and of being practiced or of being carried out in various ways. Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting.
The above-described embodiments of the present invention can be implemented in any of numerous ways. For example, the embodiments may be implemented using hardware, software or a combination thereof. When implemented in software, the software code can be executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers. It should be appreciated that any component or collection of components that perform the functions described above can be generically considered as one or more controllers that control the above-discussed function. The one or more controller can be implemented in numerous ways, such as with dedicated hardware, or with general purpose hardware (e.g., one or more processor) that is programmed using microcode or software to perform the functions recited above.
It should be appreciated that the various methods outlined herein may be coded as software that is executable on one or more processors that employ any one of a variety of operating systems or platforms. Additionally, such software may be written using any of a number of suitable programming languages and/or conventional programming or scripting tools, and also may be compiled as executable machine language code.
In this respect, it should be appreciated that one embodiment of the invention is directed to a computer readable medium (or multiple computer readable media) (e.g., a computer memory, one or more floppy discs, compact discs, optical discs, magnetic tapes, etc.) encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement the various embodiments of the invention discussed above. The computer readable medium or media can be transportable, such that the program or programs stored thereon can be loaded onto one or more different computers or other processors to implement various aspects of the present invention as discussed above.
It should be understood that the term “program” is used herein in a generic sense to refer to any type of computer code or set of instructions that can be employed to program a computer or other processor to implement various aspects of the present invention as discussed above. Additionally, it should be appreciated that according to one aspect of this embodiment, one or more computer programs that when executed perform methods of the present invention need not reside on a single computer or processor, but may be distributed in a modular fashion amongst a number of different computers or processors to implement various aspects of the present invention.
Various aspects of the present invention may be used alone, in combination, or in a variety of arrangements not specifically discussed in the embodiments described in the foregoing and is therefore not limited in its application to the details and arrangement of components set forth in the foregoing description or illustrated in the drawings. For example, aspects described in one embodiment may be combined in any manner with aspects described in other embodiment.
Use of ordinal terms such as “first”, “second”, “third”, etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements.
Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having,” “containing”, “involving”, and variations thereof herein, is meant to encompass the items listed thereafter and equivalents thereof as well as additional items.
