特許 6367544 情報処理システム、情報処理方法および情報処理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6367544

(24)【登録日】2018年7月13日

(45)【発行日】2018年8月1日

(54)【発明の名称】情報処理システム、情報処理方法および情報処理プログラム

(51)【国際特許分類】

   G08G 1/00 20060101AFI20180723BHJP

   G01C 21/34 20060101ALI20180723BHJP

   G09B 29/00 20060101ALI20180723BHJP

   G09B 29/10 20060101ALI20180723BHJP

【ＦＩ】

   G08G1/00 C

   G01C21/34

   G09B29/00 F

   G09B29/10 A

【請求項の数】10

【全頁数】21

(21)【出願番号】特願2013-253188(P2013-253188)

(22)【出願日】2013年12月6日

(65)【公開番号】特開2015-111343(P2015-111343A)

(43)【公開日】2015年6月18日

【審査請求日】2016年11月22日

(73)【特許権者】

【識別番号】500168811

【氏名又は名称】株式会社ナビタイムジャパン

(74)【代理人】

【識別番号】230104019

【弁護士】

【氏名又は名称】大野 聖二

(74)【代理人】

【識別番号】100167933

【弁理士】

【氏名又は名称】松野 知紘

(72)【発明者】

【氏名】吉 永 智 則

【審査官】 田中 純一

(56)【参考文献】

【文献】 特開２００８−１０２０４６（ＪＰ，Ａ）

【文献】 特開２００４−１４４５３１（ＪＰ，Ａ）

【文献】 特開２００８−００２９６８（ＪＰ，Ａ）

【文献】 特開２０１３−００２８４４（ＪＰ，Ａ）

【文献】 特開２００６−２７７１０９（ＪＰ，Ａ）

【文献】 特開２００２−２１３９８２（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１０／０３０５８５２（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０８Ｇ １／００ − ９９／００

Ｇ０１Ｃ ２１／００ − ２１／３６

Ｇ０１Ｃ ２３／００ − ２５／００

Ｇ０９Ｂ ２３／００ − ２９／１４

(57)【特許請求の範囲】

【請求項1】

複数の経路情報のそれぞれについて当該経路情報における目的地を出発地とする復路を推定し、複数の復路情報を生成する復路情報推定手段と、
前記複数の復路情報のうち少なくとも一部を用いて移動需要分析を行う移動需要分析手段と、を備える情報処理システム。

【請求項2】

前記移動需要分析手段は、前記複数の復路情報のうち少なくとも一部に含まれる停留地点または路線を移動需要分析の対象とする、請求項１に記載の情報処理システム。

【請求項3】

前記複数の経路情報のそれぞれが往路であるか否かを判定する往路判定手段を備え、
前記復路情報推定手段は、前記往路であると判定された経路情報について、前記復路情報を生成する、請求項１または２に記載の情報処理システム。

【請求項4】

前記移動需要分析手段は、移動需要分析を行って移動需要情報を生成し、
当該情報処理システムは、生成された前記移動需要情報を、この移動需要情報と関連する端末装置に送信する情報送信手段を備える、請求項１乃至３のいずれかに記載の情報処理システム。

【請求項5】

前記復路情報推定手段は、復路情報を生成するための探索条件を設定し、この探索条件に基づいて経路探索を行って前記復路を推定する、請求項１乃至４のいずれかに記載の情報処理システム。

【請求項6】

前記復路情報推定手段は、
前記経路情報における出発地、
前記経路情報における目的地、
前記目的地に関連するイベント情報、
前記経路情報の生成を要求したユーザの情報、および
気象情報、
のうち少なくとも１つを考慮して、前記探索条件を設定する、請求項５に記載の情報処理システム。

【請求項7】

前記複数の経路情報のそれぞれは、経路情報データベースに記録されており、
当該情報処理システムは、
経路探索要求を取得する探索要求取得手段と、
前記経路探索要求に基づいて経路探索を行い、経路情報を生成する経路探索手段と、
前記生成された経路情報が、前記経路情報データベースに記録された前記複数の経路情報のいずれかについての復路であるか否かを判定する復路判定手段と、を備え、
前記移動需要分析手段は、前記復路であると判定された経路情報を、前記復路情報として用いて移動需要分析を行う、請求項１乃至６のいずれかに記載の情報処理システム。

【請求項8】

前記復路情報推定手段は、ある経路情報についての復路であると判定された経路情報と、当該ある経路情報から推定して生成された前記復路情報と、の差分に基づいて、その後の復路情報生成を行う、請求項７に記載の情報処理システム。

【請求項9】

復路情報推定手段が、複数の経路情報のそれぞれについて当該経路情報における目的地を出発地とする復路を推定し、複数の復路情報を生成するステップと、
移動需要分析手段が、前記複数の復路情報のうち少なくとも一部を用いて移動需要分析を行うステップと、を備える情報処理方法。

【請求項10】

コンピュータを、
複数の経路情報のそれぞれについて当該経路情報における目的地を出発地とする復路を推定し、複数の復路情報を生成する復路情報推定手段、および
前記複数の復路情報のうち少なくとも一部を用いて移動需要分析を行う移動需要分析手段として機能させるための情報処理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理システム、情報処理方法および情報処理プログラムに関する。

【背景技術】

【0002】

外出の際に、目的地の混雑状況を知りたいことがある。このような課題にこたえるべく、特許文献１には、過去の検索履歴に基づいて目的地の混雑状況を予測し、混雑状況を地図上に表示する地図表示装置が開示されている。また、特許文献２には、検索を行う現在の日付に検索された他の端末からの施設検索履歴に基づいて、混雑状況を判断する情報出力端末が開示されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１１−１１８１１０号公報

【特許文献2】特開２０１０−１６９４４１号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

上記の特許文献１に記載の地図表示装置および特許文献２に記載の情報出力端末では、検索履歴に基づいて混雑状況を予測するため、検索履歴がなければ混雑状況を予測することができない。

【0005】

