JP5624525B2 - 情報処理装置、リソース提供装置および情報処理システム - Google Patents

Description

本発明の実施形態は、情報処理装置、リソース提供装置および情報処理システムに関する。

サービス事業者が運用するサイト上のＷｅｂページを介して 、ＰＣやスマートフォン等の端末内部のリソース（機能・情報）にアクセスする技術として、Ｗ３Ｃ Ｄｅｖｉｃｅ ＡＰＩがある。代表例としては、スマートフォンのＧＰＳ情報にアクセスして、位置情報に基づくサービス提供を可能にする、Ｇｅｏｌｏｃａｔｉｏｎ ＡＰＩがある。こうした、Ｄｅｖｉｃｅ ＡＰＩ技術（ここでは、本来Ｗｅｂページからは利用できない端末内部機能を利用する技術を指す）の一例として、ホームネットワーク上のルータやＡＶ機器のプラグアンドプレイを実現するＵＰｎＰ機能を、Ｗｅｂページから利用する技術が知られている。この技術を利用することで、サービス事業者が提供するＷｅｂページと、ホームネットワーク上の宅内機器リソースとのマッシュアップ（連携）が実現可能である。

Webブラウザは、Webコンテンツを構成する各パーツをネットワーク上のサイトから取得し、表示する。この時、表示するデータのみをサーバから取得し、レイアウト情報や固定的な画像データ等のテンプレートはキャッシュしておく、といった最適化手法は知られている。

しかしながら、上述した技術を用いる場合、サービス事業者が、ホームネットワーク上の機器に（Ｗｅｂページを介して）直接アクセスするものであり、幾つかの問題点がある。

第１に、サービスは、アクセス対象機器（リソース提供装置）の存在を知る必要がある。すなわち、ＰＣやスマートフォンなどのＷｅｂブラウザ搭載デバイスは、ホームネットワーク上の機器情報をサービス側に開示しなければならない。

第２に、サービスは、ホームネットワーク上の機器毎に異なり得るアクセス方式に対応する必要がある。

以上の問題点について、具体例を用いて説明する。例えば、サービス事業者がインターネット上で電子番組表サービスを運営しているケースを考える。この電子番組表サービスのＷｅｂページには、表示される番組表の番組欄にそれぞれ「録画ボタン」が設置されており、この電子番組表サービスを自宅ＰＣのＷｅｂブラウザ上で表示し、この「録画ボタン」を押下すると、自宅内のデジタルテレビで該当番組の録画予約を行うことが出来るものとする。

このとき、上述した技術において、このユースケースを実現する場合、電子番組表サービスのＷｅｂページに埋め込まれたプログラム（ＪａｖａＳｃｒｉｐｔスクリプトコード）は、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉｅｎｃｅ）の機能をそのままＷｅｂページ上から利用することになる。したがって、ＤＬＮＡ Ｄｉｓｃｏｖｅｒｙによって、ＰＣが設置されたホームネットワーク上にデジタルテレビが存在することを発見し、発見したデジタルテレビの詳細情報をＤＬＮＡ Ｄｅｓｃｒｉｐｔｉｏｎでデジタルテレビから直接取得し、録画予約のＤＬＮＡ Ａｃｔｉｏｎコマンドを送信することにより、Ｗｅｂページからの録画予約が実現される。

しかしながら、この一連のシーケンスにおいて、サービス事業者の提供するプログラムが、ユーザのホームネットワーク上に存在する機器の一覧や、各機器の詳細情報を容易に取得することが出来てしまっている。すなわち、プログラムがサービス事業者のサーバに取得した情報をアップロードするロジックを組み込んだ場合、個人情報（ユーザがどのような機器を所有しているか等）がサービス事業者側に漏洩してしまっている。

また、ＤＬＮＡに留まらず、ＥＣＨＯＮＥＴ等、別のプロトコルに対応した機器も操作対象とする場合には、上記プログラムは、複数のプロトコルに対応したコードを含まなければならない。特に、ホームネットワークに存在する機器の種別がわからない以上、全ての伝送プロトコル、さらには、機器がサポートし得る全ての認証・認可方式にも対応しなければならす、サービス事業者側に高い開発コストがかかる。

ＣＥＡ Ｓｔａｎｄａｒｄ ＣＥＡ−２０１４, http://www.ce.org

上述したように、従来技術には、サービス事業者がアクセス対象機器の存在を知る必要がある、という問題があった。

本発明の一側面は、上記従来技術の問題点を解決するためになされたものであって、プログラム提供装置を用いてサービスを提供するサービス事業者にリソース提供装置の情報を開示すること無く、当該サービスとリソース提供装置のリソースとをマッシュアップ（連携）することを実現する情報処理装置、リソース提供装置および情報処理システムを提供することを目的とする。

本発明の一態様としての情報処理装置は、プログラム提供装置およびリソース提供装置とネットワークを介して通信する情報処理装置であって、通信部と、プログラム実行部と、変換部と、を備える。

前記通信部は、前記プログラム提供装置から、第1の形式で記述されたリソースの利用要求を含むプログラムを受信する。

前記プログラム実行部は、前記プログラムを実行し、前記リソースの利用要求を抽出する。

前記変換部は、前記利用要求に示されるリソースを提供するリソース提供装置を特定し、前記利用要求を、特定したリソース提供装置によって解釈可能な第２形式に変換する。

前記通信部は、変換された利用要求を前記特定したリソース提供装置に送信し、前記リソース提供装置から、前記利用要求の処理結果を受信する。

前記変換部は、前記通信部で受信された処理結果を、前記第１の形式に変換する。

前記プログラム実行部は、前記変換部により変換された処理結果に応じた動作を行う。

本発明の第１の実施形態に係わるシステムの構成を示すブロック図。 本発明の第２の実施形態に係わるシステムの構成を示すブロック図。 本発明の第３の実施形態に係わるシステムの構成を示すブロック図。 本発明の第４の実施形態に係わるシステムの構成を示すブロック図。 本発明の第１の実施形態における機器情報記憶部のデータ構造の一例を示す図。 本発明の第２の実施形態における機器情報記憶部のデータ構造の一例を示す図。 本発明の第３の実施形態における機器情報記憶部のデータ構造の一例を示す図。 本発明の第４の実施形態における機器情報記憶部のデータ構造の一例を示す図。 本発明の第４の実施形態におけるアクセス要求元情報記憶部のデータ構造の一例を示す図。 本発明の第４の実施形態におけるプログラム提供装置が提供するプログラムの概略を示す図。 本発明の第４の実施形態における変換部が提供するリソース利用APIを定義したライブラリの一例を示す図。 本発明の第４の実施形態におけるリソース提供装置が提供する変換プログラムの一例を示す図。 本発明の第１の実施形態における変換部のフローチャート。 本発明の第２の実施形態における変換部のフローチャート。 本発明の第３及び第４の実施形態における変換部のフローチャート。 本発明の第１の実施形態におけるシステム構成要素間のシーケンス図。 本発明の第２の実施形態におけるシステム構成要素間のシーケンス図。 本発明の第３の実施形態におけるシステム構成要素間のシーケンス図。 本発明の第４の実施形態におけるシステム構成要素間のシーケンス図。

以下、本発明の実施形態について説明する。

（第１の実施形態）
本実施形態の概要として、想定する具体的なユースケースについて記す。

まず、ユーザが、ＰＣで、インターネット上のサービス（前述の電子番組表サービス）のＷｅｂページを閲覧し、録画予約したい番組欄の「録画ボタン」を押下する。このボタン押下によって、閲覧中のＷｅｂページに埋め込まれたＪａｖａＳｃｒｉｐｔコードが実行され、ＰＣの内部機能としての「ＰＣ周辺ＡＶ機器での録画予約機能」が呼び出される。ＰＣの内部処理として、実際にはインターネット上のＮＰＶＲ（Ｎｅｔｗｏｒｋ Ｐｅｒｓｏｎａｌ Ｖｉｄｅｏ Ｒｅｃｏｒｄｅｒ）（ネットワーク録画予約）クラウドサービスが利用され、クラウドサービス上に指定番組が録画される。

以上のユースケースにおける、ＰＣが本実施形態にかかる情報処理装置であり、電子番組表サービスがプログラム提供装置、ＮＰＶＲサービスがリソース提供装置となる。以下、本実施形態の詳細について述べる。

図１は、本発明の第１の実施形態に係わる情報処理装置の機能ブロックを示すシステム構成図である。第１の実施形態に係るシステムは、情報処理装置１０１と、プログラム提供装置１０２と、リソース提供装置１０３で構成される。情報処理装置１０１、プログラム提供装置１０２、リソース提供装置１０３の三者は、ネットワーク２０１を介して接続されている。

次に、本実施形態のシステムを構成するネットワーク及び装置について説明する。

ネットワーク２０１は、インターネット、または、品質保証された閉域網であるＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）などのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークである。本実施形態においては、ネットワーク２０１は、インターネットであるとする。

情報処理装置１０１は、ＣＰＵ、主記憶、補助記憶で構成され、ディスプレイと、キーボード等の入出力インタフェースとを備える、通常のコンピュータのハードウェア構成となっている。具体的には、ＰＣ、スマートフォン、スレートデバイスなどである。本実施形態において、情報処理装置１０１は、ラップトップＰＣであるとする。

プログラム提供装置（アクセス要求元）１０２は、情報処理装置１０１と同じく、通常のコンピュータのハードウェア構成となっている。具体的には、デジタル家電、ＰＣ、サーバ装置である。本実施形態においては、データセンター等で運用されるサーバ装置であり、インターネット上でＷｅｂサービス（サイト）を提供している。具体的には、前述した電子番組表サービスを提供しているものとする。このサービスは、電子番組表を閲覧するユーザが有する録画予約可能な機器（もしくは外部サービス）に対して、録画予約が行えるものを想定する。

