JP2005173644A - 情報処理装置および方法、並びに、記録媒体およびその製造方法 - Google Patents

Abstract

【課題】 コンテンツ取得までの一連のユーザ操作を容易にし、かつ、そのユーザ操作に対するユーザ端末のレスポンスを高めることができるようにする。
【解決手段】 クライアント１１−Ｂにリムーバブル記録媒体３１が装着されると、そのリムーバブル記録媒体３１から、１以上のコンテンツのそれぞれのメタデータが読みだされてクライアントメタデータデータベース２２に記憶させるとともに、１以上のコンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、メタデータを利用して誘導する（ナビゲーション情報を画像等の形態で呈示する等）機能を少なくとも有するクライアントアプリケーション（ナビゲーションプログラム）２１−Ａが、クライアントアプリケーション２１としてインストールされる。本発明は、インターネット配信のコンテンツを取得し使用するクライアントに適用可能である。
【選択図】 図３

Description

本発明は、情報処理装置および方法、並びに、記録媒体およびその製造方法に関し、特に、コンテンツ取得までの一連のユーザ操作を容易にし、かつ、そのユーザ操作に対するユーザ端末のレスポンスを高めることができる、情報処理装置および方法、並びに、記録媒体およびその製造方法に関する。

最近、インターネットが普及してきている。これにより、ユーザは、自身が保有する端末をクライアントとしてインターネットに接続し、サーバから配信されてくる各種のコンテンツをインターネットを介して取得し、利用できるようになってきた。

このようなインターネットを介して配信されるコンテンツは、現状においても多数存在し、今後増え続けていくことが予想される。また、その配置場所（配信元）もインターネット上の様々な場所に散在している。

このため、クライアントの機能として次のような機能が要求されている。即ち、クライアントに要求されている機能とは、コンテンツの検索、選択、情報供与、および利用（操作）への誘導のプロセス（クライアントの処理）全般の機能である。なお、以下、このような機能の総称を、コンテンツナビゲーション機能と称する。

従来、クライアントは、図１に示されるようなコンテンツナビゲーション機能を有していることが多い。即ち、図１は、コンテンツナビゲーション機能の従来の形態を説明する図である。

図１において、クライアント１とサーバ２とは、図示せぬインターネットを介して接続されている。

図１に示されるように、サーバ２がインターネットを介して配信可能なコンテンツの中から所望のコンテンツを選択し、それを取得するまでの一連の操作をナビゲート（誘導）するために必要な情報（以下、ナビゲーション情報と称する）は、従来のクライアント１には保持されていない。即ち、クライアント１のブラウザ１０は、必要なときに（ユーザから指示操作が有ったとき等に）その都度、インターネット上のサーバ２に対して、ナビゲーション情報の取得要求（情報要求）を行う。

サーバ２は、ナビゲーション情報をHTML(Hyper Text Markup Language)文章またはBML(Broadcast Markup Language)文章という形態で予め生成しておき、クライアント１から情報要求を受けたとき、そのナビゲーション情報（HTML文章またはBML文章）をクライアント１にインターネットを介して送信する。

なお、このナビゲーション情報に含まれるコンテンツの各種情報は、インターネット上のメタデータデータベース３に保持されたメタデータに基づいて生成された（または、メタデータ自身が使用された）ものである。即ち、サーバ２は、ナビゲーション情報（HTMLまたはBML文章）を生成するとき、メタデータの取得要求（情報要求）をメタデータデータベース３に対して行うことで、必要なメタデータを取得する。

クライアント１のブラウザ１０は、サーバ２からネットワークを介して送信されてきたHTML文章またはBML文章（ナビゲーション情報）を取得し、それを解釈することで画像等の形態に変換してユーザに呈示する。

その後、ユーザは、ブラウザ１０により呈示された画像等（ナビゲーション情報）を利用して、即ち、そのブラウザ１０を利用して、コンテンツ取得までの一連の指示操作を行う。

なお、図１の端末内他エンティティとは、コンテンツを再生するためのアプリケーションソフトウエア等を指す。即ち、ユーザは、取得済みのコンテンツを再生させる場合も、ブラウザ１０を利用して対応する指示操作を行う。

このように、従来のコンテンツナビゲーションにおいては、ユーザとのインタラクションも含めすべてのナビゲーション（処理）は、ブラウザ１０によりハンドリングされる。

なお、このようなコンテンツナビゲーションの従来の形態の詳細は、例えば、特許文献１に開示されている。即ち、特許文献１には、コンテンツ配信システムに関して、クライアントからストリームコンテンツの要求を受けると、サーバが、ストリームコンテンツの再生機能を設定する制御データをそのクライアントへ送信する手法が開示されている。詳細には、特許文献１には、クライアントが、所望のストリームコンテンツをサーバにリクエストしてから再生するまでの一連の処理が開示されている。即ち、特許文献１には、クライアントが、サービスサーバへウェブページのリクエストを行い、そのウェブページから所望のコンテンツを選択し、選択されたコンテンツのURL(Uniform Resource Locator)からストリームコンテンツを取得すると共に、自動的に再生アプリケーションソフトウエアを起動してコンテンツを再生するまでの一連の処理が開示されている。
特開２００３−６１０６６号公報

しかしながら、このようなコンテンツナビゲーション機能の従来の形態には、次のような第１の課題と第２の課題が存在する。

即ち、第１の課題とは、ブラウザ１０とサーバ２との間での通信が常に行われているために、ユーザの指示操作に対するクライアント１のレスポンスが悪いという課題である。特に、アクセスが集中するサーバ２との通信において、この第１の課題は顕著なものとなる。

また、第２の課題とは、ブラウザ１０等の操作に習熟していないユーザにとっては、所望のコンテンツを探し出し、それを取得するまでのプロセス（操作）が煩雑であり、わかりにくいという課題である。

本発明は、このような状況に鑑みてなされたものであり、コンテンツ取得までの一連のユーザ操作を容易にし、かつ、そのユーザ操作に対するユーザ端末のレスポンスを高めることができるようにするものである。

本発明の情報処理装置は、外部に配置されるコンテンツを取得し使用する情報処理装置であって、１以上のコンテンツのそれぞれのメタデータが記録されているとともに、１以上のコンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、メタデータを利用して誘導する誘導ステップと、ユーザが誘導ステップの処理に従って選択したコンテンツの配置場所をメタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップとを含むプログラムが記録されている記録媒体が装着される装着手段と、装着手段に装着された記録媒体に記録されているメタデータを利用して、記録媒体に記録されているプログラムに含まれる誘導ステップと取得ステップとのそれぞれの処理を実行する実行手段とを備えることを特徴とする。

記録媒体には、メタデータを取得するために必要な情報がさらに記録されており、実行手段は、その情報に従ってメタデータを記録媒体から取得し、そのメタデータを利用して誘導ステップと取得ステップとのそれぞれの処理を実行することができる。

記録媒体には、誘導ステップまたは取得ステップの処理のうちの少なくとも一部の処理を実行するために必要な情報がさらに記録されており、実行手段は、その情報に従って、誘導ステップまたは取得ステップの処理のうちの対応する処理を実行することができる。

メタデータには、１以上のコンテンツのそれぞれに対する、購入期間、価格、およびライセンスに関する情報が含まれることができる。

実行手段は、コンテンツを取得し使用するために、記録媒体に記録されたプログラムとは異なる他のプログラムに含まれる他のステップの処理をさらに実行し、記録媒体には、他のプログラムに含まれる他のステップの処理のうちの少なくとも一部の処理を実行するために必要な情報がさらに記録されているようにすることができる。

記録媒体には、メタデータに対応する１以上のコンテンツとは異なる他のコンテンツのデータがさらに記録されているようにすることができる。

本発明の情報処理方法は、外部に配置されるコンテンツを取得し使用する情報処理装置の情報処理方法であって、１以上のコンテンツのそれぞれのメタデータが記録されているとともに、１以上のコンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、メタデータを利用して誘導する誘導ステップと、ユーザが誘導ステップの処理に従って選択したコンテンツの配置場所をメタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップとを含むプログラムが記録されている記録媒体が情報処理装置に装着された場合、情報処理装置に装着された記録媒体に記録されているメタデータを利用して、記録媒体に記録されているプログラムに含まれる誘導ステップと取得ステップとのそれぞれの処理を実行することを特徴とする。

本発明の情報処理装置および情報処理方法においては、１以上のコンテンツのそれぞれのメタデータが記録されているとともに、１以上のコンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、メタデータを利用して誘導する誘導ステップと、ユーザが誘導ステップの処理に従って選択したコンテンツの配置場所をメタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップとを含むプログラムが記録されている記録媒体が情報処理装置に装着された場合、その記録媒体に記録されているメタデータが利用されて、そのプログラムに含まれる誘導ステップと取得ステップとのそれぞれの処理が実行される。

本発明の記録媒体は、外部に配置されるコンテンツを取得し使用する情報処理装置に装着される記録媒体であって、１以上のコンテンツのそれぞれのメタデータが記録されているとともに、情報処理装置を制御するコンピュータに実行させるプログラムであって、１以上のコンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、メタデータを利用して誘導する誘導ステップと、ユーザが誘導ステップの処理に従って選択したコンテンツの配置場所をメタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップとを含むプログラムが記録されていることを特徴とする。

本発明の記録媒体においては、１以上のコンテンツのそれぞれのメタデータが記録されているとともに、１以上のコンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、メタデータを利用して誘導する誘導ステップと、ユーザが誘導ステップの処理に従って選択したコンテンツの配置場所をメタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップとを含むプログラムが記録されている。これにより、本発明の記録媒体が情報処理装置に装着された場合、その記録媒体に記録されているメタデータが利用されて、そのプログラムに含まれる誘導ステップと取得ステップとのそれぞれの処理が実行される。

本発明の記録媒体の製造方法は、外部に配置されるコンテンツを取得し使用する情報処理装置に装着される記録媒体の製造方法において、１以上のコンテンツのそれぞれのメタデータを記録媒体に予め記録する第１の記録ステップと、情報処理装置を制御するコンピュータに実行させるプログラムであって、１以上のコンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、メタデータを利用して誘導する誘導ステップと、ユーザが誘導ステップの処理に従って選択したコンテンツの配置場所をメタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップとを含むプログラムを記録媒体に予め記録する第２の記録ステップとを含むことを特徴とする。

本発明の記録媒体の製造方法においては、１以上のコンテンツのそれぞれのメタデータが記録媒体に予め記録されるとともに、情報処理装置を制御するコンピュータに実行させるプログラムであって、１以上のコンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、メタデータを利用して誘導する誘導ステップと、ユーザが誘導ステップの処理に従って選択したコンテンツの配置場所をメタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップとを含むプログラムがその記録媒体に予め記録される。これにより、本発明の記録媒体が情報処理装置に装着された場合、その記録媒体に記録されているメタデータが利用されて、そのプログラムに含まれる誘導ステップと取得ステップとのそれぞれの処理が実行される。

以上のごとく、本発明によれば、ユーザは所望のコンテンツを取得することができる。特に、ユーザが所望のコンテンツを取得するまでの一連の操作を容易にし、かつ、そのユーザの操作に対応するユーザ端末の処理のレスポンスを高めることができる。

以下に本発明の実施の形態を説明するが、請求項に記載の構成要件と、発明の実施の形態における具体例との対応関係を例示すると、次のようになる。この記載は、請求項に記載されている発明をサポートする具体例が、発明の実施の形態に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、構成要件に対応するものとして、ここには記載されていない具体例があったとしても、そのことは、その具体例が、その構成要件に対応するものではないことを意味するものではない。逆に、具体例が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その具体例が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。

さらに、この記載は、発明の実施の形態に記載されている具体例に対応する発明が、請求項に全て記載されていることを意味するものではない。換言すれば、この記載は、発明の実施の形態に記載されている具体例に対応する発明であって、この出願の請求項には記載されていない発明の存在、すなわち、将来、分割出願されたり、補正により追加される発明の存在を否定するものではない。

本発明によれば、情報処理装置が提供される。この情報処理装置（例えば、図４、図６、および図８のクライアント１０３）は、外部（例えば、図４のサーバ１０１であって、詳細には、図８のコンテンツサーバ２２５）に配置されるコンテンツ（例えば、主に図９のContents本体。ただし、本明細書においては、図９のstartup fileやDownload.xmlといった制御情報もコンテンツに含める）を取得し使用する情報処理装置であって、１以上のコンテンツのそれぞれのメタデータ（例えば、図１０のメタデータであって、詳細は、図１８乃至図３６に示されている）が記録されているとともに、１以上の前記コンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、前記メタデータを利用して誘導する誘導ステップ（例えば、図１１のステップＳ２の「購入コンテンツナビゲーション処理（詳細は図１３）」や、ステップＳ８の「利用コンテンツナビゲーション処理（詳細は図１７）」）と、前記ユーザが前記誘導ステップの処理に従って選択した前記コンテンツの配置場所を前記メタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップ（例えば、図１５のステップＳ８１乃至Ｓ８２、図１１のステップＳ７の「ダウンロード処理（詳細は図１６）」、および、図１１のステップＳ９）とを含むプログラム（例えば、図８のクライアントアプリケーション（ナビゲーションプログラム２０３−Ａ）が記録されている記録媒体（例えば、図８等のリムーバブル記録媒体１３１）が装着される装着手段（例えば、図６と図８のドライブ１６４）と、前記装着手段に装着された前記記録媒体に記録されている前記メタデータを利用して、前記記録媒体に記録されている前記プログラムに含まれる前記誘導ステップと前記取得ステップとのそれぞれの処理を実行する実行手段（例えば、図６のCPU１５７）とを備えることを特徴とする。

この情報処理装置の前記実行手段は、前記コンテンツを取得し使用するために、前記記録媒体に記録された前記プログラムとは異なる他のプログラム（例えば、図８のコンテンツ再生部２０４乃至ダウンロード処理部２０７等のヘルパーアプリケーション）に含まれる他のステップの処理をさらに実行し、前記記録媒体には、前記他のプログラムに含まれる前記他のステップの処理のうちの少なくとも一部の処理を実行するために必要な情報がさらに記録されているようにすることができる。

また、本発明によれば、この情報処理装置の情報処理方法も提供される。

本発明によれば、記録媒体が提供される。この記録媒体（例えば、図８等のリムーバブル記録媒体１３１）は、外部（例えば、図４のサーバ１０１であって、詳細には、図８のコンテンツサーバ２２５）に配置されるコンテンツを取得し使用する情報処理装置（例えば、図４、図６、および図８のクライアント１０３）に装着される記録媒体であって、１以上の前記コンテンツのそれぞれのメタデータ（例えば、図１０のメタデータであって、詳細は、図１８乃至図３６に示されている）が記録されているとともに、前記情報処理装置を制御するコンピュータ（例えば、図６のCPU１５７）に実行させるプログラムであって、１以上の前記コンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、前記メタデータを利用して誘導する誘導ステップと、前記ユーザが前記誘導ステップの処理に従って選択した前記コンテンツの配置場所を前記メタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップとを含むプログラム（例えば、図８のクライアントアプリケーション（ナビゲーションプログラム２０３−Ａ）が記録されていることを特徴とする。

本発明によれば、外部（例えば、図４のサーバ１０１であって、詳細には、図８のコンテンツサーバ２２５）に配置されるコンテンツを取得し使用する情報処理装置（例えば、図４、図６、および図８のクライアント１０３）に装着される記録媒体（例えば、図８等のリムーバブル記録媒体１３１）の製造方法（例えば、図３９に示される製造方法）であって、１以上の前記コンテンツのそれぞれのメタデータ（例えば、図１０のメタデータであって、詳細は、図１８乃至図３６に示されている）を前記記録媒体に予め記録する第１の記録ステップ（例えば、図３９のステップＳ３０２）と、前記情報処理装置を制御するコンピュータ（例えば、図６のCPU１５７）に実行させるプログラムであって、１以上の前記コンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、前記メタデータを利用して誘導する誘導ステップと、前記ユーザが前記誘導ステップの処理に従って選択した前記コンテンツの配置場所を前記メタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップとを含むプログラム（例えば、図８のクライアントアプリケーション（ナビゲーションプログラム２０３−Ａ）を前記記録媒体に予め記録する第２の記録ステップ（例えば、図３９のステップＳ３０４）とを含むことを特徴とする。

次に、図面を参照して、本発明の実施の形態について説明する。

はじめに、図２と図３とを参照して、本発明の原理について説明する。

図２は、従来の課題（上述した従来のコンテンツナビゲーション機能（図１参照）が有する第１の課題と第２の課題）を解決可能な、コンテンツナビゲーション機能の一形態を説明する図である。

図２の形態においては、従来の課題を解決するために、クライアント１１−Ａには、クライアントアプリケーション２１とクライアントメタデータデータベース２２とが設けられる。

