JP2009516252A - テキストの表現を取得する方法 - Google Patents

Abstract

例えば曲の歌詞のようなテキストの表現を含むデータファイル２０、２２を取得する方法であって、少なくとも１つのサーバ１−３のコンテンツの検索が実行されることを許容するように構成されたサーバシステム５に対して発行された検索クエリに基づいて、文字列を含む複数の候補ファイル１３、２５を取得するステップと、前記複数の候補ファイルのサブセット１９、３５を形成するステップと、サブセット１９、３５のみにおける少なくとも１つの前記候補ファイルから、前記テキストの表現を形成するステップと、を有する方法。本方法は更に、前記候補ファイルにおける前記文字列のうち少なくとも幾つかに基づくデータを比較するステップと、前記文字列のうち少なくとも幾つかに基づくデータが類似度の基準を満足する候補ファイルから、サブセット１９、３５を形成するステップと、を含む。

Description

本発明は、例えば曲の歌詞のようなテキストの表現を含むデータファイルを取得する方法であって、
少なくとも１つのサーバのコンテンツの検索が実行されることを許容するように構成されたサーバシステムに対して発行された検索クエリに基づいて、文字列を含む複数の候補ファイルを取得するステップと、
前記複数の候補ファイルのサブセットを形成するステップと、
前記サブセットのみにおける少なくとも１つの前記候補ファイルから、前記テキストの表現を形成するステップと、
を有する方法に関する。

本発明はまた、例えば曲の歌詞のようなテキストの表現を含むデータファイルを取得するシステムであって、
少なくとも１つのサーバのコンテンツの検索が実行されることを許容するように構成されたサーバシステムに対して検索クエリを発行し、前記検索クエリに応じて文字列を含む複数の候補ファイルを取得するクライアントを含み、
前記複数の候補ファイルのサブセットを形成し、前記サブセットのみにおける前記候補ファイルのうち少なくとも１つから前記テキストの表現を形成するように構成されたシステムに関する。

本発明はまた、ネットワークポートを有し、前記ネットワークワークポートを介して、少なくとも１つのサーバのコンテンツの検索が実行されることを許容するように構成されたサーバシステムと通信するように構成された消費者向け電子装置に関する。

斯かる方法、システム、消費者向け電子装置及びコンピュータプログラムのそれぞれの例は、EvilLyrics（http://www.evillabs.sk/evillyrics、FAQ:「How does it determine where to look for lyrics?」: browse candidates manually、2003年11月22日）より知られている。EvilLyricsは、歌詞を探すため一般的な検索エンジン（google（登録商標）、Alltheweb、Altavista（登録商標））を利用する。返される結果から、EvilLyricsは既知の歌詞サイトを選択する。EvilLyricsは、これら歌詞サイトの最初のものをダウンロードし、内蔵のフィルタを利用してパースしようと試みる。ページが合致するものであると思われる場合には、EvilLyricsが歌詞であるとみなしたものを歌詞枠に表示する。EvilLyricsは時々、実際の歌詞のページではなく、例えばアルバム全体についての歌詞のリストであるようなページを、歌詞サイトから返す。この場合には、EvilLyricsは該ページをパースし、対応する歌詞ページへのリンクを見出そうと試みる。これが失敗すると、検索エンジンから返された結果セットからの次のヒットを用いてやり直す。全ての結果が利用され、それら結果が全てEvilLyricsが探していたものではないと思われる場合には、エラーメッセージが表示され、歌詞ページは空白のままとなる。

該既知の方法の問題は、ネットワーク接続された装置による自動アクセスには非常に優れたものではない点である。このことは、斯かる装置が、歌詞ページにおける特定のマークアップに適合するようにプログラムされる必要があるという事実による。専門の歌詞ページのプロバイダがレイアウトを変更、又はアクセスをブロックした場合には、該装置は再プログラムされる必要がある。

本発明の目的は、種々の供給源からの結果を提供する検索クエリに基づいて、テキストの略正確な表現を取得するための方法、システム、消費者向け電子装置及びコンピュータプログラムを提供することにある。

本目的は、前記候補ファイルにおける前記文字列のうち少なくとも幾つかに基づくデータを比較するステップと、前記文字列のうち少なくとも幾つかに基づくデータが類似度の基準を満足する候補ファイルから、前記サブセットを形成するステップと、を特徴とする、本発明による方法によって達成される。

本方法は、少なくとも１つのサーバのコンテンツの検索を許容するように構成されたサーバに発行された検索クエリに基づいて、複数の候補ファイルを取得するステップを含むため、一般の検索エンジンと併せた利用に有利に適しており、そのため本方法は１つの特定のデータベースに限定されない。本方法は、候補ファイルにおける文字列に基づくデータの比較を含むため、ブラウザプログラム等に供給され得るページレイアウトに関する命令のような命令を含むタグにより限定されない。該比較は複数の候補ファイルの並べ替えを可能とし得るため、本方法は、検索クエリにより複数の候補ファイルが得られるという事実に対処することができる。該比較は人間の介入を必要としないため、自動化に適している。例えば、テキストの正確な表現は複数の候補ファイル内で最も共通して出現する見込みが高いため、本方法はテキストの正確な表現を提供することに適している。

一実施例は、
前記複数の候補ファイルのそれぞれについての文字列の特徴セットを形成するために、前記複数の候補ファイルのそれぞれから特定の数の異なる文字列を抽出するステップと、
複数の前記文字列の特徴セットを、少なくとも１つの他の前記文字列の特徴セットと比較するステップと、
を含み、前記特徴文字列の特徴セットが特定の数よりも多い文字列を共通して持つような候補ファイルが、前記サブセットに追加される。

