JP6309109B2 - 交通流制御システム及び交通流制御方法 - Google Patents

Description

本発明は、交通機関の利用者に情報を提供して交通流を制御する交通流制御システムに関する。

交通機関に障害が発生した場合、駅は利用者で混雑し、障害が復旧した後には、交通機関に利用者が殺到する。

この技術分野の背景技術として特開２００６−４１００号公報（特許文献１）がある。特許文献１には、列車運行開始までの利用者の待機中に受けることができるサービスに関連する情報を提供する運行管理システムが開示されている。

特開２００６−４１００号公報

前述した特許文献１に記載された運行管理システムでは、利用者の意向に応じた情報を端末に配信するが、利用者の嗜好に適した待機場所を選択する方法は開示されていない。また、利用者の移動の緊急度は考慮されていなかった。通常、交通機関の利用者は乗車前の経路検索において移動の緊急度を入力しているので、この情報を使用すれば事故時に再度意向を確かめる必要なく適切な通知ができる。さらに、交通障害の回復の通知方法によって、運行開始直後の混雑を回避することも考慮されておらず、回復時の乗車についても利用者の意向が考慮されていない。

このようなシステムでは、交通機関の利用者の本システムの利用率を向上させて、駅構内や周辺の混雑を有効に緩和することが必要となる。このため、利用者の嗜好に適した待機場所を推薦し、より利用者が利用しやすく、かつ受け入れやすいシステムが求められている。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、交通機関の利用者に情報を提供する交通流制御システムであって、プログラムを実行するプロセッサと、前記プロセッサがアクセス可能なメモリと、前記プロセッサに接続される通信インターフェースとを備え、利用者の待機場所を選択するための条件が記録される待機条件を前記メモリに保持し、前記プロセッサは、交通機関に発生した障害の情報を受信した場合、前記待機条件を参照して、利用者に適する待機場所を選択し、前記選択された待機場所の情報を前記利用者の端末に送信することによって利用者の待機を促し、交通機関に発生した障害の回復の情報を受信した場合、利用者の待機場所から駅までの所要時間に応じて、前記障害の回復の情報を送信する時刻を決定し、前記決定された時刻に前記障害の回復の情報を前記利用者の端末に通知する。

本発明の代表的な実施の形態によれば、交通機関の利用者の本システムの利用率を向上して、駅構内や周辺の混雑を緩和することができる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

本発明の第１実施例の交通流制御システムの論理的な構成を示すブロック図である。 第１実施例の交通流制御システムの物理的な構成を示すブロック図である。 第１実施例の店舗情報の構成例を示す図である。 第１実施例の障害情報の構成例を示す図である。 第１実施例の回復情報の構成例を示す図である。 第１実施例の利用者待機情報の構成例を示す図である。 第１実施例の行き先情報・待機条件の構成例を示す図である。 第１実施例の交通流制御システムによって実行される処理のシーケンス図である。 第１実施例の待機場所割当処理のフローチャートである。 第１実施例の回復通知処理のフローチャートである。 第１実施例の迂回路提示処理のフローチャートである。 第１実施例の行き先・待機条件入力画面の例を説明する図である。 第１実施例の店舗情報通知画面の例を説明する図である。 第１実施例のバス乗降場の模式図である。 第１実施例のバス乗降場の模式図である。 第１実施例のバス乗降場に設置されたサイネージ装置の模式図である。 本発明の第２実施例の基本的な処理のシーケンス図である。 第２実施例の対策判断基準の例を説明する図である。 第２実施例の対策リストの例を説明する図である。 第２実施例における交通機関に障害が発生した時の処理の例を説明する図である。 第２実施例におけるイベント発生時の処理の例を説明する図である。

＜実施例１＞
まず、本発明の第１実施例について説明する。

図１は、第１実施例の交通流制御システム１００の論理的な構成を示すブロック図である。

第１実施例の交通流制御システム１００は、交通機関の利用者に情報を提供する情報提供システム、すなわち、交通機関に障害が発生した場合に利用者に待機場所を割り当て、割り当てた待機場所を案内する待機場所割当システムである。具体的には、交通流制御システム１００は、待機場所割当部１１０、回復通知最適化部１２０、情報通知部１３０及び情報入力部１４０を有する。これらの機能部は、メモリ１０２に格納されたプログラムをプロセッサ１０１（図２参照）が実行することによって実装される。

待機場所割当部１１０は、利用者に適する待機場所を選択する待機場所割当処理を実行する（図９参照）。回復通知最適化部１２０は、利用者端末２００に回復通知を送信する回復通知処理を実行する（図１０参照）。情報通知部１３０は、利用者端末２００に待機場所の情報を通知したり、回復通知を送信する。情報入力部１４０は、利用者端末２００から入力された情報を受け付ける。

また、交通流制御システム１００は、店舗情報１５０、障害情報１６０、回復情報１７０、利用者待機情報１８０及び行き先情報・待機条件１９０を有する。これらの情報及び条件は、メモリ１０２（図２参照）に格納される。なお、これらの情報及び条件は、記憶装置１０３（図２参照）に格納され、必要に応じて記憶装置１０３から読み出されて、メモリ１０２にロードされてもよい。

店舗情報１５０は、交通流制御システム１００によって利用者が誘導される待機場所となる施設（例えば、店舗）の情報が記録されるテーブルであり、その詳細は図３を用いて後述する。障害情報１６０は、交通機関において発生した障害（例えば、遅延、運休など）の情報が記録されるテーブルであり、その詳細は図４を用いて後述する。回復情報１７０は、交通機関において発生した障害の回復の情報が記録されるテーブルであり、その詳細は図５を用いて後述する。利用者待機情報１８０は、交通流制御システム１００によって誘導されて待機場所にいる利用者の情報が記録されるテーブルであり、その詳細は図６を用いて後述する。行き先情報・待機条件１９０は、利用者端末２００から入力された行き先及び待機場所の選択条件が記録されるテーブルであり、その詳細は図７を用いて後述する。

交通流制御システム１００は、ネットワーク（例えば、携帯電話網）を介して利用者端末２００と接続される。

また、交通流制御システム１００は、ネットワーク（例えば、ＬＡＮ）を介して運行制御システム３００と接続される。運行制御システム３００は、列車などの交通機関の運行を管理及び制御する計算機システムであり、交通機関に生じた障害及び障害の回復の情報を交通流制御システム１００に通知する。なお、交通流制御システム１００は、運行制御システム３００の一部として構成されてもよい。

