JP2009116554A - 交通情報通知システム、交通情報受信端末装置及びプログラム - Google Patents

Abstract

【課題】交通機関の実際の利用状況から交通情報の通知先を特定できるようにする。
【解決手段】交通情報通知システムにおける管理サーバ１は、交通機関の利用者毎にその利用履歴が記憶されている状態において、利用履歴を分析して利用者毎に交通機関の利用状況を求めると共に、この利用状況を交通情報の通知先を特定するための通知条件として利用者毎に登録しておき、交通情報を通知する場合に、この交通情報の内容からそれに該当する通知条件を満たす利用者を特定し、インターネット４、移動体通信網５を介してその利用者端末６に通知する。
【選択図】 図１

Description

この発明は、交通機関に関する交通情報をその利用者側の端末装置に通知する交通情報通知システム、交通情報をその利用者宛に配信する管理サーバから交通情報を受信して出力する交通情報受信端末装置及びプログラムに関する。

従来、交通機関の事故などでその運行が遅れた場合にその旨を案内する遅延情報あるいは交通機関に関する緊急連絡や時刻表の変更（ダイヤ変更）などの交通情報をその利用者の端末宛にメール通知する交通情報通知サービスにおいては、定期券情報を元に路線、区間、時間帯などを特定し、これらの利用状況に関連する交通情報をその利用者宛に送信するようにした技術が知られている（特許文献１参照）。
特開２００４−６２５１６号公報

しかしながら、上述した先行技術では定期券情報を元に利用状況を特定するようにしているため、定期券の利用者に向けた通知サービスに限られるほか、定期券情報から利用状況を求める結果、利用状況が固定されていまい、定期券を利用しない休日などでは通知サービスを享受することができなくなってしまう。

この発明の課題は、交通機関の実際の利用状況から交通情報の通知先を特定できるようにすることである。

請求項１記載の発明は、交通機関に関する交通情報をその利用者側の端末装置に通知する交通情報通知システムであって、交通機関を利用する利用者毎にその利用履歴を記憶する履歴記憶手段と、前記利用履歴を分析して利用者毎に交通機関の利用状況を求める分析手段と、この分析手段によって得られた利用者毎の利用状況を前記交通情報の通知先を特定するための通知条件として利用者毎に登録する登録手段と、前記交通情報を通知する場合に、当該交通情報の内容からそれに該当する前記通知条件を満たす利用者を特定してその利用者側の端末装置に通知する通知手段と、を具備したことを特徴とする。
更に、コンピュータに対して、上述した請求項１記載の発明に示した主要機能を実現させるためのプログラムを提供する（請求項１１記載の発明）。

なお、上述した請求項１記載の発明は次のようなものであってもよい。
前記利用履歴は、交通機関の利用時にその利用者が提示した記憶媒体の記録内容とその利用時刻を含む情報である（請求項２記載の発明）。

前記分析手段は、前記利用履歴を分析することによって利用路線、利用区間、利用時間帯を利用状況として求め、前記登録手段は、前記利用状況を通知条件として登録する（請求項３記載の発明）。

前記利用履歴を分析して利用者毎に交通機関の利用状況を求めて通知条件として登録する動作を定期的に行ってその登録内容を更新する更新手段を更に設けた（請求項４記載の発明）。

前記交通情報の内容と前記通知条件とから当該交通情報が利用者に対してどのように関連しているかの関連度を判断する関連度判断手段を更に設け、
前記通知手段は、前記関連度判断手段によって判断された関連度に応じて前記交通情報の通知を制御する（請求項５記載の発明）。
この請求項５記載の発明において、前記通知手段は、交通情報を通知する際に、前記関連度判断手段によって判断された関連度を含めて通知するようにしてもよい（請求項６記載の発明）。

請求項７記載の発明は、交通機関に関する交通情報をその利用者宛に配信する管理サーバから交通情報を受信して出力する交通情報受信端末装置であって、交通機関の自己の利用履歴を取得する取得手段と、この取得手段によって得られた利用履歴を記憶する履歴記憶手段と、前記利用履歴を分析して交通機関の利用状況を求める分析手段と、この分析手段によって得られた利用状況を前記交通情報の通知先を特定するための通知条件として前記管理サーバに送信する送信手段と、前記管理サーバから前記通知条件を満たす交通情報を受信して出力する出力手段と、を具備したことを特徴とする。
更に、コンピュータに対して、上述した請求項７記載の発明に示した主要機能を実現させるためのプログラムを提供する（請求項１２記載の発明）。

なお、上述した請求項７記載の発明は次のようなものであってもよい。
前記分析手段は、前記利用履歴を分析することによって利用路線、利用区間、利用時間帯を利用状況として求め、前記送信手段は、前記利用状況を通知条件として前記管理サーバに送信する（請求項８記載の発明）。

前記出力手段は、前記管理サーバから前記通知条件を満たす交通情報を受信すると共に、当該交通情報が利用者に対してどのように関連しているかの関連度を受信した場合に、当該交通情報を関連度に応じて異なる方法で報知する（請求項９記載の発明）。

前記利用履歴を分析して利用者毎に交通機関の利用状況を求めて通知条件として前記管理サーバに送信する動作を定期的に行って当該管理サーバ側の通知条件を更新する更新手段を更に設けた（請求項１０記載の発明）。

この発明によれば、交通機関の実際の利用状況から交通情報の通知先を特定することができるほか、定期券利用者に限らず、定期券を利用しない休日などでも交通情報を必要とする利用者に通知することができる。

（実施形態１）
以下、図１〜図１０を参照して本発明の第１実施形態を説明する。
図１は、交通情報通知システムを示したブロック図である。
この交通情報通知システムは、電車の事故、運行遅延などの発生に応じてその交通機関に関する交通情報をその利用者側の端末に通知する交通情報通知サービスを提供するようにした広域通信システムであり、その通知サービスを運用実施する会社側の管理サーバ１には、後述する各交通機関端末２が専用回線網３などを介して接続されているほか、インターネット４、移動体通信網（無線通信網）５を介して各利用者端末（携帯電話機）６が接続されている。

