JP2020119458A - 管理装置およびその制御方法 - Google Patents

Abstract

【課題】アクセス権の付与を効率的に行う。【解決手段】リソースに対する通信装置のアクセス権を管理する管理装置は、アクセス権の認可要求を通信装置から受信し、認可要求に含まれる情報に基づいて生成したデバイス識別子とユーザ識別子とを含む認可応答を通信装置に送信し、通信装置からユーザ識別子を通知され操作移譲がされた通信端末から、ユーザ識別子を含む検証要求を受信し、検証要求に対する応答として、検証用データを通信端末に送信し、通信端末による検証用データに基づくアクセスの受け付けに基づいて、通信装置に対するアクセス権付与の可否を決定する。管理装置は、複数の検証要求を受信した場合、当該複数の検証要求それぞれに対応する複数の通信装置へのアクセス権の付与をまとめて指示可能な検証用データを通信端末に送信する。【選択図】図６

Description

本発明は、リソースアクセスの権限付与技術に関するものである。

近年、スマートデバイスやデジタルカメラ等の通信装置がネットワーク接続機能を搭載するようになり、ウェブ上のサービスと連携を行うようになってきている。通信装置をウェブサービス上のリソースにアクセスさせる場合、ユーザは通信装置に対してリソースへのアクセス権を与える必要がある。

リソースへのアクセス権を表す認可情報を付与する技術としてＯＡｕｔｈ２．０が知られている。特許文献１には、ＯＡｕｔｈ２．０を利用した権限付与システムが開示されている。より詳細には、認可情報を管理する管理装置が通信端末のユーザインターフェースを介したユーザ操作による同意指示を得ることで、当該通信装置に対して認可情報を付与する手法が開示されている。一方、低機能なユーザインターフェースしか持たない通信装置においては、ユーザ操作による同意指示を行えないという課題がある。これに対し、通信装置とは別の代理機器を利用してユーザの同意指示を得る方法が提案されている。

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

しかしながら、上述の従来技術においては、複数の通信装置に対してまとめて認可情報を付与することに関して考慮していない。そのため、複数の通信装置に対して認可情報を付与する場合、ユーザは通信装置毎に同意指示を行う必要があるため非効率であった。

本発明は、このような問題に鑑みてなされたものであり、アクセス権の付与を効率的に行うことを可能とする技術を提供することを目的としている。

上述の問題点を解決するため、本発明に係る管理装置は以下の構成を備える。すなわち、リソースに対する通信装置のアクセス権を管理する管理装置は、
アクセス権の認可要求を通信装置から受信する第１の受信手段と、
前記認可要求に含まれる情報に基づいて生成したデバイス識別子とユーザ識別子とを含む認可応答を前記通信装置に送信する第１の送信手段と、
前記通信装置から前記ユーザ識別子を通知され操作移譲がされた通信端末から、前記ユーザ識別子を含む検証要求を受信する第２の受信手段と、
前記検証要求に対する応答として、検証用データを前記通信端末に送信する第２の送信手段と、
前記通信端末による前記検証用データに基づくアクセスを受け付ける受付手段と、
前記受付手段におけるアクセスの受け付けに基づいて、前記通信装置に対するアクセス権付与の可否を決定する決定手段と、
を有し、
前記第２の受信手段が前記通信端末から複数の検証要求を受信した場合、前記第２の送信手段は、該複数の検証要求それぞれに対応する複数の通信装置へのアクセス権の付与をまとめて指示可能な検証用データを前記通信端末に送信する。

本発明によれば、アクセス権の付与を効率的に行うことを可能とする技術を提供することができる。

通信システムの全体構成を示す図である。 認可サーバのハードウェア構成を示す図である。 通信装置のハードウェア構成を示す図である。 通信端末のハードウェア構成を示す図である。 各装置のソフトウェア構成を示す図である。 アクセストークン発行に係る処理例を示すシーケンス図である。 識別子ペア発行処理のフローチャートである。 アクセストークン発行処理のフローチャートである。 検証用データ発行処理のフローチャートである。 同意受理処理のフローチャートである。 同意要求画面の例を示す図である。 認可リクエストテーブルの例を示す図である。 グループ化テーブルの例を示す図である。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

（第１実施形態）
本実施形態に係る管理装置として、通信装置に対してリソースへのアクセス権を認可する認可サーバを例に挙げて以下に説明する。

＜システム構成＞
図１は、通信システム１００の全体構成を示す図である。通信システムは、ネットワークであるＷＡＮ（Wide Area Network）１０５やＬＡＮ（Local Area Network）１０４を介して相互に通信可能に構成された、認可サーバ１０１、通信装置１０２、通信端末１０３を含む。

認可サーバ１０１は、アクセストークンの発行を行うサーバである。ここで、アクセストークンとはリソースへのアクセス権を示す認可情報であり、例えばランダムな英数字から構成される文字列であるが、これに限るものではない。通信装置１０２は、アクセストークンを取得する装置である。図１においては、２台の通信装置１０２を示しているが３台以上存在してもよい。通信端末１０３は、アクセストークン発行の権利を持つユーザが操作する端末である。以降、アクセストークン発行の権利を持つユーザのことを検証者と呼称する。

ＬＡＮ１０４は、ＩＥＥＥ８０２．１１規格シリーズに準拠する無線ＬＡＮであるが、例えば、ワイヤレスＵＳＢ、ＭＢＯＡ、Ｂｌｕｅｔｏｏｔｈ、ＵＷＢ、ＺｉｇＢｅｅ等の他の無線媒体が用いられてもよい。また、無線媒体ではなく、有線ＬＡＮ等の有線通信媒体が用いられてもよい。ＷＡＮ１０５は、ＬＡＮ等の他のネットワークであってもよい。

上述のように、認可サーバ１０１と通信装置１０２はＬＡＮ１０４及び、ＷＡＮ１０５を介して接続されている。また、同様に認可サーバ１０１と通信端末１０３はＬＡＮ１０４及びＷＡＮ１０５を介して接続されている。尚、図示される接続に限定されるものではなく、通信装置１０２および通信端末１０３は、ＷＡＮ１０５を介して認可サーバ１０１と直接接続されていてもよい。

