JP3754912B2 - マルチメディアコンテンツの配信方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、マルチメディアコンテンツへの電子的なアクセスに関する。
【０００２】
【従来の技術】
ネットワークの接続性が爆発的成長を続けるにつれて、コンテンツプロバイダはワールド・ワイド・ウェブ（「ウェブ」）を使用してマルチメディアコンテンツ（例えば画像、ビデオ、オーディオなど）へのアクセスを提供している。ＨＴＭＬページなどのテキストコンテンツと異なり、マルチメディアコンテンツは、標準的なウェブ検索エンジンから直接アクセス可能ではない。これらの検索エンジンはウェブのサイトを検査し、それらのサイトのテキストコンテンツに関する情報を抽出する。そのような情報を、通常「メタデータ」と称し、メタデータは他のデータの諸態様を説明するかカタログ化するデータである。抽出された情報（メタデータ）により、ユーザにカスタマイズされたメタデータ・データベースを使用してそのコンテンツへのアクセスを与えることができる。
【０００３】
マルチメディアの場合、コンテンツプロバイダ又はコンテンツディストリビュータは、通常、それがアクセスできるマルチメディア項目に関する情報を、メタデータ・データベースに保管する。コンテンツプロバイダは、ユーザ又は顧客がウェブサイト、通常はコンテンツプロバイダ／ディストリビュータ自身のウェブサイトからアクセスできる検索エンジンを提供することにより、これらのデータベースへのアクセスを可能にする。コンテンツプロバイダ／ディストリビュータがアクセスできるコンテンツの表示又はおそらくは購入を求める顧客は、ウェブサイトを訪問し、検索エンジンを使用して、コンテンツプロバイダ／ディストリビュータのメタデータ・データベースを検索することができる。通常、メタデータ・データベースには、メタデータの一部として、コンテンツの視覚的識別子（例えばサムネイル、ビデオアブストラクト、オーディオプレビューなど）が含まれる。ユーザは、それらの検索から返されたメタデータに基づいて購入／使用を望む項目に関する決定を行うことができる。
【０００４】
多くの場合、マルチメディアコンテンツはディジタルであり、オンラインであり、潜在的な顧客はコンテンツプロバイダ／ディストリビュータのウェブサイトから所望のマルチメディア項目を使用する権利を購入するか、所望のマルチメディア項目のコピーを購入することができる。たいてい、このトランザクションはウェブサイト上で完了し、潜在的な顧客は新たに獲得したコンテンツを直接にダウンロードすることができる。しかし、マルチメディアコンテンツへのアクセスを提供するこのモデルは、コンテンツがオンラインであることを必要としない。例えば、潜在的な顧客は、ウェブサイトから所望のコンテンツを使用する権利又は所望のコンテンツのコピーを購入することができるが、そのコンテンツを非電子的手段（即ち、郵便システム）によって潜在的な顧客に配送することもできる。もう１つの変形形態は、所望のコンテンツの購入及びコピーの獲得のために、潜在的な顧客をディストリビュータのサイトから実際のコンテンツプロバイダにリダイレクトすることができるというものである。他の変形形態には、潜在的な顧客を、コンテンツを購入するための物理的な位置に案内すること、購入される項目に関連するメタデータを含む書籍を郵送することが含まれる。
【０００５】
上述の状況の全てにおいて、潜在的な顧客は、各コンテンツプロバイダ／ディストリビュータがアクセスできるコンテンツへのアクセスを得られるだけである。潜在的な顧客が、複数の異なるコンテンツプロバイダ／ディストリビュータに跨がる検索を実行することを求める場合には、潜在的な顧客は複数のコンテンツプロバイダ／ディストリビュータのそれぞれのウェブサイトを訪問し、その検索エンジンを使用しなければならない。潜在的な顧客は、毎回異なる検索エンジンインターフェースを使用しなければならないので、そのようなアクションはしばしば時間がかかり、厄介である。
【０００６】
これらの問題によって、コンテンツディストリビュータがコンテンツの権利を購入するか、より小さいコンテンツプロバイダのディストリビュータとして単純に働くかのいずれかである、ウェブでの非常に大きいメタデータ・データベースの開発が促進された。その例がGetty及びCorbusという巨大な画像データベースである。この手法はそれ自体の問題を有する。まず、この手法は、データベースが非常に大きくなる際に検索時間が増えるので、スケーリングしない。更に、通常、同一のメタデータキーが含まれるように、全てのメタデータを類似する形で構成しなければならない。しかし、コンテンツの使用目的に応じて、異なるメタデータがより適切になるので、これは必ずしも望ましくはない。例えば、地質学用に取り込まれた画像は、休暇向けのパンフレット用に取り込まれたものと異なるメタデータを必要とする。第３に、より小さいコンテンツプロバイダは、そのコンテンツを直接に販売する方法を有しない（即ち、彼らは効果的により大きいディストリビュータを使用することを強制される）。
【０００７】
本発明の目的は、従来技術の１つ又は複数の短所を改善することである。
【０００８】
【課題を解決するための手段】
本発明のマルチメディアコンテンツの配信方法は、メディアブラウザサーバが、ユーザに対して許可されたマルチメディアコンテンツの目次データをデータベースに記憶するステップを実行し、第１のユーザ装置が、前記メディアブラウザサーバにアクセスして該第１のユーザ装置に供給された前記マルチメディアコンテンツの目次データ全体を表示する第１の表示ステップを実行し、第２のユーザ装置が、前記メディアブラウザサーバにアクセスして該第２のユーザ装置に供給された前記目次データの中から第２のユーザ装置により複製可能なマルチメディアコンテンツの項目を表示する第２の表示ステップと、前記第２の表示ステップで表示した項目の中から要求されたマルチメディアコンテンツを前記メディアブラウザサーバから複製する複製ステップとを実行することを特徴とする。
【００１５】
【発明の実施の形態】
Ｉ．概要
図１に、以下でメディアブラウザ１０１と称するコンピュータアプリケーションプログラムがインターネット１０２などのコンピュータネットワークへの接続を形成するためにローカルコンピュータ１０５で動作する、マルチメディアアクセスシステム１００を示す。図からわかるように、インターネット１０２は複数のサーバコンピュータ１０８及び１０９を関連付けられ、サーバコンピュータのそれぞれが複数のウェブサイトをホストすることができ、ウェブサイトのそれぞれについて、マルチメディアコンテンツを保存することができる対応するストア１１２及び１１４がある。また同様に、ローカルコンピュータ１０５も関連するストア１０７を有することができるが、これは実施に必須ではない。メディアブラウザアプリケーション１０１は、ローカルコンピュータ１０５のユーザが電子的にアクセス可能なメタデータを使用してマルチメディア項目についてシステム１００をブラウズし、検索するための単一のユーザインターフェースを提供する。言い換えると、メディアブラウザ１０１はメタデータを操作する。マルチメディアコンテンツの再生／表示は、プラグインメディアツールの使用によって達成され、メタデータ関連の処理から分離される。メディアブラウザ１０１は、以下の節IVで詳細に説明する。
【００１６】
上述した配置は、図９に示されたものなどの汎用コンピュータシステム９００を使用して実践することができ、ここで、図１の処理及びこれから説明する処理が、コンピュータシステム９００内で実行されるアプリケーションプログラムなどのソフトウェアとして実施される。具体的に言うと、メディアブラウジングの方法はコンピュータシステムによって実行されるソフトウェア内の命令によってもたらされる。ソフトウェアは、本質的に２つの別々の部分、即ち、特定のメタデータストアに関するブラウジング要求及び検索要求を実行する部分と、特定のメタデータストアとユーザの間のユーザインターフェースを管理する部分に分割することができる。これらの２つの部分を、クライアント−サーバモードと称するモードで別々のコンピュータで実行することができる。ソフトウェアは、例えば以下で説明する記憶装置を含む、１つ又は複数のコンピュータ可読媒体に保管することができる。ソフトウェアは、コンピュータ可読媒体からシステムのコンピュータにロードされ、その後、そのコンピュータによって実行される。そのようなソフトウェア又はコンピュータプログラムをその上に記録されたコンピュータ可読媒体がコンピュータプログラム製品である。コンピュータでのコンピュータプログラム製品の使用がメディアブラウジングのための有利な装置をもたらすことが好ましい。
【００１７】
コンピュータシステム９００には、コンピュータモジュール９０１と、キーボード９０２及びマウス９０３などの入力装置と、プリンタ９１５及びオーディオ−ビジュアル出力装置９１４を含む出力装置とが含まれる。変調器−復調器（モデム）トランシーバ装置９１６は、例えば電話回線９２１又は他の機能媒体を介して接続可能な通信ネットワーク９２０との通信のために、コンピュータモジュール９０１によって使用される。ネットワーク９２０は、例えばインターネット又はローカルエリアネットワーク（ＬＡＮ）或いは広域ネットワーク（ＷＡＮ）などの他のネットワークシステムもしくはその両方とすることができる。集合的に、装置９０１〜９１６が、例えばローカルコンピュータ１０５又は図１に示すサーバコンピュータ１０８及び１０９の１つ又はいずれかを形成することができ、しばしばコンピュータワークステーションと記述される。
【００１８】
コンピュータモジュール９０１には、通常、少なくとも１つのプロセッサユニット９０５と、例えば半導体ランダムアクセスメモリ（ＲＡＭ）及び読取専用のメモリ（ＲＯＭ）から形成されるメモリユニット９０６と、オーディオ−ビジュアルインターフェース９０７を含む入出力（Ｉ／Ｏ）インターフェースと、キーボード９０２及びマウス９０３及び任意選択のジョイスティック（図示せず）のための入出力インターフェース９１３と、モデム９１６のためのインターフェース９０８が含まれる。記憶装置９０９が設けられ、これには、通常、ハードディスクドライブ９１０及びフロッピディスクドライブ９１１が含まれる。磁気テープドライブ（図示せず）も使用することができる。ＣＤ−ＲＯＭドライブ９１２が、通常、データの不揮発性供給源として設けられる。コンピュータモジュール９０１のコンポーネント９０５〜９１３は、通常、相互接続されたバス９０４を介して当業者に既知のコンピュータシステム９００の動作の通常のモードをもたらす形で通信する。説明された配置を実践できるコンピュータの例には、ＩＢＭ−ＰＣ及び互換機、Sun Sparcstation、及びそれらから発した類似するコンピュータシステムが含まれる。
【００１９】
通常アプリケーションプログラムは、ハードディスクドライブ９１０に常駐し、プロセッサ９０５によって読み取られ、その実行中に制御される。プログラム及びネットワーク９２０から取り出されたデータの中間記憶は、おそらくはハードディスクドライブ９１０と共に、半導体メモリ９０６を使用して達成することができる。オーディオ−ビジュアル出力装置９１４は、アプリケーションプログラムにグラフィカルユーザインターフェースを与えるのに使用することができ、これにより、ユーザ入力を、キーボード９０２を介して、及びマウスカーソルがオーディオ−ビジュアル出力装置９１４に提示されるインターフェースで操作される際にマウス９０３のボタンをクリックすることにより、与えることができる。場合によっては、アプリケーションプログラムが、ＣＤ−ＲＯＭ又はフロッピディスク上でエンコードされ、対応するドライブ９１２又は９１１を介して読み取られてユーザに供給されることができ、その代わりに、ネットワーク９２０からモデム装置９１６を介してユーザによって読み取られることができる。更に、ソフトウェアは、磁気テープと、ＲＯＭ又は集積回路と、光磁気ディスクと、コンピュータモジュール９０１と別の装置との間の無線伝送チャネル又は赤外線伝送チャネルと、ＰＣＭＣＩＡカードなどのコンピュータ可読カードと、電子メール伝送及びウェブサイトに記録された情報を含むインターネット及びイントラネットと類似物を含む、他のコンピュータ可読媒体からコンピュータシステム９００にロードすることもできる。前述は、関連するコンピュータ可読媒体の単なる例示である。他のコンピュータ可読媒体を、本発明の範囲及び趣旨から逸脱せずに実践することができる。
【００２０】
図１に戻って、メディアブラウザ１０１によって使用されるメタデータには、ローカルコンピュータ１０５から直接、又はサーバ１０８などのインターネット１０２上のアクセス可能なサイトからアクセスすることができる。通常、マルチメディアコンテンツのコレクションに関するメタデータは、少なくとも１つの対応するメターデータ項目を有するコンテンツの各項目と共に、コレクション（例えば、リポジトリ又はデータベース）に保管される。図１からわかるように、各コンテンツデータベース又はストア１０７、１１２、及び１１４は、それぞれ、対応するデータベース１０６、１１０、及び１１１に関連付けられ、これらのデータベースは対応する各々のコンテンツデータベース又はストア１０７、１１２、及び１１４内のコンテンツへのアクセスを容易にするためにメタデータ項目を保存するように構成される。以下では、メタデータ項目を、それに対応する項目（通常はコンテンツ）の記述とも称し、用語、メタデータコレクションは、そのような記述のコレクションを指す。
【００２１】
好ましい例では、メディアブラウザ１０１は、コンテンツ（１０７、１１２、及び１１４）にアクセスする必要なしにメタデータにアクセスすることができる。言い換えると、記述はコンテンツの項目の一体化された部分として保管されるのではない。これは、メディアブラウザ１０１がメタデータにアクセスするためにオーディオビジュアルコンテンツの多数の保管フォーマット／トランスポートフォーマットを直接に解釈できることを必要としないことを意味する。
【００２２】
メディアブラウザ１０１は、各記述（データベース１０６、１１０、及び１１１内）が、コンテンツデータベース又はストア（１０７、１１２、及び１１４）内のそれに対応するコンテンツへのリンクを有すると仮定する。コンテンツが、電子的に保管される場合には、これらのリンクを、ユーザによって又はプロセスによって発動させるか、電子的に従う（例えば１２０、１１５、及び１１６）ことができる。その代わりに、リンク１１８などのリンクによって非電子的な位置（例えばフィルムアーカイブ）への経路を記述することができる。非電子リンクは、能動的ではなく（即ち、リモートユーザ又はプロセスがそれに従うことができない）、従って、使用可能なコンテンツの知識を与えるだけである。よって、そのような非電子リンクを用いてリモートユーザが、メディアブラウザ１０１を使用してコンテンツをプレビューする能力を得ることはできない。
【００２３】
メディアブラウザ１０１は、メタデータを標準的な形で表現できることを必要とする。好ましい例では、個々の記述の構文及び構造が、スキーマによって定義される。コンテンツの異なる項目の記述で、異なるスキーマを使用することができる。通常、使用されるスキーマは、コンテンツのタイプと、コンテンツの通常の使用法又は目的を反映する。例えば、地質学衛星画像のメタデータスキーマは、ディジタルホームビデオのスキーマと大きく異なる可能性が非常に高い。
【００２４】
スキーマは、構文構造及び記述コンポーネント（以下では記述子と称する）の型の性質において異なる可能性がある。例えば、ディジタルホームビデオのスキーマでは、それぞれが１つ又は複数のクリップ又はショットを含む１つ又は複数のシーンを含むディジタルビデオテープを含ませるためにコンテンツのこの型の記述がモデル化される可能性がある。地質学衛星画像スキーマは、単に各画像を記述するのに使用される特定の地質学的焦点を有する複数の記述子を有するものとすることができる。好ましい例では、スキーマはＷ３ＣのＸＭＬ（Extensible Markup Language）スキーマ（Schema）言語を使用して表現され、個々の記述はＸＭＬ文書として表現される。メタデータ表現は、節IIでさらに説明する。
【００２５】
図２に、メディアブラウザ１０１がインターネット１０２を介してメタデータにアクセスできる方法の例を示す。メタデータへのアクセスの全ては、各リンクのターゲットがＵＲＩ（Uniform Resource Identifier）として表現されるリンクを使用して達成される。これらのリンクは、メディアブラウザ１０１によって自動的に、又はユーザアクション（例えば当の項目をクリックすること）に応答してのいずれかで発動させることができる。
【００２６】
メタデータが、ＸＭＬリポジトリ（ＸＭＬ文書のコレクション）２００に保管される場合には、メディアブラウザ１０１はリポジトリ２００のＸＭＬ記述へのリンクを使用してリポジトリ２００に保管されたメタデータへのアクセスを提供することができる。この記述では、メディアブラウザ１０１のユーザに提示されるリポジトリ２００の構造が表現される。ＸＭＬ記述は、コンテンツのマルチメディア項目の記述と同一の形で表現される。言い換えると、記述は、メディアブラウザ１０１からアクセス可能であり、リポジトリ２００の構造を記述するＸＭＬスキーマに準拠することが好ましい。ＸＭＬ記述には、リポジトリ２００の特定のセクションの他の記述へのリンクを含めることができる（言い換えると、リポジトリ２００の記述が、単一のＸＭＬ文書内に含まれる必要はない）。最終的に、リポジトリＸＭＬ記述は、マルチメディア項目の記述へのリンクを有する。リポジトリ２００内のマルチメディア項目の記述のそれぞれに、対応するコンテンツコレクション２０２内の対応するマルチメディア項目へのリンク２０１が含まれることが好ましい。これにより、ユーザ又は顧客が提示されたメタデータに基づいて項目の表示又は再生を選択する場合、メディアブラウザ１０１はこれらの項目を取り出せるようになる。
【００２７】
本明細書でレガシデータベース２１０と称する非ＸＭＬリポジトリへのアクセスが所望される場合、上述の図１に関して説明したリンクが、メタデータサーバ２１２と称するサーバモジュールを介して動作しなければならない。メタデータサーバ２１２は、メタデータのサイト（即ち、ローカル又はリモートのいずれか）に配置されることが好ましいが、それが必要ではなく、メタデータの所有者によって構成され、制御される。メタデータサーバ２１２の目的は、レガシデータベース２１０に格納されたメタデータを、メディアブラウザ１０１が必要とするフォーマットに効果的に変換することである。言い換えると、メタデータサーバ２１２は、好ましくはメタデータに関する１つ又は複数のスキーマへのアクセスを提供し、これらのスキーマに準拠するＸＭＬ記述を動的に生成しなければならない。メタデータサーバ２１２が、メタデータコレクションの構造／構文を記述するスキーマ定義を提供することだけが必要であり、個々の記述の構造／構文はレガシデータベース２１０に格納されることが好ましい。これらのスキーマ定義は、１つ又は複数のＸＭＬスキーマ文書に含ませても良い。リモートメタデータがＸＭＬリポジトリ２００に保管される場合と同様に、メタデータサーバ２１２が生成するマルチメディア項目の記述には、レガシデータベース２１０に対応するコンテンツコレクション２１４に保管された対応するマルチメディア項目へのリンクが含まれる。
【００２８】
メタデータサーバへのリンクも、ＵＲＩを使用して表現される。このＵＲＩは、ＵＲＩ自体であるネットワーク識別子コンポーネントと、メタデータサーバ要求の詳細を指定する照会文字列からなる。要求は、インターネット上のＨＴＴＰ（Hypertext Transfer Protocol）の「ｇｅｔ」要求を使用して実行することができる。照会の処理は、メタデータサーバ２１２が照会文字列をどのように解釈するかに応じて、コレクションの構造又はマルチメディア項目のいずれかの記述をもたらす。
【００２９】
メタデータサーバ２１２によって動的に生成される記述は、メディアブラウザのユーザのブラウジング結果又は検索結果に応答するものとすることができる。メタデータサーバについては、以下の節IIIで更に説明する。
【００３０】
II．メタデータ表現
好ましい例では、マルチメディア項目の全ての記述がスキーマに準拠し、スキーマがＷ３Ｃのスキーマ言語であるＸＭＬスキーマを使用して表されるか表現されることを前提とする。個々の記述は、ＸＭＬ文書インスタンスを使用して表現される。ＸＭＬスキーマも、ＸＭＬ文書として表現される。従って、記述（例えばマルチメディア項目の）を、各スキーマと共に、ＸＭＬリポジトリ又はＸＭＬオブジェクトストアに保管することができる。その代わりに、記述を、データベースに保管し、必要な時に効果的にＸＭＬ文書に変換することができる。
【００３１】
各記述には、それが準拠するスキーマへの参照が含まれる。参照は、ＵＲＩ（例えばhttp://somesite/schemas/DigitalVideoSchema.xsd）を使用して表される。これは、メディアブラウザが、記述へのアクセスを得た後に、その記述が準拠する１つ又は複数のスキーマに直接にアクセスできることを意味する。
【００３２】
通常、記述（ＸＭＬ文書）の各ＸＭＬ要素は、一意に識別される名前空間に属するように宣言される。ＸＭＬ文書が、属性schemaLocation（ＸＭＬSchema-instance名前空間内）を使用して、特定の名前空間に関する定義を含むスキーマの位置についてプロセッサにヒントを与えることができる。従って、ＸＭＬ文書は、よって記述も、直接ではなく間接的に１つ又は複数のスキーマを参照する。
【００３３】
この文書では、用語「記述子」を、記述のコンポーネント又はアトムを指すのに使用する。各記述子には、特徴（記述子名）及び値（記述値）が含まれる。場合によっては、記述子値に、他の記述子が含まれ、よって、記述子値が、「複合記述子」を形成することができる。他の場合には、記述子値が、文字列又は日付などのスカラ値である（即ち単純記述子又は原子的記述子）。どの場合でも、メディアブラウザ１０１は、記述子が、要素（タグ）名が記述子名であり要素の内容が記述子値である状態で表現されると仮定する。例えば、単純記述子は、記述子の値（例えば日付、テキスト列、列挙など）を表現するために要素のテキスト内容（即ち、タグの間のテキスト）を使用することができる。
【００３４】
メタデータの構造に関するこの前提は、多くの実務家が現在マークアップ言語を使用する方法と異なってはいない。言い換えると、これは実務家が特定のメタデータ語彙を表現する方法からの大幅な変更を必要としない。
【００３５】
記述の例を、これからいくつか示す。単純記述子、＜Photographer＞John Smith＜／Photographer＞では、Photographerが、記述子の名前であり、John Smithが記述子の値である。単純記述子のテキストの型は、ＸＭＬスキーマのsimpleType構成を使用して制約することができる。
【００３６】
図８に示された例では、VideoSceneとClipの両方が、複合記述子である。VideoScene記述子の値は、この記述子の開始タグと終了タグとの間に含まれるマークアップである。記述子の名前は、タグ名（即ち、VideoScene）である。同様に、Clip複合記述子の値は、Clip記述子の開始タグと終了タグの間に含まれるマークアップである。Clip記述子値には、２つの単純記述子Date及びLocationが含まれる。Location記述子の値は、開始Locationタグと終了Locationタグとの間に含まれるテキスト（即ち、Sydney,Australia）である。
【００３７】
意味のある形でユーザに記述を視覚的に提示するために記述の基本セマンティクスをより良く解釈できるようになるために、好ましい例に、記述スキーマ設計者が自分の記述子を定義する時に使用することができる複数の基本属性の定義を含むコアスキーマが含まれる。このコアスキーマに含まれる定義の例を、以下の例Ａに示す。この例Ａでは、実際のスキーマの一部分だけが示されている。この例の定義は、この例ではプレフィックス「mb:」によって識別される一意のメディアブラウザ名前空間に属する。このプレフィックス割当がスキーマ内でxmlns属性を使用して前に実行されていると仮定する。
【００３８】

