JP5589537B2 - 情報処理装置、情報処理方法、プログラム、情報提供装置および情報処理システム - Google Patents

Description

本発明は、情報処理装置、情報処理方法、プログラム、情報提供装置および情報処理システムに関する。

近年、コンピュータが担う役割をクライアント（以下、「情報処理装置」とも言う。）とサーバ（以下、「情報提供装置」とも言う。）に分担させたクライアントサーバシステムが様々な場面において活用されている。クライアントサーバにおいては、一般的に、ユーザが画面を閲覧しながら所望の指示をクライアントに入力し、クライアントはユーザから入力された指示に応じた要求をサーバに送信する。サーバは、クライアントから送信された要求を受信し、その要求に応じた操作を実行し、実行して得られた結果をその要求に対する応答としてクライアントに返信する。

このとき、クライアントに表示される画面としては、サーバによって生成されるものとクライアントによって生成されるものとに大別される。クライアントに表示される画面がサーバによって生成される技術としては、例えば、ＷｅｂサーバによりＷｅｂ画面を生成する技術や、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ＴｅｌｅＶｉｓｉｏｎ）のサーバによりテレビなどの電子機器に配信するための画面を生成する技術、リモートデスクトップにおいて操作対象のコンピュータにより手元のコンピュータに表示させる画面を生成する技術（例えば、特許文献１参照。）などがある。

また、クライアントに表示される画面がクライアント自身によって生成される技術としては、例えば、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）などのプロトコルにしたがって動作するクライアントが画面を生成する技術などがある。

特開２００７−２１９７９０号公報

しかしながら、クライアントに表示される画面がサーバによって生成される技術では、クライアント自身があらかじめ保持している画面とサーバによって生成された画面との間で親和性が悪いことがあるという問題があった。また、表示される画面がクライアント間において均一化されてしまい、クライアントにより表示される画面のバリエーションが低下してしまうという問題があった。

他方、クライアントに表示される画面がクライアント自身によって生成される技術では、例えば、サーバとクライアントとの間で使用されるプロトコルが変化した場合などに、変化した後のプロトコルに応じて、クライアントによる画面生成の機能を変更する必要が生じてしまうという問題があった。

そこで、本発明は、クライアント自身があらかじめ保持している画面とサーバによって生成された画面との間に生じる親和性の悪さを解消しつつ、サーバとクライアントとの間で使用されるプロトコルの変化に柔軟に対応することが可能な、新規かつ改良された技術を提供しようとするものである。

本発明のある実施形態によれば、情報提供装置により実行される第１操作の内容を示す第１操作内容情報を上記情報提供装置から受信する受信部と、上記情報提供装置により実行される第２操作の内容を示す第２操作内容情報を記憶するデータ記憶部と、上記受信部により受信された上記第１操作内容情報を上記データ記憶部に記憶させる記憶制御部と、画面を生成するために使用される情報である画面情報を記憶する画面情報記憶部と、上記画面情報記憶部により記憶されている上記画面情報に基づいて、上記データ記憶部により記憶されている上記第１操作内容情報および上記第２操作内容情報が設定された画面を生成して表示部に表示させる表示制御部と、を備える、情報処理装置が提供される。

上記受信部は、上記第１操作を識別するための第１操作識別情報を上記情報提供装置からさらに受信し、上記データ記憶部は、上記第２操作を識別するための第２操作識別情報をさらに記憶し、上記記憶制御部は、上記受信部により受信された上記第１操作識別情報を上記データ記憶部にさらに記憶させ、上記情報処理装置は、上記データ記憶部により記憶されている上記第１操作識別情報および上記第２操作識別情報のいずれか１つを被選択操作識別情報として選択し、上記被選択操作識別情報を含む要求である実行要求を生成する実行要求生成部と、上記実行要求生成部により生成された上記実行要求を上記情報提供装置に送信する送信部と、をさらに備えることとしてもよい。

上記表示制御部は、上記データ記憶部により記憶されている上記第１操作識別情報および上記第２操作識別情報が一致するか否かを判断し、上記第１操作識別情報および上記第２操作識別情報が一致すると判断した場合には、上記第１操作内容情報および上記第２操作内容情報のいずれか１つの上記画面への設定を省略することとしてもよい。

上記表示制御部は、上記第１操作識別情報および上記第２操作識別情報が一致すると判断した場合に、上記第１操作内容情報の上記画面への設定を省略することとしてもよい。

上記実行要求生成部は、上記表示制御部により、上記第１操作内容情報の上記画面への設定が省略された場合には上記第１操作識別情報を選択対象から除外し、上記第２操作内容情報の上記画面への設定が省略された場合には上記第２操作識別情報を選択対象から除外することとしてもよい。

上記表示制御部は、上記第１操作識別情報が上記情報提供装置に上記第１操作を実行させるための関数である第１関数名を含んでいる場合であり、かつ、上記第２操作識別情報が上記情報提供装置に上記第２操作を実行させるための関数である第２関数名を含んでいる場合に、上記第１関数名および上記第２関数名が一致するか否かを判断することにより、上記第１操作識別情報および上記第２操作識別情報が一致するか否かを判断することとしてもよい。

上記表示制御部は、上記第１関数名および上記第２関数名が一致するか否かに加えて、上記第１関数に与えられる引数および上記第２関数に与えられる引数が一致するか否かをさらに判断することにより、上記第１操作識別情報および上記第２操作識別情報が一致するか否かを判断することとしてもよい。

上記受信部は、上記実行要求に対する応答として上記実行要求に含まれる上記被選択操作識別情報により識別される操作が上記情報提供装置により実行されて得られた結果である実行結果を含む応答である実行応答を受信し、上記表示制御部は、上記受信部により受信された上記実行応答に含まれる上記実行結果を上記表示部に表示させることとしてもよい。

上記表示制御部は、上記実行結果に含まれるメッセージに種別が付加されている場合には、上記種別に応じた表示形式により上記メッセージを上記表示部に表示させることとしてもよい。

上記受信部は、上記情報提供装置により上記第１操作内容情報を上記情報処理装置に送信可能か否かを示す送信可否情報を上記情報提供装置からさらに受信し、上記情報処理装置は、上記受信部により受信された上記送信可否情報が上記情報提供装置により上記第１操作内容情報を上記情報処理装置に送信可能であることを示すか否かを判断する送信可否判断部と、上記送信可否判断部により上記送信可否情報が上記第１操作内容情報を送信可能であることを示すと判断された場合に、上記第１操作内容情報を取得するための要求である取得要求を生成する取得要求生成部と、をさらに備え、上記送信部は、上記取得要求生成部により生成された上記取得要求を上記情報提供装置に送信し、上記受信部は、上記取得要求に対する応答として上記情報提供装置から上記第１操作内容情報を受信することとしてもよい。

上記情報処理装置は、上記情報提供装置により保持されているコンテンツを識別するためのコンテンツ識別情報と上記コンテンツに関連するコンテンツ関連情報とを取得するための要求である確認要求を生成する確認要求生成部、をさらに備え、上記送信部は、上記確認要求生成部により生成された上記確認要求を上記情報提供装置に送信し、上記受信部は、上記確認要求に対する応答として上記情報提供装置から上記コンテンツ識別情報および上記コンテンツ関連情報を受信し、上記送信可否判断部は、上記受信部により受信された上記コンテンツ関連情報に、上記コンテンツに対して実行される上記第１操作の内容を示す上記第１操作内容情報が上記情報提供装置により上記情報処理装置に送信可能か否かを示す上記送信可否情報が含まれている場合に、上記コンテンツ関連情報から上記送信可否情報を取得し、取得した上記送信可否情報が上記情報提供装置により上記第１操作内容情報を上記情報処理装置に送信可能であることを示すか否かを判断し、上記取得要求生成部は、上記送信可否判断部により上記送信可否情報が上記第１操作内容情報を送信可能であることを示すと判断された場合に、上記コンテンツ識別情報を含む上記取得要求を生成し、上記送信部は、上記取得要求生成部により生成された上記取得要求を上記情報提供装置に送信し、上記受信部は、上記取得要求に対する応答として上記取得要求に含まれる上記コンテンツ識別情報により識別される上記コンテンツに対して実行される上記第１操作の内容を示す上記第１操作内容情報を上記情報提供装置から受信することとしてもよい。

また、本発明の別の実施形態によれば、受信部と、情報提供装置により実行される第２操作の内容を示す第２操作内容情報を記憶するデータ記憶部と、記憶制御部と、画面を生成するために使用される情報である画面情報を記憶する画面情報記憶部と、表示制御部と、を備える情報処理装置の上記受信部により、上記情報提供装置により実行される第１操作の内容を示す第１操作内容情報を上記情報提供装置から受信するステップと、上記記憶制御部により、上記受信部により受信された上記第１操作内容情報を上記データ記憶部に記憶させるステップと、上記表示制御部により、上記画面情報記憶部により記憶されている上記画面情報に基づいて、上記データ記憶部により記憶されている上記第１操作内容情報および上記第２操作内容情報が設定された画面を生成して表示部に表示させるステップと、を含む、情報処理方法が提供される。

また、本発明の別の実施形態によれば、コンピュータを、情報提供装置により実行される第１操作の内容を示す第１操作内容情報を上記情報提供装置から受信する受信部と、上記情報提供装置により実行される第２操作の内容を示す第２操作内容情報を記憶するデータ記憶部と、上記受信部により受信された上記第１操作内容情報を上記データ記憶部に記憶させる記憶制御部と、画面を生成するために使用される情報である画面情報を記憶する画面情報記憶部と、上記画面情報記憶部により記憶されている上記画面情報に基づいて、上記データ記憶部により記憶されている上記第１操作内容情報および上記第２操作内容情報が設定された画面を生成して表示部に表示させる表示制御部と、を備える、情報処理装置として機能させるためのプログラムが提供される。

また、本発明の別の実施形態によれば、自装置が実行する第１操作の内容を示す第１操作内容情報および上記第１操作を識別するための第１操作識別情報を記憶する記憶部と、上記記憶部により記憶されている上記第１操作内容情報および上記第１操作識別情報を情報処理装置に送信する送信部と、上記情報処理装置により上記第１操作識別情報および第２操作の内容を示す第２操作識別情報のいずれか１つが被選択操作識別情報として選択された後、上記被選択操作識別情報を含む要求である実行要求を受信する受信部と、上記受信部により受信された上記実行要求に含まれる上記被選択操作識別情報により識別される操作を実行する実行部と、を備える、情報提供装置が提供される。

また、本発明の別の実施形態によれば、情報提供装置と、情報処理装置とを有する情報処理システムであって、上記情報提供装置は、自装置が実行する第１操作の内容を示す第１操作内容情報を記憶する記憶部と、上記記憶部により記憶されている上記第１操作内容情報を上記情報処理装置に送信する送信部と、を備え、上記情報処理装置は、上記第１操作内容情報を上記情報提供装置から受信する受信部と、上記情報提供装置により実行される第２操作の内容を示す第２操作内容情報を記憶するデータ記憶部と、上記受信部により受信された上記第１操作内容情報を上記データ記憶部に記憶させる記憶制御部と、画面を生成するために使用される情報である画面情報を記憶する画面情報記憶部と、上記画面情報記憶部により記憶されている上記画面情報に基づいて、上記データ記憶部により記憶されている上記第１操作内容情報および上記第２操作内容情報が設定された画面を生成して表示部に表示させる表示制御部と、を備える、情報処理システムが提供される。

以上説明したように、本発明によれば、クライアント自身があらかじめ保持している画面とサーバによって生成された画面との間に生じる親和性の悪さを解消しつつ、サーバとクライアントとの間で使用されるプロトコルの変化に柔軟に対応することができる。

