JP2016099684A - ライフログを利用した本人確認方法および本人確認装置 - 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や受信感度は補助データとして、経緯度の信頼性などに利用できる。履歴テーブルの最も新しいレコードの示す位置での滞在時間は、現在位置情報テーブルの対応するレコードの時刻と、履歴テーブルの最も新しいレコードの示す位置での時刻との差分ということになる。また、現在位置における滞在時間は、現在位置情報テーブルの対応するレコードの時刻と現在時刻との差分ということになる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実施例１においては、単純なユーザー認証に本発明の本人確認方法を利用している。しかし、サービスプロバイダが、本人確認を必要とするユーザーに関する別のリソース（例えば、ＳＮＳにおけるユーザーデータ）を利用したサービスを提供したい場合もある。この場合、ユーザーのリソースへアクセスする権利をサービスプロバイダに与えても良いか否かを、本人確認プロバイダが確認することになる。

なお、ユーザーのリソースの管理を、本人確認プロバイダが行う場合もあるし、本人確認プロバイダとは別のサービス提供者がユーザーのリソースを管理するサービスを提供する場合もありえる。いずれにせよ、上記のサービスプロバイダ、本人確認プロバイダ、別のサービス提供者、および当該携帯通信機器（又は、ユーザーが利用する本人確認の為の処理を行うパソコンなどの通信手段）は、インターネットに接続されている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この実施例以降は、位置情報履歴だけではなく、その他の広い意味でのライフログデータを活用した本人確認方法および本人確認装置に関する。現在のスマートフォンには、各種センサーなど、非常に多くの機能が搭載されている。この実施例では、特に、スマートフォンから直接得られる情報を、ライフログとして本人確認に利用する。以下、図１８ないし図２５を参照して詳細に説明する。

上記実施例では、位置情報履歴サーバーが、本人確認サーバーとして機能しているが、ここではより一般的にライフログサーバー１０が、インターネットに常時接続して本人確認サーバーとして機能する。すなわち、スマートフォン（携帯端末）１３を携帯するユーザーは、スマートフォンから直接得られる様々な活動の記録（ライフログ）をインターネット経由で本人確認サーバー１０に送信する。本人確認サーバー１０は、ライフログサーバーとして、このライフログを蓄積管理すると共に、各ユーザーのライフログの内容に基いてユーザーの本人確認（認証）を行う。

この本人確認サーバー１０のハードウェアとしての構成は、通常のサーバーを構成するコンピュータと同様であり、以下で詳細に説明する処理を実行するプログラムが実装されている。また、ここでは本人確認サーバー１０が、ライフログサーバーとしてのサービスも行っているものとする。しかし、サーバーを別にするかどうかは、本件発明の技術的な趣旨としては重要ではなく、適宜複数のサーバーに役割を分担してもよい。例えば、本人確認サーバー１０とは別にライフログサーバーを設けておき、本人確認サーバー１０は必要に応じて認証に必要なライフログをライフログサーバーに問い合わせるようにしても良い。

一般的なスマートフォン１３に搭載されているセンサーとしては、上記実施例で利用したＧＰＳ受信機の外に、加速度センサー、ジャイロセンサー（３軸ジャイロスコープ）、方位センサー、気圧センサー、温度センサー、近接センサー、照度センサーなどがある。これらの履歴データは、ライフログのデータとして取得保存される。

加速度センサーは、縦横高さの三方向の加速度を測定するが、重力の方向も分かるので、スマートフォン本体の傾斜角（縦方向の傾き）と回転角（横方向の傾き）の３つの角度も取得できる。これと、電子コンパスで実装されている方位センサーで測定される方位角によって、スマートフォンの向き（姿勢）が特定される。また、ジャイロセンサーは、スマートフォン１３の回転速度を検出する。すなわち、スマートフォン１３の中心を原点として、３次元空間のそれぞれの空間軸について、回転速度を単位rad/s（ラジアン毎秒）で測定する。

しかし、スマートフォン１３によって搭載されているセンサーの種類は異なっている。また、状況によって取得が難しかったりすることもある。従って、測定可能なもののみが取得管理される。可能なら、代替手段によって対応するデータで代用する。例えば、後述のように、気圧センサーが利用できなければ、気象情報を提供するサーバーにアクセスし現在地情報から気温を得る。また、ＧＰＳの利用ができなければ、基地局による三角測量や、WIFIによる位置の取得を行う。

このようにセンサーなどのスマートフォン１３自体の測定手段によらず、代替手段によってデータが取得された場合には、信用度は若干低いと考えられる。従って、データ取得手段も記録しておくと、より信頼性の評価精度が高まる。

次に、本人確認サーバー１０が管理する具体的なライフログの取得管理方法を説明する。スマートフォン１３にインストールされているユーティリティプログラム（常駐プログラム）は、定期的に衛星１５を利用したＧＰＳまたは基地局１７による現在位置情報を取得する。同時に、内蔵センサー類、具体的には加速度センサー、ジャイロセンサー、方位センサー、気圧センサー、温度センサー、近接センサー、照度センサーの出力を取得して、履歴データベースに保存する。

例えば、この履歴データベースには、記録の行われた日時と、現在位置情報として、緯度、経度、その時に通信を行なっている基地局７を特定するCell-IDと、受信感度が取得され、上記実施例で示した通り履歴の蓄積管理が行われる。この実施例では、更に加速度、角加速度、傾き、気圧、方位、温度、近接、照度のデータを保存する為のフィールドも設けられている。図１９では、現在位置情報は、１つのフィールドで表されているが、そこに格納されている値は上記の通り複数の要素からなっている。その他のデータも同様である。

