(57)【特許請求の範囲】
【請求項１】
ウェブ・コンテンツをインターネット上のサイトを訪問し、該サイトから前記ウェブ・コンテンツを得ることによって自主的に収集し、前記ウェブ・コンテンツを放送媒体を介してウェブキャスト・センタから多数のクライアントに配信するシステムにおいて、
前記のウェブキャスト・センタは、前記ウェブ・コンテンツを格納し、前記収集したウェブ・コンテンツをパッケージ化し該パッケージを放送媒体を介して送信するウェブキャスト・センタであって、
インターネット上のサイトから、サイトを訪問しコンテンツを得ることによって自主的にウェブ・コンテンツを収集するサーバ・ユニットと、
前記サーバ・ユニットから物理的に分離されており、前記収集したウェブ・コンテンツをパッケージ化したものを前記サーバ・ユニットから受信し、前記放送媒体を介して放送送信する放送送信機と
を有する、前記のウェブキャスト・センタと、
１つ以上の選択したサイトからの前記ウェブ・コンテンツの１部分を前記放送送信機から受けるためのフィルタを備えた多数のクライアントと、
を備え、
前記ウェブ・コンテンツは、ウェブ・ページから成り、前記パッケージ化は、前記ページを、それらのＵＲＬ（ユニバーサル・リソース・ロケータ）にしたがってアルファベット順に並べ替えそしてパッケージファイルが同一サイトからのページを含むようパッケージ・ファイルを形成するようになされる
ことを特徴とする配信システム。
【請求項２】
請求項１記載の配信システムにおいて、前記ウェブキャスト・センタのサーバ・ユニットは、ウェブ・ページと、該ウェブ・ページが参照する任意のインライン・イメージ・ファイルを収集すること、を特徴とする配信システム。
【請求項３】
請求項１記載の配信システムにおいて、
前記サーバ・ユニットは、前記サイトから収集した前記ウェブ・コンテンツを格納するコンテンツ・キャッシュを有し、
前記配信システムは前記パッケージ化されたファイルを放送送信の前に格納するパッケージ・ストアをさらに備え、
前記サーバ・ユニットは前記コンテンツ・キャッシュ内の前記ウェブ・コンテンツをパッケージ化するパッケージャをさらに有する
ことを特徴とする配信システム。
【請求項４】
ウェブ・コンテンツをインターネット上のサイトを訪問し、該サイトから前記ウェブ・コンテンツを得ることによって自主的に収集し、前記ウェブ・コンテンツを放送媒体を介してウェブキャスト・センタから多数のクライアントに配信するシステムにおいて、
前記のウェブキャスト・センタは、前記ウェブ・コンテンツを格納し、収集したウェブ・コンテンツをパッケージ化し該パッケージを放送媒体を介して送信するウェブキャスト・センタであって、
インターネット上のサイトから、サイトを訪問しコンテンツを得ることによって自主的にウェブ・コンテンツを収集するサーバ・ユニットと、
前記サーバ・ユニットから物理的に分離され、前記収集されたウェブ・コンテンツをパッケージ化したものを前記サーバ・ユニットから受信し、前記放送媒体を介して放送送信する放送送信機と
を有する、前記のウェブキャスト・センタと、
１つ以上の選択したサイトからの前記ウェブ・コンテンツの１部分を前記放送送信機から受けるためのフィルタを備えた多数のクライアントと、
を備え、
前記ウェブキャスト・センタにある前記放送送信機は、前記ウェブ・コンテンツを個々のパッケージで送信し、
各クライアントは、前記ウェブ・コンテンツを前記パッケージから再構成するためのアンパッケージャを有し、該アンパッケージャは、前記ウェブキャスト・センタから受けた前記ウェブ・コンテンツが、前記クライアントに既に格納されていることのある同一のサイトからの任意のウェブ・コンテンツよりもより最近のものであるかどうかを判定するよう構成したこと、を特徴とする配信システム。
【請求項５】
ウェブ・コンテンツをインターネット上のサイトを訪問し、該サイトから前記ウェブ・コンテンツを得ることによって自主的に収集し、前記ウェブ・コンテンツを放送媒体を介してウェブキャスト・センタから多数のクライアントに配信するシステムにおいて、
前記のウェブキャスト・センタは、前記ウェブ・コンテンツをインターネット上のサイトから、サイトを訪問しコンテンツを得ることによって自主的に収集し、そして該ウェブ・コンテンツを格納し、収集したウェブ・コンテンツをパッケージ化し該パッケージを放送媒体を介して送信するウェブキャスト・センタであって、
インターネット上のサイトから、サイトを訪問しコンテンツを得ることによって自主的にウェブ・コンテンツを収集するサーバ・ユニットと、
前記サーバ・ユニットから物理的に分離されており、前記収集したウェブ・コンテンツをパッケージ化したものを前記サーバ・ユニットから受信し、前記放送媒体を介して放送送信する放送送信機と
を有する、前記のウェブキャスト・センタと、
１つ以上の選択したサイトからの前記ウェブ・コンテンツの１部分を前記放送送信機から受けるためのフィルタを備えた、多数のクライアントと、
を備え、
各クライアントは、アノテータを含み、該アノテータは、前記ウェブ・コンテンツ内のハイパーリンクに注釈を付すことにより、前記クライアントにてローカルに格納されていないコンテンツにアクセスする第１のハイパーリンクと、前記クライアントにてローカルに格納されたコンテンツにアクセスする第２のハイパーリンクとの間で区別するように構成したこと、を特徴とする配信システム。
【請求項６】
ウェブ・コンテンツをインターネット上のサイトを訪問し、該サイトからウェブ・コンテンツを得ることによって自主的に収集し、前記ウェブ・コンテンツを放送媒体を介してウェブキャスト・センタから多数のクライアントに配信するシステムにおいて、
前記のウェブキャスト・センタは、サーバ・ユニットと前記サーバ・ユニットから物理的に分離された放送送信ユニットとを備えたウェブキャスト・センタであって、
前記サーバ・ユニットは、
インターネット上のサイトを訪問しサイトからコンテンツを得ることによって自主的にウェブ・コンテンツを収集するギャザラと、
該ギャザラが前記サイトから自主的に収集した前記ウェブ・コンテンツを格納するコンテンツ・キャッシュと、
前記コンテンツ・キャッシュ内に格納した前記ウェブ・コンテンツを、放送パッケージ・ファイルにパッケージするパッケージャと、
を有し、前記放送送信ユニットは、
前記放送パッケージ・ファイルを放送送信の前に格納するパッケージ・ストアと、
前記パッケージ・ストアからの前記パッケージ・ファイルを個々のパッケージにセグメント化し、そして前記パッケージを放送媒体を介して送信する放送送信機と
を有し、
前記ギャザラは、第１のデータ・レートで、前記サイトから前記ウェブ・コンテンツを取得しそして前記ウェブ・コンテンツを前記コンテンツ・キャッシュに格納し、
前記放送送信機は、前記パッケージ・ストアからの前記パッケージを、前記第１データ・レートとは異なった第２のデータ・レートで送信することを特徴とするウェブキャスト・センタ。
【請求項７】
請求項６記載のウェブキャスト・センタにおいて、前記放送送信機は、前記サーバ・ユニットと前記放送送信ユニットとの間の送信データ量が前記放送送信機からの放送送信データ容量よりも少ない場合、サーバ・ユニットからのアップデート間において、前記パッケージ・ストアのパッケージ・ファイルを、サイクル動作して放送送信することを特徴とするウェブキャスト・センタ。
【請求項８】
ウェブ・コンテンツをインターネット上のサイトを訪問し、該サイトからウェブ・コンテンツを得ることによって自主的に収集し、前記ウェブ・コンテンツを放送媒体を介してウェブキャスト・センタから多数のクライアントに配信するシステムであって、
前記のウェブキャスト・センタのサーバ・ユニットがインターネット上のサイトを訪問し自主的に収集したウェブ・コンテンツをデータ・パッケージ化して個々のデータ・パッケージとし、前記サーバ・ユニットとは物理的に分離されており該データ・パッケージを受け取った放送送信機から放送媒体を介して多数のクライアントに配信するためのシステムにおいて、前記クライアントの各々に実装されるパッケージ・ハンドリング・ユニットであって、
前記データ・パッケージからパッケージ・ファイルを再構成する受信機と、
前記ウェブ・コンテンツを含む前記パッケージ・ファイルを一時的に保持するパッケージ・ストアと、
前記パッケージ・ファイルから前記ウェブ・コンテンツを再構成するアンパッケージャであって、前記放送媒体からの前記パッケージ・ファイルにおいて受けた前記ウェブ・コンテンツが、前記パッケージ・ファイル内の前記ウェブ・コンテンツが来た元と同じウェブ・サイトからの重複のウェブ・コンテンツを前記クライアントが取得した結果として前記クライアントに既に格納されている重複のウェブ・コンテンツよりも、より最近のものであるかどうかを判定する、前記のアンパッケージャと、
から成るパッケージ・ハンドリング・ユニット。
【請求項９】
ウェブ・コンテンツをインターネット上のサイトを訪問し、該サイトから前記ウェブ・コンテンツを得ることによって自主的に収集し、前記ウェブ・コンテンツを放送媒体を介してウェブキャスト・センタから多数のクライアントに配信するシステムにおいて、
（Ａ）前記のウェブキャスト・センタであって、
（１）インターネット上のサイトを訪問し、サイトからコンテンツを得ることによって自主的にウェブ・コンテンツを収集するギャザラと、
（２）前記ギャザラに対し、前記ウェブ・コンテンツを自主的に収集する前記サイトおよび時間をスケジュールするスケジューラと、
（３）前記ギャザラが前記サイトから収集した前記ウェブ・コンテンツを格納するコンテンツ・キャッシュと、
（４）前記コンテンツ・キャッシュ内に格納した前記ウェブ・コンテンツを、放送パッケージ・ファイルにパッケージするパッケージャと、
からなるサーバ・ユニットと、
（５）前記放送パッケージ・ファイルを格納するパッケージ・ストアと、
（６）前記サーバ・ユニットからは物理的に分離されており、前記パッケージ・ストアからの前記パッケージ・ファイルを個々のパッケージにセグメント化し、そして前記パッケージを放送媒体を介して送信する放送送信機と、から成るウェブキャスト・センタと、
（Ｂ）クライアントであって、
（１）前記放送されたパッケージを受信する受信機と、
（２）前記ウェブキャスト・センタが収集した前記ウェブ・コンテンツのディレクトリを格納する加入データベースと、
（３）ユーザが、前記加入データベースの前記ディレクトリから好みのウェブ・コンテンツを選択できるようにするため、前記クライアントにおいて実行される加入者ユーザ・インターフェースと、
（４）ユーザが選択した前記好みのウェブ・コンテンツを運ぶ前記パッケージを受け入れる一方で、好みでないウェブ・コンテンツを運ぶ他のパッケージを拒絶するよう前記受信機を指揮し、そして前記受け入れたパッケージから前記パッケージファイルを再構成するフィルタと、
（５）前記受信機が受けた前記パッケージ・ファイルを一時的に保持するクライアント側のパッケージ・ストアと、
（６）前記放送媒体から受けた前記パッケージ・ファイル内の前記ウェブ・コンテンツが、前記クライアントに既に格納されている前記ウェブ・コンテンツの他のバージョンよりもより最近のものであるかどうかを判定するアンパッケージャと、
から成る前記のクライアントと、
を備えたことを特徴とする配信システム。
【請求項１０】
請求項９記載の配信システムにおいて、前記ギャザラは、ウェブ・ページと、前記ホーム・ウェブ・ページが参照する任意のインライン・イメージ・ファイルを取得するよう構成したこと、を特徴とする配信システム。
【請求項１１】
請求項９記載の配信システムにおいて、前記放送送信機は、前記サーバ・ユニットと前記放送送信ユニットとの間の送信データ量が前記放送送信機からの放送送信データ容量よりも少ない場合、サーバ・ユニットからのアップデート間において、前記パッケージ・ストア内の前記パッケージ・ファイルを、サイクル動作して放送送信すること、を特徴とする配信システム。
【請求項１２】
請求項９記載の配信システムにおいて、前記ウェブキャスト・センタは、さらに、前記クライアントに対し、将来の放送送信において送信する前記ウェブ・コンテンツを通知するアナウンスを送るアナウンス発生器を含むこと、を特徴とする配信システム。
【請求項１３】
ウェブ・コンテンツをインターネット上のサイトを訪問し、該サイトから前記ウェブ・コンテンツを得ることによって自主的に収集し、前記ウェブ・コンテンツを放送媒体を介してウェブキャスト・センタから多数のクライアントに配信する方法であって、
インターネット上のサイトから前記ウェブ・コンテンツを、前記ウェブキャスト・センタのサーバー・ユニットがサイトを訪問しコンテンツを得ることによって自主的に収集するステップと、
前記ウェブ・コンテンツを第１のキャッシュに格納するステップと、
前記第１キャッシュからの前記ウェブ・コンテンツをパッケージ・ファイルにパッケージするステップと、
前記パッケージ・ファイルを第２のキャッシュに格納するステップと、
前記サーバ・ユニットとは物理的に分離された放送送信機が、前記第２キャッシュからの前記パッケージ・ファイルを前記放送媒体を介して放送するステップと、
前記パッケージ・ファイルをクライアントにて受信するステップと、
前記パッケージ・ファイルをフィルタすることにより、ユーザが好む前記ウェブ・コンテンツを含むファイルを保持するステップと、
前記保持したパッケージ・ファイルから前記好みのウェブ・コンテンツを再構成するステップと、
前記ウェブ・コンテンツ内のハイパーリンクに注釈を付すことにより、前記クライアントにてローカルに格納されていないコンテンツにアクセスする第１のハイパーリンクと、前記クライアントにてローカルに格納されたコンテンツにアクセスする第２のハイパーリンクとの間で区別するステップと、
から成ることを特徴とする配信方法。
【請求項１４】
請求項１３記載の方法であって、さらに、ウェブ・ページと、該ウェブ・ページが参照する任意のインライン・イメージ・ファイルを取得するステップ、を含むことを特徴とする配信方法。
【請求項１５】
ウェブ・コンテンツをインターネット上のサイトを訪問し、該サイトから前記ウェブ・コンテンツを得ることによって自主的に収集し、前記ウェブ・コンテンツを放送媒体を介してウェブキャスト・センタの放送送信機から多数のクライアントに配信するシステムにおいて、前記ウェブキャスト・センタにおいてウェブ・コンテンツを累積するコンピュータ実施の方法であって、
前記放送送信機からは物理的に分離されているサーバ・ユニットが、インターネット上のサイトから前記ウェブ・コンテンツを、サイトを訪問しコンテンツを得ることによって自主的に収集するステップと、
前記ウェブ・コンテンツを第１のキャッシュに格納するステップと、
前記第１キャッシュからの前記ウェブ・コンテンツをパッケージ・ファイルにパッケージするステップと、
前記パッケージ・ファイルを第２のキャッシュに格納するステップと、
を有し、
前記ウェブ・コンテンツを前記コンテンツ・キャッシュに格納するレートである第1のデータ・レートは、前記パッケージ・ストアからの前記パッケージが前記放送媒体を介して送信される第２のデータ・レートとは異なりかつ独立していることを特徴とするコンピュータ実施方法。
【請求項１６】
請求項１５記載のコンピュータ実施方法であって、さらに、
前記サーバ・ユニットが前記パッケージ・ストアからの前記パッケージ・ファイルを個々のパッケージにセグメント化するステップと、
前記放送送信機が前記パッケージを放送媒体を介して送信するステップと、
を含むこと、を特徴とするコンピュータ実施方法。
【請求項１７】
請求項１５記載のコンピュータ実施方法であって、さらに、前記サーバ・ユニットと前記放送送信機との間の送信データ量が前記放送送信機からの放送送信データ容量よりも少ない場合、前記パッケージ・ファイル内の前記ウェブ・コンテンツの更新と更新間で、前記放送送信機が前記パッケージをサイクル動作して多数回放送送信するステップを含むことを特徴とするコンピュータ実施方法。
【請求項１８】
ウェブ・コンテンツを放送媒体を介してウェブキャスト・センタから多数のクライアントに配信するシステムであって、前記ウェブキャスト・センタのサーバ・ユニットに設けられたギャザラがインターネット上のサイトを訪問して自主的に得たウェブ・コンテンツを、パッケージ・ファイルにパッケージ化して、前記サーバ・ユニットからは物理的に分離されている放送送信機から配信するシステムにおいて、前記クライアントにおいて、前記ウェブ・コンテンツ内のハイパーリンクに注釈を付すことにより、前記クライアントにてローカルに格納されていないコンテンツにアクセスする第１のハイパーリンクと、前記クライアントにてローカルに格納されたコンテンツにアクセスする第２のハイパーリンクとの間で区別するステップ、から成るコンピュータ実施方法。
【請求項１９】
請求項１８記載のコンピュータ実施方法であって、さらに、前記ハイパーリンクに注釈を付すことによって、前記クライアントにいるユーザによって少なくとも１回作動された第３のハイパーリンク間で区別するステップ、を含むことを特徴とするコンピュータ実施方法。
【請求項２０】
請求項１８記載の方法における前記ステップを実行するコンピュータ読み取り可能命令を有するコンピュータ読み取り可能記憶媒体。
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は、放送媒体でウェブに関係した情報を配信するシステムおよび方法に関するものである。この発明は、さらに、このシステムおよび方法の種々の側面を実装するのに使用するコンピュータ・デバイスおよびソフトウェアに関している。
【０００２】
（発明の背景）
本発明は、放送公衆ネットワークを介してウェブ・コンテンツを配信するシステムに関し、そして最も顕著なインターネットは、通信、エンタテイメント、ビジネス・サービスをための主要な導管として現れてきている。インターネットは、ローカル・エリア・ネットワークおよびワイド・エリア・ネットワークを含む計算機ネットワークの協働する相互接続で形成されたネットワークである。これは、個々のコンピュータおよび様々なコンピュータをスムーズに接続する共通のプロトコルを用いることにより、既存のしかも互換性のない技術の世界中からのコンピュータを相互接続する。
【０００３】
インターネットは、近年になって、ワールドワイドウェブ（ＷＷＷまたはウェブ）の圧倒的でしかも急速な成功によって普及してきている。このウェブは、つながりの複雑で非シーケンシャルなウェブで種々のトピックを互いにリンクし、これによって、ユーザは、１つのトピックから別のトピックを、その提示されたトピックの順序に無関係にブラウズすることができるようになる。このウェブは、任意のタイプの情報を分配し、発見し、アクセスするための標準として急速に発展してきている。“ウェブ・ブラウザ”は、ユーザのコンピュータ上で実行することによりウェブをナビゲートするアプリケーションである。このウェブ・ブラウザにより、ユーザは、テキスト、サウンド、イメージ、ビデオおよびその他のデータを含むＷＷＷからのハイパーメディア・コンテンツを検索しレンダーできるようにする。
【０００４】
インターネット上でのデータに対する要求における驚くほどの成長率は、部分的には、聴衆の増大に起因している。ワールドワイドウェブは、はるかに多くの聴衆に対しても余裕がありしかも興味のあるものとするスレシュホールドを超えている。非常に広範なトピックに関して利用可能な情報があり、そして人々がその情報をコスト上効果的に発見しそして見るのに役立つツールが存在している。インターネットの成長を刺激する別のファクタは、個々のユーザ当たりの増大するデータ要求である。ウェブ・サイトは、純粋なテキストから、ピクチャ、サウンドおよびビデオのようなより豊かなメディアへと進展するトレンドがある。これらより豊かなメディアを追加することは一般的となっており、その理由は、これらが、情報をより明瞭に提示し、それによってサイトのインパクトおよび人気をより強めるからである。
【０００５】
しかし残念ながら、インターネットの継続した成長並びにこれが受け入れられることに関する問題は、このウェブにアクセスする従来の方法が、要求の急速な成長を満足するのに十分な規模となっていないことである。ウェブに関するサービス品質は、ウェブ・ページを要求することとこれを見ることができるようになることとの間の時間量として、ユーザが本能的に測っている。インターネット・ユーザは、テレビおよびスタンドアロンのマルチメディア・アプリケーションでの彼らの体験から、要求に対する瞬時の結果を期待するように条件付けられてきている。ユーザは、チャンネルを変え、そしてそのチャンネルをスクリーン上でそのビデオ・コンテンツを瞬時に見ることに慣れている。しかし、インターネットは、データを瞬時に配信することができない。その大部分は、インターネットが、かなりのレイテンシ問題を有し、これは、ほぼルーチンのウェブ・ブラウジングの実行を、忍耐のいる長引くレッスンにまで減じている。
【０００６】
この基本的なジレンマは、サービス品質が、より多くの人がウェブを使用しようとするにつれて劣化することである。もっと解決できないことに、人気のあるウェブ・サイトのサービスは通常は、人気のないサイトのサービスよりもかなり悪いことは、当然の結果である。このサービス問題の根源には、分配ネットワークの帯域幅があまりにも狭いという結果として、ウェブ・データを迅速に提供できないことがある。“帯域幅”は、任意の一時にある特定のネットワーク・セグメントを通して動かすことができるデータ量である。インターネットは、異なった関連の帯域幅を有する互いに異なった技術の集合体である。インターネットを通しての分配は、通常は、利用可能な最も低い帯域幅のセグメントによって制限される。
【０００７】
図１に示したインターネット・システム２０について考えることにする。インターネット・システム２０は、ウェブ・サーバ２２を備え、これは、データを格納し、そしてこれを、インターネット２４上で存在地点（ＰＯＰ）のオペレータにあるいはＩＳＰとして示した独立のサービス・プロバイダ（ＩＳＰ）に提供する。ＩＳＰ２６は、インターネット２４への接続性を、加入者コンピュータ２８，３０，３２で表す多くのユーザに提供する。
【０００８】
このＩＳＰ２６は、ネットワーク接続３４を介してインターネット２４に接続する。この例示的１例では、ネットワーク接続３４は、“Ｔ１”接続である。“Ｔ１”は、ほぼ１．５Ｍｂｐｓ（メガビット／秒）のベースのスループット速度を有する単位帯域幅である。別の高い帯域幅の接続は、Ｔ３接続であり、これは、ほぼ４４．７Ｍｂｐｓのベース・スループット速度を有している。現行技術水準並びにインターネットを介するコンテンツ配信の現実的な問題を説明するためには、ウェブ・サーバ２２とインターネット２４との間にも、限られた帯域幅の接続があるということを理解すれば十分である。
【０００９】
加入者コンピュータ２８，３０，３２は、それらのホストＩＳＰ２６に対し、電話線あるいはケーブル線のようなホーム・エントリ・ラインと互換性のあるモデムによって接続している。市販されている技術の例として、加入者コンピュータ２８は、１４．４Ｋ接続３６を介してＩＳＰ２６に接続し、これは、標準の電話線およびＶ．３２ｂｉｓモデムから成っていて、１４．４Ｋｂｐｓ（キロビット／秒）の最大データ・レートを可能にする。加入者コンピュータ３０は、２８．８Ｋ接続３８（電話線およびＶ．３４モデム）でＩＳＰ２６に接続し、これは、２８．８Ｋｂｐｓのデータ・レートをサポートする。加入者コンピュータ３２は、ＩＳＤＮ接続４０でＩＳＰ２６に接続し、これは、特殊なタイプの電話線であって１２８−１３２Ｋｂｐｓの範囲でのデータ・フローを容易にするものである。
【００１０】
表１は、今日利用可能な接続技術をまとめている。
【００１１】
【表１】
0004693988.tif 000002
【００１２】
一次分配ネットワーク２４に対するＴ１接続では、ＩＳＰ２６は、ほぼ１．５Ｍｂｐｓの最大データ・フローを容易にすることができる。この帯域幅は、このＩＳＰの加入者全てにサービスするのに利用可能である。加入者コンピュータ２８が接続しデータ・ファイルをダウンロードしているとき、これは、１．５Ｍｂｐｓ帯域幅の１４．４Ｋｂｐｓスライスを必要とする。加入者コンピュータ３０と３２とは、その利用可能な帯域幅のそれぞれ２８．８Ｋｂｐｓと１２８Ｋｂｐｓのスライスを消費する。
【００１３】
ＩＳＰ２６は、多数の加入者からの同時の要求を収容することができる。しかし、より多くの加入者がＩＳＰサービスを利用するつれ、加入者の要求を満たすために利用可能な帯域幅が少なくなる。多すぎる要求を受けると、ＩＳＰ２６は、過負荷となり、それら要求をタイムリーな方法で十分にサービスすることができなくなることがあり、これは加入者にフラストレーションを生じさせる。レイテンシ問題が存続する場合、ＩＳＰは、追加の容量を付加することによってより大きな帯域幅を購入することができる（例えば、Ｔ３接続にアップグレードまたはより多くのＴ１接続を追加）。しかし、残念なことに、より多くの帯域幅を付加することは、ＩＳＰにとって経済的に賢明とはならないことがある。ＩＳＰに対し課される負荷は、通常は、１日の内の異なった時間で変動する。高価な帯域幅を付加して短時間の高要求時間をサービスすることは、現在の容量が１日のほとんどの間における加入者トラヒックに十分サービスできる場合には、利益にならないことがある。
【００１４】
このレイテンシ問題は、おそらく、ビデオに関して動作しているときに最も強くなる。ビデオをインターネットでダウンロードしようとするとき以外に、よりユーザを失望させるものはほとんどない。この問題は、ビデオが、テキスト・ファイル、グラフィックス、およびピクチャと比べより大きな帯域幅を必要とすることである。さらに、静止イメージやテキスト・ファイルとは異なって、ビデオは、動くイメージとして提示され、これが中断なく連続的に再生される。ビデオは、代表的には、リアルタイムのストリーミング・データに対しては１．２Ｍｂｐｓを必要とする。この１．２Ｍｂｐｓのスループット要求は、Ｔ１帯域幅（１．５Ｍｂｐｓ）のほとんど全てを消費する。したがって、多数の加入者がＩＳＰに結合され、そして１人の加入者がビデオ・ファイルを要求すると、ウェブ・サーバ２２からインターネット２４２を介してその要求側加入者に対しそのビデオをリアルタイムで流すのに十分な容量が、一般的にはない。このビデオ・ファイルは、通常はその全部が配信され、そしてその配信がされてからのみ、加入者コンピュータで再生されるものである。しかし、ビデオ・ファイルをブロック・データ・フォーマットでダウンロードするときでも、不便なことが多く、過剰な時間を要する。
【００１５】
次の例について考えることにする。ここで、ある加入者が２０秒のビデオ・クリップを有するあるウェブ・サイトにアクセスを希望しているとする。１．２Ｍｂｐｓでは、２０秒のビデオ・クリップは、２４Ｍｂｙｔｅのファイルをインターネットでダウンロードすることが関係する。このユーザがあまり高くない１４．４Ｋｂｐｓ接続を有する場合、そのファイル全体をダウンロードするのにおよそ２８分かかることになる。
【００１６】
次に、加入者／ＩＳＰ接続が十分に大きくてビデオ・ファイルのリアルタイムのビデオ・ストリーミングを取り扱えるとすると、これは、加入者コンピュータがそのビデオ・データを、ＩＳＰから受けるにつれレンダーできることを意味する。加入者／ＩＳＰ接続の帯域幅に拘わらず、リアルタイムのビット・ストリーミングは、ＩＳＰ２６と分配ネットワーク２４との間のＴ１接続３４が、ポリシー上の理由から、その帯域幅の内の１．２Ｍｂｐｓをそのビデオ・ファイルに専用させることができない場合あるいはそうしようとしない場合には、依然として実現できないことになる。ＩＳＰにおけるピーク・トラヒック時間中になされる２０秒ビデオ・クリップに対する要求は、ほぼ確実に、ＩＳＰ／ネットワーク接続が収拾することができないものとなる。より多くの帯域幅を付加することは、ＩＳＰにとってはまずい投資となることがあるため、ＩＳＰは、このレイテンシ問題を改善する経済的インセンティブを有することにならない。この結果、あるユーザは、ストリーミング・ビデオを収容できる能力のあるＩＳＰへの彼ら自身の接続に拘わらず、ストリーミング・ビデオを受けることができないことによって、不便を感じさせられることになる。
【００１７】
このレイテンシ問題は、コンテンツ・サーバ２２と分配ネットワーク２４との間の接続が等しく重い負担がかけられる場合には、さらに悪化する。コンテンツ・サーバ／ネットワーク・リンクにおける十分な帯域幅の欠如はまた、ネットワーク／ＩＳＰリンクまたはＩＳＰ／加入者リンクの帯域幅に拘わらず、インターネットでのリアルタイムのビット・ストリーミングを妨げるおそれがある。全てのリンクが十分な帯域幅を欠いていると、レイテンシ問題は、さらにその度合いが増す。
【００１８】
このため、各接続点においてより多くの帯域幅を付加する従来の技術は、上昇している要求を満たす規模の受け入れ可能なアーキテクチャを提供するものではない。したがって、インターネット上でのウェブ・コンテンツの分配を容易にする改良した技術を開発する必要が存在する。
【００１９】
（発明の摘要）
本発明は、ウェブ・コンテンツを放送媒体を介してウェブキャスト・センタから多くのクライアントに配信するシステムに関するものである。ウェブキャスト・センタは、ウェブ・コンテンツをインターネット上のサイトから収集するサーバと、このウェブ・コンテンツをクライアントに対し放送媒体を介して配信する放送ユニットとを有する。
【００２０】
前記サーバは、選択したサイトから、代表的にはウェブ・ページの形態のウェブ・コンテンツを継続的に収集するギャザラを含む。スケジューラは、前記ギャザラに対し、どのサイトおよびどの時間に、前記ウェブ・コンテンツを収集するかを知らせる。好ましくは、前記スケジューラは、前記サイトのオフ・ピーク時間中の収集時間を設定する。前記スケジューラは、管理者が前記ウェブキャスト・センタにおいて入力した好みに基づく希望するウェブ・サイトおよびコンテンツのスケジュール・データベースを保持する。前記ギャザラは、前記コンテンツをフェッチし、そしてこれを、コンテンツ・キャッシュに格納して、前記ウェブキャスト・センタにおいて前記ウェブ・コンテンツの現在のコピーを保持する。
【００２１】
前記ギャザラは、各サイトから、ルートＵＲＬ（ユニバーサル・リソース・ロケータ）のホーム・ウェブ・ページと、前記ルートＵＲＬより下の予め定めた深さ内の任意の追加のウェブ・ページとを収集するように構成可能である。管理者は、各サイトに対して希望の深さを設定する。前記ギャザラはまた、前記収集したウェブ・ページが参照する任意のインライン・イメージ・ファイルも収集する。
【００２２】
前記ウェブキャスト・サーバは、前記コンテンツ・キャッシュから前記ウェブ・コンテンツを検索し、該ウェブ・コンテンツをパッケージ・ファイルにパッケージするパッケージャを有する。該パッケージャは、前記コンテンツ・キャッシュから別個のパッケージ・ストア内に前記パッケージ・ファイルを格納する。前記パッケージは、前記ウェブ・コンテンツからのデータと、サイズおよび変更時間のような前記サーバが提供する他の情報とを含む。
【００２３】
前記放送ユニットは、前記パッケージ・ストアからの前記パッケージ・ファイルを取り、これらを個々のパッケージにセグメント化し、そしてこれらパッケージを前記放送媒体を介して送信する。好ましくは、前記放送ユニットは、フォールト・トレラントの放送ファイル転送システムとして構成した放送送信機を用いる。前記放送媒体は、マルチキャスト・パッケージ・トランスポートをサポートする任意の媒体とすることができる。可能なトランスポートは、ローカル・エリア・イーサネット・ネットワーク（ＬＡＮ）、デジタル衛星または放送テレビジョン信号へのエンコーディングを含む。
【００２４】
各クライアントには、前記放送パッケージを受信する受信機を装備する。前記クライアントは、加入データベースを保持して、前記ウェブキャスト・センタが収集した前記ウェブ・コンテンツのディレクトリを格納する。加入者ユーザ・インターフェースは、ユーザが、前記加入データベースの前記ディレクトリから好みのウェブ・コンテンツを選択できるようにする。前記クライアントは、ユーザの好みに基づいてフィルタを作成する。該フィルタは、前記受信機を指揮することにより、前記好みのウェブ・コンテンツを収集する一方で、希望しないウェブ・コンテンツを運ぶパッケージを無視するようにする。
【００２５】
前記好みのウェブ・コンテンツを受信するとき、前記クライアントは、前記パッケージ・ファイルを再構成し、そしてこれらをパッケージ・ストアに一時的に格納する。アンパッケージャは、前記パッケージ・ストア内の前記パッケージ・ファイルから前記ウェブ・コンテンツを再構成する。前記アンパッケージャは、前記放送パッケージにおいて受けた前記ウェブ・コンテンツが、ユーザがユーザ自身で前記同じサイトから収集したことのあるのと同じウェブ・コンテンツよりも最近のものであるかどうかを判定するよう構成する。前記放送コンテンツがより最近のコピーである場合、前記クライアントは、そのバージョンを保持し、そうでない場合は、前記クライアントは、前記より最近のバージョンを支持して、前記放送パッケージを捨てる。
【００２６】
前記クライアントは、前記ウェブ・ページ内に保持された任意のハイパーリンクに注釈を付す。この注釈は、作動されたリンクと、前記放送送信の結果として前記クライアントにおいてローカルに格納されたコンテンツに行くリンクと、前記クライアントからリモートに格納されたコンテンツに行くリンクとの間で区別する。この注釈は、カラー変化、あるいはスタイル上の変化の形態とすることができる。
【００２７】
（好ましい実施形態の詳細な説明）
図２は、ウェブ・コンテンツをウェブキャスト・センタ５２から放送媒体５４を介して多数のクライアント５６（１）−５６（Ｍ）に配信するためのウェブキャスト・システム５０を示している。ウェブキャスト・センタ５２は、ウェブ・サイト５８（１）−５８（Ｎ）をインターネット６０を介して訪問しそしてそれらサイトからコンテンツをフェッチすることにより、ワールドワイドウェブからウェブ・コンテンツを収集する。このウェブ・コンテンツは、代表的には、それらサイトで見い出されるウェブ・ページの形態にある。１つのウェブ・ページは、タイトル、情報の集まり、他の情報へのポインタあるいは“ハイパーリンク”である。１つのウェブ・ページは、コンピュータ・データ、オーディオ、ビデオ、アニメーション、ビットマップあるいはその他のグラフィックス、アプリケーションあるいはその他の実行可能のコード、テキスト、ハイパーメディア、あるいはその他のマルチメディア・タイプを含む種々のタイプのコンテンツから構成されたものとすることができる。
【００２８】
ウェブキャスト・センタ５２は、インターネットのワールドワイドウェブ６０からウェブ・ページを収集し、そしてこれらをページ・キャッシュ６２に格納する。システム管理者は、どのサイトをウェブキャスト・センタ５２が訪問し、そしてその訪問の時間および頻度、並びに収集するコンテンツのタイプを確立するスケジュールを設定する。
【００２９】
この収集プロセスとは別に、ウェブキャスト・センタ５２は、ページ・キャッシュ６２からページを検索し、これらページを複合のファイルに束ね、そしてこれらをパッケージ・ストア６４に格納する。パッケージ・ストア６４は、好ましくは、ページ・キャッシュ６２とは別個のデータベースである。ウェブキャスト・センタ５２は、パッケージ・ストア６４からこのパッケージ・ファイルをフェッチし、このパッケージ・ファイルを個々のパッケージ（またはパケット）にセグメント化し、そしてこれらパケットを放送媒体５４を介して送信する。
【００３０】
放送媒体５４は、一方向性のネットワークであって、これにおいては、パッケージは、ウェブキャスト・センタ５２からクライアント５６（１）−５６（Ｍ）に対し、それらクライアントからのリターン通信を必要とせずに配信する。放送媒体５４は、共有式の高度に非対称のネットワーク・リソースとして特徴付けることができ、これは、（完全に存在しない場合でない場合）限られた低速のリターン経路を有し、これは、放送伝送を受けるように活性化されることを必要としない。この放送媒体５４は、ウェブキャスト・センタとクライアントとの間の分配ネットワーク全体を構成するようにしたり、あるいはより大きな分配ネットワーク内の１つのリンクとすることもできる。
【００３１】
放送媒体５４は、種々の方法で実現することができる。放送媒体５４は、例えば、１方向伝送に対し構成された無線ネットワーク（すなわち、衛星、ラジオ、マイクロ波等）として実現することができる。放送媒体５４はまた、２方向通信をサポートするネットワーク（すなわち、インターネット、ＬＡＮ（ローカル・エリア・ネットワーク）、ＷＡＮ（ワイド・エリア・ネットワーク））として構成することもできるが、これらは、ウェブキャスト・センタからクライアントまでの一方向性マルチキャストに対し使用することができる。
【００３２】
クライアント５６（１）−５６（Ｍ）は、種々のタイプの構成を表している。これらクライアントは、データ・パッケージを受けて再構成しそしてこれらパッケージをディスプレイ上でレンダーすることができる、本質的に任意のタイプの計算機デバイスとして実現することができる。１つの可能な実現例として、クライアントは、クライアント５６（１）、５６（２）で表すデスクトップ・コンピュータとして構成することができ、これらは、図４で後述するソフトウェア／ハードウェア・コンポーネントを具備して特別に構成する。クライアント５６（１）は、放送ウェブ・コンテンツを放送媒体５４から独立サービス・プロバイダ（ＩＳＰ：Independent Service Provider）６６を介して受けるのであり、放送から直接受けるのではない。他方、クライアント５６（２）は、放送イネーブル式のパーソナル・コンピュータであって、放送パケットを直接受け能力をもつものである。
【００３３】
放送イネーブル式ＰＣの１例の実現例は、ニューウェル外（Gabe L. Newell, Dan Newell, Steven J. Fluegel, David S. Byrne, Whitney McCleary, James O. Robarts, Brian K. Moran; William B. McCormick, T.K. Backman, Kenneth J. Birdwell, Joseph S. Robinson, Alonzo Gariepy, Marc W. Whitman, and Larry Brader）の1996年1月29日出願の同時係属中の“放送イネーブル式パーソナル・コンピュータ（BroadcastEnabled Personal Computer）”と題する米国特許出願08/503,055に記述されている。この出願は、マイクロソフト社に譲渡されており、言及により本文に含めるものとする。
【００３４】
クライアントの別の実現例は、クライアント５６（３）が表すウェブ・イネーブル式テレビであり、これは、セットトップ・ボックスまたは内部計算機ユニットを有し、これがウェブ・コンテンツの受信およびレンダーを可能にする。デスクトップ・コンピュータおよびウェブ・イネーブル式ＴＶに加えて、他の可能なクライアントは、ワークステーション、ラップトップ・コンピュータ、パームトップ・コンピュータ、ネットワーク・コンピュータ等を含む。
【００３５】
本発明の別の側面によれば、別の分配エンティティが、ウェブキャスト・センタ５２に対する“クライアント”として作用することもできる。図２に示したように、地域的独立サービス・プロバイダ（ＩＳＰ）６６は、放送媒体５４でウェブキャスト・センタ５２から受ける放送伝送の加入者とすることもできる。このＩＳＰ６６は、ウェブ・コンテンツを格納し、そしてこれを、従来の分配技術を使って、クライアント５６（１）のようなそれ自身の顧客に分配する。
【００３６】
中間分配エンティティの別の例として、二次ウェブキャスト・センタ６８が、一次ウェブキャスト・センタ５２の“クライアント”として機能することもできる。二次ウェブキャスト・センタ６８は、それ自身の独立の収集プロセスに加え、一次ウェブキャスト・センタ５２から受けたウェブ・コンテンツを放送媒体７０を介してクライアント５６（４）−５６（Ｍ）の集合に再放送する。この二重ウェブキャストセンタ・アーキテクチャの１つの実現例は、一次ウェブキャスト・センタ５２が衛星を介して国全体にあるいはグローバルに分配する一次ヘッドエンドであり、二次ウェブキャスト・センタ７０が、ウェブ・コンテンツをＲＦ（無線周波数）あるいはマイクロ波伝送を介して分配する地域的配信者となるものである。
【００３７】
ウェブキャスト・システム５０は、インターネットの限られた帯域幅に負担をかけずにウェブ・コンテンツを多く（可能性として数百万）のクライアントに対し有利に分配する。ウェブ・ページを１対多の放送媒体を介して放送することは、過負荷のＩＳＰ接続または低速のクライアント・モデム接続に起因するボトルネックを回避する。ＩＳＰは、放送媒体の１つのクライアントとすることができるため、放送代替は、ＩＳＰがＴ１またはＴ３接続のような追加のインターネット接続をインストールした場合にかかる費用の数分の一で追加の帯域幅を提供する。
【００３８】
また、ウェブキャスト・システム５０は、サーバ・スケーラビリティ問題に対処する。放送データを受けるために、ウェブキャスト・センタ５２に対し付加的コストなしで多くのクライアントを本システムに追加することができる。ウェブキャスト・センタ５２に対する負荷は、一定であるが、その理由は、これが、放送伝送を受けるクライアントの数に無関係に、インターネット上のサイトをアクセスするからである。
【００３９】
ウェブキャスト・センタ
図３は、ウェブキャスト・センタ５２のアーキテクチャをより詳細に示している。これは、全体として、サーバ・ユニット８０と放送ユニット８２とから成っている。サーバ・ユニット８０は、ウェブ６０からウェブ・ページを集めそしてこれらページを放送伝送に適したパッケージ・ファイルに変換することを担当する。放送ユニット８２は、このパッケージ・ファイルを放送媒体５４に伝送することを担当する。
【００４０】
人間の管理者は、スケジュール・データベース８４をセットアップし、これには、この管理者が収集を希望するウェブ・コンテンツのリストまたはディレクトリを含める。このディレクトリは、単一のサイトからのコンテンツあるいは多数のサイトからのコンテンツを表すことができる１つの集合のウェブキャスト・グループを指定する。このディレクトリは、各ウェブキャスト・グループのネームと、各グループに含めるべきウェブ・ページと、サーバ・ユニット８０がそのグループに対し新たな更新をフェッチすべき時間とを含む。
【００４１】
スケジューラ８６は、スケジュール・データベース８４から読み取りを行い、そして特定のウェブキャスト・グループに対するサイトおよび時間のスケジュールを確立する。スケジューラ８６が、特定のサイトからウェブ・ページを検索する時間であると判定したとき、スケジューラ８６は、ギャザラ（gatherer）８８を呼び出して、インターネット６０上のサイトからウェブ・ページを集める。ギャザラ８８は、スケジューラ８６が指示した仕様（管理者がスケジュール・データベース８４に入力したもの）にしたがって指定のグループをフェッチする。
【００４２】
各グループに対して、ギャザラ８８は、そのグループに対するウェブ・コンテンツを保有する１つ以上のサイトを訪問する。ギャザラ８８は、それらサイトの各々のルートＵＲＬ（Universal Resource Locator）においてウェブ・ページにアクセスする。このルートＵＲＬにおけるウェブ・ページは、一般に“ホーム”ウェブ・ページと呼ばれている。ＵＲＬは、ある特定のサイトからのリソースを要求するのに必要な特定のリソースについての全てを記述している。ＵＲＬは、ギャザラ８８がそのリソースを検索するのに使用するプロトコルと、そのリソースがあるコンピュータのネームと、そのリソースの経路とファイル・ネームを記述している。以下は、ルートＵＲＬの１例である。
【００４３】
【表２】
0004693988.tif 000003
【００４４】
ＵＲＬの“http: //”部分は、プロトコルを記述している。文字“http”は、ハイパーテキスト転送プロトコル（ギャザラがドキュメントを要求するために従いそしてリモート・サーバがそのドキュメントを供給するのに従う規則の集合）を表している。ＵＲＬの HYPERLINK "http://www.microsoft.com" www.microsoft.com部分は、そのドキュメントを保有しているリモートのホスト・コンピュータのネームである。この例では、マイクロソフト社のホーム・ウェブ・ページがこのルートＵＲＬで提示される。
【００４５】
ウェブ・ページは、代表的には、ＳＧＭＬ（Standard Generalized Markup Language）のような“マークアップ言語”で書かれている。ＳＧＭＬは、マークアップを形式化しそしてシステムおよび処理の従属性からそれを自由にするドキュメント表現の言語として公式に定義されている。ＳＧＭＬは、ドキュメントの構造を記述し、テキスト内のその構造を描写（delineate）するタグ技法を記述する言語である。詳細には、ウェブ・ページは、“ＨＴＭＬ（Hypertext Markup Language）”と呼ぶＳＧＭＬのサブセットを利用する。１つのＨＴＭＬドキュメントは、ＨＴＭＬマークアップ・コードまたは“タグ”の形態のフォーマット化命令を含むプレーン・テキストと考えることができる。それらタグは、ドキュメントをレンダーしプリントする方法を説明し、またこれは、ハイパーリンクを指定するのにも使用する。
【００４６】
ホーム・ページは、そのサイトに関する一般的なデータを含み、これは、追加のページに対するハイパーリンク（あるいは単に“リンク”）を提供するのが普通である。ハイパーリンクは、ホスト・コンピュータ上またはインターネット上で、他の関係するウェブ・ページを見い出すべき場所を記述するシンボルまたは命令である。１つのハイパーメディア・トピックからのハイパーリンクは、通常は、そのページの著者により確立され、そして代表的には、グラフィックのアイコンまたは強調されたキーワードとしてレンダーされている。以下は、単一のハイパーリンクを含むＨＴＭＬウェブ・ページの１部分の単純な例である。
【００４７】
【表３】
0004693988.tif 000004
【００４８】
ブラウザでレンダーすると、語“upgrades”は、強調および下線付きの一方または双方で現れ、そして鉤括弧内のテキストは、以下のように全く現れない。
【００４９】
【表４】
0004693988.tif 000005
【００５０】
この強調されたキーワード“upgrades”をクリックすることにより、ユーザは、ウェブ・ブラウザに対し命令をして、その下にあるＵＲＬを活性化することができる。この場合、その下にあるＵＲＬは、以下の通り、ルートＵＲＬのサブルートである。
【００５１】
【表５】
0004693988.tif 000006
【００５２】
ルートＵＲＬに添付した部分“/upgrades”は、リモート・ホスト・コンピュータ、またはこのホスト・コンピュータが指定する他のサーバ上の、ルートＵＲＬにあるホーム・ページよりも１つ深さレベルが下の、そのページの経路およびファイル・ネームを規定する。
【００５３】
ウェブキャスト・センタ５２の管理者は、ギャザラ８８がページを収集すべき深さを確立する。ある与えられたグループに対して、管理者は、深さ限界を設定して、ギャザラ８８で収集すべきホーム・ページの下のレベル数を指定する。例えば、管理者は、３レベルの深さ限界を定めるようにもできる。ギャザラ８８は、ホーム・ページ（深さ０）と、このホーム・ページと以下の構造を有する任意のＵＲＬとの間の全てのサブルートとを収集する。
【００５４】
【表６】
0004693988.tif 000007
【００５５】
ギャザラ８８は、このハイパーリンク経路を下方に進むことにより、そのハイパーリンクが指定した各ページまたはコンテンツを検索する。各ページに対して、ギャザラ８８は、好ましくは、そのウェブ・ページが参照する任意のインラインのイメージ・ファイルを素早く手に入れるように構成する。
【００５６】
これらページを集めると、ギャザラ８８は、それらページをページ・キャッシュ６２に格納する。１つの好ましい最適化技術は、ページを検索し格納する前にその変更日付をチェックすることである。ギャザラ８８は、それら日付を、ページ・キャッシュ６２内に既に保持していることのあるその同じページの変更日付に対してチェックする。それらページを集めた最後の時以後変化していないページ（すなわち、格納しているページと同じ変更日付を有するページ）については、コピーしない。しかし、最後に集めてから以降に更新されているページについては、検索しそしてページ・キャッシュ６２に格納する。このようにして、ギャザラ８８は、効率的な収集プロセスにおいてページ・キャッシュ６２に保持されたウェブキャスト・グループを効果的に更新する。
【００５７】
ギャザラ８８は、スケジューラ８６に対し、何時、あるグループ内の指定されたコンテンツ全ての収集を終了するかを知らせる。この後、ギャザラ８８は、スケジューラ８６が立てたスケジュールにしたがって次のグループへと進むことができる。このスケジュールが指図する場合には、ギャザラ８８は、ウェブキャスト・グループに対するページを継続的に収集することにより、ページ・キャッシュ６２内のページをルーチンでリフレッシュするようにできる。
【００５８】
ギャザラ８８がある１つのグループを更新すると、スケジューラ８６は、パッケージャ（packager）９０を呼び出して、そのウェブキャスト・グループをパッケージする。パッケージャ９０は、ページ・キャッシュ６２を照会して、そのグループ内にどのようなページがあるか、そのページがどれ位の大きさであるか、そしてこれらをどのようにしてパッケージ・ファイルに分割（partition）すべきかを判定する。１つの実現例では、ある１つのグループ内の個々のページは、以下のルールにしたがってパッケージ・ファイルに分割する。
【００５９】
【表７】
0004693988.tif 000008
【００６０】
同一のパッケージ・ファイル内に置くべき各ＵＲＬ集合に対して、パッケージャ９０は、ページ・キャッシュ６２からページおよび情報を検索し、そのグループについてのヘッダ情報を付加し、そしてそのパッケージ・ファイルをパッケージ・ストア６４に格納する。パッケージャ９０が、そのグループに対する全てのパッケージ・ファイルを完了すると、これは、スケジューラ８６に対し、このグループを更新したことを通知する。
【００６１】
この時点で、パッケージ・ファイルは、本質的には、放送準備ができ、したがって放送伝送に対しては、個々のパケットにパケット化することだけしか必要としない。このパッケージ・ファイルは、そのウェブキャスト・グループのウェブ・コンテンツのよりアップツーデートのバージョンを表している。このとき、放送ユニット８２は、このウェブキャスト・グループを放送することにより、このアップツーデートのバージョンをクライアントに提供することができる。
【００６２】
尚、スケジューラ８６、ギャザラ８８、パッケージャ９０は、好ましくは、ウェブキャスト・センタ５２にある１つ以上のコンピュータ上で実行するソフトウェアで実現する。これらプログラムは、それらコンピュータのディスク・メモリのようなメモリに格納し、そして処理ユニットで実行する。１つの可能な例として、ウェブキャスト・センタにおけるそれらコンピュータは、マイクロソフト社からのWindows（登録商標）NTまたはUNIXベースのオペレーティング・システムのようなサーバ・オペレーティング・システムを走らせるサーバとして実現することができる。スケジューラ８６、ギャザラ８８およびパッケージャ９０は、このサーバ上のオペレーティング・システム上で走るソフトウェア・モジュールである。
【００６３】
図３の参照を続けると、放送ユニット８２は、パッケージ・ストア６４内のパッケージ・ファイルを取り、これらを送信可能なパケットに変換し、そしてこれらパケットを放送媒体５４を介して放送する。放送ユニット８２は、好ましくは、放送ヘッドエンド（例えば、衛星アップリンク、ケーブル・ヘッドエンド、ＴＶ放送局等）において実現され、これは、サーバ・ユニット８０の同じグループのサーバ・コンピュータで構成したりあるいは構成しなかったりすることができる。放送ユニット８２をサーバ・ユニット８０から物理的に分離することが望ましい場合がある。サーバ・ユニット８０は、ウェブキャスト・グループ、スケジュール、クライアントの好み、およびウェブ・サイトにおける変更に応答してスケジュール・データベース８４を編集する際に、人間の管理者を必要とする。これは、ウェブキャスト・ヘッドエンドに人を配置することが実現可能でない場合がある。
【００６４】
放送ユニット８２に関して、管理者は、転送スケジュール・データベース９２をセットアップし、これは、何時またはどの頻度の種々のウェブキャスト・グループを放送媒体５４を介してクライアントに送信すべきかのリストを含む。管理者は、このデータベース９２をリモートから編集するか、あるいは放送ユニット８２がサーバ・ユニット８０から物理的にリモートである場合、その情報をネットワークを介してサーバ・ユニット８０からデータベース９２に転送する。ストア／フォワード・スケジューラ９４は、データベース９２を読み取ることにより、スケジュールしたウェブキャスト・グループに属するパッケージ・ファイル集合を放送媒体５４を介して送信すべきかを判定する。
【００６５】
パッケージ・ファイルの送信は、２ステージのプロセスである。第１のステージは、あるウェブキャスト・グループに属するパッケージまたはパッケージの集合を送信する時刻をアナウンスすることである。
【００６６】
このアナウンス・ステージの間において、ストア／フォワード・スケジューラ９４は、アナウンス発生器９６を呼び出して、やがて起きる放送送信のアナウンスを作成する。このアナウンスは、この放送ファイルの配信および受信に関する詳細の多くを含み、そしてクライアントがこれらパッケージを受信するかどうかを判断するための十分な情報を含む。このアナウンスは、例えば、送信するウェブキャスト・グループのネーム、送信のアドレス（または周波数）および時刻、それらパッケージのサイズ、このグループのＵＲＬの範囲、クライアントのブラウザのキャッシュまたはファイル・システム内にこれらパッケージを置くべきかどうか等を含むことができる。このアナウンスは、代表的には、それらパッケージ・ファイル自体よりも小さな大きさのオーダーである。
【００６７】
このアナウンスは、全てのクライアントが聴いている周知のアドレス上で送る。アナウンスは、好ましくは、セッション・アナウンスメント・プロトコル（ＳＡＰ）、すなわち、マルチキャスト・データをネットワークを介してアナウンスするのに通常使用されるプロトコルを使って送る。ＳＡＰプロトコル自体は、良く知られており、そしてハンドレイ（M. Handley）の“ＳＡＰ：セッション・アナウンスメント・プロトコル（SAP: Session Announcement Protocol", INTERNET - DRAFT, draft - ietf - mmusic - sap - 00. txt, 11/27/1996）に記述されている。
【００６８】
種々のアナウンス技術が本発明で使用することができる。適当なアナウンス技術の１つの例は、バードウェル等（Kenneth J. Birdwell, Brian Moran, Randy Sargent, Carl Witty, and David S. Byrne）の名で出願の“伝送アナウンス・システムおよびこれから起きる放送ネットワークを介するデータ伝送をアナウンスする方法（Transmission Announcement System And Method For Announcing Upcoming Data Transmissions Over A Broadcast Network）”と題する同時係属中の米国特許出願に記述されている。この出願は、マイクロソフト社に譲渡されており、言及により本文に含めるものとする。
【００６９】
このアナウンスを受けそしてこのウェブ・コンテンツ・パッケージを受信するかどうかを判断する時間をクライアントに許容するのに十分な遅延の後、ストア／フォワード・スケジューラ９４は、放送送信機９８を呼び出してそれらパッケージを送信する。放送送信機９８は、パッケージ・ファイルをパッケージ・ストア６４から検索し、そしてこれらパッケージ・ファイルを送信可能なパケットまたはパッケージにセグメント化する。パッケージのサイズおよびコンフィギュレーションは、使用する放送媒体およびトランスポートに依存して異なる。例えば、衛星送信に対し具体化した放送送信機は、１つのサイズおよびコンフィギュレーションのデジタル・パケットを作成し、一方で、ＬＡＮ送信に対し具体化した放送送信機は、それとは異なったサイズおよびコンフィギュレーションのイーサーネット（Ethernet）パケットを作成する。別の例として、放送送信機は、それらパッケージを、従来のテレビジョン放送におけるＶＢＩ（垂直ブランキング・インターバル）の１部分としてあるいはケーブルＴＶ送信の１部分として、搬送するように構成することもできる。放送送信機９８は、これらパッケージをそのアドレス（または周波数）並びにアナウンスにリストした時刻に（可能な限り近い時刻に）送信する。
【００７０】
放送送信機９８は、好ましくは、ロバスト一方向ファイル転送プロトコルを実装し、これは、放送媒体を通してのある一定の量のデータ・ロスから復元することができる。効果的なプロトコルの１つの例は、放送ファイル転送プロトコル（ＢＦＴＰ）であり、これは、ウィトニー外（Carl Witty, Kenneth Birdwell, and Randy Sargent）の名で出願された“データおよび冗長の情報を一方向ネットワークを介して配信するデータ配信システムおよび方法  （Data Delivery System And Method For Delivering Data And Redundant Information Over A Unidirectional Network）”と題する同時係属中の米国特許出願に詳細に説明されている。この出願は、マイクロソフト社に譲渡されており、そして言及により本文に含めるものとする。
【００７１】
尚、スケジューラ９４と、アナウンス発生器９６の種々の面と、そして放送送信機９８は、好ましくは、放送ユニット８２にある１つ以上のコンピュータで実行するソフトウェアで実現する。これらプログラムは、それらコンピュータのディスク・メモリのようなメモリに格納され、そして処理ユニットで実行する。
【００７２】
このウェブキャスト・センタ・アーキテクチャは、多くの利益を提供する。１つの利益は、サーバ・ユニット８０が実行するウェブ収集タスクを放送ユニット８２の放送タスクから分離することができることである。これは、それらユニットを物理的に分離しそして互いに独立に動作させることができるようにする。別の利点は、ウェブ６０とパッケージ・ストア６４との間のリンクと比べ、パッケージ・ストア６４と放送送信機９８との間のより信頼性がありまたより高い帯域幅のリンクを可能にすることにより、フレキシビリティを増進することである。これは、ウェブ６０とサーバ・ユニット８０との間の接続がダウンした場合でも、データがクライアントへ流し続けるのを可能にする。
【００７３】
別の利益は、サーバ・ユニット８０と放送ユニット８２との間の接続が放送できるよりも少ないデータを転送する場合でも、本アーキテクチャが、放送帯域幅全体を利用することである。放送ユニット８２は、パッケージ・ストア６４内の各パッケージ・ファイルを継続してサイクル動作し、そしてこれらをサーバ・ユニット８０からのアップデート間において多数回放送する。このサイクル動作は、放送ストリームにおける大きなロスの場合、この送信を受信するのに利用可能でないクライアントに備えて、信頼性を改善する。
【００７４】
本アーキテクチャのさらに別の利益は、二重キャッシュ構成である。ウェブから引き出したページは、最初はページ・キャッシュ６２に格納する。これらページは、次に続いて束にし、そしてパッケージ・ストア６４にパッケージ・ファイルとして格納する。この二重キャッシュ構成は、ギャザラ８８が１つのデータ・レート（例えば、モデムまたはＴ１接続の速度）でページを集め、そしてパッケージャ９０がパッケージ・ストア６４内のファイルをそれとは異なったデータ・レートで更新することができるようにする。さらに、放送送信機９８は、次にそれらパッケージ・ファイルを、ギャザラがウェブ・ページを収集する第１のデータ・レートとは異なっておりしかもそれより通常ははるかに大きな第３のデータ・レートで検索し放送することができる。このため、収集のタスクおよび性能は、放送のタスクおよび性能とは独立である。
【００７５】
クライアント
図４は、ウェブキャスト・システムに参加するクライアント５６のアーキテクチャを示している。このクライアント５６には、ウェブ・コンテンツを含む放送送信パッケージを受ける適当なハードウェアを装備する。ＩＳＰに接続したクライアントに対しては、このハードウェアは、ＩＳＰから電話線でパッケージを受けるモデムで構成することができ、そしてＩＳＰは、さらに放送媒体からそれらパッケージを受ける。ＬＡＮに接続したクライアントに対しては、このハードウェアは、ネットワーク・カード等で構成することにより、放送パケットのネットワークを介しての受信を可能にするようにできる。
【００７６】
クライアント５６は、アナウンス・リスナ（announcement listener）１００を有し、これは、アナウンス・アドレスに同調させることによりウェブキャスト・センタからそのアナウンスを受ける。このリスナが受けたアナウンスは、放送媒体５４を介して配信する将来のウェブキャスト・グループをアナウンスする。
【００７７】
クライアント５６は、ユーザがどのウェブキャスト・グループを受けるかを選択できるようにする。ウェブキャスト・センタは、スケジュール・データベース８４内の保持されたウェブ・コンテンツのディレクトリを時々ダウンロードする。このディレクトリは、クライアント５６にある加入データベース１０２に格納する。したがって、加入データベース１０２は、ウェブキャスト・センタが提供するウェブ・コンテンツを保持し、これは、ウェブキャスト・グループのネーム、このグループ内のページに対するＵＲＬ範囲等を含む。
【００７８】
このクライアントは、加入グラフィカル・ユーザインターフェース（ＵＩ）１０４をサポートし、これは、クライアント・プロセッサ上で実行して、ユーザが加入データベース１０２内のそのディレクトリをみることができるようにする。図５は、１つの可能なグラフィカル・レイアウトによる加入ＵＩ１０４を示している。このＵＩ１０４は、利用可能なコンテンツのリストを提示し、そしてユーザがこのウェブキャスト・グループの内の１つ以上を選択できるようにする。この例では、ＵＩ１０４は、CNBC，ESPN，MSNBCおよびSmithsonian Instituteの可能なウェブキャスト・グループを示している。ＵＩ１０４上のこのディレクトリはまた、そのグループ・ネームに続く括弧内にリストしたＵＲＬ深さレベルも示している。ユーザは、チェックしたＭＳＮＢＣボックスで示すように、そのネームの前のボックスをチェックすることにより１つ以上のグループを選択できる。また、加入ＵＩ１０４は、加入の費用、加入期間および分配の周波数等、他のタイプの情報を表示するようにもできる。
【００７９】
図６は、別の可能なスクリーン・レイアウトによる加入ＵＩ１０４’を示している。図６においては、このＵＩ１０４’は、ユーザが彼らの好みにしたがって選択するための１組のカテゴリを提示している。この例では、ＵＩ１０４’は、文献（literature）、ミュージック（music）、ニュース（news）およびスポーツ（sports）のカテゴリを示している。ユーザは、種々のカテゴリを選択し、そしてこれは、次に、そのカテゴリ選択に従う加入データベース１０２内の１つ以上のウェブキャスト・グループに翻訳する。
【００８０】
図５および図６に示した加入ユーザ・インターフェースは、例示目的で提供したものである。ユーザの好み等を入力する多くの異なった方法を有する多くの他のタイプのインターフェースを使用できる。
【００８１】
ユーザの好みに基づき、クライアント５６は、フィルタ１０６を作成して、ウェブキャスト・センタから放送された好みのウェブ・コンテンツを受け入れる一方、好みでないコンテンツを拒絶する。図４の実現例では、フィルタ１０６は、アナウンス・リスナ１００からのアナウンスを受け、そして加入データベース１０２内のクライアントの好みに基づいて、クライアントが対応するやって来るウェブキャスト・グループを受け入れるべきかあるいは拒絶すべきかを判断するように構成する。フィルタ１０６は、この判断プロセスにおいて役立てるため、そのグループ・ネーム、ＵＲＬ範囲およびそのアナウンスに含まれたその他の情報を調べることができる。この判断に依存して、フィルタ１０６は、受信機１０８を制御することにより、放送媒体５４からの関連するコンテンツ・パッケージを受信するかあるいは無視する。
【００８２】
もしこのアナウンスが、ＭＳＮＢＣサイトからのページのような希望するグループに対するものである場合、フィルタ１０６は、受信機１０８を呼び出し、そしてこれにどのポートでその入来するパッケージを受信するかを知らせる。フィルタ１０６はまた、受信機１０８に対し、アナウンスに基づいて、入来パッケージを格納するファイルにどのようなネームを付けるかを知らせる。受信機１０８は、それらパッケージを配信するためのプロトコルを解釈し、そしてそのパッケージ・ファイルを再構成する。この受信機は、そのパッケージ・ファイルをクライアントのハードドライブ上の一時パッケージ・ストア１１０に格納する。このパッケージ・ファイルが完了すると、受信機１０８は、フィルタ１０６に対し、この転送が成功であるかどうかを通知する。もしこの転送が失敗であった場合、その不完全なパッケージ・ファイルを削除し、そしてこのイベントをログする。
【００８３】
もしこのパッケージ・ファイルが無傷のままで到着したとき、受信機１０８は、アンパッケージャ１１２を呼び出して、パッケージ・ファイルからのウェブ・ページを再構成する。また、アンパッケージャ１１２は、放送媒体５４から受けたウェブ・ページが、このクライアントに既に格納されたのと同じウェブ・ページよりももっと最近のものであるかどうか判定するように構成することができる。１つの可能な状況では、ユーザは、このウェブキャスト送信とは独立にあるウェブ・サイトを訪問したことがあり、そしてウェブキャスト・センタが放送中のバージョンよりもより最近の、そのウェブ・サイトからのページをダウンロードしたことがある場合がある。この場合、クライアントは、そのより最近のバージョンに上書きすることはせず、アンパッケージャ１１２がアンパッケージしたウェブ・コンテンツを捨てる。ここで、ウェブキャスト・センタから受けたページがより最近のものであると仮定すると、アンパッケージャ１１２は、そのウェブ・ページを、ブラウザのキャッシュまたはファイル・システム１１４に格納する。この後、ブラウザ（図示せず）は、それらページにアクセスし、そしてこれらをクライアント上でレンダーすることができる。適当なブラウザの１つの例は、マイクロソフト社が販売するInternet Explorerブラウザである。
【００８４】
アノテータ（annotator）１１６は、そのウェブ・ページ内に含まれたハイパーリンクに注釈を付けるために呼び出すこともできる。アノテータ１１６は、すでに作動させたリンクと、ファイル・システムまたはキャッシュ１１４内にローカルに格納したコンテンツに行くリンクと、クライアントからリモートに格納したコンテンツに行くリンク間を区別する。この注釈は、それら３組のリンクを区分する異なったカラーを使用するか、あるいは異なったフォントまたはフォーマット・スタイルを使用することとすることができる。注釈を施したリンクは、ユーザが、そのコンテンツがローカルに利用可能でありしたがって即座のアクセスの用意があるかどうか、あるいはユーザがインターネットを介してそのコンテンツをアクセスしなければならない（何等かの遅延を伴うことがある）かどうかを素早く区別するのにより便利となる。
【００８５】
アナウンス・リスナ１００、加入ＵＩ１０４、フィルタ１０６、アンパッケージャ１１２、アノテータ１１６は、好ましくは、クライアントのコンピュータ、セットトップ・ボックス、またはテレビジョン上で実行するソフトウェアで実現する。これらプログラムは、ディスク・メモリまたはＲＯＭ（リード・オンリー・メモリ）のようなメモリに格納し、そしてプロセッサ上で実行する。１つの可能な例では、クライアントは、マイクロソフト社からのWindows（登録商標）95のようなグラフィカル・ウィンドウズ・ベースのオペレーティング・システムを走らせるパーソナル・コンピュータである。別の例として、クライアントは、Windows（登録商標）ブランドのオペレーティング・システムの派生物であるオペレーティング・システムを走らせるウェブ・イネーブル式テレビジョンである。
【００８６】
以上、本発明について、構造上の特徴および方法のステップの一方または双方に特有の用語で説明したが、添付の特許請求の範囲に記載の本発明は、この記述した特定の特徴またはステップに必ずしも限定されるものではない、と理解されるべきである。これら特定の特徴およびステップは、保護を請求する発明を実施するための好ましい形態として開示したものである。
【図面の簡単な説明】
【図１】  図１は、従来技術のインターネット・システムのダイアグラム図。
【図２】  図２は、ウェブ・コンテンツをウェブキャスト・センタから放送媒体を介して多数のクライアントに配信するウェブキャスト用のシステムのダイアグラム図。
【図３】  図３は、ウェブキャスト・センタの機能的ブロック図。
【図４】  図４は、１つのクライアントの機能的ブロック図。
【図５】  図５は、ユーザが、放送媒体を介して配信されるべき好むウェブ・コンテンツを選択できるようにする、クライアントにおいて実装した加入者ユーザ・インターフェースのダイアグラム図。
【図６】  図６は、第２の実現例による加入者ユーザ・インターフェースのダイアグラム図。
【図１】
0004693988.tif 000009
【図２】
0004693988.tif 000010
【図３】
0004693988.tif 000011
【図４】
0004693988.tif 000012
【図５】
0004693988.tif 000013
【図６】
0004693988.tif 000014