(57)【特許請求の範囲】
【請求項１】
予め定められ、夫々のユーザーに共通する特定の場所を訪れていることをアクセス許可の要件とするウェブサイトへのログオン支援方法であって、
夫々のユーザー毎に、使用する携帯通信機器の現在位置情報の変化を位置情報履歴として記録し、
或るユーザーから前記ウェブサイトへのアクセス要求があった場合、前記或るユーザーの位置情報履歴から、当該ユーザーが前記特定の場所を訪れている記録を検索し、
前記検索の結果に基いて、前記アクセス要求を許可するか否かを決定することを特徴とするログオン支援方法。
【請求項２】
前記ウェブサイトは特定の施設に関連付けられており、前記特定の場所とは、この特定の施設の地理座標を中心とする所定範囲であることを特徴とする請求項１のログオン支援方法。
【請求項３】
前記或るユーザーの位置情報履歴から、当該ユーザーが前記特定の場所を訪れている記録を検索した結果、前記或るユーザーが、所定の期間に前記特定の場所を所定の複数回訪れている場合に、前記アクセス要求を許可することを特徴とする請求項２のログオン支援方法。
【請求項４】
前記位置情報履歴は、前記携帯通信機器に記録されており、前記ログオン支援システムが前記アクセス要求を許可するか否かを決定する際には、前記携帯通信機器に対して前記位置情報履歴の少なくとも一部を要求することを特徴とする請求項３のログオン支援方法。
【請求項５】
前記現在位置情報は、暗号化されてから記録されていることを特徴とする請求項４のログオン支援方法。
【請求項６】
前記現在位置情報は、前記携帯通信機器側で保存されている暗号化用数値と、前記ウェブサイト側で保存されている暗号化用数値とを用いて暗号化されることを特徴とする請求項５のログオン支援方法。
【請求項７】
前記携帯通信機器側の暗号化用数値は、前記ウェブサイトを利用する携帯通信機器毎に異なる数値を用い、前記ウェブサイト側の数値は、前記ウェブサイトを利用する携帯通信機器に拘わらず共通の数値を用いることを特徴とする請求項６のログオン支援方法。
【請求項８】
前記携帯通信機器側の暗号化用数値は、前記携帯通信機器側でクッキーとして記録され、前記現在位置情報の記録の際に、前記ウェブサイト側で前記携帯通信機器側の暗号化用数値と前記ウェブサイト側の暗号化用数値の双方を用いて暗号化することを特徴とする請求項７のログオン支援方法。
【請求項９】
前記ウェブサイトは、前記地理座標範囲を仲介サーバーに登録し、前記仲介サーバーは前記携帯通信機器から受信した現在位置情報が前記地理座標範囲に対応する場合には、前記ウェブサイトの情報を前記携帯通信機器へ送信し、前記携帯通信機器は送信された情報に基づいて前記ウェブサイトへアクセスし、暗号化された前記現在位置情報がクッキーとして記録されることを特徴とする請求項８のログオン支援方法。
【請求項１０】
前記現在位置情報に対応するクッキーのデータには位置を示すデータは含まれておらず、クッキーの所有者の情報との関連付けによって位置情報履歴が記録されることを特徴とする請求項９のログオン支援方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯端末がインターネット上のサイトへアクセスする為の、簡易的なログオン支援システムに関する。
【背景技術】
【０００２】
近年、携帯電話、ＰＨＳ（PersonalHandyphoneSystem）、スマートフォン等の携帯端末装置の利用範囲が飛躍的に広がってきている。特に通話機能の他にデータ通信機能が強化され、ユーザーに対してインターネットを介した種々の情報提供サービスが提供されている。一方で、情報提供を行うユーザーを限定したいという場面も多くなっており、ＩＤとパスワードを利用する方法や、個体識別を行う方法などを用いてユーザー確認が行われている（特許文献１）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−３３２２８２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、ＩＤとパスワードを利用する方法は、ユーザーに面倒な登録操作や認証操作を要求するので、使い勝手が良いとは言えない。携帯端末自体の個体識別を行う方法は非常に簡単であるが、必ずしも安全とは言えなく、また急速に普及しているスマートフォンでは難しいという問題がある。
【０００５】
そこで、本発明の目的は、ユーザーに特別な処理を要求すること無く、そのユーザーがアクセス権を有するかどうかをサーバー側で判断を行うことを可能とするログオン支援システムを提供することである。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明のログオン支援システムは、予め定められ、夫々のユーザーに共通する特定の場所を訪れていることをアクセス許可の要件とするウェブサイトへのログオン支援方法であって、夫々のユーザー毎に、使用する携帯通信機器の現在位置情報の変化を位置情報履歴として記録し、或るユーザーから前記ウェブサイトへのアクセス要求があった場合、前記或るユーザーの位置情報履歴から、当該ユーザーが前記特定の場所を訪れている記録を検索し、前記検索の結果に基いて、前記アクセス要求を許可するか否かを決定する。
【発明の効果】
【０００７】
本発明に係わるログオン支援システムによれば、携帯通信機器側で位置情報履歴を自動的に蓄積保存する。サーバーでは、この位置情報履歴に基づいて、当該携帯通信機器を持つユーザーにアクセス権があるかどうかを決定する。従って、アクセス権のあるユーザーは、特別な操作を行わずに、アクセス制限のない通常のウェブサイトと同じようにアクセスできる。
【図面の簡単な説明】
【０００８】
【図１】図１は、本発明の実施例１に係るログオン支援システムの全体構成を示す図である。
【図２】図２は、本発明の実施例１に係るログオン支援システムにおいて、携帯通信機器に蓄積される履歴データベースの構成を示す図である。
【図３】図３は、本発明の実施例４に係るログオン支援システムの全体構成を示す図である。
【図４】図４は、本発明の実施例４に係るログオン支援システムで用いる暗号方法を説明する図である。
【図５】図５は、本発明の実施例４に係るログオン支援システムで用いる暗号方法を説明する図である。
【図６】図６は、本発明の実施例４に係るログオン支援システムで用いる暗号方法を説明する図である。
【発明を実施するための形態】
【０００９】
以下、添付図面を参照しながら本発明の実施形態によるログオン支援システムを説明する。利用する携帯通信機器としては、現在位置情報の取得が可能で、インターネットへの通信機能を備えたものを想定する。具体的には、一般的な携帯電話、スマートフォンと呼ばれるタッチパネル付きの多機能携帯電話、タブレット型コンピュータが含まれる。現在位置情報の取得方法としては、ＧＰＳ（GlobalPositioningSystem）や、基地局による三角測量などがある。
【実施例１】
【００１０】
この実施例では、大学に通学または通勤している人が携帯する携帯通信機器３を特定し、その携帯通信機器３からの大学のウェブサイトへのアクセスを許可し、一般の端末からのアクセスにはＩＤやパスワードの提示を求めるシステムを説明する。
【００１１】
図１は、本発明の実施例１に係るログオン支援システムの全体構成を示す図である。すなわち、このシステムは、インターネットに接続した大学のサーバー１にインストールされているウェブサイトと、ユーザーが携帯する携帯通信機器３にインストールされているブラウザとユーティリティプログラムを含んでいる。この実施例では、ブラウザには以下に説明するこのシステムに必要な機能が組み込まれている。そのような機能の組み込みは、プラグインのような補助プログラムの利用などで実装される。
【００１２】
ユーティリティプログラムは、定期的に衛星５を利用したＧＰＳまたは基地局７による現在位置情報を取得して、携帯通信機器３の内部の記録領域に取得された位置情報の履歴を蓄積する。この履歴のデータベースの構成を図２に示す。この履歴データベースには、記録の行われた日時と、緯度、経度、その時に通信を行なっている基地局７を特定する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=」が追記されることになる（図６）。
【００３７】
このウェブサイトへアクセスすると、サーバー１は、クッキー名「２０１１０８」の値と、クッキー名「２０１１０９」の値を読み出す。そして、上記のように、位置情報履歴が正しいかどうかを確認してから、アクセスの条件、例えば過去一ヶ月の訪問回数（位置情報データの数）が規定を上回っているかどうかにより、アクセスの可否を判断する。このような方法により、サーバー１はユーザーのデータを一切保持すること無く、位置情報履歴の制御を行うことが出来る。
【産業上の利用可能性】
【００３８】
以上のように、本発明によるログオン支援システムによれば、ユーザーに負担をかけることなくアクセス制御を行うことができ、アクセスが期待されるユーザーを効果的にサイトへ誘導できる。
【符号の説明】
【００３９】
１サーバー
３携帯通信機器
５衛星
７基地局
９ログオン仲介サーバー
【図１】
0005991727.tif 000002
【図２】
0005991727.tif 000003
【図３】
0005991727.tif 000004
【図４】
0005991727.tif 000005
【図５】
0005991727.tif 000006
【図６】
0005991727.tif 000007