アクセス認可装置
【課題】第三者がリソースの管理実体と直接信頼関係を構築できないケースにおいても、第三者に対してリソースへのアクセス権限を委譲可能とし、かつ第三者による不正なリソースへのアクセスを防ぐことを可能とする。
【解決手段】アクセス認可装置１０１は、受信部と、第1送受信部３０１と、トークン発行部３０４とを備える。受信部は、機器におけるリソースへのアクセスをアクセス承認から承認されたことを示す第1承認情報を、第1アプリケーションからネットワークを介して受信する。第1送受信部３０１は、第1承認情報を含むアクセス承認要求をアクセス承認装置１０２に送信し、第1アプリケーションによるリソースへのアクセス可否情報を受信する。トークン発行部３０４は、アクセス可否情報がリソースへのアクセス許可を示すとき、リソースへのアクセス権限を第1アプリケーションに与えるトークン情報を発行する。
【解決手段】アクセス認可装置１０１は、受信部と、第1送受信部３０１と、トークン発行部３０４とを備える。受信部は、機器におけるリソースへのアクセスをアクセス承認から承認されたことを示す第1承認情報を、第1アプリケーションからネットワークを介して受信する。第1送受信部３０１は、第1承認情報を含むアクセス承認要求をアクセス承認装置１０２に送信し、第1アプリケーションによるリソースへのアクセス可否情報を受信する。トークン発行部３０４は、アクセス可否情報がリソースへのアクセス許可を示すとき、リソースへのアクセス権限を第1アプリケーションに与えるトークン情報を発行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、アクセス認可装置に関する。
【背景技術】
【０００２】
あるインターネット上のサービスが、そのサービスの利用者の個人情報を含む、様々なサービスに係る情報や機能（以下、リソースと呼ぶ）を、当該サービスとユーザ以外の第三者（サードパーティ製のアプリケーション等）に利用させる際に、リソースにアクセスするための認証用情報（ユーザＩＤ（承認者ＩＤ）、パスワード等）を、サービスに公開せずに、アクセス権限のみを移譲する技術として非特許文献１がある。
【０００３】
非特許文献１は、リソースに対するアクセス権限移譲に際し、認証用情報をサービスに公開しないで済む、というメリットの他に、ユーザだけでなく、サービスの管理者が、第三者による不正なリソースへのアクセスを防ぐことができるというメリットがある。
【０００４】
非特許文献１は、主としてリソースの管理実体（上述のインターネット上のサービス）と第三者との間に、事前に直接信頼関係（契約関係）が構築できていることを前提としている。このため、リソースの管理実体の数が膨大かつ遍在しているなど、サービスが直接関係を構築できない場合（例えば、リソースの管理実体として家電機器を想定する場合など）には、非特許文献１は利用できない。したがって、ユーザ以外の、リソース管理実体の管理者が、第三者による不正なリソースへアクセスを防ぐことができない。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】E.Hammer-Lahav,Ed., D.Recordon, D.Hardt “The OAuth 2.0 Protocol”, Network Working Group, IETF, June 15, 2010
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述したように、従来技術は、リソースの管理実体の数が膨大かつ遍在しているなど、第三者がリソースの管理実体と直接信頼関係を構築できないケースにおいて、第三者に対してリソースへのアクセス権限を移譲できないという問題があった。さらに、ユーザ以外のリソース管理実体の管理者が、第三者による不正なリソースへのアクセスを防ぐことが出来ないという問題があった。
【０００７】
本発明は、上記従来技術の問題点を解決するためになされたものであって、第三者がリソースの管理実体と直接信頼関係を構築できないケースにおいても、第三者に対してリソースへのアクセス権限を委譲でき、かつ、ユーザ以外のリソース管理実体の管理者が、第三者による不正なリソースへのアクセスを防ぐことが可能なアクセス認可装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の実施形態としてのアクセス認可装置は、第1アプリケーションによって利用されるリソースを有する機器、およびアクセス承認装置とそれぞれネットワークを介して接続される。前記アクセス認可装置は、受信部と、第1送受信部と、トークン発行部と、送信部とを備える。
【０００９】
前記受信部は、前記機器における前記リソースへのアクセスをアクセス承認者から承認されたことを示す第1承認情報を、前記第1アプリケーションから前記ネットワークを介して受信する。
【００１０】
前記第1送受信部は、前記第1承認情報を含むアクセス承認要求を前記アクセス承認装置に送信し、前記第1アプリケーションによる前記リソースへのアクセスを許可するかを示すアクセス可否情報を前記アクセス承認装置から受信する。
【００１１】
前記トークン発行部は、前記アクセス可否情報が前記リソースへのアクセス許可を示すとき、前記リソースへのアクセス権限を前記第1アプリケーションに与えるトークン情報を発行する。
【００１２】
前記送信部は、前記トークン発行部により発行された前記トークン情報を前記第1アプリケーションに送信する。
【図面の簡単な説明】
【００１３】
【図１】本発明の第１の実施形態に係わるシステムの構成を示すブロック図。
【図２】本発明の第２の実施形態に係わるシステムの構成を示すブロック図。
【図３】承認情報のデータ構造の一例を示す図。
【図４】トークン情報のデータ構造の一例を示す図。
【図５】本発明の第１の実施形態に係わるシステムのネットワーク構成のバリエーションを示す図（１）。
【図６】本発明の第１の実施形態に係わるシステムのネットワーク構成のバリエーションを示す図（２）。
【図７】本発明の第１の実施形態におけるトークン発行処理に係わる通信シーケンス図（１）。
【図８】本発明の第１の実施形態におけるアクセス制御に係わる通信シーケンス図。
【図９】本発明の第１の実施形態におけるトークン無効化に係わる通信シーケンス図。
【図１０】本発明の第１の実施形態におけるトークン発行処理の動作を示すフローチャート。
【図１１】本発明の第２の実施形態における開発者・利用者登録に係わる通信シーケンス図。
【図１２】本発明の第２の実施形態における承認者・機器登録に係わる通信シーケンス図。
【図１３】本発明の第２の実施形態におけるトークン発行に係わる通信シーケンス図。
【図１４】本発明の第２の実施形態における利用者情報無効化に係わる通信シーケンス図。
【図１５】本発明の第１の実施形態におけるトークン発行処理に係わる通信シーケンス図（２）。
【発明を実施するための形態】
【００１４】
（第１の実施形態）
図１は、本発明の第１の実施形態に係わるアクセス認可装置の機能ブロックを示すシステム構成図である。第１の実施形態に係るシステムは、アクセス認可装置１０１と、アクセス承認装置１０２と、利用者認証装置１０３と、機器１０４と、アプリケーション（第1アプリケーション）１１０とで構成される。アクセス認可装置１０１、利用者承認装置１０２、利用者認証装置１０３、機器１０４は、ネットワーク２０１を介して接続されている。
【００１５】
次に、本実施の形態に係るアクセス認可装置１０１のハードウェア構成について説明する。本実施の形態のアクセス認可装置１０１は、装置全体を制御するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等の制御部と、各種データや各種プログラムを記憶するＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の主記憶部と、ＧＵＩ情報等の各種データや各種プログラムを記憶するＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の補助記憶部と、これらを接続するバスとを備えており、通常のコンピュータを利用したハードウェア構成となっている。また、アクセス認可装置１０１には、外部装置（１０２〜１０４）との通信を制御する無線または有線の通信Ｉ／Ｆ（ｉｎｔｅｒｆａｃｅ）が設けられている。各外部装置との通信は、ネットワーク２０１を介して行う。少なくとも、アクセス認可装置１０１は、ネットワーク２０１を介して、アクセス承認装置１０２、利用者認証装置１０３、機器１０４、機器１０４に搭載のアプリケーション（利用者）との間で情報を送受信する手段を有する。アクセス認可装置１０１は、例えば、インターネット上に存在するサーバ装置として実現される。本実施形態において、アクセス認可装置１０１は、インターネット上のサーバ装置であるとする。
【００１６】
なお、アクセス承認装置１０２と利用者認証装置１０３のハードウェア構成は、アクセス認可装置１０１と同様である。本実施形態においては、アクセス認可装置１０１と同じく、インターネット上に存在するサーバ装置であるとする。
【００１７】
次に、機器１０４のハードウェア構成について説明する。本実施の形態の機器１０４は、アクセス認可装置１０１と同様、通常のコンピュータを利用したハードウェア構成となっている。アクセス認可装置１０１との差分は、ユーザが、アプリケーション１１０による機器の内部リソースへのアクセスを承認するため、液晶ディスプレイ等のＧＵＩ表示部と、ユーザの指示入力を受け付けるキーボードやマウスやリモートコントローラ（リモコン）等の操作入力部を備えている点にある。アクセス認可装置１０１と同様、通信Ｉ／Ｆを備え、ネットワーク２０１を介して、アクセス認可装置１０１との間で情報を送受信する手段を有する。機器１０４は、例えば、パーソナルコンピュータ、デジタルテレビ、ハードディスクレコーダ、あるいは、スレートＰＣ やスマートフォン等のモバイルデバイスとして実現される。本実施形態において、機器１０４は、デジタルテレビであるとする。さらに、この機器１０４がアプリケーション１１０に対して提供するリソースは、テレビに内蔵されたハードディスクに蓄積されたデジタル地上波放送の録画番組リストであるとする。
【００１８】
ネットワーク２０１は、例えば、インターネット、または、品質保証された閉域網であるＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）などである。本実施形態において、ネットワーク２０１は、インターネットであるとする。
【００１９】
アプリケーション１１０は、図示しないサーバまたはCD-ROM等の記録媒体から機器１０４上にダウンロードされるソフトウェアである。これは、機器１０４のハードウェア（プロセッサ）がそのまま実行可能なバイナリ形式で配布されインストールされるネイティブアプリケーションであってもよく、Ｊａｖａ（登録商標）のように、ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）上で実行されるプログラム言語で記述され、ＶＭ経由で機器１０４上のプロセッサから実行される非ネイティブなアプリケーションであってもよい。後者において、さらに、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｕｎｇｕａｇｅ）、ＣＳＳ（Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔ）、ＪａｖａＳｃｒｉｐｔで記述された、いわゆるＷｅｂページと同等のＷｅｂアプリケーションであってもよい。Ｗｅｂアプリケーションの場合、機器１０４内部のローカルＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）サーバ上に配置されていてもよく、宅内ネットワークに配置されたプライベートサーバとして宅内のＬＡＮ上に設置されていてもよく、インターネット上のサービスを実現する外部サーバ上に配置されていてもよい。本実施形態では、ローカルＨＴＴＰサーバ上に配置されたＷｅｂアプリケーションであるとする。すなわち、アプリケーション１１０は、機器１０４（デジタルテレビ）上に搭載されたＷｅｂブラウザ上（あるいは、Ｗｅｂｋｉｔ等のＷｅｂブラウザを実現するミドルウェア上）で動作するＷｅｂコンテンツであるとする。
【００２０】
次に、上述したハードウェア構成において、アクセス認可装置１０１のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について図１に則して説明する。アクセス認可装置１０１は、第１送受信部３０１と、第２送受信部３０２と、トークン発行判定部３０３と、トークン発行部３０４と、トークン情報記憶部３０５と、トークン情報提供部３０６と、トークン無効化部３０７と、承認要求許可情報発行部３５１と、承認要求許可情報記憶部３５２と、承認要求許可情報認証部３５３とを有する。
【００２１】
このうち、第１送受信部３０１、第２送受信部３０２、トークン発行判定部３０３、トークン発行部３０４、トークン情報提供部３０６、トークン無効化部３０７、承認要求許可情報発行部３５１及び承認許可情報認証部３５３は、ＣＰＵのプログラム実行時にＲＡＭなどの主記憶部上に展開されるコードの実行により実現されるものである。
【００２２】
また、トークン情報記憶部３０５と承認許可情報記憶部３５２は、例えば、主記憶もしくは補助記憶部に構築されるデータベース管理システムである。これは、リレーショナルデータベースであってもよいし、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）データベースであってもよい。また、これは単一のデータベース管理システムで構築されている必要はなく、複数のデータベース管理システム、例えば、ＳＱＬｉｔｅ３、Ｏｒａｃｌｅ、ＭｙＳＱＬなどを併用しても良い。また、１つの物理的な記憶部上に構築されるようにしてもよいし、ＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）や、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）といった複数の物理的な補助記憶部で構成されるデータベース管理システムとしてもよい。また、データの格納領域が不揮発であっても揮発であってもよい。あるいは、各記憶部に各々記憶されるデータの単位情報（エントリ）を取得できる手段を備えていれば、ＣＰＵのプログラム実行時に主記憶上に生成されるリスト構造ベースの簡易なデータ管理モジュールであってもよいし、ＣＳＶ形式ファイルの管理モジュールであってもよいし、Ｋｅｙ／Ｖａｌｕｅストアで構成されていてもよい。
【００２３】
続いて、以下に本実施形態を構成する各部の詳細について説明する。
【００２４】
第１送受信部３０１はアクセス承認装置１０２とデータ通信を行う。第1送受信部３０１はアクセス承認装置１０２に対して、アプリケーション１１０を識別する利用者識別情報と、機器１０４を識別する機器識別情報と、アプリケーション１１０が、機器１０４のリソースへのアクセスに対して該当するアクセス承認者から承認を得たことを示す承認情報（第1承認情報）と、を送信し、機器１０４のリソースに対するアプリケーション１１０によるアクセスの可否を表したアクセス可否情報を受信する。この送受信処理は、ネットワーク２０１上で行われ、例えば、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）通信で実現される。このとき、一般的には、第１送受信部３０１が、ＨＴＴＰクライアントとなり、アクセス承認装置１０２がＨＴＴＰサーバとなる。但し、実現形態としては、この限りではなく、アクセス承認装置１０２から第１送受信部３０１に対して通信コネクションを確立する構成も考えられる。この場合、逆に第１送受信部３０１が、ＨＴＴＰサーバとしてふるまうことになる。このネットワーク２０１を介した通信は、ＨＴＴＰに限定されるものではなく、上述のデータが送受信しできる限りに置いては、既存の他の通信プロトコルを用いてもよいし、独自の通信プロトコルを設計して用いてもよい。この前提は、本発明に係るネットワーク２０１を介した通信全てに当てはまる。以下、第１送受信部３０１が、送受する各情報について解説する。
【００２５】
まず、利用者識別情報は、利用者認証装置１０３が、アプリケーション（利用者）１１０に対して発行する情報である。利用者識別情報は、アプリケーション１１０を一意に識別する。アプリケーション１１０の開発者は、アプリケーション１１０の公開・配布前に、利用者認証装置１０３から利用者識別情報の発行を受け、アプリケーション１１０の内部に設定しておく。これは、例えば、利用者認証装置１０３が、アプリケーション登録用のＷｅｂページを用意しておき、前記開発者が、このＷｅｂページの登録フォーマットに必要事項を入力、申請することで発行されるようにしてもよい。あるいは、利用者識別情報の発行を電子メールベースで要求してもよい。アプリケーション１１０が公開・配布される前に、アプリケーションの内部に設定される限りに置いては、どのような発行形態を採っても構わない。利用者識別情報は、利用者認証装置１０３内で、利用者を一意に識別可能な利用者ＩＤを含み、さらに利用者ＩＤの正当性を認証するための秘密情報を含み得る。
【００２６】
機器識別情報は、機器１０４を一意に識別できる情報である。具体的には、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）、製品型名と製造番号との組み合わせ等が考えられる。機器識別情報の形式は、アクセス認可装置１０１や、アクセス承認装置１０２において、機器が一意に識別可能であれば、どのような形式であっても構わない。
【００２７】
承認情報（第1承認情報）は、アクセス承認装置１０２が、アプリケーション１１０に対して発行する情報であり、アプリケーション１１０が、機器１０４のリソースに対するアクセスを、アクセス承認者（例えば、機器１０４の所有者、機器１０４を開発した機器メーカなど）から承認されていることを示す情報である。承認情報は、少なくとも承認が得られたことを示すアクセス可否検証コードを含み、さらに、このアクセス可否検証コードの正当性を証明するための秘密情報、承認された機器１０４のリソースの種別情報、属性情報、あるいは、範囲情報を含み得るものである。承認情報の具体的な構成例を、図３に示す。
【００２８】
アクセス承認装置１０２から返されるアクセス可否情報は、前記承認情報が正しいか否か、すなわち、アクセスが承認されているか否かを表す論理値である。
【００２９】
第２送受信部３０２は、利用者認証装置１０３とデータ通信を行う。第２送受信部３０２は利用者識別情報を、利用者認証装置１０３に対して送信し、利用者認証結果情報を受信する。この利用者認証結果情報は、少なくとも、利用者認証装置１０３内で実行される利用者認証（すなわち利用者識別情報に係るアプリケーションが正当なものである（事前に登録されている）かの認証）が成功したか否かを表す論理値を含む。第２送受信部３０２は、利用者認証装置１０３と、ネットワーク２０１を介して通信する。この通信は、一般的には、ＨＴＴＰ通信によって実現されることが想定されるが、第１送受信部３０１の説明で述べたとおり、これに限られない。
【００３０】
トークン発行判定部３０３は、第１送受信部３０１がアクセス承認装置１０２から受信したアクセス可否情報と、第２送受信部３０１が利用者認証装置１０３から受信した利用者認証結果情報とに基づき、トークンの発行可否を判定する。アクセス可否情報が「可」で、利用者認証結果情報が「成功」を示すものであれば、トークンの発行を許可し、これ以外の場合は、トークンの発行を許可しない。
【００３１】
トークン発行部３０４は、アプリケーション１１０から、利用者識別情報と、機器識別情報と、承認情報を取得する。トークン発行部３０４は受信部（図示しない）によりこれらの情報をアプリケーションから受信する。トークン発行部３０４は、取得したこれらの情報を、前記トークン発行判定部３０３に渡し、トークンの発行可否の判定を要求する。トークン発行部３０４は、トークン発行判定部３０３から、発行「可」の判定結果を取得すると、トークンを含むトークン情報を生成し、アプリケーション１１０に送信部（図示しない）からトークン情報を送信する。逆に、発行「否」の判定結果を取得すると、トークン発行エラーメッセージを生成し、アプリケーション１１０に送信部（図示しない）からトークン発行エラーメッセージ送信する。生成したトークン情報は、後述するトークン情報記憶部３０５に登録する。このトークン発行に係る、アプリケーション１１０（が動作する機器１０４）とトークン発行部３０４との間の通信も、ネットワーク２０１を介して行われる。一般的には、ＨＴＴＰ通信によって実現されることが想定されるが、第１送受信部３０１の説明で述べたとおり、この限りではない。上記受信部、送信部（図示しない）はトークン発行部等と同様にＣＰＵのプログラム実行時にＲＡＭなどの主記憶部上に展開されるコードの実行により実現されてもよい。
【００３２】
ここでトークンは、トークン情報の識別子であり、たとえば固定長のビット列として実現されることができる。トークンは、アクセス認可装置１０１内で、「特定のアプリケーションからの、特定リソースへのアクセス」を特定できる限りは、どのようなフォーマットであってもよい。
【００３３】
トークン情報は、少なくともトークンを含み、さらに、利用者識別情報、機器識別情報、承認情報、アプリケーション１１０に関する情報である利用者情報、機器１０４に関する情報である機器情報、トークンの有効期限情報、および、トークンが有効か否かを示す論理値情報を含み得る。ここで、利用者情報は、前述した利用者識別情報の発行時に、アプリケーション１１０の開発者が利用者認証装置１０３に登録するアプリケーションの諸情報（アプリケーション名、アプリケーションの概要情報、開発日時、バージョン、開発者情報へのポインタなど）や、開発者情報（開発者名、開発会社名、連絡先など）を含む。また、機器情報は、機器の製品名、型番、製造番号、公開するリソース情報などを含み得るものである。トークン情報の具体的な構成例を、図４に示す。
【００３４】
トークン情報記憶部３０５は、トークン発行部３０４が生成したトークン情報を記憶する。
【００３５】
トークン情報提供部３０６は、機器１０４からトークン取得要求を取得し、該当するトークン情報を、トークン情報記憶部３０５から機器１０４に提供する。トークン取得要求は、特定のトークンに対するトークン情報を要求するものであってもよく、特定の機器に対する全てのトークン情報を要求するものであってもよく、特定のアプリケーションに対する全てのトークン情報を要求するものであってもよい。あるいは、トークン情報記憶部３０５に蓄積された、全ての有効なトークン情報を要求するものであってもよく、逆に、全ての無効なトークン情報を要求するものであってもよい。なお、トークン取得要求に係る通信も、ネットワーク２０１を介して行われる。一般的には、ＨＴＴＰ通信によって実現されることが想定される。この場合、トークン情報提供部３０６は、ＨＴＴＰサーバとして機能する。使用される通信プロトコルは、ＨＴＴＰに限定されるものではない。第１送受信部３０１の説明で述べたとおり、この限りではない。さらに、トークン情報提供部３０６は、トークンが無効化されたり、内容が更新されたりした場合に、この変更を、該当する機器に対して通知してもよい。この場合、トークン情報提供部３０６は、機器との間に、予め通信チャネルを確立・維持しておき、この通信チャネルを使って、変更が発生すると同時に、その内容を通知するようにしてもよい。これは、Ｃｏｍｅｔ等のＨＴＴＰロングポーリングを用いることで実現してもよく、あるいは、ＨＴＴＰ通信を用いて、双方向通信用のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを構築するＷｅｂＳｏｃｋｅｔを用いて実現してもよい。その他、サーバ側からＰｕｓｈ型の非同期通知を実現する枠組みであれば、どのような技術を用いても構わない。
【００３６】
トークン無効化部３０７は、発行済のトークンに対する無効化要求を取得し、当該トークンの無効化として、トークン情報記憶部３０５の該当トークンを含むトークン情報を削除するか、あるいは、前述したトークン情報に含まれる有効・無効を表す論理値情報を無効に設定する。さらに、トークンの無効化を、発生と同時に、該当機器に対して通知するために、トークン情報提供部３０６に対して、トークン情報を渡し、無効化の通知を依頼する。なお、無効化要求は、ネットワーク２０１を介した通信で実現されてもよく、あるいは、オフラインで実現されてもよい。例えば、機器のユーザが、コールセンターに電話をかけ、不正なアプリケーションを報告することをもって、無効化要求とみなすことも出来る。あるいは、メールベースでの報告でもよい。アクセス認可装置１０１のオペレータが、こうした無効化要求を受けて、トークン情報記憶部３０５の実体であるデータベースシステムを操作することで、トークンの無効化が実現されてもよい。
【００３７】
承認要求許可情報発行部３５１は、利用者認証結果情報に基づき、承認情報を取得するために必要となる承認要求許可情報を発行する。この承認要求許可情報は、以下に説明する承認要求許可情報記憶部３５２にて一意に識別可能な承認要求許可ＩＤを含み、さらに、このＩＤの正当性を認証するための秘密情報を含み得る。
【００３８】
承認要求許可情報記憶部３５２は、承認要求許可情報発行部３５１が発行した承認要求許可情報を記憶する。この認証要求許可情報記憶部３５２は、実現形態としては、トークン情報記憶部３０５と統合された形で実現されてもよい。
【００３９】
承認要求許可情報認証部３５３は、アクセス承認装置１０２からの承認要求許可情報の認証要求を受け、承認要求許可情報記憶部３５２に記憶された情報に基づいて認証し、認証情報を返す。例えば、承認要求許可情報認証部３５３は、アクセス承認装置１０２から、承認要求許可ＩＤと、秘密情報のハッシュ値、及び、利用したハッシュ関数の情報を渡され、承認要求許可情報記憶部３５２に蓄積された秘密情報のハッシュ値を、渡されたハッシュ関数の情報に基づいて求め、一致するか否かを判定する。あるいは、ハッシュ値ではなく、メッセージと、この秘密情報を用いて付与した署名を用いて、認証を行ってもよい。
【００４０】
次に、図３、図４、図７、図８、図９、図１０を用いて、本実施形態に係るアクセス認可装置３３０１の動作について説明する。図３は、本実施形態におけるアクセス承認装置１０２が発行する承認情報を示すものである。図４は、トークン情報記憶部３０５が、本実施形態において記憶する、アプリケーション１１０が機器１０４のリソースにアクセスするために取得したトークン情報を示すものである。
【００４１】
図７は、本実施形態に係るトークン発行処理の基本シーケンスを示したものである。また、図８は、本実施形態に係るアクセス制御処理の基本シーケンスを示したものである。図９は、本実施形態に係るトークン無効化処理の基本シーケンスを示したものである。図１０は、アクセス認可装置１０１の、トークン発行処理を示すフローチャートである。
【００４２】
なお、本実施形態では、機器１０４はデジタルテレビであり、アクセス対象のリソースは、テレビ内に蓄積された録画番組情報である。また、アプリケーション１１０は、この録画番組情報を利用した、録画リストの閲覧・操作を行う、録画ナビゲーションアプリである。
【００４３】
以下、まず図７のシーケンス図に基づいて、利用者識別情報の発行、トークンの発行から、発行されたトークンに基づくリソースアクセスに至る処理手順を説明する。
【００４４】
まず、前提として、ユーザが、アクセス承認装置１０２に対して、自身が機器１０４（デジタルテレビ）のアクセス承認者であることを登録する（ステップＳ１０１）。このステップは、アクセス承認者としてのユーザ登録を行ない（この際ユーザＩＤ、パスワード等の登録も行う）、その後、所有する機器情報の登録を適宜行うなどの段階的な実施が考えられる。具体的には、アクセス承認装置１０２が、アクセス承認者の登録、および、アクセス承認者が所有する機器の登録を行うためのＷｅｂページを用意することで実現してもよい。あるいは、機器１０４に、アクセス承認装置１０２のＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）をプリセットしておき、機器１０４をネットワーク２０１に接続すると、この機器情報が自動登録され、かつ、ＰＩＮコードや二次元バーコード等を用いて、機器とユーザ（アクセス承認者）が紐付けられるようにすることで、それぞれの登録を実現してもよい。いずれにしても、本実施形態においては、アクセス承認装置１０２は外部装置であるため、この実施形態は問わない。
【００４５】
次に、利用者認証装置１０２が、利用者識別情報をアプリケーション１１０（録画ナビゲーションアプリ）に対して発行する（ステップＳ１０２）。このステップは、前述したように、アプリケーション１１０の開発者が、録画アプリの公開・配布前に、アプリケーションの内部にプリセットしておく実現形態が考えられる。しかし、このステップも、利用者認証装置１０３が外部装置であるため、実施形態は問わない。この後、アプリケーション１１０が公開・配布され、機器１０４上にダウンロードされる（ステップＳ１０３）。
【００４６】
ここで、ユーザがリソースアクセスを伴うアプリケーション操作を行う（ステップＳ１０４）。本実施形態では、アプリケーション１１０は、録画ナビゲーションアプリなので、起動段階で、リソース（録画番組リスト）へのアクセスが発生し得る。アプリケーション１１０は、リソースアクセスが発生すると（具体的には、機器１０４がアプリケーションに対して公開している録画番組リスト取得ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）が呼び出されると）、アクセス認可装置１０１に対して、アクセス承認要求を送信する（ステップＳ１０５）。このとき、後段のステップＳ１０８からＳ１０９まで、アクセス承認装置１０２にリダイレクトされるため、再びアプリケーション１１０の画面を表示するため、このアクセス承認要求に対して、コールバックＵＲＩを指定する。さらに、アクセス承認に必要な情報として、利用者識別情報と、機器識別情報とをパラメータとして含める。なお、本実施形態において、このステップは、ＨＴＴＰ ＧＥＴリクエストで実現される。
【００４７】
続いて、アクセス認可装置１０１は、アクセス承認要求を受信して、アクセス承認装置１０２へ、リクエストをリダイレクトする（ステップＳ１０６、Ｓ１０７）。本実施形態では、ＨＴＴＰ ＧＥＴレスポンスに、アクセス承認装置１０２の承認画面のＵＲＩを、Ｒｅｆｅｒヘッダに指定することで実現する。このとき、リダイレクト先のＵＲＬに、ステップＳ１０５で指定した利用者識別情報と、機器識別情報と、コールバックＵＲＩをクエリパラメータとして含める。
【００４８】
ここで、リダイレクトによって、ユーザの操作対象が、機器１０４上のアプリケーション１１０から、同じく機器１０４上のＷｅｂブラウザによるＷｅｂページアクセスに切り替わる。Ｗｅｂブラウザは、Ｒｅｆｅｒヘッダに従って、利用者識別情報と、機器識別情報と、コールバックＵＲＩを伴って、アクセス承認画面を要求する（ステップＳ１０８）。当該要求にユーザＩＤおよびパスワード等を含めてもよい。
【００４９】
アクセス承認装置１０２は、応答としてアクセス承認画面を返す（ステップＳ１０９）。このとき、利用者識別情報と、機器識別情報とを、承認画面に組み込み、ユーザが「何というアプリが、どのリソースにアクセスしようとしているか」を認識出来るようにする。本実施形態においては、「録画ナビゲーションアプリが、デジタルテレビ内に蓄積された録画番組リストへのアクセスを求めている」ことを表示する。
【００５０】
続いて、ユーザが、アプリケーション１１０から機器１０４へのアクセスを許可するか否かを、アクセス承認装置１０２対し、表示されたＷｅｂページのインタフェースを介して応答する（ステップＳ１１０）。アクセス承認装置１０２は、応答が許諾を示すものであった場合には、その許可内容を含む承認情報（図３参照）を発行し、レスポンスに含める（ステップＳ１１１）。このとき、アクセス承認画面からアプリケーション１１０の画面に再遷移するために、ステップＳ１０８で渡されたコールバックＵＲＩをリダイレクト先として、Ｒｅｆｅｒヘッダに指定する。前記の承認情報は、このコールバックＵＲＩのクエリパラメータとして設定されてもよい。アクセス承認装置１０２は、発行した承認情報を、利用者識別情報および機器識別情報の組に関連づけ記憶する。
【００５１】
Ｗｅｂブラウザは、アクセス承認の応答に含まれる、このＲｅｆｅｒヘッダに従って、アプリケーション１１０の画面へリダイレクトする（ステップＳ１１２）。
【００５２】
アプリケーション１１０は、アクセスされたＵＲＩ（コールバックＵＲＩ）のクエリとして設定された、承認情報に加え、利用者識別情報と、機器識別情報とを、トークン発行要求に含めて、アクセス認可装置１０１に送信する（ステップＳ１１３）。
【００５３】
アクセス認可装置１０１がトークン発行要求を受信すると、トークン発行部３０４は、受信した承認情報、利用者識別情報、機器識別情報を、トークン発行判定部３０３に渡す。トークン発行判定部３０３は、第２送受信部３０２を介して、利用者認証装置１０３に利用者識別情報を送信し（ステップＳ１１４）、利用者認証結果情報を受信する（ステップＳ１１５）。利用者認証装置１０３は、受信した利用者識別情報が内部に登録済みであるときは、認証成功を返し、それ以外の場合は認証失敗を返す。またトークン発行判定部３０３は、第１送受信部３０１を介して、アクセス承認装置１０２に承認情報、利用者識別情報、機器識別情報を送信し（ステップＳ１１６）、アクセス可否情報を受信する（ステップＳ１１７）。アクセス承認装置１０２では、利用者識別情報および機器識別情報の組に関連づけて記憶されている承認情報が存在し、かつそのアクセス可否検証コードが、受信した承認情報に含まれるものと同一であればアクセス可と判定する。それ以外の場合は不可と判定する。トークン発行判定部３０３は、得られたアクセス可否情報と利用者承認結果情報から、トークン発行可否を判定する。それぞれ「可」および「成功」のときはトークン発行「可」と判定し、それ以外の場合は「不可」と判定する。トークン発行判定部３０３は、判定結果をトークン発行部３０４に渡す。トークン発行部３０４は、この判定結果に基づき、トークン発行「可」の場合には、トークンを含むトークン情報を生成し（ステップＳ１１８）、生成したトークン情報をトークン情報記憶部３０５に記憶する（ステップＳ１１９）。トークン発行部３０４は、発行したトークンまたはトークン情報をアプリケーション１１０に応答する（ステップＳ１２０）。
【００５４】
以上のアクセス認可装置１０１（トークン発行判定部３０３及びトークン発行部３０４）におけるトークン発行処理のフローチャートを図１０に示す。
【００５５】
最後にアプリケーション１１０はリソースへのアクセスを行い（ステップＳ１２１）、リソースアクセス結果をユーザに表示する（ステップＳ１２２）。ここでは、アプリケーションＳ１２１は、デジタルテレビ内に蓄積された録画番組のリストを取得し、取得した結果をユーザに提示する。
【００５６】
ここで、ステップＳ１２１におけるリソースアクセスの処理手順の詳細を、図８のシーケンス図をベースに説明する。
【００５７】
まず、アプリケーション１１０は、録画番組リスト取得ＡＰＩを呼び出す（ステップＳ１２１０）。本実施形態においては、アプリケーション１１０は、機器１０４内のローカルＨＴＴＰサーバ上に配置されたＷｅｂアプリケーションであるから、このＡＰＩは、Ｗｅｂページから呼び出し可能なＪａｖａＳｃｒｉｐｔにバインディングされたプラグインとして実現されていてもよいし、同じローカルＨＴＴＰサーバ上に配置されたＷｅｂ ＡＰＩとして実現されていてもよい。これは、アプリケーションの形態によっては、バイナリ形式のネイティブライブラリのＡＰＩであってもよく、ＡＰＩの形式は問わない。このとき、アプリケーションは、ＡＰＩの引数としてトークン（および、トークンと共に発行された秘密情報）を渡す。
【００５８】
機器１０４は、ＡＰＩ呼び出しを受けて、引数として渡されるトークンに対応するトークン情報の取得要求を、アクセス認可装置１０１上のトークン情報提供部３０６に対して送信する（ステップＳ１２１１）。このとき、トークンと共に、トークンと共に発行された秘密情報、機器識別情報、および、機器の機種情報などをあわせて送信してもよい。なお、機器１０４とトークン情報提供部３０６間の通信は、暗号化されることが望ましい。例えば、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）や、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）プロトコルを用いたＨＴＴＰＳ通信を用いてもよく、ＩＰＳｅｃを用いてもよく、送受されるデータ（トークンまたはトークン情報）がネットワーク２０１上にそのまま流れない限りにおいては、独自の暗号通信を用いてもよい。
【００５９】
トークン情報提供部３０６は、トークンを受信すると、機器１０４の認証を行う（ステップＳ１２１２）。これは、当該機器へのアクセスに対してトークンが発行されたか否かをトークン情報記憶部３０５に記憶された情報を用いて検証することで行ってもよく、あるいは、当該機器の機種が、トークンの発行対象たるリソースを公開しているものか否かを検証することをもって行ってもよい。あるいは、アクセス承認装置１０２に対して、アクセス承認対象機器として登録されているか否かを問い合わせることで行ってもよい。機器認証は、トークン情報に含まれる他の情報を用いて実施してもよく、以上に挙げた具体的方法の組み合わせで実施してもよい。
【００６０】
次に、トークン情報提供部３０６は、渡されたトークンの認証を行う（ステップＳ１２１３）。これは、トークンと共に発行された秘密情報の照合をもって実施してもよく、単にトークン情報記憶部３０５から、対応するトークン情報を取得する際に、該当する有効なトークン情報があるか否かをもって実施してもよい。このトークン検証は、トークン情報に含まれる他の情報を用いて実施してもよく、以上に挙げた具体的方法の組み合わせで実施してもよい。トークン情報提供部３０６は、トークン情報記憶部３０５から、対応するトークン情報を取得し（ステップＳ１２１４、Ｓ１２１５）、これを機器１０４に対して提供する（ステップＳ１２１６）。もし、該当するトークンが存在しない場合、あるいは、機器認証（ステップＳ１２１２）とトークン認証（ステップＳ１２１３）が失敗した場合は、機器１０４に対して、エラー応答を行うか、空のトークン情報を返す。
【００６１】
機器１０４は、トークン情報を受信すると、アプリケーション１０４から渡されたトークンと、トークン情報提供部３０６から取得したトークン情報とを用いて、アクセス可否判定を行う（ステップＳ１２１７）。前述したステップＳ１２１３におけるトークン認証は、ここで（すなわち機器側で）行われてもよい。トークン情報要求に対してエラー応答を受信した場合や、空のトークン情報を受信した場合には、アクセス「否」の判定を行う。一方、応答にトークン情報が含まれていた場合には、トークン情報に含まれるアクセス可能なリソースの範囲に、ステップＳ１２１０で呼び出されたＡＰＩ（録画番組リスト取得ＡＰＩ）が含まれているかどうかを判定する。含まれていれば、アクセス可否判定を「可」とし、機器内のリソースを取得し（ステップＳ１２１８）、アプリケーション側に提供する（ステップＳ１２１９）。トークン情報に有効フラグまたは有効期限が含まれている場合は、有効フラグが「有効」であり、有効期限が徒過していないことを、アクセス可否判定の「可」の条件として、加える。より簡単な判定として、有効なトークン情報の受信をもってアクセス可と判定してもよい。
【００６２】
ここで、図９を用いて、トークンを無効化する処理手順について説明する。
【００６３】
まず、トークンの無効化権限保持者が、トークン無効化要求をトークン無効化部３０７に対して行う（ステップＳ１２３）。この無効化権限保持者は、例えば、アプリケーション１１０を開発した開発者、機器１０４の機器メーカ、アプリケーション１１０及び機器１０４のユーザ、あるいは利用者認証装置１０３等が想定される。この無効化要求の発生は、アプリケーション開発者が、アプリケーションの不具合によるコンピュータウイルス感染や、機器のリソース破壊などを防止するために行ったり、不正なアプリケーションが発覚した場合に、機器メーカや一般ユーザが当該アプリケーションの排除を行う目的で行ったり、利用者認証装置１０３が、アプリケーションに発行された利用者識別情報が失効したことを、アクセス認可装置１０１に自動通知することによって行われたりすることが考えられる。また、前述の図７のステップＳ１１４における利用者認証要求に対する応答（ステップＳ１１５）が認証失敗を示すものであった場合に、当該利用者識別情報を、トークン情報に含むトークンを失効するように、トークン発行判定部３０３が、トークン無効化部３０７に要求することで行われてもよい。
【００６４】
トークン無効化部３０６は、無効化要求を受信すると、該当トークン情報の無効化をトークン情報記憶部３０５に対して要求する（ステップＳ１２４）。
【００６５】
トークン情報記憶部３０５は、要求に基づいて該当トークンを無効化し、処理結果を応答する（ステップＳ１２５）。無効化は、たとえば当該トークンを含むトークン情報の削除、または当該トークン情報に含まれ有効フラグを「無効」にすることで行う。このとき、続くステップＳ１２７以降に示す、該当トークンの無効化通知を実行する場合には、無効化したトークン情報を応答に含める。
【００６６】
このように、トークン無効化部３０６は、トークン情報記憶部３０５に無効化要求を送り、応答を受けることで、トークンの無効化を実現する（Ｓ１２６）。トークン無効化部３０６は、トークンを無効化すると、トークン情報提供部３０６に対して、該当トークンの対象機器１０４へのトークンの無効化通知を要求する（ステップＳ１２７）。このとき、該当トークンの対象機器の情報は、ステップＳ１２５における応答に含まれるトークン情報から得られる。
【００６７】
トークン情報提供部３０６は、無効化通知要求を受けて、該当トークンが無効化された旨を通知する（ステップＳ１２８）。このとき、前述したように、機器１０４とトークン情報提供部３０６の間には既に通信チャネルが確立されていて、この無効化通知は、ＣｏｍｅｔやＷｅｂＳｏｃｋｅｔといった非同期通信技術を用いて実現される。
【００６８】
一方、機器１０４は、トークン情報提供部３０６から無効化通知を受信すると、以前にトークン情報提供部３０６から受信し、キャッシュしていた該当トークン情報を無効化する（ステップＳ１２９）。機器１０４は、機器側で、該当トークンを無効化したことをアクセス認可装置側（トークン情報提供部３０６）に応答する（ステップＳ１３０、Ｓ１３１）。
【００６９】
以上のように、本実施形態によれば、アクセス認可装置によって、第三者（アプリケーション１１０、あるいは、その開発者）がリソースの管理実体（機器１０４、すなわち、デジタルテレビ、および、その所有者であるユーザ）と直接信頼関係を構築できないケースにおいても、第三者に対してリソースへのアクセス権限を委譲可能とし、かつ、ユーザ以外のリソース管理実体の管理者（例えば、機器メーカ）が、第三者による不正なリソースへのアクセスを防ぐことが可能となっている。
【００７０】
具体的には、リソースの管理実体としてのデジタルテレビは膨大な数存在し、かつ、アプリケーションが販売・配布された後にも、製造、販売され得るため、特定のデジタルテレビに対するアクセス認可を、アプリケーション１１０に対して、事前に発行することができない。こうしたケースであっても、第１に、図７のステップＳ１０８からステップＳ１１１において、アプリケーション１１０を介さずに、ユーザが承認処理を行うことで、アクセス承認装置１０２において、ユーザのＩＤやパスワードが必要な場合であっても、これをアプリケーションに漏らさずに、承認処理を行うことができる。つまり、ユーザからアプリケーションに対して、権限を移譲することが出来ている。第２に、発行したトークンを、ユーザのみならず、機器メーカをはじめとする権限保持者が無効化し、さらに無効化情報を機器側に伝える（図９のステップＳ１２７からステップＳ１３１）、もしくは、機器側が取得することで（図８のステップＳ１２１１からステップＳ１２１６）、アプリケーションによるリソースの不正利用を防ぐことが可能となっている。
【００７１】
＜利用者認証のバリエーション＞
本実施形態のトークン発行処理シーケンスは、図７に限定されるものではない。特に利用者認証を、ユーザ（アクセス承認者）から承認を得る前に行ってもよい。
【００７２】
図１５は、トークン発行処理シーケンスのバリエーションを示したものである。このバリエーションのシーケンスでは、承認要求許可情報発行部３５１、承認要求許可情報記憶部３５２、承認要求許可情報認証部３５３を用いる。
【００７３】
本バリエーションのシーケンスでは、利用者認証を経て、初めてアクセス承認者からの承認が得られる。具体的に、図７におけるアクセス承認要求（ステップＳ１０５、Ｓ１０６）時に、利用者認証を行う（図１５のステップＳ１５６、Ｓ１５７）。ここで、利用者認証が成功した場合に、承認要求許可情報発行部３５１が、承認要求許可情報を、アプリケーション（利用者）に対して発行し、これを承認要求許可情報記憶部３５２に記憶する。ここで、承認要求許可情報は、承認要求許可情報記憶部３５２内で一意に識別可能な承認要求許可ＩＤを含み、さらにこのＩＤの正当性を証明するための秘密情報を含み得る。承認要求許可情報はアプリケーションおよびユーザへの応答に含められる（ステップＳ１５８，Ｓ１５９）
ユーザは、アクセス承認装置１０２に、認証画面を要求する際に（ステップＳ１６０）、この承認要求許可情報を渡す。アクセス承認装置１０２は、渡された承認要求許可情報を、アクセス認可装置１０１上の承認要求許可情報認証部３５３に送信する（ステップＳ１６１）。承認要求許可情報認証部３５３は、承認要求許可情報認証部３５３に記憶された該当承認要求許可情報と、受信した前記情報を照合して認証し（ステップＳ１６２）、認証結果を返す（ステップＳ１６３）。たとえば受信した情報に含まれるＩＤと同一ＩＤを含む承認要求許可情報が、承認要求許可情報記憶部３５２に記憶されていれば認証成功とし、それ以外の場合は認証失敗とする。認証が成功すれば、アクセス承認装置１０２は、承認画面をユーザ返す（ステップＳ１６４）。ここで、図７におけるトークン発行要求を受けての利用者認証（ステップＳ１１４、Ｓ１１５）は、図１５のシーケンスにおいては必要ない。
【００７４】
＜トークン発行処理のバリエーション＞
また、本実施形態で述べたトークン発行処理シーケンスは、図７に限定されるものではない。例えば、トークン発行時に、利用者（アプリケーション）の認証を行う必要がなければ、利用者認証処理（ステップＳ１１４、ステップＳ１１５）を省略してもよい。また、アクセス承認装置１０２上のアクセス承認要求先を、予めアプリケーション１１０内にプリセットしておくことで、ステップＳ１０５、ステップＳ１０６を省略することができる。また、アプリケーション１１０が、信頼できるアプリケーションである場合には、アクセス承認装置１０２の承認ページにリダイレクトせずに、直接アプリケーションを介して、ユーザのＩＤやパスワードをアクセス承認装置１０２に送信するようにしてもよい。この場合、ステップＳ１０７及びステップＳ１１２を省略し、ステップＳ１０８からステップＳ１１１までの処理を、直接アプリケーション１１０から行うように構成してもよい。
【００７５】
＜リソースアクセス制御のバリエーション＞
また、本実施形態で述べたリソースアクセス処理シーケンスは、図８に限定されるものではない。図８では、アプリケーションからのリソースアクセスが発生する都度、トークン情報提供部３０６から必要なトークン情報を取得するように構成しているが、リソースアクセスのシーケンスとは別に、定期的にトークン情報提供部３０６にアクセスし、特定の機器（機器１０４）に対する全てのトークン情報を取得したり、特定のアプリケーション（アプリケーション１１０）に対する全てのトークン情報を取得したり、あるいは、トークン情報記憶部３０５に蓄積された、全ての有効なトークン情報、あるいは、無効なトークン情報を取得したりし、取得したトークンを機器内部に蓄積し、これをアクセス判定に利用するように構成してもよい。この場合、ステップＳ１２１１からステップＳ１２１６までの処理は省略できる。また、無効化処理で説明したように、アクセス認可装置１０１（トークン情報提供部３０６）から機器１０４に対して通知する手段が採れる場合には、生成されたトークン情報を端末側にタイムリーに通知することで、同様に、ステップＳ１２１１からステップＳ１２１６までの処理を省略することができる。図７のステップＳ１０４でリソースアクセス要求を受けた際、該当する有効なトークン情報が存在するか判断し、存在するときは、ステップＳ１０５〜Ｓ１２０を実施せずに、ステップＳ１２１を実施してもよい。
【００７６】
＜ネットワーク構成のバリエーション＞
なお、図５および図６は、本実施形態で述べたアクセス認可装置を含むシステムにおけるネットワーク構成のバリエーションを示すものである。ただし、ここでは、図１５のシーケンスを行わない場合を想定し、承認要求許可情報発行部３５１、承認要求許可情報記憶部３５２、承認要求許可情報認証部３５３を図１のアクセス認可装置を省いている。図１５のシーケンスを行う場合は、これらの要素３５１〜３５３を、図５または図６のアクセス認可装置に設ければよい。
【００７７】
これまで述べてきた実施形態においては、簡単のために、ネットワーク２０１（インターネット）に全てのシステム構成要素が接続されていることを想定していたが、図５および図６の構成では、機器１０４がネットワーク２０２に接続されている。ネットワーク２０２は、例えば、有線又は無線ＬＡＮ（ＬｏｃａｌＡｒｅａ Ｎｅｔｗｏｒｋ）で構成されるホームネットワークである。ネットワーク２０１とネットワーク２０２は、ブロードバンドルータ等のＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）の終端装置で接続されており、機器１０４とアクセス認可装置１０１の間の通信は、この終端装置を経由して実現される。
【００７８】
また、図６では、アプリケーションが機器１０４ではなく、ネットワーク２０２上の別の機器（操作機器１０５）にダウンロードされている。すなわち図１または図５の構成ではアプリケーションが動作する機器は機器１０４であったが、図６の構成では、アプリケーションが動作する機器は機器１０５である。アプリケーション１１０が、アクセス対象機器１０４を発見し、その機器識別情報（および機器情報）を知る何らかの手段があれば、アプリケーション１１０と機器１０４が、ネットワーク上の別のエンティティに存在してもよい。上述の手段には、例えば、宅内機器の発見を含むプラグアンドプレイを実現する、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ Ａｎｄ Ｐｌａｙ）、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）が利用できる。周辺機器を発見し、そのリソースを認識出来る手段を備えていれば、これらの既存プロトコルに限らず、独自プロトコルを含む別の手段を用いてもよい。
【００７９】
（第２の実施形態）
次に、アクセス認可装置の第２の実施の形態について説明する。なお、第１の実施形態と多くの部分で共通するため、同一の符号を使用して説明したり、説明を省略したりする。
【００８０】
図２は、本発明の第２の実施形態に係わるアクセス認可装置１０１の機能ブロックを含むシステム構成図である。図２のアクセス認可装置１０１における、システムを構成する３０３から３０７までの機能ブロックの各内部処理も、ブロック間のインタラクションも、第１の実施形態と同一である。
【００８１】
差分は、第１の実施形態においてアクセス承認装置１０２、利用者認証装置１０３が担っていた機能が、全てアクセス認可装置１０１内に組み込まれている点にある。すなわち、機能ブロック３０８から３２１が新規に追加されている。また、アクセス承認装置１０２、利用者認証装置１０３と通信するための第１送受信部３０１、第２送受信部３０２は含まれていない。
【００８２】
本実施形態に係るアクセス認可装置１０１が前提とするハードウェア構成は、第１の実施形態におけるアクセス認可装置１０１、アクセス承認装置１０２、利用者承認装置１０３を合わせたものとなる。
【００８３】
次に、アクセス認可装置１０１のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について図２に則して説明する。アクセス認可装置１０１は、トークン発行判定部３０３と、トークン発行部３０４と、トークン情報記憶部３０５と、トークン情報提供部３０６と、トークン無効化部３０７と、利用者識別情報発行部３０８と、利用者情報記憶部３０９と、利用者認証部３１０と、利用者情報提供部３１１と、利用者情報無効化部３１２と、開発者情報登録部３１３と、開発者情報記憶部３１４と、承認者情報登録部３１５と、機器情報登録部３１６と、承認者情報記憶部３１７と、利用情報提供部３１８と、承認情報発行部３１９と、承認情報記憶部３２０と、承認判定部３２１と、承認要求許可情報発行部３５１と、承認要求許可情報記憶部３５２と、承認要求許可情報認証部３５３、を有する。
【００８４】
続いて、第１の実施形態との差分である、本発明を構成する各部の詳細について以下に、説明する。
【００８５】
利用者識別情報発行部３０８は、利用者識別情報をアプリケーション（利用者）に対して発行する。具体的には、ＨＴＴＰサーバ上の機能として提供されるものであり、アプリケーションの開発者が（例えば、登録用Ｗｅｂページを介して）利用者情報を登録すると、利用者識別情報を生成し、これを発行する。同時に、生成した利用者識別情報を、利用者情報と共に、利用者情報記憶部３０９に記憶する。利用者識別情報は、アプリケーションの公開・配布前に発行され、開発者がアプリケーションの内部に設定しておくものである。利用者識別情報発行部３０８は、発行に必要な情報として、利用者情報だけでなく、開発者情報を要求してもよい。なお、利用者識別情報は、利用者を一意に識別可能な利用者ＩＤを含み、さらに利用者ＩＤの正当性を認証するための秘密情報を含み得る。
【００８６】
利用者情報記憶部３０９は、前記利用者識別情報、および、利用者識別情報に付随する利用者情報（すなわち、アプリケーション情報）を記憶する。利用者情報は、アクセスするリソースの識別情報、範囲情報、種別・属性情報等も含む。
【００８７】
利用者認証部３１０は、入力される利用者識別情報を、利用者識別情報記憶部３１２に記憶された情報に基づいて認証し、利用者承認結果情報を返す。例えば、利用者認証部３１０は、利用者ＩＤと、秘密情報のハッシュ値、及び、利用したハッシュ関数の情報を渡されると、利用者識別情報記憶部３０９に蓄積された秘密情報のハッシュ値を、渡されたハッシュ関数の情報に基づいて求め、一致するか否かを判定する。あるいは、ハッシュ値ではなく、メッセージと、この秘密情報を用いて付与した署名を用いて、認証を行ってもよい。さらに、利用者情報に含まれる、アクセスするリソースの識別情報、範囲情報、種別・属性情報などに基づき、入力されるリソースの諸情報が一致するか否かを、認証に用いてもよい。
【００８８】
利用者情報提供部３１１は、入力される利用者識別情報に対応する、利用者情報を返す。このとき、アクセス認可装置１０１の外部からの要求に対しては、利用者認証を伴うことを望まれるが、装置内部からの要求に対しては、利用者認証を行わずに、利用者情報を返すようにしてもよい。
【００８９】
利用者情報無効化部３１２は、発行済の利用者識別情報に対する無効化要求を取得し、利用者情報記憶部３０９内の該当利用者識別情報を削除するか、あるいは、前述した利用者情報に含まれる有効・無効を表す論理値情報を無効に設定する。なお、利用者情報の無効化要求は、トークン無効化部３０７と同様に、ネットワーク２０１を介した通信で実現されてもよく、あるいは、オフラインで実現されてもよい。例えば、機器のユーザが、コールセンターに電話をかけ、不正なアプリケーションを報告することをもって、無効化要求とみなすことも出来る。あるいは、メールベースでの報告でもよい。アクセス認可装置１０１のオペレータが、こうした無効化要求を受けて、利用者情報記憶部３０９の実体であるデータベースシステムを操作することで、利用者情報の無効化が実現されてもよい。さらに、利用者情報の無効化を、発生と同時に、該当機器に対して通知するために、トークン無効化部３０７に対して、通知するようにしてもよい。この場合、トークン無効化部３０７は、利用者情報無効化部３１２からの通知をトークンの無効化要求とみなして、トークン情報提供部３０６を介した機器への通知を行う。
【００９０】
開発者情報登録部３１３は、アプリケーションの開発者の情報を開発者情報として登録する。具体的には、ＨＴＴＰサーバ上の機能として提供されるものであり、アプリケーションの開発者が（例えば、登録用Ｗｅｂページを介して）自身の情報を登録すると、開発者ＩＤを生成し、これを発行する。同時に、生成した開発者ＩＤを、登録された開発者情報と共に、開発者情報記憶部３１４に記憶する。開発者情報は、利用者情報と共に、利用者情報提供部３１１から提供され得るものである。
【００９１】
開発者情報記憶部３１４は、開発者情報登録部３０９を介して登録された開発者情報を、生成された開発者ＩＤと共に記憶する。利用者情報提供部３１１からの要求に応じて、開発者情報を出力する。
【００９２】
承認者情報登録部３１５は、アクセス承認者からの要求に基づいて、機器のリソースへのアクセスを承認するアクセス承認者の情報を、アクセス認可装置１０１上に登録する。具体的には、前述した利用者識別情報発行部３０８や開発者情報登録部３１３と同様、ＨＴＴＰサーバ上の機能として提供されるものであり、機器の所有者が（例えば、登録用Ｗｅｂページを介して）承認者情報を登録すると、承認者識別情報を生成し、これを発行する。このとき、生成した承認者識別情報を、登録された承認者情報と共に、承認者情報記憶部３１７に記憶する。この承認者識別情報は、アクセス承認者を一意に識別可能な承認者ＩＤを含み、さらに承認者ＩＤの正当性を認証するための秘密情報（パスワード等）を含み得る。承認者識別情報は、機器の所有者が、上述した登録用Ｗｅｂページを介して入力した承認者ＩＤとパスワードを、承認者情報記憶部３１７内に既存のＩＤが存在しないことを確認した上で、承認する形式で発行してもよい。
【００９３】
機器情報登録部３１６は、アクセス承認者からの要求に基づいて、所有する機器情報を、アクセス認可装置１０１上に登録する。承認者情報登録部３１５と同様、ＨＴＴＰサーバ上の機能として提供されるものであり、アクセス承認者が（例えば、登録用Ｗｅｂページを介して）機器情報を登録し、同時に、承認者情報記憶部３１７に、承認者の所有機器情報として記憶する。このとき、アクセス承認者が、当該機器を所有しているか否かを確認する処理を行ってもよい。例えば、機器の画面にワンタイムパスワードや二次元バーコード等を表示し、これを、上述の登録用Ｗｅｂページから入力することで行ってもよい。あるいは、機器の出荷時に、秘密情報を機器の内部に埋め込むか、あるいは、別途保証書等と同じく書類として発行しておき、この秘密情報を登録ページから入力することで行ってもよい。
【００９４】
承認者情報記憶部３１７は、上記の承認者情報や、承認者が所有する機器の機器情報を記憶する。
【００９５】
利用情報提供部３１８は、アクセス承認者から、利用者識別情報と、機器識別情報とを取得し、アクセス承認者から承認を得る際に提示する利用情報を提供する。利用情報は、利用者情報、開発者情報、機器情報、および、アプリケーションがアクセスを求めているリソース情報を含み得る。利用情報提供部３１８は、提示する利用情報の構成に応じて、承認者情報記憶部３１７や利用者情報記憶部３０９から必要な情報を取得し、アクセス承認者に提供する。
【００９６】
承認情報発行部３１９は、利用情報提供部３１８が提供した利用情報に基づく、アクセス承認者の承認結果を取得し、承認情報を発行する。承認情報は、少なくとも承認が得られたことを示すアクセス可否検証コードを含み、さらに、承認されたリソースの種別情報、属性情報、あるいは、範囲情報を含み得るものである。これは、利用情報に含まれるリソースに関する情報とは異なるものである。例えば、利用情報には、アクセス可能なリソースとして、（Ａ）（Ｂ）（Ｃ）の３種類のＡＰＩが含まれているが、この承認情報には、実際にアクセスが発生したＡＰＩ（Ｂ）のみが含まれている。すなわち、利用情報に含まれるリソースに関する情報のサブセットになっている。承認情報発行部３１９は、この承認情報を承認情報記憶部３２０に記憶する。
【００９７】
承認情報記憶部３２０は、承認情報発行部３１９が発行した承認情報を記憶する。承認情報は、利用者識別情報および機器識別情報と関連づけられて記憶される。
【００９８】
承認判定部３２１は、入力される、利用者識別情報、機器識別情報、承認情報と、承認情報記憶部３２０の内容とに基づき、リソースへのアクセスに対するアクセス承認者からの承認の有無を判定する。
【００９９】
承認要求許可情報認証部３５３は、利用情報提供部３１８からの承認要求許可情報の認証要求を受け、承認要求許可情報記憶部３５２に記憶された情報に基づいて認証し、認証情報を返す。例えば、承認要求許可情報認証部３５３は、利用情報提供部３１８から、承認要求許可ＩＤと、秘密情報のハッシュ値、及び、利用したハッシュ関数の情報を渡され、承認要求許可情報記憶部３５２に蓄積された秘密情報のハッシュ値を、渡されたハッシュ関数の情報に基づいて求め、一致するか否かを判定する。一致するときは、認証は成功、一致しないときは、認証は失敗とする。なお、ハッシュ値ではなく、メッセージと、この秘密情報を用いて付与した署名を用いて、認証を行ってもよい。
【０１００】
次に、図３、図４、図１１、図１２、図１３、図１４を用いて、本実施形態に係るアクセス認可装置１０１の動作について説明する。図３は、本実施形態における承認情報を示すものである。図４は、トークン情報記憶部３０５が、本実施形態において記憶する、アプリケーション１１０が機器１０４のリソースにアクセスするために取得したトークン情報を示すものである。
【０１０１】
図１１は、本実施形態に係る利用者情報の登録処理シーケンスを示したものである。また、図１２は、本実施形態に係る承認者情報及び機器情報の登録処理シーケンスを示したものである。図１３は、本実施形態に係るトークン発行処理シーケンスを示したものである。図１４は、本実施形態に係るライセンス（トークン）の無効化処理の基本シーケンスを示したものである。
【０１０２】
なお、本実施形態も第１の実施形態と同様、機器１０４はデジタルテレビであり、アクセス対象のリソースは、テレビ内に蓄積された録画番組情報である。また、アプリケーション１１０は、この録画番組情報を利用した、録画リストの閲覧・操作を行う、録画ナビゲーション用のＷｅｂアプリケーションである。
【０１０３】
以下、まず、図１１のシーケンス図に則って、利用者識別情報発行の処理手順を説明する。
【０１０４】
まず、アプリケーション１１０の開発者が、開発者情報登録部３１３に対して、開発者情報の登録を要求する（ステップＳ２０１）。開発者情報登録部３１３は、例えば、Ｗｅｂページを介して登録情報を受け付けるＷｅｂサーバ上に配置された機能である。開発者は、このＷｅｂページを介して、開発者ＩＤや、パスワード、開発者名や連絡先等の諸情報を登録する。開発者情報登録部３１３は、登録された開発者ＩＤが、開発者情報記憶部３１４上に未登録であれば、開発者ＩＤとして承認し（ステップＳ２０２）、これに登録された開発者情報と合わせて、開発者情報記憶部３１４に記憶する（ステップＳ２０３、ステップＳ２０４）。登録後、開発者情報登録部３１３は、登録された開発者ＩＤと共に、登録が完了した旨を開発者に応答する（ステップＳ２０５）。ここで、登録申請された開発者ＩＤが、既に登録されたものであれば、再入力を促し、未登録の開発者ＩＤが入力されるまで繰り返す。この開発者ＩＤの登録処理（ステップＳ２０２）は、上述のような、開発者に一意になるＩＤの入力を求める方法以外にも、開発者情報登録部３１３が、自動で一意のＩＤを生成し、これを開発者側に通知するように構成してもよい。なお、開発者登録が必要なければ、以上の一連の処理（ステップＳ２０１からステップＳ２０５）は省略してもよい。
【０１０５】
次に、開発者は、アプリケーション１１０の開発時に、利用者識別情報発行部３０８に対して、トークンの発行に必要な利用者識別情報の発行を要求する（ステップＳ２０６）。利用者識別情報発行部３０８は、Ｗｅｂページを介して登録情報を受け付けるＷｅｂサーバ上に配置された機能であり、開発者は、このＷｅｂページを介して、利用者情報として、アプリケーション名、バージョン等のアプリケーション情報、アクセスしたいリソース情報（リソースの識別情報、種別・属性情報、範囲情報など）を登録する。利用者識別情報発行部３０８は、必要な利用者情報が全て登録されていることを確認すると、利用者識別情報を生成し（ステップＳ２０７）、生成した利用者識別情報と共に、利用者情報を、利用者情報記憶部３０９に登録する（ステップＳ２０８、ステップＳ２０９）。登録後、生成した利用者識別情報を開発者に応答する（ステップＳ２１０）。
【０１０６】
以上のシーケンスにより、アプリケーションに対して、アクセス認可装置１０１が一意にアプリケーションを識別、特定するための利用者識別情報が発行される。
【０１０７】
続いて、図１２のシーケンス図に則って、アクセス承認者、および、承認者の所有するアクセス対象となる機器情報の登録処理手順を説明する。
【０１０８】
まず、機器１０４の所有者（ユーザ）が、承認者情報登録部３１５に対して、承認者情報の登録を要求する（ステップＳ２１１）。承認者情報登録部３１５は、例えば、Ｗｅｂページを介して登録情報を受け付けるＷｅｂサーバ上に配置された機能である。承認者は、このＷｅｂページを介して、承認者ＩＤや、パスワード、承認者名や連絡先等の諸情報を登録する。承認者情報登録部３１５は、登録された承認者ＩＤが、承認者情報記憶部３１４上に未登録であれば、承認者ＩＤとして承認し（ステップＳ２１２）、これに登録された承認者情報と合わせて、承認者情報記憶部３１７に記憶する（ステップＳ２１３、ステップＳ２１４）。登録後、承認者情報登録部３１３は、登録された承認者ＩＤと共に、登録が完了した旨を承認者に応答する（ステップＳ２１５）。この承認者ＩＤの登録処理は、前述した開発者ＩＤの登録処理と同様、承認者自身にＩＤ入力を促すのではなく、自動で一意のＩＤを生成し、これを承認者側に通知するように構成してもよい。
【０１０９】
次に、承認者は、機器１０４の購入後、機器情報登録部３１６に対して、機器の登録を要求する（ステップＳ２１６）。機器情報登録部３１６は、Ｗｅｂページを介して登録情報を受け付けるＷｅｂサーバ上に配置された機能であり、承認者は、このＷｅｂページを介して、機器情報として、機器の製品名や型番、製品番号等を登録する。登録にあたり、機器情報登録部３１６は承認者に承認者ＩＤ、パスワード等の入力を要求する。ここで、機器情報登録部３１６は、承認者が機器を所有していることを確認する何らかの処理を行ってもよい（ステップＳ２１７）。たとえば、機器１０４に、アクセス認可装置１０１のＵＲＩをプリセットしておき、機器１０４をネットワーク２０１に接続すると、この機器情報が自動登録され、かつ、ＰＩＮコードや二次元バーコード等を用いて、機器とユーザ（アクセス承認者）が紐付けられるようにすることで、承認者と機器の紐付けを実現しても良い。具体的には、機器１０４が、機器内にプリセットされた（あるいはユーザによって手動入力された）アクセス認可装置１０１上の機器情報登録部３１６を指すＵＲＩに対して通信コネクションを確立する。このとき、クライアント（機器）の正当性を証明するための証明書が機器にインストールされていて、この情報を用いて、通信を暗号化するように構成してもよい。コネクションの確立を行うトリガは、ネットワーク２０１に接続されたことをもって行ってもよいし、機器１０４が、ユーザが登録処理を行うためのインタフェースを備え、このインタフェースを操作することによって行ってもよい。ここで、ユーザが機器情報登録画面にアクセスすると、機器情報登録部３１６は、例えば数桁の数字で構成されるＰＩＮコードを生成し、確立された通信コネクションを使って機器１０４に送信する。機器１０４は、このＰＩＮコードを画面上に表示する。ユーザは、表示されたＰＩＮコードを、機器情報登録画面の所定の（ＰＩＮコードを入力する）フォームに入力する。機器情報登録部３１６は、発行したＰＩＮコードと、ユーザに入力されたＰＩＮコードとの一致をもって、ユーザ（すなわちアクセス承認者）が、機器１０４を所有していることを認証する。このＰＩＮコードが、二次元バーコードであってもよく、機器側に送信されるＰＩＮコードが、文字列の画像データであってもよい。また、上述の例とは逆に、機器登録画面上に表示したＰＩＮコードを、機器１０４に入力して、上記保護された通信コネクションを介して、入力されたＰＩＮコードを送信するように構成してもよい。以上のように、機器とユーザの紐付け方法には、様々な実現方法が考えられ、機器情報登録部３１６は、これらの様々な既知の実現手段を用いて実現されてよい。
【０１１０】
以上のようにして承認者が機器を所有していることを確認できると、登録された機器情報を、承認者ＩＤに関連付けて、承認者情報記憶部３１７に記憶する（ステップＳ２１８、ステップＳ２１９）。最後に、登録完了を承認者に応答する（ステップＳ２２０）。
【０１１１】
以上のシーケンスにより、機器１０４とアクセス承認者とが結びつけられて、アクセス認可装置１０１（承認者情報記憶部３１７）に登録される。
【０１１２】
続いて、図１３のシーケンス図に則って、トークン発行処理手順を説明する。
【０１１３】
まず、アプリケーション１１０が公開・配布され、機器１０４上にダウンロードされる（ステップＳ２２１）。ここで、ユーザがリソースアクセスを伴うアプリケーション操作を行う（ステップＳ２２２）。本実施形態では、アプリケーション１１０は、録画ナビゲーション・アプリケーションであり、起動段階でリソース（録画番組リスト）へのアクセスが発生し得る。アプリケーション１１０は、リソースアクセスが発生すると（録画番組リスト取得ＡＰＩが呼び出されると）、利用情報提供部３１８に対応するＷｅｂページにリダイレクトされる（ステップＳ２２３、ステップＳ２２４）。これは、アプリケーション１１０に予めリダイレクトＵＲＩを設定しておくことで実現されてもよいし、第１の実施形態で述べたように、一旦、トークン発行部３０４にアクセスした後に、リダイレクトされるように構成してもよい。このときリダイレクトは、ＨＴＴＰ ＧＥＴレスポンスに、利用情報提供部３１８の承認画面のＵＲＩを、Ｒｅｆｅｒヘッダに指定することで実現する。特に、ここでは、リダイレクト先のＵＲＩに、利用者識別情報と、機器識別情報と、コールバックＵＲＩをクエリパラメータとして含める。コールバックＵＲＩを含めるのは、再びアプリケーション１１０の画面を表示するためである。承認者ＩＤとパスワードとを用いて利用者情報提供部３１８との間で事前にユーザ認証を行ってもよい。
【０１１４】
続いて、利用情報提供部３１８は、リクエストを受信して、引数として渡される利用者識別情報や機器識別情報を用いて、利用情報を取得する（ステップＳ２２５）。これは、図１３から割愛しているが、前述したように、承認者情報記憶部３１７や利用者情報記憶部３０９から必要な情報を取得し、アクセス承認画面として構成したうえで応答する（ステップＳ２２６）。このとき、利用者識別情報と、機器識別情報とを、アクセス承認画面に組み込み、第１の実施形態と同様、「録画ナビゲーションアプリが、デジタルテレビ内に蓄積された録画番組リストへのアクセスを求めている」ことを表示する。
【０１１５】
続いて、ユーザが、アプリケーション１１０から機器１０４へのアクセスを許可するか否かを、承認情報発行部３１９に対し、表示されたＷｅｂページのインタフェースを介して応答する（ステップＳ２２７）。承認情報発行部３１９は、応答が許諾を示すものであった場合には、その許可内容を含む承認情報を、承認情報記憶部３２０に記憶し（ステップＳ２２８、ステップＳ２２９）、レスポンスに含める（ステップＳ２３０）。このとき、アクセス承認画面からアプリケーション１１０の画面に再遷移するために、ステップＳ２２３で渡されたコールバックＵＲＩをリダイレクト先として、Ｒｅｆｅｒヘッダに指定する。前記の承認情報は、このコールバックＵＲＩのクエリパラメータとして設定されてもよい。
【０１１６】
機器１０４上のＷｅｂブラウザは、アクセス承認の応答に含まれる、このＲｅｆｅｒヘッダに従って、アプリケーション１１０の画面へリダイレクトする（ステップＳ２３１）。続いて、アプリケーション１１０は、アクセスされたＵＲＩ（コールバックＵＲＩ）のクエリとして設定された、承認情報に加え、利用者識別情報と、機器識別情報とを、トークン発行要求に含めて、アクセス認可装置１０１に送信し、トークン発行部３０４が取得する（ステップＳ２３２）。
【０１１７】
トークン発行要求を取得した、トークン発行部３０４は、機器１０４から受信した承認情報、利用者識別情報、機器識別情報を、トークン発行判定部３０３に渡す。トークン発行判定部３０３は、利用者認証部３１０に利用者識別情報を渡し（ステップＳ２３３）、利用者認証結果情報を取得する（ステップＳ２３４）。さらに、トークン発行判定部３０３は、承認情報記憶部３２０から、利用者識別情報および機器識別情報に関連づけられた承認情報を取得し、引数として渡された承認情報と照合しアクセス可否を判定する。（ステップＳ２３５、ステップＳ２３６）。トークン発行判定部３０３は、得られた利用者承認結果情報とアクセス可否の判定結果から、トークン発行可否を判定し、判定結果をトークン発行部３０４に渡す。トークン発行部３０４は、この判定結果に基づき、トークン発行「可」の場合には、トークンを含むトークン情報（図３参照）を生成し（ステップＳ２３７）、トークン情報記憶部３０５に記憶し（ステップＳ２３８）、トークン情報をアプリケーション１１０に応答する（ステップＳ２３９）。
【０１１８】
最後にアプリケーション１１０はリソースへのアクセスを行い（ステップＳ２４０）、リソースアクセス結果をユーザに表示する（ステップＳ２４１）。ここでは、アプリケーション１１０は、デジタルテレビ内に蓄積された録画番組のリストを取得し、取得した結果をユーザに提示する。なお、ステップＳ２４０におけるリソースアクセスの処理手順は、第１の実施形態と同様であり、図８に従う。
【０１１９】
最後に、図１４を用いて、トークンを無効化する処理手順について説明する。
【０１２０】
まず、利用者情報の無効化権限保持者が、利用者情報無効化要求を利用者情報無効化部３１２に対して行う（ステップＳ２４２）。この無効化権限保持者は、トークンの無効化権限保持者と同様であり、例えば、アプリケーション１１０の開発者、機器１０４の機器メーカ、あるいはアプリケーション１１０及び機器１０４のユーザ等が想定される。この無効化要求の発生についても、第１の実施形態で述べたトークンの無効化要求と発生と同様であり、不正なアプリケーションが発覚した場合に、機器メーカや一般ユーザが当該アプリケーションの排除を行う目的で行うことが代表的なユースケースとして挙げられる。
【０１２１】
利用者情報無効化部３１２は、無効化要求を受信すると、該当利用者情報の無効化を利用者情報記憶部３１７に対して要求する（ステップＳ２４３）。
【０１２２】
利用者情報記憶部３１７は、要求に基づいて該当利用者情報の無効化（削除もしくは有効フラグの更新等）を実行し（ステップＳ２４４）、処理結果を応答する（ステップＳ２４５）。このとき、続くステップＳ２４６以降に示す、発行済トークンの無効化を実行する場合には、無効化した利用者識別情報を応答に含める。
【０１２３】
続いて、利用者情報無効化部３１２は、利用者情報が無効化されたことを受けて、該当利用者に対して発行されたトークンの無効化を、トークン無効化部３０７に対して要求する（ステップＳ２４６）。以降の処理は、第１の実施形態のトークン無効化シーケンスと同様であり（ステップＳ２４７、ステップＳ２４８）、機器１０４に対して無効化通知を行ってもよい。
【０１２４】
以上のように、本実施形態によれば、第１の実施形態のようにアクセス承認装置、利用者認証装置などのインターネット上の外部装置を利用せずに、アクセス認可装置単体で、第三者（アプリケーション１１０、あるいは、その開発者）がリソースの管理実体（機器１０４、すなわちデジタルテレビ、および、その所有者であるユーザ）と直接信頼関係を構築できないケースにおいても、第三者に対してリソースへのアクセス権限を委譲可能とし、かつ、ユーザ以外のリソース管理実体の管理者（例えば、機器メーカ）が、第三者による不正なリソースへのアクセスを防ぐことが可能となっている」。
【０１２５】
また、第１の実施形態との差分として、ユーザや機器メーカなどの権限保持者が、利用者識別情報を無効化することによって、当該利用者（アプリケーション）に係るトークンを一括で無効化し、リソースの不正利用を効率的に防ぐことが可能となっている。
【０１２６】
＜利用者認証のバリエーション＞
最後に、第１の実施形態と同様、利用者認証を、ユーザ（アクセス承認者）から承認を得る前に行ってもよい。この場合、図１３のトークン発行処理シーケンスのステップＳ２２５の時点で、ステップＳ２３３、Ｓ２３４の利用者認証を行う。このためには、第１の実施形態と同様、承認要求許可情報発行部３５１、記憶部３５２、認証部３５３が必要になる。利用者認証が既に済んでいることを証明するための承認要求許可情報が、利用情報提供部３１８へ渡され、アクセス承認前にチェックされる。
【符号の説明】
【０１２７】
１０１ アクセス認可装置
１０２ アクセス承認装置
１０３ 利用者認証装置
１０４ 機器
１０５ 操作機器
１１０ アプリケーション
２０１ ネットワーク（インターネット、ＮＧＮ）
２０２ ネットワーク（ホームネットワーク）
３０１ 第１送受信部
３０２ 第２送受信部
３０３ トークン発行判定部
３０４ トークン発行部
３０５ トークン情報記憶部
３０６ トークン情報提供部
３０７ トークン無効化部
３０８ 利用者識別情報発行部
３０９ 利用者情報記憶部
３１０ 利用者認証部
３１１ 利用者情報提供部
３１２ 利用者情報無効化部
３１３ 開発者情報登録部
３１４ 開発者情報記憶部
３１５ 承認者情報登録部
３１６ 機器情報登録部
３１７ 承認者情報記憶部
３１８ 利用情報提供部
３１９ 承認情報発行部
３２０ 承認情報記憶部
３２１ 承認判定部
３５１ 承認要求許可情報発行部
３５２ 承認要求許可情報記憶部
３５３ 承認要求許可情報認証部
【技術分野】
【０００１】
本発明の実施形態は、アクセス認可装置に関する。
【背景技術】
【０００２】
あるインターネット上のサービスが、そのサービスの利用者の個人情報を含む、様々なサービスに係る情報や機能（以下、リソースと呼ぶ）を、当該サービスとユーザ以外の第三者（サードパーティ製のアプリケーション等）に利用させる際に、リソースにアクセスするための認証用情報（ユーザＩＤ（承認者ＩＤ）、パスワード等）を、サービスに公開せずに、アクセス権限のみを移譲する技術として非特許文献１がある。
【０００３】
非特許文献１は、リソースに対するアクセス権限移譲に際し、認証用情報をサービスに公開しないで済む、というメリットの他に、ユーザだけでなく、サービスの管理者が、第三者による不正なリソースへのアクセスを防ぐことができるというメリットがある。
【０００４】
非特許文献１は、主としてリソースの管理実体（上述のインターネット上のサービス）と第三者との間に、事前に直接信頼関係（契約関係）が構築できていることを前提としている。このため、リソースの管理実体の数が膨大かつ遍在しているなど、サービスが直接関係を構築できない場合（例えば、リソースの管理実体として家電機器を想定する場合など）には、非特許文献１は利用できない。したがって、ユーザ以外の、リソース管理実体の管理者が、第三者による不正なリソースへアクセスを防ぐことができない。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】E.Hammer-Lahav,Ed., D.Recordon, D.Hardt “The OAuth 2.0 Protocol”, Network Working Group, IETF, June 15, 2010
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述したように、従来技術は、リソースの管理実体の数が膨大かつ遍在しているなど、第三者がリソースの管理実体と直接信頼関係を構築できないケースにおいて、第三者に対してリソースへのアクセス権限を移譲できないという問題があった。さらに、ユーザ以外のリソース管理実体の管理者が、第三者による不正なリソースへのアクセスを防ぐことが出来ないという問題があった。
【０００７】
本発明は、上記従来技術の問題点を解決するためになされたものであって、第三者がリソースの管理実体と直接信頼関係を構築できないケースにおいても、第三者に対してリソースへのアクセス権限を委譲でき、かつ、ユーザ以外のリソース管理実体の管理者が、第三者による不正なリソースへのアクセスを防ぐことが可能なアクセス認可装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の実施形態としてのアクセス認可装置は、第1アプリケーションによって利用されるリソースを有する機器、およびアクセス承認装置とそれぞれネットワークを介して接続される。前記アクセス認可装置は、受信部と、第1送受信部と、トークン発行部と、送信部とを備える。
【０００９】
前記受信部は、前記機器における前記リソースへのアクセスをアクセス承認者から承認されたことを示す第1承認情報を、前記第1アプリケーションから前記ネットワークを介して受信する。
【００１０】
前記第1送受信部は、前記第1承認情報を含むアクセス承認要求を前記アクセス承認装置に送信し、前記第1アプリケーションによる前記リソースへのアクセスを許可するかを示すアクセス可否情報を前記アクセス承認装置から受信する。
【００１１】
前記トークン発行部は、前記アクセス可否情報が前記リソースへのアクセス許可を示すとき、前記リソースへのアクセス権限を前記第1アプリケーションに与えるトークン情報を発行する。
【００１２】
前記送信部は、前記トークン発行部により発行された前記トークン情報を前記第1アプリケーションに送信する。
【図面の簡単な説明】
【００１３】
【図１】本発明の第１の実施形態に係わるシステムの構成を示すブロック図。
【図２】本発明の第２の実施形態に係わるシステムの構成を示すブロック図。
【図３】承認情報のデータ構造の一例を示す図。
【図４】トークン情報のデータ構造の一例を示す図。
【図５】本発明の第１の実施形態に係わるシステムのネットワーク構成のバリエーションを示す図（１）。
【図６】本発明の第１の実施形態に係わるシステムのネットワーク構成のバリエーションを示す図（２）。
【図７】本発明の第１の実施形態におけるトークン発行処理に係わる通信シーケンス図（１）。
【図８】本発明の第１の実施形態におけるアクセス制御に係わる通信シーケンス図。
【図９】本発明の第１の実施形態におけるトークン無効化に係わる通信シーケンス図。
【図１０】本発明の第１の実施形態におけるトークン発行処理の動作を示すフローチャート。
【図１１】本発明の第２の実施形態における開発者・利用者登録に係わる通信シーケンス図。
【図１２】本発明の第２の実施形態における承認者・機器登録に係わる通信シーケンス図。
【図１３】本発明の第２の実施形態におけるトークン発行に係わる通信シーケンス図。
【図１４】本発明の第２の実施形態における利用者情報無効化に係わる通信シーケンス図。
【図１５】本発明の第１の実施形態におけるトークン発行処理に係わる通信シーケンス図（２）。
【発明を実施するための形態】
【００１４】
（第１の実施形態）
図１は、本発明の第１の実施形態に係わるアクセス認可装置の機能ブロックを示すシステム構成図である。第１の実施形態に係るシステムは、アクセス認可装置１０１と、アクセス承認装置１０２と、利用者認証装置１０３と、機器１０４と、アプリケーション（第1アプリケーション）１１０とで構成される。アクセス認可装置１０１、利用者承認装置１０２、利用者認証装置１０３、機器１０４は、ネットワーク２０１を介して接続されている。
【００１５】
次に、本実施の形態に係るアクセス認可装置１０１のハードウェア構成について説明する。本実施の形態のアクセス認可装置１０１は、装置全体を制御するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等の制御部と、各種データや各種プログラムを記憶するＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の主記憶部と、ＧＵＩ情報等の各種データや各種プログラムを記憶するＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の補助記憶部と、これらを接続するバスとを備えており、通常のコンピュータを利用したハードウェア構成となっている。また、アクセス認可装置１０１には、外部装置（１０２〜１０４）との通信を制御する無線または有線の通信Ｉ／Ｆ（ｉｎｔｅｒｆａｃｅ）が設けられている。各外部装置との通信は、ネットワーク２０１を介して行う。少なくとも、アクセス認可装置１０１は、ネットワーク２０１を介して、アクセス承認装置１０２、利用者認証装置１０３、機器１０４、機器１０４に搭載のアプリケーション（利用者）との間で情報を送受信する手段を有する。アクセス認可装置１０１は、例えば、インターネット上に存在するサーバ装置として実現される。本実施形態において、アクセス認可装置１０１は、インターネット上のサーバ装置であるとする。
【００１６】
なお、アクセス承認装置１０２と利用者認証装置１０３のハードウェア構成は、アクセス認可装置１０１と同様である。本実施形態においては、アクセス認可装置１０１と同じく、インターネット上に存在するサーバ装置であるとする。
【００１７】
次に、機器１０４のハードウェア構成について説明する。本実施の形態の機器１０４は、アクセス認可装置１０１と同様、通常のコンピュータを利用したハードウェア構成となっている。アクセス認可装置１０１との差分は、ユーザが、アプリケーション１１０による機器の内部リソースへのアクセスを承認するため、液晶ディスプレイ等のＧＵＩ表示部と、ユーザの指示入力を受け付けるキーボードやマウスやリモートコントローラ（リモコン）等の操作入力部を備えている点にある。アクセス認可装置１０１と同様、通信Ｉ／Ｆを備え、ネットワーク２０１を介して、アクセス認可装置１０１との間で情報を送受信する手段を有する。機器１０４は、例えば、パーソナルコンピュータ、デジタルテレビ、ハードディスクレコーダ、あるいは、スレートＰＣ やスマートフォン等のモバイルデバイスとして実現される。本実施形態において、機器１０４は、デジタルテレビであるとする。さらに、この機器１０４がアプリケーション１１０に対して提供するリソースは、テレビに内蔵されたハードディスクに蓄積されたデジタル地上波放送の録画番組リストであるとする。
【００１８】
ネットワーク２０１は、例えば、インターネット、または、品質保証された閉域網であるＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）などである。本実施形態において、ネットワーク２０１は、インターネットであるとする。
【００１９】
アプリケーション１１０は、図示しないサーバまたはCD-ROM等の記録媒体から機器１０４上にダウンロードされるソフトウェアである。これは、機器１０４のハードウェア（プロセッサ）がそのまま実行可能なバイナリ形式で配布されインストールされるネイティブアプリケーションであってもよく、Ｊａｖａ（登録商標）のように、ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）上で実行されるプログラム言語で記述され、ＶＭ経由で機器１０４上のプロセッサから実行される非ネイティブなアプリケーションであってもよい。後者において、さらに、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｕｎｇｕａｇｅ）、ＣＳＳ（Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔ）、ＪａｖａＳｃｒｉｐｔで記述された、いわゆるＷｅｂページと同等のＷｅｂアプリケーションであってもよい。Ｗｅｂアプリケーションの場合、機器１０４内部のローカルＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）サーバ上に配置されていてもよく、宅内ネットワークに配置されたプライベートサーバとして宅内のＬＡＮ上に設置されていてもよく、インターネット上のサービスを実現する外部サーバ上に配置されていてもよい。本実施形態では、ローカルＨＴＴＰサーバ上に配置されたＷｅｂアプリケーションであるとする。すなわち、アプリケーション１１０は、機器１０４（デジタルテレビ）上に搭載されたＷｅｂブラウザ上（あるいは、Ｗｅｂｋｉｔ等のＷｅｂブラウザを実現するミドルウェア上）で動作するＷｅｂコンテンツであるとする。
【００２０】
次に、上述したハードウェア構成において、アクセス認可装置１０１のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について図１に則して説明する。アクセス認可装置１０１は、第１送受信部３０１と、第２送受信部３０２と、トークン発行判定部３０３と、トークン発行部３０４と、トークン情報記憶部３０５と、トークン情報提供部３０６と、トークン無効化部３０７と、承認要求許可情報発行部３５１と、承認要求許可情報記憶部３５２と、承認要求許可情報認証部３５３とを有する。
【００２１】
このうち、第１送受信部３０１、第２送受信部３０２、トークン発行判定部３０３、トークン発行部３０４、トークン情報提供部３０６、トークン無効化部３０７、承認要求許可情報発行部３５１及び承認許可情報認証部３５３は、ＣＰＵのプログラム実行時にＲＡＭなどの主記憶部上に展開されるコードの実行により実現されるものである。
【００２２】
また、トークン情報記憶部３０５と承認許可情報記憶部３５２は、例えば、主記憶もしくは補助記憶部に構築されるデータベース管理システムである。これは、リレーショナルデータベースであってもよいし、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）データベースであってもよい。また、これは単一のデータベース管理システムで構築されている必要はなく、複数のデータベース管理システム、例えば、ＳＱＬｉｔｅ３、Ｏｒａｃｌｅ、ＭｙＳＱＬなどを併用しても良い。また、１つの物理的な記憶部上に構築されるようにしてもよいし、ＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）や、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）といった複数の物理的な補助記憶部で構成されるデータベース管理システムとしてもよい。また、データの格納領域が不揮発であっても揮発であってもよい。あるいは、各記憶部に各々記憶されるデータの単位情報（エントリ）を取得できる手段を備えていれば、ＣＰＵのプログラム実行時に主記憶上に生成されるリスト構造ベースの簡易なデータ管理モジュールであってもよいし、ＣＳＶ形式ファイルの管理モジュールであってもよいし、Ｋｅｙ／Ｖａｌｕｅストアで構成されていてもよい。
【００２３】
続いて、以下に本実施形態を構成する各部の詳細について説明する。
【００２４】
第１送受信部３０１はアクセス承認装置１０２とデータ通信を行う。第1送受信部３０１はアクセス承認装置１０２に対して、アプリケーション１１０を識別する利用者識別情報と、機器１０４を識別する機器識別情報と、アプリケーション１１０が、機器１０４のリソースへのアクセスに対して該当するアクセス承認者から承認を得たことを示す承認情報（第1承認情報）と、を送信し、機器１０４のリソースに対するアプリケーション１１０によるアクセスの可否を表したアクセス可否情報を受信する。この送受信処理は、ネットワーク２０１上で行われ、例えば、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）通信で実現される。このとき、一般的には、第１送受信部３０１が、ＨＴＴＰクライアントとなり、アクセス承認装置１０２がＨＴＴＰサーバとなる。但し、実現形態としては、この限りではなく、アクセス承認装置１０２から第１送受信部３０１に対して通信コネクションを確立する構成も考えられる。この場合、逆に第１送受信部３０１が、ＨＴＴＰサーバとしてふるまうことになる。このネットワーク２０１を介した通信は、ＨＴＴＰに限定されるものではなく、上述のデータが送受信しできる限りに置いては、既存の他の通信プロトコルを用いてもよいし、独自の通信プロトコルを設計して用いてもよい。この前提は、本発明に係るネットワーク２０１を介した通信全てに当てはまる。以下、第１送受信部３０１が、送受する各情報について解説する。
【００２５】
まず、利用者識別情報は、利用者認証装置１０３が、アプリケーション（利用者）１１０に対して発行する情報である。利用者識別情報は、アプリケーション１１０を一意に識別する。アプリケーション１１０の開発者は、アプリケーション１１０の公開・配布前に、利用者認証装置１０３から利用者識別情報の発行を受け、アプリケーション１１０の内部に設定しておく。これは、例えば、利用者認証装置１０３が、アプリケーション登録用のＷｅｂページを用意しておき、前記開発者が、このＷｅｂページの登録フォーマットに必要事項を入力、申請することで発行されるようにしてもよい。あるいは、利用者識別情報の発行を電子メールベースで要求してもよい。アプリケーション１１０が公開・配布される前に、アプリケーションの内部に設定される限りに置いては、どのような発行形態を採っても構わない。利用者識別情報は、利用者認証装置１０３内で、利用者を一意に識別可能な利用者ＩＤを含み、さらに利用者ＩＤの正当性を認証するための秘密情報を含み得る。
【００２６】
機器識別情報は、機器１０４を一意に識別できる情報である。具体的には、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）、製品型名と製造番号との組み合わせ等が考えられる。機器識別情報の形式は、アクセス認可装置１０１や、アクセス承認装置１０２において、機器が一意に識別可能であれば、どのような形式であっても構わない。
【００２７】
承認情報（第1承認情報）は、アクセス承認装置１０２が、アプリケーション１１０に対して発行する情報であり、アプリケーション１１０が、機器１０４のリソースに対するアクセスを、アクセス承認者（例えば、機器１０４の所有者、機器１０４を開発した機器メーカなど）から承認されていることを示す情報である。承認情報は、少なくとも承認が得られたことを示すアクセス可否検証コードを含み、さらに、このアクセス可否検証コードの正当性を証明するための秘密情報、承認された機器１０４のリソースの種別情報、属性情報、あるいは、範囲情報を含み得るものである。承認情報の具体的な構成例を、図３に示す。
【００２８】
アクセス承認装置１０２から返されるアクセス可否情報は、前記承認情報が正しいか否か、すなわち、アクセスが承認されているか否かを表す論理値である。
【００２９】
第２送受信部３０２は、利用者認証装置１０３とデータ通信を行う。第２送受信部３０２は利用者識別情報を、利用者認証装置１０３に対して送信し、利用者認証結果情報を受信する。この利用者認証結果情報は、少なくとも、利用者認証装置１０３内で実行される利用者認証（すなわち利用者識別情報に係るアプリケーションが正当なものである（事前に登録されている）かの認証）が成功したか否かを表す論理値を含む。第２送受信部３０２は、利用者認証装置１０３と、ネットワーク２０１を介して通信する。この通信は、一般的には、ＨＴＴＰ通信によって実現されることが想定されるが、第１送受信部３０１の説明で述べたとおり、これに限られない。
【００３０】
トークン発行判定部３０３は、第１送受信部３０１がアクセス承認装置１０２から受信したアクセス可否情報と、第２送受信部３０１が利用者認証装置１０３から受信した利用者認証結果情報とに基づき、トークンの発行可否を判定する。アクセス可否情報が「可」で、利用者認証結果情報が「成功」を示すものであれば、トークンの発行を許可し、これ以外の場合は、トークンの発行を許可しない。
【００３１】
トークン発行部３０４は、アプリケーション１１０から、利用者識別情報と、機器識別情報と、承認情報を取得する。トークン発行部３０４は受信部（図示しない）によりこれらの情報をアプリケーションから受信する。トークン発行部３０４は、取得したこれらの情報を、前記トークン発行判定部３０３に渡し、トークンの発行可否の判定を要求する。トークン発行部３０４は、トークン発行判定部３０３から、発行「可」の判定結果を取得すると、トークンを含むトークン情報を生成し、アプリケーション１１０に送信部（図示しない）からトークン情報を送信する。逆に、発行「否」の判定結果を取得すると、トークン発行エラーメッセージを生成し、アプリケーション１１０に送信部（図示しない）からトークン発行エラーメッセージ送信する。生成したトークン情報は、後述するトークン情報記憶部３０５に登録する。このトークン発行に係る、アプリケーション１１０（が動作する機器１０４）とトークン発行部３０４との間の通信も、ネットワーク２０１を介して行われる。一般的には、ＨＴＴＰ通信によって実現されることが想定されるが、第１送受信部３０１の説明で述べたとおり、この限りではない。上記受信部、送信部（図示しない）はトークン発行部等と同様にＣＰＵのプログラム実行時にＲＡＭなどの主記憶部上に展開されるコードの実行により実現されてもよい。
【００３２】
ここでトークンは、トークン情報の識別子であり、たとえば固定長のビット列として実現されることができる。トークンは、アクセス認可装置１０１内で、「特定のアプリケーションからの、特定リソースへのアクセス」を特定できる限りは、どのようなフォーマットであってもよい。
【００３３】
トークン情報は、少なくともトークンを含み、さらに、利用者識別情報、機器識別情報、承認情報、アプリケーション１１０に関する情報である利用者情報、機器１０４に関する情報である機器情報、トークンの有効期限情報、および、トークンが有効か否かを示す論理値情報を含み得る。ここで、利用者情報は、前述した利用者識別情報の発行時に、アプリケーション１１０の開発者が利用者認証装置１０３に登録するアプリケーションの諸情報（アプリケーション名、アプリケーションの概要情報、開発日時、バージョン、開発者情報へのポインタなど）や、開発者情報（開発者名、開発会社名、連絡先など）を含む。また、機器情報は、機器の製品名、型番、製造番号、公開するリソース情報などを含み得るものである。トークン情報の具体的な構成例を、図４に示す。
【００３４】
トークン情報記憶部３０５は、トークン発行部３０４が生成したトークン情報を記憶する。
【００３５】
トークン情報提供部３０６は、機器１０４からトークン取得要求を取得し、該当するトークン情報を、トークン情報記憶部３０５から機器１０４に提供する。トークン取得要求は、特定のトークンに対するトークン情報を要求するものであってもよく、特定の機器に対する全てのトークン情報を要求するものであってもよく、特定のアプリケーションに対する全てのトークン情報を要求するものであってもよい。あるいは、トークン情報記憶部３０５に蓄積された、全ての有効なトークン情報を要求するものであってもよく、逆に、全ての無効なトークン情報を要求するものであってもよい。なお、トークン取得要求に係る通信も、ネットワーク２０１を介して行われる。一般的には、ＨＴＴＰ通信によって実現されることが想定される。この場合、トークン情報提供部３０６は、ＨＴＴＰサーバとして機能する。使用される通信プロトコルは、ＨＴＴＰに限定されるものではない。第１送受信部３０１の説明で述べたとおり、この限りではない。さらに、トークン情報提供部３０６は、トークンが無効化されたり、内容が更新されたりした場合に、この変更を、該当する機器に対して通知してもよい。この場合、トークン情報提供部３０６は、機器との間に、予め通信チャネルを確立・維持しておき、この通信チャネルを使って、変更が発生すると同時に、その内容を通知するようにしてもよい。これは、Ｃｏｍｅｔ等のＨＴＴＰロングポーリングを用いることで実現してもよく、あるいは、ＨＴＴＰ通信を用いて、双方向通信用のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを構築するＷｅｂＳｏｃｋｅｔを用いて実現してもよい。その他、サーバ側からＰｕｓｈ型の非同期通知を実現する枠組みであれば、どのような技術を用いても構わない。
【００３６】
トークン無効化部３０７は、発行済のトークンに対する無効化要求を取得し、当該トークンの無効化として、トークン情報記憶部３０５の該当トークンを含むトークン情報を削除するか、あるいは、前述したトークン情報に含まれる有効・無効を表す論理値情報を無効に設定する。さらに、トークンの無効化を、発生と同時に、該当機器に対して通知するために、トークン情報提供部３０６に対して、トークン情報を渡し、無効化の通知を依頼する。なお、無効化要求は、ネットワーク２０１を介した通信で実現されてもよく、あるいは、オフラインで実現されてもよい。例えば、機器のユーザが、コールセンターに電話をかけ、不正なアプリケーションを報告することをもって、無効化要求とみなすことも出来る。あるいは、メールベースでの報告でもよい。アクセス認可装置１０１のオペレータが、こうした無効化要求を受けて、トークン情報記憶部３０５の実体であるデータベースシステムを操作することで、トークンの無効化が実現されてもよい。
【００３７】
承認要求許可情報発行部３５１は、利用者認証結果情報に基づき、承認情報を取得するために必要となる承認要求許可情報を発行する。この承認要求許可情報は、以下に説明する承認要求許可情報記憶部３５２にて一意に識別可能な承認要求許可ＩＤを含み、さらに、このＩＤの正当性を認証するための秘密情報を含み得る。
【００３８】
承認要求許可情報記憶部３５２は、承認要求許可情報発行部３５１が発行した承認要求許可情報を記憶する。この認証要求許可情報記憶部３５２は、実現形態としては、トークン情報記憶部３０５と統合された形で実現されてもよい。
【００３９】
承認要求許可情報認証部３５３は、アクセス承認装置１０２からの承認要求許可情報の認証要求を受け、承認要求許可情報記憶部３５２に記憶された情報に基づいて認証し、認証情報を返す。例えば、承認要求許可情報認証部３５３は、アクセス承認装置１０２から、承認要求許可ＩＤと、秘密情報のハッシュ値、及び、利用したハッシュ関数の情報を渡され、承認要求許可情報記憶部３５２に蓄積された秘密情報のハッシュ値を、渡されたハッシュ関数の情報に基づいて求め、一致するか否かを判定する。あるいは、ハッシュ値ではなく、メッセージと、この秘密情報を用いて付与した署名を用いて、認証を行ってもよい。
【００４０】
次に、図３、図４、図７、図８、図９、図１０を用いて、本実施形態に係るアクセス認可装置３３０１の動作について説明する。図３は、本実施形態におけるアクセス承認装置１０２が発行する承認情報を示すものである。図４は、トークン情報記憶部３０５が、本実施形態において記憶する、アプリケーション１１０が機器１０４のリソースにアクセスするために取得したトークン情報を示すものである。
【００４１】
図７は、本実施形態に係るトークン発行処理の基本シーケンスを示したものである。また、図８は、本実施形態に係るアクセス制御処理の基本シーケンスを示したものである。図９は、本実施形態に係るトークン無効化処理の基本シーケンスを示したものである。図１０は、アクセス認可装置１０１の、トークン発行処理を示すフローチャートである。
【００４２】
なお、本実施形態では、機器１０４はデジタルテレビであり、アクセス対象のリソースは、テレビ内に蓄積された録画番組情報である。また、アプリケーション１１０は、この録画番組情報を利用した、録画リストの閲覧・操作を行う、録画ナビゲーションアプリである。
【００４３】
以下、まず図７のシーケンス図に基づいて、利用者識別情報の発行、トークンの発行から、発行されたトークンに基づくリソースアクセスに至る処理手順を説明する。
【００４４】
まず、前提として、ユーザが、アクセス承認装置１０２に対して、自身が機器１０４（デジタルテレビ）のアクセス承認者であることを登録する（ステップＳ１０１）。このステップは、アクセス承認者としてのユーザ登録を行ない（この際ユーザＩＤ、パスワード等の登録も行う）、その後、所有する機器情報の登録を適宜行うなどの段階的な実施が考えられる。具体的には、アクセス承認装置１０２が、アクセス承認者の登録、および、アクセス承認者が所有する機器の登録を行うためのＷｅｂページを用意することで実現してもよい。あるいは、機器１０４に、アクセス承認装置１０２のＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）をプリセットしておき、機器１０４をネットワーク２０１に接続すると、この機器情報が自動登録され、かつ、ＰＩＮコードや二次元バーコード等を用いて、機器とユーザ（アクセス承認者）が紐付けられるようにすることで、それぞれの登録を実現してもよい。いずれにしても、本実施形態においては、アクセス承認装置１０２は外部装置であるため、この実施形態は問わない。
【００４５】
次に、利用者認証装置１０２が、利用者識別情報をアプリケーション１１０（録画ナビゲーションアプリ）に対して発行する（ステップＳ１０２）。このステップは、前述したように、アプリケーション１１０の開発者が、録画アプリの公開・配布前に、アプリケーションの内部にプリセットしておく実現形態が考えられる。しかし、このステップも、利用者認証装置１０３が外部装置であるため、実施形態は問わない。この後、アプリケーション１１０が公開・配布され、機器１０４上にダウンロードされる（ステップＳ１０３）。
【００４６】
ここで、ユーザがリソースアクセスを伴うアプリケーション操作を行う（ステップＳ１０４）。本実施形態では、アプリケーション１１０は、録画ナビゲーションアプリなので、起動段階で、リソース（録画番組リスト）へのアクセスが発生し得る。アプリケーション１１０は、リソースアクセスが発生すると（具体的には、機器１０４がアプリケーションに対して公開している録画番組リスト取得ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）が呼び出されると）、アクセス認可装置１０１に対して、アクセス承認要求を送信する（ステップＳ１０５）。このとき、後段のステップＳ１０８からＳ１０９まで、アクセス承認装置１０２にリダイレクトされるため、再びアプリケーション１１０の画面を表示するため、このアクセス承認要求に対して、コールバックＵＲＩを指定する。さらに、アクセス承認に必要な情報として、利用者識別情報と、機器識別情報とをパラメータとして含める。なお、本実施形態において、このステップは、ＨＴＴＰ ＧＥＴリクエストで実現される。
【００４７】
続いて、アクセス認可装置１０１は、アクセス承認要求を受信して、アクセス承認装置１０２へ、リクエストをリダイレクトする（ステップＳ１０６、Ｓ１０７）。本実施形態では、ＨＴＴＰ ＧＥＴレスポンスに、アクセス承認装置１０２の承認画面のＵＲＩを、Ｒｅｆｅｒヘッダに指定することで実現する。このとき、リダイレクト先のＵＲＬに、ステップＳ１０５で指定した利用者識別情報と、機器識別情報と、コールバックＵＲＩをクエリパラメータとして含める。
【００４８】
ここで、リダイレクトによって、ユーザの操作対象が、機器１０４上のアプリケーション１１０から、同じく機器１０４上のＷｅｂブラウザによるＷｅｂページアクセスに切り替わる。Ｗｅｂブラウザは、Ｒｅｆｅｒヘッダに従って、利用者識別情報と、機器識別情報と、コールバックＵＲＩを伴って、アクセス承認画面を要求する（ステップＳ１０８）。当該要求にユーザＩＤおよびパスワード等を含めてもよい。
【００４９】
アクセス承認装置１０２は、応答としてアクセス承認画面を返す（ステップＳ１０９）。このとき、利用者識別情報と、機器識別情報とを、承認画面に組み込み、ユーザが「何というアプリが、どのリソースにアクセスしようとしているか」を認識出来るようにする。本実施形態においては、「録画ナビゲーションアプリが、デジタルテレビ内に蓄積された録画番組リストへのアクセスを求めている」ことを表示する。
【００５０】
続いて、ユーザが、アプリケーション１１０から機器１０４へのアクセスを許可するか否かを、アクセス承認装置１０２対し、表示されたＷｅｂページのインタフェースを介して応答する（ステップＳ１１０）。アクセス承認装置１０２は、応答が許諾を示すものであった場合には、その許可内容を含む承認情報（図３参照）を発行し、レスポンスに含める（ステップＳ１１１）。このとき、アクセス承認画面からアプリケーション１１０の画面に再遷移するために、ステップＳ１０８で渡されたコールバックＵＲＩをリダイレクト先として、Ｒｅｆｅｒヘッダに指定する。前記の承認情報は、このコールバックＵＲＩのクエリパラメータとして設定されてもよい。アクセス承認装置１０２は、発行した承認情報を、利用者識別情報および機器識別情報の組に関連づけ記憶する。
【００５１】
Ｗｅｂブラウザは、アクセス承認の応答に含まれる、このＲｅｆｅｒヘッダに従って、アプリケーション１１０の画面へリダイレクトする（ステップＳ１１２）。
【００５２】
アプリケーション１１０は、アクセスされたＵＲＩ（コールバックＵＲＩ）のクエリとして設定された、承認情報に加え、利用者識別情報と、機器識別情報とを、トークン発行要求に含めて、アクセス認可装置１０１に送信する（ステップＳ１１３）。
【００５３】
アクセス認可装置１０１がトークン発行要求を受信すると、トークン発行部３０４は、受信した承認情報、利用者識別情報、機器識別情報を、トークン発行判定部３０３に渡す。トークン発行判定部３０３は、第２送受信部３０２を介して、利用者認証装置１０３に利用者識別情報を送信し（ステップＳ１１４）、利用者認証結果情報を受信する（ステップＳ１１５）。利用者認証装置１０３は、受信した利用者識別情報が内部に登録済みであるときは、認証成功を返し、それ以外の場合は認証失敗を返す。またトークン発行判定部３０３は、第１送受信部３０１を介して、アクセス承認装置１０２に承認情報、利用者識別情報、機器識別情報を送信し（ステップＳ１１６）、アクセス可否情報を受信する（ステップＳ１１７）。アクセス承認装置１０２では、利用者識別情報および機器識別情報の組に関連づけて記憶されている承認情報が存在し、かつそのアクセス可否検証コードが、受信した承認情報に含まれるものと同一であればアクセス可と判定する。それ以外の場合は不可と判定する。トークン発行判定部３０３は、得られたアクセス可否情報と利用者承認結果情報から、トークン発行可否を判定する。それぞれ「可」および「成功」のときはトークン発行「可」と判定し、それ以外の場合は「不可」と判定する。トークン発行判定部３０３は、判定結果をトークン発行部３０４に渡す。トークン発行部３０４は、この判定結果に基づき、トークン発行「可」の場合には、トークンを含むトークン情報を生成し（ステップＳ１１８）、生成したトークン情報をトークン情報記憶部３０５に記憶する（ステップＳ１１９）。トークン発行部３０４は、発行したトークンまたはトークン情報をアプリケーション１１０に応答する（ステップＳ１２０）。
【００５４】
以上のアクセス認可装置１０１（トークン発行判定部３０３及びトークン発行部３０４）におけるトークン発行処理のフローチャートを図１０に示す。
【００５５】
最後にアプリケーション１１０はリソースへのアクセスを行い（ステップＳ１２１）、リソースアクセス結果をユーザに表示する（ステップＳ１２２）。ここでは、アプリケーションＳ１２１は、デジタルテレビ内に蓄積された録画番組のリストを取得し、取得した結果をユーザに提示する。
【００５６】
ここで、ステップＳ１２１におけるリソースアクセスの処理手順の詳細を、図８のシーケンス図をベースに説明する。
【００５７】
まず、アプリケーション１１０は、録画番組リスト取得ＡＰＩを呼び出す（ステップＳ１２１０）。本実施形態においては、アプリケーション１１０は、機器１０４内のローカルＨＴＴＰサーバ上に配置されたＷｅｂアプリケーションであるから、このＡＰＩは、Ｗｅｂページから呼び出し可能なＪａｖａＳｃｒｉｐｔにバインディングされたプラグインとして実現されていてもよいし、同じローカルＨＴＴＰサーバ上に配置されたＷｅｂ ＡＰＩとして実現されていてもよい。これは、アプリケーションの形態によっては、バイナリ形式のネイティブライブラリのＡＰＩであってもよく、ＡＰＩの形式は問わない。このとき、アプリケーションは、ＡＰＩの引数としてトークン（および、トークンと共に発行された秘密情報）を渡す。
【００５８】
機器１０４は、ＡＰＩ呼び出しを受けて、引数として渡されるトークンに対応するトークン情報の取得要求を、アクセス認可装置１０１上のトークン情報提供部３０６に対して送信する（ステップＳ１２１１）。このとき、トークンと共に、トークンと共に発行された秘密情報、機器識別情報、および、機器の機種情報などをあわせて送信してもよい。なお、機器１０４とトークン情報提供部３０６間の通信は、暗号化されることが望ましい。例えば、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）や、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）プロトコルを用いたＨＴＴＰＳ通信を用いてもよく、ＩＰＳｅｃを用いてもよく、送受されるデータ（トークンまたはトークン情報）がネットワーク２０１上にそのまま流れない限りにおいては、独自の暗号通信を用いてもよい。
【００５９】
トークン情報提供部３０６は、トークンを受信すると、機器１０４の認証を行う（ステップＳ１２１２）。これは、当該機器へのアクセスに対してトークンが発行されたか否かをトークン情報記憶部３０５に記憶された情報を用いて検証することで行ってもよく、あるいは、当該機器の機種が、トークンの発行対象たるリソースを公開しているものか否かを検証することをもって行ってもよい。あるいは、アクセス承認装置１０２に対して、アクセス承認対象機器として登録されているか否かを問い合わせることで行ってもよい。機器認証は、トークン情報に含まれる他の情報を用いて実施してもよく、以上に挙げた具体的方法の組み合わせで実施してもよい。
【００６０】
次に、トークン情報提供部３０６は、渡されたトークンの認証を行う（ステップＳ１２１３）。これは、トークンと共に発行された秘密情報の照合をもって実施してもよく、単にトークン情報記憶部３０５から、対応するトークン情報を取得する際に、該当する有効なトークン情報があるか否かをもって実施してもよい。このトークン検証は、トークン情報に含まれる他の情報を用いて実施してもよく、以上に挙げた具体的方法の組み合わせで実施してもよい。トークン情報提供部３０６は、トークン情報記憶部３０５から、対応するトークン情報を取得し（ステップＳ１２１４、Ｓ１２１５）、これを機器１０４に対して提供する（ステップＳ１２１６）。もし、該当するトークンが存在しない場合、あるいは、機器認証（ステップＳ１２１２）とトークン認証（ステップＳ１２１３）が失敗した場合は、機器１０４に対して、エラー応答を行うか、空のトークン情報を返す。
【００６１】
機器１０４は、トークン情報を受信すると、アプリケーション１０４から渡されたトークンと、トークン情報提供部３０６から取得したトークン情報とを用いて、アクセス可否判定を行う（ステップＳ１２１７）。前述したステップＳ１２１３におけるトークン認証は、ここで（すなわち機器側で）行われてもよい。トークン情報要求に対してエラー応答を受信した場合や、空のトークン情報を受信した場合には、アクセス「否」の判定を行う。一方、応答にトークン情報が含まれていた場合には、トークン情報に含まれるアクセス可能なリソースの範囲に、ステップＳ１２１０で呼び出されたＡＰＩ（録画番組リスト取得ＡＰＩ）が含まれているかどうかを判定する。含まれていれば、アクセス可否判定を「可」とし、機器内のリソースを取得し（ステップＳ１２１８）、アプリケーション側に提供する（ステップＳ１２１９）。トークン情報に有効フラグまたは有効期限が含まれている場合は、有効フラグが「有効」であり、有効期限が徒過していないことを、アクセス可否判定の「可」の条件として、加える。より簡単な判定として、有効なトークン情報の受信をもってアクセス可と判定してもよい。
【００６２】
ここで、図９を用いて、トークンを無効化する処理手順について説明する。
【００６３】
まず、トークンの無効化権限保持者が、トークン無効化要求をトークン無効化部３０７に対して行う（ステップＳ１２３）。この無効化権限保持者は、例えば、アプリケーション１１０を開発した開発者、機器１０４の機器メーカ、アプリケーション１１０及び機器１０４のユーザ、あるいは利用者認証装置１０３等が想定される。この無効化要求の発生は、アプリケーション開発者が、アプリケーションの不具合によるコンピュータウイルス感染や、機器のリソース破壊などを防止するために行ったり、不正なアプリケーションが発覚した場合に、機器メーカや一般ユーザが当該アプリケーションの排除を行う目的で行ったり、利用者認証装置１０３が、アプリケーションに発行された利用者識別情報が失効したことを、アクセス認可装置１０１に自動通知することによって行われたりすることが考えられる。また、前述の図７のステップＳ１１４における利用者認証要求に対する応答（ステップＳ１１５）が認証失敗を示すものであった場合に、当該利用者識別情報を、トークン情報に含むトークンを失効するように、トークン発行判定部３０３が、トークン無効化部３０７に要求することで行われてもよい。
【００６４】
トークン無効化部３０６は、無効化要求を受信すると、該当トークン情報の無効化をトークン情報記憶部３０５に対して要求する（ステップＳ１２４）。
【００６５】
トークン情報記憶部３０５は、要求に基づいて該当トークンを無効化し、処理結果を応答する（ステップＳ１２５）。無効化は、たとえば当該トークンを含むトークン情報の削除、または当該トークン情報に含まれ有効フラグを「無効」にすることで行う。このとき、続くステップＳ１２７以降に示す、該当トークンの無効化通知を実行する場合には、無効化したトークン情報を応答に含める。
【００６６】
このように、トークン無効化部３０６は、トークン情報記憶部３０５に無効化要求を送り、応答を受けることで、トークンの無効化を実現する（Ｓ１２６）。トークン無効化部３０６は、トークンを無効化すると、トークン情報提供部３０６に対して、該当トークンの対象機器１０４へのトークンの無効化通知を要求する（ステップＳ１２７）。このとき、該当トークンの対象機器の情報は、ステップＳ１２５における応答に含まれるトークン情報から得られる。
【００６７】
トークン情報提供部３０６は、無効化通知要求を受けて、該当トークンが無効化された旨を通知する（ステップＳ１２８）。このとき、前述したように、機器１０４とトークン情報提供部３０６の間には既に通信チャネルが確立されていて、この無効化通知は、ＣｏｍｅｔやＷｅｂＳｏｃｋｅｔといった非同期通信技術を用いて実現される。
【００６８】
一方、機器１０４は、トークン情報提供部３０６から無効化通知を受信すると、以前にトークン情報提供部３０６から受信し、キャッシュしていた該当トークン情報を無効化する（ステップＳ１２９）。機器１０４は、機器側で、該当トークンを無効化したことをアクセス認可装置側（トークン情報提供部３０６）に応答する（ステップＳ１３０、Ｓ１３１）。
【００６９】
以上のように、本実施形態によれば、アクセス認可装置によって、第三者（アプリケーション１１０、あるいは、その開発者）がリソースの管理実体（機器１０４、すなわち、デジタルテレビ、および、その所有者であるユーザ）と直接信頼関係を構築できないケースにおいても、第三者に対してリソースへのアクセス権限を委譲可能とし、かつ、ユーザ以外のリソース管理実体の管理者（例えば、機器メーカ）が、第三者による不正なリソースへのアクセスを防ぐことが可能となっている。
【００７０】
具体的には、リソースの管理実体としてのデジタルテレビは膨大な数存在し、かつ、アプリケーションが販売・配布された後にも、製造、販売され得るため、特定のデジタルテレビに対するアクセス認可を、アプリケーション１１０に対して、事前に発行することができない。こうしたケースであっても、第１に、図７のステップＳ１０８からステップＳ１１１において、アプリケーション１１０を介さずに、ユーザが承認処理を行うことで、アクセス承認装置１０２において、ユーザのＩＤやパスワードが必要な場合であっても、これをアプリケーションに漏らさずに、承認処理を行うことができる。つまり、ユーザからアプリケーションに対して、権限を移譲することが出来ている。第２に、発行したトークンを、ユーザのみならず、機器メーカをはじめとする権限保持者が無効化し、さらに無効化情報を機器側に伝える（図９のステップＳ１２７からステップＳ１３１）、もしくは、機器側が取得することで（図８のステップＳ１２１１からステップＳ１２１６）、アプリケーションによるリソースの不正利用を防ぐことが可能となっている。
【００７１】
＜利用者認証のバリエーション＞
本実施形態のトークン発行処理シーケンスは、図７に限定されるものではない。特に利用者認証を、ユーザ（アクセス承認者）から承認を得る前に行ってもよい。
【００７２】
図１５は、トークン発行処理シーケンスのバリエーションを示したものである。このバリエーションのシーケンスでは、承認要求許可情報発行部３５１、承認要求許可情報記憶部３５２、承認要求許可情報認証部３５３を用いる。
【００７３】
本バリエーションのシーケンスでは、利用者認証を経て、初めてアクセス承認者からの承認が得られる。具体的に、図７におけるアクセス承認要求（ステップＳ１０５、Ｓ１０６）時に、利用者認証を行う（図１５のステップＳ１５６、Ｓ１５７）。ここで、利用者認証が成功した場合に、承認要求許可情報発行部３５１が、承認要求許可情報を、アプリケーション（利用者）に対して発行し、これを承認要求許可情報記憶部３５２に記憶する。ここで、承認要求許可情報は、承認要求許可情報記憶部３５２内で一意に識別可能な承認要求許可ＩＤを含み、さらにこのＩＤの正当性を証明するための秘密情報を含み得る。承認要求許可情報はアプリケーションおよびユーザへの応答に含められる（ステップＳ１５８，Ｓ１５９）
ユーザは、アクセス承認装置１０２に、認証画面を要求する際に（ステップＳ１６０）、この承認要求許可情報を渡す。アクセス承認装置１０２は、渡された承認要求許可情報を、アクセス認可装置１０１上の承認要求許可情報認証部３５３に送信する（ステップＳ１６１）。承認要求許可情報認証部３５３は、承認要求許可情報認証部３５３に記憶された該当承認要求許可情報と、受信した前記情報を照合して認証し（ステップＳ１６２）、認証結果を返す（ステップＳ１６３）。たとえば受信した情報に含まれるＩＤと同一ＩＤを含む承認要求許可情報が、承認要求許可情報記憶部３５２に記憶されていれば認証成功とし、それ以外の場合は認証失敗とする。認証が成功すれば、アクセス承認装置１０２は、承認画面をユーザ返す（ステップＳ１６４）。ここで、図７におけるトークン発行要求を受けての利用者認証（ステップＳ１１４、Ｓ１１５）は、図１５のシーケンスにおいては必要ない。
【００７４】
＜トークン発行処理のバリエーション＞
また、本実施形態で述べたトークン発行処理シーケンスは、図７に限定されるものではない。例えば、トークン発行時に、利用者（アプリケーション）の認証を行う必要がなければ、利用者認証処理（ステップＳ１１４、ステップＳ１１５）を省略してもよい。また、アクセス承認装置１０２上のアクセス承認要求先を、予めアプリケーション１１０内にプリセットしておくことで、ステップＳ１０５、ステップＳ１０６を省略することができる。また、アプリケーション１１０が、信頼できるアプリケーションである場合には、アクセス承認装置１０２の承認ページにリダイレクトせずに、直接アプリケーションを介して、ユーザのＩＤやパスワードをアクセス承認装置１０２に送信するようにしてもよい。この場合、ステップＳ１０７及びステップＳ１１２を省略し、ステップＳ１０８からステップＳ１１１までの処理を、直接アプリケーション１１０から行うように構成してもよい。
【００７５】
＜リソースアクセス制御のバリエーション＞
また、本実施形態で述べたリソースアクセス処理シーケンスは、図８に限定されるものではない。図８では、アプリケーションからのリソースアクセスが発生する都度、トークン情報提供部３０６から必要なトークン情報を取得するように構成しているが、リソースアクセスのシーケンスとは別に、定期的にトークン情報提供部３０６にアクセスし、特定の機器（機器１０４）に対する全てのトークン情報を取得したり、特定のアプリケーション（アプリケーション１１０）に対する全てのトークン情報を取得したり、あるいは、トークン情報記憶部３０５に蓄積された、全ての有効なトークン情報、あるいは、無効なトークン情報を取得したりし、取得したトークンを機器内部に蓄積し、これをアクセス判定に利用するように構成してもよい。この場合、ステップＳ１２１１からステップＳ１２１６までの処理は省略できる。また、無効化処理で説明したように、アクセス認可装置１０１（トークン情報提供部３０６）から機器１０４に対して通知する手段が採れる場合には、生成されたトークン情報を端末側にタイムリーに通知することで、同様に、ステップＳ１２１１からステップＳ１２１６までの処理を省略することができる。図７のステップＳ１０４でリソースアクセス要求を受けた際、該当する有効なトークン情報が存在するか判断し、存在するときは、ステップＳ１０５〜Ｓ１２０を実施せずに、ステップＳ１２１を実施してもよい。
【００７６】
＜ネットワーク構成のバリエーション＞
なお、図５および図６は、本実施形態で述べたアクセス認可装置を含むシステムにおけるネットワーク構成のバリエーションを示すものである。ただし、ここでは、図１５のシーケンスを行わない場合を想定し、承認要求許可情報発行部３５１、承認要求許可情報記憶部３５２、承認要求許可情報認証部３５３を図１のアクセス認可装置を省いている。図１５のシーケンスを行う場合は、これらの要素３５１〜３５３を、図５または図６のアクセス認可装置に設ければよい。
【００７７】
これまで述べてきた実施形態においては、簡単のために、ネットワーク２０１（インターネット）に全てのシステム構成要素が接続されていることを想定していたが、図５および図６の構成では、機器１０４がネットワーク２０２に接続されている。ネットワーク２０２は、例えば、有線又は無線ＬＡＮ（ＬｏｃａｌＡｒｅａ Ｎｅｔｗｏｒｋ）で構成されるホームネットワークである。ネットワーク２０１とネットワーク２０２は、ブロードバンドルータ等のＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）の終端装置で接続されており、機器１０４とアクセス認可装置１０１の間の通信は、この終端装置を経由して実現される。
【００７８】
また、図６では、アプリケーションが機器１０４ではなく、ネットワーク２０２上の別の機器（操作機器１０５）にダウンロードされている。すなわち図１または図５の構成ではアプリケーションが動作する機器は機器１０４であったが、図６の構成では、アプリケーションが動作する機器は機器１０５である。アプリケーション１１０が、アクセス対象機器１０４を発見し、その機器識別情報（および機器情報）を知る何らかの手段があれば、アプリケーション１１０と機器１０４が、ネットワーク上の別のエンティティに存在してもよい。上述の手段には、例えば、宅内機器の発見を含むプラグアンドプレイを実現する、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ Ａｎｄ Ｐｌａｙ）、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）が利用できる。周辺機器を発見し、そのリソースを認識出来る手段を備えていれば、これらの既存プロトコルに限らず、独自プロトコルを含む別の手段を用いてもよい。
【００７９】
（第２の実施形態）
次に、アクセス認可装置の第２の実施の形態について説明する。なお、第１の実施形態と多くの部分で共通するため、同一の符号を使用して説明したり、説明を省略したりする。
【００８０】
図２は、本発明の第２の実施形態に係わるアクセス認可装置１０１の機能ブロックを含むシステム構成図である。図２のアクセス認可装置１０１における、システムを構成する３０３から３０７までの機能ブロックの各内部処理も、ブロック間のインタラクションも、第１の実施形態と同一である。
【００８１】
差分は、第１の実施形態においてアクセス承認装置１０２、利用者認証装置１０３が担っていた機能が、全てアクセス認可装置１０１内に組み込まれている点にある。すなわち、機能ブロック３０８から３２１が新規に追加されている。また、アクセス承認装置１０２、利用者認証装置１０３と通信するための第１送受信部３０１、第２送受信部３０２は含まれていない。
【００８２】
本実施形態に係るアクセス認可装置１０１が前提とするハードウェア構成は、第１の実施形態におけるアクセス認可装置１０１、アクセス承認装置１０２、利用者承認装置１０３を合わせたものとなる。
【００８３】
次に、アクセス認可装置１０１のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について図２に則して説明する。アクセス認可装置１０１は、トークン発行判定部３０３と、トークン発行部３０４と、トークン情報記憶部３０５と、トークン情報提供部３０６と、トークン無効化部３０７と、利用者識別情報発行部３０８と、利用者情報記憶部３０９と、利用者認証部３１０と、利用者情報提供部３１１と、利用者情報無効化部３１２と、開発者情報登録部３１３と、開発者情報記憶部３１４と、承認者情報登録部３１５と、機器情報登録部３１６と、承認者情報記憶部３１７と、利用情報提供部３１８と、承認情報発行部３１９と、承認情報記憶部３２０と、承認判定部３２１と、承認要求許可情報発行部３５１と、承認要求許可情報記憶部３５２と、承認要求許可情報認証部３５３、を有する。
【００８４】
続いて、第１の実施形態との差分である、本発明を構成する各部の詳細について以下に、説明する。
【００８５】
利用者識別情報発行部３０８は、利用者識別情報をアプリケーション（利用者）に対して発行する。具体的には、ＨＴＴＰサーバ上の機能として提供されるものであり、アプリケーションの開発者が（例えば、登録用Ｗｅｂページを介して）利用者情報を登録すると、利用者識別情報を生成し、これを発行する。同時に、生成した利用者識別情報を、利用者情報と共に、利用者情報記憶部３０９に記憶する。利用者識別情報は、アプリケーションの公開・配布前に発行され、開発者がアプリケーションの内部に設定しておくものである。利用者識別情報発行部３０８は、発行に必要な情報として、利用者情報だけでなく、開発者情報を要求してもよい。なお、利用者識別情報は、利用者を一意に識別可能な利用者ＩＤを含み、さらに利用者ＩＤの正当性を認証するための秘密情報を含み得る。
【００８６】
利用者情報記憶部３０９は、前記利用者識別情報、および、利用者識別情報に付随する利用者情報（すなわち、アプリケーション情報）を記憶する。利用者情報は、アクセスするリソースの識別情報、範囲情報、種別・属性情報等も含む。
【００８７】
利用者認証部３１０は、入力される利用者識別情報を、利用者識別情報記憶部３１２に記憶された情報に基づいて認証し、利用者承認結果情報を返す。例えば、利用者認証部３１０は、利用者ＩＤと、秘密情報のハッシュ値、及び、利用したハッシュ関数の情報を渡されると、利用者識別情報記憶部３０９に蓄積された秘密情報のハッシュ値を、渡されたハッシュ関数の情報に基づいて求め、一致するか否かを判定する。あるいは、ハッシュ値ではなく、メッセージと、この秘密情報を用いて付与した署名を用いて、認証を行ってもよい。さらに、利用者情報に含まれる、アクセスするリソースの識別情報、範囲情報、種別・属性情報などに基づき、入力されるリソースの諸情報が一致するか否かを、認証に用いてもよい。
【００８８】
利用者情報提供部３１１は、入力される利用者識別情報に対応する、利用者情報を返す。このとき、アクセス認可装置１０１の外部からの要求に対しては、利用者認証を伴うことを望まれるが、装置内部からの要求に対しては、利用者認証を行わずに、利用者情報を返すようにしてもよい。
【００８９】
利用者情報無効化部３１２は、発行済の利用者識別情報に対する無効化要求を取得し、利用者情報記憶部３０９内の該当利用者識別情報を削除するか、あるいは、前述した利用者情報に含まれる有効・無効を表す論理値情報を無効に設定する。なお、利用者情報の無効化要求は、トークン無効化部３０７と同様に、ネットワーク２０１を介した通信で実現されてもよく、あるいは、オフラインで実現されてもよい。例えば、機器のユーザが、コールセンターに電話をかけ、不正なアプリケーションを報告することをもって、無効化要求とみなすことも出来る。あるいは、メールベースでの報告でもよい。アクセス認可装置１０１のオペレータが、こうした無効化要求を受けて、利用者情報記憶部３０９の実体であるデータベースシステムを操作することで、利用者情報の無効化が実現されてもよい。さらに、利用者情報の無効化を、発生と同時に、該当機器に対して通知するために、トークン無効化部３０７に対して、通知するようにしてもよい。この場合、トークン無効化部３０７は、利用者情報無効化部３１２からの通知をトークンの無効化要求とみなして、トークン情報提供部３０６を介した機器への通知を行う。
【００９０】
開発者情報登録部３１３は、アプリケーションの開発者の情報を開発者情報として登録する。具体的には、ＨＴＴＰサーバ上の機能として提供されるものであり、アプリケーションの開発者が（例えば、登録用Ｗｅｂページを介して）自身の情報を登録すると、開発者ＩＤを生成し、これを発行する。同時に、生成した開発者ＩＤを、登録された開発者情報と共に、開発者情報記憶部３１４に記憶する。開発者情報は、利用者情報と共に、利用者情報提供部３１１から提供され得るものである。
【００９１】
開発者情報記憶部３１４は、開発者情報登録部３０９を介して登録された開発者情報を、生成された開発者ＩＤと共に記憶する。利用者情報提供部３１１からの要求に応じて、開発者情報を出力する。
【００９２】
承認者情報登録部３１５は、アクセス承認者からの要求に基づいて、機器のリソースへのアクセスを承認するアクセス承認者の情報を、アクセス認可装置１０１上に登録する。具体的には、前述した利用者識別情報発行部３０８や開発者情報登録部３１３と同様、ＨＴＴＰサーバ上の機能として提供されるものであり、機器の所有者が（例えば、登録用Ｗｅｂページを介して）承認者情報を登録すると、承認者識別情報を生成し、これを発行する。このとき、生成した承認者識別情報を、登録された承認者情報と共に、承認者情報記憶部３１７に記憶する。この承認者識別情報は、アクセス承認者を一意に識別可能な承認者ＩＤを含み、さらに承認者ＩＤの正当性を認証するための秘密情報（パスワード等）を含み得る。承認者識別情報は、機器の所有者が、上述した登録用Ｗｅｂページを介して入力した承認者ＩＤとパスワードを、承認者情報記憶部３１７内に既存のＩＤが存在しないことを確認した上で、承認する形式で発行してもよい。
【００９３】
機器情報登録部３１６は、アクセス承認者からの要求に基づいて、所有する機器情報を、アクセス認可装置１０１上に登録する。承認者情報登録部３１５と同様、ＨＴＴＰサーバ上の機能として提供されるものであり、アクセス承認者が（例えば、登録用Ｗｅｂページを介して）機器情報を登録し、同時に、承認者情報記憶部３１７に、承認者の所有機器情報として記憶する。このとき、アクセス承認者が、当該機器を所有しているか否かを確認する処理を行ってもよい。例えば、機器の画面にワンタイムパスワードや二次元バーコード等を表示し、これを、上述の登録用Ｗｅｂページから入力することで行ってもよい。あるいは、機器の出荷時に、秘密情報を機器の内部に埋め込むか、あるいは、別途保証書等と同じく書類として発行しておき、この秘密情報を登録ページから入力することで行ってもよい。
【００９４】
承認者情報記憶部３１７は、上記の承認者情報や、承認者が所有する機器の機器情報を記憶する。
【００９５】
利用情報提供部３１８は、アクセス承認者から、利用者識別情報と、機器識別情報とを取得し、アクセス承認者から承認を得る際に提示する利用情報を提供する。利用情報は、利用者情報、開発者情報、機器情報、および、アプリケーションがアクセスを求めているリソース情報を含み得る。利用情報提供部３１８は、提示する利用情報の構成に応じて、承認者情報記憶部３１７や利用者情報記憶部３０９から必要な情報を取得し、アクセス承認者に提供する。
【００９６】
承認情報発行部３１９は、利用情報提供部３１８が提供した利用情報に基づく、アクセス承認者の承認結果を取得し、承認情報を発行する。承認情報は、少なくとも承認が得られたことを示すアクセス可否検証コードを含み、さらに、承認されたリソースの種別情報、属性情報、あるいは、範囲情報を含み得るものである。これは、利用情報に含まれるリソースに関する情報とは異なるものである。例えば、利用情報には、アクセス可能なリソースとして、（Ａ）（Ｂ）（Ｃ）の３種類のＡＰＩが含まれているが、この承認情報には、実際にアクセスが発生したＡＰＩ（Ｂ）のみが含まれている。すなわち、利用情報に含まれるリソースに関する情報のサブセットになっている。承認情報発行部３１９は、この承認情報を承認情報記憶部３２０に記憶する。
【００９７】
承認情報記憶部３２０は、承認情報発行部３１９が発行した承認情報を記憶する。承認情報は、利用者識別情報および機器識別情報と関連づけられて記憶される。
【００９８】
承認判定部３２１は、入力される、利用者識別情報、機器識別情報、承認情報と、承認情報記憶部３２０の内容とに基づき、リソースへのアクセスに対するアクセス承認者からの承認の有無を判定する。
【００９９】
承認要求許可情報認証部３５３は、利用情報提供部３１８からの承認要求許可情報の認証要求を受け、承認要求許可情報記憶部３５２に記憶された情報に基づいて認証し、認証情報を返す。例えば、承認要求許可情報認証部３５３は、利用情報提供部３１８から、承認要求許可ＩＤと、秘密情報のハッシュ値、及び、利用したハッシュ関数の情報を渡され、承認要求許可情報記憶部３５２に蓄積された秘密情報のハッシュ値を、渡されたハッシュ関数の情報に基づいて求め、一致するか否かを判定する。一致するときは、認証は成功、一致しないときは、認証は失敗とする。なお、ハッシュ値ではなく、メッセージと、この秘密情報を用いて付与した署名を用いて、認証を行ってもよい。
【０１００】
次に、図３、図４、図１１、図１２、図１３、図１４を用いて、本実施形態に係るアクセス認可装置１０１の動作について説明する。図３は、本実施形態における承認情報を示すものである。図４は、トークン情報記憶部３０５が、本実施形態において記憶する、アプリケーション１１０が機器１０４のリソースにアクセスするために取得したトークン情報を示すものである。
【０１０１】
図１１は、本実施形態に係る利用者情報の登録処理シーケンスを示したものである。また、図１２は、本実施形態に係る承認者情報及び機器情報の登録処理シーケンスを示したものである。図１３は、本実施形態に係るトークン発行処理シーケンスを示したものである。図１４は、本実施形態に係るライセンス（トークン）の無効化処理の基本シーケンスを示したものである。
【０１０２】
なお、本実施形態も第１の実施形態と同様、機器１０４はデジタルテレビであり、アクセス対象のリソースは、テレビ内に蓄積された録画番組情報である。また、アプリケーション１１０は、この録画番組情報を利用した、録画リストの閲覧・操作を行う、録画ナビゲーション用のＷｅｂアプリケーションである。
【０１０３】
以下、まず、図１１のシーケンス図に則って、利用者識別情報発行の処理手順を説明する。
【０１０４】
まず、アプリケーション１１０の開発者が、開発者情報登録部３１３に対して、開発者情報の登録を要求する（ステップＳ２０１）。開発者情報登録部３１３は、例えば、Ｗｅｂページを介して登録情報を受け付けるＷｅｂサーバ上に配置された機能である。開発者は、このＷｅｂページを介して、開発者ＩＤや、パスワード、開発者名や連絡先等の諸情報を登録する。開発者情報登録部３１３は、登録された開発者ＩＤが、開発者情報記憶部３１４上に未登録であれば、開発者ＩＤとして承認し（ステップＳ２０２）、これに登録された開発者情報と合わせて、開発者情報記憶部３１４に記憶する（ステップＳ２０３、ステップＳ２０４）。登録後、開発者情報登録部３１３は、登録された開発者ＩＤと共に、登録が完了した旨を開発者に応答する（ステップＳ２０５）。ここで、登録申請された開発者ＩＤが、既に登録されたものであれば、再入力を促し、未登録の開発者ＩＤが入力されるまで繰り返す。この開発者ＩＤの登録処理（ステップＳ２０２）は、上述のような、開発者に一意になるＩＤの入力を求める方法以外にも、開発者情報登録部３１３が、自動で一意のＩＤを生成し、これを開発者側に通知するように構成してもよい。なお、開発者登録が必要なければ、以上の一連の処理（ステップＳ２０１からステップＳ２０５）は省略してもよい。
【０１０５】
次に、開発者は、アプリケーション１１０の開発時に、利用者識別情報発行部３０８に対して、トークンの発行に必要な利用者識別情報の発行を要求する（ステップＳ２０６）。利用者識別情報発行部３０８は、Ｗｅｂページを介して登録情報を受け付けるＷｅｂサーバ上に配置された機能であり、開発者は、このＷｅｂページを介して、利用者情報として、アプリケーション名、バージョン等のアプリケーション情報、アクセスしたいリソース情報（リソースの識別情報、種別・属性情報、範囲情報など）を登録する。利用者識別情報発行部３０８は、必要な利用者情報が全て登録されていることを確認すると、利用者識別情報を生成し（ステップＳ２０７）、生成した利用者識別情報と共に、利用者情報を、利用者情報記憶部３０９に登録する（ステップＳ２０８、ステップＳ２０９）。登録後、生成した利用者識別情報を開発者に応答する（ステップＳ２１０）。
【０１０６】
以上のシーケンスにより、アプリケーションに対して、アクセス認可装置１０１が一意にアプリケーションを識別、特定するための利用者識別情報が発行される。
【０１０７】
続いて、図１２のシーケンス図に則って、アクセス承認者、および、承認者の所有するアクセス対象となる機器情報の登録処理手順を説明する。
【０１０８】
まず、機器１０４の所有者（ユーザ）が、承認者情報登録部３１５に対して、承認者情報の登録を要求する（ステップＳ２１１）。承認者情報登録部３１５は、例えば、Ｗｅｂページを介して登録情報を受け付けるＷｅｂサーバ上に配置された機能である。承認者は、このＷｅｂページを介して、承認者ＩＤや、パスワード、承認者名や連絡先等の諸情報を登録する。承認者情報登録部３１５は、登録された承認者ＩＤが、承認者情報記憶部３１４上に未登録であれば、承認者ＩＤとして承認し（ステップＳ２１２）、これに登録された承認者情報と合わせて、承認者情報記憶部３１７に記憶する（ステップＳ２１３、ステップＳ２１４）。登録後、承認者情報登録部３１３は、登録された承認者ＩＤと共に、登録が完了した旨を承認者に応答する（ステップＳ２１５）。この承認者ＩＤの登録処理は、前述した開発者ＩＤの登録処理と同様、承認者自身にＩＤ入力を促すのではなく、自動で一意のＩＤを生成し、これを承認者側に通知するように構成してもよい。
【０１０９】
次に、承認者は、機器１０４の購入後、機器情報登録部３１６に対して、機器の登録を要求する（ステップＳ２１６）。機器情報登録部３１６は、Ｗｅｂページを介して登録情報を受け付けるＷｅｂサーバ上に配置された機能であり、承認者は、このＷｅｂページを介して、機器情報として、機器の製品名や型番、製品番号等を登録する。登録にあたり、機器情報登録部３１６は承認者に承認者ＩＤ、パスワード等の入力を要求する。ここで、機器情報登録部３１６は、承認者が機器を所有していることを確認する何らかの処理を行ってもよい（ステップＳ２１７）。たとえば、機器１０４に、アクセス認可装置１０１のＵＲＩをプリセットしておき、機器１０４をネットワーク２０１に接続すると、この機器情報が自動登録され、かつ、ＰＩＮコードや二次元バーコード等を用いて、機器とユーザ（アクセス承認者）が紐付けられるようにすることで、承認者と機器の紐付けを実現しても良い。具体的には、機器１０４が、機器内にプリセットされた（あるいはユーザによって手動入力された）アクセス認可装置１０１上の機器情報登録部３１６を指すＵＲＩに対して通信コネクションを確立する。このとき、クライアント（機器）の正当性を証明するための証明書が機器にインストールされていて、この情報を用いて、通信を暗号化するように構成してもよい。コネクションの確立を行うトリガは、ネットワーク２０１に接続されたことをもって行ってもよいし、機器１０４が、ユーザが登録処理を行うためのインタフェースを備え、このインタフェースを操作することによって行ってもよい。ここで、ユーザが機器情報登録画面にアクセスすると、機器情報登録部３１６は、例えば数桁の数字で構成されるＰＩＮコードを生成し、確立された通信コネクションを使って機器１０４に送信する。機器１０４は、このＰＩＮコードを画面上に表示する。ユーザは、表示されたＰＩＮコードを、機器情報登録画面の所定の（ＰＩＮコードを入力する）フォームに入力する。機器情報登録部３１６は、発行したＰＩＮコードと、ユーザに入力されたＰＩＮコードとの一致をもって、ユーザ（すなわちアクセス承認者）が、機器１０４を所有していることを認証する。このＰＩＮコードが、二次元バーコードであってもよく、機器側に送信されるＰＩＮコードが、文字列の画像データであってもよい。また、上述の例とは逆に、機器登録画面上に表示したＰＩＮコードを、機器１０４に入力して、上記保護された通信コネクションを介して、入力されたＰＩＮコードを送信するように構成してもよい。以上のように、機器とユーザの紐付け方法には、様々な実現方法が考えられ、機器情報登録部３１６は、これらの様々な既知の実現手段を用いて実現されてよい。
【０１１０】
以上のようにして承認者が機器を所有していることを確認できると、登録された機器情報を、承認者ＩＤに関連付けて、承認者情報記憶部３１７に記憶する（ステップＳ２１８、ステップＳ２１９）。最後に、登録完了を承認者に応答する（ステップＳ２２０）。
【０１１１】
以上のシーケンスにより、機器１０４とアクセス承認者とが結びつけられて、アクセス認可装置１０１（承認者情報記憶部３１７）に登録される。
【０１１２】
続いて、図１３のシーケンス図に則って、トークン発行処理手順を説明する。
【０１１３】
まず、アプリケーション１１０が公開・配布され、機器１０４上にダウンロードされる（ステップＳ２２１）。ここで、ユーザがリソースアクセスを伴うアプリケーション操作を行う（ステップＳ２２２）。本実施形態では、アプリケーション１１０は、録画ナビゲーション・アプリケーションであり、起動段階でリソース（録画番組リスト）へのアクセスが発生し得る。アプリケーション１１０は、リソースアクセスが発生すると（録画番組リスト取得ＡＰＩが呼び出されると）、利用情報提供部３１８に対応するＷｅｂページにリダイレクトされる（ステップＳ２２３、ステップＳ２２４）。これは、アプリケーション１１０に予めリダイレクトＵＲＩを設定しておくことで実現されてもよいし、第１の実施形態で述べたように、一旦、トークン発行部３０４にアクセスした後に、リダイレクトされるように構成してもよい。このときリダイレクトは、ＨＴＴＰ ＧＥＴレスポンスに、利用情報提供部３１８の承認画面のＵＲＩを、Ｒｅｆｅｒヘッダに指定することで実現する。特に、ここでは、リダイレクト先のＵＲＩに、利用者識別情報と、機器識別情報と、コールバックＵＲＩをクエリパラメータとして含める。コールバックＵＲＩを含めるのは、再びアプリケーション１１０の画面を表示するためである。承認者ＩＤとパスワードとを用いて利用者情報提供部３１８との間で事前にユーザ認証を行ってもよい。
【０１１４】
続いて、利用情報提供部３１８は、リクエストを受信して、引数として渡される利用者識別情報や機器識別情報を用いて、利用情報を取得する（ステップＳ２２５）。これは、図１３から割愛しているが、前述したように、承認者情報記憶部３１７や利用者情報記憶部３０９から必要な情報を取得し、アクセス承認画面として構成したうえで応答する（ステップＳ２２６）。このとき、利用者識別情報と、機器識別情報とを、アクセス承認画面に組み込み、第１の実施形態と同様、「録画ナビゲーションアプリが、デジタルテレビ内に蓄積された録画番組リストへのアクセスを求めている」ことを表示する。
【０１１５】
続いて、ユーザが、アプリケーション１１０から機器１０４へのアクセスを許可するか否かを、承認情報発行部３１９に対し、表示されたＷｅｂページのインタフェースを介して応答する（ステップＳ２２７）。承認情報発行部３１９は、応答が許諾を示すものであった場合には、その許可内容を含む承認情報を、承認情報記憶部３２０に記憶し（ステップＳ２２８、ステップＳ２２９）、レスポンスに含める（ステップＳ２３０）。このとき、アクセス承認画面からアプリケーション１１０の画面に再遷移するために、ステップＳ２２３で渡されたコールバックＵＲＩをリダイレクト先として、Ｒｅｆｅｒヘッダに指定する。前記の承認情報は、このコールバックＵＲＩのクエリパラメータとして設定されてもよい。
【０１１６】
機器１０４上のＷｅｂブラウザは、アクセス承認の応答に含まれる、このＲｅｆｅｒヘッダに従って、アプリケーション１１０の画面へリダイレクトする（ステップＳ２３１）。続いて、アプリケーション１１０は、アクセスされたＵＲＩ（コールバックＵＲＩ）のクエリとして設定された、承認情報に加え、利用者識別情報と、機器識別情報とを、トークン発行要求に含めて、アクセス認可装置１０１に送信し、トークン発行部３０４が取得する（ステップＳ２３２）。
【０１１７】
トークン発行要求を取得した、トークン発行部３０４は、機器１０４から受信した承認情報、利用者識別情報、機器識別情報を、トークン発行判定部３０３に渡す。トークン発行判定部３０３は、利用者認証部３１０に利用者識別情報を渡し（ステップＳ２３３）、利用者認証結果情報を取得する（ステップＳ２３４）。さらに、トークン発行判定部３０３は、承認情報記憶部３２０から、利用者識別情報および機器識別情報に関連づけられた承認情報を取得し、引数として渡された承認情報と照合しアクセス可否を判定する。（ステップＳ２３５、ステップＳ２３６）。トークン発行判定部３０３は、得られた利用者承認結果情報とアクセス可否の判定結果から、トークン発行可否を判定し、判定結果をトークン発行部３０４に渡す。トークン発行部３０４は、この判定結果に基づき、トークン発行「可」の場合には、トークンを含むトークン情報（図３参照）を生成し（ステップＳ２３７）、トークン情報記憶部３０５に記憶し（ステップＳ２３８）、トークン情報をアプリケーション１１０に応答する（ステップＳ２３９）。
【０１１８】
最後にアプリケーション１１０はリソースへのアクセスを行い（ステップＳ２４０）、リソースアクセス結果をユーザに表示する（ステップＳ２４１）。ここでは、アプリケーション１１０は、デジタルテレビ内に蓄積された録画番組のリストを取得し、取得した結果をユーザに提示する。なお、ステップＳ２４０におけるリソースアクセスの処理手順は、第１の実施形態と同様であり、図８に従う。
【０１１９】
最後に、図１４を用いて、トークンを無効化する処理手順について説明する。
【０１２０】
まず、利用者情報の無効化権限保持者が、利用者情報無効化要求を利用者情報無効化部３１２に対して行う（ステップＳ２４２）。この無効化権限保持者は、トークンの無効化権限保持者と同様であり、例えば、アプリケーション１１０の開発者、機器１０４の機器メーカ、あるいはアプリケーション１１０及び機器１０４のユーザ等が想定される。この無効化要求の発生についても、第１の実施形態で述べたトークンの無効化要求と発生と同様であり、不正なアプリケーションが発覚した場合に、機器メーカや一般ユーザが当該アプリケーションの排除を行う目的で行うことが代表的なユースケースとして挙げられる。
【０１２１】
利用者情報無効化部３１２は、無効化要求を受信すると、該当利用者情報の無効化を利用者情報記憶部３１７に対して要求する（ステップＳ２４３）。
【０１２２】
利用者情報記憶部３１７は、要求に基づいて該当利用者情報の無効化（削除もしくは有効フラグの更新等）を実行し（ステップＳ２４４）、処理結果を応答する（ステップＳ２４５）。このとき、続くステップＳ２４６以降に示す、発行済トークンの無効化を実行する場合には、無効化した利用者識別情報を応答に含める。
【０１２３】
続いて、利用者情報無効化部３１２は、利用者情報が無効化されたことを受けて、該当利用者に対して発行されたトークンの無効化を、トークン無効化部３０７に対して要求する（ステップＳ２４６）。以降の処理は、第１の実施形態のトークン無効化シーケンスと同様であり（ステップＳ２４７、ステップＳ２４８）、機器１０４に対して無効化通知を行ってもよい。
【０１２４】
以上のように、本実施形態によれば、第１の実施形態のようにアクセス承認装置、利用者認証装置などのインターネット上の外部装置を利用せずに、アクセス認可装置単体で、第三者（アプリケーション１１０、あるいは、その開発者）がリソースの管理実体（機器１０４、すなわちデジタルテレビ、および、その所有者であるユーザ）と直接信頼関係を構築できないケースにおいても、第三者に対してリソースへのアクセス権限を委譲可能とし、かつ、ユーザ以外のリソース管理実体の管理者（例えば、機器メーカ）が、第三者による不正なリソースへのアクセスを防ぐことが可能となっている」。
【０１２５】
また、第１の実施形態との差分として、ユーザや機器メーカなどの権限保持者が、利用者識別情報を無効化することによって、当該利用者（アプリケーション）に係るトークンを一括で無効化し、リソースの不正利用を効率的に防ぐことが可能となっている。
【０１２６】
＜利用者認証のバリエーション＞
最後に、第１の実施形態と同様、利用者認証を、ユーザ（アクセス承認者）から承認を得る前に行ってもよい。この場合、図１３のトークン発行処理シーケンスのステップＳ２２５の時点で、ステップＳ２３３、Ｓ２３４の利用者認証を行う。このためには、第１の実施形態と同様、承認要求許可情報発行部３５１、記憶部３５２、認証部３５３が必要になる。利用者認証が既に済んでいることを証明するための承認要求許可情報が、利用情報提供部３１８へ渡され、アクセス承認前にチェックされる。
【符号の説明】
【０１２７】
１０１ アクセス認可装置
１０２ アクセス承認装置
１０３ 利用者認証装置
１０４ 機器
１０５ 操作機器
１１０ アプリケーション
２０１ ネットワーク（インターネット、ＮＧＮ）
２０２ ネットワーク（ホームネットワーク）
３０１ 第１送受信部
３０２ 第２送受信部
３０３ トークン発行判定部
３０４ トークン発行部
３０５ トークン情報記憶部
３０６ トークン情報提供部
３０７ トークン無効化部
３０８ 利用者識別情報発行部
３０９ 利用者情報記憶部
３１０ 利用者認証部
３１１ 利用者情報提供部
３１２ 利用者情報無効化部
３１３ 開発者情報登録部
３１４ 開発者情報記憶部
３１５ 承認者情報登録部
３１６ 機器情報登録部
３１７ 承認者情報記憶部
３１８ 利用情報提供部
３１９ 承認情報発行部
３２０ 承認情報記憶部
３２１ 承認判定部
３５１ 承認要求許可情報発行部
３５２ 承認要求許可情報記憶部
３５３ 承認要求許可情報認証部
【特許請求の範囲】
【請求項１】
第1アプリケーションによって利用されるリソースを有する機器、およびアクセス承認装置とそれぞれネットワークを介して接続される、アクセス認可装置であって、
前記機器における前記リソースへのアクセスをアクセス承認者から承認されたことを示す第1承認情報を、前記第1アプリケーションから前記ネットワークを介して受信する受信部と、
前記第1承認情報を含むアクセス承認要求を前記アクセス承認装置に送信し、前記第1アプリケーションによる前記リソースへのアクセスを許可するかを示すアクセス可否情報を前記アクセス承認装置から受信する第1送受信部と、
前記アクセス可否情報が前記リソースへのアクセス許可を示すとき、前記リソースへのアクセス権限を前記第1アプリケーションに与えるトークン情報を発行するトークン発行部と、
前記トークン発行部により発行された前記トークン情報を前記第1アプリケーションに送信する送信部と、
を備えたアクセス認可装置。
【請求項２】
前記トークン発行部により発行されたトークン情報を記憶するトークン情報記憶部
をさらに備えたことを特徴とする請求項１に記載のアクセス認可装置。
【請求項３】
前記トークン発行部により発行された前記トークン情報または前記トークン情報記憶部内のトークン情報を前記機器に提供するトークン情報提供部
をさらに備えたことを特徴とする請求項２に記載のアクセス認可装置。
【請求項４】
前記ネットワーク上の外部装置、またはアクセス認可装置のオペレータから前記トークン情報の無効化要求を受けて、前記トークン情報記憶部内の前記トークン情報を無効化するトークン無効化部
をさらに備えたことを特徴とする請求項３に記載のアクセス認可装置。
【請求項５】
トークン無効化部をさらに備え、
前記トークン発行部は、発行するトークン情報に有効期限を設定し、
前記トークン無効化部は、前記トークン情報記憶部における前記有効期限が切れたトークン情報を無効化する
ことを特徴とする請求項３に記載のアクセス認可装置。
【請求項６】
前記トークン情報提供部は、前記トークン無効化部により前記トークン情報が無効化されたとき、前記トークン情報が無効化されたことを前記機器に通知する
ことを特徴とする請求項４または５に記載のアクセス認可装置。
【請求項７】
前記トークン情報は、前記トークン情報の識別子を表すトークンを含む
ことを特徴とする請求項１ないし６のいずれか一項に記載のアクセス認可装置。
【請求項８】
前記トークン情報は、前記機器を識別する機器識別情報、前記第1アプリケーションを識別する利用者識別情報、前記第1承認情報、前記第1アプリケーションの詳細情報である利用者情報、前記機器の詳細情報である機器情報、前記トークン情報の有効期限情報、および前記トークン情報が有効か否かを表す論理値情報のうち少なくとも１つをさらに含む
ことを特徴とする請求項７に記載のアクセス認可装置。
【請求項９】
前記第1アプリケーションを識別する利用者識別情報を含む利用者認証要求を、前記ネットワークを介して利用者認証装置に送信し、前記利用者認証装置から前記第1アプリケーションの認証が成功したか否かを示す利用者認証結果情報を受信する第２送受信部をさらに備え、
前記トークン発行部は、前記第２送受信部で前記第1アプリケーションの認証成功を示す利用者認証結果情報が受信されたとき、前記トークン情報を発行する
ことを特徴とする請求項１ないし８のいずれか一項に記載のアクセス認可装置。
【請求項１０】
前記第1アプリケーションを識別する利用者識別情報を含む利用者認証要求を、前記ネットワークを介して利用者認証装置に送信し、前記利用者認証装置から前記第1アプリケーションの認証が成功したか否かを示す利用者認証結果情報を受信する第２送受信部と、
前記利用者認証結果情報が認証の成功を示すとき、前記第1アプリケーションに対し承認要求許可情報を発行する承認要求許可情報発行部と、
前記第1アプリケーションに対して発行された前記承認要求許可情報を記憶する承認要求許可情報記憶部と、
前記アクセス承認装置から前記利用者識別情報および承認要求許可情報を含む認証要求を受信し、前記認証要求に含まれる前記利用者識別情報のアプリケーションに対する承認要求許可情報が前記承認要求許可情報記憶部に登録されているとき、前記アプリケーションの認証の成功を示す応答を前記アクセス承認装置に返す承認要求許可情報認証部と、
を備えたことを特徴とする請求項１ないし８のいずれか一項に記載のアクセス認可装置。
【請求項１１】
前記第1承認情報は、前記アクセス承認者による承認を識別するアクセス可否検証コードを含む
ことを特徴とする請求項１ないし１０のいずれか一項に記載のアクセス認可装置。
【請求項１２】
前記第1承認情報は、アクセスを承認されたリソースの、種別情報、属性情報、範囲情報のうちの少なくとも１つをさらに含む
ことを特徴とする請求項１１に記載のアクセス認可装置。
【請求項１３】
前記利用者識別情報は、前記利用者識別情報の正当性を証明するための秘密情報と、秘密情報のハッシュ値と、秘密情報を用いた署名情報とのうち少なくとも１つを含む
ことを特徴とする請求項８ないし１０のいずれか一項に記載のアクセス認可装置。
【請求項１４】
第1アプリケーションによって利用されるリソースを含む機器とネットワークを介して接続された、アクセス認可装置であって、
アクセス承認者により前記機器における前記リソースへアクセスすることを承認されたアプリケーションに対し承認情報を記憶する承認情報記憶部と、
前記第1アプリケーションから第1承認情報を、前記ネットワークを介して受信する受信部と、
前記第1承認情報と前記承認情報記憶部の内容に基づき、前記第1アプリケーションが前記機器の前記リソースへアクセスするのを許可するかを判定する承認判定部と、
前記承認判定部により前記リソースへのアクセスが許可されたとき、前記リソースへのアクセス権限を前記第1アプリケーションに与えるトークン情報を発行するトークン発行部と、
前記トークン情報を前記ネットワークを介して前記第1アプリケーションに送信する送信部と、
を備えたアクセス認可装置。
【請求項１５】
前記トークン発行部により発行されたトークン情報を記憶するトークン情報記憶部
をさらに備えたことを特徴とする請求項１４に記載のアクセス認可装置。
【請求項１６】
前記第1アプリケーションに対して発行された前記トークン情報または前記トークン情報記憶部内のトークン情報、を前記機器に提供するトークン情報提供部
をさらに備えたことを特徴とする請求項１５に記載のアクセス認可装置。
【請求項１７】
前記ネットワーク上の外部装置、またはアクセス認可装置のオペレータから前記トークン情報の無効化要求を受けて、前記トークン情報記憶部内の前記トークン情報を無効化するトークン無効化部
をさらに備えたことを特徴とする請求項１６に記載のアクセス認可装置。
【請求項１８】
トークン無効化部をさらに備え、
前記トークン発行部は、発行するトークン情報に有効期限を設定し、
前記トークン無効化部は、前記トークン情報記憶部における前記有効期限が切れたトークン情報を無効化する
ことを特徴とする請求項１６に記載のアクセス認可装置。
【請求項１９】
前記トークン情報提供部は、前記トークン無効化部により前記トークン情報が無効化されたとき、前記トークン情報が無効化されたことを前記機器に通知する
ことを特徴とする請求項１７または１８に記載のアクセス認可装置。
【請求項２０】
前記トークン情報は、前記トークン情報の識別子を表すトークンを含むことを特徴とする請求項１４ないし１９のいずれか一項に記載のアクセス認可装置。
【請求項２１】
前記トークン情報は、前記機器を識別する機器識別情報、前記第1アプリケーションを識別する利用者識別情報、前記第1承認情報、前記第1アプリケーションの詳細情報である利用者情報、前記機器の詳細情報である機器情報、前記トークン情報の有効期限情報、および前記トークン情報が有効か否かを表す論理値情報のうち少なくとも１つをさらに含む
ことを特徴とする請求項２０に記載のアクセス認可装置。
【請求項２２】
前記機器のリソースへ前記第1アプリケーションがアクセスすることを許可するアクセス承認者による承認を前記機器から受信し、前記承認に基づき前記第1承認情報を発行し、発行した第1承認情報を前記機器に送信する前記承認情報発行部をさらに備え、
前記承認情報記憶部は、前記承認情報発行部により発行された第1承認情報を記憶する
ことを特徴とする請求項１４ないし２１のいずれか一項に記載のアクセス認可装置。
【請求項２３】
前記機器のリソースへ第1アプリケーションがアクセスすることを許可するか否かを前記アクセス承認者へ問い合わせるための利用情報を前記機器へ送信する利用情報提供部
をさらに備えたことを特徴とする請求項２２に記載のアクセス認可装置。
【請求項２４】
前記利用情報は、前記第1アプリケーションの詳細情報である利用者情報、前記第1アプリケーションの開発者情報、前記機器の詳細情報である機器情報、および、前記第1アプリケーションがアクセスを求めているリソースの情報を含むこと
を特徴とする請求項２３に記載のアクセス認可装置。
【請求項２５】
前記第1アプリケーションを識別する利用者識別情報を前記第1アプリケーションから受信する受信部と、
前記第1アプリケーションの利用者識別情報に基づき認証を行う利用者認証部と、
前記利用者認証部の認証が成功したとき、前記第1アプリケーションに対し承認要求許可情報を発行し、発行した承認要求許可情報を前記機器に送信する承認要求許可情報発行部と、
前記第1アプリケーションに対して発行された前記承認要求許可情報を記憶する承認要求許可情報記憶部と、
前記機器から前記利用者識別情報および承認要求許可情報を受信し、前記利用者識別情報のアプリケーションに対する承認要求許可情報が前記承認要求許可情報記憶部に登録されているとき、前記利用情報提供部による前記利用情報の提供を許可し、登録されていないとき許可しない承認判定部と、
を備えたことを特徴とする請求項２２ないし２４のいずれか一項に記載のアクセス認可装置。
【請求項２６】
前記第1アプリケーションを識別する利用者識別情報に基づき認証を行う利用者認証部をさらに備え、
前記受信部は、前記第1アプリケーションから前記利用者識別情報を受信し、
前記トークン発行部は、前記利用者認証部による前記第1アプリケーションの認証が成功したとき前記トークン情報を発行する
ことを特徴とする請求項１４ないし２４のいずれか一項に記載のアクセス認可装置。
【請求項２７】
前記第1承認情報は、前記アクセス承認者による承認を識別するアクセス可否検証コードを含む
ことを特徴とする請求項１４ないし２６のいずれか一項に記載のアクセス認可装置。
【請求項２８】
前記第1承認情報は、アクセスを承認されたリソースの、種別情報、属性情報、範囲情報のうちの少なくとも１つをさらに含む
ことを特徴とする請求項２７に記載のアクセス認可装置。
【請求項２９】
前記利用者識別情報は、前記利用者識別情報の正当性を証明するための秘密情報と、秘密情報のハッシュ値と、秘密情報を用いた署名情報とのうち少なくとも１つを含む
ことを特徴とする請求項２１、２５、２６のいずれか一項に記載のアクセス認可装置。
【請求項３０】
前記承認要求許可情報は、少なくとも、前記第1アプリケーションに対する承認を識別する承認要求許可識別子を含む
ことを特徴とする請求項２５に記載のアクセス認可装置。
【請求項３１】
前記ネットワーク上の外部装置から、前記第1アプリケーションの詳細情報である利用者情報を受信し、前記第1アプリケーションの前記利用者識別情報を発行する利用者識別情報発行部
を備えたことを特徴とする請求項２１、２５、２６、２９に記載のアクセス認可装置。
【請求項３２】
前記利用者識別情報と、前記利用者情報とを関連づけて記憶する利用者情報記憶部
を備えたことを特徴とする請求項３１に記載のアクセス認可装置。
【請求項３３】
前記利用者情報の提供要求を受けて、前記利用者情報を前記利用者情報記憶部から取り出して提供する利用者情報提供部
をさらに備えたことを特徴とする請求項３２に記載のアクセス認可装置。
【請求項３４】
前記ネットワーク上の外部装置、またはアクセス認可装置のオペレータから前記利用者識別情報の無効化要求を受けて、前記利用情報記憶部における前記利用者識別情報を無効化する利用者情報無効化部
を備えたことを特徴とする請求項３１ないし３３のいずれか一項に記載のアクセス認可装置。
【請求項３５】
アプリケーションの開発者に関する開発者情報を記憶する開発者情報記憶部と、
前記ネットワーク上の外部装置から前記第1アプリケーションの開発者情報を受信し、前記第1アプリケーションの前記開発者情報を前記開発者情報記憶部に登録する開発者情報登録部と
をさらに備えたことを特徴とする請求項１４ないし３４のいずれか一項に記載のアクセス認可装置。
【請求項３６】
前記アクセス承認者の承認者情報を記憶する承認者情報記憶部と、
前記ネットワーク上の外部装置から前記アクセス承認者の承認者情報を受信して、前記承認者情報記憶部に登録する承認者情報登録部と
をさらに備えたことを特徴とする請求項１４ないし３５のいずれか一項に記載のアクセス認可装置。
【請求項３７】
前記ネットワーク上の外部装置から、前記アクセス承認者がアクセス承認の権限を持つ機器の機器情報を受信し、前記機器情報を前記承認者情報記憶部に登録する機器情報登録部
をさらに備えたことを特徴とする請求項３６に記載のアクセス認可装置。
【請求項１】
第1アプリケーションによって利用されるリソースを有する機器、およびアクセス承認装置とそれぞれネットワークを介して接続される、アクセス認可装置であって、
前記機器における前記リソースへのアクセスをアクセス承認者から承認されたことを示す第1承認情報を、前記第1アプリケーションから前記ネットワークを介して受信する受信部と、
前記第1承認情報を含むアクセス承認要求を前記アクセス承認装置に送信し、前記第1アプリケーションによる前記リソースへのアクセスを許可するかを示すアクセス可否情報を前記アクセス承認装置から受信する第1送受信部と、
前記アクセス可否情報が前記リソースへのアクセス許可を示すとき、前記リソースへのアクセス権限を前記第1アプリケーションに与えるトークン情報を発行するトークン発行部と、
前記トークン発行部により発行された前記トークン情報を前記第1アプリケーションに送信する送信部と、
を備えたアクセス認可装置。
【請求項２】
前記トークン発行部により発行されたトークン情報を記憶するトークン情報記憶部
をさらに備えたことを特徴とする請求項１に記載のアクセス認可装置。
【請求項３】
前記トークン発行部により発行された前記トークン情報または前記トークン情報記憶部内のトークン情報を前記機器に提供するトークン情報提供部
をさらに備えたことを特徴とする請求項２に記載のアクセス認可装置。
【請求項４】
前記ネットワーク上の外部装置、またはアクセス認可装置のオペレータから前記トークン情報の無効化要求を受けて、前記トークン情報記憶部内の前記トークン情報を無効化するトークン無効化部
をさらに備えたことを特徴とする請求項３に記載のアクセス認可装置。
【請求項５】
トークン無効化部をさらに備え、
前記トークン発行部は、発行するトークン情報に有効期限を設定し、
前記トークン無効化部は、前記トークン情報記憶部における前記有効期限が切れたトークン情報を無効化する
ことを特徴とする請求項３に記載のアクセス認可装置。
【請求項６】
前記トークン情報提供部は、前記トークン無効化部により前記トークン情報が無効化されたとき、前記トークン情報が無効化されたことを前記機器に通知する
ことを特徴とする請求項４または５に記載のアクセス認可装置。
【請求項７】
前記トークン情報は、前記トークン情報の識別子を表すトークンを含む
ことを特徴とする請求項１ないし６のいずれか一項に記載のアクセス認可装置。
【請求項８】
前記トークン情報は、前記機器を識別する機器識別情報、前記第1アプリケーションを識別する利用者識別情報、前記第1承認情報、前記第1アプリケーションの詳細情報である利用者情報、前記機器の詳細情報である機器情報、前記トークン情報の有効期限情報、および前記トークン情報が有効か否かを表す論理値情報のうち少なくとも１つをさらに含む
ことを特徴とする請求項７に記載のアクセス認可装置。
【請求項９】
前記第1アプリケーションを識別する利用者識別情報を含む利用者認証要求を、前記ネットワークを介して利用者認証装置に送信し、前記利用者認証装置から前記第1アプリケーションの認証が成功したか否かを示す利用者認証結果情報を受信する第２送受信部をさらに備え、
前記トークン発行部は、前記第２送受信部で前記第1アプリケーションの認証成功を示す利用者認証結果情報が受信されたとき、前記トークン情報を発行する
ことを特徴とする請求項１ないし８のいずれか一項に記載のアクセス認可装置。
【請求項１０】
前記第1アプリケーションを識別する利用者識別情報を含む利用者認証要求を、前記ネットワークを介して利用者認証装置に送信し、前記利用者認証装置から前記第1アプリケーションの認証が成功したか否かを示す利用者認証結果情報を受信する第２送受信部と、
前記利用者認証結果情報が認証の成功を示すとき、前記第1アプリケーションに対し承認要求許可情報を発行する承認要求許可情報発行部と、
前記第1アプリケーションに対して発行された前記承認要求許可情報を記憶する承認要求許可情報記憶部と、
前記アクセス承認装置から前記利用者識別情報および承認要求許可情報を含む認証要求を受信し、前記認証要求に含まれる前記利用者識別情報のアプリケーションに対する承認要求許可情報が前記承認要求許可情報記憶部に登録されているとき、前記アプリケーションの認証の成功を示す応答を前記アクセス承認装置に返す承認要求許可情報認証部と、
を備えたことを特徴とする請求項１ないし８のいずれか一項に記載のアクセス認可装置。
【請求項１１】
前記第1承認情報は、前記アクセス承認者による承認を識別するアクセス可否検証コードを含む
ことを特徴とする請求項１ないし１０のいずれか一項に記載のアクセス認可装置。
【請求項１２】
前記第1承認情報は、アクセスを承認されたリソースの、種別情報、属性情報、範囲情報のうちの少なくとも１つをさらに含む
ことを特徴とする請求項１１に記載のアクセス認可装置。
【請求項１３】
前記利用者識別情報は、前記利用者識別情報の正当性を証明するための秘密情報と、秘密情報のハッシュ値と、秘密情報を用いた署名情報とのうち少なくとも１つを含む
ことを特徴とする請求項８ないし１０のいずれか一項に記載のアクセス認可装置。
【請求項１４】
第1アプリケーションによって利用されるリソースを含む機器とネットワークを介して接続された、アクセス認可装置であって、
アクセス承認者により前記機器における前記リソースへアクセスすることを承認されたアプリケーションに対し承認情報を記憶する承認情報記憶部と、
前記第1アプリケーションから第1承認情報を、前記ネットワークを介して受信する受信部と、
前記第1承認情報と前記承認情報記憶部の内容に基づき、前記第1アプリケーションが前記機器の前記リソースへアクセスするのを許可するかを判定する承認判定部と、
前記承認判定部により前記リソースへのアクセスが許可されたとき、前記リソースへのアクセス権限を前記第1アプリケーションに与えるトークン情報を発行するトークン発行部と、
前記トークン情報を前記ネットワークを介して前記第1アプリケーションに送信する送信部と、
を備えたアクセス認可装置。
【請求項１５】
前記トークン発行部により発行されたトークン情報を記憶するトークン情報記憶部
をさらに備えたことを特徴とする請求項１４に記載のアクセス認可装置。
【請求項１６】
前記第1アプリケーションに対して発行された前記トークン情報または前記トークン情報記憶部内のトークン情報、を前記機器に提供するトークン情報提供部
をさらに備えたことを特徴とする請求項１５に記載のアクセス認可装置。
【請求項１７】
前記ネットワーク上の外部装置、またはアクセス認可装置のオペレータから前記トークン情報の無効化要求を受けて、前記トークン情報記憶部内の前記トークン情報を無効化するトークン無効化部
をさらに備えたことを特徴とする請求項１６に記載のアクセス認可装置。
【請求項１８】
トークン無効化部をさらに備え、
前記トークン発行部は、発行するトークン情報に有効期限を設定し、
前記トークン無効化部は、前記トークン情報記憶部における前記有効期限が切れたトークン情報を無効化する
ことを特徴とする請求項１６に記載のアクセス認可装置。
【請求項１９】
前記トークン情報提供部は、前記トークン無効化部により前記トークン情報が無効化されたとき、前記トークン情報が無効化されたことを前記機器に通知する
ことを特徴とする請求項１７または１８に記載のアクセス認可装置。
【請求項２０】
前記トークン情報は、前記トークン情報の識別子を表すトークンを含むことを特徴とする請求項１４ないし１９のいずれか一項に記載のアクセス認可装置。
【請求項２１】
前記トークン情報は、前記機器を識別する機器識別情報、前記第1アプリケーションを識別する利用者識別情報、前記第1承認情報、前記第1アプリケーションの詳細情報である利用者情報、前記機器の詳細情報である機器情報、前記トークン情報の有効期限情報、および前記トークン情報が有効か否かを表す論理値情報のうち少なくとも１つをさらに含む
ことを特徴とする請求項２０に記載のアクセス認可装置。
【請求項２２】
前記機器のリソースへ前記第1アプリケーションがアクセスすることを許可するアクセス承認者による承認を前記機器から受信し、前記承認に基づき前記第1承認情報を発行し、発行した第1承認情報を前記機器に送信する前記承認情報発行部をさらに備え、
前記承認情報記憶部は、前記承認情報発行部により発行された第1承認情報を記憶する
ことを特徴とする請求項１４ないし２１のいずれか一項に記載のアクセス認可装置。
【請求項２３】
前記機器のリソースへ第1アプリケーションがアクセスすることを許可するか否かを前記アクセス承認者へ問い合わせるための利用情報を前記機器へ送信する利用情報提供部
をさらに備えたことを特徴とする請求項２２に記載のアクセス認可装置。
【請求項２４】
前記利用情報は、前記第1アプリケーションの詳細情報である利用者情報、前記第1アプリケーションの開発者情報、前記機器の詳細情報である機器情報、および、前記第1アプリケーションがアクセスを求めているリソースの情報を含むこと
を特徴とする請求項２３に記載のアクセス認可装置。
【請求項２５】
前記第1アプリケーションを識別する利用者識別情報を前記第1アプリケーションから受信する受信部と、
前記第1アプリケーションの利用者識別情報に基づき認証を行う利用者認証部と、
前記利用者認証部の認証が成功したとき、前記第1アプリケーションに対し承認要求許可情報を発行し、発行した承認要求許可情報を前記機器に送信する承認要求許可情報発行部と、
前記第1アプリケーションに対して発行された前記承認要求許可情報を記憶する承認要求許可情報記憶部と、
前記機器から前記利用者識別情報および承認要求許可情報を受信し、前記利用者識別情報のアプリケーションに対する承認要求許可情報が前記承認要求許可情報記憶部に登録されているとき、前記利用情報提供部による前記利用情報の提供を許可し、登録されていないとき許可しない承認判定部と、
を備えたことを特徴とする請求項２２ないし２４のいずれか一項に記載のアクセス認可装置。
【請求項２６】
前記第1アプリケーションを識別する利用者識別情報に基づき認証を行う利用者認証部をさらに備え、
前記受信部は、前記第1アプリケーションから前記利用者識別情報を受信し、
前記トークン発行部は、前記利用者認証部による前記第1アプリケーションの認証が成功したとき前記トークン情報を発行する
ことを特徴とする請求項１４ないし２４のいずれか一項に記載のアクセス認可装置。
【請求項２７】
前記第1承認情報は、前記アクセス承認者による承認を識別するアクセス可否検証コードを含む
ことを特徴とする請求項１４ないし２６のいずれか一項に記載のアクセス認可装置。
【請求項２８】
前記第1承認情報は、アクセスを承認されたリソースの、種別情報、属性情報、範囲情報のうちの少なくとも１つをさらに含む
ことを特徴とする請求項２７に記載のアクセス認可装置。
【請求項２９】
前記利用者識別情報は、前記利用者識別情報の正当性を証明するための秘密情報と、秘密情報のハッシュ値と、秘密情報を用いた署名情報とのうち少なくとも１つを含む
ことを特徴とする請求項２１、２５、２６のいずれか一項に記載のアクセス認可装置。
【請求項３０】
前記承認要求許可情報は、少なくとも、前記第1アプリケーションに対する承認を識別する承認要求許可識別子を含む
ことを特徴とする請求項２５に記載のアクセス認可装置。
【請求項３１】
前記ネットワーク上の外部装置から、前記第1アプリケーションの詳細情報である利用者情報を受信し、前記第1アプリケーションの前記利用者識別情報を発行する利用者識別情報発行部
を備えたことを特徴とする請求項２１、２５、２６、２９に記載のアクセス認可装置。
【請求項３２】
前記利用者識別情報と、前記利用者情報とを関連づけて記憶する利用者情報記憶部
を備えたことを特徴とする請求項３１に記載のアクセス認可装置。
【請求項３３】
前記利用者情報の提供要求を受けて、前記利用者情報を前記利用者情報記憶部から取り出して提供する利用者情報提供部
をさらに備えたことを特徴とする請求項３２に記載のアクセス認可装置。
【請求項３４】
前記ネットワーク上の外部装置、またはアクセス認可装置のオペレータから前記利用者識別情報の無効化要求を受けて、前記利用情報記憶部における前記利用者識別情報を無効化する利用者情報無効化部
を備えたことを特徴とする請求項３１ないし３３のいずれか一項に記載のアクセス認可装置。
【請求項３５】
アプリケーションの開発者に関する開発者情報を記憶する開発者情報記憶部と、
前記ネットワーク上の外部装置から前記第1アプリケーションの開発者情報を受信し、前記第1アプリケーションの前記開発者情報を前記開発者情報記憶部に登録する開発者情報登録部と
をさらに備えたことを特徴とする請求項１４ないし３４のいずれか一項に記載のアクセス認可装置。
【請求項３６】
前記アクセス承認者の承認者情報を記憶する承認者情報記憶部と、
前記ネットワーク上の外部装置から前記アクセス承認者の承認者情報を受信して、前記承認者情報記憶部に登録する承認者情報登録部と
をさらに備えたことを特徴とする請求項１４ないし３５のいずれか一項に記載のアクセス認可装置。
【請求項３７】
前記ネットワーク上の外部装置から、前記アクセス承認者がアクセス承認の権限を持つ機器の機器情報を受信し、前記機器情報を前記承認者情報記憶部に登録する機器情報登録部
をさらに備えたことを特徴とする請求項３６に記載のアクセス認可装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１２−９８８３９（Ｐ２０１２−９８８３９Ａ）
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願番号】特願２０１０−２４４６７８（Ｐ２０１０−２４４６７８）
【出願日】平成２２年１０月２９日（２０１０．１０．２９）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願日】平成２２年１０月２９日（２０１０．１０．２９）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]