なお、プログラム提供装置１０２が提供するプログラムは、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ドキュメントに埋め込まれたＪａｖａＳｃｒｉｐｔプログラムである。あるいは、Ｆｌａｓｈコンテンツであってもよいし、既存のＷｅｂコンテンツに限定されるものではなく、ＸＭＬ、ＢＭＬ（Ｂｒｏａｄｃａｓｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等の別のマークアップ言語と、ＪａｖａＳｃｒｉｐｔ以外のプログラム記述言語をベースにしたものであってもよい。本実施形態においては、プログラムは、ＪａｖａＳｃｒｉｐｔプログラムであるものとする。

リソース提供装置１０３は、プログラム提供装置１０２と同様、通常のコンピュータのハードウェア構成をとるものであり、具体的には、ＰＣ、サーバ装置である。本実施形態においては、データセンター等で運用されるサーバ装置であり、インターネット上でＮＰＶＲサービスを提供している。これは、サービスの会員ユーザが、サーバ上のストレージにテレビ番組を録画予約できるサービスであるものとする。

なお、リソース提供装置１０３が提供するリソースとは、装置内部の機能や情報を指すものとする。リソースへのアクセスは、リソース提供装置１０３が装置外部に公開するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を介して行われる。本実施形態においては、インターネット上に公開されたＷｅｂＡＰＩを介してリソースが提供されるものとする。

次に、情報処理装置１０１のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について図１に則して説明する。情報処理装置１０１は、第１通信部３０１、プログラム実行部３０２と、ＧＵＩ表示部３０３と、ＧＵＩ操作部３０４と、機器情報記憶部３０５と、変換部３０６とを有する。いずれも、ＣＰＵのプログラム実行時にＲＡＭなどの主記憶部上に生成されるものである。ＣＰＵの実行プログラムは、ハードディスクや、ＣＤ−ＲＯＭ等の記録媒体に格納されており、この記録媒体から読み出され、主記憶部に展開される。当該実行プログラムは、インターネット等のネットワークを介して情報処理装置１０１にダウンロードしてもよい。

このうち、機器情報記憶部３０５はデータベース管理システムである。これは、リレーショナルデータベースであってもよいし、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）データベースであってもよい。また、これは単一のデータベース管理システムで構築されている必要はなく、複数のデータベース管理システムを併用しても良い。また、１つの物理的な記憶部上に構築されるようにしてもよいし、ＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）や、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）といった複数の物理的な補助記憶部で構成されるデータベース管理システムとしてもよい。また、データの格納領域が不揮発であっても揮発であってもよい。あるいは、各記憶部に各々記憶されるデータの単位情報（エントリ）を取得できる手段を備えていれば、ＣＰＵのプログラム実行時に主記憶上に生成されるリスト構造ベースの簡易なデータ管理モジュールであってもよいし、ＣＳＶ形式ファイルの管理モジュールであってもよいし、Ｋｅｙ／Ｖａｌｕｅストアで構成されていてもよい。

以下、各部について説明する。

第１通信部３０１は、第１のネットワーク上のプログラム提供装置１０２、リソース提供装置１０３と通信する。第１通信部３０１は、プログラム実行部３０２からの要求を受けて、プログラムを含むＨＴＭＬドキュメントなどのＷｅｂコンテンツへの要求をプログラム提供装置１０２に送信し、Ｗｅｂコンテンツを受信する（前述したとおり、その他のフォーマットのコンテンツであってもよい）。第１通信部３０１は、後述する変換部３０６から入力されるリソース利用要求をリソース提供装置１０３に送信し、リソース提供装置１３による処理結果を受信する。両者との通信プロトコルについては、ＨＴＴＰ、ＦＴＰ等、ＴＣＰプロトコルをベースとしたものでもよく、ＲＴＰやＦＬＵＴＥなどＵＤＰプロトコルをベースとしたものであってもよく、特定のプロトコルに限定するものではない。本実施形態においては、インターネット上で両者とＨＴＴＰ（Ｓ）で通信する、ＨＴＴＰクライアントである。

プログラム実行部３０２は、前記プログラム提供装置１０２から受信したプログラムを含むＷｅｂコンテンツを処理する。前記プログラムに埋め込まれたリソース利用要求を、前記変換部３０６へ入力する。リソース利用要求の形式は、第1の形式に対応する。本実施形態及び後述の全ての実施形態において、このプログラム実行部３０２はＷｅｂブラウザ・エンジンである。しかしながら、Ｗｅｂブラウザに限定されるものではなく、ＢＭＬブラウザであってもよく、プログラムの実行環境を備えた、その他のアプリケーション・プラットフォームであってもよい。Ｗｅｂブラウザであることを前提とした場合、前記リソース利用要求は、情報処理装置１０１の内部リソースへのアクセスを実現するＪａｖａＳｃｒｉｐｔ ＡＰＩの呼び出し、あるいは、ＡＪＡＸ、ＷｅｂＳｏｃｋｅｔ等のＷｅｂブラウザ上で呼び出し可能な通信ＡＰＩを用いたメッセージ送信である。本実施形態においては、前記リソース利用要求は、ＪａｖａＳｃｒｉｐｔ ＡＰＩ呼び出しとして実現されるものとする。本実施形態において、前述した「録画予約ボタン」が押下されると呼び出されるＪａｖａＳｃｒｉｐｔプログラムには、例えば、以下のようなＪａｖａＳｃｒｉｐｔ ＡＰＩ（PVRDevice.reserve）が呼び出されることを想定している。

なお、この関数に含まれるパラメータは、テレビ番組を特定する識別情報のセットである。プログラム実行部３０２は、このＡＰＩの識別情報（API識別情報としてのAPI名(PVRDevice.reserve)など）と渡されたパラメータ情報（network_id, service_id, transport_stream_id, event_id）を、後述する変換部へ出力する。

ＧＵＩ表示部３０３は、情報処理装置１０１が備えるディスプレイへのレンダリングを、前記プログラム実行部３０２からの命令によって実行する。ＧＵＩ表示部３０３は、ユーザによる選択・承諾を必要とする場合に、変換部３０６からプログラム実行部３０２を介した要求にしたがって、選択・承諾のインタフェース（ポップアップ画面等）を表示する。

ＧＵＩ操作部３０４は、情報処理装置１０１が備えるキーボード、マウス、タッチパネル等の入力インタフェースを介して入力された操作信号を、プログラム実行部３０２へ出力する。プログラム実行部３０２は、この操作信号をユーザによる選択・承諾結果へと変換する（これは、Ｗｅｂブラウザの機能である）。

機器情報記憶部３０５は、リソース提供装置１０３の情報を、機器情報として記憶する。機器情報は、情報処理装置１０１のＧＵＩを介して、ユーザが手動で入力してもよい。また、本実施形態のように、ホームネットワーク上のサービスではなく、インターネット上のサービスである場合には、装置に機器情報がプリセットされていてもよいし、サービスへの加入・登録時に、情報処理装置内部に蓄積されるようにしてもよい。本実施形態におけるデータ構造の一例を図５に示す。図５に示すとおり、機器情報は、機器識別子、共通ＡＰＩ識別子、機器依存ＡＰＩのロケーション、機器依存ＡＰＩへの変換ルール情報（変換機構）を含む。ここで、機器情報を構成するこれらの属性について説明する。

まず、機器識別子は、機器すなわちリソース提供装置を識別する情報であり、ＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス、機器の型名と製造番号の組み合わせ、ＩＰｖ６アドレス等、リソース提供装置を一意に識別できる情報であれば、形式は何であってもよい。本実施形態では、機器（本実施形態においてはＮＰＶＲサービス）を特定するＵＲIである。

共通ＡＰＩ識別子は、プログラム提供装置がリソース利用要求を行うＪａｖａＳｃｒｉｐｔ ＡＰＩを識別する情報である。このＡＰＩは、情報処理装置１０１とプログラム提供装置１０２との間で、仕様が共有されていることを前提としたものである。したがって、ＡＰＩ仕様は標準化されている、もしくは、リソース提供装置に代理アクセスする情報処理装置メーカが独自仕様を定めて公開されていることを想定している。この想定のもと、ＡＰＩ識別子は、情報処理装置１０１が、各共通ＡＰＩを一意に特定できる情報であれば、どのような形式であってもよい。機器メーカの独自公開ＡＰＩであれば、公開ＡＰＩにユニークな番号を付与し、この番号をもってＡＰＩ識別子としてもよい。本実施形態では、ＡＰＩのメソッド文字列（クラス名.メソッド名）をＡＰＩ識別子としている（録画予約機能を持つデバイスの録画予約関数として、PVRDevice.reserve）。

機器依存ＡＰＩロケーションは、上記共通ＡＰＩに対応する、リソース提供装置個別のＡＰＩのロケーションを示す情報である。リソース提供装置毎に形式が異なっていてもよく、本実施形態においては、ＮＰＶＲサービスが提供するＷｅｂ ＡＰＩを指すＵＲＩである（http://npvr.service.com/webapi/reserve）。

機器依存ＡＰＩへの変換ルールは、共通ＡＰＩを利用したリソース利用要求（第1の形式）を、各機器依存ＡＰＩの実際のリソース利用要求（第２の形式）へと変換するための情報であり、変換部３０６が利用するものである。この変換ルール情報は、例えば、引数の順序情報、引数の形式の対応表情報、戻り値情報の形式やエラーコードの対応表情報で構成されてもよいし、内部で機器依存ＡＰＩ呼び出しに変換する当該共通ＡＰＩの実装そのものであってもよい。共通ＡＰＩ呼び出しを、機器依存ＡＰＩ呼び出しに変換可能な最低限の情報が含まれていれば、この変換ルール情報の形式は問わない。本実施形態においては、図５に例示するようにリクエストにおいては引数の変換表を、レスポンスに関しては、レスポンスコード・メッセージの形式変換表を持つものとしている。

なお、本実施形態においては、機器情報記憶部３０５が蓄積する情報は、図５の通りだが、このデータ構造に限定されるものでない。その他の情報を含むものであってもよい。例えば、機器がサポートするプロトコル依存のリソース利用に必要な情報を管理する、ＡＰＩの改訂を想定したバージョン情報を管理する、などが想定される。データベースとして別テーブルで管理してもよい。例えば、関数を束ねるクラス（オブジェクト）情報と、ＤＬＮＡのＳｅｒｖｉｃｅ情報を対応付けるなど、テーブル構成として階層構造をとってもかまわない。

