JP2005509950A - フィンガープリント・データベース更新方法、クライアント及びサーバ - Google Patents

Abstract

複数のマルチメディアオブジェクトのそれぞれのフィンガープリント及び関連付けられたメタデータのセットを有するデータベース（２１１）を更新する方法において、マルチメディアオブジェクト及び前記マルチメディアオブジェクトのメタデータのセットは、ファイル共有クライアント（１０１−１０５）からダウンロードされる。フィンガープリントは、前記マルチメディアオブジェクトから計算され、計算された前記フィンガープリント及び取得された前記メタデータのセットは、前記データベース（２１１）に含められる。前記データベース（２１１）は、中央サーバ（２１０）により維持されることができるか、又は前記ファイル共有クライアント（１０１−１０５）上で実行されるサーバ（４０４）により分散された仕方で維持されることができる。前記データベース（２１１）は、この仕方で、１つの特定のフィンガープリントに関連付けられた複数のメタデータのセットを蓄積する。十分な数のセットが集められた場合、確かなセットが、フィルタリング技術を使用して決定されることができる。

Description

本発明は、複数のマルチメディアオブジェクトのそれぞれのフィンガープリント及び関連付けられたメタデータのセットを有するデータベースを更新する方法に関する。本発明は、更に、このようなデータベースを更新するように構成されたファイル共有クライアント及びサーバ、並びに少なくとも１つのファイル共有クライアント及び少なくとも１つのサーバを有するファイル共有ネットワークとに関する。

人間の指紋は、既に百年以上も人々を識別するために使用されている。概念的に、指紋は、要約すると人間１人１人に唯一であると見なされることができる。近頃、マルチメディア処理の分野において、マルチメディアオブジェクトのフィンガープリントを計算することへの関心の高まりが見られる。２つのマルチメディアオブジェクトが同じものであると認可するために、前記マルチメディアオブジェクト自体を比較する代わりに、これらのフィンガープリントのみが比較される。マルチメディアオブジェクトのフィンガープリントは、当該オブジェクトの最も関連した知覚的特徴の表示である。このようなフィンガープリントは、ときどき“（ロバスト）ハッシュ”としても知られている。

フィンガープリント技術を使用するほとんどのシステムにおいて、多数のマルチメディアオブジェクトのフィンガープリントは、関連付けられたそれぞれのメタデータと一緒にデータベースに記憶される。用語“メタデータ”は、マルチメディアオブジェクトのタイトル、アーティスト、及びジャンル等のような情報に関連する。マルチメディアオブジェクトのメタデータは、フィンガープリントを計算し、ルックアップ鍵又はクエリ鍵として計算された前記フィンガープリントを使用して前記データベースにおいてルックアップ又はクエリを実行することにより引き出される。前記ルックアップは、この場合、前記フィンガープリントに関連付けられた前記メタデータを返す。

マルチメディアコンテンツ自体の代わりにマルチメディアオブジェクトのフィンガープリントをデータベースに記憶することに幾つかの利点がある。以下に例を挙げる。
１．データベースのメモリ／記憶の必要条件が減少される。
２．フィンガープリントはオブジェクトより実質的に短いので、フィンガープリントの比較は、マルチメディアオブジェクト自体の比較より効率的である。
３．マッチするフィンガープリントをデータベース内で検索することは、より短いアイテムのマッチングを伴うので、完全なマルチメディアオブジェクトを検索するよりも効率的である。
４．（異なるフォーマットでの符号化又はビットレートの変化のような）マルチメディアオブジェクトに対する小さな変化は、フィンガープリントには影響を与えないので、マッチするフィンガープリントの検索は、より成功しやすい。

マルチメディアオブジェクトのフィンガープリントを生成する方法の例は、欧州特許出願番号01200505.4（代理人整理番号PHNL010110）及びJaap Haitsma, Ton Kalker and Job Oostveen, “Robust Audio Hashing For Content Identification”, International Workshop on Content-Based Multimedia Indexing, Brescia, September 2001の中に記述される。

このようなシステムの設計における技術的な挑戦のほかに、データベースに入れられるべきマルチメディアオブジェクト、又は少なくともこれらのフィンガープリントを集める問題もある。例えば、オーディオ音楽の場合、Tower Recordsに出かけ、１００，０００枚のＣＤを買い、且つ前記ＣＤから直接フィンガープリントを計算することが可能である。これが高価な作業であるという事実は別として、この解決方法は、幾つか他の欠点を持つ。

第一に、ＣＤの購入は、自動化するのが難しい手動の作業である。特に、これは、前記データベースのフィンガープリントを最新に保つことを自動化するのが難しいことを意味する。第二に、人は、常にＣＤ音質に興味があるのではなく、もし用途に対してより適切であれば、劣化音質に興味があることもあり得る。これは、フィンガープリントが前記データベース内に入れられることができる前に付加的な前処理ステップを意味するだろう。また、人は、フィンガープリントが前記データベースに記憶される全ての曲のメタデータを得なければならない。これは、前記フィンガープリント自体を取得するよりも更なる挑戦である。

