JP2016128988A - 情報処理システム、情報処理装置の制御方法、及びプログラム - Google Patents

Abstract

【課題】サービスをモバイル端末に提供する際に、アプリケーション開発者が利用可能なセキュアなＡＰＩ認証・認可機構を提供する。【解決手段】ビーコン認証ＡＰＩ３２１は、ビーコン発信機から発信されるビーコンをクライアントコンピュータ１２２が受信したとき、クライアントコンピュータ１２２の識別情報を取得して認証を行い、認可ＡＰＩ３０４は、ビーコン認証ＡＰＩ３２１によりクライアントコンピュータ１２２の認証がされたとき、クライアントコンピュータ１２２へ認可トークンを発行する。認可ＡＰＩ３０４は、クライアントコンピュータ１２２からの認可トークンを用いたリソースの呼出し要求があったとき、認可トークンが有効であるか否かを検証し、ビーコン認証ＡＰＩ３２１は、認可トークンが有効であると検証されたとき、ビーコンに基づくイベントの内容に応じて、アプリケーション３３１に対してリソースの利用を許可する。【選択図】図３

Description

本発明は、情報処理システム、情報処理装置の制御方法、及びプログラムに関する。

近年、スマートフォンやタブレットコンピューター等のモバイル端末が急速に普及している。そして、このようなモバイル端末に対して、インターネット上のアプリケーションストア等を通じ、開発したアプリケーションを容易に公開または販売できる仕組みが存在する。また、モバイル端末向けのアプリケーション開発において、モバイル端末単体では実現困難な機能をインターネット上のＷｅｂサービスとして提供し、Ｗｅｂサービス利用料金を徴収するサービス事業も存在する。特に、サーバーサイドでのコード開発やサーバ運用が不要であり、ＷｅｂサービスＡＰＩを利用した分だけ課金するというＢａａＳ（Ｂａｃｋｅｎｄ ａｓ ａ Ｓｅｒｖｉｃｅ）というＷｅｂサービス提供形態が現れ始めている。

また近年、店舗等にビーコンを設置し、モバイル端末をビーコン受信機として利用可能な、Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙという無線通信規格を利用した製品やサービスが普及しつつある。例えば、モバイル端末がビーコンのエリア内に入ったのを検出すると、モバイル端末にクーポン券を配信するなどのユースケースが存在する。

さらに、その他のビーコン情報を活用したアプリケーションのユースケースとして、ゲームアプリでご当地限定のアイテムを配信する場合、アイテムの配信はビーコンのエリア内のみで１回限りとする回数制限があるケース。また、合計10回までクーポン券を発行可能であるが、発行する場所は問わないケースが存在する。

また、個人用のモバイル端末で会社内リソースにアクセスする場合に、モバイル端末がビーコンのエリア内（会社の建物内）に存在する時のみ、会社内リソースを利用可能とし、エリア外に出た際には会社内リソースを利用不可能にするケースが存在する。そして、上述のような多様なユースケースを実現するためには、モバイル端末が受信したビーコンのエリア情報に応じて、利用可能なリソースの範囲や回数を制限する必要がある。

また、特許文献１は、擬似衛星と認証サーバが、配置情報と認証ＩＤを共有することにより、擬似衛星から発信される信号の正当性を保証して、所定の位置の電子機器からのみ企業内システムへのアクセスを許可する技術を開示している。

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

しかしながら、特許文献１は、擬似衛星と認証サーバが、信号の正当性を保証し、所定の位置の電子機器からのみ企業内システムへのアクセスを許可する技術を開示している。しかしながら、利用するリソースの範囲や回数を制限するＡＰＩ認証・認可の仕組みを提供することはできない。例えば、モバイル端末がビーコンのエリア内に入り、サービスをこのモバイル端末に提供する際に、アプリケーション開発者が利用可能なセキュアなＡＰＩ認証・認可の仕組みを提供することはできない。

本発明は、上記の問題に鑑みてなされたものであり、モバイル端末が受信したビーコンの識別情報に応じて、利用可能なリソースの範囲や回数を、容易に許可し、制限することが可能な情報処理システムを提供することを目的とする。

本発明に係る情報処理システムは、端末のアプリケーションに対してネットワークを介してリソースを提供する情報処理システムであって、前記端末が発信装置から発信されるビーコンを受信したとき、前記端末の識別情報を取得し、前記端末の認証を行う認証手段と、前記認証手段により認証がされたとき、認可トークンを発行する認可手段とを備え、前記認可手段は、前記端末からの前記認可トークンを用いて前記リソースの呼出し要求があったとき、前記認可トークンが有効であるか否かを検証し、前記認証手段は、前記認可手段により前記認可トークンが有効であると検証されたとき、前記ビーコンに基づくイベントの内容に応じて、前記端末の前記アプリケーションに対して前記リソースの利用を許可することを特徴とする。

本発明によれば、端末が受信したビーコンの識別情報に応じて、利用可能なリソースの範囲や回数を、容易に許可し、制限することができる。

本発明の一実施形態に係るシステム全体の構成を示す図である。 情報処理装置のハードウェアの構成を示す図である。 本発明のシステムに係るソフトウェアの構成を示す図である。 サービス利用登録処理と各設定値登録処理のシーケンス図である。 利用登録画面とＡＰＩアクセス許可設定画面の一例を示す図である。 ビーコン認証オプション設定画面と詳細設定画面の一例を示す図である。 ビーコン判定条件設定画面の一例を示す図である。 クライアント登録処理のシーケンス図である。 ビーコン受信、イベント記録、トークン発行処理のシーケンス図である。 エリア滞在およびエリア外に出た場合の処理のシーケンス図である。 トークン検証処理とビーコン条件判定結果の処理のシーケンス図である。 リソース要求ＡＰＩ処理のシーケンス図である。 ビーコン条件判定処理のシーケンス図である。 ビーコン条件判定処理のシーケンス図である。

以下、本発明を実施するための最良の形態である情報処理システム、情報処理システムの制御方法およびコンピュータープログラムについて図面などを用いて説明する。

本実施形態では、Ｗｅｂサービスからアプリケーションに対してセキュアなＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）認可手段を提供するために、インターネット標準であるＯＡｕｔｈ ２．０に準拠した構成とする。特に、モバイル端末向けアプリケーションに対して、端末ごとにアクセス制御を実施可能とするために、ＯＡｕｔｈ ２．０のＣｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ ＧｒａｎｔによるＡＰＩ認可手段を提供する。

