JP2020166608A - 情報処理装置および情報処理方法 - Google Patents

Abstract

【課題】ユーザの移動を精度よく追跡する。【解決手段】複数のセグメントからなる経路を、運行スケジュールが管理されている公共交通機関を少なくとも含む複数の交通手段を用いて移動するユーザの行動を推定する情報処理装置。前記公共交通機関の運行便に関するデータであって、セグメントごとの出発予定時刻と到着予定時刻を表す運行関連データを取得する第一取得手段と、前記ユーザが移動する経路に含まれる複数のセグメントの集合である移動予定経路を取得する第二取得手段と、前記ユーザが所持するユーザ端末から位置情報を周期的に取得し、当該位置情報を含む移動実績データを生成する生成手段と、前記移動実績データと、前記運行関連データと、に基づいて、前記移動予定経路に含まれる各セグメントについて、前記ユーザが利用した交通手段と、対応するセグメントの進入時刻および退出時刻を推定する推定手段と、を有する。【選択図】図１

Description

本発明は、人の移動に関するデータを収集するシステムに関する。

コンピュータやスマートフォンを用いて、各種交通機関を利用したルート検索を行うサービスが普及している。
一方で、提案された予定経路の通りにユーザが移動しているか否かを判定したいという要望がある。例えば、複数のユーザが、提案したルートの通りに交通機関を乗り継いで移動していないことが分かれば、提案したルートや乗り継ぎ等に問題があることが推定できる。また、旅行者がどのような乗り継ぎによって移動しているかは、旅行業者や交通事業者にとって貴重なデータとなりうる。

移動中のユーザを追跡する技術として、例えば、特許文献１には、ＩＣカード乗車券の利用情報に基づいて、利用者の行動を予測するシステムが開示されている。

国際公開第２０１４／０３０５２９号 特開２０１１−０６１６１５号公報 特開２０１１−１０７０９１号公報

特許文献１に記載の発明では、ＩＣカードを用いて改札機等を通過した際の情報を利用してユーザの行動を追跡しているため、ＩＣカードに対応していない交通機関や、公共交通機関以外を利用して移動した場合に、ユーザの追跡が行えない。また、ＩＣカードの利用に関する情報は個人情報であるため、交通事業者から提供を受けられない場合がある。

本発明は上記の課題を考慮してなされたものであり、ユーザの移動を精度よく追跡することを目的とする。

本発明に係る情報処理装置は、
複数のセグメントからなる経路を、運行スケジュールが管理されている公共交通機関を少なくとも含む複数の交通手段を用いて移動するユーザの行動を推定する情報処理装置であって、前記公共交通機関の運行便に関するデータであって、セグメントごとの出発予定時刻と到着予定時刻を表す運行関連データを取得する第一取得手段と、前記ユーザが移動する経路に含まれる複数のセグメントの集合である移動予定経路を取得する第二取得手段と、前記ユーザが所持するユーザ端末から位置情報を周期的に取得し、当該位置情報を含む移動実績データを生成する生成手段と、前記移動実績データと、前記運行関連データと、に基づいて、前記移動予定経路に含まれる各セグメントについて、前記ユーザが利用した交通手段と、対応するセグメントの進入時刻および退出時刻を推定する推定手段と、を有することを特徴とする。

また、本発明に係る方法は、
複数のセグメントからなる経路を、運行スケジュールが管理されている公共交通機関を少なくとも含む複数の交通手段を用いて移動するユーザの行動を推定する情報処理装置が
行う情報処理方法であって、前記公共交通機関の運行便に関するデータであって、セグメントごとの出発予定時刻と到着予定時刻を表す運行関連データを取得する第一取得ステップと、前記ユーザが移動する経路に含まれる複数のセグメントの集合である移動予定経路を取得する第二取得ステップと、前記ユーザが所持するユーザ端末から位置情報を周期的に取得し、当該位置情報を含む移動実績データを生成する生成ステップと、前記移動実績データと、前記運行関連データと、に基づいて、前記移動予定経路に含まれる各セグメントについて、前記ユーザが利用した交通手段と、対応するセグメントの進入時刻および退出時刻を推定する推定ステップと、を含むことを特徴とする。

なお、本発明は、上記手段の少なくとも一部を含む情報処理装置として特定することができる。また、前記情報処理装置が行う方法として特定することもできる。上記処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

本発明によれば、ユーザの移動を精度よく追跡することができる。

ユーザが移動する経路を説明する図。 ユーザが行う乗り継ぎおよび移動スケジュールを説明する図。 第一の実施形態に係るナビゲーションシステムの構成概要図。 第一の実施形態における移動実績データの例。 第一の実施形態における運行関連データの例。 ユーザ行動を推定する処理の概要を説明する図。 位置情報が欠落した場合における処理の概要を説明する図。 システムの構成要素間におけるデータフローを示した図。 サーバ装置が行う行動推定処理のフローチャート図。 位置情報が欠落したセグメントについての行動推定を説明する図。

