座席位置ごとおよび立ち位置ごとに配置された人感センサと、これらの人感センサの検出結果を無線送信する送信部とを車両ごとに備える電車と、前記検出結果を混雑状況予測サーバに伝送する閉域通信網と、データベースに、電車IDを記録する電車テーブルと、車両IDを記録する車両テーブルと、停車駅を記録する駅テーブルと、位置IDを記録する停車位置テーブルと、曜日ごと時間帯ごとの乗車率を記録する混雑状況テーブルと、を保持し、端末からアクセスを受け付けたとき、検索画面を前記端末に送信し、前記端末から、混雑状況取得依頼を受け付けたとき、前記データベースに基づいた駅ごと車両ごとの混雑情報を前記端末に送信する前記混雑状況予測サーバと、を含む車両混雑状況予測システム。請求項1に記載の車両混雑状況予測システムであって、前記混雑状況取得依頼に空席検索指示が含まれているとき、前記前記混雑状況予測サーバは、乗車駅から座れると判定した電車について、駅ごと車両ごとの混雑情報を前記端末に送信することを特徴とする車両混雑状況予測システム。請求項1に記載の車両混雑状況予測システムであって、さらに、前記混雑状況予測サーバにトラブル情報を送信する管理端末を含み、前記混雑状況予測サーバは、前記管理端末からトラブル情報を受信したとき、かつ前記端末からアクセスを受け付けたとき、トラブルを通知する検索画面を前記端末に送信することを特徴とする車両混雑状況予測システム。請求項3に記載の車両混雑状況予測システムであって、前記混雑状況予測サーバは、前記端末から、混雑状況取得依頼を受け付けたとき、前記トラブル情報を加味した駅ごと車両ごとの混雑情報を前記端末に送信することを特徴とする車両混雑状況予測システム。しかし、特許文献1のシステムでは、直近数日間の混雑状況の推移や乗車降車情報に基づいた混雑状況を平均化予測している。車両トラブルによる運行ダイヤの乱れや他線他社の運行状況、または駅周辺のイベント開催により混雑状況は異なる。数日間の混雑状況を平均化するだけでは、特異的な混雑状況も平均化されてしまい、実態と混雑状況が異なるケースが考えられる。本発明は、上記の点に鑑みなされたもので、所望する車両の混雑状況と降車駅までの混雑推移情報を混雑事由毎に考慮した混雑推移情報を通知して、ユーザに対して乗車位置を決定させる為の判断材料を提供する。本発明を達成する為に、車両混雑状況予測システムは、現在の混雑状況や混雑推移情報を示すデータベースを元にして混雑推移情報を更新する機能を有している。また、特異的な混雑事由毎の混雑率を算出する。車両混雑状況予測システムは、現在の車両毎の混雑状況を検知して混雑状況処理サーバに転送する。車両混雑状況予測システムは、現在の混雑状況や特異的な混雑事由など混雑推移状況を特定するために必要な情報を混雑状況処理サーバに転送する。車両混雑状況予測システムは、混雑推移情報を保持するデータベースや運行ダイヤを保持しているデータベースを有している。車両混雑状況予測システムは、ユーザからの混雑情報要求を取得する、また、当該要求に対して乗車率情報や各車両の停車位置をユーザの携帯端末に表示する。上述した課題は、座席位置ごとおよび立ち位置ごとに配置された人感センサと、これらの人感センサの検出結果を無線送信する送信部とを車両ごとに備える電車と、検出結果を混雑状況予測サーバに伝送する閉域通信網と、データベースに、電車IDを記録する電車テーブルと、車両IDを記録する車両テーブルと、停車駅を記録する駅テーブルと、位置IDを記録する停車位置テーブルと、曜日ごと時間帯ごとの乗車率を記録する混雑状況テーブルと、を保持し、端末からアクセスを受け付けたとき、検索画面を端末に送信し、端末から、混雑状況取得依頼を受け付けたとき、データベースに基づいた駅ごと車両ごとの混雑情報を端末に送信する混雑状況予測サーバと、を含む車両混雑状況予測システムにより、達成できる。本発明によれば、日々の通常運行による統計情報だけでなく、運行ダイヤ乱れなどの特異的な事象に対しても車両の混雑状況を予測する事ができる。ユーザは最適な乗車位置、乗車時間の調整、または最適な路線ルートを決定する事ができる。また、ユーザの混雑によるストレス低減や車両混雑の平均化を期待する事ができる。以下、本発明の実施の形態について、実施例を用い図面を参照しながら詳細に説明する。なお、実質同一部位には同じ参照番号を振り、説明は繰り返さない。まず、図1ないし図8を参照して、通常運転時の車両混雑状況予測システムを説明する。図1を参照して、車両混雑状況予測システムの構成を説明する。図1において、車両混雑状況予測システム100は、路線1と、電車20と、駅10と、混雑状況予測サーバ50と、携帯端末60と、公衆網40と、閉域通信網30と、システム管理端末90とから構成される。路線1を運行する電車20には、車両毎に混雑状況を検知するセンサを設置している。センサは、駅10を出発してから一定期間モニタリングした車両毎の混雑情報を、閉域通信網30-Aを介して混雑状況処理サーバ50に転送する。すなわち、電車20は、通信システムを設置している。混雑状況予測サーバ50は、電車20の車両毎の混雑情報を、閉域通信網30-Aを介して取得する。混雑状況予測サーバ50は、ユーザからの混雑情報要求を、公衆網40を介してユーザ携帯端末60から受信する。また、混雑状況予測サーバ50は、ユーザからの混雑情報要求に対する検索結果を、公衆網40を介してユーザ携帯端末60に送信する。携帯端末60は、電車混雑状況要求を、公衆網40を介して混雑状況予測サーバ50に送信する。また、電車混雑情報要求に対する検索結果について、携帯端末60は、公衆網40を介して混雑状況予測サーバ50から受信する。システム管理端末90は、システム管理者がシステム監視情報を入手したり、また、システムの設定変更の指示要求をするために、閉域通信網30-Bを介して混雑状況予測サーバ50とデータの送受信をする。公衆網40は、インターネット、加入電話網、携帯電話網のいずれかである。閉域通信網30は、利用者専用の通信網または一般の公衆網の一部を専用利用する閉域通信網である。図2を参照して、車両混雑状況モニタを説明する。図2aにおいて、電車20の車両毎に人感センサ201を設置して混雑状況をモニタリングする。モニタリングして取得した車両混雑情報70を、図示しない無線送信部は、無線通信で混雑状況予測サーバ50に転送する。図2bにおいて、モニタリングは、車両内のセンサ感知エリア202の複数ポイントに分割して、駅を出発してから一定期間モニタリングする。車両内の乗車率は、センサ感知エリア202の分割ポイント203に対して人感検出ポイント204の割合で算出する事ができる。乗車率=人感検出ポイントの合計数/センサ感知エリアの分割ポイントの合計数×200である。ここで、乗車率は、0:乗車無し<100:空席無し<200:乗車率Maxである。なお、モニタリングの回数や周期を変更する事により、車両内の混雑情報の精度を調整する事ができる。具体的には、混雑状況を検知する人感センサ201と混雑状況処理サーバ50に転送する通信システムを組み合わせて一体型の装置を作製する。電車20の各車両の天井のセンター部に装置を設置する。装置は、車両内のセンサ感知エリア202をモニタリングして、検知した車両混雑情報70を無線で混雑状況予測サーバ50に転送する。人感センサ201は、車両毎の混雑情報を取得する為のセンサであり、混雑情報を取得するセンサ、設置台数、設置箇所は限定されるものではない。図3を参照して、混雑状況予測サーバの構成と、入出力データを説明する。図3において、混雑状況予測サーバ50は、制御部301と、演算部302と、表示部303と、入出力部304と、認証部305と、課金部306と、混雑予測処理DB80と、障害時混雑予測処理BD81と、自社運行ダイヤDB82と、他社運行ダイヤDB83とから構成される。なお、制御部301と、演算部302と、認証部305と、課金部306とは、図示しないCPUが図示しないメモリ上のプログラムを実行することにより、実現する。混雑状況予測サーバ50は、閉域通信網30-Aと接続され、イベント情報73、運行ダイヤ情報72、トラブル災害情報71、車両混雑情報70を受信する。混雑状況予測サーバ50は、公衆通信網40と接続され、端末アクセス情報74を送受信する。制御部301は、演算部302、表示部303、入出力部304、認証部305、課金部306の各機能を管理する。また、制御部301は、各機能間の連携を指示する。演算部302は、制御部301からの指示によりユーザからの混雑情報要求74に対する混雑率の算出や電車の運行状況車両混雑情報70~イベント情報73に応じた混雑率の更新を実行する。また、演算部302は、混雑予測処理DB80、障害時混雑予測処理DB81、自社運行ダイヤDB82、他社運行ダイヤDB83と連携する。表示部303は、ユーザからの混雑情報要求74に対して検索入力画面や検索結果画面をユーザの携帯端末60に表示する。入出力部304は、ネットワーク30を介して車両の運行状況に関連するトラブル災害情報71、車両混雑情報70、運行ダイヤ情報223、イベント情報73の入力を受け付ける。また、入出力部304は、ネットワーク40を介してユーザからの混雑情報要求74に対するデータの受け付け、および出力する。認証部305は、ユーザの認証可否を行なう。ユーザ認証の方法としては、ユーザを識別する識別子とパスワードを利用する方法や携帯電話の個体の識別子とパスワードを利用する方法が考えられる。課金部306は、ユーザに提供したサービスに対しての課金を行なう。なお、課金内容は、通信を行なった際の転送データ量に基づく従量課金、月極めの一定課金などが考えられる。図4を参照して、混雑予測処理データベースDBを説明する。図4において、混雑予測処理データベース80は、電車テーブル401と、車両テーブル402と、駅テーブル403と、停車位置テーブル404と、曜日テーブル405と、混雑状況テーブル406とから構成されている。電車テーブル401は、電車IDから構成されている。車両テーブル402は、電車IDごとの車両IDから構成されている。駅テーブル403は、電車IDごとの停車駅IDから構成されている。停車位置テーブル404は、車両IDごとの位置IDから構成されている。曜日テーブル405は、車両IDごとの曜日から構成されている。混雑状況テーブル406は、車両IDごと曜日ごと時間ごとの乗車率から構成されている。混雑予測処理データベース80は、各要素を階層的に関連付けられている。混雑予測処理データベース80により、車両毎の各時間帯の乗車率を取得することができる。具体的には、電車IDA→車両ID1→停車駅IDA駅→停車位置ID1→月曜日→時刻6:30の乗車率は、50である。図5を参照して、端末表示画面検索入力画面を説明する。図5は、ユーザ携帯端末60にユーザの混雑情報要求を入力する為の検索入力画面501である。ユーザ端末60は、乗車日時と、乗車時間と、乗車駅と、降車駅と、Optionの空席検索モードへのチェックとを、検索ボタンの押下により受け付け、混雑状況予測サーバ50に送信する。なお、端末画面には現状の運行状況アナウンスを表示させて情報サービスを提供することができる。また、Optionの空席検索モードへのチェックがある場合、混雑状況予測サーバ50は、OptionモードFlagに1を設定する。図6を参照して、通常時の混雑状況検索シーケンスを説明する。図6において、電車20-Aは、n駅出発後の車両ごとの乗車率をセンサで検出するS601。電車20-Aは、混雑予測処理サーバ50に乗車率を送信するS602。混雑予測処理サーバ50は、混雑予測処理DBを更新するS603。ここで、携帯端末60-Aは、混雑予測処理サーバ50にアクセスするS604。混雑予測処理サーバ50は、携帯端末60-Aに応答を返すS606。なお、この応答には、図5の応答画面が含まれている。携帯端末60-Aは、検索内容を受け付けるS607。携帯端末60-Aは、混雑予測処理サーバ50に混雑状況取得依頼を送信するS608。混雑予測処理サーバ50は、運行ダイヤを検索するS609。混雑予測処理サーバ50は、乗車駅での混雑状況検索処理を実行するS610。混雑予測処理サーバ50は、降車駅での混雑状況検索処理を実行するS611。混雑予測処理サーバ50は、応答内容を作成するS612。混雑予測処理サーバ50は、携帯端末60-Aに混雑状況結果を送信するS613。携帯端末60-Aは、画面に表示してS614、終了する。なお、ステップ608でOption空席検索モードが指定されていとき、混雑予測処理サーバ50は、OptionモードFlag=1に設定する。混雑予測処理サーバ50は、ユーザが指示した電車の運行ダイヤを検索して、乗車駅での混雑状況を検索処理して、乗車率>100の車両である場合には、後続の電車を選択して再検索を実施する。図7を参照して、混雑予測処理サーバ50の混雑率更新フローを説明する。混雑予測処理サーバ50は、混雑率を更新する際、次の変数情報a、b、xを取得するS701。なお、混雑基準テーブルは、表1に示すようにランク1~8の各段階に対して乗車率10~200を定義する。表1混雑基準テーブル------------X乗車率------------1102303504805100612071508200------------ここで、a=混雑情報テーブルの乗車率混雑予測処理DB80、b=最新の混雑情報車両混雑情報70、x=混雑基準テーブルにおけるaのランクである。混雑予測処理サーバ50は、データベース上の乗車率aと最新の乗車率bの平均値cを演算するS702。混雑予測処理サーバ50は、c<aかつx=1またはc>aかつx=8か判定するS703。NOかつc≦aのとき、混雑予測処理サーバ50は、c<混雑基準テーブル[x-1]か判定するS704。YESのとき、混雑予測処理サーバ50は、混雑情報テーブルの乗車率に混雑基準テーブル[x-1]を設定するS705。ステップ703でYESのとき、ステップ704でNOのとき、または後述するステップ707でNOのとき、混雑予測処理サーバ50は、混雑情報テーブルの乗車率に混雑基準テーブル[x]を設定するS706。すなわち、混雑率の更新は発生させない。ステップ703でNOかつc>aのとき、混雑予測処理サーバ50は、c>混雑基準テーブル[x1]か判定するS707。YESのとき、混雑予測処理サーバ50は、混雑情報テーブルの乗車率に混雑基準テーブル[x1]を設定するS708。上述したフローにより、混雑率については、混雑基準テーブルを細分化することにより、日々の乗車率の変動を敏感に反映することができる。図8を参照して、携帯端末の検索結果画面を説明する。図8において、携帯電話60-Aの検索結果画面801には、当該電車の車両それぞれに対する各駅出発後の乗車率を表示する。検索結果画面801には、駅での停車位置番号が記載されている為、ユーザはどこの乗車位置で電車を待てば、座席を確保できるのかを判断する材料が得られる。具体的には、電車A20の車両番号5にA駅で乗車した場合、A駅では空席がなく座席を確保できなかったとしても、次駅のB駅では乗車率が80と予測される為、B駅で座席を確保できる可能性があることが分かる。ユーザが駅10-Aで電車20-Aを待っている際、電車20-Aの各車両の混雑情報を入手するために、携帯端末60-Aから混雑状況処理サーバ50に問い合わせる。ユーザがネットワーク公衆網40を介して混雑状況予測サーバ50にアクセスした場合、まずは車両混雑状況予測システムのサービスを提供できるユーザであるのか混雑状況処理サーバ50の認証部305で確認される。ユーザ認証が可と判断された場合には、課金部306でユーザに対してのサービス提供の課金情報の管理が開始される。ユーザ認証する際のIDパスワード入力やユーザが電車の混雑情報を問い合わせる際の乗車時間乗車駅などの入力を促す為、入出力部304は表示部303と連携して、ユーザに対して適切な入力画面を提供する。ユーザは、携帯端末60-Aの検索入力画面501を利用して、乗車日時乗車時間乗車駅降車駅の入力、またOption空席検索モードをONにして検索ボタンを押すことにより、当該条件での混雑情報を要求する。なお、JRや私鉄で現在運行中の電車20-Aでは、車両毎に設置されている人感センサ201で検出した車両混雑情報70を、随時、混雑状況処理サーバ50に転送している。混雑状況予測サーバ50で受け付けられた車両混雑情報70を元にして、制御部301からの指示により図4で示す混雑予測処理DB80の情報は、図7で示す混雑率更新フローチャートに沿って更新される。現時点での電車20-Aの混雑情報が管理される他、今後の混雑状況についても予測処理されるデータが作成されている。混雑状況予測サーバ50は、ユーザからの電車の混雑情報の問い合わせに対して、混雑予測処理DB80の情報を演算部302で適切な処理を実施した後に、表示部303で問い合わせ内容の応答例を作成する事ができる。混雑状況処理サーバ50は、ユーザからの問い合わせに対して、ユーザが乗車する駅10-Aでの電車20-Aの最新の混雑状況、および降車するまでの途中の駅10-B、駅10-Cでの予測混雑情報を、携帯端末60-Aに検索結果画面801で示すことができる。ユーザは、この車両混雑状況予測システムのサービスを受ける事により、電車20-Aまたは電車20-Bなどの次発以降の電車に乗車すべきかを判断する事ができる。ユーザが車両混雑状況予測システムのサービスの終了を判断した場合には、課金部306での管理も終了させる。図9ないし図14を参照して、車両混雑状況予測システムのトラブル対処を説明する。まず、図9を参照して、車両混雑状況予測システムのトラブル対処を説明する。図9は、基本的に図1と同様である。図9において、システム管理者がシステム管理端末90を用いて、他路線で運行ダイヤ乱れが発生した場合、人身事故が発生した場合など、トラブル_Flag=1を混雑処理サーバ50に通知することでトラブル対処システムが適用される。図10を参照して、障害タイプ分類表を説明する。図10において、障害タイプ分類表1001は、種別記号と、タイプとから構成されている。種別記号は、a~zのアルファベット小文字である。タイプは、障害のタイプである。具体的には、種別記号aは、自社路線トラブルaである。電車20-A~20-Cまたは路線1-A~1-Cでトラブルが発生した時、該当の障害タイプによって混雑区間や混雑時間など車両内の混雑状況はさまざまである。障害タイプを詳細に分類する事でユーザに正確な混雑情報を提供することができる。トラブル_Type=種別記号にすることで、トラブル対処システムに当該の障害タイプでの処理方法が適用される。障害タイプとしては以下が考えられる。自社路線で人身事故を事由とした運行トラブルが発生した場合自社路線で車両トラブルを事由として運行トラブルが発生した場合スポーツ試合を事由として車両内混雑が発生した場合降雪を事由として運行ダイヤに影響が発生した場合トラブルが発生した時の車両内混雑の予測値は、通常運行時の乗車率に対して該当の障害タイプの掛け値を掛け合わせることにより算出する。掛け値は、式1で算出する。α=β/θ...式1ここで、α:最新の掛け値、β:過去X回の平均乗車率、θ:混雑状況テーブルの乗車率である。また、β=β1β2...βx/X...式2である。掛け値は、当該の障害タイプの過去X回の平均乗車率を通常運行時の乗車率で割ることにより算出する。過去X回の平均乗車率は、過去の参照データが多いほど精度を上げることができる。図11を参照して、障害時混雑予測処理データベースDBを説明する。図11において、障害時混雑予測処理データベース81は、電車テーブル1101と、車両テーブル1102と、駅テーブル1103と、停車位置テーブル1104と、曜日テーブル1105と、混雑状況テーブル1106とから構成されている。電車テーブル1101は、電車IDから構成されている。車両テーブル1102は、電車IDごとの車両IDから構成されている。駅テーブル1103は、電車IDごとの停車駅IDから構成されている。停車位置テーブル1104は、車両IDごとの位置IDから構成されている。曜日テーブル1105は、車両IDごとの月~日曜日から構成されている。混雑状況テーブル1106は、曜日ごと時間ごと障害タイプごとの掛け値から構成されている。障害時混雑予測処理データベース81は、各要素を階層的に関連付けする事により、各車両の各時間帯の障害タイプの掛け値を取得することができる。具体的には、電車IDA→車両ID1→停車駅A→停車位置1→月曜日→時刻23時台の自社路線トラブルaaを事由とした掛け値は12である。図12を参照して、端末表示画面検索入力画面を説明する。図12は、車両混雑状況予測システムが提供するユーザ携帯端末60にユーザの混雑情報要求を入力する検索入力画面である。図12において、ユーザ端末60は、乗車日時と、乗車時間と、乗車駅と、降車駅と、Optionの空席検索モードへのチェックとを、検索ボタンの押下により受け付け、混雑状況予測サーバ50に送信する。なお、端末画面にはA駅でAM6:50に人身事故が発生していることをアナウンスして現状の運行状況を提示する。また、Optionの空席検索モードへのチェックがある場合、混雑状況予測サーバ50は、OptionモードFlagに1を設定する。図13を参照して、トラブル発生時の混雑状況検索シーケンスを説明する。図13Aにおいて、システム管理端末90-Aは、トラブル情報を受け付けるS621。システム管理端末90-Aは、混雑予測処理サーバ50にトラブル_Flag=1、トラブル_Type=xのトラブル発生通知を送信するS622。電車20-Aは、[n]駅出発後の各車両の乗車率を検出するS623。電車20-Aは、混雑予測処理サーバ50に乗車率を無線伝達するS624。混雑予測処理サーバ50は、混雑処理用DB80を更新するS626。混雑予測処理サーバ50は、障害時混雑処理用DB81を更新するS627。ここで、携帯端末60-Aは、混雑予測処理サーバ50にアクセスするS628。混雑予測処理サーバ50は、携帯端末60-Aにトラブル情報を含む応答を送信するS629。携帯端末60-Aは、検索内容を受け付けるS631。携帯端末60-Aは、混雑予測処理サーバ50に混雑状況取得依頼を送信するS632。なお、混雑状況取得依頼には、乗車時刻、乗車駅混雑、Option等を含む。予測処理サーバ50は、運行ダイヤを検索するS633。図13Bにおいて、混雑予測処理サーバ50は、トラブル時の乗車駅での混雑状況を検索するS634。混雑予測処理サーバ50は、降車駅までの混雑状況を検索するS636。混雑予測処理サーバ50は、応答内容を作成するS637。混雑予測処理サーバ50は、携帯端末60-Aに混雑状況応答結果を送信するS638。携帯端末60-Aは、受信した混雑状況応答を表示するS639。ここで、電車20-Aは、[n1]駅出発後の各車両の乗車率を検出するS641。電車20-Aは、混雑予測処理サーバ50に乗車率を無線伝達するS642。混雑予測処理サーバ50は、混雑処理用DB80を更新するS643。混雑予測処理サーバ50は、障害時混雑処理用DB81を更新するS644。ここで、システム管理端末90-Aは、トラブル解消情報を受け付けるS646。システム管理端末90-Aは、混雑予測処理サーバ50にトラブル_Flag=0のトラブル解消通知を送信するS647。図14を参照して、携帯端末の検索結果画面を説明する。図14において、携帯電話60-Aの検索結果画面1401には、当該電車の車両それぞれに対する各駅出発後の乗車率を表示する。検索結果の表示では、ユーザはA駅10-Aに8:00の乗車時間を予定して空席検索モードを指定したが、A駅10-Aでの人身事故の影響で車両内が混雑しており、9:10まで電車を待たなければ空席を確保できない可能性があることが判明している。ユーザがA駅10-Aで電車20を待っている際、電車20の各車両の混雑情報を入手するために、携帯端末60から混雑状況処理サーバ50に問い合わせる。ユーザがネットワーク公衆網40を介して混雑状況予測サーバ50にアクセスした場合、まずは車両混雑状況予測システムのサービスを提供できるユーザであるのか混雑状況処理サーバ50の認証部305で確認される。ユーザ認証が可と判断された場合には、課金部306でユーザに対してのサービス提供の課金情報の管理が開始される。ユーザ認証する際のIDパスワード入力やユーザが電車の混雑情報を問い合わせる際の乗車時間乗車駅などの入力を促す為、入出力部304は表示部303と連携して、ユーザに対して適切な入出力画面を提供する。ユーザは、携帯端末60の検索入力画面1201を利用して、乗車日時乗車時間乗車駅降車駅の入力、またOption空席検索モードをONにして検索ボタンを押すことにより、当該条件での混雑情報を要求する。現在の運行状況にトラブルが発生している事を混雑処理サーバ50に通知する事で、混雑処理サーバ50が受信した内容を検索入力画面1201にアナウンスする事ができる。なお、JRや私鉄で現在運行中の電車20では、車両毎に設置されている人感センサ201センサで検出した車両混雑情報70を、随時、混雑状況処理サーバ50に転送している。混雑状況予測サーバ50で受け付けられた車両混雑情報70を元にして、制御部301からの指示により図4で示す混雑予測処理DB80の情報は、図7で示す混雑率更新フローチャートに沿って更新される。また、図11で示す障害時混雑処理用DB81の情報は、式1で示す掛け値の計算式で更新される。現時点での電車20の混雑情報が管理される他、今後の混雑状況についても予測処理されるデータが作成されている。混雑状況予測サーバ50は、ユーザからの電車の混雑情報の問い合わせに対して、混雑予測処理DB80、障害時混雑予測処理DB81の情報を演算部302で適切な処理を実施した後に、表示部303で問い合わせ内容の応答を作成する。混雑状況処理サーバ50は、ユーザからの問い合わせに対して、ユーザが乗車するA駅10-Aでの電車20の最新の混雑状況、および降車するまでの途中のB駅10-B、C駅10-Cでの予測混雑情報を、携帯端末60に検索結果画面1401で示す。ユーザは、この車両混雑状況予測システムのサービスを受ける事により、電車20-Aまたは電車20-Bなどの次発以降の電車に乗車すべきかを判断する。ユーザが車両混雑状況予測システムのサービスの終了を判断した場合には、課金部306での管理も終了させる。