JP2014121095A

JP2014121095A - 存在位置確認記録方法

Info

Publication number: JP2014121095A
Application number: JP2013257543A
Authority: JP
Inventors: Shigeki Uedahira; 重樹上田平
Original assignee: Interman Corp
Current assignee: Interman Corp
Priority date: 2012-12-14
Filing date: 2013-12-13
Publication date: 2014-06-30
Anticipated expiration: 2033-12-13
Also published as: JP6319683B2; US20140173110A1; US9369869B2

Abstract

【課題】無線通信機能を持つ携帯通信機器が所定の場所の近傍へ存在したことを記録する存在位置確認記録方法を提供する。
【解決手段】この存在位置確認記録方法は、前記所定の場所に設置された無線通信機器により、この無線通信機器の通信可能範囲にある携帯通信機器と通信を行うステップと、前記通信を行った後、前記通信を示す記録を、前記携帯通信機器が前記所定の場所の近傍へ存在したことが確認された記録として、前記携帯通信機器と前記無線通信機器の少なくとも一方に記録するステップとからなる。前記通信を示す記録は、前記携帯通信機器に暗号化してから記録する。
【選択図】図１

Description

本発明は、無線通信機能を持つ携帯通信機器が所定の場所の近傍へ存在したことを確認しそれを記録する存在位置確認記録方法に関する。

近年、携帯電話、ＰＨＳ（Personal Handyphone System）、スマートフォン等の携帯端末装置の利用範囲が飛躍的に広がってきている。特に通話機能の他にデータ通信機能が強化され、ユーザーに対してインターネットを介した種々の情報提供サービスが提供されている。一方で、情報提供を行うユーザーを限定したいという場面も多くなっており、ＩＤとパスワードを利用する方法や、個体識別を行う方法などを用いてユーザー確認が行われている（特許文献１）。

しかしながら、ＩＤとパスワードを利用する方法は、ユーザーに面倒な登録操作や認証操作を要求するので、使い勝手が良いとは言えない。携帯端末自体の個体識別を行う方法は非常に簡単であるが、必ずしも安全とは言えなく、また急速に普及しているスマートフォンでは難しいという問題がある。

そこで、本発明の目的は、無線通信機能を持つ携帯通信機器が所定の場所の近傍へ存在したことを確実に検出し記録する存在位置確認記録方法を提供することである。

特開２００５−３３２２８２号公報

上記課題を解決するために、無線通信機能を持つ携帯通信機器が所定の場所の近傍へ存在したことを確認し記録する方法は、前記所定の場所に設置された無線通信機器により、この無線通信機器の通信可能範囲にある携帯通信機器と通信を行うステップと、前記通信を行った後、前記通信を示す記録を、前記携帯通信機器が前記所定の場所の近傍へ存在したことが確認された記録として、前記携帯通信機器と前記無線通信機器の少なくとも一方に記録するステップとからなる。

図１は、本発明の実施例１に係る自動ログオン支援システムの全体構成を示す図である。図２は、本発明の実施例１に係る自動ログオン支援システムにおいて、携帯通信機器に蓄積される履歴データベースの構成を示す図である。図３は、本発明の実施例４に係る自動ログオン支援システムの全体構成を示す図である。図４は、本発明の実施例４に係る自動ログオン支援システムで用いる暗号方法を説明する図である。図５は、本発明の実施例４に係る自動ログオン支援システムで用いる暗号方法を説明する図である。図６は、本発明の実施例４に係る自動ログオン支援システムで用いる暗号方法を説明する図である。図７は、本発明の実施例６に係る自動ログオン支援システムの全体構成を示す図である。図８は、本発明の実施例６に係る自動ログオン支援システムの変形例の全体構成を示す図である。図９は、本発明の実施例７に係る自動ログオン支援システムの全体構成を示す図である。

以下、添付図面を参照しながら本発明の実施形態による自動ログオン支援方法およびシステムを説明する。利用する携帯通信機器としては、現在位置情報の取得が可能で、インターネットへの通信機能を備えたものを想定する。具体的には、一般的な携帯電話、スマートフォンと呼ばれるタッチパネル付きの多機能携帯電話、タブレット型コンピュータが含まれる。現在位置情報の取得方法としては、ＧＰＳ（Global Positioning System）や、ＷＩＦＩまたは基地局による三角測量などがある。

この実施例では、大学のウェブサーバーは、大学に通学または通勤している人が携帯する携帯通信機器３を特定し、その携帯通信機器３からの大学のウェブサイトへのアクセスを許可し、一般の端末からのアクセスにはＩＤやパスワードの提示を求めるシステムを説明する。