米国企業Relatable.comは、再生される音楽に基づいて音楽の好みを“学習”し、類似した音楽の好みを共有する人々のバーチャルコミュニティを作るデジタル音楽プレーヤを市場に出している。これらの好みを学習するために、前記音楽プレーヤは、ユーザのコンピュータで音楽ファイルを検索し、全ての音楽ファイルに対するフィンガープリントを作る。前記フィンガープリントは、この場合、中央サーバに提出され、ここで前記フィンガープリントは、Relatable.comにより提供されるメタデータを持つデータベースに対してマッチングされる。Relatable.comのシステムにおける情報は、これを書いている時点では、インターネット上のhttp://relatable.com/tech/player.htmlにおいて利用可能である。

Relatable.comシステムは、前記ユーザのコンピュータから取得されたメタデータが不正確であり得る（引用すると“もしあなたがあなたのＣＤコレクションからあなたの音楽ファイルを記録したならば、メタデータ（アルバムのタイトル、アーティスト又は曲の名前のような情報）が不正確であり得る”）と予想し、従ってこのメタデータは、前記音楽プレーヤにより読み出されない。むしろ、Relatable.comは、ユーザから受信したフィンガープリントの代わりにこれ自体のメタデータを使用するので、前記フィンガープリントは、容易に比較され、且つ処理されることができる。このシステムの不利点は、従って、Relatable.comが、全ての曲に対するこれ自体のメタデータを得なければならず、このメタデータのために、全てのクライアントからフィンガープリントを受信することである。

本発明の目的は、既知の方法より効率的である、導入部分による方法を提供することである。

この目的は、ネットワークに接続されたファイル共有クライアントから前記ネットワーク上のマルチメディアオブジェクト及び前記マルチメディアオブジェクトのメタデータのセットを取得するステップと、前記マルチメディアオブジェクトからフィンガープリントを計算するステップと、計算された前記フィンガープリント及び取得された前記メタデータのセットをデータベースに含めるステップとを有する方法において本発明により達成される。

この方法を使用すると、もはや積極的に出かけ、且つ例えばＣＤ上のコンテンツを買う、又は自身でコンテンツのメタデータを探す必要はない。前記ネットワーク上の前記ファイル共有クライアントから入手可能な前記オブジェクト及びメタデータを使用することにより、署名及びメタデータは、とても効率的な仕方で集められることができる。これらのクライアントは、既に前記オブジェクトを誰でもダウンロードできるようにし、従って、これらのオブジェクトを買うことは、不必要になる。更に、典型的には、前記オブジェクトは、メタデータと一緒に入手可能にされ、従ってこのメタデータも同様に使用されることができる。

一実施例において、前記フィンガープリント及び前記メタデータのセットを含めるステップは、サーバ内の計算された前記フィンガープリント及び取得された前記メタデータのセットを受信するステップと、計算された前記フィンガープリントが前記データベース内に存在するかどうかを決定するステップと、もし存在するならば、取得された前記メタデータのセットを前記フィンガープリントと関連付けるステップと、もし存在しないならば、互いに関連付けられた計算された前記フィンガープリント及び取得された前記メタデータのセットを前記データベースに加えるステップとを有する。

前記フィンガープリント及びメタデータのセットをサーバにより維持されるデータベース内に集めることは、全ての前記メタデータが入手可能である単一の場所があるという利点を持つ。複数のフィンガープリント及びメタデータのセットが、前記データベースに含められた後に、前記中央サーバは、前記データベースのコンテンツを利用可能にすることができるので、誰でもフィンガープリントを用いてクエリを提出し、代わりに適切な前記メタデータを受信することができる。

更に他の実施例において、一度、十分な数のメタデータのセットが前記データベース内の特定のフィンガープリントに関連付けられると、前記サーバは、更に、前記特定のフィンガープリントに関連付けられた確かなメタデータのセットを決定する。

１つの特定のフィンガープリントに関連付けられたメタデータのセットは、異なるクライアントから取得された。様々な理由から、誰もが、彼が共有する全てのマルチメディアオブジェクトの正しいメタデータを供給するわけではないであろうと予想されるべきである。しかしながら、１つの特定のフィンガープリントに関連付けられた前記正しいメタデータを有する１つの確かなセットを持つことが望ましい。一度、十分な数のメタデータのセットが、前記データベース内で利用可能になると、前記正しいメタデータを決定するためにフィルタリング機構を利用することが可能になる。

更に他の実施例において、前記方法は、更に、前記特定のフィンガープリントに関連付けられたメタデータのセットが以前取得された少なくとも１つのクライアントに対して前記確かなメタデータのセットを供給するステップを有する。このように、これらのクライアントは、当該曲のメタデータを更新することができる。この仕方でフィードバックを与えることにより、前記サーバは、有用なサービスを前記ファイル共有ネットワーク上の前記クライアントに提供する。

本発明は、更に、複数のマルチメディアオブジェクトのそれぞれのフィンガープリント及び関連付けられたメタデータのセットを有するデータベースを更新するように構成されたファイル共有クライアントであって、ネットワークに接続された他のファイル共有クライアントから前記ネットワーク上のマルチメディアオブジェクト及び前記マルチメディアオブジェクトのメタデータのセットを取得する手段と、前記マルチメディアオブジェクトからフィンガープリントを計算する手段と、計算された前記フィンガープリント及び取得された前記メタデータのセットを前記データベースに含める手段とを有するファイル共有クライアントを提供する。

