JP2018054906A - サーバ装置、情報処理端末、システム、および方法 - Google Patents

Abstract

【課題】生成される楽曲に対するユーザの飽きを抑制し得る、楽曲を生成する技術を提供すること。【解決手段】サーバ装置（１５０）は、通信インターフェイス（３７０）と、記憶装置（３８０）と、制御部（３６０）とを備える。記憶装置は、通信インターフェイスを介して取得した、音声を出力可能な情報処理端末（１００）の状態履歴を記憶する。制御部は、状態履歴に基づいて楽曲パラメータを決定し（Ｓ４）、決定した楽曲パラメータに基づいて生成された楽曲を、通信インターフェイスを介して情報処理端末に送信する（Ｓ６）ように構成される。【選択図】図１

Description

この開示は、楽曲を再生可能な端末を制御する技術に関し、より特定的には、楽曲を生成するためのパラメータを決定するための技術に関する。

近年、コンピュータなどの計算手段を用いた自動作曲が注目されている。この自動作曲を行なうアプリケーションは、基本的には一から作曲を行なう訳ではなく、楽曲を作成するための膨大なメロディやリズムなどを、ユーザの指示（指標）に従い、組み合わせて作曲を行なうものである。

自動作曲技術に関し、特開２０１５−０７９１３０号公報（特許文献１）は、歌詞の入力およびパラメータの指定を行なわれると、入力された歌詞を構成する複数の形態素に各々に対し、少なくとも音高を含む楽音情報を生成し、指定されたパラメータに基づいて、前記歌詞に対応して生成された複数の楽音情報を一括して補正する楽音情報生成装置を開示している（「要約」参照）。

特開２００７−３３４６８５号公報（特許文献２）は、ユーザが選択したエージェントキャラクタの楽曲嗜好性に対応付けられているキーワード関連付けリストからキーワードを抽出し、抽出キーワードによりデータベースから、エージェントキャラクタの楽曲嗜好性に適合した属性の楽曲を検索するコンテンツ検索装置を開示している（「要約」参照）。

特開２０１５−０７９１３０号公報 特開２００７−３３４６８５号公報

しかしながら、特許文献１に開示される技術は、ユーザの選択（嗜好性）に従って楽曲を生成する技術であるため、生成される複数の楽曲が互いに似通ってしまう。そのため、ユーザが生成される楽曲に飽きてしまう可能性がある。

特許文献２に開示される技術は、複数の楽曲（コンテンツ）の中からユーザの嗜好性に従い一の楽曲を選択する技術であって、そもそも楽曲を生成する技術ではない。

本開示は、上記のような問題を解決するためになされたものであって、ある局面における目的は、ユーザが飽きにくい楽曲を生成する技術を提供することである。

ある実施形態に従うサーバ装置は、通信インターフェイスと、記憶装置と、制御部とを備える。前記記憶装置は、前記通信インターフェイスを介して取得した、音声を出力可能な情報処理端末の状態履歴を記憶する。前記制御部は、前記状態履歴に基づいて楽曲パラメータを決定し、前記決定した楽曲パラメータに基づいて生成された楽曲を、前記通信インターフェイスを介して前記情報処理端末に送信するように構成される。

ある実施形態に従うサーバ装置は、互いに類似しない複数の楽曲を生成し得る。これにより、このサーバ装置は、生成される楽曲に対するユーザの飽きを抑制し得る。

この発明の上記および他の目的、特徴、局面および利点は、添付の図面と関連して理解されるこの発明に関する次の詳細な説明から明らかとなるであろう。

ある実施形態に従う楽曲生成の制御について説明する図である。 ある実施形態に従う制御システムの構成例を説明する図である。 ある実施形態に従う端末およびサーバのハードウェア構成例を説明する図である。 他の実施形態に従うサーバのハードウェア構成を説明する図である。 ある実施形態に従うイベント履歴テーブルを説明する図である。 ある実施形態に従うイベント履歴テーブルの更新方法を説明する図である。 ある実施形態に従うパラメータ決定テーブルを説明する図である。 ある実施形態に従う楽曲パラメータを決定する制御について説明する図である。 ある実施形態に従う楽曲を生成するための制御を説明するフローチャートである。 ある実施形態に従う制御システムを他の観点から説明する図である。 ある実施形態に従う端末およびサーバの構成を説明する図である。 ある実施形態に従う機器管理ＤＢを説明する図である。 ある実施形態に従う種別パラメータテーブルを説明する図である。 ある実施形態に従う履歴楽曲パラメータと、種別パラメータとに基づいて楽曲パラメータを決定する制御について説明する図である。 ある実施形態に従うユーザパラメータテーブルを説明する図である。 ある実施形態に従う楽曲を生成するためのサーバにおける制御を説明するフローチャートである。 ある実施形態に従う端末の構成例について説明する図である。 ある実施形態に従う端末において楽曲を生成する制御について説明するフローチャートである。

以下、この発明の実施形態について図面を参照しながら詳細に説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。

［技術思想］
図１は、ある実施形態に従う楽曲生成の制御について説明する図である。図１を参照して、端末１００とサーバ１５０とは、互いに通信可能に構成される。端末１００は、情報処理が可能な端末であり得る。ある実施形態において、端末１００は、掃除機、電子レンジ、冷蔵庫、洗濯機、エアコンディショナ、空気清浄器、炊飯器、テレビ、スマートフォン、タブレット、パーソナルコンピュータ、その他の家庭用電気製品であり得る。図１に示される例において、端末１００は、掃除機であるとする。

ある実施形態において、サーバ１５０は、楽曲パラメータに従い楽曲を生成可能に構成される。「楽曲パラメータ」とは、楽曲を生成可能なアプリケーションにおいて、楽曲を生成するために必要なパラメータのことをいう。

ステップＳ１において、端末１００は、予め設定されたイベント（例えば、掃除動作、充電切れ等）が生じると、その旨を知らせるイベント情報をサーバ１５０に送信する。

ステップＳ２において、サーバ１５０は、受信したイベント情報を後述する記憶装置の中の履歴テーブルＴＡ１に格納する。履歴テーブルＴＡ１は、端末１００のイベントと、時刻とを互いに関連付けて保持する。これにより、サーバ１５０は、端末１００の履歴を有する。

ステップＳ３において、端末１００は、サーバ１５０に対して楽曲を生成させるための楽曲リクエストを送信する。

ステップＳ４において、サーバ１５０は、楽曲リクエストの受信に応じて、履歴テーブルＴＡ１に基づいて、すなわち、端末１００の履歴に基づいて楽曲パラメータを決定する。

ステップＳ５において、サーバ１５０は、決定した楽曲パラメータに基づいて、楽曲を生成する。ステップＳ６において、サーバ１５０は、生成した楽曲（楽曲データ）を端末１００に送信する。ステップＳ７において、端末１００は、受信した楽曲をスピーカ等の音声出力装置から再生（出力）する。