管理サーバ１は、例えば、交通機関の事故、運行遅延、緊急連絡、時刻表などの交通情報を利用者端末６側に配信するサービスを行うためのサーバ装置であり、データベースサーバ機能、メールサーバ機能など、各種のサーバ機能が備えられている。交通機関端末２は、各駅あるいは地域毎に設置されている交通機関側の端末装置であり、事故、運行遅延などが発生した場合に、それを緊急報知するための交通情報を管理サーバ１に送信したり、自己が管轄する各自動改札機から入出場記録を収集し、入退場記録を利用履歴として管理サーバ１に送信したりする。管理サーバ１は、例えば、交通機関端末２から事故、運行遅延などを報知する交通情報を受信すると、事故、運行遅延などが発生した路線、原因、発生場所、発生時刻、遅れ時間などを交通情報データベースＤＢ１に記憶させる。また、管理サーバ１は、各交通機関端末２から入退場記録（利用履歴）を受信すると、これを利用履歴データベースＤＢ２に記憶させる。

管理サーバ１側には、交通情報データベースＤＢ１、利用履歴データベースＤＢ２のほか、交通機関毎に路線別時刻表など、交通機関に関する各種の情報を記憶する交通機関データベースＤＢ３と、後述する登録者情報データベースＤＢ４などが備えられている。利用者端末６は、交通機関を利用する利用者所持の携帯電話機であり、乗車券機能や定期券機能を構成する非接触ＩＣカード機能が搭載され、交通機関（電車）の駅改札口に設置されている改札ゲート装置（自動改札機）７を通過した際に、この改札ゲート装置７との間で電波の送受信を行うことによって乗車券処理あるいは定期券処理を実行するようにしている。

図２は、管理サーバ１の基本的な構成要素を示したブロック図である。
管理サーバ１は、交通情報通知サービスを運用実施する会社側に設置されたものであり、ＣＰＵ１１は、この管理サーバ１の全体動作を制御する中央演算処理装置である。記憶部１２は、プログラム領域とデータ領域とを有し、そのプログラム領域には、後述する図６〜図８に示す動作手順に応じて本実施形態を実現するためのプログラムが格納されている。メモリ１３は、ワーク領域を有する内部メモリであり、必要に応じてメモリ１３内の各種のデータは、記憶部１２にセーブされる。操作部１４は、データ入力、コマンド入力などを行うもので、この操作部１４から入力されたデータは高精細液晶あるいは有機ＥＬなどを使用した表示部１５に表示される。通信部１６は、広域通信網（専用回線網３、インターネット４）に接続されるもので、交通機関端末２から交通情報を受信したり、利用者毎の利用履歴を受信したりするほか、利用者端末６に対して運行遅延などを案内する交通情報を送信したりする。

図３は、利用者端末６の基本的な構成要素を示したブロック図である。
利用者端末６は、通話機能、電子メール機能、インターネット接続機能（Ｗｅｂアクセス機能）、データ通信機能、非接触ＩＣカード機能などを備えたもので、ＣＰＵ６１は、この利用者端末６の全体動作を制御する中央演算処理装置である。記憶部６２は、プログラム領域とデータ領域とを有し、そのプログラム領域には、各種のプログラムが格納されている。メモリ６３は、ワーク領域を有する内部メモリであり、必要に応じてメモリ６３内の各種のデータは、記憶部６２にセーブされる。無線通信部６４は、無線部、ベースバンド部、多重分離部などを備え、例えば、通話機能、電子メール機能、データ通信機能などの動作時に、最寄りの基地局との間でデータの送受信を行うもので、通話機能の動作時にはベースバンド部の受信側から信号を取り込んで受信ベースバンド信号に復調したのち、音声信号処理部６５を介して送話スピーカＳＰから音声出力させ、また、受話マイクＭＣからの入力音声データを音声信号処理部５から取り込み、送信ベースバンド信号に符号化したのち、ベースバンド部の送信側に与えてアンテナから発信出力させる。

操作部６６は、データ入力、コマンド入力などを行うもので、この操作部６６から入力されたデータは高精細液晶あるいは有機ＥＬなどを使用した表示部６７に表示される。非接触ＩＣカード処理部６８は、電子マネー利用機能のほか、乗車券機能や定期券機能を構成するもので、メモリ部、コイルアンテナ部を備え、受信電波によって電磁誘導された起電力を動作電力として駆動する。そして、非接触ＩＣカード処理部６８は、交通機関（電車）の駅改札口に設置されている改札ゲート装置７を通過した際に、改札ゲート装置７との間で乗車券情報を送受信したり、定期券情報を送受信したりする。

図４は、利用履歴データベースＤＢ２を説明するための図である。
利用履歴データベースＤＢ２は、駅の改札ゲート装置７を通過した入退場記録を交通機関端末２から取得した場合に、この入退場記録を利用履歴として記憶するもので、「利用者識別情報」、「交通機関情報」、「駅名情報」、「入出場情報」、「時刻情報」の各項目を有している。「利用者識別情報」は、利用者を特定する情報であり、利用者が改札を通過する際に提示した定期券（非接触ＩＣカード）から読み取った定期券情報を含む利用者識別情報“ＴＫ＊＊〜ａａａａ”と、定期券情報を含まない利用者識別情報、言い換えれば、利用者が改札を通過する際に提示した乗車券（非接触ＩＣカード）から読み取った乗車券情報を含む利用者識別情報“ＩＣ＊＊〜ｉｉｉｉ”が記憶され項目である。

「交通機関情報」は利用した交通機関名が記憶される項目であり、「駅名情報」は利用した駅名と共に自動改札機の識別番号が記憶される項目である。「入出場情報」は入場（乗車）か退場（降車）かを示す情報が記憶される項目で、「時刻情報」は利用時刻が記憶される項目であり、図示の“０７０９２８０８２０１５”は、“２００７年９月２８日８時２０分１５秒”を示している。なお、図示した利用履歴データベースＤＢ２の内容は、「利用者識別情報」をキーとして適宜ソートしたものであるが、ゲート通過順に記憶するようにしてもよい。また、利用履歴データベースＤＢ２の大容量化を防ぐために、例えば、最近１０週間あるいは６ヶ月間のように最近の利用履歴を古い情報に代わって上書きするようにしてもよい。

