JP2017091045A - 日帰り判定システム - Google Patents

Abstract

【課題】 より早いタイミングでユーザが日帰りするか否かを判定する。【解決手段】 サーバ１０は、ユーザが日帰りするか否かを判定する日帰り判定システムである。サーバ１０は、ユーザの位置を示す位置情報を取得する位置情報取得部１２と、ユーザによってアクセスされた情報を示すアクセス情報を取得するアクセス情報取得部１３と、アクセス情報に係る位置を特定し、当該位置から交通機関の位置までの距離を算出する距離算出部１４と、取得された位置情報、及び算出された距離に基づいて、ユーザが判定対象日に帰宅するか否かを判定する判定部１５とを備える。【選択図】 図１

Description

本発明は、ユーザが判定対象日に帰宅するか否か、即ち、ユーザが日帰りするか否かを判定する日帰り判定システムに関する。

従来から、ユーザの位置に基づき、ユーザが帰宅中であるか否かを判断し、帰宅中と判断された場合には帰宅時間を予測することが提案されている（例えば、特許文献１参照）。

特開２００２−２６７４８７号公報

ところで、ユーザの自宅付近の情報を提供するシステムがある。ユーザがこの情報提供を受けることで、例えば、自宅付近でいつも利用している電車が止まっている情報が事前に得られた場合、違う路線を利用する等、帰りのプランを事前に立てることができる。しかし、出張や旅行でユーザが自宅から離れた非日常圏に移動して宿泊する場合には、上記のような情報は不要である。一方で、非日常圏に滞在していても日帰りする場合には、上記の情報は必要となる。そのため、上記の情報の提供は、ユーザが日帰りするか否かを判定して、その判定結果に応じて行うことが望ましい。

その判定を特許文献１に記載された技術を用いて行うことが考えられる。しかしながら、特許文献１の技術では、ユーザが実際に帰宅をしていなければ、ユーザが帰宅するか否かを判定することができない。そのため、判定が可能となるタイミングが遅くなってしまうという問題がある。

本発明は、上記に鑑みてなされたものであり、より早いタイミングでユーザが日帰りするか否かを判定することができる日帰り判定システムを提供することを目的とする。

上記目的を達成するために、本発明に係る日帰り判定システムは、ユーザの位置を示す位置情報を取得する位置情報取得手段と、ユーザによってアクセスされた情報を示すアクセス情報を取得するアクセス情報取得手段と、アクセス情報取得手段によって取得されたアクセス情報に係る位置を特定し、当該位置から交通機関の位置までの距離を算出する距離算出手段と、位置情報取得手段によって取得された位置情報、及び距離算出手段によって算出された距離に基づいて、ユーザが判定対象日に帰宅するか否かを判定する判定手段と、を備える。

本発明に係る日帰り判定システムでは、アクセス情報に係る位置から交通機関の位置までの距離が考慮されて、ユーザが日帰りするか否かが判定される。これにより、本発明に係る日帰り判定システムによれば、アクセス情報に係る位置（例えば、レストランの位置）に行くと共に交通機関を利用するという行動をユーザの推定される行動とすることで、より早いタイミングで判定を行うことができる。

判定手段は、アクセス情報に係る位置に応じて予め設定された当該位置でのユーザの推定滞在時間にも基づいて判定することとしてもよい。この構成によれば、アクセス情報に係る位置でのユーザの推定滞在時間が更に考慮されることで、精度の高い判定を行うことができる。

アクセス情報取得手段は、ユーザが情報にアクセスした時刻を示すアクセス時刻情報も取得し、判定手段は、アクセス情報取得手段によって取得されたアクセス時刻情報にも基づいて判定する、こととしてもよい。この構成によれば、アクセス時刻情報が更に考慮されることで、精度の高い判定を行うことができる。

距離算出手段は、位置情報取得手段によって取得された位置情報に基づいて、距離の算出対象となる交通機関の位置を特定することとしてもよい。この構成によれば、ユーザの位置に基づき、判定に用いる交通機関の位置を特定することができ、その結果、適切な判定を行うことができる。

アクセス情報取得手段は、ユーザが検索に用いたキーワードも取得し、判定手段は、アクセス情報取得手段によって取得されたキーワードにも基づいて判定する、こととしてもよい。また、判定手段は、アクセス情報取得手段によって取得されたアクセス情報によって示されるアクセスが特定のアクセス先へのものか否かにも基づいて判定することとしてもよい。また、位置情報取得手段は、位置情報によって示される位置にユーザがいた時刻を示す位置時刻情報も取得し、判定手段は、位置情報取得手段によって取得された位置情報に基づいてユーザの自宅からの距離を算出し、算出した距離及び位置情報取得手段によって取得された位置時刻情報にも基づいて判定する、こととしてもよい。これらの構成によれば、より精度の高い判定を行うことができる。

日帰り判定システムは、判定手段による判定に応じて、メッセージを出力するメッセージ出力手段を更に備えることとしてもよい。この構成によれば、判定に応じた適切なメッセージを出力することができる。

本発明では、アクセス情報に係る位置から交通機関の位置までの距離が考慮されて、ユーザが日帰りするか否かが判定される。これにより、本発明によれば、アクセス情報に係る位置（例えば、レストランの位置）に行くと共に交通機関を利用するという行動をユーザの推定される行動とすることで、より早いタイミングで判定を行うことができる。

本発明の実施形態に係る日帰り判定システムであるサーバの構成を示す図である。 位置情報テーブルを示す図である。 検索ログテーブルを示す図である。 アプリ利用情報テーブルを示す図である。 交通機関情報テーブルを示す図である。 交通機関Ｗｅｂサイト情報テーブルを示す図である。 拠点情報テーブルを示す図である。 本発明の実施形態に係る日帰り判定システムであるサーバのハードウェア構成を示す図である。 本発明の実施形態に係る日帰り判定システムであるサーバで実行される処理を示すフローチャートである。

以下、図面と共に本発明に係る日帰り判定システムの実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。

図１に本実施形態に係る日帰り判定システムであるサーバ１０を示す。サーバ１０は、ユーザ端末２０に対してメッセージ（コンテンツ）を送信する装置である。ユーザ端末２０に対して送信されるメッセージは、例えば、ユーザ端末２０で表示されてユーザに利用されるものである。メッセージは、ユーザにとって有用な情報であり、例えば、電車の遅延の情報である。

