(57)【要約】【課題】「メディア識別子」が現行のメディアストリーム上で動作し、多数のクライアントに、ストリーミングメディアに埋め込まれたメディアオブジェクトのリアルタイムな識別を提供する。【解決手段】メディアオブジェクトの識別は、メディアストリームサンプルから計算され、クライアントによって生成されたトレースを、既知の識別の、格納され、予め計算されたトレース（すなわち、「フィンガープリント」）の膨大なデータベースと比較することによって、個別のクライアントに提供される。検索可能なダイナミックトレースキャッシュを使用して、特定のトレースを識別するために必要なデータベースのクエリーを制限する。このトレースキャッシュは、肯定的または否定的どちらか一方のデータベースの検索結果と共に最近のトレースのコピー１つのみをキャッシュする。キャッシュエントリは、古くなると削除される。【選択図】図３
2006146883.tif 000002
【特許請求の範囲】
【請求項１】
クライアントが監視するメディア放送ストリームに埋め込まれたメディアオブジェクトの識別を、複数の各クライアントコンピュータに提供するための方法において、コンピューティング装置を使用して、
複数のクライアントコンピュータごとに、クライアントによって生成されたメディアストリームトレースを、継続的にサーバコンピュータに送信し、
前記サーバが受信する送信メディアストリームトレースごとに、前記サーバを使用して、前記メディアストリームトレースにマッチするトレースのトレースキャッシュを検索し、
前記トレースキャッシュがマッチするトレースを含む場合は、そのマッチするトレースに関連する全てのメディアオブジェクト識別情報を前記サーバから対応するクライアントに送信し、
前記トレースキャッシュがマッチするトレースを含まない場合は、フィンガープリントデータベースを検索して、前記メディアストリームトレースにマッチするいずれかのフィンガープリントがあるか否かを判定し、前記送信されたメディアストリームトレースを、データベースの検索結果と共に前記トレースキャッシュに格納し、および
前記フィンガープリントデータベースがマッチするフィンガープリントを含む場合は、前記フィンガープリントに関連するメディアオブジェクト識別情報を前記サーバから対応するクライアントに送信すること
を備えたことを特徴とする方法。
【請求項２】
前記クライアントが生成したメディアトレースは、各クライアントによって、長さが約６秒程度である前記メディア放送ストリームのサンプルから、１秒間に約６回程度計算され、かつ送信されることを特徴とする請求項１に記載の方法。
【請求項３】
前記トレースキャッシュ内の各トレースは、所定の寿命を有し、さらに、満了した寿命を有するトレースはいずれも、全ての前記関連するメディアオブジェクト識別情報と共にトレースキャッシュから削除されることを特徴とする請求項１に記載の方法。
【請求項４】
前記所定の寿命は、前記関連するメディアオブジェクト識別情報を有するトレースに関しては、前記関連するメディアオブジェクト識別情報を持たないトレースよりも長いことを特徴とする請求項３に記載の方法。
【請求項５】
前記トレースキャッシュ内のトレースに対する前記所定の寿命の内の残っている時間は、前記トレースキャッシュ内のトレースがメディアストリームトレースとマッチするとき、前記所定の寿命にリセットされることを特徴とする請求項３に記載の方法。
【請求項６】
前記メディアストリームトレースと頻繁にマッチする前記トレースキャッシュ内のトレースは、前記所定の寿命に関わりなく永続的に前記トレースキャッシュ内に維持されることを特徴とする請求項３に記載の方法。
【請求項７】
前記トレースキャッシュ内の各トレースは、所定の時間に送信されたどの前記メディアストリームトレースともマッチに失敗した後で、全ての前記関連するメディアオブジェクト識別情報と共に前記トレースキャッシュから削除されることを特徴とする請求項１に記載の方法。
【請求項８】
前記トレースキャッシュは一定のサイズを有すること、および、送信される前記メディアストリームトレースが前記トレースキャッシュに格納されるときはいつでも、前記トレースキャッシュにおける最も古いトレースが、全ての前記関連するメディアオブジェクト識別情報と共に前記トレースキャッシュから削除されることを特徴とする請求項１に記載の方法。
【請求項９】
前記フィンガープリントデータベースからの１つまたは複数のフィンガープリントおよび前記トレースキャッシュからのゼロ以上のトレース、ならびにアップロードされる前記フィンガープリントおよびトレースに関連する全ての前記メディアオブジェクト識別情報のサブセットを、サーバから１つまたは複数のクライアントコンピュータにアップロードすることをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項１０】
前記クライアントに送られるフィンガープリントは、前記サーバに格納されるが、前記サーバ自体によっては、前記トレースのマッチ照合のため使用されないことを特徴とする請求項９に記載の方法。
【請求項１１】
前記各クライアント上のフィンガープリントと前記トレースの前記サブセットとは、前記クライアントによって生成されたメディアストリームトレースを前記サーバコンピュータに送信する前に、対応する前記クライアントによって生成されたメディアストリームトレースそれぞれに対するマッチについて検索され、および、前記クライアントによって生成されたメディアストリームトレースは、前記サブセット内のフィンガープリントおよびトレースのエントリとマッチする場合、前記サーバコンピュータに送信されないことを特徴とする請求項９に記載の方法。
【請求項１２】
対応する前記各クライアントに送信された前記メディアオブジェクト識別情報は、前記クライアントが監視する放送ストリームに埋め込まれた現在ストリームしているメディアオブジェクトの残りの持続時間を含み、および、当該情報を受信している前記クライアントはいずれも、現在ストリームしているメディアオブジェクトの残りの持続時間の間、前記クライアントによって生成されたメディアストリームトレースを前記サーバに送信することを中止することを特徴とする請求項１に記載の方法。
【請求項１３】
前記クライアントによって生成されたメディアストリームトレースの前記サーバへの送信は、ユーザが異なるストリームに切換えたことをシステムが検出すると直ちに再開されることを特徴とする請求項１２に記載の方法。
【請求項１４】
メディア放送ストリームに埋め込まれたメディアオブジェクトの識別を複数のクライアントの各々に提供するシステムであって、
前記複数のメディアストリーム放送のうち任意の１つを、前記複数のクライアントコンピュータのそれぞれで監視するステップと、
前記各クライアントコンピュータで監視したメディアストリーム放送のサンプルからリアルタイムトレースを生成するステップと、
前記各リアルタイムトレースを、前記各クライアントコンピュータから、１つまたは複数のサーバコンピュータのバンクに送信するステップと、
前記サーバのバンクが受信した各リアルタイムトレースに関し、前記サーバのバンクを使用して、前記リアルタイムトレースへのマッチのためにサーバ−ベースのトレースキャッシュを検索し、およびマッチするトレースに関連する全てのメディアオブジェクト識別情報を前記トレースキャッシュから対応する前記クライアントに送信するステップと、
前記トレースキャッシュに前記リアルタイムトレースに対するマッチが含まれない場合は、前記サーバのバンクを使用して、前記リアルタイムトレースへのフィンガープリントマッチのために前記サーバ−ベースのフィンガープリントデータベースを検索し、マッチするトレースに関連する全てのメディアオブジェクト識別情報を、前記フィンガープリントデータベースから対応するクライアントにて送信し、前記リアルタイムトレースをデータベースの検索結果と共に、前記トレースキャッシュに格納するステップと
を備えたこと特徴とするシステム。
【請求項１５】
前記トレースキャッシュ内の各トレースは、所定の寿命を有し、さらに、満了した前記寿命を有するトレースはいずれも、関連する全ての前記メディアオブジェクト識別情報と共に前記トレースキャッシュから削除されることを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記所定の寿命は、前記関連するメディアオブジェクト識別情報を有するトレースに関しては、前記関連するメディアオブジェクト識別情報を持たないトレースよりも長いことを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記トレースキャッシュ内のあるトレースに対する前記所定の寿命の内の残っている時間は、前記トレースキャッシュ内の前記トレースがメディアストリームトレースとマッチするとき、リセットされることを特徴とする請求項１５に記載のシステム。
【請求項１８】
メディアストリームトレースと頻繁にマッチする前記トレースキャッシュ内のトレースは、前記所定の寿命に関わりなく永続的に前記トレースキャッシュ内に維持されることを特徴とする請求項１５に記載のシステム。
【請求項１９】
前記トレースキャッシュ内の各トレースは、所定の時間に送信されたどのメディアストリームトレースともマッチに失敗した後で、関連する全てのメディアオブジェクト識別情報と共に前記トレースキャッシュから削除されることを特徴とする請求項１４に記載のシステム。
【請求項２０】
対応する各クライアントに送信される前記メディアオブジェクト識別情報は、前記対応する各クライアントが監視するメディア放送ストリームに埋め込まれた現在ストリームしているメディアオブジェクトの残りの持続時間を含み、および、当該情報を受信しているクライアントはいずれも、現在ストリームしているメディアオブジェクトの残りの持続時間の間、リアルタイムトレースをサーババンクに送信するのを一時的に中止することを特徴とする請求項１４に記載のシステム。
【請求項２１】
メディアオブジェクトの識別を複数のクライアントコンピュータに提供するためのコンピュータ実行可能命令を有するコンピュータ読み取り可能媒体であって、前記コンピュータ実行可能命令は、
複数のクライアントコンピュータを使用して、順序付けられたリアルタイムトレースを、各クライアントが監視するキャプチャされたメディアストリームのサンプルから生成するステップと、
生成された前記トレースをサーバコンピュータに送信すること、および
送信された前記トレースごとに、前記サーバコンピュータを使用して、
前記サーバコンピュータによってアクセス可能なトレースキャッシュを検索して、ト前記レースキャッシュが、マッチするトレースを含むか否かを判定し、
前記トレースキャッシュがマッチするトレースを含む場合は、マッチする前記トレースは関連するメディアオブジェクト識別情報を含むか否かを判定し、もし含む場合は、前記メディアオブジェクト識別情報を前記サーバから対応するクライアントに送信し、
前記トレースキャッシュがマッチするトレースを含まない場合は、フィンガープリントデータベースを検索して、マッチするフィンガープリントがあるか否かを判定し、前記送信されたトレースを、前記データベースの検索結果と共に、前記トレースキャッシュに格納し、および
前記フィンガープリントデータベースがマッチするフィンガープリントを含む場合は、前記フィンガープリントに関連するメディアオブジェクト識別情報を、前記サーバから対応するクライアントに送信するステップと
を備えたことを特徴とするコンピュータ読み取り可能媒体。
【請求項２２】
前記トレースキャッシュ内の各トレースは、所定の寿命を有し、さらに、満了した前記寿命を有するトレースはいずれも、関連する全ての前記メディアオブジェクト識別情報と共にトレースキャッシュから削除されることを特徴とする請求項２１に記載のコンピュータ読み取り可能媒体。
【請求項２３】
前記トレースキャッシュ内のトレースに関する前記所定の寿命は、前記トレースキャッシュ内のトレースがメディアストリームトレースとマッチするとき、リセットされることを特徴とする請求項２２に記載のコンピュータ読み取り可能媒体。
【請求項２４】
送信されたトレースと頻繁にマッチする前記トレースキャッシュ内のトレースは、前記所定の寿命に関わりなく永続的に前記トレースキャッシュの中に維持されることを特徴とする請求項２２に記載のコンピュータ読み取り可能媒体。
【請求項２５】
前記トレースキャッシュ内の各トレースは、所定の時間に送信されたどのメディアストリームトレースともマッチに失敗した後で、関連する全てのメディアオブジェクト識別情報と共に前記トレースキャッシュから削除されることを特徴とする請求項２１に記載のコンピュータ読み取り可能媒体。
【請求項２６】
前記トレースキャッシュは一定のサイズを有し、かつ送信されるトレースが前記トレースキャッシュに格納されるときはいつでも、前記トレースキャッシュにおける最も古いトレースが、関連する全てのメディアオブジェクト識別情報と共に前記トレースキャッシュから削除されることを特徴とする請求項２１に記載のコンピュータ読み取り可能媒体。
【請求項２７】
対応する各クライアントに送信された前記メディアオブジェクト識別情報は、各クライアントが監視するキャプチャメディア放送ストリームに埋め込まれた現在ストリームしているメディアオブジェクトの残りの持続時間を含み、および、当該情報を受信しているクライアントはいずれも、前記現在ストリームしているメディアオブジェクトの残りの持続時間の間、トレースを前記サーバコンピュータに送信するのを中止することを特徴とする請求項２１に記載のコンピュータ読み取り可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は 、放送メディアストリーム中のメディアオブジェクトの識別に関し、詳細には、同期データストリーム中の、歌曲のような、メディアオブジェクトの同時サーバ側識別を、多数の個別クライアントに対し、サーバデータベースクエリー負荷を最小にしながら提供するためのシステムおよび方法に関する。
【背景技術】
【０００２】
識別の目的で使用される「特性」を信号から抽出するための基本構想は多数存在する。例えば、オーディオ信号またはオーディオファイル等１次元信号に関しては、オーディオ特性抽出が、オーディオ信号中のメディアオブジェクトの関与する分類、検索、および識別の作業に必要なステップとして使用されて来た。識別のために、抽出特性または「トレース」を、一般的にオーディオ信号内の要素またはオーディオ信号全体の何れかを識別する既知の「フィンガープリント」と比較する。このような公知のメディアオブジェクトの識別の基本構想は、従来「オーディオフィンガープリント法」として公知である。
【０００３】
多数の従来の基本スキームが、このようなオーディオフィンガープリント技術を採用して、ラジオまたはインターネット放送などのオーディオストリーム中の特定の歌曲の識別を提供して来た。例えば、オーディオストリームを聴取するユーザは、ある歌を聴いて、題名、アーティスト、アルバムなどを知りたいと思うことがあるであろう。このとき、従来のオーディオフィンガープリント技術を使用して、歌曲のサンプルから１つまたは複数のトレースを抽出する。典型的には、次いで、これらのトレースを既知の音楽のデータベース内のフィンガープリントと比較してマッチを識別し、その結果をユーザに提供する。
【０００４】
さらに、このような技術は、多数の従来のサービスにも採用されて、一般的にオーディオフィンガープリント技術とデータベース比較に基づく有料歌曲識別またはルックアップサービスを提供して来た。例えば、比較的有名な「ＳＨＡＺＡＭ」音楽識別サービスのようないくつかの歌曲識別サービスが運営され、携帯電話ネットワークを通じて特定の歌曲をユーザのため識別する。詳細には、ＳＨＡＺＡＭが提供するようなシステムは一般的に、ユーザに対し、まず自分の携帯電話で番号をダイアルすること、および次いで約１５〜３０秒間、電話を音楽のほうに向けることを要求することによって動作する。ＳＨＡＺＡＭサービスは次いで、その音楽（または音楽から計算されるトレース）を既知の音楽のデータベースと比較することによってその音楽を識別する。ＳＨＡＺＡＭサービスは、次いで、識別される歌曲の題名、アーティスト、アルバムなどを含むテキストメッセージをユーザに戻す。
【０００５】
【特許文献１】米国特許出願公開第２００３／０２３６６６１号明細書
【特許文献２】米国特許出願公開第１０／６０２，４３８号明細書
【非特許文献１】Christopher J. C. Burges, John C. Platt, Soumaya Jana, “Distortion Discriminant Analysis for Audio Fingerprinting”, IEEE Transactions on Speech and Audio Processing, May 2003, Vol. 11, No. 3, pp 165-174
【非特許文献２】Jonathan Goldstein, John C. Platt, Christopher J. C. Burges, “Indexing High Dimensional Rectangles for Fast Multimedia Identification”, Microsoft Technical Report MSR-TR-2003-38, October 28 2003
【発明の開示】
【発明が解決しようとする課題】
【０００６】
残念なことに、上述の種類のルックアップサービスに伴う１つの問題は、音楽識別システムに対し任意の所定時間にアクセスするユーザ数が増加するにつれて、毎秒のデータベース検索要求の数も増加することである。この問題は、例えば、ＳＨＡＺＡＭが提供するようなサービスにおいては、ユーザは、識別したいと思う歌曲ごとに電話呼出およびサービス自体に対し支払いをしなければならないので、軽減される。この方法によるユーザ課金の効果は、システムの同時ユーザの数を制限する傾向にあり、それによりサーバ負荷全体が減少するからである。このようなシステムに伴う別の問題は、歌曲全体のサンプル（電話サービスの周波数／帯域幅制約により制限される）をサーバに送信する必要があり、サーバは次いで、送信されるメディアストリームのサンプルからトレースを計算する必要があることである。
【０００７】
従って、同時ユーザの数が次第に大きくなるにつれ、入ってくる音楽からトレースまたはフィンガープリントを計算し、これらフィンガープリントの識別のためデータベース検索を実行して個別ユーザに応答するための、それに相当する計算負荷が、比較的大きい専用サーバのバンクをさえも急速に圧倒することがある。その結果、このような基本スキームは、同時ユーザの数が比較的小さいとの仮定により、制限される傾向がある。さらに、このような基本構想の規模を大きくして、多数の同時ユーザを取扱うのに十分な数のサーバを設けることは可能であるけれども、数千万ドルにもなる可能性のあるそのようなシステムに掛かる費用は、抑制すべきものと思われる。
【０００８】
したがって、必要なのは、歌曲のリアルタイム識別を提供するシステムおよび方法である。さらに、当該システムおよび方法は、歌曲識別サービスを多数の同時ユーザに対し効率良く提供する能力がある一方で、同時にサーバ負荷とデータベース検索を最小にしなければならない。最後に、当該システムおよび方法はさらに、複数のクライアントコンピュータの各々によってメディアストリームのサンプルからトレースを計算するタスクを実行することを要求して、その負荷を除去することにより、サーバ負荷を最小にしなければならない。
【課題を解決するための手段】
【０００９】
ここで記述するような「メディア識別子」は、例えば、ラジオ、テレビ、またはインターネット放送のような、ストリーミングメディア放送に内蔵されるメディアオブジェクトのリアルタイムサーバ側識別を、個別クライアントに対し提供することにより、上記で確認した問題を解決するように動作する。これらのメディアオブジェクトは、例えば、歌曲、コマーシャル、ジングル、放送局識別子などを含む。一般的に、メディア識別子は、最低１つのサーバを設けることにより動作する。このサーバは、クライアントそれぞれがメディアストリームのサンプル部分から計算する「トレース」を、既知のフィンガープリントのデータベースと比較することにより、放送メディアストリーム中のメディアオブジェクトのリアルタイム識別を個々のクライアントに提供する。一般的に、計算されたトレースは、クライアントそれぞれがサーバに対して送信し、直接またはサーバ側トレースキャッシュを経由して、既知の識別の、格納され、予め計算されたトレース（ここでは「フィンガープリント」と呼びクライアントが生成するトレースと区別する）の大型データベースと比較される。
【００１０】
詳細には、クライアントごとに、入ってくるメディアストリームの固定長の断片を使用して、低次元「トレース」を繰り返し間隔で計算する。試験実施形態においては、このようなトレースを各クライアントが、メディアストリームの約６秒の程度のサンプルから、毎秒約６回の程度で計算して送付した。明らかに、長短のサンプル採取周期を使用して、多数または少数のトレースを使用することができる。これらのパラメータは、一般的にトレース計算のため使用する特定の技術に従う。
【００１１】
メディアストリームからのトレースの計算は、例えば、特許文献１「ノイズ耐性特性抽出のためのシステムおよび方法（"SYSTEM AND METHOD FOR NOISE-ROBUST FEATURE EXTRACTION"）」（その主題はここに参照により組み込まれている）に記述するシステムのような、従来の方法を使用して達成される。一般的に、このようなシステムは、入ってくるメディアストリームからサンプルを採取するステップと、サンプル値信号から低次元特性ベクトル（すなわち、「トレース」）を計算するステップにより動作する。サンプル値メディアストリームからのトレース計算は、当業者には公知なので、ここで詳細は記述しない。
【００１２】
フィンガープリントデータベースを構成するフィンガープリントは、一般的に、トレースと同様の方法で、同一のアルゴリズムを使用して計算される。しかしながら、トレースと異なり、フィンガープリントは一度だけ、既知フィンガープリントのデータベースを構築するために、メディアオブジェクトごとにサンプルから計算される。一旦作成されると、このデータベースはサーバが単にアクセスするだけで、既知のメディアオブジェクトのためにフィンガープリントを再計算する必要はない。しかしながら、既知のフィンガープリントのデータベースは、次いで、新規のメディアオブジェクト（歌曲など）が作成されるにつれ、新規のフィンガープリントを使用して更新することができる。したがって、既知フィンガープリントのデータベースは、ここに記述するメディア識別子が実行するメディア識別動作の間、サーバ上で余分の計算負荷を除去するため、オフラインで作成し次いで簡単にサーバに提供するのが好適である。
【００１３】
クライアントごとに、サーバは次いで、不完全なマッチを使用して、いずれかのトレースがいずれかのデータベース中のフィンガープリントと何れかの閾値または許容値の範囲内でマッチするか否かを判定する。このような不完全なマッチの技術を使用することは、完全なマッチの技術よりも好ましい。任意のクライアントが計算するトレースは、トレースがメディアストリームの正確に同一の部分から計算される場合であっても、ノイズ、混信、信号減衰などのため変化することがあるからである。その上、不完全なマッチの使用は、トレースを計算するメディアストリームの標本採取部分の小さい一時的オフセットをも考慮に入れる。一実施形態において、不完全なマッチは、非特許文献１に記述されている技術において知られているように、フィンガープリント固有の再正規化を使用して正確度を改良する。
【００１４】
一人のクライアントからのトレースがマッチするときはいつでも、サーバはそのクライアントに対し、そのトレースに相当する特定メディアオブジェクトの識別を知らせる。歌曲のようなメディアオブジェクトの場合、この識別は、一般的に、例えば、アーティスト、曲名、アルバム名、ジャンルなどの情報を含む。明らかに、既知メディアオブジェクトが与えられると、任意の所望の情報を、そのメディアオブジェクトの識別に使用されるデータベース中のフィンガープリントに関連付けることができる。
【００１５】
しかしながら、サーバに送付されるトレースごとにフィンガープリントデータベースの強引な強制検索を準備する代わりに、ここに記述するメディア識別子は、付加的なサーバ側キャッシュを導入する。このキャッシュは、存在するメディアストリームは有限数であること、および任意の所定時間に同一メディアストリームを受信するユーザは一般的に多数であることを仮定すると、任意の時刻に、ユーザ生成トレースの多くはほとんど同一であると考えられるという事実を利用する。言い換えると、任意の所与の時点において、特定のラジオ、テレビ、またはインターネット放送等の同一メディアストリームを聴取する多数の人々が、潜在的には数十万人または百万人さえ、存在すると思われる。この所見により、入ってくるトレースとマッチするフィンガープリントに関するデータベース検索の結果との両方をキャッシュするサーバ側キャッシュを作成することができる。
【００１６】
詳細には、各クライアントから入ってくる各トレースを、まず若干数のトレースを含むキャッシュに対して検査する。トレースがキャッシュに無いときは、完全データベース検索をおこない、そのデータベース検索の結果を、肯定的でも否定的でも、クライアントが送付するトレースと共にキャッシュに格納する。キャッシュとデータベース両方の検索は、例えば、ベーリング（ｂａｉｌｉｎｇ）（線形走査を使用する相違比較の速度を上げるための公知の方法）を使用する線形走査（すなわち、逐次）等の、従来技術を使用して行う。
【００１７】
別の実施形態において、データベースの検索は、同時係属の特許文献２「ビットベクトルインデックス付与を使用する多次元データオブジェクト検索（"Multidimensional Data Object Searching Using Bit Vector Indices"）」（その主題はここに参照により組み込まれている）に記述するような、ビットベクトルインデックス付与の使用により加速される。ビットベクトルインデックス付与法はまた、非特許文献２（その主題はここに参照により組み込まれている）にも記述されている。
【００１８】
一般的に、上記の米国特許出願およびそれに相当するマイクロソフト技術報告書に記述するビットベクトルインデックス付与法は、高次元領域に対するポイントクエリーを迅速に実行する問題に対処する。このようなクエリーは、重要性を増しつつあるマルチメディア識別および検索の問題において有用である。ここでは、異なるデータベースエントリが同一性に関し異なる尺度を有する。高次元最近接物およびイプシロン範囲クエリーのためのインデックス付与に焦点を合わせる典型的データベースインデックス付与とは対照的に、高次元領域に対するポイントクエリーのためのインデックス付与は、冗長度とビットベクトルインデックス付与の組合せに依存して顕著な性能利得を達成する効率の良いインデックス付与法を提供する。このような方法は、実在の線形走査を超える著しい性能増加を与えることが観察されて来た。
【００１９】
データベース検索の否定的な結果、すなわち、データベース内のフィンガープリントに対するトレースのマッチが無いことは、クライアントには送信さない。データベース検索の肯定的な結果、すなわち、トレースとフィンガープリントとの間のマッチは、トレースを計算したメディアオブジェクトを識別するため、クライアントに送信する。上述したように、フィンガープリントデータベースを検索する前に、キャッシュを検索してマッチトレースを確認する。従って、キャッシュに格納されるトレースに対しマッチが見出されるときは、それ以上のデータベース検索は必要がなくなる。キャッシュ内のトレースは、関連するメディアオブジェクトの識別を含むか、または単にマッチするフィンガープリントが無いことを示すだけかの何れかだからである。トレースがデータベース内のフィンガープリントにマッチする場合は、そのマッチするフィンガープリントに関連する任意の識別情報を、クライアントに返信する。
【発明の効果】
【００２０】
メディア識別子が提供するサーバ側キャッシュの長所の１つは、キャッシュのサイズが比較的小さく、キャッシュ検索が極めて迅速になることである。特に、キャッシュのサイズは、クライアント間のメディアストリーム内のポイント受信に関する最大予想遅延と、識別サービスを提供する独自のメディアストリームの数の関数である。さらに、キャッシュのサイズはユーザ数の関数ではないことに注意されたい。
【００２１】
特に、各特定メディア放送ストリームは、その特定メディアストリームを受信する各クライアントについてほぼ同期している。例えば、同一ラジオ放送局を受信する任意の二人以上のクライアントは、約１秒かその程度の極めて小さい時間のオフセットの範囲内で、同一信号を受信していると思われる。ほとんどのストリーミングメディアのインターネットまたはネットワーク放送についても同様である。
【００２２】
したがって、最大予想遅延時間（遅延時間には、各クライアントがトレースを計算してサーバに対し送信するための最大予想遅延をも含む）よりも長い間、トレースをメディアキャッシュ内に保持する必要はない。言い換えると、この遅延は単に、サーバの特定メディアオブジェクトの所定の区画に関する最初のトレースの受信と、サーバの同一メディアオブジェクトの区画に関する（最も遅いクライアントからの）最後のトレースの受信との間の最大時間である。従って、トレースは数秒程度の短い期間だけ保持すればよい。その結果、固有の入ってくるトレース全てを記憶する大きいキャッシュの必要はない。
【００２３】
関連する実施形態では、キャッシュ内のトレース寿命を設定するため最大遅延を判定または評価しようとするよりもっと簡単な解決策は、約１秒またはその程度の短時間の範囲でどのような入力トレースとのマッチにも失敗した後、単にトレースをキャッシュから削除することである。更に代替の実施形態においては、例えば、従来のＬＲＵ（使用頻度が最も低い（least recently used））論理に基いてトレースを落とす固定キャッシュサイズの使用を含む、別のキャッシュイングスキームも使用することが出来る。
【００２４】
上の要約の観点から、ここに記述するメディア識別子が、同期メディア放送ストリームについての多数の同時クライアント要求に関するリアルタイムメディア識別のため独自のシステムおよび方法を提供する。たった今記述した利点に加えて、メディア識別子の別の長所は、後続の添付図面との関連で行う詳細な説明から明らかになるであろう。
【発明を実施するための最良の形態】
【００２５】
本発明の固有の特性、態様、および利点は、以下の記述、添付の請求項、および添付図面との関連でさらに良く理解されるであろう。
【００２６】
本発明の好適実施形態に関する以下の記述においては、本文書の一部を形成し、例証として本発明が実用される具体的実施形態を示す添付図面を参照する。本発明の範囲を逸脱することなく別の実施形態を使用し構造的な変更を行ってもよいことは理解されよう。
【００２７】
（１．０  動作環境例）
図１に、本発明の実施される適切なコンピューティングシステム環境１００を示す。コンピューティングシステム環境１００は、適切なコンピューティングシステム環境の一例に過ぎず、本発明の使用または機能の範囲に関し何ら制限を加えるものではない。コンピューティング環境１００は、動作環境例１００に示す構成部品のうちいずれか１つまたは組合せに対し何らかの従属性または要件を有すると解釈すべきでもない。
【００２８】
本発明は、多数の別の汎用または専用コンピューティングシステム環境または構成と共に動作する。本発明と共に使用するため適切な公知のコンピューティングシステム、環境および／または構成の例は、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド、ラップトップまたはモバイルコンピュータまたは携帯電話および携帯情報端末のような通信装置、マルチプロセッサシステム、マイクロプロセッサに基づくシステム、セットトップボックス、プログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、大型コンピュータ、上述のシステムまたは装置のいずれかを含む分散コンピューティング環境等を含むが、これに限定されるものではない。
【００２９】
本発明は、マイクロホンアレー１９８のコンポーネントを含むハードウエアモジュールとの組合せにおいて、コンピュータにより実行されるプログラムモジュール等のコンピュータ実行可能命令の一般的なコンテキストにおいて記述される。一般的に、プログラムモジュールは、特定のタスクを実行するかまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などを含む。本発明は、１つの通信ネットワークによってリンクされたリモート処理装置によってタスクが実行される分散コンピューティング環境において実施されてもよい。分散コンピューティング環境において、プログラムモジュールは、メモリストレージ装置を含むローカルおよびリモート両方のコンピュータストレージ媒体の中に置かれる。図１を参照すると、本発明を実装するためのシステム例は、コンピュータ１１０の形で、汎用コンピューティング装置を含む。
【００３０】
コンピュータ１１０のコンポーネントは、これに限定されないが、処理装置１２０、システムメモリ１３０、および、システムメモリを含む各種システムコンポーネントを処理装置１２０に結合するシステムバス１２１を含む。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバズアーキテクチャのいずれかを使用するローカルバスを含む数種のバス構造のうちのいずれでも差し支えない。例示のためであり、限定ではないこのようなアーキテクチャは、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスを含む。
【００３１】
コンピュータ１１０は、典型的に、様々なコンピュータ読み取り可能媒体を含む。コンピュータ読み取り可能媒体は、コンピュータ１１０がアクセスすることのできる任意の利用可能な媒体であり、揮発性および不揮発性媒体、取り外し可能および固定の媒体の両方を含む。例示のためであり、限定ではない、コンピュータ読み取り可能媒体は、コンピュータストレージ媒体および通信媒体を備えていてもよい。コンピュータストレージ媒体は、揮発性および不揮発性で取り外し可能および固定であり、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、または他のデータのような情報を格納するための任意の方法または技術を使用して実装される媒体を含む。
【００３２】
コンピュータストレージ媒体は、これに限定されないが、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術を含み、また、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光ディスクストレージを含む。さらに、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージ装置、または所望の情報を格納するのに使用すること、およびコンピュータ１１０がアクセスすることのできる任意の他の媒体を含む。通信媒体は、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、またはその他のデータを、搬送波またはその他の移送機構のような変調データ信号で実現し、任意の情報配送媒体を含む。「変調データ信号」と言う用語は、信号内の情報を符号化するように設定または変更された特徴を１つまたは複数有する信号を意味する。通信媒体は、それだけには限定されないが一例として、有線ネットワークまたは直接配線された接続のような有線媒体、および音響、ＲＦ、赤外線およびその他の無線媒体のような無線媒体を含む。また上記のどんな組み合わせでも、コンピュータ読み取り可能媒体の範囲内に含まれる。
【００３３】
システムメモリ１３０は、読取専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２のような、揮発性および／または不揮発性メモリの形のコンピュータストレージ媒体を含む。スタートアップ中などにコンピュータ１１０内の要素間で情報を転送する基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）は、典型的にＲＯＭ１３１内に格納される。ＲＡＭ１３２は、処理装置１２０によって即座にアクセス可能であり、かつ／または現在動作中のデータおよび／またはプログラムモジュールを一般的に含む。例のためであり、限定ではなく、図１に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。
【００３４】
コンピュータ１１０は、別の取り外し可能／固定で、揮発性／不揮発性のコンピュータストレージ媒体も含む。例示のために過ぎないが、図１は、固定で不揮発性の磁気媒体からの読み取りまたはそれへの書き込みを行うハードディスクドライブ１４１、取り外し可能で不揮発性の磁気ディスク１５２からの読み取りまたはそれへの書込を行う磁気ディスクドライブ１５１、およびＣＤＲＯＭまたは他の光媒体などの取り外し可能で不揮発性の光ディスク１５６からの読み取りまたはそれへの書き込みを行う光ディスクドライブ１５５を示す。動作環境例で使用することのできる他の取り外し可能／固定で揮発性／不揮発性のコンピュータストレージ媒体は、これに限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどが含まれる。ハードディスクドライブ１４１は一般的に、インターフェイス１４０のような固定のメモリインターフェイスを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般的に、インターフェイス１５０のような取り外し可能メモリインターフェイスによってシステムバス１２１に接続される。
【００３５】
上に説明し図１に示すドライブおよびそれに関連するコンピュータストレージ媒体は、コンピュータによって読み取り可能な、命令、データ構造、プログラムモジュールおよび他のデータをコンピュータ１１０に提供する。図１において、例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして示す。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであっても異なっていてもよいことに注意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、ここでは異なる番号を与え、少なくともこれらが異なるコピーであることを示す。ユーザは、キーボード１６２、および普通はマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１のような、入力装置を介して、コンピュータ１１０にコマンドおよび情報を入力する。
【００３６】
別の入力装置（図示せず）は、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナ、ラジオ受信機、およびテレビまたは放送ビデオ受信機などを含む。これらおよび他の入力装置は、システムバス１２１に結合される有線または無線のユーザ入力インターフェイス１６０を介して処理装置１２０に接続されることが多いが、例えば、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）、ＩＥＥＥ１３９４インターフェイス、ブルートウース・無線インターフェイス、ＩＥＥＥ８０２．１１無線インターフェイスなど、他の従来のインターフェイスおよびバス構造によって接続されてもよい。さらに、コンピュータ１１０は、マイクロホンまたはマイクロホンアレー１９８のようなスピーチまたはオーディオ入力装置ばかりでなく、例えば、パラレル、シリアル，ＵＳＢ、ＩＥＥＥ１３９４、ブルートウース・のような従来の有線または無線インターフェイスを含むオーディオインターフェイス１９９を介して接続されるラウドスピーカ１９７または他の音響出力装置（sound output device）をも含む。
【００３７】
モニタ１９１または他の種類の表示装置も、ビデオインターフェイス１９０のようなインターフェイスを介してシステムバス１２１に接続される。モニタに加えて、コンピュータは、プリンタ１９６のような他の周辺出力装置を含み、周辺出力装置は、出力周辺装置インターフェイス１９５を介して接続されてもよい。
【００３８】
コンピュータ１１０は、リモートコンピュータ１８０のような、１つまたは複数のリモートコンピュータへの論理接続を使用するネットワーク環境において動作することもできる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の一般のネットワークノードであってよく、一般的に、コンピュータ１１０に関して上述した要素の多数または全部を含むが、図１にはメモリストレージ装置１８１のみを示す。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークも含んでもよい。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいてはごく一般的である。
【００３９】
ＬＡＮネットワーク環境において使用するとき、コンピュータ１１０は、ネットワークインターフェイスまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーク環境において使用するとき、コンピュータ１１０は、インターネットなどのＷＡＮ１７３上に通信を確立するためにモデム１７２または他の手段を一般的に含む。内蔵または外付けのモデム１７２は、ユーザ入力インターフェイス１６０、または別の適切な機構を介してシステムバス１２１に接続されてよい。ネットワーク環境において、コンピュータ１１０またはその部分に関して示されたプログラムモジュールを、リモートストレージ装置に格納してもよい。例示のため、制限ではなく、図１は、メモリ装置１８１に常駐するものとしてリモートアプリケーションプログラム１８５を示す。図示のネットワーク接続は例であって、コンピュータ間に通信リンクを確立する別の手段を使用して差し支えないことは理解されよう。
【００４０】
ここで動作環境例の記述を終え、この説明の残りの部分は、ストリーミングメディア放送に埋め込まれたメディアオブジェクトのリアルタイムサーバ側での識別をクライアントに提供する「メディア識別子」を実施するプログラムおよびプロセスの記述に専念する。
【００４１】
（２．０  序論）
「メディア識別子（Media Identifier）」は、ここに記述するように、ラジオ、テレビ、またはインターネット放送のような監視されたメディアストリームに埋め込まれたメディアオブジェクトのリアルタイムの識別を個別のクライアントに提供する。このようなメディアオブジェクトは、歌曲、コマーシャル、ジングル、放送局の識別子などを含む。
【００４２】
一般的に、メディアオブジェクトの識別は、クライアントによって生成された「トレース」を、既知の識別の、格納され、かつ予め計算されたトレース（ここでは、「フィンガープリント」と呼んでクライアントによって生成されたトレースと区別する）の膨大なデータベースと比較することによって、個別のクライアントに提供される。これらのクライアントによって生成されたトレースは、メディアストリームのサンプルから各クライアントが継続して計算され、識別のためにサーバに送信される。
【００４３】
さらに、有限数のメディアストリームとそれよりはるかに多数のクライアントが与えられた場合でも、クライアントの多くは、同時に同じメディアストリームを監視するので、サーバに送られるトレースの多くは、ほぼ一致すると思われる。この所見は、特定のトレースを識別するのに必要なデータベースクエリーの数を制限するために、検索可能な動的トレースキャッシュの作成において使用され、およびこのようにしてメディアオブジェクトがこれらのトレースと関連付けられる。データベースではなくトレースキャッシュを検索することの利点の１つは、トレースキャッシュが一般的に、桁違いに小さくできる一方で、フィンガープリントの機能的なデータベースが、何百万ものエントリを一般的に含むことができることである。
【００４４】
トレースキャッシュは、様々なクライアントが送った最新トレースの１つのコピーのみを、肯定的または否定的両方のデータベース検索結果と共にキャッシュする。言い換えると、１つのクライアントが送ったトレースで現在キャッシュに存在しないトレースはいずれも、以下に詳しく説明するように、少なくとも一時的にキャッシュ内に格納される。そのためデータベースクエリーを行う前にトレースキャッシュを検索する。データベースは、トレースキャッシュ内にマッチするトレースがないとき、クライアントによって生成された新規のトレースを識別するためだけにクエリーされる。さらに、トレースキャッシュに格納されるトレースは、時間の経過と共に削除される。一実施形態において、これは予め設定された単なる「寿命」であるが、関連した実施形態においては、この存続時間は、いずれかのクライアントによって、マッチする最後のトレースが送られてから後の時間に基づく。言い換えると、キャッシュのエントリは、マッチするトレースのヒットが無いまま古くなるのに伴い、キャッシュから機械的に削除される。
【００４５】
これらの一般概念を図２のアーキテクチャシステムのダイアグラムに示す。これは、メディア識別子を実装するためのコンポーネント間の全体的な機能的関係を示す。具体的には、図２は、複数のクライアント２００の各々がメディア放送ストリーム２１０を受信することを示す。ここに詳細を説明するように、ラジオ局放送、テレビまたは有線放送、ネットワークベースのストリーミングメディアなどのような利用可能なメディアストリーム２１０の母集団は、潜在的なクライアント２００の数よりも実質的に小さい。その結果、メディアストリーム２１０の多くは、２つ以上のクライアント２００によって同時に監視され、何百、何千、もしくは何百万ものクライアントによって監視される可能性もある。しかしながら、メディアストリームは、ローカルに利用することのできる放送を含み、クライアントは、インターネット２２０または他のネットワークを介してサーバ２３０と通信しながら、世界のいかなる場所にも位置することができるが、全クライアント２００が、全てのメディアストリーム２１０を利用し得るわけではないことに注意されたい。
【００４６】
クライアント２００は、監視したメディアストリーム２１０からサンプルを取り、計算されたトレースをネットワークまたはインターネット２２０を介してサーバ２３０（またはサーバのバンク）に送る。次いで、サーバ２３０は、トレースキャッシュ２４０を検査し、必要であれば、フィンガープリントデータベース２５０を検査して、トレースが生成されたメディアオブジェクトを識別しようと試みる。識別された場合、特定のトレースに対応するメディア識別情報を、サーバ２３０がネットワーク２２０を介してクライアント２００に戻す。
【００４７】
（２．１  システム概観）
上述したように、ここに記述するメディア識別子は、クライアントに、例えば、ラジオ、テレビ、またはインターネット放送のようなストリーミングメディア放送に埋め込まれたメディアオブジェクトのリアルタイムなサーバ側での識別を提供する。一般的に、メディア識別子は、少なくとも１つのサーバを設けることによって動作する。このサーバは、各クライアントがメディアストリームのサンプル部分から計算する「トレース」を既知のフィンガープリントのデータベースと比較することによって、放送メディアストリーム内のメディアオブジェクトのリアルタイムな識別を個別のクライアントに提供する。一般的に、計算されたトレースは、各クライアントがサーバに送り、直接か、またはサーバ側のトレースキャッシュを経由するかのいずれかによって、格納されている予め計算された既知の識別のフィンガープリントの膨大なデータベースと比較される。
【００４８】
次にサーバは、クライアントごとに、不完全なマッチを使用していずれかのトレースがデータベース内のいずれかのフィンガープリントと閾値または許容範囲の内でマッチするか否かを判定する。このような不完全なマッチ技術の使用は、完全なマッチ技術よりも好適である。任意のクライアントによって計算されるトレースは、トレースがメディアストリームの名目上同じ部分から計算される場合であっても、ノイズ、干渉、信号減衰などのためにある程度変化するからである。その上、不完全なマッチの使用は、トレースを計算するメディアストリームのサンプリング部分の小さい一時的オフセットをも考慮に入れる。
【００４９】
クライアントからのトレースが（トレースキャッシュまたはフィンガープリントデータベースのどちらかにおいて）あるフィンガープリントにマッチするときはいつでも、サーバは、クライアントに、そのトレースに対応する特定のメディアオブジェクトの同一性を知らせる。歌曲のようなメディアオブジェクトの場合、この同一性は、一般的に、例えば、アーティスト、歌曲の題名、アルバム名、ジャンルなどといった情報を含む。既知のメディアオブジェクトが与えられると、任意の所望の情報を、そのメディアオブジェクトの識別に使用されるデータベース内のフィンガープリントに関連させることができることは明らかである。
【００５０】
しかしながら、サーバに送られるトレースごとにフィンガープリントデータベースをくまなく強制的に検索する代わりに、ここに記述したメディア識別子は、追加のサーバ側のトレースキャッシュを導入する。サーバ側のトレースキャッシュは、いつでも、ユーザが生成したトレースの多くはほぼ同一であり得るという事実を利用し、メディアストリームの有限数があること、および与えられた任意の時間に同じメディアストリームを受信している多くのユーザがいることを仮定する。言い換えると、与えられた任意の時点において、特定のラジオ、テレビ、またはインターネット放送のような同じメディアストリームを聞いている人々は、多数、可能性としては数万人または百万人さえも、存在すると思われる。この所見により、入ってくるトレースおよびマッチするフィンガープリントに関するデータベースの検索結果の両方をキャッシュするサーバ側キャッシュを作成することを許容する。
【００５１】
具体的には、各クライアントから入ってくる各入ってくるトレースを、まず若干数のトレースを含むトレースキャッシュに対して検査する。トレースがキャッシュに無い場合は、トレースをそのキャッシュに格納して、データベースの完全なルックアップ（look up）を行う。そのデータベースルックアップの結果を、肯定的でも否定的でも、クライアントが送ったトレースと共にトレースキャッシュに格納する。トレースキャッシュとデータベース両方におけるルックアップは、例えば、（すなわち、連続して）ベーリング（線形走査を使用する距離比較の速度を上げるための公知の方法）を使用する線形走査のような、従来技術を使用して行う。
【００５２】
別の実施形態において、データベースのルックアップは、特許文献２に記述するような、ビットベクトルインデックス付与の使用により加速される。このビットベクトルインデックス付与法は、非特許文献２にも記述されている。
【００５３】
一般的に、前述の特許文献２およびそれに対応する非特許文献２に記述されたビットベクトルインデックス付与法は、高次元領域に対するポイントクエリーを迅速に実行する問題に取り組む。このようなクエリーは、重要性を増しつつあるマルチメディアの識別および検索の問題において有用である。ここでは、異なるデータベースエントリが類似性に関し異なる尺度を有する。高次元最近接およびイプシロン範囲クエリーのためにインデックスを付与することに焦点を合わせる典型的なデータベースのインデックス付与とは対照的に、高次元領域に対するポイントクエリーのためのインデックス付与は、冗長性とビットベクトルインデックス付与との組合せに依存して顕著な性能向上を達成する効率の良いインデックス付与法を提供する。このような方法は、実在の線形走査を超える性能の顕著な増加を与えることが認められている。
【００５４】
前述のデータベース検索の実施形態の各々では、データベース検索の否定的な結果、すなわちデータベース内のフィンガープリントにトレースのマッチが無いことは、クライアントに送信されない。データベース検索の肯定的な結果、すなわちトレースとフィンガープリントとの間のマッチは、トレースが計算されたメディアオブジェクトを識別することができるようにクライアントに送信される。上述したように、フィンガープリントデータベースを検索する前に、キャッシュを検索してマッチするトレースを識別する。その結果、キャッシュに格納されたトレースに関してマッチが見出された場合は、キャッシュ内のトレースが関連するメディアオブジェクトの識別を含むためか、またはマッチフィンガープリントが無いことを単に示しているとして、それ以上のデータベースのルックアップは必要ない。トレースがデータベース内のトレースとマッチする場合は、そのマッチするトレースに関連する全ての識別情報をクライアントに送信する。
【００５５】
（２．２  システムアーキテクチャ概観）
一般的なシステムダイアグラムによって、上に要約したプロセスを図３に示す。具体的には、図３のシステムダイアグラムは、ここに記述するようなメディア識別子を実装するためのプログラムモジュール間の相互関係を示す。
【００５６】
一般的に、メディア識別子は、各クライアントが、メディアストリームを受信するためのメディアストリームキャプチャモジュール３０５を使用してメディアストリーム２１０のうちの１つを受信し終えることによって、各クライアント２００に関する動作を開始する。メディアストリーム２１０は、オーディオストリーム、ビデオストリーム、または両者が混ざり合ったものであることに注意されたい。次にクライアント２００は、メディアストリームサンプリングモジュールを用い、リアルタイムで入ってきたメディアストリームからサンプリングする。各クライアントはトレース計算モジュール３１５を使用して、サンプリングしたメディアストリームから連続的にトレースを生成する。各クライアントによって生成されたトレースの数および頻度は、以下のセクション３においてさらに詳細に記述することに注意されたい。生成されたトレースは、トレース送信モジュール３２０に提供され、これがトレースをネットワークまたはインターネット２２０を介してサーバ２３０に送信する。
【００５７】
続いてサーバ２３０は、様々なクライアント２００から送信されたトレースを受信するためのトレース受信モジュールを使用する。サーバ２３０が様々なクライアント２００からトレースを受信し始めるとすぐに、そのトレースはトレースルックアップモジュール３３５に提供される。このモジュールは、まずトレースキャッシュ２４０を検索して、マッチするトレースを検出する。トレースキャッシュ内にマッチするトレースがない場合は、そのトレースをトレースキャッシュ内に格納し、トレースルックアップモジュール３３５を使用してフィンガープリントデータベース２５０の検索を実行する。
【００５８】
最後に、キャッシュ維持モジュール３４５が、キャッシュの全般的なクリーンアップ動作を準備する。具体的には、上述したように、サーバ２３０によって受信され、トレースキャッシュ２４０内で検出できない全トレースを、対応するデータベースの検索結果（肯定的または否定的のどちらか）と共にキャッシュに追加する。しかしながら、このプロセスに何らかの制限がないと、トレースキャッシュ２４０は急速にオーバーフローしてしまう。このように、セクション３で詳細に記述するように、トレースキャッシュは、時間の関数として古いトレースに関しクリーンアップを行う。詳細には、一実施形態において、キャッシュ維持モジュール３４５は、ある所定の期間より古いトレースをキャッシュから削除する。またはそれに替えて、キャッシュ維持モジュール３４５は、ある所定の期間中に、トレースルックアップモジュール３３５によって入ってくるトレースとマッチされなかったトレースを全て削除する。さらに別の実施形態において、キャッシュ維持モジュール３４５は、これらトレース寿命の組合せ、または肯定的データベース２５０ヒットおよび否定的データベースヒットを有するトレースについて異なる寿命のどちらか一方を使用する。
【００５９】
（３．０  作業量超過）
上述のプログラムモジュールは、メディア識別子の実装のために採用される。上に要約したように、メディア識別子は、ラジオまたはインターネット放送のような監視されたメディアストリームに埋め込まれたメディアオブジェクトのリアルタイムな識別を個別クライアントに提供する。以下のセクションは、メディア識別子の動作に関する詳細な記述、および図２および図３に関してセクション２に記述したプログラムモジュールを実装するための例示的な方法に関する動作の詳細記述を提供する。加えて、下記の３．１章に示すメディア識別子の動作の詳細な記述に続き、図４に関し、この詳細な記述に鑑みたメディア識別子の全体的な動作を要約した動作の流れ図を示す。
【００６０】
（３．１  メディア識別子の動作の詳細）
以下の段落では、ここに記述するメディア識別子の固有の動作および代替的な実施形態を詳述する。具体的には、以下の章で、トレースの計算およびフィンガープリントデータベースの構築、トレースキャッシュにおけるトレースの寿命、トレースキャッシュの検索、データベースの検索、ダウンロードしたフィンガープリントデータベースのサブセットを使用するローカルクライアントデータベースのルックアップ、および最後にクライアントに対するメディアオブジェクト識別の提供を記述する。
【００６１】
（３．１．１  トレースの計算およびフィンガープリントデータベースの構築）
メディアの識別に使用するためのオーディオ信号またはオーディオストリームのサンプルからのトレースまたは「フィンガープリント」の計算は、当業者には良く理解されている概念である。一般的に、このようなシステムは、入ってくるメディアストリームからサンプリングすることと、サンプリングした信号からコンパクト特性ベクトル（すなわち、「トレース」）を計算することにより動作する。これらのコンパクト特性ベクトルは、低次元ベクトルを備えるか、またはバイナリハッシュキーを備えることができる。メディアストリームサンプル値からのトレース計算は、当業者に既知であるため、この問題はここでは詳細に記述しない。
【００６２】
メディア識別子に関しては、メディアストリームからのトレースの計算は、多数の従来技術のうちの任意の１つを使用して達成される。例えば、メディア識別子の試験済みの実施形態において使用されたトレース計算は、特許文献１に記述されている。
【００６３】
前述の特許文献１に記述されるシステムは、一般的に、人工および／または実環境の信号を混ぜ合わせたもので「歪み弁別解析（Distortion Discriminant Analysis）」（ＤＤＡ）を使用して訓練し、そのパラメータを定義する「特性エキストラクタ（feature extractor）」を使用してオーディオ信号から特性を計算または抽出することにより動作する。記述した特性エキストラクタは、時間的または空間的構造を伴う１つまたは複数の次元を有する信号を取得し、信号の限られた範囲に指向性主要構成要素分析（ＯＰＣＡ）を適用し、空間的または時間的に隣接する複数のＯＰＣＡの出力を総計して、その総計にＯＰＣＡを適用する。隣接ＯＰＣＡ出力を総計するステップ、および総計値にＯＰＣＡを適用するステップは、オーディオ信号、画像、ビデオテータまたは任意の他の時間または周波数のドメイン信号を含む信号から、低次元のノイズ耐性特性を抽出するために、１回または複数回実行される。一旦訓練すると、その特性エキストラクタを単に使用するだけで、ここに記述するメディア識別子が使用するトレース（およびフィンガープリント）を生成する。
【００６４】
しかしながら、上述したように、上で確認した「特性エキストラクタ」は、明らかにトレースまたはフィンガープリントを計算するための唯一の方法ではない。トレースまたはフィンガープリントをどのように計算するかに関わりなく、基本的な考え方は、入ってくるメディアストリームの一定の長さのセグメントであるコンパクト「トレース」をクライアントごとに計算することである。試験ずみの実施形態においては、このようなトレースが、各クライアントによって、１秒間に約６回程度、メディアストリームの約６秒程度のサンプルから計算され送られる。明らかに、これらパラメータは、一般的にトレース計算に用いられる特定の方法に依存するので、より長い、またはより短いサンプリング周期を使用するより多い、またはより少ない数のトレースを用いることができる。
【００６５】
フィンガープリントデータベースを備えるフィンガープリントは、各クライアントによって計算されるトレースとフィンガープリントデータベースの母集団を作るために使用されるフィンガープリントとの間に明確な対応があるように、一般的にはトレースと同じ方法で、同じアルゴリズムを使用して計算される。しかしながら、メディアストリームの進行に伴い連続的に計算されるトレースとは異なり、フィンガープリントは、既知のメディアオブジェクトに対応するフィンガープリントをデータベースの母集団とするように、この既知のメディアオブジェクト内の特定の位置からサンプリングされる１つまたは複数のサンプルから、一度だけ計算される。メディアオブジェクトごとに計算されたフィンガープリントの数は、所望に応じて少なくも多くもすることができる。しかしながら、試験ずみの実施形態においては、メディアオブジェクト当たり数個のフィンガープリントを備えることが、オブジェクトの安定した識別を備えるのに十分であることが認められた。
【００６６】
一旦作成すると、フィンガープリントデータベースは、単にサーバによってアクセスされるだけで、ここに記述するように、既知のメディアオブジェクトのためにフィンガープリントを再計算する必要はい。しかしながら、既知のフィンガープリントのデータベースは、新規のメディアオブジェクト（歌曲など）が作成されるのに伴い、新規のフィンガープリントによって更新することができる。このように、既知のフィンガープリントのデータベースは、クライアントがトレースを計算するため使用する何らかのトレース計算アルゴリズムを使用してオフラインで好適に作成され、ここに記述するメディア識別子が実行するメディアの識別動作中、サーバに掛かる余計な計算負荷を取り除くようにサーバに提供される。
【００６７】
（３．１．２  トレースキャッシュの寿命）
メディア識別子が提供するサーバ側トレースキャッシュの１つの長所は、キャッシュのサイズが比較的小さく、キャッシュ検索を極めて迅速にすることである。具体的には、キャッシュのサイズは、各クライアントからの要求の間での最大予測遅延と、識別サービスを提供する独自のメディアストリームの数の関数である。さらに、キャッシュのサイズは、トレース識別要求とともにサーバにアクセスする個別のクライアントまたはユーザの数の関数ではないことに注意すべきである。
【００６８】
詳細には、特定の各メディア放送ストリームは、その特定のメディアストリームを受信するクライアントごとにほぼ同期している。例えば、同じラジオ局を受信する任意の２つ以上のクライアントは、受信するメディアのタイプとソースによって１秒かその程度の非常に短い最大時間オフセットの範囲内で同じ信号を受信していると考えられる。ほとんどのストリーミングメディアのインターネットまたはネットワーク放送についても同じことが真である。
【００６９】
したがって、極僅かな最大予想クライアント間遅延時間（遅延時間には、クライアントごとにトレースを計算してサーバに送信するための最大予想遅延も含む）より長い間、トレースをメディアキャッシュの中に保つ必要はない。言い換えると、この遅延は単に、サーバが特定のメディアオブジェクトの所与のセクションに関する最初のトレースの受信と、サーバが同じメディアオブジェクトの所定のセクションに関する（最も遅いクライアントからの）最後のトレースの受信との間の最大時間である。よって、トレースは、数秒程度の短い期間の間保つ必要があるだけである。その結果、固有の入ってくるトレース全部を格納するための大きいキャッシュは必要でない。
【００７０】
関連した実施形態における、キャッシュ内のトレース寿命を設定するために最大遅延を判定または推定しようとするよりも簡単な解決法は、約１秒程度の短時間にわたって、入ってくる全トレースとのマッチに失敗した後、単にトレースをキャッシュから削除することである。さらなる代替の実施形態においては、例えば、従来のＬＲＵ論理に基づいてトレースを落とす固定キャッシュサイズの使用を含む別のキャッシュ作成スキームも使用することができる。
【００７１】
（３．１．２  トレースキャッシュ検索）
上述したように、サーバがいずれかのトレースを受信すると、直ちにトレースキャッシュを検索して、トレースキャッシュの中に、マッチするトレースがあるか否かを判定する。マッチがある場合は、そのマッチするトレースがいかなるメディアオブジェクト識別情報を有するか否か、またはそのトレースがデータベースで検出されなかったトレースであるか否かに関する判定を行う。ここでも、トレースキャッシュに検出されないトレースは、トレースキャッシュに追加され、データベースを直ちに検索してそのトレースがデータベースの中に存在するか否かを判定する。
【００７２】
入ってくるトレースがトレースキャッシュ内のいずれのトレースとマッチするか否かの判定は、従来の信号を比較する技術を使用して行う。そのような技術には、例えば、従来のクロス相関、および入ってくるトレースの点をトレースキャッシュ内の各トレースと直接比較する線形走査が含まれる。どちらの場合も不完全なマッチが好適である。上述のように、任意の異なるクライアントが計算するトレースは、トレースがメディアストリームの名目上は同じ部分から計算される場合であっても、ノイズ、干渉、信号減衰などのため変化することがあるからである。完全なマッチを使用することはできるが、マッチするトレースの識別において効率が低いことが証明されている。一実施形態において、不完全なマッチは、非特許文献１に記述するような、当業分野で既知のようなフィンガープリント固有の再正規化を使用して正確度を改良する。
【００７３】
不完全なマッチの場合は、マッチを何らかの距離尺度ｆおよび対応する閾値θに関して判定する。例えば、トレースが低次元ベクトルであるとき、入ってくるトレースＸをキャッシュされたトレースのセットＹと直接比較する、トレース間の比較を行う１つの簡単な方法は、ｊのインデックスを与えてトレースごとに１度だけ、式１においてユークリッド距離の二乗を単に比較することである。
【００７４】
【数１】
2006146883.tif 000003
【００７５】
ここで、ｘiはトレースのｉ番目の要素、ｙijはｊ番目のキャッシュトレースのｉ番目の要素、ｎはトレースベクトルのコンポーネントの数、およびθjはｊ番目のキャッシュされたトレースに関連する距離の閾値である。
【００７６】
上述の比較方法は、信号またはトレースを比較するための極めて多数の従来技術のうちの１つに過ぎないことに注意しなければならない。このような方法は、当業者に公知なので、ここには記述しない。しかしながら、２つの信号またはトレースを比較するための任意の従来技術が、ここに記述するメディア識別子に使用するため適用することができること、およびメディア識別子は、上述の簡単な線形走査の使用に限定されることを意味するものではないことは理解されるべきである。さらに、マッチする信号またはトレースの検索を加速するための従来技術は多数存在する。１つの簡単な方法は、単純に以前のマッチの発生頻度の順でキャッシュを検索することである。別の従来の検索を加速させるスキームがあることは明らかであり、それらのいずれもここに記述するメディア識別子に使用するために適用することが可能である。
【００７７】
（３．１．４  データベースの検索）
上述したように、データベースの検索は、入ってくる特定のトレースが、トレースキャッシュ内の全てのトレースとマッチに失敗する場合にのみ実行される。フィンガープリントデータベースの実際の検索は、トレースキャッシュにおける検索とほぼ同じの方法で達成される。事実、トレースキャッシュの検索に関して上述したのと同じ種類のトレース比較が、フィンガープリントデータベース内のフィンガープリントと入ってくるトレースとを比較するために使用される。しかしながら、フィンガープリントデータベースは、トレースキャッシュより実質的に大きいと予想されることに注意されたい。事実、歌曲のフィンガープリントのみを含むメディアオブジェクトデータベースでも、世界中でストリームまたは放送されている音楽の利用可能な範囲を完全に表そうとすると、容易に数百万のエントリを有することが予想される。よって、データベース検索を加速するための方法は、トレースキャッシュ検索の加速より実質的に重要になる傾向がある。
【００７８】
この観点で、人気または発生頻度の順に検索することは、性能の著しい向上を提供する傾向がある。非常に人気のある歌曲は、未知のアーティストによるいくらか古風な歌曲よりも、１つまたは複数のメディアストリーム上でストリームされることが十分に考えられるからである。発生頻度の測定は、容易に達成されるタスクである。具体的な１つの簡単な方法は、特定のメディアオブジェクトが、ある期間を通して、異なるストリームで異なる時に識別される回数を（トレースキャッシュヒットおよびデータベースマッチを計数することにより）単に計数することである。次いで、検索目的用に、フィンガープリントデータベースにおけるエントリを発生頻度の順に順序付ける。さらに、上述したように、マッチする信号またはトレースに関するデータベース検索を加速するための多数の従来技術があり、それらはいずれもここに記述するメディア識別子に使用するため適用することが可能である。
【００７９】
（３．１．５  ローカルデータベースルックアップ）
一実施形態において、サーバの負荷は、フィンガープリントデータベース全体のある微小部分またはサブセット（およびトレースキャッシュの微小部分も同様に可能）を１つまたは複数のローカルクライアントに自動的にアップロードすることにより、さらに軽減される。典型的には、個別のクライアントにてアップロードされるトレースおよび／またはフィンガープリントは、最も頻繁に認められるもの（すなわち、最も人気のあるメディアオブジェクトに対応するトレース／フィンガープリント）であるべきである。
【００８０】
この実施形態においては、計算されるトレース全てを直ちにサーバに送ることよりも、フィンガープリントデータベースおよび／またはトレースキャッシュのサブセット（すなわち「ローカルトレースサブセット」）を有する各クライアントは、計算されるトレースを識別目的のためにサーバに送る前に、ローカルトレースサブセットにまずクエリーする。計算されたトレースが、ローカルトレースサブセット内のいずれかのトレースとマッチする場合は、ローカルトレースサブセットのマッチするトレースに関連する全ての識別情報が、計算されたトレースに割り当てられ、計算されたトレースはサーバに送られない。このようにして、メディア識別負荷の少なくとも幾分かは、サーバから１つまたは複数のローカルクライアントにオフロードされる。
【００８１】
現在人気のある歌曲のようなメディアオブジェクトの数は、メディアオブジェクト全体の母集団に比較して相対的に小さいので、ローカルトレースサブセットにあるトレースは、完全なサーバデータベースにおけるそれよりも、歌曲当たりはるかに多数のフィンガープリントを含み得ることに注意されたい。このことは、サーバに送られるトレースの数をさらに減少するという利点を付加する。マッチを行うと直ちに、現在演奏中のメディアオブジェクトは、そのメディアオブジェクトが演奏している限り、そのメディアオブジェクトに関するフィンガープリントのローカルストアに対して検査することができるからである。例えば、あるフィンガープリントがある歌曲について５秒ごとに計算されている場合、それが５秒ごとに予想マッチを検出する限り、クライアントはサーバに対していかなるトレースも送らなくてよい。
【００８２】
さらに別の実施形態において、クライアントは、肯定的なマッチが確認されるとすぐに、歌曲Ｓのように識別されたメディアオブジェクトの残りの持続時間だけ、トレースをサーバに送付することを単純に停止する。この持続時間情報は、肯定的なマッチが検出されるとき、他の識別情報と共に、サーバからクライアントに送付することができる。これは、サーバ／キャッシュシステムの上の負担をさらに軽減する簡単な方法であるが、ユーザが、例えば、前述の識別された歌曲Ｓが終了する前にメディアストリームを切り換える場合に、（すなわち、識別されるべきメディアオブジェクトであるが、識別されない）誤った否定的な結果となることがある。しかしながら、これは、クライアントがストリームを切換続けるときを単純に追跡し、ストリームの切換が発生するときはいつでも、（サブセットが存在する場合は、ローカルトレースサブセットに対する最初の検査の後に）直ちにトレースをサーバに再度送り始めることによって防止することができる。
【００８３】
（３．１．６  メディアオブジェクトの識別）
上述したように、メディアオブジェクトの識別は、ローカルクライアントが計算したトレースを、サーバが保持するトレースまたはフィンガープリントと比較することにより達成される（上述のように、ローカルトレースサブセットを検索する場合を除く）。上述のように、関連するメディアオブジェクト識別情報を有するトレースまたはフィンガープリントへのマッチを、サーバが識別するときはいつでも、そのメディアオブジェクト情報は、直ちにサーバから、その特定のマッチトレースをサーバに送信した特定のクライアントに送り戻される。
【００８４】
クライアントがメディアオブジェクト識別情報を受領すると、クライアントは、その所望の情報をどのようにも利用することができる。例えば、最も簡単な場合では、ユーザにメディアストリームの中で現在演奏中のメディアオブジェクトを知らせることができるように、クライアントは、そのメディアオブジェクト識別情報をリアルタイムで単に表示することができる。メディアオブジェクト識別情報の他の用途は、個別の各クライアントが監視する任意のストリームにおいて識別されるメディアオブジェクトのローカルの履歴記録を提供するローカルな演奏リストを構築することである。
【００８５】
（３．２  メディア識別子の動作）
図２および図３に関連して上述したプロセスを、図４の一般的な動作の流れ図によって示す。一般に図４は、メディア識別子の幾つかの動作の実施形態を示す例示的な動作の流れ図を示す。図４において、破線または点線で表す箱形および箱形の間の接続線はいずれも、ここに記述するメディア識別子の代替的な実施形態を示すこと、およびこれら代替的な実施形態のいずれかまたは全部は、以下に記述するように、本願明細書に記述される別の代替的な実施形態と組み合わせて使用されることに注意されたい。さらに、以下の説明において、システムは一般的に単一のサーバと共に動作する単一のクライアントに関して記述されていることに注意されたい。しかしながら、先行の説明に鑑みて、ここに記述するメディア識別子は、極めて多くのクライアントおよび所望の任意の数のサーバによって完全に動作することができることは明白であろう。
【００８６】
具体的には、図４に示すように、メディア識別子の動作は、クライアント２００がメディアストリーム２１０をキャプチャすること（ステップ４０５）により開始される。メディアストリームのキャプチャは、例えば、ラジオまたはテレビ放送に単に同調すること、またはインターネットなどのネットワークを介してストリーミングメディアまたは同時放送に参加することを含む従来の方法を使用して達成される。メディアストリーム２１０をキャプチャする（ステップ４０５）のに伴い、クライアントはそのメディアストリームのサンプルからリアルタイムトレースを生成する（ステップ４１０）。これらのリアルタイムトレースは、従来のネットワークの送信プロトコルを使用してサーバ２３０に送信される（ステップ４１５）。メディアトレースの計算および送信は、メディアストリームを受信している限り、またクライアントがメディアストリームに埋め込まれたメディアオブジェクトに関する識別情報を望む限り継続する。
【００８７】
しかしながら、上述したように、一実施形態において、クライアントは、サーバからのメディアオブジェクトの識別情報の受信に続いて、トレースの計算およびサーバへの送信を一時的に中止する。例えば、上述したように、フィンガープリントデータベースのために計算されたフィンガープリントは、既知のメディアオブジェクト内の既知の位置から計算される。よってこれらメディアオブジェクトの残りの長さまたは持続時間は、計算されたトレースとの関連で知ることができる（サーバにトレースを送ることおよびサーバから返されたメディアオブジェクトの識別を受信することによる遅延時間を引く）。したがって、この実施形態によって、持続時間情報がメディアオブジェクト識別情報と共に与えられる限り、クライアントは、現在演奏中のメディアオブジェクトの終点の後まで、いかなる追加のトレースを計算する必要も、サーバに送る必要もない。しかしながら、クライアントが異なるメディアストリームのキャプチャを開始する場合（例えば、ラジオ放送局を切換るなど）は、トレースの計算および送信を直ちに再開する。この実施形態は、クライアントに戻されるメディアオブジェクトの順調な識別に続いてサーバに送られるトレースの数を大幅に減少することによって、サーバの負荷を実質的に軽減することができることは明白である。
【００８８】
サーバ２３０が、クライアント２００から送信されたトレースを受信する（ステップ４２０）と、サーバは直ちに、トレースキャッシュ２４０を検査して（ステップ４２５）、キャッシュ内にマッチするトレースがあるか否かを判定する（ステップ４３０）。トレースキャッシュ内にマッチするトレースがある場合は、キャッシュ内のマッチトレースを検査して、それが肯定的なデータベースのヒットに関連するか否かを判定する（ステップ４３５）。マッチトレースが肯定的なデータベースのヒットに関連している場合は、そのマッチトレースに関連するメディア識別情報を直ちにクライアント２００に送信する（ステップ４６０）。
【００８９】
逆に、トレースキャッシュ２４０がマッチするトレースを含まない場合、マッチするフィンガープリントを捜し出すことを試みて、フィンガープリントデータベース２５０を検査する（ステップ４４０）。データベースのマッチがある場合（ステップ４４５）は、そのトレースをトレースキャッシュ２４０に格納し（ステップ４５０）、そのマッチするトレースに関連するメディア識別情報を、直ちにクライアント２００に送信する（ステップ４６０）。そのトレースにデータベースのマッチがない場合（ステップ４４５）は、そのトレースをトレースキャッシュ２４０に否定的なヒットとしてやはり格納する（ステップ４５０）。
【００９０】
どちらの場合も、一旦トレースキャッシュ２４０の中にマッチが検出されるか（ステップ４３０）、もしくは見出されないか、またはデータベース内にマッチが検出されるか（ステップ４４５）、もしくは見出されないかであり、関連する全てのメディアオブジェクト識別情報がクライアントに送信される（ステップ４６０）と、サーバは、トレースキャッシュ２４０および／またはフィンガープリントデータベース２５０それぞれの内のトレースおよび／またはフィンガープリントとの比較のために次のトレースがクライアントから送られるのを単に待つだけである。さらに、上述したように、トレースキャッシュ２４０は、継続して管理され（ステップ４５５）、寿命が満了したトレースのエントリを削除する。
【００９１】
クライアント２００がいずれかのメディアオブジェクト識別情報を受信すると、その情報はクライアントによって処理され（ステップ４６５）、所望に応じてユーザに提供される。例えば、一実施形態において、メディアオブジェクト識別情報は、そのメディアストリームが受信されて再生されるのに伴いユーザへの現在のメディアオブジェクト識別の表示を提供するために使用される。代わりに、そのメディアオブジェクト識別情報は、これに限定されないが、演奏リストの生成、メディアストリームの特徴づけ、メディアストリームの統計的な解析などを含む他の目的のために使用することができる。
【００９２】
最後に、別の実施形態において、フィンガープリントデータベース２５０（および／またはトレースキャッシュ２４０）のサブセットが、クライアント２００によってサーバ２３０からダウンロードされて（ステップ４７０）、ローカルフィンガープリントデータベースとして作用する。上述したように、このサブセットには、サーバ自体はルックアップに使用ない追加のフィンガープリントを含めることができ、これは、上述のように対象範囲を増加するため（例えば、クライアントが歌曲当たり数個のフィンガープリントを検査する）である。具体的には、比較的人気のある（または、より頻繁に認められる）メディアオブジェクトの追加のフィンガープリントをメディアオブジェクトごとにサーバが計算し、およびその追加のフィンガープリントをクライアントにダウンロードされるフィンガープリントのサブセットに含めることにより、サーバの呼出をさらに減少させる。上に記述するように、このローカルデータベースは、いずれかのトレースをサーバ２３０に送信する（ステップ４１５）前に、クライアントが検索する（ステップ４７５）。このローカルデータベースの検索においてトレースのマッチが見付かる場合に、対応するトレースは、上述のように、処理のためにサーバ２３０に送られることはない。
【００９３】
メディア識別子に関する前記の記述は、図示および記述の目的のために提示した。本発明を開示の正確な形で網羅または限定するためではない。上の教示に照らして、多くの変更および変態が可能である。さらに、前述の代替実施形態のいずれかまたは全ては、メディア識別子の追加の複合型の実施態様を形成するために望まれる任意の組合せで使用されることに注意されたい。本発明の範囲は、この詳細な記述によってではなく、ここに添付した請求項によって限定されることが目的である。
【図面の簡単な説明】
【００９４】
【図１】ここに記述する「メディア識別子」を実装する例示システムを構成する汎用コンピューティング装置を示す一般的なシステムダイアグラムを示す図である。
【図２】ここに記述する「メディア識別子」を実装するための機能コンポーネント間の一般的な関係を示すアーキテクチャシステムダイアグラム例を示す図である。
【図３】ここに記述する「メディア識別子」を実装するためのプログラムモジュールを示すアーキテクチャ例の流れ図である。
【図４】ここに記述する「メディア識別子」の一実施形態の一般的な動作を示す動作の流れ図である。
【符号の説明】
【００９５】
１４１  ハードディスクドライブ
１５１  磁気ディスクドライブ
１５５  光ディスクドライブ
【図１】
2006146883.tif 000004
【図２】
2006146883.tif 000005
【図３】
2006146883.tif 000006
【図４】
2006146883.tif 000007