JP5542592B2 - セッションを告知する方法 - Google Patents

Description

本発明は、セッションを告知する方法、特に、限定はしないがマルチキャストネットワークを通じてマルチメディアサービスセッションを告知する方法に関するものである。

音声、映像、及び他の種類のデータは、多くの異なるプロトコルに従って様々な種類のネットワークを通じて送信することができる。例えば、データは、インターネットプロトコル（ＩＰ）及びユーザデータグラムプロトコル（ＵＤＰ）のようなインターネットプロトコルスイートのプロトコルを使用する通常「インターネット」と呼ばれるネットワークの集合を通じて送信することができる。
データは、多くの場合、単一のユーザにアドレス指定されたインターネットを通じて送信される。しかし、インターネットは、ユーザのグループにアドレス可能である。これは、「マルチキャスティング」として公知である。

データをマルチキャスティングする１つの方法は、ＩＰデータキャスティングネットワークを使用することである。このようなＩＰベースのブロードキャスティングネットワークを通じて、１つ又はそれ以上のサービスプロバイダは、オンライン新聞、ラジオ、テレビ、更に楽曲、映像、映画、ゲーム、及びソフトウエアのダウンロードを含む様々な種類のＩＰサービスを供給することができる。これらのＩＰサービスは、セッションに編成され、各セッションは、音声、映像、及び／又は他の種類のデータの形態の１つ又はそれ以上のメディアストリームを含む。

これらのセッションが発生する時間及び場所を判断するために、ユーザは、電子サービスガイド（ＥＳＧ）を参照する。ＤＶＢで使用される一例は、電子プログラムガイド（ＥＰＧ）である。電子サービスガイドは、通常は部分に分割されてユーザに送信される。
しかし、この手法はいくつかの欠点を有する。一方では、セッションのいずれかが更新される場合に、ユーザは、更新されたセッションの通知を受け取る前にサービスガイドの新しいバージョンが受信されるまで通常は待たなければならない。他方では、ほとんどのセッションは、通常は更新されない。従って、ユーザによって受信されるデータのほとんどが不必要である。これは、バッテリ給電式移動端末では供給不足になりがちな処理パワー及び電力の両方の点で無駄である。
本発明は、ネットワークを通じて送信されるセッションを告知する改良された方法を提供することを目標とするものである。

Ｍ．Ｐ．Ｍａｈｅｒ，Ｃ．Ｐｅｒｋｉｎｓ、及びＥ．Ｗｈｅｌａｎ著「セッション告知プロトコル」、ＲＦＣ２９７４、ＩＥＴＦ、２０００年１０月 Ｍ．Ｈａｎｄｌｅｙ及びＶ．Ｊａｃｏｂｓｏｎ著「セッション説明プロトコル」、ＲＦＣ２３２７、ＩＥＴＦ、１９９８年４月 Ｒ．Ｆｉｎｌａｙｓｏｎ著「ＳＤＰでのセッションディレクトリの説明」、インターネット草稿、ＩＥＴＦ、２００１年１月 Ａ．Ｓａｎｔｏｓ，Ｊ．Ｍａｃｅｄｏ、及びＶ．Ｆｒｅｉｔａｓ著「マルチキャストセッションディレクトリサービスに向けて」 映画テレビ技術者協会規格「ＳＭＰＴＥ３６４Ｍ−２００１」の「宣言データエッセンス−一方向ハイパーテキスト移送プロトコル」 拡張コンテント仕様「付録Ｃ：一方向ハイパーテキスト転送プロトコル（ＵＨＴＴＰ）」、高品位テレビ強化フォーラム Ｅ．Ｌｅｖｉｎｓｏｎ著「ＭＩＭＥマルチパート／関連コンテントタイプ」、ＲＦＣ２３８７、ＩＥＴＦ（１９９８） Ｍ．Ｌｕｂｙ，Ｊ．Ｇｅｍｍｅｌｌ，Ｌ．Ｖｉｃｉｓａｎｏ，Ｌ．Ｒｉｚｚｏ、及びＪ．Ｃｒｏｗｃｒｏｆｔ著「非同期層別符号化プロトコルのインスタンス化」、ＲＦＣ３４５０、ＩＥＴＦ、２００２年４月及び２００２年１２月 Ｂ．Ｗｈｅｔｔｅｎ、Ｌ．Ｖｉｃｉｓａｎｏ、Ｒ．Ｋｅｒｍｏｄｅ、Ｍ．Ｈａｎｄｌｅｙ、Ｓ．Ｆｌｏｙｄ、及びＭ．Ｌｕｂｙ著「一対多数のバルクデータ転送のための信頼できるマルチキャスト移送ビルディングブロック」、ＲＦＣ３０４８、ＩＥＴＦ、２００１年１月 Ｂ．Ｗｈｅｔｔｅｎ、Ｌ．Ｖｉｃｉｓａｎｏ、Ｌ．Ｒｉｚｚｏ、Ｍ．Ｈａｎｄｌｅｙ、Ｓ．Ｆｌｏｙｄ、及びＭ．Ｌｕｂｙ著「層別符号化移送ビルディングブロック」、インターネット草稿、ＩＥＴＦ、２００２年２月

本発明の第１の態様によると、ネットワークを通じて送信されるセッションを告知する方法が提供され、本方法は、複数のセッションを説明する告知の第１のセットを設ける段階と、少なくとも１つの更新されたセッションを説明する告知の第２のセットを設ける段階とを含む。
これは、複数のセッションを説明する告知の第１のセットを設けるか又はいくつかの更新されたセッションを説明する告知の第２のセットを設けるかを選択することができるという利点を有する。これによって、更新されたセッションは、より迅速かつ効率的に告知される。

更新されるセッションは、複数のセッションに加えられる新しいセッション、コンテントが追加、変更、又は削除される複数のセッションの１つ、又は複数のセッションから削除されるセッションとすることができる。
告知の第１セットを設ける段階と告知の第２セットを設ける段階は、第１チャンネルを通じて告知の第１セットを設ける段階と、第２の異なるチャンネルを通じて告知の第２セットを設ける段階とを含むことができる。
告知の第１セットを設ける段階と告知の第２セットを設ける段階は、それぞれ、第１アドレス、好ましくは第１マルチキャストＩＰアドレスのような宛先アドレスを通じて告知の第１セットを設ける段階と、第２の異なるアドレス、好ましくは宛先アドレス、例えば第２の異なるマルチキャストＩＰアドレスを通じて告知の第２セットを設ける段階とを含むことができる。

告知の第１セットを設ける段階と告知の第２セットを設ける段階は、それぞれ、第１ポート番号を通じて告知の第１セットを設ける段階と、第２の異なるポート番号を通じて告知の第２セットを設ける段階とを含むことができる。
告知の第１セットを設ける段階と告知の第２セットを設ける段階は、それぞれ、第１論理チャンネルを通じて告知の第１セットを設ける段階と、第２の異なる論理チャンネルを通じて告知の第２セットを設ける段階とを含むことができる。
告知の第１セットを設ける段階と告知の第２セットを設ける段階は、複数のセッションの１つを説明する告知として告知を識別するためのデータを第１セットの告知の各告知に含め、少なくとも１つの更新されたセッションの１つを説明する告知として告知を識別するためのデータを第２セットの告知の各告知に含める段階を含むことができる。

告知の第１セットを設ける段階と告知の第２セットを設ける段階は、セッションディレクトリの第一部分内の対応するセッションの位置を指定するためのそれぞれのデータを第１セットの告知の各告知に含め、セッションディレクトリの第２部分内の対応するセッションの位置を指定するためのそれぞれのデータを第２セットの告知の各告知に含める段階を含むことができる。
告知の第１セットを設ける段階と告知の第２セットを設ける段階は、それぞれ、第１物理チャンネルを通じて告知の第１セットを設ける段階と、第２の異なる物理チャンネルを通じて告知の第２セットを設ける段階とを含むことができる。
告知の第１セットを設ける段階と告知の第２セットを設ける段階は、それぞれ、第１ネットワークを通じて告知の第１セットを設ける段階と、第２の異なるネットワークを通じて告知の第２セットを設ける段階とを含むことができる。

本方法は、少なくとも１つの更新されたセッションを含む別の複数のセッションを説明する告知の第３セットを設ける段階を更に含むことができる。
本方法は、第１チャンネルを通じて告知の第１セットを設ける段階と、第２の異なるチャンネルを通じて、少なくとも１つの更新されたセッションを説明する告知の第２セットを設ける段階と、第１チャンネルを通じて、少なくとも１つの更新されたセッションを含む別の複数のセッションを説明する告知の第３セットを設ける段階とを含むことができる。

本方法は、告知の上述の第１セットを設ける段階の後に、告知の上述の第２セットを設ける段階を配置する段階を含むことができる。
本方法は、告知の上述の第１セットを設ける段階と告知の上述の第３セットを設ける段階とを実質的に重なった又は同じ時間中に配置する段階を含むことができる。
告知の第１セットを設ける段階と告知の第２セットを設ける段階は、第１チャンネルを通じて告知の第１セットを送信する段階と、第２の異なるチャンネルを通じて告知の第２セットを送信する段階とを含むことができる。

本方法は、セッション告知プロトコル（ＳＡＰ）、一方向ハイパーテキスト転送プロトコル（ＵＨＴＴＰ）、非同期層別符号化（ＡＬＣ）プロトコル、又はユーザデータグラムプロトコル（ＵＤＰ）に基づく類似の一方向プロトコルに従って告知の第１セットを送信する段階を含むことができる。本方法は、例えばセッション説明プロトコル（ＳＤＰ）に従って配置された各告知に、対応するセッションの説明を含める段階を含むことができる。
本方法は、例えば、一連の連結メッセージとして告知の第１セットを設けることにより、告知の第１セットの全てが設けられたか否かを判断するための手段を設ける段階を含むことができる。

本方法は、タイムスロットの第１セットに告知の第１セットを設ける段階と、タイムスロットの第２セットに告知の第２セットを設ける段階とを含むことができ、タイムスロットの第１セットの各タイムスロットは、タイムスロットの第２セットの各タイムスロットとは異なる時間で設けられる。本方法は、告知の第１及び第２セットを多重化する段階を含むことができる。
本方法は、少なくとも１つの更新されたセッションを識別する告知の第３セットを設ける段階を更に含むことができる。少なくとも１つの更新されたセッションを説明する告知の第２セットを設ける段階は、少なくとも１つの更新されたセッションを識別する告知のセットを設ける段階を含むことができる。少なくとも１つの更新されたセッションを説明する告知の第２セットを設ける段階は、対応するセッションの説明を含める段階を更に含むことができる。少なくとも１つの更新されたセッションを説明する告知の第２セットを設ける段階は、少なくとも１つの更新されたセッションを指す通知のセットを設ける段階を含むことができる。

本発明の別の態様によると、ネットワークを通じて送信されるセッションを告知する方法が提供され、本方法は、複数のセッションを説明する告知の第１セットを設ける段階と、少なくとも１つの更新されたセッションを識別する告知の第２セットを設ける段階とを含む。
本方法は、少なくとも１つの更新されたセッションを説明する告知の第３セットを設ける段階を更に含むことができる。本方法は、非同期層別符号化（ＡＬＣ）プロトコルに従って告知のセットの少なくとも１つを送信する段階を含むことができる。本方法は、非同期層別符号化（ＡＬＣ）プロトコルに基づくプロトコルに従って告知のセットの少なくとも１つを送信する段階を含むことができる。本方法は、非同期層別符号化（ＡＬＣ）プロトコルセッションを形成する段階と、少なくとも１つのＡＬＣチャンネルを形成する段階とを含むことができる。本方法は、第１ＡＬＣチャンネルを通じて複数のセッションを説明するためのメタデータのセットを送信する段階を含むことができる。本方法は、第２の異なるＡＬＣチャンネルを通じて少なくとも１つの更新されたセッションを説明するためのメタデータのセットを送信する段階を含むことができる。本方法は、第３の異なるＡＬＣチャンネルを通じて少なくとも１つの更新されたセッションを識別するためのメタデータのセットを送信する段階を含むことができる。本方法は、移送オブジェクトとしてメタデータのセットを送信する段階を含むことができる。本方法は、移送オブジェクトに関連するそれぞれの配信テーブルを形成する段階と、配信テーブルを送信する段階とを更に含むことができる。