図１は、本実施形態に係る情報処理システム全体の構成を示す図である。まず、ネットワーク１０１は、各装置間で通信を行うための基盤であって、インターネットまたはイントラネットなどであってよい。ネットワーク機器１０２は、ネットワーク同士を接続するルータやスイッチなどであってよい。ファイアウォール１０３は、ネットワーク間の通信許可の制御を行う。ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０５は、コンピューター等の機器を接続する末端のネットワークであり、有線通信のネットワークに限らず、無線ＬＡＮや携帯電話通信ネットワークなどの無線通信網であってもよい。

アプリケーションサーバー１１１は、ネットワーク１０１を介して接続されており、クライアントコンピューター（端末）１２１、１２２とデータ通信可能である。クライアントコンピューター１２１、１２２は、パーソナルコンピューター、タブレットコンピューター、スマートフォンなどであってよい。ビーコン発信機１３１（発信装置）は、ビーコン受信機能を備え、クライアントコンピューター１２２と無線通信によって情報の送受信が可能である。

図２は、アプリケーションサーバー１１１、クライアントコンピューター１２１、１２２のハードウェアの構成を示す図である。ユーザーインターフェース２０１は、ディスプレイ、キーボード、マウス、タッチパネルなどであり、情報の入出力を行う。なお、これらのハードウェアを備えないコンピューターは、リモートデスクトップやリモートシェルなどにより、他のコンピューターから接続または操作することも可能である。

ネットワークインターフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピューターやネットワーク機器との通信を行う。ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０４は、組込済みプログラムおよびデータが記録されている。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０５は、ＣＰＵ２０３の一時メモリ領域である。ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）２０６は、二次記憶装置である。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０３は、ＲＯＭ２０４、ＲＡＭ２０５、ＨＤＤ２０６などから読み込んだプログラムを実行する。各ユニットは、入出力インターフェース２０７を介して接続されている。

図３は、本実施形態のシステムに係るソフトウェア構成を示す図である。アプリケーションサーバー１１１は、ＨＴＴＰサーバーモジュール３０１、Ｗｅｂアプリケーション３０２、データベース３０５を備える。ＨＴＴＰサーバーモジュール３０１は、クライアントからのＷｅｂアクセスの要求と応答の通信を管理、制御し、必要に応じて要求をＷｅｂアプリケーション３０２に転送する。Ｗｅｂアプリケーション３０２は、ブラウザーにＨＴＭＬ等のＷｅｂドキュメントや操作画面を提供するＷｅｂＵＩ３０３と、ＲＥＳＴに代表されるようなＷｅｂサービスＡＰＩにより認可処理を受け付ける認可ＡＰＩ３０４を備える。

また、Ｗｅｂアプリケーション３０２は、ＲＥＳＴに代表されるようなＷｅｂサービスＡＰＩにより、各種の処理を受け付けるリソースＡＰＩ３１３を備える。リソースＡＰＩ３１３は、データの追加、読出、更新、削除など必要な処理を実行し、クライアントからのＡＰＩ呼出し要求に対する応答を生成して、ＨＴＴＰサーバーモジュール３０１を介してクライアントに応答を返す。なお、リソースサーバーが提供する機能は、様々な機能が考えられる。よって、Ｗｅｂアプリケーション３０２のみでは実行できない場合は、不図示の他のアプリケーションや他のサーバに機能の実行を依頼して、応答を得ることも可能である。

また、Ｗｅｂアプリケーション３０２は、ビーコン発信機１３１の認証処理やビーコン情報の管理を行うビーコン認証ＡＰＩ３２１を備える。データベース３０５は、Ｗｅｂアプリケーション３０２が使用する各種データを格納する。データベース３０５は、Ｗｅｂアプリケーション３０２からの要求に応じて、各種テーブルのレコードを追加、読出、更新、削除を行う。なお、図３においては、１つのアプリケーションサーバー１１１に、ＷｅｂＵＩ３０３、認可ＡＰＩ３０４（認可手段）、リソースＡＰＩ３１３、ビーコン認証ＡＰＩ３２１を構成するように図示したが、それぞれ別々のサーバに構成することも可能である。同様にデータベース３０５も、別のサーバに構成することが可能である。

次に、クライアントコンピューター１２１の備えるブラウザー３１１は、ＷｅｂＵＩ３０３が提供するＨＴＭＬ等のＷｅｂドキュメントや操作画面を受信して表示し、ユーザによる操作結果などをＷｅｂＵＩ３０３に送信する。また、クライアントコンピューター１２２の備えるアプリケーション３３１は、クライアント登録・管理部３４１、リソース利用部３４２、ビーコン受信部３４３を備える。クライアント登録・管理部３４１は、認可ＡＰＩ３０４からアプリケーション３３１のインスタンスごとに固有のクライアントＩＤの発行を受けて管理する。

リソース利用部３４２は、リソースＡＰＩ３１３を呼び出して、アプリケーション３３１の動作に必要なデータの追加、読出、更新、削除などを実行する。ビーコン受信部３４３は、クライアントコンピューター１２２が備えるビーコンによる通信機能を利用して、ビーコン発信機１３１と通信して必要な情報を送受信する。また、ビーコン受信部３４３は、ビーコン認証ＡＰＩ３２１を呼び出して、ビーコン発信機の認証処理の中継や、ビーコン情報の送受信を行う。

ここで、図３の構成において、各モジュールのＯＡｕｔｈ ２．０に対応するロールを説明する。認可ＡＰＩ３０４が、ＯＡｕｔｈ ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｓｅｒｖｅｒロールである。リソースＡＰＩ３１３が、ＯＡｕｔｈ ２．０のＲｅｓｏｕｒｃｅ Ｓｅｒｖｅｒロールである。アプリケーション３３１が、ＯＡｕｔｈ ２．０のＣｌｉｅｎｔロールおよびＲｅｓｏｕｒｃｅ Ｏｗｎｅｒロールである。以降の説明では、各モジュールは前記のＯＡｕｔｈのロールとしてＡＰＩ認可フローを実行する。なお、本文中あるいは図中における「クライアント」とは、ＯＡｕｔｈ ２．０のＣｌｉｅｎｔロールとして、認可ＡＰＩ３０４およびリソースＡＰＩ３１３などのＷｅｂサービスＡＰＩの要求元として動作する個々のアプリケーション３３１の事を示す。

表１〜９は、アプリケーションサーバー１１１が備えるデータベース３０５の各種テーブルを示す。