サーバが画面生成を行うクライアントサーバシステムについて説明するための図である。 クライアントが画面生成を行うクライアントサーバシステムについて説明するための図である。 クライアント自身があらかじめ保持している画面の表示例を示す図である。 本実施形態に係る情報処理装置によりあらかじめ保持しているメニュー項目と情報提供装置から受信したメニュー項目とを統合して生成した画面の表示例を示す図である。 本実施形態に係る情報処理システムが有する機能の概要を説明するための図である。 本実施形態に係る情報提供装置の機能構成を示す図である。 本実施形態に係る情報処理装置の機能構成を示す図である。 本実施形態に係る情報提供装置から送信されるメニュー項目の意味合いをユースケースごとに示す図である。 本実施形態に係る情報処理装置により実行されるコマンドをユースケースごとに示す図である。 本実施形態に係るリモートオペレーションの拡張定義を用いているか否かを示すオペレーションタイプについて説明するための図である。 本実施形態に係る情報処理システムが適用される各ユースケースをサポートするために各プロパティが必要か否かを示す図である。 本実施形態に係る情報処理システムが適用される各ユースケースをサポートするために各コマンドが必要か否かを示す図である。 本実施形態に係る情報処理システムにより使用される各プロパティについて説明するための図である。 本実施形態に係る情報処理システムにより使用される各変数について説明するための図である。 本実施形態に係る情報処理システムにより使用される各コマンドについて説明するための図である。 本実施形態に係る情報処理システムにより使用されるコマンド（その１）の引数および返却値について説明するための図である。 本実施形態に係る情報処理システムにより使用されるコマンド（その１）の返却値の種類について説明するための図である。 本実施形態に係る情報処理システムにより使用されるコマンド（その２）の引数および返却値について説明するための図である。 本実施形態に係る情報処理システムにより使用されるコマンド（その２）の返却値の種類について説明するための図である。 本実施形態に係る情報処理システムにより使用されるコマンド（その３）の引数および返却値について説明するための図である。 本実施形態に係る情報処理システムにより使用されるコマンド（その３）の返却値の種類について説明するための図である。 本実施形態に係る情報処理システムにより使用されるコマンド（その４）の引数および返却値について説明するための図である。 本実施形態に係る情報処理システムにより使用されるコマンド（その４）の返却値の種類について説明するための図である。 本実施形態に係る情報提供装置により送信される取得応答の記述例を示す図である。 本実施形態に係る情報提供装置により送信される取得応答の記述例および表示例を示す図である。 本実施形態に係る情報処理装置により選択された操作識別情報を含む実行要求の記述例を示す図である。 本実施形態に係る情報提供装置により送信される実行応答の記述例を示す図（その１）である。 本実施形態に係る情報提供装置により送信される実行応答の記述例を示す図（その２）である。 本実施形態に係る情報処理システムの適用例（その１）について説明するための図である。 本実施形態に係る情報処理システムの適用例（その２）について説明するための図である。 本実施形態に係る情報処理装置によりコンテンツの種類から表示すべきメニュー項目を特定するための情報を示す図である。 本実施形態に係る情報処理装置があらかじめ保持しているメニュー項目から実行すべきコマンドを特定するための情報を示す図である。 本実施形態に係る情報提供装置から送信されるメニュー項目から実行すべきコマンドを特定するための情報を示す図である。 本実施形態に係る情報処理装置により実行される処理の流れを示すフローチャートである。 本実施形態に係る情報処理装置があらかじめ保持しているメニュー項目と本実施形態に係る情報提供装置から送信されるメニュー項目との合成について説明するための図である。 メッセージの種類を示すラベルが付加されたメッセージを含む実行応答の記述例を示す図である。 メッセージの種類とラベルの値との対応例を示す図である。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付すことにより重複説明を省略する。

また、以下の順序にしたがって当該「発明を実施するための形態」を説明する。
１．実施形態
１−１． サーバが画面生成を行うクライアントサーバシステム
１−２． クライアントが画面生成を行うクライアントサーバシステム
１−３． クライアント自身があらかじめ保持している画面の表示例
１−４． メニュー項目を統合して生成した画面の表示例
１−５． 情報処理システムが有する機能の概要
１−６． 情報提供装置の機能構成
１−７． 情報処理装置の機能構成
１−８． 情報提供装置から送信されるメニュー項目の意味合い
１−９． 情報処理装置により実行されるコマンド
１−１０．拡張定義を用いているか否かを示すオペレーションタイプ
１−１１．各ユースケースをサポートするために必要なプロパティ
１−１２．各ユースケースをサポートするために必要なコマンド
１−１３．情報処理システムにより使用される各プロパティ
１−１４．情報処理システムにより使用される変数
１−１５．情報処理システムにより使用されるコマンド
１−１６．コマンド（その１）の引数および返却値
１−１７．コマンド（その１）の返却値の種類
１−１８．コマンド（その２）の引数および返却値
１−１９．コマンド（その２）の返却値の種類
１−２０．コマンド（その３）の引数および返却値
１−２１．コマンド（その３）の返却値の種類
１−２２．コマンド（その４）の引数および返却値
１−２３．コマンド（その４）の返却値の種類
１−２４．取得応答の記述例
１−２５．取得応答の記述例および表示例
１−２６．実行要求の記述例
１−２７．実行応答の記述例（その１）
１−２８．実行応答の記述例（その２）
１−２９．情報処理システムの適用例（その１）
１−３０．情報処理システムの適用例（その２）
１−３１．コンテンツの種類からメニュー項目を特定するための情報
１−３２．情報処理装置が保持しているメニュー項目とコマンドとの対応
１−３３．情報提供装置から送信されるメニュー項目とコマンドとの対応
１−３４．情報処理装置により実行される処理の流れ
１−３５．メニュー項目の合成
１−３６．ラベルが付加されたメッセージを含む実行応答
１−３７．メッセージの種類とラベルの値との対応
２．変形例
３．まとめ

＜１．実施形態＞
［１−１．サーバが画面生成を行うクライアントサーバシステム］
図１は、サーバが画面生成を行うクライアントサーバシステムについて説明するための図である。図１に示すように、このクライアントサーバシステムでは、クライアントＣＬ１に表示される画面ＧＵがサーバＳＶ１によって生成される。サーバＳＶ１からクライアントＣＬ１に画面が送信されるに際しては、固定されたＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）転送方式が使用される。このようなクライアントサーバシステムとしては、例えば、ＷｅｂサーバによりＷｅｂ画面を生成するシステムや、ＩＰＴＶのサーバによりテレビなどの電子機器に配信するための画面を生成するシステム、リモートデスクトップにおいて操作対象のコンピュータにより手元のコンピュータに表示させる画面を生成するシステムなどがある。

このようなシステムは、クライアントＣＬ１に元々備わっている画面表示の機能により生成される画面とサーバＳＶ１により生成される画面との間の親和性が悪いという性質を有している。さらに、このようなシステムでは、クライアントＣ１は、サーバＳＶ１によって生成される画面の表示については他のクライアントとの差別化が図れないという性質を有している。

［１−２．クライアントが画面生成を行うクライアントサーバシステム］
図２は、クライアントが画面生成を行うクライアントサーバシステムについて説明するための図である。図２に示すように、このクライアントサーバシステムでは、クライアントＣＬ２に表示される画面ＧＵがクライアントＣＬ２自身によって生成される。クライアントＣＬ２とサーバＳＶ２との間の通信に使用されるプロトコルは変化する。このようなクライアントサーバシステムとしては、例えば、ＤＬＮＡなどのプロトコルにしたがって動作するクライアントＣＬ２が画面を生成するシステムなどがある。

このようなシステムは、サーバＳＶ２とクライアントＣＬ２との間で使用されるプロトコルが変化した場合などに、変化した後のプロトコルに応じて、クライアントＣＬ２による画面生成の機能を変更する必要が生じてしまうという性質がある。

本明細書では、サーバが画面生成を行うクライアントサーバシステムや、クライアントが画面生成を行うクライアントサーバシステムが有する性質を備えることのない情報処理システムについて詳細に説明する。

［１−３．クライアント自身があらかじめ保持している画面の表示例］
図３は、クライアント自身があらかじめ保持している画面の表示例を示す図である。クライアント自身があらかじめ保持している画面Ｇ１１には、コンテンツを示すボタン（「トラック１」〜「トラック４」と記載されているボタン）が設定されており、「トラック２」にフォーカスが当てられている。

「トラック２」にフォーカスが当てられている状態で、フォーカスが当てられているコンテンツを選択するための指示がクライアントに対して与えられると、「トラック２」に相当するコンテンツに対して行うことが可能な操作内容情報（以下、「メニュー項目」とも言う。）が画面Ｇ１２のウィンドウ内に表示される。図３に示した例では、「トラック２」に相当するコンテンツに対して行うことが可能な操作内容情報として、「再生」「詳細情報」が表示されている。

以下において、例えば、要求や応答に含まれる各種の情報は、情報の種別ごとに規定された要求や応答における所定位置に送信元により設定され、所定位置から送信先により取得される。

［１−４．メニュー項目を統合して生成した画面の表示例］
図４は、本実施形態に係る情報処理装置によりあらかじめ保持しているメニュー項目と情報提供装置から受信したメニュー項目とを統合して生成した画面の表示例を示す図である。図４に示すように、情報処理装置２００自身があらかじめ保持している画面Ｇ２１には、コンテンツを示すボタン（「トラック１」〜「トラック４」と記載されているボタン）が設定されており、「トラック２」にフォーカスが当てられている。

「トラック２」にフォーカスが当てられている状態で、フォーカスが当てられているコンテンツを選択するための指示が情報処理装置２００に対して与えられると、「トラック２」に相当するコンテンツに対して行うことが可能なメニュー項目が画面Ｇ２２のウィンドウ内に表示される。図４に示した例では、「トラック２」に相当するコンテンツに対して行うことが可能なメニュー項目として、「再生」「詳細情報」「お気に入り」「レート」が表示されている。このうち、「再生」「詳細情報」は、情報処理装置２００自身があらかじめ保持しているメニュー項目であり、「お気に入り」「レート」は、情報提供装置１００から受信したメニュー項目である。

「トラック２」にフォーカスが当てられている状態で、フォーカスをメニュー項目間で移動させるための指示が情報処理装置２００に対して与えられると、画面Ｇ２３のウィンドウ内でフォーカスが移動し、メニュー項目「お気に入り」にフォーカスが当てられる。「トラック２」「お気に入り」にフォーカスが当てられている状態で、操作を実行させるための指示が情報処理装置２００に対して与えられると、「トラック２」に相当するコンテンツを「お気に入り」に登録する処理が実行される。画面Ｇ２４には、「お気に入りに登録しました」というメッセージが表示されている。

以上に示したように、本実施形態では、情報処理装置２００が、自己の有する画面情報に基づいて、あらかじめ保持しているメニュー項目と情報提供装置１００から受信したメニュー項目とを統合して生成した画面を表示する。情報処理装置２００は、メニュー項目の表示位置などといった画面情報としては、あらかじめ保持しているものを使用し、メニュー項目自体については、あらかじめ保持しているものと情報提供装置１００から受信したものとの両方を使用する。

このようにすれば、あらかじめ保持しているメニュー項目と情報提供装置１００から受信したメニュー項目とを親和させて表示することができる。このような手法を、以下ではＲＯＰ（Ｒｅｍｏｔｅ ＯＰｅｒａｔｉｏｎ）と呼ぶことにする。また、情報処理装置２００をＲＯＰクライアントと称することもあり、情報提供装置１００をＲＯＰサーバと称することもある。

［１−５．情報処理システムが有する機能の概要］
図５は、本実施形態に係る情報処理システムが有する機能の概要を説明するための図である。図５に示すように、情報処理システム１０は、情報提供装置１００と、情報処理装置２００とを有するものである。情報提供装置１００と情報処理装置２００とは、例えば、同一のホームネットワーク内に存在するものであり、情報提供装置１００は、例えば、ＤＭＳ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｓｅｒｖｅｒ）として機能するものであり、情報処理装置２００は、例えば、ＤＭＰ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｐｌａｙｅｒ）として機能するものである。すなわち、情報処理装置２００は、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）にしたがって、情報提供装置１００からコンテンツやコンテンツリストを取得する。

