WO2020084905A1 - 情報処理装置及び情報処理方法 - Google Patents

Abstract

コンテンツのプロファイル識別情報を処理する情報処理装置を提供する。　情報処理装置は、コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を記憶する記憶部と、前記プロファイル識別情報を他の機器に送信する送信部を具備する。前記プロファイル識別情報は、コンテンツのコンテナフォーマットに関するプロファイル要素、コンテンツに適用される保護方式に関するプロファイル要素、コンテンツのエンコード形式に関するプロファイル要素を含み、少なくとも１つは、プロファイル要素の区分け又はその他の補足情報を記述する入れ子のプロファイル要素を内包する。

Description

情報処理装置及び情報処理方法

　本明細書で開示する技術は、コンテンツのプロファイル識別情報を処理する情報処理装置及び情報処理方法に関する。

　ＤＬＮＡ（登録商標）（Ｄｉｇｉｔａｌ　Ｌｉｖｉｎｇ　Ｎｅｔｗｏｒｋ　Ａｌｌｉａｎｃｅ）は、ホームネットワークを通じて動画や音楽、写真などのコンテンツを機器間で配信する際の互換性を確保するためのガイドラインを規定している。また、ＤＬＮＡリンクプロテクションガイドラインでは、ＤＴＣＰ－ＩＰを必須条件の著作権管理技術として採用した。したがって、ＤＬＮＡの仕様に対応した機器間では、ＤＴＣＰ－ＩＰに則ってコンテンツ伝送が行われる。

　ここで、ＤＴＣＰ（Ｄｉｇｉｔａｌ　Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）は、ホームネットワークやパーソナルネットワーク内のコピー防止を主な目的として規定された暗号化伝送方式である。ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）上で実現されているＤＴＣＰはＤＴＣＰ－ＩＰと呼ばれる。さらに、４ＫやＨＤＲ（Ｈｉｇｈ　Ｄｙｎａｍｉｃ　Ｒａｎｇｅ）といった高解像度、高品質なコンテンツに適合すべく、より高度なコンテンツ保護方式となるＤＴＣＰ２も公開されている。電波産業会（ＡＲＩＢ：Ａｓｓｏｃｉａｔｉｏｎ　ｏｆ　Ｒａｄｉｏ　Ｉｎｄｕｓｔｒｉｅｓ　ａｎｄ　Ｂｕｓｉｎｅｓｓ）でも、デジタル放送をＤＴＣＰ－ＩＰを使用してネットワーク配信することを認可している。

　また、ＤＬＮＡは、機器をネットワークに接続するプロトコルとして、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ　Ｐｌｕｇ　ａｎｄ　Ｐｌａｙ）を採用している。したがって、ＤＬＮＡ機器間では、ＣＤＳ（Ｃｏｎｔｅｎｔ　Ｄｉｒｅｃｔｏｒｙ　Ｓｅｒｖｉｃｅ）を始めとして、ＵＰｎＰで規定される機能を利用することができる（例えば、特許文献１を参照のこと）。

　ＤＬＮＡは２０１７年に解散し、ＤＬＮＡのガイドラインも２０１６年版を最後に、拡張されなくなった。

特開２０１８－１１０４４５号公報

　本明細書で開示する技術の目的は、コンテンツのプロファイル識別情報を処理する情報処理装置及び情報処理方法を提供することにある。

　本明細書で開示する技術の第１の側面は、
　コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を記憶する記憶部と、
　前記プロファイル識別情報を他の機器に送信する送信部と、
を具備する情報処理装置である。

　前記プロファイル識別情報は、コンテンツのコンテナフォーマットに関するプロファイル要素、コンテンツに適用される保護方式に関するプロファイル要素と、コンテンツのエンコード形式に関するプロファイル要素を含む。

　また、前記複数のプロファイル要素のうち少なくとも１つは、プロファイル要素の区分け又はその他の補足情報を記述する入れ子のプロファイル要素を内包する。

　また、本明細書で開示する技術の第２の側面は、
　コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を記憶部に記憶するステップと、
　前記プロファイル識別情報を他の機器に送信するステップと、
を有する情報処理方法である。

　また、本明細書で開示する技術の第３の側面は、
　コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を取得する取得部と、
　プロファイル識別情報に基づいてコンテンツを処理する処理部と、
を具備する情報処理装置である。

　第３の側面に係る情報処理装置は、前記プロファイル識別情報に含まれる各プロファイル要素が表す情報に基づいて、前記処理部による当該コンテンツの処理可能性を判定することができる。

　前記プロファイル識別情報は、コンテンツのコンテナフォーマットに関するプロファイル要素を少なくとも含む。したがって、第３の側面に係る情報処理装置は、前記処理部が備えるパーサは前記プロファイル要素が示すコンテナフォーマットに対応しているかどうかに基づいて当該コンテンツの処理可能性を判定することができる。

　また、前記プロファイル識別情報は、コンテンツに適用される保護方式に関するプロファイル要素と、コンテンツのエンコード形式に関するプロファイル要素のうち少なくとも１つを含む。したがって、第３の側面に係る情報処理装置は、前記処理部は保護方式に関するプロファイル要素が示す保護方式に対応し、又は前記処理部が備えるデコーダはエンコード形式に関するプロファイル要素が示すエンコード形式に対応しているかどうかに基づいて当該コンテンツの処理可能性を判定することができる。

　また、前記複数のプロファイル要素のうち少なくとも１つは、プロファイル要素の区分け又はその他の補足情報を記述する入れ子のプロファイル要素を内包する。したがって、第３の側面に係る情報処理装置は、前記処理部はプロファイル要素が表すコンテンツのプロファイルに対応し、且つ入れ子のプロファイル要素が表すプロファイル要素の区分け又はその他の補足情報に対応しているかどうかに基づいて当該コンテンツの処理可能性を判定することができる。

　また、第３の側面に係る情報処理装置は、非対応と判定されたプロファイル識別情報を登録する非対応リストを備え、非対応リストに登録されたプロファイル識別情報を持つコンテンツを前記処理部は処理できないと判定することができる。

　また、本明細書で開示する技術の第４の側面は、
　コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を取得するステップと、
　プロファイル識別情報に基づいてコンテンツを処理するステップと、
を有する情報処理方法である。

　本明細書で開示する技術によれば、コンテンツのプロファイル識別情報を提供するための処理を実施する情報処理装置及び情報処理方法、並びにプロファイル識別情報に従ってコンテンツに関する処理を実施する情報処理装置及び情報処理方法を提供することができる。

　なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。

　本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

図１は、コンテンツ配信システム１００の構成例を模式的に示した図である。 図２は、コンテンツ配信システム１００における基本的な通信シーケンス例を示した図である。 図３は、サーバ１０１として動作する情報処理装置の機能的構成例を模式的に示した図である。 図４は、クライアント１０２として動作する情報処理装置の機能的構成例を模式的に示した図である。 図５は、プロファイル識別情報の書式の一例を示した図である。 図６は、プロファイル識別情報の書式の他の例を示した図である。 図７は、コンテンツのプロファイル識別情報に基づいてコンテンツの再生可能性について判定するための処理手順を示したフローチャートである。 図８は、再生に失敗したコンテンツのプロファイル識別情報を非対応リストに登録するための処理手順を示したフローチャートである。 図９は、再生に失敗したコンテンツのプロファイル識別情報を要素毎に個別に非対応リストに登録するための処理手順を示したフローチャートである。 図１０は、要素毎に個別に登録した非対応リストへの登録済みを確認するための処理手順を示したフローチャートである。

　以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。

Ａ．コンテンツ配信システム
　ＤＬＮＡ規格では、サーバとクライアントで構成されるモデル（２　Ｂｏｘ　Ｐｕｌｌ）が定義されている。なお、ＤＬＮＡ規格では、サーバとクライアントとコントローラで構成されるモデル（３　Ｂｏｘ）も定義されているが、ここでは説明を省略する。

　図１には、２　Ｂｏｘ　Ｐｕｌｌモデルのコンテンツ配信システム１００の構成例を模式的に示している。図示のコンテンツ配信システム１００は、サーバ１０１とクライアント１０２からなる。サーバ１０１は、デバイスクラス「ＤＭＳ（Ｄｉｇｉｔａｌ　Ｍｅｄｉａ　Ｓｅｒｖｅｒ）」に相当し、クライアント１０２は、デバイスクラス「ＤＭＰ（Ｄｉｇｉｔａｌ　Ｍｅｄｉａ　Ｐｌａｙｅｒ）」に相当する。ＤＭＳとＤＭＰは、「デバイスディスカバリー」を通じてお互いを認識し合うことができる。サーバ１０１とクライアント１０２は、ホームネットワーク、パーソナルネットワーク、ＩＰネットワークなどを介して相互接続されているものとする。

　コンテンツ配信システム１００の基本動作は、クライアント１０２は、サーバ１０１が提供可能なコンテンツを検索し、サーバ１０１は、クライアント１０２にコンテンツを伝送する、というものである。

　図２には、コンテンツ配信システム１００における基本的な通信シーケンス例を示している。但し、サーバ１０１及びクライアント１０２はともにＤＬＮＡの仕様に対応した機器であるとする。

　まず、クライアント１０２は、ユーザからの指示などに応じて、サーバ１０１に対して、サーバ１０１が保有している（若しくは、サーバ１０１からクライアント１０２に提供することが可能な）コンテンツリストを要求する（ＳＥＱ２０１）。これに対し、サーバ１０１は、サーバ１０１が保有している（若しくは、提供可能な）コンテンツリストをクライアント１０２に送信する（ＳＥＱ２０２）。