上記によれば、ある実施形態に従うサーバ１５０は、端末１００の履歴に基づいて楽曲を生成する。端末１００の履歴は、時間とともに適宜更新される。そのため、サーバ１５０によって生成される複数の楽曲は、その時々の端末１００の履歴に応じて異なる傾向の楽曲が生成され得る。これにより、このサーバ装置は、生成される楽曲に対するユーザの飽きを抑制し得る。

また、ユーザが楽曲を生成可能なサーバと通信可能な端末を複数所有する場合もあり得る。仮に、サーバが単にユーザの嗜好性に応じた楽曲を生成する場合、これら複数の端末の各々で再生される楽曲は互いに類似してしまう。そのため、ユーザが生成される楽曲に対して飽きてしまう可能性がある。

しかし、ある実施形態に従うサーバ１５０は、各々の端末の履歴に基づいて楽曲を生成する。一般的に、ユーザは、端末の種類（例えば、掃除機と冷蔵庫）に応じて、異なる使い方をする。そのため、生成された複数の楽曲は、互いに異なる傾向になり得る。これにより、ある実施形態に従うサーバ１５０は、ユーザが複数の端末１００を所有する場合であっても、生成される楽曲に対するユーザの飽きを抑制し得る。以下、楽曲パラメータの決定方法について具体的に説明する。

［実施形態１−履歴に基づく楽曲パラメータの決定］
（制御システム）
図２は、ある実施形態に従う制御システム２００の構成例を説明する図である。図２を参照して、制御システム２００は、サーバ１５０と、ルータ２２０−１〜２２０−３と、端末１００−１〜１００−９とを備える。以下、ルータ２２０−１〜２２０−３を総称して、「ルータ２２０」とも言う。端末１００−１〜１００−９を総称して、「端末１００」とも言う。

端末１００−１〜１００−３はそれぞれ、ルータ２２０−１に接続される。端末１００−４〜１００−６はそれぞれ、ルータ２２０−２に接続される。端末１００−７〜１００−９はそれぞれ、ルータ２２０−３に接続される。端末１００とルータ２２０とは、有線または無線で接続される。

サーバ１５０は、ネットワーク２１０を介してルータ２２０と接続される。端末１００は、間接的にサーバ１５０と接続される。

なお、図２に示される例では、ルータ２２０に端末１００が３個ずつ接続される構成であるが、ルータ２２０に接続される端末１００の数はこれに限られない。ルータ２２０がローカルＩＰ（Internet Protocol）アドレスを割り当てることができる範囲内で、ルータ２２０に接続される端末１００の数は変更可能である。

図３は、ある実施形態に従う端末１００およびサーバ１５０のハードウェア構成例を説明する図である。

（端末のハードウェア構成）
端末１００は、ＣＰＵ（Central Processor Unit）３１０と、ＲＯＭ（Read Only Memory）３１５と、ＲＡＭ（Random Access Memory）３２０と、入力Ｉ／Ｆ３２５と、スピーカ３３０と、マイク３３５と、バッテリ３４０と、通信Ｉ／Ｆ３４５とを備える。

ＣＰＵ３１０は、端末１００の動作を制御する制御部として機能する。ある局面において、ＣＰＵ３１０は、ＲＯＭ３１５に格納される制御プログラムを読み出して実行することにより、イベント管理部３１２として機能し得る。

イベント管理部３１２は、端末１００において予め設定されたイベントが生じたことを検知し、その旨を知らせるイベント情報をサーバ１５０に送信する。

ＲＯＭ３１５は、ＣＰＵ３１０が実行する制御プログラムと、複数の端末１００の各々を識別するための機器ＩＤ３１７と格納し得る。ある局面において機器ＩＤ３１７は、端末１００（通信Ｉ／Ｆ３４５）のＭＡＣ（Media Access Control）アドレスであり得る。

ＲＡＭ３２０は、ＣＰＵ３１０が制御プログラムを実行するために必要なデータを一時的に記憶するワーキングメモリとして機能する。

入力Ｉ／Ｆ３２５は、ユーザの入力を受け付けるためのインターフェイスである。ある局面において、入力Ｉ／Ｆ３２５は、図示しない赤外線リモートコントローラからの入力を受け付ける赤外線受信部であり得る。他の局面において、入力Ｉ／Ｆ３２５は、端末１００に設けられたボタンであり得る。さらに他の局面において、入力Ｉ／Ｆ３２５は、端末１００に設けられたタッチパネルであり得る。

スピーカ３３０は、音声情報を音声に変換して出力する。他の局面において、端末１００は、スピーカ３３０に替えて、またはスピーカ３３０に加えて、ヘッドフォン，イヤホンその他の音声出力装置を含む構成であってもよい。

マイク３３５は、端末１００の周囲の音声を電気信号としての音声情報に変換してＣＰＵ３１０に入力する。

バッテリ３４０は、典型的にはリチウムイオン２次電池であって、端末１００に含まれる各デバイスに電力を供給するためのデバイスとして機能する。

通信Ｉ／Ｆ３４５は、後述するサーバ１５０の通信Ｉ／Ｆ３７０と通信し、各種信号のやり取りを行なう。

（サーバのハードウェア構成）
サーバ１５０は、ＣＰＵ３６０と、通信Ｉ／Ｆ３７０と、記憶装置３８０とＲＯＭ３９０と、ＲＡＭ３９５と、を備え得る。

ＣＰＵ３６０は、サーバ１５０の動作を制御する制御部として機能する。ある局面において、ＣＰＵ３６０は、記憶装置３８０またはＲＯＭ３９０に格納される制御プログラムを読み出して実行することにより、イベント情報取得部３６２、音声認識部３６４、パラメータ決定部３６６、および楽曲生成部３６８として機能し得る。

イベント情報取得部３６２は、端末１００から受信したイベント情報に基づいて、後述するイベント履歴テーブル３８２を更新する。

音声認識部３６４は、端末１００から受信する音声情報に対して音声認識処理を行なう。これにより、音声認識部３６４は、音声情報から文字列を抽出する。

パラメータ決定部３６６は、楽曲生成部３６８が楽曲を生成するために必要な楽曲パラメータを決定する。

楽曲生成部３６８は、パラメータ決定部３６６によって決定された楽曲パラメータに基づいて楽曲を生成する。楽曲生成部３６８は、既知のアプリケーションによって実現され得る。ある局面において、楽曲生成部３６８は、ヤマハ株式会社によって提供されるＶＯＣＡＬＯＤＵＣＥＲ（登録商標）を用いて実現され得る。

通信Ｉ／Ｆ３７０は、端末１００と通信するためのインターフェイスであって、一例として、無線ＬＡＮ（Local Area Network）カードであるとする。サーバ１５０は、通信Ｉ／Ｆ３７０を介してＬＡＮまたはＷＡＮ（Wide Area Network）に接続された端末１００と通信可能に構成される。