送信されるメッセージには、日常圏で必要なもの、非日常圏で必要なもの、及び日常圏でも非日常圏でも必要なものの何れかが設定されている。送信されるメッセージには、例えば、それらの何れかであることを示すフラグが付与されている。日常圏は、ユーザが日常的に活動を行う領域であり、通常、ユーザの自宅の位置を含む。非日常圏は、日常圏以外の領域である。ユーザが日常圏に位置している場合には、サーバ１０は、当該ユーザによって所持されるユーザ端末２０に対して、日常圏で必要なメッセージ、及び日常圏でも非日常圏でも必要なメッセージを送信する。

ユーザが非日常圏に位置している場合には、サーバ１０は、ユーザがその日に自宅に帰宅するか否かを判定する。サーバ１０は、ユーザがその日に自宅に帰宅しないと判定した場合には、日常圏で必要なメッセージ以外の非日常圏で必要なメッセージ、及び日常圏でも非日常圏でも必要なメッセージを送信する。サーバ１０は、ユーザがその日に自宅に帰宅すると判定した場合には、日常圏で必要なメッセージを含む全てのメッセージを送信する。このようにサーバ１０は、ユーザが、判定対象日であるメッセージの送信日に自宅に帰宅するか否かの日帰り判定を行う。これにより、ユーザ端末２０毎に（ユーザ毎に）、ユーザの状況に合致したメッセージの送信を行うことができる。

ユーザ端末２０は、ユーザによって携帯されて用いられる装置である。ユーザ端末２０は、具体的には、携帯電話機やスマートフォン等に相当する。ユーザ端末２０は、移動体通信網等のネットワークＮに接続して無線通信を行う機能を有している。ユーザ端末２０とサーバ１０とは、ネットワークＮを介して通信を行うことができ、互いに情報の送受信を行えるようになっている。ユーザ端末２０は、サーバ１０から送信されるメッセージを受信し、メッセージを利用する（例えば、表示する）機能を有している。

ユーザ端末２０は、ＧＰＳ（グローバル・ポジショニング・システム）測位機能等の自端末の測位機能を有している。ユーザ端末２０は、測位機能によって得られた自端末の位置である測位点を示す情報を、ユーザの位置を示す位置情報としてサーバ１０に送信する。位置情報は、例えば、緯度及び経度を示す情報である。ユーザ端末２０を所有するユーザには、予めユーザを特定する情報であるユーザＩＤが付与されており、ユーザ端末２０は、予め記憶した当該ユーザＩＤと共に位置情報をサーバ１０に送信する。ユーザ端末２０による自端末の測位は、継続的に行われ、例えば、定期的（例えば、５分毎）に行われる。ユーザ端末２０からサーバ１０に送信される位置情報は、サーバ１０側でいつ測位された位置に係る位置情報か把握されるようにしておく。例えば、ユーザ端末２０は、位置情報に測位時刻を対応付けてサーバ１０に送信する。あるいは、ユーザ端末２０は、測位する度に位置情報をサーバ１０に送信する。

ユーザ端末２０は、様々な情報にアクセスする機能を有している。ユーザ端末２０は、ユーザの操作により、ネットワークＮを介してＷｅｂサイトにアクセスして、Ｗｅｂサイトから情報を取得する。Ｗｅｂサイトへのアクセスでは、例えば、まず、検索エンジンによってＷｅｂサイトの検索を行う検索サイトにアクセスして、検索によりヒットしたＷｅｂサイトにアクセスする（検索結果に示される当該Ｗｅｂサイトをクリックする）。なお、検索エンジンは、サーバ１０の管理者である事業者によって提供されたものであってもよい。Ｗｅｂサイトの検索が行われる際には、検索に用いられるキーワード（検索ワード）であるクエリが、ユーザの入力操作によりユーザ端末２０に入力される。ユーザ端末２０は、このようなＷｅｂサイトへのアクセスに係る情報を、ユーザによってアクセスされた情報を示すアクセス情報としてサーバ１０に送信する。

ユーザ端末２０は、アクセス情報として、例えば、ユーザＩＤ、クエリ、タイトル、ＵＲＬ（Uniform Resource Locator）、スニペット及び検索時刻が対応付けられた情報を生成する。クエリは、上述したように検索に用いられるキーワードである。タイトル、ＵＲＬ、スニペットは、検索によりヒットし、アクセスされたＷｅｂサイトに係るものである。

検索サイトにおいて表示される検索結果には、タイトル及びスニペットが含まれている。タイトル及びスニペットは、検索サイトにおいて、検索結果のＷｅｂサイトから作成されている。例えば、Ｗｅｂサイトをクローリングして、当該Ｗｅｂサイトを構成するＨＴＭＬ（HyperText Markup Language）文書の＜ｔｉｔｌｅ＞といったタイトルタグの部分をタイトルとして、＜ｂｏｄｙ＞といったボディタグの部分の初めの十数文字をスニペットとして保持する。検索結果が表示される時点ではクローリングは完了しており、ＵＲＬ、タイトル及びスニペットは検索サイトのデータベースに保存されている。ユーザ端末２０は、タイトル及びスニペットが表示される（スニペットが利用できる）検索サイトにアクセスすることで、タイトル及びスニペットを取得する。検索時刻は、当該検索が行われた時刻である。

なお、検索のみを行って、検索によりヒットしたＷｅｂサイトへのアクセスが行われなかった場合には、ユーザ端末２０は、アクセス情報に、タイトル、ＵＲＬ及びスニペットを含めない。ユーザ端末２０は、例えば、一定時間毎、あるいは検索を行ってＷｅｂサイトにアクセスする度に、上記のようなＷｅｂサイトに係るアクセス情報をサーバ１０に送信する。この場合、例えば、検索から一定時間以内のＷｅｂサイトへのアクセスがされなかった場合には、アクセスされたＷｅｂサイトはないもの（アクセス情報に、タイトル、ＵＲＬ及びスニペットを含めないことと）としてもよい。

また、ユーザ端末２０は、情報へのアクセスの一形態として、ユーザの操作により、ユーザ端末２０に格納されているアプリケーションを起動する（ユーザに利用可能な状態にする）。例えば、交通機関に関する情報を取得するアプリケーション等が起動される。ユーザ端末２０は、アプリケーションを起動すると、アプリケーションに係るアクセス情報として、例えば、ユーザＩＤ、アプリＩＤ及び利用時刻が対応付けられた情報を生成する。アプリＩＤは、起動されたアプリケーションを特定する情報である。利用時刻は、当該アプリケーションが利用された（起動された）時刻である。ユーザ端末２０は、例えば、一定時間毎、あるいはアプリケーションの起動を行う度に、上記のようなアプリケーションに係るアクセス情報をサーバ１０に送信する。