所定の経路に沿って移動するユーザを追跡するシステムが考えられる。例えば、図１のような交通網によってユーザが出発地から目的地まで移動する場合を考える。
この場合、ルート検索サービスによって、例えば、図２に示したような経路および移動スケジュールが生成される。
一方、提案した経路の通りにユーザが移動しているかを知りたいという要望がある。特に、ルート検索において用いた乗り換え所要時間や、ユーザの歩行速度、経由地の特性等によっては、予定通りの移動が行えない場合がある。しかし、従来の技術では、ユーザからのフィードバックが無い限り、提案した移動予定と実際の移動がどの程度一致しているかを知ることは困難であった。

当該課題を解決するための、本発明に係る情報処理装置は、複数のセグメントからなる経路を、運行スケジュールが管理されている公共交通機関を少なくとも含む複数の交通手段を用いて移動するユーザの行動を推定する装置である。
具体的には、前記公共交通機関の運行便に関するデータであって、セグメントごとの出発予定時刻と到着予定時刻を表す運行関連データを取得する第一取得手段と、前記ユーザが移動する経路に含まれる複数のセグメントの集合である移動予定経路を取得する第二取得手段と、前記ユーザが所持するユーザ端末から位置情報を周期的に取得し、当該位置情報を含む移動実績データを生成する生成手段と、前記移動実績データと、前記運行関連データと、に基づいて、前記移動予定経路に含まれる各セグメントについて、前記ユーザが利用した交通手段と、対応するセグメントの進入時刻および退出時刻を推定する推定手段
と、を有する。

運行スケジュールが管理されている公共交通機関とは、予め運行ダイヤが定められている、鉄道やバス等の交通機関である。本発明が対象とする交通網は、公共交通機関と、その他の手段（徒歩、自転車、オートバイ、自家用車等）を含む交通手段によって移動可能な交通網である。

セグメントとは、経路を構成する単位区間である。一セグメントは、任意の二つの駅を結ぶ区間であってもよいし、任意の二つのバス停を結ぶ区間であってもよい。また、移動が公共交通機関以外によって行われる場合、任意の二つの地点を結ぶ区間であってもよい。
移動予定経路は、ユーザが移動する予定のセグメントの集合である。
運行関連データは、セグメントごとの出発予定時刻と到着予定時刻を含むデータである。運行関連データは、予め定められた時刻表データであってもよいし、当該時刻表データに実際の運行状況（遅延時分等）を加味したものであってもよい。
生成手段は、ユーザ端末から位置情報を周期的に取得し、移動実績データを生成する。移動実績データは、どの時刻にユーザ端末がどの地点にあったかを示すデータである。
推定手段は、移動実績データと運行関連データとを突き合わせることで、各セグメントにユーザが進入および退出した時刻と、当該セグメントの移動に利用した交通手段を推定する。ここで言う交通手段とは、鉄道／バス／徒歩といった括りであってもよいし、乗車した便を特定するものであってもよい。
かかる構成によると、経路を構成するセグメントごとに、入出時刻と交通手段を推定することができるため、ユーザの行動が当初の予定通りに行われたかを追跡することができる。

また、前記ユーザ端末は、前記ユーザの移動中において、位置情報を取得可能な第一の状態と、位置情報を取得不可能な第二の状態と、のいずれかにあり、前記生成手段は、前記ユーザ端末が前記第一の状態にある場合に取得した位置情報のみを用いて前記移動実績データを生成することを特徴としてもよい。
ユーザ端末は、常に位置情報を取得できるとは限らない。例えば、地下ではＧＰＳ情報を取得することは困難である。また、地上にいる場合であっても、端末がスリープ状態にある場合や、アプリケーションがバックグラウンドで動作している場合など、位置情報の取得が行えない場合がある。かかる場合、取得ができた位置情報のみを用いて移動実績データを生成するようにしてもよい。

また、前記移動実績データは、前記位置情報と、前記位置情報を取得した時刻と、を前記セグメントに関連付けたデータであることを特徴としてもよい。これにより、例えば、セグメントが駅やバス停によって定義されている場合、ユーザが乗車した列車やバスの便が推定可能になる。

また、前記推定手段は、前記移動実績データと前記運行関連データとを突合し、前記ユーザが乗車したと推定される前記公共交通機関の便を前記セグメントごとに決定することを特徴としてもよい。便の推定は、移動実績データと運行関連データとを突き合わせ、乗り継ぎが可能な便を絞り込むことで行うことができる。

また、前記ユーザが前記公共交通機関に乗車する際に利用したＩＣカードの通過情報を取得する手段をさらに有し、前記推定手段は、前記運行関連データと、前記通過情報と前記移動実績データの少なくとも片方と、を突合することで、前記ユーザが乗車したと推定される前記公共交通機関の便を前記セグメントごとに決定することを特徴としてもよい。
通過情報は、例えば、改札を通過した旨の情報や、乗降が発生した旨の情報である。通
過情報によって、位置情報を補完することができる。

また、前記経路の一部において前記位置情報の取得が途絶した場合に、前記推定手段は、最後に前記位置情報を取得したセグメントにおける第一の移動実績データと、前記位置情報の取得が再開されたセグメントにおける第二の移動実績データと、前記運行関連データと、に基づいて、前記位置情報の取得が行えなかった中間のセグメントにおいて前記ユーザが乗車したと推定される前記公共交通機関の便を決定することを特徴としてもよい。
例えば、経路の中間において位置情報が欠落した場合、その前後の移動実績データと時刻が整合するように（合理的な時間で乗り継ぎが行えるように）、中間のセグメントにおける乗車便を決定することができる。