また、通信装置１０２と通信端末１０３は、近距離無線通信１０６を用いて接続されている。近距離無線通信１０６は、例えば、Ｂｌｕｅｔｏｏｔｈ（商標登録）ＬｏｗＥｎｅｒｇｙ（ＢＬＥ）であるが、他の近距離無線通信であってもよい。また、光無線通信や２次元コードを用いたデータ伝達であってもよく、これに限るものではない。以下の説明では、近距離無線通信１０６はＢＬＥであるとして説明を行う。

尚、通信装置１０２は、例えばデジタルカメラであるが、携帯電話や、スマートフォン、ノートＰＣ、タブレット端末、その他のネットワークに接続する機能を有する機器であってもよい。通信端末１０３は、例えばスマートフォンであるが、デジタルカメラや、携帯電話、ノートＰＣ、タブレット端末、その他のネットワークに接続する機能を有する機器であってもよい。

＜各装置のハードウェア構成＞
図２は、認可サーバ１０１のハードウェア構成を示す図である。認可サーバ１０１は、例えば、制御部２０１、記憶部２０２、電源部２０３、有線ＬＡＮ通信部２０４、パケット送受信部２０５を有する。

制御部２０１は、記憶部２０２に記憶される制御プログラムを実行することにより、認可サーバ１０１を制御する。記憶部２０２は、制御部２０１が実行する制御プログラムや、後述する各種情報を記憶する。認可サーバ１０１における後述する各種動作は、記憶部２０２に記憶された制御プログラムを制御部２０１が実行することにより行われうる。例えば、制御部２０１及び記憶部２０２は、ハードウェア構成として、一つ又は複数のＣＰＵやＭＰＵ等のプロセッサと、一つ又は複数のＲＯＭやＲＡＭ等のメモリとを含んで構成される。ここで、ＣＰＵはCentral Processing Unitの頭字語であり、ＭＰＵはMicro Processing Unitの頭字語である。また、ＲＯＭはRead Only Memoryの、ＲＡＭはRandom Access Memoryの頭字語である。また、以下の各機能部の少なくとも一部は、例えばプロセッサによって記憶装置によって記憶されたプログラムが読み出されて実行されることにより実現されうるが、その一部は別のハードウェアによって実現されうる。

電源部２０３は、認可サーバ１０１に電源を供給する。有線ＬＡＮ通信部２０４は、有線ＬＡＮに接続され、パケット送受信部２０５の通信制御処理に基づき、当該有線ＬＡＮ内の他の機器と通信を行う。パケット送受信部２０５は、有線ＬＡＮの各種通信に係るパケットの送受信を行う。

図３は、通信装置１０２のハードウェア構成を示す図である。通信装置１０２は、例えば、無線ＬＡＮ通信部３０１、ＢＬＥ通信部３０３、パケット送受信部３０５、制御部３０６、記憶部３０７、電源部３０８、表示部３０９、操作部３１０を有する。

無線ＬＡＮ通信部３０１は、無線ＬＡＮの、ＲＦ制御、通信処理、ＩＥＥＥ８０２．１１シリーズに準拠した通信の各種制御を行うドライバや関連するプロトコルの処理を行う。無線ＬＡＮ通信部３０１は、アンテナ３０２を介して、無線ＬＡＮの通信を行う。ＢＬＥ通信部３０３は、ＢＬＥの、ＲＦ制御、通信処理、規格に準拠した通信の各種制御を行うドライバや関連するプロトコルの処理を行う。ＢＬＥ通信部３０３は、アンテナ３０４を介して通信を行う。パケット送受信部３０５は、各種通信にかかわるパケットを送受信する。

制御部３０６は、記憶部３０７に記憶される制御プログラムを実行することにより、通信装置１０２を制御する。記憶部３０７は、制御部３０６が実行する制御プログラムや、通信に必要なパラメータ等の各種情報を記憶する。通信装置１０２における後述する各種動作は、記憶部３０７に記憶された制御プログラムを制御部３０６が実行することにより行われうる。電源部３０８は、通信装置１０２に電源を供給する。表示部３０９は、各種表示を行う機能部であり、ＬＣＤやＬＥＤのように視覚で認知可能な情報の出力、またはスピーカ等の音出力を行う。操作部３１０は、通信装置１０２に対する操作を受け付ける。

図４は、通信端末１０３のハードウェア構成を示す図である。通信端末１０３は、例えば、ＢＬＥ通信部４０１、パケット送受信部４０３、制御部４０４、記憶部４０５、電源部４０６、表示部４０７、無線ＬＡＮ通信部４０８、表示部４０９、操作部４１０、通話部４１１、マイク４１２を有する。

ＢＬＥ通信部４０１は、ＢＬＥの、ＲＦ制御、通信処理、規格に準拠した通信の各種制御を行うドライバや関連するプロトコルの処理を行う。ＢＬＥ通信部４０１は、アンテナ４０２を介して通信を行う。パケット送受信部４０３は、各種通信にかかわるパケットを送受信する。

制御部４０４は、記憶部４０５に記憶される制御プログラムを実行することにより、通信端末１０３を制御する。記憶部４０５は、制御部４０４が実行する制御プログラムや、通信に必要なパラメータ等の各種情報を記憶する。通信端末１０３における後述する各種動作は、記憶部４０５に記憶された制御プログラムを制御部４０４が実行することにより行われうる。例えば、制御部４０４及び記憶部４０５は、ハードウェア構成として、一つ又は複数のＣＰＵやＭＰＵ等のプロセッサと、一つ又は複数のＲＯＭやＲＡＭ等のメモリとを含んで構成される。電源部４０６は、通信端末１０３に電源を供給する。無線ＬＡＮ通信部４０７は、無線ＬＡＮの、ＲＦ制御、通信処理、ＩＥＥＥ８０２．１１シリーズに準拠した通信の各種制御を行うドライバや関連するプロトコルの処理を行う。無線ＬＡＮ通信部４０７は、アンテナ４０８を介して、無線ＬＡＮの通信を行う。表示部４０９は、各種表示を行う機能部であり、ＬＣＤやＬＥＤのように視覚で認知可能な情報の出力、またはスピーカ等の音出力を行う。操作部４１０は、通信端末１０３に対する操作を受け付ける。通話部４１１は、マイク４１２を介して、ユーザへ通話機能を提供する。