変換部３０６は、前記プログラム実行部３０２から入力されたリソース利用要求を、前記機器情報記憶部３０５に蓄積された機器情報を用いて変換する。すなわち、第1の形式を有するリソース利用要求を、第２の形式に変換する。変換して生成したリソース利用要求を、前記リソース提供装置１０３に送信する。処理結果（たとえばリソース提供装置が録画予約を実行したとき、その旨を示す通知）を、前記第１通信部経由で受信すると、必要であれば、これをＪａｖａＳｃｒｉｐｔ ＡＰＩの出力形式に併せて変換し、プログラム実行部３０２へ出力する。

次に、図１、図５、図１３、図１６を用いて、本実施形態に係る情報処理装置１０１の動作について説明する。図１６は、本実施形態に係る情報処理装置を含むシステム構成要素間の基本シーケンスを示したものである。図１３は、本実施形態における変換部の処理のフローチャートである。

以下、図１６のシーケンス図をベースに処理手順を説明する。

前提としてユーザが、情報処理装置１０１上でブラウザを利用している。また、ユーザは、テレビ番組の録画予約をクラウドサービス上で実現するＮＰＶＲサービスに加入しており、情報処理装置１０１内の機器情報記憶部３０５には、リソース提供装置の機器情報が既に登録されている。

まず、ユーザが、ブラウザ経由でプログラム提供装置１０２上に展開されている電子番組表サービスにアクセスする（ステップＳ１０１）。ブラウザは、プログラム提供装置１０２にＨＴＴＰ ＧＥＴリクエストを送信し（ステップＳ１０2）、プログラム提供装置１０２は、電子番組表サービスのＷｅｂコンテンツを応答する（ステップＳ１０３）。このＷｅｂコンテンツには、前述したようにテレビ番組表が表示されており、各番組欄に「録画予約する」ボタンが配置されている。

ここで、ユーザは、録画予約したいテレビ番組の番組欄の録画予約ボタンを押下すると（ステップＳ１０４）、プログラム実行部３０２が、Ｗｅｂコンテンツに埋め込まれたリソース利用要求を含むＪａｖａＳｃｒｉｐｔコードを実行する（ステップＳ１０５）。ここで、前述のＪａｖａＳｃｒｉｐｔ ＡＰＩ（PVRDevice.reserve）が呼び出され、パラメータ情報と共に、変換部３０６に入力され、変換部３０６において、Ｗｅｂコンテンツ上のＪａｖａＳｃｒｉｐ ＡＰＩ呼び出しが、機器・サービス依存の実際のリソース利用要求（録画予約要求）へ変換される（ステップＳ１０６）。

ここで、変換部３０６の内部処理について図１３をベースに説明する。まず変換部３０６に、プログラム実行部３０２が、リソース利用要求の発生を通知する（ＡＰＩ識別情報とパラメータ情報を入力する）（ステップＳ１０６１）。変換部３０６は、ＡＰＩ識別子（ここでは、ＡＰＩ名： pvrDevice.reserve）をキーとして、機器情報記憶部３０５に、該当ＡＰＩを含む機器を問い合わせる（ステップＳ１０６２）。該当機器・サービスが存在しない場合（ステップＳ１０６３のＮＯ）、変換部３０６は、該当機器が存在しない旨をエラー応答する（ステップＳ１０６４）。ここでは、インターネット上のＮＰＶＲサービスが存在するので（ステップＳ１０６３のＹＥＳ）、このＮＰＶＲサービスの機器情報が取得される。変換部３０６は、機器情報に含まれる。

ＡＰＩのロケーション情報と、パラメータ変換情報を利用して、以下のＮＰＶＲサービスへの録画予約リクエスト（機器依存のリソース利用要求）を生成する（ステップＳ１０６５）。

続いて、変換部３０６は、生成したリソース利用要求を第１通信部３０１へ送信し（ステップＳ１０６６）、処理結果を受信（ステップＳ１０６７）、これをＪａｖａＳｃｒｉｐｔ ＡＰＩの応答メッセージに変換し（ステップＳ１０６８）、応答し（ステップＳ１０６９）、処理を終了する。なお、応答メッセージの変換は、例えば、レスポンスデータやエラーコードの変換表を、リクエストの場合と同様に、機器情報記憶部３０５に記憶しておき、これを利用して行われる。例えば、ＮＰＶＲの応答がＸＭＬ形式で、ＪａｖａＳｃｒｉｐｔＡＰＩの応答がＪＳＯＮ形式であった場合には、この形式変換を上記ステップＳ１０６８で実行する。

ここで、図１６の全体シーケンスに戻って、リソース利用要求変換以降のシーケンスについて説明する。

変換部３０６が、生成したリソース利用要求を図１３のステップＳ１０６６で第１通信部３０１に出力すると、第１通信部３０１は、これをＨＴＴＰ（Ｓ） ＧＥＴリクエストとして、リソース提供装置１０３へ送信する（ステップＳ１０７）。リソース提供装置１０３は、受信したリクエストに基づき、該当番組の録画予約を実行し（ステップＳ１０８）、結果を応答する（ステップＳ１０９）。第１通信部３０１は、受信した応答メッセージを、変換部３０６に入力する。変換部３０６は、入力された応答メッセージをＪａｖａＳｃｒｉｐｔ ＡＰＩの応答メッセージへと変換し、プログラム実行部３０２へ出力する。一方、プログラム実行部３０２は、応答メッセージをＷｅｂコンテンツ（プログラム）へ返す（ステップＳ１１０）。

プログラムは、例えば、応答メッセージが、録画予約の成功応答であった場合、例えば、「該当番組の録画予約に成功しました」等のメッセージを画面上に表示させる（ステップＳ１１１）。

以上のように、本実施形態の情報処理装置により、ＮＰＶＲサービス（リソース提供装置）にユーザが加入していることを電子番組表サービス（プログラム提供装置）に公開せずに、録画予約を実現できる。すなわち、サービス事業者にアクセス対象機器の情報を開示すること無く、サービス事業者のＷｅｂサービスと、アクセス対象機器のリソースとをマッシュアップ（連携）するサービスが可能となる。

（第２の実施形態）
次に、情報処理装置の第２の実施形態について説明する。なお、第１の実施形態との共通部分については、同一の符号を使用して説明したり、説明を省略したりする。

本実施形態の概要として、想定する具体的なユースケースについて記す。

まず、ユーザが、ＰＣで、インターネット上のサービス（前述の電子番組表サービス）のＷｅｂページを閲覧し、録画予約したい番組欄の「録画ボタン」を押下する。このボタン押下によって、閲覧中のＷｅｂページに埋め込まれたＪａｖａＳｃｒｉｐｔコードが実行され、ＰＣの内部機能としての「ＰＣ周辺ＡＶ機器での録画予約機能」が呼び出される。この内部機能の実行により、録画予約機能を搭載した宅内のデジタルテレビに、指定番組が録画される。第１の実施形態との差分は、インターネット上のＮＰＶＲサービスでなく、ホームネットワーク上のデジタルテレビに録画予約する点である。

以上のユースケースにおいては、デジタルテレビがリソース提供装置となり、ホームネットワークが、第２のネットワークとなる。以下、本実施形態の詳細について述べる。

図２は、本発明の第２の実施形態に係わる情報処理装置の機能ブロックを含むシステム構成図である。図２におけるプログラム提供装置１０２は、第１の実施形態と同一である。システム構成上の第１の実施形態との差分は、ネットワーク２０２が追加されている点と、ネットワーク２０２上にリソース提供装置１０４、１０５が配置されている点である。

ネットワーク２０２は、有線または無線のＩＰネットワーク、ＵＳＢ、ＨＤＭＩ、ＩＥＥＥ１３９４などの周辺機器接続用ネットワーク、あるいはＴｒａｎｓｆｅｒ Ｊｅｔ、赤外線等をはじめとする近距離あるいは近接無線ネットワーク、さらには、ＳＤカード、外付けＨＤＤなどのストレージ、ＣＤやＤＶＤなどのディスクメディア等、情報処理装置と情報を送受可能なあらゆるネットワーク、インタフェースである。本実施形態においては、ネットワーク２０２は、ホームネットワークを構成するＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であるものとする。

リソース提供装置１０４、１０５は、第１の実施形態におけるリソース提供装置１０３と同様のハードウェア構成である。本実施形態においては、デジタル家電、具体的には、１０４がデジタルテレビ、１０５がハードディスク・レコーダであるとする（第１の実施形態のリソース提供装置１０３は、インターネット上のサーバ装置を想定していた）。このデジタルテレビは、ＤＬＮＡの録画機能（ＳＲＳ：Ｓｃｈｅｄｕｌｅｄ Ｒｅｃｏｒｄｉｎｇ Ｓｅｒｖｉｃｅ）を備えているものとする。

次に、情報処理装置１０１は、ハードウェア構成は第１の実施形態と同様であるが、新たな機能ブロックとして、機器情報取得部３０７、第２通信部３０８、機器選択部３０９、ユーザ承認部３１０が追加されている。いずれも、ＣＰＵのプログラム実行時にＲＡＭなどの主記憶部上に生成されるものである。また、機能ブロックの追加に伴い、機器情報記憶部３０５に記憶される機器情報のデータ構成、および、変換部３０６の処理フローも追加・拡張されている。

以下、追加された各部について説明する。

機器情報取得部３０７は、ネットワーク２０２上のリソース提供装置を発見し、その機器情報を取得する。機器情報取得部３０７は、ＤＬＮＡにおけるＤｉｓｃｏｖｅｒｙ、および、Ｄｅｓｃｒｉｐｔｉｏｎステップの機能を行うものである。これは、第２通信部３０８を介して、定期的にネットワーク２０２に検索メッセージを送信するようにしてもよいし、ネットワーク２０２を常時監視し、ネットワーク２０２上を流れる公告メッセージ（ＤＬＮＡ Ａｄｖｅｒｔｉｓｅ メッセージ）を捕捉するように構成してもよいし、変換部３０６へのリソース利用要求の入力をトリガとして、変換部３０６からの要求に従って、検索メッセージを送信するように構成してもよい。本実施形態においては、機器情報取得部３０７は、変換部３０６の処理とは独立して、定期的に機器情報を収集しているものとする。

