JP2013016070A

JP2013016070A - ログオン支援システム

Info

Publication number: JP2013016070A
Application number: JP2011149277A
Authority: JP
Inventors: Shigeki Uedahira; 重樹上田平
Original assignee: Interman Corp
Current assignee: Interman Corp
Priority date: 2011-07-05
Filing date: 2011-07-05
Publication date: 2013-01-24

Abstract

【課題】ユーザーに特別な処理を要求すること無く、そのユーザーがアクセス権を有するかどうかをサーバー側で判断を行うことを可能とするログオン支援システムを提供する。
【解決手段】システムは、インターネットへのアクセスが可能な通信機能と、現在位置情報の検出機能と、現在位置情報の変化を逐次記録する位置情報履歴記録機能と、インターネットを介してサーバー１へのアクセスを行った際に、前記サーバーから履歴要求があれば、前記現在位置情報の記録の少なくとも一部を前記サーバーへ送信する機能、を備えた携帯通信機器３と、前記携帯通信機器３からアクセス要求があった場合、前記現在位置情報の記録の少なくとも一部を要求する機能と、前記携帯通信機器から前記現在位置情報を受信する機能と、前記現在位置情報に基づいて前記アクセス要求を許可するか否かを決定する機能、を備える。
【選択図】図１

Description

本発明は、携帯端末がインターネット上のサイトへアクセスする為の、簡易的なログオン支援システムに関する。

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

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

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

そこで、本発明の目的は、ユーザーに特別な処理を要求すること無く、そのユーザーがアクセス権を有するかどうかをサーバー側で判断を行うことを可能とするログオン支援システムを提供することである。

上記課題を解決するために、本発明のログオン支援システムは、インターネットへのアクセスが可能な通信機能と、現在位置情報の検出機能と、現在位置情報の変化を逐次記録する位置情報履歴記録機能と、インターネットを介してサーバーへのアクセスを行った際に、前記サーバーから履歴要求があれば、前記現在位置情報の記録の少なくとも一部を前記サーバーへ送信する機能、を備えた携帯通信機器と、前記携帯通信機器からアクセス要求があった場合、前記現在位置情報の記録の少なくとも一部を要求する機能と、前記携帯通信機器から前記現在位置情報を受信する機能と、前記現在位置情報に基づいて前記アクセス要求を許可するか否かを決定する機能、を備えたサーバーからなっている。

本発明に係わるログオン支援システムによれば、携帯通信機器側で位置情報履歴を自動的に蓄積保存する。サーバーでは、この位置情報履歴に基づいて、当該携帯通信機器を持つユーザーにアクセス権があるかどうかを決定する。従って、アクセス権のあるユーザーは、特別な操作を行わずに、アクセス制限のない通常のウェブサイトと同じようにアクセスできる。

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

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

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

図１は、本発明の実施例１に係るログオン支援システムの全体構成を示す図である。すなわち、このシステムは、インターネットに接続した大学のサーバー１にインストールされているウェブサイトと、ユーザーが携帯する携帯通信機器３にインストールされているブラウザとユーティリティプログラムを含んでいる。この実施例では、ブラウザには以下に説明するこのシステムに必要な機能が組み込まれている。そのような機能の組み込みは、プラグインのような補助プログラムの利用などで実装される。

ユーティリティプログラムは、定期的に衛星５を利用したＧＰＳまたは基地局７による現在位置情報を取得して、携帯通信機器３の内部の記録領域に取得された位置情報の履歴を蓄積する。この履歴のデータベースの構成を図２に示す。この履歴データベースには、記録の行われた日時と、緯度、経度、その時に通信を行なっている基地局７を特定する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のルーターに接続する場合、携帯通信機器３のユーティリティプログラムに、その位置周辺の位置情報の履歴を要求する。その家の家族であれば、非常に長い時間その周辺の位置情報が蓄積されているはずなので、そのようなデータがなければアクセスを拒絶する。例えば、他人がその家の前を携帯通信機器３を持って通っただけで、簡単にアクセスが行われてしまうといったことがなくなる。

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

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

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

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