【００３９】
属性descriptorTypeは、記述が、目次（Table of Contents）の一部（ＴＯＣ記述子）として扱われるのか、インデックスの一部（index記述子）として扱われるのかを定義するのに使用される。
【００４０】
ＴＯＣ記述子は、記述の構造を記述するのに使用され、通常は複合記述子である。ＴＯＣ記述子は、その属性又はその子の属性のいずれかにリンクが含まれなければならないという意味で、ナビゲート可能である。リンクのターゲットは、別の記述子又はコンテンツの項目のいずれかとすることができる。ＴＯＣ記述子は、読者が作品のセクションに直接に移動できるようにするという点で、書籍の目次（table of contents）の項目に類似する。
【００４１】
index記述子は、通常、階層式に構成された記述子構造の葉ノードであり、しばしばプロパティと称する（即ち、Microsoft Windows（登録商標）システムでプロパティダイアログを使用して表示されるタイプの記述情報）。以下の節IVで、メディアブラウザがdescriptorType属性を使用する方法を説明する。
【００４２】
属性は、記述子の視覚的識別子又はテキスト識別子もしくはその両方を含めるのにも使用される。視覚的識別子（即ち、visualIdentifier属性）は、サムネイル又はムービー／オーディオトラックプレビューのＵＲＩとすることができる。テキスト識別子（即ち、textIdentifier属性）は、視覚的識別子の代わりに、又はこれに追加して使用することができる。テキスト識別子には、通常、記述子を説明する文字列値が含まれる。視覚的識別子がない場合に、メディアブラウザは、このテキスト値に基づいて視覚的表現を構築することができる。これらのコア属性が、メディアブラウザのユーザインターフェースを「駆動」する。言い換えると、これらはプレゼンテーションのために含まれている。
【００４３】
コアスキーマで定義されるこれらの視覚的属性のほかに、好ましい例では、リンキングセマンティクスを提供するために、開発中のＷ３Ｃ ＸＬｉｎｋ標準規格（http://www.w3.org/TR/xlinkに記載されている）のリンキング属性を使用する。ＸＬｉｎｋは、ＨＴＭＬの＜Ａ＞リンキング要素などの基本的な一方向リンクと、より複雑なリンキング構造の両方を作成するためのフレームワークを提供する。単純リンキング要素は、好ましい例の共通のリンキング要件である。これらのリンクは、２つの記述子（即ち、メタデータの項目）の間のリンクと、記述子（メタデータ）とコンテンツ（例えば、画像、ビデオなど）の間のリンクを表現するのに使用することができる。ＸＬｉｎｋは、拡張されたリンク、ロケータ、及びアークなどの他のリンキングタイプも提供する。リンキングタイプの完全なリストは、http://www.w3.org/TR/xlinkに記載されている。
【００４４】
ＸＬｉｎｋを使用するリンクの存在は、ＸＬｉｎｋリンキング要素によってアサートされる。これらの要素は、適当な表示又は振る舞いを提供するために、アプリケーションによって理解される必要がある。ＸＬｉｎｋでは、名前空間を使用してリンク認識を達成する。好ましい例によって使用されるＸＬｉｎｋ名前空間はＵＲＩ、http://www.w3.org/1999/xlinkを有し、ｘｌｉｎｋプレフィックスに関連付けられる。この関連付けは、ＸＭＬのxmlns属性を使用して達成される（例えば、xmlns:xlink='http://www.w3.org/1999/xlink'）。ＸＬｉｎｋの名前空間は、任意の名前空間に含まれる要素に対して使用することができるグローバル属性の定義を提供する。これらのグローバル属性（xlink:type, xlink:href, xlink:role, xlink:title, xlink:show, xlink:actuate, xlink:from, xlink:to）は、要素をリンキング要素として認識可能にするのに使用することができる。例えば、特定の要素について、xlink:type属性の値に「simple」がセットされている場合には、その要素は、単純リンク要素として扱われ、属性xlink:hrefの値に、そのリンクのターゲットが含まれる。この説明の目的のために、ＸＭＬスキーマを使用するリンキング属性の定義を、以下の例Ｂに含める。
【００４５】

【００４６】
特定のスキーマで、スキーマの個々の記述子を宣言する時に、コアＸＬｉｎｋ属性及びメディアブラウザ属性を使用することができる。以下の例Ｃでは、特定の記述子VideoClip、Date、及びPhotographerが、特定のスキーマで宣言される。実際のスキーマの一部だけが示されており、メディアブラウザ名前空間及びＸＬｉｎｋ名前空間への参照がそれぞれ名前空間プレフィックスｍｂ及びｘｌｉｎｋを介して仮定されていることに留意されたい。ＸＭＬスキーマでは、これらの名前空間プレフィックスがＸＭＬスキーマ言語のxmlns属性を使用して割り当てられる。メディアブラウザ属性は、例Ｃの行21に見られるように、TOCDescriptorAttributesに関するその定義から未変更のままで参照される。しかし、例えば行24に見られるものなどの、参照されるＸＬｉｎｋ属性の１つが、その元の定義からさらに再定義されている。例えば、VideoClip記述子は、単純リンキング要素であり、従って、xlink:type属性の値は、「simple」というデフォルト値になる。単純リンクに関して、要素（記述子）はリンクソースであり、単一のリンクエンドが存在しなければならない。この単一のリンクエンドは、xlink:href属性を使用して表現される。単純リンクが有効になるためには、この属性の値を供給しなければならない（従って、この属性のuse制約に「required」がセットされている）。また、VideoClip記述子のxlink:href属性は「resource」というそのデフォルト値になることに留意されたい（即ち、リンクのターゲットは記述されているコンテンツの項目であると仮定されなければならない）。
【００４７】

【００４８】
この特定のスキーマ断片に準拠する記述に、例Ｄの断片を含めることができる。
【００４９】

【００５０】
好ましい例では、コアメディアブラウザ属性はスキーマ又は記述もしくはその両方で明示的に表現される。代替例では、以下で説明するように、記述の他の情報からこれらの属性値を推論することができる。例えば、記述子／要素は、それにその属性内又はその子の属性内のいずれかのリンクが含まれる場合に、ＴＯＣの一部として扱うことができる。更に、子孫リンクを有しない記述子は、index記述子として扱うことができる。同様に、視覚的識別子を、要素（記述子）名から自動的に構築することができる。これらの属性値を推論する方法を、後にこの節で詳細に説明する。
【００５１】
明らかに、コアメディアブラウザ及びｘｌｉｎｋのセマンティックスを表現できる代替の形がある。例えば、ＸＭＬスキーマを使用すると、コアDescriptor型を定義し、そのコア型からTOCDescriptor型及びIndexDescriptor型を導出することができる（以下の例Ｅを参照されたい）。その場合に、個々のスキーマ定義によって、これらの基本型を拡張して、例Ｃで定義されたものなどの実装ベースの記述子を提供することができる。また、好ましい例では、そのスキーマ表現言語としてＸＭＬスキーマを使用しているが、他の適当な表現力のあるスキーマ言語を使用しても良い。
【００５２】

【００５３】
［メタデータの解釈］
実際には、ユーザがメディアブラウザ１０１を使用して視覚化することを望むメタデータの全てで、上述したメディアブラウザ１０１属性及びＸＬｉｎｋ属性が明示的に使用されるわけではない。新しい記述を解析した時に、メディアブラウザ１０１は、まず受信したメタデータのタイプの識別を試みるが、このタイプの例には、それぞれが当技術分野で既知のメタデータ標準規格である、画像に関するDublin Core, MPEG-7又はDIG35を含めることができる。通常、これは、記述のルート要素宣言又は名前空間宣言のいずれかを検査することによって達成することができる。メディアブラウザ１０１がメタデータ標準規格を識別する場合、メディアブラウザ１０１は、ＸＳＬＴスタイルシートを使用して、入力の文書木（記述）を、メディアブラウザ属性及びＸＬｉｎｋ属性を明示的に使用するものに変換する。それ以上の処理は不要である。言い換えると、この変換によって、それ以上の処理なしでメディアブラウザが提示できる記述がもたらされる。
【００５４】
他の全ての記述について、検査を実行して、好ましいメディアブラウザ属性が存在することを保証することを試みる。それらが存在しない場合には、好ましい実施形態では、入力メタデータに関する適当なメディアブラウザ属性の作成のための規則のリストを使用する。規則は次の通りである。
（ｉ）href属性が、単純リンクのターゲットを表現するために仮定され、xlink:href属性として表現される。リンクのターゲット値が、ＸＭＬの拡張子を有するか拡張子なしのＵＲＩである場合、別の記述へのリンクを仮定し（即ち、xlink:roleに「description」をセットする）、そうでない場合には、リンクが、関連するコンテンツへのリンクであると仮定する（即ち、xlink:roleに「resource」をセットする）。リンクの型は、単純であると仮定する（即ち、xlink:typeに「simple」をセットする）。
（ii）要素は、記述子又はその子のどれかのいずれかにリンクが含まれる場合、ＴＯＣ記述子として分類される（即ち、mb:descriptorTypeに「TOC」をセットする）。リンクは、元のメタデータで、要素コンテンツ又は属性として表現される可能性がある。ＴＯＣ記述子として分類されない要素は、index記述子であると仮定する。
（iii）記述子が、visualIdentifier又はtextIdentiferを有しない場合、記述子のname属性が存在すればその属性から、そうでなければ要素名から得られる値を用いてtextIdentiferを作成する。これに関して、メディアブラウザ１０１は、存在すれば、必ずvisualIdentifierを表示し、そうでなければtextIdentiferを使用することが好ましい。
（iv）記述子に、それがvisualIdentifierとして働くことができる可能性があることを示す名前を有する属性が含まれる場合（例えばkeyFrame, thumbnail, previewなど）、その属性の値を使用してvisualIdentifier属性を作成する。この規則は、各属性名を可能なvisualIdentifier名のリストに対して検査することによって実施することができる。
【００５５】
上述したリストは４つのルールだけであるが、代替のルール又は追加のルールもしくはその両方を開発して、未知のメタデータ型の意味のある解釈を提供することができることを諒解されたい。
【００５６】
しかし、メタデータフォーマットの先見的知識によって、スタイルシート作成者が情報に基づく変換を定義できるようになるので、ＸＳＬＴスタイルシートの使用が望ましい手法である。例えば、visualIdentifier属性の値を別の属性の値から直接得ることもできる。既知の拡張されたDublin Core属性のサブセットに基づく、メディアブラウザによって使用可能な形への任意のビデオメタデータの変換の例を図１５に示す。
【００５７】
図１５では、ソース記述及び変換された記述がＸＭＬ要素ノード木として示され、属性が対応するノードの右の箱に示されている。要素は、楕円形を使用して表される。従って、例えばソース記述１５８０で、VideoDocument要素１５００は５つの属性１５０２即ち、DC.Title, DC.Creator, DC.Subject, DC.Type,及びhrefを有する。表記｛att_name｝を使用して、名前att_nameを有する、ソース文書内の対応する要素の属性の値を表す。avptr表記は、XPointer断片を使用してオーディオビジュアルコンテンツ内にアドレッシングする方法である。例えば、
http://../AusWild883.mpg#avptr(time::2:05.00,2:55.20)
は、オーディオビジュアルコンテンツAusWild883.mpgの断片を参照し、ここで、断片は、コンテンツの先頭から２分５秒の位置から始まり、２分５５．２秒で終わる。
【００５８】
図１５のＸＳＬＴ変換１５２８は、複数の属性１５０２（例えば、DC.Title）を有するビデオ文書要素１５００に関するソース記述１５８０の構文及びセマンティクスの知識を用いて構成される。例えば、図示の変換では、ソースScene要素１５０４、１５０６、及び１５０８の属性の組１５１０のDC.Identifier属性の値と、Shot要素１５１２、１５１４、及び１５１６の属性の組１５１８のDC.Identifier属性が、単に参照識別子であり、追加情報を提供しないと仮定する。このため、この変換では、これらの参照をmb:id属性の値として使用する。これらの識別子がメタデータのユーザに意味を伝える場合、これらの属性を、例えばScene要素のDC.Description属性１５４４として、index記述子に変換することができる。また、図１５では、変換される記述子がソース記述の初期フレーム粒度を維持しないことに留意されたい。言い換えると、正規化された記述１５３０には、ソース記述１５００のようにFrame記述が含まれてはいない。これは、通常、メディアブラウザインターフェース１０１の知識を用いて操作する、スタイルシート１５２８の設計者によって行われた決定を表す。
【００５９】
図１５の例では、要素を使用して構造を表現し、属性を使用してプロパティを表す記述を要素木に変換することが、当初は逆効果に見える可能性がある。しかし、どの情報が属性として表現されるべきか、どの情報が要素として表現されるべきかという概念は、上述したように、しばしば、メディアタイプに伴って変化する。このため、ソースメタデータの要素木への変換は、メタデータの正規化の一形態であり、よって、変換１５２８はメディアブラウザ１０１による処理及び提示が可能な正規化された記述１５９０をもたらす。
【００６０】
ソース記述１５８０は、付録１に記載のＸＭＬ文書である。メディアブラウザ１０１は、関連するスキーマが存在する場合、それらのスキーマの変換を試みない。その結果、変換された記述はスキーマに準拠せず、それゆえ、記述に注釈を付けることができない。これは、変換された記述１５９０のルート要素１５３２でメディアブラウザ１０１のupdateable属性にfalseをセットすることによって、変換された記述内で強調されている。変換１５２８を達成するのに使用されたＸＳＬＴスタイルシートを付録２に示す。
【００６１】
III．メタデータサーバ
メタデータサーバ２１２へのリンクは、ＵＲＩを使用して表現される。要求を記述する表現がメタデータサーバ２１２を一意に識別するＵＲＩに付加される。例えば、ＵＲＩ：http://somesite/myMetadata/Svr?＜query_string＞は、疑問符記号の前のＵＲＩの部分である識別子コンポーネントと、メタデータサーバ２１２に送信される要求に関する情報を運ぶ要求コンポーネントを有する。識別子コンポーネントは、それ自体がＵＲＩである。
【００６２】
好ましい例では、まずＵＲＩの識別子部分を使用して、ネットワーク１０２上でメタデータサーバ２１２を突き止めることによってリンクを解釈する。メタデータサーバ２１２を識別できないと、障害を発生したリンクがもたらされ、メディアブラウザ１０１のユーザに、走行中のプロセスを検出できなかったことについて通知することができる。好ましい例では、メタデータサーバ２１２が、プロセスとして走行中でなければならず、メタデータサーバ２１２によって実行される処理を、メディアブラウザ１０１から開始することはできない。代替例では、メディアブラウザ１０１は１つ又は複数のメタデータサーバプロセスを開始するように構成されても良い。
【００６３】
識別されたメタデータサーバ２１２が要求を受信した時に、サーバ２１２は、要求を解釈し、その要求を満足するＸＭＬ記述を応答する。この記述はＸＭＬとして送信されるのが好ましいが、望まれるか必要な場合には、記述をエンコードすることができる。記述に使用される型及び要素は、メディアブラウザ１０１がアクセスできるスキーマで定義されることが好ましい。記述は、説明される例ではメディアブラウザ１０１によってそれらのスキーマに対して検証されないが、メディアブラウザ１０１は、スキーマにアクセスできることを好む。スキーマが使用可能でない場合には、一部のメディアブラウザ機能が、使用可能でなくなる可能性がある。メタデータサーバ２１２によって使用されるスキーマの型及び要素が上述の節IIで定義したコア属性を使用して導出されることが好ましい。
【００６４】
メタデータサーバ２１２に向けられる要求は、ブラウジング又は検索式に必要なメタデータに関するものとすることができる。要求では、要求元のメディアブラウザサービスへのＸＭＬの配送を制御する様々なパラメータも指定することができる。
【００６５】
メタデータサーバ２１２に向けられた要求の結果は、型MetadataCollection又はそれから導出された型のいずれかである、１要素に含まれることが好ましい記述であり、その例を、以下の例Ｆに示す。MetadataCollection型は、メタデータサーバが、要求元のメディアブラウザアプリケーション又はサービスに情報を明示的に返す手段を提供する（例えば、要求を満足する項目の数及び記述で実際に返される項目の数）。
【００６６】