　ＤＬＮＡはＵＰｎＰプロトコルを採用している。したがって、ともにＤＬＮＡの仕様に対応したサーバ１０１とクライアント１０２間では、ＳＥＱ２０１～ＳＳＥＱ２０２で実施されるコンテンツリストの要求及び送信は、ＵＰｎＰで規定されている、コンテンツに関する情報を配信するＣＤＳ機能を利用して実施することができる。ＳＥＱ２０１では、クライアント１０２は、例えばコンテンツ情報を一括取得するＢｒｏｗｓｅコマンドを使用したり、検索条件の指定を伴ってコンテンツ情報を取得するＳｅａｒｃｈコマンドを使用したりする。そして、ＳＥＱ２０２では、サーバ１０１は、コンテンツのメタデータを読み出し、コンテンツリストに変換した上で、クライアント１０２に返信する。

　クライアント１０２は、サーバ１０１から受信したコンテンツリストを画面表示などして、ユーザに提示する（ＳＥＱ２０３）。ユーザは、コンテンツリストの中から、自分が再生したいコンテンツを指示することができる。

　クライアント１０２は、ユーザの指示に従って、受信したコンテンツリストの中からコンテンツを選択して、選択したコンテンツをサーバ１０１に要求する（ＳＥＱ２０４）。クライアント１０２は、例えばＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）リクエストの形式で、サーバ１０１にコンテンツを要求する。

　これに対し、サーバ１０１は、クライアント１０２から要求されたコンテンツをクライアント１０２に転送する（ＳＥＱ２０５）。クライアント１０２からＨＴＴＰリクエストの形式でコンテンツが要求された場合には、サーバ１０１は、例えばＨＴＴＰレスポンスの形式でコンテンツを送信する。

　サーバ１０１及びクライアント１０２はともにＤＬＮＡの仕様に対応した機器であり、ＳＥＱ２０４及びＳＥＱ２０５からなるコンテンツ伝送は著作権保護が必要なコンテンツの場合はＤＴＣＰ－ＩＰに則って行われるものとする。すなわち、クライアント１０２がコンテンツ要求（ＳＥＱ２０４）（若しくは、コンテンツリスト要求（ＳＥＱ２０１））を行なう際には、サーバ１０１とクライアント１０２間では相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ａｎｄ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ：ＡＫＥ）手続きが実施される。そして、ＳＥＱ２０５では、このＡＫＥ手続きを通じて取得した交換鍵に基づいて生成される暗号鍵を用いて、サーバ１０１とクライアント１０２間でコンテンツの暗号化伝送が実施される。

　そして、クライアント１０２は、サーバ１０１から転送されてきたコンテンツを受信し、再生する（ＳＥＱ２０６）。コンテンツ伝送がＤＴＣＰ－ＩＰに則って行われた場合には、クライアント１０２側では、サーバ１０１とのＡＫＥ手続きで生成した暗号鍵を用いて、暗号化コンテンツを復号してから再生する。

　図３には、サーバ１０１として動作する情報処理装置の機能的構成例を模式的に示している。サーバ１０１は、クライアント１０２からの要求に応じて、各種のサービスからコンテンツを取得して、クライアント１０２に送信する装置である。サービスには、放送、ストリーミング配信、ブルーレイディスクプレーヤなどのコンテンツ再生装置などが含まれる。例えば、テレビ受信機（ＴＶ）やＳＴＢ（Ｓｅｔ　Ｔｏｐ　Ｂｏｘ）、ブルーレイディスクプレーヤなどのコンテンツ再生装置、パーソナルコンピュータ（ＰＣ）などにより、サーバ１０１が構成される。

　図３に示すサーバ１０１は、制御部３０１と、コンテンツ取得部３０２と、コンテンツ送信部３０３と、通信部３０４を備えている。サーバ１０１は、ＴＶやＳＴＢなど、サーバ１０１として適用される機器の構成などに応じて、図３に示した以外の構成要素を適宜装備するが、この点の詳細については説明を省略する。

　制御部３０１は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）やメモリを備え、サーバ１０１として構成される装置全体の動作を統括的に制御する。通信部３０４は、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）アダプタや無線モジュールなどの通信インターフェースを備え、ホームネットワークやパーソナルネットワーク、ＩＰネットワークなどを介してクライアント１０２と相互接続している。

　制御部３０１は、クライアント１０２からのコンテンツリスト要求に応じて、クライアント１０２に提供可能なコンテンツリストを送信する処理や、クライアント１０２からのコンテンツ要求に応じて、クライアント１０２に対して要求されたコンテンツを送信する処理などを実施するために、サーバ１０１内の各部の動作を制御する。

　コンテンツ取得部３０２は、制御部３０１からの指示に従って、クライアント１０２から要求されたコンテンツを、各種のサービスから取得するための処理を実施する。サービスには、放送、ストリーミング配信、ブルーレイディスクプレーヤなどのコンテンツ再生装置などが含まれる（前述）。コンテンツ取得部３０２は、チューナや、ＬＡＮアダプタなどの通信インターフェース、ＨＤＭＩ（登録商標）（Ｈｉｇｈ－Ｄｅｆｉｎｉｔｉｏｎ　Ｍｕｌｔｉｍｅｄｉａ　Ｉｎｔｅｒｆａｃｅ）インターフェース、Ｖｉｄｅｏポートなどで構成される。

　コンテンツ取得部３０２は、サービスから取得したコンテンツ（若しくは、クライアント１０２に提供可能なコンテンツ）を蓄積するための、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｃ　Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）といった大容量記憶装置を備えていてもよい。また、コンテンツ取得部３０２は、ブルーレイ（登録商標）ディスクなどのメディアを再生するメディアドライブであってもよい。

　また、コンテンツ取得部３０２は、コンテンツのメタデータもさらに取得するようにしてもよい。コンテンツ取得部３０２は、取得したメタデータを蓄積しておくようにしてもよい。

　コンテンツ送信部３０３は、制御部３０１からの指示に従って、コンテンツ取得部３０２が取得したコンテンツを、通信部３０４を介してクライアント１０２に送信するための処理を実施する。例えば、コンテンツ送信部３０３は、クライアント１０２からのＨＴＴＰリクエストに応答して、ＨＴＴＰレスポンスによりコンテンツを送信する処理を実施する。

　本実施形態では、サーバ１０１はＵＰｎＰで規定されているＣＤＳ機能を通じてコンテンツリストを提供することを想定している。したがって、制御部３０１は、クライアント１０２からのＢｒｏｗｓｅコマンドやＳｅａｒｃｈコマンドに応答して、コンテンツのメタデータ（前述）に基づいてコンテンツリストを生成して、通信部３０４から送信するための制御を実施する。

　また、本実施形態では、ＤＴＣＰやＤＴＣＰ２といった著作権保護技術を適用して、サーバ１０１からクライアント１０２にコンテンツを暗号化伝送することを想定している。したがって、制御部３０１は、通信部３０４を通じて、クライアント１０２との間でＡＫＥ手続きを実施して、クライアント１０２に対する認証処理を実施する。また、制御部３０１は、ＡＫＥ手続きを通じて取得した交換鍵に基づいて生成される暗号鍵を用いて送信コンテンツを暗号化するように、コンテンツ送信部３０３に指示する。

　図４には、クライアント１０２として動作する情報処理装置の機能的構成例を模式的に示している。クライアント１０２は、ユーザからの指示に応じて、再生したいコンテンツをサーバ１０１に要求し、サーバ１０１から受信したコンテンツを再生する装置である。例えば、ＴＶ、スマートフォンやタブレットなどの多機能情報端末、ＰＣなどにより、クライアント１０２が構成される。

　図４に示すクライアント１０２は、制御部４０１と、通信部４０２と、ユーザインターフェース（ＵＩ）部４０３と、コンテンツ受信部４０４と、パーサ４０５と、Ｖｉｄｅｏデコーダ４０６と、Ａｕｄｉｏデコーダ４０７と、出力部４０８を備えている。クライアント１０２は、ＴＶや情報端末など、クライアント１０２として適用される機器の構成などに応じて、図４に示した以外の構成要素を適宜装備するが、この点の詳細については説明を省略する。

　制御部４０１は、ＣＰＵやメモリを備え、クライアント１０２として構成される装置全体の動作を統括的に制御する。通信部４０２は、ＬＡＮアダプタや無線モジュールなどの通信インターフェースを備え、ホームネットワークやパーソナルネットワーク、ＩＰネットワークなどを介してサーバ１０１と相互接続している。

　ユーザインターフェース部４０３は、例えばキーボードやマウス、タッチパネルなどの入力デバイスで構成され、ユーザからの指示を受け付けることができる。また、ユーザインターフェース部４０３は、音声エージェント機能を備え、ユーザとの対話を通じてユーザからの指示を受け付けるようにしてもよい。

　制御部４０１は、ユーザインターフェース部４０３を介したユーザからの指示に応じて、コンテンツリストやコンテンツをサーバ１０１から受信する処理や、コンテンツリストを提示したりコンテンツを再生したりする処理などを実施するために、クライアント１０２内の各部の動作を制御する。

　制御部４０１は、ユーザからコンテンツリストの提示が要求された場合には、通信部４０２を介してサーバ１０２にコンテンツリストを要求し、サーバ１０２からコンテンツリストを受信する。制御部４０１は、受信したコンテンツリストを処理し、ユーザインターフェース部４０３又は出力部４０８でコンテンツリストを提示する。ユーザは、提示されたコンテンツリストから、ユーザインターフェース部４０３を使って所望する（例えば再生したい）コンテンツを選択することができる。そして、制御部４０１は、ユーザがユーザインターフェース部４０３を介して選択したコンテンツをサーバ１０１から取得するように、コンテンツ受信部４０４に指示する。

