JP2014149811A - 本人確認方法および本人確認装置 - Google Patents

Abstract

【課題】パスワードの記憶を必要とせず、認証に用いられるクレデンシャルの変更を、ユーザーの操作を必要とせずに自動的に行われる本人確認方法および本人確認装置を提供する。
【解決手段】ユーザーの携帯通信機器から、その携帯通信機器の現在位置情報を受信し、その携帯通信機器の移動履歴に関する情報を収集する。そして、この履歴の内容に関する質問を生成し、ユーザーに提示する。ユーザーから受け取った回答と履歴の内容を比較し、両者間の整合性が確認された場合、本人であると決定する。
【選択図】図１

Description

本発明は、インターネット上で本人確認を行う本人確認方法および本人確認装置に関する。

近年、携帯電話、ＰＨＳ（Personal Handyphone System）、スマートフォン等の携帯通信機器の利用範囲が飛躍的に広がってきている。本来の機能である通話機能の他に、データ通信機能などが強化され、ユーザーに対してインターネットを介した種々のサービスが提供されている。特に、ＧＰＳを初めとする現在位置情報を利用する様々なサービスが提案されている（特許文献１）。

また、ユーザーは、そのようなサービスへのログオンにおいて、本人確認の為にIDとパスワードを入力しなければない。複数のサービスを利用する場合、夫々のIDとパスワードを設定する必要があるが、それらを記憶しておくことがユーザーへの負担となっている。そこで、OAuthやOpenIDといったプロトコルを利用した認証プロバイダが、シングルサインオンを可能としている（特許文献２）。

特開２０１１−０７０３４１号公報 特開２０１２−２０３７８１号公報

しかしながら、シングルサインオンの環境が整っていたとしても、ＩＤとパスワードの適切な管理というのは、ユーザーにとって依然として負担である。先ず、パスワードの選択という問題が有る。簡単なパスワードは、簡単に破られる。しかし、複雑なパスワードは、記憶しておくことが難しい。ユーザーにとってパスワードの選択というものは常に面倒な作業である。

また、パスワードの秘匿にもユーザーは、気を配らなければならない。その為、一般に、パスワードは定期的に変更することが推奨されている。しかし、定期的に変更する場合には、上記の通りパスワードの選択が更に大きな負担となってしまう。したがって、定期的な変更を怠っているユーザーも大変多いというのが実情である。

そこで、本発明の目的は、パスワードの記憶を必要としない本人確認方法および本人確認装置を提供することである。

また、本発明の別の目的は、認証に用いられるクレデンシャルの変更を、ユーザーの操作を必要とせずに自動的に行われる本人確認方法および本人確認装置を提供することである。

上記課題を解決するために、本発明の本人確認方法は、ユーザーの携帯通信機器から、その携帯通信機器の現在位置情報を受信するステップと、前記携帯通信機器の現在位置情報と、その位置に前記携帯通信機器が存在した時間を関連付けて記録することにより、その携帯通信機器の移動履歴に関する情報を収集するステップと、前記携帯通信機器の履歴を参照し、この履歴の内容に関する質問を生成するステップと、前記質問を前記ユーザーに提示するステップと、前記ユーザーから前記質問に対する回答を受け取るステップと、前記回答と前記履歴の内容を比較し、両者間の整合性を確認するステップと、前記回答と前記履歴の内容に整合性があると確認された場合、本人であると決定するステップとからなる。

一つの実装例では、前記履歴は、前記携帯通信機器を特定する識別子と関連付けられており、前記ユーザーの操作する通信手段から、前記識別子と共に本人確認要求を受信するステップと、この本人確認方法により本人であると決定された場合、前記通信手段へ決定内容を通知するステップとを更に含む。また、前記通信手段は、前記携帯通信機器または前記携帯通信機器以外の通信手段のいずれかである。

また、一つの実装例では、前記質問は、前記ユーザーに地図を表示し、その地図上の位置として回答を求めるものである。ここで、地図上の複数の位置として回答を求めることができる。この場合、回答には、複数の位置の前後関係を含むようにしても良い。更に、一つの実装例では、前記携帯通信機器から受信する現在位置情報は、暗号化されている。

図１は、本発明の実施例１に係る本人確認方法において、位置情報履歴データの収集方法を説明する図である。 図２は、本発明の実施例１において、各携帯通信機器に対応する履歴データベースの履歴テーブルを示す図である。 図３は、本発明の実施例１において、履歴データベースの現在位置情報テーブルを示す図である。 図４は、本発明の実施例１の利用シナリオにおける信号の流れを説明する図である。 図５は、本発明の実施例１において、一つの携帯通信機器の履歴との相関の高い他の携帯通信機器の位置情報レコードのリストが表示されている画面を示す図である。 図６は、本発明の実施例１において、一つの携帯通信機器の履歴との相関の高い位置情報レコードから、特定の携帯通信機器のレコードのみを抽出した画面を示す図である。 図７は、本発明の実施例１において、別の携帯通信機器へメッセージを送信するための編集画面を示す図である。 図８は、本発明の実施例１において、受信したメッセージが表示されている画面を示す図である。 図９は、本発明の実施例１において、メッセージへの返信を行う為の画面を示す図である。 図１０は、本発明の実施例１において、位置情報履歴照合サーバーを本人確認プロバイダとして用い、ユーザーがブラウザを介して或るサービスプロバイダへのログオンを行う具体例を説明する図である。 図１１は、本発明の実施例２に係る本人確認方法を利用したユーザー情報へのアクセス権を認可する方法を説明する図である。 図１２は、本発明の実施例１において、本人確認プロバイダによる認証によって本人確認を行うサービスプロバイダのログオン画面を示す図である。 図１３は、本発明の実施例１において、本人確認プロバイダによって表示される択一式の質問を含む質問画面を示す図である。 図１４は、本発明の実施例１において、本人確認プロバイダによって表示される択一式の質問を含む別の質問画面を示す図である。 図１５は、本発明の実施例３の本人確認方法で用いる地図を表示した質問画面を示す図である。 図１６は、本発明の実施例３の本人確認方法で用いる拡大した地図を表示した質問画面を示す図である。 図１７は、本発明の実施例３の本人確認方法で用いる更に拡大した地図を表示した質問画面を示す図である。 図１８は、本発明の実施例３の本人確認方法で用いる更に拡大した地図を表示した質問画面を示す図である。 図１９は、本発明の実施例３の本人確認方法で用いる拡大した地図において、複数の位置が指定された回答画面を示す図である。 図２０は、本発明の実施例３の本人確認方法で用いる拡大した地図において、複数の位置が指定された回答画面を示す図である。 図２１は、本発明の実施例６において、経緯度情報の暗号化方法を説明する図である。 図２２は、本発明の実施例６において、暗号化された経緯度情報の記録状態を示す図である。 図２３は、本発明の実施例６において、経緯度情報の復号方法を説明する図である。 図２４は、本発明の実施例７の利用シナリオにおける信号の流れを説明する図である。 図２５は、本発明の実施例７において、ユーザー間の共通点を抽出する追加の情報源を選択する為のダイアログを示す図である。 図２６は、本発明の実施例８の利用シナリオにおける信号の流れを説明する図である。 図２７は、本発明の実施例９において、ある特定の場所と時間における情報を得る為の検索画面を示す図である。 図２８は、本発明の実施例９において、検索結果画面を示す図である。 図２９は、本発明の実施例９において、別の携帯通信機器へメッセージを送信するための編集画面を示す図である。 図３０は、本発明の実施例９において、メッセージへの返信を行う為の画面を示す図である。 図３１は、本発明の実施例９において、掲示板へ質問メッセージを投稿するためのメッセージ編集画面を示す図である。 図３２は、本発明の実施例９において、掲示板のスレッドを示す図である。 図３３は、本発明の実施例９において、掲示板へ返信メッセージを投稿するためのメッセージ編集画面を示す図である。 図３４は、本発明の実施例９において、ある特定の場所と時間における情報を得る為の検索画面を示す図である。

