JPH11507456A - コンピュータネットワークを介してビデオデータを配信するためのシステム及び方法 - Google Patents

Abstract

(57)【要約】 ローカルサイト、及び／またはリモートサイトに格納されたビデオクリップをユーザのマルチメディア端末においてユーザが要求し、再生することができるビデオクリップ記憶・再生システム。ユーザが所望のビデオクリップを要求すると、この要求はローカル検索・再生ユニット（ＳＲＵ）を介してプライマリインデックスマネージャ（ＰＩＭ）により処理される。メッセージがＰＩＭに到達する前に、ローカルＳＲＵは要求されたビデオクリップがローカルサイトで利用可能かどうかを調べるために自身の記憶容量を確認する。ビデオクリップのいくつかがローカルサイトにある場合、ローカルＳＲＵはこの要求をＰＩＭへ通信し、ＰＩＭが特定のビデオクリップを利用できるか否かを決定する。ＰＩＭはオーディオ・ビジュアルデータが格納されている拡張されたＳＲＵを決定し、この情報をデータシーケンスインターフェース（ＤＳＩ）に送る。ＤＳＩはビデオクリップを収集し、ビデオクリップをユーザ端末へダウンロードする。ユーザはビデオクリップを見たり、コピーしたり、プリントすることが自由に出来る。好ましい実施例では、本発明による分散型ディジタルビデオクリップ分配システムは、ローカルサイト、および／またはリモートサイトに格納されたビデオクリップを提供する。このビデオクリップはインターネットから要求され、ユーザのマルチメディア端末により再生される。ユーザがウェブページに表示されている所望のビデオクリップを要求すると、要求はプライマリインデックスマネージャ（ＰＩＭ）へ迂回される。ＰＩＭは要求されたビデオクリップを格納し、ダウンロードが完了した最も近いサーバを見つける。本システムは、サーバを地理的に分散させるためにビデオクリップをアップロードし分散する手段と、ダイナミックロードバランシング、予約管理機能と、ビデオクリップの不法な複製を抑制するための保護手段をさらに有する。

Description