本発明の第２の態様によると、データ処理装置によって実行される場合に、ネットワークを通じて送信されるセッションを告知する方法をデータ処理装置に実行させるコンピュータプログラムが提供される。
本発明の第３の態様によると、ネットワークを通じて送信されるセッションにアクセスする方法が提供され、本方法は、複数のセッションを説明する告知の第１セットを選択的に受信する段階と、少なくとも１つの更新されたセッションを説明する告知の第２セットを選択的に受信する段階とを含む。

本方法は、告知の上述の第１セットの全てを受信したか否かを判断する段階を更に含むことができる。本方法は、告知の上述の第１セットをそれ以上受信しないことを選択する段階と、告知の上述の第２セットを受信することを選択する段階とを更に含むことができる。本方法は、上述の少なくとも１つの更新されたセッションを含む別の複数のセッションを説明する告知の第３セットを受信しないことを選択する段階を更に含むことができる。本方法は、少なくとも１つの更に更新されたセッションを説明する告知の第４セットを受信することを選択する段階を更に含むことができる。
本方法は、上述の少なくとも１つの更新されたセッションを識別するために告知の第２セットを使用する段階を含むことができる。本方法は、上述の少なくとも１つの更新されたセッションの説明を含む告知の別のセットを受信することを選択する段階を含むことができる。本方法は、上述の少なくとも１つの更新されたセッションの説明を取得する段階を含むことができる。

本発明の別の態様によると、ネットワークを通じて送信されるセッションにアクセスする方法が提供され、本方法は、複数のセッションを説明する告知の第１セットを選択的に受信する段階と、少なくとも１つの更新されたセッションを識別する告知の第２セットを選択的に受信する段階とを含む。本方法は、上述の少なくとも１つの更新されたセッションを説明する告知の第３セットを選択的に受信する段階を更に含むことができる。

本発明の第４の態様によると、ネットワークを通じて送信されるセッションにアクセスする方法が提供され、本方法は、複数のセッションを説明する告知の第１セットを聴取する段階と、告知の上述の第１セットを受信したか否かを判断する段階と、告知の上述の第１セットを受信した場合には、告知の上述の第１セットを聴取することを停止する段階と、少なくとも１つの更新されたセッションを説明する告知の第２セットを聴取する段階とを含む。
本方法は、上述の少なくとも１つの更新されたセッションを含む更に別の複数のセッションを説明する告知の第３セットを聴取することを停止する段階を更に含むことができる。

本発明の第５の態様によると、ネットワークを通じて送信されるセッションを告知するための装置が提供され、この装置は、複数のセッションを説明する告知の第１セットを設けるための手段と、少なくとも１つの更新されたセッションを説明する告知の第２セットを設けるための手段とを含む。
本発明の第６の態様によると、本方法を実行するための装置が提供される。
本発明の第７の態様によると、ネットワークを通じて送信されるセッションを告知するための装置が提供され、この装置は、複数のセッションを説明する告知の第１セットを供給するための第１送信器と、少なくとも１つの更新されたセッションを説明する告知の第２セットを供給するための第２送信器とを含む。

この装置は、ネットワークを通じて送信されるセッションを告知するための電子サービスガイドを管理するための手段、ネットワークを通じて送信されるセッションのコンテントを管理するための手段、ネットワークを通じて送信されるセッションを告知するための電子サービスガイドを記憶するための手段、ネットワークを通じて送信されるセッションのコンテントを記憶するための手段、ネットワークを通じて送信される更新されたセッションに対応する、電子サービスガイドに対する変更を判断するための手段、ネットワークを通じて送信される更新されたセッションに対応する、電子サービスガイドに対する変更に関連する情報を提供するためのサーバ、コンテントを提供するためのサーバ、及び／又はデータを送信するための手段を含むことができる。

本発明の第８の態様によると、ネットワークを通じて送信されるセッションにアクセスするための装置が提供され、この装置は、複数のセッションを説明する告知の第１セットを選択的に受信するための手段と、少なくとも１つの更新されたセッションを説明する告知の第２セットを選択的に受信するための手段とを含む。
この装置は、告知の上述の第１セットを受信したか否かを判断するための手段を含むことができ、更に、判断する手段が告知の第１セットが受信されたと判断した場合に、告知の上述の第２セットを選択的に受信するための手段が告知の第２セットを受信するように構成されるように構成される。

この装置は、少なくとも１つの更新されたセッションを含む別の複数のセッションを説明する告知の第３セットを選択的に受信するための手段を含むことができ、更に、上述の判断する手段が告知の第１セットが受信されたと判断した場合に、告知の第３セットを選択的に受信するための手段が告知の第３セットを受信しないように又はこれを転送しないように構成されるように構成される。
この装置は、データを受信するための手段、ネットワークを通じて送信されるセッションを告知するための電子サービスガイドをフィルタリングするための手段、ネットワークを通じて送信されるセッションを告知するための電子サービスガイドを記憶するための手段、ネットワークを通じて送信されるセッションを告知するための電子サービスガイドを閲覧するための手段、コンテントをフィルタリングするための手段、コンテントを記憶するための手段、及び／又はコンテントを閲覧するための手段を含むことができる。
この装置は、手持ち式移動通信装置とすることができる。

本発明の第９の態様によると、ディスプレイ上にプログラムスケジュールデータを呈示するためのシステムが提供され、このシステムは、少なくとも２つの告知を含み、スケジュールデータは、少なくとも部分的に複数のセッションを少なくとも部分的に説明する告知の第１セットから、及び少なくとも部分的に少なくとも１つの少なくとも部分的に更新されたセッションを説明する告知の第２セットから編成される。

本発明の第１０の態様によると、ディスプレイ上にプログラムスケジュールデータを呈示するためのシステムが提供され、このシステムは、少なくとも２つの告知を含み、スケジュールデータは、少なくとも部分的に複数のセッションを説明する反復可能な告知の第１セットから、少なくとも部分的に少なくとも１つの少なくとも部分的に更新されたセッションを説明する反復可能な告知の第２セットから、及び第１及び第２告知の少なくとも１つが受信されるか否かを定義するための反復可能な告知のうちの少なくとも１つの少なくともセッション説明から編成される。

本発明の第１１の態様によると、プログラムスケジュールデータをエンドユーザ端末に配信するためのシステムが提供され、このシステムは、告知の２つのセットを含み、各セットは、少なくとも１つの告知を含み、スケジュールデータは、少なくとも部分的に複数のセッションを少なくとも部分的に説明する告知の第１セットから、及び少なくとも部分的に少なくとも１つの少なくとも部分的に更新されたセッションを説明する告知の第２セットから編成される。

本発明の第１２の態様によると、プログラムスケジュールデータをエンドユーザ端末に呈示するためのシステムが提供され、このシステムは、告知の少なくとも２つのセットを含み、各セットは、少なくとも１つの告知を含み、スケジュールデータは、少なくとも部分的に複数のセッションを説明する反復可能な告知の第１セットから、少なくとも部分的に少なくとも１つの少なくとも部分的に更新されたセッションを説明する反復可能な告知の第２セットから、及び第１及び第２告知の少なくとも１つが受信されるか否かを定義するための反復可能な告知のうちの少なくとも１つの少なくともセッション説明から編成される。

告知の第２セットは、クライアントが以前の更新を逃したかをクライアントが検出することを可能にするための各更新されたセッションのバージョン番号を含むことができる。クライアントが以前の更新を逃したことを検出し、現在告知の第１セットを受信していない場合には、クライアントは、プログラムスケジュールデータの完全な及び最新のバージョンを受信するまで告知の第１セットを受信することを開始することができる。クライアントがプログラムスケジュールデータの完全な及び最新のバージョンを受信したことを検出すると、それは、告知の第１セットの受信を中止することができ、告知の第２セットのみの受信を継続する。クライアントが以前の更新を逃したことを検出すると、対話形ネットワーク上でプログラムスケジュールデータの完全な及び最新バージョンを取り出すことができる。反復可能な告知の各セットは、送信前にセグメントに分割することができ、転送全体内の各セグメントの位置は、それぞれのセグメントの各々のフレーム指示フィールドに示すことができ、示された位置により、クライアントは、それが所定のセットを構成する全てのセグメントを受信したか否か、又はそれ以上のセグメントを受信するために待つ必要があるか否かを判断することができる。
プログラムスケジュールデータは、人間のエンドユーザによって直接見られるか、又はソフトウエアアプリケーションによって自動的に使用することができる。プログラムスケジュールデータは、人間のエンドユーザに漸次呈示されるか、又は上述のデータが受信されている時に自動ソフトウエアアプリケーションに対して漸次利用可能にすることができる。プログラムスケジュールデータは、グラフィカルユーザインタフェースを通じて人間のエンドユーザによって見ることができる。プログラムスケジュールデータは、パーソナルビデオレコーダによって使用することができる。
ここで、本発明の実施形態を添付図面に関連して例示的に以下に説明する。

マルチキャスティングシステム１の概略図である。 コンテントデータベースに記憶されたコンテントを示す図である。 セッションディレクトリを示す図である。 電子サービスガイドデータベースに記憶された電子サービスガイドデータを示す図である。 コンテントデータベースに記憶された更新されたコンテントを示す図である。 更新されたセッションディレクトリを示す図である。 電子サービスガイドデータベースに記憶された更新された電子サービスガイドデータを示す図である。 本発明による更新前のセッションディレクトリの第１の実施形態を示す図である。 本発明による更新後の図８に示すセッションディレクトリを示す図である。 本発明による更新前の電子サービスガイドデータを示す図である。 本発明による更新後の電子サービスガイドデータを示す図である。 本発明によるＳＡＰ及びＳＤＰプロトコルを使用するセッション告知メッセージを示す図である。 本発明による図１２に示すセッション告知メッセージを使用するセッションディレクトリの説明の送信を示す図である。 本発明によるデータキャストサービスシステムを作動する方法の処理流れ図である。 本発明によるデータキャストクライアントを作動する方法の処理流れ図である。 本発明による更新後のセッションディレクトリの第２の実施形態を示す図である。 本発明による電子サービスガイドデータをデータセグメントに分割する段階を示す図である。 本発明によるＵＤＰ及びＵＨＴＴＰプロトコルを使用する別のセッション告知メッセージを示す図である。 本発明による図１８に示すセッション告知メッセージを使用するセッションディレクトリの説明の送信を示す図である。 本発明による更新データの通知を示す図である。 本発明によるＵＤＰ及びＡＬＣプロトコルを使用する別のセッション告知メッセージを示す図である。 本発明によるＡＬＣチャンネルを使用する電子サービスガイドデータの送信を示す図である。 本発明による時分割多重方式を使用してセッション告知メッセージを使用するセッションディレクトリの説明の送信を示す図である。 本発明によるマルチキャストデータを受信するために使用される端末の概略図を示す図である。 本発明による電子サービスガイドブラウザを示す図である。

マルチキャスティングシステム１
図１を参照すると、マルチキャスティングシステム１が示されている。この実施例では、マルチキャスティングシステム１は、インターネットプロトコル（ＩＰ）データキャストシステムである。マルチキャスティングシステム１は、データキャストサービスシステム２、データキャスタ３、データキャストネットワーク４、及び複数のクライアント５を含むことができる。明確にするために、１つのクライアント５のみを示すものである。