ユーザ端末２０は、通常の携帯電話機やスマートフォン等と同様にＣＰＵ（Central Processing Unit）、メモリ及び無線通信モジュール等のハードウェアを備えて構成される。

引き続いて、本実施形態に係るサーバ１０の機能を説明する。図１に示すようにサーバ１０は、記憶部１１と、位置情報取得部１２と、アクセス情報取得部１３と、距離算出部１４と、判定部１５と、メッセージ送信部１６とを備えて構成される。

記憶部１１は、サーバ１０における処理に必要となる情報を記憶する記憶手段である。具体的に、記憶部１１が、どのような情報を記憶するについては後述する。

位置情報取得部１２は、ユーザの位置を示す位置情報を取得する位置情報取得手段である。位置情報取得部１２は、位置情報によって示される位置にユーザがいた時刻を示す位置時刻情報も取得する。位置情報取得部１２は、ユーザ端末２０から送信される情報を受信して位置情報及び当該位置情報に対応する位置時刻情報を取得する。なお、１つの位置情報は、１つの位置に係るものであるとする。

位置情報取得部１２は、取得した位置情報及び当該位置情報に対応する位置時刻情報を記憶部１１の位置情報テーブルに格納する。図２に位置情報テーブルを示す。図２に示すように位置情報テーブルは、ユーザＩＤ、経度、緯度及び位置取得時刻（位置時刻情報）が対応付けられた情報を格納する。位置情報テーブルの各レコード（１つの行のデータ）が、１つの位置情報及び当該位置情報に対応する位置時刻情報に対応する。

ユーザＩＤは、位置情報に係るユーザＩＤ（位置情報と共に送信されるユーザＩＤ）である。経度及び緯度は、位置情報により示される測位点の緯度及び経度である。位置取得時刻は、位置情報により示される測位点が測位された時刻（日時）である。位置情報テーブルに格納される各情報は、位置情報取得部１２によってユーザ端末２０から受信された情報である。なお、ユーザ端末２０が、測位する度に位置情報をサーバ１０に送信する場合には、位置情報取得部１２が受信した時刻を位置取得時刻としてもよい。

アクセス情報取得部１３は、ユーザによってアクセスされた情報を示すアクセス情報を取得するアクセス情報取得手段である。アクセス情報取得部１３は、ユーザが情報にアクセスした時刻を示すアクセス時刻情報も取得する。アクセス情報取得部１３は、ユーザが検索に用いたキーワードも取得する。

アクセス情報取得部１３は、ユーザ端末２０から送信される情報を受信してアクセス情報、当該アクセス情報に対応するアクセス時刻情報及びキーワードを取得する。なお、１つのアクセス情報は、１つの（１回の）情報へのアクセスに係るものであるとする。上述したように、ユーザ端末２０から送信されるアクセス情報には、Ｗｅｂサイトに係るアクセス情報と、アプリケーションに係るアクセス情報とがある。また、Ｗｅｂサイトに係るアクセス情報には、ユーザが検索に用いたキーワードであるクエリが含まれている。

アクセス情報取得部１３は、取得したＷｅｂサイトに係るアクセス情報及び当該アクセス情報に対応するアクセス時刻情報を記憶部１１の検索ログテーブルに格納する。図３に検索ログテーブルを示す。図３に示すように検索ログテーブルは、ユーザＩＤ、クエリ、タイトル、ＵＲＬ、スニペット及び検索時刻（アクセス時刻情報）が対応付けられた情報を格納する。検索ログテーブルの各レコード（１つの行のデータ）が、１つのアクセス情報及び当該アクセス情報に対応するアクセス時刻情報（１つの検索ログ）に対応する。

ユーザＩＤは、アクセス情報に係るユーザＩＤ（アクセス情報と共に送信されるユーザＩＤ）である。クエリは、アクセス情報に係るＷｅｂサイトにアクセスする際の検索に用いられたキーワードである。タイトル、ＵＲＬ及びスニペットは、アクセスされたＷｅｂサイトに係るものである。検索時刻は、当該検索が行われた時刻である。検索ログテーブルに格納される各情報は、アクセス情報取得部１３によってユーザ端末２０から受信された情報である。なお、ユーザ端末２０が、検索を行ってＷｅｂサイトにアクセスする度にアクセス情報をサーバ１０に送信する場合には、アクセス情報取得部１３が受信した時刻を検索時刻としてもよい。

アクセス情報取得部１３は、取得したアプリケーションに係るアクセス情報及び当該アクセス情報に対応するアクセス時刻情報を記憶部１１のアプリ利用情報テーブルに格納する。図４にアプリ利用情報テーブルを示す。図４示すようにアプリ利用情報テーブルは、ユーザＩＤ、アプリＩＤ及び利用時刻（アクセス時刻情報）が対応付けられた情報を格納する。アプリ利用情報テーブルの各レコード（１つの行のデータ）が、１つのアクセス情報及び当該アクセス情報に対応するアクセス時刻情報に対応する。

ユーザＩＤは、アクセス情報に係るユーザＩＤ（アクセス情報と共に送信されるユーザＩＤ）である。アプリＩＤは、アクセス情報に係るアプリケーションのアプリＩＤである。利用時刻は、アクセス情報に係るアプリケーションが利用された時刻である。アプリ利用情報テーブルに格納される各情報は、アクセス情報取得部１３によってユーザ端末２０から受信された情報である。なお、ユーザ端末２０が、アプリケーションの起動を行う度にアクセス情報をサーバ１０に送信する場合には、アクセス情報取得部１３が受信した時刻を利用時刻としてもよい。

距離算出部１４は、アクセス情報取得部１３によって取得されたアクセス情報に係る位置を特定し、当該位置から交通機関の位置までの距離を算出する距離算出手段である。距離算出部１４は、位置情報取得部１２によって取得された位置情報に基づいて、距離の算出対象となる交通機関の位置を特定する。距離算出部１４によって算出される距離は、日帰り判定に用いられるものである。

判定部１５は、位置情報取得部１２によって取得された位置情報、及び距離算出部１４によって算出された距離に基づいて、ユーザが判定対象日に帰宅するか否かを判定する、即ち、日帰り判定を行う判定手段である。ここで判定対象日は、例えば、判定する当日である。判定部１５は、位置情報取得部１２によって取得された位置情報に基づいてユーザの自宅からの距離を算出し、算出した距離及び位置情報取得部１２によって取得された位置時刻情報にも基づいて日帰り判定を行う。判定部１５は、アクセス情報取得部１３によって取得されたアクセス時刻情報にも基づいて日帰り判定を行う。判定部１５は、位置情報取得部１２によって取得されたキーワードにも基づいて日帰り判定を行う。判定部１５は、アクセス情報取得部１３によって取得されたアクセス情報によって示されるアクセスが特定のアクセス先へのものか否かにも基づいて日帰り判定を行う。以下、距離算出部１４及び判定部１５の機能について、具体的に説明する。