これらの特徴の効果は、前記比較を計算的に比較的効率の良いものとする点である。２つの候補ファイルの各比較は、２つの候補ファイル中の全ての文字列により形成されるテキストの長さにおいて線形である。ｎ個の文字列の本文から、特定の（即ち対応する）数の文字列、例えばｋ個の文字列を抽出することは、Ｏ（ｎ）の演算を必要とする。ｋ個の文字列を、例えばアルファベット順のように、順番に並べ替えることは、Ｏ（ｋ・ｌｏｇｋ）の演算を必要とする。ｋ個の文字列を比較することは、Ｏ（ｋ）の演算を必要とする。１つの比較ための演算の総数はかくしてＯ（ｎ＋ｋ＋ｋ・ｌｏｇｋ）となり、Ｏ（ｎ^２）の演算を必要とする最長共通部分列比較のような比較と好適に同等となる。

本実施例の第１の変形例においては、前記複数の候補ファイルのそれぞれから特定の数の異なる文字列を抽出するステップは、前記複数の候補ファイルのそれぞれの少なくとも一部における異なる文字列を、前記文字列の長さによって並べ替えるステップと、最も長い前記文字列から前記特定の数の異なる文字列を選択するステップと、を含む。

このことは、前記比較に起因する並べ替えを比較的効果的なものとする。なぜなら、テキスト中の最長文字列は一般に、テキストの最も特徴的なものであるからである。かくして、最長文字列は、テキストの識別において非常に有効である。

一変形例は、更なる規則に従って等しい長さを持つ異なる文字列のなかから文字列を選択するステップを含む。

かくして、幾つかの等しい長さの異なる文字列が見出された場合、それら文字列の全てよりも少なく選択して、特徴セットを形成するための基準が存在する。本実施例は、各特徴セットが、複数の候補ファイルから特定の即ち一定の数の文字列を抽出することにより形成される、という要件を満たすことを支援する。

代替実施例においては、前記候補ファイルから特定の数の異なる文字列を抽出するステップは、
前記候補ファイルにおける少なくとも選択された異なる文字列の出現の頻度を決定するステップと、
少なくとも選択された頻度範囲内で、最も高い出現の頻度を持つ前記選択された異なる文字列から前記特徴セットを形成するステップと、
を含む。

一般に、最も頻繁に出現する文字列は、該文字列が一般的な語即ち「ストップ」ワードを表すものでない限り、テキストを非常に良く定義する。かくして、出現頻度が決定される選択される種々の文字列は、斯かる一般的な語即ち「ストップ」ワードの所定のリストに存在しないように選択されることができる。代替として、選択される頻度範囲は、任意のテキストにおいて斯かる「ストップ」ワードが出現する傾向のある（より高い）頻度を除外しても良い。

本方法の一実施例は、
前記文字列のうち少なくとも幾つかに基づくデータが前記類似度の基準を満足する複数の前記候補ファイルに共通する少なくとも１つの文字列に基づいて検索クエリを作成することにより、付加的な候補ファイルを取得するステップと、
前記少なくとも１つのサーバのコンテンツの検索を許容するように構成されたサーバシステムに対して、前記作成された検索クエリを発行するステップと、
を含む。

本実施例は、不完全に作成された初期検索クエリの悪影響を克服することを支援する。このことは特徴ファイルの範囲を拡大し、種々のタイトルによりテキストが知られている場合に特に有用である。

一実施例においては、前記複数の候補ファイルは、前記少なくとも１つのサーバに保存されたデータをダウンロードし、前記ダウンロードされたデータのキャッシュを保持し、前記キャッシュされたコンテンツのインデクスを形成し、前記検索クエリを前記インデクスと比較するように構成されたサーバシステムに発行される検索クエリに基づいて取得され、
前記複数の候補ファイルは、前記サーバシステムにより保持される前記キャッシュから取得されるデータに基づいて得られる。

本実施例は、自動化された実装に特に適している。なぜなら、少なくとも１つのサーバに保存されたデータを、該データが移動された後であるがインデクスが更新される前に、該サーバから直接にダウンロードする試みが為される場合に発生し得るブレークダウンを回避するからである。

一実施例においては、前記サブセットは、
（Ａ）基本セットに含めるための少なくとも１つの初期候補ファイルを選択するステップと、
（Ｂ）前記複数の候補ファイルのうちの複数の候補ファイルのそれぞれについて、前記基本セットに含めるために以前に選択された候補ファイルのみにおける前記文字列のうち少なくとも幾つかに基づくデータと比較して、前記文字列のうち少なくとも幾つかに基づくデータが類似度の基準を満足するか否かを決定するステップと、
（Ｃ）前記類似度の基準が満足されていることを決定したときに、前記候補ファイルを前記基本セットに追加するステップと、
を少なくとも１回実行することによって形成される。

本実施例は、比較的効率的である。なぜなら一般に、各候補ファイルの文字列の少なくとも幾つかに基づくデータを、各他の特徴ファイルの文字列の少なくとも幾つかに基づくデータと比較する必要を回避するからである。換言すれば、比較の数が低減させられる。事実上、特徴ファイルのクラスタが形成される。

本実施例の変形例においては、前記複数の候補ファイルのうちの複数の候補ファイルのそれぞれについて、前記文字列のうち少なくとも幾つかに基づくデータが前記類似度の基準を満足しているか否か及び基本セットが特定の数よりも少ないメンバを有しているか否かが決定されると、更なる基本セットが前記更なる基本セットに含めるための少なくとも１つの初期候補ファイルを選択することにより形成され、各前記選択された初期候補ファイルは、以前に形成されたいずれの基本セットに含めるために選択された初期候補ファイルとも異なるものであり、前記ステップ（Ａ）乃至（Ｃ）が前記更なる基本セットを完成させるために繰り返される。