また、前記ユーザの移動が、前記ユーザの生活圏で行われたか、非生活圏で行われたかを判定する手段をさらに有し、前記ユーザの移動が生活圏で行われた場合と比較して、非生活圏で行われた場合に、前記ユーザの徒歩速度をより遅く設定することを特徴としてもよい。かかる構成によると、より精度よく乗り継ぎを推定することができる。

（第一の実施形態）
第一の実施形態に係るナビゲーションシステムの概要について、図３を参照しながら説明する。本実施形態に係るナビゲーションシステムは、ユーザが所持する端末（ユーザ端末１００）と、ユーザ端末１００に対してナビゲーションサービスを提供するサーバ装置２００と、公共交通機関の運行を管理する交通機関サーバ３００と、を含んで構成される。なお、対象のユーザが複数である場合、ユーザ端末１００は複数あってもよい。また、交通機関サーバ３００も、交通機関ごと（あるいは運行主体ごと）に設置されていてもよい。

ユーザ端末１００は、例えばスマートフォン、携帯電話、タブレットコンピュータ、個人情報端末、ノートブックコンピュータ、ウェアラブルコンピュータ（スマートウォッチ等）といった小型のコンピュータである。ユーザ端末１００は、通信部１０１、制御部１０２、記憶部１０３、位置情報取得部１０４、入出力部１０５を有して構成される。

通信部１０１は、ネットワーク経由でサーバ装置２００と通信を行うための通信インタフェースである。

制御部１０２は、ユーザ端末１００の制御を司る手段である。制御部１０２は、例えば、ＣＰＵ（Central Processing Unit）によって構成される。
制御部１０２は、機能モジュールとして経路検索部１０２１、位置情報送信部１０２２を有している。各機能モジュールは、ＲＯＭ（Read Only Memory）等の記憶手段に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

経路検索部１０２１は、サーバ装置２００に対して経路を検索する要求（以下、経路検索要求）を送信し、得られた応答に基づいて、ユーザに対して経路案内を提供する。具体的には、出発地および目的地をユーザから取得し、当該出発地と目的地を結ぶ経路を検索するリクエストをサーバ装置２００に送信する。また、サーバ装置２００から受信した経路を、後述する入出力部１０５を介してユーザに提供する。このような機能は、オペレーティングシステム上で動作するアプリケーションプログラムによって実現してもよい。

位置情報送信部１０２２は、経路検索部１０２１によるナビゲーション中において、後述する位置情報取得部１０４によって取得された端末の位置情報をサーバ装置２００に送信する。

記憶部１０３は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。

位置情報取得部１０４は、ユーザ端末１００の現在位置を取得する手段であり、典型的にはＧＰＳ受信器などを含んで構成される。位置情報取得部１０４が取得した情報は、制御部１０２に送信される。
入出力部１０５は、ユーザに対して情報を提示し、当該ユーザから情報の入力を受けるためのインタフェースである。入出力部１０５は、例えば、ディスプレイ装置やタッチパネルを有して構成される。

次に、サーバ装置２００の構成について説明する。
サーバ装置２００は、複数のユーザ端末１００から受信した経路検索要求に基づいて、指定された出発地と目的地を結ぶ経路、および、当該経路を移動するための公共交通機関の乗り継ぎに関する情報を生成する装置である。以降、経路と乗り継ぎに関する情報を、ナビゲーション情報と称する。
また、サーバ装置２００は、ナビゲーション情報を送信したユーザ端末１００の位置情報を周期的に取得し、当該ユーザ端末１００を所持しているユーザの行動を推定する機能を有する。これにより、ユーザが取っている行動がナビゲーション情報と一致しているか否かを判定することが可能になる。

サーバ装置２００は、通信部２０１、制御部２０２、記憶部２０３を有して構成される。
通信部２０１は、通信部１０１と同様の、ネットワーク経由でユーザ端末１００および交通機関サーバ３００と通信を行うための通信インタフェースである。

制御部２０２は、サーバ装置２００の制御を司る手段である。制御部２０２は、例えば、ＣＰＵによって構成される。
制御部２０２は、機能モジュールとして経路生成部２０２１、移動実績データ取得部２０２２、運行関連データ取得部２０２３、行動推定部２０２４を有している。各機能モジュールは、ＲＯＭ等の記憶手段に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

経路生成部２０２１は、ユーザ端末１００から取得した経路検索要求に応じて、指定された出発地と目的地を結ぶ経路を検索ないし生成する。経路の生成は、例えば、後述する記憶部２０３に記憶された地図データを参照し、公知の手法によって行うことができる。また、経路の生成は、公共交通機関のダイヤ情報を参照して行ってもよい。公共交通機関のダイヤ情報は、記憶部２０３に記憶されていてもよいし、交通機関サーバ３００から取得してもよい。また、経路生成部２０２１は、必要に応じて、交通機関サーバ３００に対して座席の予約リクエスト等を送信する。