以下、添付図面を参照しながら本発明の実施形態による本人確認方法を説明する。利用する携帯通信機器としては、現在位置情報の取得が可能で、インターネットへの通信機能を備えたものを想定する。具体的には、一般的な携帯電話、スマートフォンと呼ばれるタッチパネル付きの多機能携帯電話、タブレット型コンピュータが含まれる。現在位置情報の取得方法としては、ＧＰＳ（Global Positioning System）や、基地局による三角測量、Wi-Fiの電波強度を利用したものや、それらを組み合わせたものなどがある。

なお、以下の実施例ではサーバー等に現在位置情報が蓄積されるが、その位置情報履歴から容易に自宅住所や職場や学校の位置を特定することが可能である。例えば、位置情報履歴データは、自宅に毎晩滞在した情報と、職場や学校に長時間位置した情報とが平日の間繰り返され、休日には職場や学校の位置情報は現れない、といったようなものになると考えられる。場合によっては、プライバシー上これは望ましくないと考えられる。従って、このようなデータは、位置情報履歴データから除外するのが望ましい。

更に、このような繰り返される現在位置情報の除外によって、本人確認のセキュリティの強度が高まると考えられる。なぜなら、職場や学校といった情報は、他人であっても容易に推量可能なものだからである。繰り返されない現在位置情報は、本人しか知りえない情報である可能性が高い。

図１を参照して、実施例１の本人確認方法を実装する本人確認サーバーを説明する。この本人確認サーバー（認証プロバイダ）は、共通点提供サーバーとしても機能する。まず、この共通点提供サーバーが行う共通点提供方法を説明する。この共通点提供方法は、インターネットへ接続している位置情報履歴照合サーバー１によって運営されている。また、この共通点提供方法の利用を希望するユーザーは、常駐プログラムをサーバーからダウンロードして、携帯する携帯通信機器にインストールしておく。

この常駐プログラムは、現在位置情報を定期的に測位して、位置情報履歴照合サーバー１に送信する。図１では、携帯通信機器３Ａを利用するユーザーＡと携帯通信機器３Ｂを利用するユーザーＢのみが、この共通点提供方法のユーザーを代表して図示されているが、実際には非常に多くのユーザーの存在を想定している。

位置情報履歴照合サーバー１には、履歴を管理する為の履歴データベースが設けられている。また、この履歴データベースには、図２に示すように、携帯通信機器毎に履歴テーブル２が設けられている。履歴テーブル２は、記録の行われた日付と時間、緯度、経度、その時に通信を行なっている基地局７を特定するCell-IDと、受信感度のフィールドからなっている。常駐プログラムは、タイマーイベントに応答して、携帯通信機器の現在日時、現在位置、Cell-IDおよび受信感度を、１レコードとして生成する。

ユーザーの識別には、常駐プログラムをダウンロードした際に割り振られたユニークな端末IDが用いられ、夫々の履歴テーブル２に関連付けられている。また、履歴テーブル２に含まれるレコードには、時系列に並べたシリアル番号が与えられている。すなわち、履歴テーブル２と端末IDは一対一の対応関係にある。常駐プログラムが、位置情報履歴照合サーバー１へ現在位置情報を送信する際には、Cell-IDや受信感度に加えて、この端末IDを同時に送信する。このようにサーバーが割り振るIDの代わりに、その携帯通信機器自体を識別する個体識別番号を端末IDとして用いても良い。具体的には、衛星５からの信号に基づくＧＰＳ等を利用して、常駐プログラムが数分毎（例えば、５分毎）に現在位置を測位し緯度と経度を特定する。

位置情報履歴照合サーバー１の履歴データベースでは、図３に示したような現在位置情報テーブルに、端末IDで特定される携帯通信機器の現在位置情報が記録されている。現在位置情報テーブルの各フィールドは、履歴テーブルの各フィールドに対応しているが、時系列のシリアル番号の代わりに、その携帯通信機器を特定する端末IDのフィールドが設けられている。

携帯通信機器からの現在位置情報を受信すると、位置情報履歴照合サーバー１は、添付されている端末IDが、現在位置情報テーブルに記録されているか否かを確認する。記録されていなければ、この端末IDに対応して、現在位置情報テーブルに、この現在位置情報に基づいて新たなレコードを生成する。また、この端末IDの履歴テーブルも生成する。

既に記録されていれば、その端末IDのレコードから前回の現在位置情報（経緯度）を取得し、受信した現在位置情報と照合する。もし、これらの緯度と経度がほぼ同一（例えば、高々１０ｍ程度の差異）であれば、何もせず受信した現在位置情報は捨てる。

受信した現在位置情報が現在位置情報テーブルに記録されている前回のものと異なる場合、その記録されている前回のレコードを、その端末IDに対応する履歴テーブルに新たなレコードとして追加する。そして、現在位置情報テーブルの当該レコードを、受信した現在位置情報、Cell-ID、受信感度、記録日時で更新する。従って、履歴テーブルにおいて、或るレコードの示す位置での滞在時間は、当該レコードと後続のレコードとの時間差に対応することになる。

例えば、時刻13:30のレコードの次が時刻14:30のレコードであった場合、最初のレコードの場所に一時間滞在したことになる。すなわち、測定間隔を単位としてレコードの時間フィールドが連続している場合、移動中であると考えられる。また、隣接するレコードの時間フィールドが不連続の場合には、その位置フィールドで示された場所に滞在していることを示している。従って、移動中のレコードを除いて、各レコードの日付と時間は、概ね当該携帯通信機器がその位置フィールドで示された場所に来た日時を示している。ここでは、滞在しているレコードを取り扱うため、日付フィールドを訪問日付、時間フィールドを訪問時間、位置フィールドを訪問位置と呼ぶ。Cell-IDや受信感度は補助データとして、経緯度の信頼性などに利用できる。履歴テーブルの最も新しいレコードの示す位置での滞在時間は、現在位置情報テーブルの対応するレコードの時刻と、履歴テーブルの最も新しいレコードの示す位置での時刻との差分ということになる。また、現在位置における滞在時間は、現在位置情報テーブルの対応するレコードの時刻と現在時刻との差分ということになる。

別の実装態様として、現在位置情報テーブルの各レコードを、対応する履歴テーブルの最新レコードとして記録しておいても良い。すなわち、現在位置情報テーブルは、各携帯通信機器に対応する履歴テーブルの最新レコードを参照するものとなる。この場合、履歴テーブルのみから滞在時間が算出できる。

次に、実際の利用シナリオに従って、この共通点提供方法を説明する。なお、図４に全体の信号の流れが示されている。例えば、携帯通信機器３Ａを利用するユーザーＡが、カフェでコーヒーを飲んでいるとする。そして、誰かと話をしてみたいと思った場合、携帯通信機器３Ａを手に取り、常駐プログラムのアイコンをクリックする。通常は、常駐プログラムは常に実行されている（常駐）ので、二重起動は行わずに代わりにユーザー検索要求を位置情報履歴照合サーバー１へ行う。ユーザー検索要求には、現在位置情報と端末IDが添付されている。

このユーザー検索要求を受信した位置情報履歴照合サーバー１は、現在位置情報テーブルを検索して、携帯通信機器３Ａの現在位置の近傍に位置する携帯通信機器のユーザーを特定する。例えば、携帯通信機器３Ａから５０ｍ迄の範囲にいるユーザーを特定する。もしも、その範囲のユーザー数が一定人数、例えば３人以下なら、１００ｍ迄の範囲にいるユーザーを特定する。

また、携帯通信機器３Ａの端末IDの履歴テーブルから、一定時間、例えば一時間以上滞在した場所の位置情報（以下、特定位置情報と呼ぶ）を抽出する。そして、上記範囲のユーザーの履歴テーブルから、上記特定位置情報と所定の類似関係を満たすレコードを検索する。この所定の類似関係とは、滞在時間が一定時間、例えば３０分以上であって、訪問位置間の距離が、所定の距離（例えば、１ｋｍ）よりも大きくない場合に成り立つ。検索されたレコードは、携帯通信機器３Ａの履歴との相関の高いものから並べて表示される。並べ替えは、例えば次のような手順で行われる。