図１は、本発明の実施例１に係る自動ログオン支援システムの全体構成を示す図であり、ユーザーはこのシステムを介して大学のウェブサイトへアクセスする。この自動ログオン支援システムは、インターネットへのアクセスが可能な通信機能と、現在位置情報の検出機能とを備えた携帯通信機器３と、インターネットからアクセスが可能な大学のウェブサイトを実装するサーバーを実装環境とする。すなわち、この実装環境に、携帯通信機器３にインストールされるクライアント・プログラムと、サーバー１にインストールされる認証プログラムをインストールすることで、自動ログオン支援システムが実装される。勿論、このクライアント・プログラムは、大学に通学または通勤している多くの人（ここではユーザー２で代表する）が携帯する携帯通信機器３（ここではユーザー２の所有する携帯通信機器３で代表する）にインストールされる。すなわち、このシステムは、大学のサーバー１にインストールされているウェブサイトに実装されている認証プログラムと、ユーザーが携帯する携帯通信機器３にインストールされているブラウザとユーティリティプログラムを含んでいる。上記クライアント・プログラムは、このユーティリティプログラムと上記プラグインとからなる。この実施例では、ブラウザには以下に説明するこのシステムに必要な機能が組み込まれている。そのような機能の組み込みは、プラグインのような補助プログラムの利用などで実装される。

ユーティリティプログラムは、定期的に衛星５を利用したＧＰＳ、ＷＩＦＩ測位または基地局７による現在位置情報を取得して、携帯通信機器３の内部の記録領域に取得された位置情報の履歴を蓄積する。この履歴のデータベースの構成を図２に示す。この履歴データベースには、記録の行われた日時と、緯度、経度、その時に通信を行なっている基地局７を特定するCell-IDと、受信感度のフィールドが設けられている。ユーティリティプログラムは、タイマーイベントに応答して、携帯通信機器３の現在日時、現在位置、Cell-IDおよび受信感度を、１レコードとして生成する。

ただし、履歴は位置情報に変化があった場合のみ記録する。この場合、ある場所に一時間滞在したとすると、例えば、時刻13:30の記録の次は時刻14:30の記録といった具合となる。Cell-IDや受信感度は補助データとして、経緯度の信頼性の評価などに利用出来る。

ユーザーが大学のウェブサイトにアクセスすると、大学のサーバー１は、携帯通信機器３に対して位置情報履歴を要求する。この要求は、例えば"getGeoLocationHistory"といったコマンドを含んだhtmlファイルを返すことで行われる。このコマンドには、大学の所在地の緯度と経度の範囲を示すパラメータが付加されている。上記ブラウザには、このコマンドを解釈する機能が実装されており、これに応答して、履歴データベースから上記パラメータに対応する地理座標範囲の履歴データを大学のウェブサイトに返す。例えば、パラメータを緯度35.682712度、経度139.750299度、緯度範囲0.001度、経度範囲0.001度とした場合、緯度が35.681712度乃至35.683712度、経度が139.749299度乃至139.751299度の範囲に含まれているデータが大学のサーバー１へ返される。

大学のサーバー１は、この履歴データを処理し、当該ユーザーのアクセスを許可するか否かを決定する。決定基準には、過去一ヶ月の間に何日間この大学へ訪れたかといった情報が含まれる。例えば、過去一ヶ月の間に１５日以上、上記地理座標範囲に訪れていれば、当該ユーザーにはアクセス権を与えアクセスを許可し、それ未満であればアクセスを拒絶する。すなわち、この履歴データが認証情報となる。夏休みなどでは、休み前一ヶ月のデータから判断するといった配慮も行う。アクセスを拒絶すると判断した場合でも、ＩＤやパスワードによる認証プロセスへ移行して、そのプロセスを通過してからアクセスを許可するようにする。

上記アクセス制御は、簡易的なものであり、一般的なユーザーのアクセスに制限をかけたいという場合に有効である。なので、上記位置情報によるアクセス制御と、通常のＩＤやパスワードによる認証プロセスを組み合わせることで、更にセキュリティを必要とする情報へのアクセスを制御することもできる。すなわち、上記位置情報による認証のみで、通常の情報へのアクセスを許可し、更にセキュリティを必要とする情報へのアクセスが要求された場合には、正しいＩＤとパスワードの入力を要求するようにする。

また、アクセスの可否に、時間情報も利用しても良い。例えば、大学の講義のある時間帯のデータは、それ以外のデータよりも重みを付けるようにする。具体的には、講義のない時間帯のデータは、２日で一日分として取り扱うようにする。

