(57)【要約】コンテンツ配信を維持するために、余剰ネットワーク容量の期間を優先的に識別し、使用するという技法を使用して、メディアコンテンツのプログレッシブダウンロードを提供するためのシステムおよび方法。受信側システムのバッファは、ネットワークが再生される速度と同じ速度でコンテンツを配信することができない場合、再生間隔をブリッジするために十分なコンテンツにより維持され、事前に充填される。コンテンツ配信は、余剰ネットワーク容量がネットワークに存在する場合にのみ、コンテンツが送信されるため、他のユーザのアプリケーション、ならびにネットワークおよびそのリソースの使用に影響を与えない。余剰ネットワーク容量が全く利用可能ではない場合、コンテンツをリクエストしているユーザには、コンテンツを後で再生することができるように、バックグランドで配信を継続するという選択肢が与えられてもよい。
2013524721.tif 000002
【特許請求の範囲】
【請求項１】
送信側システムから受信側システムへコンテンツを転送するための方法であって、
前記受信側システムのバッファ内に複数のセグメントを備える、リクエストされたコンテンツファイルのセグメントを受信することであって、前記セグメントが余剰ネットワーク容量のみを使用して、ネットワーク上で、前記送信側システムによって送信される、セグメントを受信することと、
前記バッファに対するバッファ充填レートを決定することと、
前記決定されたバッファ充填レートに依存して、前記バッファに対する事前充填閾値を決定することと、
前記バッファが前記決定された事前充填閾値まで充填された後、前記バッファから前記リクエストされたコンテンツファイルのプレイアウトを開始することと、
を含む、方法。
【請求項２】
前記リクエストされたコンテンツファイルのプレイアウトを開始することが、前記リクエストされたコンテンツファイルの前記複数のセグメントの全てを前記バッファ内に受信する前に生じる、請求項１に記載の方法。
【請求項３】
前記リクエストされたコンテンツファイルのプレイアウト中に、前記バッファの充填レベルを監視することと、
前記バッファが消耗しているかまたは消耗に近いことを判定することと、
前記バッファが消耗しているかまたは消耗に近いことを示す第１の警告を前記受信側システムのユーザに提供することと、
前記第１の警告に応答して、前記ユーザから、前記リクエストされたコンテンツファイルの前記複数のセグメントの残りのバックグランド配信をリクエストする命令を受信することと、
余剰ネットワーク容量のみを使用して、バックグラウンド配信モードで、前記送信側システムから、前記リクエストされたコンテンツファイルの前記複数のセグメントの前記残りを受信することと、
をさらに含む、請求項１に記載の方法。
【請求項４】
前記リクエストされたコンテンツファイルの前記複数のセグメントの前記残りが、前記受信側システムによって受信されたことを示す第２の警告を前記ユーザに提供することと、
前記第２の警告に応答して、前記ユーザから、前記リクエストされたコンテンツファイルのプレイアウトをリクエストする命令を受信することと、
前記リクエストされたコンテンツファイルを前記受信側システム上で再生することと、
をさらに含む、請求項３に記載の方法。
【請求項５】
前記リクエストされたコンテンツファイルを前記受信側システム上で再生することは、前記リクエストされたコンテンツファイル全体よりも少ない、前記リクエストされたコンテンツファイルの一部だけを再生することを含む、請求項４に記載の方法。
【請求項６】
前記第１の警告は、前記受信側システム上で稼動しているアプリケーションユーザインターフェースを介して、前記ユーザに提供される、請求項３に記載の方法。
【請求項７】
前記リクエストされたコンテンツファイルのプレイアウト中に前記バッファを監視することと、
前記バッファが消耗しているかまたは消耗に近いことを判定することと、
前記リクエストされたコンテンツファイルのプレイアウトを一時停止することと、
前記受信側システム上に記憶された補助コンテンツファイルのプレイアウトを開始することと、
前記補助コンテンツファイルのプレイアウト中に、余剰ネットワーク容量のみを使用して、前記リクエストされたコンテンツファイルの追加セグメントを受信することと、
前記リクエストされたコンテンツファイルのプレイアウトを再開することと、
をさらに含む、請求項１に記載の方法。
【請求項８】
前記補助コンテンツは、広告コンテンツを含む、請求項７に記載の方法。
【請求項９】
前記補助コンテンツファイルを前記受信側システムの前記バッファの中に受信することをさらに含み、前記補助コンテンツファイルは、余剰ネットワーク容量のみを使用して、前記送信側システムによって送信される、請求項７に記載の方法。
【請求項１０】
前記リクエストされたコンテンツファイルのプレイアウトを再開することは、前記バッファが前記決定された事前充填閾値まで充填された後に生じる、請求項７に記載の方法。
【請求項１１】
前記リクエストされたコンテンツファイルのプレイアウトを再開することは、前記バッファが、前記決定された事前充填閾値まで充填された後で、かつ前記補助コンテンツファイルのプレイアウトが、論理的な小休止の時点に到達した後に生じる、請求項７に記載の方法。
【請求項１２】
前記バッファ充填レートは、前記送信側システムから、前記受信側システムによって受信された前記リクエストされたコンテンツファイルの複数の前記セグメントに対する平均伝送レートを計算することによって決定される、請求項１に記載の方法。
【請求項１３】
前記バッファの前記事前充填閾値は、前記リクエストされたコンテンツファイルのサイズ、前記バッファ充填レート、および前記リクエストされたコンテンツファイルのプレイアウトレートのうちの１つ以上に依存する、請求項１に記載の方法。
【請求項１４】
前記受信側システムは、デジタルビデオレコーダ（ＤＶＲ）、パーソナルコンピュータ、ネットワークストレージ装置、クライアントワークステーション、セットトップボックス、パーソナルデータアシスタント（ＰＤＡ）、携帯用オーディオビデオプレーヤ、および携帯用通信デバイスからなる群から選択される受信側システムを備える、請求項１に記載のシステム。
【請求項１５】
前記送信側システムに対して、前記リクエストされたコンテンツファイルの前記セグメントの前記転送のための処理能力情報に関する、制御およびステータス情報を提供することと、
前記制御およびステータス情報に依存するレートで、前記送信側システムから、前記リクエストされたコンテンツファイルのセグメントを受信することと、
をさらに含む、請求項１に記載の方法。
【請求項１６】
前記リクエストされたコンテンツファイルのプレイアウト中に、前記バッファの前記充填レベルを監視することと、
前記バッファが消耗しているかまたは消耗に近いことを判定することと、
ユーザによって設定された事前設定ポリシールールを解釈することによって、前記ユーザがバックグラウンド配信を事前に選択していたと判定することと、
余剰ネットワーク容量のみを使用して、バックグラウンド配信モードで、前記送信側システムから、前記リクエストされたコンテンツファイルの前記複数のセグメントの残りを受信することと、
をさらに含む、請求項１に記載の方法。
【請求項１７】
送信側システムから受信側システムへコンテンツを転送するための方法であって、
前記受信側システムのバッファ内に複数のセグメントを備えるリクエストされたコンテンツファイルのセグメントを受信することであって、前記セグメントはネットワーク上で前記送信側システムによって送信される、受信することと、
前記受信側システムのユーザに対して、バックグラウンド配信モードを使用して、前記リクエストされたコンテンツファイルのセグメントを受信することを継続する選択肢を提供する第１の警告を提供することと、
前記第１の警告に応答して、前記ユーザから、前記リクエストされたコンテンツファイルの配信に対して前記バックグラウンド配信モードをリクエストする命令を受信することと、
余剰ネットワーク容量のみを使用して、前記バックグランド配信モードで、前記送信側システムから、前記リクエストされたコンテンツファイルの残りを受信することと、
を含む、方法。
【請求項１８】
前記受信側システム上に前記リクエストされたコンテンツファイルを記憶することと、
前記受信側システム上で前記リクエストされたコンテンツファイルのプレイアウトを開始することと、
をさらに含む、請求項１７に記載の方法。
【請求項１９】
前記第１の警告を提供する前に、前記リクエストされたコンテンツファイルのプレイアウトを前記受信側システム上で開始することと、
前記リクエストされたコンテンツファイルの前記プレイアウト中に、前記バッファの充填レベルを監視することと、
前記リクエストされたコンテンツファイルのプレイアウト中に、前記バッファが消耗しているかまたは消耗に近いことを判定することと、をさらに含み、
前記第１の警告を前記ユーザに提供することは、前記バッファが消耗しているかまたは消耗に近いという判定に応答して生じる、請求項１７に記載の方法。
【請求項２０】
前記受信側システムの前記ユーザに対して、前記リクエストされたコンテンツファイルが、前記受信側システム上でローカルに記憶されることを示す第２の警告を提供することと、
前記第２の警告に応答して、前記ユーザから、前記リクエストされたコンテンツファイルのプレイアウトを前記受信側システム上で開始する命令を受信することと、
前記リクエストされたコンテンツファイルのプレイアウトを前記受信側システム上で開始することと、
をさらに含む、請求項１７に記載の方法。
【請求項２１】
前記ユーザから命令を受信することは、前記ユーザによって設定された事前設定ポリシールールを解釈することを含む、請求項１７に記載の方法。
【請求項２２】
受信側システムであって、
バッファと、
前記バッファ内に複数のセグメントを備えるリクエストされたコンテンツファイルのセグメントを受信するための手段であって、前記セグメントは、余剰ネットワーク容量のみを使用して、ネットワーク上で、送信側システムによって送信される、手段と、
前記バッファに対するバッファ充填レートを決定するための手段と、
前記決定されたバッファ充填レートに依存して、前記バッファに対する事前充填閾値を決定するための手段と、
前記バッファが前記決定された事前充填閾値まで充填された後、前記バッファから前記リクエストされたコンテンツファイルのプレイアウトを開始するための手段と、
を備える、受信側システム。
【請求項２３】
前記リクエストされたコンテンツファイルのプレイアウト中に、前記バッファの前記充填レベルを監視するための手段と、
前記バッファが消耗しているかまたは消耗に近いことを判定するための手段と、
前記バッファが消耗しているかまたは消耗に近いことを示す第１の警告を前記受信側システムのユーザに提供するための手段と、
前記第１の警告に応答して、前記ユーザから、前記リクエストされたコンテンツファイルの前記複数のセグメントの残りのバックグランド配信をリクエストする命令を受信するための手段と、
余剰ネットワーク容量のみを使用して、バックグラウンド配信モードで、前記送信側システムから、前記リクエストされたコンテンツファイルの前記複数のセグメントの前記残りを受信するための手段と、
をさらに備える、請求項２２に記載のシステム。
【請求項２４】
前記リクエストされたコンテンツファイルの前記複数のセグメントの前記残りが、前記受信側システムによって受信されたことを示す、第２の警告を、前記ユーザに提供するための手段と、
前記第２の警告に応答して、前記ユーザから、前記リクエストされたコンテンツファイルのプレイアウトをリクエストする命令を受信するための手段と、
前記リクエストされたコンテンツファイルを前記受信側システム上で再生するための手段と、
をさらに備える、請求項２３に記載のシステム。
【請求項２５】
前記リクエストされたコンテンツファイルのプレイアウト中に前記バッファを監視するための手段と、
前記バッファが消耗しているかまたは消耗に近いことを判定するための手段と、
前記リクエストされたコンテンツファイルのプレイアウトを一時停止するための手段と、
前記受信側システム上に記憶された補助コンテンツファイルのプレイアウトを開始するための手段と、
前記補助コンテンツファイルのプレイアウト中に、余剰ネットワーク容量のみを使用して、前記リクエストされたコンテンツファイルの追加セグメントを受信するための手段と、
前記リクエストされたコンテンツファイルのプレイアウトを再開するための手段と、
をさらに備える、請求項２２に記載のシステム。
【請求項２６】
前記バッファ充填レートを決定するための前記手段は、前記送信側システムから、前記受信側システムによって受信された前記リクエストされたコンテンツファイルの複数の前記セグメントに対する平均伝送レートを計算するように動作可能である、請求項２２に記載のシステム。
【請求項２７】
前記バッファの前記事前充填閾値は、前記リクエストされたコンテンツファイルのサイズ、前記バッファ充填レート、および前記リクエストされたコンテンツファイルのプレイアウトレートのうちの１つ以上に依存する、請求項２２に記載のシステム。
【請求項２８】
前記受信側システムは、デジタルビデオレコーダ（ＤＶＲ）、パーソナルコンピュータ、ネットワークストレージ装置、クライアントワークステーション、セットトップボックス、パーソナルデータアシスタント（ＰＤＡ）、携帯用オーディオビデオプレーヤ、および携帯用通信デバイスからなる群から選択される受信側システムを備える、請求項２２に記載のシステム。
【請求項２９】
前記リクエストされたコンテンツファイルのプレイアウト中に、前記バッファの前記充填レベルを監視するための手段と、
前記バッファが消耗しているかまたは消耗に近いことを判定するための手段と、
ユーザによって設定された事前設定ポリシールールを解釈することによって、前記ユーザがバックグラウンド配信を事前に選択していたことを判定するための手段と、
余剰ネットワーク容量のみを使用して、バックグラウンド配信モードで、前記送信側システムから、前記リクエストされたコンテンツファイルの前記複数のセグメントの前記残りを受信するための手段と、
をさらに備える、請求項２２に記載のシステム。
【請求項３０】
受信側システムであって、
バッファと、
前記受信側システムのバッファ内に複数のセグメントを備えるリクエストされたコンテンツファイルのセグメントを受信するための手段であって、前記セグメントは、余剰ネットワーク容量のみを使用してネットワーク上で、前記送信側システムによって送信される、手段と、
前記受信側システムのユーザに対して、バックグラウンド配信モードを使用して、前記リクエストされたコンテンツファイルのセグメントを受信することを継続する選択肢を提供する、第１の警告を提供するための手段と、
前記第１の警告に応答して、前記ユーザから、前記リクエストされたコンテンツファイルの配信に対して前記バックグラウンド配信モードをリクエストする命令を受信するための手段と、
余剰ネットワーク容量のみを使用して、前記送信側システムから、前記バックグランド配信モードで、前記リクエストされたコンテンツファイルの残りを受信するための手段と、
を備える、受信側システム。
【発明の詳細な説明】
【技術分野】
【０００１】
（発明の背景）
本発明は、概して、ネットワーク上からコンテンツのプログレッシブダウンロードを提供するためのシステムおよび方法に関し、より具体的には、ネットワークの利用可能な余剰容量を使用する、コンテンツのプログレッシブダウンロードに関する。
【背景技術】
【０００２】
ネットワークに接続中のオンラインコンテンツのストリーミングは、リクエスト者による消費のために、ネットワークサーバからリクエストされたメディアコンテンツを配信する一般的な方法である。オンラインコンテンツのストリーミングに伴う日常的な問題は、サーバおよび受信者を接続しているネットワークが、コンテンツを配信するというその能力において、一時的変動を有する場合があり、その結果、再生（または「プレイアウト」）セッションにおける中断をもたらすことがある。この問題を軽減するために、配信レートを低減するためのコンテンツ圧縮、配信レート／再生品質を低減してネットワーク能力に一致させるための動的リアルタイムエンコーディング、および再生が開始することを可能にする前にコンテンツの短いセグメントを事前にバッファし、その後、再生セッションの終了までコンテンツが再生できるよりも速くバッファを充填する等、多様な方法が提案されてきた。この最後のストリーミング方法は、プログレッシブダウンロード（すなわち「ＰＤ」）として知られるようになっており、本技法は、サーバがネットワーク上で受信者に対して配信レートを維持することができない場合、短い間隔で連続的な再生を維持することを可能にするために、安全なマージンを構築することを目的とする。
【０００３】
中断を低減および回避することを計画する一方、プログレッシブダウンロードは、コンテンツを受信するシステム上でバッファが空になるのに十分長く持続するネットワーク障害に影響されないわけではない。そのような場合、再生セッションは、バッファを再び充填することができ、セッションを再開するまで、一時停止することを余儀なくされる。したがって、既存のプログレッシブダウンロード技法はしばしば、ネットワークの能力に依存して、連続的な再生セッションを提供することができないということが一般的に経験される。
【０００４】
別の増大している問題は、大型のコンテンツファイルのストリーミングが、有線、ファイバ、および無線式を含む、アクセスネットワークに与える影響である。「大型」のメディアコンテンツは、エンドユーザデバイスへまたはエンドユーザデバイスからその配信中、相当な時間および相当量のネットワークリソースを消費するという特徴的な特性を有する。一般に、消費者アクセスネットワークは、短い瞬間的なデータおよびネットワークリソース使用の配信のために設計され、メディアコンテンツのストリーミングのような長期連続的使用を目的としない。メディアコンテンツのストリーミングは、限定されたネットワークリソースを用いて多数のユーザのピーク使用要求を満足させようと試みる、アクセスネットワークのトラフィックエンジニアにとって本質的課題であると広く認識されている。ストリーミングが広く採用されたことによる典型的な結果は、全てのユーザおよびユーザのアプリケーションに対する遅いネットワーク反応によってしばしば示される、ネットワークの混雑である。
【発明の概要】
【課題を解決するための手段】
【０００５】
本明細書に記載される実施形態は概して、コンテンツ配信を維持するために、余剰ネットワーク容量の期間を優先的に識別し、使用するという技法を使用して、メディアコンテンツのプログレッシブダウンロードを提供するためのシステムおよび方法に関する。本明細書に使用される場合、余剰ネットワーク容量という用語は、アクセスプロバイダによって、ネットワークの全容量およびネットワークの使用量の観点から、ネットワークにおいて利用可能であると判定されるネットワーク容量と定義される。理解できるように、あるネットワークに対する余剰ネットワーク容量は、経時的（例えば、ピークの使用期間中）およびサービスプロバイダごとによって相当に変動する場合がある。例えば、アクセスプロバイダは、全容量の８０％等、ネットワークの全容量の事前に決定された割合に閾値を設定する場合がある。ネットワーク使用量が全容量の８０％未満に低下した任意の時点で、余剰分は、現在の使用量が８０％の閾値を超えないように、本明細書に記載される配信システムによって使用されてもよい。別のアクセスプロバイダは、同じ全容量を有するが、閾値を全容量の９０％に設定することができる。この例では、ネットワーク使用量が全容量の９０％未満になった任意の時点で、余剰分は、現在の使用量が９０％閾値を超えない限り、本明細書に記載される配信システムによって使用することができる。事前に決定される割合は、５０％、９０％、９８％等、任意の適切な割合にすることができる。余剰ネットワーク容量は、全ネットワーク容量の割合として、絶対規模として、または任意の他の適設な測定基準として、表すことができる。さらに、ネットワークの余剰ネットワーク容量は、上記に提供された例のように、ネットワークの空き帯域幅を言及する場合があるが、本用語はそのように限定されない。いくつかの事例では、本明細書に記載の方法を使用してコンテンツをダウンロードするために使用することができる余剰ネットワーク容量は、優先度、時刻、履歴データ等の他の基準を使用して決定されてもよい。
【０００６】
既存のプログレッシブダウンロード方法に類似して、いくつかの実施形態では、受信側バッファは、ネットワークがプレイアウトと同じ速度でコンテンツを配信することが不可能である場合、再生間隔をブリッジするために十分なコンテンツを用いて維持され、事前に充填される。しかしながら、異なる点は、実際のコンテンツ配信が他のユーザのアプリケーション、ならびにネットワークおよびそのリソースの使用に影響を与えない点である。これは、余剰ネットワーク容量がネットワーク内に存在する場合にのみコンテンツをストリーミングすることによって、実現される。受信側バッファを事前に充填することは、余剰ネットワーク容量だけが利用されるため、比較的より長い時間がかかる場合があるが、本方法は、最初の段階で（すなわち、ネットワークが完全に混雑してはいない状態）少なくともいくつかの余剰ネットワーク容量が、バッファを事前に充填するために利用可能であるため、ネットワークに対する負担がより少なく、再生がいったん開始すると再生を中断しないという目標を達成する可能性がより大きい。
【０００７】
ピーク使用期間が長引く間、そのような余剰ネットワーク容量は全く利用可能ではない場合がある。そのような場合、コンテンツをリクエストしているユーザは、コンテンツを後の時点で再生してもよいように、バックグランドで配信を継続するという選択肢が与えられてもよい。バックグランド配信が選択された場合、ユーザは、ネットワークの余剰容量が利用可能になるとそれを使用して、コンテンツが完全に配信された後、再生体験を再開することができる。
【図面の簡単な説明】
【０００８】
【図１】メディアコンテンツ配信システムの実装を一般に表す模式図である。
【図２】図１に示されるメディアコンテンツ配信システムの詳細を示す模式図である。
【図３Ａ】メディアコンテンツを配信するための例示的なプロセスの流れを示す流れ図である。
【図３Ｂ】メディアコンテンツを配信するための例示的なプロセスの流れを示す流れ図である。
【図４】メディアコンテンツを配信するための例示的なプロセスの流れを示す別の流れ図である。
【発明を実施するための形態】
【０００９】
本明細書に記載の実施形態は、一般的に、クライアント／サーバアーキテクチャ上で稼動するシステムおよび方法を含む。いくつかの実施形態では、クライアントソフトウェアは、ＰＣ、ラップトップ、ネットブック、移動用インターネットデバイス、携帯電話、または他の装置等、固定または携帯用装置上で稼動する。
【００１０】
いくつかの実施形態では、以下の一般的順次のステップが実施される。ユーザが操作する受信側システムは、ストリーミング配信のためのコンテンツファイルを選択し、受信側システムへのコンテンツファイルのストリーミングが開始する。コンテンツは、ネットワークに接続された送信側システムと受信側システムとの間で、そうでなければアイドルなネットワーク容量を優先的に識別する方法を使用して配信される。受信側システムは、受信されるコンテンツが、バッファの計算された充填レートに基づいて、計算された閾値レベルまでバッファを事前に充填することを可能にする。閾値レベルに到達すると、再生が開始する。コンテンツが到着するにつれて、受信側システムに搭載されたストレージ上にもキャッシュすることができる。再生がいったん開始すると、受信側システムはバッファの充填レベルを監視してもよく、バッファの消耗が発生する、または発生しそうになると、ユーザに警告し、モードをバックグランド配信へ切り替える選択肢を与えることができる。そうでなければ、再生は、ユーザが再生を一時停止する、またはコンテンツの再生が最後に到達するまで継続する。理解できるように、ユーザが保留中のバッファ消耗の警告を無視することを選択した場合、バッファが再び充填するのにともない、プレイアウトの中断が発生する可能性が高い。
【００１１】
１つの事例では、受信側システムのユーザは、ウェブブラウザアプリケーションを介して、コンテンツ配信サーバをホストするサイトへオンライン接続する。ユーザは、ストリーミング配信のためのメディアコンテンツタイトル（例えば、ビデオ、オーディオ、または他のメディアファイル）を選択してもよく、短い間隔後、メディアコンテンツは、プレーヤアプリケーションを介して受信側システム上で再生を開始する。コンテンツが受信側システム上でプレイアウトされている間、ネットワークは、再生に対応するために必要な配信レートを維持することができなくなる場合がある。短時間後、第１のユーザ警告は、ユーザに対して、再生が継続できないことを示してもよい。ユーザには、次いで、再生を切断して、配信をバックグランドで継続するように選択肢が与えられてもよい。ユーザは、次いで、この選択肢を受容し、再生アプリケーションが終了する。後の時点で、コンテンツが受信側システム上に完全にダウンロードされたことをユーザに伝達するために、第２のユーザ警告を提供してもよい。ユーザは、次いで、プレーヤアプリケーションを再起動し、中断点から、またはコンテンツの最初から、コンテンツを見ることまたは聴くことを継続することができる。コンテンツは次いで受信側システム上でローカルに記憶されるため、ネットワークはもはや再生に影響を与えなくなり、セッションは、コンテンツの最後まで中断されずに進行してもよい。ストリーミングおよびバックグランドダウンロードの両方の間、他のユーザのアプリケーションのサービス品質に影響を与えてまで、ネットワークの体験品質を確保することを回避するために、ネットワーク余剰容量が使用される。
【００１２】
別の事例では、ユーザは、受信側システムを使用してサーバに接続し、ストリーミングメディア配信用のコンテンツタイトルを選択してもよい。遅延後、コンテンツは、受信側システム上で再生を開始することができる。再生セッション中、ネットワークは時に障害状態となり、配信レートが短期間低減する場合がある。ユーザのプログレッシブダウンロードアプリケーションは、再生を開始する前に十分なコンテンツをバッファしていたため、再生セッションは中断なく継続する。コンテンツの配信は、他のユーザのアプリケーションに影響を与えてまで、ネットワークの体験品質を確保することを回避するために、ネットワーク余剰容量を使用して優先的に達成される。このプロセスは、ユーザに透過的であり、ストリーミング体験は、ピーク使用期間中にそうでなければネットワークを混雑させるであろうストリーミング方法と同一である。
【００１３】
ネットワーク混雑を回避する様式でファイルを配信するための多様な技法は、米国特許第７，５００，０１０号に開示され、その全体は参照により本明細書に組み込まれる。その参考文献に詳細が記載されるように、ファイルは、送信側システムから受信側システムへ伝送するために、セグメントに細分化することができる。ファイルセグメントを送信側システムから受信側システムへ送信した後、送信側システムから受信側システムまでネットワーク上で利用可能な最大転送レートを決定すること、ならびに任意の特定のセグメントに対する実際の転送時間を決定することが可能である。転送レートおよびファイルセグメントのサイズはどちらも、利用可能な帯域幅に基づいて動的に調整することが可能である。ネットワークが混雑した場合、米国特許第７，５００，０１０号に記載のシステムは、望ましくないネットワーク混雑を回避するために、転送レートおよび／またはファイルセグメントのサイズを自動的に低減することが可能である。より広いネットワーク帯域幅が利用可能になると、米国特許第７，５００，０１０号に記載のシステムは、それにしたがって自動的に、転送レートを増加し、かつ／またはファイルセグメントのサイズをそれに対応して調整することが可能である。このように、上記で参照した特許に記載のシステムは、ネットワークの混雑を検出し、ネットワークの混雑を回避するために、転送レートおよび／またはファイルセグメントのサイズを動的に調整する。
【００１４】
コンテンツ配信システム１００は、図１において、どちらもネットワーク１０６に通信可能に連結された、送信側システム１０２および受信側システム１０４を含むように示される。送信側システム１０２は、ファイバ、有線、無線手段を介してネットワーク１０６に接続された、サーバ、データベース、ストレージ装置、ルータ、スイッチ、ファイアウォール、または他のそのようなデバイス等のコンピュータシステムまたは複数の配列または分散コンピュータシステムからなっていてもよい。明確を期すために、多様な構成要素は、図１において送信側システム１０２として示される。
【００１５】
受信側システム１０４は、ＤＶＲ、ＰＣ、ネットワークストレージ装置、クライアントワークステーション、テレビのセットトップボックス、モデム、ゲートウェイ、またはパーソナルデータアシスタント（ＰＤＡ）、携帯用オーディオビデオプレーヤ、携帯電話等のセル方式通信デバイス等の他のそのようなデバイスを備えて、あるいは専用ハードウェア装置内に配列することができる。受信側システム１０４は、ファイバ、有線、または無線手段を介して、ネットワーク１０６に接続してもよい。ネットワーク１０６は、有線（ＤＳＬ、ケーブル、電線）、ファイバ、無線、衛星、およびセル方式タイプのネットワークを含むがこれらに限定されない、インターネットまたはＷＡＮ等の他のネットワークからの１つ以上のネットワーク構成要素を含んでもよい。ネットワーク１０６は、モデム、ルータ、ブリッジ、ゲートウェイ、ネットワークインターフェース、ケーブル伝送、無線伝送、ローカルエリアネットワーク（ＬＡＮ）、アクセスネットワーク、プロバイダネットワーク、およびピアツーピア配置を含むがこれらに限定されない、他の従来のネットワーク構成要素を含んでもよい。送信側システム１０２は、ネットワーク１０６上で受信側システム１０４へメディアファイル１１６を送信するために構成されてもよい。
【００１６】
送信側システム１０２は、ネットワーク１０６にアクセスするためのインターフェース１１０と、プロセッサ１１２と、ネットワーク上で受信側システム１０４へ伝送されるメディアファイル１１６を含み、かつコンテンツ配信方法を実施するための命令を伴う１つ以上のモジュールを含む、ストレージ１１４とを含む。受信側システム１０４は、ネットワーク１０６にアクセスするためのインターフェース１１８と、プロセッサ１２０と、送信側システム１０２から受信されたメディアファイル１１６のコピーを記憶し、コンテンツ配信方法に関する命令を実施するための１つ以上のモジュールを記憶するためのストレージ１２２とを含む。受信側システム１０４は、エンドユーザの場所に位置しても、または何らかの中間ネットワーク場所に位置してもよいことが理解される。例えば、受信側システム１０４は、複数のエンドユーザに地理的により近似した、コンテンツを配信するためのキャッシュモジュールとして機能するように動作する中間サーバを備える場合がある。
【００１７】
図２はさらに、いくつかの実施形態において提供される、システム１００の要素の機能分解を例示する。示されるように、メディアファイル１１６は、ネットワーク１０６を通じて受信側システム１０４に通信可能に連結される、送信側システム１０２のストリーミングサーバ１４１に対して有効である。受信側システム１０４は、いくつかの実施形態において、ＰＣ、ラップトップ、ネットブック、モバイルインターネットデバイス、携帯電話、メディアリーダ、メディアプレーヤ、または他のシステムを含むことができる、コンピューティングプラットフォームを含む。図２は、機能要素の１つの群化を示すが、共通または個別の物理的装置に連結された要素の他の組み合わせも可能であることが理解される。
【００１８】
動作中、受信メディアファイルストリームは、ネットワーク１０６を共有する他の無関係なトラフィックに悪影響を与えないという目標をもって余剰ネットワーク容量を優先的に使用する方法を使用して、ネットワーク１０６上でストリーミングサーバ１４１と転送を連携する、受信側システム１０４のストリーミングクライアント１４３ソフトウェアモジュールによって処理される。いくつかの実施形態において、メディアファイル１１６の転送は、「Ａｄａｐｔｉｖｅ  Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ」という名称の米国特許第７，５００，０１０号に詳細が記載される方法を使用して達成される。
【００１９】
図２に示される受信側システム１０４は、本明細書に記載の実施形態に関する記憶されたソフトウェア命令を実行するためのプロセッサ１４４およびメモリ１４５も含む。ストリーミングクライアント１４３ソフトウェアモジュールは、送信側システム１０２のストリーミングサーバ１４１から入信メディアファイル１１６を受信する。ストリーミングクライアント１４３は、受信されたコンテンツを一時バッファストレージ１４６へ、いくつかの実施形態においては、大容量記憶装置１４９へ転送する。メディア再生エンジン１４７は、バッファ１４６からコンテンツを取得し、受信側システム１０４内に統合されてもよい、またはいくつかの実施形態では分離されてもよい、メディアプレゼンテーションデバイス１４８のためにそれを処理する。例えば、いくつかの実施形態において、メディアプレゼンテーションデバイス１４８は、別個のビデオ表示画面およびオーディオスピーカを含んでもよい。
【００２０】
いくつかの実施形態において、メディア再生エンジン１４７は、バッファが、計算された事前充填閾値に到達すると、バッファ１４６からコンテンツを取得する。事前充填閾値は、再生がいったん開始した後、連続的な再生を維持するために計算されてもよい。事前充填閾値は、バッファ充填レート、コンテンツサイズ、再生レート等に基づいて計算されてもよい。
【００２１】
理解できるように、所定の事例では、バッファ１４６は、ネットワーク１０６の長時間の混雑期間中等、消耗する場合がある。これらの状況において、ユーザは、余剰ネットワーク容量を使用して、バックグラウンドで、受信側システム１０４のローカルストレージ１４９内へメディアファイル１１６の転送を継続するように選択してもよい。メディアファイル１１６がローカルストレージ１４９へ完全に転送されると、メディア再生エンジン１４７は、（ローカルストレージ１４９とメディア再生エンジン１４７との間の破線によって表されるように）メディアファイル１１６を再生するために使用されてもよい。
【００２２】
図３Ａ〜図３Ｂは、本開示の実施形態に従い、図２に示されるシステム１００によって実装されてもよい、例示的プロセス１５０を示す。プロセス１５０は、ステップ１５１で、ユーザが、ユーザの受信側システム上で稼動するアプリケーションを通じて、メディアコンテンツファイル（例えば、画像、ビデオ、オーディオ等）をリクエストすると、開始する。いくつかの実施形態において、これは、ウェブブラウザアプリケーションを使用して、特定のメディアコンテンツファイルのタイトルを閲覧し、選択することによって、実施される。ファイルストリーミングは、送信側システム１０２のストリーミングサーバ１４１が、コンテンツ（例えば、メディアファイル１１６）を受信側システム１０４にストリーミングし始めると、開始する。ネットワーク１０６の余剰帯域幅が利用可能になるとそれを優先的に利用する、転送プロセスが使用されてもよい。
【００２３】
ストリーミングクライアント１４３は、ストリーミングサーバ１４１が受信側システム１０４へのデータフローの速さを制御するために使用する、制御およびステータス情報をストリーミングサーバ１４１に提供する。「Ａｄａｐｔｉｖｅ  Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ」という名称の米国特許第７，５００，０１０号に記載される１つの事例では、ストリーミングサーバ１４１は、送信側システム１０２から受信側システム１０４へのデータフローの最大平均処理能力レート、Ｒｍａｘを判定し、次いで、これは、例えば、転送されているコンテンツファイルの以降の部分に対して、ストリーミングクライアント１４３からのリクエストのレートを速度調整することによって、受信側システム１０４または送信側システム１０２のいずれかによって強制される。Ｒｍａｘは、ストリーミングサーバ１４１によって、送信側システム１０２と受信側システム１０４との間の非混雑リンク容量を、受信側システムのストリーミングクライアント１４３によって報告された処理能力と比較することによって、決定することができる。
【００２４】
ストリーミングクライアント１４３は次いで、ステップ１５２で実際のファイルコンテンツがストリーミングクライアントに転送される前に、ストリーミングサーバ１４１から、ファイルヘッダまたは他のメタデータを受信してもよい。ヘッダファイルは、余剰ネットワーク容量のみを使用して、ネットワーク１０６上で転送されてもよい。このヘッダまたはメタデータは、プログレッシブダウンロードセッションを処理するために使用されるストリーミングクライアント143に対して、情報の信号を送るために使用されるファイル詳細を含んでもよい。いくつかの実施形態では、メタデータは、ファイルサイズ、コンテンツサイズ、およびメディアプレイアウト実行時間を含む。プレイアウトレートは、次いで、ステップ１５３で、例えば、コンテンツサイズとプレイアウト実行時間との比率を計算することによって、決定されてもよい。
【００２５】
余剰ネットワーク容量を使用して送信側システム１０２から受信されたメディアコンテンツは、次いで、ステップ１５４で、受信側システム１０４のバッファ１４６内に入れられる。ステップ１５５で、別のプロセスがバッファの充填レートを監視する。いくつかの事例において、充填レートは、一定ではない場合があり、充填レートの信頼性が高い推定値を取得するために、平均化することができる。いくつかの実施形態において、この平均化は、ストリーミングサーバ１４１とストリーミングクライアント１４３との間のコンテンツファイルセグメントの転送のリクエスト／受信反復の所定の数（例えば、５、１０、２５等）にわたって行われてもよい。他の実施形態において、平均化は、所与の時間間隔の間に到着したコンテンツファイルのバイト数の合計数をサンプリングすることによって達成されてもよい。
【００２６】
決定１５６で、バッファ充填レートの信頼性が高い推定値が取得されると、ステップ１５７で、バッファ事前充填閾値が決定される。そうでなければ、プロセス１５０は、継続してバッファ内にコンテンツを受信する。理解できるように、別個のプロセス（図示せず）は、後の時点においてローカルでプレイアウトする可能性のために、バッファに到着する任意のコンテンツをローカルストレージ（例えば、ローカルストレージ１４９）内にコピーしてもよい。
【００２７】
いくつかの実施形態において、バッファ事前充填閾値は、バッファ充填レート（ステップ１５５で決定される）をプレイアウトレート（ステップ１５３で決定される）と比較することによって、決定されてもよい。一実施形態において、バッファ事前充填閾値は、以下の式によって与えられる。
ｂｕｆｆｅｒＦｉｌｌ＝ＭＡＸ｛ｃｏｎｔｅｎｔＳｉｚｅ＊［１-ｆｉｌｌＲａｔｅ／ｐｌａｙｏｕｔＲａｔｅ］，０｝＋ｐａｄ
【００２８】
この推定値は、例えば、充填レートがネットワーク状態に従って変動するにつれて、コンテンツ転送中、経時的に変動する場合があることが理解される。したがって、バッファ充填レベルは、安全係数（すなわち、「ｐａｄ」）によって過大評価される場合があり、それによって、中断のない再生セッションを完了する可能性を向上させる。現在のネットワーク接続時点の過去の転送性能、時刻、および転送を完了するネットワーク能力の他の表示を含む追加の因子もバッファ充填レベル推定値に組み入れることができる。
【００２９】
ステップ１５８で、バッファ事前充填閾値に到達すると、ステップ１６１で、コンテンツのプレイアウトを開始することが可能になる。例えば、プレイアウトは、バッファ１４６からコンテンツを引き出すプレーヤアプリケーションまたはメディア再生エンジンを使用して実施することができる。そうでなく、バッファ事前充填閾値に到達しない場合、判定１５９で、ユーザにはコンテンツのバックグランド配信を選択する選択肢が与えられてもよい。選択肢は、アプリケーションユーザインターフェースを介して、または別の適切な様式で、ユーザに示されてもよい。ユーザが、ストリーミングクライアント１４３に対して、バックグランド配信モードが選択されるべきであると信号を送った場合、ステップ１６０でバックグランド配信フラグが設定され、ステップ１６４で受信側システム上のコンテンツの受信がストリーミング再生を行わずに進行する。そうでなければ、バッファは、事前充填閾値に到達するまで、充填を継続する（ステップ１５４）。
【００３０】
バッファ事前充填閾値に到達すると、ステップ１６１で、ストリーミングクライアントはバッファからのプレイアウトを開始する。次いで、ステップ１６２で、プレイアウトの完了時間が算出される。コンテンツファイルが、図３Ｂに示される判定１６３で完全に受信され、ユーザがステップ１７６でバックグランド配信を選択しなかった場合、プロセス１５０は終了する。ユーザがステップ１７６でバックグランド配信を選択した場合、ステップ１７７で、ファイル全体がローカルに記憶されたことを示す第１の警告をユーザに提供されてもよい。次いで、ユーザは、ステップ１７８でコンテンツファイルのプレイアウトを開始または再開してもよい。ユーザは、コンテンツファイルの最初、プレイアウトがバッファ消耗に起因して停止した点、またはコンテンツファイルの任意のユーザが選択した点を含む、任意の点から、コンテンツファイルのプレイアウトを再開してもよい。理解できるように、プレイアウトは、コンテンツファイルの最後まで、またはユーザがプレーヤアプリケーションを終了するまで、継続してもよい。コンテンツファイルが完全に受信されなかった場合、判定１６３の結果は「いいえ」であり、受信側システム１０４は、ステップ１６４のコンテンツファイルを用いてバッファ１４６を充填することを継続する。別個のプロセス（図示せず）は、後の時点においてローカルでプレイアウトする可能性のために、バッファに到着する任意のコンテンツをローカルストレージ（例えば、ローカルストレージ１４９）内にコピーしてもよい。
【００３１】
ユーザが、判定１６５でバックグランド配信を選択した場合、プロセス１５０はループし、バッファの充填およびその内容をローカルストレージに入れることを継続する。そうでなければ、ステップ１６６で、バッファ充填レートが監視され、計算される。バッファ充填レートは、ステップ１５５に関して上述したように監視され、計算されてもよい。充填レートの信頼性の高い推定値がまだ取得されない場合、判定１６７の結果は「いいえ」であり、プロセス１５０は、ループして戻り、ステップ１６３でコンテンツファイルの以降のセグメントを受信するように継続する。そうでなければ、充填レートの良好な推定値が取得されると、プロセス１５０は、ステップ１６９で、配信完了予測モジュールに継続する。いくつかの実施形態では、予測された配信完了時間は、充填レートを残りの受信されていないコンテンツファイル部分で除算することによって取得されてもよい。
【００３２】
次いで、ステップ１７０で、バッファ充填閾値が計算されてもよく、現在のバッファレベルが実質的に現在のバッファ充填閾値未満である場合、バッファ消耗または近い将来の消耗の判定を、ステップ１７１および判定１７２で検出する場合がある。バッファが空であるまたは空に近い場合、ユーザは警告を受ける場合があり（例えば、アプリケーションユーザインターフェースを介して）、ステップ１７４でバックグランド配信モードを選択する選択肢が与えられる場合がある。ユーザがバックグランド配信を選択した場合、ステップ１７５でバックグラウンド配信フラグが設定され、ストリーミング再生が終了し、コンテンツファイルの残りは、ステップ１６３、１６４、および１６５を通じてループすることによって、ローカルストレージ内に転送される。そうでなければ、プロセス１５０は、コンテンツファイルが完全に受信され、再生されるまで、またはユーザがセッションを終了するまで継続する。
【００３３】
ユーザが保留中のバッファの消耗の警告を無視することを選んだ場合、バッファが再び充填される間、プレイアウトの中断が発生する可能性が高いことが理解される。コンテンツファイルをバックグラウンド配信を用いて継続して受信する選択肢を提供する１つの利点は、コンテンツを受信することなく、ユーザにセッションを終了することを単に要求することに反して、ローカルストレージから後で再生するための保証をユーザに提供することである。加えて、いくつかの事例では、コンテンツ配信は、例えば、事前に設定されるポリシールールがユーザによって受信側システム上で事前に選択されていた場合、保留中のバッファの消耗時にバックグランド配信に自動的に切り替えてもよい。例として、この機能は、小さい子供が受信側システムを使用している場合、またはそうでなければ、再生中にユーザ相互作用を求める／得ることが不便である場合に利点となる場合がある。
【００３４】
図４は、図１および図２に示されるシステム１００によって実装されてもよい、プロセス２００を示す。一般に、プレイアウトバッファ１４６が消耗した場合、再バッファ期間中、補助コンテンツ（例えば、広告または他のコンテンツ）を再生することができる。補助コンテンツは、リクエストされたコンテンツがリクエストされた後、またはその前の時点で、受信側システム１０４にダウンロードされてもよい。再バッファ期間中に補助コンテンツを提供することによって、ユーザに「再バッファ」ステータスメッセージを単に提供するのではなく、再バッファが発生している間の時間間隔が利用される。
【００３５】
いくつかの実施形態において、ステップ２０４で、受信側システムのユーザは、送信側システムからコンテンツファイルをリクエストする。リクエストされたコンテンツを送信する前に、ステップ２０６で、バッファが消耗するようになった時の再バッファ中、以降の間隔中に再生するために後で使用されてもよい、補助コンテンツが送信される。代替として、補助コンテンツは、以前の配信トランザクション中に送信されていて、既に再生デバイス上に常駐している場合がある。次に、ステップ２０８で、バッファは、余剰ネットワーク容量を使用して、計算された事前充填閾値まで、リクエストされたコンテンツを用いて事前に充填されていてもよい。この事前充填間隔中、リクエストされたコンテンツの再生はまだ開始していない。補助コンテンツが受信された後で、かつバッファが計算された充填レベルに到達した後、ステップ２１０で、リクエストされたコンテンツの再生を開始してもよい。再生中、ネットワーク混雑によって、バッファの消耗が発生した場合、ステップ２１２で、バッファを再び充填する一方で再生は一時中断される。ユーザには、再バッファが発生していることの表示が示されてもよい。再バッファ間隔中、ステップ２１４で、以前に記憶された補助コンテンツが再生されて、時間間隔を埋める。バッファが再びその計算された充填閾値に到達すると、ステップ２１６で、リクエストされたコンテンツの再生が再開される。理解できるように、バッファがその計算された充填閾値に到達すると、リクエストされたコンテンツの再生を直ちに開始してもよい。代替として、リクエストされたコンテンツの再生は、補助コンテンツが論理的な小休止の時点まで再生された後、開始してもよい。例として、補助コンテンツがビデオ広告を含む場合、論理的な小休止の時点は、特定の広告の最後であってもよい。
【００３６】
前述の記載の実施形態は、異なる他の構成要素内部に含まれた、または異なる他の構成要素と接続された異なる構成要素を表す。そのような表されたアーキテクチャは例示に過ぎず、事実、同じ機能性を達成する、多数の他のアーキテクチャを実装することができることを理解されたい。概念的には、同じ機能を達成するための構成要素の任意配設は、所望の機能性が達成されるように、効果的に「関連付けられる」。したがって、特定の機能性を達成するために組み合わされた本明細書の任意の２つの構成要素は、アーキテクチャまたは中間構成要素とは無関係に、所望の機能性が達成されるように相互に「関連付けられる」と考えることができる。同様に、そのように関連付けられた任意の２つの構成要素は、所望の機能性を達成するために相互に「動作可能に接続」、または「動作可能に連結」すると考えることもできる。
【００３７】
本発明の特定の実施形態が示され、記載されるが、当業者には、本明細書の教示に基づいて、本発明およびそのより広義の態様から逸脱することなく変更および変形を行うことができること、したがって、添付の特許請求の範囲は、そのような変更および変形全てが本発明の真の精神および範囲の中にあるとして、それらの範囲内に包含することが明らかであろう。さらに、本発明は添付の特許請求の範囲のみによって定義されることが理解されるべきである。一般的に、本明細書、および特に添付の特許請求の範囲（すなわち、添付の特許請求の範囲の本文）に使用される用語は、一般的に、「開放型」用語（すなわち、「含んでいる」という用語は、「含んでいるがそれに限定されない」として解釈されるべきであり、「有する」という用語は、「少なくとも有する」として解釈されるべきであり、「含む」という用語は、「含むがそれに限定されない」として解釈されるべきである等）を意図することが当業者によって理解されるであろう。導入された特許請求の範囲の記述の特定の数が意図される場合、そのような意図は特許請求の範囲内で明示的に記述され、そのような記述が欠落する場合、そのような意図が全く存在しないことが当業者によってさらに理解されるであろう。例えば、理解の支援として、以下の添付の特許請求の範囲は、特許請求の範囲の記述を導入するために、「少なくとも１つの」および「１つ以上の」という導入語句の使用を含む場合がある。しかしながら、そのような語句の使用は、同じ特許請求の範囲が「１つ以上の」または「少なくとも１つの」という導入語句、および「１つの」（「ａ」または「ａｎ」）等の不定冠詞を含む場合であっても（例えば、「１つの」（「ａ」および／または「ａｎ」）は、一般的に「少なくとも１つの」または「１つ以上の」を意味すると解釈されるべきである）、「１つの」（「ａ」または「ａｎ」）という不定冠詞による特許請求の範囲の記述の導入は、そのように導入された特許請求の範囲の記述を含むいずれかの特定の特許請求の範囲が、１つだけのそのような記述を含む発明に限定することを暗示すると、解釈されてはならず、同じことは、特許請求の範囲の記述を導入するために使用される定冠詞の使用にも言える。加えて、導入された特許請求の範囲の記述の特定の数が明示的に記載される場合であっても、当業者は、そのような記載は一般的に、少なくとも記述された数を意味すると解釈されるべきである（すなわち、他の修飾語を用いない「２つの記述」のそのままの記述は、一般的に、少なくとも２つの記述、または２つ以上の記述を意味する）。
【００３８】
したがって、本発明は、添付の特許請求の範囲によることを除いて、限定されない。
【図１】
2013524721.tif 000003
【図２】
2013524721.tif 000004
【図３Ａ】
2013524721.tif 000005
【図３Ｂ】
2013524721.tif 000006
【図４】
2013524721.tif 000007
【国際調査報告】
2013524721.tif 000008
2013524721.tif 000009