　コンテンツ受信部４０４は、制御部４０１からの指示に従って、ユーザが要求するコンテンツを、通信部４０２を介してサーバ１０１から受信するための処理を実施する。パーサ４０５は、コンテンツ受信部４０４がサーバ１０１から受信したコンテンツの解析処理を実施する。ここでは、サーバ１０１からＡＶコンテンツを受信したとする。そして、パーサ４０５は、受信したコンテナからＶｉｄｅｏデータとＡｕｄｉｏデータを抽出する。但し、パーサ４０５は、非対応のデータ形式からなるコンテナからは、ＶｉｄｅｏデータとＡｕｄｉｏデータを抽出することができない。

　Ｖｉｄｅｏデコーダ４０６は、パーサ４０５から供給されるＶｉｄｅｏデータをＡＶＣデコーダやＨＥＶＣデコーダなどによりデコードして、Ｖｉｄｅｏ信号を生成する。また、Ａｕｄｉｏデコーダ４０７は、パーサ４０５から供給されるＡｕｄｉｏデータをデコードして、Ａｕｄｉｏ信号を生成する。但し、Ｖｉｄｅｏデコーダ４０６やＡｕｄｉｏデコーダ４０７は、非対応のエンコード形式のＶｉｄｅｏデータ並びにＡｕｄｉｏデータをデコードすることはできない。

　出力部４０８は、例えばディスプレイ及びスピーカからなり、Ｖｉｄｅｏデコーダ４０６が生成したＶｉｄｅｏ信号により映像出力し、Ａｕｄｉｏデコーダ４０７が生成したＡｕｄｉｏ信号により音響出力する。あるいは、出力部４０８は、Ｖｉｄｅｏデコーダ４０６が生成したＶｉｄｅｏ信号及びＡｕｄｉｏデコーダ４０７が生成したＡｕｄｉｏ信号を外部に出力するＡＶ端子であり、外付けディスプレイ及び外付けスピーカ（いずれも図示しない）をこのＡＶ端子に接続していてもよい。

　本実施形態では、クライアント１０２はＵＰｎＰで規定されているＣＤＳ機能を通じてコンテンツリストを要求することを想定している。したがって、制御部４０１は、ユーザからコンテンツリストが要求されると、通信部４０２を介してサーバ１０１にＢｒｏｗｓｅコマンドやＳｅａｒｃｈコマンドを送信する。また、制御部４０１は、通信部４０２を介してクライアント１０２から受信したコンテンツリストをユーザインターフェース部４０３又は出力部４０８で提示する。そして、ユーザは、提示されたコンテンツリストから、ユーザインターフェース部４０３を使って所望する（例えば再生したい）コンテンツを選択することができる。

　また、本実施形態では、ＤＴＣＰやＤＴＣＰ２といった著作権保護技術を適用して、サーバ１０１からクライアント１０２にコンテンツを暗号化伝送することを想定している。したがって、制御部４０１は、通信部４０２を通じて、サーバ１０１との間でＡＫＥ手続きを実施して、サーバ１０１との認証処理を実施する。また、制御部４０１は、ＡＫＥ手続きを通じて取得した交換鍵に基づいて生成される暗号鍵を用いて受信コンテンツを復号するように、コンテンツ受信部４０４に指示する。

Ｂ．コンテンツのプロファイル識別情報
　ＤＬＮＡガイドラインは、動画、音楽、写真などの各種データ形式を、Ｍｅｄｉａ　Ｆｏｒｍａｔ　Ｐｒｏｆｉｌｅ　ＩＤ（以下、「Ｐｒｏｆｉｌｅ　ＩＤ」ともいう）という識別子で分類して、同じＰｒｏｆｉｌｅ　ＩＤをサポートするサーバとクライアントの間で再生可能なコンテンツを確実に判別できるようにしていた。また、ＵＰｎＰでは、ｐｒｏｔｏｃｏｌＩｎｆｏ情報の第４フィールド内のＶｅｎｄｏｒ　Ｓｐｅｃｉｆｉｃ　ＦｉｅｌｄにＭｅｄｉａ　Ｆｏｒｍａｔ　Ｐｒｏｆｉｌｅ　ＩＤを格納して、ＣＤＳサービスによりコンテンツのプロファイル識別情報として提供することができる。

　ところが、４Ｋや８ＫなどのＵｌｔｒａ　ＨＤ動画やハイレゾ音楽が今後広まりつつあるが、これら新しいデータ形式はＤＬＮＡガイドラインに規定されていないため、再生互換性の確認が困難であるという問題がある。ＤＬＮＡが解散されたことにより、ＤＬＮＡのガイドラインの拡張も行われなくなったことから（前述）、今後、ＤＬＮＡガイドラインが新しいデータ形式に対応するように拡張されるということもない。

　付言すれば、従来のＰｒｏｆｉｌｅ　ＩＤは特定のルールでデータ形式の内容を表現したものではない。このため、機器は、既知のＰｒｏｆｉｌｅ　ＩＤについては再生互換性を判別することができるが、未知のＰｒｏｆｉｌｅ　ＩＤからデータ形式の内容を解読して再生可否を判断することは難しいという問題もある。

　ＤＬＮＡに代わって、Ｕｌｔｒａ　ＨＤ動画やハイレゾ音楽などの新しいデータ形式に対応するプロファイル識別情報を検討し規格化するような標準化団体は現存しない。Ｐｒｏｆｉｌｅ　ＩＤに相当するプロファイル識別情報を各種サービスがそれぞれの規定で定めて運用したり、メーカー毎の独自のプロファイル識別情報を定義し運用したりすると、サービスやメーカーを超えた互換性を実現できなくなってしまう。

　各種サービスやメーカーを超えて、プロファイル識別情報の書式を共通化することができれば、その記述内容から再生互換性を判別し易くなる、ということもできる。例えば、図１に示したコンテンツ配信システム１００において、クライアント１０２は、ＣＤＳなどのサービスを利用してコンテンツリストを要求して、サーバ１０１から未知の（若しくは、初めての）プロファイル識別情報が返されてきたとしても、その記述内容に基づいて再生互換性を判別し易くなる。

　そこで、本明細書では、記述内容から再生互換性を判別し易い書式からなるプロファイル識別情報、並びに、このようなプロファイル識別情報を利用したコンテンツ配信システム１００の運用について、以下で提案する。

　クライアント１０２としてのコンテンツ再生機器がコンテンツを再生する際、コンテンツのデータ格納形式（コンテナフォーマット）に対応し、さらに格納されているコンテンツのエンコード形式に対応する必要がある。動画コンテンツの場合、コンテンツ再生機器は、ＶｉｄｅｏとＡｕｄｉｏそれぞれのエンコード形式に対応していなければ、その動画コンテンツを正しく再生できない。さらには、エンコード形式にプロファイルやレベルといった区分けがある場合には、コンテンツ再生機器は、単にエンコード形式に対応しているだけでなく、コンテンツのエンコードで用いられた区分けに対応していないと、コンテンツを正しく再生できない可能性がある。もちろん、ＤＴＣＰなどの伝送規格に則って暗号化伝送されるコンテンツの場合には、コンテンツ再生機器は、その暗号を解くための保護技術にも対応していなければ、コンテンツを再生できない。

　以上のことを踏まえて、本明細書では、図５に示すようなプロファイル識別情報の書式を提案する。コンテンツのプロファイル識別情報は、コンテンツのデータ格納形式（コンテナフォーマット）やエンコード形式など複数のプロファイル要素（以下、単に「要素」ともいう）を含み、且つ、要素の中には区分けがある場合がある。図５に示す書式は、プロファイル識別情報の各要素、及び要素毎の区分けを構造化して記述する書式ということもできる。したがって、コンテンツ再生機器は、未知のプロファイル識別情報であっても、その記述内容から再生互換性を判別し易くなる、という利点がある。

　図５に示すプロファイル識別情報の書式は、既に解散したＤＬＮＡで規定していたＭｅｄｉａ　Ｆｏｒｍａｔ　Ｐｒｏｆｉｌｅ　ＩＤに置き換えて、コンテンツ配信などに利用することができる。もちろん、ＤＬＮＡには限定されず、デジタルコンテンツを扱うさまざまなサービスにも適用することができる。

　図５に示すプロファイル識別情報は、簡単に言えば、複数の要素を連結して構成される。図５に示すプロファイル識別情報の書式の基本的なルールについて説明しておく。

　図５に示すプロファイル識別情報は、「保護」、「コンテナ」、「Ｖコーデック」、「Ａコーデック」、「その他補足」の各要素を含んでいる。但し、［］で囲まれた要素は必須ではない。例えば、暗号化されていないコンテンツの場合には、先頭の要素“＜保護＞”は無しとなる。図５に示したプロファイル識別情報の場合、「コンテナ」のみが必須の要素となる。

　また、図示の書式のうち、［＜要素Ａ＞［＜要素Ｂ＞］］のように入れ子になっている要素の場合、要素Ａに内包される要素Ｂは、要素Ａが存在する場合のみ記述され得る。もちろん、要素Ａは存在するが要素Ｂが存在しない場合には、入れ子の要素“＜要素Ｂ＞”は無しとする。＜Ｖコーデック＞要素に内包される＜Ｖ補足＞要素には、＜Ｖコーデック＞要素の区分けなどが記述される。また、＜Ａコーデック＞要素に内包される＜Ａ補足＞要素には、＜Ａコーデック＞要素の区分けなどが記述される。

　また、図示の書式のうち、“＿”は、要素間の区切りを示すデリミタである。もちろん、“＿”以外の文字又は文字列をデリミタに使用することもできる。デリミタとして使用する文字を要素中に使用することは禁止とするか、又は、特定のエスケープ文字を前につけてデリミタでないことを示すようにする。