【００６７】
要求構文の詳細を説明する前に、メディアブラウザ１０１によってメタデータサーバ２１２との間で行われる通信の全体的な処理モデルを、図３のフローチャートを参照して説明する。まずステップ３００で、ＵＲＩからメタデータサーバ２１２を識別する。その後、ステップ３０１で、識別されたメタデータサーバ２１２に要求を送信する。具体的に言うと、好ましい例で行われるのは、メタデータサーバ要求を含むＵＲＩが、ＨＴＴＰを使用して取り出されるということである。言い換えると、ステップ３００及び３０１は、単一の処理として実行される。その後、システムは、ステップ３０２で応答を待つ。ステップ３０３で検査を実行して、応答を受信したかどうかを調べる。そうでない場合には、ステップ３０４で、待ち期間を所定のタイムアウトと比較し、待ち期間がタイムアウトを超えない場合には、制御をステップ３０２に戻す。待ち期間がタイムアウトを超える場合には、ステップ３０６で、メディアブラウザのユーザにエラーを報告し、ステップ３１０で処理を終了する（即ち、メタデータサーバ２１２に、なんらかの理由で到達しなかった）。
【００６８】
ステップ３０３で応答を受信した場合には、メディアブラウザ１０１は応答を検査する。メディアブラウザ１０１が応答を処理できない（例えば、応答が正しく構成されていない）場合には、ステップ３０６でエラーを報告し、ステップ３１０で処理を終了する。応答を処理（即ち解析）できる場合には、更なる処理のためにメディアブラウザ１０１内の適当なモジュールに応答を渡し、ステップ３１０で処理を終了する。
【００６９】
要求の構文を、これから詳細に説明する。
【００７０】
通常、ほとんどのレガシデータベースでは、メタデータを関係データベースに保管し、標準照会言語（ＳＱＬ）を使用してこれらのデータベースにアクセスする。一方で、ＸＭＬ文書、よってメディアブラウザ１０１は、階層的な形で情報（メタデータ）を表現する。メタデータサーバ２１２要求は、この２つの異なる表現の間のブリッジを提供しなければならない。要求がＳＱＬに基づくならば、メタデータサーバの実装が簡単になる可能性があるが、メディアブラウザ１０１はＸＭＬ関連テクノロジを使用する。具体的に言うと、メタデータサーバ要求は、http://www.w3.org/TR/xpathで見つけることができるＷ３Ｃ Recommendation XPath Version 1.0に基づく。新生のＷ３Ｃ標準XQueryを使用することも可能である。
【００７１】
XPathは、処理されるノードのクラスを記述する、非常に理解できる形を提供する。これは、手続的ではなく宣言的であり、ディレクトリ表記にならってモデル化された単純なパターン構文を使用する。XPath表現の最も一般的な形態は、ロケーションパスである。ロケーションパスでは、コンテキストノードに対する相対的なノードの組が選択される。ロケーションパスは、絶対的（ルートノードを表す「／」から始まる）又は相対的（コンテキストノードに対する）とすることができる。例えば、表現book/authorは、コンテキストノードのbook子の全てのauthor子を選択する相対ロケーションパスである。XPath構文は、例によって最も簡単に理解され、複数の例がhttp://www.w3.org/TR/xpathに示されている。複数のXPathの例を以下に示す。
（ｉ）/*によって、ルートノードの全ての子が選択される
（ii）/doc/chapter[5]/section[2]によって、docの５番目のchapterの２番目のsectionが選択される
（iii）*/paraによって、コンテキストノードのpara孫の全てが選択される
（iv）para[@type="warning"]によって、コンテキストノードのpara子のうちで、値がwarningであるtype属性を有するものが全て選択される
（ｖ）chapter[title="Introduction"]によって、コンテキストノードのchapter子のうちで、Introductionに等しい文字列値を有する１つ又は複数のtitle子を有するものが選択される。
【００７２】
XPathのロケーションパス構文は、ブラウジング要求の表現及び構造化照会に直接に使用可能である。非構造化照会（検索式）をメタデータサーバへの要求としてパッケージ化するために、XPathの機能表記を使用する。これは、XPathのより詳細な理解を必要とする。
【００７３】
XPathの主な構文構成要素は、その表現である。表現は、以下の４つの基本型の１つであるオブジェクトを作るために評価される。
・Node-set（重複がないノードの順序なし集合）
・Boolean（真又は偽）
・Number（浮動小数点数値）
・String
ロケーションパスは、上述したように、XPath表現の特殊な場合である。ロケーションパスは、パスによって選択されたノードの組を返す。ロケーションパスのうちで、大括弧「［］」によって囲まれた部分を述部と呼ぶ。述部は、それ自体が、ロケーションステップの定義された軸（選択されたノードとコンテキストノードの間の木関係）に関して選択されたノードセットをフィルタリングするように働くBoolean結果を返すXPath表現である。
【００７４】
表現は、関数呼出しとすることもでき、関数は、任意選択として引数をとる。関数呼出しのEBNF（拡張バッカス正規形式）定義は、http://www.w3.org/TR/xpathにある、上述の参照したＷ３Ｃ RecommendationのSection 3.2からとられる。そのような表現の例を示す。
【００７５】
FunctionCall ::= FunctionName'('(Argument(','Argument)*)?)'
Argument ::= Expr
このプロダクションExprが、XPathの基本構成要素であることに留意されたい。XPath実施形態によって実装されなければならないコア関数ライブラリが存在する。このライブラリの各関数は、戻り型、関数の名前、及び引数の型を与える関数プロトタイプを使用して指定される。非構造化照会を実行するために要求を渡すのに使用することができるコア関数は存在しないが、ユーザ関数を定義することによってXPathを拡張するのは単純である。
【００７６】
従って、要求の構文は、XPathに基づき、メディアブラウザへのメタデータの伝送を制御するパラメータを指定する追加の機能性を有する。その構文を、EBNFを使用して以下に詳細に示す。
【００７７】