クライアントアプリケーション２１は、コンテンツ配信におけるクライアント１１−Ａの主要なユーザインタフェース機能やクライアント１１−Ａ全体のシステム制御を担うアプリケーションソフトウエアである。

クライアントアプリケーション２１は、アクセス可能なコンテンツの全てに対するメタデータの取得要求（メタデータ取得要求）をネットワーク（図示せぬ）上のメタデータデータベース３（図１と同様）に対して定期的に行い、その結果、メタデータデータベース３から送信されてくるメタデータをクライアントメタデータデータベース２２に記憶させる。

そして、ユーザからコンテンツの取得の指示等の指示操作がなされると、クライアントアプリケーション２１は、クライアントメタデータデータベース２２に対して必要なメタデータの取得要求（情報要求）を行い、その結果クライアントメタデータデータベース２２から供給されるメタデータを利用して、ナビゲーション情報を画像等の形態で生成し、ユーザに呈示する。

その後、ユーザは、クライアントアプリケーション２１により呈示された画像等（ナビゲーション情報）を利用して、即ち、そのクライアントアプリケーション２１を利用して、コンテンツ取得までの指示操作を行う。

このように、図２に示される形態のコンテンツナビゲーション機能においては、ナビゲーション情報をユーザに呈示し、ユーザに所望のコンテンツを選択させる（対応する指示操作をさせる）までの間の処理は、クライアント１１−Ａの内部処理で完結する（ネットワークを介する通信処理は不要となる）。これに対して、図１に示される従来の形態では、ナビゲーション情報がユーザに呈示され、ユーザによりコンテンツが選択されるまでの間に、ネットワークを介するサーバ２との通信処理が必須となる。そこで、以下、コンテンツナビゲーション機能のうちの、従来の形態（図１に示される形態）を、ネットワーク依存型ナビゲーションと称し、また、図２に示される形態を、クライアント主体型ナビゲーションと称する。

以上説明したように、クライアント主体型ナビゲーションにおいては、ナビゲーション処理に必要な情報（メタデータ）がクライアント１１−Ａ内のクライアントメタデータデータベース２２に予め蓄積されているので、即ち、インターネット等のネットワークを介する通信処理を行ってメタデータを新たに取得する必要が無いので、迅速な情報アクセスや表示ができる。即ち、従来の第１の課題を解決できる効果を奏することが可能になる。

さらに、クライアント主体型ナビゲーションにおいては、ブラウザ１１（図１）ではなくクライアントアプリケーション２１が、ユーザとのインタラクションも含めたナビゲーション（処理）をハンドリングする。従って、このクライアントアプリケーション２１として、視聴者の操作性を追求したソフトウエアを適用することで、事業者によらず統一感のある分かり易いコンテンツナビゲーション機能を実現できる。即ち、従来の第２の課題を解決できる効果を奏することが可能になる。

一方、クライアント１１−Ａの製造や販売等を行う者（自然人、法人、または団体等）にとっては、独自のクライアントアプリケーション２１をクライアント１１−Ａに搭載させることで、差別化戦略を築き易い、といった効果を奏することも可能である。

しかしながら、このような効果を奏することが可能なクライアント主体型ナビゲーションにも、次のような第３の課題と第４の課題が存在する。

即ち、第３の課題とは、コンテンツの数が増大すると、それらのメタデータの全てをクライアントメタデータデータベース２２に保持させるのは困難となるという課題である。

第４の課題とは、メタデータデータベース３の分散化に対する対処方法や、メタデータの定期的な取得によるクライアントメタデータデータベース２２の更新方法等の運用方法の実現が困難であるという課題である。

そこで、本願出願人は、第３の課題と第４の課題とを解決すべく、次のような手法を発明した。即ち、本願出願人が発明した手法とは、図３に示されるように、リムーバブル記録媒体３１にメタデータを記録させ、クライアント１１−Ｂにそのメタデータを利用させる手法である。換言すると、本願出願人は、図２のクライアント主体型ナビゲーションに対して、本手法を適用することで、図３に示されるような、コンテンツナビゲーション機能の新たな形態を発明したとも言える。

以下、この図３を参照して、本発明の原理（手法）についてさらに詳しく説明する。なお、図３において、図２と対応する部分には対応する符号が付してある。

図３に示されるように、本発明が適用されるクライアント１１−Ｂにも、図２のクライアント１１−Ａと同様に、クライアントアプリケーション２１とクライアントメタデータデータベース２２とが設けられている。

ただし、本発明においては、クライアントメタデータデータベース２２に蓄積されるメタデータは、メタデータデータベース３からネットワークを介する定期的な通信により取得されるだけではなく、リムーバブル記録媒体３１からの取得も可能とされている。

なお、メタデータのリムーバブル記録媒体３１への記録の形態自身は特に限定されないが、例えば、リムーバブル記録媒体３１にメタデータが記録されていることをクライアント１０３が容易に判断できるように、特定のファイル名で記録させることができる。さらに、メタデータを一般的に開放したくない等の場合には、例えば、リムーバブル記録媒体３１の特定のセクタなど隠蔽された固定空間にメタデータを記録させてもよい。

このように、リムーバブル記録媒体３１にメタデータを記録させることで、クライアント１１−Ｂは、必要なときにのみ、そのリムーバブル記録媒体３１からメタデータを適宜取得することができ、その結果、クライアントメタデータデータベース２２側でメタデータの全てを保持がする必要がなくなる。即ち、第３の課題を解決できる効果を奏することが可能になる。

また、ユーザがリムーバブル記録媒体３１を保有し、必要なとき（コンテンツの取得を所望するとき等）にリムーバブル記録媒体３１をクライアント１１−Ｂに単に装着させる、といった簡易な運用方法の実現が容易に可能となる。即ち、第４の課題を解決できる効果を奏することが可能になる。

なお、メタデータを記録させるリムーバブル記録媒体３１の形態は特に限定されず、例えば、磁気ディスク（フロッピディスクを含む）、光ディスク（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク（ＭＤ（Mini-Disk）を含む）、および半導体メモリ等の様々な形態が存在する。

従って、ナビゲーション情報等の提示形態を、リムーバブル記録媒体３１の形態に対応して可変させることができる。即ち、リムーバブル記録媒体３１に記録された他の情報（コンテンツ等）の一般的な呈示形態と同様の呈示形態で、ナビゲーション情報等も呈示させることもできる。これにより、ユーザは、リムーバブル記録媒体３１に記録された情報を使用する場合の一般的な操作と同様の操作を行うだけで、そのリムーバブル記録媒体３１に記録されたメタデータに対応するコンテンツの取得操作を行うことができる。即ち、上述した従来の第２の課題をよりよく解決できる効果を奏することが可能になる。

具体的には、例えば、DVDの再生機器等においては、DVDに記録された複数のコンテンツ（例えば、映画の本編と、他の映画のダイジェスト版）の中から視聴するコンテンツを切り替える操作や、所定の１コンテンツ内のシーンを切り替える（チャプタを選択する）操作を行うために、メニュー画面と称される画像を利用するユーザインタフェースが提供されている。

そこで、クライアント１１−Ｂのクライアントアプリケーション２１は、このようなユーザインタフェースの提供機能を有していれば、DVD−ROMで構成されるリムーバブル記録媒体３１に記録されたメタデータから、ナビゲーション情報等をメニュー画面の形態で生成し、表示させることができる。

これにより、ユーザは、DVD−ROM（リムーバブル記録媒体３１）によって提供されたメニュー画面（ナビゲーション情報等）を利用することで、例えば、そのメニュー画面のうちの所定のボタン（ブロードバンド配信サービスのボタン等）のクリック操作を行うことで、多様なメディア連動サービスの享受が可能となる。具体的には、例えば、サービス提供者側で予め指定したインターネット上のサイトを表示させるサービスや（ただし、クライアントアプリケーション２１等がHTML文章やBML文章のブラウジング機能を有している場合）、クライアント１１−Ｂに既にダウンロードされたコンテンツ（例えば、特定の期間ある種のサービスによりお薦め録画的にダウンロードされたコンテンツ）の参照サービス等の享受が可能となる。

このように、DVDのメニュー画面を利用した操作に慣れたユーザにとっては、そのメニュー画面を利用するコンテンツの取得操作の利便性が非常に高くなる、といった効果を奏することが可能になる。

このような様々な効果を奏することが可能な本発明（図３）の具体的な適用例として、例えば、次のような例が挙げられる。

即ち、例えば、販売コンテンツが記録されたリムーバブル記録媒体３１（パッケージメディア）に、その販売コンテンツとは異なる他のコンテンツのメタデータをさらに記録させることで、販売コンテンツ（リムーバブル記録媒体３１）を購買したユーザに対して、他のコンテンツのメタデータも流通させる、といった例である。

この例の場合、販売コンテンツと他のコンテンツとの組み合わせ方は無数に考えられ、その組み合わせ方によって様々な分野に適用可能である。

例えば、販売コンテンツにプレミアム（付加価値）を付けることを目的として他のコンテンツを利用する、といった分野に適用可能である。具体的には、例えば、販売コンテンツとして、とある歌手の楽曲を想定した場合、他のコンテンツとして、その歌手のコンサートの録画映像等（データ）をインターネット上に保存しておき、販売コンテンツのパッケージメディア（リムーバブル記録媒体３１）の中に、他のコンテンツのライセンスを取得するために必要な情報や、他のコンテンツの紹介（宣伝）を呈示するために必要な情報等をメタデータとして記録しておくことができる。

また、例えば、他のコンテンツの宣伝を行うことを目的として販売コンテンツを利用する、といった分野にも適用可能である。具体的には、例えば、宣伝対象のコンテンツ（他のコンテンツ）として、未来にインターネット配信される予定の有料コンテンツ（ドラマ番組等）を想定した場合、その配信予定の有料コンテンツ（他のコンテンツ）に関連するコンテンツ（例えば、同一の俳優が出演している映画等）が、販売コンテンツとして記録されたパッケージメディア（リムーバブル記録媒体３１）の中に、他のコンテンツのライセンスを取得するために必要な情報や、他のコンテンツの紹介（宣伝）を呈示するために必要な情報をメタデータとして記録しておくことができる。

なお、このような有料コンテンツに対するメタデータをリムーバブル記録媒体３１に含ませる場合、そのメタデータの中には、対応する有料コンテンツの購入期間、価格、および、ライセンスに関する情報が含まれていると好適である。ただし、これらのメタデータの詳細については、図１０、および、図１８乃至図３６等を参照して後述する。

さらに、本発明（図３）の具体的な他の適用例として、例えば、販売コンテンツ等を含まないリムーバブル記録媒体３１（空のリムーバブル記録媒体３１等）にコンテンツのメタデータ（および、コンテンツの取得に必要なその他の情報）のみを記録させ、そのコンテンツを流通させる、といった例が挙げられる。

具体的には、例えば、通常、音楽アルバムの販売用CDには、提供者側で予め設定された楽曲（例えば、５つの楽曲）が記録されている。これに対して、本発明を適用することで、例えば、予め設定された１０の楽曲の中から所望の楽曲を５つまでユーザに自由に選択させ、CDに記録させる、といった例の実現が容易に可能となる。即ち、１０の楽曲のそれぞれのメタデータのみが記録されたリムーバブル記録媒体３１をユーザに販売し、ユーザは、そのリムーバブル記録媒体３１をクライアント１１−Ｂに装着させることで、それらの１０の楽曲の中から任意の（所望の）５曲のみをダウンロードさせ、そのリムーバブル記録媒体３１に記録させる、といった例の実現が容易に可能となる。

さらにまた、本発明（図３）の具体的な他の適用例として、例えば、コンテンツを幅広く流通させることを目的として、そのコンテンツのメタデータのみを記録したリムーバブル記録媒体３１を無償で或いは安価（コンテンツの価格未満）でユーザに配布する、といった例も挙げられる。

ところで、以上においては、クライアントアプリケーション２１がクライアント１１−Ｂにインストールされていることが前提とされた。このため、上述したような本発明（図３）の具体的な適用例を実現する場合、対象となるユーザは、クライアントアプリケーション２１がインストールされたクライアント１１−Ｂを保有する者のみであるという縛りが発生し、この縛りのため、コンテンツの幅広い流通が困難となるという課題が発生してしまう。

そこで、このような課題を解決するために、本発明においては、メタデータに加えてさらに、クライアントアプリケーション２１−Ａもリムーバブル記録媒体３１に記録させることができる。

なお、リムーバブル記録媒体３１に記録されるクライアントアプリケーションの符号として、単に２１を付与せずに２１−Ａを付与しているのは、クライアント１１−Ｂにインストールされたクライアントアプリケーション２１と、リムーバブル記録媒体３１に記録されるクライアントアプリケーション２１−Ａとは必ずしも一対一に対応するとは限らないからである。

即ち、リムーバブル記録媒体３１に記録されるクライアントアプリケーション２１−Ａは、リムーバブル記録媒体３１に共に記録されるメタデータに対応するコンテンツを取得するために必要な機能（例えば、コンテンツナビゲーション機能と、コンテンツ取得機能）を有すれば足りる。これに対して、クライアント１１−Ｂにインストールされたクライアントアプリケーション２１は、後述するように、コンテンツナビゲーション機能やコンテンツ取得機能以外にも、様々な機能を有していることが多いからである。また、リムーバブル記録媒体３１に記録されているクライアントアプリケーション２１−Ａは、リムーバブル記録媒体３１に共に記録されるメタデータに対応するコンテンツの取得は可能であるが、それ以外のコンテンツの取得が可能であるとは限らないからである。

そこで、以下、リムーバブル記録媒体３１に記録されたクライアントアプリケーション２１−Ａを、クライアント１０３にインストールされたクライアントアプリケーション２１と明確に区別するために、ナビゲーションプログラム２１−Ａと適宜称する。

即ち、ナビゲーションプログラム２１−Ａとは、１以上のコンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、（リムーバブル記録媒体３１に共に記憶される）メタデータを利用して誘導するコンテンツナビゲーション機能を少なくとも有するソフトウエアであって、リムーバブル記録媒体３１に記録されるソフトウエアである。なお、ナビゲーションプログラム２１−Ａは、他の機能をさらに有することもある。例えば、他の機能としては、ユーザがコンテンツナビゲーション機能を利用して選択したコンテンツの配置場所を（リムーバブル記録媒体３１に共に記憶される）メタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得するコンテンツ取得機能等が挙げられる。

なお、後述するように（図８の白抜き矢印に示されるように）、メタデータやクライアントアプリケーション（ナビゲーションプログラム）２１−Ａに加ええてさらに、そのメタデータに対応するコンテンツの一部（後述する図９に示されるstartup fileやDownload.xmlといった制御情報）等をリムーバブル記録媒体３１に記録させることもできる。これにより、それらの情報を取得するためのネットワーク通信が不要となり、その結果、通信量の削減ができる。また、後述するように、そのような情報をメタデータと共に記録したリムーバブル記録媒体３１自身の付加価値を高めることもできる。

さらに、このメタデータの取得、または、クライアントアプリケーション（ナビゲーションプログラム）２１−Ａのインストール、起動、若しくは、所定の処理の実行のためのコマンドやファイル等が、メタデータやクライアントアプリケーション（ナビゲーションプログラム）２１−Ａと共にリムーバブル記録媒体３１に記録されることもある。

さらにまた、ヘルパーアプリケーション（コンテンツ再生部２０４乃至ダウンロード処理部２０７等）の処理のうちの少なくとも一部の処理を実行するために必要な情報（コマンドやファイル）がリムーバブル記録媒体３１に記録されることもある。

以上、本発明の概略（原理）について説明した。以下、本発明についてさらに詳しく説明する。

図４は、本発明が適用されるコンテンツ配信システム、即ち、本発明が適用される情報処理装置（クライアント等）を含むコンテンツ配信システムの構成例を示している。

図４に示されるように、本実施の形態のコンテンツ配信システムにおいては、サーバ１０１とクライアント１０３とがネットワーク１０２を介して相互に接続されている。

なお、図４においては、サーバ１０１とクライアント１０３とがそれぞれ１つずつしか図示されていないが、当然ながら、サーバ１０１とクライアント１０３とのそれぞれの個数は１に限定されず、複数個とすることができる。また、後述するように、サーバ１０１は、１台の情報処理装置で構成してもよいし、複数台の情報処理装置で構成してもよい。

また、ネットワーク１０２の形態は特に限定されないが、ここでは、上述した従来の例との比較を容易なものとするために、インターネットとされる。

サーバ１０１は、例えば、図５に示されるようなパーソナルコンピュータで構成することができる。或いは、サーバ１０１は、複数台の、図５に示されるようなパーソナルコンピュータで構成することができる。

図５において、CPU（Central Processing Unit）１２１は、ROM（Read Only Memory）１２２に記録されているプログラム、または記憶部１２８からRAM（Random Access Memory）１２３にロードされたプログラムに従って各種の処理を実行する。RAM１２３にはまた、CPU１２１が各種の処理を実行する上において必要なデータなども適宜記憶される。