　図５に示した書式は一例であり、必ずしもこれに限定されない。例えば要素の順番を入れ替えたり、別の要素を追加したり、図５に示したいずれか少なくとも１つの要素を除いたりして、プロファイル識別情報の書式を定義することもできる。また、各要素を配置する順番を固定にしなくてもよい。

　図６には、プロファイル識別情報の書式の他の例を示している。図６に示す書式も、図５と同様に、各要素、及び要素毎の区分けを構造化してプロファイル識別情報を記述する書式である。図６に示すプロファイル識別情報の書式も、既に解散したＤＬＮＡで規定していたＭｅｄｉａ　Ｆｏｒｍａｔ　Ｐｒｏｆｉｌｅ　ＩＤに置き換えて、コンテンツ配信などに利用することができる。もちろん、ＤＬＮＡには限定されず、デジタルコンテンツを扱うさまざまなサービスにも適用することができる。

　図６には、比較のため、図５と同様に、「保護」、「コンテナ」、「Ｖコーデック」、「Ａコーデック」、「その他補足」の各要素を含み、これらの要素を連結して構成したプロファイル識別情報を例示している。

　図５との主な相違点は、図６に示すプロファイル識別情報では、各要素の先頭に、要素の種別を判定できる接頭語を付けている点である。（Ｐ）、（Ｃ）、（Ｖ）、（Ａ）、及び（Ｏ）はそれぞれ、直後に続く要素に対する接頭語である。接頭語は、例えば、要素を記述する文字列の頭文字など、要素を識別可能な１文字又は短い文字列であってもよい。

　なお、要素だけでなく、＜Ｖ補足＞や＜Ａ補足＞といった、他の要素の内包される要素（要素の区分けなどと）にも接頭語を付けるようにしてもよい。但し、それぞれを内包する＜Ｖコーデック＞要素、＜Ａコーデック＞要素の各接頭語（Ｖ）及び（Ａ）でカバーされる要素の一部とし、特に接頭語を付けなくても解釈可能な場合には、接頭語を省略することが考えられる。

　各要素に接頭語を付けた場合、要素の解釈が容易になる。したがって、配置する順番を固定にしなくても、各要素が何を表すかを解釈することが容易になる。また、図５に示す書式にあったデリミタは、接頭語が区切りになるため、削ってもよい。

　続いて、図５並びに図６に示したプロファイル識別情報に含まれる個々の要素について説明する。

　＜保護＞には、コンテンツに保護技術が適用される場合に、その方式を特定する文字列を示す。例えば“ＤＴＣＰ”、“ＤＴＣＰ２”などが考えられる。

　＜コンテナ＞には、コンテンツのデータフォーマットを特定する文字列を示す。例えば“ＭＰＥＧ－ＴＳ（Ｍｏｖｉｎｇ　Ｐｉｃｔｕｒｅ　Ｅｘｐｅｒｔｓ　ｇｒｏｕｐ－Ｔｒａｎｓｐｏｒｔ　Ｓｔｒｅａｍ）”、“ＭＰ４”、“ＪＰＥＧ（Ｊｏｉｎｔ　Ｐｈｏｔｏｇｒａｐｈｉｃ　Ｅｘｐｅｒｔｓ　Ｇｒｏｕｐ）”、“ＭＭＴ－ＴＬＶ（ＭＰＥＧ　Ｍｅｄｉａ　Ｔｒａｎｓｐｏｒｔ－Ｔｙｐｅ　Ｌｅｎｇｔｈ　Ｖａｌｕｅ）”などが考えられる。

　＜Ｖコーデック＞には、Ｖｉｄｅｏのエンコード形式を特定する文字列を示す。例えば“ＡＶＣ（Ａｄｖａｎｃｅｄ　Ｖｉｄｅｏ　Ｃｏｄｉｎｇ）（Ｈ．２６４）”、“ＨＥＶＣ（Ｈｉｇｈ　Ｅｆｆｉｃｉｅｎｃｙ　Ｖｉｄｅｏ　Ｃｏｄｉｎｇ）（Ｈ．２６５）”などが考えられる。なお、音楽コンテンツの場合はこの要素は省略される。＜Ｖコーデック＞が記述される場合は、必要に応じて内包される＜Ｖ補足＞として、動画のエンコード形式に関する補足情報を続けて記述する。

　＜Ｖ補足＞は、補足情報であることを示す文字‘：’などに続けて、補足内容を特定する文字列を示す。例えば、Ｖｉｄｅｏコーデックのプロファイルを示す“：ＭＰ（Ｍａｉｎ）”や“：ＨＰ（Ｈｉｇｈ）”、画像の解像度を示す“：ＳＤ（Ｓｔａｎｄａｒｄ　Ｄｅｆｉｎｉｔｉｏｎ）”、“：ＨＤ（Ｈｉｇｈ　Ｄｅｆｉｎｉｔｉｏｎ）”、“：４Ｋ”、“：８Ｋ”、Ｈｉｇｈ　Ｄｙｎａｍｉｃ　Ｒａｎｇｅに関する情報を示す“：ＨＬＧ（Ｈｙｂｒｉｄ　Ｌｏｇ－Ｇａｍｍａ）”、“：ＨＤＲ１０”、“：ＳＤＲ（Ｓｔａｎｄａｒｄ　Ｄｙｎａｍｉｃ　Ｒａｎｇｅ）”などが挙げられる。なお、コーデックプロファイルと解像度のように異なる種類の情報は“：ＨＰ：ＨＤ”のようにコロンのような接続記号を用いて連結して複数列記してもよい。

　＜Ａコーデック＞と＜Ａ補足＞は、それぞれＡｕｄｉｏのエンコード形式とその補足情報で、＜Ｖコーデック＞と＜Ｖ補足＞に対応するものである。

　以上の情報だけではプロファイル識別情報として不十分な場合には、＜その他補足＞にさらに補足情報が技術される。図５並びに図６に示す書式では、この要素は１つだけとなっているが、必要に応じて要素間の区切りと＜その他補足＞を複数記述してもよい。

　各要素に記述する文字列とその意味は、特定のｗｅｂサイトなどで一元管理することが望ましい。また、既存の文字列は別の文字列で登録できないようにすることが互換性確保のためには望ましいが、複数の規格で互いに不整合が起きないように個別に管理することも考えられる。

　例えば、ＤＴＣＰ２で保護して伝送するコンテンツのメディアフォーマットをＵＰｎＰのｐｒｏｔｏｃｏｌＩｎｆｏで示す場合は、ｐｒｏｔｏｃｏｌＩｎｆｏの第４フィールドにＤＴＣＰ.ＣＯＭ＿ＰＮ＝（図５又は図６に示した書式のプロファイル識別情報） と記載する旨をＤＴＣＰ２の仕様書に記載し、各要素の具体的な文字列を記述する。ここで、各要素の文字列は、既存の規定で図５又は図６に示し書式を用いるものと極力合わせるようにする。このようにすることで、ＤＴＣＰ２を用いて伝送するコンテンツについて、ＤＬＮＡで実現していたのと同等の互換性を確保することが可能となる。

　図５又は図６に示した書式のプロファイル識別情報は、プロファイル識別情報の各要素、及び要素毎の区分けを構造化して記述する書式なので、その記述内容から再生互換性を判別し易い。図１に示したコンテンツ配信システム１００におけるクライアント１０２など、コンテンツを再生する機器側では、そのコンテンツのプロファイル識別情報を参照すれば、＜保護＞、＜コンテナ＞、＜Ｖコーデック＞、＜Ａコーデック＞のうち、記述されているものの内容がすべてサポートするものであれば、そのコンテンツを当該機器で再生できる可能性があると判断することができる。

　また、プロファイル識別情報中の＜Ｖコーデック＞要素や＜Ａコーデック＞要素に入れ子の要素として再生可能な条件などの補足情報がさらに指定されている場合には、それぞれの補足情報を参照することで、より再生可否の判定の確度を上げることができる。

　例えば、あるコンテンツに対するプロファイル識別情報の値がＤＴＣＰ２＿ＭＰＥＧ－ＴＳ＿ＨＥＶＣ：４Ｋ：ＨＬＧ＿Ｍ４ＡＡＣ、すなわち＜保護＞がＤＴＣＰ２、＜コンテナ＞がＭＰＥＧ－ＴＳ、＜Ｖコーデック＞がＨＥＶＣで＜Ｖ補足＞が４ＫとＨＬＧ、＜Ａコーデック＞がＭ４ＡＡＣの場合、クライアント１０２は、自身がＤＴＣＰ２の復号機能、ＭＰＥＧ－ＴＳコンテナのパース機能、ＨＥＶＣとＭＰＥＧ４－ＡＡＣのデコーダをすべて備える場合には、このコンテンツを再生できる可能性があると判断できるが、１つでも非対応のものがある場合、例えばクライアント１０２がＨＥＶＣのデコーダを持たない場合は、このコンテンツを再生できないと判断することができる。

　さらに、＜Ｖコーデック＞要素に基づいて再生の可能性があると判定される場合には、＜Ｖコーデック＞要素の入れ子の＜Ｖ補足＞要素を参照することによって、解像度が４ＫでＨＹＢＲＩＤ　Ｌｏｇ　Ｇａｍｍａ方式のＨＤＲ映像であるということが分かる。クライアント１０２が２Ｋの解像度までしか処理する能力を持たない場合、このプロファイル識別情報に基づいて、クライアント１０２がこのコンテンツを再生できないことが判断できる。