記憶装置３８０は、典型的にはハードディスクドライブなどであって、イベント履歴テーブル３８２と、パラメータ決定テーブル３８４とを格納する。イベント履歴テーブル３８２は、端末１００の履歴を保持する。パラメータ決定テーブル３８４は、楽曲パラメータを決定するために必要なポイントを保持する。これらテーブルの詳細は図５および図７を用いて後述される。

ＲＯＭ３９０は、典型的には、フラッシュメモリなどであり、ＣＰＵ３６０が実行する制御プログラムや、サーバ１５０の動作に係る各種設定情報を格納し得る。

ＲＡＭ３９５は、典型的には、ＤＲＡＭ（Dynamic Random Access Memory）などであって、ＣＰＵ３６０が制御プログラムを実行するために必要なデータを一時的に記憶するワーキングメモリとして機能する。

なお、他の局面において、サーバ１５０のＣＰＵ３６０は、楽曲生成部の機能構成を有さない構成であってもよい。

図４は、他の実施形態に従うサーバ１５０のハードウェア構成を説明する図である。他の実施形態において、サーバ１５０のＣＰＵ３６０は、その機能構成として楽曲生成部を有さない。

この場合、他の実施形態に従うサーバ１５０は、楽曲パラメータに基づいて楽曲を生成するための楽曲生成部４１０を有する外部装置４００と通信し得る。

より具体的には、サーバ１５０は、パラメータ決定部３６６が決定した楽曲パラメータを、外部装置４００に送信する。外部装置４００は、受信した楽曲パラメータに基づいて楽曲生成部４１０によって楽曲を生成するとともに、生成した楽曲をサーバ１５０に送信するように構成される。制御システムは、このような構成であってもよい。さらに他の局面において、外部装置４００は、生成した楽曲をサーバ１５０ではなく端末１００に直接送信する構成であってもよい。

なお、図３および４に示される例では、サーバ１５０は、１つのＣＰＵ３６０と、１つの通信Ｉ／Ｆ３７０と、１つの記憶装置３８０を備える構成であるが、他の局面において、サーバは、これらのデバイスを複数有する構成であってもよい。例えば、サーバは、２つ以上のＣＰＵによって、後述する処理を分散処理してもよい。また、サーバは、２つ以上の通信Ｉ／Ｆによって端末１００と情報の送受信を行ってもよい。また、サーバは、第１の通信Ｉ／Ｆによって端末１００と通信し、第２の通信Ｉ／Ｆによって外部装置４００と通信を行なってもよい。また、サーバは、２つ以上の記憶装置を有し、記憶すべきデータを分散して複数の記憶装置に格納してもよい。

（イベント履歴テーブル）
図５は、ある実施形態に従うイベント履歴テーブル３８２を説明する図である。

図５を参照して、イベント履歴テーブル３８２は、機器ＩＤと、時刻と、イベントとを互いに関連付けて保持する。図５に示される例において、端末１００は掃除機であるとする。

図５に示される例では、機器ＩＤ「Ｄ００１０３」の端末１００において、時刻「２０１４−０７−２９ ０９：５４：１０」にイベント「おまかせモードで運転」が発生している。

機器ＩＤ「Ｄ０１０９１」の端末１００において、時刻「２０１４−０７−２９ ０９：５５：３３」にイベント「バッテリー残量が０になった」が発生している。

機器ＩＤ「Ｄ００４２７」の端末１００において、時刻「２０１４−０７−２９ ０９：５９：４２」にイベント「充電を行なった」が発生している。

機器ＩＤ「Ｄ０００６６」の端末１００において、時刻「２０１４−０７−２９ ０９：５９：４３」にイベント「パワー強で運転」が発生している。

機器ＩＤ「Ｄ００４２７」の端末１００において、時刻「２０１４−０７−２９ １０：００：０１」にイベント「念入りモードで運転」が発生している。

機器ＩＤ「Ｄ００２０８」の端末１００において、時刻「２０１４−０７−２９ １０：００：１０」にイベント「ダストボックスが一杯になった」が発生している。

上記のように、イベント履歴テーブル３８２は、各端末１００ごとに、発生したイベントと時刻とを保持する。

また、イベントは、「パワー強で運転」のような端末１００の動作を示す動作イベントの他に、「バッテリー残量が０になった」のような端末１００の状態を示す状態イベントも含み得る。このように、イベント履歴テーブルは、端末１００の状態履歴を記憶する。「状態履歴」は、端末１００の動作を示す履歴と、端末１００の状態を示す履歴を含むものである。

図６は、ある実施形態に従うイベント履歴テーブル３８２の更新方法を説明する図である。図６に示される処理は、ＣＰＵ１１０およびＣＰＵ３６０が各々の記憶デバイスに保持される制御プログラムを実行することにより実現される。

ステップＳ６１０において、端末１００のＣＰＵ３１０は、イベント管理部３１２として、予め設定されたイベントの発生を検知する。

ステップＳ６２０において、ＣＰＵ３１０は、検知したイベントの情報を示すイベント情報と、ＲＯＭ３１５に格納される機器ＩＤ３１７とをサーバ１５０に送信する。

ステップＳ６３０において、サーバ１５０のＣＰＵ３６０は、イベント情報取得部３６２として、端末１００から受信したイベント情報と、機器ＩＤ３１７と、受信した時刻とを関連付けてイベント履歴テーブル３８２に追加する。

他の局面において、イベント管理部３１２は、イベント情報と機器ＩＤ３１７とともに、イベントが発生した時刻をサーバ１５０に送信してもよい。この場合、イベント情報取得部３６２は、当該時刻を、イベント情報と機器ＩＤ３１７とともに、イベント履歴テーブル３８２に追加し得る。

さらに他の局面において、イベント情報取得部３６２は、予め定められた期間（例えば、９０日間）のイベント情報のみを保持するように構成されてもよい。この場合、イベント情報取得部３６２は、予め定められた期間を経過したイベント情報を、イベント履歴テーブル３８２から削除し得る。

（パラメータ決定テーブル）
図７は、ある実施形態に従うパラメータ決定テーブル３８４を説明する図である。

図５を参照して、パラメータ決定テーブル３８４は、イベントと、ジャンルポイントと、テンポポイントと、キーポイントとを互いに関連付けて保持する。

ある実施形態において、楽曲パラメータは、ジャンルパラメータと、テンポパラメータと、キーパラメータとを含む。

「ジャンルパラメータ」は、記憶装置３８０に格納される複数のジャンルの中から一のジャンルを決定するパラメータである。換言すれば、「ジャンルパラメータ」は、楽曲生成部３６８が生成する楽曲のジャンルを決定するパラメータである。ある局面において、記憶装置３８０には、「ヒップホップ」、「ラテン」、「バラード」、「メタル」、「カントリー」、「ロック」、「Ｒ＆Ｂ（Rhythm and blues）」の７種類のジャンルが記憶される。