管理者６は、クライアント５へのデータキャスティングのための音声、映像、及び／又は他の種類のデータのようなスケジュールされたコンテントを提供し、更にコンテントを説明するためのメタデータを提供する。メタデータは、コンテントの送信に関する情報を含む。
データキャストサービスシステム２は、クライアント５にデータキャストするためのコンテント項目と関連するメタデータを運ぶＩＰストリームを作成する。データキャスタ３は、データキャストサービスシステム２からのＩＰストリームを受信し、層２カプセル封入及び変調を提供し、更にデータキャストネットワーク４全体のクライアント５にＩＰデータを送信する。データキャストネットワーク４は、ＩＰベースのデータを配信するためのポイント・ツー・マルチポイントネットワークである。一般的に、データキャストネットワーク４は、クライアント５への複数の同時データキャストをサポートする。この実施例では、データキャストネットワーク４は、クライアント５からデータキャスタ３への戻りデータ経路を提供しない。データキャストネットワーク５は、例えば、デジタルビデオブロードキャスティング（ＤＶＢ）ネットワーク、デジタルオーディオブロードキャスティング（ＤＡＢ）ネットワーク、高度テレビジョンシステムコミティ（ＡＴＳＣ）ネットワーク、統合デジタルブロードキャスト（ＩＳＤＢ）ネットワーク、又は無線ローカルエリアネットワーク（ＷＬＡＮ）とすることができる。クライアント５は、データキャストネットワーク４によってコンテント及びコンテント説明を受信し、これをエンドユーザ７に呈示するための端末を含む。端末は、デスクトップパーソナルコンピュータ又はテレビのセットトップボックスのように固定にすることができ、又は、携帯用の例えばラップトップ又はノートブックパーソナルコンピュータ、パーソナル携帯端末、又はブロードキャスト送信を受信するための受信手段を有する携帯電話受話器とすることもできる。

データキャストサービスシステム２は、電子サービスガイド（ＥＳＧ）管理モジュール８、電子サービスガイドのメタデータを記憶するためのＥＳＧデータベース９、サービス発見サーバ１０、コンテント管理モジュール１１、データキャスティング用のコンテントを記憶するためのコンテントデータベース１２、及びコンテントサーバ１３を含む。
電子サービスガイド（ＥＳＧ）は、それらの送信スケジュールの指示と共に、例えばストリーミングメディア及びダウンロード可能ファイルのような利用可能なコンテントを説明するメタデータのセットである。単一ＥＳＧの完全な又は部分的なメタデータは、１つ又はそれ以上のチャンネルを含むことができるＥＳＧセッションで受信するクライアントに配信される。

ＥＳＧ管理モジュール８により、管理者６は、データキャストコンテントを説明するメタデータを管理することができる。コンテント項目は、ＩＰサービス及びＩＰセッションにグループ分けすることができる。コンテント項目は、送信のための割り当てられた（又は、割り当てを解除された）タイムスロットにすることができる。従って、メタデータは、ＩＰサービス及びＩＰセッションの階層としてコンテント項目の構造を説明するものである。また、メタデータは、ＩＰセッションの送信スケジュール及びＩＰセッション内の個々のコンテント項目の情報を含むことができる。

コンテント管理モジュール１１により、管理者６は、コンテントデータベース１２のコンテント項目を追加、置換、及び削除することができる。
サービス発見サーバ１０は、ＥＳＧデータベース９に見られるメタデータに基づくＩＰサービス及びＩＰセッションの告知を作成する。告知は、データキャストネットワーク４による送信のためのデータキャスタ３に送られる。告知は、カルーセル式に繰り返すことによって又は複数回送信することによって繰返し送信することができる。

以下に更に詳しく説明するように、２つの種類の告知が作成される。第１の種類の告知は、完全ＩＰサービスディレクトリを説明し、第２の種類の告知は、ＩＰサービスディレクトリへの更新を説明する。
本発明の一実施形態では、第２の種類の告知は、更新されたセッションディレクトリを送信するために使用される。
本発明の別の実施形態では、第２の種類の告知は、変更されたサービスディレクトリの部分の識別を含む。第２の種類の告知は、このような識別のみを含むことができる。告知のこのような第２の種類は、更新の通知として見なされる。更新の通知のみを含む第２の種類の告知は、更新を含む第２の種類の告知よりもより頻繁に送ることができる。第２の種類の告知は、更新の１つ又はそれ以上の通知と１つ又はそれ以上の更新の両方を含むことができ、これによって更新は、告知の時に利用可能な更新のセットから選択されることになる。

コンテントサーバ１３は、ＥＳＧデータベース９からスケジューリング情報を検索し、スケジューリング情報に基づいてコンテントデータベース１２からコンテントを検索し、これをデータキャストネットワーク４全体への送信のためのデータキャスタ３に送る。
クライアント５は、データキャスト受信器１４、サービス発見クライアント１５、電子サービスガイドのメタデータを記憶するためのＥＳＧデータベース１６、ＥＳＧブラウザ１７、コンテントフィルタリングアプリケーション１８、コンテントデータベース１９、及びコンテントブラウザ２０を含む。

データキャスト受信器１４は、データキャストネットワーク４上でデータを受信し、すぐにデータを復調してカプセル開放する。この場合、データキャスト受信器１４は、復調されかつカプセル開放されたデータをＩＰスタック（図示せず）に転送する。復調されかつカプセル開放されたデータは、コンテントストリーム又はコンテントを説明するメタデータを運ぶＩＰパケットを含む。ＩＰパケットは、スタック（図示せず）からクライアント５で実行するＩＰベースのアプリケーション１５及び１８に転送される。

サービス発見クライアント１５は、ＩＰサービス告知を運ぶための１つ又はそれ以上の所定のアドレス及び１つ又はそれ以上の所定のポートでＩＰパケットを受信する。以下に更に詳しく説明するように、サービス発見クライアント１５は、フルサービスディレクトリを説明する第１種類の告知を受信することができ、更に交互に又は付加的にサービスディレクトリへの更新を説明する第２種類の告知を受信することができる。ＩＰパケットは、ＥＳＧデータベース１６に記憶することができるか又はＥＳＧブラウザ１７に直接転送することができるメタデータを運ぶものである。

ＥＳＧデータベース１６は、サーバ側ＥＳＧデータベース９と非常に類似した情報構造を有する。ＥＳＧデータベース１６は、例えば、クライアント５が初めてオンに切り換えられる場合、最初は空であるが、ＩＰセッション告知がデータキャストサービスシステム２から受信される時に一杯になり更新される。
ＥＳＧブラウザ１７により、エンドユーザ７は、データキャストサービスシステム２から利用可能なＩＰサービス、セッション、及びコンテント項目のスケジュール及び説明を見ることができる。ＢＳＧブラウザ１７は、ＥＳＧデータベース１６からメタデータを検索することができ、又はサービス発見クライアント１５から直接メタデータを受信することができる。

コンテントフィルタリングアプリケーション１８は、コンテントブラウザ２０又はクライアントで実行される他のアプリケーションによって構成された１つ又はそれ以上の所定のアドレス及び１つ又はそれ以上の所定のポートでＩＰパケットを受信する。ＩＰパケットは、コンテントデータベース１９に記憶することができるか又はコンテントブラウザ２０に直接転送することができるコンテントを運ぶものである。

コンテントブラウザ２０は、エンドユーザ７が消費のための特定のデータキャストコンテント項目を選択した時にロードされて実行される。コンテント項目は、リアルタイムで受信することができ、又はコンテントデータベース１９から検索することができる。コンテントブラウザ２０は、例えば、ウェブブラウザ、ＭＰ３プレーヤ、又はストリーミングビデオクライアントとすることができる。
マルチキャスティングシステム１は、外部コンテントプロバイダ（図示せず）による自動コンテントアップローディング及びインターネットベースのコンテントの転送を可能にすることができる。また、データキャスタ３は、複数のデータキャストネットワーク（図示せず）にコンテントを配信することができ、各データキャストネットワークは、１つ又はそれ以上のトランスポンダを含んでいる。

本発明の実施形態では、１つ又はそれ以上のＥＳＧプロキシ（図示せず）が、データキャスタ３とクライアント４の間に設けられる。各ＥＳＧプロキシは、ＥＳＧメタデータ又はＥＳＧメタデータの一部、更新及び／又は更新の通知を受信及び送信することができる。各ＥＳＧプロキシは、１つ又はそれ以上のＥＳＧ送信側からの更新及び更新の通知を含むＥＳＧメタデータ又はその一部をフィルタリングすることができ、フィルタリングされたＥＳＧメタデータを１つ又はそれ以上のＥＳＧセッションに出力することができる。論理的に、ＥＳＧプロキシは、ＥＳＧ送信側と受信側の間に装着される。また、プロキシは、更新及び更新の通知を含むＥＳＧメタデータ又はメタデータの一部をキャッシュすることができ、出力上で独自の帯域幅制御又は輻輳制御方式を提供することができる。

セッション
図２を参照すると、コンテントデータベース１２に記憶され、第１、第２、第３、及び第４セッション２２₁、２２₂、２２₃、２３₄を含むコンテント２１が示されている。第１、第２、及び第３セッション２２₁、２２₂、２２₃は、サッカーに関するデータを含む。例えば、第１セッション２２₁は、ゲームに関するテキストを含むことができ、第２セッション２２₂は、ビデオストリーミングを含み、第３セッションは、音声ストリーミング２２₃を含むことができる。第４セッション２２₄は、ホッケーに関するデータを含む。セッション２２₁、２２₂、２２₃、２３₄は、単一のＩＰストリームか又は複数のＩＰストリームを含むことができる。

セッションディレクトリ
図３を参照すると、セッションディレクトリ２３が示されており、それに従って、セッション２２₁、２２₂、２２₃、２２₄が編成されている。セッションディレクトリ２３は、第１のレベルでポート２４₁のようなカテゴリを含む。カテゴリの更に別の例は、芸術、ビジネス、コンピュータ、ゲーム、ニュース及びショッピング、更にウェブポータルサイトに通常見られる他のカテゴリを含むものである。各カテゴリは、第２レベルでサッカー２５₁及びホッケー２５₂のようなサブカテゴリを含む。各サブカテゴリは、更に細分化することができる。例えば、サッカーサブカテゴリ２５₁は、サッカーリーグに分割することができ、その各々は、リーグ区分に分割することができ、更にその各々は、同様に選手に分割することができる。
各カテゴリ、サブカテゴリ、又は、更に別のサブカテゴリは、１つ又はそれ以上のセッションを含むことができる。例えば、サッカーサブカテゴリ２５₁は、第１、第２、及び第３セッション２２₁、２２₂、及び２２₃を含み、ホッケーサブカテゴリのカテゴリ２５₂は、第４セッション２２₄を含む。

図４を参照すると、ＥＳＧデータベース９に記憶されるＥＳＧデータ２６が示されている。電子サービスガイドデータ２６は、第１、第２、第３、及び第４セッション２２₁、２２₂、２２₃、及び２２₄を説明するためのメタデータの第１、第２、第３、及び第４セット２７₁、２７₂、２７₃、及び２７₄をそれぞれ含むものである。ＥＳＧデータ２６は、セッションディレクトリ２２の構造を反映するものである。
ＥＳＧデータ２６は、ユーザのためのＥＳＧを提供するようにクライアント５に送信される。しかし、ここで以下に説明するように、ＥＳＧデータ２６が更新される必要がある場合には問題が生じる。

図１、２、３、及び４を参照すると、最初にＥＳＧデータ２６がデータキャストサービスシステム２からクライアント５に送信される。データキャストサービスシステム２は、クライアント５に送信されるデータキャスタ３へのメタデータのセット２７₁、２７₂、２７₃、２７₄を送る。クライアント５は、メタデータのセット２７₁、２７₂、２７₃、２７₄の受信を開始し、最初は空のＥＳＧデータベース１６を満たし始める。時間と共にメタデータのセット２７₁、２７₂、２７₃、２７₄の全てが受信され、ＥＳＧデータベース１６に記憶される。この時点でＥＳＧは満たされている。

