(57)【要約】  予測ストリーミング用の技術は、ストリーミングアプリケーションに関連したブロック用のリクエストを受信し、そしてブロックに関連したデータを供給することを必要としている。ブロックリクエストデータベースは、以前のブロックリクエストデータに基づいて次にリクエストされるのに適当なブロックを予測するためにチェックされる。予測ブロックは、リクエストブロックに関連したデータを供給するときに識別される。技術によって発展したシステムは、ストリーミングサーバ、ブロックリクエストデータベース、予測エンジンを含んでいる。そしてこれらは、ブロックリクエストを予測するためにブロックリクエストデータベースを使用する。ストリーミングサーバは、予測ブロックリクエストに関連したデータを提供する。【選択図】なし
2008518508.tif 000002
【特許請求の範囲】
【請求項１】
ストリーミングアプリケーションの第１ブロック用のリクエストを受信すること；
ブロックリクエストデータベースをチェックすること；
ブロックリクエストデータベースに基づいた第２ブロックリクエストデータベースを予測すること；
リクエストに応答して、第１ブロックに関連したデータ及び第２ブロックに関連したデータを送信すること
を含んでいることを特徴とする方法。
【請求項２】
ブロックリクエストデータベースに基づく複数のブロックリクエストを予測することをさらに含み、前記送信することは、複数のブロックリクエストに関連したデータを送信することをさらに含んでいることを特徴とする請求項１に記載の方法。
【請求項３】
第２ブロックに関連したデータは、第２ブロック用のリクエストを容易に作成するための第２ブロックを識別するのに十分であることを特徴とする請求項１に記載の方法。
【請求項４】
第２ブロックに関連したデータがリクエストを不必要な第２ブロックに対して請求するのに十分なデータを含んでいることを特徴とする請求項１に記載の方法。
【請求項５】
第１ブロック用のリクエストへのリプライによって第２ブロックに関連したデータをピギーバックすることをさらに含んでいることを特徴とする請求項１に記載の方法。
【請求項６】
第１ブロック用のリクエストをログインすること；及び
ログインされたリクエストに関連したデータを取り入れるためのブロックリクエストデータベースをアップデートすること
をさらに含んでいることを特徴とする請求項１に記載の方法。
【請求項７】
ログインされたリクエストが第１ログインリクエストであり、
テンポラルアグレッシブパラメータをセットすることをさらに含み、
第１ログインリクエストに関連した受信タイムと第２ログインリクエストとの相違がテンポラルアグレッシブパラメータ以下である場合に、第２ログインリクエストについての関連づけられたエクステントに、第１ログインリクエストに関連したデータを取り入れるために、前記リクエストデータベースがアップデートされることをさらに含んでいることを特徴とする請求項６に記載の方法。
【請求項８】
アグレッシブパラメータをセットすることをさらに含んでいることをさらに含み、
第２ブロックリクエストの確率がアグレッシブパラメータよりも高くなる時に、前記第２ブロックに関連したデータ送信されることを特徴とする請求項１に記載の方法。
【請求項９】
ストリーミングアプリケーションの第１ブロック用のリクエストを受信するための手段と；
ブロックリクエストデータベースをチェックするための手段と；
ブロックリクエストデータベースに基づく第２ブロックリクエストを予測するための手段と；
リクエストに応答して、第１ブロックに関連したデータ及び第２ブロックに関連したデータを送信するための手段と
を含んでいることを特徴とするシステム。
【請求項１０】
第２ブロックに関連したデータが、第２ブロック用のリクエストを容易に作成するために第２ブロックを識別するのに十分であることを特徴とする請求項９に記載のシステム。
【請求項１１】
第２ブロックに関連したデータが、リクエストを不必要な第２ブロックに請求するための十分なデータを含んでいることを特徴とする請求項９に記載のシステム。
【請求項１２】
第１ブロック用のリクエストへのリプライによって第２ブロックに関連したデータをピギーバックするための手段をさらに含んでいることを特徴とする請求項９に記載のシステム。
【請求項１３】
第１ブロック用のリクエストをログインするための手段をさらに含んでいることを特徴とする請求項９に記載のシステム。
【請求項１４】
ログインしたリクエストに関連したデータを取り入れるブロックリクエストデータベースをアップデートするための手段をさらに含んでいることを特徴とする請求項１３に記載のシステム。
【請求項１５】
プロセッサと；
予測パラメータを含んでいるブロックリクエストデータベースと；
プロセッサとブロックリクエストデータベースとを結びつけ、ブロックリクエストデータベースをチェックするために構成され、そして第１ブロック用の第１ブロックリクエストに基づく第２ブロックのために第２ブロック及び第１ブロックに関連した予測パラメータを予測する予測エンジンと；
予測エンジンを結びつけ、予測エンジンから第２ブロックリクエストについて予測を取得し、第１ブロックに関連したデータに加えて、第１ブロックリクエストへの応答において第２ブロックと関連したデータを含み、そして、第１ブロックリクエストの応答として応答を送信する構成であるストリーミングサーバと
を含んでいることを特徴とするシステム。
【請求項１６】
第２ブロックに関連したデータが、第２ブロックリクエストを容易に作成するために第２ブロックを識別するのに十分であることを特徴とする請求項１５に記載のシステム。
【請求項１７】
第２ブロックに関連したデータが、不必要な第２ブロックリクエストに請求するのに十分なデータを含んでいることを特徴とする請求子１５に記載のシステム。
【請求項１８】
ストリーミングサーバが、第１ブロックリクエストへのリプライによって第２ブロック関連したデータをピギーバックするためにさらに構成されていることを特徴とする請求項１５に記載のシステム。
【請求項１９】
リクエストログをさらに備え、ストリーミングサーバが、該リクエストログで第１ブロックリクエストをログインするためにさらに構成されていることを特徴とする請求項１５に記載のシステム。
【請求項２０】
予測エンジンが、リクエストログによるブロックリクエストデータベースをアップデートするためにさらに構成されていることを特徴とする請求項１９に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
ソフトウェアストリーミングは、ピースがストリームされたプログラムを必要とするように、ファイルの小さなピースをダウンロードすることを必要としている。このこれらの小さなピースは、ブロックと称してもよい。ストリーミングクライアントは、ストリーミングサーバに必要なブロックのためにリクエストを送信する。そして、ストリーミングサーバは、リクエストブロックに関連したバックストリーミングデータを送信する。リクエストを送信すること及びストリーミングデータを受信することは、ストリームプログラムを遅くする遅延の原因となる。
【発明の開示】
【発明が解決しようとする課題】
【０００２】
否定し、克服し、又は減少するために有利となるストリーミングソフトウェアに関連した多くの問題がある。例えば、ストリーミング用の予測ブロックは、満足がいく状態で取り組まれなかった。
【課題を解決するための手段】
【０００３】
予測ストリーミング用の技術は、ストリーミングアプリケーションの第１ブロック用のリクエストを受信すること、ブロックリクエストデータベースをチェックすること、ブロックリクエストデータベースに基づいた第２ブロックリクエストを予測すること、そして、リクエストに応答して、第１ブロックに関連したデータ及び第２ブロックに関連したデータを送信することを必要としている。ブロックは、ストリーミングアプリケーションの大きい部分であってもよい。ブロックリクエストデータベースは、決定する確率用の確率又は手段を含んでいる。そして、第１ブロックが要求し続けると仮定すれば、第２ブロックがリクエストされる。一つ以上のファクタは、第２ブロック用のリクエストの確率を決定するときに考慮することができる。リクエストに応答して送信されたデータは、第１ブロックに関連したデータ及び第２ブロックに関連したデータを含んでいてもよい。第１ブロックに関連したデータ及び第２ブロックに関連したデータは、類似していてはならない。実施形態において、第１ブロックに関連したデータは、第１ブロック用のブロックリクエストに応答する。一方、第２ブロックに関連したデータは、第２ブロック用のリクエストを容易に作成ために十分なデータである。
【０００４】
実施形態において、技術は、ブロックリクエストデータベースに基づく予測ブロックリクエスト、そして、ブロックリクエストに関連した送信データを更に含んでいてもよい。別の実施形態において、第２ブロックに関連したデータは、リクエストを第２ブロックに不必要なものに請求するのに十分なデータを含んでいる。別の実施形態において、技術は、第１ブロック用のリクエストへのリプライについて第２ブロックに関連したデータをピギーバックすることを更に含んでいる。別の実施形態において、技術は、第１ブロック用のリクエストをログインすること及びログインされたリクエストに関連したデータを取り入れるためにブロックリクエストデータベースをアップデートすることを更に含んでいる。別の実施形態において、技術は、第２ブロックリクエストの確率がアグレッシブパラメータよりも高い時に、アグレッシブパラメータをセッティングすることを更に含んでいる。ここでは、第２ブロックに関連したデータが送信される。
【０００５】
技術により組み立てられたシステムは、プロセッサ、予測パラメータを含んでいるブロックリクエストデータベース、予測エンジン、そしてストリーミングサーバを含んでいてもよい。前記予測エンジンは、ブロックリクエストデータベースをチェックするために設定され、そして第１ブロック及び第１ブロックに関連した予測パラメータ用の第１ブロックデータベースに基づく第２ブロック用の第２ブロックリクエストを予測する。ストリーミングサーバは、予測エンジンから第２ブロックリクエストについて予測を得るために設定されてもよいし、第１ブロックに関連したデータに加えて、第１ブロックリクエストに応答する第２ブロックに関連したデータを含み、そして、第１ブロックリクエストに応答したレスポンスを送信する。
【０００６】
ある実施形態において、第２ブロックに関連したデータは、第２ブロックリクエストを容易に作成することができるように第２ブロックを識別するのに十分である。別の実施形態において、第２ブロックに関連したデータは、第２ブロックリクエストを不必要なものにするのに充分なデータを含んでいる。別の実施形態において、ストリーミングサーバは、第１ブロックリクエストへのリプライについて第２ブロックに関連したデータをピギーバックするためにさらに構成されている。別の実施形態において、システムはリクエストログを含んでいる。そこにおいて、ストリーミングサーバは、リクエストログ内の第１ブロックリクエストにログインするように構成されている。予測エンジンは、リクエストログに従うブロックリクエストデータベースをアップデートするようにさらに構成されている。
【発明を実施するための最良の形態】
【０００７】
パラメータの予測ストリーミングは、ブロックがストリーミングクライアント（ストリーミング）によってリクエストされ又は供給されることを予測をするためにメインテインパラメータ（予測の）（パラメータ）を必要としている。パラメータの予測ストリーミングは、大きい読込みに関するパイプサチュレーションの価値を高めることができ、又は連続した小さな読込みについて高速供給を容易にすることができる。パラメータの予測ストリーミングは、典型的な実施形態において、同様に適応することができる。パラメータの予測適応性のあるストリーミングは、そのうえ長い間にアクセスパターンが情報を得るように変更されるパラメータを必要としている。
【０００８】
図１〜３についての以下の説明は、コンピュータハードウェアの概要及びここで説明された発明の方法を実行することに適している他の操作の構成要素を提供することを意図するが、適用可能な環境を制限することを意図するものではない。同様に、コンピュータハードウェア及び他の操作の構成要素は、ここで説明された本発明の装置の一部として適切である。本発明は、ハンド−ヘルドのデバイス、マルチプロセッサシステム、プログラムできるマイクロプロセッサ系又は家庭用電化製品、ネットワークコンピュータ、ミニコンピュータ、メインフレームコンピュータその他同種のものを含んでいる他のコンピュータシステム構成について実行することができる。本発明はまた、通信ネットワークによってリンクされた遠隔処理装置によってタスクが実行される分散型データ処理方式のコンピュータ環境で実行することができる。
【０００９】
図１は、ネットワークシステム１００を示している。ネットワークシステム１００は、インターネットのようなネットワーク１０２によって結び付けられたいくつかのコンピュータを含んでいる。ここで使用される用語“インターネット”は、ＴＣＰ／ＩＰのような信頼できるプロトコル、及びあるいはワールドワイドウェブ（ｗｅｂ）を構成するハイパーテキストマークアップ言語（ＨＴＭＬ）用のハイパーテキスト転送プロトコル（ＨＴＴＰ）のような他のプロトコルに関する。インターネットの物理的な接続及びインターネットのプロトコルと通信規定は、当業者にとって周知である。
【００１０】
ウェブサーバ１０４は、一般的に少なくとも一つのコンピュータシステムである。このコンピュータシステムは、サーバコンピュータシステムのようにオペレートし、そしてワールドワイドウェブのプロトコルについてオペレートするように構成され、そして、インターネットに接続される。このウェブサーバシステム１０４は、普通のサーバコンピュータシステムであってもよい。選択的に、このウェブサーバ１０４は、クライアントシステムのためのインターネットへのアクセスを提供するＩＳＰの一部であってもよい。このウェブサーバ１０４は、メディアデータベースの形式を判断するウェブコンテンツ１０８に接続されたサーバコンピュータシステム１０６に接続されている。２つのコンピュータシステム１０４，１０６が図１に示される一方、ウェブサーバシステム１０４とサーバコンピュータシステム１０６は、後述するサーバコンピュータシステム１０６によって提供されたサーバ機能性とウェブサーバ機能性を提供する異なるソフトウェア構成要素を備えていてもよい。
【００１１】
ネットワーク１０２へのアクセスは、インターネットサービスプロバイダー（ＩＳＰ）１１０，１１６のように、ＩＳＰによって一般的に提供される。クライアントコンピュータシステム１１２，１１８，１２２，１２６のようなクライアントシステムに関係しているユーザは、インターネットへのアクセスをＩＳＰ１１０，１１６から得る。インターネットへのアクセスは、クライアントコンピュータシステムのユーザをＨＴＭＬフォーマットに作成された文書のような情報、送受信電子メール、そして図面への交換を許可する。これらの文書は、インターネットで“ｏｎ”と呼ばれるウェブサーバ１０４のようなウェブサーバによって度々提供される。度々これらのウェブサーバは、ＩＳＰ１１０のようなＩＳＰによって提供される。しかしながら、コンピュータシステムは、セットアップされ、そして同様にＩＳＰにあるシステムなしにインターネットに接続される。
【００１２】
クライアントコンピュータシステム１１２，１１３，１２２，１２６は、適切なウェブブラウザソフトウェアを用いてウェブサーバ１０４によって提供されたＨＴＭＬページを見ることができる。ＩＳＰ１１０は、クライアントコンピュータシステム１１２の一部と判断されたモデムインターフェース１１４によってクライアントコンピュータシステム１１２へのインターネット接続性を提供する。クライアントコンピュータシステムは、パーソナルコンピュータシステム、ネットワークコンピュータ、ウェブＴＶシステム、又は他のコンピュータシステムであってもよい。図１は、一般的に“モデム”のようなモデムインターフェース１１４を示す一方、インターフェースは、アナログモデム、ｉｓｄｎモデム、ケーブルモデム、衛星通信インターフェース（例えば“ダイレクトＰＣ”）、又はあるコンピュータシステムを他のコンピュータシステムに接続するインターフェースであってもよい。
【００１３】
ＩＳＰ１１４と同様のＩＳＰ１１６は、クライアントシステム１１８，１２２，１２６用のインターネットコネクティビティ接続性を提供する。ただし、図１に示すように、接続は、これらの３つのコンピュータシステムにとって同じものでない。クライアントコンピュータシステム１１８は、クライアントコンピュータシステム１２２，１２６がＬＡＮ１３０の一部である間、モデムインターフェース１２０に接続されている。
【００１４】
クライアントコンピュータシステム１２２，１２６は、イーサネットワーク又は他のネットワークインターフェースとなることのできるネットワークインターフェース１２４，１２８を通してＬＡＮ１３０に接続されている。このＬＡＮ１３０は、ローカルエリアネットワークのための他のインターネット−関連サービス及びファイアーウォールを提供することができるゲートウェイコンピュータシステム１３２をまた接続する。このゲートウェイコンピュータシステム１３２は、インターネット接続性を提供するためのＩＳＰ１１６がクライアントコンピュータシステム１２２，１２６に接続される。このゲートウェイコンピュータシステム１３２は、従来のサーバコンピュータシステムとすることができる。
【００１５】
あるいは、サーバコンピュータシステム１３４は、ゲートウェイシステム１３２を通してインターネットに接続する必要なく、クライアント１２２，１２６へファイル１３８及び他のサービス提供するネットワークインターフェース１３６を通してＬＡＮ１３０に直接接続することができる。
【００１６】
図２は、システム１００（図１）で使用するためのコンピュータシステム１４０を示している。コンピュータシステム１４０は、クライアントコンピュータシステム又はサーバコンピュータシステム又はウェブサーバシステムで使用できる従来のコンピュータシステムであってもよい。この種のコンピュータシステムは、ＩＳＰ１１０（図１）のようなインターネットサービスプロバイダの多くの機能を実行するために使用することができる。コンピュータシステム１４０は、コンピュータ１４２、Ｉ／Ｏ装置１４４、及びディスプレイ装置１４６を含んでいる。このコンピュータ１４２は、プロセッサ１４８、通信インターフェース１５０、メモリ１５２、ディスプレイコントローラ１５４、不揮発性の記憶装置１５６及びＩ／Ｏコントローラ１５８を含んでいる。このコンピュータシステム１４０は、Ｉ／Ｏ装置１４４とディスプレイ装置１４６とを接続又は包含していてもよい。
【００１７】
コンピュータ１４２は、モデム又はネットワークインターフェースを含むことができる通信インターフェース１５０を通して外部システムと入出力を行う。通信インターフェース１５０がコンピュータシステム１４０の一部又はコンピュータ１４２の一部であるとみなされることは認識されるであろう。通信インターフェースは、アナログモデム、ｉｓｄｎモデム、ケーブルモデム、トークンリングインターフェース、衛星通信インターフェース（例えば“ダイレクトＰＣ”）又はあるコンピュータシステムと他のコンピュータシステムとを接続する他のインターフェースとすることができる。
【００１８】
プロセッサ１４８は、例えばインテルペンティアムマイクロプロセッサ又はモトローラパワーＰＣマイクロプロセッサのような従来のマイクロプロセッサであってもよい。メモリ１５２は、バス１６０によってプロセッサ１４８と接続される。このメモリ１５２は、ダイナミックランダムアクセスメモリ（ｄｒａｍ）であってもよいし、また、スタティックラム（ｓｒａｍ）を含んでいてもよい。このバス１６０は、プロセッサ１４８をメモリ１５２と、また不揮発性記憶装置１５６と、ディスプレイコントローラ１５４と、そしてＩ／Ｏコントローラ１５８と接続する。
【００１９】
Ｉ／Ｏデバイス１４４は、キーボード、ディスクドライブ、プリンタ、スキャナそしてマウス又はポインティングデバイスを含む他の入出力装置を含むことができる。ディスプレイコントローラ１５４は、例えば陰極線管（ＣＲＴ）又は液量ディスプレイ（ＬＣＤ）のようなディスプレイ装置１４６による表示を従来の方法で制御してもよい。ディスプレイコントローラ１５４及びＩ／Ｏコントローラ１５８は、従来の周知の技術によって実施される。
【００２０】
不揮発性の記憶装置１５６は、多くの場合、磁気ハードディスク、光学ディスク、又は大量のデータ用の記憶装置の他の種類である。このデータの中には、コンピュータ１４２のソフトウェアの実行中にメモリ１５２にダイレクトメモリアクセスプロセスによってたびたび書き込まれる。この技術についてのスキルの一つは、プロセッサ１４８によってアクセスでき、そのうえデータ信号をエンコードする搬送波を包含する記憶装置のどのようなタイプも含む“機械読取媒体”又は“コンピュータ読取メディア媒体”という用語が直ちに認識される。
【００２１】
コンピュータシステム１４０は、異なる基本設計概念を有する多くの実行できるコンピュータの一例である。例えば、インテルマイクロプロセッサに基づくパーソナルコンピュータは、周辺機器用のＩ／Ｏバスであり、そしてプロセッサ１４８及びメモリ１５２（しばしばメモリバスと称される）に直接接続されるマルチバスを多くの場合備えている。このバスは、異なるバスプロトコルによって必要な変換も実行するブリッジ構成要素に一緒に接続されている。
【００２２】
ネットワークコンピュータは、本発明に使用できるコンピュータシステムの他のタイプである。ネットワークコンピュータは、ハードディスク又は他の大容量規則装置、及びネットワーク接続からプロセッサ１４８による実行用メモリ１５２にロードされた実行可能プログラムを通常含んでいない。公知技術のウェブＴＶシステムは、本発明によれば、またコンピュータシステムとみなされる。しかし、それは、入出力装置のような図２に示されたいくつかの特徴がなくてもよい。典型的なコンピュータシステムは、通常、少なくともプロセッサ、メモリ、及びメモリとプロセッサとを接続するバスを含んでいる。
【００２３】
それに加えて、コンピュータシステム１４０は、オペレーティングシステムの一部であるディスクオペレーティングシステムのようなファイルマネージメントシステムを含むオペレーティングシステムによって制御される。付随するファイルマネジメントソフトウェアに関するオペレーティングシステムソフトウェアの一例は、ワシントン州レドモンド市のマイクロソフトコーポレーションからのWindows（登録商標）そして関連しているファイル管理システムとして知られているオペレーティングシステムの系統である。ファイル管理システムに付随したオペレーティングシステムソフトウェアの他の例は、リナックス（Linux）オペレーティングシステム及びその付随したファイル管理システムである。ファイル管理システムは、不揮発性記憶装置１４８に典型的にストアされ、そして入出力データへのオペレーティングシステムによってプロセッサ１４８に必要とされる多様な行為を実行させ、不揮発性記憶装置１５６に格納されているメモリにデータをストアさせる。
【００２４】
詳細な説明のいくつかの部分は、アルゴリズムに関して及びコンピュータメモリ内のデータビットによるオペレーションの記号的な表現で提示される。これらのアルゴリズムの説明及び表現は、ワークの要旨を他の優れた技術に最も効果的に伝えるためにデータ処理技術における当業者によって用いられる手段である。アルゴリズムは、ここでは、そして一般的に所望の結果に導くオペレーションの首尾一貫したシーケンスであると理解される。オペレーションは、物理量という物理的な扱いを必要としている。通常、必ずしもではないけれども、これらの量は、ストアーされ、転送され、結合され、比較され、そして、さもなければ操作された電気的又は磁気的信号という形を取るわけではない。ビット、数値、要素、シンボル、文字、用語、番号、またはその種の他のものに関して、主に一般的な用法の理由で時々、便利であることが判明した。
【００２５】
しかし、これら及び類似した用語の全てが該当する物理量と関連し、そしてこれらの量に加えられる単に便利な呼び名であることを覚えておくべきである。以下の説明から明らかなように、特に明言された一方でない限り、この説明全体にわたって、“処理”又は“演算”又は“計算”又は“決定”又は“表示”又は同様の用語を利用するディスカッション、コンピュータシステムの機能及び処理又は類似の電子的コンピュータ装置に関して理解される。そしてそれは、コンピュータシステムのレジスタ及びメモリの内部の物理的量のように表されたデータを、コンピュータシステムメモリ又はレジスタ又は他のこの種の情報記憶、伝送又はディスプレイ装置の内部の物理量として述べた他の同様のデータにうまく処理して変換する。
【００２６】
いくつかの実施形態における本発明はまた、ここでオペレーションを実行するための装置に関する。この装置は、必要な目的のために特に作られてもよいし、又は、コンピュータに格納されたコンピュータプログラムによって選択的に作動させられた又は変更された多目的コンピュータを含んでいてもよい。このようなコンピュータプログラムは、限定しないが、フロッピィディスク、光ディスク、ＣＤ−ＲＯＭ、そして光磁気ディスク、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気もしくは光カード、又は格納する電子インストラクションに適しているどのようなタイプのメディア、そしてコンピュータシステムに接続されたそれぞれのようにコンピュータ可読記憶装置に格納してもよい。
【００２７】
ここで紹介されたアルゴリズム及びディスプレイは、いかなる特別なコンピュータにもあるいは他の装置にも本来的に関連しない。多目的システムは、ここでのティーチングに従ったプログラムが使用され、又は、必須の方法処置を実行するためのさらなる専用装置を作ることが便利であるとわかる。様々なこれらのシステムにつていの必須のストラクチャは、下記によって明らかである。加えて、本発明は、どのような特別のプログラミング言語に関しても記述されず、そして種々の実施形態がいろいろなプログラミング言語を使用して実行される。
【００２８】
図３は、コンピュータシステム１４０（図２）の一部とシステム１００（図１）の構成要素を示している。図３は、コンピュータシステム１４０、ネットワーク１６２そしてストリーミングクライアント１６４を示している。ネットワーク１６２は、インターネット、ローカルもしくはワイドエリアネットワーク（ＬＡＮもしくはＷＡＮ）、又はある他のインターネットもしくはネットワークのようなグローバル情報ネットワークでもよい。例えば、ネットワーク１０２（図１）は、ネットワーク１６２を含んでいてもよい。あるいは、ＬＡＮ１３０（図１）は、ネットワーク１６２を含んでいてもよい。他の代替物で、コンピュータシステム１４０は、物理的に又は無線でストリーミングクライアント１６４を接続してもよい。
【００２９】
このストリーミングクライアント１６４は、ネットワーク１６２を通して接続され、そして、アクセスされる。このストリーミングクライアント１６４は、ソフトウェア、ファームウェア又はハードウェアモジュールであってもよい。あるいは、このストリーミングクライアント１６４は、ソフトウェア、ファームウェア又はハードウェア構成要素のある組合せを含むことができる。このストリーミングクライアント１６４は、コンピュータシステム１４０（図２）のようなコンピュータシステムの一部であってもよい。このストリーミングクライアント１６４は、プロセッサ、メモリ、及びこのプロセッサ又はこのメモリを接続するバスを含んでいてもよい。このストリーミングクライアント１６４又はこのストリーミングクライアント１６４に関連したコンピュータシステムは、ストリーミングアプリケーションを実行している時にあるプログラムを使用してもよい。例えば、ストリーミングアプリケーションは、このストリーミングアプリケーションを実行する前に典型的にインストールされたDirectX（トレードマーク）、Acrobat（トレードマーク）、又はQuick  Time（トレードマーク）のような具体的なバージョンとともに使用してもよい。
【００３０】
コンピュータシステム１４０は、プロセッサ１６６、メモリ１６８、そしてプロセッサ１６６をメモリ１６８に接続するバス１７０を含んでいる。このメモリ１６８は、ＤＲＡＭ又はＳＲＡＭのような揮発性メモリと、磁気又は光学記憶装置のような不揮発性メモリとを含んでいる。このメモリ１６８は、また、例えば環境変数を含んでいてもよい。このプロセッサ１６６は、メモリ１６８内のコードを実行する。このメモリ１６８は、ストリーミングサーバ１７２、ブロックリクエストデータベース１７４、予測エンジン１７６、そして一つ以上のストリーミングアプリケーション１７８を含んでいる。プログラム、ファイル、コンピュータシステム１４０のデータのいくつか又はすべては、例えばサーバコンピュータ１０６（図１）によって、ウェブコンテンツのように役立つ。このプログラム、ファイル、又はデータは、サーバコンピュータ１３４（図１）のようなＬＡＮ又はＷＡＮ上のサーバコンピュータの一部であってもよい。
【００３１】
ストリーミングサーバ１７２は、このブロックへのリクエストに応答するストリーミングアプリケーション１７８の一つのようなストリーミングアプリケーションのようなブロックと関連のあるデータを出すように構成されてもよい。ブロックリクエストデータベース１７４は、ストリーミングクライアント１６４のような一つ以上のストリーミングクライアントから受信されたブロックリクエストと関連したデータを含んでいてもよい。このブロックリクエストデータベース１７４は、ブロックリクエストのサブセット又は一つにつきアップデートされたブロックリクエストログを含んでいてもよい。このブロックリクエストデータベース１７４は、ブロックリクエストが受信された全てのストリーミングクライアントの全て又はサブセットによって一般的に用いられた特定の又は一般的になクライアントであってもよい。ブロックリクエストデータベース１７４は、ストリーミングアプリケーション１７８の全てのサブセット又は全てに広く関連した又は特定のアプリケーションであってもよい。このブロックリクエストデータベース１７４は、ブロックリクエスト履歴を含んでいてもよい。この履歴は、いくつかのオリジナルのデフォルト値、又は例えばコンピュータシステム１４０を管理しているソフトウェアエージェント又はユーザによるデータ入力を長い間に受信したブロックリクエストと関連したデータから得られる。ブロックリクエストデータベース１７４は、個々のブロックリクエスト、ブロックリクエストログ、又はブロックリクエストヒストリから得られたパラメータを含んでいてもよい。
【００３２】
予測エンジン１７６は、ストリーミングクライアント１６４が要求するとしても、一つ以上のブロックを予測するために構成されている。ここで用いられる“エンジン”という用語は、ソフトウェア、ファームウェア、ハードウェア、又は目的を遂行するための他の構成要素のどのような組合せにも一般的に当てはまる。この予測エンジン１７６は、アグレッシブパラメータ（図示せず）を含んでいてもよい。このアグレッシブがハイである場合は、予測エンジン１７６は、このアグレッシブがローである場合よりももっと予測しやすい。典型的な実施形態において、アグレッシブパラメータは、確率閾値と関連している。この確率閾値は、カットオフ確率であってもよい。このカットオフ確率は、カットオフ確率よりも大きいリクエストがされる確率のあることを決定したブロックのために作られた予測に終わる。他の典型的な実施形態において、予測エンジン１７６は、確率閾値よりもハイが要求された確率についていかなるブロックを予測してもよい。これらの例において、アグレッシブがハイであるときに、アグレッシブパラメータはロー（すなわち、確率閾値はローである）であることに留意すべきである。それにもかかわらず、言語学の明快さという目的のため、以下に、アグレッシブパラメータは、アグレッシブがハイであるときにハイであると仮定される。例えば、アグレッシブパラメータが閾値確率ｘについて関連していると、その時、アグレッシブパラメータの値は、１−ｘと考えられる。そして、それはアグレッシブがハイであるときにアグレッシブパラメータがハイであることを意味している。これは、言語の明快さという目的のためであり、そして、アグレッシブパラメータが実行される方法に関して限定して解釈してはならない。アグレッシブパラメータは、閾値確率に限定されないということが強調されるべきである。
【００３３】
予測エンジン１７６が予測するとき、ストリーミングサーバ１７２は、予測をストリーミングクライアント１６４に通信してもよい。予測は、一つ以上のブロックに関する識別するデータを含んでいてもよい。それぞれは、確率閾値よりもハイをリクエストする予測確率を有するようなアグレッシブ基準に適合する。ここで使われるような識別データは、識別データについて予測する一つ以上のブロック用のリクエストを作成するため、ストリーミングクライアントにとって十分なデータである。識別データは、例えば、ブロックに関連したブロックＩＤを含んでいてもよい。この識別データは、ブロックがストリーミングクライアント１６４で実際に必要とされる前に、ブロック用の予測リクエストを容易にすることができる。識別データがストリーミングクライアント１６４に提供されている典型的な実施形態において、ストリーミングクライアント１６４は、ストリーミングデータに関連したブロックを要求するかどうかを決定することができる。これは、ストリーミングクライアント１６４が本当に必要でない又は不足していないストリーミングデータをダウンロードしないようにするのに役立つ。例えば、ストリーミングクライアント１６４が第１ブロックと関連したデータをストリーミングする必要があると、ストリーミングサーバ１７２が予測すると、そして、第１ブロックと関連したストリーミングデータが送信されると、ストリーミングクライアント１６４は、例えばローカルファクタに基づいたストリーミングデータを受信したかどうか否かにかかわらず選択することができない。他方、ストリーミングクライアント１６４が識別するデータを受信すると、ストリーミングクライアント１６４は、それが実際にストリーミングデータを必要としているか否かにかかわらず決定することができる。別の実施形態において、ストリーミングサーバ１７２は、予測ブロックに関してストリーミングクライアント１６４からの要求をさらにできる限り受信することなく、予測ブロックに関連したストリーミングデータを時々サーブする。
【００３４】
予測エンジン１７６は、多くのブロックに重要性を通知する。例えば、予測エンジン１７６は、第２ブロック（確率パラメータ）よりももっと要求されそうな第１ブロックを予測することができる。ストリーミングクライアント１６４は、例えばリクエストされた最もハイの確率に関して第１にリクエスト要求することができる。他の例として、予測エンジン１７６が第２ブロック（一時的なパラメータ）よりも早くリクエストされる第１ブロックを予測すると、予測エンジン１７６は、第２ブロックを通じて第１ブロックにより大きい重要性を与える。他の例として、第１ブロックが第２ブロック（サイズパラメータ）よりも大きいと、予測エンジン１７６は、第２ブロックを通じて第１ブロックにより大きい重要性を与える。予測エンジン１７６は、同様に、ストリーミングクライアント１６４に関連のあるパラメータを比較考量する。例えば、ストリーミングクライアント１６４が制限されたバッファサイズである場合、アグレッシブパラメータは、ローにセットすることができる。他の例として、ダウンロードバンド幅がローであると、予測エンジン１７６は、一時的な又はサイズパラメータに重要性が置かれる。あるいは、ストリーミングクライアント１６４は、ローカルコンディションにしたがってブロックリクエストを処理してもよい。その一方で、予測エンジン１７６は、全てのストリーミングクライアントの全て又はサブセットのために同様の働きをする。
【００３５】
オペレーション中に、ストリーミングクライアント１６４は、ストリーミングアプリケーション１７８のストリーミングアプリケーションに関連したブロック用リクエストをストリーミングサーバ１７２へネットワーク１６２を通して送信される。ストリーミングサーバ１７２、又はコンピュータシステムの他の構成要素（図示せず）はリクエストをログインする。実例だけの目的のために、ブロックリクエストテーブル１７４は、ブロックリクエストログとみなされる。しかし、多様な実施形態において、ブロックリクエストデータベース１７４は、ブロックリクエストログから又はログに記録されていないブロックログのグループもしくは個々から導き出される。典型的な実施形態において、ブロックリクエストデータベース１７４は、過去のブロックリクエスト、又はデフォルトもしくは初期設定から導き出されるパラメータを含んでいる。デフォルトもしくは初期設定は、ストリーミングクライアント１６４から次のブロックリクエストを予測するのに役立つ。
【００３６】
予測エンジン１７６は、次のブロックリクエストを予測するためブロックリクエストデータベース１７４からのデータを使用する。次のブロックリクエストは、例えば、最初のブロックリクエストのような同じストリーミングアプリケーションからの、ＤＬＬからの、データファイルからの、異なる実行可能なファイルからの、又はどのようなファイルもしくはアプリケーションからのブロックであってもよい。ストリーミングサーバ１７２は、リクエストブロックに関連したストリーミングデータ、及び、ストリーミングクライアント１６４への予測ブロックに関連した識別データを提供する。ストリーミングクライアント１６４は、その時、識別された予測ブロックをリクエストするかどうかを決定する。例えば、ストリーミングクライアント１６４は、ローカルキャッシュ内で識別データに関連したブロックのためのデータを有していてもよい。ストリーミングサーバ１７２がデータを再度送信する場合、バンド幅の無駄使いであり、そして、ストリーミングアプリケーションの実行を遅くすることができる。ストリーミングサーバ１７２がストリーミングデータの代わりに識別データを送信してから、ストリーミングクライアント１６４は、例えば、最初にローカルキャッシュをチェックすることができ、そしてローカルキャッシュ内ですでに利用できないならば、ストリーミングデータを要求することができる。他の実施形態において、ストリーミングサーバ１７２は、リクエストブロックに関連したストリーミングデータ及び一つ以上の予測ブロックに関連した識別データをサーブする。ストリーミングクライアント１６４は、その時、リクエストするための識別ブロックか例えば何を命じるかを決定する。本来、予測エンジンが予測内で修正する場合、ストリーミングクライアント１６４は、たとえ、ストリーミングクライアント１６４が識別データに応えて予測ブロックをリクエストしなくても、予測ブロックがやがて予測ブロックを最終的にリクエストする。
【００３７】
図４は、実施形態による予測ストリーミングのための典型的な方法のフローチャートを示している。このフローチャートは、第１ブロックを要求するモジュール１８０でスタートする。リクエストは、ストリーミングクライアントから始まる。フローチャートは、第１ブロックへのリクエストを受信するモジュール１８２に続く。受領は、ストリーミングサーバにあってもよい。ストリーミングサーバは、リクエストをログインすることができる。フローチャートは、ブロックリクエストデータベースをチェックに関するモジュール１８４に続く。サーバは、ブロックリクエストデータベースをチェックすることができる。ブロックリクエストデータベースは、ログインされたリクエストを含んでいてもよい。フローチャートは、ブロックリクエストデータベースに基づいて予測する第２ブロックリクエストに関するモジュール１８６に続く。サーバは、第２ブロックリクエストを予測するための予測エンジンを使用してもよい。予測は、第１ブロック用のブロックリクエスト、その後、ストリーミングクライアントから第２ブロック用のブロックリクエストに基づいてもよい。フローチャートは、第１ブロックに関連したブロックデータを含むリプライの第２ブロックＩＤをピギーバッキングすることに関するモジュール１８８に続く。フローチャートは、第１ブロックデータ及び第２ブロックＩＤを受信することに関するモジュール１９０に続く。フローチャートは、ローカルファクタに基づく第２ブロックにリクエストするかどうかを決定することに関するモジュール１９２に続く。フローチャートは、第２ブロックにリクエストすることに関するモジュール１９４に続く。ローカルファクタが第２ブロック用のリクエストに値するのは、実例の目的を推定するためである。例えば、第１ブロックに関連したストリーミングデータがローカルディスクキャッシュ内にある場合、第２ブロックは、リクエストされない。フローチャートは、第２ブロックのためのリクエストを受信することに関するモジュール１９６に続く。フローチャートは、第２ブロックに関連したブロックデータを含んでいる第２のリプライに関するモジュール１９８に続く。フローチャートは、第２ブロックデータを受信することに関するモジュール２００で終了する。フローチャートが大きいブロックを形成していることを描いていることに対して、連続した小さなリード（読取り）を描いているように考えられるが、ブロックは非常に大きくてもよいことに留意する必要がある。この方法及び他の方法は、連続的に配置したモジュールのように描かれている。しかし、この方法のモジュールは、専有している時、並列実行のため再オーダ又はアレンジしてもよい。
【００３８】
ストリーミングサーバがリクエストブロック（第１ブロック）に関連したデータと一緒の予測ブロック（第２ブロック）リクエストに関連したデータを送信するときに、第１第２ブロックデータは、これらが逆並列（back  to  back）送信のための待ち行列に入れられる場合、“大きいブロック”と考えることができる。しかし、第１及び第２ブロック逆並列を待ち行列に入れるために、ストリーミングサーバは、第２ブロック用のリクエストを受信しなければならず、そしてストリーミングサーバが第１ブロックデータを送信し終えた前に第２ブロックデータを待ち行列に入れなければならない。データが大きいブロックとして送信されるときに、ストリーミングサーバは、ほとんど連続するアウトプットを有することができる。大きいブロックは、大きいデータが十分に“パイプを飽和させる”ことができることから、利用できるバンド幅をもっと利用することを促進する。これは、第１ブロックストリーミングデータを送信することとリクエストを受信することと第２ブロックストリーミングデータを送信することとの間で一時中断するために、パイプを飽和状態にさせない連続したブロック用リクエストとは対照的である。十分にパイプを飽和させることで、パフォーマンスが改善される。
【００３９】
いくつかの場合には、ブロックは、最初に大きくされる。例えば、ストリーミングアプリケーションがゲームに基づくレベル用である場合、大きいブロックは全体のレベルに関連するデータを含むことができる。ブロック用リクエストが受信されたとき、全体のレベルに関連するデータは、ストリーミングサーバから連続するアウトプットとして返信される。あるいは、大きいブロックは、第１ブロックリクエスト及び予測ブロックリクエストに基づいた“大急ぎで”を構築する。例えば、ストリーミングサーバが第１ブロックリクエストへのリプライによってピギーバックされた多数の予測ブロックリクエストのための識別データを送信する場合、第１ブロックに関連するストリーミングデータに加えて、ストリーミングクライアントは、いくつか又は全てのマルチプル予測ブロックに連続してリクエストすることができる。このリクエストが比較的急速なサクセッションにおいて作られた場合、ストリーミングサーバは、ストリーミングサーバが一つの予測ブロックに関連したストリーミングデータを送信するよりももっと急速に２つの予測ブロックに関連したストリーミングデータをキューに入れることができる。このように、フォールキューを維持し、それに応じて、パイプを飽和させておくことができる。
【００４０】
図５は、一実施形態による予測ストリーミングのための典型的な方法を示している。フローチャートは、第１ブロックをリクエストすることに関するモジュール２０２でスタートする。フローチャートは、第１ブロック用リクエストを受信することに関するモジュール２０４に続く。このストリーミングサーバは、リクエストをログインすることができる。このフローチャートは、第１ブロックリクエストに基づく予測ブロックリクエストに関するモジュール２０６に続く。サーバは、ブロックリクエストを予測するための予測エンジンを使用することができる。予測エンジンは、例えば第１ブロック用より重要なブロックリクエストから得られたパラメータを含んでいるブロックリクエストデータベースを使用することができる。フローチャートは、第１ブロックに関連したストリーミングデータ及び予測ブロック用識別データを送信することに関するモジュール２０８に続く。ストリーミングサーバは、第１ブロック用リクエストにリプライする識別データをピギーバックすることができる。このフローチャートは、ストリーミングデータ及び識別データを受信することに関するモジュール２１０に続く。ストリーミングクライアントは、このデータを受信することができる。このフローチャートは、連続した一つ以上の予測ブロックをリクエストすることに関するモジュール２１２に続く。ストリーミングクライアントは、識別データに関連したブロックが要求されたローカルファクタに基づいて決定される。ストリーミングクライアントは、ブロックに関連したファクタに従う予測ブロックリクエストをオーダしてもよいし、しなくてもよい。例えば、ストリーミングクライアントは、確率のオーダで予測ブロックリクエストを作ることができる。この各ブロック用の確率は、識別データとともに送信され、又はローカルに得られる。フローチャートは、予測ブロックリクエストを受信することに関するモジュール２１４に続く。フローチャートは、アウトプットパイプを多数のブロックに関連したストリーミングデータで飽和させることに関するモジュール２１６に続く。このストリーミングサーバは、ストリーミングデータがストリーミングクライアントに送信されるのと同じぐらい速く又はより速くストリーミングデータを待ち行列によるアウトプットパイプで飽和状態にすることができる。このストリーミングサーバは、待ち行列が空でない限り、ストリーミングデータよりも遅い待ち行列ストリーミングデータが送信される場合であっても、アウトプットパイプが飽和であることを維持できる。ストリーミングサーバは、全体のストリーミングセッション用のアウトプットパイプ飽和を維持してもよいし、しなくてもよい。ストリーミングサーバがパイプで飽和状態にあるとき、全体の飽和が可能でも、ストリーミングセションの全体にわたって、ストリーミングサーバが飽和状態を維持すると推定されない。ストリーミングサーバがパイプで飽和しているとき、このパイプは、必ずしも完全に飽和しているわけではない。ストリーミングデータは、必ずしも完全に連続的なストリームであるわけではない。ここで使用されるように、データの連続的なストリームは、空でない待ち行列から送信されたデータを意味する。アウトプット待ち行列が空である間、データの第１及び第２ストリームは期間が連続であるか参照する前と後に送信する。フローチャートは、ストリーミングデータを受信することに関するモジュール２１８で終了する。ストリーミングクライアントは、ストリーミングデータを受信することができる。ストリーミングサーバがパイプを飽和させるけれども、ストリーミングクライアントは、ネットワーク遅延のようなデータ伝送の技術でよく知られていない、そして、それゆえに、ここでは説明されていない多様なファクタにしたがって、データの連続したストリームを受信してもよいし、しなくてもよい。
【００４１】
時々、ストリーミングクライアントは、全く連続した方法でブロックを速くリクエストすることができる。例えば、ブロックについてのシーケンスがビデオクリップに関連する場合、ブロックは、順序を追って次々と適度におそらくサーブされる。ストリーミングサーバがそのパターンを備えているという理由、又はストリーミングサーバが長い間受信しているブロックリクエストからパターンに気が付くという理由で、ストリーミングサーバはブロックリクエストの連続したパターンを認識することができる。ストリーミングサーバは、パターンで識別されるブロック用のブロックリクエストに通常先行することがわかるブロックリクエストに応答してストリーミングクライアントにパターンを送信することができる。そのパターンを使用することにより、ストリーミングクライアントは、それらで必要とされるストリーミングアプリケーションを予想した追加のブロックを予測的にリクエストすることができる。ストリーミングクライアントは、比較的急速なサクセッションを作ることができる。その理由は、そのパターンを使用して、どのリクエストもストリーミングサーバから受信したストリーミングクライアントを作ることができるからである。これは、結果としてストリーミングサーバでアウトプットパイプ飽和になる。このストリーミングクライアントは、各リクエストにリプライするために待ってもよいし、待たなくてもよい。予測的にリクエストされたブロックは、それらが必要とされるまで、ローカルキャッシュにストアされる。そのパターンの認識を制御するパラメータは、先読みスケジュールがアグレッシブである方法と同様に、ファイル、ファイル拡張子、ディレクトリそしてアプリケーションレベルでそれぞれに特定されることができる。それに加えて、ファイルがオープン（リードが見える前にさえ）するや否やいくつかのブロックが予測的にダウンロードされ、そして、最初のブロックがダウンロードされるまでオープンコールがそれ自体待たされることが示される。典型的な実施形態において、このパターンは、そのパターンで代表される各ブロック用のデータを識別することを含んでいる。このパターンは、ブロックリクエストデータベースを含んでいてもよい。
【００４２】
別の実施形態において、ストリーミングサーバは、パターンデータベースのような一つ以上のパターンに関するストリーミングクライアントを提供することができる。このストリーミングサーバは、ストリーミングクライアントがパターンデータベースに関連したストリーミングアプリケーションのストリーミングを最初にリクエストする時に、パターンデータベースを提供してもよいし、しなくてもよい。このストリーミングクライアントは、ブロックリクエストに基づいてリクエストするブロックが作る目的を予測するためのパターンデータベースを使用することができる。例えば、第１ブロックリクエストがパターンデータベース内のパターンが出られないように邪魔をすることに関連する場合、ストリーミングクライアントは、パターン内の第１ブロック及び各ブロックを連続してリクエストする。このパターンデータベースは、ブロックリクエストデータベースを含んでいてもよい。
【００４３】
図６は、ブロックデータを提供するため及び一実施形態に従ってブロックリクエストに応答する予測ブロックを識別するためのシステム６００の概念上の図を示している。このシステム６００は、インプットノード２１８、ストリーミングサーバ２２０、リクエストログ２２２、予測エンジン２２４、ブロックリクエストデータベース２２６、ストリーミングアプリケーション２２８、そしてアウトプットノード２３０を含んでいる。インプットノード２１８は、システム６００を他のコンピュータシステム又はストリーミングサーバ２２０にプロバイディングブロックをリクエストするためのシステム６００内のロジカルノードに接続するためのインターフェースであってもよい。このインプットノード２１８は、ストリーミングサーバ２２０の一部として扱われてもよいし、扱われなくてもよい。このストリーミングサーバ２２０は、ソフトウェア、ファームウェア、ハードウェア又はこれの組合せを含んでいてもよい。ストリーミングサーバ２２０は、一つ以上の専用のプロセッサ含むことができ、又はローカルもしくはリモートの構成要素に関する一つ以上のプロセッサ（図示せず）を含んでいてもよい。リクエストログ２２２は、コンピュータネットワークの技術で周知の後継のトラフィックを記録するログ、又はブロックリクエストを記録するだけの専用のログであってもよい。リクエストログ２２２は、ストリーミングアプリケーション２２８又はマルチプルストリーミングアプリケーション（図示せず）に関連していてもよい。リクエストログ２２２は、個々に、集合体で、又はいくつかの組合せのどれかで、一つ以上のストリーミングクライアント（図示せず）に関連していてもよい。リクエストログは、ストリーミングサーバ２２０専用であってもよいし、又はマルチプルストリーミングサーバ（図示せず）に関連していてもよい。リクエストログは、ストリーミングサーバ２２０に関してローカル又はリモートであってもよい。予測エンジン２２４は、ソフトウェア、ファームウェア、ハードウェア、又はこれらの組合せを含んでいてもよい。予測エンジンは、一つ以上の専用のプロセッサを含んでいてもよいし、又は一つ以上のプロセッサ（図示せず）をストリーミングサーバ２２０のような他のローカルの構成要素又はリモートの構成要素（図示せず）と共有していてもよい。予測エンジン２２４は、ストリーミングサーバ２２０の一部として扱ってもよいし扱わなくてもよい。ブロックリクエストデータベース２２６は、ソフトウェア、ファームウェア、ハードウェア、又はこれらの組合せを含んでいてもよい。ブロックリクエストデータベース２２６は、リクエストログ２２２の一部、予測エンジン２２４の一部、又はストリーミングサーバ２２０の一部であってもよいし、なくてもよい。別の実施形態において、ブロックリクエストデータベース２２６は、リクエストログ２２２を含んでいる。ブロックリクエストデータベース２２６は、ブロックリクエストパラメータを含んでいる。このパラメータは、定数又は変数環境変数のように作用する変数としてメモリにストアする。このパラメータは、ローカルに又は遠隔で入手することができる。このパラメータは、手動入力、自動入力又は派生したものでもよい。このパラメータは、長い間にユーザ又はエージェント、ブロックリクエスト、又は他の要因によるインプットによって長い間に変更されてもよいし、変更されなくてもよい。ストリーミングアプリケーション２２８は、ストリーミング用として利用することができるアプリケーションでもある。このストリーミングアプリケーション２２８は、前もってストリーミングのために準備してもよいし、しなくてもよい。このストリーミングアプリケーション２２８が図６に示されている間、マルチプルストリーミングアプリケーションは、システム６００に含められることがある。マルチストリーミングアプリケーションは、別々に処理されてもよい（例えば、リクエストブロックと同じストリーミングアプリケーションからブロックの予測だけを許すことによって）、又は一まとまりのブロック（例えば、予測ブロックは、リクエストブロックと異なるストリーミングアプリケーションからなる）として。このストリーミングアプリケーションは、ローカルでもよいし、リモートでもよい。アウトプットノード２３０は、システム６００を他のコンピュータシステム又はストリーミングサーバ２２０からブロックリクエストを送信するためのシステム６００内のロジカルノードに接続するためのインターフェースであってもよい。このアウトプットノード２３０は、ストリーミングサーバの一部としてみなしてもよいし、されなくてもよい。このアウトプットノード２３０及びインプットノード２１８は、インプット／アウトプットノードのコンポーネントとみなしてもよいし、みなさなくてもよい。
【００４４】
オペレーション中に、インプットノード２１９は、ストリーミングクライアント（図示せず）からブロックリクエストを受信する。このインプットノード２１９は、ストリーミングサーバ２２０にブロックリクエストを提供する。このストリーミングサーバ２２０は、リクエストログ２２０内のブロックリクエストをログインする。ストリーミングサーバは、予測エンジン２２４から予測を得る。リクエストのロギング及び予測の取得は、どのような特別のオーダでも生ずる必要がない。例えば、ストリーミングサーバ２２０は、ロジックブロックリクエストの前に（又は考慮なしで）予測エンジン２２４から予測を得てもよい。
【００４５】
この予測エンジン２２４は、リクエストログ２２２をチェックし、リクエストログ２２２をパラメータ的に代表して計算し、そして、ブロックリクエストデータベース２２６のパラメータをアップデートする。予測エンジンは、ストリーミングクライアントから次のブロックリクエストに関する予測をするために、ブロックリクエストデータベース２２６のパラメータをチェックする。リクエストログのチェック及びパラメータのチェックは、いかなる特別のオーダをでも生ずる必要がない。例えば、予測エンジン２２４は、リクエストログをチェックする前及びパラメータをアップデートする前にパラメータをチェックすることができる。予測エンジン２２４は、リクエストログをチェックすることができ、そして手順をアップデートするルーチンの一環としてパラメータをアップデートすることができる。そして、その時、ユーザ、又はシステム６００のエージェント、又はストリーミングアプリケーション２２８へのアクセスのようないくつかの他の刺激に応答することによってパラメータをアップデートするように命じる。従って、ログリクエストのチェック及びパラメータのアップデートは、予測するためのパラメータのチェックと比べて、別々の、そして間接的に関連するのみの手順と考えられる。予測は、一つ以上のブロックＩＤの形で、一つ以上のブロック、パターン、又はブロックが予測的に要求されるべきリクエストされるべきことを決定するためにストリーミングクライアントによって使用されるどのような他のデータのための識別データであってもよい。
【００４６】
ストリーミングサーバ２２０が予測を入手する時、ストリーミングサーバ２２０は、ストリーミングアプリケーション２２８のリクエストブロックに選択的にアクセスする。予測を入手すること及びリクエストブロックにアクセスすることは、どのような特別のオーダを生じさせる必要がなく、そしてオーバーラップすることがあり得る。ストリーミングサーバ２２０に提供された予測は、ストリーミングサーバ２２０によって修正されてもよいし、されなくてもよい。例えば、予測は、識別データを以前“調べる”であったデータを含んでいてもよい。この場合、識別データを調べるために使用したストリーミングサーバ２２０の一部は、予測エンジン２２４の一部と称してもよい。
【００４７】
ストリーミングアプリケーション２２８のリクエストブロックへのアクセスは、ストリーミングサーバ２２０が予測ブロックそれ自体を送信しない予測ブロックの識別子を単に返信するだけでよいため、選択できる。予測（例えばストリーミングクライアント）の受信者がブロックをすでに受信したため、確かに予測を単に送信することがより好ましい。受信者がブロックをすでに受信した場合、及びブロック残りが取り入れられた場合、そのブロックを再び送信する理由は、おそらくない。それゆえに、予測を受信するストリーミングサーバは、予測ブロックを再びリクエストすることはない。ストリーミングサーバ２２０は、予測エンジン２２４からの識別データを得ると呼ばれる。そこにおいて、識別データは、一つ以上の予測ブロックを作ることをリクエストしたときに、例えばストリーミングクライアントによって使用される。
【００４８】
このストリーミングサーバ２２０は、ストリーミングデータのようなリクエストブロック、及びアウトプットノード２３０への識別データのような予測に関連したデータを提供する。このデータは、アウトプットノード２３０から例えばストリーミングクライアント（図示せず）へ送信される。典型的な実施形態において、予測は、例えばストリーミングデータを含んでいるリプライでピギーバックされる。他の典型的な実施形態において、予測は、およそ同じ時間又は例えばストリーミングデータを含むリプライの後のどちらかで、別々に送信される。別の実施形態において、ストリーミングサーバ２２０は、ストリーミングアプリケーション２２８の予測ブロックにアクセスすることができ、そして、リクエストブロックデータを含んでいるリプライの一部として予測ブロックに関連したストリーミングデータを含んだリプライを送信することができる。すなわち、ストリーミングサーバ２２０は、リクエストブロックデータを含んでいるリプライを送信する前に、同時に、又は後で、予測ブロックに関連したストリーミングデータを別々に送信することができる。
【００４９】
予測は、予測エンジン２２４によって常に提供されてもよいし、されなくてもよい。予測がストリーミングサーバ２２０に提供されない場合、ストリーミングサーバは、リクエストブロックに関連したストリーミングデータを単に提供してもよい。典型的な実施形態において、予測エンジン２２４は、予測から十分なデータが作られないと、予測できない。あるいは、予測エンジンは、ある確率に適合するときだけ予測を提供してもよい。例えば、アグレッシブパラメータは、例えば０．５というカットオフ限界を設けてもよい。ブロック用の予測の確実性がカットオフ限界に合っていない又は上回らない場合、予測エンジン２２４は、ストリーミングサーバ２２０へブロック用の予測を提供しない。
【００５０】
図７Ａから７Ｃは、リクエストブロックに基づくブロックリクエストを予測する方法を例示して説明することを目的している。図７Ａから７Ｃは、典型的なブロックリクエストログ及び実施形態に従って導かれたパラメータを示している。図７Ａか７Ｃは、好適な実施形態を例示していることを目的としない。というのは、リクエストログ内で記録され又は省略されたデータについて多くの異なる項目があり、そして、データの選択された項目から引き出された多くの異なるパラメータがあるからである。
【００５１】
図７Ａは、典型的なリクエストログ２３２及びブロックリクエストデータベース２３４を描いている。この実例では、リクエストログ２３２は、ブロックがストリーミングクライアントからリクエストされたオーダ内のブロックリストを含んでいる。典型的な目的のために、リクエストログ２３２は、単一のストリーミングクライアントに関連していると仮定される。このリクエストログ２３２は、単一のストリーミングアプリケーションと関連していてもよいし、していなくてもよい。ブロックリクエストデータベース２３４は、リクエストログ２３２から得られたパラメータを含んでいる。典型的な目的のために、このパラメータは、リクエストログ２３２内のエントリだけから得られる。別の実施形態において、パラメータはデフォルト値を含むことができ、又は一方がリクエストログ２３２を含んでいないデータに依存することができる。実例の目的のため、リクエストログ２３２は、図７Ａに示された値だけを含むと仮定される。実例の目的のため、ブロックリクエスト（現在のブロックリクエスト）は、ブロック３〜８のそれぞれのために考慮される。
【００５２】
ブロック３用の現在のブロックリクエスト：リクエストログ２３２に示されているように、ブロック５（第２ブロックリクエスト）用ブロックリクエストは、ブロック３（第１ブロックリクエスト）に直ちに続く。第２ブロックリクエストがブロック３用のリクエストに続くため、現在のブロックリクエスト（ブロック３用）の後にブロック５用のリクエストが続くかどうかについて、予測が可能である。その後、実例の目的のため、パラメータは、リクエストログ２３２（そして他のデータが考慮されない）からだけ引き出される。そして、ブロック５用のリクエストが１００％確かであると仮定してもよい。ブロック３用の予測ブロックパラメータ配列は、［（５，１．０）］である。これは、ブロック３用のリクエストの後のブロック５用のリクエストの確率が１．０であると説明することができる。もちろん、これは、小さなデータサンプルに基づいており、そして、そのため、非常に大きいエラーになりやすい。しかし、長い間に確率はより正確になる。
【００５３】
ブロック４用の現在のブロックリクエスト：リクエストログ２３２内に示されたように、ブロック４用のブロックリクエストは、作られなかった。よって、予測は作られない。
【００５４】
ブロック５用の現在のブロックリクエスト：ブロック３用のリクエストに関して行われたこれらと同様の理由で、ブロック５用の予測パラメータ配列は、［（８，１．０）］である。
【００５５】
ブロック６用の現在のブロックリクエスト：リクエストログ２３２内に示されたように、ブロック６用のブロックリクエストは、以前に作られているが、それは（何も後に続かない）最後の（最近の）ブロックリクエストであった。よって、予測は作られない。
【００５６】
ブロック７用の現在のブロックリクエスト：ブロック３用のリクエストに関して行われたこれらと同様の理由で、ブロック５用の予測パラメータ配列は、［（８，１．０）］である。
【００５７】
ブロック８用の現在のブロックリクエスト：リクエストログ２３２内に示されたように、ブロック４用のブロックリクエストは、以前に二度作られた。ブロック８用のリクエストに続くブロックリクエストは、ある時は３で、別の時は６である。典型的な目的のため、ブロック３又は６用のリクエストが等しくあり得ると仮定することができる。よって、ブロック８用の予測ブロックパラメータ配列は、［（３，０．５），（６，０，５）］である。これは、ブロックリクエスト８用のリクエストの後のブロック３の確率が０．５であり、そして、ブロック６用のリクエストの確率が０．５であると説明することができる。ブロック３，６用のリクエストが等しくあり得ると考慮されて以後、ブロック３とブロック６の両方に関連したデータは、リプライに含められてもよい。あるいは、どちらも使われなくてもよい。また、アグレッシブパラメータは、予測するために、０．５の確率よりも高く要求される。
【００５８】
他の要因は、ブロック３，６のような等しくありそうなブロック予測の間で、“ブレーキング  タイ（breaking  a  tie）”において考慮することができる。そして、それは図７Ａのブロック８に続くと予測される。ハイ−オーダ予測指数（例えば、後述するように、第１−オーダ予測指数）は、ブロック７が（ブロック３がより好ましい選択であることを意味する）ブロック８の前にリクエストされたかどうかにかかわらず、又はブロック５が（ブロック６がより好ましい選択であることを意味する）ブロック８の前にリクエストされたかどうかにかかわらず、依存するタイを遮断することができる。予測ブロックのリターンリストは、全ｎ−オーダ予測、そしてとにかくｎ−オーダ予測指数が戻るベストＮ予測ブロックを使用して作られ、ランク付けされたオーダに返信される。例えば、第１−オーダ予測指数が予測ブロック３に１．０という確率を与えるが、ゼロ−オーダ予測指数が０．５という確率を与える場合、ブロック３は、特別なブロック用の確率の最大値、１．０という確率を含んでいる。
【００５９】
この例では、予測は、現在のブロックリクエストに続いてリクエストされたブロックに関して作られた。しかし、代わりの実例では、予測は、次のリクエストブロック、次々と、他の後のブロックリクエスト、又はこれらのいくつかの組合せに関して作られる。また、予測ブロックパラメータは、配列を表している。しかし、重要な情報を取り込んだどのようなデータ構造も受け入れられる。
【００６０】
図７Ｂは、別の実施形態による典型的なリクエストログ２３６及びブロックリクエストデータベース２３８を示している。この実例では、リクエストログ２３６は、オーダに関するブロックのリストを含んでいる。このブロックは、時にブロックがストリーミングクライアントによって送信されたことを意味するタイムフィールドを加えて、ストリーミングクライアントからリクエストされていた。選択肢において、タイムフィールドは、時にブロックが受信され、ログインされ、又は別な方法で処理されたことを意味してもよい。ブロックリクエストデータベース２３８は、タイムフィールドに関する予測ブロックパラメータ配列を含んでいる。そして、それは第１ブロックリクエスト及び第２ブロックリクエストが送信された時に、時差を表している。例えば、ブロック３用の予測ブロックパラメータ配列のために、タイムフィールドは、６：１８：０４である。そして、それは６時間、１８分、４秒のことを意味している。これは、リクエストログ２３６に示されているように、ブロック３とブロック５が送信されたときの間の違いである。他の例として、ブロック８用の予測ブロックパラメータ配列は、［（３，０．５，０：０５：２０），（６，０．５，５：１０：１５）］である。これは、ブロック３，６がブロック８用のリクエストに続いて等しくリクエストされそうであることを意味していると解釈することができる。しかし、タイムエントリーがあるため、ウェイトは、時間差に関連したそれ以下についてのエントリに与えられる。ストリーミングアプリケーションに対する５時間は長時間であるから、ウェイトは、（ブロック８後に約５分リクエストされた）ブロック３以上（ブロック８後約５分リクエストされた）ブロック６に与えてもよい。本当に、この実例によると、ブロック６とブロック８との間隔が非常に長いため、予測エンジンは、ブロック６，８間の予測リレーションシップがないと仮定することを選択することができる。
【００６１】
実施形態において、タイム−関連予測パラメータは、それらがあまりにハイであると、無視される。時間差がブロックリクエストを無視する結果となる閾値は、一時的なアグレッシブパラメータと称してもよい。例えば、テンポラルアグレッシブパラメータが１時間である場合、ブロック８用の予測ブロックパラメータ配列は、［（３，１．０，０：０５：２０）］のように書き直すことができる。すなわち、ブロック６に関連した値は、リクエストログ２３６によって、ブロック６がブロック８の後、１時間を超えて受信されたため、無視される。あるいは、ブロック８用の予測ブロックパラメータ配列は、［（３，０．５，０：０５：２０）］のように書き直すことができる。そして、それは基本的に同じものである。しかし、確率は、ブロック６に関連した数値が無視されたときに、再計算されない。同様に、ブロック３用の予測ブロックパラメータ配列は、［］のように書き直すことができる。その理由は、ブロック３用のブロックリクエストの１時間（この実例で、一時的なアグレッシブ閾値）以内でブロックリクエストがないからである。
【００６２】
別の実施形態において、予測エンジンは、次の予測ブロックを得るための予測エンジンを通した後に、“第１ラウンド”予測ブロックが修正された仮定の下で、予測ブロックを交換し続けることができる。次の予測ブロックの確率は、第２（３個からなるもの、など）ブロック用の予測確率を正確に得るためのオリジナル予測ブロックの確率を掛けてもよい。これは、確率がアグレッシブ閾値以下に落ちるまで続けられる。リミットは、返信された予測の最大値に配置される。互いに確率１．０を付け加えるブロックの長いチェーンの場合に、強調されるべきである。第１リクエストは、このチェーンの全ての次のブロックのリストを返信することができる。そして、それはストリーミングクライアントがその時、ストリーミングサーバでのパイプラインを維持するための“ブラスト（突風）リクエスト”で満たすことができる。
【００６３】
図７Ｃは、典型的なリクエストログ２４０及び他の実施形態によるブロックリクエストデータベース２４２を示している。図７Ｃは、図７Ｂと同様であるが、リクエストログ２４０のエントリは、ブロックリクエストに関連したストリーミングクライアントを含んでいる。この実例において、ストリーミングクライアントは、ストリーミングクライアントが関連したブロックをリクエストするために仮定される。決定という目的、予測ブロックパラメータ、与えられたストリーミングクライアント用のエントリのため、例えばクライアント１は、ストリーミングクライアントの他のエントリと比較される。それは、例えば、クライアント２がクライアント１の後しばらくリクエストするかどうかにかかわらず、異ならない。しかし、それは、クライアント１がリクエストブロック８の後にブロック３をリクエストした場合、及びクライアント２がリクエストブロック８の後にブロック３をリクエストした場合は異なる。この原則を使用して、予測パラメータは、個別のクライアントのブロックリクエストに基づいて長い間に適応することができる。算定する予測パラメータ用の原理は、図７Ｂに関連して同様に説明できるが、予測の精度は、図７Ｃのブロックリクエストデータベース２４２に示すように、多数のクライアントのブロックリクエストを考慮することによって改善することができる。
【００６４】
実施形態において、タイムは、図７Ｃに示されているように、実際に記録されない。もっと正確にいえば、タイムは、一つのブロックが予測数値に関して別のブロックに続くかどうか決めるためのフィルタとして使用される。実施形態の場合には、ブロック３用のエントリは、ブロックリクエストデータベース２４２について説明する目的のために示されているよりも、［（４，１．０，０：０７：０５）］という数値を持ったエントリ２４２−１とさらに同様であってもよい。換言すれば、この選択肢において、ブロックリクエストデータベース２４２は、ブロック５用のどのような予測データも含んでいない。同様に、ブロック４用のエントリは、空のセットとすることができ、そして、ブロック８用のエントリは、例エントリ２４２−２と同様とすることができる。確率が認められないブロックの省略されているこの選択肢は、予測目的と多分無関係なデータを省略すため、より好ましい。
【００６５】
図８Ａ及び図８Ｂは、ゼロオーダと第１オーダ予測に関して使用するためのリクエストログ及びブロックリクエストデータベースを示している。典型的な実施形態において、ストリーミングサーバは、長い間にアプリケーションをストリーミングしている間、リクエストされるブロックに基づいて、ゼロ、第１、又はより高いオーダの確率を作り上げる。図８Ａは、リクエストログ２４４及びブロックリクエストデータベース２４６を示している。ストリーミングアプリケーションに関連したどのブロックも、ストリーミングアプリケーションをストリームする際にリクエストされる確率を有している。その確率は、ストリーミングアプリケーションがすでにストリームされた回数と比較して、ストリーミングアプリケーションをストリームする際に、ブロックが何度リクエストされるかに基づいている。実例の目的のため、ストリーミングについての始めから終わりまでの一例、ストリーミングアプリケーションは、セションと称されてもよい。ギブンセションにおいて、一つ以上のコンビネーション（組合せ）内で一つ以上のブロックはリクエストされることができる。
【００６６】
セションは、ストリーミングの順序をストリーミングアプリケーションに作り直したブロックリクエストに関して考えることができる。例えば、図８Ａのログリクエスト２４４に示された第５セションにおいて、セション１は、３つのブロックリクエスト７，８，９から成り、セション２は、３つのブロックリクエスト８，３，４から成り、セション３は、３つのブロックリクエスト５，８，６から成り、セション４は、２つのブロックリクエスト８，３から成り、セション５は、２つのブロックリクエスト８，３から成る。これらの５つのセッションだけを考慮して、ブロックリクエストに関連する確率は、セションにリクエストされ、そして合計をセションの全数（この場合では５つ）で割ったブロックを何度も加えることによって決定することができる。例えば、ブロックリクエストデータベース２４６に示されるように、セション１，２，４、及び５を含んでいるブロック３は、０．８というゼロオーダの確率を有している。ブロック４，５，６及び７は、それぞれセション２，３，３及び１しか含んでいないため、どれも０．２というゼロオーダの確率を有している。ブロック８がセション１−５のそれぞれに含められているため、ブロック８は、１．０というゼロオーダ確率を有している。実施形態において、確率は、複合確率を得るために複数のユーザによってマルチプルプルセションにわたって作られる。
【００６７】
いくつかの実施形態において、高いオーダの確率を利用することは望ましい。例えば、ストリーミングアプリケーションが複数のブロックリクエストに関連した４つの異なる部屋に案内される４枚のドアに対して一つの部屋の方からスタートするというゲームプログラムである場合、４つの異なる各部屋に関連した複数のブロックは、おそらく等しく（それぞれ約２５％）てもよい。あるドアが選択されると、各ドア（これらは等しく取られない）に関連した複数のブロックのそれぞれは、約２５％でもよい。第１オーダ予測指数を使用することにより、一旦、我々は、複数の部屋の一つ用の第１ブロックリクエストを見て、その部屋用の次のブロックが１００％に近い第１オーダ確率を持って、その結果、その部屋用の複数のブロックは、予測的にダウンロードすることができる。
【００６８】
図８Ｂは、第１オーダ確率を示すことを目的としている。図８Ｂは、リクエストログ２４８及びブロックリクエストデータベース２５０を示している。第１オーダ確率を決定する時に、第１ブロックリクエストは、前後関係として使用される。換言すると、第１ブロックリクエストが作られると、第２ブロックリクエストの確率は、第２ブロックリクエストが第１ブロックリクエストに続く（又は同じセションの間で起こる）以前のセションに基づいて、確率と比較することによって計算される。第２ブロックリクエストの確率が一つのブロックの状況に基づくため、その確率は、第１オーダ確率と称してもよい。第１オーダ予測は、ゼロオーダ予測よりも正確であってもよいし、なくてもよい。そして、ゼロと第１の両方のオーダ確率は、ブロックリクエスト、予測を作る時に、個別に又は組み合わせて使用されてもよい。
【００６９】
リクエストログ２４８を与えられて、第２ブロックが第１ブロックリクエストに続いてリクエストされる確率は、一つ以上のセションに関して決定することができる。ブロックリクエストデータベース２５０は、別のブロックの状況を与えられたブロック用の第１オーダ確率を示すために構成される。ブロックリクエストデータベース２５０は、データ構造を例示すること、むしろ、典型的な目的のために、第１オーダ確立を単に例示することを意図していない。（ブロックコラム内でブロック用の）ブロックリクエストの確率は、各ブロック用の第１オーダ確率の下に示されている。例えば、ブロック３用のブロックリクエストの第１オーダ確率は、ブロック４の状況で１．０、ブロック５の状況で０、ブロック６の状況で０、ブロック７の状況で１．０、そしてブロック８の状況で０．８である。これらの確率は、次のようにして得られる。リクエストログ２４８に示されているように、ブロック５又は６がリクエストされた時に（セション３）、ブロック４は、リクエストされない。それゆえに、ブロック５又は６のいずれの状況でもブロック３用の第１オーダ確率は、０である。ブロック４又は７がリクエストされた時（それぞれセション２，１）、ブロック３はまたリクエストされる。それゆえ、ブロック４の状況でブロック３用の第１オーダの確率は、１．０である。ブロック８がリクエストされた時、（全５セション）、ブロック３は、同様に、５回中４回リクエストされる。それゆえに、ブロック８の状況でブロック３用の第１オーダ確率は、０．８である。各ブロック用の第１オーダ確率は、同様の方法で得ることができる。確率は、ブロックリクエストデータベース２５０に示されている。
【００７０】
第２及びより高いオーダの確率は、複数のブロックリクエストの状況に関して以外、図８Ｂに関して説明された同様の方法で決定することができる。
【００７１】
典型的な実施形態において、ストリーミングサーバは、ブロックが“アグレッシブをダウンロードした予測”パラメータを上回り、そして、ブロックデータそれ自体以外、ストリーミングクライアントに返信されたブロックデータ上に、これらのＩＤをピギーバックさせる確率を有することを決定するために、ゼロ又はより高いオーダの確率を使用することができる。このクライアントは、ブロックがローカルファクタに基づいて予測的にダウンロードすることをその時、決定することができる。ローカルファクタは、クライアントシステム負荷、ローカルディスクキャッシュのコンテンツ、バンド幅、メモリ、又は他の要因を含むことができる。
【００７２】
ある特定の実施形態において、ブロックリクエストがローカルディスクキャッシュによって“フィルタにかけられた”ため、全ての入力ブロックリクエストをリクエストログ内に取り入れることは可能でないということに注意を払うべきである。これは、結果として予測指数を狂わせるローカルディスクキャッシュにないブロック用のこれらのブロックリクエストだけを含んでいるリクエストログになる。それゆえに、実施形態において、ストリーミングサーバは、サーバが集められた予測データに関与するストリーミングサーバに指示を出すことができる。この場合、ストリーミングクライアントは、ストリーミングサーバへの完全なブロックリクエスト統計値に関するセパレートデータストリームを送信する。この例では、このセパレートデータストリームは、リクエストが上手く予測されたかストリーミングクライアントのローカルキャッシュにストアされているかに関係なく、アプリケーションによって作られた実際のブロックリクエストを含むことができる。
【００７３】
図９は、予測パラメータをアップデートする典型的な方法を示している。フローチャートは、予測データを収集することに関与するストリーミングクライアントを決めるモジュール２５２でスタートする。このリクエストは、トークンファイルに含められていてもよいし、いなくてもよい。リクエストは、ストリーミングクライアントがアプリケーションのストリーミングをリクエストするときに、ストリーミングクライアントを送信されてもよい。モジュール２５２後、フローチャートは、２つのパス（２５４−１と２５４−２）に沿って続く。モジュール２５４は、同時に発生するか、または一方が発生した後、他方が発生してもよい。
【００７４】
フローチャートは、ブロックリクエストを受信するモジュール２５４−１に続く。ストリーミングサーバは、ストリーミングクライアントからのブロックリクエストを受信することができる。フローチャートは、もしあれば、予測を含んでいるブロックリクエストに関連したデータを送信するモジュール２５６−１に続く。フローチャートは、決定ポイント２５８−１に続く。そこにおいて、セションが終了しているかどうかが決定される。セションが終了していなければ、フローチャートは、別のブロックリクエストのためのモジュール２５４−１から続く。一方、セションが終了していると、フローチャートは、モジュール２５４−１〜２５８−１で終了する。
【００７５】
フローチャートは、ローカルディスクキャッシュにストアされたブロックようのブロックリクエストを含んでいるブロックリクエスト統計値を受信するモジュール２５４−２に続く。モジュール２５４−２は、モジュール２５８−１が終了した後に、開始されたり、されなかったりする。モジュール２５４−２は、モジュール２５８−１が終了した後に、続いたり、続かなかったりする。フローチャートは、ブロックリクエスト統計値を使用する予測パラメータをアップデートすることに関するモジュール２５６−２に続く。予測パラメータは、予測を提供するためのモジュール２５６−１で使用されてもよい。フローチャートは、セションが終了しているかどうかを決定する決定ポイント２５８−２に続く。セションが終了していなければ、フローチャートは、より多くのモジュール２５４−２からブロックリクエスト統計値に続く。一方、セションが終了していると、フローチャートは、モジュール２５４−２〜２５８−２で終了する。
【００７６】
別の実施形態において、ストリーミングクライアントは、ストリーミングクライアントが予測ブロックデータＩＤを受信することに関与しているストリーミングサーバに指示することができる。そして、ストリーミングサーバは、前記のようにＩＤをピギーバックする。図１０は、ストリーミングクライアントに予測を提供する典型的な方法を示している。このフローチャートは、ストリーミングクライアントが予測ブロックデータＩＤを受信することに関与する通知を受信するモジュール２６０で始まる。ストリーミングクライアントは、ストリーミングサーバからアプリケーションのストリーミングをリクエストするときに通知を送信することができる。フローチャートは、ブロックリクエストを受信するモジュール２６２に続く。ストリーミングサーバは、ストリーミングクライアントからブロックリクエストを受信することができる。フローチャートは、予測を利用できるかどうかを決定する決定ポイント２６４に続く。予測が利用できる場合（２６４−Ｙ）、フローチャートは、ブロックリクエストへのリプライの一つ以上の予測ブロックＩＤにピギーバックするモジュール２６６と、ブロックリクエストへのリプライに送信するモジュール２６８に続く。他方、予測が利用できない場合（２６４−Ｎ）、フローチャートは、（予測ブロックＩＤでない）ブロックリクエストへリプライを送信するモジュール２６８へ続く。いずれにしても、フローチャートは、セションが終了するかどうかを決定する決定ポイント２７０に続く。セションが終了していない場合（２７０−Ｎ）、フローチャートは、前記のように、モジュール２６２に続く。他方、セションが終了している場合（２７０−Ｙ）、フローチャートは終了する。
【００７７】
別の実施形態において、ストリーミングサーバは、クライアントが予測計算の全てを処理することができるため、最初のトークンファイルとともにクライアントへブロックリクエストデータベースを送信することができる。図１１は、ストリーミングクライアントに予測機能を提供するための典型的な方法についてのフローチャートを示している。フローチャートは、ストリーミングチャートにブロックリクエストデータベースを送信するモジュール２７２から開始する。ストリーミングクライアントは、ストリーミングサーバからのブロックリクエストデータベースをリクエストしてもよいししなくてもよい。ブロックリクエストデータベースは、アプリケーションのストリーミング用のリクエストに応答して送信することができる。フローチャートは、ストリーミングクライアントから予測ブロックリクエストを含んでいる受信ブロックリクエストのモジュール２７４に続く。ストリーミングクライアントは、ブロックリクエストデータベースを有しているため、ストリーミングクライアントは、前もってリクエストしなければならないかについて予測することが可能である。ストリーミングサーバは、この場合、ＩＤピギーバックする必要がない。というのは、ストリーミングクライアントは、直接、決定し、そしてブロックをリクエストするからである。フローチャートは、ストリーミングクライアントにブロックリクエストと関連したデータを送信するモジュール２７６で終了する。ストリーミングクライアントは、ストリーミングサーバに実際のブロックリクエストパターンに関する代替のデータを送信してもよいし、しなくてもよい。モジュール２７４，２７６は、間歇的に又は同時に存在することができる。
【００７８】
別の実施形態において、ストリーミングクライアントは、ローカルに予測データを収集することができ、そして、セッションのエンドでストリーミングサーバへデータを送信することができる。図１２は、ストリーミングクライアントから予測データを受信するための典型的な方法についてのフローチャートを示している。このフローチャートは、ブロックリクエストを受信するモジュール２７８から開始する。ブロックリクエストは、ストリーミングクライアントからであってもよい。フローチャートは、たとえストリーミングクライアントに予測を含んでいても、ブロックリクエストを送信するモジュール２８０に続く。このフローチャートは、セションが終了したかどうかを決定する決定ポイント２８２に続く。セションが終了していない場合（２８２−Ｎ）、フローチャートは、上記のようにモジュール２７８に続く。他方、セションが終了している場合（２８２−Ｙ）、フローチャートは、ストリーミングクライアントから予測データを受信するモジュール２８４に続く。予測データは、リクエストログ、ブロックリクエスト履歴、又は、ブロックリクエストデータから生じた一つ以上のパラメータを含むことができる。フローチャートは、予測データを使用しているブロックリクエストデータベースをアップデートするモジュール２８６で終了する。このようにストリーミングサーバは、どのセションにも応答してブロックリクエストデータベースを適応させることができる。
【００７９】
別の実施形態において、ストリーミングサーバは、“ラン（runs）”の情報を得続けるブロックリクエストデータベースを継続することができる。ランは、ブロックリクエストが時間内に間隔を置いてきっちりと生じるためのブロックの集合である。例えば、ブロックのシーケンスが、このシーケンスで前記のブロックリクエストについて仮にいえば０．５秒以内にリクエストされた場合、ブロックのシーケンスは、ランと呼んでもよい。ランは、ブロックごとでなくランレベルについてのレコーディング確率によってメモリ資源を能率的に利用するために使用することができる。ランは、予測ダウンロードの量を減らすためにも使用することができる。例えば、レベルベースのゲームのため、ユーザは、第１ブロックをダウンロードすることができる。そして、ゲームの残りの部分は、各レベルで予測的にダウンロードされる。というのは、ダウンロードの各レベルの確率は、この例の目的のためであればほぼ１００％だからである。
【００８０】
ランの情報を得続けることにより、第１レベルがダウンロードされた後、予測ダウンロードは、第２レベル用のブロックのスタートまで、“遮断（shut  off）することができる。例えば、ランを起動させるか送信するランの始めにブロックが検出されば場合、ランの残りの間のブロックＩＤは、チェーンがそれらをリクエストするストリーミングクライアントに送信される。しかし、これらの次のブロックリクエストは、更なるランも起動しない。そのため、予測ダウンロードは、ランの中央のブロックに別のランの起動局番のように作用させない；後続の予測は、ランの中央から作られる。
【００８１】
図１３は、ランを含んでいるブロックリクエストデータベースを維持する説明を図示している。図１３は、リクエストログ２８８及びブロックリクエストデータベース２９０を示している。ブロック及びランに関連したパラメータは、例示されている点に焦点を合わせるために、ブロックリクエストデータベース２９０から省略されている。省略されたパラメータは、将来のブロックリクエスト（例えば第１オーダ確率）の予測を容易にするという目的のため、リクエストログから生じたどのようなパラメータであってもよい。リクエストログ２８８は、２つのセション、セション１及びセション２を含んでいる。セション１において、ブロックのシリーズは、連続して受信される。実例の目的のため、ランパラメータ（図示せず）は、１秒にセットされる。ブロックが相互に１秒ないで受信された場合、それらは、ランの一部とみなされてもよい。図１３の実例において、ブロック１７−２５は、相互に１秒以内に受信され、ブロック１５，１６は、ブロック１７−２５のそれぞれから１秒以上受信される。パラメータがランであるブロックリクエストデータベース２９０、ブロック１７−２５に包含したものを得ると、ブロックリクエストデータベース２９０−１に図示されているように一緒にまとめることができる。セション２において、ブロックの異なるシリーズは、連続して受信される。ブロック１７−１９，２６−３０は、互いに１秒以内に受信され、この実例において、ランとみなされる。このランは、ブロックリクエストデータベース２９０−２に図示したように、互いにまとめることができる。ブロックリクエストデータベース２９０−１及びブロックリクエストデータベース２９０−２は、結合される。その理由は、ラン１７−２５は、もはや間違いないからであり（すなわち、代わりのランは、１７−１９，２６−３０であることができる）、ランは、ブロックリクエストデータベース２９０で図示されるように、二つの異なる欄に分解されなければならない。このように、ブロックが一つのランのようにまとめられるため、より少しのデータエントリ（各リクエストブロック用の一つ）は、必要である。
【００８２】
ランがブロックリクエストデータベースにストアされるとき、ランの各ブロックは、必要とされる個々の予測なしに連続してダウンロードされる。別の実施形態において、ランの各連続したブロックは、１．０という効果的な確率を与えることができる。そして、それはアグレッシブ閾値（閾値がある予測を参酌すると仮定して）に関係なく、有利な予測処理を保証する。まだ、もう一つの選択肢において、ストリーミングクライアントは、ラン用の識別子を受信することができ、そして連続したブロックを識別するための識別子を使用するラン内で連続したブロックを要求することができる。
【００８３】
この発明が一定の実施形態において説明されたが、技術分野において、提示した発明の工夫に富んだ範囲内で一定の変更態様、置換、そして同等物が認められる。添付の特許請求の範囲は、本発明の本当の意志及び範囲内で、全てのこのような変更態様、置換、そして同等物を含んでいる；本発明は特許請求の範囲によってのみ制限される。
【図面の簡単な説明】
【００８４】
【図１】典型的な実施形態に用いるネットワークシステムを示している。
【図２】図１のシステムに用いるコンピュータシステムを示している。
【図３】図２のコンピュータシステムの部分と図１のシステムの構成要素を示している。
【図４】実施形態による予測ストリーミング用の典型的な方法のフローチャートである。
【図５】実施形態による予測ストリーミング用の典型的な方法のフローチャートである。
【図６】実施形態によるストリーミングデータを提供するためのシステム６００の概念上の図及びブロックリクエストに応じて予測ブロックを識別するための図を示している。
【図７Ａ】実施形態による典型的なリクエストログ及びブロックリクエストデータベースを示している。
【図７Ｂ】実施形態による典型的なリクエストログ及びブロックリクエストデータベースを示している。
【図７Ｃ】実施形態による典型的なリクエストログ及びブロックリクエストデータベースを示している。
【図８Ａ】実施形態による典型的なリクエストログ及びブロックリクエストデータベースを示している。
【図８Ｂ】実施形態による典型的なリクエストログ及びブロックリクエストデータベースを示している。
【図９】別の実施形態による典型的な方法を示している。
【図１０】別の実施形態による典型的な方法を示している。
【図１１】別の実施形態による典型的な方法を示している。
【図１２】別の実施形態による典型的な方法を示している。
【図１３】実施形態による典型的なログリクエスト及びブロックリクエストデータベースを示している。
【図１】
2008518508.tif 000003
【図２】
2008518508.tif 000004
【図３】
2008518508.tif 000005
【図４】
2008518508.tif 000006
【図５】
2008518508.tif 000007
【図６】
2008518508.tif 000008
【図７Ａ】
2008518508.tif 000009
【図７Ｂ】
2008518508.tif 000010
【図７Ｃ】
2008518508.tif 000011
【図８Ａ】
2008518508.tif 000012
【図８Ｂ】
2008518508.tif 000013
【図９】
2008518508.tif 000014
【図１０】
2008518508.tif 000015
【図１１】
2008518508.tif 000016
【図１２】
2008518508.tif 000017
【図１３】
2008518508.tif 000018
【国際調査報告】
2008518508.tif 000019