【発明の詳細な説明】 コンピュータネットワークを介してビデオデータを配信するためのシステム及び 方法 この発明は分散オーディオ／ビデオクリップ記憶検索システムに関し、特に、 遠隔地にローカルに記憶されたビデオ材料が、音声および関連するデータベース 情報を伴ってあるいは伴わずにユーザのマルチメディア端末により要求および検 索可能なシステムに関する。好適実施例では、この発明は遠隔的に記憶されたオ ーディオ及びビデオコンテンツがサーバから要求および検索可能であり、それに よりネットワーク容量を最大にし、送信遅延を最小にするシステムを提供する。 発明の背景 この出願は１９９５年６月７日にファイルした出願番号第08/486,517号の一部 継続出願である。 インターネットは世界中に広がったコンピュータを接続する疎結合のネットワ ークである。宛先アドレスを指定し、一連の「ホップ」を介してコンピュータか らコンピュータへメッセージをパスすることにより、インターネット上のどのコ ンピュータからでもメッセージを他のコンピュータに送信することができる。イ ンターネット上の各コンピュータ、すなわち「ノード」は固有のインターネット アドレスを有する。途中のコンピュータが通過中のメッセージを受け取ると、そ のコンピュータはメッセージの意図された宛先をチェックし、その宛先に従って メッセージを伝達する。 インターネットは規模および複雑さが急速に増大している。過去において、イ ンターネットの殆どのユーザは学者、研究者あるいは学会のユーザであった。イ ンターネットはその当時基本的にはコンピュータファイルの転送を可能にするた めに、電子メールおよびネットワークニュースを送受信するのに使用されていた 。 しかしながら、数年前にWorld Wide Web（"Web"あるいは"WWW"としても知られ る）が導入されてから、インターネットは、増大する他の種類の一般的関心事の データ、すなわち画像や記事の表示等を受け入れはじめた。 Webはインターネットに対するグラフィックユーザインターフェースを提供す る。「Webページ」は基本的にはテキストとグラフィック素材で構成されること が多く、インターネット中の「Webサーバ」として知られる多くのコンピュータ に記憶される。これらのWebページは「ＨＴＭＬ」（Hyper Text Markup Languag e）として知られる言語によりレイアウトおよびコンテンツに関して記述される 。インターネットに接続される特定のコンピュータは、ユーザがアクセスするた めの１つ以上のWebページすなわちＨＴＭＬフォーマットのコンピュータファイ ルを記憶することができる。 「ブラウザ」として知られるソフトウエアプログラムを用いて、所望のWebペ ージのロケーション（すなわちインターネットアドレス）を指定するか、あるい はもっと一般的にはWebページに「ホットリンク」することによりインターネッ ト上のWebページをアクセスし、見ることができる。一般的なブラウザとしてはL ynx，NCSAおよびNetscape Navigatorがある。所望のWebページは"http://intern et.address/directory/filename.html"フォーマットのＨＴＭＬファイルの正確 なロケーションを示す、ユニフォームリソースロケータ("URL")により指定され る。 ホットリンクは以下のようにして行われる。ユーザは最初に、ユーザのISP(イ ンターネットサービスプロバイダ)に配置されたコンピュータ上に大抵ある、公 知のアドレスを有するWebページをアクセスする。ISPはユーザにインターネット 接続をユーザに提供する組織である。そのWebページは、ＨＴＭＬフォーマット で指定されたテキストおよび視覚データに加えて、「リンク」、すなわち大抵の 場合、インターネット上の他のコンピュータ上に存在する他のWebページのイン ターネットアドレスを指し示す（URLのフォーマットの）埋め込み情報を含むこ とができる。ユーザは、（大抵の場合、マウスで指示し、クリックすることによ り）リンクを選択して、他のWebページをアクセスすることができ、他のWebペー ジはさらなるデータおよび／または追加のリンクを含むことができる。あるWeb ページがアクセスされると、その情報は、世界中のどこにあろうとも、その遠隔 地のコンピュータから、インターネットを介してユーザに送信される。 近時、Webはオーディオデータおよびビデオデータというような非常に複雑な 種類のマルチメディアコンテンツを扱うようになった。NetscapeのEMBEDタグの ような種々のＨＴＭＬ拡張機能によりWebページに埋め込まれている他の データを参照することができる。ブラウザの中には、テキストおよび画像以外の データを取り扱うことができないものがある。その他のブラウザは種々の方法で データを取り扱うことが出来る。例えば、NCSAモザイクは、データをユーザのコ ンピュータにダウンロードして未知の種類のデータの参照が可能であり、外部プ ログラムを任意に起動してデータを見たり、操作したりすることができる。最近 リリースされたNetscape Navigatorはもう一段進んだコンセプトを採用している 。ブラウザの拡張、すなわち「プラグイン」は自動的に起動され、遠隔のWebペ ージから受信したデータを取り扱う。Java言語（あるいは類似の言語）で書かれ たネットワークプログラムである「アプレット」のような他の手段を用いてブラ ウザ環境あるいはネットワークの機能を拡張することができる。 第１世代のWebコンテンツ、すなわちテキストと静止画像に比べて、オーディ オおよびビデオデータは極めて高い記憶容量および帯域が必要になる。特に、ビ デオファイルは約１０メガバイト乃至１０ギガバイトの大容量である。ユーザの 端末で、記録されたレートに近いスピードでビデオファイルを再生するためには 、ファイルは高速かつ一定のスピードで転送しなければならない。転送が遅すぎ ると、画像は最初に記録されたレートよりも遅いレートで再生される。スピード が均一でないと、ビデオは昔の映画のようにぎくしゃくして表示される。現在、 インターネット上のマルチメディアノードリンクを介して大容量のファイルを高 速に持続して転送することは不可能でないにしても困難である。データは遠くか ら送られてくることが多いので、多くの要因によって、伝送遅延を生じる場合が あり、場合によって、伝送の一部または全部を失う場合もある。 この属性は、一般的にWebおよびインターネットの急速な成長と考え合わせる といくつかの問題を引き起こす。現在、Webページのアクセスにより、インター ネットのトラフィック量が増大しつつあり、帯域の要求はすでに供給量を超えて いる。 さらに、Web上のあるコンテンツは非常に人気がある。現在のインターネット 技術では、Webページは特定のすなわち「専用の」遠隔サイトあるいはサーバか ら提供されるので、最も人気のあるサイトはオーバーロードになることが多い。 さらに、現在のインターネット技術によれば、ユーザ要求に対する各レスポンス は一般的に独立して送信される。言い換えれば、仮に、１００人のユーザが同時 に同一Webページの送信を要求すると、１００の独立した送信をこれらのユーザ に行わなければならない。これらの人気のあるWebページの多くは、インターネ ット上の多くのノードを介して送信されるので、要求されたデータと他の関連し ないデータとが同じ経路を介して送信されるため、要求が実質的にダブったり、 遅延したり、損失したりすることが起こり得る。ビデオデータを有するWebサー バが多くの要求を同時に受け付けたなら、すべてのファイルを全速で送信する能 力は一層悪化する。 従って、インターネットあるいは他の汎用ネットワーク上のオーディオ／ビデ オコンテンツへの改良されたアクセスを提供する必要性がシステムに要求される 。そのようなシステムは、コンテンツが遅延や中断なく要求したユーザに配信さ れることを保証する方策を講じる必要がある。 従来技術は、基本的にテキストあるいは画像データベースプロバイダに向けら れており、いわゆる「ビデオオンデマンド」である。これらのシステムは分散ネ ットワークの複数のコンピュータシステムにテキストデータおよびビデオまたは オーディオビジュアルデータを記憶するようには設計されていない。「ビデオオ ンデマンド」のコンセプトは基本的にリアルタイムのオーディオビジュアルデー タを非常に大量にかつ高速にダウンロードするためのホスト−クライアントアー キテクチャに基づいている。このようなシステムは、例えば、オンライン加入者 に、サウンドを伴ったノーカット映画を提供することを意図している。一般的に は、遠隔のユーザは、オーディオビジュアルデータを有する大型のメインフレー ムサーバと通信する。このようなシステムのホスト−クライアントアーキテクチ ャは、ビデオデータをプロバイダの大容量システムのみに配置してシステム内の 帯域制限要素を無くすことから生じたものである。プロバイダは、このデータを 配信するために使用されるハードウエアとソフトウエアは大容量記憶と高速送信 が要求され、知覚可能なデータの原形が損なわれたり、データが失われないよう に、実質的にエラーが無いことを保証しなければならない。 公知のかつ提案された「ビデオオンデマンド」システムは、所属する加入者に 「要求に応じて」ノーカット映画を提供するのに適した高価で複雑なコンピュー タ及び通信システムを有する。このようなシステムは、数百の同時ユーザの途方 もないビデオデータ配信要求を管理するための多重処理コンピュータシステムに 適応させるために大規模な並列コンピューターキテクチャを使用する。各多重処 理コンピュータは、多くの複雑に相互接続されたマイクロプロセッサを有した単 一の「メインフレーム」コンピュータおよびオペレーティングシステムである。 大規模並列コンピュータはさらに、かなりのかつ一定のレベルの内部データトラ フィックを維持する能力を有した非常に高速の内部データバスを有する。 大規模並列システムは３つの異なる欠点、すなわち（１）信頼性、（２）コス トおよび（３）率に応じて増減できないという欠点を有する。ビデオデータは記 憶容量が大きいので、システムを維持するには多数のハードドライブが必要であ る。この要求は実質的にコストの増大につながる。さらに、一般には、ハードド ライブはコンピュータシステムの最も信頼性の無い側面であり、多数のハードド ライブを使用することは、全体のシステムの信頼性をさらに損ねることになる。 さらに、集中化システムの基本構造により、率に応じて増減できない。 大型メインフレームを採用する別のシステムは、特別のハードドライブインタ ーフェースソフトウエアを作ることにより、ハードドライブのスループットを低 減する割合に応じて少数のユーザに配信するためのオーディオビジュアルデータ を記憶する。このソフトウエアは、コンピュータのオペレーティングシステムが どのようにコンピュータのハードドライブを使用するかを決定する。例えば、複 数ブロックの関連データは、ランダムの代わりに常にシーケンシャルに記憶する ことができる。これはさらに効率的なデータスループットレートに貢献するが、 そのようなシステムはわずかに４０の同時ユーザについてのみ適応する能力しか 有さず、インハウスの小規模ビデオ配信に適応している。 より大型の単一構造の機能ユニットを作るために複数のパーソナルコンピュー タをリンクした限定すなわち部分「配信」アーキテクチャが提案された。このシ ステムでは、ビデオデータは、単一のより大きなデジタルビデオ情報源を構築す るためにのみ配信される。例えば、長いビデオデータは、異なるマシンに別個に 記憶された断片から「動作中」につなぎ合わされる。従って、そのようなシステ ムはＡＴＭスイッチ技術を用いてこのアレイコンピュータの出力を１つ以上の連 続したビデオストリームにマージすることも可能である。 逆に、この発明は、信頼性を向上させるとともに、大型並列システムの何分の 一かのコストで同時に数千の所属ユーザを支持する能力を有した真のすなわち完 全な配信システムを提供する。好適実施例において、この発明は既存のここに記 載したネットワークアーキテクチャと結合して、既存のインターネットインフラ ストラクチャを使用して、オーディオ／ビジュアルコンテンツをエンドユーザに 迅速かつ効率よく配信する。 この発明は異なったデータベース（例えば、関連するが別個の「テキストデー タベース」および「オーディオビジュアルデータベース」）を区分けされた計算 および通信装置に配信するだけでなく、ネットワーク全体の性能を最大にするよ うにデータを分割し配信する。 この発明の一実施例において、不動産仲介人であるユーザはリストアップされ た不動産についての最新のオーディオビジュアル情報を受信する能力を有する。 現在、不動産仲介人は、不動産を検査し、不動産の写真を取り、その不動産につ いての情報を集めることを含めて、入手可能な不動産の関連する特徴を調べるの の何時間も費やしている。実際、時間的制約のために、一般的な仲介人が、リス トアップされた新しい家を見れるのは５０％に満たない。見込のある買手の希望 を確認し、その買手に選択された地域内で利用可能な地域共同体の範囲を紹介し 、潜在的買手が興味を示しそうな不動産を調べ、それらの不動産を潜在的買手に 紹介するのにはさらなる時間と努力がかかる。 この発明によれば、不動産業者の時間は、不動産を販売することに直接関連す る行為にさらに効率よく使用され、市場の動向に遅れないようにするのに必要な 時間集約的行為に使用されることはない。例えば、ビデオ端末上の不動産を見る ことが出来ることによって、不動産業者は潜在的な不動産を調べるのに費やす時 間を大幅に削減することができる。同様に、ビデオクリップを介して買手に不動 産を紹介することが可能となるので、潜在的買手とともに不動産を見て回るのに 費やされる時間も削減される。これにより不動産業者は不動産売買の最終決済手 続きや、不動産を販売するのに関連する他の行政上の義務により多くの時間を割 くことが出来る。さらに、ビデオ検索能力を持つことにより、不動産業者はその 不動産を再度訪れることなく顧客の記憶を常にリフレッシュさせることができる 。 発明の要約 この発明はビデオクリップ記憶検索システムに向けられており、それによりユ ーザはユーザのマルチメディア端末からのリクエストにより１つ以上のデータベ ースから収集した包括的なデータを受けとる。この包括的なデータは、対応する データベース情報に関連した選択されたビデオクリップの形態で提供される。 ビデオクリップ検索システムは分散コンピュータシステムあるいはネットワー クであり、それにより局部的かつ遠隔地に記憶されたビデオクリップおよびテキ スト情報が、ユーザのマルチメディア端末で要求かつ視認可能である。システム はデータベースインデックスマネージャ("IM")、拡張記憶検索装置（"拡張SRU" ）、データシーケンスインターフェース("DSI")、ローカルメモリおよび検索ユ ニット("ローカルSRU")およびユーザ端末モジュールに区分けされる。各部はシ ステムの運用と管理に重要な特徴を提供するが、必ずしも特定の物理的コンピュ ータあるいは通信部品に割り当てる必要は無い。 動作中において、ユーザは最初にユーザ端末においてリクエストを作成する。 このリクエストは、ローカルメモリおよび検索ユニット(ローカルSRU)を介して ユーザのプライマリインデックスマネージャ("PIM")に送信される。ローカルSRU はPIMが要求された情報について効率良くしらべ、場所を突き止め、報告するの を補助するために地域識別子をそのリクエストに添付する。ローカルSRUは、ユ ーザの殆どの要求されたビデオクリップを一時的に記憶し、問い合わせがユーザ のPIMに送られる前にローカルSRUは要求されたビデオクリップをポーリングする 。地域識別子を含み、何らかの局部的一致を反映させるように補正されたユーザ の問い合わせは次にPIMに送られる。 PIMは地域識別子を用いて要求されたビデオ情報を有するリモートIMを特定す る。さらに、PIMはローカルSRUに記憶されたビデオクリップが最新のものである か否かチェックする。次にPIMは自分のビデオクリップリストおよびリモートIM のリストを参照して要求された情報を検索する。その要求に応答するすべての入 手可能なデータのリストあるいは要約がローカルSRUを介してユーザに送信され る。ユーザは次にその要求を更新あるいは変更してユーザが見ることを 欲しているビデオクリップおよび／または他のデータの短縮リストを作成する。 短縮されたユーザの問い合わせは次にPIMに送られる。PIMは各要求されたビデ オクリップを前もって他のリモートIMに配置しておき、ローカルSRUに記憶され ていないビデオクリップを要求する各ユーザのためのDSIを作成し、DSIに対して 要求されたビデオクリップがどこにあるかを知らせることにより、要求されたビ デオクリップを検索してユーザ端末に表示する。DSIは要求されたビデオクリッ プを適当な拡張されたリモートSRUから収集し、この情報をローカルSRUに送信す る。 ユーザの問い合わせを満足する要求されたビデオクリップは次に、ユーザ端末 に表示される。ユーザはその結果を表示し、コピーし、および／またはセーブあ るいはプリントすることができる。標準のビデオカセットにコピーすることも可 能である。好適実施例においては、DSIはシステムの要求をさらに管理するため に、ビデオクリップの送信する順番を並び替える能力を有する。例えば、要求さ れたビデオデータは、ユーザから種々の距離で、システム中の種々のロケーショ ンに記憶および検索可能であり、異なる帯域および転送速度を有する異なる通信 ネットワークを介してアクセス可能である。好適実施例では、DSIは最適の経路 を決定し、要求された情報をダウンロードするためのスケジュールを組み、シス テムの共有部品に不当に負荷をかけずにユーザに高速で効率のよいサービスを提 供する。PIMは特定のビデオクリップが要求された頻度を記録し、これらの情報 から、即表示可能なように、特定のローカルSRUにこれらのクリップをコピーす るか否かを判断する。ビデオクリップが更新されあるいは削除されるに従い、PI Mは要求された更新をデータベースログに作成する。さらに、PIMはシステムのユ ーザの請求書情報を記録する。 この発明はさらに、ユーザがインターネットあるいは他のネットワーク上のWe bあるいはWebに類似したサイトからデータをアクセス可能にするビデオクリップ 記憶検索システムに向けられている。 最初に、特定のWebページオーディオビジュアルコンテンツがオリジナルサーバ から分離され、ユーザの端末に（地理的かつ電子的に）比較的近い距離にある地 理的に異なる地域の多数のサーバに配信される。これは、「ビデオID」をWeb ページに埋め込んで、間接的にビデオクリップを指定することにより容易になる 。ビデオIDを、そのクリップをダウンロードする任意のサーバと関連づけるため にデータベースがアクセスされる。これは、オーディオ／ビデオコンテンツを要 求すると思われるユーザに近いサーバ上に配置するように行われ、それにより、 通過するネットワークノードの数を最小限にする。さらに、あるサーバが過負荷 あるいはサービスしていない場合には、データはダイナミックに冗長であり、所 望のコンテンツが効率よく別のサイトから検索可能である。 この発明によれば、データは過去の使用、現在の使用、および予測される使用 に応答する構成のネットワークに配信される。これらの考察を最適化することに より、ネットワークトラフィックは低減可能であり、過負荷のサーバや通信リン クは回避可能である。さらに、地理的サーバは特定の地理的領域に特に関心のあ るクリップを保持するように構築可能であり、主題サーバはある主要な分野に関 連するクリップを保持するように構築可能である。 さらに、頻繁に要求されるクリップは待ち行列を作って一度に多数のユーザに マルチキャストすることとができる。これもまた、ネットワークトラフィックを 低減させ、応答性を良くする。 この発明の他の観点は、ユーザが検索されたビデオクリップと相互作用可能に する能力である。パーソナルコンピュータ上で物理的にビデオ情報を操作する技 術が知られている。例えば、ビデオキャプチャボードはテレビジョンあるいはＶ ＣＲからビデオ信号を受け取り後で編集あるいは見るためにビデオデータを記憶 することができる。この種のビデオボードおよびシステムは、"MPEG"(Motion Pi cture Experts Group)規格１および２、およびMotion "JPEG"(Joint Photograph ic Experts Group)のような圧縮プロトコルを採用して高度に圧縮された状態で ビデオデータを記憶し送信する。これによりビデオデータを加工するのに必要な メモリ容量と転送時間が低減される。このようなシステムにより、ユーザはコン ピュータ端末上で見て編集することが可能であるが、この発明と異なり、遠隔地 から高速に所望のビデオデータを選択し検索する能力を提供しない。 この発明の好適実施例において、ユーザはコンテンツプロバイダあるいはISP に口座を作る。この講座は、購読料、借り方勘定あるいは他の多くの公知の支払 い方法の形態が取り得る。ユーザがシステムを介して出資したコンテンツにアク セスすると、口座が更新される。このようにして、ユーザは所望の方法で、使用 料が請求され、購読料情報がチェックされて保存され、認証レベルが設定可能に なり認証されていない使用を防止するためのデータ保護がなされる。 このシステムは要求されたビデオクリップに対応した２次オーディオビジュア ル情報を提供することができる。不動産産業の図示する応用例において、２次オ ーディオビジュアル情報は、要求された不動産の近くに位置する、学校、ショッ ピングセンター、病院である。２次ビデオは調整システムを介して１次オーディ オビジュアルデータあるいはビデオクリップに関連づけられて、データエントリ 、データメモリ、およびシステム計算リソースの要求を最小にする。 さらに改良された実施例によれば、ユーザはダウンロードした情報を変更した らどうなるかを見ることができる。例えば、ユーザは潜在的買手に、リストアッ プされた家に、ポーチをさらに付加したらどのように見えるかを示すことができ る。 一般に、ビデオクリップをダウンロードするユーザの能力はこの発明により強 調される。ユーザがクリップを見たいとき、ビデオIDが検索され、地域データベ ースに送信される。地域データベースがビデオIDをローカルサーバに存在するク リップに一致させることができ、かつユーザの加入権が十分であれば、クリップ はローカルサーバからダウンロードされる。クリップがローカルに入手不可能な 場合、あるいはローカルサーバが過負荷の場合には、連続するさらに多くのサー バがその転送のために問い合わせを受ける。従って、最も高速な可能性のある経 路が選択されるので、ネットワーク上のトラフィックは最小限に抑えられる。 この発明の例示的実施例は不動産産業およびインターネット上でのビデオ配信 に向けられている。しかしながら、すぐに明らかになるように、この発明は、対 応するオーディオビジュアル情報への手近なアクセスが有用な広範囲の最終用途 に適用可能である。例えば、ビデオクリップ検索システムは小売業、斡旋業者、 旅行業者および他の多くの応用例に使用可能である。 図面の簡単な説明 この発明の特徴はこの発明の図示実施例の以下の詳細な説明および図面からさ らに容易に明らかになる。 図１はシステムの好適ヒエラルキーを示すブロック図である。 図２はどのようにしてビデオクリップ検索システムの種々のモジュールがアド レスされ得るかを示すブロック図である。 図３はビデオクリップ記憶管理のためのデータシーケンスインタフェースを示 すフローチャートである。 図４はインターネットを介してビデオクリップの配信を実現するこの発明の一 実施例のブロック図である。 本発明の詳細な説明 図１は、ビデオクリップ記憶装置と検索システムの好適実施例を表しており、 その構造化階層と前記システムを含む様々なモジュール（構成部分）を示してい る。図１に表されるように、本システムは一つあるいは複数のユーザー端末(use rterminal)１４を備えており、ローカル記憶装置と検索ユニット（“ローカルＳ ＲＵ”）１８、データ順序付けインタフェース（ＤＳＩ）３０、一つあるいは複 数の拡張記憶装置と検索ユニット（“拡張ＳＲＵ”）２６、及び一つあるいは複 数のインデックス（索引）マネージャ（管理部）（“ＩＭ”）２２を備えている 。 システムの概観によれば、ビデオクリップは初めに（主に）拡張ＳＲＵ２６に 記憶され、ＩＭ２２により探知され、分配（分散）される。ユーザーは、関心の ある映像（ビデオ）を、ローカルＳＲＵ１８を介して、主インデックスマネージ ャ（“ＰＩＭ”）２２と通信することにより得る。ＰＩＭ２２は、要求されたビ デオクリップの位置を捜し当て、そのビデオクリップの有効なダウンロードをユ ーザー端末１４に指示するためにＤＳＩ３０を生成する。端末１４とローカルＳ ＲＵ１８との接続は、同じコンピュータ内、または一つの建物（ビルディング） 内に設置されローカルエリアネットワークにより互いに接続された二つ以上のコ ンピュータの間で行なえる。 本システムの各構成要素を備えた一般的なソフトウェア・モジュール（構成部 分）と、各ソフトウェア・モジュールに対応付けられるデータベースは、以下の 表１に示される。本システムの各モジュールの好ましく限定されない具体的表現 も、以下に図１と表１を参照して述べられている。 ユーザー端末 ユーザー端末１４は、ユーザー（使用者）の本システムへのインタフェースで あり、一般的には、パーソナル・コンピュータ、ワークステーション、またはテ レビ受像機が上部に設けられた機器である。端末１４は、ローカルＳＲＵ１８に 接続されているか、あるいはローカルＳＲＵ１８に含まれており、ローカルＳＲ Ｕ１８の初期応答指令(initial interrogation)の後、ユーザーの要求をＰＩＭ ２２に送る。図１に示されるように、端末１４は、要求されたオーディオ−ビジ ュアルデータが記憶されているどの箇所、例えば、拡張ＳＲＵ２６または遠隔Ｓ ＲＵ３８、及び異なるシステムまたは異なる電信・電話システムのアドレスから でも、前記要求されたオーディオ−ビジュアルデータを得るために、ＰＩＭ２２ と通信する。端末１４は、要求されたオーディオ−ビジュアル情報を、ローカル ＳＲＵ１８を介して受信またはダウンロードする。 表１に示されるように、各ユーザー端末１４は探索と問合わせのインターフェ ース、オーディオ−ビジュアル表示インターフェース、及びオーディオ−ビジュ アルデータ減圧論理を備えている。前記探索と問合わせのインターフェースは、 ユーザのアクセスを、望まれるビデオ・クリップと他の情報のために応答指令で きるデータベースまたはインデックスに提供する。例えば、現実の状況での応用 例では、一つのそのようなデータベースは多重リストサービス（ＭＬＳ）を行な えている。 前記オーディオ−ビジュアル表示インターフェースは、検索されたビデオ・ク リップを処理する手法をユーザーに提供する。要求されたビデオ・クリップがユ ーザー端末１４に表示された後、ユーザーは例えば運転(play)、停止(stop)、休 止(pause)、早送り(fast forward)、早戻し(fast reverse)及び戻し(reverse)の 隠喩を用いて、本システムと対話することができる。ユーザーは、ユーザー端末 １４のウィンド内に作表された箇所に位置するクリップ内の特定の位置に“ジャ ンプ”することを選んでもよい。また、ユーザーのスクリーンの他のウィンドに 表示されるものを、ユーザーの対話のための二次的なオプションとして利用でき るリストにしてよい。 好ましい実施例では、映像（ビデオ）は記憶され、大いに圧縮された状態で本 システム内を移動し、やがてユーザー端末１４にて減圧される。この減圧論理と しては、商業的に利用される映像圧縮規格とプロトコル、例えばMotion Picture Experts Group（“ＭＰＥＧ”）規格１及び２、ＭＪＰＥＧ、Ｉｎｄｅｏ、また はＦｒａｃｔａｌを用いることができる。 ローカル探索と検索ユニット（ローカルＳＲＵ） ローカルＳＲＵ１８は、ビデオ・クリップと、拡張ＳＲＵ２６及び（または） 遠隔ＳＲＵ３８からダウンロードした情報とのための一時的な記憶箇所であり、 ユーザー端末１４を使うためにある。図１に示されるように、ユーザー端末１４ とローカルＳＲＵ１８は一つのコンピュータシステムとして接続されていてよい 。好ましい実施例では、ローカルＳＲＵ１８には一つあるいは複数のユーザー端 末１４が接続されており、各ローカルＳＲＵ１８は多くのユーザー端末１４を支 援することができる。例えば、ローカルＳＲＵ１８は、ローカルエリアネットワ ークのためのファイル・サーバーを、一つあるいは複数の不可欠な記憶装置また は接続された記憶装置とともに備えることができる。そのような実施例では、各 ユーザー端末１４は、ネットワーク接続、例えばネットワーク・ノードを介し、 伝統的なネットワーク・プロトコルとトポロジーを用いて、ローカルＳＲＵ１８ と 相互に作用する。 ローカルＳＲＵ１８内で用いるための適当な記憶媒体には、１、２または５ギ ガバイトのような大容量のハードディスク、高速光学デバイス、ＲＡＩＤデバイ ス、及びアクセスと作動を準備するための適度な数のビデオ・クリップを局所的 に記憶することができる他の媒体が含まれる。ローカルＳＲＵ１８のディスク記 憶容量の所定部分は、主ＩＭとリモートＩＭのオーディオ−ビジュアルデータ・ インデックス・データベースのサブセット（部分集合）を複写するのに必要な記 憶容量として設計されている。この情報は、どのビデオ・クリップが局所的に記 憶されるかを決める端末問合わせの間に用いられる。ビデオ・セグメント修正情 報も、インデックス・データベース内で支援され、問合わせ処理中にビデオ・セ グメント精度を維持する目的で前記ＩＭに戻される。追加記憶空間が必要とされ る事象では、追加記憶空間は稼働、非稼働、及び二次音声／映像リストのための 記憶容量を含むよう、前記ローカルＳＲＵに供給されてもよい。 オーディオ−ビジュアルデータの記憶に加えて、前記ローカルＳＲＵ１８はロ ーカル探索及び更新論理、領域識別子ビルダー、オーディオ−ビジュアルデータ ・ダウンロードインタフェース、及び（６）圧縮／減圧論理（表１）を備えてい る。 ローカルＳＲＵ１８の領域識別子ビルダー構成要素は、領域コードまたは識別 子を各ユーザー要求に接続する。前記領域識別子は、前記ＰＩＭ２２が指定され たリモートＩＭ３４と通信することと、リモートＳＲＵ３８に記憶されている要 求されたビデオ・クリップの位置を決めることを許容する。現実の状況でのデー タを配置して用いた実施例では、前記領域識別子はビデオ・セグメント中の特性 のＺＩＰコードでよい。この情報は、直接テキスト・データベースから取られて よい。しかしながら、（領域識別子（ＩＤ））フィールドがどの適切な項類また は記憶された情報のタイプ及び望まれる最終的な使い方のために適合する文脈感 知記述に合わせることができるかは、明らかである。 ローカルＳＲＵ１８は、ダウンロードされたビデオ・クリップをユーザ端末１ ４に、大いに圧縮された状態で送る。本発明の好ましい実施例では、この作動は ローカルＳＲＵ１８に接続されているオーディオ−ビジュアルダウンロードイン タフェース（表１）により、ユーザー端末１４でユーザーが見る間、すなわち “リアル・タイム”の前（または同時）に減圧して取り次がれる。ローカルＳＲ Ｕ１８も、以下に詳述するように、そのダウンロード・インターフェースを介し てＤＳＩ３０と通信する。ＤＳＩ３０は、反応する情報が見つけられた様々な位 置からの、ビデオ・クリップと他の情報のローカルＳＲＵ１８へのダウンロード を管理する。 ローカル探索及び更新論理は、主な二つの機能を供給する。第１に、ローカル ＳＲＵ１８は、問合わせがＰＩＭ２２に送られる前に要求されたビデオ・クリッ プのために、その記憶媒体を探索することができる。前記更新論理は、ＰＩＭ２ ２が局所的に利用できるビデオ・クリップが現行であるか否かを識別することを 許容する。それゆえに、ユーザーの要求がＰＩＭ２２に送られたとき、その要求 が、ビデオ・セグメントが局所的に記憶され（１）、現修正コードがビデオ・ク リップに結合されたか（２）否かを指示するよう変更される。もし、ＰＩＭ２２ が現時点でローカルＳＲＵ１８に記憶されたものを取り替えるクリップを捜し当 てた場合、ローカルＳＲＵ１８は通知され、古いデータが削除され、更新された ビデオ・クリップを含んでいるＳＲＵ２６から新しいデータがダウンロードされ る。 ローカル探索及び更新論理の第２の機能は、最も頻繁に要求される音声−ビデ オ・クリップを識別し、探知することにある。これらのビデオ・クリップは、ロ ーカルＳＲＵ１８内に含まれた記憶装置のために識別される。これは、一度予め 決められたローカルＳＲＵの記憶容量が到達し、最も激しく使われたビデオ・ク リップだけがローカルＳＲＵ１８に記憶されることを確実にする。本発明の一つ の実施例では、最も使用されない局所的に記憶されたクリップよりも多く用いら れるビデオ・クリップが識別されたとき、前記最も使用されないクリップはロー カルＳＲＵ１８内で前記多く用いられるビデオ・クリップに取り替えられる。他 の実施例では、ローカルＳＲＵ１８は最後の要求されたビデオ・クリップを、許 されるスペースに記憶してもよい。これらと他の記憶装置の交換との組み合わせ と管理手法を用いることもできる。 好ましい実施例では、ＤＳＩ３０は圧縮された型の情報を、ユーザー端末１４ にダウンロードするためにローカルＳＲＵ１８へ送る。ユーザー端末１４では、 伝統的な減圧規格を用いて減圧が行なわれる。しかしながら、ユーザーが音声映 像データを受信するためのテレビ・スクリーンまたは他の理知的でないデバイス を用いる場合、商業的に用いられる減圧規格（上述した）を介した減圧は、ロー カルＳＲＵ１８にて行なわれる。 主インデックスマネージャ ＰＩＭ２２は、本発明の主探索手段（ｅｎｇｉｎｅ）とデータベース管理モジ ュールである。表１に示されるように、ＰＩＭ２２は（ａ）インデックスマネー ジャの管理処理、（ｂ）テキストデータベース管理論理、（ｃ）記憶管理論理、 （ｄ）メッセージ経路指定論理、及び（ｅ）ＤＳＩと拡張ＳＲＵのコマンド論理 を備えている。好ましい実施例では、あらゆる使用例のために確定した機能が、 便利にまたは有効に、概念的に及び（または）物理的に一緒になるよう分類され ることは明らかであるとはいえ、ＰＩＭ２２は、二つの機能が特に同じ物理的な コンピュータ上に属す必要がないよう設計されている。 前記“インデックスマネージャの管理処理”（表１）は、高速な通信インタフ ェースのためのソフトウェア・インタフェースである（後述する）。これは、前 記ローカルＳＲＵ１８と前記テキストデータベースに通信インタフェースを供給 する。ユーザーの問合わせがＤＳＩ３０の生成を必要とするとき、“インデック スマネージャの管理処理”は、そのコンピュータ上の高速通信の現状態が予め決 められた限界を超えない限り（例えば４０−８０ユーザー）、そのコンピュータ 上にＤＳＩ３０を生成する。その場合、ＤＳＩ３０は異なるコンンピュータシス テム上に生成される。 前記“テキストデータベース管理論理”は、本システムを用いる際、テキスト ・データベースから組み込まれ、これらデータベース内に記憶されたテキストデ ータを管理し制御する。例えば、現実の状況の実施例では、“テキストデータベ ース管理論理”は、多重リストサービス（“ＭＬＳ”）データベースと接続され 、全ての分配（分散）されたネットワークにまたがるＭＬＳ問合わせを許容する 。 前記“記憶管理論理”は、“記憶エンジン”のシステムであり、最も適切な拡 張ＳＲＵ２６上の新しくかつ（または）更新されたまたはアップロードされたオ ーディオ−ビジュアルデータを配置するべきものである。オーディオ−ビジュア ルセグメントまたはクリップは、重複がローカルＳＲＵ１８への、またはＳＲＵ １８からの通信量を最小限にするとき、例えば非常に高速なネットワーク２４ま たは通信ライン１６にて、一つ以上の拡張ＳＲＵ２６に記憶することができる。 データをリモートＩＭ３４とＳＲＵ２８または他の拡張ＳＲＵ２６から一つの拡 張ＳＲＵ２６へ移動または複写する決定は、例えば様々なＳＲＵ２６上の利用で きる記憶スペースを計算するためのアルゴリズム、特定のビデオクリップの要求 、及びユーザーによる最も一般的な映像の要求の位置設定のためになされる。前 記“記憶管理論理”は、二重の情報を伝送し記憶するコストのようなパラメータ ーも探知し、各拡張ＳＲＵ２６が有効に利用され、どのＳＲＵ２６も“オーバー ロード”にならないことをことを確実にすることを支援する。 前記インデックスマネージャの“メッセージ経路指定論理”は、ローカルＳＲ Ｕ１８から区分された問合わせを受入れ、前記問合わせを解読し、その後分解さ れた問合わせをリモートＩＭ３４へ転送する。前記インデックスマネージャの“ メッセージ経路指定論理”も、リモートＩＭ３４から受けた応答を受入れ、理解 できる応答を公式化し、この応答をユーザーに中継する。 前記“ＤＳＩ及びＳＲＵのコマンド論理”は、直接ＤＳＩ３０とＳＲＵＳ２６ に通信しＤＳＩ３０とＳＲＵＳ２６を制御する機能を有するＩＭ２２を備えてい る。前記ＰＩＭ２２は、ＤＳＩ３０が拡張ＳＲＵ２６及び遠隔ＳＲＵ３８と通信 し、これらのＳＲＵに映像情報をダウンロードするよう指示できるように要求さ れたデータを通すために、このインターフェースを用いる。 前記“ＳＲＵコマンド論理”は、交互のＳＲＵ２６上の一般的な映像の重複を みる。また、これらの映像でユーザーが最も興味があるビデオセグメントの複写 を、地理的にユーザーに接近したＳＲＵ上に置く。目標は、頻繁にダウンロード される映像（“ＦＤＶ”）の数が既に多い（予め決められた値を超える）ＳＲＵ ２６上の二重データではない。データの複写（二重化）は、システム稼働がピー クでない期間中に、以下の論理に沿って実行される。ＰＩＭ２２は、この予め決 められた値を超えるＦＤＶレベルを有する拡張ＳＲＵ２６を管理するか否かを決 定する。この決定は、最も頻繁にアクセスされたビデオクリップを識別する“オ ーディオ−ビジュアルデータ・インデックス”データベース（以下に述べる）を 介して探索することによりなされる。この映像サブセットから、映像はその最も 用いられた箇所に基づいて、移動または重複（二重化）が選択される。もし前記 ＦＤＶが、ＰＩＭ２２により生成されたＤＳＩ３０から主として転送されたなら 、同じコンピュータ内に置かれた拡張ＳＲＵ２６は、ビデオクリップの二重複写 を受け入れることができるか否かを決定するよう評価される。そうであれば、前 記ＦＤＶは識別された拡張ＳＲＵ２６上に複写される。 拡張記憶及び検索ユニット（拡張ＳＲＵ） 上記したように、拡張ＳＲＵ２６は本システムのための素記憶機構であり、オ ーディオ−ビジュアルデータを複数のオーディオ−ビジュアル記憶媒体に記憶す るために用いられる。このセクションは主に拡張ＳＲＵ２６を参照するが、その 用語は要求されたオーディオ−ビジュアル情報の記憶も行なえるリモートＳＲＵ ３８を含んでいる。ソフトウェア・モジュールは、同一である。 最も要求されたオーディオ−ビジュアルデータ（ＦＤＶを含む）は、本システ ムのディスク記憶装置割当て表に最も近い連続する割当てブロックに書き込まれ る。非稼働のビデオセグメントは、前記“ディスク記憶装置割当て表”から最も 遠い連続する割当てブロックに記憶される。代わりの構成では、ディスク記憶装 置割当て表はＲＡＭ内または離れたコンピュータ上で維持される。ディスク記憶 装置は、各ビデオ・セグメントを常に連続する割当てブロックに記憶するマクロ 記憶セル内に編成される。これは、例えば２分のオーディオ−ビジュアルセグメ ントを記憶できる記憶セルを用いることで行なえる。 図１を参照すると、一つあるいは複数の拡張ＳＲＵ２６は、ＰＩＭ２２にてＤ ＳＩ３０が生成されるべきと決定した事象において、ＰＩＭ２２と各端末固有の ＤＳＩ３０に接続される。拡張ＳＲＵ２６は、要求されたデータをＤＳＩ３０に 向けて送り、ＤＳＩ３０、適切なローカルＳＲＵ１８を介して、最後にユーザー 端末１４に前記データを送る。 前記拡張ＳＲＵ２６は、ＳＲＵ管理処理、ＩＭコマンド・インタフェース、及 びＤＳＩコマンド・インタフェースを備えている。ＳＲＵ管理処理により、拡張 ＳＲＵ２６が直接ＩＭ２２及びＤＳＩと通信することができる。このインタフェ ースは、メッセージとアドレス指定されたデータパケットに応答する。また、ネ ットワーク伝送の目的のために、他のＳＲＵ２６またはＤＳＩ３０に伝送される ビデオデータを簡約する。ＳＲＵ管理処理は、ＳＲＵ２６が自身に伝送されたデ ータを記憶することを許容する。同様に、ＳＲＵ管理処理は、古いデータまたは 不必要な二重データを全て削除することができる。このデータの記憶及び削除は 、“ＩＭコマンド・インタフェース”を介してＰＩＭ２２方向のもとで行なわれ る。 前記“ＤＳＩコマンド・インタフェース”は、ＰＩＭ２２が拡張ＳＲＵ２６以 外にも機能することを許容するためにある。前記ＤＳＩコマンド・インタフェー スは、拡張ＳＲＵ２６に、起こりうるユーザー端末１４へのダウンロードのため に、オーディオ−ビジュアル情報をＤＳＩ３０の伝送バッファーにオーバーロー ドするように指示するよう構成されている。 データ順序付け（シーケンシング）インタフェース（ＤＳＩ） 本発明によれば、各ＤＳＩ３０は、拡張ＳＲＵ２６及びリモートＳＲＵ３８か らユーザー端末１４へ伝送されるデータを容易にするようＰＩＭ２２により生成 される。生成されると、ＤＳＩ３０は本システムの拡張部品またはローカル部品 内に属すことができるが、図１の好ましい実施例ではローカルに表されている。 このＤＳＩ３０は、拡張ＳＲＵ２６とリモートＳＲＵ３８の両方からローカルＳ ＲＵ１８へ伝送されたデータを収集し、管理し、バッファーに蓄えるとともに、 ユーザー端末１４へダウンロードする。 ＤＳＩ３０は、ユーザーがローカルＳＲＵ内に記憶されていないオーディオ− ビジュアル情報を要求したときはいつでも、ＰＩＭ２２により生成され、かつ( または)初期化される。好ましい実施例では、前記ＤＳＩ３０は、ビデオデータ ・ダウンローソ処理の直前に生成され、その後直ちに壊される。これは本システ ムが、問合わせその他のために一つの通信ネットワークを用いること、望ましく より広い帯域幅、ビデオデータ・ダウンロードのための通信ネットワークを用い ることを許容する。例えば、統合サービス・デジタル、ネットワーク（“ＩＳＤ Ｎ”）のＤチャンネル（“Ｘ．２５パケット”ネットワーク）接続により、ユー ザーの問合わせのＰＩＭ２２への転送とＰＩＭ２２からの応答の受信を含むよう 、ビデオ・ネットワークのビデオ問合わせトラフィックを運ぶことができる。一 度、ユーザーがどのビデオ・クリップが検索されたかを最終的に決めると、ＰＩ Ｍ２２ はＤＳＩ３０のために最も適切で有効な位置を識別し、その位置にＤＳＩ３０を 生成する。そのとき、詳しい“ＤＳＩビデオ・ダウンロード・リスト”は、ＰＩ Ｍ２２によりＤＳＩ３０に通される。ＤＳＩ３０はこのリストを、ＳＲＵに要求 された情報をダウンロードするよう指示するために用いる。 また、ＤＳＩ３０は、地理的に分散された多くのビデオデータソースを一つの 加入者宛先に接続することを許容する。 ＤＳＩ３０は、（１）ＤＳＩ管理処理、（２）オーディオ−ビジュアル順序付 け論理、（３）ＰＩＭインタフェース、（４）拡張ＳＲＵインタフェース、及び （５）ローカルＳＲＵインタフェースを備えている。 前記ＤＳＩ管理処理により、ＤＳＩ３０が直接ＰＩＭ２２、拡張ＳＲＵ２６、 リモートＳＲＵ３８、及びローカルＳＲＵ１８と通信することができる。 ＤＳＩ３０のための前記“オーディオ−ビジュアル順序付け論理”は、図２に 示したように広く作動する。前記“オーディオ−ビジュアル順序付け論理”によ り、ＤＳＩ３０はデータを再順序付けでき、記憶装置と検索ユニットのより有効 な用い方を提供することができる。その目的は、本システムが使用されていない 資源を、ネットワークの隅々まで利用できるようにすることにある。ＤＳＩ３０ は、ユーザーが各ダウンロードのために用いるべき電算システムと通信経路が何 であるかを、能動的に決定する。したがって、もし特定の拡張ＳＲＵ２６が他の ユーザーを支援することに忙しいなら、ＰＩＭ２２はユーザー端末１４のために リモート（遠隔）システム上にリモートＤＳＩ４２を生成してもよい。そのとき リモートＤＳＩ４２は、ユーザー端末１４と通信し、ダウンロード処理のための 信頼性を想定し、ユーザー端末１４にビデオデータ・ダウンロードの指示を行な う。 前記“インデックスマネージャ（管理部）インタフェース”は、（１）ＰＩＭ ２２とＤＳＩ３０の間のコマンド・インターフェース、及び（２）ＤＳＩ３０と ＰＩＭ２２の間のフィードバック機構を備えている。第１の例では、ＰＩＭ２２ は、要求されたビデオ情報をＤＳＩ３０のために収集する目的で、ＤＳＩ３０に 命令を送るために前記“インデックスマネージャインタフェース”を用いる。第 ２の例では、ＤＳＩ３０は問合わせされる各拡張ＳＲＵ２６の状態にあるＰＩＭ ２２を通知するよう、ＰＩＭ２２へ戻って知らせる。 前記“拡張ＳＲＵインタフェース”は、要求された情報をユーザー端末１４に ダウンロードするために、ＤＩＳ３０が識別された拡張ＳＲＵ２６にＤＳＩ３０ の伝送バッファーへダウンロードするよう指示することを許容する。このインタ フェースは、一般的に非常に高速なインタフェースであり、例えばＦＤＤＩまた は“ファイア・ワイヤ（Ｆｉｒｅ Ｗｉｒｅ）である。 前記ＤＳＩ３０は、そのビデオセグメント・ダウンロードをローカルＳＲＵ１ ８とともに調整するローカルＳＲＵインタフェースとして用いられる。ＤＳＩ３ ０とローカルＳＲＵ１８の間のインタフェースは、一般的に高速なインタフェー スであり、例えばＩＳＤＮである。また、ＰＩＭ２２の周囲のトラフィックが高 い場合、ＤＳＩコマンド論理が、ローカルＳＲＵインタフェース、ローカルＳＲ Ｕ１８とのリモート接続（上述した）を介して確立される。 データベース構成 このシステムは、リレーショナルデータベース又はフラット−ファイルデータ ベース、テキストインデックス及び／又はサーチエンジン、及び、オーディオ− ビジュアルクリップ及び／又はテキスト情報形式の生データを採用することがで きる。このシステムにおいては、field-orientedデータベースを使用することが でき、このようなデータベースでは各フィールドは、小括弧で閉じられて示され る。例えば、（フィールド１），（フィールド２）は、フィールド１及び２を有 するデータベースを示す。このデータベースが他のデータベースと関連付けられ ている場合、関連しているフィールドは、大括弧（[]）で示すことができる。従 って、以下に示される例では、データベース２が、フィールド３を介してデータ ベース１に関連付けられていることが示されている。 データベース１：（フィールド１），（フィールド２），［フィールド３］ データベース２：［フィールド３］，（フィールド４），（フィールド５） この発明では、ＰＩＭ２２ソフトウェアが、(１)テキストデータベース、(２) ＩＭリスト、（３）ＳＲＵリスト、（４）オーディオ−ビジュアルデータインデ ックス、及び、（５）オーディオ−ビジュアルアクセスリスト、のデータベース 構造を含むように設計されている。 この発明における図示された実施例では、ユーザは、ＰＩＭ２２を用いて、少 なくとも１つの“テキストデータベース”にアクセスすることができる。この“ テキストデータベース”は、検索可能なフィールドを有するレコードを含んでお り、このデータベースの１つに［ビデオＩＤ］がある。このデータベース内の各 レコードは、拡張又ＳＲＵ２６又はリモートＳＲＵ３８上に格納されているビデ オクリップに対応する。このデータベースは、前記システムによって保守するこ ともできるが、ひとつ又はそれ以上のサードパーティデータベース、例えば、Mu ltiple Listing Service（MLS）データベースや、他の適切なデータベース管理 “front-end”を使用することも可能である。 前記“ＩＭリスト”（テーブル１）は、データ検索時における対象特定データ ベースに必要とされる情報を格納する階層データベースであり、要求されたオー ディオ−ビジュアルデータを有するリモートＩＭ３４を識別するように機能する 。この“ＩＭリスト”は、（ＩＭアドレス），［地域（Regional）ID］，（Alte rnateアドレス）という構成を有する。地域データは複数のリモートＩＭ３４に またがるため、前記ＰＩＭリストデータには複数のリモートＩＭエントリがある 。前記（ＩＭアドレス）はネットワーク内の適切なリモートＩＭ３４の位置を見 つけるのに役に立つ。前記［地域ＩＤ］は、ＰＩＭ２２が、要求された地域識別 子に関連する情報を含んでいるとして断定されたリモートＩＭ３４と通信するこ とを可能とする。これによりサーバへのアクセス回数が減少され、従って、高速 ネットワーク２０上の通信が減少する。前記地域ＩＤは、ローカルＳＲＵ１８ソ フトウェアモジュールによるクエリー構成（construction of the guery）にお いて得られる。この発明の実施例においては、（Alternate Address）フィール ドはシステムの電話番号や電子アドレスであり、サードパーティであるデータベ ースプロバイダが用いられている場合にはリモートＩＭ３４への他のパスである 。 前記“ＳＲＵリスト”は、以下のように構成される。 （ＳＲＵ アドレス），（ＳＲＵ Under-runカウントレート），（ＳＲＵア クセスカウントレート） この（ＳＲＵ Under-runカウントレート）は、所定の期間、例えば２４時間 において、拡張ＳＲＵ２６又はリモートＳＲＵ３８が他のデータ要求を実行する ためにダウンロード中であり、このためにデータ要求を実行できなっか回数を追 跡するのに使用される。この（ＳＲＵ Under-runカウントレート）は、以下に検 討するＳＲＵモニタリングにおいて説明する。前記（ＳＲＵアクセスカウントレ ート）は、所定の時間内に、個々のＳＲＵがビデオデリバリのために何回使用さ れたかを監視する。 前記“オーディオ−ビジュアルデータインデックス”は、各ビデオクリップを 識別し、その位置を特定する。この“オーディオ−ビジュアルデータインデック ス”は以下のような構成である。 ［ビデオＩＤ］，（ＳＲＵアドレス），（位置コード），（修正コード），（ 初期コピーフラグ），（使用カウントレート），［補助アレイＩＤ］ 前記のように、［ビデオＩＤ］は、各ビデオクリップのための一義的な参照識 別子であり、テイストデータベースのテキストフィールドに対応する。（ＳＲＵ アドレス）は、要求されたオーディオ−ビジュアル情報を含むＳＲＵのネットワ ーク位置を特定する。（位置コード）は、ＳＲＵ内のビデオクリップの正確な物 理的位置を示す。（修正コード）は、ビデオクリップのバージョンが最新のバー ジョンであるか否かを示す。（初期コピーフラグ）は、新しいビデオクリップエ ントリそれぞれに追加されたフィールドであり、これによりシステムは、前記ビ デオクリップのバージョンが更新されたものであるか、複製されたのものである のか、又は、データベース全体からは削除されてはいないが、より遠い格納位置 に移動されたのであるのかを認識することができる。（使用カウントレート）は 、所定の時間間隔内に、例えば、２４時間以内に、個々のビデオクリップが何回 要求されているかを追跡する。この情報は、ＦＤＢ状態の判定に使用される。［ 補助アレイＩＤ］は、“関連付けられた”補助のデータベース、又は、関連する ビデオ又はテキスト情報（図示せず）を指摘するために使用される。 従って、補助情報が設けられている実施例、不動産実施例(real estateembodi ment)は、要求されたデータに関する追加情報が設けられていることにより、ユ ーザが利用可のなテキスト及びオーディオ−ビジュアルデータが増加する。例え ば、不動産用途のための好ましい実施例では、補助データベースは、要 求されるすべての不動産物件ビデオに関連する病院、学校、及び交通形態などの オーディオ−ビジュアル情報を含んでも良い。 この不動産の例では、補助データベースを以下のように構成することができる 。 ［補助アレイＩＤ］，（セグメント座標） ［補助アレイＩＤ］は、ＰＩＭ２２が、補助データが使用可能であることを通 知するために使用される。（セグメント座標）は、前記補助情報に対応する地理 的なエリアを示す。この地理的なエリアの境界は、地図から得られる、又は、好 ましくはＧＰＳにより得られる緯度及び経度によって表示することができる。地 理上のエリアは、一般には複数の不動産物件項目を含むので、補助データベース の各エントリは、複数のビデオクリップエントリに対応する。 “オーディオ−ビジュアルアクセスリスト”は、以下のフィールドで構成され ている。 ［ビデオＩＤ］，（ＩＭアドレス），（アクセスレート） このデータベースは、管理処理の特徴における“コンピュータシステム”をサ ポートするＤＳＩ３０のリスト、又は、オーディオ−ビジュアル情報が送られる 最も近いＩＭアドレスを保守する。ＤＳＩ３０は、複数のＳＲＵからのデータを 要求する。ＤＳＩが特定のＳＲＵからのデータ取得に成功した場合、管理ＩＭの “オーディオ−ビジュアルアクセスリスト”データベースは、ネットワーク内の 物理的位置へのビデオセグメントのデリバリを反映するように更新される。この ネットワークは、現時点では個々のＳＲＵからのビデオセグメントそれぞれの宛 先を示す情報を有する。この情報は、ネットワーク格納管理ロジックにより分配 されるビデオ及び／又はビデオのコピーのための、最も重要な宛先を判断するた めに使用される。 ビデオクリップのための主記憶位置の設置とは別に、拡張ＳＲＵ２６は、“ア クティブＡ／Ｖ項目”、“インアクティブＡ／Ｖ項目”、“補助Ａ／Ｖ項目”、 及び“リモートＡ／Ｖ項目”から構成される。各項目の用途は、不動産用途と関 連付けて説明する。不動産事情によれば、新しい不動産物件項目は、ユーザにと って一般的に大変興味深く、従って、“アクティブＡ／Ｖ項目”を構成する。古 い不動産物件項目は、頻繁に選択されることは無く、“インアクティブＡ／Ｖ項 目”を構成する。しかし、不動産物件の状態の変化により、例えば、不動産物件 価格の低下により、その不動産物件は“アクティブＡ／Ｖ項目”に戻る。“補助 Ａ／Ｖ項目”は、何らかのビデオクリップに関連した補助情報を有する。“リモ ートＡ／Ｖ項目”は、概して、既に売買された不動産物件を構成する。この情報 は、価格の比較目的に使用されるが、かなり頻繁にはアクセスされない。 拡張ＳＲＵ２６上に格納されているオーディオ−ビジュアルデータは、ビデオ クリップそのものである。この発明の好適実施例では、ビデオデータは、約２分 間のオーディオ−ビジュアルデータに等化な、拡張ＳＲＵ２６上の格納ブロック に格納される。この格納ブロックの実際の長さは変動し、ビデオデリバリアプリ ケーションに依存する。オーディオデータは、ＳＲＵの同様の長さのブロックに 格納される。オーディオ及びビデオセグメント全体は、ビデオデータとオーディ オデータとが別々に又は一緒に格納されるように、隣接して格納することができ る。 ローカルＳＲＵは、“ローカルオーディオ−ビジュアルインデックス”及び“ 実オーディオ−ビジュアルデータ”を含む。ローカルＳＲＵ１８に格納されてい るオーディオ−ビジュアルデータは、前記拡張ＳＲＵ２６に格納されているデー タと同様の構成を有する。“ローカルオーディオ−ビジュアルインデックス”は 、以下のデータフィールドにより構成される。 ［ビデオＩＤ］，（位置コード），（修正コード） ［ビデオＩＤ］は、テキストデータベース内のフィールドに対応し、ビデオク リップを識別する。（位置コード）は、ローカルＳＲＵ１８内のビデオクリップ の正確な格納位置を特定する。（修正コード）は、格納されているビデオクリッ プのバージョンが最新のものであるか否かを示す。 ＤＳＩ３０が作成された時、ＰＩＭ２２は、要求されたビデオクリップを識別 するデータ構成と、各ビデオクリップの正確な位置とを送信する。データ構成を 以下に示す。 ［ビデオＩＤ］，（ＩＭアドレス），（ＳＲＵアドレス），（位置コード）， （ＳＲＵアクセスカウントレート），（ＳＲＵ Under-runカウントレート） これら、［ビデオＩＤ］、（ＩＭアドレス）、（ＳＲＵアドレス）、（ＳＲＵ アクセスカウントレート）、及び（ＳＲＵ Under-runカウントレート）は、前述 した機能と同様に機能する。［ビデオＩＤ］フィールドは、残りのフィールドが ［ビデオＩＤ］フィールドのサポートフィールドである状態での原理フィールド である。特定の［ビデオＩＤ］に対応する各ビデオセグメントは、複数の特定の 格納位置を有することが可能であるので、ＤＳＩ３０は、このＤＳＩ３０のビデ オデータダウンロード構成で、前記ビデオセグメントの個々の格納位置のための 複数のレコードを有することができる。従って、任意のＳＲＵがオーディオ−ビ ジュアル情報をダウンロードして他の要求を実行しいているため、ＤＳＩのコマ ンドに応答できない場合、ＤＳＩ３０は、要求されたビデオクリップを他の位置 から検索するのみである。 ビデオクリップの格納 新たなビデオクリップを受け取った場合、ＰＩＭ２２は先ず、拡張ＳＲＵ２６ とリモートＳＲＵ３８のいずれがこのオーディオ−ビジュアル情報を格納するの かを判定する。ＰＩＭ２２は、ビデオセグメントの地域をサポートするＩＭ３４ を、地域識別子を比較することにより識別する。ＰＩＭ２２は、これらのＳＲＵ が使用可能なＦＤＶ記憶領域を有するか否かを認識する。これは、最も新しいビ デオクリップ項目がＦＤＶ記憶領域に格納されるためである。十分な大きさのＦ ＤＶ記憶領域がある場合、ビデオクリップはそのＳＲＵ（２６又は３８）に格納 され、監視ＩＭ（２２又は３４）Ａ／Ｖデータインデックスデータベースが更新 される。しかし、適切なＦＤＶ記憶領域が無い場合、ＰＩＭ２２は、最下位のＦ ＤＶ割り当てがなされているＳＲＵを判定し、前記ビデオをこのＳＲＵに格納す る。 ビデオクリップは以下のように格納される。（１）ビデオは、格納のためにＳ ＲＵに送られる。（２）“ＳＲＵ監視プロセス”はディスクに情報を書き込み、 データの格納位置をＰＩＭ２２に返す（格納位置メッセージのフォーマットは、 ＵＮＩＸ，ＤＯＳなどのファイルタイプに依存する）。（３）ＰＩＭ２２は、Ｐ ＩＭ２２上の“Ａ／Ｖデータインデックス”データベースに前記ビデオクリップ の格納アドレスを書き込む。 ビデオクリップの検索 図３は、この発明の好適実施例において、データのサーチ及びダウンロードが どのように行われているかの概要を示す。ユーザは、先ず、ユーザ端末１４でテ キストデータベースからデータクエリーを作成する。例えば不動産用途では、ユ ーザは、ＭＬＳより選択された不動産物件条件を指定することができる。一端作 成されると、このクエリーは、ローカルＳＲＵ１８を介してＰＩＭ２２に送信さ れる。ローカルＳＲＵ１８は、以下の手法でクエリーを修正する。ローカルＳＲ Ｕ１８は、（１）前記クエリーに地域識別子を付加し、（２）自身のデータベー スを検索し、リクエストに修正コードを付加することによりローカルＳＲＵ１８ に格納されている各リクエストに印を付ける。オーディオ−ビジュアルデータイ ンデックスは、拡張ＳＲＵ２６に格納されているオーディオ−ビジュアルデータ の正確な位置を特定し、リモートＩＭ３４を介してリモートＳＲＵに格納されて いるビデオデータの位置を特定する。ＰＩＭ２２は、地域識別子を用いていずれ のリモートＩＭ３４が要求されたビデオセグメントを含んでいるかを特定する。 特定されたリモートＩＭ３４のそれぞれは、クエリー、リストの返送、又は、Ｐ ＩＭ２２に使用可能なオーディオ−ビジュアルリファレンスの要約のための処理 を行う。ＰＩＭ２２は、修正コードを使用し、ローカルＳＲＵ１８に格納されて いるビデオセグメントが最も最新の使用可能な複製であるか否か判定する。その 後、ＰＩＭ２２は、ユーザの端末１４に全ての使用可能なビデオクリップのリス トをダウンロードする。ビデオセグメントの最新のコピーがローカルＳＲＵ１８ に格納されているので、このリストには、どのビデオクリップが直ちに使用可能 であるかが示されている。 ユーザは、データベースレコードとオーディオ−ビジュアルリファレンスとを マッチングしているリストを使用することにより、更に表示したり操作したい、 個々のレコード又はレコードグループを指定、選択する。この短縮リストは、Ｐ ＩＭ２２に送られる。ＰＩＭ２２は、ＤＳＩ３０を作成し、要求された各ビデオ クリップの正確な格納位置をＤＳＩ３０に通知する。ＤＳＩ３０はシーケンシャ ルに、拡張ＳＲＵ２６及びリモートＳＲＵ３８それぞれに照合し、可能であれば 、ＳＲＵへ正確なビデオクリップの位置を通知する。ＤＳＩ３０は、要求された 各ビデオクリップに対応する複数のアドレス位置を有することが可能であり、こ れ らのいくつかの位置は、拡張ＳＲＵ２６上であり、他はリモートＳＲＵ３８上に ある。ＤＳＩ３０は、リモートＳＲＵ３８からのビデオクリップの検索を試みる 前に、先ず、拡張ＳＲＵ２６から前記情報を取得することを試みる。これにより 影響を受けたＳＲＵは、ローカルＳＲＵ１８が情報を検索する準備ができるまで 、要求されたデータをダウンロードして、ＤＳＩ３０のバッファに送る。このＤ ＳＩでは、ＲＡＭに所定の数のビデオクリップを格納することができる。ＤＳＩ ３０はＳＲＵアクセスカウンタを更新し、この情報を、ＳＲＵ上の要求監視に使 用するためにＰＩＭ２２に送る。ローカルＳＲＵ１８によって一旦データが受け 取られれると、ローカル１８は、ユーザ端末１４にビデオクリップをダウンロー ドする。 照合されたＳＲＵが現在データの配信中である場合、ＤＳＩ３０は、代替ビデ オアドレスを使用して他のＳＲＵからのビデオクリップの検索を試みるか、もし くは、次のビデオセグメントの検索を実行する。ＳＲＵが要求されたビデオクリ ップの配信に失敗する度に、ＤＳＩ３０は、ＳＲＵの前記ＳＲＵ under-runカウ ンタをインクリメントし、最終的には、この情報をＰＩＭ２２に送る。ＳＲＵ u nder-runカウントが所定の閾値（生成され前記ＤＳＩに送られている）を越えた 場合、ＰＩＭ２２は、ＤＳＩ３０に代替ＳＲＵに対して前記ビデオクリップ情報 のための照合を行わせることにより、影響を受けたＳＲＵから更なる要求を指示 する。ビデオクリップがこの位置にのみ格納されている場合、ＤＳＩ３０がビデ オ情報がダウンロードされるまで待つことによる遅延が生じる。ＰＩＭ２２は、 これにより影響を受けた拡張ＳＲＵ２６に従ってＦＤＶの数をデクリメントする 。 更に、ＳＲＵ under-runカウントパラメータは、“オーバーアクセスされた(o ver-accesed)”ＳＲＵの位置を特定するので、ＳＲＵへの要求を分配、均一にす るため、オーディオ−ビジュアルデータは、大量の負荷がかかっているＳＲＵか ら、より少ない負荷のＳＲＵに（それらのunder-runレベルに応じて）移動又は 複写される。このような負荷管理プロセスは、オフピーク時に行われる。データ の複写又は転送に選択されたＳＲＵは、ＰＩＭ２２上に位置する“オーディオ− ビジュアルアクセスリスト”から得られる使用情報に従って特定される。 好ましくは、データは、（１）データが頻繁に照合される拡張ＳＲＵ２６上に 保持されるか、（２）頻繁にデータを要求するローカルＳＲＵ１８上に複写され るか、又は、（３）容量が許せば他のリモートＳＲＵ１８に複写される。このよ うな需要と供給の取り組みは、ＤＳＩ監視入力に応じ、ＰＩＭ２２により調停さ れており、パフォーマンスの浪費や無駄が無く、且つ、余剰を最大限に利用した 状態で、最も多く要求される情報への高速のアクセスと十分な記憶容量とを提供 することができる。又、その代わりとしてネットワークを、常に各オーディオ− ビジュアルエントリを少なくとも他の１つの位置（間隔をおいて）に格納するよ うに構成することもできる。このような重複によりスループットが向上し、信頼 性が高くなる。 通信インターフェース 図１に示すように、本実施例のシステムには、主インデックスマネジャー（Ｐ ＩＭ）２２とデータ順序付けインタフェース（ＤＳＩ）３０と通信するための拡 張形ＳＲＵが複数設けられている。これにより高い自由度、高いキャパシティ、 高いスループットを持ったシステムが実現されている。これにより、必要に応じ てシステムを拡張するのが容易になり、またビデオクリップや他のデータをシス テムに効率的に分散させたり、バックアップを取ったりすることができるように なっている。また、図１に示すように、ビデオクリップシステムは、遠隔地のビ デオクリップや他のデータにアクセスするために、他のシステムと通信可能にな っている。 ＰＩＭ２２と遠隔のインデックスマネジャー（ＩＭ）３４との間では、問い合 わせとその結果とが主に通信される。この通信には、本実施例では、超高速ネッ トワーク２０、例えば毎秒１００メガバイトという高速通信可能なファイバを使 った分散形データインタフェース（ＦＤＤＩ）が採用されている。ＰＩＭ２２は 、同様の超高速ネットワーク３２を経由して、ＰＩＭ２２と同じコンピュータ上 に設けられる拡張形ＳＲＵ２６と通信する。なお、これに代えて、超高速ＡＴＭ ネットワーク等の他のネットワークを採用してもよい。このネットワークでは、 拡張形ＳＲＵ２６は、広域ネットワーク（ＷＡＮ）という形態で分散される。Ｐ ＩＭ２２は、さらに、ＩＳＤＮのような高速ネットワークを経由してローカル形 ＳＲＵ１８と通信する。ＤＳＩ３０が設けられているときは常に、ＰＩＭ２２は 、ネットワーク３６を経由してＤＳＩ３０と通信し、ＰＩＭ２２と拡張形ＳＲＵ ２６との通信は超高速インタフェース（例えばＦＤＤＩ、ファイヤライン、ＡＴ Ｍ）を介して行われる。 拡張形又は遠隔形のＳＲＵ２６（又は３８）とＤＳＩ３０との通信は、例えば ＦＤＤＩといった超高速インタフェース２４を介して行われる。この通信インタ フェースにより、オーディオやビジュアルデータのような膨大なデータ量を高い スループットで通信することができる。これに対して、ＤＳＩ３０とローカルＳ ＲＵ１８との間の通信インタフェース２８は、経費のあまりかからないＩＳＤＮ インタフェースを経由して行われる。約１５f.p.sというビデオ信号をリアルタ イムで扱うためには、ＤＳＩ３０とローカルＳＲＵ１８との間に、少なくとも５ ６ｋボーという通信インタフェース２８が必要になる。通常は、ローカルＳＲＵ １８とユーザ端末１４は、超高速通信インタフェースと同じコンピュータ上に設 けられる。 遠隔のＩＭ３４は、図１の遠隔ＳＲＵ３８のように、自己の拡張形ＳＲＵにリ ンクされる。遠隔のＳＲＵ３８は、上述した拡張形やローカルの仕様と同じ自由 度を持った階層構造によって、遠隔のＤＳＩ４２や、他のローカルＳＲＵ４４や 、他のユーザ端末４８と通信することができる。 ［実施例］ 以下、本発明の代表的な実施例を幾つか挙げ、本発明をいかに有効に実施し得 るかについて述べる。なお、本発明はこれら実施例に限定されない。これら実施 例に加え、多くの他のビデオクリップ検索システムのアプリケーションが実現可 能であって、これらは本発明の範疇であることは容易に明らかである。 実施例１−不動産 不動産データを利用する本発明の実施例において、ユーザは、調べようとする 不動産を決定するために、複合リスティングサービスのような不動産データベー スをプライマリのテキストデータベースとして利用することになるであろう。こ のユーザは初期検索クエリーを作成する。初期検索クエリーはローカルＳＲＵ１ ８に送信される。ローカルＳＲＵはそのクエリーに地域ＩＤを添付する。このＩ Ｄは、当該アプリケーションにおいては、要求された不動産に関連するＺＩＰコ ード、地図、デカルト座標、又はＧＰＳ座標であろう。また、ローカルＳＲＵ１ ８は、それ自身の記憶手段を検索し、所要のビデオクリップがローカルに格納さ れているか否かを判断し、格納されている場合は、可能なビデオクリップにリビ ジョンコードを添付する。このエンハンストクエリーはＰＩＭ２２に送られる。 ＰＩＭ２２は、（１）ビデオクリップ使用テーブルを更新し、（２）どのリモー トＩＭ３４がエンハンストクエリーのための適切な情報を有しているかを、多く のリモートＩＭ３４の中から効率良く決定するために地域ＩＤを使用し、そして （３）ローカルにおいて可能なビデオクリップが最新のものであるか否かを判断 するためにリビジョンコードを使用する。利用可能ビデオクリップのリストはユ ーザに送信される。そしてユーザは、見たいビデオクリップを選択できる。この 要求はローカルＳＲＵ１８を通じてＰＩＭ２２に送信される。ＰＩＭ１１はＤＳ １３０を生成し、要求されたビデオクリップが何処に存在するかを、そのＤＳＩ ３０に対し指示する。ＤＳＩ３０は、エキステンドＳＲＵ２６に対し、ＤＳＩ３ ０の送信バッファにビデオクリップをダウンロードするように指示する。ビデオ クリップはローカルＳＲＵ１８に送信され、これらは後にユーザ端末１４にて表 示される。 この実例アプリケーションにおいては、それがサポートする地理的領域しだい で、どのようなセカンダリビデオクリップであってもカタログされ得る。セカン ダリビデオのリストは、申込者が不動産ビデオを見ているときに何時でも、申込 者の端末の「セカンダリビデオ」のウインドウ上において表示させることができ る。ユーザがセカンダリビデオを要求した場合、この要求はＰＩＭ２２に送信さ れる。ＰＩＭ２２はセカンダリビデオ情報の位置を既に決定している。ＰＩＭ２ ２は以前に生成したＤＳＩ３０を使用するか、あるいは別のＤＳＩ３０を生成し 、セカンダリビデオの位置をＤＳＩ３０に渡す。そしてＤＳＩ３０はセカンダリ ビデオ情報を有するＳＲＵに、この情報をダウンロードするように指示する。 本発明の更なる実施例では、事前に発行されたマップデータから不動産の座標 を得る。また別の実施例においては、各々の不動産の緯度及び経度を全地球測位 システム（ＧＰＳ）を利用して得る。例えば、不動産がフィルムに記録されてい る場合、不動産に関連するテキストデータと共に記録されているかもしれない。 実施例２−処方薬情報 本発明の別のアプリケーションは、医師に対するオンラインでの処方薬情報の 提供に向けられたものである。伝統的に、製薬会社は薬物の所有について教育す るために物理的に医師に会うという、実に不経済で些細なことに労力を払ってき た。しかしながら最近では、処方箋価格削減への強力な圧力、薬の発見及び開発 のコスト、コンペティターによるリバースエンジニアリングのスピード、そして 、よりリベラルで包括的な新薬認可への方針により、薬会社はこれ以上、各々の 処方薬を市場投入するのに完全で最新の努力を払う余裕はない。現在では、薬に 関する高品質のビデオカセットが生産されており、販売努力を補う試みにより医 師に対し直接送られている。 本発明の一実施例は、医師が使用可能な種々の薬に関する映像音声情報への迅 速なアクセスを提供するものである。不動産アプリケーションと同様に、例えば 「Physicians Desk Reference」オンラインバージョンのようなサードパーティ ーのテキストデータベースが利用され得る。医師は単にオンラインデータベース を検索し、ビデオで見たい薬のリストを選択する。当該システムは要求された映 像音声情報を検索して位置付けを行い、これをダウンロードする。この薬剤ビデ オは種々の用途において役立つ。例えば医師はこの映像音声情報を新薬の勉強の ために利用し、あるいは、既存の薬についての知識を単にリフレッシュ又は更新 するために利用する。また薬会社は、医師向けにビデオクリップ上において販売 を促進する薬に関する広告を乗せることもできる。 実施例３−小売りサービス 本発明の別のアプリケーションは、小売り産業、例えば新車及び中古車の販売 、リース及び／又はレンタル業に向けられたものである。上述と同様のテキスト データベースは、自動車の一覧、価格データ、性能データ、その他を含む。ビデ オクリップ検索システムは、適切なビデオクリップを検索するとともに、利用可 能なテキストデータベースを拡張する。小売りエリアにおける別のアプリケーシ ョンは、「イエローページ」にリストされているようなビジネスまたはサービス 上のマルチメディア情報を提供するためのものとなろう。 実施例４−人材 さらに別のアプリケーションは、人材業に向けらる。ここでは、特定の雇い人 を紹介する利用可能なテキストデータベースを拡張するために、ビデオプレゼン テーションが利用され得る。このような情報は、ヘルスケア・プロバイダー向け の、既存又は見込みの患者に関する情報を含むものである。また、このシステム は、患者向けにヘルスケア・プロバイダに関する情報を提供するためにも利用さ れ得る。これらのビデオクリップは、病院やクリニックのビデオ描写の提供や、 学歴や専門領域といったバックグラウンド情報の提供によって医師に関する情報 を表示する手だてを提供ことにより、患者／消費者による選択の一助となる。 実施例５−デートサービス デートサービス業界は、ビデオクリップ検索システムが利用され得るさらに別 の分野である。可能性のある「デート」のビデオクリップをデートサービスが表 示でき、消費者が適切なパートナーを獲得することを援助する。 実施例６−旅行サービス このシステムのさらに別のアプリケーションは、旅行代理店が顧客のための休 暇地のビデオクリップを見るためにこれをアクセスできるという旅行ビジネスに ある。 例７ インターネットの例 図４は本発明にかかるインターネット関連ビデオクリップ記憶及び検索システ ムの好ましい実施形態を示すブロック図である。このシステムはユーザ端末５０ と、通信線５２によってインターネットサービスプロバイダ（ＩＳＰ）のヘッド エンドネットワーク通信インタフェース５４に連結されたローカルＳＲＵ５１と を含む。好ましい実施形態において、インタフェース５４は一般的にネットワー ク“端末サーバ”と呼ばれるものである。インタフェース５４は、多数のユーザ 端末を支持する、ネットワークルータ、スイッチ、ハブ、あるいは他の通信装置 であってもよい。 本発明の一実施形態において、端末５０は上記したオーディオ−ビデオ復号及 び再生“ブラウザエクステンション”８４を有するＨＴＭＬブラウザ８２を走ら すパーソナルコンピュータである。ブラウザ８２はインターネット上に分散され たデータを照会したり探索したりするのに必要な機能を提供する。ブラウザエク ステンション８４は、オーディオ−ビデオ表示能力を提供することに加えて、ロ ーカルＳＲＵ５１によって構築され維持されているオーディオ−ビデオ及び他の データにアクセスし、ローカルＳＲＵ５１を介して本発明から引き出されたオー ディオ−ビジュアルデータを解凍するのに要するロジックを処理する。後述する ように、ブラウザエクステンション８４はさらにユーザがオーディオ−ビデオク リップと対話することを可能にする。 システムはさらにＰＩＭ６４と１つまたはそれ以上の拡張ＳＲＵ６６を含む。 好ましい実施形態では、ＰＩＭ６４は改善されたウェブサーバ６８とデータベー ス管理モジュール６９とを含む。インタフェース５４を含む前記した全ての要素 はユーザの家庭領域８１内の地域的ヘッドエンドバックボーン８０に接続されて いる。バックボーン８０は種々のスイッチ、ブリッジ、ルータ、及びハブによっ て連結されたイーサネットやＦＤＤＩなどの種々の既知の物理的ネットワーク要 素を具備する。 さらに、バックボーン８０に接続された任意のコンピュータに関して、１つそ れ以上の一時的ＤＳＩプロセスが生成される。そのようなＤＳＩ５８は、本発明 によるオーディオ−ビデオコンテンツを受信する各ユーザに対して、必要に応じ てＰＩＭ６４によって生成される。バックボーン８０は１つまたはそれ以上のネ ットワークルータ１１２を介してインターネット５６と通信を行う。 さらに、隣接領域８９が示される。家庭領域８１のように、隣接領域８９はウ ェブサーバ９３とデータベースマネージャ９１を収容するインデックスマネージ ャ（“ＩＭ”）８８と、少なくとも１つの拡張ＳＲＵ９２と、一時的ＤＳＩプロ セス９４と、ルータ９５とを含む。ルータ９５はインターネット５６に接続され ている。加えて、隣接領域８９はルータ１１２及び９５間の高速専用線９６によ って家庭領域８１に接続され、当領域のＳＲＵとＤＳＩとの通信を可能にしてい る。専用線９６は現存のインターネットインフラか又はインターネットインフラ に付加された新たな通信線の要素である。家庭領域８１のように、隣接領域８９ はまた、多数のユーザ端末を支持するヘッドエンドネットワーク通信インタフェ ース９８を有する。 ここで、隣接領域８９は自身のＩＭ８８を具備する必要がない。隣接領域８９ に対してローカルなユーザが数において十分低く、付加的ＩＭ８８を維持するコ ストが法外に高い場合には、家庭領域８１に対するＰＩＭ６４は、専用線９６を 介して隣接領域８９の他の要素を制御するのに用いられる。さらに、（拡張ＳＲ １６６及び９２などの）多数の地域的ＳＲＵ群を制御可能な単一のＰＩＭ６４を 用いることによって、“イントラネット”のような構成が生成される。 コンテンツプロバイダの領域９１が示される。それはまた、ウェブサーバ８３ とデータベースマネージャ８５とを収容するＩＭ９０と、少なくとも１つの拡張 ＳＲＵ１００と、１つまたはそれ以上の一時的ＤＳＩ１０２と、インターネット ５６に接続されたルータ８６とを含む。専用線９６はまた、コンテンツプロバイ ダの領域９１を他の領域８２及び８９に連結可能である。ヘッドエンドネットワ ーク通信インタフェース１０４はコンテンツプロバイダの領域９１をオーディオ −ビデオコンテンツをアップロードするプロバイダを含む多数のユーザに接続す る。 以上の要素の機能についてさらに記載する。 Ａ．ユーザ側から見た動作 ユーザ端末５０はユーザが配送システムと対話する装置である。端末５０は概 してパーソナルコンピュータ、ワークステーション、あるいはテレビセットトッ プボックスである。端末５０はネットスケープナビゲータ等のブラウザ８２を走 らすことができ、ブラウザ８２から指示されたときには、“プラグイン”又はブ ラウザエクステンション８４としてオーディオ−ビデオ再生アプリケーションを 走らすことができる。ブラウザエクステンション８４は保護かつ圧縮された形態 のオーディオ−ビデオデータを受信して、ユーザが、検索したクリップを受信、 復号、解凍、操作（すなわち再生、巻き戻し、停止など）するための機能を提供 する。ブラウザエクステンション８４はまた、ブラウザ８２又は独立してデータ をネットワーク８０に戻すことが可能である。 好ましい実施形態において、ブラウザエクステンション８４は本発明の配送シ ステムと通信を行うためにローカルＳＲＵ５１によって提供される機能を用いる 。 本発明の好ましい実施形態は割増し申し込みサービスとしての使用のために十 分な考慮を行なっている。エンドユーザはアクセスを許可されるために最良のサ ービスに申し込み、１つの実施形態においては、ユーザはユーザ端末５０に記憶 するべきコンフィギュレーションファイルを送信される。コンフィギュレーショ ンファイルは独自の申し込み識別番号や、ユーザによってアクセスされるＰＩＭ ６４のインターネットアドレスを含む。ＰＩＭ６４はユーザデータベースの中に 申し込み者に関する情報、すなわち、申し込みがあったコンテンツの種類、ユー ザの好み、サービスに関する制限、請求情報を維持する。 １つの実施形態において、ユーザデータベースは各ユーザについての次の情報 を含む。 ＰＩＭ６４はさらに、（前記した“オーディオ−ビジュアルデータインデック ス”に対応する）クリップデータベースにおける拡張ＳＲＵ６６に記憶されたオ ーディオ−ビジュアルクリップに関する情報を維持している。１つの実施形態に おいて、クリップデータベースは各クリップに対して次の情報を含む。 ＰＩＭ６４はまた、拡張ＳＲＵ６６の各々に関する情報を維持している。その ような情報は以下のようにしてＳＲＵデータベースに記憶される。 ユーザは、ユーザ端末５０上のブラウザソフトウェア８２を使用して、ウェブ ページにアクセスし、当技術において知られたリンクを選択する。ときには、ユ ーザは申込サービスによって処理されたビデオクリップにアクセスする。これは コンテンツプロバイダのウェブサーバ８３又は他のサーバに関するウェブページ にアクセスすることで行われる。所望のクリップはユーザが申し込んだものの１ つであるか、あるいは他のものである。 コンテンツプロバイダのウェブサーバ８３は、コンテンツプロバイダに知られ たユーザとＩＳＰの申込パラメータの組み合せに基づいて、各ユーザに対するカ スタム化されたウェブページを生成する。この手順は当技術分野において知られ ている。好ましくは、カスタムウェブページはＩＳＰの地域的ウェブサーバ６８ （ＰＩＭ６４の一部）上に生成される。そのような動作は所定の間隔、例えば、 毎日、あるいは、新たなコンテンツがシステムに対して利用可能になったときに はいつでも、あるいは、ユーザによるアクセスがあったときには直ちに行われる 。カスタムウェブページにアクセスすることによって、上記したユーザデータベ ースに含まれた、申込情報に基づいて、ユーザはどのような申込コンテンツが利 用可能であるかについて知らされる。このようにして、ＩＳＰは、ユーザが興味 のある情報を含むウェブページの“ビデオガイド”組を生成する。この組は申込 ビデオクリップを含む。ＩＳＰの“ビデオガイド”に含まれた情報は、ユーザの ローカルＳＲＵ５１上に記憶された情報と一体化され、これによって、全ての利 用可能なコンテンツのシームレスな閲覧を提供することができる。カスタムウェ ブページに関するリンクを選択することによって、ユーザは、たとえユーザの領 域８１内に存在しなくとも、本発明のシステムにより配送される申込コンテンツ を含むウェブページを要求することができる。 その時点で、ＩＳＰのウェブサーバ６８(又は他のウェブサーバ８３又は９３) はインターネット５６を介して従来の手段によって、ウェブページをユーザ端末 ５０に送信を開始する。従って、データはサーバ（例えばサーバ８３）から、対 応するルータ８６、インターネット５６（存在する多くのノード）、ユーザのＩ ＳＰのルータ１１２、ヘッドエンド通信インタフェース５４、そして最終的に端 末５０へと移動する。所望のクリップに対する参照はウェブページのＨＴＭＬ内 に埋め込まれている。ユーザのブラウザ８２、例えばネットスケープナビゲータ が例えばＥＭＢＥＤタグ内で供給された参照を受信したとき、埋め込みファイル を送信するためにウェブサーバ８３からの要求が直ちになされる。 埋め込みファイルのタイプ又はフォーマットはブラウザ８２によって解析され る。概してこれは、埋め込みファイルのファイル名の拡張子によって示され、当 技術分野において知られている。所望のファイルがビデオファイルであるときに は、端末５０及びブラウザエクステンション８４に属するローカルＳＲＵ５１は データを受信するべく起動される。第一に、ローカルＳＲＵ５１はビデオＩＤ、 ウェブページにおけるＥＭＢＥＤフィールド内に記憶された選択されたクリップ を特定する独自の識別子を傍受する。ローカルＳＲＵ５１は最初に所望のクリッ プがすでにローカルで記憶されているかどうかを決定する。そうでない場合には 、 ローカルＳＲＵ５１はビデオＩＤをユーザの端末５０に関連するＰＩＭ６４に渡 す。ローカルＳＲＵ５１は次にデータ転送を行なうために、ＰＩＭ６４からの認 可を待つ。 ビデオＩＤは多次元組のコンテンツ特徴付け座標(coordinates)と独自のファ イル名からなる。コンテンツ座標は、以下に述べるように、ファイルの当該タイ プを申し込んだ地域的ＩＭに一致させることを可能にする。 １つの実施形態において、ビデオＩＤは次の部分から構成される。すなわち、 コンテンツプロバイダによって定義されたファイルのテキスト名、申込サービス を行なう機構によって提供されるコンテンツプロバイダのアカウント番号、カテ ゴリ座標、カテゴリツリーの階層的部分の表示、ファイルがどこに関連するか( 例えば地域、州、又は市)を決定するのに用いられる地理的座標、そして当該フ ァイルが関連する時間間隔である。上記の特性はファイルが本発明に利用可能に なったときに知られており、以下に詳細に述べる。 好ましい実施形態において、ローカルＳＲＵ５１はビデオＩＤを次の形態でＰ ＩＭ６４に渡す。“バーチャルＵＲＬ”は“ｈｔｔｐ：／／”と、ＰＩＭ６４の インターネットアドレスと、ユーザの申込ＩＤ番号と、ビデオＩＤから構成され る。所望のクリップがローカルＳＲＵ５１に配置されているときには、バーチャ ルＵＲＬ要求は、特定の形態のファイルがすでにローカルＳＲＵ５１によってす でに検索されたことを特定するさらなる属性を含む。ネットスケープナビゲータ プロシージャＮＰＮ ＧｅｔＵＲＬＮｏｔｉｆｙはこのバーチャルＵＲＬをＰＩ Ｍに送信することを達成するのに利用可能である。バーチャルＵＲＬはネットス ケープナビゲータ及び他のネットワークブラウザによって受け入れられるフォー マットに構成される。ＰＩＭ６４による受信がありしだい、バーチャルＵＲＬは ビデオＩＤと申込者ＩＤ要素とに分解され、ＰＩＭの内部データベースにアクセ スするのに使用される。 ＰＩＭ６４は、そのユーザデータベースにおける当該ユーザの申し込み権をチ ェックし、当該ユーザが許可されており且つ所望のクリップのダウンロード必要 であれば、ＤＳＩプロセス５８に、上記所望のクリップの当該ユーザの端末５０ に対するダウンロードを開始させる。そのクリップデータベースにおけるビデオ ＩＤに対応するクリップを確認されたＰＩＭ６４は、拡張ＳＲＵ６６が当該クリ ップを有している関連のＤＳＩ５８に情報を渡す。該ＤＳＩは、転送プロセスを 開始し、確実にデータが適当な拡張ＳＲＵ６６からインタフェース５４を介して ユーザ端末５０へ送られるよう監視する。これにより、データが適当な拡張ＳＲ Ｕ６６からユーザ端末５０にダウンロードされる。このとき、ローカルＳＲＵ５ １は、そのデータを捕らえて、ブラウザエクステンション８４に転送する。この ブラウザエクステンション８４は、そのデータを扱うことができ、当該端末５０ のローカルな記憶領域にそれを保存したり、必要に応じて、そのデータの表示の 準備を行うことができるものである。また、当該ユーザが上記選択されたビデオ ＩＤで示されるクリップに対しては申し込んでいないとＰＩＭ６４が決定したと きには、どのようなＤＳＩプロセスも呼び出されることはなく、よって、ローカ ルＳＲＵ５１は、一般に行われているようにウェブページから直接そのクリップ をダウンロードしなければならないか、あるいは、そのユーザはそのクリップを 全く利用できないか、のいずれかであることを通知する。 従って、本発明においては、ＰＩＭ６４は、管理機能を果たすものである。Ｐ ＩＭ６４は、当該ＰＩＭ６４に関連する各拡張ＳＲＵ６６に記憶されているクリ ップについての詳細な情報、例えば、各クリップの場所やファイルネーム、形式 ，レート，ファイルサイズ，最終更新日時，料金情報，等の属性を持ったデータ ベースを含んでいる。拡張ＳＲＵ６６にないクリップのために、別のＩＭデータ ベースは、各ＩＭについて、より少ないレベルの情報、即ち、当該ＩＭのインタ ーネットアドレスと、それが保持している全てのオーディオ・ビデオファイルの 内容情報とを保持している。例えば、“ｎｅｗｓ：ｓｐｏｒｔｓ：ｂａｓｅｂａ ｌｌ（ニュース：スポーツ：野球）”クリップは、ユーザ領域８１を備えるもの を含む、いくつかの近地域ＩＳＰ及び遠地域ＩＳＰによって保持されることがで きる。前述したように、ＰＩＭ６４もまたユーザデータベースを有している。こ のユーザデータベースは、各ユーザについての情報、即ち、申し込み権、許可さ れたレートレベル、延滞料、料金リミット、等を保存している。特定されたビデ オＩＤを持つクリップを当該ユーザが受信することを望んでいるということを示 す、あるユーザからのバーチャルＵＲＬの受信に応じて、ＰＩＭ６４は、当該ユ ーザ が正当であるかどうか決定するために、上記ユーザデータベースにアクセスする 。ＰＩＭ６４は、次に、クリップデータベースにアクセスして、クリップ属性に 基づいて、当該ユーザが正当な申し込み権を持ち且つその所望のクリップのダウ ンロードすることを許可されているかどうか決定する。このとき、ＰＩＭ６４は また、その所望クリップをダウンロードした場合に当該ユーザの料金リミットを 越えてしまうかどうかもチェックする。 先のデータベースのチェックのいずれかで引っかかった場合には、ローカルＳ ＲＵ５１は、ダウンロードのための許可を受信せず、その拒絶の理由がＰＩＭ６ ４からブラウザエクステンション８４とブラウザ８２ユーザインタフェースにロ ーカルＳＲＵ５１を介して転送されて、ユーザにアドバイスする。当該ユーザの 申し込み制限に許可が与えられている上記所望クリップの別バージョンが利用で きる場合には、ユーザは、その別バージョンをダウンロードするオプションが与 えられることができる。 ユーザが所望クリップ又は別バージョンの受信を許可されたというＰＩＭ６４ による決定に応じて、前述したように、そのクリップを包含するファイルが当該 ユーザのローカルＳＲＵ５１によって受信されて保存されるかどうか決定される 。そうであれば、当該ファイルのそのバージョンがＰＩＭ６４上のクリップデー タベースに記憶されている現在のバージョンと再び比較される。ローカルＳＲＵ ５１でのファイルが現バージョンであれば、ダウンロードは必要ではなく、その ローカル記憶されたバージョンが再生のためにブラウザエクステンション８４に 転送される。ローカルＳＲＵ５１でのファイルが更新される、満期になる、ある いは存在しないのであれば、ＳＲＵ５１を介してブラウザエクステンション８４ への適当なファイルのダウンロードを行うステップが取り掛かられる。 ダウンロードは、以下の手順で始められ。即ち、ＰＩＭ６４は、そのクリップ データベースに問い合わせて、拡張ＳＲＵ６６にその所望クリップが記憶されて いるかどうか決定する。そのクリップが一つ以上の拡張ＳＲＵ６６から入手でき るのであれば、それらの拡張ＳＲＵ６６は、見かけ上の負荷に応じて、最もビジ ーのＳＲＵ６６が最も高いプライオリティが与えられるように、格付けされる。 そして、ＰＩＭ６４は、ＤＳＩ５８を呼び出して、ＳＲＵ６６の格付けリストを データに含ませてそれを提供する。 ＰＩＭ６４によって呼び出されたＤＳＩ５８は、ＰＩＭ６４によって提供され た上記リストから最も高い格付けの（最も最近ロードされた）ＳＲＵ６６を選択 する。次に、ＤＳＩ５８は、インタフェース５４及びＳＲＵ５１を介した拡張Ｓ ＲＵ６０から端末５０への転送を監視する。これは、ユーザのローカルＳＲＵ５ １のインターネットアドレスを有する所望のビデオクリップをアドレスすること によって行われる。選択された拡張ＳＲＵ６６が過負荷である若しくは応答する ことができない（例えば、タイムアウト前に応答できない）とＤＳＩ５８が決定 した場合には、ＤＳＩ５８は、次に高い格付けの拡張ＳＲＵ６６の使用を、当該 ダウンロードが成功するまで、あるいはその可能性を使い尽くすまで、試みる。 そのとき、ダウンロード待ち時間の情報（即ち、どのＳＲＵがダウンロードを処 理できたか、及びその成功したＳＲＵがその成功した転送を開始するまでにどれ だけの時間がかかったかの情報）がＰＩＭ６４に戻されて、ダイナミックに格付 け及び見かけ上の負荷を再計算することをＰＩＭ６４に許す。 ＤＳＩ５８は、前述したように、ダウンロードプロセスを扱い監視するソフト ウェアプロセスである。該ＤＳＩプロセス５８は、ＰＩＭ６４、ＳＲＵ６６，又 は、ＰＩＭ６４及び拡張ＳＲＵ６６に接続されたスタンドアローンのサーバによ ってホストされることができる。本発明のために必要な帯域幅を減じるために、 別々のユーザから同一ビデオクリップに対する多重要求は、当該クリップが送ら れる前に、短時間（例えば、１乃至１５秒）の間、ＤＳＩ５８によって順番待ち とされることができる。その待ち時間の間、ＤＳＩ５８は、適当なＳＲＵ６６か ら当該クリップデータを受信することができる。そして、その待ち時間の満了で 、ＤＳＩ５８は、当該クリップを要求するユーザの全てに対してそのクリップを マルチキャストすることができる。要求ユーザの全てへの経路が同じである（即 ち、ＤＳＩからヘッドエンドネットワークインタフェース５４へである）という 範囲までは、マルチキャスティングは、目的端末の全てのインターネットアドレ スを特定する一つの転送のみの使用を許す。マルチキャスト技術は、新しいコン テンツのアップロードについてのセクションで、後述する。 さらに、ＤＳＩ５８はまた、データプロテクトもサポートする。本システムの エンドユーザによって著作権の設定されたビデオクリップの配信を防止するため に、ＤＳＩ５８は、ＭＰＥＧ“ｓｅｑｕｅｎｃｅ ｈｅａｄｅｒ”データ構造の ような、オーディオ・ビデオクリップのキーデータフィールドを、再生を難しく するよう設計されたデータで変造する。正しいビデオストリーム構造データは、 ＭＰＥＧ仕様によって定義されたようなＭＰＥＧシステム構造"user stream"中 に（ＤＥＳやＲＳＡのような周知の暗号化方法によって）暗号化された状態で記 憶される。同様に、ユーザＩＤから引き出されたデータが、そのストリームに沿 った種々のポイントで、ノイズとしてビデオデータ（即ち、ＭＰＥＧ ＤＣＴマ クロブロック）に付加され、それによって、ファイルに透かしを入れる。このデ ータの位置は、前述したように、ユーザストリームの暗号化された部分内に記憶 された一連のシード番号によって定義される。ユーザストリーム及びユーザデー タブロックがＭＰＥＧファイルから取り除かれたと決定されたならば、クリップ タイトル又はビデオＩＤと共に、このシード番号はまた、後で参照するためにＰ ＩＭに属するユーザデータベース中に保管される。 前述したように全てのファイルがプロテクトされなければならないというもの ではないということに注意されたい。この計画の存在は、抑止ファクタとして部 分的に企てられたものである。さらに、上記透かしは、当局に著作権侵害者を突 き止めさせることを可能にする。前述したように、ＤＳＩ５８は、ＰＩＭ６４の ユーザデータベースから得られた特定ユーザ情報に基づいてクリップをプロテク トする。ユーザのブラウザエクステンション８４は、同様の情報に基づいて当該 クリップのプロテクトを解除することができる。従って、クリップを要求したユ ーザのみが、そのプロテクトされたクリップをプロテクト解除することができる 。 上記プロテクト及び透かしステップは、オプショナルなものであり、本発明は 、あるクリップ（例えば、広告、公共サービス公表、及び著作権の設定されてい ないもの）がプロテクト解除されたままであることができるということを予期し ている。これは、クリップデータベースでの属性によって示される。この場合、 ＤＳＩ５８は当該クリップをプロテクトせず、そのクリップは、受信され、保存 されて、プロテクト解除することなくユーザ端末５０で見ることができる。さら に、ユーザは、そのようなプロテクトされていないクリップを再配信する自由が ある。 前述したように、本発明に従ったシステムは、全く異なる地域にいる多数の同 時発生ユーザのためのマルチインデックスマネージャを有している。図４は、３ つのインデックスマネージャ、即ち、ユーザの地域８１に属するＰＩＭ６４と、 隣接地域８９に属するＩＭ８８と、コンテンツプロバイダの地域９１に属するＩ Ｍ９０とを示している。 所望クリップが拡張ＳＲＵ６６のいずれにもないとユーザのＰＩＭ６４が決定 し、ユーザが他の地域からファイルをアクセスする申し込み権利を持つと上記Ｐ ＩＭが決定したならば、ＰＩＭ６４は、最も近いＩＭ（例えば、ＩＭ８８）に問 い合わせて、別の遠隔ＩＭに対してローカルな遠隔ＳＲＵ９２の何れが所望のク リップを有しているのかを決定する。この問い合わせは、当該クリップを持って いそうなＩＭに向けて行われることができる。ＰＩＭ６４を含む各ＩＭは、当該 システムに接続された他の全てのＩＭのデータベースを維持している。各ＩＭの ために、そのデータベースは、当該ＩＭのインターネットアドレスと、当該ＩＭ のＳＲＵによって記憶されたファイルのタイプの情報とを含む。ファイルタイプ 情報は、前述したように、コンテンツ対等データの形式で記憶されることができ る。従って、該データベースを調べることによって、ＰＩＭ６４は、ＩＭＥが所 望のクリップを持っていそうであるということを決定し、それらのＩＭにのみ問 い合わせを行うことができる。 ＩＭ８８のような、問い合わされた遠隔ＩＭのそれぞれは、それらのＳＲＵ９ ２によって経験されている見かけ上の負荷の情報と一緒に、そのＳＥＵ９２が当 該ファイルを含むかどうかを示すメッセージで応答する。所望のクリップが見つ かったならば、実行可能な遠隔ＳＲＵのリストがＰＩＭ６４に転送される。ＰＩ Ｍ６４は、前述したように、そのＳＲＵリストでローカルＤＳＩを順次呼び出し て、ファイルをユーザの端末５０に転送する。 隣接遠隔ＩＭに問い合わせた後、ＰＩＭ６４がまだＳＲＵ６６や９２で所望ク リップを見つけられない場合には、ＰＩＭ６４は、次に、コンテンツプロバイダ が最初に当該ファイルをアップロードしたソースＩＭ９０に接続する。このソー スＩＭ９０のインターネットアドレスは、ＰＩＭ６４のクリップデータベース中 に提供されている。所望クリップが未だカレントである（即ち、失効していない 又は取り替えられていない）ならば、ソースＩＭに属するＳＲＵ１００の内の何 れかに、それが存在する。そして、ＤＳＩ５８は、前述したように、要求したユ ーザのローカルＳＲＵ５１及び端末５０に対する当該クリップのダウンロードを 呼び出される。 ビデオクリップデータが受信されるにつれて、それはローカルＳＲＵ５１に記 憶され、同時に、ブラウザエクステンション８４に送られて、プロテクトを解除 してビデオクリップを表示する。前述したように、ローカルＳＲＵ５１は、プロ テクトされた形態でデータを記憶する。同時に、エンドユーザによる不正な複製 に対してプロテクトされる。要求されたクリップを記憶するためにローカルＳＲ Ｕ５１で利用できる十分な記憶容量がない場合には、前述したように、ローカル ＳＲＵ５１の検索及び更新ロジックは、既に記憶されている最も昔に使用された クリップのいくつかを削除して、新しいデータのための空間を作る。 本発明の一実施形態においては、クリップは、ＭＰＥＧ、ＡＶＩ、又はＱｕｉ ｃｋＴｉｍｅファイルフォーマットで記憶されることができる。そのようなフォ ーマットは、当該分野でよく知られてものであり、種々のコンピュータ体系で使 用することが可能である。例えば、ＭＰＥＧ １及びＭＰＥＧ ２は、離散コサ イン変換体系を使用し、ＭＰＥＧ ４は、ウェーブレット（wavelet）圧縮を使 用して提供される。ＡＶＩ及びＱｕｉｃｋＴｉｍｅファイルは、一般に、Ｉｎｄ ｉｏ、Ｃｉｎｅｐａｃｋ、フラクタル、又はウェーブレット圧縮のような体系を 使用することができる。従って、本発明のブラウザエクステンション８４は、前 述の全ての圧縮フォーマット及び体系が使用される必要はないとはいえ、本発明 で使用される全てのタイプのファイルを判断して解凍することができなければな らない。 ユーザが、先にダウンロードしローカルＳＲＵ５１に残っているクリップを再 び見ることを望む場合には、ブラウザエクステンション８４は、コスト無しにプ ロテクト解除して再び見らることをそのデータに許すか、所望のクリップがそれ が見られるそれぞれの期間のために支払わなければらない一回ごとのものであれ ば、ローカルＳＲＵ５１にＰＩＭ６４に問い合わせさて請求レコードを更新させ るか、の何れかを行うことができる。 前述の体系の結果として、ネットワーク負荷は、典型的なディジタルビデオ配 送システムに比較して最小にされる。ビデオクリップの多数のコピーが別個の地 域のユーザに並行してダウンロードされることができる。このクリップのコピー は、各ユーザの地域にローカルなサーバ上に存在し、一般に、各ダウンロードの ための少数のネットワークノードを渡って転送される。さらに、別個の地域のた めの拡張ＳＲＵは、各インターネットサービスプロバイダのヘッドエンドネット ワークを介して、当該地域の各ユーザへ至るユニークな通信経路を有している。 従って、全体のインターネット５６上のトラフィック状況を害する（又は、トラ フィック状況によって害される）ことなく、多くの別個のダウンロードが別個の 地域において同時に企てられることができる。 さらに、詳細に後述するように、ＰＩＭ６４を含む各ＩＭは、全てのクリップ のためにその地域内のデマンドを追跡する。特定の地域内でまれにアクセスされ るクリップは、拡張ＳＲＵ６６から削除され、必要なときにのみ、遠隔ＳＲＵ９ ２又は１００から再獲得されることができる。この場合、ローカルの記憶装置の 要求は最小化される。従って、最も高いデマンド中のクリップのためには、拡張 ＳＲＵ６６からデータがダウンロードされることができるということが最もあり そうなことであり、これが最も高速な経路である。より低いデマンドのクリップ については、最も近い遠隔ＳＲＵ９２が最初に問い合わされるものである。それ らのＳＲＵ９２のための応答時間は、所望クリップを有する遠隔ＳＲＵ９２への （“ｐｉｎｇ”プログラムに類似の）通信リンクを対話式にテストすることによ って決定されることができる。このテストプロセスは、テストパケットのための 往復経過時間、いくつかのパケットを配送し受信することによって決定される利 用可能な帯域幅、及び、通知されたような遠隔ＳＲＵ９２の記憶容量、の組み合 わせである。 Ｂ．新規コンテンツのアップロードと頒布 コンテンツのプロバイダーは、本システムに利用可能ないわゆるビデオクリッ プのようなコンテンツを作成する責任を有している。ソフトウエアツールはこの 目的のために提供される。コンテンツのプロバイダーは、ＭＰＥＧフォーマット 或いは他の既知のデジタルビデオフォーマットでのビデオクリップで開始しよう とする。そしてコンテンツはソフトウエアツールを使用して、ビデオＩＤ、レイ ティング、言語とコンテンツの属性、期日、及びクリップに対する他の属性とを 指定し、これらはクリップを表すファイル内に蓄積される。ＭＰＥＧファイルは 、種々の再生装置を支援するマルチビデオとオーディオストリームとを有するも のである。例えば、異なるバージョンは、異なる言語で提供され、異なる再生度 を有し、電話番号のような地理的に特殊な情報を有し、あるバージョンの不満足 な部分をカットしたり編集することにより、種々のレイティングレベルを有して いる。本発明の好ましい実施例では、ＰＩＭ６４に属するユーザーのデータベー スのデータは、どのバージョンのクリップがユーザーにとって望ましいかを構築 するために使用され、ダウンロードに際して、クリップファイルを分解して適切 なバージョンにするためにＤＳＩ５８はＰＩＭ６４によって監督される。 クリップに付いているコンテンツの属性はサブジェクトの階層の形式で表現さ れる。例えば、クリップが、“エラー! ブックマークが定義されていません。”のコンテ ンツ領域に属するとして注釈を付けられる。そしてこれらの４つのコンテンツ領 域は、ＰＩＭ６４のクリップデータベースと共に、クリップファイルそのもの内 にも指示される。コンテンツ領域の広範な変化は、予約サービスを提供する機関 によって予め作られ、クリップをアップロードする前にコンテンツプロバイダー によって使用される。特殊なニーズを有するコンテンツプロバイダーは、予約サ ービスプロバイダーの承認の基で或いは承認なく、サブジェクトの階層的ツリー に加えることが可能であると言える。 以上述べたように、コンテンツプロバイダーはソフトウエアツールを用いてあ る属性をクリップファイルに付ける。ソフトウエアツールはまた、ビデオＩＤナ ンバーのマスターデータベースと通信して、たとえどこであろうとも、アップロ ードされた各クリップが本発明と一致するユニークなビデオＩＤコンテンツ有す ることを保証する。そしてソフトウエアツールは、クリップをコンテンツプロバ イダーのＷｅｂサーバー８３にアップロードして、そのクリップが以下に詳細に 述べるように本発明を構成するようにする。 コンテンツプロバイダーがビデオクリップを変更し、或いは利用可能な新しい クリップを作成すると、そのクリップはコンテンツプロバイダーのＷｅｂサーバ ー８３にアップロードされ、そのクリップを表すデータファイルについての情報 はコンテンツプロバイダーの近くのＩＭ９０（以前議論したソースＩＭ）に送ら れる。そしてそのクリップは以下のようにして地方のＩＭとＳＲＵに配られる。 ソースＩＭ９０はそのクリップを自らのクリップデータベースに登録し、その クリップがコンテンツプロバイダーからＩＭ９０に送られる際に、名前、日付、 時間、ビデオＩＤ、レイティング、コピー情報、予約情報、コンテンツ情報及び 他のクリップの属性を含む情報を記憶させる。そして、ソースＩＭ９０は、ＩＭ の記憶管理ロジックを呼び出して、そのファイルを少なくとも１つの拡張された ＳＲＵ１００にコピーする。選択された特定のＳＲＵは、今までに一般的に議論 してきたように、ソースＩＭ９０によって作成されたロードデターミネーション に依存する。選ばれたＳＲＵ１００のインターネットアドレスはまたソースＩＭ ９０のクリップデータベースに蓄積される。 そしてソースＩＭ９０は、更新されたファイルを、システムを介して他のＩＭ に送る。以上議論してきたように、ＩＭ９０はシステムの他のすべてのＩＭのデ ータベースを維持し、他のＩＭが維持しているコンテンツのタイプを維持する。 受信ＩＭは新しいクリップを獲得して、引き続きそれを各々のＳＲＵに送る。前 述のメカニズムによって、更新されたビデオクリップはそのようなファイルを記 憶しているＩＭにのみ送られる。データ転送には、今までにリストアップされた 全ての情報に加えて、ソースＩＭ９０のインターネットアドレスが含まれる。デ ータはマルチキャスティング技術或いはプロパゲーション技術によって送られ、 それによって各ＩＭは、メッセージが送られてきたＩＭを除く近隣のＩＭの全て にそのメッセージ送る。少ないネットワーク帯域幅で済むので、マルチキャステ ィング方法が好ましい。プロパゲーション方法は、丈夫ではあるが、多くのＩＭ が新しいデータを要求する場合にはデータ更新に対する応答時間が遅くなる。 各ＩＭは、コンテンツデータベースを有していて、そのコンテンツのカテゴリ ーはその領域の加入者に利用可能である。選択はＩＭを有するインターネットサ ービスプロバイダーによってなされる。コンテンツカテゴリーはコンテンツの特 徴座標形式で表現される。選択されたカテゴリーのクリップのみＩＭの属するＳ ＲＵに記憶される。ＰＩＭ６４のようなＩＭが新しいか変更されたクリップの利 用可能性についてのメッセージを受信した場合には、ＩＭはコンテンツデータベ ースをチェックしてファイルを必要とするか否かを決定する。そうであれば、そ のＩＭは基盤のＩＭ９０にクリップを記憶することを示すメッセージを送る。 変わりに、コンテンツを、どのＩＭがそのクリップを記憶するかを決定するメ ッセージを最初に送らずに配ってもい。そのためには、基盤のＩＭはそのＩＭデ ータベースをアクセスして、どのＩＭが新しいか或いは更新されたクリップを含 むコンテンツ座標を有しているかを決定する。そしてその質問を満たすＩＭのリ ストがコンテンツの頒布のために使用される。要求している全てのＩＭにクリッ プを配るために、基盤のＩＭ９０はその記憶管理ロジックを利用してクリップを 送る。基盤のＩＭ９０は、インターネットマルチキャスト標準に指定されている ようなマルチキャストインターネットアドレスをまず予約する。そしてＩＭ９０ は、要求している各ＩＭにメッセージを送り、各ＩＭがマルチキャストグループ に加わるかことを要求する。そしてクリップがＤＳＩ１０２によって予約された マルチキャストインターネットアドレスに送られると、各ＩＭはファイルを受信 して、そのファイルを自らの基準に基づいてＳＲＵに配る。 従って、ＰＩＭ６４のような各ＩＭは、最も新しくロードされた拡張ＳＲＵを クリップを記憶するために使用される状態にし、そしてその記憶管理ロジックを 呼び出してそのクリップを拡張ＳＲＵ６６の中の１つにコピーする。ＰＩＭ６４ は、自らがクリップのより古いバージョンを既に有しているかどうかを決定する ためのチェックを行う。既に有している場合には、記憶管理ロジックは、新しい バージョンを拡張ＳＲＵ６６にコピーする前に古いバージョンを削除する。もし もクリップが、例えば異なる言語形式の、或いは地域的な特定情報を有している 部分やセグメントを具備している場合には、ＩＭコンテンツデータベースによっ て関連があるとされる部分だけが記憶される。例えば、特定のＩＳＰがスペイン 語を話すユーザを有していない場合には、クリップのスペイン語バージョンは地 域的には記憶する必要がない。 コンテンツプロバイダーはまた、システムに指示して特定クリップの全てのコ ピーを除去する。それを行うためには、そのインストラクションを有するメッセ ージが、コンテンツプロバイダーＩＭ９０に送られる。そして、そのメッセージ はシステムを介して、新規で更新されたクリップに対して今までに説明されたよ うにして、伝播される。各ＩＭが特定のクリップを除去するインストラクション を受信した場合には、ＩＭはクリップデータベースに問い合わせて、どの拡張Ｓ ＲＵがそのクリップを記憶しているかどうかを決定する。そうであれば、ＩＭ記 憶管理ロジックが呼び出されて、適当なＳＲＵからそのクリップの全てのコピー を削除する。 ＰＩＭ６４を含む各ＩＭはクリップデータベースと拡張ＳＲＵ６６に記憶され ているデータに対してメインテナンスを実行する。周期的に、ＰＩＭは、チェッ クを行い、クリップデータベースのどのクリップが期限切れになったか、或いは どのクリップが特定時間内、例えば１時間、１日、１週間或いは１ヶ月間アクセ スされなかったどうかを判断する。どれかに当てはまる場合には、ＰＩＭ６４は きおく管理ロジックを呼び出して、適切なＳＲＵ６６からそのクリップを削除す る。 Ｃ．ダイナミック・ロード管理 性能を良くするために本発明のシステムは、（１）予想された使用方法に基づ くファイルのプレロードと頒布、（２）ダイナミック・ロード・バランス、（３ ）自動的なファイルの交換、のような通信ネックを除去するための手段を搭載し ている。以下に述べる手段は、オン・ディマンド対応に基づくもの、或いはネッ クを減じるためのマルチ通信路の使用を高めることに基づくものである。しかし ながら、他のロード管理技術も本発明では使用されている。例えば、上述したよ うなＰＩＭ６４によって作り出される拡張ＳＲＵ２６の優先的なリストである。 （１）プリロードと頒布 ＰＩＭ６４は、例えば１時間毎に周期的に、そのデータベースにおいて、拡張 ＳＲＵ６６の各ファイルが１週間における日と１日における時間の関数として要 求されている周期を収集し蓄積する。スポーツ、自動車、音楽のような予め決め られたカテゴリーにおけるファイルアクセスの周期は、ここのファイルのアクセ ス周期や、各ダウンロードに対して使用されたユーザー通信リンクスピードとし て、表にされて蓄積される。上記の情報は将来の使用方法を予想するために使用 される。 本発明の好ましい実施例では、以前に使用された使用方法の３つのカテゴリー が、所定のクリップがダウンロードされる回数を予想するために使用される。第 １に、前の週の同じ日時におけるクリップサブジェクトマターカテゴリーにおけ るクリップの歴史的需要に基づくデータが、線形的に外挿されて現在の日時にお けるそのカテゴリー需要を予測くする。この第１のファクターは、例えば最終的 重み付けのフラクションに寄与し、そのフラクションは理想的には２０−４０％ である。第２に、以前の日における対応する時間に亙る特定クリップに基づくデ ータが、現在に日時でのそのクリップの需要を予測するために、線形的に外挿さ れる。この第２のファクターは最終的な重み付けに２０−３０％寄与する。第３ に、現在時間に直接的に続く期間に亙る特定クリップ（或いは前のもの）に基づ くデータが、線形的に外挿されて、クリップ需要を予測する。この３番目のファ クターは最終的な重み付けに３０−６０％寄与する。 これら３つのファクターは、例えば各クリップがどのくらい頻繁に近々の期間 にダウンロードされるかを見積もるために使用される。各期間の終わりには、予 測されたロードが実際のロードと比較され、例えばニューラルネットワークのよ うな公知の技術に基づいて、将来の期間に対する重み付けが修正される。 上述した工夫に基づいて、ＰＩＭ６４は予想されるダウンロード野融通を図る ためにＳＲＵ６６の帯域幅を試算する。この試算は、例えばその期間内における 予想されるダウンロード数による各ファイルのサイズを積算することによりなさ れる。もしも、試算から得られた帯域幅が単一のＳＲＵ６６の容量の閾値の例え ば１０−５０％以下である場合には、ロード・バランスを取る必要はない。しか しながら、試算から得られた帯域幅が高い場合には、どのファイルも閾値を超え ないようになるまで適切な数の拡張ＳＲＵ６６上にファイルが配られる。このこ とは、最も高い見積もりファイルを、多数のＳＲＵに配ることにより達成される 。即ち、ユーザの予想されるダウンロードスピードにおけるファイルの瞬間的な ダウンロード数を融通するのに十分な数のＳＲＵに配られる。この頒布は、ファ イルの配信を望まれているＰＩＭ６４によって呼び出された記憶管理ロジックに より達成される。 必要以上のファイルのコピーが存在する場合には、ＰＩＭ６４は記憶管理ロジ ックを使用して、最も高い予想ロードを有するＳＲＵ６６から過剰なファイルを 除去する。（除去される以外のクリップに基づいて。） （２）ダイナミック・ロード・バランス 拡張ＳＲＵ６６のダイナミック・ロード・バランスは、特定のＳＲＵ６６がネ ックとなるチャンスを最小にし、ピークロード期間内の帯域幅（バンド幅）を最 大にするためになされる。本発明のインターネットにおける実施例に基づくロー ド・バランスは、以上述べたような発明全体に対してなされ、特定の事例が以下 に述べられる。 ＰＩＭ６４は、拡張ＳＲＵ６６の各々についての現在の性能情報を維持する。 この情報は、いつＤＳＩ５８が開始し、ＤＳＩ５８が以上述べたようにＳＲＵ６ ６からのファイル転送を終了するかを判断して得られる。 もしＳＲＵがその理論的容量の閾値限界、例えば８０％に近づくロードを有し ていると、ＰＩＭ６４は、このことがダウンロードリクエストの不釣り合いな大 量の部分、例えば１０％以上を受信する少数のクリップによるか否かをチェック する。そうであれば、ＰＩＭ６４は記憶管理ロジックを呼び出して、そのファイ ルを、例えば最近ロードされたＳＲＵ６６に送る。 特定ファイルやファイルの少数グループに対する予想される現在の需要が、あ る領域内の拡張ＳＲＵ６６の全ての閾値容量、例えば３０−５０％を超える場合 には、ＰＩＭは、ＤＳＩ５８によってアクセス可能なＲＡＭバッファー１０６に これらのクリップを移動しようと試みる。ＲＡＭバッファー１０６を使用すると 、最も需要の大きなクリップの検索に必要なディスクアクセス量を少なくできる 。そして、ＰＩＭ６４によって維持されているＳＲＵ６６の配信容量は、それら の増加した容量を反映して更新される。 ある領域内の拡張ＳＲＵ６６の全てが現在のユーザ数の需要に対応できない場 合には、システムは、以下のようにＩＭ８８のような近くのＩＭに属するリモー トＳＲＵを使用できる。ＤＳＩ５８が以上述べたようにローカルＳＲＵからデー タを得ることに失敗した後に、ＤＳＩ５８は、ＰＩＭ６４に再質問して、実行可 能なＳＲＵの第２のリストを得る。以上述べたように、ＰＩＭ６４は適切なリモ ートＩＭに質問して、そのような情報を得る。 本発明のダイナミック・ロード・バランスのために、拡張ＳＲＵ６６、リモー トＳＲＵ９２または１００、或いはリモートＩＭ８８または９０がもしも失敗し た場合には、変わりのサーバーと通信路が自動的に利用可能になり、ユーザサー ビスを行う。データは、マルチの物理的サーバー上に冗長的に維持されている。 ＩＭと拡張ＳＲＵとを含む各領域は、ビデオクリップを管理し配るための独立し たシステムである。そこにはセンター化されたデータ管理機能は存在しない。従 って、ある領域における失敗は、他の領域に壊滅的な影響を与えない。 更に、ＩＳＰがプレミアサービスを行うエンドユーザの数が増加し、利用可能 なビデオクリップの数が増加すると、本発明は、限界のない成長の可能性を提供 する。各拡張ＳＲＵ６６のディスク容量と共に、物理的に拡張したＳＲＵ６６の 数は、更にデータを蓄積するために増加される。別のＩＭが、別の地域的な領域 をサービスするために、或いはオーバーロードな領域を分割するために加えられ る。並列データ転送の数を増加するために、１以上のＤＳＩ５８は、共有してい る物理的サーバー或いはある領域内の独立したサーバー上に共存できる。 自動ファイル交換 本発明の自動ファイル交換に関しては、新規コンテンツのアップロードと頒布 の項で説明した。 Ｄ．クリップ分割 本発明の１実施例によれば、ビデオクリップ分割が示される。即ち、クリップ は２以上のセグメントから形成される。分割されたクリップが選択された後、要 求しているユーザには、クリップ内のセグメントのインデックスが提示され、ダ ウンロードするセグメントを選ぶ。 これを達成するために、コンテンツプロバイダーはまず上述したソフトウエア ツールを使用しているビデオクリップを編集し、クリップの特定フレームが連続 したインデックスナンバーによって特定される。セグメントデータはクリップに 添付されていて、ファイル内に保存される。セグメントデータには、各インデッ クスナンバーに対して、インデックスされたフレームのテキスト名或いは記述、 インデックスセグメントのスタートと終了バイトカウントが含まれている。好ま しい実施例では、ＭＰＥＧファイルのユーザ傾向がセグメントデータを含むよう に使用される。この様にして、ＭＰＥＧファイルの適合性が他のプレイヤーによ る使用のために保たれている。 特に、セグメントデータは以下のようにしてＭＰＥＧファイル内に含まれてい る。ＭＰＥＧファイルは、多数のビデオストリーム、オーディオストリーム、単 一のＭＰＥＧフォーマットストリーム及び単一のユーザストリームとを所有して いる。これらのストリームは全て、同じ“提示時間”で使用するためにエベント をリンクしたパラメータと共に結合されている。従って、本発明のセグメントデ ータは、ユーザストリーム中に含まされていて、望ましいビデオ或いはオーディ オエベントに対応する特定の提示時間に生じるように付加されている。この特性 は、同期目的のために有効である。 更に、ユーザストリームはマルチのサブストリームを含んでいる。本発明の好 ましい実施例は、少なくとも２つのユーザ・サブストリームを有している。即ち 、セグメント・サブストリームと防御サブストリームである。セグメント・サブ ストリームは、以上述べたインデックスナンバーと対応するデータと共に、セグ メントへのコンテンツテーブルを有している。防御サブストリームは、以上述べ たプロテクション（防御）とウオーターマーキングデータとを有している。マル チの特殊に定義されたサブストリームをＭＰＥＧファイルのユーザストリーム内 で使用することにより、本発明のブラウザー８２やブラウザー・エックステンシ ョン８４以外のＭＰＥＧビューワは、本発明によりダウンロードされたプロテク トされていないビデオクリップを見るのに使用できる。そのようなビューワは単 に追加の情報を無視する。 セグメント化されていないクリップは、ＳＲＵ６６に属するハードディスク上 の隣接するファイルとしてＳＲＵ６６条に一般的に蓄積されている。しかしなが ら、セグメント化されたクリップは、独立の検索可能なレコードとしてストアさ れている。そして、ＰＩＭ６４は、クリップデータベース内で、どのセグメント がどのＳＲＵ６６にストアされているか追跡する。セグメントデータは又上述し たようにＭＰＥＧファイル内に保たれている。 ユーザがセグメント化されたクリップを見たいという要求を出す場合には、ク リップはビデオＩＤによって特定され、セグメント化されていないクリップに対 して議論したようにＰＩＭ６４によって突き止められる。しかしながら、ビデオ データがダウンロードされる前に、クリップセグメントブラウザー・エックステ ンション８４によるディスプレイのためにユーザターミナル５０にダウンロード される。そして、ユーザはダウンロードしたい特定のセグメントを選択する。特 定されたセグメントのセグメントナンバーは、ブラウザー・エックステンション ８４によってＤＳＩ５８に知らされ、ＤＳＩ５８は、ローカルＳＲＵ５１を介し て適切なローカルＳＲＵ６６からターミナル５０に、リクエストを受けたセグメ ントだけをダウンロードする。セグメントが独立のＳＲＵ６６にストアされてい る場合には、ＤＳＩ５８は同時に、独立のＳＲＵ６６からユーザターミナル５０ へのダウンロードを用意するローディングセグメントでもある。 セグメントデータの他の使用方法もある。コンテンツプロバイダーは、追加の 情報をクリップのフレームやセグメントに結合することもできる。この情報は追 加のコントロール・サブストリームにストアされる。このサブストリームは以前 議論したＭＰＥＧユーザストリームの一部分である。例えば、セグメントデータ は、他のクリップやＨＴＭＬファイルを特定する追加のビデオＩＤやＵＲＬを含 んでいる。クリップがユーザブラウザー・エックステンション８４によってダウ ンロードされ再生されると、ブラウザー・エックステンション８４は、リンクを 示す関連したビデオＩＤ、ＵＲＬ或いはテキストをディスプレイする。ユーザは これらのリンクの内の１つ以上のリンクを選択し、ブラウザー８２或いはブラウ ザー・エックステンション８４は、本発明の方法により或いはインターネット上 の従来の手段により、関連する情報を得ることができる。 セグメントデータはまた、ブラウザーエックステンション８４に対する隠れた インストラクションを含んでいる。そのようなデータは、以上述べてきたような ＭＰＥＧユーザストリームの部分から作られた追加のオブジェクトサブストリー ムに含まれている。例えば、クリップの特定のフレームやセグメントに関連した 予め規定されたコードを含めることにより、ブラウザー・エックステンション８ ４はディスプレイに線図で表したオブジェクト、テキスト或いは他のコントロー ルを加えるように命令される。追加のコンピューティング機能が、Ｊａｖａプロ グラム言語で記載されたような、ターミナルに独立したコンピュータプログラム をセグメントデータベースに埋め込む形式により追加できる。クリップがブラウ ザーエックステンション８４により受信されると、プログラムコードもまた受信 されて解釈され、ブラウザー８２に送られる。適当な時間に、ブラウザー・エッ クステンション８４は、ブラウザー８２と交信して、適切なアクションを起こす 。 セグメントはそれぞれ、コンテンツ・レイティングや言語のような自分の属性 を有している。そのような属性は上述したようにＭＰＥＧファイルのセグメント ・サブストリームにストアされる。属性情報はセグメント毎のベースでＰＩＭ６ ４によって使用され、どのセグメントが特定のユーザに利用可能かを判断する。 そのような利用可能なセグメントのみがダウンロード可能としてブラウザー・エ ックステンション８４に示される。ＰＬＭ６４は、ＰＬＭ１８に命令して、ユー ザデータベースの情報によって示されたそのようなセグメントのみをダウンロー ドする。関連したデータを有していないセグメントは無視される。そして、拡張 ＳＲＵ６６にストアされたクリップファイルはダイナミックに解凍されて望まし くないコンテンツを削除し、ユーザに望ましいビデオクリップを提供するように 再構築される。 セグメント化されたファイルは、コンテンツ・プロバイダーのＷｅｂサーバー ８３のセグメントとして蓄積される。本発明のシステムが利用可能でない場合、 即ち、ユーザが十分な予約権を有していないか、或いは特定のクリップがどのＳ ＲＵにもストアされていなかった場合には、Ｗｅｂページはここのセグメントを リストするために使用でき、セグメントはインターネット５６上の従来の方法で 独立クリップとして選択可能である。 Ｅ．加入（予約）コントロールと管理 以上議論してきたように、本発明は加入者に対するプレミアサービスである。 従って、以下の加入管理の機能は必要に応じて含ませることができる。 本発明にアクセスするためには、エンドユーザはプレミアサービスに加入しな ければならない。加入は無料であり、自由である。ＩＳＰは、ユーザにサイン・ アップ・プログラムを提供する。サイン・アップ・プログラムは、データ入力を 受信する形式を有するＩＳＰのＷｅｂサーバー６８上にＷｅｂページとして搭載 されている。ユーザは月毎のチャージに対する料金限度について質問され、クレ ジットカード番号のような支払情報を知らせる。ビデオクリップの望ましい再生 質と解像度のようなユーザデータが集められる。ユーザはまた以下に議論される ようなレイティングシステムでの使用における容認できるコンテンツ制限を構築 する。サイン・アップ・プログラムや将来でのサイン・アップＷｅｂページを使 用して、ユーザは配列データにアクセスしてそれを望ましいものに変更する。 加入ベースで利用可能なコンテンツに対して、本発明はコンテンツへの加入者 として指定されたユーザへのアクセスを制限する。ユーザは特定のコンテンツに 直接加入することができるし、ＩＳＰはエンドユーザに対して予約できる。いず れの場合にも、ＰＩＭ６４はそのユーザデータベースにＰＩＭ６４に接続されて いるオーソライズされた加入者全員のリストを持っていて、本発明を介したクリ ップのダウンロードをその領域で許可された者に制限している。 各ビデオクリップはまた、期限が切れる日付や終了した時間を付記する。その ような情報はＰＩＭ６４に属するクリップデータベースにストアされている。そ して、ＰＩＭ６４は、期限が切れたファイルをどのユーザのブラウザー・エック ステンション８４に転送することを禁じ、ユーザターミナル５０に局所的に蓄積 されているクリップをリプレイすること、即ち、リクエストにプロテクトをかけ ないこと、を随意に禁じる。 あるクリップは、鑑賞毎の支払ベースで利用可能にできる。そのような場合に は、各ダウンロード或いは選択的な各鑑賞は、ＰＩＭ６４により追跡される。ユ ーザのアカウントはダウンロード或いは鑑賞の基に増加額が生じる。ブラウザー ・エックステンション８４は、クリップダウンロードに対する許可を得るための チャージを支払うようにユーザに警告できる。 鑑賞毎の支払システムの乱用を防止するための機構を設けることもできる。鑑 賞毎の支払システムでは、ユーザがシステムを過剰に使用する可能性がある。合 理的でない高いレベルのチャージが生じる可能性もある。従って、ユーザ等は、 ブラウザー・エックステンション８４を予めプログラムして、コストリミットを 設けることも可能である。このコストリミットはパスワードによってプロテクト される。ファイルをダウンロードする前に、ＰＩＭ６４は、トータルコストをブ ラウザー・エックステンション８４に知らせる。もしトータルチャージがプレイ ヤーの限界を超えると、ダウンロードは禁止されるか、パスワードを入力するこ とによりユーザに取り引きを問い合わす。 請求の他の形態は、加入者料金の形式でなされる。コンテンツプロバイダーは 、ユーザがビデオクリップの選択されたグループをアクセスするには、周期的な 加入者料金を支払うように要求できる。そのような加入者アクセスは、コンテン ツプロバイダーやＩＳＰの考えに従って限度を設けなくてもよいし、限度を設け てもよい。この支払いシステムは、上述した鑑賞毎の支払システムと組み合わせ て使用できる。あるクリップは適当な加入で無料にし、一方他のクリップは鑑賞 毎の支払でのみ利用可能にできる。もしあるダウンロードされたクリップを遠隔 領域８９や９１から検索しなければならない場合には、遠隔地料金を設定できる 。ＰＩＭ６４は、周期的な加入者料金の発生を追跡してそのチャージを領域８１ のユーザのアカウントに乗せることができる。 以上述べたように、加入は、関心あるエリアに限定することができる。ユーザ は、ブラウザー・エックステンション８４とブラウザー８２とを使用して、関心 あるトピックスのＷｅｂを検索できる。そのようなサーチ能力は公知である。望 ましいクリップの収集が決定されると、ユーザはブラウザー・エックステンショ ン８４を使用して、ＰＩＭ６４にクリップ要求の提案グループを提出する。そし て、ＰＩＭ６４は、質問結果を出すために提案された加入項目と料金の情報を答 える。ユーザはそのような項目を受け入れることもできるし拒絶することもでき る。受け入れる場合には、ユーザアカウントがそれに基づいて更新される。 本発明のシステムは、例えば並列コントロールにおける使用の種々のレイティ ングを融通できる。コンテンツが作られたり、コンテンツプロバイダーのＷｅｂ サーバー８３とＩＭ９０にアップロードされた場合には、コンテンツプロバイダ ーはレイティングレベルを割り当てる。このレイティングレベルはＩＭ９０とＰ ＩＭ６４のクリップデーターベースにストアされると共に、クリップを含むＷｅ ｂページに任意にストアされる。鑑賞者は予めユーザ等によってプログラムされ ていて、特殊な限界よりも高いレイティングを有するビデオクリップのダウンロ ードを禁止する。このレイティングコントロールプログラムはパスワードにより プロテクトされている。各クリップは、例えば特性と正確さからなる２次元のレ イティングマトリックスによって評価される。ある実施例では、特性は、赤裸々 さ、ポルノグラフィー、言語や騒々しさであり、正確さのレベルは例えば１から ５である。 レイティング・コントロール・メカニズムでは、ビデオクリップがユーザによ り要求されると、ＰＩＭ６４には、ビデオＩＤが隠されているタグの一部として のＷｅｂページからか、或いはＰＩＭ６４がクリップを特定した後にＰＩＭ６４ のクリップデータベースからのどちらかからレイティング情報が供給される。ユ ーザレイティングコントロール限界はビデオＩＤから構成される実質的なＵＲＬ の部分としてＰＩＭ６４に送られる。そしてＰＩＭ６４はその情報に基づいてダ ウンロードを許可したり拒絶したりする。 実施例８ 変形例 本システムの上記説明から分かるように、本発明の実施例は多数の異なる適用 が可能であり、ネットワークを巡って時間的に臨界的なデータを大量に送ること が可能である。特に、以上の開示はオーディオを有しているか有していないかに 関わらず、ビデオクリップに限定されるものではない。また、オーディオだけの クリップでも達成できるし、コンピュータデータでも、更に他のタイプのデータ でも達成できる。同様に、開示された機能的な素子は図示されたものに限定され るものではなく、ＰＩＭ６４とＤＳＩ５８のような素子は、特定の実施に望まし く或いは必要であれば、単一サーバー上のハードウエアであってもよい。代わり に、機能的な素子は数個のハードウエアに分割でき、当業者に知られているよう に、性能を向上することが可能である。また、３個所だけの領域が図４には示さ れているが、本発明は、多数の領域が、インターネット５６或いは他のネットワ ークとライン９６のような高速ラインによって接続される構成を採ることができ る。各領域は同様に、それぞれのヘッドエンド・ネットワーク・インターフェー ス５４に接続された多数のユーザを有することもできる。 ある特定の構造と動作が説明されてきたが、本発明の範囲を逸脱することなく 種々変形して実施することができる。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ Ｚ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ， ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，Ｉ Ｌ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ， ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，Ｒ Ｕ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ (72)発明者 グルーバー、ハリー アメリカ合衆国、カリフォルニア州 92130、サン・ディエゴ、フェアーバンク ス・ランチ、ビア・ポッサダ・デル・ノル テ 6150 【要約の続き】 による分散型ディジタルビデオクリップ分配システム は、ローカルサイト、および／またはリモートサイトに 格納されたビデオクリップを提供する。このビデオクリ ップはインターネットから要求され、ユーザのマルチメ ディア端末により再生される。ユーザがウェブページに 表示されている所望のビデオクリップを要求すると、要 求はプライマリインデックスマネージャ（ＰＩＭ）へ迂 回される。ＰＩＭは要求されたビデオクリップを格納 し、ダウンロードが完了した最も近いサーバを見つけ る。本システムは、サーバを地理的に分散させるために ビデオクリップをアップロードし分散する手段と、ダイ ナミックロードバランシング、予約管理機能と、ビデオ クリップの不法な複製を抑制するための保護手段をさら に有する。