そして、数分毎（例えば、５分毎）に現在位置を測位し現在位置情報を取得し記録するが、それと同時に、方位センサー、気圧センサー、温度センサー、近接センサー、照度センサーの出力を取得し記録する。

それとは別に、加速度センサーのデータは、常時その変化をモニターするようにする。そして、加速度に変化があった際に、加速度センサーの出力変化の推移を計測する。例えば、スマートフォン１３を机においている間や、就寝中などは、データの取得は行わない。また、加速度に変化があった場合には、加速度センサーの出力だけではなく、同時に、角加速度センサー、方位センサー、近接センサー、照度センサーの出力変化の推移も計測する。そして、スマートフォン１３を携帯するユーザーの動きを推測して記録する。

具体的には、それらセンサーの出力変化の推移から推定して、静止、屋内での作業、歩行、自転車走行、乗車中、スポーツ活動・・・睡眠中などに分けて、それらに例えば０，１，２，３，４，５，６，・・・といった数値を割り当て、モーションコードとして記録する（図２０参照）。

また、この実施例では、モーションコードが変化した時に記録を行うようにする。例えば、地下鉄に２０分乗ってから降りて歩いたとすれば、地下鉄に乗った時刻に乗車中のモーションコードを１レコードとして記録し、次に降りて歩いた時刻に歩行のモーションコードをその次の１レコードとして記録する。また、現在位置情報も取得して、夫々のレコードに記録しておく。

気圧センサーのデータは、その位置における気圧を検出して記録する。例えば、ユーザーのいる場所の天候に関する付随情報として利用できる。履歴データベースには、この気圧データに加えて、インターネット上のサービスから得られる気圧データも併せて記録しておく。このようなインターネット上のサービスとしては、例えば気象庁の発表する市町村レベルのものがある。

更に、クラウドソーシングサービスとしてユーザーレベルのきめの細かい情報もある。例えば、プロジェクト（公序良俗違反につき、不掲載）では、スマートフォンに搭載されているＧＰＳと気圧センサーの情報を、各ユーザーから受信し、そのデータに基いて、場所ごとのリアルタイムの気圧情報を提供している。スマートフォン１３が気圧センサーを搭載していない場合には、現在位置に対応するこの気圧情報を記録しておく。また、スマートフォン１３が気圧センサーを搭載している場合でも、実測値とは別途この気圧情報を記録しておいてもよい。

また、クラウドソーシングサービスの中には、各ユーザーが自分が今いる地点の天気をアイコンタップで入力して、各地の現在天気が把握できるようになっているものもある。この場合、リアルタイムに近い現状の天気を得ることが出来る。この天気情報（晴れ、薄曇り、曇り、雨模様、本降りなど）も、ライフログのデータとして取得保存する（図では天候フィールド）。ただし、このようなインターネット上の情報は、必要に応じてその都度取得するようにして、履歴データベースのデータ量を削減するようにしても良い。

温度センサーのデータは、一般に外気温よりも高い値を示す。これはスマートフォン１３自体の発熱やユーザーの体温の影響を受けるためである。従って、外気温を推定する補助データとして利用したり、スマートフォン１３の使用状況や、ポケットに入っているか机に置かれているかなど保存状況を推定する補助データとして利用する。やはり、この温度データに加えて、現在位置に対応して、インターネット上のサービスから得られる気温データも併せて記録しておく。

近接センサーの出力は、スマートフォン１３の近接センサーの位置（例えば画面正面）の近傍（例えば数センチ以内）に、何かが存在しているか否かを示している。従って、例えば、ユーザーがスマートフォン１３を耳に当てているかどうかをチェックするのに利用される。しかし、このデータを利用することで、温度センサーのデータと共に、スマートフォン１３の使用状況や、ポケットに入っているか机に置かれているかなど保存状況を推定する補助データとして利用する。また、通話状態の履歴と併せて手ぶら通話をしているかどうか、といった情報も得られる。

照度センサーのデータは、周囲の明るさを示している。従って、スマートフォン１３の置かれている状況に関する情報が得られる。炎天下で使用していたか、室内で使用していたか、ポケットに入っていたか、夜就寝している間、暗い中に置かれていたか、といった情報が得られる。

更に、スマートフォン１３とパソコンによる当該ユーザーのＷＥＢサイトの閲覧履歴や、アプリケーションの起動履歴や、ブラウザで保管しているお気に入りのサイト情報の推移も、ライフログのデータとして保存する。この場合、パソコン側にも対応するユーティリティプログラムがインストールされており、このユーティリティプログラムが履歴データを本人確認サーバー１０へ送信する。ただし、このようなデータは、ユーザー自身でも記憶が曖昧だったりするので、何度も閲覧しているサイトを当てさせる、といったものとし、簡易的な認証にだけ利用するようにする。

このようなライフログは図２１に示したようなデータベースに保存される。ここで操作が実行された際に１つのレコードが生成され、夫々のレコードは、日付および時刻、操作コードと、操作データからなっている。操作コードは、パソコンとスマートフォンを区別し、ＷＥＢサイトの閲覧、アプリケーションの起動、お気に入りの変更などの操作内容をコードで表現したものである。また、操作データは、閲覧したＵＲＬ、アプリケーション名、お気に入りに登録または抹消したＵＲＬなどである。

更に、スマートフォン１３による通話記録に関する履歴データも本人確認サーバー１０へ送信する。この通話記録に関しては、通話相手の情報だけではなく通話内容も全て録音し、音声認識により対応するテキスト情報も併せて記録保存される。