一般に、ユーザは移動の度に検索を行うとは限らない。例えば、ある目的地まで移動する際、往路を検索することはよくあるが、復路は検索しないことも多い。往路の逆の経路で移動すればよいためである。

【0006】

そうすると、特許文献１，２に記載の技術では、復路に関する混雑状況を予測することはできないという問題がある。

【0007】

本発明は上記の問題点に鑑みてなされたものであり、その目的は、復路についての経路探索が行われない場合であっても復路の移動需要情報を生成できる情報処理システム、情報処理方法および情報処理プログラムを提供するものである。

【課題を解決するための手段】

【0008】

本発明の一態様によれば、複数の経路情報のそれぞれについて復路を推定して、複数の復路情報を生成する復路情報推定手段と、前記複数の復路情報のうち少なくとも一部を用いて移動需要分析を行う移動需要分析手段と、を備える情報処理システムが提供される。

【発明の効果】

【0009】

本発明によれば、復路を推定するため、復路についての経路探索が行われない場合であっても、復路の移動需要情報を生成できる。

【図面の簡単な説明】

【0010】

【図1】本発明の第１の実施形態に係るサーバ２の概略構成を示すブロック図。

【図2】イベント情報データベース２２２のデータ構造の一例を示す図。

【図3】ユーザ情報データベース２２４のデータ構造の一例を示す図。

【図4】経路情報データベース２２１のデータ構造の一例を示す図。

【図5】経路情報データベース２２１のデータ構造の別の例を示す図。

【図6】復路情報データベース２２５のデータ構造の一例を示す図。

【図7】復路情報データベース２２５のデータ構造の別の例を示す図。

【図8】図１のサーバ２の処理動作の一例を示すフローチャート。

【図9】本発明の第２の実施形態に係るサーバ２ａの概略構成を示すブロック図。

【図10】図９のサーバ２ａの処理動作の一例を示すフローチャート。

【図11】本発明の第３の実施形態に係る情報処理システムの概略構成を示すブロック図。

【図12】本発明の第３の実施形態に係る情報処理システムの概略構成を示すブロック図。

【図13】出力部１４に表示される移動需要情報の一例を示す図。

【図14】出力部１４に表示される移動需要情報の別の例を示す図。

【図15】出力部１４に表示される移動需要情報のまた別の例を示す図。

【図16】出力部１４に表示される移動需要情報のまた別の例を示す図。

【図17】出力部１４に表示される移動需要情報のまた別の例を示す図。

【発明を実施するための形態】

【0011】

以下、本発明に係る実施形態について、図面を参照しながら具体的に説明する。

【0012】

（第１の実施形態）
図１は、本発明の第１の実施形態に係るサーバ２の概略構成を示すブロック図である。サーバ２は、通信部２１と、記憶部２２と、制御部２３とを備える情報処理装置である。

【0013】

通信部２１は、ユーザが使用する端末装置（不図示）など、外部の装置とネットワークを介して通信を行うインターフェースである。

【0014】

記憶部２２は例えばハードディスク等の固定型データストレージであり、経路情報データベース２２１、イベント情報データベース２２２、経路ネットワーク情報データベース２２３１、地図情報データベース２２３２、ＰＯＩ情報データベース２２３３、ユーザ情報データベース２２４および復路情報データベース２２５を格納する。

【0015】

経路情報データベース２２１は制御部２３により生成される経路情報を蓄積したデータベースである。経路情報データベース２２１のデータ構造の例は図４および図５を用いて後述する。

【0016】

イベント情報データベース２２２はイベントに関する情報を蓄積したデータベースである。イベント情報データベース２２２のデータ構造の一例を図２に示している。図示のように、イベント情報データベース２２２は、イベントＩＤをインデックスとして、インベントが開催されるイベント会場と、イベント内容と、イベントの開始日時および終了日時とが関連付けられている。開始日時はイベントそのものの開始日時でもよいしイベント会場の開場日時であってもよい。終了日時はコンサートのようにある程度確定している情報であるのが望ましい。スポーツのように終了日時が確定できない場合は、平均的な試合時間や試合内容（対戦チームや出場予定選手など）などから推定される日時でもよいし、終了日時の情報が含まれなくてもよい。また、展示会など、イベントが開始日時から終了日時まで複数日におよぶこともあってもよい。

【0017】

図１に戻り、経路ネットワーク情報データベース２２３１は、経路ネットワーク情報として、例えば交通ネットワーク情報を含んでおり、経路探索に用いられる。

【0018】

交通ネットワーク情報は鉄道やバス等の交通網や道路網を規定する情報である。交通網の情報としては、交通機関の路線情報、時刻表情報、料金情報等を含む。道路網の情報は、例えば交差点等の道路網表現上の結節点であるノードのデータと、ノード間の道路区間であるリンクのデータとの組み合わせによって表現される。

【0019】

地図情報データベース２２３２は、全国および各地方の道路地図などの地図データと、地図データに対応付けられた地図オブジェクト情報を含む。地図データは道路を表した地図である。地図オブジェクト情報とは、地図上に表示される施設の形状についての形状情報、地図上に表示される注記についての注記情報、地図上に表示される記号についての記号情報などである。地図情報データベース２２３２は地図を描画するために用いられる。

【0020】

ＰＯＩ情報データベース２２３３はＰＯＩ（Point Of Interest）の位置情報などを含む。ここで、ＰＯＩの位置（座標）情報は、ＰＯＩの位置座標、ＰＯＩの電話番号、ＰＯＩの住所、ならびに、ＰＯＩの存在する地点の立地（都市部、郊外、港湾部、および、駅周辺等）および用途制限等を含んでいる。また、ＰＯＩ情報は、ＰＯＩの名称、種別（カテゴリ）、ＵＲＬ、営業時間、取扱商品、平均価格（例えば、平均使用料金など）、評判、ランキング、立ち寄りやすさ、レコメンドスコア、写真データ、クーポン情報、口コミ（例えば、口コミ評価およびユーザコメントなど）、使用条件、使用可能性、施設規模、ＰＯＩ ＩＤ、当該ＰＯＩ情報へのアクセス回数またはアクセス頻度等の参照率、および、当該ＰＯＩ情報の更新日時等の情報を含んでいる。ＰＯＩ情報は地点検索やＰＯＩの詳細情報を参照するために用いられる。