また、例えば、情報提供装置１００がＤＭＳとして機能するものであるとし、情報処理装置２００がＤＭＲ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｒｅｎｄｅｒｅｒ）として機能するものであるとすることもできる。これについては、図２９および図３０を参照して後に改めて説明する。コンテンツの種類としては、音楽データ、映像データ、テキストデータなどが想定されるが特に限定されるものではない。

図５に示すように、情報処理システム１０は、ＲＯＰ対応チェック、追加オペレーションメニューの取得、オペレーションメニューの実行の順に処理を実行する。上記では、追加オペレーションメニューは、情報提供装置１００から受信するメニュー項目を意味する。例えば、ＲＯＰ対応チェックにおいて、情報提供装置１００がＤＭＳとして機能する場合には、情報処理装置２００は、情報提供装置１００により提供されるＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）を使用して追加オペレーションメニューのあるＣＤＳオブジェクト（コンテンツ）はどれかを確認する。また、ＲＯＰ対応チェックにおいて、例えば、情報提供装置１００がＤＭＲとして機能する場合には、情報処理装置２００は、いま情報提供装置１００にセットされているコンテンツに追加オペレーションメニューはあるかを確認する。

続いて、情報処理装置２００は、追加オペレーションメニューのあるコンテンツについて追加オペレーションを取得する。その後、情報処理装置２００は、オペレーションメニューを実行する。

情報提供装置１００がＤＭＳとして機能する場合には、情報処理装置２００は、例えば、コマンド「ＣＤＳ：Ｂｒｏｗｓｅ（）」によりコンテンツのメタデータを取得し、そのメタデータとして「ａｖ：ｍｓＯｐｌｉｓｔ」を含むかどうかによってＲＯＰ対応チェックを行い、情報提供装置１００がＤＭＲとして機能する場合には、情報処理装置２００は、例えば、コマンド「ＡＶＴ：ＧｅｔＰｏｓｉｔｉｏｎＩｎｆｏ（）」により現在セットされているコンテンツのメタデータを取得し、そのメタデータとして「ａｖ：ｍｒＯｐｌｉｓｔ」を含むかどうかによりＲＯＰ対応チェックを行う。

また、情報提供装置１００がＤＭＳとして機能する場合には、情報処理装置２００は、例えば、コマンド「ＣＤＳ：Ｘ＿ＧｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ（）」により追加オペレーションメニューの取得を行い、情報提供装置１００がＤＭＲとして機能する場合には、情報処理装置２００は、例えば、コマンド「ＡＶＴ：Ｘ＿ＧｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ（）」によりにより追加オペレーションメニューの取得を行う。追加オペレーションメニューは、例えば、「ＯｐＬｉｓｔ」として情報提供装置１００から情報処理装置２００に返信される。

また、情報提供装置１００がＤＭＳとして機能する場合には、情報処理装置２００は、例えば、コマンド「ＣＤＳ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ（）」によりオペレーションメニューの実行を行い、情報提供装置１００がＤＭＲとして機能する場合には、情報処理装置２００は、例えば、コマンド「ＡＶＴ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ（）」によりにオペレーションメニューの実行を行う。オペレーションメニューの実行結果は、例えば、「結果表示用情報」として情報提供装置１００から情報処理装置２００に返信される。

［１−６．情報提供装置の機能構成］
図６は、本実施形態に係る情報提供装置の機能構成を示す図である。情報提供装置１００は、少なくとも、記憶部１３０と、送信部１４０と、受信部１１０と、実行部１２４とを備えるものである。

記憶部１３０は、情報提供装置１００が実行する第１操作の内容を示す第１操作内容情報および第１操作を識別するための第１操作識別情報を記憶する機能を有するものである。上記した例では、第１の操作は、コンテンツをお気に入りに登録する操作や、コンテンツのレートを変更する操作などであり、第１操作内容情報は、文字列「お気に入り」「レート」などであり、第１操作識別情報は、コンテンツをお気に入りに登録する処理を識別するための情報や、コンテンツのレートを変更する操作を識別するための情報などである。記憶部１３０は、例えば、ＨＤＤや半導体メモリなどの記憶装置によって構成されるものである。

送信部１４０は、記憶部１３０により記憶されている第１操作内容情報および第１操作識別情報を情報処理装置２００に送信する機能を有するものである。送信部１４０は、例えば、通信装置によって構成され、情報処理装置２００との通信インタフェースとして機能するものである。

受信部１１０は、情報処理装置２００により第１操作識別情報および第２操作の内容を示す第２操作識別情報のいずれか１つが被選択操作識別情報として選択された後、被選択操作識別情報を含む要求である実行要求を受信する機能を有するものである。上記した例では、第２の操作は、コンテンツを再生する操作や、コンテンツの詳細情報を表示する操作などであり、第２操作内容情報は、文字列「再生」「詳細情報」などであり、第２操作識別情報は、コンテンツを再生する操作を識別するための情報や、コンテンツの詳細情報を表示する操作を識別するための情報などである。受信部１１０は、例えば、通信装置によって構成され、情報処理装置２００との通信インタフェースとして機能するものである。

実行部１２４は、受信部１１０により受信された実行要求に含まれる被選択操作識別情報により識別される操作を実行する機能を有するものである。実行要求は、図５に示した例では、情報処理装置２００によりコマンド「ＣＤＳ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ（）」または「ＡＶＴ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ（）」が実行されることにより受信される。実行部１２４は、例えば、受信部１１０により受信された実行要求に含まれる被選択操作識別情報がコンテンツを再生する操作を識別するための情報である場合には、その識別情報により識別される操作であるコンテンツの再生操作を実行する。

情報提供装置１００は、確認部１２２をさらに備えることとしてもよい。確認部１２２は、受信部１１０により受信された確認要求に対する応答として、記憶部１３０により記憶されているコンテンツを識別するためのコンテンツ識別情報とコンテンツに関連するコンテンツ関連情報とを含む応答である確認応答を生成する機能を有するものである。確認応答は、送信部１４０により情報処理装置２００に送信される。

情報提供装置１００は、取得部１２３をさらに備えることとしてもよい。取得部１２３は、受信部１１０により受信された取得要求に対する応答として、取得要求に含まれているコンテンツ識別情報により識別されるコンテンツのオペレーションリスト（第１操作内容情報）を記憶部１３０から取得し、取得したオペレーションリストを含む応答である取得応答を生成する機能を有するものである。取得応答は、送信部１４０により情報処理装置２００に送信される。

情報提供装置１００は、受信情報判断部１２１をさらに備えることとしてもよい。受信情報判断部１２１は、受信部１１０により受信された情報を判断する機能を有するものである。例えば、受信情報判断部１２１は、受信部１１０により受信された情報に取得要求を識別するための情報が含まれている場合には、受信部１１０により受信された情報が取得要求であると判断してその要求を取得部１２３に出力する。また、例えば、受信情報判断部１２１は、受信部１１０により受信された情報に確認要求を識別するための情報が含まれている場合には、受信部１１０により受信された情報が確認要求であると判断してその要求を確認部１２２に出力する。また、例えば、受信情報判断部１２１は、受信部１１０により受信された情報が実行要求を識別するための情報が含まれている場合には、受信部１１０により受信された情報が実行要求であると判断してその要求を実行部１２４に出力する。

受信情報判断部１２１、確認部１２２、取得部１２３、実行部１２４などを含む制御部１２０は、例えば、ＣＰＵ、ＲＡＭなどにより構成され、ＣＰＵが記憶部１３０によって記憶されているプログラムをＲＡＭに展開して実行することによりその機能が実現されるものである。しかし、このような構成に限らず、受信情報判断部１２１、確認部１２２、取得部１２３、実行部１２４の中には、専用のハードウェアにより構成されるものが存在してもよい。記憶部１３０は、ＣＰＵによるプログラムの実行に際して使用される各種のデータをさらに記憶しているものとしてもよい。

［１−７．情報処理装置の機能構成］
図７は、本実施形態に係る情報処理装置の機能構成を示す図である。情報処理装置２００は、少なくとも、受信部２５０と、データ記憶部２３０と、記憶制御部２２６と、画面情報記憶部２４０と、表示制御部２２２とを備えるものである。

受信部２５０は、情報提供装置１００により実行される第１操作の内容を示す第１操作内容情報を情報提供装置１００から受信する機能を有するものである。第１操作内容情報は、取得応答に含まれて情報提供装置１００から受信される。上記した例では、第１の操作は、コンテンツをお気に入りに登録する操作や、コンテンツのレートを変更する操作などであり、第１操作内容情報は、文字列「お気に入り」「レート」などである。受信部２５０は、例えば、通信装置によって構成され、情報提供装置１００との通信インタフェースとして機能するものである。

データ記憶部２３０は、情報提供装置１００により実行される第２操作の内容を示す第２操作内容情報を記憶する機能を有するものである。上記した例では、第２の操作は、コンテンツを再生する操作や、コンテンツの詳細情報を表示する操作などであり、第２操作内容情報は、文字列「再生」「詳細情報」などである。データ記憶部２３０は、例えば、ＨＤＤや半導体メモリなどの記憶装置によって構成されるものである。

記憶制御部２２６は、受信部２５０により受信された第１操作内容情報をデータ記憶部２３０に記憶させる機能を有するものである。第１操作内容情報は、例えば、オペレーション情報２３１を構成する情報として記憶制御部２２６によりデータ記憶部２３０に登録される。第２操作内容情報は、例えば、オペレーション情報２３１を構成する情報として既にデータ記憶部２３０に登録されている。

画面情報記憶部２４０は、画面を生成するために使用される情報である画面情報２４１を記憶する機能を有するものである。画面情報２４１は、例えば、表示対象となる各情報の画面内における位置を示す情報である。当然のことながら、画面情報２４１には、操作の内容を示す操作内容情報の画面内における位置を示す情報も含まれている。

表示制御部２２２は、画面情報記憶部２４０により記憶されている画面情報２４１に基づいて、データ記憶部２３０により記憶されている第１操作内容情報および第２操作内容情報が設定された画面を生成して表示部２６０に表示させる機能を有するものである。表示制御部２２２が、画面情報記憶部２４０により記憶されている画面情報２４１に基づいて、第１操作内容情報として文字列「お気に入り」「レート」を表示部２６０に表示させるとともに第２操作内容情報として文字列「再生」「詳細情報」を表示部２６０に表示させた結果は、図４の画面Ｇ２２に示すように表示される。

なお、ここでは、表示部２６０が情報処理装置２００の内部に存在することとしているが、表示部２６０は、情報処理装置２００の外部に存在することとしてもよい。表示部２６０は、例えば、表示装置により構成されるものである。

受信部２５０は、第１操作を識別するための第１操作識別情報を情報提供装置１００からさらに受信することとしてもよい。その場合には、データ記憶部２３０は、第２操作を識別するための第２操作識別情報をさらに記憶しており、記憶制御部２２６は、受信部２５０により受信された第１操作識別情報をデータ記憶部２３０にさらに記憶させることとしてもよい。第１操作識別情報は、例えば、オペレーション情報２３１を構成する情報として記憶制御部２２６により第１操作内容情報に対応付けてデータ記憶部２３０に登録される。第２操作内容情報は、例えば、オペレーション情報２３１を構成する情報として既に第２操作内容情報に対応付けてデータ記憶部２３０に登録されている。

また、その場合には、情報処理装置２００は、実行要求生成部２２４と、送信部２７０とをさらに備えることとしてもよい。実行要求生成部２２４は、データ記憶部２３０により記憶されている第１操作識別情報および第２操作識別情報のいずれか１つを被選択操作識別情報として選択し、被選択操作識別情報を含む要求である実行要求を生成する。より詳細には、実行要求生成部２２４は、選択情報２３２によって選択される操作識別情報を被選択操作識別情報として使用する。また、実行要求生成部２２４は、選択情報２３２によって選択されるコンテンツ識別情報をさらに含んだ実行要求を生成してもよい。実行要求のフォーマットについては特に限定されるものではない。