なお、上述の各装置の機能ブロックは単なる例である。また、複数の機能ブロックを１つの機能ブロックとして構成するようにしてもよいし、何れかの機能ブロックを更に複数の機能を行うブロックに分けるよう構成してもよい。

＜各装置のソフトウェア構成＞
図５は、各装置（認可サーバ１０１、通信装置１０２、通信端末１０３）のソフトウェア構成を示す図である。ここでは、後述する、認可リクエストを要求した通信装置１０２に対する認可サーバ１０１によるアクセストークンの発行に関する処理に関連するソフトウェア構成のみを示している。図５（Ａ）は認可サーバ１０１、図５（Ｂ）は通信装置１０２、図５（Ｃ）は通信端末１０３のソフトウェア構成をそれぞれ表す。

認可サーバ１０１は、識別子ペア発行モジュール５０１、認可リクエスト管理モジュール５０２、検証用データ発行モジュール５０３、グループ識別子管理モジュール５０４を有する。更に、同意受理モジュール５０５、認証モジュール５０６、アクセストークン発行モジュール５０７を有する。通信装置１０２は、検証用ＵＲＩ送信モジュール５０８、アクセストークン取得モジュール５０９、認可リクエストモジュール５１０を有する。通信端末１０３は、Ｗｅｂブラウザ５１１、検証用ＵＲＩ受信モジュール５１２を有する。ここで、ＵＲＩは、Uniform Resource Identifierの頭字語であり、ネットワーク上の位置を示す情報である。各モジュールが実行する処理の詳細については図７〜図１０を参照して後述する。

＜システムの動作＞
通信システムの動作を、図７から図１０のフローチャートを参照して説明する。特に、認可サーバ１０１が実行する各種処理を中心に説明する。

図７は、識別子ペア発行処理７００のフローチャートである。識別子ペア発行処理７００は、通信装置１０２からの認可リクエストに応答して、ユーザ識別子とデバイス識別子の対（識別子ペア）を通信装置１０２に発行する処理である。識別子ペア発行処理７００は、認可サーバ１０１が、認可リクエストの受信を契機に、識別子ペア発行モジュール５０１を起動することで開始される。

認可リクエストは、通信装置１０２が認可サーバ１０１に対し、認可取得の開始を要求するために送信するメッセージであり、認可要求情報が含まれる。認可要求情報は、例えば、認可要求者を識別するための識別子や、要求するアクセス権の範囲を示す権限範囲情報であるがこれに限らない。例えば、通信装置１０２の名称やアイコン画像など、その他の情報を含んでもよい。また、認可要求者を識別するための識別子は、事前に認可サーバ１０１において固有の識別子を生成し、通信装置１０２に対し登録したものである。識別子ペア発行処理７００が開始されると、識別子ペア発行モジュール５０１は、Ｓ７０１を実行する。

ステップＳ７０１では、識別子ペア発行モジュール５０１は、認可リクエストに含まれる認可要求情報を認可リクエスト管理モジュール５０２に記憶する。ステップＳ７０２では、識別子ペア発行モジュール５０１は、ユーザ識別子とデバイス識別子を生成する。ユーザ識別子とデバイス識別子は、認可サーバ上で一意な値であり、任意の英数字の羅列で表現される文字列である。ユーザ識別子は、同意指示を行うことができる権限を表す情報であり、情報端末１０３から認可サーバに送信される識別子である。また、デバイス識別子は、アクセストークンを取得することができる権限を表す情報であり、通信装置１０２から認可サーバ１０１に対して送信される識別子である。尚、ユーザ識別子とデバイス識別子には、それぞれ有効期限や利用可能な回数を設定してもよい。ステップＳ７０３では、識別子ペア発行モジュール５０１は、認可リクエスト管理モジュール５０２を用いて、Ｓ７０２で生成したユーザ識別子とデバイス識別子を、受信した認可要求情報に関連付けて図１２に示す認可リクエストテーブルに記憶する。ステップＳ７０４では、識別子ペア発行モジュール５０１は、ユーザ識別子とデバイス識別子の対を通信装置１０２に送信（発行）する。

図１２は、認可リクエストテーブルの例を示す図である。認可リクエストテーブルは、例えば、認可要求者、認可要求範囲、デバイス識別子、ユーザ識別子、アクセストークン発行許可の項目から構成される。認可要求者と認可要求範囲は、認可要求情報に含まれる情報である。認可要求者の項目は、認可要求者を識別するための識別子を記憶する。また、認可要求範囲の項目は、通信装置１０２が認可サーバに対して要求するアクセス権の範囲を記憶する。アクセストークン発行許可の項目は、デバイス識別子によるアクセストークン発行が許可されているかどうかを記憶する。

図８は、アクセストークン発行処理８００のフローチャートである。アクセストークン発行処理８００は、認可サーバ１０１が、通信装置１０２からのアクセストークン取得リクエストに応答して、アクセストークンを通信装置１０２に発行する処理である。アクセストークン発行処理８００は、認可サーバ１０１が、アクセストークン取得リクエストの受信を契機に、アクセストークン発行モジュール５０７を起動することで実行される。

アクセストークン取得リクエストは、通信装置１０２がアクセストークンの取得を要求するメッセージであり、通信装置１０２から認可サーバ１０１に対し送信される。アクセストークン取得リクエストは、識別子ペア発行処理７００で発行された、デバイス識別子を含むが、これに限るものではない。例えば、アクセストークン取得リクエストの送信者を識別するための情報等が含まれていてもよい。アクセストークン発行処理８００が開始されると、アクセストークン発行モジュール５０７は、Ｓ８０１を実行する。

ステップＳ８０１では、アクセストークン発行モジュール５０７は、アクセストークン取得リクエストで受信したデバイス識別子によるアクセストークンの発行が許可されているか否かを認可リクエスト管理モジュール５０２によって判断する。アクセストークンの発行が許可されていると判断した場合はＳ８０３に遷移し、アクセストークンの発行が許可されていないと判断した場合はＳ８０２に遷移する。ステップＳ８０２では、アクセストークン発行モジュール５０７は、エラー情報を生成して、アクセストークン発行処理を終了する。尚、エラー情報は、例えば、アクセストークンの発行が許可されていない旨を通知する情報等であるが、これに限るものではない。ステップＳ８０３では、アクセストークン発行モジュール５０７は、アクセストークンを生成して、アクセストークン発行処理を終了する。