先ず、その特定位置に携帯通信機器３Ａと同じ時間に滞在したユーザーのレコードが優先される。その中では、このユーザーと携帯通信機器３Ａのユーザーが、同時に滞在した時間の長いレコードが優先される。すなわち、上記特定位置情報と滞在時間がより長く重複する位置情報レコードが優先される。

次に、携帯通信機器３Ａのユーザーと、同じ場所にいた累積の滞在時間（同時でなくても）が長いユーザーのレコードが優先される。

図５に携帯通信機器に表示された上記レコードのリスト画面の例を示す。ここで、最も優先度の高い一番上のレコードは、端末IDが415bfa41であり、横浜市本牧市民公園近くの場所において、2011年08月28日の11:48から4時間25分滞在したことを意味する。また、当該携帯通信機器３Ａがその場所にいた日付、時刻および滞在時間が、括弧内に示されている。従って、このリストから、当該携帯通信機器３Ａのユーザーが、端末IDが415bfa41のユーザーと、同じ場所、同じ時間に４時間以上共に滞在したことが分かる。

尚、リストに表示される場所の名前は、逆ジオコーディングによって経緯度から住所へ変換し、電話帳サービスを利用して住所から名前を検索することで行う。但し、山や海など、電話帳サービスを利用できない場合には、経緯度とその場所の名前を対応付けたデータベースを利用して、「〜山」とか「〜海岸」といった表記を行う。ＧＰＳでは誤差があるので「〜付近」といった表記を用いる。

リスト画面において、場所の項目（ここでは「横浜市本牧市民公園近く」）をクリックすると、横浜市本牧市民公園をサーチタームとしたWeb検索結果が表示される。ここで、携帯通信機器３Ａのユーザーは、これがジャズ・コンサートに行った時の記録であることを思い出す。また、端末ID（ここでは「415bfa41」）をクリックすると、図６に示したように、そのユーザーのレコードのみを抽出して表示することができる。

ここでユーザーＡは、端末IDが"415bfa41"のユーザーＢと話をしてみたいと考える。そこで、メッセージ送信のボタンをクリックすると、メッセージ編集の画面に切り替わる（図７）。そこでメッセージを入力して、送信ボタンをクリックすると、端末ID "415bfa41"の携帯通信機器３Ｂへこのメッセージが送信される。具体的には、先ず位置情報履歴照合サーバー１が、この携帯通信機器３Ｂ宛メッセージを受信する。次に、携帯通信機器３Ｂが、現在位置情報を位置情報履歴照合サーバー１に送信した際に、位置情報履歴照合サーバー１は、携帯通信機器３Ｂ宛メッセージを返すようにする。

このメッセージは、図８に示したように、メッセージ本文に加えて、ユーザーＡの履歴データが表示される。但し、この履歴データは、ユーザーＢと関連性の高い履歴から表示されるので、内容は図６と同等のものとなる。この履歴データから、ユーザーＢは、ユーザーＡがどのような人物であるかについての一定の情報を得ることができる。ユーザーＢは、このメッセージに対して、返信ボタンをクリックして、図９に示したようなメッセージ編集画面から返信を行うことが出来る。また、必要に応じて、ユーザーＡとユーザーＢは、メッセージのやり取りを繰り返すこともできる。尚、メッセージの送受信処理は、常駐プログラムと位置情報履歴照合サーバー１が担う。

上記の位置情報履歴の更新プロセスでは、次のような例外処理を行うことが出来る。すなわち、位置情報が得られない場合、インターネットへアクセスできない場合および常駐プログラムが一時的に動作を停止した場合である。

位置情報が得られない場合とは、必要なＧＰＳ衛星が補足されず、Wi-Fiによる位置情報も利用できない場合である。このような場合、基地局による三角測量で大まかな位置情報を得て、位置情報レコードを生成する。但し、この位置情報レコードは、受信感度を０とした参考情報であり、この共通点提供方法では位置情報レコードとして利用できない。しかし、有効な位置情報レコード間を接続するパディングレコードとして機能する。インターネットへアクセスできない場合とは、たとえば、携帯通信機器の電波が通じない場合である。このような場合、常駐プログラムは、携帯通信機器の内部で位置情報レコードを保存しておき、インターネットへアクセスできるようになった段階で、位置情報履歴照合サーバー１へ送信する。常駐プログラムが一時的に動作を停止した場合とは、たとえば、携帯通信機器のバッテリーが切れた場合や携帯通信機器の電源を落とした場合である。このような場合、再起動の後、常駐プログラムは、位置情報レコードの送信を再開する。一方、再起動の後、位置情報履歴照合サーバー１が常駐プログラムから受信した位置情報レコードは、位置情報履歴照合サーバー１で保存してあった最新の位置情報レコード（無効位置情報レコード）と訪問時間が連続していない。すなわち、訪問時間が現在位置取得間隔よりも長い。この場合、位置情報履歴照合サーバー１は、無効位置情報レコードを前記最新の位置情報レコードに続く履歴テーブルの位置情報レコードとして生成し、受信した位置情報レコードは現在位置情報テーブルに保存する。無効位置情報レコードの訪問日付と訪問時間は、位置情報履歴照合サーバー１が前記最新の位置情報レコードに続いて受信すべきだったレコードの訪問日付と訪問時間となっている。無効位置情報レコードの他のフィールドは全て０であり、このレコードが無効であることを示す。

なお、位置情報が得られない場合には、ユーザーが位置情報履歴照合サーバー１へ、訪問日付、訪問時間、訪問位置、滞在時間を指定して、履歴データベースの履歴テーブルへレコード挿入を依頼することもできる。この場合、「20130101: Hotel Okura in Toranomon (Tokyo) at 15:00 for 4 hours」といった内容を含むテキストを送信すれば良い。例えば、SNSへその滞在に関する投稿を行なって、そのテキストをそのまま利用しても良い。位置情報履歴照合サーバー１は、テキストを解析して、訪問日付、訪問時間、訪問位置、滞在時間を抽出し、この抽出された情報に応じた履歴テーブルの位置（無効レコードの位置）に挿入する。

上記共通点提供方法では、位置情報の詳細な履歴が位置情報履歴照合サーバー１で管理される。このように個人の位置情報履歴を蓄積したシステムは、位置情報を利用して本人確認を行う本人確認プロバイダ（認証プロバイダ）として利用できる。以下、図１０を参照して、位置情報履歴照合サーバー１を実施例１の本人確認プロバイダとして用い、ユーザーがブラウザを介して或るサービスプロバイダへのログオンを行う具体例を説明する。

なお、この場合、この本人確認プロバイダによるユーザーの本人確認を利用しようとするサービスプロバイダは、前もって、本人確認プロバイダのＵＲＬと公開鍵を所有している必要がある。これらブラウザと、サービスプロバイダおよび本人確認プロバイダとの通信はＳＳＬによって行われる。

まず、ユーザーは、ブラウザで、図１２に示したようなサービスプロバイダのログオン画面へアクセスする。このログオン画面には、ユーザーＩＤを入力するフォームが含まれており、ユーザーＩＤを入力した後に送信ボタンを押すと、認証要求が本人確認プロバイダへリダイレクトされる。この認証要求には、このユーザーＩＤと共に、このサービスプロバイダのＵＲＬと認可ＩＤが添付されている。

この認可ＩＤはユーザーＩＤと本人確認プロバイダに関連付けられており、サービスプロバイダが発行する。そして一定の有効期間（例えば、２０分）が設けられており、この有効期間内に、ログオン処理を完了する必要がある。以下、ブラウザと本人確認プロバイダとの間で次のような認証プロセスが行われる。