図５は、登録者情報データベースＤＢ４を説明するための図である。
登録者情報データベースＤＢ４は、交通機関利用者のうち交通情報通知サービスを受けるために予め登録された会員（サービス登録者）に関する情報を記憶するもので、「登録者ＩＤ」、「氏名情報」、「定期券識別情報」、「ＩＣカード識別情報」、「通知先情報」、「利用履歴情報」、「通知条件」、「更新期間」の各項目を有している。「登録者ＩＤ」、「氏名情報」は、サービス登録者を特定する登録者識別情報が記憶される項目であり、「登録者ＩＤ」は、その先頭から割り振られた「０００００１」から始まる一連番号が記憶される項目である。

「定期券識別情報」、「ＩＣカード識別情報」は、定期券（非接触ＩＣカード）を特定するための情報が記憶される項目で、上述した「利用者識別情報」と同様の内容となっている。なお、定期券所持の登録者には「定期券識別情報」及び「ＩＣカード識別情報」が設定されるが、定期券不所持の登録者には「ＩＣカード識別情報」のみが設定される。「通知先情報」は、交通情報を登録者に通知する際の通知先（連絡先）情報が記憶される項目で、メールアドレスに限らず、電話番号などであってもよい。

「利用履歴情報」は、利用履歴データベースＤＢ２から抽出した登録者対応の利用履歴が記憶される項目で、例えば、最近１０週間の利用履歴を分析することによって得られた当該登録者の利用状況を示している。すなわち、図４の例では、“ＴＫ＊＊〜ａａａａ”で示される利用者（登録者）は、朝の時間帯はＡ駅（池袋駅）からＢ駅（新宿駅）の方向の路線（山手線内回り）を利用し、夜の時間帯はＢ駅（新宿駅）からＡ駅（池袋駅）の方向の路線（山手線外回り）を利用していることが分かるが、この利用状況が利用履歴として設定される。なお、路線とは上り、下り、内回り、外回りのように進行方向をも含むことを意味している（以下、同様）。「通知条件」は運行遅延などの交通情報を利用者端末６にメール送信して通知するための通知条件が記憶される項目であり、「利用履歴情報」に応じて求められた通知条件として、例えば、“利用路線とその隣接関係”、“利用区間とその隣接関係”、“利用時間”などが設定される。

ここで、“利用路線とその隣接関係”とは、例えば、路線ＸのＡ駅付近で発生した事故によって路線Ｘに運行遅延が発生した場合に、このＡ駅を通る他の路線Ｙ、Ｚが利用路線Ｘと隣接関係にある路線（事故の影響を受ける可能性が高い路線）となる。また、“利用区間とその隣接関係”とは、Ａ駅付近で事故が発生した場合に、このＡ駅の前後に隣接する区間が事故の影響を受ける区間となる。また、“利用時間”は、一般的な時間帯に限らず、曜日、平日あるいは休日を含むもので、例えば、平日（月曜日〜金曜日）の８時００分〜１０時００分、日曜日の１１時００分〜１２時３０分などが利用時間として設定される。また、「更新期間」は、「通知条件」の内容を更新するための更新タイミングが記憶される項目で、図示の例では１ヶ月間隔で「通知条件」を更新すべきことが設定されている。

次に、第１実施形態の交通情報通知システムにおける管理サーバ１の動作概念を図６〜図８に示すフローチャートを参照して説明する。ここで、これらのフローチャートに記述されている各機能は、読み取り可能なプログラムコードの形態で格納されており、このプログラムコードにしたがった動作が逐次実行される。また、伝送媒体を介して伝送されてきた上述のプログラムコードに従った動作を逐次実行することもできる。このことは後述する他の実施形態においても同様であり、記録媒体のほかに、伝送媒体を介して外部供給されたプログラム／データを利用してこの実施形態特有の動作を実行することもできる。なお、図６〜図８は、管理サーバ１の全体動作のうち、本実施形態の特徴部分の動作概要を示したフローチャートであり、この図６〜図８のフローから抜けた際には、全体動作のフロー（図示省略）に戻る。

図６は、管理サーバ１において定期的（例えば、１日１回）に実行開始される利用履歴記憶処理・通知条件設定処理を示したフローチャートである。
先ず、管理サーバ１は、各駅の改札ゲート装置７を通過した各利用者の入退場記録（利用状況）を各交通機関端末２からそれぞれ取得する（ステップＡ１）。この場合、入退場記録は、改札ゲート装置７で利用者が提示した非接触ＩＣカード（定期券あるいは乗車券）から読み取った定期券情報あるいは乗車券情報に現在時刻（利用時刻）、駅名、改札番号などが付加された構成で、交通機関端末２によって収集管理されており、管理サーバ１からの送信要求を受け取った際に、交通機関端末２は、この入退場記録を管理サーバ１に送信する。管理サーバ１は、各交通機関端末２から受信取得した入退場記録を利用履歴データベースＤＢ２に利用履歴として格納する（ステップＡ２）。その際、利用履歴データベースＤＢ２の記憶データ量がフル状態であれば、その先頭領域に記憶されている古い利用履歴に代わって新たな入退場記録（利用状況）を上書き保存するようにしている。

そして、登録者情報データベースＤＢ４の各「登録者ＩＤ」をその先頭から順次指定するための指定レジスタｉにその初期値“１”をセットしたのち（ステップＡ３）、この指定レジスタｉに基づいて登録者情報データベースＤＢ４を検索し、指定レジスタｉの値に対応する「登録者ＩＤ」を指定すると共に、この「登録者ＩＤ」に対応する情報として「更新期間」を読み出す（ステップＡ４）。そして、前回の更新時から現時点までの経過期間を求め、この経過期間と「更新期間」とを比較することによって「更新期間」に達したかを調べる（ステップＡ５）。なお、指定レジスタｉの値に対応する「登録者ＩＤ」を以下、「登録者ｉ」と呼称するものとする。