送信部２７０は、実行要求生成部２２４により生成された実行要求を情報提供装置１００に送信する機能を有するものである。送信部２７０は、例えば、通信装置によって構成され、情報提供装置１００との通信インタフェースとして機能するものである。

図４に示した例では、第１操作識別情報は、コンテンツをお気に入りに登録する処理を識別するための情報や、コンテンツのレートを変更する操作を識別するための情報などであり、第２操作識別情報は、コンテンツを再生する操作を識別するための情報や、コンテンツの詳細情報を表示する操作を識別するための情報などである。すなわち、図４に示した例では、第１操作識別情報と第２操作識別情報とが一致してしまう状況も起こり得る。このような場合には、第１操作内容情報と第２操作内容情報とを両方表示してしまうとユーザに混乱を与えてしまう可能性がある。

したがって、例えば、表示制御部２２２は、データ記憶部２３０により記憶されている第１操作識別情報および第２操作識別情報が一致するか否かを判断し、第１操作識別情報および第２操作識別情報が一致すると判断した場合には、第１操作内容情報および第２操作内容情報のいずれか１つの画面への設定を省略することとしてもよい。第１操作内容情報と第２操作内容情報との両方が表示されてしまうことを防ぐことができるので、ユーザに混乱を与えてしまう可能性を低減できる。

画面への設定を省略する操作内容情報として、第１操作内容情報および第２操作内容情報のいずれを選択するかについては様々な手法が想定される。しかし、情報処理装置２００は、第２操作内容情報をあらかじめ保持していることを考慮すると、表示制御部２２２は、第１操作識別情報および第２操作識別情報が一致すると判断した場合に、第１操作内容情報の画面への設定を省略するのがよい。

実行要求生成部２２４は、表示制御部２２２により、第１操作内容情報の画面への設定が省略された場合には第１操作識別情報を選択対象から除外し、第２操作内容情報の画面への設定が省略された場合には第２操作識別情報を選択対象から除外することとしてもよい。このようにすれば、実行要求生成部２２４は、表示制御部２２２により画面への設定が省略された操作内容情報に対応する操作識別情報を選択できなくなるので、ユーザに混乱を与えてしまう可能性をさらに低減できる。

表示制御部２２２は、第１操作識別情報が情報提供装置１００に第１操作を実行させるための関数である第１関数名を含んでいる場合であり、かつ、第２操作識別情報が情報提供装置１００に第２操作を実行させるための関数である第２関数名を含んでいる場合に、第１関数名および第２関数名が一致するか否かを判断することとしてもよい。表示制御部２２２は、例えば、この判断により、第１操作識別情報および第２操作識別情報が一致するか否かを判断することとしてもよい。より詳細には、表示制御部２２２は、第１関数名および第２関数名が一致すれば、第１操作識別情報および第２操作識別情報が一致すると判断し、表示制御部２２２は、第１関数名および第２関数名が一致しなければ、第１操作識別情報および第２操作識別情報が一致しないと判断すればよい。

表示制御部２２２は、第１関数名および第２関数名が一致するか否かに加えて、第１関数に与えられる引数および第２関数に与えられる引数が一致するか否かをさらに判断することとしてもよい。この判断により、第１操作識別情報および第２操作識別情報が一致するか否かを判断することとしてもよい。より詳細には、表示制御部２２２は、第１関数名および第２関数名が一致するか否かに加えて、第１関数に与えられる引数および第２関数に与えられる引数がさらに一致すれば、第１操作識別情報および第２操作識別情報が一致すると判断し、表示制御部２２２は、第１関数名および第２関数名は一致するものの、第１関数に与えられる引数および第２関数に与えられる引数が一致しなければ、第１操作識別情報および第２操作識別情報が一致しないと判断すればよい。さらなる詳細については、図３４および図３５を参照して後に説明する。

受信部２５０は、実行要求に対する応答として、実行要求に含まれる被選択操作識別情報により識別される操作が情報提供装置１００により実行されて得られた結果である実行結果を含む応答である実行応答をさらに受信する機能を有することとしてもよい。その場合には、表示制御部２２２は、受信部２５０により受信された実行応答に含まれる実行結果を表示部２６０に表示させることとしてもよい。図４には、表示制御部２２２が、実行結果である「お気に入りに登録しました」を表示部２６０の画面Ｇ２４に表示させた例が示されている。

表示制御部２２２は、実行結果に含まれるメッセージに種別が付加されている場合には、種別に応じた表示形式によりメッセージを表示部２６０に表示させることとしてもよい。さらなる詳細については、図３６および図３７を参照して後に説明する。

受信部１１０は、情報提供装置１００により第１操作内容情報を情報処理装置２００に送信可能か否かを示す送信可否情報を情報提供装置１００からさらに受信することとしてもよい。その場合には、情報処理装置２００は、受信部２５０により受信された送信可否情報が情報提供装置１００により第１操作内容情報を情報処理装置２００に送信可能であることを示すか否かを判断する送信可否判断部２２７と、送信可否判断部２２７により送信可否情報が第１操作内容情報を送信可能であることを示すと判断された場合に、第１操作内容情報を取得するための要求である取得要求を生成する取得要求生成部２２８と、をさらに備えることとしてもよい。

その場合には、送信部２７０は、取得要求生成部２２８により生成された取得要求を情報提供装置１００に送信し、受信部２５０は、取得要求に対する応答として情報提供装置１００から第１操作内容情報を受信することとしてもよい。

情報処理装置２００は、情報提供装置１００により保持されているコンテンツを識別するためのコンテンツ識別情報とコンテンツに関連するコンテンツ関連情報とを取得するための要求である確認要求を生成する確認要求生成部２２３をさらに備えていてもよい。その場合には、送信部２７０は、確認要求生成部２２３により生成された確認要求を情報提供装置１００に送信し、受信部２５０は、確認要求に対する応答として情報提供装置１００からコンテンツ識別情報およびコンテンツ関連情報を受信する。

送信可否判断部２２７は、受信部２５０により受信されたコンテンツ関連情報に、コンテンツに対して実行される第１操作の内容を示す第１操作内容情報が情報提供装置１００により情報処理装置に送信可能か否かを示す送信可否情報が含まれている場合に、コンテンツ関連情報から送信可否情報を取得し、取得した送信可否情報が情報提供装置１００により第１操作内容情報を情報処理装置２００に送信可能であることを示すか否かを判断する。送信可否判断部２２７は、受信部２５０により受信されたコンテンツ関連情報をコンテンツ情報２３３に登録することとしてもよい。コンテンツ関連情報に、例えば、コンテンツ識別情報などを含んだコンテンツリストや、送信可否情報などを含んだメタデータが含まれていることが想定され、コンテンツ関連情報は、コンテンツ情報２３３として登録されれば、後に使用することができる。

取得要求生成部２２８は、送信可否判断部２２７により送信可否情報が第１操作内容情報を送信可能であることを示すと判断された場合に、コンテンツ識別情報を含む取得要求を生成し、送信部２７０は、取得要求生成部２２８により生成された取得要求を情報提供装置１００に送信し、受信部２５０は、取得要求に対する応答として取得要求に含まれるコンテンツ識別情報により識別されるコンテンツに対して実行される第１操作の内容を示す第１操作内容情報を情報提供装置１００から受信する。

入力情報判断部２２１は、入力部２１０を介してユーザから入力された情報が確認要求送信を指示するための情報であると判断した場合には、確認要求送信を指示するための情報を取得要求生成部２２８に出力する。また、入力情報判断部２２０は、入力部２１０を介してユーザから入力される情報が実行要求送信を指示するための情報であると判断した場合には、実行要求送信を指示するための情報を実行要求生成部２２４に出力する。入力情報判断部２２１は、入力部２１０を介してユーザから入力された情報が選択情報２３２の変更を指示するための情報であると判断した場合には、選択情報２３２の変更を指示するための情報を表示制御部２２２に出力する。

表示制御部２２２は、入力情報判断部２２１から入力された選択情報２３２の変更を指示するための情報に基づいて、選択情報２３２を更新する。選択情報２３２は、オペレーション情報２３１を構成するコンテンツ識別情報と操作識別情報との組み合わせを選択するための情報である。

情報処理装置２００は、受信情報判断部２２５を備えるものとしてもよい。受信情報判断部２２５は、受信部２５０により受信された情報を判断する機能を有するものである。例えば、受信情報判断部２２５は、受信部２５０により受信された情報に取得応答を識別するための情報が含まれている場合には、受信部２５０により受信された情報が取得応答であると判断してその応答を記憶制御部２２６に出力する。また、例えば、受信情報判断部２２５は、受信部２５０により受信された情報に確認応答を識別するための情報が含まれている場合には、受信部２５０により受信された情報が確認応答であると判断してその応答を送信可否判断部２２７に出力する。また、例えば、受信情報判断部２２５は、受信部２５０により受信された情報が実行応答を識別するための情報が含まれている場合には、受信部２５０により受信された情報が実行応答であると判断してその応答を表示制御部２２２に出力する。

入力情報判断部２２１や、表示制御部２２２、確認要求生成部２２３、実行要求生成部２２４、受信情報判断部２２５、記憶制御部２２６、送信可否判断部２２７、取得要求生成部２２８のそれぞれは、例えば、ＣＰＵ、ＲＡＭなどにより構成され、ＣＰＵがデータ記憶部２３０によって記憶されているプログラムをＲＡＭに展開して実行することによりその機能が実現されるものである。しかし、このような構成に限らず、入力情報判断部２２１や、表示制御部２２２、確認要求生成部２２３、実行要求生成部２２４、受信情報判断部２２５、記憶制御部２２６、送信可否判断部２２７、取得要求生成部２２８の中には、専用のハードウェアにより構成されるものが存在してもよい。データ記憶部２３０は、ＣＰＵによるプログラムの実行に際して使用される各種のデータをさらに記憶しているものとしてもよい。

［１−８．情報提供装置から送信されるメニュー項目の意味合い］
図８は、本実施形態に係る情報提供装置から送信されるメニュー項目の意味合いをユースケースごとに示す図である。図８に示すように、本実施形態に係る情報処理装置２００が適用されるユースケースとしては、主に、コンテンツオペレーション（Ｃｏｎｔｅｎｔ Ｏｐｅｒａｔｉｏｎ）とメディアオペレーション（Ｍｅｄｉａ Ｏｐｅｒａｔｉｏｎ）とが想定される。

コンテンツオペレーションは、情報処理装置２００がＤＭＰやＤＭＣから構成され、情報提供装置１００がＤＭＳから構成される場合に、情報処理装置２００が、情報提供装置１００に保持されているＣＤＳのコンテンツを選択しており、オプションボタンの押下を検出したときに、選択しているコンテンツのメニュー項目を表示するものである。図４に示した例がこれに該当する。

メディアオペレーションは、情報処理装置２００がＤＭＣから構成され、情報提供装置１００がＤＭＲから構成される場合に、情報処理装置２００が、オプションボタンの押下を検出したときに、情報提供装置１００にセットされたコンテンツのメニュー項目を表示するものである。

本実施形態に係る情報提供装置から送信されるメニュー項目は、この他、機器設定メニュー（ネットワーク設定など）や、コンテンツ再生時の最初に自動的に表示されるメニュー（規約に同意するか否かを入力させるメニューなど）、コンテンツ再生終了時に自動的に表示されるメニュー（友達にお勧めするか否かを入力させるメニューなど）に適用することができる。

また、共通で済む部分をユースケースごとに最初から作り直すのには仕様開発コスト、設計・実装コストがかかるため、異なるユースケース間においても使用できる共通定義を用意するのが好ましい。後に説明するような、Ｏｐｅｒａｔｉｏｎ Ｌｉｓｔ、Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ、Ｒｅｓｕｌｔ Ｄｏｃｕｍｅｎｔなどが共通定義の例である。このように共通定義を用意しておき、共通定義されたものに対する取得の仕方、セットの仕方（ネットワークＡＰＩなど）のみをユースケースごとに定義すればよい。

