JP2014519253A - 放送番組コンテンツを認識するシステム及び方法 - Google Patents

Abstract

放送源から放送番組コンテンツをサンプリングする少なくとも１つの受信機と、サンプリングされた放送番組コンテンツを認識し且つ格納するコンテンツ認識エンジンと、クライアント装置からクエリを受け取ると放送番組コンテンツに関連する情報を返す、コンテンツ認識手段とデータ通信するコンテンツデータベースとを備える、放送番組コンテンツ認識システムを開示する。このシステムは、コンテンツ認識エンジンが、サンプルの放送番組コンテンツを認識できない場合、コンテンツ認識エンジンが、認識されないサンプルを少なくとも第１及び第２の連続した部分に分割し、第１の部分をすでに認識したサンプルに追加するように構成される。
【選択図】 図１

Description

発明の分野

本発明は、放送番組コンテンツを認識するシステム及び方法に関する。このシステム及び方法は、限定ではないが特に通信デバイスのユーザが同調する、音楽のような放送番組コンテンツを認識するのに適しており、これに関連してこのシステム及び方法を説明する。

発明の背景についての次の説明は、単に本発明の理解を容易にすることを意図している。当然のことながらこの説明は、言及する題材のいずれも、本出願の優先日の時点でいかなる管轄においても、公開されていた、知られていた、又は当業者の一般的常識の一部であったと確認するか又は認めるものではない。

現在の音楽認識システム及び方法は、典型的には、音楽認識エンジンの使用を含んでいる。このような音楽認識エンジンは、典型的には音楽認識アルゴリズムのある形式を用いる。周知の音楽認識アルゴリズムが、典型的には音声サンプルを取得し、この音声サンプルをそのデータベース中のエントリと比較し、識別された音声サンプルで入手可能なある情報を返す。

現在の音楽認識システムは、主としてスタンドアローン機能に、又は複数のユーザによってアクセスできるオンラインサービスにとどまっていた。複数のユーザからの同時要求を処理するその機能を強化するために、概略的にはオンライン音楽認識システムが、負荷バランシングを備えたサーバファームとして実装され、すなわち、音楽認識システムは、同時要求が殺到するとき、負荷を共有するサーバファームに、自らの多くのインスタンスを複製することになる。しかしながらこのような実装は、接続的に高帯域ネットワークを想定する。オンライン認識エンジンは、相当量のインターネット帯域幅に恵まれているので、大量の要求があるにもかかわらず、依然として優れた応答時間を提供する。

しかしながら、現在の音楽認識システムがモバイルサービスに関連して実装されるとき、サーバファームのモデルは同様にうまく機能しない可能性がある。これは、通常、ＧＳＭ（登録商標）のネットワークであるモバイルネットワークの限られた帯域幅によるものである。何百万人ものユーザをサポートするモバイルサービスでは、サーバの負荷は重くなりすぎて認識エンジンが処理できなくなり、結果として許容しがたいユーザエクスペリエンス及び／又は実際のサービスの障害が生じる。このような障害及びボトルネックは、ネットワークの非データ利用にも悪影響を及ぼすことになる。サービス品質の劣化は、加入者離反（ｓｕｂｓｃｒｉｂｅｒ ｃｈｕｒｎ）を非常に高める原因となり、これは、市場の飽和に近い状態及び激しい競争のこの時代において、移動体通信事業者の消滅につながる恐れがある。

上記に加えて、モバイルサービスに関連する現在の先行技術のシステムは、ユーザが音声クリップとしてこの歌の断片（ｓｎｉｐｐｅｔ）を取り込んで、同じものを歌認識エンジンに送信する必要がある。音声クリップは、いかに短くとも、また圧縮技術にかかわらず、かなりのサイズである。

本発明は、上述の欠点を軽減するコンテンツ認識システム及び方法を提供しようとするものである。

本発明は、音楽認識要求に伴うオーバヘッドを軽減し、したがって比較的低帯域幅のＧＳＭ（登録商標）のネットワークにおける障害及びボトルネックを回避するという課題に対処するために開発された。

本発明の第１の態様によれば、
放送源から放送番組コンテンツをサンプリングする少なくとも１つの受信機と、
サンプリングされた放送番組コンテンツを認識して格納するコンテンツ認識エンジンと、
クライアント装置からクエリを受け取ると放送番組コンテンツに関連する情報を返す、コンテンツ認識手段とデータ通信するコンテンツデータベースと、
を含む、放送番組コンテンツ認識システムが提供される。