表１は、テナント管理テーブルである。テナントＩＤを格納するカラムを備える。テナントＩＤは、アプリケーションサーバーの提供するＷｅｂサービスが、様々な組織や個人などに利用される場合、セキュアにリソースを分離するための単位である。上述のようなシステムは、一般にマルチテナントシステムと呼ばれる。

表２は、ユーザ管理テーブルである。ユーザが所属するテナントＩＤを格納するカラム、ユーザＩＤを格納するカラム、ユーザのメールアドレスを格納するカラム、ユーザのパスワードを格納するカラム、ユーザが所属するテナントにおいて付与されている権限を格納するカラムを備える。本実施形態では、テナント内のすべてのデータに対する権限を持つテナント管理者と、制限された権限のみを持つ一般というユーザ権限があるものとする。

表３は、クライアント管理テーブルである。クライアントＩＤを格納するカラム、クライアントのシークレットを保存するカラムを備える。また、クライアントが所属するテナントＩＤを格納するカラム、クライアントの種別を格納するカラムを備える。なお、クライアントの種別には、テナントの管理権限を持つマスターと制限された権限のみを持つ一般のクライアント権限がある。また、クライアントのＤＮを格納するカラムを備え、クライアント管理テーブルにより、ＯＡｕｔｈ ２．０のＣｌｉｅｎｔを個別に識別して管理する。

表４は、クライアント証明書管理テーブルである。クライアント証明書のシリアル番号を格納するカラム、証明書の発行者を格納するカラムを備える。また、証明書の主体者を格納するカラム、証明書の有効期間の開始日時を格納するカラムを備える。そして、証明書の有効期間の終了日時を格納するカラム、テナントマスターＤＮ（Ｄｉｓｔｉｎｇｕｉｓｈｅｄ Ｎａｍｅ）を格納するカラムを備える。

表５は、ビーコン認証オプション管理テーブルである。テナントＩＤを格納するカラム、ビーコン認証オプションの設定対象が、ＡＰＩまたはスコープの種別を格納するカラムを備える。また、ビーコン認証オプションの設定対象であるＡＰＩまたはスコープを格納するカラム、設定対象に対して、ビーコン認証オプションが有効または無効であることを示す真偽値を格納するカラムを備える。ビーコン識別情報を格納するカラムを備える。本実施形態では、Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙを適用した場合の仕様であり、ｐｒｏｘｉｍｉｔｙＵＵＩＤ， ｍａｊｏｒ， ｍｉｎｏｒの３つの値を格納する場合の実施例を示す。記号*が値としてセットされている場合、任意の値に対して本設定が有効であることを示す。また、表５は、利用可能エリア制限の種別を格納するカラムを設定対象ごとのＡＰＩ利用上限回数を格納するカラムを備える。ビーコン判定条件ＩＤを格納するカラムを備える。

表６は、ビーコン判定条件管理テーブルである。テナントＩＤを格納するカラム、ビーコン判定条件ＩＤを格納するカラムを備える。また、設定種別ＩＤを格納するカラム、設定が有効であるか否かを示す真偽値を格納するカラム、設定毎の判定時間を格納するカラムを備える。

表７は、ビーコンイベント管理テーブルである。イベントの日時を格納するカラム、ビーコン識別情報を格納するカラムを備える。また、イベントの発生内容を格納するカラム、イベントの発生元であるクライアントＩＤを格納するカラムを備える。

表８は、認可トークン管理テーブルである。認可トークンＩＤを格納するカラム、スコープを格納するカラムを備える。認可トークンの発行対象のクライアントＩＤを格納するカラムを備える。認可トークンの有効期限を格納するカラムを備える。

表９は、ＡＰＩ呼出し回数管理テーブルである。ＡＰＩ呼出し回数管理テーブルは、クライアントＩＤを格納するカラム、ＡＰＩ呼出し回数集計の対象ＡＰＩを格納するカラムを備える。また、クライアントから呼び出されて利用されたＡＰＩ利用回数を格納するカラム、クライアントからＡＰＩが呼び出された最終アクセス成功日時を格納するカラムを備える。

次に、図４、５、６および７を用いて、アプリケーションサーバー１１１が提供するＷｅｂサービスに利用登録する処理について説明する。なお、利用登録するユーザは、アプリケーション３３１の開発者を主たるユーザとする。まず、ブラウザー３１１は、ＷｅｂＵＩ３０３に対して、利用登録画面の取得要求を行う（ステップＳ４０１）。次に、ブラウザー３１１は、ＷｅｂＵＩ３０３が提供する利用登録画面５００を取得して（ステップＳ４０２）、ブラウザー３１１に表示する（ステップＳ４０３）。

ここで、図５に示す利用登録画面５００について説明する。利用者情報入力フィールド５０１は、ユーザのメールアドレスやパスワードを入力するフィールドである。料金メニュー選択フィールド５０２は、料金メニューを選択するフィールドである。ＷｅｂＵＩ３０３は、料金メニュー選択フィールド５０２にＡＰＩ課金メニューの選択肢を提供する画面を表示する。本実施形態では、月ごとのＡＰＩ呼出し上限数に対して、従量課金をする実施例を提示したが、課金体系は様々なものであってよい。なお、本実施形態では、任意の課金体系を取り得るものとする。登録ボタン５０３は、利用登録要求を送信するボタンである。

ここで、図４の説明に戻る。ユーザは、利用者情報を利用者情報入力フィールド５０１に入力し、料金メニュー選択フィールド５０２から料金メニューを選択する。そして、登録ボタン５０３を押下して、ＷｅｂＵＩ３０３に利用登録要求を送信する（ステップＳ４０４）。

次に、ＷｅｂＵＩ３０３は、まず表１に示すテナント管理テーブルにテナントＩＤを新規追加する。次に、ＷｅｂＵＩ３０３は、入力された利用者情報に従って、表２に示すユーザ管理テーブルに、ユーザのレコードを追加し、権限のカラムにテナント管理者を付与する。前述の処理により、ユーザは作成されたテナントの設定値などを変更することができる。また、ＷｅｂＵＩ３０３は、表３に示すクライアント管理テーブルに、種別カラムがマスターのクライアントを１つ作成する。

次に、作成したマスタークライアントのＤＮと同一のテナントマスターＤＮを保持するクライアント証明書を作成し、その他の証明書情報を表４に示すクライアント証明書管理テーブルに格納する（ステップＳ４０５）。そして、登録処理が完了すると、ブラウザー３１１に登録完了を応答する（ステップＳ４０６）。次に、ブラウザー３１１は、ＷｅｂＵＩ３０３にＡＰＩアクセス許可設定画面５１０の取得要求を行う（ステップＳ４０７）。次に、ＷｅｂＵＩ３０３が、ＡＰＩアクセス許可設定画面５１０を取得してブラウザー３１１に応答し（ステップＳ４０８）、ブラウザー３１１に表示する（ステップＳ４０９）。