本発明は、更に、複数のマルチメディアオブジェクトのそれぞれのフィンガープリント及び関連付けられたメタデータのセットを有するデータベースを更新するように構成されたサーバであって、計算されたフィンガープリント及びメタデータのセットを受信するネットワーキング手段と、計算された前記フィンガープリントが前記データベース内に存在するかどうかを決定する確認手段と、もし存在するならば、取得された前記メタデータのセットを前記フィンガープリントに関連付ける手段と、もし存在しないならば、互いに関連付けられた計算された前記フィンガープリント及び取得された前記メタデータのセットを前記データベースに加える手段とを有するサーバを提供する。

一実施例において、一度、十分な数のメタデータのセットが前記データベース内の特定のフィンガープリントに関連付けられると、前記サーバは、更に、前記特定のフィンガープリントに関連付けられた確かなメタデータのセットを決定するフィルタリング手段を有する。

更に他の実施例において、前記サーバは、更に、前記特定のフィンガープリントに関連付けられたメタデータのセットが以前取得された少なくとも１つのクライアントに対して前記確かなメタデータのセットを供給するように構成される。

本発明は、少なくとも１つの本発明によるファイル共有クライアントと、少なくとも１つの本発明によるサーバとを有するファイル共有ネットワークにも関する。

本発明のこれら及び他の態様は、図面に示される実施例を参照して明らかになり、説明されるだろう。

全ての図にわたり、同じ参照符号は、同様な又は対応するフィーチャを示す。図面に示されたフィーチャの幾つかは、典型的にはソフトウェアにおいて実施され、従って、ソフトウェアモジュール又はオブジェクトのようなソフトウェアエンティティを表す。

図１は、複数のファイル共有クライアント１０１、１０２、１０３、１０４及び１０５を有するファイル共有ネットワーク１００を概略的に示す。ここではクライアント１０１乃至１０５の間に直接接続を持つ物理的なネットワークとして示されているが、ネットワーク１００は、概念的又は仮想的なネットワークとして最も良く見なされる。即ち、全てのクライアント１０１乃至１０５が、物理的に又はネットワークのように常に互いに直接接続される必要はない。必要なのは、“ネットワーク上の”１つのクライアントが、他のクライアントからファイル又はオブジェクトを取得することができることだけである。また、直接のクライアント・ツー・クライアント接続が使用される場合でさえも、全てのクライアントが全ての他のクライアントに接続される必要はない。

ネットワーク１００は、クライアント１０１乃至１０５に対するディレクトリサービスを実行するサーバ１１０を有してもよい。ファイル共有ネットワーク１００に接続するために、クライアント１０１は、共有したいファイル（又はオブジェクト）のリストをサーバ１１０に提出する。サーバ１１０は、ネットワーク１００に接続された全てのクライアントから前記サーバが受信するリストを結合する。他のクライアント１０２乃至１０５は、この場合、サーバ１１０に接続され、且つ前記結合されたリストをブラウズするか、又は前記リスト上の特定のオブジェクトを検索することができる。これらは、この後、捜しているオブジェクトを持つクライアントにコンタクトし、前記クライアントから直接前記オブジェクトを取得する（ダウンロードする）ことができる。このように、サーバ１１０は、クライアント１０１乃至１０５間のファイル又はオブジェクトの共有に直接的には参加しない。このアプローチは、世界的なNapsterファイル共有ネットワークにおいてよく知られている。

サーバ１１０を持たないネットワーク１００を実現することも可能である。この場合、クライアント１０１は、既にネットワーク１００上にある１つ以上の他のクライアント１０２乃至１０５に接続することによりネットワーク１００に接続する。クライアントは、該クライアントが接続された複数のクライアントに検索要求を送信することにより前記ネットワークを検索する。これらの複数のクライアントは、これらが共有するオブジェクトのリストを調査し、もし前記要求されたオブジェクトが該リストに存在するならば結果を返す。更に、前記要求は、これらの複数のクライアントに接続された他のクライアントに転送される。このように、前記要求は、前記要求を満たすことができるクライアントにより受信されるまで、又は全てのクライアントがこれを受信し、何れもこれを満たすことができないことがわかるまで、全体的なネットワーク１００上に分散される。

このような実施例は、例えばGnutellaファイル共有ネットワークから既知である。この実施例の不利点は、ネットワーク１００がスケーラブルでないことである。Gnutellaのようなネットワークは、現在、例えば、１００万のクライアントをサポートすることができない。更に、もし複数の“遅い”コンピュータ、即ちネットワーク１００に対する制限された帯域幅、処理パワー及び／又はメモリを持つコンピュータがあれば、前記ネットワークは遅くなるだろう。

代わりに、クライアント１０１は、１つ以上の他のクライアント１０２乃至１０５に接続した後に、共有したいファイル又はオブジェクトのリストを他のクライアント１０２乃至１０５に提出することができる。前記リストは、この場合、ネットワーク１００上の全てのクライアントに送られる。このように、全てのクライアントは、どのクライアントがどの利用可能なファイル又はオブジェクトを持っているかを知り、当該クライアントに直接コンタクトすることができる。