Requestには、単一のXPathExpressioneとその後の任意選択のParameterListが含まれる。XPathExpressionは、述部表現が追加の関数呼出し
Functtion: Boolean query(unstructuredQuery)
をサポートしなければならないことを除き、http://www.w3.org/TR/xpathに記載のXPath Version 1.0のプロダクションLocationPathに一致する。
【００７８】
この関数を、ロケーションパスに含めることができ、この関数を使用してメタデータサーバ２１２がデータベース２１０に関連する検索エンジンに非構造化照会を渡すことを要求することができる。例えば、ロケーションパス/Lifestyles/images[query("surfing")]は、それゆえ、メタデータサーバ２１２によって、非構造化照会「surfing」を満足する、Lifestylesノードの子である全てのimagesを見つけることとして解釈される。表現unstructuredQueryはＵＲＩに含むために、適当にエンコードしなければならないことに留意されたい。適当なエンコーディングは、http://www.ietf.org/rfc.htmlから入手可能な、Network Working GroupのRequest for Comments(RFC)2396によって指定される。
【００７９】
上述したNmtoken及びDigitの両方が、XML Version 1.0 Recommendationで定義されている（http://www.w3.org/TR/1998/REC-xml-19980210を参照）。
【００８０】
RequestのParameterListコンポーネントは、任意選択である。ParameterListには、任意選択の個々のプロダクション、MaximumItems、StartItem、NumberLevels、及びTransactionIDが含まれ、これらにより、それぞれmaxItemsパラメータ、startItemパラメータ、noLevelsパラメータ、及びrequestIDパラメータが指定される。これらのパラメータのどれも指定されない場合には、メディアブラウザ１０１はデフォルト値を使用する。
【００８１】
パラメータmaxItemsは、メタデータサーバ２１２によって返される項目の最大個数を指す。従って、例えば、コレクションの特定のセクションに多数の項目が含まれる場合に、メディアブラウザは、まず、例えば（ｎ＝１０１）項目を要求することができる。デフォルト値は、メディアブラウザ１０１内でユーザによって指定される。このパラメータは、メディアブラウザ１０１によって、Requestに自動的に挿入される。ユーザが値を指定しない場合には、システムデフォルトが使用される（例えばmaxItems=100）。
【００８２】
startItemパラメータを用いると、メディアブラウザ１０１は指定された項目番号から始めて、次のｎ項目を得ることができるようになる。startItemパラメータは、メタデータサーバ２１２から検索結果を取り出す際に有用である。これがＵＲＩで指定されない場合には、「１」の値がメタデータサーバ２１２によって仮定される。
【００８３】
パラメータnoLevelsによって、メディアブラウザ１０１は返される記述の構造を定義できるようになる。通常、記述の単一（階層）レベルが要求されるが、複数のレベルの階層を含む特定のビュー（例えばビデオのシーン及びクリップ）をユーザが要求する場合に、より多数のレベルが望ましい場合がある。このパラメータが指定されない場合には、１（階層）レベルの値が仮定される。
【００８４】
requestIDパラメータを用いると、前の要求を参照する要求を式で表せるようになる。例えば、前の要求の結果から項目の次の組を得ることが望ましい場合がある。requestIDが指定された場合には、メタデータサーバ２１２は、requestIDによって識別される前の要求を使用して応答することを試みる。requestIDによって識別される要求が、もはやメタデータサーバ２１２のキャッシュ内で使用可能でない場合には、その要求に関連する処理を繰り返さなければならない。requestIDは、メタデータサーバ２１２に関して一意の値であり、メタデータサーバ２１２によって生成される（メタデータサーバ２１２による要求の受信を表すタイムスタンプに基づくものとすることができる）。requestIDは、型MetadataCollection（例Ｆを参照されたい）又はその型から導出された型を有する要素を使用してメディアブラウザ１０１に返すことができる。
【００８５】
［ブラウジング要求］
一実施形態では、ブラウジングのためのメタデータコレクションへのブラウジングエントリを最初に得る時に使用されるデフォルトRequestを、XPathExpression、「/*」と、ParameterList内でフォーマットされた所望のパラメータ（例えば「/*&maxItems=100&noLevels=2」）とすることができる。対応するＵＲＩは、次のようになる。
【００８６】
http://mySite/myMetadataSvr?/*&maxItems=100&noLevels=2
ここで、//mySite/myMetadataSvrが、メタデータサーバプロセスのＵＲＩである。
【００８７】
この要求を受信した時に、メタデータサーバ２１２が、要求を満足するために手順を呼び出す。この手順は、関連するメタデータコレクションのＸＭＬ記述の動的生成をもたらす。従って、この記述は、関連するメタデータコレクションをそれによってブラウズすることができる構造を反映する。メタデータコレクションを、ある形態のデータベースに保管することが一般的である。例えば、メタデータサーバ２１２を、コレクションのカテゴリ又はパブリッシャセクションを提供するように構成し、その結果、ユーザがより簡単にメタデータをブラウズできるようにすることができる。通常、これらのカテゴリは、データベース項目を記述するのに使用されるスキーマに反映される。その代わりに、メタデータサーバ２１２が、データベース内の別々の項目の全てのリストを単純に送信することにより、メディアブラウザ１０１からの要求に応答することができる。
【００８８】
通常の使用のシナリオを説明するために、次の構造を有する画像メタデータ・データベースを検討する。このデータベースは、図７に示すように、Lifestyles、Sports、及びAnimalsを含む複数のカテゴリからなる。Lifestylesカテゴリは、それ以上の構造を有しない（即ち、画像だけから構成される）が、Sportsカテゴリは、サブカテゴリに更に構造化され、Animalsカテゴリは、更にサブカテゴリに構造化され、その後、画像クラスに構造化される。この説明の目的にとって、このデータが実際にどのように保管されるかは、重要でない。
【００８９】
メタデータサーバ２１２が、そのメタデータコレクションに関するその変換機能を実施できる固定された形はない。１つの可能な形を以下に説明する。
【００９０】
メタデータサーバ２１２は、Category、Subcategory、Class、及びImageの型のＸＭＬスキーマ定義に基づいて記述を生成する。通常、これらのスキーマ定義は、単一のＸＭＬスキーマ文書内に存在する。これらの定義で、メディアブラウザ１０１属性及びグローバルＸＬｉｎｋ属性のコア属性（上述した節IIを参照）を使用することが好ましい。そのような定義の基本的な例を、以下に、ＸＭＬ スキーマの例Ｇに示す。定義で、xlink:show属性を使用して、メディアブラウザ１０１にソース側でリンクのターゲットを「埋め込む」（即ち、メタデータサーバ２１２によって生成される記述断片が、リンクソース要素のコンテンツとして単純に含まれる）ように指示できることに留意されたい。定義では、これらの属性値に「replace」をセットすることもでき、この場合には、メディアブラウザ１０１が、リンクソースである記述子を、メタデータサーバ２１２によって供給された記述断片に置換する。
【００９１】

【００９２】
例Ｇのスキーマ文書には、メディアブラウザ（ｍｂ）名前空間について定義されたMetadataCollection型（例Ｆを参照）を拡張したルート要素、ImageLibraryの宣言が含まれる。従って、これは、基本型について定義された属性の全て（即ち、descriptorType、requestID、noItemsIdentified、noItemsReturned、及びstartItemRuterned）を継承する。更に、ImageLibraryは、記述子のリスト：Category、SubCategory、Class、又はImageのどれをも含むように定義される。このルート要素のコンテンツとしてメタデータサーバによって実際に返されるものは、受信した要求に依存する。
【００９３】
このスキーマ文書には、ＴＯＣ記述子：Category、SubCategory、Class、及びImageの宣言も含まれる。これらの記述子のそれぞれは、属性グループTOCDescriptorAttributes（ｍｂ名前空間から、上記した例Ａで定義される）及びリンキング属性の組（xlink名前空間からのtype、href、role、及びshow）を含むように定義される。
【００９４】
この例では、type属性、show属性、及びrole属性のデフォルトがインスタンス（例えば、要求に応答してメタデータサーバによって生成されるＸＭＬ文書）内で上書きされない限り、「simple」、「new」、及び「resource」になる。従って、例えば、xlink:show属性のデフォルト値は、別のメタデータサーバ要求へのリンクを含めなければならない場合、上書きする必要がある。この場合、通常、この属性の所望の値が「embed」であり、これにより、生成された記述の受信側が、その要素コンテンツ記述を、メタデータサーバへのリンクソースを含む記述子の子要素として埋め込むことを指示される。xlink:show属性の値に「replace」をセットすることも可能であり、これは、生成される記述の要素コンテンツを、メタデータサーバへのオリジナルリンクを含む記述子に置換しなければならないことを意味する。xlink:show属性のデフォルト値は、リソースへのリンクが実在的である場合に使用することができる。この場合は、ユーザはそのリソースを新しいウィンドウに表示することを望む（従って、デフォルト値に単語「new」が使用される）。
【００９５】
また、生成される記述は、リンクの目的が別の記述にリンクすることである場合に、xlink:role属性の値を上書きする必要がある。この場合、この属性の値に、「description」をセットしなければならない。
【００９６】
例Ｇの宣言された記述子のそれぞれが、visualIdentifier属性を継承する（TOCDescriptorAttributesグループ又はIndexDescriptorAttributesグループのいずれかから）。この属性は、メディアブラウザ１０１によって、項目のコンテンツの視覚的表現を提供するのに使用される。例えば、項目が画像である場合に、visualIdentifier属性値に、通常、画像のサムネイルのＵＲＩが含まれる。カテゴリ、サブカテゴリ、及びクラスの場合には、visualIdentifier属性値に、アイコンのＵＲＩを含めることができる。この属性が指定されない場合には、メディアブラウザ１０１が、供給されたtextIdentifier属性値から、又は、この値も供給されない場合には、要素の名前から（この場合、Image、Class、Subcategory、又はCategory）、その項目の視覚的識別子を生成することが好ましい。
【００９７】
「/*」Requestの受信時に、メタデータサーバ２１２は、以下の例ＨのＸＭＬ断片のように、コレクションのＸＭＬ記述を生成する。この記述は、型MetadataCollection（例Ｇを参照）になるように宣言された要素に含まれ、この記述には、次の記述のためにメタデータサーバに戻るリンクが含まれる。メタデータサーバが、この戻りリンクでXPathExpressionを指定するだけでよいことに留意されたい。要求をディスパッチする前に、ＵＲＩにParameterListを追加するのは、メディアブラウザの責任である。
【００９８】

【００９９】
上記の例Ｈでは、メタデータサーバ２１２への戻りリンクの記述XPathExpressionsを使用して、Lifestylesカテゴリ内と、Sportsカテゴリ及びAnimalsカテゴリのサブカテゴリ内の画像のそれぞれへのリンクを識別する。これらのリンクは、上記の項目がメディアブラウザ１０１で視覚的に提示された時にユーザが上記の項目の１つを展開することを選択した時に、活動化される。前の説明及びこの後の説明では、コンテキストノードがコレクションのルートノードであると仮定して、XPathExpressionsが、相対ロケーションパスとして指定されている。その代わりに、絶対パスを使用することができる。
【０１００】
上の例Ｈでは、メタデータサーバ２１２への戻りリンクのＵＲＩターゲットに、「［」文字及び「］」文字が含まれる。一般に、ＲＦＣ ２３９６によれば、これらの文字は、一部のゲートウェイ及びトランスポートエージェントによって排除される可能性があるので、これらの文字をＵＲＩ内でエンコードされないままにすることは賢明ではない。これらの文字は、読みやすくするために、この例及び以下の例でエンコードされないままにされている。
【０１０１】
例えば、例Ｈに示されたＸＭＬ断片が処理され、ユーザに提示された時に、「Sports」カテゴリの視覚的識別子が選択された場合に、メタデータサーバへの対応する戻りリンクが発動される。メタデータサーバ２１２は、以下の例Ｉに示される記述断片を生成し、返すことにより、このリンクに応答する。
【０１０２】

【０１０３】
返される記述が、適切に形成されることが好ましい。更に、返される記述は、メディアブラウザ１０１によって解析可能でなければならない。リンクのコンテンツを受信した時のメディアブラウザ１０１のアクションは、前に説明したxlink属性showに依存する。通常、この属性には「embed」がセットされ、その場合には、受信した記述がリンクのソースで埋め込まれる。受信した記述で、コンテナ要素（例えば例Ｆで定義された型MetadataCollectionの）が使用される場合には、この要素も埋め込まれる。埋め込まれたコンテナ要素は、「Other」のdescriptorType値（例Ａを参照）を有するものとして定義されることが好ましい。その代わりに、前に述べたように、xlink:show属性に、「replace」をセットすることができ、この場合には、リンクのコンテンツがリンクソースを含む要素に置換される。xlink:show属性がメタデータサーバによって生成された記述内のリンク要素に関して含まれない場合には、デフォルトのアクションは「new」である。これは、リンクのコンテンツが、新しいウィンドウに表示されることを意味する。明らかに、これは、記述よりもコンテンツ（即ちリソース）について望ましい振る舞いである。
【０１０４】
コレクションの記述を、さらに、ユーザがこれらのサブカテゴリの１つを選択することによって利用することができる。このアクションの結果、メタデータサーバ２１２が、選択されたサブカテゴリに含まれる画像の記述を生成する。
【０１０５】
例Ｉの記述は、メタデータサーバ２１２によって動的に生成されるが、この記述に、単一の階層レベルだけが含まれることに留意されたい。これは、ＵＲＩのParameterListでnoLevelsパラメータを指定することによって変更することができる。場合によっては、Requestで、親と子の両方のＴＯＣ要素を必要とするビューを生成するために、２レベルの階層記述が要求される場合がある。例えば、メディアブラウザ１０１が２レベルのビューを使用しており、２レベルのＴＯＣ階層を含む記述を取り出すことを望む場合、メディアブラウザ１０１は、ＵＲＩに「nolevels=2」パラメータを付加する。例えば、リンク

は、下の例Ｊに示された記述断片をもたらす。
【０１０６】
第２レベルは、リンクのターゲットであるレベルのＴＯＣ子であると仮定される。noLevelsの値が１を超える時に、パラメータmaxItems及びstartItemの値が記述の最下位ＴＯＣレベルを参照しなければならないことが好ましい。同様に、返されるパラメータの値も、記述の最下位レベルを参照する。また、最下位ＴＯＣレベルのIndex記述子の子も、以下の例Ｊに示された返されるＸＭＬに含めることができることに留意されたい。
【０１０７】

【０１０８】
［検索要求］
検索要求は、高度検索オプションを使用して構造化照会を指定するユーザ、又は単純検索オプションを使用して非構造化照会を指定するユーザのいずれかから発する可能性がある。用語「構造化」照会は、本明細書では、情報ソースの既知のプロパティの用語に関して表現される制約の組からなる照会を意味するのに使用される。これらの制約は、結合的（論理積）な形又は離接的（論理和）な形もしくはこの２つの混合で組み合わせることができる。用語「非構造化」照会は、本明細書では、結合の有無を問わず、キーワード及び式のリストからなる照会を意味するのに使用される（例えば、Yahoo!（登録商標）、AltaVista（登録商標）などのほとんどの検索エンジンによって使用されるタイプの照会）。この２つの照会タイプの間の主要な相違は、構造化照会が、情報ソースの知識（例えば、メタデータデータベースのスキーマ）を用いて式で表されることである。
【０１０９】
構造化照会が形成される場合には、この照会は、XPathExpressionを使用して表現され、制約が前の節でブラウジングに関して説明したように、ロケーションステップの述部として表現されることが好ましい。従って、非構造化照会だけを、この節で検討する必要がある。
【０１１０】
現在存在するほとんどのメタデータコレクションは、非構造化検索関数を有する。多くの場合に、かなりの労力が、この検索関数を、速度及び適切な結果に関してできる限り最適にするために費やされてきた。その結果、非構造化照会がユーザによって指定される時には、必ず、これらの検索機能を使用することが有利である。
【０１１１】
非構造化照会を、前にこの節で定義した照会関数呼出しを使用して、メタデータサーバ２１２に渡すことができる。この関数呼出しは、ロケーションパスのステップの述部内に含まれることが好ましい。ロケーションパスに、そのロケーションステップのそれぞれの述部を含めることができるので、XPathExpressionに、複数の非構造化照会式を含めることができる。しかし、非構造化照会に基づく要求のほとんどに、単一の照会式が含まれる。例えば、XPathExpressionである//image[query("dog OR cat")]によって、ルートノードの子孫であり、照会「dog OR cat」を満足する全てのimage項目が選択される。XPathExpressionは、ＵＲＩの一部としてディスパッチされる前に、適当にエンコードされる必要があることに留意されたい（ＲＦＣ ２３９６を参照）。例えば、空白文字は、文字３つ組％２０を使用してエンコードしなければならない。
【０１１２】
通常、検索は、多数の項目をもたらす可能性がある。メディアブラウザ１０１に返される記述は、記述に含まれる項目の数に関して、maxItemsパラメータを使用することによって制限することができる。結果の第１の組を受け取った後に、メディアブラウザ１０１は、startItemパラメータを使用することによって、次の組を要求することができる。これを行うために、メディアブラウザ１０１は、元の要求に対する応答と共にメタデータサーバ２１２が返したrequestIDを含める。言い換えると、返されるrequestIDにより、後の要求によってアクセスできるトランザクションの開始が識別される。
【０１１３】
以上は、メタデータサーバ２１２の構成に関する複数の言外の意味を有する。というのは、そのような要求が、メタデータサーバ２１２が前の要求の結果を保存でき、アクセスできることを必要とするからである。しかし、伝統的なサーバ例では、キャッシュ内に要求の結果を無期限に維持することができない。前の要求を参照する要求が到着した場合に、メタデータサーバ２１２が、requestIDをそのキャッシュに記憶された要求結果と照合することを試みることが好ましい。要求がもはやキャッシュ内にない場合には、それを再処理する。代替の例では、一致を達成できない場合に、メタデータサーバ２１２が、任意選択として、要求の再処理を行う前に、テキスト的類似性に基づいてその要求を他の要求と突き合わせることを試みることができる。この手法は、メタデータサーバ２１２による大きく重複した処理を除去できるという点で役立つ。従って、メタデータサーバ２１２のキャッシュのサイズは、実装依存とすることができる。
【０１１４】
IV．メディアブラウザアプリケーション
メディアブラウザ１０１は、ユーザに、異なるメタデータコレクションをブラウズし、検索するための単一のユーザインターフェースを提供する。メディアブラウザ１０１の例のグラフィカルユーザインターフェース４００を、図４に示す。メディアブラウザインターフェース４００は、ユーザにコンテンツ（の項目）に関連するメタデータを介するコンテンツ（の特定の項目）のブラウズ又は検索のいずれかのオプションを与える。メディアブラウザ１０１は、独立型アプリケーションとして（例えば、米国のMivrosoft Corporation社によって製造されるＷｏｒｄ９７など）又は複数同時ユーザに供給することができるサービスとして、実施することができる。好ましい例では、メディアブラウザ１０１がサービスとして実施される。このモードでは、各ユーザが、彼らのパーソナライズされたＴＯＣにアクセスするために、サービスにログインすることを要求される。メディアブラウザ１０１のサービス態様を、以下の節Ｖで更に説明する。この節は、メディアブラウザ１０１の機能性の説明に当てられる。この説明では、メディアブラウザサービスを仮定するが、その機能性を、独立型プログラムとして同等によく実施できることは明白である。
【０１１５】
通常、メディアブラウザ１０１は、デフォルトのメディアツールプラグインの組と共に実施される。メディアブラウザ１０１のユーザは、彼ら自身の実装にプラグインされる更なるメディアツールを選択でき、好ましくはインターネットを介してダウンロードすることができる。各プラグインは、ターゲットメディアタイプの定義された組を有する。メタデータのブラウズ及び検索からメディア再生／表示を分離することが、メディアブラウザ１０１の重要な概念である。というのは、これによって、アプリケーションを特定のユーザ／環境に適合できるようになるからである。
【０１１６】
メディアブラウザ１０１は、ユーザがアクセスを選択した情報ランドスケープの構造を表すTable of Contents（ＴＯＣ）を供給することにより、メタデータへのブラウジングアクセスを可能にする。この情報ランドスケープには、ローカルメタデータへのリンク又はリモートメタデータへのリンクもしくはその両方を含めることができ、情報ランドスケープは、通常、ユーザが個人的な興味に関係するメタデータサイトを発見した時に、各ユーザによってカスタマイズされる。デフォルトＴＯＣが、新しいユーザのそれぞれに提供されることが好ましい。
【０１１７】
基礎となる情報ランドスケープは、全てのレベルで記述（即ちＸＭＬ文書）として表される。これは、ＸＭＬの場合にはノード及びリンクを含む木である記述の基本構造が、ユーザがＴＯＣのエントリポイントを表示しているかコンテンツ（例えばディジタルビデオ）のマルチメディア項目の記述の詳細を表示しているかにかかわらず、同一であることを意味する。ＴＯＣは、情報ランドスケープの視覚的表現なので、ユーザのＴＯＣ内のナビゲーションは、ＴＯＣの全てのレベルについて変更されない。これは、インターフェース４００が、ユーザが異なるウェブサイトのメタデータをブラウズしているか、メタデータコレクションの異なるセクション（例えば画像メタデータコレクションのカテゴリ）のメタデータをブラウズしているか、マルチメディアコンテンツ（例えばディジタルビデオテープ内のクリップ）の記述内のメタデータをブラウズしているかにかかわらず、同一であることを意味する。
【０１１８】
ＴＯＣは、選択可能である項目によって形成される。これらの項目には、ＴＯＣ記述子の視覚的表現が含まれる（メタデータ表現の詳細については、節IIを参照されたい）。項目には、ブラウジングの際にユーザを助けるための視覚的識別子が含まれる。通常、視覚的識別子は、ある形でコンテンツを表している。これは、マルチメディアコンテンツの項目に対応する視覚的識別子の場合に特にそうである。視覚的識別子の例には、単純なテキスト、グラフィカルにデザインされたテキスト、画像のサムネイル、アニメーション、及びビデオの短いプレビューが含まれる。これらの視覚的識別子が、記述によって供給されることが好ましいが、そうでない場合には、メディアブラウザ１０１が、記述に含まれる情報（例えばtextIdentifier属性又は要素名）からこれらをグラフィカルに生成することができる。視覚的識別子は、節II及び節IIIで詳細に説明した。
【０１１９】
好ましい例で提供されるブラウジング機能性を、これから図５を参照して説明する。メディアブラウザ１０１を活動化する時に、情報ランドスケープの最初の記述がステップ５００で読み取られる。この最初の記述には、通常、異なるメタデータコレクション又はメタデータコレクションのセクションへのトップレベルリンクの組が含まれる。メディアブラウザ１０１は、その後、ステップ５０１で、この記述を処理し、記述から最初のＴＯＣを構築する。通常、記述の処理には、記述を含むＸＭＬ文書の解析と、コンピュータメモリ内のオブジェクトモデルを使用する記述の提示が含まれる。ステップ５０１に、記述から全てのＴＯＣ記述子を検出し、これらの記述子からＴＯＣを作成することが含まれることが好ましい。ＴＯＣ記述子とindex記述子との区別が、節IIで説明したコアdescriptorType属性を使用して実行されることが好ましい。
【０１２０】
次のステップ５０２で、最初のＴＯＣのビューを生成し、ユーザに提示する。このビューは、Mivrosoft Corporation社が製造するWINDOWS EXPLORERなどのアプリケーションによって使用される木構造の形で提供することができる。図４に示された長方形のパネル４０２を設けて、情報ランドスケープの最初のレベルの項目に対応する視覚的識別子４０４を示すことが好ましい。例えば、これは、複数の最初のメタデータコレクションを識別する視覚的識別子の格子とすることができる。
【０１２１】
メディアブラウザ１０１は、その後、ユーザイベントを待つ。ステップ５０３で、ユーザが、例えば視覚的識別子４０４をクリックすることによって、項目を選択する時に、ステップ５０４で、対応する記述子を検査して、それが子ＴＯＣ記述子を有するかどうかを判定する。これは、個々の記述に複数レベルの構造が含まれる場合である可能性がある（例えば、コレクションの記述に、しばしば、１つの記述内の複数のＴＯＣレベルが含まれる場合がある）。項目が子ＴＯＣ項目を有する場合には、制御がステップ５１０に進み、子項目を用いてＴＯＣのビューを更新する。
【０１２２】
選択された項目が、子ＴＯＣ項目を有しない場合には、ステップ５０５で、メディアブラウザ１０１が、項目に記述へのリンクが含まれるかどうかを判定する。これは、リンクのソースを表すリンキング要素が「rescription」の指定されたrole（リンキング要素のroleは前に説明した）を有する場合に、明示的に達成することができる。リンクのroleが定義されていない場合には、メディアブラウザ１０１は、リンクターゲットのＵＲＩのファイル拡張子に基づいてターゲットが更なる記述であるかどうかを判定する。例えば、拡張子が「.xml」である場合には、記述がまず仮定される。しかし、「.xml」ファイルを解析する際に、そのファイルが、指定された記述スキーマに従わないことがわかった場合には、メディアブラウザ１０１は「.xml」ファイルを記述ではなくリソースとして扱うことが好ましい。
【０１２３】
選択された項目に、更なる記述へのリンクが含まれる場合には、ステップ５０６が実施され、このステップで、メディアブラウザ１０１は、指定された記述が記述キャッシュ内で使用可能である（即ち、おそらくは別のユーザのために又は現在のユーザとの前のセッションのために、記述が前に取り出された）かどうかを判定する。記述が使用可能でない場合には、ステップ５０７で、メディアブラウザ１０１は、その記述を取り出す。これは、ＨＴＴＰのget要求を標準ウェブブラウザに転送することによって達成することができる。ステップ５０８で、返された記述を処理し、記述キャッシュに保管する。ステップ５０９で、最初のＴＯＣを作成する際に使用されたものと同一の原理を使用して、新しい記述を反映するようにＴＯＣを更新する。最後に、ステップ５１０で、ＴＯＣのビューも更新し、更なる対話のためにユーザに提示する。ステップ５１０の後に、制御は、ステップ５０３に戻り、ＴＯＣからのさらなる選択を行うことができる。
【０１２４】
前の段落で説明したブラウジングイベントは、情報ランドスケープの新しいレベルの項目を含むようにビューイングパネルが更新されることをもたらすことが好ましい。例えば、この新しいレベルで、特定のメタデータコレクションの主要なカテゴリを示すことができる。
【０１２５】
ステップ５０５で、選択された項目に更なる記述へのリンクが含まれない場合には、そのリンクをコンテンツの項目へのリンクとして扱う。ステップ５２０で、項目の視覚的識別子を強調表示し、ステップ５２１で、更なるアクションを行うことができる。例えば、識別子を複数の他の項目と共に選択し、インターフェース４００の一部を形成するスタック４０６又は買い物かご４０８にドラッグすることができる。コンテンツの項目へのリンクが、ユーザによってダブルクリックされる場合には、その項目を選択された項目のコンテンツタイプ用のデフォルトメディアツールを使用して、即座に提示するか、再生する。
【０１２６】
メディアブラウザ１０１の好ましい実施形態では、２種類の検索が可能である。単純検索は、ユーザが検索入力ボックス４１０にテキスト照会を供給し、単純検索機能４１２を選択することによって構築される。ユーザは、高度検索４１４を選択することにより、使用可能なindex記述子のリストを使用する高度な構造化照会を構築することもできる。後者のオプションが可能であるのは、メディアブラウザ１０１が異なる記述に使用されるスキーマの知識を有するからである。メディアブラウザ１０１は、１つ又は複数の選択された記述子に関連するindex記述子のリストを構築でき、ユーザが選択されたindex記述子の必要な値を入力することによって照会の制約を指定できることが好ましい。そのようにユーザによって入力される制約が、結合的（「論理積」風）に結合されることが好ましいが、明らかに他の代替案（離散的組み合わせ又はこの２つの混合）も可能である。ユーザは、制約の種類（例えば、等しい、未満、超える、含む、不等）を指定することもできなければならない。例えば、ユーザが、発行者「ＡＢＣ」によって発行され、１００ドルから２００ドルの範囲のコストを有する画像について画像データベースを検索したい場合に、ユーザがテキスト照会でキーワードを使用するだけよりも、使用可能な記述子から直接に構造化照会を構築できる場合の方が、照会が成功する可能性が高い。後者の手法は、上で述べた単純検索機能に対応するが、画像記述のどこにでも配置される文字列「ＡＢＣ」、「１００ドル」、及び「２００ドル」をもたらす可能性がある。構造化検索照会の処理は、以下で更に説明する。
【０１２７】
メディアブラウザの好ましい例の検索機能性を、これから図６を参照して説明する。最初のステップ６００で、ユーザが、検索に関する１つ又は複数のコンテキスト項目を指定する。これらは、ステップ６０３で検索が開始される時に検索される、ＴＯＣ内の項目である。ステップ６０１で、ユーザが高度検索を選択したかどうかを判定する。ユーザが、高度検索の実行を選択しない場合には、制御はステップ６０２に移り、ここで、ユーザが、上述したテキスト照会を指定するように要求される。この照会は、ユーザが関心を持っているキーワード又は句のリストからのものとすることができる。
【０１２８】
ユーザが高度検索の実行を選択した場合には、制御はステップ６０１からステップ６２０に移る。使用可能なindex記述子のリストが、コンテキスト項目のリストに含まれる記述のいずれかに関係するスキーマ定義及び宣言から生成される。好ましい実施形態では、index記述子が上述の節IIで述べた、descriptorType属性によってＴＯＣ記述子から区別される。ユーザは、ステップ６２１で、使用可能な記述子のリスト及び基本的な検索結合演算子（例えばＡＮＤ、ＯＲ、及びＮＯＴ）の組に基づいて構造化照会を表現することができる。ユーザは、特定のindex記述子に対する許容可能な範囲を表現し（例えば、項目の価格が１００ドルを超えて２００ドル未満でなければならない）、制約のタイプを示す（例えば等しい又は含む）ことができる。
【０１２９】
ステップ６０３で、ユーザが、現在の照会（テキスト又は構造化）を用いる検索を開始する。この後に、ステップ６０４で、コンテキスト項目のリストの最初の項目が識別される。ステップ６０５で、新しいスレッド又はプロセスが作成され、その後、コンテキスト項目について開始される。その次のステップ６０６で、検査を行って、識別されたコンテキスト項目が、関連するメタデータサーバを有するかどうかを調べる。コンテキスト項目が特定のメタデータコレクションに関する原点又はルートである場合には、ステップ６０６に、記述内のリンクの検査が含まれる。識別されたコンテキスト項目が、原点又はルート項目でない場合には、ＴＯＣを検査して、識別された項目の親についてメタデータサーバが存在するかどうかを確立する必要がある。そのような検査が、識別された項目に関する関連するメタデータサーバの位置をもたらす場合には、メタデータコレクション内の識別された項目のコンテキストを、照会を要求としてメタデータサーバに運ぶXPathExpressionのロケーションパスに含める。例えば、検索について選択されたコンテキスト項目が「Image Collection ABC」内の「Lifestyleカテゴリ」である場合には、次のようなＵＲＩで、検索要求がメタデータサーバに渡される。
【０１３０】

ここで、＜expression＞に、非構造化照会が含まれる。
【０１３１】
ステップ６０６で、関連するメタデータサーバが識別される場合には、ステップ６０８で、照会をＵＲＩとして（節IIIで説明した要求構文を使用して）表現し、識別されたメタデータサーバに送信する。
【０１３２】
ステップ６０６で、メタデータサーバが識別されない場合には、ステップ６０４で識別されたコンテキスト項目内の要求を満足する項目について検索を開始し、制御をステップ６０９に移して、更なるコンテキスト項目を検出する。更なる項目が存在する場合には、ステップ６１０で、コンテキスト項目のリスト内の次の項目を識別し、制御をステップ６０５に戻す。ステップ６０９で、識別すべきコンテキスト項目がもうないことがわかった場合には、制御をステップ６２０に移して、検索プロセスは、検索結果が到着するのを待つ。これに関して、個々のコンテキスト項目に対する多数の検索プロセスが動作し、実質的に同時に結果を返す可能性があることを諒解されたい。全てのスレッド又はプロセスが完了した時に、ステップ６２５で、個々の検索プロセスの結果を照合し、ステップ６３０で処理を終了する。代替実施形態では、全てのスレッドが完了する前に、結果の照合及び表示を開始することができる。
【０１３３】
好ましい実施形態では、ユーザの照会（構造化又は非構造化）が、選択されたコンテキストのそれぞれに無変更で渡される。代替実施形態では、コンテキストのそれぞれに転送される有効な照会を、システムによって変更し、コンテキストの能力を考慮に入れることができる。
【０１３４】
ユーザは、メディアブラウザ１０１のブラウジング及び検索の機能性を使用して関心があるマルチメディアコンテンツを突き止めることができる。ユーザは、項目の視覚的識別子を図４に示されたスタック４０６にドラッグすることにより、項目の一時的コレクションを構築することができる。スタック４０６は、任意選択として保存し、後のセッションで再呼出しすることができる、メタデータ参照のコレクションを表す。スタック４０６は、ビューイングウィンドウに表示することができ、検索に関するコンテキスト項目として選択することができるという点で、情報ランドスケープの他のレベルと同様に扱われる。スタック４０６は、エントリＴＯＣの「Stacks」見出しの下で情報ランドスケープに挿入することもできる。ユーザは、スタック４０６の内容を保存し、その後、後のセッションで、保存されたスタック４０６を取り出し、使用することができる。
【０１３５】
コンテンツが、即座に所望され、オンライン購入が使用可能である場合には、ユーザはその項目を買い物かご４０８にドラッグすることができる。買い物かご４０８は、効果的に特殊化されたスタックである。代替インターフェースでは、買い物かご４０８をそのようなものとして単純に表現することができる。いつでも、ユーザは買い物かごを右クリックして、「購入」プラグインメディアツールを開始することができる。その代わりに、ユーザはマウスを買い物かごアイコンの上に移動して、使用可能なメディアツールのメニューを表示し、このメニューから選択を行うこともできる。
【０１３６】
「購入」プラグインは、既に説明した、メディア表示機能及びメディア再生機能を提供するメディアツールと同一の形で動作する。ユーザは、その実施形態の適当な「購入」ツールを選択することができる。購入ツールは、単純に、買い物かご４０８内の項目のそれぞれを調べ、それらの項目をオンラインで購入できるかどうかを確立し、そうである場合には、ユーザをコンテンツプロバイダ／ディストリビュータのサイトにリダイレクトして、項目を購入する。代替構成では、ユーザはメディアブラウザサービスに関するアカウントを確立することができ、これらのアカウントを介して項目を購入するために、メディアブラウザサービスを、節Ｖで更に説明する。
【０１３７】
Ｖ．メディアブラウザビジネスシステム
節IVで説明したメディアブラウザ１０１は、サービスとして実装することができる。好ましい実施形態では、メディアブラウザ１０１は技術的にはクライアント−サーバアプリケーションとして実装され、ユーザがインターネットからログインできるサービスとして動作する。各ユーザは、好ましくはパスワードによってセキュアに識別され、サービスに関して、指定された限界までのデータを保管することができる。このユーザデータは、最初のＴＯＣ記述、ユーザプリファレンス、保管されたスタック、及びクライアント動作に必要な他の情報（例えばユーザプリファレンス、ローカルにインストールされたプラグインに関する情報など）からなる。このサービスが、周期的（例えば毎月）な購読料に対してユーザに提供されることが好ましい。
【０１３８】
上述したように、サービスとしてメディアブラウザ１０１を動作させることの主な技術的長所の１つは記述をキャッシュ記憶できることである。従って、例えば、会社「ＡＢＣ」がメディアブラウザサービスをインストールし、会社「ＡＢＣ」の多数のユーザが特定のメタデータコレクションを使用する場合、このコレクションからの記述がサービスの記述キャッシュ内で使用可能になる。言い換えると、記述を、個々のユーザのそれぞれのために取り出す必要がない。これは、主要な長所を表す。
【０１３９】
好ましい実施形態では、メディアブラウザサービスが標準ウェブサーバにリンクしたサービスとして動作する。従って、メディアブラウザクライアントを標準ウェブブラウザを使用して実装することができる。これは、ユーザが単純にメディアブラウザホームページに行って、ユーザ自身のコンピュータワークステーションでクライアントを始動できることを意味する。サーバは、通常、ほとんどのウェブサイトの標準ウェブサーバと同様に、継続的に動作する。
【０１４０】
好ましい実施形態のモデルでは、デフォルト・メディアブラウザサーバが、主サービスプロバイダ（例えば、テクノロジの知的所有権に対する権利を所有する会社）のサイトから運営される。他の当事者は、彼ら自身のイントラネット上で彼ら自身のメディアブラウザサービスをインストールするために、その権利を購入することができる。そのような選択肢は、自分のイントラネットのユーザのためにサービスの速度を最適化することを望んでいる当事者にとって望ましい可能性がある。
【０１４１】
上述した開示の更なる長所は、メタデータサーバ２１２の概念を中心とするビジネスシステムにある。節IIIで説明したように、メタデータサーバ２１２は、コンテンツプロバイダ／ディストリビュータが、ＳＱＬデータベースなどのレガシシステムに保管されたメタデータをそれによって使用可能にすることができる手段を提供する。従って、コンテンツプロバイダ／ディストリビュータがメタデータコレクションをサービスするメタデータサーバ２１２を有する能力により、効果的に顧客ベースが開かれる。というのは、潜在的な顧客が、潜在的に多数のサイトから彼らのメタデータにアクセスできるからである。実際、各メディアブラウザクライアントは、潜在的に、コンテンツプロバイダ／ディストリビュータのメタデータコレクションへのアクセスを提供することができる。これにより、売上及び露出の増大という利益がもたらされる。
【０１４２】
しかし、インターネット公衆に彼らの商品／コンテンツを紹介することを望む全てのウェブサイトと同様に、潜在的な顧客は、コンテンツプロバイダ／ディストリビュータのメタデータサーバ２１２の存在に関して知る必要がある。これが発生することを可能にするために、コンテンツプロバイダ／ディストリビュータが、メディアブラウザ／メタデータサーバシステム１００にかかわると決定した時に、コンテンツプロバイダ／ディストリビュータは、主メディアブラウザサービスプロバイダからサンプルの（カスタマイズ可能な）メタデータサーバをダウンロードする。これを用いて、コンテンツプロバイダは、一般的なプラットホームから、コンテンツプロバイダのレガシデータベースにアクセスするために対応するデータベースマネージャによって使用されるデータベースフォーマットへＸＭＬスキーマフォーマットをインターフェースするための特定のトランスレータを組み込んだプラットホームへ、サンプルメタデータサーバを修正することができる。サンプルメタデータサーバを構成する際の、コンテンツプロバイダにとってのオプションの１つが、彼らの新たに「カスタマイズされた」メタデータサーバを、全てのメディアブラウザサービスを用いて配布されるデフォルトＴＯＣエントリ上のリンクとして含ませることを選択することである。これは、新しいメタデータサーバへのリンクが、主メディアブラウザサービスプロバイダのデフォルトサービスに現れ、メディアブラウザソフトウェアを用いて副サービスのそれぞれに配布されることを意味する。これによって、コンテンツプロバイダの商品の直接広告がもたらされる。明らかに、ユーザは、メディアブラウザサービスを扱い始める時に、彼ら自身のＴＯＣをカスタマイズすることができる。しかし、エントリＴＯＣ上のリンクの最初の存在によって、ユーザに、新たにリンクされたメタデータサーバを介して可視にされるメタデータコレクションが紹介される。
【０１４３】
彼らのメタデータサーバへのリンクを標準ＴＯＣに含ませることを選択する際に、コンテンツプロバイダ／ディストリビュータは、彼らのメタデータサーバが処理する要求のそれぞれの量について特定の料金を請求されることに合意する場合がある。この料金は、通常、非常に安くすることができる（例えば、１００００要求ごとに１米ドル）。インストールされたメタデータサーバが、要求の数の記録を保持し、その後、周期的にサービスに関してコンテンツプロバイダ／ディストリビュータに請求する責任を負う、統合された請求機構を有することが好ましい。請求されるクレジットカード番号は、メタデータサーバ内に保護された形で保管することができ、請求は、自動化された電子的な形で実行される。
【０１４４】
要約すると、主メディアブラウザサービスによるメタデータサーバの提供によって、コンテンツプロバイダ／ディストリビュータがマルチメディアコンテンツを宣伝し、販売するための機能強化されたサービス及び機構を提供できるようになる。メタデータサーバの実施により、効果的に、コンテンツプロバイダ／ディストリビュータのメタデータコレクションがコンテンツプロバイダ／ディストリビュータによって運営される検索エンジンを単に訪問することに慣れた聴衆より幅広い聴衆に「開かれる」。更に、メタデータブラウザ／サーバシステムにより、メタデータのブラウズ／検索が潜在的な顧客にとってより魅力的になる。これは、顧客が、より便利（即ち、単一インターフェース）、かつ時間効率の良い（即ち、他のメタデータコレクションと並列に）形でこれらのアクションを実行できるからである。
【０１４５】
メディアブラウザサービスを使用して彼らのオープンメタデータコレクションを効果的に宣伝するという次のステップを行うことにより、潜在的な顧客ベースが更に広がる。この主要な追加の長所に関して、コンテンツプロバイダ／ディストリビュータは、請求期間中に彼らのメタデータサーバが処理する要求の数に基づいて、わずかな定期的な料金を支払うことを約束する。ごく少数の要求が処理される場合には、コンテンツプロバイダ／ディストリビュータに請求されるコストが低い。これは、特により小さいコンテンツプロバイダにとって、重要な長所である。
【０１４６】
図１０に、ローカルサーバ１５０に、上述したメディアブラウザサーバ１５２が組み込まれ、ローカルサーバ１５０に接続された複数のローカルユーザ１５４〜１５６による使用に利用可能である、実施形態を示す。ローカルサーバ１５０は、ユーザ１５４〜１５６と複数のコンテンツプロバイダ１６０及び１７０並びに金融施設１８０の間の、インターネット１０２を介する接続を提供する。プロバイダ１６０及び１７０には、それぞれ、コンテンツのレガシデータベース１６４及び対応するストア１６６が組み込まれる。通常、データベース１６４には、コンテンツへの参照をストア１６６内のコンテンツの位置にマッピングするテーブルの配列が含まれる。メタデータサーバ１６２も設けられ、ＨＴＴＰに従ってＵＲＩとして送信されるメディアブラウザ要求を受信し、メディアブラウザ要求を満足するＸＭＬ記述を生成するように構成される。この構成で、メディアブラウザサービス１５２にアクセスできるローカルユーザ１５４〜１５６は、レガシデータベース１６４に固有又はそれに関連する呼出し、コマンド又は命令の特定の知識を有することなく又はそれらを使用することなく、コンテンツにリモートアクセスできる。このような構成で、コンテンツ１６６へのユーザ１５４のアクセスを、データベース１６４の性質（例えば、データベースがＳＱＬ又はｄＢａｓｅのどちらを使用して形成されるか）に対して透過的な形で行うことができ、それと同時に、データベース１６４の構造、編成、及び検索の属性及び機能を保つことができる。
【０１４７】
ＴＯＣ１５８にリストされた複数のコンテンツプロバイダに跨がるコンテンツの検索を実行する時に、ローカルユーザ１５４に、例えばプロバイダ１６０及び１７０のそれぞれに関する積極的な返答を与えることができる。この段階で、ローカルサーバ１５０の所有者が、各プロバイダ１６０及び１７０のコンテンツへのローカルユーザ１５０のアクセスを「紹介」又は促進することに関する料金に関して、プロバイダ１６０及び１７０のそれぞれに送り状を送ることができる。口語的に言えば、これは「見張り料」と見なすことができ、結果を配送する検索の数、又は検索によって配送された結果の数、或いは単純にメタデータサーバが処理する要求の数に基づくなどの複数の形で請求することができる。
【０１４８】
ローカルユーザ１５４がプロバイダ１６０によって返されるコンテンツの購入を望む場合、金融トランザクションをローカルユーザ１５４とプロバイダ１６０の間で、おそらくは金融機関１８０を介してローカルサーバ１５０に影響せず、ローカルサーバ１５０によって影響されずに、実行することができる。代替手法では、ローカルサーバ１５０を金融仲介者として間に挟むことができ、これにより、プロバイダ１６０がコンテンツの購入についてローカルサーバ１５０に請求し、ローカルサーバ１５０がローカルユーザ１５４に請求する。そのような手法は、より便利になる可能性があり、前の請求及び支払の例よりトランザクションに関する強化されたセキュリティをもたらす。例えば、検索セッションによって返されるコンテンツを複数のコンテンツプロバイダ１６０及び１７０から購入することが望まれる場合、ローカルユーザはローカルサーバとの単一のトランザクションを実行するだけでよい。これらの２つの当事者は、事前に存在する関係を有するので、ユーザが、それとの関係が存在しない可能性があるプロバイダから直接に購入する場合よりも、ユーザの識別を緩和することができる。同一の論点が、ローカルサーバ１５０とプロバイダ１６０及び１７０との間の関係に当てはまる。
【０１４９】
以上、マルチメディアコンテンツの提供に関して適用可能な例及び実施形態を説明したが、他の商品及びサービスも提供することができる。例えば、図１では、リンク１１８が、データベース１１７から電子的にダウンロードすることができるマルチメディアコンテンツではなく物理的な商品に向かっているが、ユーザのデータベース１１７に問い合わせる能力、検索結果を得る能力、及び最終的に購入トランザクションを実行する能力が残されている。
【０１５０】
更に、いくつかの実施形態は、特定の金融トランザクションに関する商業的な基礎を持たなくても良い。例えば、全世界の特許庁が、その独自データベースを一般公衆に使用可能にすることを選択することができる。上述したメディアブラウザ及びサーバの実施形態によって、ユーザ照会を複数のデータベースにポストできるようにするウェブページなどの特別に設計された統合ソフトウェアを必要とすることなく、これを実行できるようになる。従って、これにより、公衆が、分散異種データベースのフェデレーションにアクセスできるようになる。
【０１５１】
VI．装置用のカスタマイズ
図１１に、ユーザが、インターネットなどの通信ネットワーク１１０６をブラウズする目的でメディアブラウザサーバ１１０２への許可されたアクセスを有し、ユーザが関心を持ち、複製を望む可能性があるマルチメディア項目を識別するマルチメディアアクセスシステム１１００を示す。メディアブラウザサーバ１１０２は、データベース１１０４に関連し、データベース１１０４はユーザに固有の目次（ＴＯＣ）データを組み込まれ、前に訪問したかレビューのためにユーザが使用可能なロケーションを組み込まれる。目次及びメディアブラウザサーバ１１０２を用いて、ユーザは対応するコンテンツリポジトリ１１１０及びメタデータリポジトリ１１１１を関連付けられたメタデータサーバ１１０８を介してマルチメディアコンテンツを抽出することができる。
【０１５２】
ユーザは、実質的に図９の形態に対応する、デスクトップコンピュータ１１１２によってメディアブラウザサーバ１１０２にアクセスすることができる。そのような形態では、デスクトップコンピュータ１１１２が、その構成に応じてそれぞれがおそらくは複数のフォーマットで供給される、ビデオ、オーディオ、及び画像を含むマルチメディア項目のほとんどのタイプを複製する能力を有する。
【０１５３】
そのような情況では、デスクトップコンピュータ１１１２のユーザに供給される目次を、ビデオ、オーディオ、及び画像のコンテンツ項目に関係するメタデータを含む目次１１１４として示すことができる。これらの項目のそれぞれを目次１１１４内で提示することができるのは、デスクトップコンピュータ１１１２が、これらのデータフォーマットのそれぞれを複製する能力を有するからである。その結果、これらの項目が、メディアブラウザサーバ１１０２のデータベース１１０４内に保管されたユーザの目次の全体を表すことができる。
【０１５４】
しかし、本形態によれば、同一のユーザが、メディアのブラウジング及び配送用の代替装置を操作する時に、その代替装置でユーザに提示される目次が、現在使用されている（即ち代替の）装置で複製することができるコンテンツの項目だけを提示するように修正される。これも図１１に示されており、図１１では、ユーザがセル電話基地局及び公衆交換電話網１１１８を介してインターネットネットワーク１１０６に接続することができる、携帯電話受話器装置１１１６を操作する。携帯電話受話器１１１６は、これに関して無線アプリケーションプロトコル（ＷＡＰ）などの適当なデータフォーマットを使用してメディアブラウザサーバ１１０２を介するブラウジング動作を実行することができる。
【０１５５】
しかし、この場合に、携帯電話受話器１１１６は、そのディスプレイ上にテキストだけを複製する能力と、それに統合的に含まれるラウドスピーカ又は当技術分野で既知の、受話器１１０６に接続可能なヘッドセット装置を使用することによってサウンドを複製する能力を備える。その結果、テキストブラウジング（例えば、メタデータ内の視覚的識別子ではなくテキスト識別子を使用する）を電話受話器を使用して実行し、受話器１１１６のラウドスピーカを使用して複製することができるオーディオ項目だけに制限された目次１１２０を表示することができる。例えば、受話器１１１６にＭＰ３プレイヤモジュールが組み込まれている場合には、ＭＰ３圧縮されたデータを含む目次１１２０内のオーディオコンポーネントを複製することができる。更に、８ビットＰＣＭ又は１６ビットＰＣＭなどの他のフォーマットでエンコードされたオーディオを「電話」周波帯の３００Ｈｚから３ｋＨｚに帯域制限して複製することができる。
【０１５６】
通常、ユーザが要求するコンテンツは、コンテンツプロバイダのサイト（例えばメタデータサーバ１１０８）に保管される。その代わりに、コンテンツを保護された形でメディアブラウザサービス１１０２と一緒に保管することができる。そのような構成では、メディアブラウザサーバ１１０２がコンピュータ１１１２であれ電話機１１１６であれ、その時に使用されているデスティネーション装置に応じて装置へのコンテンツのストリーミングをカスタマイズすることができる。そのようなカスタマイズには、帯域幅の修正、コーディング、あらゆる形態の暗号化を含めることができる。
【０１５７】
そのような形態では、ユーザがコンテンツを購入する前に、プレビューの形でコンテンツをブラウズすることができる。プレビューで満足した時に、ユーザは、コンテンツにアクセスする権利を買うことを選択することができる。この権利を用いて、ユーザがディジタル項目の単一の再生／表示、所定の時間期間の間の再生／表示の権利、又はディジタルコンテンツの無制限コピー（ＣＤ又は電子的）を許可される。コンテンツを使用する権利を購入する時に、ユーザは購入するコンテンツに関して望まれるサービスの品質（ＱＯＳ）（例えば、チャネル数、関連するムービークリップなど）も指定することができる。購入を行った後に、ＱＯＳは使用される装置に無関係に、そのユーザが使用可能な最高のＱＯＳを表す。これは、ユーザが購入されたＱＯＳを利用できない装置からメディアブラウザサーバ１１０２にログオンする場合に、より低いＱＯＳがもたらされるからである。この例が、ユーザがデスクトップコンピュータ１１１２を使用して、ＣＤ品質オーディオの複製の権利を購入する場合である。その後に、電話受話器１１１６を持っている間、そのユーザが、前に購入したＣＤオーディオの複製を選択することができるが、このＣＤオーディオは、電話受話器のより低い品質の出力のために、より低いサービスの品質（例えば電話機の品質）で複製される可能性がある。このようなＱＯＳの変更は、その時に接続されている装置に応じてメディアブラウザサーバ１１０２によって検出することができ、これによって、メディアブラウザサーバ１１０２が、その時に使用中の装置に適用可能な複製ＱＯＳでメタデータサーバ１１０８を介して適当なコンテンツを抽出することがもたらされる。
【０１５８】
上述した例のそれぞれの場合で、ユーザに供給されるＴＯＣはリポジトリ１１０４内のユーザのデータから導出されるが、その時に使用されている特定の装置に応じてメディアブラウザサーバ１１０２によって修正されたものである。そのような形態を用いると、メディアブラウザサーバ１１０２がいつでもサーバ１１０２に接続されている装置のタイプを検出する能力を有し、余分な情報の配送なしに、適当なフォーマットでのその装置へのコンテンツの配送を保証する。そのような形態は、ユーザ選択を複製できるコンテンツに自動的に制限することを介し、システム１１００にまたがるデータ転送によって消費される帯域幅の削減においても望ましい。
【０１５９】
VII．使用する権利の制御
ユーザに電子マルチメディアコンテンツを提供することに関連する問題の１つが、ユーザが個人的使用又は配布のためにそのコンテンツを複製又はコピーできる範囲である。これは、オーディオ及びビデオコンテンツのオンライン販売の場合に、また著作権の維持及び芸術家及び演者へのロイヤリティの供給において、特に重要である。具体的に言うと、この問題は、ユーザが使用可能なコンテンツをブラウズし、コンテンツ選択を購入した後に現実になる。通常、購入は、ほとんどの場合に、コンテンツを使用できる形に関係する購入価格でコンテンツを使用する権利を提供する。通常、コンテンツは、コンテンツの単一の再生又は使用、所定の時間期間（例えば１時間、１週間、１年間）にわたる再生、購入者（ユーザ）による無期限の使用、及び、場合によっては、さ更なる使用の権利によって禁止されるか禁止されないかのいずれかのコンテンツを配布する権利まで変化する使用の権利と共に提供される可能性がある。
【０１６０】
そのような使用する権利に対する制御を提供する形態１２００を図１２に示す。図１２では、ユーザの装置１２０２が、メディアブラウザサービス１２０６を介してマルチメディアコンテンツにアクセスし、コンテンツは、コンテンツに関連するメタデータサーバ１２１４、コンテンツリポジトリ１２１６、及びメタデータリポジトリ１２１８を組み込んだコンテンツプロバイダ１２１２から得られる。前の形態と同様に、装置１２０２のユーザは、メディアブラウザサービス１２０６に関連するメタデータ１２０８を有し、このメタデータ１２０８が、コンテンツをコンテンツプロバイダ１２１２から取り出し、ユーザの装置１２０２に配送できるようにするリンク及び制御を形成する。
【０１６１】
購入の時に、保管されたコンテンツ１２１６に関するリポジトリ１２１８からのメタデータへのリッチリンクが、ユーザに転送される。このリッチリンクは、メタデータとして記述することもできるが、このリッチリンクに、コンテンツへのリンク、保管されたコンテンツ１２１６に関する情報（例えば、プログラム素材のリスティング）を含み、コンテンツの検索に使用されるメタデータ、コンテンツを使用する権利をユーザに与えるアクセス情報及び使用量情報が含まれる。アクセス情報は、ユーザがディジタルコンテンツを必要に応じて必要な時にユーザに配送／ストリーミングできるようにするために必要である。この形で、ユーザはコンテンツを保管するのではなく、コンテンツを複製する必要がある時に、必ず、単純にメディアブラウザサービス１２０６を介してコンテンツにアクセスする。前の形態と同様に、コンテンツを、その代わりに、メディアブラウザサービス１２０６を用いて保管することができ、この場合に、サービス１２０６は、コンテンツプロバイダ１２１２にとって信頼されるサービスとして働く。
【０１６２】
形態１２００は、ユーザの装置１２０２に配送される暗号化されないコンテンツ又は暗号化されたコンテンツのいずれかを使用して動作させることができる。どちらの場合でも、購入の後に、保管されたコンテンツ１２１６を表示又は再生する要求１２２６が、ユーザの装置１２１２から発行され、メディアブラウザサービス１２０６によって受信される。
【０１６３】
暗号化されない配送の場合には、アクセス鍵１２３０が、要求１２２６に応答して、メディアブラウザサービス１２０６からメタデータサーバ１２１４に送信１２２２される。メタデータサーバ１２１４は、保管されたコンテンツ１２１６を配送／ストリーミング１２２０する前に、アクセス鍵１２３０を検証する。コンテンツ１２１６は、メディアブラウザサービス１２０６に配送され、そこから、ユーザ１２０２へ、この場合には暗号化されない、装置に敏感な形１２２８で配送されることが好ましい。アクセス鍵１２３０は、２つの部分から形成されることが好ましい。第１の部分には、メディアブラウザサービス１２０６の一部としてユーザのメタデータ１２０８と共に保管され、ユーザと、そのユーザがアクセスする権利を有するコンテンツの項目とを識別するように動作する、鍵部分１２１０が含まれる。鍵部分１２１０は、コンテンツ１２１６の購入の時にユーザによって入力された鍵値とすることができ、そのコンテンツへのアクセスを可能にする個人識別番号の同等物を表し、コンテンツの特定の購入に関係することができ、従って、ユーザ及び購入されるコンテンツに関する情報を組み込むことができる。その代わりに、鍵部分１２１０を、メタデータサーバ１２１４によって自動的に生成することができる。アクセス鍵１２３０のもう１つの部分１２２４は、メディアブラウザサービス１２０６に固有とすることができる。その結果、アクセス鍵１２３０は、認証された２部分鍵対配置によって形成され、これは、メタデータサーバ１２１４による受信時に、ユーザの装置１２０２へのコンテンツ１２１６の配送をもたらし、このユーザの装置で、装置１２０２の一部を形成するプレイヤ１２０４を使用してそのコンテンツを複製することができる。
【０１６４】
上述した（暗号化されない）方法では、ユーザが購入したコンテンツの有効な受取人であることだけが保証されることに留意されたい。メタデータサーバ１２１４は、コンテンツを配送した後に、ユーザがコンテンツを保管すること又はコンテンツが他の潜在的なユーザによって傍受されることに対する制御を有しない。
【０１６５】
暗号化されたコンテンツをユーザに送信する場合には、メタデータサーバ１２１４が、有効なアクセス鍵１２３０を受信した時に、メタデータサーバ１２１４がメディアブラウザサービス１２０６にコンテンツ１２１６を送信１２２０することによって応答する。この配送は、暗号化される必要がない。これは、ほとんどの実施形態で、メディアブラウザサービス１２０６とメタデータサーバ１２１４の間のリンクが永久的又は他の形の信頼される接続とすることができるからである。しかし、追加の保護のために、暗号化を適用することができる。その場合に、メディアブラウザサービス１２０６は、ユーザの現在のセッションを識別する鍵情報を使用してストリーミングされたコンテンツ１２２０を暗号化し、暗号化されたコンテンツをユーザの装置に送信する。これに関して、鍵情報は、要求１２２６中にユーザのクライアント装置によって供給された識別（ＩＤ）から作るか、生成することができる。
【０１６６】
ユーザの装置１２０２のプレイヤ１２０４は、有効な暗号化解除鍵を有する場合に、条件的にコンテンツを暗号化解除する。この鍵は、コンテンツの暗号化に使用された鍵情報とすることができる。その代わりに、この鍵を、公開鍵／秘密鍵暗号対の秘密鍵とすることができる。セッションＩＤによって、コンテンツの暗号化解除鍵の一部又は全体を形成することができる。サーバ１２０６からのストリーミングの要求された時刻を、追加的に又はその代わりに使用することができる。
【０１６７】
この（暗号化された）コンテンツ配送の方法は、３つの別々のレベルで保護を提供する。まず、メタデータサーバ１２１４で、コンテンツは、有効なアクセス鍵が受信された場合に限って、メディアブラウザサーバ１２０６に配送される。メディアブラウザサーバ１２０６が、使用の権利の条件で設定された時に関して要求が有効であるかどうかを検査することが好ましい。即ち、メディアブラウザサーバ１２０６は、アクセス鍵１２３０をコンテンツプロバイダ１２１２のメタデータサーバ１２１４に送信する前に、満了日に関して検査する。メディアブラウザサービスは、使用量情報へのリンクを検査することによって、これを行うことができる。これは、使用量情報が、所定のスキーマに従って構造化されることを必要とする。その代わりに、好ましくは、メディアブラウザが要求を送信し、メタデータサーバが使用権を検査する。
【０１６８】
第２に、暗号化されたコンテンツは、別のセッション又はユーザのために再生されないので、メディアブラウザサーバ１２０６とユーザの装置１２０２の間でこれを傍受することはできない。
【０１６９】
第３に、プレイヤ１２０４がコンテンツを条件的に暗号化解除するので、コンテンツをクライアント側で保管することができない。
【０１７０】
その代わりに、コンテンツの暗号化に使用される鍵情報を、使用する権利のメタデータから得られるアクセス鍵及び満了日などの他の情報を含むものとするか、プレイヤ１２０４によって検査することができるバイオメトリック情報によるものとすることができる。例えば、バイオメトリック情報には、例えば、指紋、又は音声鍵識別を含めることができる。
【０１７１】
VIII．ユーザの間の通信リンク
異なるユーザが、ユーザが興味深いと思ったコンテンツへのリンクを交換できることが望ましいことがしばしばである。
【０１７２】
図１３Ａに、メディアブラウザサービス１３０２が、コンテンツ１３０６のユーザへの供給のためにメタデータサーバ１３０４に関連する、形態１３００を示す。サービス１３０２には、複数のユーザのそれぞれの目次のリポジトリ１３０８が組み込まれる。複数のユーザ１３１０及び１３１２が、サービス１３０２に登録され、通信ネットワーク１３８０によってサービス１３０２に結合され、この通信ネットワーク１３８０は、通常、有線の陸線の他にセルラリンク及びマイクロ波リンクなどの高周波コンポーネントを組み込むことができる公衆交換電話網（ＰＳＴＮ）である。
【０１７３】
第１のユーザ１３１０は、リポジトリ１３０８内に保管された目次１３６０を有し、同様に、第２のユーザ１３１２は目次１３６２を有する。第１のユーザ１３１０の目次１３６０には、メタデータ項目１３１８が含まれる。第１のユーザ１３１０によるサービス１３０２へのログオンの際に、ＴＯＣ１３６０がユーザ装置で複製１３１４され、項目１３１８に対応する画像サムネイルを含むように見える。メタデータ項目１３１８は、第１のユーザ１３１０に配送されるコンテンツ１３３０を提供し、受信されるコンテンツ１３３０は、符号１３２０に示されているように、１年の使用期間と関連付けられる。
【０１７４】
第１のユーザ１３１０がコンテンツ１３３０を第２のユーザ１３１２と共有することを望み、サービス１３０２に関する第２のユーザ１３１２のログオン詳細の知識を有する場合、第１のユーザは自分のＴＯＣ１３１４／１３６０からＴＯＣ１３６２にメタデータを転送することができる。これは、図１３Ａでは、メタデータ１３２２を提供するためのリポジトリ１３０８内のメタデータ１３１８のＴＯＣ１３６０からＴＯＣ１３６２への転送１３２８によって示されている。しかし、第２のユーザ１３１２はコンテンツ１３３０を購入していないので、この転送に関連する使用する権利のメタデータが「１年の使用」から「１回の再生／表示」に変更され、これにより、第２のユーザ１３１２はコンテンツ１３３０の単一の複製だけが許可される。第２のユーザ１３１２によるその後のログオンの際に、ＴＯＣ１３６２がユーザの装置にロードされ、メタデータ１３２２がＴＯＣ１３１６の送り状（inbox）に提示されるＴＯＣ１３１６として示される。
【０１７５】
図１３Ｂに、図１３Ａに類似し、類似する符号が対応する機能を有する対応する装置に関係する、形態１３９０を示す。しかし、図１３Ｂの形態１３９０は、第１のユーザ１３１０から第２のユーザ１３１２へのメタデータ１３１８の無線通信をもたらす。この構成では、ユーザ装置のそれぞれが、送信器１３４０、１３４４と、相補的なリスナ（受信器）１３４２、１３４６を設けられ、これにより、ＲＦ又はＩＲなどの無線通信を使用する、ユーザ装置の間の両方向直接通信がもたらされる。このような形態で、第１のユーザ１３１０がリスナ１３４６による受信のために送信器１３４０を介してＴＯＣ１３１４からメタデータ１３４８を転送することができ、リスナ１３４６はＴＯＣ１３１６へメタデータの運搬に専心することができる。そこから、ネットワーク接続１３８０によって、第２のユーザ１３１２が新しい項目エントリ１３２２を用いてＴＯＣ１３６２を更新できるようになる。この手法の特定の長所は、情報の送信側が受信側のログオン詳細を知る必要がないことである。
【０１７６】
更なる形態は、メディアブラウザサービス１３０２の登録されたユーザでない人へメタデータを有線又は無線で通信するものである。そのような例では、メタデータは、サービス１３０２の匿名ユーザログインと共に、送信者１３１０のメディアブラウザサービス１３０２のＵＲＩを含む受取り（voucher）に包まれても良い。受取りの受信者は、（例えばマウスクリックを介して）受取りを選択し、メディアブラウザサービス１３０２にアクセスし、匿名ログインを介してメタデータを表示することができる。受信者は、メタデータ内の使用する権利情報が十分に寛大であるかどうかに応じてコンテンツを再生することができる。
【０１７７】
受取りは、電子メールによって送信することができる。受取りは、２つの装置の間に送信器／リスナ環境が存在する場合、無線で送信することもできる。受信された受取りは、受信者の装置のデスクトップに表示される。
【０１７８】
メタデータ１３２６が、上述した方法のいずれかを使用して運ばれる情況では、メタデータに使用する権利の情報が含まれる、複数の可能性が残される。まず、使用する権利が未変更のまま残され、従って、無料で提供されるコンテンツのデフォルトケースになる可能性がある。そのような形態は、サービスに対して料金を請求するコンテンツプロバイダによってサポートされる可能性が低い。もう１つの可能性は、使用する権利のデフォルトを、図１３Ａ及び１３Ｂに示されているように、単一使用１３２８にすることである。もう１つの代替案は、使用する権利を元のメタデータの使用する権利の情報によって指示される形で変更することである。これには、コンテンツプロバイダのメタデータサーバとの通信と、新しいユーザに送信される新しい使用する権利が含まれる可能性がある。この処理は、受信側のメディアブラウザクライアントによって自動的に開始することができる。この形では、転送トランザクションをメディアブラウザ又はメタデータサーバの知識を用いて実行することだけができ、このメディアブラウザ又はメタデータサーバは新しいユーザの目次を変更し、結果として使用する権利の情報を変更する能力を有する。
【０１７９】
複数の理由から、コンテンツではなくメタデータ１３２６だけを通信することが好ましい（図１３Ａ及び１３Ｂには図示せず）。まず、モバイルデバイスは、通常、送信帯域幅より大きい受信帯域幅を有し（これが高価な送信器を必要としないので）、従って、リンクを供給する装置がコンテンツを送信することによる負担を被ることはない。また、メタデータには、コンテンツを使用する権利に関する情報を含めることができ、従って、この形態はコンテンツのライセンス交付されない使用を制限することを望むコンテンツプロバイダにとって魅力的である。これは、図１３Ａで、第１のユーザ１３１６がコンテンツの１年の使用１３１８を有するが、第２のユーザ１３２０にメタデータリンク１３２６を供給する際に、第２のユーザに「１回の再生のみ」の使用する権利１３２８が与えられることによって示されている。更に、メタデータだけを送信することの長所は、メタデータを受信側ユーザ１３２０の目次に追加することができ、それゆえ、検索に使用できることである。そのようなメタデータによって、受信側ユーザ１３２０が必要に応じてコンテンツを購入でき、完全な使用する権利を得ることができるようにもなる。
【０１８０】
説明した場合の各々のメタデータが、個々の記述又はメタデータサーバ１３０４に関連するメタデータリポジトリ内のメタデータ項目のいずれかへのリンクであることが好ましい。通信されるリンクに使用する権利の情報を含めるか、この情報への参照又はリンクを含めるかのいずれかを行うことができる。リンク、メタデータ、及び選択可能なコンテンツの間の関係を、図１３Ｃに示す。リンクには、上述したように、属性も含めることができるので、そのようなリンクは厳密ではないがメタデータとして説明することもできる。
【０１８１】
場合によっては、メタデータではなくコンテンツをストリーミングすることが好ましい場合がある。コンテンツをストリーミングすることの長所は、ストリームコンテンツを、効果的に同時に（カラオケのために同期化するなど）受信できることである。
【０１８２】
IX．装置の間のセッションの切替
図１４に、ユーザが現在のメディアブラウザセッションをある装置から別の装置へ切り替えられるようにする形態１４００を示す。図示されているのは、例えば、それぞれがマルチメディアストリームの複製に関する適当なプレイヤを備えた、携帯電話受話器１４０４又は自動車１４１６内のハイファイオーディオ機器１４１２を操作するユーザにマルチメディアデータストリーミングを提供するように構成されたメディアブラウザサービス１４０２である。
【０１８３】
例示的動作では、携帯電話１４０４を所有しているユーザがメディアブラウザサービス１４０２を介してアクセス可能なプロバイダにストリーミングメディアを要求することができる。これには、支払が伴う場合と、無料の場合とがある。要求を行う際に、電話機１４０４はメディアブラウザサービス１４０２に公開鍵も送信し、プロバイダがメディアの使用を認証できるようにすることができる。プロバイダは、その後、電話機１４０４にメディアブラウザサービス１４０２と同一でない場合にはそれを介してセッションに関連するメタデータを送信する。これには、セッション識別子が含まれ、メディアのロック解除に使用される鍵を含めることができる。鍵は、電話機１４０４の公開鍵を用いて暗号化され、その結果、特定の宛先の電話機１４０４だけが電話機１４０４内に保管された相補的な秘密鍵を使用してメディアをデコードできるようになる。この秘密鍵は、通常、電話機１４０４のメモリ内で保護され、その装置からエクスポートされることを意図されておらず、これにより、他の装置が電話機１４０４になりすますことを防止できる。
【０１８４】
ユーザがしばらく電話機１４０４を使用してメディアを受信した後に、ユーザはそのセッション（再生）を自分の自動車１４１６内の機器１４１２に転換することを決定する。セッションの転換を達成するために、ユーザは電話機１４０４に組み込まれた（図１４には図示されていないが、手持ちポータブル電子装置と共に使用することについて既知の）赤外線（ＩＲ）送受信器を自動車機器１４１２に関連して対応するＩＲ送受信器１４１４に向け、送信ボタン１４０８の押下により電話機１４０４はセッションに関連するメタデータを自動車機器１４１２に送信する。
【０１８５】
自動車機器１４１２は、その後、メディアブラウザサービス１４０２とのセッションを再ネゴシエートし、電話機１４０４がセッションを開始するために実行したものと同一のステップを実行するように動作する。これには、例えば機器１４１２によって複製できるサービス品質が電話機１４０４のそれより高く、それがユーザによって所望される場合の、余分な支払のネゴシエーションが含まれる可能性がある。具体的なハンドオーバ時間もネゴシエートされ、これによって、プレイヤの間のシームレスな転送が可能になる。この接続では、自動車機器１４１２に、何らかの形のＲＦトランシーバ装置が含まれており、例えばセル電話網を介する、メディアブラウザサービス１４０２との適当な通信が可能になることに留意されたい。
【０１８６】
ハンドオーバ時間に達した時に、メディアブラウザサービス１４０２が電話機１４０４へのセッションメディアの送信を停止し、自動車機器１４１２へのメディアの送信を開始する。電話機１４０４によって使用されたメタデータが無効になり、メディアはそれ以降はその特定のメタデータを使用して得ることができなくなる。スイッチオーバには、電話機１４０４及び自動車機器１４１２の経路遅延の推定値を得ることが含まれる場合がある。２つの参加者の間のネットワーク接続の経路遅延を推定する方法自体は、ネットワーク技術で既知である。
【０１８７】
この形態の特定の長所は、メディアブラウザサービス１４０２への通知を介して、コンテンツストリームの性質を複製が実行されるデスティネーション装置に対して条件的に変更できることである。これは、元のセッションに入った時に購入されたサービスの品質を条件として実行することができる。代替案では、デスティネーション装置の変更によって、配送とそれに関連するコストの新しい条件を受け入れることでサービスの品質を高めるようにユーザに促しても良い。この形で、電話受話器１４０４へのＭＰ３オーディオの配送を自動車ハイファイ機器１４１２へのＣＤ品質のオーディオのストリーミングに置換することができる。更に、自動車１４１６から降りた時に、ユーザは図１１のデスクトップコンピュータ１１１２などの更に高度な装置にセッションを転送することを選択することができ、この場合、その時に供給されているコンテンツに（例えば、電話機又は自動車ラジオで「聞く」ことができ、デスクトップコンピュータ１１１２を介して表示（見ながら聞く）ことができる音楽ビデオなどの）ビデオコンポーネントが含まれていれば、ビデオをオーディオと一緒にストリーミングしても良い。
【０１８８】
Ｘ．使用量情報
例えば図１２などの、上述した様々な形態で、コンテンツプロバイダ１２１２が特定のコンテンツ項目がメディアブラウザサーバ１２０６又は他のそのようなサーバ（図示せず）を介してメタデータサーバ１２１４に要求された回数に関する情報を簡単に累算できることを諒解されたい。しかし、メディアブラウザサーバ１２０６によって、余分な使用量情報を提供することができ、これには、下記を含めることができる。
（ａ）コンテンツの特定の項目の再生／表示に使用されている装置の種類、
（ｂ）人口統計又はメディアブラウザサーバ１２０６の地理的表示もしくはその両方による特定のコンテンツ項目の使用量。
【０１８９】
コンテンツプロバイダ１２１２は、彼ら自身のメタデータサーバ１２１４からの総使用量統計だけを有する。個々のメディアブラウザサービスから使用量情報を得ることに、商業的価値がある。この情報は、コンテンツプロバイダ１２１２が彼らのメタデータサーバを宣伝する方法（即ち、特定のサービスのデフォルトＴＯＣにリンクを含めることに支払うかどうか）を左右するのに使用することができる。
【０１９０】
ウェブサーバは、ダウンロードに関して既に効果的にこの統計を提供することができるが、ストリーミングコンテンツに関するこの情報を有することによってダウンロードではなく「使用」が測定されるので、より正確な統計が得られる。ユーザがあるディジタルコンテンツをダウンロードする時には、そのコンテンツが実際に使用される回数に関する情報は得られない。というのは、コンテンツがユーザによって保管されるからである。本明細書で説明する形態を用いると、コンテンツは、ユーザによって保管されるのではなく、ストリーミング又は他の形で、アクセスがメディアブラウザサーバ１２０６を介して行われるたびに供給される。また、装置の種類毎の使用量に関する統計を得ることにより、コンテンツプロバイダが彼らのサポート／調査を再生プラットホームに絞りこむのを支援することができる。
【０１９１】
XI．適当性レーティング制御の提供
説明した様々な形態で、許容可能なレーティングをメディアブラウザサービス１２０６或いは特定の装置と共にユーザアカウントに関連付けることができる。前者は、ある範囲のメディアブラウザアカウントがあることが必要である。これは、例えば、親（制御する側）アカウント及び子（制御される側）アカウントによって実施することができる。レーティング制御は、以下のために使用することができる。
（ａ）再生／表示の制御、及び／又は
（ｂ）購入の制御
ユーザは、現在、ウェブ（即ち、子供のページなど）を使用する人にレーティング制御を委ねることができるが、これらのレーティングレベルは一般にグローバルに決定される。親／子アカウントの概念及び親アカウントが親の制御の下であるものとして指定される１つ又は複数の他のアカウントを使用して再生／表示／購入できるコンテンツを具体的に制御できるようにすることは、アクセスを制御する、非常に望ましくカスタマイズ可能な方法である。重要なことに、親は、彼ら自身の子だけのアクセスを制御できる。
【０１９２】
アクセスは、複製装置によって制御することもできる。この場合、親と子は、彼らの所有者ユーザアカウントを有するか、同一のアカウントを使用することができる。しかし、子供によって使用される装置は、利用可能な項目のいくつかへのアクセスを制限するのに使用されても良い。
【０１９３】
XII．メディアブラウザサービスのロケーティング
コンテンツプロバイダ１２１２は、コンピュータネットワーク（インターネット、ウェブなど）を介して利用可能な、おそらく全ての、メディアブラウザサービス（１２０６など）を識別できることを望んでいる。これは、コンテンツプロバイダが、彼らのコンテンツをこれらのサービスに宣伝できるようになるために望まれるものである。従って、コンテンツプロバイダ１２１２は、ネットワークの検索を行い、特定の（メディアブラウザ）サービスを提供するサーバを識別し、そのサーバに宣伝材料を配布することができる。
【０１９４】
XIII．ユーザインターフェースのナビゲーション
図４を参照して上述したユーザインターフェースは、ほとんどのグラフィカルユーザインターフェース（ＧＵＩ）と同様に、一部選択可能であるグラフィカル情報の最適な提示を介して機能性を最大にしようと努めるデバイスである。そのようなＧＵＩは、グラフィックデザイナ、マーケティング担当者などのセミプロフェッショナル／ビジネスユーザ並びに家庭内コンピュータユーザによって使用されることが期待される。全てのＧＵＩと同様に、ディスプレイの面積は、高価であり、情報提示を最適化することが常に望ましい。階層データコレクション（例えばデータベース、ファイルシステム）を介するナビゲーションが、ほとんどのＧＵＩの重要なコンポーネントである。伝統的に、ＧＵＩナビゲーションは、所望のデータの位置を確認するためにユーザが木の枝を選択する、データコレクションの木表現を使用して実行される。そのような提示は、例えばWINDOWS EXPLORER（米国Microsoft Corporation社の商標）で行われるが、通常は表示画面（例えば９１４）の１側面全体に沿って、かなりの表示面積を占める。重要なことに、多数の分岐レベルに遭遇する場合に、そのような木は、表示画面の幅方向に延び、他の目的に望まれる表示面積を更に占める。
【０１９５】
本明細書に記載のメディアブラウザ形態並びに他の形態と共に使用することができる代替ＧＵＩが、図１６に示されたインターフェース１６００である。ユーザがメディアブラウザサービスにログオンする時に、ユーザに、そのユーザの現在のＴＯＣが提示される。トップレベルの項目は、ブラウズウィンドウ内でその視覚的識別子によって表されて表示される。
【０１９６】
ユーザの情報ランドスケープ又はＴＯＣを介するナビゲーションは、両方がビューイングウィンドウ１６０４の上に配置されるロケーション１６０２及び１６０６から形成される、階層「ブレッドクラブ」とユーザが対話することによって達成することができる。用語「ロケーション」は、葉以外のノードＴＯＣ記述子を指すのに使用される。ブレッドクラブの各レベル内で、ユーザはブレッドクラブのそのレベルで他の含まれるロケーションオプションのメニューをプルダウンすることを選択できる。
【０１９７】
階層ブレッドクラブを使用するナビゲーションを、図１７Ａ及び１７Ｂに例示する。図１７Ａに、ユーザのＴＯＣがMyDocumentsというタイトルを付けられた選択可能タブ１７０２の下に見られる、ＧＵＩ１６００の部分１７００を示す。選択された時に、タブ１７０２に、その下に直接含まれるロケーションがリストされる。含まれるロケーションを、例えばマウス９０３をクリックすることによって選択すると、選択されたロケーションに関する、隣接するリスト１７０４が作成される。図１７Ａから、ユーザがMyImagesを選択したことが明らかであろう。同様の選択によって、新しいリストが順番に作成されて、２０００年のCairnsでの休日に撮影された２つのＪＰＥＧ画像が示される。図１７Ａでは、データコレクションへの選択されたパスが、これにより、ユーザに、データコレクションのトラーバサルのために適当なコンテキスト的参照を提供することが、各ロケーション名の隣のチェックによって示されていることが明らかであろう。いつでも、ユーザがデータコレクション内の代替のパスに従うことを望む場合、選択されていないロケーションのどれでも選択することができ、これによって、対応するブレッドクラブディスプレイが表示される。これに関して、ブレッドクラブリストには、選択されたロケーションに含まれるロケーションだけが表示される。表示ウィンドウ１７１０がリストの下に配置されて、任意のＴＯＣ項目１７１２の表現（例えばサムネイル画像）を表示する。図１７Ｂに、ユーザが、図１７Ａの構成から、MyVideoを選択し、ナビゲーション表示がビデオコンテンツを有するロケーションを示すように変更された結果を示す。図１７Ａ及び図１７Ｂの各々で、サブディレクトリHol.2000が示されていることに留意されたい。というのは、MyImagesロケーションとMyVideoロケーションの両方に、その名前のロケーションが含まれるからである。前と同様、更に含まれるロケーション１７２４及び１７２６が表示されたロケーションから項目の適当な選択の際にリストされても良い。図１７Ｂに、MyVideoロケーションに含まれる項目１７３０を有する表示ウィンドウを示す。
【０１９８】
このナビゲーション方法を、ロケーション（ＸＭＬ記述内のノード）に関して説明したが、これをファイルシステム内のディレクトリに適用できることは明白である。
【０１９９】
標準的な木ベースの方法に対するこのナビゲーション手法の長所の１つは、様々な分岐パスに沿って上下にナビゲートする必要もなく、ある副枝から脱出し、別の副枝に直接に入ることが単純であることである。このナビゲーション方法の他の長所は、非常にわずかな画面スペースを使用することであり、これは、モバイルデバイスなどの画面スペースが限られる場合に貴重である。ユーザは、クリックされた項目の子項目を表示するために、ビューイングウィンドウ１６０６内の視覚的識別子を単純にダブルクリックするという標準的な方法を使用して自分のＴＯＣをナビゲートすることもできる。その代わりに、図１６のインターフェース上のブレッドクラブの右側に配置されるヒストリリスト１６０８内の所望のロケーションを選択することによって、前に訪問したロケーションを再表示することができる。
【０２００】
ユーザは、ビューイングウィンドウ内に表示する項目の数を定義することができる。しばしば、できる限り多数の項目（例えば検索結果）を視覚的に提示できることが望ましい。しかし、表示される項目が多すぎる場合には、項目のコンテンツを理解することが困難になる。ロケーションが単一のウィンドウ１６０６内に表示されるより多くの項目を含むならば、このウィンドウの下のビューイングウィンドウコントロール１６１０がそのコンテンツを通してページに使用される。試験的なユーザが初期のユーザビリティ調査でこのプリファレンスを示したので、ページングがスクローリングに優先して選択された。
【０２０１】
図１６の左上のパネルが検索パネル１６１２である。ユーザは、自分のＴＯＣから検索するロケーションを選択することができる。単純テキストベース検索と高度検索の両方に適応して、ユーザが所望の記述子と必要な値を選択できるようにしてある。高度検索では、ユーザが選択された記述子に対する制約を指定することによって質問を構築する。言い換えると、質問の結果はフィルタを伴うブラウジング表現に類似であり、XPathロケーションとして直接に表現される。インターフェース１６００は、ユーザがコンテンツタイプ（例えば画像、ビデオ及び／又はオーディオ）に基づき検索表現をフィルタリング可能とするが、メディアブラウザサーバはいずれのメディアタイプのメタデータも表現できる。メディアタイプセレクタがターゲットユーザのためのインターフェースのユーザビリティを改善するために、そのインターフェースに含まれる。
【０２０２】
左下のパネル１６１４に、ビューイングウィンドウ内で現在選択されている項目に関して一般的に使用されるプロパティ（index記述子）の組が表示される。このパネルに表示されるプロパティは事前に決定される。選択された記述子に、これらの記述子名を有するindex記述子が含まれず、使用可能なindex記述子を検査する（例えば、型date又は類似する記述子名を持つ可能性がある、他のindex記述子を検出する）ことによってこれらのプロパティを識別することができない場合には、値は表示されない。
【０２０３】
図１６の右側のパネル１６１８には、このインターフェースで開かれている現在のスタックの全てのリストが含まれる。スタックは、メタデータへのリンクの、ユーザのパーソナライズされたストアである（即ち、スタック内の各項目は、任意選択のXPointerを有するＵＲＩに過ぎない）。スタックは、検索結果、画像ライブラリの組からのお気に入りの画像への参照、又は別のタスクのための現在の作業セットを保管するのに使用することができる。開かれているスタックのどれにでも、ビューイングウィンドウから項目をドラッグすることができる。スタックは、ロケーションのように扱われ、ビューイングウィンドウで開き、表示することができる。開かれたスタックが閉じられる時に、前の非スタックロケーションがビューイングウィンドウ内で置換される。ユーザがスタックを使い終えた場合、ユーザは後のセッションで使用するためにスタックを保存することを選択することができる。これは、スタックデータがユーザのパーソナルデータに保存されることをもたらす。
【０２０４】
インターフェース１６００の右下の買い物かごアイコン１６２０は、購入に関する項目のために特殊化されたスタックに過ぎない。必要な場合に「購入ウィザード」をこのアイコンから呼び出して、ショッピング及び支払を容易にすることができる。このウィザードは、メディアブラウザに関するユーザのアカウントを使用して、買い物かごのメタデータに関連するコンテンツを購入できることが好ましい。言い換えると、コンテンツが異なるコンテンツプロバイダによって所有される場合は、ユーザが各ベンダを訪問して、そのベンダが提供する項目を購入する必要がなくなる。
【０２０５】
図１１の構成のような、ここに記載された形態を用いて、メディアブラウジングセッションを実施するために、ユーザは、通常、ローカルコンピュータ１１１２を用いて、インターネット１１０６へのアクセスを管理するために、NETSCAPE NAVIGATOR（米国Netscape Corp.社の商標）又はINTERNET EXPLORER（Microsoft Corp.社の商標）などの従来のインターネットブラウジングアプリケーションを実行する。インターネットブラウザを用いて、ユーザはメディアブラウザサーバ１１０２にアクセスし、メディアブラウザサーバ１１０２がユーザにログイン名及びパスワードを入力するように促す。ユーザがアクセスに関して許可されることに満足した時に、サーバ１１０２はローカルコンピュータ１１１２内でメディアブラウザアプリケーションを起動し、ユーザは、当初はＴＯＣ１１１４を提示される。ここで、ユーザがＴＯＣ１１１４から「Images」を選択すると、図１８Ａに示されたＧＵＩウィンドウ１９００を提示することができ、ここで、ユーザは検索セクション１９０２内で利用可能な機能及びアイコン１９０４、１９０６を利用して、ユーザ自身がブックマークに追加したロケーション１９０６から、オーディオ、ビデオ、及びテキストなどの他のメディアと比較して、全ての画像１９０４を識別する。その代わりに、ユーザはキーワード１９１０又は、画像、ビデオ、及びオーディオの各々について選択可能なアイコン１９１４を含む高度検索１９１２を用いて、他のディレクトリ１９０８を検索しても良い。検索は、アイコン１９１６の選択によって開始される。
【０２０６】
図１８Ａの例では、ユーザ自身の画像の検索によって、検索結果の複数のブラウザページが返されており、検索結果のそれぞれは、ＧＵＩウィンドウ１９００の主データ部分１９３２内に表示されるサムネイル画像１９２２、１９２４、１９２６などによって示される。検索結果の範囲は、検索結果のページの選択を提供するページングバー１９３０によって示される。この例では、番号「３」が強調表示され、ユーザが検索結果のページ３を表示していることが示されている。各サムネイル画像１９２２、１９２４、１９２６などは、最終的な表示、使用、又は購入もしくはこれらの組み合せについて所望することができる実際の画像に関連するメタデータの一部を表す。望む場合に、ユーザは、「properties」アイコン１９２０を選択することによって実際の画像に関する詳細情報を見ることができ、アイコン１９２０は、プロパティ要約区域１９１８内に配置され、プロパティ要約区域１９１８には、サムネイル１９２２、１９２４、１９２６の選択された１つについて、画像に関連する他のメタデータを表示することができる。
【０２０７】
図１８Ｂに移って、ユーザが図１８Ａのサムネイル１９２８並びにpropertiesアイコン１９２０を選択している。これが発生すると、プロパティ要約区域１９１８がブラウザウィンドウ１９００を横切ってかなりの範囲まで拡張され、主データ部分１９３２に表示されたサムネイル画像の多くを覆う。拡張された要約部分１９３４には、選択されたサムネイル１９２８ａの表現が含まれ、拡張された要約部分１９３４によって、ユーザが選択された画像の「Specific Properties」1936又は「All Properties」1938のビューのいずれかを選択できる。テーブル１９４０は、拡張された要約部分１９３４に提示され、これには、発行の詳細、画像に関連するキーワードなどを含む、画像に関する様々なカテゴリの情報が含まれる。一部の実施形態では、テーブル１９４０の項目のいくつかを、ユーザが変更でき、「ＯＫ」アイコン１９４２を用いて、ユーザＴＯＣ又はユーザ自身のメタデータレコードの一部として保存することができる。これには、様々なキャプション又はキーワードを含めることができるが、通常、発行者及び写真家などの所有者の情報は含まれない。そのような変更は、メディア項目のプロパティを変更することになる。
【０２０８】
ユーザが、図１８Ａのようにセット全体を得るのではなく、自分自身の画像内で検索することを望む状況では、「高度検索」アイコン１９１０を選択することができ、これによって、図１８Ｃに示されているように、「検索」区域１９０２が主データ区域１９３２を横切って拡張され、拡張された検索セクション内に検索可能な判断基準のテーブル１９５０が表示される。テーブル１９５０に示される判断基準には、図１８Ｂのプロパティテーブル１９４０に存在する可能性があるものが含まれる。ユーザは、テーブル１９５０内の値を修正して得られる検索結果の範囲を調整することができ、この検索結果は、更なるアイコン１９５２の選択によって確認される。
【０２０９】
図１８Ａに戻って、ユーザは、望みに応じて主部分１９３２内のメディア項目（即ち、この例ではサムネイル１９２２、１９２４、１９２６など）の１つ又は複数を選択し、これらの項目をスタック区域１９６０内の複数のスタックの１つにドラッグすることができる。この形で、ユーザは、望まれる場合にユーザ自身のソーティング方式に従って配置された、自分自身のメディアコレクションを簡単に作成することができる。図１８Ａでは、２つのスタック１９６２及び１９６４が示され、その各々が選択可能アイコンとして形成される。スタック１９６４は、ユーザが記録した、前の検索結果に関連する。
【０２１０】
スタックアイコン１９６４が開くために選択された時に、図１８Ｄに示されているように、スタック１９６４内に記録されたメディア参照、この例では人間の手の一連のサムネイル画像１９７０が、主データ区域１９３２内に表示される。これが発生すると、図１８Ｄに示されているように、スタックアイコン１９６４がスタック区域１９６０内で拡張され、この例では「Search_1」というタイトルを付けられた、選択されたスタックのコンテンツに関連する要約情報コンポーネント１９６６が形成される。表示される情報には、以下を含んでも良い。
（ｉ）コレクションの作成の詳細（例えば、検索によって使用された照会を含む、検索の結果として）
（ii）コレクションの項目数及び総サイズ
（iii）項目がスタックに追加又は削除された時のログ記録など、コレクションに対して実行されたアクティビティのヒストリ
（iv）適当である場合に、コレクションのコンテンツのアニメーション付きプレビュー。例えば、スタックにビデオ項目（又はそれへのリンク）が含まれる場合に、これらの項目の要約をコレクションプレビューにアニメーション化することができる。これには、メディアプレイヤウィンドウ又は類似物などの適当なプレビューツールの起動を含めることができる。
【０２１１】
コレクションアイコンの一部としてこの情報を表示することには、複数の長所が存在する。長所には、以下が含まれる。
（ｉ）表示される情報がスタックコレクションのプロパティを表すことが、ユーザに簡単に明白になる
（ii）ユーザが他の形でスタック要約情報の表示を具体的に選択する必要がなくなる
（iii）要約情報は、コレクションが作成された形に応じて変化するものとすることができる。例えば、スタックコレクションが、例えば追加又は削除によって変更される際に、要約情報を自動的に更新することができる。
【０２１２】
図１８Ａ乃至１８Ｄの形態は、コレクションが表示のために開かれる時に項目及び項目のコレクション（この場合メタデータへのリンク）に関する情報を自動的に示す方法を提供する。従来技術の形態と異なり、この情報は、コレクションアイコンの展開の一部として表示され、これは、コレクションがユーザによって開かれる時にアニメーションされた形で行われることが好ましい。これに対して、要約情報をWINDOWS EXPLORER（Microsoft Corp.）内で項目について表示することができるが、そのような情報は、コレクション項目（フォルダ）を右クリックし、システムがプロパティダイアログを表示することによって表示されるか、コレクションの子項目のアイコンを含むブラウズウィンドウ内に表示されるかのいずれかである。図１８Ａ乃至１８Ｄの形態で、ユーザがスタック（コレクション）を開く時にスタックアイコンが展開され、要約情報（スタック名の他に）がスタックアイコン自体の拡大された区域に表示される。
【０２１３】
XIV．代替の構造化された情報処理システム
ここまでの説明は、メタデータを使用するブラウジング及び検索と、その後の関連するコンテンツのアクセスに関するものであった。上述した特徴の多くが、アクセスされるリポジトリに必ずしもコンテンツの特定の項目にリンクされない情報が含まれる場合にも適用されることは、当業者には明白であろう。例えば、本明細書で情報サーバと称する、メタデータサーバの同等物を、情報サーバに関連する供給源に保管された特定の構造化された情報に関する、プロセスからの要求をも受け入れるように構成することができる。情報供給源は、メタデータリポジトリと同様に、スキーマによって公開的に表現することができる。要求元のプロセスと情報サーバの間の通信は、この明細書の節IIIで実質的に説明したように構成することができる（即ち、これにより、ブラウジング要求及び検索要求が可能になる）。要求の結果は、構造化された情報を表すＸＭＬ文書である。節Ｖの最後に示した、このより一般的な実施形態の例は、ユーザが単一のユーザインターフェースを用いて全世界の異なる特許データベースに潜在的にアクセスする方法を示している。
【０２１４】
明らかに、情報サーバに要求を行う処理は、多少異なる形で動作する。例えば、ＴＯＣ記述子とindex記述子の間の区別は、もはや有用ではないかもしれない。その代わりに、そのような構造化情報を受け取る処理の主な特徴は、様々な異種供給源からの情報を正しくフォーマットすることである。そのような最終目的のために、前に説明した高度検索を用いて必要な情報を選択的に識別する能力が非常に有用である。ブラウジング要求及び検索要求の結果は、使用されるデータ型に応じて、特定のユーザのためにカスタマイズされたものであってもなくてもよい、所定のフォーマットを用いる様々なフォーマットでユーザに提示することができる。
【０２１５】
［産業上の利用可能性］
上述した形態及び実施形態は、コンピュータ産業及びデータ処理産業、特に、マルチメディアサービスを提供する産業に適用可能である。実施形態は、特に、インターネットサービスプロバイダが、彼らが提供するサービス又はホストもしくはその両方の検索に商業的価値を追加しながら、コンテンツのベンダと購入者とを引き合わせることを容易にすることを提供する。
【０２１６】
前述は、本発明の少なくとも１つの実施形態を説明したものであり、本発明の範囲及び趣旨から逸脱せずにこれに対する修正又は変更を行うことができ、この実施形態は、例示的であって制限的ではない。
【０２１７】
付録１は、図１５の例に関するＸＭＬソース記述であり、付録２は、付録１のソース記述を正規化された形に変換するのに使用することができるＸＭＬスタイルシートである。

【図面の簡単な説明】
【図１】マルチメディアアクセスシステムの動作環境を示すブロック図である。
【図２】図１のメディアブラウザがメタデータデータベースにアクセスする方法を示す、より詳細なブロック図である。
【図３】メディアブラウザとメタデータサーバの間の通信処理を示す流れ図である。
【図４】マルチメディアアクセスシステムのメディアブラウザコンポーネントのユーザインターフェースの視覚的外観を示す図である。
【図５】メディアブラウザの好ましいブラウジング処理を示す流れ図である。
【図６】メディアブラウザの好ましい検索処理を示す流れ図である。
【図７】構造化された画像メタデータデータベースを示す図である。
【図８】ブラウジング処理によって使用されるＸＭＬメタデータの例を示す図である。
【図９】メディアブラウザがその上で動作することができるコンピュータシステムの概略ブロック図表現である。
【図１０】図１から８のシステムの例の実施形態を示す図である。
【図１１】異なる装置のためのメディアブラウザのカスタマイズを示す図である。
【図１２】マルチメディアコンテンツを使用する権利を制御できる配置を示す図である。
【図１３Ａ】、
【図１３Ｂ】、
【図１３Ｃ】メタデータリンクを装置の間で通信できる方法を示す図である。
【図１４】現在のメディアブラウザセッションをある装置から別の装置へ切り替えることができる配置を示す図である。
【図１５（ａ）】、
【図１５（ｂ）】ソース記述を、メディアブラウザ配置によって提示可能な正規化された記述に変換できる方法の例を示す図である。
【図１６】好ましいメディアブラウザのグラフィカルユーザインターフェースを示す図である。
【図１７Ａ】、
【図１７Ｂ】「ブレッドクラブ」ナビゲーションが図１６のインターフェースでどのように使用されるかを示す図である。
【図１８Ａ】、
【図１８Ｂ】、
【図１８Ｃ】、
【図１８Ｄ】さらに変更されたメディアブラウザグラフィカルユーザインターフェースを介するシステムユーザを示す図である。

Claims (5)

1. メディアブラウザサーバが、ユーザに対して許可されたマルチメディアコンテンツの目次データをデータベースに記憶するステップを実行し、
   第１のユーザ装置が、前記メディアブラウザサーバにアクセスして該第１のユーザ装置に供給された前記マルチメディアコンテンツの目次データ全体を表示する第１の表示ステップを実行し、
   第２のユーザ装置が、前記メディアブラウザサーバにアクセスして該第２のユーザ装置に供給された前記目次データの中から第２のユーザ装置により複製可能なマルチメディアコンテンツの項目を表示する第２の表示ステップと、
   前記第２の表示ステップで表示した項目の中から要求されたマルチメディアコンテンツを前記メディアブラウザサーバから複製する複製ステップとを実行することを特徴とするマルチメディアコンテンツの配信方法。
2. 前記メディアブラウザサーバが、前記第１のユーザ装置又は前記第２のユーザ装置のタイプを検出する検出ステップと、
   前記検出されたタイプに応じたフォーマットのデータを前記第１のユーザ装置又は前記第２のユーザ装置へ配信する配信ステップとを更に実行することを特徴とする請求項１記載のマルチメディアコンテンツの配信方法。
3. 前記メディアブラウザサーバが、前記第１のユーザ装置又は前記第２のユーザ装置から要求されるマルチメディアコンテンツを保管する保管ステップを実行し、
   前記メディアブラウザサーバが、前記第１のユーザ装置又は前記第２のユーザ装置からの要求に応じて、前記マルチメディアコンテンツのストリーミングをカスタマイズするカスタマイズステップを更に実行することを特徴とする請求項１記載のマルチメディアコンテンツの配信方法。
4. 前記カスタマイズステップでは、前記マルチメディアコンテンツのストリーミングの帯域幅の修正、コーディング、暗号化のうち、少なくとも１つが行われることを特徴とする請求項３記載のマルチメディアコンテンツの配信方法。
5. 前記第１のユーザ端末又は第２のユーザ端末が、前記マルチメディアコンテンツを表示する表示ステップと、
   前記マルチメディアコンテンツの表示後、前記マルチメディアコンテンツのアクセス権の購入を前記メディアブラウザサーバに対して指示する指示ステップとを更に実行し、
   前記メディアブラウザサーバが、前記指示されたマルチメディアコンテンツの再生、再生期間又はコピーを前記第１のユーザ装置又は前記第２のユーザ装置に対して許可する許可ステップを実行することを特徴とする請求項１記載のマルチメディアコンテンツの配信方法。

Images