Patent Grant
8433505
1. Technical Field
The following relates generally to navigation and traffic reporting systems, and in particular to systems and methods with traffic probes that report traffic conditions on intervals.
2. Related Art
Rush hour traffic volume, road construction, vehicular collisions, and roadside emergencies are just a few examples of the various events and circumstances that can cause traffic congestion. Due to the nature of such events traffic congestion can be difficult to predict. Although radio, television, and online news sources can provide traffic information gathered using various techniques such as highway cameras, phone-in traffic tips, satellite imagery, and road sensors; this information is stale and/or inaccurate.
Old or inaccurate traffic information can be troublesome for various reasons. For example, an alternate traffic route, which may be less convenient, is chosen due to a traffic report indicating that a traffic problem exists, even though, in fact, the problem has been resolved. This can cause a commuter to take a less optimal route, which can waste fuel, cause them to be late, and cause congestion on side-roads. Conversely, a traffic report may indicate that the commuter's route is clear, when in fact an event has, in the meantime, created a traffic jam, since the traffic report is based on information that is not current. Although it may be considered that more frequent positional reporting may help with faster detection of traffic jams, other considerations may be important, such as conservation of battery life of devices, network resources, and so on. Therefore, further improvements in navigation and traffic systems are desired.
Embodiments will now be described by way of example, and not limitation, with reference to the appended drawings wherein:
It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments described herein. Also, the description is not to be considered as limiting the scope of the embodiments described herein.
The following table of contents provides a guide to the disclosure, and is organized into sections. First, component technologies and techniques are described, followed by an example architecture in which such component technologies and techniques can be employed, and finally, disclosure of several applications that can be provided in such an architecture, and which can be based on the component technologies and techniques is provided.
Introduction
The following disclosure relates to a number of topics, as outlined below and addressed in further detail in sections with corresponding headings:
An object for vehicle navigation is providing a route from an origin to a destination. The route can be roughly defined to include an ordered sequence of roadways that may be traveled to move from the origin to the destination. In general, there will be many (perhaps millions of) possible sequences that may be used to travel between any given origin/destination pair. In practice, there are a relatively small number that are “good” (as defined by some measure or measures, such as shortest, fastest, and more subjective measures such as simplest, least stress, most scenic, and so on). Given a set of conditions, there often can be determined an optimal (best) route to fit a given measure or measures.
For computer-assisted vehicle navigation, a route can be defined relative to a map database. A map database generally comprises an object-based encoding of the geometry, connectivity and descriptive attributes of a collection of roadways, and is usually based on a topological model, such as a 1D directed graph inscribed within a 2D surface sheet. The individual objects in a model of this type include edges that mostly represent roads (such as the centerlines of roads), and nodes that represent locations where roads intersect and cul-de-sacs terminate. A “road” or “roadway” (used interchangeably here) in a map database can be defined in terms of a connected “chain” of edges that share a common name. Most roadways consist of a single connected chain. Some roads are more complicated, for instance, a road may be split in two by another geographic feature such as a river.
Certain non-road features can also be represented by edges, including railroads, streams and rivers, and the boundaries of area objects (faces) such as parks, water bodies, and military bases, as well as boundaries of towns, cities, counties and similar divisions of governmental hierarchy.
The geometry of the database can be represented by coordinate locations (x/y or longitude/latitude points) associated with nodes, and “shape” (often point sequences) associated with edges. The “raw” connectivity of the roadways is represented by the edge/node connectivity that is provided by the directed graph representation: each edge has a specific “from” and “to” node; each node has a list of edges that have the node at either the “from” or “to” end.
Actual road connectivity may be limited by descriptive attributes such as turn prohibitions and travel mode restrictions. Other descriptive attributes can include the road name, legal travel speed and direction (bi-directional or one-way), number of lanes and similar.
Map databases can carry different levels of detail. A fully detailed, or large-scale map database will include everything from the most important long-distance highways to minor back alleys and un-paved country lanes. A sparsely detailed, or small-scale map database can have only the most important highways and connections that allow long distance travel.
Map databases also include varying geographical extents of coverage. Some map databases may cover only a small area. Others may cover entire continents. Often there is an inverse correlation between scale and coverage extent, in that large-scale maps tend to have limited geographic coverage, while continental extent maps may have limited detail. Such a circumstance was particularly true for paper maps (city map vs. road atlas), and is still true in paper-equivalent computer map renderings. A familiar example is the internet-based mapping service: when zooming in on a given displayed map area, more detail and less extent are displayed, and when zooming out, less detail and more extent are displayed.
In fully-detailed databases, wide roads and roads with wide medians may also be split lengthwise into two separate one-way chains representing the two independent directions of travel. Many roads are short, consisting of only a single edge. Some roads are very long, spanning from ocean to ocean across a continent, and consisting of thousands of individual edges within a full-detailed representation. Most roads are somewhere between these two extremes.
A route as originally described may therefore be represented as a specific sequence of connected edges within a map database. Given a route with this representation, a variety of properties about the overall route can be determined by inspecting the individual edges. For instance, to determine the length of the route, one can sum the lengths of the individual edges. Similarly, to estimate travel time of a route, one can determine the travel time for each edge (length divided by speed) and accumulate the sum over the whole set. Such a travel time is termed “static”, in that it would be based on a fixed representation of speed.
More elaborate results may be determined by examining a route's edge sequence within the context of the containing database. For instance, the list of turn-by-turn instructions that are required to follow a route may be inferred by examining how the route traverses each node relative to the other edges that occur at the corresponding intersection. Some intersection traversals are more important than others, and may warrant explicit identification in a route representation. Other intersections are more trivial; for example, those in which no turn is made. Such intersections may not be explicitly identified in some representations.
Turning now to
In the example shown in
As will also be explained below, the notification sub-system 80 uses device data 78 from a plurality of mobile devices 100 to dynamically determine traffic conditions, such as the development of the congested zone 2, in order to prepare a notification 84 that can be sent to a mobile device 100 that is expected to be headed towards the congested zone 2.
Commute traffic congestion tends to follow very reliable patterns. For example, a given stretch of heavily used freeway at 7:30 AM every weekday morning, would be expected to have traffic moving much slower than during normal “free-flow” conditions. Within that basic model, more refined patterns can be found. For example, it can be found that traffic may be heaviest on Monday (33 mph average), a little lighter Tuesday-Thursday (37 mph) and perhaps lighter still on Friday (45 mph). However, the same stretch of freeway may be free flowing (e.g., 65 mph) at noon, flowing well during the evening commute (e.g., 60 mph), and racing along at 75+ mph overnight and on the weekend.
Further, observations for a single person traveling at roughly the same time over the same route for five days a week, 50 weeks a year, can be accumulated to develop a robust model of the traffic congestion that this person faces each day, including its consistency, its day-of-the-week and season-of-the-year variability, and perhaps most importantly, the congestion's effect on the travel time that the person experiences daily.
Furthermore, these observations can yield information about how the congestion tends to affect certain portions of the route. For example, a portion of a route following “Hwy 1” tends to flow at 39 mph, and the portion that follows “Hwy 2” tends to flow at 51 mph. In turn, the portion of Hwy 1 between 7th and 10th streets can be observed to average 34 mph at around 7:44 AM, and the portion between 10th and 14th streets observed to average 41 mph at 7:51 AM and so on.
This description of a single person's experience can be generalized into the system concept of collecting traffic data using “traffic probe” and using that data for traffic modeling. By collecting observations or data for a large enough number of vehicles/drivers (by, for example, using wireless devices with GPS), then those observations and that data can be aggregated and collectively analyzed to develop an overall model of traffic congestion. In such a system, each device (e.g., owned by a driver of a vehicle) serves as a probe sensing the traffic conditions at particular locations and times. The overall picture serves as the traffic model, and is a byproduct of the system.
To perform such traffic modeling and aggregation of probe data, a framework that sub-divides the highly trafficked parts of the road network into well defined “traffic segments” (e.g., Hwy 1 between 7th and 10th) is provided. Each traffic segment can correspond to a short “chain” of edges that are in the map database.
A route can be defined by a composition or series of road segments. A definition of a route can include a series of road segments, and information indicating how those road segments would be traversed for the route. Such a definition can be sent from a server (reference the example architecture, below), to a mobile device. Context concerning such a route also can be transmitted. For example, segments of roads that intersect road segments comprised in a route also can be transmitted with the route definition. In such a circumstance, the mobile device can have road segment information for the route, as well as information about roads that intersect the route. Such information can be used to provide context for a route on a display, as well as enabling faster reactions to deviation from the route. Other information also can be transmitted about the route, such as point of interest information about items in a selected category found along the route.
For traffic and congesting modeling using a road segment-based system, each probe can travel through the network (matching the travel shape of its path to the shape of a continuous sequence of edges) and can provide its average speed through each road segment (a road segment comprises portions of one or more roads, and need not be, for example, a portion of only a single road.) Such information can be assigned to a best-fitting time bucket.
Even with a well-distributed and robust number of probes, some road segments may not be well traveled at certain times of the day (for instance, reverse commute directions); it may also be that some time periods of the day may not have seen very many probes anywhere (2:00-3:00 AM). However, these “gaps” in the data collection represent locations and times when there is not much traffic to begin with (in that the absence of probes in an otherwise well-distributed probe set leads to that conclusion); therefore, such data gaps are not considered to represent a true lack of knowledge concerning traffic conditions on those road segments or at those times. Rather, such absence can itself be considered an indication of where and when traffic congestion likely will not occur, and using default static speed data would suffice.
One product of such a data collection and aggregation process is a “historical traffic model”. In one example, a historical traffic model includes a list of traffic segments and associated time-of-day, day-of-week (and given enough time, week-of-year) time slots that contain expected traffic flow speeds (potentially with error estimates) during that time slot on that segment. A traffic segment can be on the same level of granularity as road segments, can be more detailed than road segments, or less detailed than road segments. For example, a single traffic segment can represent multiple road segments over which similar traffic conditions exist. By further example, a traffic segment can represent only a portion of a road segment, where divergent traffic conditions are found to exist, as compared with the rest of the road segment. Gaps can be filled with default “static” speeds. The model can be constructed as a large matrix, with rows representing traffic segments and columns representing time slots.
In some embodiments, it may be that only 20-25% of the edges in the map database will be “covered” by the model, because most edges are minor roads that may have little or no congestion or traffic patterns of interest, and therefore may not be of primary concern. Instead, freeways, highways, and important arteries and connecting ramps would be the primary focus of the traffic model.
One useful application of a historical model is to improve the accuracy of travel time estimation, and in one specific application, Estimation Time of Arrival (ETA) calculations or determination. ETA is an important feature provided by a vehicle navigation system. ETA is a fairly simple concept: “if I leave now and follow this route, about when will I get there?” Determining ETA is equally simple on the surface: if I know my route, and I have an estimate of how long it will take to travel the route (for example, the “static” summation described above), then I can estimate my ETA by taking the current time (or in general, the expected departure time) and merely add the travel time estimate. This technique is good as long as the travel time estimate is reliable.
However, travel time estimates can be unreliable. In fact, there are a variety of factors that can cause travel time to vary. Very long routes probably involve one or more stops (for fuel, food, sleep, etc.) that will increase travel time. Travel time is also (obviously) dependent on actual travel speed: some people drive fast, some drive slow; some times there is bad weather or unforeseen detours; sometimes there is traffic congestion that is slow, slower or even stopped all together. Accurately computing ETA in an automated vehicle navigation system is therefore problematic. Many of the influencing factors are completely beyond the insight or control of the best automated system, as they rely on human behavior (e.g., the decision to make a stop) or the unpredictable future (traffic “accidents” happen). However, if we factor out the uncontrollable, there are still many refinements that may be made to improve travel time estimation accuracy.
Historical modeling techniques also can be personalized for each user, such that particular user habits and preferences can shape data collected and how that data is used in developing a traffic model for that user.
Data collection for and observations about personal driving habits can be used to improve accuracy of the estimation of route travel time and correspondingly ETA determination, and further that historical traffic models have the potential for even greater improvement and wider application.
However, both of these methods rely on the stability of previously-observed driving patterns, and sometimes actual traffic congestion (due to accidents, bad weather, sporting events and similar, or just wide variability) is much worse (and occasionally much better) than expected.
If the departure time for a trip is immediate, it typically is preferable to know what the “live, real time” traffic conditions are now, rather than relying solely on the historical model, at least for the first portion of the route. Such an approach should yield more accurate travel time and ETA, and can serve as a trigger to alert the driver that today's experience will be worse (“you're going to be late”) or better (“you have ten extra minutes”) than usual.
With a network of probes (which can be used to produce the historical traffic model described previously), it is possible to monitor the current activity of all probes in real time to produce a current picture of traffic congestion, as will be addressed further below. For example, for all traffic segments, a list of recent probe samples for each segment can be tracked and used to compute a “live expected speed” for the segment.
An approach to using these live speeds to compute travel time can be similar to the use of speeds from the historical model and can include stepping through the route's edges in sequence computing travel times for each edge. If the edge corresponds to a traffic segment for which there is a current live speed, then that speed can be used. If there is no live speed, then the historical model value from the appropriate time slot can be used. If there is no traffic segment, then a static speed can be used.
In practice, a robust implementation is more complicated than this conceptual description. One reason is that live traffic has a limited “shelf life”. In other words, after some amount of time (e.g., 30 minutes), it is likely that the current live speed will be invalid, and that the historical pattern speed may be more accurate.
A preferred speed determination function includes a continuous function of live and historical values. A simplified description of one such function can be: for a set time along the route (<10 minutes?) the average live speed of recent probes is used, then for some period of time (10-30 minutes?) a decreasing fraction of live data combined with an increasing fraction of historical speed data is used, after which historical is used exclusively.
Because conditions will change, the ETA calculation preferably is continuously updated as the route is consumed (traveled) during driving. Such preference is based on at least three reasons. First, actual traffic congestion will continue to evolve, and probes driving somewhere up ahead may detect different and new conditions, thus evolving the live model. Second, because part of the route has been consumed by driving, the location framework for live traffic has shifted, so that live information is needed for roads that are further along the route than originally needed. Third, because actual travel progress may vary greatly from the original estimate (particularly on long routes), the time framework of the historical model may also change, resulting in a dramatic increase or decrease of likely traffic speeds far ahead.
Live traffic and congestion data, such as that obtained from in-vehicle probes, can be used for modelling traffic and congestion, and can supplement a historical model. A mixture of live data and historical data can be used.
It was described above that some examples include probes provided in moving vehicles that report an average speed value over a segment of road. Average speed can be represented as an average speed value, as time and distance information, as time information, if distance is known, as a difference from an expected average speed value, or equivalent forms of expression that allow determination of an average speed value on a particular segment (or a portion thereof).
Such segment-based reporting provides benefits that are not available from point based reporting. Point-based reporting is where a probe or device indicates an instantaneous speed value at a given time and/or position. Point-based reporting generally consumes more device power, bandwidth, and loads a receiving server more than segment-based reporting. Segment-based reporting can be done based on pre-defined road segments.
For example, a number of roads each can be divided into a number of segments. The divisions of a road into segments can be recorded by defining lat/lon positions for a start and an end of each segment. A lat/lon defining an end of one segment can be used as the lat/lon for the next segment on that road. Other definitional approaches can include providing a lat/lon for a start of a segment and a distance offset. As would be understood by a person of ordinary skill, a variety of approaches to defining road segments can be provided, so long as a given mobile device can determine starting and ending conditions for road segments that it is traversing.
Each of the road segments can be provided with an identifier. The identifiers of the road segments can be made available to the mobile devices (e.g., mobile device 100). In some examples, the mobile device 100 can store all road segment definition data and the identifiers for those defined road segments. Such data also can be stored on the server, or otherwise accessible to the server, such that sharing of segment identifiers provides a way for the mobile devices and the servers to identify particular road segments.
In one preferred implementation, a route is determined by a server. The route can be defined by a sequence of identified road segments (can be identified, for example, by identifiers, or by a sequence of lat/lon positions). The definition of the route can be transmitted wirelessly from the server to mobile device 100. Mobile device 100 can store the route definition in a memory, and access the road segment data from the memory (see e.g., flash memory 108 and RAM 106 of
In other circumstances, a probe device (e.g., mobile device 100) may not be in an active route guidance mode, and instead may be functioning more as a traffic probe. In such circumstances, that device may be provided only a few road segments at a time, such as the next one or two road segments, and these road segments would not necessarily be ordered into a route.
In segment-based reporting, progress reports can be based on segments, rather than on sampling of instantaneous speed at different points along a route. For example, reports can include average speed for a device on a completed segment. However, for segment-based reporting, if a probe vehicle gets stuck in traffic before finishing a given segment, an arbitrarily or unknown delay may occur for the probe to finish the segment and report. Thus, a segment reporting system could fail to report existence of heavy traffic in conditions when such reporting may be most useful. Also, where there is a specific, potentially serious traffic condition, it can be useful to have a more granular perspective as to where that problem is within a given road segment.
Additional logic can be provided in each probe, which monitors progress in completing each segment. If the probe is not making sufficient progress (average speed is less than 15 mph, for example), the logic ends the segment early and reports an average speed immediately.
In an example where the segments are defined using fixed road segments, such logic can use a “partial” segment defined as a segment plus an offset distance (e.g., a number of meters) from the beginning of the segment. After the first partial segment report, the probe can continue to make partial reports until the segment is complete. A server receiving this report information can treat each partial report as an estimate of the speed on the entire segment, extrapolating the speed to the entire length of the segment.
For each subsequent partial report, the server can update the average speed of the segment, until eventually the server can provide a complete report for that segment. If multiple probes are on the same segment and sending partial reports, the server can update each partial report from each probe using a trip identifier. The server may ultimately save only the final, completed segment report to a historical database, in situations where the true average speed on that segment is the principal figure used for providing estimates, such as ETA and ETD. These partial reports also can be used to build a sub-segment resolution representation of traffic on the segment, pinpointing where traffic conditions are worst along the segment. In some examples, these partial reports can be used in determining where to subdivide (or further subdivide) a road into segments.
In some implementations, mobile device 100 does not make reports for each road segment completed, and instead makes reports responsive to detecting unexpected progress conditions. For example, data transmitted for a route can comprise road segment definitions as previously discussed. Road segment definitions can include historical average speed information. If the average speed on a traversed road segment does not appreciably differ from the average speed provided from the server, then mobile device 100 can determine not to send a progress report after that road segment completes.
A limited shelf life of traffic data also implies that the availability of live traffic data for a probe-based system depends on the existence of traffic probes. Further, such probes would best be available during potential times of congestion on routes where such congestion likely would occur. As such, a probe-based live traffic model benefits from the presence of a “critical mass” of probes driving around the corresponding road network. There are many possible ways to define critical mass. One useful definition is that, for each important traffic segment, there has been at least one probe sample collected within the last 5 minutes. In a gradual probe deployment (for instance, based on the gradual adoption of a consumer application), it is likely that the most highly trafficked roadways will achieve critical mass first, followed by less highly trafficked roadway, and so on. It is also likely that some directions of some roads, and certain times of the day (or night) may not readily achieve a critical mass of live traffic probes. However, because there is a high correlation between presence of probes at locations and at times where and when there is a need for probe data, a “working” critical mass can be achieved with tractable probe penetration numbers.
A definition of critical mass can be adapted for particular users. For example, a route taken to work by a particular user may achieve critical mass on a given day, if each (potentially congested) traffic segment had at least one valid probe sample available before that user drove such segment. Thus, in a given deployment, some people will enjoy the benefits of critical mass in advance of general availability. A probe-based system also causes some probes to be “sacrificial probes” in that those problems did not get a live traffic data, and instead were caught in a given traffic problem. In other words, for some users to avoid traffic, some other user has to encounter it.
It is possible to extend the benefits of the live traffic model to other applications. For example, an application can be provided that estimates a required departure time, to arrive at a given destination at or before a given time. More particularly, the application can give updates as to changes in required departure time based on the live traffic model. For example, if a person knows of (or has calendared) a 10:30 appointment, a device, such as a digital assistant or phone, can repeatedly check an ETA, and provide an alert when the ETA is within a range of the appointment time (e.g., 5, 10, 15, or 20 minutes). If the person has experience traveling that route, then such an application can help the user leave at an appropriate time based on live traffic conditions, rather than simply on personal experience. The ability to personalize the ETA is applicable in this application as well. Further user selectable capabilities can be provided, including selecting when alerts are provided. Still further, on longer trips, the application can provide an alert sooner. The person also can calendar the urgency or importance of the meeting and the application can respond to that importance or urgency level in tailoring when alerts should be given.
To aid the reader in understanding at least one environment in which the notification sub-system 80, and the above-described applications, may be implemented, an example system comprising the wireless network 200 and other components that may be used to effect communications between mobile devices 100 and the notification sub-system 80 will now be described.
As noted above, data communication devices will be commonly referred to as “mobile devices”. Examples of applicable mobile devices include pagers, cellular phones, cellular smart-phones, portable gaming and entertainment devices, wireless organizers, personal digital assistants, computers, laptops, handheld wireless communication devices, wirelessly enabled notebook computers and the like.
One exemplary mobile device is a two-way communication device with advanced data communication capabilities including the capability to communicate with other mobile devices or computer systems through a network of transceiver stations. The mobile device may also have the capability to allow voice communication. Depending on the functionality provided by the mobile device, it may be referred to as a smartphone, a data messaging device, a two-way pager, a cellular telephone with data messaging capabilities, a wireless Internet appliance, or a data communication device (with or without telephony capabilities).
The mobile device may be one that is used in a system that is configured for continuously routing content, such as pushed content, from a host system to the mobile device. An example architecture of such a system will now be described.
Referring now to
Message C in
The mobile device 100 may be adapted for communication within wireless network 200 via wireless links, as required by each wireless network 200 being used. As an illustrative example of the operation for a wireless router 26 shown in
Although the above describes the host system 250 as being used within a corporate enterprise network environment, this is just one embodiment of one type of host service that offers push-based messages for a handheld wireless device that is capable of notifying and preferably presenting the data to the user in real-time at the mobile device when data arrives at the host system.
Provision of a wireless router 26 (sometimes referred to as a “relay”), there are a number of advantages to both the host system 250 and the wireless network 200. The host system 250 in general runs a host service that is considered to be any computer program that is running on one or more computer systems. The host service is said to be running on a host system 250, and one host system 250 can support any number of host services. A host service may or may not be aware of the fact that information is being channelled to mobile devices 100. For example an e-mail or message program 138 (see
As discussed above, a mobile device 100 may be a hand-held two-way wireless paging computer as exemplified in
The host system 250 shown herein has many methods when establishing a communication link to the wireless router 26. For one skilled in the art of data communications the host system 250 could use connection protocols like TCP/IP, X.25, Frame Relay, ISDN, ATM or many other protocols to establish a point-to-point connection. Over this connection there are several tunnelling methods available to package and send the data, some of these include: HTTP/HTML, HTTP/XML, HTTP/Proprietary, FTP, SMTP or some other proprietary data exchange protocol. The type of host systems 250 that might employ the wireless router 26 to perform push could include: field service applications, e-mail services, stock quote services, banking services, stock trading services, field sales applications, advertising messages and many others.
This wireless network 200 abstraction can be accomplished by wireless router 26, which can implement this routing and push functionality. The type of user-selected data items being exchanged by the host could include: E-mail messages, calendar events, meeting notifications, address entries, journal entries, personal alerts, alarms, warnings, stock quotes, news bulletins, bank account transactions, field service updates, stock trades, heart-monitoring information, vending machine stock levels, meter reading data, GPS data, etc., but could, alternatively, include any other type of message that is transmitted to the host system 250, or that the host system 250 acquires through the use of intelligent agents, such as data that is received after the host system 250 initiates a search of a database or a website or a bulletin board.
The wireless router 26 provides a range of services to make creating a push-based host service possible. These networks may comprise: (1) the Code Division Multiple Access (CDMA) network, (2) the Groupe Special Mobile or the Global System for Mobile Communications (GSM) and the General Packet Radio Service (GPRS), and (3) the upcoming third-generation (3G) and fourth generation (4G) networks like EDGE, UMTS and HSDPA, LTE, Wi-Max etc. Some older examples of data-centric networks include, but are not limited to: (1) the Mobitex Radio Network (“Mobitex”) and (2) the DataTAC Radio Network (“DataTAC”).
Providing push services for host systems 250 can be bettered by the wireless router 26 implementing a set of defined functions. The wireless router 26 can be realized by many hardware configurations; however, features described likely would be present in these different realizations.
Referring to
The mobile device 100a shown in
The display 12 may include a selection cursor 18 that depicts generally where the next input or selection will be received. The selection cursor 18 may comprise a box, alteration of an icon or any combination of features that enable the user to identify the currently chosen icon or item. The mobile device 100a in
The mobile device 100b shown in
The mobile device 100 may include a wide range of one or more positioning or cursor/view positioning mechanisms such as a touch pad, a positioning wheel, a joystick button, a mouse, a touchscreen, a set of arrow keys, a tablet, an accelerometer (for sensing orientation and/or movements of the mobile device 100 etc.), or other input device, whether presently known or unknown, may be employed. Similarly, any variation of keyboard 20, 22 may be used. It will also be appreciated that the mobile devices 100 shown in
Now, to aid the reader in understanding the structure of the mobile device 100 and how it can communicate with the wireless network 200, reference will now be made to
Referring first to
The main processor 102 also interacts with additional subsystems such as a Random Access Memory (RAM) 106, a flash memory 108, a display 110, an auxiliary input/output (I/O) subsystem 112, a data port 114, a keyboard 116, a speaker 118, a microphone 120, a GPS receiver 121, short-range communications 122, and other device subsystems 124.
Some of the subsystems of the mobile device 100 perform communication-related functions, whereas other subsystems may provide “resident” or on-device functions. By way of example, the display 110 and the keyboard 116 may be used for both communication-related functions, such as entering a text message for transmission over the network 200, and device-resident functions such as a calculator or task list.
The mobile device 100 can send and receive communication signals over the wireless network 200 after required network registration or activation procedures have been completed. Network access is associated with a subscriber or user of the mobile device 100. To identify a subscriber, the mobile device 100 may use a subscriber module component or “smart card” 126, such as a Subscriber Identity Module (SIM), a Removable User Identity Module (RUIM) and a Universal Subscriber Identity Module (USIM). In the example shown, a SIM/RUIM/USIM 126 is to be inserted into a SIM/RUIM/USIM interface 128 in order to communicate with a network. Without the component 126, the mobile device 100 is not fully operational for communication with the wireless network 200. Once the SIM/RUIM/USIM 126 is inserted into the SIM/RUIM/USIM interface 128, it is coupled to the main processor 102.
The mobile device 100 is a battery-powered device and includes a battery interface 132 for receiving one or more rechargeable batteries 130. In at least some embodiments, the battery 130 can be a smart battery with an embedded microprocessor. The battery interface 132 is coupled to a regulator (not shown), which assists the battery 130 in providing power V+ to the mobile device 100. Although current technology makes use of a battery, future technologies such as micro fuel cells may provide the power to the mobile device 100. In some embodiments, a plurality of batteries, such as a primary and a secondary battery may be provided.
The mobile device 100 also includes an operating system 134 and software components 136 to 146 which are described in more detail below. The operating system 134 and the software components 136 to 146 that are executed by the main processor 102 are typically stored in a persistent store such as the flash memory 108, which may alternatively be a read-only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that portions of the operating system 134 and the software components 136 to 146, such as specific device applications, or parts thereof, may be temporarily loaded into a volatile store such as the RAM 106. Other software components can also be included, as is well known to those skilled in the art.
The subset of software applications 136 that control basic device operations, including data and voice communication applications, may be installed on the mobile device 100 during its manufacture. Software applications may include a message application 138, a device state module 140, a Personal Information Manager (PIM) 142, a connect module 144 and an IT policy module 146. A message application 138 can be any suitable software program that allows a user of the mobile device 100 to send and receive electronic messages, wherein messages are typically stored in the flash memory 108 of the mobile device 100. A device state module 140 can provide persistence, i.e. the device state module 140 provides for availability and storage of potentially important device data. Device state module 140 can be implemented using flash memory 108 (or other non-volatile memory technologies), so that the data is not lost when the mobile device 100 is turned off or loses power. A PIM 142 includes functionality for organizing and managing data items of interest to the user, such as, but not limited to, e-mail, text messages, instant messages, contacts, calendar events, and voice mails, and may interact with the wireless network 200. A connect module 144 implements the communication protocols that are required for the mobile device 100 to communicate with the wireless infrastructure and any host system 250, such as an enterprise system, that the mobile device 100 is authorized to interface with. An IT policy module 146 can receive IT policy data that encodes IT policies, and may be responsible for organizing and securing rules, such as a “Set Maximum Password Attempts” IT policy, and password expiration policies.
Other types of software applications or components 139 can also be installed on the mobile device 100. These software applications 139 can be pre-installed applications (e.g., applications other than message application 138) or third party applications, which are added after the manufacture of the mobile device 100. Examples of third party applications include games, calculators, and utilities.
The additional applications 139 can be loaded onto the mobile device 100 through at least one of the wireless network 200, the auxiliary I/O subsystem 112, the data port 114, the short-range communications subsystem 122, or any other suitable device subsystem 124.
The data port 114 can be any suitable port that enables data communication between the mobile device 100 and another computing device. The data port 114 can be a serial or a parallel port. In some instances, the data port 114 can be a USB port that includes data lines for data transfer and a supply line that can provide a charging current to charge the battery 130 of the mobile device 100.
For voice communications, received signals are output to the speaker 118, and signals for transmission are generated by the microphone 120. Although voice or audio signal output is accomplished primarily through the speaker 118, the display 110 can also be used to provide additional information such as the identity of a calling party, duration of a voice call, or other voice call related information.
Referring now to
Signals received by the antenna 154 through the wireless network 200 are input to the receiver 150, which may perform such common receiver functions as signal amplification, frequency down conversion, filtering, channel selection, and analog-to-digital (A/D) conversion. A/D conversion of a received signal allows more complex communication functions such as demodulation and decoding to be performed in the DSP 160. In a similar manner, signals to be transmitted are processed, including modulation and encoding, by the DSP 160. These DSP-processed signals are input to the transmitter 152 for digital-to-analog (D/A) conversion, frequency up conversion, filtering, amplification and transmission over the wireless network 200 via the antenna 156. The DSP 160 not only processes communication signals, but also provides for receiver and transmitter control. For example, the gains applied to communication signals in the receiver 150 and the transmitter 152 may be adaptively controlled through automatic gain control algorithms implemented in the DSP 160.
The wireless link between the mobile device 100 and the wireless network 200 can contain one or more different channels, typically different RF channels, and associated protocols used between the mobile device 100 and the wireless network 200. An RF channel is a limited resource that should be conserved, based on concerns such as limits of overall bandwidth and limited battery power of the mobile device 100.
When the mobile device 100 is fully operational, the transmitter 152 is typically keyed or turned on only when it is transmitting to the wireless network 200 and is otherwise turned off to conserve resources. Similarly, the receiver 150 may be periodically turned off to conserve power until it is needed to receive signals or information (if at all) during designated time periods. The receiver 150 also can be turned on to poll for data to be retrieved.
Some aspects of the description provided relate to a system architecture where information can be pushed to mobile devices. Such system architectures can operate to push information responsive to a request from a mobile. For example, mobile device 100 can request information periodically, and the system can respond with any messages or notifications determined to be applicable to device 100.
Turning now to
The status region 44 in this embodiment comprises a date/time display 48. The theme background 46, in addition to a graphical background and the series of icons 42, also comprises a status bar 50. The status bar 50 provides information to the user based on the location of the selection cursor 18, e.g. by displaying a name for the icon 53 that is currently highlighted.
An application, such as a maps program 60 (see also
Turning now to
The notification system 84, which in this example resides at the wireless router 26, stores traffic-related data in a traffic database 82. Such traffic-related data may comprise any device data 78 obtained from various mobile devices 100, copies of notifications 84 that have already been sent (or are about to be sent—to facilitate repeated use of the same notifications 84), and any other information that may be required to carry out the delivery of a notification 84 based on the acquisition of device data 78, several examples of which will be explained below. It will be appreciated that the traffic database 82 may represent any memory, datastore, or storage medium and may or may not be internal to the wireless router 26. For example, the traffic database 82 may be maintained by a third party or configured to be an integral component of the notification system 84. As such, the configuration shown in
The configuration shown in
More particularly,
If the segment is complete, then a report for that segment can be sent; in one example, the report includes an average speed for the mobile device on that now-completed segment. An example method for preparing such a report is depicted in
If the segment is not complete, then a determination (1007) whether progress has been abnormally slow is made. Such a determination can include comparing an average speed on the portion of the segment completed to an average speed for that segment (or a separately maintained average speed for that segment portion), and if the comparison indicates a slowing of more than a threshold, then an abnormally slow determination can be made. Other example approaches to determining abnormally slow conditions include detecting whether there was a sudden deceleration, which persists for more than a threshold amount of time, an appropriately scaled portion of the average speed, or whether an expected amount of time to complete the segment (or the portion completed) has exceeded a threshold. The determination (1007) can be used to detect an unexpected progress condition, such as an average speed slower than an expectation by more than a threshold (as explained, the expected average speed can be provided by a server, with data defining a route to be traversed).
If abnormally slow progress has been determined, then a report for the portion of the segment completed is sent (1013). Preferably, this report is sent responsively to the detection of abnormally slow progress, so that increased granularity of resolution where a potential problem is detected can be tracked.
Continuing with
If the current segment remains incomplete, then another partial segment report is sent (1021), which can be prepared according to the method of
Upon completion of a road segment, a new segment can begin (1011), and the depicted method can repeat. In this description, some elements were disclosed, for simplicity, as happening sequentially or serially. However, embodiments need not have such temporal ordering. For example, there may be some lag between when a segment is determined completed, such that the mobile device may already be physically present in a new road segment when the report for the last road segment is transmitted.
These messages can be received by a server (or group of servers, or other implementation of a centralized receiver of reports) and processed. An example method of such processing is depicted in
A determination (1305) about whether a traffic condition exists can be determined based on the received messages (reports). For example, a report indicating much slower average transit times for a partially completed road segment than for a report received earlier for the same segment may indicate a changed condition. Historical traffic data also can be accessed to determine whether that road segment portion is prone to congestion on that road segment portion (although typically, an average time for completing that road segment portion, or the entirety of the road segment preferably would be updated to reflect the existence of a regular congestion point).
Upon determining that a traffic condition exists, other devices (a second device) that are approaching the area can be identified (1307). One example approach to detecting whether a second device is approaching the area can be to analyze most recently received reports of devices, as described above, or to track which devices have that road segment on a current route. A detour can be determined (1309) that would allow circumnavigation of the traffic incident. An updated ETA determination (1311) also can be triggered based on a received partial segment report. An alert is sent (1313) to those devices determined to be approaching the traffic congestion; such alert can be accompanied by any proposed detour or updated ETA calculated. The alert can include a suggested detour. Alerts can be sent via Short Messaging Service (SMS), e-mail, via voice messaging, or a telephone call, for example. Further, the content of the alert can be expressed as text, graphically, or a combination thereof. For example, a map of a proposed detour can be provided for display on a graphical user interface of device 100.
Such disclosures are exemplary and other variations can be provided according to these examples. Where detours are indicated, the search can automatically be performed for those suggested detours, and results displayed, according to the above description for the main route. Results of a search also can initiate calculation of a detour, and display of indications of the availability of that detour, and the results of the search which prompted that detour.
In summary of some exemplary aspects disclosed above, mobile devices can operate as probes of traffic conditions in a segment-based reporting system. A segment-based reporting system has a characteristic that probe devices do not continuously report information, such as a current position, but instead report information on an segment. The segment can be a time segment, or a distance segment, for example. A distance segment can be pre-defined, such that a road can be sub-divided into a number of pre-defined segments, which are used by all probes in the system. Thus, each probe generally would send a report responsive to detecting completion of a given segment.
Where segments/segments are defined based on distance (as opposed to time), methods and systems performing such methods further operate to detect whether an abnormal condition is present on a given segment, thereby causing a delayed completion of the segment. For example, if probes are supposed to report an average time to complete each kilometer of a given road, then if there is an abnormally slow rate of travel on a given part of that road, such as an accident, the accident may prevent probes from completing the segment and reporting the average speed, which would be helpful in detecting the accident, and allowing other probes to avoid the accident. Therefore, systems and methods as described herein detect such conditions, by, for example, detecting an average speed slower than expected (can be thresholded), detecting sudden decelerations that persist, and so on. Responsive to such detection, probe devices can close the current segment early and report an average speed on the portion completed. A probe that closed a current segment early can enter a reporting mode that reports progress on a time-based interval, responsive to the early closing of the segment.
Although the above has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art as outlined in the appended claims.
This application claims priority from U.S. provisional patent application No. 61/290,577, filed on Dec. 29, 2009, and which is incorporated by reference in its entirety, for all purposes, herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5220507 | Kirson | Jun 1993 | A |
| 6012012 | Fleck et al. | Jan 2000 | A |
| 6810321 | Cook | Oct 2004 | B1 |
| 20050222756 | Davis et al. | Oct 2005 | A1 |
| 20090287402 | Liu et al. | Nov 2009 | A1 |
| Number | Date | Country |
|---|---|---|
| 2009068970 | Jun 2009 | WO |
| WO 2009068970 | Jun 2009 | WO |
| Entry |
|---|
| Extended European Search report mailed Mar. 18, 2011, in corresponding European patent application No. 10168158.3. |
| Examination Report mailed Jul. 26, 2011, in corresponding European patent application No. 10168158.3. |
| Summons to attend oral proceedings pursuant to Rule 115 91) EPC mailed Feb. 3, 2012, in corresponding European patent application No. 10168158.3. |
| Number | Date | Country | |
|---|---|---|---|
| 20110160988 A1 | Jun 2011 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61290577 | Dec 2009 | US |