最初に、本人確認プロバイダは、図１３又は図１４に示したような質問画面を表示する。この質問画面には、本人のみが知りうる位置情報に関わる択一式の質問が、表示されている。ここで位置情報に関わる質問とは、ある時間範囲（過去の何処か、ある年、ある年のある季節、ある季節、ある月、何日前、何時間前など）にどこ（どの国、どの地方、どの都市、どの町、どの施設、山、海など）に、どれ位（何分、何時間など）滞在したかという情報に関連するものである。そして、その質問に対して、複数の回答候補とスキップのいずれかを選択できる。

同様の質問に５問答えて、３問以上正解なら本人として認証される。正解のない無関係な出題も出され、その場合はスキップすることが正解となる。または、パスワードも予め設定しておき、３問正解で２問不正解なら、パスワード認証を行うようにしても良い。この場合、３問不正解なら認証失敗であり、４問以上正解なら認証成功とする。

本人として認証されれば、本人確認プロバイダはその旨を証明する電子証明書（ＲＳＡ、ＥＣＤＳＡなど）を生成し、サービスプロバイダのＵＲＬへリダイレクトする。この電子証明書では、ユーザーＩＤと認可ＩＤを関連付けて本人認証を行なっている。サービスプロバイダは、この電子証明書を本人確認プロバイダの公開鍵を用いて検証し、成功すればユーザーＩＤのユーザーとしてログオンを許可する。

次に、当該ユーザーの位置情報履歴から択一質問を生成する方法の一例を説明する。先ず、この位置情報履歴を検索して、今日と昨日のレコードから、１０〜２０分間滞在したレコードを２つ抽出する。直近の記録なのでユーザーは細かいところも記憶していると考えられる。従って、例えば、「昨日、喫茶モネ付近で午後２時前後に３０分滞在した」といった選択肢を生成する。

次に、過去一週間から２つのレコードを抽出する。更に、それ以前から１つのレコードを抽出する。但し、時間的な隔たりが大きいほど、普段の行動範囲から離れている場所のレコードを選択し、年単位で離れている場合は、「何年の春」というように、より範囲の広い時間を指定して質問するようにする。

当該ユーザーの位置情報履歴から５つのレコードを抽出したら、夫々について５つの誤りのレコードを選択して質問を構成する。誤りのレコードは、他のユーザーをランダムに選択し、そのユーザーのレコードをランダムに抽出し、抽出したレコードが誤りのレコードであることを確認して生成する。当該ユーザーの位置情報履歴を曖昧検索し、もし、このようにして抽出した誤りのレコード候補がヒットしている場合には、再度別の誤りのレコードを抽出する。

また、質問はスキップを含めて６択なので、６問に１問は全ての選択肢を誤りとする。例えば、「昨日、喫茶モネ付近で午前１２時前後に３０分滞在した」といった具合に、当人なら気づく程度に正解から少しずらずことで正解の選択肢を誤りの選択肢とするようにしても良い。この場合、正解はスキップである。

なお、上記例では、正解のない質問の為に、「スキップ」というキャプションのボタンを表示しているが、「その他」といった同等の意味のキャプションにしてもよい。また、上記例では、ユーザーの識別には、常駐プログラムをダウンロードした際に割り振られたユニークな端末IDが用いられているので、この端末IDがそのまま確認する本人のIDとなる。もちろん、このような管理用の数値である端末IDをそのままではなく、ユーザーが希望するユーザー名を端末IDに関連付けて登録し、このユーザー名による本人確認を行うようにしても良い。更に、携帯通信機器経由で本人確認を行うだけではなく、例えば、パーソナルコンピュータ、タブレット型端末、または当該携帯通信機器とは別のスマートフォンや、その他の通信機能を有する端末において本人確認を行う場合であっても、上記本人確認方法はそのまま実施できることは言うまでもない。すなわち、クレデンシャルの基礎データは、ユーザーの携帯通信機器によって蓄積されるが、その基礎データは当該携帯通信機器とは無関係に本人確認に利用できる。

実施例１においては、単純なユーザー認証に本発明の本人確認方法を利用している。しかし、サービスプロバイダが、本人確認を必要とするユーザーに関する別のリソース（例えば、ＳＮＳにおけるユーザーデータ）を利用したサービスを提供したい場合もある。この場合、ユーザーのリソースへアクセスする権利をサービスプロバイダに与えても良いか否かを、本人確認プロバイダが確認することになる。
なお、ユーザーのリソースの管理を、本人確認プロバイダが行う場合もあるし、本人確認プロバイダとは別のサービス提供者がユーザーのリソースを管理するサービスを提供する場合もありえる。いずれにせよ、上記のサービスプロバイダ、本人確認プロバイダ、別のサービス提供者、および当該携帯通信機器（又は、ユーザーが利用する本人確認の為の処理を行うパソコンなどの通信手段）は、インターネットに接続されている。

以下、図１１を参照して、上記の本人確認方法を用いたアクセス権の認可の具体例を説明する。ただし、位置情報履歴照合サーバーに位置情報履歴が蓄積され管理されるまでは、実施例１での処理と同じであり、ユーザーの位置情報履歴が利用可能となっていることを前提とする。

先ず、このサービスプロバイダのサービスを受けるためには、ユーザーは、別のサービスの管理する情報へのアクセス権を移譲する必要がある。そこで、ユーザーは、サービスプロバイダを介して、そのアクセス権を得るための認証を開始する。

サービスプロバイダは、ユーザーからの認証開始要求を受けて、本人確認プロバイダへトークン要求を送信する。このトークン要求には、どのリソースへのアクセス権を許可するかとか、書き換えは許可するかとか、アクセス権の有効期間といった認可情報を含んでいる。

このトークン要求を受けて、本人確認プロバイダは、未認可のトークンをサービスプロバイダへ返す。サービスプロバイダは、この未認可トークンを確認してユーザーへ転送するが、ユーザー側ではこれを本人確認プロバイダへリダイレクトする。

次に、ユーザーと本人確認プロバイダとの間で、本人確認の認証が行われる。まず、ユーザーから返された未認可トークンを受けて、本人確認プロバイダは、サービスプロバイダへ移譲するアクセス権の内容をユーザーへ示して同意を求める。ユーザーは、その内容を確認してからアクセス権の移譲に同意する。

そして、上記の本発明の本人確認方法により本人確認が行われる。これは、ユーザーからのクレデンシャルの送信ということになる。すなわち、本人確認プロバイダは、本人のみが知りうる位置情報に関わる択一式の質問を例えば５問提示し、ユーザーはそれに回答し、３問正解なら本人として認証する。

本人確認に成功すると、本人確認プロバイダは、認可済トークンをユーザーへ返す。この認可済トークンは、ユーザーからサービスプロバイダへリダイレクトされる。そして、サービスプロバイダは、この認可済トークンを用いて、ユーザーのリソースへのアクセスを行う。例えば、Web APIの呼出すことでユーザー情報の読み出し等を行う。

上記実施例では、択一式の質問によって本人確認を行っている。この実施例３では、ユーザーに「○月△日□時に何処へいたか？」といった質問を行い直接の回答を求める。但し、文字による回答は面倒であり、また曖昧さが残るので以下のように地図から選択するようにする。以下の処理は、図１０のプロトコルにおいて「質問」と「回答」に対応する処理を置き換えるものである。その他は、実施例１または実施例２と同様の処理を行う。

すなわち、ユーザーは、ブラウザで、図１２に示したようなサービスプロバイダのログオン画面へアクセスする。このログオン画面には、ユーザーＩＤ（ユーザー名）を入力するフォームが含まれており、ユーザーＩＤを入力した後に送信ボタンを押すと、認証要求が本人確認プロバイダへリダイレクトされる。この認証要求には、このユーザーＩＤと共に、このサービスプロバイダのＵＲＬと認可ＩＤが添付されている。

まず、本人確認プロバイダは、図１５に示したような日本全体の地図を表示して、「ユーザー名を入力して、１１月３日午後１時の所在地をなるべく細かく指定して下さい」といった過去のユーザーの位置情報そのものに関する質問を行う。質問の所在地は、現在に近いほどそのユーザーの日常の行動範囲に近いレコードから選択され、過去へ遡るほどより遠い場所のレコードから選択される。この選択方法はユーザーに知らされており、一年前の質問といった場合には、旅行や出張の記憶から回答すれば良いということになる。これに対して、ユーザーは、上記端末ＩＤと一対一に対応するユーザー名を入力した上でその日時にいた場所を思いだして指定（入力）する。