さらに、交通流制御システム１００は、ネットワーク（例えば、ＬＡＮ）を介して経路探索部４００と接続される。経路探索部４００は、移動経路を検索する計算機システムであり、利用者が予定した経路を利用できない場合、代替経路の情報を交通流制御システム１００に通知する。経路探索部４００は、交通流制御システム１００の一部として構成されてもよいし、運行制御システム３００の一部として構成されてもよい。

さらに、交通流制御システム１００は、ネットワーク（例えば、ＬＡＮ）を介して、交通管制システム３５０、バス事業者の管理システム３６０及びタクシー事業者の管理システム３７０と接続される。交通管制システム３５０は、交通標識や交通信号を制御する計算機システムであって、警察や行政機関が管理する。管理システム３６０は、バス運行事業者がバスの運行を管理するための計算機システムであって、本実施例ではバスの増発の要請を受け付ける。管理システム３７０は、タクシー運行事業者がタクシーの運行を管理するための計算機システムであって、本実施例ではタクシーの配車の要請を受け付ける。

なお、本実施例において、同じ事業者が鉄道とバスとタクシーとを運行する場合、運行制御システム３００と、バス事業者の管理システム３６０と、タクシー事業者の管理システム３７０とは、一つのシステムを構成してもよい。さらに、これらのシステム３００、３６０、３７０が、交通流制御システム１００と統合して、一つのシステムを構成してもよい。

また、交通流制御システム１００と交通管制システム３５０とが、一つのシステムを構成してもよい。

図２は、第１実施例の交通流制御システム１００の物理的な構成を示すブロック図である。

本実施形態の交通流制御システム１００は、プロセッサ（ＣＰＵ）１０１、メモリ１０２、記憶装置１０３及び通信インターフェース１０４を有する計算機システムによって構成される。

プロセッサ１０１は、メモリ１０２に格納されたプログラムを実行する。メモリ１０２は、不揮発性の記憶素子であるＲＯＭ及び揮発性の記憶素子であるＲＡＭを含む。ＲＯＭは、不変のプログラム（例えば、ＢＩＯＳ）などを格納する。ＲＡＭは、ＤＲＡＭ（Dynamic Random Access Memory）のような高速かつ揮発性の記憶素子であり、プロセッサ１０１が実行するプログラム及びプログラムの実行時に使用されるデータを一時的に格納する。

記憶装置１０３は、例えば、磁気記憶装置（ＨＤＤ）、フラッシュメモリ（ＳＳＤ）等の大容量かつ不揮発性の記憶装置であり、プロセッサ１０１が実行するプログラム及びプログラムの実行時に使用されるデータ（例えば、地図データ）を格納する。すなわち、プログラムは、記憶装置１０３から読み出されて、メモリ１０２にロードされて、プロセッサ１０１によって実行される。

交通流制御システム１００は、入力インターフェース１０５及び出力インターフェース１０８を有してもよい。入力インターフェース１０５は、キーボード１０６やマウス１０７などが接続され、利用者からの入力を受けるインターフェースである。出力インターフェース１０８は、ディスプレイ装置１０９やプリンタなどが接続され、プログラムの実行結果を利用者が視認可能な形式で出力するインターフェースである。

通信インターフェース１０４は、所定のプロトコルに従って、他の装置との通信を制御するネットワークインターフェース装置である。

プロセッサ１０１が実行するプログラムは、リムーバブルメディア（ＣＤ−ＲＯＭ、フラッシュメモリなど）又はネットワークを介して交通流制御システム１００に提供され、非一時的記憶媒体である不揮発性記憶装置１０３に格納される。このため、交通流制御システム１００は、リムーバブルメディアからデータを読み込むインターフェースを有するとよい。

第１実施例の交通流制御システム１００は、物理的に一つの計算機上で、又は、論理的又は物理的に構成された複数の計算機上で構成される計算機システムであり、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。

図３は、第１実施例の店舗情報１５０の構成例を示す図である。

店舗情報１５０は、交通流制御システム１００によって利用者が誘導される待機場所となる店舗の情報が記録されるテーブルであり、店舗名１５１、カテゴリ１５２、保有設備１５３、所要時間１５４、クーポン１５５、利用回数１５６及び単価１５７のフィールドを含む。

店舗名１５１は、利用者が誘導される待機場所となる店舗の名称である。カテゴリ１５２は、当該店舗の種別である。保有設備１５３は当該店舗で利用者が利用できる設備であり、例えば、ＷｉＦｉや、ＡＣ電源（商用電源）、ＤＣ電源（ＵＳＢ規格の５Ｖ）である。所要時間１５４は、当該店舗から駅までの所要時間である。クーポン１５５は、当該店舗において、利用者に提供される特典の内容である。

利用回数１５６は、本交通流制御システム１００によって紹介された利用者が当該店舗を利用した回数であり、後述する店舗への課金情報となる。単価１５７は、本交通流制御システム１００によって紹介された利用者が当該店舗を利用した回数当たりの課金額であり、店舗情報が登録される際に予め決められている。

なお、店舗情報１５０は駅毎に一つのテーブルを有するが、店舗情報１５０が最寄り駅のフィールドを含み、全ての駅に関する店舗（待機場所）の情報が記録されてもよい。また、本実施例の店舗情報には、商品や役務を提供する商業施設（カフェ、商店、ショッピングセンター、ゲームセンターなど）が登録されるが、公共施設（博物館、美術館など）が登録されてもよい。すなわち、店舗に限らず、様々な施設が店舗情報１５０に登録されてよい。

図４は、第１実施例の障害情報１６０の構成例を示す図である。

障害情報１６０は、障害ＩＤ１６１、回復時間１６２及び影響駅１６３のフィールドを含み、発生した障害（例えば、遅延、運休など）の情報を運行制御システム３００から取得して記録する。

障害ＩＤ１６１は、交通機関に発生した障害を一意に識別するための識別情報である。回復時間１６２は、当該障害を復旧するために必要な時間の予想値である。影響駅１６３は、当該障害で影響を受ける駅（例えば、運転を見合わせている区間の駅）のリストである。

図５は、第１実施例の回復情報１７０の構成例を示す図である。

回復情報１７０は、障害ＩＤ１７１及び回復時刻１７２のフィールドを含み、障害の回復の情報を運行制御システム３００から取得して記録する。

障害ＩＤ１７１は、交通機関に発生した障害を一意に識別するための識別情報である。回復時刻１７２は、当該障害が復旧する時刻である。なお、回復時刻１７２が過去の時刻であれば、当該障害が既に回復していることを示し、回復時刻１７２が将来の時刻であれば、当該障害が未だに回復していないことを示す。