「テンポパラメータ」は、楽曲生成部３６８が生成する楽曲のテンポ（例えば、ＢＰＭ：Beats Per Minute）を決定するパラメータである。ある局面において、テンポパラメータは、８０ｂｐｍ〜１６０ｂｐｍの間に設定され得る。

「キーパラメータ」は、楽曲生成部３６８において、ジャンルパラメータによって定まる基準のキー（調）を変更するパラメータである。換言すれば、キーパラメータは、楽曲生成部３６８が生成する楽曲のキーを決定するパラメータである。ある局面において、キーパラメータは、−６．０〜＋６．０の間の整数に設定され得る。

他の局面において、楽曲パラメータは、楽曲のリズムを決定するためのリズムパラメータや、楽曲のコード進行を決定するためのコードパラメータや、楽曲の曲調を決定するための曲調パラメータ、楽曲の長さ（時間）を決定するための曲長パラメータ等を含み得る。

さらに他の局面において、楽曲生成部３６８は歌詞を含む楽曲を再生可能に構成され、楽曲パラメータは歌詞の情報（テキストデータ）を含み得る。この場合、歌詞の情報は、ユーザが入力Ｉ／Ｆ３２５を操作して、またはマイク３３５に対する発話によって登録され得る。

「ジャンルポイント」は、ジャンルパラメータを決定する際の計算に使用される値である。「テンポポイント」は、テンポパラメータを決定する際の計算に使用される値である。「キーポイント」は、キーパラメータを決定する際の計算に使用される値である。

図７に示される例において、イベント「おまかせモードで運転」には、Ｒ＆Ｂのジャンルポイントが「＋２」に設定される。なお、当該イベントに対してテンポポイントおよびキーポイントは「ｎｕｌｌ（何もしない）」に設定される。

イベント「スポットモードで運転」には、ヒップホップのジャンルポイントが「＋２」、テンポポイントが「−２」に設定される。

イベント「壁際モード」には、テンポポイントが「−２」、キーポイントが「＋０．０２」に設定される。

イベント「念入りモード」には、ラテンのジャンルポイントが「＋２」に設定される。
イベント「バッテリー残量２０％以下になった」には、バラードのジャンルポイントが「＋５」、テンポポイントが「−５」、キーポイントが「−０．１」に設定される。ある局面において、イベント管理部３１２は、バッテリ３４０に接続される電圧計（不図示）の検知結果が予め定められた値を下回った時に、このイベントが発生したと判断し得る。

イベント「バッテリー残量が０になった」には、バラードのジャンルポイントが「＋１０」、テンポポイントが「−１０」、キーポイントが「−０．２」に設定される。

イベント「パワー強で運転」には、メタルのジャンルポイントが「＋２」、テンポポイントが「＋２」、キーポイントが「＋０．０２」に設定される。

イベント「写真を撮影」には、ロックのジャンルポイントが「＋５」に設定される。ある局面において、端末１００にはカメラ（不図示）が搭載される。ある局面において、イベント管理部３１２は、ユーザから入力Ｉ／Ｆ３２５またはマイク３３５にカメラによる撮影指示の入力がなされた際に、このイベントが発生したと判断し得る。

イベント「天気予報」には、ロックのジャンルポイントが「＋２」、テンポポイントが「＋２」に設定される。ある局面において、イベント管理部３１２は、ユーザから入力Ｉ／Ｆ３２５またはマイク３３５に天気を伺う旨の入力がなされた際に、このイベントが発生したと判断し得る。

イベント「ダストボックスが一杯」には、Ｒ＆Ｂのジャンルポイントが「＋３」、キーポイントが「−０．０５」に設定される。ある局面において、端末１００は、掃除機であって、図示しないダストボックスを備えるものとする。このとき、イベント管理部３１２は、ダストボックスに配置されるフォトリフレクタの検知結果に基づいてこのイベントが発生したと判断し得る。

（楽曲パラメータの決定方法）
図８は、ある実施形態に従う楽曲パラメータを決定する制御について説明する図である。サーバ１５０は、端末１００から楽曲リクエストを受け付けると、この端末１００に応じた楽曲パラメータを決定する。

まず、ジャンルパラメータを決定するための制御について説明する。
サーバ１５０のＣＰＵ３６０は、パラメータ決定部３６６として、イベント履歴テーブル３８２を参照して楽曲リクエストを受け付けた端末１００の履歴を取得する。より具体的には、パラメータ決定部３６６は、イベント履歴テーブル３８２のうち、予め定められた期間（例えば９０日間）内の楽曲リクエストを受け付けた端末１００の機器ＩＤに相当するイベント情報を取得する。

次に、パラメータ決定部３６６は、パラメータ決定テーブル３８４を参照して、取得したイベント情報に対応するジャンルポイントを、各ジャンルについて積算する。この各ジャンルにおけるジャンルポイントの積算値を、「積算ジャンルポイント」とも称する。

一例として、予め定められた期間内に、イベント「写真を撮影」が２回、「ダストボックスが一杯」が１回発生したとする。この場合、パラメータ決定部３６６は、ロックの積算ジャンルポイントが「１０」、Ｒ＆Ｂの積算ジャンルポイントが「３」であると計算する。

分図（Ａ）は、ある局面における各ジャンルについての積算ジャンルポイントを示す図である。分図（Ａ）に示される例において、ヒップホップの積算ジャンルポイントが「６０」、ラテンの積算ジャンルポイントが「４０」、・・・ロックの積算ジャンルポイントが「−２０」、Ｒ＆Ｂの積算ジャンルポイントが「３０」となっている。

次に、パラメータ決定部３６６は、各ジャンルについて、積算ジャンルポイントの合計に対する自ジャンルの積算ジャンルポイントの割合を算出する。このとき、パラメータ決定部３６６は、負の積算ジャンルポイントを「０」として計算し得る。そのため、分図（Ａ）の例において積算ジャンルポイントの合計は「１８０」となる。

分図（Ｂ）は、分図（Ａ）の各ジャンルにおける、積算ジャンルポイントの合計に対する自ジャンルの積算ジャンルポイントの割合を示す図である。パラメータ決定部３６６は、この割合を確率として、７種類のジャンルの中から一のジャンルを、ジャンルパラメータとして決定する。分図（Ｂ）において、ヒップホップの選ばれる確率が最も高い。一方、バラードまたはロックが選ばれる確率が最も低い。

次に、テンポパラメータを決定するための制御について説明する。
パラメータ決定部３６６は、ジャンルパラメータと同様に、パラメータ決定テーブル３８４を参照して、取得したイベント情報に対応するテンポポイントを積算する。このテンポポイントの積算値を、「積算テンポポイント」とも称する。

一例として、予め定められた期間内に、イベント「天気予報」が５５回、「バッテリー残量２０％以下になった」が１回発生したとする。この場合、パラメータ決定部３６６は、積算テンポポイントが「１０５」であると計算する。