CPU１２１、ROM１２２、およびRAM１２３は、バス１２４を介して相互に接続されている。このバス１２４にはまた、入出力インタフェース１２５も接続されている。

入出力インタフェース１２５には、キーボード、マウスなどよりなる入力部１２６、ディスプレイなどよりなる出力部１２７、ハードディスクなどより構成される記憶部１２８、および、モデム、ターミナルアダプタなどより構成される通信部１２９が接続されている。通信部１２９は、インターネットを含むネットワーク１０２（図４）を介して他の情報処理装置（ここでは、図４に示されるように、クライアント１０３）との通信処理を行う。

入出力インタフェース１２５にはまた、必要に応じてドライブ１３０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどよりなるリムーバブル記録媒体１３１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部１２８にインストールされる。

また、ドライブ１３０に装着されたリムーバブル記録媒体１３１には、記憶部１２８に記憶されているデータやプログラム、例えば、上述したメタデータ、ナビゲーションプログラム（クライアントアプリケーション）、コンテンツの一部分（制御情報）等、様々な情報が適宜記録される。なお、リムーバブル記録媒体１３１に記録される情報には、外部から供給され通信部１２９により受信された情報が含まれることもある。

換言すると、サーバ１０１は、メタデータ、ナビゲーションプログラム（クライアントアプリケーション）、および、コンテンツの一部分（制御情報）等、様々な情報を、ドライブ１３０に装着されたリムーバブル記録媒体１３１に記録することができる。即ち、メタデータが記録されたリムーバブル記録媒体１３１、ナビゲーションプログラム（クライアントアプリケーション）がさらに記録されたリムーバブル記録媒体１３１、または、コンテンツの一部分（制御情報）等、その他の情報がさらに記録されたリムーバブル記録媒体１３１が、サーバ１０１により製造される。

なお、このようなメタデータ、ナビゲーションプログラム（クライアントアプリケーション）、および、その他の情報のうちの少なくともメタデータが記録されたリムーバブル記録媒体１３１は、サーバ１０１とは異なる他の情報処理装置（図示せず）により製造されることもある。

以上、図５を参照して、サーバ１０１のハードウエアの構成例について説明した。

次に、クライアント１０３のハードウエアの構成について説明する。

クライアント１０３も、図５に示されるようなパーソナルコンピュータで構成することもできるが、その他、例えば、図６に示されるように、ハードディスクビデオレコーダで構成することもできる。

この場合、図６に示されるように、クライアント１０３には、アンテナ１７１と表示装置１７２がさらに接続される。

クライアント１０３は、図示せぬ放送局から放送された放送電波をアンテナ１７１を介して受信すると、その放送電波を復調し、その結果得られる映像信号と音声信号とを表示装置１７２に提供する。このとき必要に応じて、クライアント１０３は、その映像信号と音声信号とをコンテンツとして自分自身の内部（後述する同図の補助記憶部１６０等）に記憶させ、それ以降、再生が指令される度に、その映像信号と音声信号とを表示装置１７２に繰り返し供給することができる。

また、クライアント１０３は、図４のサーバ１０１から配信されてくるコンテンツをネットワーク１０２を介して受信し、そのコンテンツに対応する映像信号と音声信号とを表示装置１７２に供給したり、コンテンツを自分自身の内部に一度記憶させ、それ以降、再生が指令される度に、そのコンテンツに対応する映像信号と音声信号とを表示装置１７２に繰り返し供給することもできる。

即ち、サーバ１０１のコンテンツの配信方法には、ストリーミングによる配信（以下、ストリーミング配信と適宜称する）とダウンロードのファイルによる配信（以下、ダウンロード配信と適宜称する）とが存在する。ストリーミング配信の場合、クライアント１０３は、ネットワーク１０２を介して受信したコンテンツ（それに対応する映像信号と音声信号）をリアルタイムで表示装置１７２に出力することになる。これに対して、ダウンロード配信の場合、コンテンツは、例えば、補助記憶部１６０等に一旦記録される。それ以降、再生が指令される度に、補助記憶部１６０等に記録されたコンテンツ（ファイル）が読み出され、そのコンテンツに対応する映像信号と音声信号とが表示装置１７２に繰り返し供給される。

表示装置１７２は、例えば、テレビジョン受像機やモニタ等として構成され、クライアント１０３から映像信号と音声信号とが供給されると、その映像信号に対応する映像を表示するとともに、その音声信号に対応する音声を出力する。

クライアント１０３のハードウエア構成例についてさらに詳しく説明する。

図６のクライアント１０３において、チューナ１５１は、ユーザにより選択されたチャンネル（入力部１６２の入力に対応するチャンネル）または予め設定されたチャンネルの放送電波、即ち、そのチャンネルに対応する放送局から放送された放送電波をアンテナ１７１を介して受信して復調し、その結果得られるテレビジョン放送信号（映像信号と音声信号）をエンコーダ１５２に供給する。

このとき、地上波のテレビジョン放送信号の垂直ブランキング期間には、これから放送される放送番組に対するEPG（Electronic Program Guide）情報が含まれていることがある。また、衛星波のテレビジョン放送信号にも、これから放送される放送番組に対するEPG情報が含まれていることがある。そこで、チューナ１５１はさらに、復調した映像信号をEPG取得部１５４にも供給する。

EPG取得部１５４は、供給された映像信号にEPG情報が含まれている場合、そのEPG情報を抽出して所定のメモリ（例えば、主記憶部１６１、補助記憶部１６０、或いは、主記憶部１５５等）に記憶させる。なお、このEPG情報を、上述したメタデータとして使用することもできる。

エンコーダ１５２は、チューナ１５１より供給されたテレビジョン放送信号を、例えばMPEG（Moving Picture Experts Group）方式でエンコードした上で、バス１５８を介して補助記憶部１６０にファイル形式で記憶させる。

即ち、補助記憶部１６０は、例えば、ハードディスク等で構成され、各放送番組のそれぞれを構成するデータ、即ち、エンコードされたテレビジョン放送信号をファイル形式で記憶する。

また、補助記憶部１６０は、上述したように、サーバ１０１（図４）から配信され、通信部１６３に受信されたコンテンツ（ファイル）も記憶する。

さらに、補助記憶部１６０は、リムーバブル記録媒体１３１に記録された情報、即ち、上述した、メタデータやナビゲーションプログラム（後述する図８の例では、クライアントアプリケーション（ナビゲーションプログラム）２０３−Ａ）がインストールされる。

補助記憶部１６０に記憶されたコンテンツ（データ）のうちの再生が指示されたコンテンツは、バス１５８を介してデコーダ１５３に供給される。デコーダ１５３は、このコンテンツ（データ）を、MPEG方式でデコードした上で表示装置１７２に供給する。デコーダ１５３は、通信部１６３から供給されるコンテンツ（ストリーミング配信のコンテンツ）のデータも、MPEG方式でデコードした上で表示装置１７２に供給する。

さらに、デコーダ１５３は、補助記憶部１６０等に記憶されたその他の各種情報（例えば、後述する図１４のコンテンツのリスト等）も、映像信号または音声信号の形態で表示装置１７２に供給する。

なお、エンコーダ１５２とデコーダ１５３は、補助記憶部１６０に記憶されていたコンテンツ若しくはその他の情報、または、通信部１６３から供給されるコンテンツ若しくはその他の情報等を表示装置１７２に供給していないときには、チューナ１５１より出力されたテレビジョン放送信号をそのまま表示装置１７２に供給することもできる。

ところで、バス１５８には、上述した、エンコーダ１５２、デコーダ１５３、および、補助記憶部１６０の他、ROM１５９、主記憶部１６１、入力部１６２、および通信部１６３が接続されている。ROM１５９には、CPU１５７が実行するプログラム（その具体例については図８を参照して後述する）が記憶されている。一方、RAMなどよりなる主記憶部１６１には、CPU１５７が各種の処理を実行する上において必要なデータやパラメータが適宜記憶される。入力部１６２は、クライアント１０３の表面に配置されるキー群（図示せず）や、図７に示されるリモートコマンダ１８１と受光部（図示せず）との組み合わせ等から構成される。

図７に示されるように、このリモートコマンダ１８１は、数字１乃至１２に対応する数字ボタン１８２を有している。また、リモートコマンダ１８１の前方先端には、ユーザのボタン操作に対応する赤外線信号を発生する発生部１８３が設けられている。

数字ボタン１８２の図中下側には、カーソルなどを上下左右に移動させるとき操作される方向ボタン１８５Ｕ，１８５Ｄ，１８５Ｌ，１８５Ｒと、その中央に確定処理を行うとき、操作される決定ボタン１８４が配置されている。

また、リモートコマンダ１８１の図中下側には、詳細ボタン１８６、停止ボタン１８７、および再生ボタン１８８が設けられている。詳細ボタン１８６は、呈示されている情報のより詳細な情報の提示を指示するとき操作される。停止ボタン１８７は、コンテンツの再生を停止するとき操作される。再生ボタン１８８は、コンテンツの再生を指示するとき操作される。再生ボタン１８８の上方のメニューボタン１８９は、メニューを表示するとき操作される。

なお、図示は省略されているが、リモートコマンダ１８１には、この他、各種の機能が割り当てられた各種のボタンが適宜設けられる。

図６に戻り、通信部１６３は、ネットワーク１０２を介するサーバ１０１（図４）との通信を制御する。なお、通信部１６３により通信が制御される情報の具体例については、図８を参照して後述する。

バス１５８にはさらに、ドライブ１６４が接続され、磁気ディスク、光ディスク、光磁気ディスク、または、半導体メモリなどのリムーバブル記録媒体１３１が適宜装着され、それらから読み出されたコンピュータプログラムが必要に応じて補助記憶部１６０にインストールされる。具体的には、例えば、リムーバブル記録媒体１３１にクライアントアプリケーション（ナビゲーションプログラム）２０３−Ａ（後述する図８参照）が記録されていた場合、それが必要に応じて適宜読み出され、補助記憶部１６０にインストールされる。

また、リムーバブル記録媒体１３１にメタデータが記録されていた場合、それが必要に応じて適宜読み出され、補助記憶部１６０の所定の領域（後述する図８に示されるクライアントメタデータデータベース２０９）に記憶される。

さらに、リムーバブル記録媒体１３１にその他の情報（後述する図９のstartup fileやdownload.xml等の制御情報や、後述するクライアントアプリケーション２０３に対するコマンド若しくはファイル等）が記録されている場合、それが必要に応じて適宜読み出され、主記憶部１５５や主記憶部１６１等に記憶される。

一方、バス１５６には、チューナ１５１、エンコーダ１５２、デコーダ１５３、EPG取得部１５４、RAMなどよりなる主記憶部１５５、および、CPU１５７が接続されている。

従って、例えば、クライアント１０３が起動された場合、CPU１５７は、ROM１５９に記録された各種のソフトウエアを読み出し、それらのソフトウエアに従って所定の処理を実行する。このとき、主記憶部１５５や主記憶部１６１には、そのときの処理に必要なデータなどが適宜記憶されるので、CPU１５７は、これらのデータの送受信の処理をバス１５６やバス１５８を介して対応するブロックと行う。

図８は、本実施の形態のコンテンツ配信システム（図４）の機能的構成例を示している。即ち、図８は、本実施の形態のサーバ１０１（図５）とクライアント１０３（図６）とのそれぞれの機能的構成例を示している。

図８において、太線の矢印はメタデータの伝送の流れを、白抜きの矢印はコンテンツの伝送の流れを、細線の矢印はその他の情報の流れを、それぞれ示している。

はじめに、クライアント１０３に着目すると、入力部１６２は、上述したように、リモートコマンダ１８１（図７）等で構成され、ユーザからの各種の指令を入力する。表示装置１７２は、上述したように、コンテンツを構成する画像を表示したり、対応する音声を出力する。また、表示装置１７２は、その他の各種の情報をユーザに呈示する。なお、上述した説明においては、表示装置１７２は、クライアント１０３に接続された外部機器として捉えたが、クライアント１０３の一構成要素であると捉えてもよい。そこで、表示装置１７２がクライアント１０３の一構成要素となり得ることも考慮して、以下、表示装置１７２を呈示部１７２と称する。

クライアントアプリケーション２０３は、上述したように、クライアント１０３がコンテンツ配信におけるクライアント端末として機能するように、主要なユーザインタフェース機能やクライアント１０３のシステム制御機能を有するアプリケーションソフトウエアである。

詳細には、クライアントアプリケーション２０３の主要な機能として、例えば、次の（１）乃至（１０）に示される機能が存在する。

（１）クライアント１０３の様々な機能へのエントリの提供（メニュー）
（２）クライアント１０３が利用するコンテンツ（パッケージ）のメタデータの事前取得機能
（３）クライアントメタデータデータベース２０９に蓄積されたメタデータに基づくコンテンツナビゲーション機能（購入または取得のためのコンテンツ（パッケージ）選択を目的としたナビゲーション機能（後述する図１３参照）、利用のためのコンテンツ選択を目的としたナビゲーション機能（後述する図１７参照））
（４）決済サーバ２２２との間でコンテンツ購入に関わる決済を行うための決済クライアント機能（課金処理部２０６の制御機能含む。後述する図１１のステップＳ４とＳ５の処理参照）
（５）DRM(Digital Right Management)処理の制御機能（DRM処理部２０５の制御機能含む。後述する図１５参照）
（６）コンテンツサーバ２２５から配信されるコンテンツのダウンロード制御機能（ダウンロード処理部２０７の制御機能含む。後述する図１８参照）
（７）コンテンツ再生部２０４の起動（コンテンツ選択後の処理であって、後述する図１１のステップＳ９の処理参照）
（８）ドライブ１６４等を介した外部メディア（リムーバブル記録媒体１３１等）へのコンテンツの移動の指示
（９）クライアント１０３全体のシステム制御
（１０）タイマー制御及びこれに基づく通電制御

なお、上述した（１）乃至（１０）で示される機能のそれぞれは、クライアント１０３に予め備えられていることもあるし（一般的に、（３）を除く機能は予め備えられていることが多い）、後から得られることもある。即ち、後者については、リムーバブル記録媒体１３１がドライブ１６４に装着され、そのリムーバブル記録媒体１３１に記録されている、（３）の機能を少なくとも有するナビゲーションプログラム２０３−Ａがインストールされた結果として、（３）の機能が追加されることになる。

勿論、ナビゲーションプログラム２０３−Ａは、（３）の機能以外にも他の機能、例えば、（４）乃至（７）等の機能を有していることもあり、クライアント１０３にこれらの機能が予め備えられていなければ、ナビゲーションプログラム２０３−Ａがインストールされることで、これらの機能が追加されることになる。

また、クライアントアプリケーション２０３は、ブラウンジング機能を有することもある。ブラウジング機能とは、例えば、HTML(Hyper Text Markup Language)文書（CSS(Cascading Style Sheets)を含む）の呈示機能と、HTMLに含まれるスクリプトの実行機能を含む。また、同様に、BML(Broadcast Markup Language)文書（CSSを含む）の呈示機能と、BMLに含まれるスクリプトの実行機能含む。この他、コンテントガード社のXrML(eXtensible rights Markup Language)に対応する機能を含むこともできる。ただし、ブラウジング機能は、クライアントアプリケーション２０３にとって必須な機能ではなく、ブラウジング機能を有するブラウザがクライアントに別途設けられることもある（図３８参照）。

このように、クライアントアプリケーション２０３は、クライアント１０３の制御の最上位に位置し、クライアント１０３をコンテンツ配信端末として機能させるための、ユーザインタフェースの全般と、ナビゲーションから視聴までのシナリオを設定するソフトウエアである。

このようなクライアントアプリケーション２０３に対して、コンテンツ再生部２０４、DRM処理部２０５、課金処理部２０６、および、ダウンロード処理部２０７等は、例えば、クライアントアプリケーション２０３に対するヘルパーアプリケーションソフトウエアとして構成される。

ただし、コンテンツ再生部２０４、DRM処理部２０５、課金処理部２０６、および、ダウンロード処理部２０７等は、ハードウエア等の他の形態で構成してもよい。

コンテンツ再生部２０４は、例えば、マイクロソフト社のメディアプレーヤ（商標）に代表されるソフトウエアにより構成され、コンテンツの再生等を制御し、実行する。コンテンツ再生部２０４はまた、マークアップ言語処理以外のクライアントアプリケーション２０３に組み込まれている各種の制御を実行することもある。

DRM(Digital Right Management)処理部２０５は、サーバ１０１を構成するDRMサーバ２２４と通信し、コンテンツに関するライセンスを取得し、クライアント１０３内において、これを管理する。なお、DRM処理部２０５は、暗号化されているデータを復号するキーKc（図示せず）をコンテンツ再生部２０４に供給するので、キーKcをセキュアに管理するためには、例えば、コンテンツ再生部２０４と一体化される。

課金処理部２０６は、電子マネー、プリペイドなどの方式に基づいて、課金処理を行う。

