JP2020057114A - 情報処理装置、情報処理方法およびコンピュータプログラム - Google Patents

Abstract

【課題】ユーザが行った行動を推定する。【解決手段】本発明の実施形態に係る情報処理装置は、ユーザの位置情報と時刻情報とを含む移動履歴データに基づき、前記ユーザが生活圏外に位置している期間の少なくとも一部に含まれる前記位置情報と前記時刻情報とを旅程データとして特定する旅程判別部と、前記旅程データに基づき、前記ユーザが前記生活圏外で宿泊したか否かを判定する宿泊判定部と、を備える。【選択図】図２

Description

本開示は、情報処理装置、情報処理方法およびコンピュータプログラムに関する。

下記特許文献１には、ユーザの位置情報を用いて、ユーザが日帰りするか否かを判定する判定システムが開示されている。

特開２０１７−０９１０４５号公報

特許文献１に開示された判定システムは、ユーザが日帰りするかを予測するものであり、実際にユーザが日帰りしたかを判定するものではない。すなわち、当該判定システムは、日帰りというユーザの行動について、ユーザが当該行動を行うか否かを予測するものである。これに対して、ユーザの位置情報を用いて、ユーザが実際に行った行動を推定するニーズがある。

本開示は、ユーザが行った行動を推定可能な情報処理装置、情報処理方法およびコンピュータプログラムを提供する。

本発明の実施形態に係る情報処理装置は、ユーザの位置情報と時刻情報とを含む移動履歴データに基づき、前記ユーザが生活圏外に位置している期間の少なくとも一部に含まれる前記位置情報と前記時刻情報とを旅程データとして特定する旅程判別部と、前記旅程データに基づき、前記ユーザが前記生活圏外で宿泊したか否かを判定する宿泊判定部と、を備える。

第１の実施形態に係る情報処理システムの全体構成を示す図。 第１の実施形態に係る情報処理装置の機能ブロック図。 ユーザ属性データの例を示す図。 地域を経緯度に基づきメッシュ化した例を示す図。 移動履歴データの例を示す図。 メッシュ属性データの一例を示す図。 メッシュと市区町村の関係を示す図。 移動履歴データにメッシュの属性情報を追加した例を示す図。 ユーザ属性データにメッシュの属性情報を追加した例を示す図。 旅程の概念図を示す図。 旅程判別部による旅程判別処理の一例のフローチャート。 図８の移動履歴データに対して生活圏フラグを設定した例を示す図。 宿泊判定部の処理のフローチャート。 ユーザが宿泊したか否かを判断する具体例を説明するための図。 早朝出発か否かを判断する具体例を説明するための図。 旅程初日の宿泊地がユーザ自宅の市区町村内の場合に行う処理の例の図。 ストリーム情報の一例を示す図。 サマリ情報の一例を示す図。 第１の実施形態に係る情報処理装置の動作のフローチャート。 変形例１の具体例を説明するための図。 ユーザ端末の電源が途中でＯＦＦになった移動履歴データの例を示す図。 変形例１に係るストリーム情報の例を示す図。 変形例１に係る出力情報生成部の処理の一例のフローチャート。 変形例２に係るストリーム情報の例を示す図。 変形例３を説明するための図。 第２の実施形態に係る情報処理装置のブロック図。 経路メッシュデータの一例を示す図。 経路推定部により行う経路推定処理の一例を示すフローチャート。 経路間距離を計算する例を示す図。 経路推定情報の一例を示す図。

以下、この技術的思想の実施の形態について図面を参照しながら詳細に説明する。本開示において示される１以上の実施形態において、各実施形態が含む要素を互いに組み合わせることができ、かつ、当該組み合わせられた結果物も本開示が示す実施形態の一部をなすものとする。

（第１の実施形態）
図１は、本実施形態に係る情報処理システムの全体構成を示す。情報処理システムは、情報処理装置１００とサーバ１２０とを備えており、これらがネットワーク１１０を介して接続されている。

情報処理装置１００は、コンピュータにより構成される。コンピュータは、ハードウェア構成として、プロセッサ１０２と、メモリ１０４と、入出力インタフェース１０６と、通信インタフェース１０８とをそれぞれ１つ又は複数、備える。これらの要素は、図示しないバスによって接続されている。

メモリ１０４には、オペレーティング・システムと、情報処理プログラムと、情報処理に使用される各種のデータとが格納されている。オペレーティング・システムは、情報処理装置１００の全体的な動作を制御するためのコンピュータプログラムである。情報処理プログラムは、情報処理装置１００が後述する情報処理の各機能を実現するためのコンピュータプログラムである。メモリ１０４は、情報処理装置１００の動作によって生成されるデータを一時的又は永続的に記憶することもできる。メモリ１０４の具体例は、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ハードディスク、フラッシュメモリ、光ディスク等である。

プロセッサ１０２は、メモリ１０４に格納されているコンピュータプログラムを読み出して、それに従った処理を実行するように構成される。プロセッサ１０２がメモリ１０４に格納された情報処理プログラムを実行することによって、後述する情報処理の各機能が実現される。プロセッサ１０２は、例えばＣＰＵ（Central Processing Unit）である。

入出力インタフェース１０６は、情報処理装置１００のオペレータから情報処理装置１００を操作するための入力を受ける。また、入出力インタフェース１０６は、オペレータに画像表示、メッセージ送信、または印刷等の出力を行う。入出力インタフェース１０６の具体例は、キーボード、タッチパッド、マウス、ディスプレイ、メーラ、プリンタ等である。

通信インタフェース１０８は、ネットワーク１１０を介してサーバ１２０と通信するためのネットワーク・インタフェースである。

ネットワーク１１０は、有線ネットワーク、無線ネットワーク、これらの混合ネットワーク等、どのようなネットワークでもかまわない。ここでは、ネットワーク１１０は例えばインターネットのようなワイドエリアネットワーク（Wide Area Network）であるとする。

サーバ１２０は、携帯電話会社等の通信会社、または当該通信会社と契約を結んだ会社（以下、通信会社等）が管理するサーバである。サーバ１２０は、複数人のユーザの属性データ（ユーザ属性データ）を管理する。ユーザは、例えば、通信会社等と回線の利用契約をしている者や、回線を利用する権利を有する者（回線の利用契約をしている者の家族など）である。サーバ１２０は、各ユーザの位置情報等の履歴を、各ユーザの移動体から取得される位置データに基づき管理する。移動体は、例えばユーザが携帯するスマートフォン等の移動端末、ユーザが身に付ける任意のデバイス（例えばウェアラブルデバイス）などがある。あるいは、移動体は、ユーザが乗車する車でもよい。以下の説明では、移動体としてユーザが携帯する移動端末を想定するが、これに限定されない。

ユーザ端末１４０は、ユーザが携帯する移動端末である。ユーザ端末１４０は、基地局１３０を介して、他のユーザ端末１４０と音声通信やデータ通信を行い、また、サーバ１２０とデータ通信を行うことができる。基地局１３０は、通信会社等により設置された中継装置であり、バックボーンネットワーク（図示せず）を介してサーバ１２０に接続されている。基地局１３０は、ユーザ端末１４０間の音声通信やデータ通信の中継を行い、またサーバ１２０およびユーザ端末１４０間のデータ通信の中継を行う。

サーバ１２０は、基地局１３０を介して、ユーザ端末１４０とデータ通信が可能である。また、サーバ１２０は、ネットワーク１１０に接続された無線ＬＡＮのアクセスポイント（ＡＰ）１６０を介して、ユーザ端末１４０とデータ通信可能である。なお、ユーザ端末１４０は、基地局１３０に接続するモードと、ＡＰ１４０に接続するモードとを切り換え可能でもよい。サーバ１２０は、予め同意を得たユーザを対象に、ユーザ端末１４０から定期的にユーザＩＤ、位置情報、時刻情報（タイムスタンプ）等を含む位置データを取得する。取得間隔は、例えば、１分、２分、５分、１０分、１５分、３０分、または１時間間隔など任意の時間間隔でよい。位置情報は、例えばユーザ端末１４０がＧＰＳ（Global Positioning System）を利用して取得した経度および緯度（経緯度）の情報もしくはこれに基づく情報である。時刻情報は、ユーザ端末１４０で管理している時刻の情報であり、ユーザ端末１４０で位置情報が取得されたときの時刻を表す。ユーザＩＤは、例えば、通信会社等がユーザに付与したＩＤである。

ユーザ端末１４０は、一定時間ごとに位置情報と時刻情報とを検出し、ユーザＩＤ、位置情報および時刻情報等を含む位置データを、サーバ１２０に送信する。位置データの送信は、一例として、ユーザ端末１４０に、通信会社等が提供するアプリケーションをインストールしておき、当該アプリケーションの機能により行う。サーバ１２０は、ユーザ端末１４０から取得した位置データを、内部のデータベースまたは外部のアクセス可能なデータベースに蓄積していく。またサーバ１２０は、各ユーザのユーザ属性データを取得する。ユーザ属性データの取得は、ユーザ端末１４０にアプリケーションをインストールするときに行ってもよいし、その後の任意のタイミングで行ってもよい。あるいは、契約時にユーザが通信会社等に提供した情報からユーザ属性データを作成し、サーバ１２０に格納してもよい。ユーザ属性データは、サーバ１２０の内部または外部のアクセス可能なデータベースに蓄積する。

サーバ１２０は、ユーザ毎の位置データを蓄積した移動履歴データ、およびユーザ毎のユーザ属性データを、ネットワーク１１０を介して、情報処理装置１００に提供可能に構成される。提供に際して、サーバ１２０は、移動履歴データおよびユーザ属性データにおける一部の項目を加工してもよい。

例えば、地図上の領域を経緯度に基づき複数のメッシュ（セル）に分割した場合のメッシュの識別子（以下、メッシュコード）を位置情報としてもよい。この場合、サーバ１２０は、情報処理装置１００に提供する移動履歴データに含める位置情報として、メッシュコードを用いる。メッシュコードを用いることで、移動履歴データのサイズを低減できる。また、ユーザ個人の詳細な位置を秘匿化できる。本実施形態では、情報処理装置１００に提供する移動履歴データに含める位置情報としてメッシュコードを用いるものとする。ただし、位置情報として、経緯度の情報を用いることも妨げない。なお、ユーザ端末１４０側で経緯度をメッシュコードに変換し、変換したメッシュコードを含む位置データをサーバ１２０に送信してもよい。この場合、サーバ１２０での変換作業は不要である。

また、情報処理装置１００に提供するユーザ属性データに含められるユーザＩＤは、ユーザ個人が特定されない形式に加工されたものでもよい。例えばユーザＩＤをハッシュ関数に変換してもよい。