図６は、第１実施例の利用者待機情報１８０の構成例を示す図である。

利用者待機情報１８０は、交通流制御システム１００によって誘導されて待機場所にいる利用者の情報であり、障害ＩＤ１８１、利用者ＩＤ１８２、店舗名１８３、回復通知条件１８４及び所要時間１８５のフィールドを含む。

障害ＩＤ１８１は、交通機関に発生した障害を一意に識別するための識別情報である。利用者ＩＤ１８２は、交通流制御システム１００の利用者を一意に識別するための識別情報である。店舗名１８３は、利用者が交通流制御システム１００によって誘導されて待機している店舗の名称である。回復通知条件１８４は、利用者端末２００から入力された、回復通知に関する条件であり、「混雑回避」又は「時間優先」が設定される。なお、回復通知条件１８４に、障害回復からの待ち時間を数値で設定してもよい。所要時間１８５は、利用者が待機している店舗から駅までの所要時間である。

図７は、第１実施例の行き先情報・待機条件１９０の構成例を示す図である。

行き先情報・待機条件１９０は、利用者端末２００から入力された行き先及び待機場所の選択条件が記録されるテーブルであり、利用者ＩＤ１９１、出発地１９２、到着地１９３、緊急度１９４、嗜好１９５、待機設備条件１９６及び回復通知条件１９７のフィールドを含む。

利用者ＩＤ１９１は、行き先及び待機場所の選択条件を入力した利用者を一意に識別するための識別情報である。出発地１９２は、当該利用者による移動の出発地である。到着地１９３は、当該利用者による移動の到着地である。緊急度１９４は、当該利用者の移動の緊急度であり、「高」又は「低」が設定される。緊急度１９４は、交通機関に障害が発生した際に待機場所を提示するか、迂回経路を提示するかを判定するために用いられる。嗜好１９５は、当該利用者に紹介する待機場所の種別を示す。待機設備条件１９６は、当該利用者に紹介する待機場所で利用者が利用できる設備の条件である。回復通知条件１９７は、当該利用者に障害回復を通知する条件である。

図８は、第１実施例の交通流制御システム１００によって実行される処理のシーケンス図である。

まず、利用者は、利用者端末２００を用いて、交通流制御システム１００にアクセスして、行き先情報及び待機条件を入力する（Ｓ１０１）。行き先情報及び待機条件の入力は、交通機関の障害が発生する前（例えば、乗車時）でも、障害が発生した後でもよい。行き先・待機条件を利用者端末２００で入力するための行き先・待機条件入力画面２１０の例は、図１２を用いて後述する。

一方、運行制御システム３００は、交通機関に発生した障害を検出すると、交通流制御システム１００に障害情報を通知する（Ｓ１０２）。運行制御システム３００から交通流制御システム１００に通知される障害情報は、障害ＩＤ、回復時間及び影響駅の情報を含む。

交通流制御システム１００は、運行制御システム３００から受信した障害情報を障害情報１６０に格納し、影響駅にて障害の回復を待っている利用者に適する待機場所を選択し（Ｓ１０３）、選択された待機場所の候補を利用者端末２００に通知する。利用者端末２００に通知される待機場所候補は、障害ＩＤ、待機場所の店舗名及びクーポンの情報を含む。なお、待機場所を選択する待機場所割当処理の詳細は図９を用いて後述する。

利用者端末２００は、交通流制御システム１００から待機場所候補を受信すると、店舗情報通知画面２２０を表示する（Ｓ１０４）。なお、店舗情報通知画面２２０の例は図１３を用いて後述する。

利用者端末２００に表示された店舗情報通知画面２２０の「利用済」ボタン２２３が操作されると、利用者端末２００はクーポン利用情報を交通流制御システム１００に送信する（Ｓ１０５）。「利用済」ボタン２２３は、利用者が操作しても、利用者から画面の提示を受けた店員が操作してもよい。また、店員が「利用済」ボタン２２３を操作する際に、店舗毎に定められたパスコードを入力するようにしてもよい。また、利用者端末２００の位置が当該店舗の位置と所定の誤差範囲内で一致したら、利用者が店舗を利用したと判定してもよい。位置情報を用いる場合、店舗内に設置されたビーコンからの信号を受信したかによって判定してもよい。さらに、店舗に設けられた近距離無線通信手段（例えば、非接触ＩＣカードリーダや、Ｂｌｕｅｔｏｏｔｈなど）と利用者端末２００とが通信することによって、利用者が店舗を利用したと判定してもよい。

利用者端末２００から交通流制御システム１００に送信されるクーポン利用情報は、障害ＩＤ、利用者ＩＤ及び店舗名の情報を含む。障害ＩＤ及び店舗名は、交通流制御システム１００が送信した待機場所候補に含まれている識別情報を、利用者端末２００が折り返して交通流制御システム１００に送信される。利用者ＩＤは、利用者端末２００で保持している識別情報が送信される。

交通流制御システム１００はクーポン利用情報を受信すると、利用者待機情報に当該利用者のレコードを保存する（Ｓ１０６）。具体的には、利用者端末２００から送信されるクーポン利用情報に含まれる障害ＩＤ、利用者ＩＤ及び店舗名を、利用者待機情報１８０の障害ＩＤ１８１、利用者ＩＤ１８２及び店舗名１８３にそれぞれ格納する。また、行き先情報・待機条件１９０から、当該利用者ＩＤの回復通知条件１９７を取得し、利用者待機情報１８０の回復通知条件１８４に格納する。さらに、店舗情報１５０から、当該店舗の所要時間１５４を取得し、利用者待機情報１８０の所要時間１８５に格納する。

また、交通流制御システム１００はクーポン利用情報を受信すると、利用回数１５６に１を加算して店舗情報１５０を更新する（Ｓ１０７）。店舗情報１５０の利用回数１５６は、所定のタイミングで集計され、課金情報として利用される。

その後、障害が回復すると、運行制御システム３００は、交通流制御システム１００に障害の回復を通知する（Ｓ１０８）。運行制御システム３００から交通流制御システム１００に通知される回復情報は、障害ＩＤ及び回復時刻の情報を含む。

交通流制御システム１００は、運行制御システム３００から受信した回復情報通知を回復情報１７０に格納し、該当する利用者の利用者端末２００に回復通知を送信する（Ｓ１０９）。交通流制御システム１００から利用者端末２００に送信される回復通知は、障害ＩＤ及び回復時刻の情報を含む。