既知のKaZaaファイル共有ネットワークもサーバ１１０無しで動作するが、上述の問題を克服するために２種類のクライアント、即ちスーパーノード及び“通常の”クライアントを使用する。スーパーノードは、十分な帯域幅、処理パワー及びメモリを持つクライアントである。通常のクライアントは、スーパーノードに接続することにより前記ネットワークに接続し、共有されるべきファイルのリストを前記スーパーノードに送信する。スーパーノードは、複数のクライアントに対して接続を持ち、更に、複数の他のスーパーノードにも接続される。

スーパーノードは、同時に通常のクライアントでもある。即ち、ユーザにとって、彼のコンピュータがスーパーノードであるという事実は、明白である。ユーザがファイルを検索したい場合、彼のクライアントは、彼のクライアントが現在接続されているスーパーノードに要求を送信する。前記スーパーノードは、前記スーパーノードのクライアントにより送信されたリストの中にあるマッチするファイルを返す。更に、前記スーパーノードは、前記Gnutellaの実施例の中で上述されたものに類似した仕方で接続された全ての前記スーパーノードに前記要求を転送する。しかしながら、スーパーノード間の接続は、大きな帯域幅を持つので、このアプローチは、Gnutellaネットワークより大幅に速い。更に、これは、何百万のクライアントまで拡大されることができる。

典型的にはピア・ツー・ピア即ちＰ２Ｐファイル共有ネットワークと称されるこのようなファイル共有ネットワークは、莫大な人気がある。これらのネットワークのよく知られた例は、Napster、Musiccity、Gnutella、Kazaa、Imesh及びBearshareである。一度、ユーザが適切なクライアント・ソフトウェアを彼らのパーソナルコンピュータにインストールすると、前記ユーザは、彼らのファイルを共有することができ、他のユーザにより共有されたファイルをダウンロードすることができる。クライアント１０１乃至１０５は、インターネットのようなネットワークに接続されることができ、前記ネットワークは、ファイル共有ネットワーク１００の確立を容易にする。クライアントは、ファイル又はオブジェクトを取得するために他のクライアントに対して、例えば、ＴＣＰ／ＩＰ直接接続を使用することができる。

最も人気のあるネットワーク上には、通常、５００，０００以上の人々が同時に接続される。これを書いている時点で、人々は、主として、音楽ファイル（しばしばＭＰ３形式で）を共有しているが、映画の共有が人気を得てきている。用語“マルチメディアオブジェクト”は、音楽、歌、映画、テレビ番組及び絵等を含むファイルを示すために使用されるだろう。マルチメディアオブジェクトは、幾つかの異なるファイルから成ることができることに注意すべきである。

図２は、サーバ２１０に接続されたネットワーククローラ２００を概略的に図示する。クローラ２００は、クライアント１０１乃至１０５がファイル共有ネットワーク１００上で共有しているマルチメディアオブジェクトを取得するように構成される。これは、“クローリング”として当技術分野において既知であり、従って、クローリングの行為を実行するエンティティは、“クローラ”として既知である。クローラ２００は、この目的のために、ファイル共有ネットワーク１００に接続されることができる。クローラ２００は、全ての入手可能なマルチメディアオブジェクトのリストを取得するためにサーバ１１０にコンタクトすることもでき、この場合、全ての前記入手可能なマルチメディアオブジェクトをダウンロードするために全ての個別のクライアント１０１乃至１０５に直接アクセスすることができる。

ネットワークをクローリングする場合、ネットワーク１００及び／又はネットワーク１００上の個別のノードのオーバーロードを防止するように気を付けなければならない。特定のクライアントが、多数のオブジェクトを共有可能にする場合、クローラ２００は、とても短い時間内に全てのオブジェクトをダウンロードしようとし得る。これは、前記特定のクライアントのネットワーク接続をオーバーロードする本格的なリスクを持ち込み、クローラ２００がファイル共有ネットワーク１００に対するアクセスを拒否される結果となるかもしれない。

クローラ２００は、クローラ２００が前記マルチメディアオブジェクト自体を取得する前記クライアントから前記マルチメディアオブジェクトのメタデータのセットをも取得する。しばしばこのメタデータのセットは、前記マルチメディアオブジェクトに含まれる又は共にあるので、前記メタデータのセットの取得は、前記マルチメディアオブジェクトを取得する場合に自動的に行われる。例えば、人気のあるＭＰ３形式の音楽を有するマルチメディアオブジェクトは、しばしば前記オブジェクトの終わりにＩＤ３‘タグ’としてメタデータを含む。

マルチメディアオブジェクトをダウンロードして、クローラ２００は、この場合、前記マルチメディアオブジェクトからフィンガープリントを計算する。上述されたように、フィンガープリントを計算する１つの方法は、欧州特許出願公開公報01200505.4（代理人整理番号PHNL010110）において記述されるが、もちろんフィンガープリントを計算する如何なる方法でも使用されることができる。

クローラ２００は、二者択一的に、クライアント１０１乃至１０５の１つ以上にインストールされたハードウェア又はソフトウェアモジュール、例えばクライアント１０１乃至１０５上で実行されるファイル共有ソフトウェアにおけるプラグインモジュールとして実現されることができる。クローラ２００は、この場合、単純に、前記マルチメディアオブジェクトを、共有ドライブ又はディレクトリ上のこれらにアクセスすることにより取得することができ、前記ネットワークからダウンロードする必要がない。前記マルチメディアオブジェクトの前記メタデータのセットは、同様に、前記共有ドライブ又はディレクトリ上の前記マルチメディアオブジェクトから単純に読み取ることにより取得されることができる。