これにより、ＤＬＮＡでないプロトコルにもこれらの共通定義を、取得したり、セットしたりするＡＰＩを定義することで、ＲＯＰの使用可能なシーンを増やすことができる。例えば、ＡＶ／Ｃコマンドを追加定義してＩＥＥＥ１３９４にも使用できるようにできる。

［１−９．情報処理装置により実行されるコマンド］
図９は、本実施形態に係る情報処理装置により実行されるコマンドをユースケースごとに示す図である。ユースケースについては、図８に示した通りである。情報処理装置により実行されるコマンドは、図５を参照して説明したコマンドに対応している。

［１−１０．拡張定義を用いているか否かを示すオペレーションタイプ］
図１０は、本実施形態に係るリモートオペレーションの拡張定義を用いているか否かを示すオペレーションタイプについて説明するための図である。ｏｐｅｒａｔｉｏｎ ｔｙｐｅがｃｏｍｍｏｎの場合には、ＲＯＰに対応できる情報処理装置２００にとって必須部分の規定がなされる。また、さらに追加として、ＢＩＶＬ（Ｂｒａｖｉａ Ｉｎｔｅｒｎｅｔ Ｖｉｄｅｏ Ｌｉｎｋ）のようにより高度なＵＩ遷移を含むオペレーションを拡張定義することができる。ＢＩＶＬは、テレビに対してインターネットを介してサーバがコンテンツを提供するサービスの種類である。

例えば、リモートオペレーション対応をチェックする際に、ｏｐｅｒａｔｉｏｎ ｔｙｐｅという概念を導入することで、拡張定義を用いているかどうかの判別を可能とすることができる。例えば、図１０に示すようなｏｐｅｒａｔｉｏｎ ｔｙｐｅを定義することができる。

「ｒｅｓｕｌｔ ｉｎｆｏｒｍａｔｉｏｎ」や、「ｏｐｅｒａｔｉｏｎ ｌｉｓｔ」にはいろいろな工夫が考えられるが、全ての工夫を全てのクライアントが解釈可能であることを要求すると、あまり使われない工夫も全ての機器の組み合わせで不必要に実装することになってしまい、コストが高くなってしまう。したがって、いろいろな工夫のうちで、必須で対応（解釈可能）としなければいけない工夫を定義する（ｃｏｍｍｏｎ ｔｙｐｅ）。その他の工夫のうち、あるユースケース（ＢＩＶＬのコンテンツを中継したいなどといったユースケース）では必要、というものをまとめて、ｐｒｏｆｉｌｅ化する（例えば、ｂｉｖｌ ｔｙｐｅとする）。後者のｏｐｔｉｏｎａｌ ｐｒｏｆｉｌｅについて、サーバは自分の提供したいＲＯＰはどのｐｒｏｆｉｌｅをサポートしていれば解釈できるかをクライアントにわかるようにする。例えば、「ａｖ：ｍｓＯｐＬｉｓｔ」タグの値などを使用することとすればよい。

［１−１１．各ユースケースをサポートするために必要なプロパティ］
図１１は、本実施形態に係る情報処理システムが適用される各ユースケースをサポートするために各プロパティが必要か否かを示す図である。図１１において、Ｒはユースケースをサポートする場合に必須とするものである。

［１−１２．各ユースケースをサポートするために必要なコマンド］
図１２は、本実施形態に係る情報処理システムが適用される各ユースケースをサポートするために各コマンドが必要か否かを示す図である。上記したように、ユースケース「Ｃｏｎｔｅｎｔ Ｏｐｅｒａｔｉｏｎ」では、ＤＭＳがＲＯＰサーバとなる。ＤＭＳを参照するＤＭＰやＤＭＣなどがＲＯＰクライアントとなる。

ＤＭＰなどがコンテンツの選択時の操作メニューをＵＩ表示する際、リモートオペレーションを用いると、ＤＭＳが提供するオペレーションリストを操作メニューに追加することができる。ＤＬＮＡでは、ＤＭＳがコンテンツリストをＤＩＤＬ−Ｌｉｔｅ ＸＭＬドキュメントで提供する。コンテンツのメタデータはコンテンツを表すＣＤＳオブジェクトに含まれるプロパティ（ＸＭＬ要素・属性）として提供される。ここで、本実施形態に係るオペレーションリストを提供可能なオブジェクトにはプロパティとして「ａｖ：ｍｓＯｐＬｉｓｔ」が付加されることとすることができる。

「ａｖ：ｍｓＯｐＬｉｓｔ」を持つＣＤＳオブジェクトのＣＤＳオブジェクトＩＤ（＠ｉｄ）を指定して、「ＣＤＳ：：Ｘ＿ＧｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ ａｃｔｉｏｎ」を発行すると、オペレーションリストＸＭＬドキュメントを得ることができる。情報処理装置２００は、オペレーションリストを解釈することで、そのＣＤＳオブジェクトに対応するオペレーションをＵＩに追加することができる。

ユーザがオペレーションリストに含まれるオペレーションを行ったときに、そのオペレーションの「Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ」を指定して「ＣＤＳ：：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ ａｃｔｉｏｎ」を発行する。「Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ」はオペレーションリストドキュメントに記載されている。「Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ ａｃｔｉｏｎ」の「ｒｅｓｐｏｎｓｅ」の「Ｒｅｓｕｌｔ Ａｒｇｕｍｅｎｔ」には、エラー時のメッセージ用文字列など、実行後のＵＩに必要な情報が含まれている。

上記したように、ユースケース「Ｍｅｄｉａ Ｏｐｅｒａｔｉｏｎ」では、ＤＭＲがＲＯＰサーバとなる。ＤＭＲを参照するＰｕｓｈ ＣｏｎｔｒｏｌｌｅｒやＤＭＣなどがＲＯＰクライアントとなる。ＤＭＣなどがＤＭＲにセットされているコンテンツの操作メニューをＵＩ表示する際、リモートオペレーションを用いると、ＤＭＲが提供するオペレーションリストを操作メニューに追加することができる。

ＤＬＮＡでは、ＤＭＲがセットされているコンテンツのメタデータを「ＡＶＴ：：ＧｅｔＰｏｓｉｔｉｏｎＩｎｆｏ」等を用いてＤＩＤＬ−Ｌｉｔｅ ＸＭＬドキュメントで提供する。このドキュメントに、本実施形態に係るオペレーションリストを提供可能な場合には「ａｖ：ｍｒＯｐＬｉｓｔ」を付加することができる。「ａｖ：ｍｒＯｐＬｉｓｔ」を持つ「ＡＶＴ ＩｎｓｔａｎｃｅのＩｎｓｔａｎｃｅ ＩＤを指定して、「ＡＶＴ：：Ｘ＿ＧｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ ａｃｔｉｏｎ」を発行すると、オペレーションリストＸＭＬドキュメントを得ることができる。情報処理装置２００は、オペレーションリストを解釈することで、オペレーションをＵＩに追加することができる。

ユーザがオペレーションリストに含まれるオペレーションを行ったときに、そのオペレーションの「Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ」を指定して「ＡＶＴ：：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ ａｃｔｉｏｎ」を発行する。「Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ」はオペレーションリストドキュメントに記載されている。「Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ ａｃｔｉｏｎ」のｒｅｓｐｏｎｓｅの「Ｒｅｓｕｌｔ Ａｒｇｕｍｅｎｔ」には、エラー時のメッセージ用文字列など、実行後のＵＩに必要な情報が含まれている。

［１−１３．情報処理システムにより使用される各プロパティ］
図１３は、本実施形態に係る情報処理システムにより使用される各プロパティについて説明するための図である。ＤＩＤＬ−Ｌｉｔｅ ＸＭＬドキュメント内でＯｂｊｅｃｔに配置されるプロパティに、図１３に示されるようなＤｅｓｃｒｉｐｔｉｏｎを追加する。
ｎａｍｅｓｐａｃｅには、例えば、「ｕｒｎ：ｓｃｈｅｍａｓ−ｓｏｎｙ−ｃｏｍ：ａｖ」を用い、ｎａｍｅｓｐａｃｅ ｐｒｅｆｉｘとして「ａｖ」を用いることができる。

［１−１４．情報処理システムにより使用される変数］
図１４は、本実施形態に係る情報処理システムにより使用される各変数について説明するための図である。“Ｘ＿”で始まらない変数は、ＵＰｎＰ ＡＶ ＣＤＳ／ＡＶＴの同名Ｓｔａｔｅ Ｖａｒｉａｂｌｅと同じ定義であるので、図１４には示していない。「ＣＤＳ／ＡＶＴ：Ｘ＿Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＯｐｅｒａｔｉｏｎＬｉｓｔ」は、ＸＭＬエスケープしたＯｐｅｒａｔｉｏｎＬｉｓｔドキュメントを含む。「Ｘ＿Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＡｃｔｉｏｎＤｉｒｅｃｔｉｖｅ」は、どのオペレーション、パラメータが選択されたかを示す、「Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ」を含む。「Ｘ＿Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＲＯＰＲｅｓｕｌｔ」は、ＸＭＬエスケープしたＲｅｓｕｌｔドキュメントを含む。

［１−１５．情報処理システムにより使用されるコマンド］
図１５は、本実施形態に係る情報処理システムにより使用される各コマンドについて説明するための図である。「ＣＤＳ：Ｘ＿ＧｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ」ａｃｔｉｏｎは、指定したＣＤＳオブジェクトＩＤに応じたオペレーションリストを返すものである。「ＣＤＳ：Ｘ＿ＧｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ」ａｃｔｉｏｎは、指定したオブジェクトＩＤが存在しない場合は７０１を、対応するオブジェクトがオペレーションリストを持っていない場合には８０５を返す。

「ＣＤＳ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ」ａｃｔｉｏｎは、指定したオブジェクトＩＤのオペレーションリストの「ＡｃｔｉｏｎＤｉｒｅｃｔｉｖｅ」に相当するオペレーションを実行する。「ＣＤＳ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ」ａｃｔｉｏｎの実行結果は「Ｒｅｓｕｌｔ」として返される。「ｒｅｓｕｌｔ ｉｎｆｏｒｍａｔｉｏｎ」を含まない場合は、「Ｒｅｓｕｌｔ Ａｒｇｕｍｅｎｔ」は空であってもよい。

また、「ＣＤＳ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ」ａｃｔｉｏｎにより、返された時点でのオブジェクトのＣＤＳ ＵｐｄａｔｅＩＤも返される。ＣＤＳ ＵｐｄａｔｅＩＤは、Ｂｒｏｗｓｅ（）によって確認するときのＵｐｄａｔｅＩＤと同じ扱いのものである。ＲＯＰクライアントは、ＵｐｄａｔｅＩＤが変化している場合には、オペレーションの結果として（もしくは偶然そのタイミングで）そのオブジェクトの構成が変化したものと判断することができる。

「ＣＤＳ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ」ａｃｔｉｏｎは、指定したオブジェクトＩＤが存在しない場合は７０１を、対応するオブジェクトがオペレーションリストを持っていない場合には８０５を返す。指定した「ＡｃｔｉｏｎＤｉｒｅｃｔｉｖｅ」の内容がオペレーションリストの内容と合致せず、不適切である場合は、８０６を返す。

「ＡＶＴ：Ｘ＿ＧｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ」ａｃｔｉｏｎは、指定したＡＶＴ Ｉｎｓｔａｎｃｅ ＩＤにセットされているコンテンツに応じたオペレーションリストを返すものである。「ＡＶＴ：Ｘ＿ＧｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ」ａｃｔｉｏｎは、指定したＡＶＴ Ｉｎｓｔａｎｃｅ ＩＤが存在しない場合は７１８を、対応するオペレーションリストがない場合には８０５を返す。