情報処理装置１００は、移動履歴データおよびユーザ属性データを、通信インタフェース１０８を用いて、ネットワーク１１０に接続されたサーバ１２０から取得することができる。情報処理装置１００を管理する会社が、通信会社等と異なる会社の場合は、事前に通信会社等と、移動履歴データおよびユーザ属性データの提供を受けるための契約を結んでいてもよい。

図１の例では１台のサーバ１２０のみ備えられているが、サーバ１２０以外にも、種々のサーバがネットワーク１１０に接続されて、情報処理装置１００に情報（例えば地図データなど）を提供してもよい。

情報処理装置１００は、単一のコンピュータにより構成されてもよいし、ネットワークを介して相互に接続された複数のコンピュータからなるシステムとして構成されてもよい。

図２は、情報処理装置１００の機能ブロック図である。図１のコンピュータが実行するコンピュータプログラムによって、図２の機能が実現される。情報処理装置１００は、データ記憶部２１０、前処理部２２０、旅程判別部２３０、宿泊判定部２４０、出力情報生成部２５０およびデータ取得部２６０を備える。

データ取得部２６０は、ネットワーク１１０を介して、サーバ１２０からユーザの移動履歴データ２１１およびユーザ属性データ２１２を取得して、データ記憶部２１０に格納する。また、データ取得部２６０は、メッシュ属性データ２１３および地図データ２１４の少なくとも一方を、サーバ１２０または別のサーバから取得して、データ記憶部２１０に格納する。あるいは、メッシュ属性データ２１３および地図データ２１４の少なくとも一方は、予めオペレータの操作により記録媒体からデータ記憶部２１０にインストールしてもよい。記録媒体の具体例は、メモリ装置、ＣＤ−ＲＯＭ、ハードディスク装置などである。

データ記憶部２１０は、移動履歴データ２１１、ユーザ属性データ２１２、メッシュ属性データ２１３、地図データ２１４、および後述する出力情報生成部２５０が生成する出力情報（ストリーム情報、サマリ情報）２１５を格納する。その他、データ記憶部２１０は、各部２２０〜２５０が処理の途中や処理の結果として生成するデータを格納してもよい。

地図データ２１４は、地図要素の位置やサイズ、範囲等の情報を表した、いわゆる地図を表した情報である。地図要素の情報の例として、緯度・経度、地名、住所、建物名、道路名、地域や建物、道路の形状または範囲など、様々な地図中の要素を表す情報がある。

ユーザ属性データ２１２は、複数人のユーザの属性情報を格納したデータである。図３に、ユーザ属性データ２１２の例を示す。複数のユーザについて、ユーザＩＤと、自宅の位置情報、職場の位置情報、年齢の情報、性別の情報が格納されている。職場の位置情報が「−」のユーザは、職場が存在しないもしくは不明なユーザである。ここで示す項目は一例に過ぎず、職業など他の項目が存在してもよい。

自宅および職場の位置情報は、地域を経緯度に基づき一定のサイズの複数のメッシュに分割（メッシュ化）したときに自宅および職場が属するメッシュの識別子（メッシュコード）である。メッシュ化された個々の領域（メッシュ）のサイズは、一例として５００ｍ×５００ｍ、１００ｍ×１００ｍ、３００ｍ×３００ｍがあるが、特定のサイズに限定されない。また、メッシュの縦と横のサイズが異なってもよい。また、メッシュの形状は矩形に限られず、正多角形など、別の形状でもよい。また、地域ごとに、メッシュのサイズが異なってもよい。

図４は、地域を経緯度に基づきメッシュ化した例を示す。地域が複数のメッシュに分割されている。個々の矩形がメッシュであり、個々のメッシュには、メッシュの位置を表す固有の識別コード（メッシュコード）が付与されている。あるユーザ（ユーザＩＤがＵ００００１）の自宅４０１が示されている。この場合、ユーザの自宅位置は、自宅４０１が属するメッシュのメッシュコード（図の例ではＭ００２１）によって表される。ここでは２次元のメッシュ化を行っているが、高さ（高度）を含めた３次元のメッシュ化を行ってもよい。

ここで地域とは、任意に定めた領域のことであり、一例として市区町村、都道府県、地方（関東地方、東北地方など）がある。また、メッシュも地域の一例である。

移動履歴データ２１１は、１または複数人のユーザの移動履歴を表す。移動履歴データ２１１は、複数のユーザの移動履歴をテーブル等のデータベースに格納したものでもよいし、ユーザごとのファイルでもよい。移動履歴データ２１１は、移動履歴として、少なくとも時刻情報と位置情報とを含む。

図５に、あるユーザ（例えばユーザＩＤがＵ００００１のユーザ）についての移動履歴データ２１１の例を示す。時刻情報は、ユーザ端末１４０で位置情報が取得された時刻を表す。位置情報が取得される間隔が１５分であれば、時刻情報の間隔は１５分である。時刻情報は、時刻の値そのものでもよいし、時刻をコード化したものでもよい。例えば一定時間ごとに位置情報を取得する場合は、一定時間毎に１だけ値がインクリメントされるコードでもよい。図の例では、一定時間ごとに値が１インクリメントされるコードにより時刻を表している。例えば、ある時刻を“Ｔ０００００１１０”で表す場合に、その一定時間後の時刻を、１インクリメントした“Ｔ０００００１１１”によって表す。

位置情報は、時刻情報で示される時刻においてユーザ端末１４０で測位されたユーザ端末１４０の位置をメッシュコードに変換したものである。ただし、位置情報を、メッシュコードでなく、経度・緯度等の値で表す場合も排除されない。

図５の例では、ユーザが、時刻Ｔ０００００１１０でメッシュＭ００２１に存在し、一定時間後の時刻Ｔ０００００１１１にはメッシュＭ００２３に存在し、さらにその一定時間後の時刻Ｔ０００００１１２にはメッシュＭ００５１に存在し、さらにその一定時間後の時刻Ｔ０００００１１３には、同じメッシュＭ００５１に存在することなどが表されている。なお、“メッシュＸＸＸＸ” （Ｘには任意の値が入る）とはメッシュコードがＸＸＸＸのメッシュのことである。

メッシュ属性データ２１３は、各メッシュのメッシュコードと属性情報とを格納したデータである。図６は、メッシュ属性データ２１３の一例を示す。ここでは、属性情報として、メッシュの属する市区町村、メッシュの属する都道府県、メッシュの経度・緯度の情報が含まれる。市区町村および都道府県は、図の例では名称により表しているが、コードにより表しても良い。経度はＸから始まる４桁のコード、緯度はＹから始まる４桁のコードで模式的に表している。経度・緯度は、例えばメッシュ内の所定位置（例えば中心）を表す。メッシュの位置を特定可能であれば、メッシュ内の他の位置を用いてもかまわない。市区町村は、複数のメッシュを包含する領域であり、都道府県は複数の市区町村を包含する領域である。なお、１つのメッシュが複数の地域（例えば複数の市区町村）にまたがってもよい。この場合は、メッシュに属する面積の大きい方の市区町村に、当該メッシュが属するとしてもよいし、別の基準で、当該メッシュが属する市区町村を決定してもよい。

図７に、メッシュと市区町村との関係を示す。ある県におけるＹ市、Ｋ市およびＮ市のそれぞれの一部の領域が示される。各市は複数のメッシュを包含している。各メッシュの経度・緯度は異なるが、いくつかのメッシュでは、市区町村および都道府県が同じである。前述の図６の例では、メッシュＭ０００２１とＭ０００２２は経度・緯度は異なっているが、同じ市および同じ県に属する。

（前処理部２２０）
図１の前処理部２２０は、メッシュ属性データ２１３を用いて、移動履歴データ２１１に前処理を行う。具体的には、移動履歴データ２１１における位置情報が示すメッシュの属性情報をメッシュ属性データ２１３から特定し、特定した属性情報を移動履歴データ２１１に追加する。図６のメッシュ属性データ２１３の場合に、図５の移動履歴データ２１１にメッシュの属性情報を追加した例を図８に示す。

前処理部２２０は、前処理後の移動履歴データ２１１に対して間引処理を行ってもよい。間引処理とは連続して同じメッシュのデータが続く場合に、これらのデータを１つにまとめることである。例えば、連続して同じメッシュが続くデータのうち時間的に最も早いデータを残し、残りのデータを削除する。図８の例では、時刻Ｔ０００００１１２と時刻Ｔ０００００１１３とのデータのメッシュ（Ｍ００５１）が同じため、時間的後の方の時刻Ｔ０００００１１３のデータを削除する。この場合、時刻Ｔ０００００１１２から時刻Ｔ０００００１１４の前までは、継続して同じメッシュ（Ｍ００５１）にユーザがいると判断すればよい（なお、時刻Ｔ０００００１１４のメッシュはメッシュＭ００５１ではないとする）。このように間引処理を行うことで、移動履歴データ２１１のサイズを低減できる。なお、間引処理を、前処理を行う前の移動履歴データ２１１に対して行い、間引処理後の移動履歴データ２１１に対して前処理（メッシュの属性情報の追加）を行ってもよい。

また、前処理部２２０は、メッシュ属性データ２１３を用いて、ユーザ属性データ２１２に前処理を行う。具体的には、ユーザ属性データ２１２に含まれる自宅の位置情報および職場の位置情報が示すメッシュの属性情報をメッシュ属性データ２１３から特定し、特定した属性情報を、ユーザ属性データ２１２に追加する。図６のメッシュ属性データ２１３の例の場合に、図３のユーザ属性データ２１２にメッシュの属性情報を追加した例を図９に示す。

（生活圏）
本実施形態では、ユーザが当該ユーザの生活圏を出ている間、ユーザは旅行、または旅程した行動をしていると定義する。例えばユーザが生活圏から出て、生活圏に戻ってくるまでユーザが旅行、または旅程した行動をしている。生活圏とは、日常的に活動を行う領域であり、一例として、ユーザの自宅または職場またはこれらの両方等を含む領域である。

図１０に旅行（旅程した行動）の概念図を示す。ユーザの生活圏にユーザの自宅１００１が存在する。ユーザが経路１００２で生活圏内を移動し、地点１００３で生活圏を出る。その後、生活圏外（非生活圏）の経路１００４を移動し、再び地点１００５で生活圏に戻ってくる。その後、経路１００６で自宅１００１に戻る。この場合、経路１００４の移動工程の全部または一部が、旅行または旅程に対応する。

（旅程判別部２３０）
旅程判別部２３０は、対象となるユーザの生活圏を決定する。例えば、ユーザ属性データ２１２および当該ユーザの移動履歴データの少なくとも一方を用いて、当該ユーザの生活圏を決定する。一例として、ユーザの自宅または職場を含むメッシュを生活圏と決定する。または、ユーザの自宅または職場から一定の距離範囲の領域（例えば半径３ｋｍ内の領域）に属するメッシュ群をユーザの生活圏としてもよい。この際、当該領域の端がメッシュを横切る場合は、当該メッシュも生活圏に含めるとするが、含めないように定義してもよい。自宅と職場の両方を対象とする場合、ユーザには２つの生活圏が存在してもよい。