移動実績データ取得部２０２２は、ナビゲーション情報を送信したユーザ端末１００から位置情報を周期的に取得し、ナビゲーションを受けている当該ユーザ端末１００がどのように移動しているかを表すデータ（以下、移動実績データ）を生成する。
本実施形態では、移動実績データは、図４に示したような、ユーザの識別子、位置情報（例えば緯度と経度）、日時情報、セグメント（どのセグメントを移動中であるか）を含むテーブルである。移動実績データ取得部２０２２は、ユーザ端末１００から位置情報を受信するごとに新しいレコードを生成し、記憶部２０３に記憶させる。

運行関連データ取得部２０２３は、公共交通機関の運行に関するデータ（以下、運行関連データ）を交通機関サーバ３００から取得する。本実施形態では、運行関連データとは
、列車またはバスの運行予定を表すデータ（時刻表データ）である。図５に示したように、運行関連データには、駅またはバス停といった運行拠点と、各拠点の出発、通過、到着時刻が運行便ごとに記録されている。

行動推定部２０２４は、移動実績データ取得部２０２２が取得した移動実績データと、運行関連データ取得部２０２３が取得した運行関連データに基づいて、ユーザが実際にとった行動をセグメントごとに推定する。詳細な処理については後述する。

記憶部２０３は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。

次に、交通機関サーバ３００の構成について説明する。
交通機関サーバ３００は、公共交通機関の運行を管理するサーバ装置である。具体的には、公共交通機関の運行関連データ（時刻表データ）を提供し、かつ、座席が指定された交通機関について予約を受け付ける装置である。交通機関サーバ３００は、交通機関ごとに存在してもよいし、交通事業者ごとに存在してもよい。例えば、同一の事業者が運行する複数路線の交通機関を管理するものであってもよい。

交通機関サーバ３００は、通信部３０１、制御部３０２、記憶部３０３を有して構成される。
通信部３０１は、通信部２０１と同様の、ネットワーク経由でサーバ装置２００と通信を行うための通信インタフェースである。

制御部３０２は、交通機関サーバ３００の制御を司る手段である。制御部３０２は、例えば、ＣＰＵによって構成される。
制御部３０２は、機能モジュールとして予約受付部３０２１、運行関連データ提供部３０２２を有している。各機能モジュールは、ＲＯＭ等の記憶手段に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

予約受付部３０２１は、サーバ装置２００からの要求に基づいて、対応する交通機関の座席ないし運行を予約する。予約対象は、例えば、優等列車の指定席、高速バスの指定席、船舶や航空便の指定席、タクシー（配車）などであってもよい。予約受付部３０２１は、予約の成立にともなって、代金の決済を行う機能を有していてもよい。なお、予約受付部３０２１は、指定席以外の有料座席に対する決済を行ってもよい。

運行関連データ提供部３０２２は、対応する交通機関の運行関連データをサーバ装置２００に提供する。運行関連データは、図５に示したように、駅またはバス停と、各拠点の出発、通過、到着時刻が運行便ごとに記録されたデータである。なお、運行関連データは、運行予定時刻を表したものであってもよいし、現在の運行状況（遅延等）を反映したものであってもよい。図５における括弧は、運行遅延を反映させた時刻（実際の到着予定時刻）を表したものである。図５（Ｂ）に図示した例では、００２便の、バス停６における本来の通過予定が１０時５３分であって、実際は１０時５５分に通過が見込まれる旨を示している。このように、運行関連データは、状況に応じて随時更新されてもよい。
本実施形態では、交通機関サーバ３００は、全時間帯における運行関連データを記憶しており、サーバ装置２００の求めに応じて、そのうちの一部（指定された時間帯に対応するデータ）を提供する。

次に、サーバ装置２００が、ユーザ端末１００から周期的に取得した位置情報を用いて移動実績データを生成し、セグメントごとのユーザ行動を推定する処理の概要について説明する。

ここでは、サーバ装置２００（移動実績データ取得部２０２２）が、図１に示した交通網を、図２に示した予定で移動するユーザが所持するユーザ端末１００から、図６の符号６０１で示したタイミングで位置情報を取得したものとする。

図６の例では、１０時０分から１０時２０分までの間に受信した４つの位置情報が、セグメントＡに対応するものであることが判定できる。また、１０時２０分から１０時５０分までの間に受信した２つの位置情報が、セグメントＢに対応するものであることが判定できる。同様に、１０時５０分から１０時５５分までの間に受信した３つの位置情報が、セグメントＣに、１０時５５分から１１時１５分までの間に受信した２つの位置情報が、セグメントＤに、１１時１５分から１１時２２分までの間に受信した３つの位置情報が、セグメントＥにそれぞれ対応するものであることが判定できる。
これらの位置情報をセグメントにマッピングすると、図４（Ａ）に示したような移動実績データが得られる。

次に、サーバ装置２００（行動推定部２０２４）が、このようにして得られた移動実績データと、公共交通機関の運行関連データを突き合わせ、各セグメントにおいてユーザがどの手段を用いて移動したかを判定する。
例えば、出発地と駅Ａを結ぶ公共交通機関は存在しないため、行動推定部２０２４は、ユーザが公共交通機関以外によってセグメントＡを移動したと判定する。セグメントＡにおける移動開始時刻（セグメントＡに進入した時刻）は１０時０分となり、移動終了時刻（セグメントＡを退出した時刻）は１０時２０分となる。