ダウンロード処理部２０７は、ダウンロード配信において、コンテンツサーバ２２５からファイル形式で配信されるコンテンツをダウンロードし、コンテンツ記憶部２０８に記憶させる処理を行う。即ち、コンテンツ記憶部２０８は、例えば、補助記憶部１６０（図６）のハードディスク（一領域）などで構成され、サーバ１０１のコンテンツサーバ２２５から提供されるコンテンツを記憶する。

クライアントメタデータデータベース２０９は、サーバ１０１のメタデータデータベース２２３からネットワーク１０２を介して通信されてくるメタデータを保持したり、ドライブ１６４に装着されたリムーバブル記録媒体１３１から読み出されたメタデータを保持する。

なお、上述したように、リムーバブル記録媒体１３１には、これらのヘルパーアプリケーション（コンテンツ再生部２０４乃至ダウンロード処理部２０７等）の処理のうちの少なくとも一部の処理を実行するために必要な情報（コマンドやファイル）が記録されていることもある。

次に、サーバ１０１に着目すると、サーバ１０１は、図８の例では、ショップサーバ２２１、決済サーバ２２２、メタデータデータベース２２３、DRMサーバ２２４、およびコンテンツサーバ２２５により構成されている。

サーバ１０１の各部は、クライアント１０３の各部と、図８に示されるように、相互に情報を授受する。

ショップサーバ２２１は、サービスプロバイダのユーザ（クライアント１０３の保有者）に対する窓口となるサーバ機能を有している。即ち、このサーバ機能として、例えば、コンテンツ購入に伴う決済処理機能（決済サーバ２２２との通信機能含む）、決済処理後のライセンス発行手続き処理機能（DRMサーバ２２４との通信機能含む）、および、ライセンス再発行やコンテンツ再ダウンロードなどのユーティリティの提供機能等が含まれる。

なお、一般的にはさらに、サーバ機能として、コンテンツ選択のために必要な検索、プロモーション、内容説明などのナビゲーションシナリオをHTML文章またはBML文書としてクライアント１０３に提供する機能も含まれていることが多い。ただし、本実施の形態においては、この機能は必須ではない。クライアント１０３側のクライアントアプリケーション２０３が、この機能に対応する機能、即ち、自身内部（クライアントメタデータデータベース２０９）に蓄積されたメタデータを利用するコンテンツナビゲーション機能を有しているからである。

決済サーバ２２２は、クライアント１０３の課金処理部２０６等と通信し、決済処理を行う。決済サーバ２２２は、ショップサーバ２２１からの決済処理依頼に基づいて、決済処理を行い、その決済結果をショップサーバ２２１に出力する。

メタデータデータベース２２３は、クライアントアプリケーション２０３からの定期的なメタデータ取得依頼に基づいて、記憶しているメタデータを読み出し、ネットワーク１０２を介して、クライアント１０３のクライアントメタデータデータベース２０９に供給し、記憶させる。

また、メタデータデータベース２２３は、サーバ１０１の管理者等の指示に基づいて、記憶しているメタデータをリムーバブル記録媒体１３１に記憶させる。即ち、サーバ１０１は、メタデータを予め記録したリムーバブル記録媒体１３１を製造する。このリムーバブル記録媒体１３１がクライアント１０３のドライブ１６４に装着されると、そのリムーバブル記録媒体１３１に記憶されたメタデータが読み出され、クライアントメタデータデータベース２０９に記憶される。

なお、リムーバブル記録媒体１３１には、図８に示されるように、クライアントアプリケーション（ナビゲーションプログラム）２０３−Ａ、コンテンツサーバ２２５から供給されるコンテンツの一部分（後述する図９のstartup fileやDownload.xml）、および、その他上述した各種情報（図８には図示せず）が必要に応じて記録される。

さらに、メタデータデータベース２２３は、ショップサーバ２２１からのメタデータ検索依頼に基づいて、検索して得られたメタデータをショップサーバ２２１に供給する。

DRMサーバ２２４は、ショップサーバ２２１からのライセンス発行許可要請に基づいて、クライアント１０３のDRM処理部２０５と通信し、DRM処理を実行する。このDRM処理には、ユーザがライセンスを有する適正なユーザであるのか否かの認証処理、暗号化されているデータを復号するのに必要なキーKcの付与、取得処理、その他の著作権管理に必要な処理が含まれる。正しいDRM処理が実行できたとき、DRMサーバ２２４は、コンテンツサーバ２２５にコンテンツを暗号化するのに必要なキーKcを供給する。また、DRMサーバ２２４は、正しいDRM処理が実行できたとき、クライアント１０３のDRM処理部２０５に、対応するキーKcを供給する。

コンテンツサーバ２２５は、DRMサーバ２２４より供給されたキーKcを用いて、コンテンツデータを暗号化し、コンテンツ再生部２０４にストリーミング配信するか、または、ダウンロードのファイルとしてコンテンツ記憶部２０８に配信し、記憶させる。

また、ここでは、後述する図９に示されるように、startup fileやDownload.xml等のコンテンツ制御情報もコンテンツの一部である（コンテンツに含まれる）とされており、コンテンツサーバ２２５は、このようなコンテンツ制御情報（コンテンツ）をクライアントアプリケーション２０３に送信したり、或いは、上述したように、リムーバブル記録媒体１３１に記憶させる。

なお、図８の例では、サーバ１０１を複数のサーバ（複数台の情報処理装置）で構成するようにしたが、１つのサーバ（１台の情報処理装置）で構成することも、もちろん可能である。

図９は、決済、DRM処理、および再生に関する各種の情報の関係を表している。同図に示されるように、機器IDとユーザID(User ID)は、１対１に対応している。機器IDは、クライアント１０３にそれぞれ割り当てられたIDであり、ユーザIDは、そのクライアント１０３を使用するユーザに割り当てられたIDである。これらのIDにより、クライアント１０３やユーザが個々に識別される。

所定のユーザIDが割り当てられたユーザは、サーバ１０１の管理者との間で、商品としてのパッケージを購入する契約を行う。具体的には、ユーザは、サーバ１０１から提供されるコンテンツ（番組等）の中から所望のコンテンツをパッケージ(Package)として購入する。このパッケージには、パッケージメタデータ(Package Meta data)が１対１に対応している。

各パッケージには、１以上のコンテンツが対応付けられている。１つのコンテンツは、コンテンツ(Contents)本体、ダウンロード用の管理情報ファイルとしてのDownload.xml、およびスタートアップファイル(startup file)により構成される。コンテンツ本体は、例えば、コンテンツが番組である場合、その番組の内容を表すコンテンツデータの本体である。

管理情報ファイルとしてのDownload.xmlは、そのコンテンツがダウンロード用のコンテンツである場合に用意されるものであり、その中には、ディレクトリ、ファイル名等が記述されている。そのディレクトリに記述されている全てのファイルが受信されたとき、ダウンロードが完了したことになる。

startup fileは、そのコンテンツがダウンロード配信用のデータであるのか、ストリーミング配信用のデータであるのかといったことを表す配信タイプに関する情報を含んでいる。即ち、startup fileは、そのコンテンツ内で最初に実行される制御情報であって、その内容に基づいて、Contents本体等を起動する（遷移する）。

ところで、上述したように（図８の白抜き矢印で示されるように）、このようなDownload.xmlやstartup fileといったコンテンツの一部分（Contents本体等の制御情報）を、対応するコンテンツのメタデータと共にリムーバブル記録媒体１３１（図８）に記録させることができる。

これにより、クライアントアプリケーション２０３（図８）は、後述するように、これらの情報（コンテンツの制御情報等）を取得するための通信をサーバ１０１と行う必要が無くなり、その結果、サーバ１０１との通信量を削減することができる。

さらに、メタデータと、ダウンロード制御ファイル等とを組み合わせて使うことにより、リムーバブル記録媒体１３１自体の付加価値を新たに創造することもできる。

例えば、所定のサービスを受けるために必要なファイル情報（Download.xml等）を、リムーバブル記録媒体１３１の特定の領域に埋め込むことにより、パーソナルコンピュータのようなWebアクセスの操作や端末としての機能（キーボード入力）等が簡略化できた状態で（即ち、ユーザにとっては、パーソナルコンピュータの操作よりも容易な操作を行うだけで）、その制御ファイル（Download.xml等）に従った処理が実行され、その結果、必要なデータファイル（Contents本体等）一式のダウンロードが可能になる。

ところで、コンテンツには、コンテンツID(Contents ID)が１対１に対応する。コンテンツは、このコンテンツIDにより識別される。コンテンツIDには、コンテンツメタデータ(Contents Metadata)がさらに１対１に対応する。コンテンツメタデータは、図１０に示されるように、コンテンツID(Contents_id)、タイトル名(title名)、ジャンル、番組説明といった情報を含んでいる。

１つのコンテンツIDには、ｎ個（ｎは１以上の整数）のライセンスID（LicenseID）が対応付けられる。同様に、１つのコンテンツメタデータには、ｎ個のライセンスメタデータ(License Metadata)が対応付けられる。

ライセンスIDは、１対１に対応付けられているライセンスを識別する。各ライセンスは、ライセンスID、使用ルール(Usage Rule)、およびコンテンツ(Contents)鍵束により構成される。このコンテンツ鍵束（上述したキーKcに対応する）は、そのライセンスが対象とするコンテンツを復号するのに必要な任意の数のキー（鍵）を含む鍵束であり、コンテンツIDと１対１に対応している。

ライセンスIDには、ライセンスメタデータが１対１に対応する。ライセンスメタデータには、図１０に示されるように、ライセンスID(License_ID)、コンテンツID(Contents_id)、コンテンツURL（ContentsURL(Uniform Resource Locator)）、ライセンスURL（LicenseURL）、配信タイプ、コンテンツタイトル名（Contents title名）、使用規則のテキスト(Usage１Rule text)などが含まれる。

ライセンスメタデータとコンテンツメタデータは、そこに含まれるコンテンツIDにより、ｎ対１に対応付けられる。

ライセンスメタデータのコンテンツURLは、コンテンツを得る場合のアクセス先を表す。ライセンスURLは、ライセンスを得る場合のアクセス先を表す。配信タイプは、そのライセンスが対象とするコンテンツが、ストリーミング配信されるものであるのか、ダウンロードファイルとして配信されるものであるのかを表す。

パッケージは、ライセンスIDとｍ対ｎ（ｍはｎと同様、１以上の整数）に対応付けられる。同様に、パッケージメタデータは、ライセンスメタデータとｍ対ｎに対応付けられる。

パッケージメタデータは、図１０に示されるように、パッケージID(Package ID)、ショップサイトURL(Shop Site URL)、パッケージ(Package)利用期間、パッケージ(Package)タイプ、パッケージ(Package)情報、およびライセンスID（License id）リストにより構成される。

パッケージIDは、パッケージを識別する情報である。ショップサイトURLは、そのパッケージを得るためのショップサイトのアクセス先を表す。パッケージ利用期間は、そのパッケージを利用することが可能な期間を表す。

パッケージタイプは、そのパッケージがパック(Pack)であるのか、またはサブスクリプション(Subscription)であるのかを表す。あるいは、また、パッケージタイプは、マルチキャスト(Multicast)であるのか、そうでないのかを表す。Packは、予め定められている所定の任意の数の番組が含まれるタイプのパッケージであることを表す。Subscriptionは、例えば、予め定めされた一定の日数に渡って、予め定められたチャンネルの番組を視聴できるタイプであることを表す。Multicastは、そのパッケージが有料または無料で不特定多数のユーザに提供されるタイプであることを表す。

パッケージ情報は、そのパッケージの名称と料金に関する情報を含む。ライセンスIDリストは、そのパッケージに含まれるライセンスのライセンスIDを記述する。

パッケージメタデータは、そこに記述されているライセンスIDに対応するライセンスメタデータに対応することになる。

このように、メタデータには、パッケージメタデータ、ライセンスメタデータ、および、コンテンツメタデータと言った３種類のメタデータが少なくとも存在し、これらの３種類のメタデータが、図８のメタデータデータベース２２３に記憶されており、必要に応じて、クライアント１０３のクライアントメタデータデータベース２０９に転送される（ネットワーク１０２経由とリムーバブル記録媒体１３１経由とのいずれも含む）。

なお、メタデータの詳細については、図１８以降の図面を参照して後述する。

次に、図１１のフローチャートを参照して、クライアント１０３の処理（サーバ１０１上のコンテンツを取得する場合の処理）について説明する。

はじめに、ステップＳ１において、クライアント１０３は、コンテンツの取得に必要なメタデータを収集し、クライアントメタデータデータベース２０９に記憶させる。

このメタデータの収集方法には、上述したように、ネットワーク１０２を介する定期的な通信による収集方法と、リムーバブル記録媒体１３１を介する収集方法との２種類が存在する。

これらの２種類の収集方法のうちの後者の収集方法に対応するステップＳ１の処理の詳細例が、図１２のフローチャートに示されている。そこで、以下、図１２のフローチャートを参照して、ステップＳ１の処理の詳細例について説明する。

なお、以下、このようなステップＳ１の処理を、「メタデータ事前取得処理」と称する。

図１２のステップＳ２１において、図６のクライアント１０３のCPU１５７は、ドライブ１６４にリムーバブル記録媒体１３１が装着されたか否かを判定する。

ステップＳ２１において、リムーバブル記録媒体１３１がまだ装着されていないと判定された場合、処理はステップＳ２１に戻され、リムーバブル記録媒体１３１が装着されたか否かが再度判定される。即ち、CPU１５７は、ドライブ１６４の装着状態を常時監視している。

例えば、ユーザが所定のリムーバブル記録媒体１３１をドライブ１６４に装着させると、CPU１５７は、ステップＳ２１において、リムーバブル記録媒体１３１が装着されたと判定し、ステップＳ２２において、そのリムーバブル記録媒体１３１にメタデータが記録されているか否かを判定する。

リムーバブル記録媒体１３１にメタデータが記録されていない場合（ステップＳ２２において、メタデータが記録されていないと判定された場合）、「メタデータ事前取得処理」は終了となる。ただし、リムーバブル記録媒体１３１に他の情報が記録されている場合、他の情報に対応する処理が実行されることもある。例えば、リムーバブル記録媒体１３１に、販売用のコンテンツ（映画等）が含まれている場合、そのコンテンツの再生処理が実行されることもある。

これに対して、リムーバブル記録媒体１３１にメタデータが記録されている場合（ステップＳ２２において、メタデータが記録されていると判定した場合）、CPU１５７は、ステップＳ２３において、リムーバブル記録媒体１３１からメタデータを読み出し、図８のクライアントメタデータデータベース２０９（補助記憶部１６０等）に記憶させる。

なお、ステップＳ２２の判定処理の判定方法は、特に限定されず、例えば、上述したように、特定のファイル名（メタデータ専用のファイル名）のデータが記録されているか否か、或いは、特定の領域（メタデータ専用の領域）にデータが記録されているか否か等に基づいて、ステップＳ２２の判定処理を行うこともできる。

ただし、ここでは、例えば、リムーバブル記録媒体１３１の特定な領域にメタデータを取得するためのファイルが記録されているか否かに基づいて、ステップＳ２２の判定処理を行うとする。即ち、ムーバブル記録媒体１３１の特定な領域にメタデータを取得するためのファイルが記録されている場合、CPU１５７は、ステップＳ２２において、メタデータが記録されていると判定し、ステップＳ２３において、そのファイルを先に読み出し、そのファイルの内容（コマンド等）に基づいてメタデータを読み出し、クライアントメタデータデータベース２０９に記憶させる。

ステップＳ２４において、CPU１５７は、そのメタデータに対応するナビゲーションプログラム２０３−Ａ（図８）は既にインストール済みであるか否かを判定する。即ち、CPU１５７は、クライアントアプリケーション２０３に、そのメタデータに対応するコンテンツナビゲーション機能が含まれているか否かを判定する。

ステップＳ２４において、そのメタデータに対応するナビゲーションプログラム２０３−Ａは既にインストール済みである（クライアントアプリケーション２０３に対応する機能が含まれている）と判定した場合、CPU１５７は、ステップＳ２８において、クライアントアプリケーション２０３を起動させる。これにより、「メタデータ事前取得処理」は終了となる。

なお、リムーバブル記録媒体１３１に、ナビゲーションプログラム２０３−Ａを起動するためのファイル情報やコマンドが記録されている場合がある。このような場合、CPU１５７は、このファイル情報やコマンドに従って、クライアントアプリケーション２０３を起動させる。

これに対して、ステップＳ２４において、そのメタデータに対応するナビゲーションプログラム２０３−Ａはまだインストールされていない（クライアントアプリケーション２０３に対応する機能が含まれていない）と判定した場合、CPU１５７は、ステップＳ２５において、ナビゲーションプログラム２０３−Ａがリムーバブル記録媒体１３１に記録されているか否かを判定する。