　ここで、サーバ１０１が同じコンテンツについて、２Ｋでも提供できることを別のプロファイル識別情報の値ＤＴＣＰ２＿ＭＰＥＧ－ＴＳ＿ＨＥＶＣ：２Ｋ：ＳＤＲ＿Ｍ４ＡＡＣで示している場合、クライアント１０２は、そのプロファイル識別情報に対応するコンテンツの提供を受けることで正常に再生できる可能性がある。

　また、ＨＥＶＣのデコーダにほとんど制約がないクライアント１０２の場合、＜Ｖ補足＞に未知の文字列が含まれていても、そのコンテンツの再生を試みるという判断も考えられる。一方、サーバ１０１との通信帯域が４Ｋコンテンツの伝送には不十分な場合には、安定伝送のためにクライアント１０２が敢えてプロファイル識別情報ＤＴＣＰ２＿ＭＰＥＧ－ＴＳ＿ＨＥＶＣ：２Ｋ：ＳＤＲ＿Ｍ４ＡＡＣに対応するコンテンツの提供を受けるという動作も考えられる。

　そして、図５や図６に示した書式からなるコンテンツのプロファイル識別情報が示される限り、クライアント１０２は、コンテンツの提供元のサービス（放送、配信など）に依らずに上記のような判定処理を実施することができる。

Ｃ．本提案に係るプロファイル識別情報を利用したシステム動作
　コンテンツ配信システム１００において、コンテンツリストの提示にＵＰｎＰ規格のＣＤＳ機能を利用し、且つ、コンテンツの伝送にはＤＴＣＰやＤＴＣＰ２といった著作権保護技術を適用した場合のサーバ１０１及びクライアント１０２の動作については、Ａ項で概略的に説明した。ここでは、既に解散したＤＬＮＡで規定していたＭｅｄｉａ　Ｆｏｒｍａｔ　Ｐｒｏｆｉｌｅ　ＩＤに代えて、本明細書で提案する書式からなるプロファイル識別情報を利用する場合の、サーバ１０１及びクライアント１０２の各動作について、詳細に説明する。

　サーバ１０１側では、クライアントに提供可能な各コンテンツについて、それぞれのメタデータに基づいて、図５又は図６に示した書式からなるプロファイル識別情報を作成する。そして、ＤＴＣＰ２で保護して伝送するコンテンツのメディアフォーマットをＵＰｎＰのｐｒｏｔｏｃｏｌＩｎｆｏで示す場合は、ｐｒｏｔｏｃｏｌＩｎｆｏの第４フィールドにＤＴＣＰ.ＣＯＭ＿ＰＮ＝（図５又は図６に示した書式のプロファイル識別情報） と記載する。また、サーバ１０１は、例えば図２に示した通信シーケンスのＳＥＱ２０２において、ＵＰｎＰ規格のＣＤＳ機能を通じて、図５又は図６に示した書式からなるプロファイル識別情報をクライアント１０２に開示する。

　クライアント１０２側では、ＵＰｎＰ規格のＣＤＳ機能を通じて、図５又は図６に示した書式からなるプロファイル識別情報を、サーバ１０１から取得することができる。プロファイル識別情報は、プロファイル識別情報の各要素、及び要素毎の区分けを構造化して記述する書式なので、その記述内容から再生互換性を判別し易い。

　クライアント１０２は、コンテンツのプロファイル識別情報を参照すれば、＜保護＞、＜コンテナ＞、＜Ｖコーデック＞、＜Ａコーデック＞のうち、記述されているものの内容がすべてサポートするものであれば、そのコンテンツを当該機器で再生できる可能性があると判断することができる。

　また、プロファイル識別情報中の＜Ｖコーデック＞要素や＜Ａコーデック＞要素に入れ子の要素として再生可能な条件などの補足情報がさらに指定されている場合には、クライアント１０２は、それぞれの補足情報を参照することで、より再生可否の判定の確度を上げることができる。

　図７には、クライアント１０２が、サーバから取得したコンテンツのプロファイル識別情報に基づいて、そのコンテンツの再生可能性について判定するための処理手順をフローチャートの形式で示している。この処理手順は、クライアント１０２として構成される情報処理装置の制御部４０１の制御下で実施されるものとする。

　図示の処理手順を実施する際、クライアント１０２は、自機器で再生できないことが確定されたコンテンツのプロファイル識別情報を、非対応リストに登録していることを前提とする（非対応リストは、例えば、制御部３０１内のメモリに記録される）。また、この処理手順は、１つのコンテンツに対する判定処理を示している。コンテンツが複数ある場合には、クライアント１０２は、コンテンツ毎にこの判定処理を逐次適用するものとする。

　クライアント１０２は、取得したプロファイル識別情報を参照すると（ステップＳ７０１）、まずこのプロファイル識別情報が非対応リストに登録済みであるかどうかをチェックする（ステップＳ７０２）。

　このプロファイル識別情報が非対応リストに登録済みである場合には（ステップＳ７０２のＹｅｓ）、プロファイル識別情報で示された各要素をチェックするまでもなく、自機器でそのコンテンツを再生できないことが明らかである。そこで、クライアント１０２は、このコンテンツは再生不可と判定して（ステップＳ７１１）、本処理を終了する。

　一方、処理中のプロファイル識別情報が非対応リストに登録されていない場合には（ステップＳ７０２のＮｏ）、このプロファイル識別情報に記載されている各要素について、クライアント１０２が再生できないものが含まれていないかどうかを個別にチェックする。

　処理中のプロファイル識別情報中に、＜保護＞要素が存在する場合、クライアント１０２は、その値が示す保護方式のコンテンツの復号や、求められる保護規定の遵守が可能かどうかをチェックする（ステップＳ７０３）。そして、＜保護＞要素の値が示す保護方式のコンテンツの復号や、求められる保護規定の遵守が可能でない場合には（ステップＳ７０３のＮｏ）、クライアント１０２は、このコンテンツは再生不可と判定して（ステップＳ７１１）、本処理を終了する。

　なお、＜保護＞要素は必須ではない。処理中のプロファイル識別情報中に、＜保護＞要素が存在しない場合には、当該コンテンツに保護のための機能は不要であり、クライアント１０２は＜保護＞要素に対応している場合（ステップＳ７０３のＹｅｓ）と同様として処理する。

　また、クライアント１０２は、パーサ４０５が＜コンテナ＞要素の値が示すフォーマットのデータ格納形式に対応し、コンテナからＶｉｄｅｏデータとＡｕｄｉｏデータを正しく抽出できるかどうかをチェックする（ステップＳ７０４）。そして、＜コンテナ＞要素の値が示すフォーマットのデータ格納形式にパーサ４０５が対応していない場合には（ステップＳ７０４のＮｏ）、クライアント１０２は、このコンテンツは再生不可と判定して（ステップＳ７１１）、本処理を終了する。

　また、処理中のプロファイル識別情報中に、＜Ｖコーデック＞要素が存在する場合、クライアント１０２は、その値が示す方式でエンコードされたＶｉｄｅｏデータをＶｉｄｅｏデコーダ４０６でデコードできるかどうかをチェックする（ステップＳ７０５）。そして、＜Ｖコーデック＞要素の値が示す方式でエンコードされたＶｉｄｅｏデータをＶｉｄｅｏデコーダ４０６でデコードできない場合には（ステップＳ７０５のＮｏ）、クライアント１０２は、このコンテンツは再生不可と判定して（ステップＳ７１１）、本処理を終了する。

　なお、＜Ｖコーデック＞要素は必須ではない。処理中のプロファイル識別情報中に、＜Ｖコーデック＞要素が存在しない場合には、クライアント１０２は、該当するコンテンツにはＶｉｄｅｏデータは含まれないものとし、＜Ｖコーデック＞要素に対応している場合（ステップＳ７０５のＹｅｓ）と同様として処理する。

　また、処理中のプロファイル識別情報中に、＜Ａコーデック＞要素が存在する場合、クライアント１０２は、その値が示す方式でエンコードされたＡｕｄｉｏデータをＡｕｄｉｏデコーダ４０７でデコードできるかどうかをチェックする（ステップＳ７０６）。そして、＜Ａコーデック＞要素の値が示す方式でエンコードされたＡｕｄｉｏデータをＡｕｄｉｏデコーダ４０７でデコードできない場合には（ステップＳ７０６のＮｏ）、クライアント１０２は、このコンテンツは再生不可と判定して（ステップＳ７１１）、本処理を終了する。

　なお、＜Ａコーデック＞要素は必須ではない。処理中のプロファイル識別情報中に、＜Ａコーデック＞要素が存在しない場合には、クライアント１０２は、該当するコンテンツにはＡｕｄｉｏデータは含まれないものとし、＜Ａコーデック＞要素に対応している場合（ステップＳ７０６のＹｅｓ）と同様として処理する。

　また、処理中のプロファイル識別情報中に、＜Ｖ補足＞要素が存在する場合、クライアント１０２は、その値が示すＶｉｄｅｏ関連の処理が、クライアント１０２自身が対応していないなどの理由により、当該コンテンツの再生に支障を来す情報があるかどうかをチェックする（ステップＳ７０７）。そして、＜Ｖ補足＞要素の中に当該コンテンツの再生に支障を来す情報がある場合には（ステップＳ７０７のＹｅｓ）、クライアント１０２は、このコンテンツは再生不可と判定して（ステップＳ７１１）、本処理を終了する。

　なお、＜Ｖ補足＞要素の値が複数の補足情報からなる場合には、ステップＳ７０７では、クライアント１０２は個々の補足情報についてチェックを行う。

