(57)【要約】  メディアコンテンツソースから受信者に送信されたリアルタイム制御プロトコル（ＲＴＣＰ）のメッセージ内に埋め込まれるのは、受信者にストリーミングされるメディアプレゼンテーションを記述するセッション記述のメッセージである。セッション記述のメッセージは、装置から受信者にストリーミングされるメディアコンテンツの再生リスト内のメディアコンテンツ作品に関連付ける。セッション記述のメッセージを埋め込むＲＴＣＰのメッセージは、３つのフィールドを含む。ＲＴＣＰのメッセージをセッション記述のメッセージを埋め込むタイプであるとして識別するデータを含む第１のフィールドと、メディアプレゼンテーションに対するセッション記述のメッセージであるデータを含む第２のフィールドと、第１、第２、および第３のフィールドの長さを足し合わせて生成されるＲＴＣＰのメッセージの長さを識別するデータを含む第３のフィールドとを含む。
2007509573.tif 000002
【特許請求の範囲】
【請求項１】
リアルタイム制御プロトコル（以下、ＲＴＣＰという）のメッセージが格納される１つまたは複数のコンピュータ可読媒体であって、
前記ＲＴＣＰのメッセージをセッション記述のメッセージを埋め込むタイプであるとして識別するデータを含む第１のフィールドと、
メディアプレゼンテーションに対する前記セッション記述のメッセージであるデータを含む第２のフィールドと、
前記第１のフィールドの長さ、前記第２のフィールドの長さ、および前記第３のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの長さを識別するデータを含む第３のフィールドと
を含むことを特徴とする１つまたは複数のコンピュータ可読媒体。
【請求項２】
前記セッション記述のメッセージは、セッション記述プロトコル（以下、ＳＤＰという）のセッション記述のメッセージであることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項３】
前記メディアプレゼンテーションは、マルチメディアプレゼンテーションを含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項４】
前記メディアプレゼンテーションのメディアストリームに関するＲＴＰ特有の情報を各々識別する１つまたは複数のＲＴＰ−Ｓｔａｔｅブロックと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、および前記１つまたは複数のＲＴＰ−Ｓｔａｔｅブロックの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項５】
前記メディアプレゼンテーションをストリーミングするために使用されるリアルタイムトランスポートプロトコル（以下、ＲＴＰという）のバージョンを識別するデータを含む第４のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、および前記第４のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項６】
追加パディングが前記ＲＴＣＰのメッセージに含まれるかどうかを識別するデータを含む第４のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、および前記第４のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項７】
前記第２のフィールド内の前記データが圧縮されているかどうかを識別するデータを含む第４のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、および前記第４のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項８】
前記セッション記述のメッセージおよび前記セッション記述のメッセージの送信者のアドレスを識別するデータを含む第４のフィールドと
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、および前記第４のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項９】
前記セッション記述のメッセージおよび前記セッション記述のメッセージの前記送信者の前記アドレスを識別する前記データは、前記セッション記述のメッセージおよび前記セッション記述のメッセージの前記送信者の前記アドレスについて計算されたチェックサムを含むことを特徴とする請求項８に記載の１つまたは複数のコンピュータ可読媒体。
【請求項１０】
前記ＲＴＣＰのメッセージに含まれるＲＴＰ−Ｓｔａｔｅブロックの個数を識別するデータを含む第４のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、および前記第４のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項１１】
前記第４のフィールドは、前記ＲＴＣＰのメッセージにＲＴＰ−Ｓｔａｔｅブロックが含まれないことを示す値０を含むことを特徴とする請求項１０に記載の１つまたは複数のコンピュータ可読媒体。
【請求項１２】
前記ＲＴＣＰのメッセージのＲＴＰ−Ｓｔａｔｅブロック内のデータが特定のＳＤＰ  Ｆｌｏｗ  ＩＤを持つすべてのＲＴＰパケットに適用されるのか、それとも特定のＲＴＰ  Ｐａｙｌｏａｄ  Ｔｙｐｅ数を持つＲＴＰパケットにのみ適用されるのかを識別するデータを含む第４のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、および前記第４のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項１３】
前記ＲＴＣＰのメッセージのＲＴＰ−Ｓｔａｔｅブロックに対するＲＴＰ  Ｐａｙｌｏａｄ  Ｔｙｐｅ数を識別するデータを含む第４のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、および前記第４のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項１４】
前記ＲＴＣＰのメッセージのＲＴＰ−Ｓｔａｔｅブロックの参照先の前記メディアプレゼンテーションのメディアストリームを識別するデータを含む第４のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、および前記第４のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項１５】
前記ＲＴＣＰのメッセージのＲＴＰ−Ｓｔａｔｅブロックの参照先の前記メディアプレゼンテーションのメディアストリームのソースを識別するデータを含む第４のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、および前記第４のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項１６】
前記ＲＴＰパケットが前記メディアストリームの先頭で送信された場合に前記メディアプレゼンテーションのメディアストリームに対するＲＴＰパケットが持つであろうＲＴＰ  Ｔｉｍｅｓｔａｍｐフィールドの値を識別するデータを含む第４のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、および前記第４のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項１７】
前記メディアプレゼンテーションのメディアストリームについて送信される第１のＲＴＰパケットのＲＴＰシーケンス番号フィールドの値を識別するデータを含む第４のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、および前記第４のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項１８】
前記ＲＴＣＰのメッセージが前記セッション記述のメッセージの断片を含むことを示すデータを含む第４のフィールドと、
前記断片を識別するデータを含む第５のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、前記第４のフィールドの長さ、および前記第５のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項１９】
前記メディアプレゼンテーションをストリーミングするために使用されるリアルタイムトランスポートプロトコル（以下、ＲＴＰという）のバージョンを識別するデータを含む第４のフィールドと、
追加パディングが前記ＲＴＣＰのメッセージに含まれるかどうかを識別するデータを含む第５のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、前記第４のフィールドの長さ、および前記第５のフィールドの長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項２０】
前記メディアプレゼンテーションをストリーミングするために使用されるリアルタイムトランスポートプロトコル（以下、ＲＴＰという）のバージョンを識別するデータを含む第４のフィールドと、
追加パディングオクテットが前記ＲＴＣＰのメッセージに含まれるかどうかを識別するデータを含む第５のフィールドと、
前記第２のフィールド内の前記データが圧縮されているかどうかを識別するデータを含む第６のフィールドと、
前記セッション記述のメッセージおよび前記セッション記述のメッセージの送信者のアドレスを識別するデータを含む第７のフィールドと、
前記ＲＴＣＰのメッセージに含まれるＲＴＰ−Ｓｔａｔｅブロックの個数を識別するデータを含む第８のフィールドと、
前記ＲＴＣＰのメッセージのＲＴＰ−Ｓｔａｔｅブロック内のデータが特定のＳＤＰ  Ｆｌｏｗ  ＩＤを持つすべてのＲＴＰパケットに適用されるのか、それとも特定のＲＴＰ  Ｐａｙｌｏａｄ  Ｔｙｐｅ数を持つＲＴＰパケットにのみ適用されるのかを識別するデータを含む第９のフィールドと、
前記ＲＴＣＰのメッセージの前記ＲＴＰ−Ｓｔａｔｅブロックに対するＲＴＰ  Ｐａｙｌｏａｄ  Ｔｙｐｅ数を識別するデータを含む第１０のフィールドと、
前記ＲＴＣＰのメッセージの前記ＲＴＰ−Ｓｔａｔｅブロックの参照先の前記メディアプレゼンテーションのメディアストリームを識別するデータを含む第１１のフィールドと、
前記ＲＴＣＰのメッセージの前記ＲＴＰ−Ｓｔａｔｅブロックの参照先の前記メディアプレゼンテーションの前記メディアストリームのソースを識別するデータを含む第１２のフィールドと、
前記ＲＴＰパケットが前記メディアストリームの先頭で送信された場合に前記メディアプレゼンテーションの前記メディアストリームに対するＲＴＰパケットが持つであろうＲＴＰ  Ｔｉｍｅｓｔａｍｐフィールドの値を識別するデータを含む第１３のフィールドと、
前記メディアプレゼンテーションの前記メディアストリームについて送信される第１のＲＴＰパケットのＲＴＰシーケンス番号フィールドの値を識別するデータを含む第１４のフィールドと、
前記ＲＴＣＰのメッセージが前記セッション記述のメッセージの断片を含むことを示すデータを含む第１５のフィールドと、
前記断片を識別するデータを含む第１６のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、前記第３のフィールドの前記長さ、前記第４のフィールドの長さ、前記第５のフィールドの長さ、前記第６のフィールドの長さ、前記第７のフィールドの長さ、前記第８のフィールドの長さ、前記第９のフィールドの長さ、前記第１０のフィールドの長さ、前記第１１のフィールドの長さ、前記第１２のフィールドの長さ、前記第１３のフィールドの長さ、前記第１４のフィールドの長さ、前記第１５のフィールドの長さ、および前記第１６のフィールドの長さを足し合わせることで生成された前記ＲＴＣＰのメッセージの前記長さを識別するデータを含む前記第３のフィールドと
を含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項２１】
複数の命令を格納している１つまたは複数のコンピュータ可読媒体であって、前記複数の命令が装置の１つまたは複数のプロセッサによって実行されると、前記１つまたは複数のプロセッサは、
メディアコンテンツソースから、リアルタイム制御プロトコル（以下、ＲＴＣＰという）メッセージを受信することと、
前記メディアコンテンツソースから前記装置にストリーミングされるメディアコンテンツの再生リスト内のメディアコンテンツの複数の作品のうちの１つに関連付けられたセッション記述のメッセージを前記ＲＴＣＰのメッセージから抽出することと、
前記セッション記述のメッセージに少なくとも一部は基づきメディアコンテンツの前記複数の作品のうちの前記１つを処理することと
を行う特徴とする１つまたは複数のコンピュータ可読媒体。
【請求項２２】
前記セッション記述のメッセージは、セッション記述プロトコル（以下、ＳＤＰという）セッション記述のメッセージであることを特徴とする請求項２１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項２３】
前記ＲＴＣＰのメッセージは、ＲＴＣＰパケットの一部であることを特徴とする請求項２１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項２４】
前記セッション記述のメッセージに少なくとも一部は基づいて前記１つまたは複数のプロセッサにメディアンコンテンツの前記複数の作品のうちの前記１つを処理させる前記命令は、前記装置では前記１つまたは複数のプロセッサにメディアンコンテンツの前記複数の作品のうちの前記１つを再生させることを特徴とする請求項２１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項２５】
前記命令は、前記１つまたは複数のプロセッサに、メディアンコンテンツの前記複数の作品内のメディアコンテンツの前記他の作品のそれぞれについて受信、抽出、および処理を繰り返させることをさらに特徴とする請求項２１に記載の１つまたは複数のコンピュータ可読媒体。
【請求項２６】
前記ＲＴＣＰのメッセージは、
前記ＲＴＣＰのメッセージを前記セッション記述のメッセージを埋め込むタイプであるとして識別するデータを含む第１のフィールドと、
前記セッション記述のメッセージであるデータを含む第２のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、および前記第３のフィールドの前記長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの長さを識別するデータを含む第３のフィールドと
を含むことを特徴とする１つまたは複数のコンピュータ可読媒体。
【請求項２７】
装置内に実装される方法であって、
前記装置からクライアント装置にストリーミングされるメディアンコンテンツの再生リスト内のメディアンコンテンツの複数の作品のうちの１つに関連付けられているセッション記述のメッセージを含むリアルタイム制御プロトコル（以下、ＲＴＣＰという）メッセージを作成することと、
前記ＲＴＣＰのメッセージを前記クライアント装置に送信することと
を備えたことを特徴とする方法。
【請求項２８】
前記再生リスト内のメディアコンテンツの前記複数の作品のうちの第２にものに関連付けられている第２のセッション記述のメッセージを含む第２のＲＴＣＰのメッセージを作成することと、
前記第２のＲＴＣＰのメッセージを前記クライアント装置に送信することと
をさらに備えたことを特徴とする請求項２７に記載の方法。
【請求項２９】
前記装置は、サーバ装置を備えたことを特徴とする請求項２７に記載の方法。
【請求項３０】
前記セッション記述のメッセージは、セッション記述プロトコル（以下、ＳＤＰという）セッション記述のメッセージであることを特徴とする請求項２７に記載の方法。
【請求項３１】
前記ＲＴＣＰのメッセージは、ＲＴＣＰパケットの一部であることを特徴とする請求項２７に記載の方法。
【請求項３２】
前記ＲＴＣＰのメッセージは、
前記ＲＴＣＰのメッセージを前記セッション記述のメッセージを埋め込むタイプであるとして識別するデータを含む第１のフィールドと、
前記セッション記述のメッセージであるデータを含む第２のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、および前記第３のフィールドの前記長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの長さを識別するデータを含む第３のフィールドと
を含むことを特徴とする請求項２７に記載の方法。
【請求項３３】
サーバ装置と、
クライアント装置と
を備え、前記サーバ装置が、
前記サーバ装置から前記クライアント装置にストリーミングされるメディアンコンテンツの再生リスト内のメディアンコンテンツの複数の作品のうちの１つに関連付けられているセッション記述のメッセージを含むリアルタイム制御プロトコル（以下、ＲＴＣＰという）メッセージを作成することと、
前記ＲＴＣＰのメッセージを前記クライアント装置に送信することと
を構成し、前記クライアント装置が、
前記サーバ装置から前記ＲＴＣＰのメッセージを受信することと、
前記ＲＴＣＰのメッセージから前記セッション記述のメッセージを抽出することと、
前記セッション記述のメッセージに少なくとも一部は基づきメディアコンテンツの前記複数の作品のうちの前記１つを処理することと
を構成することを特徴とするシステム。
【請求項３４】
前記ＲＴＣＰのメッセージは、
前記ＲＴＣＰのメッセージを前記セッション記述のメッセージを埋め込むタイプであるとして識別するデータを含む第１のフィールドと、
前記セッション記述のメッセージであるデータを含む第２のフィールドと、
前記第１のフィールドの前記長さ、前記第２のフィールドの前記長さ、および前記第３のフィールドの前記長さを足し合わせることで生成された、前記ＲＴＣＰのメッセージの長さを識別するデータを含む第３のフィールドと
を含むことを特徴とする請求項３３に記載のシステム。
【請求項３５】
マルチメディアプレゼンテーションのデータを受信し、前記データは第１の複数のストリームを含むことと、
専用アナウンスメントストリームを含む第２の複数のストリームおよび前記第１の複数のストリームから選択された第１のストリームをマルチキャストし、前記アナウンスメントストリームは前記マルチメディアプレゼンテーションのプレゼンテーション記述情報を含むことと
を特徴とする方法。
【請求項３６】
前記第２の複数のストリームは、異なるチャネル上でマルチキャストされることを特徴とする請求項３５に記載の方法。
【請求項３７】
前記第２の複数のストリームは、所定の異なるチャネル上でマルチキャストされることを特徴とする請求項３６に記載の方法。
【請求項３８】
前記所定の異なるチャネルは、所定の論理アドレスを含むことを特徴とする請求項３７に記載の方法。
【請求項３９】
前記所定の論理アドレスは、所定のポートを含む所定のインターネットプロトコル（以下、ＩＰという）アドレスであることを特徴とする請求項３８に記載の方法。
【請求項４０】
前記所定の異なるチャネルは、論理アドレスの所定のポートを含むことを特徴とする請求項３７に記載の方法。
【請求項４１】
前記第２の複数のストリームは、前記マルチメディアプレゼンテーションのデータの事前に選択された個数の前の部分ユニットを各々含んだ、前記マルチメディアプレゼンテーションのデータの複数のユニットを含む第２のストリームをさらに含むことを特徴とする請求項３５に記載の方法。
【請求項４２】
前記複数のユニットの各々のユニットは、キーフレームを含むことを特徴とする請求項４１に記載の方法。
【請求項４３】
前記第２の複数のストリームは、異なるビットレートを持つビデオデータの複数のストリームをさらに含むことを特徴とする請求項３５に記載の方法。
【請求項４４】
前記第２の複数のストリームは、異なるビットレートを持つオーディオデータの複数のストリームをさらに含むことを特徴とする請求項３５に記載の方法。
【請求項４５】
前記第２の複数のストリームは、異なる言語のマルチメディアデータの複数のストリームをさらに含むことを特徴とする請求項３５に記載の方法。
【請求項４６】
前記第２の複数のストリームは、前記第２の複数のストリームを受信するクライアント上で実行されているアプリケーションにより使用されるデータのストリームをさらに含むことを特徴とする請求項３５に記載の方法。
【請求項４７】
前記アナウンスメントストリームは、誤り訂正情報を含むことを特徴とする請求項３５に記載の方法。
【請求項４８】
前記アナウンスメントストリームは、セキュリティ情報を含むことを特徴とする請求項３５に記載の方法。
【請求項４９】
前記アナウンスメントストリームは、帯域外チャネル上でマルチキャストされることを特徴とする請求項３５に記載の方法。
【請求項５０】
前記アナウンスメントストリームは、帯域内チャネル上でマルチキャストされることを特徴とする請求項３５に記載の方法。
【請求項５１】
前記アナウンスメントストリームは、リアルタイムトランスポート制御プロトコル（以下、ＲＴＣＰという）に適合するようにマルチキャストされ、前記アナウンスメントストリームが、リアルタイムトランスポートプロトコル（以下、ＲＴＰという）に適合するようにマルチキャストされたマルチメディアプレゼンテーションのストリーム内に帯域内となるように分散されることを特徴とする請求項５０に記載の方法。
【請求項５２】
前記アナウンスメントストリームは、アナウンスメントストリームデータがマルチメディアプレゼンテーションデータを含むパケットに含まれるようにマルチキャストされることを特徴とする請求項５０に記載の方法。
【請求項５３】
操作を実行するためのコンピュータ実行可能命令を格納するコンピュータアクセス可能媒体であって、
マルチメディアプレゼンテーションのデータを受信し、前記データは第１の複数のストリームを含むことと、
専用アナウンスメントストリームを含む第２の複数のストリームおよび前記第１の複数のストリームから選択された第１のストリームをマルチキャストし、前記アナウンスメントストリームが前記マルチメディアプレゼンテーションのプレゼンテーション記述情報を含むことと
を含むことを特徴とするコンピュータアクセス可能媒体。
【請求項５４】
前記第２の複数のストリームは、異なるチャネル上でマルチキャストされることを特徴とする請求項５３に記載のコンピュータアクセス可能媒体。
【請求項５５】
前記第２の複数のストリームは、所定の異なるチャネル上でマルチキャストされることを特徴とする請求項５４に記載のコンピュータアクセス可能媒体。
【請求項５６】
前記所定の異なるチャネルは、所定の論理アドレスを含むことを特徴とする請求項５５に記載のコンピュータアクセス可能媒体。
【請求項５７】
前記所定の論理アドレスは、所定のポートを含む所定のインターネットプロトコル（以下、ＩＰという）アドレスであることを特徴とする請求項５６に記載のコンピュータアクセス可能媒体。
【請求項５８】
前記所定の異なるチャネルは、論理アドレスの所定のポートを含むことを特徴とする請求項５５に記載のコンピュータアクセス可能媒体。
【請求項５９】
前記第２の複数のストリームは、前記複数のユニットが前記マルチメディアプレゼンテーションのデータの事前に選択された個数の前の部分ユニットを各々含んだ、前記マルチメディアプレゼンテーションのデータの複数のユニットを含む第２のストリームをさらに含むことを特徴とする請求項３５に記載のコンピュータアクセス可能媒体。
【請求項６０】
前記複数のユニットの各々のユニットは、キーフレームを含むことを特徴とする請求項５９に記載のコンピュータアクセス可能媒体。
【請求項６１】
前記第２の複数のストリームは、異なるビットレートを持つビデオデータの複数のストリームをさらに含むことを特徴とする請求項５３に記載のコンピュータアクセス可能媒体。
【請求項６２】
前記第２の複数のストリームは、異なるビットレートを持つオーディオデータの複数のストリームをさらに含むことを特徴とする請求項５３に記載のコンピュータアクセス可能媒体。
【請求項６３】
前記第２の複数のストリームは、異なる言語のマルチメディアデータの複数のストリームをさらに含むことを特徴とする請求項５３に記載のコンピュータアクセス可能媒体。
【請求項６４】
前記第２の複数のストリームは、前記第２の複数のストリームを受信するクライアント上で実行されているアプリケーションにより使用されるデータのストリームをさらに含むことを特徴とする請求項５３に記載のコンピュータアクセス可能媒体。
【請求項６５】
前記アナウンスメントストリームは、誤り訂正情報を含むことを特徴とする請求項５３に記載のコンピュータアクセス可能媒体。
【請求項６６】
前記アナウンスメントストリームは、セキュリティ情報を含むことを特徴とする請求項５３に記載のコンピュータアクセス可能媒体。
【請求項６７】
操作を実行するためのコンピュータ実行可能命令を格納するコンピュータアクセス可能媒体であって、
マルチメディアプレゼンテーションのデータを受信し、前記データは第１の複数のストリームを含むことと、
前記第１の複数のストリームからの選択された第１のストリームを含む第２の複数のストリーム、および前記マルチメディアプレゼンテーションのデータの事前に選択された前の部分ユニットを各々含んだ、前記マルチメディアプレゼンテーションのデータの複数のユニットを含む第２のストリームをマルチキャストすることと
を含むことを特徴とするコンピュータアクセス可能媒体。
【請求項６８】
前記複数のユニットの各々のユニットは、キーフレームを含むことを特徴とする請求項６７に記載のコンピュータアクセス可能媒体。
【請求項６９】
前記第２のストリームの前記複数のユニットは、マルチメディアプレーヤーが前記マルチメディアプレゼンテーションの再生を開始するのに要する時間を十分に短縮できるデータを各々含むことを特徴とする請求項６７に記載のコンピュータアクセス可能媒体。
【請求項７０】
マルチメディアプレゼンテーションのデータを受信し、前記データは第１の複数のストリームを含むことと、
前記第１の複数のストリームから選択された第１のストリームを含む第２の複数のストリーム、および前記マルチメディアプレゼンテーションのデータの事前に選択された前の部分ユニットを各々含んだ、前記マルチメディアプレゼンテーションのデータの複数のユニットを含む第２のストリームをマルチキャストすることと
を含むことを特徴とする方法。
【請求項７１】
前記複数のユニットの各々のユニットは、キーフレームを含むことを特徴とする請求項７０に記載の方法。
【請求項７２】
前記第２のストリームの前記複数のユニットは、マルチメディアプレーヤーが前記マルチメディアプレゼンテーションの再生を開始するのに要する時間を十分に短縮できるデータを各々含むことを特徴とする請求項７０に記載の方法。
【請求項７３】
マルチメディアプレゼンテーションのデータを受信し、前記データは第１の複数のストリームを含むことと、
前記第１の複数のストリームに含まれる情報に関係する第１および第２のストリームを含む第２の複数のストリームをマルチキャストし、前記第１および第２のストリームは事前に選択されたチャネルでマルチキャストされること
とを含むことを特徴とする方法。
【請求項７４】
前記所定の異なるチャネルは、所定の論理アドレスを含むことを特徴とする請求項７３に記載の方法。
【請求項７５】
前記所定の異なるチャネルは、インターネットプロトコル（以下、ＩＰという）アドレスの所定のポートを含むことを特徴とする請求項７３に記載の方法。
【請求項７６】
前記第１のストリームは、プレゼンテーション記述情報を含むアナウンスメントストリームであることを特徴とする請求項７３に記載の方法。
【請求項７７】
操作を実行するためのコンピュータ実行可能命令を格納するコンピュータアクセス可能媒体であって、
マルチメディアプレゼンテーションのデータを受信し、前記データは第１の複数のストリームを含むことと、
前記第１の複数のストリームに含まれる情報に関係する第１および第２のストリームを含む第２の複数のストリームをマルチキャストし、前記第１および第２のストリームは事前に選択されたチャネルでマルチキャストされることと
を含むことを特徴とするコンピュータアクセス可能媒体。
【請求項７８】
前記所定の異なるチャネルは、所定の論理アドレスを含むことを特徴とする請求項７７に記載のコンピュータアクセス可能媒体。
【請求項７９】
前記所定の論理アドレスは、所定のポートを含む所定のインターネットプロトコル（以下、ＩＰという）アドレスであることを特徴とする請求項７８に記載のコンピュータアクセス可能媒体。
【請求項８０】
前記所定の異なるチャネルは、論理アドレスの所定のポートを含むことを特徴とする請求項７７に記載のコンピュータアクセス可能媒体。
【請求項８１】
前記第１のストリームは、プレゼンテーション記述情報を含むアナウンスメントストリームであることを特徴とする請求項７８に記載のコンピュータアクセス可能媒体。
【請求項８２】
事前に選択された第１のチャネルから第１のストリームを受信し、前記第１のストリームはマルチキャストされるマルチメディアプレゼンテーションに関係するプレゼンテーション記述情報を含むことと、
前記事前に選択された第１のチャネル上で前記第１のストリームを受信すると同時に、第２の事前に選択されたチャネル上で第２のストリームを受信し、前記第２のストリームはマルチキャストされる前記マルチメディアプレゼンテーションのマルチメディアのストリームを含むことと
を含むことを特徴とする方法。
【請求項８３】
前記第２のストリームの受信を終了することと、
前記第１のストリームから受信されたプレゼンテーション記述情報に対する応答として選択された第３のチャネル上で第３のストリームを選択的に受信し、前記第３のストリームはマルチキャストされる前記マルチメディアプレゼンテーションのマルチメディアデータの他のストリームを含むことと
をさらに含むことを特徴とする請求項８２に記載の方法。
【請求項８４】
前記第２のストリームが事前に選択された基準に一致することを示す前記第１のストリームから受信されたプレゼンテーション記述情報に対応する応答として前記第２のストリームの受信を継続することをさらに含むことを特徴とする請求項８２に記載の方法。
【請求項８５】
操作を実行するためのコンピュータ実行可能命令を格納するコンピュータアクセス可能媒体であって、
事前に選択された第１のチャネルから第１のストリームを受信し、前記第１のストリームはマルチキャストされるマルチメディアプレゼンテーションに関係するプレゼンテーション記述情報を含むことと、
前記事前に選択された第１のチャネル上で前記第１のストリームを受信すると同時に、第２の事前に選択されたチャネル上で第２のストリームを受信し、前記第２のストリームはマルチキャストされる前記マルチメディアプレゼンテーションのマルチメディアのストリームを含むことと
を含むことを特徴とするコンピュータアクセス可能媒体。
【請求項８６】
前記操作は、
前記第２のストリームの受信を終了することと、
前記第１のストリームから受信されたプレゼンテーション記述情報に対する応答として選択された第３のチャネル上で第３のストリームを選択的に受信し、前記第３のストリームはマルチキャストされる前記マルチメディアプレゼンテーションのマルチメディアデータの他のストリームを含むことと
をさらに含むことを特徴とする請求項８５に記載のコンピュータアクセス可能媒体。
【請求項８７】
前記操作は、前記第２のストリームが事前に選択された基準に一致することを示す前記第１のストリームから受信されたプレゼンテーション記述情報に対応する応答として前記第２のストリームの受信を継続することをさらに含むことを特徴とする請求項８５に記載のコンピュータアクセス可能媒体。
【請求項８８】
事前に選択された第１のチャネルから１ユニットのデータを受信し、前記第１のチャネルはマルチキャストされるマルチメディアプレゼンテーションのデータの複数のユニットを転送し、前記複数のユニットはそれぞれ、マルチキャストされる前記マルチメディアプレゼンテーションのデータの事前に選択された個数の前の部分ユニットを含むことと、
前記第１の事前に選択されたチャネルからのデータの受信を終了することと、
第２のチャネル上で第２のストリームを受信し、前記第２のストリームはマルチキャストされる前記マルチメディアプレゼンテーションのマルチメディアのストリームを含むことと
を含むことを特徴とする方法。
【請求項８９】
前記第２のチャネルは、アナウンスメントチャネルから受信されたプレゼンテーション記述情報に対する応答として選択されることを特徴とする請求項８８に記載の方法。
【請求項９０】
前記第２のチャネルは、事前に選択されることを特徴とする請求項８８に記載の方法。
【請求項９１】
操作を実行するためのコンピュータ実行可能命令を格納するコンピュータアクセス可能媒体であって、
事前に選択された第１のチャネルから１ユニットのデータを受信し、前記第１のチャネルはマルチキャストされるマルチメディアプレゼンテーションのデータの複数のユニットを転送し、前記複数のユニットはそれぞれ、マルチキャストされる前記マルチメディアプレゼンテーションのデータの事前に選択された個数の前の部分ユニットを含むことと、
前記第１の事前に選択されたチャネルからのデータの受信を終了することと、
第２のチャネル上で第２のストリームを受信し、前記第２のストリームはマルチキャストされる前記マルチメディアプレゼンテーションのマルチメディアのストリームを含むことと
を含むことを特徴とするコンピュータアクセス可能媒体。
【請求項９２】
前記第２のチャネルは、アナウンスメントチャネルから受信されたプレゼンテーション記述情報に対する応答として選択されることを特徴とする請求項９１に記載のコンピュータアクセス可能媒体。
【請求項９３】
前記第２のチャネルは、事前に選択されることを特徴とする請求項９１に記載のコンピュータアクセス可能媒体。
【請求項９４】
マルチメディアプレゼンテーションの第１の複数のストリームを受信するための第１のインターフェースと、
前記マルチメディアプレゼンテーションに関するプレゼンテーション記述情報を含むアナウンスメントストリームを供給するアナウンスメントジェネレータと、
前記アナウンスメントストリームと前記第１の複数のストリームから選択された第１のストリームとを複数のチャネルにマッピングするマッパと、
前記マッピングされたアナウンスメントストリームと前記マッピングされた第１のストリームとを含んだ、第２の複数のストリームをネットワーク上でマルチキャストするための第２のインターフェースと
を備えたことを特徴とするシステム。
【請求項９５】
前記第２の複数のストリームは、所定の異なるチャネル上でマルチキャストされることを特徴とする請求項９４に記載のシステム。
【請求項９６】
前記所定の異なるチャネルは、所定の論理アドレスを含むことを特徴とする請求項９５に記載のシステム。
【請求項９７】
前記所定の論理アドレスは、インターネットプロトコル（以下、ＩＰという）アドレスおよびポートを各々含むことを特徴とする請求項９６に記載のシステム。
【請求項９８】
前記所定の異なるチャネルは、論理アドレスの所定のポートを含むことを特徴とする請求項９５に記載のシステム。
【請求項９９】
前記第２の複数のストリームは、マルチキャストされた場合、前記マルチメディアプレゼンテーションのデータの事前に選択された個数の前の部分ユニットを各々含んだ、前記マルチメディアプレゼンテーションのデータの複数のユニットを含む第２のストリームををさらに含むことを特徴とする請求項９５に記載のシステム。
【請求項１００】
前記第２のストリームは、キーフレームを含むことを特徴とする請求項９９に記載のシステム。
【請求項１０１】
前記第２の複数のストリームは、前記第１の複数のストリームから選択された異なるビットレートを持つビデオデータの複数のストリームをさらに含むことを特徴とする請求項９５に記載のシステム。
【請求項１０２】
前記第２の複数のストリームは、前記第１の複数のストリームから選択された異なるビットレートを持つオーディオデータの複数のストリームをさらに含むことを特徴とする請求項９５に記載のシステム。
【請求項１０３】
前記第２の複数のストリームは、前記第１の複数のストリームから選択された異なる言語によるマルチメディアデータの複数のストリームをさらに含むことを特徴とする請求項９５に記載のシステム。
【請求項１０４】
前記第２の複数のストリームは、前記第２の複数のストリームを受信するクライアント上で実行されているアプリケーションにより使用されるデータのストリームをさらに含むことを特徴とする請求項９５に記載のシステム。
【請求項１０５】
前記アナウンスメントストリームは、誤り訂正情報を含むことを特徴とする請求項９５に記載のシステム。
【請求項１０６】
前記アナウンスメントストリームは、セキュリティ情報を含むことを特徴とする請求項９５に記載のシステム。
【請求項１０７】
前記アナウンスメントストリームは、帯域外チャネル上でマルチキャストされることを特徴とする請求項９５に記載のシステム。
【請求項１０８】
前記アナウンスメントストリームは、帯域内チャネル上でマルチキャストされることを特徴とする請求項９５に記載のシステム。
【請求項１０９】
前記アナウンスメントストリームは、リアルタイムトランスポート制御プロトコル（以下、ＲＴＣＰという）に適合するようにマルチキャストされ、前記アナウンスメントストリームは、リアルタイムトランスポートプロトコル（以下、ＲＴＰという）に適合するようにマルチキャストされたマルチメディアプレゼンテーションのストリーム内に帯域内となるように分散されることを特徴とする請求項１０８に記載のシステム。
【請求項１１０】
前記アナウンスメントストリームは、アナウンスメントストリームデータがマルチメディアプレゼンテーションデータを含むパケットに含まれるようにマルチキャストされることを特徴とする請求項１０８に記載のシステム。
【請求項１１１】
請求項９５に記載のコンポーネントを含むことを特徴とするコンピュータアクセス可能媒体。
【請求項１１２】
マルチメディアプレゼンテーションの第１の複数のストリームを受信するための手段と、
前記マルチメディアプレゼンテーションに関するプレゼンテーション記述情報を含むアナウンスメントストリームを生成するための手段と、
前記アナウンスメントストリームと前記第１の複数のストリームから選択された第１のストリームとを複数のチャネルのうちの１つまたは複数のチャネルにマッピングするための手段と、
前記マッピングされたアナウンスメントストリームと第１のストリームとを含んだ、第２の複数のストリームをネットワーク上でマルチキャストするための手段と
を備えたことを特徴とするシステム。
【請求項１１３】
前記第２の複数のストリームは、所定の異なるチャネル上でマルチキャストされることを特徴とする請求項１１２に記載のシステム。
【請求項１１４】
前記第２の複数のストリームの一部としてマルチキャストされるために、マルチキャストされた場合に、前記マルチメディアプレゼンテーションのデータの事前に選択された個数の前の部分ユニットを含む、前記複数のユニットのデータをマッピングするための前記手段に前記マルチメディアプレゼンテーションのデータの複数のユニットを供給するための手段をさらに備えたことを特徴とする請求項１１３に記載のシステム。
【請求項１１５】
請求項１１２に記載のコンポーネントを含むことを特徴とするコンピュータアクセス可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般には、ストリーミングメディアおよびデータ転送に関し、より詳細には、ＲＴＣＰのメッセージ内にセッション記述のメッセージを埋め込むことに関する。
【背景技術】
【０００２】
オーディオ、ビデオ、および／またはテキストのストリーミングなどのコンテンツストリーミングの人気が高まっている。「ストリーミング」という用語は、通常、コンテンツを表すデータを、丸ごとあらかじめ配送しておいて再生するのではなく、必要に応じてネットワークを介してクライアントコンピュータに供給することを示すために使用される。したがって、クライアントコンピュータは、「ファイル」全体が配送されるのを待つのではなく、ストリーミングコンテンツをネットワークサーバから受信しながらレンダリングする。
【０００３】
マルチメディアコンテンツのストリーミングが広く利用されることで、以前にはインターネットまたはその他のコンピュータネットワーク上で利用できなかったさまざまな情報コンテンツが利用できるようになる。ライブコンテンツは、そのようなコンテンツのうちの１つの重要な例である。ストリーミングマルチメディアを使用することにより、注目すべきイベントのオーディオ、ビデオ、またはオーディオ／ビジュアルの対象範囲を、イベントの展開に合わせてインターネット上でブロードキャストすることができる。同様に、テレビ局およびラジオ局も、インターネット上でそのライブコンテンツを送信することができる。
【０００４】
セッション記述プロトコル（ＳＤＰ）（例えば、非特許文献１参照）は、「セッション」と呼ばれるマルチメディアプレゼンテーションの特性、およびそのプレゼンテーション内に含まれる１つまたは複数のメディアストリームの特性を記述するために使用されるテキストベースのフォーマットである。ＳＤＰは、セッションアナウンスメント（ｓｅｓｓｉｏｎ  ａｎｎｏｕｎｃｅｍｅｎｔ）、セッション招待、およびその他の形のマルチメディアセッション招待の目的のためにマルチメディアセッションを記述することを意図したアプリケーションレベルのプロトコルとして開発された。ＳＤＰは、ストリーミングデータの配送に使用されるマルチメディアセッションの特性の記述はおよび／またはネゴシエーションを行うために、リアルタイムストリーミングプロトコル（ＲＴＳＰ）またはハイパーテキスト転送プロトコル（ＨＴＴＰ）などの他のプロトコルに従って、使用することができる。
【０００５】
しかし、多くの状況では、ＳＤＰ情報をネットワークサーバからクライアントコンピュータに取り込むことは困難である。例えば、ネットワークサーバは、再生リストに表示されているプレゼンテーションなど、一連のマルチメディアプレゼンテーションをクライアントコンピュータにストリーミングしている場合がある。ネットワークサーバが前のプレゼンテーションのストリーミングを次のプレゼンテーションに切り換えるときに、次のプレゼンテーションに対するＳＤＰ情報をクライアントコンピュータから利用できるようにすることは困難であることが多い。そこで、ＳＤＰ情報をクライアントコンピュータから利用できるようにするメカニズムを付加できれば都合がよい。
【０００６】
コンテンツストリーミングは、マルチキャストも可能である。ストリーミングコンテンツのマルチキャストに対する従来のアプローチでは、コンテンツをサーバにマルチキャストし、その後、ネットワーク上でコンテンツをマルチキャストするのがふつうである（つまり、ストリームを受信するクライアントからのフィードバックなしで）。サーバは、通常、異なるフォーマット（例えば、ビットレート、言語、符号化法など）を有する複数のストリームでコンテンツをマルチキャストする。ネットワークに接続されているクライアントは、その後、その資源に見合った（複数の）ストリームを受け取ることができる。クライアント側で受信する（複数の）ストリームを選択できるようにするため、１つのマルチキャストアプローチでは、サーバがクライアント側でコンテンツのストリームを開くことができる「マルチキャスト情報」を提供するファイルを供給することが必要である。このファイルの維持およびパブリッシュは、通常、比較的高い管理コストがかかる手作業によるプロセスである。さらに、適切に維持され、パブリッシュされない場合、クライアントに問題が生じ、顧客が不満を抱くことになりかねない。このブローチの他の問題として、コンテンツへのアクセスが正常に行えるように、クライアント側でその「マルチキャスト情報」を最新状態に保持しなければならないという点が挙げられる。この問題は、更新を要求するのに好適な裏チャネルを持たないクライアント（例えば、単一指向性衛星リンクを使用するクライアント）にとってはさらに深刻である。
【０００７】
【特許文献１】「Methods and Systems for Self-Describing Multicasting of Multimedia Presentations」という表題の２００３年１０月２４日に出願した同時係属出願第１０／６９３，４３０号
【非特許文献１】Network Working Group Request for Comments (RFC) 2327
【非特許文献２】Network Working Group Request for Comments (RFC) 2326, April 1998
【非特許文献３】Network Working Group Request for Comments (RFC) 1945, May 1996
【非特許文献４】Network Working Group Request for Comments (RFC) 2068, January 1997
【非特許文献５】Network Working Group Request for Comments (RFC) 3550, July 2003
【非特許文献６】Network Working Group Request for Comments (RFC) 1950, May 1996
【非特許文献７】Network Working Group Request for Comments (RFC) 2974, October 2000
【非特許文献８】Grouping of Media Lines in the Session Description Protocol (SDP) Network Working Group Request for Comments (RFC) 3388, December 2002
【非特許文献９】Specification, IETF RFC-2974, entitled "Session Announcement Protocol"
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ここでは、セッション記述のメッセージをリアルタイム制御プロトコル（ＲＴＣＰ）のメッセージ内に埋め込むことについて説明する。メディアコンテンツソースから受信者に送信されたＲＴＣＰのメッセージの少なくとも一部に埋め込まれるのが、受信者にストリーミングされるメディアプレゼンテーションを記述するセッション記述のメッセージである。
【課題を解決するための手段】
【０００９】
いくつかの態様によれば、セッション記述のメッセージを埋め込むＲＴＣＰのメッセージは、少なくとも３つのフィールドを含む。第１のフィールドは、ＲＴＣＰのメッセージをセッション記述のメッセージを埋め込むタイプであるとして識別するデータを含む。第２のフィールドは、メディアプレゼンテーションに対するセッション記述のメッセージであるデータを含む。第３のフィールドは、第１のフィールドの長さ、第２のフィールドの長さ、および第３のフィールドの長さを足し合わせることで生成された、ＲＴＣＰのメッセージの長さを識別するデータを含む。
【００１０】
他の態様によれば、ＲＴＣＰのメッセージは、サーバ装置などの装置のところで作成される。ＲＴＣＰのメッセージ内に埋め込まれたセッション記述のメッセージは、装置から受信者にストリーミングされるメディアコンテンツの再生リスト内の複数のメディアコンテンツ作品のうちの１つに関連付けられる。
【００１１】
他の態様によれば、マルチメディアプレゼンテーションは、異なるマルチメディア資源のクライアントに対応できるマルチメディアデータの複数のストリームに対する複数のチャネルとともにプレゼンテーション記述情報を含むアナウンスメントチャネル（ａｎｎｏｕｎｃｅｍｅｎｔ  ｃｈａｎｎｅｌ）を使用してマルチキャストされる。クライアントは、アナウンスメントチャネルを使用することにより、そのマルチメディア資源に適する（複数の）チャネルを選択することができる。
【００１２】
他の態様によれば、これらのチャネルは、所定の方法で作成され（例えば、事前に選択された論理アドレス、ＩＰアドレスの事前に選択されたポートなど）、クライアントは、アナウンスメントチャネルを結合せずに（または結合するのと同時に）チャネルを即座に結合し、起動時の待ち時間を短縮することができる。
【００１３】
他の態様によれば、マルチメディアプレゼンテーションの現在のユニットを「リアルタイムよりも高速な」ビットレートで（つまり、マルチメディアストリームのビットレートよりも高速な速度で）あらかじめ選択された数の前のユニットとともに含む複数のデータブロックを供給するアクセラレーションチャネル（ａｃｃｅｌｅｒａｔｉｏｎ  ｃｈａｎｎｅｌ）を作成できる。この機能を使用すると、十分なデータを素早くバッファリングするのに適した資源を持つクライアントは、ユーザにそのマルチメディアデータを提示することを開始することができる。代替として、アクセラレーションチャネルは、「リアルタイムよりも高速である」必要はなく、クライアントは、そのアクセラレーションチャネルと、マルチメディアデータをマルチキャストする他のチャネルの両方を同時実行するように結合して、実際に、クライアントが「リアルタイムよりも高速な」速度でマルチメディアデータを受信するようにできる。
【００１４】
類似のコンポーネントおよび／または図を参照するため本明細書全体を通して同じ番号を使用する。
【発明を実施するための最良の形態】
【００１５】
ここでは、セッション記述のメッセージをリアルタイム制御プロトコル（ＲＴＣＰ）のメッセージ内に埋め込むことについて説明する。マルチメディアまたは単一メディアプレゼンテーションは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットを使用して、サーバ装置などのメディアコンテンツソースからクライアント装置などの受信者にストリーミングされる。ストリーミングされるプレゼンテーションに関する制御情報も、ＲＴＣＰのメッセージを使用して、メディアコンテンツソースから受信者に送信される。ＲＴＣＰのメッセージの少なくとも一部に埋め込まれるのが、ストリーミングされるプレゼンテーションを記述するセッション記述のメッセージである。
【００１６】
本明細書の説明では、メディアコンテンツソースから受信者にストリーミングされるマルチメディアプレゼンテーションを参照する。メディアコンテンツソースは、メディアコンテンツのどのようなソースでもよく、例えばサーバ装置がそうである。受信者は、メディアコンテンツのどのような受信者でもよく、例えばクライアント装置がそうである。さらに、これは、本明細書の説明ではストリーミングされるマルチメディアプレゼンテーションのことであるが、マルチメディアプレゼンテーションに関して本明細書で説明されているのと同じようにして単一メディアプレゼンテーションもストリーミングすることができることは理解されるであろう。
【００１７】
図１は、本明細書で説明されているようなＲＴＣＰのメッセージに埋め込まれたセッション記述のメッセージを使用してメディアストリーミングを実行するために使用することができるネットワーク環境例１００を示す図である。環境１００において、複数の（ａ）クライアントコンピューティング装置１０２（１）、１０２（２）、．．．、１０２（ａ）は、ネットワーク１０６を介して、複数の（ｂ）サーバコンピューティング装置１０４（１）、１０４（２）、．．．、１０４（ｂ）に結合される。ネットワーク１０６は、さまざまな従来のネットワークプロトコル（公開および／または専用プロトコルを含む）のどれかを使用して、さまざまな従来のネットワークトポロジおよびタイプ（有線および／または無線ネットワークを含む）のどれかを表すことが意図されている。例えば、ネットワーク１０６は、インターネットとともに、場合によっては、１つまたは複数のローカルエリアネットワーク（ＬＡＮ）の少なくとも一部を含むことができる。
【００１８】
コンピューティング装置１０２および１０４は、それぞれ、デスクトップＰＣ、ワークステーション、メインフレームコンピュータ、インターネットアプライアンス、ゲーム機、ハンドヘルドＰＣ、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）などを含む、さまざまな従来のコンピューティング装置のうちのどれかとすることができる。装置１０２および１０４の１つまたは複数は、同じ種類の装置、または代替として異なる種類の装置とすることができる。
【００１９】
サーバ装置１０４では、さまざまなデータをクライアント１０２へのストリーミングに利用可能にできる。用語「ストリーミング」は、メディアを表すデータがネットワーク上でクライアント装置に供給され、コンテンツの再生が、そのコンテンツ全体が配送される前に開始できる（例えば、再生する前にデータを丸ごと事前配送するのではなく必要に応じてデータを供給する）ことを示すために使用される。データは、公開利用可能とすることも、それとは別に制約することもできる（例えば、特定のユーザにのみ制限する、適切な料金を支払っている場合のみ利用可能、など）。データは、オーディオ、ビデオ、テキスト、アニメーションなどのさまざまな１つまたは複数のタイプのコンテンツのどれでもよい。さらに、データは、記録済みのデータでも、また代替として、「ライブ」（例えば、コンサート演奏会でキャプチャされ、キャプチャされてまもなくストリーミングに利用できるようにされるコンサートのデジタル表現）データでもよい。
【００２０】
クライアント装置１０２は、ストリーミングメディアコンテンツをファイルとして格納するサーバ１０４、または代替として、他の何らかのソースからストリーミングメディアを受信するサーバ１０４からストリーミングメディアを受信することができる。例えば、サーバ１０４は、ストリーミングメディアコンテンツをファイルとして格納する他のサーバからストリーミングメディアを受信するか、または他の何らかのソース（例えば、「ライブ」イベントを符号化するエンコーダ）からストリーミングメディアを受信することができる。
【００２１】
本明細書で使用されているように、ストリーミングメディアは、一方の装置から他方の装置へ（例えば、サーバ装置１０４からクライアント装置１０２へ）１つまたは複数のメディアストリームをストリーミングすることを指す。メディアストリームは、オーディオ、ビデオ、テキストなどのうちの１つまたは複数などのさまざまなタイプのコンテンツのどれでも含むことができる。
【００２２】
図２は、本明細書で説明されているようなＲＴＣＰのメッセージに埋め込まれたセッション記述のメッセージを使用してメディアコンテンツをストリーミングすることができるクライアントおよびサーバ装置例を示す図である。通常、サーバ装置１０４からクライアント装置１０２へメディアコンテンツをストリーミングするために、クライアント装置１０２とサーバ装置１０４は両方とも、複数の異なるプロトコルに従う。これらの異なるプロトコルは、ストリーミングプロセスの異なる態様に関与することができる。図２には示されていないが、１つまたは複数の追加装置（例えば、ファイヤウォール、ルータ、ゲートウェイ、ブリッジなど）が、クライアント装置１０２とサーバ装置１０４との間に配置可能である。
【００２３】
図２の例において、アプリケーションレベルプロトコル１５０、トランスポートプロトコル１５２、および１つまたは複数の配送チャネルプロトコル１５４は、ストリーミングプロセスの一部として使用されている。図２に示されていない追加プロトコルも、使用することができる（例えば、アプリケーションレベルプロトコル１５０とトランスポートプロトコル１５２との間に（複数の）プロトコルが追加されてもよい）。アプリケーションレベルプロトコル１５０は、リアルタイム特性を持つデータの配送を制御するためのアプリケーションレベルのプロトコルである。アプリケーションレベルプロトコル１５０は、ストリーミングオーディオおよびビデオコンテンツなどのリアルタイムデータをオンデマンドでしかも規制しつつ配送することを可能にする、オプションにより拡張可能な、フレームワークを提供する。アプリケーションレベルプロトコル１５０は、メディアサーバからストリーミングマルチメディアの配送を開始し、配送方向を決める制御プロトコルである。アプリケーションレベルプロトコル１５０の例として、リアルタイムストリーミングプロトコル（ＲＴＳＰ）（例えば、非特許文献２参照）、およびハイパーテキスト転送プロトコル（ＨＴＴＰ）（例えば、非特許文献３または４参照）がある。
【００２４】
アプリケーションレベルプロトコル１５０は、ストリーミングオーディオおよびビデオなどのリアルタイムデータの配送にトランスポートプロトコル１５２を使用する。トランスポートプロトコル１５２は、メディアストリームのパケットフォーマットを定義する。トランスポートプロトコル１５２は、オーディオ、ビデオ、またはシミュレーションデータなどのリアルタイムデータをマルチキャストまたはユニキャストネットワークサービス上で送信するアプリケーションに好適なエンドツーエンドのネットワークトランスポート機能を実現する。トランスポートプロトコル１５２の例として、リアルタイムトランスポートプロトコル（ＲＴＰ）およびリアルタイム制御プロトコル（ＲＴＣＰ）（例えば、非特許文献５参照）がある。ＲＴＰおよびＲＴＣＰの将来のドラフトまたは標準化バージョンなどの他のバージョンも使用できる。ＲＴＰでは、資源予約を取り扱わず、リアルタイムサービスに対するサービス品質を保証しない。データトランスポートは、制御プロトコル（ＲＴＣＰ）により強化されるため、大規模なマルチキャストネットワークに拡張可能な形でデータ配送の監視が可能になり、またある程度の制御および識別機能が備えられる。
【００２５】
ＲＴＣＰプロトコルでは、１つまたは複数の制御メッセージをＲＴＣＰパケットと呼ばれるユニットにまとめる。１つまたは複数のＲＴＣＰ内に、セッション記述のメッセージを含む制御メッセージが埋め込まれる。セッション記述のメッセージは、サーバ装置１０４からクライアント装置１０２にストリーミングされるマルチメディアプレゼンテーションの特性を記述する。サーバ装置１０４からクライアント装置１０２へのストリーミングメディアは、セッション記述のメッセージを含む。
【００２６】
フランスポートプロトコル１５２は、トランスポート接続に対して（複数の）配送チャネルプロトコル１５４を使用する。（複数の）配送チャネルプロトコル１５４は、サーバ装置１０４からクライアント装置１０２へデータのパケットを転送するための１つまたは複数のチャネルを備える。それぞれのチャネルは、通常、単一のメディアストリームのデータパケットを送信するために使用されるが、他の実施形態では、複数のメディアストリームのデータパケットを送信するために使用することができる。配送チャネルプロトコル１５４の例としては、伝送制御プロトコル（ＴＣＰ）パケットおよびユーザデータグラムプロトコル（ＵＤＰ）パケットがある。ＴＣＰでは、データパケットの配送を保証し、ＵＤＰでは、データパケットの配送を保証しない。通常、ＴＣＰを使用したデータパケットの配送は、ＵＤＰを使用したデータパケットの配送に比べて、信頼性が高いが、時間もかかる。
【００２７】
図３は、本明細書で説明されているようなＲＴＣＰのメッセージに埋め込まれたセッション記述のメッセージを使用してメディアコンテンツをストリーミングすることができるマルチキャスト環境におけるクライアントおよびサーバ装置例を示す図である。いくつかの実施形態では、図２のプロトコル１５０、１５２、および１５４は、図３のクライアントおよびサーバ装置に含まれるが、例示されていない。さらに、図３には示されていないが、１つまたは複数の追加装置（例えば、ファイヤウォール、ルータ、ゲートウェイ、ブリッジなど）が、クライアント装置１０２とサーバ装置１０４との間に配置可能である。
【００２８】
サーバ装置１０４のストリーミングモジュール１８２は、同じマルチメディアプレゼンテーションを複数の（ｘ）クライアント装置１０２（１）、１０２（２）、．．．、１０２（ｘ）のそれぞれにストリーミングする。それぞれのクライアント装置１０２は、ストリーミングされるマルチメディアプレゼンテーションを受信し、クライアント装置１０２で受信されたストリームを処理し、通常は、クライアント装置１０２でマルチメディアプレゼンテーションを再生する。同じデータが、それぞれのクライアント装置１０２にほぼ同じ時間にストリーミングされ、サーバ装置１０４は、一度に同じマルチメディアプレゼンテーションを１回分だけストリーミングするので、さまざまなクライアント装置１０２ではストリーミングされているこの１回分を聴取する。
【００２９】
ストリーミングメディア１８６は、１つまたは複数のセッション記述のメッセージが埋め込まれているＲＴＣＰのメッセージを含む。同じセッション記述のメッセージを、マルチメディアプレゼンテーションのストリーミングで複数回ブロードキャストすることができ、それによって、新しいクライアント装置１０２は、ストリーミングの開始後ストリーミングメディアを聴取するが、それでも、マルチメディアプレゼンテーションを記述するセッション記述のメッセージを受信することができる。セッション記述のメッセージをストリーミングメディア１８６のＲＴＣＰのメッセージ内に埋め込むことにより、クライアント装置１０２は、セッション記述のメッセージを受信するために、別のストリームまたはブロードキャストを、場合によってはサーバ装置１８２以外の装置から、聴取する必要はない。
【００３０】
例えば、参照により本明細書に組み込まれている、特許文献１ではマルチキャスト環境の一実施例を説明している。
【００３１】
図４は、本明細書で説明されているようなＲＴＣＰのメッセージに埋め込まれたセッション記述のメッセージを使用してメディアコンテンツをストリーミングすることができるサーバサイド再生リスト環境におけるクライアントおよびサーバ装置例を示す図である。いくつかの実施形態では、図２のプロトコル１５０、１５２、および１５４は、図４のクライアントおよびサーバ装置に含まれるが、例示されていない。さらに、図３には示されていないが、１つまたは複数の追加装置（例えば、ファイヤウォール、ルータ、ゲートウェイ、ブリッジなど）が、クライアント装置１０２とサーバ装置１０４との間に配置可能である。
【００３２】
サーバ装置１０４のストリーミングモジュール２０２は、マルチメディアプレゼンテーションをストリーミングメディア２０４としてクライアント装置１０２のストリーミングメディアプレーヤー２０６にストリーミングする。ストリーミングメディアプレーヤー２０６は、ストリーミングされるマルチメディアプレゼンテーションを受信し、クライアント装置１０２で受信されたストリームを処理し、通常は、クライアント装置１０２でマルチメディアプレゼンテーションを再生する。
【００３３】
サーバ装置１０４は、複数の（ｙ）メディアコンテンツ２１０（１）、２１０（２）、．．．、２１０（ｙ）作品を識別する再生リスト２０８を含む。いくつかの実装では、再生リスト２０８は複数のエントリを含み、それぞれのエントリは複数のメディアコンテンツ２１０作品のうちの１つを識別する。代替として、再生リスト２０８では、単一のメディアコンテンツ作品を識別することができるが、そのような状況では、その単一のメディアコンテンツ作品は、再生リストを使用するのではなく、単純にそれ自体により参照することが可能である。クライアント装置１０２は再生用の単一資源を選択することができ、その資源で再生リスト２０８を識別する。ストリーミングモジュール２０２は、識別された再生リスト２０８にアクセスし、その後、個々のメディアコンテンツ作品２１０にアクセスし、それらの作品２１０をクライアント装置１０２にストリーミングする。そこで、クライアント装置１０２は、単一資源にアクセスすることができるが、それでも、サーバ装置１０４からストリーミングされた異なる複数のメディアコンテンツ作品を持つ。クライアント装置１０２によってではなく、複数のメディアコンテンツ作品を識別するためにサーバ装置１０４により再生リスト２０８がアクセスされ、参照されると、再生リスト２０８は、さらに、サーバサイド再生リストとして参照することもできる。
【００３４】
それぞれのメディアコンテンツ２１０作品は、１つまたは複数のメディアストリームを含む。異なるメディアコンテンツ２１０作品は、異なる数のメディアストリームを含むことができる。それぞれのメディアコンテンツ２１０作品は、通常、マルチメディアプレゼンテーションである。コンテンツの「作品」の定義は、実装により、また媒体のタイプに基づいて異なる場合がある。例えば、音楽オーディオおよび／またはビデオコンテンツの場合、それぞれの楽曲は１つのコンテンツ作品とすることができる。コンテンツは、自然な境界（例えば、異なる楽曲）にそって、または代替として、他の任意の方法で（例えば、５分分のコンテンツが１つの作品）、複数の作品に分けることができる。格納されているコンテンツについては、異なる複数のコンテンツ作品を複数のファイルとして格納するか、または代替として、同じファイルに格納することができる。
【００３５】
図３および４の２つの別々の図面として例示されているが、図４に例示されているようなサーバサイドにより参照される複数のメディアコンテンツ作品を図３に例示されているようにマルチキャストすることができることは理解されるであろう。
【００３６】
図２、３、および４を参照すると、トランスポートレベルで、サーバ装置１０４からクライアント装置１０２にストリーミングされるデータは、ＲＴＰパケット内に埋め込まれる。ストリーミングされるデータおよびＲＴＰパケットに関係する制御情報は、ＲＴＣＰパケット内の１つまたは複数の制御メッセージに埋め込まれる。
【００３７】
通常、ＲＴＣＰパケットは、異なるタイプの複数のメッセージからなる。ＲＴＣＰパケット内の第１のメッセージは、Ｒｅｃｅｉｖｅｒ  ＲｅｐｏｒｔまたはＳｅｎｄｅｒ  Ｒｅｐｏｒｔのいずれかである。第２のメッセージは、ＳＤＥＳ（ソース記述）メッセージである。ＳＤＥＳメッセージは、１つまたは複数のテキストメタデータアイテムを含む。ＳＤＥＳメッセージは、ＣＮＡＭＥ（標準名）アイテムを含む。ＣＮＡＭＥアイテムは、メディアコンテンツソースの永続的トランスポートレベル識別子であり、ＲＴＰ同期ソース（ＳＳＲＣ）数とテキスト文字列との間のマッピングを実現する。ＳＳＲＣは、ＲＴＰ（およびＲＴＣＰ）パケットのソースである。ＣＮＡＭＥは、同じプレゼンテーションに属する複数のＲＴＰセッションに参加している送信者または受信者は、それぞれのＲＴＰセッションで異なるＳＳＲＣ値を使用するが、ＣＮＡＭＥ値を同じに保てるように使用される。
【００３８】
ＲＴＣＰパケットに入れることができるメッセージの追加タイプは、セッション記述のメッセージを埋め込まれている制御メッセージである。セッション記述のメッセージは、サーバ装置１０４からクライアント装置１０２にストリーミングされるマルチメディアプレゼンテーションの特性を記述する。異なるメディアフォーマットまたはプロトコルをそのようなセッション記述のメッセージに対し使用することができる。そのようなメディアフォーマットの一例は、セッション記述プロトコル（ＳＤＰ）（例えば、非特許文献１参照）である。いくつかの実施形態では、本明細書で説明されているセッション記述のメッセージは、非特許文献１で説明されているＳＤＰフォーマットによるメッセージである。
【００３９】
マルチメディアプレゼンテーションの特性を記述するのに異なるフォーマットを使用できるが、それらの特性の（複数の）識別子を含む１つまたは複数のセッション記述のメッセージがサーバ装置１０４からクライアント装置１０２に送信される。サーバ装置１０４により特定のマルチメディアプレゼンテーションのため単一のセッション記述のメッセージが送信されるか、または代替として、複数のセッション記述のメッセージが送信されるようにできる。複数のセッション記述のメッセージが送信される場合、複数のメッセージは、同じ情報、異なる情報、または重複する情報を含むことができる。
【００４０】
セッション記述のメッセージは、例えば、マルチメディアプレゼンテーションをマルチキャストするために使用されるさまざまなチャネルの識別、マルチメディアプレゼンテーションで利用可能なそれぞれのメディアストリームの記述（例えば、ストリームのタイプ（例えば、ビデオをまたはオーディオ）、それぞれのメディアストリームのビットレート、ストリーム内で使用される言語などを示す）、誤り訂正情報、セキュリティ／認証情報、暗号化情報、またはデジタル権利管理（ＤＲＭ）情報などのうちの１つまたは複数を含む。
【００４１】
特定の状況において、セッション記述のメッセージは、複数のＲＴＣＰ制御メッセージにまたがって分けられるか、または断片化されることが可能であることに留意されたい。このような状況は、例えば、セッション記述のメッセージは非常に大きい場合に生じることがある。これらのＲＴＣＰ制御メッセージはそれぞれ、異なるＲＴＣＰパケットに含まれ、それぞれセッション記述のメッセージ全体の一部分つまり断片を含む。クライアント装置１０２は、それらの部分または断片のすべてを受信した後、それらを組み合わせて１つにし、セッション記述のメッセージを再作成することができる。
【００４２】
図５は、埋め込まれたセッション記述のメッセージを持つＲＴＣＰ制御メッセージ２５０のフォーマット例を示す図である。ＲＴＣＰのメッセージ２５０は、以下では、複数のフィールド（部分ともいう）を含み、それぞれさまざまなデータを格納するものとして説明されている。これらのフィールドは、以下で説明され、図５に示されている順序と異なる順序で配列できることは理解されるであろう。さらに、これらのフィールドのサイズまたは長さ（例えば、ビット単位の）は以下で説明されているが、これらは例にすぎず、これらのフィールドは、それとは別に、この例のサイズまたは長さよりも大きくても、小さくてもよいことは理解されるであろう。いくつかの実施形態では、ＲＴＣＰのメッセージ２５０は、図５に示されているすべてのフィールドを含む。他の実施形態では、ＲＴＣＰのメッセージ２５０は、図５に示されているすべてのフィールドではなく一部のフィールドを含むか、または図５に示されていない追加フィールドを含むことができる。
【００４３】
ＲＴＣＰのメッセージ２５０のフィールドは、ヘッダ２９０、ＲＴＰ−Ｓｔａｔｅブロック２９２、およびセッション記述のメッセージ２８４の３つのグループに分けられるとみなすことができる。ヘッダ２９０は、ＲＴＣＰのメッセージ２５０に関するさまざまな情報を含む。ＲＴＰ−Ｓｔａｔｅブロック２９２は、オプションであり、含まれる場合、セッション記述のメッセージ内に記述されるマルチメディアプレゼンテーションのストリームに関するＲＴＰ特有の情報を識別するために使用される（例えば、セッション記述のメッセージでストリームのＳＳＲＣおよび初期ＲＴＰシーケンス番号を指定するために）。通常、１つのＲＴＰ−Ｓｔａｔｅブロック２９２は、マルチメディアプレゼンテーション内の各メディアストリームに対するＲＴＣＰのメッセージ２５０に関連付けられ、そこに含まれる。セッション記述のメッセージ２８４は、ＲＴＣＰのメッセージ２５０内に埋め込まれたセッション記述のメッセージである。
【００４４】
Ｖ（バージョン）フィールド２５２は、使用されるＲＴＰのバージョンを識別する２ビットフィールドであり、ＲＴＰパケットでのようにＲＴＣＰでも同じである。例えば、非特許文献５により定義されたバージョンは２である。
【００４５】
Ｐ（パディング）フィールド２５４は、セットされた場合（例えば、値１に）、ＲＴＣＰのメッセージ２５０は制御情報の一部ではない追加パディングを末尾のところに含むことを示す単一ビットである。このパディングは、長さフィールド２６２に含まれるが、そうでなければ、無視すべきである。パディングの大きさは、パディング自体の中に含まれる。いくつかの実装では、追加パディングはオクテット単位であり、パディングの最後のオクテットは、含まれるパディングオクテットの個数（それ自体を含む）であり、したがって、無視すべきである。
【００４６】
Ｃ（圧縮）フィールド２５６は、セットされた場合（例えば、値１を持つ）、ＳＤＰデータフィールド２８４内のデータが圧縮されていることを示す単一ビットである。ＺＬＩＢ  Ｃｏｍｐｒｅｓｓｅｄ  Ｄａｔａ  Ｆｏｒｍａｔ  Ｓｐｅｃｉｆｉｃａｔｉｏｎバージョン３．３（例えば、非特許文献６参照）に記載されているようなＺｌｉｂ圧縮を使用するなど、異なるタイプの圧縮を使用できる。
【００４７】
Ｒｅｓ（予約）フィールド２５８は、４ビット予約フィールドである。いくつかの実装では、Ｒｅｓフィールド２５８は０にセットされなければならない。
【００４８】
ＰＴ（ペイロードタイプ）ヘッダフィールド２６０は、ＲＴＣＰのメッセージ２５０がセッション記述のメッセージを埋め込んでいることを示す値（例えば、１４１）にセットされた７ビットフィールドである。
【００４９】
Ｌｅｎｇｔｈフィールド２６２は、ＲＴＣＰのメッセージ２５０の長さを識別する１６ビットフィールドである。この長さは、任意のヘッダと任意のパディングを含む、ＲＴＣＰのメッセージ２５０内のさまざまなフィールドの長さを足し合わせることにより生成することができる。いくつかの実装では、長さは３２ビット数量から１を引いた値で識別される。
【００５０】
ＳＤＰＭｓｇＨａｓｈ（ＳＤＰメッセージハッシュ）フィールド２６４は、ＲＴＣＰのメッセージ２５０に含まれるセッション記述のメッセージおよび送信者（例えば、サーバ装置１０４）のアドレス（例えば、ＩＰアドレス）を識別するために使用される１６ビットフィールドである。いくつかの実装では、フィールド２６４内の識別子は、セッション記述のメッセージおよびアドレスに対するチェックサムとして計算され、そのため、いずれかの変更があれば、フィールド２６４内の識別子の値も変更される。いくつかの実装では、ＳＤＰＭｓｇＨａｓｈフィールド２６４は、セッションアナウンスメントプロトコル（ＳＡＰ）（例えば、非特許文献７参照）に記載されている「ｍｓｇ  ｉｄ  ｈａｓｈ」フィールドと同じようにして計算される。以下で説明されているように、セッション記述のメッセージが複数のＲＴＣＰのメッセージに断片化されている場合、各断片のＳＤＰＭｓｇＨａｓｈフィールド２６４の値は、同一でなければならない。
【００５１】
Ｆ（断片追加）フィールド２６６は、セットされた場合（例えば、値１を持つ）、セッション記述のメッセージが複数のＲＴＣＰのメッセージに断片化されており、現在のＲＴＣＰのメッセージはセッション記述のメッセージの最後の断片を含んでいないことを示す、単一ビットである。Ｆフィールド２６６がセットされていない場合（例えば、値０を持つ）、セッション記述のメッセージは断片化されていないか（完全なセッション記述のメッセージがＲＴＣＰのメッセージ２５０内に含まれる）、またはセッション記述のメッセージは断片化されており、ＲＴＣＰのメッセージ２５０はセッション記述のメッセージの最後の断片を含む。
【００５２】
ＦｒａｇＳｅｑＮｕｍ（断片シーケンス番号）フィールド２６８は、セッション記述のメッセージを異なる複数の断片を識別するために使用される１５ビットフィールドである。セッション記述のメッセージの断片は、サーバ装置１０４とクライアント装置１０２の両方に認識されている何らかの方法で識別子を割り当てられる。例えば、これらの識別子は、０から順次始まる値を割り当てられ、したがって、第１のセグメントは値０を持ち、第２のセグメントは値１を持ち、第３のセグメントは値２を持ち、というように続く。ＲＴＣＰのメッセージ２５０がセッション記述のメッセージの断片を含まない場合（つまり、ＲＴＣＰのメッセージ２５０は完全なセッション記述のメッセージを含む）、ＦｒａｇＳｅｑＮｕｍ  ２６８は、０にセットされなければならない。
【００５３】
ＮｕｍＲｔｐＳｔａｔｅ（ＲＴＰ状態数）フィールド２７０は、ＲＴＣＰのメッセージ２５０に含まれるＲＴＰ−Ｓｔａｔｅブロックの数を指定するために使用される１６ビットフィールドである。それぞれのＲＴＰ−Ｓｔａｔｅブロックのサイズは１４バイトである。「ＮｕｍＲｔｐＳｔａｔｅ」フィールドは、ＲＴＰ−Ｓｔａｔｅブロックが存在していない場合には０にセットされる。ＲＴＣＰのメッセージ２５０の示されている例では、１つのＲＴＰ−Ｓｔａｔｅブロック２９２がある。複数のＲＴＰ−Ｓｔａｔｅブロックがある場合、フィールド２７２、２７４、２７６、２７８、２８０、および２８２は、複数のＲＴＰ−Ｓｔａｔｅブロックのそれぞれについて含まれる。セッション記述のメッセージが複数のＲＴＣＰのメッセージ２５０に断片化される場合、セッション記述のメッセージの第１の断片を含むＲＴＣＰのメッセージ２５０のみが（複数の）ＲＴＰ−Ｓｔａｔｅブロックを含んでいなければならない。
【００５４】
Ａフィールド２７２は、ＰＴフィールド２７４が有効なＲＴＰペイロードタイプ番号を含む場合にセットされない（例えば、値０を持つ）１ビットフィールドである。Ａフィールド２７２がセットされない場合、ＲＴＰ−Ｓｔａｔｅブロック２９２内の情報は、ＰＴフィールド２７４で識別されるＲＴＰ  Ｐａｙｌｏａｄ  Ｔｙｐｅ番号およびＦｌｏｗ  ＩＤフィールド２７２で識別されるＳＤＰ  Ｆｌｏｗ  ＩＤにのみ適用される。Ａフィールド２７２がセットされる場合（例えば、値１を持つ）、ＰＴフィールド２７４は無視されるべきであり、ＲＴＰ−Ｓｔａｔｅブロック２９２は、使用されるＲＴＰ  Ｐａｙｌｏａｄ  Ｔｙｐｅに関係なくＦｌｏｗ  ＩＤフィールド２７６で識別されたＳＤＰ  Ｆｌｏｗ  ＩＤに対するすべてのＲＴＰパケットに適用される。
【００５５】
ＰＴフィールド２７４は、ＲＴＰ−Ｓｔａｔｅブロック２９２に含まれる情報のＲＴＰ  Ｐａｙｌｏａｄ  Ｔｙｐｅ番号を指定する７ビットフィールドである。Ａフィールド２７２がセットされている場合（例えば、値１を持つ）、ＰＴフィールド２７４は使用されず、０にセットされるべきである。
【００５６】
Ｆｌｏｗ  ＩＤフィールド２７６は、ＲＴＰ−Ｓｔａｔｅブロック２９２に含まれる情報の参照先であるＳＤＰ  Ｆｌｏｗ  ＩＤを識別する２４ビットフィールドである。それぞれのメディアストリームは、異なるＲＴＰセッション上でストリーミングされる。これらのＲＴＰセッションは、「ａ＝ｍｉｄ：」属性を使用して番号を割り当てられる（例えば、非特許文献８を参照）。Ｆｌｏｗ  ＩＤフィールド２７６は、セッション記述のメッセージ内の特定の「ｍ＝」エントリを識別するが、これは「ｍ＝」エントリの「ａ＝ｍｉｄ」属性（非特許文献８による）に対する値と同じである。
【００５７】
ＳＳＲＣ（同期ソース）フィールド２７８は、Ｆｌｏｗ  ＩＤフィールド２７６により識別されるメディアストリームに使用されるＲＴＰ  ＳＳＲＣフィールド値を指定する３２ビットフィールドである。Ａフィールド２７２がセットされない場合（例えば、値０を持つ）、ＳＳＲＣフィールド２７８は、ＰＴフィールド２７４により与えられるＲＴＰ  Ｐａｙｌｏａｄ  Ｔｙｐｅを使用するこのメディアストリームに対するＲＴＰパケットにのみ適用される。
【００５８】
ＲｔｐＴｉｍｅ（ＲＴＰ時間）フィールド２８０は、ＲＴＰパケットがＦｌｏｗ  ＩＤフィールド２７６により識別されたメディアストリームの正確に先頭のところで送信された場合に持つであろうＲＴＰ  Ｔｉｍｅｓｔａｍｐフィールドの値を指定する３２ビットフィールドである。例えば、メディアプレゼンテーションのタイムラインが時刻Ｔで始まった場合、ＲｔｐＴｉｍｅフィールド２８０の値は、Ｒｔｐ−Ｓｔａｔｅブロック２９２により識別されたメディアストリームに対しそのようなＲＴＰパケットが実際に存在しているとしても、ちょうど時刻Ｔに送信されるであろうパケットのＲＴＰ  Ｔｉｍｅｓｔａｍｐフィールドの値である。
【００５９】
ＲｔｐＳｅｑ（ＲＴＰシーケンス）フィールド２８２は、Ｆｌｏｗ  ＩＤフィールド２７６により識別されたメディアストリームに対し送信される第１のＲＴＰパケットのＲＴＰシーケンス番号フィールドの値を与える１６ビットフィールドである。Ａフィールド２７２がセットされない場合（例えば、値０を持つ）、ＲｔｐＳｅｑフィールド２８２は、ＰＴフィールド２７４により与えられるＲＴＰ  Ｐａｙｌｏａｄ  Ｔｙｐｅを使用するこのメディアストリームに対するＲＴＰパケットにのみ適用される。
【００６０】
ＳＤＰデータフィールド２８４は、ＲＴＣＰのメッセージ２５０内に埋め込まれたセッション記述のメッセージである。セッション記述のメッセージが断片化される状況では、ＳＤＰデータフィールド２８４は、セッション記述のメッセージの一部しか含まない（例えば、セッション記述のメッセージの単一断片）。いくつかの実装では、セッション記述のメッセージは、ＵＴＦ−８形式の完全なＳＤＰ記述である。
【００６１】
図６は、セッション記述のメッセージフォーマット例を示す図である。図６の具体例として例示されているが、セッション記述のメッセージは、異なる順序の、または代替として、異なる複数のメッセージにまたがって分散された、複数のフィールドまたは部分を含む形式を持つことも可能である。
【００６２】
セッション記述のメッセージ３２０は、セッションレベル記述部分３２２および０またはそれ以上のメディアレベル記述部分３２４を含む。セッションレベル記述部分３２２は、セッション全体およびセッションの一部であるすべてのメディアストリームに適用されるデータを持つ１つまたは複数のフィールドを含む。他方、それぞれのメディアレベル記述部分３２２は、単一メディアストリームにのみ適用されるデータを持つ１つまたは複数のフィールドを含む。
【００６３】
メディアレベルへ記述部分３２２内のデータフィールドは、特定のメディアストリームの特性を記述する。これらの特性は、セッションレベル記述部分３２２に記述されている特性に加わるもの、またはセッションレベル記述部分３２２に記述されている特性に代わるものとすることができる。例えば、特定のメディアレベル記述部分３２２における１つまたは複数の特性は、その特定のメディアレベル記述部分３２２に関連する特定のメディアストリームに関して、セッションレベル記述部分３２２で識別された特性をオーバーライドすることができる。
【００６４】
セッション記述のメッセージ３２０、およびメッセージ３２０の構造は、特にＳＤＰに関して、以下でさらに詳しく説明される。これらの特定の構造は、例にすぎず、セッション記述のメッセージは異なる形態をとることができることは理解されるであろう。
【００６５】
セッションレベル記述部分３２２は、ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎフィールドと呼ばれる、特定のフィールドから始まる。同様に、メディアレベル記述部分３２４は、それぞれ、ｍｅｄｉａ  ｎａｍｅ  ａｎｄ  ｔｒａｎｓｐｏｒｔ  ａｄｄｒｅｓｓフィールドと呼ばれる、特定のフィールドから始まる。いくつかの実施形態では、同じタイプの複数のフィールドをセッション記述のメッセージに含めることができる（例えば、単一セッション記述のメッセージは、２つ以上のａｔｔｒｉｂｕｔｅフィールドを持つことができる）。
【００６６】
以下の表Ｉは、セッションレベル記述部分３２２に含めることができるフィールド例を示している。表Ｉは、それぞれのフィールド例に対する名前、それぞれのフィールド例に対する略号またはタイプ、およびそれぞれのフィールド例の簡単な説明を含む。いくつかの実施形態では、ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎフィールド、ｏｗｎｅｒ／ｃｒｅａｔｏｒ  ａｎｄ  ｓｅｓｓｉｏｎ  ｉｄｅｎｔｉｆｉｅｒフィールド、ｓｅｓｓｉｏｎ  ｎａｍｅフィールド、およびｔｉｍｅ  ｄｅｓｃｒｉｐｔｉｏｎフィールドは必須であるが、表Ｉの他のフィールドはすべてオプションである。
【００６７】
【表１】
2007509573.tif 000003
【００６８】
以下の表ＩＩは、ｔｉｍｅ  ｄｅｓｃｒｉｐｔｉｏｎフィールドをさらに詳しく説明したものである。表ＩＩは、ｔｉｍｅ  ｄｅｓｃｒｉｐｔｉｏｎフィールド内の各フィールドに対する名前、ｔｉｍｅ  ｄｅｓｃｒｉｐｔｉｏｎフィールド内の各フィールドに対する略号またはタイプ、およびｔｉｍｅ  ｄｅｓｃｒｉｐｔｉｏｎフィールド内の各フィールドの簡単な説明を含む。ｔｉｍｅ  ｔｈｅ  ｓｅｓｓｉｏｎ  ｉｓ  ａｃｔｉｖｅフィールドは必須であるが、ｚｅｒｏ  ｏｒ  ｍｏｒｅ  ｒｅｐｅａｔ  ｔｉｍｅｓフィールドはオプションである。
【００６９】
【表２】
2007509573.tif 000004
【００７０】
以下の表ＩＩＩは、メディアレベル記述部分３２４に含めることができるフィールド例を示している。表ＩＩＩは、それぞれのフィールド例に対する名前、それぞれのフィールド例に対する略号またはタイプ、およびそれぞれのフィールド例の簡単な説明を含む。いくつかの実施形態では、ｍｅｄｉａ  ａｎｎｏｕｎｃｅｍｅｎｔフィールドは必須であるが、表ＩＩＩ内の他のすべてのフィールドはオプションである。
【００７１】
【表３】
2007509573.tif 000005
【００７２】
図７は、サーバサイド再生リストを使用した場合にＲＴＣＰのメッセージにセッション記述のメッセージを埋め込むためのプロセス例３５０を示すフローチャートである。図７は、サーバ装置１０４（例えば、図１、２、３、また４の）などのメディアコンテンツソースにより実行される活動を示している。
【００７３】
最初、再生リスト内のメディアコンテンツの次の作品が識別される（活動３５２）。メディアコンテンツの作品の再生が開始すると、次の作品が再生リスト内で識別されている最初の作品となる。さらに、コンテンツの１作品の終了に達する毎に（例えば、クライアント装置１０２での作品の再生がまだ完了していない可能性が高くても、コンテンツの作品全体がクライアント装置１０２にストリーミングされている）、メディアコンテンツの次の作品は、終了に達した作品に続く作品である。この次の作品は、再生リスト内で展示された順序で並んでいるか、またはユーザが、再生リスト内の異なる作品にナビゲートすることができる場合のあることに留意されたい（例えば、ユーザは、再生リスト内の特定の作品をスキップするか、または飛び越えることを要求できる場合がある）。
【００７４】
この後、メディアコンテンツの識別された作品を記述する情報が得られる（活動３５４）。この情報は、１つまたは複数の異なる方法で取得することができる。この情報を取得する１つの方法は、ファイルまたはレコードから取り出すことである。いくつかの実施形態では、情報の少なくとも一部は、メディアコンテンツの識別された作品に関連付けられたファイルまたはレコード内に格納される。このファイルまたはレコードは、その中に格納されている情報取り出すために活動３５４でアクセスされる。
【００７５】
この情報を取得する１つの方法は、人間のユーザから受け取ることである。いくつかの実施形態では、情報の少なくとも一部は、人間のユーザから受信される。これらのユーザ入力は、活動３５４で、セッション記述のメッセージに含める情報の少なくとも一部として使用される。
【００７６】
この情報を取得するもう１つの方法は、自動検出である。いくつかの実施形態では、情報の少なくとも一部は、コンピューティング装置でメディアコンテンツの識別された作品のソースまたはメディアコンテンツの識別された作品自体を分析することにより自動的に取得することができる。この自動検出された情報は、活動３５４で、セッション記述のメッセージに含める情報の少なくとも一部として使用される。
【００７７】
その後、取得された情報を含むセッション記述のメッセージを持つＲＴＣＰのメッセージが作成される（活動３５６）。いくつかの実施形態では、ＲＴＣＰのメッセージは、上述の図５のＲＴＣＰのメッセージ２５６の形をとる。次に、作成されたＲＴＣＰのメッセージは、メディアコンテンツの次の作品の意図された受信者へ送信される（活動３５８）。メディアコンテンツの次の作品の意図された受信者は、メディアコンテンツのストリーミング先である装置である（例えば、図１、２、３、または４のクライアント装置１０２。作成されたＲＴＣＰのメッセージは、意図された受信者へストリーミングされるストリーミングメディアの一部として含まれるＲＴＣＰパケットに含まれる。
【００７８】
再生リストで識別されているメディアコンテンツの２つの異なる作品についてストリーミングされるメディアストリームの個数が異なるような状況が発生しうることに留意されたい。例えば、再生リストで識別されているメディアコンテンツの第１の作品は２つのストリーム（例えば、オーディオストリームとビデオストリーム）を持つことができるが、再生リストで識別されたメディアンコンテンツの第２の作品は３つのストリーム（例えば、オーディオストリーム、ビデオストリーム、およびテキストサブタイトルストリーム）を持つことができる。さらに、ＵＤＰを使用してメディアをストリーミングする場合、それぞれのメディアストリームは、通常、異なるＵＤＰポートで受信者に届いた異なるＵＤＰチャネルを使用している。受信者がメディアコンテンツの第１の作品に対して２つのポートしか開いていなかった場合（例えば、オーディオストリームに１つのポート、ビデオストリームに１つのポート）、受信者がメディアコンテンツの第２の作品のテキストサブタイトルストリームを受信するために利用できるポートはないことになる。
【００７９】
このような状況は、異なる方法で解決できる。いくつかの実施形態では、このような状況は、ＴＣＰを使用して開いているＨＴＴＰ接続を介して（複数の）追加メディアストリームをストリーミングすることにより解決される。この方法で（複数の）追加メディアストリームがストリーミングされていることを示す情報がＲＴＣＰのメッセージ２５０に含まれる（例えば、各追加メディアストリームに対する追加ＲＴＰ−Ｓｔａｔｅブロック２９２として）。
【００８０】
他の実施形態では、このような状況は、ワイルドカードポートと呼ばれることの多い、１つまたは２つの付加的ポートを受信者に開いてもらうことにより解決される。これらのワイルドカードポートのそれぞれを使用して、サーバ装置が受信者に送信するメディアストリームを受信することができる。（複数の）追加メディアストリームが複数のワイルドカードポートのうちのどれにストリーミングされているかを示す情報が、ＲＴＣＰのメッセージ２５０に含まれる（例えば、各追加メディアストリームに対する追加ＲＴＰ−Ｓｔａｔｅブロック２９２として）。
【００８１】
他の実施形態では、このような状況は、サーバ装置がメディアコンテンツの第２の作品に対して利用可能なメディアストリームのすべてを識別するセッション記述のメッセージを受信者に（例えば、ＲＴＣＰのメッセージ２５０で）送信することにより解決される。その後、サーバ装置は、受信者が受信を望んでいるメディアストリームを受信者が選択するのを待つ。受信者は、選択を行い（例えば、自動的に、または受信者側でのユーザ入力に基づいて）、サーバ装置に、どの（複数の）メディアストリームが選択されたか、選択された（複数の）メディアストリームをどのポートにストリーミングするかを示す情報を送信する。
【００８２】
図８は、サーバサイド再生リストを使用した場合にＲＴＣＰのメッセージにセッション記述のメッセージを受信するためのプロセス例３８０を示すフローチャートである。図８は、クライアント装置１０２（例えば、図１、２、３、また４の）などのストリーミングメディアの受信者により実行される活動を示している。
【００８３】
最初に、ＲＴＣＰのメッセージは、メディアコンテンツソースから受信される（活動３８２）。メディアコンテンツソースは、例えば、図１、２、３、または４のサーバ装置１０４である。
【００８４】
再生リスト内のメディアコンテンツの次の作品に対するセッション記述のメッセージがＲＴＣＰのメッセージから抽出される（活動３８４）。再生リスト内のメディアコンテンツの複数の作品のストリーミングが始まったばかりであれば、メディアコンテンツのこの次の作品が再生リスト内のメディアコンテンツの最初の作品となる。メディアコンテンツの複数の作品のうちの少なくとも１つのストリーミングが開始した後、メディアコンテンツの次の作品が再生リスト内で識別されている次の作品となる。この次の作品は、再生リスト内で展示された順序で並んでいるか、またはユーザが、再生リスト内の異なる作品にナビゲートすることができる場合のあることに留意されたい（例えば、ユーザは、再生リスト内の特定の作品をスキップするか、または飛び越えることを要求できる場合がある）。また、メディアコンテンツの次の作品に対するセッション記述のメッセージは、通常、（メディアコンテンツの現在の作品の再生が終了したときにクライアント装置１０２がメディアコンテンツの次の作品の再生を即座に開始できるように）終了されようとしているメディアコンテンツの現在の作品の再生の前に受信されることに留意されたい。
【００８５】
その後、抽出されたセッション記述のメッセージは、メディアコンテンツの次の作品の処理で使用される（活動３８６）。この処理は、通常、クライアント装置１０２におけるメディアコンテンツの次の作品の再生を含む。
【００８６】
図９は、一実施形態により、マルチメディアプレゼンテーションをマルチキャストするシステム５００を例示している。この実施形態では、システム５００は、ネットワーク５０８を介してサーバ５０４に接続されているコンテンツソース５０２、サーバ５０４、およびクライアント５０６１〜５０６ｘを備える。ネットワーク５０８は、有線（光ファイバを含む）または無線ネットワーク（例えば、ＲＦまたは自由空間光学系）の適当なタイプとすることができる。一実施形態では、ネットワーク５０８はインターネットであるが、他の実施形態では、ネットワーク５０８はローカルエリアネットワーク（ＬＡＮ）、キャンパスエリアネットワークなどとすることもできる。
【００８７】
この実施形態では、サーバ５０４はアナウンスメントジェネレータ５１０を含む。以下でさらに詳しく説明するが、アナウンスメントジェネレータ５１０の実施形態は、ネットワーク５０８上でマルチキャストされるマルチメディアプレゼンテーションに関する情報を含むストリームを生成する。マルチメディアプレゼンテーションをマルチキャストするシステム５００の実施形態の操作について、図１０から図１２を参照しつつ以下で説明する。
【００８８】
図１０は、一実施形態による、マルチメディアプレゼンテーションをマルチキャストする際の図９のシステム５００５００のサーバの動作の流れを例示している。図９および５０２を参照すると、サーバ５０４は以下のようにマルチメディアプレゼンテーションをマルチキャストする動作をする。
【００８９】
ブロック５２４で、サーバ５０４は、接続５１２を介してマルチメディアプレゼンテーションを受け取る。この実施形態では、サーバ５０４は、リンク５１２を介してコンテンツソース５０２からマルチメディアプレゼンテーションを受信する。特に、コンテンツソース５０２は、ネットワーク５０８上でマルチキャストされるマルチメディアコンテンツを供給する。マルチメディアコンテンツは、適当な方法で生成することができる。例えば、マルチメディアコンテンツは、データストア（図に示されていない）にその後格納されるすでに記録／生成済みのコンテンツであるか、またはキャプチャされ（例えば、ビデオカメラ、マイクなど）符号化された（エンコーダは示されていない）ライブパフォーマンスとすることができる。
【００９０】
典型的なアプリケーションでは、マルチメディアプレゼンテーションは複数のストリームを含む。例えば、マルチメディアプレゼンテーションは、ビデオストリーム、オーディオストリーム、低いビットレートで符号化された他のビデオストリーム、および低いビットレートで符号化された他のオーディオストリームを含むことができる。他のアプリケーションでは、マルチメディアプレゼンテーションに設定されるストリームは、このアプリケーション例で説明されているのよりも多い場合も少ない場合もある。したがって、この実施形態では、サーバ５０４は、ブロック５２４において１つまたは複数のストリームの形でマルチメディアプレゼンテーションを受信する。
【００９１】
ブロック５２６で、サーバ５０４は、アナウンスメントストリームを形成し、リンク５１４を介してネットワーク５０８上でそのアナウンスメントストリームをマルチキャストする。この実施形態では、サーバ５０４のアナウンスメントジェネレータ５１０は、アナウンスメントストリームを形成する。いくつかの実施形態では、アナウンスメントジェネレータ５１０は、管理者により構成することができるが、他の実施形態では、アナウンスメントジェネレータ５１０は、ブロック５２４で受信された（複数の）ストリームを処理し、その（複数の）ストリームから情報を抽出し、アナウンスメントストリームを形成するように構成することができる。
【００９２】
いくつかの実施形態では、サーバ５０４は、専用アナウンスメントチャネル（つまり、他のマルチメディアプレゼンテーションに関係するアナウンスメント情報なしのチャネル）上でアナウンスメントストリームをマルチキャストする。この文脈で使用されているように、チャネルは、マルチキャストインターネットプロトコル（ＩＰ）アドレスおよびポートなどの論理アドレスとすることができる。したがって、クライアントは、チャネルに関連付けられた論理アドレスおよびポートで受信を待つ形でチャネルに参加することができる。クライアントは、限定はしないが、電子メール、招待、Ｗｅｂサイト投稿、および従来のセッションアナウンスメントプロトコル（ＳＡＰ）マルチキャスト（例えば、非特許文献９での定義を参照）などの適当な方法で論理アドレスを知ることができる。ＳＡＰマルチキャストを使用してマルチメディアプレゼンテーションをアナウンスする実施形態では、ＳＡＰマルチキャストは、「インライン」アナウンスメントストリーム（以下で詳述する）で供給されるであろう詳細なプレゼンテーション記述情報を含む必要はない。
【００９３】
いくつかの実施形態では、アナウンスメントストリームは、マルチメディアデータを含むストリームと「インライン」でマルチキャストされる。例えば、マルチメディアデータのストリームは、リアルタイムトランスポートプロトコル（ＲＴＰ）によるパケットを使用してマルチキャストすることができ、アナウンスメントストリームは、リアルタイムトランスポート制御プロトコル（ＲＴＣＰ）によるパケットを使用してマルチキャストすることができる。一実施形態では、ＲＴＰは非特許文献５（ＲＴＣＰの規格も含む）で定義されている。この実施形態では、ＲＴＰは、ＲＴＣＰパケットでアナウンスメントデータをサポートするように拡張されている。他の精密化では、アナウンスメントデータは、マルチメディアデータと同じＲＴＰパケット（または他のプロトコルパケット／データグラム）により「インライン」で送信することができる。他の実施形態では、アナウンスメントチャネルは、帯域外とすることができる（例えば、アナウンスメントシャネルがＳＡＰを使用してマルチキャストされる場合）。
【００９４】
アナウンスメントストリームは、例えば、マルチメディアプレゼンテーションをマルチキャストするために使用されるさまざまなチャネルの識別（例えば、ストリームのタイプ（例えば、ビデオまたはオーディオ）、ストリームのビットレート、ストリームで使用される言語などを示す）であってチャネル、誤り訂正情報のそれぞれによりトランスポートされる識別、暗号化情報、デジタル権利管理（ＤＲＭ）情報などのマルチメディアプレゼンテーションを記述する情報を含む。一実施形態では、アナウンスメントストリームは、マルチメディアプレゼンテーションにおいて繰り返しマルチキャストされ、したがって、別のときに参加するクライアントであってもそのマルチメディア記述情報を受け取ることができる。アナウンスメントストリームを介してこのプレゼンテーション記述情報を受信したクライアントは、その後、その資源に照らし合わせて参加するのに適当な（複数の）チャネルを決定することができる。
【００９５】
ブロック５２８で、サーバ５０４は、ブロック５２４で受信されたマルチメディアプレゼンテーションの（複数の）ストリームから選択された（複数の）ストリームをマルチキャストする。いくつかのシナリオにおいて、サーバ５０４は、ブロック５２４で受信されたストリームすべてをマルチキャストする。いくつかの実施形態では、管理者側が、あらかじめ選択されたチャネルで特定のストリームをマルチキャストするようにサーバ５０４を構成することができる。一実施形態では、サーバ５０４は、少なくとも、アナウンスメントチャネル、ビデオチャネル、およびオーディオチャネルをサポートする。より一般的には、サーバ５０４は、さらに、マルチメディアプレゼンテーションを処理するために利用可能な異なる資源を持つクライアントに対応するために異なるビットレートのビデオおよびオーディオストリームの追加チャネルをサポートする。
【００９６】
例えば、図１１に示されているように、サーバ５０４は、アナウンスメントチャネル５３２、アクセラレーションチャネル５３４（図１５および１６に関して以下で説明されている）、高品質ビデオチャネル５３６、高品質オーディオチャネル５３８、アプリケーションチャネル５４０、代替言語チャネル５４２１〜５４２Ｎ、および代替ビットレートチャネル５４４１〜５４４Ｍ（オーディオおよび／またはビデオストリーム用）をサポートするように構成することができる。一実施形態では、アプリケーションチャネル５４０を使用して、クライアントのローカルで実行されることが予期されているアプリケーションにより使用されるデータをマルチキャストすることができる（例えば、メディアプレーヤー、Ｍｉｃｒｏｓｏｆｔ  ＰｏｗｅｒＰｏｉｎｔ（登録商標）データなどのマルチキャストされたアプリケーションデータを使用するためにプラグインを出ようとする場合のある他のアプリケーション）。コンテンツソース５０２により供給されるストリームおよびサーバ５０４の構成、およびチャネルのあらかじめ選択された定義に応じて、サーバ５０４は、１つのストリームをただ１つのチャネルにのみ、複数のチャネルにマッピングするか、またはどのチャネルにもマッピングしないようにできる。例えば、コンテンツソース５０２からのマルチメディアプレゼンテーションが英語ストリームとスペイン語ストリームを含む場合、サーバ５０４は、スペイン語ストリームをチャネル５４２１〜５４２Ｎのすべて、またはチャネル５４２１にのみマッピングするか、またはどのチャネルにも全くマッピングしないように構成することができる。
【００９７】
いくつかの実施形態では、チャネルの「レイアウト」があらかじめ選択される。例えば、それぞれのチャネルが独自のＩＰアドレスを持つ実施形態では、チャネルはマルチキャスト用に割り当てられたＩＰアドレスの範囲内の順次ＩＰアドレスの集合とすることができる（つまり、ＩＰアドレス２２４．０．０．０からＩＰアドレス２３９．２５５．２５５．２５５への範囲）。したがって、アナウンスメントチャネル５３２はＩＰアドレス２３１．０．０．１に割り当てられ、アクセラレーションチャネル５３４はＩＰアドレス２３１．０．０．２に割り当てられ、高品質ビデオチャネル５３６はＩＰアドレス２３１．０．０．３に割り当てることができる。同様に、複数のチャネルをグループＩＰアドレスの順次ポートの集合とすることができる。そのため、ＲＴＰベースの実施形態では、アナウンスメントチャネル５３２はポート２３１．０．０．１：５０００に割り当てられ、アクセラレーションチャネル５３４はポート２３１．０．０．１：５００２に割り当てられ、高品質ビデオチャネル５３６はポート２３１．０．０．１：５００４に割り当てられ、といったように続く（したがって、ポート５００１、５００３、および５００５はＲＴＣＰパケットに使用できる）。
【００９８】
システム５００５００の上記の実施形態で使用されるアプローチには複数の利点がある。例えば、アナウンスメントストリームは専用チャネルでマルチキャストされるため、クライアントはより素早く、プレゼンテーション技術情報を取得することができ、それによって、起動待ち時間を短縮できるため都合がよい。対照的に、従来のＳＡＰマルチキャストアプローチは、通常、ＳＡＰマルチキャストは一般的に大量のマルチキャストをアナウンスし、特定のマルチメディアプレゼンテーションのアナウンスメントがマルチキャストされる頻度を減らす傾向がある（したがって、起動待ち時間を引き延ばす傾向がある）ため起動待ち時間が長くなる。
【００９９】
さらに、システム５００のこれらの実施形態は、クライアントがサーバ５０４への裏チャネルを持つことを要求せず、それによって、マルチメディアプレゼンテーションを目的の視聴者に自在に配送することができる。
【０１００】
さらに、システム５００のこれらの実施形態では、サーバ側ですでに説明されている従来システムで必要な「マルチキャスト情報」ファイルを供給する必要がなくなり、したがって、このファイルを保持し、パブリッシュするコストがなくなる。
【０１０１】
さらに、チャネルの集合でマルチキャストされるストリームは、いくつかの実施形態では「予測可能」であるため、クライアントは、アナウンスメントチャネル５３２からマルチメディアプレゼンテーション記述情報を受信して処理するのを待たずに特定のチャネルに参加することを選択できる。例えば、アグレッシブなクライアント（通常は、比較的大きな資源を持つクライアント）は、アナウンスメントチャネル５３２に参加するのと同時にまたは参加する代わりに高品質ビデオおよび高品質オーディオチャネル５３６および５３８に参加することを選択することができ、それによってクライアントが、データを失うことなくストリームを処理するための十分な資源を実際に有する場合に起動待ち時間を短縮することができる。例えば、大きな資源を持つクライアントは、高速なＣＰＵおよび大きなバッファリング資源があるコンピューティングプラットフォームを持つクライアントとすることができ、比較的大容量の利用可能な帯域幅を持つ高速コンピュータネットワークに接続される。高速なＣＰＵおよび大きなバッファリング資源があると、データを失うリスクは大幅に低減される。
【０１０２】
図１２は、一実施形態による、サーバ５０４（図９）によりマルチキャストされるマルチメディアプレゼンテーションを受信する際のクライアント５０６１（図９）の動作の流れを例示している。クライアント５０６２〜５０６Ｘ（図９）は、実質的に同一の方法で動作することが可能である。図９、１１、および１２を参照すると、クライアント５０６１は以下のようにマルチメディアプレゼンテーションを受信する際の動作をする。
【０１０３】
ブロック５６２では、クライアント５０６１は、マルチメディアプレゼンテーションのアナウンスメントチャネルの論理アドレスをすでに受信しており、アナウンスメントチャネル５３２に参加する。一実施形態についてすでに説明されているように、サーバ５０４は、専用アナウンスメントチャネル上でプレゼンテーション記述情報を繰り返しマルチキャストする。したがって、クライアント５０６１は、一般的に比較的多数のマルチメディアおよび／またはその他のタイプのプレゼンテーションの記述情報をマルチキャストする従来のシステムと比べてプレゼンテーション記述情報を比較的高速に受信することができる。
【０１０４】
ブロック５６４で、クライアント５０６１は、その後、受信されたアナウンスメントストリーム内に記述されている、マルチメディアデータストリームを供給するチャネルの１つまたは複数に参加する。一実施形態では、クライアント５０６１は、クライアント５０６１に利用可能な資源を使用して最適なエクスペリエンスが得られるように参加する（複数の）チャネルを決定することができる。クライアント５０６１は、その後、マルチメディアプレゼンテーションの選択された（複数の）ストリームを受信することができる。
【０１０５】
図１２Ａは、他の実施形態による、サーバ５０４（図９）によりマルチキャストされるマルチメディアプレゼンテーションを受信する際のクライアント５０６１（図９）の動作の流れを例示している。クライアント５０６２〜５０６Ｘ（図９）は、実質的に同一の方法で動作することが可能である。図９、１１、および１２Ａを参照すると、クライアント５０６１は以下のようにマルチメディアプレゼンテーションを受信する際の動作をする。この実施形態では、クライアント５０６１は、ブロック５６２（上述のようにアナウンスメントチャネル５３２に参加するため）とブロック５７０を実質的に同時に実行する。
【０１０６】
ブロック５７０で、クライアント５０６１は、さらに、アナウンスメントチャネル５３２に加えて、マルチメディアプレゼンテーションの１つまたは複数の事前選択されたチャネルにも参加する。一実施形態についてすでに説明したように、サーバ５０４は、所定の方法で事前に選択されたチャネルにおいてストリームをマルチキャストするように構成することができる。この実施形態では、クライアント５０６１は、事前に選択されたチャネル割り当てを利用して、アナウンスメントチャネル５３２からプレゼンテーション記述情報を受信しなくても、目的のチャネルに参加することができる。例えば、一シナリオでは、クライアント５０６１は、マルチメディアプレゼンテーションを受信し処理するための比較的大きな資源を持ち、標準的な高品質ビデオおよび高品質オーディオストリームを処理することができる。これらの資源があるため、クライアント５０６１は、チャネル５３６および５３８に即座に参加し、高品質ビデオおよび高品質のオーディオストリームを受信するように構成できるため、クライアント５０６１が適切にストリームを処理できるという比較的高い期待とともに起動待ち時間を短縮することができる。
【０１０７】
決定ブロック５７２では、クライアント５０６１は、クライアント５０６１に利用可能な資源に照らして、ブロック５７０で参加した（複数の）チャネルから受信された（複数の）ストリームをそれが最適な形で処理できるかどうかを判定する。一実施形態では、クライアント５０６１は、アナウンスメントチャネル５３２から受信したプレゼンテーション記述情報を使用して、その資源がそれらのチャネル上で受信されたストリームを処理できるかどうかを判定する。例えば、ブロック５７０で参加されたチャネルのストリームの持つビットレート（アナウンスメントストリーム内に記述される）は、クライアント５０６１には大きすぎて、データを失わずに処理することはできない（その結果、オーディオストリームのオーディオ再生が切れ切れになったり、またはビデオストリームのビデオ再生にむらが生じたりする可能性がある）。クライアント５０６１は、ブロック５７２で、事前に選択された（複数の）チャネルの（複数の）ストリームを最適な形で処理し、クライアント５０６１は、マルチキャストされたマルチメディアプレゼンテーションが終了するまでブロック５７０内でクライアントが参加した（複数の）チャネルから（複数の）ストリームを受信し続ける。
【０１０８】
しかし、この実施形態では、ブロック５７２のクライアント５０６１が事前に選択された（複数の）チャネルの（複数の）ストリームを最適な形で処理できないと判断した場合、動作の流れはブロック５６４（図１２に関してすでに説明されている）に進む。ブロック５６４で、ブロック５６２で受信されたプレゼンテーション記述情報を使用することにより、クライアント５０６１は、クライアント５０６１が最適な形で処理できるマルチメディアデータストリームを搬送する１つまたは複数の他のチャネルに参加する。ブロック５７４において、この実施形態では、クライアント５０６１は、ブロック５７０で参加された事前に選択されたチャネルを終了することができる。クライアント５０６１は、マルチキャストされたマルチメディアプレゼンテーションが終了するか、またはチャネルを抜けることを選択するまで、ブロック５６４で参加されているチャネルから（複数の）ストリームを受信し続ける。
【０１０９】
図１３は、一実施形態によれば、サーバ５０４（図９）のコンポーネントのいくつかを例示している。この実施形態では、アナウンスメントジェネレータ５１０（図９に関して上で説明されている）に加えて、サーバ５０４は、コンフィギュレーションコントローラ５８２、構成可能なストリームマッパ５８４、ソースインターフェース５８６、およびネットワークインターフェース５８８を含む。いくつかの実施形態では、これらの要素は、サーバ５０４のコンピューティング環境により実行することができるソフトウェアモジュールまたはコンポーネントである。
【０１１０】
ソースインターフェース５８６は、リンク５１２を介してコンテンツソース５０２（図９）から１つまたは複数のマルチメディアストリームを受信するように構成されている。構成可能なストリームマッパ５８２は、ソースインターフェース５８６からストリームを、アナウンスメントジェネレータ５１０からアナウンスメントストリーム、コンフィギュレーションコントローラ５８２から制御情報を受信するように構成されている。この実施形態では、構成可能なストリームマッパ５８４は、ソースインターフェース５８６から受信されたストリームの１つまたは複数を（複数の）マルチキャストチャネルにマッピングするか、または方向付ける際のスイッチのように機能する。ネットワークインターフェース５８８は、選択されたストリームをネットワーク５０８上でマルチキャストする（図９）。いくつかの実施形態では、コンフィギュレーションコントローラ５８２は、マルチメディアプレゼンテーションの受信された（複数の）ストリームを（複数の）チャネルにマッピングするように、構成可能なストリームマッパ５８４を構成する。さらに、いくつかの実施形態では、コンフィギュレーションコントローラ５８２は、アナウンスメントの生成の際にアナウンスメントジェネレータ５１０を方向付ける。コンフィギュレーションコントローラ５８２の一実施形態の動作の流れは、図１３およびに関して以下で説明されている。
【０１１１】
図１４は、一実施形態による、マルチメディアプレゼンテーションをマルチキャストする際のコンフィギュレーションコントローラ５８２（図１３）の動作の流れを例示している。図１３および１４を参照すると、コンフィギュレーションコントローラ５８２の一実施形態は、後述のようにマルチメディアプレゼンテーションをマルチキャストする動作をする。
【０１１２】
ブロック６０２で、コンフィギュレーションコントローラ５８２のこの実施形態は、管理者から構成情報を受け取る。管理者は、手動で、サーバ５０４のコンフィギュレーションコントローラ５８２に構成情報を供給することができる。この構成情報で、論理アドレスに関してチャネルのそれぞれを定義し、プレゼンテーション記述情報（すでに説明されている）を含むことができる。例えば、プレゼンテーション情報は、マルチキャストされるマルチメディアプレゼンテーションの（複数の）ストリームの（複数の）メディアタイプ、（複数の）ストリームの（複数の）ビットレート、（複数の）言語、誤り訂正情報、セキュリティ／認証情報、暗号化情報、デジタル権利管理（ＤＲＭ）情報などを含むことができる。
【０１１３】
他の実施形態では、コンフィギュレーションコントローラ５８６は、ソースインターフェース５８６を介してコンテンツソース５０２（図９）から受信された後、ストリーム自体から（例えば、複数のストリームに含まれるヘッダまたはメタデータ情報から）プレゼンテーション記述情報を抽出するように構成することができる。
【０１１４】
ブロック６０４で、コンフィギュレーションコントローラ５８２は、アナウンスメントジェネレータ５１０からアナウンスメントストリームを、ソースインターフェース５８６から（複数の）マルチメディアデータストリームをプレゼンテーション記述情報に記述されているチャネルにマッピングするようにストリームマッパ５８４を構成する。このアナウンスメントストリームは、マルチメディアプレゼンテーションのマルチキャスト時にサーバ５０４によりアナウンスメントチャネル上で繰り返しマルチキャストされる。
【０１１５】
ブロック６０６で、コンフィギュレーションコントローラ５８２は、（複数の）ストリームのプレゼンテーション記述情報をアナウンスメントジェネレータ５１０に供給する。すでに説明されているように、アナウンスメントジェネレータ５１０は、プレゼンテーション記述情報を含むアナウンスメントストリームを形成する。
【０１１６】
すでに説明されているように、チャネルの「レイアウト」は事前選択されるようにできる。例えば、クライアントは、マルチキャストされたマルチメディアプレゼンテーションに参加するため論理アドレス（例えば、ＵＲＬ）を与えられる。一実施形態では、その第１の論理アドレスは、一実施形態のアナウンスメントストリームを搬送するように事前に選択される。この実施例では、次の順次論理アドレスはアクセラレーションチャネルを搬送するように事前に選択されるが、次の順次論理アドレスは高品質ビデオストリームを搬送するように事前に選択され、図１１の実施形態に示されているように続く。コンフィギュレーションコントローラ５８２は、事前に選択されたチャネルレイアウトに従ってアナウンスメントストリームおよびマルチメディアデータストリームをマッピングするようにストリームマッパ５８４を構成する。
【０１１７】
図１５は、他の実施形態によれば、サーバ５０４（図９）のコンポーネントのいくつかを例示している。サーバ５０４のこの他の実施形態は、この実施形態が高速化されたストリームジェネレータ７０２を含むことを除き、図１３の実施形態に実質的に類似している。一実施形態では、高速化されたストリームジェネレータ７０２は、マルチキャストされたマルチメディアデータの各ユニットがマルチメディアデータの現在の部分ユニットおよびデータの事前に選択された数の前の部分ユニットを含むストリームを形成するように構成される。例えば、高速化されたストリームは、データグラムがマルチメディアプレゼンテーションの（複数の）現在のフレームおよび前の５秒分のフレームを含むようにマルチキャストすることができる。この実施形態では、高速化されたストリームジェネレータ７０２は、アクセラレーションチャネル５３４などの専用アクセラレーションチャネルにマッピングされる構成可能なストリームマッパ５８４に高速化されたストリームを供給する（図１１）。しかし、他の実施形態では、アクセラレーションチャネルデータグラムは、（複数の）現在のフレームを含む必要はない。
【０１１８】
図１６は、一実施形態による、高速化されたストリームジェネレータ７０２（図１５）を備えるサーバ５０４の動作の流れを例示している。図１５および１６を参照すると、サーバ５０４のこの実施形態は後述のように動作する。
【０１１９】
ブロック８０２で、高速化されたストリームジェネレータ７０２は、ネットワーク５０８上でのマルチキャストのため１ユニット分のマルチメディアデータを形成する（図９）。この実施形態では、高速化されたストリームジェネレータ７０２は、マルチメディアプレゼンテーションデータの現在の部分ユニットおよびマルチメディアプレゼンテーションデータの前のＺ個の部分ユニットを使用してユニットを形成する。すでに述べたように、このユニットは、１つのデータグラムまたはパケットでよく、部分ユニットは、マルチメディアデータのフレームとすることができる。一実施形態では、Ｚは、ユニット（つまり、パケットまたはデータグラム）がマルチメディアデータをレンダリングまたは復号化するために必要なキーフレームを必ず含むように選択される。他の実施形態では、Ｚは、キーフレームを持つユニットが保証されるかどうかに関係なく選択される。
【０１２０】
ブロック８０４では、ブロック８０２で形成されたマルチメディアデータのユニットは、ネットワーク５０８上でマルチキャストされる（図９）。この実施形態では、高速化されたストリームジェネレータ７０２は、マルチメディアデータのユニットを構成可能なストリームマッパ５８４に供給し、その後、そのブロックをアクセラレーションチャネルにマッピングする。続いて、サーバ５０４は、ネットワークインターフェース５８８を介してマルチメディアデータのユニットをネットワーク５０８（図９）上でマルチキャストする。一実施形態では、サーバ５０４は、「リアルタイムよりも速い」速度（つまり、基本のマルチメディアデータのビットレートよりも高速なビットレート）でユニットをマルチキャストする。このアプローチでは、比較的大きな資源を持つクライアントをアクセラレーションチャネルに参加させ、レンダリングまたは再生がより速く開始できるようにユニットを受信するとそのマルチメディアプレーヤーのバッファに素早く書き込むようにできて都合がよい。この機能は、マルチメディアデータのマルチキャストされたユニットがキーフレームを含む実施形態において強化される。それとは別に、サーバ５０４がユニットをマルチキャストする速度は、「リアルタイムよりも速い」必要はない。このアプローチは、クライアントがアクセラレーションチャネルとマルチメディアデータをマルチキャストする他のチャネルの両方に同時に参加するアプリケーションで使用することができ、実際に、クライアントは「リアルタイムよりも速い」速度でマルチメディアデータを受信する。
【０１２１】
さらに多くのマルチメディアデータがマルチキャストされる場合、決定ブロック８０６で表されるように、動作の流れはブロック８０２に戻る。したがって、例えば、データグラムで転送されるマルチメディアフレームの上述の例を使用すると、次のデータグラムは、マルチメディアデータの次のフレームと、前のデータグラム内の追加されたフレームと、前の（Ｚ−１）個のフレームを含むであろう。したがって、この実施形態では、それぞれのユニット（例えば、データグラム）は、現在の部分ユニット（例えば、フレーム）と前のＺ個のフレームのスライディングウィンドウを表し、Ｚは、各ユニットが十分な情報を持ち、クライアントのマルチメディアプレーヤーにマルチメディアプレゼンテーションのレンダリング／再生を開始させるのに必要な時間を短縮できる十分に大きい値となるように選択される。すでに述べたように、いくつかの実施形態では、Ｚは、各ユニットがキーフレームを必ず持つように選択することができる。
【０１２２】
一実施形態では、ビデオおよびオーディオデータのユニットは、マルチメディアプレゼンテーションがオーディオストリームとビデオストリームの両方を含む場合に同じチャネル上で交互になるようにマルチキャストされる。他の実施形態では、別のアクセラレーションチャネルをオーディオおよびビデオストリームに使用することができる。
【０１２３】
マルチメディアプレゼンテーションの開始時に、高速化されたストリームジェネレータの一実施形態は、マルチメディアデータの少なくともＺ個の部分ユニットが（複数の）非高速化チャネルでマルチキャストされるまで待ち、それからブロック８０２で１ユニット分のデータを形成する。
【０１２４】
図１７は、一実施形態によれば、高速化されたストリームを受信する際のクライアントの動作の流れを例示している。ブロック９０２で、クライアント（例えば、図９のクライアント５０６１〜５０６Ｘの１つ）は、アクセラレーションチャネルに参加す。いくつかのシナリオにおいて、アクセラレーションチャネルは、事前に選択されたチャネルレイアウトの一部であり、クライアントはそれに参加する際に、アナウンスメントチャネルに参加するのと同時であっても、またアナウンスメントチャネルに参加しなくてもよい。すでに説明されているように、アクセラレーションチャネルは、クライアントが起動待ち時間を短縮できるようにマルチメディアプレゼンテーションを受信して処理するための比較的大きな資源を持つクライアントにより使用することができ、都合がよい。
【０１２５】
ブロック９０４で、クライアントは、アクセラレーションチャネルからマルチメディアデータの１つまたは複数のユニットを受信する。一実施形態では、マルチメディアデータのそれぞれのユニットは、図１６とともに上で説明されているように生成される。その後、クライアントは、マルチメディアデータのそれぞれのユニットを処理して、比較的素早く、レンダリングまたは再生プロセスを開始することができる。一シナリオでは、クライアントは、１ユニットのビデオデータと１ユニットのオーディオデータを受信し、ビデオデータはできる限りすぐにクライアントがレンダリング／再生プロセスを開始できるようにキーフレームを１つ含む。すでに説明されているように、ユニットは、他の実施形態ではキーフレームを持たなくてよい。
【０１２６】
ブロック９０６で、クライアントは、続いて、高品質ビデオチャネル５３６および高品質オーディオチャネル５３８などの非高速化チャネルに参加できる。一実施形態では、クライアントが参加する非高速化チャネルは、上述の事前に選択されたチャネルレイアウトを使用して事前に選択される。他の実施形態では、クライアントは、アナウンスメントストリームに含まれるプレゼンテーション記述情報に基づいて（複数の）チャネルに参加する。ブロック９０８で、クライアントは、アクセラレーションチャネルを終了する。一実施形態では、クライアントは、１つまたは複数のレンダリング／再生プロセスを開始するのに必要なマルチメディアデータの１つまたは複数のユニットを受信した直後にアクセラレーションチャネルを終了する。
【０１２７】
ブロック９０２から９０８までは、順次実行されるとおりに説明されているが、図１７のフローチャートでは（本明細書で説明されている他のフローチャートと同様）、それらのブロックの実行は、示されているのと異なる順序であるか、またはいくつかのブロックが複数回実行されるか、またはいくつかのブロックが同時に実行されるか、またはそれらの組み合わせである。例えば、いくつかの実施形態では、ブロック９０２および９０６は、並列に実行され、したがって、動作の流れは、クライアントが高速化チャネルと非高速化チャネルに同時に参加する形をとる。ブロック９０４は、ブロック９０２の後に順次実行され、ブロック９０４および９０６は、ブロック９０８に進む。
【０１２８】
図１７Ａは、クライアントがアクセラレーションチャネルおよびいくつかの事前に選択されたチャネルに参加し、その後、他のチャネルに参加することができるシナリオ例を示している（例えば、アナウンスメントチャネルから受信されたアナウンスメント情報に基づいて）。この例では、クライアントは、１つまたは複数の事前に選択された非高速化チャネル（つまり、ブロック９０６）に参加するのと同時にアクセラレーションチャネル（つまり、ブロック９０２）に参加する。その後、クライアントは、アクセラレーションチャネル（つまり、ブロック９０４）からマルチメディアデータの１つまたは複数のユニットを受信するとともに、（複数の）非高速化チャネルからマルチメディアおよびアナウンスメントデータを受信する。アナウンスメントチャネルに参加した結果、クライアントは、（複数の）事前に選択されたチャネルを終了し、他の非高速化チャネル（つまり、ブロック５７２、５６４、および５７４）に参加することを決定することができる。
【０１２９】
上述のさまざまなマルチキャスト機能の実施形態は、サーバおよびクライアントのコンピュータ環境に実装することができる。サーバおよびクライアントで使用するのに適しているコンピュータ環境例は、図１８とともに以下で説明される。
【０１３０】
図１８は、本明細書で説明されている手法を実装するために使用することができる、一般的なコンピュータ環境１０００を例示している。コンピュータ環境１０００は、コンピューティング環境の一例にすぎず、コンピュータおよびネットワークアーキテクチャの用途または機能性の範囲に関する制限を示唆する意図はない。コンピュータ環境１０００は、コンピュータ環境例１０００に例示されている１つのコンポーネントまたはその組み合わせに関係する何らかの依存関係または要求条件がその環境にあるものと解釈すべきでない。
【０１３１】
コンピュータ環境１０００は、コンピュータ１００２の形態の汎用コンピューティング装置を備える。コンピュータ１００２のコンポーネントは、限定はしないが、１つまたは複数のプロセッサまたは処理ユニット１００４、システムメモリ１００６、およびプロセッサ１００４を含むさまざまなシステムコンポーネントをシステムメモリ１００６に結合するシステムバス１００８を含むことができる。
【０１３２】
システムバス１００８は、メモリバスまたはメモリコントローラ、周辺機器バス、アクセラレイティッドグラフィックスポート、およびさまざまなバスアーキテクチャのどれかを使用するプロセッサまたはローカルバスを含む数種類のバス構造のうちの１つまたは複数を表している。例えば、このようなアーキテクチャとしては、Ｉｎｄｕｓｔｒｉａｌ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ  ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、Ｍｅｚｚａｎｉｎｅバスとも呼ばれるＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔｓ（ＰＣＩ）バス、ＰＣＩ  Ｅｘｐｒｅｓｓバス、ユニバーサルシリアルバス（ＵＳＢ）、Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ（ＳＤ）バス、またはＩＥＥＥ  １３９４、つまりＦｉｒｅＷｉｒｅバスがある。
【０１３３】
コンピュータ１００２は、さまざまなコンピュータ可読媒体を備えることができる。そのような媒体は、コンピュータ１００２によってアクセス可能な媒体であればどのような媒体でも使用可能であり、揮発性および不揮発性媒体、取り外し可能および取り外し不可能媒体を含む。
【０１３４】
システムメモリ１００６は、ランダムアクセスメモリ（ＲＡＭ）１０１０などの揮発性メモリ、および／または読み取り専用メモリ（ＲＯＭ）１０１２またはフラッシュＲＡＭなどの不揮発性メモリの形態のコンピュータ可読媒体を含む。起動時などにコンピュータ１００２内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１０１４は、ＲＯＭ  １０１２またはフラッシュＲＡＭに格納される。通常、ＲＡＭ  １０１０は、処理ユニット１００４に直接アクセス可能な、および／または処理ユニット１２０によって現在操作されているデータおよび／またはプログラムモジュールを格納する。
【０１３５】
コンピュータ１００２は、さらに、他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体も備えることができる。例えば、図１０は、取り外し不可能な不揮発性磁気媒体（図に示されていない）の読み出しおよび書き込みを行うハードディスクドライブ１０１６、取り外し可能な不揮発性磁気ディスク１０２０（例えば、「フロッピー（登録商標）ディスク」）の読み出しおよび書き込みを行う磁気ディスクドライブ１０１８、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、またはその他の光媒体などの取り外し可能な不揮発性光ディスク１０２４の読み出しおよび／または書き込みを行う光ディスクドライブ１０２２を例示している。ハードディスクドライブ１０１６、磁気ディスクドライブ１０１８、および光ディスクドライブ１０２２は、それぞれ、１つまたは複数のデータメディアインターフェース１０２５によりシステムバス１００８に接続される。代替として、ハードディスクドライブ１０１６、磁気ディスクドライブ１０１８、および光ディスクドライブ１０２２は、１つまたは複数のインターフェース（図に示されていない）によりシステムバス１００８に接続することができる。
【０１３６】
ディスクドライブおよびその関連するコンピュータ可読媒体は、コンピュータ１００２用のコンピュータ可読命令、データ構造体、プログラムモジュール、およびその他のデータを格納する不揮発性記憶装置を実現する。実施例は、ハードディスク１０１６、取り外し可能磁気ディスク１０２０、および取り外し可能光ディスク１０２４を例示しているが、磁気カセットまたはその他の磁気記憶装置、フラッシュメモリカード、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）または他の光記憶装置、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、電気的消去可能プログラム可能読み取り専用メモリ（ＥＥＰＲＯＭ）などの、コンピュータによりアクセス可能なデータを格納することができる他のタイプのコンピュータ可読媒体も、このコンピューティングシステムおよび環境例を実装するために使用することができる。
【０１３７】
例えば、オペレーティングシステム１０２６、１つまたは複数のアプリケーションプログラム１０２８、その他のプログラムモジュール１０３０、およびプログラムデータ１０３２を含む、多くのプログラムモジュールは、ハードディスク１０１６、磁気ディスク１０２０、光ディスク１０２４、ＲＯＭ  １０１２、および／またはＲＡＭ  １０１０に格納されることができる。そのようなオペレーティングシステム１０２６、１つまたは複数のアプリケーションプログラム１０２８、他のプログラムモジュール１０３０、およびプログラムデータ１０３２（またはそれらの何らかの組み合わせ）はそれぞれ、分散ファイルシステムをサポートする常駐コンポーネントの全部または一部を実装することができる。
【０１３８】
ユーザはキーボード１０３４およびポインティング装置１０３６（例えば、「マウス」）などの入力装置を介してコンピュータ１００２にコマンドおよび情報を入力することができる。他の入力装置１０３８（図に特には示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、シリアルポート、スキャナなどがある。これらの入力装置およびその他の入力装置は、システムバス１００８に結合されている入力／出力インターフェース１０４０を介して処理ユニット１００４に接続され、またパラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造により接続されることも可能である。
【０１３９】
モニタ１０４２またはその他の種類の表示装置も、ビデオアダプタ１０４４などのインターフェースを介してシステムバス１００８に接続されることができる。モニタ１０４２に加えて、他の出力周辺装置は、スピーカ（図に示されていない）およびプリンタ１０４６などのコンポーネントを含み、Ｉ／Ｏインターフェース１０４０を介してコンピュータ１００２に接続されることができる。
【０１４０】
コンピュータ１００２は、（複数の）リモートコンピューティング装置１０４８などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク接続環境で動作させることができる。例えば、リモートコンピューティング装置１０４８は、ＰＣ、携帯型コンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイス、または他の共通ネットワークノードなどとすることができる。リモートコンピューティング装置１０４８は、コンピュータ１００２に関して本明細書で説明されている要素および特徴の多くまたは全部を含むことができる携帯型コンピュータとして例示されている。代替として、コンピュータ１００２は、非ネットワーク接続環境でも動作可能である。
【０１４１】
コンピュータ１００２とリモートコンピュータ１０４８との間の論理接続は、ローカルエリアネットワーク（ＬＡＮ）１０５０と一般的なワイドエリアネットワーク（ＷＡＮ）１０５２として表されている。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、およびインターネットでは一般的である。
【０１４２】
ＬＡＮネットワーキング環境で実装される場合、コンピュータ１００２は、ネットワークインターフェースまたはアダプタ１０５４を介してローカルネットワーク１０５０に接続される。ＷＡＮネットワーキング環境で実装される場合、コンピュータ１００２は、通常、広域ネットワーク１０５２上での通信を確立するためのモデム１０５６または他の手段を含む。
【０１４３】
モデム１０５６は、コンピュータ１００２に内蔵しても、外付けでもよいが、Ｉ／Ｏインターフェース１０４０または他の適切なメカニズムを介してシステムバス１００８に接続することができる。例示されているネットワーク接続は実施例であり、コンピュータ１００２と１０４８との間の少なくとも１つの通信リンクを確立する他の手段を採用できることは理解されるであろう。
【０１４４】
コンピューティング環境１０００とともに例示されているようなネットワーク接続環境では、コンピュータ１００２またはその一部に関して示されているプログラムモジュールは、リモートメモリ記憶装置に格納されうる。例えば、リモートアプリケーションプログラム１０５８は、リモートコンピュータ１０４８のメモリ装置に常駐する。説明のため、アプリケーションまたはプログラムおよびオペレーティングシステムなどの他の実行可能なプログラムコンポーネントは、本明細書では、離散ブロックとして例示されているが、そのようなプログラムおよびコンポーネントは、異なる時点において、コンピューティング装置１００２の異なる記憶コンポーネント内にあり、コンピュータの少なくとも１つのデータプロセッサにより実行されることは理解される。
【０１４５】
さまざまなモジュールおよび手法は、１つまたは複数のコンピュータまたはその他の装置により実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的背景状況において、本明細書で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。これらのプログラムモジュールなどは、ネイティブコードとして実行するか、または仮想マシンまたはその他のジャストインタイムコンパイル実行環境などで、ダウンロードし実行することができる。通常、プログラムモジュールの機能は、さまざまな実施形態で望まれているように組み合わせるか、または分散させることができる。
【０１４６】
これらのモジュールおよび手法の実装は、コンピュータ可読媒体に格納するか、または何らかの形のコンピュータ可読媒体で伝送することができる。コンピュータ可読媒体は、コンピュータによりアクセスできる入手可能な媒体であればどのようなものでもよい。例えば、コンピュータ可読媒体は、「コンピュータ記憶媒体」および「通信媒体」を含むことができる。
【０１４７】
「コンピュータ記憶媒体」は、コンピュータ可読命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含む。コンピュータ記憶媒体としては、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、または所望の情報を格納するために使用することができ、しかもコンピュータによりアクセスできるその他の媒体がある。
【０１４８】
「通信媒体」は、通常、コンピュータ可読命令、データ構造体、プログラムモジュール、または搬送波またはその他のトランスポートメカニズムなどの変調データ信号によるその他のデータを具現化するものである。通信媒体は、さらに、情報配送媒体も含む。「変調データ信号」という用語は、信号内の情報を符号化する方法によりその特性のうち１つまたは複数が設定または変更された信号を意味する。非限定的例にすぎないが、通信媒体は、有線ネットワークまたは直接配線接続などの有線媒体、ならびに音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体を含む。上記のいずれの組み合わせもコンピュータ可読媒体の範囲に含まれる。
【０１４９】
本明細書全体を通して、「一実施形態」、または「一実施例」と記述されている場合、これは、特定の説明されている機能、構造、または特性が本発明の少なくとも一実施形態に含まれることを意味する。したがって、このようなフレーズを使用した場合、１つの実施形態というよりも複数の実施形態を指している。さらに、説明されている機能、構造、または特性は、１つまたは複数の実施形態において、適当な方法により組み合わせることができる。
【０１５０】
ただし、当業者であれば、本発明は、特定の詳細の１つまたは複数なしで、または他の方法、資源、材料などを使用して、実践できることは理解できるであろう。他の場合には、単に本発明の態様をわかりにくくすることを避けるため、よく知られている構造、資源、または操作については、示されていないか、または詳述されていない。
【０１５１】
複数の実施例およびアプリケーション例が例示され、説明されているが、本発明は、上述の正確な構成および資源に限定されないことが理解されるであろう。請求されている発明の範囲から逸脱することなく、本明細書に開示されている本発明の方法およびシステムの配置、操作、および詳細に対し、さまざまな修正、変更、および変形を加えられることは、当業者には明白なことであろう。
【０１５２】
上記の説明では構造的特徴および／または方法論的活動に特有の言語を使用しているが、付属の請求項で定められている発明は、説明されている具体的な特徴または活動に必ずしも限られないことは理解されるであろう。むしろ、具体的な特徴および活動は発明を実装するための複数の実施形態例として開示されている。
【図面の簡単な説明】
【０１５３】
【図１】本明細書で説明されているようなＲＴＣＰのメッセージに埋め込まれたセッション記述のメッセージを使用してメディアストリーミングを実行するために使用することができるネットワーク環境例を例示する図である。
【図２】本明細書で説明されているようなＲＴＣＰのメッセージに埋め込まれたセッション記述のメッセージを使用してメディアコンテンツをストリーミングすることができるクライアントおよびサーバ装置例を例示する図である。
【図３】本明細書で説明されているようなＲＴＣＰのメッセージに埋め込まれたセッション記述のメッセージを使用してメディアコンテンツをストリーミングすることができるマルチキャスト環境におけるクライアントおよびサーバ装置例を例示する図である。
【図４】本明細書で説明されているようなＲＴＣＰのメッセージに埋め込まれたセッション記述のメッセージを使用してメディアコンテンツをストリーミングすることができるサーバサイド再生リスト環境におけるクライアントおよびサーバ装置例を例示する図である。
【図５】埋め込まれたセッション記述のメッセージを持つＲＴＣＰのメッセージのフォーマット例を例示する図である。
【図６】セッション記述のメッセージフォーマット例を例示する図である。
【図７】再生リストを使用した場合にＲＴＣＰのメッセージにセッション記述のメッセージを埋め込むためのプロセス例を例示するフローチャートである。
【図８】再生リストを使用した場合にＲＴＣＰのメッセージにセッション記述のメッセージを受け取るためのプロセス例を例示するフローチャートである。
【図９】一実施形態による、マルチメディアプレゼンテーションをマルチキャストするためのシステムを例示するブロック図である。
【図１０】一実施形態による、図９のシステム内のサーバの動作の流れを例示するフローチャートである。
【図１１】一実施形態による、チャネル例を例示する図である。
【図１２】一実施形態による、図９のシステム内のクライアントの動作の流れを例示するフローチャートである。
【図１２Ａ】他の実施形態による、図９のシステム内のクライアントの動作の流れを例示するフローチャートである。
【図１３】一実施形態による、図９のサーバを例示するブロック図である。
【図１４】一実施形態による、図１３のコンフィギュレーションコントローラの動作の流れを例示するフローチャートである。
【図１５】他の実施形態による、図９のサーバを例示するブロック図である。
【図１６】一実施形態による、図１５の高速化されたストリームジェネレータを備えるサーバの動作の流れを例示するフローチャートである。
【図１７】一実施形態による、高速化されたストリームを受信する際のクライアントの動作の流れを例示するフローチャートである。
【図１７Ａ】他の実施形態による、高速化されたストリームを受信する際のクライアントの動作の流れを例示するフローチャートである。
【図１８】上記実施形態を実施するのに好適なコンピューティング環境例を例示するブロック図である。
【図１】
2007509573.tif 000006
【図２】
2007509573.tif 000007
【図３】
2007509573.tif 000008
【図４】
2007509573.tif 000009
【図５】
2007509573.tif 000010
【図６】
2007509573.tif 000011
【図７】
2007509573.tif 000012
【図８】
2007509573.tif 000013
【図９】
2007509573.tif 000014
【図１０】
2007509573.tif 000015
【図１１】
2007509573.tif 000016
【図１２】
2007509573.tif 000017
【図１２Ａ】
2007509573.tif 000018
【図１３】
2007509573.tif 000019
【図１４】
2007509573.tif 000020
【図１５】
2007509573.tif 000021
【図１６】
2007509573.tif 000022
【図１７】
2007509573.tif 000023
【図１７Ａ】
2007509573.tif 000024
【図１８】
2007509573.tif 000025
【国際調査報告】
2007509573.tif 000026