ここで、図５に示すＡＰＩアクセス許可設定画面（スコープ設定）５１０について説明する。スコープ使用選択フィールド５１１は、ＯＡｕｔｈ ２．０のオプション属性であるスコープ（Ｓｃｏｐｅ）を用いるか否かを選択するフィールドである。ＡＰＩおよびスコープ設定フィールド５１２は、ＡＰＩごとのＵＲＩおよびスコープを表示するフィールドである。スコープを使用しない場合、クライアント認証を受けた正当なクライアントは、認可トークンを発行して、任意のＡＰＩを呼び出すことが可能である。一方、スコープを使用する場合、ＡＰＩごとに必要なスコープが決まっているので、用途に応じて、必要なスコープを指定して認可トークンを発行要求する。

そして、発行された認可トークンを用いてＡＰＩを呼び出すことにより、スコープの範囲内のＡＰＩのみの呼出しが許可され、アクセスが可能となる。前述の処理により、ＡＰＩごとのアクセス権をスコープという単位で区分することが可能である。そして、スコープが指定された認可トークンを持つクライアントからの目的のＡＰＩへのアクセスのみを許可することができる。

ここで、図４に示すステップＳ４０７の説明に戻る。ブラウザー３１１は、ＷｅｂＵＩ３０３対して、ビーコン認証オプション設定画面６００の取得要求を行う（ステップＳ４０７）。次に、ＷｅｂＵＩ３０３からビーコン認証オプション設定画面６００を取得して（ステップＳ４０８）、ブラウザー３１１に表示する（ステップＳ４０９）。また、ビーコン認証オプション設定画面６００内の詳細設定ボタンが押下された場合、詳細設定画面６１０を取得して、ブラウザー３１１表示する。同様に、ビーコン認証オプション設定画面６００内のビーコン判定条件設定ボタンが押下された場合は、ビーコン判定条件設定画面７００を取得して、ブラウザー３１１に表示する。

ここで、図６に示すビーコン認証オプション設定画面６００について説明する。ビーコン認証オプション選択フィールド６０１は、ビーコン認証オプションをＡＰＩ単位またはスコープ単位のいずれかで設定するかを選択するフィールドである。ビーコン情報入力フィールド６０２は、ビーコン認証オプション選択フィールド６０１でＡＰＩ単位が選択された場合は、設定対象ＡＰＩ名を表示する。そして、ビーコン情報入力フィールド６０２は、ＡＰＩごとにビーコン認証オプションの有効または無効の選択値、ビーコン識別情報を入力するフィールドである。

一方、ビーコン認証オプション選択フィールド６０１でスコープ単位が選択された場合は、設定対象スコープ名を表示し、スコープごとにビーコン認証オプションの有効または無効の選択値、ビーコン識別情報を入力するフィールドとなる。設定ボタン６０３を押下すると、ブラウザー３１１からＷｅｂＵＩ３０３に設定要求が送信される（ステップＳ４１０）。そして、フィールドに入力された値が、表５に示すビーコン認証オプション管理テーブルに保存され（ステップＳ４１１）、ＷｅｂＵＩ３０３が設定要求に応答する（ステップＳ４１２）。

次に、図６に示すビーコン認証オプションの詳細設定画面６１０について説明する。利用可能エリア選択フィールド６１１は、設定対象ＡＰＩが、ビーコンのエリア内外問わず利用可能かエリア内のみで利用可能かを選択し、選択した利用可能エリアにおいて、クライアントＩＤごとにＡＰＩの制限回数を設定するフィールドである。そして、設定ボタン６１２を押下すると、フィールドで入力された値が、表５に示すビーコン認証オプション管理テーブルに保存される。

次に、図７に示すビーコン判定条件の設定画面７００について説明する。判定時に使用する時間入力フィールド７０１は、ビーコン判定条件の基本設定による判定時に使用する時間を入力するフィールドである。詳細条件選択フィールド７０２は、詳細条件（１）、（２Ａ）、（２Ｂ）を適用するか否かを選択するフィールドである。なお、詳細条件（１）を選択したときのみ、（２Ａ）および（２Ｂ）を選択することが可能である。

詳細条件の判定時に使用する時間入力フィールド７０３、７０４、７０５は、それぞれ詳細条件（１）、（２Ａ）、（２Ｂ）による判定時に使用する時間を入力するフィールドである。設定ボタン７０６を押下すると、フィールドに入力された値が、表６に示すビーコン判定条件管理テーブルに保存される。また、表６の各設定値がいずれの設定対象ＡＰＩまたはスコープに対するかを識別するために、表５、６で共通のテナントＩＤとビーコン判定条件ＩＤで関連付ける。

判定種別ＩＤカラムには、設定対象が基本設定・詳細条件（１）（２Ａ）（２Ｂ）のいずれの条件であるかを識別するために、それぞれの種別に対応させた値であるＢＡ００１、ＯＰ００１、ＯＰ００２Ａ、ＯＰ００２Ｂを格納する。また、設定有効化カラムには、フィールド７０２でそれぞれの条件に対して選択した真偽値を格納する。そして、判定時間カラムには、フィールド７０１〜７０５で入力した値を格納する。

ここで、図４に示すステップＳ４１３の説明に戻る。ブラウザー３１１は、クライアント証明書取得要求をＷｅｂＵＩ３０３に送信する（ステップＳ４１３）。そして、ＷｅｂＵＩ３０３は、作成したクライアント証明書を読み出して（ステップＳ４１４）、ブラウザー３１１に応答する（ステップＳ４１５）。

次に、図８を用いて、クライアントの登録処理と認可トークンの発行処理について説明する。なお、アプリケーション３３１には、あらかじめ取得したクライアント証明書がアプリケーション３３１の開発者によって組み込まれており、クライアント証明書が組みこまれたアプリケーション３３１が、クライアントコンピューター１２２に配布される。