なお他の局面において、記憶装置３８０には初期テンポ値（例えば、１２０）が記憶されているものとする。この場合、パラメータ決定部３６６は、初期テンポ値と、取得したイベント情報に対応するテンポポイントの積算値とを足し合わせた値を積算テンポポイントと定義する。

パラメータ決定部は、算出した積算テンポポイントの値を中心とする確率分布（たとえば、ガウス分布）をもとに、テンポパラメータを決定する。すなわち、積算テンポポイントの値がテンポパラメータとして決定される確率が最も高い。

次に、キーパラメータを決定するための制御について説明する。パラメータ決定部３６６は、テンポパラメータと同様に、パラメータ決定テーブル３８４を参照して、取得したイベント情報に対応するキーポイントを積算する。このキーポイントの積算値を、「積算キーポイント」とも称する。

一例として、予め定められた期間内に、イベント「壁際モード」が１３回、「パワー強で運転」が１３回発生したとする。この場合、パラメータ決定部３６６は、積算キーポイントが「０．５２」であると計算する。

パラメータ決定部３６６は、算出した積算キーポイントの値を中心とする確率分布（たとえば、ガウス分布）をもとに、一のキーパラメータを算出する。パラメータ決定部は、算出されたキーパラメータを整数に四捨五入してキーパラメータを決定する。

一例として、パラメータ決定部３６６が、積算キーポイントが「０．５２」である場合に、キーパラメータ「０．５８」を算出したとする。この場合、パラメータ決定部３６６は、当該値を四捨五入してキーパラメータを「１」に決定する。

上記の積算ジャンルポイント、積算テンポポイント、積算キーポイントなどの楽曲パラメータを決定するための積算ポイントを総称して「履歴楽曲パラメータ」とも言う。上記のように、ある実施形態に従うサーバ１５０は、履歴楽曲パラメータを算出して、当該算出した履歴楽曲パラメータに基づいて確率的に前記楽曲パラメータを決定する。これにより、生成される楽曲の傾向が、その都度変わり得る。その結果、サーバ１５０は、ユーザの生成される楽曲に対する飽きを抑制し得る。

（楽曲生成の制御のフロー）
図９は、ある実施形態に従う楽曲を生成するための制御を説明するフローチャートである。図６に示される処理は、ＣＰＵ１１０およびＣＰＵ３６０が各々の記憶デバイスに保持される制御プログラムを実行することにより実現される。

ステップＳ９１０において、ユーザは、端末１００のマイク３３５に対して「何か歌ってみて」と発話する。

ステップＳ９２０において、端末１００のＣＰＵ３１０は、マイク３３５から入力された音声情報と、機器ＩＤ３１７とをサーバ１５０に送信する。

ステップＳ９３０において、サーバ１５０のＣＰＵ３６０は、音声認識部３６４として、受信した音声情報から文字列「何か歌ってみて」を抽出する。音声認識部３６４は、抽出した文字列に予め定められた文字列（例えば、「歌って」、「歌がききたい」など）が含まれていると判断する。これにより、ＣＰＵ３６０は、端末１００からの楽曲リクエストを受け付ける。

一例として、音声認識部３６４は、音声情報の先頭から所定時間単位（たとえば、１０ｍｓｅｃ単位）で区切られる波形データと、記憶装置３８０に格納される音響モデル（母音や子音などの音素ごとに音声の特徴量）とを照合して、音声情報から文字列を抽出する。このとき、音声認識部３６４は、ＨＭＭ（Hidden Markov Model）に従い音声情報から文字列を抽出し得る。

ステップＳ９４０において、ＣＰＵ３６０は、イベント情報取得部３６２として、イベント履歴テーブル３８２を参照して、予め定められた期間内における受信した機器ＩＤ３１７に対応するイベント情報を抽出する。

ステップＳ９５０において、ＣＰＵ３６０は、パラメータ決定部３６６として、パラメータ決定テーブル３８４を参照して、抽出したイベント情報に基づいて履歴楽曲パラメータ（積算ジャンルポイント、積算テンポポイント、積算キーポイント）を算出する。

ステップＳ９６０において、ＣＰＵ３６０は、パラメータ決定部３６６として、算出した履歴楽曲パラメータから楽曲パラメータ（ジャンルパラメータ、テンポパラメータ、キーパラメータ）を決定する。

ステップＳ９７０において、ＣＰＵ３６０は、楽曲生成部３６８として、決定した楽曲パラメータに基づいて楽曲を生成する。

ステップＳ９８０において、ＣＰＵ３６０は、生成した楽曲を音声出力装置から出力可能な楽曲データに変換して端末１００に送信する。

ステップＳ９９０において、端末１００は、受信した楽曲データを、スピーカ３３０から出力（再生）する。

上記によれば、ある実施形態に従うサーバ１５０は、端末１００の履歴に基づいて楽曲を生成する。端末１００の履歴は、時間とともに適宜更新される。そのため、サーバ１５０によって生成される複数の楽曲は、その時々の端末１００の履歴に応じて異なる傾向の楽曲が生成され得る。これにより、このサーバ装置は、生成される楽曲に対するユーザの飽きを抑制し得る。

また、ある実施形態に従うサーバ１５０は、ユーザが複数の端末１００（例えば、掃除機と冷蔵庫）を所有する場合に、各々の端末の履歴に応じた楽曲を生成する。そのため、ある実施形態に従うサーバ１５０は、ユーザが複数の端末１００を所有する場合であっても、生成される楽曲に対するユーザの飽きを抑制し得る。

［実施形態２−他の楽曲パラメータの算出方法（機器種別、ユーザ設定）］
上記の実施形態において、サーバ１５０は、端末１００の履歴のみに基づいて楽曲パラメータを決定する構成であった。この実施形態において、サーバ１５０は、端末１００の履歴に加え、他のパラメータも考慮して、楽曲パラメータを決定し得る。

（家と端末とユーザとの関係）
図１０は、ある実施形態に従う制御システム２００を他の観点から説明する図である。ネットワーク２１０には、各家庭に配置されるルータ２２０が接続されている。この各家庭には１台以上の端末１００が配置されている。また、この各家庭には、１人以上のユーザが端末１００を操作し得る。

（端末１００およびサーバ１５０の構成）
図１１は、ある実施形態に従う端末１００およびサーバ１５０の構成を説明する図である。なお、図１１に示される例において、端末１００およびサーバ１５０のハードウェア構成は、図３で説明した端末１００およびサーバ１５０のハードウェア構成と同じであるため、その説明は繰り返さない。

図１１に示される端末１００のＲＯＭ３１５は、機器ＩＤ３１７に加えて、機器種別１１１０をさらに格納する点において、図３で説明したＲＯＭと相違する。

