Patent Publication Number: US-10769946-B1

Title: Incentive-compatible, asymmetric-information, real-time traffic-routing differential-advice

Description:
TECHNICAL FIELD 
     This disclosure pertains generally to computer navigation management, and more specifically to automatically determining and electronically providing incentive-compatible, asymmetric-information, real-time traffic-routing differential-advice to a plurality of drivers and self-driving cars (and other road-based motor vehicles). 
     BACKGROUND 
     Serious congestion problems occur when multiple vehicles attempt to depart from or pass through a given location or route simultaneously, beyond a weather-specific threshold that the infrastructure can comfortably accommodate. For example, consider departures from a stadium following a college or professional football game. A large number of drivers depart from the same parking facilities through a limited number of exits and adjoining roadways. Each driver has the same information and expectations as every other driver. The vast bulk expect that their best chance to avoid stifling congestion and minimize the time during which they are stuck in traffic is to leave promptly when the game ends (or to leave early, especially if the game is not close), in order to beat the rush. Of course, the aggregate behavior of such drivers creates a huge traffic tie-up, making exit from lots difficult and time consuming, and further creating additional congestion on the routes leading away from the stadium after exiting the lot, often through several intersections. Any traffic information a driver receives from radio, other broadcasts, or apps such as Google Maps, is the same information obtained by every other driver from these sources. Information suggesting an alternative routing is often accepted by every driver receiving it, seriously diminishing what help that information could offer by creating congestion on the alternative route. 
     Similar problems are present in other scenarios in which a large number of people attempt to exit a fixed area in a given window of time. This applies not only to other situations in which crowds of people or vehicles attempt to depart events at roughly the same time, but evacuations in the event of natural or other disasters. For example, there has been no substantive progress in hurricane evacuations since Hurricane Katrina in 2005. Estimates of the average speed of evacuation during Katrina range from two to five miles per hour. As cars are limited to traveling much shorter distances on a tank of gas at those speeds, and at much higher engine temperatures, over 1,000 vehicles were reported pulled over on the shoulder of expressways, presumed overheated or out of gas. Additionally, in the attempt to get out of New Orleans, a large enough number of drivers chose to use an exit ramp onto the inbound lanes of expressways so as to substantially reduce average speeds and generate very hazardous driving conditions for first-responders trying to get into the city. As with the drivers leaving a stadium parking lot after a football game, everyone had the same information, and the same expectations about alternative routes. The evacuation order had been broadcast, and the vast majority of drivers started their cars and attempted to leave within minutes of that broadcast. There was no organized plan for evacuation of people without access to a car, or for families with only one car wanting to carry more persons, luggage, medicines and medical devices than the car could handle. When the possessor of the car sought to evacuate family members, low-speed travel crossing intersections where outbound travel was congested became difficult or impossible. For thousands of families, decisions as to the arrival target of evacuations were made without communication or coordination. In particular, children in school were taken to different locations than those chosen by their parents. Several newspapers reported thousands of cases of families unable to locate members for days afterward. 
     Similar congestion problems also occur whenever multiple vehicles or people attempt to move through a limited infrastructure simultaneously. Consider rush hour traffic. Over sixty years ago, William Vickrey (who later shared the 1997 Nobel Prize in Economics) wrote that average speed at the peak of rush hour could be dramatically increased if every driver ahead of the peak began her/his commute 10 minutes earlier, and every driver after the peak began 10 minutes later. No city or congested bridge (e.g., across the Hudson River, San Francisco or Chesapeake Bay, or at any international border) has found a way to take advantage of Vickrey&#39;s theory. Whether radio broadcasts, Google Maps, or Waze, every driver accessing a traffic information source has the same information. A small subset of drivers might be the ones who would benefit most from a given alternative route, because of the totality of their route and ultimate destination. However, these drivers have no way of knowing that. Slow speeds, long commuting times, increases in accidents, and frustration at a level affecting physical health, are all widespread. Similar issues exist with public transportation at rush hour. For example, overcrowded subway stops, as hordes try to catch the same trains at the same times, are neither pleasant nor conducive to good health or good behavior. 
     It would be desirable to address these issues. 
     SUMMARY 
     Incentive-compatible, asymmetric-information, real-time traffic-routing assignments and recommendations are automatically determined and individually provided to multiple participants (e.g., human or automated drivers of cars or other vehicles) traversing through a specific area in association with a given event associated with a particular organization. For one example, the organization can be an athletic association or concert promoter, and the event a sporting event or concert occurring at a specific stadium, arena or venue. At the conclusion of such events, large numbers of drivers attempt to exit and traverse through a physically constrained area at the same time, resulting in congestion. In this example, the venue&#39;s parking facilities, exits, nearby streets, intersections, highway ramps, and other potential bottlenecks can all become extremely congested for significant periods of time in these situations. 
     A set of rules is applied to minimize the time to traverse through the specific area in association with the specific event, summed over the multiple participants, accounting for physical constraints of the specific area and incentive-compatibility constraints concerning the participants. An initial suggested assignment is determined for each specific participant, based on applying the set of rules. Each initial suggested assignment includes a departure time and an initial route for the participant. Updated real-time data concerning physical constraints of the specific area are received, such as real-time traffic information. Real-time recommendations are determined for specific ones of the participants, based on applying the set of rules accounting for the updated real-time data. Real-time recommendations include suggestions to deviate from initial suggested assignments or from previous recommendations, based on the updated information. The initial suggested assignments and real-time recommendations are provided to the corresponding participants, for example by wirelessly communicating with apps running on the participant&#39;s mobile computing devices (e.g., by transmitting text messages, graphical mapping indicia, electronic audio commands, etc.). In some embodiments, assignments and recommendations are wirelessly communicated to automated driving systems associated with the participant&#39;s smart or self-driving cars. The determined initial suggested assignments and real-time recommendations facilitate real-time routing of traffic that incentivizes minimization of disutility associated with time to traverse through the specific area for the multiple participants. 
     Applying the set of rules can further comprise distinguishing between the total time to traverse through the area and “stuck” time while traversing through the area, with a greater disutility assigned to stuck time than to total time. Time during which a participant traversing through the specific area is moving at less than a specific threshold speed after initial departure can be classified as stuck time. Applying the set of rules can also further comprise distinguishing between time during which participants are traversing through the area prior to reaching their vehicles (e.g., after the game ends but before an attendee reaches his or her car), and time during which participants are traversing through the area after reaching their vehicles, with a greater disutility assigned to the later. In some embodiments, the set of rules even incentivizes increasing the time prior to reaching a vehicle, for example to encourage attendees to spend some time buying souvenirs or the like. In some embodiments, specific incentive-compatibility constraints to be utilized in applying the set of rules are received from the specific organization. For example, the organization could specify different weights to be applied to the disutility of different classifications of time spent traversing through the area (e.g., stuck time, total time, time before reaching one&#39;s car, etc.). The organization can also specify to weigh the disutility of different participants differently, for example to give preference to season-ticket holders or those with premium seating plans or the like. 
     In one embodiment, applying the set of rules takes the form of applying the prototypical algorithmic objective function minimize a,r  o (a,r)=Σ p  w m  log e  t d +Σ p  max(w s  log e  t s ), where p represents individual participants, t d  is the corresponding specific total time, t s  is the corresponding specific stuck time, w m  is the power to which each t d  for each individual participant is raised before summing, and w s  is the power to which each t s  for each individual participant is raised before summing. (a, r) are the long vector of the initial suggested assignments and the long vector of the real-time recommendations, determined by applying the set of rules to minimize the time to traverse through the specific area in association with the specific event, summed over the multiple participants. 
     The physical constraints of the specific area can be represented as mathematical relationships between traffic density and path-flow-through speed for the corresponding traffic infrastructure, which can be utilized in the set of rules to represent physical constraints in the specific area, to determine the initial suggested assignments and real-time recommendations. In one embodiment, these mathematical relationships are represented as, for each one of multiple paths through a specific point j in the specific area at specific time t, i jt (a,r)≤v jt E[F jt |t dc ], where i is input rate to the specific one of the plurality of paths, v is flow-through volume, f is statistical relation between entry rate and flow-through volume for minimizing time of participants to traverse through the specific area in association with the specific event, and E denotes the expectation operator. The mathematical relationships between traffic density and path-flow-through speed for traffic infrastructure of the specific area can further comprise accounting for the predicted behavior of cars driven by non-participants in the specific area. 
     Incentive-compatibility constraints, for each participant, concerning the multiple participants can be represented as mathematical relationships between the disutility of total time to traverse through the specific area and the disutility of stuck time while traversing through the specific area for all of the participants, which can be utilized in the set of rules to represent incentive-compatibility constraints concerning the multiple participants to determine the initial suggested assignments and the real-time recommendations. In one embodiment, these mathematical relationships can be represented as, for each vehicle v, E[t dv +uv c  t sv |a,r]≤E[t dv +u t sv |a′,r′,]∀(a′,r′)≠(a, r), where ∀ denotes “for all”, t d  is total time, t s  is stuck time, u is utility, (a′,r′) denotes any route other than the recommended one, and E denotes the expectation operator. 
     Another example scenario in which the functionality described herein can be utilized is rush-hour traffic management (e.g., where the specific organization is a transit authority, the specific event is a time period subject to traffic congestion, and the specific area is a jurisdiction of the transit authority). The functionality can also be used, for example, to manage evacuations (e.g., where a civic authority is responsible for evacuating a city or region in anticipation of a hurricane or other disaster). 
     The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of an exemplary network architecture in which an incentive-compatible, asymmetric-information, real-time traffic-routing differential-advice system (“IARTD”) system can be implemented, according to some embodiments. 
         FIG. 2  is a block diagram of the operation of an IARTD system, according to some embodiments. 
         FIG. 3  is a block diagram of a computer system suitable for implementing an IARTD system, according to some embodiments. 
     
    
    
     The Figures depict various embodiments for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein. 
     DETAILED DESCRIPTION 
       FIG. 1  is a block diagram illustrating an exemplary network architecture  100  in which an incentive-compatible, asymmetric-information, real-time traffic-routing differential-advice system (“IARTD”) system  101  can be implemented. The illustrated network architecture  100  comprises multiple clients  103 A,  103 B and  103 N, as well as multiple servers  105 A and  105 N. Although  FIG. 1  illustrates three clients  103  and two servers  105 A-N as an example, in practice many more (or fewer) clients  103  and/or servers  105  can be deployed. In one embodiment, the network  107  is in the form of the Internet, although other networks can be used in other embodiments, such as a private enterprise-level wide area network. 
     In  FIG. 1 , an IARTD system  101  is illustrated as residing on server  105   a , with a mobile device agent  109   a ,  109   b , and  109   c  running on each client  103   a ,  103   b , and  103   c , respectively. It is to be understood that this is an example only, and in various embodiments various functionalities of an IARTD system  101  can be instantiated on a client  103 , a server  105 , or can be distributed between multiple clients  103  and/or servers  105 . 
     Clients  103  and servers  105  can be implemented using computer systems  610  such as the one illustrated in  FIG. 3  and described below. The clients  103  and servers  105  are communicatively coupled to a network  107 , for example via a network interface  648  or modem  647  as described below in conjunction with  FIG. 3 . Clients  103  are able to access applications and/or data on servers  105  using, for example, the mobile device agent  109 , a web browser or other client software (not shown), etc. Clients  103  can be in the form of mobile computing devices, which are portable computer systems  610  capable of connecting to a network  107  and running applications. Some mobile computing devices are referred to as smartphones, although some mobile phones not so designated also have these capabilities. Tablet computers, in-dash or onboard vehicle computing systems, convertible laptops, laptop computers, hybrids, smart watches and other types of wearable computing devices are all examples of mobile computing devices. 
       FIG. 2  illustrates the operation of an IARTD system  101 , running on a server  105  and communicating with multiple mobile device agents  109  according to some embodiments. As described above, the functionalities of the IARTD system  101  can reside on a server  105  or other specific computer  610 , or be otherwise distributed between multiple computer systems  610 , including within a cloud-based computing environment in which the functionality of the IARTD system  101  is provided as a cloud-based service over a network  107 . It is to be understood that although the IARTD system  101  is illustrated in  FIG. 2  as a single entity, the IARTD system  101  represents a collection of functionalities, which can be instantiated as a single or multiple modules as desired. In some embodiments, the different modules of the IARTD system  101  can reside on different computing devices  610  as desired. Each mobile device agent  109  can be instantiated as an app for a given mobile operating system (e.g., Android, iOS, Windows 10, etc.), with different mobile device agents being specifically implemented for different types of mobile computing devices utilized by different end users. 
     It is to be understood that the components and modules of the IARTD system  101  can be instantiated (for example as object code or executable images) within the system memory  617  (e.g., RAM, ROM, flash memory) of any computer system  610 , such that when the processor  614  of the computer system  610  processes a module, the computer system  610  executes the associated functionality. As used herein, the terms “computer system,” “computer,” “client,” “client computer,” “server,” “server computer” and “computing device” mean one or more computers configured and/or programmed to execute the described functionality. Additionally, program code to implement the functionalities of the IARTD system  101  can be stored on computer-readable storage media. Any form of tangible computer-readable storage medium can be used in this context, such as magnetic, optical, flash and/or solid-state storage media, or any other type of media. As used herein, the term “computer-readable storage medium” does not mean an electrical signal separate from an underlying physical medium. 
     As described in detail below,  FIG. 2  illustrates the IARTD system  101  applying a given set of rules  201  to make initial suggested assignments  203  and real-time recommendations  205  to multiple parties responsible for operating and navigating (e.g., driving) vehicles (e.g., cars), so as to facilitate the real-time routing of traffic in a manner that incentivizes the individual operators to make decisions that maximize utility for participants, according to inputs and prioritizations of an organization (e.g., a college or professional athletic organization, an event promoter, a municipality, a regional transit authority, etc.). For clarity of description, the term “car” is used herein to refer to any type of vehicle under the guidance of the IARTD system  101 . Actual cars are a specific-use case (e.g., trucks, busses, motorcycles, etc., are other possible examples). The term “driver” is used to refer the party in a given vehicle that makes corresponding routing decisions, although in some cases this will not be the person actually operating the vehicle (or may be an automated device or system). 
     In one embodiment, the set of rules  201  applied by the IARTD system  101  in order to determine and make assignments  203  and real-time recommendations  205  to multiple drivers can be expressed via the following prototypical algorithmic objective function: Minimize a,r  o(a,r)=Σ c w m  log e  t d +Σ c  max(w s  log e t s ). In this objective function, c represents individual cars that are being guided by the IARTD system  101 . The objective function is designed to minimize the sum of certain types of costs, summed over all these cars. In this prototypical case the IARTD system  101  treats all cars equally, although certain cars or classes of cars can be assigned weighted prioritizations in other embodiments, as described below. For clarity of illustration and explanation, a c subscript for terms inside the summation is submersed. In the function, t d  is the corresponding particular car&#39;s time to destination (e.g., in minutes), whereas t s  is the total number of “stuck” minutes (or other unit of time). Total time to destination can be in the form of the total number of minutes the car will take either to reach its final destination, or to reach the boundary of an area being managed by the IARTD system  101 . Stuck time can be time while in the area during which the vehicle is not moving, or is moving below a “stuck threshold” speed. The specific value to use for the stuck threshold is a variable design parameter that can be set differently in different embodiments and under different circumstances as desired (e.g., 0.25 miles/hour, 1 mile/hour, 5 miles/hour, etc.). 
     In some embodiments, the IARTD system  101  does not simply minimize the sum of these costs. More specifically, in one embodiment, before summing, individual times to destination, t d , are raised to the power w m , a parameter chosen for the application (the objective function is log-linear, log e  x y =y log e  x.). For the purpose of this example, suppose w m =1.1. In this embodiment, before summing, individual minutes spent stuck are raised to the power w s  (suppose for example that w s =1.4). The 1.1 power (w m ) has the effect that the IARTD system  101  will adjust slightly to let the slowest-moving traffic move faster, even if that slightly increases total driving time. In other words, w m =1.1 gives a slightly higher priority to the slowest-moving traffic. The 1.4 power (w s ) gives a notably higher priority to a car that spends a disproportionate number of minutes stuck. This results in a higher priority for reducing the time spent stuck for those cars which will be stuck longer, even if that more-than-slightly increases total driving time. In different use cases, different values can be used for w m  and w s  as desired. 
     The variables used to accomplish this grand minimization in the function shown above are a, which is shorthand for the long vector of initial suggested assignments  203 , and r, shorthand for the long vector of real-time recommendations  205 . Applying this function to the totality of the participating cars, the IARTD system  101  determines and makes initial assignments  203  in advance of providing “move” recommendations  205 . An initial assignment  203  made to a given driver can include an amount of time for which the car&#39;s occupants are recommended to wait before heading to the car (or otherwise depart their current location), as well as an initial planned route. The system also determines and makes real-time recommendations  205  to the drivers, based on application of the rule set  201  (e.g., the function above). A real-time recommendation  205  can be in the form of a suggestion that a particular car change to an alternate routing, for example due to recognition by the IARTD system  101  that the originally assigned routing is showing higher-than-predicted congestion. It is to be understood that the IARTD system  101  can receive real-time information concerning traffic, weather and other conditions, and, taking this updated data into account, apply the set of rules  201  to determine real-time recommendations  205  to specific drivers to change their routes, adjust their departures times, etc. Although assignments  203  and real-time recommendations  205  are made separately, both seek to minimize the same objective function. Note that initial assignments  203  and real-time recommendations  205  are in fact both a form of recommendations. This approach to congestion reduction results in scenarios which are not command-and-control. Instead, participants work with the IARTD system  101  to reduce traffic congestion because they themselves are incentivized to do so, by the reduction of total and/or stuck time they experience when participating. When drivers are so incentivized, they likely are willing to voluntarily follow assignments  203  and real-time recommendations  205 . 
     In one embodiment, specific organizations (e.g., athletic associations, event promoters, municipalities) purchase, contract for or otherwise obtain use of a specific implementation of the IARTD system  101  configured to their specifications, and make their instantiation available to drivers or other users who are their customers, charges, etc. For example, a college athletic association could purchase an implementation of the IARTD system  101  configured to guide drivers out of the parking facilities at their stadium after football games. Individuals who purchase tickets could then be offered use of the IARTD system  101 , for example by downloading the mobile device agent  109  to their smartphones (e.g., in the form of an app), and receiving initial assignments  203  and real-time recommendations  205  from the IARTD system  101 , for example in the form of text messages, graphical indicia on maps displayed on mobile devices screens, electronic audio commands (e.g., voice simulated driving directions through the mobile device speaker or car audio system), or any combination of such textual, graphical and/or audio output to the drivers. 
     It is to be understood that while participating organizations are not expected to understand the mathematical meaning of w m  and w s  (e.g., the 1.1 and 1.4 powers), organization can be prompted to enter configuration criteria indicating weights of importance to assign to total time and stuck time, based for example on an organization&#39;s perceived importance of these factors to the drivers under its jurisdiction (e.g., how likely the organization thinks total time to destination relative to the total minutes spent being stuck is to result in driver resentment, complaints, and refusals to participate, etc.). The IARTD system  101  can provide default values, and in some embodiments organizations may configure these values up and down as desired, for example through a system administrator dashboard or other user-interface. The values 1.1 and 1.4 are used as examples to illustrate a scenario in which time spent stuck is adjudged to have greater disutility per passing minute than the total time to reach the chosen destination, and hence is assigned greater weight for overall minimization. Oftentimes drivers are more frustrated by stuck time than longer total drive time, but the specific weightings for these factors are configurable parameters. 
     In some embodiments the objective function can include a third summation not shown in the formula above, but which does not fundamentally change the nature of the mathematical relationships involved. As shown above, the objective function starts counting “time to destination” t d  when the event (e.g., the game) ends. Suppose, though, that the organization believes that the disutility of an additional minute spent remaining at the event (e.g., to talk with persons seated nearby, to purchase souvenirs, to purchase and consume food, or to take photos and selfies) is valued differently than the disutility of arriving at the destination one minute later. In such a case, “time to destination” for that organization can be redefined to start when a driver reaches the car (or physically departs the stadium, enters the parking lot, etc.), with “added time spent at the event before going to the car” t a  added into the objective function separately, for the sole reason that t a  can be raised to a different power than t d  before summing, to reflect the organization&#39;s belief about its separate disutility. In other words, the specific rule set  201 , as expressed in the mathematical relationships between the parameters of the formula, can be modified between embodiments and use cases to account for different disutilities and relative weightings between them. 
     It is further possible that an organization desires that people remain on the premises (e.g., in the stadium) after the event finishes, for example to spend more money on concessions. In such a scenario, longer “added time spent at the event before going to the car” is viewed as a positive, at least up to a point. This can be addressed by an adjustment to multiply the summed t a &#39;s by a small negative coefficient before entering them into the objective function. Because going too far with this type of preference could frustrate drivers, in some embodiments the IARTD system  101  alerts an organization to the potential dangers when such weighting is introduced, for example by suggesting to classify only, say, the first 10 minutes of “added time spent at the event before going to the car” as t a , with “time to destination” starting 10 minutes after the event ends. Note that the specific suggestions, alerts, warnings, defaults and other interaction specifics between the IARTD system  101  and organization level administrators can vary between embodiments as desired. 
     Note also that the objective function as presented above treats all cars potentially participating as equally important. In some embodiments, an organization may treat disutility of different drivers or classes of drivers differently. For one example, luxury-box purchasers or season-ticket holders could be weighted above other customers at the event. For another, cars containing more passengers who had attended the event could be given greater weight (these two examples are not mutually exclusive). Both examples could be accommodated by incorporating a coefficient larger than 1 for the cars of such drivers, multiplied to the time measure after it had been raised to the relevant power. 
     For each organizational scenario (e.g., exit management after a specific sporting event at a given stadium/arena, or after a concert at a given venue), data concerning relevant physical constraints is input into the IARTD system  101 . For example, each parking lot serving the stadium is physically constrained by the number of cars that can leave per period of time via each exit without resulting in dramatically lower speeds through the exit than the street it reaches, thereby causing cars to get stuck in the lot before reaching the exit. For each parking area, exit, street, intersection, ramp, etc., there exists some given limitation of the number of vehicles that can pass per period of time without creating excessive congestion. Thus, the IARTD system  101  can account for the physical constraints of each potential bottleneck in the area being managed in a given scenario, such as each path through an affected intersection, each entry ramp onto an expressway, each change in the number of available lanes, etc. This data can be obtained, for example, from traffic surveys as to the relation between traffic density and path-flow-through speed. In different embodiments the data concerning the physical constraints of specific traffic infrastructure can be received and/or otherwise obtained from different sources as desired. This data can be updated in real-time as new information becomes available. For example, as noted above, real-time information concerning changes to traffic, weather, road conditions, lane closures, etc., can be received in real-time. The IARTD system  101  applies these data to constrain (a, r), the initial assignments  203  and real-time recommendations  205 . These constraints can incorporate additional information such as traffic-light timing, lane openings and closures, etc. In some instances the organization will not be able to control these factors (e.g., where the organization is a private party and the traffic-light is controlled by a public utility). In other situations, the organization can obtain control (e.g., the organization is the municipality or the bottleneck is on private property). The specific target volumes of traffic throughput per unit of time used by the IARTD system  101  for given potential bottlenecks are variable design parameters, and can be adjusted as desired. 
     The physical constraints affecting the traffic throughput in an area under the management of the IARTD system  101  in a given scenario are represented mathematically, and built into the instantiation of the rule set  201  used by the IARTD system  101  in that implementation. To the extent consistent with objective-function minimization, and accounting for the predicted behavior of cars driven by nonparticipants, initial assignments  203  to individual drivers of when to head to their respective cars will be constrained by these values. 
     In one embodiment, these physical constraints are of the form, for each path through an intersection (from direction n,s,e,w), or an entry ramp j at time t (measured from t=0 at the end of the event): i jt (a,r)≤v jt  E[f jt |t dc ], where i is the input rate to that path, v the flow-through volume and f the (statistically) expected relation between entry rate and flow-through volume for minimizing the time to get participants to their destinations (thus, E denotes the expectation operator). In other embodiments, variations in these mathematical relationships can be used to represent the physical constraints as desired. 
     The IARTD system  101  also applies incentive-compatibility constraints. It is to be understood that incentive-compatibility constraints are a major aspect missing from conventional command-and-control traffic management systems. Drivers will not agree to participate unless they believe they will reach their destination at least as quickly, and with as little disutility, as if they simply chose the departure time and route on their own, not accepting the system&#39;s recommendations. Participation is voluntary, but of course the IARTD system  101  will function more effectively if a larger fraction of the vehicles within the area under its management [a] have their cellphones turned on, offering location information, and [b] are following assignments  203  and real-time recommendations  205 . Therefore, on any one usage of the IARTD system  101  it is unwise to issue any assignment  203  or recommendation  205  which the driver would on average be better off not following. These incentive-compatibility constraints are even more important in situations where the IARTD system  101  will be used repeatedly by the same organization, which would typically be the case for most organizations, if not all. The rate of future driver participation will heavily be determined by effectiveness of the IARTD system  101  as perceived by the participants, both directly in terms of their future incentives to participate and follow recommendations, and indirectly in the impact the system  101  effectiveness will have on other potential participants, who learn of this information via social media, word of mouth, etc. 
     These incentive-compatibility constraints can be represented mathematically in the form, for each car c: E[t dc +u c  t sc |a,r]≤E[t dc +u t sc |a′, r′], ∀(a′, r′)≠(a, r), where ∀ is read “for all.” In words, this specifies that on average, the weighted sum of {time to destination+time stuck} is at least as low should the driver be following the system&#39;s recommendations as for any other feasible recommendations the driver might consider following, where the weighted sum uses that driver&#39;s tradeoff between t d  and is (u c  will be greater than 1 if the driver is more irked by an extra minute stuck than by an extra (moving) minute required to reach his destination, and greater for drivers with a stronger difference between these disutilities). Note that in this context, making a “feasible” recommendation merely rules out recommending paths that do not lead to the desired destination, or that involve driving behaviors prohibited by law, such as driving on the sidewalk or the wrong side of a road or expressway, proceeding through red lights, etc. 
     To initially express incentive compatibility constraints straightforwardly, the above inequality abstracts from two aspects. First, the IARTD system  101  does not know the true value of u c , which is a matter of personal preference which may not even be known precisely by the driver himself or herself (especially when passengers&#39; disutilities are taken into account). Thus, the IARTD system  101  will account for this by satisfying the constraint for driver c for all values of u c  within some reasonable interval U=[{hacek over (u)},û]. Adding this complication yields, for each car c: E[t dc +u c t sc |a,r]≤E[t dc +u t sc ]∀(a′, r′)≠(a, r), ∀u c  ∈U. Note that the specific parameters used for the interval are a variable design choice. Second, “on average” is a simplification unlikely to be acceptable to most organizations. Thus, organizations will be allowed to specify a threshold T, so that each participant finds the incentive constraint holding for him or her not just on average, but with probability at least T. To focus on this aspect, incentive compatibility constraints can be stated more simply by submersing the first aspect: Prob{[t dc +u c  t sc |a,r]≤[t dc +u t sc |a′, r′]}≥T,∀(a′,r′)≠(a, r). 
     It is possible that an organization choosing to have certain preferred customers given higher priority will wish to use a higher threshold T in the incentive-compatibility constraint relating to those customers than to “normal” customers. 
     Thus, by applying the functionality described above, the IARTD system  101  applies a set of rules  201  (basically mathematical relationships expressed by, for example, the prototypical algorithmic objective function described above) that improve computer-related traffic management technology by allowing the making of initial assignments  203  and real-time recommendations  205  to multiple parties responsible for operating and navigating (e.g., driving) vehicles (e.g., cars), so as to facilitate the real-time routing of traffic in a manner that incentivizes the individual operators to make decisions that maximize the utility for participants, according to inputs and prioritizations of an organization. This enables the computerized performance of a function not previously performable by a computer, specifically the automated provision of incentive-compatible, asymmetric-information, real-time traffic-routing differential-advice that takes into account incentive-compatibility constraints. In strict contrast to conventional command-and-control traffic management systems, the IARTD system  101  avoids issuing any assignment  203  or recommendation  205  to any driver which the driver would on average be better off not following (or, in some embodiments would be worse off following only with a specified low probability). 
     As an aid to understanding the operation of the IARTD system  101  according to several example embodiments, certain specific use cases are now described. It is to be understood that these are examples only, and other uses are both possible and contemplated. As noted above, one use case for the IARTD system  101  is managing traffic exiting from a fixed, physically constrained area such as the parking facilities of a specific stadium after the conclusion of a specific event, such as a college or professional football game. In this scenario, information for each participating driver such as the driver&#39;s parking spot, seats, and destination upon departure are obtained, for example via each driver&#39;s instance of the mobile device agent  109  (e.g., smartphone app). In some cases, some of this information is already known to the IARTD system  101  (e.g., the driver&#39;s seats, where the driver is a season ticket holder, or the driver&#39;s default destination, where the driver is a repeat participant). Information such as parking space can be gleaned automatically by the mobile device agent  109  (e.g., by GPS or other location identifying functionality on the driver&#39;s mobile device) and/or input by the driver. The exact information obtained for the drivers varies between use cases as desired. 
     The IARTD system  101  can send each driver an individualized text message, app alert or other electronic communication, suggesting a time for his/her group to leave their seats and head to the car. The IARTD system  101  can choose these times so that [a] the number of cars attempting exit at any given time is kept below bottleneck levels, and [b] the number of cars attempting to traverse any given path (e.g., arriving northbound, turning left through an immediate traffic-signal-controlled intersection, entering a given highway via a specific on-ramp, etc.) at any given time is kept below bottleneck levels. The IARTD system  101  can transmit to each driver an initial assignment  203  comprising an individualized initial recommended route to the corresponding destination. This initial recommendation is received by the mobile device agent  109  on the driver&#39;s mobile device. The device agent  109  uses the initial assignment  203  to provide navigation instructions to the driver (e.g., via graphical indicia on a map and/or audio output and/or by controlling or otherwise interfacing with the routing aspect of an automated driving system). The IARTD system  101  can update an initial recommendation  203  by transmitting real-time recommendations  205  to the driver&#39;s mobile device agent  109  as traffic conditions suggest better alternatives. The mobile device agent  109  then provides updated real-time instructions to the driver. In one embodiment, drivers not using a smartphone can be called, texted, or otherwise electronically contacted by the IARTD system  101  with computer-generated real-time recommendations  205  as to changes in recommended routes to individual destinations. 
     As noted above, another use case for the IARTD system  101  is hurricane (or other disaster) evacuations. In one embodiment, for a given metropolitan area in a hurricane zone, two types of data can be gathered ahead of hurricane season, and updated as necessary: [a] data on possible evacuation routes, including traffic density/average speed, bottleneck densities, and data on arrival sites and the capacities and resources to be present at each; and [b] voluntarily supplied data on households to be evacuated (e.g., work, school, and home addresses, and usual times at addresses, together with which cars are likely at which addresses when; resources required at an arrival site) and on first responders to be positioned (similar data). The IARTD system  101  can be run well before hurricane season for possible evacuation scenarios (e.g., workday, weekend, day, night), and re-optimized to be re-run when needed. 
     On the evening before a possible evacuation, the IARTD system  101  could send one designated member of each household a text message or other alert about recommended preparations (e.g., things to pack and put in car trunks). Working with federal, state and local emergency-preparedness teams, the operator of the IARTD system  101  could encourage provision of, say, an hour advance notice to the IARTD system  101  of any evacuation order that is to be broadcast. 
     The IARTD system  101  could (first priority) send individualized recommendations of times and routes for hospitals to be evacuated; then (second priority) for schools, for example. Routes for first responders could be projected to minimize interference from evacuees (both those participating in the use of the IARTD system  101  and those on their own), and could be individualized and sent in one format (e.g., text or other alert type) to non-moving first responders, and in another (e.g., audio alert or voice message) to responders on the move. Individual voluntary participants in evacuation could also be sent individualized messages as desired. For example, an initial communication to an evacuee could state: “We recommend that you stay where you are, keep calm, and leave for your car at such time as to be in your car 41 minutes from now. You will then be sent a recommendation between 41 and 43 minutes from now to start your car. The routing app on your smartphone will provide an initial recommended route to your arrival location. The app will automatically recommend re-routing whenever that can help avoid congestion. If you follow our recommendations, you will reach the same arrival location as the rest of your household, at least as soon and likely sooner than if you decide to go on your own.” 
     For rush-hour traffic management, studies and other empirical data concerning relevant routes, expressways and local roads, at different times and under different weather conditions, can be used to supply density/speed figures, and bottleneck densities for routes, exit and entry ramps, local-road traffic-light-controlled intersections, etc. 
     Potentially participating drivers provide their usual destinations for morning and afternoon commutes, together with needed morning arrival times, and earliest possible departure times. These usual destinations and times can be modified for a particular day, or indefinitely as a result of change in home or office location, for example via a user interface on the mobile device agent  109  or a web interface to the IARTD system  101 . Information concerning vacations, sick days, changes in schedule, etc., can also be supplied. Last-minute changes may receive lower priority. 
     Initial assignments  203  for morning departure times can be provided to the mobile device agents  109  of the participating drivers by the IARTD system  101  the night before, at an evening hour of the driver&#39;s choosing. In the morning, a driver could, for example, be given advance notice of a recommendation to depart M minutes earlier (e.g., 20 minutes), for example 3M minutes before the initially planned time (e.g., 60 minutes notice for 20 minutes earlier departure). The IARTD system  101  can tailor reminders of planned departure times to individual preferences (e.g., 10-minute warning only, also 5-minute warning, etc.). A recommendation  205  indicates to start now, with an initially assigned route  203 . The IARTD system  101  can then provide real-time recommendations  205  to account for route-changes based on updated conditions and the like. A driver starting late (or early) is automatically detected by the driver&#39;s mobile device agent  109 , which transmits this information to the IARTD system  101 , which can then adjust the recommendations  205  accordingly. Similarly, a driver who plans to leave work late on a given day is encouraged to provide an updated estimate. Unannounced late departures can be automatically detected, and the IARTD system  101  can adjust recommendations  205  accordingly. The IARTD system  101  also adjusts for the behavior of nonparticipating drivers, which can be discerned, for example, from speeds at which cell phones pass cell towers. 
       FIG. 3  is a block diagram of an example computer system  610  suitable for implementing an IARTD system  101 . Both clients  103  and servers  105  can be implemented in the form of such computer systems  610 . As illustrated, one component of the computer system  610  is a bus  612 . The bus  612  communicatively couples other components of the computer system  610 , such as at least one processor  614 , system memory  617  (e.g., random access memory (RAM), read-only memory (ROM), flash memory), an input/output (I/O) controller  618 , an audio output interface  622  communicatively coupled to an audio output device such as a speaker  620 , a display adapter  626  communicatively coupled to a video output device such as a display screen  624 , one or more interfaces such as Universal Serial Bus (USB) receptacles  628 , serial ports  630 , parallel ports (not illustrated), etc., a keyboard controller  633  communicatively coupled to a keyboard  632 , a storage interface  634  communicatively coupled to one or more hard disk(s)  644  (or other form(s) of storage media), a host bus adapter (HBA) interface card  635 A configured to connect with a Fibre Channel (FC) network  690 , an HBA interface card  635 B configured to connect to a SCSI bus  639 , an optical disk drive  640  configured to receive an optical disk  642 , a mouse  646  (or other pointing device) coupled to the bus  612 , e.g., via a USB receptacle  628 , a modem  647  coupled to bus  612 , e.g., via a serial port  630 , and one or more wired and/or wireless network interface(s)  648  coupled, e.g., directly to bus  612 . 
     Other components (not illustrated) may be connected in a similar manner (e.g., document scanners, digital cameras, printers, etc.). Conversely, all of the components illustrated in  FIG. 3  need not be present (e.g., smartphones and tablets typically do not have optical disk drives  640 , external keyboards  632  or external pointing devices  646 , although various external components can be coupled to mobile computing devices via, e.g., USB receptacles  628 ). The various components can be interconnected in different ways from that shown in  FIG. 3 . 
     The bus  612  allows data communication between the processor  614  and system memory  617 , which, as noted above may include ROM and/or flash memory as well as RAM. The RAM is typically the main memory into which the operating system  650  and application programs are loaded. The ROM and/or flash memory can contain, among other code, the Basic Input-Output system (BIOS) which controls certain basic hardware operations. Application programs can be stored on a local computer readable medium (e.g., hard disk  644 , optical disk  642 ) and loaded into system memory  617  and executed by the processor  614 . Application programs can also be loaded into system memory  617  from a remote location (i.e., a remotely located computer system  610 ), for example via the network interface  648  or modem  647 . In  FIG. 3 , the IARTD system  101  is illustrated as residing in system memory  617 . 
     The storage interface  634  is coupled to one or more hard disks  644  (and/or other standard storage media). The hard disk(s)  644  may be a part of computer system  610 , or may be physically separate and accessed through other interface systems. 
     The network interface  648  and/or modem  647  can be directly or indirectly communicatively coupled to a network  107  such as the internet. Such coupling can be wired or wireless. 
     As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies, data structures and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or limiting to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain relevant principles and their practical applications, to thereby enable others skilled in the art to best utilize various embodiments with or without various modifications as may be suited to the particular use contemplated.