利用者端末２００は、交通流制御システム１００から回復通知を受信すると、回復情報を表示する（Ｓ１１０）。具体的には、利用者端末２００は、交通障害が回復を表示したり（例えば、「事故が復旧しました。」や、「１６時に運行を再開しました。」）、交通障害の回復予定を表示したり（例えば、「１６時に運行を再開する予定です。」）、店舗を出発する時刻を表示してもよい。利用者は、利用者端末２００に表示された回復情報を見て、待機場所から駅に移動する時刻を決定することができる。

図９は、第１実施例の待機場所割当処理（図８のステップＳ１０３）の詳細のフローチャートである。

各影響駅ＸについてステップＳ１２１からＳ１２７の処理を繰り返し実行する。

まず、影響駅Ｘにいる利用者のうち出発地及び到着地の両方が影響駅Ｘに含まれる利用者のデータを行き先情報・待機条件１９０から選択する（Ｓ１２１）。影響駅Ｘにいる利用者は、利用者の現在位置や入出場記録などから特定することができる。また、利用者の現在位置は、ＧＰＳなどの測位デバイスや接続基地局を用いた測位方法を用いて取得することができる。例えば、障害情報１６０の１行目の交通障害について、行き先情報・待機条件１９０の各利用者のデータを照合すると、出発地１９２及び到着地１９３の両方が影響駅１６３に含まれる利用者は、利用者ＩＤが１００２、１００３及び１００４の３名である。

なお、経路探索部４００に問い合わせて、出発地と到着地との間の標準的な経路に影響駅が含まれているかを判定してもよい。また、到着地のみが影響駅に含まれる利用者のデータを行き先情報・待機条件１９０から抽出してもよい。

そして、選択された各データについてステップＳ１２２からＳ１２７の処理を繰り返し実行する。

まず、抽出されたデータの緊急度１９４が「高」であるかを判定する（Ｓ１２２）。緊急度１９４が「高」である場合、当該利用者が急いで移動しているので、迂回経路を提示する（Ｓ１２８）。迂回経路提示処理は、図１１を用いて後述する。

次に、嗜好１９５によって処理を分岐する（Ｓ１２３）。嗜好１９５が「カフェ」である場合、店舗情報１５０のカテゴリ１５２が「カフェ」である待機場所を店舗情報１５０から抽出し（Ｓ１２４）、ステップＳ１２６に進む。一方、嗜好１９５が「ショッピング」である場合、店舗情報１５０のカテゴリ１５２が「ショッピング」である待機場所を店舗情報１５０から選択し（Ｓ１２５）、ステップＳ１２６に進む。

この場合、嗜好が一致する処理に進むが、嗜好が多くの項目に分類されている場合、嗜好が類似しているものを選択してもよい。さらに、嗜好が一致しているものが選択できなかった場合に、嗜好が類似しているものを選択してもよい。

ステップＳ１２６において、店舗情報１５０の保有設備１５３が行き先情報・待機条件１９０の待機設備条件１９６を満たす待機場所を選択する。

ステップＳ１２２からＳ１２６の処理では、緊急度、嗜好及び保有設備の三つの条件を用いて待機場所を選択したが、緊急度、嗜好及び保有設備の一部の条件を用いて、待機場所を選択してもよい。

その後、選択された待機場所の情報を通知する（Ｓ１２７）。交通流制御システム１００から利用者端末２００に通知される待機場所候補は、障害ＩＤ、待機場所の店舗名及びクーポンの情報を含む。障害ＩＤは、障害情報１６０の障害ＩＤ１６１から取得する。待機場所の店舗名は、ステップＳ１２６で抽出された店舗名１５１であり、クーポンは当該店舗のクーポン１５５である。

交通流制御システム１００は、原則として、１箇所の待機場所を通知するが、複数の待機場所を通知してもよい。この場合、利用者の現在位置（例えば、駅）から近い順に表示しても、利用者の好みへの適合度が高い順にリスト形式で表示してもよい。さらに、行き先情報・待機条件１９０の回復通知条件１９７が「時間優先」の利用者には、現在位置から近い（例えば、３分以内）待機場所を割り当て、回復通知条件１９７が「混雑回避」の利用者には、現在位置から遠い待機場所を割り当ててもよい。

なお、店舗毎に複数のクーポンの情報を店舗情報１５０に記録し、利用者の属性（例えば、年齢、性別、職業、過去の利用履歴など）によって、適するクーポンを選択してもよい。

図１０は、第１実施例の回復通知処理（図８のステップＳ１０９）の詳細のフローチャートである。

まず、運行制御システム３００から受信した回復情報通知の障害ＩＤと等しい利用者の情報を利用者待機情報１８０から選択する（Ｓ１３１）。

選択された各利用者についてステップＳ１３２からＳ１３７の処理を繰り返し実行する。

まず、回復情報１７０の回復時刻１７２から利用者待機情報１８０の所要時間１８５を減じた値を通知時刻Ｔに設定する（Ｓ１３２）。

そして、利用者待機情報１８０の回復通知条件１８４が「混雑回避」であるかを判定する（Ｓ１３３）。回復通知条件１８４が「混雑回避」であれば、交通機関の障害が回復した直後の混雑が緩和してからの乗車を勧めるために、ステップＳ１３２で計算した通知時刻Ｔに所定の時間（本例では３０分）を加算する（Ｓ１３４）。ステップＳ１３４で加算する時間は３０分に限らず、混雑状況（各駅の待機利用者の数）に応じて設定してもよく、利用者が設定した時間でもよい。

その後、通知時刻Ｔが現在時刻より早いかを判定する（Ｓ１３５）。通知時刻Ｔが現在時刻より早ければ、直ちに利用者端末２００に回復通知を送信する（Ｓ１３７）。一方、通知時刻Ｔが現在時刻より後の時刻であれば、時刻Ｔに回復通知を送信する（Ｓ１３６）。

なお、回復通知条件１８４が「混雑回避」の利用者にも、すぐに回復を通知して、待機場所を出る推奨時刻を通知してもよい。

図１１は、第１実施例の迂回路提示処理（図９のＳ１２８）のフローチャートである。