クライアント装置は、放送番組コンテンツを受信するモバイルデバイスであることが好ましい。

クエリはＳＭＳクエリ又はＨＴＴＰ ｐｏｓｔクエリであることが好都合である。クエリは、放送番組コンテンツのタイムスタンプ及び放送源に関連する識別情報を含む。

クライアント装置は、定期的な時間間隔で、ステーションＩＤ及びタイムスタンプに関する受動的情報をコンテンツデータベースに自動的に送信するように構成されることが好ましい。このような構成では、コンテンツデータベースは、受信した受動的情報を処理して、クライアント装置への放送番組コンテンツをカスタマイズするアプリケーションコンテンツマネージャとさらにデータ通信する。

受動的情報は、ＳＭＳ、ＭＭＳ、ＩＰ、独自のメッセージング、又は、Ｗｉ−ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、若しくはＮｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ（近距離無線通信、ＮＦＣ）のような他の利用できる無線接続によって、送信可能であることが好ましい。

システムはさらに、コンテンツデータベースとデータ通信するプロファイリングデータベースを含み、コンテンツデータベース及びプロファイルデータベースからの情報が、あるユーザ指定の結論に到達するように構成され、集約され、統合されることが好ましい。

本発明の第２の態様によれば、放送番組コンテンツをサンプリングする少なくとも１つの受信機と、サンプリングされた放送番組コンテンツを認識して格納するコンテンツ認識エンジンとを含み、コンテンツ認識エンジンが、サンプルの放送番組コンテンツを認識できない場合、コンテンツ認識手段が、認識されないサンプルを少なくとも第１及び第２の連続した部分に分割し、第１の部分又は第２の部分をすでに認識されたサンプルに追加する、放送番組コンテンツ認識システムを提供する。

システムは、終了条件に到達するか、追加された第１又は第２の部分が認識可能になるまで、認識されないサンプルを繰り返して分割し、追加するように構成されることが好ましい。

システムは、認識されないサンプルに失敗サンプルとして印を付けるように構成されることが好ましい。

本発明の第３の態様によれば、
ａ．放送番組コンテンツのサンプルを受信するステップと、
ｂ．受信したサンプルが認識可能であるかどうかを判断するステップと、
ｃ．受信したサンプルが認識可能ではないと判断される場合、受信したサンプルを第１及び第２の連続した部分に分割するステップと、
ｄ．第１の部分をすでに認識可能なサンプルに追加するステップと、
を含む、放送された番組コンテンツを認識する方法を提供する。

この方法は、追加されたサンプルが認識可能になるまで、ステップ（ｂ）から（ｄ）を繰り返すステップを含むことが好ましい。

次に本発明について、単に例として添付の図面を参照して説明する。
本発明の第１の実施形態に従ったコンテンツ認識システムの略図である。 本発明の第２の実施形態に従ったコンテンツ認識システムの略図である。 本発明の諸実施形態によるサンプリングアルゴリズムを示す流れ図である。 結果として失敗としてコンテンツ認識システムによって認識される、コンテンツ継続時間に入らないサンプルを示す図である。 様々なシナリオにおける認識できないサンプルの分割を示す図である。

発明の実施形態の説明

本発明の第１の態様によれば、放送番組コンテンツ認識システム１０がある。コンテンツ認識システム１０は、１つ又は複数の放送源１２から放送された番組コンテンツを受信する複数の放送受信機１４と、コンテンツ認識エンジン１６と、コンテンツデータベース１８とを含む。放送源１２は、典型的には放送局である。説明のために、放送源１２は、周波数変調（ＦＭ）周波数放送局である。各放送局１２は、異なるＦＭ周波数帯域で番組コンテンツを放送する。この実施形態の説明のために、各放送源からの放送コンテンツは音楽であるが、放送コンテンツは、音声広告などの他の音声コンテンツとすることもできることは容易に理解される。

各受信機１４は、その対応する放送源１２と通信する。各受信機１４は、放送源の同じエリアに配置することがある、又は地理的に分散することもあると理解されたい。各受信機１４は、放送された音楽をその対応する放送源１２から連続してサンプリングするように構成される。各受信機１４は、サンプリング時間ｔに放送番組コンテンツをサンプリングするように構成される。