この位置情報履歴記録用ＵＲＬは、位置情報履歴データを携帯通信機器に記録するためのＵＲＬである。このＵＲＬを受けたユーティリティプログラムは、そのＵＲＬへアクセスする。この際、携帯通信機器から現在位置情報を取得して、登録されている地理座標範囲に対応するかどうかを確認しても良い。

アクセスを受けたウェブサイトは、位置情報履歴データをクッキーとして、そのユーザーが携帯する携帯通信機器に記録する。ただし、この位置情報履歴データには、実際の位置情報は含まなくても良い。そのクッキーは、現在位置情報が地理座標範囲にある時にのみ記録されるからである。

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

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

クッキーには、その地理座標範囲に入った時の日時情報と、その地理座標範囲から出る直前の日時情報を記録する。この２つの日時情報が同一なら、すなわち、高々十分程度しかその地理座標範囲に滞在していなければ、クッキーとして記録しない。なので偶然前を通過しただけでは、クッキーの更新は行わないようにする。

これにより例えば大学の所在地の周囲にどれだけ滞在したかが分かる。更に、通常のブラウザでは、クッキーの容量は限られているので、月毎に分割して記録するようにする。例えばクッキー名を「２０１１０９」として、２０１１年９月のデータを記録するようにする。一日平均１０箇所の滞在があるとしても、月のデータ数は６００となる。一つの日時情報は４文字のデータなので、クッキーのデータは２４００文字となる。

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

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

携帯通信機器３が、最初に地理座標範囲に入ると、サーバー１側で２５６ビットの乱数ＲＣを生成して、Base64で文字列に変換し、これをクッキーとして携帯通信機器側に記録しておく。この乱数ＲＣは、ユーザー毎に異なる数値である。また、サーバー１側では、予め乱数ＲＳを保存しておく。この乱数ＲＳは全てのユーザーで共通である。

そして、日時情報は乱数ＲＣと乱数ＲＳのビットごとの排他的論理和を算出し、そのハッシュ値（ここではＳＨＡ−２）のLSBから日時情報分に対応するビットだけ取り出して暗号化用乱数とする。ハッシュ値は２５６ビットなので、再帰的にハッシュ値を計算し、前のハッシュ値に連結することで、必要な桁数の暗号化用乱数を得るようにする。例えば、ハッシュ値の計算と連結を１０回繰り返せば、２５６０ビットの暗号化用乱数が得られる。

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

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

この暗号化用乱数とデコードされたクッキーのデータとの排他的論理和を算出し、位置情報履歴を得る。ここで、位置情報履歴が２０１１年９月のデータとして正しい範囲にあるかどうかを検証する。また、昇順になっているかも検証する。検証に失敗すれば、その旨を通知して処理を終了する。検証に成功すれば、0x37B0を連結し暗号化用乱数との排他的論理和を算出する。そして、その算出データをBase64でエンコードして得た暗号化データで、クッキー名「２０１１０９」の値を更新する。この場合、携帯通信機器側では、クッキーのデータには、0x37B0に対応する文字列「N7A=」が追記されることになる（図６）。

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

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

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

Claims

インターネットへのアクセスが可能な通信機能と、現在位置情報の検出機能と、現在位置情報の変化を逐次記録する位置情報履歴記録機能と、インターネットを介してサーバーへのアクセスを行った際に、前記サーバーから履歴要求があれば、前記現在位置情報の記録の少なくとも一部を前記サーバーへ送信する機能、を備えた携帯通信機器と、
前記携帯通信機器からアクセス要求があった場合、前記現在位置情報の記録の少なくとも一部を要求する機能と、前記携帯通信機器から前記現在位置情報を受信する機能と、前記現在位置情報に基づいて前記アクセス要求を許可するか否かを決定する機能、を備えたサーバーからなるログオン支援システム。