図９は、検証用データ発行処理９００のフローチャートである。検証用データ発行処理９００は、認可サーバ１０１が、通信端末１０３からの検証開始リクエストに応答して、通信端末１０３に検証用データを発行する処理である。検証用データ発行処理９００は、検証開始リクエストの受信を契機に、認可サーバ１０１が、検証用データ発行モジュール５０３を起動することで実行される。

検証開始リクエストは、通信端末１０３上で、通信装置１０２によるアクセストークンの取得を許可または拒否するための操作の開始を要求するためのメッセージある。検証開始リクエストは、通信端末１０３から認可サーバ１０１に対して送信されるメッセージである。尚、検証開始リクエストには、グループ識別子とユーザ識別子が含まれるがこれに限らない。例えば、ユーザ識別子のみが含まれても良い。また、検証開始リクエストにはユーザ識別子が２つ以上含まれてもよい。これにより、１つの検証開始リクエストにより、複数のユーザ識別子をグループ識別子に紐づけて記憶することが可能になり、受信するメッセージの数を減らすことができる。

ここでは、グループ識別子として、検証者のユーザＩＤを識別するための情報を利用することを想定しているが、これに限らない。例えば、認可サーバ１０１や通信装置１０２、通信端末１０３が発行した任意の値をグループ識別子として利用してもよい。また、検証者のユーザＩＤを識別するための情報は、検証者のログイン状態を表す情報として記憶されているＣｏｏｋｉｅを想定するが、これに限らない。例えば、ユーザ認証のためのＩＤやパスワードであってもよいし、その他のクレデンシャル情報を用いてもよい。Ｃｏｏｋｉｅはログイン完了後のセッション番号である。

認可サーバ１０１は、検証開始リクエストの受信を契機に、検証用データ発行モジュール５０３を起動し、検証用データ発行処理９００を実行する。検証用データ発行処理９００が開始されると、検証用データ発行モジュール５０３は、認証モジュール５０６を用いてＳ９０１を実行する。

ステップＳ９０１では、認証モジュール５０６は、検証開始リクエスト送信元の検証者に対する認証が完了しているかどうか判断する。ここで、検証者に対する認証が完了しているかどうかの判断は、検証開始リクエストによって受信したＣｏｏｋｉｅを検証し、ユーザのログインが完了済みかどうか確認するにより行う。認証が完了していないと判断した場合はＳ９０２へ遷移し、認証が完了していると判断した場合はＳ９０３へ遷移する。

ステップＳ９０２では、認証モジュール５０６は、検証者の認証を行う。検証者の認証は、Ｗｅｂブラウザ５１１上でユーザが入力した検証者のＩＤとパスワードを認証モジュール５０６に対して送信し、正当性を検証することにより行うことを想定しているが、これに限らない。例えば、Ｗｅｂブラウザ５１１に事前に記憶されているクライアント証明書を、認証モジュール５０６に対して送信し、正当性を検証することにより認証を行ってもよい。認証モジュール５０６は、検証者の認証が完了すると、Ｗｅｂブラウザ５１１に対しＣｏｏｋｉｅを送信する。

ステップＳ９０３では、検証用データ発行モジュール５０３は、グループ識別子管理モジュール５０４を利用し、検証開始リクエストで受信したユーザ識別子をグループ識別子に関連付けてグループ化テーブルに記憶する。

図１３は、グループ化テーブルの例を示す図である。ここで、グループ化テーブルは、例えば、グループ識別子、ユーザ識別子の項目から構成される。尚、グループ記憶及び管理を行うグループ識別子管理モジュール５０４において、１つのグループ識別子に関連付けられるユーザ識別子の個数に上限を設けてもよい。ユーザ識別子の個数が上限に達した場合、グループ識別子管理モジュール５０４はＷｅｂブラウザ５１１に対し、上限に達した旨のメッセージを、後述する検証用データに含み送信する。例えば、認可サーバ１０１のセキュリティポリシーにより、検証者が一度の認可操作で認可可能な通信装置数に上限が存在する場合、上限に達した旨のメッセージを送信することで、検証者の不要な認可操作を抑制することができる。

ステップＳ９０４では、検証用データ発行モジュール５０３は、グループ識別子管理モジュール５０４を用いて、受信したグループ識別子と同一のグループ識別子に関連付けられたユーザ識別子を探索する。ここで、ユーザ識別子の探索は、グループ識別子管理モジュール５０４の記憶するグループ化テーブルから、受信したグループ識別子と同一のグループ識別子に関連付けられたユーザ識別子を検索することで行う。

ステップＳ９０５では、検証用データ発行モジュール５０３は、認可リクエスト管理モジュール５０２を用いて、Ｓ９０４で探索されたユーザ識別子に関連付けられた認可要求情報を探索する。ここで、認可要求情報の探索は、認可リクエスト管理モジュールの記憶する認可リクエストテーブルから、探索されたユーザ識別子に関連付けられた情報を検索することによって行う。

ステップＳ９０６では、検証用データ発行モジュール５０３は、Ｓ９０４で探索されたユーザ識別子と、Ｓ９０５で探索された認可要求情報を基に検証用データを生成する。ここで、検証用データは、グループ識別子に紐づけられた全てのユーザ識別子の対となるデバイス識別子によるアクセストークン取得を許可することのできる許可ＵＲＩや、認可要求情報を含むがこれに限らない。例えば、グループ識別子に紐づけられた全てのユーザ識別子の対となるデバイス識別子によるアクセストークン取得を拒否するためのＵＲＩを含んでもよい。また、検証者が特定の通信装置を選択するためのデータを含んでもよい。これにより、検証者は１回の認可操作で特定の通信装置を許可する対象から除外したり、特定の通信装置を許可する対象にしたりすることができる。さらに、検証用データは、通信端末１０３における検証用ＵＲＩ受信モジュール５１２を呼び出すＵＲＩを含んでもよい。例えば、検証用ＵＲＩ受信モジュール５１２がＱＲコード（登録商標）リーダであった場合、検証者が通信端末１０３においてＷｅｂブラウザからＱＲコードリーダへ手動で操作を切り替える必要がある。これに対し、検証用データに検証用ＵＲＩ受信モジュール５１２を呼び出すＵＲＩを付加することによって、検証者はＷｅｂブラウザ上での簡単な操作でＱＲコードリーダへ切り替えることが可能になる。