駅Ａと駅Ｄを結ぶ公共交通機関には鉄道があるため、行動推定部２０２４は、交通機関サーバ３００（運行関連データ提供部３０２２）から、鉄道についての運行関連データを取得し、突き合わせを行う。図５（Ａ）の例からは、１０時２０分にセグメントＢに進入し、１０時５０分にセグメントＢから退出できる列車の候補には、１００２列車と１００３列車があることがわかるが、乗り換え時間を考慮して、１００３列車が候補として抽出される。すなわち、ユーザは、１００３列車によってセグメントＢを移動したと判定される。なお、乗り換え時間は、ユーザの徒歩速度を加味して算出してもよい。ユーザの徒歩速度は、例えば、年齢や性別に応じた所定の値とすることができる。

駅Ｄとバス停６を結ぶ公共交通機関は存在しないため、行動推定部２０２４は、ユーザが公共交通機関以外によってセグメントＣを移動したと判定する。セグメントＣにおける移動開始時刻は１０時５０分となり、移動終了時刻は１０時５５分となる。

バス停６とバス停１１を結ぶ公共交通機関にはバスがあるため、行動推定部２０２４は、交通機関サーバ３００（運行関連データ提供部３０２２）から、バスについての運行関連データを取得し、突き合わせを行う。図５（Ｂ）の例からは、１０時５５分にセグメントＤに進入し、１１時１５分にセグメントＤから退出できるバスの候補として、００２便が抽出される（本来の発車予定は１０時５３分であるが、遅延によって発車時刻が１０時５５分に変更されているため）。

バス停１１と目的地を結ぶ公共交通機関は存在しないため、行動推定部２０２４は、ユーザが公共交通機関以外によってセグメントＥを移動したと判定する。セグメントＥにおける移動開始時刻は１１時１５分となり、移動終了時刻は１１時２２分となる。

このように、サーバ装置２００は、ユーザ端末１００から周期的に取得した位置情報をセグメントにマッピングし、運行関連データを参照することで、ユーザが各セグメントを移動した際の交通手段、および、各セグメントの入退出時刻を決定する。

ところで、図６に示したように、全てのセグメントにおいて十分な数の位置情報がユーザ端末１００から取得できるとは限らない。例えば、鉄道が地下を走行していた場合や、バスがトンネルを通過した場合、位置情報が取得できないタイミングが発生しうる。このようなケースは、ユーザ端末１００上でナビゲーションアプリケーションが動作していない場合（例えば、スリープ状態にある場合）にも発生する。

本実施形態では、かかるケースに対応するため、受信できた位置情報のみを用いて、セグメントごとの行動推定を行う。
図７は、移動途中において位置情報が欠落、すなわち、位置情報の送信が一時的に滞ったケースを説明する図である。本例では、鉄道とバスによる移動中に、周期的な位置情報の送信が中断したものとする。

図７の例では、１０時０分から１０時１９分までの間に受信した３つの位置情報が、セグメントＡに対応するものであることが判定できる。また、１１時１９分から１１時２４分までの間に受信した３つの位置情報が、セグメントＥに対応するものであることが判定できる。これらの位置情報をセグメントにマッピングすると、図４（Ｂ）に示したような移動実績データが得られる。

本例では、セグメントＢ，Ｃ，Ｄについては情報が存在しない。そこで、行動推定部２０２４は、前後のセグメントにおける移動実績データに基づいて、中間のセグメントにおけるユーザの行動を推定する。

例えば、セグメントＢについては、セグメントＡの退出時刻に基づいて、列車に乗車した時刻を推定することができる。本例の場合、駅Ａに到着した時刻に乗り換え所要時間を加算した結果、１００３列車に乗車した可能性が最も高いと判定することができる。すなわち、セグメントＢの推定進入時刻は１０時２５分となり、推定退出時刻は１０時４８分となる。

また、セグメントＤについては、セグメントＥの進入時刻に基づいて、バスから降車した時刻を推定することができる。本例の場合、バス停１１に到着した時刻から、００２便に乗車した可能性が最も高いと判定することができる。すなわち、セグメントＤの推定進入時刻は１０時５５分となり、推定退出時刻は１１時１５分となる。

セグメントＣについては、セグメントＢおよびＤにおける推定結果と整合するように、交通手段および入退出時刻を推定する。例えば、徒歩によって移動を行い、セグメントＣに１０時４８分に進入し、１０時５５分に退出したと推定する。

このように、サーバ装置２００は、ユーザ端末１００から位置情報が取得できない期間が発生した場合に、前後のセグメントにおける移動実績データと、運行関連データとを突き合わせ、中間のセグメントにおけるユーザの行動を推定する。

次に、前述した機能を実現するための、具体的な処理方法について説明する。
図８は、本実施形態に係るナビゲーションシステムを構成する各要素が行う処理と、要素間におけるデータのフローを示した図である。
まず、ステップＳ１１で、ユーザが、ユーザ端末１００（経路検索部１０２１／例えば、ナビゲーションアプリケーション）を介して経路探索要求を発行する。経路探索要求には、出発地と目的地を指定する情報が含まれる。当該経路探索要求は、サーバ装置２００に送信される。