前記フィンガープリントの計算は、クライアント１０１乃至１０５上で実行されることもできる。マルチメディアオブジェクトのフィンガープリントの計算は、ＣＰＵに負担をかけ得るので、ここで、ＣＰＵパワーを消費しすぎることを防止するように気を付けなければならない。前記ユーザは、前記ファイル共有ソフトウェアがシステムの通常の使用に干渉するのを見るので、ＣＰＵパワーを消費しすぎることは、前記ファイル共有ソフトウェアの前記ユーザを狼狽させ得る。

前記フィンガープリントは、ユーザ要求があると、又は代わりにバックグラウンドで計算されることができる。後者の場合、依然としてフィンガープリントが計算されていない新しいマルチメディアオブジェクトに対して前記共有ドライブ又はディレクトリを定期的にスキャンすることが好ましい。もしこのようなオブジェクトが発見されるならば、フィンガープリントは自動的に計算される。もしこのようなオブジェクトに対してメタデータが入手可能でなければ、前記ユーザは、メタデータのセットを入力するように指示されることができる。

如何なる場合でも、一度、クローラ２００が、マルチメディアオブジェクトのフィンガープリントを計算し、前記マルチメディアオブジェクトのメタデータのセットを取得すると、クローラ２００は、フィンガープリント及びメタデータのセットをデータベース２１１に含める。このデータベース２１１は、図２の実施例に示されるように中央サーバ２１０により維持されることができる。前記データベースは、代わりに、下で図４を参照して明らかになるであろうように、分散された仕方で維持されることができる。

図３は、サーバ２１０をより詳細に示す。本実施例において、データベース２１１を維持するのはサーバ２１０である。クローラ２００は、ここで、データベース２１１に含めるために計算された前記フィンガープリント及び取得された前記メタデータのセットをサーバ２１０に提出する。サーバ２１０内のネットワーキング・モジュール３０１は、前記フィンガープリント及びメタデータのセットを受信する。確認モジュール３０２は、受信された前記フィンガープリントが、好ましくは、クエリを解決するデータベース管理システム（ＤＢＭＳ）バックエンドモジュール３０３にクエリを提出することにより、データベース２１１内に既に存在するかどうかを確認し、データベース２１１から結果を引き出し、前記結果を確認モジュール３０２に返す。

もし受信された前記フィンガープリントが既にデータベース２１１内にあれば、確認モジュール３０２は、前記メタデータのセットをＤＢＭＳバックエンドモジュール３０３に提出し、ＤＢＭＳバックエンドモジュール３０３は、前記メタデータのセットを既にデータベース２１１内にある前記フィンガープリントに関連付けるようにデータベース２１１を更新する。もし受信された前記フィンガープリントが既にデータベース２１１内にあるわけではないならば、確認モジュール３０２は、計算された前記フィンガープリント及び取得された前記メタデータのセットをＤＢＭＳバックエンドモジュール３０３に提出し、ＤＢＭＳバックエンドモジュール３０３は、互いに関連付けられた前記フィンガープリント及び前記メタデータのセットをデータベース２１１に加える。

データベース２１１は、フィンガープリントＦＰ１、ＦＰ２、ＦＰ３、ＦＰ４及びＦＰ５並びにそれぞれの関連付けられたメタデータのセットを有する。図３に与えられた前記例において、フィンガープリントＦＰ１は、セットＭＤＳ１１、ＭＤＳ１２及びＭＤＳ１３に関連付けられる。フィンガープリントＦＰ２は、セットＭＤＳ２１及びＭＤＳ２２に関連付けられる。フィンガープリントＦＰ３は、セットＭＤＳ３１、ＭＤＳ３２及びＭＤＳ３３に関連付けられる。フィンガープリントＦＰ４は、セットＭＤＳ４１及びＭＤＳ４２に関連付けられ、最後にフィンガープリントＦＰ５は、セットＭＤＳ５１、ＭＤＳ５２及びＭＤＳ５３に関連付けられる。

ある時点で、データベース２１１は、１つの特定のフィンガープリントに関連付けられた複数のメタデータのセットを含むだろう。これらのメタデータのセットは、異なるクライアント１０１乃至１０５から取得された。様々な理由から、全員が、共有する全てのマルチメディアオブジェクトに対して正しいメタデータを供給するわけではないであろうことは予想されるべきである。しかしながら、１つの特定のフィンガープリントに関連付けられた正しいメタデータを有する１つの確かなセットを持つことが望ましい。

１つの特定のフィンガープリントに関連付けられた１つ又は２つのメタデータのセットしかない間は、これらのセットの何れが正しいメタデータを含んでいるかを決定することはとても難しい。しかしながら、十分な数のセットが１つの特定のフィンガープリントに対して集められる場合、自動化された処理が、１つの確かなセットを選ぶために使用されることができる。この目的のために、サーバ２１０は、一度十分な数のメタデータのセットがデータベース２１１内の特定のフィンガープリントに関連付けられると、前記特定のフィンガープリントに関連付けられた確かなメタデータのセットを決定するように構成されたフィルタリングモジュール３０４を備える。