第２通信部３０８は、リソース提供装置１０４、１０５と、ネットワーク２０２上で通信する。第２通信部３０８は、後述する機器情報取得部３０７によるネットワーク２０２上のリソース提供装置発見、および、変換部３０６を介したプログラムによるリソース利用のための通信を担う。本実施形態においては、第２通信部３０８は、ＨＴＴＰクライアント、かつ、ＤＬＮＡクライアント（コントロールポイント）の通信部である。

機器選択部３０９は、リソース利用要求を送信する対象が複数見つかった場合に、機器選択用のユーザインタフェースを、プログラム実行部３０２を介して、ＧＵＩ表示部３０３に表示し、ユーザの選択結果を、同様にプログラム実行部３０２から取得し、結果を変換部３０６に入力する。

ユーザ承認部３１０は、情報処理装置１０１上のリソース（周辺機器情報）も含めて、リソース利用に関して、ユーザ許諾が必要な場合に、許諾用のユーザインタフェースを、プログラム実行部３０２を介して、ＧＵＩ表示部３０３に表示し、ユーザの承認結果を同様にプログラム実行部３０２から取得し、結果を変換部３０６に入力する。さらに、ユーザによる承認結果を記憶し、一定期間あるいは永続的に流用するように構成することも可能である。

次に、機器情報記憶部３０５のデータ構造の変更点について説明する。本実施形態におけるデータ構造の一例を図６に示す。第１の実施形態（図５）との差分は、機器名、ユーザ承認の必要有無、ユーザ承認日時、ユーザ承認結果、ユーザ承認の有効期限が追加されている点である。順に説明する。

機器名情報は、機器選択部３０９が、生成するユーザの選択インタフェースに一覧する機器名を表す表示文字列情報である。

ユーザ承認の必要有無情報は、当該リソース提供装置のリソースを利用するにあたり、情報処理装置１０１を操作するユーザの許諾を必要とするか否かを表すブール値である。

ユーザ承認日時情報は、当該リソース提供装置のリソースを利用する際に、ユーザ承認を求めた日時情報である。

ユーザ承認結果は、上記ユーザ承認の結果情報であり、許可か拒否を表すブール値である。

ユーザ承認の有効期限情報は、ユーザの承認結果が適用される期間を示す情報である。図６の例では、秒単位で指定している。有効期限情報は、負値、もしくは、0を指定すると無期限を表すなど、有限でない場合もサポートするものとする。

次に、図２、図６、図１４、図１７を用いて、本実施形態に係る情報処理装置１０１の動作について説明する。図１４は、本実施形態における変換部３０６の処理フローを表すフローチャートである。図１７は、本実施形態に係る情報処理装置を含むシステム構成要素間の基本シーケンスを示したものである。

以下、図１７のシーケンス図をベースに処理手順を説明する。

まず、ユーザが、ブラウザ経由でプログラム提供装置１０２上に展開されている電子番組表サービスにアクセスする前に、機器情報取得部３０７が、定期的にネットワーク２０２上のリソース提供装置の情報を取得している。具体的には、機器情報取得部３０７は、ＤＬＮＡのＳｅａｒｃｈメッセージを，第２通信部３０８を介して送信する（ステップＳ２０１）。ネットワーク２０２上のリソース提供装置１０４、１０５は、Ｓｅａｒｃｈメッセージを受けて、Ａｄｖｅｒｔｉｓｅメッセージを送信する（ステップＳ２０２、２０３）。このＡｄｖｅｒｔｉｓｅメッセージを受信すると、機器情報取得部３０７は、リソース提供装置１０４、１０５の存在を認識し、それぞれに対して詳細機器情報の取得要求メッセージを送信する（ステップＳ２０４，Ｓ２０６）。リソース提供装置１０４、１０５は、それぞれ機器情報を応答する（ステップＳ２０５，Ｓ２０７）。この機器情報取得シーケンス（Ｓ２０４〜Ｓ２０５，Ｓ２０６〜Ｓ２０７）は、リソース提供装置側が複数のサービスを有する場合には、複数回発生し得る。

ここで、第１の実施形態と同様に、ユーザがプログラム提供装置１０２（電子番組表サービス）にアクセスし、録画予約したい番組の録画予約ボタンを押下、Ｗｅｂコンテンツに埋め込まれたプログラムが実行される（ステップＳ２０８〜Ｓ２１２）。これは、第１の実施形態におけるステップＳ１０１〜Ｓ１０５と同様なので説明を割愛する。

ここで、変換部３０６の内部処理について図１４をベースに説明する。まず変換部３０６に、プログラム実行部３０２が、リソース利用要求の発生を通知する（ＡＰＩ識別情報とパラメータ情報を入力する）（ステップＳ２１０１）。変換部３０６は、リソース利用要求を受けると、ネットワーク２０２（ホームネットワーク）上の周辺機器情報へのアクセスに対する許諾をユーザに求めるか否かを判定する（ステップＳ２１０２）。これは、前述したように毎回許諾を求めるように構成してもよいし、有効期限を設け、期限が切れた場合に再度許諾を求めるように構成してもよいし、一度許諾されたものは初期化されない間は許諾を求めないように構成してもよい（こうした有効期限の管理はユーザ承認部３１０で管理する）。ここで許諾が必要であると判定された場合には、変換部３０６は、ユーザ承認部３１０に対して、ユーザ許諾インタフェースの表示を促す。ユーザ承認部３１０は、プログラム実行部３０２を介して、ＧＵＩ表示部３０３にユーザに承認を求めるインタフェース（ポップアップ画面など）を表示する。例えば、「Ｗｅｂページが、周辺機器情報の利用を求めていますが、よろしいですか？[ＯＫ][ＮＧ]」等の文言を表示し、ユーザの選択を促す。ユーザ承認部２１０は、ユーザの選択結果を、同様にプログラム実行部３０２を介して取得し、変換部３０６に出力する。ユーザが拒否した場合には（ステップＳ２１０４）、変換部３０６は、権限エラーが発生したものとして、プログラム実行部３０２へエラー応答を行い、処理を終了する（ステップＳ２１０５）。一方、ユーザが許可した場合には、変換部３０６は、機器情報取得部３０５から、ＡＰＩに対応するリソースを有するリソース提供装置の機器情報を取得する（ステップＳ２１０６）。ここでは、リソース提供装置１０４、１０５が、それぞれデジタルテレビ、ハードディスク・レコーダであり、共に録画機能を持っているとすると、該当機器が複数存在することになり（ステップＳ２１０９）、変換部３０６は、機器選択部３０９に、機器選択インタフェースの表示を求める。機器選択部３０９は、プログラム実行部３０２を介して、機器選択インタフェースを表示して、ユーザに機器の選択を促す（ステップＳ２１１０）。ここで、ユーザがデジタルテレビを選択したとすると、変換部３０６は、該当機器に対するアクセス許諾を求める必要があるか否かを、前述のステップＳ２１０２と同様に判定する（ステップＳ２１１１）。この判定には、機器情報記憶部３０５の該当機器の該当ＡＰＩ情報に、承諾が必要か否か、有効期限等の情報が含まれていて、これを利用するように構成してもよい。ここで必要と判定された場合には、ユーザ承認部３１０が、承認インタフェースを画面に表示し、ユーザの入力結果を、変換部３０６へ返す（ステップＳ２１１２）。ユーザが拒否した場合には、ＡＰＩ呼び出しに権限エラーを返し、終了する（ステップＳ２１０５）。他方、ユーザが許可した場合には、ＪａｖａＳｃｒｉｐｔ ＡＰＩ呼び出しを、本実施形態においては、ＤＬＮＡのＡｃｔｉｏｎコマンド（ＳＯＡＰメッセージ）に変換し、第１の実施形態における図１３のステップＳ１０６５〜Ｓ１０６９の処理を行い、結果をプログラム実行部３０２へ返す（ステップＳ２１１４）。

以上のように、本実施形態によれば、ホームネットワークに配置されているデジタル家電（リソース提供装置）の存在を含めた情報を、電子番組表サービス（プログラム提供装置）に公開せずに録画予約を実現できている。すなわち、外部Ｗｅｂサービスからの宅内機器への不正アクセスを防止するとともに、どのような機器をユーザが所有しているか、といったプライバシーに係る情報を、一切Ｗｅｂサービス側に公開することなく、Ｗｅｂサービスと宅内機器との連携、すなわち、マッシュアップサービスが実現できている。また、本実施形態によれば、こうした連携機能にかかるリソース利用に関して、ユーザの許諾に基づいて実行することが可能になっている。

（第３の実施形態）
次に、情報処理装置の第３の実施形態について説明する。なお、第１、第２の実施形態との共通部分については、同一の符号を使用して説明したり、説明を省略したりする。

本実施形態の概要は、第２の実施形態と同様であるが、リソース提供装置（デジタルテレビ）が、ユーザ認証・認可を求める点で異なる。すなわち、情報処理装置（PC）上で、リソース利用対象機器を決定した後で、デジタルテレビがユーザ認証とユーザによるアクセス認可を求める。この認可処理に関しては、ネットワーク２０１（インターネット）上のアクセス認可装置（例えば、デジタルテレビのメーカが運営するユーザサポート用サービスサイト）が代理でユーザ認証、および、ユーザによるアクセス認可を行うことも考えられるが、本実施形態では、一例として、デジタルテレビ自体がベーシック認証を行う場合を示す。情報処理装置（PC）は、デジタルテレビで発行された認証・認可が得られたことを証明する情報（以降、チケットと呼ぶ）をデジタルテレビに提示する。デジタルテレビは、提示されたチケットの正当性を確認し、ユーザ認証が成功し、かつ、ユーザによるアクセス認可が得られた情報処理装置に対してのみ、リソースを返す。