「ＡＶＴ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ」ａｃｔｉｏｎは、指定したＡＶＴ Ｉｎｓｔａｎｃｅ ＩＤのオペレーションリストの「ＡｃｔｉｏｎＤｉｒｅｃｔｉｖｅ」に相当するオペレーションを実行する。「ＡＶＴ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ」ａｃｔｉｏｎの実行結果は「Ｒｅｓｕｌｔ」として返される。「ｒｅｓｕｌｔ ｉｎｆｏｒｍａｔｉｏｎ」を含まない場合は、「Ｒｅｓｕｌｔ Ａｒｇｕｍｅｎｔ」は空であってもよい。

「ＡＶＴ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ」ａｃｔｉｏｎは、指定したＡＶＴ Ｉｎｓｔａｎｃｅ ＩＤが存在しない場合は７１８を、対応するオペレーションリストがない場合には８０５を返す。指定した「ＡｃｔｉｏｎＤｉｒｅｃｔｉｖｅ」の内容がオペレーションリストの内容と合致せず、不適切である場合は、８０６を返す。

ここで、ＲＯＰの結果コンテンツのリストの内容が変更されたとしても、クライアントはＲＯＰのセマンティクスを理解していないので、古いリスト表示のままでいるかもしれない。しかしながら、毎回リストを更新するのは、通信コスト、画面表示遷移時間の面で無駄が大きい。そこで、ＲＯＰ処理、もしくは偶然、コンテンツリストの内容が変わったら、クライアントにコンテンツリストの表示の更新を促すため、ＵｐｄａｔｅＩＤの値をｉｎｃｒｅｍｅｎｔすることとしてもよい。これは、ＣＤＳ：ＢｒｏｗｓｅにあるＵｐｄａｔｅＩＤの仕組みと同じである。例えば、多くのコンテンツの入ったリストを、例えば、１０件ずつブラウズしているときに、４回目と５回目の間でＵｐｄａｔｅＩＤが変わったら、リストの内容が陳腐化したと気づき、はじめからブラウズしなおす、といった処理が可能になる。

［１−１６．コマンド（その１）の引数および返却値］
図１６は、本実施形態に係る情報処理システムにより使用されるコマンド（その１）の引数および返却値について説明するための図である。コマンド（その１）は、図１５に示した「ＣＤＳ：Ｘ＿ＧｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ」である。

［１−１７．コマンド（その１）の返却値の種類］
図１７は、本実施形態に係る情報処理システムにより使用されるコマンド（その１）の返却値の種類について説明するための図である。コマンド（その１）は、図１５に示した「ＣＤＳ：Ｘ＿ＧｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ」である。

［１−１８．コマンド（その２）の引数および返却値］
図１８は、本実施形態に係る情報処理システムにより使用されるコマンド（その２）の引数および返却値について説明するための図である。コマンド（その２）は、図１５に示した「ＣＤＳ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ」である。

［１−１９．コマンド（その２）の返却値の種類］
図１９は、本実施形態に係る情報処理システムにより使用されるコマンド（その２）の返却値の種類について説明するための図である。コマンド（その２）は、図１５に示した「ＣＤＳ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ」である。

［１−２０．コマンド（その３）の引数および返却値］
図２０は、本実施形態に係る情報処理システムにより使用されるコマンド（その３）の引数および返却値について説明するための図である。コマンド（その３）は、図１５に示した「ＡＶＴ：Ｘ＿ＧｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ」である。

［１−２１．コマンド（その３）の返却値の種類］
図２１は、本実施形態に係る情報処理システムにより使用されるコマンド（その３）の返却値の種類について説明するための図である。コマンド（その３）は、図１５に示した「ＡＶＴ：Ｘ＿ＧｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ」である。

［１−２２．コマンド（その４）の引数および返却値］
図２２は、本実施形態に係る情報処理システムにより使用されるコマンド（その４）の引数および返却値について説明するための図である。コマンド（その４）は、図１５に示した「ＡＶＴ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ」である。

［１−２３．コマンド（その４）の返却値の種類］
図２３は、本実施形態に係る情報処理システムにより使用されるコマンド（その４）の返却値の種類について説明するための図である。コマンド（その４）は、図１５に示した「ＡＶＴ：Ｘ＿ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ」である。

［１−２４．取得応答の記述例］
図２４は、本実施形態に係る情報提供装置により送信される取得応答の記述例を示す図である。記述例Ｄ１１の「Ｅｌｅｍｅｎｔｓ」「Ａｔｔｒｉｂｕｔｅｓ」について説明する。ｏｐｌｉｓｔには、オペレーションリストドキュメントのｒｏｏｔ ｔａｇ． ｎａｍｅｓｐａｃｅ ｄｅｃｌａｒａｔｉｏｎ （ｘｍｌｎｓ＝…）が配置される。ｎａｍｅｓｐａｃｅとしては、「ｕｒｎ：ｓｃｈｅｍａｓ−ｓｏｎｙ−ｃｏｍ：ａｖ：ｒｏｐｏｐｌｉｓｔ」を用いる。ｏｐｌｉｓｔは、子要素としてひとつ以上のｏｐｅｒａｔｉｏｎを持つ。

ｏｐｅｒａｔｉｏｎは、ひとつのオペレーションを表す。ｏｐｅｒａｔｉｏｎは１６個以内とする。ｏｐｅｒａｔｉｏｎ＠ｔｙｐｅは、オペレーションのタイプを表す。ｏｐｅｒａｔｉｏｎ＠ｔｙｐｅが「ｃｏｍｍｏｎ ｔｙｐｅ」の場合のみ省略することが可能である。ｄｉｓｐｌａｙＳｔｒｉｎｇは、必須であり、オペレーションまたはパラメータをＵＩ表示する際の表示文字列を表すものである。ｄｉｓｐｌａｙＳｔｒｉｎｇは、２５６ｂｙｔｅ以内とする。

ｓｈｏｒｔＤｉｓｐｌａｙＳｔｒｉｎｇは、「ｃｏｍｍｏｎ ｔｙｐｅ」の場合に、ｄｉｓｐｌａｙＳｔｒｉｎｇの文字列長が３２ｂｙｔｅより大きい場合は、必須である。ｄｉｓｐｌａｙＳｔｒｉｎｇの文字列長が３２ｂｙｔｅ以下である場合は、オプションである。ｓｈｏｒｔＤｉｓｐｌａｙＳｔｒｉｎｇは、オペレーションまたはパラメータをＵＩ表示する際の表示文字列で、短い表示領域しかもたない機器がｄｉｓｐｌａｙＳｔｒｉｎｇの代わりに用いる。ｓｈｏｒｔＤｉｓｐｌａｙＳｔｒｉｎｇは、３２ｂｙｔｅ以内とする。

ｓｅｌｅｃｔｅｄは、オプションである。リストをＵＩ表示するときに、そのオペレーションまたはパラメータをデフォルトで選択状態にするべきであることを示す。ｓｅｌｅｃｔｅｄは、オペレーションリスト内の一つ以下のオペレーションにつく。ｓｅｌｅｃｔｅｄは、パラメータにつく場合は、オペレーションごとに、パラメータリスト内の一つ以下のパラメータにつく。

ｃｏｎｆｉｒｍは、オプションであり、そのオペレーションまたはパラメータを選択したときに、本当に実行するかの再確認をすべきかを示すものである。再確認の仕方については限定されない。ｉｃｏｎＵｒｌは、オプションであり、そのオペレーションまたはパラメータを表すアイコンを取得できるＵＲＬを示す。ｉｃｏｎＵｒｌ＠ｐｒｏｆｉｌｅは、ｉｃｏｎＵｒｌがある場合には必須である。ｉｃｏｎＵｒｌ＠ｐｒｏｆｉｌｅは、アイコンのフォーマットを示す。現在のところアイコンのフォーマットはＤＬＮＡのＪＰＥＧ＿ＴＮ ｐｒｏｆｉｌｅ準拠とするので、ｉｃｏｎＵｒｌ＠ｐｒｏｆｉｌｅの値は、例えば、「ＪＰＥＧ＿ＴＮ」とする。

ａｃｔｉｏｎは、ｏｐｅｒａｔｉｏｎには、ｐａｒａｍｅｒｔｅｒＬｉｓｔがない場合は必須であり、ある場合は禁止である。ａｃｔｉｏｎは、ｐａｒａｍｅｔｅｒには必須であり、ａｃｔｉｏｎには、そのオペレーション、パラメータを実行する際に用いるａｃｔｉｏｎ ｄｉｒｅｃｔｉｖｅが記述される。ａｃｔｉｏｎ＠ｒｏｐＯｎｌｙは、「１」の場合、ａｃｔｉｏｎ ｄｉｒｅｃｔｉｖｅの内容をＲＯＰクライアントがパースすることができないことを示す。ａｃｔｉｏｎ＠ｒｏｐＯｎｌｙは、「０」の場合、省略可能であることを示す。

ｐａｒａｍｅｔｅｒＬｉｓｔは、ｏｐｅｒａｔｉｏｎにａｃｔｉｏｎがない場合は必須であり、ある場合は禁止である。ｐａｒａｍｅｔｅｒＬｉｓｔは、そのオペレーションに関連するパラメータ（サブ選択肢）のリストを示す。ｐａｒａｍｅｔｅｒＬｉｓｔは、子要素として一つ以上のｐａｒａｍｅｔｅｒを持つ。ｐａｒａｍｅｔｅｒは、一つのパラメータを示す。ｐａｒａｍｅｔｅｒは１６個以内である。

ここで、「ｓｈｏｒｔＤｉｓｐｌａｙＳｔｒｉｎｇ」がないと、全ての機器がモバイル用の短い文字列でデザインされたメニュー項目名を用いなければならない、もしくは、モバイルでは項目名が途中で切れてしまう。「ｓｅｌｅｃｔｅｄ」がないと、クライアント側ではどの選択肢をデフォルトとすべきか判断できない。クライアントアプリケーションは、項目の名前は把握できても意味は把握できないため、意味を把握できるようにしようとすると、サーバで新機能が足された場合にクライアントにも新規実装が必要となってしまう。「ｃｏｎｆｉｒｍｅｄ」がないと、クライアント側では本当に再確認すべき項目がどれか把握することができない。別の手法では、全ての項目で再確認すると、不適切な場合もあるのでＵＸが劣ってしまう。したがって、クライアントアプリケーションにとって意味が把握できない設定項目でもユーザに使いやすくする工夫を施す必要がある。

［１−２５．取得応答の記述例および表示例］
図２５は、本実施形態に係る情報提供装置により送信される取得応答の記述例および表示例を示す図である。記述例Ｄ１２により記述された取得応答に含まれるオペレーションリストは、画面Ｇ３に示すように表示される。ただし、図２５に示したオペレーションリストの構造定義は一例にすぎない。例えば、この構造定義はより複雑な定義にすることも可能である。例えば、２階層制限ではなく、より深い階層を許すこととしてもよい。また、例えば、文字入力フォームを要求することとしてもよい。ｃｏｍｍｏｎ、ｂｉｖｌ以外の今後のｐｒｏｆｉｌｅでは、そのような拡張を行う可能性もある。ｃｏｍｍｏｎ、ｂｉｖｌのような仕組みをつくっておいたおかげで、将来拡張しても、ｃｏｍｍｏｎ、ｂｉｖｌしかサポートしていない機器に悪影響を及ぼさない実装ができる。ｃｏｍｍｏｎ、ｂｉｖｌ向けの項目メニューと新ｔｙｐｅ向けの項目メニューとを分けることとしてもよい。

［１−２６．実行要求の記述例］
図２６は、本実施形態に係る情報処理装置により選択された操作識別情報を含む実行要求の記述例を示す図である。記述例Ｄ２１により記述された実行要求は、以下に示す説明では「Ｎｏｒｍａｔｉｖｅ Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ」に相当する。

「Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ」はオペレーションリスト内で記述されるオペレーションまたはパラメータがユーザによって選択された際にＲＯＰサーバに送られるＩＤ的な文字列である。「Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ」には中身を解釈せずに、ｏｐａｑｕｅなＩＤとしてそのまま用いられる形式と、中身を解釈（パース）してそのオペレーションまたはパラメータを選択するということがどういうことなのか、そのセマンティクスを理解して用いることが可能な形式との、２種類の実装がある。両者はオペレーションリスト内でｒｏｐＯｎｌｙという属性値によって区別することができる。