かくして、初期候補ファイルの準最適な選択が、不完全な結果をもたらすことが回避される。類似する候補ファイルの幾つかのクラスタが形成される。

更に拡張された変形例は、複数の前記基本セットを形成しそれぞれが前記特定の数よりも少ないメンバを有することを決定すると、前記特徴ファイルからの前記サブセットとして最も多いメンバを持つ前記基本セットを選択して前記テキストの表現を形成するステップを含む。

かくして、複数の候補ファイルの文字列が非常に大きく異なる場合であっても、結果に常に到達する。

一実施例は、
選択基準を利用して前記複数の候補ファイルのそれぞれについての文字列の特徴セットを形成するために、前記複数の候補ファイルのそれぞれから特定の数の異なる文字列を抽出するステップと、
前記選択基準により決定された前記文字列のうち少なくとも１つの重要度に応じて、前記文字列の前記特徴セットをランク付けするステップと、
前記特徴セットが、初期候補ファイルとして以前に選択されたいずれの候補ファイルについての特徴セットよりも低い、前記ランクにおける最上位に出現するファイルを、少なくとも１つの前記初期候補ファイルとして選択するステップと、
を含む。

本実施例は、初期候補ファイルの選択において非常に効果的であり、メンバがテキストを最良に表現していることを仮定するに十分なサイズの基本セットへと導く見込みが高いという利点を持つ。かくして、本実施例もまた比較的効率的である。なぜなら、最良の初期候補ファイルの選択が、より少ない比較の実行を許容するからである。

一実施例においては、
前記複数の候補ファイルは、前記文字列及びクライアントを制御するための制御コードを表す列を含む複数のソースファイルを取得することにより取得され、
前記文字列は、前記複数の候補ファイルを形成するため、規則のセットに従って前記複数のソースファイルからフィルタリングされる。

本実施例は、ＨＴＭＬ（Hypertext Markup Language）ファイルのような、マークアップコードを含むテキストファイルを検索するために検索エンジンを利用してテキストの表現を取得するために特に適している。なぜなら、テキストがマークアップコードから分離されるからである。

他の態様によれば、本発明によるシステムは、前記候補ファイルにおける前記文字列のうち少なくとも幾つかに基づくデータを比較して、前記文字列のうち少なくとも１つに基づくデータが類似度の基準を満足する候補ファイルから前記サブセットを形成するように構成されたことを特徴とする。

好適には、本システムは本発明による方法を実行するように構成される。

他の態様によれば、本発明は、ネットワークポートを有し、前記ネットワークワークポートを介して、少なくとも１つのサーバのコンテンツの検索を許容するように構成されたサーバと通信するように構成された消費者向け電子装置であって、本発明によるシステムを有する消費者向け電子装置を提供する。

他の態様によれば、本発明は、機械読み取り可能な媒体に組み込まれたときに、情報処理機能を持つシステムに本発明による方法を実行させることが可能な命令のセットを含む、コンピュータプログラムを提供する。

本発明はまた、テキストの表現を含むデータファイルを取得する装置であって、
文字列を含む複数の候補ファイルを取得し、
前記複数の候補ファイルのサブセットを形成し、
前記サブセットのみにおける前記特徴ファイルの少なくとも１つから前記テキストの表現を形成するように構成された装置において、
前記装置は更に、前記候補ファイルにおける前記文字列のうち少なくとも幾つかに基づくデータを比較して、前記文字列のうち少なくとも幾つかに基づくデータが類似度の基準を満足する候補ファイルから前記サブセットを形成するように構成されたことを特徴とする装置を提供する。

本発明は、添付図面を参照しながら、以下に更に詳細に説明される。

以下の説明において、曲の歌詞を含むテキストファイルが、従来の検索エンジンを実装するサーバシステムに対するクエリに基づいて得られる方法の詳細が示される。しかしながら本方法は、例えばＨＴＭＬファイルを保存するサーバのような複数のサーバに種々のバージョンが保存された他の種類のテキストの表現を取得するためにも、同様に適している。例には、例えばゲティスバーグの演説や聖書のテキスト等のような、良く知られた演説又は書籍のテキストを含むファイルを含む。

図１において、第１、第２及び第３のウェブサーバ１乃至３が、例えばインターネットのようなＷＡＮ（wide area network）４に接続されている。ウェブサーバ１乃至３のそれぞれは、ブラウザによるテキストの表示を制御するための制御コード、即ちウェブサーバ１乃至３がホストとなるＨＴＭＬ文書をユーザが表示し該文書とインタラクトすることを可能とするソフトウェアアプリケーションを表すテキスト及び文字列を表す文字列を含む複数のＨＴＭＬファイルのホストである。勿論、図１においては簡単さのためにウェブサーバ１乃至３の数が３つに限定されているのであり、現実的な実装においては、より多くのサーバが存在する。

サーバシステム５は、ウェブサーバ１乃至３がホストとなっているファイルのコンテンツの検索を許容するように構成される。サーバシステム５は、検索エンジンを実装する。該検索エンジンは、例えばgoogle（登録商標）、Yahoo!（登録商標） Search、MSN（登録商標） search等のような、それ自体知られた種類のものである。代替の実施例においては、サーバシステム５は、幾つかの斯かる検索エンジンに検索クエリを発行して、結果を併合するタイプのものである。本発明はＨＴＭＬ文書に限定されるものではなく、ＲＳＳフィード（ウェブ放送のためのＸＭＬ（eXtensible Markup Language）フォーマットの一種）及びＰＤＦ（Portable Document Format）ファイルを含む、他のタイプのコンテンツを検索するように構成された検索エンジンに発行される検索クエリの結果を利用しても良い。また、ウェブサーバ１乃至３はＨＴＴＰプロトコルに従って動作するが、以下に示される本方法の変形例は、ＦＴＰサーバを検索するための検索エンジン又はGopherプロトコルのための検索エンジンにより提供される結果を利用する。