判定部１５は、ユーザが日常圏に位置しているか、あるいは、非日常圏に位置しているかの判定であるに日常圏／非日常圏判定を行う。判定部１５は、記憶部１１の図２に示す位置情報テーブルから、日常圏／非日常圏判定の判定対象のユーザの位置情報を取得する。判定部１５は、例えば、判定対象日の全ての位置情報を日常圏／非日常圏判定の判定対象とする。

一方、判定部１５は、例えば、判定時点の前日から予め設定された期間である過去Ｎ日分の、当該ユーザについての位置情報を位置情報テーブルから取得する。判定部１５は、取得した位置情報から、２次元カーネル密度推定又は混合ガウス分布等によって位置に応じた確率密度関数を算出する。この確率密度関数は、位置毎にユーザが日常的に位置している確率を算出するためのものである。確率密度関数の算出は、予め行っておいてもよい。

判定部１５は、確率密度関数を用いて、日常圏／非日常圏判定の判定対象のユーザの位置情報によって示される位置の確率密度を算出する。判定部１５は、算出した確率密度が非日常圏である条件に合致するか否かを判定し、当該条件に合致していたら、ユーザが非日常圏に位置していると判定する。例えば、判定部１５は、算出した確率密度が０であったら（あるいは当該確率密度が予め設定した閾値以下であったら）、ユーザが非日常圏に位置していると判定し、それ以外の場合、ユーザが日常圏に位置していると判定する。

また、判定部１５は、以下の方法で日常圏／非日常圏判定を行ってもよい。例えば、過去Ｎ日分の当該ユーザについての位置情報によって示される各位置と、判定対象の位置情報によって示される位置との距離を算出する。算出した距離と、予め設定した閾値（例えば、５０ｋｍ）とを比較して、全ての距離が閾値以上であったら、ユーザが非日常圏に位置していると判定し、それ以外の場合、ユーザが日常圏に位置していると判定する。また、判定部１５は、上記以外の任意の方法で日常圏／非日常圏判定を行ってもよい。

判定部１５は、少なくとも一つの位置情報に基づき、ユーザが非日常圏に位置していると判定した場合、当該ユーザについての日帰り判定を行う。判定部１５は、それ以外の場合、日帰り判定を行わない。即ち、日常圏に位置している場合、判定を行うまでもなく、ユーザは日帰りするものとされる。あるいは、判定部１５は、判定時点で最新（位置取得時刻が最も新しい）の位置情報に基づき、ユーザが非日常圏に位置していると判定した場合のみ、日帰り判定を行うこととしてもよい。

ここで、本実施形態における日帰り判定について説明する。本実施形態における日帰り判定では、ユーザが帰宅しやすい状態、状況にあるかの度合いを示す帰宅しやすさ度を算出する。まず、ユーザ端末２０から送信されて記憶部１１に記憶されている情報に基づいて、４つの観点からの帰宅しやすさ度ｘ１〜ｘ４を算出する。続いて、以下のように、各帰宅しやすさ度をそれぞれの帰宅しやすさ度ｘ１〜ｘ４に応じた重みｗ１〜ｗ４で重み付けして足し合わせて、総合の帰宅しやすさ度を算出する。

帰宅しやすさ度＝ｗ１ｘ１＋ｗ２ｘ２＋ｗ３ｘ３＋ｗ４ｘ４
そして、総合の帰宅しやすさ度に基づいて、ユーザが、判定対象日に自宅に帰宅するか否かを判定する。なお、帰宅しやすさ度は、値が大きいほど、ユーザがより帰宅しやすい状態、状況にあることを示している。

以下、帰宅しやすさ度ｘ１〜ｘ４毎にサーバ１０の機能（距離算出部１４及び判定部１５の機能）を説明する。まず、帰宅しやすさ度ｘ１（食事の場所の検索結果の利用）の算出について説明する。食事をとる場所（例えば、晩御飯を食べる場所）が、帰宅時に使用する交通機関（例えば、新幹線の駅又は空港）の近くであれば、食事をしてすぐに帰宅する予定を立てている可能性が高いと考えられる。そのため、食事をとる場所を検索した際に、帰宅時に使用する交通機関を示す単語が検索に用いられるキーワードに入っていれば帰宅する可能性が高いとする。

判定部１５は、記憶部１１の図２に示す位置情報テーブルから、日帰り判定の判定対象のユーザの位置情報を取得する。この位置情報は、例えば、判定時点で最新（位置取得時刻が最も新しい）のものである。なお、日常圏／非日常圏判定の際に上記の位置情報を取得していたら、再度、取得する必要はない（以下、同様）。

記憶部１１は、帰宅しやすさ度の算出に用いられる、交通機関（例えば、新幹線の駅又は空港）の名称と当該交通機関の位置とが対応付けられた情報を交通機関情報テーブルで保持する。図５に交通機関情報テーブルを示す。図５に示すように交通機関情報テーブルは、ＩＤ、名称、緯度及び経度が対応付けられた情報を格納する。交通機関情報テーブルの各レコード（１つの行のデータ）が、１つの交通機関の情報に対応する。

ＩＤは、１つの交通機関の情報に相当する交通機関情報テーブルの各データを一意に特定するための情報である。名称は、交通機関の名称である。緯度及び経度は、交通機関の位置の緯度及び経度である。図５に示す交通機関情報テーブルに格納される情報は、予め、サーバ１０の管理者等によってサーバ１０に入力されている。

判定部１５は、判定対象のユーザの位置情報によって示される位置と、交通機関情報テーブルの各交通機関の情報によって示される位置とを参照し、ユーザの位置から最も近い交通機関を特定し、その名称を取得する。続いて、判定部１５は、図３に示す検索ログテーブルの当該ユーザのレコードを参照し、クエリに取得した交通機関の名称を含むレコードを抽出する。抽出する（参照する）レコードの範囲は、判定対象日である判定の当日、又は当該当日を含む予め設定された期間である直近数日である。判定部１５は、抽出したレコードのうち、クエリに更に「レストラン」という単語が含まれているものを抽出する。なお、当該単語は、「レストラン」というものに限られず、ユーザが食事を行うことが推定されるものであればよい。判定部１５は、上記の結果、抽出されるレコードが存在していれば（最寄りの交通機関の名称と「レストラン」という単語とで検索している結果があれば）ｘ１を１とし、抽出されるレコードが存在していなければ（最寄りの交通機関の名称と「レストラン」という単語とで検索している結果がなければ）ｘ１を０とする。