ある局面において、機器種別１１１０は、端末１００の種別（例えば、掃除機、冷蔵庫、電子レンジ等）を特定するための情報であり得る。他の局面において機器種別１１１０は、端末１００の製品名を特定するための情報であり得る。

図１１に示される記憶装置３８０は、パラメータ決定テーブル３８４に代えてパラメータ決定ＤＢ１１２０を格納し、さらに機器管理ＤＢ１１３０を格納する点において、図３で説明した記憶装置と相違する。

（機器管理ＤＢ）
図１２は、ある実施形態に従う機器管理ＤＢ１１３０を説明する図である。

ある実施形態において、機器管理ＤＢ１１３０は、家テーブル１２２０と、機器テーブル１２４０と、ユーザテーブル１２６０と、機器種別テーブル１２８０とを含む。

分図（Ａ）は、ある実施形態に従う家テーブル１２２０を説明する図である。
家テーブル１２２０は、家ＩＤと家の名前とを互いに関連付けて保持する。

ある局面において、家ＩＤは、サーバ１５０に接続される家庭を識別するための情報である。ある局面において、家ＩＤは、ルータ２２０に割り当てられるグローバルＩＰアドレスであり得る。

ある局面において、家の名前は、サーバ１５０に接続される家庭に属する人間の名字であり得る。家の名前は、ユーザが入力Ｉ／Ｆ３２５を操作して、またはマイク３３５に対する発話によって登録し得る。

分図（Ｂ）は、ある実施形態に従う機器テーブル１２４０を説明する図である。
機器テーブル１２４０は、機器ＩＤと、家ＩＤと、機器種別とを互いに関連付けて保持する。

ある局面において、サーバ１５０は、ルータ２２０から、機器ＩＤと家ＩＤと機器種別とを受信する。サーバ１５０は、受信した機器ＩＤと、機器テーブル１２４０に保持される複数の機器ＩＤの各々とを比較して、一致する機器ＩＤが無いと判断した場合、受信した機器ＩＤと家ＩＤと機器種別とを関連付けて機器テーブル１２４０に登録し得る。

分図（Ｃ）は、ある実施形態に従うユーザテーブル１２６０を説明する図である。ユーザテーブル１２６０は、ユーザＩＤと家ＩＤとユーザネームとユーザパラメータテーブルと、特徴量データとを互いに関連付けて保持する。

ユーザＩＤは、端末１００の複数のユーザを互いに識別するための情報である。ユーザネームは、端末１００のユーザが入力Ｉ／Ｆ３２５を操作して設定した、またはマイク３３５に対して発話した自身を識別するための名称である。

ユーザパラメータテーブルは、楽曲パラメータを決定する際の計算に使用される、ユーザごとの設定値である。このテーブルの詳細は、図１４において後述される。

特徴量データは、ユーザの音声に対応する音声情報から抽出される特徴である。特徴量データは、ＬＰＣ（Linear Predictive Coding）ケプストラム係数や、ＭＦＣＣ（Mel-Frequency Cepstrum Coefficient）等の既知の手法によって算出され得る。

分図（Ｄ）は、ある実施形態に従う機器種別テーブル１２８０を説明する図である。機器種別テーブル１２８０は、機器種別と、種別パラメータテーブルとを互いに関連付けて保持する。

種別パラメータテーブルは、楽曲パラメータを決定する際の計算に使用される、機器種別ごとの設定値である。

図１３は、ある実施形態に従う種別パラメータテーブルを説明する図である。
図１３を参照して、種別パラメータテーブルには、上記説明した「ジャンル」（各ジャンル）、「テンポ」、「キー」ごとに種別パラメータが設定される。

図１３に示される例において、機器種別「掃除機」に対応する種別パラメータテーブルＤＴ００１には、テンポの種別パラメータが「１２０」に、キーの種別パラメータが「−０．５」に、ヒップホップの種別パラメータが「３０」に、ヒップホップの種別パラメータが「２０」に、ヒップホップの種別パラメータが「−１０」に、ヒップホップの種別パラメータが「４０」に、ヒップホップの種別パラメータが「５０」に、ヒップホップの種別パラメータが「−３０」に、ヒップホップの種別パラメータが「２０」にそれぞれ設定されている。

ある局面において、サーバ１５０のＣＰＵ３６０は、パラメータ決定部３６６として、履歴楽曲パラメータと、種別パラメータとに基づいて楽曲パラメータを決定し得る。

図１４は、ある実施形態に従う履歴楽曲パラメータと、種別パラメータとに基づいて楽曲パラメータを決定する制御について説明する図である。

図１４に示される例において、積算テンポポイントが「１００」、積算キーポイントが「３」、ヒップホップの積算ジャンルポイントが「２０」、その他ジャンルの積算ジャンルポイントが「０」と算出されたとする。

また、テンポの種別パラメータが「１５０」、キーの種別パラメータが「１」、ラテンの種別パラメータが「２０」、その他ジャンルの種別パラメータが「０」と算出されたとする。

ある局面においてパラメータ決定部３６６は、履歴楽曲パラメータに係数０．８を乗じた値と、種別パラメータに係数０．２を乗じた値とを合算した合算パラメータを算出する。なお、他の局面において、ユーザは、これら各係数の値を任意に設定し得る。ただし、各係数の値は、各係数の合計値が１．０になるように設定される。

図１４に示される例において、パラメータ決定部３６６は、テンポの合算パラメータが「１２０」（＝１００×０．８＋１５０×０．２）、キーの合算パラメータが「２．６」、ヒップホップの合算パラメータが「１６」、ラテンの合算パラメータが「４」、その他ジャンルの合算パラメータが「０」であると算出する。

パラメータ決定部３６６は、算出した合算パラメータに基づいて、上記図８で説明した制御と同様の制御を行ない、楽曲パラメータを決定する。

上記によれば、ある実施形態に従うサーバ１５０は、機器種別に応じて設定される種別パラメータを考慮して楽曲パラメータを決定する。そのため、サーバ１５０は、ユーザが複数種別の端末１００を所有する場合において、複数の端末の各々で再生される楽曲は、互いに異なる傾向になり得る。その結果、サーバ１５０は、ユーザが複数種別の端末１００を所有する場合であっても、生成される楽曲に対するユーザの飽きを抑制し得る。

図１５は、ある実施形態に従うユーザパラメータテーブルを説明する図である。
図１５を参照して、ユーザパラメータテーブルには、上記説明した「ジャンル」（各ジャンル）、「テンポ」、「キー」ごとにユーザパラメータが設定される。

図１５に示される例において、ユーザＩＤ「Ｕ００００１」に対応するユーザパラメータテーブルＵＴ００１には、テンポのユーザパラメータが「１５０」に、キーのユーザパラメータが「１．０」に、ヒップホップのユーザパラメータが「４０」に、ヒップホップのユーザパラメータが「１０」に、ヒップホップのユーザパラメータが「−２０」に、ヒップホップのユーザパラメータが「３０」に、ヒップホップのユーザパラメータが「２０」に、ヒップホップのユーザパラメータが「−１０」に、ヒップホップのユーザパラメータが「３０」にそれぞれ設定されている。