図１に示された状況において利用されるようなウェブ検索エンジンは、ウェブサーバ１乃至３からファイルを取得することにより機能する。これらのファイルは、スパイダ（spider）又はクローラ（crawler）により取得される。該取得されたファイルは、該ファイルがＨＴＭＬ以外のフォーマットである場合には最初にＨＴＭＬに変換され、次いでキャッシュされる。該キャッシュされたＨＴＭＬファイルの内容は、該ファイルの内容を解析することによりインデクシングされる。該インデクシング処理に起因するデータは、インデクスデータベースに保存される。検索クエリがサーバシステム５に発行されると、該検索クエリは前記インデクスデータベース中のデータと比較され、クローラにより取得されたときに該インデクスされたファイルが保存されていた場所へのリンクを含む結果を返す。

検索クエリは、一般的な表現の形でサーバシステム５に発行される。一般的な表現とは、特定の文法規則に従った文字列のセットを記述する又は該セットに合致する文字列である。該表現は、文字列のセットを記述する表現であり、時にパターンとして知られる。

図１に示されるシステムは、歌詞サーバ６を含む。本システムは更に、例えばＭＰ３、ＷＭＡ又は同様のフォーマットのファイルのような、圧縮された音楽ファイルをデコードするためのデコーダアプリケーションを備えた携帯電話のような、モバイル型コンテンツプレイヤ７を含む。モバイル型コンテンツプレイヤ７は、ゲートウェイ８及びセル無線通信網９を介して、ＷＡＮ４に接続されている。歌詞サーバ６は、モバイル型コンテンツプレイヤ７に曲の歌詞の表現を含むファイルを供給するため、以下に説明されるような方法を実行するように構成される。

モバイル型コンテンツプレイヤ７は、歌詞ファイルの要求を含むメッセージを、歌詞サーバ６に送信する。該要求は、歌詞が要求される曲に関連するデータを有する。例えば、モバイル型コンテンツプレイヤ７は、圧縮されたオーディオデータを含むファイルから、１以上の識別タグを取得しても良い。斯かる識別タグは一般に、アーティストの名前及びトラックの名前を含む。

歌詞サーバ６は、該要求を取得し、該要求から要求された曲を識別するデータを取得する。該データは、ＷＡＮ４を介してサーバシステム５に発行される検索クエリを、一般的な表現で作成するために利用される。検索エンジンを有するサーバシステム５から検索結果を得るために、ラッパ（wrapper）プログラムが利用される。該ラッパプログラムは、サーバシステム５により、検索エンジンに対するインタフェースとして提供されたウェブサイトからのデータを抽出する。該ラッパプログラムは、サーバシステム５により提供されるウェブサイトのコヒーレント構造を利用して、前記検索クエリに合致するファイルが保存されている場所のＵＲＬ（Uniform Resource Locator）を取得する。歌詞サーバ６は好ましくは、検索エンジンにより提供されるＡＰＩ（Application Program Interface）を利用して、検索結果として示されたＵＲＬのコンテンツを取得する。

一実施例においては、該ＡＰＩは、キャッシュ要求と呼ばれる方法を提供し、該方法によりＵＲＬが検索エンジンのＡＰＩサービスに入力される。該ＡＰＩサービスは、検索エンジンのクローラが最後に当該ＵＲＬを巡回したときにサーバシステム５によりキャッシュされた、該ＵＲＬのコンテンツを返す。その効果は、歌詞サーバ６が、ウェブサーバ１乃至３の１つからコンテンツを、該コンテンツが移動された後に取得しようと試みた場合に生じ得るエラーメッセージに対処する必要がない点である。好適には、サーバシステム５により保持されるキャッシュは、ＨＴＭＬファイルの形のもののみである。このことは、歌詞サーバ６による変換の必要を回避する。

図２に示された一実施例においては、歌詞サーバ６は、一連のキャッシュ要求をサーバシステム５に発行することにより、ＨＴＭＬファイルのセット１０を取得する（ステップ１１）。

続くステップ１２において、歌詞サーバ６は、候補ファイルのセット１３を生成する。ここで利用されるように、ファイルなる語は、単一の単位として保存されるビットのシーケンスを意味することに留意されたい。該単位は、歌詞サーバ６における利用においてファイルシステムにより保持されるファイルに対応する必要はない。しかしながら、単純な、且つこの理由のため好適な実装においては、候補ファイルのセット１３は、プレーンテキストファイルのセットにより形成される。各テキストファイルは、ＨＴＭＬファイルのセット１０の対応する１つに基づく。

ＨＴＭＬファイルのセット１０から歌詞を抽出するステップ１２を実行する際、歌詞サーバは、文字列とブラウザクライアントを制御するための制御コードを表す列とを解析する。該文字列は、それぞれがＨＴＭＬファイルのセット１０の対応する１つに基づく候補ファイルのセット１３からフィルタリングされる。本処理において、ＨＴＭＬタグ、広告及び周囲のテキストが破棄されるか、又はプレーンテキストファイルにおける対応する文字コードにより置換される。例えば、＜ｂｒ＞タグは改行文字により置換される。歌詞を抽出して候補ファイルのセット１３を形成する処理は、歌詞の構造的特徴に基づいて実行され、それによりＨＴＭＬ文書の内容全体の中で歌詞を特定する。かくして、候補ファイルのセット１３を形成するため、規則のセットが利用される。