このようなライフログは図２２に示したようなデータベースに保存される。ここで通話が実行された際に１つのレコードが生成され、夫々のレコードは、日付および時刻、通話時間、通話相手、電話番号、通話の成否、通話内容（音声認識テキスト）へのポインタ、通話録音データへのポインタからなっている。ここで通話内容や録音データは、夫々へのポインタを使ってアクセス可能なように別途保存されている。

しかし、通話内容を含む通話記録は、特にプライベートな情報である。従って、上記の通り、非省略の情報ではなく、ユーザーの設定によって適宜部分的なものとすることが望ましい。例えば、後述の通り、図３７に示したようなダイアログボックスを表示し、内容をユーザーが任意に選択できるようにする。この図で、通話時刻とは、新たな通話を開始した時刻である。また、通話時間とは、通話を継続した時間の長さであり、これが選択されれば通話時刻が必ず選択される。呼出先の情報は、相手の電話番号でも良いし、相手の登録名でも良い。

更に、スマートフォン１３とパソコンによる当該ユーザーのメールの送受信履歴も、ライフログのデータとして保存する。この送受信履歴は、メッセージソースの各要素、すなわち、送信日時、受信日時、送信および受信相手の名前とメールアドレス、メッセージの件名や本文および添付書類を含む各データ要素を、データベースとして検索可能にしたものである。

このようなライフログは図２３に示したようなデータベースに保存される。ここでメールの送受信が行われた際に１つのレコードが生成され、夫々のレコードは、日付および時刻、相手、メールアドレス、メッセージ内容へのポインタからなっている。ここでメッセージ内容は、ポインタを使ってアクセス可能なように別途保存されている。

次に、上記ライフログのデータを用いた本人確認の具体例を説明する。なお、処理の流れは実施例１または実施例２で説明したものと同じであり、質問の内容のみが異なるので、その質問のみを以下に説明する。上記ライフログの場合、余り古いデータでは、覚えていないことが多い。従って、遡ってもせいぜい数日前程度の履歴から認証用の質問を行うようにすると良い。この質問に対する回答を採点し、採点結果が規定レベルにあれば本人確認を成功させる。

図２４や図２５の例では、昨日のライフログから質問を行っている。この質問では、正しい内容を選択するものであり、多くの場合は複数の選択が正しい回答となっている。６項目示されているので、１つの質問でも６項目すべてが偶然正解する可能性は低い（ランダムに回答した場合で２^-6）が、必要に応じて、同様の質問を繰り返しても良い。

また、６項目の全ての選択／非選択が正しくなくとも、５項目が正しければ正解としてもよい。いずれにせよ、その都度違う質問を行うので、６項目の個々の真偽は分からないようになっている。選択された項目は、図に示したように、枠のデザインが変化して選択されていることが視覚的に区別される。

これらの項目は、上記ライフログのデータに基いて、ランダムに作成される。例えば、気圧、温度や天候のデータで雨模様であったことが明白なレコードの中で、加速度や角加速度のデータから外出していたことが明白なレコードがあれば、「雨模様で外出」という真の項目が抽出される。また、傾きのデータと、加速度や角加速度のデータを組み合わせて、スマートフォン１３が使用されていないことが明白なレコードがあれば、「スマホは使わなかった」という真の項目が抽出される。更に、近接センサーのデータや、照度のデータを組み合わせて、スマートフォン１３が出されていないことが明白なレコードがあれば、「ポケットやカバンからスマホは出してない」という真の項目が抽出される。このような真の項目を例えば１０項目抽出し、更にランダムに偽の項目を同数生成し、合計２０項目から、６項目を無作為に選択して、ひとつの質問とする。

実施例７では、スマートフォン１３を中心としたライフログのデータ履歴を取得管理しているが、この実施例８では、家の中の生活の記録もライフログのデータとして取得保存される。具体的には、図２６に示したように、スマート家電と呼ばれるネットワークに接続した家電製品２０の操作・管理に関する履歴データもライフログのデータとして取得され保存管理される。

この場合、スマートフォン１３を操作パネルとして用いる。従来は、家電本体で操作することが普通であったが、スマートフォン１３を利用すればより多くのメリットが存在する。例えば、状況に応じて操作パネルの表示を変更したり、インターネットからの情報収集して表示したり、機能のアップデートが可能であったりする。また、一般に比較的大きな画面で高精細な情報を表示できるということが、その電化製品をより便利で使いやすいものにしている。

スマート家電によるライフログは、スマートフォンのセンサーによるライフログとは別々に扱うだけでなく、相互に関連付けることが可能である。例えば、ライフログデータの関連付けにより、「夜８時に帰宅する前に、駅からエアコンを何度に調整した」とか、「家族へ通話した後でお風呂のスイッチを入れた」といった情報が得られる。

また、方位センサーのデータは、加速度センサーの出力と組み合わせて、スマートフォン１３がどの方角を向いているかを検出できる。例えば、スマートフォン１３で家電製品を操作する場合、ユーザーはなるべくその家電製品にスマートフォン１３を向けるようにする。そして、その操作履歴とスマートフォン１３の向きを関連付けることで、逆にスマートフォン１３の方向から、向けられた家電製品を推定することも可能となる。この関連付けを学習し記録しておく。

このような学習により、スマートフォン１３を家電製品へ向けるだけで、リモコン画面の初期表示を決定するといったこともできる。具体的には、加速度センサーの検出データの変化をモニターするようにする。そして、加速度に変化があった際に、方位センサーの出力から方向を算出して対応する家電製品を操作する為のリモコン画面を自動で表示するようにする。