なお、ｘ１の値は、ユーザの位置（最新の位置情報によって示される位置）に応じて変わりえる。即ち、ユーザが、その名称を検索のキーワードとした交通機関の近傍に位置していた場合に、ユーザが帰宅しやすいと判定する。

続いて、帰宅しやすさ度ｘ２（アクセス情報から推定した食事の場所候補の位置情報の利用）の算出について説明する。帰宅しやすさ度ｘ１についてと同様に、食事をとる場所が、帰宅時に使用する交通機関の近くであれば、食事をしてすぐに帰宅する予定を立てている可能性が高いと考えられる。そこで、検索してアクセスした情報に基づき、アクセス先に係る施設（例えば、レストラン）が食事をとる場所であると仮定する。そして、アクセスした情報に係る施設の位置と、帰宅時に使用すると考えられる交通機関とが近いかどうかを上記の度合いの算出に利用する。また、検索時刻が早い（昼等）場合、昼食を調べている可能性もあり、遅い時刻（夜）に検索した場合の方が、晩御飯について調べていると考えられる。そこで、検索が行われた時刻も上記の度合いの算出に利用する。

この算出では、距離算出部１４が、記憶部１１の図２に示す位置情報テーブルから、日帰り判定の判定対象のユーザの位置情報を取得する。この位置情報は、帰宅しやすさ度ｘ１を算出した際と同様に、例えば、判定時点で最新（位置取得時刻が最も新しい）のものである。距離算出部１４は、判定対象のユーザの位置情報によって示される位置と、交通機関情報テーブルの各交通機関の情報によって示される位置とを参照し、ユーザの位置から最も近い交通機関を特定する。また、距離算出部１４は、判定対象のユーザの位置情報によって示される位置から、予め設定された範囲以内の地名を取得する。地名の取得は、例えば、位置と地名とが対応付けられて、予め、記憶部１１に記憶された情報が参照されて行われる。

続いて、距離算出部１４は、検索ログテーブルの当該ユーザのレコードを参照し、クエリに「レストラン」という単語、又は取得した地名の何れかを含むレコードを抽出する。抽出する（参照する）レコードの範囲は、判定対象日である判定の当日、又は当該当日を含む予め設定された期間である直近数日である。この際、上記の何れかではなく、「レストラン」という単語と、取得した地名との両方が含まれるレコードを抽出してもよい。

距離算出部１４は、抽出したレコードから、スニペットに位置（アクセス情報に係る位置）を示す記載を含むものを抽出する。位置を示す記載としては、例えば、住所、若しくは緯度及び経度の情報である。この位置は、Ｗｅｂサイトに係る施設（例えば、レストラン）の位置である。距離算出部１４は、上記の位置を示す記載から、当該位置の緯度及び経度を特定する。即ち、距離算出部１４は、アクセス情報に係る位置を特定する。例えば、位置を示す情報が住所であった場合、ジオコーティングによって緯度及び経度を特定する。なお、Ｗｅｂサイトからの緯度及び経度の特定は、上記以外の方法で行われてもよい。距離算出部１４は、ユーザの位置から最も近い交通機関の位置と、検索ログテーブルから抽出されたレコードから特定された位置との距離ｄ＿ｒｅｓｔａｕｒａｎｔを算出する。

上記のように、距離算出部１４は、ユーザによってアクセスされたアクセス情報に係る施設の位置から、交通機関の位置までの距離を算出する。この際の施設は、クエリでの限定等によって、予め設定された特定の施設（例えば、レストラン）に限定してもよい。また、この特定の施設の限定は、上記以外によって行われてもよい。この距離ｄ＿ｒｅｓｔａｕｒａｎｔが近い（値が小さい）ほど、帰宅しやすいとする。距離算出部１４は、算出した距離ｄ＿ｒｅｓｔａｕｒａｎｔ及び検索ログテーブルから抽出された、当該距離に対応するレコードを判定部１５に通知する。

判定部１５は、検索ログテーブルから抽出されて距離算出部１４から通知されたレコードの検索時刻ｔ＿ｓｅａｒｃｈを示す情報を取得する。検索時刻が古い（ＵＮＩＸ時間に変換した値が小さい）ほど、帰宅しやすいとする。判定部１５は、距離ｄ＿ｒｅｓｔａｕｒａｎｔの逆数と、検索時刻ｔ＿ｓｅａｒｃｈ（例えば、ＵＮＩＸ時間に変換した値）の逆数とを積算する、以下の式によりｘ２を算出する。
ｘ２＝（１／ｔ＿ｓｅａｒｃｈ）＊（１／ｄ＿ｒｅｓｔａｕｒａｎｔ）

検索ログテーブルから抽出されたレコードが複数ある場合には、それぞれのレコードについてｘ２の値を求めて、それらの値からｘ２を決定することとしてもよい。例えば、それぞれのレコードのｘ２の値の平均を取ることとしてもよい。あるいは、それらのレコードのうち、検索時刻が最も新しいものから求められたｘ２を用いることとしてもよい。また、それぞれのレコードのｘ２の値を、検索時刻が新しいものから順に大きな重みとなるよう重み付けして、足し合わせてものを用いることとしてもよい。

なお、ｘ２の値も、ｘ１と同様に、ユーザの位置（最新の位置情報によって示される位置）に応じて値が変わりえる。即ち、ユーザが、アクセスした情報に係る施設の位置の近くにある交通機関の近傍に位置していた場合に、ユーザが帰宅しやすいと判定する。

続いて、帰宅しやすさ度ｘ３（交通機関の検索結果の利用）の算出について説明する。帰宅する日が近いほど新幹線や飛行機のチケット予約や、予約したチケットの確認のために交通機関のＷｅｂサイトを訪問する（アクセスする）頻度、又はアプリケーションの利用頻度が高くなると考えられる。そのため、非日常圏を訪問してから交通機関のＷｅｂサイトへの訪問、又はアプリケーションの利用履歴があれば帰宅しやすいとする。