経路探索要求を受信したサーバ装置２００（経路生成部２０２１）は、出発地と目的地を結ぶ経路（移動予定経路）を生成する（ステップＳ１２）。なお、必要に応じて、交通機関サーバ３００に対して予約リクエストを送信してもよい。この場合、交通機関サーバ３００（予約受付部３０２１）は、予約リクエストに応じて座席等の確保を行い、結果を返すようにしてもよい（ステップＳ１３）。
なお、移動予定経路には、各セグメントの移動開始予定時刻および移動終了予定時刻が含まれていてもよい。

経路生成部２０２１が生成した移動予定経路は、ユーザ端末１００（経路検索部１０２１）へ送信され（ステップＳ１４）、経路案内が開始される。
ユーザが移動を開始すると、移動を開始した旨の情報（開始トリガ）がサーバ装置２００へ送信される（ステップＳ１５）。
ユーザが移動を開始したことは、ナビゲーションアプリケーションに対してユーザが行った操作に基づいて判定してもよいし、ユーザ端末１００によって自動的に検知してもよい。

ステップＳ１６では、サーバ装置２００（行動推定部２０２４）が、ユーザの行動推定を開始する。この間、位置情報が周期的にユーザ端末１００からサーバ装置２００へ送信される（ステップＳ１７）。
ユーザが移動を終了すると、移動を終了した旨の情報（終了トリガ）がサーバ装置２００へ送信される（ステップＳ１８）。
ユーザが移動を終了したことは、ナビゲーションアプリケーションに対してユーザが行った操作に基づいて判定してもよいし、ユーザ端末１００によって自動的に検知してもよい。これにより、サーバ装置２００による行動推定が終了する（ステップＳ１９）。

図９は、サーバ装置２００が行う行動推定処理のフローチャートである。図示したフローチャートは、ステップＳ１６〜Ｓ１９の期間において繰り返し実行される。

まず、ステップＳ２１で、移動実績データ取得部２０２２が、ユーザ端末１００に対して位置情報の送信を要求する。ユーザ端末１００（位置情報送信部１０２２）は、当該要求に応答して、位置情報取得部１０４を介して位置情報を取得し、サーバ装置２００に送信する。取得された位置情報は、サーバ装置２００において一時的に記憶される。なお、本例ではサーバ装置２００が位置情報の送信を要求したが、ユーザ端末１００が能動的に位置情報を送信してもよい。なお、位置情報の取得に失敗した場合（ユーザ端末１００からの応答が無い場合や、ユーザ端末１００から規定の周期で位置情報が送信されてこない場合を含む）であっても、処理は継続する。

次に、ステップＳ２２で、移動実績データ取得部２０２２が、位置情報の取得が一定時間以上途絶したか否かを判定する。一定時間は、例えば、予め定められた時間（３分，５分，１０分など）とすることができるが、この限りではない。
ここで否定判定であった場合、ステップＳ２３で、移動実績データ取得部２０２２が、受信した位置情報に基づいて、移動実績データを生成または更新する。具体的には、図４に示したように、ユーザＩＤと、位置情報と、日時と、セグメントを対応付けて記憶する。位置情報とセグメントとの対応付けは、ステップＳ１２で生成した移動予定経路を参照することで行うことができる。

次に、ステップＳ２４で、行動推定部２０２４が、対応するセグメントにおけるユーザの行動を推定する。本ステップでは、まず、運行関連データ取得部２０２３が、対象セグメントおよび対象時間帯において利用可能な公共交通機関の運行関連データを取得する。そして、対象の移動実績データと、取得した運行関連データを突き合わせ、ユーザが乗車
可能な便があるか否かを判定する。本ステップでは、セグメントごとに、交通手段（公共交通機関を利用したか否か、公共交通機関を利用した場合は便名）と、当該セグメントの入退出時刻を推定する。
なお、交通手段が一意に特定できない場合、複数の候補を保持してもよい。また、複数の候補に尤度を付してもよいし、当該尤度に応じて複数の候補をランク付けしてもよい。

次に、ステップＳ２５で、行動推定部２０２４が、ユーザが目的地に到着したか否かを判定する。ここで否定判定であった場合、ステップＳ２１へ戻り、処理を継続する。

次に、ステップＳ２２で肯定判定であった場合を説明する。
位置情報の取得が途絶し、所定の時間が経過した場合、処理はステップＳ２７へ遷移する。ステップＳ２７では、位置情報の取得が再開されるまで待機する。位置情報の取得が再開された場合、処理はステップＳ２８へ進む。

ステップＳ２８〜Ｓ２９では、位置情報が取得できなかったセグメントのそれぞれについて、ステップＳ２４とは異なる方法でユーザの行動推定を行う。ここでは、図１０の例によって説明を行う。本例では、セグメントＢ，Ｃ，Ｄについて、位置情報の取得が行えなかったものとする。

まず、ステップＳ２８で、行動が推定できていないセグメント（未推定セグメント）が残っているかを判定する。未推定セグメントがあった場合、ステップＳ２９で、運行関連データ取得部２０２３が取得した運行関連データと、移動実績データ取得部２０２２が取得した移動実績データを用いて、当該未推定セグメントにおけるユーザの行動を推定する。
具体的には、行動推定が完了しているセグメント（推定済セグメント）と未推定セグメントとの境界（例えば、セグメントＡとセグメントＢの境界）を特定し、乗り継ぎが合理的な時間で行える公共交通機関の便を抽出する。もし、利用可能な公共交通機関が無い場合、公共交通機関以外によって移動した旨を決定する。これにより、未推定セグメントにおいてユーザが利用した交通手段（例えば、乗車した公共交通機関の便）と、当該セグメントへの入退出時刻が推定できる。