音楽認識エンジン１６は、当業者に知られている第三者のソフトウェアアプリケーション（例えば、ＳｏｕｎｄＨｏｕｎｄ（商標））とすることもできるプログラムを含む。音楽認識エンジン１６は、各受信機１４から音楽サンプルを受信し、処理するように構成される。音楽認識エンジン１６によって行われる処理は、定められた認識時間内のサンプルをパースし（ｐａｒｓｉｎｇ）、識別することを含む。

コンテンツデータベース１８には、コンテンツ認識エンジン１６が常に設けられる。認識エンジン１６からコンテンツデータベース１８に送信されるデータは、いかなる所望のフォーマットとすることもできる。例えば、コンテンツデータベース１８は、認識エンジン１６からコードを復号し、同じものを、単純なデータベースのルックアップクエリ、例えば限定ではないがＳＱＬクエリによって、歌のタイトル、ジャンル、アーティストなどのような関連情報に変換するデコーダの独自のセットを有することもできる。コンテンツデータベース１８は、少なくとも１つのクライアント装置２０からクエリを受け取るように構成され、各クエリは、タイムスタンプ及びクライアント装置２０を同調する放送局１２に対応する局ＩＤを含んでいる。コンテンツデータベース１８は、受け取った時間に従って認識エンジン１６から受け取った情報をまとめ、したがって、コンテンツ認識エンジン１６から受け取ったコンテンツの履歴記録を提供することができる。ユーザが取得することもできる履歴記録は、データベース１８のサイズ及び容量によって決まる。

クライアント装置２０は、典型的にはモバイルデバイスである。この実施形態では、モバイルデバイス２０は、ＦＭチューナを備え、したがってモバイルデバイス２０のユーザは、選択した放送局１２に周波数を合わせることができる。モバイルデバイス２０は、コンテンツデータベース１８とデータ通信するように構成され、ＨＴＰＰ ＰＯＳＴリクエスト、メソッド呼び出し、キーワードに基づくＳＭＳクエリなどのようなデータクエリ機構を使用して、コンテンツデータベース１８に問い合わせることもできる。

次にシステム１０について、その動作と関連して説明する。

例示のように、モバイルデバイス２０のユーザは、モバイルデバイス２０に組み込まれているＦＭチューナを調整することによって複数の放送局１２のうちの特定の放送局１２に同調する。ユーザは、ユーザが同調した、放送された曲のタイトルを知ることを希望し、したがってユーザは、モバイルデバイスのインタフェースにアクセスして、前述のプロトコルに基づいて（ＨＴＴＰ ＰＯＳＴ、ＳＭＳクエリなどにより）プレイリストデータベース１８にクエリを送信する。

コンテンツデータベース１８は、以下の２つのパラメータに基づいて単純なルックアップを実行する：
ａ．クエリのタイムスタンプ
ｂ．局ＩＤ

コンテンツデータベース１８は、クエリのタイムスタンプをチェックして、タイムスタンプが既知の一定のサンプリング間隔ｔ_ｋ内に入るかどうかを判断する。ここで、サンプリング間隔ｔ_ｋは、放送番組コンテンツが放送されることになっている時間である。タイムスタンプが、既知のサンプリング間隔ｔ_ｋ内に入らない場合、コンテンツデータベース１８は、クライアント装置２０に検出失敗エラーを返し、必要に応じてクライアント装置２０のユーザに再試行を促す。

典型的には、サンプリング間隔ｔの値は、音楽サンプルの識別に成功するために必要とされる最小サンプル時間を考慮して音楽認識アルゴリズムによって決定される。時間間隔がより短いと、事実上、認識エンジン１４が音声サンプルを識別することを阻むことになる。

しかしながら、サンプリングが２つの異なる音楽サンプルにわたり、認識エンジンがサンプルを識別することを阻むことのないように、サンプリング間隔ｔをできるだけ短く保つことが望ましい。したがって、重複サンプルのサンプリングを防止するために、サンプリング間隔ｔは、理想的には放送コンテンツの再生の長さよりも短く、長くとも同じに保たれなければならないということになる。しかしながら、事実上、各放送コンテンツは、同じ再生の長さを有することはなく、したがってサンプリング間隔ｔは小さく、最大でも、最も短い放送コンテンツの再生の長さと等しく保たれるべきである。たとえそうであっても、各放送される番組コンテンツの再生の長さは変わるので、重複の可能性はある。この実施形態における手法は、コンテンツ認識エンジン１６によって必要とされるサンプリング間隔ｔを最小サンプリング間隔に一致させ、いかなる重複サンプルも解消することである。（重複の状態／シナリオとして知られる）サンプルの重複が発生する場合、コンテンツ認識エンジン１６内のサンプルアルゴリズムが、重複状態（以下に説明する）を解消するために必要な動作を実行する。