また、生活圏を決定する別の方法として、以下の方法を用いてもよい。例えば移動履歴データにおいてある一定期間（例えば１週間）内に含まれる各メッシュの発生確率を計算する。ユーザ端末１４０が１５分に１回位置データを送信する場合、１日あたり９６（＝４×２４）個の位置データが取得され、１週間では、６７２（＝９６×７）個の位置データが取得される。当該１週間において、あるメッシュの発生回数が３３６であるとすると、当該メッシュの発生確率は３３６／６７２（＝０．５）である。発生確率を閾値と比較し、閾値以上であれば、生活圏、閾値未満であれば、非生活圏と判断する。仮に閾値が０．１であれば、上記発生確率が０．５のメッシュは生活圏と判断される。このようにして閾値以上のメッシュをすべて特定し、特定したメッシュの集合を生活圏とする。発生確率ではなく、上記の発生回数を閾値と比較してもよい。この場合、発生回数が閾値未満であれば、非生活圏、閾値以上であれば、生活圏と判断する。発生確率または発生回数は、発生頻度の一例である。発生頻度を表す他の値を用いてもよい。移動履歴データを用いて生活圏を決定する場合に、使用するデータとして、位置情報が自宅（または職場）からの距離が一定値以下との条件を満たすデータのみ用いてもよい。これにより、たまたまユーザが長期間遠出した場合のデータのみを用いて生活圏を決定することを防止できる。

旅程判別部２３０は、特定したユーザの生活圏に含まれるメッシュのメッシュコードの集合を生活圏データとして得る。生活圏データをデータ記憶部２１０に格納してもよい。

旅程判別部２３０は、生活圏データと移動履歴データ２１１とに基づき、ユーザが旅行をしたか否か、すなわちユーザが生活圏を出たか否かを判別する旅程判別処理を行う。日帰り旅行は、例えば観光のみの旅行（宿泊なしの旅程）である。

ここで１日の始まりの時刻を基準時刻と称する。基準時刻は任意に定義できる。基準時刻は、一例として朝の時間帯に属する時刻である。本実施形態では６：００を基準時刻とする。この場合、０６：００（午前６時００分）〜０５：５９（午前５時５９分）までが１日となる。ただし、基準時刻は、０７：００、０７：３０、または０８：００など、別の時刻でもかまわない。また、基準時刻は、昼の時間帯、または夜の時間帯に属してもよい。

図１１は、旅程判別部２３０による旅程判別処理の一例のフローチャートである。まずユーザの移動履歴データ２１１において、本処理に用いるデータ範囲を特定する。当該ユーザの移動履歴データのすべてを本処理に用いるとしてもよいし、オペレータが指定した範囲のデータ（例えば６月１０日〜６月２０日までのデータなど）でもよい。旅程判別部２３０は、特定したデータ範囲の最初のデータから処理を開始する（Ｓ１１０１）。例えば、特定したデータ範囲が６月１０日から６月２０日までのデータであれば、６月１０日の６：００のデータから処理を開始する。

旅程判別部２３０は、処理の対象となるデータに基づき、ユーザが生活圏内に位置しているどうか、すなわちユーザ端末１４０が生活圏内に位置しているか判断する（Ｓ１１０２）。当該データに含まれるメッシュコードが、上記の生活圏データに含まれていれば、ユーザが生活圏内にいると判断する。一方、生活圏データに当該メッシュデータが含まれていない場合は、ユーザは生活圏内にいない（生活圏外にいる）と判断する。ユーザが生活圏内にいると判断した場合は、そのデータに対して生活圏内にいることを示す値（例えば“１”）にしたフラグ（生活圏フラグ）を設定し、生活圏内にいないと判断した場合は、そのデータに対してユーザが生活圏外にいることを示す値（例えば“０”）にした生活圏フラグを設定する（Ｓ１１０３）。生活圏フラグを設定後、次以降のデータ以降についても、同様に、ユーザが生活圏内にいるか否かの判断と、生活圏フラグの設定とを繰り返す（Ｓ１１０４のＮＯ）。図８の移動履歴データに対して生活圏フラグを設定した例を図１２に示す。「内」はユーザが生活圏内にいることを表す値に対応し、「外」はユーザが生活圏外にいることを表す値に対応する。「外」の生活圏フラグが設定された期間は、ユーザが生活圏外にいる期間に対応する。

特定した範囲内のすべてのデータに対して生活圏フラグを設定したら、フラグ設定後のデータを用いて、ユーザが生活圏を出てから、データ当該生活圏内に戻ってくるまでのデータを旅程データとして検出する（Ｓ１１０５）。フラグが「内」から「外」に最初に変わったときに生活圏を出たと判断でき、その後、「外」から「内」に変わったときにユーザが生活圏に戻ったと判断できる。そこで、「内」から「外」に変わったときの当該「外」のデータから、次に「内」に戻るまでの一連のデータを、旅程データとして特定する。

図１２の例では、時刻Ｔ０００００１１１では生活圏内にいたユーザが、時刻Ｔ０００００１１１で生活圏外になり、その後、時刻Ｔ０００００２３３で生活圏に戻ったため、時刻Ｔ０００００１１１〜時刻Ｔ０００００２３３までの一連のデータを旅程データとする。このように、生活圏を出てから戻るまでのデータを１単位として旅程データとする。時刻Ｔ０００００２３４以降の後続するデータについても同様にして、生活圏を出た時刻と、戻った時刻を特定し、旅程データを特定する。これを繰り返し行う。以下の処理は、特定した各旅程データについて行う。ここでは、旅程データとして、ユーザが生活圏を出てから戻るまでの一連のデータとしたが、ユーザが生活圏を出ている間のデータを含む限り、これに限定されない。例えばユーザが生活圏に戻ったときのデータ（図１２の例ではＴ０００００２３３のデータ）を旅程データが含まなくても良い。また、ユーザが生活圏を出ている間の一部のデータを旅程データとしてもよい。すなわち、ユーザが生活圏外に位置している期間の少なくとも一部の期間に含まれる位置情報と時刻情報とを含む限り、旅程データは任意に定めることができる。

（宿泊判定部２４０）
宿泊判定部２４０は、旅程判別部２３０で特定された旅程データに基づき、ユーザが日帰り旅行（宿無しの旅程）をしたか、宿泊付きの旅行（宿泊有りの旅程）をしたかを判断する。宿泊とは、ホテル、旅館またはテント等の宿泊施設を利用することを意味する。ユーザが宿泊したと判断した場合、ユーザが宿泊した回数と、ユーザが宿泊した地域（ここでは市区町村）とを判定する。

図１３は、本実施形態に係る宿泊判定部２４０により行われる宿泊判定処理のフローチャートである。本フローチャートのステップの順序は一例であり、動作の矛盾が無い限り、ステップの順序を入れ替えても問題ない。

宿泊判定部２４０は、上記の特定した旅程データに基づき、ユーザの宿泊の有無を判断する（Ｓ１３００）。すなわち、ユーザが日帰り旅行（宿泊無しの旅程）をしたのか、宿泊付きの旅行（宿泊有りの旅程）をしたのかを判断する。

一例として、旅程データの時間長が２４時間以上（１日以上）であれば、ユーザが宿泊した（１泊以上の旅程）と判断し、２４時間未満であれば、宿泊していない（日帰り旅行を行った）と判断する。旅程データの時間長とは、旅程データに含まれる最初のデータの時刻情報が示す時刻（開始時刻）と、最後のデータの時刻情報が示す時刻（終了時刻）との差分の時間長である。旅程判別部２３０は、判断対象となった旅程データに対して、宿泊したか否かを表すフラグ（宿泊フラグ）を付与する。例えば、宿泊した場合、宿泊フラグの値を“１”にし、宿泊していない場合は、宿泊フラグの値を“０”にする。図１４を用いて、ユーザが宿泊したか否かを判断する具体例を説明する。

図１４に示すように、ユーザが生活圏を出た日時が６月１０日０６：１５、生活圏に戻った日時が６月１１日０７：３０であったとする（旅程１）。この場合、旅程の開始時刻と終了時刻との差分が２４時間以上のため、ユーザは宿泊した（１泊以上の旅程）と判断する。別の例として、生活圏を出た日時が６月１０日０６：１５、生活圏に戻った時刻が６月１１日０１：３０であったとする（旅程２）。この場合、旅程の開始時刻と終了時刻との差分が２４時間未満のためユーザは宿泊していない（日帰り旅行を行った）と判断する。

宿泊判定部２４０は、旅程判別部２３０でユーザが宿泊したと判断された旅程データに対して、何回日をまたいでいるかカウントする（Ｓ１３０１）。すなわち、１日の基準時刻となる０６：００を何回経過しているかをカウントする。カウント値を変数Ｋにより表す。

次に、宿泊判定部２４０は、ユーザが宿泊したと判断された旅程データに基づき、ユーザの出発が早朝出発であるかを判断する（Ｓ１３０２）。早朝出発は、開始時刻（生活圏を出た時刻）が、基準時刻より一定時間前の時刻（第１時刻）と、基準時刻との間の場合である。例えば、基準時刻が０６：００の場合に、第１時刻が基準時刻の３時間前の０３：００であるとする。この場合、開始時刻が、０３：００以降、０６：００前であれば、早朝出発と判断する。早朝出発か否かを判断する具体例を、図１５を用いて説明する。

図１５に示すように、生活圏を出た日時が６月１０日０５：００、生活圏に戻った日時が６月１１日１９：１５であったとする（旅程３）。この場合、開始時刻が第１時刻（０３時００分）以降で、基準時刻（０６時００分）より前のため、早朝出発と判断する。

第１時刻は、ここでは基準時刻の３時間前であったが、２時間前でもよいし、１時間前でもよいし、その他の時間前の時刻でもよい。基準時刻および第１時刻は、ユーザの属性（例えば年齢または性別など）に応じて変更してもよい。また、基準時刻および第１時刻は、調整可能な値としてオペレータにより設定可能なパラメータとしてもよい。

ステップＳ１３０２において早朝出発と判断された場合（ＹＥＳ）、ステップＳ１３０１で計算されたカウント値Ｋから１を引く（Ｓ１３０３）。これは、早朝出発の場合、基準時刻をまたいでいても、ユーザが生活圏外で宿泊したわけではないため（例えば自宅で宿泊したと想定されるため）、１泊としてカウントすることは適切でないためである。一方、早朝出発でないと判断された場合は（ＮＯ）、カウント値Ｋをそのまま維持する。