ステップＳ９０７では、検証用データ発行モジュール５０３は、生成した検証用データを通信端末１０３に送信（発行）する。

図１０は、同意受理処理１０００のフローチャートである。同意受理処理１０００は、認可サーバ１０１が、通信端末１０３による許可ＵＲＩへのアクセスに応答して、認可の同意を受理する処理である。同意受理処理１０００は、認可サーバ１０１が、許可ＵＲＩへのアクセスを契機に、同意受理モジュール５０５を起動することによって実行される。

認可サーバは、許可ＵＲＩへのアクセスにより通信端末１０３からグループ識別子と選択情報を受信する。ここで、選択情報は検証者が認可に対する同意を行った対象の通信装置を識別するための情報である。選択情報は、ユーザ識別子であるがこれに限らない。例えば、許可と拒否を表現する識別子でも良い。選択情報は、認可を拒否する通信装置に発行したユーザ識別子であるがこれに限らない。例えば、認可を許可する通信装置に発行したユーザ識別子であってもよいし、認可の可否を表す情報を通信装置の数だけ含んでもよい。

ステップＳ１００１では、同意受理モジュール５０５は、認証モジュール５０６を用いて、許可ＵＲＩへのアクセスに含まれるＣｏｏｋｉｅを基にユーザＩＤを判別する。ステップＳ１００２では、同意受理モジュール５０５は、グループ識別子管理モジュール５０４を用い、グループ化テーブルの記憶する検証者のユーザＩＤに対して関連付けられたユーザ識別子を全て探索する。ステップＳ１００３では、同意受理モジュール５０５は、ステップ１００２で取得されたユーザ識別子全てに対し、Ｓ１００４とＳ１００５を繰り返す。

ステップＳ１００４では、同意受理モジュール５０５は、許可ＵＲＩへのアクセスで受信した選択情報を基に、ユーザ識別子の対になるデバイス識別子によるアクセストークン取得が許可されているか判断する。ここでは、認可サーバ１０１が選択情報として拒否された通信装置を識別する情報を受信するものとして説明を行う。同意受理モジュール５０５は、処理対象のユーザ識別子と同一のユーザ識別子を選択情報として受信したか確認する。同一のユーザ識別子を選択情報として受信していた場合、同意受理モジュール５０５は、ユーザ識別子の対になるデバイス識別子によるアクセストークンの取得が許可されていないと判断する。一方、同一のユーザ識別子を選択情報として受信していなかった場合、同意受理モジュール５０５は、ユーザ識別子の対になるデバイス識別子によるアクセストークンの取得が許可されていると判断する。Ｓ１００４で、ユーザ識別子の対になるデバイス識別子によるアクセストークンの取得が許可されていると判断された場合はＳ１００５へ遷移し、許可されていないと判断された場合はＳ１００６へ遷移する。

ステップＳ１００５では、同意受理モジュール５０５は、認可リクエスト管理モジュール５０２を用いて、認可リクエストテーブルにおけるユーザ識別子と対になるデバイス識別子によるアクセストークンの取得を許可状態にする。

ステップＳ１００６では、同意受理モジュール５０５は、取得されたユーザ識別子全てに対する処理が完了した場合、同意受理処理を終了する。完了していない場合、Ｓ１００３に戻り、他のユーザ識別子に対する処理を行う。

尚、上述の説明では、Ｓ１００４でアクセストークンの取得が許可されていないと判断した場合はＳ１００６へ進むようにしたが、当該ユーザ識別子とデバイス識別子を認可リクエスト管理モジュール５０２から削除してもよい。これにより、認可リクエスト管理モジュールの利用するメモリ容量を削減できる。

＜処理例＞
図６は、アクセストークンの発行に係る処理例を示すシーケンス図である。本処理例では、２台の通信装置１０２（通信装置１０２Ａ、通信装置１０２Ｂ）が、認可サーバ１０１に対し認可を要求する。次に、検証者が通信端末１０３を用いて認可サーバ１０１の発行した許可ＵＲＩにアクセスする。その後、認可サーバ１０１は、許可ＵＲＩへのアクセスに基づき、通信装置１０２Ａと１０２Ｂへのアクセストークン発行を許可する。

通信装置１０２Ａは、認可サーバ１０１に認可要求である認可リクエスト６０１を送信する。尚、認可リクエスト６０１は、通信装置１０２Ａに対するユーザの入力操作を契機に送信されるがこれに限らない。例えば、通信端末１０３から、ＢＬＥによる所定の信号を受信した場合や、他の通信装置から信号を受信した場合にも開始しうる。

認可サーバ１０１は、認可リクエスト６０１を受信すると、識別子ペア発行モジュール５０１を起動し、識別子ペア発行処理７００を開始する。

認可サーバ１０１は、識別子ペア発行処理７００を終了すると、通信装置１０２Ａに認可応答である認可レスポンス６０２を送信する。ここで、認可レスポンスは、識別子発行処理によって発行されたデバイス識別子とユーザ識別子を含むがこれに限らない。例えば、ユーザ識別子の有効期限やデバイス識別子の有効期限など、その他の情報が含まれていてもよい。尚、ここでは、通信装置１０２Ａは認可サーバ１０１に対し、認可要求情報として「Ｃａｍｅｒａ００１」と「Ｕｐｌｏａｄ Ｂｒｏｗｓｅ」を送信したものとする。また、認可サーバ１０１は、通信装置１０２Ａに対し、デバイス識別子とユーザ識別子として、「ＤｅｖｉｃｅＣｏｄｅ００１」と「ＵｓｅｒＣｏｄｅ００１」を送信したものとする。

また、通信装置１０２Ｂは、認可サーバ１０１に認可リクエスト６０３を送信する。認可サーバ１０１は、認可リクエスト６０３を受信すると、識別子ペア発行処理７００を開始する。