まず、クライアント登録・管理部３４１は、ＨＴＴＰサーバーモジュール３０１にクライアント登録要求を送信する（ステップＳ８０１）。次に、ＨＴＴＰサーバーモジュール３０１は、クライアント登録要求に対して、クライアント証明書を呼出元に要求する。そして、クライアント登録・管理部３４１は、クライアント証明書をＨＴＴＰサーバーモジュール３０１に送信する。ＨＴＴＰサーバーモジュール３０１は、受信したクライアント証明書が有効である場合（ステップＳ８０２）、クライアント登録要求を認可ＡＰＩ３０４に送信する（ステップＳ８０３）。

本実施形態では、アプリケーション３３１が、アプリケーションサーバー１１１の正当なクライアントであることを認証するためにクライアント証明書を用いているが、Ｂａｓｉｃ認証やＤｉｇｅｓｔ認証など他の認証方式であってもよい。そして、認可ＡＰＩ３０４は、受信したクライアント証明書から得られたシリアル番号を用いて、表４に示すクライアント証明書管理テーブルを検索し、テナントマスターＤＮを特定する。さらに、認可ＡＰＩ３０４は、表３に示すクライアント管理テーブルを検索し、前記特定したテナントマスターＤＮと同じＤＮを持つレコードを取得する（ステップＳ８０４）。

次に、認可ＡＰＩ３０４は、前記取得したレコードのクライアント種別がマスターであることを検証し、該当レコードのテナントＩＤを読み出す。認可ＡＰＩ３０４は、表３に示すクライアント管理テーブルにレコードを追加し、ＵＵＩＤに代表されるようなユニークなＩＤを採番してクライアントＩＤカラムに格納する。また、読み出したテナントＩＤをテナントＩＤカラムに格納する。そして、シークレットカラムに自動生成したシークレットを格納し、種別カラムには一般を格納する（ステップＳ８０５）。

次に、認可ＡＰＩ３０４は、クライアント登録・管理部３４１にクライアント登録要求の応答として、生成したクライアントＩＤとシークレットを返信する（ステップＳ８０６）。クライアント登録・管理部３４１は、受信したクライアントＩＤとシークレットを、読み出し可能なように記憶領域に保存する（ステップＳ８０７）。

以上がアプリケーション３３１をクライアントとしてアプリケーションサーバー１１１に登録する処理である。前述の処理により、アプリケーションサーバー１１１が発行したクライアント証明書を持つ正当なクライアントのみがアプリケーションサーバー１１１にクライアントとして登録できる。

次に、図９、１０、１１、１２、１３および１４を用いて、ビーコンのエリア内に入った際に、ビーコン認証を実行し、ビーコン認証成功時に認可トークンを発行要求して、認可トークンを使用してリソースＡＰＩを呼び出す処理について説明する。まず、ビーコン受信部３４３およびリソース利用部３４２は、クライアント登録・管理部３４１にクライアントＩＤの取得要求を行う（ステップＳ９０３）。そして、クライアント登録・管理部３４１からクライアントＩＤを取得し、利用可能に保存する（ステップＳ９０４）。

次に、ビーコン受信部３４３が、ビーコン発信機１３１が発信するビーコンを受信して検知する（ステップＳ９０５）。また、受信を検知した際に、ビーコン受信部３４３は、ビーコン識別情報であるＰｒｏｘｉｍｉｔｙＵＵＩＤ、Ｍａｊｏｒ、Ｍｉｎｏｒの値を取得する。そして、ビーコン発信機が正当なものであるか否かを確認するため、ビーコン認証処理を行う。正当な機器であるか否かを判定するため、様々な手段を利用することが可能であるが、本実施形態では、事前にビーコン発信機とビーコン認証ＡＰＩが同一の秘密鍵を保持する手段により、ビーコン認証を行う実施形態を示す。

まず、ビーコン受信部３４３は、ビーコン認証ＡＰＩ３２１に、ビーコン認証チャレンジ文字列要求をビーコン識別情報とともに送信する（ステップＳ９０６）。次に、ビーコン認証ＡＰＩ３２１は、ビーコン認証チャレンジ文字列を応答する（ステップＳ９０７）。そして、ビーコン受信部３４３は、ビーコン認証ＡＰＩ３２１が応答したチャレンジ文字列をビーコン発信機１３１に送信する（ステップＳ９０８）。次に、ビーコン発信機１３１は、受信したチャレンジ文字列を秘密鍵で暗号化し、暗号化文字列としてビーコン受信部３４３に返信する（ステップＳ９０９）。そして、ビーコン受信部３４３は、ビーコン認証ＡＰＩ３２１に、暗号化文字列およびクライアントＩＤを送信する（ステップＳ９１０）。

次に、ビーコン認証ＡＰＩ３２１は、受信した暗号化文字列が、チャレンジ文字列が所定の秘密鍵で暗号化されたものか否かを判定する（ステップＳ９１１）。所定の秘密鍵で暗号化されたものである場合（ＹＥＳ）、ビーコン認証ＡＰＩ３２１は、表７に示すビーコンイベント管理テーブルに、日時、ビーコン識別情報、イベント、クライアントＩＤを記録する（ステップＳ９１２）。そして、ビーコン認証ＡＰＩ３２１は、ビーコン認証チャレンジ結果成功をビーコン受信部３４３に応答する（ステップＳ９１３）。

一方、ステップＳ９１１において、チャレンジ文字列が所定の秘密鍵で暗号化されたものでない場合（ＮＯ）、ビーコン認証ＡＰＩ３２１は、ビーコン認証チャレンジ結果失敗をビーコン受信部３４３に応答する。次に、ビーコン受信部３４３は、受信した応答から、ビーコン認証チャレンジ結果が成功か否かを判定する（ステップＳ９１４）。そして、ビーコン認証チャレンジ結果が失敗の場合（ＮＯ）、正当なビーコンではないため、処理を中止する。一方、ビーコン認証チャレンジ結果が成功の場合（ＹＥＳ）、ビーコンのエリア入イベントをビーコン識別情報とともに、リソース利用部３４２に通知する（ステップＳ９１５）。

次に、リソース利用部３４２は、受信したビーコン識別情報に基づき、該当のビーコンのエリア内に入った端末に提供するサービスの処理を開始する。例えば、店舗に来店した場合にクーポン券を配信する、会社に到着した場合に今日のスケジュールを配信する等、ビーコン識別情報に基づいて、様々なサービス処理を切り替えることができる。

次に、リソース利用部３４２は、認可ＡＰＩ３０４に対し認可トークン発行要求をクライアントＩＤ、シークレット、スコープのパラメーターとともに送信する（ステップＳ９１６）。そして、認可ＡＰＩ３０４は、受信したクライアントＩＤ、シークレットが表３に示すクライアント管理テーブルに存在し、一致することを検証して、要求元のクライアントを認証する。認証に成功した場合、表８に示す認可トークン管理テーブルに、レコードを追加して認可トークンを生成する（ステップＳ９１７）。