リクエストが（１人又は複数の）ユーザによって行われるかどうかにかかわらず、各受信機１４は、その放送局１２によって放送される音楽を連続してサンプリングする。サンプリングは、図３に示し以下のように説明するサンプリングアルゴリズムに基づいて行われる：

この処理は、放送源１２から放送されたコンテンツのサンプルを取ることから始める（ステップ３２）。サンプリングは連続的であるが、１つのサンプルは、有限周期で取られ、サンプルを取るステップとして理解される。

アルゴリズムは、サンプルが準備できているかどうかをチェックする（ステップ３４）。チェックするステップは、サンプルが利用できるかどうかを確認することを含む。デフォルトにより、サンプルは生サンプルである。チェックするステップは、代替的にはトランスコードされたサンプルで実行することもできる（すなわち、生サンプルを１６進数の、プレーンテキスト、又は任意の一意のコードに変換する、オプションのトランスコードするステップを含む）。このような場合、チェックするステップは、トランスコードされたサンプルの有効性を確認する。サンプルが準備できると、認識エンジン１６へ送られる（ステップ３６）。認識エンジン１６は、知られている技術に基づいてコンテンツの認識を実行し、認識が成功であるかどうかをチェックする（ステップ３８）。コンテンツ認識が成功であると判断される場合、情報はコンテンツデータベース１８に格納される（ステップ４０）。サンプルはまた、サーキュラーキューバッファ（ｃｉｒｃｕｌａｒ ｑｕｅｕｅ ｂｕｆｆｅｒ）に保持される。サーキュラーキューバッファは、先入れ先出しキューシステムとすることもでき、バッファに格納されたコンテンツがもはや必要ではない場合、このコンテンツを廃棄する手段である。コンテンツ認識が成功ではない場合、失敗マークが作成される（ステップ４２）。失敗した認識とは、サンプルが重複状態のカテゴリに入り、したがって、分割を必要とする（ステップ４４）ことを意味し、このステップについては図５に示している。分割されたサンプル及び第１の部分は、格納バッファキューに保有されている以前のサンプルに追加される（ステップ４６）。連結されたサンプルは、次にコンテンツ認識エンジンへ送られる（ステップ３６参照）。この処理は、サンプルが認識され、格納されるまで繰り返す（ステップ４０）。認識が失敗する場合、先に分割されたサンプルの第１の部分の半分が分割され、その後バッファキュー内の以前のサンプルに追加される。

ステップ４４について以下にさらに説明し、図５に示す。

図５は、特定の放送局１２で再生されている番組コンテンツＡ及びＢ、並びに番組コンテンツＡ及びＢが連続して再生される間に取られるサンプル１、２、３、及び４を示す。サンプル１、２、及び４が決定的であること、すなわちコンテンツＡはサンプル１及び２を使用して確認することができ、コンテンツＢはサンプル４を使用して確認することができることが容易に理解される。しかしながらサンプル３は、サンプル３の一部がコンテンツＡの放送中に取られ、サンプル３の別の部分はコンテンツＢの放送中に取られるので、重複問題を生み出す。

結果として、サンプル３の認識は、音楽認識アルゴリズムがサンプル３をコンテンツＡと関連付けるべきか、コンテンツＢと関連付けるべきかを判断できないとき、ステップ３８に基づいて失敗となる。失敗サンプル３を検出すると、サンプリングアルゴリズムは、引き続いて失敗サンプルに印を付け（ステップ４２）、サンプル３をサンプルＳ３Ｌ（第１の部分）とサンプルＳ３Ｒとに分割する。サンプルＳ３Ｌをサンプル２に追加すると、コンテンツ認識エンジンは、サンプル２＋Ｓ３Ｌの有効な認識を行うことができる。しかしながら、サンプルＳ３Ｒがステップ３８に基づいてさらに失敗し、したがって重複問題として残る。失敗サンプルＳ３Ｒはその後、サンプルＲＬとサンプルＲＲの別の分割をトリガする。ＲＲをサンプル４に追加すると、結果としてコンテンツＢの有効な識別になることに注意する。しかしながらＲＬをサンプル２又はサンプル４に追加することは、ともに結果として識別プロセスの失敗となる。例示及び説明は、「左に追加（ｌｅｆｔ ａｐｐｅｎｄ）」のシナリオを述べたが、「右に追加（ｒｉｇｈｔ ａｐｐｅｎｄ）」（すなわち、例えばサンプルＳ３Ｒをサンプル３に追加する）もこのシステムによって等しく対応されることがわかる。