【0021】

ここで、ＰＯＩとは、便利な場所や興味のある場所などとして人が知覚する特定の地点および施設などであって、店舗（例えば、コンビニエンスストア、ガソリンスタンド、飲食店等）、会社、事務所、公共施設（例えば、官庁、学校、駅）、娯楽施設（例えば、映画館、劇場、遊園地等）、および、屋外施設（例えば、公園、バスターミナル、屋外駐車場等）等である。また、ＰＯＩは、一時的に行われるイベント（例えば、祭り、コンサート、フリーマーケット、スポーツの試合等）のに関する情報であってもよい。

【0022】

ユーザ情報データベース２２４は各端末装置のユーザ情報を蓄積したデータベースである。ユーザ情報データベース２２４のデータ構造の一例を図３に示している。図示のように、ユーザＩＤをインデックスとして、自宅、自宅の最寄駅、勤務（通学）地、勤務（通勤）地の最寄駅、通勤（通学）経路、お気に入り地点、お気に入り探索条件、イベント後の行動パターン（イベント後に特定の地点に立ち寄る傾向があるか否かなど）などが関連付けられている。お気に入り探索条件は、通常時の探索条件（例えば時間を優先するか、料金を優先するか）と、イベント復路用の探索条件（例えば混雑しない経路を優先する）とを別個に設定されていてもよい。

【0023】

これらのユーザ情報は、ユーザ自ら予め登録しておいてもよいし、ユーザの行動履歴や検索履歴などからサーバ２が自動で取得してもよい。

【0024】

図１に戻り、復路情報データベース２２５は復路情報を蓄積したものである。復路情報とは、経路情報データベース２２１に蓄積された経路情報のそれぞれに対応する復路を示す情報であり、制御部２３により生成される。復路情報データベース２２５のデータ構造の例は、図６を用いて後述する。

【0025】

なお記憶部２２を必ずしもサーバ２内に設けなくてもよい。すなわち、各データベースの少なくとも一部をネットワークを介して接続される別個の装置内に記憶してもよい。

【0026】

続いて、制御部２３について説明する。制御部２３は、探索要求取得部２３１と、経路探索部２３２と、往路判定部２３３と、復路情報推定部２３４と、分析対象設定部２３５と、移動需要分析部２３６とを有する。これらの各部の機能は、サーバ２内のプロセッサ（不図示）が所定のプログラムを実行することによって実現されてもよい。

【0027】

探索要求取得部２３１はネットワークおよび通信部２１を介して端末装置から探索要求を取得する。探索要求には探索条件が含まれる。探索条件は、少なくとも出発地および目的地を含んでおり、１または複数の経由地を含んでいてもよい。また、探索条件は出発希望日時または到着希望日時を含んでいる。さらに、探索条件は、有料道路を使用するか否か、特急列車を使用するか否か、などの条件を含んでいてもよい。

【0028】

経路探索部２３２は、探索条件に基づき、経路ネットワーク情報データベース２２３１を参照して経路探索を行う。これにより、出発地から目的地までの経路を示す経路情報が生成される。経路情報は１または複数の交通手段の組み合わせにより構成される。探索要求が出発希望日時を含んでいた場合、経路情報には到着予定日時が含まれる。一方、探索要求が到着希望日時を含んでいた場合、経路情報には出発予定日時が含まれる。

【0029】

往路判定部２３３は生成された経路情報が示す経路が往路であるか否かを判定する。

【0030】

一例として、往路判定部２３３はイベント情報データベース２２２を参照して判定を行ってもよい。より具体的には、経路情報における目的地がイベント情報データベース２２２に登録されたイベント会場である場合に、往路判定部２３３は当該経路が往路であると判定してもよい。より正確に判定するために、経路情報における目的地がイベント会場であり、かつ、到着希望（予定）日時がイベントの開始日時に近い場合に、往路判定部２３３は往路であると判定してもよい。また、目的地がイベント会場近辺のホテルなどである場合に、往路判定部２３３は当該経路が往路であると判定してもよい。

【0031】

また、目的地に対応するＰＯＩが、ＰＯＩ情報においてイベント会場にカテゴライズされている場合、イベント情報データベース２２２を参照しなくても、往路判定部２３３は当該経路が往路であると判定することができる。

【0032】

別の例として、往路判定部２３３はユーザ情報データベース２２４を参照して判定を行ってもよい。より具体的には、経路情報における出発地がユーザの自宅や勤務地（あるいはそれらの最寄駅）などである場合、往路判定部２３３は当該経路が往路であると判定してもよい。逆に、目的地がユーザの自宅や勤務地である場合は、往路判定部２３３は当該経路が往路ではないと判定してもよい。あるいは、経路情報における目的地がユーザの勤務地である場合に、往路判定部２３３は当該経路が往路であると判定してもよい。

【0033】

また、往路判定部２３３はイベント情報データベース２２２およびユーザ情報データベース２２４の両方を参照して判定を行ってもよい。例えば、経路情報における出発地がユーザの自宅や勤務地であり、かつ、目的地がイベント会場である場合に、往路判定部２３３は当該経路が往路であると判定してもよい。これにより判定の精度を向上できる。

【0034】

あるいは、往路判定部２３３は、探索により得られた経路ではなく、探索条件のみに基づいて簡易に往路判定を行ってもよい。

【0035】

以上、探索要求取得部２３１、経路探索部２３２および往路判定部２３３の処理を経て、経路情報データベース２２１が生成される。

【0036】

図４は、経路情報データベース２２１のデータ構造の一例を示す図である。この経路情報データベース２２１では、経路情報ＩＤをインデックスとして、端末ＩＤ、探索実行日時、地点情報、時刻情報および往路フラグが関連付けられている。