また、追加したレコードには、新しく採番した認可トークンＩＤ、受信したパラメーター内のスコープ、受信したクライアントＩＤ、認可トークンの有効期限の日時が格納される。そして、認可ＡＰＩ３０４は、リソース利用部３４２に、認可トークン要求に対して応答する（ステップＳ９１８）。ステップＳ９１７のクライアント認証が失敗した場合、エラー応答を返信する。一方、クライアント認証が成功した場合、認可トークンＩＤと有効期限を返信する。また、ステップＳ９１６において、すでにリソース利用部３４２が認可トークンを保持しているが、有効期限が切れている場合は、上述の処理と同様のフローで、認可トークンを再発行する。そして、ステップＳ１００１に進む。

ここで、図１０を用いてビーコンのエリア内に継続滞在している場合、およびビーコンのエリア外に出た場合のビーコンイベント記録について説明する。まず、ビーコン発信機１３１からのビーコンを、ビーコン受信部３４３が継続して受信している間（ステップＳ９５１）、ビーコン受信部３４３は、エリア内イベントを定期的にビーコン認証ＡＰＩ３２１に通知する（ステップＳ９５２）。

次に、ビーコン認証ＡＰＩ３２１は、表７に示すビーコンイベント管理テーブルに、日時、ビーコン識別情報、イベント、クライアントＩＤを記録して（ステップＳ９５３）、ビーコン受信部３４３に対し確認を応答する（ステップＳ９５４）。一方、ビーコン受信部３４３がビーコン発信機１３１からのビーコンの受信を停止した場合（ステップＳ９６１）、ビーコン受信部３４３は、エリア出イベントをビーコン認証ＡＰＩ３２１に通知する（ステップＳ９６２）。ここで「エリア出」とはビーコンを受信可能なエリア外に出たことを示す。

次に、ビーコン認証ＡＰＩ３２１は、表７に示すビーコンイベント管理テーブルに、日時、受信を停止したビーコン識別情報、イベントの内容にはエリア出、受信したクライアントＩＤを記録する（ステップＳ９６３）。ビーコン認証ＡＰＩ３２１はビーコン受信部３４３に対し確認を応答する（ステップＳ９６４）。

次に、図１１に示すトークン検証処理について説明する、リソース利用部３４２は、リソースＡＰＩ３１３に、リソースＡＰＩ呼出し要求を認可トークンＩＤとともに送信する（ステップＳ１００１）。次に、リソースＡＰＩ３１３は、受信した認可トークンＩＤとスコープ設定フィールド５１２に基づいてＡＰＩアクセスに必要な要求スコープを、認可トークン検証要求として認可ＡＰＩ３０４に送信する（ステップＳ１００２）。

次に、認可ＡＰＩ３０４は、表８に示す認可トークン管理テーブルを検索し、受信した認可トークンの認可トークンＩＤを持つレコードが存在し、かつ、現在日時が所定の時間以内であることを検証する。また、認可トークンの発行先のクライアントＩＤが、表３に示すクライアント管理テーブルに存在することを確認し、対応するクライアントＩＤが有効であることを確認する（ステップＳ１００３）。そして、認可ＡＰＩ３０４は、ステップＳ１００３の検証処理の結果に基づいて、受信した認可トークンが有効であるか否かを判定する（ステップＳ１００４）。

受信した認可トークンが有効でない場合（ＮＯ）、認可ＡＰＩ３０４は、認可トークン検証結果としてトークン無効エラーをリソースＡＰＩ３１３に応答する（ステップＳ１００５）。リソースＡＰＩ３１３は、リソース利用部３４２にリソースＡＰＩ呼出しの応答として、トークン無効エラーを返信する（ステップＳ１００６）。

一方、受信した認可トークンが有効である場合（ＹＥＳ）、認可ＡＰＩ３０４はリソースＡＰＩ３１３に、認可トークン検証ＯＫの応答を返信する（ステップＳ１００７）。そして、リソースＡＰＩ３１３は、スコープ使用選択フィールド５１１およびスコープ設定フィールド５１２のスコープ設定に基づいて、ステップＳ１００１で呼び出されたＡＰＩに対し、スコープを利用している場合はＡＰＩ名と対象スコープを特定する。また、スコープを利用していない場合は対象ＡＰＩ名を特定する。

次に、リソースＡＰＩ３１３は、表５に示すビーコン認証オプション管理テーブルを検索し、設定対象カラムの値が前記特定されたＡＰＩまたはスコープに合致するレコードを取得する。そして、取得したレコードのオプション設定カラムから値を取得し、特定されたＡＰＩまたはスコープに対し、ビーコン認証オプションが有効か否かを判定する（ステップＳ１００８）。ビーコン認証オプションが有効でない場合は（ＮＯ）、ステップＳ１０１６に進む。一方、ビーコン認証オプションが有効である場合（ＹＥＳ）、リソースＡＰＩ３１３は、ビーコン認証ＡＰＩ３２１に、クライアントＩＤ、対象ＡＰＩまたはスコープをビーコン条件判定要求として送信する（ステップＳ１００９）。そして、図１３に示すステップＳ１１０１に進む。

次に、ビーコン認証ＡＰＩ３２１は、表５に示すビーコン認証オプション管理テーブルから、対象ＡＰＩまたはスコープに対して許可対象であるビーコン識別情報を取得する。また、表７に示すビーコンイベント管理テーブルから、受信したビーコン条件判定要求に含まれるクライアントＩＤと取得したビーコン識別情報に合致し、かつ、イベントの内容がエリア入またはエリア内であるレコードを取得する（ステップＳ１１０１）。ここで「エリア入」とはビーコンを受信可能なエリア内に入ったことを示し、「エリア内」とはビーコンを受信可能なエリア内にいることを示す。すなわち、受信したビーコンに基づくイベントの内容のレコードを取得する。そして、取得したレコードをビーコン認証ＡＰＩ３２１に応答する（ステップＳ１１０２）。