図３は、本発明の第３の実施形態に係わる情報処理装置の機能ブロックを含むシステム構成図である。システムの全体構成は、第２の実施形態と同様である。

次に、情報処理装置１０１は、ハードウェア構成は第１及び第２の実施形態と同様であるが、新たな機能ブロックとして、認証認可処理部３１１、リソース提供装置起動部３１２が追加されている。

いずれも、ＣＰＵのプログラム実行時にＲＡＭなどの主記憶部上に生成されるものである。また、機能ブロックの追加に伴い、機器情報記憶部３０５に記憶される機器情報のデータ構成、および、変換部３０６の処理フローも追加・拡張されている。

以下、追加された各部について説明する。

認証認可処理部３１１は、変換部３０６からの認証認可処理要求を受けて、機器情報記憶部３０５に記憶された、該当リソース提供装置（１０４、１０５）のアクセス認証・認可方式情報に基づき、第１通信部３０１、第２通信部３０８、ユーザ承認部３１０を利用して、リソース利用のための認証認可処理を行う。この認証認可処理は、リソース提供装置上で実行されるベーシック認証やダイジェスト認証、リソース提供装置とは異なる外部機器（アクセス認可装置）上で、代理でアクセス認可を実現するOAuth認証などを想定している。認証認可処理部３１１は、これらの認証クライアントとして振舞う。

リソース提供装置起動部３１２は、ネットワーク２０２上のリソース提供装置が、スリープ状態にある場合に、これをWake On LAN等を利用して起動し、通信可能状態に変更する。リソース利用要求の送信対象が見つからない場合に、変換部３０６によって呼び出される。

次に、機器情報記憶部３０５のデータ構造の変更点について説明する。本実施形態におけるデータ構造の一例を図７に示す。第２の実施形態（図６）との差分は、プロトコル種別、アクセス認証・認可方式識別情報、チケット情報、チケット有効期限情報、ＭＡＣアドレスが追加されている点である。順に説明する。

プロトコル種別情報は、ＤＬＮＡやＩＥＥＥ１３９４、白物家電向けのプロトコルＥＣＨＯＮＥＴ等、リソース提供装置がネットワーク２０２上でサポートしている通信プロトコル情報である。本実施形態においては、ＤＬＮＡに限定されているが、上述した以外の様々なプロトコルに対応することも想定している。機器情報取得部３０５は、其々のプロトコルに則した機器情報の収集を行う。

アクセス認証・認可方式識別情報は、ベーシック認証、ダイジェスト認証、あるいは、ＯＡｕｔｈ認証など、リソース提供装置の要求する認証方式を表す情報である。方式に複数のバージョンが存在する場合には、このバージョン情報についても合わせて記憶することも考えられる。

チケット情報は、認可が得られたことを示す情報であり、リソース提供装置に提示する情報である。これも、ライセンス情報と同様、前記アクセス認証・認可方式情報毎に必要な情報、形式は異なる。本実施形態では、チケット情報は、ＯＡｕｔｈ認証に則った、認可が与えられたことを示すものであるとする。

チケット有効期限情報は、チケットの有効期限を示す情報である。

最後に、機器のＭＡＣアドレスは、スリープ状態にある機器を起動するために利用するものである。機器識別子情報で代替できる場合には、ＭＡＣアドレスは必要ない。

本実施形態における機器情報は、以上４項目の追加で収まっているが、認証・認可方式に応じて、さらなる情報が必要な場合もあり、リソース提供装置へ情報処理装置がアクセスするために必要なアクセス認証・認可手続きに必要な様々な情報を保持し得るものとする。

次に、図３、図７、図１５、図１８を用いて、本実施形態に係る情報処理装置１０１の動作について説明する。図１５は、本実施形態における変換部３０６の処理フローを表すフローチャートである。図１８は、本実施形態に係る情報処理装置を含むシステム構成要素間の基本シーケンスを示したものである。

以下、図１８のシーケンス図をベースに処理手順を説明する。

まず、機器情報取得部３０７による機器情報の収集の手順（Ｓ３０１−Ｓ３０７）は、第２の実施形態のステップＳ２０１〜２０７と同様であるため、ここでは省略する。機器情報取得部３０７は、例えば、ＤＬＮＡ Ｄｉｓｃｏｖｅｒｙ、Ｄｅｓｃｒｉｐｔｉｏｎ ステップの手順に則って、リソース提供装置１０４、１０５の機器情報を取得し、機器情報記憶部１０７に格納する。この機器情報収集部の手順は、白物家電を対象にしたＥＣＨＯＮＥＴや、ＩＥＥＥ１３９４など、その他のプロトコルに従う場合は、各プロトコルにおける機器発見のメカニズムを用いればよい。

続く、プログラム提供装置１０２からのリソース利用プログラムを含むＷｅｂコンテンツの取得処理、ユーザがＷｅｂコンテンツ中の「録画予約」ボタンを押下することによるリソース利用プログラムの実行開始までは、第２の実施形態と同様である（Ｓ３０８〜Ｓ３１２）。ここまでは、上述の機器情報取得処理を含めて、第２の実施形態のステップＳ２０１〜Ｓ２１２に一致する。

ここで変換部３０６によるリソース利用要求変換処理（ステップＳ３１３）について、図１５を用いて説明する。第２の実施形態と同様、変換部３０６は、機器情報記憶部３０５の情報に基づいて、機器選択と、ユーザによる選択機器のリソース利用許諾までを行う（ステップＳ３１０２〜Ｓ３１１３）。これも、図１４における第２の実施形態のステップＳ２１０２〜Ｓ２１１３までに一致する。本実施形態では、リソース利用要求を機器依存の要求メッセージに変換し（ステップＳ３１１４）、機器に対して送信した後に（ステップＳ３１１５）、送信先のアドレスが解決できずに送信が失敗すると（ステップＳ３１１６）、変換部３０６は、リソース提供装置起動部３１２へ該当リソース提供装置の遠隔起動を要求する。リソース提供装置起動部３１２は、変換部３０６からの要求を受けて、該当機器に対するＷａｋｅ Ｏｎ ＬＡＮパケットを送信し、Ｅｔｈｅｒｎｅｔ（登録商標）越しに該当リソース提供装置１０４を起動する（ステップＳ３１１７）。リソース利用要求送信が成功して装置が起動するまで、再送の上限回数、再送を繰り返す。上限に達した場合には（Ｓ３１１８のＹＥＳ）、通信エラーをプログラム実行部３０２へ応答し（ステップＳ３１１９）、処理を終了する（ステップＳ３１２４）。リソース提供装置１０４へのリソース利用要求の送信が成功すると、本実施形態では、変換部３０６は、リソース提供装置からエラー応答として、アクセス認証（ベーシック認証）が必要な旨を通知される。これは、例えば、ＨＴＴＰ／１．１ ４０１ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｒｅｑｕｉｒｅｄ応答によって実現されるが、アクセス認証がベーシック認証やダイジェスト認証でない場合には、この限りではなく、独自の方法で実現されてもかまわない。他にも、機器情報記憶部３０５に、機器上でのアクセス認証・認可が必要であるか否かをあらわす情報を格納しておき、この情報に基づいて、４０１応答を受けずに認証・認可をダイレクトに実行する方法を採っても構わない。アクセス認証要求を受けると、変換部３０６は、認証認可処理部３１１に処理を要求し、認証認可処理部３１１は、認証認可処理を実行する（ステップＳ３１２０）。認証認可処理が成功すると、実際にリソース利用が行われ、変換部３０６は、受信した処理結果を変換して、プログラム実行部３０２へ応答を返し、一連の処理が完了する（ステップＳ３１２１〜ステップ３１２４）。

ここで、上述の図１５のフローチャートにおけるステップＳ３１２０における認証認可処理について、図１８のシーケンス図を利用して説明する。認証認可処理部３１１は、まず、ＨＴＴＰの４０１応答を受けて（ステップＳ３１５、Ｓ３１６）、プログラム実行部３０２を介して、リソース提供装置１０４（デジタルテレビ）上に設定されたユーザアカウントとパスワードの入力を求めるポップアップ画面を表示する。ユーザがポップアップ画面上に、ユーザアカウントとパスワードを入力すると（ステップＳ３１７）、この２値を“：”で連結しＢａｓｅ６４エンコードしたデータを認証ヘッダに指定して、送信する（ステップＳ３１８）。リソース提供装置１０４は、指定されたユーザアカウントとパスワードが正しいものであれば、認証成功の応答と共に、情報提供装置１０１からのリソース利用要求を許可するか否かを、ユーザに承諾するよう求める応答メッセージを送信する（ステップＳ３１９）。認証認可処理部３１１は、認証時と同様に、プログラム実行部３０２を介して、ユーザに認可を求めるポップアップ画面を表示する。例えば、「ＰＣからデジタルテレビへの録画予約メッセージを受け取りました。録画予約を許可しますか？[OK][NG]」といったメッセージ確認画面を表示する。ユーザがＯＫをクリックして、アクセス（すなわち、リソース利用）を許可すると（ステップＳ３２０）、このユーザによる許諾が、リソース利用装置１０４へ送信される（ステップＳ３２１）。リソース提供装置１０４は、ユーザの許諾を受けて、確認応答を返す（ステップＳ３２２）。この確認応答には、アクセス許可を示す一時的な認可情報（チケット情報）とその有効期限情報を返すように構成してもよい。本実施形態においては、チケット情報は、図７に例示した文字列情報であるものとするが、この形式はどのようなものであってもよい。また、チケット情報などの情報を応答するにあたり、応答形式は、ＨＴＴＰのレスポンスの認証認可にかかるヘッダ（Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダ）や独自拡張ヘッダに格納するようにしてもよいし、レスポンスボディにＸＭＬやＪＳＯＮ形式で格納するようにしてもよい。前者の既存ヘッダを利用する方法であれば、ポップアップ画面での認証認可時に指定したものと同じデータ（ベーシック認証であれば、ユーザID／パスワードをＢａｓｅ６４エンコードしたもの）をチケットとしてもよい。認証認可処理部３１１は、このチケット情報と有効期限情報を、変換部３０６へ返す。変換部３０６は、チケット情報と有効期限情報を、リソース利用要求メッセージに含めて送信する（ステップＳ３２３）。リソース提供装置１０４は、指定されたチケット情報を検証し、該当リソース利用要求を実行（ステップＳ３２４）、結果を応答する（ステップＳ３２５）。あとは、図１５のフローチャートのＳ３１２１からＳ３１２４と同様であり、変換部３０６が機器情報記憶部３０５に記憶された変換ルールに則って、リソース利用要求処理結果を変換し、変換結果をプログラム実行部３０２上で実行されるプログラムへ返し、当該プログラムは、結果を画面上に表示する（ステップＳ３２６、ステップＳ３２７）。