ある局面において、ユーザは、入力Ｉ／Ｆ３２５を操作して、またはマイク３３５に対して発話することにより、ユーザパラメータを端末１００に入力し得る。端末１００は、入力されたユーザパラメータと機器ＩＤ３１７とを、サーバ１５０に送信する。サーバ１５０は、受信した機器ＩＤ３１７と、ユーザパラメータテーブルとを関連付けてユーザテーブル１２６０に記憶する。

ある局面において、サーバ１５０のＣＰＵ３６０は、パラメータ決定部３６６として、履歴楽曲パラメータと、ユーザパラメータとに基づいて楽曲パラメータを決定し得る。さらに他の局面において、パラメータ決定部３６６は、履歴楽曲パラメータと、種別パラメータと、ユーザパラメータとに基づいて楽曲パラメータを決定し得る。なお、これらのパラメータを用いた楽曲パラメータの決定方法は、図１４で説明した方法と同じであるため、繰り返し説明しない。また、各パラメータに乗じる係数の値は、適宜ユーザによって変更可能に構成され得る。

上記によれば、ある実施形態に従うサーバ１５０は、ユーザパラメータを考慮して、換言すれば、ユーザの嗜好性を考慮して楽曲パラメータを決定する。これにより、サーバ１５０は、端末１００の履歴に基づきつつ、ユーザの好きな楽曲を生成し得る。

（楽曲生成の制御のフロー）
図１６は、ある実施形態に従う楽曲を生成するためのサーバ１５０における制御を説明するフローチャートである。図６に示される処理は、ＣＰＵ３６０が記憶装置３８０またはＲＯＭ３９０に格納される制御プログラムを実行することにより実現される。なお、図９と同一符号を付している部分については同じ処理であるため、その部分についての説明は繰り返さない。図１６に示される一連の制御は、図９のステップＳ９３０で説明した楽曲リクエストの受付処理に応じて実行され得る。

ステップＳ１６１０において、ＣＰＵ３６０は、端末１００から受信した音声情報からユーザＩＤを取得できたか否かを判断する。

より具体的には、ＣＰＵ３６０は、受信した音声情報から特徴量を算出する。次にＣＰＵ３６０は、算出した特徴量と、ユーザテーブル１２６０に保持される複数の特徴量の各々とを比較して、各ユーザの特徴量ごとに一致度を算出する。次にＣＰＵ３６０は、予め定められた値よりも大きい一致度を有するユーザの特徴量が存在したか否かを判断する。ＣＰＵ３６０は、存在したと判断した場合に党がユーザの特徴量に対応するユーザＩＤを取得する。なお、ＣＰＵ３６０は、予め定められた値よりも大きい一致度を有するユーザの特徴量が複数存在する場合、最も一致度の大きい一の特徴量に対応するユーザＩＤを取得し得る。

ＣＰＵ３６０は、ユーザＩＤを取得できた場合（ステップＳ１６１０においてＹＥＳ）、処理をステップＳ１６２０に進める。そうでない場合（ステップＳ１６１０においてＮＯ）、ＣＰＵ３６０は、処理をステップＳ１６３０に進める。

ステップＳ１６２０において、ＣＰＵ３６０は、ステップＳ９５０で算出した履歴楽曲パラメータと、種別パラメータと、ユーザパラメータとに基づいて、楽曲パラメータを決定する。

より具体的には、ＣＰＵ３６０は、機器テーブル１２４０を参照して受信した機器ＩＤ３１７に対応する機器種別を取得するとともに、機器種別テーブル１２８０を参照して取得した機器種別に対応する種別パラメータテーブルから種別パラメータを取得する。

また、ＣＰＵ３６０は、ユーザテーブル１２６０を参照して、ステップＳ１６１０で取得したユーザＩＤに対応するユーザパラメータテーブルからユーザパラメータを取得する。

ステップＳ１６３０において、ＣＰＵ３６０は、履歴楽曲パラメータと、種別パラメータとに基づいて楽曲パラメータを決定する。

ステップＳ９７０において、ＣＰＵ３６０は、楽曲生成部３６８として、決定した楽曲パラメータに基づいて楽曲を生成する。

［実施形態３−端末が楽曲を生成］
上記の実施形態では、端末１００は、サーバ１５０にイベント情報を送信して、サーバ１５０から楽曲データを受信する構成であった。しかしながら、ネットワーク環境が劣悪な場合など、サーバから楽曲データを受信することが難しい場合もあり得る。そこで、ある実施形態に従う端末は、自身で楽曲データを生成するように構成される。

図１７は、ある実施形態に従う端末１７００の構成例について説明する図である。なお、図３と同一符号を付している部分については同じであるため、その部分についての説明は繰り返さない。

端末１７００は、記憶装置１７１０を有する点、および通信Ｉ／Ｆ３４５を有さない点において、図３で説明した端末１００のハードウェア構成と相違する。

端末１７００のＣＰＵ３１０は、ＲＯＭ３１５または記憶装置１７１０に格納される制御プログラムを読み込んで実行することにより、イベント管理部３１２に加え、さらに音声認識部１７２０、パラメータ決定部１７３０、および楽曲生成部１７４０として機能し得る。音声認識部１７２０、パラメータ決定部１７３０、楽曲生成部１７４０はそれぞれ、図３で説明した音声認識部３６４、パラメータ決定部３６６、楽曲生成部３６８と同じ機能を有する。

記憶装置１７１０は、イベント履歴テーブル１７１２と、パラメータ決定テーブル３８４とを含む。イベント履歴テーブル１７１２は、図５で説明したイベント履歴テーブル３８２のうち、時刻とイベントとを互いに関連付けて保持するテーブルであるため、特に図示しない。

図１８は、ある実施形態に従う端末１７００において楽曲を生成する制御について説明するフローチャートである。図１８に示される処理は、端末１７００のＣＰＵ３１０が、ＲＯＭ３１５または記憶装置１７１０に格納される制御プログラムを読み込むことによって実行され得る。

ステップＳ１８１０において、ＣＰＵ３１０は、音声認識部１７２０として、楽曲リクエストを受け付けたかを判断する。この処理は、上記に説明したステップＳ９３０の処理と実質的に同じである。

ステップＳ１８２０において、ＣＰＵ３１０は、イベント管理部３１２として、イベント履歴テーブル１７１２を参照して、予め定められた期間内（例えば、９０日間）におけるイベント情報を抽出する。

ステップＳ１８３０において、ＣＰＵ３１０は、パラメータ決定部１７３０して、パラメータ決定テーブル３８４を参照して、抽出したイベント情報に基づいて履歴楽曲パラメータを算出する。