次に、ビーコン認証ＡＰＩ３２１は、表５に示すビーコン認証オプション管理テーブルを参照し、対象ＡＰＩまたはスコープに対応する利用可能エリア制限種別の値を取得し、制限種別が１または２のいずれかであるかを判定する（ステップＳ１１０３）。制限種別が１の場合、ステップＳ１１０２で取得したレコードの件数が、１件以上であるか判定する（ステップＳ１１０４）。取得したレコードの件数が１件以上でない場合（ＮＯ）、図１４に示すステップＳ１１１８に進み、ビーコン条件判定を失敗にセットする（ステップＳ１１１８）。取得したレコードの件数が１件以上である場合（ＹＥＳ）、図１４に示すステップＳ１１１７に進み、ビーコン条件判定を成功にセットする（ステップＳ１１１７）。

一方、図１３に示すステップＳ１１０３において制限種別が２の場合、ステップＳ１１０５に進む。制限種別が２の場合は、エリア内のみでリソースＡＰＩの利用を許可する設定であり、かつ現在日時が最新エリア入またはエリア内イベントの日時に基本設定の時間Ｐを加えた時間以内であるか否かを判定する（ステップＳ１１０５）。なお、基本設定の時間Ｐは、表６に示すビーコン判定条件管理テーブルの判定種別ＩＤがＢＡ００１のレコードの判定時間の値である。

ステップＳ１１０５において、現在日時が最新エリア入またはエリア内イベントの日時に基本設定の時間Ｐを加えた時間以内でない場合（ＮＯ）、図１４に示すステップＳ１１１８に進む。一方、現在日時が最新エリア入またはエリア内イベントの日時に基本設定の時間Ｐを加えた時間以内であるとする（ＹＥＳ）。この場合、表６に示すビーコン判定条件管理テーブルの設定種別ＩＤがＯＰ００１であるレコードの設定有効化カラムの値が真（有効）であるかを判定する（ステップＳ１１０６）。設定有効化カラムの値が真（有効）でない場合（ＮＯ）、図１４に示すステップＳ１１１７に進む。一方、設定有効化カラムの値が真（有効）である場合（ＹＥＳ）、ステップ１１０７に処理を進める。

次に、ステップＳ１１０２において、取得した最新エリア入またはエリア内イベントの日時より新しく、同一のクライアントＩＤであって、同一のビーコン識別情報に合致するビーコンの最新のエリア出のイベントレコードを取得する（ステップＳ１１０７）。そして、データベース３０５が、ビーコン認証ＡＰＩ３２１にレコード取得結果を応答する（ステップＳ１１０８）。そして、図１４に示すステップＳ１１０９に進む。ビーコン認証ＡＰＩ３２１は、レコード取得結果が０件か否かを判定する（ステップＳ１１０９）。

レコード取得結果が０件でない場合（ＮＯ）、現在日時が取得した最新エリア出イベントの日時に詳細条件（１）の時間Ｑを加えた時間以内であるか否かを判定する（ステップＳ１１１０）。なお、詳細条件（１）の時間Ｑは、表６に示すビーコン判定条件管理テーブルの判定種別ＩＤがＯＰ００１のレコードの判定時間の値である。

最新エリア出イベントの日時に詳細条件（１）の時間Ｑを加えた時間以内でない場合（ＮＯ）、ステップＳ１１１８に進む。一方、最新エリア出イベントの日時に詳細条件（１）の時間Ｑを加えた時間以内である場合（ＹＥＳ）、ステップＳ１１１７に進む。

一方、レコード取得結果が０件である場合（ＹＥＳ）、ステップＳ１１１１に進む。そして、ビーコン認証ＡＰＩ３２１は、表６に示すビーコン判定条件管理テーブルの設定種別ＩＤがＯＰ００２Ａであるレコードの設定有効化カラムの値が真（有効）であるかを判定する（ステップＳ１１１１）。設定有効化カラムの値が真（有効）である場合（ＹＥＳ）、現在日時がステップＳ１１０２で取得した最新エリア入またはエリア内イベントの日時に所定の時間、例えば詳細条件（２）の時間Ｒを加えた時間以内であるかを判定する（ステップＳ１１１２）。なお、詳細条件（２Ａ）の時間Ｒは、表６に示すビーコン判定条件管理テーブルの判定種別ＩＤがＯＰ００２Ａのレコードの判定時間の値である。

最新エリア入またはエリア内イベントの日時に詳細条件（２）の時間Ｒを加えた時間以内である場合（ＹＥＳ）、ステップＳ１１１７に進む。最新エリア入またはエリア内イベントの日時に詳細条件（２）の時間Ｒを加えた時間以内でない場合（ＮＯ）、ステップＳ１１１３に進む。

一方、ステップＳ１１１２の判定において設定有効化カラムの値が真（有効）でない場合（ＮＯ）、ステップＳ１１１３に進む。そして、ビーコン認証ＡＰＩ３２１は、表６に示すビーコン判定条件管理テーブルの設定種別ＩＤがＯＰ００２Ｂであるレコードの設定有効化カラムの値が真（有効）であるか否かを判定する（ステップＳ１１１３）。

設定有効化カラムの値が真（有効）でない場合（ＮＯ）、ステップＳ１１１８に進む。一方、設定有効化カラムの値が真（有効）である場合（ＹＥＳ）、ビーコン認証ＡＰＩ３２１は、表９に示すＡＰＩ呼出し回数管理テーブルから、同一のクライアントＩＤおよび対象ＡＰＩのレコードを取得する（ステップＳ１１１４）。そして、ビーコン認証ＡＰＩ３２１はビーコン認証ＡＰＩ３２１に最終アクセス成功日時を応答する（ステップＳ１１１５）。

次に、ビーコン認証ＡＰＩ３２１は、現在日時が取得した最終アクセス成功日時（最終取得日時）に詳細条件（２Ｂ）の時間Ｓを加えた時間以内であるかを判定する（ステップＳ１１１６）。なお、詳細条件（２Ｂ）の時間Ｓは、表６に示すビーコン判定条件管理テーブルの判定種別ＩＤがＯＰ００２Ｂのレコードの判定時間の値である。

現在日時が取得した最終アクセス成功日時に詳細条件（２Ｂ）の時間Ｓを加えた時間以内でない場合（ＮＯ）、ステップＳ１１１８に進む。一方、現在日時が取得した最終アクセス成功日時に詳細条件（２Ｂ）の時間Ｓを加えた時間以内である場合（ＹＥＳ）、ステップＳ１１１７に進む。