「ＲＯＰ−Ｏｎｌｙ Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ」は、Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ文字列をＲＯＰクライアントが解釈することはできない。「ＣＤＳ：：ＥｘｅｃｕｔｅＯｐｅｒａｔｉｏｎ（）」等の、ユースケースごとに定められたオペレーション実行アクションの引数として、そのままＯｐａｑｕｅに用いる。ｒｏｐＯｎｌｙ＝１となる。

「Ｎｏｒｍａｔｉｖｅ Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ」は以下に定められたシンタックスに沿って構成されたＸＭＬ Ｄｏｃｕｍｅｎｔであり、このオペレーション・パラメータを選択してリモートオペレーションをすることが、相当するＳＯＡＰ Ａｃｔｉｏｎを実行したケースと同様であることを表す。ｒｏｐＯｎｌｙ＝０となる（もしくは省略される）。「Ｎｏｒｍａｔｉｖｅ Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ」はオペレーションリスト内ではＸＭＬエスケープされる。

記述例Ｄ２１において、ａｃｔｉｏｎは、Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ ｄｏｃｕｍｅｎｔのルートタグである。このａｃｔｉｏｎ ｅｌｅｍｅｎｔは、オペレーションリスト内のａｃｔｉｏｎ ｅｌｅｍｅｎｔとは異なる。ｘｍｌ ｎａｍｅｓｐａｃｅ ｄｅｃｌａｒａｔｉｏｎを行う。ｎａｍｅｓｐａｃｅとしては、ｕｒｎ：ｓｃｈｅｍａｓ−ｓｏｎｙ−ｃｏｍ：ａｖ：ｒｏｐａｃｔｉｏｎｄｉｒｅｃｔｉｖｅを用いる。

ｎａｍｅは、相当するＳＯＡＰ Ａｃｔｉｏｎの名前である。ａｒｇｕｅｍｎｔＬｉｓｔは、そのＳＯＡＰ ＡｃｔｉｏｎにＩＮ Ａｒｇｕｍｅｎｔがある場合、必須である。ａｒｇｕｅｍｎｔＬｉｓｔは、子要素としてひとつ以上の、ＩＮ Ａｒｇｕｍｅｎｔそれぞれを表すｅｌｅｍｅｎｔを持つ。ａｒｇｕｍｅｎｔは、そのＳＯＡＰ ＡｃｔｉｏｎのＩＮ Ａｒｇｕｍｅｎｔ名をｅｌｅｍｅｎｔ名とし、値をｅｌｅｍｅｎｔ ｖａｌｕｅとする。

［１−２７．実行応答の記述例（その１）］
図２７は、本実施形態に係る情報提供装置により送信される実行応答の記述例を示す図（その１）である。図２７には、実行応答が記述例Ｄ３１により記述されている。記述例Ｄ３１で記述されたようなＲｅｓｕｌｔドキュメントは、オペレーションの実行後に情報処理装置２００でどのようなＵＩ遷移をすべきかを表すＸＭＬドキュメントである。ｒｅｓｕｌｔルートエレメントの子要素として、０個以上の遷移情報を表すｒｅｓｕｌｔ ｉｎｆｏｒｍａｔｉｏｎが含まれる。

現在、ｃｏｍｍｏｎ ｔｙｐｅ のオペレーションリストで定められているｒｅｓｕｌｔ ｉｎｆｏｒｍａｔｉｏｎはｍｅｓｓａｇｅのみであり、これは実行結果として表示すべきＵＩメッセージテキストを表す。例えば、エラー時のＵＩメッセージはＳＯＡＰエラーではなく、ＳＯＡＰは成功したうえで、このｍｅｓｓａｇｅ ｒｅｓｕｌｔ ｉｎｆｏｒｍａｔｉｏｎを用いて行われる。未知のｒｅｓｕｌｔ ｉｎｆｏｒｍａｔｉｏｎは無視される。

［１−２８．実行応答の記述例（その２）］
図２８は、本実施形態に係る情報提供装置により送信される実行応答の記述例を示す図（その２）である。図２８には、実行応答が記述例Ｄ３２により記述されている。

［１−２９．情報処理システムの適用例（その１）］
図２９は、本実施形態に係る情報処理システムの適用例（その１）について説明するための図である。図２９に示すように、ＤＭＣは、例えば、ＤＭＲのインスタンス１にＤＭＳ上のコンテンツ２をセットして再生指示をすることができる。

［１−３０．情報処理システムの適用例（その２）］
図３０は、本実施形態に係る情報処理システムの適用例（その２）について説明するための図である。図３０に示すように、ＤＭＲにセットされているコンテンツによって表示
内容が変わるときもある。

［１−３１．コンテンツの種類からメニュー項目を特定するための情報］
図３１は、本実施形態に係る情報処理装置によりコンテンツの種類から表示すべきメニュー項目を特定するための情報を示す図である。情報処理装置２００は、例えば、データ記憶部２３０により、図３１に示すような、コンテンツの種類とメニュー項目との対応情報を記憶しておくことができる。

［１−３２．情報処理装置が保持しているメニュー項目とコマンドとの対応］
図３２は、本実施形態に係る情報処理装置があらかじめ保持しているメニュー項目から実行すべきコマンドを特定するための情報を示す図である。情報処理装置２００は、例えば、データ記憶部２３０により、図３２に示すような、あらかじめ保持しているメニュー項目（自前メニュー項目）とコマンド（Ｎｅｔｗｏｒｋ ＡＰＩ）との対応情報を記憶しておくことができる。

［１−３３．情報提供装置から送信されるメニュー項目とコマンドとの対応］
図３３は、本実施形態に係る情報提供装置から送信されるメニュー項目から実行すべきコマンドを特定するための情報を示す図である。情報提供装置１００は、例えば、記憶部１３０により、図３３に示すような、情報提供装置から送信されるメニュー項目（ＲＯＰメニュー）とコマンド（Ｎｅｔｗｏｒｋ ＡＰＩ）との対応情報を記憶しておくことができる。

ＤＭＰ（ＲＯＰクライアント）は、自前のメニュー項目と、ＲＯＰ経由で取得したメニュー項目とを合わせてオプションメニューを作るが、機能的に同じものがそれぞれのメニュー項目に含まれていると、合わせたＵＩが不自然になってしまう。まず、ＤＭＰが機能的に同じものをどのように検出するかが問題である。ここで、ＲＯＰメニュー項目の「Ｎｏｒｍａｔｉｖｅ Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ」を解読すると、ＤＭＰは、そのメニュー項目がどういうＤＬＮＡ ＡＰＩ相当の機能なのかを把握することができる。一方、ＤＭＰは、自前メニューについては、それらがどういうＤＬＮＡ ＡＰＩによって実装されているかを知っている。同じＤＬＮＡ ＡＰＩで実現される項目は、同じ機能であると判断することができる。よって、片方をＵＩから削除することとする。自前メニューであれば、ＤＭＰが完全に意味を把握しているので、自前メニューを残す実装が有力と思われる。

［１−３４．情報処理装置により実行される処理の流れ］
図３４は、本実施形態に係る情報処理装置により実行される処理の流れを示すフローチャートである。図３４に示すように、情報処理装置２００の受信部２５０は、コンテンツリストとメタデータとを取得し（ステップＳ１０１）、表示部２６０においてコンテンツリストを表示する（ステップＳ１０２）。コンテンツリストとメタデータとの取得には、例えば、ＤＬＮＡ（ＣＤＳ：：Ｂｒｏｗｓｅ）を用いることができる。コンテンツの種類やコンテンツのタイトルを取得できる。

入力情報判断部２２１は、処理対象となるコンテンツを決定する（ステップＳ１０３）。例えば、ユーザによる操作（例えば上下キー）により、処理の対象となるコンテンツを決定するための情報が入力部２１０を介して入力される。表示制御部２２２は、自前コンテンツメニューを決定し（ステップＳ１０４）、ＲＯＰメニューが有るか否かを判断する（ステップＳ１０５）。例えば、コンテンツの種類に応じて、可能な操作が異なることが考えられるため、表示制御部２２２は、図３１に示したような対応情報に基づいて、表示すべきメニューを決定する。ＲＯＰメニューが有るか否かの判断は、メタデータの中にＲＯＰが可能であることを示すもの（ａｖ：ｍｓＯｐＬｉｓｔ）があるか否かを調べることにより判断できる。表示制御部２２２は、ＲＯＰメニューが無い場合には（ステップＳ１０５で「Ｎｏ」）、ステップＳ１０９に進む。

表示制御部２２２は、ＲＯＰメニューが有る場合には（ステップＳ１０５で「Ｙｅｓ」）、ＲＯＰメニューを取得して（ステップＳ１０６）、重複調査（ステップＳ１０７）、重複削除（ステップＳ１０８）をして、メニュー表示を行い（ステップＳ１０９）、処理を終了する。表示制御部２２２は、例えば、「ＣＤＳ：：Ｘ＿ＧｅｔＯｐｅｒａｔｉｏｎＬｉｓｔ」により、ＲＯＰのオペレーションメニューを取得することができる。いくつかのメニュー項目は、「Ｎｏｒｍａｔｉｖｅ Ａｃｔｉｏｎ Ｄｉｒｅｃｔｉｖｅ」を含んでいて、ＤＬＮＡ ＡＰＩで実現する場合のＡＰＩが記載されている（図３３参照）。

表示制御部２２２は、自前メニューの項目について、ＤＬＮＡのどのＡＰＩを用いて実現するかについてあらかじめ把握している（図３２参照）。表示制御部２２２は、例えば、ＲＯＰで得られた項目のＡＰＩ（図３３参照）と、そのコンテンツのために自前で用意する項目（図３１参照）が用いるＡＰＩ（図３２参照）で、重複しているものを探す。図３２と図３３とに示した例では、自前の「評価変更」はＲＯＰの「レート」と同義であることがわかる。重複削除（ステップＳ１０８）では、重複しているものについて片方を削除してから合成し、メニュー表示（ステップＳ１０９）では、表示すべきメニューを得る。この例の場合の、音楽コンテンツ用のケースを図３５に示す。

［１−３５．メニュー項目の合成］
図３５は、本実施形態に係る情報処理装置があらかじめ保持しているメニュー項目と本実施形態に係る情報提供装置から送信されるメニュー項目との合成について説明するための図である。図３５に示した例では、自前の「評価変更」はＲＯＰの「レート」とは同義であると判断され、ＲＯＰの「レート」が削除されている。

［１−３６．ラベルが付加されたメッセージを含む実行応答］
図３６は、メッセージの種類を示すラベルが付加されたメッセージを含む実行応答の記述例を示す図である。図３６に示す記述例Ｄ４１のように、「Ｒｅｓｕｌｔ ｉｎｆｏｒｍａｔｉｏｎ」の現在の書式＜ｍｅｓｓａｇｅ＞送りたい文＜／ｍｅｓｓａｇｅ＞の中にｌａｂｅｌ ｘｍｌ ａｔｔｒｉｂｕｔｅを追加して、＜ｍｅｓｓａｇｅ ｌａｂｅｌ＝“１”＞送りたい文＜／ｍｅｓｓａｇｅ＞という形式で記述する。

［１−３７．メッセージの種類とラベルの値との対応］
図３７は、メッセージの種類とラベルの値との対応例を示す図である。「ＲＯＰ ｒｅｓｕｌｔ ｉｎｆｏｒｍａｔｉｏｎ ｍｅｓｓａｇｅ」は、ＲＯＰによるメニューの実行後にふさわしいＵＩ遷移として、ＲＯＰサーバがＲＯＰクライアントに、サーバからのメッセージをＵＩ表示しなさいと指示するために用いられる。ここで表示されるメッセージは、例えば、「録画に成功しました」「お気に入りの件数が多すぎて登録できませんでした」などが想定される。