規則の例は、以下を含む：
−曲の歌詞は、空白行により分離された、テキストのブロックから構成される。典型的には１乃至１０個のブロックがある。各ブロックは典型的に、１乃至１０行から成り、各行は典型的に３乃至６０個のキャラクタから成る。該キャラクタの少なくとも半分が文字である。
−歌詞の行は＜ＢＲ＞タグにより明示的に分断され、他のＨＴＭＬタグを含まない。
−歌詞は通常、少なくとも曲のタイトル、更に時にはアーティストの名前、アルバムの名前又は「歌詞」なる語を含む行により先行される。該行は通常、歌詞のものとは異なるフォントのものである。

続くステップ１４において、セット１３における複数の候補ファイルのそれぞれから、特定の数ｋ個の異なる文字列が抽出され、該複数の候補ファイルのそれぞれについて文字列の特徴セットを形成する。これら特徴セットはここでは指紋（fingerprintｔ）と呼ばれ、図２において指紋のテーブル１５として示される。ここでは指紋なる語が用いられるが、これらは通常の意味での指紋ではなく、指紋は該指紋に対する及び該指紋が生成される基となった特徴ファイルについて一意である必要はない。数ｋは、セット１３における候補ファイルのそれぞれについて同一である。本実施例においては、該数は予め決定された数である。該数は、セット１３における候補ファイルの数に依存する変数であっても良い。

指紋を抽出するステップ１４の幾つかのとり得る代替の実装のうち、１つが利用される。

第１の実施例においては、セット１３における複数の候補ファイルのそれぞれの少なくとも一部における異なる文字列が該文字列の長さによって並べ替えられ、最長のものからｋ個の文字列が選択される。原則として、ｋ個の最長のものが選択される。しかしながら、特定の文字列の選択を禁止する１以上の規則があっても良い。これら文字列は、例えばタイトルにおける語に対応する文字列を含んでも良い。一変形例においては、候補ファイルのセット１３のそれぞれが、全体として解析される。他の変形例においては、ｋ個の最長文字列を決定するために、各候補ファイルの一部のみが解析される。該解析が、等しい長さの幾つかの異なる文字列が存在することを明らかにすると、更なる規則に従って、これら文字列のうち十分な数のものが選択され、ｋ個の文字列のセットに帰着する。例えば、文字列が長さによって並べ替えられている候補ファイルの一部において最も高い頻度で出現する等しい長さを持つ文字列が、指紋を完成させるために選択されても良い。

第２の実施例においては、歌詞サーバ６が、候補ファイルにおける少なくとも選択された異なる文字列の出現の頻度を決定する。該サーバは、少なくとも選択された頻度範囲内で、最も高い出現の頻度を持つ選択された異なる文字列から、指紋を形成する。「the」、「a」、動詞の語形変化「to be」及び「to have」等のような一般的なストップワードの選択を防ぐため、これらストップワードは選択から除外される。適用分野において一般的なストップワードもまた、除外されても良い。例えば、歌詞に適用される場合には、語「love」と「you」との組み合わせが除外されても良い。代替として、考慮される歌詞の言語におけるテキスト中のストップワードの通常の出現の頻度の知識が、頻度範囲を限定するために利用されても良い。歌詞の言語は、モバイル型コンテンツプレイヤ７により発行された要求を介して、歌詞サーバ６に知られていても良い。

指紋のテーブル１５における指紋が取得される方法にかかわらず、合致する指紋のテーブル１６が続いて形成される（ステップ１７）。該ステップ１７において、候補ファイルにおける文字列の少なくとも幾つかに基づく（即ち対応する）指紋が、少なくとも１つの他の指紋とそれぞれ比較され、これら指紋が類似度の基準を満たすか否かを決定する。図２の実施例においては、図３のものと対照的に、各指紋は他の各指紋と比較される。指紋におけるｋ個の文字列のうちｂ個が合致した場合、類似度の基準が満たされる。一変形例においては、該類似度の基準を満足し且つ殆どのメンバを持つ指紋の群が選択され、合致する指紋のテーブル１６を形成する。

次いで（ステップ１８）、合致する指紋のテーブル１６における指紋に関連する候補ファイルが決定される。これらファイルは候補ファイルのサブセット１９を形成し、該サブセットに基づいて単一の歌詞ファイル２０が形成される（ステップ２１）。

ステップ２１は、幾つかの方法のうちいずれかにより実装されても良い。単純な実装の１つは、歌詞ファイル２０をサブセット１９からランダム的に選択することである。他の変形例においては、サブセット１９のサイズを更に低減させるために、更なる解析が該サブセット１９に適用される。例えば、ｍ個（ｍ＞ｋ）の文字列の指紋を用いて図２の方法が繰り返されても良い。他の変形例においては、候補ファイルの内容は、断片に分割される。本変形例においては、歌詞ファイル２０は順序付けられた断片のシーケンスとして形成され、該断片の少なくとも１つは、特定の基準を満たすサブセット１９中の候補ファイルからの断片のクラスタに基づいて構築される。かくして、歌詞ファイル２０の内容は、サブセット１９における複数の候補ファイルから取得される。本実施例は、本出願人による、「Method, system and device for obtaining a representation of a text」と題された、本願と同じＥＰ優先日を持つ公開された同時係属中の特許出願において、より完全に開示されている手法を利用しても良い。歌詞ファイル２０は、ＷＡＮ４、ゲートウェイ８及びセル無線通信網９を介して、モバイル型コンテンツプレイヤ７に供給される。

歌詞ファイル２２を取得する第２の方法が、図３及び４に示される。第１のステップ２３は図２における第１のステップ１１に対応し、ＨＴＭＬファイルのセット２４を取得するために利用される。図２に示された方法の第１のステップ１１に関して以上に議論されたいずれの変形例も、図３に示される第１のステップ２３を実装するために利用可能である。

