"プログラム提供装置およびリソース提供装置とネットワークを介して通信する情報処理装置であって、前記プログラム提供装置から、第1の形式で記述されたリソースの利用要求を含むプログラムを受信する通信部と、前記プログラムを実行し、前記リソースの利用要求を抽出するプログラム実行部と、前記利用要求に示されるリソースを提供するリソース提供装置を特定し、前記利用要求を、特定したリソース提供装置によって解釈可能な第2形式に変換する変換部と、を備え、前記通信部は、前記変換部により変換された利用要求を前記特定したリソース提供装置に送信し、前記特定したリソース提供装置から前記利用要求の処理結果を受信し、前記変換部は、前記通信部で受信された処理結果を、前記第1の形式に変換し、前記プログラム実行部は、前記変換部により変換された処理結果に応じた動作を行う情報処理装置。リソースの識別情報と、リソース提供装置との対応情報を記憶する機器情報記憶部をさらに備え、前記変換部は、前記対応情報に基づき、前記リソースを提供するリソース提供装置を特定する、ことを特徴とする請求項1に記載の情報処理装置。ユーザインタフェースと、前記リソースを提供するリソース提供装置が複数存在する場合、利用するリソース提供装置をユーザに、前記ユーザインタフェースを介して選択させる機器選択部をさらに備え、前記変換部は、前記ユーザによって選択されたリソース提供装置を特定することを特徴とする請求項1または2に記載の情報処理装置。前記複数のリソース提供装置は、前記第2の形式として、それぞれ異なる形式に対応し、前記変換部は、特定したリソース提供装置が解釈可能な形式に、前記第1形式を変換することを特徴とする請求項3に記載の情報処理装置。前記ネットワーク上に存在するリソース提供装置を発見し、発見したリソース提供装置の機器情報を取得する機器情報取得部と、前記機器情報取得部により取得された機器情報を記憶する機器情報記憶部と、をさらに備え、前記機器情報に基づき、前記リソースを提供するリソース提供装置を特定することを特徴とする請求項1ないし4のいずれか一項に記載の情報処理装置。前記機器情報記憶部は、前記リソース提供装置のプロトコル情報を記憶し、前記機器情報取得部は、前記プロトコル情報を利用して前記機器情報を収集することを特徴とする請求項5に記載の情報処理装置。前記機器情報へのアクセスに対するユーザ承認を得るユーザ承認部をさらに備え、前記変換部は、前記ユーザにより承認が得られたときのみ前記機器情報へアクセスすることを特徴とする請求項5または6に記載の情報処理装置。前記リソース提供装置へのアクセスに対するユーザ承認を得るユーザ承認部をさらに備え、前記変換部は、前記ユーザにより承認が得られたときのみ、前記リソース提供装置へ前記リソースの利用要求を送信することを特徴とする請求項1ないし7のいずれか一項に記載の情報処理装置。前記リソース提供装置のリソース利用に必要な認証認可方式および認証用情報を記憶する機器情報記憶部と、前記リソース提供装置が要求する方式に則して、前記リソース提供装置との間で認証認可処理を実行する認証認可処理部とをさらに備えたことを特徴とする請求項1ないし8のいずれか一項に記載の情報処理装置。前記認証認可処理部は、前記プログラム提供装置による前記リソースの利用を許可するかを否かユーザに問い合わせ、問い合わせの結果を前記特定したリソース提供装置に通知することを特徴とする請求項1ないし9のいずれか一項に記載の情報処理装置。前記プログラム提供装置と第1ネットワークを介して接続され、前記リソース提供装置と前記第1ネットワークと異なる第2ネットワークを介して接続され、前記通信部は、第1通信部と、第2通信部とを含み、前記第1通信部は、前記第1ネットワークを介して前記プログラム提供装置と通信し、前記第2通信部は、前記第2ネットワークを介して前記リソース提供装置と通信することを特徴とする請求項1ないし10のいずれか一項に記載の情報処理装置。前記特定したリソース提供装置への前記リソースの利用要求の送信が失敗した場合に、遠隔起動用通信メッセージを送信して、前記特定したリソース提供装置を起動するリソース提供装置起動部をさらに備えたこと、を特徴とする請求項1ないし11のいずれか一項に記載の情報処理装置。前記第1形式および前記第2形式間の変換機構を格納した機器情報記憶部をさらに備え、前記変換部は、前記変換機構に基づき、前記利用要求の変換を行うことを特徴とする請求項1ないし12のいずれか一項に記載の情報処理装置。前記変換機構は、前記第1形式および前記第2形式間の変換方法を定義した変換ルールであり、前記変換部は、前記変換ルールに従って、前記利用要求の変換を行うことを特徴とする請求項13に記載の情報処理装置。前記変換機構は、プログラムであり、前記変換部は、前記プログラムを前記機器情報記憶部から読み出して実行することにより、前記利用要求の変換を行うことを特徴とする請求項13に記載の情報処理装置。前記通信部は、前記リソース提供装置または外部のサーバから前記プログラムを受信し、前記機器情報記憶部は、前記通信部で受信された前記プログラムを記憶することを特徴とする請求項15に記載の情報処理装置。リソースを提供するリソース提供装置であって、情報処理装置から、前記リソースへのアクセス要求元の情報を含む、前記リソースの利用要求を受信する通信部と、前記アクセス要求元が前記リソースを利用することをユーザが承認するかの問い合わせを、前記情報処理装置に送信し、前記情報処理装置からユーザ承認の結果を受信する、アクセス制御部と、前記ユーザ承認の結果の正当性を、外部のアクセス認可装置に問い合わせることで、検証する承認結検証部と、前記承認結果が正当と判断されたとき、前記リソースを提供するリソース提供部とを備えたリソース提供装置。請求項1ないし16のいずれか一項に記載の情報処理装置と、請求項17に記載のリソース提供装置と、を備えた情報処理システム。上述したように、従来技術には、サービス事業者がアクセス対象機器の存在を知る必要がある、という問題があった。本発明の一側面は、上記従来技術の問題点を解決するためになされたものであって、プログラム提供装置を用いてサービスを提供するサービス事業者にリソース提供装置の情報を開示すること無く、当該サービスとリソース提供装置のリソースとをマッシュアップ連携することを実現する情報処理装置、リソース提供装置および情報処理システムを提供することを目的とする。本発明の一態様としての情報処理装置は、プログラム提供装置およびリソース提供装置とネットワークを介して通信する情報処理装置であって、通信部と、プログラム実行部と、変換部と、を備える。前記通信部は、前記プログラム提供装置から、第1の形式で記述されたリソースの利用要求を含むプログラムを受信する。前記プログラム実行部は、前記プログラムを実行し、前記リソースの利用要求を抽出する。前記変換部は、前記利用要求に示されるリソースを提供するリソース提供装置を特定し、前記利用要求を、特定したリソース提供装置によって解釈可能な第2形式に変換する。前記通信部は、変換された利用要求を前記特定したリソース提供装置に送信し、前記リソース提供装置から、前記利用要求の処理結果を受信する。前記変換部は、前記通信部で受信された処理結果を、前記第1の形式に変換する。前記プログラム実行部は、前記変換部により変換された処理結果に応じた動作を行う。以下、本発明の実施形態について説明する。第1の実施形態本実施形態の概要として、想定する具体的なユースケースについて記す。まず、ユーザが、PCで、インターネット上のサービス前述の電子番組表サービスのWebページを閲覧し、録画予約したい番組欄の録画ボタンを押下する。このボタン押下によって、閲覧中のWebページに埋め込まれたJavaScriptコードが実行され、PCの内部機能としてのPC周辺AV機器での録画予約機能が呼び出される。PCの内部処理として、実際にはインターネット上のNPVRNetworkPersonalVideoRecorderネットワーク録画予約クラウドサービスが利用され、クラウドサービス上に指定番組が録画される。以上のユースケースにおける、PCが本実施形態にかかる情報処理装置であり、電子番組表サービスがプログラム提供装置、NPVRサービスがリソース提供装置となる。以下、本実施形態の詳細について述べる。図1は、本発明の第1の実施形態に係わる情報処理装置の機能ブロックを示すシステム構成図である。第1の実施形態に係るシステムは、情報処理装置101と、プログラム提供装置102と、リソース提供装置103で構成される。情報処理装置101、プログラム提供装置102、リソース提供装置103の三者は、ネットワーク201を介して接続されている。次に、本実施形態のシステムを構成するネットワーク及び装置について説明する。ネットワーク201は、インターネット、または、品質保証された閉域網であるNGNNextGenerationNetworkなどのIPInternetProtocolネットワークである。本実施形態においては、ネットワーク201は、インターネットであるとする。情報処理装置101は、CPU、主記憶、補助記憶で構成され、ディスプレイと、キーボード等の入出力インタフェースとを備える、通常のコンピュータのハードウェア構成となっている。具体的には、PC、スマートフォン、スレートデバイスなどである。本実施形態において、情報処理装置101は、ラップトップPCであるとする。プログラム提供装置アクセス要求元102は、情報処理装置101と同じく、通常のコンピュータのハードウェア構成となっている。具体的には、デジタル家電、PC、サーバ装置である。本実施形態においては、データセンター等で運用されるサーバ装置であり、インターネット上でWebサービスサイトを提供している。具体的には、前述した電子番組表サービスを提供しているものとする。このサービスは、電子番組表を閲覧するユーザが有する録画予約可能な機器もしくは外部サービスに対して、録画予約が行えるものを想定する。なお、プログラム提供装置102が提供するプログラムは、HTMLHyperTextMarkupLanguageドキュメントに埋め込まれたJavaScriptプログラムである。あるいは、Flashコンテンツであってもよいし、既存のWebコンテンツに限定されるものではなく、XML、BMLBroadcastMarkupLanguage等の別のマークアップ言語と、JavaScript以外のプログラム記述言語をベースにしたものであってもよい。本実施形態においては、プログラムは、JavaScriptプログラムであるものとする。リソース提供装置103は、プログラム提供装置102と同様、通常のコンピュータのハードウェア構成をとるものであり、具体的には、PC、サーバ装置である。本実施形態においては、データセンター等で運用されるサーバ装置であり、インターネット上でNPVRサービスを提供している。これは、サービスの会員ユーザが、サーバ上のストレージにテレビ番組を録画予約できるサービスであるものとする。なお、リソース提供装置103が提供するリソースとは、装置内部の機能や情報を指すものとする。リソースへのアクセスは、リソース提供装置103が装置外部に公開するAPIApplicationProgrammingInterfaceを介して行われる。本実施形態においては、インターネット上に公開されたWebAPIを介してリソースが提供されるものとする。次に、情報処理装置101のCPUが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について図1に則して説明する。情報処理装置101は、第1通信部301、プログラム実行部302と、GUI表示部303と、GUI操作部304と、機器情報記憶部305と、変換部306とを有する。いずれも、CPUのプログラム実行時にRAMなどの主記憶部上に生成されるものである。CPUの実行プログラムは、ハードディスクや、CD-ROM等の記録媒体に格納されており、この記録媒体から読み出され、主記憶部に展開される。当該実行プログラムは、インターネット等のネットワークを介して情報処理装置101にダウンロードしてもよい。このうち、機器情報記憶部305はデータベース管理システムである。これは、リレーショナルデータベースであってもよいし、XMLeXtensibleMarkupLanguageデータベースであってもよい。また、これは単一のデータベース管理システムで構築されている必要はなく、複数のデータベース管理システムを併用しても良い。また、1つの物理的な記憶部上に構築されるようにしてもよいし、NASNetworkAttachedStorageや、SANStorageAreaNetworkといった複数の物理的な補助記憶部で構成されるデータベース管理システムとしてもよい。また、データの格納領域が不揮発であっても揮発であってもよい。あるいは、各記憶部に各々記憶されるデータの単位情報エントリを取得できる手段を備えていれば、CPUのプログラム実行時に主記憶上に生成されるリスト構造ベースの簡易なデータ管理モジュールであってもよいし、CSV形式ファイルの管理モジュールであってもよいし、Key/Valueストアで構成されていてもよい。以下、各部について説明する。第1通信部301は、第1のネットワーク上のプログラム提供装置102、リソース提供装置103と通信する。第1通信部301は、プログラム実行部302からの要求を受けて、プログラムを含むHTMLドキュメントなどのWebコンテンツへの要求をプログラム提供装置102に送信し、Webコンテンツを受信する前述したとおり、その他のフォーマットのコンテンツであってもよい。第1通信部301は、後述する変換部306から入力されるリソース利用要求をリソース提供装置103に送信し、リソース提供装置13による処理結果を受信する。両者との通信プロトコルについては、HTTP、FTP等、TCPプロトコルをベースとしたものでもよく、RTPやFLUTEなどUDPプロトコルをベースとしたものであってもよく、特定のプロトコルに限定するものではない。本実施形態においては、インターネット上で両者とHTTPSで通信する、HTTPクライアントである。プログラム実行部302は、前記プログラム提供装置102から受信したプログラムを含むWebコンテンツを処理する。前記プログラムに埋め込まれたリソース利用要求を、前記変換部306へ入力する。リソース利用要求の形式は、第1の形式に対応する。本実施形態及び後述の全ての実施形態において、このプログラム実行部302はWebブラウザエンジンである。しかしながら、Webブラウザに限定されるものではなく、BMLブラウザであってもよく、プログラムの実行環境を備えた、その他のアプリケーションプラットフォームであってもよい。Webブラウザであることを前提とした場合、前記リソース利用要求は、情報処理装置101の内部リソースへのアクセスを実現するJavaScriptAPIの呼び出し、あるいは、AJAX、WebSocket等のWebブラウザ上で呼び出し可能な通信APIを用いたメッセージ送信である。本実施形態においては、前記リソース利用要求は、JavaScriptAPI呼び出しとして実現されるものとする。本実施形態において、前述した録画予約ボタンが押下されると呼び出されるJavaScriptプログラムには、例えば、以下のようなJavaScriptAPIPVRDevicereserveが呼び出されることを想定している。なお、この関数に含まれるパラメータは、テレビ番組を特定する識別情報のセットである。プログラム実行部302は、このAPIの識別情報API識別情報としてのAPI名などと渡されたパラメータ情報networkidserviceidtransportstreamideventidを、後述する変換部へ出力する。GUI表示部303は、情報処理装置101が備えるディスプレイへのレンダリングを、前記プログラム実行部302からの命令によって実行する。GUI表示部303は、ユーザによる選択承諾を必要とする場合に、変換部306からプログラム実行部302を介した要求にしたがって、選択承諾のインタフェースポップアップ画面等を表示する。GUI操作部304は、情報処理装置101が備えるキーボード、マウス、タッチパネル等の入力インタフェースを介して入力された操作信号を、プログラム実行部302へ出力する。プログラム実行部302は、この操作信号をユーザによる選択承諾結果へと変換するこれは、Webブラウザの機能である。機器情報記憶部305は、リソース提供装置103の情報を、機器情報として記憶する。機器情報は、情報処理装置101のGUIを介して、ユーザが手動で入力してもよい。また、本実施形態のように、ホームネットワーク上のサービスではなく、インターネット上のサービスである場合には、装置に機器情報がプリセットされていてもよいし、サービスへの加入登録時に、情報処理装置内部に蓄積されるようにしてもよい。本実施形態におけるデータ構造の一例を図5に示す。図5に示すとおり、機器情報は、機器識別子、共通API識別子、機器依存APIのロケーション、機器依存APIへの変換ルール情報変換機構を含む。ここで、機器情報を構成するこれらの属性について説明する。まず、機器識別子は、機器すなわちリソース提供装置を識別する情報であり、URIUniversalResourceIdentifier、UUIDUniversalUniqueIdentifier、MACMediaAccessControlアドレス、機器の型名と製造番号の組み合わせ、IPv6アドレス等、リソース提供装置を一意に識別できる情報であれば、形式は何であってもよい。本実施形態では、機器本実施形態においてはNPVRサービスを特定するURIである。共通API識別子は、プログラム提供装置がリソース利用要求を行うJavaScriptAPIを識別する情報である。このAPIは、情報処理装置101とプログラム提供装置102との間で、仕様が共有されていることを前提としたものである。したがって、API仕様は標準化されている、もしくは、リソース提供装置に代理アクセスする情報処理装置メーカが独自仕様を定めて公開されていることを想定している。この想定のもと、API識別子は、情報処理装置101が、各共通APIを一意に特定できる情報であれば、どのような形式であってもよい。機器メーカの独自公開APIであれば、公開APIにユニークな番号を付与し、この番号をもってAPI識別子としてもよい。本実施形態では、APIのメソッド文字列クラス名メソッド名をAPI識別子としている録画予約機能を持つデバイスの録画予約関数として、PVRDevicereserve。機器依存APIロケーションは、上記共通APIに対応する、リソース提供装置個別のAPIのロケーションを示す情報である。リソース提供装置毎に形式が異なっていてもよく、本実施形態においては、NPVRサービスが提供するWebAPIを指すURIであるhttpnpvrservicecomwebapireserve。機器依存APIへの変換ルールは、共通APIを利用したリソース利用要求第1の形式を、各機器依存APIの実際のリソース利用要求第2の形式へと変換するための情報であり、変換部306が利用するものである。この変換ルール情報は、例えば、引数の順序情報、引数の形式の対応表情報、戻り値情報の形式やエラーコードの対応表情報で構成されてもよいし、内部で機器依存API呼び出しに変換する当該共通APIの実装そのものであってもよい。共通API呼び出しを、機器依存API呼び出しに変換可能な最低限の情報が含まれていれば、この変換ルール情報の形式は問わない。本実施形態においては、図5に例示するようにリクエストにおいては引数の変換表を、レスポンスに関しては、レスポンスコードメッセージの形式変換表を持つものとしている。なお、本実施形態においては、機器情報記憶部305が蓄積する情報は、図5の通りだが、このデータ構造に限定されるものでない。その他の情報を含むものであってもよい。例えば、機器がサポートするプロトコル依存のリソース利用に必要な情報を管理する、APIの改訂を想定したバージョン情報を管理する、などが想定される。データベースとして別テーブルで管理してもよい。例えば、関数を束ねるクラスオブジェクト情報と、DLNAのService情報を対応付けるなど、テーブル構成として階層構造をとってもかまわない。変換部306は、前記プログラム実行部302から入力されたリソース利用要求を、前記機器情報記憶部305に蓄積された機器情報を用いて変換する。すなわち、第1の形式を有するリソース利用要求を、第2の形式に変換する。変換して生成したリソース利用要求を、前記リソース提供装置103に送信する。処理結果たとえばリソース提供装置が録画予約を実行したとき、その旨を示す通知を、前記第1通信部経由で受信すると、必要であれば、これをJavaScriptAPIの出力形式に併せて変換し、プログラム実行部302へ出力する。次に、図1、図5、図13、図16を用いて、本実施形態に係る情報処理装置101の動作について説明する。図16は、本実施形態に係る情報処理装置を含むシステム構成要素間の基本シーケンスを示したものである。図13は、本実施形態における変換部の処理のフローチャートである。以下、図16のシーケンス図をベースに処理手順を説明する。前提としてユーザが、情報処理装置101上でブラウザを利用している。また、ユーザは、テレビ番組の録画予約をクラウドサービス上で実現するNPVRサービスに加入しており、情報処理装置101内の機器情報記憶部305には、リソース提供装置の機器情報が既に登録されている。まず、ユーザが、ブラウザ経由でプログラム提供装置102上に展開されている電子番組表サービスにアクセスするステップS101。ブラウザは、プログラム提供装置102にHTTPGETリクエストを送信しステップS102、プログラム提供装置102は、電子番組表サービスのWebコンテンツを応答するステップS103。このWebコンテンツには、前述したようにテレビ番組表が表示されており、各番組欄に録画予約するボタンが配置されている。ここで、ユーザは、録画予約したいテレビ番組の番組欄の録画予約ボタンを押下するとステップS104、プログラム実行部302が、Webコンテンツに埋め込まれたリソース利用要求を含むJavaScriptコードを実行するステップS105。ここで、前述のJavaScriptAPIPVRDevicereserveが呼び出され、パラメータ情報と共に、変換部306に入力され、変換部306において、Webコンテンツ上のJavaScripAPI呼び出しが、機器サービス依存の実際のリソース利用要求録画予約要求へ変換されるステップS106。ここで、変換部306の内部処理について図13をベースに説明する。まず変換部306に、プログラム実行部302が、リソース利用要求の発生を通知するAPI識別情報とパラメータ情報を入力するステップS1061。変換部306は、API識別子ここでは、API名:pvrDevicereserveをキーとして、機器情報記憶部305に、該当APIを含む機器を問い合わせるステップS1062。該当機器サービスが存在しない場合ステップS1063のNO、変換部306は、該当機器が存在しない旨をエラー応答するステップS1064。ここでは、インターネット上のNPVRサービスが存在するのでステップS1063のYES、このNPVRサービスの機器情報が取得される。変換部306は、機器情報に含まれる。APIのロケーション情報と、パラメータ変換情報を利用して、以下のNPVRサービスへの録画予約リクエスト機器依存のリソース利用要求を生成するステップS1065。続いて、変換部306は、生成したリソース利用要求を第1通信部301へ送信しステップS1066、処理結果を受信ステップS1067、これをJavaScriptAPIの応答メッセージに変換しステップS1068、応答しステップS1069、処理を終了する。なお、応答メッセージの変換は、例えば、レスポンスデータやエラーコードの変換表を、リクエストの場合と同様に、機器情報記憶部305に記憶しておき、これを利用して行われる。例えば、NPVRの応答がXML形式で、JavaScriptAPIの応答がJSON形式であった場合には、この形式変換を上記ステップS1068で実行する。ここで、図16の全体シーケンスに戻って、リソース利用要求変換以降のシーケンスについて説明する。変換部306が、生成したリソース利用要求を図13のステップS1066で第1通信部301に出力すると、第1通信部301は、これをHTTPSGETリクエストとして、リソース提供装置103へ送信するステップS107。リソース提供装置103は、受信したリクエストに基づき、該当番組の録画予約を実行しステップS108、結果を応答するステップS109。第1通信部301は、受信した応答メッセージを、変換部306に入力する。変換部306は、入力された応答メッセージをJavaScriptAPIの応答メッセージへと変換し、プログラム実行部302へ出力する。一方、プログラム実行部302は、応答メッセージをWebコンテンツプログラムへ返すステップS110。プログラムは、例えば、応答メッセージが、録画予約の成功応答であった場合、例えば、該当番組の録画予約に成功しました等のメッセージを画面上に表示させるステップS111。以上のように、本実施形態の情報処理装置により、NPVRサービスリソース提供装置にユーザが加入していることを電子番組表サービスプログラム提供装置に公開せずに、録画予約を実現できる。すなわち、サービス事業者にアクセス対象機器の情報を開示すること無く、サービス事業者のWebサービスと、アクセス対象機器のリソースとをマッシュアップ連携するサービスが可能となる。第2の実施形態次に、情報処理装置の第2の実施形態について説明する。なお、第1の実施形態との共通部分については、同一の符号を使用して説明したり、説明を省略したりする。本実施形態の概要として、想定する具体的なユースケースについて記す。まず、ユーザが、PCで、インターネット上のサービス前述の電子番組表サービスのWebページを閲覧し、録画予約したい番組欄の録画ボタンを押下する。このボタン押下によって、閲覧中のWebページに埋め込まれたJavaScriptコードが実行され、PCの内部機能としてのPC周辺AV機器での録画予約機能が呼び出される。この内部機能の実行により、録画予約機能を搭載した宅内のデジタルテレビに、指定番組が録画される。第1の実施形態との差分は、インターネット上のNPVRサービスでなく、ホームネットワーク上のデジタルテレビに録画予約する点である。以上のユースケースにおいては、デジタルテレビがリソース提供装置となり、ホームネットワークが、第2のネットワークとなる。以下、本実施形態の詳細について述べる。図2は、本発明の第2の実施形態に係わる情報処理装置の機能ブロックを含むシステム構成図である。図2におけるプログラム提供装置102は、第1の実施形態と同一である。システム構成上の第1の実施形態との差分は、ネットワーク202が追加されている点と、ネットワーク202上にリソース提供装置104、105が配置されている点である。ネットワーク202は、有線または無線のIPネットワーク、USB、HDMI、IEEE1394などの周辺機器接続用ネットワーク、あるいはTransferJet、赤外線等をはじめとする近距離あるいは近接無線ネットワーク、さらには、SDカード、外付けHDDなどのストレージ、CDやDVDなどのディスクメディア等、情報処理装置と情報を送受可能なあらゆるネットワーク、インタフェースである。本実施形態においては、ネットワーク202は、ホームネットワークを構成するLANLocalAreaNetworkであるものとする。リソース提供装置104、105は、第1の実施形態におけるリソース提供装置103と同様のハードウェア構成である。本実施形態においては、デジタル家電、具体的には、104がデジタルテレビ、105がハードディスクレコーダであるとする第1の実施形態のリソース提供装置103は、インターネット上のサーバ装置を想定していた。このデジタルテレビは、DLNAの録画機能SRS:ScheduledRecordingServiceを備えているものとする。次に、情報処理装置101は、ハードウェア構成は第1の実施形態と同様であるが、新たな機能ブロックとして、機器情報取得部307、第2通信部308、機器選択部309、ユーザ承認部310が追加されている。いずれも、CPUのプログラム実行時にRAMなどの主記憶部上に生成されるものである。また、機能ブロックの追加に伴い、機器情報記憶部305に記憶される機器情報のデータ構成、および、変換部306の処理フローも追加拡張されている。以下、追加された各部について説明する。機器情報取得部307は、ネットワーク202上のリソース提供装置を発見し、その機器情報を取得する。機器情報取得部307は、DLNAにおけるDiscovery、および、Descriptionステップの機能を行うものである。これは、第2通信部308を介して、定期的にネットワーク202に検索メッセージを送信するようにしてもよいし、ネットワーク202を常時監視し、ネットワーク202上を流れる公告メッセージDLNAAdvertiseメッセージを捕捉するように構成してもよいし、変換部306へのリソース利用要求の入力をトリガとして、変換部306からの要求に従って、検索メッセージを送信するように構成してもよい。本実施形態においては、機器情報取得部307は、変換部306の処理とは独立して、定期的に機器情報を収集しているものとする。第2通信部308は、リソース提供装置104、105と、ネットワーク202上で通信する。第2通信部308は、後述する機器情報取得部307によるネットワーク202上のリソース提供装置発見、および、変換部306を介したプログラムによるリソース利用のための通信を担う。本実施形態においては、第2通信部308は、HTTPクライアント、かつ、DLNAクライアントコントロールポイントの通信部である。機器選択部309は、リソース利用要求を送信する対象が複数見つかった場合に、機器選択用のユーザインタフェースを、プログラム実行部302を介して、GUI表示部303に表示し、ユーザの選択結果を、同様にプログラム実行部302から取得し、結果を変換部306に入力する。ユーザ承認部310は、情報処理装置101上のリソース周辺機器情報も含めて、リソース利用に関して、ユーザ許諾が必要な場合に、許諾用のユーザインタフェースを、プログラム実行部302を介して、GUI表示部303に表示し、ユーザの承認結果を同様にプログラム実行部302から取得し、結果を変換部306に入力する。さらに、ユーザによる承認結果を記憶し、一定期間あるいは永続的に流用するように構成することも可能である。次に、機器情報記憶部305のデータ構造の変更点について説明する。本実施形態におけるデータ構造の一例を図6に示す。第1の実施形態図5との差分は、機器名、ユーザ承認の必要有無、ユーザ承認日時、ユーザ承認結果、ユーザ承認の有効期限が追加されている点である。順に説明する。機器名情報は、機器選択部309が、生成するユーザの選択インタフェースに一覧する機器名を表す表示文字列情報である。ユーザ承認の必要有無情報は、当該リソース提供装置のリソースを利用するにあたり、情報処理装置101を操作するユーザの許諾を必要とするか否かを表すブール値である。ユーザ承認日時情報は、当該リソース提供装置のリソースを利用する際に、ユーザ承認を求めた日時情報である。ユーザ承認結果は、上記ユーザ承認の結果情報であり、許可か拒否を表すブール値である。ユーザ承認の有効期限情報は、ユーザの承認結果が適用される期間を示す情報である。図6の例では、秒単位で指定している。有効期限情報は、負値、もしくは、0を指定すると無期限を表すなど、有限でない場合もサポートするものとする。次に、図2、図6、図14、図17を用いて、本実施形態に係る情報処理装置101の動作について説明する。図14は、本実施形態における変換部306の処理フローを表すフローチャートである。図17は、本実施形態に係る情報処理装置を含むシステム構成要素間の基本シーケンスを示したものである。以下、図17のシーケンス図をベースに処理手順を説明する。まず、ユーザが、ブラウザ経由でプログラム提供装置102上に展開されている電子番組表サービスにアクセスする前に、機器情報取得部307が、定期的にネットワーク202上のリソース提供装置の情報を取得している。具体的には、機器情報取得部307は、DLNAのSearchメッセージを,第2通信部308を介して送信するステップS201。ネットワーク202上のリソース提供装置104、105は、Searchメッセージを受けて、Advertiseメッセージを送信するステップS202、203。このAdvertiseメッセージを受信すると、機器情報取得部307は、リソース提供装置104、105の存在を認識し、それぞれに対して詳細機器情報の取得要求メッセージを送信するステップS204,S206。リソース提供装置104、105は、それぞれ機器情報を応答するステップS205,S207。この機器情報取得シーケンスS204~S205,S206~S207は、リソース提供装置側が複数のサービスを有する場合には、複数回発生し得る。ここで、第1の実施形態と同様に、ユーザがプログラム提供装置102電子番組表サービスにアクセスし、録画予約したい番組の録画予約ボタンを押下、Webコンテンツに埋め込まれたプログラムが実行されるステップS208~S212。これは、第1の実施形態におけるステップS101~S105と同様なので説明を割愛する。ここで、変換部306の内部処理について図14をベースに説明する。まず変換部306に、プログラム実行部302が、リソース利用要求の発生を通知するAPI識別情報とパラメータ情報を入力するステップS2101。変換部306は、リソース利用要求を受けると、ネットワーク202ホームネットワーク上の周辺機器情報へのアクセスに対する許諾をユーザに求めるか否かを判定するステップS2102。これは、前述したように毎回許諾を求めるように構成してもよいし、有効期限を設け、期限が切れた場合に再度許諾を求めるように構成してもよいし、一度許諾されたものは初期化されない間は許諾を求めないように構成してもよいこうした有効期限の管理はユーザ承認部310で管理する。ここで許諾が必要であると判定された場合には、変換部306は、ユーザ承認部310に対して、ユーザ許諾インタフェースの表示を促す。ユーザ承認部310は、プログラム実行部302を介して、GUI表示部303にユーザに承認を求めるインタフェースポップアップ画面などを表示する。例えば、Webページが、周辺機器情報の利用を求めていますが、よろしいですかOKNG等の文言を表示し、ユーザの選択を促す。ユーザ承認部210は、ユーザの選択結果を、同様にプログラム実行部302を介して取得し、変換部306に出力する。ユーザが拒否した場合にはステップS2104、変換部306は、権限エラーが発生したものとして、プログラム実行部302へエラー応答を行い、処理を終了するステップS2105。一方、ユーザが許可した場合には、変換部306は、機器情報取得部305から、APIに対応するリソースを有するリソース提供装置の機器情報を取得するステップS2106。ここでは、リソース提供装置104、105が、それぞれデジタルテレビ、ハードディスクレコーダであり、共に録画機能を持っているとすると、該当機器が複数存在することになりステップS2109、変換部306は、機器選択部309に、機器選択インタフェースの表示を求める。機器選択部309は、プログラム実行部302を介して、機器選択インタフェースを表示して、ユーザに機器の選択を促すステップS2110。ここで、ユーザがデジタルテレビを選択したとすると、変換部306は、該当機器に対するアクセス許諾を求める必要があるか否かを、前述のステップS2102と同様に判定するステップS2111。この判定には、機器情報記憶部305の該当機器の該当API情報に、承諾が必要か否か、有効期限等の情報が含まれていて、これを利用するように構成してもよい。ここで必要と判定された場合には、ユーザ承認部310が、承認インタフェースを画面に表示し、ユーザの入力結果を、変換部306へ返すステップS2112。ユーザが拒否した場合には、API呼び出しに権限エラーを返し、終了するステップS2105。他方、ユーザが許可した場合には、JavaScriptAPI呼び出しを、本実施形態においては、DLNAのActionコマンドSOAPメッセージに変換し、第1の実施形態における図13のステップS1065~S1069の処理を行い、結果をプログラム実行部302へ返すステップS2114。以上のように、本実施形態によれば、ホームネットワークに配置されているデジタル家電リソース提供装置の存在を含めた情報を、電子番組表サービスプログラム提供装置に公開せずに録画予約を実現できている。すなわち、外部Webサービスからの宅内機器への不正アクセスを防止するとともに、どのような機器をユーザが所有しているか、といったプライバシーに係る情報を、一切Webサービス側に公開することなく、Webサービスと宅内機器との連携、すなわち、マッシュアップサービスが実現できている。また、本実施形態によれば、こうした連携機能にかかるリソース利用に関して、ユーザの許諾に基づいて実行することが可能になっている。第3の実施形態次に、情報処理装置の第3の実施形態について説明する。なお、第1、第2の実施形態との共通部分については、同一の符号を使用して説明したり、説明を省略したりする。本実施形態の概要は、第2の実施形態と同様であるが、リソース提供装置デジタルテレビが、ユーザ認証認可を求める点で異なる。すなわち、情報処理装置PC上で、リソース利用対象機器を決定した後で、デジタルテレビがユーザ認証とユーザによるアクセス認可を求める。この認可処理に関しては、ネットワーク201インターネット上のアクセス認可装置例えば、デジタルテレビのメーカが運営するユーザサポート用サービスサイトが代理でユーザ認証、および、ユーザによるアクセス認可を行うことも考えられるが、本実施形態では、一例として、デジタルテレビ自体がベーシック認証を行う場合を示す。情報処理装置PCは、デジタルテレビで発行された認証認可が得られたことを証明する情報以降、チケットと呼ぶをデジタルテレビに提示する。デジタルテレビは、提示されたチケットの正当性を確認し、ユーザ認証が成功し、かつ、ユーザによるアクセス認可が得られた情報処理装置に対してのみ、リソースを返す。図3は、本発明の第3の実施形態に係わる情報処理装置の機能ブロックを含むシステム構成図である。システムの全体構成は、第2の実施形態と同様である。次に、情報処理装置101は、ハードウェア構成は第1及び第2の実施形態と同様であるが、新たな機能ブロックとして、認証認可処理部311、リソース提供装置起動部312が追加されている。いずれも、CPUのプログラム実行時にRAMなどの主記憶部上に生成されるものである。また、機能ブロックの追加に伴い、機器情報記憶部305に記憶される機器情報のデータ構成、および、変換部306の処理フローも追加拡張されている。以下、追加された各部について説明する。認証認可処理部311は、変換部306からの認証認可処理要求を受けて、機器情報記憶部305に記憶された、該当リソース提供装置104、105のアクセス認証認可方式情報に基づき、第1通信部301、第2通信部308、ユーザ承認部310を利用して、リソース利用のための認証認可処理を行う。この認証認可処理は、リソース提供装置上で実行されるベーシック認証やダイジェスト認証、リソース提供装置とは異なる外部機器アクセス認可装置上で、代理でアクセス認可を実現するOAuth認証などを想定している。認証認可処理部311は、これらの認証クライアントとして振舞う。リソース提供装置起動部312は、ネットワーク202上のリソース提供装置が、スリープ状態にある場合に、これをWakeOnLAN等を利用して起動し、通信可能状態に変更する。リソース利用要求の送信対象が見つからない場合に、変換部306によって呼び出される。次に、機器情報記憶部305のデータ構造の変更点について説明する。本実施形態におけるデータ構造の一例を図7に示す。第2の実施形態図6との差分は、プロトコル種別、アクセス認証認可方式識別情報、チケット情報、チケット有効期限情報、MACアドレスが追加されている点である。順に説明する。プロトコル種別情報は、DLNAやIEEE1394、白物家電向けのプロトコルECHONET等、リソース提供装置がネットワーク202上でサポートしている通信プロトコル情報である。本実施形態においては、DLNAに限定されているが、上述した以外の様々なプロトコルに対応することも想定している。機器情報取得部305は、其々のプロトコルに則した機器情報の収集を行う。アクセス認証認可方式識別情報は、ベーシック認証、ダイジェスト認証、あるいは、OAuth認証など、リソース提供装置の要求する認証方式を表す情報である。方式に複数のバージョンが存在する場合には、このバージョン情報についても合わせて記憶することも考えられる。チケット情報は、認可が得られたことを示す情報であり、リソース提供装置に提示する情報である。これも、ライセンス情報と同様、前記アクセス認証認可方式情報毎に必要な情報、形式は異なる。本実施形態では、チケット情報は、OAuth認証に則った、認可が与えられたことを示すものであるとする。チケット有効期限情報は、チケットの有効期限を示す情報である。最後に、機器のMACアドレスは、スリープ状態にある機器を起動するために利用するものである。機器識別子情報で代替できる場合には、MACアドレスは必要ない。本実施形態における機器情報は、以上4項目の追加で収まっているが、認証認可方式に応じて、さらなる情報が必要な場合もあり、リソース提供装置へ情報処理装置がアクセスするために必要なアクセス認証認可手続きに必要な様々な情報を保持し得るものとする。次に、図3、図7、図15、図18を用いて、本実施形態に係る情報処理装置101の動作について説明する。図15は、本実施形態における変換部306の処理フローを表すフローチャートである。図18は、本実施形態に係る情報処理装置を含むシステム構成要素間の基本シーケンスを示したものである。以下、図18のシーケンス図をベースに処理手順を説明する。まず、機器情報取得部307による機器情報の収集の手順S301-S307は、第2の実施形態のステップS201~207と同様であるため、ここでは省略する。機器情報取得部307は、例えば、DLNADiscovery、Descriptionステップの手順に則って、リソース提供装置104、105の機器情報を取得し、機器情報記憶部107に格納する。この機器情報収集部の手順は、白物家電を対象にしたECHONETや、IEEE1394など、その他のプロトコルに従う場合は、各プロトコルにおける機器発見のメカニズムを用いればよい。続く、プログラム提供装置102からのリソース利用プログラムを含むWebコンテンツの取得処理、ユーザがWebコンテンツ中の録画予約ボタンを押下することによるリソース利用プログラムの実行開始までは、第2の実施形態と同様であるS308~S312。ここまでは、上述の機器情報取得処理を含めて、第2の実施形態のステップS201~S212に一致する。ここで変換部306によるリソース利用要求変換処理ステップS313について、図15を用いて説明する。第2の実施形態と同様、変換部306は、機器情報記憶部305の情報に基づいて、機器選択と、ユーザによる選択機器のリソース利用許諾までを行うステップS3102~S3113。これも、図14における第2の実施形態のステップS2102~S2113までに一致する。本実施形態では、リソース利用要求を機器依存の要求メッセージに変換しステップS3114、機器に対して送信した後にステップS3115、送信先のアドレスが解決できずに送信が失敗するとステップS3116、変換部306は、リソース提供装置起動部312へ該当リソース提供装置の遠隔起動を要求する。リソース提供装置起動部312は、変換部306からの要求を受けて、該当機器に対するWakeOnLANパケットを送信し、Ethernet登録商標越しに該当リソース提供装置104を起動するステップS3117。リソース利用要求送信が成功して装置が起動するまで、再送の上限回数、再送を繰り返す。上限に達した場合にはS3118のYES、通信エラーをプログラム実行部302へ応答しステップS3119、処理を終了するステップS3124。リソース提供装置104へのリソース利用要求の送信が成功すると、本実施形態では、変換部306は、リソース提供装置からエラー応答として、アクセス認証ベーシック認証が必要な旨を通知される。これは、例えば、HTTP/1.1401AuthorizationRequired応答によって実現されるが、アクセス認証がベーシック認証やダイジェスト認証でない場合には、この限りではなく、独自の方法で実現されてもかまわない。他にも、機器情報記憶部305に、機器上でのアクセス認証認可が必要であるか否かをあらわす情報を格納しておき、この情報に基づいて、401応答を受けずに認証認可をダイレクトに実行する方法を採っても構わない。アクセス認証要求を受けると、変換部306は、認証認可処理部311に処理を要求し、認証認可処理部311は、認証認可処理を実行するステップS3120。認証認可処理が成功すると、実際にリソース利用が行われ、変換部306は、受信した処理結果を変換して、プログラム実行部302へ応答を返し、一連の処理が完了するステップS3121~ステップ3124。ここで、上述の図15のフローチャートにおけるステップS3120における認証認可処理について、図18のシーケンス図を利用して説明する。認証認可処理部311は、まず、HTTPの401応答を受けてステップS315、S316、プログラム実行部302を介して、リソース提供装置104デジタルテレビ上に設定されたユーザアカウントとパスワードの入力を求めるポップアップ画面を表示する。ユーザがポップアップ画面上に、ユーザアカウントとパスワードを入力するとステップS317、この2値を:で連結しBase64エンコードしたデータを認証ヘッダに指定して、送信するステップS318。リソース提供装置104は、指定されたユーザアカウントとパスワードが正しいものであれば、認証成功の応答と共に、情報提供装置101からのリソース利用要求を許可するか否かを、ユーザに承諾するよう求める応答メッセージを送信するステップS319。認証認可処理部311は、認証時と同様に、プログラム実行部302を介して、ユーザに認可を求めるポップアップ画面を表示する。例えば、PCからデジタルテレビへの録画予約メッセージを受け取りました。録画予約を許可しますかOKNGといったメッセージ確認画面を表示する。ユーザがOKをクリックして、アクセスすなわち、リソース利用を許可するとステップS320、このユーザによる許諾が、リソース利用装置104へ送信されるステップS321。リソース提供装置104は、ユーザの許諾を受けて、確認応答を返すステップS322。この確認応答には、アクセス許可を示す一時的な認可情報チケット情報とその有効期限情報を返すように構成してもよい。本実施形態においては、チケット情報は、図7に例示した文字列情報であるものとするが、この形式はどのようなものであってもよい。また、チケット情報などの情報を応答するにあたり、応答形式は、HTTPのレスポンスの認証認可にかかるヘッダAuthorizationヘッダや独自拡張ヘッダに格納するようにしてもよいし、レスポンスボディにXMLやJSON形式で格納するようにしてもよい。前者の既存ヘッダを利用する方法であれば、ポップアップ画面での認証認可時に指定したものと同じデータベーシック認証であれば、ユーザID/パスワードをBase64エンコードしたものをチケットとしてもよい。認証認可処理部311は、このチケット情報と有効期限情報を、変換部306へ返す。変換部306は、チケット情報と有効期限情報を、リソース利用要求メッセージに含めて送信するステップS323。リソース提供装置104は、指定されたチケット情報を検証し、該当リソース利用要求を実行ステップS324、結果を応答するステップS325。あとは、図15のフローチャートのS3121からS3124と同様であり、変換部306が機器情報記憶部305に記憶された変換ルールに則って、リソース利用要求処理結果を変換し、変換結果をプログラム実行部302上で実行されるプログラムへ返し、当該プログラムは、結果を画面上に表示するステップS326、ステップS327。以上のように、本実施形態によれば、第1、第2の実施形態で説明した効果に加えて、情報提供装置101上でのリソース利用に対するユーザ承認だけでなく、リソース提供装置104、105が、ユーザ認証及び認可を要求する場合にも、プログラム提供装置によるリソース利用を実現することが可能となる。変換部306が、様々な機種に合わせたリソースへのアクセス認証及び認可処理を実現することにより、プログラム提供装置102は、個々の認証認可方式に対応する必要がない。また、この一連の認証認可プロセスは、共通APIの呼び出しの内部処理として実行されるため、プログラム提供装置102が、リソースを利用するに当たって、どのような認証認可処理が行われたのか感知することができない。つまり、本実施形態においてユーザが入力した、ユーザアカウントやパスワードの情報を知ることはできない。つまり、個々の機器がユーザ認証及び認可を要求する場合においても、これらの処理にかかるユーザの秘密情報を全くプログラム側に知らせずに、リソース利用Webコンテンツと宅内機器リソースのマッシュアップサービスを実現することが可能になっている。第4の実施形態次に、情報処理装置の第4の実施形態について説明する。なお、第1、第2、および、第3の実施形態との共通部分については、同一の符号を使用して説明したり、説明を省略したりする。本実施形態の概要は、第3の実施形態と同様であるが、リソース提供装置デジタルテレビがユーザ認証及びアクセス認可をインターネット上のサービスを利用して実施する点と、デジタルテレビに対するユーザ認証認可が、情報処理装置101PCではなく、プログラム提供装置102に対する認可を要求する点で異なる。まず前者の差分は、デジタルテレビがユーザ認証とユーザによるアクセス認可を求める際に、第3の実施形態では、デジタルテレビ自体がベーシック認証を行うものであったのに対して、本実施形態では、ネットワーク201インターネット上のアクセス認可装置例えば、デジタルテレビのメーカが運営するユーザサポート用サービスサイト107が代理でユーザ認証、および、ユーザによるアクセス認可を行うものである点である。このとき、情報処理装置PCは、アクセス認可装置で発行された認証認可が得られたことを証明する情報以降、トークンと呼ぶをデジタルテレビに提示する。デジタルテレビは、提示されたトークンの正当性を確認することで、ユーザ認証が成功し、かつ、ユーザによるアクセス認可が得られた情報処理装置に対してのみ、リソースを返す。後者の差分は、第3の実施形態が、デジタルテレビがPCからのアクセスに対する認可を求めるものであったのに対して、本実施形態では、デジタルテレビは電子番組表サービスからのアクセスに対する認可を求めるものである点である。図4は、本発明の第4の実施形態に係わる情報処理装置の機能ブロックを含むシステム構成図である。システム構成上の第2の実施形態との差分は、ネットワーク201上にアクセス認可装置107が提供されている点である。アクセス認可装置107は、プログラム提供装置102と同様、通常のコンピュータのハードウェア構成となっており、ここではデータセンター等で運用されるサーバ装置である。本実施形態におけるアクセス認可装置107は、前述したように、リソース提供装置104デジタルテレビを製造販売するメーカが運用し、ユーザサポートサービスを提供しているものとする。このサービスは、製品を購入したユーザに対して、購入した製品情報型名、製造番号等と共にユーザ登録を行ってもらうことで、製品に対するアップデート情報などを提供すると共に、本実施形態が実現するようなインターネット上のWebサイトからの製品内部のリソース利用に対するアクセス認証認可サービスを提供するものとする。情報処理装置101は、ハードウェア構成及び機能ブロック構成共に、第3の実施形態と基本的に同様である。一方、リソース提供装置104は、第2、第3の実施形態と同様のハードウェア構成をとるが、前述したようにPC情報処理装置101ではなく、電子番組表サービスプログラム提供装置102に対するアクセス認可を求めるものであり、通信部401、リソース提供部402、アクセス要求元情報記憶部403、アクセス制御部404、承認結果検証部405を有する。いずれも、CPUのプログラム実行時にRAMなどの主記憶部上に生成されるものである。以下、各部について説明する。通信部401は、ネットワーク202上で、情報処理装置101と通信する。通信部401は、情報処理装置101上の機器情報取得部307によるネットワーク202上のリソース提供装置発見、および、変換部306を介したプログラムによるリソース利用のための要求、および、リソース利用に伴う認証認可要求を受け付ける。本実施形態においては、通信部401は、HTTPサーバ、かつ、DLNAデバイスの通信部である。リソース提供部402は、通信部401を介して受信したリソース利用要求に対応するリソースを提供する。アクセス要求元情報記憶部403は、アクセス要求元の情報、すなわち、情報処理装置101ではなく、リソース利用要求プログラムを埋め込んだWebコンテンツを提供するプログラム提供装置102に係る情報を記憶する。本実施形態におけるアクセス元情報記憶部403に蓄積される情報のデータ構造は、図9に例示するように、アクセス要求元識別子、アクセス対象リソース識別子、ユーザ識別子、アクセス可否情報、ユーザ承認結果、認可情報、認可有効期限で構成されている。アクセス要求元識別子は、プログラム提供装置102の識別情報である。本実施形態では、電子番組表サービスのURLである。アクセス対象リソース識別子は、アクセス要求元が利用要求するリソースを識別する情報である。アクセス対象リソース識別子は、機器情報記憶部305における機器依存APIロケーションに相当する情報である。ユーザ識別子は、リソース提供装置104上のユーザを識別する情報である。リソース提供装置にユーザアカウントが存在しない場合には、この情報は含まなくても構わない。アクセス可否情報は、ユーザリソース提供装置所有者による、当該アクセス要求元による当該リソースの利用の可否を示す情報である。許可か拒否の二値、もしくは、この二値に未承認を加えた三値をとる。この情報は、装置外部のアクセス認可装置を想定する場合に、このアクセス認可装置におけるアクセス可否を示すものを想定しており、外部アクセス認可装置を想定しない場合には必要ない。ユーザ承認結果は、ユーザリソース提供装置所有者によるアクセス可否の判断結果を示す情報であり、許可か拒否の二値、もしくは、これに未承認を加えた三値をとる。認可情報は、アクセス可否情報と同様、外部のアクセス認可装置を想定する場合に、外部アクセス認可装置が認可を与えたことを示すチケット情報である。これは、情報処理装置101上の機器情報記憶部305上のデータ図8参照に含まれるチケット情報である。リソース提供装置104は、この情報と、情報処理装置101がリソース利用要求と共に提示するチケット情報とのマッチングをとり、アクセス可否を判定する。認可有効期限は、上記認可情報の有効期限を示すものである。これもアクセス可否判定に利用される。アクセス制御部404は、リソース利用要求に含まれるアクセス要求元情報を取得し、アクセス可否情報が未設定のアクセス要求元からのアクセスを受信した場合には、情報処理装置101に対して、ユーザのアクセス承認を要求する。アクセス制御部404は、情報処理装置からのユーザによるアクセス可否の承認結果を、通信部401を介して受信し、アクセス要求元情報記憶部403に結果を格納すると共に、承認結果を利用してアクセス制御を行う。承認結果検証部405は、リソース提供装置104が、アクセス認可に外部装置アクセス認可装置107を利用する場合に、このアクセス認可装置107から認可情報チケット情報を取得し、取得した許可情報を、情報処理装置101からのリソース利用要求に含まれるチケット情報と比較することで、承認が実際に得られたか否かを検証する。次に、情報処理装置101の差分について説明する。本実施形態は、第3の実施形態と、変換部306の内部処理、および、機器情報記憶部305のデータ構造において異なっている。まず、変換部306は、第1から第3までの実施形態においては、機器情報記憶部305に記憶された変換ルールに則って、リソース利用リクエスト及びレスポンスの変換を行うものであったが、本実施形態においては、変換部306は、各リソース提供装置が提供する変換用プログラム変換機構をロードするだけのものとなっている。次に、機器情報記憶部305のデータ構造の変更点について説明する。本実施形態におけるデータ構造の一例を図8に示す。第3の実施形態図7との差分は、プロトコル種別および変換ルール情報を含まない点、変換ルールの代わりに変換プログラムのロケーションを含む点、ライセンス情報ライセンス情報秘密鍵が追加されている点である。追加された項目について順に説明する。まず、変換プログラムのロケーション情報は、第1~3の実施形態で述べた変換ルールではなく、変換コード自体を含んでいる。このため、変換部306は、ルールを解釈して変換する、という処理を行う必要がなく、変換プログラムをそのまま適用すれば、共通API呼び出しが、適切な機器依存のリソース利用要求に変換され、取得した処理結果の変換までも行える。ライセンス情報ライセンス情報秘密鍵は、アクセス認可を得るために必要な、情報処理装置101が認可を得る権利を持っていることを示す情報である。前記アクセス認証認可方式情報毎に必要な情報、形式は異なる。例えば、X509クライアント証明書であってもよいし、あるいは、アクセス認可装置104がクライアント毎に発行するクライアント識別情報と秘密鍵のペア情報であってもよい。形式は問わない。本実施形態では、OAuth認証に則った、クライアントクレデンシャルクライアント識別情報および秘密鍵情報であるものとする。チケット情報は、認可が得られたことを示す情報であり、リソース提供装置に提示する情報である。これも、ライセンス情報と同様、前記アクセス認証認可方式情報毎に必要な情報、形式は異なる。本実施形態では、チケット情報は、OAuth認証に則った、認可が与えられたことを示すトークン情報であるものとする。チケット有効期限情報アクセス認可の有効期限は、チケットの有効期限を示す情報である。本実施形態においては、チケット有効期限情報は、OAuth認証に則った、トークンの有効期限情報である。最後に、機器のMACアドレスは、スリープ状態にある機器を起動するために利用するものである。機器識別子情報で代替できる場合には、MACアドレスは必要ない。なお、認証認可方式に応じては、さらなる情報が必要な場合もある。この場合、機器情報は、リソース提供装置へ情報処理装置がアクセスするために必要なアクセス認証認可手続きに必要な様々な情報を保持し得るものとする。次に、図4、図8、図9、図10、図11、図12、図19を用いて、本実施形態に係る情報処理装置101及びリソース提供装置104の動作について説明する。図8は、本実施形態における機器情報記憶部305に記憶される機器情報のデータ構成の一例を示すものである。図10は、本実施形態におけるプログラム提供装置102が提供するプログラムWebコンテンツの概略を示すものである。図11は、変換部306が提供するリソース利用APIを定義したライブラリ擬似コードの一例を示すものである。図12は、リソース提供装置104が提供する変換プログラム擬似コードの一例を示すものである。図19は、本実施形態に係る情報処理装置を含むシステム構成要素間の基本シーケンスを示したものである。なお、変換部306の処理は、第3の実施形態と同様であり、図15に示すフローチャートに従うものとする。以下、図19のシーケンス図をベースに処理手順を説明する。なお、第3の実施形態との差分のみについて説明する。まず、機器情報取得ステップS401~S410での差分は、情報処理装置101は、各リソース提供装置104、105の情報を取得すると、変換部305が、機器情報に含まれる、機器識別情報、変換プログラムのロケーション情報に基づき、自身が提供するリソース利用API定義ライブラリ図11に、各変換プログラムを動的にロードするコードを追加する。具体的には、リソース提供装置104の場合は、8行目から12行目のコードを、リソース提供装置105の場合は、13行目から16行目のコードを、追加する。変換部306が実施する処理は以上である。続いて、ユーザが、プログラム提供装置102が提供する電子番組表サービスにアクセスし、ユーザが特定番組の録画予約ボタンを押下するステップS411。ここで、電子番組表サービスのWebコンテンツの構成の概要について、図10をベースに簡単に説明しておく。図10に示すように、プログラム提供装置102が提供するWebコンテンツは、リソースを利用するここでは宅内のテレビの録画予約機能を呼び出すreserve関数を呼び出すプログラムファイルuseResourcejsと、このuseResourcejsが呼び出すreserve関数を定義したライブラリファイルdeviceAPIjsを、Webコンテンツ内で呼び出しているそれぞれ、図10の7行目、10行目。前者のuseResourcejsは、プログラム提供装置102上に配置されており、後者のdeviceAPIjsは、本実施形態においては、情報処理装置101内に配置されている。前述したように、後者のファイルは、機器の発見や離脱に伴い、動的に変換部306によって書き換えられるものである。次に、ステップS413の変換部306における変換処理について説明する。処理フロー自体は第3の実施形態と同様であり、図15に従うものであるが、主に変換処理自体図15のステップS3121-S3123が異なっている。これは、第3の実施形態が、変換ルールに則って、変換部306によって行われるものであったのに対して、本実施形態においては、各リソース装置が提供する変換プログラムが変換処理を行うためである。変換処理について図11、図12、図15を用いて説明する。図15におけるリソース利用要求入力S3101は、情報処理装置101が提供するリソース利用APIreserve関数の呼び出しに対応する。続くステップS3102~S3120までの処理が、内部のprepare関数図11の4行目の内部処理に対応する。ここで、機器の特定と認証認可処理までが完了しており、ライブラリdeviceApijs側に、リソース利用対象機器の識別情報が返される。ここではリソース提供装置104のリソースを利用するので、変換部306が組み込んだ、図11の8行目から12行目のコードが呼び出され、リソース提供装置上の変換プログラムhttp1921680108888upnpcontrolpvrsrsctrljstranscodejsがロードされ、利用される。図12に示すように、リクエストの変換、送信、レスポンスの受信、変換までの全ての処理図15のステップS3121-S3123が、この変換プログラム内で実行される。続いて、情報処理装置101上の変換部306は、リソース利用要求プログラムの提供元の電子番組表サービスの識別情報図9よりhttpwwwiepgcomを含む、リソース利用要求を、上記変換コードの呼び出しによってリソース提供装置104に送信するステップS414。リソース提供装置上の通信部401は、リソース利用要求メッセージを受信し、これをアクセス制御部404へ渡す。アクセス制御部404は、アクセス要求元情報記憶部403の該当情報を参照し、アクセス可否情報が未設定であることを検知する。アクセス制御部404は、アクセス認可装置107上でのアクセス認可が必要であると判定し、エラー応答として、アクセス認証OAuth認証が必要な旨を通知する。具体的には、ネットワーク201上のアクセス認可装置107上のアクセス承認用ページへとリダイレクトするように要求する。これは、例えば、HTTP/1.1302Found応答によって実現されるステップS415。このとき、アクセス制御部404は、リダイレクト先のURLに、再リダイレクトアクセス認可装置107からリソース提供装置104へリダイレクトするためのコールバックURL、および、リソース提供装置の識別情報UUIDやMACアドレス、シリアル番号モデル番号などを含める。情報処理装置101上の変換部306は、リダイレクト要求を受信すると、認証認可処理部311に認証認可を要求するステップS416。認証認可処理部311は、HTTPレスポンスリダイレクト要求に従い、アクセス認可装置107上のアクセス承認画面にアクセスするステップS417。ここでは、ユーザが、アクセス認可装置107機器メーカのユーザサポートサービスへログインを行っていない状態であり、ユーザ認証画面へさらにリダイレクトされるステップS418。認証認可処理部402は、プログラム実行部302を介して、このユーザ認証画面をポップアップ表示する。ユーザが、アクセス認可装置107機器メーカのユーザサポートサービス上のユーザアカウントとパスワードを入力し、OKボタンを押下するとステップS419、認証認可処理部311は、認証要求メッセージをアクセス認可装置107へ送信しステップS420、認証結果を受信するステップS421。受信した認証結果は、最初にアクセス要求したアクセス承認画面であり、認証認可処理部411は、これもポップアップ画面として表示する。この画面には、例えば電子番組表サービスXがデジタルテレビYへ録画予約を求めていますが許可しますかOKNG等のメッセージが表示される。ここで、ユーザがOKボタンを押下するとステップS422、認証認可処理部311が、アクセス認証要求メッセージを送信しステップS423、アクセス認可装置107から応答を受信するステップS424。この応答メッセージは、ステップS415で、リソース提供装置104が指定したコールバックURLに対するリダイレクトを要求するHTTP/1.1302Found。この応答メッセージには、アクセス認可を示すチケット情報もしくは、チケット情報を取得するためのVerificationCodeが含まれている。本実施形態では、直接チケットが含まれているものとするが、VerificationCodeである場合、これをHTTPSなどの安全な通信経路を用いて、アクセス認可装置107に提示し、改めてチケットを取得するように構成してもよい。また、このとき認証認可処理部311は、機器情報記憶部305に記憶されたライセンス情報を利用して、アクセス認可を得る権利を持っていることを、アクセス認可装置107に提示するように構成してもよい。認証認可処理部311は、コールバックURLすなわち、リソース利用のためのWebAPI呼び出しへリクエストを送信するステップS425。このリクエストメッセージには、アクセス要求元情報に加え、チケット情報が含まれているものとする。このチケット情報は、チケットを表す文字列データと共に、チケットの正当性を証明する秘密情報のハッシュ値が含まれるように構成してもよい。ここで、リソース提供装置104上のアクセス制御部404は、受信したリソース利用要求に含まれる、アクセス要求元情報とチケット情報を抽出する。この時点で、チケット情報が、アクセス要求元情報記憶部403に記憶されていない場合、アクセス制御部404は、承認結果検証部405に、取得したチケットの正当性検証を要求する。承認結果検証部405は、情報処理装置101を介して、アクセス認可装置107に、当該機器に対するアクセス承認結果の要求メッセージを送信するステップS426。なおリソース提供装置104がネットワーク201上にあるときは、当該要求メッセージを直接、送信する。アクセス認可装置107は、要求を受けて、要求元のリソース提供装置に係る承認結果情報を応答するステップS427。この応答に、ステップS425で受信したのと同じチケットが含まれていた場合、チケットを正当なものであるとして、アクセス制御部404に応答を返すと共にステップS428、認可に係る情報図9に一覧された属性情報をアクセス要求元情報記憶部403に記憶する。アクセス制御部404は、この応答に基づき、アクセスを許可し、リソース提供部402が、アクセス対象リソースを提供するステップS429、S430。以降は、リソース利用要求処理結果に対応して、変換部306が機器情報記憶部305に記憶された変換コードを呼び出して、変換コード変換結果をプログラム実行部302上で実行されるプログラムへ返し、当該プログラムは、結果を画面上に表示するステップS431、ステップS432。以上のように、本実施形態によれば、第3の実施形態で説明した効果に加えて、リソース提供装置104、105がアクセス要求元プログラム提供装置101に応じたアクセス制御を行うことが可能となっている。また、リソース提供装置上のみならず、外部のアクセス認可サービスを利用したアクセス認可に基づく、アクセス制御を行うことも可能であることを示している。また、この一連の認証認可プロセスは、第1~3の実施形態と同様、共通APIの呼び出しの内部処理として実行されるため、プログラム提供装置102が、リソースを利用するに当たって、どのような認証認可処理が行われたのか検知することができない。つまり、本実施形態においてユーザが入力した、ユーザアカウントやパスワードの情報を知ることはできない。つまり、個々の機器がユーザ認証及び認可を、外部の認証認可サービスを利用して要求する場合にであっても、これらの処理にかかるユーザの秘密情報を全くプログラム側に知らせずに、リソース利用Webコンテンツと宅内機器リソースのマッシュアップサービスを実現できている。また、本実施形態においては、変換処理自体を、各リソース提供装置が提供する形式を採っているため、単なる変換表に基づく静的なマッピングにとらわれないより複雑で柔軟な処理が可能となる。また、このプログラムの配置場所が、リソース提供装置上だけでなく、リソース提供装置のメーカサイトに配置してもよく、変更やデプロイが容易であるという利点もある。"