ここで、「更新期間」に達していなければ（ステップＡ５でＮＯ）、指定レジスタｉに“１”を加算してその値を更新したのち（ステップＡ８）、その値は「登録者ＩＤ」の最大値（サービス登録者の人数）Ｎを越えたかを調べるが（ステップＡ９）、いま、指定レジスタｉの値を“２”に更新した場合であり、最大値Ｎ未満であるから（ステップＡ９でＮＯ）、上述のステップＡ４に戻り、登録者ｉの情報として、その「更新期間」を読み出し、以下、指定レジスタｉの値が「登録者ＩＤ」の最大値Ｎを越えるまで上述の動作を繰り返す。これによって「更新期間」に達すると（ステップＡ５でＹＥＳ）、その登録者ｉの「利用履歴情報」及び「通知条件」を利用履歴データベースＤＢ２の内容に基づいて更新する処理に移る（ステップＡ６、Ａ７）。

すなわち、「更新期間」に達した登録者ｉの「定期券識別情報」、「ＩＣカード識別情報」を登録者情報データベースＤＢ４から読み出し、この「定期券識別情報」、「ＩＣカード識別情報」に基づいて利用履歴データベースＤＢ２の「利用者識別情報」を検索したのち、この「利用者識別情報」に対応する各利用履歴として「駅情報」、「入出場情報」、「時刻情報」をそれぞれ抽出して整理し、それらを登録者情報データベースＤＢ４の「利用履歴情報」の項目に設定することで「利用履歴情報」の内容を更新する（ステップＡ６）。そして、この「利用履歴情報」に応じて利用路線とその隣接関係、利用区間とその隣接関係、利用時間などを通知条件として求め、「利用履歴情報」の「通知条件」の項目に設定することで「通知条件」の内容を更新する（ステップＡ７）。

図９は、「利用履歴情報」から「通知条件」を設定する場合を具体的に示したものである。すなわち、あるサービス登録者の最近１０週間分の利用履歴を分析して、曜日毎にその利用頻度を集計したもので、図９（１）、（２）は、時間帯「８時００分〜１０時００分」、「１８時００分〜２０時００分」別に、Ａ駅（池袋駅）からＢ駅（新宿駅）の方向の路線を利用している利用頻度を曜日毎に集計した結果であり、月曜日から金曜日において「８時００分〜１０時００分」の利用頻度が高いことを示している。

図９（３）、（４）は、時間帯「８時００分〜１０時００分」、「１８時００分〜２０時００分」別に、Ｂ駅からＡ駅の方向の路線を利用している利用頻度を曜日毎に集計した結果であり、月曜日から金曜日において「１８時００分〜２０時００分」の利用頻度が高いことを示している。これによって平日の時間帯「８時００分〜１０時００分」でＡ駅からＢ駅の方向の路線を利用していること、平日の時間帯「１８時００分〜２０時００分」にＢ駅からＡ駅の方向の路線を利用していることが分かる。このような分析結果に基づいて「通知条件」を設定するが、その際、利用路線とその隣接関係、利用区間とその隣接関係、利用時間などとして設定するようにしている。

図７は、管理サーバ１において交通情報通知処理の全体概要を示したフローチャートである。
先ず、管理サーバ１は、事故、運行遅延などの発生に応じて交通機関端末２から交通情報を受信すると（ステップＢ１でＹＥＳ）、事故、運行遅延などが発生した路線、原因、発生場所、発生時刻、遅れ時間などを交通情報データベースＤＢ１に格納すると共に（ステップＢ２）、この交通情報に基づいてサービス登録者に対して通知する通知情報を作成する（ステップＢ３）。図１０は、受信した交通情報に基づいて作成された通知情報の内容を例示したもので、事故の発生状況を示す案内、運転を見合わせている旨の案内、続報、復旧の見通しなどをインターネットに接続して確認すべき旨の案内を含む内容となっている。そして、事故、運行遅延などの発生によって影響を受けるサービス登録者を通知対象者として選択する処理を実行する（ステップＢ４）。

図８は、通知対象者選択処理（図７のステップＢ４）を詳述するためのフローチャートである。
先ず、管理サーバ１は、受信した交通情報に基づいて作成した通知情報を解釈して事故の発生状況を分析し、例えば、事故、運行遅延などが発生した路線、発生時刻、発生場所などを特定する（ステップＣ１）。そして、登録者情報データベースＤＢ４の各「登録者ＩＤ」をその先頭から順次指定するための指定レジスタｉにその初期値“１”をセットしたのち（ステップＣ２）、この指定レジスタｉに基づいて登録者情報データベースＤＢ４を検索して登録者ｉを指定すると共に、この登録者ｉに対応する情報として「通知条件」を読み出して、通知情報の分析結果と対比する（ステップＣ３）。その結果、通知情報は「通知条件」に合致するかを調べる（ステップＣ４〜Ｃ６）。

すなわち、事故、運行遅延などが発生した路線又はその隣接路線が「通知条件」に合致するかを調べる（ステップＣ４）。例えば、路線ＸのＡ駅付近で発生した事故で路線Ｘに運行遅延が発生した場合に、この路線Ｘあるいは路線Ｘと隣接関係にある路線Ｙ、Ｚが「通知条件」として設定されていれば、「通知条件」に合致すると判断される。次に、事故、運行遅延などが発生した区間とその隣接関係が「通知条件」に合致するかを調べる（ステップＣ５）。例えば、Ａ駅付近で事故が発生した場合に、このＡ駅の前後に隣接する区間が「通知条件」として設定されていれば、「通知条件」に合致すると判断される。次に、事故、運行遅延などが発生した時刻が「通知条件」に合致するかを調べる（ステップＣ６）。例えば、「通知条件」としての利用時間帯が“平日（月曜日〜金曜日）の８時００分〜１０時００分”である場合に、事故、運行遅延などが発生した時刻が平日の８時３０分であれば、「通知条件」に合致すると判断される。