認可サーバ１０１は、識別子ペア発行処理７００が終了すると、通信装置１０２Ｂへデバイス識別子とユーザ識別子を含む、認可レスポンス６０４を送信する。尚、ここでは、通信装置１０２Ｂは認可サーバ１０１に対し、認可要求情報として「Ｃａｍｅｒａ００２」と「Ｕｐｌｏａｄ」を送信したものとする。また、認可サーバ１０１は、通信装置１０２Ｂに対し、デバイス識別子とユーザ識別子として、「ＤｅｖｉｃｅＣｏｄｅ００２」と「ＵｓｅｒＣｏｄｅ００２」を送信したものとする。

図１２は、認可リクエスト管理モジュールの記憶する認可リクエストテーブルの例を示す図である。具体的には、上述の通信装置１０２Ａおよび通信装置１０２Ｂのそれぞれに対して識別子ペアを発行した直後の状態を示している。

次に、通信装置１０２Ａは、認可サーバ１０１にアクセストークン取得リクエスト６０５を送信する。アクセストークン取得リクエスト６０５は、認可レスポンス６０２によって通信装置１０２Ａが受信したデバイス識別子を含む。尚、アクセストークン取得リクエスト６０５は、認可レスポンス６０２を通信装置１０２Ａが受信したことを契機に、通信装置１０２Ａがアクセストークン取得モジュール５０９を起動することによって送信される。また、ここでは、通信装置１０２Ａは、アクセストークンの取得が完了するまで、一定期間毎にアクセストークン取得リクエスト６０５を送信するものとするが、これに限らない。例えば、通信装置１０２Ａに対するユーザの入力操作や、通信端末１０３からＢＬＥによる所定の信号を受信した場合にも送信され得る。認可サーバ１０１は、アクセストークン取得リクエストを受信すると、アクセストークン発行モジュール５０７を起動し、アクセストークン発行処理８００を実行する。

Ｓ８０１において、認可リクエスト管理モジュール５０２は記憶した認可リクエストテーブルから、「ＤｅｖｉｃｅＣｏｄｅ００１」に対応するアクセストークン発行許可の項目を参照する。参照したアクセストークン発行許可の値は「Ｎｏ」であるので、認可リクエスト管理モジュールはアクセストークン発行が許可されていないと判断し、Ｓ８０２に遷移する。Ｓ８０２で、アクセストークン発行モジュール５０７はエラー情報を発行する。認可サーバ１０１は通信装置１０２Ａに対し、アクセストークン取得レスポンス６０６を送信する。アクセストークン取得レスポンス６０６はエラー情報を含む。

また、通信装置１０２Ｂは、認可サーバ１０１にアクセストークン取得リクエスト６０７を送信する。アクセストークン取得リクエスト６０７に係る処理は、上述のアクセストークン取得リクエスト６０５に係る処理と同様であるため、説明を省略する。

通信装置１０２Ａは、通信端末１０３の検証用ＵＲＩ受信モジュール５１２に操作移譲メッセージ６０９を送信する。ここで、操作移譲メッセージ６０９は、認可レスポンス６０２に含まれるユーザ識別子と検証用ＵＲＩを含み、近距離無線通信１０６を用いて送信される。尚、操作移譲メッセージ６０９は、認可レスポンス６０２の受信を契機に検証用ＵＲＩ送信モジュール５０８を起動することで送信されるが、これに限らない。例えば、通信装置１０２Ａに対するユーザの入力操作や、通信端末１０３からＢＬＥによる所定の信号を受信した場合にも開始しうる。

通信端末１０３は、検証用ＵＲＩ受信モジュール５１２からＷｅｂブラウザ５１１を経由して、検証要求である検証開始リクエスト６１０を認可サーバ１０１に送信する。検証開始リクエスト６１０は、認可レスポンス６０２で認可サーバ１０１が通信装置１０２Ａに対して送信したユーザ識別子を含む。また、検証開始リクエスト６１０は、検証用ＵＲＩ受信モジュール５１２が、例えば、操作移譲メッセージ６０９の受信を契機に、検証用ＵＲＩに対して送信するが、これに限らない。例えば、あらかじめ検証用ＵＲＩ受信モジュール５１２が受信する操作移譲メッセージの数を決めておき、受信したユーザ識別子の数が規定値に達した時に一度に送信してもよいし、通信端末１０３に対する、ユーザの操作を契機に送信するなどしてもよい。

認可サーバ１０１は、検証開始リクエスト６１０を受信したことを契機に、検証用データ発行モジュール５０３を起動し、検証用データ発行処理９００を実行する。検証用データ発行モジュール５０３は、Ｓ９０１において、検証者が認証済みでないと判断し、Ｓ９０２へ遷移する。Ｓ９０２において、認証モジュール５０６は認証検証者の認証を行う。また、Ｓ９０２において、検証者の認証が完了した時点で、ユーザＩＤが明らかになる。ここで、検証者のユーザＩＤは「ＵｓｅｒＡ」であるものとする。データ発行モジュールは、Ｓ９０２からＳ９０７を実行し、検証用データを発行する。その後、認可サーバ１０１は、通信端末１０３のＷｅｂブラウザ５１１に検証用データを送信する。

Ｗｅｂブラウザ５１１は、検証用データを受信すると、検証用データを基に同意要求画面１１０１を表示する。図１１は、同意要求画面の例を示す図である。図１１（Ａ）に示す同意要求画面１１０１は、通信装置１０２Ａに関する同意を指定する画面である。同意要求画面１１０１は、例えば、許可する認可要求者を選択するためのチェックボックス、認可要求者の情報、認可に同意するためのボタン、認可を拒否するためのボタンなどを含む。検証者はチェックボックスにおけるチェックを外すことによって、特定の通信機器を同意の対象から外すことができる。ここでは、同意要求画面においてユーザの許可ＵＲＩに対する操作が行われなかった（すなわち、認可の許可または拒否のボタン操作が行われなかった）ものとして説明を続ける。