以上のように、本実施形態によれば、第１、第２の実施形態で説明した効果に加えて、情報提供装置１０１上でのリソース利用に対するユーザ承認だけでなく、リソース提供装置１０４、１０５が、ユーザ認証及び認可を要求する場合にも、プログラム提供装置によるリソース利用を実現することが可能となる。変換部３０６が、様々な機種に合わせたリソースへのアクセス認証及び認可処理を実現することにより、プログラム提供装置１０２は、個々の認証認可方式に対応する必要がない。また、この一連の認証認可プロセスは、共通ＡＰＩの呼び出しの内部処理として実行されるため、プログラム提供装置１０２が、リソースを利用するに当たって、どのような認証・認可処理が行われたのか感知することができない。つまり、本実施形態においてユーザが入力した、ユーザアカウントやパスワードの情報を知ることはできない。つまり、個々の機器がユーザ認証及び認可を要求する場合においても、これらの処理にかかるユーザの秘密情報を全くプログラム側に知らせずに、リソース利用（Ｗｅｂコンテンツと宅内機器リソースのマッシュアップサービス）を実現することが可能になっている。

（第４の実施形態）
次に、情報処理装置の第４の実施形態について説明する。なお、第１、第２、および、第３の実施形態との共通部分については、同一の符号を使用して説明したり、説明を省略したりする。

本実施形態の概要は、第３の実施形態と同様であるが、リソース提供装置（デジタルテレビ）がユーザ認証及びアクセス認可をインターネット上のサービスを利用して実施する点と、デジタルテレビに対するユーザ認証・認可が、情報処理装置１０１（ＰＣ）ではなく、プログラム提供装置１０２に対する認可を要求する点で異なる。

まず前者の差分は、デジタルテレビがユーザ認証とユーザによるアクセス認可を求める際に、第３の実施形態では、デジタルテレビ自体がベーシック認証を行うものであったのに対して、本実施形態では、ネットワーク２０１（インターネット）上のアクセス認可装置（例えば、デジタルテレビのメーカが運営するユーザサポート用サービスサイト）１０７が代理でユーザ認証、および、ユーザによるアクセス認可を行うものである点である。このとき、情報処理装置（ＰＣ）は、アクセス認可装置で発行された認証・認可が得られたことを証明する情報（以降、トークンと呼ぶ）をデジタルテレビに提示する。デジタルテレビは、提示されたトークンの正当性を確認することで、ユーザ認証が成功し、かつ、ユーザによるアクセス認可が得られた情報処理装置に対してのみ、リソースを返す。

後者の差分は、第３の実施形態が、デジタルテレビが「ＰＣからのアクセス」に対する認可を求めるものであったのに対して、本実施形態では、デジタルテレビは「電子番組表サービスからのアクセス」に対する認可を求めるものである点である。

図４は、本発明の第４の実施形態に係わる情報処理装置の機能ブロックを含むシステム構成図である。システム構成上の第２の実施形態との差分は、ネットワーク２０１上にアクセス認可装置１０７が提供されている点である。

アクセス認可装置１０７は、プログラム提供装置１０２と同様、通常のコンピュータのハードウェア構成となっており、ここではデータセンター等で運用されるサーバ装置である。本実施形態におけるアクセス認可装置１０７は、前述したように、リソース提供装置１０４（デジタルテレビ）を製造販売するメーカが運用し、ユーザサポート・サービスを提供しているものとする。このサービスは、製品を購入したユーザに対して、購入した製品情報（型名、製造番号等）と共にユーザ登録を行ってもらうことで、製品に対するアップデート情報などを提供すると共に、本実施形態が実現するようなインターネット上のWebサイトからの製品内部のリソース利用に対するアクセス認証・認可サービスを提供するものとする。

情報処理装置１０１は、ハードウェア構成及び機能ブロック構成共に、第３の実施形態と基本的に同様である。

一方、リソース提供装置１０４は、第２、第３の実施形態と同様のハードウェア構成をとるが、前述したようにＰＣ（情報処理装置１０１）ではなく、電子番組表サービス（プログラム提供装置１０２）に対するアクセス認可を求めるものであり、通信部４０１、リソース提供部４０２、アクセス要求元情報記憶部４０３、アクセス制御部４０４、承認結果検証部４０５を有する。いずれも、ＣＰＵのプログラム実行時にＲＡＭなどの主記憶部上に生成されるものである。以下、各部について説明する。

通信部４０１は、ネットワーク２０２上で、情報処理装置１０１と通信する。通信部４０１は、情報処理装置１０１上の機器情報取得部３０７によるネットワーク２０２上のリソース提供装置発見、および、変換部３０６を介したプログラムによるリソース利用のための要求、および、リソース利用に伴う認証認可要求を受け付ける。本実施形態においては、通信部４０１は、ＨＴＴＰサーバ、かつ、ＤＬＮＡデバイスの通信部である。

リソース提供部４０２は、通信部４０１を介して受信したリソース利用要求に対応するリソースを提供する。

アクセス要求元情報記憶部４０３は、アクセス要求元の情報、すなわち、情報処理装置１０１ではなく、リソース利用要求プログラムを埋め込んだＷｅｂコンテンツを提供するプログラム提供装置１０２に係る情報を記憶する。本実施形態におけるアクセス元情報記憶部４０３に蓄積される情報のデータ構造は、図９に例示するように、アクセス要求元識別子、アクセス対象リソース識別子、ユーザ識別子、アクセス可否情報、ユーザ承認結果、認可情報、認可有効期限で構成されている。

アクセス要求元識別子は、プログラム提供装置１０２の識別情報である。本実施形態では、電子番組表サービスのＵＲＬである。

アクセス対象リソース識別子は、アクセス要求元が利用要求するリソースを識別する情報である。アクセス対象リソース識別子は、機器情報記憶部３０５における機器依存ＡＰＩロケーションに相当する情報である。

ユーザ識別子は、リソース提供装置１０４上のユーザを識別する情報である。リソース提供装置にユーザアカウントが存在しない場合には、この情報は含まなくても構わない。

アクセス可否情報は、ユーザ（リソース提供装置所有者）による、当該アクセス要求元による当該リソースの利用の可否を示す情報である。許可か拒否の二値、もしくは、この二値に未承認を加えた三値をとる。この情報は、装置外部のアクセス認可装置を想定する場合に、このアクセス認可装置におけるアクセス可否を示すものを想定しており、外部アクセス認可装置を想定しない場合には必要ない。

ユーザ承認結果は、ユーザ（リソース提供装置所有者）によるアクセス可否の判断結果を示す情報であり、許可か拒否の二値、もしくは、これに未承認を加えた三値をとる。

認可情報は、アクセス可否情報と同様、外部のアクセス認可装置を想定する場合に、外部アクセス認可装置が認可を与えたことを示すチケット情報である。これは、情報処理装置１０１上の機器情報記憶部３０５上のデータ（図８参照）に含まれるチケット情報である。リソース提供装置１０４は、この情報と、情報処理装置１０１がリソース利用要求と共に提示するチケット情報とのマッチングをとり、アクセス可否を判定する。

認可有効期限は、上記認可情報の有効期限を示すものである。これもアクセス可否判定に利用される。

アクセス制御部４０４は、リソース利用要求に含まれるアクセス要求元情報を取得し、アクセス可否情報が未設定のアクセス要求元からのアクセスを受信した場合には、情報処理装置１０１に対して、ユーザのアクセス承認を要求する。アクセス制御部４０４は、情報処理装置からのユーザによるアクセス可否の承認結果を、通信部４０１を介して受信し、アクセス要求元情報記憶部４０３に結果を格納すると共に、承認結果を利用してアクセス制御を行う。

承認結果検証部４０５は、リソース提供装置１０４が、アクセス認可に外部装置（アクセス認可装置１０７）を利用する場合に、このアクセス認可装置１０７から認可情報（チケット情報）を取得し、取得した許可情報を、情報処理装置１０１からのリソース利用要求に含まれるチケット情報と比較することで、承認が実際に得られたか否かを検証する。

次に、情報処理装置１０１の差分について説明する。本実施形態は、第３の実施形態と、変換部３０６の内部処理、および、機器情報記憶部３０５のデータ構造において異なっている。

まず、変換部３０６は、第１から第３までの実施形態においては、機器情報記憶部３０５に記憶された変換ルールに則って、リソース利用リクエスト及びレスポンスの変換を行うものであったが、本実施形態においては、変換部３０６は、各リソース提供装置が提供する変換用プログラム（変換機構）をロードするだけのものとなっている。

次に、機器情報記憶部３０５のデータ構造の変更点について説明する。本実施形態におけるデータ構造の一例を図８に示す。第３の実施形態（図７）との差分は、プロトコル種別および変換ルール情報を含まない点、変換ルールの代わりに変換プログラムのロケーションを含む点、ライセンス情報（ライセンス情報秘密鍵）が追加されている点である。追加された項目について順に説明する。

まず、変換プログラムのロケーション情報は、第１〜３の実施形態で述べた変換ルールではなく、変換コード自体を含んでいる。このため、変換部３０６は、ルールを解釈して変換する、という処理を行う必要がなく、変換プログラムをそのまま適用すれば、共通ＡＰＩ呼び出しが、適切な機器依存のリソース利用要求に変換され、取得した処理結果の変換までも行える。