図５を参照すると、コンテントデータベース１２が更新され、対応する更新されたコンテント２１’が示されている。更新されたコンテント２１’は、更新されたセッション２２₁’及び新しいセッション２２₅を含む。例えば、第１セッション２２₁は、マッチプレビューをマッチレポートで置換することによって更新することができる。新しいセッション２２₅は、ホッケー定番リストを備えるテキストファイルとすることができる。
図６を参照すると、更新されたセッションディレクトリ２３’が示されており、更新されたセッション２２₁’と新しいセッション２２₅を含む。
図７を参照すると、メタデータの更新された第１セット２７’₁とメタデータの新しいセット２７₅を含む更新されたＥＳＧデータ２６’とが示されている。

図１、４、６、及び７を参照すると、更新されたＥＳＧデータ２６’は、データキャストサービスシステム２からクライアント５に送信される。データキャストサービスシステム２は、送信のためのデータキャスタ３に更新されたＥＳＧデータ２６’を送る。次に、クライアント５は、メタデータの更新されたセット２７₁’、２７₂、２７₃、２７₄、２７₅を受信する。しかし、クライアント５は、メタデータの各セット２７₁’、２７₂、２７₃、２７₄、２７₅が既存の又は更新されたデータに関するものか否かを知らない。従って、メタデータの各着信セット２７₁’、２７₂、２７₃、２７₄、２７₅は、更新されたデータセッションに関するものかを検査するために、メタデータの記憶されたセット２７₁、２７₂、２７₃、２７₄と比較される。このようにメタデータを処理することは無駄である。更に、更新される第１セッション２２₁と変更されるクライアント５の電子サービスガイドとの間に遅延が生じることになる。

従って、改良されたセッションディレクトリ及び改良されたＥＳＧを提供することが望ましい。
この問題への１つのソリューションは、セッションディレクトリを分割し、それに応じてＥＳＧの送信を分割することである。セッションディレクトリの説明は、更に詳しく説明するように、一方がフルセッションディレクトリを説明し、他方が更新されたセッションディレクトリを説明する２つの種類のセッション告知を送ることによって送信される。

セッションディレクトリの分割−第１の実施例
図８及び９を参照すると、それぞれ更新前及び更新後の本発明によるセッションディレクトリ２８及び２８’の第１の実施形態が示されている。
セッションディレクトリ２８及び２８’は、この実施例ではカテゴリレベルより上の比較的高いレベルで２つの部分に分割され、２つの部分は、それぞれ、フルセッションディレクトリ２９₁と更新されたセッションディレクトリ２９₂と呼ばれる。以下の第２の実施例で、比較的低いレベルで分割されるセッションディレクトリが説明される。

フルセッションディレクトリ２９₁は、スポーツ２４₁のような上述のものと実質的に同じカテゴリを含む。各カテゴリは、サッカー２５₁及びホッケー２５₂のようなサブカテゴリを含む。同様に、更に別のサブカテゴリも存在することができる。各カテゴリ、サブカテゴリ、又は任意の更に別のカテゴリは、１つ又はそれ以上のセッションを含むことができる。この場合、サッカーサブカテゴリ２５₁は、第１、第２、及び第３セッション２２₁、２２₂、及び２２₃を含み、ホッケーサブカテゴリ２５₂は、第４セッション２２₄を含む。

更新されたセッションディレクトリ２９₂はまた、スポーツ３０₁のようなフルセッションディレクトリのカテゴリに対応するカテゴリを含む。同様に、各対応するカテゴリは、サッカー３１₁及びホッケー３１₂のような対応するサブカテゴリを含む。同様に、対応する更に別のサブカテゴリも存在することができる。各対応するカテゴリ、対応するサブカテゴリ、又は任意の対応する更に別のサブカテゴリは、更新がある場合は１つ又はそれ以上の更新されたセッションを含むことができる。

更新の前に、更新されたセッションディレクトリ２９₂は、どのセッションも列挙しない。
更新の後に、更新されたディレクトリ２９₂は、更新されたセッションを列挙する。この場合、サッカーサブカテゴリ３１₁は、更新された第１セッション２２₁’を含み、ホッケーサブカテゴリのカテゴリ３１₂は、第５セッション２２₅を含む。

この構成は、２つの種類のセッション告知を送るために使用される。告知の１つの種類は、全てのセッションを説明するために使用される。告知の別の種類は、更新されたセッションを説明するために使用される。
従って、クライアントは、セッションの全ての説明、すなわち、フルセッションディレクトリを受信するように第１種類の告知を最初に聴取することができる。クライアントが全てのセッションの説明を受信した状態で、クライアントは、セッションへのいかなる更新も知るように、第２種類の告知のみを聴取することができる。

ＳＡＰ及びＳＤＰを使用するセッション告知
図１０及び１１を参照すると、更新前及び更新後の本発明によるＥＳＧデータ３２及び３２’の第１の実施例が示されている。
ＥＳＧデータ３２は、第１、第２、第３、及び第４セッション２２₁、２２₂、２２₃、及び２２₄をそれぞれ説明するためのメタデータの第１、第２、第３、及び第４セット３３₁、３３₂、３３₃、及び３３₄を含む。
更新されたＥＳＧ３２’は、更新された第１、第２、第３、第４、及び第５セッション２２₁’、２２₂、２２₃、２２₄、及び２２₅をそれぞれ説明するためのメタデータの更新された第１、第２、第３、第４、及び第５セット３３₁’、３３₂、３３₃、３３₄、及び３３₅を含む。

セッション告知プロトコル（ＳＡＰ）は、クライアント５へメタデータのセット３３₁、３３₁’、３３₂、３３₃、３３₄、３３₅を送信するために使用され、セッション説明プロトコル（ＳＤＰ）は、セッション２２₁、２２₁’、２２₂、２２₃、２２₄、２２₅を説明するために使用される。Ｍ．Ｐ．Ｍａｈｅｒ，Ｃ．Ｐｅｒｋｉｎｓ、及びＥ．Ｗｈｅｌａｎ著「セッション告知プロトコル」、ＲＦＣ２９７４、ＩＥＴＦ、２０００年１０月、及びＭ．Ｈａｎｄｌｅｙ及びＶ．Ｊａｃｏｂｓｏｎ著「セッション説明プロトコル」、ＲＦＣ２３２７、ＩＥＴＦ、１９９８年４月を参照されたい。

セッション告知プロトコル及びセッション説明プロトコルの使用は、クライアント５に送信されるセッションディレクトリの構造を説明する情報を有利に可能にするものである。Ｒ．Ｆｉｎｌａｙｓｏｎ著「ＳＤＰでのセッションディレクトリの説明」、インターネット草稿、ＩＥＴＦ、２００１年１月及びＡ．Ｓａｎｔｏｓ，Ｊ．Ｍａｃｅｄｏ、及びＶ．Ｆｒｅｉｔａｓ著「マルチキャストセッションディレクトリサービスに向けて」を参照されたい。

図１２を参照すると、本発明によるセッション告知３４の実施形態が示されている。セッション告知３４は、ＳＡＰヘッダ３５とセッションのＳＤＰ説明３６の形式でのペイロードを含む。ＳＤＰ説明３６は、セションを説明するためのメタデータのセット３３を含む。
図１３を参照すると、本発明の実施形態において、セッションディレクトリ２８の説明は、２つの種類のセッション告知３７₁及び３７₂を送ることによって送信され、各々は、セッションディレクトリを説明し、この場合はフルセッションディレクトリ２９₁と更新されたセッションディレクトリ２９₂をそれぞれ説明している。

セッション告知の第１種類３７₁は、全てのセッションの説明、すなわち、フルセッションディレクトリ２９₁を送るのに使用される。以前のサイクル３８₁の間、告知３４₁、３４₂、３４₃、３４₄は、更新前の全てのセッション２２₁、２２₂、２２₃、２２₄を説明し、以後のサイクル３８₂の間、告知３４₁’、３４₂、３４₃、３４₄、３４₅は、更新後の全てのセッション２２₁’、２２₂、２２₃、２２₄、２２₅を説明する。

告知の第２種類３７₂は、以前のサイクル３８₁の間の告知３４₁、３４₂、３４₃、３４₄の送信から追加されたり、取り除かれたり、又は変更されたセッションの説明を送るためだけに使用される。この実施例では、サイクルは、以前のサイクル３８₁に先行しない。従って、以前のサイクル３８₁の間、第２種類の告知３７₂はない。以後のサイクル３８₂の間、告知３４₁’及び３４₅は、更新されたセッション２２₁’及び２２₅を説明する（図９）。

通常、告知の２つのサイクル３８₁及び３８₂よりも多くのサイクルが存在することになる。更に、より多くのセッションを更新することができる。従って、次のサイクル（図示せず）の各々は、第２種類の告知３７₂を含むか又は含まないとすることができる。任意的に、第２種類の告知３７₂は、回復できない送信エラーに対して保護するためにサイクル中に繰返し送ることができる。
セッションディレクトリ２８の構造（図９）は、ＳＤＰ及びＳＡＰを使用するマルチキャストＩＰアドレスの階層を使用して説明することができる。

本発明によるセッションディレクトリ２８の構造を説明する方法の実施形態は、所定のマルチキャストアドレスで第１セッション告知を送信する段階を含む。第１セッション告知は、第２マルチキャストアドレスとセッションディレクトリに関する他の詳細とを含む。この方法は、第２マルチキャストアドレスで第２セッション告知を送信する段階を含む。第２セッション告知は、第３マルチキャストアドレスとセッションサブディレクトリに関する他の詳細とを含む。サブディレクトリは、同様にセッションディレクトリの次のレベルを告知するために使用することができるので、セッションディレクトリ階層は、どの深さのツリーとしても編成することができる。この実施例では、ルート又はデフォルトセッション告知（図示せず）が、第１及び第２種類の告知３７₁及び３７₂をそれぞれ受信するための一対のアドレスを指定する公知のアドレスで送信される。
１つ又はそれ以上の「カテゴリ」フィールドは、クライアント５にセッション告知をフィルタリングさせて編成させることのできるセッション告知に含むことができる。
上述のように、第１種類の告知３７₁は、「２２４．２．１７．０」のような第１のＩＰアドレス上で送信される。

図１３を参照すると、第１セッション告知３４₁は、例えば、以下を含む第１セッション２２₁のＳＤＰ説明３６を含むことができる。
ｖ＝０
ｏ＝ｊｓｍｉｔｈ ２８９０８４２８０７ ２８９０８４４５２５ ＩＮ ＩＰ４ １０．４７．１６．５
ｃ＝ＩＮ ＩＰ４ ２２４．２．１７．１２／１２７
ｔ＝２８９２０５４１２６ ２８９２３９９６８８
ｍ＝ｄａｔａ ９８７５ ＵＨＴＴＰ ＵＤＰ
ａ＝ｃａｔ：Ｆｕｌｌ．Ｓｐｏｒｔｓ．Ｓｏｃｃｅｒ

第１セッション告知３４₁が更新される場合、更新された第１セッション告知３４₁’は、例えば、以下を含む更新された第１セッション２２₁’のＳＤＰ説明３６を含むことができる。
ｖ＝０
ｏ＝ｊｓｍｉｔｈ ２８９０８４２８０７ ２８９０８４４５２６ ＩＮ ＩＰ４ １０．４７．１６．５
ｃ＝ＩＮ ＩＰ４ ２２４．２．１７．１２／１２７
ｔ＝２８９２０５４１２６ ２８９２３９９７２６
ｍ＝ｄａｔａ ９８７５ ＵＨＴＴＰ ＵＤＰ
ａ＝ｃａｔ：Ｆｕｌｌ．Ｓｐｏｒｔｓ．Ｓｏｃｃｅｒ