ユーザーが、その日時に都内の或る場所にいたとすると、場所の指定は次のように行う。まず、最初の日本全体の地図で、東京都のあたりをクリック（タップ）する。すると本人確認プロバイダは、図１６に示したように、東京都を中心として拡大した地図を表示する。この拡大した地図において、ユーザーは自分のいた地域をクリックして、図１７に示したように、更に拡大した地図を表示する。この更に拡大した地図において、ユーザーは、都内の或る場所に近い位置をクリックする。すると本人確認プロバイダは、図１８に示したように、クリックされた位置を中心として市街地の地図を表示する。最後に必要なら地図の表示位置をずらしながら、自分のいた場所をクリックする。そして、ユーザーは、地図の上に表示されているＯＫボタンを押して入力を終了する。

入力された位置が正しければ、本人確認プロバイダは、その回答を正解とする。ただし、ここでは上記実施例のように正解と不正解という結果ではなく、上記履歴テーブルに格納してある値と入力された値の差異が小さいほど高い点数として評価される。例えば、上記履歴テーブルに格納してある値と比較して、違いが２０ｍ以内であれば１０点とする。また、２０ｍ乃至１００ｍ以内であれば９点とする、といった具合である。ただし、過去に遡れば難易度が高くなると考えられるので、時間的に離れている程、評価点数を高くするようにする。

地図の表示は、ユーザーは、適宜ピンチインやピンチアウト等によって、縮尺率を変更したり、ドラッグによってずらせたりする。例えば、その日時に外国へ出張していた場合は、図１５の表示からピンチインしたりドラッグしたりして海外へ移動して、必要な表示を行う。また、ユーザーは、余り記憶が定かで無い場合には、例えば図１７のような縮尺率のところでＯＫボタンを押して入力を終了してもよい。この場合、クリック位置自体は正しくても、評価は１、２点といった低い点数しか与えられない。正しい位置が表示されていない状態で入力を終了した場合には、マイナスの評価点数を与える。質問は最大５回まで行い。例えば、評価点数の合計が２０点を超えたら、本人確認プロバイダは、本人確認に成功したと判断する。

以下、本人として認証されれば、本人確認プロバイダはその旨を証明する電子証明書（ＲＳＡ、ＥＣＤＳＡなど）を生成し、サービスプロバイダのＵＲＬへリダイレクトする。この電子証明書では、ユーザーＩＤと認可ＩＤを関連付けて本人認証を行なっている。サービスプロバイダは、この電子証明書を本人確認プロバイダの公開鍵を用いて検証し、成功すればユーザーＩＤのユーザーとしてログオンを許可する。これは、実施例１と同様である。

上記実施例３では、「○月△日□時に何処へいたか？」といった１つの居場所に関する質問を行っている。それに対して、この実施例４では、１つの位置ではなく複数の位置からなる移動パターンとしての回答が求められる。例えば、本人確認プロバイダは、「ユーザー名を入力して、本日午後１時以降の所在地を３点、時系列的に、なるべく細かく指定して下さい」といった質問を行う。その他の処理は、実施例３と同様である。

この質問を受けて、ユーザーが、図１９に示したように地図上の位置Ｐ１、Ｐ２、Ｐ３を、この順番でクリック（タップ）したとする。その場合、そのユーザーは、１１月３日午後１時頃、Ｐ１にいて、その後Ｐ２へ移動し、そこから更にＰ３へ移動したことを移動パターンとして入力したことになる。

この回答を受けて、本人確認プロバイダは、ユーザーの履歴データベースを参照して、１１月３日午後１時頃に位置Ｐ１、Ｐ２、Ｐ３に対応する移動パターンが存在するか否かを確認する。そのような移動パターンが存在すれば高い評価点数、例えば１０点を与える。３つの位置は正しいが、移動パターンの順序が違っている場合は、低い評価点数、例えば５点を与える。１つの位置は誤っているが、２つの位置が正しい場合は、より低い評価点数、例えば３点を与える。１つの位置だけが正しい場合は、１点を与える。すなわち、パターン類似の程度によって、評価点数の増減を行う。

ここでは１つの質問で３つの所在地を回答することになるので、質問の回数は実施例３の場合よりも少なくても良い。例えば、質問は最大３回まで行う。そして、評価点数の合計が所定の点数（例えば１０点）を超えたら、本人確認プロバイダは、本人確認に成功したと判断する。

この実施例では、移動パターンというやや難度の高い質問となっているので、余り古い記録では正解を出すのは困難である。従って、高々数日以内、例えば３日以内の位置情報履歴から、３点の移動パターンが明確なようなレコードを検索して質問を生成するようにするとよい。例えば、選択した３点の位置が近すぎる場合や、滞在時間が短かったりする場合は、選択をやり直すようにする。

また、移動パターンの範囲を、ユーザーが予め設定できるようにしてもよい。例えば「５分前から１０分前の３０ｍ以内の移動」や「現時刻から５分前迄」あるいは「５分前から現在までの移動」といったように、そのユーザーの行動傾向に合わせて、最も効果的な設定が行える。しかし、この本人確認プロバイダは、必要に応じてこの設定とは異なる質問の生成を行うこともできる。例えば、現在の場所で１時間以上動いていない場合、質問は生成できない。そのような場合には、１時間よりも前の記録から質問を生成することになる。

上記移動パターンは、一筆書きのように、指（又はカーソル）を滑らすようにして３点を連続して行うことも出来る。この方が、数十分前程度の記憶の範囲であれば、素早く入力を行える。また、この場合、２つの位置の移動のスピードに意味を与えることもできる。例えば、位置Ｐ１から位置Ｐ２へは車での移動で、位置Ｐ２から位置Ｐ３へは徒歩であれば、位置Ｐ１から位置Ｐ２へは速くなぞり、位置Ｐ２から位置Ｐ３へはゆっくりとなぞるようにする。本人確認プロバイダは、このスピードを検出し、評価点数に反映させる。

また、筆圧感知が可能な端末からの本人確認では、入力の際の筆圧も本人確認プロバイダへ送信される。例えば、滞在時間が長い場合は強く押すようにし、滞在時間が短い場合は弱く押すようにする。本人確認プロバイダは、この筆圧を検出し、評価点数に反映させる。

更に、特定のビルを指定する場合、そのビルの何階にいたかという情報も加えることが出来る。階数の指定を可能とする場合、図２０に示したように、地図の表示されている画面にトラックバーを設けておく。そして、入力した１つの位置が選択されている状態で、それをスライドさせて指定すれば良い。階数が合っていれば、評価点数を増加させる。

更に、認証を行う端末のモニター（タッチパネル）に指紋センサーを設けて、上記本人確認と併用して指紋認証を行っても良い。この場合、指による位置入力の際に指紋の検出も行い、予め登録されている指紋情報と照合することでスコアを算出し、このスコアと上記本人確認の評価点数を組み合わせて認証の可否を判断するようにする。これにより本人確認のセキュリティが更に向上する。同様に、指紋認証の替わりに静脈認証を上記本人確認方法と組み合わせても良い。

上記実施例では、携帯通信機器にインストールされた常駐プログラムが、現在位置情報を定期的に測位し、それを本人確認プロバイダのサーバーへ送信し、このサーバーで位置情報履歴を管理するようにしている。しかし、サーバーへ送信せずに、携帯通信機器内部で位置情報履歴を管理するようにしてもよい。

この場合は、携帯通信機器のシステムそのものへのログインに利用する。例えば、携帯通信機器を立ち上げた際に、上記実施例のような本人確認を行い、それに成功した場合に携帯通信機器が利用できるようにする。同様に、携帯通信機器が待機状態にある場合に、そこから動作状態へ復帰する際（ロック解除）に、本人確認を行い、それに成功した場合に携帯通信機器が利用できるようにする。