まず、利用者の現在位置及び到着地を取得する。利用者の現在位置は、利用者端末２００に備わるＧＰＳなどの測位デバイスや接続基地局を用いた測位方法によって取得することができる。到着地は行き先情報・待機条件１９０から取得する。そして、経路探索部４００に問い合わせて、利用者の現在位置から到着地まで鉄道による迂回経路が利用可能であるかを判定する（Ｓ１４１）。例えば、経路探索部４００が鉄道のみの利用を条件として探索した迂回経路が通常の移動時間の２倍より小さければ、鉄道による迂回経路が利用可能であると判定してもよい。

利用者の現在位置から到着地まで鉄道による迂回経路が利用可能であれば、鉄道による迂回経路を案内する（Ｓ１４２）。

次に、経路探索部４００に問い合わせて、利用者の現在位置から到着地までバス路線を含む迂回経路が利用可能であるかを判定する（Ｓ１４４）。例えば、経路探索部４００が鉄道及びバスの利用を条件として探索した迂回経路が通常の移動時間の２倍より小さければ、バス路線があると判定してもよい。

なお、バス路線の有無を判定する前に、管理者に対策案を提示して、管理者が選択した対策案を受け付ける処理（Ｓ１４３）を実行してもよい。

バス路線がある場合、経路探索部４００から取得した迂回経路のためのバスの利用案内を利用者端末２００に送信する（Ｓ１４５）。例えば、利用するバス路線が発車するバス乗り場や、バスの運賃や、バスによる迂回経路による移動時間を案内する。

その後、同一方向に迂回乗車する人の数が所定数以上であるかを判定する（Ｓ１４６）。同一方向に迂回乗車する人の数は、行き先情報・待機条件１９０を参照し、到着地が同一の利用者のうち、利用者端末２００に回復通知を送信した人の数を合計したり、バス乗り場で撮影された画像から人数をセンシングしたり、シミュレーションによって人数を計算してもよい。また、バスが増発される場合、増発バスの乗車を申し込んだ利用者の利用者端末２００に乗車券を配付してもよい。

そして、同一方向に迂回乗車する人の数が所定数以上であれば、増発バスを手配したり、乗り合いタクシーを手配したりする（Ｓ１４７）。例えば、バス運行事業者の運行管理システムに増発バスの手配を要請する。また、タクシー運行事業者の運行管理システムに乗り合いタクシーの手配を要請する。

一方、ステップＳ１４４においてバス路線がないと判定された場合、タクシーの利用案内を利用者端末２００に送信する（Ｓ１４８）。例えば、タクシー乗り場や、タクシーによる移動時間を案内する。

その後、タクシー待ちの人の数が所定数以上であるかを判定する（Ｓ１４９）。タクシー待ちの人の数が所定数以上であれば、バスレーンをタクシーレーンに切り替えるために、交通標識の表示の変更を交通管制システム３５０に要請し、交通規制を変更して、タクシー乗り場を増加する（Ｓ１５０）。

その後、タクシー運行事業者の運行管理システムにタクシーの手配を要請する（Ｓ１５１）。このため、タクシー運行事業者は確実に乗客が見込めるタクシーを配車することができる。なお、近隣にいるタクシーのみを配車対象にすると、遠方からタクシーが集まることなく、周辺の道路の渋滞を引き起こさなくてよい。

図１２は、第１実施例の行き先・待機条件入力画面２１０の例を説明する図である。

行き先・待機条件入力画面２１０は、出発地の入力欄２１１、到着地の入力欄２１２、緊急度の選択欄２１３、カテゴリの選択欄２１４、設備の条件の選択欄２１５及び回復時の条件の選択欄２１６を含む。交通流制御システム１００は、行き先・待機条件入力画面２１０に入力されたデータを行き先情報・待機条件１９０に記録する。

出発地の入力欄２１１及び到着地の入力欄２１２には、それぞれ、当該利用者が移動する出発地及び到着地が入力される。出発地の入力欄２１１及び到着地の入力欄２１２に入力されたデータは、それぞれ、行き先情報・待機条件１９０の出発地１９２及び到着地１９３に記録される。

緊急度の選択欄２１３では、「高」又は「低」が選択される。選択されたデータは、行き先情報・待機条件１９０の緊急度１９４に記録される。カテゴリの選択欄２１４では、利用者が選択可能な待機場所のカテゴリが選択可能で、図示した例では「カフェ」及び「ショッピング」の一つ以上が選択可能であるが、さらに細かく分類してもよく、他のカテゴリの選択肢を含んでもよい。カテゴリの選択欄２１４で選択されたデータは、行き先情報・待機条件１９０の嗜好１９５に記録される。

設備の条件の選択欄２１５では、当該利用者に紹介する待機場所で利用者が利用できる設備の条件が選択される。選択されたデータは、行き先情報・待機条件１９０の待機設備条件１９６に記録される。図示した例では、「スマホ充電」、「ＷｉＦｉ」及び「ＡＣ電源」の一つ以上が選択可能である。

回復時の条件の選択欄２１６では、当該利用者に障害回復を通知する条件が選択される。選択されたデータは、行き先情報・待機条件１９０の回復通知条件１９７に記録される。図示した例では、「時間優先」又は「混雑回避」が選択可能である。「混雑回避」を選択した場合、利用者に通知を送る時間の入力を求めてもよい。

なお、利用者は、緊急度、カテゴリ、設備の条件の少なくとも一つを選択すればよく、利用者が選択しなかった項目は、行き先情報・待機条件１９０において、ヌルデータとなる。

図１３は、第１実施例の店舗情報通知画面２２０の例を説明する図である。

店舗情報通知画面２２０は、店舗情報２２１及びクーポン２２２の表示欄を含み、「利用済」ボタン２２３を含む。

店舗情報２２１は、当該利用者が入力した条件に一致する店舗の情報（例えば、店舗名）である。なお、店舗名に、詳細な店舗情報（地図、連絡先、予約画面など）へのハイパーリンクを含めてもよい。クーポン２２２は、利用者に提供されるクーポンの内容を表示する。クーポン２２２が、特典の詳細な情報へのハイパーリンクを含んでもよい。

「利用済」ボタン２２３は、利用者がクーポンの利益を受けた場合、利用者又は店員が操作する。

図１４、図１５Ａ及び図１５Ｂは、第１実施例のバス乗降場の模式図である。

図１４は、通常時（通常モード）のバス乗降場６００を示す。図１４に示すように、バス乗降場６００には大型の表示画面を有するサイネージ装置６１０が設置されており、通常時はバスの乗降案内やバス路線の情報が提供される。また、バス乗降場６００には、チェックイン端末６２０が設置されており、乗車するバスを予約できたり、予約したバスのチケットを発券できる。さらに、バス乗降場は、屋根や壁を有し、バスが発着する面以外は囲われた空間を形成し、その中には空調機が設置される。

