(57)【要約】  マルチメディアデータを蓄積し、端末へ送信するマルチメディアコンテンツサーバにおいて、端末が特殊再生などのためにランダムアクセスを行ったとしても、データ放送を実現できる技術を提供する。マルチメディアデータ送信装置（１０１）は、マルチメディアデータ受信装置（１０２）からデータ送信要求を受け取ると、要求されたマルチメディアデータを送信するとともに、データ放送に必要な情報を、必ず送信するマルチメディアデータへ挿入するかあるいは、マルチメディアデータとは別にデータ放送用データを送信することにより、マルチメディアデータ受信装置（１０２）はデータ放送に必要なデータを取得することができるようになる。
2010525616.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディアデータ受信装置からの送信要求に応じて、蓄積されたマルチメディアデータを、ネットワークを経由して前記マルチメディアデータ受信装置へ送信するマルチメディアデータ送信装置であって、
デジタル放送から受信した、オーディオ、ビデオ、および付加情報を含む第１のマルチメディアデータを蓄積する蓄積部と、
前記蓄積された第１のマルチメディアデータにおいて発生するイベント及び該イベント発生のタイミングを表現するイベント情報を管理するイベント情報管理部と、
前記マルチメディアデータ受信装置からの要求メッセージを受信する要求受信部と、
前記要求メッセージによって指定されたマルチメディアデータおよびイベント情報を前記マルチメディアデータ受信装置へ送信する情報送信部とを備える
ことを特徴とするマルチメディアデータ送信装置。
【請求項２】
前記マルチメディアデータ送信装置は、さらに、前記蓄積した第１のマルチメディアデータから複数の区間を抽出し、指定された特殊再生に応じた第２のマルチメディアデータを生成する送信データ生成部を備え、
前記マルチメディアデータ受信装置からの特殊再生の要求を受けた場合に、
前記送信データ生成部は、
前記イベント情報を参照することにより、前記マルチメディアデータ受信装置から指定された前記第１のマルチメディアデータにおいて発生するイベントを含むように前記第２のマルチメディアデータを生成し、かつ、
前記第１のマルチメディアデータにおける前記イベントの発生タイミングを含んだ区間を特定した場合には、前記第２のマルチメディアデータにおいて該区間の同じ位置に該イベントを配置し、
該イベントの発生タイミングを含む区間を特定しなかった場合は、前記第１のマルチメディアデータにおいて、前記イベントの発生タイミングより後かつ直近の特定された前記第１のマルチメディアデータの区間に相当する、前記第２のマルチメディアデータの区間の直前に該イベントを配置し、
前記情報送信部は、前記送信データ生成部が生成した前記第２のマルチメディアデータを送信する
ことを特徴とする請求項１記載のマルチメディアデータ送信装置。
【請求項３】
前記要求受信部が前記マルチメディアデータ受信装置から受け付ける要求メッセージは、マルチメディアデータ、ＭＰＥＧ（Moving Picture Experts Group）規格のセクションデータ、ファイル、ディレクトリ、ＭＰＥＧ  ＤＳＭ−ＣＣ（Digital Storage Media Command and Control）規格のＭｏｄｕｌｅまたは前記規格のＯｂｊｅｃｔの取得要求である
ことを特徴とする請求項１記載のマルチメディアデータ送信装置。
【請求項４】
前記要求受信部が前記マルチメディアデータ受信装置から受け付ける要求メッセージは、データの種類、データの識別子、およびマルチメディアデータの区間のうち、少なくとも何れかひとつを指定する
ことを特徴とする請求項３記載のマルチメディアデータ送信装置。
【請求項５】
前記情報送信部は、前記マルチメディアデータ受信装置からの要求メッセージに応じて、前記要求メッセージに対応するマルチメディアデータ、ＭＰＥＧ（Moving Picture Experts Group）規格のセクションデータ、ファイル、ディレクトリ、ＭＰＥＧ  ＤＳＭ−ＣＣ（Digital Storage Media Command and Control）規格のＭｏｄｕｌｅまたは前記規格のＯｂｊｅｃｔを送信する
ことを特徴とする請求項３記載のマルチメディアデータ送信装置。
【請求項６】
前記情報送信部は、前記マルチメディアデータ受信装置から要求メッセージが受信されたときに、前記イベント情報管理部が管理するデータを参照することにより、前記要求メッセージに応じたデータを選択して送信する
ことを特徴とする請求項５記載のマルチメディアデータ送信装置。
【請求項７】
前記イベント情報管理部は、さらに、該第１のマルチメディアデータに含まれるデータ放送を再生するための情報を管理する
ことを特徴とする請求項１記載のマルチメディアデータ送信装置。
【請求項８】
前記情報送信部は、前記マルチメディアデータ受信装置からの要求により、前記イベント情報管理部が保持するイベント情報の管理情報を前記マルチメディアデータ受信装置へ送信する
ことを特徴とする請求項１記載のマルチメディアデータ送信装置。
【請求項９】
マルチメディアデータ送信装置から、マルチメディアデータと前記マルチメディアデータの関連情報を受信して前記マルチメディアデータを再生するマルチメディアデータ受信装置であって、
前記関連情報は、前記マルチメディアデータに関連するＭＰＥＧ規格のセクションデータ、ファイル、ディレクトリ、ＭＰＥＧ  ＤＳＭ−ＣＣ（Moving Picture Experts Group   Digital Storage Media Command and Control）規格のＭｏｄｕｌｅ、前記規格のＯｂｊｅｃｔ、または、該マルチメディアデータにおいて発生するイベント及びイベント発生のタイミングを表現するイベント情報であり、
前記受信した関連情報の種類に応じた処理によって、前記マルチメディアデータの再生を行う
ことを特徴とするマルチメディアデータ受信装置。
【請求項１０】
前記マルチメディアデータ受信装置は、前記イベント情報を受信した場合、前記受信したイベント情報の内容に応じて、受信済みの前記マルチメディアデータもしくは前記関連情報を削除することにより、または、前記マルチメディアデータ送信装置に要求して新たなマルチメディアデータもしくは関連情報を受信することにより、前記マルチメディアデータ受信装置が保持する前記マルチメディアデータもしくは前記関連情報の更新を行う
ことを特徴とする請求項９記載のマルチメディアデータ受信装置。
【請求項１１】
前記マルチメディアデータ受信装置は、前記マルチメディアデータ送信装置に要求することにより前記関連情報を受信する
ことを特徴とする請求項９記載のマルチメディアデータ受信装置。
【請求項１２】
前記マルチメディアデータ受信装置は、さらに、
前記マルチメディアデータ送信装置が保持する、前記イベントの管理情報を受信し、
受信した前記管理情報を参照することにより、前記イベントに応じて必要となるデータを判定し、
前記必要となるデータを前記マルチメディアデータ送信装置に要求することによって受信する
ことを特徴とする請求項９記載のマルチメディアデータ受信装置。
【請求項１３】
前記マルチメディアデータ受信装置は、さらに、
Ｊａｖａ（登録商標）アプリケーションを実行するＪａｖａ実行手段を備え、
前記Ｊａｖａアプリケーションからの指示により、マルチメディアデータ、あるいは、前記マルチメディアデータの関連情報を取得する
ことを特徴とする請求項９記載のマルチメディアデータ受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ホームネットワークなどのネットワーク上で、デジタル化されたマルチメディアコンテンツデータの送受信に関するもので、特にデータ放送などマルチメディアデータに付随するデータの再生の実現に関連する。
【背景技術】
【０００２】
近年、ＢＳデジタル放送、ＣＳ１１０度デジタル放送および地上波デジタル放送などのデジタル放送が開始された。また、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）やＢＤ（Ｂｌｕ−Ｒａｙ  Ｄｉｓｃ）、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）などデジタルデータの記録媒体に番組を録画するＤＶＲ（Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｒｅｃｏｒｄｅｒ）などの普及が進んでいる。これらにより、家庭内で利用できる、デジタル化されたマルチメディアコンテンツが増加している。
【０００３】
また、一方で、ブロードバンド環境の整備により、家庭からのインターネットアクセスが普及している。それに伴い、家庭内の各部屋をＩＰネットワークで繋ぐ、いわゆるホームネットワークの普及も進んでいる。
【０００４】
このような状況により、家庭内のデジタル放送受信機で受信したデジタル放送、もしくは、レコーダに蓄積したデジタルコンテンツを、ホームネットワークを用いて、他の部屋で視聴するといったことが行われるようになった。
【０００５】
こういった、ホームネットワークを用いたデジタルコンテンツの共有では、上記のようなＣＥ機器間だけでなく、パーソナルコンピュータ（ＰＣ）やＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔｓ)と呼ばれる携帯情報端末などを含めた、ホームネットワークに接続される全ての機器間で可能とする動きが活発である。具体的には、ＤＬＮＡ（Ｄｉｇｉｔａｌ  Ｌｉｖｉｎｇ  Ｎｅｔｗｏｒｋ  Ａｌｌｉａｎｃｅ）などの標準化団体がこのための標準規格、実装ガイドラインを策定して公開している。
【０００６】
この際、ホームネットワーク上のサーバ（例えば、デジタル放送を受信するセットトップボックスやＤＶＲ）とクライアント（例えば、パーソナルコンピュータやデジタルプレーヤ）における、お互いの機器の認識や利用できるコンテンツの情報のやり取りには、ＵＰｎＰ  ＤＡ（Ｕｎｉｖｅｒｓａｌ  Ｐｌａｇ  ａｎｄ  Ｐｌａｙ  Ｄｅｖｉｃｅ  Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＵＰｎＰ  ＡＶ（ＵＰｎＰ  ＡＶ  Ａｒｃｈｉｔｅｃｔｕｒｅ） に規定されたものが使用される。ＵＰｎＰ  ＡＶでは、サーバは、クライアントからの問い合わせを受けて、提供コンテンツの一覧と、各コンテンツの属性を返答する。また、コンテンツデータを通信する必須プロトコルとして、ＤＬＮＡではＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を必須として用いることとしている。
【０００７】
このようなホームネットワークにおけるコンテンツの共有において、例えば放送コンテンツを、複数端末間でネットワークを利用し共有する場合、日本のＡＲＩＢ規格や欧州のＤＶＢ規格のような放送規格に従う必要がある。これらの規格ではネットワークに出力する場合、ＰａｒｔｉａｌＴＳの形式で出力すると決められている。また放送では、ストリーム中の構造情報やアプリケーション情報を運ぶセクションデータはバージョンアップし更新される。更に、データ放送のために、データ放送の再生中に使用される実データを配信しており、このデータ放送用の実データも、バージョンアップし更新される。更に、映像や音声とデータ放送の同期を実現するために、データ放送を行うコンテンツが利用する時間情報や映像・音声との同期を行うタイミングを通知するセクションも伝送されている。このようなストリーム中の更新情報や同期のタイミング通知などのイベント情報を正しく取得するためには、クライアントはホームネットワークを用いてサーバ上のＰａｒｔｉａｌＴＳを全て受信し解析する必要がある。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００５−１２３７３４号公報
【特許文献２】特開２００６−２６１７６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、録画したコンテンツをネットワーク経由で再生する際、クライアントは該コンテンツに対応するＰａｒｔｉａｌＴＳの全データを受信できるとは限らない。例えば、クライアントがサーバ上に存在するコンテンツを特殊再生するとき、クライアントはコンテンツデータの特定区間を選択的に受信し再生する方法や、サーバはクライアントに要求された再生スピードに応じてコンテンツデータの特定区間を選択し、選択したデータでストリームを構成して送信し、クライアントは受信したストリームを再生する方法を用いることができる。このような方法で早送りなどの特殊再生を行うと、クライアントは、該コンテンツのストリームデータを全て受信することはできない。受信できなかったストリームに、映像や音声とデータ放送を同期するタイミングを通知するイベントや、データ放送の再生中に使用される実データ、データ放送用データなどのバージョンアップを通知するイベントを含む場合、クライアントは、正しくデータ放送の再生を実現することができない。そのため、サーバは、特殊再生中であってもクライアントがストリーム中のイベント情報を判断できる情報をクライアントへ送出する方法や映像・音声とデータ放送に関連する情報を分離し送出する方法が求められる。
【００１０】
このとき第一の課題は、クライアントは所望のコンテンツを含むデータ放送用データの存在及びその内容を知らないため、別途、データ放送用データやイベント情報の取得を要求することができない。
【００１１】
第二の課題は、データ放送用データが更新されている可能性があるため、データ放送用データをサーバから取得する際に、該当データがバージョンアップされていると、クライアントは適切なデータを取得できない。
【００１２】
第三の課題は、クライアントがサーバから取得したデータ放送用データを記憶領域に保存する場合、記憶領域に保存されたデータ放送用データがクライアントの再生位置において、使用可能か否か判断できない。これは、クライアントが該データ放送用データに関連するバージョンアップなどのイベントの発生の有無を検知できないためである。
【００１３】
第四の課題は、クライアントが映像や音声と同期したデータ放送を実現するためには、クライアントが該当するデータを必要とするタイミングでサーバへデータ取得要求を発行していては、映像や音声の同期処理にデータ取得が間に合わない可能性がある。これは、クライアントがサーバから所望のデータを取得する際に遅延（ネットワークによる遅延やサーバ処理による遅延など）が発生する可能性があることに加え、この遅延が起こっている間もクライアント端末上では、コンテンツの再生が行われており、クライアント上では、本来データ放送と同期すべきタイミングを過ぎてしまう可能性があるため、映像・音声とデータ放送の同期を正しく実現することができない。
【００１４】
このような課題に対して、特開２００５−１２３７３４号公報では、映像・音声の帯域を確保し、余った帯域でデータ放送を送出する手法を提案している。ここでは、クライアント端末を操作するユーザがＥＰＧ情報を操作する処理をトリガとし、サーバへデータ送信要求を発行する。しかし、特開２００５−１２３７３４号公報では、クライアントではデータ放送用データを記憶領域に保存することを想定していないため、第三の課題を解決することはできない。さらに、特開２００５−１２３７３４号公報では、ネットワークの遅延などにより、データ放送用データの取得が遅延することを想定していないため、第四の課題を解決することができない。さらに、特開２００５−１２３７３４号公報は、データのバージョンアップの記述がないため第ニの課題の解決策を得ることができない。また、データ放送用のイベントのように同期処理を要する情報の送受信について具体的な手法が明記されていないため、第一の課題に関しても、十分な解決策を得ることができない。
【００１５】
また、特開２００６−２６１７６３号公報は、データ放送のデータ及び管理テーブルを記録し、特殊再生中であってもデータ放送の再生を可能とする手法を提案している。しかしながら、特開２００６−２６１７６３号公報は、ローカル端末上で特殊再生時にデータ放送を行う手法を提案しており、ネットワークを経由したストリーミング再生は想定していない。そのため、ネットワーク経由のストリーミング再生でデータ放送の再生を実現する際に発生する第一から第四の課題を解決することはできない。
【００１６】
そこで、本発明は、かかる問題に鑑みてなされたものであって、ストリーミング再生において特殊再生中であってもストリーム中のイベントを判断できる情報を、サーバからクライアントへ送出する方法やマルチメディアデータ受信装置からデータ放送関連情報の取得要求を受け、該要求に応じたデータ放送関連情報を送出するマルチメディアデータ送信装置と、受信した情報を基にストリーム及びデータ放送の再生を行うマルチメディアデータ受信装置を提供することを目的とする。
【課題を解決するための手段】
【００１７】
上記目的を達成するために、本発明のマルチメディアデータ送信装置は、マルチメディアデータ受信装置からの送信要求に応じて、蓄積されたマルチメディアデータを、ネットワークを経由して前記マルチメディアデータ送信装置へ送信するものであって、デジタル放送から受信した、オーディオ、ビデオ、および付加情報を含む第１のマルチメディアデータを蓄積する蓄積部と、前記蓄積された第１のマルチメディアデータにおいて発生するイベント及び該イベント発生のタイミングを表現するイベント情報を管理するイベント情報管理部と、前記マルチメディアデータ受信装置からの要求メッセージを受信する要求受信部と、前記要求メッセージによって指定されたマルチメディアデータおよびイベント情報を前記マルチメディアデータ受信装置へ送信する情報送信部とを備える。
【００１８】
本構成によれば、マルチメディアデータに含まれる更新やデータ放送の時刻あるいは映像・音声との同期情報などタイミングに関連するイベント情報を管理し、それを前記マルチメディアデータ受信装置へ送信することができる。
【００１９】
また、前記マルチメディアデータ送信装置は、さらに、蓄積した第１のマルチメディアデータから複数の区間を抽出し、指定された特殊再生に応じた第２のマルチメディアデータを生成する送信データ生成部を備え、前記マルチメディアデータ受信装置からの特殊再生の要求を受けた場合に、前記送信データ生成部は、前記イベント情報を参照することにより、前記マルチメディアデータ受信装置から指定された前記第１のマルチメディアデータにおいて発生するイベントを含むように前記第２のマルチメディアデータを生成し、かつ、前記第１のマルチメディアデータにおける前記イベントの発生タイミングを含んだ区間を特定した場合には、前記第２のマルチメディアデータにおいて該区間の同じ位置に該イベントを配置し、該イベントの発生タイミングを含む区間を特定しなかった場合は、前記第１のマルチメディアデータにおいて、前記イベントの発生タイミングより後かつ直近の特定された前記第１のマルチメディアデータの区間に相当する、前記第２のマルチメディアデータの区間の直前に該イベントを配置し、前記情報送信部は、前記送信データ生成部が生成した前記第２のマルチメディアデータを送信しても良い。
【００２０】
本構成によれば、特殊再生中であっても、前記第１のマルチメディアデータのイベントを、前記マルチメディアデータ受信装置へ送信することが可能となる。
【００２１】
また、前記要求受信部が前記マルチメディアデータ受信装置から受け取る要求メッセージは、マルチメディアデータ、ＭＰＥＧ（Moving Picture Experts Group）規格のセクションデータ、ファイル、ディレクトリ、ＭＰＥＧ  ＤＳＭ−ＣＣ（Digital Storage Media Command and Control）規格のＭｏｄｕｌｅあるいは前記規格のＯｂｊｅｃｔの取得要求であっても良い。
【００２２】
本構成によれは、本発明のマルチメディアデータ送信装置は、前記マルチメディアデータ受信装置の要求に応じて、マルチメディアデータ、ＭＰＥＧ規格のセクションデータ、ファイル、ディレクトリ、ＭＰＥＧ  ＤＳＭ−ＣＣ規格のＭｏｄｕｌｅあるいは前記規格のＯｂｊｅｃｔを送信することができる。
【００２３】
また、前記要求受信部が前記マルチメディアデータ受信装置から受け取る要求メッセージは、データの種類、データの識別子、およびマルチメディアデータの区間のうち、少なくとも何れかひとつを指定しても良い。
【００２４】
本構成によれば、本発明のマルチメディアデータ送信装置は、前記マルチメディアデータ受信装置からより明確に指定されたデータを送信することが可能となる。
【００２５】
また、前記情報送信部は、前記マルチメディアデータ受信装置からの要求メッセージに応じて、前記要求メッセージに対応するマルチメディアデータ、ＭＰＥＧ（Moving Picture Experts Group）規格のセクションデータ、ファイル、ディレクトリ、ＭＰＥＧ  ＤＳＭ−ＣＣ（Digital Storage Media Command and Control）規格のＭｏｄｕｌｅまたは前記規格のＯｂｊｅｃｔを送信しても良い。
【００２６】
本構成によれば、本発明のマルチメディアデータ送信装置は、前記マルチメディアデータ受信装置からの要求に応じて、データ放送を再生するために必要なデータを送信することができる。
【００２７】
また、前記情報送信部は、前記マルチメディアデータ受信装置から要求メッセージが受信されたときに、前記イベント情報管理部が管理するデータを参照することにより、前記要求メッセージに応じたデータを選択し送信しても良い。
【００２８】
本構成によれば、マルチメディアデータが含む更新などのイベントを反映したマルチメディアデータをマルチメディアデータ受信装置へ送信することができる。
【００２９】
また、前記イベント情報管理部は、さらに、該第１のマルチメディアデータに含まれるデータ放送を再生するための情報を管理しても良い。
【００３０】
本構成によれば、イベント情報管理部が必要なデータを含めて管理することにより、送信要求受信時に該第１のマルチメディアデータから該要求メッセージに応じたデータを抽出することなく、必要なデータを送信することが可能となる。
【００３１】
また、前記情報送信部は、前記マルチメディアデータ受信装置からの要求により、前記イベント情報管理部が保持するイベント情報の管理情報を前記マルチメディアデータ受信装置へ送信しても良い。
【００３２】
本構成によれば、マルチメディアデータ受信装置が、再生に先立ってイベント情報を知ることが可能となり、マルチメディアデータ受信装置がイベント情報やデータ放送の再生に必要な情報やそれを取得するタイミングを判断することが可能となる。
【００３３】
また、本発明のマルチメディアデータ受信装置は、マルチメディアデータ送信装置からマルチメディアデータと、該マルチメディアデータの関連情報を受信して前記マルチメディアデータを再生するマルチメディアデータ受信装置であって、前記関連情報は、前記マルチメディアデータに関連するＭＰＥＧ規格のセクションデータ、ファイル、ディレクトリ、ＭＰＥＧ  ＤＳＭ−ＣＣ（Moving Picture Experts Group   Digital Storage Media Command and Control）規格のＭｏｄｕｌｅ、前記規格のＯｂｊｅｃｔ、または、該マルチメディアデータにおいて発生するイベント及びイベント発生のタイミングを表現するイベント情報であり、受信した関連情報の種類に応じた処理によって、前記マルチメディアデータの再生を行う。
【００３４】
本構成によれば、マルチメディアデータ送信装置が録画したコンテンツの再生及び該コンテンツのデータ放送の再生を、マルチメディアデータ受信装置上で行うことが可能となる。
【００３５】
また、本発明のマルチメディアデータ受信装置は、前記イベント情報を受信した場合、前記受信したイベント情報の内容に応じて、受信済みの前記マルチメディアデータもしくは前記関連情報を削除することにより、または、前記マルチメディアデータ送信装置に要求して新たなマルチメディアデータもしくは関連情報を受信することにより、前記マルチメディアデータ受信装置が保持する前記マルチメディアデータもしくは前記関連情報の更新を行っても良い。
【００３６】
本構成によれば、イベントに応じて、前記マルチメディアデータもしくは前記関連情報を正しく更新することが可能となる。
【００３７】
また、本発明のマルチメディアデータ受信装置は、前記マルチメディアデータ送信装置に要求することにより、前記関連情報を受信しても良い。
【００３８】
本構成によれば、マルチメディアデータ受信装置は、該関連情報を取得するタイミングを制御することが可能となる。
【００３９】
また、本発明のマルチメディアデータ受信装置は、さらに、前記マルチメディアデータ送信装置が保持する前記イベント情報の管理情報を受信し、受信した前記管理情報を参照することにより、前記イベントに応じて必要となるデータを判定し、前記必要となるデータを前記マルチメディアデータ送信装置に要求することによって受信しても良い。
【００４０】
本構成によれば、マルチメディアデータ受信装置がイベント情報やデータ放送の再生に必要な情報やそれを取得するタイミングを判断することが可能となる。
【００４１】
また、本発明のマルチメディアデータ受信装置は、さらに、Ｊａｖａアプリケーションを実行するＪａｖａ（登録商標）実行手段を備え、前記Ｊａｖａアプリケーションからの指示により、マルチメディアデータ、あるいは、前記マルチメディアデータの関連情報を取得しても良い。
【００４２】
本構成によれば、Ｊａｖａアプリケーションの要求に応じたデータ放送の再生を行うことが可能となる。
【発明の効果】
【００４３】
以上述べたように、本発明によれば、放送で受信したオーディオ、ビデオおよびＭＰＥＧ規格のセクションなど付加情報を含むマルチメディアデータを蓄積し、マルチメディアデータ受信装置からの要求メッセージに応じて、前記蓄積されたマルチメディアデータを、ネットワークを経由して前記マルチメディアデータ受信装置へ送信するマルチメディアデータ送信装置であって、前記蓄積されたマルチメディアデータにおいて発生するイベント及びイベント発生のタイミングを管理するイベント情報管理部と、前記要求メッセージによって指定されたマルチメディアデータおよびイベント情報を前記マルチメディア受信装置へ送信する情報送信部を備えることにより、マルチメディアデータに含まれる更新やデータ放送の時刻あるいは映像・音声との同期情報などタイミングに関連するイベント情報を管理し、それを前記マルチメディアデータ受信装置へ送信することができる。
【００４４】
２００７年４月５日に出願された、明細書と図面と請求項とを含む米国仮出願第６０／９１０，２６４号と、２００７年１１月１４日に出願された、明細書と図面と請求項とを含む米国仮出願第６０／９８７，８６５号とを本出願に引用して援用する。
【図面の簡単な説明】
【００４５】
【図１】図１は、本発明の実施の形態におけるマルチメディアコンテンツ通信システムの構成図である。
【図２】図２は、本発明の実施の形態おけるマルチメディアデータ送信装置１０１の構成図である。
【図３】図３は、入力部２０１をフロントパネルで構成した場合の外観の一例を示す図である。
【図４】図４は、本発明の実施の形態におけるマルチメディアデータ送信装置１０１が保存するプログラム構成の一例を示す構成図である。
【図５Ａ】図５Ａは、本発明に係る画面表示の一例を示す図である。
【図５Ｂ】図５Ｂは、本発明に係る画面表示の他の例を示す図である。
【図６】図６は、本発明に係る第２メモリ２０３が保存する情報の一例を示す図である。
【図７】図７は、本発明に係る第２メモリ２０３が保存する情報の一例を示す図である。
【図８Ａ】図８Ａは、本発明に係る第２メモリ２０３が保存する情報の一例を示す図である。
【図８Ｂ】図８Ｂは、本発明に係る第２メモリ２０３が保存する情報の他の例を示す図である。
【図８Ｃ】図８Ｃは、本発明に係る第２メモリ２０３が保存する情報の他の例を示す図である。
【図９】図９は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図１０】図１０は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図１１】図１１は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図１２】図１２は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図１３】図１３は、本発明の実施の形態におけるマルチメディアデータ送信装置１０１が保存するプログラム構成の構成図の一例を示す図である。
【図１４】図１４は、本発明に係る蓄積管理ライブラリ１３０２の構成の一例を示す図である。
【図１５Ａ】図１５Ａは、本発明に係る画面表示の一例を示す図である。
【図１５Ｂ】図１５Ｂは、本発明に係る画面表示の他の例を示す図である。
【図１６】図１６は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図１７Ａ】図１７Ａは、ＮＰＴ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｓｃｒｉｐｔｏｒが伝送する情報を示す図である。
【図１７Ｂ】図１７Ｂは、Ｓｔｒｅａｍ  Ｅｖｅｎｔ  Ｄｅｓｃｒｉｐｔｏｒが伝送する情報を示す図である。
【図１８Ａ】図１８Ａは、本発明に係る蓄積管理ライブラリ１３０２の構成の一例を示す図である。
【図１８Ｂ】図１８Ｂは、本発明に係る蓄積管理ライブラリ１３０２の処理の一例を示す図である。
【図１９】図１９は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図２０】図２０は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図２１】図２１は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図２２】図２２は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図２３Ａ】図２３Ａは、本発明に係るネットワークライブラリ４０５ｅの構成の一例を示す図である。
【図２３Ｂ】図２３Ｂは、本発明に係るネットワークライブラリ４０５ｅの処理の一例を示す図である。
【図２４】図２４は、本発明の実施の形態おけるマルチメディアデータ受信装置１０２の構成図を示す図である。
【図２５】図２５は、本発明の実施の形態におけるマルチメディアデータ受信装置１０２が保存するプログラム構成の構成図である。
【図２６】図２６は、本発明に係る第１メモリ２４０２あるいは第２メモリ２４０３が保存する情報の一例を示す図である。
【図２７】図２７は、本発明に係る画面表示の一例を示す図である。
【図２８】図２８は、本発明に係るネットワークライブラリ２５０４ｄの構成の一例を示す図である。
【図２９】図２９は、ＤＳＭ−ＣＣの構成図である。
【図３０】図３０は、本発明に係る蓄積管理ライブラリ１３０２の構成の一例を示す図である。
【図３１】図３１は、本発明に係る蓄積管理ライブラリ１３０２の構成の一例を示す図である。
【図３２】図３２は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図３３Ａ】図３３Ａは、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図３３Ｂ】図３３Ｂは、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図３４】図３４は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図３５Ａ】図３５Ａは、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図３５Ｂ】図３５Ｂは、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図３６Ａ】図３６Ａは、本発明に係るＤＳＭ−ＣＣ  ＭｏｄｕｌｅとＤＳＭ−ＣＣ  Ｏｂｊｅｃｔの一例を示す図である。
【図３６Ｂ】図３６Ｂは、本発明に係るファイルシステムの一例を示す図である。
【図３６Ｃ】図３６Ｃは、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図３７】図３７は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図３８】図３８は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図３９】図３９は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図４０】図４０は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図４１】図４１は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図４２】図４２は、本発明に係るＤＳＭ−ＣＣ  ＭｏｄｕｌｅとＤＳＭ−ＣＣ  Ｏｂｊｅｃｔの一例を示す図である。
【図４３】図４３は、本発明に係る第１メモリ２０２あるいは第２メモリ２０３が保存する情報の一例を示す図である。
【図４４】図４４は、本発明に係るネットワークライブラリ２５０４ｄの構成の一例を示す図である。
【図４５】図４５は、本発明の実施の形態におけるマルチメディアデータ送信装置１０１が保存するプログラム構成の構成図である。
【図４６】図４６は、本発明の実施の形態における第２メモリ２０３に蓄積されたデータの構成の一例を示す図である。
【図４７】図４７は、本発明の実施の形態におけるマルチメディアデータの属性情報の一例を示す図である。
【図４８】図４８は、本発明の実施の形態における属性情報テーブルの一例を示す図である。
【図４９】図４９は、本発明の実施の形態におけるＵＲＩテーブルの一例を示す図である。
【図５０】図５０は、Ｒｅｃ４０５ｊ及びネットワークライブラリ４０５ｅの内部構成図である。
【図５１】図５１は、Ｒｅｃ４０５ｊが保存する変化点情報の一例を示す図である。
【図５２】図５２は、本発明の実施の形態おけるマルチメディアデータ受信装置１０２の構成図である。
【図５３】図５３は、本実施の形態におけるマルチメディアデータ受信装置１０２が保存するプログラム構成の構成図である。
【図５４】図５４は、ネットワークライブラリ２００４ｄの内部構成図である。
【発明を実施するための形態】
【００４６】
以下本発明の実施の形態について、図面を参照しながら説明する。
【００４７】
（実施の形態１）
図１は、本発明の実施の形態におけるマルチメディアコンテンツ通信システムの構成図である。図１において、１０１は本発明におけるマルチメディアデータ送信装置を、１０２は本発明におけるマルチメディアデータ受信装置を、１０３はネットワークを、１０４はこれらによって構成されるマルチメディアコンテンツ通信システムを表す。マルチメディアデータ送信装置１０１、マルチメディアデータ受信装置１０２は、ネットワーク１０３に接続されており、ネットワーク１０３を介して相互に通信可能である。また、１０５はケーブルテレビの放送局を、１０６は、マルチメディアデータ送信装置１０１と放送局１０５を結ぶケーブルを表す。
【００４８】
本実施の形態におけるマルチメディアデータ送信装置１０１は、ネットワークインタフェースと、マルチメディアデータを蓄積する蓄積手段を備えた、デジタル放送を受信するＣＡＴＶ  ＳＴＢ（Ｓｅｔ  Ｔｏｐ  Ｂｏｘ）である。なお、ここでは対象となる放送システムとしてケーブルシステムを用いて説明しているが、本発明はデジタル放送の放送システムに依存しないため、衛星放送や地上波放送など他のシステムであっても適用可能である。マルチメディアデータ送信装置１０１は、ケーブル１０６を介して放送局１０５に接続されている。そして、マルチメディアデータ送信装置１０１は、放送局１０５から受信したデジタル放送コンテンツのマルチメディアデータを、蓄積手段に蓄積する。また、ネットワークインタフェースを通して、ネットワーク１０３に接続されている。そして、ネットワーク１０３を通じて送信された、マルチメディアデータ受信装置１０２からの要求を受信する。そして、要求に応じて受信したデジタル放送のコンテンツ、もしくは、蓄積しているコンテンツごとの情報や属性もしくはマルチメディアデータを、ネットワーク１０３を通じてマルチメディアデータ受信装置１０２へ送信するものである。
【００４９】
なお、マルチメディアデータ送信装置１０１が蓄積手段に蓄積するデジタル放送コンテンツは、ＭＰＥＧ２−ＴＳ形式のデータである。
【００５０】
マルチメディアデータ受信装置１０２は、ユーザの要求により、マルチメディアデータ送信装置１０１へ提供可能なコンテンツの一覧送信要求を送信する。そして、マルチメディアデータ送信装置１０１から、その返答として、コンテンツの一覧を受信しユーザに提示する。さらに、ユーザが選択したコンテンツについて、そのマルチメディアデータの送信要求をマルチメディアデータ送信装置１０１へ送信する。その返答として、マルチメディアデータを受信し再生してユーザに提示する。また、ユーザから早送りや巻き戻しなどの特殊再生の要求を受け付けると、一旦マルチメディアデータの通信を停止し、改めて特殊再生に必要な部分の送信要求を連続して発行し、その都度マルチメディアデータを受信し再生することにより特殊再生を実現する方法や、ユーザが要求した特殊再生の再生スピードをマルチメディアデータ送信装置１０１へ送信し、マルチメディアデータ送信装置１０１は要求された再生スピードに応じて該マルチメディアデータの特定区間を連続的に選択し、選択したデータでストリームを生成して、マルチメディアデータ受信装置１０２へ送信するといった方法などにより、特殊再生を実現する。
【００５１】
ネットワーク１０３は、家庭内に施設されたホームネットワークであり、イーサネット、無線ＬＡＮなどによって構成されたＩＰネットワークである。
【００５２】
以下、マルチメディアデータ送信装置１０１と、マルチメディアデータ受信装置１０２の通信とそれぞれの動作について説明する。
【００５３】
マルチメディアデータのサーバとなるマルチメディアデータ送信装置１０１は、ネットワーク１０３に接続されると、サービスを提供可能なサーバであることを、ネットワーク１０３にブロードキャストすることにより、他の装置に通知する。更に、ネットワーク１０３に接続された他の装置からの要求により、提供するサービスと、そのアクセスの方法を、要求元の装置に送信する。また、クライアントとなるマルチメディアデータ受信装置１０２は、ネットワーク１０３に接続されると、ネットワーク１０３に接続されたサーバ装置を検索し、各サーバ装置がどのような機能を持っているかを取得する。この通信は、ＤＬＮＡと同様に、ＵＰｎＰ  ＤＡ（Ｄｅｖｉｃｅ  Ａｒｃｈｉｔｅｃｔｕｒｅ）で定義されている方法により行えるため、詳細な説明は省略する。これにより、マルチメディアデータ受信装置１０２は、マルチメディアデータ送信装置１０１がネットワーク１０３に接続されているマルチメディアサーバであることを認識できる。
【００５４】
以下、マルチメディアデータ送信装置１０１とマルチメディアデータ受信装置１０２との間で行われるマルチメディアデータの通信について、順を追って説明する。
【００５５】
まず、マルチメディアデータ受信装置１０２は、マルチメディアデータ送信装置１０１に対し、提供可能なコンテンツの一覧送信要求を発行する。そして、マルチメディアデータ送信装置１０１は、その要求を受け、提供可能コンテンツを検索し、その一覧を、マルチメディアデータ受信装置１０２へ返信する。この通信は、ＵＰｎＰ  ＡＶ  ＣＤＳ（Ｃｏｎｔｅｎｔ  Ｄｉｒｅｃｔｏｒｙ  Ｓｅｒｖｉｃｅ）のＢｒｏｗｓｅもしくはＳｅａｒｃｈによって行えるものであり、その詳細説明は省略する。
【００５６】
マルチメディアデータ送信装置１０１は、マルチメディアデータ受信装置１０２から提供可能なコンテンツの一覧送信要求を受信すると、蓄積手段に蓄積したコンテンツの一覧を返信する。送信する一覧は、ＵＰｎＰ  ＡＶもしくはＤＬＮＡにて定義されているものが利用できるため、詳細説明は省略する。
【００５７】
提供コンテンツ一覧を受信したマルチメディアデータ受信装置１０２は、その一覧をユーザに提示する。そして、ユーザが選択したコンテンツのマルチメディアデータの送信を、マルチメディアデータ送信装置１０１へ要求する。マルチメディアデータ送信装置１０１は、要求されたコンテンツデータを蓄積手段から読み出し、マルチメディアデータ受信装置１０２へ送信する。マルチメディアデータの通信は、ＤＬＮＡにて必須プロトコルとなっているＨＴＴＰを用いて通信するものとする。
【００５８】
ここで、ユーザから早送りや巻き戻し、スローといった特殊再生を要求された場合、マルチメディアデータ受信装置は要求された特殊再生を実行する。これは、マルチメディアデータ受信装置１０２が、要求された特殊再生の種類に応じて、必要なデータ区間を判定し、これらの区間のみのデータを受信して再生、表示することを繰り返すことにより、特殊再生を行う方法や、ユーザが要求した特殊再生の再生スピードをマルチメディアデータ送信装置１０１へ送信し、マルチメディアデータ送信装置１０１が要求された再生スピードに応じて該マルチメディアデータの特定区間を連続的に選択し、選択したデータによりストリームを生成し、マルチメディアデータ受信装置１０２へ送信するといった方法により実現する。このため、いずれの方法においても特殊再生を行う場合は、マルチメディアデータ受信装置１０２は、該マルチメディアデータの全てのＴＳパケットを取得することができない場合がある。そのため、データ放送の再生を実現するために、課題が生じる。
【００５９】
一般に、放送局１０５は、データ放送用データを繰返し送出するカルーセル方式で伝送する。カルーセル方式については、ＩＳＯ／ＩＥＣ国際規格１３８１８−６“ＭＰＥＧ−２  Ｄｉｇｉｔａｌ  Ｓｔｏｒａｇｅ  Ｍｅｄｉａ  Ｃｏｍｍａｎｄ  ａｎｄ  Ｃｏｎｔｒｏｌ”（以下、ＤＳＭ−ＣＣ）により知られている。
【００６０】
このとき放送局１０５は、ストリーム中の構造情報やアプリケーション情報を運ぶセクションデータとその更新情報、更に、データ放送で用いるデータ放送用データとその更新情報、更に、映像や音声とデータ放送の同期を実現するための時間情報や同期のタイミングを通知する情報などのデータ放送関連情報を送信している。更に、放送局はこれらのデータ放送関連情報の各情報の関連を考慮し、該当情報を適切なタイミングでストリーム中にエンコードし送出する。
【００６１】
そのため、マルチメディアデータ送信装置１０１が、マルチメディアデータ受信装置１０２へストリームを送出する場合、放送局１０５より受信したタイミングと同じタイミングでデータ放送用データを送出する必要がある。しかしながら、上述したようにユーザが特殊再生を行った場合、ストリームの一部を取得できないため、マルチメディアデータ受信装置１０２は、データ放送の再生を行うことができない。なお、データ放送を実現するために必要なデータ放送関連情報の一例として、以下の情報がある。
【００６２】
データ放送用データ：実データを取得・構成するために必要な情報
・ストリーム中の構造情報やアプリケーション情報
・データ放送用データの構造情報
・データ放送の再生中に使用される実データ
イベント情報:タイミングに関連する情報
・ストリーム中の構造情報、アプリケーション情報、データ放送用データの構造情報の更新情報と更新タイミング
・映像や音声とデータ放送の同期を実現するための時間情報や同期のタイミング
【００６３】
そのため、マルチメディアデータ受信装置１０２がデータ放送を実現するためには、データ放送関連情報として、上記データ放送用データとイベント情報を取得する必要がある。
【００６４】
そこで本実施の形態では、マルチメディアデータ送信装置１０１は、タイミングが重要となるイベント情報を、マルチメディアデータ受信装置１０２に要求された該コンテンツの特殊再生用ストリームに含む方法を説明する。なお、ここではデータ放送用データは、該コンテンツのストリームから取得する方法でも、後述の実施の形態２で説明する方法であってもよい。
【００６５】
更に、実施の形態２では、該コンテンツのデータ放送関連情報をマルチメディアデータ受信装置１０２から要求し取得する方法を説明する。
【００６６】
更に、実施の形態３では、実施の形態１、２ではマルチメディアデータ送信装置１０１が管理していたイベント情報の管理情報あるいはデータ放送用データの管理情報あるいは両方をマルチメディアデータ受信装置１０２へ提供し、マルチメディアデータ受信装置１０２がデータ放送関連情報の取得を行うタイミングを判断する方法を説明する。
【００６７】
また、マルチメディアデータ受信装置１０２は、前述した方法によって取得したデータ放送関連情報を用いてデータ放送を再生する。
【００６８】
以下、マルチメディアコンテンツ通信システム１０４を構成する、マルチメディアデータ送信装置１０１およびマルチメディアデータ受信装置１０２について、更に詳細に説明する。
【００６９】
まず、マルチメディアデータ送信装置１０１について説明する。
【００７０】
図２は、本実施の形態におけるマルチメディアデータ送信装置１０１を構成する構成要素の関係を示したブロック図であり、入力部２０１、第１メモリ２０２、第２メモリ２０３、受信部２０４、多重分離手段２０５、デスクランブラ２０６、ＴＳデコーダ２０７、映像出力部２０８、音声出力部２０９、ＴＳマルチプレクサ２１０、ネットワーク部２１１、ＣＰＵ２１２で構成される。
【００７１】
入力部２０１は、フロントパネルやリモコン受光器等で構成され、ユーザからのチャンネル選択等の指示を受け付ける。図３は、フロントパネルで入力部２０１を構成した場合の一例である。３００はフロントパネルであり、上カーソルボタン３０１、下カーソルボタン３０２、左カーソルボタン３０３、右カーソルボタン３０４、ＯＫボタン３０５、取消ボタン３０６、ＥＰＧボタン３０７、シアターボタン３０８の８つのボタンを備えている。ユーザがボタンを押下すると、押下されたボタンの識別子が、ＣＰＵ２１２に通知される。
【００７２】
第１メモリ２０２は、ＲＡＭ等で構成され、ＣＰＵ２１２が一時的にデータを保存する際に使用される。
【００７３】
第２メモリ２０３は、フラッシュメモリ、ハードディスク等で電源が停止しても情報を保持可能なデバイスで構成され、ＣＰＵ２１２が実行するプログラムを保存する。第２メモリは、ＳＤメモリカード等の取り外し可能な記憶デバイスを用いていてもよい。
【００７４】
受信部２０４は、ＣＡＴＶ局からのケーブルに接続され放送波を受信し、ＣＰＵ２１２から指定された周波数にチューニングし、ＭＰＥＧトランスポートストリームを抽出して、多重分離手段２０５に引き渡す。
【００７５】
多重分離手段２０５は、受信部２０４からＭＰＥＧトランスポートストリームを受け取り、ＣＰＵ２１２から指定された情報を抽出しＣＰＵ２１２に引き渡す。またＭＰＥＧトランスポートストリームをそのままデスクランブラ２０６に引き渡す。
【００７６】
デスクランブラ２０６は、多重分離手段２０５から与えられたスクランブルされているＭＰＥＧトランスポートストリームをデスクランブル（＝復号）し、ＴＳデコーダ２０７に引き渡す。デスクランブラ２０６は、マルチメディアデータ送信装置１０１に内蔵されたモジュールでも良いし、北米ケーブル受信機で導入されているＣａｂｌｅＣＡＲＤ（登録商標）でも実施可能である。ＣａｂｌｅＣＡＲＤの仕様は米国ＣａｂｌｅＬａｂｓが策定したＣａｂｌｅＣＡＲＤ  Ｉｎｔｅｒｆａｃｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎに記載されており、ここでは説明を省略する。
【００７７】
ＴＳデコーダ２０７は、ＣＰＵ２１２から音声データ、映像データ、ＰＳＩ／ＳＩ情報などのセクションデータの識別子を受け取る。さらに、デスクランブラ２０６から受け取ったデスクランブルされたストリームから、受け取った音声データ、映像データ、ＰＳＩ／ＳＩ情報などのセクションデータの識別子に対応するデータを抽出する、抽出した映像データを映像出力部２０８に、音声データを音声出力部２０９に引き渡す。また、その両方と、セクションデータを、ＴＳマルチプレクサ２１０に引き渡す。ＴＳマルチプレクサ２１０には、ＴＳパケットの形式で引き渡しても良いし、ＴＳパケットからデータを抽出し、抽出したデータだけを引き渡しても良い。
【００７８】
映像出力部２０８は映像出力端子を含み、受け取った映像データを端子に対応した映像データに変換して出力する。端子の例としては、コンポジットケーブル端子などがある。
【００７９】
音声出力部２０９は音声出力端子を含み、受け取った音声データを端子に対応した音声データに変換して出力する。端子の例としては、イヤホン端子や、コンポジットケーブル端子などがある。
【００８０】
ＴＳマルチプレクサ２１０は、受け取った映像データ、音声データ、セクションデータからＭＰＥＧ２トランスポートストリームを構成し、該ＭＰＥＧ２トランスポートストリームをネットワーク部２１１に引き渡す。ＰＳＩ／ＳＩ情報は必要に応じて書き換えられる。書き換えの一例として、ＴＳマルチプレクサ２１０は、ＰＡＴを、指定されたコンテンツのみの情報を含むように書き換えることなどがある。このとき、ＴＳパケットの形式で引き渡された場合には、引き渡されたＴＳパケットをそのまま順に並べてＭＰＥＧ２トランスポートストリームを構成しても良い。
【００８１】
ネットワーク部２１１は、ネットワークインタフェースを含み、ＣＰＵ２１２から受け取ったデータを、ネットワークインタフェースが接続されたネットワークの物理メディアに応じた信号に変換して出力する。また、ネットワークインタフェースから信号を受信し、ＩＰネットワークで規定されたパケットに変換して、ＣＰＵ２１２へ引き渡す。
【００８２】
ＣＰＵ２１２は、第２メモリ２０３が記憶するプログラムを実行することで、受信部２０４、多重分離手段２０５、デスクランブラ２０６、ＴＳデコーダ２０７、ＴＳマルチプレクサ２１０、ネットワーク部２１１を制御する。
【００８３】
図４は、第２メモリ２０３に記憶され、ＣＰＵ２１２に実行されるプログラムの構成図の一例である。
【００８４】
プログラム４００は、複数のサブプログラムで構成され、具体的にはＯＳ４０１、ＥＰＧ４０２、ＪａｖａＶＭ４０３、サービスマネージャ４０４、Ｊａｖａライブラリ４０５で構成される。
【００８５】
ＯＳ４０１は、マルチメディアデータ送信装置１０１の電源が投入されると、ＣＰＵ２１２が起動するサブプログラムである。ＯＳは、オペレーティングシステムの略であり、Ｌｉｎｕｘ等が一例である。ＯＳ４０１は、他のサブプログラムを平行して実行するカーネル４０１ａ及びライブラリ４０１ｂで構成される公知の技術の総称であり、詳細な説明は省略する。本実施の形態においては、ＯＳ４０１のカーネル４０１ａは、ＥＰＧ４０２とＪａｖａＶＭ４０３をサブプログラムとして実行する。また、ライブラリ４０１ｂは、これらサブプログラムに対して、マルチメディアデータ送信装置１０１が保持する構成要素を制御するための複数の機能を提供する。
【００８６】
本実施の形態では、ライブラリ４０１ｂは機能の一例として、チューナ４０１ｂ１、限定解除４０１ｂ２、ＡＶ再生４０１ｂ３、ＮＥＴ４０１ｂ４を含む。
【００８７】
チューナ４０１ｂ１は、他のサブプログラムやＪａｖａライブラリ４０５のＴｕｎｅｒ４０５ｃから周波数を含むチューニング情報を受け取り、受信部２０４に引き渡す。受信部２０４は与えられたチューニング情報に基づき復調処理を行い、復調したデータを多重分離手段２０５に引き渡すことができる。この結果、他のサブプログラム及びＪａｖａライブラリ４０５のＴｕｎｅｒ４０５ｃはライブラリ４０１ｂを通して受信部２０４を制御することができる。
【００８８】
限定解除４０１ｂ２は、他のサブプログラムやＪａｖａライブラリ４０５のＣＡ４０５ｄから情報を受け取り、デスクランブラ２０６に引き渡す。
【００８９】
ＡＶ再生４０１ｂ３は、他のサブプログラムやＪａｖａライブラリ４０５のＪＭＦ４０５ａから、音声のパケットＩＤと映像のパケットＩＤを受け取る。受け取った音声のパケットＩＤと映像のパケットＩＤを、ＴＳデコーダ２０７に与える。この結果、ＴＳデコーダ２０７は与えられたパケットＩＤに基づいて、フィルタリングを行い、映像・音声の再生を実現する。
【００９０】
ＮＥＴ４０１ｂ４は、他のサブプログラムやＪａｖａライブラリ４０５のネットワークライブラリ４０５ｅから受け取ったデータを、ＩＰネットワークで規定されるアプリケーション層より下のプロトコルのパケットを作成する。アプリケーション層より下のプロトコルとは、例えばＴＣＰパケット、ＵＤＰパケット、ＩＰパケットなどである。これをネットワーク部２１１に引き渡すことで、ネットワーク１０３を介して他の機器にメッセージおよびデータを送信する。また、ネットワーク１０３を介して他の機器からメッセージを受信したときに、他のサブプログラムやＪａｖａライブラリ４０５のネットワークライブラリ４０５ｅに、アプリケーション層のプロトコルのパケットに変換して引き渡す。アプリケーション層のプロトコルとは、例えば、ＨＴＴＰやＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）などである。
【００９１】
ＥＰＧ４０２は、ユーザに番組一覧を表示及び、ユーザからの入力を受け付ける番組表示部４０２ａと、チャンネル選局を行う再生部４０２ｂで構成される。ここで、ＥＰＧはＥｌｅｃｔｒｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅの略である。ＥＰＧ４０２は、マルチメディアデータ送信装置１０１の電源が投入されると、カーネル４０１ａによって起動される。起動されたＥＰＧ４０２の内部では、番組表示部４０２ａと再生部４０２ｂが同時に起動される。番組表示部４０２ａは起動されると、マルチメディアデータ送信装置１０１の入力部２０１を通して、ユーザからの入力を待つ。ここで、入力部２０１が図３で示されるフロントパネルで構成されている場合、ユーザが、入力部２０１のＥＰＧボタン３０７を押下すると、ＥＰＧボタンの識別子がＣＰＵ２１２に通知される。ＣＰＵ２１２上で動作するサブプログラムであるＥＰＧ４０２の番組表示部４０２ａは、この識別子を受け取り、番組情報表示データを作成し、図示していないモニタ出力手段によりモニタ５１０に出力する。モニタ５１０は、マルチメディアデータ送信装置１０１が備えるものであっても良いし、マルチメディアデータ送信装置１０１とコンポジットケーブルやＨＤＭＩケーブルなどで接続されたテレビであっても良い。モニタ５１０は、受信した番組情報表示データを表示する。
【００９２】
図５Ａ及び図５Ｂは、モニタ５１０に表示された番組表の一例である。図５Ａを参照して、モニタ５１０には、格子状に番組情報が表示されている、列５０１には、時刻情報が表示されている。列５０２には、チャンネル名「チャンネル１」と、列５０１の時刻に対応する時間帯に放映される番組が表示されている。「チャンネル１」では、９：００〜１０：３０に番組「ニュース９」が放映され、１０：３０〜１２：００は「映画ＡＡＡ」が放映されることを表す。列５０３も列５０２同様、チャンネル名「チャンネル２」と、列５０１の時刻に対応する時間帯に放映される番組が表示されている。９：００〜１１：００に番組「映画ＢＢＢ」が放映され、１１：００〜１２：００は「ニュース１１」が放映される。５３０は、カーソルである。カーソル５３０は、フロントパネル３００の左カーソル３０３と右カーソル３０４を押下すると移動する。図５Ａの状態で、右カーソル３０４を押下すると、カーソル５３０は右に移動し、図５Ｂのようになる。また、図５Ｂの状態で、左カーソル３０３を押下すると、カーソル５３０は左に移動し、図５Ａのようになる。
【００９３】
図５Ａの状態で、フロントパネル３００のＯＫボタン３０５が押下されると、番組表示部４０２ａは、「チャンネル１」の識別子を再生部４０２ｂに通知する。図５Ｂの状態で、フロントパネル３００のＯＫボタン３０５が押下されると、番組表示部４０２ａは、「チャンネル２」の識別子を再生部４０２ｂに通知する。
【００９４】
また、番組表示部４０２ａは、表示する番組情報を、多重分離手段２０５を通して定期的に、第２メモリ２０３に記憶しておく。一般的に、放送局からの番組情報の取得は時間が掛かる。入力部２０１のＥＰＧボタン３０７が押下された時、第２メモリ２０３に予め保存された番組情報を表示することで、素早く番組表を表示することができる。
【００９５】
図６は、第２メモリ２０３に記憶している番組情報の一例である。番組情報は表形式で格納されている。列６０１は、チャンネルの識別子である。列６０２は、番組名である。列６０３は番組の放送開始時間、列６０４は放送終了時間である。列６０５は、番組の音声種別を表しており、モノラル音声、ステレオ音声、５．１チャンネル音声をそれぞれ「モノラル」、「ステレオ」、「５．１」と表記している。列６０６は、番組の種別を表している。通常番組は空欄であり、「映画」は映画、「スポ」はスポーツ番組を表す。行６１１〜６１４の各行は、それぞれひとつの番組情報を表す。この例では、ひとつの番組情報は、チャンネルの識別子、番組名、放送開始時間、放送終了時間、番組の音声種別の組となる。例えば、行６１１はチャンネル識別子が「１」、番組名が「ニュース９」、放送開始時間が「９：００」、放送終了時間が「１０：３０」、音声種別が「モノラル」、番組の種別は「通常」を含む組となっている。
【００９６】
再生部４０２ｂは、受け取ったチャンネルの識別子を用いて、チャンネルを再生する。すなわちチャンネルを構成する映像と音声を再生する。チャンネルの識別子とチャンネルの関係は、チャンネル情報として、第２メモリ２０３に予め格納されている。図７は第２メモリ２０３に格納されているチャンネル情報の一例である。チャンネル情報は表形式で格納されている。列７０１は、チャンネルの識別子である。列７０２は、チャンネル名である。列７０３はチューニング情報である。ここで、チューニング情報は周波数や転送レート、符号化率などを含み、受信部２０４に与える値である。列７０４はプログラムナンバーである。プログラムナンバーとは、ＭＰＥＧ２規格で規定されているＰＭＴを識別するための番号である。ＰＭＴに関しては、後述する。行７１１〜７１４の各行は、各チャンネルの識別子、チャンネル名、チューニング情報の組となる。行７１１は識別子が「１」、チャンネル名が「チャンネル１」、チューニング情報に周波数「１５０ＭＨｚ」、プログラムナンバーが「１０１」を含む組となっている。再生部４０２ｂは、チャンネルの再生を行うため、受け取ったチャンネルの識別子をそのままサービスマネージャ４０４に引き渡す。
【００９７】
また、再生部４０２ｂは、再生中に、ユーザがフロントパネル３００の上カーソル３０１と下カーソル３０２を押下すると、入力部２０１からＣＰＵ２１２を通して、押下された通知を受け取り、再生しているチャンネルを変更する。上カーソル３０１を押下すると、現在再生中のチャンネルよりもひとつ小さいチャンネル識別子を持つチャンネルを再生し、また下カーソル３０２を押下すると、現在再生中のチャンネルよりもひとつ大きいチャンネル識別子を持つチャンネルを再生する。まず、再生部４０２ｂは、第２メモリ２０３に現在再生中のチャンネルの識別子を記憶する。図８Ａ、図８Ｂ及び図８Ｃは、第２メモリ２０３に保存しているチャンネルの識別子の例である。図８Ａでは識別子「３」が記憶されており、図７を参照し、チャンネル名「ＴＶ  ３」のチャンネルが再生中であることを示す。図８Ａの状態で、ユーザが上カーソル３０１を押下すると再生部４０２ｂは、図７のチャンネル情報を参照し、表中で現在再生中のチャンネルよりもひとつ小さい識別子を持つチャンネルであるチャンネル名「チャンネル２」のチャンネルに再生を切り変えるため、サービスマネージャ４０４にチャンネル名「チャンネル２」の識別子「２」を引き渡す。同時に、第２メモリ２０３に記憶されているチャンネル識別子「２」に書き換える。図８Ｂは、チャンネル識別子が書き換えられた状態を表す。また、図８Ａの状態で、ユーザが下カーソル３０２を押下すると再生部４０２ｂは、図７のチャンネル情報を参照し、表中で現在再生中のチャンネルよりもひとつ大きい識別子を持つチャンネルであるチャンネル名「ＴＶ  Ｊａｐａｎ」のチャンネルに再生を切り変えるため、サービスマネージャ４０４にチャンネル名「ＴＶ  Ｊａｐａｎ」の識別子「４」を引き渡す。同時に、第２メモリ２０３に記憶されているチャンネル識別子「４」に書き換える。図８Ｃは、チャンネル識別子が書き換えられた状態を表す。チャンネル識別子は、第２メモリ２０３に記憶されているので、マルチメディアデータ送信装置１０１の電源が切られた際も保存されている。
【００９８】
さらに再生部４０２ｂは、マルチメディアデータ送信装置１０１の電源が投入された際に、起動されると、第２メモリ２０３に記憶されているチャンネル識別子を読み出す。そして、そのチャンネル識別子をサービスマネージャに引き渡す。これにより、マルチメディアデータ送信装置１０１は、電源投入時に前回の稼動時に再生されていた最後のチャンネルの再生を開始することができる。
【００９９】
ＪａｖａＶＭ４０３は、Ｊａｖａ（登録商標）言語で記述されたプログラムを逐次解析し実行するＪａｖａバーチャルマシンである。Ｊａｖａ言語で記述されたプログラムはバイトコードと呼ばれる、ハードウェアに依存しない中間コードにコンパイルされる。Ｊａｖａバーチャルマシンは、このバイトコードを実行するインタープリタである。また、一部のＪａｖａバーチャルマシンは、バイトコードをＣＰＵ２１２が理解可能な実行形式に翻訳してから、ＣＰＵ２１２に引渡し、実行することも行う。ＪａｖａＶＭ４０３は、カーネル４０１ａに実行するＪａｖａプログラムを指定され起動される。本実施の形態では、カーネル４０１ａは、実行するＪａｖａプログラムとしてサービスマネージャ４０４を指定する。Ｊａｖａ言語の詳細は、書籍「Ｊａｖａ  Ｌａｎｇｕａｇｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ  ０−２０１−６３４５１−１）」等の多くの書籍で解説されている。ここでは、その詳細を省略する。また、ＪａｖａＶＭ自体の詳細な動作などは、「Ｊａｖａ  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ  ０−２０１−６３４５１―Ｘ）」等の多くの書籍で解説されている。ここでは、その詳細を省略する。
【０１００】
サービスマネージャ４０４は、Ｊａｖａ言語で書かれたＪａｖａプログラムであり、ＪａｖａＶＭ４０３によって逐次実行される。サービスマネージャ４０４は、ＪＮＩ（Ｊａｖａ  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅ）を通して、Ｊａｖａ言語で記述されていない他のサブプログラムを呼び出したり、または、呼び出されたりすることが可能である。ＪＮＩに関しても、書籍「Ｊａｖａ  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅ」等の多くの書籍で解説されている。ここでは、その詳細を省略する。
【０１０１】
まず、デジタル放送を受信し、受信したマルチメディアデータを再生する場合の処理について説明する。
【０１０２】
サービスマネージャ４０４は、ＪＮＩを通して、再生部４０２ｂよりチャンネルの識別子を受け取る。
【０１０３】
サービスマネージャ４０４は、最初にＪａｖａライブラリ４０５の中にあるＴｕｎｅｒ４０５ｃに、チャンネルの識別子を引き渡し、チューニングを依頼する。Ｔｕｎｅｒ４０５ｃは、第２メモリ２０３が記憶するチャンネル情報を参照し、チューニング情報を獲得する。今、サービスマネージャ４０４がチャンネルの識別子「２」をＴｕｎｅｒ４０５ｃに引き渡すと、Ｔｕｎｅｒ４０５ｃは、図７の行７１２を参照して、対応するチューニング情報「１５６ＭＨｚ」を獲得する。Ｔｕｎｅｒ４０５ｃは、ＯＳ４０１のライブラリ４０１ｂのチューナ４０１ｂ１を通して、受信部２０４にチューニング情報を引き渡す。受信部２０４は与えられたチューニング情報に従って放送局から送信されてきた信号を復調し、多重分離手段２０５に引き渡す。
【０１０４】
次にサービスマネージャ４０４は、Ｊａｖａライブラリ４０５の中にあるＣＡ４０５ｄにデスクランブルを依頼する。ＣＡ４０５ｄは、ＯＳ４０１のライブラリ４０１ｂの限定解除４０１ｂ２を通して復号に必要な情報をデスクランブラ２０６に与える。デスクランブラ２０６は、与えられた情報を元に、受信部２０４から与えられた信号を復号しＴＳデコーダ２０７に引き渡す。
【０１０５】
サービスマネージャ４０４は、Ｊａｖａライブラリ４０５の中にあるＪＭＦ４０５ａにチャンネルの識別子を与え、映像・音声の再生を依頼する。
【０１０６】
まず、最初にＪＭＦ４０５ａは、再生すべき映像と音声を特定するためのパケットＩＤをＰＡＴ、ＰＭＴから取得する。ＰＡＴやＰＭＴはＭＰＥＧ２規格で規定されている、ＭＰＥＧ２トランスポートストリーム内の番組構成を表現するテーブルであり、ＭＰＥＧ２トランスポートストリームに含まれるパケットのペイロードに埋め込まれて、音声や映像と共に送信されるものである。詳細は規格書を参照されたい。ここでは、概略のみ説明する。ＰＡＴは、Ｐｒｏｇｒａｍ  Ａｓｓｏｃｉａｔｉｏｎ  Ｔａｂｌｅの略で、パケットＩＤ「０」のパケットに格納され送信されている。ＪＭＦ４０５ａは、ＰＡＴを取得するため、ＯＳ４０１のライブラリ４０１ｂを通して、多重分離手段２０５にパケットＩＤ「０」を指定する。多重分離手段２０５がパケットＩＤ「０」でフィルタリングを行い、ＣＰＵ２１２に引き渡すことでＪＭＦ４０５ａは、ＰＡＴのパケットを収集する。図９は、収集したＰＡＴの情報の一例を模式的に表した表である。列９０１は、プログラムナンバーである。列９０２は、パケットＩＤである。列９０２のパケットＩＤはＰＭＴを取得するために用いられる。行９１１〜９１３は、チャンネルのプログラムナンバーと対応するパケットＩＤの組である。ここでは、三つのチャンネルが定義されている。行９１１はプログラムナンバー「１０１」とパケットＩＤ「５０１」の組が定義されている。今、ＪＭＦ４０５ａに与えられたチャンネルの識別子が「２」とすると、ＪＭＦ４０５ａは、図９の行９１２を参照して、対応するプログラムナンバー「１０２」を獲得し、次に、図９のＰＡＴの行９１２を参照し、プログラムナンバー「１０２」に対応するパケットＩＤ「５０２」を獲得する。ＰＭＴは、Ｐｒｏｇｒａｍ  Ｍａｐ  Ｔａｂｌｅの略で、ＰＡＴで規定されたパケットＩＤのパケットに格納され送信されている。ＪＭＦ４０５ａは、ＰＭＴを取得するため、ＯＳ４０１のライブラリ４０１ｂを通して、多重分離手段２０５にパケットＩＤを指定する。ここで、指定するパケットＩＤは「５０２」とする。多重分離手段２０５がパケットＩＤ「５０２」でフィルタリングを行い、ＣＰＵ２１２に引き渡すことでＪＭＦ４０５ａは、ＰＭＴのパケットを収集する。図１０は、収集したＰＭＴの情報の一例を模式的に表した表である。列１００１は、ストリーム種別であり。列１００２は、パケットＩＤである。列１００２で指定されるパケットＩＤのパケットには、ストリーム種別で指定された情報がペイロードに格納され送信されている。列１００３は補足情報である。行１０１１〜１０１４はエレメンタリ−ストリームと呼ばれる、パケットＩＤと送信している情報の種別の組である。行１０１１は、ストリーム種別「音声」とパケットＩＤ「５０１１」の組であり、パケットＩＤ「５０１１」のペイロードには音声が格納されていることを表す。ＪＭＦ４０５ａは、ＰＭＴから再生する映像と音声のパケットＩＤを獲得する。図１０を参照して、ＪＭＦ４０５ａは、行１０１１から音声のパケットＩＤ「５０１１」を、行１０１２から映像のパケットＩＤ「５０１２」を獲得する。
【０１０７】
次に、ＪＭＦ４０５ａは、ＯＳ４０１のライブラリ４０１ｂのＡＶ再生４０１ｂ３に獲得した音声のパケットＩＤと映像のパケットＩＤを引き渡す。これを受けて、ＡＶ再生４０１ｂ３は、受け取った音声のパケットＩＤと映像のパケットＩＤを、ＴＳデコーダ２０７に与える。ＴＳデコーダ２０７は与えられたパケットＩＤでフィルタリングを行う。ここではパケットＩＤ「５０１１」のパケットを音声出力部２０９に、パケットＩＤ「５０１２」のパケットを映像出力部２０８に、それぞれ引き渡す。音声出力部２０９は、与えられたパケットを適宜変換し（例えばデジタル−アナログ変換）出力する。映像出力部２０８は、与えられたパケットを適宜変換し（例えばデジタル−アナログ変換）出力する。
【０１０８】
最後にサービスマネージャ４０４は、Ｊａｖａライブラリ４０５の中にあるＡＭ４０５ｂにチャンネルの識別子を与え、データ放送再生を依頼する。ここで、データ放送再生とは、ＭＰＥＧ２トランスポートストリームに含まれるＪａｖａプログラムを抽出し、ＪａｖａＶＭ４０３に実行させることである。ＭＰＥＧ２トランスポートストリームにＪａｖａプログラムを埋め込む方法は、ＭＰＥＧ規格書  ＩＳＯ／ＩＥＣ１３８１８−６に記述されたＤＳＭ−ＣＣという方式を用いる。ここではＤＳＭ−ＣＣの詳細な説明は省略する。ＤＳＭ−ＣＣ方式は、ＭＰＥＧ２トランスポートストリームのパケットの中に、コンピュータで使用されているディレクトリやファイルで構成されるファイルシステムをエンコードする方法を規定している。ここでは、Ｊａｖａライブラリ４０５の中のＤＳＭ−ＣＣ４０５ｌが取得するデータは、ファイル構造をもつデータ構造でエンコードを行うＯｂｊｅｃｔＣａｒｏｕｓｅｌ方式でエンコードされているものとする。また、実行するＪａｖａプログラムの情報はＡＩＴと呼ばれる形式で、ＭＰＥＧ２トランスポートストリームのパケットの中に埋め込まれ送信されている。ＡＩＴは、ＤＶＢ−ＭＨＰ規格（正式には、ＥＴＳＩ  ＴＳ  １０１  ８１２  ＤＶＢ−ＭＨＰ仕様Ｖ１．０．２）の１０章に定義されている、Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅの略である。
【０１０９】
ＡＭ４０５ｂは、まず、ＡＩＴを獲得するため、ＪＭＦ４０５ａ同様ＰＡＴ、ＰＭＴを取得し、ＡＩＴが格納されているパケットのパケットＩＤを獲得する。今、与えられたチャンネルの識別子が「２」で、図９のＰＡＴ、図１０のＰＭＴが送信されていると、ＪＭＦ４０５ａと同様の手順で、図１０のＰＭＴを獲得する。ＡＭ４０５ｂは、ＰＭＴからストリーム種別が「データ」で補足情報として「ＡＩＴ」を持つエレメンタリ−ストリームからパケットＩＤを抽出する。図１０を参照して、行１０１３のエレメンタリ−ストリームが該当し、パケットＩＤ「５０１３」を獲得する。
【０１１０】
ＡＭ４０５ｂは、ＯＳ４０１のライブラリ４０１ｂを通して多重分離手段２０５にＡＩＴのパケットＩＤを与える。多重分離手段２０５は、与えられたパケットＩＤでフィルタリングを行い、ＣＰＵ２１２に引き渡す。この結果、ＡＭ４０５ｂは、ＡＩＴのパケットを収集することができる。図１１は、収集したＡＩＴの情報の一例を模式的に表した表である。列１１０１はＪａｖａプログラムの識別子である。列１１０２はＪａｖａプログラムの制御情報である。制御情報には「ａｕｔｏｓｔａｒｔ」、「ｐｒｅｓｅｎｔ」、「ｋｉｌｌ」などがあり、「ａｕｔｏｓｔａｒｔ」は即時にマルチメディアデータ送信装置１０１がこのプログラムを自動的に実行することを意味し、「ｐｒｅｓｅｎｔ」は自動実行しないことを意味し、「ｋｉｌｌ」はプログラムを停止することを意味する。列１１０３は、ＤＳＭ−ＣＣ方式でＪａｖａプログラムを含んでいるパケットＩＤを抽出するためのＤＳＭ−ＣＣ識別子である。列１１０４はＪａｖａプログラムのプログラム名である。行１１１１と１１１２は、Ｊａｖａプログラムの情報の組である。行１１１１で定義されるＪａｖａプログラムは、識別子「３０１」、制御情報「ａｕｔｏｓｔａｒｔ」、ＤＳＭ−ＣＣ識別子「１」、プログラム名「ａ／ＴｏｐＸｌｅｔ」の組である。行１１１２で定義されるＪａｖａプログラムは、識別子「３０２」、制御情報「ｐｒｅｓｅｎｔ」、ＤＳＭ−ＣＣ識別子「１」、プログラム名「ｂ／ＧａｍｅＸｌｅｔ」の組である。ここでふたつのＪａｖａプログラムは同じＤＳＭ−ＣＣ識別子を持つが、これはひとつのＤＳＭ−ＣＣ方式でエンコードされたファイルシステム内にふたつのＪａｖａプログラムが含まれていることを表す。ここでは、Ｊａｖａプログラムに対して四つの情報しか規定しないが、実際にはより多くの情報が定義される。詳細はＤＶＢ−ＭＨＰ規格を参照されたい。
【０１１１】
ＡＭ４０５ｂは、ＡＩＴの中から「ａｕｔｏｓｔａｒｔ」のＪａｖａプログラムを見つけ出し、対応するＤＳＭ−ＣＣ識別子及びＪａｖａプログラム名を抽出する。図１１を参照して、ＡＭ４０５ｂは行１１１１のＪａｖａプログラムを抽出し、ＤＳＭ−ＣＣ識別子「１」及びＪａｖａプログラム名「ａ／ＴｏｐＸｌｅｔ」を獲得する。
【０１１２】
次にＡＭ４０５ｂは、ＡＩＴから取得したＤＳＭ−ＣＣ識別子を用いて、ＪａｖａプログラムをＤＳＭ−ＣＣ方式で格納しているパケットのパケットＩＤをＰＭＴから獲得する。具体的には、ＰＭＴの中でストリーム種別が「データ」で、補足情報のＤＳＭ−ＣＣ識別子が合致するエレメンタリ−ストリームのパケットＩＤを取得する。
【０１１３】
今、ＤＳＭ−ＣＣ識別子が「１」であり、ＰＭＴが図１０とすると、行１０１４のエレメンタリ−ストリームが合致し、パケットＩＤ「５０１４」を取り出す。
【０１１４】
ＡＭ４０５ｂは、ＯＳ４０１のライブラリ４０１ｂを通して多重分離手段２０５にＤＳＭ−ＣＣ方式でデータが埋めこめられたパケットのパケットＩＤを指定する。ここでは、パケットＩＤ「５０１４」を与える。多重分離手段２０５は、与えられたパケットＩＤでフィルタリングを行い、ＣＰＵ２１２に引き渡す。この結果、ＡＭ４０５ｂは、必要なパケットを収集することができる。ＡＭ４０５ｂは、収集したパケットから、ＤＳＭ−ＣＣ方式に従ってファイルシステムを復元し、第１メモリ２０２あるいは第２メモリ２０３に保存する。ファイルシステム等のデータを取り出し第１メモリ２０２あるいは第２メモリ２０３に保存することを以降、ダウンロードと呼ぶ。
【０１１５】
図１２は、ダウンロードしたファイルシステムの一例である。図中、丸はディレクトリを四角はファイルを表し、１２０１はルートディレクトリ、１２０２はディレクトリ「ａ」、１２０３はディレクトリ「ｂ」、１２０４はファイル「ＴｏｐＸｌｅｔ．ｃｌａｓｓ」、１２０５はファイル「ＧａｍｅＸｌｅｔ．ｃｌａｓｓ」である。
【０１１６】
ここでは、ＭＰＥＧ２トランスポートストリームからファイルシステムをダウンロードする例を記載したが、北米デジタルケーブル放送規格であるＯＣＡＰ（ＯｐｅｎＣａｂｌｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｌａｔｆｏｒｍ）仕様では、ＩＰネットワークを用いたダウンロードなども規定している。また、ＡＩＴではなくＸＡＩＴと呼ばれる情報を用いてファイルシステムの存在位置を特定し、ファイルシステムをダウンロードする方法も規定されている。
【０１１７】
次にＡＭ４０５ｂは、第１メモリ２０２あるいは第２メモリ２０３にダウンロードしたファイルシステム中から実行するＪａｖａプログラムをＪａｖａＶＭ４０３に引き渡す。今、実行するＪａｖａプログラム名が「ａ／ＴｏｐＸｌｅｔ」とすると、Ｊａｖａプログラム名の最後に「．ｃｌａｓｓ」を付加したファイル「ａ／ＴｏｐＸｌｅｔ．ｃｌａｓｓ」が実行すべきファイルとなる。「／」はディレクトリやファイル名の区切りであり、図１２を参照して、ファイル１２０４が実行すべきＪａｖａプログラムである。次にＡＭ４０５ｂは、ファイル１２０４をＪａｖａＶＭ４０３に引き渡す。
【０１１８】
ＪａｖａＶＭ４０３は、引き渡されたＪａｖａプログラムを実行する。
【０１１９】
サービスマネージャ４０４は、他のチャンネルの識別子を受け取ると、Ｊａｖａライブラリ４０５に含まれる各ライブラリを通して再生している映像・音声及びＪａｖａプログラムの実行を、同じくＪａｖａライブラリ４０５に含まれる各ライブラリを通して停止し、新たに受け取ったチャンネルの識別子に基づいて、映像・音声の再生及びＪａｖａプログラムの実行を行う。
【０１２０】
また、サービスマネージャ４０４は、再生部４０２ｂだけでなく、ＪａｖａＶＭ４０３上で実行されるＪａｖａプログラムからチャンネルの識別子を受け取る機能も備える。具体的には、チャンネルの識別子を受け取るためのＪａｖａ言語のクラス及びそのメソッドを提供する。チャンネルの識別子を受け取ると、サービスマネージャ４０４は、Ｊａｖａライブラリ４０５に含まれる各ライブラリを通して現在再生している映像・音声及びＪａｖａプログラムの実行を、同じくＪａｖａライブラリ４０５に含まれる各ライブラリを通して停止し、その後、新たに受け取ったチャンネルの識別子に基づいて、新しい映像・音声の再生及びＪａｖａプログラムの実行を行う。
【０１２１】
このようにＪａｖａプログラムは、サービスマネージャ４０４を利用することで、サービス選択を行うことができる。ここまで、サービスマネージャ４０４によるサービスの選択、つまり、受け取ったチャンネル識別子に従い、チューニング、映像・音声再生、Ｊａｖａプログラム起動を行う動作について述べた。
【０１２２】
次に、本発明の主要機能であるサービスの記録および記録したサービスをマルチメディアデータ送信装置１０１が、マルチメディアデータ受信装置１０２への送出する方法について説明する。
【０１２３】
なお、サービスの記録とは、サービスに含まれる映像・音声、およびサービスに含まれるＪａｖａプログラムなどを、第２メモリ２０３などの記録領域へ蓄積することであるが、ここでは特に、マルチメディアデータ受信装置１０２において、データ放送を再生するために必要となるデータを記録する方法を説明する。
【０１２４】
また、マルチメディアデータ受信装置１０２への送出とは、サービス記録時に生成した情報及び記録データを用いて、マルチメディアデータ受信装置１０２へデータ放送関連情報を送出する方法について説明する。
【０１２５】
なお、ここでマルチメディアデータ送信装置１０１が用いる記憶領域は、ＴＣＰ／ＩＰ接続、ＵＳＢ接続、ＩＥＥＥ１３９４接続、赤外線接続など、なんらかの方法で接続された別端末であってもよい。
【０１２６】
以降、図１３に示すように、サービスを記録する機能を有するレコーディングマネージャ１３０１および、ＤＶＲ１３０５ｍ、蓄積管理ライブラリ１３０２、録画ライブラリ１３０１ｂ５を導入する。
【０１２７】
図２は、サービスの記録機能を備えるデジタル放送受信機の一般的なハードウェア構成を表す図である。図２の構成要素に関して、サービスの記録に関連しない構成要素および処理が変わらない構成要素の説明は省略する。
【０１２８】
ＴＳマルチプレクサ２１０は、受け取った映像データ、音声データ、セクションデータからＭＰＥＧ２トランスポートストリームを構成する。このとき、ＰＳＩ／ＳＩ情報は必要に応じて書き換えられる。書き換えの一例として、ＴＳマルチプレクサ２１０は、ＰＡＴを、指定されたコンテンツのみの情報を含むように書き換えることなどがある。そして、マルチメディアデータ受信装置１０２へ該ＭＰＥＧ２トランスポートストリームを送出している際には、ネットワーク部２１１へ該ＭＰＥＧ２トランスポートストリームを引き渡す。また、該ＭＰＥＧ２トランスポートストリームを第２メモリなどの記憶媒体に記録している際には、ＴＳマルチプレクサ２１０は、生成したストリームをＣＰＵ２１２に引き渡し、ＣＰＵ２１２が、引き渡されたストリームを保存する。構成したストリームを記録する。このとき、ＴＳパケットの形式で引き渡された場合には、引き渡されたＴＳパケットをそのまま順に並べてＭＰＥＧ２トランスポートストリームを構成しても良い。
【０１２９】
次に図１３に示すプログラムの構成要素の一例を説明する。図１３において、図４と同じ番号で識別される構成要素は、図４と同じ処理を行うため説明を省略する。
【０１３０】
プログラム１３００は、ＥＰＧ１３０４とレコーディングマネージャ１３０１とＪａｖａライブラリ１３０３を備える。さらに、ＥＰＧ１３０４は録画部１３０５を備え、ライブラリ４０１ｂは録画ライブラリ１３０１ｂ５を備え、Ｊａｖａライブラリ１３０３は、ＤＶＲ１３０５ｍと蓄積管理ライブラリ１３０２を備える。
【０１３１】
ＥＰＧ１３０４の録画部１３０５は、番組表示部４０２ａが表示したＥＰＧ情報に対し、ユーザが行った録画要求を行った場合、ユーザが録画予約を行ったチャンネルを特定するチャンネル識別子を取得する。録画部１３０５は、コンテンツの録画を行うため、チャンネルの識別子をそのままレコーディングマネージャ１３０１に引き渡す。
【０１３２】
録画ライブラリ１３０１ｂ５は、ＤＶＲ１３０５ｍから指定されたマルチメディアデータを第２メモリ２０３などの記録領域へ記録する。
【０１３３】
ＪａｖａライブラリのＤＶＲ１３０５ｍはレコーディングマネージャ１３０１に指定されたコンテンツの録画要求を録画ライブラリ１３０１ｂ５へ依頼する。
【０１３４】
図１４に蓄積管理ライブラリ１３０２の構成を示す。蓄積管理ライブラリ１３０２は、データ取得部１４０１および、制御部１４０２、イベントテーブル生成部１４０３を備える。
【０１３５】
蓄積管理ライブラリ１３０２のデータ取得部１４０１は、データ放送を実現するために必要な情報のうち、特に該当セクションの受信をトリガとしてデータ放送に影響を及ぼすイベントを取得し、第２メモリ２０３へ蓄積すると共に、イベントを管理するイベントテーブル生成部１４０３へ通知する機能を有する。
【０１３６】
蓄積管理ライブラリ１３０２の制御部１４０２は、第２メモリ２０３に蓄積された管理テーブルやデータ毎の格納場所及び必要なデータを管理する。
【０１３７】
蓄積管理ライブラリ１３０２のイベントテーブル生成部１４０３は、データ取得部１４０１から通知された情報及びタイミングを用いてイベントテーブルを生成する機能を有する。
【０１３８】
蓄積管理ライブラリ１３０２による各データの詳細な記録方法、管理方法、取得方法、タイムスタンプ等必要なデータについては後述する。
【０１３９】
ＥＰＧ１３０４は、ＥＰＧ４０２の構成に加え、番組表示部が受け付けたユーザからの入力に従い、指定されたチャンネルの録画（サービスＲｅｃｏｒｄ）を行う録画部１３０５を備える。図１５Ａおよび図１５Ｂは、ユーザが、入力部２０１のＥＰＧボタン３０７を押下した際に、ＣＰＵ２１２上で動作するサブプログラムであるＥＰＧ１３０４の番組表示部４０２ａがモニタに表示した番組表の一例である。ＥＰＧ１３０４は、チャンネルの選択機能及びチャンネルの録画機能を備えることから、番組表示部４０２ａは、例えば録画選択モードと視聴選択モードを提供するものとし、図１５Ａ及び図１５Ｂは録画選択モードを提供している画面であるとする。図１５Ａ及び図１５Ｂにおいて、図５Ａおよび図５Ｂの場合と同じ番号を付した構成は、図５Ａおよび図５Ｂの場合と同等の機能を有するため、説明を省略する。
【０１４０】
図１５Ａの状態で、フロントパネル３００のＯＫボタン３０５が押下されると、番組表示部４０２ａは、「チャンネル１」のチャンネル識別子をＤＶＲ１３０５ｍに通知する。図１５Ｂの状態で、フロントパネル３００のＯＫボタン３０５が押下されると、番組表示部４０２ａは、「チャンネル２」のチャンネル識別子をＤＶＲ１３０５ｍに通知する。ここで、サービス録画、再生機能を備えるデジタル放送受信機において、チャンネル識別子は、放送局から送信されるサービス及び第２メモリ２０３などの記録領域に蓄積されたサービスから1サービスを一意に特定する識別子である。
【０１４１】
ＤＶＲ１３０５ｍは、受け取ったチャンネル識別子を用いて、コンテンツを録画する。チャンネル識別子とチャンネルの関係は、図７を参照して、先述のとおりである。ＤＶＲ１３０５ｍは、チャンネルの録画を行うため、受け取ったチャンネル識別子をそのままレコーディングマネージャ１３０１に引き渡す。
【０１４２】
ＪａｖａＶＭ４０３は、サービス録画（チャンネルの録画）時において、実行するＪａｖａプログラムとしてレコーディングマネージャ１３０１を指定する。
【０１４３】
レコーディングマネージャ１３０１は、Ｊａｖａ言語で書かれたＪａｖａプログラムであり、ＪａｖａＶＭ４０３によって逐次実行される。レコーディングマネージャ１３０１は、ＪＮＩ（Ｊａｖａ  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅ）を通して、Ｊａｖａ言語で記述されていない他のサブプログラムを呼び出したり、または、呼び出されたりすることが可能である。
【０１４４】
レコーディングマネージャ１３０１は、ＪＮＩを通して、ＤＶＲ１３０５ｍよりチャンネル識別子を受け取る。
【０１４５】
レコーディングマネージャ１３０１は、最初にＪａｖａライブラリ４０５の中にあるＴｕｎｅｒ４０５ｃに、チャンネル識別子を引き渡し、チューニングを依頼する。ここで、サービス録画時においてレコーディングマネージャ１３０１からチューニングを依頼された場合のＴｕｎｅｒ４０５ｃの処理は、サービス選択時においてサービスマネージャ４０４からチューニングを依頼された場合の処理と同等であるため説明を省略する。
【０１４６】
次にレコーディングマネージャ１３０１は、ＣＡ４０５ｄに暗号解除を依頼する。ここで、サービス録画時においてレコーディングマネージャ１３０１から暗号解除を依頼された場合のＣＡ４０５ｄの処理は、サービス選択時においてサービスマネージャ４０４から暗号解除を依頼された場合の処理と同等であるため説明を省略する。
【０１４７】
なお、レコーディングマネージャ１３０１から暗号解除を依頼されたＣＡ４０５ｄは、暗号解除後に独自の形式で暗号を掛けるなどの方法を取っても良い。
【０１４８】
なお録画時には、ＣＡ４０５ｄによって暗号解除を行わず録画し、再生時に暗号解除する方法でもよい。
【０１４９】
なお、レコーディングマネージャ１３０１からＣＡ４０５ｄへの暗号解除依頼の有無に係わらず本発明は実施可能である。
【０１５０】
次にレコーディングマネージャ１３０１は、Ｊａｖａライブラリ１３０３の中にあるＤＶＲ１３０５ｍにチャンネル識別子を与え、映像・音声の記録を依頼する。
【０１５１】
まず、最初にＤＶＲ１３０５ｍは、記録すべき映像と音声を特定するためのＰＩＤをＰＡＴ、ＰＭＴから取得する。ここで、ＤＶＲ１３０５ｍは、ＰＡＴを取得するため、ＯＳ４０１のライブラリ４０１ｂを通して、多重分離手段２０５にＰＩＤ「０」とｔａｂｌｅ＿ｉｄ「０」を指定する。多重分離手段２０５がＰＩＤ「０」及びｔａｂｌｅ＿ｉｄ「０」でフィルタリングを行い、第１メモリ２０２を通してＣＰＵ２１２に引き渡すことで、ＤＶＲ１３０５ｍは、ＰＡＴを収集する。ここで、ＰＡＴの例として図９を挙げる。今、ＤＶＲ１３０５ｍに与えられたチャンネル識別子が「１」とすると、ＤＶＲ１３０５ｍは、図７の行７１１を参照して、対応するプログラムナンバー「１０１」を獲得し、次に、図９のＰＡＴの行９１１を参照し、プログラムナンバー「１０１」に対応するＰＩＤ「５０１」を獲得する。ＤＶＲ１３０５ｍは、ＰＭＴを取得するため、ＯＳ４０１のライブラリ４０１ｂを通して、多重分離手段２０５にＰＡＴより取得したＰＩＤとｔａｂｌｅ＿ｉｄ「２」を指定する。ここで、指定するＰＩＤは「５０１」とする。多重分離手段２０５がＰＩＤ「５０１」及びｔａｂｌｅ＿ｉｄ「２」でフィルタリングを行い、第１メモリ２０２を通してＣＰＵ２１２に引き渡すことで、ＤＶＲ１３０５ｍはＰＭＴの収集をする。ここでＰＭＴの例として図１６を挙げる。ここで、図１６において、図１０と同等の構成要素には同一番号を付し説明を省略する。図１６において、行１０１５に表されるＥＳは、データ用セクションを伝送するＥＳであり、ＰＩＤが５０１５であり、付加情報がＤＳＭ−ＣＣ［２］（ＤＳＭ−ＣＣ識別子が２）であるＴＳパケットによって構成される。なお、図１６の行１０１６に表れるＥＳは、ストリーム種別が「イベント」の補足情報をもつ、ＤＳＭ−ＣＣストリームイベント「ＤＳＭ−ＣＣ＿ＳＴ［１］」であるＴＳパケットによって構成される。ＤＶＲ１３０５ｍは、ＰＭＴから記録する映像と音声のＰＩＤを獲得する。図１６を参照して、ＤＶＲ１３０５ｍは、行１０１１から音声のＰＩＤ「５０１１」を、行１０１２から映像のＰＩＤ「５０１２」を獲得する。
【０１５２】
次に、ＤＶＲ１３０５ｍは、ＯＳ４０１のライブラリ４０１ｂを通して、獲得した映像／音声のＰＩＤを、ＴＳデコーダ２０７に与える。ＴＳデコーダ２０７は与えられたＰＩＤに基づいて、フィルタリングを行う。ここではＰＩＤ「５０１１」、「５０１２」のＰＥＳパケットをＴＳマルチプレクサ２１０に引き渡す。なお、ここでＴＳマルチプレクサ２１０へ引き渡す前に、必要に応じて再エンコードしてもよい。ＴＳマルチプレクサ２１０は、受け取った映像データ、音声データ、セクションデータからＭＰＥＧ２トランスポートストリームを構成する。なお、ＰＳＩ／ＳＩ情報は必要に応じて書き換えられる。書き換えの一例として、ＴＳマルチプレクサ２１０は、ＰＡＴを指定されたコンテンツのみの情報を含むように書き換えることなどがある。また、ＴＳマルチプレクサ２１０は、指定されたＰＩＤやｔａｂｌｅ＿ｉｄなどの条件に一致するデータを含むＭＰＥＧ２トランスポートストリームを生成してもよい。ＴＳマルチプレクサ２１０が生成した、録画用ＭＰＥＧ２トランスポートストリームを第２メモリ２０３へ蓄積する。また、ＴＳマルチプレクサ２１０は、データをＴＳパケットの形式で引き渡された場合には、引き渡されたＴＳパケットをそのまま順に並べてＭＰＥＧ２トランスポートストリームを構成しても良い。
【０１５３】
なお、ここで、蓄積管理ライブラリ１３０２は、録画用ＭＰＥＧ２トランスポートストリームを該ストリームの識別子と関連つけて第２メモリ２０３へ蓄積する機能を備えることとし、ＤＶＲ１３０５ｍは、レコーディングマネージャ１３０１から指定されたチャンネル識別子とＴＳマルチプレクサ２１０が多重し生成した録画用ＭＰＥＧ２トランスポートストリームを、蓄積管理ライブラリ１３０２の制御部１４０２に引き渡して、録画用ＭＰＥＧ２トランスポートストリームの第２メモリ２０３への蓄積を依頼することで、録画用ＭＰＥＧ２トランスポートストリームを第２メモリ２０３へ蓄積する、としても、本発明は実施可能である。
【０１５４】
最後にレコーディングマネージャ１３０１は、Ｊａｖａライブラリ１３０３の中にある蓄積管理ライブラリ１３０２の制御部１４０２にチャンネル識別子を与え、データ放送の蓄積を依頼する。ここで、データ放送の蓄積とは、ネットワークで接続されたクライアントであるマルチメディアデータ受信装置１０２がデータ放送の再生を実現するために必要とするデータ放送用データを、ＭＰＥＧ２トランスポートストリームから抽出し、第２メモリ２０３に蓄積することである。
【０１５５】
マルチメディアデータ受信装置１０２がデータ放送の再生を実現するために必要とするデータ放送関連情報には、データ放送のタイミングに関連するイベント情報と、実データを取得・構成するために必要な情報であるデータ放送用データがある。このうち、データ放送に関連するイベントは、タイミングが関連するため、該当するイベントの事象が発生する前までに、クライアントに通知する必要がある。以下に、データ放送に関連するイベントの一例として、イベントを検知するための情報とその詳細を示す。
【０１５６】
・データ放送関連情報用の更新に関連する情報
【表１】
2010525616.tif 000003
(*1)：Ｍｏｄｕｌｅのバージョンアップが発生した場合は、対象となるＭｏｄｕｌｅに含まれるオブジェクトのいずれかまたはすべてにおいてバージョンアップが発生したと考える。
【０１５７】
・データ放送用データが刻む時間情報及びタイミング情報
【表２】
2010525616.tif 000004
【０１５８】
図１７ＡにＮＰＴ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｓｃｒｉｐｔｏｒが伝送する情報を示す。また、図１７ＢにＳｔｒｅａｍ  Ｅｖｅｎｔ  Ｄｅｓｃｒｉｐｔｏｒが伝送する情報を示す。なお、これらを伝送するセクションをＤＳＭ−ＣＣストリームセクションと呼ぶ。
【０１５９】
ＮＰＴ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｓｃｒｉｐｔｏｒは、ｃｏｎｔｅｎｔＩＤで識別される時刻と該時刻のスピードを通知する。ＮＰＴの時刻は、ＮＰＴ＿ＲｅｆｅｒｅｎｃｅとＳＴＣ＿Ｒｅｆｅｒｅｎｃｅと端末が刻むＳＴＣの値から求めることができ、その時刻が刻むスピードをｓｃａｌｅＮｕｍｅｒａｔｏｒ／ｓｃａｌｅＤｅｎｏｍｉｎａｔｏｒを計算することで、時刻を進ませる増分がわかる。
【０１６０】
一方、Ｓｔｒｅａｍ  Ｅｖｅｎｔ  Ｄｅｓｃｒｉｐｔｏｒは、ｅｖｅｎｔＩＤで識別されるｅｖｅｎｔを通知するタイミングをｅｖｅｎｔＮＰＴによって通知する。
【０１６１】
これらのＤｅｓｃｒｉｐｔｏｒは、ＡＶと同期したデータ放送の実現を行うために用いられる。例えば、クイズ番組などにおいて、「映像・音声によってモニタ上に表示されている司会者の動作」と「データ放送によって配信している答え」の同期をとり、モニタへ表示することがあげられる。このようなデータ放送の番組を実現するために、放送局は、対象となるクイズ番組と共に動作させるアプリケーションとアプリケーションが用いるデータを配信すると共に、対象となるクイズ番組が刻む時刻情報をＮＰＴ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｓｃｒｉｐｔｏｒによって配信する。そして、クイズ番組の中で答えを必要とするタイミングをＳｔｒｅａｍ  Ｅｖｅｎｔ  Ｄｅｓｃｒｉｐｔｏｒによって通知することで、放送波を受信する受信装置は、適切なＮＰＴ時刻になったとき、アプリケーションへイベントを識別するｅｖｅｎｔＩＤと共に通知することができる。このようなイベントを受信したアプリケーションが、該当するデータをモニタへ表示することにより、映像・音声と同期したデータ放送を実現することができる。なお、Ｓｔｒｅａｍ  Ｅｖｅｎｔ  Ｄｅｓｃｒｉｐｔｏｒには、前述したようなイベントを発行するＮＰＴ時刻を知らせる「Ｓｃｈｅｄｕｌｅｄ  Ｅｖｅｎｔ」と、受信したタイミングで直ちにイベントを発行することを要求する「ｄｏ  ｉｔ  ｎｏｗ」イベントが存在する。詳細はＤＳＭ−ＣＣ規格を参照されたい。
【０１６２】
以上のようなイベントデータは、制御部１４０２によって設定されたＰＩＤをもとにデータ取得部１４０１が取得したデータをイベントテーブル生成部１４０３がイベントテーブルを生成することで、管理される。
【０１６３】
（マルチメディアデータ送信装置１０１におけるイベントテーブル生成）
ここで、マルチメディアデータ送信装置１０１の蓄積管理ライブラリ１３０２の各データの詳細な記録方法、管理方法、取得方法処理を説明する。制御部１４０２は、ＰＡＴ、ＰＭＴ、ＡＩＴ、ＤＳＭ−ＣＣセクションであるＤＳＩ（Ｄｏｗｎｌｏａｄ  Ｓｅｒｖｅｒ  Ｉｎｉｔｉａｔｅ）、ＤＩＩ（Ｄｏｗｎｌｏａｄ  Ｉｎｆｏ  Ｉｎｄｉｃａｔｉｏｎ）を運ぶエレメンタリーストリームのＰＩＤとＤＳＭ−ＣＣストリームセクションを運ぶエレメンタリーストリームのＰＩＤを取得し、データ取得部１４０１へ設定する。なお、図１８Ａにデータ取得部１４０１の構成図を示す。データ取得部１４０１は、ストリーム構成情報取得監視部１８０１とアプリケーション構成情報取得監視部１８０２とカルーセル構成情報取得監視部１８０３とデータ放送用ストリーム情報取得監視部１８０４から構成される。各構成要素の説明は後述する。なお、各処理の主要な処理は後述するが、図１８Ｂに蓄積管理ライブラリの主要な処理を説明する。蓄積管理ライブラリ１３０２の制御部１４０２は、レコーディングマネージャ１３０１からチャンネル識別子を受け、蓄積依頼を受ける（Ｓ１−１８０１）。制御部１４０２は、ストリーム構成情報あるいはアプリケーション構成情報、あるいは、カルーセル構成情報あるいは、データ放送用ストリーム情報を伝送するＰＩＤを取得しデータ取得部１４０１へ通知し取得・監視を依頼する（Ｓ１−１８０２）。データ取得部１４０１のストリーム構成情報取得監視部１８０１およびアプリケーション構成情報取得監視部１８０２およびカルーセル構成情報取得監視部１８０３及びデータ放送用ストリーム情報取得監視部１８０４の時間軸取得監視部１８０４１は最初に取得したデータをイベントテーブル生成部１４０３へ通知し、その後は監視を行う。ストリームイベント取得部１８０４２は、関連データを取得時にイベントテーブル生成部１４０３へ通知する（Ｓ１−１８０３）。イベントテーブル生成部１４０３は受信した情報を、ストリーム中のタイミング情報と共に記録する（Ｓ１−１８０４）。データ取得部１４０１においてイベント検出を監視し（Ｓ１−１８０６）、録画終了まで繰り返す（Ｓ１−１８０５）。なお、イベント検出の監視(Ｓ１−１８０６）において、イベントを検出すると、イベントテーブル生成部１４０３は、受信した情報をストリーム中のタイミング情報と共に記録する（Ｓ１−１８０７）。ことで、イベントテーブルの生成を行う。以下、各処理の詳細を説明する。
【０１６４】
今、与えられたチャンネル識別子が「１」で、図９のＰＡＴ、図１６のＰＭＴが送信されているとすると、制御部１４０２は、ＪＭＦ４０５ａおよびＤＶＲ１３０５ｍと同様に与えられたチャンネル識別子をもとにＰＭＴのＰＩＤ「５０１」を獲得する。ここで、制御部１４０２は、ＰＡＴのＰＩＤである「０」とＰＭＴのＰＩＤ「５０１」をデータ取得部１４０１のストリーム構成情報取得監視部１８０１へ引き渡す。
【０１６５】
次に、制御部１４０２は、ＡＩＴのＰＩＤを取得するため、ＪＭＦ４０５ａと同様の手順で、図１６のＰＭＴを獲得する。蓄積管理ライブラリ１３０２の制御部１４０２は、ＰＭＴからストリーム種別が「データ」で補足情報として「ＡＩＴ」を持つエレメンタリ−ストリームからＰＩＤを抽出する。図１６を参照して、行１０１３のエレメンタリ−ストリームが該当し、ＰＩＤ「５０１３」を獲得する。ここで、制御部１４０２は、ＡＩＴのＰＩＤ「５０１３」をデータ取得部１４０１のアプリケーション構成情報取得監視部１８０２へ引き渡す。
【０１６６】
次に、制御部１４０２は、ＤＳＭ−ＣＣセクションのＤＳＩ及びＤＩＩのＰＩＤを取得するため、蓄積管理ライブラリ１３０２の制御部１４０２は、ＯＳ４０１のライブラリ４０１ｂを通してＴＳデコーダ２０７にＡＩＴのＰＩＤとｔａｂｌｅ＿ｉｄ「０ｘ７４」を与える。ＴＳデコーダ２０７は、与えられたＰＩＤ及びｔａｂｌｅ＿ｉｄでフィルタリングを行い、第１メモリ２０２を通してＣＰＵ２１２に引き渡す。この結果、蓄積管理ライブラリ１３０２は、ＡＩＴを収集することができる。図１９は、収集したＡＩＴの情報の一例を模式的に表した表である。図１９において、図１１と同一の構成要素には同一の番号を付し、説明を省略する。行１９１１〜行１９１４は、Ｊａｖａプログラムの情報の組である。行１９１１で定義されるＪａｖａプログラムは、Ｊａｖａプログラムの識別子「３０１」、制御情報「ａｕｔｏｓｔａｒｔ」、ＤＳＭ−ＣＣ識別子「１」、プログラム名「ａ／ＴｏｐＸｌｅｔ」の組である。行１９１２で定義されるＪａｖａプログラムは、Ｊａｖａプログラムの識別子「３０２」、制御情報「ｐｒｅｓｅｎｔ」、ＤＳＭ−ＣＣ識別子「１」、プログラム名「ｂ／ＧａｍｅＸｌｅｔ」の組である。行１９１３で定義されるＪａｖａプログラムは、Ｊａｖａプログラムの識別子「３０３」、制御情報「ｋｉｌｌ」、ＤＳＭ−ＣＣ識別子「２」、プログラム名「ｚ／ＳｔｕｄｙＸｌｅｔ」の組である。行１９１４で定義されるＪａｖａプログラムは、Ｊａｖａプログラムの識別子「３０４」、制御情報「ｄｅｓｔｒｏｙ」、ＤＳＭ−ＣＣ識別子「１」、プログラム名「ｂ／ＭｕｓｉｃＸｌｅｔ」の組である。次に、蓄積管理ライブラリ１３０２の制御部１４０２は、ＡＩＴに記載される全てのＪａｖａプログラムを見つけ出し、対応するＤＳＭ−ＣＣ識別子を抽出する。図１９を参照して、蓄積管理ライブラリ１３０２は行１９１１のＪａｖａプログラム、行１９１２のＪａｖａプログラム、行１９１３のＪａｖａプログラム、行１９１４のＪａｖａプログラムを抽出し、ＤＳＭ−ＣＣ識別子「１」、ＤＳＭ−ＣＣ識別子「２」を獲得する。次に蓄積管理ライブラリ１３０２の制御部１４０２は、ＡＩＴから取得したＤＳＭ−ＣＣ識別子を用いて、ＤＳＭ−ＣＣ方式でＪａｖａプログラムなどのデータ放送用データを格納しているＴＳパケットのＰＩＤをＰＭＴから獲得する。具体的には、ＰＭＴの中でストリーム種別が「データ」で、補足情報のＤＳＭ−ＣＣ識別子が合致するエレメンタリ−ストリームのＰＩＤを取得する。今、ＤＳＭ−ＣＣ識別子が「１」及び「２」であり、ＰＭＴが図１６とすると、行１０１４及び行１０１５のエレメンタリ−ストリームが合致し、ＰＩＤ「５０１４」及びＰＩＤ「５０１５」を取り出す。ここで、制御部１４０２は、ＤＳＭ−ＣＣセクションを伝送するＰＩＤである「５０１４」と「５０１５」をデータ取得部１４０１のカルーセル構成情報取得監視部１８０３へ引き渡す。
【０１６７】
制御部１４０２は、ＰＭＴを取得し、図１６の行１０１６に表れるストリーム種別が「イベント」（ＳｔｒｅａｍＴｙｐｅ＝０Ｃ）の補足情報をもつ、ＤＳＭ−ＣＣストリームイベント「ＤＳＭ−ＣＣ＿ＳＴ［１］」であるＴＳパケットによって構成されるエレメンタリーストリームのＰＩＤである「５０１７」を獲得する。ここで、制御部１４０２は、ＤＳＭ−ＣＣセクションを伝送するＰＩＤである「５０１７」をデータ取得部１４０１のデータ放送用ストリーム情報取得監視部１８０４へ引き渡す。
【０１６８】
次に、蓄積管理ライブラリ１３０２のデータ取得部１４０１の構成要素を説明する。図１８Ａに、データ取得部１４０１の構成要素を示す。図１８Ａにおいて、１８０１はストリーム構成情報取得監視部を、１８０２はアプリケーション構成情報取得監視部を、１８０３はカルーセル構成情報取得監視部を、１８０４はデータ放送用ストリーム情報取得監視部を、１８０４１はデータ放送用ストリーム情報取得監視部１８０４内の時間軸取得監視部を、１８０４２はデータ放送用ストリーム情報取得監視部１８０４内のストリームイベント取得部を、それぞれ示す。
【０１６９】
ストリーム構成情報取得監視部１８０１は、サービス録画開始時のＰＡＴ、ＰＭＴを取得し、第２メモリ２０３へ記録し、サービス録画中、記録したＰＡＴ、ＰＭＴのバージョンアップを監視する。また、サービス録画開始時に記録したＰＡＴとＰＭＴへの参照をイベントテーブル生成部１４０３へ通知する。また、バージョンアップが発生した場合、イベントテーブル生成部１４０３へ通知する。ここでは、イベントテーブル生成部１４０３へ通知する情報は、バージョンアップが発生したという情報とそのバージョンナンバーを通知し、このバージョンアップしたテーブルも第２メモリ２０３へ記録するという方法を説明するが、他にも、バージョンアップによって変更された内容を通知する方法や、バージョンアップしたセクション自身あるいは、それに相当する情報を通知するという方法でもよい。
【０１７０】
アプリケーション構成情報取得監視部１８０２は、サービス録画開始時のＡＩＴを取得し、第２メモリ２０３へ記録し、サービス録画中、記録したＡＩＴのバージョンアップを監視する。また、サービス録画開始時に記録したＡＩＴへの参照をイベントテーブル生成部１４０３へ通知する。そして、バージョンアップが発生した場合、イベントテーブル生成部１４０３へ通知する。ここでは、イベントテーブル生成部１４０３へ通知する情報は、バージョンアップが発生したという情報とそのバージョンナンバーを通知し、このバージョンアップしたテーブルも第２メモリ２０３へ記録するという方法を説明するが、他にも、バージョンアップによって変更された内容を通知する方法や、バージョンアップしたセクション自身あるいは、それに相当する情報を通知するという方法でもよい。
【０１７１】
カルーセル構成情報取得監視部１８０３は、サービス録画開始に伴うデータ放送取得開始時のＤＳＩ及びＤＩＩを取得し、第２メモリ２０３へ記録し、サービス録画中、記録したＤＳＩ及びＤＩＩのバージョンアップを監視する。また、サービス録画開始時に記録したＤＳＩ、ＤＩＩへの参照をイベントテーブル生成部１４０３へ通知する。そして、バージョンアップが発生した場合、イベントテーブル生成部１４０３へ通知する。ここでは、イベントテーブル生成部１４０３へ通知する情報は、バージョンアップが発生したという情報と、ＤＳＩ及びＤＩＩのバージョン情報を含むＴｒａｎｓａｃｔｉｏｎＩＤを通知し、このバージョンアップしたテーブルも第２メモリ２０３へ記録するという方法を説明するが、他にも、バージョンアップによって変更された内容を通知する方法や、バージョンアップしたセクション自身あるいは、それに相当する情報を通知するという方法でもよい。
【０１７２】
データ放送用ストリーム情報取得監視部１８０４は、サービス録画開始に同じＰＭＴ内ストリーム種別が「イベント」（ＳｔｒｅａｍＴｙｐｅ＝０Ｃ）の補足情報をもつエレメンタリーストリームより、ｔａｂｌｅ＿ｉｄ＝「３Ｄ」で伝送されているＤＳＭ−ＣＣストリームデスクリプタを運ぶセクションを取得する。そして、取得したＤＳＭ−ＣＣストリームセクションがＮＰＴ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｓｃｒｉｐｔｏｒを運ぶ場合は、時間軸取得監視部１８０４１へ該セクションを引き渡す。また、ＤＳＭ−ＣＣストリームセクションがＳｔｒｅａｍ  Ｅｖｅｎｔ  Ｄｅｓｃｒｉｐｔｏｒを伝送する場合は、ストリームイベント取得部１８０４２へ該セクションを引き渡す。
【０１７３】
時間軸取得監視部１８０４１は、ＮＰＴ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｓｃｒｉｐｔｏｒが伝送するＮＰＴという時間軸のスピード（＝ｓｃａｌｅＮｕｍｅｒａｔｏｒ／ｓｃａｌｅＤｅｎｏｍｉｎａｔｏｒ）に変化が起きた場合は、イベントテーブル生成部１４０３へ通知する。また、ＮＰＴ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｓｃｒｉｐｔｏｒは一定の決まった間隔で放送ストリームにエンコードされているが、このＮＰＴ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｓｃｒｉｐｔｏｒの受信が途絶えたタイミングと再度受信を検知した場合は、イベントテーブル生成部１４０３へ通知する。ＮＰＴのスピードが変化したとき、イベントテーブル生成部１４０３へ通知する情報として、ここではＮＰＴのスピードが変化したことを識別する情報（ここでは、ＮＰＴＳｐｅｅｄＣｈａｎｇｅフラグとする）を通知し、変更されたＮＰＴ時間を識別するＣｏｎｔｅｎｔＩＤと変更されたＮＰＴのスピード情報を表すｓｃａｌｅＮｕｍｅｒａｔｏｒとｓｃａｌｅＤｅｎｏｍｉｎａｔｏｒおよび、そのイベントを受信したＮＰＴ時刻を通知する方法を説明するが、ＮＰＴ時刻の代わりに、ＮＰＴ時刻を求めるために利用するＮＰＴ＿ＲｅｆｅｒｅｎｃｅとＳＴＣ＿Ｒｅｆｅｒｅｎｃｅを通知するという方法でもよい。また、別の方法として、イベントテーブル生成部１４０３へはスピードが変化した情報と変更されたＮＰＴ時間を識別するＣｏｎｔｅｎｔＩＤのみを通知し、このスピードの変化が発生したテーブルを第２メモリ２０３へ記録するという方法でもよい。また、ＮＰＴ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｓｃｒｉｐｔｏｒの受信が途絶えたとき、イベントテーブル生成部１４０３へは、ＮＰＴ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｓｃｒｉｐｔｏｒの受信が途絶えたということを識別する情報（ここでは、ＮＰＴＤｉｓｃｏｎｔｉｎｕｉｔｙフラグとする）と変更されたＮＰＴ時間を識別するＣｏｎｔｅｎｔＩＤを通知する。更に、ＮＰＴ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｓｃｒｉｐｔｏｒの受信が再開したとき、再開したＮＰＴ時間を識別するＣｏｎｔｅｎｔＩＤと、ＮＰＴ時間を求めるために必要なＮＰＴ＿Ｒｅｆｅｒｅｎｃｅ及びＳＴＣ＿Ｒｅｆｅｒｅｎｃｅの情報とＮＰＴのスピード情報を通知するという方法でもよいし、ＮＰＴ  Ｒｅｆｅｒｅｎｃｅ  Ｄｅｓｃｒｉｐｔｏｒの受信が再開したという情報とＮＰＴ時間を識別するＣｏｎｔｅｎｔＩＤを通知し、このスピードの変化をしたテーブルを第２メモリ２０３へ記録するという方法でもよい。
【０１７４】
ストリームイベント取得部１８０４２は、Ｓｔｒｅａｍ  Ｅｖｅｎｔ  Ｄｅｓｃｒｉｐｔｏｒを受信した際には常に、イベントテーブル生成部１４０３へ通知する。このとき、イベントテーブル生成部１４０３へは、取得したイベントが「ｄｏ  ｉｔ  ｎｏｗ」イベントか「Ｓｃｈｅｄｕｌｅｄ  ｅｖｅｎｔ」かのいずれのイベントを伝送したのかということを示す情報と、Ｓｔｒｅａｍ  Ｅｖｅｎｔ  Ｄｅｓｃｒｉｐｔｏｒによって伝送されたＤＳＭ−ＣＣストリームイベントを識別するｅｖｅｎｔＩＤと該ストリームイベントを発行するＮＰＴ時間であるｅｖｅｎｔＮＰＴをイベントテーブル生成部１４０３へ通知する。または、取得したイベントが「ｄｏ  ｉｔ  ｎｏｗ」イベントか「Ｓｃｈｅｄｕｌｅｄ  ｅｖｅｎｔ」かのいずれのイベントを伝送したのかということを示す情報と、Ｓｔｒｅａｍ  Ｅｖｅｎｔ  Ｄｅｓｃｒｉｐｔｏｒによって伝送されたＤＳＭ−ＣＣストリームイベントを識別するｅｖｅｎｔＩＤのみを通知し、このＳｔｒｅａｍ  Ｅｖｅｎｔ  Ｄｅｓｃｒｉｐｔｏｒを伝送するテーブルを第２メモリ２０３へ記録するという方法でもよい。
【０１７５】
イベントテーブル生成部１４０３は、ストリーム構成情報取得監視部１８０１、アプリケーション構成情報取得監視部１８０２、カルーセル構成情報取得監視部１８０３からデータ放送用ストリーム情報取得監視部１８０４によって通知されたタイミングとその情報を記録する。イベントテーブル生成部１４０３が生成するイベントテーブルの一例を図２０および図２１に、示す。なおここでは、記録するタイミングとして、サービス記録開始を０とした時刻（ここではメディアタイムと呼ぶ）として記録する方法を述べるが、ストリーム構成情報取得監視部１８０１、アプリケーション構成情報取得監視部１８０２、カルーセル構成情報取得監視部１８０３、データ放送用ストリーム情報取得監視部１８０４から通知を受けたタイミング、つまりバージョンアップなどが発生したタイミングを識別できる情報であれば、他の情報であってもよい。更に、今後メディアタイムについて記述する際には、常にタイミングを識別できる情報であれば、ストリーム開始位置からのデータ量で表すＢｙｔｅ位置やＮＰＴ（ＮｏｒｍａｌＰｌａｙＴｉｍｅ）など、他の情報であってもよい。
【０１７６】
次に、図２０に蓄積管理ライブラリ１３０２のデータ管理部１４０２が管理するイベントテーブルの一例を示す。図２０において、２０００はイベントテーブルを表す。２００１列は、ストリーム構成情報取得監視部１８０１、アプリケーション構成情報取得監視部１８０２、カルーセル構成情報取得監視部１８０３、データ放送用ストリーム情報取得監視部１８０４から通知を受けた時刻（一例として２００１列はメディアタイム）を示す。次に、２００２は、イベントの識別子を示す。なお、ここではストリーム構成情報取得監視部１８０１がＰＡＴ、ＰＭＴのバージョンアップを検知したことを識別する情報として、ＰＡＴ、ＰＭＴを用いる。また、アプリケーション構成情報取得監視部１８０２がＡＩＴのバージョンアップを検知したことを識別する情報として、ＡＩＴを用いる。また、カルーセル構成情報取得監視部１８０３がＤＳＩ、ＤＩＩのバージョンアップを検知したことを識別する情報として、ＤＳＩ、ＤＩＩを用いる。また、データ放送用ストリーム情報取得監視部１８０４の時間軸取得監視部１８０４１がＮＰＴ時刻のスピードの変更及び、ＮＰＴ時刻を運ぶセクションの不連続や、再受信を通知する情報を識別する情報としてＮＰＴ、また、データ放送用ストリーム情報取得監視部１８０４のストリームイベント取得部１８０４２がＳｔｒｅａｍＥｖｅｎｔ  Ｄｅｓｃｒｉｐｔｏｒを受信したことを識別する情報としてＳｔｒｅａｍＥｖｅｎｔを用いる。２００３は、各イベントの発生を発見したＰＩＤを示す。２００４は、各セクションの格納場所（例えばセクションに対応するデータの先頭位置を示す第２メモリのアドレス情報）を示す。また、図２１の２１０５列には、ストリーム構成情報取得監視部１８０１、アプリケーション構成情報取得監視部１８０２、カルーセル構成情報取得監視部１８０３、データ放送用ストリーム情報取得監視部１８０４から各イベントの通知を受けた際の付加情報を示す。
【０１７７】
図２２に録画ストリームとイベントテーブルの関連と、ストリームおよびイベントテーブルの格納場所の一例を示す。図２２において、２２００はストリーム関連テーブルを表す。また、列２２０１は、録画ストリームの名前などの識別子を示す。列２２０２は、録画ストリームを含むチャンネル識別子を示す。列２２０３は録画ストリームの格納場所（例えば録画ストリームに対応するデータの先頭位置を示す第２メモリのアドレス情報）を示す。列２２０４は関連するイベントテーブルの名前などの識別子を示し、列２２０５はイベントテーブルの格納場所（例えばイベントテーブルに対応するデータの先頭位置を示す第２メモリのアドレス情報）を示す。
【０１７８】
ここで図２３Ａに、図４のプログラムの構成図で示したネットワークライブラリ４０５ｅの内部構成の一例をあらわすブロック図を示す。図２３Ａにおいて、ネットワークライブラリ４０５ｅは、要求受信部２３ａ、制御部２３ｂ、データ取得部２３ｄ、Ｈｅａｄｅｒ生成部２３ｅ、情報送信部２３ｆを備える。また、図２３Ｂに図２３Ａに示すネットワークライブラリ４０５ｅのシーケンスを示す。以下、ネットワークライブラリ４０５ｅがマルチメディアデータ受信装置１０２より次のようなリクエストメッセージを受信（Ｓ１−２３０１）した場合を例に、それぞれの動作について説明する。また、ストリーム関連テーブルとして図２２に示した２２００を用い、イベントテーブルとして、図２０の２０００を用いることとする。
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
PlaySpeed.dlna.org : speed= 5
【０１７９】
要求受信部２３ａは、要求元端末から送信されてきたリクエストメッセージを解析し、その内容を制御部２３ｂに引き渡すものである（Ｓ１−２３０２）。上記のリクエストメッセージを受信した場合は、該リクエストメッセージから、少なくとも要求されたコンテンツのＵＲＩ（上記の例では、http://192.168.0.3/AVData/0001.m2ts）を取得し、制御部２３ｂへ引き渡す。
【０１８０】
制御部２３ｂは、要求受信部２３ａから引き渡された情報に従い、ネットワークライブラリ４０５ｅの他の構成要素を制御して、レスポンスメッセージを生成し、該要求元端末へ送信するものである。制御部２３ｂは、まず、要求受信部２３ａが受信したリクエストメッセージが正しいか判断する（Ｓ１−２３０３）。不正なものであった場合や、ネットワークライブラリ４０５ｅの他の構成要素よりエラー通知が発生した場合は、Ｈｅａｄｅｒ生成部２３ｅに依頼して（Ｓ１−２３０６）、対応するＨＴＴＰのエラーメッセージを生成し（Ｓ１−２３０７）、それを情報送信部２３ｆに引き渡して（Ｓ１−２３０８）、該要求元端末へ送信し（Ｓ１−２３０９）、処理を終了する。受信したリクエストメッセージが正しいものであれば、制御部２３ｂは、クライアントより指定されたコンテンツのＵＲＩより、録画ストリームの名前などの識別子（ここでは、０００１．ｍ２ｔｓ）と再生スピード（ここではｓｐｅｅｄ＝５）を取得し、データ取得部２３ｄへ引き渡す（Ｓ１−２３０４）。なお、リクエストメッセージに“PlaySpeed.dlna.org : speed=”が存在しない場合は、再生スピード＝１（通常再生に相当する再生速度）としてみなすこととする。
【０１８１】
データ取得部２３ｄは、ＩＯ４０５ｇに依頼してストリーム関連テーブル２２００を読み出す。データ取得部２３ｄは、制御部２３ｂによって引き渡された識別子と列２２０１を参照し録画ストリームの名前などの識別子を比較し、制御部２３ｂによって引き渡された識別子に関連するコンテンツの存在を確認する。存在しない場合には、そのエラー内容を制御部２３ｂへ通知し終了する。一方、存在した場合は、識別子が一致する録画ストリームの格納場所２２０３と、イベントテーブルの名前などの識別子２２０４とそのイベントテーブルの格納場所２２０５を取得する。次に、データ取得部２３ｄは、取得したイベントテーブルの名前などの識別子２２０４とそのイベントテーブルの格納場所２２０５をもとに、イベントテーブル２０００を取得する。
【０１８２】
データ取得部２３ｄは、録画ストリームの格納場所２２０３からストリームを読み出し、制御部２３ｂによって引き渡された再生スピードで再生するためのストリームデータを生成する。このとき、データ取得部２３ｄは、イベントテーブル２０００を参照し、イベントテーブル２０００に記載されたセクションを、ストリームの開始からの時刻に応じてセクションの格納場所２００４より取得し、生成するストリームに挿入し、生成したストリームと成功の結果を制御部２３ｂへ引き渡す（Ｓ１−２３０５）。特に通常の再生速度よりも速い再生速度を指定して再生を要求している場合、録画ストリームの格納場所２２０３に示されたストリームを全て送れず、断片的な区間のストリームデータを生成するような構成となるが、従来であれば、この断片的な区間に必要なデータ（例えばセクション）が含まれていなければ、必要なデータをクライアントへ送れなかったが、本実施の形態においては上述の構成を採用することにより、通常再生よりも速い再生速度で再生を要求がなされても、データ取得部２３ｄは生成するストリームデータに必要なデータを確実に挿入できるようになる。これにより、クライアントは、通常再生及び特殊再生のいずれの場合においても、イベントテーブルに記載されたセクションを必ず受信することができるようになり、データ放送に必要なイベントを取りこぼすことなく取得することができるようになる。なお、イベントテーブルが存在しない場合は、引き渡された録画ストリームの識別子と再生スピードに基づきストリームを生成し、イベントテーブルが存在しなかった旨と生成したストリームを制御部２３ｂへ引き渡す。
【０１８３】
また、ここでは、イベントテーブル２０００を生成する際に、予めセクションを抜き出しセクションの格納場所２００４に保存する方法を説明したが、本方法は、特殊再生中であっても、必ずクライアントへ通知する必要のあるセクションデータを、クライアントへ送出するストリームへ必ず挿入できる方法であれば別の方法であってもよい。
【０１８４】
例えば、イベントテーブル２０００は、セクションの格納場所２００４は保持せず、２００１に記載されたメディアタイム近辺に録画セクションに含まれる該当セクションは必ずクライアントへ送出するストリームに挿入するという方法であってもよい。
【０１８５】
また、イベントテーブル２０００は、セクションの格納場所２００４は保持せず、メディアタイム２００１の代わりに、各セクションを伝送するセクションの開始位置からその範囲をByte位置などで記載しておき、該当セクションを運ぶTSパケットは必ず挿入するという方法であってもよい。
【０１８６】
制御部２３ｂは、データ取得部２３ｄからの結果やＣｏｎｔｅｎｔＴｙｐｅなど、レスポンスのヘッダ生成に必要な情報をＨｅａｄｅｒ生成部２３ｅに引き渡し、ＨＴＴＰメッセージのヘッダを生成する（Ｓ１−２３０６）。
【０１８７】
Ｈｅａｄｅｒ生成部２３ｅは、制御部２３ｂによって引き渡されたＨＴＴＰリクエストへの結果とデータ取得部２３ｄが生成したストリームなど、ヘッダ生成に必要なデータをもとに、ＨＴＴＰレスポンスヘッダを生成し制御部２３ｂへ返す（Ｓ１−２３０７）。
【０１８８】
制御部２３ｂは、生成したＨＴＴＰレスポンスヘッダとデータ取得部２３ｄが生成あるいは取得したストリームよりＨＴＴＰレスポンスを生成し情報送信部２３ｆに引き渡す。なお、制御部２３ｂは、クライアントとのコネクションが終了するか、コンテンツが終了するまで、送信を繰り返す（Ｓ１−２３０８）。
【０１８９】
情報送信部２３ｆは、制御部２３ｂによって引き渡されたＨｅａｄｅｒ生成部２３ｅが生成したヘッダとデータ取得部２３ｄが生成したストリームを該要求元端末へ送信する（Ｓ１−２３０９）。
【０１９０】
以下に情報送信部２３ｆが送出するHTTPレスポンスの一例を示す。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: video/mpeg
(空行)
[データ取得部２３ｄが生成したストリームのデータ]
【０１９１】
以上の処理により、通常再生、特殊再生のいずれの場合においても、ストリーム中のデータ放送に関連するイベントをクライアントへ送信することができるため、クライアント端末においてもデータ放送を再現することができる。
【０１９２】
次に、マルチメディアコンテンツ通信システム１０４を構成する、マルチメディアデータ受信装置１０２について説明する。
【０１９３】
図２４は、本実施の形態におけるマルチメディアデータ受信装置１０２の構成要素の関係を示したブロック図であり、入力部２４０１、第１メモリ２４０２、第２メモリ２４０３、多重分離手段２４０４、ＴＳデコーダ２４０５、映像出力部２４０６、音声出力部２４０７、ネットワーク部２４０８、ＣＰＵ２４０９で構成される。
【０１９４】
入力部２４０１、第１メモリ２４０２、第２メモリ２４０３は、上記した本実施の形態におけるマルチメディアデータ送信装置１０１の入力部２０１、第１メモリ２０２、第２メモリ２０３と同様のものである。なお、マルチメディアデータ受信装置１０２は、第２メモリ２４０３に、マルチメディアデータ送信装置１０１から受信したコンテンツ一覧やＥＰＧデータなどの、マルチメディアデータの識別子、タイトル、放送日時、放送チャンネルなど番組情報を蓄積する。
【０１９５】
多重分離手段２４０４は、ＣＰＵ２４０９からＭＰＥＧトランスポートストリームを受け取り、ＣＰＵ２４０９から指定された情報を抽出し、ＣＰＵ２４０９に引き渡す。また、ＭＰＥＧトランスポートストリームをそのままＴＳデコーダ２４０５に引き渡す。
【０１９６】
ＴＳデコーダ２４０５は、ＣＰＵ２４０９から、音声データ、映像データの識別子を受け取る。さらに、多重分離手段２４０４から受け取ったストリームから、受け取った音声データ、映像データの識別子に対応するデータを抽出する。抽出した映像データを映像出力部２４０６に、音声データを音声出力部２４０７に、それぞれ引き渡す。
【０１９７】
映像出力部２４０６、音声出力部２４０７は、上記した本実施の形態におけるマルチメディアデータ送信装置１０１の映像出力部２０８、音声出力部２０９と同様のものである。
【０１９８】
ネットワーク部２４０８は、ネットワークインタフェースを含み、ＣＰＵ２４０９から受け取ったデータを、ネットワークインタフェースが接続されたネットワークの物理メディアに応じた信号に変換して出力する。また、ネットワークインタフェースから信号を受信し、ＩＰネットワークで規定されたパケットに変換して、ＣＰＵ２４０９へ引き渡す。
【０１９９】
ＣＰＵ２４０９は、第２メモリ２４０３が記憶するプログラムを実行することで、多重分離手段２４０４、ＴＳデコーダ２４０５、ネットワーク部２４０８を制御する。
【０２００】
図２５は、第２メモリ２４０３に記憶され、ＣＰＵ２４０９に実行されるプログラムの構成図の一例である。
【０２０１】
プログラム２５００は、複数のサブプログラムで構成され、具体的にはＯＳ２５０１、ＪａｖａＶＭ２５０２、サービスマネージャ２５０３、Ｊａｖａライブラリ２５０４、ＨＮ−ＥＰＧアプリ２５０５で構成される。
【０２０２】
ＯＳ２５０１は、マルチメディアデータ受信装置１０２の電源が投入されると、ＣＰＵ２４０９が起動するサブプログラムである。ＯＳは、オペレーティングシステムの略であり、Ｌｉｎｕｘ等が一例である。ＯＳ２５０１は、他のサブプログラムを平行して実行するカーネル２５０１ａ及びライブラリ２５０１ｂで構成される公知の技術の総称であり、詳細な説明は省略する。本実施の形態においては、ＯＳ２５０１のカーネル２５０１ａは、ＪａｖａＶＭ２５０２をサブプログラムとして実行する。また、ライブラリ２５０１ｂは、これらサブプログラムに対して、マルチメディアデータ受信装置１０２が保持する構成要素を制御するための複数の機能を提供する。
【０２０３】
本実施の形態では、ライブラリ２５０１ｂは機能の一例として、限定解除２５０１ｂ１、ＡＶ再生２５０２ｂ２、ＮＥＴ２５０１ｂ３を含む。
【０２０４】
限定解除２５０２ｂ１は、他のサブプログラムやＪａｖａライブラリ２５０４のＣＡ２５０４ｃから情報を受け取り、ＡＶ再生２５０１ｂ２を有効にして、ネットワークから受信したマルチメディアデータの再生を許可したりするものである。
【０２０５】
ＡＶ再生２５０２ｂ２は、他のサブプログラムやＪａｖａライブラリ２５０４のＪＭＦ２５０４ａから、音声のパケットＩＤと映像のパケットＩＤを受け取る。受け取った音声のパケットＩＤと映像のパケットＩＤを、ＴＳデコーダ２４０５に与える。この結果、ＴＳデコーダ２４０５は与えられたパケットＩＤに基づいて、フィルタリングを行い、映像・音声の再生を実現する。
【０２０６】
ＮＥＴ２５０１ｂ３は、他のサブプログラムやＪａｖａライブラリ２５０４のネットワークライブラリ２５０４ｄから受け取ったデータを、ＩＰネットワークで規定されるアプリケーション層より下のプロトコルのパケットを作成する。アプリケーション層より下のプロトコルとは、例えばＴＣＰパケット、ＵＤＰパケット、ＩＰパケットなどである。これをネットワーク部２４０８に引き渡すことで、ネットワーク１０３を介して他の機器にメッセージおよびデータを送信する。また、ネットワーク１０３を介して他の機器からのメッセージを受信したときに、他のサブプログラムやＪａｖａライブラリ２５０４のネットワークライブラリ２５０４ｄに、アプリケーション層のプロトコルのパケットに変換して引き渡す。アプリケーション層のプロトコルとは、例えば、ＨＴＴＰ、ＲＴＳＰやＲＴＰなどである。
【０２０７】
ＨＮ−ＥＰＧ２５０５は、ユーザへネットワーク上に存在するマルチメディアデータ送信装置１０１が保持するマルチメディアデータの一覧を表示、及び、ユーザからの入力を受け付ける番組表示部２５０５ａと受信したコンテンツの再生を行う再生部２５０５ｂで構成される。ＨＮ−ＥＰＧ２５０５は、マルチメディア受信装置１０２の電源が投入されると、カーネル２５０１ａによって起動される。番組表示部２５０５ａは起動されると、入力部２４０１を通して、ユーザからの入力を待つ。
【０２０８】
ここで、入力部２４０１が図３で示されるフロントパネルで構成されている場合、ユーザが、入力部２５１のＥＰＧボタン３０７を押下すると、ＥＰＧボタンの識別子がＣＰＵ２４０９に通知される。ＣＰＵ２４０９上で動作するサブプログラムであるＨＮ−ＥＰＧ２５０５の番組表示部２５０５ａは、この識別子を受け取り、ホームネットワーク上の機器に録画された番組情報表示データを作成するため、ＪａｖａライブラリのＨＮ２５０４iを通し、ネットワークへ接続された機器情報及び各機器が保有するサービス情報及びマルチメディアコンテンツサーバのサービスを提供する機器に録画されたマルチメディアデータの情報を取得する。ＨＮ２５０４ｉは、ネットワークに接続された機器及びサービス及びコンテンツ情報を取得し記録する機能を持つ。ＨＮ２５０４ｉの処理については後述する。ここで、番組表示部２５０５ａがＨＮ２５０４ｉから取得したネットワークへ接続された機器及びサービス及びコンテンツの情報の一例を図２６に示す。なお、図２６に示したネットワーク上のマルチメディアデータ情報は、番組表示部２５０５ａがＨＮ２５０４ｉから取得し保持する形式でもよいし、番組表示部２５０５ａは該情報が必要なタイミングに、ＨＮ２５０４ｉより必要なデータを取得する形式でも良い。２６０１はネットワークに接続された機器識別子を示し、２６０２は機器名を示す。２６０３は該機器が保持するサービスの識別子である。なお、サービスの種類はＵＰｎＰ規格にて定められているが、ここではコンテンツを提供する機能をもつＭｅｄｉａＳｅｒｖｅｒをサービスの対象とする。また、２６０４は、該サービスが保有する録画済コンテンツの識別子を示し、２６０５は、コンテンツ名を示し、２６０６は該コンテンツへアクセスするためのマルチメディアデータＵＲＩを示す。
【０２０９】
次に、番組表示部２５０５ａは、取得した機器・サービス・マルチメディア情報を基に
図示していないモニタ出力手段によりモニタ２７１０に出力する。モニタ２７１０は、マルチメディアデータ受信装置１０２が備えるものであっても良いし、マルチメディアデータ受信装置１０２とコンポジットケーブルやＨＤＭＩケーブルなどで接続されたテレビであっても良い。モニタ２７１０は、受信した番組情報表示データを表示する。図２７は、モニタ２７１０に表示されたホームネットワークに接続された機器が録画したコンテンツの一例である。図２７において、２７１１は、コンテンツ名が「ニュース１」で録画された日時が「２００５／０３／３０  １１：００−１２：００」のコンテンツが「ＬｉｖｉｎｇＲｏｏｍ」の機器に存在していることを示す。また、２７１２は、コンテンツ名が「ドラマ１」で録画された日時が「２００５／０４／０１  ２１：００−２３：００」のコンテンツが「ＬｉｖｉｎｇＲｏｏｍ」の機器に存在することを示し、２７１３はコンテンツ名「ニュース２」で、録画された日時が「２００５／０５／０１  １：００−２：００」のコンテンツが「Ｋｉｔｃｈｅｎ」の機器に存在することを示す。更に、図２７では、カーソル２７３０が２７１１のコンテンツを選択している。
【０２１０】
図２７の状態で、フロントパネル３００のＯＫボタン３０５が押下されると、番組表示部２５０５ａは、選択されたコンテンツ２７１１の情報としてコンテンツ名と機器情報を再生部２５０５ｂに通知する。
【０２１１】
再生部２５０５ｂは、図２６に示すようなネットワーク上のマルチメディアデータ情報に基づき、受け取ったコンテンツ名および機器名を用いて、コンテンツ識別子とサービス識別子、機器識別子を取得する。再生部２５０５ｂは、ユーザによって選択されたネットワーク上のマルチメディアデータを再生するため、取得したコンテンツ識別子とサービス識別子、デバイス識別子をサービスマネージャ２５０３へ引き渡す。
【０２１２】
サービスマネージャ２５０３は、上記した本実施の形態におけるマルチメディアデータ送信装置１０１のサービスマネージャ４０４と、以下の相違点を除いて同様のものである。サービスマネージャ４０４はＥＰＧ１３０４の再生部４０２ｂよりチャンネル識別子を受け取り、その識別子をＴｕｎｅｒ４０５ｃに引き渡してチューニングさせ、さらにＣＡ４０５ｄに依頼してデスクランブルを行い、ＪＭＦ４０５ａにチャンネルの識別子を与えて映像・音声の再生を依頼するものであったが、サービスマネージャ２５０３は、ＨＮ−ＥＰＧ２５０５より機器識別子、サービス識別子、コンテンツ識別子を受け取り、ＪＭＦ２５０４ａへこれらの識別子を与え、ネットワークに存在するコンテンツの再生を依頼するものである。
【０２１３】
なお、早送りや巻き戻しなどの特殊再生に関しては、サービスマネージャ２５０３は、後述のＪＭＦ２５０４ａに特殊再生を依頼し、ネットワークライブラリ２５０４ｄを用いて、特殊再生に必要なデータを順次受信させることによって行う。
【０２１４】
Ｊａｖａライブラリ２５０４は、第２メモリ２４０３に格納されている複数のＪａｖａライブラリの集合である。本実施の形態では、Ｊａｖａライブラリ２５０４は、ＪＭＦ２５０４ａ、ＡＭ２５０４ｂ、ＣＡ２５０４ｃ、ネットワークライブラリ２５０４ｄ、再生Ｌｉｂ２５０４ｅ、ＨＮ２５０４ｉ等を含んでいる。
【０２１５】
ＡＭ２５０４ｂ、再生Ｌｉｂ２５０４ｅ、ＩＯ２５０４ｆ、ＡＷＴ２５０４ｇ、ＳＩ２５０４ｈは、それぞれ、上記した本実施の形態におけるマルチメディアデータ送信装置１０１のＪａｖａライブラリ４０５中のＡＭ４０５ｂ、再生Ｌｉｂ４０５ｆ、ＩＯ４０５ｇ、ＡＷＴ４０５ｈ、ＳＩ４０５ｉと同様のものである。
【０２１６】
ＪＭＦ２５０４ａは、受け取った機器識別子、サービス識別子、コンテンツ識別子を基に、ＨＮ２５０４ｉよりマルチメディアデータ送信装置１０１のＩＰアドレスなどの情報及びコンテンツのＵＲＩを取得する。そして、取得した情報をネットワークライブラリ２５０４ｄに与えて、マルチメディアデータ送信装置１０１へマルチメディアデータ送信要求発行とマルチメディアデータ送信装置１０１から送信されたマルチメディアデータの受信を依頼する。ネットワークライブラリ２５０４ｄは、依頼を受けると、マルチメディアデータ送信装置１０１と接続して、マルチメディアデータの送信要求を発行する。そして、ネットワークライブラリ２５０４ｄは、マルチメディアデータ送信装置１０１から送信されたデータを第１メモリ２４０２へ記録し、ＪＭＦ２５０４ａへ通知する。
ＪＭＦ２５０４ａは、第１メモリに記録されたマルチメディアデータを多重分離手段２４０４に引き渡すことで、該マルチメディアデータの再生が行える。
【０２１７】
ＣＡ２５０４ｃは、ネットワーク１０３経由で送信されてきたマルチメディアデータのコピー制御など、該マルチメディアデータの権利処理を管理するものである。コピー制御のための情報は、マルチメディアデータ送信装置１０１や、放送局１０５などのコンテンツ提供者、権利者が指定する外部のサーバなどから送信されてもよいし、マルチメディアデータ送信装置１０１から送信されてきたトランスポートストリームのＰＭＴに含まれているコピー制御情報を参照しても良い。
【０２１８】
ＨＮ２５０４ｉは、マルチメディアデータ送信装置１０１のようなネットワークに接続されたサーバ機器及び、該サーバ機器が保有するサービス及び、該サービスが提供するマルチメディアコンテンツ情報を取得し記録する機能を持つ。また、ＨＮ２５０４ｉは、ネットワーク１０３に接続されたサーバ機器の検索、および該サーバ機器が提供するサービスやマルチメディアコンテンツの情報およびコンテンツデータの取得を、ネットワークライブラリ２５０４ｄを通して行うことができる。なお、ＨＮ２５０４ｉは、ネットワークライブラリ２５０４ｄに含まれる構成であっても良い。また、ＨＮ２５０４ｉが管理するネットワーク上のマルチメディアデータ情報の一例が図２６である。本実施の形態では、ＨＮ−ＥＰＧ２５０５の番組表示部２５０５ａへ図２６のネットワーク上のマルチメディアデータ情報を提供し、番組表示部２５０５ａもが該情報を保持する一例を示したが、番組表示部２５０５ａは該情報が必要なタイミングに、ＨＮ２５０４ｉへ問合わせ、該情報を保持しない形式でも良い。
【０２１９】
ネットワークライブラリ２５０４ｄは、ＯＳ２５０１ｂのＮＥＴ２５０１ｂ３を通して、ネットワーク１０３に接続されたマルチメディアデータ送信装置１０１と通信するものである。マルチメディアデータ送信装置１０１との通信は、マルチメディアデータの一覧送受信、およびマルチメディアデータの送信要求発行と該マルチメディアデータの受信である。
【０２２０】
図２８は、ネットワークライブラリ２５０４ｄの内部構成の一例を表すブロック図である。ネットワークライブラリ２５０４ｄは、制御部２８０１ａ、接続管理部２８０１ｂ、メッセージ処理部２８０１ｃ、判定部２８０１ｄ、送受信部２８０１ｅを含む。なお、ネットワークライブラリ２５０４ｄは、ＩＰネットワークに関連する他の機能を含んでも良い。
【０２２１】
制御部２８０１ａは、マルチメディアデータ受信装置１０２上で実行される、ダウンロードしたＪａｖａアプリケーションもしくは、サービスマネージャ２５０３やＪａｖａライブラリ２５０４の他の構成要素にＪａｖａ  ＡＰＩを提供し、ネットワークライブラリ２５０４ｄが実現する機能を利用可能とするものである。接続管理部２８０１ｂは、制御部２８０１ａから依頼されて動作するものであり、マルチメディアデータ送信装置１０１のようなネットワーク１０３上の外部機器とのネットワーク接続を管理するものである。メッセージ処理部２８０１ｃは、制御部２８０１ａから依頼されて動作するものであり、制御部２８０１ａから受け取った情報を基に、ネットワーク接続を行っている外部機器へ送信するメッセージの生成を行うものである。判定部２８０１ｄは、制御部２８０１ａから依頼されて動作するものであり、外部機器から受信したレスポンスメッセージを制御部２８０１ａから受け取ってそれを解釈し、内容を制御部２８０１ａに通知するものである。送受信部２８０１ｅは、制御部２８０１ａからの依頼で動作するものであり、接続管理部２８０１ｂが管理し、制御部２８０１ａから引き渡されるネットワーク接続において、制御部２８０１ａから引き渡されたデータを送信し、また、前記ネットワーク接続からデータを受信して制御部２８０１ａに引き渡すものである。以下、これらの動作を説明する。
【０２２２】
まず、ネットワーク１０３に接続された外部機器が提供するコンテンツ一覧を取得する動作について説明する。
【０２２３】
まず、制御部２８０１ａは、ダウンロードしたＪａｖａアプリケーションやサービスマネージャ２５０３などからの依頼により、ネットワーク１０３に接続された機器の一覧を取得する。この機器一覧は、ＵＰｎＰ  ＤＡに定義された通信を行うことによって生成できる。また、このＵＰｎＰ  ＤＡに定義された通信は、外部機器から通知を受ける場合と、マルチメディアデータ受信装置１０２から、すなわち、制御部２８０１ａから問い合わせる場合とがある。外部機器から通知を受けた場合、制御部２８０１ａは、送受信部２８０１ｅが受信したＵＰｎＰ  ＤＡで定義されるメッセージを判定部２８０１ｄに解釈させ、その内容を得る。メッセージとは、サーバ機器もしくはサーバ機器が提供するサービスが、ネットワーク１０３を通して利用可能であることを通知するものである。続いて、制御部２８０１ａは、通知してきた外部機器に対して、ＵＰｎＰ  ＤＡで定義された、該サーバ機器もしくはサービスの情報の問い合わせメッセージを、メッセージ処理部２８０１ｃに生成させる。さらに、制御部２８０１ａは、生成したメッセージを送受信部２８０１ｅに与えて送信させ、該サーバ機器からの返答メッセージを受信させる。更に、制御部２８０１ａは、受信した返答メッセージを解釈させ、メッセージ処理部２８０１ｃに与えて解釈させることにより、該サーバ機器および該サーバ機器が提供するサービスの詳細を知ることができる。なお、これらの通信に用いられるネットワークコネクションは、接続管理部２８０１ｂによって管理される。
【０２２４】
また、制御部２８０１ａから問い合わせる場合は、まず、制御部２８０１ａは、メッセージ処理部２８０１ｃに依頼して、ＵＰｎＰ  ＤＡで定義されている機器の存在を問い合わせるメッセージを生成する。そして、生成したメッセージをメッセージ処理部２８０１ｃに依頼して、ネットワーク１０３にブロードキャストさせる。続いて接続管理部２８０１ｂに依頼して、前記ブロードキャストしたメッセージに対する返答を受信するために接続要求を受け付ける。接続管理部２８０１ｂより接続を受け入れたことを通知されれば、制御部２８０１ａは、送受信部２８０１ｅに依頼してメッセージを受信させる。さらに、制御部２８０１ａは、判定部２８０１ｄに依頼して、受信したメッセージを解釈させ、その情報を取得する。さらに、制御部２８０１ａは、メッセージ処理部２８０１ｃに依頼して、機器が提供するサービスや能力を問い合わせるメッセージを生成させ、送受信部２８０１ｅに依頼して、外部機器へ送信させる。さらに、制御部２８０１ａは、送受信部２８０１ｅに依頼して、送信したメッセージに対するレスポンスメッセージを受信させ、受信したメッセージを判定部２８０１ｄに与えて解釈させ、その内容を取得する。これにより、制御部２８０１ａは、ある外部機器の情報を得ることができる。
【０２２５】
上記のような処理を繰り返すことにより、マルチメディアデータ受信装置１０２は、ネットワーク１０３に接続されたサーバ機器、および該サーバ機器が提供するサービスの一覧を取得できる。
【０２２６】
続いて、制御部２８０１ａは、ダウンロードしたＪａｖａアプリケーションやサービスマネージャなどからの依頼により、ネットワーク１０３に接続された特定の外部機器が提供するコンテンツ一覧を取得する。以降、この特定の外部機器をマルチメディアデータ送信装置１０１として説明する。
【０２２７】
まず、制御部２８０１ａは、メッセージ処理部２８０１ｃに依頼して、ＵＰｎＰ  ＡＶで定義されたコンテンツ一覧送付依頼メッセージを生成する。このとき、Ｊａｖａアプリケーションなどから、コンテンツの条件を引き渡されていれば、その条件をメッセージ処理部２８０１ｃに与えて、適切なメッセージを生成する。続いて、制御部２８０１ａは、Ｊａｖａアプリケーションなどから与えられたマルチメディアデータ送信装置１０１のＩＰアドレスなどの情報を接続管理部２８０１ｂに与えて、マルチメディアデータ送信装置１０１とのネットワーク接続の情報を得る。そして、それを送受信部２８０１ｅに与える。このとき、マルチメディアデータ送信装置１０１とのネットワーク接続がまだ確立されていなかった場合には、接続管理部２８０１ｂは新たにマルチメディアデータ送信装置１０１との接続を確立する。続いて、制御部２８０１ａは、メッセージ処理部２８０１ｃが生成したコンテンツ一覧送付依頼メッセージを送受信部２８０１ｅに与えて、マルチメディアデータ送信装置１０１へ送信させる。さらに、制御部２８０１ａは、送受信部２８０１ｅに依頼して、マルチメディアデータ送信装置１０１からのレスポンスメッセージを受信させる。さらに、制御部２８０１ａは、受信したレスポンスメッセージを判定部２８０１ｄに与えて解釈させ、その内容であるコンテンツ一覧を取得する。制御部２８０１ａは、取得したコンテンツ一覧をＨＮ２５０４ｉへ引き渡す。
【０２２８】
次に、ＪＭＦ２５０４ａからの依頼により、マルチメディアデータ送信装置１０１からマルチメディアデータおよびその関連のデータを受信し、再生するときの処理について説明する。以下、ＪＭＦ２５０４ａからの依頼による処理を例に説明するが、ダウンロードしたＪａｖａアプリケーションからの依頼やサービスマネージャ２５０３から要求を受けたとしても同様である。
【０２２９】
ＪＭＦ２５０４ａは、サービスマネージャ２５０３より引き渡された機器識別子、サービス識別子、コンテンツ識別子を基に、ＨＮ２５０４ｉよりマルチメディアデータ送信装置１０１のＩＰアドレスなどの情報及びコンテンツのＵＲＩを取得する。そして、これらの情報をネットワークライブラリ２５０４ｄに与え、該マルチメディアデータ取得依頼を行う。
【０２３０】
ネットワークライブラリ２５０４ｄの制御部２８０１ａは、マルチメディアデータ取得依頼を受信すると、ＪＭＦ２５０４ａから引き渡された情報をのうち、少なくともマルチメディアデータ送信装置１０１のＩＰアドレスや該ネットワーク接続のためのポート番号などを接続管理部２８０１ｂに与え、接続管理部２８０１ｂに依頼して、マルチメディアデータ送信装置１０１とのネットワーク接続を確立する。
【０２３１】
接続管理部２８０１ｂは、制御部２８０１ａから引き渡された情報により、マルチメディアデータ送信装置１０１とのネットワーク接続を確立する。ネットワーク接続とは、例えば、マルチメディアデータの通信をＨＴＴＰで行う場合、ＨＴＴＰを行うためのＴＣＰコネクションをさす。なお、本実施の形態においては、接続管理部２８０１ｂにマルチメディアデータ送信装置１０１のＩＰアドレスやポート番号を与えるとしたが、取得するデータのＵＲＩを与え、接続管理部２８０１ｂがＵＲＩを解釈して、これらの情報を得る構成であっても良い。また、コンテンツの識別子を与え、接続管理部２８０１ｂがこれらの情報を取得する構成であっても良い。
【０２３２】
次に、制御部２８０１ａは、これらの取得要求をマルチメディアデータ送信装置１０１へ要求するために、メッセージ処理部２８０１ｃへ依頼し、対応するＨＴＴＰリクエストを生成する。
【０２３３】
メッセージ処理部２８０１ｃは、要求されたマルチメディアデータのＵＲＩをＨＴＴＰリクエストに設定する。更に、特殊再生を行う場合は、該マルチメディアデータの再生速度を、ＨＴＴＰリクエストに設定する。再生速度の設定は、ＤＬＮＡで定義されている“PlaySpeed.dlna.org”拡張ヘッダを用いることにより行える。例えば、５倍速再生の場合には、“PlaySpeed.dlna.org: speed=5”をＨＴＴＰレスポンスヘッダに加える。以下に、マルチメディアデータのＵＲＩをhttp://192.168.0.3/AVData/0001.m2tsとし、要求された特殊再生が５倍速再生の場合のＨＴＴＰリクエストの例を示す。
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
PlaySpeed.dlna.org : speed= 5
【０２３４】
続いて、制御部２８０１ａは、以上のように生成したＨＴＴＰリクエストを送受信部２８０１ｅに与え、マルチメディアデータ送信装置１０１へ送信させる。
【０２３５】
次に、制御部２８０１ａは送受信部２８０１ｅに依頼して、マルチメディアデータ送信装置１０１よりＨＴＴＰレスポンスを受信する。受信したＨＴＴＰレスポンスの例を以下に示す。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: video/mpeg
PlaySpeed.dlna.org: speed=5
(空行)
[マルチメディアデータ送信装置１０１のデータ取得部２３ｄが生成したストリームのデータ]
【０２３６】
そして、制御部２８０１ａは、受信したＨＴＴＰレスポンスメッセージを、判定部２８０１ｄへ引き渡し、その解釈を依頼する。
【０２３７】
判定部２８０１ｄでは、まず、ＨＴＴＰレスポンスのレスポンスコードを確認する。結果が２００  ＯＫの場合は、それを制御部２８０１ａに伝える。すると、制御部２８０１ａは、ＨＴＴＰレスポンスのボディ部にある受信したマルチメディアデータを第１メモリ２４０２へ記録し、ＪＭＦ２５０４ａ（またはコンテンツ取得依頼を行ったライブラリ）へ通知する。
【０２３８】
そして、ＪＭＦ２５０４ａは、通知を受けた第１メモリに記録されたマルチメディアデータのトランスポートストリームをＴＳデコーダ２４０５へ引き渡す。このとき、ＪＭＦ２５０４ａは、ＰＡＴを取得するため、ＯＳ２５０１のライブラリ２５０１ｂを通して、ＴＳデコーダ２４０５へＰＡＴのＰＩＤ「０」を指定する。ＴＳデコーダ２４０５がＰＩＤ「０」及びｔａｂｌｅ＿ｉｄ「０」でフィルタリングを行い、第１メモリ２４０２を通してＣＰＵ２４０９に引き渡すことで、ＪＭＦ２５０４ａは、ＰＡＴを収集する。ネットワークから取得したＰＡＴは、マルチメディアデータ送信装置１０１によって唯一のプログラムのみが存在するように書き換えられているので、ＰＡＴ内に含まれるプログラムのＰＭＴを伝送するＰＩＤを取得する。ここでは、マルチメディアデータ送信装置１０１が図９のＰＡＴより唯一のプログラムとして９１１を選択した場合（９１２及び９１３のプログラムを削除した場合）を想定し、ＰＭＴのＰＩＤとして「５０１」を獲得する。次に、ＪＭＦ２５０４ａは、ＰＭＴを取得するため、ＴＳデコーダ２４０５にＰＩＤ「５０１」及びｔａｂｌｅ＿ｉｄ「２」を指定し、フィルタリングを行い、第１メモリ２４０２を通してＣＰＵ２４０９に引き渡すことで、ＪＭＦ２５０４ａはＰＭＴの収集をする。一例として、ＪＭＦ２５０４ａが図１６のＰＭＴを取得した場合を説明する。ＪＭＦ２５０４ａは、図１６を参照して、ＪＭＦ４０５ａは、行１０１１から音声のＰＩＤ「５０１１」を、行１０１２から映像のＰＩＤ「５０１２」を獲得する。受け取った音声のパケットＩＤと映像のパケットＩＤを、ＴＳデコーダ２４０５に与える。この結果、ＴＳデコーダ２４０５は与えられたパケットＩＤに基づいて、フィルタリングを行い、映像・音声の再生を実現する。
【０２３９】
最後にサービスマネージャ２５０３は、Ｊａｖａライブラリ２５０４の中にあるＡＭ２５０４ｂに機器識別子、サービス識別子、コンテンツ識別子を与え、データ放送再生を依頼する。ＡＭ２５０４ｂの処理は、マルチメディアデータ送信装置１０１のＡＭ４０５ｂと同等であるため、説明を省略する。
【０２４０】
このように、本実施の形態ではデータ放送に関連するイベントの発生を通知するセクションは必ずマルチメディアデータ送信装置１０１によって、ネットワークから取得するストリームに含まれているため、マルチメディア受信装置１０２は、受信したトランスポートストリームを放送波から受信したストリームと同様に扱うことで、データ放送を実現することができる。
【０２４１】
（実施の形態２）
実施の形態１では、マルチメディアデータ受信装置１０２がデータ放送を再生する際に、必要となるイベントデータを、マルチメディアデータ送信装置１０１が特殊再生中であっても必ずストリームに挿入する方法を説明した。つまり、実施の形態１では、データ放送用データに関しては、特別な処理は行わず、本来ストリーム中にＤＳＭ−ＣＣ方式にて繰り返しエンコードされている、ファイルシステムを構成するデータ放送用データから取得する方法であった。実施の形態１の手法は、ＤＳＭ−ＣＣによって伝送されるデータ放送用データが十分小さくストリーム中に繰返し含まれているため、マルチメディア受信装置１０２が特殊再生中にデータ放送用データを取得できないことがあった場合でも、ユーザが許容できる時間内に再度データ放送用データがストリーム中に含まれ、マルチメディアデータ受信装置１０２が要求するデータ放送用データを取得できる場合を想定したものである。
【０２４２】
一方、本実施の形態では、ＤＳＭ−ＣＣによって伝送するデータ放送用データが大きく、特殊再生などの理由によりデータ取得が行えなかった場合に、次回のストリームに含まれる時刻まで待てないような場合も想定できる。そこで、本実施の形態では、データ放送用データをストリームとは別の方式で取得する手法を説明する。
【０２４３】
ここで、ＤＳＭ−ＣＣの構成を図２９に示す。図２９は、ＤＳＭ−ＣＣ規格で定められたＤＳＭ−ＣＣセクションとファイルやディレクトリなどのオブジェクトの関連を表す。ＤＳＭ−ＣＣセクション２９０１には、伝送するデータの構成情報を含むＤＳＩやＤＩＩセクションと、実際のデータを含むＤＤＢというセクションが存在する。ＤＳＩ及びＤＩＩの情報に基づきＤＤＢをつなぎ合わせることでＭｏｄｕｌｅ２９０２を構成し、このＭｏｄｕｌｅ２９０２をＤＳＭ−ＣＣの規則に従い分割することでファイル及びディレクトリなどのＯｂｊｅｃｔ２９０３を取得できる。そのため、マルチメディアデータ送信装置１０１とマルチメディアデータ受信装置１０２間の通信には、これらの３つのデータ形式を用いた方法が考えられる。
・ＤＳＭ−ＣＣセクションで通信する形式
・ＤＳＭ−ＣＣ  Ｍｏｄｕｌｅで通信する形式
・ファイル及びディレクトリなどＤＳＭ−ＣＣ  Ｏｂｊｅｃｔで通信する形式
【０２４４】
まず、本実施の形態におけるマルチメディアデータ送信装置１０１について説明する。
【０２４５】
本実施の形態におけるマルチメディアデータ送信装置１０１を構成する構成要素の関係を示すブロック図の一例は、図２と同じである。また、第２メモリ２０３に記憶され、ＣＰＵ２１２に実行されるプログラムの構成図の一例は、図１３と同様のため説明を省略する。ただし、蓄積管理ライブラリ１３０２は、その内部構成が異なるものとなるため、以下にその構成の一例を示す。
【０２４６】
本実施の形態における蓄積管理ライブラリ１３０２の構成を図３０および図３１に示す。
【０２４７】
図３０において、蓄積管理ライブラリ１３０２は、データ取得部３００１および、制御部３００２、イベントテーブル生成部１４０３、データテーブル生成部３００３を備える。このうち、イベントテーブル生成部１４０３は、実施の形態１におけるイベントテーブル生成部１４０３と同様の処理を行うため、説明は省略する。
【０２４８】
蓄積管理ライブラリ１３０２のデータ取得部３００１は、前述したデータ放送を再生するために必要なイベントを取得し、第２メモリ２０３へ蓄積し、イベントを管理するイベントテーブル生成部１４０３へ通知する機能に加え、データ放送用データを取得し、第２メモリ２０３へ蓄積すると共にデータテーブル生成部３００３あるいは制御部３００２、あるいは両方へ通知する機能を有する。
【０２４９】
データ取得部３００１の構成要素において、図１８Ａで示したアプリケーション構成情報取得監視部１８０２及びデータ放送用ストリーム情報取得監視部１８０４については、実施の形態１と同様の処理を行う。
【０２５０】
一方、ストリーム構成情報取得監視部３１０１は、ストリーム構成情報取得監視部１８０１に加え、サービス録画開始時に取得したＰＡＴ、ＰＭＴ及びバージョンアップが発生したＰＡＴ、ＰＭＴのデータを制御部３００２あるいはカルーセルデータ取得部３１０５あるいは両方へ引き渡す。
【０２５１】
カルーセル構成情報取得監視部３１０３は、カルーセル構成情報取得監視部１８０３に加え、サービス録画開始時に取得したＤＳＩ及びＤＩＩ及びバージョンアップが発生したＤＳＩ及びＤＩＩのデータを制御部３００２あるいはカルーセルデータ取得部３１０５あるいは両方へ引き渡す。
【０２５２】
カルーセルデータ取得部３１０５は、カルーセル構成情報取得監視部３１０３から引き渡された図示していないＤＳＩを参照し、ＤＳＩに含まれるＤＩＩ識別子を基に該当するＤＩＩを収集する。図３２は、収集したＤＳＩの情報の一例を模式的に表した表である。図３２において、３２０１はＭｏｄｕｌｅ識別子が含まれる。３２０２は、Ｍｏｄｕｌｅを伝送するエレメンタリーストリームを識別するＡｓｓｏｃｉａｔｉｏｎ  ｔａｇを含む。Ａｓｓｏｃｉａｔｉｏｎ  ｔａｇは、ＰＭＴを参照し、指定されたＡｓｓｏｃｉａｔｉｏｎ  ｔａｇと同じＡｓｓｏｃｉａｔｉｏｎ  ｔａｇが含まれるＡｓｓｏｃｉａｔｉｏｎ  ｔａｇ  Ｄｅｓｃｒｉｐｔｏｒが存在するエレメンタリーストリームのＰＩＤを取得することができる。３２０３は、Ｍｏｄｕｌｅのバージョンを示す。３２０４は、Ｍｏｄｕｌｅのサイズを示す。なお、ＤＩＩは３２１１〜３２１３のように複数のＭｏｄｕｌｅ情報を含む。ここで、ＭｏｄｕｌｅはＤＳＭ−ＣＣセクションのＤＤＢというセクションで伝送される。そのため、Ｍｏｄｕｌｅを取得するとは、
・列３２０２のＡｓｓｏｃｉａｔｉｏｎＴａｇを用いて取得したＰＩＤとｔａｂｌｅ＿ｉｄ「３ｂ」をＴＳデコーダに設定しフィルタリングすることで、ＤＤＢセクションを取得する。
・各ＤＤＢセクションのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒにＤＤＢセクションを並べる順番が含まれるため、取得したｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒに従いＤＤＢセクションを並べる。なお、各ＤＤＢセクションには伝送するデータサイズが含まれるため、取得したＤＤＢセクションのデータサイズを合計し、３２０４のＭｏｄｕｌｅサイズに達するまで取得する。
ことを言う。なお、詳細は前述したＤＳＭ−ＣＣ規格１３８１８−６及びＭＨＰ／ＯＣＡＰ規格を参照されたい。
【０２５３】
（ＤＳＭ−ＣＣセクションで通信する方式）
まず、マルチメディアデータ送信装置１０１からマルチメディアデータ受信装置１０２にデータ放送用データで再生に使用される実データをＤＳＭ−ＣＣセクションとして伝送する場合を説明する。上述した方法により、カルーセルデータ取得部３１０５は、ＤＩＩに含まれるＭｏｄｕｌｅ情報３２１１〜３２１３に従い、Ｍｏｄｕｌｅを構成するＤＤＢセクションを取得し、第１メモリ２０２へ記録する。そして、データテーブル生成部３００３へ通知する。
【０２５４】
次に、カルーセルデータ取得部３１０５は、ストリーム構成情報取得監視部３１０１あるいはカルーセル構成情報取得監視部３１０３、または制御部３００２からＰＡＴ、ＰＭＴ、およびＤＳＩの少なくともひとつのバージョンアップを受け取ると、ＤＳＭ−ＣＣセクションの取得を停止する。
【０２５５】
また、カルーセルデータ取得部３１０５は、カルーセル構成情報取得監視部３１０３から、ＤＩＩのバージョンアップを受け取ると、カルーセルデータ取得部３１０５が保持するバージョンアップ前のＤＩＩのＴｒａｎｓａｃｔｉｏｎＩＤを確認し、バージョンアップ前のＤＩＩを取得する。そしてバージョンアップ前のＤＩＩとバージョンアップ後のＤＩＩを比較し、列３２０３に示すＭｏｄｕｌｅのバージョンが変更されているＭｏｄｕｌｅを検出する。これによりバージョンアップが発生したＭｏｄｕｌｅを特定することができるため、最新のＤＩＩより変更されたＭｏｄｕｌｅを伝送しているＡｓｓｏｃｉａｔｉｏｎＴａｇを取得し、エレメンタリーストリームのＰＩＤを取得する。そして、該当Ｍｏｄｕｌｅを伝送するＤＳＭ−ＣＣセクションを新たに取得し、第１メモリ２０２へ記録する。そして、データテーブル生成部３００３へ通知する。
【０２５６】
データテーブル生成部３００３は、データ放送に関連するデータの格納場所を管理するテーブルを生成し、カルーセルデータ取得部３１０５が取得したＤＳＭ−ＣＣセクションなどデータ放送に関連するデータを第２メモリ２０３に記録しデータを管理する。図３３Ａに、データテーブル生成部３００３が生成するテーブルの一例を示す。なお、図３３Ａのデータテーブルは、ＤＳＩおよびＤＩＩの情報を示す３３００のメインテーブルと、ＤＩＩに含まれる情報を示す３３００−１のＤＩＩ参照情報管理テーブルから構成される。３３０１はメディアタイムを示す。なお、この時間は録画ストリームの開始からの位置が特定できる情報なら他の情報であってもよい。３３０２は、受信したセクションの識別子を示す。３３０３は、各セクションデータの格納場所（例えばセクションデータに対応するデータの先頭位置を示す第２メモリのアドレス情報など）を示す。３３０４は、ＤＩＩから参照される情報を構成するセクションを管理するＤＩＩ参照情報管理テーブル３３００−１への参照を示す。なお、ここではＤＩＩ参照情報管理テーブル３３００−１の説明のため、図３２のＤＩＩを例に説明する。３３３１はＭｏｄｕｌｅ識別子である。３３３２はＭｏｄｕｌｅのバージョンを示す。３３３３は、３３３１のＭｏｄｕｌｅの実データを伝送するＤＤＢセクションへの参照を示す。３３３３−１がＤＤＢセクションのＢｌｏｃｋＮｕｍｂｅｒを示す。ＢｌｏｃｋＮｕｍｂｅｒは、Ｍｏｄｕｌｅを構成するＤＤＢセクションを並べる順番を示す。３３３３−２は、ＤＤＢセクションの格納場所（例えばＤＤＢセクションに対応するデータの先頭位置を示す第２メモリのアドレス情報など）を示す。なお、これ以降のデータも同様の形式でＢｌｏｃｋＮｕｍｂｅｒとＤＤＢセクションの格納場所の組で保持するものとする。３３２１はＭｏｄｕｌｅ識別子が「０ｘ０００１」でＭｏｄｕｌｅのバージョンが「０」、Ｍｏｄｕｌｅを構成するＤＤＢセクションとして、ＢｌｏｃｋＮｕｍｂｅｒが「０」のＤＤＢセクションからＭｏｄｕｌｅを構成していることが分かる。また、３３２２はＭｏｄｕｌｅ識別子が「０ｘ０００２」でＭｏｄｕｌｅのバージョンが「１」、Ｍｏｄｕｌｅを構成するＤＤＢセクションとして、ＢｌｏｃｋＮｕｍｂｅｒが「０」のＤＤＢセクションからＢｌｏｃｋＮｕｍｂｅｒが「３」のＤＤＢセクションの４つのＤＤＢセクションでＭｏｄｕｌｅを構成していることが分かる。
【０２５７】
次に、図３３Ｂは、ＤＩＩのバージョンアップが発生したときのテーブルの一例を示す。ＤＩＩを受け取ると、受信したＤＩＩの情報を３３１２に追加し、バージョンアップ前のＤＩＩ３３１１と比較する。そして、更新されたＭｏｄｕｌｅが０ｘ０００２のＭｏｄｕｌｅであることが分かると、ＤＩＩ参照情報管理テーブル３３００−２を生成する。なお、ここでは、ＤＩＩ参照情報管理テーブルとして、バージョンアップが発生した０ｘ０００２のみをＤＩＩ参照情報管理テーブル３３００−２で管理する一例を示すが、バージョンアップされたＭｏｄｕｌｅを管理できる方法であれば他の方法であってもよい。
【０２５８】
なお、ここではデータテーブルは、カルーセルデータ取得部３１０５が記録した第２メモリ２０３への参照を保持することでデータの格納場所を保存する形式としたが、カルーセルデータ取得部３１０５はデータ放送用データをストリームと別記録せず、図２２のストリーム関連テーブル２２００の列２２０３に指定された第２メモリ２０３に存在する録画ストリームの位置をデータテーブル生成部３００３へ通知し、マルチメディアデータ受信装置１０２からデータ放送用データの取得要求があったときに、データテーブル生成部３００３が生成したテーブルを参照し、録画ストリームから取得する方法でもよい。
【０２５９】
蓄積管理ライブラリ１３０２の制御部３００２は、第２メモリ２０３に蓄積された管理テーブルやデータ毎の格納場所及び必要なデータを管理する。また、ストリーム構成情報取得監視部３１０１より、バージョンアップの通知を受け取ると、ストリーム構成情報取得監視部３１０１にＰＩＤ指定を行うために利用したＰＡＴあるいはＰＭＴと比較し、該当するＤＳＭ−ＣＣ識別子を伝送するＥＳのＰＩＤなどが変化している場合は、カルーセルデータ取得部３１０５及びデータテーブル生成部３００３に通知する。
【０２６０】
次に、マルチメディアデータ送信装置１０１のネットワークライブラリ４０５ｅが、マルチメディアデータ受信装置１０２から以下のようなリクエストメッセージを受信した場合を例に説明する。
＜セクションのリクエスト１＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Section&pid=0x5014&table_id=0x3B  HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
【０２６１】
この例は、リクエストメッセージに含まれるＵＲＩに、セクションのリクエストを含めたものである。この例においては、ＩＰアドレスが１９２．１６８．０．３のサーバ上の／ＡＶＤａｔａ／０００１．ｍ２ｔｓで表されるストリームからのセクション取得の要求であり、“type=Section”でセクション取得の要求を表し、“pid=0x5014”で要求するセクションの「ｐｉｄ」が「０ｘ５０１４」であることを、“table_id=0x3B”で要求するセクションのｔａｂｌｅ＿ｉｄが「０ｘ３Ｂ」であることを示している。
【０２６２】
またセクション取得要求は、ＨＴＴＰリクエストに拡張ヘッダＸ−Ｓｅｃｔｉｏｎ−Ｒｅｑｕｅｓｔをつけることによって行ってもよい。この場合は、拡張ヘッダＸ−Ｓｅｃｔｉｏｎ−Ｒｅｑｕｅｓｔは、要求するマルチメディアデータ中のセクションの種類、送信を要求するセクション情報をセミコロン“；”で区切ることとする。生成した拡張ヘッダの一例を以下に示す。
X-Section-Request: type = section ; pid = 0x5014; table_id = 0x3B
【０２６３】
したがって、マルチメディアデータ受信装置１０２からマルチメディアデータ送信装置１０１へ、以下の例のようなＨＴＴＰリクエストが発行される。
＜セクションのリクエスト２＞
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
X-Section-Request: type = section ; pid = 0x5014; table_id = 0x3B
【０２６４】
このように、セクションを要求していることを示す情報と、ＰＩＤ及びｔａｂｌｅ＿ｉｄといった取得したいセクションを識別できる情報を指定できる方法であれば他の識別子を利用してもよいし、どのようなリクエストであってもよい。
【０２６５】
また、バージョンアップによって更新されるセクションを取得するためには、マルチメディアデータ受信装置１０２が取得したいセクションを特定できるように、要求するセクションを取得するタイミングを通知する。なお、ここではタイミングを通知する方法の一例としてメディアタイムを利用する方法を説明するが、タイミングを通知する方法としては、メディアタイムやNPT、ストリーム中のバイト位置などストリーム中に位置を特定できる情報であれば、指定形式はどのような方法であってもよい。
＜セクションのリクエスト３＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Section&pid=0x5014&table_id=0x3B&media_time=00:10:00 HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
【０２６６】
また、開始時間以降のセクションを指定のタイミング以降連続して取得する場合、メディアタイムの指定の後に“-”を指定する（下記の例では“media_time”の開始時間として“00:10:00”を指定した後に“-”を指定することにより、メディアタイムの開始時間が“00:10:00”以降のセクションを連続して取得を要求する例を示す）。そのため、録画ストリームの最後までのセクションの取得要求を行う場合は、次のようなリクエストとなる。
＜セクションのリクエスト４＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Section&pid=0x5014&table_id=0x3B& media_time=00:10:00- HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
【０２６７】
また、開始位置を指定する以外に、取得要求を行う期間を指定するという方法であってもよい。この場合、開始のタイミングと終了のタイミングを“-”でつなげることで表現する。そのため、期間（例えばメディアタイムが“00:10:00-00:30:00”）を指定した取得要求を行う場合は、次のようなリクエストとなる。
＜セクションのリクエスト５＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Section&pid=0x5014&table_id=0x3B& media_time=00:10:00-00:30:00 HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
【０２６８】
なお、上記のような指定方法以外にも、ＤＬＮＡで定義されているＴｉｍｅＳｅｅｋＲａｎｇｅ．ｄｌｎａ．ｏｒｇ拡張ヘッダを利用してメディアタイムの範囲を指定する方法や、ＨＴＴＰ１．１で定義されているＲａｎｇｅヘッダを利用してストリームのバイト位置の範囲を指定するなど、要求するセクションを特定できるような情報であればどのようなリクエストであってもよい。
【０２６９】
ネットワークライブラリ４０５ｅは、図２３Ａに構成要素を示した実施の形態１と、以下の相違点を除いて同様の処理を行う。以下に、処理の異なるものについて、詳細に説明する。
【０２７０】
要求受信部２３ａは、リクエストメッセージを受信した場合は、該リクエストメッセージから、少なくとも要求されたコンテンツ及びセクション情報を取得し、制御部２３ｂへ引き渡す。
【０２７１】
制御部２３ｂは、受信したリクエストメッセージが正しいものであれば、制御部２３ｂは、クライアントより指定された録画ストリームの識別子（ここでは、０００１．ｍ２ｔｓ）とセクションの取得条件（ＰＩＤ＝０ｘ５０１４、ｔａｂｌｅ＿ｉｄ＝３Ｂ、ＭｅｄｉａＴｉｍｅ＝００：１０：００）を取得し、データ取得部２３ｄへ引き渡す。制御部２３ｂは、データ取得部２３ｄからの結果や要求されたＴｙｐｅやセクション条件などヘッダ生成に必要な情報をＨｅａｄｅｒ生成部２３ｅに引き渡し、ＨＴＴＰレスポンスメッセージのヘッダを生成する。なお、制御部２３ｂは、データ取得部２３ｄが取得したセクションを含めＨＴＴＰレスポンスを生成する。なお、このとき、複数のセクションを送る場合には、それらを連続して送信し、受信したマルチメディアデータ受信装置１０２で受信データを解析し、各セクションを取得する方法であっても良い。また、ＨＴＴＰ１．１で定義されているチャンク形式転送エンコーディング（Ｃｈｕｎｋｅｄ  Ｔｒａｎｓｆｅｒ  Ｃｏｄｉｎｇ）を利用して、各セクションごとにチャンクを形成して送信する方法であっても良い。そして、生成したＨＴＴＰメッセージを情報送信部２３ｆに引き渡して、該要求元端末へ送信する。なお、制御部２３ｂは、クライアントからの要求を満たすか、あるいはコネクションが終了するか、録画ストリームが終了するまで、送信を繰り返す。
【０２７２】
次に、図３４に録画ストリームとイベントテーブル、データテーブルの関連を示すストリーム関連テーブル（３４００）を示す。列３４０６は、データテーブルの識別子であり、列３４０７はデータテーブルの格納場所（例えばデータテーブルに対応するデータの先頭位置を示す第２メモリのアドレス情報など）を示す。
【０２７３】
以下、ストリーム関連テーブルとして図３４に示す３４００を、イベントテーブルは図２０に示した２０００を用いて、データテーブルは図３３Ａまたは図３３Ｂに示した３３００の表を用いて説明する。データ取得部２３ｄは、ＩＯ４０５ｇに依頼して図３４に示すストリーム関連テーブル３４００を読み出す。データ取得部２３ｄは、制御部２３ｂによって引き渡された識別子と列３４０１を参照し録画ストリーム識別子を比較し、制御部２３ｂによって引き渡された識別子に関連するコンテンツの存在を確認する。存在しない場合には、そのエラー内容を制御部２３ｂへ通知し終了する。一方、存在した場合は、データテーブル識別子３４０６とデータテーブルの格納場所３４０７を取得する。次に、データ取得部２３ｄは、取得したデータテーブルの名前などの識別子３４０６とそのデータテーブルの格納場所３４０７をもとに、データテーブル３３００を取得する。
【０２７４】
データ取得部２３ｄは、指定されたｔａｂｌｅ＿ｉｄを確認する。ｔａｂｌｅ＿ｉｄとしては、ＰＡＴは「０」、ＰＭＴは「２」、ＡＩＴは「７４」、ＤＳＩ・ＤＩＩは「３Ｂ」、ＤＤＢは「３Ｃ」とする。データ取得部２３ｄは、ｔａｂｌｅ＿ｉｄ「０」及び、ｔａｂｌｅ＿ｉｄ「２」、ｔａｂｌｅ＿ｉｄ「７４」が指定された場合は、イベントテーブル２０００を取得し、指定されたメディアタイム及びＰＩＤを参照し、要求されたリクエストに関連するセクションをイベントテーブル２０００より取得する。なお、ｔａｂｌｅ＿ｉｄ「３Ｂ」の場合はイベントテーブル２０００を参照してもデータテーブル３３００を参照してもよい。
【０２７５】
ここで、セクションのリクエスト３により、「ｐｉｄ」が「０ｘ５０１４」、ｔａｂｌｅ＿ｉｄが「０ｘ３Ｂ」でメディアタイムが「１０：００」のセクションを要求された場合、例えばイベントテーブル２０００を参照し、行２０１５の列２００４に示す格納場所に格納されたＤＩＩセクションが条件に一致することがわかる。また、セクションのリクエスト４及びセクションのリクエスト５を受信した場合は、行２０１６の列２００４に示す格納場所に格納されたＤＩＩも条件に一致する。そこでデータ取得部２３ｄは、条件に一致したＤＩＩセクションを取得し、制御部２３ｂへ引き渡す。なお、該当するセクションが存在しなかった場合などには、該当セクションが存在しなかった旨を制御部２３ｂへ引き渡す方法でもよい。また、指定されたコンテンツをストリーム関連テーブル２２００の録画ストリームの格納場所２２０３より取得し、録画ストリームから該当セクションを抽出することで、制御部２３ｂへ引き渡すという方法であってもよい。
【０２７６】
また、データ取得部２３ｄは、指定されたセクションがｔａｂｌｅ＿ｉｄ「３Ｃ」の場合は、データテーブル３３００を取得し、指定されたメディアタイムの時刻に有効なＤＳＩ及びＤＩＩを選択し、格納場所に記録されたＤＳＩ及びＤＩＩを参照し指定されたＰＩＤで送信されているＭｏｄｕｌｅ識別子を全て取得し、該当するＭｏｄｕｌｅ識別子に関連づけて記録しているセクションを順に制御部２３ｂへ引き渡す。なお、ここではセクションを識別する情報をリクエストに指定した場合について説明しているため、指定されたＰＩＤなどのセクション条件に応じてマルチメディアデータ受信装置へ送出するとしたが、リクエストでＣａｒｏｕｓｅｌＩＤなどＤＳＭ−ＣＣ識別子を指定し、指定されたＤＳＭ−ＣＣ識別子関連する全てのセクションをマルチメディアデータ受信装置１０２へセクションを送信する方法でもよい。
【０２７７】
Ｈｅａｄｅｒ生成部２３ｅは、制御部２３ｂによって引き渡されたＨＴＴＰリクエストへの結果など、ヘッダ生成に必要なデータをもとに、ＨＴＴＰレスポンスのヘッダを生成し制御部２３ｂへ返す。
【０２７８】
情報送信部２３ｆは、制御部２３ｂによって引き渡されたＨｅａｄｅｒ生成部２３ｅが生成したＨＴＴＰレスポンスヘッダとデータ取得部２３ｄが取得したデータを該要求元端末へ送信する。
【０２７９】
以下に情報送信部２３ｆが送出するHTTPレスポンスの一例を示す。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: application/octet-stream
(空行)
[要求されたセクションデータ]
【０２８０】
なお、Ｈｅａｄｅｒ生成部２３ｅは、該ＨＴＴＰレスポンスに含まれるセクションデータの種類を示す拡張ヘッダを生成してもよい。一例として、拡張ヘッダＸ−Ｓｅｃｔｉｏｎ−Ｉｎｆｏを用い、ＰＩＤおよびｔａｂｌｅ＿ｉｄなどＨＴＴＰレスポンスに含まれるデータをフィルタリングした条件や、該セクションがストリーム中に存在したタイミングであるメディアタイムを表すものとする。もちろん、ＨＴＴＰリクエストで指定された条件を含んでもよい。なお、拡張ヘッダＸ−Ｓｅｃｔｉｏｎ−Ｉｎｆｏが含む情報は、該ＨＴＴＰレスポンスに含まれるデータを識別できる情報であれば、他の情報であってもよい。
X-Section-Info: type = section ; pid = 0x5014; table_id = 0x3B; media_time=00:10:00
【０２８１】
すなわち、該ＨＴＴＰレスポンスに含まれるデータの情報を含む拡張ヘッダを含むＨＴＴＰレスポンスは、次のようなレスポンスになる。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: application/octet-stream
X-Section-Info: type = section ; pid = 0x5014; table_id = 0x3B; media_time=00:10:00
(空行)
[要求されたセクションデータ]
【０２８２】
また、ここでは拡張ヘッダを用いてＨＴＴＰレスポンスに含まれる情報を記述する方法を説明したが、他の形式でマルチメディアデータ受信装置１０２へ通知してもよい。
【０２８３】
以上の処理により、マルチメディアデータ受信装置１０２の要求に応じてセクションを構成するデータを送出することができる。
【０２８４】
（ＤＳＭ−ＣＣ  Ｍｏｄｕｌｅで通信する方式）
次に、マルチメディアデータ送信装置１０１からマルチメディアデータ受信装置１０２にデータ放送用データで再生に使用される実データをＤＳＭ−ＣＣ  Ｍｏｄｕｌｅとして伝送する場合を説明する。
【０２８５】
Ｍｏｄｕｌｅで伝送する場合もセクションで伝送する場合と同等の処理を行う。但し、ＤＳＭ−ＣＣ  セクションで通信する方式の場合は、データテーブル生成部３００３が、第２メモリ２０３へ記録するデータをＤＳＭ−ＣＣセクションとして記録していたのに対し、ＤＳＭ−ＣＣ  Ｍｏｄｕｌｅで通信する場合は、第２メモリへ保存する際に、ＤＳＭ−ＣＣセクションからＭｏｄｕｌｅへ変更し記録する方式であってもよい。なお、ＤＳＭ−ＣＣセクションからＭｏｄｕｌｅを生成する方法は、Ｍｏｄｕｌｅを構成するＤＳＭ−ＣＣセクションに対し、ＢｌｏｃｋＮｕｍｂｅｒの順番で各セクションのペイロードをつなぎあわせることで生成できる。ここで、データテーブル生成部３００３が生成するテーブルの一例を図３５Ａ及び図３５Ｂに示す。なお、図３３Ａまたは図３３Ｂと同じ番号を付したものは、図３３Ａまたは図３３Ｂと同様の内容であるため、説明を省略する。図３５Ａにおいて、ＤＩＩ参照情報管理テーブル３５００−１の３５３２は、カルーセルデータ取得部３１０５が第１メモリ２０２を用いてＤＳＭ−ＣＣセクションの受信を受け取ると、Ｍｏｄｕｌｅを構成する全てのＤＳＭ−ＣＣセクションが揃う前は、第１メモリ２０２でセクションを管理（例：３５３２−１）し、Ｍｏｄｕｌｅを構成する全てのＤＳＭ−ＣＣセクションが揃った際に、Ｍｏｄｕｌｅデータを生成し、第２メモリ２０３へ記録（例えば、行３３２１の列３５３２に示す格納場所、行３３２３の列３５３２に示す格納場所へ）する。また、図３５Ｂは、ＤＩＩのバージョンアップが発生した場合も同様で、Ｍｏｄｕｌｅを構成するＤＳＭ−ＣＣセクションが揃った際に、Ｍｏｄｕｌｅを生成し、第２メモリ２０３へ記録したところの一例である。
【０２８６】
もちろん、第２メモリ２０３へ記録するデータは、ＤＳＭ−ＣＣセクションとして記録し、マルチメディアデータ受信装置１０２の要求に応じてＭｏｄｕｌｅを構成して送出するという方法であってもよい。次に、マルチメディアデータ送信装置１０１のネットワークライブラリ４０５ｅが、マルチメディアデータ受信装置１０２から以下のようなリクエストメッセージを受信した場合を例に説明する。
＜Ｍｏｄｕｌｅのリクエスト１＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Module&Carousel_id=0x0001&ModuleId=0x0001&ModuleVersion=0 HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
【０２８７】
この例は、リクエストメッセージに含まれるＵＲＩに、Ｍｏｄｕｌｅのリクエストを含めたものである。この例においては、ＩＰアドレスが１９２．１６８．０．３のサーバ上の／ＡＶＤａｔａ／０００１．ｍ２ｔｓで表されるストリームからのＭｏｄｕｌｅ取得要求であり、“type=Module”でＭｏｄｕｌｅ取得の要求を表し、“Carousel_id=0x0001”で要求するＭｏｄｕｌｅの「Ｃａｒｏｕｓｅｌ＿ｉｄ」が「０ｘ０００１」であることを、“ModuleId=0x0001”で要求するＭｏｄｕｌｅのＭｏｄｕｌｅ＿ｉｄが「０ｘ０ｘ０００１」であることを、“ModuleVersion=0”で要求するＭｏｄｕｌｅのバージョンが「０」であることを示している。
【０２８８】
またＭｏｄｕｌｅ取得要求は、ＨＴＴＰリクエストに拡張ヘッダＸ−Ｍｏｄｕｌｅ−Ｒｅｑｕｅｓｔをつけることによって行ってもよい。この場合は、拡張ヘッダＸ−Ｍｏｄｕｌｅ−Ｒｅｑｕｅｓｔは、要求するマルチメディアデータ中のＭｏｄｕｌｅの種類、送信を要求するモジュール情報をセミコロン“；”で区切ることとする。生成した拡張ヘッダの一例を以下に示す。
X-Module-Request: type = module ; carouselID = 0x0001; ModuleID=0x0001 ; ModuleVersion = 0
【０２８９】
したがって、マルチメディアデータ受信装置１０２からマルチメディアデータ送信装置１０１へ、以下の例のようなＨＴＴＰリクエストが発行される。
＜Ｍｏｄｕｌｅのリクエスト２＞
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
X-Module-Request: type = module ; carouselID = 0x0001; ModuleID=0x0001 ; ModuleVersion = 0
【０２９０】
ここではＭｏｄｕｌｅを識別する情報として、ＣａｒｏｕｓｅｌＩＤとＭｏｄｕｌｅＩＤとＭｏｄｕｌｅＶｅｒｓｉｏｎを指定する方法を説明したが、カルーセルに含まれるＭｏｄｕｌｅを特定できる情報であれば他のものを使ってもよいし、どのように指定してもよい。
【０２９１】
また、ここではＭｏｄｕｌｅのバージョンを指定することで、Ｍｏｄｕｌｅを特定する方法で説明するが、要求するＭｏｄｕｌｅのタイミングをリクエストに指定することで、該当するタイミングに有効なＭｏｄｕｌｅをマルチメディアデータ送信装置１０１が選択することで指定する方法であってもよい。このタイミングの一例として、メディアタイムを利用したリクエストなどタイミングを特定できる情報であれば他の情報を用いてもよい。このタイミングを指定するリクエスト方法は、上記セクションのリクエスト３−５で指定した方法と同等の方法を利用できる。一例として、セクションのリクエスト３に対応するＭｏｄｕｌｅのリクエスト３を以下に示す。
＜Ｍｏｄｕｌｅのリクエスト３＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Module&Carousel_id=0x0001&ModuleId=0x0002&media_time=00:00:15 HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
【０２９２】
ネットワークライブラリ４０５ｅは、図２３Ａに構成要素を示した実施の形態１と、以下の相違点を除いて同様の処理を行う。以下に処理の異なるものについて、詳細に説明する。
【０２９３】
要求受信部２３ａは、上記のリクエストメッセージを受信した場合は、該リクエストメッセージから、少なくとも要求されたコンテンツ及びＭｏｄｕｌｅ情報を取得し、制御部２３ｂへ引き渡す。
【０２９４】
制御部２３ｂは、受信したリクエストメッセージが正しいものであれば、制御部２３ｂは、クライアントより指定された録画ストリームの識別子（ここでは、０００１．ｍ２ｔｓ）とＭｏｄｕｌｅ取得条件（ＣａｒｏｕｓｅｌＩＤ＝０ｘ０００１、ＭｏｄｕｌｅＩＤ＝０ｘ０００１、ＭｏｄｕｌｅＶｅｒｓｉｏｎ＝０）を取得し、データ取得部２３ｄへ引き渡す。制御部２３ｂは、データ取得部２３ｄからの結果などヘッダ生成に必要な情報をＨｅａｄｅｒ生成部２３ｅに引き渡し、ＨＴＴＰレスポンスメッセージのＨｅａｄｅｒを生成する。なお、制御部２３ｂは、データ取得部２３ｄが取得したセクションを含めＨＴＴＰレスポンスを生成する。なお、ここではＭｏｄｕｌｅを識別する情報をリクエストに指定した場合を想定して説明しているため、指定されたＭｏｄｕｌｅをマルチメディアデータ受信装置１０２へ送出する方法を説明するが、リクエストでＣａｒｏｕｓｅｌＩＤなどＤＳＭ−ＣＣを識別する情報を指定し、リクエストされたＤＳＭ−ＣＣの識別子に関連する全てのＭｏｄｕｌｅをマルチメディアデータ受信装置１０２へ送信する方法でもよい。そして、生成したＨＴＴＰメッセージを情報送信部２３ｆに引き渡して、該要求元端末であるマルチメディアデータ受信装置１０２へ送信する。なお、制御部２３ｂは、クライアントからの要求を満たすか、あるいはコネクションが終了するか、録画ストリームが終了するまで、送信を繰り返す。
【０２９５】
データ取得部２３ｄは、ＩＯ４０５ｇに依頼してデータテーブル３５００とストリーム関連テーブル３４００を読み出す。データ取得部２３ｄは、制御部２３ｂによって引き渡された識別子と列３４０１を参照して録画ストリーム識別子を比較し、制御部２３ｂによって引き渡された識別子に関連するコンテンツの存在を確認する。存在しない場合には、そのエラー内容を制御部２３ｂへ通知し終了する。一方、存在した場合は、データテーブル識別子３４０６とデータテーブルの格納場所３４０７を取得する。次に、データ取得部２３ｄは、取得したデータテーブルの名前などの識別子３４０６とそのデータテーブルの格納場所３４０７をもとに、データテーブル３５００を取得する。
【０２９６】
データ取得部２３ｄは、指定されたＣａｒｏｕｓｅｌＩＤを確認し、データテーブル３５００の３３１０行を参照し、行３３１０の列３３０３に示す格納場所に記録されたＤＳＩが保持するＣａｒｏｕｓｅｌＩＤと比較する。ＣａｒｏｕｓｅｌＩＤが一致する場合は、３３１１行の３３０３列に示す格納場所に記録されたＤＩＩを取得し、ＤＩＩにも同じＣａｒｏｕｓｅｌＩＤが指定されていることを確認する。そして、取得したＤＩＩに、リクエストで指定されたＭｏｄｕｌｅ識別子及びＭｏｄｕｌｅのバージョンが一致するか確認する。このとき、ＣａｒｏｕｓｅｌＩＤおよびＭｏｄｕｌｅ識別子およびＭｏｄｕｌｅのバージョンが一致しない場合は、他のＤＩＩを確認する。ここでは、３３１１行の３３０３列に示す格納場所に記録されたＤＩＩが、リクエストで指定されたＭｏｄｕｌｅ識別子及びＭｏｄｕｌｅのバージョンが一致するＤＩＩとして、リクエストで指定されたＭｏｄｕｌｅを保持する行３３１１の列３３０３に示す格納場所に記録されたＤＩＩを取得する。そして、行３３１１の列３３０４に示すＤＩＩ参照情報管理テーブルへの参照情報を参照し、指定されたＭｏｄｕｌｅを含むＤＩＩ参照情報管理テーブル３５００−１を取得する。そして、リクエストされたＭｏｄｕｌｅ識別子「０ｘ０００１」及びＭｏｄｕｌｅのバージョン「０」に一致したＭｏｄｕｌｅ（行３３２１列３５３２）を制御部２３ｂに通知する。
【０２９７】
他の一例として、データテーブルが図３５Ｂに示した３５０１であるとき、Ｍｏｄｕｌｅのリクエスト３の要求を受信した場合を説明する。なおデータテーブルが図３５Ａのときと同様の処理を行う場合は説明を省略する。
【０２９８】
データ取得部２３ｄは、リクエスト３の要求で指定されたＣａｒｏｕｓｅｌＩＤを確認し、データテーブル３５０１のＤＳＩ（３３１０）が保持するＣａｒｏｕｓｅｌＩＤと比較する。ＣａｒｏｕｓｅｌＩＤが一致する場合は、指定されたＭｏｄｕｌｅ識別子が一致するＭｏｄｕｌｅを保持するＤＩＩを取得するが、図３５Ｂには３３１１のＤＩＩとバージョンアップ後の３３１２のＤＩＩが存在するため、指定されたＭｅｄｉａ＿ｔｉｍｅ=00:0O:15に有効な３３１２のＤＩＩを取得し、指定されたＭｏｄｕｌｅＩＤ＝２のＭｏｄｕｌｅを制御部２３ｂに通知する。
【０２９９】
Ｈｅａｄｅｒ生成部２３ｅは、制御部２３ｂによって引き渡されたＨＴＴＰリクエストへの結果など、ヘッダ生成に必要なデータをもとに、ＨＴＴＰレスポンスヘッダを生成し制御部２３ｂへ返す。
【０３００】
情報送信部２３ｆは、制御部２３ｂによって引き渡されたＨｅａｄｅｒ生成部２３ｅが生成したヘッダとデータ取得部２３ｄが取得したデータを該要求元端末へ送信する。
【０３０１】
以下に情報送信部２３ｆが送出するHTTPレスポンスの一例を示す。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: application/octet-stream
(空行)
[要求されたＭｏｄｕｌｅデータ]
【０３０２】
なお、Ｈｅａｄｅｒ生成部２３ｅは、該ＨＴＴＰレスポンスに含まれるＭｏｄｕｌｅの種類を示す拡張ヘッダを生成してもよい。一例として、拡張ヘッダＸ−Ｍｏｄｕｌｅ−Ｉｎｆｏを用いて、ＣａｒｏｕｓｅｌＩＤ及びＭｏｄｕｌｅＩＤなどＨＴＴＰレスポンスに含まれるデータの取得条件や、該Ｍｏｄｕｌｅがストリーム中から取得されたタイミングであるメディアタイムを表しても良い。もちろん、ＨＴＴＰリクエストで指定された条件を含んでもよい。なお、拡張ヘッダＸ−Ｍｏｄｕｌｅ−Ｉｎｆｏが含む情報は、該ＨＴＴＰレスポンスに含まれるデータを識別できる情報であれば、他の情報であってもよい。
X-Module-Info: type = module ; carouselID = 0x0001; ModuleID=0x0001 ; ModuleVersion = 0
【０３０３】
すなわち、該ＨＴＴＰレスポンスに含まれるデータの情報を含む拡張ヘッダを含むＨＴＴＰレスポンスは、次のようなレスポンスになる。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: application/octet-stream
X-Module-Info: type = module ; carouselID = 0x0001; ModuleID=0x0001 ; ModuleVersion = 0
(空行)
[要求されたＭｏｄｕｌｅデータ]
【０３０４】
また、ここでは拡張ヘッダを用いてＨＴＴＰレスポンスに含まれる情報を記述する方法を説明したが、他の形式でマルチメディアデータ受信装置１０２へ通知してもよい。
【０３０５】
以上の処理により、マルチメディアデータ受信装置１０２の要求に応じてＭｏｄｕｌｅを構成するデータを送出することができる。
【０３０６】
（ＤＳＭ−ＣＣ  Ｏｂｊｅｃｔで通信する方式）
次に、マルチメディアデータ送信装置１０１からマルチメディアデータ受信装置１０２にデータ放送用データで再生に使用される実データをＤＳＭ−ＣＣ  Ｏｂｊｅｃｔとして伝送する場合を説明する。
【０３０７】
図３６Ａ〜図３６ＣにＤＳＭ−ＣＣ  ＭｏｄｕｌｅとＤＳＭ−ＣＣ  Ｏｂｊｅｃｔとファイルシステムの関係の一例を示す。３６０１は、図２９で示したＭｏｄｕｌｅとＯｂｊｅｃｔの関係に実際のＯｂｊｅｃｔの種類（ＦＩＬＥ、ＤＩＲＥＣＴＯＲＹ、ＳＴＲＥＡＭ、ＳＴＲＥＡＭＥＶＥＮＴ）および３６０２に示したファイルシステムに存在するパスを示す。例えばＭｏｄｕｌｅ「０ｘ０００１」には「／」のパスに存在するＤＩＲＥＣＴＯＲＹ  Ｏｂｊｅｃｔの情報が含まれる。Ｍｏｄｕｌｅ「０ｘ０００２」には「／ａ」のパスに存在するＤＩＲＥＣＴＯＲＹ  Ｏｂｊｅｃｔの情報と「／ａ／ＴｏｐＸｌｅｔ．ｃｌａｓｓ」のパスに存在するＦＩＬＥ  Ｏｂｊｅｃｔと「／ｂ」のパスに存在するＤＩＲＥＣＴＯＲＹ  Ｏｂｊｅｃｔと「／ｂ／ＧａｍｅＸｌｅｔ．ｃｌａｓｓ」のパスに存在するＦＩＬＥ  Ｏｂｊｅｃｔの情報が含まれる。更に、Ｍｏｄｕｌｅ「０ｘ０００３」には「／ｂ／ＳＥ１」のパスに存在するＳＴＲＥＡＭＥＶＥＮＴ  Ｏｂｊｅｃｔと「／ｃ」のパスに存在するＤＩＲＥＣＴＯＲＹ  Ｏｂｊｅｃｔと「／ｃ／Ｓ１」のパスに存在するＳＴＲＥＡＭ  Ｏｂｊｅｃｔの情報が含まれる。このようなＭｏｄｕｌｅによって伝送された情報で構成したファイルシステムの一例が３６０２である。次に、３６０３は、データテーブル生成部３００３が生成するデータテーブルの一例である。３６１１はＤＳＭ−ＣＣによって伝送されるファイルツリーに存在するＯｂｊｅｃｔのパスを示す。３６１２は、ＯｂｊｅｃｔのＴｙｐｅを示す。３６１３は、各Ｏｂｊｅｃｔが有効になるタイミングを示す。Ｏｂｊｅｃｔが有効になるタイミングの一例として、各Ｏｂｊｅｃｔを取得したタイミングでもよいし、各Ｏｂｊｅｃｔを伝送していたＭｏｄｕｌｅが現れたタイミングでもよいし、各Ｏｂｊｅｃｔを伝送していたＤＩＩが現れたタイミングなどであってもよい。なお、ここでは各Ｏｂｊｅｃｔを伝送していたＤＩＩが表れたタイミングとして示した。
【０３０８】
次に３６１４は、各Ｏｂｊｅｃｔがストリーム上から伝送されなくなったタイミングを示す。Ｏｂｊｅｃｔが伝送されなくなるタイミングの一例として、ＤＩＩのバージョンアップにより該Ｏｂｊｅｃｔを伝送するＭｏｄｕｌｅが変更され、Ｏｂｊｅｃｔが存在しなくなったタイミングや、Ｏｂｊｅｃｔを伝送するＭｏｄｕｌｅがＤＩＩから削除されるタイミングであってもよいし、ストリームが終了するタイミングやＰＡＴ、ＰＭＴ、ＤＳＩがバージョンアップしたタイミングなどであってもよい。なお。ここではストリームが終了するタイミングとして示した。
【０３０９】
３６１５は、各Ｏｂｊｅｃｔが更新されたタイミングを示す。Ｏｂｊｅｃｔが更新されるタイミングの一例として、該当Ｏｂｊｅｃｔの内容が変更されたタイミングでもよいし、ＤＩＩのバージョンアップにより、該当Ｏｂｊｅｃｔを伝送するＭｏｄｕｌｅが更新されたタイミングなど、他の方法で検出してもよい。なお。ここでは各Ｏｂｊｅｃｔを伝送するＭｏｄｕｌｅにバージョンアップが起こったタイミングとして示した。図３６Ａ〜図３６ＣではＤＩＩのバージョンアップが発生していないため、記述がない。
【０３１０】
３６１６は、各Ｏｂｊｅｃｔの格納場所（例えば各Ｏｂｊｅｃｔに対応するデータの先頭位置を示す第２メモリのアドレス情報）を示す。
【０３１１】
なお、ここで、ＤＩＩのバージョンアップによるデータテーブル生成の例を示す。なお、ここで各Ｍｏｄｕｌｅが含むＯｂｊｅｃｔは３６０１である場合で説明する。
【０３１２】
・例１：Ｍｏｄｕｌｅの追加
図３７のＤＩＩが伝送されていて、メディアタイムが「２０：００」のときに図３２のＤＩＩにバージョンアップした際のデータテーブルの一例を図３８に示す。図３７から図３２にＤＩＩが変更された場合は、「０ｘ０００３」のＭｏｄｕｌｅが追加されているため、Ｍｏｄｕｌｅ「０ｘ０００３」によって伝送されているＯｂｊｅｃｔが有効になるタイミングとしてＤＩＩが受信された「２０：００」（３８１３列の３６２６〜３６２８行）とする。
【０３１３】
・例２：Ｍｏｄｕｌｅの削除
図３２のＤＩＩが伝送されていて、メディアタイムが「２５：００」のときに図３７のＤＩＩにバージョンアップした際のデータテーブルの一例を図４０に示す。図３２から図３７にＤＩＩが変更された場合は、「０ｘ０００３」のＭｏｄｕｌｅが削除されているため、Ｍｏｄｕｌｅ「０ｘ０００３」によって伝送されているＯｂｊｅｃｔが削除状態になるタイミングとしてＤＩＩが受信された「２５：００」（４０１４列の３６２６〜３６２８行）とする。
【０３１４】
・例３：Ｍｏｄｕｌｅの更新
図３２のＤＩＩが伝送されていて、メディアタイムが「１０：００」のときに図３９のＤＩＩにバージョンアップした際のデータテーブルの一例を図４１に示す。図３２から図３９にＤＩＩが更新された場合は、「０ｘ０００２」のＭｏｄｕｌｅが更新されているため、新しいＭｏｄｕｌｅのバージョンの「０ｘ０００２」のＭｏｄｕｌｅ（図４２）を再取得し、取得したＭｏｄｕｌｅに含まれるＯｂｊｅｃｔを比較し、更新されたＯｂｊｅｃｔ（４２１）に更新のタイミングを指定し（列４１１５の行３６２３）、格納場所には、更新前後のＯｂｊｅｃｔへの参照（つまり更新前のＯｂｊｅｃｔのデータの先頭位置を示す第２メモリのアドレス情報、更新後のＯｂｊｅｃｔのデータの先頭位置を示す第２メモリのアドレス情報）を保持する。また、前述したようにＭｏｄｕｌｅ「０ｘ０００２」によって伝送されているＯｂｊｅｃｔが更新されたタイミングとして、ＤＩＩが受信された「１０：００」（２３Ａ１５列の３６２２〜３６２５行）とし、格納場所には、更新前後のＯｂｊｅｃｔへの参照（つまり更新前のＯｂｊｅｃｔのデータの先頭位置を示す第２メモリのアドレス情報、更新後のＯｂｊｅｃｔのデータの先頭位置を示す第２メモリのアドレス情報）を保持する方法であってもよい。
【０３１５】
なお、ここでは図３２のＤＩＩから図３９のＤＩＩへバージョンアップした際のデータテーブルの他の一例として図４３に示す。図３２から図３９へＤＩＩが更新された場合、「０ｘ０００２」のＭｏｄｕｌｅが更新されていることがわかるため、「０ｘ０００２」のＭｏｄｕｌｅに含まれる全てのＯｂｊｅｃｔに対応する更新のタイミング（４３１５列の３６２２行〜３６２５行）に「１０：００」を指定し、格納場所（図４３の列３６１６）には、更新前後のＯｂｊｅｃｔへの参照（つまり更新前のＯｂｊｅｃｔのデータの先頭位置を示す第２メモリのアドレス情報、更新後のＯｂｊｅｃｔのデータの先頭位置を示す第２メモリのアドレス情報）を保持する方法であってもよい。
【０３１６】
なお、各タイミングを示す情報（例えば図３６Ｃに示す列３６１３−３６１５、図３８に示す列３８１３、列３６１４−列３６１５、図４０に示す列３６１３、列４０１４、列３６１５、図４１に示す列３６１３−列３６１４、列４１１５、図４３に示す列３６１３、列４３１４−列４３１５など）としてメディアタイムを用いたが、録画ストリーム中の位置情報が分かる情報であれば、他の情報であってもよい。また、Ｏｂｊｅｃｔ情報（例えば列３６１１、列３６１２）に関連づける情報として、各Ｏｂｊｅｃｔに変化が起こったタイミング（列３６１３−列３６１５）を用いたが、関連情報としてＭｏｄｕｌｅ識別子とＭｏｄｕｌｅのバージョンを記録しておき、マルチメディアデータ受信装置１０２からＯｂｊｅｃｔ取得要求時に、該当するタイミングのＯｂｊｅｃｔを検出するという方法であってもよい。
【０３１７】
次に、ネットワークライブラリ４０５ｅが以下のようなリクエストメッセージを受信した場合を例に説明する。
＜Ｏｂｊｅｃｔのリクエスト１＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Object&path=/a/TopXlet.class&media_time=00:09:00 HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
【０３１８】
この例は、リクエストメッセージに含まれるＵＲＩに、オブジェクトのリクエストを含めたものである。この例においては、ＩＰアドレスが１０２．１６８．０．３のサーバ上の／ＡＶＤａｔａ／０００１．ｍ２ｔｓで表されるストリームに関連したデータの取得要求であり、“type=Object”でオブジェクト取得の要求を表し、“path=/a/TopXlet.class”で要求するオブジェクトの「パス」が「/a/TopXlet.class」であることを表し、“media_time=00:09:00”でメディアタイムが「００：０９：００」時点のデータ要求することを表している。
【０３１９】
またＯｂｊｅｃｔ取得要求は、ＨＴＴＰリクエストに拡張ヘッダＸ−Ｏｂｊｅｃｔ−Ｒｅｑｕｅｓｔをつけることによって行ってもよい。この場合は、拡張ヘッダＸ−Ｏｂｊｅｃｔ−Ｒｅｑｕｅｓｔは、要求するマルチメディアデータ中のＯｂｊｅｃｔの種類、送信を要求するセクション情報をセミコロン“；”で区切ることとする。生成した拡張ヘッダの一例を以下に示す。
X-Object-Request: type = Object ; path=/a/TopXlet.class ; Media_time = 00:09:00
【０３２０】
したがって、マルチメディアデータ受信装置１０２からマルチメディアデータ送信装置１０１へ、以下の例のようなＨＴＴＰリクエストが発行される。
＜Ｏｂｊｅｃｔのリクエスト２＞
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
X-Object-Request: type = Object ; path=/a/TopXlet.class ; Media_time = 00:09:00
【０３２１】
このように、Ｏｂｊｅｃｔを要求していることを示す情報と、該Ｏｂｊｅｃｔのパスといった取得したいＯｂｊｅｃｔの識別子を指定できる方法であれば、どのようなリクエストであってもよい。また、ここではパスを指定する方法として、カルーセルのルートディレクトリからのパスを指定する方法を説明したが、カルーセルに含まれるＯｂｊｅｃｔを特定できるパスであればどのように指定してもよい。また、ここでは、Ｏｂｊｅｃｔの識別子としてパスを利用しているが、ＯｂｊｅｃｔＩＤなど、Ｏｂｊｅｃｔが特定できるものであれば、他のものを使っても良い。
【０３２２】
なお、ここでは取得するタイミングを指定する方法として、メディアタイムを利用した方法を説明するが、タイミングを特定できる情報であれば、他の指定方法であってもよい。タイミングの指定方法については、上記セクションやＭｏｄｕｌｅの要求の場合と同様に行えるため、詳細な説明は省略する。
【０３２３】
ネットワークライブラリ４０５ｅは、図２３Ａに構成要素を示した実施の形態１および本実施の形態におけるセクションやＭｏｄｕｌｅのリクエストにおいて説明したネットワークライブラリ４０５ｅと、以下の相違点を除いて同様の処理を行う。以下に、処理の異なるものについて、詳細に説明する。
【０３２４】
要求受信部２３ａは、上記のリクエストメッセージを受信した場合は、該リクエストメッセージから、少なくとも要求されたコンテンツ及びＯｂｊｅｃｔの識別子を取得し、制御部２３ｂへ引き渡す。
【０３２５】
制御部２３ｂは、受信したリクエストメッセージが正しいものであれば、制御部２３ｂは、クライアントより指定された録画ストリームの識別子（ここでは、０００１．ｍ２ｔｓ）とＯｂｊｅｃｔ取得条件（ｐａｔｈ=/a/TopXlet.class）を取得し、データ取得部２３ｄへ引き渡す。制御部２３ｂは、データ取得部２３ｄからの結果などヘッダ生成に必要な情報をＨｅａｄｅｒ生成部２３ｅに引き渡し、ＨＴＴＰレスポンスメッセージのヘッダを生成する。なお、制御部２３ｂは、データ取得部２３ｄが取得したＯｂｊｅｃｔを含めＨＴＴＰレスポンスを生成する。なお、ここではＯｂｊｅｃｔを識別する情報をリクエストに指定した場合を想定して説明しているが、リクエストでＣａｒｏｕｓｅｌＩＤなどＤＳＭ−ＣＣを識別する情報を指定し、関連する全てのＯｂｊｅｃｔをマルチメディアデータ受信装置１０２へ送信する方法でもよい。そして、生成したＨＴＴＰメッセージを情報送信部２３ｆに引き渡して、該要求元端末であるマルチメディアデータ受信装置１０２へ送信する。なお、制御部２３ｂは、クライアントからの要求を満たすか、あるいはコネクションが終了するか、録画ストリームが終了するまで、送信を繰り返す。
【０３２６】
以下、データテーブルの例として、図４１に示した４１０３を用いて説明する。データ取得部２３ｄは、ＩＯ４０５ｇに依頼してストリーム関連テーブル３４００を読み出す。データ取得部２３ｄは、制御部２３ｂによって引き渡された識別子と列３４０１を参照して録画ストリーム識別子を比較し、制御部２３ｂによって引き渡された識別子に関連するコンテンツの存在を確認する。存在しない場合には、そのエラー内容を制御部２３ｂへ通知し終了する。一方、存在した場合は、データテーブル識別子３４０６とデータテーブル格納場所３４０７を取得する。次に、データ取得部２３ｄは、取得したデータテーブルの名前などの識別子３４０６とそのイベントテーブル格納場所３４０７をもとに、データテーブル４１０３を取得する。
【０３２７】
データ取得部２３ｄは、指定されたパスと、データテーブル４１０３に記録されたパスを比較し、一致するパスを選択する。ここでは、リクエストされた「ｐａｔｈ」が「/a/TopXlet.class」のため、行３６２３に一致することがわかる。そして、データ取得部２３ｄは、データテーブル４１０３の行３６２３の列３６１３及び列３６１４及び列４１１５を参照し、該当Ｏｂｊｅｃｔが「１０：００」に更新されていることがわかる。ここでは、指定された「ｍｅｄｉａＴｉｍｅ」が「００：０９：００」のため、マルチメディアデータ受信装置１０２は、更新が起こる前のデータをリクエストしている。そのため、データ取得部２３ｄは、３６１６を参照し更新前のＯｂｊｅｃｔを取得し、制御部２３ｂへ通知する。
【０３２８】
Ｈｅａｄｅｒ生成部２３ｅは、制御部２３ｂによって引き渡されたＨＴＴＰリクエストへの結果など、ヘッダ生成に必要なデータをもとに、ＨＴＴＰレスポンスヘッダを生成し制御部２３ｂへ返す。
【０３２９】
情報送信部２３ｆは、制御部２３ｂによって引き渡されたＨｅａｄｅｒ生成部２３ｅが生成したヘッダとデータ取得部２３ｄが取得したデータを該要求元端末へ送信する。
【０３３０】
以下に情報送信部２３ｆが送出するHTTPレスポンスの一例を示す。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: application/octet-stream
(空行)
[要求されたＯｂｊｅｃｔデータ]
【０３３１】
なお、Ｈｅａｄｅｒ生成部２３ｅは、該ＨＴＴＰレスポンスに含まれるＯｂｊｅｃｔの種類を示す拡張ヘッダを生成してもよい。一例として、拡張ヘッダＸ−Ｏｂｊｅｃｔ−Ｉｎｆｏを用い、パスや該Ｏｂｊｅｃｔがストリーム中から取得されたタイミングであるメディアタイムを表すものとする。もちろん、ＨＴＴＰリクエストで指定された条件をそのまま含んでもよい。なお、拡張ヘッダＸ−Ｏｂｊｅｃｔ−Ｉｎｆｏが含む情報は、該ＨＴＴＰレスポンスに含まれるデータを識別できる情報であれば、他の情報であってもよい。
X-Object-Info: type = Object ; path=/a/TopXlet.class ; Media_time = 00:09:00
【０３３２】
すなわち、該ＨＴＴＰレスポンスに含まれるデータの情報を含む拡張ヘッダを含むＨＴＴＰレスポンスは、次のようなレスポンスになる。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: application/octet-stream
X-Object-Info: type = Object ; path=/a/TopXlet.class ; Media_time = 00:09:00
(空行)
[要求されたＯｂｊｅｃｔデータ]
【０３３３】
また、ここでは拡張ヘッダを用いてＨＴＴＰレスポンスに含まれる情報を記述する方法を説明したが、他の形式でマルチメディアデータ受信装置１０２へ通知してもよい。
【０３３４】
以上の処理により、マルチメディアデータ受信装置１０２の要求に応じてＯｂｊｅｃｔを構成するデータを送出することができる。
【０３３５】
次に本実施の形態におけるマルチメディアデータ受信装置１０２を説明するが、マルチメディアデータ受信装置１０２は、実施の形態１で説明した機能と同等であるため、ここでは差分についてのみ説明する。
【０３３６】
実施の形態１ではネットワークライブラリ２５０４ｄは、マルチメディアデータ取得依頼をＪＭＦ２５０４ａより受けていた。しかし、本実施の形態では、さらに、セクションおよびＭｏｄｕｌｅ、Ｏｂｊｅｃｔなどのデータ要求を発行する他のライブラリ（ＡＭ２５０４ｂ及びＤＳＭ−ＣＣ２５０４ｌなど）からのデータ取得要求を受け、要求されたデータを取得する。なお、ここで示した他のライブラリがデータを要求する処理については、既に説明しているため詳細な説明を省略するが、実施の形態１では、ＭＰＥＧ２トランスポートストリームに含まれるＪａｖａプログラムを抽出し、ＪａｖａＶＭ４０３に実行させることでデータ放送再生を行っていたが、本実施の形態では、データ放送用データをネットワークライブラリ２５０４ｄへ依頼し、マルチメディアデータ送信装置１０１から取得する機能以外は、実施の形態１で説明と同等の方法でデータ放送再生を行うことができる。ＡＭ２５０４ｂは、ＪＭＦ２５０４ａ同様、サービスマネージャ２５０３より機器識別子、サービス識別子、コンテンツ識別子を受け取りデータ放送再生の依頼を受ける。そして、ＪＭＦ２５０４ａ同様、ＰＡＴ、ＰＭＴを取得し、ＡＩＴを伝送するＰＩＤを取得し、ＡＩＴのＰＩＤとｔａｂｌｅ＿ｉｄを指定しセクションを取得する。このように、実施の形態１では、ＪＭＦ２５０４ａが録画ストリームを取得し再生しているＴＳデコーダ２４０５へセクション条件を設定することでフィルタリングを行っていたが、ＰＡＴ、ＰＭＴ、ＡＩＴなどのセクションの取得要求をネットワークライブラリ２５０４ｄに行い、マルチメディアデータ送信装置１０１からセクションを直接取得する方法でもよい。また、ＡＭ２５０４ｂは、取得したＡＩＴを参照し、ＤＳＭ−ＣＣ識別子を取得し、該当するＤＳＭ−ＣＣ識別子とサービスマネージャ２５０３に引き渡された情報をＤＳＭ−ＣＣ２５０４ｌへ引き渡すことで、指定したファイルを取得することができる。AM２５０４ｂは、取得したＪａｖａプログラムを抽出し、ＪａｖａＶＭ４０３に実行させることでデータ放送再生を行う。
【０３３７】
なお、ＤＳＭ−ＣＣ２５０４ｌは、これまでＤＳＭ−ＣＣからファイルを取得する方法を説明した処理を行うことにより、ファイルシステムを構成するＯｂｊｅｃｔを取得する。このとき、ＤＳＩ及びＤＩＩの取得は、ＪＭＦ２５０４ａが録画ストリームを取得し再生しているＴＳデコーダ２４０５へセクション条件を設定することでフィルタリングを行ってもよいが、ネットワークライブラリ２５０４ｄにＤＳＩ、ＤＩＩセクションの取得を依頼してもよい。また、ＤＳＭ−ＣＣ２５０４ｌがＤＳＩ、ＤＩＩを参照し、Ｏｂｊｅｃｔを取得するために、ＤＤＢのセクションのフィルタリング条件をＴＳデコーダ２４０５へ設定する方法でもよいが、ネットワークライブラリ２５０４ｄへ以下のいずれかのデータ形式で取得要求を行う方法でもよい。
・セクション形式でデータ取得を依頼
・Ｍｏｄｕｌｅ形式でデータ取得を依頼
・Ｏｂｊｅｃｔ形式でデータ取得を依頼
【０３３８】
なお、各ライブラリがネットワークライブラリ２５０４ｄへ依頼を行う際には、ＪＭＦ２５０４ａ同様、サービスマネージャ２５０３より受け取った機器識別子、サービス識別子、コンテンツ識別子を基に、ＨＮ２５０４ｉよりマルチメディアデータ送信装置１０１のＩＰアドレスなどの情報及びコンテンツのＵＲＩを取得し、取得した該情報をネットワークライブラリ２５０４ｄに与え、該マルチメディアデータ取得依頼を行う。
【０３３９】
ネットワークライブラリ２５０４ｄの制御部２８０１ａは、マルチメディアデータ取得依頼を受信すると、引き渡された情報をのうち、少なくともマルチメディアデータ送信装置１０１のＩＰアドレスや該ネットワーク接続のためのポート番号などを接続管理部２８０１ｂに与え、接続管理部２８０１ｂに依頼して、マルチメディアデータ送信装置１０１とのネットワーク接続を確立する。
【０３４０】
接続管理部２８０１ｂは、実施の形態１と同様の処理を行うため説明を省略する。
【０３４１】
次に、制御部２８０１ａは、これらの取得要求をマルチメディアデータ送信装置１０１へ要求するために、メッセージ処理部２８０１ｃへ依頼し、対応するＨＴＴＰリクエストを生成する。
【０３４２】
メッセージ処理部２８０１ｃは、要求されたマルチメディアデータのＵＲＩをＨＴＴＰリクエストに設定する。一例として、マルチメディアデータのＵＲＩhttp://192.168.0.3/AVData/0001.m2tsに関連するセクションの取得要求を受け、セクション条件として、ＰＩＤ＝０ｘ５０１４、ｔａｂｌｅ＿ｉｄ＝０ｘ３Ｂを指定された場合、以下のようなＨＴＴＰリクエストを生成する。
＜セクションのリクエスト１＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Section&pid=0x5014&table_id=0x3B  HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
【０３４３】
また、ＨＴＴＰリクエストの形式は、セクションを要求していることと、セクションを識別する情報を設定できれば上記のようなＨＴＴＰリクエストにこだわらない。例えば、
ＨＴＴＰリクエストに拡張ヘッダＸ−Ｓｅｃｔｉｏｎ−Ｒｅｑｕｅｓｔをつけることによって行ってもよい。この場合は、拡張ヘッダＸ−Ｓｅｃｔｉｏｎ−Ｒｅｑｕｅｓｔは、要求するマルチメディアデータ中のセクションの種類、送信を要求するセクション情報をセミコロン“；”で区切ることとする。生成した拡張ヘッダの一例を以下に示す。
X-Section-Request: type = section ; pid = 0x5014; table_id = 0x3B
【０３４４】
したがって、このような拡張ヘッダを用いてリクエストする場合は、以下の例のようなＨＴＴＰリクエストが発行される。
＜セクションのリクエスト２＞
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
X-Section-Request: type = section ; pid = 0x5014; table_id = 0x3B
【０３４５】
また、上記のようなセクションのリクエストに加え、取得したいセクションのタイミングをリクエストに設定する一例を説明する。ここでは、タイミングとしてメディアタイムを指定する例を示す。なお、タイミングに関しては、ネットワークライブラリ２５０４ｄへデータ取得を要求する際に設定するとしてもいいし、メッセージ処理部２８０１ｃがリクエストの生成を受けた際に、ＪＭＦ２５０４ａなどから取得し設定する方法でもよい。ここでは一例として、Media_time=00:00:15を設定する方法を示す。
＜セクションのリクエスト３(1)＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Section&pid=0x5014&table_id=0x3B&media_time=00:00:15 HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
＜セクションのリクエスト３(2)＞
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
X-Section-Request: type = section ; pid = 0x5014; table_id = 0x3B ; media_time=00:00:15
【０３４６】
また、指定時間以降のセクションを連続して取得する場合、メディアタイムの指定の後に“-”を指定する（下記の例では“media_time”の指定時間として“00:10:00”を指定した後に“-”を指定することにより、メディアタイムが“00:10:00”以降のセクションを連続して取得を要求する例を示す）。そのため、連続した取得要求を行う場合は、次のようなリクエストとなる。
＜セクションのリクエスト４＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Section&pid=0x5014&table_id=0x3B&media_time=00:10:00- HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
【０３４７】
また、取得開始位置を指定する以外に、取得要求を行う期間を指定するという方法であってもよい。この場合、開始のタイミングと終了のタイミングを“-”でつなげることで表現する。そのため、期間（例えばメディアタイムが“00:10:00-00:30:00”）を指定した取得要求を行う場合は、次のようなリクエストとなる。
＜セクションのリクエスト５＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Section&pid=0x5014&table_id=0x3B& media_time=00:10:00-00:30:00 HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
【０３４８】
なお、ここではメディアタイムを用いてタイミングを通知する方法を用いたがマルチメディアデータ中の位置を特定できれば他の情報でもよい。他の情報の一例としては、ＮＰＴやストリームのバイト位置で指定する方法などがある。
【０３４９】
また、上記のような指定方法以外にも、ＤＬＮＡで定義されているＴｉｍｅＳｅｅｋＲａｎｇｅ．ｄｌｎａ．ｏｒｇ拡張ヘッダを利用してメディアタイムの範囲を指定する方法や、ＨＴＴＰ１．１で定義されているＲａｎｇｅヘッダを利用してストリームのバイト位置の範囲を指定するなど、要求するセクションを特定できるような情報であればどのようなリクエストであってもよい。
【０３５０】
また、メッセージ処理部２８０１ｃが生成するリクエストの他の例として、マルチメディアデータのＵＲＩhttp://192.168.0.3/AVData/0001.m2tsに関連するＭｏｄｕｌｅの取得要求を受け、取得するＭｏｄｕｌｅの条件として、Ｃａｒｏｕｓｅｌ＿ｉｄ＝０ｘ０００１、Ｍｏｄｕｌｅ＿ｉｄ＝０ｘ０００１、Ｍｏｄｕｌｅ＿Ｖｅｒｓｉｏｎ＝０を指定された場合、以下のようなＨＴＴＰリクエストを生成する。
＜Ｍｏｄｕｌｅのリクエスト１＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Module&Carousel_id=0x0001&ModuleId=0x0001&ModuleVersion=0 HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
【０３５１】
またＭｏｄｕｌｅ取得要求は、ＨＴＴＰリクエストに拡張ヘッダＸ−Ｍｏｄｕｌｅ−Ｒｅｑｕｅｓｔをつけることによって行ってもよい。この場合は、拡張ヘッダＸ−Ｍｏｄｕｌｅ−Ｒｅｑｕｅｓｔは、要求するマルチメディアデータ中のＭｏｄｕｌｅの種類、送信を要求するセクション情報をセミコロン“；”で区切ることとする。生成した拡張ヘッダの一例を以下に示す。
X-Module-Request: type = module ; carouselID = 0x0001; ModuleID=0x0001 ; ModuleVersion = 0
【０３５２】
したがって、以下の例のようなＨＴＴＰリクエストが発行される。
＜Ｍｏｄｕｌｅのリクエスト２＞
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
X-Module-Request: type = module ; carouselID = 0x0001; ModuleID=0x0001 ; ModuleVersion = 0
【０３５３】
なお、ここではＭｏｄｕｌｅを識別する情報として、Ｃａｒｏｕｓｅｌ＿ｉｄ、Ｍｏｄｕｌｅ＿ｉｄ、ＭｏｄｕｌｅＶｅｒｓｉｏｎを用いたが、取得したいＭｏｄｕｌｅを指定できる方法であれば、どのようなリクエストであってもよい。なお、ここでは一例として、ＭｏｄｕｌｅＶｅｒｓｉｏｎのかわりにメディアタイムを利用して、取得するＭｏｄｕｌｅタイミングを指定する方法を説明する。メディアタイムを用いる方法は、セクションのリクエスト３−５で指定した方法と同等の方法を利用できる。ここでは一例として、セクションのリクエスト３に対応するＭｏｄｕｌｅのリクエスト３のみを以下に示す。
＜Ｍｏｄｕｌｅのリクエスト３(1)＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Module&Carousel_id=0x0001&ModuleId=0x0002&media_time=00:00:15 HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
＜Ｍｏｄｕｌｅのリクエスト３(2)＞
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
X-Module-Request: type = module ; carousel_id = 0x0001; module_id = 0x0002 ; media_time=00:00:15
【０３５４】
また、メッセージ処理部２８０１ｃが生成するリクエストの他の例として、マルチメディアデータのＵＲＩhttp://192.168.0.3/AVData/0001.m2tsに関連するＯｂｊｅｃｔの取得要求を受け、取得するＯｂｊｅｃｔの条件として、ｐａｔｈ＝／ａ／ＴｏｐＸｌｅｔ．ｃｌａｓｓ、Ｍｅｄｉａ＿ｔｉｍｅ＝００：０９：００を指定された場合、以下のようなＨＴＴＰリクエストを生成する。
＜Ｏｂｊｅｃｔのリクエスト１＞
GET http://192.168.0.3/AVData/0001.m2ts?type=Object&path=/a/TopXlet.class&media_time=00:09:00 HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
【０３５５】
またＯｂｊｅｃｔ取得要求は、ＨＴＴＰリクエストに拡張ヘッダＸ−Ｏｂｊｅｃｔ−Ｒｅｑｕｅｓｔをつけることによって行ってもよい。この場合は、拡張ヘッダＸ−Ｏｂｊｅｃｔ−Ｒｅｑｕｅｓｔは、要求するマルチメディアデータ中のＯｂｊｅｃｔの種類、送信を要求するセクション情報をセミコロン“；”で区切ることとする。生成した拡張ヘッダの一例を以下に示す。
X-Object-Request: type = Object ; path=/a/TopXlet.class ; Media_time = 00:09:00
【０３５６】
したがって、以下の例のようなＨＴＴＰリクエストが発行される。
＜Ｏｂｊｅｃｔのリクエスト２＞
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
X-Object-Request: type = Object ; path=/a/TopXlet.class ; Media_time = 00:09:00
【０３５７】
ここではＯｂｊｅｃｔを識別する情報として、パスとメディアタイムを指定する方法を説明したが、カルーセルに含まれるＯｂｊｅｃｔを特定できる情報であれば他の情報を使ってもよいし、どのようなリクエストであってもよい。他の情報を用いる一例としては、パスのかわりにＯｂｊｅｃｔを特定する情報としてＯｂｊｅｃｔＩＤを利用する方法でもよい。また、ここではパスを指定する方法として、カルーセルのルートディレクトリからのパスを指定する方法を説明したが、カルーセルに含まれるＯｂｊｅｃｔを特定できるパスであればどのように指定してもよい。
【０３５８】
なお、ここでは取得するタイミングを指定する方法として、メディアタイムを利用した方法を説明するが、タイミングを特定できる情報であれば、他の指定方法であってもよい。またタイミングの指定方法については、セクションやＭｏｄｕｌｅで送信する場合に説明しているため、省略する。
【０３５９】
続いて、制御部２８０１ａは、以上のように生成したＨＴＴＰリクエストを送受信部２８０１ｅに与え、マルチメディアデータ送信装置１０１へ送信させる。
【０３６０】
次に、制御部２８０１ａは送受信部２８０１ｅに依頼して、マルチメディアデータ送信装置１０１よりＨＴＴＰレスポンスを受信する。受信したＨＴＴＰレスポンスの例を以下に示す。
【０３６１】
・セクション要求に対するレスポンス例
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: application/octet-stream
(空行)
[要求されたセクションデータ]
【０３６２】
また、該ＨＴＴＰレスポンスに含まれるセクションデータの種類を示す拡張ヘッダを生成してもよい。一例として、拡張ヘッダＸ−Ｓｅｃｔｉｏｎ−Ｉｎｆｏを用いて、ＰＩＤおよびｔａｂｌｅ＿ｉｄなどＨＴＴＰレスポンスに含まれるデータをフィルタリングした条件や、該セクションがストリーム中に存在したタイミングであるメディアタイムを表すものとする。もちろん、ＨＴＴＰリクエストで指定された条件を含んだものであってもよい。なお、拡張ヘッダＸ−Ｓｅｃｔｉｏｎ−Ｉｎｆｏが含む情報は、該ＨＴＴＰレスポンスに含まれるデータを識別できる情報であれば、他の情報であってもよい。
X-Section-Info: type = section ; pid = 0x5014; table_id = 0x3B; media_time=00:10:00
【０３６３】
すなわち、該ＨＴＴＰレスポンスに含まれるデータの情報を含む拡張ヘッダを含むＨＴＴＰレスポンスは、次のようなレスポンスになる。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: application/octet-stream
X-Section-Info: type = section ; pid = 0x5014; table_id = 0x3B; media_time=00:10:00
(空行)
[要求されたセクションデータ]
【０３６４】
また、ここでは拡張ヘッダを用いてＨＴＴＰレスポンスに含まれる情報を記述する方法を説明したが、他の形式であってもよい。
【０３６５】
・Ｍｏｄｕｌｅ要求に対するレスポンス例
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: application/octet-stream
(空行)
[要求されたＭｏｄｕｌｅデータ]
【０３６６】
なお、該ＨＴＴＰレスポンスに含まれるＭｏｄｕｌｅの種類を示す拡張ヘッダを生成してもよい。一例として、拡張ヘッダＸ−Ｍｏｄｕｌｅ−ＩｎｆｏがＣａｒｏｕｓｅｌＩＤ及びＭｏｄｕｌｅＩＤなどＨＴＴＰレスポンスに含まれるデータの取得条件や、該Ｍｏｄｕｌｅがストリーム中から取得されたタイミングであるメディアタイムを含む。もちろん、ＨＴＴＰリクエストで指定された条件を含んでもよい。なお、拡張ヘッダＸ−Ｍｏｄｕｌｅ−Ｉｎｆｏが含む情報は、該ＨＴＴＰレスポンスに含まれるデータを識別できる情報であれば、他の情報であってもよい。
X-Module-Info: type = module ; carouselID = 0x0001; ModuleID=0x0001 ; ModuleVersion = 0
【０３６７】
すなわち、該ＨＴＴＰレスポンスに含まれるデータの情報を含む拡張ヘッダを含むＨＴＴＰレスポンスは、次のようなレスポンスになる。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: application/octet-stream
X-Module-Info: type = module ; carouselID = 0x0001; ModuleID=0x0001 ; ModuleVersion = 0
(空行)
[要求されたＭｏｄｕｌｅデータ]
【０３６８】
また、ここでは拡張ヘッダを用いてＨＴＴＰレスポンスに含まれる情報を記述する方法を説明したが、他の形式であってもよい。
【０３６９】
・Ｏｂｊｅｃｔ要求に対するレスポンス例
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: application/octet-stream
(空行)
[要求されたＯｂｊｅｃｔデータ]
【０３７０】
なお、該ＨＴＴＰレスポンスに含まれるＯｂｊｅｃｔの種類を示す拡張ヘッダを生成してもよい。一例として、拡張ヘッダＸ−Ｏｂｊｅｃｔ−Ｉｎｆｏがパスや該Ｏｂｊｅｃｔがストリーム中から取得されたタイミングであるメディアタイムを含む。もちろん、ＨＴＴＰリクエストで指定された条件をそのまま含んでもよい。なお、拡張ヘッダＸ−Ｏｂｊｅｃｔ−Ｉｎｆｏが含む情報は、該ＨＴＴＰレスポンスに含まれるデータを識別できる情報であれば、他の情報であってもよい。
X-Object-Info: type = Object ; path=/a/TopXlet.class ; Media_time = 00:09:00
【０３７１】
すなわち、該ＨＴＴＰレスポンスに含まれるデータの情報を含む拡張ヘッダを含むＨＴＴＰレスポンスは、次のようなレスポンスになる。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: application/octet-stream
X-Object-Info: type = Object ; path=/a/TopXlet.class ; Media_time = 00:09:00
(空行)
[要求されたＯｂｊｅｃｔデータ]
【０３７２】
また、ここでは拡張ヘッダを用いてＨＴＴＰレスポンスに含まれる情報を記述する方法を説明したが、他の形式であってもよい。
【０３７３】
そして、制御部２８０１ａは、受信したＨＴＴＰレスポンスメッセージを、判定部２８０１ｄへ引き渡し、その解釈を依頼する。
【０３７４】
判定部２８０１ｄでは、まず、ＨＴＴＰレスポンスのレスポンスコードを確認する。結果が２００  ＯＫの場合は、それを制御部２８０１ａに伝える。すると、制御部２８０１ａは、ＨＴＴＰレスポンスのボディ部にある受信したデータを第１メモリ２４０２へ記録し、データ取得要求を行ったライブラリへ通知する。
【０３７５】
以上のように、セクション、Ｍｏｄｕｌｅ、Ｏｂｊｅｃｔを要求することで、録画ストリームとは別に取得することができる。このような方法を実現することにより、特殊再生中など、データ放送用データを取得できないことがあった場合でもマルチメディアデータ受信装置１０２が必要とするデータを、要求に応じてマルチメディアデータ送信装置１０１から取得することができる。
【０３７６】
（実施の形態３）
実施の形態１及び２では、マルチメディアデータ受信装置１０２のストリーム及びセクション及びＭｏｄｕｌｅ及びＯｂｊｅｃｔの取得要求に対し、マルチメディアデータ送信装置１０１が要求に応じたデータを選択し、マルチメディアデータ受信装置１０２へ送出していた。一方、本実施の形態では、マルチメディアデータ送信装置１０１が管理していたイベントテーブルあるいはデータテーブルをマルチメディアデータ受信装置１０２へ送出し、マルチメディアデータ受信装置１０２がバージョンアップなどの発生を考慮し、マルチメディアデータ送信装置１０１へリクエストを出すか否かを判断することを特徴とする。なお、このようにマルチメディアデータ受信装置１０２が、各データのバージョンアップを検知することにより、マルチメディアデータ送信装置１０１へデータ取得依頼を発行する必要性を判断できるため、例えばバージョンアップが発生したときのみ、リクエストを発行するようにすれば、ネットワーク上のトラフィックを抑えることができるという利点がある。また、実施の形態１では、マルチメディアデータ送信装置１０１がイベントテーブルに含まれるようなイベント情報を、特殊再生中であっても必ずマルチメディアデータ受信装置１０２へ送出する必要があったが、イベントテーブルをマルチメディアデータ受信装置１０２に送出する本実施の形態では、マルチメディアデータ受信装置１０２がイベントを検知できるため、必ずしもこのような処理を行う必要はない。
【０３７７】
まず、マルチメディアデータ送信装置１０１について説明する。
【０３７８】
マルチメディアデータ送信装置１０１は、実施の形態１及び２で説明した機能の全部あるいは一部と同等の処理を行うため説明を省略するが、本実施の形態で説明するマルチメディアデータ送信装置１０１は、マルチメディアデータ受信装置１０２の要求に応じてイベントテーブル及びデータテーブルを送出する機能を持つ。
【０３７９】
ここでは、一例として、マルチメディアデータ送信装置１０１へのイベントテーブル及びデータテーブルの取得要求として拡張ヘッダＸ−Ｉｎｄｅｘ−Ｒｅｑｕｅｓｔを用いる。なお、リクエストの形式は、これまで同様、イベントデータあるいはデータテーブルあるいは両方のいずれかの取得要求を行っていることがわかる形式であれば、どのような形式でもよい。
【０３８０】
本実施の形態におけるネットワークライブラリ４０５ｅの処理について、次のようなリクエストメッセージを受信した場合を例に説明する。なお、本実施の形態におけるネットワークライブラリ４０５ｅの構成は、図２３Ａに示したものと同様である。
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
X-Index-Request: type = Event table
X-Index-Request: type = Data table
【０３８１】
受信したリクエストメッセージが正しいものであれば、制御部２３ｂは、クライアントより指定されたコンテンツのＵＲＩより、録画ストリームの名前などの識別子（ここでは、０００１．ｍ２ｔｓ）と拡張ヘッダＸ−Ｉｎｄｅｘ−Ｒｅｑｕｅｓｔによって指定された「Ｅｖｅｎｔ  ｔａｂｌｅ」「Ｄａｔａ  ｔａｂｌｅ」を取得し、データ取得部２３ｄへ引き渡す。制御部２３ｂは、データ取得部２３ｄにおける処理の結果や送信するデータタイプなどヘッダ生成に必要な情報をＨｅａｄｅｒ生成部２３ｅに引き渡し、ＨＴＴＰレスポンスメッセージのヘッダを生成する。なお、制御部２３ｂは、データ取得部２３ｄが取得したデータを分割し、生成したヘッダと分割されたストリームよりＨＴＴＰレスポンスを生成する。そして、生成したＨＴＴＰメッセージを情報送信部２３ｆに引き渡して、該要求元端末へ送信する。
【０３８２】
データ取得部２３ｄは、ＩＯ４０５ｇに依頼して図２１に示すストリーム関連テーブル２２００あるいは図３４に示すストリーム関連テーブル３４００を読み出す。ここでは一例としてストリーム関連テーブル３４００を用いる。データ取得部２３ｄは、制御部２３ｂによって引き渡された識別子と列２２０１を参照し録画ストリームの名前などの識別子を比較し、制御部２３ｂによって引き渡された識別子に関連するコンテンツの存在を確認する。存在しない場合には、そのエラー内容を制御部２３ｂへ通知し終了する。一方、存在した場合は、識別子が一致する録画ストリームの格納場所２２０３と、「Ｅｖｅｎｔ  ｔａｂｌｅ」がＴｙｐｅに指定されている場合は、イベントテーブルの名前などの識別子２２０４とそのイベントテーブル格納場所２２０５を取得し、「Ｄａｔａ  ｔａｂｌｅ」がＴｙｐｅに指定されている場合は、データテーブル識別子３４０６とデータテーブル格納場所３４０７を取得する。次に、データ取得部２３ｄは、取得したイベントテーブル、あるいはデータテーブルの名前などの識別子２２０４及び３４０６とそのイベントテーブル格納場所２２０５及び３４０７をもとに、イベントテーブル（図２０、図２１）あるいは、データテーブル（図３３Ａ、図３３Ｂ、図３５Ａ、図３５Ｂ、図３６Ｃの３６０３、図３８、図４０、図４１、図４３のいずれか）を取得し、制御部２３ｂへ引き渡す。なお、各イベントテーブル及びデータテーブルが保持する格納場所（図２０の列２００４および、図３３Ａまたは図３３Ｂの列３３０３および列３３３３、図３６Ｃの列３６１６）は、マルチメディアデータ受信装置１０２へ送出するテーブルからは削除し、マルチメディアデータ受信装置１０２が実施の形態１および２のように取得要求を行い、マルチメディアデータ送信装置１０１も同じイベントテーブル及びデータテーブルを参照することで、要求されたデータを送出するという方法でもよいし、これら格納場所を、第２メモリ２０３上でそれらのデータが格納されている場所を指し示すＵＲＬに書き換え、マルチメディアデータ受信装置１０２が直接データを指定し取得する方式でもよい。
【０３８３】
なお、ここでイベントテーブルあるいはデータテーブルが存在しなくても、ＨＴＴＰレスポンスは要求された録画ストリーム「０００１．ｍ２ｔｓ」が存在すれば、エラーにはせずに、ＨＴＴＰレスポンスの拡張ヘッダＸ−Ｉｎｄｅｘ−Ｒｅｓｐｏｎｓｅを利用し、以下のように通知してもよい。
X-Index-Response：result = no event table, no data table
【０３８４】
Ｈｅａｄｅｒ生成部２３ｅは、制御部２３ｂによって引き渡されたＨＴＴＰリクエストへの結果とデータ取得部２３ｄが取得したイベントテーブルあるいはデータテーブルなど、Ｈｅａｄｅｒ生成に必要なデータをもとに、ＨＴＴＰレスポンスのＨｅａｄｅｒを生成し制御部へ返す。
【０３８５】
情報送信部２３ｆは、制御部２３ｂによって引き渡されたＨｅａｄｅｒ生成部２３ｅが生成したＨｅａｄｅｒとデータ取得部２３ｄが生成したストリームを該要求元端末へ送信する。
【０３８６】
正常に処理を終了した場合のレスポンスの一例を示す。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: video/mpeg
X-Index-Info: type=event table ; url = http://192.168.0.3/table/0001_event.dat
X-Index-Info: type=data table ; url = http://192.168.0.3/table/0001_data.dat
(空行)
[実施の形態１で説明したデータ取得部２３ｄが生成したストリームのデータ]
【０３８７】
また、イベントテーブル及びデータテーブルが存在しなかった場合のレスポンスの一例を示す。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: video/mpeg
X-Index-Response：type=event table; result = no event table
X-Index-Response：type=data table; result = no data table
(空行)
[実施の形態１で説明したデータ取得部２３ｄが生成したストリームのデータ]
【０３８８】
マルチメディアデータ送信装置１０１が上記のようなレスポンスを返すことで、マルチメディアデータ受信装置１０２は、イベントテーブル及びデータテーブルがマルチメディアデータ送信装置１０１に存在する場合は、各テーブルのURLを取得する。そして、各URLを用いてマルチメディアデータ送信装置１０１へ取得要求のＨＴＴＰレスポンスを発行することで、イベントテーブル及びデータテーブルを取得することができる。
【０３８９】
次に、マルチメディアデータ受信装置１０２について説明する。
【０３９０】
マルチメディアデータ受信装置１０２の機能については、実施の形態１及び２で既に説明しているため同等の機能を行う処理は説明を省略し、ここでは差分についてのみ説明する。
【０３９１】
本実施の形態で説明するマルチメディアデータ受信装置１０２は、実施の形態２においてマルチメディアデータ送信装置１０１が行っていたイベントテーブル及びデータテーブルを参照し、データのバージョンアップの発生の有無を確認していた処理を行うことを特徴とする。
【０３９２】
本実施の形態で説明するネットワークライブラリ２５０４ｄの構成を図４４に示す。データ管理部４４０１ｆは、以下の３つの機能あるいはその一部を保持する。
【０３９３】
「データの管理」
マルチメディアデータ受信装置１０２が受信したイベントテーブル及びデータテーブルと取得したデータを管理する。具体的には、管理するデータにバージョンアップが発生するタイミングで取得データを削除する。
【０３９４】
「データ更新の通知」
イベントテーブル及びデータテーブルを確認し、バージョンアップが発生したタイミングになると、更新通知の依頼を受けた各ライブラリへ更新を通知する。例えば、制御部２８０１ａが、更新通知の依頼を要求することで、現在ネットワークライブラリ２５０４ｄがマルチメディアデータ送信装置１０１へ取得依頼を発行しているデータに更新が発生した場合は、リクエストを停止することができる。また他の例としては、ネットワークライブラリ２５０４ｄへデータ取得を行った各ライブラリが更新通知依頼を行うことにより、マルチメディアデータ受信装置１０２はセクションなどの要求データのバージョンアップが発生したタイミングを検知することができるため、バージョンアップの発生をアプリケーションへ通知することや、内部処理の変更に利用することができる。
【０３９５】
「データの事前取得」
イベントテーブル及びデータテーブルを確認し、マルチメディアデータ受信装置１０２の各ライブラリから要求が発生する前に、必要となるデータをマルチメディアデータ送信装置１０１より事前に取得することができる。これにより、各ライブラリがデータを必要とするタイミングには、既にデータを取得しておくことができるため、マルチメディアデータ受信装置１０２は、マルチメディアデータ送信装置１０１からデータを取得するために発生する時間を短縮することができる。また特に、データ放送を実現するために必要なタイミングに関連するデータを事前に取得しておくことで、データ放送を正しく再生することができるようになる。
【０３９６】
なお、図４４において図２８と同じ番号を付しているものは図２８と同等の処理を行う。そのためここでは、図２８との差分についてのみ説明する。
【０３９７】
ネットワークライブラリ２５０４ｄの制御部２８０１ａは、各ライブラリよりデータ取得の依頼を受けると、引き渡されたデータ取得要求の情報をデータ管理部４４０１ｆへ引き渡す。データ管理部４４０１ｆは、制御部２８０１ａによって引き渡されたデータ取得要求に関連するデータが、既に保持しているデータに存在しないか確認する。データ管理部４４０１ｆが保持するデータに依頼されたデータが存在しない場合は、データ管理部４４０１ｆは制御部２８０１ａへ存在しないことを通知する。これを受けた制御部２８０１ａは実施の形態１及び２で説明した処理と同等の処理を行い、マルチメディアデータ送信装置１０１からデータ取得を行う。一方、データ管理部４４０１ｆに既に依頼されたデータが存在する場合は、該当データにバージョンアップが発生していないか、実施の形態１及び２においてマルチメディアデータ送信装置１０１が行った処理と同等の処理を行い確認する。バージョンアップが発生している場合は、制御部２８０１ａへ該当データが存在しないことを通知する。これを受けた制御部２８０１ａは実施の形態１及び２で説明した処理と同等の処理を行い、マルチメディアデータ送信装置１０１からデータ取得を行う。また、バージョンアップが発生していない場合は、データ管理部４４０１ｆが保持するデータを制御部２８０１ａへ引き渡す。制御部２８０１ａは、データ管理部４４０１ｆから受け取ったデータを各ライブラリへ引き渡す。
【０３９８】
また、データ管理部４４０１ｆは、データ更新の監視依頼を受けることができる。データ管理部４４０１ｆは、依頼された各データが更新されるメディアタイムの時間になると、バージョンアップが起こったことを、データ更新依頼を行ったライブラリや制御部２８０１ａへ通知する。なお、データ管理部４４０１ｆがメディアタイムを取得するために、ＪＭＦ２５０４ａなど他のライブラリを利用してもよいし、データ管理部４４０１ｆの中で時間をカウントする方法で実現してもよい。また、ここではメディアタイムを用いて、タイミングを指定された場合を説明したが、これまで同様、タイミングを指定する方法はメディアタイム以外の情報を利用してもよい。
【０３９９】
また、データ管理部４４０１ｆは、録画データ取得要求がＪＭＦ２５０４ａより発行された際などに、イベントテーブル及びデータテーブルを参照し、予め必要となるデータを予想し、マルチメディアデータ送信装置１０１から取得することができる。一例として、イベントテーブル図２１を取得した場合、データ放送実現の際に必要となるＰＡＴ２０１０とＰＭＴ２０１１とＡＩＴ２０１２とＤＳＩ２０１３とＤＩＩ２０１４を取得しておくという方法でもよい。更にデータ放送のイベントに関しては、タイミングが重要であるため、事前に取得する場合は、ＮＰＴ２０１７とＳｔｒｅａｍＥｖｅｎｔ２０１８とＳｔｒｅａｍＥｖｅｎｔ２０１９も予め取得しておくという方法でもよい。
【０４００】
更にデータテーブルに関しては、一例としてデータテーブル図４１を受信したデータ管理部４４０１ｆは、データ放送のタイミングに関連するデータであるＳｔｒｅａｍ３６２８及びＳｔｒｅａｍＥｖｅｎｔ３６２６に関しては事前に取得するという方法でもよい。また、データ管理部４４０１ｆはあらかじめ３６２１から３６２８の全てのデータ取得を行うという方針でもよい。またデータ管理部４４０１ｆは、３６２３のＯｂｊｅｃｔが１０：００のメディアタイムに更新されることがわかるため、事前に１０：００以降の該当Ｏｂｊｅｃｔを取得しておき、バージョンアップが発生した際でも、マルチメディアデータ送信装置１０１へ取得要求を出す必要がないように制御する方針でもよい。
【０４０１】
また、データ管理部４４０１ｆはイベントテーブル２０１２のＡＩＴを取得した際に、ＡＩＴに記述されたプログラム名（例：図１９の２６０４）によって指定されたデータを事前に取得するという方法でもよい。
【０４０２】
以上のようにマルチメディアデータ受信装置１０２がイベントテーブルやデータテーブルを管理することで、必要となるデータ管理やバージョンアップの検知、更に、マルチメディアデータ送信装置１０１からの事前のデータ取得を可能とし、タイミングなどを考慮したデータ放送を実現することができる。
【０４０３】
なお、ここではデータ管理部４４０１ｆが、イベントテーブルやデータテーブルを管理する方法で説明したが、他のライブラリが本機能を実現してもよい。
【０４０４】
（実施の形態４）
以下、実施の形態１で用いた図１〜３および図５Ａ〜図１２と、図４５〜図５４とを参照しながら、本発明の実施の形態４を説明する。
【０４０５】
図１は、本発明の実施の形態４におけるマルチメディアコンテンツ通信システムの構成図である。図１において、１０１は本発明におけるマルチメディアデータ送信装置を、１０２は本発明におけるマルチメディアデータ受信装置を、１０３はネットワークを、１０４はこれらによって構成されるマルチメディアコンテンツ通信システムを表す。マルチメディアデータ送信装置１０１、マルチメディアデータ受信装置１０２は、ネットワーク１０３に接続されており、ネットワーク１０３を介して相互に通信可能である。また、１０５はケーブルテレビの放送局を、１０６は、マルチメディアデータ送信装置１０１と放送局１０５を結ぶケーブルを表す。
【０４０６】
本実施の形態におけるマルチメディアデータ送信装置１０１は、ネットワークインタフェースと、マルチメディアデータを蓄積する蓄積手段を備えた、デジタル放送を受信するＣＡＴＶ  ＳＴＢ（Ｓｅｔ  Ｔｏｐ  Ｂｏｘ）である。マルチメディアデータ送信装置１０１は、ケーブル１０６を介して放送局１０５に接続されている。そして、マルチメディアデータ送信装置１０１は、放送局１０５から受信したデジタル放送コンテンツのマルチメディアデータを、蓄積手段に蓄積する。また、ネットワークインタフェースを通して、ネットワーク１０３に接続されている。そして、ネットワーク１０３を通じて送信された、マルチメディアデータ受信装置１０２からの要求を受信する。マルチメディアデータ送信装置１０１は、マルチメディアデータ受信装置１０２からの要求に応じて放送局１０５から受信したデジタル放送コンテンツのマルチメディアデータ、あるいは、蓄積しているマルチメディアデータに関する情報を、ネットワーク１０３を通じてマルチメディアデータ受信装置１０２へ送信するものである。
【０４０７】
なお、マルチメディアデータ送信装置１０１が蓄積手段に蓄積するデジタル放送コンテンツは、ＭＰＥＧ２−ＴＳ形式のデータである。
【０４０８】
マルチメディアデータ受信装置１０２は、ユーザの要求により、マルチメディアデータ送信装置１０１へ、提供可能なコンテンツの一覧送信要求を送信する。そして、マルチメディアデータ送信装置１０１から、その返答として、コンテンツの一覧を受信し、ユーザに提示する。さらに、ユーザが選択したコンテンツについて、そのマルチメディアデータの送信要求を、マルチメディアデータ送信装置１０１へ送信する。その返答として、マルチメディアデータを受信し、再生してユーザに提示する。さらに、ユーザから早送りや巻き戻しなどの特殊再生の要求を受け付けると、一旦マルチメディアデータの通信を停止し、改めて、特殊再生に必要な部分の送信要求を連続して発行し、その都度、マルチメディアデータを受信し、再生することにより、特殊再生を実現するものである。
【０４０９】
ネットワーク１０３は、家庭内に施設されたホームネットワークであり、イーサネット、無線ＬＡＮなどによって構成されたＩＰネットワークである。
【０４１０】
以下、マルチメディアデータ送信装置１０１と、マルチメディアデータ受信装置１０２の通信とそれぞれの動作について説明する。
【０４１１】
マルチメディアデータのサーバとなるマルチメディアデータ送信装置１０１は、ネットワーク１０３に接続されると、サービスを提供可能なサーバであることを、ネットワーク１０３にブロードキャストすることにより、他の装置に通知する。更に、マルチメディアデータ送信装置１０１は、ネットワーク１０３に接続された他の装置からの要求により、マルチメディアデータ送信装置１０１が提供するサービスと、そのアクセスの方法を、要求元の装置に送信する。また、クライアントとなるマルチメディアデータ受信装置１０２は、ネットワーク１０３に接続されると、ネットワーク１０３に接続されたサーバ装置を検索し、各サーバ装置がどのような機能を持っているかを取得する。この通信は、ＤＬＮＡと同様に、ＵＰｎＰ  ＤＡ（Ｄｅｖｉｃｅ  Ａｒｃｈｉｔｅｃｔｕｒｅ）で定義されている方法により行えるため、詳細な説明は省略する。これにより、マルチメディアデータ受信装置１０２は、マルチメディアデータ送信装置１０１がネットワーク１０３に接続されているマルチメディアサーバであることを認識できる。
【０４１２】
以下、マルチメディアデータ送信装置１０１とマルチメディアデータ受信装置１０２との間で行われるマルチメディアデータの通信について、順を追って説明する。
【０４１３】
まず、マルチメディアデータ受信装置１０２は、マルチメディアデータ送信装置１０１に対し、提供可能なコンテンツの一覧送信要求を発行する。そして、マルチメディアデータ送信装置１０１は、その要求を受け、提供可能コンテンツを検索し、その一覧を、マルチメディアデータ受信装置１０２へ返信する。この通信は、ＵＰｎＰ  ＡＶ  ＣＤＳ（Ｃｏｎｔｅｎｔ  Ｄｉｒｅｃｔｏｒｙ  Ｓｅｒｖｉｃｅ）のＢｒｏｗｓｅもしくはＳｅａｒｃｈによって行えるものであり、その詳細説明は省略する。
【０４１４】
マルチメディアデータ送信装置１０１は、マルチメディアデータ受信装置１０２から提供可能なコンテンツの一覧送信要求を受信すると、蓄積手段に蓄積したコンテンツの一覧を返信する。送信する一覧は、ＵＰｎＰ  ＡＶもしくはＤＬＮＡにて定義されているものが利用できるため、詳細説明は省略する。
【０４１５】
提供コンテンツ一覧を受信したマルチメディアデータ受信装置１０２は、その一覧をユーザに提示する。そして、ユーザが選択したコンテンツのマルチメディアデータの送信を、マルチメディアデータ送信装置１０１へ要求する。マルチメディアデータ送信装置１０１は、要求されたコンテンツデータを蓄積手段から読み出し、マルチメディアデータ受信装置１０２へ送信する。マルチメディアデータの通信は、ＤＬＮＡにて必須プロトコルとなっているＨＴＴＰを用いて通信するものとする。
【０４１６】
ここで、ユーザから特殊再生を要求されると、マルチメディアデータ受信装置１０２は、早送りや巻き戻し、スローといった特殊再生の種類に応じて、必要なデータ区間を判定し、これらの区間のみのデータを受信して再生、表示することを繰り返すことにより、特殊再生を行うこととする。このため、マルチメディアデータ受信装置１０２は、特殊再生を行うと、該マルチメディアデータの全てのＴＳパケットを取得することができない場合がある。この場合、例えば、再生に必要な番組構成を表現するテーブル、あるいは、データ放送のアプリケーションを表現するテーブルといった、マルチメディアデータ中の情報について、そのバージョンアップなどの変化が起こったとしても、それを検知することが出来ない場合が起こる。そのため、再生を正しく行えない、もしくは、データ放送のアプリケーションを正しく起動、動作させることが出来ない、といったことが起こる。そこで、マルチメディアデータ受信装置１０２は、マルチメディアデータ送信装置１０１へ変化点情報の送信を要求する。
【０４１７】
このような通信は、以下のように行うことが出来る。
【０４１８】
該マルチメディアデータのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）をｈｔｔｐ：／／１９２．１６８．０．３／ＡＶＤａｔａ／０００１．ｍ２ｔｓとする。そしてマルチメディアデータ中の情報の変化点情報送信の要求を、ＨＴＴＰリクエストに拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔをつけることによって行う。拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔは、要求するマルチメディアデータ中の変化点の種類、送信を要求する変化点発生の範囲をセミコロン“；”で区切ることとする。また、変化点の種類を示す指示子としてtypeを使用し、“type=xx”と指定することとする。送信を要求するマルチメディアデータ中の変化点の種類の一例として、番組構成を表現するテーブルはｓｉと指定し、データ放送のアプリケーションを表現するテーブルはａｉｔと指定する。また、送信を要求する変化点発生の範囲は、指示子scopeを使用し、“scope=yy”のように指定することとする。該マルチメディアデータ中の全ての変化点の送信要求を行う場合はａｌｌと指定する。送信要求範囲の指定に関しては後述する。例えば、データ放送のアプリケーションを表現するテーブルのバージョン情報を、マルチメディアデータ全区間について送信要求を行う場合は、以下の拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔを用いることとなる。
X-Version-Request: type = ait ; scope = all
【０４１９】
したがって、マルチメディアデータ受信装置１０２からマルチメディアデータ送信装置１０１へ、以下の例のようなＨＴＴＰリクエストが発行される。
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
X-Version-Request: type = ait ; scope = all
【０４２０】
このＨＴＴＰリクエストを受信したとき、マルチメディアデータ送信装置１０１は、該マルチメディアデータをマルチメディアデータ受信装置１０２へ送信するとともに、要求されたマルチメディアデータより、指定された範囲の変化点情報を検出し、マルチメディアデータ受信装置１０２へ送信する。
【０４２１】
ここで、マルチメディアデータ送信装置１０１は、マルチメディアデータの変化点情報を提供するＵＲＩを、ＨＴＴＰレスポンスの拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏによって示すことで返信する。拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏは、その値として、指示子typeを用いて変化点を通知する情報の種類を表し、指示子urlを用いて該変化点情報を提供するＵＲＩを表すこととする。例えば、上記リクエストに対するレスポンスの場合、変化点を提供するＵＲＩをhttp://192.168.0.3/VUP/0001-ait.vupとすれば、拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏは以下のようになる。
X-Version-Info: type=ait ; url = http://192.168.0.3/VUP/0001-ait.vup
【０４２２】
正常に処理を行えた場合、レスポンスコードとして２００  ＯＫを用いてレスポンスを行う。したがって、上記リクエストに対するレスポンスは以下のようになる。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: video/mpeg
Content-Length: 47952
X-Version-Info: type=ait ; url = http://192.168.0.3/VUP/0001-ait.vup
(空行)
[47952バイトのデータ]
【０４２３】
また、リクエスト中のＸ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔの値について、typeで指定される種類が不正であった場合、他にＨＴＴＰに関するエラーが起こっていなければ、レスポンスコードとして２００  ＯＫを用いてレスポンスを行うが、拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏの値を、“Invalid type”として、不正なリクエストであったことを通知する。例えば、以下のレスポンスのようになる。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: video/mpeg
Content-Length: 47952
X-Version-Info: Invalid type
(空行)
[47952バイトのデータ]
【０４２４】
また、リクエスト中のＸ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔの値について、scopeで指定される種類が不正であった場合、他にＨＴＴＰに関するエラーが起こっていなければ、レスポンスコードとして２００  ＯＫを用いてレスポンスを行うが、拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏの値を、“Invalid scope”として、不正なリクエストであったことを通知する。例えば、以下のレスポンスのようになる。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: video/mpeg
Content-Length: 47952
X-Version-Info: Invalid scope
(空行)
[47952バイトのデータ]
【０４２５】
また、受信したＨＴＴＰリクエストについて、要求されたＵＲＩに対応するマルチメディアデータがないなど、拡張したもの以外のＨＴＴＰに関するエラーが含まれていれば、それにあったレスポンスを行う。この場合、Ｘ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔが含まれているリクエストに対しても、レスポンスには、Ｘ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏを含めないこととする。
【０４２６】
なお、ここで拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏによって指定されたＵＲＩによって取得できるデータは、マルチメディアデータ送信装置１０１とマルチメディアデータ受信装置１０２間において、同じ解釈が可能な情報であるならば、どのような情報形態であってもよい。一例としては、表形式で記述されたデータ、ＸＭＬで記述されたデータ、バイナリのセクションデータなどがあげられる。
【０４２７】
また、ここではマルチメディアデータ受信装置１０２からのＨＴＴＰリクエストに拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔを登録したことにより、マルチメディアデータ送信装置１０１が、ＨＴＴＰレスポンスに拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏを追加し返信するという方法を説明したが、マルチメディアデータ受信装置１０２から明示的に変化点情報送信のリクエストを行うことなく、マルチメディアデータ送信装置１０１から拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏによって変化点情報を通知するという実施形態であってもよい。
【０４２８】
また、ＨＴＴＰレスポンスの拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏにストリーム中の変化点情報を追記するという方法であってもよい。一例として、ｌｅｎｇｔｈに実データのサイズを示し、ｂｙｔｅｓにセクションデータのバイナリ情報を明記するという方法がある。またこれ以外にも、バイナリ情報ではなく、テキスト化された情報を明記するという方法であってもよい。
X-Version-Info: type=ait; length = 100 ; bytes = 110110010001001……1111
【０４２９】
また、ＨＴＴＰレスポンスの拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏにストリームの変化点情報を伝送するセクションデータを含むマルチメディアデータのバイト位置による範囲を指定するという方法であってもよい。一例として、ｔｙｐｅ指示子よりセクションデータの種類を示し、その種類には、番組構成を表現するテーブルをｓｉあるいは、データ放送のアプリケーションを表現するテーブルをａｉｔと指定する。また、ｂｙｔｅｓ指示子を用いて、マルチメディアデータの先頭を０とし、セクションデータを伝送するバイト位置の範囲を指定する。なお、バイト位置の範囲をＴＳパケットのパケット番号で指定してもよい。これはＴＳパケットが１８８バイトの固定長であることより、容易に計算可能である。
X-Version-Info : type=ait; bytes=5000-10000
【０４３０】
そして、このようにセクションデータを伝送するバイト位置の範囲を通知されたマルチメディアデータ受信装置１０２は、指定されたバイト位置範囲を指定して、再度マルチメディアデータの取得要求を行うことにより、変化点情報を含むセクションデータを取得することができる。
【０４３１】
なお、ここでは、要求する変化点の種類として、番組構成を表現するテーブル（ｓｉ）及び、データ放送のアプリケーションを表現するテーブル（ａｉｔ）を個別に指定する方法を示したが、マルチメディアデータ中の変化点全てをまとめて取り扱うという方法であってもよい。例えば、マルチメディアデータ送信装置１０１及びマルチメディアデータ受信装置１０２間で、拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔにおいてｔｙｐｅをａｌｌと指定した場合、マルチメディアデータ送信装置１０１は、マルチメディアデータ中の指定された範囲における、ｓｉとａｉｔすべてのセクションデータの変化点を一つの変化点情報として通知する、としても良い。
【０４３２】
また、以上の説明では、取得する変化点情報の発生する範囲としてマルチメディアデータ全てを対象とした方法を示したが、該マルチメディアデータの特定の範囲で変化点の発生があった際に、その変化点情報を通知するという方法であっても良い。例えば、拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔにおいて、変化点送信要求範囲の指定は、該マルチメディアデータの先頭からのバイト位置で指定しても良い。これは、scope指示子に、ストリームの先頭を０としたバイト位置で始点と終点とを表し、それらをハイフンでつなぐことにより指定できる。また、終点を省略した場合には、該マルチメディアデータの終わりまでを指定することとする。ただし、複数の範囲を同時に指定することは出来ないものとする。例えば、マルチメディアデータ中の変化点の要求範囲の送信開始要求位置を該マルチメディアデータの先頭を０として４７９４０バイト目、送信終了要求位置を該マルチメディアデータの先頭を０として９５８７９バイト目とし、要求する変化点の種類はデータ放送のアプリケーションを表現するテーブルとすれば、以下の拡張ヘッダにより要求することとなる。
X-Version-Request : type = ait ; scope = 47940-95879
【０４３３】
また、該マルチメディアデータの先頭から４７９４０バイト目までに発生する、データ放送のアプリケーションを表現するテーブルの変化点の情報を要求する場合には、以下の拡張ヘッダとなる。
X-Version-Request : type = ait ; scope = 0-47940
【０４３４】
また、該マルチメディアデータの４７９４０バイト目から終わりまでに発生する、データ放送のアプリケーションを表現するテーブルの変化点の情報を要求する場合には、以下の拡張ヘッダとなる。
X-Version-Request : type = ait ; scope = 47940-
【０４３５】
このような拡張ヘッダを含むリクエストに関するＨＴＴＰレスポンスは、上述したレスポンスと同様な形式で行うことが可能である。
【０４３６】
なお、本実施の形態においては、送信要求を行う変化点発生の範囲の指定を、該マルチメディアデータにおけるバイト位置で指定したが、該マルチメディアデータのコンテンツの開始からの経過時間で指定する方法でも同様の効果を得られる。
【０４３７】
また、データ放送のアプリケーションを表現するテーブル（ａｉｔ）の変化点情報を受信することにより、マルチメディアデータ受信装置１０２では、アプリケーションの管理情報の変化を検知することができる。そのため、マルチメディアデータ受信装置１０２上で、アプリケーションの起動や停止などが可能となる。このとき、アプリケーションのファイルは、マルチメディアデータ送信装置１０１から、マルチメディアデータに多重化されてマルチメディアデータ受信装置１０２へ送られ、マルチメディアデータ受信装置１０２にてマルチメディアデータから抽出しても良く、また、マルチメディアデータ送信装置１０１から、マルチメディアデータとは別に、マルチメディアデータ受信装置１０２へ送られる構成であっても良い。以下に、後者の場合における、マルチメディアデータ受信装置１０２が、マルチメディアデータ送信装置１０１からアプリケーションのファイルを取得する方法の一例を示す。
【０４３８】
まず、マルチメディアデータ受信装置１０２は、ファイルが保存されている場所に関する情報をマルチメディアデータ送信装置１０１へ要求する。ここでは、ベースとなるディレクトリを要求することとする。これは、以下のような拡張ヘッダＸ−Ｔｒｅｅ−Ｂａｓｅ−Ｒｅｑｕｅｓｔを用いて、マルチメディアデータを要求するＨＴＴＰリクエストのヘッダに設定する。
X-Tree-Base-Request : carousel_id = 1
【０４３９】
このヘッダを含んだＨＴＴＰリクエストは以下の例のようになる。
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
X-Tree-Base-Request : carousel_id = 1
【０４４０】
このＨＴＴＰリクエストを受信したマルチメディアデータ送信装置１０１は、アプリケーションのファイルツリーを保存しているディレクトリを、拡張ヘッダＸ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏを用いてＨＴＴＰレスポンスのヘッダに記述し、このレスポンスを送信する。Ｘ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏヘッダの例を以下に示す。
X-Tree-Base-Info : directory = /DVR/Content/0001/Carousel1/ 
【０４４１】
また、Ｘ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏヘッダを含むＨＴＴＰレスポンスは以下の例のようになる。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: video/mpeg
Content-Length: 47952
X-Tree-Base-Info : directory = /DVR/Content/0001/Carousel1/ 
(空行)
[47952バイトのデータ]
【０４４２】
このレスポンスを受信したマルチメディアデータ受信装置１０２は、マルチメディアデータ送信装置１０１からファイル取得を行う場合に、取得したファイルディレクトリとファイルパスとを連結して示すことでファイルを特定することが出来るため、該ファイルを取得することができる。例えば、Ｘ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏによって、マルチメディアデータ送信装置１０１のＨＴＴＰサーバのルートディレクトリからのパスを返すとしたならば、取得したベースディレクトリを「/DVR/Content/0001/Carousel1/」、アプリケーションのベースディレクトリを「/」、アプリケーションのベースディレクトリからの相対パスを「TestXlet1.class」とした場合、マルチメディアデータ受信装置１０２は、マルチメディアデータ送信装置１０１へ、「http://192.168.0.3/DVR/Content/0001/Carousel1/TestXlet1.class」をリクエストすることで、マルチメディアデータ送信装置１０１からファイルを受信することができる。
【０４４３】
また、Ｘ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏによって、ＮＦＳ（Ｎｅｔｗｏｒｋ  Ｆｉｌｅ  Ｓｙｓｔｅｍ）によってマウントを許可するディレクトリが通知され、そこにネットワークマウントを行うことで、ファイルにアクセスするという方法であっても、同様の効果が得られる。例えば、Ｘ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏによって通知された「/DVR/Content/0001/Carousel1/」で示される、マルチメディアデータ送信装置１０１のディスクもしくはディレクトリに対し、マルチメディアデータ受信装置１０２がＮＦＳマウントすることによって、その下にあるファイルにアクセスすることが可能となる。
【０４４４】
以下、マルチメディアコンテンツ通信システム１０４を構成する、マルチメディアデータ送信装置１０１およびマルチメディアデータ受信装置１０２について、更に詳細に説明する。
【０４４５】
まず、マルチメディアデータ送信装置１０１について説明する。
【０４４６】
図２は、本実施の形態におけるマルチメディアデータ送信装置１０１を構成する構成要素の関係を示したブロック図であり、入力部２０１、第１メモリ２０２、第２メモリ２０３、受信部２０４、多重分離手段２０５、デスクランブラ２０６、ＴＳデコーダ２０７、映像出力部２０８、音声出力部２０９、ＴＳマルチプレクサ２１０、ネットワーク部２１１、ＣＰＵ２１２で構成される。
【０４４７】
入力部２０１は、フロントパネルやリモコン受光器等で構成され、ユーザからのチャンネル選択等の指示を受け付ける。図３は、フロントパネルで入力部２０１を構成した場合の一例である。３００はフロントパネルであり、上カーソルボタン３０１、下カーソルボタン３０２、左カーソルボタン３０３、右カーソルボタン３０４、ＯＫボタン３０５、取消ボタン３０６、ＥＰＧボタン３０７、シアターボタン３０８の８つのボタンを備えている。ユーザがボタンを押下すると、押下されたボタンの識別子が、ＣＰＵ２１２に通知される。
【０４４８】
第１メモリ２０２は、ＲＡＭ等で構成され、ＣＰＵ２１２が一時的にデータを保存する際に使用される。
【０４４９】
第２メモリ２０３は、フラッシュメモリ、ハードディスク等で電源が停止しても情報を保持可能なデバイスで構成され、ＣＰＵ２１２が実行するプログラムを保存する。第２メモリは、ＳＤメモリカード等の取り外し可能な記憶デバイスを用いていてもよい。
【０４５０】
受信部２０４は、ＣＡＴＶ局からのケーブルに接続され放送波を受信し、ＣＰＵ２１２から指定された周波数にチューニングし、ＭＰＥＧトランスポートストリームを抽出して、多重分離手段２０５に引き渡す。
【０４５１】
多重分離手段２０５は、受信部２０４からＭＰＥＧトランスポートストリームを受け取り、ＣＰＵ２１２から指定された情報を抽出しＣＰＵ２１２に引き渡す。またＭＰＥＧトランスポートストリームをそのままデスクランブラ２０６に引き渡す。
【０４５２】
デスクランブラ２０６は、多重分離手段２０５から与えられたスクランブルされているＭＰＥＧトランスポートストリームをデスクランブル（＝復号）し、ＴＳデコーダ２０７に引き渡す。デスクランブラ２０６は、マルチメディアデータ送信装置１０１に内蔵されたモジュールでも良いし、北米ケーブル受信機で導入されているＣａｂｌｅＣＡＲＤ（登録商標）でも実施可能である。ＣａｂｌｅＣＡＲＤの仕様は米国ＣａｂｌｅＬａｂｓが策定したＣａｂｌｅＣＡＲＤ  Ｉｎｔｅｒｆａｃｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎに記載されており、ここでは説明を省略する。
【０４５３】
ＴＳデコーダ２０７は、ＣＰＵ２１２から音声データ、映像データ、ＰＳＩ／ＳＩ情報などのセクションデータの識別子を受け取る。さらに、デスクランブラ２０６から受け取ったデスクランブルされたストリームから、受け取った音声データ、映像データ、ＰＳＩ／ＳＩ情報などのセクションデータの識別子に対応するデータを抽出する、抽出した映像データを映像出力部２０８に、音声データを音声出力部２０９に引き渡す。また、その両方と、セクションデータを、ＴＳマルチプレクサ２１０に引き渡す。
【０４５４】
映像出力部２０８は映像出力端子を含み、受け取った映像データを端子に対応した映像データに変換して出力する。端子の例としては、コンポジットケーブル端子などがある。
【０４５５】
音声出力部２０９は音声出力端子を含み、受け取った音声データを端子に対応した音声データに変換して出力する。端子の例としては、イヤホン端子や、コンポジットケーブル端子などがある。
【０４５６】
ＴＳマルチプレクサ２１０は、受け取った映像データ、音声データ、セクションデータからＭＰＥＧ２トランスポートストリームを構成し、該ＭＰＥＧ２トランスポートストリームをネットワーク部２１１に引き渡す。ＰＳＩ／ＳＩ情報は必要に応じて書き換えられる。
【０４５７】
ネットワーク部２１１は、ネットワークインタフェースを含み、ＣＰＵ２１２から受け取ったデータを、ネットワークインタフェースが接続されたネットワークの物理メディアに応じた信号に変換して出力する。また、ネットワークインタフェースから信号を受信し、ＩＰネットワークで規定されたパケットに変換して、ＣＰＵ２１２へ引き渡す。
【０４５８】
ＣＰＵ２１２は、第２メモリ２０３が記憶するプログラムを実行することで、受信部２０４、多重分離手段２０５、デスクランブラ２０６、ＴＳデコーダ２０７、ＴＳマルチプレクサ２１０、ネットワーク部２１１を制御する。
【０４５９】
図４５は、第２メモリ２０３に記憶され、ＣＰＵ２１２に実行されるプログラムの構成図の一例である。
【０４６０】
プログラム４００は、複数のサブプログラムで構成され、具体的にはＯＳ４０１、ＥＰＧ４０２、ＪａｖａＶＭ４０３、サービスマネージャ４０４、Ｊａｖａライブラリ４０５で構成される。
【０４６１】
ＯＳ４０１は、マルチメディアデータ送信装置１０１の電源が投入されると、ＣＰＵ２１２が起動するサブプログラムである。ＯＳは、オペレーティングシステムの略であり、Ｌｉｎｕｘ等が一例である。ＯＳ４０１は、他のサブプログラムを平行して実行するカーネル４０１ａ及びライブラリ４０１ｂで構成される公知の技術の総称であり、詳細な説明は省略する。本実施の形態においては、ＯＳ４０１のカーネル４０１ａは、ＥＰＧ４０２とＪａｖａＶＭ４０３をサブプログラムとして実行する。また、ライブラリ４０１ｂは、これらサブプログラムに対して、マルチメディアデータ送信装置１０１が保持する構成要素を制御するための複数の機能を提供する。
【０４６２】
本実施の形態では、ライブラリ４０１ｂは機能の一例として、チューナ４０１ｂ１、限定解除４０１ｂ２、ＡＶ再生４０１ｂ３、ＮＥＴ４０１ｂ４を含む。
【０４６３】
チューナ４０１ｂ１は、他のサブプログラムやＪａｖａライブラリ４０５のＴｕｎｅｒ４０５ｃから周波数を含むチューニング情報を受け取り、受信部２０４に引き渡す。受信部２０４は与えられたチューニング情報に基づき復調処理を行い、復調したデータを多重分離手段２０５に引き渡すことができる。この結果、他のサブプログラム及びＪａｖａライブラリ４０５のＴｕｎｅｒ４０５ｃはライブラリ４０１ｂを通して受信部２０４を制御することができる。
【０４６４】
限定解除４０１ｂ２は、他のサブプログラムやＪａｖａライブラリ４０５のＣＡ４０５ｄから情報を受け取り、デスクランブラ２０６に引き渡す。
【０４６５】
ＡＶ再生４０１ｂ３は、他のサブプログラムやＪａｖａライブラリ４０５のＪＭＦ４０５ａから、音声のパケットＩＤと映像のパケットＩＤを受け取る。受け取った音声のパケットＩＤと映像のパケットＩＤを、ＴＳデコーダ２０７に与える。この結果、ＴＳデコーダ２０７は与えられたパケットＩＤに基づいて、フィルタリングを行い、映像・音声の再生を実現する。
【０４６６】
ＮＥＴ４０１ｂ４は、他のサブプログラムやＪａｖａライブラリ４０５のネットワークライブラリ４０５ｅから受け取ったデータを、ＩＰネットワークで規定されるアプリケーション層より下のプロトコルのパケットを作成する。アプリケーション層より下のプロトコルとは、例えばＴＣＰパケット、ＵＤＰパケット、ＩＰパケットなどである。これをネットワーク部２１１に引き渡すことで、ネットワーク１０３を介して他の機器にメッセージおよびデータを送信する。また、ネットワーク１０３を介して他の機器からメッセージを受信したときに、他のサブプログラムやＪａｖａライブラリ４０５のネットワークライブラリ４０５ｅに、アプリケーション層のプロトコルのパケットに変換して引き渡す。アプリケーション層のプロトコルとは、例えば、ＨＴＴＰやＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）などである。
【０４６７】
ＥＰＧ４０２は、ユーザに番組一覧を表示及び、ユーザからの入力を受け付ける番組表示部４０２ａと、チャンネル選局を行う再生部４０２ｂで構成される。ここで、ＥＰＧはＥｌｅｃｔｒｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅの略である。ＥＰＧ４０２は、マルチメディアデータ送信装置１０１の電源が投入されると、カーネル４０１ａによって起動される。起動されたＥＰＧ４０２の内部では、番組表示部４０２ａと再生部４０２ｂが同時に起動される。番組表示部４０２ａは起動されると、マルチメディアデータ送信装置１０１の入力部２０１を通して、ユーザからの入力を待つ。ここで、入力部２０１が図３で示されるフロントパネルで構成されている場合、ユーザが、入力部２０１のＥＰＧボタン３０７を押下すると、ＥＰＧボタンの識別子がＣＰＵ２１２に通知される。ＣＰＵ２１２上で動作するサブプログラムであるＥＰＧ４０２の番組表示部４０２ａは、この識別子を受け取り、番組情報表示データを作成し、図示していないモニタ出力手段によりモニタ５１０に出力する。モニタ５１０は、マルチメディアデータ送信装置１０１が備えるものであっても良いし、マルチメディアデータ送信装置１０１とコンポジットケーブルやＨＤＭＩケーブルなどで接続されたテレビであっても良い。モニタ５１０は、受信した番組情報表示データを表示する。図５Ａ及び図５Ｂは、モニタ５１０に表示された番組表の一例である。図５Ａを参照して、モニタ５１０には、格子状に番組情報が表示されている、列５０１には、時刻情報が表示されている。列５０２には、チャンネル名「チャンネル１」と、列５０１の時刻に対応する時間帯に放映される番組が表示されている。「チャンネル１」では、９：００〜１０：３０に番組「ニュース９」が放映され、１０：３０〜１２：００は「映画ＡＡＡ」が放映されることを表す。列５０３も列５０２同様、チャンネル名「チャンネル２」と、列５０１の時刻に対応する時間帯に放映される番組が表示されている。９：００〜１１：００に番組「映画ＢＢＢ」が放映され、１１：００〜１２：００は「ニュース１１」が放映される。５３０は、カーソルである。カーソル５３０は、フロントパネル３００の左カーソル３０３と右カーソル３０４を押下すると移動する。図５Ａの状態で、右カーソル３０４を押下すると、カーソル５３０は右に移動し、図５Ｂのようになる。また、図５Ｂの状態で、左カーソル３０３を押下すると、カーソル５３０は左に移動し、図５Ａのようになる。
【０４６８】
図５Ａの状態で、フロントパネル３００のＯＫボタン３０５が押下されると、番組表示部４０２ａは、「チャンネル１」の識別子を再生部４０２ｂに通知する。図５Ｂの状態で、フロントパネル３００のＯＫボタン３０５が押下されると、番組表示部４０２ａは、「チャンネル２」の識別子を再生部４０２ｂに通知する。
【０４６９】
また、番組表示部４０２ａは、表示する番組情報を、多重分離手段２０５を通して定期的に、第２メモリ２０３に記憶しておく。一般的に、放送局からの番組情報の取得は時間が掛かる。入力部２０１のＥＰＧボタン３０７が押下された時、第２メモリ２０３に予め保存された番組情報を表示することで、素早く番組表を表示することができる。
【０４７０】
図６は、第２メモリ２０３に記憶している番組情報の一例である。番組情報は表形式で格納されている。列６０１は、チャンネルの識別子である。列６０２は、番組名である。列６０３は番組の放送開始時間、列６０４は放送終了時間である。列６０５は、番組の音声種別を表しており、モノラル音声、ステレオ音声、５．１チャンネル音声をそれぞれ「モノラル」、「ステレオ」、「５．１」と表記している。列６０６は、番組の種別を表している。通常番組は空欄であり、「映画」は映画、「スポ」はスポーツ番組を表す。行６１１〜６１４の各行は、それぞれひとつの番組情報を表す。この例では、ひとつの番組情報は、チャンネルの識別子、番組名、放送開始時間、放送終了時間、番組の音声種別の組となる。例えば、行６１１はチャンネル識別子が「１」、番組名が「ニュース９」、放送開始時間が「９：００」、放送終了時間が「１０：３０」、音声種別が「モノラル」、番組の種別は「通常」を含む組となっている。
【０４７１】
再生部４０２ｂは、受け取ったチャンネルの識別子を用いて、チャンネルを再生する。すなわちチャンネルを構成する映像と音声を再生する。チャンネルの識別子とチャンネルの関係は、チャンネル情報として、第２メモリ２０３に予め格納されている。図７は第２メモリ２０３に格納されているチャンネル情報の一例である。チャンネル情報は表形式で格納されている。列７０１は、チャンネルの識別子である。列７０２は、チャンネル名である。列７０３はチューニング情報である。ここで、チューニング情報は周波数や転送レート、符号化率などを含み、受信部２０４に与える値である。列７０４はプログラムナンバーである。プログラムナンバーとは、ＭＰＥＧ２規格で規定されているＰＭＴを識別するための番号である。ＰＭＴに関しては、後述する。行７１１〜７１４の各行は、各チャンネルの識別子、チャンネル名、チューニング情報の組となる。行７１１は識別子が「１」、チャンネル名が「チャンネル１」、チューニング情報に周波数「１５０ＭＨｚ」、プログラムナンバーが「１０１」を含む組となっている。再生部４０２ｂは、チャンネルの再生を行うため、受け取ったチャンネルの識別子をそのままサービスマネージャ４０４に引き渡す。
【０４７２】
また、再生部４０２ｂは、再生中に、ユーザがフロントパネル３００の上カーソル３０１と下カーソル３０２を押下すると、入力部２０１からＣＰＵ２１２を通して、押下された通知を受け取り、再生しているチャンネルを変更する。上カーソル３０１を押下すると、現在再生中のチャンネルよりもひとつ小さいチャンネル識別子を持つチャンネルを再生し、また下カーソル３０２を押下すると、現在再生中のチャンネルよりもひとつ大きいチャンネル識別子を持つチャンネルを再生する。まず、再生部４０２ｂは、第２メモリ２０３に現在再生中のチャンネルの識別子を記憶する。図８Ａ、図８Ｂ及び図８Ｃは、第２メモリ２０３に保存しているチャンネルの識別子の例である。図８Ａでは識別子「３」が記憶されており、図７を参照し、チャンネル名「ＴＶ  ３」のチャンネルが再生中であることを示す。図８Ａの状態で、ユーザが上カーソル３０１を押下すると再生部４０２ｂは、図７のチャンネル情報を参照し、表中で現在再生中のチャンネルよりもひとつ小さい識別子を持つチャンネルであるチャンネル名「チャンネル２」のチャンネルに再生を切り変えるため、サービスマネージャ４０４にチャンネル名「チャンネル２」の識別子「２」を引き渡す。同時に、第２メモリ２０３に記憶されているチャンネル識別子「２」に書き換える。図８Ｂは、チャンネル識別子が書き換えられた状態を表す。また、図８Ａの状態で、ユーザが下カーソル３０２を押下すると再生部４０２ｂは、図７のチャンネル情報を参照し、表中で現在再生中のチャンネルよりもひとつ大きい識別子を持つチャンネルであるチャンネル名「ＴＶ  Ｊａｐａｎ」のチャンネルに再生を切り変えるため、サービスマネージャ４０４にチャンネル名「ＴＶ  Ｊａｐａｎ」の識別子「４」を引き渡す。同時に、第２メモリ２０３に記憶されているチャンネル識別子「４」に書き換える。図８Ｃは、チャンネル識別子が書き換えられた状態を表す。チャンネル識別子は、第２メモリ２０３に記憶されているので、マルチメディアデータ送信装置１０１の電源が切られた際も保存されている。
【０４７３】
さらに再生部４０２ｂは、マルチメディアデータ送信装置１０１の電源が投入された際に、起動されると、第２メモリ２０３に記憶されているチャンネル識別子を読み出す。そして、そのチャンネル識別子をサービスマネージャに引き渡す。これにより、マルチメディアデータ送信装置１０１は、電源投入時に前回の稼動時に再生されていた最後のチャンネルの再生を開始することができる。
【０４７４】
ＪａｖａＶＭ４０３は、Ｊａｖａ（登録商標）言語で記述されたプログラムを逐次解析し実行するＪａｖａバーチャルマシンである。Ｊａｖａ言語で記述されたプログラムはバイトコードと呼ばれる、ハードウェアに依存しない中間コードにコンパイルされる。Ｊａｖａバーチャルマシンは、このバイトコードを実行するインタープリタである。また、一部のＪａｖａバーチャルマシンは、バイトコードをＣＰＵ２１２が理解可能な実行形式に翻訳してから、ＣＰＵ２１２に引渡し、実行することも行う。ＪａｖａＶＭ４０３は、カーネル４０１ａに実行するＪａｖａプログラムを指定され起動される。本実施の形態では、カーネル４０１ａは、実行するＪａｖａプログラムとしてサービスマネージャ４０４を指定する。Ｊａｖａ言語の詳細は、書籍「Ｊａｖａ  Ｌａｎｇｕａｇｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ  ０−２０１−６３４５１−１）」等の多くの書籍で解説されている。ここでは、その詳細を省略する。また、ＪａｖａＶＭ自体の詳細な動作などは、「Ｊａｖａ  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＩＳＢＮ  ０−２０１−６３４５１―Ｘ）」等の多くの書籍で解説されている。ここでは、その詳細を省略する。
【０４７５】
サービスマネージャ４０４は、Ｊａｖａ言語で書かれたＪａｖａプログラムであり、ＪａｖａＶＭ４０３によって逐次実行される。サービスマネージャ４０４は、ＪＮＩ（Ｊａｖａ  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅ）を通して、Ｊａｖａ言語で記述されていない他のサブプログラムを呼び出したり、または、呼び出されたりすることが可能である。ＪＮＩに関しても、書籍「Ｊａｖａ  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅ」等の多くの書籍で解説されている。ここでは、その詳細を省略する。
【０４７６】
まず、デジタル放送を受信し、受信したマルチメディアデータを再生する場合の処理について説明する。
【０４７７】
サービスマネージャ４０４は、ＪＮＩを通して、再生部４０２ｂよりチャンネルの識別子を受け取る。
【０４７８】
サービスマネージャ４０４は、最初にＪａｖａライブラリ４０５の中にあるＴｕｎｅｒ４０５ｃに、チャンネルの識別子を引き渡し、チューニングを依頼する。Ｔｕｎｅｒ４０５ｃは、第２メモリ２０３が記憶するチャンネル情報を参照し、チューニング情報を獲得する。今、サービスマネージャ４０４がチャンネルの識別子「２」をＴｕｎｅｒ４０５ｃに引き渡すと、Ｔｕｎｅｒ４０５ｃは、図７の行７１２を参照して、対応するチューニング情報「１５６ＭＨｚ」を獲得する。Ｔｕｎｅｒ４０５ｃは、ＯＳ４０１のライブラリ４０１ｂのチューナ４０１ｂ１を通して、受信部２０４にチューニング情報を引き渡す。受信部２０４は与えられたチューニング情報に従って放送局から送信されてきた信号を復調し、多重分離手段２０５に引き渡す。
【０４７９】
次にサービスマネージャ４０４は、Ｊａｖａライブラリ４０５の中にあるＣＡ４０５ｄにデスクランブルを依頼する。ＣＡ４０５ｄは、ＯＳ４０１のライブラリ４０１ｂの限定解除４０１ｂ２を通して復号に必要な情報をデスクランブラ２０６に与える。デスクランブラ２０６は、与えられた情報を元に、受信部２０４から与えられた信号を復号しＴＳデコーダ２０７に引き渡す。
【０４８０】
サービスマネージャ４０４は、Ｊａｖａライブラリ４０５の中にあるＪＭＦ４０５ａにチャンネルの識別子を与え、映像・音声の再生を依頼する。
【０４８１】
まず、最初にＪＭＦ４０５ａは、再生すべき映像と音声を特定するためのパケットＩＤをＰＡＴ、ＰＭＴから取得する。ＰＡＴやＰＭＴはＭＰＥＧ２規格で規定されている、ＭＰＥＧ２トランスポートストリーム内の番組構成を表現するテーブルであり、ＭＰＥＧ２トランスポートストリームに含まれるパケットのペイロードに埋め込まれて、音声や映像と共に送信されるものである。詳細は規格書を参照されたい。ここでは、概略のみ説明する。ＰＡＴは、Ｐｒｏｇｒａｍ  Ａｓｓｏｃｉａｔｉｏｎ  Ｔａｂｌｅの略で、パケットＩＤ「０」のパケットに格納され送信されている。ＪＭＦ４０５ａは、ＰＡＴを取得するため、ＯＳ４０１のライブラリ４０１ｂを通して、多重分離手段２０５にパケットＩＤ「０」を指定する。多重分離手段２０５がパケットＩＤ「０」でフィルタリングを行い、ＣＰＵ２１２に引き渡すことでＪＭＦ４０５ａは、ＰＡＴのパケットを収集する。図９は、収集したＰＡＴの情報の一例を模式的に表した表である。列９０１は、プログラムナンバーである。列９０２は、パケットＩＤである。列９０２のパケットＩＤはＰＭＴを取得するために用いられる。行９１１〜９１３は、チャンネルのプログラムナンバーと対応するパケットＩＤの組である。ここでは、三つのチャンネルが定義されている。行９１１はプログラムナンバー「１０１」とパケットＩＤ「５０１」の組が定義されている。今、ＪＭＦ４０５ａに与えられたチャンネルの識別子が「２」とすると、ＪＭＦ４０５ａは、図９の行９１２を参照して、対応するプログラムナンバー「１０２」を獲得し、次に、図９のＰＡＴの行９１２を参照し、プログラムナンバー「１０２」に対応するパケットＩＤ「５０２」を獲得する。ＰＭＴは、Ｐｒｏｇｒａｍ  Ｍａｐ  Ｔａｂｌｅの略で、ＰＡＴで規定されたパケットＩＤのパケットに格納され送信されている。ＪＭＦ４０５ａは、ＰＭＴを取得するため、ＯＳ４０１のライブラリ４０１ｂを通して、多重分離手段２０５にパケットＩＤを指定する。ここで、指定するパケットＩＤは「５０２」とする。多重分離手段２０５がパケットＩＤ「５０２」でフィルタリングを行い、ＣＰＵ２１２に引き渡すことでＪＭＦ４０５ａは、ＰＭＴのパケットを収集する。図１０は、収集したＰＭＴの情報の一例を模式的に表した表である。列１００１は、ストリーム種別であり。列１００２は、パケットＩＤである。列１００２で指定されるパケットＩＤのパケットには、ストリーム種別で指定された情報がペイロードに格納され送信されている。列１００３は補足情報である。行１０１１〜１０１４はエレメンタリ−ストリームと呼ばれる、パケットＩＤと送信している情報の種別の組である。行１０１１は、ストリーム種別「音声」とパケットＩＤ「５０１１」の組であり、パケットＩＤ「５０１１」のペイロードには音声が格納されていることを表す。ＪＭＦ４０５ａは、ＰＭＴから再生する映像と音声のパケットＩＤを獲得する。図１０を参照して、ＪＭＦ４０５ａは、行１０１１から音声のパケットＩＤ「５０１１」を、行１０１２から映像のパケットＩＤ「５０１２」を獲得する。
【０４８２】
次に、ＪＭＦ４０５ａは、ＯＳ４０１のライブラリ４０１ｂのＡＶ再生４０１ｂ３に獲得した音声のパケットＩＤと映像のパケットＩＤを引き渡す。これを受けて、ＡＶ再生４０１ｂ３は、受け取った音声のパケットＩＤと映像のパケットＩＤを、ＴＳデコーダ２０７に与える。ＴＳデコーダ２０７は与えられたパケットＩＤでフィルタリングを行う。ここではパケットＩＤ「５０１１」のパケットを音声出力部２０９に、パケットＩＤ「５０１２」のパケットを映像出力部２０８に、それぞれ引き渡す。音声出力部２０９は、与えられたパケットを適宜変換し（例えばデジタル−アナログ変換）出力する。映像出力部２０８は、与えられたパケットを適宜変換し（例えばデジタル−アナログ変換）出力する。
【０４８３】
最後にサービスマネージャ４０４は、Ｊａｖａライブラリ４０５の中にあるＡＭ４０５ｂにチャンネルの識別子を与え、データ放送再生を依頼する。ここで、データ放送再生とは、ＭＰＥＧ２トランスポートストリームに含まれるＪａｖａプログラムを抽出し、ＪａｖａＶＭ４０３に実行させることである。ＭＰＥＧ２トランスポートストリームにＪａｖａプログラムを埋め込む方法は、ＭＰＥＧ規格書  ＩＳＯ／ＩＥＣ１３８１８−６に記述されたＤＳＭＣＣという方式を用いる。ここではＤＳＭＣＣの詳細な説明は省略する。ＤＳＭＣＣ方式は、ＭＰＥＧ２トランスポートストリームのパケットの中に、コンピュータで使用されているディレクトリやファイルで構成されるファイルシステムをエンコードする方法を規定している。ここでは、Ｊａｖａライブラリ４０５の中のＤＳＭＣＣ４０５ｌが取得するデータは、ファイル構造をもつデータ構造でエンコードを行うＯｂｊｅｃｔＣａｒｏｕｓｅｌ方式でエンコードされているものとする。また、実行するＪａｖａプログラムの情報はＡＩＴと呼ばれる形式で、ＭＰＥＧ２トランスポートストリームのパケットの中に埋め込まれ送信されている。ＡＩＴは、ＤＶＢ−ＭＨＰ規格（正式には、ＥＴＳＩ  ＴＳ  １０１  ８１２  ＤＶＢ−ＭＨＰ仕様Ｖ１．０．２）の１０章に定義されている、Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅの略である。
【０４８４】
ＡＭ４０５ｂは、まず、ＡＩＴを獲得するため、ＪＭＦ４０５ａ同様ＰＡＴ、ＰＭＴを取得し、ＡＩＴが格納されているパケットのパケットＩＤを獲得する。今、与えられたチャンネルの識別子が「２」で、図９のＰＡＴ、図１０のＰＭＴが送信されていると、ＪＭＦ４０５ａと同様の手順で、図１０のＰＭＴを獲得する。ＡＭ４０５ｂは、ＰＭＴからストリーム種別が「データ」で補足情報として「ＡＩＴ」を持つエレメンタリ−ストリームからパケットＩＤを抽出する。図１０を参照して、行１０１３のエレメンタリ−ストリームが該当し、パケットＩＤ「５０１３」を獲得する。
【０４８５】
ＡＭ４０５ｂは、ＯＳ４０１のライブラリ４０１ｂを通して多重分離手段２０５にＡＩＴのパケットＩＤを与える。多重分離手段２０５は、与えられたパケットＩＤでフィルタリングを行い、ＣＰＵ２１２に引き渡す。この結果、ＡＭ４０５ｂは、ＡＩＴのパケットを収集することができる。図１１は、収集したＡＩＴの情報の一例を模式的に表した表である。列１１０１はＪａｖａプログラムの識別子である。列１１０２はＪａｖａプログラムの制御情報である。制御情報には「ａｕｔｏｓｔａｒｔ」、「ｐｒｅｓｅｎｔ」、「ｋｉｌｌ」などがあり、「ａｕｔｏｓｔａｒｔ」は即時にマルチメディアデータ送信装置１０１がこのプログラムを自動的に実行することを意味し、「ｐｒｅｓｅｎｔ」は自動実行しないことを意味し、「ｋｉｌｌ」はプログラムを停止することを意味する。列１１０３は、ＤＳＭＣＣ方式でＪａｖａプログラムを含んでいるパケットＩＤを抽出するためのＤＳＭＣＣ識別子である。列１１０４はＪａｖａプログラムのプログラム名である。行１１１１と１１１２は、Ｊａｖａプログラムの情報の組である。行１１１１で定義されるＪａｖａプログラムは、識別子「３０１」、制御情報「ａｕｔｏｓｔａｒｔ」、ＤＳＭＣＣ識別子「１」、プログラム名「ａ／ＴｏｐＸｌｅｔ」の組である。行１１１２で定義されるＪａｖａプログラムは、識別子「３０２」、制御情報「ｐｒｅｓｅｎｔ」、ＤＳＭＣＣ識別子「１」、プログラム名「ｂ／ＧａｍｅＸｌｅｔ」の組である。ここでふたつのＪａｖａプログラムは同じＤＳＭＣＣ識別子を持つが、これはひとつのＤＳＭＣＣ方式でエンコードされたファイルシステム内にふたつのＪａｖａプログラムが含まれていることを表す。ここでは、Ｊａｖａプログラムに対して四つの情報しか規定しないが、実際にはより多くの情報が定義される。詳細はＤＶＢ−ＭＨＰ規格を参照されたい。
【０４８６】
ＡＭ４０５ｂは、ＡＩＴの中から「ａｕｔｏｓｔａｒｔ」のＪａｖａプログラムを見つけ出し、対応するＤＳＭＣＣ識別子及びＪａｖａプログラム名を抽出する。図１１を参照して、ＡＭ４０５ｂは行１１１１のＪａｖａプログラムを抽出し、ＤＳＭＣＣ識別子「１」及びＪａｖａプログラム名「ａ／ＴｏｐＸｌｅｔ」を獲得する。
【０４８７】
次にＡＭ４０５ｂは、ＡＩＴから取得したＤＳＭＣＣ識別子を用いて、ＪａｖａプログラムをＤＳＭＣＣ方式で格納しているパケットのパケットＩＤをＰＭＴから獲得する。具体的には、ＰＭＴの中でストリーム種別が「データ」で、補足情報のＤＳＭＣＣ識別子が合致するエレメンタリ−ストリームのパケットＩＤを取得する。
【０４８８】
今、ＤＳＭＣＣ識別子が「１」であり、ＰＭＴが図１０とすると、行１０１４のエレメンタリ−ストリームが合致し、パケットＩＤ「５０１４」を取り出す。
【０４８９】
ＡＭ４０５ｂは、ＯＳ４０１のライブラリ４０１ｂを通して多重分離手段２０５にＤＳＭＣＣ方式でデータが埋めこめられたパケットのパケットＩＤを指定する。ここでは、パケットＩＤ「５０１４」を与える。多重分離手段２０５は、与えられたパケットＩＤでフィルタリングを行い、ＣＰＵ２１２に引き渡す。この結果、ＡＭ４０５ｂは、必要なパケットを収集することができる。ＡＭ４０５ｂは、収集したパケットから、ＤＳＭＣＣ方式に従ってファイルシステムを復元し、第１メモリ２０２あるいは第２メモリ２０３に保存する。ファイルシステム等のデータを取り出し第１メモリ２０２あるいは第２メモリ２０３に保存することを以降、ダウンロードと呼ぶ。
【０４９０】
図１２は、ダウンロードしたファイルシステムの一例である。図中、丸はディレクトリを四角はファイルを表し、１２０１はルートディレクトリ、１２０２はディレクトリ「ａ」、１２０３はディレクトリ「ｂ」、１２０４はファイル「ＴｏｐＸｌｅｔ．ｃｌａｓｓ」、１２０５はファイル「ＧａｍｅＸｌｅｔ．ｃｌａｓｓ」である。
【０４９１】
ここでは、ＭＰＥＧ２トランスポートストリームからファイルシステムをダウンロードする例を記載したが、ＯＣＡＰ仕様では、ＩＰネットワークを用いたダウンロードなども規定している。また、ＡＩＴではなくＸＡＩＴと呼ばれる情報を用いてファイルシステムの存在位置を特定し、ファイルシステムをダウンロードする方法も規定されている。
【０４９２】
次にＡＭ４０５ｂは、第１メモリ２０２あるいは第２メモリ２０３にダウンロードしたファイルシステム中から実行するＪａｖａプログラムをＪａｖａＶＭ４０３に引き渡す。今、実行するＪａｖａプログラム名が「ａ／ＴｏｐＸｌｅｔ」とすると、Ｊａｖａプログラム名の最後に「．ｃｌａｓｓ」を付加したファイル「ａ／ＴｏｐＸｌｅｔ．ｃｌａｓｓ」が実行すべきファイルとなる。「／」はディレクトリやファイル名の区切りであり、図１２を参照して、ファイル１２０４が実行すべきＪａｖａプログラムである。次にＡＭ４０５ｂは、ファイル１２０４をＪａｖａＶＭ４０３に引き渡す。
【０４９３】
ＪａｖａＶＭ４０３は、引き渡されたＪａｖａプログラムを実行する。
【０４９４】
サービスマネージャ４０４は、他のチャンネルの識別子を受け取ると、Ｊａｖａライブラリ４０５に含まれる各ライブラリを通して再生している映像・音声及びＪａｖａプログラムの実行を、同じくＪａｖａライブラリ４０５に含まれる各ライブラリを通して停止し、新たに受け取ったチャンネルの識別子に基づいて、映像・音声の再生及びＪａｖａプログラムの実行を行う。
【０４９５】
また、サービスマネージャ４０４は、再生部４０２ｂだけでなく、ＪａｖａＶＭ４０３上で実行されるＪａｖａプログラムからチャンネルの識別子を受け取る機能も備える。具体的には、チャンネルの識別子を受け取るためのＪａｖａ言語のクラス及びそのメソッドを提供する。チャンネルの識別子を受け取ると、サービスマネージャ４０４は、Ｊａｖａライブラリ４０５に含まれる各ライブラリを通して現在再生している映像・音声及びＪａｖａプログラムの実行を、同じくＪａｖａライブラリ４０５に含まれる各ライブラリを通して停止し、その後、新たに受け取ったチャンネルの識別子に基づいて、新しい映像・音声の再生及びＪａｖａプログラムの実行を行う。
【０４９６】
次に、マルチメディアデータ送信装置１０１において、デジタル放送を受信して、そのマルチメディアデータを第２メモリ２０３に蓄積する処理について説明する。
【０４９７】
図４６は、マルチメディアデータ送信装置１０１が、第２メモリ２０３にマルチメディアデータを蓄積する形態の一例である。マルチメディアデータ送信装置１０１は、マルチメディアデータとその属性情報、属性情報テーブル、ＵＲＩテーブルを第２メモリ２０３に記憶する。図４６において、１３０１、１３０２、・・・はマルチメディアデータを、１３１１、１３１２、・・・はマルチメディアデータの属性情報を、１３２１は属性情報テーブルを、１３３１はＵＲＩテーブルを、それぞれ表す。マルチメディアデータ１３０１、１３０２、・・・は、ＭＰＥＧ２−ＴＳ形式で符号化され、暗号化されたマルチメディアデータである。属性情報１３１１、１３１２、・・・は、各マルチメディアデータのタイトルなどの付加的な情報である。ここでは、属性情報１３１１はマルチメディアデータ１３０１の属性情報を、属性情報１３１２はマルチメディアデータ１３０２の属性情報を、それぞれ表すこととする。
【０４９８】
図４７は、本実施の形態における属性情報の一例を表す。本実施の形態においては、属性情報はＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）で定義されたテキストで表すものとする。図４７では、ＣｏｎｔｅｎｔＩＤ要素で該コンテンツの識別子を、ＦｉｌｅＮａｍｅ要素で該マルチメディアデータのファイル名を、ＦｉｌｅＴｒｅｅ要素で該マルチメディアデータに含まれるＯｂｊｅｃｔＣａｒｏｕｓｅｌで伝送されるディレクトリやファイルで構成されるファイルシステムを保存したディレクトリ名を、ＣｈａｎｎｅｌＩＤ要素で図６の列６０１で示されているような該番組が放送されたチャンネルの識別子を、ＰｒｏｇｒａｍＮｏ要素で図７の列７０４に示されているようなＰＭＴを検索するプログラムナンバーを、Ｔｉｔｌｅ要素で図６の列６０２で示されているような番組名を、Ｇｅｎｒｅ要素で図６の列６０６に示されているような番組の種別を、Ｄａｔｅ要素で該番組が放送された日時を、ＲｅｃｏｒｄＤａｔｅ要素で該番組が録画された日時を、ＰｌａｙｂａｃｋＴｉｍｅ要素で、該マルチメディアデータが再生もしくはネットワーク１０３に出力された回数を、ＦｏｒｍａｔＴｙｐｅ要素で該コンテンツのメディアフォーマットの種類を、ＣｏｎｔｅｎｔＴｙｐｅ要素でＩＡＮＡ（Ｉｎｔｅｒｎｅｔ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓ  Ａｕｔｈｏｒｉｔｙ）から該コンテンツのメディアフォーマットに割り当てられたＣｏｎｔｅｎｔ−Ｔｙｐｅを、それぞれ表す。なお、属性情報は、このようなＸＭＬによる構成に限るものではなく、他の形式、例えば、バイナリデータとして記録しても良い。
【０４９９】
属性情報テーブルは、コンテンツの識別子と、該識別子で表されるコンテンツのマルチメディアデータを記録したファイル、および、属性情報を記録したファイルとの対応表である。図４８にその一例を示す。図４８において、列１５０１はコンテンツの識別子を表し、列１５０２は属性情報のファイル名を表す。行１５１１〜１５１３は、コンテンツの識別子と対応する属性情報のファイル名の組である。行１５１１からは、識別子１のコンテンツの属性情報はファイル０００１．ａｔｔｒに記録されていることを読み取ることができる。
【０５００】
図４９に、ＵＲＩテーブル１３３１の構成の一例を示す。図４９において、列１６０１は各コンテンツの識別子を示し、列１６０２は各コンテンツにアクセスするためのＵＲＩを表す。列１６０３は、ＡＩＴやＰＭＴなどのセクションデータの変化点情報を保持するデータへアクセスするためのＵＲＩを表す。各行１６１１〜１６１３は、コンテンツの識別子とＵＲＩの組が表されている。例えば、行１６１１は、識別子１のコンテンツのＵＲＩは、ｈｔｔｐ：／／１９２．１６８．０．３／ＡＶＤａｔａ／０００１．ｍ２ｔｓで、ＡＩＴセクションの変化点情報を保持するファイルのＵＲＩは、ｈｔｔｐ：／／１９２．１６８．０．３／ＶＵＰ／０００１−ａｉｔ．ｖｕｐあることを表している。
【０５０１】
以下、蓄積する処理について説明する。まず、デスクランブルまでの動作は、上記再生する場合と同様である。続いて、サービスマネージャ４０４は、ＣＡ４０５ｄに該マルチメディアデータに関する保護要否と、必要な場合にはどのような保護であるかの情報の取得を依頼する。この情報を保護情報と呼ぶこととする。ＣＡ４０５ｄは、デスクランブラ２０６から該マルチメディアデータの保護情報を受け取り、それをサービスマネージャ４０４に引き渡す。次に、サービスマネージャ４０４は、引き渡された保護情報から、該マルチメディアデータが蓄積可能であるかどうかを判定する。蓄積可能である場合に限り、サービスマネージャ４０４は、Ｊａｖａライブラリ４０５の中のＲｅｃ４０５ｊに該マルチメディアデータの蓄積及び該マルチメディアデータ内の変化点の記録を依頼する。
【０５０２】
ここで図５０に、図４５のプログラムの構成図で示したＲｅｃ４０５ｊの内部構成の一例をあらわすブロック図を示す。
【０５０３】
要求受信部１７０１ａは、サービスマネージャ４０４より受信した該マルチメディアデータの蓄積及びマルチメディアデータ内の変化点の記録要求を受信し、制御部１７０１ｂへ要求内容を伝える。
【０５０４】
制御部１７０１ｂは、要求された該マルチメディアデータのサービス及びパケットＩＤを取得するため、上記ＪＭＦ４０５ａおよびＡＭ４０５ｂと同様に、ＰＡＴ、ＰＭＴを取得し、蓄積する番組に関する映像データ、音声データ、各セクションデータのパケットＩＤを取得する。今、与えられたチャンネルの識別子が「２」で、図９のＰＡＴ、図１０のＰＭＴが送信されていると、ＪＭＦ４０５ａと同様の手順で、図１０のＰＭＴを獲得する。なお、ここで蓄積するデータは、図１０のＰＭＴに記述された全てのデータである。
【０５０５】
次に制御部１７０１ｂは、ＯＳ４０１のライブラリ４０１ｂを通してＴＳデコーダ２０７に、これらのパケットＩＤを与え、ＴＳマルチプレクサ２１０に出力させる。ＴＳデコーダ２０７は、与えられたパケットＩＤでフィルタリングを行い、ＴＳマルチプレクサ２１０に引き渡す。このとき制御部１７０１ｂは、変化を求めたいセクションを特定するパケットＩＤを、変化点検出部１７０２ａへ通知する。
【０５０６】
変化点検出部１７０２ａは、指定されたセクションに関して、受信したセクションと前回取得した受信セクションと比較し、セクションのバージョンアップが発生しているか否か判断する。このときセクションのバージョンフィールドを確認し、バージョンが変更していた場合は、本セクションが伝送するセクションの内容を保存するため、本セクションを変化点保存部１７０２ｂへわたす。
【０５０７】
変化点保存部１７０２ｂは、変化点検出部１７０２ａによって検出された変化点に対し、バージョンアップ発生のタイミング及びそのときのセクションデータを、ＩＯ４０５ｇに依頼して第２メモリ２０３へ書き込む。以下、この情報を変化点情報と呼ぶこととし、その一例を図５１に示す。図５１において、列１８０１は、セクションの種類を示す。これは、例えばａｉｔやｐｍｔなどである。列１８０２は、バージョンナンバーを示す。列１８０３は、バージョンが変化した時間情報である。この時間情報は、該マルチメディアコンテンツの開始からの経過時間で表現することとする。列１８０４は、バージョンが変化したセクションを伝送する、ストリーム中の開始位置を示し、列１８０５は、バージョンが変化したセクションを伝送する、ストリーム中の終了位置を示す。なお、列１８０４及び列１８０５は該マルチメディアコンテンツの先頭を０としたときのバイト位置で指定する。列１８０６はバイナリのセクション長をバイト数で示し、列１８０７はセクションのバイナリデータを示す。なお、図５１で示した変化点情報は、この形式に限らず、変化点を表す情報と、変化の内容を表す情報が含まれていれば、他の形式であっても良い。
【０５０８】
変化点保存部１７０２ｂが変化点情報を書き込んだあと、制御部１７０２ａは、第２メモリ２０３上の図５１の保存場所を参照するＵＲＩを生成する。なお、図５１では、ａｉｔがバージョンアップした図を示したが、ｐｍｔのバージョンアップでも、ａｉｔとｐｍｔのような異なるセクションを同一のテーブルに書く方式でもよい。また、ここではマルチメディアコンテンツの記録時に、ストリームの変化点情報をまとめて記録する方法を示したが、これはマルチメディアデータ受信装置１０２からストリーム変化点情報の要求があったタイミングに、保存されているＭＰＥＧトランスポートストリームから作成する構成であってもよい。
【０５０９】
また、制御部１７０１ｂは、受信したＰＭＴに含まれるＥｌｅｍｅｎｔａｒｙＳｔｒｅａｍ（以下ＥＳ）のＳｔｒｅａｍＴｙｐｅの参照時、ＳｔｒｅａｍＴｙｐｅ＝０ｘ０ｂのＯｂｊｅｃｔＣａｒｏｕｓｅｌが含まれているか確認する。そして、該マルチメディアデータにＯｂｊｅｃｔＣａｒｏｕｓｅｌが含まれている場合は、カルーセル取得部１７０２ｃへカルーセル取得を要求する。
【０５１０】
カルーセル取得部１７０２ｃは、Ｊａｖａライブラリ４０５のＤＳＭＣＣ４０５ｌを用いて、該マルチメディアデータで伝送される全てのＯｂｊｅｃｔＣａｒｏｕｓｅｌをダウンロードし、Ｃａｒｏｕｓｅｌ毎に図１２に示したようなファイル構造を構築する。このファイル構造を、以下ＦｉｌｅＴｒｅｅと呼ぶ。取得したＦｉｌｅＴｒｅｅを保存するため、ＦｉｌｅＴｒｅｅ保存部１７０２ｄを呼ぶ。
【０５１１】
ＦｉｌｅＴｒｅｅ保存部１７０２ｄは、ＩＯ４０５ｇに依頼して、第２メモリ２０３へＦｉｌｅＴｒｅｅを保存する。このとき、ＦｉｌｅＴｒｅｅ保存部１７０２ｄは、保存したディレクトリを、図４７のＦｉｌｅＴｒｅｅ要素へ記録する。
【０５１２】
なお、ここではマルチメディアコンテンツの記録時に、オブジェクトカルーセルを記録する方法を示したが、これはマルチメディアデータ受信装置１０２からファイル取得要求があったタイミングに、第２メモリ２０３へ保存済みのＭＰＥＧトランスポートストリームから新たに作成するという構成であってもよい。
【０５１３】
なお、ここでは、セクションのバージョンアップを検知する変化点検出部１７０２ｂは、Ｒｅｃ４０５ｊの構成要素として実現したが、本機能は、ＳＩ４０５ｉに含まれていても良く、また、ＴＳデコーダ２０７の機能であっても良い。
【０５１４】
制御部１７０１ｂは、ＴＳデコーダ２０７でフィルタリングされたデータ、および、そのデータの種類をＴＳマルチプレクサ２１０に与えることにより、ＴＳマルチプレクサ２１０にＭＰＥＧ２トランスポートストリームを構成させる。
【０５１５】
さらに、制御部１７０１ｂは、Ｊａｖａライブラリ４０５の中のＩＯ４０５ｇに依頼して、ＴＳマルチプレクサ２１０が構成したＭＰＥＧトランスポートストリームを第２メモリ２０３に書き込む。
【０５１６】
さらに、制御部１７０１ｂは、サービスマネージャ４０４に依頼して、該番組のチャンネル識別子を受け取り、ＩＯ４０５ｇに依頼して、第２メモリ２０３に記憶された図６に示す番組情報のうち、蓄積したマルチメディアデータに対応するものの番組情報を読み取る。
【０５１７】
さらに、制御部１７０１ｂは、サービスマネージャ４０４に依頼して該蓄積したマルチメディアデータの識別子を取得する。
【０５１８】
さらに、取得した番組情報と、該マルチメディアデータの識別子と、マルチメディアデータを蓄積したファイル名と、上記変化点情報のＵＲＩから属性情報を作り、ＩＯ４０５ｇに依頼して、該属性情報を第２メモリ２０３に書き込む。
【０５１９】
さらに、制御部１７０１ｂは、ＩＯ４０５ｇに依頼して、属性情報テーブルを読み出し、内容を更新して、ＩＯ４０５ｇに依頼して第２メモリ２０３に書き込むことにより、属性情報テーブルを更新する。
【０５２０】
次に、第２メモリ２０３に蓄積したマルチメディアデータのうち、ネットワーク１０３に接続された端末からの要求されたものを、該要求元端末へ送信する処理について説明する。
【０５２１】
ここで図５０右部に、図４５のプログラムの構成図で示したネットワークライブラリ４０５ｅの内部構成の一例をあらわすブロック図を示す。
【０５２２】
以下、図４９に示したＵＲＩテーブル１３３１で、次のようなリクエストメッセージを受信した場合を例に説明する。
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
X-Version-Request: type = ait ; scope = all
X-Tree-Base-Request : carousel_id = 1
【０５２３】
要求受信部１７０３ａは、要求元端末から送信されてきたリクエストメッセージを解析し、その内容を制御部１７０３ｂに引き渡すものである。上記のリクエストメッセージを受信した場合は、該リクエストメッセージから、少なくとも要求されたコンテンツのＵＲＩと、Ｘ−Ｖｅｒｓｉｏｎ−ＲｅｑｕｅｓｔおよびＸ−Ｔｒｅｅ−Ｂａｓｅ−Ｒｅｑｕｅｓｔの内容を取得して、制御部１７０３ｂへ引き渡す。
【０５２４】
制御部１７０３ｂは、要求受信部１７０３ａから引き渡された情報に従い、ネットワークライブラリ４０５ｅの他の構成要素を制御して、レスポンスメッセージを生成し、該要求元端末へ送信するものである。制御部１７０３ｂは、まず、要求受信部１７０３ａが受信したリクエストメッセージが不正なものであれば、Ｈｅａｄｅｒ生成部１７０３ｅに依頼して、対応するＨＴＴＰのエラーメッセージを生成させ、それを情報送信部１７０３ｆに引き渡して、該要求元端末へ送信し、処理を終了する。受信したリクエストメッセージが正しいものであれば、制御部１７０３ｂは、ＩＯ４０５ｇに依頼してＵＲＩテーブル１３３１を読み出す。読み出したＵＲＩテーブル１３３１と、要求受信部１７０３ａが取得したＵＲＩから、要求されているコンテンツの識別子を得る。上記の例の場合、コンテンツの識別子は１であることがわかる。また、該要求されたコンテンツに含まれるストリームの変化点情報のＵＲＩ  ｈｔｔｐ：／／１９２．１６８．０．３／ＶＵＰ／０００１−ａｉｔ．ｖｕｐも取得することができる。
【０５２５】
続いて、制御部１７０３ｂは、要求受信部１７０３ａから引き渡された情報の中に、ストリームの変化点情報の送信要求があるか否かを調べる。ストリームの変化点情報の送信要求がある場合には、以下の処理を行う。まず、制御部１７０３ｂは、変化点情報取得部１７０３ｃに、ＵＲＩテーブル１３３１より取得したストリームの変化点情報のＵＲＩと、要求受信部１７０３ａから引き渡されたストリームの変化点情報の送信要求の内容を引き渡す。
【０５２６】
変化点情報取得部１７０３ｃは、引き渡された変化点情報のURI ｈｔｔｐ：／／１９２．１６８．０．３／ＶＵＰ／０００１−ａｉｔ．ｖｕｐから、それが保存されているファイルを特定する。そして、該ファイルへアクセスし、該ファイルの有無を確かめる。該ファイルが存在しない場合は、Ｈｅａｄｅｒ生成部１７０３ｅに変化点情報が存在しないことを通知して処理を終了する。該ファイルが存在する場合には、そのＵＲＩと、リクエストメッセージに含まれていた拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔの値である、ｔｙｐｅ及びｓｃｏｐｅ情報とをＨｅａｄｅｒ生成部１７０３ｅへ引き渡す。なお、拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔのｓｃｏｐｅによって、変化点発生の範囲を指定されている場合、変化点情報取得部１７０３ｃは、該変化点情報のファイルから情報を読み出し、指定された区間に含まれる変化点だけの変化点情報を新たに生成してファイルとして第２メモリ２０３に保存し、そのＵＲＩをＨｅａｄｅｒ生成部１７０３ｅへ引き渡す構成であっても良い。
【０５２７】
続いて、制御部１７０３ｂは、ストリーム取得部１７０３ｄへ、要求されたコンテンツのＵＲＩと、コンテンツの識別子を与える。すると、ストリーム取得部１７０３ｄは、ＩＯ４０５ｇに依頼して、属性情報テーブル１３２１を読み出す。そして、要求されたコンテンツの識別子より、該コンテンツの属性情報ファイルのファイル名を取得する。例えば、図４８に示した属性情報テーブル１３２１の場合、識別子１のコンテンツの属性情報ファイルは０００１．ａｔｔｒであることがわかる。続いて、ストリーム取得部１７０３ｄは、ＩＯ４０５ｇに依頼して、取得したファイル名の属性情報ファイルを読み出す。読み出した属性情報ファイルの内容のうち、ＦｉｌｅＮａｍｅ要素から該コンテンツのマルチメディアデータを格納したファイル名及びＦｉｌｅＴｒｅｅ属性情報を取得する。例えば、図４７に示した属性情報ファイルの場合、マルチメディアデータのファイル名は０００１．ｍ２ｔｓであり、ＯｂｊｅｃｔＣａｒｏｕｓｅｌのＦｉｌｅＴｒｅｅを保存したディレクトリが、／ＤＶＲ／Ｃｏｎｔｅｎｔ／０００１／Ｃａｒｏｕｓｅｌ１であることがわかる。
【０５２８】
続いて、ストリーム取得部１７０３ｄは、ＩＯ４０５ｇに依頼して、取得したファイル名のマルチメディアデータの存在を確認する。存在しない場合には、そのエラー内容をＨｅａｄｅｒ生成部１７０３ｅへ引き渡し、制御部１７０３ｂへ通知する。
【０５２９】
また、制御部１７０３ｂは、要求受信部１７０３ａから引き渡された情報の中に、アプリケーションのファイルを取得するための情報要求であるＸ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏがあるかどうかを調べる。該要求がある場合には、以下の処理を行う。まず、制御部１７０３ｂは、取得した該コンテンツ識別子とＸ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏの内容を、ベースポイント取得部１７０３ｇへ引き渡す。ベースポイント取得部１７０３ｇは、ＩＯ４０５ｇに依頼して、属性情報テーブル１３２１を読み出す。そして、要求されたコンテンツの識別子より、該コンテンツの属性情報ファイルのＦｉｌｅＴｒｅｅ要素を読み出す。例えば、図４７に示した属性情報ファイルの場合、ＯｂｊｅｃｔＣａｒｏｕｓｅｌのＦｉｌｅＴｒｅｅを保存したディレクトリが、／ＤＶＲ／Ｃｏｎｔｅｎｔ／０００１／Ｃａｒｏｕｓｅｌ１であることがわかる。続いて、ベースポイント取得部１７０３ｇは、ＩＯ４０５ｇに依頼して、取得したマウントポイント以下にＦｉｌｅＴｒｅｅが存在するか否かを確認する。存在する場合には、ＦｉｌｅＴｒｅｅ要素で指定されたディレクトリ名をＨｅａｄｅｒ生成部１７０３ｅへ引き渡す。存在しない場合には、空の文字列をＨｅａｄｅｒ生成部１７０３ｅへ引き渡す。
【０５３０】
続いて、制御部１７０３ｂは、Ｈｅａｄｅｒ生成部１７０３ｅに依頼して、レスポンスメッセージのヘッダを生成させる。Ｈｅａｄｅｒ生成部１７０３ｅでは、ここまでにネットワークライブラリ４０５ｅの各構成要素から受け取った情報を基に、ＨＴＴＰレスポンスメッセージのヘッダを生成する。すなわち、マルチメディアデータが存在する場合には、該属性情報ファイルや、ＩＯ４０５ｇに依頼することにより得られるファイルサイズなどの情報を集めて返信メッセージのヘッダを生成する。更に、変化点情報取得部１７０３ｃの結果より、変化点情報が存在する場合は、変化点情報取得部１７０３ｃから受け取った情報により、拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏを生成する。上記の例の場合では、X-Version-Info: url = http://192.168.0.3/VUP/0001-ait.vupという拡張ヘッダを追加してレスポンスメッセージのヘッダを生成する。変化点情報が存在しなかった場合には、Ｈｅａｄｅｒ生成部１７０３ｅは、Ｘ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏ拡張ヘッダを生成しない。更に、ベースポイント取得部１７０３ｇから受け取った情報により、拡張ヘッダＸ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏを生成する。上記の例の場合では、X-Tree-Base-Info : directory = /DVR/Content/0001/Carousel1/の拡張ヘッダをレスポンスメッセージのヘッダに追加する。この返信メッセージを情報送信部１７０３ｆへ引き渡す。ベースポイント取得部１７０３ｇから空の文字列が引き渡された場合には、値なしの拡張ヘッダＸ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏを生成して、レスポンスメッセージのヘッダに追加する。また、ベースポイント取得部１７０３ｇから何も情報が引き渡れていない場合には、Ｈｅａｄｅｒ生成部１７０３ｅは、拡張ヘッダＸ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏを生成しない。以上のようにして生成したレスポンスメッセージのヘッダを、情報送信部１７０３ｆへ引き渡す。
【０５３１】
続いて、制御部１７０３ｂは、情報送信部１７０３ｆに依頼して、レスポンスメッセージを該要求元端末へ送信する。情報送信部１７０３ｆは、まず、Ｈｅａｄｅｒ生成部１７０３ｅから引き渡された生成されたレスポンスメッセージのヘッダを、該要求元端末へ送信する。
【０５３２】
続いて、制御部１７０３ｂは、ＩＯ４０５ｇに依頼して、該マルチメディアデータを順次読み出しながら、情報送信部１７０３ｆに依頼して、読み出したデータを該要求元端末へ送信する。
【０５３３】
また、要求元端末よりマルチメディアデータの送信範囲を指定されている場合には、制御部１７０３ｂは、ＩＯ４０５ｇに依頼して、該マルチメディアデータの該当部分を読み出し、そのデータサイズなどの情報を集めて返信メッセージのヘッダを生成する。このとき、上記と同様の処理を行うことにより、レスポンスメッセージのヘッダを生成する。さらに、制御部１７０３ｂは、情報送信部１７０３ｆに依頼して、生成したレスポンスメッセージのヘッダを要求元端末へ送信する。続いて、制御部１７０３ｂは、情報送信部１７０３ｆに依頼して、読み出した該マルチメディアデータの該当部分を、要求元端末へ送信する。
【０５３４】
なお、上記の例では、ストリーム取得部１７０３ｄやベースポイント取得部１７０３ｇなど各構成要素が個別に属性情報テーブル１３２１を読み出すとしたが、制御部１７０３ｂが属性情報テーブル１３２１を読み出し、その中の必要な情報を各構成要素に引き渡す構成であっても良いことは言うまでもない。
【０５３５】
また、上記の例では、変化点情報を取得するＵＲＩをレスポンスメッセージのヘッダに含めることによって通知を行っているが、変化点の情報をレスポンスメッセージのヘッダに含める構成であっても良い。この場合、Ｈｅａｄｅｒ生成部１７０３ｅは、特に変化点情報取得部１７０３ｃから取得した／ＤＶＲ／Ｃｏｎｔｅｎｔ／０００１／ＶＵＰ／００００１−ａｉｔ.ｖｕｐより、図５１に示したような変化点情報を読み出す。Ｈｅａｄｅｒ生成部１７０３ｅは読み出した変化点情報を参照し、ＡＩＴなどのセクションの長さ及びその内容を取得する。そして、拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏにて、指示子lengthを用いてそのセクションの長さを、また、bytes指示子を用いてそのセクションの内容を記述する。例えば、以下のような拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏを生成する。
X-Version-Info: type=ait; length = 100 ; bytes = 110110010001001……1111
【０５３６】
また、図５１の列１８０４及び列１８０５を用いて、該マルチメディアコンテンツの先頭を０とした場合の、セクションを伝送するバイト位置を表すことが出来る。例えば、指示子section_rangeを用いて始点と終点を記述し、以下のような拡張ヘッダを生成する。
X-Version-Info : type=ait; section_range=5000-10000
【０５３７】
Ｊａｖａライブラリ４０５は、第２メモリ２０３に格納されている複数のＪａｖａライブラリの集合である。本実施の形態では、Ｊａｖａライブラリ４０５は、ＪＭＦ４０５ａ、ＡＭ４０５ｂ、Ｔｕｎｅｒ４０５ｃ、ＣＡ４０５ｄ、ネットワークライブラリ４０５ｅ、再生Ｌｉｂ４０５ｆ、ＩＯ４０５ｇ、ＡＷＴ４０５ｈ、ＳＩ４０５ｉ、Ｒｅｃ４０５ｊ等を含んでいる。
【０５３８】
ＪＭＦ４０５ａ、ＡＭ４０５ｂ、Ｔｕｎｅｒ４０５ｃ、ＣＡ４０５ｄ、Ｒｅｃ４０５ｊの機能は、既に記述されているので省略する。
【０５３９】
再生Ｌｉｂ４０５ｆは、第２メモリ２０３が記憶している、現在再生しているチャンネルの識別子をＪａｖａプログラムに渡すためのＪａｖａ言語のクラスおよびメソッドを（以下Ｊａｖａ  ＡＰＩと記述）提供する。このＪａｖａ  ＡＰＩを利用することで、Ｊａｖａプログラムは、現在再生中のチャンネルを知ることができる。
【０５４０】
ＩＯ４０５ｇは、Ｊａｖａプログラムが第２メモリ２０３にデータを書き込むためのＪａｖａ  ＡＰＩ、あるいは、その書き込んだデータを第２メモリ２０３から読みこむためのＪａｖａ  ＡＰＩをＪａｖａプログラムに提供する。このＡＰＩを利用することで、Ｊａｖａプログラムは、任意のデータを第２メモリ２０３に保存することができる。この保存されたデータはマルチメディアデータ送信装置１０１の電源がオフになっても消えないので、マルチメディアデータ送信装置１０１の電源が投入された後、再びそのデータを読み込むことができる。
【０５４１】
ＡＷＴ４０５ｈは、Ｊａｖａプログラムが描画を行ったり、入力部２０１からのキー入力通知を受け取るためのＪａｖａ  ＡＰＩを提供する。具体的には、「Ｔｈｅ  Ｊａｖａ  ｃｌａｓｓ  Ｌｉｂｒａｒｉｅｓ  Ｓｅｃｏｎｄ  Ｅｄｉｔｉｏｎ，Ｖｏｌｕｍｅ  ２」（ＩＳＢＮ０−２０１−３１００３−１）で既定されるｊａｖａ．ａｗｔパッケージ、ｊａｖａ．ａｗｔ．ｅｖｅｎｔパッケージ及びその他のｊａｖａ．ａｗｔのサブパッケージが相当する。ここでは、詳細な説明を省略する。
【０５４２】
ＳＩ４０５ｉは、Ｊａｖａプログラムがチャンネル情報や電子番組表情報を取得するＪａｖａ  ＡＰＩを提供する。具体的には、Ｊａｖａ  ＴＶ仕様などが存在する。また、生のバイナリデータを放送中のＭＰＥＧ２トランスポートストリームから取得するＭＰＥＧセクションフィルタＡＰＩがＯＣＡＰ仕様の中で定義されており、送信されてきた独自の電子番組データをＪａｖａアプリケーションが理解して取り扱うことも出来る。
【０５４３】
次に、マルチメディアデータ受信装置１０２について説明する。
【０５４４】
図５２は、本実施の形態におけるマルチメディアデータ受信装置１０２の構成要素の関係を示したブロック図であり、入力部１９０１、第１メモリ１９０２、第２メモリ１９０３、多重分離手段１９０４、ＴＳデコーダ１９０５、映像出力部１９０６、音声出力部１９０７、ネットワーク部１９０８、ＣＰＵ１９０９で構成される。
【０５４５】
入力部１９０１、第１メモリ１９０２、第２メモリ１９０３は、上記した本実施の形態におけるマルチメディアデータ送信装置１０１の入力部２０１、第１メモリ２０２、第２メモリ２０３と同様のものである。なお、マルチメディアデータ受信装置１０２は、第２メモリ１９０３に、マルチメディアデータ送信装置１０１から受信したコンテンツ一覧やＥＰＧデータなどの、マルチメディアデータの識別子、タイトル、放送日時、放送チャンネルなど番組情報を蓄積する。
【０５４６】
多重分離手段１９０４は、ＣＰＵ１９０９からＭＰＥＧトランスポートストリームを受け取り、ＣＰＵ１９０９から指定された情報を抽出し、ＣＰＵ１９０９に引き渡す。また、ＭＰＥＧトランスポートストリームをそのままＴＳデコーダ１９０５に引き渡す。
ＴＳデコーダ１９０５は、ＣＰＵ１９０９から、音声データ、映像データの識別子を受け取る。さらに、多重分離手段１９０４から受け取ったストリームから、受け取った音声データ、映像データの識別子に対応するデータを抽出する。抽出した映像データを映像出力部１９０６に、音声データを音声出力部１９０７に、それぞれ引き渡す。
【０５４７】
映像出力部１９０６、音声出力部１９０７は、上記した本実施の形態におけるマルチメディアデータ送信装置１０１の映像出力部２０８、音声出力部２０９と同様のものである。
【０５４８】
ネットワーク部１９０８は、ネットワークインタフェースを含み、ＣＰＵ１９０９から受け取ったデータを、ネットワークインタフェースが接続されたネットワークの物理メディアに応じた信号に変換して出力する。また、ネットワークインタフェースから信号を受信し、ＩＰネットワークで規定されたパケットに変換して、ＣＰＵ１９０９へ引き渡す。
【０５４９】
ＣＰＵ１９０９は、第２メモリ１９０３が記憶するプログラムを実行することで、多重分離部１９０４、ＴＳデコーダ１９０５、およびネットワーク部１９０８を制御する。
【０５５０】
図５３は、第２メモリ１９０３に記憶され、ＣＰＵ１９０９に実行されるプログラムの構成図の一例である。
【０５５１】
プログラム２０００は、複数のサブプログラムで構成され、具体的にはＯＳ２００１、ＪａｖａＶＭ２００２、サービスマネージャ２００３、Ｊａｖａライブラリ２００４で構成される。
【０５５２】
ＯＳ２００１は、マルチメディアデータ受信装置１０２の電源が投入されると、ＣＰＵ１９０９が起動するサブプログラムである。ＯＳは、オペレーティングシステムの略であり、Ｌｉｎｕｘ等が一例である。ＯＳ２００１は、他のサブプログラムを平行して実行するカーネル２００１ａ及びライブラリ２００１ｂで構成される公知の技術の総称であり、詳細な説明は省略する。本実施の形態においては、ＯＳ２００１のカーネル２００１ａは、ＪａｖａＶＭ２００２をサブプログラムとして実行する。また、ライブラリ２００１ｂは、これらサブプログラムに対して、マルチメディアデータ受信装置１０２が保持する構成要素を制御するための複数の機能を提供する。
【０５５３】
本実施の形態では、ライブラリ２００１ｂは機能の一例として、限定解除２００１ｂ１、ＡＶ再生２００２ｂ２、ＮＥＴ２００１ｂ３を含む。
【０５５４】
限定解除２００２ｂ１は、他のサブプログラムやＪａｖａライブラリ２００４のＣＡ２００４ｃから情報を受け取り、ＡＶ再生２００１ｂ２を有効にして、ネットワークから受信したマルチメディアデータの再生を許可したりするものである。
【０５５５】
ＡＶ再生２００２ｂ２は、他のサブプログラムやＪａｖａライブラリ２００４のＪＭＦ２００４ａから、音声のパケットＩＤと映像のパケットＩＤを受け取る。受け取った音声のパケットＩＤと映像のパケットＩＤを、ＴＳデコーダ１９０５に与える。この結果、ＴＳデコーダ１９０５は与えられたパケットＩＤに基づいて、フィルタリングを行い、映像・音声の再生を実現する。
【０５５６】
ＮＥＴ２００１ｂ３は、他のサブプログラムやＪａｖａライブラリ２００４のネットワークライブラリ２００４ｄから受け取ったデータを、ＩＰネットワークで規定されるアプリケーション層より下のプロトコルのパケットを作成する。アプリケーション層より下のプロトコルとは、例えばＴＣＰパケット、ＵＤＰパケット、ＩＰパケットなどである。これをネットワーク部１９０８に引き渡すことで、ネットワーク１０３を介して他の機器にメッセージおよびデータを送信する。また、ネットワーク１０３を介して他の機器からのメッセージを受信したときに、他のサブプログラムやＪａｖａライブラリ２００４のネットワークライブラリ２００４ｄに、アプリケーション層のプロトコルのパケットに変換して引き渡す。アプリケーション層のプロトコルとは、例えば、ＨＴＴＰ、ＲＴＳＰやＲＴＰなどである。
【０５５７】
サービスマネージャ２００３は、上記した本実施の形態におけるマルチメディアデータ送信装置１０１のサービスマネージャ４０４と、以下の相違点を除いて同様のものである。サービスマネージャ４０４はＥＰＧ４０２の再生部４０２ｂよりチャンネル識別子を受け取り、その識別子をＴｕｎｅｒ４０５ｃに引き渡してチューニングさせ、さらにＣＡ４０５ｄに依頼してデスクランブルを行い、ＪＭＦ４０５ａにチャンネルの識別子を与えて映像・音声の再生を依頼するものであったが、サービスマネージャ２００３は、Ｊａｖａライブラリ２００４の中にあるＬｉｓｔ２００４ｉからコンテンツの識別子を受け取り、ネットワークライブラリ２００４ｄにコンテンツの識別子およびそれを蓄積している装置などの情報を引き渡して、該装置からストリームを受信し、Ｊａｖａライブラリ２００４の中にあるＪＭＦ２００４ａにコンテンツの識別子を与えることで、映像・音声の再生を依頼するものである。Ｌｉｓｔ２００４ｉについては、後述する。
【０５５８】
サービスマネージャ２００３は、Ｊａｖａライブラリ２００４のネットワークライブラリ２００４ｄに、コンテンツの識別子及びマルチメディアデータ送信装置１０１のＩＰアドレスなどの情報、該コンテンツにアクセスするためのＵＲＩなどの情報を与える。そして、サービスマネージャ２００３は、ネットワークライブラリ２００４ｄに、マルチメディアデータ送信装置１０１へのマルチメディアデータ送信要求の送信を依頼する。さらに、サービスマネージャ２００３は、ネットワークライブラリ２００４ｄに、マルチメディアデータ送信装置１０１から送信されたマルチメディアデータの受信を依頼する。ネットワークライブラリ２００４ｄでは、依頼を受けると、マルチメディアデータ送信装置１０１と接続して、マルチメディアデータの送信要求を発行する。そして、ネットワークライブラリ２００４ｄは、マルチメディアデータ送信装置１０１から送信されたデータをＣＰＵ１９０９へ引き渡す。
【０５５９】
サービスマネージャ２００３は、マルチメディアデータを多重分離手段１９０４に引き渡すことで、該マルチメディアデータの再生が行える。
【０５６０】
なお、早送りや巻き戻しなどの特殊再生に関しては、サービスマネージャ２００３は、後述のＪＭＦ２００４ａに特殊再生を依頼し、また、ネットワークライブラリ２００４ｄに依頼して、特殊再生に必要なデータを順次受信させることによって行う。
【０５６１】
Ｊａｖａライブラリ２００４は、第２メモリ１９０３に格納されている複数のＪａｖａライブラリの集合である。本実施の形態では、Ｊａｖａライブラリ２００４は、ＪＭＦ２００４ａ、ＡＭ２００４ｂ、ＣＡ２００４ｃ、ネットワークライブラリ２００４ｄ、再生Ｌｉｂ２００４ｅ、Ｌｉｓｔ２００４ｉ等を含んでいる。
【０５６２】
ＪＭＦ２００４ａ、ＡＭ２００４ｂ、再生Ｌｉｂ２００４ｅ、ＩＯ２００４ｆ、ＡＷＴ２００４ｇ、ＳＩ２００４ｈは、それぞれ、上記した本実施の形態におけるマルチメディアデータ送信装置１０１のＪａｖａライブラリ４０５中のＪＭＦ４０５ａ、ＡＭ４０５ｂ、再生Ｌｉｂ４０５ｆ、ＩＯ４０５ｇ、ＡＷＴ４０５ｈ、ＳＩ４０５ｉと同様のものである。
【０５６３】
ＣＡ２００４ｃは、ネットワーク１０３経由で送信されてきたマルチメディアデータのコピー制御など、該マルチメディアデータの権利処理を管理するものである。コピー制御のための情報は、マルチメディアデータ送信装置１０１や、放送局１０５などのコンテンツ提供者、権利者が指定する外部のサーバなどから送信されてもよいし、マルチメディアデータ送信装置１０１から送信されてきたトランスポートストリームのＰＭＴに含まれているコピー制御情報を参照しても良い。
【０５６４】
Ｌｉｓｔ２００４ｉは、マルチメディアデータ送信装置１０１におけるＥＰＧや、マルチメディアデータ送信装置１０１が蓄積し提供するマルチメディアコンテンツの一覧を表示し、入力部１９０１が受け付けたユーザ操作によって、一覧からひとつのマルチメディアコンテンツを選択し、サービスマネージャ２００３に再生を依頼するものである。このとき、マルチメディアデータ送信装置１０１の情報もサービスマネージャ２００３に引き渡す。また、マルチメディアデータ送信装置１０１におけるＥＰＧおよびマルチメディアデータ送信装置１０１から提供されるコンテンツの一覧は、ネットワークライブラリ２００４ｄを通して、取得することができる。なお、Ｌｉｓｔ２００４ｉは、ネットワークライブラリ２００４ｄに含まれる構成であっても良い。
【０５６５】
ネットワークライブラリ２００４ｄは、ＯＳ２００１ｂのＮＥＴ２００１ｂ３を通して、ネットワーク１０３に接続されたマルチメディアデータ送信装置１０１と通信するものである。マルチメディアデータ送信装置１０１との通信は、マルチメディアデータの一覧送受信、およびマルチメディアデータの送信要求発行と該マルチメディアデータの受信である。
【０５６６】
図５４は、ネットワークライブラリ２００４ｄの内部構成の一例を表すブロック図である。ネットワークライブラリ２００４ｄは、制御部２１０１ａ、接続管理部２１０１ｂ、メッセージ処理部２１０１ｃ、判定部２１０１ｄ、送受信部２１０１ｅを含む。なお、ネットワークライブラリ２００４ｄは、ＩＰネットワークに関連する他の機能を含んでも良い。
【０５６７】
制御部２１０１ａは、マルチメディアデータ受信装置１０２上で実行される、ダウンロードしたＪａｖａアプリケーションもしくは、サービスマネージャ２００３やＪａｖａライブラリ２００４の他の構成要素にＪａｖａ  ＡＰＩを提供し、ネットワークライブラリ２００４ｄが実現する機能を利用可能とするものである。接続管理部２１０１ｂは、制御部２１０１ａから依頼されて動作するものであり、マルチメディアデータ送信装置１０１のようなネットワーク１０３上の外部機器とのネットワーク接続を管理するものである。メッセージ処理部２１０１ｃは、制御部２１０１ａから依頼されて動作するものであり、制御部２１０１ａから受け取った情報を基に、ネットワーク１０３との接続を行っている外部機器へ送信するメッセージの生成を行うものである。判定部２１０１ｄは、制御部２１０１ａから依頼されて動作するものであり、外部機器から受信したレスポンスメッセージを制御部２１０１ａから受け取ってそれを解釈し、内容を制御部２１０１ａに通知するものである。送受信部２１０１ｅは、制御部２１０１ａからの依頼で動作するものであり、接続管理部２１０１ｂが管理し、制御部２１０１ａから引き渡されるネットワーク接続において、制御部２１０１ａから引き渡されたデータを送信し、また、前記ネットワーク接続からデータを受信して制御部２１０１ａに引き渡すものである。以下、これらの動作を説明する。
【０５６８】
まず、ネットワーク１０３に接続された外部機器が提供するコンテンツ一覧を取得する動作について説明する。
【０５６９】
まず、制御部２１０１ａは、ダウンロードしたＪａｖａアプリケーションやサービスマネージャ２００３などからの依頼により、ネットワーク１０３に接続された機器の一覧を取得する。この機器一覧は、ＵＰｎＰ  ＤＡに定義された通信を行うことによって生成できる。また、このＵＰｎＰ  ＤＡに定義された通信は、外部機器から問い合わせを受ける場合と、マルチメディアデータ受信装置１０２から、すなわち、制御部２１０１ａから問い合わせる場合とがある。外部機器から通知を受けた場合、制御部２１０１ａは、送受信部２１０１ｅが受信したＵＰｎＰ  ＤＡで定義されるメッセージを判定部２１０１ｄに解釈させ、その内容を得る。メッセージは、サーバ機器のようなデバイス、もしくはサーバ機器が提供するサービスが、ネットワーク１０３を通して利用可能であることを通知する。続いて、制御部２１０１ａは、通知してきた外部機器に対して、ＵＰｎＰ  ＤＡで定義された、該サーバ機器もしくはサービスの情報の問い合わせメッセージを、メッセージ処理部２１０１ｃに生成させる。さらに、制御部２１０１ａは、生成したメッセージを送受信部２１０１ｅに与えて送信させ、該サーバ機器からの返答メッセージを受信させる。更に、制御部２１０１ａは、受信した返答メッセージを、メッセージ処理部２１０１ｃに与えて解釈させることにより、該サーバ機器および該サーバ機器が提供するサービスの詳細を知ることができる。なお、これらの通信に用いられるネットワークコネクションは、接続管理部２１０１ｂによって管理される。
【０５７０】
また、制御部２１０１ａから問い合わせる場合は、まず、制御部２１０１ａは、メッセージ処理部２１０１ｃに依頼して、ＵＰｎＰ  ＤＡで定義されている機器の存在を問い合わせるメッセージを生成する。そして、生成したメッセージを送受信部２１０１ｅに依頼して、ネットワーク１０３にブロードキャストさせる。続いて接続管理部２１０１ｂに依頼して、前記ブロードキャストしたメッセージに対する返答を受信するために接続要求を受け付ける。接続管理部２１０１ｂより接続を受け入れたことを通知されれば、制御部２１０１ａは、送受信部２１０１ｅに依頼してメッセージを受信させる。さらに、制御部２１０１ａは、判定部２１０１ｄに依頼して、受信したメッセージを解釈させ、その情報を取得する。さらに、制御部２１０１ａは、メッセージ処理部２１０１ｃに依頼して、機器が提供するサービスや能力を問い合わせるメッセージを生成させ、送受信部２１０１ｅに依頼して、外部機器へ送信させる。さらに、制御部２１０１ａは、送受信部２１０１ｅに依頼して、送信したメッセージに対するレスポンスメッセージを受信させ、受信したメッセージを判定部２１０１ｄに与えて解釈させ、その内容を取得する。これにより、制御部２１０１ａは、ある外部機器の情報を得ることができる。このような処理を繰り返すことにより、ネットワーク１０３に接続された外部機器の一覧を取得できる。
【０５７１】
続いて、制御部２１０１ａは、ダウンロードしたＪａｖａアプリケーションやサービスマネージャ２００３などからの依頼により、ネットワーク１０３に接続された特定の外部機器が提供するコンテンツ一覧を取得する。以降、この特定の外部機器をマルチメディアデータ送信装置１０１として説明する。
【０５７２】
まず、制御部２１０１ａは、メッセージ処理部２１０１ｃに依頼して、ＵＰｎＰ  ＡＶで定義されたコンテンツ一覧送付依頼メッセージを生成する。このとき、Ｊａｖａアプリケーションなどから、コンテンツの条件を引き渡されていれば、その条件をメッセージ処理部２１０１ｃに与えて、適切なメッセージを生成する。続いて、制御部２１０１ａは、Ｊａｖａアプリケーションなどから与えられたマルチメディアデータ送信装置１０１のＩＰアドレスなどの情報を接続管理部２１０１ｂに与えて、マルチメディアデータ送信装置１０１とのネットワーク接続の情報を得る。そして、それを送受信部２１０１ｅに与える。このとき、マルチメディアデータ送信装置１０１とのネットワーク接続がまだ確立されていなかった場合には、接続管理部２１０１ｂは新たにマルチメディアデータ送信装置１０１との接続を確立する。続いて、制御部２１０１ａは、メッセージ処理部２１０１ｃが生成したコンテンツ一覧送付依頼メッセージを送受信部２１０１ｅに与えて、マルチメディアデータ送信装置１０１へ送信させる。さらに、制御部２１０１ａは、送受信部２１０１ｅに依頼して、マルチメディアデータ送信装置１０１からのレスポンスメッセージを受信させる。さらに、制御部２１０１ａは、受信したレスポンスメッセージを判定部２１０１ｄに与えて解釈させ、その内容であるコンテンツ一覧を取得する。制御部２１０１ａは、取得したコンテンツ一覧をＪａｖａアプリケーションやサービスマネージャ２００３、もしくはＬｉｓｔ２００４ｉへ引き渡す。
【０５７３】
次に、ダウンロードしたＪａｖａアプリケーションもしくはサービスマネージャ２００３からの依頼により、マルチメディアデータ送信装置１０１からマルチメディアデータおよびその関連のデータを受信し、再生するときの処理について説明する。以下、サービスマネージャ２００３からの依頼による処理を例に説明するが、ダウンロードしたＪａｖａアプリケーションからの依頼の場合も同様である。
【０５７４】
まず、制御部２１０１ａは、サービスマネージャ２００３からマルチメディアデータ取得依頼を受信すると、接続管理部２１０１ｂに依頼して、マルチメディアデータ送信装置１０１とのネットワーク接続を確立する。このとき、サービスマネージャ２００３から、コンテンツの識別子及びマルチメディアデータ送信装置１０１のＩＰアドレスなどの情報、該コンテンツにアクセスするためのＵＲＩなどの情報などが制御部２１０１ａに引き渡される。このうち、少なくともマルチメディアデータ送信装置１０１のＩＰアドレスや該ネットワーク接続のためのポート番号などを接続管理部２１０１ｂに与える。
【０５７５】
接続管理部２１０１ｂは、制御部２１０１ａから引き渡された情報により、マルチメディアデータ送信装置１０１とのネットワーク接続を確立する。ネットワーク接続とは、例えば、マルチメディアデータの通信をＨＴＴＰ通信で行う場合、ＨＴＴＰを行うためのＴＣＰコネクションをさす。なお、本実施の形態においては、接続管理部２１０１ｂにマルチメディアデータ送信装置１０１のＩＰアドレスやポート番号を与えるとしたが、取得するデータのＵＲＩを与え、接続管理部２１０１ｂがＵＲＩを解釈して、これらの情報を得る構成であっても良い。また、コンテンツの識別子を与え、接続管理部２１０１ｂがこれらの情報を取得する構成であっても良い。
【０５７６】
次に、制御部２１０１ａは、サービスマネージャ２００３によって再生を起動するため、図５３に示した各種ライブラリからのセクション取得要求及びファイル取得要求を受け付ける。例えば、ＡＶ再生のためのマルチメディアデータの受信を行う。また、マルチメディアデータ受信装置１０２上で特殊再生を行う際には、ＰＡＴやＰＭＴ及びＤＳＭＣＣで伝送されるファイルの受信要求が必要となる。これは、特殊再生時は、マルチメディアデータの全てのＴＳストリームを受信しない場合があり、ＪＭＦ２００４ａやＡＭ２００４ｂ、ＤＳＭＣＣ２００４ｌなどがＰＡＴ及びＰＭＴを利用する必要なタイミングでこれらのセクションデータ、もしくは、ＤＳＭＣＣのファイルがマルチメディアデータ受信装置１０２に存在しない可能性があるからである。
【０５７７】
次に、制御部２１０１ａは、これらの取得要求をマルチメディアデータ送信装置１０１へ要求するために、メッセージ処理部２１０１ｃへ依頼し、対応するＨＴＴＰリクエストを生成する。
【０５７８】
メッセージ処理部２１０１ｃは、要求されたマルチメディアデータのＵＲＩをＨＴＴＰリクエストに設定する。例えば、マルチメディアデータのＵＲＩがhttp://192.168.0.3/AVData/0001.m2tsで、かつ、特殊再生に備え、ストリーム中の変化点情報を要求するために拡張ヘッダX-Version-Requestを設定したＨＴＴＰリクエストは以下のようになる。
GET http://192.168.0.3/AVData/0001.m2ts HTTP/1.1
Host: 192.168.0.3
Date: Thr Jan 11 15:00:00 2007 GMT
User-Agent: AVT Client
Connection: Keep-Alive
X-Version-Request: type = ait ; scope = all
【０５７９】
なお、特殊再生時には、必要なマルチメディアコンテンツの特定区間を指定する方法でリクエストが行われる。これはＨＴＴＰのＲａｎｇｅヘッダを用いて行うことが出来る。また、同様に、変化点発生の範囲を指定したヘッダを生成する。
X-Version-Request : type = ait ; scope = 47940-95879
【０５８０】
この拡張ヘッダは、例えば特殊再生のために、取得しなかったストリームの区間に変化点がある場合、それを取得するために利用することができる。
【０５８１】
続いて、制御部２１０１ａは、以上のように生成したＨＴＴＰリクエストを送受信部２１０１ｅに与え、マルチメディアデータ送信装置１０１へ送信させる。
【０５８２】
次に、制御部２１０１ａは送受信部２１０１ｅに依頼して、マルチメディアデータ送信装置１０１よりＨＴＴＰレスポンスを受信する。受信したＨＴＴＰレスポンスの例を以下に示す。
HTTP/1.1 200 OK
Date: Thr Jan 11 15:00:01 2007 GMT
Server: AVT Server
Connection: Keep-Alive
Content-Type: video/mpeg
Content-Length: 47952
X-Version-Info: type=ait ; url = http://192.168.0.3/VUP/0001-ait.vup
(空行)
[47952バイトのデータ]
【０５８３】
そして、制御部２１０１ａは、受信したＨＴＴＰレスポンスメッセージを、判定部２１０１ｄへ引き渡し、その解釈を依頼する。
【０５８４】
判定部２１０１ｄでは、まず、ＨＴＴＰレスポンスのレスポンスコードを確認する。結果が２００  ＯＫの場合は、それを制御部２１０１ａに伝える。すると、制御部２１０１ａは、ＨＴＴＰレスポンスのボディ部にある受信したマルチメディアデータをサービスマネージャ２００３へ引き渡し、再生が行われる。
【０５８５】
更に、判定部２１０１ｄは、ストリーム中の変化点情報を示す拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏが存在するか調べる。上記の例のように存在する場合は、その内容を制御部２１０１ａに通知する。そして、制御部２１０１ａは、メッセージ処理部２１０１ｃ及び送受信部２１０１ｅに依頼して、変化点情報取得のためのメッセージを生成してマルチメディアデータ送信装置１０１へ送信し、さらに、送受信部２１０１ｅに依頼して、マルチメディアデータ送信装置１０１より指定されたストリーム変化点情報を受信する。そして、制御部２１０１ａは、受信した変化点情報をＳＩ２００４ｈへと引き渡す。拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏが存在しない場合は、判定部２１０１ｄから制御部２１０１ａへ、拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏが存在しないことが通知されるのみである。
【０５８６】
ＳＩ２００４ｈでは、受信したマルチメディアデータの再生時、受信した変化点情報に従い、リクエストされたＪａｖａライブラリへセクションデータのバージョンアップを通知する。これにより、Ｊａｖａアプリケーションやサービスマネージャ２００３、もしくは、Ｊａｖａライブラリは、セクションデータのバージョンアップに対応して適切な処理が可能となる。例えば、新たにアプリケーションを起動する必要がある場合、起動のタイミングなどを検知することが可能となる。これにより、適切なタイミングでアプリケーションを起動することができる。アプリケーションの起動などのために、マルチメディアデータ送信装置１０１からファイルの取得が必要な場合は、上述の拡張ヘッダＸ−Ｔｒｅｅ−Ｂａｓｅ−Ｒｅｑｕｅｓｔおよび拡張ヘッダＸ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏを利用して取得することが可能である。すなわち、制御部２１０１ａは、メッセージ処理部２１０１ｃに依頼して、拡張ヘッダＸ−Ｔｒｅｅ−Ｂａｓｅ−Ｒｅｑｕｅｓｔを含んだマルチメディアデータ送信要求メッセージを生成し、送受信部２１０１ｅにそのメッセージを与えて、マルチメディアデータ送信装置１０１へ送信する。そして、送受信部２１０１ｅにより、そのレスポンスメッセージを受信し、受信したレスポンスメッセージを判定部２１０１ｄに引き渡す。判定部２１０１ｄでは、さらに拡張ヘッダＸ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏが含まれているかを調べ、含まれている場合にはそれを制御部２１０１ａに通知する。制御部２１０１ａでは、Ｊａｖａアプリケーションやサービスマネージャ２００３などから、ファイル取得の要求を受け付けると、通知されたＸ−Ｔｒｅｅ−Ｂａｓｅ−Ｉｎｆｏの値を用いて、上述のようにマルチメディアデータ送信装置１０１からファイルを受信する。
【０５８７】
以上のように、マルチメディアデータ受信装置１０２において、特殊再生を行ったとしても、ストリームの変化点を正しく検知することができ、データ放送を含め、コンテンツを適切に再生することが可能となる。
【０５８８】
なお、ここではＳＩ２００４ｈが、バージョンアップのタイミングを管理する例を示したが、マルチメディアデータ再生時のコンテンツの視聴箇所と、受信した変化点情報の対応をとり、バージョンアップの通知など適切な処理を行うことが可能であれば、他のライブラリが本機能を実現してもよい。
【０５８９】
（その他の変形例）
本発明を上記実施の形態に基づいて説明してきたが、本発明は、上記実施の形態に限定されるものではない。以下のような場合も、本発明に含まれる。
【０５９０】
（１）上記実施の形態においては、コンテンツデータの通信プロトコルとしてＨＴＴＰを用いたが、ＲＴＰ／ＲＴＳＰなど、他のプロトコルを用いても良い。
【０５９１】
（２）上記実施の形態では、ＭＰＥＧ２−ＴＳ形式の映像コンテンツのみを説明したが、他の符号化形式の映像コンテンツや、音楽などの別の種類のコンテンツでも同様の処理が行えることは言うまでもない。
【０５９２】
（３）上記実施の形態では、データおよびテーブルの送信は、クライアントであるマルチメディアデータ受信装置１０２からの依頼により、サーバであるマルチメディアデータ送信装置１０１から送信されたが、クライアントからの要求がない場合に、サーバから送信する構成であってもよい。この場合、サーバからどの形式で送られるかは、サーバが独自に決めても良いし、クライアントとの間であらかじめ決めておいても良い。また、放送局など、外部からの指示により決めても良い。
【０５９３】
（４）上記実施の形態では、拡張ヘッダを規定したが、同等の情報を送信できるものであれば、この形式に限らないことは言うまでもない。
【０５９４】
（５）上記実施の形態では、マルチメディアデータの送信要求に含めて、データおよびテーブルの送信要求を発行したが、マルチメディアデータの通信とは独立に、変化点情報の通信を行っても良い。また、上記実施の形態においては、ＨＴＴＰ−ＧＥＴリクエストのヘッダにデータおよびテーブルの送信要求を含めて送信したが、データの送受信を伴わないＨＴＴＰ−ＨＥＡＤリクエストなどを用いてデータおよびテーブルのみの通信を行っても良い。
【０５９５】
（６）上記実施の形態では、ストリームの変化点情報の送信は、クライアントであるマルチメディアデータ受信装置１０２からの依頼により、サーバであるマルチメディアデータ送信装置１０１から送信されたが、クライアントからの要求がなくても、サーバから送信する構成であってもよい。
【０５９６】
（７）上記実施の形態では、拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔ及び拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏを規定したが、同等の情報を送信できるものであれば、この形式に限らないことは言うまでもない。例えば、Ｐｒａｇｍａヘッダフィールドを利用しても良い。この場合、送信要求のｐｒａｇｍａ−ｄｉｒｅｃｔｉｖｅとして、ｇｅｔＶｅｒｓｉｏｎＩｎｆｏＵＲＩを使用し、ＵＲＩ通知のｐｒａｇｒｍａ−ｄｉｒｅｃｔｉｖｅをｖｅｒｉｏｎＩｎｆｏＵＲＩとすれば、送信要求はリクエストメッセージに以下のヘッダを加えることで実現できる。
Pragma: getVersionInfoURI
【０５９７】
また、ＵＲＩはレスポンスメッセージに以下のヘッダを追加することで通知することができる。
Pragma: versionInfoURI = "http://192.168.0.3/VUP/0001-ait.vup"
【０５９８】
その特定区間で発生した変化点情報が必要な場合や、特定のセクションデータだけの変化点情報を取得する場合は、このＰｒａｇｍａヘッダフィールドのＰｒａｇｍａ−ｄｉｒｅｃｔｉｖｅを追加しても良いし、上記の拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔおよび拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｉｎｆｏと併用しても良い。また、拡張ヘッダＸ−Ｖｅｒｓｉｏｎ−Ｒｅｑｕｅｓｔを含むリクエストのレスポンスとしてＰｒａｇｍａヘッダフィールドを用いるなどしても良い。
【０５９９】
（８）上記実施の形態では、マルチメディアデータの送信要求に含めて、変化点情報の送信要求を発行したが、マルチメディアデータの通信とは独立に、変化点情報の通信を行っても良い。また、上記実施の形態においては、ＨＴＴＰ−ＧＥＴリクエストのヘッダに変化点情報の送信要求を含めて送信したが、データの送受信を伴わないＨＴＴＰ−ＨＥＡＤリクエストなどを用いて変化点情報のみの通信を行っても良い。
【０６００】
（９）上記実施の形態では、マルチメディアデータ送信装置は、マルチメディアデータ受信装置から指定された範囲での変化点情報を通知するとしたが、マルチメディアデータ受信装置がRangeヘッダフィールドなどを用いて、マルチメディアデータの特定区間のみのデータを取得する場合、その区間の変化点を通知するとしても良い。あるいは、指定された区間の前もしくは後ろの変化点を通知するとしても良い。また、マルチメディアデータ受信装置が、連続して区間指定の要求を発行する場合は、前回要求された区間と、今回要求された区間の間の変化点を通知するとしても良い。
【０６０１】
（１０）上記の各装置を構成する構成要素の一部又は全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。
【０６０２】
（１１）上記の各装置を構成する構成要素の一部又は全部は、各装置に脱着可能なＩＣカード又は単体のモジュールから構成されているとしてもよい。前記ＩＣカード又は前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、などから構成されるコンピュータシステムである。前記ＩＣカード又は前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ＩＣカード又は前記モジュールは、その機能を達成する。このＩＣカード又はこのモジュールは、耐タンパ性を有するとしてもよい。
【０６０３】
（１２）本発明のマルチメディアデータ送信装置、マルチメディアデータ受信装置は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。
【０６０４】
また、本発明のマルチメディアデータ送信装置、マルチメディアデータ受信装置は、前記コンピュータプログラム又は前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ―ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Ｂｌｕ−ｒａｙ  Ｄｉｓｃ）、半導体メモリなど、に記録したものとしてもよい。また、これらの記録媒体に記録されている前記コンピュータプログラム又は前記デジタル信号であるとしてもよい。
【０６０５】
また、本発明のマルチメディアデータ送信装置、マルチメディアデータ受信装置は、前記コンピュータプログラム又は前記デジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
【０６０６】
また、本発明のマルチメディアデータ送信装置、マルチメディアデータ受信装置は、マイクロプロセッサとメモリとを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記憶しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしてもよい。
【０６０７】
また、前記プログラム又は前記デジタル信号を前記記録媒体に記録して移送することにより、又は前記プログラム又は前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
【０６０８】
（１３）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。
【０６０９】
上記に詳細に説明した本発明の実施の形態は単なる例示にすぎず、本発明の新規な教示および効果から実質的に逸脱することなく例示として挙げた実施の形態において様々な変更が可能であることは、当業者であれば容易に理解するところである。したがって、かかる変更はすべて本発明の範囲内に含まれるものである。
【産業上の利用可能性】
【０６１０】
本発明にかかるマルチメディアデータ送信装置、マルチメディアデータ受信装置、およびこれらによって構成されるマルチメディアコンテンツ通信システムは、ホームネットワークを利用したマルチメディアコンテンツの共有において、マルチメディアサーバがクライアントからの要求に応じてマルチメディアデータを送信し再生するとき、特殊再生が発生するとデータ放送を正しく実現することができないという課題を、データ放送用データにおいてタイミングなどに依存して必要となるデータを必ずマルチメディアデータ受信装置へ通知する手法を提供することにより、データ放送を正しいタイミングで実現することが可能となる。このため、ホームネットワークなどのネットワーク環境におけるサーバ装置、受信端末、マルチメディアデータ通信方法などとして有用である。
【符号の説明】
【０６１１】
１０１  マルチメディアデータ送信装置
１０２  マルチメディアデータ受信装置
１０３  ネットワーク
１０４  マルチメディアコンテンツ通信システム
１０５  放送局
１０６  ケーブル
２０１  入力部
２０２  第１メモリ
２０３  第２メモリ
２０４  受信部
２０５  多重分離手段
２０６  デスクランブラ
２０７  ＴＳデコーダ
２０８  映像出力部
２０９  音声出力部
２１０  ＴＳマルチプレクサ
２１１  ネットワーク部
２１２  ＣＰＵ
２４０１  入力部
２４０２  第１メモリ
２４０３  第２メモリ
２４０４  多重分離手段
２４０５  ＴＳデコーダ
２４０６  映像出力部
２４０７  音声出力部
２４０８  ネットワーク部
２４０９  ＣＰＵ
【図１】
2010525616.tif 000005
【図２】
2010525616.tif 000006
【図３】
2010525616.tif 000007
【図４】
2010525616.tif 000008
【図５Ａ】
2010525616.tif 000009
【図５Ｂ】
2010525616.tif 000010
【図６】
2010525616.tif 000011
【図７】
2010525616.tif 000012
【図８Ａ】
2010525616.tif 000013
【図８Ｂ】
2010525616.tif 000014
【図８Ｃ】
2010525616.tif 000015
【図９】
2010525616.tif 000016
【図１０】
2010525616.tif 000017
【図１１】
2010525616.tif 000018
【図１２】
2010525616.tif 000019
【図１３】
2010525616.tif 000020
【図１４】
2010525616.tif 000021
【図１５Ａ】
2010525616.tif 000022
【図１５Ｂ】
2010525616.tif 000023
【図１６】
2010525616.tif 000024
【図１７Ａ】
2010525616.tif 000025
【図１７Ｂ】
2010525616.tif 000026
【図１８Ａ】
2010525616.tif 000027
【図１８Ｂ】
2010525616.tif 000028
【図１９】
2010525616.tif 000029
【図２０】
2010525616.tif 000030
【図２１】
2010525616.tif 000031
【図２２】
2010525616.tif 000032
【図２３Ａ】
2010525616.tif 000033
【図２３Ｂ】
2010525616.tif 000034
【図２４】
2010525616.tif 000035
【図２５】
2010525616.tif 000036
【図２６】
2010525616.tif 000037
【図２７】
2010525616.tif 000038
【図２８】
2010525616.tif 000039
【図２９】
2010525616.tif 000040
【図３０】
2010525616.tif 000041
【図３１】
2010525616.tif 000042
【図３２】
2010525616.tif 000043
【図３３Ａ】
2010525616.tif 000044
【図３３Ｂ】
2010525616.tif 000045
【図３４】
2010525616.tif 000046
【図３５Ａ】
2010525616.tif 000047
【図３５Ｂ】
2010525616.tif 000048
【図３６Ａ】
2010525616.tif 000049
【図３６Ｂ】
2010525616.tif 000050
【図３６Ｃ】
2010525616.tif 000051
【図３７】
2010525616.tif 000052
【図３８】
2010525616.tif 000053
【図３９】
2010525616.tif 000054
【図４０】
2010525616.tif 000055
【図４１】
2010525616.tif 000056
【図４２】
2010525616.tif 000057
【図４３】
2010525616.tif 000058
【図４４】
2010525616.tif 000059
【図４５】
2010525616.tif 000060
【図４６】
2010525616.tif 000061
【図４７】
2010525616.tif 000062
【図４８】
2010525616.tif 000063
【図４９】
2010525616.tif 000064
【図５０】
2010525616.tif 000065
【図５１】
2010525616.tif 000066
【図５２】
2010525616.tif 000067
【図５３】
2010525616.tif 000068
【図５４】
2010525616.tif 000069
【国際調査報告】
2010525616.tif 000070
2010525616.tif 000071
2010525616.tif 000072
2010525616.tif 000073
2010525616.tif 000074
2010525616.tif 000075