ここで、「ＲＯＰ ｒｅｓｕｌｔ ｉｎｆｏｒｍａｔｉｏｎ ｍｅｓｓａｇｅ」の拡張を行い、メッセージ文だけではなく、その意味合いのタイプを表すラベルを付記してＲＯＰクライアントに送るようにすることができる。ラベルは、「成功」「失敗」「警告」などを示すものが想定される。また、ラベルなしは、一般情報を示すものとしてもよい。ＲＯＰクライアントは、メッセージ表示時に、ラベルに応じた修飾をすることができる。例えば、○印の後に「録画に成功しました」と表示する場合や、×印の後に「登録できませんでした」と表示してビープ音を鳴らすなど、修飾の様態はＲＯＰクライアントが決めることができる。また、例えば、ラベルを無視してメッセージを全部同じ扱いにするようなＲＯＰクライアントがいてもよい。

＜２．変形例＞
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

＜３．まとめ＞
本実施形態によれば、情報処理装置２００自身があらかじめ保持している画面と情報提供装置１００によって生成された画面との間に生じる親和性の悪さを解消しつつ、情報提供装置１００と情報処理装置２００との間で使用されるプロトコルの変化に柔軟に対応することができる。

１０ 情報処理システム
１００ 情報提供装置
１１０ 受信部
１２０ 制御部
１２１ 受信情報判断部
１２２ 確認部
１２３ 取得部
１２４ 実行部
１３０ 記憶部
１４０ 送信部
２１０ 入力部
２２０ 入力情報判断部
２２１ 入力情報判断部
２２２ 表示制御部
２２３ 確認要求生成部
２２４ 実行要求生成部
２２５ 受信情報判断部
２２６ 記憶制御部
２２７ 送信可否判断部
２２８ 取得要求生成部
２３０ データ記憶部
２３１ オペレーション情報
２３２ 選択情報
２３３ コンテンツ情報
２４０ 画面情報記憶部
２４１ 画面情報
２５０ 受信部
２６０ 表示部
２７０ 送信部

Claims (18)

1. 情報提供装置により実行される第１操作の内容を示す第１操作内容情報および前記第１操作を識別するための第１操作識別情報を前記情報提供装置から受信する受信部と、
   前記情報提供装置により実行される第２操作の内容を示す第２操作内容情報および前記第２操作を識別するための第２操作識別情報を記憶するデータ記憶部と、
   画面を生成するために使用される情報である画面情報を記憶する画面情報記憶部と、
   前記画面情報記憶部により記憶されている前記画面情報に基づいて、前記第１操作内容情報および前記第２操作内容情報が設定された画面を生成して表示部に表示させる表示制御部と、
   を備え、
   前記表示制御部は、前記第１操作識別情報および前記第２操作識別情報が一致する場合、前記第１操作内容情報および前記第２操作内容情報のいずれか１つの前記画面への設定を省略する、
   情報処理装置。
2. 前記情報処理装置は、
   前記第１操作識別情報および前記第２操作識別情報のいずれか１つを被選択操作識別情報として選択し、前記被選択操作識別情報を含む要求である実行要求を生成する実行要求生成部と、
   前記実行要求生成部により生成された前記実行要求を前記情報提供装置に送信する送信部と、
   をさらに備える、請求項１に記載の情報処理装置。
3. 前記表示制御部は、
   前記第１操作識別情報および前記第２操作識別情報が一致すると判断した場合に、前記第１操作内容情報の前記画面への設定を省略する、
   請求項１に記載の情報処理装置。
4. 前記実行要求生成部は、
   前記表示制御部により、前記第１操作内容情報の前記画面への設定が省略された場合には前記第１操作識別情報を選択対象から除外し、前記第２操作内容情報の前記画面への設定が省略された場合には前記第２操作識別情報を選択対象から除外する、
   請求項２に記載の情報処理装置。
5. 前記表示制御部は、
   前記第１操作識別情報が前記情報提供装置に前記第１操作を実行させるための関数である第１関数名を含んでいる場合であり、かつ、前記第２操作識別情報が前記情報提供装置に前記第２操作を実行させるための関数である第２関数名を含んでいる場合に、前記第１関数名および前記第２関数名が一致するか否かを判断することにより、前記第１操作識別情報および前記第２操作識別情報が一致するか否かを判断する、
   請求項１に記載の情報処理装置。
6. 前記表示制御部は、
   前記第１関数名および前記第２関数名が一致するか否かに加えて、前記第１関数に与えられる引数および前記第２関数に与えられる引数が一致するか否かをさらに判断することにより、前記第１操作識別情報および前記第２操作識別情報が一致するか否かを判断する、
   請求項５に記載の情報処理装置。
7. 前記受信部は、
   前記実行要求に対する応答として前記実行要求に含まれる前記被選択操作識別情報により識別される操作が前記情報提供装置により実行されて得られた結果である実行結果を含む応答である実行応答を受信し、
   前記表示制御部は、
   前記受信部により受信された前記実行応答に含まれる前記実行結果を前記表示部に表示させる、
   請求項２に記載の情報処理装置。
8. 前記表示制御部は、
   前記実行結果に含まれるメッセージに種別が付加されている場合には、前記種別に応じた表示形式により前記メッセージを前記表示部に表示させる、
   請求項７に記載の情報処理装置。
9. 前記受信部は、
   前記情報提供装置により前記第１操作内容情報を前記情報処理装置に送信可能か否かを示す送信可否情報を前記情報提供装置からさらに受信し、
   前記情報処理装置は、
   前記受信部により受信された前記送信可否情報が前記情報提供装置により前記第１操作内容情報を前記情報処理装置に送信可能であることを示すか否かを判断する送信可否判断部と、
   前記送信可否判断部により前記送信可否情報が前記第１操作内容情報を送信可能であることを示すと判断された場合に、前記第１操作内容情報を取得するための要求である取得要求を生成する取得要求生成部と、
   前記取得要求生成部により生成された前記取得要求を前記情報提供装置に送信する送信部と、
   をさらに備え、
   前記受信部は、
   前記取得要求に対する応答として前記情報提供装置から前記第１操作内容情報を受信する、
   請求項１に記載の情報処理装置。
10. 前記情報処理装置は、
    前記情報提供装置により保持されているコンテンツを識別するためのコンテンツ識別情報と前記コンテンツに関連するコンテンツ関連情報とを取得するための要求である確認要求を生成する確認要求生成部、
    をさらに備え、
    前記送信部は、
    前記確認要求生成部により生成された前記確認要求を前記情報提供装置に送信し、
    前記受信部は、
    前記確認要求に対する応答として前記情報提供装置から前記コンテンツ識別情報および前記コンテンツ関連情報を受信し、
    前記送信可否判断部は、
    前記受信部により受信された前記コンテンツ関連情報に、前記コンテンツに対して実行される前記第１操作の内容を示す前記第１操作内容情報が前記情報提供装置により前記情報処理装置に送信可能か否かを示す前記送信可否情報が含まれている場合に、前記コンテンツ関連情報から前記送信可否情報を取得し、取得した前記送信可否情報が前記情報提供装置により前記第１操作内容情報を前記情報処理装置に送信可能であることを示すか否かを判断し、
    前記取得要求生成部は、
    前記送信可否判断部により前記送信可否情報が前記第１操作内容情報を送信可能であることを示すと判断された場合に、前記コンテンツ識別情報を含む前記取得要求を生成し、
    前記送信部は、
    前記取得要求生成部により生成された前記取得要求を前記情報提供装置に送信し、
    前記受信部は、
    前記取得要求に対する応答として前記取得要求に含まれる前記コンテンツ識別情報により識別される前記コンテンツに対して実行される前記第１操作の内容を示す前記第１操作内容情報を前記情報提供装置から受信する、
    請求項９に記載の情報処理装置。
11. 前記情報処理装置は、前記表示部をさらに備える、
    請求項１に記載の情報処理装置。
12. ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）環境におけるＤＭＳ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｓｅｒｖｅｒ）として機能する、
    請求項１に記載の情報処理装置。
13. ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）環境におけるＤＭＣ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｃｏｎｔｒｏｌｌｅｒ）として機能する、
    請求項１に記載の情報処理装置。
14. 前記表示制御部は、前記情報提供装置により提供されるＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）に基づいて前記第１操作識別情報および前記第２操作識別情報が一致するか否かを判断する、
    請求項１に記載の情報処理装置。
15. 受信部と、情報提供装置により実行される第２操作の内容を示す第２操作内容情報および前記第２操作を識別するための第２操作識別情報を記憶するデータ記憶部と、画面を生成するために使用される情報である画面情報を記憶する画面情報記憶部と、表示制御部と、を備える情報処理装置の前記受信部により、前記情報提供装置により実行される第１操作の内容を示す第１操作内容情報および前記第１操作を識別するための第１操作識別情報を前記情報提供装置から受信することと、
    前記表示制御部により、前記画面情報記憶部により記憶されている前記画面情報に基づいて、前記第１操作内容情報および前記第２操作内容情報が設定された画面を生成して表示部に表示させることと、を含み、
    前記表示制御部により、前記第１操作識別情報および前記第２操作識別情報が一致する場合、前記第１操作内容情報および前記第２操作内容情報のいずれか１つの前記画面への設定を省略すること、
    を含む、情報処理方法。
16. コンピュータを、
    情報提供装置により実行される第１操作の内容を示す第１操作内容情報および前記第１操作を識別するための第１操作識別情報を前記情報提供装置から受信する受信部と、
    前記情報提供装置により実行される第２操作の内容を示す第２操作内容情報および前記第２操作を識別するための第２操作識別情報を記憶するデータ記憶部と、
    画面を生成するために使用される情報である画面情報を記憶する画面情報記憶部と、
    前記画面情報記憶部により記憶されている前記画面情報に基づいて、前記第１操作内容情報および前記第２操作内容情報が設定された画面を生成して表示部に表示させる表示制御部と、
    を備える、情報処理装置として機能させるためのプログラム。
17. 自装置が実行する第１操作の内容を示す第１操作内容情報および前記第１操作を識別するための第１操作識別情報を記憶する記憶部と、
    前記記憶部により記憶されている前記第１操作内容情報および前記第１操作識別情報を情報処理装置に送信する送信部と、
    前記情報処理装置により前記第１操作識別情報および第２操作を識別するための第２操作識別情報のいずれか１つが被選択操作識別情報として選択された後、前記被選択操作識別情報を含む要求である実行要求を受信する受信部と、
    前記受信部により受信された前記実行要求に含まれる前記被選択操作識別情報により識別される操作を実行する実行部と、
    を備え、
    前記情報処理装置により、前記第１操作内容情報および前記第２操作の内容を示す第２操作内容情報が設定された画面が表示され、前記第１操作識別情報および第２操作識別情報が一致する場合、前記第１操作内容情報および前記第２操作内容情報のいずれか１つの前記画面への設定が省略される、
    情報提供装置。
18. 情報提供装置と、情報処理装置とを有する情報処理システムであって、
    前記情報提供装置は、
    自装置が実行する第１操作の内容を示す第１操作内容情報を記憶する記憶部と、
    前記記憶部により記憶されている前記第１操作内容情報を前記情報処理装置に送信する送信部と、
    を備え、
    前記情報処理装置は、
    前記第１操作内容情報および前記第１操作を識別するための第１操作識別情報を前記情報提供装置から受信する受信部と、
    前記情報提供装置により実行される第２操作の内容を示す第２操作内容情報および前記第２操作を識別するための第２操作識別情報を記憶するデータ記憶部と、
    画面を生成するために使用される情報である画面情報を記憶する画面情報記憶部と、
    前記画面情報記憶部により記憶されている前記画面情報に基づいて、前記第１操作内容情報および前記第２操作内容情報が設定された画面を生成して表示部に表示させる表示制御部と、
    を備え、
    前記表示制御部は、前記第１操作識別情報および前記第２操作識別情報が一致する場合、前記第１操作内容情報および前記第２操作内容情報のいずれか１つの前記画面への設定を省略する、
    情報処理システム。