ライセンス情報（ライセンス情報秘密鍵）は、アクセス認可を得るために必要な、情報処理装置１０１が認可を得る権利を持っていることを示す情報である。前記アクセス認証・認可方式情報毎に必要な情報、形式は異なる。例えば、Ｘ５０９クライアント証明書であってもよいし、あるいは、アクセス認可装置１０４がクライアント毎に発行するクライアント識別情報と秘密鍵のペア情報であってもよい。形式は問わない。本実施形態では、ＯＡｕｔｈ認証に則った、クライアント・クレデンシャル（クライアント識別情報および秘密鍵情報）であるものとする。

チケット情報は、認可が得られたことを示す情報であり、リソース提供装置に提示する情報である。これも、ライセンス情報と同様、前記アクセス認証・認可方式情報毎に必要な情報、形式は異なる。本実施形態では、チケット情報は、ＯＡｕｔｈ認証に則った、認可が与えられたことを示すトークン情報であるものとする。

チケット有効期限情報（アクセス認可の有効期限）は、チケットの有効期限を示す情報である。本実施形態においては、チケット有効期限情報は、ＯＡｕｔｈ認証に則った、トークンの有効期限情報である。

最後に、機器のＭＡＣアドレスは、スリープ状態にある機器を起動するために利用するものである。機器識別子情報で代替できる場合には、ＭＡＣアドレスは必要ない。

なお、認証・認可方式に応じては、さらなる情報が必要な場合もある。この場合、機器情報は、リソース提供装置へ情報処理装置がアクセスするために必要なアクセス認証・認可手続きに必要な様々な情報を保持し得るものとする。

次に、図４、図８、図９、図１０、図１１、図１２、図１９を用いて、本実施形態に係る情報処理装置１０１及びリソース提供装置１０４の動作について説明する。図８は、本実施形態における機器情報記憶部３０５に記憶される機器情報のデータ構成の一例を示すものである。図１０は、本実施形態におけるプログラム提供装置１０２が提供するプログラム（Webコンテンツ）の概略を示すものである。図１１は、変換部３０６が提供するリソース利用APIを定義したライブラリ（擬似コード）の一例を示すものである。図１２は、リソース提供装置１０４が提供する変換プログラム（擬似コード）の一例を示すものである。図１９は、本実施形態に係る情報処理装置を含むシステム構成要素間の基本シーケンスを示したものである。なお、変換部３０６の処理は、第３の実施形態と同様であり、図１５に示すフローチャートに従うものとする。

以下、図１９のシーケンス図をベースに処理手順を説明する。なお、第３の実施形態との差分のみについて説明する。

まず、機器情報取得ステップ（Ｓ４０１〜Ｓ４１０）での差分は、情報処理装置１０１は、各リソース提供装置１０４、１０５の情報を取得すると、変換部３０５が、機器情報に含まれる、機器識別情報、変換プログラムのロケーション情報に基づき、自身が提供するリソース利用API定義ライブラリ（図１１）に、各変換プログラムを動的にロードするコードを追加する。具体的には、リソース提供装置１０４の場合は、８行目から１２行目のコードを、リソース提供装置１０５の場合は、１３行目から１６行目のコードを、追加する。変換部３０６が実施する処理は以上である。

続いて、ユーザが、プログラム提供装置１０２が提供する電子番組表サービスにアクセスし、ユーザが特定番組の録画予約ボタンを押下する（ステップＳ４１１）。

ここで、電子番組表サービスのWebコンテンツの構成の概要について、図１０をベースに簡単に説明しておく。図１０に示すように、プログラム提供装置１０２が提供するＷｅｂコンテンツは、リソースを利用する（ここでは宅内のテレビの録画予約機能を呼び出すreserve関数を呼び出す）プログラムファイルuseResource.jsと、このuseResource.jsが呼び出すreserve関数を定義したライブラリファイルdeviceAPI.jsを、Ｗｅｂコンテンツ内で呼び出している（それぞれ、図１０の７行目、１０行目）。前者のuseResource.jsは、プログラム提供装置１０２上に配置されており、後者のdeviceAPI.jsは、本実施形態においては、情報処理装置１０１内に配置されている。前述したように、後者のファイルは、機器の発見や離脱に伴い、動的に変換部３０６によって書き換えられるものである。

次に、ステップＳ４１３の変換部３０６における変換処理について説明する。処理フロー自体は第３の実施形態と同様であり、図１５に従うものであるが、主に変換処理自体（図１５のステップＳ３１２１−Ｓ３１２３）が異なっている。これは、第３の実施形態が、変換ルールに則って、変換部３０６によって行われるものであったのに対して、本実施形態においては、各リソース装置が提供する変換プログラムが変換処理を行うためである。

変換処理について図１１、図１２、図１５を用いて説明する。図１５におけるリソース利用要求入力（Ｓ３１０１）は、情報処理装置１０１が提供するリソース利用ＡＰＩ（reserve関数）の呼び出しに対応する。続くステップＳ３１０２〜Ｓ３１２０までの処理が、内部のprepare()関数（図１１の4行目）の内部処理に対応する。ここで、機器の特定と認証認可処理までが完了しており、ライブラリ（deviceApi.js）側に、リソース利用対象機器の識別情報が返される。ここではリソース提供装置１０４のリソースを利用するので、変換部３０６が組み込んだ、図１１の８行目から１２行目のコードが呼び出され、リソース提供装置上の変換プログラム（http://192.168.0.10:8888/upnp/control/pvr-srs-ctrl-js/transcode.js）がロードされ、利用される。図１２に示すように、リクエストの変換、送信、レスポンスの受信、変換までの全ての処理（図１５のステップＳ３１２１−Ｓ３１２３）が、この変換プログラム内で実行される。

続いて、情報処理装置１０１上の変換部３０６は、リソース利用要求プログラムの提供元の電子番組表サービスの識別情報（図９よりhttp://www.iepg.com）を含む、リソース利用要求を、上記変換コードの呼び出しによってリソース提供装置１０４に送信する（ステップＳ４１４）。リソース提供装置上の通信部４０１は、リソース利用要求メッセージを受信し、これをアクセス制御部４０４へ渡す。アクセス制御部４０４は、アクセス要求元情報記憶部４０３の該当情報を参照し、アクセス可否情報が未設定であることを検知する。アクセス制御部４０４は、アクセス認可装置１０７上でのアクセス認可が必要であると判定し、エラー応答として、アクセス認証（ＯＡｕｔｈ認証）が必要な旨を通知する。具体的には、ネットワーク２０１上のアクセス認可装置１０７上のアクセス承認用ページへとリダイレクトするように要求する。これは、例えば、ＨＴＴＰ／１．１ ３０２ Ｆｏｕｎｄ応答によって実現される（ステップＳ４１５）。このとき、アクセス制御部４０４は、リダイレクト先のＵＲＬに、再リダイレクト（アクセス認可装置１０７からリソース提供装置１０４へリダイレクト）するためのコールバックＵＲＬ、および、リソース提供装置の識別情報（ＵＵＩＤやＭＡＣアドレス、シリアル番号＋モデル番号など）を含める。

情報処理装置１０１上の変換部３０６は、リダイレクト要求を受信すると、認証認可処理部３１１に認証認可を要求する（ステップＳ４１６）。認証認可処理部３１１は、ＨＴＴＰレスポンス（リダイレクト要求）に従い、アクセス認可装置１０７上のアクセス承認画面にアクセスする（ステップＳ４１７）。ここでは、ユーザが、アクセス認可装置１０７（機器メーカのユーザサポート・サービス）へログインを行っていない状態であり、ユーザ認証画面へさらにリダイレクトされる（ステップＳ４１８）。認証認可処理部４０２は、プログラム実行部３０２を介して、このユーザ認証画面をポップアップ表示する。ユーザが、アクセス認可装置１０７（機器メーカのユーザサポート・サービス）上のユーザアカウントとパスワードを入力し、ＯＫボタンを押下すると（ステップＳ４１９）、認証認可処理部３１１は、認証要求メッセージをアクセス認可装置１０７へ送信し（ステップＳ４２０）、認証結果を受信する（ステップＳ４２１）。受信した認証結果は、最初にアクセス要求したアクセス承認画面であり、認証認可処理部４１１は、これもポップアップ画面として表示する。この画面には、例えば「電子番組表サービスＸがデジタルテレビＹへ録画予約を求めていますが許可しますか？[ＯＫ][ＮＧ]」等のメッセージが表示される。ここで、ユーザがＯＫボタンを押下すると（ステップＳ４２２）、認証認可処理部３１１が、アクセス認証要求メッセージを送信し（ステップＳ４２３）、アクセス認可装置１０７から応答を受信する（ステップＳ４２４）。この応答メッセージは、ステップＳ４１５で、リソース提供装置１０４が指定したコールバックＵＲＬに対するリダイレクトを要求する（ＨＴＴＰ／１．１ ３０２ Ｆｏｕｎｄ）。この応答メッセージには、アクセス認可を示すチケット情報（もしくは、チケット情報を取得するためのＶｅｒｉｆｉｃａｔｉｏｎ Ｃｏｄｅ）が含まれている。本実施形態では、直接チケットが含まれているものとするが、Ｖｅｒｉｆｉｃａｔｉｏｎ Ｃｏｄｅである場合、これをＨＴＴＰＳなどの安全な通信経路を用いて、アクセス認可装置１０７に提示し、改めてチケットを取得するように構成してもよい。また、このとき認証認可処理部３１１は、機器情報記憶部３０５に記憶されたライセンス情報を利用して、アクセス認可を得る権利を持っていることを、アクセス認可装置１０７に提示するように構成してもよい。

認証認可処理部３１１は、コールバックＵＲＬ（すなわち、リソース利用のためのＷｅｂ ＡＰＩ呼び出し）へリクエストを送信する（ステップＳ４２５）。このリクエストメッセージには、アクセス要求元情報に加え、チケット情報が含まれているものとする。このチケット情報は、チケットを表す文字列データと共に、チケットの正当性を証明する秘密情報のハッシュ値が含まれるように構成してもよい。