Claims (1)

1. 【特許請求の範囲】 １．ユーザがデータベースからビデオクリップを要求でき、要求ビデオクリッ プを受信及び表示できるいマルチメディア端末と、 前記マルチメディア端末と通信し、前記マルチメディア端末からのビデオ クリップ要求を受け、処理するために適応される局所格納検索モジュールと、 前記局所格納検索モジュールと通信し、前記局所格納検索モジュールから のビデオクリップ要求を受け、処理するために適応される一次索引マネージャと 、 前記一次索引マネージャと通信し、ビデオクリップを含むデータベースを 含む複数のデータベースを格納する拡張格納検索モジュールと、 前記一次索引マネージャによって制御され、前記拡張格納検索モジュール に前記要求ビデオクリップをダウンロードさせるために適応されるデータ順序づ けインタフェースと、 前記局所格納検索モジュールを介して前記要求日で小クリップを前記マル チメディア端末にダウンロードする手段と、 により構成されるビデオクリップ格納検索システム。 ２．複数のユーザに適応するために複数のマルチメディアにより構成される請 求の範囲第１項記載のビデオクリップ格納検索システム。 ３．複数の拡張格納検索モジュールが前記一次索引マネージャに接続される請 求の範囲第１項記載のビデオクリップ格納検索システム。 ４．前記一次索引マネージャは複数の遠隔索引マネージャに更に接続される請 求の範囲第１項記載のビデオクリップ格納検索システム。 ５．前記一次索引マネージャおよび各遠隔索引マネージャは前記拡張格納検索 ユニットに格納された各ビデオクリップのリストを維持する請求の範囲第４項記 載のビデオクリップ格納検索システム。 ６．前記要求が前記一次索引マネージャに送られる前に各要求ビデオリップに 地域識別子を付帯するため前記局所格納検索モジュールのための手段を更に含む 請求の範囲第４項記載のビデオクリップ格納検索システム。 ７．前記一次索引マネージャは前記要求ビデオクリップを含む遠隔索引マネー ジャを認識するため前記地域識別子を使用する請求の範囲第５項記載のビデオク リップ格納検索システム。 ８．前記要求ビデオクリップが前記局所格納検索モジュールに格納されている かどうかを決定するために前記局所格納検索モジュールを検索する手段と、 前記要求ビデオクリップが格納されているかどうかを示すために前記ユー ザ要求を修正する手段と、 を更に含む請求の範囲第５項記載のビデオクリップ格納検索システム。 ９．前記ビデオは圧縮形態で格納され、前記マルチメディア端末は前記マルチ メディア端末においてユーザに前記ビデオクリップを見せるために伸張手段を含 む請求の範囲第１項記載のビデオクリップ格納検索システム。 １０．前記局所探索検索モジュールは前記要求ビデオクリップを前記ユーザ端末 にダウンロードするための伸張手段を有する請求の範囲第１項記載のビデオクリ ップ格納検索システム。 １１．前記データ順序づけインタフェースは前記複数の拡張格納検索モジュール から受信された情報を順序付けする手段を含む請求の範囲第３項記載のビデオク リップ格納検索システム。 １２．ユーザは不動産、薬剤、小売り、旅行および個人情報の少なくとも１つを データベースからクリップ要求できる請求の範囲第１項記載のビデオクリップ格 納検索システム。 １３．前記データベースは不動産情報を含み、前記地域識別子はＺＩＰコード、 カルテシアン座標、およびＧＰＳ座標の１つである請求の範囲第１２項記載のビ デオクリップ格納検索システム。 １４．オーディオ・ビジュアルクリップを選択するためデータベースを探索し、 選択オーディオ・ビジュアルクリップの要求を見て調整するステップと、 ユーザのマルチメディア端末から局所探索検索モジュールへオーディオ・ ビジュアルクリップの要求を送るステップと、 前記要求オーディオ・ビジュアルクリップが格納されているかどうかを決 定するため前記局所探索検索モジュールを探索するステップと、 前記要求オーディオ・ビデオクリップが格納されているかどうかを示すた め前記局所探索検索モジュール内の要求を地域識別子を各要求オーディオ・ビジ ュアルクリップに付帯することによって修正するステップと、 前記修正要求を一次索引マネージャに送るステップと、 １以上の拡張探索検索モジュール内で各オーディオ・ビジュアルクリップ の正確な格納位置を決定するために前記一次索引マネージャを使用するステップ と、 データ順序づけインタフェースを生成し維持し、前記拡張探索検索モジュ ールに前記要求オーディオ・ビジュアルクリップを前記データ順序づけインタフ ェースにダウンロードさせるステップと、 前記局所探索検索モジュールを介して前記ユーザマルチメディア端末に前 記オーディオ・ビジュアルクリップをダウンロードするステップと、 前記ユーザマルチメディア端末で見るために前記オーディオ・ビジュアル クリップを圧縮状態から伸張するステップと、 により構成される、オーディオ・ビジュアルクリップを格納し、データベ ースから検索する方法。 １５．異なる地理的個所での複数のビデオ記憶媒体と、 各々が１以上の異なる個所で記憶媒体によって１以上のコピーで格納され る複数のデジタル化ビデオクリップと、 所望のビデオクリップを要求し見るためのビデオ表示端末で構成されるユ ーザインタフェースと、 前記ユーザインタフェースを介して要求したビデオクリップを前記ビデオ 記憶媒体に位置付けし、滞留するための探索エンジンと、 １以上の配置済みビデオクリップ検索し、前記ユーザインタフェースに転 送するための少なくとも１つのユーザ特定バッファと、 ユーザインタフェースと前記探索エンジンとをリンクする第１通信チャネ ルと、 前記探索エンジンと前記記憶媒体とをリンクする第２通信チャネルと、 前記記憶媒体と前記ユーザバッファとをリンクする第３通信チャネルと、 前記ユーザ特定バッファと前記ユーザインタフェースとをリンクする第４ 通信チャネルと、 供給及び需要の基礎に立って前記記憶媒体の前記ビデオクリップを１以上 の個所に配信する格納エンジンと、 により構成される配信ビデオクリップ格納検索システム。 １６．前記第１，第２及び第４通信チャネルはそれぞれ超高速および高速の一方 であり、前記第３通信チャネルは超高速である請求の範囲第１５項記載の配信ビ デオクリップ格納検索システム。 １７．各超高速チャネルはＦＤＤＩおよびＡＴＭから成るグループから選択され るプロトコルを用い、各高速チャネルはＩＳＤＮプロトコルを用いる請求の範囲 第１６項記載の配信ビデオクリップ格納検索システム。 １８．各超高速チャネルは少なくとも略１００メガボーの最小帯域幅を有し、各 高速チャネルは少なくとも略５６キロボーの最小帯域幅を有する請求の範囲第１ ６項記載の配信ビデオクリップ格納検索システム。 １９．各ビデオクリップおよび各記憶媒体は独特に識別され、各記憶媒体はデジ タルメモリおよびこのデジタルメモリに格納され、そこから検索される前記ビデ オクリップのデータベースを有するファイルサーバで構成される請求の範囲第１ ５項記載の配信ビデオクリップ格納検索システム。 ２０．各ファイルサーバは１以上のメモリ装置を有し、その各々は高容量ハード 装置、高速度光学装置、ＲＡＩＤ装置およびＷＯＲＭドライブからなるグループ から独立的に選択される請求の範囲第１９項記載の配信ビデオクリップ格納検索 システム。 ２１．各ビデオクリップは圧縮フォーマットで格納され、表示のために伸張され る請求の範囲第１５項記載の配信ビデオクリップ格納検索システム。 ２２．ビデオ伸張は前記ユーザ特定バッファおよび前記ユーザインタフェースの １つで起こる請求の範囲第２１項記載の配信ビデオクリップ格納検索システム。 ２３．前記圧縮フォーマットはＭＰＥＧＩ、ＭＰＥＧII、ＭＩＰＥＧ、インディ オ(Indio)およびフラクタル(Fractal)の１つである請求の範囲第２１項記載の配 信ビデオクリップ格納検索システム。 ２４．前記ユーザインタフェースはパーソナルコンピュータに存在し、探索イン タフェースとオーディオ・ビジュアル表示インタフェースを含む請求の範囲第１ ５項記載の配信ビデオクリップ格納検索システム。 ２５．前記ユーザインタフェースは検索ビデオクリップのさらなる処理及び扱い のために設ける請求の範囲第２４項記載の配信ビデオクリップ格納検索システム 。 ２６．前記ユーザ特定バッファは検索ビデオクリップを格納するための局所記憶 媒体ビデオクリップを搬送する請求の範囲第１５項記載の配信ビデオクリップ格 納検索システム。 ２７．最頻度に要求されるビデオクリップは前記局所記憶媒体に格納される請求 の範囲第２６項記載の配信ビデオクリップ格納検索システム。 ２８．前記ユーザインタフェースおよび前記ユーザ特定バッファは前記複数の記 憶媒体の１つと関連するファイルサーバおよびパーソナルコンピュータの１つに 独立的に存在する請求の範囲第１５項記載の配信ビデオクリップ格納検索システ ム。 ２９．前記探索エンジンは前記システムに格納されたビデオクリップおよびその 格納個所を示す情報を有する１以上のデータベースをアクセスする請求の範囲第 １５項記載の配信ビデオクリップ格納検索システム。 ３０．前記データベースの少なくとも１つは前記複数の記憶媒体の１つに存在す る請求の範囲第２９項記載の配信ビデオクリップ格納検索システム。 ３１．前記データベースの他は独立オンラインサービスに存在する請求の範囲第 ３０項記載の配信ビデオクリップ格納検索システム。 ３２．前記ユーザインタフェースは最新情報を検索するための局所探索および更 新ロジックを含む請求の範囲第１５項記載の配信ビデオクリップ格納検索システ ム。 ３３．請求の範囲第１５項記載の１以上の遠隔ビデオクリップ格納検索システム に対する通信ゲートウエイおよび特別システムアドレスを更に含む請求の範囲第 １５項記載の配信ビデオクリップ格納検索システム。 ３４．前記探索エンジンは通信インタフェースと、ユーザ特定バッファロジック と、データベース管理ロジックと、格納管理ロジックと、メッセージ経路指定ロ ジックとにより構成される請求の範囲第１５項記載の配信ビデオクリップ格納検 索システム。 ３５．前記ユーザ特定バッファロジックは要求ビデオクリップの局所有効性を決 定し、前記データベース管理ロジックは要求ビデオクリップのシステムワイド有 効性を決定し、前記格納管理ロジックは前記システムに格納されたビデオクリッ プの場所および配信を決定し、前記メッセージ経路指定ロジックは前記システム を介しての質問およびビデオクリップの移動のための通信チャネルを決定する請 求の範囲第３４項記載の配信ビデオクリップ格納検索システム。 ３６．各ビデオクリップはメモリの連続ブロックに格納される請求の範囲第１５ 項記載の配信ビデオクリップ格納検索システム。 ３７．ユーザにダウンロードするための拡張遠隔格納個所からデータ順序づけイ ンタフェースに送られるオーディオ・ビジュアルデータを収集し、管理し、緩衝 するデータ順序づけインタフェースであって、 前記拡張遠隔格納個所の１以上に格納されるオーディオ・ビジュアルセグ メントの正確な位置を通信するための、索引マネージャと前記データ順序づけイ ンタフェースとの間の第１通信インタフェースと、 前記ダウンロードオーディオ・ビジュアルセグメントを前記データ順序づ けインタフェースの送信バッファに送るためにの、前記拡張遠隔格納個所と前記 データ順序づけインタフェースとの間の第２通信インタフェースと、 前記オーディオ。ビジュアルセグメントが検索されるまで前記オーディオ ・ビジュアルセグメントを含むように識別される各拡張遠隔格納位置から各オー ディオ・ビジュアルセグメントを順次要求するためのオーディオ・ビジュアル順 序づけロジックと、 各検索オーディオ・ビジュアルセグメントの場所を管理するための格納管 理ロジックと、 ユーザへの終局ダウンロードのため前記検索オーディオ・ビジュアルセグ メントが送られるユーザと前記データ順序づけインタフェースとの間の第３通信 インタフェースと、 により構成されるデータ順序づけインタフェース。 ３８．前記第１及び第２通信インタフェースは超高速であり、前記第３通信イン タフェースは高速である請求の範囲第３７項記載のデータ順序づけインタフェー ス。 ３９．各超高速インタフェースは少なくとも略１００メガボーの最小帯域幅を有 し、各高速インタフェースは少なくとも略５６キロボーの最小帯域幅を有する請 求の範囲第３８項記載のデータ順序づけインタフェース。 ４０．前記格納管理ロジックは、 オーディオ・ビジュアルセグメントが前記遠隔格納個所のいずれか１つか らまたは前記拡張格納個所から検索されたかどうかを決定する手段と、 オーディオ・ビジュアルセグメントが遠隔格納個所から検索された回数を 、最小要求オーディオ・ビデオセグメントが前記拡張格納個所から検索される回 数と比較する手段と、 前記遠隔格納個所から前記拡張格納個所へ、前記拡張格納個所からよりも より頻繁に前記遠隔格納個所から検索されるオーディオ・ビジュアルセグメント を複写する手段と、 前記最小要求オーディオ・ビジュアルセグメントを前記拡張格納個所から 取り除き、前記最小要求オーディオ・ビジュアルセグメントを前記遠隔格納個所 の１つに配置する手段と、 により構成される請求の範囲第３７項記載のデータ順序づけインタフェー ス。 ４１．前記オーディオ・ビジュアル順序づけロジックは、 前記拡張または遠隔格納個所のいずれかから要求されたオーディオ・ビジ ュアルセグメントが前記拡張または遠隔格納個所からのオーディオ・ビジュアル データの他の要求のために検索できないかどうかを決定する手段と、 他の拡張または遠隔格納個所から前記オーディオ・ビジュアルセグメント を要求する手段と、 どの格納個所が前記オーディオ・ビジュアルセグメントを前記索引マネー ジャに提供するかを通信する手段と、 により構成される請求の範囲第３７項記載のデータ順序づけインタフェー ス。 ４２．ユーザがそれを介してビデオクリップをクリップデータベースから要求で き、ネットワークに接続され、前記ネットワークを介して要求されたビデオクリ ップを受信でき表示できるマルチメディア端末と、 前記ネットワークに接続され、各々が複数のビデオクリップを格納する複 数の拡張格納検索ユニットと、 前記ネットワークを介して前記マルチメディア端末と通信し、前記マルチ メディア端末からのビデオクリップ要求を受け、処理するために適応される一次 索引マネージャと、 前記一次索引マネージャによって制御され、前記拡張格納検索ユニットに 前記要求ビデオクリップを前記マルチメディア端末にダウンロードさせるために 適応されるデータ順序づけインタフェースと、 により構成される配信ビデオクリップ搬送システム。 ４３．前記ネットワークはインターネットである請求の範囲第４２項記載の配信 ビデオクリップ搬送システム。 ４４．複数のユーザに適応するために複数のマルチメディア端末を更に含む請求 の範囲第４２項記載の配信ビデオクリップ搬送システム。 ４５．複数のユーザに適応するために複数の一次索引マネージャを更に含む請求 の範囲第４４項記載の配信ビデオクリップ搬送システム。 ４６．前記マルチメディア端末の各々は単一の一次索引マネージャに関連してい る請求の範囲第４５項記載の配信ビデオクリップ搬送システム。 ４７．複数の前記マルチメディア端末は前記一次索引マネージャの各々と関連す る請求の範囲第４６項記載の配信ビデオクリップ搬送システム。 ４８．前記マルチメディア端末はヘッドエンドインタフェース(head-end interf ace)を介して前記ネットワークに接続される請求の範囲第４２項記載の配信ビデ オクリップ搬送システム。 ４９．前記データ順序づけインタフェースは前記ヘッドエンドインタフェースに 直接接続される請求の範囲第４８項記載の配信ビデオクリップ搬送システム。 ５０．前記拡張検索ユニットの各々は前記データ順序づけインタフェースに接続 される請求の範囲第４９項記載の配信ビデオクリップ搬送システム。 ５１．各々が複数のビデオクリップを格納し、前記ネットワークに接続される複 数の遠隔格納検索ユニットを更に含む請求の範囲第５０項記載の配信ビデオクリ ップ搬送システム。 ５２．前記一次索引マネージャは全ての認可されたユーザに関する情報を含むユ ーザデータベースを維持する請求の範囲第４２項記載の配信ビデオクリップ搬送 システム。 ５３．前記マルチメディア端末にて走行するブラウザプログラムを更に含む請求 の範囲第４２項記載の配信ビデオクリップ搬送システム。 ５４．前記マルチメディア端末で走行し、前記ブラウザプログラムと対話できる ブラウザ拡張プログラムを更に含む請求の範囲第５３項記載の配信ビデオクリッ プ搬送システム。 ５５．前記マルチメディア端末はダウンロードクリップの一次格納のための格納 バッファを更に含む請求の範囲第４２項記載の配信ビデオクリップ搬送システム 。 ５６．前記データ順序づけインタフェースはダウンロードのために配列されたク リップの一時記憶に適応されるＲＡＭバッファを含む請求の範囲第４２項記載の 配信ビデオクリップ搬送システム。 ５７．ネットワークをブラウジング(browsing)するステップと、 関心ビデオクリップを識別するステップと、 前記ユーザに対応するユーザ情報を検索するためユーザデータベースを探 索するステップと、 前記関心ビデオクリップに対応するクリップ情報を検索するためクリップ データベースを探索するステップと、 前記ユーザが前記クリップを受けることを認可されているかを決定するた めに前記ユーザ情報をクリップ情報に整合するステップと、 何処に前記クリップ情報が格納されているかを決定するために前記クリッ プ情報を分析するステップと、 前記クリップをその格納個所からダウンロードすることをデータ順序づけ インタフェースに指令するステップと、 前記クリップを前記ユーザにダウンロードするステップと、 でなる、マルチメディア端末を有するユーザにネットワークを介してビデ オクリップを配信する方法。 ５８．マルチメディア端末でクリップを見るステップを更に含む請求の範囲第５ ７項記載の方法。 ５９．局所格納検索ユニットにクリップを格納するステップを更に含む請求の範 囲第５８項記載の方法。 ６０．ダウンロードのためにユーザによって受ける付加的負担を反映するために 前記ユーザデータベースを更新するステップを更に含む請求の範囲第５８記載の 方法。 ６１．クリップをダウンロードする前にクリップを保護するステップを更に含む 請求の範囲第５８項記載の方法。 ６２．クリップを見る前にクリップの保護を解除するステップを更に含む請求の 範囲第６１項記載の方法。 ６３．クリップを見る前にクリップを伸張するステップを更に含む請求の範囲第 ６２項記載の方法。 ６４．データ順序づけインタフェースにクリップをダウンロードさせる前にクリ ップが局所格納検索ユニットに格納されるかどうかを決定するステップを更に含 む請求の範囲第５７項記載の方法。 ６５．前記クリップが既に前記局所格納検索ユニットに格納されていれば、前記 クリップはダウンロードされない請求の範囲第６４項記載の方法。 ６６．前記クリップは前記マルチメディア端末で再現される請求の範囲第６５項 記載の方法。 ６７．前記クリップは、認可が一次索引マネージから受けられるときだけ再現さ れる請求の範囲第６４項記載の方法。 ６８．前記認可は前記ユーザデータベースの情報および前記クリップデータベー スの情報に基づいている請求の範囲第６７項記載の方法。 ６９．前記ユーザデータベースは一次索引マネージャによって維持される請求の 範囲第５７項記載の方法。 ７０．前記クリップデータベースは前記一次索引マネージャによって維持される 請求の範囲第６９項記載の方法。 ７１．前記探索、整合、分析および指令ステップは前記一次索引マネージャによ って行われる請求の範囲第７０項記載の方法。 ７２．前記ダウンロードステップはデータ順序づけインタフェースによって行わ れる請求の範囲第５７項記載の方法。 ７３．前記認識ステップは要求メッセージを前記一次索引マネージャに送ること を前記ブラウザに指令するユーザによって行われる請求の範囲第７１項記載の方 法。 ７４．前記要求メッセージはユ方法ーザおよび要求ビデオクリップを認識する部 分を有する請求の範囲第７３項記載の方法。 ７５．前記要求メッセージは前記一次索引マネージャのインターネットアドレス を特定し、ユーザを識別し、要求ビデオクリップの識別を独特に特定するテキス ト配列の形態である請求の範囲第７４項記載の方法。 ７６．前記クリップはクリップをダウンロードすることをデータ順序づけインタ フェースに指令する前に拡張格納検索ユニットに格納される請求の範囲第７１項 記載の方法。 ７７．クリップが拡張格納検索ユニットに格納されなけれは、何処にクリップが 格納されるかを決定するため隣接索引マネージャに問う合わせるステップを更に 含む請求の範囲第７６項記載の方法。 ７８．クリップが前記拡張格納検索ユニットに格納されれば、前記データ順序づ けインタフェースは前記拡張格納検索ユニットに直接接続されるコンピュータに 呼び出される請求の範囲第７８項記載の方法。 ７９．前記データ順序づけインタフェースはクリップが格納されている前記格納 検索ユニットに直接接続されるコンピュータに呼び出される請求の範囲第７７項 記載の方法。 ８０．前記隣接索引マネージャに対して局所的である格納検索ユニットにクリッ プが格納されていなければクリップが何処に格納されているかを決定するため前 記元の索引マネージャに問い合わせるステップを更に含む請求の範囲第７７項記 載の方法。 ８１．前記データ順序づけインタフェースは、クリップが格納されている前記格 納検索ユニットに接続されるコンピュータに呼び出される請求の範囲第８０項記 載の方法。 ８２．クリップが１以上の拡張格納検索ユニットに格納されていれば、最高速ダ ウンロード路を決定するステップを更に含み、前記データ順序づけインタフェー スは前記最高速ダウンロード路を介してクリップをダウンロードすることを指令 される請求の範囲第７６項記載の方法。 ８３．クリップが１以上の拡張格納検索ユニットに格納されていれば、最高速ダ ウンロード路を決定するステップを更に含み、前記データ順序づけインタフェー スは前記最高速ダウンロード路を介してクリップをダウンロードすることを指令 される請求の範囲第７９項記載の方法。 ８４．ユーザがクリップを受けることを認可されていことを決定されていたかど うかをユーザは知らされる請求の範囲第５７項記載の方法。 ８５．ユーザがクリップを受けることを認可されていないことを決定されていれ ば、ダウンロードが終了される請求の範囲第８４項記載の方法。 ８６．前記高速度ダウンロード路が利用不可であれば、別のダウンロード路を決 定し利用するステップを更に含む請求の範囲第８２項記載の方法。 ８７．前記ダウンロードステップが前記指令ステップ後の所定タイムアウト期間 以内に行うことができなければ、前記高速度ダウンロード路が利用不可であると 見なされる請求の範囲第８６項記載の方法。 ８８．所望内容に予約するステップを更に含む請求の範囲第５７項記載の方法。 ８９．前記予約クリップに基づいたカスタムウエブページ(custom Web pages)を 発生するステップを更に含み、このカスタムウエブページが予約クリップにリン クすることを含む請求の範囲第８８項記載の方法。 ９０．前記識別ステップは前記カスタムウエブページの１つのリンクを選択する ユーザによって行われる請求の範囲第８９項記載の方法。 ９１．定期予約料金を反映するために前記ユーザデータベースを更新するステッ プを更に含む請求の範囲第８８項記載の方法。 ９２．前記整合ステップは前記クリップ情報の定格属性と前記ユーザ情報の定格 制限とを比較するステップを含む請求の範囲第５７項記載の方法。 ９３．前記ネットワークに利用できるクリップを生成するステップを更に含む請 求の範囲第５７項記載の方法。 ９４．前記利用できるクリップを生成するステップは ウエブサーバにクリップをアップロードするサブステップと、 前記ウエブサーバに対応する索引マネージャに前記クリップを登録するサ ブステップと、 前記ネットワークの選択索引マネージャが何処にクリップを格納するかを 決定するサブステップと、 前記選択索引マネージャへ前記クリップを通すサブステップと、 前記クリップを選択拡張格納検索ユニットに装荷し、各拡張格納検索ユニ ットに対応する前記索引マネージャに前記クリップを登録するサブステップと、 を含む請求の範囲第９３項記載の方法。 ９５．前記通すステップはクリップを前記選択索引マネージャに多重送(multica st)することを含む請求の範囲第９４項記載の方法。 ９６．各索引マネージャは対応する格納検索ユニットにクリップを装荷するかを 決定する請求の範囲第９４項記載の方法。 ９７．前記決定は前記索引マネージャによって扱われる内容データベースに基づ いてなされる請求の範囲第９５項記載の方法。 ９８．効率的ネットワークの利用のためにクリップを配信するステップを更に含 む請求の範囲第５７項記載の方法。 ９９．前記配信ステップは、 以前の日の同時間および以前の週の同日での履歴使用に基づいて所定目的 領域において到来期間のクリップの第１予測使用頻度を計算するステップと、 先の日の同時間での履歴使用に基づいて到来期間のクリップの第２予測使 用頻度を計算するステップと、 直前の期間での履歴利用に基づいて到来期間のクリップの第３予測使用頻 度を計算するステップと、 クリップ毎に到来期間における全体の予測利用頻度を決定するため前記予 測頻度を合成するステップと、 前記予測利用頻度を包括するに必要な帯域幅を評価するステップと、 どの一般のクリップが前記予測使用頻度に最も寄与しているかを決定する ステップと、 前記評価帯域幅が閾値を越えていれば、負荷を配信するために前記一般ク リップを移動するステップと、 を含む請求の範囲第９８項記載の方法。 １００．前記合成ステップは前記第１予測使用頻度に対して２０〜４０％、前記 第２予測使用頻度に対して２０〜３０％、そして前記第３予測使用頻度に対して ３０〜６０％の重み付けを利用する請求の範囲第８８項記載の方法。 １０１．前記閾値は低速化しないで理論帯域幅容量の１０〜５０％である請求の 範囲第９９項記載の方法。 １０２．前記移動ステップは前記予測使用頻度を含めることのできる多数の拡張 格納検索ユニットに対して前記一般クリップを配信することを含む請求の範囲第 ９９項記載の方法。 １０３．クリップを送るときに生じる遅延を前記一次索引マネージャに通信する ステップを更に含む請求の範囲第８２項記載の方法。 １０４．前記一次索引マネージャはその拡張検索ユニットの各々によって起こる 明白な負荷を追跡する請求の範囲第１０３項記載の方法。 １０５．前記一次索引マネージャは、前記拡張格納検索ユニットの明白な負荷が 第１閾値より大きければ、拡張格納検索ユニットのクリップの再配信を指令する 請求の範囲第１０４項記載の方法。 １０６．前記第１閾値は低速化しないで理論帯域幅容量の略８０％である請求の 範囲第１０５項記載の方法。 １０７．前記一次索引マネージャは、一般クリップに基づいた拡張格納検索ユニ ットの明確な負荷が第２閾値より大きければ、前記一般クリップがＲＡＭバッフ ァに装荷されるべきことを指令する請求の範囲第１０５項記載の方法。 １０８．前記第２閾値は低速化しないで理論帯域幅容量の３０〜５０％である請 求の範囲第１０７項記載の方法。 １０９．前記一次索引マネージャは、前記データ順序づけインタフェースがどの 拡張格納検索ユニットからもダウンロードできなければ、隣接する索引マネージ ャと関連する遠隔格納検索ユニットからクリップがダウンロードされるべきこと を指令する請求の範囲第１０７項記載の方法。 １１０．前記明白な前記遠隔格納検索ユニットは前記一次索引マネージャに問い 合わせることによって前記データ順序づけインタフェースによって識別される請 求の範囲第１０９項記載の方法。 １１１．あるビデオクリップは複数のセグメントからなる請求の範囲第４２項記 載の配信ビデオクリップ搬送システム。 １１２．前記セグメントはセグメントクリップ関連するセグメントデータによっ て示される請求の範囲第１１１項記載の配信ビデオクリップ搬送システム。 １１３．前記セグメントデータは各セグメントと関連する原文情報で構成される 請求の範囲第１１２項記載の配信ビデオクリップ搬送システム。 １１４．前記セグメントデータは各セグメントと関連するインターネットアドレ スで構成される請求の範囲第１１３項記載の配信ビデオクリップ搬送システム。 １１５．前記セグメントデータは付加ビデオクリップを識別する請求の範囲第１ １４項記載の配信ビデオクリップ搬送システム。 １１６．前記セグメントデータが前記一次索引マネージャに格納される請求の範 囲第１１２項記載の配信ビデオクリップ搬送システム。 １１７．前記分割クリップは前記拡張格納検索ユニットに複数のファイルとして 格納される請求の範囲第１１６項記載の配信ビデオクリップ搬送システム。 １１８．前記クリップが分割されるかを決定するステップと、クリップが分割さ れれば、それをユーザに知らせるステップと、セグメントが所望とされるインス トラクションを待つステップとを更に含み、前記ダウンロードステップは前記所 望のセグメントだけをダウンロードする請求の範囲第５７項記載の方法。 １１９．クリップが分割されるかを決定するステップと、どのセグメントがユー ザデータベースのデータをアクセスすることによって所望されるかを計算するス テップとをさらに有し、前記ダウンロードステップは所望のセグメントだけをダ ウンロードする請求の範囲第５７項記載の方法。 １２０．前記格納バッファは前記端末と前記インタフェースの間に介在される局 所格納検索ユニットにより構成される請求の範囲第５５項記載のシステム。 １２１．前記局所格納検索ユニットはスペースが許す限りビデオクリップの局所 データベースを維持する請求の範囲第１２０項記載のシステム。 １２２．前記マルチメディア端末は前記ネットワークによってビデオクリップを 交互に受けるため前記局所データベースをアクセスできる請求の範囲第１２１項 記載のシステム。 １２３．前記要求メッセージはウエブページに含まれている請求の範囲第７５項 記載の方法。 １２４．前記セグメントクリップはＭＰＥＧファイルである請求の範囲第１１２ 項記載の方法。 １２５．前記セグメントデータは前記ＭＰＥＧファイルに属するユーザセグメン トに格納される請求の範囲第１２４項記載の方法。 １２６．前記保護ステップは クリップ内のキーデータフィールドを識別するステップと、 前記キーフィールドの内容を暗号化するステップと、 前記クリップ内の前記暗号化内容を格納するステップと、 前記キーデータフィールドを変造内容と置き換えるステップと、 を含む請求の範囲第６１項記載の方法。 １２７．前記保護ステップは 前記ユーザに対応する情報に基づいたユーザ透かし(user watermark)を 発生するステップと、 前記クリップに前記ユーザ透かしを格納するステップと、 を更に含む請求の範囲第１２６項記載の方法。 １２８．前記クリップはＭＰＥＧファイルであり、前記暗号化内容は前記ＭＰＥ Ｇファイルに属するユーザストリーム内に格納される請求の範囲第１２６項記載 の方法。 １２９．前記クリップはＭＰＥＧファイルであり、前記ユーザ透かしは前記ＭＰ ＥＧファイルに属するユーザストリームに格納される請求の範囲第１２７項記載 の方法。 １３０．前記非保護ステップは 前記クリップ内のキーデータフィールドを識別するステップと、 前記暗号化内容が格納されている個所を位置付けするステップと、 前記暗号化内容を解読するステップと、 前記キーデータフィールドを前記解読内容と置き換えるステップと、 により構成される請求の範囲第１２６項記載の方法。