　また、処理中のプロファイル識別情報中に、＜Ａ補足＞要素が存在する場合、クライアント１０２は、その値が示すＡｕｄｉｏ関連の処理が、クライアント１０２自身が対応していないなどの理由により、当該コンテンツの再生に支障を来す情報があるかどうかをチェックする（ステップＳ７０８）。そして、＜Ａ補足＞要素の中に当該コンテンツの再生に支障を来す情報がある場合には（ステップＳ７０８のＹｅｓ）、クライアント１０２は、このコンテンツは再生不可と判定して（ステップＳ７１１）、本処理を終了する。

　なお、＜Ａ補足＞要素の値が複数の補足情報からなる場合には、ステップＳ７０７では、クライアント１０２は個々の補足情報についてチェックを行う。

　また、処理中のプロファイル識別情報中に、＜その他補足＞要素が存在する場合、クライアント１０２は、その値が示す処理が、クライアント１０２自身が対応していないなどの理由により、当該コンテンツの再生に支障を来す情報があるかどうかをチェックする（ステップＳ７０９）。そして、＜その他補足＞要素の値が示す処理が当該コンテンツの再生に支障を来す情報がある場合には（ステップＳ７０９のＹｅｓ）、クライアント１０２は、このコンテンツは再生不可と判定して（ステップＳ７１１）、本処理を終了する。

　なお、＜その他補足＞要素の値が複数の補足情報からなる場合には、ステップＳ７０９では、クライアント１０２は個々の補足情報についてチェックを行う。

　そして、当該コンテンツのプロファイル識別情報に含まれるすべての要素にクライアント１０２が対応し、且つ、入れ子の要素として指定されたすべての補足情報が当該コンテンツの再生に支障を来さないと判定された場合には、クライアント１０２はこのコンテンツを再生できる可能性ありと判定して（ステップＳ７１０）、本処理を終了する。

　クライアント１０２は、ＵＰｎＰ規格のＣＤＳ機能を通じてサーバ１０１からコンテンツリストを取得する際に、コンテンツリスト中の各コンテンツのプロファイル識別情報を参照する。

　そして、クライアント１０２は、コンテンツリストをユーザに提示する際に、図７に示した処理手順に従って再生不可と判定されたコンテンツを非表示にしたり、再生できない、あるいは再生に失敗したことを示す形式で表示したりする。また、再生不可と判定されたコンテンツをコンテンツリストに表示又は非表示にするかを、ユーザの指示に基づいて切り替えられるようにしてもよい。また、再生不可と判定されたコンテンツであっても、ユーザがユーザインターフェース部４０３などを通じて選択した場合には、クライアント１０２は、そのコンテンツの再生を試行する動作を実施するようにしてもよい。

　図８には、クライアント１０２が、コンテンツの再生を試行して、再生に失敗したときにそのコンテンツのプロファイル識別情報を非対応リストに登録するための処理手順をフローチャートの形式で示している。この処理手順は、クライアント１０２として構成される情報処理装置の制御部４０１の制御下で実施されるものとする。

　クライアント１０２は、コンテンツの再生に失敗したとき（ステップＳ８０１のＹｅｓ）、そのコンテンツのプロファイル識別情報を非対応リストに登録済みであるかどうかをチェックする（ステップＳ８０２）。プロファイル識別情報が既に非対応リストに登録されている場合には（ステップＳ８０２のＹｅｓ）、再度の非対応リストへの登録処理は不要であり、後続の処理をすべてスキップして、本処理を終了する。

　一方、再生に失敗したコンテンツのプロファイル識別情報がまだ非対応リストに登録されていない場合には（ステップＳ８０２のＮｏ）、クライアント１０２は、そのプロファイル識別情報に、＜Ｖ補足＞、＜Ａ補足＞、＜その他補足＞など補足情報が含まれていないかどうかをチェックする（ステップＳ８０３）。

　プロファイル識別情報にいずれの補足情報も含まれていない場合（ステップＳ８０３のＹｅｓ）、クライアント１０２は＜保護＞、＜コンテナ＞、＜Ｖコーデック＞、及び＜Ａコーデック＞の各要素がそれぞれ示す値にすべて対応している場合でもそのコンテンツを再生できない場合があることを意味する。したがって、そのプロファイル識別情報だけではコンテンツの再生の可否を判定できないので、クライアント１０２は、後続の処理をすべてスキップして、このプロファイル識別情報の非対応リストへの登録は差し控え、本処理を終了する。

　プロファイル識別情報にいずれかの補足情報が含まれている場合（ステップＳ８０３のＮｏ）、クライアント１０２は、自身にとって未知の補足情報など、再生に支障を来す可能性がある情報が存在するかどうかをさらにチェックする（ステップＳ８０４）。

　そして、再生に支障を来す可能性がある補足情報がプロファイル識別情報中に存在する場合には（ステップＳ８０４のＹｅｓ）、クライアント１０２は、そのプロファイル識別情報を非対応リストに登録して（ステップＳ８０５）、本処理を終了する。

　また、再生に支障を来す可能性がある補足情報がプロファイル識別情報中に含まれていない場合には（ステップＳ８０４のＮｏ）、クライアント１０２は、そのプロファイル識別情報を非対応リストに登録せずに、本処理を終了する。

　図８に示した処理手順の変形例として、再生に失敗したコンテンツのプロファイル識別情報を非対応リストに登録する処理を、ＶｉｄｅｏとＡｕｄｉｏで個別に行うことも考えられる。

　図９には、再生に失敗したコンテンツのプロファイル識別情報の非対応リストへの登録をＶｉｄｅｏとＡｕｄｉｏｎで個別に実施するための処理手順をフローチャートの形式で示している。この処理手順は、クライアント１０２として構成される情報処理装置の制御部４０１の制御下で実施されるものとする。

　クライアント１０２は、コンテンツの再生に失敗しなかったときには（ステップＳ９０１のＮｏ）、後続の処理をすべてスキップして、本処理を終了する。

　クライアント１０２は、コンテンツの再生に失敗したときには（ステップＳ９０１のＹｅｓ）、Ｖｉｄｅｏの再生に失敗したかどうかをさらにチェックする（ステップＳ９０２）。

　Ｖｉｄｅｏの再生に失敗しなかった場合には（ステップＳ９０２のＮｏ）、後続の処理ステップＳ９０３～Ｓ９０５をスキップして、クライアント１０２は処理ステップＳ９０６に進む。

　一方、Ｖｉｄｅｏの再生に失敗したときには（ステップＳ９０２のＹｅｓ）、クライアント１０２は、そのコンテンツのプロファイル識別情報中に、＜Ｖ補足＞要素が含まれるかどうかをチェックする（ステップＳ９０３）。

　プロファイル識別情報中に＜Ｖ補足＞要素が含まれない場合には（ステップＳ９０３のＮｏ）、後続の処理ステップＳ９０４～Ｓ９０５をスキップして、クライアント１０２は処理ステップＳ９０６に進む。

　プロファイル識別情報中に＜Ｖ補足＞要素が含まれる場合には（ステップＳ９０３のＹｅｓ）、クライアント１０２は、その＜Ｖ補足＞要素の中に当該コンテンツの再生に支障を来す可能性がある情報があるかどうかをチェックする（ステップＳ９０４）。

　＜Ｖ補足＞要素の中に当該コンテンツの再生に支障を来す可能性がある情報がない場合には（ステップＳ９０４のＮｏ）、後続の処理ステップＳ９０５をスキップして、クライアント１０２は処理ステップＳ９０６に進む。

　＜Ｖ補足＞要素の中に当該コンテンツの再生に支障を来す可能性がある情報がある場合には（ステップＳ９０４のＹｅｓ）、クライアント１０２は、＜Ｖコーデック＞要素と＜Ｖ補足＞要素のペアを非対応リストに登録する（ステップＳ９０５）。

　続いて、クライアント１０２は、Ａｕｄｉｏの再生に失敗したかどうかをさらにチェックする（ステップＳ９０６）。

　Ａｕｄｉｏの再生に失敗しなかった場合には（ステップＳ９０６のＮｏ）、後続の処理ステップＳ９０７～Ｓ９０９をスキップして、クライアント１０２は本処理を終了する。

　一方、Ａｕｄｉｏの再生に失敗したときには（ステップＳ９０６のＹｅｓ）、クライアント１０２は、そのコンテンツのプロファイル識別情報中に、＜Ａ補足＞要素が含まれるかどうかをチェックする（ステップＳ９０７）。

　プロファイル識別情報中に＜Ａ補足＞要素が含まれない場合には（ステップＳ９０７のＮｏ）、後続の処理ステップＳ９０８～Ｓ９０９をスキップして、クライアント１０２は本処理を終了する。

　プロファイル識別情報中に＜Ａ補足＞要素が含まれる場合には（ステップＳ９０７のＹｅｓ）、クライアント１０２は、その＜Ａ補足＞要素の中に当該コンテンツの再生に支障を来す可能性がある情報があるかどうかをチェックする（ステップＳ９０８）。

　＜Ａ補足＞要素の中に当該コンテンツの再生に支障を来す可能性がある情報がない場合には（ステップＳ９０８のＮｏ）、後続の処理ステップＳ９０５をスキップして、クライアント１０２は本処理を終了する。

　＜Ａ補足＞要素の中に当該コンテンツの再生に支障を来す可能性がある情報がある場合には（ステップＳ９０８のＹｅｓ）、クライアント１０２は、＜Ａコーデック＞要素と＜Ａ補足＞要素のペアを非対応リストに登録して（ステップＳ９０９）、本処理を終了する。

　図９に示した処理手順に従って、プロファイル識別情報の非対応リストへの登録をＶｉｄｅｏとＡｕｄｉｏで個別に実施する場合、若しくは、ある要素と、その要素の区分けなどを記述する入れ子の要素のペアを非対応リスト登録する場合には、非対応リストのチェックは、プロファイル識別情報の全体一致ではなく、要素毎の部分一致に基づいて行うことになる。