この実施例では、スマートフォン１３にインストールされているユーティリティプログラムは、スマートフォン１３を用いた家電製品（スマート家電）の操作情報（操作履歴）や、家電製品から得た各種データを、インターネット経由で本人確認サーバー１０へ送信する。また、本人確認サーバー１０には、スマートフォン１３から送信されたデータを受信し、データベースに保存し管理するプログラムが実装されている。

家の中にあるそのような家電製品には、エアコン、冷蔵庫、テレビ、ビデオレコーダ、洗濯乾燥機、炊飯器、電子レンジなどのネットワークに接続可能な電化製品の全てであるが、外にも玄関鍵や自動車などでも、ネットワークに接続可能なものがあり、そういったものも履歴データとして収集管理する。例えば、何時帰宅したかとか、自動車の走行履歴などが収集対象となり得る。

なお、これらの生活家電は家庭内の有線ＬＡＮ（多くの場合イーサネット（登録商標））またはＷＩＦＩなどの無線ＬＡＮによって、スマートフォン１３と通信を行う。また、これらの生活家電は、上記有線または無線ＬＡＮを介して、インターネットへも接続し、スマートフォン１３を介すること無く直接インターネットへ接続し、本人確認サーバー１０と通信を行うこともできる。

ネットワーク対応の冷蔵庫では、スマートフォン１３をリモコンとする設定温度の変更や、扉の開閉、保管されている食品の状況やその変化、が履歴情報として収集される。また、履歴情報の収集方法としては、冷蔵庫から直接インターネットを介して本人確認サーバー１０へ送信する場合と、冷蔵庫を介すること無くスマートフォン１３から直接インターネットを介して本人確認サーバー１０へ送信する場合がある。後者の場合としては、例えば、スマートフォン１３をリモコンとして冷蔵庫を操作するような場合がある。

冷蔵庫で保管されている食品の状況やその変化を、自動で検出記録することは難しい。なので、多くの場合は、ユーザーが手入力により記録することになる。ＱＲコード（登録商標）が利用可能なら、幾分入力は楽になる。いずれにせよ、手入力により記録されて情報は、本人確認サーバー１０へ送信されそこで管理される。この場合、保管食品の状況の履歴に関しては、ネットワークに非対応の冷蔵庫であっても、スマートフォン１３から履歴データを本人確認サーバー１０へ送信し管理できる。

ネットワーク対応のエアコンでは、スマートフォン１３をリモコンとする設定温度の変更や、外出先からスマートフォン１３による遠隔操作やタイマー予約や、電気代の管理などが可能となっている。これらのエアコンに対するスマートフォン１３による操作の履歴が本人確認サーバー１０へ送信され管理される。

更に、現在の室温や運転状況が、エアコン側からスマートフォン１３へ送られる。このエアコン側情報は、スマートフォン１３から更に本人確認サーバー１０へ送信されそこで管理される。勿論、エアコンから直接インターネットを介してこのエアコン側情報を本人確認サーバー１０へ送信することもできる。

ネットワーク対応の洗濯乾燥機は、スマートフォン１３をリモコンとして操作が可能となっている。また、インターネット経由で、洗濯終了の通知や、故障予知、乾燥フィルターの詰まりの通知を、スマートフォン１３で受信することもできる。これらの操作情報や通知情報が、洗濯乾燥機側からスマートフォン１３へ送られる。この洗濯乾燥機側情報は、スマートフォン１３から更に本人確認サーバー１０へ送信されそこで管理される。勿論、洗濯乾燥機から直接インターネットを介してこの洗濯乾燥機側情報を本人確認サーバー１０へ送信することもできる。

ネットワーク対応の炊飯器や電子レンジでは、スマートフォン１３をリモコンとして操作が可能となっている。また、インターネット経由で、料理の出来上がりや、電気消費量の通知、故障予知の通知を、スマートフォン１３で受信することもできる。これらの操作情報や通知情報が、炊飯器や電子レンジ側からスマートフォン１３へ送られる。この炊飯器や電子レンジ情報は、スマートフォン１３から更に本人確認サーバー１０へ送信されそこで管理される。勿論、炊飯器や電子レンジから直接インターネットを介してこの炊飯器や電子レンジ側情報を本人確認サーバー１０へ送信することもできる。

照明もスマートフォン１３から制御できるものが市販されている。スマートフォン１３のユーティリティプログラムには、この制御機能も実装されている。特に、ＬＥＤ照明では、明るさや色合いの調整も可能である。タイマー機能も容易に実装できるが、照明機器そのものにタイマー機能が無い場合には、ユーティリティプログラムにタイマー機能を実装すれば良い。やはり、照明のオンオフや、明るさや色合いの調整、タイマー設定に関して、それらの履歴が、ライフログのデータとして本人確認サーバー１０へ送信する。

上記家電製品のライフログは図２７に示したようなデータベースに保存される。ここで操作が実行された際に１つのレコードが生成され、夫々のレコードは、日付および時刻、その家電製品を示す機器コードと、夫々の機器に依存する操作コードと、操作データからなっている。例えば、エアコンでタイマーを設定した場合には、エアコンの機器コード７、設定時間で起動するタイマーの操作コード１２、設定時間０５００（午前５時）といったレコードが記録される。

次に、上記ライフログのデータを用いた本人確認の具体例を説明する。ここでも処理の流れは実施例１または実施例２で説明したものと同じであり、質問の内容のみが異なるので、その質問のみを以下に説明する。やはり、余り古いデータでは、覚えていないことが多い。従って、遡ってもせいぜい数日前程度の履歴から認証用の質問を行うようにすると良い。

