(57)【要約】  【課題】  ウェブ・タイプ・オブジェクトのインテリジェント・スケジューリングを実現する。  【解決手段】  クローズド・ウェブ・サイトを形成し、ユーザに配信され、前記ユーザによって前記クローズド・ウェブ・サイトから選択される確率が最も高いウェブ・オブジェクトの予測判定に基づいて記憶されるウェブ・オブジェクトの記憶媒体への記憶を制御する方法であって、前記クローズド・ウェブ・サイトを形成する複数のウェブ・オブジェクトを識別するステップと、前記クローズド・ウェブ・サイトのウェブ・ツリーを判定するステップと、前記ウェブ・オブジェクト又は前記ウェブ・ツリーに関連する１つ又は複数のパラメータを識別するステップと、前記ウェブ・オブジェクトが選択される確率を各ウェブ・オブジェクトの前記１つ又は複数のパラメータから判定して、選択が見込まれるウェブ・オブジェクト・セットを生成するステップと、前記選択が見込まれるウェブ・オブジェクトをそれぞれの確率に従って順序付けするステップと、最も確率が高いウェブ・オブジェクトが最初に記憶されるように、選択が見込まれるオブジェクト・セットに由来する前記ウェブ・オブジェクトをそれぞれに関する確率順に記憶するステップと、前記記憶媒体内に使用可能な容量が存在する限り前記記憶するステップを継続するステップと、を含む方法が提供される。  【選択図】  図１２
2009541877.tif 000002
【特許請求の範囲】
【請求項１】
クローズド・ウェブ・サイトを形成し、ユーザに配信され、前記ユーザによって前記クローズド・ウェブ・サイトから選択される確率が最も高いウェブ・オブジェクトの予測判定に基づいて記憶されるウェブ・オブジェクトの記憶媒体への記憶を制御する方法であって、
前記クローズド・ウェブ・サイトを形成する複数のウェブ・オブジェクトを識別するステップと、
前記クローズド・ウェブ・サイトのウェブ・ツリーを判定するステップと、
前記又は各ウェブ・オブジェクト又は前記ウェブ・ツリーに関連する１つ又は複数のパラメータを識別するステップと、
前記ウェブ・オブジェクトが選択される確率を各ウェブ・オブジェクトの前記１つ又は複数のパラメータから判定して、選択が見込まれるウェブ・オブジェクト・セットを生成するステップと、
前記選択が見込まれるウェブ・オブジェクトをそれぞれの確率に従って順序付けするステップと、
最も確率が高いウェブ・オブジェクトが最初に記憶されるように、前記選択が見込まれるウェブ・オブジェクト・セットに由来する前記ウェブ・オブジェクトをそれぞれに関する確率順に記憶するステップと、
前記記憶媒体内に使用可能な容量が存在する限り前記記憶するステップを継続するステップと、
を含む方法。
【請求項２】
選択される各ウェブ・オブジェクトの前記確率を判定する前記ステップは、ステップ数が多いウェブ・オブジェクトよりもステップ数が少ないウェブ・オブジェクトの方が選択される確率が高くなるように、前記クローズド・ウェブ・サイト内のルート・ウェブ・オブジェクトから各ウェブ・オブジェクトまでのステップ数を決定するステップを含む、請求項１に記載の方法。
【請求項３】
選択される各ウェブ・オブジェクトの前記確率を判定する前記ステップは、サイズが大きいウェブ・オブジェクトよりもサイズが小さいウェブ・オブジェクトの方が高い確率を有するように、各ウェブ・オブジェクトのサイズを決定するステップを含む、請求項１又は２に記載の方法。
【請求項４】
選択される各ウェブ・オブジェクトの前記確率を判定する前記ステップは、前記又は各ウェブ・オブジェクトの隣接ウェブ・オブジェクト数を判定するステップを含む、請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
選択される各ウェブ・オブジェクトの前記確率を判定する前記ステップは、前記又は各ウェブ・オブジェクト内の他のウェブ・オブジェクトへのリンク数を判定するステップを含む、請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
前記ユーザがウェブ・オブジェクトを選択した場合に、前記ユーザの後の選択確率の判定に使用される新しいパラメータ・セットが判定されるように、パラメータの前記判定を更新するステップを更に含む請求項１乃至５のいずれか一項に記載の方法。
【請求項７】
前記後の選択確率に基づいて、後に選択される確率が最も低い前記ウェブ・オブジェクトが最初に除去されるように、前記記憶媒体からウェブ・オブジェクトを除去するステップを更に含む請求項６に記載の方法。
【請求項８】
前記記憶媒体内に優先順位の高い新しいウェブ・オブジェクト用の十分なスペースができるまで、前記記憶媒体から前記ウェブ・オブジェクトを除去するステップを更に含む請求項７に記載の方法。
【請求項９】
前記ユーザが選択を行う度に前記更新するステップを繰り返すステップを更に含む請求項６又は７に記載の方法。
【請求項１０】
前記確率をそのテーブルに基づいて判定することが可能となるようなパラメータ・テーブルを各ウェブ・オブジェクト毎に形成するステップを更に含む請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
請求項１乃至１０のいずれか一項に記載の方法に従って放送規格チャンネルを介して伝送されるウェブ・オブジェクトを、メモリ（８９０）を有する遠隔モバイル・デバイス（１０４）において閲覧する方法であって、
当該ウェブ・オブジェクトを選択する複数のユーザを判定する１つ又は複数のパラメータが含まれるクローズド・ウェブ・サイトの一部又は全部を形成する複数のウェブ・オブジェクトを受信するステップと、
前記優先順位に従って、最も確率が高い前記ウェブ・オブジェクトが最初に記憶されるように前記ウェブ・オブジェクトを前記メモリに記憶するステップと、
閲覧すべきウェブ・オブジェクトを選択し、それによって前記１つ又は複数のパラメータと、前記又は各ウェブ・オブジェクトが後に選択される新しい確率とを更新するステップと、
前記新しい優先順位に基づいて、新しい確率が最も高い前記ウェブ・オブジェクトが最初に記憶されるように、メモリに記憶される前記ウェブ・オブジェクトを更新するステップと、
前記選択するステップ及び前記更新するステップを必要に応じて繰り返すステップと、
を含む方法。
【請求項１２】
請求項１乃至１０のいずれか一項に記載の方法の各ステップを実行するように適合された手段を備えるシステム。
【請求項１３】
請求項１乃至１１のいずれか一項に記載の方法の各ステップを実行するように適合された手段を備える装置。
【請求項１４】
それ自体がコンピュータ・システム上で実行されたときに請求項１乃至１０のいずれか一項に記載の方法の各ステップを実行する命令を備えるコンピュータ・プログラム。
【請求項１５】
それ自体がコンピュータ・システム上で実行されたときに請求項１１に記載の方法の各ステップを実行する命令を備えるコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は放送情報をキャッシュする方法及び装置に関するものであり、具体的には、必ずしもそれだけに限定されるわけではないが、ウェブ情報の形で提示される情報をキャッシュする方法及び装置に関するものである。
【背景技術】
【０００２】
モバイル・テレビジョン（例えば携帯用テレビジョン）環境では現在２つの補完的な放送技法が存在する。モバイルＴＶ技術は、音声電話及びインターネット・アクセスだけでなく、高品質の地上波デジタル放送を単一の無線デバイスで楽しむ機会を顧客に提供している。携帯機器向けデジタル・ビデオ放送（ＤＶＢ‐Ｈ）は、インターネット・プロトコル（ＩＰ）・データ・キャストを放送する。ＤＶＢ‐Ｈは、計算リソース及びバッテリ・リソースに制約のあるデバイス向けに最適化されたＩＰベースのメカニズムを使用して、任意のタイプのデジタル・コンテンツ及びサービスを配信するエンド・ツー・エンドの放送システムである。
【０００３】
ＩＰデータ・キャスト（ＩＰＤＣ）に固有の部分は、双方向モバイル・セルラーの対話型部分と組み合わせることが可能な単方向ＤＶＢ放送パスを備えている点にある。つまり、ＩＰＤＣは、放送メディア・サービスと電気通信需要とを収束させ得る重要なプラットフォームとなっている。
【０００４】
ＩＰＤＣで使用されるファイル配信方法は、ＦＬＵＴＥプロトコルに基づいている。ＦＬＵＴＥ（単方向トランスポートを利用したファイル配信）は、任意のタイプのデータ（例えば、オーディオ、ビデオ、バイナリ、静止画、テキスト、ＥＳＧキャリッジ・リターン、メタデータ等）を含むことが可能なファイルの形でコンテンツを配信する。
【０００５】
ウェブ・サーバには、例えばＷｉＦｉ（Ｒ）を使用したモバイル機器を使用してアクセスすることができる。しかしながら、ＷｉＦｉの範囲は多くの場合非常に限られているため、一般にはプライベート・エリアや空港等での使用にとどまっている。一方、ＧＰＲＳ、ＥＤＧＥ、ＵＭＴＳのような２．５Ｇ又は３Ｇ通信手段を使用してウェブ・サーバに接続することもできる。このような接続は、高額な入会金を払う必要が生じる可能性もあることから専門家によって使用される傾向にあり、一般の視聴者にとっては必ずしも魅力的な選択肢ではない。モバイル機器上でＴＶを放送するための新しい規格が登場している（例えばＤＶＢ‐Ｈ）。これらの規格のうちのいくつかは、オブジェクト伝送手段を定義している。
【０００６】
図１は、既知のモバイル・インターネット・インフラストラクチャ１００と、別個のデジタル・ビデオ放送インフラストラクチャ１０２とを示している。モバイル・ユーザは、モバイル・デバイス１０４を使用してＴＶチャンネルとインターネット・サイトの両方にアクセスすることができる。ＴＶチャンネルは、例えば欧州ではＤＶＢ‐Ｈを使用して放送され得る。ビデオ・ソース１０６は、ＤＶＢ‐Ｈエンカプスレータ、ＤＶＢ‐Ｈストリーマ又は変調装置１１２、及び増幅器１１４を含むことが可能なＤＶＢ‐Ｈヘッド・エンド１０８を使用して放送される。ＤＶＢ‐Ｈヘッド・エンドからはＶＨＦ／ＵＨＦ信号１１６が出力され、この信号がモバイル・デバイス１０４によって受信される。モバイル・デバイスは、ＤＶＢ‐Ｈ処理対応のＧＳＭ電話であってもＰＤＡであってもよい。パラレル・モードにおいて、モバイル・デバイス１０４は従来のウェブ・ブラウザ機能をサポートすることができ、例えばＧＰＲＳ／ＵＭＴＳネットワーク１２２に属するアクセス・ポイント１２０からの信号１１８を受信することができる。ＧＰＲＳ／ＵＭＴＳネットワーク１２２は、電話会社のゲートウェイ１２６を利用してインターネット１２４にアクセスすることができる。インターネット１２４は、ウェブ・サーバ１２８にアクセスしてユーザに送信されるコンテンツを取得することができる。ウェブ・サーバ１２８には、例えばＰＳＴＮやＡＤＳＬ等の有線回線を介して接続され得るコンピュータ１３０のような非モバイル・デバイスを利用してアクセスすることもできる。
【０００７】
上記の現行のシステム及び方法で直面するいくつかの課題を以下に示す。まず、高額な加入料が必要となることに加えて、インターネットに到達可能な通信スタックと、放送テレビジョンを受信することが可能な別個の通信スタックとをサポートすることが可能な無線機器が必要となることが挙げられる。また、いくつかのエリアではインターネット及びＴＶ放送の範囲が必ずしも一致しないという課題も存在し、例えばあるエリアは１つの範囲を有し、あるエリアは別の範囲を有することがあり、それらの両方の範囲を有するエリアもあれば、いずれの範囲も有さないエリアも存在する可能性がある。
【０００８】
本出願人の同時係属出願（米国特許出願第１１／７６２３０３号（ＦＲ０９  ２００６  ００２９））には、同一のメディア・チャンネルを介してウェブ・オブジェクト及びビデオ・メディアを転送し受信する方法及び装置が開示されている。この同時係属出願ではウェブ・オブジェクトのスケジューリング問題について論じているが、本発明は、該出願の追加的な発明の特徴に関するものである。
【特許文献１】本出願人の同時係属出願である米国特許出願第１１／７６２３０３号（ＦＲ０９  ２００６  ００２９）
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明の一目的は、従来技術の放送方法及びシステムに関連する課題のうちの少なくともいくつかを解決することである。
【００１０】
本発明の別の目的は、新しい放送伝送手段を使用してＤＶＢ‐Ｈタイプ・オブジェクトとウェブ・タイプ・オブジェクトの両方を同一のメディアを介して転送し、ウェブ・タイプ・オブジェクトのインテリジェント・スケジューリングを実現することである。
【００１１】
本発明の他の目的は、ウェブ・サイトをモバイル機器に放送する方法であって、プリファレンスを示すリターン・チャンネル（ｒｅｔｕｒｎ  ｃｈａｎｎｅｌ）手段を必要とせずに、予測を使用してスケジューリングを支援する方法を提供することである。
【課題を解決するための手段】
【００１２】
本発明は、添付の特許請求の範囲で定義される方法及びシステムを対象とする。
【００１３】
より具体的には、本発明は、クローズド・ウェブ・サイトを形成し、ユーザに配信され、前記ユーザによって前記クローズド・ウェブ・サイトから選択される確率が最も高いウェブ・オブジェクトの予測判定に基づいて記憶されるウェブ・オブジェクトの記憶媒体への記憶を制御する方法であって、前記クローズド・ウェブ・サイトを形成する複数のウェブ・オブジェクトを識別するステップと、前記クローズド・ウェブ・サイトのウェブ・ツリーを判定するステップと、前記又は各ウェブ・オブジェクト又は前記ウェブ・ツリーに関連する１つ又は複数のパラメータを識別するステップと、前記ウェブ・オブジェクトが選択される確率を各ウェブ・オブジェクトの前記１つ又は複数のパラメータから判定して、選択が見込まれるウェブ・オブジェクト・セットを生成するステップと、前記選択が見込まれるウェブ・オブジェクトをそれぞれの確率に従って順序付けするステップと、最も確率が高いウェブ・オブジェクトが最初に記憶されるように、選択が見込まれるオブジェクト・セットに由来する前記ウェブ・オブジェクトをそれぞれに関する確率順に記憶するステップと、前記記憶媒体内に使用可能な容量が存在する限り前記記憶するステップを継続するステップと、を含む方法を開示する。
【００１４】
本発明の他の実施形態は、添付の特許請求範囲の従属請求項に記載されている。
【００１５】
本発明は、ユーザによって次に閲覧され得る対象に関する確率及び予測に関係する頻度で周期的に放送を行うスケジューラに利点を有する。ウェブ・オブジェクトのパラメータ（ルート・オブジェクトからのホップ又はジャンプ数やウェブ・オブジェクトのリンク情報等）を更新することにより、リターン・チャンネルならびにリターン・チャンネルに関するコスト及び複雑さを伴うことなく、後続のウェブ・オブジェクトを予測し記憶することが可能となる。
【００１６】
別の利点としては、ウェブ・オブジェクトの受信を可能にする機能が挙げられる。この新しい機能はサービスとして追加することができ、従来の任意のウェブ・ブラウザからウェブ・プロキシとして閲覧される。あるオブジェクトがウェブ・ブラウザから要求されたときは、このプロキシが当該要求を傍受し、前記オブジェクトの受信まで待機する。前記オブジェクトの受信がエラーなく完了したときは、前記オブジェクトが直ちにウェブ・ブラウザに戻され、その後ユーザに引き渡される。それ故、このプロキシは、現在閲覧されているオブジェクトに基づいて、ユーザによって選択される確率が最も高いウェブ・オブジェクトを記憶する。
【００１７】
他の利点としては、現在表示されているページから事前定義された最大ホップ・カウント位置に所在するすべてのページをキャッシュすることにより、上記のプロキシ機能を拡張することが挙げられる。これらのオブジェクトは隣接ウェブ・オブジェクトと呼ばれることもある。キャッシュ・サイズは限られているので、隣接オブジェクト・グループの一部を構成しないウェブ・オブジェクトは、必要に応じて削除することができる。
【００１８】
以下では例示として、添付図面を参照しながら本発明について説明する。
【発明を実施するための最良の形態】
【００１９】
図２は、本発明に係るウェブ放送ゲートウェイ２００を含むウェブ・キャスト及びデジタル・ビデオ放送インフラストラクチャを示している。ウェブ放送ゲートウェイ２００は、ウェブ・サーバ１２８とデジタル・ビデオ放送環境との間のリンクである。ウェブ放送ゲートウェイ２００は、ＴＶ放送機能だけを有するモバイル・ユーザがウェブ・サイトにアクセスし、音楽、ビデオ、画像等のウェブ・オブジェクトにアクセスすることを可能にする。本明細書で使用する「ウェブ・オブジェクト」という用語は、ウェブ上で発見されるすべてのタイプの情報を含むものとする。ウェブ放送ゲートウェイは、いわゆる「クローズド・ウェブ・サイト」を形成するオブジェクトを放送するのに使用される。「クローズド・ウェブ・サイト」という用語は、当該サイトのウェブ・ページ上で発見されるリンクが当該ウェブ・サイトのオブジェクトを参照しているウェブ・サイトを定義する。換言すれば、クローズド・ウェブ・サイトのウェブ・ページ内では「外部サイト」の参照が発見されることはない。これについては以下でより詳細に説明する。
【００２０】
クローズド・ウェブ・サイトは、任意の適切な手法で生成される。クローズド・ウェブ・サイトが形成されると、当該クローズド・ウェブ・サイトは、以下で説明するように送信機から放送される。
【００２１】
本発明の好ましい一実施形態では、ウェブ放送ゲートウェイは４つの主要な要素を含む。ウェブ放送ゲートウェイの１つ目の要素は、クローズド・ウェブ・サイトを周期的に探索して当該サイトに属する各オブジェクトを識別するウェブ・サイト・ポンプ（ｗｅｂｓｉｔｅ  ｐｕｍｐ）２１０である。発見された各オブジェクト毎に一意の参照である一意のオブジェクト識別子（ｕｎｉｑｕｅ  ｏｂｊｅｃｔ  ｉｄｅｎｔｉｆｉｅｒ：ＯＩＤ）が決定され、クローズド・ウェブ・サイトを構成するすべてのオブジェクトを含むテーブルにレコードが追加され又はレコードの更新が行われる。このテーブルは、コンテンツ及びクローズド・ウェブ・サイトを形成するオブジェクト間の関係が判定される問い合わせフェーズ中に形成される。このテーブルには、問い合わせフェーズが終了した時点で完了のマークを付けることができる。
【００２２】
ウェブ放送ゲートウェイの２つ目の要素は、ウェブ・ページ（ＨＴＭＬ、ＷＭＬ等）内で発見されたＵＲＬを当該ウェブ・ページ又はオブジェクトに関するＯＩＤ及び任意選択でメタデータを含む新しいＵＲＬに修正するハイパーテキスト言語トランスレータ２２０である。ハイパーテキスト言語トランスレータ２２０については以下でより詳細に説明する。
【００２３】
ウェブ放送ゲートウェイの３つ目の要素は、クローズド・ウェブ・サイトのすべてのオブジェクトをスキャンして、任意のオブジェクトと、当該クローズド・ウェブ・サイト内に含まれる他のすべてのオブジェクトとの間に介在するホップ数を計算するサイト・アナライザ２３０である。
【００２４】
ウェブ放送ゲートウェイの４つ目の要素は、スケジューラ２４０である。スケジューラ２４０は、ウェブ・サイト・ポンプ２１０によって作成され、サイト・アナライザ２３０によって修正されるテーブルを利用するカルーセル（ｃａｒｒｏｕｓｅｌ）の形をとることができる。スケジューラ２４０は、各オブジェクトに関連する加重（ｗｅｉｇｈｔｉｎｇ）を含む。加重は、該当するオブジェクトに対する他のクローズド・ウェブ・サイトのページ又はオブジェクト内の参照数、ルート・ページから当該オブジェクトに到達するまでの「ホップ」数、及び当該オブジェクトのサイズに基づくものである。このような加重を使用してカルーセルの入力が行われる。識別され記憶されたウェブ・オブジェクトは、以下でより詳細に説明するように、ＦＬＵＴＥプロトコルを使用してユーザに配信される。
【００２５】
ウェブ・オブジェクトは、ウェブ・サーバ１２８からダウンロードされた後ウェブ放送ゲートウェイ２００によって処理され記憶される。図１に示されるモバイル・インターネット構造、即ち、電話会社のゲートウェイ、ＧＰＲＳ／ＵＭＴＳ、及びＧＳＭアクセス・ポイントはここでも維持される。しかしながら、これらはウェブ・オブジェクトのダウンロードでは使用されない。その代わりに、以下でより詳細に説明するように、ウェブ放送ゲートウェイ２００（カルーセル・スケジューラ２４０）からの出力が、ＤＶＢ‐Ｈカプセル化モジュールにおいてビデオ・ソースの出力と組み合わせられる。ＤＶＢ‐Ｈ放送は、あるバーストでビデオを放送し他のバーストでデータを放送する、バースト単位で行われる。カルーセル・スケジューラ２４０は、各オブジェクトをそれぞれの加重に従って送信する。これらの加重は、クローズド・ウェブ・サイト内のオブジェクトの位置に依存する。例えば、ルート・ページは、カルーセルが回転する度に何回も送信される可能性があるが、クローズド・ウェブ・サイト内の最低レベルのオブジェクトは、各回転中に１回又は２回しか送信されない可能性がある。同様に、中間レベルのオブジェクトは、カルーセルの各回転中に数回送信される可能性がある。
【００２６】
そのため、本発明によれば、モバイル・デバイス１０４は、ビデオ及びウェブ・オブジェクトに関するＤＶＢ‐Ｈ放送ヘッド・エンドからの送信物だけを受信する。例示のＧＰＲＳ又はＵＭＴＳ向けの他の技術形態では、リンク１１８を介した他の接続を使用することもできる。しかしながら、本発明ではそれらの他の接続の詳細に説明は省略する。
【００２７】
次に図３を参照して、「クローズド・ウェブ・サイト」についてより詳細に説明する。図３は、クローズド・ウェブ・サイト３００内のウェブ・オブジェクト及び各ウェブ・オブジェクト間の関係を示している。クローズド・ウェブ・サイトとは、他のサイトを参照する外部ウェブ・サイトへの参照が存在しないサイトを指す。換言すれば、サイト内のルート・ページから最も遠いウェブ・オブジェクトに到達するまでのホップ数が事前定義された値に制限される。事前定義される値は、記憶容量、ツリーの性質（即ち、各ホップ毎のページ数）、個々のページ・サイズ等に応じて異なる可能性がある。外部参照（即ち、クローズド・ウェブ・サイトの外部）が存在する場合にも、それらの外部参照を無視することができ、又は外部参照が使用可能でないことをユーザに示す適切なメッセージを生成することができ、あるいはその両方を行うことができる。クローズド・ウェブ・サイト３００において、ルート・ページ３１０（Ｉｎｄｅｘ．ｈｔｍ）は４つのリンクを有する。そのうちの３つは、他のウェブ・ページ上に所在するｐａｇｅ１．ｈｔｍ  ３５０上のリンク３２０、ｐａｇｅ２．ｈｔｍ上のリンク３３０、及びｐａｇｅ３．ｈｔｍ上のリンク３４０である。４つ目のリンクは画像３８０（「Ｂｋｇｒｎｄ．ｇｉｆ」）を参照している。一方、第２レベル上の各ページ（ｐａｇｅ１、ｐａｇｅ２、及びｐａｇｅ３）は、ルート・ページ３１０から２ホップ先の第３レベルに所在するページへのリンクを有する。ｐａｇｅ２．ｈｔｍは、ルート・ページ（ｉｎｄｅｘ．ｈｔｍ）３１０内及びｐａｇｅ１．ｈｔｍ  ３５０内で２回参照されており、異なるルートから到達することができる。
【００２８】
本例では、第３レベルの各ページ（ｐａｇｅ１１、１２、２１、２２、３１、及び３２）が最終レベルとなる。他の状況では、ツリーに４レベル以上のページが含まれることも２レベル以下のページが含まれることもある。ファイル（又はオブジェクト）「ＶＩＤＥＯ１．ｍｐｇ」には、いくつかの異なる場所（例えば、ｐａｇｅ１、ｐａｇｅ２１、ｐａｇｅ２２、及びｐａｇｅ３１）からアクセスすることができる。同様に、「ＡＵＤＩＯ１．ｍｐ３」にはｐａｇｅ２、ｐａｇｅ１１、及びｐａｇｅ２１上からアクセスすることができる。これにより、ユーザがウェブ・オブジェクト又はファイルにアクセスする柔軟性がもたらされ、ユーザが特定のページを閲覧する際の遅延を最小限に抑えるのに役立つ。このようなウェブ・オブジェクト・ツリー及び各ページ間の様々なジャンプ、ホップ、又はステップの知識を利用して、図４を参照しながら以下で簡潔に説明するテーブルを作成することができる。これにより、本発明のシステムはハイパーテキスト言語の翻訳を実行することが可能となり、ストレージを最適化することが可能となる。
【００２９】
図４は、各エントリが図３に示されるクローズド・ウェブ・サイト内のオブジェクトを表す、本発明に係るＵＲＬマッピング・テーブル４００を示している。このテーブルは、以下で説明する見出しが識別されるいくつかの列を含む。
【００３０】
列１内に示されるページ名４１０は、ウェブ・サーバ内で定義されるオブジェクト名である。このページ名には、ウェブ・ホーム・ディレクトリに従って又は他の任意の適切な手法で、ディレクトリ階層のプレフィックスを付けることができる。
【００３１】
列２内に示されるオブジェクト・タイプ４３０は、ウェブ・オブジェクト・タイプを示す。ウェブ・オブジェクト・タイプの例としては、ＨＴＭＬ又はＷＭＬページを対象とする「Ｔｅｘｔ」、ＪＰＥＧ、ＧＩＦ、ＴＩＦＦ、又は他の任意の画像又は写真ファイルを対象とする「ｉｍａｇｅ」、ＭＰ３、ＷＭＡ、ＡＶＩ、又は他の任意のオーディオ又は音楽ファイル・フォーマットを対象とする「ａｕｄｉｏ」、ＭＰＥＧ、ＡＶＩ、ＱｕｉｃｋＴｉｍｅムービー、又は他の任意のビデオ・ファイル・フォーマットを対象とする「ｖｉｄｅｏ」が挙げられる。
【００３２】
その次の列にはオブジェクト識別子（ＯＩＤ）４４０が示されている。ＯＩＤは、クローズド・ウェブ・サイト内のウェブ・オブジェクトを識別する一意の参照番号である。このＯＩＤは、以下でより詳細に説明するように、クローズド・ウェブ・サイトを形成するすべてのページ内で発見されるリンク中のページ名の代わりとなる。
【００３３】
使用状況（ｕｓａｇｅ）を示すフィールド４５０も識別され、ここにもデータが入力されている。すべてのオブジェクトが放送状態にあるが、アクセス制御保護を受けているために使用できないオブジェクトが存在することもある。これらのオブジェクトを使用可能にするために、ユーザ（顧客）はライセンスを要求することができる。他のすべてのオブジェクトには「放送」の使用状況が使用されているが、これらの保護オブジェクトに関連する使用状況は「オン・デマンド」となっている。
【００３４】
ルート・ホップ・カウント４６０は、そのオブジェクトとルート・ページとの間に介在するページ数を示す。この情報は、カルーセル・スケジューリング用のオブジェクト加重の計算に使用される。
【００３５】
参照カウント４７０は、クローズド・ウェブ・サイト内のすべてのページ内のオブジェクトを指す参照数である。この情報も、カルーセル・スケジューリング用のオブジェクト加重の計算に使用される。
【００３６】
オブジェクトのサイズ標識４８０は、Ｋバイト単位のサイズを示すものであり、この値もまた、以下で説明するカルーセル・スケジューリング用のオブジェクト加重の計算で使用される。
【００３７】
上述のテーブルは、以下で説明するようにトランスレータだけでなくスケジューラでも使用される。
【００３８】
図５は、本発明の一例として使用される小規模なクローズド・ウェブ・サイト５００に関する完全なウェブ・ツリーを示している。ＯＩＤ参照１００を有するウェブ・オブジェクトがルート・ページである。１ホップ分隔てられた隣接ページ又はオブジェクトは、１０１、１０２、１０３、及び１０４で示され、２ホップ分隔てられた隣接ページは、１０５、１０６、１０７、１０８、１０９、１１０、及び１１１で示されている。図５には３ホップ、４ホップ、５ホップ、及び６ホップ先のページも示されている。いくつかのページは異なるルートを経由して到達することができるが、それぞれのホップ数は明らかに異なる。一般には最短のホップ数が最適条件として選択されるが、あるページから別のページまでの異なるルートが利用される場合もある。
【００３９】
図６は、図５のウェブ・ツリーに関するＵＲＬホップ・テーブル６００を示している。このテーブルは、クローズド・ウェブ・サイト内のすべてのオブジェクトをスキャンして、任意のオブジェクトと、当該クローズド・ウェブ・サイト内の他のオブジェクトとの間に介在するホップ数を計算するサイト・アナライザ２３０によって作成される。テーブル内の各列はターゲット・ウェブ・オブジェクトのＯＩＤ  ６１０を表し、各行はソース又はアクティブ・ウェブ・オブジェクトを表している。例えば、参照オブジェクトがＯＩＤ  １００（６７０）である場合、１０１、１０２、１０３、及び１０４のＯＩＤを有するターゲット・オブジェクト（６４０）とは１ホップ分隔てられており、１３６、１３７、及び１３８のＯＩＤを有するターゲット・オブジェクト（６５０）とは６ホップ分隔てられている。
【００４０】
図７は、送信側からモバイル・デバイスに転送されるオブジェクトの構造を示している。ウェブ・オブジェクトをモバイル端末に放送するためにスケジューラ（カルーセル）に記憶する前に、当該ウェブ・オブジェクトはデータ・パケット又はコンテナ７００の形に形成される。データ・パケットは、後述するいくつかの異なるフィールドを含む。
【００４１】
図７のＯＩＤ参照７１０は、ウェブ・サイト・ポンプ２１０によってウェブ・オブジェクトと関連付けられ、翻訳フェーズ中に当該ウェブ・オブジェクトの属性として扱われるオブジェクト識別子である。ウェブ・オブジェクト・サイズ７３０が示され、その後にウェブ・オブジェクト７４０自体も示される。ウェブ・オブジェクトは、テキスト・ページ、オーディオ・ファイル、画像、あるいは他の任意のタイプのウェブ・オブジェクトとすることができる。図７には１組の隣接グループ７５０、７６０、７７０が示されており、これらは特定のウェブ・オブジェクト、即ち参照ウェブ・オブジェクトから所与のホップ数だけ隔てられた隣接オブジェクトをマッピングする。隣接グループ１（７５０）は、参照ウェブ・オブジェクトから１ホップ分だけ隔てられたすべてのオブジェクトをマッピングし、隣接グループ２（７６０）は、２ホップ分隔てられたすべてのオブジェクトをマッピングし、隣接グループｎ（７７０）は、「ｎ」ホップ分隔てられたすべてのオブジェクトをマッピングする。データ・パケットの最後は１６進数のｘ’００’で表される。
【００４２】
各隣接グループは特定の手法で構造化され、ここでは例示のために隣接グループ１（７５０）の構造が示されている。この構造は、ネットワーク・グループと、当該グループ内のすべてのオブジェクトと参照オブジェクトとの間に介在するホップ数とを識別する隣接グループＩＤ  ７５１を含む。したがって、ホップ・カウントが１と等しいグループが識別される。また、ホップ・カウントが２と等しいグループが識別され、以下同様にグループの識別が行われる。この処理は、クローズド・ウェブ・サイト内で発見される最大ホップ数に至るまで続けられる。構造内にはウェブ・オブジェクト・カウント７５２も示されており、このウェブ・オブジェクト・カウント７５２は、そのグループに属する（それぞれのＯＩＤで表される）ウェブ・オブジェクトの数を表す。隣接グループＩＤから特定のホップ・カウントの隣接ＯＩＤ  ７５３及びＯＩＤ  ７５４のリストも判定される。このように、クローズド・ウェブ・サイトに関するすべての詳細事項と、各データ・パケット内のツリー構造とが存在する。これにより、ユーザ要求に応じたウェブ・オブジェクトの予測キャッシュ（ｐｒｅｄｉｃｔｉｖｅ  ｃａｃｈｉｎｇ）が可能となる。
【００４３】
データ・パケットは、図８を参照して以下で説明するように、モバイル・デバイス内のウェブ・クライアントに送信される。モバイル・デバイス上のウェブ・クライアント８００は、通信スタック８１０を介してウェブ・サーバと通信するウェブ・ブラウザ８２０を含む。通信スタック８１０は、ＷｉＦｉや２．５Ｇ／３Ｇプロトコル（ＧＰＲＳ、ＥＤＧＥ、ＵＭＴＳ）等、広く使用されているプロトコルのうちの１つを使用することができる。また、ウェブ・クライアント８００は、ビデオ・プレーヤ８８０と、ＤＶＢ‐Ｈ受信機８４０とを含む。ＴＶ放送をサポートする端末は、以下で説明するように、本発明に係る新しい機能を有する。
【００４４】
モバイルＴＶ受信機はいくつかの異なる機能及びレイヤを含んでおり、例えば、ＤＶＢ‐Ｈ受信機８４５と、ＩＰモジュール８５０と、ユーザ・データグラム・プロトコル（ＵＤＰ）モジュール８５５とを含んでおり、それぞれデータ部分用のＦＬＵＴＥ（単方向トランスポートを利用したファイル配信）と、ビデオ用のＲＴＰ（実時間プロトコル）とに関する２つのセッション・レイヤ８６０及び８６５が提供される。
【００４５】
また、ビデオ処理要素は、Ｈ．２６４デコーダ８７０と、ビデオ・ストリーマ８７５とを含む。ビデオ・ストリーマ８７５からの出力は、ユーザに表示するためにビデオ・プレーヤ８８０に送信される。
【００４６】
本発明は、ブラウザからのすべての要求を傍受するウェブ・プロキシ８３０として働くサービスとして起動することが可能な新しいコンポーネントを実装する。この新しいコンポーネントは、ＦＬＵＴＥ上で受信されるすべてのファイルを検査し、要求されたファイルが受信されたときは当該ファイルを直ちにブラウザに配信する。このコンポーネントは、クライアント・アプリケーションによるいかなる修正も必要とせず、ローカル・ウェブ・プロキシの使用状況を定義するようにウェブ・ブラウザを構成するだけでよい。ウェブ・プロキシ８３０はページをキャッシュした後、当該ページをウェブ・ブラウザに受け渡す。このクライアントの主な機能は、すべての隣接ウェブ・オブジェクトをそれ自体のメモリ８９０に保存することを目的とする予測キャッシュ・メカニズムである。メモリ８９０は、ＳＤカード、コンパクト・フラッシュ、ＳＩＭカード、あるいは他の任意の適切なメモリとすることができる。以下では図９乃至図１１を参照して、キャッシュ及びメモリの動作について説明する。
【００４７】
図９及び図１０に関して、それぞれ図９では参照ウェブ・オブジェクト１００の周囲、図１０ではウェブ・オブジェクト１０２（本例では参照ウェブ・オブジェクトとなる）の周囲に所在する１ホップ又は２ホップを伴うオブジェクトが示されている。各図の中心にはアクティブ・ウェブ・オブジェクト（ＨＴＭＬページ又はその翻訳ページ）が示されている。同心円９００及び９１０に関して、円９００は１ホップ分隔てられた１組の隣接ウェブ・オブジェクトを表し、円９１０は２ホップ分隔てられた１組のオブジェクトを表している。言うまでもなく、これよりも多くのホップ数（３ホップや４ホップ）だけ隔てられた複数組のウェブ・オブジェクトを表す他の多数の同心円（又はレイヤ）を存在させることもできるが、本発明の例示として選択された図示の例では、ホップ数は本出願人らの自由裁量で「２」に固定されている。
【００４８】
隣接組に属するすべてのオブジェクトをメモリ８９０にキャッシュすることができる。キャッシュされるレイヤ数は、メモリ・サイズ及びウェブ・オブジェクト・サイズに依存し、また、後述の予測因子にも依存する。
【００４９】
図９において、アクティブ・ウェブ・オブジェクト（ウェブ・ブラウザに現在表示されているオブジェクト）は１００である。このウェブ・オブジェクトは、１ホップ分隔てられた４つの隣接ウェブ・オブジェクト、即ち、１０１、１０２、１０３、及び１０４を有する。更に、この同一のアクティブ・ウェブ・オブジェクトは、２ホップ分隔てられた７つの隣接ウェブ・オブジェクト、即ち、１０５、１０６、１０７、１０８、１０９、１１０、及び１１１も有する。ユーザがウェブ・オブジェクト１０２に関するリンクをクリックすることを選択した場合は、新しい構成が形成される。この新しい構成では、ウェブ・オブジェクト１０２が中心に置かれ（この時点でのアクティブ・ウェブ・オブジェクト）、１ホップ先の隣接ウェブ・オブジェクトがウェブ・オブジェクト１００及び１０７となり、２ホップ先の隣接ウェブ・オブジェクトがウェブ・オブジェクト１０１、１０３、１０４、１０８、１１２、１１３、１１４、及び１１５となる。ページ１０２がアクティブ・ウェブ・オブジェクトとなるように選択することで、４つの新しいオブジェクト１１２、１１３、１１４、及び１１５が２ホップで到達可能となる。これらのオブジェクトはこの時点でキャッシュされなければならない。これと同時に、５つの古いオブジェクト１０５、１０６、１０９、１１０、及び１１１はもはや隣接範囲に存在しなくなるため、メモリを解放する上で必要があれば、それらの古いオブジェクトをキャッシュから除去することができる。
【００５０】
各オブジェクトに関する情報及びそれらのキャッシュ方法は、図１１に示されるようなテーブルに記憶することができる。このキャッシュ・テーブル１０００は予測キャッシュ機能によって使用され、以下で詳述する情報を含む。
【００５１】
ＯＩＤ  １０１０は、サーバのウェブ・ポンプによってクローズド・ウェブ・サイトに属するウェブ・オブジェクトと関連付けられ、本発明の全体をとおしてウェブ・オブジェクトの「識別子」として使用される、オブジェクト識別子として記憶される。このテーブルは、ウェブ・キャッシュ内のウェブ・オブジェクトのステータスを示すステータス１０２０も含む。ステータスの例としては以下のものを挙げることができる。
●「キャッシュ済み（Ｃａｃｈｅｄ）」：ウェブ・オブジェクト１０４（１０６０）の場合のように、そのウェブ・オブジェクトがキャッシュに保存されていることを示すステータス。
●「削除可能（Ｍａｙ  ｂｅ  ｓｕｐｐｒｅｓｓｅｄ）」：ウェブ・オブジェクト１０６（１０７０）の場合のように、そのウェブ・オブジェクトがキャッシュ内に存在するが、隣接ウェブ・オブジェクト・グループに属していないことを示すステータス。
●「キャッシュ予定（Ｔｏ  ｂｅ  ｃａｃｈｅｄ）」：ウェブ・オブジェクト１１１（１０８０）の場合のように、そのウェブ・オブジェクトが隣接ウェブ・オブジェクトの範囲に属するが、まだ受信されていないことを示すステータス。
このキャッシュ・テーブルは、オブジェクトのサイズ１０３０（例えばＫバイト単位）を示す標識も含む。この標識は、キャッシュ内のすべてのオブジェクトが占める合計サイズを計算し、キャッシュ・オーバーフローを防止するためにどのオブジェクトを削除すべきかを決定するのに使用される。ホップ１０４０の列は、各オブジェクトとアクティブ・オブジェクト（ウェブ・ブラウザ内に表示されるＨＴＭＬ／ＷＭＬページ又はその翻訳ページ）との間に介在するホップ数を表す。図示の例において、アクティブ・ウェブ・オブジェクトはＯＩＤ  １０２である。ＯＩＤ隣接オブジェクトに関する隣接オブジェクト・リスト１０５０、ならびにテーブル・オブジェクトとカレント・オブジェクト又はアクティブ・オブジェクトとの間に介在する既知のホップ数も示されている。リスト内のすべてのオブジェクトは、カレントＯＩＤからクライアント内で構成される最大ホップ数だけ隔てられている。図示の例において、最大ホップ数は「２」である。
【００５２】
ここで、ユーザはカレント・アクティブ・ページ（例えばＯＩＤ  １０２）を閲覧しており、新しいページ（例えばＯＩＤ  １０７）を表示するリンクをクリックし、また、ＯＩＤ  １０７についてはテーブル内でローカル変数「ａｃｔｉｖｅ  ｐａｇｅ」（アクティブ・ページ）が設定されているものと仮定する。次に、カレント・アクティブ・ページ（ＯＩＤ  １０２）は、テーブル内のＯＩＤ  １０２の関連行においてローカル変数「ｐｒｅｖｉｏｕｓ  ｐａｇｅ」（以前のページ）に設定される。
【００５３】
「アクティブ・ページ」（ＯＩＤ  １０７）のステータスが「キャッシュ済み」である場合、換言すれば当該ページが既に受信済みである場合には、キャッシュ・テーブルのルックアップが実行される。ユーザは要求されたページ又はウェブ・オブジェクトに直ちに受け渡され得る。このテーブルは、当該ページの隣接ページに関する情報ならびに先述した他の情報も含む。ＯＩＤ  １０７が「アクティブ・ページ」であることから、当該ページの隣接セットは（まだキャッシュされていなければ）直ちにキャッシュされなければならない。したがって、ＯＩＤ  １０７から１ホップ先のすべての隣接ＯＩＤが「キャッシュ済み」又は「キャッシュ予定」に設定される。また、スペースが許せば、２ホップあるいは３ホップ以上先のＯＩＤについても同様にマーク付けすることができる。２ホップあるいは３ホップ以上先のすべてのウェブ・オブジェクト又はページをキャッシュする十分なスペースが存在しない場合は、まず最小ホップ数に基づいて、次にサイズ又は別のパラメータに基づいて、スペースが空いた時点でキャッシュ先となるページとキャッシュ対象となるページとを判定するように選択することができる。また、この時点で「以前のページ」（ＯＩＤ  １０２）の隣接ページのうちＯＩＤ  １０７の隣接ページに該当しない隣接ページをキャッシュから除去することができる。というのも、それらの隣接ページと現在閲覧されている「アクティブ・ページ」との間にはより多くのホップ数が存在することから、それらの隣接ページがユーザの要求ページに該当する可能性が低いためである。したがって、テーブル内ではＯＩＤ  １０２のすべての隣接ＯＩＤ（ＯＩＤ  １０７の隣接ＯＩＤを除く）に「削除可能」のマーク付けを行うことができる。スペースが必要とされる場合は、上述したように、それらのウェブ・オブジェクトをキャッシュから除去し、より「アクティブ・ページ」に近い場所にあるページ又はウェブ・オブジェクトと置き換えることができる。
【００５４】
「アクティブ・ページ」ＯＩＤ  １０７のステータスが「キャッシュ済み」である場合には、システムは当該ページが受信され閲覧可能な状態になるまで待機しなければならない。「アクティブ・ページ」の隣接セットに関する詳細情報はテーブルから得られるため、すべてのページの到着及び送信が監視される。ウェブ・オブジェクト又はページは、それ自体が受信されたときにテーブル内で「キャッシュ済み」に設定され、それ自体が「アクティブ・ページ」である場合、又は「アクティブ・ページ」の隣接セット内のＯＩＤを有するページである場合は、メモリに記憶されることになる。それ自体のＯＩＤが「以前のページ」の隣接セットに属しており、「アクティブ・ページ」の隣接セットに属さない場合は、そのウェブ・オブジェクは「削除可能」に設定することができる。ルート上にまだ存在せず、上述のように取り込まれた「アクティブ・ページ」に該当するすべてのページに対して「キャッシュ予定」のマーク付けがなされ、配信要求が行われる。
【００５５】
以下に図１２及び図１３を参照して、上記の各処理ステップについてより詳細に説明する。
【００５６】
この処理はステップ１１００から開始する。
【００５７】
ステップ１１０５で、アクティブ・ドライブのルート・ページが判定され、当該ルート・ページは、ＡＰと呼ばれるローカル変数内で「アクティブ・ページ」となるように設定される。「以前のページ」を指すＰＰと呼ばれるローカル変数もルート・ページに設定される。アクティブ・ページの各隣接ページは、「アクティブ隣接ページ（ａｃｔｉｖｅ  ｎｅｉｇｈｂｏｒ）」（又はローカル変数ＡＮ）として設定され、「新しいページ（ｎｅｗ  ｐａｇｅ）」を指すローカル変数ＮＰは、その時点で「新しいページ」が存在しないので「ｅｍｐｔｙ」又は「ｖｏｉｄ」に設定される。その後、ＡＰが表示され、ＡＰレコード・フィールドのステータス１０２０が「キャッシュ済み」に設定され、ホップ・フィールド１０４が「０」に設定され、キャッシュ・テーブル１０００が更新される。
【００５８】
ステップ１１１０で、この処理はイベントの発生まで待機状態となる。ページが受信された場合は、ステップ１１１５から処理が続行される。ユーザが新しいページをクリックした場合は、ステップ１１６０に進む。その他の場合は、ステップ１１１０で待機する。
【００５９】
ステップ１１１５で、受信されたページがＮＰと等しいかどうかを判定するための分析が実行される。ＮＰと等しい場合は（ＹＥＳ）ステップ１１２０に進み、そうでない場合は（ＮＯ）ステップ１１６９に進む。
【００６０】
ステップ１１２０で、ローカル変数ＰＰはＡＰに設定され、ローカル変数ＡＰはＮＰに設定され、ローカル変数ＮＰは「ｖｏｉｄ」にリセットされる。ＡＰが表示され、ローカル変数ＡＮはＡＰの隣接セットに設定される。このステップは実質的に、ページの受信に応じてテーブル１０００及びユーザによって閲覧されるページを更新する。閲覧されるページは、クローズド・ウェブ・サイト内のルート・ページであることも他の任意のページであることもある。
【００６１】
ステップ１１２５で、ローカル変数ＣＲ（「ｃｕｒｒｅｎｔ  ｒｅｃｏｒｄ」（カレント・レコード））がキャッシュ・テーブル１０００の最初のレコードと等しくなるように設定される。
【００６２】
ステップ１１３０で、ＣＲ．ＯＩＤがＡＮに属するかどうかが判定される。ＡＮに属する場合は（ＹＥＳ）ステップ１１３５に進み、そうでない場合は（ＮＯ）ステップ１１４０に進む。
【００６３】
ステップ１１３５で、ＣＲのホップ・フィールド１０４０がＡＰに対する新しいホップ数を反映するように更新され、その後ステップ１１４５に進む。
【００６４】
ステップ１１４０で、ＣＲのステータス・フィールド１０２０が「削除可能」に設定され、他のページ又はオブジェクト用のメモリが必要となったときはその時点で当該ページを削除することができる。
【００６５】
ステップ１１４５で、ＣＲがキャッシュ・テーブル１０００の最後のレコードであるかどうかを判定するための分析が実行される。最後のレコードである場合は（ＹＥＳ）ステップ１１５５に進み、そうでない場合は（ＮＯ）ステップ１１５０に進む。
【００６６】
ステップ１１５０で、ＣＲの次のレコードがＣＲとなり、ステップ１１３０に進む。
【００６７】
ステップ１１５５で、ステータス・フィールド１０２０が「キャッシュ予定」に設定されたＡＮの各メンバに関する新しいレコードを追加することにより、キャッシュ・テーブル１０００が更新される。
【００６８】
（ユーザが新しいページをクリックした場合にステップ１１１０から到達する）ステップ１１６０で、ローカル変数ＮＰは、ユーザによって選択された新しいページに設定される。
【００６９】
ステップ１１６５で、当該ＮＰが既にキャッシュされているかどうかが判定される。既にキャッシュされている場合は（ＹＥＳ）ステップ１１２０に進み、そうでない場合は（ＮＯ）ステップ１１１０に進む。
【００７０】
ステップ１１６７で、最後のイベントがページの受信であるかどうかを判定するための分析が実行される。最後のイベントがページの受信である場合は（ＹＥＳ）ステップ１１６９に進み、そうでない場合は（ＮＯ）ステップ１１１０に戻る。
【００７１】
ステップ１１６９で、受信されたページを記憶するのに十分な空きスペースがキャッシュ内に存在するかどうかを判定するための分析が実行される。空きスペースが存在する場合は（ＹＥＳ）ステップ１１９０に進み、そうでない場合は（ＮＯ）ステップ１１７０に進む。
【００７２】
ステップ１１７０で、受信されたページがＡＮ内に存在するものかどうかを判定するための分析が実行される。ＡＮ内に存在する場合は（ＹＥＳ）ステップ１１７２に進み、そうでない場合は（ＮＯ）ステップ１１１０に進む。
【００７３】
ステップ１１７２で、ステータス・フィールド１０２０が「削除可能」と等しいページがキャッシュ内に含まれるかどうかを判定するための分析が実行される。含まれる場合は（ＹＥＳ）ステップ１１９２に進み、含まれない場合は（ＮＯ）ステップ１１７５に進む。
【００７４】
ステップ１１７５で、それ自体のホップ・カウントがＡＰのホップ・カウントを２だけ上回るページがキャッシュ内に含まれるかどうかを判定するための分析が実行される。含まれる場合は（ＹＥＳ）ステップ１１９５に進み、含まれない場合は（ＮＯ）ステップ１１７７に進む。
【００７５】
ステップ１１７７で、それ自体のホップ・カウントがＡＰのホップ・カウントを１だけ上回るページがキャッシュ内に含まれるかどうかを判定するための分析が実行される。含まれる場合は（ＹＥＳ）ステップ１１８５に進み、含まれない場合は（ＮＯ）ステップ１１８０に進む。
【００７６】
ステップ１１８０で、キャッシュ内で発見された最大ページが除去される。その後ステップ１１６９に進む。
【００７７】
ステップ１１７７の条件を満たしたキャッシュ内の最大ページはステップ１１８５で除去される。その後ステップ１１６９に進む。
【００７８】
ステップ１１９０で、受信されたページがキャッシュに記録され、受信されたページのステータス・フィールド１０２０が「キャッシュ済み」に設定され、当該ページの特徴に従ってサイズ１０３０やホップ１０４０等の他のフィールドが更新される。その後ステップ１１１０に戻る。
【００７９】
ステップ１１７２の条件を満たしたキャッシュ内の最大ページはステップ１１９２で除去される。その後ステップ１１６９に戻る。
【００８０】
ステップ１１７５の条件を満たしたキャッシュ内の最大ページはステップ１１９５で除去される。その後再びステップ１１６９に戻る。
【００８１】
上述の各方法ステップは、上記のシステムの受信機側で実行される。各方法ステップの実行は、ウェブ・オブジェクトの管理及びユーザへの提供に関与する。これと並行して、ビデオが同一のトランスポート・ストリーム又は放送ストリームを介して送信され、同一のエンド・デバイス側で受信される。ビデオ及びウェブ・オブジェクトを輸送するバーストは、一般的なＤＶＢ‐Ｈの慣行に従って認識される。放送ストリームの送受信方法の詳細は、本出願人の同時係属出願（米国特許出願第１１／７６２３０３号（ＦＲ０９  ２００６  ００２９））に詳しく記載されている。
【００８２】
モバイル・デバイスは、例えばＰＤＡや携帯電話、あるいはモバイル・タイプの遠隔通信可能な他の任意のタイプのデバイスを含めた任意のタイプのデバイスであってよい。
【００８３】
本明細書に記載されるＤＶＢ‐Ｈ、ＲＴＰ、Ｈ．２６４等の規格は単なる例示のために示したものであり、現行の又は将来登場する他の任意の規格についても等しく適用することが可能である。
【００８４】
放送者は、例えばユーザがある試合の観戦者であれば次回の観戦チケットや適切な広告等、放送メディアに合わせてクローズド・ウェブ・サイトを調整する形でクローズド・ウェブ・サイトに影響を及ぼすことができる。
【００８５】
以上、本発明の好ましい一実施形態に関して図示及び説明してきたが、本発明の趣旨及び範囲から逸脱することがなければ、本発明の細部に様々な変更を施すことができることを理解していただきたい。
【図面の簡単な説明】
【００８６】
【図１】モバイル・インターネット・インフラストラクチャと別個のデジタル・ビデオ放送インフラストラクチャとに関する従来技術のシステムを示すブロック図である。
【図２】本発明に係るウェブ・キャスト及びデジタル・ビデオ放送インフラストラクチャのブロック図である。
【図３】本発明に係る様々なウェブ・オブジェクト間の関係を示すブロック図である。
【図４】本発明に係るウェブ・オブジェクトのＵＲＬマッピング・テーブルを示す図である。
【図５】複雑なウェブ・サイト内の相互接続関係を示すマップ図である。
【図６】ＵＲＬホップ・テーブルを示す図である。
【図７】ウェブ・オブジェクトがメディアを介して転送されるときのウェブ・オブジェクトの構造を示す図である。
【図８】本発明に係るオブジェクト・キャッシュを含むウェブ・クライアントの構造を示す図である。
【図９】第１の参照オブジェクトの周囲に所在する、１ホップ及び２ホップを伴うアクティブ・ウェブ・オブジェクトを示す図である。
【図１０】第２の参照オブジェクトの周囲に所在する、１ホップ及び２ホップを伴う新しいアクティブ・ウェブ・オブジェクトを示す図である。
【図１１】本発明に係る予測キャッシュ機能によって管理されるテーブルを示す図である。
【図１２】本発明に従ってキャッシュを予測的に管理する処理ステップを示す図である。
【図１３】本発明に従ってキャッシュを予測的に管理する処理ステップを示す図である。
【図１】
2009541877.tif 000003
【図２】
2009541877.tif 000004
【図３】
2009541877.tif 000005
【図４】
2009541877.tif 000006
【図５】
2009541877.tif 000007
【図６】
2009541877.tif 000008
【図７】
2009541877.tif 000009
【図８】
2009541877.tif 000010
【図９】
2009541877.tif 000011
【図１０】
2009541877.tif 000012
【図１１】
2009541877.tif 000013
【図１２】
2009541877.tif 000014
【図１３】
2009541877.tif 000015
【国際調査報告】
2009541877.tif 000016
2009541877.tif 000017
2009541877.tif 000018