次に、当該旅程データに基づき、ユーザが宿泊した地域（市区町村またはメッシュなど。以下の説明では市区町村とする）を特定する（Ｓ１３０４）。具体的には、まず、旅程データにおける各日について、特定の時間帯において所定時間以上滞在したメッシュを特定する。所定時間以上滞在したメッシュが複数存在するときは、最も長く滞在したメッシュを特定する。そして、特定したメッシュを含む市区町村を、ユーザが宿泊した市区町村とする。特定の時間帯は、一例として２２：００から０６：００までの時間帯（２２：００−６：００）である。また、所定時間は、一例として１時間である。ただし、特定の時間帯および所定時間は、これらの値に限定されず、他の値でもよい。特定の時間帯および所定時間は、ユーザの属性（例えば年齢または性別など）に応じて変更してもよい。また、特定の時間帯および所定時間は、調整可能な値としてオペレータにより設定可能なパラメータでもよい。

特定の時間帯において、ユーザが所定時間以上滞在しているメッシュが存在しない場合は、ユーザは夜通し、移動していた（すなわち宿泊していない）と判断してもよい。

次に、上記のステップＳ１３０４で特定した市区町村（宿泊地）のうち、旅程初日の宿泊地（市区町村）が、ユーザ自宅の市区町村に一致するかを判断する（ステップＳ１３０５）。この判断は、旅程初日の宿泊地（市区町村）が、ユーザ属性データ２１２（図９参照）における該当ユーザの自宅の市区町村と一致するかで行う。

旅程初日の宿泊地がユーザ自宅の市区町村に一致する場合は（ＹＥＳ）、カウント値Ｋから１を引く（Ｓ１３０６）。また、上記ステップＳ１３０４で特定した宿泊地（市区町村）のうち、初日宿泊地であるユーザ自宅の市区町村を除去する。例えば、ユーザの生活圏をユーザ自宅の市区町村が包含している場合を想定する。この場合、初日宿泊地が、ユーザ自宅の市区町村内であるが、ユーザの生活圏外である場合がある。例えば、ユーザが夜間出発し、飲食店での飲食または交通機関の出発待ち等で所定時間以上、ユーザ自宅の市区町村内かつユーザの生活圏外に位置するメッシュに滞在した場合、ユーザ自宅の市区町村で宿泊したと判断され得る。この場合、旅先での宿泊とは言えないため、１泊としてカウントしない。本ステップＳ１３０６の処理の具体例を、図１６を用いて説明する。

図１６に示すように、ユーザが６月１０日２３：１５に生活圏を出て、途中でユーザ自宅の市区町村内のレストランに、所定時間Ｔ１の間、滞在したとする。レストランを出た後は、夜間を通して、移動し、６月１０日０６：００になったとする。この後、観光および宿泊等して、翌日の６月１１日０７：３０に生活圏に戻ったとする（旅程４）。この場合、生活圏外で所定時間Ｔ１以上の間滞在したため上記ステップＳ１３０３で１泊としてカウントされていることから、本ステップＳ１３０６では、その分のカウントを無かったことにする。このため、カウント値Ｋから１を引く。また、上記のステップＳ１３０４で特定した宿泊地（市区町村）のうち、ユーザの初日の宿泊地として特定されたユーザ自宅の市区町村を除去する。

一方、ステップＳ１３０５において旅程初日の宿泊地（市区町村）が、該当ユーザ自宅の市区町村でないと判断した場合は（ＮＯ）、カウント値Ｋをそのまま維持する。

以上の処理により、ユーザが宿泊した回数（あるいは旅程の日数）と、ユーザが宿泊した地域（ここでは市区町村）とが特定される。

（出力情報生成部２５０）
出力情報生成部２５０は、旅程判別処理および宿泊判定処理の結果に基づき、出力情報２１５を生成する。出力情報２１５として、ストリーム情報と、サマリ情報とを生成する。

（ストリーム情報）
ストリーム情報は、ユーザの移動したメッシュ、市区町村、都道府県、滞在時間等の履歴を表した情報であり、旅程データから生成される。

図１７に、出力情報生成部２５０により生成されたストリーム情報の一例を示す。ストリーム情報は、シーケンス番号、メッシュコード、経緯度、市区町村、都道府県、滞在期間（滞在の開始時刻および終了時刻）の情報を含む。このストリーム情報は、図１２の移動履歴データから特定された旅程データに対応する。なお、図１２では、時刻をコードにより表していたが、図１７では滞在期間の開始時刻および終了時刻を、年月日時分の値により表している。

出力情報生成部２５０は、旅程データに基づき、ストリーム情報を生成する。具体的には、旅程データにおいて、連続して同じメッシュを示すデータを１つのシーケンスデータとしてまとめ、当該連続するデータの最初のデータの時刻情報と末尾のデータの時刻情報に基づき、当該メッシュにおける滞在期間を特定し、滞在期間の開始時刻および終了時刻をシーケンスデータに設定する。シーケンスデータには、シーケンス番号（シーケンスＮｏ）を付与する。

例えば、図１７のシーケンス番号００００２のシーケンスデータは、図１２の時刻Ｔ０００００１１２、Ｔ０００００１１３のデータを１つにまとめたものである。図１２のデータが１５分おきのデータであるとし、時刻Ｔ０００００１１２が２０１８／０６／２０／０５：１５に対応し、時刻Ｔ０００００１１３が２０１８／０６／２０／０５：３０に対応するとする。このとき滞在期間は２０１８／０６／２０／０５：１５〜２０１８／０６／２０／０５：４５である。よって、滞在期間の開始時刻および終了時刻として、２０１８／０６／２０／０５：１５および２０１８／０６／２０／０５：４５を設定する。以降、旅程データに対して同様の処理を繰り返すことで、図１７のストリーム情報が生成できる。ストリーム情報を分析することで、ユーザがどのような旅程や経路で各地域を訪れたり、各地域でどのように過ごしたりするのかを分析できる。分析の結果を、各地域の観光促進に役立てることができる。

なお、同じユーザに対して複数の旅程データが検出された場合は、２番目以降の旅程データについても同様にしてストリーム情報を生成する。２番目以降のストリーム情報を１番目のストリーム情報の末尾に続けてもよいし（図１７の例では２番目のストリーム情報はシーケンス番号０００５０から始まる）、同じユーザの複数のストリーム情報を別々のファイルとして管理してもよい。ストリーム情報を管理するデータベースにユーザＩＤの列を設け、複数のユーザのストリーム情報を同じデータベースで管理してもよい。あるいは、各ユーザのストリーム情報を、別々のファイルとして管理してもよい。

（サマリ情報）
サマリ情報は、ユーザの旅程の概要を表した情報あり、例えば旅程判別処理および宿泊判定処理の少なくとも一方の結果と、ストリーム情報（１旅程分のストリーム情報）とから生成できる。サマリ情報は、一例として、ユーザＩＤ、旅程日数、シーケンス番号、日付、宿泊市町村の情報を含む。

図１８（Ａ）に、サマリ情報の例を示す。このサマリ情報は図１７のストリーム情報に基づき生成されている。このサマリ情報はユーザ１（ユーザＩＤがＵ００００１のユーザ）に対して生成されている。旅程日数および宿泊市町村は、宿泊判定処理の結果から取得できる。この例では、宿泊判定処理でユーザが１泊したと判断されたため、１泊との情報を宿泊判定処理の結果から取得し、サマリ情報に設定する。また、宿泊判定処理でユーザがＴ県Ｌ市に宿泊したと判断されたため、Ｔ県Ｌ市の情報を宿泊判定処理の結果から取得し、サマリ情報に設定する。シーケンス番号は、サマリ情報の生成する元となった１旅程分のストリーム情報に含まれるシーケンス番号の範囲である。旅程日付は、当該するストリーム情報の最初のシーケンスデータの時刻の日付から、最後のシーケンスデータの日付までの範囲を設定する。

図１８（Ｂ）は、サマリ情報の他の例を示す。図１８（Ａ）と同じくユーザ１に対して生成されたサマリ情報であるが、図１８（Ａ）とは異なる旅程データに対して生成されている。ユーザは、２０１８年６月２７日〜２９日の２泊で、Ａ県Ｈ市と、Ｙ県Ｙ市のこの順で宿泊している。対応するシーケンス番号は０００５０〜００１６７（これらのシーケンスデータは図示せず）である。

図１８（Ｃ）は、サマリ情報のさらに他の例を示す。図１８（Ａ）および図１８（Ｂ）と同じくユーザ１に対して生成されたサマリ情報であるが、図１８（Ａ）および図１８（Ｂ）とは異なる旅程データに対して生成されている。旅程判別処理でユーザは宿泊していない（日帰り旅行をした。宿泊無しの旅程）と判断されたため、旅程日数の項目には、「日帰り」が設定されている。「宿泊無」など他の表記でもよい。宿泊していないと判断されたため、宿泊市町村の項目には、宿泊地が無いことを意味する「−」が設定されている。また、日付は、１日分の日付となっている。

図１８（Ａ）〜図１８（Ｃ）で示したサマリ情報は一例であり、他にも様々な項目を追加し、または、項目の内容を拡張してもよい。例えばユーザが早朝出発をしたと判断された場合は（図１３のＳ１３０２参照）、ユーザが早朝出発したことを表す情報を追加してもよい。また、ユーザが夜間出発をしたと判断された場合は（図１３のＳ１３０５参照）、ユーザが夜間出発したことを表す情報を追加してもよい。また、旅程日数は、宿泊日数のみならず、旅程全体の日数を含めてもよい。例えば、図１８（Ａ）の例では、旅程日数を、１泊２日としてもよい。

図１９は、本実施形態に従った情報処理装置１００の動作の一例のフローチャートである。前処理部２２０が、メッシュ属性データ２１３を用いて、移動履歴データ２１１およびユーザ属性データ２１２に対して、市区町村、都道府県、経緯度等の属性情報を追加する前処理を行う（Ｓ１９０１）。

旅程判別部２３０が、前処理後の移動履歴データ２１１に基づき、各ユーザについて、旅程データの検出を行う（Ｓ１９０２）。旅程データは、各ユーザが各々の生活圏を出ている間の移動履歴（位置情報と時間情報）であり、例えば生活圏を出てから当該生活圏に戻るまでの時間範囲に属する移動履歴である。１人のユーザあたり、旅程データが複数検出される場合もある。

宿泊判定部２４０は、ユーザの旅程データに基づき、ユーザが生活圏外で宿泊したか否かを判断する（Ｓ１９０３）。例えば旅程データの時間長が２４時間以上であれば、宿泊したと判断する。ユーザが宿泊したと判断した場合、ユーザが宿泊した回数および宿泊地（例えば市区町村またはメッシュ）を特定する（同Ｓ１９０３）。具体的には、旅程データにおいて基準時刻が経過した回数をカウントし、カウントした回数だけユーザは宿泊したと判断する。この際、前述した早朝出発が検出された場合、およびユーザ自宅の市区町村での宿泊が検出された場合（夜間出発の場合）、それぞれカウント回数を１減算する。これにより、宿泊回数を高精度に求める。