上記の例は大学のウェブサイトを想定しているが、その他の学校や、職場、会社、研究所、地域コミュニティーなど、ある特定の場所に居て活動する人が、スムーズにそのウェブサイトやその他のネットワークにアクセスできるようにするシステムとして利用出来る。

更に、家庭内無線LANのアクセス制御に利用することも出来る。従来、特に、無線ＬＡＮルーターを最初に設置した際には、面倒な手続きが必要であった。すなわち、家庭内無線LANのルーターに接続する場合、携帯通信機器３のユーティリティプログラムに、その位置周辺の位置情報の履歴を要求する。その家の家族であれば、非常に長い時間その周辺の位置情報が蓄積されているはずなので、そのようなデータがなければアクセスを拒絶する。例えば、他人がその家の前を携帯通信機器３を持って通っただけで、簡単にアクセスが行われてしまうといったことがなくなる。

上記実施例１では、携帯通信機器３からアクセスされた場合、大学のウェブサイトは、位置情報履歴を取得するためのコマンドを含んだhtmlファイルを返す。従って、携帯通信機器３側のブラウザは、このコマンドを解釈して実行するためのプラグインのような補助プログラムがインストールされている必要がある。しかし、ブラウザは通常利用しているもののままで、位置情報履歴を取得するための処理を、全てユーティリティプログラムのみで行うことも可能である。
すなわち、携帯通信機器３からアクセスされた場合、大学のウェブサイト側の認証プログラムは、位置情報履歴をユーティリティプログラムに要求する。

この場合、ユーティリティプログラムは、所定のポート経由で要求を受け、位置情報履歴を返す。認証プログラムは、位置情報履歴で認証を行い、成功すれば携帯通信機器３側のブラウザに、ウェブサイトの認証後のページを返す。認証に失敗すれば、ＩＤやパスワードによる認証を行う為のページを返す。

この実施例では、位置情報を補完するために携帯通信機器３内部に搭載されている計測機器を利用する。具体的には、実施例１で記録する情報に加えて、温度、湿度、気圧などの携帯通信機器３内部の計測結果も記録しておく。そして、位置情報の信頼性を確認する為に、ネットで公表されているその時間その場所におけるデータと比較する。それらが対応していなければ、位置情報も対応していないと判断し、アクセスを許可しない。これは、改ざん防止に効果がある。

この実施例では、サイトへのアクセスを、特定の位置情報を送信する携帯通信機器に対してのみ許可する。例えば、或るイベントに関する特別なサイトへのアクセスを、そのイベントに参加している人に限定にする、といったことが可能となる。或いは、つぶやきブログなどへの投稿で、携帯通信機器からの位置情報によって、投稿の可否を決定する。例えば、或るイベントに関するハッシュタグを含む投稿では、そのイベント会場の周辺からの投稿のみを受け付けるようにする、といったことが可能となる。

この実施例では、ログオン仲介サーバー９を用いる（図３）。自動ログオン支援システムを利用したいウェブサイトは、このログオン仲介サーバー９へアクセスして、ウェブサイトの位置情報履歴記録用ＵＲＬと、希望する地理座標範囲を関連付けて登録する。また、ユーザーが携帯する携帯通信機器３には、ユーティリティプログラムがインストールされており、ウェブサイト側のサーバー１には、下記のクッキー処理アルゴリズムが実装されている。

ユーティリティプログラムは、定期的に（例えば数分程度、この実施例では十分間隔で）ログオン仲介サーバー９へアクセスする。このログオン仲介サーバー９は携帯通信機器３の現在位置情報を取得して、その位置に関連付けて登録されているウェブサイトの位置情報履歴記録用ＵＲＬを返す。

この位置情報履歴記録用ＵＲＬは、位置情報履歴データを携帯通信機器３に記録するためのＵＲＬである。このＵＲＬを受けたユーティリティプログラムは、例えば、大学のウェブサイト側にあるそのＵＲＬへアクセスする。アクセスを受けたウェブサイトは、位置情報履歴データをクッキーとして返し、そのユーザーが携帯する携帯通信機器３に記録される。もし、携帯通信機器３にクッキーとして保存されている以前の位置情報履歴データがあれば、ウェブサイトは、ユーティリティプログラムからその位置情報履歴データを受信して、新たなレコードを追記することで位置情報履歴データを更新してから携帯通信機器３に返す。この際、携帯通信機器３から現在位置情報を取得して、登録されている地理座標範囲に対応するかどうかを確認しても良い。

ただし、この位置情報履歴データには、実際の位置情報は含まなくても良い。そのクッキーは、現在位置情報が地理座標範囲にある時にのみ記録されるからである。正確に言えば、位置の情報はそのクッキーに関連付けられたＵＲＬ(ドメイン)という形式で記録され、その履歴は日時情報として記録される。従って、ここでは、クッキーとして保存された日時情報（日時レコード）のセットも位置情報履歴と呼ぶことにする。