同様に、第２セッション告知３４₂は、例えば、以下を含む第２セッション２２₂のＳＤＰ説明３６を含むことができる。
ｖ＝０
ｏ＝ｊｓｍｉｔｈ ２８９０８４２８０７ ２８９０８４４５２６ ＩＮ ＩＰ４ １０．４７．１６．５
ｃ＝ＩＮ ＩＰ４ ２２４．２．１７．１３／１２７
ｔ＝２８９２０５４１２６ ２８９２３９９７２６
ｍ＝ｖｉｄｅｏ ９８７５ ＲＴＰ／ＡＶＰ ３１
ａ＝ｃａｔ：Ｆｕｌｌ．Ｓｐｏｒｔｓ．Ｓｏｃｃｅｒ
第２種類の告知３７₂は、「２２４．２．１７．１」のような第２のＩＰアドレス上で送信される。

図１３を更に参照すると、更新された第１セッション告知３４₁’は、例えば、以下を含む更新された第１セッション２２₁’のＳＤＰ説明３６（図９）を含むことができる。
ｖ＝０
ｏ＝ｊｓｍｉｔｈ ２８９０８４２８０７ ２８９０８４４５２６ ＩＮ ＩＰ４ １０．４７．１６．５
ｃ＝ＩＮ ＩＰ４ ２２４．２．１７．１２／１２７
ｔ＝２８９２０５４１２６ ２８９２３９９７２６
ｍ＝ｄａｔａ ９８７５ ＵＨＴＴＰ ＵＤＰ
ａ＝ｃａｔ：Ｕｐｄａｔｅ．Ｓｐｏｒｔｓ．Ｓｏｃｃｅｒ

更新されたセション２２₁’（図９）は、いくつかの方法で更新されたセッションとして識別することができる。
最初に、第１セッション告知３４₁と更新された第１セッション告知３４₁’は、「ｏ＝」フィールドで異なるバージョン番号を指定する、すなわち、第１及び更新された第１セッション告知３４₁及び３４₁’のバージョン番号を比較する段階と異なるバージョン番号を記録する段階とを含むことができる。
第２に、更新された第１セッション告知３４₁’は、更新されたセッションに関連する告知のために確保された、この場合は異なるＩＰアドレスである異なるチャンネルを通じて設けられる。従って、更新されたセッションを識別する段階は、異なるチャンネルで告知を受信する段階を含むことができる。
第３に、更新された第１セッション告知３４₁’は、セッション告知が更新に関連するという事実を識別するカテゴリフィールドを含む。従って、更新されたセションを識別する段階は、更新に関連するとして告知がそれ自体を識別するか否かを判断する段階、及び／又はセッションディレクトリ内の位置を判断する段階を含むことができる。

データキャストサービスシステム２を作動する方法
図１及び１４を参照すると、本発明によるデータキャストサービスシステム２を作動する方法の実施形態が示されている。
ＥＳＧ管理モジュール８は、セッションがコンテントデータベース１２で更新されたか否かを識別する（段階Ｓ１）。ＥＳＧ管理モジュールがいずれかの更新されたセッションを識別する場合、モジュールは、ＥＳＧデータベースのメタデータの対応するセットを更新する（段階Ｓ２）。更新は、メタデータの追加又は削除を含むことができる。メタデータは、サービス発見サーバ１０に渡され、メタデータの任意の更新されたセットのための更新されたセッション告知を作成する（段階Ｓ３）。サービス発見サーバ１０は、複数のセッションを説明する告知の第１セット、言い換えるとフルセッション告知と、少なくとも１つの更新されたセッションを説明する告知の第２セット、言い換えると更新されたセッション告知とを異なるＩＰアドレスのような異なるチャンネルを通じてデータキャスタ３に転送する（段階Ｓ４及びＳ５）。データキャスタ３は告知を受信し、これらをデータキャストネットワーク４によって各クライアント５に送信する。

クライアント５を作動する方法
図１及び１５を参照すると、本発明によるクライアント５を作動する方法の実施形態が示されている。
クライアント５は、第１種類のセッション告知３７₁の全てを受信したか否かを検査する（段階Ｔ１）。受信していない場合、クライアント５は、告知の両方の種類３７₁及び３７₂を聴取する（段階Ｔ１及びＴ２）。しかし、クライアント５が第１種類のセッション告知３７₁の全てを受信した場合には、次に、クライアントは、第１種類の告知３７₁を聴取することを停止し、第２種類の告知３７₂だけを聴取し続けることができる。これは、より少ないセッション告知のみが受信及び／又は処理されるので、処理パワー及び電力を節約するという利点を有する。

告知の第１及び第２種類３７₁及び３７₂は、他のセッションディレクトリに関連する告知のマルチキャストアドレスを含むことができ、同様に、更に別のセッションディレクトリに関連する告知のマルチキャストアドレスを含むこともできる。
第１種類の告知３７₁は、ディレクトリ階層の所定の深さまでのサブディレクトリを含むセッションディレクトリに関連するものと見なされる。第２種類の告知３７₂も、同様にディレクトリ階層の所定の深さまでのサブディレクトリを含むセッションディレクトリに関連するものと見なされる。いずれかの種類の告知３７₁及び３７₂が１つよりも多いセッションディレクトリに関連する場合、これらは、ＩＰセッション階層の異なるサブツリーの詳細を告知するために使用することができる。従って、複数のサブディレクトリの説明が第１種類の告知３７₁を使用して送信される場合、クライアント５は、特定のサブディレクトリの異なるセッション説明の全てが受信されるとすぐに、そのサブディレクトリに関連する告知の受信を中止することができる。

セッションディレクトリの分割−第２の実施例
図１６を参照すると、本発明によるセッションディレクトリ２８”の第２の実施形態が示されている。セッションディレクトリ２８”は、この実施例ではセッションレベルより上の比較的低いレベルで２つの部分に分割され、その２つの部分は、それぞれ、フルセッションディレクトリ２９_1a及び２９_1bと更新されたセッションディレクトリ２９_2a及び２９_2bと呼ばれる。
ＥＳＧデータ３２及び更新されたＥＳＧデータ３２’は、本発明によるセッションディレクトリ２８”の第２の実施形態の構造を反映するように修正される。

ＵＨＴＴＰを使用するセッション告知
ＳＡＰ及びＳＤＰを利用するセッション告知を使用する欠点は、フルセッションディレクトリ２９₁を説明するのに十分な第１種類の告知３７₁を受信した時間をクライアント５が確立するのが困難であるということである。告知３４₁’、３４₂、３４₃、３４₄、３４₅は失われるか又は壊れ、これらのプロトコルではこのようなイベントを検出できない。
代替的な実施形態では、この問題は、フルセッションディレクトリ２９₁を説明するセッション告知を互いに連結することによって解決される。

一方向ハイパーテキスト転送プロトコル（ＵＨＴＴＰ）は、複数セッション説明の連結転送を実行するために使用され、映画テレビ技術者協会規格「ＳＭＰＴＥ３６４Ｍ−２００１」の「宣言データエッセンス−一方向ハイパーテキスト移送プロトコル」及び拡張コンテント仕様「付録Ｃ：一方向ハイパーテキスト転送プロトコル（ＵＨＴＴＰ）」、高品位テレビ強化フォーラムを参照されたい。
ＵＨＴＴＰは、単一のＵＨＴＴＰ転送が複数の独立ＭＩＭＥオブジェクトを含むことができるようにするＭＩＭＥマルチパート／関連コンテントタイププロトコルをサポートし、これに関して、Ｅ．Ｌｅｖｉｎｓｏｎ著「ＭＩＭＥマルチパート／関連コンテントタイプ」、ＲＦＣ２３８７、ＩＥＴＦ（１９９８）を参照されたい。

図１７を参照すると、ＥＳＧデータ３２は、複数のデータセグメント４０₁、４０₂、４０₃に分割することができる単一のリソース３９と考えられる。この実施例では、メタデータのセットよりも少ないデータセグメントがある。しかし、データセグメントの数は、メタデータのセットの数に等しいか又はそれ以上とすることができる。冗長なエラー修正セグメント（図示せず）が計算され、データセグメント４０₁、４０₂、４０₃にインターリーブされる。更新された電子サービスガイドデータ３２’も同様に処理される。
図１８を参照すると、ＵＤＰヘッダ４２とＵＤＰペイロード４３とを含むユーザデータグラムプロトコル（ＵＤＰ）パケット４１が示されている。ＵＤＰペイロード４３は、ペイロードとしてＵＨＴＴＰヘッダ４５とデータセグメント４０₁、４０₂、４０₃とを含むＵＨＴＴＰパケット４４を含む。ＵＨＴＴＰによって各データセグメント４０₁、４０₂、４０₃に番号を付けることができる。

図１９を参照すると、ＥＳＧデータ３２は、連結された転送として送信され、更新されたＥＳＧデータ３２’も連結された転送として送信される。ＥＳＧデータ３２では、第１、第２、及び第３ＵＤＰパケット４１₁、４１₂、及び４１₃が送信される。同様に、更新されたＥＳＧ３２’では、第４、第５、及び第６ＵＤＰパケット４１₄、４１₅、及び４１₆が送信される。各々の場合において、１つ又はそれ以上のＵＤＰパケット４１₁、４１₂、４１₃、４１₄、４１₅、４１₆の送信が失敗するか又はそれに包含されたデータセグメントの検索が失敗した場合は、対応するＵＤＰパケット４１₁、４１₂、４１₃、４１₄、４１₅、４１₆が再送信される。
更新されたセッションの説明は、第７ＵＤＰパケット４１₇で送信される。

上述のように、デフォルトセッション告知は、完全な及び更新されたセッションディレクトリ２９₁及び２９₂の詳細を提供するために使用することができる。デフォルトセッション告知の例は、以下を含むことができる。
ｖ＝０
ｏ＝ｄｃａｓｔｅｒ ４２８９０９８０９８ ４２８９０９９１２５ ＩＮ ＩＰ４ １３０．２３０．３．２
ｓ＝Ｅｘｐｅｒｉｍｅｎｔａｌ ｓｅｓｓｉｏｎ ｄｉｒｅｃｔｏｒｙ ｓｅｒｖｉｃｅ
ｉ＝Ｆｕｌｌ ａｎｄ ｕｐｄａｔｅ ｓｅｓｓｉｏｎ ｄｉｒｅｃｔｏｒｉｅｓ ｄｅｌｉｖｅｒｅｄ ｖｉａ ＵＨＴＴＰ
ｕ＝ｈｔｔｐ：／／ｗｗｗ．ｄａｔａｃａｓｔｅｒ．ｃｏｍ
ｅ＝ｄｃａｓｔｅｒ＠ｄａｔａｃａｓｔｅｒ．ｃｏｍ
ｃ＝ＩＮ ＩＰ４ ２２４．２．１７．１２／１２７
ｔ＝２８７３３９７４９６ ２８７３４０４６９６
ｍ＝ｄａｔａ ４２４５１ ｕｄｐ ｕｈｔｔｐ
ａ＝Ｘ−ｓｅｓｓｉｏｎ−ｄｉｒｅｃｔｏｒｙ−ｆｕｌｌ
ｍ＝ｄａｔａ ４２４５２ ｕｄｐ ｕｈｔｔｐ
ａ＝Ｘ−ｓｅｓｓｉｏｎ−ｄｉｒｅｃｔｏｒｙ−ｕｐｄａｔｅｓ

この実施例では、フルセッション告知及び更新されたセッション告知が異なるポート番号で提供される。また、この実施例では、ＵＨＴＴＰがフルセッション告知及び更新されたセッション告知で使用される。しかし、ＵＨＴＴＰは、フルセッション告知のために使用することができ、ＳＡＰ及びＳＤＰは、更新されたセッション告知のために今まで通り使用することができる。
データセグメント４０₁、４０₂、４０₃の付番により、クライアント５は、これらがＥＳＧデータ３２を受信した時間を検出することができる。これが起こった状態で、クライアント５は更新を聴取する。