図２８や図３０の例では、昨日のライフログから質問を行っている。やはり、この質問では、正しい内容を選択するものであり、多くの場合は複数の選択が正しい回答となっている。６項目示されているので、１つの質問でも偶然正解する可能性は低いが、必要に応じて、同様の質問を繰り返しても良い。質問の精製方法は実施例７と同様である。

なお、この実施例では、スマート家電を主に扱っているが、スマートフォンからの情報と組み合わせることでより確実性が高くなる。すなわち、図２４〜図２８と図２９や図３０の質問を混合すると良い。例えば、図３１や図３２に示したような質問を行う。

更に、「車で遠出をした」といった質問は、自動車そのものからのデータで生成することもできるが、スマートフォンの加速度、角加速度の情報や、移動履歴のデータからも生成できる。また、こういったスマート家電とスマートフォンの両者のデータを関連付けることで、ライフログの解釈をより確実とすることもできる。

この実施例では、上記各実施例のライフログデータに加えて、テレビや番組を録画するビデオレコーダの視聴や録画といった番組視聴履歴もライフログとして本人確認に利用する。テレビやビデオレコーダの場合には、より認証に適した有効な履歴データが得られる。すなわち、何を観たかというのは、余り忘れないものである。ここでは、スマートフォン１３のユーティリティプログラムによって、ユーザーは、ＬＡＮ経由のテレビやビデオレコーダのリモコンとして、当該スマートフォン１３を利用できるものとする。

この実施例では、テレビやビデオレコーダ側には、スマートフォン１３のユーティリティプログラムの送信するＬＡＮ経由のコマンドを、通常の赤外線によるリモコンと同様の操作コマンドとして解釈するようなプログラムが実装されている。それに加えて、録画予約状況や録画の実行結果やスマートフォン１３以外の操作を含む自分の状態をスマートフォン１３のユーティリティプログラムに通知する処理も行うものとする。

放送のデジタル化に伴い、放送電波に乗って、所定の規格による電子番組表が送信されている。本人確認サーバー１０では、この電子番組表を取得してデータベースとして保存しておくので、各ユーザーの視聴履歴はチャネル番号と時刻さえ記憶しておけば、そこから番組情報（タイトル、概要、出演者など）も特定される。

従って、視聴履歴の各レコードは、動作時刻と動作コードからなる。動作コードは、テレビやビデオレコーダの動作を示す４バイトのコードであり、最初の２バイトがチャネル情報を示し、その後の２バイトが動作内容を示す。チャネル情報の上位４ビットは放送種別を示し、下位の１２ビットはチャネル番号を示す。放送種別は、地上デジタル放送(0001b)、ＢＳデジタル放送(0010b)、ＣＳ放送(0011b)、ケーブルテレビ(0100b)などの種別を示す。図３３は、この番組視聴履歴のデータベースに対応する表の一例を概略的に示す図である。

動作内容は、テレビやビデオレコーダのオン・オフ、チャネル変更、録画開始、録画終了、録画開始予約、録画終了予約などを区別する為の数値で指定する。例えば、録画予約に関する動作は、上位２ビットを１０（録画開始予約）、１１（録画終了予約）とすることで区別し、録画開始予約時間と録画終了予約時間は、日付および時刻フィールドに対応する現在時間からのオフセット（秒数）として下位１４ビットに格納する。録画予約以外の動作内容は、最上位ビットを０とする。

次に、上記ライフログのデータを用いた本人確認の具体例を説明する。やはり、処理の流れは実施例１または実施例２で説明したものと同じであり、質問の内容のみが異なるので、その質問のみを以下に説明する。図３４乃至図３６は、上記番組視聴履歴を用いた本人確認で用いる質問の具体例を示す。図３４と図３５の質問は、番組名を選択する６択問題である。また、図３６では、１つの番組について、詳しい情報を示して、どのような視聴を行ったかを質問している。この場合、詳しい情報を示しているので、比較的古い情報でもユーザーは答えられると推定できる。

なお、本人確認サーバー１０は、ライフログサーバーとしても機能するので、ユーザーは本人確認を行った後に、自身のライフログを自由に検索したり、取得したり、操作したりできる。上記ライフログのデータは、包括的で詳細なので本人にとっては非常に有用な情報となり得る。

この実施例では、ユーザーのプライバシーを配慮して、ライフログのデータを暗号化してから、本人確認サーバー１０へ送信する。ここでの暗号化方式は、実施例６のものと基本的な構造は同じであるが、より一般化している。ここで基本的な処理は次の通りである。

スマートフォンまたはパソコンは、本人確認サーバー１０に偽情報を真情報と常に一対として送信し、それによりサーバー側で真偽が判断できるようにする。真情報は上記の通り実際のライフログデータとして生成し、当該真情報とは大きく異なるレコードを生成してペアとなる偽情報を生成する。偽情報と真情報は、夫々暗号化してからこの順序で送信する。サーバー側では、内容は分からないが、いずれが真偽であるかは受信した順序で分かる。

従って、この場合、サーバーで管理すべき情報の量は２倍になる。本人確認サーバー１０は、スマートフォンまたはパソコンから受信した暗号化された偽情報と真情報をそのまま保存管理する。また、図３８に示したような、受信した偽情報と真情報に対応する情報へアクセスする為のポインタを、受信した日時に関連付けた表を作成し更新を行う。例えば、同一日時の最初が偽情報であり後が真情報である。