なお、セキュリティ上の理由で、位置情報履歴記録用ＵＲＬは、数分毎（例えば、５分毎）に別のＵＲＬへ更新することが望ましい。すなわち、ウェブサイトは、数分毎にログオン仲介サーバー９へアクセスして、位置情報履歴記録用ＵＲＬを更新する。例えば、「daigaku.ac.jp/iew8s.html」の乱数部分「iew8s」をべつの乱数に変えて「daigaku.ac.jp/iew7.html」などとする。但し、更新された後も、「daigaku.ac.jp/iew8s.html」のＵＲＬも数分程度（例えば、５分程度）は有効とする。

この実施例では、クッキーは日時情報を羅列したデータとなる。日時情報は、2000年1月1日の午前０時０分からの十分単位でカウントした数値とする。例えば、2000年1月1日の午前１時０分なら、整数６となる。一つの日時情報を３バイトの符合なしデータとした場合、三百年以上はオーバーフローしない。クッキーで扱えるのは文字列だけなので、Base64で変換すると一つの日時情報は４文字のデータとなる。

クッキーには、その地理座標範囲に入った時の日時情報と、その地理座標範囲から出る直前の日時情報を記録する。この２つの日時情報が同一なら、すなわち、高々十分程度しかその地理座標範囲に滞在していなければ、クッキーとして記録しない。実際には、その地理座標範囲に入った時に、同一の日時情報のペアを追記したクッキーを保存する。その後その地理座標範囲に留まった場合、十分毎に、新たな日時情報で上記ペアの後の方の日時情報を入れ替える。その地理座標範囲に留まったか否かは、上記ペアの後の方の日時情報と新たな日時情報が連続しているかどうか、すなわち、十分間だけ離れているかどうかで判断する。地理座標範囲に留まっていない場合、すなわち、高々十分程度しかその地理座標範囲に滞在していない場合、ユーザー２がその地理座標範囲から出た後に、クッキーに同一の日時情報が残る。しかし、次のアクセスの際に、ウェブサイト側で同一日時情報が確認された場合、それらを削除して新たな日時情報をクッキーに加える。なので偶然前を通過しただけでは、クッキーの更新は行わないようにする。

これにより例えば大学の所在地の周囲にどれだけ滞在したかが分かる。更に、通常のブラウザでは、クッキーの容量は限られているので、月毎に分割して記録するようにする。クッキーの名前は、年月の名前から作成する。

例えばクッキー名を「２０１１０９」として、２０１１年９月のデータを記録するようにする。一日平均１０箇所の滞在があるとしても、月のデータ数（レコード数）は６００となる。一つの日時情報は４文字のデータなので、クッキーのデータは２４００文字となる。

この場合、２つのレコードが対となって、携帯通信機器３の訪れた時と場所および滞在時間を示す実質的な１つのレコードと考えられる。このレコード対は、次のように圧縮される。すなわち、地理座標範囲に入ってから離れると、既に述べたように一対のレコードが携帯通信機器３に記録される。次のアクセスの際に、ウェブサイトは、最新のレコード対の差分を計算する。例えば、滞在時間が３０分なら、差分は３となる。上記の通り、最新のレコード対（当月より前のクッキーに存在することもあり得る）の差分が０なら、ウェブサイトはそのレコード対を削除して新たな日時情報をクッキーに加える。０でないなら、ウェブサイトは、最新のレコード対の後の方のレコードを削除して、差分をBase64でエンコードした一文字の滞在時間情報と新たな日時情報をクッキーに加える。Base64で表される数値は０〜６３であるから、一文字の滞在時間情報は、最大で６３０分までとなる。これを越えた場合は、全て６３０分（'/'とエンコードされる数値63）として記録する。

この実施例では、或る所在地にどれだけ訪れたかという履歴データが、非常に簡単に蓄積されていく。上記実施例１のようにログオンに利用する以外にも、販売促進に利用することも出来る。例えば、食堂に入った場合、ユーティリティプログラムが自動的にその食堂の位置情報履歴記録用ＵＲＬにアクセスして、履歴データを蓄積する。その食堂のホームページにアクセスすれば、蓄積した履歴データをクッキーとしてホームページへ送られる。これにより、例えば、履歴データに基づいて、何時も来ている人にはクーポンを発行する、といったことが可能となる。

上記実施例では、位置情報履歴はユーザーが携帯する携帯通信機器３に記録される。なので、ユーザー側で改ざんされる可能性がある。これを防ぐために暗号化を利用しても良い。その一例を図４ないし図６を参照して以下に説明する。ここでは、実施例４のシステムに暗号化を実装する。この暗号化では、２つのキーを用いて実行される。

