(57)【要約】  記憶された音楽の選択されたアイテムを非テキストベースで識別する方法。本方法の第１の広範な部分は、音楽識別データベースを構築するステップに焦点を合わせたものである。そのプロセスは、選択された音楽アイテムのタグを取り込むステップと、タグへの参照キーを開発するためにタグを処理するステップとを必要とする。次いで、参照キーおよび記憶された音楽への関連と共にタグを記憶する。データベースは、複数のタグを収集することによって構築される。本方法の第２の広範な部分は、データベースから記憶された音楽の所望のアイテムを検索するステップである。そのプロセスは、ユーザから照会タグを取り込むステップと、照会タグへの照会キーを開発するために照会タグを処理するステップとを必要とする。記憶された音楽の所望のアイテムを識別するために、照会タグをデータベースに記憶された参照キーと比較する。
2009516268.tif 000002
【特許請求の範囲】
【請求項１】
音楽の選択されたアイテムを非テキストベースで識別する方法において、
音楽識別データベースを構築するステップであって、
前記選択された音楽アイテムのタグを取り込むステップと、
前記タグへの参照キーを開発するために前記タグを処理するステップと、
前記参照キーおよび前記音楽アイテムへの関連と共に前記タグを記憶するステップと、
複数のタグを収集するステップと
を含むステップと、
前記データベースから音楽の所望のアイテムを検索するステップであって、
照会タグを取り込むステップと、
前記照会タグへの照会キーを開発するために前記照会タグを処理するステップと、
音楽の前記所望のアイテムを識別するために、前記照会キーを前記データベースに記憶された参照キーと比較するステップと
を含むステップと
を含む方法。
【請求項２】
前記音楽アイテムへの前記関連は、前記音楽アイテムに関係付けられた情報を含む、請求項１に記載の方法。
【請求項３】
前記音楽アイテムへの前記関連は、少なくとも音楽の前記選択されたアイテムの題名および演奏者を含む、請求項１に記載の方法。
【請求項４】
前記処理するステップのそれぞれは、
前記タグをフレームに分割するステップと、
各フレームを処理するステップであって、
前記フレームのピッチ曲線を検出するステップと、
休止を識別するステップと、
音境界をマークするステップと、
各音のピッチ値を判定するステップと、
各音の前記ピッチ値を量子化するステップと
を含むステップと、
処理されたフレームを、前記タグを識別用キーに組み立てるステップと
を含む、請求項１に記載の方法。
【請求項５】
音楽タグの集まりを組み立てる方法において、
複数のユーザがアクセス可能なコンピュータベースの位置を確立するステップと、
音楽タグを収集するコンピュータプログラム手段を設けるステップと、
音楽タグを収集するステップであって、
音楽の選択されたアイテムに関するタグを取り込むステップと、
前記タグへのキーを開発するために前記タグを処理するステップと、
前記キーおよび前記音楽アイテムへの関連と共に前記タグを記憶するステップと、
タグを提供するようにユーザに対して奨励するステップと
を含むステップと、
他のユーザによって提供された主旋律のユーザランク付けを取り込むステップと、
ユーザの間での対話を容易にするステップと
を含む方法。
【請求項６】
前記コンピュータベースの位置は、ウェブサイトである、請求項５に記載の方法。
【請求項７】
前記奨励することは、金銭的な奨励を含む、請求項５に記載の方法。
【請求項８】
前記金銭的な奨励は、前記提供されたタグの有効性の測定値に基づく、請求項７に記載の方法。
【請求項９】
前記奨励することは、タグ提出に基づいてユーザを公表することを含む、請求項５に記載の方法。
【請求項１０】
前記公表奨励は、前記提供されたタグの有効性の測定値に基づく、請求項９に記載の方法。
【請求項１１】
携帯電話機着信音を生成するために、選択されたタグを処理するステップと、
結果として得られる着信音をユーザに提供するステップと
をさらに含む、請求項５に記載の方法。
【請求項１２】
音楽識別データベースを構築する方法であって、
音楽タグを取り込むステップと、
前記タグへの参照キーを開発するために前記タグを処理するステップと、
前記参照キーおよび音楽アイテムへの関連と共に前記タグを記憶するステップと、
複数のタグを収集するステップと
を含む方法。
【請求項１３】
前記処理するステップは、
前記タグをフレームに分割するステップと、
各フレームを処理するステップであって、
前記フレームのピッチ曲線を検出するステップと
休止を識別するステップと、
音境界をマークするステップと、
各音のピッチ値を判定するステップと、
各音の前記ピッチ値を量子化するステップと
を含むステップと、
処理されたフレームを、前記タグを識別用キーに組み立てるステップと
を含む、請求項１２に記載の方法。
【請求項１４】
音楽アイテムを提供する方法であって、
音楽タグおよび前記音楽タグへの参照キーを含む第１のデータベースを設けるステップと、
ユーザから照会タグを取り込むステップと、
前記タグへの照会キーを開発するために前記タグを処理するステップと、
前記音楽タグが前記照会タグと最もよく合致することを判定するために、前記照会キーを前記データベース音楽参照キーと突き合わせるステップと、
前記最もよく合致するタグに関連する前記音楽アイテムを検索するステップと
を含む方法。
【請求項１５】
前記処理するステップは、
前記タグをフレームに分割するステップと、
各フレームを処理するステップであって、
前記フレームのピッチ曲線を検出するステップと
休止を識別するステップと、
音境界をマークするステップと、
各音のピッチ値を判定するステップと、
各音の前記ピッチ値を量子化するステップと
を含むステップと、
処理されたフレームを、前記タグを識別用キーに組み立てるステップと
を含む、請求項１４に記載の方法。
【請求項１６】
音楽アイテムを消費者に供給するシステムにおいて、
ＣＰＵ、周辺機器、および入出力デバイスを含み、リモートユーザとの通信のために、ネットワークに動作可能に接続されたコンピュータシステムと、
消費者によって入力された音楽タグを取り込む手段であって、前記タグが、参照タグまたは照会タグとして識別される、手段と、
前記タグへの識別用キーを開発するために前記タグを処理する手段と、
識別用キーおよびそれぞれの前記音楽アイテムへの関連と共に、参照タグを記憶するデータベース手段と、
音楽の所望のアイテムを識別するために、照会タグを記憶された参照タグと比較するマッチングアルゴリズム手段と
を含むシステム。
【請求項１７】
前記処理する手段は、
前記タグをフレームに分割する手段と、
各フレームを処理する手段であって、
前記フレームのピッチ曲線を検出するステップと、
休止を識別するステップと、
音境界をマークするステップと、
各音のピッチ値を判定するステップと、
各音の前記ピッチ値を量子化するステップと
を含む手段と、
処理されたフレームを、前記タグを識別用キーに組み立てる手段と
を含む、請求項１６に記載のシステム。
【請求項１８】
前記マッチングアルゴリズム手段は、識別用キーを前記照会タグおよび前記参照タグと比較する、請求項１６に記載のシステム。
【請求項１９】
ｉ個の多次元データ項目の参照シーケンスに対するｊ個の多次元データ項目の照会シーケンスの位置合わせのスコアを決定する方法において、
ｉ×ｊ行列を構成するステップと、
照会シーケンスメンバ（ｊ）の間の各遷移および各参照メンバ（ｉ）にスコアを割り当てるためにスコア決定関数を使用するステップであって、前記スコア決定関数は、
Ｓ（ｉ，ｊ）＝ｍａｘ（ＳＤＶ，ＳＤＨ，Ｓｍ，０）
であり、ここで、
ＳＤＶ＝Ｓ（ｉ−１，ｊ）−ＤＶ
ＳＤＨ＝Ｓ（ｉ，ｊ−１）−ＤＨ
Ｓｍ＝Ｓ（ｉ−１，ｊ−１）＋Ｔ
であり、ＤＶおよびＤＨは、削除コスト要因であり、Ｔは、遷移関数である
ステップと、
行列セル（ｉ，ｊ）内に各スコアＳｉ，ｊを取り込むステップと、
前記行列にまたがる最適な移動経路を識別するステップであって、
前記行列の最下行内で最高のセルスコアを選択するステップと、
前記行列にまたがって逆方向にそのセルにつながる前記遷移をトレースするステップと
を含むステップと
を含む方法。
【請求項２０】
多次元データ項目の参照シーケンスに多次元データ項目の照会シーケンスを突き合わせる方法において、
選択された参照シーケンスに前記照会シーケンスを位置合わせするステップであって、
ｉ×ｊ行列を構成するステップと、
照会シーケンスメンバ（ｊ）の間の各遷移および各参照メンバ（ｉ）にスコアを割り当てるためにスコア決定関数を使用するステップであって、前記スコア決定関数は、
Ｓ（ｉ，ｊ）＝ｍａｘ（ＳＤＶ，ＳＤＨ，Ｓｍ，０）
であり、ここで、
ＳＤＶ＝Ｓ（ｉ−１，ｊ）−ＤＶ
ＳＤＨ＝Ｓ（ｉ，ｊ−１）−ＤＶ
Ｓｍ＝Ｓ（ｉ−１，ｊ−１）＋Ｔ
であり、ＤＶおよびＤＨは、削除コスト要因であり、Ｔは、遷移関数である
ステップと、
行列セル（ｉ，ｊ）内に各スコアＳｉ，ｊを取り込むステップと、
前記行列にまたがる最適な移動経路を識別するステップであって、
前記行列の最下行内で最高のセルスコアを選択するステップと、
前記行列にまたがって逆方向にそのセルにつながる前記遷移をトレースするステップと
を含むステップと
を含むステップ
を含む方法。
【請求項２１】
履歴要因に基づいて再計算することによって前記最適な経路をテストするステップと、
前記行列に関する最大の可能なスコアを計算するステップと、
前記再計算された最適な移動経路によって達成される前記最大の可能なスコアのパーセンテージとして前記行列スコアを正規化するステップと
参照シーケンスごとに前記位置合わせを繰り返すステップと、
前記最高のセルスコアを選択することによって最良の合致を判定するステップと
をさらに含む、請求項２０に記載の方法。
【請求項２２】
前記スコア決定関数は、
Ｓ（ｉ，ｊ）＝ｍａｘ（ＳＤＶ，ＳＤＨ，Ｓｍ，ＳＨＣ，ＳＶＣ，０）
であり、ここで、
ＳＤＶ＝Ｓ（ｉ−１，ｊ）−ＤＶ
ＳＤＨ＝Ｓ（ｉ，ｊ−１）−ＤＨ
Ｓｍ＝Ｓ（ｉ−１，ｊ−１）＋Ｔ；
ＳＨＣ＝ｍａｘ（ＨＯＲＩＺＯＮＴＡＬ＿ＣＯＮＳ＿ＳＣＯＲＥ（ｈ）），  ｈ＝１，２，３，…，Ｈｍａｘ
ＳＶＣ＝ｍａｘ（ＶＥＲＴＩＣＡＬ＿ＣＯＮＳ＿ＳＣＯＲＥ（ｖ）），  ｖ＝１，２，３，…Ｖｍａｘ
であり、ＤＶおよびＤＨは、削除コスト要因であり、Ｔは、遷移関数である
請求項２１に記載の方法。
【請求項２３】
前記遷移関数は、
Ｔ＝ｗ（１）＊ＳＴ（１）＋ｗ（２）＊ＳＴ（２）＋…
であり、ここで、ＳＴ（ｋ）は、前記セル（ｉ，ｊ）と、次元ｋでヌル値を有しない、前記セル（ｉ，ｊ）につながる経路上の最も最近突き合わされたセルとの間の次元ｋでの遷移のスコアであり、ｗ（ｋ）は、そのような遷移に関する所望の重みである
請求項２２に記載の方法。
【請求項２４】
音楽参照タグから導出された多次元データ項目の参照シーケンスに、音楽照会タグから導出された多次元データ項目の照会シーケンスを突き合わせる方法において、
選択された参照シーケンスに前記照会シーケンスを位置合わせするステップであって、
ｉ×ｊ行列を構成するステップと、
照会シーケンスメンバ（ｊ）の間の各遷移および各参照メンバ（ｉ）にスコアを割り当てるためにスコア決定関数を使用するステップであって、前記スコア決定関数は、
Ｓ（ｉ，ｊ）＝ｍａｘ（ＳＤＶ，ＳＤＨ，Ｓｍ，０）
であり、ここで、
ＳＤＶ＝Ｓ（ｉ−１，ｊ）−ＤＶ
ＳＤＨ＝Ｓ（ｉ，ｊ−１）−ＤＨ
Ｓｍ＝Ｓ（ｉ−１，ｊ−１）＋Ｔ
であり、ＤＶおよびＤＨは、削除コスト要因であり、Ｔは、遷移関数である
ステップと、
行列セル（ｉ，ｊ）内に各スコアＳｉ，ｊを取り込むステップと、
前記行列にまたがる最適な移動経路を識別するステップであって、
前記行列の最下行内で最高のセルスコアを選択するステップと、
前記行列にまたがって逆方向にそのセルにつながる前記遷移をトレースするステップと
を含むステップと
を含むステップ
を含む方法。
【請求項２５】
履歴要因に基づいて再計算することによって前記最適な経路をテストするステップと、
前記行列に関する最大の可能なスコアを計算するステップと、
前記再計算された最適な移動経路によって達成される前記最大の可能なスコアのパーセンテージとして前記行列スコアを正規化するステップと
参照シーケンスごとに前記位置合わせを繰り返すステップと、
前記最高のセルスコアを選択することによって最良の合致を判定するステップと
をさらに含む、請求項２４に記載の方法。
【請求項２６】
前記スコア決定関数は、
Ｓ（ｉ，ｊ）＝ｍａｘ（ＳＤＶ，ＳＤＨ，Ｓｍ，ＳＨＣ，ＳＶＣ，０）
であり、ここで、
ＳＤＶ＝Ｓ（ｉ−１，ｊ）−ＤＶ
ＳＤＨ＝Ｓ（ｉ，ｊ−１）−ＤＨ
Ｓｍ＝Ｓ（ｉ−１，ｊ−１）＋Ｔ；
ＳＨＣ＝ｍａｘ（ＨＯＲＩＺＯＮＴＡＬ＿ＣＯＮＳ＿ＳＣＯＲＥ（ｈ）），  ｈ＝１，２，３，…，Ｈｍａｘ
ＳＶＣ＝ｍａｘ（ＶＥＲＴＩＣＡＬ＿ＣＯＮＳ＿ＳＣＯＲＥ（ｖ）），  ｖ＝１，２，３，…Ｖｍａｘ
であり、ＤＶおよびＤＨは、削除コスト要因であり、Ｔは、遷移関数である
請求項２４に記載の方法。
【請求項２７】
前記遷移関数は、
Ｔ＝ｗ（１）＊ＳＴ（１）＋ｗ（２）＊ＳＴ（２）＋…
であり、ここで、ＳＴ（ｋ）は、次元ｋでの遷移のスコアであり、ｗ（ｋ）は、そのような遷移に関する所望の重みである
請求項２４に記載の方法。
【請求項２８】
前記多次元データ項目は、少なくともピッチおよび持続時間に関連する次元を含む、請求項２４に記載の方法。
【請求項２９】
前記音楽タグ内の休止に関係する、ピッチに関連するデータ項目は、未定義の値を有し、スコア決定関数は、スコアを計算する際にその値を使用するのではなく、前の合致する値を使用し、前記前の合致する値は、その目的で前方に伝搬される、請求項２８に記載の方法。
【請求項３０】
音楽アイテムおよびそのようなファイルに関連するキーファイルを含むデータベースから音楽のアイテムを検索する方法において、前記キーファイルは、少なくとも選択されたフォーマットの音符のピッチおよび持続時間の情報を含むそのような音楽に関する識別値のシーケンスからなり、
ユーザからオーディオ照会を取り込むステップと、
前記選択されたフォーマットで、前記オーディオ入力照会に関連する照会キーを生成するために前記オーディオ照会を処理するステップと、
前記照会キーを参照キーと突き合わせるステップであって、
照会ファイルへの最良の合致を識別するために、照会ファイルおよび各参照ファイルに対する反復ストリング位置合わせ動作を実行するステップ
を含むステップと、
前記合致する参照ファイルに関連する前記音楽アイテムを検索するステップと
を含む方法。
【請求項３１】
前記反復ストリング位置合わせは、
選択された参照シーケンスに前記照会シーケンスを位置合わせするステップであって、
ｉ×ｊ行列を構成するステップと、
照会シーケンスメンバ（ｊ）の間の各遷移および各参照メンバ（ｉ）にスコアを割り当てるためにスコア決定関数を使用するステップであって、前記スコア決定関数は、
Ｓ（ｉ，ｊ）＝ｍａｘ（ＳＤＶ，ＳＤＨ，Ｓｍ，０）
であり、ここで、
ＳＤＶ＝Ｓ（ｉ−１，ｊ）−ＤＶ
ＳＤＨ＝Ｓ（ｉ，ｊ−１）−ＤＨ
Ｓｍ＝Ｓ（ｉ−１，ｊ−１）＋Ｔ
であり、ＤＶおよびＤＨは、削除コスト要因であり、Ｔは、遷移関数である
ステップと、
行列セル（ｉ，ｊ）内に各スコアＳｉ，ｊを取り込むステップと、
前記行列にまたがる最適な移動経路を識別するステップであって、
前記行列の最下行内で最高のセルスコアを選択するステップと、
前記行列にまたがって逆方向にそのセルにつながる前記遷移をトレースするステップと
を含むステップと
を含むステップ
を含む、請求項３０に記載の方法。
【請求項３２】
履歴要因に基づいて再計算することによって前記な経路をテストするステップと、
前記行列に関する最大の可能なスコアを計算するステップと、
前記再計算された最適な移動経路によって達成される前記最大の可能なスコアのパーセンテージとして前記行列スコアを正規化するステップと
参照シーケンスごとに前記位置合わせを繰り返すステップと、
前記最高のセルスコアを選択することによって最良の合致を判定するステップと
をさらに含む、請求項３１に記載の方法。
【請求項３３】
前記スコア決定関数は、
Ｓ（ｉ，ｊ）＝ｍａｘ（ＳＤＶ，ＳＤＨ，Ｓｍ，ＳＨＣ，ＳＶＣ，０）
であり、ここで、
ＳＤＶ＝Ｓ（ｉ−１，ｊ）−ＤＶ
ＳＤＨ＝Ｓ（ｉ，ｊ−１）−ＤＨ
Ｓｍ＝Ｓ（ｉ−１，ｊ−１）＋Ｔ；
ＳＨＣ＝ｍａｘ（ＨＯＲＩＺＯＮＴＡＬ＿ＣＯＮＳ＿ＳＣＯＲＥ（ｈ）），  ｈ＝１，２，３，…，Ｈｍａｘ
ＳＶＣ＝ｍａｘ（ＶＥＲＴＩＣＡＬ＿ＣＯＮＳ＿ＳＣＯＲＥ（ｖ）），  ｖ＝１，２，３，…Ｖｍａｘ
であり、ＤＶおよびＤＨは、削除コスト要因であり、Ｔは、遷移関数である
請求項３１に記載の方法。
【請求項３４】
前記遷移関数は、
Ｔ＝ｗ（１）＊ＳＴ（１）＋ｗ（２）＊ＳＴ（２）＋…
であり、ここで、ＳＴ（ｋ）は、次元ｋでの遷移のスコアであり、ｗ（ｋ）は、そのような遷移に関する所望の重みである
請求項３１に記載の方法。
【請求項３５】
前記多次元データ項目は、少なくともピッチおよび持続時間に関連する次元を含む、請求項３０に記載の方法。
【請求項３６】
前記音楽タグ内の休止に関係する、ピッチに関連するデータ項目は、未定義の値を有し、スコア決定関数は、スコアを計算する際にその値を使用するのではなく、前の合致する値を使用し、前記前の合致する値は、その目的で前方に伝搬される、請求項３５に記載の方法。
【請求項３７】
音楽タグを表すデータ構造であって、
音楽データ部分であって、
音楽ファイル記憶フォーマットでエンコードされた、音楽アイテムの録音である、タグ部分と、
前記タグ部分から導出された識別データを含む、キー部分と
を含む音楽データ部分と、
前記音楽アイテムに関係するデータ項目を含むメタデータ部分と
を含むデータ構造。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、それだけには限らないが特に音楽ファイルおよびマルチメディアファイルに関する探索可能（ｓｅａｒｃｈａｂｌｅ）参照データベース（ｒｅｆｅｒｅｎｃｅ  ｄａｔａｂａｓｅ）を作成するシステムおよび方法に関する。詳細には、本発明は、非テキストベースの検索（ｒｅｔｒｉｅｖａｌ）システムを使用して、記憶された音楽を検索することに関する。
【背景技術】
【０００２】
データベース内で維持され記憶される音楽の集まりは、商業分野の共通する特徴になってきた。しかし、そのようなデータベース内で音楽を見つけることが問題となる可能性がある。明確な問題は、音楽データベースによって提供される探索方法がもたらす難点である。一般に、ユーザは、「曲名」または「演奏者」など、一般的に規定された、または特定の探索フィールドに入力されるテキスト入力から開始しなければならない。しかし、ユーザは、曲の正確な名前を覚えていない場合があり、演奏者、グループ、または作曲者の名前すら覚えていない場合がある。この場合、たとえばエンゲルベルト＝フンパーディングが様々な姿で現れて非常に混乱し得るだけではなく、名前を思い出すことができる場合であっても、綴りが問題になり得る。テキストベースの音楽探索によく見られるこの要件は、そのような問題を当技術分野固有のものにしている。
【０００３】
さらに、テキストから出発した後で、当技術分野では、ある曲の主たる主旋律を聞く機会をユーザに提供することに成功していない。本明細書で使用される主旋律は、聞く人がある曲の主要な部分と考えるはずの、メロディ、リズム、およびおそらくは歌詞の組合せを指す。当技術分野では、ある曲のオリジナルの楽譜および歌詞にアクセスできる場合であっても、そのような作業が困難となる。主旋律を楽譜から自動的に抽出し、歌詞からの単語に結び付けることは、不可能ではないとしても困難である。信号処理手法および人工知能手法を使用して、ある歌のデジタルフォーマットからその歌の主なメロディを抽出するいくつかの試みがあった。これらの手法は、特に複数の楽器が同時に演奏されることを伴う音楽でうまくいかなかった。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
したがって、非テキストベースの検索方法に基づいて、記憶された音楽を検索する改善された方法およびシステムを提供する機会が生じる。
【課題を解決するための手段】
【０００５】
本発明の一態様は、記憶された音楽の選択されたアイテムを非テキストベースで識別する方法である。本方法の第１の広範な部分は、音楽識別データベースを構築するステップに焦点を合わせたものである。そのプロセスは、選択された音楽アイテムのタグを取り込むステップと、タグへの参照キーを開発するためにタグを処理するステップとを必要とする。次いで、参照キーおよび記憶された音楽への関連と共にタグを記憶する。データベースは、複数のタグを収集することによって構築される。本方法の第２の広範な部分は、データベースから記憶された音楽の所望のアイテムを検索するステップである。そのプロセスは、ユーザから照会タグを取り込むステップと、照会タグへの照会キーを開発するために照会タグを処理するステップとを必要とする。記憶された音楽の所望のアイテムを識別するために、照会キーをデータベースに記憶された参照キーと比較する。
【発明を実施するための最良の形態】
【０００６】
以下、図面を参照して詳細に説明する。好ましい実施形態は、本発明の範囲を限定するためではなく、本発明を例示するために説明され、本発明の範囲は、添付の特許請求の範囲のみによって定義される。当業者は、以下の説明に基づく様々な均等の変形形態を理解するであろう。
【０００７】
前述の一般的な説明と以下の詳細な説明は共に、例示的なもの、説明的なものにすぎず、特許請求される本発明について限定的ではないことを理解されたい。以下の考察では、類似の符号が、類似の要素を指す。
【０００８】
一般に、本発明について、２つの広範な、接続された部分で想像することができる。第１に、非テキストベースの構造を中心として構築される、記憶された音楽のデータベースを用意しなければならない。次いで、非テキストベースの探索機構および検索機構を利用して、所望の音楽アイテムを検索することができる。その全体の第１の半分が、図１および付随する考察に概して示され、第２の半分が、図２に示されている。
【０００９】
音楽タグ付け
図１は、非テキストベースの音楽データベースを構築するプロセス１００を示す。当業者なら、そのようなデータベースには複数の可能な応用分野があることを理解するであろう。一実施形態では、このデータベースは、書籍、電子デバイス、および他の製品ならびに音楽を販売するウェブベースの総合販売活動など、大会社の音楽販売部分をサポートする。他の実施形態は、このデータベースをミュージックストアに置かれたキオスク内で使用し、買物客が所望の音楽を識別することを可能にする。そのようなどちらの場合にも、音楽探索システムは、ある種のショッピングエンジンにデータを供給する。別法では、このデータベースは、独立型ウェブサイトの主ドライバとすることができ、その例を、本明細書で示す。当業者は、図の例を他の環境および他の応用分野に適合させる技量を有する。重要なそのような応用分野は、本発明の方法を携帯電話機環境に適合させることができ、この携帯電話機環境では、キーパッドが小さいことにより、タイピングではなく歌うことによって音楽の選択を示すことができることが強く奨励される。
【００１０】
このデータベースの基礎になる重要な概念は、このデータベースが、音楽アイテムの主旋律を人間が知覚したものについて人間が演奏したものを含むことである。したがって、このデータベースは、オリジナルの音楽アイテムを含まず、これらのアイテムの参照部分さえ含まない。このデータベースは、本明細書で「タグ」と呼ばれるもの、すなわち下記に示すように、直接的または間接的に人間によって演奏される音楽主旋律を記録する、概して短い演奏（長さが数分ではなく数十秒）のオーディオファイルを含む。用語「タグ」は、以下ではそのような演奏を表すのに使用される。
【００１１】
人間に由来する音楽の標本のグループが存在することにより、従来技術を制限するその重要な問題、すなわち複雑なオーディオファイルから音楽主旋律の単純なバージョンを抽出するという要件が完全に回避されることに留意されたい。この場合、参照サンプルは、単純で簡単な産物であるだけではなく、コンピュータ構築物ではなく人間の産物でもある。照会する人間の知覚は、コンピュータプログラムの知覚よりもタグ付けする人の人間の知覚にはるかによく合致する可能性がより高い。その結果、探索プロセス全体を容易にするデータのセットが得られる。
【００１２】
ラジオボタン、メニュー選択など、従来の方法による「音楽追加」機能を開始した後で、ユーザは、タグを、音声入力モードで入力するか、それとも間接入力モードまたは記符入力モードで入力するかを選択しなければならない。前者を選択すると、ユーザは、音楽主旋律についてそのユーザが知覚したものを音声表現することを必要とする。この音声表現は、歌うこと、ハミング、口笛を吹くことなど、ユーザが好む任意の形態をとることができる。唯一の要件は、入力がオーディオ信号であることである。その要件は、マイクロホンなどのオーディオ入力デバイスを必要とするが、そのようなデバイスの性質および品質は、ユーザに委ねることができる。ユーザは、探索要求を入力するのではなく、アイテムをデータベースに入力しているので、その曲の名前を与えなければならない。さらに、ユーザは、ある曲の特定の演奏が暗示されていることを示すために、または単純に将来の探索者に、より多くの情報を与えるために、演奏者名を与えることができる。一実施形態では、ユーザによって与えられるテキスト情報は、知的妥当性検査ルーチンにかけられ、この知的妥当性検査ルーチンは、可能な限り明瞭なデータを保証するために、綴りの誤りなどを探す。そのルーチンは、たとえば、エアロスミスがバッハのカンタータを録音していると自信があるかどうか、そのユーザに照会できるように、文脈を検査するように拡張することができる。
【００１３】
ユーザが音声入力を選択する場合に、このシステムは、図２に示されたものなどのグラフィカルインターフェースを提供することができる。ここで、画面１４０は、ユーザによって与えられたテキスト情報をエコーすると同時に、録音コントロールを提供する。この画面は、インターネット上とインターネット外の両方で、録音デバイス内で広く使用されている典型的なコントロールを示し、これらのコントロールは、変更し、または提示することができ、しかし特定の実施形態の必要に最もふさわしい。
【００１４】
音声入力は、ＷＡＶ、ＭＰ３、ＷＭＡなど、音楽素材を処理するための既知のフォーマットのいずれかで取り込み、保存することができる。異なるファイルフォーマットは、下記に示す処理システムの適合を必要とするが、そのような適合は、十分に当業者の水準内にある。
【００１５】
別法として、ユーザは、図３に示された音楽入力インターフェース１５０などのインターフェースを使用して、非オーディオ入力を選択することができる。このインターフェースは、ユーザが、直接に音符を使用して主旋律を入力することを可能にする。譜表１５２が設けられ、この場合には高音部記号および低音部記号を有するピアノスタイルでセットアップされ、ドラッグアンドドロップエリア１５４は、様々な時価の音、シャープ記号、フラット記号、および様々な値の休符を提供する。ユーザは、記号を譜表にドラッグアンドドロップして、主旋律を作成することができる。さらに、キーボード１５６も設けられ、このキーボード１５６は、ユーザがキーをクリックし、音を譜表に表示させることを可能にする。音符を入力する複数の技法が、当技術分野で既知であり、当業者は、そのような技法を選択し、本明細書で特許請求される発明を用いる特定の応用例の必要に適合させることができるであろう。
【００１６】
非常に有用な入力方法は、ユーザがキーボードまたは他の楽器ＭＩＤＩデバイスで主旋律を演奏することによって主旋律を入力できるようにする、ＭＩＤＩインターフェースであろう。当業者なら、ＭＩＤＩによって生成されたファイルを、本システムで好ましいとされるフォーマットに変換する最も有効な方法を理解するであろう。
【００１７】
記符入力は、上記で指摘したように、音楽フォーマット、好ましくは、上記で指摘したようにオーディオ素材を扱うために選択されたフォーマットに変換される。
【００１８】
このシステムは、この時点で、人間が再生し聞くことのできるファイルを有するが、音楽アイテムを突き合わせるためには比較的役に立たないツールである。ファイル内容の合致という問題さえ超えている。当技術分野は、マッチングアルゴリズムを適用できる点に達するために信号処理が必要であることが明らかである。当技術分野は、複数の解決策を提供してきたが、本発明までは、どの方法も適切な結果を提供しなかった。
【００１９】
図４は、マッチングアルゴリズムへの入力を生成するプロセスの実施形態２００を示す。このプロセスは、タグ内容を処理して、以下で「キー」ファイルと称するデータ構造など、マッチングアルゴリズムによるさらなる動作に適切なデータ構造を生成することからなる。
【００２０】
さらに、音楽検索システムが、ユーザの入力によって突き合わされることになる、事前に録音された音楽ファイルを使用できることを理解されたい。そのようなファイルは、既存の音楽録音、既存の音楽録音からの抜粋、またはそのような音楽の特別に録音されたバージョンからの抜粋からなるものとすることができる。参照音楽を提供する上記または他の方法のいずれについても、キーファイルへのオーディオファイルの処理は、下記に示すように進行する。
【００２１】
最初に、オーディオファイルは、２５ｍｓなどの適切な作業長さのフレームに分割される。この方法それ自体の説明から理解されるように、この実施形態では信号レベルの間に境界が設定され、オーディオファイルが、接するフレームに分割されるのではなく、隣接フレームの間に重ね合わせが設けられること。そのような重ね合わせ量が、フレーム長の約５０％になることが好ましい。
【００２２】
ステップ２０４〜２１２は、デジタル化されたオーディオ信号から開始し、音符値のシーケンスを導出することを目指す、各フレームに順番に適用されるプロセスを示す。ステップ２０４での最初のアクションは、ピッチ曲線（ｐｉｔｃｈ  ｃｏｎｔｏｕｒ）を検出することである。この結果を得るために、複数の技法が当技術分野で既知である。様々な実施形態は、自己相関ピッチトラッキング、平均振幅差関数（ＡＭＤＦ）解析、またはハーモニックグルーピング（ｈａｒｍｏｎｉｃ  ｇｒｏｕｐｉｎｇ）を使用するピッチトラッカを利用する。上記または既知の方法のどれでも、１フレームあたり１ピッチ値を有するピッチ値のベクトルからなる出力を生成するのに使用することができる。したがって、この出力は、経時的なピッチ値のトラックに対応する。
【００２３】
次に、ステップ２０６で、休止（無音の期間）を識別する。これは、複数の既知の方法によって達成することができる。一実施形態は、音声エネルギーの生の値または対数値のいずれかに基づくエネルギーヒストグラムを使用する。次いで、複数のモードが存在すると判定される場合に、このシステムは、音声（境界より大きい値）と無音（境界より小さい値）との間の境界を定義する「無音閾値」を動的に計算する。
【００２４】
音声が存在する期間を考慮して、ステップ２０８で、音の間の境界の位置を判定する。一実施形態は、エネルギーレベルおよびピッチ値を解析し、いずれかの要因が選択された閾値より大きく変化する点に焦点を絞る。他の実施形態は、連続するフレームの間の相互相関を調べる。上記および当業者に既知の他の技法は、ある音が別の音に変化する時価を生成する。
【００２５】
隣接する音変化点間のピッチ値が、変化する可能性が最も高いことを理解されたい。実際には、音のスラー効果およびレガート効果により、人間の演奏が純音の連続からなるのではないことは確実である。しかし、オーディオファイルを一連の音に変換することは、音ごとに、固定されたピッチ値が選択されることを必要とする。したがって、ステップ２１０で、単一のピッチ値を各音期間に割り当てる。一実施形態は、音境界の間のピッチ曲線の算術平均を利用する。他の実施形態は、幾何平均を使用する。当技術分野で既知の他の技法を使用することができる。
【００２６】
最後に、音ピッチ値を量子化する、すなわち、事前定義された値を有する音符に対応するように音ピッチ値を設定する。特定の音を、ステップ２１２で選択して、量子化の差分誤差（ｄｉｆｆｅｒｅｎｃｅ  ｅｒｒｏｒ）を最小にする。本方法は、音程の任意の所与の系を処理することができ、その系での結果を生成することができることに留意されたい。西洋音楽については、半音系（ｓｅｍｉｔｏｎｅ  ｓｙｓｔｅｍ）が、最も一般的に使用されるが、本システムは、単に異なる量子化テーブルを選択することによって、様々な他の調律系（ｔｕｎｉｎｇ  ｓｙｓｔｅｍ）と共に等しく機能することができる。同様に、等分平均律とウェルテンペラメントとの両方を提供することができる。
【００２７】
その結果、フレームごとに、多次元ベクトルのシーケンスが得られ、値は、少なくともピッチおよび持続時間を表す。他の実施形態は、音量、アタック、および他の音楽的特性、ならびに音声学的要因を考慮に入れて、追加の次元を使用することができる。
【００２８】
ステップ２１４では、すべてのフレームを処理し終えたかどうかを判定し、それが達成されるまでステップ２０４〜２１２を通ってループして戻る。処理が完了したとき、フレームの間の重ね合わせの量を考慮に入れて、キーがフレーム結果から組み立てられる。
【００２９】
この点までに、このシステムは、データおよびメタデータを収集し終えている。データ項目には、オーディオタグおよびキーが含まれる。メタデータは、曲、演奏者などの名前などアイテムメタデータと、ユーザの名前、およびいくつかの実施形態においては他の識別用データなどユーザメタデータと、入力時刻またはアプリケーションの動作に有用な他の情報などシステムメタデータといった、いくつかのタイプのものである。システムは、この点で、図５に示されたものなどのデータレコードを構築することができる。この図では、データレコード１６０は、データ項目１６２およびメタデータ１６４からなる。前者のカテゴリには、オーディオタグ１６５およびキー１６６が含まれ、後者には、アイテムメタデータ１６７、ユーザメタデータ１６８、およびシステムメタデータ１６９が含まれる。
【００３０】
データベースシステムそれ自体のさらなる詳細は、当業者に委ねることができる。図示の実施形態および類似の構造をサポートするのに十分な、典型的なデータベースアプリケーションは、Ｏｒａｃｌｅ  Ｃｏｒｐ．、Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐ．などによって供給されている。本明細書で示すデータ構造を与えられれば、当業者は、必要なデータベースアプリケーションを構築し、サポートすることができるであろう。
【００３１】
留意しなければならない点は、本システムが、迅速な探索結果を実現するためにデータインデックスの使用を必要としないことである。このシステムは、膨大なスケールであっても、インデクシングシステムを一切用いずに、キーファイルを使用する直接検索動作を実現することができる。ある点で、インデクシング方法を導入することが望ましい場合があるが、そのステップは、本明細書で開示され特許請求されるシステムの動作に必要ではない。
【００３２】
考察中のアプリケーション実施形態は、確実に広く網羅するために、タグのかなり大きなデータベースを蓄積しなければならない。さらに、良い品質のタグが確実に存在するように、可能な曲ごとに複数のタグを収集することが有利になる。量に関する第１の問題は、タグを入力するようにユーザを誘導することを目指す、複数の奨励プランを構築することによって対処することができる。１つの方法は、ユーザが、入力されたすべてのタグについて規定された金額の報酬を受け取る、単純な支払プランとすることができる。この方法は単純であるが、入力の質を高める動機にならない。このシステムが音楽データベースを操作するだけではなく音楽演奏の販売も行う応用環境では、好ましい方法は、下記で詳細に説明するように、第１のユーザによって入力されたタグに基づいて別のユーザが音楽アイテムを購入するたびに、第１のユーザが報酬を受ける手数料モデルであろう。複数のタグ、特に複数の高品質タグを入力するユーザは、ウェブサイトの適切なページで、「強力なタグ付け者（ｐｏｗｅｒ  ｔａｇｇｅｒ）」などとして識別されることによって、認められることができる。複数の奨励プランが可能であり、ユーザは、異なる状況で、ある範囲の奨励プランを使用する可能性が高い。
【００３３】
従来の種類の報酬方式に加えて、システムオペレータは、着信音としての携帯電話機にダウンロードするためにタグを提供することによってなど、収入源としてタグを活用することができる。そのような提供は、金銭の支払に基づくものとすることができ、あるいは、着信音を、奨励プランに組み込むことができる。さらに、主旋律の提供は、最初のタグ付けする人に、その人のタグがダウンロードされるたびに支払または他のクレジットを与えることによって、さらに促進される可能性がある。他の収入の機会を、当業者は思い浮かべるであろうが、それらのすべてが、本明細書に添付の特許請求の範囲に含まれる。
【００３４】
良質の提出という問題は、別個の問題ではあるが、同様に重要な問題である。音楽をあまりうまく演奏できない複数の人がおり、そのような人がタグを入力する場合、そのタグは、実際の音楽アイテムにあまり似ていない可能性がある。したがって、「数小節をハミング」しようと試みる後続のユーザが、その曲のより優れた演奏を提出する可能性があるが、このサンプルに基づけば、正しい結果は返されない。
【００３５】
考察中の実施形態で採用された、その問題に対する１つの可能な解決策を、図６に示す。この図では、ユーザは、既存のタグを聞き、演奏の質に投票する機会を与えられる。ここで表示されるウェブページは、投票するユーザに、関係するメタデータ（タグ付けした人の名前、アイテム情報など）を見て、そのタグの品質に関して、１０個の星システムを使用して投票する機会を与える。投票は、このシステムがタグの間で区別し、主旋律を最もよく模しているタグおよびそうでないタグを識別することを可能にする。タグ入力それ自体に関して、システムオペレータは、少なくとも任意の所与のシステムの履歴の初期に、投票するようにユーザに奨励することを望む可能性が高い。データ検索における投票情報の使用は、下記で扱う。投票情報は、様々な実施形態で示される複数の形で、基本的なデータベースシステムに組み込むことができる。図の実施形態で従っている１つの方法は、票を提供するユーザへのさらなるリンクと共に、投票結果テーブルを基本タグテーブルに単にリンクすることである。当業者は、この作業を実行する、同等に有効な他の手段を考案するであろう。
【００３６】
初期のシステムオペレータは、後で独立型製品として他者に販売できるタグデータベースを開発できることに留意されたい。したがって、たとえば、ウェブベース企業は、かなり大きなユーザコミュニティを開発し、大規模な、有用なタグデータベースを生成することができる。ミュージックストアがそのようなデータベースを開発できる可能性は低く、したがって、そのデータベース自体に関する市場が存在し得る。これは、このシステムの構築部分および検索部分が独立に動作できるという事実をさらに示すものである。ある企業は、そのようなデータベースを開発しマーケティングすることだけからなる事業を行えることを、容易に想像することができる。他の会社は、構築ステップを一切行わず、探索を実行するのに既存データベースを使用するだけの形で、同様に機能することができる。
【００３７】
シーケンスの突合せおよびスコア決定
タグデータベースを構成し終えたので、このシステムは、図７に示されているように、記憶された音楽を検索する準備ができている。音楽検索における最初のユーザステップ２５２は、「照会タグ」を入力すること、すなわちデータベースタグを作るために、正確に上記で示したステップを実行することである。以下では、データベース内のタグおよびそれらに関連するキーを、「参照」タグおよび「参照」キーと称する。このシステムの一実施形態では、ユーザは、タグ作成に関して行われたのと同様に、直接的または間接的に（記符を使用して）「照会タグ」を入力することができる。どの場合でも、このステップの結果、タグと同じ構造を有する照会が作成される。
【００３８】
次に、ステップ２５４で、上述のものとまったく同じ手順を使用することによって、照会タグを使用して、照会キーを生成する。便宜上、下の考察では、用語「照会」および「参照」を使用し、それぞれ照会キーおよび参照キーを指す。
【００３９】
一般に、続くステップ２５６〜２６６では、各照会を対話式で取り出し、下記に示すようにこれを解析し、次いで、解析を比較することによって、照会に対する最良の合致を見つける。これらの解析は、参照シーケンスまたはむしろ参照シーケンスの部分が照会シーケンスに合致する度合を数値スコアで表すこと、また、次いで、そのスコアに従ってその合致の品質をランク付けすることを目指すものである。
【００４０】
ステップ２５６の取出動作は、従来のように進行する。インデクシングシステムは適用されないが、上述のようにユーザによるランク付けが得られている場合、これらのランク付けを使用して、参照をグループ化することができ、その結果、より高いランクを有する参照が、より低いランクを有する参照の前に取り出されるようになる。一実施形態は、別の曲に進む前に、ランク順で、所与の曲のすべての標本（メタデータによって識別される）を取り出すことによって進行する。他の実施形態は、ランク順で参照を取り出し、その結果、照会は、まず、すべての高品質の参照に対して実行され、もっぱらその後で、より低いランクを有する参照に対して実行されるようになる。そのような構成は、システムオペレータの判断に委ねられる。
【００４１】
照会と参照との間の最良の合致は、探索照会とデータベース内の参照とを比較することによって判定される。これは、概して見出し「ストリング位置合わせ」の下に含まれる、いくつかの方法で行うことができる。「距離」法、Ｎｅｅｄｌｅｍａｎ−Ｗｕｎｓｃｈアルゴリズム、またはいわゆる巡回セールスマン問題および他の方法など、いくつかのそのような方法が、当技術分野で既知である。本明細書で詳細に述べられ、特許請求される一実施形態は、動的計画法から導出された技法である、動的遷移マッチング（Ｄｙｎａｍｉｃ  Ｔｒａｎｓｉｔｉｏｎ  Ｍａｔｃｈｉｎｇ、ＤＴＭ）と称する位置合わせプロセスを使用する。図７では、この方法が流れ図の形でプロセス２５０として図示されている。ＤＴＭは、イベントそれ自体ではなくイベントの間の遷移を解析し、量子化し、次いで、突き合わせることによって、イベントのシーケンスを突き合わせる包括的プロセスである。これらのシーケンス（「ノード」）は、潜在的に多次元であり、それらのノードのすべての次元が異なる座標系にある可能性があるので、これらのシーケンスは、完全に異なる可能性がある。しかし、ノードの次元の間の遷移は、この技法が各次元について正しく定義される（たとえば、差、比など）場合、座標系に関わりなく突き合わせることができる。したがって、ＤＴＭは、複数の次元と、異なる次元についての遷移の複数の定義とを有する、様々な応用例に適用可能な包括的で強力な技法を表す。この提示を単純にするために、本考察では、例を、図の実施形態のメロディマッチング応用例に制限する。ここで、用語「ノード」および「音」は、交換可能に使用される。当業者なら、他の分野および学問分野へのこの技法の広範な適用可能性を理解するであろう。
【００４２】
このプロセスのこの点で、この実施形態は、２次元シーケンスの形で照会および参照を有する。このシーケンス内の各音は、ピッチ値および持続時間値のベクトルである。他の実施形態は、望むなら、音声学的内容および他の情報を含むことができる。
【００４３】
参照シーケンスを、（ｒ１，ｄ１）、（ｒ２，ｄ２）、…、（ｒｎ，ｄｎ）と表すことができ、ここで、ｒ値は、ピッチインデックスを表し、ｄ値は、持続時間インデックスを表す。同様に、照会シーケンスを、（ｑ１，ｔ１）、（ｑ２，ｔ２、）…、（ｑｍ，ｔｍ）と表すことができる。
【００４４】
一般に、照会のサイズｍは、参照のサイズｎより小さいが、これは要件ではない。ＤＴＭは、時間スケールを正規化すること、すなわちキーと照会とのピッチスケールが同じであることを必要としない。また、たとえば、休止を除去する、または生シーケンスを遷移値のシーケンスに変換するためにシーケンスを変換する必要もなく、解析は、生データを使用して進行することができる。この技法は、照会内の２つのノード間の遷移に比べてキー内の２つのノード間の遷移を突き合わせ、したがって、動的遷移マッチングという名前になっている。この２つの遷移間の比較は、１つまたは複数の特徴を考慮に入れることができ、たとえば、諸実施形態は、望むなら、半音差、持続時間比、音声学的内容、および他のプロパティを使用することができる。
【００４５】
ＤＴＭ技法は、
照会＝（６０，１２）、（休止，６）、（６５，１２）、（７１，２）、（７２，１０）、（６７，２３）、（６５，１２）
参照＝（８９，１０）、（９０，１０）、（休止，５）、（９５，１０）、（１０２，１０）、（９７，２０）、（９５，１０）、（９０，１０）
などの２つのシーケンスで処理する。上述のように、各シーケンスメンバの値は、キー抽出プロセスによって決定される、ピッチ値および持続時間値を表す。７つのメンバを含むこの照会は、各シーケンスの最初のメンバから開始して、参照の最後のメンバを合致する音がない状態のままにするか、最後の音を突き合わせ、最初の参照音を合致されないままにすることによって、参照と位置合わせできることは明らかである。さらに、実際の音楽を処理するシステムは、スラーおよび装飾音などの現象を可能にするために、シーケンス内の複数の音を合併しなければならない可能性をも見込まなければならない。たとえば、ここでの照会シーケンスでは、メンバ４が、メンバ５と実際上同一のピッチを有し、非常に短い持続時間も有する。
【００４６】
この突合せ問題に対する解を、表１に示す。休止がどのように突き合わされるかに留意し、参照内の音（１０２，１０）と合致させるための照会内の（７１，２）と（７２，１０）の合併にも留意されたい。その結果、最初および最後の参照シーケンスメンバは、対応する照会メンバによって突き合わされない。
【００４７】
【表１】
2009516268.tif 000003
【００４８】
最適な位置合わせ解析は、下の表２など、行列またはスコアテーブルを中心として構築され、このテーブルでは、ｉ軸上のセルが、参照シーケンス内のベクトルを表し、ｊ軸上のセルが、照会のベクトルを表す。表２は、この例の照会および参照を解析するために構成されることになる完全なテーブルの例示的な部分を表す。（ｒｉ，ｄｉ）および（ｑｊ，ｔｊ）の値が示されている。
【００４９】
【表２】
2009516268.tif 000004
【００５０】
この解析は、いくつかの特徴をＮｅｅｄｌｅｍａｎ−Ｗｕｎｓｃｈアルゴリズムと共有する。主に、この解析は、左上（ｉ＝１，ｊ＝１）から右下（ｉ＝ｍａｘ，ｊ＝ｍａｘ）にかけてこの行列を走査（ｔｒａｖｅｒｓｅ）し、各列を順番に下に進み、セルごとにスコアＳ（ｉ，ｊ）を計算することによって進行する。
【００５１】
この解析の最終的な産物は、セルからセルへの最適な走査に関する、（ｉ＝１，ｊ＝１）から（ｉ＝ｍａｘ，ｊ＝ｍａｘ）への最適な経路である。Ｎｅｅｄｌｅｍａｎ−Ｗｕｎｓｃｈ法で暗黙の、移動に対する制約を与えられて、セル（ｉ，ｊ）からの走査は、３つの形で、すなわち（ｉ＋１，ｊ＋１）へ下に斜めに、（ｉ，ｊ＋１）へ垂直に、または（ｉ＋１，ｊ）へ水平に進むことだけができる。値のシーケンスの実際の突合せに関して、斜めの移動が、新しい値の対の突合せに対応することがわかる。したがって、（ｉ＝１，ｊ＝１）では、（ｒ１，ｄ１）が（ｑ１，ｔ１）に合致し、（ｉ＝２，ｊ＝２）への移動は、（ｑ２，ｔ２）への（ｒ２，ｄ２）の新しい合致を生成する。垂直移動または水平移動は、一方の軸で移動するが他方の軸では移動しない。したがって、（ｉ＝１，ｊ＝１）では、（ｒ１，ｄ１）が（ｑ１，ｔ１）と合致するが、（ｉ＝１，ｊ＝２）への垂直移動は、（ｒ１，ｄ１）を（ｑ２，ｔ２）に合致させようと試みる。明らかに、この演算が機能することができる唯一の形は、（ｑ１，ｔ１）または（ｑ２，ｔ２）の１つを削除することであり、したがって、これらの演算を、それぞれ垂直削除および水平削除と称する。
【００５２】
重要な概念は、各セルが、親セル（ｉ，ｊ）を有し、各セルのスコアが、この親セル（ｉ，ｊ）に基づくことである。親セルは、最高のスコアを生じた走査に基づいて、スコア決定プロセス中に判定される。合致について、親セルは、（ｉ−１，ｊ−１）である。垂直削除について、親は（ｉ−１，ｊ）であり、水平削除について、親は（ｉ，ｊ−１）である。
【００５３】
したがって、ステップ２６８のスコアを決定することは、親セルのスコアから開始して、テストセルに到着できる３つの可能な走査をテストすること、および可能な走査のうちのどれが最良のスコアを生成するかを判定するために適切なスコア決定関数を適用することからなる。したがって、各セルのスコア決定は、前に何があったかに大きく依存する。さらに、スコア決定システムは、これらの走査について削除コストを査定することによって、合致に報酬を与え、削除させないように構成される。一般に、スコア決定の式は、次のようになる。
Ｓ（ｉ，ｊ）＝ｍａｘ（ＳＤＶ，ＳＤＨ，Ｓｍ，０）    （式１）
ここで、
ＳＤＶ＝ＶＥＲＴＩＣＡＬ＿ＤＥＬＥＴＩＯＮ＿ＳＣＯＲＥ
ＳＤＨ＝ＨＯＲＩＺＯＮＴＡＬ＿ＤＥＬＥＴＩＯＮ＿ＳＣＯＲＥ
Ｓｍ＝ＳＵＢＳＴＩＴＵＴＩＯＮ＿ＳＣＯＲＥ（Ｍａｔｃｈ）
である。セルのスコアが、０未満になることができないことに留意されたい。
【００５４】
境界条件は、走査が実際に可能であることを保証することによって適用される。たとえば、右上角の（ｉ＝１，ｊ＝１）では、すべての種類の移動が不可能であり、したがって、唯一の頼みとなるのは、０のデフォルト値でセルのスコアを決定することである。その列の他のセルでは、垂直削除が可能であるが、合致または水平削除を行うことはできない。
【００５５】
これらの原理、すなわち３つの可能な走査に関するスコア決定を適用して、スコアは、次のように計算される。
ＳＤＶ＝Ｓ（ｉ−１，ｊ）−ＤＶ
ＳＤＨ＝Ｓ（ｉ，ｊ−１）−ＤＨ
Ｓｍ＝Ｓ（ｉ−１，ｊ−１）＋Ｔ
ここで、ＤＶおよびＤＨは、削除コスト要因であり、Ｔは、遷移関数である。
【００５６】
遷移関数は、（ｉ−１，ｊ−１）から（ｉ  ｊ）への移動の値である。当業者は、ＤＴＭ技法が適用される特定の応用例に適切な遷移関数を判定することができる。本明細書で示される音楽探索応用例について、Ｔは、各次元の差の絶対値の加重組合せであり、この次元は、この示されている例では、ピッチと持続時間の対数とである。その原理の変更を、下記に示す。
【００５７】
上記で指摘したように、音楽応用例では、隣接する音を組み合わせることが有利である多くの状況が生じる。そのプロセスは、そのような組合せの結果を測定する要因を追加することによって、スコア決定プロセスに統合することができる。垂直合併および水平合併を解析する条件を追加することによって、結果のスコア関数は、次のようになる。
Ｓ（ｉ，ｊ）＝ｍａｘ（ＳＤ，ＳＤＨ，Ｓｍ，ＳＨＣ，ＳＶＣ，０）    （式２）
ここで、
ＳＤＶ＝ＶＥＲＴＩＣＡＬ＿ＤＥＬＥＴＩＯＮ＿ＳＣＯＲＥ
ＳＤＨ＝ＨＯＲＩＺＯＮＴＡＬ＿ＤＥＬＥＴＩＯＮ＿ＳＣＯＲＥ
Ｓｍ＝ＳＵＢＳＴＩＴＵＴＩＯＮ＿ＳＣＯＲＥ（Ｍａｔｃｈ）
ＳＨＣ＝ｍａｘ（ＨＯＲＩＺＯＮＴＡＬ＿ＣＯＮＳ＿ＳＣＯＲＥ（ｈ）），  ｈ＝１，２，３，…，Ｈｍａｘ
ＳＶＣ＝ｍａｘ（ＶＥＲＴＩＣＡＬ＿ＣＯＮＳ＿ＳＣＯＲＥ（ｖ）），  ｖ＝１，２，３，…Ｖｍａｘ
あるセルのスコアが、０未満になることができないことに留意されたい。
【００５８】
本方法のスコア決定プロセスは、従来技術の類似のアルゴリズムとは顕著に異なる。第１に、当技術分野は、休止すなわち曲内の無音の期間の問題に対処する有効な方法を開発していない。この問題は、遺伝子配列解析などの現象の解析では生じない。というのは、塩基の一部が、値を有しない遺伝子配列を有することができないからである。ここでは、休止が、「未定義の」値として扱われ、解析を進行することが可能になり、これは、下記に示すように、休止に特別な考慮を与えることをも可能にする。
【００５９】
さらに、ここでの解析が、音それ自体ではなく音の間の遷移に焦点を合わせていることを理解することが重要である。その結果、このスコア決定プロセスは、垂直方向または水平方向で前の音を削除することによるか、それとも、やはり垂直方向または水平方向で複数の前の音を組み合わせることによるか、それとも、遷移を「合致」として扱うことすなわち前の音から現在の音への単純な移動によって、最高のスコアが達成されるかどうかを判定することからなる。５つの可能な遷移のすべてが、解析され、最高のスコアを表す遷移が、保持され、そのスコアが、行列内の適切な場所で入力される。
【００６０】
スコア関数の各部分について、複数の変更および追加が可能である。次の考察では、各構成要素に詳細に焦点を合わせる。
【００６１】
ＳＤＶ＝ＶＥＲＴＩＣＡＬ＿ＤＥＬＥＴＩＯＮ＿ＳＣＯＲＥ
このスコアは、垂直削除、すなわち表２に従う照会内の音の削除から生じる。理解できるように、削除は好ましくなく、したがって、コストが査定される。垂直削除のコストがＤＶである場合には、
ＳＤＶ（ｉ，ｊ）＝Ｓ（ｉ，ｊ−１）−ＤＶ    （式３）
である。
【００６２】
削除コストは、削除される音の重要性によってさらに正規化することができる。削除される音の持続時間がｔｊである場合に、正規化された削除コストは、ＤＶ＊ｔｊ／ｍｅａｎ＿ｑとすることができ、ここで、ｍｅａｎ＿ｑは、すべての非休止ノードにまたがる照会シーケンスの持続時間の平均値である。
ＳＤＶ（ｉ，ｊ）＝Ｓ（ｉ，ｊ−１）−ＤＶ＊ｔｊ／ｍｅａｎ＿ｑ    （式４）
【００６３】
上記で指摘したように、削除は、遷移の実際の削除を意味する。しかし、遷移は、その遷移を含む２つのノードのうちの一方（ソースノードおよび宛先ノードと称する）の削除によって削除される。過去の／ソースノード（ｊ−１）または現在の／宛先ノード（ｊ）のどちらを削除しなければならないかの判断を行わなければならない。この判断は、一般に、応用例に依存する。しかし、ある音が既に別の遷移で突き合わされている場合には、その音を削除することはできない。したがって、次のルールが使用される。
ｓｃｏｒｅ（ｉ，ｊ）＞０の場合：これは、正のスコアを有する以前の合致があり、したがって、ｊ−１のノードが正の合致であったことを意味する。この場合には、（ｊ）にある新しいノードを削除する。
ｓｃｏｒｅ＝＝０の場合：この場合には、正の合致が、現在の経路で生き残っていない。したがって、ノード（ｊ−１）は、有用ではなく、削除することができる。
【００６４】
置換スコアのために、削除されたノードを追跡することが重要である。あるノードが削除されたならば、その親のプロパティが、前方に伝搬され、その結果、これらのプロパティを、置換の計算で使用できるようになる。
【００６５】
ＳＤＨ＝ＨＯＲＩＺＯＮＴＡＬ＿ＤＥＬＥＴＩＯＮ＿ＳＣＯＲＥ
このステップは、上述の垂直削除ステップと同一であるが、表２の水平方向での参照の削除を処理する。パラメータは、ＤＨがＤＶの代わりに使用されるなど、それに応じて変更される。
【００６６】
Ｓｍ＝ＳＵＢＳＴＩＴＵＴＩＯＮ＿ＳＣＯＲＥ（Ｍａｔｃｈ）
このスコアは、（ｉ−１，ｊ−１）から（ｉ，ｊ）への経路を採用することから生じる。これは、参照内での（ｒｉ−１，ｄｉ−１）から（ｒｉ，ｄｉ）への遷移に比べて照会内での（ｑｊ−１，ｔｊ−１）から（ｑｊ，ｔｊ）への遷移に対応する。しかし、親ノードが削除されている場合には、それらに伝搬された値が、この計算で使用される。たとえば、（ｒｉ−１，ｄｉ−１）が、前のステップで、この経路上で削除されている場合、その親の次元の値が、そのノードに伝搬されている。これらの値が、このステップで（ｒｉ−１，ｄｉ−１）の代わりに使用される。
【００６７】
新しいスコアＳｍ（ｉ，ｊ）は、親のスコアＳ（ｉ−１，ｊ−１）を（ｉ−１，ｊ−１）から（ｉ，ｊ）への遷移のスコアに加算することによって計算される。この遷移は、多次元ノード（この場合ではピッチおよび持続時間）間の遷移なので、スコアの相対重みを判定し、それに応じて使用する必要がある。これらのパラメータは、異なる照会に適合させることができる。複数の次元を使用する置換スコアを計算するための包括的な式は、次の通りである。
Ｓｍ（ｉ，ｊ）＝Ｓ（ｉ−１，ｊ−１）＋ｗ１＊ＳＴ１＋ｗ２＊ＳＴ２＋…    （式５）
ここで、ＳＴ１は、次元１（たとえば、ピッチ）での遷移のスコアであり、ＳＴ２は、次元２（たとえば、持続時間）での遷移のスコアであり、以下同様である。ｗ１、ｗ２、…は、これらの遷移の相対重みである。ＤＴＭ技法の他の実施形態では、重みを使用してあらゆる段階で各次元のスコアを組み合わせるのではなく、スコアの配列を伝搬させ、複数の段階の後で、スコアの配列を使用する、より複雑な判断基準に基づいて、判断を行うことが可能である。
【００６８】
メロディマッチングでは、式４が、
Ｓｍ（ｉ，ｊ）＝Ｓ（ｉ−１，ｊ−１）＋Ｒ＊ｐｉｔｃｈ＿ｒｅｗａｒｄ−Ｋ＊ｔｅｍｐｏ＿ｅｒｒｏｒ    （式６）
に換算され、ここで、ｐｉｔｃｈ＿ｒｅｗａｒｄは、（ｒｉ−１）から（ｒｉ）への遷移と比較した（ｑｊ−１）から（ｑｊ）への遷移のスコアである。ｔｅｍｐｏ＿ｅｒｒｏｒは、（ｄｉ−１）から（ｄｉ）に進む遷移と比較した（ｔｊ−１）から（ｔｊ）に進む遷移誤差である。
【００６９】
削除誤差と同様に、置換スコアには、突き合わされる音の持続時間に従って重みを付けることもできる。これは、その平均値によって正規化された照会内の音の持続時間（ｔｊ／ｍｅａｎ＿ｑ）または（（ｔｊ−１＋ｔｊ）／ｍｅａｎ＿ｑ）を、加算されたスコアに乗じることによって行うことができる。
【００７０】
ｐｉｔｃｈ  ｒｅｗａｒｄは、０と１との間の数であり、ｑｊ、ｑｊ−１、ｒｉ、ｒｉ−１を使用して次のように計算される：ｐｉｔｃｈ＿ｒｅｗａｒｄ＝１−ｐｉｔｃｈ＿ｅｒｒｏｒであり、ｐｉｔｃｈ＿ｅｒｒｏｒは、次のように計算される。
ケースＩ：ｑｊ、ｑｊ−１、ｒｉ、ｒｉ−１に「休止」がない：
ｐｉｔｃｈ  ｅｒｒｏｒは、オクターブジャンプを可能にするためのｍｏｄ  １２演算と共に、遷移の差の絶対値として計算され、次いで、任意選択で、より大きい遷移に関して正規化される。より複雑な非線形正規化を適用することができる。
ケースＩＩ：ｑｊとｒｉとの両方が、休止である：この場合には、ｐｉｔｃｈ＿ｅｒｒｏｒ＝０である。
ケースＩＩＩ：ｑｊおよびｒｉの一方だけが休止である：ｐｉｔｃｈ＿ｅｒｒｏｒ＝１。
ケースＩＶ：ｑｊ−１およびｒｉ−１のいずれかが休止である場合に、その親のピッチが、計算に使用され、次いで、上の３つのケースの１つが使用される。
【００７１】
ｔｅｍｐｏ＿ｅｒｒｏｒは、複数の技法を使用して計算することができる。本発明の技法で使用される１つの可能な技法は、次の通りである。
ｔｅｍｐｏ＿ｅｒｒｏｒ＝ａｂｓ（ｌｏｇ２［（ｄｉ／ｄｉ−１）（ｔｊ−１／ｔｊ）］）    （式６）
【００７２】
持続時間の比がより等しくなるにつれて、誤差がどのように０に減少するかに留意されたい。
【００７３】
合致スコアの品質は、この技法に履歴パラメータＭを追加することによって改善することができる。この実施形態では、合致スコアは、前のＭ個の突き合わされた親の重み付きスコアに基づいて計算される。パラメータＭは、設計パラメータである。Ｍのより大きい値は、より高い処理能力を必要とする。しかし、Ｍのより大きい値は、必ずしも性能を改善しない。たとえば、誤りのある参照変化の場合に、その誤りがスコア計算で伝搬され続けることは、本発明者らは望まない。したがって、Ｍの選択は、人間の注意のスパン、使用可能な計算能力、参照データベースの品質などの要因を考慮に入れなければならない。特定の実施形態でのＭの値は、当業者が容易に決定することができる。したがって、履歴パラメータの使用は、役に立つが、本明細書で特許請求される方法の機能に必須ではない。
【００７４】
ＳＶＣ＝ｍａｘ（ＶＥＲＴＩＣＡＬ＿ＣＯＮＳ＿ＳＣＯＲＥ（ｖ）），  ｖ＝１，２，３，…Ｖｍａｘ
このステップは、照会内の複数の音を組み合わせること、および、それらを参照内の単一の音と突き合わせることによって、より高いスコアを達成できるかどうかを判定する。これは、２つの音をマージし、スコアを再計算すること、次いで３つの音をマージし、スコアを再計算することなどによって反復される。限界Ｖｍａｘは、応用例およびデータのタイプならびに使用可能な処理能力に依存する設計パラメータである。音が組み合わされるとき、それらの持続時間は、加算される。それらのピッチは、休止ではない最長の持続時間を有する支配的な音のピッチとすることができ、あるいは、ｐｉｔｃｈ＿ｅｒｒｏｒを、合併される音ごとに別々に計算し、それらの持続時間に従って重みを付けることができる。後者が使用される場合に、休止のｐｉｔｃｈ＿ｅｒｒｏｒは、累算されない。
【００７５】
ＳＨＣ＝ｍａｘ（ＨＯＲＩＺＯＮＴＡＬ＿ＣＯＮＳ＿ＳＣＯＲＥ（ｈ）），ｈ＝１，２，３，…，Ｈｍａｘ
このステップは、上述の垂直合併ステップと同一であるが、表２の水平方向での参照内の合併を処理する。すべてのパラメータが、それに応じて変更される。
【００７６】
休止
前述のように、ほとんどの既存の技法は、突合せ技法を適用する前に、参照および照会から休止を除去する。しかし、休止は、貴重な情報を含む場合があり、性能を改善するのに使用することができる。休止は通常無視される。というのは、休止へまたは休止からの遷移が明確に定義されないので休止を処理することが難しい、または、場合によっては、休止が誤って検出され、ストリング（照会または参照）の一方に存在するが他方に存在しない場合があるからである。
【００７７】
本方法の目標は、休止が有用な情報をもたらす場合には休止を情報のソースとして使用し、休止がそのような情報をもたらさない場合にはペナルティなしで休止を無視することである。メロディマッチング以外の応用例での休止は、ノードの１つまたは複数の次元が意味のある値を有しない、ヌルノードの形でも存在し得る。メロディでは、休止の持続時間次元が、有効な値を含むが、ピッチ次元は、有効な値を含まない。
【００７８】
次のステップが、休止を処理するために適用される。
前処理：すべてのストリング（照会および参照）が、前処理され、その結果、すべてのストリングが、休止から始まらなくなり、連続する休止もなくなる。
すべての連続する休止が、それらの持続時間を加算することによってマージされる。削除では、ペナルティなしで（または減らされたペナルティを伴って）休止を削除することができる。
休止が突き合わされるとき、その突合せ親のピッチ次元が、この休止に伝搬され、その結果、この休止が後で別の音と突き合わされるとき、この休止の親のピッチ情報が使用されるようになる。
置換スコアのピッチ誤差を計算する際には、休止は、上述の４つのケースに従って処理される。
【００７９】
位置合わせ判定
スコアテーブルが完成した後で、このシステムは、ステップ２６０で、最良の位置合わせ経路を判定する。最初の行での削除は、スコアが０未満になるや否やスコアが必ず０に変更されるので、ペナルティを与えられない。位置合わせ後の参照内での削除がペナルティを与えられないことを確実にするために、ノード（ｍ，ｎ）で終わる最良の経路を見つけるのではなく、最高のスコアを有するセルである、最後の行の最終宛先を探す。これは、照会が、参照のいずれかの部分に完全に突き合わされ終えていることを保証する。この宛先ノードが判定された後で、この宛先ノードを逆方向に走査して、このノードにつながり、最高スコアをもたらした経路を判定する。その結果が、表１に示されたものなどの位置合わせテーブルである。
【００８０】
このレベルでは、解析は、照会が、指定されたスコア決定レベルで所与の参照シーケンスと合致するかどうかを判定するのに十分である。所与の応用例が、照会と参照シーケンスの組との間の最良の合致のランク付けによる判定を必要としない場合には、このレベルの解析が十分である。
【００８１】
しかし、多くの応用例では、最終目標は、所与の照会に合致している最良の参照を見つけることである。上記で得られたスコアは、次の理由に基づいて、最良の位置合わせのために参照を分類する目的にとって適切でない場合がある。
−短期記憶：位置合わせスコアは、合致するスコアが親ノードだけに依存する１次（ｆｉｒｓｔ  ｏｒｄｅｒ）として計算される。ある突き合わされたノードに誤りがある場合に、２つの遷移が影響を受け、したがって、１つの誤りが２つのペナルティをもたらす。
−休止の削除および音の合併は、所与の照会／参照対のより小さい最大の可能なスコアをもたらす可能性がある。異なる対が、それらの最大スコアに対する異なる上限を有する場合に、それらの最終スコアの比較は、公平な比較ではない。
【００８２】
これらの問題は、ステップ２６２、すなわち再スコア決定で対処され、ステップ２６２では、いくつかの技法を適用して、スコア決定の品質を改善する。再スコア決定は、Ｏ（ｍ＊ｎ）で行われる位置合わせとは対照的に、Ｏ（ｍ）で行われる。再スコア決定では、Ｒｅｓｃｏｒｅ＿Ｍ（必ずしもＭと等しくはない）未満だけ離れた音の各対の遷移が、スコア決定され、スコアが累算される。所与の位置合わせテーブルに関する最大スコアも、計算され、新しいスコアは、所与の位置合わせテーブルについて達成された最大スコアのパーセンテージとして報告される。これは、すべての照会／参照対の新しいスコアの間での公平な比較を保証する正規化プロセスである。新しいスコアの計算は、パラメータＲ、Ｋ、およびＭの異なる組を使用することができ、各遷移のスコアは、各遷移のノードの持続時間にも従って重みを付けられる。
【００８３】
新しいスコアは、参照の位置合わせされたセグメント内の削除されたノードについてペナルティを与えることによって、さらに正規化される。前述のように、位置合わせされたセグメントの前および位置合わせされたセグメントの後で削除されるノードには、ペナルティを与えるべきではない。というのは、照会は、参照のどの部分にも合致する可能性があるからである。しかし、再スコアは、参照の位置合わせされたセグメントの途中の削除されたノードに関するペナルティを考慮に入れていない。これに対処するために、新しいスコアは、位置合わせされたテーブル内の参照音の総持続時間で乗算され、位置合わせされたセグメントの総持続時間から削除された休止の持続時間を引いた値によって除算される。
【００８４】
このシステムは、次いで、判断ブロック２６４を介して、各参照シーケンスを通って反復する。最後に、新しいスコアが、参照ストリングを分類するのに使用され、ステップ２６６で、最高のスコアが、所与の照会に関する最良の合致として報告される。
【００８５】
システム実施形態
図８ａおよび図８ｂは、音楽アイテムを識別し、消費者に配布するシステム３００の形態で、本明細書で特許請求される発明の特定の実施形態を示す。明らかにされるように、システム３００は、個々の環境に合わせて構成することができ、その結果、システム全体が共に使用されるようになり、あるいは各サブシステムを独立の形で利用できるようになる。
【００８６】
音楽配布システム３００は、２つの協力するシステム、すなわちデータベース入力システム３１０および検索システム３６０として、最もよく視覚化することができる。まず、図８ａに示された入力システムを検討すると、ユーザは、設備の詳細に応じて、直接に、またはネットワークを介してこのシステムにアクセスすることができる。このシステムが、上述のようにウェブサイトの一部として構成される場合、ユーザ３０２は、ネットワーク３０４を介してアクセスすることになり、このネットワーク３０４は、その例ではインターネットであろう。他のシステムを、たとえば周遊船上のエンターテイメントシステムの一部としてなど、閉じたネットワークで動作するように構成することができる。
【００８７】
他のユーザ３０６は、このシステムに直接に接続された端末またはコンピュータを介して、このシステムに直接にアクセスすることができる。そのタイプのアクセスは、たとえば、ユーザがシステム３１０を介してタグを入力し、次いで、システム３６０を使用して音楽を検索することができる、小売店または商店街のキオスクで見ることができる。当業者なら、本明細書で示されるアクセスの手段およびシステムが、事実上例示的であることを理解するであろう。時間の経過につれて、他のアクセスデバイスが使用可能になり、そのようなデバイスは、本明細書に完全に組み込まれる。
【００８８】
どちらの場合でも、ユーザは、フロントエンド３１０と対話し、このフロントエンド３１０は、グラフィカルユーザインターフェース（ＧＵＩ）とすることができる。アクセスデバイスと同様に、当業者は、所与の設備または応用例に合わせてインターフェースデバイスの最も効果的な形態を考案することができるであろう。そのデバイスが本明細書に記載の機能を実行する限り、そのデバイスは、本発明の範囲に含まれる。
【００８９】
入力フェーズでは、ユーザは、音楽キャプチャモジュール３１４または音楽ランキングモジュール３２０と対話する。両システムの詳細な動作は、上述されている。音楽キャプチャモジュールは、オーディオファイルの形の音楽タグと、形態３１６を使用する、音楽およびユーザに関するメタデータとの両方を取り込むことに留意されたい。
【００９０】
音楽キャプチャモジュールが選択される場合、オーディオファイルは、処理エンジン３１６に送られ、この処理エンジンは、そのオーディオデータを上述のように処理する。結果のデータレコードは、記憶のために音楽データデータベース４００に転送される。サブシステム３１０および３６０が共に開発される実施形態では、音楽データデータベース４００が、これらのシステムによって共有される単一構成要素であることに留意されたい。
【００９１】
ユーザが音楽ランキングモジュール３２０を選択する場合、処理エンジンは関係せず、このモジュールは、データレコードに直接に相互作用する。ここでは、上記で示したように、音楽タグは変更されない。
【００９２】
ウェブ機能３３０は、上述のように、ユーザの相互対話を容易にし関心を高めるように設計された特徴を含む。奨励金または着信音変換の専用のウェブページなど、システム動作の改善を目指す特徴は、たとえば音楽ベースのソーシャルネットワークの構築専用のページと組み合わされる。そのような特徴は、それらが完全にシステムオペレータの自由裁量であることを示すために、破線の形態で図示されている。たとえば、小売店でのシステムの実施態様は、そのような特徴を含まない可能性が最も高いが、ウェブサイトは、おそらくはそのような特徴をユーザの注意の前面に押し出すであろう。当業者は、そのような特徴を利用して、本発明の技術的特徴に対して必要な焦点を保ちながら、最も利益を得ることができるであろう。
【００９３】
図８ｂは、検索システム３６０を示す。このシステムは、上述のデータ検索タスクを組み入れており、所望の音楽アイテムを消費者に手渡すのに必要なステップを追加するためにこれらのタスクを拡張する。上述のように、ユーザ３５２は、インターネットなどのネットワークを介して進行することができ、あるいは、３５６などのデバイスを介して直接アクセスを行うことができる。後者のデバイスは、音楽の選択および販売を監督できる、ミュージックストア内の端末またはキオスクとして容易に実施することができる。
【００９４】
フロントエンド３６２は、このシステムとのユーザ対話を管理する。このシステムは、図８ａのフロントエンド３１０と組み合わせるか、これと機能を共有することができる。同様に、照会キャプチャモジュール３６４は、図８ａのキャプチャモジュール３１４と一致するものとすることができる。ここで、ユーザは、従うべき代替の機能がないので、フロントエンドからそのモジュールに直接に進む。
【００９５】
ユーザは、上述のように照会タグを供給し、この照会タグは、処理エンジンに供給される（この処理エンジンは、やはり、適切な構成の処理エンジン３１８と同一の、またはこれと同じモジュールとすることができる。結果のデータファイルは、マッチングエンジン３６８に供給され、このマッチングエンジン３６８は、ＤＴＭシステムまたは同等の方法などのマッチングアルゴリズムを適用して、音楽データデータベース４００に含まれる音楽タグの中から最良の合致を検索する。
【００９６】
マッチングエンジンは、アイテムメタデータ（データ１６７、図５）を使用して、タグがあてはまる音楽アイテムを識別し、その情報をフロントエンド３６２に転送する。ユーザが望む場合に、フロントエンドは、音楽アイテム自体を音楽アイテム記憶装置４１０から検索し、ユーザに直接に供給することができる。保持施設に置かれる実施形態では、音楽記憶デバイスは、その店内の実際の音楽アイテムの在庫情報および位置情報を供給することができ、あるいは任意選択で、その音楽アイテムを特別注文する能力を提供することができる。
【００９７】
他の実施形態は、システム内の音楽アイテム記憶データベースを使用するのではなく、第三者の販売者によって提供されるそのようなシステムにアクセスする。このようにして、小さい施設が、広範囲の音楽ライブラリを組み立てるという代償なしで、広範な音楽入手可能性を提供することができる。
【００９８】
他の実施形態
当業者なら、本明細書で開示され特許請求されるシーケンスマッチング方法を複数の環境で適用できることを理解するであろう。特に望ましい実施形態は、遺伝子配列解析システムでこの方法を使用することになり、この遺伝子配列解析システムでは、突き合わされる配列が、音楽の音ではなく、ＤＮＡ鎖に基づく。もう１つの望ましい実施形態は、音声認識でこの方法を使用することであろう。
【００９９】
本発明は、方法またはこの方法を実施するように適合されたデバイスとして実施することができる。本発明は、非テキストベースの情報のコンピュータ支援検索を実行するロジックを与えられた媒体などの製造品とすることができる。
【０１００】
本発明は、上記で詳細に示した好ましい実施形態および例を参照して開示されているが、これらの例が、制限的な意味ではなく例示的であることを意図されていることを理解されたい。当業者が変更および組合せをたやすく思い浮かべるであろうことが企図されており、それらの変更および組合せは、本発明の精神および添付の特許請求の範囲に含まれる。
【図面の簡単な説明】
【０１０１】
【図１】記憶された音楽の非テキストベースのデータベースを構築するプロセスの実施形態を示す図である。
【図２】図１に示された実施形態によるタグの記録を制御するグラフィカルインターフェースの一実施形態を示す図である。
【図３】間接タグ入力インターフェースの一実施形態を示す図である。
【図４】図１の実施形態によるタグキーの構築を示す図である。
【図５】記憶された音楽を検索するためのデータベースのデータレコードの構造を示す図である。
【図６】図１に示された実施形態による、タグの品質に関する投票を制御するグラフィカルインターフェースの一実施形態を示す図である。
【図７】記憶された音楽を検索するプロセスの実施形態を示す図である。
【図８ａ−８ｂ】記憶された音楽のデータベースを構築し、記憶された音楽を検索するプロセスの実施形態を示す図である。
【図１】
2009516268.tif 000005
【図２】
2009516268.tif 000006
【図３】
2009516268.tif 000007
【図４】
2009516268.tif 000008
【図５】
2009516268.tif 000009
【図６】
2009516268.tif 000010
【図７】
2009516268.tif 000011
【図８ａ】
2009516268.tif 000012
【図８ｂ】
2009516268.tif 000013
【国際調査報告】
2009516268.tif 000014