【0037】

端末ＩＤは経路探索要求を行った端末装置を特定するものである。なお、端末装置を特定するＩＤに代えて、経路探索要求を行ったユーザを特定するユーザＩＤであってもよい。探索実行日時は、探索要求に応じて経路探索部２３２が経路探索を行った日時である。

【0038】

地点情報は、経路情報における出発地および目的地を少なくとも含んでおり、さらに１または複数の経由地を含んでいてもよい。各地点情報の表現法は任意であり、駅名、施設名、住所、緯度および経度などにより表されることができる。また、ユーザ情報と紐づけて、ユーザの自宅や勤務先などで地点情報を表現してもよい。

【0039】

時刻情報は、出発予定日時および到着希望日時の組、または、出発希望日時および到着予定日時の組を含んでいる。すなわち、出発希望日時が探索条件として設定された経路情報の場合には前者の組が含まれ、到着希望日時が探索条件として設定された経路情報の場合には後者の組が含まれる。また、時刻情報は経由予定日時を含んでいてもよい（不図示）。

【0040】

また、図４の経路情報データベース２２１の特徴として、各経路情報が往路であるか否かを示す往路フラグが含まれる。往路フラグは往路判定部２３３による判定結果に基づくものである。

【0041】

図５は、経路情報データベース２２１のデータ構造の別の例を示す図である。この経路情報データベース２２１では、往路判定部２３３により往路であると判定された経路情報のみが蓄積される。よって、図５の経路情報データベース２２１は往路フラグを含んでいなくてもよい。

【0042】

いずれにしても、経路情報データベース２２１には往路である経路を示す経路情報が蓄積される。なお、以上はサーバ２自身が経路探索を行って経路情報データベース２２１を生成する例であるが、予め経路情報データベース２２１が生成されてサーバ２の外部に蓄積されていてもよい。後者の場合、以降の復路情報推定部２３４などは、外部に蓄積された経路情報データベース２２１を参照して処理を行えばよい。

【0043】

図１に戻り、復路情報推定部２３４は、経路情報データベース２２１に蓄積された往路である経路のそれぞれについて、その復路を示す復路情報を生成する。一例として、復路情報推定部２３４は、復路情報推定用の探索条件を設定し、経路ネットワーク情報データベース２２３１を参照して経路探索を行うことにより、復路情報を生成する。復路情報用の探索条件は、単純には、往路である経路の出発地および目的地を入れ替えたものとすることができる。また、出発時刻をイベントの終了時刻とすることができる。

【0044】

しかしながら、復路情報推定部２３４は、以下のように探索条件における出発地や目的地を補正してもよいし、適宜経由地を追加してもよい。また、復路情報推定部２３４は探索条件における日時情報を補正してもよい。

【0045】

例えば、復路情報推定部２３４は、ユーザ情報データベース２２４を参照し、復路情報推定用の探索条件の少なくとも一部を設定してもよい。具体例として、往路の出発地がユーザの勤務先であっても、ユーザの自宅を復路の目的地に設定してもよい。また、往路の目的地がユーザの勤務地である場合、当該勤務地を復路の出発地に設定し、ユーザの自宅を復路の目的地に設定するとともに、勤務終了時刻に基づいて出発時刻を設定してもよい。勤務終了時刻は、予めユーザ情報データベース２２４に登録されていてもよいし、ユーザの行動パターンから推定してもよい。

【0046】

あるいは、イベント後行動パターンに応じて、特定の場所（お気に入りの居酒屋など）が登録されている場合、経由地としてその特定の場所を設定してもよい。あるいは、特定の場所でなくても、立ち寄る場所に何らかの傾向（チェーン店の喫茶店、観光地など）がある場合、そのような場所を検索して経由地に設定してもよい。また、ユーザ情報データベース２２４がイベント復路用のお気に入り探索条件を含んでいる場合、この探索条件を考慮してもよい。

【0047】

また、復路情報推定部２３４は、イベント情報データベース２２２を参照し、復路情報推定用の探索条件の少なくとも一部を設定してもよい。具体例として、イベントの終了時間や、イベント会場が閉じる時刻に応じて、出発日時を設定してもよい。イベント情報データベース２２２にイベントの終了日時についての情報がない場合、イベント内容から推定して出発日時を設定してもよい。例えば、花見やショッピングの場合は平均的な滞在時間と、往路の到着時刻とから、復路の出発日時を設定してもよい。

【0048】

さらに、イベント会場の近辺に店や観光地などの立ち寄り地点がある場合、一部のユーザが立ち寄り地点に立ち寄るとして、復路情報推定用の探索条件を設定してもよい。例えば、インベント会場であるＴ野球場の近辺に、大型店舗Ａ、小型店舗Ｂ、観光地Ｃがある場合、任意の１％のユーザについては店舗Ａを経由地とし、任意の０．１％のユーザについては店舗Ｂを経由地とし、任意の０．５％のユーザについては観光地Ｃを経由地としてもよい。

【0049】

その他、一部のユーザは混雑を避ける経路を選択することも考えられるため、例えば任意の７％のユーザについては混雑を避ける経路を優先する探索条件とし、他のユーザについては短時間で移動できる経路を優先する探索条件としてもよい。

【0050】

もちろん、復路情報推定部２３４は、イベント情報データベース２２２およびユーザ情報データベース２２４の両方を参照して、復路情報推定用の探索条件の少なくとも一部を設定してもよい。例えば、イベントの終了時間に出発したのでは、ユーザの自宅まで終電に間に合わないこともあり得る。そのような場合には、イベント会場からユーザの自宅まで終電で移動することを探索条件として設定してもよい。

【0051】

その他、復路情報推定部２３４は気象情報を考慮して復路情報推定用の探索条件を設定してもよい。例えば、雨の予報である場合には、どこも経由せずにイベント会場から自宅へ移動する探索条件としてもよい。また、復路情報推定部２３４はイベントの結果を考慮して復路情報推定用の探索条件を設定してもよい。例えば、イベントが日本チームと外国チームとのスポーツの試合であって、日本チームが勝った場合には上記のように経由地を設定し、日本チームが負けた場合にはどこも経由せずにイベント会場から自宅へ移動する探索条件としてもよい。