携帯通信機器３が、最初に地理座標範囲に入り、ユーティリティプログラムがサーバー１にアクセスすると、サーバー１側で２５６ビットの乱数ＲＣを一方のキーとして生成して、Base64で文字列に変換し、これをサーバー１のドメイン名に関連付けて例えばCKeyという名前のクッキーとして携帯通信機器３側に記録しておく。サーバー１のドメイン名は、ログオン仲介サーバー９から得たＵＲＬから分かるので、乱数ＲＣは携帯通信機器３側で生成し、クッキーとして保存しても良い。この乱数ＲＣは、この携帯通信機器３でのみ保存され、ユーザー毎に異なる数値である。また、サーバー１側では、予め乱数ＲＳをもう一方のキーとして保存しておく。この乱数ＲＳは秘匿され、全てのユーザーで共通である。

ユーティリティプログラムは、携帯通信機器３が地理座標範囲に入ると、実施例４に示したようにサーバー１にアクセスして日時情報を位置情報履歴として蓄積する。しかし、その際、ユーティリティプログラムは、乱数ＲＣをサーバー１に送信し、サーバー１は乱数ＲＣと乱数ＲＳを用いて位置情報履歴を暗号化してからクッキーとしてユーティリティプログラムに返す。すなわち、先ず、乱数ＲＣと乱数ＲＳのビットごとの排他的論理和を算出し、そのハッシュチェイン（ここではＳＨＡ−２を用いる）を算出し、そのLSBから位置情報履歴に対応するビットだけ取り出して暗号化用鍵とする。ハッシュ値は２５６ビットなので、例えば、ＳＨＡ−２を位置情報履歴に対して１０回繰り返せば、１０個の２５６ビットのハッシュ値が得られ、連結して２５６０ビットのビット列（ハッシュチェイン）が得られる。

図４を参照して、日時が２０１２年１２月２７日０時０分なら、日時情報のデータは0xA6D10となる。これはBase64でそのまま文字列に変換すると「Cm0Q」となる。地理座標範囲に携帯通信機器３が入った場合、サーバー１は「２０１２１２」のクッキーを取得しようとする。その月で最初に地理座標範囲に携帯通信機器３が入った場合には、クッキーは得られない。その場合、日時情報データ0xA6D10を暗号化するために、暗号化用鍵のLSB側２４ビットと排他的論理和を算出しBase64で文字列に変換し、暗号化データとしてクッキー名「２０１２１２」の値として保存する。

ここでもし、その月で既に何度か地理座標範囲に携帯通信機器３が入っており、そのクッキーの現在の値が取得された場合には、その値が正しいかどうかを確認し、正しい場合に新たな４文字を追記する。それにはまず、現在の値を取得し、Base64の文字列をデコードして位置情報履歴の暗号化されたバイナリデータを得る（図５）。また、クッキー名「CKey」の値を取得し、Base64の文字列をデコードして乱数ＲＣを得る。そして、上記ハッシュ計算により、乱数ＲＣと乱数ＲＳから現在のクッキーのビット長よりも２４ビット（新たな日時情報分）長い暗号化用鍵を算出する。

この暗号化用鍵と暗号化された位置情報履歴との排他的論理和を算出し、位置情報履歴を得る。ここで、位置情報履歴が２０１２年１２月のデータとして正しい範囲にあるかどうかを検証する。また、昇順になっているかも検証する。検証に失敗すれば、その旨を通知して処理を終了する。検証に成功すれば、複合された位置情報履歴に0xA6D10を連結し暗号化用鍵との排他的論理和を算出する。そして、その算出データをBase64でエンコードして得た暗号化データで、クッキー名「２０１２１２」の値を更新する。

このウェブサイトへアクセスすると、サーバー１は、クッキー名「２０１２１１」の値と、クッキー名「２０１２１２」の値を読み出す。そして、上記のように、位置情報履歴が正しいかどうかを確認してから、アクセスの条件、例えば過去一ヶ月の訪問回数（位置情報データの数）が規定を上回っているかどうかにより、アクセスの可否を判断する。このような方法により、サーバー１はユーザーのデータを一切保持すること無く、位置情報履歴の制御を行うことが出来る。

以上のように、本発明による自動ログオン支援システムによれば、ユーザーに負担をかけることなくアクセス制御を行うことができ、アクセスが期待されるユーザーを効果的にサイトへ誘導できる。