例えば、データベース２１１が、１つの特定のフィンガープリントに関連付けられた以下のメタデータのセットを含むと仮定する。
１．（アーティスト＝“Jewwel”、タイトル＝“Hands”）
２．（アーティスト＝“Jewel”、タイトル＝“Hands”）
３．（アーティスト＝“Jewel”、タイトル＝“Hnds”）
４．（アーティスト＝“Jewel”、タイトル＝“Hands”）
５．（アーティスト＝“Jewel”、タイトル＝“Hands”）

この例において、５つのうち４つのセットがアーティストの名前を“Jewel”として与え、１つのみが前記名前を“Jewwel”として与えることは、容易に見られることができる。大多数が勝つという単純なアプローチを使用すると、前記確かなメタデータのセットは、前記アーティストの名前を“Jewel”として与えるだろう。同様に、５つのうち４つのセットが、前記曲のタイトルを“Hands”として与え、従って前記確かなメタデータのセットも、前記曲のタイトルを“Hands”として与えるだろう。もちろん同じアプローチは、アルバムタイトル、発表年、ジャンル及び前記アーティストのウェブサイトのＵＲＬ等のような前記セットに含まれる他の型のメタデータに対して使用されることができる。

複数の候補値から確かな値を自動的に決定する他の、より高度な技術も、もちろん使用されることができる。このような技術は、知的エージェントの分野で一般的であり、エージェントにより受信された情報からノイズを除去するために使用される。このような技術は、決定樹プルーニング（pruning）及びクロス確認を含む。何が“十分な数”を正確に構成するかは、使用される技術に依存する。多数決を使用する場合、少なくとも５つのメタデータのセットを持つことが、満足な結果を生じる。

全てのメタデータのセットが必ずしも完全であるわけではないことが観測される。例えば、１つのメタデータのセットは、特定の曲に対してタイトル及びアーティストの名前のみを含むかもしれないが、他のセットは、前記曲が得られるアルバムのタイトル及び前記アルバムの発表年をも含むかもしれない。従って、上述の処理は、メタデータの個別の型、即ち、全ての入手可能なタイトルに基づいて前記タイトルに対して一度、全ての入手可能なアーティスト名に基づいて前記アーティスト名に対して一度、及び前記発表年に対して一度等で、実行されるべきである。このように、可能な限り詳細であり、即ちタイトル及びアーティストのみではなく、アルバムタイトル及び発表年をも含む確かなメタデータのセットが取得される。このような詳細な確かなメタデータのセットは、最も有益である。

一度、前記確かなメタデータのセットが決定され、特定のフィンガープリントに関連付けられると、当該特定のフィンガープリントに関連付けられた他のメタデータのセットは、データベース２１１から削除されることができる。これは、データベース２１１のサイズを減少させる。もちろん、前記メタデータのセットのバックグラウンドでのチェックを連続的に実行することも可能である。例えば、ジャンルの分類のような幾つかのメタデータは、時間に関して一定ではない。

サーバ２１０内で、どのクライアントから特定のフィンガープリントが取得されたかを追跡することは可能である。一度、前記特定のフィンガープリントに対する前記確かなメタデータのセットが決定されると、前記確かなメタデータのセットは、前記確かなメタデータのセットに対応しないメタデータのセットが取得されたクライアントに対して又はこのようなクライアントのみに対してフィードバックされることができる。このように、このようなクライアントは、当該曲のメタデータを更新することができる。これは、ユーザ・クライアントを使用してメタデータ生成を可能にする動機を与えるために使用されることができるツールである。

サーバ２１０は、データベース２１１の少なくとも一部を他に対して利用可能にすることができる。サーバ２１０は、例えば、検索インターフェース３０５を提供することによりこの一部を利用可能にすることができ、検索インターフェース３０５を介して、クライアントがフィンガープリントを提出し、代わりにメタデータのセットを受信することができる。好ましくは、提出された前記フィンガープリントに関連付けられた前記確かなメタデータのセットのみが返される。もし確かなメタデータのセットが入手可能でなければ、サーバ２１０は、提出された前記フィンガープリントに関連付けられた全ての前記メタデータのセットを返すことができ、又は確かな回答が前記検索に対して与えられることができないと報告することができる。

前記データベースから提出された前記フィンガープリントに関連付けられたメタデータのセットを引き出す様々な方法は、上述の欧州特許出願公開公報01200505.4（代理人整理番号PHNL010110）並びに欧州特許出願公開公報01202720.7（代理人整理番号PHNL010510）及び欧州特許出願公開公報01202959.1（代理人整理番号PHNL010532）から既知である。他の方法も、もちろん、使用されることができる。

データベース２１１のコンテンツは、無料で、又は代金を支払っている加入者に対してのみ利用可能にされることができる。代わりに、料金は、前記データベース上で実行されるクエリ毎に課金されることができる。フィンガープリントの提出に応答して前記クライアントに返されるメタデータの量は、変えられることもでき、例えば、無料のサービスは、アーティスト及びタイトルのみを返し、加入に基づくサービスは、前記データベース内の全ての利用可能なメタデータを返す。