　図１０には、図９に示した処理手順に従って非対応リストの登録処理を実施した場合に、図７に示したフローチャート中のステップＳ７０２の非対応リストの登録確認処理で実施すべき詳細な処理手順をフローチャートの形式で示している。

　クライアント１０２は、まず、コンテンツのプロファイル識別情報中に、＜Ｖ補足＞要素が含まれるかどうかをチェックする（ステップＳ１００１）。

　プロファイル識別情報中に＜Ｖ補足＞要素が含まれない場合には（ステップＳ１００１のＮｏ）、処理ステップＳ１００２をスキップして、クライアント１０２は処理ステップＳ１００３に進む。

　プロファイル識別情報中に＜Ｖ補足＞要素が含まれる場合には（ステップＳ１００１のＹｅｓ）、クライアント１０２は、コンテンツのプロファイル識別情報の＜Ｖコーデック＞要素と＜Ｖ補足＞要素のペアが非対応リストに登録済みかどうかをチェックする（ステップＳ１００２）。

　＜Ｖコーデック＞要素と＜Ｖ補足＞要素のペアが非対応リストに登録済みである場合には（ステップＳ１００２のＹｅｓ）、ステップＳ１００５に進み、クライアント１０２は当該プロファイル識別情報に非対応と判定して、本処理を終了する。

　一方、＜Ｖコーデック＞要素と＜Ｖ補足＞要素のペアが非対応リストに登録されていない場合には（ステップＳ１００２のＮｏ）、クライアント１０２は、続いて、コンテンツのプロファイル識別情報中に、＜Ａ補足＞要素が含まれるかどうかをチェックする（ステップＳ１００３）。

　プロファイル識別情報中に＜Ａ補足＞要素が含まれない場合には（ステップＳ１００３のＮｏ）、処理ステップＳ１００４をスキップして、クライアント１０２は本処理を終了する。

　プロファイル識別情報中に＜Ａ補足＞要素が含まれる場合には（ステップＳ１００３のＹｅｓ）、クライアント１０２は、コンテンツのプロファイル識別情報の＜Ａコーデック＞要素と＜Ａ補足＞要素のペアが非対応リストに登録済みかどうかをチェックする（ステップＳ１００４）。

　＜Ａコーデック＞要素と＜Ａ補足＞要素のペアが非対応リストに登録されていない場合には（ステップＳ１００４のＮｏ）、クライアント１０２は、ステップＳ１００５をスキップして、本処理を終了する。

　一方、＜Ａコーデック＞要素と＜Ａ補足＞要素のペアが非対応リストに登録済みである場合には（ステップＳ１００４のＹｅｓ）、ステップＳ１００５に進み、クライアント１０２は当該プロファイル識別情報に非対応と判定して、本処理を終了する。

Ｄ．本提案に係るプロファイル識別情報による効果
　ＤＬＮＡが解散したことで、コンテンツの素性を表すＭｅｄｉａ　Ｆｏｒｍａｔ　Ｐｒｏｆｉｌｅ　ＩＤの標準化を行う場がなくなった。このため、今後利用が進みつつある４Ｋや８Ｋのコンテンツ、ＨＤＲコンテンツ、それをＤＴＣＰ２で保護したものについて、Ｍｅｄｉａ　Ｆｏｒｍａｔ　Ｐｒｏｆｉｌｅ　ＩＤでコンテンツの素性を表すことができなくなる。コンテンツの素性を表すプロファイル識別情報を各種サービスが独自に規定することが考えられるが、そうなるとクライアントは、サービス毎のプロファイル識別情報に個別対応しないと互換性が確保できなくなる。

　これに対し、本明細書では、特定のサービスによらず、クライアントがコンテンツの素性を把握し易くなるようなプロファイル識別情報の書式について提案した。例えば、ＤＴＣＰ２の仕様書で、ＤＴＣＰ２でコンテンツを保護する場合のＰｒｏｆｉｌｅＩＤの書式として、本明細書で提案する書式を規定すれば、少なくともＤＴＣＰ２が適用されるコンテンツについてはサービス毎に独自のプロファイル識別情報が乱立するのを防ぐことにつながる。

　また、クライアントは、本明細書で提案する書式からなるプロファイル識別情報で示される各要素（保護、コンテナ、Ｖｉｄｅｏコーデック、Ａｕｄｉｏコーデック）に対応しているかどうかをチェックすることによって、そのプロファイル識別情報に対応するコンテンツの再生可能性を判定することができる。さらに、クライアントは、少なくとも一部の要素の入れ子の要素として示される補足情報への対応の有無をチェックすることによって、対応するコンテンツの再生可能性を高い精度で見極めることができる。

　さらに、サーバが特定のコンテンツを複数の形式で提供できる場合には、クライアントは、形式毎に規定されたコンテンツのプロファイル識別情報に基づいて、再生品質や接続安定度など優先したいことに応じて最適なコンテンツを選択することも可能になる。

　以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

　本明細書で提案する、コンテンツのプロファイル識別情報の書式は、既に解散したＤＬＮＡで規定していたＭｅｄｉａ　Ｆｏｒｍａｔ　Ｐｒｏｆｉｌｅ　ＩＤに置き換えて、コンテンツ配信などに利用することができる。もちろん、ＤＬＮＡには限定されず、デジタルコンテンツを扱うさまざまなサービスに、本明細書で提案するプロファイル識別情報の書式を適用することができる。

　要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。

　なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を記憶する記憶部と、
　前記プロファイル識別情報を他の機器に送信する送信部と、
を具備する情報処理装置。
（１－１）各プロファイル要素は、プロファイル要素を識別可能な１文字又は短い文字列からなる接頭語を含む、
上記（１）に記載の情報処理装置。
（２）前記プロファイル識別情報は、コンテンツのコンテナフォーマットに関するプロファイル要素を少なくとも含む、
上記（１）に記載の情報処理装置。
（２－１）コンテンツのコンテナフォーマットに関するプロファイル要素は、当該コンテンツがＭＰＥＧ－　ＴＳ、ＭＰ４、ＪＰＥＧ、ＭＭＴ－ＴＬＶを含むいずれのコンテナフォーマットであるかを示すプロファイル要素を含む、
上記（２）に記載の情報処理装置。
（３）前記プロファイル識別情報は、コンテンツに適用される保護方式に関するプロファイル要素と、コンテンツのエンコード形式に関するプロファイル要素のうち少なくとも１つを含む、
上記（１）又は（２）のいずれかに記載の情報処理装置。
（３－１）コンテンツのエンコード形式に関するプロファイル要素は、当該コンテンツにＤＴＣＰ又はＤＴＣＰ２が適用されるか否かを示す、
上記（３）に記載の情報処理装置。
（４）前記プロファイル識別情報は、Ｖｉｄｅｏのエンコード形式に関するプロファイル要素と、Ａｕｄｉｏのエンコード形式に関するプロファイル要素のうち少なくとも１つを含む、
上記（３）に記載の情報処理装置。
（５）前記複数のプロファイル要素のうち少なくとも１つは、入れ子のプロファイル要素を内包する、
上記（１）乃至（４）のいずれかに記載の情報処理装置。
（６）プロファイル要素の区分け又はその他の補足情報を入れ子のプロファイル要素に記述する、
上記（５）に記載の情報処理装置。
（７）コンテンツのエンコード形式に関するプロファイル要素は、そのエンコード形式の区分けを記述する入れ子のプロファイル要素を内包する、
上記（６）に記載の情報処理装置。
（７－１）Ｖｉｄｅｏのエンコード形式に関するプロファイル要素は、コーデックプロファイルと解像度のうち少なくとも１つを記述する入れ子のプロファイル要素を内包する、
上記（７）に記載の情報処理装置。
（８）前記記憶部は、ｐｒｏｔｏｃｏｌＩｎｆｏ情報の第４フィールド内のＶｅｎｄｏｒ　Ｓｐｅｃｉｆｉｃ　Ｆｉｅｌｄに前記プロファイル識別情報を記憶する、
上記（１）乃至（７）のいずれかに記載の情報処理装置。
（９）前記送信部は、ＵＰｎＰ規格のＣＤＳに則って、前記他の機器に前記プロファイル識別情報を送信する、
上記（１）乃至（８）のいずれかに記載の情報処理装置。
（１０）コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を記憶部に記憶するステップと、
　前記プロファイル識別情報を他の機器に送信するステップと、
を有する情報処理方法。
（１１）コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を取得する取得部と、
　プロファイル識別情報に基づいてコンテンツを処理する処理部と、
を具備する情報処理装置。
（１１－１）前記取得部は、ＵＰｎＰ規格のＣＤＳに則って、前記他の機器から前記プロファイル識別情報を取得する、
上記（１１）に記載の情報処理装置。
（１２）前記プロファイル識別情報に含まれる各プロファイル要素が表す情報に基づいて、前記処理部による当該コンテンツの処理可能性を判定する、
上記（１１）に記載の情報処理装置。
（１３）前記プロファイル識別情報は、コンテンツのコンテナフォーマットに関するプロファイル要素を少なくとも含み、
　前記処理部が備えるパーサは前記プロファイル要素が示すコンテナフォーマットに対応しているかどうかに基づいて当該コンテンツの処理可能性を判定する、
上記（１２）に記載の情報処理装置。
（１４）前記プロファイル識別情報は、コンテンツに適用される保護方式に関するプロファイル要素と、コンテンツのエンコード形式に関するプロファイル要素のうち少なくとも１つを含み、
　前記処理部は保護方式に関するプロファイル要素が示す保護方式に対応し、又は前記処理部が備えるデコーダはエンコード形式に関するプロファイル要素が示すエンコード形式に対応しているかどうかに基づいて当該コンテンツの処理可能性を判定する、
上記（１２）又は（１３）のいずれかに記載の情報処理装置。
（１５）前記プロファイル識別情報は、Ｖｉｄｅｏのエンコード形式に関するプロファイル要素と、Ａｕｄｉｏのエンコード形式に関するプロファイル要素のうち少なくとも１つを含み、
　前記処理部が備えるＶｉｄｅｏデコーダはＶｉｄｅｏのエンコード形式に関するプロファイル要素が示すＶｉｄｅｏのエンコード形式に対応し、又は前記処理部が備えるＡｕｄｉｏデコーダはＡｕｄｉｏのエンコード形式に関するプロファイル識別情報が示すＡｕｄｉｏのエンコード形式に対応しているかどうかに基づいて当該コンテンツの処理可能性を判定する、
上記（１２）乃至（１４）のいずれかに記載の情報処理装置。
（１６）前記複数のプロファイル要素のうち少なくとも１つは、プロファイル要素の区分け又はその他の補足情報を記述する入れ子のプロファイル要素を内包し、
　前記処理部はプロファイル要素が表すコンテンツのプロファイルに対応し、且つ入れ子のプロファイル要素が表すプロファイル要素の区分け又はその他の補足情報に対応しているかどうかに基づいて当該コンテンツの処理可能性を判定する、
上記（１２）乃至（１５）のいずれかに記載の情報処理装置。
（１７）コンテンツのエンコード形式に関するプロファイル要素は、そのエンコード形式の区分け又は補足情報を記述する入れ子のプロファイル要素を内包し、
　前記処理部が備えるデコーダはエンコード形式に関するプロファイル要素が示すエンコード形式に対応し、且つ、入れ子のプロファイル要素が示すエンコード形式の区分け又は補足情報にも対応しているかどうかに基づいて当該コンテンツの処理可能性を判定する、
上記（１２）乃至（１６）のいずれかに記載の情報処理装置。
（１８）非対応と判定されたプロファイル識別情報を登録する非対応リストを備え、
　非対応リストに登録されたプロファイル識別情報を持つコンテンツを前記処理部は処理できないと判定する、
上記（１１）乃至（１７）のいずれかに記載の情報処理装置。
（１９）前記処理部がコンテンツの処理に失敗した原因となるプロファイル要素及びその入れ子のプロファイル要素をペアにして前記非対応リストに登録し、
　前記非対応リストに登録されたプロファイル要素及びその入れ子のプロファイル要素のペアを含むプロファイル識別情報を持つコンテンツを前記処理部は処理できないと判定する、
上記（１８）に記載の情報処理装置。
（２０）コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を取得するステップと、
　プロファイル識別情報に基づいてコンテンツを処理するステップと、
を有する情報処理方法。
（２１）コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を記憶する記憶部、
　前記プロファイル識別情報を他の機器に送信する送信部、
としてコンピュータを機能させるようにコンピュータ可読形式で記述されたコンピュータプログラム。
（２２）コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を取得する取得部、
　プロファイル識別情報に基づいてコンテンツを処理する処理部、
としてコンピュータを機能させるようにコンピュータ可読形式で記述されたコンピュータプログラム。