実施例５では、ユーザー側で正しく暗号化された日時情報を偽造することはできない。しかし、サーバー１に、不正に日時情報を生成させることは、技術的には可能である。例えば、ユーザー２は、自宅にいながらあたかも大学に滞在しているかのように、携帯通信機器３から送信される現在位置情報を改ざんすることも可能である。この実施例６では、携帯通信機器３が実際に大学付近に存在している時のみ、サーバー１が日時情報を生成するようにする。

図７は、本発明の実施例６に係る自動ログオン支援システムの全体構成を示す図であり、ユーザーはこのシステムを介して大学のウェブサイト１５へアクセスする。やはり、この自動ログオン支援システムは、インターネットへのアクセスが可能な通信機能と、現在位置情報の検出機能とを備えた携帯通信機器３にインストールされるユーティリティプログラムと、サーバー９にインストールされる認証プログラムを含んでいる。サーバー９には、インターネットへのアクセスが可能なネットワークアダプタＮＩＣ１と、無線アクセスポイント１１（ＷＩＦＩ通信装置）に接続したネットワークアダプタＮＩＣ２が備えられている。携帯通信機器３のネットワーク接続機能には、ＷＩＦＩ（無線ＬＡＮ）と３Ｇが含まれている。また、サーバー９には、ネットワーク機能を持つ日時情報発行部１３も実装されている。この日時情報発行部１３のネットワーク機能は、ネットワークアダプタＮＩＣ２にのみバインドされている。

更に、サーバー９には、ネットワークアダプタＮＩＣ１を介してインターネットへ公開している大学のウェブサイト１５も含まれている。携帯通信機器３のユーティリティプログラムは、定期的に（例えば数分程度、この実施例では十分間隔で）付近の無線アクセスポイントを検索する。無線アクセスポイントが見つかれば、日時情報発行部１３へのアクセスを試みる。もし、日時情報発行部１３が起動していれば、大学のウェブサイト１５のドメイン名と共に日時情報を返す。携帯通信機器３はクッキーとしてこの日時情報を保存する。。日時情報発行部１３は、無線アクセスポイント１１に接続したネットワークアダプタＮＩＣ２にのみバインドされているので、無線アクセスポイント１１の近傍の携帯通信機器３のみに日時情報を発行する。日時情報発行部１３は、日時情報を発行する際に、携帯通信機器３から乱数ＲＣを受け取り、この乱数ＲＣとサーバー側の乱数ＲＳを用いて、暗号化を行う。この方法は実施例５と同一である。

サーバー９のネットワークアダプタＮＩＣ１はインターネットに接続しており、大学のウェブサイト１５を公開している。また、サーバー９のログオン処理部１７は、インターネットからのアクセスを受けて、ログオン処理を行う。すなわち、携帯通信機器３がインターネット経由で大学のウェブサイト１５へアクセスすると、ログオン処理部１７は、携帯通信機器３から乱数ＲＣおよび位置情報履歴のクッキーの取得を試みる。もし携帯通信機器３からクッキーが返されなければ、ＩＤやパスワードによる通常の認証を行う為のページを返す。もし携帯通信機器３からクッキーが返されれば、乱数ＲＣと、暗号化された位置情報履歴が得られるので、位置情報履歴を乱数ＲＣおよび乱数ＲＳによって復号する。サーバー９のログオン処理部１７は、得られた位置情報履歴がアクセス条件を満たすかどうかで、携帯通信機器３へのアクセスの可否を判断する。アクセス条件を満たさなければ、ＩＤやパスワードによる通常の認証を行う為のページを返す。

なお、サーバー９は、無線アクセスポイント１１によってインターネットへのアクセスを提供していても良い。この場合も、ログオン処理部１７は、無線アクセスポイント１１経由での大学のウェブサイト１５へのアクセスがあれば、携帯通信機器３に乱数ＲＣおよび位置情報履歴のクッキーを取得し、上記の通りのログオン処理を行う。また、ログオン処理部１７による上記ログオン処理で、位置情報履歴が所定の条件を満たす場合にのみ、無線アクセスポイント１１経由でのインターネットへのアクセスを提供するようにしても良い。大学ではなく、この自動ログオン支援システムを店舗などに導入すれば、集客に寄与することが期待できる。例えば、コーヒーショップで、過去一週間に２度以上訪れている客にインターネットへのアクセスを無料で提供するようにすれば、常連客をつなぎ止め、また増加させることができる。

なお、図７では、サーバー９は、無線アクセスポイント１１と共に大学近傍に設けられており、ウェブサーバーとしてウェブサイト１５を公開しているが、図８に示したようにウェブサイト１５をPaasなどのクラウドに設置しても良い。この場合、サーバー９の代わりに通常のパーソナルコンピュータＰＣに、日時情報発行部１３をインストールし、外部に設置したウェブサイト１５にログオン処理部１７をインストールすれば良い。勿論、日時情報発行部１３とログオン処理部１７とで、同一の乱数ＲＣを用いる必要がある。