図５に示すように、重複サンプル、サンプル３が分割されるにつれて、確定の間隔（ｉｎｔｅｒｖａｌ ｏｆ ｃｅｒｔａｉｎｔｙ）は増大する。分割するステップ４４がなければ、確定の間隔、すなわち、第１の確定の間隔（Ｆｉｒｓｔ Ｉｎｔｅｒｖａｌ ｏｆ Ｃｅｒｔａｉｎｔｙ）として知られる、コンテンツ認識エンジン１６が放送される番組コンテンツを明確に識別することができる期間は、サンプル３が重複状態にあるのでより短くなる。第１の確定の間隔後の、サンプル３内に入る時間のユーザクエリは、したがってエラーを返す。

しかしながら、分割するプロセス／ステップ４４を適用すると、確定の間隔が増大する。第１の部分のサンプルＳ３Ｌは、第１の確定の間隔に追加され、結果としてより長い第２の確定の間隔となる。したがって、第２の確定の間隔に入る同じユーザクエリは、結果として番組コンテンツＡの確実な識別になる。図示するようにクエリの同じポイントについては、第２の確定の間隔の下で、結果はよりよいものとなる。

認識が成功すると、サンプル及びその情報は格納され、認識エンジン１６は既知の間隔ｔ_ｋを更新して、サンプリング時間ｔと追加部分にかかる時間を含める。各格納されたサンプルについて、システムは、ステップ４２下の失敗マークが作成されたかどうかをチェックする（ステップ４８）。失敗マークが検出される場合、最近処理されたサンプルが（通常の長さのサンプルと対照的に）分割され、連結／追加されたサンプルであることを意味し、したがって、次の通常の長さのサンプルに移るべき時となる（ステップ３２）。失敗マークがないとき、システムは、処理するさらなる分割があるかどうかをチェックする（ステップ５０）。処理する他のサンプルがない場合、サンプリングアルゴリズムは、次のサンプルへ進む（ステップ３２）。

説明するように分割（ステップ４４）及び追加の処理は繰り返しであるが、終了条件を有する。このような条件は、例えば繰り返しの数をある数ｎに決定すること、又は１／２ｔが最小サンプリング時間ｔ_ｍｉｎの持続となるまで、などビジネスルールによって規定することもできる。ｔ_ｍｉｎは、有益なサンプルを有するのに必要とされる最小サンプリング時間であり、ｔ_ｍｉｎ未満にサンプリングされたサンプルは認識できないものとなる。ｎは、最初に２に設定することができる。

同じ参照符号が同じ部分を示す本発明の第２の実施形態に従った、コンテンツ認識システム１０がある。

コンテンツ認識システム１０は、放送源１２から放送番組コンテンツを受信するようにそれぞれ構成された複数の放送受信機１４と、コンテンツ認識エンジン１６と、コンテンツデータベース１８とを含む。放送源１２は、典型的には放送局である。説明のために、放送源１２は、ＦＭ周波数放送局である。各放送局は、異なるＦＭ周波数帯域で番組コンテンツを放送する。この実施形態の説明の目的で、各放送源からの放送コンテンツは音楽であるが、広告などを含む、他の音声コンテンツとすることもできることは容易に理解される。

第１の実施形態に加えて、移動体通信事業者若しくはアプリケーションコンテンツマネージャ９００及びプロファイリングデータベース９５０がある。

第１の実施形態に記載する通常クエリの代わりに、クライアント装置２０は、局ＩＤ及びタイムスタンプに関する受動的情報を、ユーザが情報を能動的に要求することなく定期的に、コンテンツデータベース１８に送信する。これは、例えばクライアント装置の設定によって行うこともできるが、さらに詳細には説明しない。このように送信される受動的情報は、クライアント装置２０のユーザが別の局１２に切り換えた場合、（局ＩＤの切り換えに基づいて）反映することができる。受動的情報は、クライアント装置２０が使用しているＳＭＳ、ＭＭＳ、ＩＰ、独自のメッセージング機構などにより、ＧＳＭ（登録商標）のネットワークを通じて、又は、クライアント装置２０に装備されている場合、Ｗｉ−ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、近距離無線通信（ＮＦＣ）などのような他の利用可能な無線接続を通じて、送信することができる。

