JP3754912B2 - Multimedia content distribution method - Google Patents

Description

【００３９】
属性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記述子の間の区別は、もはや有用ではないかもしれない。その代わりに、そのような構造化情報を受け取る処理の主な特徴は、様々な異種供給源からの情報を正しくフォーマットすることである。そのような最終目的のために、前に説明した高度検索を用いて必要な情報を選択的に識別する能力が非常に有用である。ブラウジング要求及び検索要求の結果は、使用されるデータ型に応じて、特定のユーザのためにカスタマイズされたものであってもなくてもよい、所定のフォーマットを用いる様々なフォーマットでユーザに提示することができる。
【０２１５】
［産業上の利用可能性］
上述した形態及び実施形態は、コンピュータ産業及びデータ処理産業、特に、マルチメディアサービスを提供する産業に適用可能である。実施形態は、特に、インターネットサービスプロバイダが、彼らが提供するサービス又はホストもしくはその両方の検索に商業的価値を追加しながら、コンテンツのベンダと購入者とを引き合わせることを容易にすることを提供する。
【０２１６】
前述は、本発明の少なくとも１つの実施形態を説明したものであり、本発明の範囲及び趣旨から逸脱せずにこれに対する修正又は変更を行うことができ、この実施形態は、例示的であって制限的ではない。
【０２１７】
付録１は、図１５の例に関するＸＭＬソース記述であり、付録２は、付録１のソース記述を正規化された形に変換するのに使用することができるＸＭＬスタイルシートである。

