(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5767144
(24)【登録日】2015年6月26日
(45)【発行日】2015年8月19日
(54)【発明の名称】経路検索システムを用いた混雑度予測装置および混雑度予測プログラム
(51)【国際特許分類】
G06Q 50/30 20120101AFI20150730BHJP
G01C 21/00 20060101ALI20150730BHJP
G08G 1/005 20060101ALI20150730BHJP
【FI】
G06Q50/30
G01C21/00
G08G1/005
【請求項の数】9
【全頁数】10
(21)【出願番号】特願2012-54993(P2012-54993)
(22)【出願日】2012年3月12日
(65)【公開番号】特開2013-190867(P2013-190867A)
(43)【公開日】2013年9月26日
【審査請求日】2014年10月1日
【早期審査対象出願】
(73)【特許権者】
【識別番号】303026132
【氏名又は名称】株式会社駅探
(74)【代理人】
【識別番号】100111110
【弁理士】
【氏名又は名称】美甘 徹也
(74)【代理人】
【識別番号】100159938
【弁理士】
【氏名又は名称】砂井 正之
(72)【発明者】
【氏名】清水 直之
【審査官】
塩田 徳彦
(56)【参考文献】
【文献】
特開2012−048559(JP,A)
【文献】
特開2008−102046(JP,A)
【文献】
特開2005−212499(JP,A)
【文献】
特開2005−247237(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 − 50/34
G01C 21/00
G08G 1/005
(57)【特許請求の範囲】
【請求項1】
ネットワークに接続されたクライアント端末からの経路検索要求を受信して、その要求に応じた経路検索を実行して前記クライアント端末にその乗り換え案内を送信する経路検索システムであって、
少なくとも前記経路検索要求の検索条件のログ情報を記憶するログ情報記憶手段と、
前記ログ情報から作成した所定期間内の乗り換え案内結果の駅間利用状況データから混雑度を予測する混雑度予測手段と、
を有する経路検索システムを用いた混雑度予測装置。
【請求項2】
前記乗り換え案内に前記混雑度を示すメッセージを付加することを特徴とする請求項1に記載の経路検索システムを用いた混雑度予測装置。
【請求項3】
前記ログ情報記憶手段を含む第1のサーバ装置と、
前記混雑度予測手段を含む第2のサーバ装置と、
を有し、
前記第2のサーバ装置とは別に、前記ログ情報から乗り換え案内を作成する第3のサーバを有する請求項1に記載の経路検索システムを用いた混雑度予測装置。
【請求項4】
ネットワークに接続されたクライアント端末からの経路検索要求を受信して、その要求に応じた経路検索を実行して前記クライアント端末にその乗り換え案内を送信する経路検索システムであって、
少なくとも前記経路検索要求の検索条件および前記乗り換え案内のログ情報を記憶するログ情報記憶手段と、
前記ログ情報から作成した所定期間内の乗り換え案内結果の駅間利用状況データから混雑度を予測する混雑度予測手段と、
を有する経路検索システムを用いた混雑度予測装置。
【請求項5】
前記駅間利用状況データは、所定時間単位に、経路検索ルート間の駅毎に検索回数をカウントした値を示していることを特徴とする請求項1又は4に記載の経路検索システムを用いた混雑度予測装置。
【請求項6】
前記混雑度を示すメッセージは、検索対象日の前記駅間利用状況データと過去の同一曜日又は同一日の前記駅間利用状況データと比較することで判断したものであることを特徴とする請求項1又は4に記載の経路検索システムを用いた混雑度予測装置。
【請求項7】
前記混雑度を示すメッセージは、検索対象日の前記駅間利用状況データと過去の所定期間の前記駅間利用状況データの平均値とを比較することで判断したものであることを特徴とする請求項1又は4に記載の経路検索システムを用いた混雑度予測装置。
【請求項8】
ネットワークに接続されたクライアント端末からの経路検索要求を受信して、その要求に応じた経路検索を実行して前記クライアント端末にその乗り換え案内を送信する経路検索システムであって、少なくとも前記経路検索要求の検索条件のログ情報を記憶するログ情報記憶手段に接続されるサーバに搭載され、
少なくとも前記経路検索要求の検索条件のログ情報を受信する機能と、
前記ログ情報から所定期間内の乗り換え案内を作成し、作成した乗り換え案内結果の駅間利用状況データから混雑度を予測する機能と、
をサーバコンピュータに実現する混雑度予測プログラム。
【請求項9】
ネットワークに接続されたクライアント端末からの経路検索要求を受信して、その要求に応じた経路検索を実行して前記クライアント端末にその乗り換え案内を送信する経路検索システムであって、少なくとも前記経路検索要求の検索条件および前記乗り換え案内のログ情報を記憶するログ情報記憶手段に接続されるサーバに搭載され、
少なくとも前記経路検索要求の検索条件および前記乗り換え案内のログ情報を受信する機能と、
前記ログ情報から所定期間内の乗り換え案内を作成し、作成した乗り換え案内結果の駅間利用状況データから混雑度を予測する機能と、
をサーバコンピュータに実現する混雑度予測プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、経路検索システムを用いた混雑度予測装置および混雑度予測プログラムに関するものである。
【背景技術】
【0002】
インターネット等を通じて、出発地から目的地までの交通手段に関する情報を取得する経路検索サービスが知られている。例えば、利用者の端末装置から検索要求が行われると、経路検索サービスではその要求に応じて、目的地迄の到着時間が速い経路、乗換回数が少ない経路、利用料金が安い経路などを検索して、利用者に提供している。利用者は、その検索結果を参考に各種交通手段を利用して、目的地への移動を行っている。
【0003】
しかしながら、従来の経路検索システムでは、乗車する時間帯における交通手段の混雑度や、目的地駅又はその駅周辺の混雑度や、途中の乗り換え駅の混在度については何も案内されていない。
【0004】
交通手段の混雑具合は、その乗車ルート上の各駅周辺で行われているイベント、例えば有名人のコンサート、演奏会、各種の催し物、各種のスポーツイベントにより変化する。このような各種のイベントに関する情報は、そのイベントの参加者(当事者およびお客となる人)や、そのイベントに興味のある人だけしか知らないことが多い。そのため、イベント情報を知らない利用者が、乗車ルート上で集客イベントに巻き込まれてしまう可能性がある。利用者によっては、混雑を嫌う人も多く、できる限り精神的な苦痛を避けたいと思っている。
【0005】
特開2006−277109号公報には、携帯通信端末がサーバに対して経路検索要求を行うと、サーバは、検索した経路とその近辺のイベントによる予想混雑率を携帯通信端末へ送信し、携帯通信端末がそれを表示する技術が開示されている。その具体的な方法は、イベントへの予想参加人数、イベントの開催時間、イベントに関連した公共交通手段への予想利用人数、及びイベントに伴う公共交通手段の予想混雑率の少なくとも一つを含むイベント情報を携帯通信端末に出力するものである。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開2006−277109号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
しかしながら、特許文献1には、公共交通手段への予想利用人数や公共交通手段の予想混雑率をどのように求めるかの具体的の方法は何も開示されていない。
【0008】
本発明が解決しようとする課題は、乗り換え案内のログ情報(発着駅や発着時刻などの検索条件)を基に、検索ルート上の各駅と時間帯の乗り換え案内の利用状況を作成集計して、乗り換え案内の利用状況を利用駅の混雑度と予測する経路検索システムを用いた混雑度予測装置および混雑度予測プログラムを提供することにある。
【課題を解決するための手段】
【0009】
本実施形態の経路検索システムを用いた混雑度予測装置は、ネットワークに接続されたクライアント端末からの経路検索要求を受信して、その要求に応じた経路検索を実行して前記クライアント端末にその乗り換え案内を送信する経路検索システムであって、少なくとも前記経路検索要求の検索条件のログ情報を記憶するログ情報記憶手段と、前記ログ情報から作成した
所定期間内の乗り換え案内結果の
駅間利用状況データから混雑度を予測する混雑度予測手段と、を有することを特徴とする。
【0010】
本実施形態の混雑度予測プログラムは、ネットワークに接続されたクライアント端末からの経路検索要求を受信して、その要求に応じた経路検索を実行して前記クライアント端末にその乗り換え案内を送信する経路検索システムであって、少なくとも前記経路検索要求の検索条件のログ情報を記憶するログ情報記憶手段に接続されるサーバに搭載され、少なくとも前記経路検索要求の検索条件のログ情報を受信する機能と、前記ログ情報から
所定期間内の乗り換え案内を作成し、作成した乗り換え案内結果の
駅間利用状況データから混雑度を予測する機能と、をサーバコンピュータに実現することを特徴とする。
【発明の効果】
【0011】
実施形態によれば、経路検索条件のログ情報を用いて乗り換え案内の駅間利用状況データを作成することで、乗り換え案内区間の混雑度を予測して利用者にメッセージ提供することができるため、利用者は、混雑を避けた移動を計画することができ、精神的な苦痛を避けることができる。
【図面の簡単な説明】
【0012】
【
図1】第1の実施形態に係る経路検索システムを用いた混雑度予測装置の構成を示すブロック図。
【
図2】第1の実施形態に係る経路検索システムを用いた混雑度予測装置の駅間利用状況データの一例を示す図。
【
図3】第1の実施形態に係る経路検索システムを用いた混雑度予測プログラムの動作を示すフローチャート。
【
図4】第2の実施形態に係る経路検索システムを用いた混雑度予測装置の構成を示すブロック図。
【
図5】第3の実施形態に係る経路検索システムを用いた混雑度予測装置の構成を示すブロック図。
【発明を実施するための形態】
【0013】
以下、図面を参照して、本発明の実施形態に係る経路検索システムを用いた混雑度予測装置および混雑度予測プログラムを説明する。
【0014】
図1は、第1の実施形態に係る経路検索システムを用いた混雑度予測装置の構成を示すブロック図である。
【0015】
図1において、クライアント端末10a,10b,10cは、利用者端末であって、パソコン、携帯電話機、スマートフォンなどの端末装置が用いられる。利用者は、クライアント端末10a,10b,10cからインターネットなどのネットワーク20を通じて経路検索サービスを提供するURLアドレスにアクセスして、第1のサーバ装置である経路検索サーバ100へ経路検索要求を行う。
【0016】
経路検索サーバ100は、第1処理装置110と第1ディスク記憶装置120を有している。第1処理装置110は、経路検索プログラムを実行して、利用者からの経路検索要求に対し、目的地迄の到着時間が速い経路、乗換回数が少ない経路、利用料金が安い経路などを1つ又は複数検索して、その検索結果をネットワーク20を通じて利用者のクライアント端末10a,10b,10cに送信する。経路検索の方法については、既知の技術を用いて実行すればよく、本発明と直接関係しないのでその説明は省略する。
【0017】
多数の利用者からの経路検索サーバ100に対する経路検索要求は、第1処理装置110によってログ情報として第1ディスク記憶装置120に格納される。ログ情報は、クライアント端末10a,10b,10cから入力された例えば、アクセス時刻、検索対象の年月日、出発地、目的地、到着時刻又は出発時刻などの検索条件である。以下の実施形態では、このログ情報が混雑度予測の判断元データとして利用される。
【0018】
経路検索サーバ100は、第2のサーバ装置である駅間利用状況データ作成用クライアント200(以下、単にクライアント200と称する)と接続されている。また、クライアント200は、第3のサーバ装置である駅間利用状況データ作成用経路検索サーバ300(以下、単に経路検索サーバ300と称する)と接続されている。
【0019】
クライアント200は、第2処理装置210と第2ディスク記憶装置220を有している。そして、経路検索サーバ100の第1ディスク記憶装置120に格納されたログ情報は、クライアント200の第2ディスク記憶装置220にコピー又は移動される。第2処理装置210は、第2ディスク記憶装置220に記憶した検索条件のログ情報を経路検索サーバ300が扱えるデータに変換して、経路検索サーバ300に出力する。
【0020】
経路検索サーバ300は、第3処理装置310と第3ディスク記憶装置320を有している。経路検索サーバ300は、経路検索サーバ100と同じ構成(経路検索プログラム)を有している。経路検索サーバ300は、クライアント200から取得した情報を基に、乗り換え案内情報を作成して第3ディスク記憶装置320に記憶する。そして、作成した乗り換え案内情報をクライアント200へ出力する。つまり、経路検索サーバ100からのログ情報を基に、乗り換え案内を再現して、その結果をクライアント200に送信する。
【0021】
クライアント200は、経路検索サーバ300から取得した乗り換え案内情報を加工して、後述する駅間利用状況データを作成して第2ディスク記憶装置220に記憶する。そして、クライアント200は、駅間利用状況データを基に混雑度のメッセージを作成し、経路検索サーバ100に提供する。
【0022】
経路検索サーバ100は、乗り換え案内に混雑度のメッセージを付加して、ネットワーク20を経由してクライアント端末10a,10b,10cに提供する。
【0023】
図2の左側には、クライアント200によって作成される駅間利用状況データの一例を示している。
図2では、中央線のとある月曜日の駅間利用状況データの一例を示している。駅間利用状況データは、所定期間内の全ての検索条件の検索対象の年月日、出発地、目的地、到着時刻又は出発時刻などを基に、所定時間単位(ここでは、1時間毎としたが30分単位でもよい)に、検索ルート間の駅毎に検索回数をカウントする。所定期間としては、例えば1年、6ヶ月、1ヶ月、1週間、検索対象日の単位であって、利用者数のデータ量に応じて適宜変更しても良い。
【0024】
例えば、出発地:高尾駅、目的地:東京駅の経路検索要求に対しては、高尾駅〜東京駅の区間の全ての駅(32駅)で+1がカウントされる。例えば、出発地:立川駅、目的地:新宿駅の経路検索要求に対しては、立川駅〜新宿駅の区間の駅(17駅)で+1がカウントされる。例えば、出発地:立川駅、目的地:赤坂見附駅の検索要求に対しては、検索ルートの中央線区間では立川駅〜四ッ谷駅の区間の駅(21駅)で+1がカウントされる。実施形態では、こうして作成された駅間利用状況データを参照して混雑度情報を作成し、乗り換え結果の案内にその混雑度情報を付加して、利用者に提供する。
【0025】
次に、
図3を参照して、混雑度予測プログラムによる本実施形態の動作を説明する。
【0026】
まず、クライアント200は、経路検索サーバ100の第1ディスク記憶装置120に格納されている、乗り換え案内システムでの利用者からの経路検索要求のログ情報を取得する(
図3のステップS10)。ログ情報は、経路検索サーバ100からタイムリーにクライアント200へ送信しても構わないが、アクセス量の少ない夜間にクライアント200へ送信しても良い。例えば、経路検索サーバ100の第1ディスク記憶装置120に貯めていた一日分のログ情報を夜間に送信すれば、アクセス量の多い昼間での経路検索サーバ100の負荷が軽減される。
【0027】
クライアント200は、取得したログ情報を確認して(
図3のステップS20)、ログ情報がない又はエラーがあれば処理を終了する。一方、ログ情報が正常であれば、対象期間のログ情報がまだあるか否かを確認し(
図3のステップS30)、ログ情報が無ければ処理を終了する。
【0028】
ログ情報が存在すれば、クライアント200は、当該ログ情報を経路検索サーバ300を呼べる形式に変換して、経路検索を再現するために経路検索サーバ300に送信する(
図3のステップS40,50)。これにより、経路検索サーバ300は、クライアント200から取得したログ情報から乗り換え案内を作成して、その乗り換え案内結果をクライアント200へ送信する。
【0029】
クライアント200は、乗り換え案内結果を取得して第2ディスク記憶装置に220に格納する(
図3のステップS60)。
【0030】
クライアント200は、取得した乗り換え案内結果のエラーチェックを行い(
図3のステップS70)、エラーがあれば次のログ情報を読み出し(
図3のステップS100)、ステップS30〜S60を実行する。
【0031】
クライアント200は、取得した乗り換え案内結果にエラーがなければ、その乗り換え案内結果から、例えば
図2の左側に示す「駅間利用状況データ」を作成して、第2ディスク記憶装置220に格納する(
図3のステップS80,90)。そして、クライアント200は、次のログ情報を読み出し(
図3のステップS100)、ステップS30〜S90を実行する。このステップS30〜S90の処理を、対象期間のログ情報に対して実行することによって、対象期間の「駅間利用状況データ」を作成することができる。
【0032】
そして、クライアント200は、第2ディスク記憶装置220に格納した「駅間利用状況データ」から混雑度を示した駅間利用状況メッセージを作成して、経路検索サーバ100に渡す。経路検索サーバ100は、乗り換え案内結果に駅間利用状況メッセージを付加して、ネットワーク20を経由して利用者のクライアント端末10a,10b,10cに送信する。
【0033】
ここで混雑度の予測データとして、例えば以下のようなメッセージで表示する。
【0034】
(1)検索対象日の「駅間利用状況データ」から、経路検索を要求した利用者数が多いかどうかで、混雑度を5段階で表示する。即ち、「駅間利用状況データ」の件数の多い状況から純粋に混んでいるかどうかを表示する。
【0035】
(2)集計したデータは曜日などの単位でまとめ、ある対象期間の平均と比較し「普段と比べて」の混雑度を表示する。例えば、「有楽町駅 9時着頃 山手線」が普段より利用が多い場合は、その情報を表示する。例えば、クライアント200の第2ディスク記憶装置220内に、検索対象日の1週間前又は1ヶ月前又は1年前の同一曜日又は同一日の「駅間利用状況データ」の過去データとして記憶しておき、検索対象日の「駅間利用状況データ」と比較することで、混雑度を判断してもよい。また、例えば検索対象日の1年間又は半年間又は1ヶ月間又は1週間の「駅間利用状況データ」を平均した過去データとして記憶しておき、検索対象日の「駅間利用状況データ」と比較することで、混雑度を判断してもよい。
【0036】
(3)上記(2)の場合に、クライアント200に予めイベントデータを取り込み、そのイベントデータとの紐付けができれば、その情報も出力する。例えば「9時より国際フォーラムで「就職説明会」が開催されています。これによりこの時間帯は混雑する可能性があります」など。
【0037】
図2の右側には、左側の駅間利用状況データに基づいて作成した乗り換え案内表示の一例を示している。立川駅の出発時刻の時間帯における、カウント値と1年間又は半年間又は1ヶ月間の「駅間利用状況データ」を平均した過去データとを比較して「混雑度「4」 普段通り、混雑しています。四ッ谷駅から混雑が緩和されます」のメッセージを利用者のクライアント端末10a,10b,10cに乗り換え案内結果と同時に表示させる。また、東京駅では、図示していない山手線の「駅間利用状況データ」を基に、「混雑度「5」 普段より混雑する可能性があります。9時着が多く検索されています。有楽町駅でイベントがある可能性があります」のメッセージを利用者のクライアント端末10a,10b,10cに表示させる。
【0038】
また、利用者のクライアント端末10a,10b,10cの画面に「混雑度予測」ボタンを設け、当該ボタンを利用者がクリックした時だけ、混雑度の予測メッセージを提供するようにしてもよい。
【0039】
したがって、実施形態によれば、経路検索条件のログ情報を用いて乗り換え案内の駅間利用状況データを作成することで、乗り換え案内区間の混雑度を予測して利用者にメッセージ提供することができるため、利用者は、混雑を避けた移動を計画することができ、精神的な苦痛を避けることができる。
【0040】
図4は、第1の実施形態の第1変形例を示している。
図1では、駅間利用状況データ作成を司るものとして、駅間利用状況データ作成用クライアント200と駅間利用状況データ作成用経路検索サーバ300とに分けた構成としたが、
図4に示すように1つのサーバ装置400にて構成してもよい。このような構成によれば、1つのサーバ装置400によって、乗り換え案内の作成、「駅間利用状況データ」の作成を実行するため、
図3のステップS50,S60を省略することができる。
【0041】
図5、第1の実施形態の第2変形例を示している。
図5では、駅間利用状況データ作成用経路検索サーバ300を無くした構成としている。このような構成とした場合、
図3のステップS10では、クライアント200は、経路検索サーバ100からログ情報と乗り換え案内情報の両方を取得することになる。また、
図3のステップS40,S50,S60,S70を省略することができる。
【0042】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【0043】
10a,10b,10c‥クライアント端末、
20‥ネットワーク
100‥経路検索サーバ
110‥第1処理装置
120‥第1ディスク記憶装置
200‥駅間利用状況データ作成用クライアント
210‥第2処理装置
220‥第2ディスク記憶装置
300‥駅間利用状況データ作成用経路検索サーバ
310‥第3処理装置
320‥第3ディスク記憶装置