出力情報生成部２５０は、宿泊判定部２４０の判定結果と、旅程データとに基づき出力情報２１５としてストリーム情報と、サマリ情報とを生成する（Ｓ１９０４）。ストリーム情報は、ユーザが経由した地域（メッシュ、市区町村、都道府県など）と、当該地域に滞在した期間とを時系列に表したものであり、旅行中におけるユーザの滞在履歴である。サマリ情報は、ユーザの旅程の概要（宿泊日数、宿泊場所、日付など）を表した情報である。

以上、本実施形態によれば、旅程データを用いることで、ユーザが旅行中に宿泊したか否かを判定できる。すなわち、ユーザが生活圏外で宿泊という行動を行ったか否かを推定できる。

また、本実施形態によれば、ユーザが生活圏を出てから生活圏に戻るまでの期間のデータを旅程データとすることで、１回の旅程（１回分の旅行）に着目した判断を行うことができる。

また、本実施形態によれば、旅程データの時間長を用いてユーザの宿泊有無を判断することで、精度の高い判断が可能となる。

また、本実施形態によれば、特定の時間帯に所定時間以上滞在した地域にユーザが宿泊したことを決定することで、高い精度でユーザが宿泊した地域を特定できる。

また、本実施形態によれば、１日の基準時刻を経過した回数に基づき、ユーザが宿泊した回数を計算することで、ユーザが宿泊した回数を高い精度で計算できる。

また、本実施形態によれば、基準時刻が早朝の時間帯に属し、ユーザが早朝出発して基準時刻をまたいだ場合をカウント対象から除外することで、ユーザが宿泊した回数を高い精度で計算できる。

また、本実施形態によれば、例えば、ユーザが夜間出発し、ユーザの生活圏を包含する地域で所定時間以上滞在した場合に、当該地域に宿泊したと誤判断されることを防止できる。

また、本実施形態によれば、ユーザが経由した地域と、地域に滞在した期間とを時系列に表した出力情報を生成することで、ユーザがどのような旅程や経路で各地域を訪れたり、各地域でどのように過ごしたりするのかを分析できる。分析の結果を、各地域の観光促進に役立てることができる。

（変形例１）
ユーザが移動の途中でユーザ端末１４０の電源がＯＦＦになったり、電波環境が悪くなったりした場合にユーザ端末１４０が基地局１３０と通信不能な状況に陥る場合がある。このとき、サーバ１２０はユーザ端末１４０から位置データを取得できず、移動履歴データ２１１の一部にデータの欠落が発生する。

例えば、ユーザが生活圏を出て、さらに自宅の市区町村（生活圏を包含する第１地域）を出た後に、観光および宿泊等し、その後、帰途につく場合を想定する。帰りの途中で、ユーザ端末１４０の電池残量が少なくなり、ユーザ端末１４０の電源がＯＦＦになることがある。この場合、取得される位置データの末尾はユーザ端末１４０が電源ＯＦＦになる直前に取得されたデータであり、生活圏に入る前に位置データが途切れてしまう。

図２０は、本変形例１の具体例を説明するための図である。ユーザの生活圏にユーザの自宅２００１が存在する。ユーザが自宅２００１を出発し、地点２００３で生活圏を出る。その後、経路２００４を移動する。より詳細には、まずユーザ自宅の市区町村内を通過し、その後、市区町村外に出る。旅先で観光および宿泊などし、帰途につく。ユーザ自宅の市区町村に戻り、市区町村内を通過し、生活圏に向かう途中の地点２００７でユーザ端末１４０の電源がＯＦＦになる。以降、サーバ１２０では、ユーザ端末１４０からの位置データの取得が中止される。ユーザ端末１４０が電源ＯＦＦのままユーザは移動し、地点２００５で生活圏に入り、自宅２００１に到着する。図中の実線の経路は、サーバ１２０がユーザ端末１４０から位置データを一定時間毎に取得している経路であり、破線の経路は、サーバ１２０がユーザ端末１４０から位置データを取得できていない経路である。

サーバ１２０による位置データの取得が生活圏から離れた位置で停止してしまうため、出力情報生成部２５０で生成されるストリーム情報（または移動履歴データ２１１）を辿っても、ユーザが生活圏に戻るところまで確認できない。そこで、本変形例では、少なくともユーザ自宅の市区町村内にまで戻っている場合は、ユーザがその後自宅（または生活圏）に帰ったとみなし、市区町村に戻ったときまでのデータを旅程データとして検出する。また、ユーザが帰宅した（または生活圏に帰った）ことを示すシーケンスデータをストリーム情報に追加する。これにより、移動履歴データ２１１の途中で位置データが欠落している場合でも、旅程データを検出し、ストリーム情報およびサマリ情報を生成できる。

図２１に、ユーザが旅先から戻りの途中で、自宅の市区町村（Ｙ市）に入り、生活圏に入る前にユーザ端末１４０の電源がＯＦＦになった場合の移動履歴データの例を示す。ここでは時刻の列に、時刻の値ではなく、時刻を表すコードが格納されてもよい。

６月２１日の１８：４５まで位置データが取得されているが、同日付の１９：００以降で位置データが欠落している。位置データの欠落を示すため、欠落している時刻の位置データをデータ取得間隔で補完し、時刻以外の列には“Ｎ／Ａ”を入れている。ただし、このようなデータの補完を行わなくともよい。この場合、時刻間隔がデータ取得間隔より大きくなっている箇所で、位置データの欠落があると見なす処理を行えばよい。データが途切る直前の位置データの位置情報はメッシュＭ００５１を表しており、メッシュＭ００５１の市区町村は、ユーザの生活圏内ではないものの、ユーザ自宅と同じ市区町村（Ｙ市）内である。この場合、旅程判別部２３０では、一例として６月２１日の１８：４５までの位置データを旅程データとして検出する。また、出力情報生成部２５０では、生成するストリーム情報における当該メッシュＭ００５１の滞在を示すシーケンスデータに続けて、ユーザは生活圏（または自宅）に戻ったことを示すシーケンスデータを追加する。

図２２に、本変形例１における出力情報生成部２５０で生成されるストリーム情報の例を示す。このストリーム情報は、図２１の移動履歴データから特定された旅程データに基づき生成されたものである。シーケンス番号０００４８のシーケンスデータとして、メッシュコードの列に生活圏に帰ったことを表すコード（帰宅コード）（図では「ＭＭＭＭ」と表記している）を含むシーケンスデータが追加されている。帰宅コードを含むシーケンスデータを帰宅ログと呼ぶ。このように帰宅ログをストリーム情報に追加したことにより、ユーザが市区町村内のメッシュＭ００５１に入った後、生活圏（あるいは自宅）に戻ったことが把握できる。なお、上述した第１の実施形態では生活圏に戻ったときのシーケンスデータまでストリーム情報に含まれていたため、帰宅ログが無くても、ユーザが生活圏に戻ったことをストリーム情報から把握できる。

メッシュコードの列に帰宅コードを追加するのではなく、ストリーム情報に新しい列（例えば項目名「ステータス」の列）を設け、当該列に帰宅コードを追加してもよい。この場合、他のシーケンスデータのステータス列には、他の種類のステータスを格納してもよい。例えば、滞在期間（開始時刻および終了時刻間の期間）が一定時間未満のシーケンスデータに対してはユーザが移動しているとみなし「移動」を表すステータスコードを追加してもよい。滞在期間が一定時間以上のときは、観光・食事等の滞在をしているみなし、「滞在」を表すステータスコードを追加してもよい。他の種類のコードを定義してもよい。

図２３は、本変形例１に係る出力情報生成部２５０の処理（自宅近隣判定処理）の一例のフローチャートである。旅程判別部２３０で特定された旅程データにおいてユーザが生活圏に到着する前に位置データが途切れているかを判断する（Ｓ２３０１）。位置データが途切れていない場合（ＮＯ）、本処理を終了する。すなわち、第１の実施形態と同様にしてストリーム情報を生成する。

ユーザが生活圏に入る前に位置データが途切れている場合（ＹＥＳ）、かつ途切れる直前の位置データが示すメッシュがユーザ自宅の市区町村内かを判断する（Ｓ２３０２）。当該メッシュがユーザ自宅の市区町村内の場合、ストリーム情報の末尾に、帰宅ログを追加する（Ｓ２３０３）。当該メッシュがユーザ自宅の市区町村内でない場合（ＮＯ）、第１の実施形態と同様にしてストリーム情報を生成すればよい。あるいは、位置データが途切れた後のユーザの行動は不明であることを表す情報を含むシーケンスデータをストリーム情報に追加してもよい。

本変形例１によれば、ユーザが自宅の市区町村まで戻ってきた場合は、その後ユーザは生活圏に戻ったとみなすことで、旅程データの一部に欠落があっても、ユーザが生活圏に戻るまでの移動工程を表した出力情報（ストリーム情報）を生成できる。

（変形例２）
ユーザが観光中やホテルの滞在中に、自動販売機での買い物やトイレに行くなどの理由で一時的に移動し、すぐに元の場所に戻る場合がある。このとき、メッシュ間の往復が発生し得るが、このような一時的な移動に起因するメッシュの移動を、ストリーム情報に含めることは、分析の目的に資さない場合もある。本変形例２は、このような一時的なメッシュ間の移動は無かったかのように、ストリーム情報を生成することを特徴とする。

具体的な処理としては、まず第１の実施形態と同様にして、出力情報生成部２５０がストリーム情報を作成する。作成したストリーム情報の例を図２４の上に示す。図示の例では、ユーザは、メッシュＭ０９９９で６月２０日１２：００〜６月２０日１３：３０まで滞在し（シーケンス番号０００２０）、その後、５分間、メッシュＭ０９９８に滞在し（シーケンス番号０００２１）、その後、再びメッシュＭ０９９９に戻って、６月２０日１４：３０まで滞在している（シーケンス番号０００２２）。

出力情報生成部２５０は、一時的な移動のシーケンスデータが存在するかを判断する。図２４の例では、シーケンス番号０００２１のシーケンスデータが一時的な移動のシーケンスデータと判断する（判断方法の詳細は後述する）。出力情報生成部２５０は、そのようなシーケンスデータは不要と判断する。

