(57)【特許請求の範囲】
【請求項１】
ネットワークに接続されたクライアント端末からの経路検索要求を受信して、その要求に応じた経路検索を実行して前記クライアント端末にその乗り換え案内を送信する経路検索システムであって、
少なくとも前記経路検索要求の検索条件のログ情報を記憶するログ情報記憶手段と、
前記ログ情報から作成した所定期間内の乗り換え案内結果の駅間利用状況データから混雑度を予測する混雑度予測手段と、
を有する経路検索システムを用いた混雑度予測装置。
【請求項２】
前記乗り換え案内に前記混雑度を示すメッセージを付加することを特徴とする請求項１に記載の経路検索システムを用いた混雑度予測装置。
【請求項３】
前記ログ情報記憶手段を含む第１のサーバ装置と、
前記混雑度予測手段を含む第２のサーバ装置と、
を有し、
前記第２のサーバ装置とは別に、前記ログ情報から乗り換え案内を作成する第３のサーバを有する請求項１に記載の経路検索システムを用いた混雑度予測装置。
【請求項４】
ネットワークに接続されたクライアント端末からの経路検索要求を受信して、その要求に応じた経路検索を実行して前記クライアント端末にその乗り換え案内を送信する経路検索システムであって、
少なくとも前記経路検索要求の検索条件および前記乗り換え案内のログ情報を記憶するログ情報記憶手段と、
前記ログ情報から作成した所定期間内の乗り換え案内結果の駅間利用状況データから混雑度を予測する混雑度予測手段と、
を有する経路検索システムを用いた混雑度予測装置。
【請求項５】
前記駅間利用状況データは、所定時間単位に、経路検索ルート間の駅毎に検索回数をカウントした値を示していることを特徴とする請求項１又は４に記載の経路検索システムを用いた混雑度予測装置。
【請求項６】
前記混雑度を示すメッセージは、検索対象日の前記駅間利用状況データと過去の同一曜日又は同一日の前記駅間利用状況データと比較することで判断したものであることを特徴とする請求項１又は４に記載の経路検索システムを用いた混雑度予測装置。
【請求項７】
前記混雑度を示すメッセージは、検索対象日の前記駅間利用状況データと過去の所定期間の前記駅間利用状況データの平均値とを比較することで判断したものであることを特徴とする請求項１又は４に記載の経路検索システムを用いた混雑度予測装置。
【請求項８】
ネットワークに接続されたクライアント端末からの経路検索要求を受信して、その要求に応じた経路検索を実行して前記クライアント端末にその乗り換え案内を送信する経路検索システムであって、少なくとも前記経路検索要求の検索条件のログ情報を記憶するログ情報記憶手段に接続されるサーバに搭載され、
少なくとも前記経路検索要求の検索条件のログ情報を受信する機能と、
前記ログ情報から所定期間内の乗り換え案内を作成し、作成した乗り換え案内結果の駅間利用状況データから混雑度を予測する機能と、
をサーバコンピュータに実現する混雑度予測プログラム。
【請求項９】
ネットワークに接続されたクライアント端末からの経路検索要求を受信して、その要求に応じた経路検索を実行して前記クライアント端末にその乗り換え案内を送信する経路検索システムであって、少なくとも前記経路検索要求の検索条件および前記乗り換え案内のログ情報を記憶するログ情報記憶手段に接続されるサーバに搭載され、
少なくとも前記経路検索要求の検索条件および前記乗り換え案内のログ情報を受信する機能と、
前記ログ情報から所定期間内の乗り換え案内を作成し、作成した乗り換え案内結果の駅間利用状況データから混雑度を予測する機能と、
をサーバコンピュータに実現する混雑度予測プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、経路検索システムを用いた混雑度予測装置および混雑度予測プログラムに関するものである。
【背景技術】
【０００２】
インターネット等を通じて、出発地から目的地までの交通手段に関する情報を取得する経路検索サービスが知られている。例えば、利用者の端末装置から検索要求が行われると、経路検索サービスではその要求に応じて、目的地迄の到着時間が速い経路、乗換回数が少ない経路、利用料金が安い経路などを検索して、利用者に提供している。利用者は、その検索結果を参考に各種交通手段を利用して、目的地への移動を行っている。
【０００３】
しかしながら、従来の経路検索システムでは、乗車する時間帯における交通手段の混雑度や、目的地駅又はその駅周辺の混雑度や、途中の乗り換え駅の混在度については何も案内されていない。
【０００４】
交通手段の混雑具合は、その乗車ルート上の各駅周辺で行われているイベント、例えば有名人のコンサート、演奏会、各種の催し物、各種のスポーツイベントにより変化する。このような各種のイベントに関する情報は、そのイベントの参加者（当事者およびお客となる人）や、そのイベントに興味のある人だけしか知らないことが多い。そのため、イベント情報を知らない利用者が、乗車ルート上で集客イベントに巻き込まれてしまう可能性がある。利用者によっては、混雑を嫌う人も多く、できる限り精神的な苦痛を避けたいと思っている。
【０００５】
特開２００６−２７７１０９号公報には、携帯通信端末がサーバに対して経路検索要求を行うと、サーバは、検索した経路とその近辺のイベントによる予想混雑率を携帯通信端末へ送信し、携帯通信端末がそれを表示する技術が開示されている。その具体的な方法は、イベントへの予想参加人数、イベントの開催時間、イベントに関連した公共交通手段への予想利用人数、及びイベントに伴う公共交通手段の予想混雑率の少なくとも一つを含むイベント情報を携帯通信端末に出力するものである。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−２７７１０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１には、公共交通手段への予想利用人数や公共交通手段の予想混雑率をどのように求めるかの具体的の方法は何も開示されていない。
【０００８】
本発明が解決しようとする課題は、乗り換え案内のログ情報（発着駅や発着時刻などの検索条件）を基に、検索ルート上の各駅と時間帯の乗り換え案内の利用状況を作成集計して、乗り換え案内の利用状況を利用駅の混雑度と予測する経路検索システムを用いた混雑度予測装置および混雑度予測プログラムを提供することにある。
【課題を解決するための手段】
【０００９】
本実施形態の経路検索システムを用いた混雑度予測装置は、ネットワークに接続されたクライアント端末からの経路検索要求を受信して、その要求に応じた経路検索を実行して前記クライアント端末にその乗り換え案内を送信する経路検索システムであって、少なくとも前記経路検索要求の検索条件のログ情報を記憶するログ情報記憶手段と、前記ログ情報から作成した所定期間内の乗り換え案内結果の駅間利用状況データから混雑度を予測する混雑度予測手段と、を有することを特徴とする。
【００１０】
本実施形態の混雑度予測プログラムは、ネットワークに接続されたクライアント端末からの経路検索要求を受信して、その要求に応じた経路検索を実行して前記クライアント端末にその乗り換え案内を送信する経路検索システムであって、少なくとも前記経路検索要求の検索条件のログ情報を記憶するログ情報記憶手段に接続されるサーバに搭載され、少なくとも前記経路検索要求の検索条件のログ情報を受信する機能と、前記ログ情報から所定期間内の乗り換え案内を作成し、作成した乗り換え案内結果の駅間利用状況データから混雑度を予測する機能と、をサーバコンピュータに実現することを特徴とする。
【発明の効果】
【００１１】
実施形態によれば、経路検索条件のログ情報を用いて乗り換え案内の駅間利用状況データを作成することで、乗り換え案内区間の混雑度を予測して利用者にメッセージ提供することができるため、利用者は、混雑を避けた移動を計画することができ、精神的な苦痛を避けることができる。
【図面の簡単な説明】
【００１２】
【図１】第１の実施形態に係る経路検索システムを用いた混雑度予測装置の構成を示すブロック図。
【図２】第１の実施形態に係る経路検索システムを用いた混雑度予測装置の駅間利用状況データの一例を示す図。
【図３】第１の実施形態に係る経路検索システムを用いた混雑度予測プログラムの動作を示すフローチャート。
【図４】第２の実施形態に係る経路検索システムを用いた混雑度予測装置の構成を示すブロック図。
【図５】第３の実施形態に係る経路検索システムを用いた混雑度予測装置の構成を示すブロック図。
【発明を実施するための形態】
【００１３】
以下、図面を参照して、本発明の実施形態に係る経路検索システムを用いた混雑度予測装置および混雑度予測プログラムを説明する。
【００１４】
図１は、第１の実施形態に係る経路検索システムを用いた混雑度予測装置の構成を示すブロック図である。
【００１５】
図１において、クライアント端末１０ａ，１０ｂ，１０ｃは、利用者端末であって、パソコン、携帯電話機、スマートフォンなどの端末装置が用いられる。利用者は、クライアント端末１０ａ，１０ｂ，１０ｃからインターネットなどのネットワーク２０を通じて経路検索サービスを提供するＵＲＬアドレスにアクセスして、第１のサーバ装置である経路検索サーバ１００へ経路検索要求を行う。
【００１６】
経路検索サーバ１００は、第１処理装置１１０と第１ディスク記憶装置１２０を有している。第１処理装置１１０は、経路検索プログラムを実行して、利用者からの経路検索要求に対し、目的地迄の到着時間が速い経路、乗換回数が少ない経路、利用料金が安い経路などを１つ又は複数検索して、その検索結果をネットワーク２０を通じて利用者のクライアント端末１０ａ，１０ｂ，１０ｃに送信する。経路検索の方法については、既知の技術を用いて実行すればよく、本発明と直接関係しないのでその説明は省略する。
【００１７】
多数の利用者からの経路検索サーバ１００に対する経路検索要求は、第１処理装置１１０によってログ情報として第１ディスク記憶装置１２０に格納される。ログ情報は、クライアント端末１０ａ，１０ｂ，１０ｃから入力された例えば、アクセス時刻、検索対象の年月日、出発地、目的地、到着時刻又は出発時刻などの検索条件である。以下の実施形態では、このログ情報が混雑度予測の判断元データとして利用される。
【００１８】
経路検索サーバ１００は、第２のサーバ装置である駅間利用状況データ作成用クライアント２００（以下、単にクライアント２００と称する）と接続されている。また、クライアント２００は、第３のサーバ装置である駅間利用状況データ作成用経路検索サーバ３００（以下、単に経路検索サーバ３００と称する）と接続されている。
【００１９】
クライアント２００は、第２処理装置２１０と第２ディスク記憶装置２２０を有している。そして、経路検索サーバ１００の第１ディスク記憶装置１２０に格納されたログ情報は、クライアント２００の第２ディスク記憶装置２２０にコピー又は移動される。第２処理装置２１０は、第２ディスク記憶装置２２０に記憶した検索条件のログ情報を経路検索サーバ３００が扱えるデータに変換して、経路検索サーバ３００に出力する。
【００２０】
経路検索サーバ３００は、第３処理装置３１０と第３ディスク記憶装置３２０を有している。経路検索サーバ３００は、経路検索サーバ１００と同じ構成（経路検索プログラム）を有している。経路検索サーバ３００は、クライアント２００から取得した情報を基に、乗り換え案内情報を作成して第３ディスク記憶装置３２０に記憶する。そして、作成した乗り換え案内情報をクライアント２００へ出力する。つまり、経路検索サーバ１００からのログ情報を基に、乗り換え案内を再現して、その結果をクライアント２００に送信する。
【００２１】
クライアント２００は、経路検索サーバ３００から取得した乗り換え案内情報を加工して、後述する駅間利用状況データを作成して第２ディスク記憶装置２２０に記憶する。そして、クライアント２００は、駅間利用状況データを基に混雑度のメッセージを作成し、経路検索サーバ１００に提供する。
【００２２】
経路検索サーバ１００は、乗り換え案内に混雑度のメッセージを付加して、ネットワーク２０を経由してクライアント端末１０ａ，１０ｂ，１０ｃに提供する。
【００２３】
図２の左側には、クライアント２００によって作成される駅間利用状況データの一例を示している。図２では、中央線のとある月曜日の駅間利用状況データの一例を示している。駅間利用状況データは、所定期間内の全ての検索条件の検索対象の年月日、出発地、目的地、到着時刻又は出発時刻などを基に、所定時間単位（ここでは、１時間毎としたが３０分単位でもよい）に、検索ルート間の駅毎に検索回数をカウントする。所定期間としては、例えば１年、６ヶ月、１ヶ月、１週間、検索対象日の単位であって、利用者数のデータ量に応じて適宜変更しても良い。
【００２４】
例えば、出発地：高尾駅、目的地：東京駅の経路検索要求に対しては、高尾駅〜東京駅の区間の全ての駅（３２駅）で＋１がカウントされる。例えば、出発地：立川駅、目的地：新宿駅の経路検索要求に対しては、立川駅〜新宿駅の区間の駅（１７駅）で＋１がカウントされる。例えば、出発地：立川駅、目的地：赤坂見附駅の検索要求に対しては、検索ルートの中央線区間では立川駅〜四ッ谷駅の区間の駅（２１駅）で＋１がカウントされる。実施形態では、こうして作成された駅間利用状況データを参照して混雑度情報を作成し、乗り換え結果の案内にその混雑度情報を付加して、利用者に提供する。
【００２５】
次に、図３を参照して、混雑度予測プログラムによる本実施形態の動作を説明する。
【００２６】
まず、クライアント２００は、経路検索サーバ１００の第１ディスク記憶装置１２０に格納されている、乗り換え案内システムでの利用者からの経路検索要求のログ情報を取得する（図３のステップＳ１０）。ログ情報は、経路検索サーバ１００からタイムリーにクライアント２００へ送信しても構わないが、アクセス量の少ない夜間にクライアント２００へ送信しても良い。例えば、経路検索サーバ１００の第１ディスク記憶装置１２０に貯めていた一日分のログ情報を夜間に送信すれば、アクセス量の多い昼間での経路検索サーバ１００の負荷が軽減される。
【００２７】
クライアント２００は、取得したログ情報を確認して（図３のステップＳ２０）、ログ情報がない又はエラーがあれば処理を終了する。一方、ログ情報が正常であれば、対象期間のログ情報がまだあるか否かを確認し（図３のステップＳ３０）、ログ情報が無ければ処理を終了する。
【００２８】
ログ情報が存在すれば、クライアント２００は、当該ログ情報を経路検索サーバ３００を呼べる形式に変換して、経路検索を再現するために経路検索サーバ３００に送信する（図３のステップＳ４０，５０）。これにより、経路検索サーバ３００は、クライアント２００から取得したログ情報から乗り換え案内を作成して、その乗り換え案内結果をクライアント２００へ送信する。
【００２９】
クライアント２００は、乗り換え案内結果を取得して第２ディスク記憶装置に２２０に格納する（図３のステップＳ６０）。
【００３０】
クライアント２００は、取得した乗り換え案内結果のエラーチェックを行い（図３のステップＳ７０）、エラーがあれば次のログ情報を読み出し（図３のステップＳ１００）、ステップＳ３０〜Ｓ６０を実行する。
【００３１】
クライアント２００は、取得した乗り換え案内結果にエラーがなければ、その乗り換え案内結果から、例えば図２の左側に示す「駅間利用状況データ」を作成して、第２ディスク記憶装置２２０に格納する（図３のステップＳ８０，９０）。そして、クライアント２００は、次のログ情報を読み出し（図３のステップＳ１００）、ステップＳ３０〜Ｓ９０を実行する。このステップＳ３０〜Ｓ９０の処理を、対象期間のログ情報に対して実行することによって、対象期間の「駅間利用状況データ」を作成することができる。
【００３２】
そして、クライアント２００は、第２ディスク記憶装置２２０に格納した「駅間利用状況データ」から混雑度を示した駅間利用状況メッセージを作成して、経路検索サーバ１００に渡す。経路検索サーバ１００は、乗り換え案内結果に駅間利用状況メッセージを付加して、ネットワーク２０を経由して利用者のクライアント端末１０ａ，１０ｂ，１０ｃに送信する。
【００３３】
ここで混雑度の予測データとして、例えば以下のようなメッセージで表示する。
【００３４】
（１）検索対象日の「駅間利用状況データ」から、経路検索を要求した利用者数が多いかどうかで、混雑度を５段階で表示する。即ち、「駅間利用状況データ」の件数の多い状況から純粋に混んでいるかどうかを表示する。
【００３５】
（２）集計したデータは曜日などの単位でまとめ、ある対象期間の平均と比較し「普段と比べて」の混雑度を表示する。例えば、「有楽町駅  9時着頃  山手線」が普段より利用が多い場合は、その情報を表示する。例えば、クライアント２００の第２ディスク記憶装置２２０内に、検索対象日の１週間前又は１ヶ月前又は１年前の同一曜日又は同一日の「駅間利用状況データ」の過去データとして記憶しておき、検索対象日の「駅間利用状況データ」と比較することで、混雑度を判断してもよい。また、例えば検索対象日の１年間又は半年間又は１ヶ月間又は１週間の「駅間利用状況データ」を平均した過去データとして記憶しておき、検索対象日の「駅間利用状況データ」と比較することで、混雑度を判断してもよい。
【００３６】
（３）上記（２）の場合に、クライアント２００に予めイベントデータを取り込み、そのイベントデータとの紐付けができれば、その情報も出力する。例えば「９時より国際フォーラムで「就職説明会」が開催されています。これによりこの時間帯は混雑する可能性があります」など。
【００３７】
図２の右側には、左側の駅間利用状況データに基づいて作成した乗り換え案内表示の一例を示している。立川駅の出発時刻の時間帯における、カウント値と１年間又は半年間又は１ヶ月間の「駅間利用状況データ」を平均した過去データとを比較して「混雑度「４」  普段通り、混雑しています。四ッ谷駅から混雑が緩和されます」のメッセージを利用者のクライアント端末１０ａ，１０ｂ，１０ｃに乗り換え案内結果と同時に表示させる。また、東京駅では、図示していない山手線の「駅間利用状況データ」を基に、「混雑度「５」  普段より混雑する可能性があります。９時着が多く検索されています。有楽町駅でイベントがある可能性があります」のメッセージを利用者のクライアント端末１０ａ，１０ｂ，１０ｃに表示させる。
【００３８】
また、利用者のクライアント端末１０ａ，１０ｂ，１０ｃの画面に「混雑度予測」ボタンを設け、当該ボタンを利用者がクリックした時だけ、混雑度の予測メッセージを提供するようにしてもよい。
【００３９】
したがって、実施形態によれば、経路検索条件のログ情報を用いて乗り換え案内の駅間利用状況データを作成することで、乗り換え案内区間の混雑度を予測して利用者にメッセージ提供することができるため、利用者は、混雑を避けた移動を計画することができ、精神的な苦痛を避けることができる。
【００４０】
図４は、第１の実施形態の第１変形例を示している。図１では、駅間利用状況データ作成を司るものとして、駅間利用状況データ作成用クライアント２００と駅間利用状況データ作成用経路検索サーバ３００とに分けた構成としたが、図４に示すように１つのサーバ装置４００にて構成してもよい。このような構成によれば、１つのサーバ装置４００によって、乗り換え案内の作成、「駅間利用状況データ」の作成を実行するため、図３のステップＳ５０，Ｓ６０を省略することができる。
【００４１】
図５、第１の実施形態の第２変形例を示している。図５では、駅間利用状況データ作成用経路検索サーバ３００を無くした構成としている。このような構成とした場合、図３のステップＳ１０では、クライアント２００は、経路検索サーバ１００からログ情報と乗り換え案内情報の両方を取得することになる。また、図３のステップＳ４０，Ｓ５０，Ｓ６０，Ｓ７０を省略することができる。
【００４２】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００４３】
１０ａ，１０ｂ，１０ｃ‥クライアント端末、
２０‥ネットワーク
１００‥経路検索サーバ
１１０‥第１処理装置
１２０‥第１ディスク記憶装置
２００‥駅間利用状況データ作成用クライアント
２１０‥第２処理装置
２２０‥第２ディスク記憶装置
３００‥駅間利用状況データ作成用経路検索サーバ
３１０‥第３処理装置
３２０‥第３ディスク記憶装置
【図１】
0005767144.tif 000002
【図２】
0005767144.tif 000003
【図３】
0005767144.tif 000004
【図４】
0005767144.tif 000005
【図５】
0005767144.tif 000006