候補ファイルのセット２５は、図２に示された方法における対応するステップ１２におけるものと全く同じ方法で生成される（ステップ２６）。指紋の第１のテーブル２７が、図２の方法における対応するステップ１４におけるものと同様に生成される（ステップ２８）。

図３の変形例においては、比較的効率的に指紋を照合するため、クラスタリングアルゴリズムが利用される。第１のステップ２９において、指紋に含めるための文字列を選択するための基準により決定される、各指紋における文字列の少なくとも１つの重要度（significance）に従って、第１のテーブル２７における指紋をランク付けすることにより、指紋の順序付けられたテーブル３０が生成される。かくして、セット２５の候補ファイルにおける文字列が、該文字列から最長のｋ個の文字列を選択するために長さに従って並べ替えられている場合には、第１のテーブル２７における指紋がここで該テーブルに含まれる文字列の長さに従って並べ替えられる。一変形例においては、各指紋における最長文字列の長さが、該指紋をランク付けするために利用される。他の変形例においては、最短文字列の長さがとられる。他の変形例においては、各指紋における文字列の平均長が決定され、該指紋をランク付けするために利用される。更に他の変形例においては、指紋におけるそれぞれの文字列の長さの合計が利用される。有利な変形例においては、前記順序付けは、指紋の最も重要な文字列を最初に比較することにより実行される。これに関連する基準が等しい（２つの指紋における最長文字列の長さが等しい）場合、２つの指紋における次に重要な文字列が比較される、等する。

指紋を抽出するステップ２８において、選択された文字列の出現の頻度が利用された場合、順序付けられたテーブル３０は、それぞれの指紋における文字列の１つ又は幾つかに関連する頻度に従って指紋をランク付けする。一変形例においては、指紋は、それぞれの指紋を形成する文字列の出現の頻度の合計に従ってランク付けされる。

候補ファイルの基本セット３１が、ここで選択される（ステップ３２）。基本セット３１は、指紋の順序付けられたテーブル３０の先頭において指紋が出現する、少なくとも１つの候補ファイルから開始する。並べ替え操作（ステップ２９）の効果は、順序付けられたテーブル３０の先頭において出現する指紋が、完全な歌詞についての指紋である見込みが高く、一方で底部に近い指紋が、不完全な歌詞についての指紋である見込みが高い点である。かくして、クラスタリングは、「正確な」歌詞を表す見込みが非常に高い候補ファイルから開始する。

好適な変形例において、順序付けられたテーブル３０の先頭は、少なくともＣ個の文字列を共通に持つ２つの指紋を探すために検索される。関連する候補ファイルは、初期候補ファイルとして基本セット３１に割り当てられる。該初期候補ファイルは、順序付けられたテーブル３０の先頭において指紋が出現するものから選択されるため、これらファイルは歌詞の完全なバージョンを表している見込みが非常に高い。

次のステップ３３において、基本セット３１に既に追加されている候補ファイルについての指紋のみに対して、更なる指紋が比較される。該更なる指紋が類似度基準を満たさない場合には、順序付けられたテーブル３０における次の指紋が選択される。該指紋が類似度基準を満たすと、関連する候補ファイルが基本セットに追加される（ステップ３４）。

セット２５にＮ個の候補ファイルがあると仮定すると、基本セット３１に候補ファイルを追加するステップ３３及び３４は、基本セットが十分大きくなるまで繰り返される。このことに対する基準は、該基本セットがＮ／ｉ個（２＜ｉ＜Ｎ）よりも多いメンバを有することである。全ての指紋が比較された後にも該基準が満たされない場合には、少なくとも１つの更なる基本セットへ含めるための、初期候補ファイルの別の対が選択される。該選択は、該別の対が、以前に形成されたいずれの基本セットについての初期候補ファイルとしても選択されていないものとなるように為される。

前記更なる基本セットの最初のもの又はいずれかがＮ／ｉ個よりも多いメンバを含むという基準を満たす場合、十分な数のメンバを持つという基準を満たす基本セット３１により構成される候補ファイルのサブセット３５が形成される（ステップ３６）。

複数の基本セットを形成し、それぞれがＮ／ｉ個よりも少ないメンバを有すると決定した際に、これ以上の基本セットが形成され得ない又はされるべきでないことが分かった場合には、これ以前に形成された複数の基本セットのうち最長のものが、候補ファイルのサブセット３５を構成するために利用される。基本セットを形成するためのステップ３２乃至３４の繰り返しの回数は、例えば所定の数に制限されても良い。代替として、歌詞サーバ６が、セット２５中の候補ファイルのそれぞれが、基本セット３１についての初期候補ファイルとして選択されていることを決定しても良い。

一実施例においては、ここで歌詞ファイル２２が、図２の方法における対応するステップ２１に関して以上に概説された方法を利用して、候補ファイルのサブセット３５に基づいて形成される。

図３及び４に示された実施例においては、候補ファイルのサブセット３５がＸ個よりも少ないメンバを有すると決定された場合には、歌詞サーバ６が該サブセット３５を拡張する。このことは、図４に模式的に示される。歌詞サーバ６は、以前に取得された候補ファイルのサブセット３５における複数の候補ファイルに共通する少なくとも１つの文字列に基づいて少なくとも１つの検索クエリを形成する（ステップ３８）ことにより、付加的な候補ファイルのセット３７を得る。

該検索クエリは通常の表現のものである。該検索クエリは、サーバシステム５がホストとなっている検索エンジンに発行される（ステップ３９）。図２及び３における示された同様のステップ１１及び２３に関して以上に概説した態様で、付加的なＨＴＭＬファイルのセット４０が得られる（ステップ４１）。

