(57)【要約】  クライアントデバイス（１０４）はホストデバイス（１０２）からストリーミングコンテンツを受信する。このストリーミングコンテンツは処理に先立って１または複数のバッファ（１２８）に置かれる。バッファの容量と満杯に関するモニタリングが処理に先立って行なわれる（１３２）。バッファの容量と満杯に関するモニタリングはクライアントデバイス側で行なわれ、情報がホストデバイスに送信される。ホストデバイスは、クライアントデバイスによって提供された情報に基づいてストリーミングコンテンツのレートまたはフローを調整する。
2008543176.tif 000002
【特許請求の範囲】
【請求項１】
１または複数のバッファの容量を判定するステップであって、前記容量はバッファ情報に記述される、ステップと、
前記１又は複数のバッファにおける前記スペースを計算するステップであって、前記使用済みスペースが前記バッファ情報に記述される、ステップと、
前記バッファ情報に基づいてストリーミングコンテンツのフローを調整するホストデバイスに、前記バッファ情報を送信するステップと
を備えることを特徴とする方法。
【請求項２】
前記判定するステップは、前記ストリーミングコンテンツを受信する全てのバッファにおいて実行されることを特徴とする請求項１に記載の方法。
【請求項３】
前記判定するステップは、前記ストリーミングコンテンツを受信しているバッファの集合容量に基づくことを特徴とする請求項１に記載の方法。
【請求項４】
前記バッファ情報を送信するステップは、バッファ満杯報告の形式であることを特徴とする請求項１に記載の方法。
【請求項５】
前記バッファ情報のやり取りをネゴシエートするステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項６】
前記ネゴシエートするステップは、前記バッファ情報を前記ホストデバイスにどのくらいの頻度で送信するかを判定するステップを含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記ネゴシエートするステップは、前記バッファ情報を伝達するために使用される通信プロトコルを特定するステップを含むことを特徴とする請求項５に記載の方法。
【請求項８】
１または複数のコンピュータ可読媒体であって、その実行時に、請求項１に記載の方法を実行するコンピュータ実行可能命令を備えることを特徴とするコンピュータ可読媒体。
【請求項９】
クライアントデバイスとバッファ情報の前記やり取りをネゴシエートするステップと、
前記クライアントデバイスから前記バッファ情報を受信するステップと、
前記クライアントデバイスに対してストリーム送信されるコンテンツのレートを前記バッファ情報に基づいて調整するステップと
を備えることを特徴とする方法。
【請求項１０】
前記ネゴシエートするステップは、前記クライアントから前記バッファ情報をどのくらいの頻度で受信するかを判定するステップを含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記調整するステップは、最適バッファ使用量の値からの偏差に基づくことを特徴とする請求項９に記載の方法。
【請求項１２】
前記レートを調整するステップは、ネットワーク上の伝送レートおよび前記コンテンツの符号化ビットレートを調整することを特徴とする請求項９に記載の方法。
【請求項１３】
前記バッファ情報が受信されない場合に、以後のバッファ情報を待つステップか、または、以前のバッファ情報を使用するステップを含むことを特徴とする請求項９に記載の方法。
【請求項１４】
前記バッファ情報が受信されない場合に、所定のレートまたは以前のバッファ情報から生じるレートに基づいて前記クライアントデバイスに対してコンテンツをストリーミングするステップをさらに備えることを特徴とする請求項９に記載の方法。
【請求項１５】
１または複数のコンピュータ可読媒体であって、その実行時に、請求項９に記載の方法を実行するコンピュータ実行可能命令を備えることを特徴とするコンピュータ実行可能媒体。
【請求項１６】
処理ユニットと、
前記処理ユニットによってアクセス可能であり、かつ処理ユニットによって動作する１または複数のバッファであって、前記バッファは、１又は複数のソースからのストリーム送信されたコンテンツを受信した、バッファと、
前記処理ユニットによってアクセス可能であり、かつ処理ユニットによって動作するバッファモニタであって、前記バッファモニタは、前記バッファの前記満杯レベルをモニタし、前期バッファの前記満杯レベルに基づいて、またはバッファ満杯報告がどのくらいの頻度で受信される予定であるかをネゴシエートした頻度に基づいてバッファ満杯報告を生成する、バッファモニタと
を備えることを特徴とするコンピュータ。
【請求項１７】
前記バッファは、中間ジッタバッファおよびコンテンツバッファを含むことを特徴とする請求項１６に記載のコンピュータ。
【請求項１８】
前記バッファは、カプセル化されたデータコンテンツを格納する第１バッファと、カプセル化が解除された復号化用のデータコンテンツを格納する第２バッファとを含むことを特徴とする請求項１６に記載のコンピュータ。
【請求項１９】
前記バッファ満杯報告は、特定の通信プロトコルを使用してホストデバイスに送信されることを特徴とする請求項１６に記載のコンピュータ。
【請求項２０】
前記コンテンツバッファに先行してデコーダをさらに備えることを特徴とする請求項１６に記載のコンピュータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデジタルコンテンツシステムに関し、より詳細には、ストリーム送信されるデジタルコンテンツのフローをかかるシステムで調整することに関する。
【背景技術】
【０００２】
オーディオ、ビデオおよび/またはテキストメディアコンテンツのストリーミングのような、マルチメディアコンテンツまたはデジタルコンテンツ（コンテンツ）ストリーミングは、ますます普及化している。ここで「ストリーミング(streaming)」という用語は、コンテンツが、ネットワークを介してサーバまたはホストデバイスによってクライアントデバイス（すなわち、デスクトップＰＣ、ノートブックまたはポータブルコンピュータ、セルラ電話や他の無線通信デバイス、パーソナルデジタルアシスタント(ＰＤＡ)、ゲーミングコンソール、ＩＰセットトップボックス、ハンドヘルドＰＣなどの、従来コンピューティングデバイスの任意の種類のいずれかとして実現されたメディア再生デバイス）に提供されることを示すために用いられているのが代表的である。一般的に、クライアントデバイスは、全てのコンテンツまたは「ファイル」全体が配信されるのを待つのではなく、コンテンツがホストから受信されるのと「同時に」ストリーミングコンテンツをレンダリングしている（例えば、再生または表示している）。
【０００３】
コンテンツがネットワークを介して「ストリーム送信される」とき、コンテンツはデータパケットにおいてストリーム送信されるのが代表的である。このようなデータパケットは、リアルタイム転送プロトコル(real time transfer protocol：ＲＴＰ)などのプロトコルで定義されたフォーマットになっていて、ユーザデータグラムプロトコル(user datagram protocol：ＵＤＰ)などの別のフォーマットを介して伝達されることがある。さらに、このようなデータパケットは、ホストデバイスからストリーム送信されるとき圧縮され、符号化されることがある。データパケットは、そのあとクライアントデバイス側で伸張(decompress)され、復号化(decode)されている。
【０００４】
データパケットは、ホストデバイスによって送信される順序でクライアントデバイスによって受信されることがあるが、ケースによっては、データパケットは受信されないこともあれば、別の順序で受信されることもある。さらに、受信されるデータパケットのレートまたはフローに関して若干の不確実性が存在することもある。データパケットは、クライアントデバイスがデータパケットをレンダリングできる以上の高速レートで到着または受信されることもあれば、十分に高速に到着しないこともある（すなわち、データパケットはクライアントデバイスがそのデータパケットをレンダリングするのに十分に高速に到着しないことがある）。特に、ストリーミングが行なわれるとき、データパケットは、必ずしもリアルタイムレートで送信されるとは限らない場合がある。データパケットはリアルタイムレートよりも高速に送信されることもあれば、低速に送信されることもある。
【０００５】
クライアントデバイスは、通常、バッファを使用して受信したデータパケットを処理に先立って格納する。このようなバッファはストレージが制限されており、パケットが受信されるときのレートに応じて、バッファオーバフロー（データパケットが余りに高速に受信されるため）またはバッファアンダフロー（データパケットが十分に高速に受信されないため）が発生することがある。データパケットが余りに高速のレートで到着した場合は、クライアントバッファにオーバフローが起こって、データパケットが処理されないことがある。データパケットが十分に高速にまたはタイムリーに受信されない場合は、不具合(glitch)または中断(break)がユーザ側で起こることになる。例えば、マルチメディアコンテンツがクライアントデバイスにストリーム送信され、十分に高速にクライアントデバイスによって受信されない場合は、ユーザは提示されたマルチメディアコンテンツに不具合または中断を見ることになる。さらに、オーバフローまたはアンダフロー状態が検出されたときは、その問題を訂正するためにクライアントデバイス側とホストデバイス側のクロックを同期化する必要が起こることがある。オーバフロー問題がすでに発生した後では、その問題を訂正するにはすでに遅すぎるのが一般である。しかし、クロックを同期化することで、問題の再発を防止することができる場合がある。あるいは、十分に早期に行なっていれば、問題の再発を防止することができる。オーバフローとアンダフローは、デバイスのクロックドリフト(clock drift)やネットワーク輻輳といった、いくつかの理由で発生することもある。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従って、ホストデバイス側とクライアントデバイス側にクロック回復が組み込まれている場合も、組み込まれていない場合も、ホストデバイスからクライアントデバイスへのデータパケットフローまたはストリームを調整する必要性が起こっている。
【課題を解決するための手段】
【０００７】
クライアントデバイス側のバッファの容量と使用量に関するバッファ情報がホストデバイスに送信される。バッファ情報には、クライアントデバイス側の１または複数のバッファの容量、およびバッファがどれだけ一杯であるか、あるいは利用されているかの情報が含まれる。バッファ情報はホストデバイスに送信され、ホストデバイスではその情報を使用してクライアントデバイスへのストリーミングコンテンツのフローを調整する。
【０００８】
詳細な説明は添付図面を参照して以下に記載されている。図面においては、参照符号の一番左側の数字はその参照符号が最初に現れている図を示している。別の図で同じ参照符号が用いられているときは、それは類似または同一項目を示している。
【発明を実施するための最良の形態】
【０００９】
以下では、ストリーム送信されたコンテンツを、処理に備えて受信するクライアントデバイスバッファのステータスに関してホストデバイスに通知する手法を説明する。
【００１０】
図１は、コンテンツまたはデータパケットフロー情報を、クライアント再生デバイスまたはクライアントデバイス１０４からホストデバイス１０２に提供するのに適した例示環境１００を示す図である。具体的には、バッファ満杯報告(buffer fullness report：ＢＦＲ)はクライアントデバイス１０４によってホストデバイス１０２に提供され、この場合、ＢＦＲにはコンテンツまたはデータパケットを受信し、処理するクライアントデバイスバッファのステータスが含まれている。
【００１１】
ソースまたはホストデバイス１０２は、データファイルやメディアファイルなどのデジタルデータコンテンツおよび／またはライブケーブルＴＶフィード(feed)やウェブキャスト(Webcast)などのライブメディアコンテンツにアクセスできるのが一般的である。ホストデバイス１０２はクライアントデバイス１０４にコンテンツをストリーム送信する。例えば、メディアコンテンツの場合には、クライアントデバイス１０４は、ストリーミングコンテンツをホストデバイス１０２から受信し、それをユーザのためにレンダリング(render)または再生するのが一般的である。コンテンツはネットワーク１０６を介して送信されるかストリーム送信される。さらに、ホストクライアント１０２で利用可能なストリーミングコンテンツに関するクライアントデバイス１０４からの要求は、クライアントデバイス１０４からネットワーク１０６を経由してホストデバイス１０２に送られることがある。ホストデバイス１０２は要求を受信し、要求されたコンテンツを、ネットワーク１０６を経由して要求側クライアントデバイス１０４にストリーム送信する。ネットワーク１０６には、ＩＥＥＥ１３９４を取り入れているネットワークのような、種々のネットワークが含まれている場合がある。一般的に、ネットワーク１０６には、種々のパケット交換ネットワーク(packet switched network)のいずれかが含まれることが意図されている。ホストデバイス１０２は、種々の従来コンピューティングデバイスのいずれかとして実現されている場合があり、その中には、例えば、サーバ、デスクトップＰＣ、ノートブックまたはポータブルコンピュータ、ワークステーション、メインフレームコンピュータ、インターネットアプライアンス、これらを組み合わせたものなどが含まれ、これらは、格納されたメディアコンテンツおよび／またはライブのメディアコンテンツをクライアントデバイス１０４にストリーム送信するように構成可能になっている。クライアント再生デバイス１０４も、種々の従来コンピューティングデバイスのいずれかとして実現されている場合があり、その中には、例えば、デスクトップＰＣ、ノートブックまたはポータブルコンピュータ、ワークステーション、メインフレームコンピュータ、インターネットアプライアンス、ゲーミングコンソール、ハンドヘルドＰＣ、セルラ電話や他の無線通信デバイス、パーソナルデジタルアシスタント(personal digital assistant：ＰＤＡ)、セットトップボックス、テレビジョン、これらを組み合わせたものなどが含まれている。ホストデバイス１０２とクライアントデバイス１０４を実現するための例示コンピュータは、図５を参照して以下に詳しく説明されている。
【００１２】
ホストデバイス１０２は、クライアントデバイス１０４に対してストリーミングすることが可能な種々のデータまたはコンテンツを作成することが可能であり、その中には、オーディオ、ビデオ、テキスト、イメージ、アニメーションなどのコンテンツが含まれる。ここで「ストリーム送信される(streamed)」または「ストリーミング(streaming)」という用語は、データがネットワーク１０６を介してクライアント再生デバイス１０４に提供され、コンテンツの再生がコンテンツ全体の配信に先立って開始することが可能であることを示すために用いられている。コンテンツは公共に利用可能である場合もあれば、逆に限定されている場合もある（例えば、一部のユーザだけに限定されている、該当料金が支払われた場合だけ利用可能である、特定のネットワークにアクセスできるユーザに限定されている、など）。さらに、コンテンツは「オンデマンド(on-demand)」である場合もあれば（例えば、既知サイズの録音済みで、格納されたコンテンツ）、逆にライブ「ブロードキャスト」からのものである場合もある（例えば、コンサートの演奏時に取り込まれて、その取り込み直後にストリーミングに利用可能にされるコンサートのデジタル表現のように、既知サイズのないもの）。
【００１３】
ネットワーク１０６は、種々の従来ネットワークプロトコル（公用および／または独自仕様のプロトコルを含む）のいずれかを採用している、種々の従来ネットワークトポロジおよびタイプ（光ネットワーク、有線ネットワークおよび／または無線ネットワークを含む）のいずれかを表わすことを意図している。ネットワーク１０６には、例えば、ホームネットワーク、企業ネットワーク、またはインターネット、ＩＥＥＥ１３９４が含まれ、１または複数のローカルエリアネットワーク（ＬＡＮ）および／またはワイドエリアネットワーク（ＷＡＮ）の少なくとも一部を含む場合もある。
【００１４】
例示ホストデバイス１０２は中央処理ユニットまたはプロセッサ１０８、およびメモリ１１０を含む。メモリ１１０には、ネットワーク１０６を介してクライアントデバイス１０４にストリーム送信されるコンテンツを作成または処理できるアプリケーションが含まれている。さらに、処理されたコンテンツおよび／または（別のソースから）受信されたコンテンツがコンテンツストレージ１１４に格納されている場合もある。この実現形態では、コンテンツストレージ１１４はメモリ１１０とは別になっている。他の実現形態では、コンテンツストレージ１１４はメモリ１１０の一部になっていることがある。クロック１１６は１または複数の機能を備えており、ホストデバイス１０２からストリーム送信されたデータパケットごとにタイムスタンプを発行することがある。
【００１５】
例示クライアントデバイス１０４は中央処理ユニットまたはプロセッサ１１８とメモリ１２０を含む。メモリ１２０には、ホストデバイス１０２のようなソースから受信したコンテンツを消費または使用するアプリケーション１２２が含まれている。ジッタバッファ(jitter buffer)１２４はデータパケットを受信し、中間バッファの働きをする。帯域幅が制限されたり、コンテンツのストリーミングにばらつきがあるといった、ある種の伝送問題がアンダフローやオーバフロー状態を引き起こしているために、特にオーディオ／ビデオコンテンツがストリーム送信されるとき、ストリーム送信されたコンテンツに不具合や中断が起こるのを防止するために一部のコンテンツ（すなわち、データパケット）をジッタバッファ１２４に保持しておくことが望まれている。
【００１６】
この実現形態では、デコーダ１２６はジッタバッファ１２４から符号化データパケットを受信し、そのデータパケットを復号化している。他の実現形態では、プリデコーダバッファ(pre-decoder buffer)（すなわち、デコーダ１２６の前に置かれたバッファ）が組み込まれていることがある。ケースによっては、圧縮データパケットがクライアントデバイスに送信され、クライアントデバイスにて受信されることがある。そのようなケースでは、クライアントデバイス１０４は、データパケットを伸張するコンポーネントで実現さていることがあり、その場合、このコンポーネントはデコーダ１２６の一部になっている場合とそうでない場合とがある。
【００１７】
伸張および復号化データパケットを受信し、コンテンツバッファ１２８に格納しておくことができる。他の実現形態では、２つのバッファがデコーダの前に置かれていることがある。第１バッファは、リアルタイム転送プロトコル(ＲＴＰ)を取り入れたデータパケットを保持しており、第２バッファはＲＴＰデータパケットコンテンツだけを保持している（つまり、ＲＴＰヘッダは保持していない）。第２バッファは、デコーダ１２６によって復号化されるべきコンテンツを備えている。言い換えれば、第１バッファはＲＴＰでカプセル化されたデータパケット（つまり、カプセル化されたデータコンテンツ）を保持しており、第２バッファは、復号化用の、ＲＴＰでカプセル化されていないデータパケット（つまり、カプセル化が解除されたデータコンテンツ）を保持している。コンテンツバッファ１２８は、コンテンツの特定のタイプを格納する１または複数のバッファを含んでいることがある。例えば、ビデオコンテンツを格納する別個のビデオバッファや、オーディオコンテンツを格納する別個のオーディオバッファがある。さらに、ジッタバッファ１２４は、オーディオコンテンツとビデオコンテンツを格納する別個のバッファを含む場合がある。
【００１８】
クライアントデバイス１０４は、各々の特定のデータパケットに組み込まれたユニークなタイムスタンプに基づいてデータパケットを区別するためにクロック１３０を備えている。言い換えれば、クロック１３０は、データパケットを正しい速度で再生するために使用される。一般的に、データパケットは、タイムスタンプに基づいてデータパケットをソートすることによって再生される。タイムスタンプは、データパケットに含まれ、ホストデバイス１０２のクロック１１６によって提供または発行される。
【００１９】
クライアントデバイス１０４は、コンテンツがホストデバイス１０２からストリーム送信される間にバッファ１２４と１２８の満杯レベルをモニタし、バッファ満杯報告(ＢＦＲ)１３４を生成するように構成されたモニタ１３２を備えている。ＢＦＲ１３４はバッファ満杯情報をホストデバイス１０２に提供する。一般的に、ＢＦＲ１３４の中で伝達される情報は、クライアントデバイス１０４にストリーム送信されるコンテンツまたはデータパケットのフローを制御または調整するためにホストデバイス１０２によって使用される。
【００２０】
本実施形態では、ホストデバイス１０２は、クライアントデバイス１０４などの、１または複数のクライアントデバイスから１または複数のＢＦＲ１３８を受信するように構成されたクライアントバッファ満杯報告（ＢＦＲ）モジュール１３６を備えている。ＢＦＲ１３８は特定のクライアントデバイスに固有になっている。受信され、クライアントＢＦＲモジュール１３６に格納された各々のＢＦＲ１３８は、別個のジッタバッファ、コンテンツバッファ、オーディオバッファ、ビデオバッファなどを含む、特定のクライアントバッファにおけるバッファ情報（つまり、満杯）についてホストデバイス１０２に通知する。ホストデバイス１０２は、コンテンツが伝送される（例えば、ストリーム送信される）レートを、ＢＦＲ１３８におけるバッファ情報に基づいて計算することができる。
【００２１】
ＢＦＲ１３４は、起り得るオーバフローまたはアンダフロー状態を示すためにクライアントデバイス１０４によって送出されることがある。また、ＢＦＲは、クライアントデバイス１０４によって定期的に送出されることもある。ケースによっては、クライアントデバイス１０４は別個のデータストリームにおいて応答の一部としてＢＦＲを送信することもある。応答がクライアントデバイス１０４によって行なわれるとき、その応答は定義されたフォーマットまたはプロトコルの形式になっていることがある。例えば、ＲＴＰ、具体的にはリアルタイムトランスポート制御プロトコル(real time transport control protocol：ＲＴＣＰ)が使用される場合は、データパケットとは別の制御パケットがホストデバイス１０２とクライアントデバイス１０４の間でやり取りされることがある。クライアントデバイス１０４からの制御パケットは、ホストデバイス１０２へのフィードバックとなるものである。ＢＦＲ１３８は、そのような制御パケットに組み入れられていることがある。
【００２２】
図２は、ジッタバッファ(jitter buffer)とコンテンツバッファ(content buffer)の実施例を示す図である。ここでは、ホストデバイス１０４に含まれるジッタバッファ１２４とコンテンツバッファ１２８を具体的に説明する。ジッタバッファ１２４はＮ個のストレージユニット２００を含み、そこでは各々のストレージユニット２００は受信したデータパケット２０２を格納しておくことができる。
【００２３】
ストレージユニット２００は先入れ先出し(first in first out：ＦＩＦＯ)構造に配列されて、最初に受信したデータパケットが最初にコンテンツバッファ１２８に送信されるか、あるいはデコーダ（例えば、デコーダ１２６）または他の中間コンポーネント（例えば、伸張器(de-compressor)）に送信されるようになっている。最初に受信されたデータパケット２０２が最初に処理されることがあっても、データパケット２０２がネットワーク内で並べ替えられること（つまり、失われること）が起り得る。この場合、受信されたデータパケットは該当する場所でコンテンツバッファ１２８内に挿入されることがあるので、他のデータパケットがシフトされることがある。
【００２４】
データパケット２０２は、コンテンツバッファ１２８または他の中間コンポーネントに送信されるまでストレージユニット２００に格納される。データパケット２０２がコンテンツバッファ１２８に送信されないと、ストレージユニット２００はストレージユニット２００（Ｎ）までデータパケット２０２で満たされることになる。この例では、ストレージユニット２００（１）に格納されたデータパケット２０２（１）、ストレージユニット２０２（２）に格納されたデータパケット２０２（２）、およびストレージユニット２００（３）に格納されたデータパケット２０２（３）が示されている。
【００２５】
ジッタバッファ１２４は、サポートまたは格納できるバイト数で定義され得る制限サイズを有する。さらに、ジッタバッファ１２４の制限サイズは、格納できるコンテンツの総時間長さに変換される「時間」サイズで定義することもできる。Ｎ個のストレージユニット２００はジッタバッファ１２４のサイズに制限されている。
【００２６】
コンテンツバッファ１２８はＭ個のストレージユニット２０４を含み、そこでは各々のストレージユニット２０４はデータパケット２０６を格納することが可能になっている。データパケット２０６は、復号化され、伸張され、アプリケーション（例えば、クライアントデバイス１０４のメモリ１２０に格納されたアプリケーション１２２）によってレンダリングの準備に置かれることが予想される。個数ＭはＮと同じ個数であることも、そうでないこともある。さらに、コンテンツバッファ１２８のサイズ（つまり、バイトサイズ）はジッタバッファ１２４のサイズと同じでないことがある。
【００２７】
コンテンツバッファ１２８のストレージユニット２０４はＦＩＦＯ構造に配列され、最初に受信したデータパケット２０６が最初に処理されるようになっている。通常、各データパケット２０６上のタイムスタンプをチェックして、データパケット２０６がいつ処理されるかを判定することが可能になっている。データパケット２０６は、コンテンツバッファ１２６または他の中間コンポーネントに送信されるまでストレージユニット２０４に格納されている。データパケット２０４が処理されないと、ストレージユニット２０４はストレージユニット２０４（Ｍ）までデータパケット２０６で満たされることになる。この例では、ストレージユニット２０４（１）に格納されたデータパケット２０６（１）、ストレージユニット２０４（２）に格納されたデータパケット２０６（２）、ストレージユニット２０６（３）に格納されたデータパケット２０４（３）、およびストレージユニット２０６（Ｍ−１）に格納されたデータパケット２０６（Ｍ−１）が示されている。
【００２８】
バッファ満杯報告、つまり、ＢＦＲ（例えば、ＢＦＲ１３４と１３８）は、任意の所与の瞬間におけるジッタバッファ１２４とコンテンツバッファ１２８の最大容量（すなわち、バイトサイズまたは時間サイズ）を具体的に記述している。なお、ＢＦＲからは、バッファ内の空きスペースに関する重要な情報が得られることに留意されたい。実現形態によっては、クライアントデバイスに２以上のジッタバッファおよび／またはコンテンツバッファが置かれていることもある。ＢＦＲは、そのようなバッファすべての最大容量と空きスペースを具体的に記述している。さらに、任意の所与の時点において、ＢＦＲは、いくつのストレージユニット（例えば、ストレージユニット２００と２０４）がデータパケット（例えば、データパケット２０２と２０６）で満たされているかを記述している。ＢＦＲは、以下で詳しく説明するように、バッファの「満杯」をバイトサイズおよび／または時間で表わすことができる。
【００２９】
図３は、ＢＦＲの伝送をサポートするプロトコルスタックを示すと共に、ＢＦＲから得られ得る具体的情報を示している。プロトコルスタック３００は、コンピュータネットワーキング・プロトコルスイート(computer networking protocol suite)をソフトウェアで具体的に実現したものである。このようなプロトコルスタックは業界で周知である。一般的に、プロトコルスタックの下位レベルは、ソフトウェアおよび／またはハードウェアの最下位レベルでデバイス（例えば、ホストデバイス１０２とクライアントデバイス１０４）間がやりとりする設計になっている。
【００３０】
この例では、プロトコルスタック３００の最下位プロトコルレベルは、一般的にホストデバイス１０２とクライアントデバイス１０４の間の「インタネットワーク(inter network)」接続の働きをするイーサネット(Ethernet(登録商標))レベル３０２である。次の上位レベルは、特にインターネットを介する通信を目的としたインターネットプロトコルレベル３０４である。ユーザデータグラムプロトコル(ＵＤＰ)３０６は、一般的ブロードキャストまたはメッセージ通信を行なうために使用されることがある。リアルタイムトランスポート制御プロトコル(ＲＴＣＰ)またはリアルタイムトランスポートプロトコル(ＲＴＰ)レベル３０８は、特にストリーミングコンテンツ（例えば、マルチメディア）などのリアルタイムデータを通信するために使用される。ＢＦＲは、別の上位レベルのＢＦＲレベル３１０を介して通信されることがある。レベル３１０を使用すると、クライアントデバイス１０４による実際のコンテンツ通信とは関係なくホストデバイス１０２からＢＦＲを通信することができる。
【００３１】
例示のＢＦＲ１３２は、バッファサイズ３１２を含み、そのサイズはクライアントデバイス１０４側のジッタバッファとコンテンツバッファを含む２以上のバッファに関するものである。言い換えれば、ＢＦＲは直接的に（つまり、ジッタバッファ１２４）または間接的に（つまり、ホストデバイス１０２からのコンテンツバッファ）コンテンツを受信するすべてのバッファについて提供される。「バイト」の単位は、処理用にバッファに現在格納されている、あるいは待ち（キュー）に置かれているデータ３１４の量を表わすために使用されることがある。これとは別に、空きスペースの量が表わされることもある。さらに、「時間」の単位は、処理用にバッファに現在格納されている、あるいは待ち（キュー）に置かれているデータ３１４の量を表わすために使用されることもある。情報は、個々のバッファごとに提供されることも、バッファのグループについて提供されることもある。
【００３２】
図４は、クライアントデバイスのバッファステータスをホストデバイスに通知するプロセス４００を示す図である。このプロセス４００は、論理的フローグラフにおけるブロックの集まりとして示されており、これらのブロックはハードウェア、ソフトウェア、ファームウエアまたはこれらを組み合わせたもので実現できるオペレーションのシーケンスを表わしている。ソフトウェアとの関連で、ブロックは、１または複数のプロセッサによって実行されたとき、列挙されたオペレーションを実行するコンピュータ命令を表わしている。プロセス４００は、上述したホストデバイス１０２およびクライアントデバイス１０４と関連付けて説明される。フローチャートとして説明されているものの、本発明によれば、あるプロセスは同時にまたは異なる順序で実行されるが意図されている。
【００３３】
ブロック４０２において、クライアントデバイスはバッファ情報に関してどのように、なにをやり取りするかについてホストデバイスとネゴシエートする。バッファ情報は、クライアントデバイス側で作成されるバッファ満杯報告（ＢＦＲ）の形式になっており、ホストデバイスに送信される。バッファ満杯報告のコンテンツまたはバッファ満杯報告に含まれる情報としては、クライアントデバイス側のバッファの容量またはサイズ、特定の場合にバッファで消費されるスペースの量、および受信されたコンテンツまたはデータパケットに関する情報がある。さらに、クライアントデバイスとホストデバイスとの間のネゴシエーションとしては、バッファ情報またはＢＦＲがどれだけの頻度でクライアントデバイスからホストデバイスに送信されるかを判定することがある。バッファ情報またはＢＦＲを送信する頻度またはレートを大きくすると、メディアを含むコンテンツなどの、データパケットのストリーミングの調整が向上し、バッファのアンダフローとオーバフローが防止されることになる。
【００３４】
ブロック４０４において、ホストデバイスはバッファ情報のやりとりに関してクライアントデバイスとネゴシエートする。ホストデバイスは、バッファ情報をやりとりすることに関するホストデバイスの機能を備えていることがあり、その中には、ホストデバイスによる最大アウトプット（つまり、コンテンツまたはデータパケットをストリーム送信する能力）が含まれている。さらに、ブロック４０２と４０４で行なわれるネゴシエーションの中には、バッファ情報またはＢＦＲを伝達するためにどのような通信プロトコルが使用されるかを特定することが含まれていることがある。
【００３５】
ブロック４０６において、クライアントデバイスは、コンテンツまたはデータパケットをホストデバイスから受信するすべてのバッファの容量を判定する。この判定は、ジッタバッファおよびコンテンツバッファなどの、すべてのバッファについて行なわれる。さらに、バイトサイズや時間サイズなどの、１または複数のサイズメトリックスについての判定が行なわれることもある。ケースによっては、バッファの総容量または集合容量についての判定が行なわれることもある。例えば、ジッタバッファの容量はコンテンツバッファの容量と結合されていることがある。
【００３６】
ブロック４０８において、クライアントデバイスはバッファ内の使用済みスペースと未使用スペースを計算する。この計算は、クライアントデバイスがコンテンツまたはデータパケットの受信を続けることが予想されることから、特定の時間的瞬時について行なわれる。バイトサイズまたは時間サイズは、使用済みスペースおよび未使用スペースの計算で使用されることがある。この計算をバッファの容量と関連付けて測定すると、追加のコンテンツまたはデータパケットが受信可能であるかどうか（つまり、アンダフローを意味する）、あるいは追加のコンテンツまたはデータパケットが受信不能であるかどうか（つまり、オーバフローを意味する）の情報が得られる。
【００３７】
ブロック４１０において、クライアントデバイスはバッファ情報を送信する。この情報はＢＦＲの形体になっていることがある。ストリームごとに別々のＢＦＲが送信されることもある。言い換えれば、あるＢＦＲはオーディオストリームについて送信され、別のＢＦＲはビデオストリームについては送信されることがある。一般的に、ＢＦＲからは、すべてのストリームに関する情報が得られる。ＢＦＲは、リアルタイムトランスポート制御プロトコル（ＲＴＣＰ）報告のような、別の報告または通信パケットの一部としてクライアントデバイスから送信されることがある。ケースによっては、ＢＦＲは、離散的(discrete)かつ別個の伝送として送信されることがある。例えば、ＢＦＲは別個の下位レベル通信プロトコルを介して伝達されることがある。
【００３８】
ホストデバイスはＢＦＲを受信すると（すなわち、ブロック４１２のＹＥＳブランチに続いて）、ブロック４１４において、ホストデバイスはクライアントデバイスに送信されたコンテンツのフローまたはレートを調整する。このレート調整は、ネットワーク上の伝送レートとコンテンツの符号化ビットレートに対して行なわれることがある。例えば、バッファ容量が高パーセンテージで使用されていること（すなわち、オーバフロー状態）をＢＦＲが示していれば、ホストデバイスはクライアントデバイスにストリーム送信されるコンテンツのレートを低速にする。逆に、バッファ容量が低パーセンテージで使用されていること（すなわち、アンダフロー状態）をＢＦＲが示していれば、ホストデバイスはクライアントデバイスにストリーム送信されるコンテンツのレートを大きくする。理想的または最適バッファ使用量からの偏差についても、考慮されることがある。言い換えれば、最適バッファ使用量からのプラスまたはマイナスの許容し得る偏差またはパーセンテージをＢＦＲが示していれば、フローレートの調整は行なわれない。特定のクライアントバッファに関する情報を提供する複数のＢＦＲは、特定のクライアントデバイスへのフローを調整するためにホストデバイスによって使用されることがある。言い換えれば、その特定デバイスには、複数のジッタバッファおよびコンテンツバッファが置かれていることがあり、各バッファはホストデバイスに送信される特定のＢＦＲを有する。ＢＦＲ情報から、ホストデバイスは、クライアントデバイス側のバッファごとの消費レートと全体の消費レートとを計算することができる。
【００３９】
ＢＦＲが受信されない場合（つまり、ブロック４１２のＮＯブランチに続いて）、この状態を解決するために２つのソリューションがあり得る。密結合ソリューション (tightly coupled solution)が選択された場合は（つまり、ブロック４１６のＹＥＳブランチに続いて）、ＢＦＲはホストデバイスからクライアントデバイスへのコンテンツのフローを排他的に指示している。言い換えれば、密結合ソリューションによると、クライアントデバイスへのコンテンツをスロットル（すなわち、ストリーム送信）するためにＢＦＲがホストデバイスによって使用される。密結合ソリューションでは、ホストデバイスはクライアントのバッファが満杯になるまでコンテンツを送信してから停止することがある。ホストデバイスはクライアントのバッファにスペースが残っていることをＢＦＲが示した後に、送信を再開することができる。ＢＦＲが受信されない場合には、ブロック４１８において、ホストデバイスは以前または最後に受信したＢＦＲに示されている情報を使用することができる。あるいは、ホストデバイスは次のＢＦＲまたは以後のＢＦＲまで待機することもある。初期送信の場合には（つまり、ＢＦＲが全く受信されていない場合）、ホストデバイスは最初のＢＦＲまで待機することができる。
【００４０】
密結合ソリューションが選択されない場合、言い換えれば、疎結合ソリューション(loosely coupled solution)が選択された場合には（つまり、ブロック４１６のＮＯブランチに続いて）、ブロック４２０において、ＢＦＲは助言的な情報(advisory information)としてのみ使用される。言い換えれば、ＢＦＲが受信されない場合、１つの例として、ホストデバイスは、事前に定義されたレート（つまり、フロー）または以前のＢＦＲに基づいて計算された（つまり、推論された）レートに基づいてコンテンツまたはデータパケットをストリーム送信することがある。他のケースでは、ホストデバイスはホストデバイスの容量に基づいてコンテンツまたはデータパケットをストリーム送信することがある。疎結合ソリューションでは、ＢＦＲは助言的な情報として使用され、ＢＦＲが受信されない場合は、コンテンツは依然としてホストデバイスに送信されることがある。ホストデバイスはフローをスロットルするヒントとしてＢＦＲを使用する。ホストデバイスは、クライアントデバイスがバッファ内のコンテンツを消費するときの概算のレート（プラスまたはマイナスのクロックドリフト）を知っていることがあるので、ホストデバイスはコンテンツを送信する前にＢＦＲを待たないで済むのが通常である。
【００４１】
＜フロー制御＞
ＢＦＲは、クライアントデバイス側で利用可能なバッファの数に基づくストリーム伝送であるフロー制御の一般的なコンセプトを示している。フロー制御を使用すると、ホストデバイスは任意の時点でクライアントデバイス側に空きバッファがいくつ利用可能であるかを正確に知り、クライアントデバイスのバッファがオーバフローしないことを保障することができる。フロー制御の一部としては、ホストデバイスに頻繁に送信されるＢＦＲによって、ホストデバイスがその伝送レートを調整して、クライアントデバイスバッファが使い果たされて不具合を引き起こさないことを保障することができる。ネットワークのエラーが原因でネットワーク輻輳または遅延が発生して転送レートを低下させる場合には、フロー制御とＢＦＲによって、データを正しいレートで送信することが可能になる。クライアント側に利用可能なバッファスペースをホストデバイスが知っている場合には、ホストデバイスは、ストリームスタートアップ時または中断期間に利用可能なスペースを即時に満たすことができるので、結果的にパフォーマンスが向上することになる。一時的にネットワーク輻輳が起こった場合には、ホストデバイスは、コンテンツをより高速に配信し、１または複数のクライアントのバッファを満たすことにより「キャッチアップ(catch-up)」することができる。一般的に、ホストデバイスは、クライアントデバイスのジッタバッファが格納されたコンテンツについて満杯になったことを確かめることができ、クライアントデバイスはネットワークジッタに対してよりトレラントになり、システムはより強固になる。
【００４２】
＜例示コンピュータ＞
図５は、本発明の主題の側面を実施する環境として適している例示のコンピューティングデバイスまたはコンピュータ５００を示す図である。具体的には、コンピュータ５００はホストデバイス１０４とクライアントデバイス１０４を詳細に表わしている。コンピュータ５００は、本発明の主題の側面を実施する環境として適している。コンピュータ５００のコンポーネントとしては、処理ユニット５０５（例えば、プロセッサ１０８と１１８）、システムメモリ５１０（例えば、メモリ１１０と１２０）、およびシステムメモリ５１０を含む種々のシステムコンポーネントを処理ユニット５０５に結合するシステムバス５２１があるが、これらに限定されない。システムバス５２１は、数種のバス構造のいずれかである場合があり、その中には種々のバスアーキテクチャのいずれかを使用したメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスが含まれている。例を挙げると、そのようなバスアーキテクチャとしては、ＩＳＡ(Industry Standard Architecture)バス、ＭＣＡ(Micro Channel Architecture)バス、ＥＩＳＡ(Enhanced ISA)バス、ＶＥＳＡ(Video Electronics Standards Association)ローカルバス、およびMezzanineバスとしても知られているＰＣＩ(Peripheral Component Interconnect)バスがあるが、これらに限定されない。
【００４３】
例示コンピュータ５００は、種々のコンピュータ可読媒体を備えているのが代表的である。コンピュータ可読媒体としては、コンピュータ５００がアクセス可能な利用可能媒体ならばどのような媒体でもよく、その中には揮発性媒体と不揮発性媒体で、取り外し可能媒体と取り外し不能媒体の両方が含まれている。例を挙げると、コンピューティングデバイス可読媒体としては、コンピュータ記憶媒体および通信媒体があるが、これらに限定されない。コンピュータ記憶媒体としては、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータなどの情報を記憶するための、いずれかの方法またはテクノロジで実現された揮発性および不揮発性で取り外し可能および取り外し不能媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリテクノロジ、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク(digital versatile disk：ＤＶＤ)または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは必要とする情報を格納するために使用することができ、管理サーバ５００によってアクセス可能な他の媒体が含まれるが、これらに限定されない。通信媒体は、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータを、搬送波または他のトランスポートメカニズムなどの変調データ信号で具現化しているのが代表的であり、その中には情報配信媒体が含まれている。ここで「変調データ信号(modulated data signal)」とは、その特性の１または複数が、情報を信号において符号化するような形でセットまたは変更された信号のことである。例を挙げると、通信媒体としては、有線ネットワークや直接有線コネクションなどの有線媒体、および音響、ＲＦ、赤外線および他の無線媒体などの無線媒体があるが、これらに限定されない。上記に列挙したいずれかを組み合わせたものも、当然にコンピューティングデバイス可読媒体の範囲に含まれるものである。
【００４４】
システムメモリ５１０には、リードオンリメモリ(read only memory：ＲＯＭ)５３１やランダムアクセスメモリ(random access memory：ＲＡＭ)５３２などの揮発性および／不揮発性メモリの形式のコンピューティングデバイス記憶媒体が含まれている。スタートアップ時の期間のように、コンピュータ５００内のエレメント間で情報を転送するのを支援する基本ルーチンからなる基本入力／出力システム（ＢＩＯＳ）５３３はＲＯＭ５３１に格納されているのが代表的である。ＲＡＭ５３２は、処理ユニット５０５によって即時にアクセス可能でありおよび／または現在操作の対象になっているデータおよび／またはプログラムモジュールを収めているのが代表的である。図５はオペレーティングシステム５３４、アプリケーションプログラム５３５（この中にはアプリケーション１１２または１２２が含まれている）、その他のプログラムモジュール５３６、およびプログラムデータ５３７を例示しているが、これらに限定されない。その他のプログラムモジュール５３６には、バッファモニタ１３２およびクライアントＢＦＲ報告モジュール１３６が含まれていることがある。
【００４５】
コンピュータ５００は、その他の取り外し可能／取り外し不能で、揮発性／不揮発性コンピュータ記憶媒体を備えていることもある。図５は、取り外し不能で不揮発性磁気媒体との間で読み書きを行なうハードディスクドライブ５４１、取り外し可能で不揮発性磁気ディスク５５２との間で読み書きを行なう磁気ディスクドライブ５５１、およびＣＤ−ＲＯＭや他の光媒体などの取り外し可能で不揮発性光ディスク５５６との間で読み書きを行なう光ディスクドライブ５５５を例示しているが、これらに限定されない。例示動作環境で使用できるその他の取り外し可能／不揮発性、揮発性／取り外し不能コンピューティングデバイス記憶媒体としては、磁気テープ、磁気テープカセット、フラッシュメモリカード、デジタルバーサタイルディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがあるが、これらに限定されない。ハードディスクドライブ５４１は、インタフェース５４０のような取り外し不能メモリインタフェースを通してシステムバス５２１に接続されているのが代表的であり、磁気ディスクドライブ５５１と光ディスクドライブ５５５は、インタフェース５５０のような取り外し可能メモリインタフェースによってシステムバス５２１に接続されているのが代表的である。
【００４６】
上述し、図５に図示のドライブおよびその関連コンピューティングデバイス記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュールおよびその他のデータをコンピュータ５００のために格納している。図５において、例えば、ハードディスクドライブ５４１はオペレーティングシステム５４４、アプリケーションプログラム５４５、その他のプログラムモジュール５４６およびプログラムデータ５４７を格納するものとして示されている。なお、これらのコンポーネントは、オペレーティングシステム５３４、アプリケーションプログラム５３５、その他のプログラムモジュール５３６およびプログラムデータ５３７と同じである場合と、異なる場合とがあることに留意されたい。ここで、オペレーティングシステム５４４、アプリケーションプログラム５４５、その他のプログラムモジュール５４６およびプログラムデータ５４７に異なる番号が付けられているのは、最低限、これらが異なるコピーであることを示すためである。ユーザは、キーボード５４８およびマウス、トラックボール、タッチパッドと一般に呼ばれているポインティングデバイス５６１などのインプットデバイスを通して、コマンドと情報を例示のコンピュータ５００に入力することができる。その他のインプットデバイス（図示せず）としては、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ(satellite dish)、スキャナなどがある。これらおよびその他のインプットデバイスはシステムバスに結合されたユーザインプットインタフェース５６０を通して処理ユニット５２０に接続されることが多いが、パラレルポート、ゲームポートまたは特にＵＳＢポートなどの他のインタフェースおよびバス構造によって接続されることもある。
【００４７】
モニタ５６２または他のタイプのディスプレイデバイスも、ビデオインタフェース５９０のようなインタフェースを介してシステムバス５２１に接続されている。モニタ５６２のほかに、コンピューティングデバイスはスピーカ５９７およびプリンタ５９６などの他の周辺アウトプットデバイスを有することが可能であり、これらはアウトプット周辺インタフェース５９５を通して接続可能になっている。
【００４８】
例示のコンピュータ５００は、リモートコンピューティングデバイス５８０のような、１または複数のリモートコンピューティングデバイスへの論理的コネクションを使用してネットワーキング環境で動作させることができる。リモートコンピューティングデバイス５８０はパーソナルコンピューティングデバイス、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたはその他の共通ネットワークノードにすることができ、コンピュータ５００に関連して上述したエレメントの多くまたはすべてを備えているのが代表的である。図５に図示の論理的コネクションはローカルエリアネットワーク（ＬＡＮ）５７１とワイドエリアネットワーク（ＷＡＮ）５７３を含んでいるが、上述したネットワーク１０６のような他のネットワークが含まれていることもある。このようなネットワーキング環境はオフィス、企業内コンピューティングデバイスネットワーク、イントラネット、およびインターネットで普及している。
【００４９】
ＬＡＮネットワーキング環境で使用されるときは、例示管理サーバ５００は、ネットワークインタフェースまたはアダプタ５７０を通してＬＡＮ５７１に接続されている。ＷＡＮネットワーキング環境で使用されるときは、例示コンピュータ５００は、インターネットのようなＷＡＮ上で通信を確立するためのモデム５７２または他の手段を備えているのが代表的である。モデム５７２は内蔵型と外付け型があり、ユーザインプットインタフェース５６０または他の該当メカニズムを介してシステムバス５２１に接続されるもともある。ネットワーキング環境では、例示コンピュータ５００に関連して図示のプログラムモジュールまたはその一部は、リモートメモリストレージデバイスに格納されていることがある。図５はリモートアプリケーションプログラム５８５を例示しているが、これに限定されない。以上から理解されるように、ネットワークコネクションは例示であり、コンピューティングデバイス間の通信リンクを確立する他の手段が使用されることもある。
【００５０】
＜結論＞
上述した方法およびコンピュータは、クライアントデバイスからホストデバイスにバッファ満杯報告を提供するものとして説明されている。構造上の特徴および／または方法における実行に特有の言葉で本発明を説明してきたが、当然に理解されるように、請求項に定義されている本発明は、必ずしも特定の特徴または実行に限定されるとは限らない。むしろ、特定の特徴およびアクトは、請求項に記載の発明を実現する例示形態として開示されたものである。
【図面の簡単な説明】
【００５１】
【図１】クライアントデバイスからホストデバイスに対してバッファ満杯報告を提供するのに適した例示環境を示すブロック図である。
【図２】クライアントデバイスに含まれるジッタバッファとコンテンツバッファの例示実施形態を示すブロック図である。
【図３】プロトコルスタックおよびそのプロトコルスタックを介して伝送されるバッファ満杯報告の例示実施形態を示すブロック図である。
【図４】クライアントデバイスのバッファステータスをホストデバイスに通知するプロセスを示すフロー図である。
【図５】図１乃至図４を参照して説明されているようなホストデバイスとクライアントデバイスを実現するのに適した例示コンピューティング環境を示す図である。
【図１】
2008543176.tif 000003
【図２】
2008543176.tif 000004
【図３】
2008543176.tif 000005
【図４】
2008543176.tif 000006
【図５】
2008543176.tif 000007
【国際調査報告】
2008543176.tif 000008