上記実施例では、携帯通信機器３側に位置情報履歴を保存している。この場合、上記の通り、ユーザー側で改ざんされる可能性がある。この実施例では、改ざん防止に暗号化を利用する代わりに、サーバー９側に位置情報履歴を保存するようにする。図９は、本発明の実施例７に係る自動ログオン支援システムの全体構成を示す図であり、ユーザーはこのシステムを介して大学のウェブサイトへアクセスする。実施例６と同様に、サーバー９には、インターネットへのアクセスが可能なネットワークアダプタＮＩＣ１と、無線アクセスポイント１１（ＷＩＦＩ通信装置）に接続したネットワークアダプタＮＩＣ２が備えられている。携帯通信機器３のネットワーク接続機能には、ＷＩＦＩ（無線ＬＡＮ）と３Ｇが含まれている。また、サーバー９には、ネットワーク機能を持つ位置情報履歴管理部２１も実装されている。この位置情報履歴管理部２１のネットワーク機能は、ネットワークアダプタＮＩＣ２にのみバインドされている。

更に、サーバー９には、ネットワークアダプタＮＩＣ１を介してインターネットへ公開している大学のウェブサイト１５も含まれている。携帯通信機器３のユーティリティプログラムは、定期的に（例えば数分程度、この実施例では十分間隔で）付近の無線アクセスポイントを検索する。無線アクセスポイントが見つかれば、位置情報履歴管理部２１へのアクセスを試みる。もし、位置情報履歴管理部２１が起動していれば、大学のウェブサイト１５のドメイン名を返す。携帯通信機器３のユーティリティプログラムは、このドメイン名に対応するクッキーがあれば、それを位置情報履歴管理部２１へ送信する。もし、クッキーを受信しなければ、位置情報履歴管理部２１は、携帯通信機器３の識別番号として１２８ビットの乱数を返す。携帯通信機器３はクッキーとしてこの識別番号を保存する。更に、位置情報履歴管理部２１は、現在時刻に対応する日時情報のペアをこの識別番号に関連付けて履歴データベースＤＢに蓄積する。ここでの日時情報は、実施例４と同様に、2000年1月1日の午前０時０分からの十分単位でカウントした３バイトの符合なしデータとする。ただし、ここではBase64で文字列に変換することなく、バイナリデータとして保存する。その他の日時情報の扱いは、実施例４と同じである。

もし、クッキーを受信すれば、位置情報履歴管理部２１は、クッキーの値（携帯通信機器３の識別番号）を履歴データベースＤＢから検索する。もし、クッキーの値が上記履歴データベースＤＢに見つからなければ、位置情報履歴管理部２１は、携帯通信機器３の識別番号として１２８ビットの乱数を返す。携帯通信機器３はクッキーとしてこの識別番号を保存する。位置情報履歴管理部２１は、現在時刻に対応する日時情報のペアをこの識別番号に関連付けて履歴データベースＤＢに蓄積する。もし、クッキーの値が履歴データベースＤＢに見つかれば、位置情報履歴管理部２１は、現在時刻に対応する日時情報のペアをこの識別番号に関連付けて履歴データベースＤＢに蓄積する。

位置情報履歴管理部２１は、無線アクセスポイント１１に接続したネットワークアダプタＮＩＣ２にのみバインドされているので、無線アクセスポイント１１の近傍の携帯通信機器３のみに識別番号を発行する。サーバー９のネットワークアダプタＮＩＣ１はインターネットに接続しており、大学のウェブサイト１５を公開している。また、サーバー９のログオン処理部２２は、インターネットからのアクセスを受けて、ログオン処理を行う。すなわち、携帯通信機器３がインターネット経由で大学のウェブサイト１５へアクセスすると、ログオン処理部２２は、携帯通信機器３からクッキーの取得を試みる。もし携帯通信機器３からクッキーが返されなければ、ＩＤやパスワードによる通常の認証を行う為のページを返す。もし携帯通信機器３からクッキーが返されれば、携帯通信機器３の識別番号が得られる。ログオン処理部２２は、この識別番号を位置情報履歴管理部２１に照会して、位置情報履歴を得る。既に述べたような方法で、ログオン処理部２２は、この位置情報履歴に基づいて当該ユーザーのアクセスを許可するか否かを決定する。上記例では、識別番号として生成する乱数のサイズは１２８ビットとしているが、もっと短いサイズを採用しても良い。例えば、多くの場合は、９６ビット以下で十分である。また、日時情報のペアではなく、実施例４で示唆したように日時情報と滞在時間情報とからなる１つのレコードとしても良い。この場合、滞在時間情報は１バイトのデータとし、１レコードを４バイトとする。