この方法は携帯通信機器以外の機器に対しても応用出来る。例えば、自動車や重機といった人間が操作し移動するものにＧＰＳ受信機を設置し、始動にあたって上記実施例のような本人確認を行う。すなわち、自動車や重機の移動経路に関する質問を表示して、本人確認を行う。それに成功した場合にだけ、操作（運転）ができるようにする。工作機械の場合には、位置情報履歴の代わりに作業履歴を管理するようにし、作業履歴に関する質問によって本人確認を行ってもよい。例えば、何時、何を、どれ位製造したか、といった内容に関する質問を用いる。そして、正しい回答を得られれば作業員本人であると確認し、工作機械を起動するようにしても良い。

上記実施例１乃至実施例４では、携帯通信機器からユーザーの位置情報が常にサーバーに記録され蓄積されていく。位置情報履歴というのはユーザーのプライバシーに関わるものなので、これを嫌うユーザーも多数存在すると考えられる。従って、この実施例６では、このようなユーザーのプライバシーを配慮した実装を行うようにする。

この目的のために、携帯通信機器から送信されるユーザーの位置情報は、暗号化してからサーバーへ送信される。以下、その暗号化の方法と暗号化された位置情報の利用方法を、図２１乃至図２３を参照して詳しく説明する。上記実施例１と同様に、この本人確認プロバイダによる本人確認サービスの利用を希望するユーザーは、常駐プログラムを本人確認プロバイダのサーバーからダウンロードして、携帯する携帯通信機器にインストールしておく。

この常駐プログラムを利用する際には、初期設定として暗号鍵を決定する。この暗号鍵としては、例えば、ユーザーが指定した文字列をＳＨＡ−１といったハッシュ関数で処理し、その上位１２８ビットを用いる。又は、常駐プログラムが乱数を生成して、それを暗号鍵としても良い。下記の通り、一旦暗号鍵の設定を行えば、その後の処理においてユーザーは特に意識する必要はない。

その後、この常駐プログラムは、現在位置情報を定期的に測位して、経緯度のデータを得る。この経緯度のデータは、緯度３２ビットと経度３２ビットの６４ビットの情報であり、上記暗号鍵を用いて暗号化され、その時の現在時刻である時間情報と共に本人確認プロバイダのサーバーへ送信する。

図２１に示したように、この暗号化方法は次のように行われる。先ず、現在時刻を秒単位の６４ビットＵＮＩＸ時間（「ＵＮＩＸ」は登録商標）として、そこに１２８ビットの暗号鍵を連結し、都合１９２ビットのデータとする。この１９２ビットのデータを、ハッシュ関数（ここではＳＨＡ−１）で処理し、その出力である１６０ビットのハッシュ値の上位６４ビットを暗号化用ビット列とする。そして、この暗号化用ビット列と６４ビットの経緯度情報との排他的論理和として、暗号化経緯度情報を算出する。この暗号化経緯度情報は、現在時刻と共に１２８ビットの現在位置情報レコードとして送信される。

このような暗号化方法では、すべての経緯度には異なる現在時刻が付加されているので、同一の経緯度で送信されたレコードであっても、全く異なる情報として送信される。従って、サーバーで蓄積される経緯度情報は、暗号鍵がなければ、互いに相関のない単なる乱数の集まりのようになる。

この１２８ビットの位置情報レコードは、正しい現在位置情報（真現在位置情報）を含んでいるが、更に、この常駐プログラムは、偽現在位置情報を含む１２８ビットの位置情報をも生成する。生成方法は真現在位置情報と全く同一であるが、正しい経緯度とは異なる偽の経緯度を適宜選択して用いている。

偽現在位置情報は、真現在位置情報と交互に送信されるが、サーバー側で真偽が判断できるようにしている。例えば、真現在位置情報では現在時刻を示す時間情報を偶数とし、偽現在位置情報では現在時刻を示す時間情報を奇数とする。これは必要に応じて、付加する現在時刻を一秒増加させることで行う。なお、ここでは、５分間隔で真現在位置情報と偽現在位置情報を交互に送信するものとする。

サーバーは、これら真現在位置情報と偽現在位置情報を受信し、ユーザーＩＤと関連付けて、真現在位置情報と偽現在位置情報とを区別してデータベースに蓄積する。真現在位置情報と偽現在位置情報の各レコードは、時間情報と暗号化された経緯度情報のフィールドを含んでいる。

実装では、時間情報は５分間隔と決まっているので、時間情報のフィールドは省略できる。具体的には、図２２に示したように、６４ビットを単位とする最初のアドレス（０番目のアドレス（インデックス））に最初の位置情報レコードに付加されている時間情報を書き込む。図２２では、ＵＮＩＸ時間で０ｘ５２７４９７３ａが書き込まれている。なお、図２２では、説明のために便宜上平文のデータが記載されている。しかし、実際に本人確認プロバイダのサーバーに記録されているのは、これらデータは暗号化されており、無意味で相関のない乱数の羅列のようになっている。

この最初の位置情報レコードに含まれる経緯度情報は、真現在位置情報の経緯度情報であり、次の１番目のアドレスに書き込む。経緯度情報の書き込まれる６４ビットの記録領域の内、上位の３２ビットには緯度を書き込み、下位の３２ビットには経度を書き込む。そして、５（Ｎ＋１）分後の経緯度情報は、Ｎ番目のアドレスに書き込むようにする。携帯通信機器からの位置情報の送信がない場合、対応するアドレスには０を格納しておく。このような記録方法により、アドレスが奇数の位置情報レコードは真の経緯度情報を含むものであり、アドレスが偶数の位置情報レコードは偽の経緯度情報を含むものとなる。

次に、このサーバーを利用した本人確認方法を説明する。まず、ユーザーは、ブラウザで、図１２に示したようなサービスプロバイダのログオン画面へアクセスする。このログオン画面には、ユーザーＩＤを入力するフォームが含まれており、ユーザーＩＤを入力した後に送信ボタンを押すと、認証要求が本人確認プロバイダへリダイレクトされる。この認証要求には、このユーザーＩＤと共に、このサービスプロバイダのＵＲＬと認可ＩＤが添付されている。

この認可ＩＤはユーザーＩＤと本人確認プロバイダに関連付けられており、サービスプロバイダが発行する。そして一定の有効期間（例えば、２０分）が設けられており、この有効期間内に、ログオン処理を完了する必要がある。ここまでは実施例１による本人確認方法と同じである。以下、ブラウザと本人確認プロバイダとの間で次のような認証プロセスが行われる。

最初に、本人確認プロバイダは、ユーザーＩＤに対応する位置情報履歴データベースの奇数アドレスＡを無作為に抽出して、真現在位置情報として受信した一対の経緯度を真位置情報レコードとして取得する。そして、この位置情報履歴データベースのアドレスＡ＋１、Ａ＋３、Ａ＋５、Ａ＋７から、偽現在位置情報として受信した４対の経緯度を偽位置情報レコードとして取得する。順序から真偽がわからないように、これら５つの位置情報のレコードをランダムに入れ替える。そして、真位置情報レコードの時間情報と共に、携帯通信機器へ送信する。本人確認プロバイダは、位置情報は暗号されているので、実際の位置は分からないが、何番目の位置情報レコードが真位置情報レコードであるかは分かる。本人確認プロバイダは、入れ替えた５つの位置情報レコードにおける真位置情報レコードの位置を保持しておく。

携帯通信機器は、これら時間情報と共に受信した５つの位置情報レコード、つまり暗号化された経緯度情報を復号する。復号方法は、図２３に示したように、上記暗号化方法の逆である。すなわち、受信した時間情報に暗号鍵を連結し、暗号化の際に用いたハッシュ関数で処理し、その上位６４ビットを暗号化用ビット列とする。そして、この暗号化用ビット列と６４ビットの経緯度情報との排他的論理和として平文の経緯度情報を得る。