【0052】

図４および図５を用いてより具体的な例を示す。経路情報ＩＤが００２である経路情報では、目的地がＴ野球場であり、到着希望日時が２０１３年１月１２日１２時である。図２を参照すると、同日の１２時３０分からＴ野球場で野球の試合が開催される。そこで、復路情報推定部２３４は、出発地をＴ野球場、目的地をＨ駅（経路情報ＩＤが００２である経路情報における出発地）、出発時刻を１６時（野球の平均試合時間が３時間強であるため）として経路探索を行い、復路情報を生成する。

【0053】

生成された復路情報は復路情報データベース２２５に蓄積される。復路情報データベース２２５のデータ構造の一例を図６に示す。復路情報データベース２２５では、復路情報ＩＤをインデックスとして、対応する経路情報ＩＤと、地点情報と、時刻情報とが関連付けられている。

【0054】

対応する経路情報ＩＤとは、図４または図５などの経路情報データベース２２１におけるどの経路情報に対する復路情報であるかを示している。例えば、図６における復路情報ＩＤが３０１である復路情報は、図４または図５における経路情報ＩＤが００２である経路情報を往路とする復路である。地点情報および時刻情報は、経路情報データベース２２１におけるものと同様である。

【0055】

また、復路情報推定部２３４は、１つの往路に対して、複数の復路を推定してもよい。この場合、復路情報推定部２３４は複数の復路のそれぞれに重み係数を設定する。重み係数の和が１になるようにする。復路の候補が複数あり、いずれか１つに特定できない場合に特に有効な手法である。なお、重み係数は、復路の数で等分してもよいし、ランダムに割り振ってもよいし、実際に使用される可能性が高い復路（移動に要する時間が短い経路や、料金が安い経路など）ほど重み係数を大きくしてもよい。

【0056】

図７は、復路情報データベース２２５のデータ構造の別の例を示す図であり、復路情報推定部２３４が１つの復路に対して１または複数の復路を推定する場合のものである。経路情報ＩＤが００５である経路情報に対して、４つの復路、すなわち、復路情報ＩＤが３０３１〜３０３４の復路が推定されている。そして、重み係数は、順に、０．５，０．３，０．１，０．１に設定されている。この重み係数を考慮して、後の移動需要分析が行われる。なお、１つの往路から１つのみの復路が推定された場合、その重み係数は１とする。

【0057】

図１に戻り、分析対象設定部２３５は、移動需要分析部２３６によって行われる移動需要分析の対象となる分析対象を設定する。分析対象には場所と日時が含まれる。分析対象は、例えば「２０１３年１月１２日１５時〜１８時のＴ野球場」などと設定される。

【0058】

分析対象の場所とは、特定の地点、エリア、区間などである。ここで地点は、出発地・経由地・目的地などの停留地点であり、駅名、ＰＯＩの名称、緯度・経度・高度、住所、および電話番号等の情報で表されてもよい。エリアは、「Ａ駅周辺」、「Ｂ市」、「Ｃ地方」などで表されてもよい。また、区間は、路線や道路などである。

【0059】

分析対象の日時とは、日付や時刻、期間等の情報で表されてもよい。そのほか、時間帯や曜日、移動体種別、利用者属性などのあらゆる情報を分析対象として、その一または複数を組み合わせて分析対象としてもよい。

【0060】

分析対象は予め定められたものでもよい。また、分析対象は、ユーザにより設定された分析対象を端末装置から、分析対象設定部２３５が受け付けたものであってもよい。あるいは、分析対象は、サーバ２の外部から、分析対象設定部２３５が取得したものであってもよい。

【0061】

移動需要分析部２３６は、復路情報データベース２２５に蓄積された復路情報に基づいて、分析対象の移動需要を分析し、移動需要情報を生成する。移動需要情報とは、分析対象の混雑度や利用人数などに関する情報である。以下、移動需要情報の生成について、より具体的に説明する。

【0062】

まず移動需要分析部２３６は設定された分析対象に関連する復路情報を復路情報データベース２２５から抽出する。

【0063】

例えば分析対象が「２０１３年１月１２日１５時〜１８時のＴ野球場」であったとする。この場合、移動需要分析部２３６は、上記「２０１３年１月１２日１５時〜１８時」の範囲内に「Ｔ野球場」（およびその最寄駅）を出発する、経由する、または、到着する復路情報を抽出する。図６の例では、復路情報ＩＤが３０１の復路情報が抽出される。なお、日時の範囲には設定された日時に所定のマージンを加えたものであってもよい。さらに分析対象の日時と、他の日時との比較を行うために、移動需要分析部２３６は、分析対象の日時の範囲外に「Ｔ野球場」を出発などする復路情報を抽出してもよい。

【0064】

続いて、移動需要分析部２３６は抽出された経路情報に対して統計処理などを行って、移動需要情報を生成する。

【0065】

具体的な処理の例としては、移動需要分析部２３６は抽出された復路情報の数に基づいて混雑度を算出してもよい。さらに、移動需要分析部２３６は、抽出された復路情報の数を、予め保持している通常時（イベントが開催されない時）の数と比較してもよい。あるいは、移動需要分析部２３６は、抽出された復路情報の数を、分析対象のキャパシティなどの情報と比較してもよい。得られる移動需要は、数値で表されてもよいし、数値に基づく評価（例えば、混雑度：高、混雑度：中）で表されてもよい。

【0066】

図７に示すように、各往路に重み係数が設定されている場合、重み係数を考慮して復路情報の数をカウントしてもよい。図７の例において、「Ｔ野球場」を含む復路の数は１．５となる。

【0067】

このような移動需要分析の結果、復路情報の少なくとも一部（すなわち抽出された復路情報）に含まれる分析対象場所における、分析対象日時の移動需要が予測される。