　１００…コンテンツ配信システム
　１０１…サーバ、１０２…クライアント
　３０１…制御部、３０２…コンテンツ取得部
　３０３…コンテンツ送信部、３０４…通信部
　４０１…制御部、４０２…通信部
　４０３…ユーザインターフェース部、４０４…コンテンツ受信部
　４０５…パーサ、４０６…Ｖｉｄｅｏデコーダ
　４０７…Ａｕｄｉｏデコーダ、４０８…出力部

Claims (20)

1. 　コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を記憶する記憶部と、
   　前記プロファイル識別情報を他の機器に送信する送信部と、
   を具備する情報処理装置。
2. 　前記プロファイル識別情報は、コンテンツのコンテナフォーマットに関するプロファイル要素を少なくとも含む、
   請求項１に記載の情報処理装置。
3. 　前記プロファイル識別情報は、コンテンツに適用される保護方式に関するプロファイル要素と、コンテンツのエンコード形式に関するプロファイル要素のうち少なくとも１つを含む、
   請求項１に記載の情報処理装置。
4. 　前記プロファイル識別情報は、Ｖｉｄｅｏのエンコード形式に関するプロファイル要素と、Ａｕｄｉｏのエンコード形式に関するプロファイル要素のうち少なくとも１つを含む、
   請求項３に記載の情報処理装置。
5. 　前記複数のプロファイル要素のうち少なくとも１つは、入れ子のプロファイル要素を内包する、
   請求項１に記載の情報処理装置。
6. 　プロファイル要素の区分け又はその他の補足情報を入れ子のプロファイル要素に記述する、
   請求項５に記載の情報処理装置。
7. 　コンテンツのエンコード形式に関するプロファイル要素は、そのエンコード形式の区分けを記述する入れ子のプロファイル要素を内包する、
   請求項６に記載の情報処理装置。
8. 　前記記憶部は、ｐｒｏｔｏｃｏｌＩｎｆｏ情報の第４フィールド内のＶｅｎｄｏｒ　Ｓｐｅｃｉｆｉｃ　Ｆｉｅｌｄに前記プロファイル識別情報を記憶する、
   請求項１に記載の情報処理装置。
9. 　前記送信部は、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ　Ｐｌｕｇ　ａｎｄ　Ｐｌａｙ）規格のＣＤＳ（Ｃｏｎｔｅｎｔ　Ｄｉｒｅｃｔｏｒｙ　Ｓｅｒｖｉｃｅ）に則って、前記他の機器に前記プロファイル識別情報を送信する、
   請求項１に記載の情報処理装置。
10. 　コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を記憶部に記憶するステップと、
    　前記プロファイル識別情報を他の機器に送信するステップと、
    を有する情報処理方法。
11. 　コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を取得する取得部と、
    　プロファイル識別情報に基づいてコンテンツを処理する処理部と、
    を具備する情報処理装置。
12. 　前記プロファイル識別情報に含まれる各プロファイル要素が表す情報に基づいて、前記処理部による当該コンテンツの処理可能性を判定する、
    請求項１１に記載の情報処理装置。
13. 　前記プロファイル識別情報は、コンテンツのコンテナフォーマットに関するプロファイル要素を少なくとも含み、
    　前記処理部が備えるパーサは前記プロファイル要素が示すコンテナフォーマットに対応しているかどうかに基づいて当該コンテンツの処理可能性を判定する、
    請求項１２に記載の情報処理装置。
14. 　前記プロファイル識別情報は、コンテンツに適用される保護方式に関するプロファイル要素と、コンテンツのエンコード形式に関するプロファイル要素のうち少なくとも１つを含み、
    　前記処理部は保護方式に関するプロファイル要素が示す保護方式に対応し、又は前記処理部が備えるデコーダはエンコード形式に関するプロファイル要素が示すエンコード形式に対応しているかどうかに基づいて当該コンテンツの処理可能性を判定する、
    請求項１２に記載の情報処理装置。
15. 　前記プロファイル識別情報は、Ｖｉｄｅｏのエンコード形式に関するプロファイル要素と、Ａｕｄｉｏのエンコード形式に関するプロファイル要素のうち少なくとも１つを含み、
    　前記処理部が備えるＶｉｄｅｏデコーダはＶｉｄｅｏのエンコード形式に関するプロファイル要素が示すＶｉｄｅｏのエンコード形式に対応し、又は前記処理部が備えるＡｕｄｉｏデコーダはＡｕｄｉｏのエンコード形式に関するプロファイル識別情報が示すＡｕｄｉｏのエンコード形式に対応しているかどうかに基づいて当該コンテンツの処理可能性を判定する、
    請求項１２に記載の情報処理装置。
16. 　前記複数のプロファイル要素のうち少なくとも１つは、プロファイル要素の区分け又はその他の補足情報を記述する入れ子のプロファイル要素を内包し、
    　前記処理部はプロファイル要素が表すコンテンツのプロファイルに対応し、且つ入れ子のプロファイル要素が表すプロファイル要素の区分け又はその他の補足情報に対応しているかどうかに基づいて当該コンテンツの処理可能性を判定する、
    請求項１２に記載の情報処理装置。
17. 　コンテンツのエンコード形式に関するプロファイル要素は、そのエンコード形式の区分け又は補足情報を記述する入れ子のプロファイル要素を内包し、
    　前記処理部が備えるデコーダはエンコード形式に関するプロファイル要素が示すエンコード形式に対応し、且つ、入れ子のプロファイル要素が示すエンコード形式の区分け又は補足情報にも対応しているかどうかに基づいて当該コンテンツの処理可能性を判定する、
    請求項１２に記載の情報処理装置。
18. 　非対応と判定されたプロファイル識別情報を登録する非対応リストを備え、
    　非対応リストに登録されたプロファイル識別情報を持つコンテンツを前記処理部は処理できないと判定する、
    請求項１１に記載の情報処理装置。
19. 　前記処理部がコンテンツの処理に失敗した原因となるプロファイル要素及びその入れ子のプロファイル要素をペアにして前記非対応リストに登録し、
    　前記非対応リストに登録されたプロファイル要素及びその入れ子のプロファイル要素のペアを含むプロファイル識別情報を持つコンテンツを前記処理部は処理できないと判定する、
    請求項１８に記載の情報処理装置。
20. 　コンテンツに関する複数のプロファイル要素を表す情報を連結したプロファイル識別情報を取得するステップと、
    　プロファイル識別情報に基づいてコンテンツを処理するステップと、
    を有する情報処理方法。

Images