出力情報生成部２５０は、不要と判断したシーケンスデータを削除し、削除したシーケンスデータの前後のシーケンス番号のシーケンスデータを統合する。図２４の例では、シーケンス番号０００２１のシーケンスデータを削除し、シーケンス番号０００２０と０００２２のシーケンスデータを統合し、シーケンス番号０００２０の新たなシーケンスデータとする。そして、シーケンス番号２２より後ろのシーケンスデータのシーケンス番号を０００２１から始まる番号に振り直す。統合後のストリーム情報の例を図２４の下に示す。統合されたシーケンスデータでは、滞在期間の開始時刻および終了時刻が６月２０日１２：００および６月２０日１４：３０になっている。これによりユーザは、６月２０日１２：００〜６月２０日１４：３０の間、メッシュＭ０９９９に滞在し続けたとして記録される。

一時的な移動を表すシーケンスデータを検出するアルゴリズムはどのようなものでもよい。例えば、あるシーケンスデータが表す滞在期間の長さ（滞在期間長Ａとする）と、当該あるシーケンスデータに時間的に前に隣接するシーケンスデータが示す滞在期間の長さ（滞在期間長Ｂとする）と、当該あるシーケンスデータに時間的に後に隣接するシーケンスデータが示す滞在期間の長さ（滞在時間長Ｃ）とに基づき判断できる。一例として、Ａ／（Ａ＋Ｂ＋Ｃ）が閾値未満であれば、当該シーケンスデータを不要と判断する。

図２４の上の例であれば、シーケンス番号０００２１のシーケンスデータが示す滞在期間の長さ５分である。その前後のシーケンス番号０００２０、０００２２のシーケンスデータが示す滞在期間の長さはそれぞれ９０分、５５分である。よって５／（５＋９０＋５５）が閾値未満であれば、シーケンス番号０００２１のシーケンスデータは不要であると判断する。

（変形例３）
第１の実施形態では、宿泊判定部２４０は、ユーザの宿泊地を市区町村またはメッシュ等により特定したが、ユーザが宿泊した宿泊施設を特定してもよい。特定した宿泊施設の情報を、サマリ情報に追加してもよい。

例えば、ユーザが宿泊したと特定されたメッシュ（宿泊メッシュ）内に、地図データ２１４から宿泊施設が１つのみあることが分かる場合は、当該宿泊施設を、ユーザが宿泊した宿泊施設と決定する。

宿泊メッシュ内に１つも宿泊施設が無い場合は、宿泊メッシュの端（メッシュが矩形であれば矩形の辺）から最も近くに存在する宿泊施設を、ユーザが宿泊した宿泊施設と決定してもよい。図２５（Ａ）に、メッシュ状に分割されたある市町区村（Ｔ県Ｌ市）の一部を示す。中心のメッシュが宿泊メッシュであるが、宿泊施設は存在しない。一方、周囲の４つのメッシュには、宿泊施設２５０１〜２５０４が存在する。この場合、宿泊施設２５０３が宿泊施設のメッシュから最も近いため、宿泊施設２５０３をユーザの宿泊施設と決定する。

宿泊メッシュ内に複数の宿泊施設が存在するときは、例えば夜間の特定の時間帯に宿泊メッシュ周辺のメッシュ（近隣メッシュ）への一時的な移動履歴があるかを調べ、そのようなメッシュが存在するときは、近隣メッシュに最も近い宿泊施設を、ユーザの宿泊施設として決定してもよい。例えば、ユーザ端末１４０が搭載するＧＰＳ装置の検出誤差により、ユーザが宿泊メッシュ内に滞在している間も、近隣メッシュが検出される場合もあり得る。また、夜食の買い物等で一時的に外出し、ユーザが近隣メッシュに入る場合もある。

そこで、夜間の特定の時間帯に、近隣メッシュへの移動履歴があった場合には、宿泊メッシュ内の複数の宿泊施設のうち、近隣メッシュに最も近い宿泊施設を、ユーザの宿泊施設として特定する。図２５（Ｂ）に、メッシュ状に分割されたある市町区村（Ｔ県Ｍ市）の一部を示す。宿泊メッシュに２つの宿泊施設２５０５、２５０６が存在する。夜間の特定の時間帯に上側へのメッシュへの往復移動２５０７があったとする。この場合、上側のメッシュに近いのは宿泊施設２５０６のため、宿泊施設２５０６をユーザの宿泊施設として決定する。

また、ユーザ端末１４０が、図１のＡＰ１６０経由でサーバ１２０に位置データを送信し、ユーザ端末１４０が位置データにＡＰ１６０の識別情報（例えばＡＰ１６０のＭＡＣアドレスなど）を含める場合を考える。サーバ１２０は、アクセスポイントの識別情報の項目も含む移動履歴データを情報処理装置１００に提供する。この場合、情報処理装置１００は、ＡＰ１６０の識別情報を利用して、宿泊施設を特定してもよい。情報処理装置１００のデータ記憶部２１０には、ＡＰ１６０の識別情報（例えばＭＡＣアドレス）とＡＰ１６０の位置情報（例えば経緯度）とを含むアクセスポイント位置データを格納しておく。アクセスポイント位置データは、例えば（ＭＡＣアドレス、経緯度）のリストである。アクセスポイント位置データをデータ取得部２６０が外部のサーバから取得して、データ記憶部２１０に格納してもよい。夜間の特定の時間帯に、所定時間以上継続して識別情報が取得されたＡＰ１６０を特定し、特定したＡＰ１６０の位置に最も近い宿泊施設を、ユーザの宿泊施設として特定する。これにより、宿泊メッシュ内に複数の宿泊施設が存在する場合も、宿泊施設を高精度の特定できる。図２５（Ｃ）に、メッシュ状に分割されたある市町区村（Ｔ県Ｎ市）の一部を示す。宿泊メッシュに２つの宿泊施設２５０８、２５０９が存在する。夜間の特定の時間帯に、ＡＰ２５１１の識別情報が、所定時間以上継続して取得されたとする。この場合、ＡＰ２５１１に最も近い宿泊施設は、宿泊施設２５０８である。よって宿泊施設２５０８を、ユーザの宿泊施設として特定する。ＡＰ２５１１は宿泊施設２５０８内に設置されたＡＰでもよいし、宿泊施設２５０８の近隣に設置されたＡＰでもよい。上述した第２の変形例と同様に、一時的な要因（例えばユーザが一時的に買い物に出かける、トイレに行く、電波環境の悪化など）によりユーザ端末１４０がＡＰ２５１１から一時的に別のＡＰに接続し、当該別のＡＰの識別情報が取得された場合には、当該別のＡＰへの接続はなかったとみなし、ユーザ端末１４０は同じＡＰ２５１１に接続され続けていたとしてもよい。

（第２の実施形態）
第２の実施形態では、ある対象地域（例えばある市区町村）を訪れたユーザについて、対象地域につながっている（接続されている）複数の経路のうち、ユーザがどの経路で対象地域に入り、また、どの経路で対象地域からユーザが出たかを推定する。例えば、対象地域に出入りするための経路が４つある場合、ユーザが対象地域に入るのに用いた経路（以下、入力経路）と、対象地域から出るのに用いた経路（以下、出力経路）とを推定する。経路は、道路でも、線路でもよい。経路が空路または航路の場合も排除されない。ユーザが対象地域を訪れたかどうかは、例えばストリーム情報または移動履歴データから特定できる。

図２６は、第２の実施形態に係る情報処理装置のブロック図である。第１の実施形態の情報処理装置に対して、経路推定部２７０が追加されている。また、データ記憶部２１０には、経路メッシュデータ２１６と、経路推定部２７０により生成される経路推定情報２１７とが格納されている。以下、第１の実施形態との差分を中心に説明し、第１の実施形態と同様の部分についての説明は省略する。

経路推定部２７０は、出力情報生成部２５０により生成されたストリーム情報に基づき、ユーザが対象地域を訪れたかを調べる。対象地域は、一例として、評価対象となる第２地域に対応する。対象地域は、ある市区町村でもよいし、特定のメッシュでもよいし、ある市区町村の一部でもよいし、複数の市区町村にまたがる地域でもよいし、その他の方法で定めた地域でもよい。

対象地域をどのように特定するかに関して、予め情報処理装置のデータ記憶部２１０に対象地域のリストが保持されていてもよい。または、入出力インタフェース１０６を用いてオペレータが対象地域を指定してもよい。または、ネットワーク１１０を介して、データ取得部２６０が外部のサーバから対象地域を指定する情報を取得してもよい。対象地域を特定する方法はどのような方法でもかまわない。

経路推定部２７０は、ユーザが対象地域を訪れたと判断した場合に、ユーザが対象地域に入るのに用いた入力経路、およびユーザが対象地域から出るのに用いた出力経路の少なくとも一方を推定する（経路推定処理）。本実施形態では、経路は、メッシュにより構成される経路（メッシュ経路）である。このために、経路メッシュデータ２１６を用いる。経路メッシュデータ２１６は、ある領域を経緯度に基づきメッシュ状に分割したメッシュ領域に、１つ以上の地域と、各地域へ入出力可能な経路とをメッシュにより表したデータである。地図データ２１４と対応づけすることで、実際の経路とメッシュ経路との対応がとれるようにしてもよい。

図２７に、経路メッシュデータ２１６の一例を示す。ある領域をメッシュ状に分割したメッシュ領域に、対象地域としてのＡ町と、Ａ町の入出力可能な４つのメッシュ経路２７１１（メッシュ経路１），メッシュ経路２７１２（メッシュ経路２），メッシュ経路２７１３（メッシュ経路３），メッシュ経路２７１４（メッシュ経路４）が示されている。メッシュ経路２７１１〜２７１４内には、破線で示す実際の経路２７１１Ａ〜２７１４Ａの領域が図示されている。また、Ａ町を示すメッシュ領域内には、破線で示すＡ町の実際の領域２７２１が表されている。なお、これらの破線で示す領域は経路メッシュデータ２１６に含まれていなくてもよい。ユーザは、これら４つのメッシュ経路のいずれかを用いてＡ町に入り、また、これら４つのメッシュ経路のいずれかを用いてＡ町から出ることができる。各メッシュ経路は、１つ以上のメッシュのシーケンスとして構成される。各メッシュ経路に予め識別情報を付与し、識別情報によって各経路を識別してもよいし、各メッシュ経路を、メッシュコードのシーケンスによって識別してもよい。各メッシュ経路の長さ（メッシュ経路に含まれるメッシュの個数）は同じでも、異なっていてもよい。

図２８は、経路推定部２７０により行う経路推定処理の一例を示すフローチャートである。各ユーザに対して生成された１つまたは複数のストリーム情報をそれぞれ対象ストリーム情報として特定する（Ｓ２８０１）。

対象ストリーム情報からユーザが対象地域に入ったかを調べる（Ｓ２８０２）。ユーザが対象地域に入ったかは、例えば、対象地域と同じ地域（市区町村、メッシュ等）を示す値がストリーム情報に含まれているかで判断する。当該同じ地域を示す値がストリーム情報に含まれている場合は、当該地域を示す値を最初に含むシーケンスデータの滞在期間の開始時刻でユーザが対象地域に入ったと判断する。当該地域を示す値がストリーム情報に含まれていない場合は、ユーザが対象地域に入っていないと判断する。ユーザが対象地域に入っていないと判断した場合は（ＮＯ）、本処理を終了する。なお、対象地域が複数存在してもよく、その場合は、各対象地域について本処理および以降の処理を行う。