通信装置１０２Ｂは、検証用ＵＲＩ受信モジュール５１２に対し操作移譲メッセージ６１２を送信する。操作移譲メッセージ６１２は、認可レスポンス６０４で認可サーバ１０１が通信装置１０２Ｂに対して送信したユーザ識別子と検証用ＵＲＩを含む。検証用ＵＲＩ受信モジュール５１２は、操作移譲メッセージ６１２の受信を契機に、Ｗｅｂブラウザ５１１を経由し、認可サーバ１０１に対して検証開始リクエスト６１３を送信する。検証開始リクエスト６１３は、認可レスポンス６０４で認可サーバが通信装置１０２Ａに対して送信したユーザ識別子とＳ９０２で発行されたＣｏｏｋｉｅを含む。認可サーバ１０１は、検証開始リクエスト６１３を受信したことを契機に、検証用データ発行モジュール５０３を起動し、検証用データ発行処理９００を実行する。検証用データ発行モジュール５０３は、Ｓ９０１において、検証開始リクエスト６１３で受信したＣｏｏｋｉｅを基に検証者の認証が済んでいると判断し、Ｓ９０３へ遷移する。検証用データ発行モジュール５０３は、Ｓ９０３からＳ９０６を実行し、検証用データを発行する。

図１３は、グループ識別子管理モジュール５０４の記憶するグループ化テーブルの例を示す図である。具体的には、上述の通信装置１０２Ａおよび通信装置１０２Ｂのそれぞれに対する検証用データを通信端末１０３（Ｗｅｂブラウザ５１１）に発行した直後の状態を示している。認可サーバ１０１は、Ｗｅｂブラウザ５１１に対し、検証用データ６１４を送信する。

Ｗｅｂブラウザ５１１は、検証用データ６１４の受信を契機に、検証用データ６１４を基に同意要求画面１１０２を表示する。図１１（Ｂ）に示す同意要求画面１１０２は、通信装置１０２Ａ及び通信装置１０２Ｂに関する同意をまとめて指定可能な画面である。同意要求画面１１０２は、複数の認可要求に関する情報のリスト表示や、各認可要求に関する情報に対応するチェックボックス、認可に同意するためのボタン、認可を拒否するためのボタンを含む。認可要求に関する情報は、認可を要求している通信装置の識別子と認可要求情報である。これにより、ユーザは許可のボタンを押すことで、認可サーバ１０１が通信装置１０２Ａと通信装置１０２Ｂに対してまとめて認可を与えることを許可することができる。また、ユーザは、所望の通信装置を選択する（チェックボックスをチェックする）ことで、選択した通信装置をアクセス権付与の認可対象から外したり加えたりすることができる。ここでは、通信装置１０２Ａと通信装置１０２Ｂの両方に対してアクセス権を許可するものとして説明を行う。

Ｗｅｂブラウザ５１１は、認可サーバ１０１に対して許可ＵＲＩへのアクセス６１５を行う。許可ＵＲＩへのアクセス６１５は、例えば、検証者がＷｅｂブラウザ５１１上の許可に同意するためのボタンを押下することによって行われる。許可ＵＲＩへのアクセス６１５は、例えば、グループ識別子と、認可に対する同意の対象を識別するための選択情報が含まれる。選択情報は、認可を拒否したい通信装置に対して発行されたユーザ識別子である。

認可サーバ１０１は、許可ＵＲＩへのアクセス６１５の受付を契機に、同意受理モジュール５０５を起動し、同意受理処理１０００を実行する。同意受理モジュール５０５は、Ｓ１００１を実行し、Ｓ１００２へ遷移する。Ｓ１００２で、同意受理モジュール５０５は、処理の結果として「ＵｓｅｒＣｏｄｅ００１」と「ＵｓｅｒＣｏｄｅ００２」を取得する。

Ｓ１００３で、同意受理モジュールは、「ＵｓｅｒＣｏｄｅ００１」と「ＵｓｅｒＣｏｄｅ００２」に対して処理を行う。選択情報が許可ＵＲＩへのアクセス６１５に含まれていなかったとすると、ユーザ識別子「ＵｓｅｒＣｏｄｅ００１」に対しＳ１００５へ遷移する。認可リクエスト管理モジュールは、ユーザ識別子「ＵｓｅｒＣｏｄｅ００１」に対して、認可リクエストテーブルの「ＵｓｅｒＣｏｄｅ００１」に対応するアクセストークン発行許可を「Ｙｅｓ」に変える。「ＵｓｅｒＣｏｄｅ００２」に対しても、「ＵｓｅｒＣｏｄｅ００１」と同様にＳ１００５の処理が行わる。

「ＵｓｅｒＣｏｄｅ００１」と「ＵｓｅｒＣｏｄｅ００２」に対する処理が完了すると、同意受理モジュールは、同意受理処理を終了する。認可サーバ１０１は、Ｗｅｂブラウザ５１１に対して完了通知６１６を送信する。完了通知６１６は、同意受理が完了した旨を検証者に対して通知するための情報を含む。

通信装置１０２Ａは、認可サーバ１０１に対して、アクセストークン取得要求であるアクセストークン取得リクエスト６１７を送信する。アクセストークン取得リクエスト６１７に対するアクセストークン発行処理では、Ｓ８０１において、「ＤｅｖｉｃｅＣｏｄｅ００１」によるアクセストークンの発行が許可されていると判断される。アクセストークン発行モジュール５０７は、Ｓ８０３において、通信装置１０２Ａに対しアクセストークンを発行する。認可サーバは通信装置１０２Ａに対して、アクセストークン取得レスポンス６１８を送信する。アクセストークン取得レスポンス６１８は、アクセストークン発行処理によって発行されたアクセストークンを含む。

通信装置１０２Ｂは、認可サーバ１０１に対してアクセストークン取得リクエスト６１９を送信する。アクセストークン取得リクエスト６１９に対するアクセストークン発行処理では、Ｓ８０１において、「ＤｅｖｉｃｅＣｏｄｅ００２」によるアクセストークンの発行が許可されていると判断される。アクセストークン発行モジュール５０７は、Ｓ８０３において、通信装置１０２Ｂに対しアクセストークンを発行する。認可サーバは通信装置１０２Ｂに対して、アクセストークン取得レスポンス６２０を送信する。アクセストークン取得レスポンス６２０は、アクセストークン発行処理によって発行されたアクセストークンを含む。

このようにして、操作者（検証者）は、１回の認可操作で複数の通信装置１０２に対するアクセストークンの発行可否を指定することが可能となる。なお、許可ＵＲＩに対するアクセスや、グループ識別子に対応するユーザ識別子の追加などのグループ識別子に対する操作が一定時間行われなかった場合、該当するグループ識別子及びユーザ識別子をグループ識別子管理モジュールから削除してもよい。これにより、グループ識別子の管理に要するメモリ利用を低減することが可能となる。

