(57)【要約】本発明によれば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）トランスポートを用いて、ストリーミングコンテンツオブジェクトを再生する方法が開示される。１つの工程において、ストリーミングコンテンツオブジェクトの第１の部分が、ＨＴＴＰを用いて、パケット交換ネットワーク（１０８）から受信される。第１の部分は、該第１の受信工程と少なくとも部分的に時間的に同時に再生される。ストリーミングコンテンツオブジェクトの第２の部分が受信される。第２の部分は、ストリーミングコンテンツオブジェクトにおいて、第１の部分とは連続していない。
2005510919.tif 000002
【特許請求の範囲】
【請求項１】
ハイパーテキスト転送プロトコル（ＨＴＴＰ）トランスポートを用いて、ストリーミングコンテンツオブジェクトを再生する方法であって、
ＨＴＴＰを用いてパケット交換ネットワークから、ストリーミングコンテンツオブジェクトの第１の部分を受信する工程と、
前記第１の受信工程と少なくとも部分的に時間的に同時に、第１の部分を再生する工程と、
ストリーミングコンテンツオブジェクトの第２の部分を受信する工程と、ストリーミングコンテンツオブジェクト内で第２の部分は第１の部分と連続していないことと
から成る方法。
【請求項２】
前記第２の受信工程と少なくとも部分的に時間的に同時に、第２の部分を再生する工程をさらに含む、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項１に記載の方法。
【請求項３】
第２の部分を再生する前に、第２の部分内のキーフレームを待つ工程をさらに含む、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項１に記載の方法。
【請求項４】
中間にいかなる再生もなく、第１の部分が第２の部分に時間的に隣接して再生される、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項１に記載の方法。
【請求項５】
再生制御に関連するユーザ入力を検出する工程をさらに含み、前記第２の受信工程が、前記検出工程に少なくとも部分的に応答するものである、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項１に記載の方法。
【請求項６】
第２の部分のためのバイト範囲を決定する工程をさらに含む、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項１に記載の方法。
【請求項７】
ストリーミングコンテンツオブジェクトの第２の部分の位置を決定する工程をさらに含む、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項１に記載の方法。
【請求項８】
遠隔サーバから第１の部分を要求する工程と、
遠隔サーバから第２の部分を要求する工程と
をさらに含む、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項１に記載の方法。
【請求項９】
ＨＴＴＰトランスポートを用いて、ストリーミングコンテンツオブジェクトを再生する方法であって、
ＨＴＴＰトランスポートを用いて、ストリーミングコンテンツオブジェクトの第１の部分を受信する工程と、
ストリーミングコンテンツオブジェクトの再生制御に対応するユーザ入力を検出する工程と、
前記検出工程に少なくとも部分的に応答して、ストリーミングコンテンツオブジェクトの第２の部分を受信する工程と
から成る方法。
【請求項１０】
前記第１の受信工程と少なくとも部分的に時間的に重複して、第１の部分を再生する工程をさらに含む、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項９に記載の方法。
【請求項１１】
再生制御が、ストリーミングコンテンツオブジェクトの不連続なポイントまで再生ポイントを移動するものである、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項９に記載の方法。
【請求項１２】
前記第１の受信工程と少なくとも部分的に同時に、第１の部分を再生する工程と、
前記第２の受信工程と少なくとも部分的に同時に、第２の部分を再生する工程と、前記第１の再生工程が、前記第２の再生工程と時間的に隣接して実行されることと
をさらに含む、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項９に記載の方法。
【請求項１３】
再生制御に関連するユーザ入力を検出する工程をさらに含み、前記第２の受信工程が、前記検出工程に少なくとも部分的に応答するものである、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項９に記載の方法。
【請求項１４】
第２の部分のためのバイト範囲を決定する工程をさらに含む、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項９に記載の方法。
【請求項１５】
ＨＴＴＰトランスポートを用いて、ストリーミングコンテンツオブジェクトを再生するコンテンツ再生製品であって、
ＨＴＴＰトランスポートを用いて、ストリーミングコンテンツオブジェクトの第１の部分を受信するコードと、
ストリーミングコンテンツオブジェクトの再生制御に対応するユーザ入力を検出するコードと、
前記検出工程に少なくとも部分的に応答して、ストリーミングコンテンツオブジェクトの第２の部分を受信するコードと、
前記３つのコードを備えた機械可読媒体と
を有するコンテンツ再生製品。
【請求項１６】
前記第１の受信工程と少なくとも部分的に時間的に重複して、第１の部分を再生するコードをさらに有する、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項１５に記載のコンテンツ再生製品。
【請求項１７】
前記第１の受信工程と少なくとも部分的に同時に、第１の部分を再生するコードと、
前記第２の受信工程と少なくとも部分的に同時に、第２の部分を再生するコードと、前記前記第１の再生工程が、前記第２の再生工程に時間的に隣接することと
をさらに有する、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項１５に記載のコンテンツ再生製品。
【請求項１８】
再生制御に関連するユーザ入力を検出するコードをさらに有し、前記第２の受信工程が、検出工程に少なくとも部分的に応答するものである、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項１５に記載のコンテンツ再生製品。
【請求項１９】
第２の部分のためのバイト範囲を決定するコードをさらに有する、ＨＴＴＰトランスポートを用いてストリーミングコンテンツオブジェクトを再生する請求項１５に記載のコンテンツ再生製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、２００１年１１月２８日に出願された米国特許出願第０９／９９７，５１９号の優先権を主張する。
本発明はネットワークファイル転送に関し、詳細には、ハイパーテキスト転送プロトコル（ＨＴＴＰ）でのコンテンツのストリーミングに関する。
【背景技術】
【０００２】
インターネット上で、ファイルはＨＴＴＰやその他のファイル転送プロトコルで転送される。ＨＴＴＰトランスポートは、いかなる再生操作も行うことなく、コンテンツオブジェクトを最初から最後までストリーミングするために用いられる。ＨＴＴＰは、ファイルを転送する最も遍在的なプロトコルの１つであるが、ストリーミングされたコンテンツ（以下、本明細書ではストリーミングコンテンツと記す）のトランスポート用に他のプロトコルも開発されている。かかるトランスポートプロトコルには、ＲＥＡＬＴＭ、Ｗｉｎｄｏｗｓ  Ｍｅｄｉａ  ＡｕｄｉｏＴＭ（ＷＭＡ）およびＱｕｉｃｋｔｉｍｅＴＭが含まれ、これらはすべて、それぞれリアルネットワークス社（RealNetworks（登録商標））、マイクロソフト社（Microsoft （登録商標））およびアップル社（Apple （登録商標））社が所有する専売プロトコルである。これらのプロトコルは、各プロトコルの事業者によって販売されるカスタムサーバソフトウェアで支援される。ストリーミングコンテンツのプロトコルは、サーバソフトウェアと組み合わせると、ストリーミングコンテンツをダウンロードしている間に、再生操作が可能となる。
【０００３】
１実施形態において、本発明は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）トランスポートを利用して、ストリーミングコンテンツオブジェクトを再生する１つの方法を提供する。１つの工程において、ストリーミングコンテンツオブジェクトの第１の部分が、ＨＴＴＰを用いて、パケット交換ネットワークから受信される。第１の部分は、該第１の受信工程と、少なくとも部分的に時間的に一致して再生される。ストリーミングコンテンツオブジェクトの第２の部分が受信される。第２の部分は、ストリーミングコンテンツオブジェクトにおいて、第１の部分とは隣接していない。
【０００４】
別の実施形態において、本発明は、ＨＴＴＰトランスポートを利用して、ストリーミングコンテンツオブジェクトを再生する１つの方法を提供する。１つの工程において、ストリーミングコンテンツオブジェクトの第１の部分が、ＨＴＴＰトランスポートを用いて受信される。ストリーミングコンテンツオブジェクトの再生制御に対応するユーザ入力が検出される。ストリーミングコンテンツオブジェクトの第２の部分が、ユーザ入力の検出に少なくとも部分的に応答して、受信される。
【０００５】
さらに別の実施形態において、本発明は、ＨＴＴＰトランスポートを利用して、ストリーミングコンテンツオブジェクトを再生するコンテンツ再生製品を提供する。コンテンツ再生製品は、ＨＴＴＰトランスポートを利用して、ストリーミングコンテンツオブジェクトの第１の部分を受信するコードと、ストリーミングコンテンツオブジェクトの再生制御に対応するユーザ入力を検出するコードと、検出工程に少なくとも部分的に応答する、ストリーミングコンテンツオブジェクトの第２の部分を受信するコードと、それらの３つのコードを備えた機械可読媒体とを有する。
【発明を実施するための最良の形態】
【０００６】
本発明を添付図面を用いて説明する。添付図面において、同様の構成要素および／または特徴は、同じ参照符号を有し得る。
以下の説明は、好ましい典型的な実施形態を説明しているだけであり、本発明の範囲、利用性、あるいは構成を制限することは意図していない。そうではなく、好ましい典型的な実施形態の以下の説明は、本発明の好ましい典型的な１実施形態の実施を可能とする説明を当業者に提供する。添付の特許請求の範囲に設定されるように、本発明の精神と範囲から逸脱することなく、構成要素の機能と配列に種々の変更が行えることは言うまでもない。
【０００７】
本発明は、再生操作を可能にする、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いて、ストリーミングコンテンツオブジェクトを再生する方法を含む。ユーザは、ストリーミングコンテンツオブジェクトをダウンロードしている間に、現在のストリームポイントとは連続していない別の再生ポイントを選択できる。ファイルの新しい位置が決定され、その新しい位置に対応するストリームが要求される。このようにして、ユーザは、ＨＴＴＰトランスポートが使用されるストリーミングコンテンツオブジェクト内のどの位置にも前後にスキップできる。
【０００８】
まず、図１を参照すると、ストリーミングコンテンツの分配システム１００の１実施形態のブロック図が示される。オリジンサーバ１０４が、インターネット１０８上で、コンテンツ処理プログラム１２４にコンテンツオブジェクトを送る。コンテンツ処理プログラム１２４は、ネットワークインターフェース１１２を通してインターネット１０８と通信を行う。示されないが、オリジンサーバ１０４はネットワークインターフェースも有している。
【０００９】
オリジンサーバ１０４は、コンテンツ処理プログラム１２４から通常は離れた位置で、コンテンツオブジェクトをホストする。オリジンサーバ１０４のソフトウェアは、コンテンツ処理プログラム１２４に関連してユーザに提供されるウェブページを作成する。ウェブページのリンクはコンテンツオブジェクトファイルへのＨＴＴＰ呼び出しである。リンクを一旦選択すると、コンテンツオブジェクトファイルをコンテンツ処理プログラム１２４に送信開始するため、オリジンサーバ１０４にＨＴＴＰ呼び出しが行われる。
【００１０】
コンテンツ処理プログラム１２４の基底にあるオペレーティングシステムは、アプリケーションプログラムインターフェース（ＡＰＩ）またはその等価物を介して、ネットワークインターフェース１１２と通信を行う。コンテンツオブジェクトファイルがネットワークインターフェース１１２から受信されると、オペレーティングシステムはファイルタイプを認識し、そのファイルタイプに関係するコンテンツ処理プログラム１２４を呼び出す。
【００１１】
コンテンツ処理プログラム１２４は、ストリーミングコンテンツオブジェクトファイルを、それがオリジンサーバ１０４からダウンロードされたときに再生する。コンテンツ処理プログラム１２４によって、音声または画像が再生され得る。ＲｅａｌＴＭ、Ｗｉｎｄｏｗｓ  Ｍｅｄｉａ  ＡｕｄｉｏＴＭ（ＷＭＡ）、ＱｕｉｃｋｔｉｍｅＴＭなどのＨＴＴＰ以外のトランスポートも支援される。コンテンツオブジェクトファイルは、ストリーミングの開始後に最初から通常は再生されるが、ユーザは、開始点から離れた時点まで音声や画像を先にスキップすることを望むことがある。たとえば、ユーザは、映画から冒頭の内容解説表示（クレジット）をとばすことを望むことがある。コンテンツ処理プログラム１２４がファイル内のコンテンツのいずれの部分でもコンテンツオブジェクトファイルを再生できるよう、コンテンツオブジェクトファイルはストリーミング形式を使用する。非ストリーミング形式の場合、再生が開始する前に、ファイル全体がダウンロードされる。
【００１２】
コンテンツ処理プログラムのスライダーバー、先送りボタンまたは巻戻しボタンにより、ユーザは、ストリーミングコンテンツファイルが再生を再開する場所をコンテンツ処理
プログラム１２４に伝えることが可能である。たとえば、ユーザは、ＭＰ３形式で聞き覚えのない歌のダウンロードを開始することがある。その後すぐに、ユーザは、ユーザがその歌を聞きたいかどうかをユーザが素早く判断できるように、歌の開始後１０％の時点すなわち３０秒後の箇所にスライダーを移動させる。コンテンツ処理プログラム１２４は、スライダー位置に対応するコンテンツオブジェクトファイルのバイト範囲を決定し、オリジンサーバ１０４からそのバイト範囲を要求する。コンテンツオブジェクトファイルの該バイト範囲が、一旦、コンテンツ処理プログラム１２４のストリーミングを開始すると、該バイト範囲が再生される。
【００１３】
図２を参照すると、ストリーミングコンテンツの分配システム２００の別の実施形態のブロック図が示される。本実施形態では、ＨＴＴＰを用いてコンテンツオブジェクトをストリーミングする能力を本来は備えていないが、再生の操作は可能であるコンテンツ処理プログラム１２４が使用される。処理プログラム１２４にＨＴＴＰストリーミング済ファイルを再生できるようにさせるため、ビューアオブジェクトプロキシ２０４とスキン２１２が用いられる。ユーザは、再生の操作のため、スキン２１２とインターフェースを取る。
【００１４】
コンテンツ処理プログラム１２４の観点から見ると、サポートされていないＨＴＴＰトランスポートが使用されているにもかかわらず、ユーザは、コンテンツ処理プログラム１２４に固有のトランスポートメカニズムを利用してコンテンツファイルを要求しているように見える。この擬態はスキン２１２とビューアオブジェクトプロキシ２０４によって実行される。スキンからのコマンドが、ビューアオブジェクトプロキシ２０４によって、コンテンツ処理プログラム１２４によって理解されるコマンドに変換され、コンテンツオブジェクトの再生のストリーミングが生じる。たとえば、スキン２１２で、ＨＴＴＰトランスポートでのファイル要求はＷＭＡファイル要求に変換される。ビューアオブジェクトプロキシ２０４はＷＭＡ要求を、オリジンサーバ１０４が理解するＨＴＴＰ要求に変換する。
【００１５】
次に図３を参照すると、ユーザーが再生を操作している間に、ユーザがコンテンツオブジェクトの受渡をストリーミングするプロセス３００の１実施形態のフローチャートが示される。図示したプロセスは、ユーザが、ストリーミング可能なコンテンツオブジェクトのためのウェブページを見ている工程３０８から始まる。工程３１２において、ＨＴＴＰトランスポートを支援するが他のトランスポートプロトコルは支援しない可能性のあるオリジンサーバ１０４からダウンロードするコンテンツオブジェクトファイルが選択される。工程３１４で、ブラウザがそのファイルのＨＴＴＰ要求を行う。
【００１６】
工程３１６で、関連するコンテンツ処理プログラム１２４を呼び出すため、ファイル拡張子（たとえば．ＭＰ３、．ＲＡ、．ＭＯＶ、．ＭＰＧなど）で表されるファイルのタイプがオペレーティングシステムに送られる。工程３２０で、コンテンツ処理プログラムが、ファイルの最初から、ストリーミングコンテンツを再生する。工程３２８で、ユーザは、現在再生中の部分とは不連続なコンテンツオブジェクトファイルの別の部分を要求できる。不連続部分が要求されると、工程３３２で、対応するバイト範囲が要求され、ストリーミングされる。あるいは、不連続部に対する要求がない場合は、工程３３６に処理が続く。
【００１７】
キーフレームを有するファイル形式の場合、不連続部分の再生は、コンテンツオブジェクトファイルの次のキーフレームまで通常生じ得ない。コンテンツ処理プログラム１２４は、要求されたバイト範囲のバイトを受信し、音声または画像を再生する前に、次のキーフレームまで待機する。幾つかの実施形態では、ビューアオブジェクトプロキシ２０４は、コンテンツ処理プログラム１２４が直ちに再生を開始できるよう、キーフレームの前に
生じるバイトストリームの部分を送ることすらしない。さらに別の実施形態において、たとえばＭＰＥＧ画像の場合に、画像が一定期間中ブロック状になるよう、コンテンツ処理プログラム１２４は、キーフレームなしに再生を開始できる。
【００１８】
工程３３６において、コンテンツオブジェクトファイルの再生が完了しているかを判断するため試験が実行される。ストリームが完全にダウンロードされて、再生されているか、ユーザがダウンロードを中止した場合、再生は完了し、プロセスが終了する。再生が完了していないと、プロセスは工程３２８に戻る。このようにして、ユーザは、ＨＴＴＰトランスポートを用いてコンテンツオブジェクトをストリーミングするために、コンテンツ処理プログラム１２４とインターフェースする。他の実施形態は、コンテンツ処理プログラムが、ＨＴＴＰトランスポート用の支援を本来欠いている場合に、コンテンツオブジェクトのストリーミングをするために、スキン２１２とコンテンツ処理プログラム１２４を用いることができる。
【００１９】
図４を参照すると、再生操作と共にコンテンツオブジェクトの受渡をストリーミングするプロセス４００の１実施形態のフローチャートが示される。図示したプロセスは、コンテンツ処理プログラム１２４が、遠隔にあるオリジンサーバ１０４からのコンテンツオブジェクトファイルにＨＴＴＰ要求を行う工程４０８から始まる。コンテンツ処理プログラム１２４は、インターネット１０８あるいは何らかの他のパケット交換ネットワークによって、オリジンサーバ１０４に接続されている。
【００２０】
工程４１２と４１６において、ダウンロードされる予定のファイルが分析される。ファイル形式は、一般的にファイル名拡張子によって判断され得る。バイト数で表されるファイル長は、ファイルのＨＴＴＰトランスポートより前に送られるＨＴＴＰヘッダから判断される。ファイル形式を知ることで、ファイルのデータとヘッダをどのように解釈するかの判断が可能となる。ファイル内で、ファイルヘッダは、ファイル内のコンテンツに関するさらなる情報を提供する。通常、ファイルヘッダには、ビットレート、コーデック、その他の形式情報が含まれる。
【００２１】
コンテンツファイルに関するこの情報を備え、ファイル内のコンテンツの位置と上記情報の形式が工程４１６で決定される。たとえば、ファイル名が「Beach Boys-Surfin' USA.MP3」で、ファイルサイズが２，８９０キロバイトとする。拡張子「．ＭＰ３」は、ファイルがＭＰＥＧ−１音声レイヤ３形式を使用していることを意味する。標準のＭＰ３ファイルヘッダ内で、毎秒１６０キロビットのコード化速度が、２分２７秒のトラック時間とともに指定され得る。この時点で、音声を表すコンテンツファイルの部分が決定でき、たとえば、ファイルの最後の２，８８０キロバイトが音声データに相当し、ここでファイルの最初の１０キロバイトがヘッダ情報である場合がある。
【００２２】
音声データのダウンロードと再生が工程４２０で実行される。工程４２４では、ストリームのダウンロードが完了したかどうかの判断が行われる。ダウンロードがまだ完了していないと仮定すると、プロセスは工程４２８に続き、そこで、ユーザによるいかなる再生制御も検出される。再生制御がない場合、プロセスは、コンテンツファイルが連続したあるいは時系列的な態様でダウンロードを継続する工程４２０に戻る。
【００２３】
工程４２８でユーザが再生を制御している場合、プロセスは、要求するＨＴＴＰバイト範囲が決定される工程４３２に分岐する。画像または音声データのいずれの部分かのコンテンツファイルのバイト範囲は、ユーザによって指定される時間または割合に基づいて補間され得る。前述の例に続いて、ユーザは、コンテンツ処理プログラム１２４内でスライダーを移動させて、「Surfin' USA 」という歌の中間の位置、あるいはその歌の約１分１４秒の位置を示すことができる。固定コード化速度を仮定すると、バイト範囲は、ファイ
ルの最後の２，８８０キロバイトの半分を過ぎて開始、すなわち、ファイルの１，４５０キロバイトの箇所から開始する。新しいバイト範囲が一旦決定されると、工程４３６で、ＨＴＴＰバイト要求コマンドを用いて、オリジンサーバ１０４からそのバイト範囲が要求される。プロセスが工程４２０に戻った後に、コンテンツ処理プログラム１２４が、コンテンツオブジェクトファイルの後半を受信し、再生する。
【００２４】
いくつかのファイル形式においては、キールフレームがデータストリームに定期的に送られる。再生は、次のキーフレームが受信されるまで可能とならない。コンテンツオブジェクトの不連続部を受信すると、コンテンツ処理プログラム１２４は、再生を開始する前に、次のキーフレームの受信を待ってもよい。当業者にとっては明らかであるが、前述の様態での再生制御は、ＨＴＴＰトランスポートと時間的に連続しないコンテンツファイルの様々な部分の再生を可能にする。
【００２５】
次に図５を参照すると、向上した精度でコンテンツオブジェクトをストリーミングするプロセス５００の別の実施形態のフローチャートが示される。特定のファイル形式において、コード化速度は定期的に変化し得る。したがって、１回の補間では充分な精度を提供できないことがある。再生の新しい部分への切換が遅れるという犠牲を払って、工程５０８の精度テストが本実施形態に追加される。補間が、結果として１秒あるいはその他の何らかの期間内の精度にならない場合、精度が反復達成されるように、別の補間を実行するために、誤った位置のタイムスタンプが用いられる。
【００２６】
たとえば、１分間の歌の半分を過ぎた時点が要求されると、コンテンツファイルのデータ部の中間から始まるバイト範囲が選択される。次のタイムスタンプがデータストリームから検索され、補間された推定値と照合される。本例において、タイムスタンプは、第１の補間から生じたストリーム開始２０秒後の時点を示す。１秒の精度が達成されるまで、要求する第２のバイト範囲、またその次を推定するため、ファイルの残りの４０秒間に対する補間が実施される。本実施形態は、１秒の精度を採用しているが、いかなる期間、割合、その他の増分単位を用いてもよい。
【００２７】
前述の説明を踏まえて、本発明の多くの利点が容易に明らかとなる。たとえば遍在性ＨＴＴＰトランスポートがコンテンツ処理プログラムによって利用され得る。オリジンサーバは、コンテンツをストリーミングするために、現在使用されている専有トランスポートを支援する専有ソフトウェアを必要としない。さらに、ＨＴＴＰトランスポート用の固有の支援を持たない従来のコンテンツ処理プログラムが、スキンとビューアオブジェクトプロキシを用いることで、ＨＴＴＰトランスポートを支援するよう操作され得る。
【００２８】
本発明の多くの変更と改変も使用できる。たとえば、幾つかの実施形態は、オリジンサーバから受信されたコンテンツオブジェクトファイルのいかなる部分もバッファに移せる。すでにダウンロードされた部分の再生を指定する、その後の再生操作では、オリジンサーバからのストリーミング要求をしなくてよい。これを実行するため、すでにダウンロードされた部分がバッファから検索され得る。別の例として、前述実施形態は、バイト範囲を決定するために、特定の補間アルゴリズムを使用するが、別の実施形態は、バイト範囲を決定するために、いかなる既知のアルゴリズムをも使用できる。
【００２９】
本発明の原理を、特定の装置と方法に関連して以上のように説明してきたが、以上の説明は例示のみを目的としてなされたものであり、本発明の範囲に対する制限としてなされたものではないことは明確に理解されるはずである。
【図面の簡単な説明】
【００３０】
【図１】ストリーミングコンテンツの分配システムの１実施形態のブロック図。
【図２】ストリーミングコンテンツの分配システムの別の実施形態のブロック図。
【図３】ユーザが再生操作をしている間に、コンテンツオブジェクトの受渡をストリーミングするプロセスの１実施形態のフローチャート。
【図４】再生操作と共にコンテンツオブジェクトの受渡をストリーミングするプロセスの１実施形態のフローチャート。
【図５】向上させた精度でコンテンツオブジェクトをストリーミングするプロセスの別の実施形態のフローチャート。
【図１】
2005510919.tif 000003
【図２】
2005510919.tif 000004
【図３】
2005510919.tif 000005
【図４】
2005510919.tif 000006
【図５】
2005510919.tif 000007
【国際調査報告】
2005510919.tif 000008
2005510919.tif 000009