判定部１５は、日常圏／非日常圏判定で、非日常圏に位置していると判定した位置情報のうち、位置取得時刻が最も古いものを特定する。判定部１５は、図３に示す検索ログテーブルの当該ユーザのレコードを参照し、特定された最も古い位置取得時刻よりも新しい検索時刻を有するレコードを抽出する。また、判定部１５は、図４に示すアプリ利用情報テーブルの当該ユーザのレコードを参照し、特定された最も古い位置取得時刻よりも新しい利用時刻を有するレコードを抽出する。これは、ユーザが非日常圏に移動してからの上記のＷｅｂサイトへの訪問、及びアプリケーションの利用（自宅に帰るための利用）を判定に用いるためである。非日常圏に移動する前は、非日常圏に移動するためにこれらを利用することが考えられるからである。

記憶部１１は、帰宅しやすさ度の算出に用いられる、特定のアクセス先である交通機関のＷｅｂサイト（例えば、新幹線や飛行機のチケット予約をするためのＷｅｂサイト）を示す情報を交通機関Ｗｅｂサイト情報テーブルで保持する。図６に交通機関Ｗｅｂサイト情報テーブルを示す。図６に示すように交通機関Ｗｅｂサイト情報テーブルは、ＩＤ、タイトル及び名称が対応付けられた情報を格納する。交通機関Ｗｅｂサイト情報テーブルの各レコード（１つの行のデータ）が、１つの交通機関のＷｅｂサイトの情報に対応する。

ＩＤは、１つの交通機関のＷｅｂサイトの情報に相当する交通機関Ｗｅｂサイト情報テーブルの各データを一意に特定するための情報である。タイトルは、Ｗｅｂサイトのタイトルである。ＵＲＬは、ＷｅｂサイトのＵＲＬである。図６に示す交通機関Ｗｅｂサイト情報テーブルに格納される情報は、予め、サーバ１０の管理者等によってサーバ１０に入力されている。

判定部１５は、抽出した検索ログテーブルのレコードにタイトル又はＵＲＬが、交通機関Ｗｅｂサイト情報テーブルに記憶されているタイトル又はＵＲＬと一致しているか否かを判断する。判定部１５は、上記の結果、一致しているレコードが検索ログテーブルに存在していれば（交通機関Ｗｅｂサイト情報テーブル記憶される情報に示されるＷｅｂサイトにユーザがアクセスしていれば）ｘ３を１とし、一致しているレコードが検索ログテーブルに存在していなければ（当該Ｗｅｂサイトにユーザがアクセスしていなければ）ｘ３を０とする。なお、一致しているレコードは、帰宅しやすさ度ｘ２の算出に用いたものと異なっていてもよい（通常は異なる）。

また、判定部１５は、抽出したアプリ利用情報テーブルのアプリＩＤが、予め設定されて記憶されたアプリＩＤと一致しているか否かを判断する。設定されて記憶されたアプリＩＤは、例えば、新幹線や飛行機のチケット予約をするためのアプリケーションのアプリＩＤである。当該アプリケーションは、例えば、ユーザが交通機関の情報といった特定の情報にアクセスするために用いられるため、特定のアクセス先である。判定部１５は、上記の結果、一致しているレコードがアプリ利用情報テーブルに存在していれば（特定のアプリケーションをユーザが利用していれば）ｘ３を１とし、一致しているレコードがアプリ利用情報テーブルに存在していなければ（特定のアプリケーションをユーザが利用していなければ）ｘ３を０とする。

続いて、帰宅しやすさ度ｘ４（現在位置から自宅までの距離と時刻）の算出について説明する。自宅から距離の近い場所を訪問している方が日帰りしやすいと考えられるので、当該距離が近いほど帰宅しやすいとする。また、時刻が早いほど日帰りしやすいと考えられる。

記憶部１１は、帰宅しやすさ度の算出に用いられる、ユーザの自宅の位置の情報を拠点情報テーブルで保持する。図７に拠点情報テーブルを示す。図７に示すように拠点情報テーブルは、ユーザＩＤ、拠点の形態、緯度及び経度が対応付けられた情報を格納する。拠点情報テーブルの各レコード（１つの行のデータ）が、１人のユーザの情報に対応する。

ユーザＩＤは、自宅に係るユーザのユーザＩＤである。拠点の形態は、位置がどのような拠点であるかを示す情報である。なお、本実施形態では、拠点の形態は、ユーザの自宅とするが、自宅以外の形態が用いられてもよい。緯度及び経度は、拠点（ユーザの自宅）の位置の緯度及び経度である。図７に示す拠点情報テーブルに格納される情報は、予め、各ユーザ端末２０からサーバ１０によって受信されてサーバ１０に入力されている。

判定部１５は、記憶部１１の図２に示す位置情報テーブルから、日常圏／非日常圏判定の判定対象のユーザの位置情報を取得する。当該位置情報は、判定時点で最新（位置取得時刻が最も新しい）の位置情報である。判定部１５は、取得した位置情報によって示される位置と、拠点情報テーブルの当該ユーザの情報によって示されるユーザの位置との距離ｄ＿ｈｏｍｅを算出する。この距離ｄ＿ｈｏｍｅが近い（値が小さい）ほど、帰宅しやすいとする。

判定部１５は、位置情報テーブルから当該位置情報のレコードの位置取得時刻ｔ＿ｃｕｒｒｅｎｔを示す情報を取得する。位置取得時刻が古い（ＵＮＩＸ時間に変換した値が小さい）ほど、帰宅しやすいとする。判定部１５は、距離ｄ＿ｈｏｍｅの逆数と、位置取得時刻ｔ＿ｃｕｒｒｅｎｔ（例えば、ＵＮＩＸ時間に変換した値）の逆数とを積算する、以下の式によりｘ４を算出する。
ｘ４＝（１／ｔ＿ｃｕｒｒｅｎｔ）＊（１／ｄ＿ｈｏｍｅ）

判定部１５は、全ての帰宅しやすさ度ｘ１〜ｘ４を算出したら、上述したように以下の式により、総合の帰宅しやすさ度を算出する。
帰宅しやすさ度＝ｗ１ｘ１＋ｗ２ｘ２＋ｗ３ｘ３＋ｗ４ｘ４

判定部１５は、算出した総合の帰宅しやすさ度と、予め設定された閾値とを比較して、ユーザが判定対象日に帰宅するか否かを判定する。比較の結果、総合の帰宅しやすさ度が閾値よりも小さかった場合、判定部１５は、当該ユーザについて帰宅しないと判定する。比較の結果、総合の帰宅しやすさ度が閾値以上であった場合、判定部１５は、当該ユーザについて帰宅すると判定する。判定部１５は、日常圏／非日常圏判定及び日帰り判定の結果をメッセージ送信部１６に通知する。なお、各帰宅しやすさ度ｘ１〜ｘ４の重みｗ１〜ｗ４、及び上記の閾値については、実際のユーザの情報及び要求される判定の精度等に基づき、適宜、実際のデータ等が用いられたチューニングがされることが望ましい。