その結果、運行遅延などの発生路線、発生区間、発生時刻が全て「通知条件」に合致する場合には（ステップＣ６でＹＥＳ）、登録者ｉを通知対象者として選択したのち（ステップＣ７）、次の登録者ｉを指定するためにステップＣ８に移り、指定レジスタｉに“１”を加算してその値を更新するが、発生路線、発生区間、発生時刻の何れか一つでも「通知条件」に合致していなければ（ステップＣ４〜Ｃ６の何れかでＮＯ）、この登録者ｉを通知対象者から外すためにステップＣ８に移り、指定レジスタｉの値を更新する。そして、更新後の値は「登録者ＩＤ」の最大値（サービス登録者の人数）Ｎを越えたかを調べるが（ステップＣ９）、いま、指定レジスタｉの値を“２”に更新した場合であり、最大値Ｎ未満であるから（ステップＣ９でＮＯ）、上述のステップＣ３に戻り、登録者ｉに対応する「更新期間」を読み出し、指定レジスタｉの値が「登録者ＩＤ」の最大値Ｎを越えるまで以下、上述の動作を繰り返す。

このような通知対象者選択処理が終わると、この通知対象者に対して通知情報を送信する処理に移る（図７のステップＢ５）。すなわち、通知対象者に対応する「通知先情報」を登録者情報データベースＤＢ４から読み出し、この通知先に対して図１０のような通知情報を送信する。この場合、「通知先情報」がメールアドレスであれば、通知情報を電子メールとして、各通知対象の利用者端末６に対して一斉に同報通知するようにしている。

以上のように、この第１実施形態の交通情報通知システムにおける管理サーバ１は、交通機関を利用する利用者毎にその利用履歴が記憶されている状態において、利用履歴を分析して利用者毎に交通機関の利用状況を求めると共に、この利用状況を通知条件として利用者毎に登録しておき、交通情報を通知する場合に、この交通情報の内容からそれに該当する通知条件を満たす利用者を特定してその利用者端末６に通知するようにしたので、交通機関の実際の利用状況から交通情報の通知先を特定することができるほか、通知条件を実際の利用状況から動的に変化させることができ、定期券利用者に限らず、定期券を利用しない休日などでも交通情報を必要とする利用者に対して通知することが可能となる。

利用履歴は、利用者が改札で提示した非接触ＩＣカード（定期券あるいは乗車券）から定期券情報あるいは乗車券情報とその利用時刻などを含む入退場記録であり、この入退場記録を交通機関端末２から取得し、この入退場記録を利用履歴データベースＤＢ２に利用履歴として格納するようにしたので、利用履歴を入力する操作を行うことなく、利用履歴を自動取得することができる。

管理サーバ１は、利用履歴を分析して利用路線、利用区間、利用時間帯を利用状況として求め、この利用状況を通知条件として登録するようにしたので、利用者にとって必要な交通情報のみを享受することができる。

管理サーバ１は、利用履歴を分析して利用者毎に交通機関の利用状況を求めて通知条件として登録する動作を定期的に行ってその登録内容（通知条件）を更新するようにしたので、最新の利用状況に応じて通知条件を動的に変化させることができ、実情に即したものとなる。

なお、上述した第１実施形態においては、運行遅延などの発生路線、発生区間、発生時刻の全てが「通知条件」に合致した場合に、その登録者を通知対象者として選択するようにしたが、例えば、発生路線と発生時刻が「通知条件」に合致した場合に、その登録者を通知対象者として選択するようにしてもよく、また、発生路線、発生区間が「通知条件」に合致した場合に、その登録者を通知対象者として選択するようにしてもよい。

（実施形態２）
以下、この発明の第２実施形態について図１１及び図１２を参照して説明する。
なお、上述した第１実施形態においては、事故、運行遅延などの発生路線、発生区間、発生時刻の全てが「通知条件」に合致する利用者に対して通知情報を送信するようにしたが、この第２実施形態においては、路線、区間、時刻の項目のうち、その何れかの項目が「通知条件」に合致するかに応じて利用者への影響度（関連度）を求め、この影響度を含めて通知情報を送信するようにしたものである。

すなわち、通知情報の内容と通知条件とから運行遅延などが利用者に対してどのように影響（関連）しているかの影響度（関連度）を利用者毎に判断し、運行遅延などの影響を受ける利用者に対して当該影響度を付加した通知情報を送信するようにしたものである。
ここで、両実施形態において基本的あるいは名称的に同一のものは、同一符号を付して示し、その説明を省略すると共に、以下、第２実施形態の特徴部分を中心に説明するものとする。

図１１は、第２実施形態における通知対象者選択処理を詳述するためのフローチャートである。なお、図６で示した利用履歴記憶処理・通知条件設定処理と図７で示した交通情報通知処理は、第２実施形態においても基本的に同様であるため、その説明を省略するものとする。
先ず、管理サーバ１は、運行遅延などの発生に応じて受信した交通情報に基づいて作成した通知情報を解釈して事故の発生状況を分析して、例えば、事故、運行遅延などの発生路線、発生時刻、発生場所などの各項目を特定する（ステップＤ１）。

そして、登録者情報データベースＤＢ４の各「登録者ＩＤ」をその先頭から順次指定するために指定レジスタｉにその初期値“１”をセットしたのち（ステップＤ２）、この指定レジスタｉに基づいて登録者情報データベースＤＢ４を検索して登録者ｉを指定すると共に、この登録者ｉに対応する情報として、「通知条件」を読み出し、発生路線、発生時刻、発生場所の各項目に対応する分析結果と対比する（ステップＤ３）。その際、各項目に重み付けした評価関数により定量化した相関度を算出したのち（ステップＤ４）、登録者ｉの「通知条件」との相関度を調べる（ステップＤ５）。