ＵＨＴＴＰの使用は別の利点を有する。これは、ビット及びバーストエラーが送信で起こる場合でさえも正常な送信の可能性を増すために使用することができる前方エラー補正（ＦＥＣ）をサポートする。しかし、ＦＥＣがクライアントエンドでのいずれかのエラーの回復に失敗した場合には、クライアント５は、定期的なＵＨＴＴＰ再送信を待つことになる。代替的に、戻り経路が設けられている場合には、自動反復要求（ＡＲＱ）を使用することができる。
コンテントの信頼できる配信を提供する他のプロトコルを使用することもできる。

非同期層別符号化（ＡＬＣ）又はＡＬＣに基づくプロトコルは、コンテントの信頼できる配信を提供し、完全な又は部分的なＥＳＧメタデータ、更新、及び更新の通知を配信するために使用することができる。
非同期層別符号化（ＡＬＣ）は、ＩＰマルチキャスティングのための拡張可能な信頼できるコンテント配信プロトコルであり、これに関して、Ｍ．Ｌｕｂｙ，Ｊ．Ｇｅｍｍｅｌｌ，Ｌ．Ｖｉｃｉｓａｎｏ，Ｌ．Ｒｉｚｚｏ、及びＪ．Ｃｒｏｗｃｒｏｆｔ著「非同期層別符号化プロトコルのインスタンス化」、ＲＦＣ３４５０、ＩＥＴＦ、２００２年４月及び２００２年１２月を参照されたい。
また、Ｂ．Ｗｈｅｔｔｅｎ、Ｌ．Ｖｉｃｉｓａｎｏ、Ｒ．Ｋｅｒｍｏｄｅ、Ｍ．Ｈａｎｄｌｅｙ、Ｓ．Ｆｌｏｙｄ、及びＭ．Ｌｕｂｙ著「一対多数のバルクデータ転送のための信頼できるマルチキャスト移送ビルディングブロック」、ＲＦＣ３０４８、ＩＥＴＦ、２００１年１月を参照されたい。
また、Ｂ．Ｗｈｅｔｔｅｎ、Ｌ．Ｖｉｃｉｓａｎｏ、Ｌ．Ｒｉｚｚｏ、Ｍ．Ｈａｎｄｌｅｙ、Ｓ．Ｆｌｏｙｄ、及びＭ．Ｌｕｂｙ著「層別符号化移送ビルディングブロック」、インターネット草稿、ＩＥＴＦ、２００２年２月を参照されたい。

ＡＬＣベースプロトコルを使用するセッション告知、更新、及び更新の通知
ＡＬＣは、ファイルのようなバイナリオブジェクトのための一方向移送サービスを提供する。ＡＬＣは、層別符号化移送（ＬＣＴ）の信頼できるマルチキャストプロトコルビルディングブロックに基づいて、１つ又はそれ以上の層別チャンネルを含むセッションのＬＣＴ概念を受け継ぐものである。
ＡＬＣ／ＬＣＴセッションは、１つ又はそれ以上のオブジェクトのためのＡＬＣ／ＬＣＴヘッダを有する単一発信者搬送パケットに関連する論理的にグループ分けされたチャンネルのセットから成るものである。完全な又は部分的なＥＳＧの配信、更新、及び更新の通知では、ＡＬＣプロトコルに基づくプロトコルが使用される。従って、１つ又はそれ以上のＥＳＧチャンネルを含むＥＳＧセッションを形成することができる。各ＥＳＧチャンネルは、ＡＬＣセッションに対応するものである。

上述のように、ＡＬＣセッションは、１つ又はそれ以上のＡＬＣチャンネルを含む。各ＡＬＣチャンネルは、ＡＬＣプロトコルに従ってパケットを転送するための「ビットパイプ」と考えられる。ＡＬＣセッションの準備のために、発信者は、いくつかのＡＬＣチャンネルを選択し、その各々について対応するビットレートを選択する。ＡＬＣセッションの各受信者は、ＡＬＣチャンネルの全て又はそのいくつかだけを受信することを選択することにより、受信ビットレートを制御することができる。

ＡＬＣチャンネルは、一対の変数（Ｓ，Ｇ）によって一意的に定義可能であり、かつ認識可能である。Ｓは、発信者のＩＰユニキャストアドレスであり、Ｇは、マルチキャスト受信グループに対するマルチキャストＩＰアドレスである。Ｇはまた、ユニキャストＩＰアドレスとすることができるが、「ＲＦＣ ３４５０」は、ユニキャストの使用を定めていない。
ＡＬＣセッションは、一対の変数（Ｓ，ＴＳＩ）によって一意的に定義可能であり、かつ認識可能である。Ｓは、発信者のユニキャストＩＰアドレスであり、ＴＳＩは、各ＡＬＣパケット４７のヘッダでの移送セッション識別子フィールドの値である（図２１）。

ＡＬＣ又はＡＬＣベースのプロトコルを使用して、少なくとも１つのＥＳＧチャンネルを含むＥＳＧセッションが形成される。ＥＳＧセッションは、３つのＥＳＧチャンネル、すなわち、完全な又は部分的なＥＳＧを配信するための１つのチャンネル、更新を配信するための１つのチャンネル、及び更新を通知するための１つのチャンネルを含むのが好ましい。
それぞれのＥＳＧチャンネルの各々は、移送セッション識別子（ＴＳＩ）フィールドで同じ値を有するデータパケットを運ぶ。同じチャンネルのデータパケットは、同じソースポート及びＩＰアドレスから送られ、異なる宛先ポート及び／又はＩＰアドレスにアドレス指定される。

ＥＳＧセッションは、完全ＥＳＧチャンネル、ＥＳＧ更新チャンネル、及びＥＳＧ通知チャンネルを含むことができる。
完全ＥＳＧチャンネルは、発信者の完全な又は部分的なＥＳＧメタデータセットを説明するＥＳＧメタデータセットを繰返し配信するものである。部分的なＥＳＧだけが配信される場合は、クライアントには、ポイントツーポイントＥＳＧ移送プロトコルのような異なるプロトコルによって完全ＥＳＧへのアクセスがもたらされる。
更新ＥＳＧチャンネルは、完全ＥＳＧの現在のバージョンが作成されてから変わった発信者のＥＳＧの部分を含むＥＳＧメタデータセットを繰返し配信する。
通知ＥＳＧチャンネルは、完全ＥＳＧの最新バージョンが構築されてから変わった発信者のＥＳＧの部分へのポインタから成るメタデータセットを繰返し配信する。このポインタは、変わった部分を識別するメタデータセット内のデータフィールドである。

ＥＳＧチャンネルの各々は、同様に１つ又はそれ以上のＡＬＣチャンネルを含むことができる。ＥＳＧチャンネルを構成する全てのＡＬＣチャンネルは、連続したＩＰアドレスで送られる。各ＥＳＧチャンネルのために使用されるベースＩＰアドレスだけを受信者に信号で知らせる必要がある。これは、輻輳制御指示フィールドでの「ネクストフラグ」により、受信者が現在のＥＳＧチャンネルに対して使用したかもしれない次のＩＰアドレスを発見することができるからである。
対話形ネットワーク接続を有するＥＳＧ受信者は、受信する必要があるＥＳＧメタデータの種類及びネットワークの輻輳状態に応じて、移送チャンネルに加わりかつ離れることができる。一方向ネットワーク接続性だけを有するＥＳＧ受信者はより制約されているが、依然として不必要な移送チャンネルをフィルタリングして除く任意選択肢を有する。更に、ＥＳＧプロキシ（図示せず）のようなネットワーク要素は、例えば、輻輳がこのようなリンクの送出部で検出される場合に、一方向リンクに転送される移送チャンネルの数を低減することができる。

図２０を参照すると、更新されたＥＳＧ３２’のためのメタデータのセット３３３₁’、３３₂、３３₃、３３₄、３３₅（図１１）が準備される場合、更新の通知のためのメタデータのセット４５も準備される。メタデータセット４５は、いずれかの更新されたセッション２２₁’及び２２₅へのポインタを含む（図９）。任意的に、メタデータセット４５は、複数のデータセグメント４６₁及び４６₂に分割することができる。
図２１を参照すると、メタデータセット又はデータセグメントを配信するためのパケット４７が示されている。パケット４７は、ＵＤＰ又はＡＬＣパケットと実質的に同じであり、１つ又はそれ以上のヘッダ、１つ又はそれ以上のペイロードデータフィールド、及び他のデータフィールドを含むことができることが好ましい。ＵＤＰヘッダのような標準ヘッダフォーマットを使用することもできる。

この実施例では、少なくともメタデータセット３３及び４５又はデータセグメント４６₁及び４６₂を含むＵＤＰヘッダ４８、ＬＣＴヘッダ４９、ＦＥＣペイロードＩＤフィールド５０、及びペイロード５１を含むＡＬＣパケット４７について説明する。
これらの間に、ヘッダ、好ましくは、ＬＣＴヘッダ４９は、バージョン番号フィールドを含むいくつかのフィールド（図示せず）と、輻輳制御フラグ、移送セッション識別子フラグ、移送オブジェクト識別子フラグ、ハーフワードフラグ、送信側現在時刻表示フラグ、予想残り時間表示フラグ、クローズセッションフラグ、及びクローズオブジェクトフラグを含むいくつかのフラグ（図示せず）とを含むことができる。将来の使用のために確保される更に別のデータフィールドを含めることもできる。

移送セッション識別子フラグは、移送セッション識別子に使用されたフィールドフォーマットを識別する。移送オブジェクト識別子フラグは、移送オブジェクト識別子に使用されたフィールドフォーマットを示す。送信側現在時刻表示フラグは、送信側現在時刻フィールドの有無を示す。予想残り時間表示フラグは、予想残り時間フィールドの有無を示す。クローズセッションフラグは、セッションの終了を示し、クローズオブジェクトフラグは、オブジェクトの送信の終了を示すものである。
これらの間に、ヘッダ、好ましくは、ＬＣＴヘッダ４９は、ヘッダ及び／又はパケットの１つ又はそれ以上の長さを示すいくつかのフィールド（図示せず）、輻輳制御に関連する情報を有するいくつかのフィールド（図示せず）、及び移送セッション及び移送オブジェクトを識別するための１つ又はそれ以上の識別子を含む１つ又はそれ以上のフィールド（図示せず）を含む。

更に別のデータフィールド（図示せず）は、例えば、ＡＬＣ符号化記号及び可能なヘッダ拡張子に関連する情報を有することができる。更に別のデータフィールド（図示せず）は、使用される前方エラー補正（ＦＥＣ）方式の情報を含むことができる。ＦＥＣデータは、ペイロードデータから作成され、更にこれにインターリーブされる冗長な情報である。ＦＥＣの使用により、受信側は、送信エラーによって失われたか又は損傷を受けたペイロードデータセグメントを再構成することができる。
これらの間で、ヘッダ、好ましくは、ＦＥＣペイロードＩＤフィールド５０は、ソースブロック番号（図示せず）と符号化記号ＩＤ（図示せず）とを含む。
ソースブロック番号は、ペイロード５１の符号化記号がオブジェクトのどのソースブロックから発生するかを示すものである。また、符号化記号ＩＤは、ソースブロックから発生したどの特定の符号化記号がペイロード５１で運ばれるかを識別するものである。