【図面の簡単な説明】
【図１】マルチメディアアクセスシステムの動作環境を示すブロック図である。
【図２】図１のメディアブラウザがメタデータデータベースにアクセスする方法を示す、より詳細なブロック図である。
【図３】メディアブラウザとメタデータサーバの間の通信処理を示す流れ図である。
【図４】マルチメディアアクセスシステムのメディアブラウザコンポーネントのユーザインターフェースの視覚的外観を示す図である。
【図５】メディアブラウザの好ましいブラウジング処理を示す流れ図である。
【図６】メディアブラウザの好ましい検索処理を示す流れ図である。
【図７】構造化された画像メタデータデータベースを示す図である。
【図８】ブラウジング処理によって使用されるＸＭＬメタデータの例を示す図である。
【図９】メディアブラウザがその上で動作することができるコンピュータシステムの概略ブロック図表現である。
【図１０】図１から８のシステムの例の実施形態を示す図である。
【図１１】異なる装置のためのメディアブラウザのカスタマイズを示す図である。
【図１２】マルチメディアコンテンツを使用する権利を制御できる配置を示す図である。
【図１３Ａ】、
【図１３Ｂ】、
【図１３Ｃ】メタデータリンクを装置の間で通信できる方法を示す図である。
【図１４】現在のメディアブラウザセッションをある装置から別の装置へ切り替えることができる配置を示す図である。
【図１５（ａ）】、
【図１５（ｂ）】ソース記述を、メディアブラウザ配置によって提示可能な正規化された記述に変換できる方法の例を示す図である。
【図１６】好ましいメディアブラウザのグラフィカルユーザインターフェースを示す図である。
【図１７Ａ】、
【図１７Ｂ】「ブレッドクラブ」ナビゲーションが図１６のインターフェースでどのように使用されるかを示す図である。
【図１８Ａ】、
【図１８Ｂ】、
【図１８Ｃ】、
【図１８Ｄ】さらに変更されたメディアブラウザグラフィカルユーザインターフェースを介するシステムユーザを示す図である。[0001]
BACKGROUND OF THE INVENTION
The present invention applies to multimedia content. Electronic Regarding access.
[0002]
[Prior art]
As network connectivity continues to explode, content providers are using the World Wide Web (“Web”) to provide access to multimedia content (eg, images, video, audio, etc.). Unlike text content such as HTML pages, multimedia content is not directly accessible from standard web search engines. These search engines examine web sites and extract information about the text content of those sites. Such information is commonly referred to as “metadata”, which is data that describes or catalogs aspects of other data. The extracted information (metadata) can give the user access to its content using a customized metadata database.
[0003]
In the case of multimedia, the content provider or content distributor typically stores information about the multimedia items it can access in a metadata database. The content provider allows access to these databases by providing a search engine that users or customers can access from a website, typically the content provider / distributor's own website. A customer seeking to view or possibly purchase content that can be accessed by a content provider / distributor can visit a website and use a search engine to search the content provider / distributor's metadata database. A metadata database typically includes visual identifiers of content (eg, thumbnails, video abstracts, audio previews, etc.) as part of the metadata. Users can make decisions regarding items they wish to purchase / use based on the metadata returned from those searches.
[0004]
In many cases, the multimedia content is digital and online, and potential customers purchase the right to use the desired multimedia item from the content provider / distributor's website, or a copy of the desired multimedia item. Can be purchased. Often this transaction is completed on the website and potential customers can download the newly acquired content directly. However, this model of providing access to multimedia content does not require the content to be online. For example, a potential customer can purchase a right to use the desired content or a copy of the desired content from a website, but the content can be obtained by non-electronic means (ie a postal system). Can also be delivered to. Another variation is that potential customers can be redirected from the distributor's site to the actual content provider for purchase of desired content and acquisition of copies. Other variations include directing potential customers to physical locations for purchasing content and mailing books containing metadata related to the items being purchased.
[0005]
In all of the above situations, potential customers only have access to content that each content provider / distributor can access. If a potential customer wants to perform a search across multiple different content providers / distributors, the potential customer visits each website of the multiple content providers / distributors and searches The engine must be used. Such actions are often time consuming and cumbersome because potential customers must use different search engine interfaces each time.
[0006]
These issues have encouraged the development of very large metadata databases on the Web, where content distributors either purchase content rights or simply act as distributors for smaller content providers. Examples are the huge image databases called Getty and Corbus. This approach has its own problems. First, this approach does not scale because the search time increases when the database becomes very large. In addition, all metadata must typically be configured in a similar manner so that the same metadata key is included. However, this is not always desirable because different metadata becomes more appropriate depending on the intended use of the content. For example, images captured for geology require different metadata than those captured for vacation brochures. Third, smaller content providers do not have a way to sell their content directly (ie, they are effectively forced to use a larger distributor).
[0007]
The object of the present invention is to remedy one or more disadvantages of the prior art.
[0008]
[Means for Solving the Problems]
The multimedia content distribution method of the present invention is a media browser server. But Storing table of contents data of multimedia contents authorized for user in database Run , First user equipment But , The multimedia content provided to the first user device by accessing the media browser server; Table of contents data The entire Display First Display step Run , Second user equipment But , Supplied to the second user device by accessing the media browser server Display items of multimedia contents that can be copied by the second user device from the table of contents data. Second Display in the display step and the second display step Shi Requested multimedia content from From the media browser server Duplicate Duplication Step and Execution It is characterized by doing.
[0015]
DETAILED DESCRIPTION OF THE INVENTION
I. Overview
FIG. 1 illustrates a multimedia access system 100 in which a computer application program, hereinafter referred to as a media browser 101, runs on a local computer 105 to form a connection to a computer network such as the Internet 102. As can be seen, the Internet 102 is associated with a plurality of server computers 108 and 109, each of which can host a plurality of websites, each of which can store multimedia content. There are corresponding stores 112 and 114 that can. Similarly, the local computer 105 can also have an associated store 107, but this is not essential for implementation. Media browser application 101 provides a single user interface for browsing and searching system 100 for multimedia items using metadata that is electronically accessible to users of local computer 105. In other words, the media browser 101 operates metadata. Multimedia content playback / display is accomplished through the use of plug-in media tools and is decoupled from metadata-related processing. The media browser 101 is described in detail in Section IV below.
[0016]
The arrangement described above can be practiced using a general purpose computer system 900 such as that shown in FIG. 9, where the processing of FIG. 1 and the processing described below is performed within the computer system 900. Implemented as software such as application programs. Specifically, the media browsing method is provided by instructions in software executed by a computer system. The software essentially splits into two separate parts: a part that performs browsing and search requests for a specific metadata store, and a part that manages the user interface between the specific metadata store and the user. be able to. These two parts can be executed on separate computers in a mode called client-server mode. The software may be stored on one or more computer readable media including, for example, storage devices described below. The software is loaded from the computer readable medium into the computer of the system and then executed by the computer. A computer readable medium having such software or computer program recorded on it is a computer program product. Preferably, the use of a computer program product on a computer provides an advantageous device for media browsing.
[0017]
Computer system 900 includes a computer module 901, input devices such as a keyboard 902 and mouse 903, and output devices including a printer 915 and an audio-visual output device 914. A modulator-demodulator (modem) transceiver device 916 is used by the computer module 901 for communication with a communication network 920 that can be connected, for example, via a telephone line 921 or other functional medium. The network 920 can be, for example, the Internet or other network system, or both, such as a local area network (LAN) or a wide area network (WAN). Collectively, the devices 901-916 can form, for example, the local computer 105 or one or any of the server computers 108 and 109 shown in FIG. 1 and are often described as computer workstations.
[0018]
The computer module 901 typically includes at least one processor unit 905, a memory unit 906 formed, for example, from semiconductor random access memory (RAM) and read-only memory (ROM), and an input / output including an audio-visual interface 907. An (I / O) interface, an input / output interface 913 for a keyboard 902 and mouse 903 and an optional joystick (not shown), and an interface 908 for a modem 916 are included. A storage device 909 is provided, which typically includes a hard disk drive 910 and a floppy disk drive 911. A magnetic tape drive (not shown) can also be used. A CD-ROM drive 912 is typically provided as a non-volatile source of data. The components 905-913 of computer module 901 typically communicate via interconnected bus 904 in a manner that provides a normal mode of operation of computer system 900 known to those skilled in the art. Examples of computers that can implement the described arrangement include IBM-PC and compatible machines, Sun Sparcstation, and similar computer systems originating therefrom.
[0019]
The application program typically resides on the hard disk drive 910, is read by the processor 905, and is controlled during its execution. Intermediate storage of programs and data retrieved from network 920 can be accomplished using semiconductor memory 906, possibly in conjunction with hard disk drive 910. The audio-visual output device 914 can be used to provide a graphical user interface to an application program so that user input is presented via the keyboard 902 and a mouse cursor to the audio-visual output device 914. It can be given by clicking the button of the mouse 903 when operated by the interface. In some cases, an application program can be encoded on a CD-ROM or floppy disk, read via a corresponding drive 912 or 911, and provided to the user, instead, from the network 920 to the modem device 916. It can be read by the user via In addition, the software includes magnetic tape, ROM or integrated circuit, magneto-optical disk, wireless or infrared transmission channel between computer module 901 and another device, computer readable card such as a PCMCIA card, electronic It can also be loaded into computer system 900 from other computer readable media, including the Internet and intranets, including mail transmissions and information recorded on websites. The foregoing is merely exemplary of relevant computer readable media. Other computer readable media may be practiced without departing from the scope and spirit of the invention.
[0020]
Returning to FIG. 1, the metadata used by the media browser 101 can be accessed directly from the local computer 105 or from an accessible site on the Internet 102, such as the server 108. Typically, metadata about a collection of multimedia content is stored in a collection (eg, repository or database) with each item of content having at least one corresponding metadata item. As can be seen from FIG. 1, each content database or store 107, 112, and 114 is associated with a corresponding database 106, 110, and 111, respectively, which is associated with each corresponding content database or store 107, 112. , And 114 are configured to store metadata items to facilitate access to content. In the following, a metadata item is also referred to as a description of the corresponding item (usually content), and the term metadata collection refers to a collection of such descriptions.
[0021]
In the preferred example, the media browser 101 can access the metadata without having to access the content (107, 112, and 114). In other words, the description is not stored as an integrated part of the content item. This means that the media browser 101 does not need to be able to directly interpret a number of storage formats / transport formats of audiovisual content in order to access the metadata.
[0022]
Media browser 101 assumes that each description (in databases 106, 110, and 111) has a link to its corresponding content in a content database or store (107, 112, and 114). If the content is stored electronically, these links can be triggered by the user or by a process or electronically followed (eg, 120, 115, and 116). Instead, a link, such as link 118, can describe the path to a non-electronic location (eg, a film archive). Non-electronic links are not active (ie, remote users or processes cannot follow it) and therefore only provide knowledge of available content. Thus, a remote user cannot obtain the ability to preview content using the media browser 101 using such a non-electronic link.
[0023]
The media browser 101 needs to be able to express metadata in a standard form. In the preferred example, the syntax and structure of each description is defined by a schema. Different schemas can be used to describe different items of content. Typically, the schema used reflects the type of content and the normal usage or purpose of the content. For example, the geological satellite image metadata schema is very likely to be very different from the digital home video schema.
[0024]
Schemas can differ in the nature of the syntax structure and the type of description components (hereinafter referred to as descriptors). For example, in a digital home video schema, this type of description of content can be modeled to include a digital video tape that contains one or more scenes, each containing one or more clips or shots. There is. A geological satellite image schema may have multiple descriptors with a specific geological focus that is simply used to describe each image. In a preferred example, the schema is expressed using the W3C Extensible Markup Language (XML) Schema language, and each description is expressed as an XML document. Metadata representation is further described in Section II.
[0025]
FIG. 2 shows an example of how the media browser 101 can access metadata via the Internet 102. All access to the metadata is accomplished using links where the target of each link is represented as a Uniform Resource Identifier (URI). These links can be activated either automatically by the media browser 101 or in response to a user action (eg, clicking on the item).
[0026]
If the metadata is stored in an XML repository (a collection of XML documents) 200, the media browser 101 provides access to the metadata stored in the repository 200 using a link to the XML description of the repository 200. can do. In this description, the structure of the repository 200 presented to the user of the media browser 101 is expressed. The XML description is expressed in the same form as the description of the multimedia item of the content. In other words, the description is preferably accessible from the media browser 101 and preferably conforms to an XML schema that describes the structure of the repository 200. The XML description can include links to other descriptions of a particular section of the repository 200 (in other words, the description of the repository 200 need not be contained within a single XML document). Finally, the repository XML description has a link to the description of the multimedia item. Each multimedia item description in the repository 200 preferably includes a link 201 to the corresponding multimedia item in the corresponding content collection 202. Thus, when the user or customer selects display or playback of items based on the presented metadata, the media browser 101 can retrieve these items.
[0027]
If access to a non-XML repository referred to herein as a legacy database 210 is desired, the link described above with respect to FIG. 1 must operate through a server module referred to as a metadata server 212. The metadata server 212 is preferably located at the metadata site (ie, either local or remote), but it is not required and is configured and controlled by the metadata owner. The purpose of the metadata server 212 is to effectively convert the metadata stored in the legacy database 210 into a format required by the media browser 101. In other words, the metadata server 212 should preferably provide access to one or more schemas for metadata and dynamically generate XML descriptions that conform to these schemas. It is only necessary for the metadata server 212 to provide a schema definition that describes the structure / syntax of the metadata collection, and the structure / syntax of each description is preferably stored in the legacy database 210. These schema definitions may be included in one or more XML schema documents. Similar to the case where the remote metadata is stored in the XML repository 200, the description of the multimedia item generated by the metadata server 212 includes the corresponding multimedia item stored in the content collection 214 corresponding to the legacy database 210. Link is included.
[0028]
A link to the metadata server is also expressed using a URI. This URI consists of a network identifier component that is the URI itself, and a query string that specifies details of the metadata server request. The request can be performed using an HTTP (Hypertext Transfer Protocol) “get” request on the Internet. The processing of the query results in a description of either the structure of the collection or the multimedia item, depending on how the metadata server 212 interprets the query string.
[0029]
The description dynamically generated by the metadata server 212 may be responsive to the browsing or search results of the media browser user. The metadata server is further described in Section III below.
[0030]
II. Metadata representation
The preferred example assumes that all descriptions of multimedia items conform to a schema and that the schema is represented or represented using an XML schema, which is the W3C schema language. Individual descriptions are represented using XML document instances. An XML schema is also expressed as an XML document. Thus, descriptions (eg of multimedia items) can be stored with each schema in an XML repository or XML object store. Instead, the description can be stored in a database and effectively converted to an XML document when needed.
[0031]
Each description contains a reference to the schema to which it conforms. References are expressed using URIs (eg http: //somesite/schemas/DigitalVideoSchema.xsd). This means that after a media browser gains access to a description, it can directly access one or more schemas to which the description conforms.
[0032]
Normally, each XML element in the description (XML document) is declared to belong to a uniquely identified namespace. An XML document can use the attribute schemaLocation (in the XMLSchema-instance namespace) to hint the processor about the location of the schema that contains the definition for a particular namespace. Thus, an XML document, therefore, references one or more schemas indirectly, not directly.
[0033]
In this document, the term “descriptor” is used to refer to a component or atom of description. Each descriptor includes a feature (descriptor name) and a value (description value). In some cases, the descriptor value includes other descriptors, and thus the descriptor value can form a “composite descriptor”. In other cases, the descriptor value is a scalar value such as a string or date (ie, a simple descriptor or an atomic descriptor). In any case, the media browser 101 assumes that the descriptor is expressed with the element (tag) name being the descriptor name and the content of the element being the descriptor value. For example, a simple descriptor can use the text content of an element (ie, text between tags) to represent the value of the descriptor (eg, date, text string, enumeration, etc.).
[0034]
This assumption about the structure of metadata is not different from how many practitioners currently use markup languages. In other words, this does not require a significant change from how practitioners represent a particular metadata vocabulary.
[0035]
Here are some examples of descriptions: In the simple descriptor <Photographer> John Smith </ Photographer>, Photographer is the name of the descriptor and John Smith is the value of the descriptor. The text type of a simple descriptor can be constrained using the simpleType construct of the XML schema.
[0036]
In the example shown in FIG. 8, both VideoScene and Clip are composite descriptors. The value of the VideoScene descriptor is the markup included between the start tag and end tag of this descriptor. The name of the descriptor is a tag name (ie, VideoScene). Similarly, the value of the Clip composite descriptor is a markup included between the start tag and the end tag of the Clip descriptor. The Clip descriptor value includes two simple descriptors Date and Location. The value of the Location descriptor is text (ie, Sydney, Australia) included between the start Location tag and the end Location tag.
[0037]
Used as a preferred example when a description schema designer defines his or her descriptor, so that the basic semantics of the description can be better interpreted to present the description to the user in a meaningful way. A core schema is included that includes definitions of multiple basic attributes that can be. An example of definitions included in this core schema is shown in Example A below. In this example A, only a portion of the actual schema is shown. The definition of this example belongs to the unique media browser namespace identified in this example by the prefix “mb:”. Suppose this prefix assignment has been performed previously in the schema using the xmlns attribute.
[0038]

[0039]
The attribute descriptorType is used to define whether the description is handled as part of the table of contents (TOC descriptor) or part of the index (index descriptor).
[0040]
The TOC descriptor is used to describe the structure of the description and is usually a composite descriptor. A TOC descriptor is navigable in the sense that either its attributes or its child attributes must contain a link. The target of the link can be either another descriptor or an item of content. A TOC descriptor is similar to a table of contents item in that it allows the reader to navigate directly to a section of the work.
[0041]
The index descriptor is usually a leaf node of a hierarchically structured descriptor structure, often referred to as a property (ie, a type of descriptive information that is displayed using the properties dialog on Microsoft Windows systems). ). Section IV below describes how the media browser uses the descriptorType attribute.
[0042]
Attributes are also used to include descriptor visual identifiers and / or text identifiers. The visual identifier (ie visualIdentifier attribute) can be a thumbnail or a URI of a movie / audio track preview. Text identifiers (ie, textIdentifier attributes) can be used instead of or in addition to visual identifiers. The text identifier typically includes a string value that describes the descriptor. In the absence of a visual identifier, the media browser can build a visual representation based on this text value. These core attributes “drive” the media browser user interface. In other words, these are included for presentation.
[0043]
In addition to these visual attributes defined in the core schema, the preferred example is the W3C XLink standard under development (http://www.w3.org/TR/xlink) to provide linking semantics. Use the linking attribute). XLink provides a framework for creating both basic one-way links, such as HTML <A> linking elements, and more complex linking structures. Simple linking elements are a common linking requirement of the preferred example. These links are used to represent links between two descriptors (ie, metadata items) and links between descriptors (metadata) and content (eg, images, videos, etc.) be able to. XLink also provides other linking types such as extended links, locators, and arcs. A complete list of linking types can be found at http://www.w3.org/TR/xlink.
[0044]
The presence of a link using XLink is asserted by the XLink linking element. These elements need to be understood by the application in order to provide proper display or behavior. XLink uses name spaces to achieve link recognition. The XLink namespace used by the preferred example has the URI http://www.w3.org/1999/xlink and is associated with the xlink prefix. This association is achieved using the XML xmlns attribute (eg, xmlns: xlink = 'http: //www.w3.org/1999/xlink'). The XLink namespace provides a definition of global attributes that can be used for elements contained in any namespace. These global attributes (xlink: type, xlink: href, xlink: role, xlink: title, xlink: show, xlink: actuate, xlink: from, xlink: to) make the element recognizable as a linking element. Can be used. For example, for a specific element, if the value of the xlink: type attribute is set to “simple”, the element is treated as a simple link element, and the target of the link is set to the value of the attribute xlink: href. included. For purposes of this description, the definition of linking attributes using an XML schema is included in Example B below.
[0045]

[0046]
In a particular schema, core XLink attributes and media browser attributes can be used when declaring the schema's individual descriptors. In Example C below, specific descriptors VideoClip, Date, and Photographer are declared with a specific schema. Note that only a portion of the actual schema is shown, and references to the media browser namespace and the XLink namespace are assumed via the namespace prefixes mb and xlink, respectively. In the XML schema, these namespace prefixes are assigned using the xmlns attribute of the XML schema language. Media browser attributes are referenced unchanged from their definition for TOCDescriptorAttributes, as seen in line 21 of Example C. However, one of the referenced XLink attributes, such as that found in row 24, has been further redefined from its original definition. For example, the VideoClip descriptor is a simple linking element, so the value of the xlink: type attribute is a default value of “simple”. For simple links, the element (descriptor) is the link source and there must be a single link end. This single link end is represented using the xlink: href attribute. In order for a simple link to be valid, the value of this attribute must be supplied (thus the use constraint of this attribute is set to “required”). Also note that the xlink: href attribute of the VideoClip descriptor defaults to “resource” (ie, the link target must be assumed to be the item of content being described).
[0047]

[0048]
A description conforming to this particular schema fragment may include the fragment of Example D.
[0049]

[0050]
In the preferred example, the core media browser attributes are explicitly expressed in a schema and / or description. In the alternative, these attribute values can be inferred from other information in the description, as described below. For example, a descriptor / element can be treated as part of a TOC if it contains any links in its attributes or its child attributes. Furthermore, descriptors that do not have descendant links can be treated as index descriptors. Similarly, visual identifiers can be automatically constructed from element (descriptor) names. The method for inferring these attribute values is described in detail later in this section.
[0051]
Clearly, there are alternative forms that can represent the core media browser and xlink semantics. For example, using an XML schema, a core Descriptor type can be defined and a TOCDescriptor type and an IndexDescriptor type can be derived from the core type (see Example E below). In that case, individual schema definitions can extend these basic types to provide implementation-based descriptors such as those defined in Example C. In the preferred example, an XML schema is used as the schema expression language, but another schema language having appropriate expressive power may be used.
[0052]

[0053]
[Interpretation of metadata]
In practice, all of the metadata that the user wishes to visualize using the media browser 101 does not explicitly use the media browser 101 and XLink attributes described above. When parsing the new description, the media browser 101 first attempts to identify the type of metadata received, examples of this type include the Dublin Dublin for images, each of which is a metadata standard known in the art. Can include Core, MPEG-7 or DIG35. Typically this can be accomplished by examining either the root element declaration or the namespace declaration of the description. When the media browser 101 identifies the metadata standard, the media browser 101 uses the XSLT stylesheet to convert the input document tree (description) into one that explicitly uses the media browser attribute and the XLink attribute. To do. No further processing is necessary. In other words, this transformation provides a description that the media browser can present without further processing.
[0054]
For all other descriptions, a check is performed to attempt to ensure that the preferred media browser attributes are present. If they do not exist, the preferred embodiment uses a list of rules for creating appropriate media browser attributes for the input metadata. The rules are as follows:
(I) The href attribute is assumed to represent the target of a simple link and is represented as an xlink: href attribute. If the link target value is a URI with an XML extension or no extension, assume a link to another description (ie, set “description” in xlink: role), otherwise Assumes that the link is a link to related content (ie, sets “resource” in xlink: role). Assume that the link type is simple (ie, set xlink: type to “simple”).
(Ii) An element is classified as a TOC descriptor if it contains a link in either the descriptor or any of its children (ie, set TOC to “TOC” in mb: descriptorType). A link may be represented as element content or an attribute in the original metadata. An element that is not classified as a TOC descriptor is assumed to be an index descriptor.
(Iii) If the descriptor does not have visualIdentifier or textIdentifer, create a textIdentifer using the value obtained from the attribute if the name attribute of the descriptor exists, otherwise from the element name. In this regard, it is preferable that the media browser 101 always displays a visualIdentifier if it exists, and otherwise uses a textIdentifer.
(Iv) If the descriptor contains an attribute with a name indicating that it may be able to act as a visualIdentifier (eg keyFrame, thumbnail, preview, etc.), the value of that attribute is used to determine the visualIdentifier attribute Create This rule can be implemented by checking each attribute name against a list of possible visualIdentifier names.
[0055]
Although the above list has only four rules, it should be appreciated that alternative rules and / or additional rules can be developed to provide a meaningful interpretation of unknown metadata types.
[0056]
However, the use of XSLT stylesheets is a desirable approach because the a priori knowledge of the metadata format allows stylesheet creators to define information-based transformations. For example, the value of the visualIdentifier attribute can be obtained directly from the value of another attribute. An example of the conversion of arbitrary video metadata into a form usable by a media browser based on a subset of known extended Dublin Core attributes is shown in FIG.
[0057]
In FIG. 15, the source description and the converted description are shown as an XML element node tree, and the attributes are shown in the box to the right of the corresponding node. Elements are represented using ellipses. Thus, for example, in the source description 1580, the VideoDocument element 1500 has five attributes 1502, namely DC.Title, DC.Creator, DC.Subject, DC.Type, and href. The notation {att_name} is used to represent the value of the attribute of the corresponding element in the source document with the name att_name. Avptr notation is a method of addressing in audiovisual content using XPointer fragments. For example,
http: //../AusWild883.mpg#avptr (time :: 2: 05.00,2: 55.20)
Refers to a fragment of the audiovisual content AusWild883.mpg, where the fragment starts at a position of 2 minutes 5 seconds from the beginning of the content and ends at 2 minutes 55.2 seconds.
[0058]
The XSLT transform 1528 of FIG. 15 is constructed using the syntax and semantic knowledge of the source description 1580 for a video document element 1500 having a plurality of attributes 1502 (eg, DC.Title). For example, in the illustrated transformation, the value of the DC.Identifier attribute of the attribute set 1510 of the source Scene elements 1504, 1506, and 1508 and the DC.Identifier attribute of the attribute set 1518 of the Shot elements 1512, 1514, and 1516 are: Assume that it is merely a reference identifier and does not provide additional information. For this reason, this conversion uses these references as the value of the mb: id attribute. If these identifiers convey meaning to the metadata user, these attributes can be converted into an index descriptor, for example, as a DC.Description attribute 1544 of a Scene element. Also note in FIG. 15 that the descriptor being transformed does not maintain the initial frame granularity of the source description. In other words, the normalized description 1530 does not include a Frame description like the source description 1500. This typically represents a decision made by the designer of style sheet 1528 that operates using knowledge of media browser interface 101.
[0059]
In the example of FIG. 15, converting a description that uses elements to represent a structure and uses attributes to represent a property into an element tree may initially seem counterproductive. However, the concept of which information should be represented as attributes and which information should be represented as elements often varies with media type, as described above. Thus, conversion of source metadata into an element tree is a form of metadata normalization, and thus conversion 1528 results in a normalized description 1590 that can be processed and presented by the media browser 101.
[0060]
The source description 1580 is the XML document described in Appendix 1. If there are related schemas, the media browser 101 does not attempt to convert those schemas. As a result, the transformed description does not conform to the schema and therefore cannot be annotated. This is highlighted in the converted description by setting the updateable attribute of the media browser 101 to false in the root element 1532 of the converted description 1590. The XSLT stylesheet used to achieve transformation 1528 is shown in Appendix 2.
[0061]
III. Metadata server
A link to the metadata server 212 is expressed using a URI. An expression describing the request is appended to the URI that uniquely identifies the metadata server 212. For example, the URI: http: // somesite / myMetadata / Svr? <Query_string> has an identifier component that is the portion of the URI before the question mark symbol and a request component that carries information about the request sent to the metadata server 212. . The identifier component is itself a URI.
[0062]
In the preferred example, the identifier portion of the URI is first used to interpret the link by locating the metadata server 212 on the network 102. Failure to identify the metadata server 212 results in a failed link and can notify the user of the media browser 101 that the running process could not be detected. In a preferred example, the metadata server 212 must be running as a process, and the processing executed by the metadata server 212 cannot be started from the media browser 101. In the alternative, the media browser 101 may be configured to initiate one or more metadata server processes.
[0063]
When the identified metadata server 212 receives the request, the server 212 interprets the request and responds with an XML description that satisfies the request. This description is preferably sent as XML, but the description can be encoded if desired or necessary. The types and elements used for the description are preferably defined in a schema that the media browser 101 can access. The description is not validated against those schemas by the media browser 101 in the illustrated example, but the media browser 101 prefers to have access to the schema. If the schema is not available, some media browser features may not be available. The schema types and elements used by the metadata server 212 are preferably derived using the core attributes defined in Section II above.
[0064]
Requests directed to the metadata server 212 may relate to metadata required for browsing or search expressions. The request can also specify various parameters that control the delivery of XML to the requesting media browser service.
[0065]
The result of the request directed to the metadata server 212 is a description that is preferably contained in one element, either of type MetadataCollection or a type derived therefrom, an example of which is shown in Example F below. The MetadataCollection type provides a means for the metadata server to explicitly return information to the requesting media browser application or service (eg, the number of items that satisfy the request and the number of items that are actually returned in the description).
[0066]

[0067]
Before explaining the details of the request syntax, an overall processing model of communication performed by the media browser 101 with the metadata server 212 will be described with reference to a flowchart of FIG. First, in step 300, the metadata server 212 is identified from the URI. Thereafter, in step 301, a request is transmitted to the identified metadata server 212. Specifically, what is done in the preferred example is that the URI containing the metadata server request is retrieved using HTTP. In other words, steps 300 and 301 are executed as a single process. The system then waits for a response at step 302. A check is performed at step 303 to see if a response has been received. Otherwise, in step 304, the waiting period is compared with a predetermined timeout, and if the waiting period does not exceed the timeout, control is returned to step 302. If the waiting period exceeds the timeout, an error is reported to the media browser user at step 306 and the process ends at step 310 (ie, the metadata server 212 was not reached for some reason).
[0068]
If a response is received at step 303, the media browser 101 checks the response. If the media browser 101 cannot process the response (eg, the response is not configured correctly), an error is reported at step 306 and the process ends at step 310. If the response can be processed (ie, analyzed), the response is passed to the appropriate module in the media browser 101 for further processing, and processing ends at step 310.
[0069]
The syntax of the request will now be described in detail.
[0070]
Typically, most legacy databases store metadata in relational databases and access these databases using standard query language (SQL). On the other hand, the XML document, and thus the media browser 101, expresses information (metadata) in a hierarchical form. The metadata server 212 request must provide a bridge between the two different representations. If the request is based on SQL, the metadata server may be easy to implement, but the media browser 101 uses XML-related technology. Specifically, the metadata server request is based on W3C Recommendation XPath Version 1.0, which can be found at http://www.w3.org/TR/xpath. It is also possible to use the new W3C standard XQuery.
[0071]
XPath provides a very understandable way of describing the class of nodes being processed. It is declarative rather than procedural and uses a simple pattern syntax modeled after directory notation. The most common form of XPath expression is a location path. In the location path, a set of nodes relative to the context node is selected. The location path can be absolute (starting with “/” representing the root node) or relative (relative to the context node). For example, the expression book / author is a relative location path that selects all author children of the book child of the context node. The XPath syntax is most easily understood by example, and several examples are shown at http://www.w3.org/TR/xpath. Examples of multiple XPaths are shown below.
(I) / * selects all children of the root node
(Ii) The second section of the fifth chapter of doc is selected by / doc / chapter [5] / section [2]
(Iii) * / para selects all the para grandchildren of the context node
(Iv) para [@ type = "warning"] selects all para children of the context node that have a type attribute whose value is warning
(V) chapter [title = "Introduction"] selects the chapter children of the context node that have one or more title children having a string value equal to Introduction.
[0072]
XPath's location path syntax can be used directly for browsing request representation and structured queries. Use XPath functional notation to package unstructured queries (queries) as requests to the metadata server. This requires a more detailed understanding of XPath.
[0073]
The main syntax component of XPath is its representation. The representation is evaluated to create an object that is one of four basic types:
Node-set (unordered set of nodes with no duplicates)
・ Boolean (true or false)
・ Number (floating point number)
・ String
The location path is a special case of the XPath expression as described above. The location path returns the set of nodes selected by the path. A portion of the location path enclosed by square brackets “[]” is called a predicate. A predicate is an XPath expression that itself returns a Boolean result that serves to filter the selected node set with respect to the defined axis of the location step (the tree relationship between the selected node and the context node).
[0074]
An expression can also be a function call, and a function optionally takes an argument. The EBNF (Extended Bacchus Normal Form) definition of the function call is taken from Section 3.2 of the above referenced W3C Recommendation at http://www.w3.org/TR/xpath. An example of such a representation is shown.
[0075]
FunctionCall :: = FunctionName '(' (Argument (',' Argument) *)?) '
Argument :: = Expr
Note that this production Expr is the basic building block of XPath. There is a core function library that must be implemented by the XPath embodiment. Each function in this library is specified using a function prototype giving the return type, function name, and argument type. There is no core function that can be used to pass requests to execute unstructured queries, but extending XPath by defining user functions is simple.
[0076]
Thus, the request syntax is based on XPath and has the additional functionality of specifying parameters that control the transmission of metadata to the media browser. Its syntax is detailed below using EBNF.
[0077]