その結果、相関度が“強”であれば、登録者ｉを影響度大（Ａ）の通知対象者として選択し（ステップＤ６）、相関度が“中”であれば、登録者ｉを影響度中（Ｂ）の通知対象者として選択し（ステップＤ７）、相関度が“弱”であれば、登録者ｉを影響度弱（Ｃ）の通知対象者として選択する（ステップＤ８）。そして、次の登録者ｉを指定するためにステップＤ９に移り、指定レジスタｉに“１”を加算してその値を更新するが、相関度が“最弱”であれば、登録者ｉを通知対象者から外すためにステップＤ９に移り、指定レジスタｉの値を更新する。

例えば、０７年１０月２０日（土曜日）、０８時１０分ごろに山手線内回りの池袋付近で信号機が故障した場合の影響で、現在山手線の内回りの運転を見合わせている場合に、事故発生時間帯に山手線の内回りの利用している登録者は、影響度大（Ａ）の通知対象者として選択される。また、事故発生時間帯に山手線を利用しているが、その外回りを利用している登録者にあっては、影響度中（Ｂ）の通知対象者として選択される。また、事故発生時間帯に西○池袋線の池袋方面に向かう上り電車を利用している登録者は、影響度中（Ｂ）の通知対象者として選択されるが、事故発生時間帯に西○池袋線の飯能方面に向かう下りの電車を利用している登録者にあっては、影響度弱（Ｃ）の通知対象者として選択される。

一方、山手線の内回りを利用し、事故発生時間帯（土曜日）でも利用している登録者は、影響度大（Ａ）の通知対象者として選択される。また、山手線の内回りを利用しているが、事故発生時間帯（土曜日）には利用していない登録者にあっては、影響度弱（Ｃ）の通知対象者として選択される。なお、地震などの影響で全線が停止したような場合には、それらの路線を利用している全登録者が通知対象者として選択される。

そして、指定レジスタｉの値を更新したのちは（ステップＤ９）、その値は「登録者ＩＤ」の最大値（サービス登録者の人数）Ｎを越えたかを調べるが（ステップＤ１０）、いま、指定レジスタｉの値を“２”に更新した場合であり、最大値Ｎ未満であるから（ステップＤ１０でＮＯ）、上述のステップＤ３に戻り、登録者ｉの「通知条件」を読み出し、指定レジスタｉの値が「登録者ＩＤ」の最大値Ｎを越えるまで以下、上述の動作を繰り返す。

このようにして図１１の通知対象者選択処理が終わると、上述した第１実施形態と同様に、各通知対象者に対して通知情報を送信する処理が行われる。すなわち、通知対象者に対応する「通知先情報」を登録者情報データベースＤＢ４から読み出し、この通知先に対して通知情報を影響度と共に送信するが、その際、「通知先情報」がメールアドレスであれば、影響度を含む通知情報を電子メールとして、各通知対象の利用者端末６に対して一斉に同報通知する。図１２は、利用者端末６での受信画面を例示した図で、図１２（１）は、影響度強（Ａ）の登録者の受信画面、（２）は、影響度中（Ｂ）の登録者の受信画面、（３）は、影響度弱（Ｃ）の登録者の受信画面を示し、各受信画面には、交通情報の案内と共に、影響度が案内される。なお、影響度強（Ａ）の登録者の受信画面には、例えば、「他の路線を利用してください」といった付加的な情報も案内するようにしてもよい。また、影響度中（Ｂ）の登録者の受信画面には、「帰りの時間帯まで復旧しない場合に影響を受けてしまいます」といった付加的な情報も案内するようにしてもよい。

以上のように、この第２実施形態においては、通知情報の内容と通知条件とから運行遅延などが利用者に対してどのように影響しているかの影響度を登録者毎に判断し、この影響度に応じて通知情報の送信を制御するようにしたので、運行遅延などの影響度に応じた通知が可能となる。

また、運行遅延などの影響を受ける利用者に対してその影響度を含めた通知情報を送信するようにしたので、登録者にあっては自分がどの位の影響を受けるかを知ることができ、それに対する迅速な対応が可能となる。

なお、上述した第２実施形態においては、影響度大（Ａ）、影響度中（Ｂ）、影響度弱（Ｃ）に分けたが、４以上のレベルに区分してもよく、また、通知情報を送信する場合に、影響度に応じてデータ送信量を変えたり、優先送信したりしてもよい。また、影響度に応じて交通情報を色分け表示したり、交通情報の案内表示と共にその影響度を音声案内したりするなど、影響度に応じた異なる方法で交通情報を報知するようにしてもよい。

（実施形態３）
以下、この発明の第３実施形態について図１３及び図１４を参照して説明する。
なお、上述した第１及び第２実施形態において管理サーバ１は、各駅の改札ゲート装置７を通過した各利用者の入退場記録を交通機関端末２から取得して利用履歴データベースＤＢ２に利用履歴として記憶するほか、この利用履歴に基づいて通知条件を求めて登録者情報データベースＤＢに記憶するようにしたが、この第３実施形態の利用者端末６は、改札ゲート装置７を通過した際の入退場記録を取得して自己の利用履歴として記憶すると共に、この利用履歴から通知条件を求めて管理サーバ１に送信するようにしたものである。すなわち、第１及び第２実施形態において管理サーバ１で実行されていた処理の一部を第３実施形態では利用者端末６側で実行するようにしたものである。

そして、この第３実施形態においては、第１及び第２実施形態と同様、管理サーバ１側に交通情報データベースＤＢ１、交通機関データベースＤＢ３、登録者情報データベースＤＢ４が設けられているが、この第３実施形態では、利用履歴データベースＤＢ２を利用者端末６側に設けるようにしている。なお、交通情報データベースＤＢ１、利用履歴データベースＤＢ２、交通機関データベースＤＢ３、登録者情報データベースＤＢ４は、上述した第１実施形態の場合と基本的に同様であるため、その説明を省略するものとする。また、第１、第３実施形態において基本的あるいは名称的に同一のものは、同一符号を付して示し、その説明を省略すると共に、以下、第３実施形態の特徴部分を中心に説明するものとする。