ＡＬＣに基づくプロトコルが使用される場合、ＡＬＣプロトコルインスタンス化に特定のヘッダ拡張子（図示せず）は、各移送オブジェクトの配信に少なくとも一度は含まれる。ヘッダ拡張子でのＦＥＣオブジェクト送信情報により、受信側は、関連する移送オブジェクトを配信するために使用されたバンド内のＦＥＣパラメータを発見することができる。
ヘッダ拡張子（図示せず）は、ヘッダ拡張子の種類、ヘッダ拡張子の長さ、使用されるＦＥＣ符号器の識別、オブジェクトの転送の長さ、パケットペイロードで運ばれた現在の移送オブジェクトのソースブロック毎のソースブロック長、パケットペイロードで運ばれた現在の移送オブジェクトの符号化記号毎の長さのような１つ又はそれ以上のフィールドを含む。更に、ヘッダ拡張子は、将来の使用のために確保される１つ又はそれ以上のフィールドを含むことができる。

輻輳制御フィールド内の情報は、指示フラグを含むことができ、その値の一連番号は、各パケットが送られる毎に１つずつ増加され、それは、パケット損失及び将来の使用のために確保された部分を検出するために受信側によって使用することができる。
指示フラグが「１」に設定される場合、それは、現在のＡＬＣセッションが現在のＩＰアドレスと次に続くＩＰアドレスとを含む２つ又はそれ以上のＡＬＣチャンネルから成ることを示すものである。このフィールドでの「０」の値は、現在のＩＰアドレスが現在のＡＬＣセッションでの最も高いＩＰアドレスであることを示すものである。受信側は、ＥＳＧ送信側によるＡＬＣチャンネルの動的な追加又は削除を検出するためにこのフィールドをモニタすることができる。
ＡＬＣパケットフォーマットに関連する更なる詳細は、前出の「ＲＦＣ ３４５０」の「非同期層別符号化プロトコルインスタンス化」に見出すことができる。

本発明の実施形態では、告知は、バイナリオブジェクトと見なすことができ、従って、移送オブジェクトと呼ぶことができる。各移送オブジェクトは、移送オブジェクト識別子フィールド（図示せず）の値によって識別され、この値は、１つの移送セッションの範囲内で一意的なものである。各ＥＳＧメタデータセットは、別々の移送オブジェクトとして送られるのが好ましい。
各移送オブジェクトでは、付加的な情報は、ＥＳＧ配信テーブル（図示せず）の形式で形成することができる。送信側では、ＥＳＧ配信テーブルを移送セッション毎に挿入することができる。受信側では、ＥＳＧ配信テーブル情報構文解析を提供することができる。

移送セッション内の各種類の移送チャンネルに対して、異なる配信テーブルを送信することができる。
ＥＳＧ配信テーブル（図示せず）は、マッピングの各々が移送オブジェクト識別子値及び移送オブジェクトの特性を含むマッピングのセットとして形成することができる。ＥＳＧ配信テーブルは、２つの部分、すなわち、ＥＳＧヘッダとＥＳＧペイロードを含むことができる。
ＥＳＧ配信テーブルヘッダは、ヘッダ拡張子の種類、ヘッダ拡張子の長さ、ＥＳＧ配信テーブルバージョン、及びＥＳＧ配信テーブル失効のフィールドを含む。

ＥＳＧヘッダ拡張子は、可変長プロトコルインスタンス化特定のヘッダ拡張子であり、これは、全てのパケット搬送ＥＳＧ配信テーブルに含まれており、ＥＳＧ配信テーブルの同じバージョンを運ぶ全てのパケットで同一である。ＥＳＧ配信テーブルバージョンは、現在送信されているＥＳＧ配信テーブルの番号である。このフィールドは、新しいＡＬＣ移送セッションのＥＳＧ配信テーブルに対して「０」の値を有し、更新されたＥＳＧ配信テーブルが同じＡＬＣ移送セッションのために構築される時はいつでも１つずつ増加される。所定の最大値に達した後は、バージョン番号は終了して「０」に戻る。ＥＳＧ配信テーブル失効は時間値であり、その後はＥＳＧ配信テーブルが有効であると期待されない時間を示すものである。ＥＳＧ配信テーブルの新しいバージョンは、現在のバージョンの失効時間前に送られるのが好ましい。しかし、受信側は、新しいバージョンを受信しなかった場合には、その失効時間後でもＥＳＧ配信テーブルの現在のバージョンを使用し続けなければならない。

ＥＳＧペイロードは、移送オブジェクト識別子と各移送オブジェクト識別子によって識別された移送オブジェクトに関連する属性との間の実際のマッピングを包含する。ＥＳＧペイロードフォーマットは、例えば、現在のＡＬＣ移送セッション内の移送オブジェクトの固有の識別子、現在の移送オブジェクトと移送オブジェクトのバイトの長さと移送オブジェクトのＭＩＭＥ種類とを一意的に識別するためのＵＲＬ、ＺＬＩＢ圧縮のような移送オブジェクトに使用される符号化のための識別子、及び移送オブジェクトに対するＭＤ５チェックサムのような１つ又はそれ以上のフィールドを含む、ＡＳＣＩＩテキストとして表されたＸＭＬ構造とすることができる。ＥＳＧペイロードフィールドは、「ＨＴＴＰ １．１」仕様に定められた対応するフィールドの構文及びセマンティクスを使用することができる。

図２３を参照すると、告知の第１セット３７₁として完全ＥＳＧの配信、告知の第２セット３７₂として更新されたＥＳＧの配信、及び告知の第３セット３７₃として更新の通知の配信が示されている。
上述のように、更新の通知を含む告知は、更新を含む告知よりも頻繁に送ることができる。
データキャストクライアント５は、更新を含む告知よりはむしろ更新の通知を含む告知を聴取することを選択することができる。ユーザが関心のあるセッションへの更新の通知を受信する場合、データキャストクライアント５は、更新を含む告知を聴取することができ、及び／又はユニキャストによるなどの別の方法でセッションの説明を取得することができる。

時分割多重方式
上述の実施形態では、ＥＳＧデータの部分３２及び３２’を含むＩＰパケットは、送信スロットが利用可能である限りデータキャスタ３によってクライアント５に送信することができる。しかし、クライアント５がＩＰパケットを確実に受信することができるようにするために、クライアント５は、いつでもデータを受信するように構成されるのが好ましい。これは、処理パワー及び電力を不必要に使用するという欠点を有する。
この問題のソリューションは、時分割多重方式（ＴＤＭ）を用いることである。

図２３を参照すると、本発明によるセッションディレクトリ２８の説明を送信する代替的方法が示されている。この実施例では、セッション告知の２つの種類３７₁及び３７₂を含む後のサイクル３８₂’のみが示されている。
ＥＳＧデータを説明するための第１種類の告知３７₁とＥＳＧデータへの更新を説明するための第２種類の告知３７₂は、異なるタイムスロット５２₁及び５２₂で送信される。例えば、第１及び第２種類の告知３７₁及び３７₂は、他のタイムスロットで送信される。しかし、タイムスロット５２₁及び５２₂は隣り合っている必要はない。タイムスロットは、可変又は固定長とすることができる。

すなわち、クライアント５がＥＳＧデータへの更新を聴取したい場合には、第１種類の告知３７₁が送信される間タイムスロット５２₁を聴取する必要はなく、第２種類の告知３７₂のみが送信されるタイムスロット５２₂を聴取することができる。これによってクライアント５は、タイムスロット５２₁中に受信器１４（図１）をオフに切り換えることができる。ＥＳＧデータは、クライアントの受信器をオン又はオフにする必要がある時、及び／又はコンテントがデータキャストオペレータによって定められたサービスエリア内で送信される時に関連する情報を包含するものである。

データキャストクライアント５
図２４を参照すると、本発明によるデータキャストクライアント５の実施形態は、バス５８を通じて接続されるプロセッサ５３、入／出力インタフェース５４、メモリ５５、受信器５６、及び送受信機５７を含む。入／出力インタフェース５４は、ユーザインタフェース５９、ディスプレイ６０、記憶装置６１、及びスピーカー６２に接続される。
データキャストクライアント５は、本発明により第１及び第２無線通信ネットワークと共に使用する手持ち式移動通信装置とすることができる。例えば、第１無線通信ネットワークは、ＤＶＢ−Ｔ又はＤＡＢネットワーク、又は、これらの又は同様のネットワークのいずれかの修正とすることができ、受信器５６は、このようなネットワークからの信号を受信かつ復調するように構成することができる。第２無線通信ネットワークは、ＵＭＴＳネットワーク、又は、他の３Ｇ、２．５Ｇ、又は２Ｇ電気通信ネットワークとすることができ、送受信機５７は、ＵＭＴＳ又は同様のネットワークを通じて信号を受信／送信かつ復調／変調するように構成することができる。

データキャストクライアント５は、第１及び第２有線及び／又は無線通信ネットワークと共に使用するためのテレビセットに接続したセットトップボックスとすることができる。例えば、第１通信ネットワークは、ＤＶＢ−Ｔネットワークとすることができ、受信器５６は、ＤＶＢ−Ｔネットワークからの信号を受信して復調するように構成することができる。第２通信ネットワークは、インターネットとすることができ、送受信機５７は、公衆交換電話網を通じてインターネットサービスプロバイダに接続するためのモデム（図示せず）を含むことができる。

２つのネットワークを使用して、セッション及びセッション告知を異なるネットワーク上で送信することができる。代替的に、セッション告知の第１及び第２種類を異なるネットワーク上で送信することができる。
２つのネットワークが利用可能である場合、クライアント装置のユーザは、要求応答モデルを使用することにより、完全な又は部分的なＥＳＧメタデータの配信、その更新、及び更新の通知を管理することができ、この場合、要求は、第２通信ネットワークを通じてデータキャストサービスシステムに送信される。クライアントとデータキャストサービスの間の通信では、必要に応じて確認応答を使用することができる。クライアントは、第２通信ネットワークを使用して通知を要求することができ、選択された通知は、このような通知が作成される時にクライアントに送信される。

メモリ５５にロードされてプロセッサ５３によって実行される時、コンピュータプログラム（図示せず）は、装置の他の要素と共にプロセッサ５３にサービス発見クライアント１５、ＥＳＧブラウザ１７、コンテントフィルタリングアプリケーション１８、及びコンテントブラウザ２０をそれぞれ提供させる。記憶装置６１は、ＥＳＧ及びコンテントデータベース１６及び１９を保持するために使用される。ユーザインタフェース５９により、ユーザは、セッションを選択するための命令のような命令をＥＳＧブラウザ１７及びコンテントブラウザ２０に提供することができる。ディスプレイ６０により、ユーザは、セッション説明及びセッションコンテントを見ることができる。スピーカー６２により、ユーザは、セッションコンテントを聴取することができる。

ＥＳＧブラウザ
図２５を参照すると、ＥＳＧブラウザウィンドウ６３の実施例が示されている。ウィンドウ６３は、例えば、セッションが現在送信中であるか又は検索期間であるか否かに関して送信の日付に基づいてセッションをフィルタリングする命令を受信するための第１セクション６４を含む。ウィンドウ６３は、フィルタリングされたセッションのリストを表示してセッションを選択する命令を受信するための第２セクション６５を含む。ウィンドウ６３は、選択されたセッションの説明を表示してセッションにアクセスする命令を受信するための第３セクション６６を含む。

多くの修正が上述の実施形態に行えることが認められるであろう。
セッション告知は、クライアントに対してマルチキャストではなくユニキャストにすることができる。
セッション及びセッション告知は、異なるネットワーク上で送信することができる。例えば、セッションは、ＤＶＢネットワーク上で送信することができ、セッション告知は、ＤＡＢネットワークを通じて送ることができる。

セッション告知の第１及び第２種類は、異なるネットワーク上で送信することができる。例えば、第１種類の告知は、ＤＶＢ−Ｔネットワークを通じて送信することができ、第２種類の告知は、３Ｇネットワークを通じて送ることができる。セッション告知の第１及び第２種類は、同じネットワーク上で送信することができるが、１つ又はそれ以上の異なる物理チャンネル、例えば、異なる搬送周波数で送信することもできる。セッション告知の第１及び第２種類は、同じネットワークを通じて、更に同じ物理チャンネルによって送信することができるが、１つ又はそれ以上の異なる論理チャンネルによって送信することもできる。