なお、距離算出部１４及び判定部１５は、例えば、予め設定されたタイミング、あるいはサーバ１０の管理者等からサーバ１０に対して要求があった場合に判定の処理を行う。具体的には、メッセージを送信するタイミングで判定を行う。また、距離算出部１４及び判定部１５による処理は、ユーザ毎に（ユーザ毎の情報に対して）行われる。日常圏／非日常圏判定及び日帰り判定の対象となるユーザは、予め設定されており、例えば、メッセージの送信候補となるユーザである。

メッセージ送信部１６は、判定部１５による判定に応じて、メッセージを出力するメッセージ出力手段である。メッセージ送信部１６は、ユーザ端末２０に対してメッセージを送信する。メッセージ送信部１６は、別の装置から受信する等して、予め送信対象となるメッセージを記憶している。メッセージには、上述したように日常圏で必要なもの、非日常圏で必要なもの、及び日常圏でも非日常圏でも必要なものの何れかが設定されている。メッセージ送信部１６は、各ユーザ端末２０に対して、判定部１５から通知された判定の結果に基づいてメッセージを送信する。

ユーザが日常圏に位置していると判定された場合（日帰り判定が行われなかった場合）、メッセージ送信部１６は、当該ユーザのユーザ端末２０に対して、送信対象となるメッセージのうち、日常圏で必要なもの、及び日常圏でも非日常圏でも必要なものを送信する。ユーザが判定対象日に帰宅しないと判定された場合、メッセージ送信部１６は、当該ユーザのユーザ端末２０に対して、送信対象となるメッセージのうち、非日常圏で必要なもの、及び日常圏でも非日常圏でも必要なものを送信する。ユーザが判定対象日に帰宅すると判定された場合、メッセージ送信部１６は、当該ユーザのユーザ端末２０に対して、全てのメッセージを送信する。以上が、本実施形態に係るサーバ１０の機能である。

図８に本実施形態に係るサーバ１０のハードウェア構成を示す。図８に示すようにサーバ１０は、ＣＰＵ１０１、主記憶装置であるＲＡＭ（Random Access Memory）１０２及びＲＯＭ（Read Only Memory）１０３、通信を行うための通信モジュール１０４、並びにハードディスク等の補助記憶装置１０５等のハードウェアを備えるコンピュータを含むものとして構成される。これらの構成要素がプログラム等により動作することにより、上述したサーバ１０の機能が発揮される。以上が、本実施形態に係るサーバ１０の構成である。

引き続いて、図９のフローチャートを用いて、本実施形態に係るサーバ１０で実行される処理を説明する。ユーザ端末２０から位置情報が送信されると、サーバ１０では、位置情報取得部１２によって位置情報が受信されて取得される（Ｓ０１）。また、ユーザ端末２０からアクセス情報が送信されると、サーバ１０では、アクセス情報取得部１３によってアクセス情報が受信されて取得される（Ｓ０２）。なお、位置情報の取得及びアクセス情報の取得は、ユーザ端末２０から情報が送信される度に行われる。

続いて、判定部１５によって、位置情報取得部１２によって取得された位置情報に基づいて、日常圏／非日常圏判定が行われる（Ｓ０３）。この判定で、少なくとも一つの位置情報に基づきユーザが非日常圏に位置していると判定された場合（Ｓ０３の非日常圏）、引き続いて当該ユーザについての日帰り判定が行われる。具体的には、距離算出部１４によって、位置情報取得部１２によって取得された位置情報及びアクセス情報取得部１３によって取得されたアクセス情報に基づいて、アクセス情報に係る位置から交通機関の位置までの距離が算出される（Ｓ０４）。

また、判定部１５によって、位置情報取得部１２によって取得された位置情報及びアクセス情報取得部１３によって取得されたアクセス情報に基づいて、帰宅しやすさ度ｘ１〜ｘ４が算出される。帰宅しやすさ度ｘ２の算出の際、距離算出部１４によって算出された距離が用いられる。続いて、判定部１５によって、算出された帰宅しやすさ度ｘ１〜ｘ４から、総合の帰宅しやすさ度が算出される（Ｓ０５）。続いて、判定部１５によって、算出された総合の帰宅しやすさ度から日帰り判定が行われる（Ｓ０６）。

続いて、メッセージ送信部１６によって、判定部１５による判定に基づいて、ユーザ端末２０に対してメッセージの送信が行われる（Ｓ０７）。また、Ｓ０３において、ユーザが非日常圏に位置していると判定されなかった場合（Ｓ０３の日常圏）、日帰り判定は行われず、メッセージ送信部１６によって、判定部１５による判定に基づいて、ユーザ端末２０に対してメッセージの送信が行われる（Ｓ０７）。送信されたメッセージは、ユーザ端末２０で受信されて利用される。なお、Ｓ０３〜Ｓ０７の処理は、ユーザ毎に行われる。以上が、本実施形態に係るサーバ１０で実行される処理である。

上述したように本実施形態では、アクセス情報に係る位置から交通機関の位置までの距離が考慮されて、ユーザが日帰りするか否かが判定される（帰宅しやすさ度ｘ２を用いた判定）。これにより、本実施形態によれば、アクセス情報に係る位置（例えば、レストランの位置）に行くと共に交通機関を利用するという行動をユーザの推定される行動とすることで、ユーザが実際に帰宅していない状態であっても、ユーザの日帰り判定を行うことができる。従って、単にユーザの位置を参照する場合と比べて、より早いタイミングで日帰り判定を行うことができる。また、ユーザのスケジュール（カレンダに登録された情報）やメールの情報から、ユーザの行動が推定できない場合にも、より早いタイミングで日帰り判定を行うことができる。なお、ユーザのスケジュールやメールの情報を参照できる場合には、当該情報を用いてもユーザの日帰りが判定できなかった場合に、本実施形態の日帰り判定を行うこととしてもよい。

また、本実施形態のようにアクセス時刻情報を用いて、日帰り判定を行う（帰宅しやすさ度ｘ２の算出）こととしてもよい。この構成によれば、時刻情報が更に考慮されることで、精度の高い判定を行うことができる。

また、本実施形態のようにユーザの位置に基づいて、距離の算出対象となる交通機関の位置を特定することとしてもよい。この構成によれば、ユーザの位置に基づき、判定に用いる交通機関の位置を特定することができ、その結果、適切な判定を行うことができる。但し、交通機関の位置は、必ずしもユーザの位置に基づくものとしなくてもよく、例えば、アクセス情報に係る位置（例えば、レストランの位置）から最も近い交通機関の位置までの距離としてもよい。