本人確認を行う場合、本人確認サーバー１０は、ランダムに６レコードを抽出しユーザーのスマートフォンまたはパソコンへ送信する。ユーザー側では、受信したレコードを「＊時に＊＊さんへ＊分だけ通話を行った」といった項目に複合して、上記のような質問形式で表示する。ユーザーの行った回答は、本人確認サーバー１０に送信され、採点されて本人確認の成否が決定する。これは、本人確認サーバー１０側では、実際の内容が分からないということを除いて、暗号されていない上記実施例と同様である。

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

通常の暗号化であれば、暗号化キーが漏洩すれば、正規のユーザーと同等の立場となり、本人として全ての情報にアクセスできてしまう。しかし、上記のような本人確認方法によれば、暗号化キーが分かっても本人のような記憶が無いので認証に失敗し、情報へのアクセスは出来ない。ライフログのデータを取得するには、当然ながら、その前に認証を成功することが前提となっている。

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

この実施例では、脈拍、 呼吸数や体温といった生体情報を、ライフログの一部として蓄積管理する。スマートフォンのみでも一部の生体情報は収集できるが、ここでは別途デバイスを併用する。このデバイスは、一般的なウエアラブル端末でも良いが、生体情報の収集に特化したものがより望ましい。すなわち、この端末は、ユーザーの身体から直接生体情報を計測して、そのデータを無線でスマートフォンへ送信する。データを受信したスマートフォンは、必要に応じてそのデータに処理を施してから、本人確認サーバーへ送信する。

このようなデバイスの具体例としては、心電計、呼吸センサーや温度センサーが編み込まれたＴシャツがある。スマートフォンがこのＴシャツからBluetooth（登録商標）経由で情報を取得し、心拍数、心拍数ゾーン、心拍の変化、呼吸数、呼吸の深さ、体温といった生体情報を算出し取得することができる。また、スマートフォンの加速度センサーやジャイロセンサーの出力と組み合わせて、消費エネルギー、活動強度、歩数、消費カロリーといった生体情報も算出し取得することができる。

ここでは、スマートフォンは生のセンサー情報から生体情報を算出し、その生体情報を本人確認サーバー１０へライフログデータとして送信する。しかし、スマートフォンは生のセンサー情報を本人確認サーバー１０へ送信し、本人確認サーバー１０が生体情報を算出するようにすることも可能である。

ここでも、上記生体情報は、常時計測するのではなく、加速度に変化があった場合に、計測を開始するようにする。この際、その他のライフログ情報から推定されたユーザーの活動タイプ（静止、屋内での作業、歩行、自転車走行、乗車中、スポーツ活動・・・睡眠中など）の推移に関連付けて、生体情報を変動パターンとして記録する。

以下、図３９を参照して、ユーザーの活動タイプが切り替わった場合の処理を説明する。すなわち、ステップＳ１０１で、移行直後から一定時間（例えば、１０分間）生体情報の変動パターンを取得する。具体的には、移行から１０秒間、移行から５秒後から１０秒間、移行から１０秒後から１０秒間・・・といった具合に、この１０秒の区間をずらしながら５秒毎の生体情報を測定していく。このようにして１２０個のデータからなる変動パターンが得られる。この生体情報変動パターンを、歩行から静止といった活動タイプの移行に関連付けて、本人確認サーバー１０においてライフログデータとして記録する。なお、歩行から静止への移行した場合には、一定時間経過後（例えば、１０分後）も、静止状態にある場合には、静止状態での生体情報も算出し取得する。なお、これらの区間や間隔の取り方は適宜変更可能である。

そして、活動タイプの個々の移行に関して十分な数の変動パターンが収集された後に（ステップＳ１０３でＹＥＳ）、各々の活動タイプの移行毎に代表的な生体情報変動パターンの参照パターンを生成する（ステップＳ１０４）。また、参照パターンが生成された後は（ステップＳ１０２でＹＥＳ）、変動パターンが収集される毎に、参照パターンとの類似度が計算される（ステップＳ１０５）。この類似度が所定の閾値以上であれば（ステップＳ１０６でＮＯ）、本人と判定され（ステップＳ１０７）、その変動パターンによって参照パターンが更新される（ステップＳ１０８）。また、所定の閾値よりも小さい場合には（ステップＳ１０６でＹＥＳ）、本人ではないと判定される（ステップＳ１０９）。なお、下記の通り、スマートフォンでは、最後に送信した変動パターンを保持するようにしておく。

２つのパターン間の類似度の算出方法としては、例えば、畳込みを行い、その最大値や平均値を類似度とする方法がある。より精度を高めるには、生体認証などで利用されているような特徴点に基づく算出方法や、その他の算出方法を利用してもよい。また、それらの組み合わせで類似度を求めれば更に信頼性を高めることができる。代表的な生体情報変動パターンは、例えば、収集された他の変動パターンとの類似度の平均が最も大きなパターンとして求めることが出来る。

以下、図４０を参照して、ユーザーがスマートフォンのブラウザを介して或るサービスプロバイダへのログオンを行う具体例を説明する。

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

まず、ユーザーは、スマートフォンのブラウザで、図６に示したようなサービスプロバイダのログオン画面へアクセスする。このログオン画面には、ユーザーＩＤを入力するフォームが含まれており、ユーザーＩＤを入力した後に送信ボタンを押すと、認証要求が本人確認サーバー１０へリダイレクトされる。この認証要求には、このユーザーＩＤと共に、このサービスプロバイダのＵＲＬと認証ＩＤおよび直近の生体情報が添付されている。この直近の生体情報は、最後にスマートフォンから本人確認サーバー１０へ送った変動パターンの最後の１２８バイトで良い。この１２８バイトがパスワードの同様の意味を持つ。

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