Request includes a single XPathExpressione followed by an optional ParameterList. XPathExpression is a function call with an additional predicate expression
Functtion: Boolean query (unstructuredQuery)
The XPath Version 1.0 production LocationPath described at http://www.w3.org/TR/xpath, except that it must be supported.
[0078]
This function can be included in the location path and can be used to request that the metadata server 212 pass unstructured queries to the search engine associated with the database 210. For example, the location path / Lifestyles / images [query ("surfing")] therefore finds by the metadata server 212 all images that are children of the Lifestyles node that satisfy the unstructured query "surfing". Is interpreted as Note that the representation unstructuredQuery must be properly encoded for inclusion in the URI. A suitable encoding is specified by Network Working Group Request for Comments (RFC) 2396, available from http://www.ietf.org/rfc.html.
[0079]
Both Nmtoken and Digit described above are defined in the XML Version 1.0 Recommendation (see http://www.w3.org/TR/1998/REC-xml-19980210).
[0080]
The ParameterList component of Request is optional. The ParameterList includes optional individual productions, MaximumItems, StartItem, NumberLevels, and TransactionID, which specify a maxItems parameter, a startItem parameter, a noLevels parameter, and a requestID parameter, respectively. If none of these parameters are specified, the media browser 101 uses default values.
[0081]
The parameter maxItems points to the maximum number of items returned by the metadata server 212. Thus, for example, if a particular section of the collection contains a large number of items, the media browser can first request, for example, (n = 101) items. The default value is specified by the user in the media browser 101. This parameter is automatically inserted into the Request by the media browser 101. If the user does not specify a value, the system default is used (eg maxItems = 100).
[0082]
Using the startItem parameter, the media browser 101 can start with the specified item number and obtain the next n items. The startItem parameter is useful when retrieving a search result from the metadata server 212. If this is not specified in the URI, a value of “1” is assumed by the metadata server 212.
[0083]
The parameter noLevels allows the media browser 101 to define the structure of the returned description. Typically, a single (hierarchical) level of description is required, but a higher number of levels may be desirable when a user requests a particular view (eg, video scene and clip) that includes multiple levels of hierarchy. is there. If this parameter is not specified, a value of 1 (hierarchy) level is assumed.
[0084]
The requestID parameter allows you to express a request that references a previous request as an expression. For example, it may be desirable to obtain the next set of items from the results of a previous request. If requestID is specified, the metadata server 212 attempts to respond using the previous request identified by requestID. If the request identified by requestID is no longer available in the metadata server 212 cache, the processing associated with that request must be repeated. The requestID is a unique value for the metadata server 212 and is generated by the metadata server 212 (can be based on a time stamp representing receipt of a request by the metadata server 212). The requestID can be returned to the media browser 101 using an element having a type MetadataCollection (see Example F) or a type derived from that type.
[0085]
[Browsing request]
In one embodiment, the default Request used when initially obtaining a browsing entry to the metadata collection for browsing is the XPathExpression, “/ *”, and the desired parameters formatted in the ParameterList (eg, “/ * & maxItems = 100 & noLevels = 2 ”). The corresponding URI is as follows:
[0086]
http: // mySite / myMetadataSvr? / * & maxItems = 100 & noLevels = 2
Here, // mySite / myMetadataSvr is the URI of the metadata server process.
[0087]
When receiving this request, the metadata server 212 invokes a procedure to satisfy the request. This procedure results in the dynamic generation of an XML description of the associated metadata collection. This description thus reflects the structure by which the associated metadata collection can be browsed. It is common to store metadata collections in some form of database. For example, the metadata server 212 can be configured to provide a category or publisher section of the collection so that the user can more easily browse the metadata. Typically these categories are reflected in the schema used to describe the database items. Instead, the metadata server 212 can respond to requests from the media browser 101 by simply sending all lists of separate items in the database.
[0088]
To illustrate normal use scenarios, consider an image metadata database with the following structure: As shown in FIG. 7, this database includes a plurality of categories including Lifestyles, Sports, and Animals. The Lifestyles category has no further structure (ie it consists only of images), but the Sports category is further structured into subcategories, the Animals category is further structured into subcategories and then into image classes. Structured. For the purposes of this description, it is immaterial how this data is actually stored.
[0089]
There is no fixed way in which the metadata server 212 can perform its conversion function on its metadata collection. One possible form is described below.
[0090]
The metadata server 212 generates a description based on the XML schema definition of the types of Category, Subcategory, Class, and Image. Typically, these schema definitions exist within a single XML schema document. In these definitions, it is preferable to use the media browser 101 attribute and the core attribute of the global XLink attribute (see Section II above). A basic example of such a definition is shown below in XML Schema Example G. By definition, the xlink: show attribute is used to “embed” the link target on the source side in the media browser 101 (ie, the description fragment generated by the metadata server 212 is simply included as the content of the link source element. Note that you can instruct By definition, these attribute values can also be set to “replace”, in which case the media browser 101 replaces the descriptor that is the link source with the description fragment supplied by the metadata server 212.
[0091]

[0092]
The schema document of example G includes a declaration of ImageLibrary, a root element that extends the MetadataCollection type (see example F) defined for the media browser (mb) namespace. This therefore inherits all of the attributes defined for the base type (ie descriptorType, requestID, noItemsIdentified, noItemsReturned, and startItemRuterned). In addition, ImageLibrary is defined to contain any of the descriptor lists: Category, SubCategory, Class, or Image. What is actually returned by the metadata server as the content of this root element depends on the received request.
[0093]
This schema document also includes declarations of TOC descriptors: Category, SubCategory, Class, and Image. Each of these descriptors includes an attribute group TOCDescriptorAttributes (from the mb namespace, defined in Example A above) and a set of linking attributes (type, href, role, and show from the xlink namespace) Defined.
[0094]
In this example, unless the defaults for the type, show, and role attributes are overwritten in an instance (eg, an XML document generated by the metadata server in response to a request), “simple”, “new”, and Becomes “resource”. Thus, for example, the default value of the xlink: show attribute needs to be overwritten if a link to another metadata server request must be included. In this case, the desired value of this attribute is typically “embed”, which allows the recipient of the generated description to use the element content description as a child element of the descriptor that contains the link source to the metadata server. Instructed to embed. It is also possible to set the value of the xlink: show attribute to “replace”, which means that the element content of the generated description must be replaced with a descriptor containing the original link to the metadata server. means. The default value of the xlink: show attribute can be used when the link to the resource is real. In this case, the user wishes to display the resource in a new window (thus the word “new” is used for the default value).
[0095]
Also, the generated description must overwrite the value of the xlink: role attribute when the purpose of linking is to link to another description. In this case, “description” must be set as the value of this attribute.
[0096]
Each of the declared descriptors of Example G inherits the visualIdentifier attribute (from either the TOCDescriptorAttributes group or the IndexDescriptorAttributes group). This attribute is used by the media browser 101 to provide a visual representation of the item's content. For example, when the item is an image, the visualIdentifier attribute value usually includes the URI of the thumbnail of the image. For categories, subcategories, and classes, the visualIdentifier attribute value can include the URI of the icon. If this attribute is not specified, the media browser 101 will either from the supplied textIdentifier attribute value, or if this value is also not supplied, from the name of the element (in this case, Image, Class, Subcategory, or Category) Preferably, a visual identifier for the item is generated.
[0097]
Upon reception of the “/ *” Request, the metadata server 212 generates an XML description of the collection as in the XML fragment of Example H below. This description is contained in an element declared to be of type MetadataCollection (see Example G), which includes a link back to the metadata server for the next description. Note that the metadata server need only specify XPathExpression on this return link. It is the media browser's responsibility to add the ParameterList to the URI before dispatching the request.
[0098]

[0099]
In Example H above, the description XPathExpressions of the return links to the metadata server 212 is used to identify links to each of the images in the Lifestyles category and in the subcategories of the Sports category and the Animals category. These links are activated when the user chooses to expand one of the above items when the above items are visually presented in the media browser 101. In the previous description and the following description, XPathExpressions is specified as a relative location path, assuming that the context node is the root node of the collection. Instead, absolute paths can be used.
[0100]
In example H above, the URI target for the return link to the metadata server 212 includes the “[” and “]” characters. In general, according to RFC 2396, it is unwise to leave these characters unencoded in the URI, as these characters may be rejected by some gateways and transport agents. These characters are left unencoded in this example and in the following examples for readability.
[0101]
For example, when the XML fragment shown in Example H is processed and presented to the user, a corresponding return link to the metadata server is invoked if a visual identifier of the “Sports” category is selected. The metadata server 212 responds to this link by generating and returning the description fragment shown in Example I below.
[0102]

[0103]
The returned description is preferably formed appropriately. Furthermore, the returned description must be parseable by the media browser 101. The action of the media browser 101 when the link content is received depends on the xlink attribute show described above. Normally, this attribute is set to “embed”, in which case the received description is embedded in the link source. If the received description uses a container element (eg of type MetadataCollection defined in Example F), this element is also embedded. The embedded container element is preferably defined as having a descriptorType value of “Other” (see Example A). Instead, as previously mentioned, the xlink: show attribute can be set to “replace”, in which case the link content is replaced with the element containing the link source. If the xlink: show attribute is not included for a link element in the description generated by the metadata server, the default action is “new”. This means that the contents of the link are displayed in a new window. Obviously, this is more desirable behavior for content (ie resources) than description.
[0104]
The description of the collection can be further utilized by the user selecting one of these subcategories. As a result of this action, the metadata server 212 generates a description of the image included in the selected subcategory.
[0105]
Note that the description of Example I is dynamically generated by the metadata server 212, but this description includes only a single hierarchy level. This can be changed by specifying the noLevels parameter in the URI ParameterList. In some cases, a Request may require a two-level hierarchical description to generate a view that requires both parent and child TOC elements. For example, if the media browser 101 uses a two-level view and wishes to retrieve a description that includes a two-level TOC hierarchy, the media browser 101 adds a “nolevels = 2” parameter to the URI. For example, link

Yields the description fragment shown in Example J below.
[0106]
The second level is assumed to be the TOC child of the level that is the target of the link. When the value of noLevels exceeds 1, preferably the values of parameters maxItems and startItem must refer to the lowest TOC level of the description. Similarly, the value of the parameter returned refers to the lowest level of the description. It should also be noted that the child of the lowest TOC level Index descriptor can also be included in the returned XML shown in Example J below.
[0107]

[0108]
Search request
A search request may originate from either a user who specifies a structured query using the advanced search option or a user who specifies an unstructured query using the simple search option. The term “structured” query is used herein to mean a query consisting of a set of constraints expressed in terms of known properties of an information source. These constraints can be combined in an associative (logical product) or disjunctive (logical sum) form or a mixture of the two. The term “unstructured” query is used herein to mean a query consisting of a list of keywords and expressions, with or without binding (eg, Yahoo! ®, AltaVista® (registered) Type of query used by most search engines, such as The main difference between the two query types is that structured queries are expressed in terms of information source knowledge (eg, metadata database schema).
[0109]
If a structured query is formed, this query is preferably expressed using XPathExpression, and the constraints are expressed as location step predicates as described in the previous section for browsing. Therefore, only unstructured queries need to be considered in this section.
[0110]
Most metadata collections that currently exist have unstructured search functions. In many cases, considerable effort has been expended to make this search function as optimal as possible in terms of speed and reasonable results. As a result, it is advantageous to use these search functions whenever an unstructured query is specified by the user.
[0111]
Unstructured queries can be passed to the metadata server 212 using the query function calls previously defined in this section. This function call is preferably included in the location path step predicate. Since a location path can contain predicates for each of its location steps, an XPathExpression can contain multiple unstructured query expressions. However, most requests based on unstructured queries contain a single query expression. For example, the XPathExpression // image [query (“dog OR cat”)] selects all image items that are descendants of the root node and satisfy the query “dog OR cat”. Note that an XPathExpression needs to be properly encoded before it can be dispatched as part of a URI (see RFC 2396). For example, a white space character must be encoded using the character triple% 20.
[0112]
Typically, a search can result in a large number of items. The description returned to the media browser 101 can be limited by using the maxItems parameter with respect to the number of items included in the description. After receiving the first set of results, the media browser 101 can request the next set by using the startItem parameter. To do this, the media browser 101 includes the requestID returned by the metadata server 212 along with the response to the original request. In other words, the returned requestID identifies the start of a transaction that can be accessed by a later request.
[0113]
The above has a plurality of meanings related to the configuration of the metadata server 212. This is because such a request requires that the metadata server 212 can store and access the results of previous requests. However, traditional server examples cannot keep the result of a request in the cache indefinitely. When a request arrives that references a previous request, the metadata server 212 preferably attempts to match the requestID with the request result stored in its cache. If the request is no longer in the cache, reprocess it. In an alternative example, if a match cannot be achieved, the metadata server 212 optionally attempts to match the request with other requests based on textual similarity before reprocessing the request. be able to. This technique is useful in that large and duplicated processing by the metadata server 212 can be eliminated. Accordingly, the cache size of the metadata server 212 can be implementation-dependent.
[0114]
IV. Media browser application
Media browser 101 provides users with a single user interface for browsing and searching different metadata collections. An example graphical user interface 400 of the media browser 101 is shown in FIG. The media browser interface 400 gives the user the option of either browsing or searching for content (specific items) via metadata associated with the content (items). The media browser 101 can be implemented as a stand-alone application (eg, Word 97 manufactured by Mivrosoft Corporation, USA) or as a service that can be provided to multiple concurrent users. In the preferred example, the media browser 101 is implemented as a service. In this mode, each user is required to log into the service in order to access their personalized TOC. The service mode of the media browser 101 is further described in Section V below. This section is devoted to describing the functionality of the media browser 101. This description assumes a media browser service, but it is clear that its functionality can be equally well implemented as a stand-alone program.
[0115]
Typically, the media browser 101 is implemented with a default set of media tool plug-ins. Users of the media browser 101 can select additional media tools that are plugged into their own implementation, preferably downloaded via the Internet. Each plug-in has a defined set of target media types. Separating media playback / display from metadata browsing and retrieval is an important concept of the media browser 101. This is because it allows the application to be adapted to a specific user / environment.
[0116]
The media browser 101 provides browsing access to metadata by providing a Table of Contents (TOC) that represents the structure of the information landscape that the user has chosen to access. This information landscape can include a link to local metadata, a link to remote metadata, or both, and the information landscape is usually used when a user discovers a metadata site related to personal interests. Customized by each user. A default TOC is preferably provided for each new user.
[0117]
The underlying information landscape is represented as a description (ie an XML document) at all levels. This is because, in the case of XML, the basic structure of the description, which is a tree containing nodes and links, displays details of the multimedia item description of the content (eg digital video) or whether the user is displaying the entry point of the TOC. Means the same regardless of whether Since the TOC is a visual representation of the information landscape, the user's navigation within the TOC is not changed for all levels of the TOC. This may be because the interface 400 is browsing the metadata for different websites, browsing metadata for different sections of the metadata collection (eg, category of image metadata collection), or multimedia content (eg, Means the same regardless of whether you are browsing the metadata in the description of the clip in the digital videotape).
[0118]
The TOC is formed by items that can be selected. These items include a visual representation of the TOC descriptor (see Section II for details on metadata representation). The item includes a visual identifier to help the user during browsing. A visual identifier typically represents content in some form. This is especially true for visual identifiers corresponding to items of multimedia content. Examples of visual identifiers include simple text, graphically designed text, image thumbnails, animations, and short video previews. These visual identifiers are preferably supplied by the description; otherwise, the media browser 101 may generate them graphically from information (eg, textIdentifier attribute or element name) contained in the description. it can. Visual identifiers are described in detail in Sections II and III.
[0119]
The browsing functionality provided in the preferred example will now be described with reference to FIG. When activating the media browser 101, an initial description of the information landscape is read in step 500. This initial description typically includes a set of top level links to different metadata collections or sections of metadata collections. The media browser 101 then processes this description at step 501 and builds the first TOC from the description. Typically, the description processing includes analysis of an XML document containing the description and presentation of the description using an object model in computer memory. Step 501 preferably includes detecting all TOC descriptors from the description and creating a TOC from these descriptors. The distinction between the TOC descriptor and the index descriptor is preferably performed using the core descriptorType attribute described in Section II.
[0120]
In the next step 502, a view of the first TOC is generated and presented to the user. This view can be provided in the form of a tree structure used by applications such as WINDOWS EXPLORER manufactured by Mivrosoft Corporation. The rectangular panel 402 shown in FIG. 4 is preferably provided to show the visual identifier 404 corresponding to the first level item in the information landscape. For example, this can be a grid of visual identifiers that identify multiple initial metadata collections.
[0121]
The media browser 101 then waits for a user event. At step 503, when the user selects an item, for example by clicking on the visual identifier 404, at step 504, the corresponding descriptor is examined to determine if it has a child TOC descriptor. . This may be the case when each description includes multiple levels of structure (eg, a collection description often includes multiple TOC levels within one description). If the item has a child TOC item, control proceeds to step 510 where the child item is used to update the view of the TOC.
[0122]
If the selected item does not have a child TOC item, in step 505, the media browser 101 determines whether the item includes a link to the description. This can be achieved explicitly if the linking element representing the source of the link has a specified role of “rescription” (the role of the linking element has been described previously). If the link role is not defined, the media browser 101 determines whether the target is a further description based on the file extension of the URI of the link target. For example, if the extension is “.xml”, the description is first assumed. However, when analyzing the “.xml” file, if it is found that the file does not conform to the specified description schema, the media browser 101 treats the “.xml” file as a resource instead of a description. Is preferred.
[0123]
If the selected item includes a link to a further description, step 506 is performed, in which the media browser 101 can use the specified description in the description cache (ie, Determine if the description was previously retrieved, possibly for another user or for a previous session with the current user. If the description is not available, in step 507, the media browser 101 retrieves the description. This can be accomplished by forwarding an HTTP get request to a standard web browser. In step 508, the returned description is processed and stored in the description cache. In step 509, the TOC is updated to reflect the new description, using the same principles used in creating the first TOC. Finally, at step 510, the TOC view is also updated and presented to the user for further interaction. After step 510, control can return to step 503 to make further selections from the TOC.
[0124]
The browsing event described in the previous paragraph preferably results in the viewing panel being updated to include a new level of items in the information landscape. For example, at this new level, the main categories of a particular metadata collection can be shown.
[0125]
In step 505, if the selected item does not contain a link to further description, the link is treated as a link to the content item. At step 520, the visual identifier of the item is highlighted, and at step 521, further actions can be taken. For example, an identifier can be selected along with a number of other items and dragged to the stack 406 or shopping basket 408 that forms part of the interface 400. When a link to an item of content is double clicked by the user, the item is immediately presented or played using the default media tool for the content type of the selected item.
[0126]
In the preferred embodiment of the media browser 101, two types of searches are possible. A simple search is constructed by the user providing a text query in the search input box 410 and selecting the simple search function 412. The user can also construct an advanced structured query using a list of available index descriptors by selecting advanced search 414. The latter option is possible because the media browser 101 has knowledge of the schema used for the different descriptions. The media browser 101 can build a list of index descriptors associated with one or more selected descriptors, and the user can specify query constraints by entering the required values of the selected index descriptors Is preferred. It is preferred that the constraints entered by the user are combined in a combinatorial ("logical AND" manner), but obviously other alternatives (discrete combinations or a mixture of the two) are possible. The user must also be able to specify the type of constraint (eg, equal, less than, include, unequal). For example, if the user wants to search the image database for images issued by issuer "ABC" and having a cost in the range of $ 100 to $ 200, it can be used rather than just using keywords in the text query If a structured query can be constructed directly from a simple descriptor, the query is more likely to succeed. The latter approach corresponds to the simple search function described above, but may result in the strings “ABC”, “$ 100”, and “$ 200” placed anywhere in the image description. The processing of structured search queries is further described below.
[0127]
The preferred example search functionality of the media browser will now be described with reference to FIG. In an initial step 600, the user specifies one or more context items for the search. These are items in the TOC that are searched when the search is started in step 603. In step 601, it is determined whether the user has selected advanced search. If the user does not choose to perform an advanced search, control passes to step 602 where the user is requested to specify the text query described above. This query can be from a list of keywords or phrases that the user is interested in.
[0128]
If the user has selected to perform an advanced search, control passes from step 601 to step 620. A list of available index descriptors is generated from schema definitions and declarations related to any of the descriptions contained in the list of context items. In the preferred embodiment, the index descriptor is distinguished from the TOC descriptor by the descriptorType attribute described in Section II above. The user can express a structured query at step 621 based on a list of available descriptors and a set of basic search join operators (eg, AND, OR, and NOT). The user can represent an acceptable range for a particular index descriptor (eg, the item price must be greater than $ 100 and less than $ 200) and indicate the type of constraint (eg, equal or include) it can.
[0129]
In step 603, the user initiates a search using the current query (text or structured). After this, at step 604, the first item in the list of context items is identified. In step 605, a new thread or process is created and then started for the context item. In the next step 606, a check is made to see if the identified context item has an associated metadata server. If the context item is the origin or root for a particular metadata collection, step 606 includes checking for links in the description. If the identified context item is not the origin or root item, the TOC needs to be examined to establish whether a metadata server exists for the identified item's parent. If such an inspection results in the location of the associated metadata server for the identified item, the XPathExpression location path that carries the context of the identified item in the metadata collection to the metadata server as a request for a query. Include in For example, when the context item selected for the search is “Lifestyle category” in “Image Collection ABC”, the search request is passed to the metadata server with the following URI.
[0130]

Here, <expression> includes an unstructured query.
[0131]
If the associated metadata server is identified at step 606, then the query is expressed as a URI (using the request syntax described in Section III) and sent to the identified metadata server at step 608. .
[0132]
If no metadata server is identified at step 606, a search is initiated for items that satisfy the request in the context item identified at step 604, and control is transferred to step 609 to detect additional context items. . If there are more items, step 610 identifies the next item in the list of context items and returns control to step 605. If at step 609 it is found that there are no more context items to identify, control passes to step 620 and the search process waits for search results to arrive. In this regard, it should be appreciated that multiple search processes for individual context items may operate and return results at substantially the same time. When all threads or processes are complete, the results of the individual search processes are collated at step 625 and the process ends at step 630. In an alternative embodiment, results collation and display can begin before all threads are complete.
[0133]
In the preferred embodiment, the user's query (structured or unstructured) is passed unchanged to each of the selected contexts. In an alternative embodiment, valid queries forwarded to each of the contexts can be modified by the system to take into account the context's capabilities.
[0134]
A user can locate the multimedia content of interest using the browsing and search functionality of the media browser 101. The user can build a temporary collection of items by dragging the visual identifiers of the items onto the stack 406 shown in FIG. Stack 406 represents a collection of metadata references that can be saved as options and recalled in a later session. The stack 406 is treated like any other level in the information landscape in that it can be displayed in a viewing window and can be selected as a context item for search. The stack 406 can also be inserted into the information landscape under the “Stacks” heading of the entry TOC. The user can save the contents of stack 406 and then retrieve and use the saved stack 406 in a later session.
[0135]
If the content is desired immediately and online purchases are available, the user can drag the item to the shopping basket 408. Shopping basket 408 is an effectively specialized stack. In an alternative interface, the shopping basket 408 can simply be represented as such. At any time, the user can right-click on the shopping basket to initiate the “Purchase” plug-in media tool. Alternatively, the user can move the mouse over the shopping cart icon to display a menu of available media tools and make a selection from this menu.
[0136]
The “purchase” plug-in operates in the same manner as the media tool that provides the media display function and the media playback function described above. The user can select the appropriate “purchase” tool for that embodiment. The purchase tool simply looks at each of the items in the shopping cart 408 and establishes whether those items can be purchased online, and if so, redirects the user to the content provider / distributor site. Buy items. In an alternative configuration, the user can establish accounts for the media browser service, and the media browser service is further described in Section V to purchase items through these accounts.
[0137]
V. Media browser business system
The media browser 101 described in Section IV can be implemented as a service. In the preferred embodiment, the media browser 101 is technically implemented as a client-server application and operates as a service that allows a user to log in from the Internet. Each user is preferably securely identified by a password and can store data up to a specified limit for the service. This user data consists of the initial TOC description, user preferences, stored stack, and other information required for client operation (eg, user preferences, information about locally installed plug-ins, etc.). This service is preferably provided to the user for a periodic (eg monthly) subscription fee.
[0138]
As mentioned above, one of the main technical advantages of operating the media browser 101 as a service is that the description can be cached. Thus, for example, if company “ABC” installs a media browser service and many users of company “ABC” use a particular metadata collection, descriptions from this collection can be used in the service description cache. Become. In other words, a description need not be retrieved for each individual user. This represents a major advantage.
[0139]
In the preferred embodiment, the media browser service operates as a service linked to a standard web server. Thus, the media browser client can be implemented using a standard web browser. This means that the user can simply go to the media browser home page and start the client on the user's own computer workstation. The server usually runs continuously, like the standard web server of most websites.
[0140]
In the preferred embodiment model, the default media browser server is operated from the site of the main service provider (eg, a company that owns rights to the intellectual property rights of the technology). Other parties can purchase that right to install their own media browser service on their own intranet. Such an option may be desirable for parties who want to optimize the speed of service for their intranet users.
[0141]
A further advantage of the above disclosure resides in a business system centered on the concept of the metadata server 212. As described in Section III, the metadata server 212 provides a means by which a content provider / distributor can thereby make metadata stored in a legacy system such as an SQL database available. Thus, the ability of content providers / distributors to have a metadata server 212 that serves metadata collection effectively opens up a customer base. This is because potential customers can access their metadata from potentially many sites. In fact, each media browser client can potentially provide access to the content provider / distributor's metadata collection. This provides the benefit of increased sales and exposure.
[0142]
However, as with all websites that wish to introduce their products / content to the Internet public, potential customers need to know about the presence of the content provider / distributor's metadata server 212. To allow this to occur, when the content provider / distributor decides to be involved with the media browser / metadata server system 100, the content provider / distributor can receive a sample (customizable) from the primary media browser service provider. ) Download the metadata server. Using this, content providers have incorporated a specific translator to interface the XML schema format from the general platform to the database format used by the corresponding database manager to access the content provider's legacy database. You can modify the sample metadata server to the platform. One of the options for content providers when configuring the sample metadata server is to link their new “customized” metadata server to the default TOC entry distributed with all media browser services. Is to choose to include as This means that a link to the new metadata server appears in the primary service of the primary media browser service provider and is distributed to each of the secondary services using the media browser software. This results in direct advertising of content provider products. Clearly, users can customize their own TOC when they begin to handle the media browser service. However, the first presence of a link on the entry TOC introduces the metadata collection that is made visible to the user through the newly linked metadata server.
[0143]
In choosing to include a link to their metadata server in the standard TOC, content providers / distributors will be charged a specific fee for each amount of request that their metadata server processes. You may agree. This fee can usually be very cheap (eg, US $ 1 for every 10,000 requests). The installed metadata server preferably has an integrated billing mechanism that is responsible for keeping a record of the number of requests and then periodically billing the content provider / distributor for services. The billed credit card number can be stored in a protected form in the metadata server, and billing is performed in an automated electronic form.
[0144]
In summary, the provision of a metadata server by the main media browser service allows content providers / distributors to provide enhanced services and mechanisms for advertising and selling multimedia content. The implementation of the metadata server effectively “opens” the content provider / distributor's metadata collection to a wider audience than an audience accustomed to simply visiting a search engine operated by the content provider / distributor. In addition, the metadata browser / server system makes metadata browsing / searching more attractive to potential customers. This is because the customer can perform these actions in a more convenient (ie, single interface) and time efficient (ie, in parallel with other metadata collection).
[0145]
The potential customer base is further expanded by taking the next step of effectively promoting their open metadata collection using media browser services. With regard to this major additional advantage, content providers / distributors promise to pay a small periodic fee based on the number of requests that their metadata server handles during the billing period. If only a few requests are processed, the cost charged to the content provider / distributor is low. This is an important advantage, especially for smaller content providers.
[0146]
FIG. 10 shows an embodiment in which the media browser server 152 described above is incorporated in the local server 150 and is available for use by a plurality of local users 154 to 156 connected to the local server 150. The local server 150 provides a connection via the Internet 102 between the users 154-156 and the plurality of content providers 160 and 170 and the financial facility 180. Providers 160 and 170 each incorporate a content legacy database 164 and a corresponding store 166. Database 164 typically includes an array of tables that map references to content to content locations in store 166. A metadata server 162 is also provided and configured to receive a media browser request sent as a URI according to HTTP and generate an XML description that satisfies the media browser request. In this configuration, local users 154-156 having access to the media browser service 152 can access content without having or using specific knowledge of calls, commands or instructions specific to or associated with the legacy database 164. Remote access is possible. With such a configuration, the user 154 can access the content 166 in a manner that is transparent to the nature of the database 164 (eg, whether the database is formed using SQL or dbase). At the same time, the structure, organization, and search attributes and functions of the database 164 can be preserved.
[0147]
When performing a search for content across multiple content providers listed in the TOC 158, the local user 154 can be given a positive response, for example for each of the providers 160 and 170. At this stage, the owner of the local server 150 may send an invoice to each of the providers 160 and 170 for a fee related to “introducing” or facilitating local user 150 access to the content of each provider 160 and 170. it can. Spokenly, this can be considered a “watch-out fee” and is based on the number of searches that deliver the result, or the number of results delivered by the search, or simply the number of requests that the metadata server processes. Can be billed in multiple forms.
[0148]
If the local user 154 wishes to purchase content returned by the provider 160, the financial transaction does not affect the local server 150 between the local user 154 and the provider 160, possibly via the financial institution 180, and is affected by the local server 150. Without running. In an alternative approach, the local server 150 can be sandwiched as a financial intermediary, whereby the provider 160 charges the local server 150 for the purchase of content, and the local server 150 charges the local user 154. Such an approach can be more convenient and provides enhanced security with respect to transactions over previous billing and payment examples. For example, if it is desired to purchase content returned by a search session from multiple content providers 160 and 170, the local user need only perform a single transaction with the local server. Since these two parties have a pre-existing relationship, the user's identity can be mitigated rather than when the user purchases directly from a provider that may not have a relationship with it. The same issue applies to the relationship between local server 150 and providers 160 and 170.
[0149]
In the foregoing, examples and embodiments applicable for providing multimedia content have been described, but other products and services can also be provided. For example, in FIG. 1, link 118 points to a physical product rather than multimedia content that can be electronically downloaded from database 117, but the ability to query user database 117, obtain search results, And finally the ability to execute purchase transactions.
[0150]
Further, some embodiments may not have a commercial basis for a particular financial transaction. For example, patent offices worldwide can choose to make their own databases available to the general public. The media browser and server embodiments described above allow this to be done without the need for specially designed integration software such as web pages that allow user queries to be posted to multiple databases. This therefore allows the public access to the federation of distributed heterogeneous databases.
[0151]
VI. Customization for equipment
FIG. 11 identifies multimedia items that the user has authorized access to the media browser server 1102 for the purpose of browsing a communication network 1106 such as the Internet and that the user is interested in and may wish to duplicate. A multimedia access system 1100 is shown. Media browser server 1102 is associated with database 1104, which incorporates user-specific table of contents (TOC) data and a location that the user has previously visited or can use for review. Using the table of contents and media browser server 1102, the user can extract multimedia content through the metadata server 1108 associated with the corresponding content repository 1110 and metadata repository 1111.
[0152]
A user can access the media browser server 1102 via a desktop computer 1112 that substantially corresponds to the configuration of FIG. In such a form, the desktop computer 1112 has the ability to replicate most types of multimedia items, including video, audio, and images, each possibly supplied in multiple formats depending on its configuration.
[0153]
In such a situation, the table of contents provided to the user of the desktop computer 1112 may be shown as a table of contents 1114 that includes metadata relating to video, audio, and image content items. Each of these items can be presented in the table of contents 1114 because the desktop computer 1112 has the ability to replicate each of these data formats. As a result, these items can represent the entire user table of contents stored in the database 1104 of the media browser server 1102.
[0154]
However, according to this embodiment, when the same user operates an alternative device for browsing and delivering media, the table of contents presented to the user at the alternative device is the device that is currently used (ie, the alternative). It is modified so that only items of content that can be duplicated are presented. This is also illustrated in FIG. 11, in which a user operates a cellular telephone handset device 1116 that can connect to the Internet network 1106 via a cell phone base station and the public switched telephone network 1118. The cell phone handset 1116 can perform a browsing operation via the media browser server 1102 in this regard using an appropriate data format such as wireless application protocol (WAP).
[0155]
However, in this case, the cell phone handset 1116 has the ability to replicate only text on its display and a loudspeaker integrated therein or a headset device that is connectable to the handset 1106 known in the art. It has the ability to duplicate sound by using it. As a result, only audio items that can be text browsing (eg, using a text identifier rather than a visual identifier in the metadata) using the telephone handset and replicated using the loudspeaker of the handset 1116. The table of contents 1120 limited to can be displayed. For example, when the MP3 player module is incorporated in the receiver 1116, the audio component in the table of contents 1120 including the MP3 compressed data can be duplicated. In addition, audio encoded in other formats, such as 8-bit PCM or 16-bit PCM, can be replicated with bandwidth limitations from the “telephone” frequency band of 300 Hz to 3 kHz.
[0156]
Typically, the content requested by the user is stored on a content provider's site (eg, metadata server 1108). Instead, the content can be stored with the media browser service 1102 in a protected form. In such a configuration, whether the media browser server 1102 is a computer 1112 or a telephone 1116, the streaming of content to the device can be customized depending on the destination device being used at that time. Such customization can include bandwidth modification, coding, and any form of encryption.
[0157]
In such a form, the content can be browsed in the form of a preview before the user purchases the content. When satisfied with the preview, the user can choose to buy the right to access the content. With this right, the user is granted a single playback / display of a digital item, the right to play / display for a predetermined period of time, or an unlimited copy (CD or electronic) of digital content. When purchasing the right to use the content, the user can also specify the quality of service (QOS) desired for the purchased content (eg, number of channels, associated movie clips, etc.). After making a purchase, the QOS represents the highest QOS available to the user, regardless of the device used. This is because a lower QOS results when a user logs on to the media browser server 1102 from a device that cannot use the purchased QOS. An example of this is when a user purchases rights to copy CD quality audio using a desktop computer 1112. Later, while holding the telephone handset 1116, the user can select a duplicate of the previously purchased CD audio, but this CD audio is more suitable for the lower quality output of the telephone handset. There is a possibility of duplication with a low quality of service (eg telephone quality). Such a change in QOS can be detected by the media browser server 1102 according to the device connected at that time, so that the media browser server 1102 can apply a duplicate QOS applicable to the device currently in use. This results in extracting appropriate content via the metadata server 1108.
[0158]
In each of the above examples, the TOC supplied to the user is derived from the user's data in the repository 1104, but modified by the media browser server 1102 depending on the particular device being used at the time. It is. With such a form, the media browser server 1102 has the ability to detect the type of device connected to the server 1102 at any time, and content to that device in the proper format without delivery of extra information Guarantee delivery. Such a form is also desirable in reducing bandwidth consumed by data transfer across the system 1100 via automatically limiting user selection to content that can be replicated.
[0159]
VII. Control of rights to use
One of the problems associated with providing electronic multimedia content to a user is the extent to which the user can duplicate or copy that content for personal use or distribution. This is particularly important in the case of online sales of audio and video content and in the maintenance of copyright and the supply of royalty to artists and performers. Specifically, this problem becomes real after the user browses available content and purchases a content selection. Typically, purchases most often provide the right to use the content at a purchase price related to how the content can be used. Typically, content is a single playback or use of content, playback over a predetermined period of time (eg, 1 hour, 1 week, 1 year), indefinite use by a purchaser (user), and in some cases. May be provided with usage rights that vary to the right to distribute content that is either prohibited or not prohibited by further usage rights.
[0160]
A form 1200 that provides control over such usage rights is shown in FIG. In FIG. 12, a user's device 1202 accesses multimedia content via a media browser service 1206, and the content is a content provider that incorporates a metadata server 1214, a content repository 1216, and a metadata repository 1218 associated with the content. 1212. As in the previous embodiment, the user of device 1202 has metadata 1208 associated with the media browser service 1206 so that the metadata 1208 can retrieve content from content provider 1212 and deliver it to the user's device 1202. Link and control.
[0161]
At the time of purchase, a rich link to metadata from repository 1218 regarding stored content 1216 is forwarded to the user. The rich link can be described as metadata, but the rich link includes a link to the content and information about the stored content 1216 (for example, listing of program material), and is used for searching for the content. It includes metadata, access information that gives the user the right to use the content, and usage information. Access information is necessary so that the user can deliver / stream digital content to the user as needed. In this way, the user simply accesses the content via the media browser service 1206 whenever the content needs to be replicated rather than stored. Similar to the previous form, content can instead be stored using the media browser service 1206, in which case the service 1206 serves as a trusted service for the content provider 1212.
[0162]
Form 1200 can operate using either unencrypted content or encrypted content delivered to the user's device 1202. In either case, after purchase, a request 1226 to display or play the stored content 1216 is issued from the user's device 1212 and received by the media browser service 1206.
[0163]
In the case of unencrypted delivery, the access key 1230 is sent 1222 from the media browser service 1206 to the metadata server 1214 in response to the request 1226. The metadata server 1214 verifies the access key 1230 before delivering / streaming 1220 the stored content 1216. Content 1216 is preferably delivered to media browser service 1206 and from there to user 1202 in a device-sensitive form 1228 that is not encrypted in this case. Access key 1230 is preferably formed of two parts. The first portion is stored with the user's metadata 1208 as part of the media browser service 1206 and operates to identify the user and the item of content that the user has rights to access. Is included. The key portion 1210 can be a key value entered by the user at the time of purchase of the content 1216 and represents the equivalent of a personal identification number that allows access to the content and relates to a specific purchase of the content. Can therefore incorporate information about the user and the content to be purchased. Instead, the key portion 1210 can be automatically generated by the metadata server 1214. Another portion 1224 of access key 1230 may be specific to media browser service 1206. As a result, the access key 1230 is formed by an authenticated two-part key pair arrangement that results in delivery of content 1216 to the user's device 1202 upon receipt by the metadata server 1214, at which the user's device The content can be duplicated using a player 1204 that forms part of the device 1202.
[0164]
Note that the above-described (non-encrypted) method only ensures that the user is a valid recipient of the purchased content. The metadata server 1214 has no control over the user storing the content or the content being intercepted by other potential users after delivering the content.
[0165]
When sending encrypted content to a user, when the metadata server 1214 receives a valid access key 1230, the metadata server 1214 responds by sending 1220 the content 1216 to the media browser service 1206. . This delivery does not need to be encrypted. This is because in most embodiments, the link between the media browser service 1206 and the metadata server 1214 can be a permanent or other form of trusted connection. However, encryption can be applied for additional protection. In that case, the media browser service 1206 encrypts the streamed content 1220 using key information that identifies the user's current session and sends the encrypted content to the user's device. In this regard, the key information can be generated or generated from the identification (ID) supplied by the user's client device during request 1226.
[0166]
The player 1204 of the user device 1202 conditionally decrypts the content if it has a valid decryption key. This key can be key information used for content encryption. Alternatively, this key can be the private key of a public / private key encryption pair. The session ID can form part or all of the content decryption key. The requested time of streaming from the server 1206 may additionally or alternatively be used.
[0167]
This (encrypted) content delivery method provides protection at three separate levels. First, the content is delivered to the media browser server 1206 only when a valid access key is received by the metadata server 1214. Preferably, the media browser server 1206 checks whether the request is valid with respect to when set in terms of usage rights. That is, the media browser server 1206 checks for an expiration date before sending the access key 1230 to the metadata server 1214 of the content provider 1212. The media browser service can do this by examining the link to usage information. This requires usage information to be structured according to a predetermined schema. Instead, the media browser preferably sends the request and the metadata server checks the usage rights.
[0168]
Second, the encrypted content cannot be intercepted between the media browser server 1206 and the user's device 1202 because it is not played for another session or user.
[0169]
Third, since the content is decrypted conditionally by the player 1204, the content cannot be stored on the client side.
[0170]
Instead, the key information used to encrypt the content should include other information such as access key and expiration date obtained from the metadata of the right to use, and can be examined by the player 1204 It can be informational. For example, the biometric information can include, for example, a fingerprint or a voice key identification.
[0171]
VIII. Communication link between users
Often it is desirable for different users to be able to exchange links to content that they find interesting.
[0172]
FIG. 13A shows a configuration 1300 in which a media browser service 1302 is associated with a metadata server 1304 for provision of content 1306 to a user. The service 1302 incorporates a repository 1308 for each of a plurality of users. Multiple users 1310 and 1312 are registered with service 1302 and coupled to service 1302 by communication network 1380, which typically includes high-frequency components such as cellular links and microwave links in addition to wired land lines. A public switched telephone network (PSTN) that can be incorporated.
[0173]
The first user 1310 has a table of contents 1360 stored in the repository 1308, and similarly, the second user 1312 has a table of contents 1362. The table of contents 1360 of the first user 1310 includes a metadata item 1318. When the first user 1310 logs on to the service 1302, the TOC 1360 is duplicated 1314 at the user device and appears to include an image thumbnail corresponding to the item 1318. The metadata item 1318 provides content 1330 to be delivered to the first user 1310, and the received content 1330 is associated with a one year usage period, as indicated at 1320.
[0174]
If the first user 1310 wants to share content 1330 with the second user 1312 and has knowledge of the logon details of the second user 1312 regarding the service 1302, the first user may change his / her TOC 1314/1360 to TOC 1362. You can transfer metadata. This is illustrated in FIG. 13A by the transfer 1328 of TOC 1360 to TOC 1362 of metadata 1318 in repository 1308 to provide metadata 1322. However, since the second user 1312 has not purchased the content 1330, the right-to-use metadata associated with this transfer has been changed from "1 year use" to "1 playback / display" The second user 1312 is allowed only a single copy of the content 1330. Upon subsequent logon by the second user 1312, the TOC 1362 is loaded into the user's device and the metadata 1322 is shown as a TOC 1316 that is presented in the TOC 1316 inbox.
[0175]
FIG. 13B shows a configuration 1390 that is similar to FIG. 13A and relates to a corresponding device having similar functions with corresponding functions. However, the form 1390 of FIG. 13B provides for wireless communication of metadata 1318 from the first user 1310 to the second user 1312. In this configuration, each user device is provided with a transmitter 1340, 1344 and a complementary listener (receiver) 1342, 1346, thereby enabling the user device to use wireless communication such as RF or IR. Two-way direct communication. In this manner, the first user 1310 can transfer metadata 1348 from the TOC 1314 via the transmitter 1340 for reception by the listener 1346, and the listener 1346 is dedicated to transporting metadata to the TOC 1316. Can do. From there, the network connection 1380 allows the second user 1312 to update the TOC 1362 with the new item entry 1322. A particular advantage of this approach is that the sender of information does not need to know the logon details of the receiver.
[0176]
In a further embodiment, metadata is communicated in a wired or wireless manner to a person who is not a registered user of the media browser service 1302. In such an example, the metadata may be wrapped in a voucher that includes the URI of the sender 1310 media browser service 1302 along with the anonymous user login of the service 1302. The recipient of the receipt can select the receipt (eg, via a mouse click), access the media browser service 1302 and display the metadata via an anonymous login. The recipient can play the content depending on whether the rights information used in the metadata is sufficiently generous.
[0177]
Receipts can be sent via email. Receipts can also be transmitted wirelessly if a transmitter / listener environment exists between the two devices. Received receipts are displayed on the desktop of the recipient's device.
[0178]
In situations where the metadata 1326 is carried using any of the methods described above, there remains a plurality of possibilities that include information on the right to use in the metadata. First, the right to use is left unchanged, and thus may be the default case for content provided free of charge. Such a form is unlikely to be supported by content providers that charge for services. Another possibility is to default the right to use to single use 1328 as shown in FIGS. 13A and 13B. Another alternative is to change the right to use as indicated by the right-to-use information in the original metadata. This may include communication with the content provider's metadata server and new usage rights sent to new users. This process can be automatically initiated by the receiving media browser client. In this form, transfer transactions can only be performed using the knowledge of the media browser or metadata server, which changes the new user's table of contents and consequently changes the rights information used. Have the ability to
[0179]
For multiple reasons, it is preferable to communicate only metadata 1326, not content (not shown in FIGS. 13A and 13B). First, the mobile device typically has a reception bandwidth that is larger than the transmission bandwidth (since it does not require an expensive transmitter), and thus bears the burden of the device supplying the link sending the content. There is no. The metadata can also include information regarding the right to use the content, and thus this form is attractive for content providers who wish to limit the unlicensed use of the content. This is because in FIG. 13A, the first user 1316 has one year of usage 1318 of content, but when providing the metadata link 1326 to the second user 1320, the second user “ The right to use “only” 1328 is given. Further, the advantage of sending only metadata is that it can be added to the table of contents of the receiving user 1320 and therefore can be used for searching. Such metadata also allows the receiving user 1320 to purchase content as needed and to obtain full rights to use.
[0180]
Each described metadata is preferably a link to either an individual description or a metadata item in the metadata repository associated with the metadata server 1304. Either the information about the right to use can be included in the communicated link, or a reference or link to this information can be included. The relationship between links, metadata, and selectable content is shown in FIG. 13C. As described above, since a link can also include an attribute, such a link can be described as metadata although it is not strict.
[0181]
In some cases, it may be preferable to stream content rather than metadata. The advantage of streaming content is that stream content can be received effectively simultaneously (such as synchronized for karaoke).
[0182]
IX. Switching sessions between devices
FIG. 14 illustrates a configuration 1400 that allows a user to switch a current media browser session from one device to another. Shown is to provide multimedia data streaming to a user operating a cell phone handset 1404 or a hi-fi audio device 1412 in a car 1416, each with an appropriate player for duplicating the multimedia stream, for example. The media browser service 1402 is configured as shown in FIG.
[0183]
In an exemplary operation, a user having a mobile phone 1404 can request streaming media from a provider accessible via the media browser service 1402. This may be accompanied by payment or free of charge. In making the request, the phone 1404 can also send a public key to the media browser service 1402 to allow the provider to authenticate the use of the media. The provider then sends metadata related to the session to the phone 1404 through the media browser service 1402 if it is not identical. This includes the session identifier and can include the key used to unlock the media. The key is encrypted using the public key of the telephone 1404 so that only a specific destination telephone 1404 can decode the media using the complementary secret key stored in the telephone 1404. This secret key is usually protected in the memory of the phone 1404 and is not intended to be exported from that device, thereby preventing other devices from impersonating the phone 1404.
[0184]
After the user receives media using the telephone 1404 for a while, the user decides to switch the session (playback) to the device 1412 in his car 1416. To accomplish session conversion, the user uses an infrared (IR) transceiver (not shown in FIG. 14 but known for use with handheld portable electronic devices) embedded in telephone 1404 in automotive equipment 1412. When the transmission button 1408 is pressed, the telephone 1404 transmits the metadata related to the session to the automobile device 1412 toward the corresponding IR transceiver 1414 in relation to
[0185]
The automotive device 1412 then operates to renegotiate the session with the media browser service 1402 and perform the same steps that the phone 1404 has performed to initiate the session. This can include, for example, negotiating extra payments when the quality of service that can be replicated by the device 1412 is higher than that of the telephone 1404, which is desired by the user. A specific handover time is also negotiated, which allows seamless transfer between players. It should be noted that in this connection, the automotive equipment 1412 includes some form of RF transceiver device, allowing proper communication with the media browser service 1402, for example, via the cell phone network.
[0186]
When the handover time is reached, the media browser service 1402 stops sending session media to the telephone 1404 and starts sending media to the automotive device 1412. The metadata used by the phone 1404 becomes invalid and the media can no longer be obtained using that particular metadata. The switchover may include obtaining an estimate of the path delay of the telephone 1404 and the automotive equipment 1412. Methods for estimating the path delay of a network connection between two participants are known per se in network technology.
[0187]
A particular advantage of this form is that via notification to the media browser service 1402, the nature of the content stream can be conditionally changed for the destination device where the duplication is performed. This can be performed subject to the quality of service purchased when entering the original session. Alternatively, a change in the destination device may prompt the user to improve the quality of service by accepting new terms for delivery and associated costs. In this manner, delivery of MP3 audio to the telephone handset 1404 can be replaced with streaming CD quality audio to the car hi-fi device 1412. Further, when getting out of the car 1416, the user can choose to transfer the session to a more sophisticated device, such as the desktop computer 1112 of FIG. 11, in which case the content being provided at that time (eg, If it contains a video component (such as a music video that can be “listened” on the phone or car radio and can be viewed (listened while listening) via the desktop computer 1112), the video can be streamed with the audio. Also good.
[0188]
X. Usage information
The number of times content provider 1212 has requested a particular content item from metadata server 1214 via media browser server 1206 or other such server (not shown), for example in various forms as described above, such as FIG. Please understand that it is easy to accumulate information about. However, the media browser server 1206 can provide extra usage information, which can include:
(A) the type of device being used to play / display a particular item of content;
(B) Usage of a particular content item by demographic and / or geographic display of the media browser server 1206.
[0189]
Content providers 1212 only have total usage statistics from their own metadata server 1214. Obtaining usage information from individual media browser services has commercial value. This information can be used to influence how content providers 1212 advertise their metadata server (ie, whether to pay to include a link in the default TOC for a particular service).
[0190]
The web server can already provide this statistic effectively for downloads, but having this information about streaming content measures “use” rather than downloads, so it provides more accurate statistics. When a user downloads digital content, information about the number of times that content is actually used is not available. This is because the content is stored by the user. Using the forms described herein, content is not stored by the user, but is delivered each time access is made via the media browser server 1206, in a streaming or other manner. In addition, obtaining statistics on usage by device type can help content providers focus their support / survey on playback platforms.
[0191]
XI. Providing appropriate rating control
In various forms described, acceptable ratings can be associated with a user account along with the media browser service 1206 or a particular device. The former requires having a range of media browser accounts. This can be implemented, for example, by a parent (controlling) account and a child (controlled) account. Rating control can be used for:
(A) Playback / display control and / or
(B) Purchase control
Users can currently leave rating control to those who use the web (ie, children's pages, etc.), but these rating levels are generally determined globally. Allows specific control over the content that can be played / displayed / purchased using the parent / child account concept and one or more other accounts where the parent account is designated as being under parental control This is a highly desirable and customizable way of controlling access. Importantly, parents can control access only to their own children.
[0192]
Access can also be controlled by a replication device. In this case, the parent and child can have their owner user account or use the same account. However, devices used by children may be used to restrict access to some of the available items.
[0193]
XII. Media browser service locating
The content provider 1212 wants to be able to identify possibly all media browser services (such as 1206) that are available over a computer network (Internet, web, etc.). This is desirable in order for content providers to be able to promote their content to these services. Accordingly, the content provider 1212 can search the network, identify a server that provides a particular (media browser) service, and distribute promotional material to that server.
[0194]
XIII. User interface navigation
The user interface described above with reference to FIG. 4, like most graphical user interfaces (GUIs), is a device that seeks to maximize functionality through optimal presentation of graphical information that is selectable in part. . Such GUIs are expected to be used by semi-professional / business users such as graphic designers, marketers and home computer users. As with all GUIs, the display area is expensive and it is always desirable to optimize information presentation. Navigation through a hierarchical data collection (eg, database, file system) is an important component of most GUIs. Traditionally, GUI navigation is performed using a tree representation of a data collection in which the user selects a tree branch to locate the desired data. Such presentation is performed in, for example, WINDOWS EXPLORER (trademark of Microsoft Corporation, USA), but usually occupies a considerable display area along one side of the display screen (for example, 914). Importantly, when a large number of branch levels are encountered, such a tree extends in the width direction of the display screen and further occupies the display area desired for other purposes.
[0195]
An alternative GUI that can be used with the media browser form described herein as well as other forms is the interface 1600 shown in FIG. When a user logs on to the media browser service, the user is presented with the user's current TOC. The top level item is displayed and represented by its visual identifier in the browse window.
[0196]
Navigation through the user's information landscape or TOC can be accomplished by the user interacting with a hierarchical “bread club”, formed from locations 1602 and 1606, both of which are located above the viewing window 1604. The term “location” is used to refer to a node TOC descriptor other than a leaf. Within each level of the bread club, the user can choose to pull down a menu of other included location options at that level of the bread club.
[0197]
Navigation using a hierarchical bread club is illustrated in FIGS. 17A and 17B. FIG. 17A shows a portion 1700 of the GUI 1600 where the user's TOC is seen under a selectable tab 1702 titled MyDocuments. When selected, tab 1702 lists the locations directly contained below it. Selecting an included location, for example by clicking the mouse 903, creates an adjacent list 1704 for the selected location. From FIG. 17A it will be clear that the user has selected MyImages. A similar selection creates a new list in turn, showing two JPEG images taken on a holiday in Cairns in 2000. In FIG. 17A, the check next to each location name indicates that the selected path to the data collection thereby provides the user with an appropriate contextual reference for traversal of the data collection. It will be clear. At any time, if the user wishes to follow an alternate path in the data collection, any of the unselected locations can be selected, thereby displaying the corresponding bread club display. In this regard, only the locations included in the selected location are displayed in the bread club list. A display window 1710 is placed below the list to display a representation of any TOC item 1712 (eg, a thumbnail image). FIG. 17B shows the result when the user has selected MyVideo from the configuration of FIG. 17A and the navigation display has been changed to show locations with video content. Note that in each of FIGS. 17A and 17B, a subdirectory Hol.2000 is shown. This is because both the MyImages location and the MyVideo location contain a location with that name. As before, further included locations 1724 and 1726 may be listed upon appropriate selection of items from the displayed locations. FIG. 17B shows a display window having items 1730 included in the MyVideo location.
[0198]
Although this navigation method has been described in terms of locations (nodes in XML descriptions), it is clear that this can be applied to directories in the file system.
[0199]
One of the advantages of this navigation approach over standard tree-based methods is that you do not have to navigate up and down along the various branch paths, but escape from one sub-branch and enter another sub-branch directly. Is simple. Another advantage of this navigation method is that it uses very little screen space, which is valuable when screen space is limited, such as mobile devices. The user can also navigate his / her TOC using the standard method of simply double-clicking the visual identifier in the viewing window 1606 to display the child items of the clicked item. . Instead, the previously visited location can be redisplayed by selecting the desired location in the history list 1608 located on the right side of the bread club on the interface of FIG.
[0200]
The user can define the number of items to display in the viewing window. Often it is desirable to be able to visually present as many items as possible (eg search results). However, when there are too many items to be displayed, it becomes difficult to understand the contents of the items. If the location contains more items than are displayed in a single window 1606, the viewing window control 1610 below this window is used for the page through its content. As pilot users showed this preference in early usability studies, paging was chosen in preference to scrolling.
[0201]
The search panel 1612 is the upper left panel in FIG. The user can select a location to search from his / her TOC. Adapted to both simple text-based search and advanced search, the user can select the desired descriptor and the required value. In advanced search, questions are constructed by the user specifying constraints on the selected descriptor. In other words, the result of the query is similar to a browsing expression with a filter and is expressed directly as an XPath location. The interface 1600 allows the user to filter the search expression based on the content type (eg, image, video and / or audio), but the media browser server can express metadata for any media type. A media type selector is included in the interface to improve the usability of the interface for the target user.
[0202]
The lower left panel 1614 displays a set of commonly used properties (index descriptors) for the currently selected item in the viewing window. The properties displayed on this panel are predetermined. The selected descriptor does not include index descriptors with these descriptor names, and checks for available index descriptors (eg, other types that may have type date or similar descriptor names If these properties cannot be identified by detecting the index descriptor), no value is displayed.
[0203]
The right panel 1618 of FIG. 16 contains a list of all current stacks open in this interface. The stack is the user's personalized store of links to metadata (ie, each item in the stack is just a URI with an optional XPointer). The stack can be used to store search results, references to favorite images from a set of image libraries, or the current working set for another task. You can drag items from the viewing window to any open stack. A stack is treated like a location and can be opened and displayed in a viewing window. When the opened stack is closed, the previous non-stack location is replaced in the viewing window. When the user has finished using the stack, the user can choose to save the stack for use in a later session. This results in the stack data being stored in the user's personal data.
[0204]
The shopping cart icon 1620 at the bottom right of the interface 1600 is just a specialized stack for items related to purchases. A "Purchase Wizard" can be called from this icon when needed to facilitate shopping and payment. Preferably, the wizard can purchase content related to shopping basket metadata using the user's account for the media browser. In other words, if the content is owned by different content providers, the user need not visit each vendor and purchase items provided by that vendor.
[0205]
In order to conduct a media browsing session using the form described herein, such as the configuration of FIG. 11, a user typically uses a local computer 1112 to manage access to the Internet 1106. Run a traditional Internet browsing application such as NETSCAPE NAVIGATOR (Trademark of Netscape Corp., USA) or INTERNET EXPLORER (Trademark of Microsoft Corp.). Using an Internet browser, the user accesses the media browser server 1102 and the media browser server 1102 prompts the user to enter a login name and password. When the user is satisfied that the user is authorized for access, the server 1102 launches the media browser application in the local computer 1112 and the user is initially presented with the TOC 1114. Here, if the user selects “Images” from the TOC 1114, the GUI window 1900 shown in FIG. 18A can be presented, where the user can view the functions and icons 1904, 1906 available within the search section 1902. Used to identify all images 1904 from the location 1906 that the user himself has added to the bookmark as compared to other media such as audio, video, and text. Alternatively, the user may search other directories 1908 using keywords 1910 or advanced search 1912 that includes selectable icons 1914 for each of images, video, and audio. The search is initiated by selection of icon 1916.
[0206]
In the example of FIG. 18A, a plurality of browser pages of search results are returned by searching for the user's own images, and each of the search results is a thumbnail image 1922 displayed in the main data portion 1932 of the GUI window 1900, 1924, 1926, etc. The range of search results is indicated by a paging bar 1930 that provides a selection of search result pages. In this example, the number “3” is highlighted, indicating that the user is displaying page 3 of the search result. Each thumbnail image 1922, 1924, 1926, etc. represents a portion of the metadata associated with the actual image that may be desired for final display, use, or purchase or a combination thereof. If desired, the user can view detailed information about the actual image by selecting the “properties” icon 1920, which is located within the property summary area 1918, and contains a thumbnail for the property summary area 1918. For a selected one of 1922, 1924, 1926, other metadata associated with the image can be displayed.
[0207]
Moving to FIG. 18B, the user has selected the thumbnail 1928 and properties icon 1920 of FIG. 18A. When this occurs, the property summary area 1918 extends across the browser window 1900 to a significant extent, covering much of the thumbnail image displayed in the main data portion 1932. The expanded summary portion 1934 includes a representation of the selected thumbnail 1928a, and the expanded summary portion 1934 allows the user to select either the “Specific Properties” 1936 or “All Properties” 1938 view of the selected image. Can be selected. Table 1940 is presented in an expanded summary portion 1934 that includes various categories of information about the image, including publication details, keywords associated with the image, and the like. In some embodiments, some of the items in table 1940 can be changed by the user and saved using the “OK” icon 1942 as part of the user TOC or the user's own metadata record. This can include various captions or keywords, but typically does not include information about owners such as publishers and photographers. Such a change will change the properties of the media item.
[0208]
In situations where the user desires to search within his own image instead of getting the entire set as in FIG. 18A, the “advanced search” icon 1910 can be selected, which results in that shown in FIG. 18C. As shown, the “search” area 1902 is expanded across the main data area 1932 and a table of searchable criteria 1950 is displayed within the expanded search section. The determination criteria shown in the table 1950 include those that may exist in the property table 1940 of FIG. 18B. The user can adjust the range of search results obtained by modifying the values in the table 1950, and the search results are confirmed by selecting a further icon 1952.
[0209]
Returning to FIG. 18A, the user selects one or more of the media items (ie, thumbnails 1922, 1924, 1926, etc. in this example) in the main portion 1932 as desired, and selects these items in the stack area 1960. Can be dragged to one of multiple stacks. In this way, users can easily create their own media collections arranged according to their own sorting schemes if desired. In FIG. 18A, two stacks 1962 and 1964 are shown, each formed as a selectable icon. Stack 1964 relates to previous search results recorded by the user.
[0210]
When the stack icon 1964 is selected for opening, as shown in FIG. 18D, a media reference recorded in the stack 1964, in this example a series of thumbnail images 1970 of the human hand, is displayed in the main data area 1932. Is displayed. When this occurs, as shown in FIG. 18D, the stack icon 1964 is expanded in the stack area 1960 and is summarized information related to the contents of the selected stack, in this example titled “Search_1”. A component 1966 is formed. The displayed information may include the following.
(I) details of the creation of the collection (eg, as a result of the search, including the query used by the search)
(Ii) Number of collection items and total size
(Iii) History of activities performed on the collection, such as logging when items are added to or removed from the stack
(Iv) An animated preview of the collection's content where appropriate. For example, if the stack contains video items (or links to them), a summary of these items can be animated into a collection preview. This can include launching an appropriate preview tool, such as a media player window or the like.
[0211]
There are several advantages to displaying this information as part of the collection icon. Advantages include the following:
(I) It is easily apparent to the user that the displayed information represents the properties of the stack collection
(Ii) Eliminates the need for the user to specifically select the display of stack summary information in other ways
(Iii) The summary information may vary depending on how the collection was created. For example, summary information can be automatically updated when the stack collection is changed, for example, by addition or deletion.
[0212]
The form of FIGS. 18A-18D provides a way to automatically indicate information about items and collections of items (in this case links to metadata) when the collection is opened for display. Unlike prior art forms, this information is displayed as part of the collection icon expansion, which is preferably done in an animated form when the collection is opened by the user. In contrast, summary information can be displayed for items in WINDOWS EXPLORER (Microsoft Corp.), but such information can be displayed by right clicking on a collection item (folder) and the system displaying a properties dialog. Or in a browse window that contains icons for the collection's child items. In the form of FIGS. 18A-18D, when a user opens a stack (collection), the stack icon is expanded and summary information (in addition to the stack name) is displayed in an enlarged area of the stack icon itself.
[0213]
XIV. Alternative structured information processing system
The discussion so far has been about browsing and searching using metadata, and then accessing related content. It will be apparent to those skilled in the art that many of the features described above also apply when the accessed repository contains information that is not necessarily linked to a particular item of content. For example, an equivalent of a metadata server, referred to herein as an information server, is configured to also accept requests from processes regarding specific structured information stored in a source associated with the information server be able to. An information source can be publicly represented by a schema, similar to a metadata repository. Communication between the requesting process and the information server can be configured substantially as described in Section III of this specification (ie, this allows browsing and retrieval requests). The result of the request is an XML document that represents structured information. This example of a more general embodiment, shown at the end of Section V, shows how a user can potentially access different patent databases worldwide using a single user interface.
[0214]
Obviously, the process of making a request to the information server operates in a slightly different manner. For example, the distinction between TOC descriptors and index descriptors may no longer be useful. Instead, the main feature of the process of receiving such structured information is to correctly format information from various disparate sources. For such end purpose, the ability to selectively identify the necessary information using the advanced search described above is very useful. Browsing and search request results are presented to the user in various formats using a predetermined format, which may or may not be customized for a particular user, depending on the data type used. be able to.
[0215]
[Industrial applicability]
The forms and embodiments described above are applicable to the computer industry and the data processing industry, in particular, the industry that provides multimedia services. Embodiments provide, among other things, making it easier for Internet service providers to bring content vendors and buyers together while adding commercial value to the search for services and / or hosts they provide. To do.
[0216]
The foregoing has described at least one embodiment of the invention, and modifications or changes may be made thereto without departing from the scope and spirit of the invention. It is not restrictive.
[0217]
Appendix 1 is an XML source description for the example of FIG. 15, and Appendix 2 is an XML stylesheet that can be used to convert the source description of Appendix 1 to a normalized form.

[Brief description of the drawings]
FIG. 1 is a block diagram showing an operating environment of a multimedia access system.
FIG. 2 is a more detailed block diagram illustrating how the media browser of FIG. 1 accesses a metadata database.
FIG. 3 is a flowchart showing communication processing between a media browser and a metadata server.
FIG. 4 illustrates a visual appearance of a user interface of a media browser component of a multimedia access system.
FIG. 5 is a flow diagram illustrating a preferred browsing process for the media browser.
FIG. 6 is a flowchart showing a preferred search process of the media browser.
FIG. 7 illustrates a structured image metadata database.
FIG. 8 is a diagram illustrating an example of XML metadata used by browsing processing.
FIG. 9 is a schematic block diagram representation of a computer system on which a media browser can operate.
FIG. 10 illustrates an example embodiment of the system of FIGS.
FIG. 11 illustrates media browser customization for different devices.
FIG. 12 is a diagram illustrating an arrangement capable of controlling the right to use multimedia content.
FIG. 13A
FIG. 13B
FIG. 13C illustrates a method by which metadata links can be communicated between devices.
FIG. 14 illustrates an arrangement in which a current media browser session can be switched from one device to another.
[FIG. 15 (a)]
FIG. 15 (b) is a diagram illustrating an example of a method that can convert a source description into a normalized description that can be presented by media browser placement.
FIG. 16 illustrates a preferred media browser graphical user interface.
FIG. 17A
17B illustrates how “bread club” navigation is used in the interface of FIG.
FIG. 18A
FIG. 18B
FIG. 18C
FIG. 18D illustrates a system user via a further modified media browser graphical user interface.

Claims (5)

Media browser server executes the step of storing the contents data of the multimedia content is permitted to the user database,
The first user device executes the contents first display step of displaying the entire data of the multimedia content provided to the user equipment of the first to access the media browser server,
Second the second user device displays the item of the multimedia content that can be replicated by the second user equipment from among the contents data supplied to the user device of the second access to the media browser server and the display step,
A multimedia content distribution method comprising: performing a duplication step of duplicating multimedia content requested from the items displayed in the second display step from the media browser server . The media browser server, a detection step of detecting the type of the first user equipment or the second user equipment,
Distribution of multimedia content according to claim 1, wherein further executes the distribution step for distributing data in a format corresponding to the detected type to the first user equipment or the second user equipment Method. The media browser server, executes the first user device or the second storage step stores multimedia content that will be requested by the user equipment,
The media browser server, the first user device or in response to a request from the second user device, according to claim 1, wherein further perform customized steps to customize the streaming of the multimedia content Multimedia content distribution method. 4. The multimedia content delivery method according to claim 3, wherein at the customization step, at least one of correction, coding, and encryption of a streaming bandwidth of the multimedia content is performed . Said first user terminal or the second user terminal, and a display step of displaying the multimedia contents,
After displaying the multimedia content, further executes the instruction step of instructing the purchase of access rights of the multimedia content to the media browser server,
Claims wherein the media browser server, playback of the indicated multimedia content, and executes a permission step of permitting reproduction period or copied to the first user equipment or the second user equipment Item 5. The multimedia content distribution method according to Item 1.

Images