【0068】

図８は、図１のサーバ２の処理動作の一例を示すフローチャートである。探索要求取得部２３１が端末装置から探索要求を受信すると（ステップＳ１）、経路探索部２３２は探索条件に基づいて経路探索を行う（ステップＳ２）。そして、往路判定部２３３は、必要に応じて、イベント情報データベース２２２やユーザ情報データベース２２４を参照し、生成された経路情報が往路であるか否かを判定する（ステップＳ３）。

【0069】

以上の処理の結果が、経路情報データベース２２１に記録される（ステップＳ４）。このとき、図４に示すように、往路か否かの判定結果を示すフラグとともに経路情報が記録されてもよいし、図５に示すように、往路と判定された経路情報のみが記録されてもよい。

【0070】

続いて、復路情報推定部２３４は、往路である経路情報から復路を推定し、復路情報を生成する（ステップＳ５）。復路情報は復路情報データベース２２５に記録される（ステップＳ６）。

【0071】

サーバ２は、移動需要分析を開始するまで、以上の処理を行う（ステップＳ７のＮＯ）。なお、復路情報推定部２３４は、１つの経路情報が生成される度に、対応する復路情報を生成してもよい。また、定期的に、あるいは、経路情報が一定数集まった段階で、復路情報推定部２３４が復路情報を生成してもよい。もしくは、移動需要分析を開始する時点で、復路情報推定部２３４が復路情報を生成してもよい。

【0072】

続いて、サーバ２は移動需要分析を開始する（ステップＳ７のＹＥＳ）。そのタイミングは任意であり、定期的に移動需要分析を行ってもよいし、外部からの要求に応じて移動需要分析をおこなってもよい。

【0073】

移動需要分析を行うために、まず分析対象設定部２３５は分析対象を設定する（ステップＳ８）。次いで、移動需要分析部２３６は、設定された分析対象に関連する復路情報を、復路情報データベース２２５から取得する（ステップＳ９）。そして、移動需要分析部２３６は、取得された復路情報に基づいて移動需要分析を行い、移動需要情報を生成する（ステップＳ１０）。

【0074】

このように、第１の実施形態では、往路である経路情報から復路情報を推定し、推定された復路情報を用いて移動需要情報を生成する。そのため、復路についての経路探索要求がない場合であっても、復路についての移動需要情報を生成できる。

【0075】

（第２の実施形態）
上述した第１の実施形態は、往路である経路情報から推定された復路情報を用いて、移動需要分析を行うものであった。これに対し、以下に説明する第２の実施形態では、復路の経路が実際に探索された場合には、推定された復路情報に代えて、経路探索によって生成された復路情報を用いるものである。

【0076】

図９は、本発明の第２の実施形態に係るサーバ２ａの概略構成を示すブロック図である。図９では、図１と共通する構成部分には同一の符号を付しており、以下では相違点を中心に説明する。

【0077】

図９のサーバ２ａの制御部２３ａは、復路判定部２３７をさらに有する。復路判定部２３７は、探索要求取得部２３１が取得した探索要求に基づいて生成された経路情報が、経路情報データベース２２１に既に記録された往路である経路情報についての復路であるか否かを判定する。例えば以下のようにして、復路判定部２３７は判定する。

【0078】

探索要求には、この探索要求を行った端末装置を特定する端末ＩＤを含めておく。そして、復路判定部２３７は、取得された探索要求に含まれる端末ＩＤが、経路情報データベース２２１に存在するか否かを確認する。存在し、かつ、経路情報データベース２２１における該当する経路情報の目的地が、新たに取得された探索要求における探索条件の出発地と一致している場合に、復路判定部２３７は復路であると判定することができる。

【0079】

復路と判定された場合、復路判定部２３７は、当該探索要求に応じて経路探索部２３２により生成された経路情報を、復路情報として、復路情報データベース２２５に記録する。既に復路情報推定部２３４により復路情報が推定されて復路情報データベース２２５に記録されていることもある。この場合、復路判定部２３７は、既に記録されている推定された復路情報を、実際に経路探索によって生成された新たな復路情報に置換する。

【0080】

図１０は、図９のサーバ２ａの処理動作の一例を示すフローチャートである。図８と共通する処理動作は簡略化して描いている。

【0081】

図８と同様に、探索要求が受信され（ステップＳ１）、経路探索が行われる（ステップＳ２）。そして、生成された経路情報について、往路判定部２３３が往路であるか否かを判定するとともに、復路判定部２３７が復路であるか否かを判定する（ステップＳ３’）。

【0082】

復路でないと判定された場合、以降の処理は図８と同様である。復路であると判定された場合、復路判定部２３７は生成された経路情報を、復路情報として復路情報データベース２２５に記録（あるいは置換）する（ステップＳ６）。以降の処理は、図８と同様である。

【0083】

結果として、復路の経路探索が行われた往路については、推定された復路情報ではなく、実際の経路探索により得られた復路情報が移動需要分析に用いられる。一方、復路の経路探索が行われなかった往路については、推定された復路情報が用いられる。すなわち、移動需要分析部２３６が移動需要分析に用いる復路情報には、推定された復路情報と、実際の復路情報とが混在することもあり得る。

【0084】

このように、第２の実施形態では、復路の経路探索が行われた復路については、実際の経路探索により得られた復路情報を用いるため、より高精度に移動需要分析を行うことができる。

【0085】

なお、経路探索により生成され、復路であると判定された復路情報と、復路情報推定部２３４により推定された復路情報との差分に基づいて、復路情報推定部２３４によるその後の復路推定アルゴリズムをブラッシュアップしてもよい。これにより、復路情報の精度を向上できる。

【0086】

例えば、図３において、ユーザＵ００１のイベント後の行動パターンは「直帰」となっている。しかしながら、実際に経路探索により得られた復路情報では、経由地「Ｇ１店」が含まれていたとする。この場合、復路判定部２３７は、ユーザＵ００１のイベント後行動パターンを「直帰」から「Ｇ１店」に更新する。これにより、復路情報推定部２３４は、この情報を考慮して、次回以降の復路情報推定用の探索条件を設定することになる。

