説明

ログオン支援システム

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

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、携帯端末がインターネット上のサイトへアクセスする為の、簡易的なログオン支援システムに関する。
【背景技術】
【0002】
近年、携帯電話、PHS(Personal Handyphone System)、スマートフォン等の携帯端末装置の利用範囲が飛躍的に広がってきている。特に通話機能の他にデータ通信機能が強化され、ユーザーに対してインターネットを介した種々の情報提供サービスが提供されている。一方で、情報提供を行うユーザーを限定したいという場面も多くなっており、IDとパスワードを利用する方法や、個体識別を行う方法などを用いてユーザー確認が行われている(特許文献1)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2005−332282号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、IDとパスワードを利用する方法は、ユーザーに面倒な登録操作や認証操作を要求するので、使い勝手が良いとは言えない。携帯端末自体の個体識別を行う方法は非常に簡単であるが、必ずしも安全とは言えなく、また急速に普及しているスマートフォンでは難しいという問題がある。
【0005】
そこで、本発明の目的は、ユーザーに特別な処理を要求すること無く、そのユーザーがアクセス権を有するかどうかをサーバー側で判断を行うことを可能とするログオン支援システムを提供することである。
【課題を解決するための手段】
【0006】
上記課題を解決するために、本発明のログオン支援システムは、インターネットへのアクセスが可能な通信機能と、現在位置情報の検出機能と、現在位置情報の変化を逐次記録する位置情報履歴記録機能と、インターネットを介してサーバーへのアクセスを行った際に、前記サーバーから履歴要求があれば、前記現在位置情報の記録の少なくとも一部を前記サーバーへ送信する機能、を備えた携帯通信機器と、前記携帯通信機器からアクセス要求があった場合、前記現在位置情報の記録の少なくとも一部を要求する機能と、前記携帯通信機器から前記現在位置情報を受信する機能と、前記現在位置情報に基づいて前記アクセス要求を許可するか否かを決定する機能、を備えたサーバーからなっている。
【発明の効果】
【0007】
本発明に係わるログオン支援システムによれば、携帯通信機器側で位置情報履歴を自動的に蓄積保存する。サーバーでは、この位置情報履歴に基づいて、当該携帯通信機器を持つユーザーにアクセス権があるかどうかを決定する。従って、アクセス権のあるユーザーは、特別な操作を行わずに、アクセス制限のない通常のウェブサイトと同じようにアクセスできる。
【図面の簡単な説明】
【0008】
【図1】図1は、本発明の実施例1に係るログオン支援システムの全体構成を示す図である。
【図2】図2は、本発明の実施例1に係るログオン支援システムにおいて、携帯通信機器に蓄積される履歴データベースの構成を示す図である。
【図3】図3は、本発明の実施例4に係るログオン支援システムの全体構成を示す図である。
【図4】図4は、本発明の実施例4に係るログオン支援システムで用いる暗号方法を説明する図である。
【図5】図5は、本発明の実施例4に係るログオン支援システムで用いる暗号方法を説明する図である。
【図6】図6は、本発明の実施例4に係るログオン支援システムで用いる暗号方法を説明する図である。
【発明を実施するための形態】
【0009】
以下、添付図面を参照しながら本発明の実施形態によるログオン支援システムを説明する。利用する携帯通信機器としては、現在位置情報の取得が可能で、インターネットへの通信機能を備えたものを想定する。具体的には、一般的な携帯電話、スマートフォンと呼ばれるタッチパネル付きの多機能携帯電話、タブレット型コンピュータが含まれる。現在位置情報の取得方法としては、GPS(Global Positioning System)や、基地局による三角測量などがある。
【実施例1】
【0010】
この実施例では、大学に通学または通勤している人が携帯する携帯通信機器3を特定し、その携帯通信機器3からの大学のウェブサイトへのアクセスを許可し、一般の端末からのアクセスにはIDやパスワードの提示を求めるシステムを説明する。
【0011】
図1は、本発明の実施例1に係るログオン支援システムの全体構成を示す図である。すなわち、このシステムは、インターネットに接続した大学のサーバー1にインストールされているウェブサイトと、ユーザーが携帯する携帯通信機器3にインストールされているブラウザとユーティリティプログラムを含んでいる。この実施例では、ブラウザには以下に説明するこのシステムに必要な機能が組み込まれている。そのような機能の組み込みは、プラグインのような補助プログラムの利用などで実装される。
【0012】
ユーティリティプログラムは、定期的に衛星5を利用したGPSまたは基地局7による現在位置情報を取得して、携帯通信機器3の内部の記録領域に取得された位置情報の履歴を蓄積する。この履歴のデータベースの構成を図2に示す。この履歴データベースには、記録の行われた日時と、緯度、経度、その時に通信を行なっている基地局7を特定するCell-IDと、受信感度のフィールドが設けられている。
【0013】
ただし、履歴は位置情報に変化があった場合のみ記録する。この場合、ある場所に一時間滞在したとすると、例えば、時刻13:30の記録の次は時刻14:30の記録といった具合となる。Cell-IDや受信感度は補助データとして、経緯度の信頼性などに利用出来る。
【0014】
ユーザーが大学のウェブサイトにアクセスすると、大学のサーバー1は、例えば"getGeoLocationHistory"といったコマンドを含んだhtmlファイルを返す。このコマンドには、大学の所在地の緯度と経度の範囲を示すパラメータが付加されている。上記ブラウザには、このコマンドを解釈する機能が実装されており、これに応答して、履歴データベースから上記パラメータに対応する地理座標範囲の履歴データを返す。例えば、パラメータを緯度35.682712度、経度139.750299 度、緯度範囲0.001度、経度範囲0.001度とした場合、緯度が35.681712度乃至35.683712度、経度が139.749299度乃至139.751299度の範囲に含まれているデータが大学のサーバー1へ返される。
【0015】
大学のサーバー1は、この履歴データを処理し、当該ユーザーのアクセスを許可するか否かを決定する。決定基準には、過去一ヶ月の間に何日間この大学へ訪れたかといった情報が含まれる。例えば、過去一ヶ月の間に15日以上、上記地理座標範囲に訪れていればアクセスを許可し、それ未満であればアクセスを拒絶する。夏休みなどでは、休み前のデータから判断するといった配慮も行う。アクセスを拒絶すると判断した場合でも、IDやパスワードによる認証プロセスへ移行して、そのプロセスを通過してからアクセスを許可するようにする。
【0016】
上記アクセス制御は、簡易的なものであり、一般的なユーザーのアクセスに制限をかけたいという場合に有効である。なので、上記位置情報によるアクセス制御と、通常のIDやパスワードによる認証プロセスを組み合わせることで、更にセキュリティを必要とする情報へのアクセスを制御することもできる。
【0017】
また、アクセスの可否に、時間情報も利用しても良い。例えば、大学の講義のある時間帯のデータは、それ以外のデータよりも重みを付けるようにする。具体的には、講義のない時間帯のデータは、2日で一日分として取り扱うようにする。
【0018】
上記の例は大学のウェブサイトを想定しているが、その他の学校や、職場、会社、研究所、地域コミュニティーなど、ある特定の場所に居て活動する人が、スムーズにそのウェブサイトやその他のネットワークにアクセスできるようにするシステムとして利用出来る。
【0019】
更に、家庭内LANのアクセス制御に利用することも出来る。すなわち、家庭内LANのルーターに接続する場合、携帯通信機器3のユーティリティプログラムに、その位置周辺の位置情報の履歴を要求する。その家の家族であれば、非常に長い時間その周辺の位置情報が蓄積されているはずなので、そのようなデータがなければアクセスを拒絶する。例えば、他人がその家の前を携帯通信機器3を持って通っただけで、簡単にアクセスが行われてしまうといったことがなくなる。
【実施例2】
【0020】
この実施例では、位置情報を補完するために携帯通信機器内部に搭載されている計測器機の利用する。具体的には、実施例1で記録する情報に加えて、温度、湿度、気圧などの携帯通信機器内部の計測結果も記録しておく。そして、位置情報の信頼性を確認する為に、ネットで公表されているその時間その場所におけるデータと比較する。それらが対応していなければ、位置情報も対応していないと判断し、アクセスを許可しない。これは、改ざん防止に効果がある。
【実施例3】
【0021】
この実施例では、サイトへのアクセスを、特定の位置情報を送信する携帯通信機器に対してのみ許可する。例えば、或るイベントに関する特別なサイトへのアクセスを、そのイベントに参加している人に限定にする、といったことが可能となる。或いは、つぶやきブログなどへの投稿で、携帯通信機器からの位置情報によって、投稿の可否を決定する。例えば、或るイベントに関するハッシュタグを含む投稿では、そのイベント会場の周辺からの投稿のみを受け付けるようにする、といったことが可能となる。
【実施例4】
【0022】
この実施例では、ログオン仲介サーバー9を用いる(図3)。ログオン支援システムを利用したいウェブサイトは、このログオン仲介サーバー9へアクセスして、ウェブサイトの位置情報履歴記録用URLと、希望する地理座標範囲を関連付けて登録する。また、ユーザーが携帯する携帯通信機器には、ユーティリティプログラムがインストールされており、ウェブサイト側のサーバー1には、下記のクッキー処理アルゴリズムが実装されている。
【0023】
ユーティリティプログラムは、定期的に(例えば数分程度、この実施例では十分間隔で)ログオン仲介サーバー9へアクセスする。このWebサイトは携帯通信機器の現在位置情報を取得して、その位置に関連付けて登録されているウェブサイトの位置情報履歴記録用URLを返す。
【0024】
この位置情報履歴記録用URLは、位置情報履歴データを携帯通信機器に記録するためのURLである。このURLを受けたユーティリティプログラムは、そのURLへアクセスする。この際、携帯通信機器から現在位置情報を取得して、登録されている地理座標範囲に対応するかどうかを確認しても良い。
【0025】
アクセスを受けたウェブサイトは、位置情報履歴データをクッキーとして、そのユーザーが携帯する携帯通信機器に記録する。ただし、この位置情報履歴データには、実際の位置情報は含まなくても良い。そのクッキーは、現在位置情報が地理座標範囲にある時にのみ記録されるからである。
【0026】
なお、位置情報履歴記録用URLは、数分毎(例えば、5分毎)に別のURLへ更新することが望ましい。すなわち、ウェブサイトは、数分毎にログオン仲介サーバー9へアクセスして、位置情報履歴記録用URLを更新する。例えば、「daigaku.ac.jp/iew8s.html」の乱数部分「iew8s」をべつの乱数に変えて「daigaku.ac.jp/iew7.html」などとする。但し、更新された後も、「daigaku.ac.jp/iew8s.html」のURLも数分程度(例えば、5分程度)は有効とする。
【0027】
この実施例では、クッキーは日時情報を羅列したデータとなる。日時情報は、2000年1月1日の午前0時0分からの十分単位でカウントした数値とする。一つの日時情報を3バイトの符合なしデータとした場合、三百年以上はオーバーフローしない。クッキーで扱えるのは文字列だけなので、Base64で変換すると一つの日時情報は4文字のデータとなる。
【0028】
クッキーには、その地理座標範囲に入った時の日時情報と、その地理座標範囲から出る直前の日時情報を記録する。この2つの日時情報が同一なら、すなわち、高々十分程度しかその地理座標範囲に滞在していなければ、クッキーとして記録しない。なので偶然前を通過しただけでは、クッキーの更新は行わないようにする。
【0029】
これにより例えば大学の所在地の周囲にどれだけ滞在したかが分かる。更に、通常のブラウザでは、クッキーの容量は限られているので、月毎に分割して記録するようにする。例えばクッキー名を「201109」として、2011年9月のデータを記録するようにする。一日平均10箇所の滞在があるとしても、月のデータ数は600となる。一つの日時情報は4文字のデータなので、クッキーのデータは2400文字となる。
【0030】
この実施例では、或る所在地にどれだけ訪れたかという履歴データが、非常に簡単に蓄積されていく。上記実施例1のようにログオンに利用する以外にも、販売促進に利用することも出来る。例えば、食堂に入った場合、ユーティリティプログラムが自動的にその食堂の位置情報履歴記録用URLにアクセスして、履歴データを蓄積する。その食堂のホームページにアクセスすれば、蓄積した履歴データをクッキーとしてホームページへ送られる。これにより、例えば、履歴データに基づいて、何時も来ている人にはクーポンを発行する、といったことが可能となる。
【0031】
上記実施例では、位置情報履歴はユーザーが携帯する携帯通信機器に記録される。なので、ユーザー側で改ざんされる可能性がある。これを防ぐために暗号化を利用しても良い。その一例を図4ないし図6を参照して以下に説明する。
【0032】
携帯通信機器3が、最初に地理座標範囲に入ると、サーバー1側で256ビットの乱数RCを生成して、Base64で文字列に変換し、これをクッキーとして携帯通信機器側に記録しておく。この乱数RCは、ユーザー毎に異なる数値である。また、サーバー1側では、予め乱数RSを保存しておく。この乱数RSは全てのユーザーで共通である。
【0033】
そして、日時情報は乱数RCと乱数RSのビットごとの排他的論理和を算出し、そのハッシュ値(ここではSHA−2)のLSBから日時情報分に対応するビットだけ取り出して暗号化用乱数とする。ハッシュ値は256ビットなので、再帰的にハッシュ値を計算し、前のハッシュ値に連結することで、必要な桁数の暗号化用乱数を得るようにする。例えば、ハッシュ値の計算と連結を10回繰り返せば、2560ビットの暗号化用乱数が得られる。
【0034】
図4を参照して、位置情報の日時が2011年9月3日12時40分なら、位置情報のデータは0x37B0となる。地理座標範囲に携帯通信機器が入った場合、サーバー1は「201109」のクッキーを取得しようとする。その月で最初に地理座標範囲に携帯通信機器が入った場合には、クッキーは得られない。その場合、データ0x37B0を暗号化するために、暗号化用乱数のLSB側24ビット(実際は16ビット)と排他的論理和を算出しBase64で文字列に変換し、暗号化データとしてクッキー名「201109」の値として保存する。
【0035】
ここでもし、その月で既に何度か地理座標範囲に携帯通信機器が入っており、そのクッキーの現在の値が取得された場合には、新たな4文字をその値に連結することになる。それにはまず、現在の値を取得し、Base64の文字列をデコードしてバイナリデータのビット列にする(図5)。また、乱数RCを取得し、Base64の文字列をデコードしてビット列にする。そして、上記ハッシュ計算により、乱数RCと乱数RSから現在のクッキーのビット長よりも24ビット長い暗号化用乱数を算出する。
【0036】
この暗号化用乱数とデコードされたクッキーのデータとの排他的論理和を算出し、位置情報履歴を得る。ここで、位置情報履歴が2011年9月のデータとして正しい範囲にあるかどうかを検証する。また、昇順になっているかも検証する。検証に失敗すれば、その旨を通知して処理を終了する。検証に成功すれば、0x37B0を連結し暗号化用乱数との排他的論理和を算出する。そして、その算出データをBase64でエンコードして得た暗号化データで、クッキー名「201109」の値を更新する。この場合、携帯通信機器側では、クッキーのデータには、0x37B0に対応する文字列「N7A=」が追記されることになる(図6)。
【0037】
このウェブサイトへアクセスすると、サーバー1は、クッキー名「201108」の値と、クッキー名「201109」の値を読み出す。そして、上記のように、位置情報履歴が正しいかどうかを確認してから、アクセスの条件、例えば過去一ヶ月の訪問回数(位置情報データの数)が規定を上回っているかどうかにより、アクセスの可否を判断する。このような方法により、サーバー1はユーザーのデータを一切保持すること無く、位置情報履歴の制御を行うことが出来る。
【産業上の利用可能性】
【0038】
以上のように、本発明によるログオン支援システムによれば、ユーザーに負担をかけることなくアクセス制御を行うことができ、アクセスが期待されるユーザーを効果的にサイトへ誘導できる。
【符号の説明】
【0039】
1 サーバー
3 携帯通信機器
5 衛星
7 基地局
9 ログオン仲介サーバー

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

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate


【公開番号】特開2013−16070(P2013−16070A)
【公開日】平成25年1月24日(2013.1.24)
【国際特許分類】
【出願番号】特願2011−149277(P2011−149277)
【出願日】平成23年7月5日(2011.7.5)
【出願人】(596177559)インターマン株式会社 (14)
【Fターム(参考)】