図１５Ａ及び図１５Ｂは、障害発生時（インシデントモード）のバス乗降場６００を示す。図１５Ａに示すように、インシデントモードでは、バス乗降場をタクシー乗り場に変更する。このため、設置されたサイネージ装置６１０に障害時に有用な案内を表示する。例えば、タクシーの乗車案内や、タクシーによる所要時間や料金を表示するとよい。また、乗り合いタクシーの案内を表示してもよい。さらに、図１５Ｂに示すように、バスやタクシー以外の交通手段（例えば、レンタサイクル）の案内を表示してもよい。

以上に説明したように、本発明の第１実施例によると、交通流制御システム１００が、交通機関の運行状況を受信し、行き先情報・待機条件１９０を参照して利用者に適する待機場所を選択し、選択された待機場所の情報を利用者端末２００に送信するので、利用者の嗜好に適した待機場所を選択することによって交通機関の利用者の本システムの利用率を向上し、駅構内や周辺の混雑を緩和することができる。また、利用者が必要とする情報を提供することによって、利用者の不満を解消することができる。

また、前述した特許文献１に記載された運行管理システムでは、利用者の意向に応じた情報を端末に配信するが、方法は開示されていない。また、利用者の移動の緊急度は考慮されていなかった。通常、交通機関の利用者は乗車前の経路検索において移動の緊急度を入力しているので、この情報を使用すれば事故時に再度意向を確かめる必要なく適切な通知ができる。

また、行き先情報・待機条件１９０に記録される利用者の嗜好は頻繁に変わるものではないので、交通機関の障害が発生する前に入力しておくことにより、障害が発生する毎に利用者に意向を問い合わせることなく、適切な通知をすることができる。

また、交通流制御システム１００が、交通機関に発生した障害の情報を受信した場合、利用者に適する待機場所を選択し、選択された待機場所の情報を利用者端末２００に送信するので、交通機関の利用者を分散し、駅構内や周辺の混雑を緩和することができる。

また、交通流制御システム１００が、障害の回復の情報を受信した場合、障害の回復を利用者端末２００に通知するので、利用者は、障害の回復を知ることができて便利である。

また、交通流制御システム１００が、利用者の待機場所から駅までの所要時間に応じて、前記障害の回復の情報を送信する時刻を決定するので、待機場所に応じてちょうどよい時刻に駅に到着することができ、駅構内の混雑を緩和することができる。すなわち、利用者は回復情報の通知を見たら待機場所を出て駅に向かえば自分の望みに従った電車（混んでいても早く目的地に着く電車、又は混雑が収まった後の電車）に乗ることができる。

また、交通流制御システム１００が、利用者が混雑を回避した移動を望む場合、交通機関の障害の回復から所定時間が経過した後に前記障害の回復の情報を送信するので、空いている時間帯に交通機関を利用することができる。

また、交通流制御システム１００が、緊急度、待機場所の種別及び設備の条件の少なくとも一つに従って、利用者に適する待機場所を選択するので、利用者の好みに合わせた待機場所を選択することができ、利用者の利便性を向上でき、本システムの利用率を向上することができる。

また、交通流制御システム１００が、移動の緊急度が高い利用者に迂回経路を案内し、移動の緊急度が低い利用者に待機場所を選択するので、急いでいる利用者にも適切な案内をすることができる。すなわち、通常、交通機関の利用者は乗車前の経路検索において移動の緊急度を入力しているので、この情報を使用すれば事故時に再度意向を確かめる必要ない。第１実施例の交通流制御システム１００では、交通機関の乗車前に入力された情報を使用して、利用者に情報を提供するので、事故時に再度意向を確かめる必要がなく、利用者に適切な情報を提供できる。

また、交通流制御システム１００は、利用者が待機場所で利用できるクーポンを利用者端末２００に送信するので、利用者に待機場所を利用するインセンティブを与えることができ、待機場所は顧客を増加することができる。

また、交通流制御システム１００が、クーポンの利用状況に応じて、当該待機場所への課金情報を生成するので、交通流制御システム１００を運営する事業者の収益とすることができる。

また、交通障害が発生した区間がバスによって移動可能であり、かつ、同一方向に移動する人が所定数以上である場合、交通流制御システム１００が、増発バスを手配するので、バス乗り場の混雑を緩和し、利用者が早く目的地に到着できるようになる。また、バス運行事業者は、確実に乗客が見込める増発バスを運行することができる。

また、タクシーを待っている人が所定数以上である場合、タクシーを手配するので、交通流制御システム１００が、タクシー乗り場の混雑を緩和し、利用者が早く目的地に到着できるようになる。また、タクシー運行事業者は、確実に乗客が見込めるタクシーを配車することができる。

また、交通流制御システム１００が、タクシーの進入を可能にするようにバス乗り場の交通規制の変更を交通管制システムに要請することによって、バス乗り場をタクシー乗り場に切り替えるので、タクシープールを増加し、多くのタクシーを短時間で出発させることができる。このため、駅構内や周辺の混雑を緩和し、利用者が早く目的地に到着できるようになる。

また、交通流制御システム１００が、タクシー事業者の管理システムに、近隣のタクシーを手配するように要請するので、周辺の道路の渋滞を引き起こすことなく、タクシーを配車することができる。

＜実施例２＞
次に、本発明の第２実施例について説明する。

第２実施例では、交通流制御システム１００が複数の情報を収集し、リアルタイムの情報及び／又は予め分かっている情報に基づいて、交通流を制御する対策を作成する。なお、第２実施例では、交通流制御システム１００が、運行制御システム３００のサブシステムとして位置付けられているが、運行制御システム３００が以下に説明する処理を実行してもよい。

なお、第２実施例では、前述した第１実施例と同じ構成及び処理には同じ符号を付し、それらの説明は省略する。

図１６は、第２実施例の基本的な処理のシーケンス図である。

まず、交通流制御システム１００は、基礎データを取得する（Ｆ０００１）。基礎データは、予め予定されているイベント（例えば、参加者が多い展示会やコンサート）の情報である。

次に、交通流制御システム１００は、運行制御システム３００から、リアルタイムの運行情報を取得し（Ｆ０００２）、取得した基礎データ及びリアルタイム情報を用いて交通流を算出する（Ｆ０００５）。この交通流の算出は、所定のタイミング（例えば、所定時間間隔）で繰り返し実行する。算出した交通流は、交通流制御システム１００のディスプレイ装置１０９に表示したり、Ｗｅｂサイトによって一般利用者に開示してもよい。