ユーザが対象地域に入ったと判断した場合（ＹＥＳ）、対象地域に入る前の一定時間内のシーケンスデータから、ユーザが対象地域に入るのに利用したメッシュを特定する（Ｓ２８０３）。特定したメッシュを時系列に並べたシーケンスを、入力シーケンスと称する。例えばユーザがＡ町に入る前の一定時間内に、メッシュＭ０８４８、Ｍ０８６９、Ｍ０８７７、Ｍ０８６７、Ｍ０８７３、メッシュＭ０８８８の順に移動して、Ａ町に入ったとする。この場合、入力シーケンスとして、（Ｍ０８４８、Ｍ０８６９、Ｍ０８７７、Ｍ０８６７、Ｍ０８７３、Ｍ０８８８）を特定する。なお、メッシュＭ０８８８は、ユーザが利用して経路の終端とＡ町との境界を含んでいてもよい。

入力シーケンスの別の求め方として、対象地域に入る直前の所定数のメッシュを時系列に並べたシーケンスを入力シーケンスとしてもよい。例えば、所定数が５であれば、Ａ町に入るのに使用したＡ町に入る直前の５個のメッシュの位置のシーケンスを入力シーケンスとする。

経路推定部２７０は、入力シーケンスと経路メッシュデータ２１６とを用いて、ユーザがＡ町に入るのに用いた入力経路を特定する（Ｓ２８０４）。以下、入力経路を特定する方法を説明する。

まず、対象地域に接続されている各メッシュ経路を経路メッシュデータ２１６から特定し、特定した各メッシュ経路を候補経路とする。入力シーケンスと各候補経路との距離を評価する評価値を計算し、最も評価が高い候補経路を、入力経路とする。以下、評価値を計算する例を、図２９を用いて説明する。

図２９に、入力シーケンスＳと、候補経路ＣＲとが一例として示されている。入力シーケンスＳ上にはユーザが移動したｋ個のメッシュの位置（メッシュ位置）ＰＤが示されている。候補経路ＣＲ上には、候補経路ＣＲに含まれるｎ個のメッシュ位置ＰＲが示されている。メッシュ位置は、例えばメッシュの中心であるが、これに限定されるものではない。図示の例では、説明の簡単ため、入力シーケンスＳ上の各メッシュ位置は、候補経路ＣＲ上のメッシュ位置のいずれとも一致しないように描かれているが、入力シーケンスＳのメッシュ位置の全部または一部が、候補経路ＣＲ上のメッシュ位置と一致している場合もあり得る。

入力シーケンスＳと候補経路ＣＲとの距離の評価値Ｅは、例えば、以下の式により算出する。

ＰＤ_ｉは、入力シーケンスＳ上のｉ番目のメッシュ位置である。ＰＲ_ｊは候補経路ＣＲ上のｊ番目のメッシュ位置である。式２により、入力シーケンスＳ上にあるｋ個のメッシュ位置ＰＤ_ｉ（ｉ＝１，２，・・・ｋ）の各々に関して、候補経路ＣＲ上のｎ個のメッシュ位置との距離の二乗を計算し、計算した値をｎで除算することにより、メッシュ位置ＰＤ_ｉと候補経路ＣＲとの距離ｄｉ（ｉ＝１，２，・・・ｋ）を求める。図示の例では、位置ＰＤ_ｋ−５（ｉ＝ｋ−５の場合）について、候補経路ＣＲ上のｎ個のメッシュ位置（ＰＲ_１〜ＰＲ_ｎ）との距離（図の一点鎖線を参照）の二乗を計算し、ｎで除算することにより、距離ｄ_ｋ−５を求める様子が示されている。式１により求めたｋ個の距離ｄ_ｉ（ｉ＝１，２，・・・ｋ）を合計し、ｋで除算することにより、評価値Ｅを得る。

図２７の例の場合、Ａ町に接続されている各メッシュ経路２７１１〜２７１４をそれぞれ候補経路ＣＲとし、入力シーケンスと各候補経路ＣＲとの距離の評価値Ｅを式１および式２により計算する。そして、メッシュ経路２７１１〜２７１４のうち、評価が最も高いメッシュ経路を、入力経路として決定する。この例では、評価値Ｅの値が最も小さいメッシュ経路が、入力シーケンスとの距離が最も小さいため、最も評価が高いメッシュ経路となる。よって、評価値Ｅの値が最も小さいメッシュ経路を、入力経路として決定する。

ここでは入力シーケンスと候補経路との距離を式１で評価したが、別の手法で当該距離を評価してもかまわない。例えば、メッシュ位置のシーケンスを入力変数とし、これに最も近似する候補経路を出力変数とするニューラルネットワークを機械学習により構築する。構築したニューラルネットワークに、入力シーケンスを入力変数として入力し、ニューラルネットワークから出力された変数が示す候補経路を、入力経路としてもよい。

次に、ステップＳ２８０５において、対象ストリーム情報に基づき、ユーザが対象地域から出たかを調べる。ユーザが対象地域から出たかどうかは、例えば、ユーザが対象地域に入った後、対象地域と異なる地域（市区町村、メッシュ等）への移動があったかで判断する。ユーザが対象地域から出ていないと判断した場合は（ＮＯ）、ステップＳ２８０８に進む。

ユーザが対象地域から出ていると判断した場合は（ＹＥＳ）、ユーザが対象地域から出た後の一定時間内のシーケンスデータからユーザが利用したメッシュを特定する（Ｓ２８０６）。特定したメッシュを時系列に並べたシーケンスを、出力シーケンスと称する。例えば、ユーザがＡ町を出て、その後の一定時間内にメッシュＭ０７７７、メッシュＭ０７８５、Ｍ０７４４、Ｍ０７５８、Ｍ０７１１、Ｍ０７２５の順に移動したとする。この場合、出力シーケンスとして、（メッシュＭ０７７７、Ｍ０７８５、Ｍ０７４４、Ｍ０７５８、Ｍ０７１１、Ｍ０７２５）を特定する。なお、メッシュＭ０７７７は、Ａ町と、Ａ町から出てユーザが利用する経路の始点との境界を含んでいても良い。

出力シーケンスの別の求め方として、対象地域から出た直後の所定数のメッシュを時系列に並べたシーケンスを出力シーケンスとしてもよい。例えば、所定数が５であれば、Ａ町から出た後の５個のメッシュのシーケンスを出力シーケンスとする。

経路推定部２７０は、経路メッシュデータ２１６と、出力シーケンスとを用いて、ユーザがＡ町から出た後に用いた出力経路を特定する（同Ｓ２８０７）。特定の方法は、入力経路の場合と同様である。すなわち、まず、対象地域に接続されている各経路を候補経路とする。出力シーケンスと各候補経路との距離の評価値を計算し、最も評価値の値が小さい候補経路を、出力経路とする。評価値の計算方法は、入力経路の場合と同様である。

経路推定部２７０は、ユーザＩＤと、対象地域と、特定した入力経路と、特定した出力経路との情報を含む経路推定情報２１７を生成する（Ｓ２８０８）。なお、出力経路の情報は、ステップＳ２８０７で出力経路を特定した場合のみ含める。経路推定情報２１７には、対象地域に滞在した期間、対象地域に入った時刻（到着時刻）、対象時刻から出た時刻（出発時刻）など、他の情報を含めてもよい。複数のユーザについて生成された経路推定情報２１７の一例を図３０に示す。複数人のユーザの経路推定情報がデータベースに格納されている。

このような複数人分の経路推定情報２１７を統計分析することで、対象地域の出入りに利用される入力経路および出力経路の傾向を把握できる。この傾向を利用して、様々な対策を立てることができる。例えば、特定の入力経路または特定の出力経路の頻度が高く、渋滞が発生しがちな場合は、別の経路の利用も促す看板を立てることで、渋滞解消を図ることができる。また、利用頻度の高い入力経路に案内を多く出すことで、対象地域内でのユーザ消費を促すための効果的な宣伝を行うことができる。

以上、第２の実施形態によれば、ユーザが対象地域に入るのに用いた経路を高い精度で推定できる。また、ユーザが対象地域から出るのに用いた経路を高い精度で推定できる。

本実施形態では、候補経路をメッシュ経路としたが、候補経路はメッシュでない経路であってもよい。この場合、経路を例えば一定距離間隔ごとの位置（例えば経緯度）のシーケンスによって表すことで、本実施形態と同様の処理により、入力経路および出力経路を特定できる。

本発明は、上述した実施形態に限定されるものではなく、本発明の構成要素を種々に具体化できる。また、上記実施形態における各構成要素を適宜、拡張し、変更し、削除し、または組み合わせて、本発明を形成することも可能である。また、別の構成要素を新たに追加して、本発明を形成することも可能である。

以下に、本願明細書に開示された主題を付記する。

［項目１］
ユーザの位置情報と時刻情報とを含む移動履歴データに基づき、前記ユーザが生活圏外に位置している期間の少なくとも一部に含まれる前記位置情報と前記時刻情報とを旅程データとして特定する旅程判別部と、
前記旅程データに基づき、前記ユーザが前記生活圏外で宿泊したか否かを判定する宿泊判定部と、
を備えた情報処理装置。
旅程データを用いることで、ユーザが旅行中に宿泊したか否か（旅程に宿泊が含まれるか）を判定できる。すなわち、ユーザが日帰り旅行をしたのか、宿泊付きの旅行をしたのかを判別できる。

［項目２］
前記旅程データは、前記ユーザが前記生活圏外に出てから前記生活圏に戻るまでの前記位置情報および前記時刻情報を含むデータである
項目１に記載の情報処理装置。
移動体が生活圏を出てから生活圏に戻るまでの位置情報および時刻情報のデータを旅程データとすることで、１回の旅程（１回分の旅行）に着目した判断を行うことができる。

［項目３］
前記宿泊判定部は、前記旅程データの時間長に基づき、前記ユーザが前記生活圏外で宿泊したか否かを判定する
項目１または２に記載の情報処理装置。
旅程データの時間長を用いてユーザの宿泊有無を判断することで、精度の高い判断が可能となる。

［項目４］
前記宿泊判定部は、前記旅程データに基づき、前記ユーザが特定の時間帯に所定時間以上滞在した地域を検出し、検出した前記地域に前記ユーザが宿泊したことを決定する
項目１〜３のいずれか一項に記載の情報処理装置。
特定の時間帯に所定時間以上移動体が位置した地域にユーザが宿泊したことを決定することで、ユーザが宿泊した地域を高い精度で特定できる。