ここで、図１１に戻り、ビーコン認証ＡＰＩ３２１は、ステップＳ１１１７またはステップＳ１１１８でセットされたビーコン条件判定結果を、リソースＡＰＩ３１３に応答する（ステップＳ１０１０）。そして、リソースＡＰＩ３１３は、受信したビーコン条件判定結果が成功か否かを判定する（ステップＳ１０１１）。そして、図１２に示すステップＳ１０１２に進む。ビーコン条件判定結果が成功でない場合（ＮＯ）、リソースＡＰＩ３１３は、リソース利用部３４２にビーコン判定条件エラーを返す（ステップＳ１０１２）。すなわち、ビーコンによるリソース利用許可の条件を満たしていないため、リソースＡＰＩの利用が許可されない。

一方、ビーコン条件判定結果が成功である場合（ＹＥＳ）、図１２に示すステップＳ１０１３に進む。リソースＡＰＩ３１３は、表９に示すＡＰＩ呼出し回数管理テーブルを対象のクライアントＩＤ、ＡＰＩであるＡＰＩ利用回数カラムの値、および、表５に示すビーコン認証オプション管理テーブルのＡＰＩ利用上限回数を読み出す（ステップＳ１０１３）。そして、リソースＡＰＩ３１３は、読み出したＡＰＩ利用回数がＡＰＩ利用上限回数より小さいか否かを判定する（ステップＳ１０１４）。

ＡＰＩ利用回数がＡＰＩ利用上限回数より大きい場合（ＮＯ）、認可ＡＰＩ３０４は、リソースＡＰＩ３１３に、認可トークン検証応答としてＡＰＩ呼出し回数上限到達エラーを返す（ステップＳ１０１９）。そして、リソースＡＰＩ３１３は、リソース利用部３４２に、リソースＡＰＩ応答としてＡＰＩ呼出し回数上限到達エラーを返す（ステップＳ１０２０）。

一方、ＡＰＩ利用回数がＡＰＩ利用上限回数より小さい場合、リソースＡＰＩ３１３は、表９に示すＡＰＩ呼出し回数管理テーブルの対象のクライアントＩＤ、ＡＰＩであるＡＰＩ利用回数カラムの値に１を加算する（ステップＳ１０１５）。そして、リソースＡＰＩ３１３は、ステップＳ１００１で受信したリソース要求の処理を実行し、応答を生成する（ステップＳ１０１６）。

次に、リソースＡＰＩ３１３は、リソース要求ＡＰＩ呼出しに対する応答として、ステップＳ１０１６で生成したリソース要求応答およびＡＰＩ呼出し成功（ＯＫ）をリソース利用部３４２に返信する（ステップＳ１０１７）。そして、リソース利用部３４２は、受信したリソースＡＰＩ応答の処理を実行する（ステップＳ１０１８）。例えば、クーポンの配信を受けた場合、アプリケーション３３１の画面にクーポンを表示する、等のユースケースや取得したリソースによって決まっている処理を実行する。

以上、本実施形態によれば、アプリケーションサーバー１１１は、リソースＡＰＩ３１３へのＡＰＩ利用要求に対して、ＯＡｕｔｈ ２．０の認可フローに準拠したＡＰＩ認可を提供する。特に、クライアントコンピューター１２２のアプリケーション３３１ごとに、クライアントＩＤを設定可能であり、クライアントＩＤごとに受信したビーコンの識別情報に応じて、利用可能なリソースＡＰＩの範囲や回数を許可および制限することが可能である。特に、ＢａａＳを利用する場合は、モバイル端末向けアプリケーションの開発者は、ＡＰＩあるいはスコープごとにビーコン認証オプションを設定する。これによって、ビーコンのエリア検知とＯＡｕｔｈ ２．０の認可フローに準拠したリソースＡＰＩの利用および許可や回数制限を容易に連携させることができる。

（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

また、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

Claims (9)

1. 端末のアプリケーションに対してネットワークを介してリソースを提供する情報処理システムであって、
   前記端末が発信装置から発信されるビーコンを受信したとき、前記端末の識別情報を取得し、前記端末の認証を行う認証手段と、
   前記認証手段により認証がされたとき、認可トークンを発行する認可手段とを備え、
   前記認可手段は、前記端末からの前記認可トークンを用いた前記リソースの呼出し要求があったとき、前記認可トークンが有効であるか否かを検証し、
   前記認証手段は、前記認可手段により前記認可トークンが有効であると検証されたとき、前記ビーコンに基づくイベントの内容に応じて、前記端末の前記アプリケーションに対して前記リソースの利用を許可する
   ことを特徴とする情報処理システム。
2. 前記認可手段は、指定されたスコープの範囲内のリソースのみの呼出しを許可する前記認可トークンを発行することを特徴とする請求項１記載の情報処理システム。
3. 前記認可手段は、前記リソースの利用回数が予め設定された前記リソースの利用上限回数よりも大きい場合、前記端末に通知を行う
   ことを特徴とする請求項１または２記載の情報処理システム。
4. 前記認証手段は、少なくとも前記イベントとして前記端末が前記ビーコンを受信可能なエリア内に入ったこと、前記端末が前記エリアにいること、または前記端末が前記エリア外に出たことのいずれかを取得する
   ことを特徴とする請求項１ないし３のいずれかに記載の情報処理システム。
5. 前記認証手段は、現在日時が前記イベントの日時に所定の時間を加えた時間以内であるとき、前記端末の前記アプリケーションに対して前記リソースの利用を許可する
   ことを特徴とする請求項４記載の情報処理システム。
6. 前記認証手段は、前記イベントの最終取得日時に所定の時間を加えた時間以内であるとき、前記端末の前記アプリケーションに対して前記リソースの利用を許可する
   ことを特徴とする請求項４または５記載の情報処理システム。
7. 前記認可手段は、前記エリア内のみで前記リソースの利用を許可する
   ことを特徴とする請求項４ないし６のいずれか１項に記載の情報処理システム。
8. 端末のアプリケーションに対してネットワークを介してリソースを提供する情報処理システムの制御方法であって、
   前記端末が発信装置から発信されるビーコンを受信したとき、前記端末の識別情報を取得し、前記端末の認証を行う認証工程と、
   前記認証工程により認証がされたとき、認可トークンを発行する認可工程と、
   前記端末からの前記認可トークンを用いて前記リソースの呼び出し要求があったとき、前記認可トークンが有効であるか否かを検証する検証工程と、
   前記認可工程により前記認可トークンが有効であると検証されたとき、前記ビーコンに基づくイベントの内容に応じて、前記端末の前記アプリケーションに対して前記リソースの利用を許可する許可工程とを有する
   ことを特徴とする情報処理システムの制御方法。
9. 請求項８に記載の制御方法をコンピューターに実行させることを特徴とするコンピュータープログラム。
   
   

Images