付加的な候補ファイルのセット３７は、図２及び３に示された対応するステップ１２及び２６におけるものと同一の、図２に示されたステップ１２に関して以上に説明された態様で得られる。

次いで、付加的な指紋４３が、セット３７における付加的な候補ファイルから抽出される（ステップ４４）。付加的な指紋４３は、指紋の第１のテーブル２７に追加される（ステップ４５）。付加的な候補ファイル３７は、候補ファイルのセット２５に追加される（ステップ４６）。次いで、ステップ２９、３２乃至３４及び３６が繰り返されて候補ファイルの新たなサブセット３５を形成し、該サブセットに基づいて、図３及び４に示された方法の最後のステップ４７において歌詞ファイル２２が形成される。該最後のステップ４７は、図２に示された方法における最後のステップ２１に対応する。該ステップ２１のいずれの実装が、図３及び４に示された方法の最後のステップ４７において利用されても良い。

付加的なＨＴＭＬファイルのセット４０を取得するために新たな検索クエリを形成することにより、候補ファイルのサブセット３５を拡張することの効果は、歌詞ファイル２２が、より多くの候補ファイルに基づくものとなる点である。このことは、歌詞ファイル２２の内容が正確なものである見込みを高くする。他の効果は、ユーザの介入の必要が少ない点である。なぜなら、本方法は、最初のステップ２３、２６、２８乃至２９、３２乃至３４及び３６が歌詞サーバ６のようなデータ処理システムにより自動的に実行される場合に得られる候補ファイルのサブセット３５の内容を解析することにより、候補ファイルのセット２５を自動的に拡張するからである。かくして本方法は、本方法を実行するデータ処理システムが、いずれの歌詞サーバ又は検索エンジンとも独立したものとなるように、自動化された実行を許容するように構成される。テキストの最も正確なバージョンが、該テキストの正確なバージョンを得るために複数のファイルを利用して形成され、それぞれのサーバより得られる。

上述の実施例は本発明を限定するものではなく説明するものであって、当業者は添付する請求項の範囲から逸脱することなく多くの代替実施例を設計することが可能であろうことは留意されるべきである。請求項において、括弧に挟まれたいずれの参照記号も、請求の範囲を限定するものとして解釈されるべきではない。「有する（comprise）」なる語は、請求項に記載されたもの以外の要素又はステップの存在を除外するものではない。要素に先行する「１つの（a又はan）」なる語は、複数の斯かる要素の存在を除外するものではない。特定の手段が相互に異なる従属請求項に列挙されているという単なる事実は、これら手段の組み合わせが有利に利用されることができないことを示すものではない。

例えば、モバイル型コンテンツプレイヤ７及び歌詞サーバ６を利用する実施例が説明されたが、一代替実施例は、ネットワーク接続を持つ単一のコンピュータ（例えばパーソナルコンピュータ）上のプログラムのみを含む。代替として、モバイル型コンテンツプレイヤ７がテキストファイルに導く本方法全体を実行しても良いし、又はインターネットを検索するための検索エンジンをも有するサーバシステム５によって本方法全体が実行されても良い。

テキストの表現を取得する方法の適用のためのシステムの実施例を模式的に示す。 テキストの表現を取得する方法の第１の例を示すフロー図である。 テキストの表現を取得する方法の第２の例を示すフロー図である。 図３に示された方法における更なるステップを示すフロー図である。

Claims (17)

1. 例えば曲の歌詞のようなテキストの表現を含むデータファイルを取得する方法であって、
   少なくとも１つのサーバのコンテンツの検索が実行されることを許容するように構成されたサーバシステムに対して発行された検索クエリに基づいて、文字列を含む複数の候補ファイルを取得するステップと、
   前記複数の候補ファイルのサブセットを形成するステップと、
   前記サブセットのみにおける少なくとも１つの前記候補ファイルから、前記テキストの表現を形成するステップと、
   を有する方法において、
   前記候補ファイルにおける前記文字列のうち少なくとも幾つかに基づくデータを比較するステップと、前記文字列のうち少なくとも幾つかに基づくデータが類似度の基準を満足する候補ファイルから、前記サブセットを形成するステップと、
   を特徴とする方法。
2. 前記複数の候補ファイルのそれぞれについての文字列の特徴セットを形成するために、前記複数の候補ファイルのそれぞれから特定の数の異なる文字列を抽出するステップと、
   複数の前記文字列の特徴セットを、少なくとも１つの他の前記文字列の特徴セットと比較するステップと、
   を含み、前記特徴文字列の特徴セットが特定の数よりも多い文字列を共通して持つような候補ファイルが、前記サブセットに追加される、請求項１に記載の方法。
3. 前記複数の候補ファイルのそれぞれから特定の数の異なる文字列を抽出するステップは、前記複数の候補ファイルのそれぞれの少なくとも一部における異なる文字列を、前記文字列の長さによって並べ替えるステップと、最も長い前記文字列から前記特定の数の異なる文字列を選択するステップと、を含む、請求項２に記載の方法。
4. 更なる規則に従って等しい長さを持つ異なる文字列のなかから文字列を選択するステップを含む、請求項３に記載の方法。
5. 前記候補ファイルから特定の数の異なる文字列を抽出するステップは、
   前記候補ファイルにおける少なくとも選択された異なる文字列の出現の頻度を決定するステップと、
   少なくとも選択された頻度範囲内で、最も高い出現の頻度を持つ前記選択された異なる文字列から前記特徴セットを形成するステップと、
   を含む、請求項２に記載の方法。
