(57)【特許請求の範囲】
【請求項１】
曲情報と、その曲のメロディが直前の音に対する高低変化を表す符号にてコード化されたメロディコードと、を関連付けて記憶した記憶手段と、
検索対象であるメロディが直前の音に対する高低変化を表す符号にてコード化された検索対象メロディコードの入力を受け付けるメロディ検索受付手段と、
前記検索対象メロディコードに対応する曲を前記記憶手段に記憶された前記メロディコードに基づいて検索するメロディ検索手段と、
検索された曲の前記曲情報を出力する曲情報出力手段と、
を備え、
前記メロディ検索受付手段は、メロディ検索装置にネットワークを介して接続された入力装置を備えた携帯型情報処理端末から送信された前記検索対象メロディコードの入力を受け付けると共に、
前記曲情報出力手段は、前記携帯型情報処理端末に対して検索結果である曲情報を送信し、
前記メロディコードと前記検索対象メロディコードとは、直前の音に対して、高い、低い、変化なし、をそれぞれ表す３値符号にて構成されており、
前記メロディ検索受付手段は、３×３に配置された操作ボタンを含む前記入力装置を備えた前記携帯型情報処理端末から、前記３値符号がそれぞれ割り当てられた、縦、横、斜めのいずれかに並んで配置された３つの前記操作ボタンに入力された前記検索対象メロディコードを受け付ける、
ことを特徴とするメロディ検索装置。
【請求項２】
前記携帯型情報処理端末は、携帯電話である、ことを特徴とする請求項１記載のメロディ検索装置。
【請求項３】
前記記憶手段は、前記曲情報として当該曲の音源データを記憶する、ことを特徴とする請求項１又は２記載のメロディ検索装置。
【請求項４】
曲情報と、その曲のメロディが直前の音に対する高低変化を表す符号にてコード化されたメロディコードと、を関連付けて記憶した記憶手段を備えたコンピュータに、
検索対象であるメロディが直前の音に対する高低変化を表す符号にてコード化された検索対象メロディコードの入力を受け付けるメロディ検索受付手段と、
前記検索対象メロディコードに対応する曲を前記記憶手段に記憶された前記メロディコードに基づいて検索するメロディ検索手段と、
検索された曲の前記曲情報を出力する曲情報出力手段と、
を実現させると共に、
前記メロディ検索受付手段は、メロディ検索装置にネットワークを介して接続された入力装置を備えた携帯型情報処理端末から送信された前記検索対象メロディコードの入力を受け付け、
前記曲情報出力手段は、前記携帯型情報処理端末に対して検索結果である曲情報を送信し、
前記メロディコードと前記検索対象メロディコードとは、直前の音に対して、高い、低い、変化なし、をそれぞれ表す３値符号にて構成されており、
前記メロディ検索受付手段は、３×３に配置された操作ボタンを含む前記入力装置を備えた前記携帯型情報処理端末から、前記３値符号がそれぞれ割り当てられた、縦、横、斜めのいずれかに並んで配置された３つの前記操作ボタンに入力された前記検索対象メロディコードを受け付ける、
ことを実現させるためのプログラム。
【請求項５】
曲情報と、その曲のメロディが直前の音に対する高低変化を表す符号にてコード化されたメロディコードと、を関連付けて記憶した記憶手段を備え、前記メロディコードに基づいて曲の検索を行うメロディ検索装置、にネットワークを介して接続された操作部及び表示部を有する携帯型情報処理端末であって、
検索対象であるメロディが直前の音に対する高低変化を表す符号にてコード化された検索対象メロディコードの入力を、前記操作部から受け付ける入力受付手段と、
受け付けた前記検索対象メロディコードを前記メロディ検索装置に対して送信して検索要求する検索要求手段と、
この検索要求に応じて前記メロディ検索装置から送信される前記曲情報を受け付けて前記表示部に表示する検索結果受付手段と、
を備え、
前記メロディコードと前記検索対象メロディコードとは、直前の音に対して、高い、低い、変化なし、をそれぞれ表す３値符号にてコード化されており、
前記入力受付手段は、前記操作部が有する３×３に配置された操作ボタンのうち、前記３値符号がそれぞれ割り当てられた、縦、横、斜めのいずれかに並んで配置された３つの前記操作ボタンに入力された前記検索対象メロディコードを受け付ける、
ことを特徴とする携帯型情報処理端末。
【請求項６】
前記メロディ検索装置にネットワークを介して接続された携帯電話である、ことを特徴とする請求項５記載の携帯型情報処理端末。
【請求項７】
曲情報と、その曲のメロディが直前の音に対する高低変化を表す符号にてコード化されたメロディコードと、を関連付けて記憶した記憶手段を備え、前記メロディコードに基づいて曲の検索を行うメロディ検索装置、にネットワークを介して接続された操作部及び表示部を有する携帯型情報処理端末に、
検索対象であるメロディが直前の音に対する高低変化を表す符号にてコード化された検索対象メロディコードの入力を、前記操作部から受け付ける入力受付手段と、
前記検索対象メロディコードを前記メロディ検索装置に対して送信して検索要求する検索要求手段と、
この検索要求に応じて前記メロディ検索装置から送信される前記曲情報を受け付けて前記表示部に表示する検索結果受付手段と、
を実現させると共に、
前記メロディコードと前記検索対象メロディコードとは、直前の音に対して、高い、低い、変化なし、をそれぞれ表す３値符号にてコード化されており、
前記入力受付手段は、前記操作部が有する３×３に配置された操作ボタンのうち、前記３値符号がそれぞれ割り当てられた、縦、横、斜めのいずれかに並んで配置された３つの前記操作ボタンに入力された前記検索対象メロディコードを受け付ける、
ことを実現させるためのプログラム。
【請求項８】
曲情報とその曲のメロディが直前の音に対する高低変化を表す符号にてコード化されたメロディコードとを関連付けて記憶した記憶手段を備えたメロディ検索装置が、当該メロディ検索装置にネットワークを介して接続された入力装置を備えた携帯型情報処理端末から検索対象であるメロディが直前の音に対する高低変化を表す符号にてコード化された検索対象メロディコードの入力を受け付けるメロディ検索受付工程と、
前記メロディ検索装置が、前記検索対象メロディコードに対応する曲を前記記憶手段に記憶された前記メロディコードに基づいて検索するメロディ検索工程と、
前記メロディ検索装置が、前記携帯型情報処理端末に対して検索された曲の前記曲情報を送信して出力する曲情報出力工程と、
前記メロディ検索受付工程の前に、前記携帯型情報処理端末が、前記検索対象メロディコードの入力を受け付けて前記メロディ検索装置に送信するメロディ入力工程と、
を有し、
前記メロディコードと前記検索対象メロディコードとは、直前の音に対して、高い、低い、変化なし、をそれぞれ表す３値符号にてコード化されており、
前記メロディ入力工程は、３×３に配置された操作ボタンを含む前記入力装置を備えた前記携帯型情報処理端末が、前記３値符号がそれぞれ割り当てられた、縦、横、斜めのいずれかに並んで配置された３つの前記操作ボタンに入力された前記検索対象メロディコードを受け付けて、前記メロディ検索装置に送信する、
ことを特徴とするメロディ検索方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メロディ検索装置にかかり、特に、簡略化されたメロディコードを利用してメロディを検索するメロディ検索装置に関する。
【背景技術】
【０００２】
近年の携帯電話には、着信時に着信音の代わりに音楽を流す機能や、携帯電話機を音楽プレーヤーとして使用し音楽を聞く機能など、音楽再生機能が備わっている。このため、音楽に関するサービス、例えば、ネットワークを介した音楽配信サービスなどが普及している。
【０００３】
そして、ユーザが音楽の配信を希望する場合には、もちろん音楽を検索する必要が生じる。かかる検索時には、通常、曲名、作曲者や歌手などで検索するのが一般的である。例えば、下記特許文献１には、ユーザの携帯電話から曲のヒントになるようなキーワードを入力して管理サーバへ送出すると、管理サーバで候補リストが返送され、そして、ユーザはその候補リストを見て、実際に欲しい曲を指定してサーバから曲のデータをダウンロードする、というシステムが開示されている。
【０００４】
さらに、近年では、鼻歌を歌って検索システムにメロディを入力すると、そのメロディを検索するという技術開発も進められている（非特許文献１参照）。
【０００５】
一方で、１つ１つの曲のメロディを表現する方法として、1975年にDenys Parsonsが発明した方法がある。これは、同年に出版された”The Directory of Tunesand musical Themes” (Publisher: Spencer  Brown, London Date
Published:1975 ISBN: 090474700X）という本に記載されている方法である（以下、「Parsonsのコード化手法」という）。このParsonsのコード化手法は、曲のメロディを、
●：先頭の音
U(Up)：１つまえの音より上がっている
D(Down)：１つまえの音より下がっている
R(Repeat)：１つまえの音と同じ
の４種類で表現する。このうち、●は、先頭の音としてどの音でもよく、単に先頭を表現しているだけので、実質的には、３種類のコードにてメロディを表現している。例えば、ベートーヴェンの第５交響曲「運命」は、有名な「タタタター、タタタター」（音名：ソソソミー  ファファファレー)で始まるものだが、これは、●RRDURRDで表現される。
【０００６】
そして、上記Parsonsのコード化手法を利用してメロディの検索を行うことについて、下記特許文献２，３に示唆されている。特許文献２には、ユーザにて音声により入力されたメロディ自体を、上述したParsonsのコード化手法にて変換し、データベースと比較することが開示されている。また、特許文献３には、Parsonsのコード化手法によるコードを用いた検索の可能性について開示されている。
【０００７】
【特許文献１】特開２００４−３４２０４４号公報
【特許文献２】特開２００２−１３２２７８号公報
【特許文献３】特表２００３−５２９０９１号公報
【非特許文献１】蔭山哲也、高島洋典、「ハミング歌唱を手掛かりとするメロディ検索」、電子情報通信学会論文誌、1994、VOL.J77-D-II、 No. 8
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、上述した従来例には、以下のような不都合があった。まず、上述した特許文献１に開示の技術では、曲に関係する言葉であるキーワードを入力するというものであるため（例えば、「どらえもん」と入れると、「どらえもん」のＴＶ番組の主題歌が選択され、「国歌」と入れると、「君が代」や米国の国歌のリストが提示される）、メロディは思いついたが、作曲者も歌手も曲名も全然思い出さない場合には、検索することが困難である。さらには、キーワードを思い出すことや打つことが面倒な場合もしばしばあり、例えば、携帯電話では、通話機能を優先させるためにキーボードが小さく、このような入力のしにくい小さいキーボードでは、曲名や作曲者名を入れるのは不便かつ面倒である、という問題が生じる。
【０００９】
また、非特許文献１に開示の技術では、携帯電話にはマイクがついており、音声認識装置を組み込んだものも存在するため、実際に鼻歌を歌って検索をすることも可能であるが、電車の中のような人前で鼻歌を歌って検索したいときには行うことができない。さらには、検索したい曲のメロディをより正確に再現して入力しなければならないため、所望の曲を検索することが困難である、という問題が生じる。
【００１０】
さらに、特許文献２では、上述したParsonsのコード化手法にて、入力された音楽及びデータベースに蓄積された音楽をそれぞれ変換して検索に用いるため、かかる変換処理時に処理時間及び処理負荷がかかる、という問題が生じる。また、ユーザは実際に歌うなどして入力しなければならないため、上述同様の問題が生じる。
【００１１】
また、特許文献３には、検索の可能性について触れられているだけであって、ましてや、かかる技術は検索に適していないとの記載があることから、どのような構成にて実現するか、といったことは一切開示されていない。
【００１２】
このため、本発明では、上記従来例の有する不都合を改善し、特に、特別に音楽知識を持たないユーザであっても、検索する音楽情報の入力が容易であり、簡単かつ的確にメロディから曲の検索を行うことができるメロディ検索システムを提供することをその目的とする。
【課題を解決するための手段】
【００１３】
そこで、本発明の一形態であるメロディ検索装置は、
曲情報と、その曲のメロディが直前の音に対する高低変化を表す符号にてコード化されたメロディコードと、を関連付けて記憶した記憶手段と、
検索対象であるメロディが直前の音に対する高低変化を表す符号にてコード化された検索対象メロディコードの入力を受け付けるメロディ検索受付手段と、
検索対象メロディコードに対応する曲を記憶手段に記憶されたメロディコードに基づいて検索するメロディ検索手段と、
検索された曲の曲情報を出力する曲情報出力手段と、
を備えたことを特徴としている。
【００１４】
そして、メロディコードと検索対象メロディコードとは、直前の音に対して、高い、低い、変化なし、をそれぞれ表す３値符号にて構成されている、ことを特徴としている。また、メロディ検索受付手段は、３値符号がそれぞれ割り当てられ並んで配置された３つの操作ボタンを有する入力装置から検索対象メロディコードの入力を受け付ける、ことを特徴としている。さらに、メロディ検索受付手段は、メロディ検索装置にネットワークを介して接続された入力装置である携帯型情報処理端末から送信された検索対象メロディコードの入力を受け付けると共に、曲情報出力手段は、携帯型情報処理端末に対して検索結果である曲情報を送信する、ことを特徴としている。そして、例えば、携帯型情報処理端末は、携帯電話である。
【００１５】
上記発明によると、まず、ユーザは、検索したいメロディを、所定の音を基準とした高低変化、特に、直前の音に対して、高い、低い、変化なし、といった３値符号にて入力することで、メロディの検索要求をすることができる。そして、メロディ検索装置側では、上述したような符号にて予め各曲のメロディが記憶されており、入力された３値符号に基づいて曲の検索を行うことができる。従って、ユーザにとっては、メロディを正確に記憶していない場合であっても、直前の音に比べて、上がるか、下がるか、同音か、さえ間違えなければ、正しく検索することができるため、利便性が向上しうる。また、３値コードの入力で済むため、携帯電話などのキーが小さい装置からも容易に入力でき、検索することができる。特に、３×３に配置された携帯電話のキーでは、縦、横、斜めなどに並んで配列された３つのキーを用いることで、例えば片手で親指をずらして容易に入力することができる。さらに、メロディ検索装置側では、３値符号のマッチングなどによる検索処理を実行すればよいため、処理負荷が軽減される。
【００１６】
また、記憶手段は、曲情報として当該曲の音源データを記憶する、ことを特徴としている。これにより、曲名を検索した後に、その曲の音源データを携帯電話にダウンロードすることもでき、ユーザの利便性、及び、事業者側のサービスの向上を図ることができる。
【００１７】
また、本発明の他の形態であるプログラムは、
曲情報と、その曲のメロディが直前の音に対する高低変化を表す符号にてコード化されたメロディコードと、を関連付けて記憶した記憶手段を備えたコンピュータに、
検索対象であるメロディが直前の音に対する高低変化を表す符号にてコード化された検索対象メロディコードの入力を受け付けるメロディ検索受付手段と、
検索対象メロディコードに対応する曲を記憶手段に記憶されたメロディコードに基づいて検索するメロディ検索手段と、
検索された曲の曲情報を出力する曲情報出力手段と、
を実現させる、ことを特徴としている。
【００１８】
さらに、本発明の他の形態である入力装置は、
曲情報と、その曲のメロディが直前の音に対する高低変化を表す符号にてコード化されたメロディコードと、を関連付けて記憶した記憶手段を備え、メロディコードに基づいて曲の検索を行うメロディ検索装置、に接続された操作部及び表示部を有する入力装置であって、
検索対象であるメロディが直前の音に対する高低変化を表す符号にてコード化された検索対象メロディコードの入力を、操作部から受け付ける入力受付手段と、
受け付けた検索対象メロディコードをメロディ検索装置に対して送信して検索要求する検索要求手段と、
この検索要求に応じてメロディ検索装置から送信される曲情報を受け付けて表示部に表示する検索結果受付手段と、
を備えたことを特徴としている。
【００１９】
このとき、例えば、メロディコードと検索対象メロディコードとは、直前の音に対して、高い、低い、変化なし、をそれぞれ表す３値符号にてコード化されており、操作部に装備され並んで配置された３つの操作ボタンに、３値符号がそれぞれ割り当てられている、ことを特徴としている。そして、例えば、入力装置は、メロディ検索装置にネットワークを介して接続された携帯電話である。
【００２０】
また、本発明の他の形態であるプログラムは、
曲情報と、その曲のメロディが直前の音に対する高低変化を表す符号にてコード化されたメロディコードと、を関連付けて記憶した記憶手段を備え、メロディコードに基づいて曲の検索を行うメロディ検索装置、に接続された操作部及び表示部を有する入力装置に、
検索対象であるメロディが直前の音に対する高低変化を表す符号にてコード化された検索対象メロディコードの入力を、操作部から受け付ける入力受付手段と、
検索対象メロディコードをメロディ検索装置に対して送信して検索要求する検索要求手段と、
この検索要求に応じてメロディ検索装置から送信される曲情報を受け付けて表示部に表示する検索結果受付手段と、
を実現させる、ことを特徴としている。
【００２１】
さらに、本発明の他の形態であるメロディ検索方法は、
曲情報とその曲のメロディが直前の音に対する高低変化を表す符号にてコード化されたメロディコードとを関連付けて記憶した記憶手段を備えたメロディ検索装置が、検索対象であるメロディが直前の音に対する高低変化を表す符号にてコード化された検索対象メロディコードの入力を受け付けるメロディ検索受付工程と、
メロディ検索装置が、検索対象メロディコードに対応する曲を記憶手段に記憶されたメロディコードに基づいて検索するメロディ検索工程と、
メロディ検索装置が、検索された曲の曲情報を出力する曲情報出力工程と、
を有する、ことを特徴としている。
【００２２】
そして、メロディコードと検索対象メロディコードとは、直前の音に対して、高い、低い、変化なし、をそれぞれ表す３値符号にてコード化されている、ことを特徴としている。また、メロディ検索受付工程は、メロディ検索装置に接続された入力装置に並んで配置され、３値符号がそれぞれ割り当てられた３つの操作ボタンから入力された検索対象メロディコードを受け付ける、ことを特徴としている。さらに、メロディ検索受付工程の前に、メロディ検索装置にネットワークを介して接続された入力装置である携帯型情報処理端末が、検索対象メロディコードの入力を受け付けてメロディ装置に送信して入力するメロディ入力工程を有する、ことを特徴としている。
【００２３】
上述した構成の入力装置、プログラム、メロディ検索方法といった発明であっても、上記メロディ検索装置と同様に作用するため、上述した本発明の目的を達成することができる。
【発明の効果】
【００２４】
本発明は、以上のように構成され機能するので、これによると、ユーザにとっては、メロディを正確に記憶していない場合であっても、直前の音と比較した高低変化を入力することにより、正しく検索することができるため、入力時の手間が省けるとともに容易に入力することができ、また、高度な音楽的才能も必要が無く、音楽検索時の利便性の向上を図ることができる、という従来に無い優れた効果を有する。さらには、メロディ検索装置側にとっては、簡易にコード化されたメロディデータを用いて音楽の検索処理を実行すればよいため、処理負荷が軽減される。
【発明を実施するための最良の形態】
【００２５】
本発明では、メロディを、直前の音と比較した高低変化に基づいてコード化して検索を行うことに特徴を有する。以下、実施例では、メロディのコード化の一例として、所定の音を基準とした、高い、低い、変化なし、といった３値符号にて表したコードを利用する場合を説明する。但し、本発明は、メロディが３値符号にコード化されたものを利用する場合に限定されず、さらに多値の符号にコード化されたものを利用して検索を行ってもよい。
【００２６】
また、実施例では、メロディ検索処理を実行するメロディ検索サーバ（メロディ検索装置）にネットワークを介して接続された携帯電話といった携帯型情報処理端末を入力装置、及び、検索結果を表示する装置として利用する場合を例示して説明するが、携帯電話に限定されず、メロディ検索サーバとデータ通信可能な他の情報処理端末にて検索が可能なよう構成してもよい。また、入力装置は、必ずしもメロディ検索サーバにネットワークを介して接続されている装置でなくてもよく、コンピュータであるメロディ検索サーバのキーボードなどを検索時の入力装置として利用してもよい。
【実施例１】
【００２７】
本発明の第１の実施例を、図１乃至図５を参照して説明する。図１乃至図２は、ユーザが操作する携帯電話の構成を示す図であり、図３は、メロディ検索サーバの構成を示す図である。図４乃至図５は、メロディ検索の際の動作を示す図である。
【００２８】
［構成］
本発明におけるメロディ検索システムは、ユーザが検索対象となるメロディを入力する携帯電話１と、この携帯電話１とネットワークを介して接続されたメロディ検索処理を実行するメロディ検索サーバ５（メロディ検索装置）と、を備えている。以下、それぞれの装置について詳述する。
【００２９】
＜メロディ検索サーバ＞
メロディ検索サーバ５は、ネットワーク上に設置されたサーバコンピュータであり、後述するように、携帯電話１からメロディの検索要求を受け付け、メロディの検索処理を実行し、その検索結果を通知する機能を有する。具体的には、ＣＰＵなどの演算装置に所定のプログラムが組み込まれることにより、図３に示すように、検索要求受付処理部５１と、メロディ検索処理部５２と、検索結果出力処理部５３と、が構築されている。また、ハードディスクなどの記憶装置（記憶手段）には、音楽データベース５４（音楽ＤＢ）が形成されている。以下、さらに詳述する。
【００３０】
まず、音楽ＤＢ５４には、各曲毎に、曲名と、その曲のメロディが上述したようにParsonsのコード化手法にてコード化されたメロディコードと、が関連付けられて記憶されている。その一例を、図４に示す。ここでは、音楽データベースとしての表の名前を「楽曲表」とし、「メロディコード」と「曲名」の２つのカラムからなる表として定義してある。
【００３１】
具体的には、上述したように、曲のメロディを、
●：先頭の音（曲の開始）
U(Up)：１つ前の音より上がっている
D(Down)：１つ前の音より下がっている
R(Repeat)：１つ前の音と同じ
の４種類で表現している。なお、先頭の音はどの音でもよいため、３値符号にて表現していることと同じである。
【００３２】
なお、上述したParsonsのコード化手法によると、10000曲のクラシック、ロック、フォークソングのメロディは、１６コード（１６音）あれば、各メロディを識別するのに十分であると言われている。すると、１音を３値（２ビット）にて表せるため、２×１６＝３２ビットあれば、十分ということになる。かかる場合に、実装の容易さを考慮すると、１音ごとに１バイトを割り当てたとしてメロディを文字列として表現したとして、１６バイトで済む。実際には、より大規模な音楽データベースに対応するためにもう少し多くしておくのがよいが、いずれにせよ、メロディ情報を格納するために、非常に小さい容量で十分である。また、曲名は、最大の長さが100文字だとして１曲ごとに100バイトあれば良いので、こちらも非常に少ない容量で済む。従って、１曲を１レコードとした場合に、１レコード毎に１６バイトと１００バイトあれば良いことになる。
【００３３】
また、図４には図示していないが、音楽ＤＢ５４には、さらに、各曲毎に、その曲の原曲となるメロディを表す音源データも、関連付けられて記憶されている。なお、この音源データは、後述するように、送信された携帯電話１などで再生可能なデータである。
【００３４】
次に、各処理部５１〜５３について説明する。検索要求受付処理部５１（メロディ検索受付手段）は、後述する携帯電話１からネットワークを介して送信された、検索対象であるメロディがParsonsのコード化手法にて表された３値符号による検索対象メロディコード、及び、検索要求、を受信してメロディ検索処理部５２に渡す。
【００３５】
メロディ検索処理部５２（メロディ検索手段）は、上述したように携帯電話１から受信した検索対象メロディコードに対応する曲を、音楽ＤＢ５４内から検索する。このとき、受信した検索対象メロディコードと、音楽ＤＢ５４内に記憶されている各曲のメロディコードの一部と、が一致するか否かによって検索する。ここでの検索は、各メロディコードは文字列として表現されているため、文字列同士の比較で先頭が部分一致するかどうかを調べることにより行われる。例えば、文字列同士の部分一致比較は、関係データベースの標準言語であるSQLでは、LIKE演算子として規定されているので、通常の関係データベースではLIKE演算子は提供されている。そこで、LIKE演算子をそのまま使えばよい。具体的には、利用者が携帯電話で入力してサーバに送信された検索対象メロディコードが、文字列変数INPUTに入っているとすると、
SELECT  曲名 FROM 楽曲表 WHERE メロディ LIKE INPUT + '%'
というSQL式を関係データベースのエンジンに発行すればよい。すると、INPUTに含まれる検索対象メロディコードが先頭に来る「メロディ」フィールドの値を含むレコードがマッチして、その「曲名」フィールドの値が返される。より具体的に説明すると、例えば、利用者が、ベートーヴェンの運命交響曲の最初のメロディ断片として、検索対象メロディコードを、
●RRDURRD
として入力すると、検索式は、
SELECT  曲名 FROM 楽曲表 WHERE メロディ LIKE '●RRDURRD%'
となる。ここで、%(パーセント）記号は、任意の文字にマッチするワイルドカードの特殊文字である。従って、「楽曲表」から'●RRDURRD'で始まるメロディのレコードが検索される。仮に、先頭から８音の上下が'●RRDURRD'と同じ曲が、運命交響曲と同じものがあれば、それも検索される。この検索結果（曲名や該当なしとの結果）が、メロディ検索処理部５２から検索結果出力処理部５３への出力となる。
【００３６】
また、検索結果出力処理部５３（曲情報出力手段）は、上述したメロディ検索処理部５２による検索結果、つまり、検索されたメロディコードに関連付けられた曲情報である曲目や音源データを、携帯電話１に返送する。あるいは、検索できなかったときには、該当データなしの情報を返送する。なお、図４に示す符号５０には、上述したメロディ検索サーバ５の演算装置に構築される機能を示している。
【００３７】
＜携帯電話＞
次に、メロディの検索を要求するユーザが操作する携帯電話１について説明する。携帯電話１は、各数字の操作ボタンを含む操作部２と、液晶ディスプレイである表示部３と、携帯電話による各種機能を実現するための処理を実行するＣＰＵである演算部と、所定のデータを記憶しておくＲＡＭやＲＯＭなどの記憶部と、を備えた一般的な携帯電話である。また、この携帯電話１には、通話機能のみならず、インターネットなどのネットワークにアクセスして、他のサーバコンピュータとデータ通信を行う機能も有している。さらには、音楽データを再生する機能も有している。
【００３８】
そして、携帯電話１の演算装置には、所定のプログラムが組み込まれることにより、図２に示すように、送受信処理部１１、入力受付処理部１２、表示処理部１３、が構築されている。
【００３９】
送受信処理部１１は、メロディ検索サーバ５とデータ通信を行う処理部である。例えば、後述するように入力受付処理部１２にて入力されたParsonsのコード化手法にて表された検索対象メロディコードを、メロディバッファであるメモリ１４から読み出してメロディ検索サーバ５に対して送信し、検索要求する機能（検索要求手段）を有する。また、この検索要求に応じてメロディ検索サーバ５から送信された検索結果を受け付けて、表示処理部１３に通知する機能を有する。これに応じて、表示処理部１３は、受け付けた検索結果、つまり、検索された曲名あるいは検索されなかった旨の情報を、表示部３に表示する機能を有する。従って、送受信処理部１１は、表示処理部１３と協働して検索結果を受け付けて、表示部３に表示するといった検索結果受付手段としても機能する。
【００４０】
また、入力受付処理部１２（入力受け付け手段）は、操作部２からユーザにて入力された、Parsonsのコード化手法にて表された３値符号による検索対象メロディコードを受け付けて、メモリ１４に一時保存する。そして、送受信処理部１１に対して、上述したようにメロディ検索サーバ５に検索要求してもらうよう通知したり、表示部３に入力内容を表示してもらうよう表示処理部１３に通知する。
【００４１】
ここで、操作部２の操作ボタンは、それぞれ以下の値を入力するよう設定されている。まず、メロディ入力開始を指定するコードを出力するS（Start）キーとして、符号２４に示す数字４のキーが対応している。また、直前の音に対して音程が上がっていることを指定するコードを出力するU（Up）キーとして、符号２１に示す数字１のキーが対応している。そして、直前の音に対して音程が下がっていることを指定するコードを出力するD（Down）キーとして、符号２２に示す数字２のキーが対応している。さらに、直前の音に対して音程が変化しないことを指定するコードを出力するR（Repeat）キーとして、符号２３に示す数字３のキーが対応している。
【００４２】
このように、本実施例では、図１の符号２１〜２３に示す数字１，２，３のように、横に並んで配列された３つの操作ボタンにて、Parsonsのコード化手法による３値符号が入力可能となり、かかるデータが入力受付処理部１２にて受け付け可能となる。従って、携帯電話１では、親指一本を左右にずらすだけでメロディの入力が可能となり、利便性が増す。但し、上述した各コードは、横に並んで配列された操作ボタンに割り当てられることに限定されず、縦や斜めに配列されて割り当てられてもよい。
【００４３】
なお、入力受付処理部１２にて受け付けられる検索対象メロディコードは、メロディバッファとしてのメモリ１４に一時格納されるが、この格納容量としては、メロディ検索サーバ５に記憶されている音楽ＤＢ５４のメロディコードで説明したように、例えば、１６バイトといった非常に小量の容量で済む。
【００４４】
［動作］
次に、上記構成のシステムの動作を、図４及び図５を参照して説明する。図４は、携帯電話１及びメロディ検索サーバ５間におけるメロディ検索時のデータの流れを示す説明図であり、図５は、メロディ検索サーバ５の動作を示すフローチャートである。
【００４５】
まず、ユーザは、曲目が知りたいメロディを、上述したParsonsのコード化手法による３値コードにて、携帯電話１から入力する。このとき、まず、符号２４に示すキーにて、入力開始の合図となる「●」コードを入力する。その後、この音に続く音の音程が上がっているか、下がっているか、同じか、に応じて、各コード「U」「D」「R」を対応するキー（符号２１〜２３）にて入力する。すると、入力されたコードは、検索対象メロディコードとして、メモリ１４内に一時格納される。ここでは、例えば、「●RRDURRD」と入力されたとする。その後、この検索対象メロディコードが携帯電話１からメロディ検索サーバ５に送信され、これにより、メロディの検索要求がなされる（メロディ入力工程）。
【００４６】
すると、メロディ検索サーバ５は、携帯電話１から入力された検索対象メロディコードを受け付け（メロディ検索受付工程）、対応するメロディの検索を行う（メロディ検索工程）。具体的には、検索対象メロディコードのＳＱＬ言語処理エンジンにて、
SELECT  曲名 FROM 楽曲表 WHERE メロディ LIKE INPUT + '%'
というSQL式のINPUTに入力する（ステップＳ１）。すると、INPUTに含まれるメロディ断片である検索対象メロディコードが先頭に来る「メロディ」フィールドの値を含むレコードがマッチして、その「曲名」フィールドの値が返される（ステップＳ２）。このとき、検索できなかった場合には、「適合するメロディはありませんでした」という文字列がOUTPUTに入力される（ステップＳ３）。
【００４７】
その後、検索結果となるOUTPUT変数の値が、携帯電話１に送信される（ステップＳ４、曲情報出力工程）。これにより、携帯電話１の表示部３には、検索対象メロディコードに対応する曲の曲目が表示されることとなり、ユーザは曲目を知ることができる。なお、メロディ検索サーバ５からは、検索された曲の音源データが携帯電話１に送信されてもよい。これにより、ユーザは、携帯電話１にて探していた曲を聴くことができる。
【００４８】
このようにすることにより、ユーザにとっては、メロディを正確に記憶していない場合であっても、直前の音に比べて、上がるか、下がるか、同音か、さえ間違えなければ、正しく検索することができるため、利便性が向上しうる。また、３値コードの入力で済むため、携帯電話などのキーが小さい装置からも容易に入力でき、検索することができる。特に、３×３に配置された携帯電話のキーでは、縦、横、斜めなどに並んで配列された３つのキーを用いることで、例えば片手で親指をずらして容易に入力することができる。さらに、メロディ検索装置側では、３値符号のマッチングなどによる検索処理を実行すればよいため、処理負荷が軽減される。
【産業上の利用可能性】
【００４９】
本発明は、携帯電話などで再生することが可能な音楽情報を提供する事業者にて、音楽検索サービスを提供するシステムとして利用することができ、産業上の利用可能性を有する。
【図面の簡単な説明】
【００５０】
【図１】携帯電話の構成を示す外観図である。
【図２】携帯電話の構成を示す機能ブロック図である。
【図３】メロディ検索サーバの構成を示す機能ブロック図である。
【図４】携帯電話及びメロディ検索サーバ間におけるメロディ検索時のデータの流れを示す説明図である。
【図５】メロディ検索サーバの動作を示すフローチャートである。
【符号の説明】
【００５１】
１  携帯電話
２  操作部
３  表示部
５  メロディ検索サーバ
１１  送受信処理部
１２  入力受付処理部
１３  表示処理部
１４  メモリ
５１  検索要求受付処理部
５２  メロディ検索処理部
５３  検索結果出力処理部
５４  音楽データベース
【図１】
0004819574.tif 000002
【図２】
0004819574.tif 000003
【図３】
0004819574.tif 000004
【図４】
0004819574.tif 000005
【図５】
0004819574.tif 000006