この実施例では、上記ライフログデータに加えて、自動車内での行動も蓄積管理する。自動車に設けられた装備として、走行や操縦などの内部データを送信する手段があれば、送信された情報をスマートフォンで受信し、それをスマートフォンから本人確認サーバー１０へ送信し、そこで蓄積管理する。

現在の自動車では、エンジンやメーター、トランスミッション、ブレーキ、パワーステアリングなどの制御などのために、数多くのＥＣＵ（Electronics Control Unit）が搭載されている。それらＥＣＵ間をつなぐネットワークとしてＣＡＮ（Controller Area Network）が広く普及している。このＣＡＮのデータを、スマートフォン経由でクラウドにリアルタイムで送受信する。

すなわち、ＣＡＮで取得できる情報としては、自動車の走行速度やエンジン回転数、燃料噴射量、ブレーキペダルのストローク量、ステアリングの舵角など多岐にわたる。また、自動車に搭載されているセンサー情報を使用して得られる周辺の気候や渋滞、路面の凍結状態を取得することもできる。これらの情報は、車載OBD（On Board Diagnostics）コネクターに実装されたWi-Fi機能により、スマートフォンへ送信される。

また、通常の自動車の内部データやスマートフォンでは取得できない情報もある。その中でも特に重要な情報の１つは、運転者の視線方向の変化である。幾つかの従来技術では、運転者がよそ見しているかどうかを判断して安全運転につなげる効果が期待されている。このような従来技術の場合、視線方向の変化をライフログデータとして蓄積していないし、また、蓄積する必要もない。本実施例ではこの視線方向の変化履歴をライフログデータとして蓄積管理する。

まず、自動車の運転席の正面側で、運転者の視界を遮らない位置、例えば、ダッシュボードの上とかルーフ部分のフロントガラスに接する位置に、視線検出装置を設置する。この視線検出装置は近赤外ＬＥＤと近赤外カメラを備えている。この近赤外ＬＥＤで運転者の顔を照らし、目の角膜からの反射光を近赤外線カメラで受光することで、運転者の視線方向を検出する。また、同時に顔の向きも検出する。なお、運転が行われている間、検出は継続して連続的に行われる。検出データは、視線検出装置から、無線でスマートフォンへ送られ、このスマートフォン経由でサーバーへ送られる。運転者の視線方向のデータは、例えば、上下方向と左右方向への角度として得られるが、そのデータをそのまま蓄積してはデータ量が大きくなるだけでなく、利用する際にも不便である。従って、サーバーではデータのサブバンド符号化を行う。

具体的には、生のデータをバッファに蓄積し、視線方向変化の様子がまとまっている時間区間、例えば、余り動かない区間、良く動く区間、激しく動く区間、といった区間でデータを区分けする。各区間毎に、離散ウェーブレット変換を行い、その結果をライフログのデータベースに蓄積管理する。勿論、十分な容量があれば、夫々の区間毎に可逆圧縮を行って全ての生データをも保存するようにしても良い。

このような視線方向履歴は、運転者の癖や問題点を分析する手助けになる。しかし、ここではその応用の１つとして視線方向履歴を認証に利用する。まず、ウェーブレット係数を一定量以上蓄積し、そこから幾つかの類型パターンを抽出する。例えば、ブレーキの後、動き始め、信号などで停止し発車する際の視線方向の動きとか、周波数成分の分布とかである。そして、本人確認サーバー１０は、ユーザーの視線方向の動きの特徴を代表する照合用パターンを生成し、スマートフォンへ送信する。

以下、照合用パターンが生成された後、どのように運転者の本人確認が行われるかについて図４１を参照して説明する。この処理は、自動車の始動時に行うものであり、本人確認がなされた後は、そのまま通常運転が可能で、それと共に連続的に視線方向履歴の取得が継続される。

本人が運転する場合、通常通り、エンジンを起動し運転を開始する。その後の視線方向のデータは連続的にスマートフォンで受信されるが（ステップＳ２０１）、まだ本人確認がなされていないので、このデータはサーバーへは送らない。スマートフォンに視線方向の変化履歴が一定時間、例えば５分以上、具体的には１０分間蓄積されると、そのデータについて離散ウェーブレット変換を行い、照合用パターンとの類似度を算出する（ステップＳ２０２）。例えば、畳込みを行い、その最大値や平均値を類似度とする。やはり、より精度を高めるには、生体認証などで利用されているような特徴点に基づく算出方法や、その他の算出方法を利用してもよい。また、それらの組み合わせで類似度を求めれば更に信頼性を高めることができる。

この類似度が閾値を下回らなければ（ステップＳ２０３でＮＯ）、本人と判断して（ステップＳ２０５）、変化履歴データをサーバーへ送信する。サーバーでは、この変化履歴データを用いて照合用パターンを更新する（ステップＳ２０６）。また、サーバーでは、この更新された照合用データを用いて過去の履歴データとの類似度を算出し、より適切で信頼性のある閾値を決定する。これら更新された照合用データおよび閾値はスマートフォンへ送信され、スマートフォン側ではこのデータで照合用データおよび閾値を更新する。なお、十分に信頼性のある閾値というのは、本人を他人と判断することがないような閾値であり、具体的には、過去の履歴データから求めた類似度の最小値よりも小さい値とすれば良い。

他人が運転する場合、やはり、エンジンを起動し運転を開始する。その後の視線方向の変化履歴はスマートフォンで受信され（ステップＳ２０１）、一定時間蓄積されると、離散ウェーブレット変換を行い、照合用パターンとの類似度を算出する（ステップＳ２０２）。この類似度が閾値を下回れば（ステップＳ２０３でＹＥＳ）、本人でない可能性がある。しかし、動き始めのパターンのみではバラツキが考えられるので、ブレーキの後、アクセルを踏んだ後、信号などで停止し発車する際など、別の変動パターンでも類似度を算出して照合用パターンと比較する。