この平文の経緯度情報を用いて実施例１と同様の択一質問を生成する。ただし、この実施例６では、質問の生成は、携帯通信機器側の常駐プログラムが実行する。携帯通信機器のユーザーは、何番目の経緯度情報が正しいかを回答として、本人確認プロバイダへ送信する。実施例１による本人確認方法と同様に、例えば、同様の質問に５問答えて、３問以上正解なら本人として認証される。

上記本人確認方法において、最初に抽出した真現在位置情報の後から４つの偽現在位置情報が選択されている。従って、位置情報履歴の蓄積の際に、常駐プログラムが真現在位置情報の後に送信する偽現在位置情報は、それよりも前に蓄積された４つの真現在位置情報とは離れた位置情報を含むようにする。従って、常駐プログラムは少なくとも最新の５つの真現在位置情報（経緯度情報）を保持しておかなければならない。このように偽現在位置情報を生成することによって、４つの偽現在位置情報のいずれも偶然正しい位置情報となることがない。

なお、サーバーに保存されているデータは、ユーザーの行動の記録になっており、ユーザー本人にとって有用な情報である。そこで、上記の本人確認が行われた後、ユーザーが望めば任意の日時を指定して、位置情報レコードを取得出来るようにしても良い。このようにすることで、位置情報履歴が、ユーザーにとっての備忘録の１つとなりえる。また、上記暗号化を用いた方法では、ユーザー本人は何時でも自分の位置情報履歴を取り出すことができるので、備忘録以外にも、様々な応用の余地が残されている。

このように経緯度情報を暗号化してから送信することで、行動履歴という個人情報の漏洩のリスクを回避し、ユーザーのプライバシーを守ることが出来る。すなわち、サーバーに保存されているデータは、ユーザー本人以外には、単なる乱数の羅列としての意味しか無く何の情報も得られないものである。また、万一、暗号キーが第三者へ漏れても、サーバーからの問題の意味が分かるだけで、正解は分からない。従って、不正ログオンは不可能である。

以上の説明から明らかなように、第三者が、ユーザーになりすまして、本人確認を成功するには２段階のセキュリティをクリアする必要がある。まず、何らかの方法を用いて、サーバーへ侵入し、ユーザーのデータベースを取得する。これで暗号化された経緯度情報を得る。次に、ユーザーの携帯通信機器へ侵入し、常駐プログラムが利用する暗号鍵の位置を特定し、そこへのアクセスに成功し、暗号鍵を取得する。これによりサーバーのデータを平文にし、真位置情報レコードのみを取り出す。この２段階のいずれか一方だけでも困難であり、両方をクリアするのは極めて難しいので、情報は十分に秘匿されていると考えられる。

この実施例では、携帯通信機器にインストールされた常駐プログラムが、現在位置情報を定期的に測位するという点では、実施例１と同様である。ただし、ここでの測位結果は、当該携帯通信機器内のデータベースに保存される。このデータベースの構成は、図２の一つの履歴テーブルと同じである。現在位置情報の記録方法は、記録場所が各携帯通信機器である点、現在位置情報テーブルを用いない点を除いて、実施例１と同じなので詳細は省略する。

すなわち、図１の携帯通信機器３Ａにインストールされた常駐プログラムは、ＧＰＳ等により得た現在位置情報を、携帯通信機器３Ａのメモリへ保存する。また、携帯通信機器３Ｂにインストールされた常駐プログラムは、ＧＰＳにより得た現在位置情報を、携帯通信機器３Ｂのメモリへ保存する。また、実施例２の常駐プログラムは、実施例１と同様の位置情報履歴照合機能を備えている。

次に、実際の利用シナリオに従って、この実施例の共通点提供方法の機能を説明する。なお、図２４に全体の信号の流れが示されている。例えば、携帯通信機器３Ａを利用するユーザーＡが、パーティーに出席しており、携帯通信機器３Ｂを利用するユーザーＢと初対面であったとする。ユーザーＡは、位置情報履歴照合を行う旨の提案をする。ユーザーＢは了解し、Bluetooth（登録商標）、Wi-Fi Direct等の通信手段により、互いの位置情報履歴の交換を行う。具体的には、先ず携帯通信機器３Ａは、位置情報履歴の交換要求を携帯通信機器３Ｂに送信する。これに対して、携帯通信機器３Ｂは、その要求内容を表示するので、ユーザーＢはＯＫボタン(図不示)を押す。そして互いの位置情報履歴の交換を行う。

携帯通信機器３Ｂの位置情報履歴を受信した携帯通信機器３Ａは、自機に記録されている位置情報履歴と比較照合し、相関関係のあるレコードを抽出する。そして、相関の高いものから並べて表示する。その方法は実施例１と同じであり、図６に示されたリストをその表示例とすることができる。履歴比較照合処理は、夫々の携帯通信機器の常駐プログラムが行う。尚、位置情報履歴データの量が大きい場合には、照合対象データは、履歴の全てではなく直近のデータのみとしても良い。

携帯通信機器３Ａの位置情報履歴を受信した携帯通信機器３Ｂも、同様の処理を行うので、ユーザーＡとユーザーＢは同様の表示を見ることになる。そして、お互いの共通点を手掛かりに、話が弾む可能性が出てくる。すなわち、相関関係で抽出された位置情報履歴が、現実世界のアイスブレーカーとなり得る。

この実施例２は、セキュリティという点で望ましい実装となっている。すなわち、位置情報履歴照合サーバーといったところにユーザーの位置情報履歴情報が集中的に管理されていると、万一漏洩事故が起こった際にはシステムの信頼性が大きく損なわれる。しかし、実施例２では、ユーザーＡとユーザーＢの信頼関係と自己責任というリスクに限定される。

この共通点提供方法では、互いに位置情報履歴を比較することで、一方のユーザーに、他方のユーザーとの共通の興味に関する情報を提供している。しかし、ユーザー間の共通点に関する情報を抽出するのに、位置情報履歴だけではなく他の情報も利用することが出来る。このような情報源としては、ＷＥＢ閲覧履歴、ブラウザのお気に入り登録項目およびアドレス帳の登録項目がある。例えば、図２５のようなダイアログから、情報源の選択を行うことができる。ＷＥＢ閲覧履歴が選択された場合、２つの携帯通信機器のＷＥＢ閲覧履歴から、双方に存在するＵＲＬを検索する。但し、検索エンジンのＵＲＬは除外する。そして、検索されたＵＲＬからダウンロードして、そのタイトルを共通点に関する情報として表示する。お気に入り登録が選択された場合、２つの携帯通信機器のお気に入り登録を比較し、共通のＵＲＬのタイトルを表示する。アドレス帳が選択された場合、その登録項目を比較することで共通する知人を見出すことが出来る。この場合、この共通する知人が携帯通信機器に表示されるが、当該携帯通信機器での登録名で表示される。

また、上記情報交換方法は、プライバシーという観点からも好ましい。例えば、釣りの好きなユーザーの釣りに関する情報は、やはり釣りの好きなユーザーにしか表示されない。つまり、共通点に関する情報しか交換されない。なお、ＷＥＢ閲覧履歴、ブラウザのお気に入り登録項目およびアドレス帳の登録項目のいずれにも共通点が存在しないことも少なくない。従って、どの情報源を選択していたかは他方のユーザーには分からない。

なお、上記項目に他にも、適当なユーザー固有の情報も共通点抽出項目として利用できる。そのような共通点抽出項目としては、例えば、予定表のデータなどがある。予定表では、位置情報の他にもユーザーの興味に関係する情報も含まれている可能性がある。

この実施例では、携帯通信機器にインストールされた常駐プログラムが、現在位置情報を定期的に測位し、当該携帯通信機器内のデータベースに保存するという点では、実施例２と同様である。ただし、位置情報履歴を比較照合し相関関係を抽出するのは、位置情報履歴照合サーバーが行う。この位置情報履歴照合サーバーは、受信した位置情報履歴の比較照合を行うのみで、位置情報履歴の蓄積は行わない。