コンテンツデータベース１８は、プロファイリングデータベース９５０とデータ通信する。コンテンツデータベース１８及びプロファイルデータベース９５０からの情報をさらに適用し、集約し、統合して（データマイニングして）、あるユーザ指定の結論に到達することもできる。例えば、どの特定のコンテンツによりクライアント装置２０のユーザはチャンネルを切り換えるか、及び何によりユーザはチャンネルをそのままにするかを示すこと、ユーザの好みを聞くことなどであるが、聴いた歌、特定のチャンネルにとどまる長さ、ユーザがチャンネルを変えた時に放送されていたコンテンツなどのような他の情報を追跡することもできる。プロファイリングデータベース９５０は、この情報を移動体通信事業者又はアプリケーションコンテンツマネージャ９００に送る。コンテンツマネージャ９００はその後、例えば、加入者が好む同じジャンルのオプションメディアコンテンツの販売を利用できる、又はそのようなジャンルに識別されるアーティストの近く行われるコンサートなどのような、示唆的マーケティング及びターゲット広告によって、モバイルデバイス２０用のコンテンツをカスタマイズすることができる。

データベース１８及びプロファイルデータベース９５０からの情報を、様々な方法でさらに利用することもできる。ユーザ行動に関する情報は、どの特定の放送番組コンテンツによってクライアント装置２０のユーザが別のチャンネルに移るか、何によってユーザはそのチャンネルにとどまるかを示すように、集約し、統合することができる。所与の時間に放送局１２にチャンネルを合わせているリスナーの数に関する情報が利用可能であり、特定の番組コンテンツを放送する最良の時間／期間に関して、アプリケーションコンテンツマネージャ９００にとって利用可能な情報を作成する。情報はその後、コンテンツプロバイダ及び放送局１２が使用して、リスナーをさらに魅了する関連番組を決定することができる。さらに、この実施形態は、放送局１２を評価することに関連することもある。伝統的には、情報収集及び評価は、手動の無作為調査から家庭及び個人に無作為に配置された装置を使用した自動データ収集まで様々である手段を使用して行われることが理解される。この実施形態を用いて、内蔵チューナを備えたすべてのモバイルデバイス２０は、何人のクライアント装置２０（したがってエンドユーザ）が任意の時間に特定の放送チャンネル１２を聴いているかをリアルタイムに判断することを可能にする統合報告システムを付けることもできる。現在の実施形態により、広告主は、ターゲット視聴者によって決まるどの放送チャンネル１２を使用すべきかに関してよりよくアドバイスされるようになる。

上述の統合報告システムは、バックグラウンドで実行され、クライアント装置２０によって送信される受動的情報と同様である。受動的情報は、クライアント装置２０のユーザが特定のチャンネルに合わせるとき単純な通知とすることができ、このような通知は、データベースで照合され、そこからのレポートは、無料でアクセス可能、購読料を払う、ペイパービュー、又はその後決定することができる他のビジネスモデルの別のサービスとすることもできる。

この実施形態は、定義された領域で最も再生される音楽をランク付けするためにさらに使用することもできる。いかなるエンドユーザの参加も必要なしに、組み合わされた要素１４、１６、及び１８を使用して、任意の所与の期間で人気のある音楽、歌、又はアルバムをモニタし、ランク付けすることもできる。リスナーの密度は、位置及びモバイルデバイス２０の数に基づいて同様に判断することもできる。さらに、位置情報は、移動体通信事業者９００によりプロファイリングデータベース９５０を介して提供することもできる。情報を用いて、地理的プロファイリングを作成して、より関連のあるコンテンツ及び番組を配信することができる。

本発明のさらなる実施形態では、受信機１４及び音楽認識エンジン１６は、ハイブリッド放送局に置き換えることもできる。

コンテンツ認識システム１０の関連する利点は、履歴データを追跡する能力である。この点において、ユーザが「最近再生したあの歌は何か」を問い合わせるとき、コンテンツデータベース１８は情報を検索し、歌情報を提供する。