ステップＳ２５において、ナビゲーションプログラム２０３−Ａがリムーバブル記録媒体１３１に記録されていないと判定した場合、CPU１５７は、所定のエラー処理を実行し、「メタデータ事前取得処理」を終了させる。なお、エラー処理の形態については、特に限定されず、例えば、記録媒体１３１に記録されていたメタデータ（ステップＳ２３の処理でクライアントメタデータデータベース２０９に記録されたメタデータ）に対応するコンテンツの取得が不可能であることのメッセージを表示装置（呈示部）１７２に表示させてもよい。

これに対して、ステップＳ２５において、ナビゲーションプログラム２０３−Ａがリムーバブル記録媒体１３１に記録されていると判定した場合、CPU１５７は、ステップＳ２７において、そのナビゲーションプログラム２０３−Ａを補助記憶部１６０等にインストールする。即ち、CPU１５７は、ナビゲーションプログラム２０３−Ａが有する機能（リムーバブル記録媒体１３１に記録されているメタデータを利用するコンテンツナビゲーション機能）を、クライアントアプリケーション２０３の機能に追加する。

なお、リムーバブル記録媒体１３１に、ナビゲーションプログラム２０３−Ａをインストールするためのファイル情報やコマンドが記録されている場合がある。このような場合、CPU１５７は、このファイル情報やコマンドに従って、ナビゲーションプログラム２０３−Ａを補助記憶部１６０等にインストールする。

そして、ステップＳ２８において、CPU１５７は、ステップＳ２７の処理で機能が追加されたクライアントアプリケーション２０３を起動させる。これにより、「メタデータ事前取得処理」が終了となる。

なお、上述したように、リムーバブル記録媒体１３１に、ナビゲーションプログラム２０３−Ａを起動するためのファイル情報やコマンドが記録されている場合がある。このような場合、CPU１５７は、このファイル情報やコマンドに従って、クライアントアプリケーション２０３を起動させる。

図１１に戻り、このようにして、クライアントアプリケーション２０３が起動されると、ステップＳ２において、クライアント１０３は、このクライアントアプリケーション２０３等を利用して、リムーバブル記録媒体１３１に記録されていたメタデータ（図１２のステップＳ２３の処理でクライアントメタデータデータベース２０９に記録されたメタデータ）に対応する１以上のコンテンツの中から、購入希望のコンテンツを選択するまでのユーザ操作をナビゲートする処理を実行する。即ち、クライアント１０３は、コンテンツナビゲーション機能に対応する処理を実行する。

なお、以下、このようなステップＳ２の処理を、「購入コンテンツナビゲーション処理」と称する。この「購入コンテンツナビゲーション処理」の詳細例が図１３のアローチャートに示されている。そこで、図１３のアローチャートを参照して、「購入コンテンツナビゲーション処理」の詳細例について説明する。

なお、図１３において、ヘルパーアプリケーションは、コンテンツ再生部２０４、DRM処理部２０５、課金処理部２０６、および、ダウンロード処理部２０７（図８）により構成される。また、ユーザインタフェースは、入力部１６２と呈示部１７２と（図８）により構成される。このことは、後述する他のアローチャート（図１５、図１６、および図１７）においても同様とされる。

ステップＳ４１において、クライアントアプリケーション２０３は、例えば、メタデータ取得要求を発行することで、クライアントメタデータデータベース２０９に既に記憶されている（図１２のステップＳ２３の処理で記憶された）メタデータの読み出しを指令する。

なお、リムーバブル記録媒体１３１に、メタデータを取得するためのファイル情報やコマンドが記録されている場合がある。このような場合、CPU１５７は、このファイル情報やコマンドに従って、メタデータ取得要求をクライアントメタデータデータベース２０９に対して発行する。

ステップＳ５１において、クライアントメタデータデータベース２０９は、クライアントアプリケーション２０３からのメタデータ取得要求を取得すると、予め記憶されているメタデータ群を読み出し、クライアントアプリケーション２０３に送信する。

クライアントアプリケーション２０３は、ステップＳ４２において、そのメタデータ群を受信すると、そこに記述されているコンテンツ（番組）のタイトル名等を読み出し、ステップＳ４３において、例えば、図１４に示されるようなコンテンツのリスト（データ）を生成し、ユーザインタフェースとしての呈示部１７２に供給する。ステップＳ６１において、呈示部１７２は、このコンテンツのリスト（データ）を画像として表示する。即ち、コンテンツのリストは、例えば、図１４に示されるように呈示される。

ユーザは、このリストの表示を見て、リモートコマンダ１８３の方向ボタン１８５Ｕ乃至１８５Ｒと決定ボタン１８４を適宜操作することで、所定のタイトル名のコンテンツ（番組）を選択し、図１４中左下に表示されている「購入ボタン」をクリックする（「購入ボタン」にカーソル等を配置させ、決定ボタン１８４を押下操作する）。

すると、ステップＳ６２において、入力部１６２は、このユーザの操作（購入コンテンツ選択操作）に対応する選択信号（選択された番組を指定する情報）を、クライアントアプリケーション２０３に供給する。

クライアントアプリケーション２０３は、ステップＳ６３において、入力部１６２からのその選択信号を受信すると、ユーザにより選択されたコンテンツを、購入対象のコンテンツ（以下、購入コンテンツと称する）として決定する。

これにより、「購入コンテンツナビゲーション処理」は終了となる。

図１１に戻り、このようにして、ステップＳ２の「購入コンテンツナビゲーション処理」が終了されると、クライアントアプリケーション２０３は、ステップＳ３において、課金処理部２０６を制御して、購入コンテンツに対する決済をサーバ１０１に依頼する。

即ち、クライアントアプリケーション２０３は、例えば、メタデータからユーザIDやパッケージIDを認識し、ショップサーバ２２１に対して、ユーザIDによるログイン入力を行い、パッケージIDを通知して決済手段の指定も含めて購入要求を行う。

そして、ステップＳ４において、クライアントアプリケーション２０３は、決済が完了したか否かを判定する。ステップＳ４において、決済が完了していないと判定された場合、処理はステップＳ４に戻され、決済が完了したか否かが再度判定される。即ち、クライアントアプリケーション２０３は、決済が完了するまで、その処理を待機する。

このとき、サーバ１０１側では、次のような処理が実行されている。即ち、ショップサーバ２２１は、指定された決済手段に対応する決済サーバ２２２に接続して、決済処理を行う。その決済処理が正常に完了した場合には、ショップサーバ２２１は、リンクする顧客データベース（図示せず）に購入者（いまの場合、クライアント１０３を利用するユーザ）のユーザIDに対応して購入されたパッケージIDを登録する。

続けて、ショップサーバ２２１は、顧客データベースからユーザIDに対応する機器IDリストを取得し、さらにメタデータデータベース２２３からパッケージIDに対応するライセンスIDリストを取得し、これらの（複数の）機器IDと（複数の）ライセンスIDのすべての組み合わせのリストをDRMサーバ２２４に送り、DRMサーバ２２４はこれを保持する。

ショップサーバ２２１は、一連の決済処理が完了したら、そのことをクライアントアプリケーション２０３に通知する。

すると、クライアントアプリケーション２０３は、決済処理の完了を呈示部１７２（ユーザインタフェース）により視聴者に呈示すると共に、購入対象のパッケージメタデータのステータスを購入済として更新する。

以上の処理が完了した時点で、クライアントアプリケーション２０３は、ステップＳ４において、決済が完了したと判定し、ステップＳ５において、購入コンテンツのライセンスを取得するための処理を実行する。

なお、以下、ステップＳ５の処理を「ライセンス取得処理」と称する。この「ライセンス取得処理」の詳細例が図１５のアローチャートに示されている。そこで、図１５のアローチャートを参照して、「ライセンス取得処理」の詳細例について説明する。

ステップＳ８１において、クライアントアプリケーション２０３は、購入コンテンツに対応するstartup fileの取得をサーバ１０１に要求する。このstartup file取得要求には、購買コンテンツを識別するコンテンツIDが含まれている。なお、このとき、クライアントアプリケーション２０３は、コンテンツIDと、サーバ１０１のアクセス先（例えば、コンテンツサーバ２２５上の所定のURL）等を、クライアントメタデータデータベース２０９に記憶されたメタデータから認識する。

サーバ１０１（コンテンツサーバ２２５）は、ステップＳ９１において、指定されたコンテンツIDに対応するコンテンツ（購買コンテンツ）のstartup fileを読み出し、クライアントアプリケーション２０３に送信する。

クライアントアプリケーション２０３は、ステップＳ８２において、このstartup fileを受信する。

なお、購入コンテンツによっては、その構成要素にstartup fileを含まないこともあり、そのような場合、クライアントアプリケーション２０３のステップＳ８１とＳ８２、および、後述するステップＳ８３の処理（それらの処理に伴うサーバ１０１側のステップＳ９１の処理）は省略される。

また、後述するように、１つのコンテンツ、即ち、上述した図９に示される、Contents本体、startup file、および、Download.xmlのそれぞれは、必ずしも同一の場所（いまの場合、コンテンツサーバ２２５）に保存される必要は無い。即ち、上述したように、通信量の削減を目的として、メタデータに加えて、そのメタデータに対応するコンテンツのstartup fileやDownload.xmlをリムーバブル記録媒体１３１に記録させることも可能である。このような場合、ステップＳ８１の処理におけるstartup file取得要求は、サーバ１０１に対してではなく、リムーバブル記録媒体１３１に対して行われる。即ち、ステップＳ８２において、クライアントアプリケーション２０３は、リムーバブル記録媒体１３１より読み出されたstartup fileを取得する。

次に、ステップＳ８３において、クライアントアプリケーション２０３は、startup fileに記述された処理の実行を開始する。

このステップＳ８３の処理の内容は、startup fileの記述内容によって異なることになる。ただし、ここでは、説明の簡略上、startup fileには、ライセンスの取得（確認）が指示されており、ステップＳ８３において、ライセンスの取得の処理が開始されるとする。具体的には、例えば、ここでは、「DRM処理に必要となる情報を記載したファイル（以下、DRM情報参照ファイルと称する）への参照」がstartup fileに記述されており、クライアントアプリケーション２０３は、ステップＳ８３において、そのstartup fileの記述に従って、DRM情報参照ファイルをサーバ１０１から取得するとする。なお、ここでは、このDRM情報参照ファイルもコンテンツの一部として取り扱う。

この場合、ステップＳ８４において、クライアントアプリケーション２０３は、DRM処理部２０５に対してライセンス(License)取得（確認）を依頼する。即ち、クライアントアプリケーション２０３は、先の決済処理により権利を得たライセンスID（リスト）とDRMサーバURLを引数にDRM処理部２０５に対してライセンス取得（確認）指示を行う。

DRM処理部２０５は、そのライセンス取得依頼を受信すると、ステップＳ１０１において、DRMサーバ２２４にアクセスし、DRMサーバ２２４との通信によりDRM処理を実行する。即ち、サーバ１０１（DRMサーバ２２４）側から見ると、ステップＳ９２において、クライアント１０３に対するDRM処理が実行される。

詳細には、DRM処理部２０５は、DRMサーバ２２４に対して、規定されたセッションにてライセンスIDを送ってライセンス取得を試みる。DRMサーバ２２４は、このセッションの初期に端末の機器（クライアント１０３）を機器IDとして認識しているので、ライセンスIDが送られてきた時点で、機器IDに対してライセンスIDが許可されているか否かをチェックすることにより、正当なライセンス取得要求か否かを判断する。そして、DRMサーバ２２４は、そのチェックで問題がなければライセンスをDRM処理部２０５に送信する。

DRM処理部２０５は、そのライセンスを受信するとセキュアに格納して、ステップＳ１０２において、DRM処理の完了をクライアントアプリケーション２０３に通知する（DRM処理完了通知を送信する）。

即ち、DRM処理部２０５は、DRM処理完了通知として、DRMサーバ２２４からのライセンス取得の成否結果をクライアントアプリケーション２０３に送信する。なお、ライセンス取得が成功したことを示すDRM処理完了通知には、対応するコンテンツ（いまの場合、購入コンテンツ）を復号するのに必要なキーKcも含まれていることがある。

クライアントアプリケーション２０３は、ステップＳ８５において、ライセンス取得が成功したことを示すDRM処理完了通知をDRM処理部２０５より受信すると、ユーザインタフェースとしての呈示部１７２に、購入コンテンツの配信処理の準備が完了したことを示すメッセージ（データ）を提供する。即ち、呈示部１７２は、ステップＳ１１１において、そのメッセージを画像等の形態で呈示する。なお、このメッセージの呈示形態は特に限定されず、例えば、購入コンテンツの配信形態がダウンロード配信である場合、上述した図１４に示される画像のうちの右下のダウンロードボタンの色を変えたり、点滅させたりする呈示形態を取ることができる。

これにより、「ライセンス取得処理」は終了となる。

なお、クライアントアプリケーション２０３は、ステップＳ８５において、ライセンス取得が失敗したことを示すDRM処理完了通知をDRM処理部２０５より受信した場合、処理をステップＳ８４に戻し、ライセンス取得依頼を再度発行してもよいし、所定のエラーメッセージを呈示部１７２を介してユーザに呈示してもよい。

また、上述したように、コンテンツを幅広く流通させることを目的として、そのコンテンツのメタデータを記録したリムーバブル記録媒体１３１を無償で或いは安価（コンテンツの価格未満）でユーザに配布することができる。このような場合、そのコンテンツに対してライセンスがあえて設定されていないこともあり、このようなとき、ステップＳ８４以降の処理(DRM処理等)は省略可能である。

図１１に戻り、このようにして、ステップＳ５の「ライセンス取得処理」が終了されると、クライアントアプリケーション２０３は、ステップＳ６において、購入コンテンツは、ダウンロード用のコンテンツであるか否かを判定する。

例えば、先に取得された（図１５のステップＳ８２）のstartup fileにおいて、購入コンテンツがストリーミング配信であることが指定されている場合、クライアントアプリケーション２０３は、ステップＳ６において、購入コンテンツはダウンロード用のコンテンツではない（ストリーミング配信用のコンテンツである）と判定し、後述するステップＳ７の「ダウンロード処理」を実行せずに、その処理をステップＳ８に進める。

これに対して、先に取得されたstartup fileにおいて、購入コンテンツがダウンロード配信であることが指定されている場合、クライアントアプリケーション２０３は、ステップＳ６において、ダウンロード用のコンテンツであると判定し、ステップＳ７において、ダウンロード処理部２０７を制御して、購入コンテンツのコンテンツデータ(Contents本体)をダウンロードし、コンテンツ記憶部２０８に記憶させる。

なお、以下、このようなステップＳ７の処理を、「ダウンロード処理」と称する。この「ダウンロード処理」の詳細例が図１６のアローチャートに示されている。そこで、図１６のアローチャートを参照して、「ダウンロード処理」の詳細例について説明する。

ステップＳ１５１において、ユーザインタフェースとしての入力部１６２は、先に決定した購入コンテンツのダウンロードを指示する信号をクライアントアプリケーション２０３に供給する。

なお、ダウンロードを指示する信号の形態は、特に限定されず、例えば、次のような信号が可能である。即ち、例えば、上述した図１４の画像が表示されている状態で、ユーザが、リモートコマンダ１８３の方向ボタン１８５Ｕ乃至１８５Ｒを利用して、「ダウンロードボタン」にカーソル等を配置させ、決定ボタン１８４を押下操作したとき（「ダウンロードボタン」をクリックする操作をしたとき）にクライアントアプリケーション２０３に入力される信号を、ダウンロード指示の信号として利用することができる。

クライアントアプリケーション２０３は、このようなダウンロード指示を受けて、ステップＳ１６１において、購入コンテンツに対応するDownload.xml(図９)の取得をサーバ１０１（コンテンツサーバ２２５）に要求する。このDownload.xml取得要求には、購買コンテンツを識別するコンテンツIDが含まれている。このコンテンツIDはメタデータから認識される。

サーバ１０１（コンテンツサーバ２２５）は、ステップＳ１８１において、指定されたコンテンツIDに対応するコンテンツ（購買コンテンツ）のDownload.xmlを読み出し、クライアントアプリケーション２０３に送信する。

クライアントアプリケーション２０３は、ステップＳ１６２において、このDownload.xmlを受信する。

なお、上述したように、リムーバブル記録媒体１３１には、メタデータの他、そのメタデータに対応するコンテンツのstartup fileやDownload.xmlの記録も可能である。このような場合、ステップＳ１６１の処理におけるDownload.xml 取得要求は、サーバ１０１に対してではなく、リムーバブル記録媒体１３１に対して行われる。即ち、ステップＳ１６２において、クライアントアプリケーション２０３は、リムーバブル記録媒体１３１より読み出されたDownload.xmlを取得する。

次に、クライアントアプリケーション２０３は、ステップＳ１６３において、このDownload.xmlをダウンロード制御部２０７に供給することで、ダウンロードを指令する。即ち、クライアントアプリケーション２０３は、ダウンロード処理をダウンロード処理部２０７に委託する。