実際の利用シナリオの例は次のとおりである。図２６に全体の信号の流れが示されている。やはり、携帯通信機器３Ａを利用するユーザーＡが、パーティーに出席しており、携帯通信機器３Ｂを利用するユーザーＢと初対面であったとする。ユーザーＡは、位置情報履歴比較を行う旨の提案をする。ユーザーＢは了解し、Bluetooth、Wi-Fi Direct等の通信手段により、携帯通信機器３Ａからの位置情報履歴の交換要求を、携帯通信機器３Ｂで受信する。この際、携帯通信機器３Ａと携帯通信機器３Ｂは、互いの端末ＩＤも受信する。

次に、携帯通信機器３Ａと携帯通信機器３Ｂは、当該携帯通信機器内に蓄積されている位置情報履歴を位置情報履歴照合サーバーへ送信する。その際に、夫々自機の端末ＩＤと相手方の端末ＩＤも添付しておく。これらのデータを受信した位置情報履歴照合サーバーは、位置情報履歴の相関関係のあるレコードを抽出する。そして、相関の高いものから並べて表示する。その方法は実施例１と同じであり、図６をその表示例とすることができる。

ユーザーからみた実施例４の機能は、実施例２とほぼ同様であるが、位置情報履歴は位置情報履歴照合サーバーのみに送信され相手方の端末へは送信されない。相手方の端末へ送信されるのは、共通点に関するデータのみである。また、位置情報履歴照合サーバーには位置情報履歴は蓄積されない。従って、初対面同士でも、比較的気軽に利用できる。この場合も、位置情報履歴データの量が大きい場合には、照合対象データは、履歴の全てではなく直近のデータのみとしても良い。

この実施例９では、実施例１の位置情報履歴データベースを、ユーザー同士の情報交換に利用するというものである。具体的には、2011年08月28日のジャズ・コンサートの終了時間を知りたいとする。その場合、図２７に示したような常駐プログラムのユーザー検索画面を利用する。例えば、図５のユーザー検索ボタンをクリックすることによって、図２７に示したようなユーザー検索画面が表示される。

ユーザー検索画面では、場所、日付、時間および滞在時間を検索タームとして入力することができる。例えば、ここで横浜市本牧市民公園、2011/08/28と入力して検索ボタンをクリックすれば、検索要求が位置情報履歴照合サーバーへ送られ、検索タームにヒットするユーザーのレコードが抽出される。例えば、図２８に示したようなユーザー検索結果が表示される。この検索結果は、入力された検索タームに近いものから滞在時間の長いものを優先的に表示される。

ここで、端末IDである"415bfa41"の項目をクリックすると、図２９に示したようなメッセージ編集の画面に切り替わる。そこでメッセージを入力して、送信ボタンをクリックすると、端末ID "415bfa41"の携帯通信機器へメッセージが送信される。これに対して、図３０のような返信がある。このようにすることで、ある特定の場所と時間における情報を得る新たな手段が提供される。

上記例では、ユーザー同士のその場限りのメッセージのやり取りとなっている。これを掲示板でのやり取りとすることで、情報をより有効に活用できる。この掲示板は、一般的な掲示板の機能に加えて、次のような追加機能が付加されている。すなわち、メッセージを投稿する場合には、質問メッセージであるか、通常メッセージであるかを選択する。質問メッセージであれば、日付と場所を指定しておく必要があり、日付と場所がそのままスレッド名となる。図３１に、質問メッセージ編集画面の例を示す。この例では、「2011/08/28：横浜市本牧市民公園」がスレッド名となっている。

また、質問メッセージが投稿された場合、掲示板システムは、位置情報履歴からその日付と場所を検索し、該当するレコードを含む位置情報履歴のユーザーを特定する。そして、そのユーザーの携帯通信機器が、常駐プログラムが位置情報を送信する為に定期的にサーバーへアクセスした際に、サーバーから常駐プログラムへ通知され、図３２に示したように掲示板の当該質問メッセージのスレッドが表示される。

掲示板のスレッドに表示されている投稿ボタンを押せば、図３３に示したような返信メッセージ編集画面が表示される。ここから、質問に対して回答を行うことが出来る。掲示板のスレッドに表示されている検索リンクを押せば、図３４のような検索画面が表示される。この検索画面から、ある特定の場所と時間における情報を得ることができる。ここから、ユーザーは質問メッセージを投稿する前に、同じようなスレッドがないかどうか検索することが求められる。

以上、本発明を実施例により詳細に説明したが、当業者にとっては、本発明が本願中に説明した実施例に限定されるものではないということは明らかである。本発明の装置は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。従って、本願の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。

例えば、そのユーザーがビルの中で何階にいるか、といった情報が取得できるような高精度な屋内位置検知システムが利用可能なら、履歴データベースの履歴テーブルにそのような詳細情報も加えておくことも出来る。このような詳細情報を含む位置情報レコードによれば、例えば、ビルのどのオフィスにいたかといったこも分かるようになる。

更に、高度計を実装している携帯通信機器であれば、検出した高度情報に基づいて、ビルの中で何階にいるか、といった情報を得て、上記詳細情報とし て位置情報履歴照合サーバーへ送信することも可能である。

以上のように、本発明による位置情報履歴照合システムによれば、パスワードを必要とせず、クレデンシャルが自動的に変更されるような本人確認手段が提供される。従って、ユーザーは、パスワードの選択や記憶といった面倒な負担から開放され、より安全な本人確認を行うことが出来る。

Ａ、Ｂ ユーザー
１ サーバー
２ 履歴テーブル
３Ａ、３Ｂ 携帯通信機器
５ 衛星
７ 基地局

Claims (8)

1. ユーザーの携帯通信機器から、その携帯通信機器の現在位置情報を受信するステップと、
   前記携帯通信機器の現在位置情報と、その位置に前記携帯通信機器が存在した時間を関連付けて記録することにより、その携帯通信機器の移動履歴に関する情報を収集するステップと、
   前記携帯通信機器の履歴を参照し、この履歴の内容に関する質問を生成するステップと、
   前記質問を前記ユーザーに提示するステップと、
   前記ユーザーから前記質問に対する回答を受け取るステップと、
   前記回答と前記履歴の内容を比較し、両者間の整合性を確認するステップと、
   前記回答と前記履歴の内容に整合性があると確認された場合、本人であると決定するステップとからなる本人確認方法。
2. 前記履歴は、前記携帯通信機器を特定する識別子と関連付けられており、
   前記ユーザーの操作する通信手段から、前記識別子と共に本人確認要求を受信するステップと、
   この本人確認方法により本人であると決定された場合、前記通信手段へ決定内容を通知するステップとを更に含むことを特徴とする請求項１に記載の本人確認方法。
3. 前記通信手段は、前記携帯通信機器または前記携帯通信機器以外の通信手段のいずれかであることを特徴とする請求項２に記載の本人確認方法。
4. 前記質問は、前記ユーザーに地図を表示し、その地図上の位置として回答を求めるものであることを特徴とする請求項３に記載の本人確認方法。
5. 前記質問は、地図上の複数の位置として回答を求めるものであることを特徴とする請求項４に記載の本人確認方法。
6. 前記質問は、地図上の複数の位置と共にその順序として回答を求めるものであることを特徴とする請求項４に記載の本人確認方法。
7. 前記携帯通信機器から受信する現在位置情報は、暗号化されていることを特徴とする請求項５に記載の本人確認方法。
8. ユーザーの携帯通信機器から、その携帯通信機器の現在位置情報を受信するステップと、
   前記携帯通信機器の現在位置情報と、その位置に前記携帯通信機器が存在した時間を関連付けて記録することにより、その携帯通信機器の移動履歴に関する情報を収集するステップと、
   前記携帯通信機器の履歴を参照し、この履歴の内容に関する質問を生成するステップと、
   前記質問を前記ユーザーに提示するステップと、
   前記ユーザーから前記質問に対する回答を受け取るステップと、
   前記回答と前記履歴の内容を比較し、両者間の整合性を確認するステップと、
   前記回答と前記履歴の内容に整合性があると確認された場合、本人であると決定するステップと、
   を実行可能な本人確認装置。

Images