ある未推定セグメントについて、行動推定が完了したら、当該セグメントを推定済セグメントとし、未推定セグメントが無くなるまで前述した処理を反復する。
なお、行動推定処理は、時刻順に行ってもよいが、最後に位置情報が取得できたセグメントと、位置情報の取得が再開されたセグメントの双方から行うようにしてもよい。すなわち、時間軸方向に対して順方向と逆方向で並行して行うようにしてもよい。

例えば、（１）セグメントＡに対応する移動実績データに基づいてセグメントＢの推定を行い、（２）セグメントＥに対応する移動実績データに基づいてセグメントＤの推定を行い、（３）セグメントＢおよびＤの推定結果に基づいてセグメントＣの推定を行うといった手順で、中間セグメントの行動推定を行うようにしてもよい。
この場合、順方向に推定を行った結果と、逆方向に行った推定の結果が時刻的に整合しない場合（例えば、中間のセグメントにおいて乗り継ぎが不可能になった場合）、矛盾を解消する方向にいずれかの乗車便をずらし、再試行するようにしてもよい。
未推定セグメントが無くなったら、処理はステップＳ２５へ遷移する。

ステップＳ２５では、ユーザが目的地に到着したか否かを判定する。ユーザが目的地に到着していない場合、処理はステップＳ２１へ戻る。ユーザが目的地に到着した場合、処理は終了する。処理の結果得られた情報（ユーザの行動に関する情報）は、記憶部２０３に記憶され、または、外部の装置へ提供される。

以上に説明したように、第一の実施形態に係るナビゲーションシステムでは、複数のセグメントを経由して移動したユーザの行動を追跡することができる。特に、中間のセグメントにおいて位置情報の送信が一時的に中断した場合であっても、前後において取得した位置情報と、公共交通機関の運行関連データを突き合わせることで、当該セグメントにおけるユーザの行動を推定することができる。

（第一の実施形態の変形例）
第一の実施形態では、公共交通機関を利用しない場合のユーザの移動速度を所定値に設定した。しかし実際は、人の移動速度（例えば、徒歩速度や乗り換えに要する時間等）は環境によって変わりうる。そこで、対象ユーザの移動が生活圏で行われたか、非生活圏で行われたかを判定し、判定結果に基づいて当該ユーザの徒歩速度を補正してもよい。

生活圏の判定は、例えば、記憶部２０３に蓄積された過去の移動実績データの多さに基づいて行うことができる。例えば、過去の所定期間における移動回数が多いセグメントは、通い慣れた道であると推定される。よって、過去の所定期間における移動回数が少ないセグメントと比べて、歩行速度を速く設定し、または、乗り換え時に必要な時間を短く設定することができる。このような判定は、経路単位で行ってもよいし、セグメント単位で行ってもよい。

また、第一の実施形態では、交通機関サーバ３００が全時間帯の運行関連データを提供可能であるものとしたが、事業者によっては、過去の時刻における運行関連データを提供していない場合がある。かかる場合、過去におけるユーザの行動を推定しようとした際に、運行関連データが入手できないといった不都合が発生しうる。
これに対応するため、運行関連データ取得部２０２３は、行動推定処理を開始する際に、ユーザが利用しうる交通機関についての運行関連データを予め取得するようにしてもよい。例えば、当初の行動予定が乱れることを想定し、利用可能である全ての公共交通機関について、所定の期間における運行関連データを取得し、キャッシュするようにしてもよい。また、運行関連データのキャッシュは、位置情報の取得が途絶したタイミングで行うようにしてもよい。

また、第一の実施形態では、ユーザの移動中において、サーバ装置２００がリアルタイムで行動推定を行ったが、ユーザが移動を終了した後で、蓄積された移動実績データに基づいて事後的に行動推定を行うようにしてもよい。

また、第一の実施形態では、全てのセグメントに対して行動推定を行ったが、行動が絞り込めないセグメントが存在する場合、当該セグメントを除外して処理を行うようにしてもよい。

また、第一の実施形態では、移動予定経路が事前に決まっている例を挙げたが、ユーザの移動経路は必ずしも事前に定まっている必要は無い。すなわち、移動予定経路が存在しない状態で、図９に示した行動推定処理を開始し、ユーザが移動したセグメントを事後的に推定するようにしてもよい。

（第二の実施形態）
第二の実施形態は、ユーザが公共交通機関に乗車する際に利用したＩＣカードの通過情報を併用して、当該ユーザの行動推定を行う実施形態である。
第二の実施形態では、交通機関サーバ３００が、ＩＣカードの通過情報をサーバ装置２００に提供し、サーバ装置２００が、当該通過情報を加味してユーザの行動推定を行うという点において第一の実施形態と相違する。

具体的には、制御部２０２が、特定のユーザの通過情報の提供を交通機関サーバ３００に要求し、制御部３０２が、これに応答して、所定の期間における当該ユーザの通過情報をサーバ装置２００に送信する。また、行動推定部２０２４は、受信した通過情報をさらに用いて、ユーザの行動推定を行う。