【0087】

あるいは、上述したように、当初は７％のユーザについては復路として混雑を避ける経路を優先する探索条件とし、他のユーザについては短時間で移動できる経路を優先する探索条件としていたとする。ところが、実際の混雑を避ける経路を優先する探索条件としたユーザは３％であった場合、以降は３％のユーザについて混雑を避ける経路を優先する探索条件としてもよい。

【0088】

（第３の実施形態）
以下に説明する第３の実施形態は、生成された移動需要情報を端末装置に送信するものである。

【0089】

図１１は、本発明の第３の実施形態に係る情報処理システムの概略構成を示すブロック図である。情報処理システムは、端末装置１と、サーバ２ｂとを備えている。なお、図１１では簡略化のために１台のみの端末装置１を描いているが、実際には複数の端末装置１がある。図１１では、図１と共通する構成部分には同一の符号を付しており、以下では相違点を中心に説明する。

【0090】

端末装置１はユーザが使用するものであり、携帯電話、スマートフォンもしくはタブレット端末装置等のモバイル電子機器などであってもよいし、パーソナルコンピュータやカーナビゲーション装置等の据え置き型電子機器であってもよい。端末装置１はネットワーク３を介してサーバ２ｂと通信するが、ネットワーク３は有線回線と無線回線のいずれでもよく、回線の種類や形態は問わない。

【0091】

端末装置１は、通信部１１と、操作入力部１２と、出力部１３と、制御部１４とを有する。

【0092】

通信部１１はネットワーク３を介して制御部１４とサーバ２との間で情報を送受信するインターフェースである。

【0093】

操作入力部１２はユーザが端末装置１に操作を入力するためのインターフェースであり、例えばモバイル電子機器におけるタッチパネルやマイク等や、据え置き型電子機器におけるキーボード、タッチパッドもしくはダイヤルボタン等である。操作入力部１２を用いて、ユーザは探索条件を設定したり、探索要求をサーバ２ｂに送信したりする。

【0094】

出力部１３は端末装置１から各種情報を出力するインターフェースであり、例えば映像を表示する液晶ディスプレイである。具体的には、出力部は、ユーザからの操作を受け付けるためのＧＵＩ（Graphical User Interface）や、移動需要情報などを表示する。あるいは、出力部１３は移動需要情報などを音声で出力するスピーカであってもよい。

【0095】

また、出力部１３は情報などをユーザへ直接提示するものでなくてもよい。例えば、出力部１３は、外部に接続される表示手段および／または音声再生手段に映像信号および／または音声信号を出力するものであってもよいし、外部に接続される印刷装置にデータを出力するものであってもよいし、端末装置１内あるいは外部の記憶装置へ出力して記憶させるものでもよい。

【0096】

制御部１４は、情報送信部１４１と、情報受信部１４２とを有する。情報送信部１４１は、探索要求などの情報を、通信部１１からネットワーク３を介してサーバ２ｂへ送信する。情報受信部１４２は、移動需要情報などの情報を、ネットワーク３および通信部１１を介してサーバ２ｂから受信する。

【0097】

また、本実施形態におけるサーバ２ｂの制御部２３ｂは、送信先決定部２３８と、情報送信部２３９とをさらに有する。送信先決定部２３８は、移動需要分析部２３６により生成された移動需要情報を、どの端末装置１に送信するかを決定する。より具体的には、移動需要分析部２３６は、生成された移動需要情報と関連する端末装置１を、送信先の端末装置１として決定する。情報送信部２３９は、決定された端末装置１に、移動需要情報を送信する。

【0098】

なお、端末装置１は個人ユーザが使用するものであってもよいし、店舗や鉄道事業者などの法人ユーザが使用するものであってもよい。後者の場合、一例として端末装置１は店舗に配置され、移動需要に基づいて商品の仕入れ量やスタッフ数を調整するために利用され得る。このような端末装置１の場合、単に移動需要を受信できればよいため、情報送信部１４１を省略してもよい。あるいは、情報送信部１４１を設け、当該店舗の近辺を分析対象とする移動需要情報の生成および配信をサーバ２ｂに要求してもよい。

【0099】

図１２は、図１１の情報処理装置システムの処理動作の一例を示すフローチャートである。図８と共通する部分は簡略化している。移動需要分析部２３６が移動需要分析を行って移動需要情報を生成すると（ステップＳ１０）、送信先決定部２３８は移動需要情報の送信先を決定する（ステップＳ２１）。

【0100】

例えば、送信先決定部２３８は、経路情報データベース２２１における端末ＩＤに基づいて、移動需要分析に用いられた復路情報に対応する往路の探索要求を行った端末装置１を、送信先としてもよい。

【0101】

また、送信先決定部２３８は、ユーザ情報データベース２２４に基づいて、移動需要分析の分析対象を頻繁に利用しているユーザの端末装置１を、送信先としてもよい。

【0102】

あるいは、送信先決定部２３８は、分析対象の近くに自宅や勤務先があるユーザの端末装置１を、送信先としてもよい。また、送信先決定部２３８は、分析対象の近辺にある店舗などの端末装置１を、送信先としてもよい。さらに、送信先決定部２３８は、移動需要が増加する区間の少なくとも一部と、通勤経路（例えば、ユーザ情報データベース２２４に定期区間として登録されている）の少なくとも一部が重なるユーザの端末装置１を、送信先としてもよい。

【0103】

なお、送信先決定部２３８は、分析対象の移動需要が通常時と比較してそれほど高くない場合、どの端末装置１にも移動需要情報を送信しないことにしてもよい。また、送信先決定部２３８は、車両に座れない程度に移動需要が増加した場合に限って、いずれかの端末装置１に移動需要情報を送信することにしてもよい。

【0104】