図１３は、第３実施形態において改札ゲート装置７の通過時に改札ゲート装置７と非接触ＩＣカード処理部６８との間での交信で実行開始される利用者端末６側での利用履歴記憶処理・通知条件設定処理を示したフローチャートである。
先ず、利用者端末６は、改札ゲート装置７と非接触ＩＣカード処理部６８との交信によってその入退場記録を受信取得し（ステップＥ１）、この入退場記録を自身の利用履歴として利用履歴データベースＤＢ２に格納する（ステップＥ２）。その際、利用履歴データベースＤＢ２の記憶データ量がフル状態であれば、その先頭領域に記憶されている古い利用履歴に代わって新たな入退場記録（利用状況）を上書き保存するようにしている。

そして、「更新期間」を読み出し、前回の更新時から現時点までの経過期間を求め、この経過期間と「更新期間」とを比較することによって「更新期間」に達したかを調べ（ステップＥ３）、「更新期間」に達していなければ（ステップＥ３でＮＯ）、このフローから抜けるが、「更新期間」に達していれば（ステップＥ３でＹＥＳ）、利用履歴データベースＤＢ２の「通知条件」を更新する処理に移る（ステップＥ４）。すなわち、上述した第１実施形態と同様に、例えば、最近１０週間分の利用履歴を分析し、その分析結果に基づいて「通知条件」に利用路線とその隣接関係、利用区間とその隣接関係、利用時間などを設定することによってその内容を更新する。このように「更新期間」に達すると、更新後の「通知条件」をその「利用者識別情報」と共に管理サーバ１に送信する（ステップＥ５）。

ここで、管理サーバ１は、利用者端末６から「通知条件」、「利用者識別情報」を受信すると、この「利用者識別情報」に基づいて登録者情報データベースＤＢ４を検索し、対応する「通知条件」に今回受信した「通知条件」を上書きすることによってその内容を更新する。また、上述した第２実施形態と同様に、管理サーバ１は、運行遅延などの発生時にその交通情報を受信すると、この交通情報に基づいて作成した通知情報を解釈して事故の発生状況を分析し、その分析結果と通知条件とから運行遅延などが利用者に対してどのように影響しているかの影響度を登録者毎に判断して通知対象者を選択し、この影響度を付加した通知情報（交通情報）を通知対象者の利用者端末６に対して送信するようにしている。

図１４は、第３実施形態において管理サーバ１から通知情報（交通情報）を受信した際に実行開始される利用者端末６側での交通情報報知処理を示したフローチャートである。
利用者端末６は、管理サーバ１から受信した交通情報を取り込むと（ステップＦ１）、この交通情報に付加されている影響度は、影響度強（Ａ）、影響度中（Ｂ）、影響度弱（Ｃ）の何れであるかを判断し（ステップＦ２）、この影響度に応じた異なる方法で交通情報を報知する（ステップＦ３）。例えば、影響度に応じて交通情報を色分け表示したり、交通情報の案内表示と共にその影響度を音声案内したりするなど、影響度に応じた異なる方法で交通情報を報知する。

以上のように、この第３実施形態において利用者端末６は、改札ゲート装置７を通過した際の入退場記録を取得して自己の利用履歴として記憶すると共に、この利用履歴から通知条件を求めて管理サーバ１に送信したのち、管理サーバ１から当該通知条件を満たす交通情報を受信して出力するようにしたので、管理サーバ１は、登録者毎に利用履歴を記憶する処理と通知条件を作成する処理を行わなくてもよく、処理の負担を軽減できるほか、システム全体として効率のよい運用が可能となる。

利用者端末６は、利用履歴を分析して利用路線、利用区間、利用時間帯を利用状況として求め、この利用状況を通知条件として管理サーバ１に送信するようにしたので、利用者にとって必要な交通情報のみを享受することができる。

利用者端末６は、管理サーバ１から通知条件を満たす交通情報を受信すると共に、当該交通情報が利用者にどの位影響しているかの影響度を受信した場合に、当該交通情報を影響度に応じて異なる方法で報知するようにしたから、事故、運行遅延などの影響を知ることができ、それに対する迅速な対応が可能となる。

利用者端末６は、利用履歴を分析して通知条件を求めて管理サーバ１に送信する動作を定期的に行って管理サーバ１側の通知条件を更新するようにしたので、最新の利用状況に応じて通知条件を動的に変化させることができ、実情に即したものとなる。

なお、上述した第３実施形態において利用者端末６は、管理サーバ１から受信した交通情報を影響度に応じて色分け表示などのように異なる方法で報知するようにしたが、交通情報を表示する際に、上述した第２実施形態の図１２（１）〜（３）のように影響度を付加して交通情報を表示するようにしてもよい。

また、上述した各実施形態において交通情報は、事故、運行遅延に限らず、交通機関に関する緊急連絡（避難連絡など）や時刻表の変更（ダイヤ変更）などの交通情報であってもよい。また、利用者端末６側で交通情報を表示メッセージによって案内する場合に限らず、交通情報を音声メッセージによって案内するようにしてもよい。

また、交通機関としては電車、モノレールなどの鉄道に限らず、バス、船舶、高速道路であってもよい。なお、高速道路の場合には、ＥＴＣカード（高速料金後払いカード）を利用して料金所を通過した場合に、渋滞などの交通情報を登録者の車載端末に送信するようにしてもよい。
その他、利用者端末６は、携帯電話機に限らず、例えば、ＰＤＡ、電子カメラ、電子腕時計、音楽再生機などでも同様に適用可能である。