ＩＣカードの通過情報は、ユーザ端末１００の位置情報と比較して正確なものである。従って、第二の実施形態では、セグメントの入退出に対応する通過情報が得られた場合に、当該通過情報によって、セグメントの進入時刻または退出時刻を確定させる。対象ユーザの通過情報を取得する処理は、図９の処理とは独立して実行され、ステップＳ２４ないしＳ２９で行われた推定結果を、必要に応じて上書きする。
かかる構成によると、ユーザの行動推定精度をより向上させることが可能になる。

なお、第二の実施形態では、ＩＣカードによって乗車可能な公共交通機関を例示したが、公共交通機関以外から通過情報を取得してもよい。例えば、カーシェアリングや自転車シェアリングにおいて発生した貸出情報や返却情報を、通過情報として扱ってもよい。この場合、サーバ装置２００が、シェアリング事業者が管理する装置と通信を行って、位置情報と関連付いた貸出情報や返却情報を取得するようにしてもよい。

（変形例）
上記の実施形態はあくまでも一例であって、本発明はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本発明は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤディスク・ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１００・・・ユーザ端末
１０１，２０１，３０１・・・通信部
１０２，２０２，３０２・・・制御部
１０３，２０３，３０３・・・記憶部
１０４・・・位置情報取得部
１０５・・・入出力部
２００・・・サーバ装置
３００・・・交通機関サーバ

Claims (8)

1. 複数のセグメントからなる経路を、運行スケジュールが管理されている公共交通機関を少なくとも含む複数の交通手段を用いて移動するユーザの行動を推定する情報処理装置であって、
   前記公共交通機関の運行便に関するデータであって、セグメントごとの出発予定時刻と到着予定時刻を表す運行関連データを取得する第一取得手段と、
   前記ユーザが移動する経路に含まれる複数のセグメントの集合である移動予定経路を取得する第二取得手段と、
   前記ユーザが所持するユーザ端末から位置情報を周期的に取得し、当該位置情報を含む移動実績データを生成する生成手段と、
   前記移動実績データと、前記運行関連データと、に基づいて、前記移動予定経路に含まれる各セグメントについて、前記ユーザが利用した交通手段と、対応するセグメントの進入時刻および退出時刻を推定する推定手段と、を有する、
   情報処理装置。
2. 前記ユーザ端末は、前記ユーザの移動中において、位置情報を取得可能な第一の状態と、位置情報を取得不可能な第二の状態と、のいずれかにあり、
   前記生成手段は、前記ユーザ端末が前記第一の状態にある場合に取得した位置情報のみを用いて前記移動実績データを生成する、
   請求項１に記載の情報処理装置。
3. 前記移動実績データは、前記位置情報と、前記位置情報を取得した時刻と、を前記セグメントに関連付けたデータである、
   請求項１または２に記載の情報処理装置。
4. 前記推定手段は、前記移動実績データと前記運行関連データとを突合し、前記ユーザが乗車したと推定される前記公共交通機関の便を前記セグメントごとに決定する、
   請求項３に記載の情報処理装置。
5. 前記ユーザが前記公共交通機関に乗車する際に利用したＩＣカードの通過情報を取得する手段をさらに有し、
   前記推定手段は、前記運行関連データと、前記通過情報と前記移動実績データの少なくとも片方と、を突合することで、前記ユーザが乗車したと推定される前記公共交通機関の便を前記セグメントごとに決定する、
   請求項３または４に記載の情報処理装置。
6. 前記経路の一部において前記位置情報の取得が途絶した場合に、
   前記推定手段は、最後に前記位置情報を取得したセグメントにおける第一の移動実績データと、前記位置情報の取得が再開されたセグメントにおける第二の移動実績データと、前記運行関連データと、に基づいて、前記位置情報の取得が行えなかった中間のセグメントにおいて前記ユーザが乗車したと推定される前記公共交通機関の便を決定する、
   請求項３から５のいずれかに記載の情報処理装置。
7. 前記ユーザの移動が、前記ユーザの生活圏で行われたか、非生活圏で行われたかを判定する手段をさらに有し、
   前記ユーザの移動が生活圏で行われた場合と比較して、非生活圏で行われた場合に、前記ユーザの徒歩速度をより遅く設定する、
   請求項１から６のいずれかに記載の情報処理装置。
8. 複数のセグメントからなる経路を、運行スケジュールが管理されている公共交通機関を少なくとも含む複数の交通手段を用いて移動するユーザの行動を推定する情報処理装置が行う情報処理方法であって、
   前記公共交通機関の運行便に関するデータであって、セグメントごとの出発予定時刻と到着予定時刻を表す運行関連データを取得する第一取得ステップと、
   前記ユーザが移動する経路に含まれる複数のセグメントの集合である移動予定経路を取得する第二取得ステップと、
   前記ユーザが所持するユーザ端末から位置情報を周期的に取得し、当該位置情報を含む移動実績データを生成する生成ステップと、
   前記移動実績データと、前記運行関連データと、に基づいて、前記移動予定経路に含まれる各セグメントについて、前記ユーザが利用した交通手段と、対応するセグメントの進入時刻および退出時刻を推定する推定ステップと、を含む、
   情報処理方法。

Images