その後、所定の面積内に存在する人の数が所定の閾値を超えたかによって、算出された交通流にボトルネックが発生しているかを判定する（Ｆ０００６）。ボトルネックが発生していない場合、何も問題がないので、何もアクションをせず、通常運行を行う（Ｆ０００７）。

一方、例えば、ボトルネックが発生している場合や、ボトルネックの発生の予兆があり注意が必要な場合には、ボトルネックへの対策が必要であると判定し、インシデントモードに移行する。インシデントモードでは、インシデントの発生状況に応じて対策を作成する。具体的には、対策判断基準５１０を参照し、インシデントの状況（重大性、波及範囲及び緊急性）に応じて、取るべき対策を選択する。

その後、選択された対策を適用して交通流をシミュレーションし（Ｆ００１０）、対策案の内容とシミュレーションされた交通流を管理者に提示する。そして、管理者が対策を選択して、対策を行う箇所（駅、バス乗り場、待機場所など）を設定し（Ｆ００２０）、対策の実施を交通流制御システム１００に指示する（Ｆ００２１）。交通流制御システム１００は、接続されている他のシステムに対策の実施指示を送信し、対策を実施する（Ｆ００２２）。対策実施指示は、例えば、以下のものがある。
（１）臨時バスの増発の手配
（２）タクシー運行事業者への配車を手配
（３）バス乗り場をタクシー乗り場へ切り替え
（４）近隣の施設の利用を促すクーポンの発行
（５）待機利用者が興味を示す映像や商品案内を周辺のサイネージ装置へ配信

その後、リアルタイムの運行情報を取得し（Ｆ０００３）、状況を更新して（Ｆ００２３）、対策を継続する必要があるかを判定する（Ｆ００２４）。対策を継続する必要があれば、ステップＦ００１０に戻り、ステップＦ０００３で取得したリアルタイム情報を用いて、交通流を再度計算する。

一方、ボトルネックが解消しており、対策を終了してもよいと判断されれば、対策を徐々に緩和する（Ｆ００２５）。なお、直ちに対策を終了してもよい。

対策が完全に終了した後、通常モードに戻り、通常運行を行う（Ｆ０００７）。

図１７は、第２実施例のインシデントの状況に合わせた対策判断基準５１０の例を示す図である。

対策判断基準５１０は、インシデントの状況に合わせて取るべき対策を判断するために用いられる基準であり、交通流制御システム１００のメモリ１０２に格納される。対策判断基準５１０は、選択肢５１１、対策５１２、重大性５１３、波及範囲５１４及び緊急性５１７のフィールドを含む。また、波及範囲５１４は、場所５１５及び時間５１６のフィールドを含む。また、対策判断基準５１０は、具体的なインシデントを表す例５１８のフィールドを任意の項目として含んでもよい。

選択肢５１１は、選択される対策群の名称である。対策５１２は、選択される対策の識別子である。対策の識別子は、対策リスト５２０（図１８）に規定される。重大性５１３は、発生している又は発生が予想されるインシデントの重大性である。重大性５１３は、例えば、影響を受ける人の数、インシデントによる経済損失の額などによって算出することができる。波及範囲（場所）５１５は、インシデントの影響が広い範囲に波及するかを示す。波及範囲（時間）５１６は、インシデントの影響が長時間波及するかを示す。緊急性５１７は、インシデントに対して急いで対策をする必要があるかを示す。例えば、インシデントの影響を受け駅で待っている人の数が急速に増えて、混乱の発生が予想される場合、緊急性が高いと判断することができる。

図１８は、第２実施例の対策リスト５２０の例を示す図である。

対策リスト５２０には、インシデント発生時の対策が定義されており、交通流制御システム１００のメモリ１０２に格納される。

対策リスト５２０は、対策ＩＤ５２１、対策５２２、効果５２３及びコスト５２４のフィールドを含む。対策リスト５２０は、対策の具体的な内容を表す例５２５のフィールドを任意の項目として含んでもよい。

対策ＩＤ５２１は、対策を一意に識別するための識別情報である。対策ＩＤ５２１によって、対策が階層的に定義される。例えば、対策ＩＤ＝１の対策（バス停のモード切替）が指定された場合、対策ＩＤ＝１．１の対策（サイネージ装置の表示切替）と、対策ＩＤ＝１．２の対策（クーポン発行）と、対策ＩＤ＝１．３の対策（タクシー乗り入れ許可）とが行われる。

対策５２２は、対策の名称であり、当該対策の概要を示す。効果５２３は、当該対策の効果である。効果５２３は、インシデントの種類によって効果が異なる場合がある。コスト５２４は、当該対策のコストである。

図１９は、第２実施例において交通機関に障害が発生した時の具体的な処理の例を示す図である。

図１９に示す場合、ステップＦ０００２で取得したリアルタイム情報が、鉄道路線の障害で路線Ａの運行が停止しており復旧の目処がないことを示している。

このため、計算された交通流にボトルネックが発生しており、このインシデントは重大性が「大」きく、波及範囲（場所）が「広い」もので、波及範囲（時間）が「不明」であり、緊急性が「高」いものである。そして、対策判断基準５１０によると、可能な全てのリソースを投入して混乱を回避すべきインシデントであると判断できる（Ｆ００１０）。

そして、管理者は、対策を行う駅を設定し（Ｆ００２０）、対策の実施を交通流制御システム１００に指示する（Ｆ００２１）。交通流制御システム１００は、管理者から対策実施指示を受けると、接続されている他のシステムに対策の実施指示を送信し、対策を実施する（Ｆ００２２）。この例で実施される対策は、例えば、タクシー運行事業者の管理システム３７０にタクシーの配車を手配して、タクシー待ちの人を減らす。このため、バス運行事業者の管理システム３６０にバス乗り場のモードの切り替えを要求し、バス乗り場をタクシー乗り場に変更する。さらに、交通管制システム３５０にバスレーンの規制標識の切り替えを要求し、バスレーンにタクシーが進入できるように変更する。また、例えば、近隣の商業施設のクーポンを発行して、当該商業施設における待機を促す。

図２０は、第２実施例においてイベント発生時の処理の例を示す図である。