ステップＳ１８４０において、ＣＰＵ３１０は、パラメータ決定部１７３０として、算出した履歴楽曲パラメータから楽曲パラメータを決定する。同ステップにおいて、ＣＰＵ３１０は、楽曲生成部１７４０として、決定した楽曲パラメータに基づいて楽曲を生成する。

ステップＳ１８５０において、ＣＰＵ３１０は、生成した楽曲を音声出力装置から出力可能な楽曲データに変換して、スピーカ３３０から出力（再生）する。

上記によれば、ある実施形態に従う端末１７００は、サーバによらず、オフライン環境下でも自端末の履歴に基づいて楽曲を生成し得る。

上記で説明した各制御は、１つのＣＰＵ３１０、または１つのＣＰＵ３６０によって実現されるものとしてあるが、これに限られない。これらの各制御は、少なくとも１つのプロセッサのような半導体集積回路によって実装され得る。

上記の回路は、有形の読取可能な少なくとも１つの媒体から、１以上の命令を読み出すことにより上記説明した各制御を実現しうる。

このような媒体は、磁気媒体（たとえば、ハードディスク）、光学媒体（たとえば、コンパクトディスク（ＣＤ）、ＤＶＤ）、揮発性メモリ、不揮発性メモリの任意のタイプのメモリなどの形態をとるが、これらの形態に限定されるものではない。

揮発性メモリはＤＲＡＭおよびＳＲＡＭ（Static Random Access Memory）を含み得る。不揮発性メモリは、ＲＯＭ、ＮＶＲＡＭを含み得る。半導体メモリは、少なくとも１つのプロセッサとともに半導体回路の１部分であり得る。

今回開示された実施の形態は全ての点で例示であって制限的なものではないと考えられるべきである。また、上記説明した様々な実施形態は、適宜組み合わせられ得る。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内での全ての変更が含まれることが意図される。

１００，１７００ 端末、１５０ サーバ、２００ 制御システム、２１０ ネットワーク、２２０ ルータ、３１２ イベント管理部、３１５，３９０ ＲＯＭ、３２０，３９５ ＲＡＭ、３３０ スピーカ、３３５ マイク、３４０ バッテリ、３６２ イベント情報取得部、３６４，１７２０ 音声認識部、３６６，１７３０ パラメータ決定部、３６８，４１０，１７４０ 楽曲生成部、３８０，１７１０ 記憶装置、３８２，１７１２ イベント履歴テーブル、３８４ パラメータ決定テーブル、４００ 外部装置、１１１０ 機器種別、１２２０ 家テーブル、１２４０ 機器テーブル、１２６０ ユーザテーブル、１２８０ 機器種別テーブル。

Claims (11)

1. サーバ装置であって、
   通信インターフェイスと、
   記憶装置と、
   制御部とを備え、
   前記記憶装置は、前記通信インターフェイスを介して取得した、音声を出力可能な情報処理端末の状態履歴を記憶し、
   前記制御部は、
   前記状態履歴に基づいて楽曲パラメータを決定し、
   前記決定した楽曲パラメータに基づいて生成された楽曲を、前記通信インターフェイスを介して前記情報処理端末に送信するように構成される、サーバ装置。
2. 前記制御部は、
   前記楽曲パラメータに基づいて楽曲を生成するための楽曲生成部を含み、
   前記楽曲生成部で生成された楽曲を前記情報処理端末に送信するように構成される、請求項１に記載のサーバ装置。
3. 前記制御部は、
   前記決定した楽曲パラメータを、楽曲パラメータに基づいて楽曲を生成可能に構成される外部装置に送信し、
   前記外部装置から受信した楽曲を前記情報処理端末に送信するように構成される、請求項１に記載のサーバ装置。
4. 前記通信インターフェイスは、複数種別の情報処理端末と通信可能に構成され、
   前記記憶装置は、前記種別ごとに種別パラメータをさらに記憶するように構成され、
   前記制御部は、
   前記複数種別の情報処理端末のうち、一の情報処理端末の種別に応じた種別パラメータと、前記一の情報処理端末の状態履歴とに基づいて前記楽曲パラメータを決定するように構成される、請求項１〜３のいずれか１項に記載のサーバ装置。
5. 前記記憶装置は、前記情報処理端末のユーザごとに設定されるユーザパラメータをさらに記憶するように構成され、
   前記制御部は、前記ユーザパラメータと前記状態履歴とに基づいて前記楽曲パラメータを決定するように構成される、請求項１〜４のいずれか１項に記載のサーバ装置。
6. 前記制御部は、予め定められた期間内の前記状態履歴に基づいて前記楽曲パラメータを決定するように構成される、請求項１〜５のいずれか１項に記載のサーバ装置。
7. 前記楽曲パラメータは、楽曲のテンポを決定するためのテンポパラメータ、楽曲のジャンルを決定するためのジャンルパラメータ、および楽曲のキーを決定するためのキーパラメータのうち少なくともいずれか１つを含む、請求項１〜６のいずれか１項に記載のサーバ装置。
8. 前記制御部は、前記状態履歴に基づいて履歴楽曲パラメータを算出して、当該算出した履歴楽曲パラメータに応じた確率に基づいて前記楽曲パラメータを決定するように構成される、請求項１〜７のいずれか１項に記載のサーバ装置。
9. 情報処理端末であって、
   音声出力装置と、
   通信インターフェイスと、
   前記通信インターフェイスを介して前記情報処理端末のイベント情報をサーバ装置に送信するように構成される制御部とを備え、
   前記サーバ装置は、
   前記イベント情報の履歴に基づいて楽曲パラメータを決定し、
   前記決定した楽曲パラメータに基づいて生成された楽曲を前記情報処理端末に送信するように構成され、
   前記制御部は、前記通信インターフェイスを介して前記サーバ装置から受信した楽曲を前記音声出力装置から出力するように構成される、情報処理端末。
10. サーバ装置と、情報処理端末とを備えるシステムであって、
    前記サーバ装置は、
    通信インターフェイスと、
    記憶装置と、
    制御部とを含み、
    前記記憶装置は、前記情報処理端末の状態履歴を記憶し、
    前記制御部は、
    前記状態履歴に基づいて楽曲パラメータを決定し、
    前記決定した楽曲パラメータに基づいて生成された楽曲を、前記通信インターフェイスを介して前記情報処理端末に送信するように構成され、
    前記情報処理端末は、
    音声出力装置と、
    前記サーバ装置から受信した楽曲を前記音声出力装置から出力するように構成される制御部とを含む、システム。
11. サーバ装置が、音声を出力可能な情報処理端末に楽曲を送信するための方法であって、
    前記情報処理端末からイベント情報を受信するステップと、
    前記イベント情報の履歴に基づいて楽曲パラメータを決定するステップと、
    前記決定した楽曲パラメータに基づいて生成された楽曲を前記情報処理端末に送信するステップとを備える、方法。

Images