［項目５］
前記宿泊判定部は、前記旅程データに基づき１日の基準時刻を経過した回数をカウントし、カウントした前記回数に基づき、前記ユーザの宿泊日数を決定する
項目１〜４のいずれか一項に記載の情報処理装置。
１日の基準時刻を経過した回数に基づき、ユーザの宿泊日数を計算することで、ユーザの宿泊日数を高い精度で計算できる。

［項目６］
前記宿泊判定部は、前記旅程データの開始時刻が、前記旅程データの開始時刻より後に最初に到来する基準時刻と、前記基準時刻より一定時間前の第１時刻との間に含まれる場合は、カウントした前記回数から１を減算する
項目５に記載の情報処理装置。
例えば、基準時刻が早朝の時間帯に属し、ユーザが早朝出発して基準時刻をまたいだ場合をカウント対象から除外することで、ユーザの宿泊日数を高い精度で計算できる。

［項目７］
前記宿泊判定部は、前記旅程データに基づき、前記ユーザが特定の時間帯に所定時間以上滞在した地域を検出し、検出した前記地域のうちの１つが、前記ユーザの生活圏を包含する第１地域に一致するかを判断し、一致する場合は、カウントした前記回数から１を減算する
項目５または６に記載の情報処理装置。
例えば、ユーザが夜間出発し、ユーザの生活圏を包含する第１地域で所定時間以上滞在した場合に、当該第１地域内で宿泊したと誤判断されることを防止できる。

［項目８］
前記旅程データに基づき、前記ユーザが経由した地域と、前記ユーザが前記地域に滞在した滞在期間とを時系列に表した出力情報を生成する出力情報生成部
を備えた項目１〜７のいずれか一項に記載の情報処理装置。
ユーザがどのような旅程や経路で各地域を訪れたり、各地域にどのように過ごしたりするのかを分析できる。分析の結果を用いて、各地域の観光促進に役立てることができる。

［項目９］
前記出力情報生成部は、前記ユーザが前記生活圏を包含する第１地域の外に出た後、前記第１地域に戻ってきたことを検出した場合は、前記ユーザが前記生活圏に戻ってきたことを検出できなくても、前記ユーザが前記生活圏に戻ったことを示す情報を前記出力情報に追加する
項目８に記載の情報処理装置。
ユーザが第１地域まで戻ってきたときは、生活圏に戻ったとみなすことで、旅程データに一部の欠落があっても、ユーザが生活圏に戻るまでの移動工程を表した出力情報を生成できる。

［項目１０］
前記旅程データに基づき前記ユーザが第２地域に入ったことを検出した場合に、前記ユーザが前記第２地域に入る際に経由した前記位置情報のシーケンスを特定し、前記位置情報のシーケンスと、前記第２地域に接続されている複数の経路との距離を計算し、計算した前記距離に基づき、前記ユーザが前記第２地域に入るのに使用した経路を前記複数の経路から選択する、経路推定部
を備えた項目１〜９のいずれか一項に記載の情報処理装置。
ユーザが第２地域に入るのに用いた経路を高い精度で推定できる。

［項目１１］
前記旅程データに基づき前記ユーザが第２地域から出たことを検出した場合に、前記ユーザが前記第２地域から出た後に経由した前記位置情報のシーケンスを特定し、前記位置情報のシーケンスと、前記第２地域に接続されている複数の経路との距離を計算し、計算した前記距離に基づき、前記ユーザが前記第２地域から出るのに使用した経路を前記複数の経路から選択する、経路推定部
を備えた項目１〜１０のいずれか一項に記載の情報処理装置。
ユーザが第２地域から出るのに用いた経路を高い精度で推定できる。

［項目１２］
前記位置情報は、地図上の領域を分割した複数のメッシュのうち、前記ユーザが位置するメッシュの識別子である
項目１〜１１のいずれか一項に記載の情報処理装置。
位置情報がメッシュを示す場合も、ユーザが旅行中に宿泊したか否か（旅程に宿泊が含まれるか）を判定できる。

［項目１３］
ユーザの位置情報と時刻情報とを含む移動履歴データに基づき、前記ユーザが生活圏外に位置している期間の少なくとも一部に含まれる前記位置情報と前記時刻情報とを旅程データとして特定するステップと、
前記旅程データに基づき、前記ユーザが前記生活圏外で宿泊したか否かを判定するステップと、
をコンピュータが実行する情報処理方法。
旅程データを用いることで、ユーザが旅行中に宿泊したか否か（旅程に宿泊が含まれるか）を判定できる。すなわち、ユーザが日帰り旅行をしたのか、宿泊付きの旅行をしたのかを判別できる。

［項目１４］
ユーザの位置情報と時刻情報とを含む移動履歴データに基づき、前記ユーザが生活圏外に位置している期間の少なくとも一部に含まれる前記位置情報と前記時刻情報とを旅程データとして特定するステップと、
前記旅程データに基づき、前記ユーザが前記生活圏外で宿泊したか否かを判定するステップと、
をコンピュータに実行させるためのコンピュータプログラム。
旅程データを用いることで、ユーザが旅行中に宿泊したか否か（旅程に宿泊が含まれるか）を判定できる。すなわち、ユーザが日帰り旅行をしたのか、宿泊付きの旅行をしたのかを判別できる。

１００：情報処理装置
１０２：プロセッサ
１０４：メモリ
１０６：入出力インタフェース
１０８：通信インタフェース
１１０：ネットワーク
１２０：サーバ
１３０：基地局
１４０：ユーザ端末
１６０：アクセスポイント
２１０：データ記憶部
２１１：移動履歴データ
２１２：ユーザ属性データ
２１３：メッシュ属性データ
２１４：地図データ
２１５：出力情報
２１６：経路メッシュデータ
２１７：経路推定情報
２２０：前処理部
２３０：旅程判別部
２４０：宿泊判定部
２５０：出力情報生成部
２６０：データ取得部
２７０：経路推定部
４０１，１００１、２００１：自宅
１００２、１００４、１００６、２００４：経路
２７１１〜２７１４：メッシュ経路
１００３、１００５、２００３、２００７：地点
２５０１〜２５０６、２５０８、２５０９：宿泊施設
２５０７：往復移動
２５１１：アクセスポイント
Ｓ：入力シーケンス
ＣＲ：候補経路

Claims (14)

1. ユーザの位置情報と時刻情報とを含む移動履歴データに基づき、前記ユーザが生活圏外に位置する期間の少なくとも一部に含まれる前記位置情報と前記時刻情報とを旅程データとして特定する旅程判別部と、
   前記旅程データに基づき、前記ユーザが前記生活圏外で宿泊したか否かを判定する宿泊判定部と、
   を備えた情報処理装置。
2. 前記旅程データは、前記ユーザが前記生活圏外に出てから前記生活圏に戻るまでの前記位置情報および前記時刻情報を含むデータである
   請求項１に記載の情報処理装置。
3. 前記宿泊判定部は、前記旅程データの時間長に基づき、前記ユーザが前記生活圏外で宿泊したか否かを判定する
   請求項１または２に記載の情報処理装置。
4. 前記宿泊判定部は、前記旅程データに基づき、前記ユーザが特定の時間帯に所定時間以上滞在した地域を検出し、検出した前記地域に前記ユーザが宿泊したことを決定する
   請求項１〜３のいずれか一項に記載の情報処理装置。
5. 前記宿泊判定部は、前記旅程データに基づき１日の基準時刻を経過した回数をカウントし、カウントした前記回数に基づき、前記ユーザの宿泊日数を決定する
   請求項１〜４のいずれか一項に記載の情報処理装置。
6. 前記宿泊判定部は、前記旅程データの開始時刻が、前記旅程データの開始時刻より後に最初に到来する基準時刻と、前記基準時刻より一定時間前の第１時刻との間に含まれる場合は、カウントした前記回数から１を減算する
   請求項５に記載の情報処理装置。
7. 前記宿泊判定部は、前記旅程データに基づき、前記ユーザが特定の時間帯に所定時間以上滞在した地域を検出し、検出した前記地域のうちの１つが、前記ユーザの生活圏を包含する第１地域に一致するかを判断し、一致する場合は、カウントした前記回数から１を減算する
   請求項５または６に記載の情報処理装置。
8. 前記旅程データに基づき、前記ユーザが経由した地域と、前記ユーザが前記地域に滞在した滞在期間とを時系列に表した出力情報を生成する出力情報生成部
   を備えた請求項１〜７のいずれか一項に記載の情報処理装置。
9. 前記出力情報生成部は、前記ユーザが前記生活圏を包含する第１地域の外に出た後、前記第１地域に戻ってきたことを検出した場合は、前記ユーザが前記生活圏に戻ってきたことを検出できなくても、前記ユーザが前記生活圏に戻ったことを示す情報を前記出力情報に追加する
   請求項８に記載の情報処理装置。
10. 前記旅程データに基づき前記ユーザが第２地域に入ったことを検出した場合に、前記ユーザが前記第２地域に入る際に経由した前記位置情報のシーケンスを特定し、前記位置情報のシーケンスと、前記第２地域に接続されている複数の経路との距離を計算し、計算した前記距離に基づき、前記ユーザが前記第２地域に入るのに使用した経路を前記複数の経路から選択する、経路推定部
    を備えた請求項１〜９のいずれか一項に記載の情報処理装置。
11. 前記旅程データに基づき前記ユーザが第２地域から出たことを検出した場合に、前記ユーザが前記第２地域から出た後に経由した前記位置情報のシーケンスを特定し、前記位置情報のシーケンスと、前記第２地域に接続されている複数の経路との距離を計算し、計算した前記距離に基づき、前記ユーザが前記第２地域から出るのに使用した経路を前記複数の経路から選択する、経路推定部
    を備えた請求項１〜１０のいずれか一項に記載の情報処理装置。
12. 前記位置情報は、地図上の領域を分割した複数のメッシュのうち、前記ユーザが位置するメッシュの識別子である
    請求項１〜１１のいずれか一項に記載の情報処理装置。
13. ユーザの位置情報と時刻情報とを含む移動履歴データに基づき、前記ユーザが生活圏外に位置している期間の少なくとも一部に含まれる前記位置情報と前記時刻情報とを旅程データとして特定するステップと、
    前記旅程データに基づき、前記ユーザが前記生活圏外で宿泊したか否かを判定するステップと、
    をコンピュータが実行する情報処理方法。
14. ユーザの位置情報と時刻情報とを含む移動履歴データに基づき、前記ユーザが生活圏外に位置している期間の少なくとも一部に含まれる前記位置情報と前記時刻情報とを旅程データとして特定するステップと、
    前記旅程データに基づき、前記ユーザが前記生活圏外で宿泊したか否かを判定するステップと、
    をコンピュータに実行させるためのコンピュータプログラム。

Images