すなわち、引き続きステップＳ２０１で別の区間の変動パターンを取得し、ステップＳ２０２で類似度を算出し、ステップＳ２０３で判定する。もし、類似度が閾値を下回らなければ（ステップＳ２０３でＮＯ）、本人と判断して上記の通り本人確認処理は終了する。

この比較照合を所定回数だけ繰り返しても、類似度が閾値以上とならない場合は（ステップＳ２０７でＹＥＳ）、他人と判断し（ステップＳ２０８）、運転を停止させる処理を開始する（ステップＳ２０９）。例えば、「想定外の事態が発生しました。１０分以内に安全な場所に移動して停車願います」といったアナウンスを行う。１０分以内に停車しなければ、徐々にパワーを下げるようにする。そして、停車の後は、起動操作が行われてもエンジンを始動しない。

この実施例では、ウエアラブル端末のデータを、上記ライフログデータに加えて蓄積管理する。このウエアラブル端末のデータは、無線でスマートフォンへ送られ、スマートフォンから本人確認サーバーへ送信され、そこで蓄積管理される。ここでは一例として、リストバンド型または腕時計型のウエアラブル端末を想定する。

このウエアラブル端末には、加速度センサーやジャイロセンサーが設けられており、腕の動きを直接計測する。従って、個人の癖や特徴的な動きのパターンが記録され、他のライフログデータとの組み合わせにより、実際の活動内容を推定することが可能となる。また、この特徴的な動きのパターンを検出して、本人確認を行うことができる。

例えば、ゴルフ練習場で打ちっ放しをする場合、このウエアラブル端末からスマートフォン経由で、ゴルフ練習場のサーバーへ、クラブのスイングパターン情報が、「動きパターン」という生体情報として送信される。ゴルフ練習場のサーバーでは、このデータに基いて同一人物であるか否かという生体認証を行うことが出来る。これによって、常連客への割引などを行うことができる。

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

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

本実施例および上記各実施例のライフログデータは、非常にプライベートな情報である。従って、ユーザーの設定によって適宜保存するデータを選択できるようにすることが望ましい。例えば、図３７に示したようなダイアログボックスを表示し、本人確認サーバー１０へ送信され、本人確認サーバー１０で蓄積管理されるライフログデータの項目をユーザーが任意に選択できるようにする。

Ａ、Ｂ ユーザー
１ サーバー
２ 履歴テーブル
３Ａ、３Ｂ 携帯通信機器
５、１５ 衛星
７ 基地局
１０ ライフログサーバー
１３ スマートフォン
２０ 家電製品

Claims (8)

1. インターネット上に存在するサーバーによってユーザーの本人確認を行う方法であって、
   前記ユーザーの携帯通信機器から、インターネットを介してライフログ情報を受信するステップと、
   前記ライフログ情報の履歴を蓄積管理するステップと、
   前記ライフログ情報の履歴を参照して、前記ユーザーであれば知り得る前記履歴に関する質問を生成するステップと、
   前記履歴に関する質問を、インターネットを介して前記携帯通信機器へ送信するステップと、
   前記履歴に関する質問に対して前記ユーザーが行い、前記携帯通信機器から送信された回答を、インターネットを介して受信するステップと、
   前記ユーザーが行った回答が正しいかどうかを評価するステップと、
   前記評価結果に基いて、本人確認を成功させるかどうかを決定するステップとからなる本人確認方法。
2. 前記ライフログ情報とは、スマート家電から得られる情報であることを特徴とする請求項１に記載の本人確認方法。
3. 前記携帯通信機器は、前記スマート家電の動作を制御する機能を持ち、スマート家電から得られる前記ライフログ情報は、前記携帯通信機器を介して前記サーバーへ送信されることを特徴とする請求項２に記載の本人確認方法。
4. 前記ライフログ情報とは、前記携帯通信機器に搭載されているセンサーで得た情報であることを特徴とする請求項１に記載の本人確認方法。
5. 前記センサーは、加速度センサー、ジャイロセンサー、方位センサー、気圧センサー、温度センサー、近接センサー、照度センサーのいずれかを含むことを特徴とする請求項１に記載の本人確認方法。
6. 前記携帯通信機器はメール送受信機能を備えており、前記ライフログ情報とは、前記携帯通信機器で行ったメールの送受信に関する情報であることを特徴とする請求項４に記載の本人確認方法。
7. 前記携帯通信機器は通話機能を備えており、前記ライフログ情報とは、前記携帯通信機器で行った通話に関する情報であることを特徴とする請求項４に記載の本人確認方法。
8. インターネットを介してユーザーの本人確認を行う装置であって、
   前記ユーザーの携帯通信機器から、インターネットを介してライフログ情報を受信するステップと、
   前記ライフログ情報の履歴を蓄積管理するステップと、
   前記ライフログ情報の履歴を参照して、前記ユーザーであれば知り得る前記履歴に関する質問を生成するステップと、
   前記履歴に関する質問を、インターネットを介して前記携帯通信機器へ送信するステップと、
   前記履歴に関する質問に対して前記ユーザーが行い、前記携帯通信機器から送信された回答を、インターネットを介して受信するステップと、
   前記ユーザーが行った回答が正しいかどうかを評価するステップと、
   前記評価結果に基いて、本人確認を成功させるかどうかを決定するステップを実行可能な本人確認装置。

Images