(57)【要約】【課題】ある局面における目的は、ユーザの嗜好に合致する楽曲を選択する技術を提供することである。【解決手段】サーバ装置（１５０）は、通信インターフェイス（３７０）と、記憶装置（３８０）と、制御部（３６０）とを備える。記憶装置は、楽曲の評価を保持する。制御部は、情報処理端末（１００）が再生した楽曲に関連するユーザの発話内容であって、情報処理端末が取得した発話内容を通信インターフェイスを介して取得し、取得された発話内容に関連する一以上の楽曲の中から、少なくとも一の楽曲を情報処理端末が再生する楽曲として選択し、情報処理端末によって再生された楽曲に対するユーザの応答内容から、選択された楽曲の評価を更新するように構成される。【選択図】図３
2018055440.tif 000002
【特許請求の範囲】
【請求項１】
通信インターフェイスと、
記憶装置と、
制御部とを備え、
前記記憶装置は、楽曲の評価を保持し、
前記制御部は、
情報処理端末が取得した発話内容を前記通信インターフェイスを介して取得し、
前記取得された発話内容に関連する一以上の楽曲の中から、少なくとも一の楽曲を前記情報処理端末が再生する楽曲として選択し、
前記情報処理端末によって再生された楽曲に対するユーザの応答内容から、前記選択された楽曲の評価を更新するように構成される、サーバ装置。
【請求項２】
前記少なくとも一の楽曲を前記情報処理端末が再生する楽曲として選択することは、前記評価に基づいて前記少なくとも一の楽曲を選択することを含む、請求項１に記載のサーバ装置。
【請求項３】
前記評価に基づいて前記少なくとも一の楽曲を選択することは、前記評価に応じた確率に基づいて前記少なくとも一の楽曲を選択することを含む、請求項２に記載のサーバ装置。
【請求項４】
前記発話内容は、ユーザの感情、およびユーザの動作のうち少なくともいずれかを示す単語を含む、請求項１〜３のいずれか１項に記載のサーバ装置。
【請求項５】
前記記憶装置は、
前記楽曲を特定するための特定情報と前記楽曲のジャンルとを互いに関連付けて保持する楽曲管理テーブルと、
前記ジャンルと前記発話内容とを互いに関連付けて保持する応答テーブルとを格納するように構成され、
前記少なくとも一の楽曲を前記情報処理端末が再生する楽曲として選択することは、
前記応答テーブルを参照して前記取得した発話内容に対応するジャンルを特定することと、
前記楽曲管理テーブルを参照して前記特定したジャンルに関連付けられた一以上の楽曲の中から、少なくとも一の楽曲を選択することとを含む、請求項１〜４のいずれか１項に記載のサーバ装置。
【請求項６】
前記制御部は、前記発話内容を取得したことに応じて、ユーザに楽曲を再生するか否かを問い合わせる指示を前記情報処理端末に送信するように構成されており、
前記少なくとも一の楽曲を前記情報処理端末が再生する楽曲として選択することは、前記問い合わせに対するユーザの応答内容に応じて前記少なくとも一の楽曲を選択することを含む、請求項１〜５のいずれか１項に記載のサーバ装置。
【請求項７】
前記制御部は、前記情報処理端末によって楽曲の再生が終了した後にユーザに対して前記再生された楽曲に対する評価を問い合わせる指示を前記情報処理端末に送信するように構成されており、
前記選択された楽曲の評価を更新することは、前記評価の問い合わせに対するユーザの応答内容に応じて、前記選択された楽曲の評価を更新することを含む、請求項１〜６のいずれか１項に記載のサーバ装置。
【請求項８】
前記ユーザの発話内容を取得することは、前記ユーザの発話内容から予め定められた文字列を検出することを含み、
前記少なくとも一の楽曲を前記情報処理端末が再生する楽曲として選択することは、前記文字列に関連付けられた一以上の楽曲の中から、少なくとも一の楽曲を選択することを含む、請求項１〜７のいずれか１項に記載のサーバ装置。
【請求項９】
前記選択された楽曲の評価を更新することは、前記少なくとも一の楽曲に付随するメタデータと、前記再生された楽曲に対するユーザの応答内容とに基づいて、前記選択された楽曲に関連する楽曲の評価を更新することを含む、請求項１〜８のいずれか１項に記載のサーバ装置。
【請求項１０】
前記関連する楽曲は、前記少なくとも一の楽曲に付随するメタデータと共通するメタデータを有する、請求項９に記載のサーバ装置。
【請求項１１】
前記メタデータは、歌手、作詞者、作曲者、および発表年のうち少なくとも１つの情報を含む、請求項９または１０に記載のサーバ装置。
【請求項１２】
前記記憶装置は、前記楽曲について、前記情報処理端末で再生された回数を記憶するように構成され、
前記少なくとも一の楽曲を前記情報処理端末が再生する楽曲として選択することは、前記評価と前記再生された回数とに基づいて、前記少なくとも一の楽曲を選択することを含む、請求項１〜１１のいずれか１項に記載のサーバ装置。
【請求項１３】
前記少なくとも一の楽曲を選択することは、前記再生された回数が多い楽曲ほど、前記少なくとも一の楽曲として選択する確率が高くなることを含む、請求項１２に記載のサーバ装置。
【請求項１４】
前記少なくとも一の楽曲を選択することは、前記再生された回数が少ない楽曲ほど、前記少なくとも一の楽曲として選択する確率が高くなることを含む、請求項１２に記載のサーバ装置。
【請求項１５】
情報処理端末であって、
記憶装置と、
音声入力装置と、
音声出力装置と、
制御部とを備え、
前記記憶装置は、少なくとも一の楽曲と、前記楽曲の評価を保持し、
前記制御部は、
前記情報処理端末のユーザの発話内容を前記音声入力装置から取得し、
前記取得された発話内容に関連する一以上の楽曲の中から、少なくとも一の楽曲を前記音声出力装置によって再生し、
前記再生された楽曲に対するユーザの応答内容から、前記再生された楽曲の評価を更新するように構成される、情報処理端末。
【請求項１６】
音声入力装置、音声出力装置、および記憶装置を含む情報処理端末のコンピュータによって実行される、前記音声出力装置が再生する楽曲を選択するためのプログラムであって、
前記記憶装置は、少なくとも一の楽曲、および前記楽曲の評価を記憶するように構成され、
前記プログラムは、前記コンピュータに、
音声入力装置からユーザの発話内容を取得するステップと、
前記取得された発話内容に関連する一以上の楽曲の中から、少なくとも一の楽曲を選択するステップと、
前記選択した楽曲を前記音声出力装置によって再生するステップと、
前記再生した楽曲に対するユーザの応答を前記音声入力装置によって受け付けるステップと、
前記音声入力装置によって受け付けたユーザの応答に基づいて、前記再生した楽曲の評価を更新するステップとを実行させる、プログラム。
【請求項１７】
情報処理端末と、サーバ装置とを備えるシステムであって、
前記情報処理端末は、
音声入力装置と、
音声出力装置とを含み、
前記サーバ装置は、
通信インターフェイスと、
記憶装置と、
制御部とを備え、
前記記憶装置は、楽曲の評価を保持し、
前記制御部は、
前記情報処理端末が前記音声入力装置により取得した発話内容を前記通信インターフェイスを介して取得し、
前記取得された発話内容に関連する一以上の楽曲の中から、少なくとも一の楽曲を前記音声出力装置が再生する楽曲として選択し、
前記音声出力装置によって再生された前記楽曲に対するユーザの応答内容から、前記選択した楽曲の評価を更新するように構成される、システム。
【請求項１８】
サーバ装置が、情報処理端末が再生する楽曲を選択するための方法であって、
前記サーバ装置は、記憶装置に前記楽曲の評価を保持するように構成され、
前記方法は、
前記情報処理端末のユーザの発話内容を取得するステップと、
前記取得された発話内容に関連する一以上の楽曲の中から、少なくとも一の楽曲を前記情報処理端末が再生する楽曲として選択するステップと、
前記情報処理端末によって再生された楽曲に対するユーザの応答内容から、前記選択された楽曲の評価を更新するステップとを備える、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この開示は、端末で再生される楽曲を選択する技術に関し、より特定的には、ユーザの嗜好を反映して楽曲を選択する技術に関する。
【背景技術】
【０００２】
近年、音楽をＣＤプレイヤー等の再生専用機で楽しむ人は減っている一方、スマートフォンやパソコン等のデジタル機器で音楽を楽しむ人が増えている。このようなデジタル機器を用いて音楽を聴く人は、音楽のみを聴くのではなく、何らかの作業を行いながら音楽を気軽に楽しむことが多い。
【０００３】
ところで、音楽を再生可能なデジタル機器の中には、何らかの情報に基づいてユーザが所望する楽曲を再生するものがある。例えば、特開２００６−０９２４３０号公報（特許文献１）は、「ユーザの発話内容から予め設定されたキーワードを検出し、ユーザの発話内容か抽出したプロソディ情報を分析してユーザの感情情報を検出し、検出したキーワードおよび感情情報からユーザ状況を推定し、雰囲気要因情報収集部が収集した車室内の客観的な情報とユーザの状況とから現在の雰囲気を複数のカテゴリのいずれかに分類し、カテゴリリストから雰囲気推定部により分類されたカテゴリに属する音楽データを検索し、その音楽データを再生する音楽再生装置」を開示している（「要約」参照）。
【０００４】
また、特開２００５−３５２１５１号公報（特許文献２）は、「人間の感情状態に基づいて自動的に音楽出力する音楽出力装置」を開示している。より具体的には、この装置は、「人間の発する音声または活動に伴って生じる活動音を取得し、音響情報として入力する音響情報入力手段と、音響情報から該音響情報の音響スペクトルに係る特徴量を抽出する音響特徴量抽出手段と、それを入力して、状態判断テーブルに基づき音響情報に係る人間の感情状態を判断する状態判断手段と、音楽選択テーブルに基づき音楽を選択する音楽選択手段と、楽曲データから音楽を出力する音楽出力手段とを備える」（「要約」参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−０９２４３０号公報
【特許文献２】特開２００５−３５２１５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記の特許文献に開示される音楽出力（再生）装置は、ユーザのその時の状態を推測し、その推測した状態に適すると推測される音楽を再生するものであって、ユーザによっては、再生された曲がその時のユーザの気分に合致するものではない、ということもあり得る。そのため、よりユーザの嗜好に合致する楽曲を再生するための技術が求められている。
【０００７】
本開示は、上記のような問題を解決するためになされたものであって、ある局面における目的は、ユーザの嗜好に合致する楽曲を選択できるサーバ装置を提供することである。他の局面における目的は、ユーザの嗜好に合致する楽曲を選択できる方法を提供することである。他の局面における目的は、ユーザの嗜好に合致する楽曲を選択できる情報処理端末を提供することである。さらに他の局面における目的は、この情報処理端末で使用されるプログラムを提供することである。他の局面における目的は、ユーザの嗜好に合致する楽曲を選択できるシステムを提供することである。
【課題を解決するための手段】
【０００８】
ある実施形態に従うサーバ装置は、通信インターフェイスと、記憶装置と、制御部とを備える。記憶装置は、楽曲の評価を保持する。制御部は、情報処理端末が再生した楽曲に関連するユーザの発話内容であって、情報処理端末が取得した発話内容を通信インターフェイスを介して取得し、取得された発話内容に関連する一以上の楽曲の中から、少なくとも一の楽曲を情報処理端末が再生する楽曲として選択し、情報処理端末によって再生された楽曲に対するユーザの応答内容から、選択された楽曲の評価を更新するように構成される。
【発明の効果】
【０００９】
ある実施形態に従うサーバ装置は、一以上の楽曲の中から、ユーザの嗜好に合致する楽曲を選択し得る。
【００１０】
この発明の上記および他の目的、特徴、局面および利点は、添付の図面と関連して理解されるこの発明に関する次の詳細な説明から明らかとなるであろう。
【図面の簡単な説明】
【００１１】
【図１】ある実施形態に従う楽曲選択の制御について説明する図である。
【図２】ある実施形態に従う制御システムの構成例について説明する図である。
【図３】ある実施形態に従う端末およびサーバのハードウェア構成例を説明する図である。
【図４】ある実施形態に従う応答ＤＢを説明する図である。
【図５】ある実施形態に従う機器管理テーブルを説明する図である。
【図６】ある実施形態に従う楽曲管理ＤＢを説明する図である。
【図７】ある実施形態に従う評価テーブルのデータ構造を説明する図である。
【図８】ある実施形態に従う評価値の更新制御について説明する図である。
【図９】ある実施形態に従う楽曲を選択する制御について説明する図である。
【図１０】他の実施形態に従う楽曲を選択する制御について説明する図である。
【図１１】上記一連の楽曲を選択する制御について説明するためのフローチャートである。
【図１２】ある実施形態に従うサーバが楽曲を選択する制御、および楽曲の評価値を更新する制御について説明するフローチャートである。
【図１３】ある実施形態に従う制御システムについて説明する図である。
【図１４】ある実施形態に従う機器管理ＤＢについて説明する図である。
【図１５】ある実施形態に従うサーバが楽曲を選択する制御、および楽曲の評価値を更新する制御について説明するフローチャートである。
【図１６】ある実施形態に従う端末の構成例について説明する図である。
【図１７】ある実施形態に従う端末が楽曲を選択する制御、および楽曲の評価値を更新する制御について説明するフローチャートである。
【発明を実施するための形態】
【００１２】
以下、この発明の実施形態について図面を参照しながら詳細に説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。
【００１３】
［技術思想］
図１は、ある実施形態に従う楽曲選択の制御について説明する図である。図１を参照して、ある実施形態に従う制御システム２００は、端末１００とサーバ１５０とを備える。端末１００とサーバ１５０とは、互いに通信可能に構成される。端末１００は、情報処理が可能な端末であり得る。ある実施形態において、端末１００は、掃除機、電子レンジ、冷蔵庫、洗濯機、エアコンディショナ、空気清浄器、炊飯器、テレビ、スマートフォン、タブレット、パーソナルコンピュータ、その他の家庭用電気製品であり得る。図１に示される例において、端末１００は、掃除機（掃除ロボット）であるとする。
【００１４】
ある実施形態において、サーバ１５０は、楽曲データ群３８１と、楽曲管理テーブル１６０と、評価テーブル１７０とを、後述する記憶装置３８０に格納し得る。
【００１５】
楽曲データ群３８１は、１以上の楽曲のデータを保持する。楽曲管理テーブル１６０は、楽曲データ群３８１に保持される一以上の楽曲の各々について、タイトルと発話内容とを互いに関連付けて保持する。
【００１６】
評価テーブル１７０は、楽曲データ群３８１に保持される一以上の楽曲の各々について、タイトルと評価値とを互いに関連付けて保持する。
【００１７】
ある実施形態において、サーバ１５０は、ユーザの発話内容に基づいて、楽曲データ群３８１に保持される一以上の楽曲データの中から一の楽曲データを選択し、選択した一の楽曲データを端末１００に送信する。以下、サーバにおいて一の楽曲データを選択する制御の技術思想について説明する。
【００１８】
ステップＳ１において、ユーザは「集中したいよ」と発話する。
ステップＳ２において、端末１００は、後述するマイク３３５から入力された音声情報をサーバ１５０に送信する。
【００１９】
ステップＳ３において、サーバ１５０は、楽曲管理テーブル１６０を参照して、受信した音声情報から抽出した文字列（すなわち、ユーザの発話内容）に対応するタイトルが「月光」と「愛の夢」であると特定する。
【００２０】
ステップＳ４において、サーバ１５０は、評価テーブル１７０を参照して、特定したタイトル「月光」、「愛の夢」の評価値がそれぞれ「３」、「５」であると特定する。同ステップにおいて、さらにサーバ１５０は、評価値が高い「愛の夢」を一の楽曲として選択し得る。このように、サーバ１５０は、楽曲データ群３８１に保持される一以上の楽曲の中から、端末１００のユーザの発話内容に基づいて、当該発話内容に関連する一の楽曲を選択する。
【００２１】
ステップＳ５において、サーバ１５０は、楽曲データ群３８１にアクセスして、選択した楽曲「愛の夢」のデータ（楽曲データ）を端末１００に送信する。
【００２２】
ステップＳ６において、端末１００は、サーバ１５０から受信した楽曲データを音声出力装置によって再生する。
【００２３】
ステップＳ７において、端末１００は、ユーザに対して再生した楽曲の評価を問い合わせる。ある局面において、端末１００は、ユーザに対して「どうだった？」と発話する。
【００２４】
ステップＳ８において、ユーザは、端末１００に対して再生された楽曲に対する評価を発話する。ある局面において、ユーザは、端末１００に対して「集中できたよ」と発話する。
【００２５】
ステップＳ９において、端末１００は、マイクから入力された音声情報をサーバ１５０に送信する。
【００２６】
ステップＳ１０において、サーバ１５０は、受信した音声情報を解析して、再生された楽曲に対するユーザの評価に基づいて、ステップＳ４で選択した楽曲「愛の夢」の評価を更新する。ある局面において、サーバ１５０は、再生された楽曲「愛の夢」に対するユーザの評価が肯定的であると判断し、評価テーブル１７０に保持されるタイトル「愛の夢」に対応する評価値を大きくし得る。このように、サーバ１５０は、端末１００によって再生された楽曲に対するユーザの応答内容に基づいて、選択された楽曲の評価を更新する。
【００２７】
上記によれば、ある実施形態に従うサーバは、ユーザの発話内容に加え、ユーザの楽曲に対する評価（ユーザの嗜好）も考慮して、ユーザがその時に聞きたいと思われる楽曲を選択する。そのため、このサーバは、従来に比して、よりユーザの嗜好に合致する楽曲を選択し得る。
【００２８】
また、ユーザは、自身の嗜好を選曲に反映させるにあたり、端末からの楽曲評価の問い合わせに対して発話（例えば、「良かったよ」、「いまいち」など）するだけよい。そのため、ユーザは、楽曲評価のための面倒な操作を行なう必要がない。以下、この制御システム２００についての具体的な構成および制御について説明する。
【００２９】
［実施形態１］
図２は、ある実施形態に従う制御システム２００の構成例について説明する図である。図２を参照して、ある実施形態に従う制御システム２００は、端末１００Ａ，１００Ｂ，１００Ｃと、サーバ１５０とを備える。以下、端末１００Ａ、端末１００Ｂ、端末１００Ｃを総称して「端末１００」とも言う。
【００３０】
図２に示される例において、端末１００Ａおよび１００Ｂは掃除機（例えば、掃除ロボット）であって、端末１００Ｃは冷蔵庫である。端末１００はネットワーク２１０を介してサーバ１５０と通信可能に構成される。
【００３１】
なお、図２に示される例において、サーバ１５０は、複数の端末１００と通信可能に構成されるが、他の局面において少なくとも１つの端末１００と通信可能に構成されればよい。
【００３２】
図３は、ある実施形態に従う端末１００およびサーバ１５０のハードウェア構成例を説明する図である。
【００３３】
（端末のハードウェア構成）
端末１００は、ＣＰＵ（Central  Processor  Unit）３１０と、記憶装置３２０と、ＲＡＭ（Random  Access  Memory）３２５と、スピーカ３３０と、マイク３３５と、入力Ｉ／Ｆ３４０と、通信Ｉ／Ｆ３４５とを備える。
【００３４】
ＣＰＵ３１０は、記憶装置３２０に格納される制御プログラムを読み出して実行することにより、端末１００の動作を制御する制御部として機能する。
【００３５】
記憶装置３２０は、典型的にはハードディスクドライブまたはフラッシュメモリであって、ＣＰＵ３１０が実行する制御プログラムと、機器ＩＤ３２４とを記憶する。
【００３６】
機器ＩＤ３２４は、複数の端末１００の各々を識別するための識別情報である。ある局面において、機器ＩＤ３２４は、端末１００（通信Ｉ／Ｆ３４５）のＭＡＣ（Media  Access  Control）アドレスであり得る。
【００３７】
ＲＡＭ３２５は、ＣＰＵ３１０が制御プログラムを実行するために必要なデータを一時的に記憶するワーキングメモリとして機能する。
【００３８】
スピーカ３３０は、音声情報（例えば、楽曲データ）を音声に変換して出力する。他の局面において、端末１００は、スピーカ３３０に替えて、またはスピーカ３３０に加えて、ヘッドフォン，イヤホンその他の音声出力装置を含む構成であってもよい。
【００３９】
マイク３３５は、端末１００の周囲の音声を電気信号としての音声情報に変換してＣＰＵ３１０に入力する。
【００４０】
入力Ｉ／Ｆ３４０は、ユーザの入力を受け付けるためのインターフェイスである。ある局面において、入力Ｉ／Ｆ３４０は、赤外線リモートコントローラ（図示しない）からの入力を受け付ける赤外線受信部であり得る。他の局面において、入力Ｉ／Ｆ３４０は、端末１００に設けられたボタンであり得る。さらに他の局面において、入力Ｉ／Ｆ３４０は、端末１００に設けられたタッチパネルであり得る。
【００４１】
通信Ｉ／Ｆ３４５は、後述するサーバ１５０の通信Ｉ／Ｆ３７０と通信し、各種信号を送受信する。
【００４２】
（サーバのハードウェア構成）
サーバ１５０は、ＣＰＵ３６０と、通信Ｉ／Ｆ３７０と、記憶装置３８０とＲＡＭ３９０とを備える。
【００４３】
ＣＰＵ３６０は、サーバ１５０の動作を制御する制御部として機能する。ある局面において、ＣＰＵ３６０は、記憶装置３８０に格納される制御プログラムを読み出して実行することにより、抽出部３６１、検出部３６３、応答部３６５、選択部３６７、および更新部３６９として機能し得る。
【００４４】
抽出部３６１は、端末１００から受信した音声情報から文字列を抽出する。一例として、抽出部３６１は、音声情報の先頭から所定時間単位（例えば、１０ｍｓｅｃ単位）で区切られる波形データと、記憶装置３８０に格納される音響モデル（母音や子音などの音素ごとに音声の特徴量）とを照合して、音声情報から文字列を抽出する。このとき、音声認識部３６４は、隠れマルコフモデル（ＨＭＭ：Hidden  Markov  Model）に従い音声情報から文字列を抽出し得る。
【００４５】
検出部３６３は、抽出部３６１が抽出した文字列の中に、予め定められたキーワード（文字列）が含まれているか否かを判断する。予め定められたキーワードは、記憶装置３８０に格納される。
【００４６】
応答部３６５は、抽出部３６１が抽出した文字列に応じて、端末１００のユーザに対する発話内容を生成する。
【００４７】
選択部３６７は、後述する楽曲データ群３８１に保持されるに保持される一以上楽曲の中から、端末１００が再生する一の楽曲を選択する。より具体的には、選択部３６７は、検出部３６３が検出したキーワードに関連付けられた一以上の楽曲の中から、これら楽曲の評価に基づいて一の楽曲を選択する。
【００４８】
更新部３６９は、楽曲データ群３８１に保持される複数の楽曲の各々についての評価を、ユーザの応答内容に基づいて更新する。
【００４９】
通信Ｉ／Ｆ３７０は、端末１００と通信するためのインターフェイスであって、一例として、無線ＬＡＮ（Local  Area  Network）カードであるとする。サーバ１５０は、通信Ｉ／Ｆ３７０を介してＬＡＮまたはＷＡＮ（Wide  Area  Network）に接続された端末１００と通信可能に構成される。
【００５０】
記憶装置３８０は、典型的にはハードディスクドライブまたはフラッシュメモリであって、楽曲データ群３８１と、応答ＤＢ（データベース）３８２と、機器管理テーブル３８４と、楽曲管理ＤＢ３８６と、評価テーブル３８８とを格納する。
【００５１】
楽曲データ群３８１は、端末１００によって再生され得る一以上の楽曲データによって構成される。記憶装置３８０に格納されるその他の各種データの詳細は、図４〜図７を用いて後述される。
【００５２】
ＲＡＭ３９０は、典型的には、ＤＲＡＭ（Dynamic  Random  Access  Memory）などであって、ＣＰＵ３６０が制御プログラムを実行するために必要なデータを一時的に記憶するワーキングメモリとして機能する。
【００５３】
なお、図３に示される例では、サーバ１５０は、１つのＣＰＵ３６０と、１つの通信Ｉ／Ｆ３７０と、１つの記憶装置３８０を備える構成であるが、他の局面において、サーバは、これらのデバイスを複数有する構成であってもよい。例えば、サーバは、２つ以上のＣＰＵによって、後述する処理を分散処理してもよい。また、サーバは、２つ以上の通信Ｉ／Ｆによって端末１００と情報の送受信を行ってもよい。また、サーバは、２つ以上の記憶装置を有し、記憶すべきデータを分散して複数の記憶装置に格納してもよい。
【００５４】
（応答ＤＢ）
図４は、ある実施形態に従う応答ＤＢ３８２を説明する図である。図４を参照して、応答ＤＢ３８２は、複数の応答テーブルＲ００１，Ｒ００２，・・・と、問い合わせテーブル４１０とを格納する。
【００５５】
分図（Ａ）は、応答テーブルのデータ構造を説明する図である。応答テーブルは、端末１００（の機器ＩＤ）ごとに管理される。ある局面において、応答ＤＢは、端末１００Ａ（の機器ＩＤ）の応答テーブルＲ００１と、端末１００Ｂの応答テーブルＲ００２と、端末１００Ｃの応答テーブルＲ００３とを含む。
【００５６】
各応答テーブルは、感情ＩＤと、キーワードと、ユーザ状態と、応答フレーズと、ジャンルと、効果ＩＤとを互いに関連付けて保持する。
【００５７】
感情ＩＤは、応答テーブルに登録される複数のキーワードを互いに識別するためのＩＤである。
【００５８】
キーワードは、ある局面において、端末１００のユーザの感情、およびユーザの動作のいずれかを示す単語を含み得る。ユーザ状態は、キーワードに対応するユーザの状態（気分）を示す。
【００５９】
応答フレーズは、キーワードに関連付けられた端末１００のユーザに対する発話内容である。ある局面において、サーバ１５０のＣＰＵ３６０は、検出部３６３として、ユーザの端末１００に対する発話内容に、応答テーブルに保持されるキーワードが含まれているか否かを判断し得る。ＣＰＵ３６０は、応答部３６５として、キーワードが含まれていると判断した場合に、当該キーワードに関連付けられた応答フレーズ（または応答フレーズの音声情報）を端末１００に送信し得る。
【００６０】
ジャンルは、ユーザ状態（気分）に合致し得る音楽のカテゴリである。効果ＩＤは、後述する楽曲の評価を、種類ごとに行なうための識別情報である。
【００６１】
一例として、分図（Ａ）に示される応答テーブルＲ００１において、ユーザの感情を示すキーワード「失敗した」、「つらい」、「くやしい」、「かなしい」、および「さびしい」に対して、ユーザ状態「元気をもらいたい」と、応答フレーズ「おつかれさま。元気が出る歌があるけど、聴いてみる？」とが関連付けられている。これらのキーワードには、ジャンル「ＰＯＰＳ」と、効果ＩＤ「１」とがさらに関連付けられている。
【００６２】
また、ユーザの感情を示すキーワード「気分を変えたい」および「ブルーな気分だ」に対して、ユーザ状態「盛り上がりたい」と、応答フレーズ「おつかれさま。盛り上がれる歌があるけど、聴いてみる？」とが関連付けられている。これらのキーワードには、ジャンル「ＰＯＰＳ」と、効果ＩＤ「２」とがさらに関連付けられている。
【００６３】
ジャンル「ＰＯＰＳ」に効果ＩＤ「１」が関連付けられる場合と、効果ＩＤ「２」が関連付けられる場合とがあるように、一のジャンルに複数の効果ＩＤが関連付けられ得る。
【００６４】
また、上記の例ではキーワードに対して一のジャンルが関連付けられているが、他の局面において、キーワードに対して複数のジャンルが関連付けられてもよい。係る場合、サーバ１５０のＣＰＵ３６０は、選択部３６７として、キーワードに応じた一のジャンルを設定された条件（例えば、ランダム）によって決定し得る。
【００６５】
なお、他の局面において、応答テーブルは、少なくともキーワードと、ジャンルと、効果ＩＤとを互いに関連付けて保持していればよく、感情ＩＤと、ユーザ状態と、応答フレーズとを保持しないデータ構造であってもよい。
【００６６】
また、端末１００のユーザは、入力Ｉ／Ｆ３４０を操作して、またはマイク３３５に対する発話によって、キーワードに関連付けられるジャンルを設定し得る。ある局面において、ジャンルは、図４に示される例の他に、「ブルース」、「演歌」、「ロック」、「パンク」、「ヒップホップ」、「レゲエ」、「ジャズ」、「ミクスチャー」、「カントリー」、「メタル」等を含み得る。
【００６７】
分図（Ｂ）は、問い合わせテーブル４１０を説明する図である。問い合わせテーブル４１０は、効果ＩＤと、ユーザ状態と、応答フレーズとを関連付けて保持する。問い合わせテーブル４１０に保持されるユーザ状態は、端末１００が楽曲を再生した後に推測されるユーザの状態（気分）である。問い合わせテーブル４１０に保持される応答フレーズは、端末１００が再生した楽曲に対するユーザの評価を問い合わせるためのフレーズである。
【００６８】
ある局面において、サーバ１５０は、端末１００Ａに対するユーザの発話内容に「失敗した」が含まれると判断する。この場合、サーバ１５０は、応答テーブルＲ００１を参照して、キーワード「失敗した」に関連付けられるジャンルが「ＰＯＰＳ」であると特定し得る。サーバ１５０は、楽曲データ群３８１に保持される一以上の楽曲データの中から、特定したジャンルの楽曲データを端末１００Ａに送信し得る。また、サーバ１５０は、問い合わせテーブル４１０を参照して、キーワード「失敗した」に関連付けられる効果ＩＤ「１」の応答フレーズ「癒されたかな？」を端末１００に送信し得る。端末１００は、受信した楽曲データを再生し終わった後に、当該応答フレーズをユーザに対して発話し得る。
【００６９】
（機器管理テーブル）
図５は、ある実施形態に従う機器管理テーブル３８４を説明する図である。図５を参照して、機器管理テーブルは、端末１００を識別するための機器ＩＤと、応答テーブルと、楽曲管理テーブルとを互いに関連付けて保持する。換言すれば、機器管理テーブルは、端末１００（の機器ＩＤ）ごとに、応答テーブルと、楽曲管理テーブルとを保持する。楽曲管理テーブルは、端末１００の楽曲データ３２２に記憶される複数の楽曲の各々について、メタデータと、評価とを記憶するためのテーブルである。楽曲管理テーブルのデータ構造は、図６を用いて後述される。
【００７０】
図５に示される例において、機器ＩＤ「Ｄ００１」の端末１００には、応答テーブルＲ００１と、楽曲管理テーブルＭ００１とが設定される。機器ＩＤ「Ｄ００２」の端末１００には、応答テーブルＲ００２と、楽曲管理テーブルＭ００２とが設定される。機器ＩＤ「Ｄ００３」の端末１００には、応答テーブルＲ００３と、楽曲管理テーブルＭ００３とが設定される。
【００７１】
（楽曲管理ＤＢ）
図６は、ある実施形態に従う楽曲管理ＤＢ３８６を説明する図である。楽曲管理ＤＢ３８６は、複数の楽曲管理テーブルＭ００１，Ｍ００２，・・・を格納する。楽曲管理テーブルは、端末１００（の機器ＩＤ）ごとに管理されるテーブルである。
【００７２】
各楽曲管理テーブルは、楽曲データ群３８１に保持される複数の楽曲の各々について、楽曲ＩＤと、楽曲に付随するメタデータと、楽曲の評価値とを互いに関連付けて保持する。楽曲ＩＤは、楽曲を特定するための識別情報である。ある局面において、楽曲管理テーブルは、楽曲データ群３８１に保持されるすべての楽曲についてのデータを管理する。この場合、例えば、楽曲管理テーブルＭ００１で管理される楽曲（楽曲ＩＤ）と、楽曲管理テーブルＭ００２で管理される楽曲とが一致する。他の局面において、楽曲管理テーブルは、楽曲データ群３８１に保持される楽曲のうち、任意の楽曲についてのデータを管理する。この場合、例えば、楽曲管理テーブルＭ００１で管理される楽曲と、楽曲管理テーブルＭ００２で管理される楽曲とが相違し得る。
【００７３】
ある局面において、メタデータは、楽曲についての、タイトルと、アーティスト（歌手）と、作詞者と、作曲者と、発表年と、ジャンル（カテゴリ）とを含み得る。他の局面において、メタデータは、楽曲についての再生回数、タイアップ情報、テンポ、周波数、楽曲が収録されるアルバム名、および楽曲の長さ等を含み得る。
【００７４】
楽曲の評価値は、上記説明した効果ＩＤごとに設定される。ある局面において、効果ＩＤごとに設定される各評価値は、自然数（１以上の整数）となるように設定され得る。これにより、評価値が「０」となって選ばれる可能性のなくなる楽曲が存在することを防ぎ得る。
【００７５】
図６に示される例において、タイトル「○○」の楽曲は、効果ＩＤ「１」（ユーザ状態「癒された」）の評価値が「３」に設定され、効果ＩＤ「２」（ユーザ状態「リフレッシュできた」）の評価値が「４」に設定され、その他の効果ＩＤの評価値が「０」に設定されている。
【００７６】
（評価テーブル）
図７は、ある実施形態に従う評価テーブル３８８のデータ構造を説明する図である。図７を参照して、評価テーブル３８８は、評価ＩＤと、評価フレーズと、応答フレーズと、更新値（再生楽曲）と、更新値（関連楽曲）とを互いに関連付けて保持する。
【００７７】
評価ＩＤは、評価テーブル３８８に登録される複数の評価フレーズを互いに識別するための識別情報である。
【００７８】
評価フレーズは、再生された楽曲の評価の問い合わせ（図４で説明した問い合わせテーブル４１０の応答フレーズ）に対して想定される、ユーザの発話内容であり得る。
【００７９】
評価テーブル３８８に保持される応答フレーズは、評価フレーズに関連付けられた端末１００のユーザに対する発話内容である。
【００８０】
更新値は、楽曲管理テーブルに保持される楽曲の評価値を更新するための値である。換言すれば、更新値は、更新前の評価値と更新後の評価値との差分を定義する値である。更新値（再生楽曲）は、楽曲管理テーブルに保持される楽曲のうち、再生された楽曲に関連付けられた評価値を更新するための値である。更新値（関連楽曲）は、当該再生された楽曲に関連する楽曲に関連付けられた評価値を更新するための値である。
【００８１】
図７に示される例において、再生した楽曲に対して極めて肯定的な評価フレーズ「癒された」、「リフレッシュできた」、「リラックスできた」、「ストレス発散できた」、「好き」、「良かった」および「さすが」に対して更新値（再生楽曲）「＋３」と、更新値（関連楽曲）「＋１」とが設定されている。また、やや肯定的な評価フレーズ「少し癒された」、「少しリフレッシュできた」、「少しリラックスできた」、「少しストレス発散できた」、「それなり」、「まあまあ」および「普通」に対して、更新値（再生楽曲）「＋１」と、更新値（関連楽曲）「０」とが設定されている。
【００８２】
一方で、再生した楽曲に対して極めて否定的な評価フレーズ「癒されなかった」、「リフレッシュできなかった」、「リラックスできなかった」、「ストレス発散できなかった」、「嫌い」、「だめ」および「わかってない」に対して、更新値（再生楽曲）「−３」と、更新値（関連楽曲）「−１」とが設定されている。なお、図７において図示していないが、やや否定的な評価フレーズに対して更新値（再生楽曲）「−１」と、更新値（関連楽曲）「０」とが設定され得る。
【００８３】
次に、楽曲管理テーブルに保持される評価値を、評価テーブルに保持される更新値に基づいて更新する制御について説明する。
【００８４】
（評価値の更新制御）
図８は、ある実施形態に従う評価値の更新制御について説明する図である。分図（Ａ）は更新前の楽曲管理テーブルを、分図（Ｂ）は更新後の楽曲管理テーブルをそれぞれ表す。
【００８５】
図８に示される例において、ユーザが「失敗した」と端末１００に対して発話し、それに応じて端末１００がタイトル「○○」の楽曲を再生したとする。また、ユーザは、再生された楽曲に対して「良かったよ」と発話したとする。
【００８６】
サーバ１５０のＣＰＵ３６０は、応答部３６５として、応答テーブルを参照してキーワード「失敗した」に関連付けられる効果ＩＤが「１」であると特定する。次に、サーバ１５０のＣＰＵ３６０は、更新部３６９として、評価テーブル３８８を参照して、ユーザの発話内容に評価フレーズ「良かった」が含まれていると判断するとともに、当該評価フレーズの更新値（再生楽曲）が「＋３」、更新値（関連楽曲）が「＋１」であると特定する。次に、更新部３６９は、楽曲管理テーブルにアクセスして、再生した楽曲「○○」の効果ＩＤ「１」の評価値に「３」を加算する。その結果、楽曲「○○」の効果ＩＤ「１」の評価値は「４」から「７」に更新される。なお、更新部は、上記のように既に評価された楽曲の評価値を変更する制御に加え、ユーザからの評価を受けていない楽曲の評価値（初期値、例えば「０」）も変更するように構成される。
【００８７】
次に、更新部３６９は、再生した楽曲「○○」に関連する楽曲が、楽曲管理テーブルの中に存在するか否かを判断する。ある局面において、更新部３６９は、再生した楽曲のメタデータと共通するメタデータを有する楽曲を、再生した楽曲に関連する楽曲として特定し得る。
【００８８】
図８に示される例において、タイトル「○○」の楽曲と、タイトル「○×」の楽曲とは、アーティスト、作詞者、および作曲者が共通する。これにより、更新部３６９は、再生した楽曲「○○」に関連する楽曲として、タイトル「○×」の楽曲を特定し得る。更新部３６９は、楽曲管理テーブルにおける、関連する楽曲「○×」のＩＤ「１」の評価値に「１」を加算する。その結果、楽曲「○×」の効果ＩＤ「１」の評価値は「３」から「４」に更新される。
【００８９】
ある局面において、楽曲データ群３８１に新たな楽曲が追加され得る。これに伴い、楽曲管理テーブルに、新たな楽曲の評価値が登録される。この新たな楽曲についての評価値の登録について説明する。
【００９０】
サーバ１５０は、楽曲データ群３８１に新たな楽曲が追加されると、当該新たな楽曲に関連する楽曲が、楽曲管理テーブルに登録されているか否かを判断する。ある局面において、新たな楽曲に関連する楽曲は、新たな楽曲のメタデータと共通するメタデータを有する。
【００９１】
サーバ１５０は、関連する楽曲があると判断した場合、当該関連する楽曲の評価履歴に基づいて、新たな楽曲の評価値を設定し得る。一例として、関連する楽曲が過去に効果ＩＤ「１」として３回再生され、ユーザが極めて肯定的な評価を２回行い、やや否定的な評価を１回行ったとする。この場合、サーバ１５０は、評価テーブル３８８を参照して、極めて肯定的な評価フレーズに対する更新値（関連楽曲）が「＋１」であると特定し、やや否定的な評価フレーズに対する更新値（関連楽曲）が「０」であると特定し得る。サーバ１５０は、特定した更新値（関連楽曲）に基づき、新たな楽曲の効果ＩＤ「１」の初期評価値（例えば「０」）に「２」を加えて登録し得る。
【００９２】
上記によれば、サーバ１５０は、新たな楽曲を楽曲管理テーブルに登録する際、関連する楽曲の評価履歴、すなわち、ユーザの嗜好を反映して登録し得る。
【００９３】
なお、他の局面において、サーバ１５０は、新たな楽曲のジャンルと同じジャンルに属する楽曲の評価値の平均値を、新たな楽曲の評価値として楽曲管理テーブルに登録し得る。これにより、後述する楽曲の選択制御によって新たな楽曲が選択される確率が、当該ジャンルにおいて平均値となり得る。
【００９４】
さらに他の局面において、サーバ１５０は、新たな楽曲のジャンルと同じジャンルに属するいずれの楽曲の評価値よりも高い値を、新たな楽曲の評価値として楽曲管理テーブルに登録し得る。これにより、楽曲の選択制御によって新たな楽曲が選択される確率が、当該新たな楽曲のジャンルに属する楽曲の中で最も高くなり得る。
【００９５】
次に、楽曲の評価値に基づいて、複数の楽曲の中から一の楽曲を選択するための制御について説明する。
【００９６】
（楽曲の選択制御）
図９は、ある実施形態に従う楽曲を選択する制御について説明する図である。ある局面において、ユーザが「失敗した」と端末１００に対して発話したとする。サーバ１５０のＣＰＵ３６０は、選択部３６７として、応答テーブルを参照して、キーワード「失敗した」に関連付けられるジャンルが「ＰＯＰＳ」、効果ＩＤが「１」であるとそれぞれ特定する。
【００９７】
次に、選択部３６７は、楽曲管理テーブルを参照して、ジャンル「ＰＯＰＳ」に関連付けられる楽曲のタイトルと、当該楽曲の効果ＩＤ「１」の評価値とをそれぞれ特定する。
【００９８】
分図（Ａ）に示される例において、選択部３６７は、ジャンル「ＰＯＰＳ」に関連付けられる楽曲のタイトルが「ＡＡＡ」、「ＢＢＢ」、「ＣＣＣ」、「ＤＤＤ」であると特定するとともに、これらの楽曲の効果ＩＤ「１」の評価値がそれぞれ「２０」、「１０」、「２５」、「５」であると特定する。
【００９９】
次に、選択部３６７は、これら楽曲の各々について、評価値を積算した合計値（６０＝２０＋１０＋２５＋５）に対する自身の評価値の割合を算出する（分図（Ｂ））。一例として、選択部３６７は、楽曲「ＡＡＡ」について、合計値「６０」に対する評価値「２０」の割合が「３３％」であると算出する。なお、ある局面において、評価値が負の値の場合もあり得る。この場合、選択部３６７は、負の評価値を「０」として計算し得る。また、ある局面において、評価値がすべて「０」の場合（例えば、初期状態）もあり得る。この場合、選択部３６７は、ランダムに一の楽曲を選択し得る。ある局面において、各楽曲の評価値の初期値が「１０」に設定され得る。これは、初期値がすべて「０」に設定されると、特定の楽曲のみを再生する可能性が高まるためである。
【０１００】
次に、選択部３６７は、これら算出した割合を確率として、４曲の中から一の楽曲を選択する。分図（Ｂ）に示される例において、楽曲「ＣＣＣ」が選ばれる確率が最も高く、楽曲「ＤＤＤ」が選ばれる確率が最も低い。
【０１０１】
上記によれば、選択部３６７は、再生した楽曲に対するユーザの応答によって定まる評価値に基づいて、楽曲データ群３８１に保持される一以上の楽曲の中から一の楽曲を選択し得る。
【０１０２】
図１０は、他の実施形態に従う楽曲を選択する制御について説明する図である。図９の例では、選択部３６７は、楽曲の評価値に基づいて一の楽曲を選択する構成であった。他の局面において、選択部３６７は、楽曲の評価値に加え、さらに楽曲の再生回数を考慮して、一の楽曲を選択し得る。この場合、各楽曲管理テーブルは、管理する楽曲（楽曲ＩＤ）の各々について、機器ＩＤに対応する端末１００で再生された回数を保持する。
【０１０３】
分図（Ａ）に示される例において、選択部３６７は、ジャンル「ＰＯＰＳ」に関連付けられる楽曲のタイトルが「ＡＡＡ」、「ＢＢＢ」、「ＣＣＣ」、「ＤＤＤ」であると特定するとともに、これらの楽曲の効果ＩＤ「１」の評価値がそれぞれ「２０」、「１０」、「２５」、「５」、再生回数がそれぞれ「１０」、「６」、「１５」、「３」であると特定する。次に、選択部３６７は、各楽曲について、評価値を再生回数で割った指標値を算出する。一例として、選択部３６７は、楽曲「ＡＡＡ」について、指標値が「２．０」（＝２０÷１０）であると算出する。なお、ある局面において、再生回数が「０」の場合もあり得る。この場合、選択部３６７は、再生回数を「１」として計算し得る。
【０１０４】
次に、選択部３６７は、各楽曲について、指標値を積算した合計値（７．１＝２．０＋１．７＋１．７＋１．７）に対する自身の指標値の割合を算出する（分図（Ｂ））。一例として、選択部３６７は、楽曲「ＡＡＡ」について、合計値「７．１」に対する指標値「２．０」の割合が「２８％」であると算出する。
【０１０５】
次に、選択部３６７は、これら算出した割合を確率として、４曲の中から一の楽曲を選択する。分図（Ｂ）に示される例において、楽曲「ＡＡＡ」が選ばれる確率が最も高い。
【０１０６】
上記によれば、再生回数が少ない楽曲ほど選択される確率が高くなる。これにより、サーバ１５０は、ユーザがいつも同じ楽曲を聴く可能性を低減し得る。換言すれば、サーバ１５０は、ユーザの端末１００が再生する楽曲に対する飽きを抑制し得る。
【０１０７】
他の局面において、選択部３６７は、再生回数が多い楽曲ほど選択する確率が高くなるように構成されてもよい。一例として、選択部３６７は、評価値を再生回数で割るのではなく、評価値と再生回数とを乗する、または評価値に再生回数を加算するように構成され得る。これにより、サーバ１５０は、再生回数が多い楽曲、すなわち、ユーザの好きな楽曲をより選択しやすくなる。
【０１０８】
（制御の流れ）
図１１は、上記一連の楽曲を選択する制御について説明するためのフローチャートである。図１１に示される処理は、ＣＰＵ３１０およびＣＰＵ３６０が各々の記憶装置に格納される制御プログラムを実行することにより実現される。
【０１０９】
ステップＳ１１０５において、ユーザは端末１００のマイク３３５に対して発話する。ステップＳ１１１０において、端末１００のＣＰＵ３１０は、マイク３３５から入力された音声情報を、自身の機器ＩＤ３２４とともにサーバ１５０に送信する。
【０１１０】
ステップＳ１１１５において、サーバ１５０のＣＰＵ３６０は、受信した音声情報から文字列を抽出する。ステップＳ１１２０において、ＣＰＵ３６０は、抽出した文字列（ユーザの発話内容）から、応答テーブルに保持される予め定められた文字列（キーワード）を検出する。
【０１１１】
ステップＳ１１２５において、ＣＰＵ３６０は、楽曲を再生するか否かを問い合わせる問合せ指示を端末１００に送信する。より具体的には、ＣＰＵ３６０は、応答テーブルを参照して、検出したキーワードに関連付けられた応答フレーズ（問い合わせ）を音声合成した音声情報を端末１００に送信する。なお、他の局面において、ＣＰＵ３６０は、応答フレーズをテキストデータとして端末１００に送信し、ＣＰＵ３１０は、受信したテキストデータを音声合成するように構成されてもよい。
【０１１２】
ステップＳ１１３０において、ＣＰＵ３１０は、楽曲を再生するか否かを問い合わせる音声情報をスピーカ３３０によって出力する。ステップＳ１１３５において、ユーザは、この問い合わせに対する応答をマイク３３５に対して行なう。
【０１１３】
ステップＳ１１４０、ステップＳ１１４５に示される処理は、上記説明したステップＳ１１１０、ステップＳ１１１５の処理とそれぞれ同じであるため、繰り返し説明しない。
【０１１４】
ステップＳ１１５０において、ＣＰＵ３６０は、抽出した文字列を解析して、ステップＳ１１３５においてユーザが楽曲を再生する旨の応答を行なったと判断する。同ステップにおいて、さらにＣＰＵ３６０は、ステップＳ１１２０で検出したキーワードと、楽曲の評価値とに基づいて、楽曲管理テーブルに保持される複数の楽曲の中から、一の楽曲を選択する。
【０１１５】
ステップＳ１１５５において、ＣＰＵ３６０は、楽曲データ群３８１に保持される楽曲データの中から、選択した一の楽曲に対応する楽曲データ（音声情報）を端末１００に送信する。
【０１１６】
ステップＳ１１６０において、ＣＰＵ３１０は、サーバ１５０から受信した楽曲データをスピーカ３３０によって再生する。ある局面において、ＣＰＵ３１０は、サーバ１５０から楽曲データを受信した後に当該楽曲データを再生する方式を採用し得る。他の局面において、ＣＰＵ３１０は、サーバ１５０からの楽曲データの受信処理と、当該楽曲データの再生処理とを並行して行なうストリーミング方式を採用し得る。
【０１１７】
ステップＳ１１６５において、ＣＰＵ３６０は、再生した楽曲の評価を問い合わせる評価指示を端末１００に送信する。より具体的には、ＣＰＵ３６０は、問い合わせテーブル４１０を参照して、再生した楽曲の効果ＩＤに対応する応答フレーズ（問い合わせ）を音声合成した音声情報を端末１００に送信する。ある局面において、ＣＰＵ３６０は、端末１００が楽曲の再生を終了した後にユーザに対して評価を問い合わせるように、端末１００に対して評価指示を送信する。
【０１１８】
ステップＳ１１７０において、ＣＰＵ３１０は、楽曲の評価を問い合わせる音声情報をスピーカ３３０によって出力する。ステップＳ１１７５において、ユーザは、この問い合わせに対する応答をマイク３３５に対して行なう。
【０１１９】
ステップＳ１１８０、ステップＳ１１８５に示される処理は、上記説明したステップＳ１１１０、ステップＳ１１１５の処理とそれぞれ同じであるため、繰り返し説明しない。
【０１２０】
ステップＳ１１９０において、ＣＰＵ３６０は、抽出した文字列と、評価テーブル３８８とに基づいて、再生された楽曲および関連する楽曲の評価値を更新する。次に、図１１におけるサーバ１５０の処理を図１２を用いて、より詳細に説明する。
【０１２１】
図１２は、ある実施形態に従うサーバ１５０が楽曲を選択する制御、および楽曲の評価値を更新する制御について説明するフローチャートである。図１２に示される処理は、ＣＰＵ３６０が記憶装置３８０に格納される制御プログラムを実行することにより実現される。なお、図１２に示される一連の処理は、機器ＩＤ「Ｄ００１」に設定される端末１００Ａから音声情報を受信したことにより実行されるものとする。
【０１２２】
ステップＳ１２０５において、ＣＰＵ３６０は、抽出部３６１として、端末１００Ａから受信した音声情報から文字列を抽出する。
【０１２３】
ステップＳ１２１０において、ＣＰＵ３６０は、機器管理テーブル３８４を参照して、受信した機器ＩＤ「Ｄ００１」に対応する応答テーブルＲ００１と、楽曲管理テーブルＭ００１とを特定する。
【０１２４】
ステップＳ１２１５において、ＣＰＵ３６０は、検出部３６３として、ステップＳ１２０５で抽出した文字列（ユーザの発話内容）に、応答テーブルＲ００１に保持される予め定められた文字列（キーワード）が含まれているか否かを判断する。
【０１２５】
ＣＰＵ３６０は、ユーザの発話内容にキーワードが含まれていると判断した場合（ステップＳ１２１５においてＹＥＳ）、処理をステップＳ１２２０に進める。そうでない場合（ステップＳ１２１５においてＮＯ）、ＣＰＵ３６０は、処理をステップＳ１２２５に進める。
【０１２６】
ステップＳ１２２０において、ＣＰＵ３６０は、応答テーブルＲ００１を参照して、検出したキーワードに関連付けられた応答フレーズを音声合成した音声情報（問い合わせ指示）を端末１００に送信する。
【０１２７】
ステップＳ１２２５において、ＣＰＵ３６０は、ステップＳ１２０５で抽出した文字列に応答する応答フレーズを音声合成した音声情報を端末１００に送信する。一例として、ＣＰＵ３６０は、抽出した文字列「おはよう」に応答する応答フレーズ「おはよう」を音声合成した音声情報を端末１００に送信し得る。
【０１２８】
ステップＳ１２３０において、ＣＰＵ３６０は、ステップＳ１２２０の問い合わせに対するユーザの応答である音声情報を端末１００から受信する。
【０１２９】
ステップＳ１２３５において、ＣＰＵ３６０は、楽曲を再生する否かを判断する。より具体的には、ＣＰＵ３６０は、受信した音声情報を解析して、ステップＳ１２２０の問い合わせに対するユーザの応答が、肯定的であるか、または否定的であるかを判断する。
【０１３０】
一例として、ステップＳ１２２０の問い合わせ（例えば、「歌でも聴いてみる？」）に対するユーザの応答が「うん」、「いいね」、「宜しく」、「はい」、「イエス」などの肯定的な単語を含む場合に、ＣＰＵ３６０はユーザの応答が肯定的であると判断し得る。一例として、ユーザの応答が「いや」、「結構です」、「いいや」、「ノー」などの否定的否単語を含む場合に、ＣＰＵ３６０はユーザの応答が否定的であると判断し得る。
【０１３１】
ＣＰＵ３６０は、ユーザの応答が肯定的であった場合に楽曲を再生すると判断して（ステップＳ１２３５においてＹＥＳ）、処理をステップＳ１２４０に進める。一方、ＣＰＵ３６０は、ユーザの応答が否定的であった場合に楽曲を再生しないと判断して（ステップＳ１２３５においてＮＯ）、処理をステップＳ１２４５に進める。
【０１３２】
ステップＳ１２４０において、ＣＰＵ３６０は、選択部３６７として、楽曲管理テーブルＭ００１から一の楽曲を選択する。より具体的には、選択部３６７は、応答テーブルＲ００１を参照して、ステップＳ１２１５で検出したキーワードに関連付けられるジャンルと効果ＩＤとを特定する。次に、選択部３６７は、楽曲管理テーブルＭ００１に保持される楽曲のうち、上記特定したジャンルに属する楽曲を抽出する。選択部３６７は、抽出した一以上の楽曲の中から、上記特定した効果ＩＤに対応するこれらの楽曲の評価値に基づいて、一の楽曲を選択する。ＣＰＵ３６０は、楽曲データ群３８１にアクセスして、選択した一の楽曲に対応する楽曲データ（音声情報）を端末１００に送信する。
【０１３３】
なお、他の局面において、ＣＰＵ３６０は、選択した楽曲の情報とともに、肯定的なユーザの応答に対する端末１００の発話内容（例えば、「ＯＫ！○○を歌うね！」）を端末１００に送信するように構成されてもよい。
【０１３４】
ステップＳ１２４５において、ＣＰＵ３６０は、否定的なユーザの応答に対する端末１００の発話内容（応答フレーズ）を端末１００に送信する。一例として、ＣＰＵ３６０は、「そっか・・・じゃあまた今度だね」を音声合成した声を出力するための音声情報を端末１００に送信し得る。
【０１３５】
ステップＳ１２５０において、ＣＰＵ３６０は、応答部３６５として、再生した楽曲の評価を問い合わせる評価指示を端末１００に送信する。より具体的には、応答部３６５は、問い合わせテーブル４１０を参照して、ステップＳ１２４０で特定した効果ＩＤに対応する応答フレーズ（問い合わせ）を音声合成した声を出力するための音声情報を端末１００に送信する。
【０１３６】
ステップＳ１２５５において、ＣＰＵ３６０は、ステップＳ１２５０の問い合わせに対するユーザの応答である音声情報を端末１００から受信する。
【０１３７】
ステップＳ１２６０において、ＣＰＵ３６０は、更新部３６９として、受信した音声情報に基づいて再生された楽曲および関連する楽曲の評価値を更新する。より具体的には、更新部３６９は、受信した音声情報から文字列を抽出するとともに、評価テーブル３８８を参照して当該文字列に含まれる評価フレーズを特定する。
【０１３８】
更新部３６９は、特定した評価フレーズに関連付けられた更新値（再生楽曲）と、更新値（関連楽曲）とを特定する。更新部３６９は、楽曲管理テーブルＭ００１にアクセスして、再生された楽曲（選択した一の楽曲）のステップＳ１２４０で特定した効果ＩＤの評価値を、更新値（再生楽曲）に基づいて更新する。
【０１３９】
更新部３６９はさらに、楽曲管理テーブルＭ００１にアクセスして、再生された楽曲に関連する楽曲があるか否かを判断し、あると判断した場合に、関連する楽曲のステップＳ１２４０で特定した効果ＩＤの評価値を、更新値（関連楽曲）に基づいて更新する。
【０１４０】
上記によれば、ある実施形態に従うサーバは、ユーザの発話内容に加え、ユーザの楽曲に対する評価（ユーザの嗜好）も考慮して、ユーザがその時に聞きたいと思われる楽曲を選択する。そのため、このサーバは、従来に比して、よりユーザの嗜好に合致する楽曲を選択し得る。
【０１４１】
また、ユーザは、自身の嗜好を選曲に反映させるにあたり、端末からの楽曲評価の問い合わせに対して発話（例えば、「良かったよ」、「いまいち」など）するだけよい。そのため、ユーザは、楽曲評価のための面倒な操作を行なう必要がない。
【０１４２】
［実施形態２］
上記の実施形態において、サーバ１５０は、端末１００（の機器ＩＤ）ごとに、応答テーブルと、楽曲管理テーブルとを管理（保持）する構成であった。しかしながら、ある局面において、端末１００（例えば、冷蔵庫）を複数のユーザで使用することも考えられる。係る場合、複数のユーザの各々の嗜好に応じて楽曲を選択することが望ましい。以下では、端末１００を複数のユーザで使用する場合であっても、複数のユーザの各々の嗜好を反映して楽曲を選択できる制御システムについて説明する。
【０１４３】
図１３は、ある実施形態に従う制御システム１３００について説明する図である。なお、図３と同一符号を付している部分については同じであるため、その部分についての説明は繰り返さない。
【０１４４】
図１３を参照して、制御システム１３００は、端末１００と、サーバ１３５０とを備える。サーバ１３５０のハードウェア構成は、サーバ１５０のハードウェア構成と同じであるが、内部に記憶するデータが異なる。
【０１４５】
サーバ１３５０のＣＰＵ３６０は、記憶装置３８０に格納される制御プログラムを読み出して実行することにより、認証部１３６０としてさらに機能し得る。記憶装置３８０は、機器管理テーブル３８４に替えて、機器管理ＤＢ１３８４を含む。
【０１４６】
図１４は、ある実施形態に従う機器管理ＤＢ１３８４について説明する図である。機器管理ＤＢ１３８４は、関連付けテーブル１４２０と、ユーザテーブル１４４０とを格納する。
【０１４７】
分図（Ａ）は、ある実施形態に従う関連付けテーブル１４２０のデータ構造を説明する図である。分図（Ａ）を参照して、関連付けテーブル１４２０は、機器ＩＤと、ユーザＩＤとを互いに関連付けて保持する。ユーザＩＤは、端末１００の複数ユーザの各々を互いに識別するための識別情報である。
【０１４８】
分図（Ｂ）は、ある実施形態に従うユーザテーブル１４４０のデータ構造を説明する図である。ユーザテーブル１４４０は、ユーザＩＤと、特徴量と、応答テーブルと、楽曲管理テーブルとを互いに関連付けて保持する。
【０１４９】
特徴量は、ユーザの音声を変換した音声情報から抽出される特徴である。特徴量の算出方法は、線形予測符号ケプストラム係数（ＬＰＣＣＣ：Linear  Predictive  Coding  Cepstrum  Coefficient）や、メル周波数ケプストラム係数（ＭＦＣＣ：Mel-Frequency  Cepstrum  Coefficient）等の既知の手法を用いることができる。
【０１５０】
このように、ある実施形態に従うサーバ１３５０は、キーワードに対するジャンルを定義する応答テーブルと、楽曲の評価値を保持する楽曲管理テーブルとをユーザごとに管理する。
【０１５１】
ある局面において、サーバ１３５０は、端末１００から音声情報を受信すると、この音声情報から得られる特徴量と、ユーザテーブルに格納される複数の特徴量の各々とを比較して、一致度が所定値以上のものがない場合に、新たなユーザとして登録し得る。その際、サーバ１３５０は、端末１００からユーザに、ユーザの名前を問い合わせ、当該ユーザの名前もユーザテーブルにさらに格納し得る。
【０１５２】
また、ある局面において、楽曲管理テーブルは、楽曲データ群３８１に保持される楽曲のうち、任意の楽曲についてのデータを管理する。例えば、楽曲管理テーブルは、対応するユーザがサーバ１３５０にアップロードした楽曲だけを管理し得る。他の例において、ユーザは、入力Ｉ／Ｆ３４０を操作して、またはマイク３３５に対する発話によって、楽曲データ群３８１に保持される楽曲の中から楽曲管理テーブルで管理する楽曲を選択し得る。これにより、サーバ１３５０は、ユーザテーブル１４４０に登録される複数のユーザの各々に応じた楽曲を選択し得る。
【０１５３】
図１５は、ある実施形態に従うサーバ１３５０が楽曲を選択する制御、および楽曲の評価値を更新する制御について説明するフローチャートである。図１５に示される処理は、ＣＰＵ３６０が記憶装置３８０に格納される制御プログラムを実行することにより実現される。図１５に示される一連の処理は、機器ＩＤ「Ｄ００１」に設定される端末１００Ａから音声情報を受信したことにより実行されるものとする。なお、図１２と同一符号を付している部分については同じ処理であるため、その部分についての説明は繰り返し説明しない。
【０１５４】
ステップＳ１５１０において、ＣＰＵ３６０は、端末１００Ａから受信した音声情報に対応する発話者を特定する。より具体的には、ＣＰＵ３６０は、関連付けテーブル１４２０を参照して、受信した機器ＩＤ「Ｄ００１」に対応するユーザＩＤが「Ｕ００１」と、「Ｕ００２」であると特定する。次に、ＣＰＵ３６０は、ユーザテーブル１４４０を参照して、受信した音声情報から得られる特徴量と、特定した２つのユーザＩＤに対応する特徴量の各々とを比較して、最も一致度が高い特徴量のユーザＩＤを特定する。図１５に示される例において、ＣＰＵ３６０は、最も一致度が高い特徴量のユーザＩＤが「Ｕ００１」であると特定する。
【０１５５】
ステップＳ１５２０において、ＣＰＵ３６０は、ユーザテーブル１４４０を参照して、特定したユーザＩＤ「Ｕ００１」に対応する応答テーブルＲ００１と、楽曲管理テーブルＭ００１とを特定する。
【０１５６】
これにより、ある実施形態に従うサーバ１３５０は、ユーザごとに管理される楽曲の評価値（楽曲管理テーブル）に基づいて、ユーザの嗜好に合致する一の楽曲を選択し得る。そのため、ある実施形態に従うサーバ１３５０は、端末１００を複数のユーザで使用する場合であっても、複数のユーザの各々の嗜好を反映して楽曲を選択し得る。
【０１５７】
［実施形態３］
上記の実施形態では、端末１００は、サーバに音声情報を送信して、サーバから選択された楽曲の楽曲データを受信する構成であった。しかしながら、ネットワーク環境が劣悪な場合など、サーバが楽曲を選択することが難しい場合もあり得る。そこで、ある実施形態に従う端末は、楽曲データ群を自身で保持し、再生する楽曲を自身で決定するように構成される。
【０１５８】
図１６は、ある実施形態に従う端末１６００の構成例について説明する図である。なお、図３と同一符号を付している部分については同じであるため、その部分についての説明は繰り返さない。
【０１５９】
端末１６００のハードウェア構成は、通信Ｉ／Ｆ３４５を有さない点において、図３で説明した端末１００のハードウェア構成と相違する。
【０１６０】
ＣＰＵ３１０は、記憶装置３２０に格納される制御プログラムを読み出して実行することにより、抽出部１６１１、検出部１６１３、応答部１６１５、選択部１６１７、および更新部１６１９として機能し得る。これらは、図３で説明した抽出部３６１、検出部３６３、応答部３６５、選択部３６７、更新部３６９とそれぞれ実質的に同じ機能を有し得る。
【０１６１】
記憶装置３２０は、楽曲データ群３８１と、応答テーブルＲ００１と、問い合わせテーブル４１０と、楽曲管理テーブルＭ００１と、評価テーブル３８８とをさらに格納し得る。
【０１６２】
図１７は、ある実施形態に従う端末１６００が楽曲を選択する制御、および楽曲の評価値を更新する制御について説明するフローチャートである。図１７に示される処理は、ＣＰＵ３１０が記憶装置３２０に格納される制御プログラムを実行することにより実現される。
【０１６３】
ステップＳ１７０５において、ＣＰＵ３１０は、抽出部１６１１として、マイク３３５から入力された音声情報から文字列を抽出する。
【０１６４】
ステップＳ１７１５において、ＣＰＵ３１０は、検出部１６１３として、ステップＳ１７０５で抽出した文字列（ユーザの発話内容）に、応答テーブルＲ００１に保持される予め定められた文字列（キーワード）が含まれているか否かを判断する。
【０１６５】
ＣＰＵ３１０は、ユーザの発話内容にキーワードが含まれていると判断した場合（ステップＳ１７１５においてＹＥＳ）、処理をステップＳ１７２０に進める。そうでない場合（ステップＳ１７１５においてＮＯ）、ＣＰＵ３１０は、処理をステップＳ１７２５に進める。
【０１６６】
ステップＳ１７２０において、ＣＰＵ３１０は、応答テーブルＲ００１を参照して、検出したキーワードに関連付けられた応答フレーズをスピーカ３３０から出力する。
【０１６７】
ステップＳ１７２５において、ＣＰＵ３１０は、ステップＳ１７０５で抽出した文字列に応答する応答フレーズをスピーカ３３０から出力する。
【０１６８】
ステップＳ１７３０において、ＣＰＵ３１０は、ステップＳ１７２０の問い合わせに対するユーザの応答である音声情報をマイク３３５から取得する。
【０１６９】
ステップＳ１７３５において、ＣＰＵ３１０は、楽曲を再生する否かを判断する。より具体的には、ＣＰＵ３１０は、取得した音声情報を解析して、ステップＳ１７２０の問い合わせに対するユーザの応答が、肯定的であるか、否定的であるかを判断する。
【０１７０】
ＣＰＵ３１０は、ユーザの応答が肯定的であった場合に楽曲を再生すると判断して（ステップＳ１７３５においてＹＥＳ）、処理をステップＳ１７４０に進める。一方、ＣＰＵ３１０は、ユーザの応答が否定的であった場合に楽曲を再生しないと判断して（ステップＳ１７３５においてＮＯ）、処理をステップＳ１７４５に進める。
【０１７１】
ステップＳ１７４０において、ＣＰＵ３１０は、選択部１６１７として、楽曲管理テーブルＭ００１から一の楽曲を選択する。より具体的には、選択部１６１７は、応答テーブルＲ００１を参照して、ステップＳ１７１５で検出したキーワードに関連付けられるジャンルと効果ＩＤとを特定する。次に、選択部１６１７は、楽曲管理テーブルＭ００１に保持される楽曲のうち、上記特定したジャンルに属する楽曲を抽出する。選択部１６１７は、抽出した一以上の楽曲の中から、上記特定した効果ＩＤに対応するこれらの楽曲の評価値に基づいて、一の楽曲を選択する。
【０１７２】
ステップＳ１７４５において、ＣＰＵ３１０は、否定的なユーザの応答に対する端末１００の応答フレーズをスピーカ３３０から出力する。
【０１７３】
ステップＳ１７４７において、ＣＰＵ３１０は、楽曲データ群３８１にアクセスして、選択した一の楽曲の楽曲データ（音声情報）をスピーカ３３０によって再生する。
【０１７４】
ステップＳ１７５０において、ＣＰＵ３１０は、応答部１６１５として、再生した楽曲の評価をユーザに問い合わせる。より具体的には、応答部１６１５は、問い合わせテーブル４１０を参照して、ステップＳ１７４０で特定した効果ＩＤに対応する応答フレーズ（問い合わせ）を音声合成した音声情報をスピーカ３３０から出力する。
【０１７５】
ステップＳ１７５５において、ＣＰＵ３１０は、ステップＳ１７５０の問い合わせに対するユーザの応答である音声情報をマイク３３５から取得する。
【０１７６】
ステップＳ１７６０において、ＣＰＵ３１０は、更新部１６１９として、受信した音声情報に基づいて再生された楽曲および関連する楽曲の評価値を更新する。より具体的には、更新部１６１９は、受信した音声情報から文字列を抽出するとともに、評価テーブル３８８を参照して当該文字列に含まれる評価フレーズを特定する。
【０１７７】
更新部１６１９は、特定した評価フレーズに関連付けられた更新値（再生楽曲）と、更新値（関連楽曲）とを特定する。更新部１６１９は、楽曲管理テーブルＭ００１にアクセスして、再生された楽曲（選択した楽曲）について特定した効果ＩＤの評価値を、更新値（再生楽曲）に基づいて更新する。
【０１７８】
更新部１６１９はさらに、楽曲管理テーブルＭ００１にアクセスして、再生された楽曲に関連する楽曲があるか否かを判断し、あると判断した場合に、関連する楽曲について特定した効果ＩＤの評価値を、更新値（関連楽曲）に基づいて更新する。
【０１７９】
上記によれば、ある実施形態に従う端末１６００は、サーバと通信することなく、自身でユーザの嗜好に合致する楽曲を選択し得る。
【０１８０】
［他の構成］
上記の実施形態１および２では、サーバ１５０が楽曲データ群３８１を保持するように構成された。他の局面において、端末が楽曲データ群３８１を保持するように構成されてもよい。係る場合、サーバは、選択した楽曲を特定するための情報（例えば、タイトル、楽曲ＩＤ等）を、端末１００に送信するように構成される。
【０１８１】
また、上記の実施形態では、サーバまたは端末は一の楽曲を選択するように構成されていたが、他の局面において、これらは、２以上の楽曲を選択するように構成されてもよい。係る場合、端末は、２以上の楽曲をスピーカ３３０によって再生し得る。
【０１８２】
また、上記の実施形態では、楽曲の評価は評価値であったが、他の局面において、楽曲の評価は数値によらず、「○」、「△」、「×」などの抽象的な概念であってもよい。
【０１８３】
上記で説明した各制御は、１つのＣＰＵ３１０、または１つのＣＰＵ３６０によって実現されるものとしてあるが、これに限られない。これらの各制御は、少なくとも１つのプロセッサのような半導体集積回路によって実装され得る。
【０１８４】
上記の回路は、有形の読取可能な少なくとも１つの媒体から、１以上の命令を読み出すことにより上記説明した各制御を実現しうる。
【０１８５】
このような媒体は、磁気媒体（例えば、ハードディスク）、光学媒体（例えば、コンパクトディスク（ＣＤ）、ＤＶＤ）、揮発性メモリ、不揮発性メモリの任意のタイプのメモリなどの形態をとるが、これらの形態に限定されるものではない。
【０１８６】
揮発性メモリはＤＲＡＭおよびＳＲＡＭ（Static  Random  Access  Memory）を含み得る。不揮発性メモリは、ＲＯＭ、ＮＶＲＡＭを含み得る。半導体メモリは、少なくとも１つのプロセッサとともに半導体回路の１部分であり得る。
【０１８７】
今回開示された実施形態はすべての点で例示であって制限的なものではないと考えられるべきである。また、上記説明した様々な実施形態は、適宜組み合わせられ得る。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【０１８８】
１００，１６００  端末、１５０，１３５０  サーバ、１６０，Ｍ００１，Ｍ００２，Ｍ００３  楽曲管理テーブル、１７０，３８８  評価テーブル、２００，１３００  制御システム、２１０  ネットワーク、３２０，３８０  記憶装置、３２５，３９０  ＲＡＭ、３３０  スピーカ、３３５  マイク、３６１，１６１１  抽出部、３６３，１６１３  検出部、３６４  音声認識部、３６５，１６１５  応答部、３６７，１６１７  選択部、３６９，１６１９  更新部、３８１  楽曲データ群、３８４  機器管理テーブル、４１０  問い合わせテーブル、１３６０  認証部、１４２０  テーブル、１４４０  ユーザテーブル。
【図１】
2018055440.tif 000003
【図２】
2018055440.tif 000004
【図３】
2018055440.tif 000005
【図４】
2018055440.tif 000006
【図５】
2018055440.tif 000007
【図６】
2018055440.tif 000008
【図７】
2018055440.tif 000009
【図８】
2018055440.tif 000010
【図９】
2018055440.tif 000011
【図１０】
2018055440.tif 000012
【図１１】
2018055440.tif 000013
【図１２】
2018055440.tif 000014
【図１３】
2018055440.tif 000015
【図１４】
2018055440.tif 000016
【図１５】
2018055440.tif 000017
【図１６】
2018055440.tif 000018
【図１７】
2018055440.tif 000019