本開示を読むことから他の変形及び修正が当業者には明らかであろう。このような変形及び修正は、セッション及びその構成部分を告知するためのシステムの設計、製作、及び使用において既に行われ、かつ本明細書で既に説明した特徴の代わりに又はそれに加えて使用することができる均等物及び他の特徴を含むことができる。
特許請求の範囲は、特徴の特定の組合せに対して本出願において考案されているが、本発明の開示の範囲はまた、任意数の特徴、又は暗に又は明示的に本明細書に開示された特徴の任意の他の組合せ、又はその任意の一般化をそれがいずれかの特許請求の範囲において本発明で請求されたものと同じ発明に関連するものか否か又はそれが本発明が行うように特定の問題のいずれか又は全てを軽減するか否かに関わらず含むことを理解すべきである。本出願人は、本出願又はそれから派生する任意の更なる出願の手続き中にこのような特徴及び／又は特徴の組合せに対して新しい特許請求の範囲が考案される場合があることをここに告知するものである。

２８ セッションディレクトリ
２９１ フルセッションディレクトリ
２９２ 更新されたセッションディレクトリ

Claims (23)

1. ネットワークを通じてマルチメディアセッションを確立する方法であって、
   複数のマルチメディアセッションを説明する電子サービスガイドデータの告知の第１セットを送信側において発生し、
   少なくとも１つの更新されたマルチメディアセッションを説明する電子サービスガイドデータの告知の第２セットを前記送信側において発生し、前記少なくとも１つの更新されたマルチメディアセッションは、前記告知の第１セットの以前のバージョンに対して反映されたものであって且つ前記告知の第１セットの現在のバージョンにて説明されているものであり、
   第１チャンネルにおいて前記告知の第１セット及び第２チャンネルにおいて前記告知の第２セットを、前記ネットワークを介して１つ若しくは２つ以上のサイクルの間に同時に前記送信側から送信すること、
   を備え、
   前記複数のマルチメディアセッションは各々、１つ若しくは２つ以上のメディアデータストリームを含んでおり、
   前記告知の第２セットは、前記少なくとも１つの更新されたマルチメディアセッションだけを説明することを特徴とする方法。
2. 第１チャンネルを通じて前記告知の第１セットを送信し、第２の異なるチャンネルを通じて前記告知の第２セットを送信することを含み、前記第１及び第２チャンネルは論理的にグループ分けされ、１つの送信側と関連付けられていることを特徴とする請求項１に記載の方法。
3. 前記告知の第１セットを発生することは、前記告知の第１セットの各々に、前記複数のマルチメディアセッションのうちの１つに前記各々の告知を対応付けるためのデータを含めることを含み、前記告知の第２セットを発生することは、前記告知の第２セットの各々に、前記少なくとも１つの更新されたマルチメディアセッションのうちの１つに前記各々の告知を対応付けるためのデータを含めることを含むことを特徴とする請求項１に記載の方法。
4. 前記告知の第１セットによって説明されるマルチメディアセッションの各々の部分を指すポインタを用いて、前記少なくとも１つの更新されたマルチメディアセションを通知する告知の第３セットを発生することを更に含むことを特徴とする請求項１に記載の方法。
5. 前記告知の第２セットを発生することは、該少なくとも１つの更新されたマルチメディアセッションのうちの１つに、前記告知の第２セットの各々を対応付けるためのメタデータを発生することを含むことを特徴とする請求項１に記載の方法。
6. 非同期層別符号化（ＡＬＣ）プロトコル又は非同期層別符号化（ＡＬＣ）プロトコルに基づくプロトコルに従って、前記告知の第１及び第２のセットのうちの少なくとも１つが送信されることを特徴とする請求項１に記載の方法。
7. データ処理装置によって実行される時に、請求項１に記載のネットワークを通じてマルチメディアセッションを確立する方法を該データ処理装置に実行させることを特徴とするコンピュータプログラム。
8. ネットワークを通じて送信されるマルチメディアセッションにアクセスする方法であって、
   複数のマルチメディアセッションを説明する電子サービスガイドデータの告知の第１セットを、受信器において第１チャンネルを介して受信し、
   少なくとも１つの更新されたマルチメディアセッションを説明する電子サービスガイドデータの告知の第２セットを、第２チャンネルを介して１つ若しくは２つ以上のサイクルの間に前記告知の第１セットと同時に受信器において受信すること、
   を備え、前記少なくとも１つの更新されたマルチメディアセッションは、前記告知の第１セットの以前のバージョンに対して反映されたものであって且つ前記告知の第１セットの現在のバージョンにて説明されているものであり、
   前記複数のマルチメディアセッションは各々、１つ若しくは２つ以上のメディアデータストリームを含んでおり、
   前記告知の第２セットは、前記少なくとも１つの更新されたマルチメディアセッションだけを説明することを特徴とする方法。
9. 前記告知の第２セットは、前記少なくとも１つの更新されたマルチメディアセッションのうちの１つに前記告知の第２セットの各々を対応付けるメタデータを含むことを特徴とする請求項８に記載の方法。
10. 前記告知の第１セットの全てを受信したか否かを判断することを更に含むことを特徴とする請求項９に記載の方法。
11. ネットワークを通じて送信されるマルチメディアセッションにアクセスする方法であって、
    第１チャンネルを介して受信される複数のマルチメディアセッションを説明する電子サービスガイドデータの告知の第１セットに、受信器においてアクセスし、
    電子サービスガイドデータの告知の第２セットが第２チャンネルを介して１つ若しくは２つ以上のサイクルの間に前記告知の第１セットと同時に受信されたか否かを、前記受信器によって判断し、前記告知の第２セットは、前記告知の第１セットの以前のバージョンに対して反映されたものであって且つ前記告知の第１セットの現在のバージョンにて説明されている少なくとも１つの更新されたマルチメディアセッションを説明しており、
    前記告知の第２セットを受信した場合には、前記告知の第１セットに受信器においてアクセスすることを停止して、前記告知の第２セットに、受信器においてアクセスすること、
    を備え、
    前記複数のマルチメディアセッションは各々、１つ若しくは２つ以上のメディアデータストリームを含んでおり、
    前記告知の第２セットは、前記少なくとも１つの更新されたマルチメディアセッションだけを説明することを特徴とする方法。
12. ネットワークを通じてマルチメディアセッションを確立するための装置であって、
    複数のマルチメディアセッションを説明する電子サービスガイドデータの告知の第１セットを発生するための手段と、
    少なくとも１つの更新されたマルチメディアセッションを説明する電子サービスガイドデータの告知の第２セットを発生するための手段であって、前記少なくとも１つの更新されたマルチメディアセッションは、前記告知の第１セットの以前のバージョンに対して反映されたものであって且つ前記告知の第１セットの現在のバージョンにて説明されているような手段と、
    第１チャンネルにて前記告知の第１セット及び第２チャンネルにて前記告知の第２セットを、前記ネットワークを介して１つ若しくは２つ以上のサイクルの間に同時に送信する手段と、
    を備え、
    前記複数のマルチメディアセッションは各々、１つ若しくは２つ以上のメディアデータストリームを含んでおり、
    前記告知の第２セットは、前記少なくとも１つの更新されたマルチメディアセッションだけを説明することを特徴とする装置。
13. ネットワークを通じて送信されるマルチメディアセッションにアクセスするための装置であって、
    複数のマルチメディアセッションを説明する電子サービスガイドデータの告知の第１セットを、第１チャンネルを介して受信するための手段と、
    少なくとも１つの更新されたマルチメディアセッションを説明する電子サービスガイドデータの告知の第２セットを、第２チャンネルを介して１つ若しくは２つ以上のサイクルの間に前記告知の第１セットと同時に受信するための手段であって、前記少なくとも１つの更新されたマルチメディアセッションは、前記告知の第１セットの以前のバージョンに対して反映されたものであって且つ前記告知の第１セットの現在のバージョンにて説明されているような手段と、
    を備え、
    前記複数のマルチメディアセッションは各々、１つ若しくは２つ以上のメディアデータストリームを含んでおり、
    前記告知の第２セットは、前記少なくとも１つの更新されたマルチメディアセッションだけを説明することを特徴とする装置。
14. 前記告知の第１セットを受信したか否かを判断するための手段、
    を含み、
    前記判断するための手段が、前記告知の第１セットが前記告知の第１及び第２セットを同時に受信する前記１つ若しくは２つ以上のサイクルの外で受信されたと判断した場合に、前記告知の第２セットを受信するための手段が該告知の第２セットを受信する、
    ことを特徴とする請求項１３に記載の装置。
15. 前記告知の第１セットにより説明されるマルチメディアセッションの各部分を指すポインタを使用して前記少なくとも１つの更新されたマルチメディアセッションを通知する告知の第３セットを、選択的に受信するための手段、
    を含み、
    前記判断するための手段が、前記告知の第１セットが受信されたと判断した場合に、前記告知の第３セットを選択的に受信するための手段は該告知の第３セットを受信しないか又は転送する、
    ことを特徴とする請求項１４に記載の装置。
16. 移動通信装置であることを特徴とする請求項１３に記載の装置。
17. 電子サービスガイドデータをエンドユーザ端末に呈示するためのシステムであって、
    ネットワークを介して２つの別々のチャンネルにて告知の第１及び第２セットを同時に送信する手段であって、電子サービスガイドデータの前記告知の第１セットは、複数のマルチメディアセッションを説明しており、電子サービスガイドデータの前記告知の第２セットは、少なくとも１つの更新されたマルチメディアセッションを説明しており、前記少なくとも１つの更新されたマルチメディアセッションは前記告知の第１セットの以前のバージョンに対して反映されたものであって且つ前記告知の第１セットの現在のバージョンにて説明されているような手段と、
    電子サービスガイドデータの前記告知の第１セットから少なくとも部分的に、電子サービスガイドデータの前記告知の第２セットから少なくとも部分的に及び前記告知の第１セット及び第２セットのうちの少なくとも１つが受信されているか否かを定義する前記第１及び第２告知のうちの少なくとも１つのマルチメディアセッション説明から少なくとも部分的に、電子サービスガイドを構築する手段と、を備え、
    前記複数のマルチメディアセッションは各々、１つ若しくは２つ以上のメディアデータストリームを含んでおり、
    前記告知の第２セットは、前記少なくとも１つの更新されたマルチメディアセッションだけを説明することを特徴とするシステム。
18. 前記少なくとも１つの更新されたマルチメディアセッションは、前記告知の第１セットの以前のバージョンへ追加され、該以前のバージョンから変更され、又は該以前のバージョンから取り除かれている、
    ことを特徴とする請求項１に記載の方法。
19. 前記告知の第２セットの各々は、同じサイクルにおいて前記第１チャンネルにて１つの対応する第１告知と同時に前記第２チャンネルにてブロードキャストされる、
    ことを特徴とする請求項１に記載の方法。
20. 前記告知の第２セットは、同じサイクルにおいて前記第１チャンネルにて前記告知の第１セットの対応する１つ１つと交互に前記第２チャンネルにてブロードキャストされる、
    ことを特徴とする請求項１に記載の方法。
21. 前記告知の第３セットは、前記ネットワークを介して１つ若しくは２つ以上のサイクルの間に前記告知の第１及び第２セットのうちの少なくとも１つと同時に第３チャンネルにてブロードキャストされる、
    ことを特徴とする請求項４に記載の方法。
22. 前記告知の第３セットは、前記告知の第２セットよりも頻繁にブロードキャストされる、
    ことを特徴とする請求項４に記載の方法。
23. 前記告知の第３セットの各々は、同じサイクルにおいて前記第１チャンネルにて１つの対応する第１又は第２告知と同時に前記第３チャンネルにてブロードキャストされる、
    ことを特徴とする請求項４に記載の方法。

Images