ここで、リソース提供装置１０４上のアクセス制御部４０４は、受信したリソース利用要求に含まれる、アクセス要求元情報とチケット情報を抽出する。この時点で、チケット情報が、アクセス要求元情報記憶部４０３に記憶されていない場合、アクセス制御部４０４は、承認結果検証部４０５に、取得したチケットの正当性検証を要求する。承認結果検証部４０５は、情報処理装置１０１を介して、アクセス認可装置１０７に、当該機器に対するアクセス承認結果の要求メッセージを送信する（ステップＳ４２６）。なおリソース提供装置１０４がネットワーク２０１上にあるときは、当該要求メッセージを直接、送信する。アクセス認可装置１０７は、要求を受けて、要求元のリソース提供装置に係る承認結果情報を応答する（ステップＳ４２７）。この応答に、ステップＳ４２５で受信したのと同じチケットが含まれていた場合、チケットを正当なものであるとして、アクセス制御部４０４に応答を返すと共に（ステップＳ４２８）、認可に係る情報（図９に一覧された属性情報）をアクセス要求元情報記憶部４０３に記憶する。アクセス制御部４０４は、この応答に基づき、アクセスを許可し、リソース提供部４０２が、アクセス対象リソースを提供する（ステップＳ４２９、Ｓ４３０）。

以降は、リソース利用要求処理結果に対応して、変換部３０６が機器情報記憶部３０５に記憶された変換コードを呼び出して、変換コード（変換結果）をプログラム実行部３０２上で実行されるプログラムへ返し、当該プログラムは、結果を画面上に表示する（ステップＳ４３１、ステップＳ４３２）。

以上のように、本実施形態によれば、第３の実施形態で説明した効果に加えて、リソース提供装置１０４、１０５がアクセス要求元（プログラム提供装置１０１）に応じたアクセス制御を行うことが可能となっている。また、リソース提供装置上のみならず、外部のアクセス認可サービスを利用したアクセス認可に基づく、アクセス制御を行うことも可能であることを示している。また、この一連の認証認可プロセスは、第１〜３の実施形態と同様、共通ＡＰＩの呼び出しの内部処理として実行されるため、プログラム提供装置１０２が、リソースを利用するに当たって、どのような認証・認可処理が行われたのか検知することができない。つまり、本実施形態においてユーザが入力した、ユーザアカウントやパスワードの情報を知ることはできない。つまり、個々の機器がユーザ認証及び認可を、外部の認証認可サービスを利用して要求する場合にであっても、これらの処理にかかるユーザの秘密情報を全くプログラム側に知らせずに、リソース利用（Ｗｅｂコンテンツと宅内機器リソースのマッシュアップサービス）を実現できている。

また、本実施形態においては、変換処理自体を、各リソース提供装置が提供する形式を採っているため、単なる変換表に基づく静的なマッピングにとらわれないより複雑で柔軟な処理が可能となる。また、このプログラムの配置場所が、リソース提供装置上だけでなく、リソース提供装置のメーカサイトに配置してもよく、変更やデプロイが容易であるという利点もある。

１０１ 情報処理装置
１０２，プログラム提供装置
１０３，１０４，１０５リソース提供装置
１０７ アクセス認可装置
２０１，２０２ ネットワーク
３０１ 第１通信部
３０２ プログラム実行部
３０３ ＧＵＩ表示部
３０４ ＧＵＩ操作部
３０５ 機器情報記憶部
３０６ 変換部
３０７ 機器情報取得部
３０８ 第２通信部
３０９ 機器選択部
３１０ ユーザ承認部
３１１ 認証認可処理部
３１２ リソース提供装置起動部
４０１ 通信部
４０２ リソース提供部
４０３ アクセス要求元情報記憶部
４０４ アクセス制御部
４０５ 承認結果検証部

Claims (16)

1. プログラム提供装置およびリソース提供装置とネットワークを介して通信する情報処理装置であって、
   前記プログラム提供装置から、サービスを実行するための要求を含むプログラムを受信し、前記要求は、第１の形式で記述され、前記サービスを実行するために用いられるリソースを提供するリソース提供装置の識別子の指定を含まない、通信部と、
   前記プログラムを実行し、前記要求を抽出するプログラム実行部と、
   前記プログラム実行部で抽出した前記要求と、要求とリソースとリソース提供装置の識別子である装置識別子とを関連づけたデータとに基づき、前記サービスを実行するために用いられるリソースを提供するリソース提供装置と、当該リソース提供装置で前記サービスを実行するために用いられるリソースを特定し、前記要求を、前記特定したリソース提供装置によって解釈可能な第２形式で記述された、前記特定したリソースの利用要求に変換する変換部と、
   を備え、
   前記通信部は、前記変換部により変換された前記利用要求を、前記特定したリソース提供装置に送信し、前記特定したリソース提供装置から前記利用要求の処理結果を受信し、
   前記変換部は、前記通信部で受信された処理結果を、前記第１の形式に変換し、
   前記プログラム実行部は、前記変換部により変換された処理結果に応じた動作を行う
   情報処理装置。
2. ユーザインタフェースと、
   前記リソースを提供するリソース提供装置が複数存在する場合、利用するリソース提供装置をユーザに、前記ユーザインタフェースを介して選択させる機器選択部をさらに備え、
   前記変換部は、前記ユーザによって選択されたリソース提供装置を特定する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記複数のリソース提供装置は、前記第２の形式として、それぞれ異なる形式に対応し、
   前記変換部は、特定したリソース提供装置が解釈可能な形式に、前記第1形式を変換する
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記ネットワーク上に存在するリソース提供装置を発見し、発見したリソース提供装置の機器情報を取得する機器情報取得部と、
   前記機器情報取得部により取得された機器情報を記憶する機器情報記憶部と、をさらに備える
   請求項１ないし３のいずれか一項に記載の情報処理装置。
5. 前記機器情報記憶部は、前記リソース提供装置のプロトコル情報を記憶し、
   前記機器情報取得部は、前記プロトコル情報を利用して前記機器情報を収集する
   ことを特徴とする請求項４に記載の情報処理装置。
6. 前記機器情報へのアクセスに対するユーザ承認を得るユーザ承認部をさらに備え、
   前記変換部は、前記ユーザにより承認が得られたときのみ前記機器情報へアクセスする
   ことを特徴とする請求項４または５に記載の情報処理装置。
7. 前記リソース提供装置へのアクセスに対するユーザ承認を得るユーザ承認部をさらに備え、
   前記変換部は、前記ユーザにより承認が得られたときのみ、前記リソース提供装置へ前記リソースの利用要求を送信する
   ことを特徴とする請求項１ないし６のいずれか一項に記載の情報処理装置。
8. 前記リソース提供装置のリソース利用に必要な認証・認可方式および認証用情報を記憶する機器情報記憶部と、
   前記リソース提供装置が要求する方式に則して、前記リソース提供装置との間で認証・認可処理を実行する認証認可処理部と
   をさらに備えたことを特徴とする請求項１ないし７のいずれか一項に記載の情報処理装置。
9. 前記認証認可処理部は、前記プログラム提供装置による前記リソースの利用を許可するかを否かユーザに問い合わせ、問い合わせの結果を前記特定したリソース提供装置に通知する
   ことを特徴とする請求項１ないし８のいずれか一項に記載の情報処理装置。
10. 前記プログラム提供装置と第1ネットワークを介して接続され、前記リソース提供装置と前記第1ネットワークと異なる第２ネットワークを介して接続され、
    前記通信部は、第1通信部と、第２通信部とを含み、
    前記第1通信部は、前記第1ネットワークを介して前記プログラム提供装置と通信し、
    前記第２通信部は、前記第２ネットワークを介して前記リソース提供装置と通信する
    ことを特徴とする請求項１ないし９のいずれか一項に記載の情報処理装置。
11. 前記特定したリソース提供装置への前記リソースの利用要求の送信が失敗した場合に、遠隔起動用通信メッセージを送信して、前記特定したリソース提供装置を起動するリソース提供装置起動部をさらに備えたこと、
    を特徴とする請求項１ないし１０のいずれか一項に記載の情報処理装置。
12. 前記第１形式および前記第２形式間の変換機構を格納した機器情報記憶部をさらに備え、
    前記変換部は、前記変換機構に基づき、前記要求の変換を行う
    ことを特徴とする請求項１ないし１１のいずれか一項に記載の情報処理装置。
13. 前記変換機構は、前記第1形式および前記第２形式間の変換方法を定義した変換ルールであり、
    前記変換部は、前記変換ルールに従って、前記要求の変換を行う
    ことを特徴とする請求項１２に記載の情報処理装置。
14. 前記変換機構は、プログラムであり、
    前記変換部は、前記プログラムを前記機器情報記憶部から読み出して実行することにより、前記要求の変換を行う
    ことを特徴とする請求項１２に記載の情報処理装置。
15. 前記通信部は、前記リソース提供装置または外部のサーバから前記プログラムを受信し、
    前記機器情報記憶部は、前記通信部で受信された前記プログラムを記憶する
    ことを特徴とする請求項１４に記載の情報処理装置。
16. 請求項１ないし１５のいずれか一項に記載の情報処理装置と、
    リソースを提供するリソース提供装置であって、
    情報処理装置から、前記リソースへのアクセス要求元の情報を含む、前記リソースの利用要求を受信する通信部と、
    前記アクセス要求元が前記リソースを利用することをユーザが承認するかの問い合わせを、前記情報処理装置に送信し、前記情報処理装置からユーザ承認の結果を受信する、アクセス制御部と、
    前記ユーザ承認の結果の正当性を、外部のアクセス認可装置に問い合わせることで、検証する承認結検証部と、
    前記承認結果が正当と判断されたとき、前記リソースを提供するリソース提供部と
    を備えたリソース提供装置と
    を備えた情報処理システム。

Images