楽曲データ交換フォーマットおよび携帯端末装置
【課題】 複数の要素に対応して楽曲を変更することができ、かつ、ファイルをメモリに書き込むだけで複数の要素と楽曲の対応関係を設定することができる楽曲データ交換フォーマットおよび携帯端末装置を提供する。
【解決手段】 楽曲コントローラ２１は、まず、現在の時刻情報、現在の日付情報、現在の位置情報からなる要素情報を取得する。位置情報はＧＰＳユニットからのデータに基づいてＣＰＵによって生成される。次に、楽曲コントローラ２１は楽曲データファイル２２から要素情報に基づいて楽曲データを選択し、プレイヤー２３へロードする。プレイヤー２３は、携帯電話機に着信があった時、楽曲コントローラ２１から受けた楽曲データ中のイベント列を時間シーケンスに従って順次音源１１へ送信する。音源１１はそのイベント列を受け、楽音信号を生成しスピーカ１２へ出力する。
【解決手段】 楽曲コントローラ２１は、まず、現在の時刻情報、現在の日付情報、現在の位置情報からなる要素情報を取得する。位置情報はＧＰＳユニットからのデータに基づいてＣＰＵによって生成される。次に、楽曲コントローラ２１は楽曲データファイル２２から要素情報に基づいて楽曲データを選択し、プレイヤー２３へロードする。プレイヤー２３は、携帯電話機に着信があった時、楽曲コントローラ２１から受けた楽曲データ中のイベント列を時間シーケンスに従って順次音源１１へ送信する。音源１１はそのイベント列を受け、楽音信号を生成しスピーカ１２へ出力する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば携帯電話機の呼び出し音をＴＰＯ（時間、場所、場合等）に応じて切り換えること等を可能とする楽曲データ交換フォーマットおよび携帯端末装置に関する。
【背景技術】
【０００２】
近年、携帯電話機の音声着信やメール着信の着信音としてユーザが着信音サーバを有するサイトから好みの着信メロディを選択し、ダウンロードして携帯電話機に設定することが行われる。しかし、着信毎に一度設定した着信メロディが繰り返し発音されると、飽きがくるのが避けられず、その場合、ユーザが別の着信メロディをダウンロードして登録し直すことが行われる。
これに対し、特許文献１には、時間によって着信メロディを自動的に変更するようにした装置が記載され、また、特許文献２には、携帯電話機の場所に応じて着信メロディを自動的に変更するようにした装置が記載されている。
【特許文献１】特開2001-197159号公報
【特許文献２】特開2003-333126号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、特許文献１、２に記載される装置は、時間または場所という単一の要素にしか対応できず、複数の要素に対応して着信メロディを変更することはできなかった。また、特許文献１、２の装置は着信メロディファイルを他の端末に移した時に、要素とメロディとの対応関係を再設定する必要があった。
【０００４】
本発明は上記事情を考慮してなされたもので、その目的は、複数の要素に対応して楽曲を変更することができ、かつ、ファイルをメモリに書き込むだけで複数の要素と楽曲の対応関係を設定することができる楽曲データ交換フォーマットおよび携帯端末装置を提供することにある。
【課題を解決するための手段】
【０００５】
この発明は上記の課題を解決するためになされたもので、請求項１に記載の発明は、複数の楽曲データと、再生条件の要素および再生すべき前記複数の楽曲データの対応関係が記録された再生条件要素テーブルとを含むことを特徴とする楽曲データ交換フォーマットである。
請求項２に記載の発明は、請求項１に記載の楽曲データ交換フォーマットにおいて、前記再生条件の要素のうちのどの要素を優先するかを指示する優先度情報を含むことを特徴とする。
【０００６】
請求項３に記載の発明は、複数の楽曲データと、再生条件の要素および再生すべき前記複数の楽曲データの対応関係が記録された再生条件要素テーブルとを含む楽曲データ交換フォーマットファイルを記憶する記憶手段と、要素情報を取得する要素情報取得手段と、前記記憶手段から前記楽曲データ交換フォーマットファイルの楽曲データを読み込んで楽曲を再生する楽音再生手段と、楽曲再生のトリガを受け、前記要素情報取得手段によって取得された現在の要素情報と前記記憶手段内の前記再生条件要素テーブルのいずれかの要素とが合致しているか否かを検査し、合致している場合に合致している要素に対応する楽曲データを前記楽音再生手段へ送信して楽曲を再生させる制御手段とを具備することを特徴とする携帯端末装置である。
【０００７】
請求項４に記載の発明は、請求項３に記載の携帯端末装置において、前記楽曲データ交換フォーマットファイルは前記再生条件の要素のうちのどの要素を優先するかを指示する優先度情報を含み、前記制御手段は前記優先度情報の順に現在の要素情報と前記記憶手段内の前記再生条件要素テーブルの各要素とが合致しているか否かの判断を行うことを特徴とする。
請求項５に記載の発明は、請求項３または請求項４に記載の携帯端末装置において、前記再生条件要素テーブルは時間と楽曲データとの対応関係を記録した時間テーブルを含むことを特徴とする。
【０００８】
請求項６に記載の発明は、請求項３〜請求項５のいずれかの項に記載の携帯端末装置において、前記再生条件要素テーブルは、日付と楽曲データとの対応関係を記録した日付テーブルを含むことを特徴とする。
請求項７に記載の発明は、請求項３〜請求項６のいずれかの項に記載の携帯端末装置において、前記要素情報取得手段は、要素情報として現在位置情報を取得するＧＰＳ装置を有し、前記再生条件要素テーブルは場所と楽曲データとの対応関係を記録した場所テーブルを含むことを特徴とする。
【０００９】
請求項８に記載の発明は、請求項３〜請求項７のいずれかの項に記載の携帯端末装置において、基地局と無線通信回線を介して通信する通信手段を有し、前記通信手段が音声通話またはメールの着信時に前記トリガを前記制御手段へ出力することを特徴とする。
請求項９に記載の発明は、請求項３〜請求項８のいずれかの項に記載の携帯端末装置において、前記楽曲データは、音源駆動用のシーケンスデータであり、前記楽音再生手段は前記シーケンスデータを解読して楽音信号を生成する音源であることを特徴とする。
【００１０】
請求項１０に記載の発明は、請求項３〜請求項８のいずれかの項に記載の携帯端末装置において、前記楽曲データは、サンプリングデータであり、前記楽音再生手段はサンプリングデータをアナログ楽音信号に変換する変換手段であることを特徴とする。
請求項１１に記載の発明は、請求項３〜請求項１０のいずれかの項に記載の携帯端末装置において、前記複数の楽曲データは、歌手単位またはジャンル単位またはカテゴライズされた単位で集められたデータであることを特徴とする。
【００１１】
請求項１２に記載の発明は、請求項３〜請求項１１のいずれかの項に記載の携帯端末装置において、前記記憶手段内の再生条件要素テーブルをユーザの指示に従って書き換える書換手段を有することを特徴とする。
【発明の効果】
【００１２】
この発明によれば、携帯電話機の音声着信音やメール着信音をＴＰＯに応じて自動的に変更することが可能となり、ユーザにとって飽きがこない利点がある。また、歌手単位、ジャンル単位、カテゴリ単位などで楽曲データがパッケージとして提供される場合は、ユーザは１つのパッケージをダウンロードするだけで、複数の要素と楽曲の対応関係を携帯端末装置に設定することができ、飽きがこない変化に富んだ着信音等を設定することができる。また、請求項１２の発明によれば、ユーザが要素と楽曲の対応関係をカスタマイズすることができる効果が得られる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照し、この発明の実施の形態について説明する。図１はこの発明の一実施の形態による携帯端末装置である携帯電話機３０の構成を示すブロック図である。この図において、符号１は各部を制御するＣＰＵ（中央処理装置）、２はＣＰＵ１の処理においてデータが一時記憶される不揮発性ＲＡＭ（ランダムアクセスメモリ）であり、後述する楽曲データ交換フォーマットファイルも記憶されている。３はＣＰＵ１のプログラムおよび地図データが記憶されたＲＯＭ（リードオンリメモリ）である。４は液晶表示器による表示部、５はテンキーおよびファンクションキーからなる操作キー部である。６は通信部であり、アンテナ７を介して受信した高周波信号を復調し、復調によって得られた音声データについては音声処理部８へ出力し、文字データ、記号データ等についてはバスラインＢを介してＣＰＵ１へ出力する。また、この通信部６は、ＣＰＵ１から供給される文字データ等および音声処理部８から出力される音声データによって高周波の搬送波を変調しアンテナ７から発信する。
【００１４】
音声処理部８は、マイクロフォン９から出力される音声信号をディジタル音声データに変換し、さらに圧縮して通信部６へ出力する。また、通信部６から出力される圧縮されたディジタル音声データを伸長し、アナログ信号に変換してイヤスピーカ１０へ出力する。１１は音源であり、バスラインＢを介して供給されるシーケンスデータ（ＭＩＤＩ規格によるデータ）を解読し、ＦＭ（周波数変調）方式またはＷＴ（ウエーブテーブル）方式によって楽音信号を生成し、スピーカ１２へ出力する。１５はＧＰＳユニットであり、ＧＰＳ衛星からの電波に基づいて携帯電話機３０の現在位置を算出し、バスラインＢを介してＣＰＵ１へ出力する。１６はバイブレータであり、ＣＰＵ１からの駆動信号を受けて振動モータを回転させ振動を発生する。
【００１５】
図２はＲＡＭ２内に設定された楽曲データ交換フォーマットファイルＦを示す図である。このファイルＦは、ユーザが携帯電話機３０の通信部６により、楽曲データ交換フォーマットファイルＦを記憶し管理するデータベースを備えた専用サーバに無線通信回線を介してアクセスして携帯電話機３０にダウンロードするものである。ファイルＦ中の各データはチャンク（塊）単位で管理され、各チャンクは各々次のデータを格納している。
Contents Into Chunk：コンテンツ種別やコンテンツ複製許可等のファイル管理用データが 格納される。
Optional Data Chunk(Optin)：再生条件要素テーブル（後述）等の楽曲データ固有の情報 が格納される。
Score Track Chunk＃１〜＃ｎ：楽音を再生するための音色データ、シーケンスデータ等が 格納される。１つのScore Track Chunkが１つの楽曲データに対応し、＃１〜＃ｎがそれ ぞれ楽曲データのＩＤ番号となる。
Setup Data Chunk：音色データやエフェクト設定データ等を格納する。それらは、再生開 始時に音源１１内に設定され、シーケンスデータの解釈に伴って用いられる。
Sequence Data Chunk：シーケンスデータが格納される。シーケンスデータは時間情報を持 つイベントの集合体である。イベントには発音イベント、音色変更イベント、音量変更 イベント、ピッチ変更イベント等がある。
【００１６】
図３は、上述したOptional Data Chunk(Option)内に格納された再生条件要素テーブルを示す図である。Optional Data Chunkは様々な楽曲固有情報が格納されており、これらの情報は、
タグ（２バイト固定）＋サイズ（２バイト固定）＋Ｄａｔａ（可変長）
で定義される。再生条件要素であることを示すタグを予め定義しておく。Ｄａｔａ部には、図３に示す時間テーブルＴ１、日付（月）テーブルＴ２、場所テーブルＴ３、優先度テーブルＴ４等の再生条件要素テーブルが格納されている。それぞれのテーブルは、ＴＰＯに応じた要素毎に再生楽曲ＩＤ（上述のScore Track ChunkのＩＤ番号）が割り付けられている。Defaultは該当する再生条件がないときに割り付けるものである。
【００１７】
次に、上記実施形態による携帯電話機３０の動作を図４〜図６を参照して説明する。なお、この携帯電話機３０における着信音生成動作以外の動作は従来の携帯電話機と同様であり、その説明を省略する。
図４は着信音発生動作を説明するための機能ブロック図であり、以下の説明においては（ ）内に図１のハードウエア構成の対応部分を示す。
楽曲コントローラ２１（ＣＰＵ１）は、まず、現在の時刻情報、現在の日付情報、現在の携帯電話機３０の位置情報からなる要素情報を取得する。現在の時刻情報および日付情報はＣＰＵ１が保持している。また、携帯電話機３０の位置情報はＧＰＳユニット１５からのデータに基づいてＣＰＵ１によって生成される。次に、楽曲コントローラ２１は楽曲データファイル２２（ＲＡＭ２内のファイルＦを指す）から要素情報に基づいて対応する再生楽曲ＩＤが示す楽曲データを選択し、プレイヤー２３（ＣＰＵ１）へロードする。プレイヤー２３は、携帯電話機３０に着信があった時、楽曲コントローラ２１から受けた楽曲データ中のイベント列を時間シーケンスに従って順次音源１１へ送信する。この場合、プレイヤー２３から音源１１へ送信されるデータはＭＩＤＩ規格のデータである。音源１１はそのイベント列を受け、楽音信号を生成しスピーカ１２へ出力する。
【００１８】
図５、図６は上述した動作をさらに詳細に示したフローチャートであり、図６は図５のステップＳ５に続くフローチャートである。以下、このフローチャートに沿って動作を説明する。
ＣＰＵ１は、所定時間が経過する毎に要素情報の取り込みを行う（ステップＳ１、Ｓ２）。すなわち、まず、現在時刻をＲＡＭ２の予め設定された要素情報エリアに書き込み、次に、現在の月日を同エリアに書き込む。次に、ＧＰＳユニット１５から携帯電話機３０の現在位置データを取得し、次いで、その現在位置データが示す位置の周辺の地図データをＲＯＭ３から読み出し、読み出した地図データから現在位置が海岸近郊であるか、山中であるか、首都圏えあるかを検知し、その結果を示す場所データをＲＡＭ２の要素情報エリアに書き込む。
【００１９】
次に、ＣＰＵ１は、ＲＡＭ２のファイルＦの優先度テーブルＴ４にアクセスして優先度１のテーブルを検知し、図３の例の場合、優先度１のテーブルが時間テーブルＴ１であることから、次に、時間テーブルＴ１の各時間データと上述した要素情報エリア内の時間データとを比較する（ステップＳ３）。そして、合致していた場合は（ステップＳ４の判断が「ＹＥＳ］）、着信時に再生する楽曲データの再生楽曲ＩＤとして時間テーブルＴ１において合致した再生楽曲ＩＤを、ＲＡＭ２内に予め設定された再生データエリアに書き込む。例えば、現在時刻が１２時３０分であった場合、時間テーブルＴ１から再生楽曲ＩＤ＃５が読み出され、再生データエリアに書き込まれる。
【００２０】
次に、ＣＰＵ１は着信があったか否かを判断し（ステップＳ６）、着信がない場合は再びステップＳ１、Ｓ２へ戻り、要素データの取り込みを行う。そして、取り込んだ要素データが優先度１のテーブルと合致している場合は再びステップＳ５の処理を行うが、合致しない場合、例えば、現在時刻が１３時３０分になった場合は、次に優先度２の場所テーブルＴ３の各場所データと要素情報エリアに書き込まれた現在位置の場所データとを比較する（ステップＳ７）。そして、現在位置の場所データが、場所テーブルＴ３の場所データのいずれかと一致していた場合は（ステップＳ８の判断が「ＹＥＳ｝）、ＲＡＭ２の上述した再生データエリア内のデータを場所テーブルＴ３において合致した場所データに対応する再生楽曲ＩＤに書き換える（ステップＳ９）。例えば、現在位置が首都圏であった場合は、場所テーブルＴ３の再生楽曲ＩＤ＃１１が読み出され、再生データエリアに書き込まれる。
【００２１】
次に、ステップＳ６へ進み、着信がない場合は再びステップＳ１へ戻る。そして、ステップＳ１、Ｓ２、Ｓ３、Ｓ４が実行され、ステップＳ４の判断が「ＮＯ」であった場合はステップＳ７、Ｓ８が実行され、ステップＳ８の判断も「ＮＯ」であった場合、つまり、現在位置の場所が海岸近郊でも山中でも首都圏でもない場合はステップＳ１０へ進む。ステップＳ１０では、優先度３の日付（月）テーブルＴ２と要素情報エリアに書き込まれた現在の日付（月）データとが比較される（ステップＳ１０）。そして、現在の日付（月）データが、日付（月）テーブルＴ２の月データのいずれかと一致していた場合は（ステップＳ１１の判断が「ＹＥＳ｝）、ＲＡＭ２の上述した再生データエリア内のデータを日付（月）テーブルＴ２において合致した月データに対応する再生楽曲ＩＤに書き換える（ステップＳ１２）。例えば、現在の月データが９月であった場合は、日付（月）テーブルＴ２の再生楽曲ＩＤ＃９が読み出され、再生データエリアに書き込まれる。また、現在の月データが例えば６月あるいは１１月であり、優先度３の日付（月）テーブルＴ２のいずれの月データとも合致しなかった場合は（ステップＳ１１の判断が「ＮＯ」）、再生データエリアを日付（月）テーブルＴ２のDefaultの再生楽曲ＩＤ＃１に書き換える（ステップＳ１３）。そして、ステップＳ６へ進む。
【００２２】
このように、この携帯電話機３０は、一定時間経過毎に要素情報を取り込み、取り込んだ要素情報および図３の再生条件要素テーブルに基づいて再生データエリア内の再生楽曲ＩＤを書き換える。そして、着信があった場合は（ステップＳ６の判断が「ＹＥＳ」）、再生データエリア内の再生楽曲ＩＤのシーケンスデータをＲＡＭ２のファイルＦ（図２）から読み出し、順次、音源１１へ送信する（ステップＳ１４）。これにより、再生データエリア内の再生楽曲ＩＤに対応する楽曲がスピーカ１２から発音される。そして、操作キー部５のオフフックボタンが操作され、あるいは、回線切断が行われると（ステップＳ１５が「ＹＥＳ」）、着信音の再生終了処理が行われる（ステップＳ１６）。
【００２３】
なお、図３に示す再生条件要素テーブル（優先度テーブルを含む）は、前述のサーバにおいて、楽曲データ交換フォーマットファイルＦを作成するためのオーサリングツール上で編集をしてもよいし、あるいは、ユーザの携帯電話機において、ファイルＦをダウンロードした後、ユーザが直接編集できるようにしてもよい。
また、音源１１はＣＰＵ（ＤＳＰ）演算によるソフトウエア方式のものでもよく、あるいは、専用のハードウエア方式のものでもよい。音源のタイプは、ＦＭ音源、ＷＴ音源、ＰＣＭ音源等いずれのタイプのものでもよい。また、上記実施形態はファイルＦに楽曲データとしてシーケンスデータが記録されているが、これに代えて、サンプリングされたオーディオデータや、ＭＰ３等の方式によって圧縮されたオーディオデータを記録しておいてもよい。この場合、音源１１に代えてオーディオデータをアナログ信号に変換する楽音再生装置、あるいは、圧縮されたオーディオデータを伸長しアナログ信号に変換する楽音再生装置を設ければよい。
【００２４】
また、上記実施形態では、３つの要素テーブルを示したが、他の要素テーブル（場合分けや条件を示す要素テーブル等）を適宜追加してもよい。また、上記実施形態においては、ＲＡＭ２の再生データエリア内に、着信に先立って再生楽曲ＩＤを設定するようになっているが、これに代えて、着信を受けてから再生条件要素テーブルに基づいて楽曲ＩＤを決定するようにしてもよい。また、楽曲再生のトリガは音声通話（いわゆる電話）の着信に限らず、メール着信や、ユーザによるボタンＯＮや、ランダムあるいは所定の時間でトリガがかかるようにしてもよい。また、設定時刻にアラームを鳴動させるスケジュールアラーム装置を設け、該スケジュールアラーム装置がアラーム発生時に楽曲再生のトリガを出力するようにしてもよい。
【００２５】
以上がこの発明の一実施形態の詳細である。この発明は次のような利用例が考えられる。
（１）携帯端末機のダウンロードサービスとして、楽曲データ交換フォーマットファイルを歌手単位（または演奏者単位）でパッケージ提供する。その歌手の持つ曲のうち、さわやかな曲であれば時刻を朝に、夏をイメージする曲であれば月を夏（７、８月）に、海をイメージする曲であれば場所を海岸近郊に設定する。これにより、ユーザは、特別な設定をすることなく、自分好みの歌手のＴＰＯに応じた着信メロディを再生することができる。
なお、歌手単位に限らず、他のジャンル単位、その他のカテゴライズされた単位でファイルを作成することも有効である。
【００２６】
（２）再生条件要素テーブルを月日として持ち、ユーザあるいはユーザの近親者の誕生日のみ、特別な曲を設定する。これにより、ユーザは特別な設定をすることなく、誕生日の着信時には、特別な楽曲を再生することができる。また、近親者の誕生日に設定したファイルを、電子メールの添付を利用して近親者宛に送信する。近親者は、このファイルを登録することにより、誕生日の着信時には特別な楽曲を再生することができる。近親者にとって、誕生日の楽しみが増えるし、特別な日であることを感じることができる。
【産業上の利用可能性】
【００２７】
この発明は、主として携帯電話機に用いられる。
【図面の簡単な説明】
【００２８】
【図１】この発明の一実施形態による携帯電話機の構成を示すブロック図である。
【図２】図１におけるＲＡＭ２内に記憶される楽曲データ交換フォーマットファイルＦ示す図である。
【図３】図２におけるOptional Data Chunk内に格納された再生条件要素テーブルを示す図である。
【図４】同実施形態の動作を説明するための機能ブロック図である。
【図５】同実施形態の動作を説明するためのフローチャートである。
【図６】同実施形態の動作を説明するためのフローチャートであり、図５に示すフローチャートの続きである。
【符号の説明】
【００２９】
１…ＣＰＵ、２…ＲＡＭ、３…ＲＯＭ、１１…音源、１２…スピーカ、１５…ＧＰＳユニット、２１…楽曲コントローラ、２２…楽曲データファイル、２３…プレイヤー、３０…携帯電話機、Ｆ…楽曲データ交換フォーマットファイル、Ｔ１…時間テーブル、Ｔ２…日付テーブル、Ｔ３…場所テーブル、Ｔ４…優先度テーブル。
【技術分野】
【０００１】
本発明は、例えば携帯電話機の呼び出し音をＴＰＯ（時間、場所、場合等）に応じて切り換えること等を可能とする楽曲データ交換フォーマットおよび携帯端末装置に関する。
【背景技術】
【０００２】
近年、携帯電話機の音声着信やメール着信の着信音としてユーザが着信音サーバを有するサイトから好みの着信メロディを選択し、ダウンロードして携帯電話機に設定することが行われる。しかし、着信毎に一度設定した着信メロディが繰り返し発音されると、飽きがくるのが避けられず、その場合、ユーザが別の着信メロディをダウンロードして登録し直すことが行われる。
これに対し、特許文献１には、時間によって着信メロディを自動的に変更するようにした装置が記載され、また、特許文献２には、携帯電話機の場所に応じて着信メロディを自動的に変更するようにした装置が記載されている。
【特許文献１】特開2001-197159号公報
【特許文献２】特開2003-333126号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、特許文献１、２に記載される装置は、時間または場所という単一の要素にしか対応できず、複数の要素に対応して着信メロディを変更することはできなかった。また、特許文献１、２の装置は着信メロディファイルを他の端末に移した時に、要素とメロディとの対応関係を再設定する必要があった。
【０００４】
本発明は上記事情を考慮してなされたもので、その目的は、複数の要素に対応して楽曲を変更することができ、かつ、ファイルをメモリに書き込むだけで複数の要素と楽曲の対応関係を設定することができる楽曲データ交換フォーマットおよび携帯端末装置を提供することにある。
【課題を解決するための手段】
【０００５】
この発明は上記の課題を解決するためになされたもので、請求項１に記載の発明は、複数の楽曲データと、再生条件の要素および再生すべき前記複数の楽曲データの対応関係が記録された再生条件要素テーブルとを含むことを特徴とする楽曲データ交換フォーマットである。
請求項２に記載の発明は、請求項１に記載の楽曲データ交換フォーマットにおいて、前記再生条件の要素のうちのどの要素を優先するかを指示する優先度情報を含むことを特徴とする。
【０００６】
請求項３に記載の発明は、複数の楽曲データと、再生条件の要素および再生すべき前記複数の楽曲データの対応関係が記録された再生条件要素テーブルとを含む楽曲データ交換フォーマットファイルを記憶する記憶手段と、要素情報を取得する要素情報取得手段と、前記記憶手段から前記楽曲データ交換フォーマットファイルの楽曲データを読み込んで楽曲を再生する楽音再生手段と、楽曲再生のトリガを受け、前記要素情報取得手段によって取得された現在の要素情報と前記記憶手段内の前記再生条件要素テーブルのいずれかの要素とが合致しているか否かを検査し、合致している場合に合致している要素に対応する楽曲データを前記楽音再生手段へ送信して楽曲を再生させる制御手段とを具備することを特徴とする携帯端末装置である。
【０００７】
請求項４に記載の発明は、請求項３に記載の携帯端末装置において、前記楽曲データ交換フォーマットファイルは前記再生条件の要素のうちのどの要素を優先するかを指示する優先度情報を含み、前記制御手段は前記優先度情報の順に現在の要素情報と前記記憶手段内の前記再生条件要素テーブルの各要素とが合致しているか否かの判断を行うことを特徴とする。
請求項５に記載の発明は、請求項３または請求項４に記載の携帯端末装置において、前記再生条件要素テーブルは時間と楽曲データとの対応関係を記録した時間テーブルを含むことを特徴とする。
【０００８】
請求項６に記載の発明は、請求項３〜請求項５のいずれかの項に記載の携帯端末装置において、前記再生条件要素テーブルは、日付と楽曲データとの対応関係を記録した日付テーブルを含むことを特徴とする。
請求項７に記載の発明は、請求項３〜請求項６のいずれかの項に記載の携帯端末装置において、前記要素情報取得手段は、要素情報として現在位置情報を取得するＧＰＳ装置を有し、前記再生条件要素テーブルは場所と楽曲データとの対応関係を記録した場所テーブルを含むことを特徴とする。
【０００９】
請求項８に記載の発明は、請求項３〜請求項７のいずれかの項に記載の携帯端末装置において、基地局と無線通信回線を介して通信する通信手段を有し、前記通信手段が音声通話またはメールの着信時に前記トリガを前記制御手段へ出力することを特徴とする。
請求項９に記載の発明は、請求項３〜請求項８のいずれかの項に記載の携帯端末装置において、前記楽曲データは、音源駆動用のシーケンスデータであり、前記楽音再生手段は前記シーケンスデータを解読して楽音信号を生成する音源であることを特徴とする。
【００１０】
請求項１０に記載の発明は、請求項３〜請求項８のいずれかの項に記載の携帯端末装置において、前記楽曲データは、サンプリングデータであり、前記楽音再生手段はサンプリングデータをアナログ楽音信号に変換する変換手段であることを特徴とする。
請求項１１に記載の発明は、請求項３〜請求項１０のいずれかの項に記載の携帯端末装置において、前記複数の楽曲データは、歌手単位またはジャンル単位またはカテゴライズされた単位で集められたデータであることを特徴とする。
【００１１】
請求項１２に記載の発明は、請求項３〜請求項１１のいずれかの項に記載の携帯端末装置において、前記記憶手段内の再生条件要素テーブルをユーザの指示に従って書き換える書換手段を有することを特徴とする。
【発明の効果】
【００１２】
この発明によれば、携帯電話機の音声着信音やメール着信音をＴＰＯに応じて自動的に変更することが可能となり、ユーザにとって飽きがこない利点がある。また、歌手単位、ジャンル単位、カテゴリ単位などで楽曲データがパッケージとして提供される場合は、ユーザは１つのパッケージをダウンロードするだけで、複数の要素と楽曲の対応関係を携帯端末装置に設定することができ、飽きがこない変化に富んだ着信音等を設定することができる。また、請求項１２の発明によれば、ユーザが要素と楽曲の対応関係をカスタマイズすることができる効果が得られる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照し、この発明の実施の形態について説明する。図１はこの発明の一実施の形態による携帯端末装置である携帯電話機３０の構成を示すブロック図である。この図において、符号１は各部を制御するＣＰＵ（中央処理装置）、２はＣＰＵ１の処理においてデータが一時記憶される不揮発性ＲＡＭ（ランダムアクセスメモリ）であり、後述する楽曲データ交換フォーマットファイルも記憶されている。３はＣＰＵ１のプログラムおよび地図データが記憶されたＲＯＭ（リードオンリメモリ）である。４は液晶表示器による表示部、５はテンキーおよびファンクションキーからなる操作キー部である。６は通信部であり、アンテナ７を介して受信した高周波信号を復調し、復調によって得られた音声データについては音声処理部８へ出力し、文字データ、記号データ等についてはバスラインＢを介してＣＰＵ１へ出力する。また、この通信部６は、ＣＰＵ１から供給される文字データ等および音声処理部８から出力される音声データによって高周波の搬送波を変調しアンテナ７から発信する。
【００１４】
音声処理部８は、マイクロフォン９から出力される音声信号をディジタル音声データに変換し、さらに圧縮して通信部６へ出力する。また、通信部６から出力される圧縮されたディジタル音声データを伸長し、アナログ信号に変換してイヤスピーカ１０へ出力する。１１は音源であり、バスラインＢを介して供給されるシーケンスデータ（ＭＩＤＩ規格によるデータ）を解読し、ＦＭ（周波数変調）方式またはＷＴ（ウエーブテーブル）方式によって楽音信号を生成し、スピーカ１２へ出力する。１５はＧＰＳユニットであり、ＧＰＳ衛星からの電波に基づいて携帯電話機３０の現在位置を算出し、バスラインＢを介してＣＰＵ１へ出力する。１６はバイブレータであり、ＣＰＵ１からの駆動信号を受けて振動モータを回転させ振動を発生する。
【００１５】
図２はＲＡＭ２内に設定された楽曲データ交換フォーマットファイルＦを示す図である。このファイルＦは、ユーザが携帯電話機３０の通信部６により、楽曲データ交換フォーマットファイルＦを記憶し管理するデータベースを備えた専用サーバに無線通信回線を介してアクセスして携帯電話機３０にダウンロードするものである。ファイルＦ中の各データはチャンク（塊）単位で管理され、各チャンクは各々次のデータを格納している。
Contents Into Chunk：コンテンツ種別やコンテンツ複製許可等のファイル管理用データが 格納される。
Optional Data Chunk(Optin)：再生条件要素テーブル（後述）等の楽曲データ固有の情報 が格納される。
Score Track Chunk＃１〜＃ｎ：楽音を再生するための音色データ、シーケンスデータ等が 格納される。１つのScore Track Chunkが１つの楽曲データに対応し、＃１〜＃ｎがそれ ぞれ楽曲データのＩＤ番号となる。
Setup Data Chunk：音色データやエフェクト設定データ等を格納する。それらは、再生開 始時に音源１１内に設定され、シーケンスデータの解釈に伴って用いられる。
Sequence Data Chunk：シーケンスデータが格納される。シーケンスデータは時間情報を持 つイベントの集合体である。イベントには発音イベント、音色変更イベント、音量変更 イベント、ピッチ変更イベント等がある。
【００１６】
図３は、上述したOptional Data Chunk(Option)内に格納された再生条件要素テーブルを示す図である。Optional Data Chunkは様々な楽曲固有情報が格納されており、これらの情報は、
タグ（２バイト固定）＋サイズ（２バイト固定）＋Ｄａｔａ（可変長）
で定義される。再生条件要素であることを示すタグを予め定義しておく。Ｄａｔａ部には、図３に示す時間テーブルＴ１、日付（月）テーブルＴ２、場所テーブルＴ３、優先度テーブルＴ４等の再生条件要素テーブルが格納されている。それぞれのテーブルは、ＴＰＯに応じた要素毎に再生楽曲ＩＤ（上述のScore Track ChunkのＩＤ番号）が割り付けられている。Defaultは該当する再生条件がないときに割り付けるものである。
【００１７】
次に、上記実施形態による携帯電話機３０の動作を図４〜図６を参照して説明する。なお、この携帯電話機３０における着信音生成動作以外の動作は従来の携帯電話機と同様であり、その説明を省略する。
図４は着信音発生動作を説明するための機能ブロック図であり、以下の説明においては（ ）内に図１のハードウエア構成の対応部分を示す。
楽曲コントローラ２１（ＣＰＵ１）は、まず、現在の時刻情報、現在の日付情報、現在の携帯電話機３０の位置情報からなる要素情報を取得する。現在の時刻情報および日付情報はＣＰＵ１が保持している。また、携帯電話機３０の位置情報はＧＰＳユニット１５からのデータに基づいてＣＰＵ１によって生成される。次に、楽曲コントローラ２１は楽曲データファイル２２（ＲＡＭ２内のファイルＦを指す）から要素情報に基づいて対応する再生楽曲ＩＤが示す楽曲データを選択し、プレイヤー２３（ＣＰＵ１）へロードする。プレイヤー２３は、携帯電話機３０に着信があった時、楽曲コントローラ２１から受けた楽曲データ中のイベント列を時間シーケンスに従って順次音源１１へ送信する。この場合、プレイヤー２３から音源１１へ送信されるデータはＭＩＤＩ規格のデータである。音源１１はそのイベント列を受け、楽音信号を生成しスピーカ１２へ出力する。
【００１８】
図５、図６は上述した動作をさらに詳細に示したフローチャートであり、図６は図５のステップＳ５に続くフローチャートである。以下、このフローチャートに沿って動作を説明する。
ＣＰＵ１は、所定時間が経過する毎に要素情報の取り込みを行う（ステップＳ１、Ｓ２）。すなわち、まず、現在時刻をＲＡＭ２の予め設定された要素情報エリアに書き込み、次に、現在の月日を同エリアに書き込む。次に、ＧＰＳユニット１５から携帯電話機３０の現在位置データを取得し、次いで、その現在位置データが示す位置の周辺の地図データをＲＯＭ３から読み出し、読み出した地図データから現在位置が海岸近郊であるか、山中であるか、首都圏えあるかを検知し、その結果を示す場所データをＲＡＭ２の要素情報エリアに書き込む。
【００１９】
次に、ＣＰＵ１は、ＲＡＭ２のファイルＦの優先度テーブルＴ４にアクセスして優先度１のテーブルを検知し、図３の例の場合、優先度１のテーブルが時間テーブルＴ１であることから、次に、時間テーブルＴ１の各時間データと上述した要素情報エリア内の時間データとを比較する（ステップＳ３）。そして、合致していた場合は（ステップＳ４の判断が「ＹＥＳ］）、着信時に再生する楽曲データの再生楽曲ＩＤとして時間テーブルＴ１において合致した再生楽曲ＩＤを、ＲＡＭ２内に予め設定された再生データエリアに書き込む。例えば、現在時刻が１２時３０分であった場合、時間テーブルＴ１から再生楽曲ＩＤ＃５が読み出され、再生データエリアに書き込まれる。
【００２０】
次に、ＣＰＵ１は着信があったか否かを判断し（ステップＳ６）、着信がない場合は再びステップＳ１、Ｓ２へ戻り、要素データの取り込みを行う。そして、取り込んだ要素データが優先度１のテーブルと合致している場合は再びステップＳ５の処理を行うが、合致しない場合、例えば、現在時刻が１３時３０分になった場合は、次に優先度２の場所テーブルＴ３の各場所データと要素情報エリアに書き込まれた現在位置の場所データとを比較する（ステップＳ７）。そして、現在位置の場所データが、場所テーブルＴ３の場所データのいずれかと一致していた場合は（ステップＳ８の判断が「ＹＥＳ｝）、ＲＡＭ２の上述した再生データエリア内のデータを場所テーブルＴ３において合致した場所データに対応する再生楽曲ＩＤに書き換える（ステップＳ９）。例えば、現在位置が首都圏であった場合は、場所テーブルＴ３の再生楽曲ＩＤ＃１１が読み出され、再生データエリアに書き込まれる。
【００２１】
次に、ステップＳ６へ進み、着信がない場合は再びステップＳ１へ戻る。そして、ステップＳ１、Ｓ２、Ｓ３、Ｓ４が実行され、ステップＳ４の判断が「ＮＯ」であった場合はステップＳ７、Ｓ８が実行され、ステップＳ８の判断も「ＮＯ」であった場合、つまり、現在位置の場所が海岸近郊でも山中でも首都圏でもない場合はステップＳ１０へ進む。ステップＳ１０では、優先度３の日付（月）テーブルＴ２と要素情報エリアに書き込まれた現在の日付（月）データとが比較される（ステップＳ１０）。そして、現在の日付（月）データが、日付（月）テーブルＴ２の月データのいずれかと一致していた場合は（ステップＳ１１の判断が「ＹＥＳ｝）、ＲＡＭ２の上述した再生データエリア内のデータを日付（月）テーブルＴ２において合致した月データに対応する再生楽曲ＩＤに書き換える（ステップＳ１２）。例えば、現在の月データが９月であった場合は、日付（月）テーブルＴ２の再生楽曲ＩＤ＃９が読み出され、再生データエリアに書き込まれる。また、現在の月データが例えば６月あるいは１１月であり、優先度３の日付（月）テーブルＴ２のいずれの月データとも合致しなかった場合は（ステップＳ１１の判断が「ＮＯ」）、再生データエリアを日付（月）テーブルＴ２のDefaultの再生楽曲ＩＤ＃１に書き換える（ステップＳ１３）。そして、ステップＳ６へ進む。
【００２２】
このように、この携帯電話機３０は、一定時間経過毎に要素情報を取り込み、取り込んだ要素情報および図３の再生条件要素テーブルに基づいて再生データエリア内の再生楽曲ＩＤを書き換える。そして、着信があった場合は（ステップＳ６の判断が「ＹＥＳ」）、再生データエリア内の再生楽曲ＩＤのシーケンスデータをＲＡＭ２のファイルＦ（図２）から読み出し、順次、音源１１へ送信する（ステップＳ１４）。これにより、再生データエリア内の再生楽曲ＩＤに対応する楽曲がスピーカ１２から発音される。そして、操作キー部５のオフフックボタンが操作され、あるいは、回線切断が行われると（ステップＳ１５が「ＹＥＳ」）、着信音の再生終了処理が行われる（ステップＳ１６）。
【００２３】
なお、図３に示す再生条件要素テーブル（優先度テーブルを含む）は、前述のサーバにおいて、楽曲データ交換フォーマットファイルＦを作成するためのオーサリングツール上で編集をしてもよいし、あるいは、ユーザの携帯電話機において、ファイルＦをダウンロードした後、ユーザが直接編集できるようにしてもよい。
また、音源１１はＣＰＵ（ＤＳＰ）演算によるソフトウエア方式のものでもよく、あるいは、専用のハードウエア方式のものでもよい。音源のタイプは、ＦＭ音源、ＷＴ音源、ＰＣＭ音源等いずれのタイプのものでもよい。また、上記実施形態はファイルＦに楽曲データとしてシーケンスデータが記録されているが、これに代えて、サンプリングされたオーディオデータや、ＭＰ３等の方式によって圧縮されたオーディオデータを記録しておいてもよい。この場合、音源１１に代えてオーディオデータをアナログ信号に変換する楽音再生装置、あるいは、圧縮されたオーディオデータを伸長しアナログ信号に変換する楽音再生装置を設ければよい。
【００２４】
また、上記実施形態では、３つの要素テーブルを示したが、他の要素テーブル（場合分けや条件を示す要素テーブル等）を適宜追加してもよい。また、上記実施形態においては、ＲＡＭ２の再生データエリア内に、着信に先立って再生楽曲ＩＤを設定するようになっているが、これに代えて、着信を受けてから再生条件要素テーブルに基づいて楽曲ＩＤを決定するようにしてもよい。また、楽曲再生のトリガは音声通話（いわゆる電話）の着信に限らず、メール着信や、ユーザによるボタンＯＮや、ランダムあるいは所定の時間でトリガがかかるようにしてもよい。また、設定時刻にアラームを鳴動させるスケジュールアラーム装置を設け、該スケジュールアラーム装置がアラーム発生時に楽曲再生のトリガを出力するようにしてもよい。
【００２５】
以上がこの発明の一実施形態の詳細である。この発明は次のような利用例が考えられる。
（１）携帯端末機のダウンロードサービスとして、楽曲データ交換フォーマットファイルを歌手単位（または演奏者単位）でパッケージ提供する。その歌手の持つ曲のうち、さわやかな曲であれば時刻を朝に、夏をイメージする曲であれば月を夏（７、８月）に、海をイメージする曲であれば場所を海岸近郊に設定する。これにより、ユーザは、特別な設定をすることなく、自分好みの歌手のＴＰＯに応じた着信メロディを再生することができる。
なお、歌手単位に限らず、他のジャンル単位、その他のカテゴライズされた単位でファイルを作成することも有効である。
【００２６】
（２）再生条件要素テーブルを月日として持ち、ユーザあるいはユーザの近親者の誕生日のみ、特別な曲を設定する。これにより、ユーザは特別な設定をすることなく、誕生日の着信時には、特別な楽曲を再生することができる。また、近親者の誕生日に設定したファイルを、電子メールの添付を利用して近親者宛に送信する。近親者は、このファイルを登録することにより、誕生日の着信時には特別な楽曲を再生することができる。近親者にとって、誕生日の楽しみが増えるし、特別な日であることを感じることができる。
【産業上の利用可能性】
【００２７】
この発明は、主として携帯電話機に用いられる。
【図面の簡単な説明】
【００２８】
【図１】この発明の一実施形態による携帯電話機の構成を示すブロック図である。
【図２】図１におけるＲＡＭ２内に記憶される楽曲データ交換フォーマットファイルＦ示す図である。
【図３】図２におけるOptional Data Chunk内に格納された再生条件要素テーブルを示す図である。
【図４】同実施形態の動作を説明するための機能ブロック図である。
【図５】同実施形態の動作を説明するためのフローチャートである。
【図６】同実施形態の動作を説明するためのフローチャートであり、図５に示すフローチャートの続きである。
【符号の説明】
【００２９】
１…ＣＰＵ、２…ＲＡＭ、３…ＲＯＭ、１１…音源、１２…スピーカ、１５…ＧＰＳユニット、２１…楽曲コントローラ、２２…楽曲データファイル、２３…プレイヤー、３０…携帯電話機、Ｆ…楽曲データ交換フォーマットファイル、Ｔ１…時間テーブル、Ｔ２…日付テーブル、Ｔ３…場所テーブル、Ｔ４…優先度テーブル。
【特許請求の範囲】
【請求項１】
複数の楽曲データと、再生条件の要素および再生すべき前記複数の楽曲データの対応関係が記録された再生条件要素テーブルとを含むことを特徴とする楽曲データ交換フォーマット。
【請求項２】
前記再生条件の要素のうちのどの要素を優先するかを指示する優先度情報を含むことを特徴とする請求項１に記載の楽曲データ交換フォーマット。
【請求項３】
複数の楽曲データと、再生条件の要素および再生すべき前記複数の楽曲データの対応関係が記録された再生条件要素テーブルとを含む楽曲データ交換フォーマットファイルを記憶する記憶手段と、
要素情報を取得する要素情報取得手段と、
前記記憶手段から前記楽曲データ交換フォーマットファイルの楽曲データを読み込んで楽曲を再生する楽音再生手段と、
楽曲再生のトリガを受け、前記要素情報取得手段によって取得された現在の要素情報と前記記憶手段内の前記再生条件要素テーブルのいずれかの要素とが合致しているか否かを検査し、合致している場合に合致している要素に対応する楽曲データを前記楽音再生手段へ送信して楽曲を再生させる制御手段と、
を具備することを特徴とする携帯端末装置。
【請求項４】
前記楽曲データ交換フォーマットファイルは前記再生条件の要素のうちのどの要素を優先するかを指示する優先度情報を含み、前記制御手段は前記優先度情報の順に現在の要素情報と前記記憶手段内の前記再生条件要素テーブルの各要素とが合致しているか否かの判断を行うことを特徴とする請求項３に記載の携帯端末装置。
【請求項５】
前記再生条件要素テーブルは時間と楽曲データとの対応関係を記録した時間テーブルを含むことを特徴とする請求項３または請求項４に記載の携帯端末装置。
【請求項６】
前記再生条件要素テーブルは、日付と楽曲データとの対応関係を記録した日付テーブルを含むことを特徴とする請求項３〜請求項５のいずれかの項に記載の携帯端末装置。
【請求項７】
前記要素情報取得手段は、要素情報として現在位置情報を取得するＧＰＳ装置を有し、
前記再生条件要素テーブルは場所と楽曲データとの対応関係を記録した場所テーブルを含むことを特徴とする請求項３〜請求項６のいずれかの項に記載の携帯端末装置。
【請求項８】
基地局と無線通信回線を介して通信する通信手段を有し、前記通信手段が音声通話またはメールの着信時に前記トリガを前記制御手段へ出力することを特徴とする請求項３〜請求項７のいずれかの項に記載の携帯端末装置。
【請求項９】
前記楽曲データは、音源駆動用のシーケンスデータであり、前記楽音再生手段は前記シーケンスデータを解読して楽音信号を生成する音源であることを特徴とする請求項３〜請求項８のいずれかの項に記載の携帯端末装置。
【請求項１０】
前記楽曲データは、サンプリングデータであり、前記楽音再生手段はサンプリングデータをアナログ楽音信号に変換する変換手段であることを特徴とする請求項３〜請求項８のいずれかの項に記載の携帯端末装置。
【請求項１１】
前記複数の楽曲データは、歌手単位またはジャンル単位またはカテゴライズされた単位で集められたデータであることを特徴とする請求項３〜請求項１０のいずれかの項に記載の携帯端末装置。
【請求項１２】
前記記憶手段内の再生条件要素テーブルをユーザの指示に従って書き換える書換手段を有することを特徴とする請求項３〜請求項１１のいずれかの項に記載の携帯端末装置。
【請求項１】
複数の楽曲データと、再生条件の要素および再生すべき前記複数の楽曲データの対応関係が記録された再生条件要素テーブルとを含むことを特徴とする楽曲データ交換フォーマット。
【請求項２】
前記再生条件の要素のうちのどの要素を優先するかを指示する優先度情報を含むことを特徴とする請求項１に記載の楽曲データ交換フォーマット。
【請求項３】
複数の楽曲データと、再生条件の要素および再生すべき前記複数の楽曲データの対応関係が記録された再生条件要素テーブルとを含む楽曲データ交換フォーマットファイルを記憶する記憶手段と、
要素情報を取得する要素情報取得手段と、
前記記憶手段から前記楽曲データ交換フォーマットファイルの楽曲データを読み込んで楽曲を再生する楽音再生手段と、
楽曲再生のトリガを受け、前記要素情報取得手段によって取得された現在の要素情報と前記記憶手段内の前記再生条件要素テーブルのいずれかの要素とが合致しているか否かを検査し、合致している場合に合致している要素に対応する楽曲データを前記楽音再生手段へ送信して楽曲を再生させる制御手段と、
を具備することを特徴とする携帯端末装置。
【請求項４】
前記楽曲データ交換フォーマットファイルは前記再生条件の要素のうちのどの要素を優先するかを指示する優先度情報を含み、前記制御手段は前記優先度情報の順に現在の要素情報と前記記憶手段内の前記再生条件要素テーブルの各要素とが合致しているか否かの判断を行うことを特徴とする請求項３に記載の携帯端末装置。
【請求項５】
前記再生条件要素テーブルは時間と楽曲データとの対応関係を記録した時間テーブルを含むことを特徴とする請求項３または請求項４に記載の携帯端末装置。
【請求項６】
前記再生条件要素テーブルは、日付と楽曲データとの対応関係を記録した日付テーブルを含むことを特徴とする請求項３〜請求項５のいずれかの項に記載の携帯端末装置。
【請求項７】
前記要素情報取得手段は、要素情報として現在位置情報を取得するＧＰＳ装置を有し、
前記再生条件要素テーブルは場所と楽曲データとの対応関係を記録した場所テーブルを含むことを特徴とする請求項３〜請求項６のいずれかの項に記載の携帯端末装置。
【請求項８】
基地局と無線通信回線を介して通信する通信手段を有し、前記通信手段が音声通話またはメールの着信時に前記トリガを前記制御手段へ出力することを特徴とする請求項３〜請求項７のいずれかの項に記載の携帯端末装置。
【請求項９】
前記楽曲データは、音源駆動用のシーケンスデータであり、前記楽音再生手段は前記シーケンスデータを解読して楽音信号を生成する音源であることを特徴とする請求項３〜請求項８のいずれかの項に記載の携帯端末装置。
【請求項１０】
前記楽曲データは、サンプリングデータであり、前記楽音再生手段はサンプリングデータをアナログ楽音信号に変換する変換手段であることを特徴とする請求項３〜請求項８のいずれかの項に記載の携帯端末装置。
【請求項１１】
前記複数の楽曲データは、歌手単位またはジャンル単位またはカテゴライズされた単位で集められたデータであることを特徴とする請求項３〜請求項１０のいずれかの項に記載の携帯端末装置。
【請求項１２】
前記記憶手段内の再生条件要素テーブルをユーザの指示に従って書き換える書換手段を有することを特徴とする請求項３〜請求項１１のいずれかの項に記載の携帯端末装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００６−１５４０８７（Ｐ２００６−１５４０８７Ａ）
【公開日】平成１８年６月１５日（２００６．６．１５）
【国際特許分類】
【出願番号】特願２００４−３４２３５９（Ｐ２００４−３４２３５９）
【出願日】平成１６年１１月２６日（２００４．１１．２６）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
【公開日】平成１８年６月１５日（２００６．６．１５）
【国際特許分類】
【出願日】平成１６年１１月２６日（２００４．１１．２６）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
[ Back to top ]