上記実施例７では、位置情報履歴としての日時情報を利用することで、ウェブサイト１５へアクセスする為のログオン処理を自動化している。しかし、ウェブサイト１５は、誰でも自由にアクセス可能なホームページと、そこからリンクされている掲示板（ＢＢＳ）やソーシャルネットワーキングサービス（ＳＮＳ）を含み、そこへのアクセスは、上記自動ログオン支援システムを介して行うようにしても良い。例えば、行きつけの居酒屋のホームページへアクセスすると、常連客のみがアクセスできるＳＮＳがあり、ＳＮＳには実施例７に係る自動ログオン支援システムが実装されていれば、そこでは顔見知りのみが情報交換を行なえるようになっており、常連客にとっては安心感があり、お互いを知る手がかりにもなる。

実施例８は、実施例６の変形例である。実施例６では、携帯通信機器３のユーティリティプログラムは、定期的に付近の無線アクセスポイントを検索し、無線アクセスポイントが見つかれば、日時情報発行部１３へのアクセスを試みる。これにより、日時情報発行部１３は、確かに携帯通信機器３が近くに存在することを確認することができる。

この実施例８では、携帯通信機器３のユーティリティプログラムには、予め無線アクセスポイント１１の位置が記録されている。この無線アクセスポイント１１の位置とは、例えば、コンビニエンスストアの各チェーン店の座標であれば、複数の位置として記録される。

携帯通信機器３が記録されている位置の近傍へ入った場合にのみ無線アクセスポイントを検索し、無線アクセスポイントが見つかれば、日時情報発行部１３へのアクセスを試みる。もし、日時情報発行部１３が起動していれば、実施例６と同様に、来店証明の位置情報履歴を携帯通信機器３が残す。なお、この実施例８でも、実施例７と同様に、サーバー９側に位置情報履歴を保存するようにしてもよい。また、携帯通信機器３とサーバー９の双方に、位置情報履歴を保存するようにしてもよい。

このようなシステムを飲食店などの店舗へ設置し、客が来店しただけで、何もせずにポイントを自動的に加算するようにする。例えば、来店と共に携帯通信機器３側にポップアップ画面を表示し、加算されたポイントを表示するようにしても良い。このようにすることで、店舗側も客側にもポイント加算のための面倒な手続きを省くことが可能となり、集客力の向上も期待できる。

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

例えば、上記例では、一対のレコードを、４文字の日時情報と一文字の滞在時間情報に圧縮している。しかし、日時情報の年月の部分は、クッキー名前に入っているので冗長である。そこで日時情報から年月の部分を削除して、更に圧縮することができる。日時情報は１０分単位で記録されるので、年月の部分を除いたデータは、０〜４４６４(６＊２４＊３１)の数値で表され、１３ビットで表現可能である。滞在時間情報を５ビットに割り当てれば、日時情報と滞在時間情報を１８ビットとなる。これはBase64で変換して３文字のデータとなる。滞在時間が０の日時情報は存在しないので、５ビットの滞在時間情報は１０分〜３２０分（０〜３１）まで記録できる。

上記の通り、最新のレコード対の差分が０なら、ウェブサイトはそのレコード対を削除して新たな日時情報をクッキーに加える。０でないなら、ウェブサイトは、最新のレコード対の前の方のレコードから１３ビットの日時情報を生成し、レコード対の差分をから５ビットの滞在時間情報を生成し、これらを連結して１８ビットのレコードを生成する。この１８ビットのレコードをBase64でエンコードし、３文字の日時情報と滞在時間情報を生成する。それから、最新のレコード対を削除し、この３文字情報をクッキーに加え、更に新たな日時情報をクッキーに加える。

１サーバー
３携帯通信機器
５衛星
７基地局
９ログオン仲介サーバー

Claims

無線通信機能を持つ携帯通信機器が所定の場所の近傍へ存在したことを確認し記録する方法であって、
前記所定の場所に設置された無線通信機器により、この無線通信機器の通信可能範囲にある携帯通信機器と通信を行うステップと、
前記通信を行った後、前記通信を示す記録を、前記携帯通信機器が前記所定の場所の近傍へ存在したことが確認された記録として、前記携帯通信機器と前記無線通信機器の少なくとも一方に記録するステップとからなる存在位置確認記録方法。
前記通信を示す記録は、前記携帯通信機器に暗号化してから記録することを特徴とする請求項１に記載の存在位置確認記録方法。