交通情報通知システムを示したブロック図。 管理サーバ１の基本的な構成要素を示したブロック図。 利用者端末６の基本的な構成要素を示したブロック図。 利用履歴データベースＤＢ２を説明するための図。 登録者情報データベースＤＢ４を説明するための図。 管理サーバ１において定期的（例えば、１日１回）に実行開始される利用履歴記憶処理・通知条件設定処理を示したフローチャート。 管理サーバ１において交通情報通知処理の全体概要を示したフローチャート。 通知対象者選択処理（図７のステップＢ４）を詳述するためのフローチャート。 （１）〜（４）は、あるサービス登録者の最近１０週間分の利用履歴を分析して、曜日毎にその利用頻度を集計した結果を示した図。 受信した交通情報に基づいて作成された通知情報の内容を例示した図。 第２実施形態における通知対象者選択処理を詳述するためのフローチャート。 利用者端末６での受信画面を例示した図で、（１）は、影響度強（Ａ）の登録者の受信画面、（２）は、影響度中（Ｂ）の登録者の受信画面、（３）は、影響度弱（Ｃ）の登録者の受信画面を示した図。 第３実施形態において改札ゲート装置７の通過時に改札ゲート装置７と非接触ＩＣカード処理部６８との間での交信で実行開始される利用者端末６側での利用履歴記憶処理・通知条件設定処理を示したフローチャート。 第３実施形態において管理サーバ１から通知情報（交通情報）を受信した際に実行開始される利用者端末６側での交通情報報知処理を示したフローチャート。

符号の説明

１ 管理サーバ
２ 交通機関端末
３ 専用回線網
４ インターネット
５ 移動体通信網
６ 利用者端末
７ 改札ゲート装置
１１、６１ ＣＰＵ
１２、６２ 記憶部
１６ 通信部
６４ 無線通信部
６８ 非接触ＩＣカード処理部
ＤＢ１ 交通情報データベース
ＤＢ２ 利用履歴データベース
ＤＢ３ 交通機関データベース
ＤＢ４ 登録者情報データベース

Claims (12)

1. 交通機関に関する交通情報をその利用者側の端末装置に通知する交通情報通知システムであって、
   交通機関を利用する利用者毎にその利用履歴を記憶する履歴記憶手段と、
   前記利用履歴を分析して利用者毎に交通機関の利用状況を求める分析手段と、
   この分析手段によって得られた利用者毎の利用状況を前記交通情報の通知先を特定するための通知条件として利用者毎に登録する登録手段と、
   前記交通情報を通知する場合に、当該交通情報の内容からそれに該当する前記通知条件を満たす利用者を特定してその利用者側の端末装置に通知する通知手段と、
   を具備したことを特徴とする交通情報通知システム。
2. 前記利用履歴は、交通機関の利用時にその利用者が提示した記憶媒体の記録内容とその利用時刻を含む情報である、
   ようにしたことを特徴とする請求項１記載の交通情報通知システム。
3. 前記分析手段は、前記利用履歴を分析することによって利用路線、利用区間、利用時間帯を利用状況として求め、
   前記登録手段は、前記利用状況を通知条件として登録する、
   ようにしたことを特徴とする請求項１記載の交通情報通知システム。
4. 前記利用履歴を分析して利用者毎に交通機関の利用状況を求めて通知条件として登録する動作を定期的に行ってその登録内容を更新する更新手段を更に設けた、
   ことを特徴とする請求項１記載の交通情報通知システム。
5. 前記交通情報の内容と前記通知条件とから当該交通情報が利用者に対してどのように関連しているかの関連度を判断する関連度判断手段を更に設け、
   前記通知手段は、前記関連度判断手段によって判断された関連度に応じて前記交通情報の通知を制御する、
   ようにしたことを特徴とする請求項１記載の交通情報通知システム。
6. 前記通知手段は、交通情報を通知する際に、前記関連度判断手段によって判断された関連度を含めて通知する、
   ようにしたことを特徴とする請求項５記載の交通情報通知システム。
7. 交通機関に関する交通情報をその利用者宛に配信する管理サーバから交通情報を受信して出力する交通情報受信端末装置であって、
   交通機関の自己の利用履歴を取得する取得手段と、
   この取得手段によって得られた利用履歴を記憶する履歴記憶手段と、
   前記利用履歴を分析して交通機関の利用状況を求める分析手段と、
   この分析手段によって得られた利用状況を前記交通情報の通知先を特定するための通知条件として前記管理サーバに送信する送信手段と、
   前記管理サーバから前記通知条件を満たす交通情報を受信して出力する出力手段と、
   を具備したことを特徴とする交通情報受信端末装置。
8. 前記分析手段は、前記利用履歴を分析することによって利用路線、利用区間、利用時間帯を利用状況として求め、
   前記送信手段は、前記利用状況を通知条件として前記管理サーバに送信する、
   ようにしたことを特徴とする請求項７記載の交通情報受信端末装置。
9. 前記出力手段は、前記管理サーバから前記通知条件を満たす交通情報を受信すると共に、当該交通情報が利用者に対してどのように関連しているかの関連度を受信した場合に、当該交通情報を関連度に応じて異なる方法で報知する、
   ようにしたことを特徴とする請求項７記載の交通情報受信端末装置。
10. 前記利用履歴を分析して利用者毎に交通機関の利用状況を求めて通知条件として前記管理サーバに送信する動作を定期的に行って当該管理サーバ側の通知条件を更新する更新手段を更に設けた、
    ことを特徴とする請求項７記載の交通情報受信端末装置。
11. コンピュータに対して、
    交通機関を利用する利用者毎にその利用履歴が記憶されている状態において、この利用履歴を分析して利用者毎に交通機関の利用状況を求める機能と、
    前記分析によって得られた利用者毎の利用状況を前記交通情報の通知先を特定するための通知条件として利用者毎に登録する機能と、
    前記交通情報を通知する場合に、当該交通情報の内容からそれに該当する前記通知条件を満たす利用者を特定してその利用者側の端末装置に通知する機能と、
    を実現させるためのプログラム。
12. コンピュータに対して、
    交通情報受信端末装置であって、
    交通機関の自己の利用履歴を取得する機能と、
    前記取得した利用履歴が記憶されている状態において、この利用履歴を分析して交通機関の利用状況を求める機能と、
    交通機関に関する交通情報をその利用者宛に配信する管理サーバから交通情報を受信して出力するために、前記分析によって得られた利用状況を交通情報の通知先を特定するための通知条件として前記管理サーバに送信する機能と、
    前記管理サーバから前記通知条件を満たす交通情報を受信して出力する機能と、
    を実現させるためのプログラム。

Images