さらに、記載した実施形態は、ユーザデバイスの比較的古い世代と下位互換性がある。このような場合、ユーザは、単純なテキストリクエスト（局ＩＤを含む）をさらに送信することもでき、システム１０は、例えばラジオ局から再生中の歌のタイトルに関するテキストメッセージで返信する。
変形形態
・プロファイルデータベース９５０並びに結合された要素１４、１６、及び１８から生じる位置に基づくサービスは、同じユーザからの以前のトランザクション若しくはイベントの記録、又は利用可能な記録から調べることができる任意のパターンなど、同等の任意の関連機能に置き換えることができる。
・受信機１４による連続的なサンプリングを毎日２４時間行うこともできる。

上述の実施形態は、以下に詳細に記載するような本発明を単に例示する目的で提供されていること、並びに当業者には明らかであるさらなる変形形態及び改良形態が、記載する本発明の範囲及び領域に入ると考えられることを理解されたい。さらに、本発明の個々の実施形態について述べることもできたが、本発明は、前述の実施形態の組合せもまた含むものとする。

Claims (13)

1. 放送番組コンテンツ認識システムであって、
   放送源から放送番組コンテンツをサンプリングする少なくとも１つの受信機と、
   前記サンプリングされた放送番組コンテンツを認識して格納するコンテンツ認識エンジンと、
   前記コンテンツ認識手段とデータ通信するコンテンツデータベースであって、クライアント装置からクエリを受け取ると前記放送番組コンテンツに関連する情報を返すコンテンツデータベースと、
   を備える、システム。
2. 前記クライアント装置が、前記放送番組コンテンツを受信するモバイルデバイスである、請求項１に記載のシステム。
3. 前記クエリが、ＳＭＳクエリ又はＨＴＴＰ ｐｏｓｔクエリである、請求項１に記載のシステム。
4. 前記クエリが、前記放送番組コンテンツのタイムスタンプ及び前記放送源に関連する識別子を含む、請求項１に記載のシステム。
5. 前記クライアント装置が、定期的な時間間隔で、前記局ＩＤ及び前記タイムスタンプに関する受動的情報を前記コンテンツデータベースに自動的に送信するように構成される、請求項４に記載のシステム。
6. 前記コンテンツデータベースが、前記受信した受動的情報を処理して前記クライアント装置への放送番組コンテンツをカスタマイズするアプリケーションコンテンツマネージャとさらにデータ通信する、請求項５に記載のシステム。
7. 受動的情報を、ＳＭＳ、ＭＭＳ、ＩＰ、独自のメッセージング、又は、Ｗｉ−ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、若しくはＮｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ（ＮＦＣ）のような他の利用できる無線接続によって送信することができる、請求項５に記載のシステム。
8. 当該システムが、前記コンテンツデータベースとデータ通信するプロファイリングデータベースをさらに備え、前記コンテンツデータベース及びプロファイルデータベースからの情報が、あるユーザ指定の結論に到達するように構成され、集約され、統合される、請求項１に記載のシステム。
9. 放送番組コンテンツをサンプリングする少なくとも１つの受信機と、前記サンプリングされた放送番組コンテンツを認識し且つ格納するコンテンツ認識エンジンとを備える放送番組コンテンツ認識システムであって、
   前記コンテンツ認識エンジンが、前記サンプリングされた放送番組コンテンツを認識できない場合、前記コンテンツ認識エンジンが、前記認識されないサンプルを少なくとも第１及び第２の連続した部分に分割し、前記第１の部分又は前記第２の部分をすでに認識したサンプルに追加する、システム。
10. 当該システムが、前記認識されないサンプルを失敗サンプルとして印を付ける、請求項９に記載のシステム。
11. 当該システムが、終了条件に到達するか、前記追加された第１又は第２の部分が認識可能になるまで、前記認識されないサンプルを繰り返して分割し、追加する、請求項９に記載のシステム。
12. 放送された番組コンテンツを認識する方法であって、
    ａ．放送番組コンテンツのサンプルを受信するステップと、
    ｂ．前記受信したサンプルが認識可能であるかどうかを判断するステップと、
    ｃ．前記受信したサンプルが認識可能ではないと判断される場合、前記受信したサンプルを第１及び第２の連続した部分に分割するステップと、
    ｄ．前記第１の部分又は第２の部分をすでに認識可能であるサンプルに追加するステップと、
    を含む、方法。
13. 前記追加されたサンプルが認識可能になるまで、ステップ（ｂ）から（ｄ）を繰り返すステップを含む、請求項１２に記載の方法。

Images