以上説明したとおり第１実施形態によれば、認可サーバ１０１は、複数の通信装置１０２に対する認可情報（アクセストークン）の付与をまとめて許可する許可ＵＲＩを生成し、通信端末１０３に送信する。そして、認可サーバ１０１は、通信端末１０３による許可ＵＲＩへのアクセスに基づいて複数の通信装置１０２に対する認可情報の付与を決定する。これにより、通信端末１０３の操作者（検証者）は、１回の認可操作で複数の通信装置１０２に対するアクセストークンの発行可否を指定することが可能となる。すなわち、操作者による指示回数を削減することができる。

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

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１０１ 認可サーバ； １０２ 通信装置； １０３ 通信端末

Claims (13)

1. リソースに対する通信装置のアクセス権を管理する管理装置であって、
   アクセス権の認可要求を通信装置から受信する第１の受信手段と、
   前記認可要求に含まれる情報に基づいて生成したデバイス識別子とユーザ識別子とを含む認可応答を前記通信装置に送信する第１の送信手段と、
   前記通信装置から前記ユーザ識別子を通知され操作移譲がされた通信端末から、前記ユーザ識別子を含む検証要求を受信する第２の受信手段と、
   前記検証要求に対する応答として、検証用データを前記通信端末に送信する第２の送信手段と、
   前記通信端末による前記検証用データに基づくアクセスを受け付ける受付手段と、
   前記受付手段におけるアクセスの受け付けに基づいて、前記通信装置に対するアクセス権付与の可否を決定する決定手段と、
   を有し、
   前記第２の受信手段が前記通信端末から複数の検証要求を受信した場合、前記第２の送信手段は、該複数の検証要求それぞれに対応する複数の通信装置へのアクセス権の付与をまとめて指示可能な検証用データを前記通信端末に送信する
   ことを特徴とする管理装置。
2. 前記通信装置から該通信装置のデバイス識別子を含むアクセストークン取得要求を受信する第３の受信手段と、
   前記アクセストークン取得要求に含まれるデバイス識別子に対して前記決定手段によりアクセス権が付与されている場合に、アクセストークンを前記通信装置に送信する第３の送信手段と、
   を更に有する
   ことを特徴とする請求項１に記載の管理装置。
3. 前記第２の受信手段が前記通信端末から複数の検証要求を受信しかつ該複数の検証要求それぞれに含まれるユーザ識別子が同一のユーザを示す場合に、前記第２の送信手段は、前記複数の通信装置へのアクセス権の付与をまとめて指示可能な検証用データを前記通信端末に送信する
   ことを特徴とする請求項１又は２に記載の管理装置。
4. 前記検証要求は１以上のユーザ識別子を含んでおり、
   前記複数の検証要求が同一のユーザ識別子を含む場合、該複数の検証要求それぞれに含まれるユーザ識別子が同一のユーザを示すと判断する
   ことを特徴とする請求項３に記載の管理装置。
5. 複数のユーザ識別子をグループ化するグループ識別子を記憶するグループ記憶手段を更に有し、
   前記検証要求はグループ識別子を更に含んでおり、
   前記複数の検証要求それぞれに含まれるグループ識別子が同一である場合、該複数の検証要求それぞれに含まれるユーザ識別子が同一のユーザを示すと判断する
   ことを特徴とする請求項３に記載の管理装置。
6. 前記第２の送信手段は、前記検証要求に含まれるグループ識別子に関連付けられたユーザ識別子の個数が上限に達している場合、上限に達した旨を通知する情報を含む前記検証用データを前記通信端末に送信する
   ことを特徴とする請求項５に記載の管理装置。
7. 前記認可要求は、要求するアクセス権の範囲を示す権限範囲情報、前記通信装置を識別するための識別子、前記通信装置の名称、前記通信装置を示すアイコン画像、の少なくとも１つを含む認可情報を含む
   ことを特徴とする請求項１乃至６の何れか１項に記載の管理装置。
8. 前記第１の受信手段により受信した認可要求に含まれる情報と、前記第１の送信手段により送信した認可応答に含まれる情報と、を関連付けて記憶する記憶手段を更に有する
   ことを特徴とする請求項１乃至７の何れか１項に記載の管理装置。
9. 前記検証用データは、前記検証要求に含まれるユーザ識別子と同一のグループに含まれるユーザ識別子に関連付けられた１以上の通信装置の情報を含む
   ことを特徴とする請求項１乃至８の何れか１項に記載の管理装置。
10. 前記検証用データは、ネットワークにおける前記受付手段の位置を示すＵＲＩを含む
    ことを特徴とする請求項１乃至９の何れか１項に記載の管理装置。
11. 前記受付手段は、前記通信端末による前記検証用データに基づくアクセスを受け付けた際に、１以上の通信装置それぞれに対するアクセス権付与の可否を受け付ける
    ことを特徴とする請求項１乃至１０の何れか１項に記載の管理装置。
12. リソースに対する通信装置のアクセス権を管理する管理装置の制御方法であって、
    アクセス権の認可要求を通信装置から受信する第１の受信工程と、
    前記認可要求に含まれる情報に基づいて生成したデバイス識別子とユーザ識別子とを含む認可応答を前記通信装置に送信する第１の送信工程と、
    前記通信装置から前記ユーザ識別子を通知され操作移譲がされた通信端末から、前記ユーザ識別子を含む検証要求を受信する第２の受信工程と、
    前記検証要求に対する応答として、検証用データを前記通信端末に送信する第２の送信工程と、
    前記通信端末による前記検証用データに基づくアクセスを受け付ける受付工程と、
    前記受付工程におけるアクセスの受け付けに基づいて、前記通信装置に対するアクセス権付与の可否を決定する決定工程と、
    を含み、
    前記第２の受信工程において前記通信端末から複数の検証要求を受信した場合、前記第２の送信工程では、該複数の検証要求それぞれに対応する複数の通信装置へのアクセス権の付与をまとめて指示可能な検証用データを前記通信端末に送信する
    ことを特徴とする管理装置の制御方法。
13. コンピュータを、請求項１乃至１１の何れか１項に記載の管理装置の各手段として機能させるためのプログラム。

Images