the following is an explanation of an example of the present invention with reference to the drawings . the same reference numbers are used to denote the same objects in all of the drawings except where otherwise indicated . the following explanation is of an embodiment of the present invention , and the present invention is by no means intended to be limited to the content explained in the example . fig4 is a block diagram of computer hardware used to realize the system configuration and processing in an example of the present invention . in fig1 , a cpu 404 , main memory ( ram ) 406 , a hard disk drive ( hdd ) 408 , a keyboard 410 , a mouse 412 , and a display 414 are connected to a system bus 402 . the cpu 404 is preferably based on 32 - bit or 64 - bit architecture , and can be a pentium ® 4 , core ® 2 duo or xeon ® from intel corporation , or an athlon ® from advanced micro devices , inc . the main memory 406 preferably has a capacity of 4 gb or more . the hard disk drive 408 preferably has a capacity of 500 gb or more in order to store a large amount of data . main memory 406 and hard disk drive 408 are examples of computer readable storage mediums . computer readable storage mediums are hardware capable of storing information such as data , computer readable instructions , program code in functional form , and / or other suitable information on a temporary basis and / or permanent basis . a preferred example of such a hardware configuration is the ibm ® system x series . however , the present invention is not limited to this . it can even be embodied in a personal computer . while not shown in any of the drawings , the hard disk drive 408 includes a pre - installed operating system . the operating system can be any operating system compatible with the cpu 404 . examples include linux ®, windows xp ®, windows 2000 ®, and windows 2008 server ® from microsoft corporation , or mac os ® from apple , inc . the hard disk drive 408 stores the main routine 502 , traffic route graph data 504 , request data 506 , solver 508 , route searching module 510 , and route updating module 512 described below . the main routine 502 , solver 508 , route searching module 510 , and route updating module 512 are created in an existing programming language such as c , c ++, c # or java ™, and are loaded into the memory 406 at system startup and by the action of the operating system , if necessary . the display 414 is preferably a liquid crystal display . any resolution can be used , including xga ( resolution : 1024 × 768 ) or uxga ( resolution : 1600 × 1200 ). while not shown in the drawings , the display 414 is used to display operating screens for starting and stopping the processing program of the present invention , and for displaying traffic route data . the following is an explanation of the logic function structure used to embody the present invention with reference to the function block diagram of fig5 . in fig5 , the main routine 502 is the program that manages the overall process , displays operating screens ( not shown ) on the display 414 , and starts and stops the process in response to user operations entered using the keyboard 410 and mouse 412 . the traffic graph data 504 is weighted graph data in which routes are described in graph form with roads expressed as edges and intersections as nodes , and in which the weight of each road is approximated by a monotonically increased piecewise linear function to model the occurrence of congestion due to an increase in traffic volume . the graph is typically expressed as a matrix or list to make it computer readable and storable in media such as a hard disk . however , the graph can assume any form able to achieve the object of the present invention . fig6 is a diagram showing the piecewise linearity of the edges and required times . here , x is traffic volume expressed in the number of vehicles transiting per hour . this is a piecewise linear approximation of the graph shown in fig1 . as shown in the drawing , the piecewise linear functions used are required time t = a 1 x + b 1 where 0 ≦ x & lt ; x 1 , required time t = a 2 x + b 2 where x 1 ≦ x & lt ; x 2 , and required time t = a 3 x + b 3 where x 2 ≦ x , where a i & gt ; 0 ( i = 1 , 2 , 3 ). here , only three zones are shown , but this is merely an embodiment . if necessary , zones of any number and width can be used . the piecewise linear functions are not limited to this . for example , it can be implemented as a linear function indicated from each edge and referencing a table in memory . in other words , a table is prepared so that { a 1 , b 1 } is returned in response to a value for traffic volume of ≦ x 1 , and { a 2 , b 2 } is returned in response to a value for traffic volume of x 1 ≦ x & lt ; x 2 , etc . the coefficient groups such as { a 1 , b 1 }, { a 2 , b 2 } for performing piecewise linear approximation of each edge are determined according to the actual condition of the road . in other words , a coefficient such as { a i , b i } ( i = 1 , 2 , 3 , etc .) is preferably determined in proportion to the actual length of the edge . however , { a i , b i } is made larger for a road going uphill , and { a i , b i } is made smaller for a road going downhill . also , { a i , b i } is made larger for a road with a large curve , { a i , b i } is made smaller for a road with many lanes , and { a i , b i } is made larger for a narrow road . in addition , { a i , b i } is made smaller for a road with good pavement , and { a i , b i } is made larger for a road with no pavement . in a preferred example , the required time for each edge is t = max i { a i x + b i }. here , a i & gt ; 0 . the request data 506 is provided as a set of { departure point , destination point , demand level }. this request data can be collected , for example , using probe car data . traffic data collection techniques using probe car data are common in the art . for examples , see japanese patent publication no . 2004 - 110458 , japanese patent publication no . 2004 - 156982 , japanese patent publication no . 2007 - 193705 , and japanese patent publication no . 2004 - 241987 . because the number of vehicles traveling between each { departure point , destination point } pair is known over a given period of time , these techniques can be used prepare request data 506 so that the number of vehicles is set as the level of demand , the { departure point , destination point , demand level } sets are sorted in descending order by level of demand , and a predetermined number of pairs is saved from the top to a hard disk drive 408 . the solver 508 uses as the objective function a minimized maximum value of all values obtained by dividing the actual required time for all requests by the shortest required time , and solves a mixed integer programming ( mip ) problem , providing as output to each request a plurality of routes and their utilization ratio ( real number ). there are no restrictions on the solver , but a preferred example is ibm ® ilog cplex . the mip formulation is explained below in greater detail . the route searching module 510 performs a weighted graph route search using any well - known algorithm such as dijkstra &# 39 ; s algorithm or an a * search technique . the algorithm can also be a revised a * search technique described in japanese patent publication no . 2008 - 157698 . the route updating module 512 arbitrarily eliminates routes in order to reduce the amount of computation or adds useful routes . the process executed by the route updating module 512 is explained in greater detail below with reference to the flowchart in fig8 . the following is an explanation of the route selecting process of the present invention with reference to the flowchart in fig7 and fig8 . in step 702 of fig7 , the main routine 502 calls up the route searching module 510 , and searches for the lowest cost route , or shortest route , from a departure point to a destination point for the { departure point , destination point } pair in request data 506 where x = 0 is placed in the formula for t = max i { a i x + b i }. in step 704 , the main routine 502 calls up the solver 508 , and solves a mixed integer programming ( mip ) problem with the candidate routes at the present time . in the loop consisting of step 704 , step 706 and step 708 , the calculation time can be reduced by using the previous solution as the initial value in the second and subsequent iterations . the following is an explanation of the mip formulation . the formulation is intended to use an objective function in which the maximum value of all values obtained by dividing the actual required time for all requests by the shortest required time is minimized . this is expressed as graph g =( v , e ), where v is the set of nodes and e is the set of edges in the traffic graph data 504 . referencing the piecewise linear approximation in fig6 , the traveling time for moving along edge e e is expressed by the following equation , where the volume of traffic is x . t e ( x )= max i ( a ei x b ei ) also , let p i * be the set of all routes not including the cycle from node s i to node g i . then , p p i * is expressed as a permutation of the connecting edge . p =( e i · e 2 . . . , e | p | ) therefore , let t i * be the minimum required time from node s i to node g i when traffic volume x is 0 . in other words , t i * is expressed by the following equation . at this time , let the cost of each edge e e be t e ( 0 ), and ti * can be determined , for example , by calling up the route searching module 510 and executing the shortest route search algorithm , even though all of the elements of pi * are not explicitly enumerated . also , sequential numbers are given to the elements of candidate route set p i * for request i , and the jth route of p i * ( j = 1 , . . . , | p i *|) is expressed by p i . in addition , l is a sufficiently large positive constant , and y ij is an integer variable , which takes 0 or 1 expressing whether or not candidate route j for request i is used . these definitions are used to formulate a mixed integer programming problem in the following manner . ⁢ ly ij + ∑ e ∈ p ij ⁢ t e ⁡ ( x e ) ≤ λ ⁢ ⁢ t i * + l ⁢ ⁢ for ⁢ ⁢ i = 1 , … ⁢ , k , ⁢ j = 1 , … ⁢ ,  p i *  ⁢ ⁢ x e = ∑ ( i , j ) = { i , j | e ∈ p ij } ⁢ x ij ⁢ ⁢ for ⁢ ⁢ e ∈ e ⁢ ⁢ ∑ j ⁢ x ij = d i ⁢ ⁢ for ⁢ ⁢ i = 1 , … ⁢ , k ⁢ ⁢ x ij ≤ d i ⁢ y ij ⁢ ⁢ for ⁢ ⁢ i = 1 , … ⁢ , k , j = 1 , … ⁢ ,  p i *  ⁢ ⁢ x ij ≥ 0 , x ij ∈ r ⁢ ⁢ for ⁢ ⁢ i = 1 , … ⁢ , k , j = 1 , … ⁢ ,  p i *  ⁢ ⁢ y ij ∈ { 0 , 1 } ⁢ ⁢ for ⁢ ⁢ i = 1 , … ⁢ , k , j = 1 , … ⁢ ,  p i *  , equation ⁢ ⁢ 2 thus , x ij resulting from the solution of the mixed integer programming problem expresses the traffic volume of the jth route in request i . in other words , x ij / d i is the utilization ratio of the jth route in request i . this utilization ratio is expressed in fig9 as a percentage associated with each of a plurality of routes from the departure point 1 to the destination point 1 . next , in step 706 , the main routine 502 determines whether or not the termination conditions have been satisfied . the termination conditions have been satisfied , for example , when the calculation time exceeds a time set in advance , or the number of iterations has exceeded a predetermined number . when the main routine 502 has determined that the termination conditions have been satisfied , the process is terminated . at this time , a plurality of routes from the departure point to the destination point of each request , and the utilization ratio of each route are obtained . when the main routine 502 in step 706 determines that the termination conditions have not been satisfied , the process proceeds to step 708 , where the main routine 502 calls up the route updating module 512 and updates the candidate routes . the candidate routes are updated by deleting unused routes and unpromising routes , and adding promising routes . this process is explained below in greater detail with reference to the flowchart in fig8 . after the candidate routes have been updated in step 708 , the mip is again solved by the solver 508 in step 704 based on the updated candidate routes . the following is an explanation of the processing performed in the route updating module 512 with reference to the flowchart in fig8 . in other words , in step 802 , the route updating module 512 eliminates the following routes in each request as unpromising routes . those routes whose lowest cost is equal to or greater than the cost of current best solution . here , the lowest cost is the cost when traffic volume x = 0 . those routes that was added in the previous iteration , but not used . an unused route is determined in the calculation results of the solver 508 in step 704 by a value of 0 for variable y ij . an explosion in the number of candidate routes is suppressed by eliminating these routes . in step 804 , the route updating module 512 sets those requests whose “ actual required time / shortest required time ” is maximum and “ actual required time ” for all the candidates is same to bottleneckrequest &# 39 ; s , and sets those edges included in the candidate route to bottleneckedge &# 39 ; s . in other words , the route updating module 512 identifies bottleneck requests and bottleneckedge sets in the results of each iteration . those requests that determine the object function value are defined as bottleneckrequest &# 39 ; s , and those edges included in candidate routes of the request are defined as bottleneckedge &# 39 ; s . in step 806 , the route updating module 512 searches for routes in each bottleneckrequest whose cost is less than the current best solution which satisfy the following conditions . with the current cost , those routes that do not use bottleneckedge &# 39 ; s will be searched . if not found , with the current cost , those routes that may use bottleneckedge &# 39 ; s will be searched . any route found in this manner is added . in other words , routes which lower the objective function value when added , or routes with a high probability of lowering the objective function value can be efficiently added . in step 808 , the route updating module 512 determines whether or not a candidate route was found in step 806 . if found , returning from the subroutine shown in fig8 , the process goes back to step 704 in fig7 . when the route updating module 512 determines in step 808 that a candidate route was not found , the route updating module 512 in step 810 searches for a route satisfying the following conditions if there is no route concerning each non - bottleneckedge which worsens the solution at the time and increases the flow , that is , traffic volume . with the current cost , those routes that do use bottleneckedge &# 39 ; s will be searched . if not found , those route that may use bottleneckedge &# 39 ; s will be searched . if a route is found , it is added . returning from the subroutine shown in fig8 , the process goes back to step 704 in fig7 . the reason why the process in step 810 is performed is that even those requests that are not bottleneck may improve the objective function value by adding candidate routes . at this time , for those requests that have the candidate routes satisfying the following conditions , the objective function value cannot be improved no matter which route is added for such the requests . none of the edges of the candidate route is a bottleneckedge and the route itself is not a route to determine the current objective function value . these conditions assume the cost function of the edge is a cost function that strictly increases monotonically . in other words , for the required time function of the “ ax + b ”, “ a & gt ; 0 ” should be used instead of “ a 0 ”. returning to the flowchart in fig7 , when the mip has been calculated in step 704 and it has been determined in step 706 that the termination conditions have been satisfied , a plurality of routes is returned for each request , and a utilization ratio is returned for each route . when the desired routes between many - to - many departure points and destination points and the utilization ratios of the desired routes have been obtained in this manner , those can be applied to the routing of traffic in order to alleviate steady or permanent congestion , such as during rush hour , and regular congestion around certain facilities . it can also be applied to crowd control in order to plan efficient routes for crowd movement at event venues , and to plan effective evacuation routes in case of fire . the present invention was explained with reference to a particular embodiment , and one type of hardware configuration was illustrated . however , the present invention can also be used in any other hardware environment , such as a multiprocessor environment or a network - connected crown computing environment .