6. 前記文字列のうち少なくとも幾つかに基づくデータが前記類似度の基準を満足する複数の前記候補ファイルに共通する少なくとも１つの文字列に基づいて検索クエリを作成することにより、付加的な候補ファイルを取得するステップと、
   前記少なくとも１つのサーバのコンテンツの検索を許容するように構成されたサーバシステムに対して、前記作成された検索クエリを発行するステップと、
   を含む、請求項１乃至５のいずれか一項に記載の方法。
7. 前記複数の候補ファイルは、前記少なくとも１つのサーバに保存されたデータをダウンロードし、前記ダウンロードされたデータのキャッシュを保持し、前記キャッシュされたコンテンツのインデクスを形成し、前記検索クエリを前記インデクスと比較するように構成されたサーバシステムに発行される検索クエリに基づいて取得され、
   前記複数の候補ファイルは、前記サーバシステムにより保持される前記キャッシュから取得されるデータに基づいて得られる、請求項１乃至６のいずれか一項に記載の方法。
8. 前記サブセットは、
   （Ａ）基本セットに含めるための少なくとも１つの初期候補ファイルを選択するステップと、
   （Ｂ）前記複数の候補ファイルのうちの複数の候補ファイルのそれぞれについて、前記基本セットに含めるために以前に選択された候補ファイルのみにおける前記文字列のうち少なくとも幾つかに基づくデータと比較して、前記文字列のうち少なくとも幾つかに基づくデータが類似度の基準を満足するか否かを決定するステップと、
   （Ｃ）前記類似度の基準が満足されていることを決定したときに、前記候補ファイルを前記基本セットに追加するステップと、
   を少なくとも１回実行することによって形成される、請求項１乃至７のいずれか一項に記載の方法。
9. 前記複数の候補ファイルのうちの複数の候補ファイルのそれぞれについて、前記文字列のうち少なくとも幾つかに基づくデータが前記類似度の基準を満足しているか否か及び基本セットが特定の数よりも少ないメンバを有しているか否かが決定されると、更なる基本セットが前記更なる基本セットに含めるための少なくとも１つの初期候補ファイルを選択することにより形成され、各前記選択された初期候補ファイルは、以前に形成されたいずれの基本セットに含めるために選択された初期候補ファイルとも異なるものであり、前記ステップ（Ａ）乃至（Ｃ）が前記更なる基本セットを完成させるために繰り返される、請求項８に記載の方法。
10. 複数の前記基本セットを形成しそれぞれが前記特定の数よりも少ないメンバを有することを決定すると、前記特徴ファイルからの前記サブセットとして最も多いメンバを持つ前記基本セットを選択して前記テキストの表現を形成するステップを含む、請求項９に記載の方法。
11. 選択基準を利用して前記複数の候補ファイルのそれぞれについての文字列の特徴セットを形成するために、前記複数の候補ファイルのそれぞれから特定の数の異なる文字列を抽出するステップと、
    前記選択基準により決定された前記文字列のうち少なくとも１つの重要度に応じて、前記文字列の前記特徴セットをランク付けするステップと、
    前記特徴セットが、初期候補ファイルとして以前に選択されたいずれの候補ファイルについての特徴セットよりも低い、前記ランクにおける最上位に出現するファイルを、少なくとも１つの前記初期候補ファイルとして選択するステップと、
    を含む、請求項８乃至１０のいずれか一項に記載の方法。
12. 前記複数の候補ファイルは、前記文字列及びクライアントを制御するための制御コードを表す列を含む複数のソースファイルを取得することにより取得され、
    前記文字列は、前記複数の候補ファイルを形成するため、規則のセットに従って前記複数のソースファイルからフィルタリングされる、請求項１乃至１１のいずれか一項に記載の方法。
13. 例えば曲の歌詞のようなテキストの表現を含むデータファイルを取得するシステムであって、
    少なくとも１つのサーバのコンテンツの検索が実行されることを許容するように構成されたサーバシステムに対して検索クエリを発行し、前記検索クエリに応じて文字列を含む複数の候補ファイルを取得するクライアントを含み、
    前記複数の候補ファイルのサブセットを形成し、前記サブセットのみにおける前記候補ファイルのうち少なくとも１つから前記テキストの表現を形成するように構成されたシステムにおいて、
    前記システムは更に、前記候補ファイルにおける前記文字列のうち少なくとも幾つかに基づくデータを比較して、前記文字列のうち少なくとも１つに基づくデータが類似度の基準を満足する候補ファイルから前記サブセットを形成するように構成されたことを特徴とするシステム。
14. 請求項１乃至１２のいずれか一項に記載の方法を実行するように構成された、請求項１３に記載のシステム。
15. ネットワークポートを有し、前記ネットワークワークポートを介して、少なくとも１つのサーバのコンテンツの検索が実行されることを許容するように構成されたサーバシステムと通信するように構成された消費者向け電子装置であって、請求項１３又は１４に記載のシステムを有する消費者向け電子装置。
16. 機械読み取り可能な媒体に組み込まれたときに、情報処理機能を持つシステムに請求項１乃至１２のいずれか一項に記載の方法を実行させることが可能な命令のセットを含む、コンピュータプログラム。
17. テキストの表現を含むデータファイルを取得する装置であって、
    文字列を含む複数の候補ファイルを取得し、
    前記複数の候補ファイルのサブセットを形成し、
    前記サブセットのみにおける前記特徴ファイルの少なくとも１つから前記テキストの表現を形成するように構成された装置において、
    前記装置は更に、前記候補ファイルにおける前記文字列のうち少なくとも幾つかに基づくデータを比較して、前記文字列のうち少なくとも幾つかに基づくデータが類似度の基準を満足する候補ファイルから前記サブセットを形成するように構成されたことを特徴とする装置。

Images