図４は、ファイル共有クライアント１０１をより詳細に示す。上述されたように、分散された仕方でフィンガープリント及びメタデータのセットを持つ前記データベースを維持することも可能である。これは、サーバ２１０のようなサーバの必要性を回避する。前記データベースを維持するために必要な機能性は、この場合、ファイル共有クライアント１０１乃至１０５の１つ以上の全体又は一部で実現されることを必要とする。

ファイル共有クライアント１０１は、好ましくは、当技術分野においてよく知られているように、パーソナルコンピュータとして実現され、前記パーソナルコンピュータ上でファイル共有ソフトウェアが実行される。ファイル共有ソフトウェア４０１は、典型的には最近のオペレーティングシステムにおいて利用可能なＴＣＰ／ＩＰスタックのようなネットワーキング・モジュール４０２を使用する。記憶部４０３は、ファイル共有ソフトウェア４０１により共有される１つ以上のマルチメディアオブジェクトを含む。このような記憶部４０３は、典型的にはハードディスクにおけるディレクトリであるだろう。ある場合には、記憶部４０３は、分離した部分を含んでもよく、ここにダウンロードされたマルチメディアオブジェクトが記憶される。この部分は、典型的にはディレクトリも、共有されるべきマルチメディアオブジェクトが記憶されたディレクトリと必ずしも同じではない。

本発明の本実施例によると、ファイル共有クライアント１０１は、フィンガープリント・サーバ４０４をも有する。このサーバ４０４は、図３のサーバ２１０に類似した仕方でフィンガープリント・データベース４０５を維持する。データベース４０５は、もしデータベース４０５に記憶されたフィンガープリントが記憶部４０３において共有されるマルチメディアオブジェクトから取得されるならば、とても容易に構築及び維持されることができる。これは、図２を参照して上で説明されたように、ファイル共有クライアント１０１にインストールされたハードウェア又はソフトウェアモジュールとしてクローラ２００を実施することにより実現されることができる。

データベース４０５は、ちょうどデータベース２１１のようにフィンガープリント及び関連付けられたメタデータのセットを含むだろうが、本実施例の分散された性質のため、データベース４０５のコンテンツは、おそらくデータベース２１１のコンテンツより小さくなるだろう。データベース４０５は、典型的には、もちろん記憶部４０３が１つの特定のマルチメディアオブジェクトの複数のコピーを含む限り、各共有されたマルチメディアオブジェクトに対し、フィンガープリント及び１つの関連付けられたメタデータのセットを含むだろう。付加的に、データベース４０５は、ファイル共有クライアント１０１によりネットワーク１００上の他のファイル共有クライアントからダウンロードされたマルチメディアオブジェクトのフィンガープリント及びメタデータを用いて拡張されることができる。

マルチメディアオブジェクトのフィンガープリントは、前記オブジェクトの相対的に小さな部分のみがフィンガープリントを計算するために必要なので、当該オブジェクトがダウンロードされている間に計算されることができる。もし当該オブジェクトのメタデータが同様に入手可能であれば、前記フィンガープリント及びメタデータは、前記オブジェクトが完全にダウンロードされる前にデータベース４０５に含められることができる。もしこの処理の間に、前記フィンガープリントが既にデータベース４０５内にあると決定されるならば、前記ユーザが、この特定のマルチメディアオブジェクトのコピーを既に所有している可能性はとても高い。前記ユーザは、この場合、警告されることができるので、ダウンロードを中止することができる。

クライアント１０１が、他のクライアント１０２からマルチメディアオブジェクトをダウンロードしている場合、クライアント１０１は、１つ以上のフィンガープリントを関連付けられたメタデータのセットと共にクライアント１０２からダウンロードすることもできる。これらのフィンガープリントは、相対的に小さく（典型的なマルチメディアオブジェクトが数メガバイトなのに対して１０キロバイト程度）、従って、クライアント１０１の動作に影響を与えない。これは、ネットワーク１００内のクライアント１０１乃至１０５にわたり任意の仕方でフィンガープリント及びメタデータを持つデータベースを分散するやり方を提供する。ここで、クライアント１０１に対してデータベースを分散することが可能である。

前記KaZaaファイル共有ネットワークにおいて、前記スーパーノードは、好ましくは、ネットワーク１００上にフィンガープリント及びメタデータを分散するために使用される。前記Napsterファイル共有ネットワークのようなネットワークにおいて、これは、前記フィンガープリントを分散する前記中央サーバであることができる。

正しいメタデータの取得は、スーパーノード又は中央サーバにより援助されることもできる。クライアントは、特定のフィンガープリントに対する検索要求を前記クライアントが接続されるスーパーノードに提出する。前記スーパーノードは、他のスーパーノードに前記要求を送る。確かなセットを決定するために前記データベース内の前記メタデータのセットをフィルタリングする中央サーバなしで、前記スーパーノードは、おそらくクエリに対する複数の回答を受信するだろう。前記スーパーノードは、この場合、上で説明されたように、多数決又は他の技術を利用して、確かなメタデータのセットを決定することができ、この場合、前記確かなメタデータのセットは、前記要求を提出した前記クライアントに供給し返される。