ダウンロード処理部２０７は、そのDownload.xmlを解析し、ダウンロード準備処理として、コンテンツ記憶部２０８の空き容量チェックなどを行い、ライセンスが取得済みであることも確認する。さらに、ダウンロード処理部２０７は、ダウンロード対象コンテンツ（購入コンテンツ）の格納場所を示すディレクトリ情報を生成しメタデータの一部としてクライアントメタデータデータベース２０９に保持させる。

そして、ステップＳ２０１において、Download.xmlに記述されたコンテンツを構成するファイル、例えば、Contents本体の取得をサーバ１０１（コンテンツサーバ２２５等のDownload.xmlに記述された場所）に要求する。

サーバ１０１は、ステップＳ１８２において、要求されたContents本体等を読み出し、クライアント１０３に送信する。

クライアント１０３のコンテンツ記憶部２０８は、ステップＳ２１１において、ダウンロード処理部２０７の制御に基づいて、サーバ１０１からネットワーク１０２を介して送信されてきたContents本体等を記憶させる。即ち、ダウンロード処理部２０７は、ステップＳ２０２において、コンテンツ記憶部２０８のコンテンツデータの記憶処理を制御する。

詳細には、ダウンロード処理部２０７は、先に取得したDownload.xml等の制御ファイルと、Download.xmlに記述されたContents本体等のファイルとを１つのコンテンツとして、コンテンツ記憶部２０８に記憶させる。即ち、ダウンロード処理部２０７は、コンテンツ記憶部２０８内に特定のディレクトリを生成した上で、その下に元のコンテンツ内のディレクトリ構造を保持しつつ、これらのコンテンツの各構成要素（Contents本体等）のそれぞれを書き込んでいく。

全てのデータをコンテンツ記憶部２０８に記憶させると、ダウンロード処理部２０７は、ステップＳ２０３において、処理の完了をクライアントアプリケーション２０３に通知する（処理完了通知を送信する）。

クライアントアプリケーション２０３は、ステップＳ１６４において、その処理完了通知をダウンロード処理部２０７より受信すると、ユーザインタフェースとしての呈示部１７２に、購入コンテンツのダウンロードが完了したことを示すメッセージ（データ）を提供する。即ち、呈示部１７２は、ステップＳ１５２において、そのメッセージを画像等の形態で呈示する。これにより、「ダウンロード処理」は終了となる。

なお、ダウンロード処理部２０７が処理を実行している最中に、クライアントアプリケーション２０３は、必要に応じて（例えば、ユーザの指示操作があった場合等に）、ダウンロードの進捗状況を呈示部１７２を介してユーザに呈示することができる。

図１１に戻り、このようにしてステップＳ７の「ダウンロード処理」が終了されるか、或いは、ステップＳ６の処理で、ダウンロード用のコンテンツではないと判定されると、クライアントアプリケーション２０３は一端その処理を待機する。或いは、クライアントアプリケーション２０３は立ち下げられる。

その後、ユーザが、購入済みのコンテンツの利用（試聴）を目的として、入力部１６２を操作してクライアントアプリケーション２０３の処理を再開させるかまたは再起動させると、ステップＳ８において、クライアント１０３は、このクライアントアプリケーション２０３等を利用して、購入済みのコンテンツの中から利用（試聴）希望のコンテンツを選択するまでのユーザの操作をナビゲートする処理を実行する。

なお、以下、このようなステップＳ８の処理を、「利用コンテンツナビゲーション処理」と称する。この「利用コンテンツナビゲーション処理」の詳細例が図１７のアローチャートに示されている。そこで、図１７のアローチャートを参照して、「利用コンテンツナビゲーション処理」の詳細例について説明する。

ユーザがコンテンツの利用を指示する目的でリモートコマンダ１８３を適宜操作すると、入力部１６２は、ステップＳ２２１において、その操作に対応する信号を、コンテンツ利用指示としてクライアントアプリケーション２０３に供給する。

クライアントアプリケーション２０３は、このコンテンツ利用指示を受けると、ステップＳ２４１において、例えば、メタデータ取得要求を発行することで、クライアントメタデータデータベース２０９に既に記憶されている（図１２のステップＳ２３の処理で記憶された）メタデータのうちの、購入済みのコンテンツに対応するメタデータの読み出しを指令する。

ステップＳ２５１において、クライアントメタデータデータベース２０９は、クライアントアプリケーション２０３からのメタデータ取得要求を取得すると、予め記憶されているメタデータ群のうちの、購入済みのコンテンツに対応するメタデータ群を読み出し、クライアントアプリケーション２０３に送信する。

クライアントアプリケーション２０３は、ステップＳ２４２において、そのメタデータ群を受信すると、そこに記述されているコンテンツ（番組）のタイトル名等を読み出し、ステップＳ２４３において、図示はしないが、購入済みのコンテンツのリスト（データ）を生成し、ユーザインタフェースとしての呈示部１７２に供給する。ステップＳ２２２において、呈示部１７２は、購入済みのコンテンツのリスト（データ）を画像として表示する。

ユーザは、このリストの表示を見て、リモートコマンダ１８３（図７）の方向ボタン１８５Ｕ乃至１８５Ｒを適宜操作することで、試聴を所望するタイトル名のコンテンツ（番組）を選択し、リモートコマンダ１８３の再生ボタン１８８を押下操作する。

すると、ステップＳ２２３において、入力部１６２は、このユーザの操作（利用コンテンツ選択操作）に対応する選択信号（選択された番組を指定する情報）を、クライアントアプリケーション２０３に供給する。

クライアントアプリケーション２０３は、ステップＳ２４４において、入力部１６２からのその選択信号を受信すると、ユーザにより選択されたコンテンツを、これからユーザが利用する（再生させる）コンテンツ（以下、利用コンテンツと称する）として決定する。

これにより、「利用コンテンツナビゲーション処理」は終了となる。

図１１に戻り、このようにして、ステップＳ８の「利用コンテンツナビゲーション処理」が終了されると、クライアントアプリケーション２０３は、プラグインにより、コンテンツ再生部２０４を起動し、利用コンテンツの呈示（再生）を指示する。

すると、コンテンツ再生部２０４は起動し、ステップＳ９において、利用コンテンツのContents本体をサーバ１０１またはコンテンツ記憶部２０８より取得し、呈示部１７２に呈示（再生）させる。

詳細には、はじめに、クライアントアプリケーション２０３は、利用コンテンツに対応するライセンスの確認をDRM処理部２０５に指示する。

DRM処理部２０５は、利用コンテンツに対応するライセンスが存在するか否かを確認することで、DRM処理を実行する。

クライアントアプリケーション２０３は、このようなDRM処理部２０５のDRM処理が正しく完了した場合には、利用コンテンツの再生をコンテンツ再生部２０４に指示する。

コンテンツ再生部２０４は、DRM処理部２０５に利用コンテンツを復号するための鍵（上述したキーKc）の取得を試みる。DRM処理部２０５は、その時点の利用条件をチェックして問題がなければ対応する鍵（キーkc）をセキュアにコンテンツ再生部２０４に転送し、コンテンツ再生部２０４内のデクリプタに設定する。

コンテンツ再生部２０４は、利用コンテンツの配信形態がストリーミング配信である場合、サーバ１０１のコンテンツサーバ２２５からストリーミング配信されてくる利用コンテンツのContents本体を、キーkcを用いて順次復号し、デコードして、呈示部１７２に供給する。

これに対して、利用コンテンツの配信形態がダウンロード配信である場合、上述したステップＳ７の「ダウンロード処理（図１６）」で、利用コンテンツのContents本体はコンテンツ記憶部２０８に既に保存されているので、コンテンツ再生部２０４は、利用コンテンツのContents本体をコンテンツ記憶部２０８より取得し、キーkcを用いて順次復号し、デコードして、呈示部１７２に供給する。

このようにして、コンテンツ再生部２０４は、ステップＳ９において、呈示部１７２による利用コンテンツの呈示を行う。

以上、本実施の形態のクライアント１０３の処理について説明した。

このように、本実施の形態のクライアント１０３の処理においては、リムーバブル記録媒体１３１からクライアントメタデータデータベース２０９に転送されたメタデータの助けを借りて、クライアント１０３側の内部処理だけで（ブラウザ等を用いる外部との通信処理を行うことなく）検索画面（上述したコンテンツリスト等）を表示させることが可能になる。

さらに、その後の通信処理においても、メタデータからコンテンツの配置場所が認識され、RTP.HTTPといった通信プロトコルでその配置場所に存在するコンテンツの伝送処理が行われるので、ウェブ画面等の呈示は一切不要となる。

さらにまた、本実施の形態のクライアント１０３は、リムーバブル記録媒体１３１に記録されたメタデータを利用することで、上述したクライアント主体型ナビゲーションが有する第３の課題と第４の課題とを解決することができる。

なお、繰り返しになるが、第３の課題とは、コンテンツの数が増大すると、それらのメタデータの全てをクライアントメタデータデータベース２０９に保持させるのは困難となるという課題である。

第４の課題とは、サーバ１０１のメタデータデータベース２２３の分散化に対する対処方法や、メタデータの定期的な取得によるクライアントメタデータデータベース２０９の更新方法等の運用方法の実現が困難であるという課題である。

次に、図１８乃至図３６を参照して、このようなクライアント１０３が利用可能なメタデータ、即ち、リムーバブル記録媒体１６１に記録可能なメタデータの詳細例について説明する。

上述した図９と図１０とを参照して説明したように、メタデータは、パッケージメタデータ(Package Meta data)、ライセンスメタデータ（Licence Meta data）、および、コンテンツメタデータ（Contents Meta data）といった３種類に区分することができるが、このようなメタデータはまた、図１８に示されるように区分することもできる。即ち、図１８は、メタデータの図１０とは異なる区分方法を説明する図である。

図１８に示されるように、パッケージメタデータのうちの、PackageID、Shop site URL、Shop function URL、販売開始や終了日時、Packageタイプ、パッケージ料金、パッケージ名、プロモーション情報、ジャンル情報、選択可能ライセンス数、および、Licence idリスト、といった情報は、コンテンツ商品のチラシや宣伝目的の情報であると言える。そこで、このようなコンテンツ商品のチラシや宣伝目的の情報を、以下、コンテンツ商品メタデータと称する。即ち、メタデータのうちの一部の情報は、コンテンツ商品メタデータに区分される。

また、パッケージメタデータのうちの、配信開始や終了日時、および、コンテンツURL、といった情報は、コンテンツ検索処理、例えば、コンテンツ選択のナビゲーション処理のための検索処理にとって有意な情報であると言える。そこで、以下、コンテンツのタイトル、その概要、そのジャンル、その場所情報、およびその時間情報等、コンテンツ検索処理にとって有意な情報を、コンテンツ検索属性メタデータと称する。即ち、メタデータのうちの一部の情報は、コンテンツ検索属性メタデータに区分される。

コンテンツ検索属性メタデータにはまた、ライセンスメタデータのうちの、コンテンツURL、配信対応、および、配信開始終了日時、並びに、コンテンツタイトル名が含まれる。さらに、コンテンツ検索属性メタデータには、コンテンツメタデータ全体も含まれる。

ライセンスメタデータのうちの、ライセンスID、コンテンツID、ライセンスURL、ライセンス有効期限、利用条件情報、および、リソース情報、といった情報は、購入したライセンス(コンテンツの視聴権利)の管理目的の情報であると言える。そこで、以下、ライセンスの管理目的の情報を、ライセンス管理メタデータと称する。即ち、メタデータのうちの一部の情報は、ライセンス管理メタデータに区分される。

このように、メタデータは、コンテンツ商品メタデータ、ライセンス管理メタデータ、および、コンテンツ検索属性メタデータといった３種類に区分することができる（ただし、パッケージメタデータのうちの、メタデータ削除日時、メタデータ更新頻度、および、付帯端末生成情報、並びに、ライセンスメタデータのうちの付帯端末生成情報は除く）。

なお、コンテンツ商品メタデータ、ライセンス管理メタデータ、および、コンテンツ検索属性メタデータのそれぞれの間のシンボルは、図１９に示される規則に従って描画されている。例えば、図１８に示される、コンテンツ商品メタデータとライセンス管理メタデータとの間に描画されたシンボルは、図１９中一番上のシンボルであって、１つのコンテンツ商品メタデータから、ゼロ以上のライセンス管理メタデータが関連付けられることを示している。図１９に示されるこれらのシンボルは、後述する図２０、図２４、および、図３０においても使用されている。

ところで、コンテンツナビゲーション機能にとっては、上述したように、このように区分されたメタデータのうちのコンテンツ検索属性メタデータが特に重要である。

そこで、以下、コンテンツ検索属性メタデータの詳細についてさらに説明する。

図１８に示されるように、コンテンツ検索属性メタデータはさらに、コンテンツ記述メタデータ、インスタンス記述メタデータ、および、セグメント記述メタデータの３つの種類に分類される。

コンテンツ記述メタデータとは、コンテンツのリリースや放送形態に依存しないコンテンツに関する一般的な情報を指す。例えば、コンテンツ記述メタデータには、コンテンツのタイトルや内容のテキスト記述、およびジャンルなどの情報が含まれる。一般的には、コンテンツ制作者が、コンテンツのリリース前にコンテンツ記述メタデータを生成する。

インスタンス記述メタデータとは、コンテンツの特定のインスタンスを記述する情報を指す。例えば、インスタンス記述メタデータには、コンテンツのインスタンスの位置(放送スケジュールやアドレス)や配信メディアに依存するパラメータ（ビデオフォーマット等）の情報が含まれる。インスタンス記述メタデータは、コンテンツがリリースまたは放送されるときに、リリースまたは放送サービス事業者等により与えられる。

セグメント記述メタデータとは、コンテンツのストリームを、時間で区切られたセグメントとして検索や操作するための情報を指す。このセグメント記述メタデータは、ハイライトシーンを抽出するようなノンリニア視聴を実現するために利用される。

以下、コンテンツ記述メタデータ、インスタンス記述メタデータ、および、セグメント記述メタデータのそれぞれの詳細について、その順番に個別に説明していく。

はじめに、コンテンツ記述メタデータについて説明する。

図２０は、コンテンツ記述メタデータの構成例を示している。

図２０に示されるように、コンテンツ記述メタデータは、ProgramGroup(プログラムグループ)、Program(プログラム)、および、ProgramReview(プログラムレビュー)から構成される。

Program(プログラム)とは、番組に対応するコンテンツの単位であるProgram(プログラム)についての情報を指す。即ち、Program(プログラム)は、タイトルや概要等から番組を検索するときに必要な情報である。具体的には、例えば、Program(プログラム)には、図２１に示されるような情報が含まれる。

図２１において、ProgramId(プログラム識別子)には、このProgram(プログラム)のCRID（Content Reference Identifier）が記述される。OtherIdentifier(CRID以外のコンテンツ識別子)には、このProgram(プログラム)を識別するために、CRIDの他に使用することができる識別子が記述される。AVAttributes(オーディオビジュアル属性)には、メディア属性（例えば、符号化方式やパラメータ等）が記述される。

MemberOf(プログラムグループへの参照)には、このProgram(プログラム)が含まれるProgramGroup(プログラムグループ)のCRIDのリストが記述される。なお、ProgramGroup(プログラムグループ)については後述する。このMemberOf(プログラムグループへの参照)により、どのような理由により派生したProgram(プログラム)なのか（例えば言語の違い等）を示すタイプの定義が可能となる。シリーズ中のプログラムのエピソード番号を指定するために、MemberOf(プログラムグループへの参照)として、それぞれのProgramGroup(プログラムグループ)内で一意なインデックス値の付与が可能とされている。

BasicContentsDescription(基本コンテンツ記述)には、図２１に示されるような、各種の基本的な内容が記述される。

即ち、Title(タイトル)には、このProgram(プログラム)のタイトルが記述される。なお、複数のタイトルの記述が可能とされている。MediaTitle(メディアタイトル)には、「タイトル」として使用可能な画像等を示す情報が記述される。ShortTitle(ショートタイトル)には、表示の際に参考とするタイトルの短形式版が記述される。

Synopsis(概要)には、このProgram(プログラム)の内容の説明が記述される。

Language(言語)には、このProgram(プログラム)を構成する音声の言語が記述される。CaptionLanguage(キャプション言語)には、このProgram(プログラム)におけるキャプション情報の言語が記述される。SignLanguage(手話言語)には、このProgram(プログラム)において指定される手話言語が記述される。

CreditsList(クレジット一覧)には、このProgram(プログラム)で出演している俳優や、このProgram(プログラム)の監督などのクレジット一覧が記述される。

PromotionalInformation(プロモーション情報)には、販売促進目的で利用される内容が記述される。

Keywords(キーワード)には、このProgram(プログラム)の特徴を示すキーワードの一覧が記述される。なお、キーワードとは、一つの単語か、もしくは複数の単語からなる完全なフレーズを指す。