以上のようにして決定された端末装置１に、情報送信部２３９は移動需要情報を送信する（ステップＳ２２）。一例として、情報送信部２３９は移動需要情報を含むメールを端末装置１へプッシュ配信してもよい。

【0105】

端末装置１の情報受信部１４２はサーバ２ｂから移動需要情報を受信する（ステップＳ３１）。そして、出力部１４は移動需要情報を出力する（ステップＳ３２）。以下、出力部１４がディスプレイであるとして、このディスプレイに表示される画面の例をいくつか挙げる。

【0106】

図１３は、出力部１４に表示される移動需要情報の一例を示す図である。図１３は個人ユーザが使用する端末装置１の出力部１４に表示される移動需要情報を例示している。

【0107】

図１３（ａ）に示すように、分析対象の移動需要が急騰している場合、その旨のメッセージを「混雑予報」として表示してもよい。より具体的には、混雑が見込まれる場所（同図では「ＸＸ線」）、時間（同図では「２２：００頃」）、混雑の原因となるイベント（同図では「ＢＤ館でのコンサート」）を表示するのが望ましい。逆に、図１３（ｂ）に示すように、イベントは開催されるがそれほど移動需要が増えない場合、その旨のメッセージを表示してもよい。

【0108】

このような移動需要情報に基づいて、ユーザは移動の経路や時間帯を検討することができる。

【0109】

図１４は、出力部１４に表示される移動需要情報の別の例を示す図である。図１４（ａ）は鉄道事業者が使用する端末装置１の出力部１４に表示される移動需要情報を例示している。図示のように、どの駅のどのホームの移動需要が急騰しているかを表示することで、移動需要情報を駅員の配置などに利用することができる。

【0110】

図１４（ｂ）は駅構内の店が使用する端末装置１の出力部１４に表示される移動需要情報を例示している。図示のように、移動需要が急騰していることを表示することで、移動需要情報を商品の在庫調整などに利用することができる。

【0111】

図１５は、出力部１４に表示される移動需要情報のまた別の例を示す図である。同図の横軸は時刻である。縦軸は、ある１つの分析対象地点または区間について、ステップＳ９で取得された復路情報の数である。このように、分析対象の地点または区間における時刻毎の混雑予測情報を、移動需要情報として表示してもよい。

【0112】

図１６は、出力部１４に表示される移動需要情報のまた別の例を示す図である。同図の横軸は時刻である。縦軸は、ある２つの分析対象地点または区間（同図の例では、Ｔ野球場とＢＤ館）について、ステップＳ９で取得された復路情報の数である。このように、複数の分析対象の地点または区間における時刻毎の混雑予測情報を、移動需要情報として表示してもよい。これにより、ユーザは、どの地点あるいは区間が相対的に混雑しているかを容易に比較できる。

【0113】

図１７は、出力部１４に表示される移動需要情報のまた別の例を示す図である。同図の横軸は時刻である。縦軸は、ある１つの分析対象地点または区間について、ステップＳ９で取得された復路情報の数であり、より詳しくは、分析対象日時における復路情報の数と、平均的な復路情報の数とを示している。これにより、イベントが開催されるときと、開催されないときとで、混雑状況を容易に比較できる。

【0114】

なお、平均的な復路情報の数とは、分析対象日時以外の日時における復路情報の数の平均値である。この数は、所定期間における平均でもよいし、所定期間における分析対象日時と類似する属性（曜日、祝日、天気など）の日時における平均でもよい。

【0115】

このように、第３の実施形態では、移動需要情報を、関連するユーザの端末装置１に送信する。そのため、ユーザは自身に関する分析対象の移動需要を把握できる。

【0116】

なお、移動需要分析の分析対象を含む経路を探索したユーザの端末装置１を送信先とする場合、情報送信部２３９は、そのような経路探索が要求されたタイミングで、要求を行った端末装置１に移動需要情報を送信してもよい。

【0117】

また、図１１のサーバ２ｂ内に、第２の実施形態における復路判定部２３７を設けて、第２の実施形態と第３の実施形態とを組み合わせてもよい。

【0118】

上述した各実施形態では、経路情報が経路探索の結果である例を示しているが、経路探索要求に含まれる探索条件を経路情報として用いてもよい。

【0119】

なお、図１などでは、１つのサーバ２内に記憶部２２および制御部２３を設ける例を示している。しかしながら、各データベースや処理部の少なくとも一部を、ネットワーク接続された他の装置内に設けてもよい。この場合、通信部２１が他の装置と通信することで、図１と同等の機能を実現できる。図１のように１台の装置内にすべての構成を設ける場合であっても、複数の装置に分散して設ける場合であっても、「システム」と表現することができる。

【0120】

上述した実施形態で説明した情報処理システムの少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、情報処理システムの少なくとも一部の機能を実現するプログラムをフレキシブルディスクやＣＤ−ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。

【0121】

また、情報処理システムの少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。

【0122】

上記の記載に基づいて、当業者であれば、本発明の追加の効果や種々の変形を想到できるかもしれないが、本発明の態様は、上述した個々の実施形態には限定されるものではない。特許請求の範囲に規定された内容およびその均等物から導き出される本発明の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。

【符号の説明】

【0123】

１ 端末装置
１１ 通信部
１２ 操作入力部
１３ 出力部
１４ 制御部
１４１ 情報送信部
１４２ 情報受信部
２，２ａ，２ｂ サーバ
２１ 通信部
２２ 記憶部
２２１ 経路情報データベース
２２２ イベント情報データベース
２２３１ 経路ネットワーク情報データベース
２２３２ 地図情報データベース
２２３３ ＰＯＩ情報データベース
２２４ ユーザ情報データベース
２２５ 復路情報データベース
２３，２３ａ，２３ｂ 制御部
２３１ 探索要求取得部
２３２ 経路探索部
２３３ 往路判定部
２３４ 復路情報推定部
２３５ 分析対象設定部
２３６ 移動需要分析部
２３７ 復路判定部
２３８ 送信先決定部
２３９ 情報送信部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】