前記スーパーノードは、この後、前記クライアントの１つが再び前記クエリを提出するたびに、全ての前記他のスーパーノードに再び前記クエリを送る必要を避けるために、前記確かなセットを用いてこれ自体のデータベース４０５を更新することができる。しかしながら、これは、彼の情報がいつか期限切れになるであろうリスクを負う。

フィンガープリント・サーバ４０４のサイズ、即ち分散されたデータベース４０５のフィンガープリント・サーバ４０４が維持する部分は、これが実行中の前記パーソナルコンピュータの性能に依存するようにされることができる。例えば、帯域幅の制限、ＣＰＵ速度及び／又は利用可能なワーキングメモリ（ＲＡＭ）が、考慮されることができる。このように、遅いコンピュータが、大きなフィンガープリント・サーバを負担することはないだろう。

上述の実施例は、本発明を制限するのではなく説明し、当業者が添付請求項の範囲から外れることなく多くの代替実施例を設計することができるであろうことに注意すべきである。

前記請求項において、括弧間に位置付けられた如何なる参照符号も、前記請求項を制限するように解釈されるべきではない。単語“有する”は、請求項に列挙された要素又はステップ以外の要素又はステップの存在を除外しない。要素の先にある単語“１つの”は、複数のこのような要素の存在を除外しない。

本発明は、幾つかの別個の要素を有するハードウェアによって、及び適切にプログラムされたコンピュータによって実施されることができる。幾つかの手段を挙げる装置請求項において、これらの手段の幾つかは、ハードウェアの同一のアイテムにより実施されることができる。特定の方策が相互に異なる従属請求項に列挙されるという単なる事実は、これらの方策の組み合わせが有利に使用されることができないことを示さない。

複数のクライアントを有するファイル共有ネットワークを概略的に示す。 サーバに接続されたネットワーククローラを概略的に示す。 前記サーバをより詳細に示す。 ファイル共有クライアントをより詳細に示す。

Claims (9)

1. 複数のマルチメディアオブジェクトのそれぞれのフィンガープリント及び関連付けられたメタデータのセットを有するデータベースを更新する方法であって、ネットワーク上のマルチメディアオブジェクト及び前記マルチメディアオブジェクトのメタデータのセットを前記ネットワークに接続されたファイル共有クライアントから取得するステップと、前記マルチメディアオブジェクトからフィンガープリントを計算するステップと、前記データベースに計算された前記フィンガープリント及び取得された前記メタデータのセットを含めるステップとを有する方法。
2. 前記フィンガープリント及び前記メタデータのセットを含めるステップが、サーバ内の計算された前記フィンガープリント及び取得された前記メタデータのセットを受信するステップと、計算された前記フィンガープリントが前記データベース内に存在するかどうかを決定するステップと、もし存在するならば、取得された前記メタデータのセットを前記フィンガープリントに関連付けるステップと、もし存在しないならば、互いに関連付けられた計算された前記フィンガープリント及び取得された前記メタデータのセットを前記データベースに加えるステップとを有する、請求項１に記載の方法。
3. 前記サーバは、更に、一度十分な数のメタデータのセットが、前記データベース内の特定のフィンガープリントに関連付けられると、前記特定のフィンガープリントに関連付けられた確かなメタデータのセットを決定する、請求項２に記載の方法。
4. 前記特定のフィンガープリントに関連付けられたメタデータのセットが以前取得された少なくとも１つのクライアントに対して前記確かなメタデータのセットを供給するステップを更に有する、請求項３に記載の方法。
5. 複数のマルチメディアオブジェクトのそれぞれのフィンガープリント及び関連付けられたメタデータのセットを有するデータベースを更新するように構成されたファイル共有クライアントであって、ネットワーク上のマルチメディアオブジェクト及び前記マルチメディアオブジェクトのメタデータのセットを前記ネットワークに接続された他のファイル共有クライアントから取得する手段と、前記マルチメディアオブジェクトからフィンガープリントを計算する手段と、計算された前記フィンガープリント及び取得された前記メタデータのセットを前記データベースに含める手段とを有するファイル共有クライアント。
6. 複数のマルチメディアオブジェクトのそれぞれのフィンガープリント及び関連付けられたメタデータのセットを有するデータベースを更新するように構成されたサーバであって、計算されたフィンガープリント及びメタデータのセットを受信するネットワーキング手段と、計算された前記フィンガープリントが前記データベース内に存在するかどうかを決定する確認手段と、もし存在するならば、取得された前記メタデータのセットを前記フィンガープリントに関連付ける手段と、もし存在しないならば、互いに関連付けられた計算された前記フィンガープリント及び取得された前記メタデータのセットを前記データベースに加える手段とを有するサーバ。
7. 一度十分な数のメタデータのセットが前記データベース内の特定のフィンガープリントに関連付けられると、前記特定のフィンガープリントに関連付けられた確かなメタデータのセットを決定するフィルタリング手段を更に有する、請求項６に記載のサーバ。
8. 前記特定のフィンガープリントに関連付けられたメタデータのセットが以前取得された少なくとも１つのクライアントに対して前記確かなメタデータのセットを供給するように更に構成された、請求項７に記載のサーバ。
9. 少なくとも１つの請求項６に記載のファイル共有クライアントと、少なくとも１つの請求項６、７又は８に記載のサーバを有するファイル共有ネットワーク。

Images