図２０に示す場合、イベントの開催が予定されている。例えば、ステップＦ０００１で取得した基礎データが、マリーナベイサンズにおける３万人が参加予定の人気歌手のコンサートである。このため、予め交通流のシミュレーションをし、さらに、Ｆ０００２でリアルタイムの情報を取得して交通流を算出する（Ｆ０００５）。

このような大規模イベントの場合、イベント終了時に交通流のボトルネックが発生する。そして、対策判断基準５１０を参照して、対策案を選択して、選択された対策にて交通流を計算する（Ｆ００１０）。このとき、バスの増発及びバス乗り場のモード切替が対策案として管理者に提示された。

そして、管理者は、対策の内容を選択し、対策を行うバス乗り場を設定し（Ｆ００２０）、対策の実施を交通流制御システム１００に指示する（Ｆ００２１）。交通流制御システム１００は、管理者から対策実施指示を受けると、接続されている他のシステムに対策の実施指示を送信し、対策を実施する（Ｆ００２２）。この例で実施される対策は、例えば、バス運行事業者の管理システム３６０に臨時バスを手配して、バス待ちの人を減らす。このため、バス運行事業者の管理システム３６０にバス乗り場のモードを切り替えを要求し、多くの臨時バスがバス乗り場から出発できるように変更する。さらに、交通管制システム３５０にバスレーンの規制標識の切り替えを要求し、多くのバスが出発できるようにバスレーンを変更する。

また、例えば、会場周辺のサイネージ装置の表示を切り替えて、当該歌手のプロモーションビデオを上映し、バスを待っている利用者を楽しませてもよい。また、会場周辺のサイネージ装置を切り替えて、当該歌手に関する商品の情報を提供しても、会場周辺に滞留する利用者に有用な情報を提供してもよい。さらに、近隣の商業施設のクーポンを発行して、コンサート終了後に、近隣の施設における滞留を促してもよい。さらに、特別なサービスとして、当該歌手との写真撮影会を実施し、バスに乗車する時刻を分散してもよい。

以上に説明したように、本発明の第２の実施例によると、様々なインシデントに対応して、交通流を制御するための対策を行うことができる。特に、予め予定されているイベントや、突発的に生じる交通障害などによって生じる混乱を避け、交通流を制御することができる。

なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、本実施例は鉄道に障害が発生した場合を説明したが、他の交通機関（バスなど）にも適用することができる。さらに、高速道路で発生する交通障害（事故や渋滞など）から、利用者を待機させたり、迂回させる場合にも適用することができる。

例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。

また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Solid State Drive）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

Claims (10)

1. 交通機関の利用者に情報を提供する交通流制御システムであって、
   プログラムを実行するプロセッサと、前記プロセッサがアクセス可能なメモリと、前記プロセッサに接続される通信インターフェースとを備え、
   利用者の待機場所を選択するための条件が記録される待機条件を前記メモリに保持し、
   前記プロセッサは、
   交通機関に発生した障害の情報を受信した場合、前記待機条件を参照して、利用者に適する待機場所を選択し、
   前記選択された待機場所の情報を前記利用者の端末に送信することによって利用者の待機を促し、
   交通機関に発生した障害の回復の情報を受信した場合、利用者の待機場所から駅までの所要時間に応じて、前記障害の回復の情報を送信する時刻を決定し、
   前記決定された時刻に前記障害の回復の情報を前記利用者の端末に通知することを特徴とする交通流制御システム。
2. 請求項１に記載の交通流制御システムであって、
   前記待機条件は、交通機関の障害の回復時の利用者の移動の形態の情報を含み、
   前記プロセッサは、利用者が混雑を回避した移動を望む場合、交通機関の障害の回復から所定時間が経過した後に前記障害の回復の情報を送信することを特徴とする交通流制御システム。
3. 請求項１に記載の交通流制御システムであって、
   前記待機条件は、利用者が入力した移動の緊急度、待機場所の種別、及び待機場所に備わる設備の条件の少なくとも一つを含み、
   前記プロセッサは、前記緊急度、前記待機場所の種別及び前記設備の条件の少なくとも一つに従って、利用者に適する待機場所を選択することを特徴とする交通流制御システム。
4. 請求項３に記載の交通流制御システムであって、
   前記プロセッサは、前記待機条件を参照して、緊急度が低い利用者に待機場所を選択することを特徴とする交通流制御システム。
5. 請求項１に記載の交通流制御システムであって、
   前記プロセッサは、
   前記障害が発生した区間が他の交通機関によって移動可能かを判定し、
   当該区間がバスによって移動可能であり、かつ、同一方向に移動する人が所定数以上である場合、増発バスを手配し、
   当該区間がバスによって移動不可能であり、かつ、タクシーを待っている人が所定数以上である場合、タクシーを手配することを特徴とする交通流制御システム。
6. 請求項５に記載の交通流制御システムであって、
   前記プロセッサは、タクシーの進入を可能にするようにバス乗り場の交通規制の変更を交通管制システムに要請することによって、バス乗り場をタクシー乗り場に切り替えることを特徴とする交通流制御システム。
7. 請求項６に記載の交通流制御システムであって、
   前記プロセッサは、タクシー事業者の管理システムに、近隣のタクシーを手配するように要請することを特徴とする交通流制御システム。
8. 請求項１に記載の交通流制御システムであって、
   前記利用者の端末に送信される待機場所の情報は、利用者が当該待機場所で受けられる特典の情報を含むことを特徴とする交通流制御システム。
9. 請求項８に記載の交通流制御システムであって、
   前記プロセッサは、利用者が前記待機場所で特典を利用した場合、当該待機場所への課金情報を生成することを特徴とする交通流制御システム。
10. 交通機関の利用者に情報を提供する情報提供システムによる交通流制御方法であって、
    前記情報提供システムは、プログラムを実行するプロセッサと、前記プロセッサがアクセス可能なメモリと、前記プロセッサに接続される通信インターフェースとを有し、
    前記メモリは、利用者の待機場所を選択するための条件が記録される待機条件を保持し、
    前記方法は、
    前記プロセッサが、交通機関に発生した障害の情報を受信した場合、前記待機条件を参照して、利用者に適する待機場所を選択し、
    前記プロセッサが、前記選択された待機場所の情報を前記利用者の端末に送信することによって利用者の待機を促し、
    前記プロセッサが、交通機関に発生した障害の回復の情報を受信した場合、利用者の待機場所から駅までの所要時間に応じて、前記障害の回復の情報を送信する時刻を決定し、
    前記プロセッサが、前記決定された時刻に前記障害の回復の情報を前記利用者の端末に通知することを特徴とする交通流制御方法。