Genre(ジャンル)には、このProgram(プログラム)が属するジャンルが記述される。なお、Genre(ジャンル)に記述可能なジャンルとして、例えば、図２２に示されるような階層構造の各ジャンルが存在する。即ち、第１層（最上位の層）として、例えば、NON-FICTUIN（ノンフィクション）、SPORTS（スポーツ）、MUSIC AND DANCE（音楽/ダンス）、LEISURE/HOBBY（レジャー/趣味）、FICTION（フィクション）、および、AMUSEMENT（アミューズメント）等の記述が可能とされている。

さらに、NON-FICTUIN（ノンフィクション）の下層（第２層）として、NEWS（ニュース）等の記述が、そのNEWS（ニュース）のさらに下層（第３層）として、Daily News（毎日のニュース）やSpecial edistion（特別ニュース番組）等の記述が、それぞれ可能とされている。同様に、SPORTS(スポーツ)の下層（第２層）として、Athletics（アスレチックス）等の記述が、その、Athletics（アスレチックス）のさらに下層（第３層）として、Field（フィールド系）等の記述が、それぞれ可能とされている。また、MUSIC AND DANCE（音楽/ダンス）の下層（第２層）として、Classical music（クラシック）等の記述が可能とされている。

図２１に戻り、ParentalGuidance(視聴制限指定)には、このProgram(プログラム)の視聴制限指定が記述される。AwardsList(アワードリスト)には、このProgram(プログラム)の賞およびノミネートの一覧が記述される。RelatedMaterial(関連マテリアル)には、このProgram(プログラム)の関連する他の情報への参照情報が記述される。ProductionInformation(制作情報)には、このProgram(プログラム)が作成された日時と国についての情報が記述される。ReleaseInformation(リリース情報)には、このProgram(プログラム)が公開された日時と国についての情報が記述される。

図２０に戻り、ProgramGroup(プログラムグループ)とは、複数のProgram(プログラム)をまとめたProgramGroup(プログラムグループ)についての情報を指す。即ち、ProgramGroup(プログラムグループ)とは、シリーズ番組単位で番組を検索する際に必要な情報である。具体的には、例えば、ProgramGroup(プログラムグループ)には、図２３に示されるような情報が含まれる。

GroupId(グループ識別子)には、このProgramGroup(プログラムグループ)に対するCRIDが記述される。

GroupType(グループタイプ)には、このProgramGroup(プログラムグループ)のグループタイプが記述される。具体的には、例えば、シリーズや連続番組等の様々なタイプが記述される。

Ordered(順序型指定)は、このProgramGroup(プログラムグループ)に属するメンバーが順序付けられているか否かを示すフラグである。

MemberOf(プログラムグループへの参照)には、このProgramGroup(プログラムグループ)が含まれる（属している）ProgramGroup(プログラムグループ)のCRIDのリストが記述される。即ち、それぞれのProgramGoup(プログラムグループ)内で一意なインデックス値が付与される。

BasicContentDescription(基本コンテンツ記述) とは、基本的な内容記述を指し、具体的には、上述したProgram(プログラム)のBasicContentDescription(基本コンテンツ記述)と同様の記述（図２１参照）が含まれる。

図２０に戻り、ProgramReview(プログラムレビュー)とは、Program(プログラム)に関するレビューについての情報を指す。即ち、ProgramReview(プログラムレビュー)は、批評家の評価結果やレーティング値等から番組を検索する際に必要な情報である。

ProgramReview(プログラムレビュー)には、Program(プログラム参照)とReview(レビュー)とが含まれる。Program(プログラム参照)には、対応するProgram(プログラム)のCRIDが記述される。Review(レビュー)には、対応するProgram(プログラム)、即ち、Program(プログラム参照)で指定されたCRIDを有するProgram(プログラム)に対するレビューが記述される。なお、Review(レビュー)の記述内容の詳細については省略する。

次に、インスタンス記述メタデータについて説明する。

図２４は、インスタンス記述メタデータの構成例を示している。

図２４に示されるように、インスタンス記述メタデータは、ProgramLocation(プログラムロケーション)、OnDemandLocation(オンディマンドロケーション)、ScheduleEvent(スケジュールイベント)、および、Service(サービス)から構成される。

ProgramLocation(プログラムロケーション)とは、Program（プログラム）の個々のインスタンスを指す。即ち、ProgramLocation(プログラムロケーション)は、Program（プログラム）が配信されるメディアの違いによらない一般的なインスタンスの情報である。具体的には、例えば、ProgramLocation(プログラムロケーション)には、図２５に示されるような情報が含まれる。

即ち、Program(プログラム参照)には、対応するProgram(プログラム)のCRIDが記述される。

InstanceDescription(インスタンス記述)には、対応するProgram(プログラム)、即ち、Program(プログラム参照)で指定されたCRIDを有するProgram(プログラム)のインスタンスが記述される。具体的には、例えば、InstanceDescription(インスタンス記述)には、Program(プログラム)のBasicContentsDescription(基本コンテンツ記述)（図２１参照）のうちの、Title(タイトル)、Synopsis(概要)、および、AVAttributes(オーディオビジュアル属性)が記述される。

図２４に戻り、OnDemandLocation(オンディマンドロケーション)とは、Program（プログラム）がインターネット上にアーカイブされている場合の位置（URLアドレス・時刻・時間）を記述する際に利用される情報である。具体的には、例えば、OnDemandLocation(オンディマンドロケーション)には、ProgramLocation(プログラムロケーション)に含まれる属性の他に、図２６に示される情報が含まれる。

即ち、URLは、対応するProgram(プログラム) がインターネット上にアーカイブされている場合のURLが記述される。

PublishedDuration(再生時間)には、対応するProgram(プログラム)、即ち、上述したURLに位置するProgram(プログラム)の再生時間が記述される。

Start/EndOfAvailability(利用可能日時:開始/終了)には、対応するProgram(プログラム)、即ち、上述したURLに位置するProgram(プログラム)が使用可能となる日時、即ち、開始時刻と終了時刻とが記述される。

First/LastAvailability（リリース情報）は、対応するProgram(プログラム)、即ち、上述したURLに位置するProgram(プログラム)が初回か或いは終回である場合に、そのことを示すフラグである。

図２４に戻り、ScheduleEvent(スケジュールイベント)とは、対応するProgram（プログラム）が放送配信される場合のその位置（チャンネル、時刻、および時間）を記述する際に利用される情報を指す。具体的には、例えば、ScheduleEvent(スケジュールイベント)には、対応するProgramLocation(プログラムロケーション)に含まれる属性の他に、図２７に示される情報が含まれる。