また、本実施形態のように検索に用いたキーワードにも基づいて日帰り判定（帰宅しやすさ度ｘ１を用いた判定）を行うこととしてもよい。また、本実施形態のようにアクセス情報によって示されるアクセスが特定のアクセス先へのものか否かにも基づいて日帰り判定（帰宅しやすさ度ｘ３を用いた判定）を行うこととしてもよい。また、本実施形態のようにユーザの位置と自宅までの距離、及び位置取得時刻にも基づいて日帰り判定（帰宅しやすさ度ｘ４を用いた判定）を行うこととしてもよい。これら構成によれば、より精度の高い判定を行うことができる。但し、日常圏／非日常圏判定を含む日帰り判定にユーザの位置情報を用いている構成となっていれば、帰宅しやすさ度ｘ２以外は必ずしも用いる必要はない。

なお、上記の帰宅しやすさ度ｘ２に加えて、帰宅しやすさ度ｘ２における距離の算出対象となったアクセス情報に係る位置でのユーザの推定滞在時間を日帰り判定に利用してもよい。判定部１５は、アクセス情報に係る位置に応じて予め設定された当該位置でのユーザの推定滞在時間にも基づいて判定することとしてもよい。当該位置でのユーザの推定滞在時間は、例えば、Ｗｅｂサイトに係る施設（例えば、レストラン）にユーザがどの程度の時間いるかを推定したものである。判定部１５は、Ｗｅｂサイトに係る施設毎に予め推定滞在時間を記憶しておく。当該推定滞在時間が短いほど、帰宅しやすいとする。そこで、当該推定滞在時間が短いほど大きくなる値（例えば、推定滞在時間の逆数）を帰宅しやすさ度ｘ５とする。判定部１５は、総合の帰宅しやすさ度に重みｗ５で重み付けされた帰宅しやすさ度ｘ５（＝ｗ５ｘ）を更に加えて、日帰り判定を行うこととしてもよい。この構成によれば、アクセス情報に係る位置でのユーザの推定滞在時間が更に考慮されることで、精度の高い判定を行うことができる。

また、本実施形態では、総合の帰宅しやすさ度を算出して、日帰り判定を行うこととしたが、機械学習により日帰り判定を行うこととしてもよい。例えば、算出した各帰宅しやすさ度ｘ１〜ｘ５を説明変数として、日帰り判定を行うための学習モデルを機械学習（ロジスティック回帰、ＳＶＭ（サポートベクターマシン））により予め生成しておき、当該学習モデルによって日帰り判定を行ってもよい。

また、本実施形態のように、サーバ１０は、日帰り判定に応じてメッセージの送信を行うこととしてもよい。この構成によれば、判定に応じた適切なメッセージを送信することができる。但し、サーバ１０は、本発明に係る日帰り判定システムとしては、日帰り判定まで行うこととすればよい。即ち、日帰り判定の判定結果を別の装置に出力して、別の装置が判定結果に基づきメッセージの提供を行うこととしてもよい。また、メッセージの送信以外に、日帰り判定の判定結果が用いられてもよい。

また、本実施形態では、Ｗｅｂサイトのアクセスに係るアクセス情報は、Ｗｅｂサイトの検索を前提としたが、必ずしもＷｅｂサイトの検索を必要とせず、Ｗｅｂサイトのアクセスのみの情報が用いられてもよい。

また、本実施形態では、本発明に係る日帰り判定システムをサーバ１０としたが、ユーザ端末２０が本発明に係る日帰り判定システムであってもよい。その場合、ユーザ端末２０に上述したサーバ１０の本発明に係る機能が備えられる。また、本発明に係る機能が、サーバ１０と、ユーザ端末２０とに分散して備えられていてもよい。

１０…サーバ、１１…記憶部、１２…位置情報取得部、１３…アクセス情報取得部、１４…距離算出部、１５…判定部、１６…メッセージ送信部、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…通信モジュール、１０５…補助記憶装置、２０…ユーザ端末、Ｎ…ネットワーク。

Claims (8)

1. ユーザの位置を示す位置情報を取得する位置情報取得手段と、
   前記ユーザによってアクセスされた情報を示すアクセス情報を取得するアクセス情報取得手段と、
   前記アクセス情報取得手段によって取得されたアクセス情報に係る位置を特定し、当該位置から交通機関の位置までの距離を算出する距離算出手段と、
   前記位置情報取得手段によって取得された位置情報、及び前記距離算出手段によって算出された距離に基づいて、前記ユーザが判定対象日に帰宅するか否かを判定する判定手段と、
   を備える日帰り判定システム。
2. 前記判定手段は、前記アクセス情報に係る位置に応じて予め設定された当該位置でのユーザの推定滞在時間にも基づいて判定する請求項１に記載の日帰り判定システム。
3. 前記アクセス情報取得手段は、前記ユーザが情報にアクセスした時刻を示すアクセス時刻情報も取得し、
   前記判定手段は、前記アクセス情報取得手段によって取得されたアクセス時刻情報にも基づいて判定する、請求項１又は２に記載の日帰り判定システム。
4. 前記距離算出手段は、前記位置情報取得手段によって取得された位置情報に基づいて、距離の算出対象となる交通機関の位置を特定する請求項１〜３の何れか一項に記載の日帰り判定システム。
5. 前記アクセス情報取得手段は、前記ユーザが検索に用いたキーワードも取得し、
   前記判定手段は、前記アクセス情報取得手段によって取得されたキーワードにも基づいて判定する、請求項１〜４の何れか一項に記載の日帰り判定システム。
6. 前記判定手段は、前記アクセス情報取得手段によって取得されたアクセス情報によって示されるアクセスが特定のアクセス先へのものか否かにも基づいて判定する請求項１〜５の何れか一項に記載の日帰り判定システム。
7. 前記位置情報取得手段は、前記位置情報によって示される位置に前記ユーザがいた時刻を示す位置時刻情報も取得し、
   前記判定手段は、前記位置情報取得手段によって取得された位置情報に基づいて前記ユーザの自宅からの距離を算出し、算出した距離及び前記位置情報取得手段によって取得された位置時刻情報にも基づいて判定する、請求項１〜６の何れか一項に記載の日帰り判定システム。
8. 前記判定手段による判定に応じて、メッセージを出力するメッセージ出力手段を更に備える請求項１〜７の何れか一項に記載の日帰り判定システム。

Images