BroadcastURL(ブロードキャストURL)には、対応するProgram（プログラム）が放送配信される場合のそのURLが記述される。具体的には、例えば、DVB(DVB Digital Video Broadcastingにより規定されている番組を指定するURL等が記述される。

ServiceId(サービス参照)には、このScheduleEvent(スケジュールイベント)が含まれるService(サービス)の識別子が記述される。

EventDescription(イベント記述)には、様々なイベントの内容情報が記述される。具体的には、例えば、PublishedTime(開始時刻)、PublishedDuration(継続時間)、Live(ライブ放送指定)、Repeat(再放送指定)、First/LastShowing(初回/終回指定)、および、Free (無料指定)が記述される。

PublishedTime(開始時刻)には、対応するProgram（プログラム）がECG（Electronic Contents Gides）上に公開される開始時刻が記述される。PublishedDuration(継続時間)には、対応するProgram（プログラム）がECG上に公開されている継続時間が記述される。なお、実際の運用時の正確な開始時刻や継続時間はロケータによる位置解決メカニズムによって提供される。

Live(ライブ放送指定)は、対応するProgram（プログラム）がライブ放送であるか否かを示すフラグである。Repeat(再放送指定)は、対応するProgram（プログラム）が再放送であるか否かを示すフラグである。First/LastShowing(初回/終回指定)は、対応するProgram（プログラム）が最初（初回）または最後（最終回）の放送である場合にそれを示すフラグである。Free (無料指定)は、対応するProgram（プログラム）が無料であるか否か示すフラグである。

図２４に戻り、Service(サービス)とは、対応するProgram（プログラム）を放送する放送チャンネルについて記述された情報を指す。即ち、Service(サービス)には、同一の放送サービス事業者から提供される複数のScheduleEvent(スケジュールイベント)に対応する放送番組を含むストリーム全体の内容が記述される。具体的には、例えば、Service(サービス)には、図２８に示される情報が含まれる。

即ち、ServiceId(サービス識別子)には、サービスの識別子が記述される。ParentService(親サービス参照)には、親Service(サービス)への参照を示す情報が記述される。例えば、ParentService(親サービス参照)には、指定された参照有効期間の記述が可能である。

Name(サービス名)にはサービスの名称が、Owner(所有者)にはそのサービスの商標所有者が、Logo(ロゴ)にはそのサービスのネットワークロゴが、ServiceGenre(サービスジャンル)にはそのサービスのジャンルが、それぞれ記述される。

ここで、図２９を参照して、Service(サービス)についてさらに詳しく説明する。

即ち、図２９は、画面に表示された一般的なEPG（Electronic Program Gide）を示しており、また、上述した、Program(プログラム)、ProgramGroup(プログラムグループ)、ScheduleEvent(スケジュールイベント)、および、Service(サービス)のそれぞれが何れのフレームに対応するのかを示している。

図２９に示されるように、EPG上の各々の番組（例えば、野球中継、ニュース、クイズ、ドラマ、バラエティ、および、映画等）はScheduleEvent(スケジュールイベント)に、一連の番組をまとめたチャンネル（例えば、チャンネルＸ，Ｙ，Ｚ等）はService(サービス)に、それぞれ対応する。各番組のそれぞれの情報のうち、ScheduleEvent(スケジュールイベント)には放映時刻等が記述され、Program(プログラム)には番組の内容自身が記述される。複数のProgram(プログラム)とそれに紐付けられるScheduleEvent(スケジュールイベント)を含むパッケージ（例えば、野球中継パッケージ等）の情報はProgramGroup(プログラムグループ)に記述される。

次に、セグメント記述メタデータについて説明する。

セグメント記述メタデータは、番組のハイライトシーンを集めて要約のみを視聴する機能や、トピックヘッドラインのブックマークを作成する等の機能を実現するための情報である。

図３０は、セグメント記述メタデータの構成例を示している。

図３０に示されるように、セグメント記述メタデータは、Segment(セグメント)、および、SegementGroup(セグメントグループ)から構成される。

ところで、上述したように、１つのProgram(プログラム)は、それを入手することができる物理的や時間的な位置の違いにより複数のProgramLocation(プログラムロケーション)に対応させることができ、特定のProgram(プログラム)のインスタンスを選択する処理はCRIDに基づいた位置解決処理によって実行される。

ここで、所定のCRIDにより識別されるProgram(プログラム)に対応する異なるインスタンスのストリーム再生時の時間軸は同一であると仮定すると、位置解決処理において何れのProgram(プログラム)のインスタンスが選択されても同じセグメント記述が適用される。

従って、図３０に示されるように、異なるProgram(プログラム)から派生する複数のSegment(セグメント)を、1つのSegementGroup(セグメントグループ)としてまとめることが可能になる。例えば、好きな俳優の出演場面だけを集めたオリジナル番組を構成する場合等に利用される。

詳細には、Segment(セグメント)とは、対応するProgram(プログラム)を時間で区切った個々のセグメントについての情報を指す。具体的には、例えば、Segment(セグメント)には、図３１に示される情報が含まれる。

Segmented(セグメント識別子)には、このSegment(セグメント)の識別子が、ProgramRef (プログラム参照)には、このSegment(セグメント)に対応するProgram(プログラム)のCRIDが、それぞれ記述される。

SegmentLocator(セグメントロケータ)には、対応するProgram(プログラム)中でのこのSegment(セグメント)の位置(開始時間および長さ)が記述される。KeyFrameLocator(キーフレームロケータ)には、このSegment(セグメント)のキーフレームの位置が記述される。

BasicSegmentDescription(基本セグメント記述)には、このSegment(セグメント)の各種内容が記述される。具体的には、例えば、Title(タイトル)、Keywords(キーワード)、Synopsis(概要)、および、RelatedMaterial(関連マテリアル)が記述される。

Title(タイトル)には、このSegment(セグメント)のタイトルが、Keywords(キーワード)には、このSegment(セグメント)のキーワードのリストが、Synopsis(概要)には、このSegment(セグメント)の内容の説明が、RelatedMaterial(関連マテリアル)には、関連する他の情報への参照情報が、それぞれ記述される。

図３０に戻り、SegmentGroup(セグメントグループ)とは、Segment(セグメント)のグループについての情報を指す。グルーピングされる際には、例えば、ハイライト、ブックマーク等のグループのタイプが定義される。具体的には、例えば、SegmentGroup(セグメントグループ)には、図３２に示される情報が含まれる。

即ち、GroupId(グループ識別子)には、このSegmentGroup(セグメントグループ)の識別子が記述される。

GroupType(グループタイプ)には、このSegmentGroup(セグメントグループ)のタイプが記述される。このGroupType(グループタイプ)に記述可能なタイプとして、一つないし複数のProgram(プログラム)から選択されたハイライトを表す” highlights”、および、Program(プログラム)に対する一連のアクセスポイントを示す” bookmarks”等が存在する。

Ordered(順序型指定)は、グループ内のメンバーが順序付けられているか否かを示すフラグである。

Duration（継続時間）には、このグループに含まれるSegment（セグメント）の長さの合計時間が記述される。なお、この長さはSegmentGroup(セグメントグループ)の直接のメンバーであるSegment（セグメント）の長さの合計に相当する。

Segment/SegmentGroupRefs(セグメント/セグメントグループ参照)には、メンバーであるSegment（セグメント）/ SegmentGroup(セグメントグループ)への参照情報が記述される。

ProgramRef(プログラム参照)には、このSegmentGroup(セグメントグループ)が属しているProgram(プログラム)への参照情報が記述される。メンバーとなるSegment(セグメント)やSegmentGroup(セグメントグループ)がそれぞれ異なるProgram(プログラム)から収集されている場合、それらのProgram(プログラム)からなるProgramGroup(プログラムグループ)のCRIDが参照される。

KeyFrameLocator(キーフレームロケータ)には、一つのProgram(プログラム)内に閉じたSegmentGroup(セグメントグループ)について、そのキーフレームの位置が記述される。

BasicSegmentDescription(基本セグメント記述)は、SegmentGroup(セグメントグループ)の内容に関する記述であって、上述したSegment(セグメント)のBasicSegmentDescription(基本セグメント記述)（図３１参照）と同様の記載がなされる。

図３３乃至図３６には、Program(プログラム)の中の複数のSegment(セグメント)をSegmentGroup(セグメントグループ)により所定の観点でまとめる様子が示されている。

即ち、図３３は、第１のProgram(プログラム)の構成例を示している。

図３３に示されるように、第１のProgram(プログラム)は、Segment(セグメント)３０１Ａ乃至３０１Ｇから構成される。

なお、同図中、複数の斜線が描画された領域を有するSegment(セグメント)、即ち、Segment(セグメント)３０１Ａ，３０１Ｄ，３０１Ｇは、GroupType(グループタイプ)が” highlights”であるSegmentGroup(セグメントグループ)に属することを示している。

また、同図中、複数の水平線が描画された領域を有するSegment(セグメント)、即ち、Segment(セグメント)３０１Ｂ，３０１Ｄは、GroupType(グループタイプ)が” bookmarks” であるSegmentGroup(セグメントグループ)に属することを示している。

図３４は、第２のProgram(プログラム)の構成例を示している。

図３４に示されるように、第２のProgram(プログラム)は、Segment(セグメント)３０２Ａ乃至３０２Ｈから構成される。

なお、同図中、複数の水平線が描画された領域を有するSegment(セグメント)、即ち、Segment(セグメント)３０２Ａ，３０２Ｃ，３０２Ｆは、GroupType(グループタイプ)が” bookmarks” であるSegmentGroup(セグメントグループ)に属することを示している。

図３５は、このような第１のProgram(プログラム)（図３３）と、第２のProgram(プログラム)（図３４）の中から、GroupType(グループタイプ)が” highlights”であるSegmentGroup(セグメントグループ)のSegment(セグメント)をまとめた場合の構成例を示している。このように、セグメント記述メタデータを使用することで、ハイライトシーンだけを集めたSegmentGroup(セグメントグループ)を定義することが可能になる。

図３６は、このような第１のProgram(プログラム)（図３３）と、第２のProgram(プログラム)（図３４）の中から、GroupType(グループタイプ)が” bookmarks”であるSegmentGroup(セグメントグループ)のSegment(セグメント)をまとめた場合の構成例を示している。このように、セグメント記述メタデータを使用することで、複数の番組をまたがって所望の対象物（例えば、好みの出演者等）が出ているシーンを集めたSegmentGroup(セグメントグループ)、即ち、そのようなブックマークを集めたSegmentGroup(セグメントグループ)を定義することが可能になる。

以上、本発明において、リムーバブル記録媒体（図３のリムーバブル記録媒体３１や図８等のリムーバブル記録媒体１３１）に記録可能なメタデータの例について説明した。

ところで、本発明が適用されるコンテンツナビゲーション機能の形態は、図３の例に限定されず、様々な形態を取ることが可能である。即ち、本発明は、図２のクライアント主体型ナビゲーションに適用できるだけでなく、その他のコンテンツナビゲーション機能に対しても適用可能である。

具体的には、例えば、図３７に示されるようなコンテンツナビゲーション機能の形態、即ち、ネットワーク依存型ナビゲーション（図１）と、クライアント主体型ナビゲーション（図２）とを併せた形態（以下、このような形態を、ハイブリット型ナビゲーションと称する）に対して、本発明を適用することができる。即ち、図３７は、ハイブリット型ナビゲーション手法を説明する図である。

ハイブリット型ナビゲーション手法においては、クライアント３０２−Ａには、ブラウザ３１１とクライアントアプリケーション３１２とが共に設けられている。クライアント３０２―Ａにはまた、クライアントメタデータデータベース３１３が設けられている。

また、サーバ３０１には、ショップサーバ３２１、および、メタデータデータベース３２２が設けられている。サーバ３０１にはさらに、図示はしないが、図８のサーバ１０１と同様の、決済サーバ、コンテンツサーバ、および、DRMサーバ等が設けらることもある。

なお、ハイブリット型ナビゲーションにおけるクライアント３０２−Ａの動作は、基本的に、ネットワーク依存型ナビゲーションにおけるクライアント１の動作（図１）と、クライアント主体型ナビゲーション（図２）におけるクライアント１１−Ａの動作との組み合わせである。従って、ここでは、その詳細な説明については省略する。

このように、ハイブリット型ナビゲーションは、クライアント主導型ナビゲーション(図２)が有する特長と、ネットワーク依存型ナビゲーション（図１）が有する特長とのそれぞれをそのまま有することになる。

しかしながら、ハイブリット型ナビゲーションでも、結局、クライアント主導型ナビゲーションが有する上述した第３の課題と第４の課題とをそのまま有することになる。

そこで、図３８に示されるように、ハイブリット型ナビゲーションに対しても、図３と同様の手法（本発明の手法）を適用することで、第３の課題と第４の課題とを解決することができる。即ち、図３８は、本発明が適用されるコンテンツナビゲーション手法の他の形態（図３とは異なる形態）を説明する図である。なお、図３８において、図３７と対応する部分には対応する符号が付してある。

図３８に示されるように、ハイブリット型ナビゲーションに対しても本発明を適用することで、クライアント３０２−Ｂは、サーバ３０１のメタデータデータベース３２２に蓄積されているメタデータや、クライアントアプリケーション（ナビゲーションプログラム）３１２−Ａ等の情報を、リムーバブル記録媒体３３２から取得することが可能になる。

従って、ハイブリット型ナビゲーションに対しても本発明を適用した場合（図３８）においても、クライアント主体型ナビゲーションに対して本発明を適用した場合（図３）と全く同様の効果を奏することが可能になる。

ところで、本発明が適用されるリムーバブル記録媒体（図３のリムーバブル記録媒体３１、図８等のリムーバブル記録媒体１３１、および、図３８のリムーバブル記録媒体３３２等）は、図３９のフローチャートに従って製造することができる。

即ち、図３９は、発明が適用されるリムーバブル記録媒体の製造方法を説明するフローチャートである。そこで、以下、図３９のフローチャートを参照して、本発明が適用されるリムーバブル記録媒体の製造方法を説明する。

なお、上述したように、リムーバブル記録媒体の製造装置の形態は特に限定されないが、ここでは、上述した図５の形態（パーソナルコンピュータ）のサーバ１０１が製造装置であるとして説明する。

はじめに、ステップＳ３０１において、サーバ１０１のCPU１２１は、リムーバブル記録媒体１３１がドライブ１３０に装着されたか否かを判定する。

リムーバブル記録媒体１３１がドライブ１３０に装着されていない場合（ステップＳ３０１において、リムーバブル記録媒体１３１が装着されていないと判定された場合）、処理はステップＳ３０１に戻され、ムーバブル記録媒体１３１が装着されたか否かが再度判定される。即ち、リムーバブル記録媒体１３１が装着されるまで、ステップＳ３０１の処理が繰り返される。

リムーバブル記録媒体１３１がドライブ１３０に装着されると、CPU１２１は、ステップＳ３０１において、リムーバブル記録媒体１３１が装着されたと判定し、ステップＳ３０２において、記憶部１２８等からメタデータを読み出し、リムーバブル記録媒体１３１に記録させる。

ステップＳ３０３において、CPU１２１は、ナビゲーションプログラム２０３−Ａ（図８）を記憶するか否かを判定する。

ステップＳ３０３において、ナビゲーションプログラム２０３−Ａを記憶しないと判定された場合、処理は終了となる。即ち、メタデータのみが記録されたリムーバブル記録媒体１３１が製造される。

なお、ステップＳ３０３において、ナビゲーションプログラム２０３−Ａを記憶しないと判定された場合、処理は終了されずに、ステップＳ３０５の処理に移行してもよい。

これに対して、ステップＳ３０３において、ナビゲーションプログラム２０３−Ａを記憶すると判定した場合、CPU１２１は、ステップＳ３０２において、記憶部１２８等からナビゲーションプログラム２０３−Ａを読み出し、リムーバブル記録媒体１３１に記録させる。

そして、ステップＳ３０４において、CPU１２１は、その他の情報を記録するか否かを判定する。

ステップＳ３０５において、その他の情報を記憶しないと判定された場合、処理は終了となる。即ち、メタデータとナビゲーションプログラム２０３−Ａとが記録されたリムーバブル記録媒体１３１が製造される。

これに対して、ステップＳ３０５において、その他の情報を記録すると判定した場合、CPU１２１は、ステップＳ３０６において、記憶部１２８等から対応する情報（その他の情報）を読み出し、リムーバブル記録媒体１３１に記録させる。これにより、処理は終了となり、メタデータ、ナビゲーションプログラム２０３−Ａ、およびその他の情報が記録されたリムーバブル記録媒体１３１が製造される。

ところで、上述した一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラム（例えば、クライアントアプリケーション等）が、ネットワークや記録媒体からインストールされる。

この記録媒体は、図３，図５，図６，図３８等に示されるように、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク（フロッピディスクを含む）、光ディス（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク（ＭＤ（Mini-Disk）を含む）、もしくは半導体メモリなどよりなるリムーバブル記録媒体３１（図３），１３１（図５や図６等），３３２（図３８）により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROM１２２（図５），１５９（図６）や、記憶部１２８，補助記憶部１６０に含まれるハードディスクなどで構成される。

なお、上述した一連の処理は必要に応じて、適宜ハードウエアに実行させてもよい。

また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。

また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。

以上においては、クライアントは、図６に示されるハードディスクビデオレコーダ、または、図５に示されるパーソナルコンピュータで構成されるとして説明したが、本発明が適用されるクライアントは、上述したように、リムーバブル記録媒体が装着可能であればその形態は特に限定されず、これらの他、ディジタルテレビジョン受像機、DVD(Digital Versatile Disk)レコーダ、その他各種のコンテンツ処理装置に適用することが可能である。

また、配信するコンテンツは、テレビジョン放送の番組に限らず、各種のコンテンツとすることができる。

コンテンツナビゲーション機能の従来の形態（ネットワーク依存型ナビゲーション）を説明する図である。 図１のネットワーク依存型ナビゲーションが有する課題を解決可能なコンテンツナビゲーション機能の形態（クライアント主体型ナビゲーション）を説明する図である。 図２のクライアント主体型ナビゲーションに本発明を適用した場合の形態、即ち、本発明が適用される、コンテンツナビゲーション機能の形態を説明する図である。 本発明を適用したコンテンツ配信システムの構成例を示すブロック図である。 図４のサーバのハードウエア構成例を示すブロック図である。 図４のクライアントのハードウエア構成例を示すブロック図である。 図６のクライアントを遠隔操作するリモートコマンダの外観の構成例を示す正面図である。 図４のコンテンツ配信システムの機能的構成例を示すブロック図である。 各種のIDとメタデータの関係を説明する図である。 パッケージメタ、ライセンスメタデータ、およびコンテンツメタデータの関係を示す図である。 図４のクライアントが、サーバから配信されたコンテンツを取得する場合の動作例を説明するフローチャートである。 図１１のメタデータ事前取得処理の詳細な例を説明するフローチャートである。 図１１の購入コンテンツナビゲーション処理の詳細な例を説明するアローチャートである。 図８のクライアントの呈示部がユーザに呈示する、購入コンテンツをユーザに決定させるためのユーザインタフェース用の画像（コンテンツリスト）の例を示す図である。 図１１のライセンス取得処理の詳細な例を説明する図である。 図１１のダウンロード処理の詳細な例を説明するアローチャートである。 図１１の利用コンテンツナビゲーション処理の詳細な例を説明するアローチャートである。 メタデータの分類法を説明する図である。 図１８等で使用されるシンボルの規則を説明する図である。 図１８のコンテンツ検索属性メタデータのうちのコンテンツ記述メタデータの構成例を説明する図である。 図２０のコンテンツ記述メタデータのうちのProgram（プログラム）の構成例を示す図である。 図２１のProgram（プラグラム）のGenre（ジャンル）に記述可能なジャンルの階層構造例を示す図である。 図２０のコンテンツ記述メタデータのうちのProgramGroup（プログラムグループ）の構成例を示す図である。 図１８のコンテンツ検索属性メタデータのうちのインスタンス記述メタデータの構成例を説明する図である。 図２４のインスタンス記述メタデータのうちのProgramLocation（プログラムロケーション）の構成例を説明する図である。 図２４のインスタンス記述メタデータのうちのOnDemandLocation（オンディマンドロケーション）の構成例を説明する図である。 図２４のインスタンス記述メタデータのうちのScheduleEvent（スケジュールイベント）の構成例を説明する図である。 図２４のインスタンス記述メタデータのうちのService（サービス）の構成例を説明する図である。 画面に表示された一般的なEPG（Electronic Program Gide）の例を示す図である。 図１８のコンテンツ検索属性メタデータのうちのセグメント記述メタデータの構成例を説明する図である。 図３０のセグメント記述メタデータのうちのSegment（セグメント）の構成例を説明する図である。 図３０のセグメント記述メタデータのうちのSegmentGroup（セグメントグループ）の構成例を説明する図である。 セグメント記述メタデータの使用方法を説明するための、第１のプログラムの構成例を示す図である。 セグメント記述メタデータの使用方法を説明するための、第２のプログラムの構成例を示す図である。 図３３の第１のプログラムと図３４の第２のプログラムの中から、GroupType(グループタイプ)が” highlights”であるSegmentGroup(セグメントグループ)のSegment(セグメント)をまとめた場合の構成例を示す図である。 図３３の第１のプログラムと図３４の第２のプログラムの中から、GroupType(グループタイプ)が” bookmarks”であるSegmentGroup(セグメントグループ)のSegment(セグメント)をまとめた場合の構成例を示す図である。 図１のネットワーク依存型ナビゲーションと図２のクライアント主体型ナビゲーションとを併せたコンテンツナビゲーション機能（ハイブリット型ナビゲーション）の原理を説明する図である。 図３７のハイブリット型ナビゲーションに本発明を適用した場合の形態、即ち、本発明が適用される、コンテンツナビゲーション機能の他の形態を説明する図である。 リムーバブル記録媒体の製造処理を説明するフローチャートである。

符号の説明

１１−Ａ，１１−Ｂ クライアント， ２１ クライアントアプリケーション， ２１−Ａ クライアントアプリケーション（ナビゲーションプログラム）， ２２ クライアントメタデータデータベース， ３１ リムーバブル記録媒体， １０１ サーバ， １０２ ネットワーク， １０３ クライアント， １３１ リムーバブル記録媒体， １５７ CPU， １５９ ROM， １６２ 入力部， １６３ 通信部， １６４ ドライブ， ２０３ クライアントアプリケーション， ２０４ コンテンツ再生部， ２０５ DRM処理部， ２０６ 課金処理部， ２０７ ダウンロード処理部， ２０８ コンテンツ記憶部， ２０９ クライアントメタデータデータベース， ２２１ ショップサーバ， ２２２ 決済サーバ， ２２３ メタデータデータベース， ２２４ DRMサーバ， ２２５ コンテンツサーバ， ３０１ サーバ， ３０２−Ａ，３０２−Ｂ クライアント， ３１１ ブラウザ， ３１２ クライアントアプリケーション， ３１２−Ａ クライアントアプリケーション（ナビゲーションプログラム）， ３１３ クライアントデータベース， ３２１ ショップサーバ， ３２２ メタデータデータベース, ３３２ リムーバブル記録媒体

Claims (9)

1. 外部に配置されるコンテンツを取得し使用する情報処理装置において、
   １以上の前記コンテンツのそれぞれのメタデータが記録されているとともに、１以上の前記コンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、前記メタデータを利用して誘導する誘導ステップと、前記ユーザが前記誘導ステップの処理に従って選択した前記コンテンツの配置場所を前記メタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップとを含むプログラムが記録されている記録媒体が装着される装着手段と、
   前記装着手段に装着された前記記録媒体に記録されている前記メタデータを利用して、前記記録媒体に記録されている前記プログラムに含まれる前記誘導ステップと前記取得ステップとのそれぞれの処理を実行する実行手段と
   を備えることを特徴とする情報処理装置。
2. 前記記録媒体には、前記メタデータを取得するために必要な情報がさらに記録されており、
   前記実行手段は、前記情報に従って前記メタデータを前記記録媒体から取得し、そのメタデータを利用して前記誘導ステップと前記取得ステップとのそれぞれの処理を実行する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記記録媒体には、前記誘導ステップまたは前記取得ステップの処理のうちの少なくとも一部の処理を実行するために必要な情報がさらに記録されており、
   前記実行手段は、前記情報に従って、前記誘導ステップまたは前記取得ステップの処理のうちの対応する処理を実行する
   ことを特徴とする請求項１に記載の情報処理装置。
4. 前記メタデータには、１以上の前記コンテンツのそれぞれに対する、購入期間、価格、およびライセンスに関する情報が含まれる
   ことを特徴とする請求項１に記載の情報処理装置。
5. 前記実行手段は、前記コンテンツを取得し使用するために、前記記録媒体に記録された前記プログラムとは異なる他のプログラムに含まれる他のステップの処理をさらに実行し、
   前記記録媒体には、前記他のプログラムに含まれる前記他のステップの処理のうちの少なくとも一部の処理を実行するために必要な情報がさらに記録されている
   ことを特徴とする請求項１に記載の情報処理装置。
6. 前記記録媒体には、前記メタデータに対応する１以上の前記コンテンツとは異なる他のコンテンツのデータがさらに記録されている
   ことを特徴とする請求項１に記載の情報処理装置。
7. 外部に配置されるコンテンツを取得し使用する情報処理装置の情報処理方法において、
   １以上の前記コンテンツのそれぞれのメタデータが記録されているとともに、１以上の前記コンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、前記メタデータを利用して誘導する誘導ステップと、前記ユーザが前記誘導ステップの処理に従って選択した前記コンテンツの配置場所を前記メタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップとを含むプログラムが記録されている記録媒体が前記情報処理装置に装着された場合、
   前記情報処理装置に装着された前記記録媒体に記録されている前記メタデータを利用して、前記記録媒体に記録されている前記プログラムに含まれる前記誘導ステップと前記取得ステップとのそれぞれの処理を実行する
   ことを特徴とする情報処理方法。
8. 外部に配置されるコンテンツを取得し使用する情報処理装置に装着される記録媒体において、
   １以上の前記コンテンツのそれぞれのメタデータが記録されているとともに、
   前記情報処理装置を制御するコンピュータに実行させるプログラムであって、１以上の前記コンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、前記メタデータを利用して誘導する誘導ステップと、前記ユーザが前記誘導ステップの処理に従って選択した前記コンテンツの配置場所を前記メタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップとを含むプログラムが記録されている
   ことを特徴とする記録媒体。
9. 外部に配置されるコンテンツを取得し使用する情報処理装置に装着される記録媒体の製造方法において、
   １以上の前記コンテンツのそれぞれのメタデータを前記記録媒体に予め記録する第１の記録ステップと、
   前記情報処理装置を制御するコンピュータに実行させるプログラムであって、１以上の前記コンテンツの中からこれから取得するコンテンツを選択するまでのユーザの一連の操作を、前記メタデータを利用して誘導する誘導ステップと、前記ユーザが前記誘導ステップの処理に従って選択した前記コンテンツの配置場所を前記メタデータから認識し、その配置場所にアクセスして、そのコンテンツを取得する取得ステップとを含むプログラムを前記記録媒体に予め記録する第２の記録ステップと
   を含むことを特徴とする記録媒体の製造方法。

Images