JP5630447B2 - カラオケシステム - Google Patents

Description

本発明は、同一カラオケ楽曲について複数回歌唱した歌唱データをサーバへ投稿するカラオケシステムに関する。

従来、カラオケ装置で歌唱したカラオケ楽曲の歌唱データをサーバへ投稿し、その投稿したカラオケ楽曲の歌唱データを他のカラオケ装置へダウンロードして、再生することを可能としたカラオケシステムが知られている（例えば、特許文献１参照）。

特許文献１のカラオケシステムでは、ダウロードしたカラオケ楽曲の歌唱データに同一カラオケ楽曲の歌唱データを追加して投稿したり、自分が投稿した歌唱データを削除したりする等の編集を行って再投稿することが可能である。

特開２０１０−１４８２３号公報

近年、同一カラオケ楽曲についてユーザが複数回歌唱して各回ごとに重ね合わせるように録音し、その録音した歌唱データをサーバへ投稿して公開可能とするサービスが提唱されつつある。このサービスにおいて、歌唱データを投稿した後、各歌唱データを個々に削除したり、パラメータ調整等の編集を行ったりできれば、ユーザにとって非常に便利である。しかしながら、上記特許文献１では、そのような点までは特に配慮されていなかった。

本発明の目的は、同一カラオケ楽曲についての複数の歌唱データを投稿した後、各歌唱データごとに編集することができるカラオケシステムを提供することにある。

上記目的を達成するために、第１の発明は、カラオケ楽曲を再生可能であり、且つ、特定のカラオケ楽曲について、歌唱者により歌唱される歌唱音を複数回録音可能であり、且つ、前記特定のカラオケ楽曲について、歌唱者により過去に録音された少なくとも１つの第１歌唱音に重ねて、新たに入力される第２歌唱音を合わせて出力可能なカラオケ装置と、ネットワークを介して前記カラオケ装置と接続可能なサーバと、を備えるカラオケシステムであって、前記カラオケ装置は、前記サーバから前記第１歌唱データをダウンロードするダウンロード手段と、前記特定のカラオケ楽曲について録音可能な複数回の歌唱ごとに、歌唱者により歌唱された前記第２歌唱音を取得する歌唱音取得手段と、前記歌唱音取得手段が録音可能な複数回の歌唱ごとに前記第２歌唱音を取得するのにしたがい、前記第２歌唱音の歌唱者を撮影可能な撮影手段により撮影された映像データを取得する映像取得手段と、前記映像取得手段により取得された各回の映像データのうち、１つの映像データを決定する映像決定手段と、複数回の録音可能な回数ごとに、前記歌唱音取得手段により取得された前記第２歌唱音を示す第２歌唱データと、前記第２歌唱音に重ねて出力された前記第１歌唱音を示す第１歌唱データとを、各回の歌唱データを互いに合成されることなく、互いに独立しつつ１つの歌唱データフォルダ内にグループ化した歌唱データフォルダに、前記映像決定手段により決定された映像データが組み込まれることで形成される動画データフォルダにして、録音歌唱データとして記憶する記憶手段と、前記特定のカラオケ楽曲について、複数回録音された前記録音歌唱データの中から、ネットワークに公開するための録音歌唱データを決定する決定手段と、前記決定手段により決定された録音歌唱データと、決定された録音歌唱データと合わせて前記記憶手段に記憶された複数回の前記第１歌唱データまたは前記第２歌唱データと、を、ネットワークに接続される前記サーバへ投稿する投稿手段と、を備え、前記サーバは、前記決定手段により決定され、前記ネットワークへ公開された録音歌唱データについて、前記カラオケ装置または前記カラオケシステムに接続可能な端末装置から要求された前記録音歌唱データの編集要求を受信する受信手段と、前記受信手段により受信された編集要求に基づいて、ネットワークへ公開された録音歌唱データに対応付けられた前記第１歌唱データ及び前記第２歌唱データを用いて編集処理を実行する実行手段と、前記実行手段により編集処理が実行された結果、編集された前記第１歌唱データまたは前記第２歌唱データを、ネットワークへ公開する公開手段と、を備え、前記投稿手段は、前記ダウンロード手段によりダウンロードした前記第１歌唱データに、前記第２歌唱データと、前記第２歌唱データに示される前記第２歌唱音を歌唱した歌唱者を撮影した前記映像データと、を対応付けて、各回の歌唱データを互いに合成されることなく、互いに独立しつつ１つの歌唱データフォルダ内にグループ化した歌唱データフォルダに、映像データが組み込まれることで形成される動画データフォルダにして、前記サーバヘ投稿することを特徴とする。

本願第１発明のカラオケシステムは、サーバに対してネットワークをかいして接続されたカラオケ装置と、を有している。カラオケ装置は、歌唱音取得手段と、記憶手段と、決定手段と、投稿手段と、を備え、サーバは、受信手段と、実行手段と、公開手段と、を備えている。

歌唱者（同一利用者でもよいし、複数利用者でもよい）が同一の特定カラオケ楽曲について複数回歌唱すると、カラオケ装置の歌唱音取得手段が、その複数回歌唱された歌唱音を示す歌唱データを取得する。このとき、当該カラオケ装置は歌唱者により歌唱される歌唱音を複数回録音可能に構成されている。これに対応して、歌唱音取得手段は、過去に録音された第１歌唱音や、第１歌唱音に重ねて新たに入力される第２歌唱音を取得する。そして、上記のようにして複数回録音される都度、第１歌唱音に対応した第１歌唱データと、第２歌唱音に対応した第２歌唱データとが、対応付けられ、録音歌唱データ（いわゆる録音ＩＤ）を付して記憶手段に記憶される。

そして、決定手段によって、上記複数回録音された録音歌唱データのうち、ユーザ（例えば第２歌唱者等）がネットワークでの公開を希望する録音歌唱データが決定される。これに対応して、投稿手段が、上記決定された録音歌唱データと、この録音歌唱データに対応して記憶手段に記憶されている第１歌唱データまたは第２歌唱データと、をサーバへ投稿する。サーバにおいて、投稿されたデータに係わる第１または第２歌唱データの検閲処理やアップロード処理等の所定の処理が行われると、その処理結果が例えば上記ユーザの操作端末へ送信される。その結果、適宜、ユーザによる編集要求が操作端末からサーバへと送信される。

このとき、本願第１発明においては、カラオケ装置は、さらに、映像データ取得手段を有する。歌唱者が、特定カラオケ楽曲を歌唱する歌唱時、歌唱者を含む所定範囲をカメラで撮影すると、歌唱音取得手段が第２歌唱者による特定カラオケ楽曲の複数回の歌唱ごとに第２歌唱音を取得するときに、映像データ取得手段が、当該複数回の特定カラオケ楽曲の歌唱時における第２歌唱者が撮影された映像データを取得する。特に、本願第１発明においては、カラオケ装置は、さらに、選択手段を有する。歌唱者が、複数回の特定カラオケ楽曲を歌唱する歌唱時、歌唱者を含む所定範囲をカメラで撮影すると、上述したように映像データ取得手段が、当該複数回の特定カラオケ楽曲の歌唱時における第２歌唱者が撮影された映像データを取得する。そして、選択手段が、取得された各回の映像データのうち１つの映像データを選択する。そして、記憶手段が、上記複数回の回数ごとに、第２歌唱データと、第１歌唱データと、上記選択された１つの映像データとを、互いに対応付けて、さらに録音歌唱データ（いわゆる録音ＩＤ）を付して記憶する。本願第１発明のカラオケシステムのサーバは、受信手段と、実行手段と、公開手段と、を有する。これにより、ユーザは、複数の歌唱データを含むデータを投稿して公開しようとするとき、ダウンロードした第１歌唱データに、第２歌唱データと、第２歌唱データに示される第２歌唱音を歌唱した歌唱者を撮影した映像データと、を対応付けて、各回の歌唱データを互いに合成されることなく、互いに独立しつつ１つの歌唱データフォルダ内にグループ化した歌唱データフォルダに、前記映像決定手段により決定された映像データが組み込まれることで形成される動画データフォルダにして投稿することができる。特に、ユーザは、複数回のうちいずれかの回における歌唱者の歌唱している姿を含む映像データを、互いに合成されることなく、互いに独立しつつ１つの歌唱データフォルダ内にグループ化した歌唱データと併せて投稿することができる。そして、上記映像データとともに投稿された上記第１歌唱データ又は第２歌唱データについては、上記編集要求において、複数回録音された録音歌唱データのうち、所望の特定の回数の録音歌唱データに対応した特定の歌唱データ（第１歌唱データまたは第２歌唱データ）の削除やパラメータ変更等の適宜の指示を行う。これにより、受信手段が上記の指示内容を示す上記編集要求を受信する。そして、実行手段が、当該編集要求に従い、所望の特定の歌唱データの削除やパラメータ変更等の編集処理を行い、その編集後のデータを用いて、公開手段が、第１歌唱データまたは第２歌唱データを、ネットワークへ公開する。

以上のように、本願第１発明によれば、複数回の録音に基づき複数の歌唱データを含む投稿データを、各歌唱データごとに編集することができる。これにより、複数の歌唱データの一部に、例えば削除されるべき不適当な歌唱データがあったり、音量等のパラメータを変更したい歌唱データがあった場合でも、上記不適当な歌唱データを編集で除いた後に公開したり、特定の歌唱データについて上記パラメータを変更した後に公開することができる。したがって、複数の歌唱データ全体としての処理（全歌唱データ削除等）しかできない従来手法に比べ、利用者の利便性を向上することができる。

第２発明は、上記第１発明において、前記受信手段は、前記編集要求として、ネットワークへ公開された録音歌唱データに対応付けられた前記第１歌唱データ及び前記第２歌唱データの中から、所望の前記第１歌唱データまたは前記第２歌唱データを除いたデータによる編集要求であって、サーバ側から公開拒否情報が通知された前記カラオケ装置または前記端末装置から、前記公開拒否情報に対する編集要求の指示を受信し、前記実行手段は、ネットワークへ公開された録音歌唱データに対応付けられた前記第１歌唱データ及び前記第２歌唱データの中から、所望の前記第１歌唱データまたは前記第２歌唱データを除いたデータにより、前記公開拒否情報に対する編集要求の指示に対応する編集処理を、前記編集要求の前記公開拒否情報が示す公開拒否対象のデータが無くなるまで繰り返し実行し、前記公開手段は、前記実行手段により編集処理が、前記公開拒否情報が示す前記公開可否情報のデータが無くなるまで繰り返し実行された結果、編集された後の、前記公開拒否対象のデータがなくなった前記第１歌唱データまたは前記第２歌唱データを、ネットワークへ公開することを特徴とする。

本願第２発明においては、例えば、投稿されたデータ中に削除されるべき（公開が拒否された）不適当な歌唱データが含まれていた場合、ユーザの操作端末からの、特定の歌唱データの削除指示を含む編集要求がサーバの受信手段により受信される。これにより、実行手段により所望の特定の歌唱データを削除する編集処理が実行され、編集後のデータが公開手段によりネットワークに公開される。したがって、公開が拒否された特定の歌唱データを含む複数の歌唱データ全体が削除されうる従来手法に比べ、利用者の利便性を向上することができる。

第３発明は、上記第２発明において、前記カラオケ装置は、第１歌唱者により過去に録音された少なくとも１つの前記第１歌唱音に重ねて、前記第１歌唱者とは異なる第２歌唱者により新たに入力される前記第２歌唱音を合わせて出力可能であり、前記歌唱音取得手段は、録音可能な複数回の歌唱ごとに、前記第２歌唱者により歌唱された前記第２歌唱音を取得し、前記サーバにおいて、前記実行手段は、ネットワークへ公開された録音歌唱データに対応付けられた前記第１歌唱データまたは前記第２歌唱データの中から、所望の前記第１歌唱データまたは前記第２歌唱データを除いたデータにより、編集処理を実行し、前記公開手段は、前記実行手段により編集処理が実行された結果、編集された前記第１歌唱データまたは前記第２歌唱データを、ネットワークへ公開することを特徴とする。

本願第３発明においては、第１歌唱者と第２歌唱者とが異なる。すなわち、カラオケ装置の歌唱音取得手段は、過去に録音された特定のカラオケ楽曲の第１歌唱データをサーバより取得する。そして、当該特定カラオケ楽曲の再生に合わせて第２歌唱者が歌唱して、第１歌唱データに係わる第１歌唱音と競演（コラボレーション歌唱）すると、歌唱音取得手段が、マイクロフォンから出力された当該特定カラオケ楽曲のコラボレーション歌唱による第２歌唱データを取得する。そして、記憶手段が、上記取得された第１歌唱データと第２歌唱データとを対応付け、録音歌唱データ（いわゆる録音ＩＤ）とともに記憶する。

これにより、本願第３発明においては、サーバからダウンロードして再生した第１歌唱音とコラボレーション歌唱して、第１歌唱データと、コラボレーション歌唱した第２歌唱データとを含む、複数の歌唱データを用いて、編集処理を実行することができる。

本願第４発明においては、カラオケ装置は、さらに、映像データ取得手段を有する。歌唱者が、特定カラオケ楽曲を歌唱する歌唱時、歌唱者を含む所定範囲をカメラで撮影すると、歌唱音取得手段が第２歌唱者による特定カラオケ楽曲の複数回の歌唱ごとに第２歌唱音を取得するときに、映像データ取得手段が、当該複数回の特定カラオケ楽曲の歌唱時における第２歌唱者が撮影された映像データを取得する。特に、本願第４発明においては、カラオケ装置は、さらに、選択手段を有する。歌唱者が、複数回の特定カラオケ楽曲を歌唱する歌唱時、歌唱者を含む所定範囲をカメラで撮影すると、上述したように映像データ取得手段が、当該複数回の特定カラオケ楽曲の歌唱時における第２歌唱者が撮影された映像データを取得する。そして、選択手段が、取得された各回の映像データのうち１つの映像データを選択する。そして、記憶手段が、上記複数回の回数ごとに、第２歌唱データと、第１歌唱データと、上記選択された１つの映像データとを、互いに対応付けて、さらに録音歌唱データ（いわゆる録音ＩＤ）を付して記憶する。これにより、ユーザは、複数の歌唱データを含むデータを投稿して公開しようするとき、歌唱者の歌唱している姿を含む映像データを、歌唱データと併せて投稿することができる。特に、ユーザは、複数回のうちいずれかの回における歌唱者の歌唱している姿を含む映像データを、歌唱データと併せて投稿することができる。そして、上記映像データとともに投稿された上記第１歌唱データ又は第２歌唱データについては、前述と同様、各データごとに編集することができる。

第４発明は、上記第１から第３発明のいずれかにおいて、前記サーバにおいて、前記受信手段は、前記編集要求として、投稿されている前記映像データの編集要求を受信し、前記実行手段は、前記映像データの代わりに、所定の設定画像により、編集処理を実行し、前記公開手段は、前記実行手段により編集処理が実行された結果、前記設定画像に対応付けられた前記第１歌唱データまたは前記第２歌唱データを、ネットワークへ公開することを特徴とする。

本願第４発明においては、投稿されたデータに含まれる１つの映像データが公開不可であった場合に、実行手段が、当該１つの映像データに代えて、アバター等の歌唱者を模した所定の静止画または動画の設定図像によって上記編集処理を行う。これにより、映像データとともに投稿された複数の歌唱データに、何の視覚的データも付随しなくなるのを防止することができる。

本発明によれば、同一カラオケ楽曲についての複数の歌唱データを投稿した後、各歌唱データごとに編集することができる。

本実施形態のカラオケシステムの全体構成を表す機能ブロック図である。 カラオケ装置で形成される歌唱データフォルダのデータ構造の一例を表す説明図である。 カラオケ装置の制御部によって実行される処理手順の詳細を表すフローチャートである。 サーバの制御部によって実行される処理手順の詳細を表すフローチャートである。 操作端末のＣＰＵによって実行される処理手順を表すフローチャートである。 特定カラオケ楽曲の歌唱データをダウンロードして歌唱者がコラボレーション歌唱する変形例において、カラオケ装置で形成される歌唱データフォルダのデータ構造の一例を表す説明図である。 カラオケ装置の制御部によって実行される処理手順を表すフローチャートである。 サーバにアップロードされた歌唱データのパラメータを変更する場合のサーバの制御部によって実行される処理手順を表すフローチャートである。 操作端末のＣＰＵによって実行される処理手順を表すフローチャートである。 映像データを含めて投稿する変形例において、カラオケ装置で形成される歌唱データフォルダを含む動画データフォルダのデータ構造の一例を表す説明図である。 カラオケ装置の制御部によって実行される処理手順を表すフローチャートである。 サーバの制御部によって実行される処理手順を表すフローチャートである。 操作端末のＣＰＵによって実行される処理手順を表すフローチャートである。 特定カラオケ楽曲の歌唱データをダウンロードして歌唱者がコラボレーション歌唱し映像データとともに投稿する変形例において、カラオケ装置で形成される歌唱データフォルダを含む動画データフォルダのデータ構造の一例を表す説明図である。 カラオケ装置の制御部によって実行される処理手順を表すフローチャートである。

以下、本発明の一実施の形態を図面を参照しつつ説明する。

図１は、本実施形態のカラオケシステムの全体構成を表す機能ブロック図である。

図１において、カラオケシステム１は、少なくとも１つのカラオケ装置１０と、少なくとも１つの操作端末３０と、サーバ４０とを有している。カラオケ装置１０は、例えばカラオケ店舗等のカラオケルームＫＲに設置されている。カラオケ装置１０は、楽曲データとしてのＭｕｓｉｃａｌ Ｉｎｓｔｒｕｍｅｎｔ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ（ＭＩＤＩ；登録商標）データ及び映像データを用いて、カラオケ演奏曲の再生サービスを提供する装置である。カラオケ装置１０とサーバ４０とは、例えば通信ネットワーク等のネットワークＮＷとを介し、互いに情報送受信可能に接続されている。操作端末３０とサーバ４０とは、上記ネットワークＮＷとを介し、互いに情報送受信可能に接続されている。

カラオケ装置１０は、装置本体２０と、リモコン１２と、マイクロフォン１４と、撮影手段としてのカメラ１６とを有している。装置本体２０とリモコン１２とは、例えば無線または有線のＬＡＮ等のネットワークを介し、互いに情報送受信可能に接続されている。装置本体２０とマイクロフォン１４及びカメラ１６とは、それぞれ無線回線または有線回線により接続されている。

装置本体２０は、制御部２１と、大容量記憶装置２２と、操作部２３と、受信部２４と、音源２５と、音声制御部２６と、スピーカ２７と、表示部２８（表示手段）と、通信制御部２９とを有している。

制御部２１は、図示しないＣＰＵや、ＲＡＭ及びＲＯＭ等のメモリを備えている。この制御部２１は、ＲＡＭの一時記憶機能を利用しつつ、ＲＯＭや上記大容量記憶装置２２に予め記憶された各種プログラムを実行する。これにより、装置本体２０全体の制御を行う。

特に、制御部２１は、カメラ１６により動画撮影された歌唱者を含むカラオケルームＫＲ内の所定範囲の映像データに対し画像処理を行い、その映像データを大容量記憶装置２２に記憶するとともに表示部２８に表示させる処理を行う。

大容量記憶装置２２は、例えばＨａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ（ＨＤＤ）などから構成される。この大容量記憶装置２２は楽曲データ記憶手段として機能し、楽曲データ（ＭＩＤＩデータ）、背景映像データ、及び歌詞データ等の各種情報が記憶されている。また、この大容量記憶装置２２には、ユーザの歌唱時の歌唱音を示す歌唱データ及び映像データが順次記憶される。

操作部２３は、例えば複数のキーやスイッチなどから構成される。ユーザは、この操作部２３または後述のリモコン１２を用いて、カラオケ演奏曲の予約操作等の各種操作を行うことができる。

受信部２４は、上記のマイクロフォン１４から出力された歌唱者の音声信号を受信する。

音源２５は、上記制御部２１によって大容量記憶装置２２から読み出された楽曲データを再生して音声制御部２６へ出力する。音声制御部２６は、音源２５から出力された楽曲データ、及び、受信部２４を介してマイクロフォン１４により入力された音声信号を増幅し、スピーカ２７へ出力する。スピーカ２７は、音声制御部２６から出力された楽曲データ及び音声信号を音声出力する。

なお、以下適宜、音源２５、音声制御部２６、及びスピーカ２７を、省略して「音源２５等」と称する。

表示部２８は、例えば液晶ディスプレイなどから構成され、各種映像を表示する表示手段として機能する。特に、表示部２８は、上記音源２５等により楽曲データの再生が行われるのにしたがい、楽曲データの再生に同期して、大容量記憶装置２２から読み出された背景映像データ、及び歌詞データに対応したテロップ等を表示することができる。なお、表示部２８は、カラオケ装置１０に含まれず、カラオケ装置１０の外部に設置されても良い。

通信制御部２９は、リモコン１２やサーバ４０との間で情報通信の制御を行う。

リモコン１２は、利用者がカラオケ演奏曲の予約操作等の各種操作を複数のキーやスイッチ等で行うための操作端末である。

マイクロフォン１４は、歌唱者の歌唱音を入力し、対応する上記歌唱データを出力する。

カメラ１６は、歌唱時に歌唱者を含む所定範囲の視野を動画撮影するためのもので、その所定範囲の映像データを生成する。

操作端末３０は、例えばパーソナルコンピュータ（ＰＣ）からなる。操作端末３０は、ＣＰＵ３１と、例えばＲＡＭやＲＯＭ等からなるメモリ３２と、例えばキーボードやマウスなどから構成される。また、パーソナルコンピュータは、ユーザにより指示や情報が入力される操作部３３（操作手段）と、例えば液晶ディスプレイなどから構成される。さらに、パーソナルコンピュータは、各種情報やメッセージを表示する表示部３４（表示手段）等を備えている。なお、この操作端末３０は、例えばユーザの自宅や勤務先や立ち寄り箇所等、ユーザが自らの意思で適宜に操作できる箇所に設置されている。操作端末３０は、スマートフォンやタブレットＰＣであっても良い。

サーバ４０は、例えば大容量記憶装置等からなる図示しないデータ格納部と、サーバ４０全体の各種制御機能を司るサーバ制御部（後述の図４のフロー参照）と、を備えている。サーバ４０のデータ格納部には、予め、過去にあるユーザがカラオケ演奏曲を歌唱したときの歌唱データと、歌唱者の姿を含む所定範囲の映像データと、当該カラオケ演奏曲の曲ＩＤ（曲識別情報）とが、互いに関連付けられ、セットで記憶されている。

以上において、本実施形態のカラオケシステム１では、あるカラオケ装置１０において歌唱者（同一利用者でもよいし、複数利用者でもよい）が同一の特定カラオケ楽曲について複数回歌唱し、対応する複数の歌唱データをサーバ４０へ投稿した後、操作端末３０またはカラオケ装置１０で各歌唱データごとに削除等の編集を行うことができる。すなわち、本実施形態では、ある１つのカラオケ楽曲について、歌唱者による歌唱音を複数回録音可能に構成されており、各回ごとに、それまでに録音された歌唱音を再生しながら、新たな歌唱音を重ねるように録音するようになっている。その際、本実施形態の特徴として、各回の歌唱データは、互いに合成されることなく、互いに独立しつつ１つの歌唱データフォルダ内にグループ化しつつ組み込まれる。

図２は、上記複数回の録音において、各回の録音ごとに、歌唱データがグループ化されて管理される上記歌唱データフォルダの例を示す説明図である。図２（ａ）は、特定の１つのカラオケ楽曲の再生に合わせて、まず１回目の録音として、歌唱者Ａが歌唱を行い、その歌唱データが録音された状態を表している。このとき、本実施形態では複数回分の録音の歌唱データを順次組み込み可能な歌唱データフォルダが用いられる。この１回目の録音では、図示のように、上記歌唱者Ａの歌唱データ（曲ＩＤ付き。以下同様）のみを含む歌唱データフォルダが形成される。なお、各歌唱データは適宜の識別情報（この例では、録音回数を示す録音歌唱データとしての録音ＩＤ）により識別される。この１回目の録音における録音ＩＤは「００１」である。

図２（ｂ）は、２回目の録音として、上記歌唱者Ａの歌唱データに歌唱者Ｂの歌唱データが組み込まれた歌唱データフォルダ（録音ＩＤ「００２」）が生成された状態を表している。具体的には、図２（ｂ）は、上記と同一のカラオケ楽曲について、当該カラオケ楽曲及び上記１回目に録音された歌唱者Ａの歌唱データに合わせて歌唱者Ｂが歌唱を行った例である。さらに図２（ｃ）は、３回目の録音として、さらに歌唱者Ｃが歌唱を行うことで、上記歌唱者Ａの歌唱データ及び歌唱者Ｂの歌唱データに、上記歌唱者Ｃの歌唱データが組み込まれた歌唱データフォルダ（録音ＩＤ「００３」）が形成された状態を表している。具体的には、図２（ｃ）は、上記と同一のカラオケ楽曲について、当該カラオケ楽曲及び上記１回目に録音された歌唱者Ａの歌唱データ及び上記２回目に録音された歌唱者Ｂの歌唱データに合わせた例である。

本実施形態では、上記のように、複数回の同一カラオケ楽曲の再生に合わせて各回ごとに歌唱者Ａ，Ｂ，Ｃが順次重ねるように歌唱して３つの歌唱データが１つの歌唱データフォルダ内に組み込まれる。すなわち、各歌唱者Ａ，Ｂ，Ｃそれぞれの歌唱データを同一カラオケ楽曲の曲ＩＤとともに歌唱データフォルダに組み込むことで、３つの歌唱データをグループ化してグループ化データが生成されている。いずれの歌唱データフォルダも、歌唱データフォルダをサーバ４０に投稿後、サーバ４０の当該歌唱データフォルダにアクセスすることにより、歌唱データフォルダ内の複数（この例では３つ）の歌唱データを各歌唱データごとに削除を行うことができる。各歌唱データごとの削除以外に、歌唱音の音量増減などのパラメータ変更等も行うことができる。以下適宜、これらを総称して単に「編集」又は「編集処理」という。詳細は後述する。これにより、そのような編集後のグループ化データを更新して公開することができる。

本実施形態による上記の手法を実現するために、カラオケ装置１０の制御部２１によって実行される処理手順を図３により説明する。

図３において、まず、ステップＳ１０で、制御部２１は、歌唱者によるカラオケ楽曲の予約が行われたか否かを判定する。歌唱者が操作部２３の直接操作またはリモコン１２を介した操作によりカラオケ楽曲の予約操作を行うと、制御部２１は、そのカラオケ楽曲を特定する曲ＩＤを取得するとともに、上記カラオケ楽曲の予約が行われたと判定する。歌唱者によるカラオケ楽曲の予約が行われるまで判定が満たされず（ステップＳ１０：ＮＯ）、ステップＳ１０をループして待機する。歌唱者によるカラオケ楽曲の予約が行われたら判定が満たされ（ステップＳ１０：ＹＥＳ）、ステップＳ１５に処理を移す。なお、上記のような一般的なカラオケの予約によって多重録音が開始されるのではなく、多重録音用の別のアプリケーションが、上記カラオケ予約時に適宜の特定の操作によって別途起動される構成でもよい。この場合、上記ステップＳ１０では、上記通常のカラオケ予約に加え、上記特定の操作が行われたかどうかが判定される。

ステップＳ１５では、制御部２１は、上記ステップＳ１０でのカラオケ楽曲の予約に基づき、大容量記憶装置２２から、当該予約に係わるカラオケ楽曲に対応した楽曲データ、背景映像データ、及び歌詞データ等を読み出す。そして、音源２５等に、上記楽曲データの再生を開始させるとともに、表示部２８に、上記楽曲データの再生と同期して、上記背景映像データ及び歌詞データの表示を開始させる。これにより、歌唱者はマイクロフォン１４を手にして、楽曲データに基づき再生されるカラオケ楽曲に合わせて歌唱することができる。歌唱者によるカラオケ楽曲の歌唱でマイクロフォン１４に入力された歌唱音は、マイクロフォン１４で音声信号に変換され、歌唱データとして音声制御部２６に出力される。ステップＳ１５が終了すると、ステップＳ２０に移る。

ステップＳ２０では、制御部２１は、音声制御部２６を介し、マイクロフォン１４から出力された歌唱者の特定カラオケ楽曲の歌唱データを取得する。なお、このステップＳ２０が、各請求項記載の歌唱音取得手段として機能する。ステップＳ２０が終了すると、ステップＳ２５に移る。

ステップＳ２５では、制御部２１は、上記ステップＳ２０で取得した歌唱データを（歌唱したカラオケ楽曲の曲ＩＤと対応付けて）組み込んだ上記歌唱データフォルダを作成し、大容量記憶装置２２に格納する。このステップＳ２５が、各請求項記載の記憶手段として機能する。ステップＳ２５が終了すると、ステップＳ３０に移る。

ステップＳ３０では、制御部２１は、同一のカラオケ楽曲について所定回数（この例では例えば３回）の録音分の歌唱データが組み込まれた歌唱データフォルダが生成されたか（言い換えれば上記所定回数の多重録音が行われたか）否かを判定する。例えばユーザが、当該カラオケ楽曲について上記所定回数の歌唱及び録音が終了すると、操作部２３またはリモコン１２により、上記多重録音を終了させる操作を行う。当該操作が行われないうちはステップＳ３０の判定が満たされず（ステップＳ３０：ＮＯ）、上記ステップＳ１５に戻り同様の手順を繰り返す。すなわち、上記ステップＳ１５での当該カラオケ楽曲の楽曲データの再生、ステップＳ２０での当該再生に伴う新たな歌唱データの取得、及びステップＳ２５での新たな歌唱データフォルダの生成が繰り返される。上記操作が行われた場合はステップＳ３０の判定が満たされ（ステップＳ３０：ＹＥＳ）、ステップＳ３５に移る。このステップＳ３０からステップＳ３５へ移行する機能が、各請求項記載の決定手段として機能する。

ステップＳ３５では、制御部２１は、この時点での最新の歌唱データフォルダを大容量記憶装置２２から読み出し、当該歌唱データフォルダに係わる上記録音ＩＤや上記ステップＳ１０で取得したカラオケ楽曲の曲ＩＤとともに、ネットワークＮＷを介してサーバ４０へ投稿しアップロードする。このステップＳ３５が、各請求項記載の投稿手段として機能する。アップロードされた歌唱データフォルダは、サーバ４０に設けられた上記データ格納部に格納される。ステップＳ３５が終了すると、その後、本フローを終了する。

次に、上記に対応して、サーバ４０の制御部によって実行される処理手順を図４により説明する。

図４において、まず、ステップＳ１１０で、サーバ４０のサーバ制御部は、前述のステップＳ３５においてカラオケ装置１０から歌唱データフォルダが投稿されたか否かを判定する。カラオケ装置１０から歌唱データフォルダがサーバ４０へ投稿されるまで判定が満たされず（ステップＳ１１０：ＮＯ）、ステップＳ１１０をループして待機する。カラオケ装置１０から歌唱データフォルダがサーバ４０へ投稿されると判定が満たされ（ステップＳ１１０：ＹＥＳ）、ステップＳ１１５に移る。このとき、サーバ４０では、カラオケ装置１０から歌唱データフォルダが投稿されると、サーバ係員による試聴など適宜の方法で、上記ステップＳ１１０で投稿された上記歌唱データフォルダ内の複数の歌唱データの個々について所定の検閲処理が行われる。そして、検閲処理の結果、複数の歌唱データのうちの少なくとも１つが、公序良俗等の観点から公開するのが不適当で公開を拒否すべき歌唱データであった場合は、サーバ係員により、適宜の操作手段を介し、歌唱データの検閲ＮＧの操作が行われる。一方、歌唱データフォルダ内の複数の歌唱データの全てに問題がなく公開を許可する場合は、サーバ係員により、歌唱データの検閲ＯＫの操作が行われる。

上記に応じて、ステップＳ１１５で、サーバ制御部は、投稿された歌唱データフォルダについて歌唱データの検閲ＯＫ操作があったか否かを判定する。歌唱データの検閲ＯＫ操作があった場合は判定が満たされ（ステップＳ１１５：ＹＥＳ）、ステップＳ１２０に移る。歌唱データの検閲ＯＫ操作がない場合は判定が満たされず（ステップＳ１１５：ＮＯ）、ステップＳ１２５に移る。

ステップＳ１２０では、サーバ制御部は、投稿された歌唱データフォルダの歌唱データの公開を許可するＯＫ結果を、ネットワークＮＷを介して上記操作端末３０（ＰＣ）に送信する。ステップＳ１２５が終了すると、ステップＳ１４０に移る。

ステップＳ１４０では、サーバ制御部は、上記ステップＳ１１５でＯＫ結果を送信した歌唱データフォルダ（投稿データ）をサーバ４０上に公開し、本フローを終了する。なお、このステップＳ１４０が各請求項記載の公開手段として機能する。

一方、ステップＳ１２５では、サーバ制御部は、投稿された歌唱データフォルダの歌唱データの検閲ＮＧ操作があったか否かを判定する。歌唱データの検閲ＮＧ操作がない場合は判定が満たされず（ステップＳ１２５：ＮＯ）、上記ステップＳ１１５に戻り、同様の手順を繰り返す。歌唱データの検閲ＮＧ操作があった場合は判定が満たされ（ステップＳ１２５：ＹＥＳ）、ステップＳ１３０に移る。

ステップＳ１３０では、サーバ制御部は、投稿された歌唱データフォルダの歌唱データの公開を拒否するＮＧ結果を操作端末３０（ＰＣ）に送信する。この送信するＮＧ結果には、歌唱データフォルダ内の複数の歌唱データのうちのいずれの歌唱データが公開に不適当であるかを示す公開拒否情報を含ませることができる。ステップＳ１３０が終了すると、本フローを終了する。

次に、上記に対応して、操作端末３０のＣＰＵ３１によって実行される処理手順を図５により説明する。

図５において、ステップＳ２１０で、ＣＰＵ３１は、サーバ４０から歌唱データフォルダの歌唱データの検閲結果（上記図４のステップＳ１２０又はステップＳ１３０参照）が送られてきたか否かを判定する。サーバ４０から歌唱データの検閲結果が送信されるまで判定が満たされず（ステップＳ２１０：ＮＯ）、ステップＳ２１０をループして待機する。サーバ４０から歌唱データの検閲結果が送信されると判定が満たされ（ステップＳ２１０：ＹＥＳ）、ステップＳ２１５に移る。

ステップＳ２１５では、ＣＰＵ３１は、表示部３４に制御信号を出力し、表示部３４にサーバ４０から送信された検閲結果を表示する。ステップＳ２１５が終了すると、ステップＳ２２０に移る。

ステップＳ２２０では、ＣＰＵ３１は、表示部３４に表示された検閲結果がＯＫ結果であるか否かを判定する。表示部３４に表示された検閲結果がＯＫ結果である場合は判定が満たされ（ステップＳ２２０：ＹＥＳ）、その後、本フローを終了する。表示部３４に表示された検閲結果がＯＫ結果でない場合は判定が満たされず（ステップＳ２２０：ＮＯ）、ステップＳ２２５に移る。

ステップＳ２２５では、ＣＰＵ３１は、ユーザによるサーバ４０へのアクセス操作があるか否かを判定する。ユーザが操作部３３を用いてサーバ４０へのアクセス操作を行うまでは判定が満たされず（ステップＳ２２５：ＮＯ）、ステップＳ２２５をループして待機する。ユーザがサーバ４０へのアクセス操作を行った場合は判定が満たされ（ステップＳ２２５：ＹＥＳ）、ステップＳ２３０に移る。

ステップＳ２３０では、ＣＰＵ３１は、ネットワークＮＷを介してサーバ４０へアクセスし、サーバ４０にアップロードされた歌唱データフォルダにアクセスする。アクセスされた歌唱データフォルダには、上述のようにカラオケ楽曲の曲ＩＤが含まれる。この歌唱データフォルダ内の歌唱データには、前述したように、サーバ４０において、公開が不適当とした歌唱データそのものに公開拒否情報が付随させることができる。ステップＳ２３０が終了すると、ステップＳ２３５に移る。

ステップＳ２３５では、ＣＰＵ３１は、表示部３４に制御信号を出力し、上記アクセスした歌唱データフォルダ内の歌唱データの一覧（この例では例えば３回分の歌唱データ）を表示する。ステップＳ２３５が終了すると、ステップＳ２４０に移る。

ステップＳ２４０では、ＣＰＵ３１は、ユーザが表示部３４に表示された歌唱データフォルダ内の複数個の歌唱データの一覧の中からいずれか１つの歌唱データを削除する削除要求操作を行ったか否かを判定する。ユーザは、以下の操作により、削除すべき歌唱データを知ることができる。例えば、図４のステップＳ１３０でサーバ４０から操作端末３０に送信されたＮＧ結果に含まれる公開拒否情報を見ることによって、削除すべき歌唱データを知ることができる。また、操作端末３０の表示部３４に表示された複数の歌唱データのうちの公開拒否の対象となった歌唱データに付随した公開拒否情報を見ることによって、削除すべき歌唱データを知ることができる。これによりユーザは、操作部３３を用いて該当する歌唱データの削除要求操作をサーバ４０に対し行うことができる。ユーザが歌唱データの削除要求操作を行った場合は判定が満たされ（ステップＳ２４０：ＹＥＳ）、ステップＳ２４５に移る。ユーザが歌唱データの削除要求操作を行わなかった場合は判定が満たされず（ステップＳ２４０：ＮＯ）、後述のステップＳ２５０に移る。

ステップＳ２４５では、ＣＰＵ３１は、上記ステップＳ２３５で表示された歌唱データフォルダ内の複数の歌唱データのうち、ユーザの削除要求操作の対象となった歌唱データを削除する削除要求（編集要求）をサーバ４０に送信する。サーバ４０のサーバ制御部はこの削除要求を受信し（各請求項記載の受信手段としての機能）た後、さらに編集処理として、当該削除要求の対象となったいずれかの歌唱データを上記歌唱データフォルダから削除する（各請求項記載の実行手段としての機能）。こうしてステップＳ２４５が終了すると、ステップＳ２５０に移る。

ステップＳ２５０では、ＣＰＵ３１は、歌唱データの削除が完了したか否か、言い換えれば歌唱データフォルダの編集が終了したか否かを判定する。具体的には、上記ステップＳ２４５に対応した上記サーバ４０のサーバ制御部での上記編集処理により、歌唱データフォルダ内の複数の歌唱データのうちの公開拒否対象の全ての歌唱データの削除が完了したか否かが判定される。歌唱データフォルダ内に公開拒否対象の歌唱データが残っていれば判定が満たされず（ステップＳ２５０：ＮＯ）、上記ステップＳ２３５に戻って同様の手順を繰り返す。歌唱データフォルダ内に公開拒否対象の歌唱データがなくなった場合は判定が満たされ（ステップＳ２５０：ＹＥＳ）、ステップＳ２５５に移る。

ステップＳ２５５では、ＣＰＵ３１は、公開拒否対象の歌唱データが削除された後に残った歌唱データで歌唱データフォルダを上書き更新する指示をサーバ４０に出力する。これにより、サーバ４０のサーバ制御部は、上記歌唱データフォルダを更新する。ステップＳ２５５が終了すると、このフローを終了する。

以上説明したように、本実施形態のカラオケシステム１によれば、複数回の録音に基づき複数の歌唱データを含む投稿データを、各歌唱データごとに編集することができる。これにより、複数の歌唱データの一部に、例えば削除されるべき不適当な歌唱データがあった場合でも、上記不適当な歌唱データを編集で除いた後に公開することができる。したがって、複数の歌唱データ全体としての処理（全歌唱データ削除等）しかできない従来手法に比べ、利用者の利便性を向上することができる。

なお、上記実施形態では、サーバ４０での歌唱データの検閲結果を操作端末３０に送信し、公開が拒否された特定の歌唱データがあった場合に、操作端末３０で特定の歌唱データを削除する編集要求をサーバ４０に送信したが、これに限られない。すなわち、操作端末３０に代えて歌唱データの検閲結果をカラオケ装置１０に送信し、カラオケ装置１０から歌唱データフォルダにアクセスし特定の歌唱データを削除する編集要求を送信するようにしてもよい。

また、本発明は、上記にも限られず、技術思想を逸脱しない範囲でさらに種々の変形が可能である。以下、そのような変形例について説明する。なお、各変形例の各図において、上記実施形態と同様の部分には適宜同一の符号を付し、適宜説明を省略又は簡略化する。

（１）歌唱者が、同一カラオケ楽曲の別の歌唱者の歌唱データに合わせてコラボレーション歌唱する場合
上記実施形態では、カラオケ装置１０で歌唱者が同一カラオケ楽曲について複数回歌唱する場合を説明したが、これに限られない。すなわち、サーバ４０にアップロード済みの特定カラオケ楽曲の歌唱データがダウンロードされても良い。この場合、ダウンロードした特定カラオケ楽曲の再生に合わせて、歌唱者が当該ダウンロードした歌唱データの歌唱者と競演してコラボレーション歌唱するようにしてもよい。

上記コラボレーション歌唱する変形例１において、図２と同様、複数回の録音の各回ごとに、歌唱データがグループ化された歌唱データフォルダの例を示す説明図を、図６に示す。図６（ａ）は、特定の１つのカラオケ楽曲の歌唱データ（コラボレーション相手となる歌唱者Ｘ）がダウンロードされた状態を表している。このとき、図示のように、上記歌唱者Ｘの歌唱データ（曲ＩＤ付き。以下同様）のみを含む歌唱データフォルダ（録音ＩＤ「０１１」）が形成される。

図６（ｂ）は、１回目の録音として、上記歌唱者Ｘの歌唱データに歌唱者Ａの歌唱データが組み込まれた歌唱データフォルダ（録音ＩＤ「０１２」）が生成された状態を表している。具体的には、図６（ｂ）は、同一のカラオケ楽曲について、当該カラオケ楽曲及び上記ダウンロードされた歌唱者Ｘの歌唱データに合わせて歌唱者Ａが歌唱を行った例である。さらに図６（ｃ）は、２回目の録音として、さらに歌唱者Ｂが歌唱を行うことで、上記歌唱者Ｘの歌唱データ及び歌唱者Ａの歌唱データに、上記歌唱者Ｂの歌唱データが組み込まれた歌唱データフォルダ（録音ＩＤ「０１３」）が生成された状態を表している。具体的には、図６（ｃ）は、同一のカラオケ楽曲について、当該カラオケ楽曲及び上記ダウンロードされた歌唱者Ｘの歌唱データ及び上記１回目に録音された歌唱者Ａの歌唱データに合わせて、歌唱者Ｂが歌唱を行う例である。

本変形例のカラオケ装置１０の制御部２１によって実行される処理手順を図７により説明する。図７のフローチャートは、図３に示すフローチャートのステップＳ１０の代わりにステップＳ１１〜ステップＳ１４を設け、ステップＳ１５とステップＳ２０との間にステップＳ１７を設けた点が異なる。図７において、例えば図示しないカラオケ管理者により例えばカラオケ装置１０の電源がオンにされることによって、このフローが開始される。

図７において、まず、新たに設けたステップＳ１１で、カラオケ装置１０の制御部２１は、特定のカラオケ楽曲について歌唱者によるコラボレーション歌唱の要求があったか否かを判定する。例えば、歌唱者は、操作部２３の直接操作またはリモコン１２を介した操作により、特定のカラオケ楽曲のコラボレーション歌唱の要求操作を行う。すると、制御部２１は、そのカラオケ楽曲の曲ＩＤを取得するとともに、コラボレーション歌唱要求が行われたと判定する。歌唱者によるカラオケ楽曲のコラボレーション歌唱要求が行われるまで判定が満たされず（ステップＳ１１：ＮＯ）、制御部２１は、ステップＳ１１の処理をループして待機する。歌唱者による特定のカラオケ楽曲のコラボレーション歌唱要求が行われたら判定が満たされ（ステップＳ１１：ＹＥＳ）、制御部２１は、新たに設けたステップＳ１２に処理を移す。

ステップＳ１２では、制御部２１は、ネットワークＮＷを介してサーバ４０にアクセスする。このアクセスにより、サーバ４０の上記データ格納部に格納されたアップロード済みの上記特定のカラオケ楽曲の歌唱データの一覧が、表示部２８に表示される。ステップＳ１２が終了すると、新たに設けたステップＳ１３に移る。

ステップＳ１３では、制御部２１は、歌唱者により、表示部２３に表示された特定のカラオケ楽曲の歌唱データの一覧から１つの歌唱データ(本変形例における第１歌唱データに相当)が選択されたか否かを判定する。歌唱者が操作部２３の直接操作またはリモコン１２を介した操作により特定のカラオケ楽曲の上記第１歌唱データの選択操作を行うまで判定が満たされない（ステップＳ１３：ＮＯ）。すなわち、制御部２１は、ステップＳ１３の処理をループして待機する。歌唱者が特定のカラオケ楽曲の第１歌唱データの選択操作を行った場合は判定が満たされ（ステップＳ１３：ＹＥＳ）、制御部２１は、新たに設けたステップＳ１４に処理を移す。

ステップＳ１４では、制御部２１は、ネットワークＮＷを介してサーバ４０にアクセスする。そして、サーバ４０のデータ格納部に格納されたアップロード済みの複数の歌唱データの中から、上記ステップＳ１３で選択した１つの特定の第１歌唱データをダウンロードする。そして制御部２１は、上記ダウンロードした第１歌唱データを（カラオケ楽曲の曲ＩＤと対応付けて）組み込んだ歌唱データフォルダを生成し（上記図６（ａ）参照）、大容量記憶装置２２に格納する。ステップＳ１４が終了すると、ステップＳ１５に移る。

ステップＳ１５では、上記図３と同様、制御部２１は、上記ステップＳ１３での特定のカラオケ楽曲の第１歌唱データの選択に基づき、大容量記憶装置２２から、当該選択に係わる特定のカラオケ楽曲に対応した楽曲データ、背景映像データ、及び歌詞データ等を読み出す。そして、音源２５等に、上記楽曲データの再生を開始させるとともに、表示部２８が、上記楽曲データの再生と同期して、上記背景映像データ及び歌詞データの表示を開始する。ステップＳ１５が終了すると、制御部２１は、新たに設けたステップＳ１７に処理を移す。

ステップＳ１７では、制御部２１は、上記ステップＳ１４でダウンロードした第１歌唱データを読み出し、音源２５等に、読み出した第１歌唱データの再生を開始させる。これにより、上記ステップＳ１５で開始されるカラオケ楽曲の再生に同期して、第１歌唱データの再生が開始される。これにより、歌唱者はマイクロフォン１４を用いて、カラオケ楽曲の再生に合わせて第１歌唱者（第１歌唱データの歌唱者。前述の例では歌唱者Ｘ）の歌唱音を聞きながら歌唱することにより、第１歌唱者とコラボレーション歌唱（競演）することができる。歌唱者によるカラオケ楽曲のコラボレーション歌唱でマイクロフォン１４に入力された歌唱音は、マイクロフォン１４で音声信号に変換される。そして、変換された音声信号が、第２歌唱データとして音声制御部２６に出力される。ステップＳ１７が終了すると、制御部２１は、ステップＳ２０に処理を移す。

ステップＳ２０では、上記図３と同様、制御部２１は、音声制御部２６を介し、マイクロフォン１４から出力された歌唱者のコラボレーション歌唱時の上記第２歌唱データを取得する。ステップＳ２０が終了すると、制御部２１は、ステップＳ２５に処理を移す。

ステップＳ２５では、制御部２１は、上記図３と同様、上記ステップＳ２０で取得した第２歌唱データを（歌唱したカラオケ楽曲の曲ＩＤと対応付けて）組み込んだ上記歌唱データフォルダを作成する。そして、制御部２１は、作成した歌唱データフォルダを大容量記憶装置２２に格納する。このステップＳ２５が、各請求項記載の記憶手段として機能する。ステップＳ２５が終了すると、制御部２１は、ステップＳ３０に処理を移す。

ステップＳ３０では、制御部２１は、上記図３と同様、同一のカラオケ楽曲について所定回数（この例では例えば２回）の録音分の歌唱データが組み込まれた歌唱データフォルダが生成されたか（言い換えれば上記所定回数の多重録音が行われたか）否かを判定する。ユーザにより前述と同様の多重録音終了操作が行われないうちはステップＳ３０の判定が満たされず（ステップＳ３０：ＮＯ）、上記ステップＳ１５に戻り、制御部２１は同様の手順を繰り返す。すなわち、上記ステップＳ１５での当該カラオケ楽曲の楽曲データの再生、ステップＳ２０での当該再生に伴う新たな歌唱データの取得、及びステップＳ２５での新たな歌唱データフォルダの生成が繰り返される。上記操作が行われた場合は判定が満たされ（ステップＳ３０：ＹＥＳ）、制御部２１はステップＳ３５に処理を移す。このステップＳ３０からステップＳ３５へ移行する機能が、各請求項記載の決定手段として機能する。

ステップＳ３５では、制御部２１は、上記図３同様、この時点での最新の歌唱データフォルダを大容量記憶装置２２から読み出す。そして、制御部２１は、当該歌唱データフォルダに係わる上記録音ＩＤや上記カラオケ楽曲の曲ＩＤとともに、ネットワークＮＷを介してサーバ４０へ投稿しアップロードする。このステップＳ３５が、各請求項記載の投稿手段として機能する。アップロードされた歌唱データフォルダは、サーバ４０に設けられた上記データ格納部に格納される。ステップＳ３５が終了すると、その後、制御部２１は、本フローの処理を終了する。

上記において、上記ステップＳ１４及びステップＳ２０の手順は各請求項記載の歌唱音取得手段として機能する。

なお、本変形例におけるサーバ４０の制御部によって実行される処理手順は前述の図４と同等であり、操作端末３０のＣＰＵ３１によって実行される処理手順は図５と同様であるので、説明を省略する。

以上説明したように、本変形例１においては、サーバ４０からダウンロードして再生した第１歌唱データとコラボレーション歌唱して、第１歌唱データと、コラボレーション歌唱した第２歌唱データとを含む、複数の歌唱データを用いて、編集処理を実行することができる。

（２）歌唱データのパラメータを変更する編集処理を行う場合
以上においては、サーバ４０において、投稿された歌唱データフォルダの歌唱データの公開の可否が検閲され、それに対しユーザが、特定の歌唱データを削除する編集要求を行ったが、これに限られない。すなわち、サーバ４０により公開された歌唱データに対し、ユーザが、特定の歌唱データについて、例えば音量を増減する等のパラメータ変更の編集処理を行えるようにしてもよい。

本変形例２を図８及び図９により説明する。図８は、変形例２でのサーバ４０の制御部によって実行される処理手順を示す。図８のフローチャートは、図４に示すフローチャートのステップＳ１１０とステップＳ１４０との間のステップＳ１１５〜ステップＳ１３５を削除し、代わりにステップ１２２を設けた点だけが異なる。

図８において、ステップＳ１１０の手順は図４と同様である。すなわち、ステップＳ１１０において、カラオケ装置１０から歌唱データフォルダがサーバ４０へ投稿されて判定が満たされる（ステップＳ１１０：ＹＥＳ）と、制御部２１は、新たに設けたステップＳ１２２に処理を移す。

ステップＳ１２２では、サーバ制御部は、投稿された歌唱データフォルダの歌唱データをそのまま公開するアップロード通知を、ネットワークＮＷを介して操作端末３０（ＰＣ）に送信する。ステップＳ１２２が終了すると、サーバ制御部は、ステップＳ１４０に処理を移す。

ステップＳ１４０の手順は上記図４と同様である。ステップＳ１４０では、サーバ制御部は、上記ステップＳ１２２でアップロード通知を送信した歌唱データフォルダ（投稿データ）をネットワーク上に公開し、本フローを終了する。

図９は、変形例２での操作端末３０のＣＰＵ３１によって実行される処理手順を表すフローチャートである。図９のフローチャートは、図５に示すフローチャートのステップＳ２１０、ステップＳ２１５及びステップＳ２２０の代わりに、新たにステップＳ２１２及びステップＳ２１７を設け、ステップＳ２４０及びステップＳ２４５の代わりに、新たにステップＳ２４２及びステップＳ２４７を設けた点が異なる。

図９において、まず、新たに設けたステップＳ２１２で、操作端末３０のＣＰＵ３１は、カラオケ装置１０から投稿した歌唱データフォルダに対し、サーバ４０から歌唱データフォルダのアップロード通知（図８のステップＳ１２２参照）が送られてきたか否かを判定する。サーバ４０からアップロード通知が送信されるまで判定が満たされず（ステップＳ２１２：ＮＯ）、ＣＰＵ３１は、ステップＳ２１２の処理をループして待機する。サーバ４０からアップロード通知が送信されると判定が満たされ（ステップＳ２１２：ＹＥＳ）、ＣＰＵ３１は、新たに設けたステップＳ２１７に処理を移す。

ステップＳ２１７では、ＣＰＵ３１は、表示部３４に制御信号を出力し、表示部３４にサーバ４０から送信されたアップロード通知を表示する。サーバ４０は、操作端末３０へアップロード通知を送信した後、投稿した歌唱データフォルダを公開する（図８のステップＳ１４０参照）。このため、表示部３４に表示されたアップロード通知を見た歌唱者は、サーバ４０の歌唱データフォルダにアクセスし歌唱データをダウンロードして、当該歌唱データの音量等のパラメータを変更する編集を行なうことが可能となる。ステップＳ２１７が終了すると、ステップＳ２２５に移る。

ステップＳ２２５〜ステップＳ２３５の手順は図５と同様であるので詳細な説明を省略する。上記ステップＳ２３５において、表示部３４に上記アクセスした歌唱データフォルダ内の歌唱データの一覧（この例では例えば３回分の歌唱データ）を表示し、上記ステップＳ２３５が終了すると、ＣＰＵ３１は、新たに設けたステップＳ２４２に処理を移す。

ステップＳ２４２では、ＣＰＵ３１は、ユーザが、変更要求操作を行ったか否かを判定する。変更要求操作は、上記表示部３４に表示された歌唱データフォルダ内の複数個の歌唱データの一覧の中から、いずれか１つの歌唱データのパラメータ（例えば歌唱音の音量を増減するパラメータ）を変更する操作である。ユーザが操作部３３を用いて歌唱データのパラメータ変更要求操作を行った場合は、ステップＳ２４２の判定が満たされる（ステップＳ２４２：ＹＥＳ）。これにより、ＣＰＵ３１は、新たに設けたステップＳ２４７に処理を移す。ユーザが歌唱データのパラメータ変更要求操作を行わなかった場合は、ステップＳ２４２の判定が満たされない（ステップＳ２４２：ＮＯ）。これにより、ＣＰＵ３１は、後述のステップＳ２５０に処理を移す。

ステップＳ２４７では、ＣＰＵ３１は、上記ステップＳ２３５で表示された歌唱データフォルダ内の複数の歌唱データのうち、ユーザのパラメータ変更要求操作の対象となった歌唱データの当該パラメータの変更要求（編集要求）をサーバ４０に送信する。サーバ４０のサーバ制御部はこの変更要求を受信し（各請求項記載の受信手段としての機能）た後、さらに編集処理として、当該変更要求の対象となったいずれかの歌唱データの対応するパラメータを上記要求に沿って変更する（各請求項記載の実行手段としての機能）。こうしてステップＳ２４７が終了すると、ＣＰＵ３１は、ステップＳ２５０に処理を移す。

ステップＳ２５０では、ＣＰＵ３１は、上記図５と同様、歌唱データフォルダ内の複数の歌唱データのうちの所望の歌唱データのパラメータ変更が完了したか否かを判定する。これは、言い換えれば、ＣＰＵ３１が、歌唱データフォルダの編集が終了したか否かを判定することである。歌唱データフォルダ内にパラメータ変更対象の歌唱データが残っていれば判定が満たされず（ステップＳ２５０：ＮＯ）、ＣＰＵ３１は、上記ステップＳ２３５に処理を戻して同様の手順を繰り返す。歌唱データフォルダ内にパラメータ変更対象の歌唱データがなくなった場合は判定が満たされ（ステップＳ２５０：ＹＥＳ）、ＣＰＵ３１は、ステップＳ２５５に処理を移す。

ステップＳ２５５では、ＣＰＵ３１は、上記図５と同様、パラメータ変更後の歌唱データで歌唱データフォルダを上書き更新する指示をサーバ４０に出力する。これにより、サーバ４０のサーバ制御部は、上記歌唱データフォルダを更新する。ステップＳ２５５が終了すると、このフローを終了する。

以上のように、本変形例２においても、複数回の録音に基づき複数の歌唱データを含む投稿データを、各歌唱データごとに編集することができる。これにより、複数の歌唱データの一部に、例えば音量等のパラメータを変更したい歌唱データがあった場合には、上記パラメータを変更する編集を行った後に公開することができる。したがって、複数の歌唱データ全体としての処理しかできない従来手法に比べ、利用者の利便性を向上することができる。

なお、上記変形例２では、投稿した歌唱データフォルダの特定の歌唱データの音量に関するパラメータを操作端末３０からの操作により変更する編集を行ったが、これに限られない。すなわち、操作端末３０に代えてカラオケ装置１０からパラメータを変更する編集要求を送信するようにしてもよい。

（３）歌唱者の映像データを撮影し投稿する場合
本変形例では、上記実施形態と同様に、同一カラオケ楽曲について歌唱した複数の歌唱データがグループ化され、歌唱データフォルダとして投稿される。その投稿の際、各回のカラオケ楽曲の歌唱時それぞれにおける歌唱時の歌唱者を含む映像データからいずれか１回の映像データが選択される。そして、その選択された特定の回の映像データが、歌唱データフォルダと一緒に投稿される。

図１０は、複数回の録音において、各回の録音ごとに、歌唱データがグループ化され、さらに複数回のうち１回の映像データが組み込まれることで形成される動画データフォルダの例を示す説明図である。図１０（ａ）は、特定の１つのカラオケ楽曲の再生に合わせて、まず１回目の録音として、歌唱者Ａが歌唱を行う例である。具体的には、図１０（ａ）は、その歌唱データが録音されて上記歌唱データフォルダ（録音ＩＤ「０２１」）が生成され、さらに１回目録音時の歌唱者である歌唱者Ａの姿を撮影した映像データが組み込まれて動画データフォルダが形成された状態を表している。

図１０（ｂ）は、２回目の録音として、上記歌唱者Ａの歌唱データに歌唱者Ｂの歌唱データが組み込まれた歌唱データフォルダ（録音ＩＤ「０２２」）が形成された状態を表している。具体的には、図１０（ｂ）は、上記の形成の結果、上記歌唱者Ａの映像データとともに動画データフォルダが形成された状態を表している。その後、上記と同一のカラオケ楽曲について、当該カラオケ楽曲と、上記１回目に録音された歌唱者Ａの歌唱データと、上記２回目に録音された歌唱者Ｂの歌唱データとに合わせて、さらに歌唱者Ｃが歌唱を行う。これにより、３回目の録音として、上記歌唱者Ａの歌唱データ及び歌唱者Ｂの歌唱データに、上記歌唱者Ｃの歌唱データが組み込まれた歌唱データフォルダ（録音ＩＤ「００３」）が形成される。図１０（ｃ）は、このようにして、上記歌唱者Ａの映像データとともに動画データフォルダが形成された状態を表している。

本変形例では、上記のように、複数回分の録音の歌唱データの歌唱データフォルダと、複数回分の録音時のうちいずれかの回（この例では１回目）の歌唱時の歌唱者の姿の映像データと、が動画データフォルダに組み込まれる。すなわち、各歌唱者Ａ，Ｂ，Ｃそれぞれの歌唱データを同一カラオケ楽曲の曲ＩＤとともに歌唱データフォルダに組み込み３つの歌唱データが形成されている。さらにそれら歌唱データと、上記いずれかの回の歌唱者の姿を含む映像データと、がグループ化されて、グループ化データが生成されている。いずれの動画データフォルダも、サーバ４０に投稿された後にそれぞれ編集可能である。すなわち、サーバ４０の動画データフォルダにアクセスが行われることにより、動画フォルダに含まれる歌唱データフォルダ内の複数（この例では３つ）の歌唱データが、各歌唱データごとに編集可能である。ここでいう編集とは、上記同様に、削除若しくは歌唱音の音量増減などのパラメータ変更等のことである。なお、さらにそのような編集後のグループ化データはさらに更新されて公開可能である。

変形例３での上記の手法を実現するために、カラオケ装置１０の制御部２１によって実行される処理手順を図１１により説明する。図１１のフローチャートは、図３に示すフローチャートのステップＳ２５〜ステップＳ３５を削除し、代わりに新たなステップＳ２２、ステップＳ２７、ステップＳ３１、ステップＳ３２、ステップＳ３３及びステップＳ３７を設けた点が異なる。

図１１において、ステップＳ１０〜ステップＳ２０の手順は図３と同じである。すなわち、制御部２１は、ステップＳ２０においてマイクロフォン１４から出力された歌唱者の歌唱データを取得し、ステップＳ２０が終了すると、新たに設けたステップＳ２２に移る。

ステップＳ２２では、制御部２１は、上記ステップＳ２０でのカラオケ楽曲の歌唱データを取得するのに合わせて、当該カラオケ楽曲の歌唱時における歌唱者の姿を撮影した映像データをカメラ１６から取得する（その際歌唱したカラオケ楽曲の曲ＩＤと対応付ける）。このステップＳ２２が、各請求項記載の映像取得手段として機能する。ステップＳ２２が終了すると、新たに設けたステップＳ２７に移る。

ステップＳ２７では、制御部２１は、上記ステップＳ２０で取得した歌唱データを（歌唱したカラオケ楽曲の曲ＩＤと対応付けて）組み込んだ上記歌唱データフォルダを作成する。さらに、制御部２１は、上記ステップＳ２２で取得した映像データを組み込んで上記動画データフォルダを仮作成し、上記大容量記憶装置２２に格納する。このステップＳ２７が、各請求項記載の記憶手段として機能する。ステップＳ２７が終了すると、制御部２１は、新たに設けたステップＳ３１に処理を移す。

ステップＳ３１では、制御部２１は、同一のカラオケ楽曲について所定回数（この例では例えば３回）の録音分の歌唱データと各回の映像データが組み込まれた動画データフォルダが生成されたか（言い換えれば上記所定回数の多重録音及び録画が行われたか）否かを判定する。例えばユーザが、当該カラオケ楽曲について上記所定回数の録音及び撮影が終了すると、操作部２３またはリモコン１２により、上記多重録音・録画を終了させる操作を行う。当該操作が行われないうちはステップＳ３１の判定が満たされない（ステップＳ３１：ＮＯ）。これにより、制御部２１は、上記ステップＳ１５に処理を戻して様の手順を繰り返す。すなわち、上記ステップＳ１５での当該カラオケ楽曲の楽曲データの再生と、ステップＳ２０及びステップＳ２２での当該再生に伴う新たな歌唱データ及び新たな映像データの取得と、ステップＳ２７での新たな動画データフォルダの生成（仮生成）と、が繰り返される。上記操作が行われた場合は判定が満たされ（ステップＳ３１：ＹＥＳ）、新たに設けたステップＳ３２に移る。

ステップＳ３２では、制御部２１は、この時点での最新の動画データフォルダを大容量記録装置２２から読み出す。そして、制御部２１は、当該データフォルダ内に前述のようにして含まれている複数回の映像データから、適宜の選択設定により１つの映像データを選択する。この選択は、例えばユーザが、操作部２３またはリモコン１２により選択操作を行うようにしてもよいし、予め固定的に定められた適宜のルールにより制御部２１が自動選択するようにしてもよい。このステップＳ３２が、各請求項記載の映像決定手段として機能する。ステップＳ３２が終了すると、新たに設けたステップＳ３３に移る。

ステップＳ３３では、制御部２１は、上記ステップＳ３２で選択した１つの映像データを除く他の回の映像データを削除（または適宜の除外処理）することで、投稿すべき動画データフォルダを完成する（図１０（ｃ）参照）。このステップＳ３３が、各請求項記載の決定手段として機能する。ステップＳ３３が終了すると、新たに設けたステップＳ３７に移る。

ステップＳ３７では、制御部２１は、上記ステップＳ３３で完成した動画データフォルダを、当該動画データフォルダに係わる上記カラオケ楽曲の曲ＩＤとともに、カラオケ装置１０からネットワークＮＷを介してサーバ４０へ投稿しアップロードする。このステップＳ３７が、各請求項記載の投稿手段として機能する。アップロードされた動画データフォルダは、サーバ４０に設けられた上記データ格納部に格納される。ステップＳ３７が終了すると、制御部２１は、その後、本フローの処理を終了する。

次に、上記に対応して、サーバ４０の制御部によって実行される処理手順を図１２により説明する。図１２のフローチャートは、図４に示すフローチャートのステップＳ１１０の代わりに新たなステップＳ１１２を設け、ステップＳ１２０とステップＳ１４０との間に新たなステップＳ１３１及びステップＳ１３２を設けた。さらに、図１２のフローチャートは、その新たなステップＳ１３１と上記ステップＳ１４０との間に新たなステップＳ１３３、ステップＳ１３４及びステップＳ１３５を設けた点が異なる。

図１２において、まず、新たに設けたステップＳ１１２で、サーバ４０のサーバ制御部は、前述のステップＳ３７においてカラオケ装置１０から動画データフォルダが投稿されたか否かを判定する。カラオケ装置１０から動画データフォルダがサーバ４０へ投稿されるまで判定が満たされない（ステップＳ１１２：ＮＯ）。これにより、サーバ制御部は、ステップＳ１１２の処理をループして待機する。カラオケ装置１０から動画データフォルダがサーバ４０へ投稿されると判定が満たされ（ステップＳ１１２：ＹＥＳ）、サーバ制御部は、ステップＳ１１５に処理を移す。このとき、サーバ４０では、カラオケ装置１０から動画データフォルダが投稿されると、上記図４と同様、サーバ係員による試聴など適宜の方法で、上記ステップＳ１１２で投稿された動画データフォルダに含まれる歌唱データフォルダ内の複数の歌唱データの個々について所定の検閲処理が行われる。そして、検閲処理の結果、複数の歌唱データのうちの少なくとも１つが、公序良俗等の観点から公開するのが不適当で公開を拒否すべき歌唱データであった場合は、サーバ係員により、適宜の操作手段を介し、歌唱データの検閲ＮＧの操作が行われる。一方、動画データフォルダに含まれる歌唱データフォルダ内の複数の歌唱データの全てに問題がなく公開を許可する場合は、サーバ係員により、歌唱データの検閲ＯＫの操作が行われる。

上記に応じて、ステップＳ１１５で、サーバ制御部は、投稿された動画データフォルダにおける歌唱データフォルダについて歌唱データの検閲ＯＫ操作があったか否かを判定する。歌唱データの検閲ＯＫ操作があった場合はステップＳ１１５の判定が満たされ（ステップＳ１１５：ＹＥＳ）、サーバ制御部は、ステップＳ１２０に処理を移す。歌唱データの検閲ＯＫ操作がない場合はステップＳ１１５の判定が満たされず（ステップＳ１１５：ＮＯ）、サーバ制御部は、ステップＳ１２５に処理を移す。

ステップＳ１２０では、サーバ制御部は、投稿された動画データフォルダにおける歌唱データフォルダ歌唱データの公開を許可するＯＫ結果を、ネットワークＮＷを介して上記操作端末３０（ＰＣ）に送信する。ステップＳ１２０が終了すると、サーバ制御部は、新たに設けたステップＳ１３１に処理を移す。

一方、ステップＳ１２５では、サーバ制御部は、投稿された動画データフォルダにおける歌唱データフォルダの歌唱データの検閲ＮＧ操作があったか否かを判定する。歌唱データの検閲ＮＧ操作がない場合は判定が満たされず（ステップＳ１２５：ＮＯ）、上記ステップＳ１１５に戻り、同様の手順を繰り返す。歌唱データの検閲ＮＧ操作があった場合はステップＳ１１２の判定が満たされ（ステップＳ１２５：ＹＥＳ）、サーバ制御部は、ステップＳ１３０に処理を移す。

ステップＳ１３０では、サーバ制御部は、投稿された動画データフォルダにおける歌唱データフォルダの歌唱データの公開を拒否するＮＧ結果を操作端末３０（ＰＣ）に送信する。この送信するＮＧ結果には、歌唱データフォルダ内の複数の歌唱データのうちいずれの歌唱データが公開に不適当であるかを示す公開拒否情報を含ませることができる。ステップＳ１３０が終了すると、サーバ制御部は、新たに設けた上記ステップＳ１３１に処理を移す。

ステップＳ１３１では、サーバ制御部は、投稿された動画データフォルダについて映像データの検閲ＯＫ操作があったか否かを判定する。すなわち、上記歌唱データと同様、映像データについても、サーバ係員による試写など適宜の方法で、上記ステップＳ１１２で投稿された動画データフォルダ内の１つの映像データについて所定の検閲処理が行われる。そして、検閲処理の結果、当該１つの映像データが、公序良俗等の観点から公開するのが不適当で公開を拒否すべき映像データであった場合は、サーバ係員により、適宜の操作手段を介し、映像データの検閲ＮＧの操作が行われる。一方、動画データフォルダに含まれる１つの映像データに問題がなく公開を許可する場合は、サーバ係員により、映像データの検閲ＯＫの操作が行われる。このようにして映像データの検閲ＯＫ操作があった場合はステップＳ１３１の判定が満たされ（ステップＳ１３１：ＹＥＳ）、サーバ制御部は、新たに設けたステップＳ１３２に処理を移す。映像データの検閲ＯＫ操作がない場合は判定が満たされず（ステップＳ１３１：ＮＯ）、サーバ制御部は、新たに設けたステップＳ１３３に処理を移す。

ステップＳ１３２では、上記ステップＳ１２０と同様、サーバ制御部は、投稿された動画データフォルダに含まれる上記１つの映像データの公開を許可するＯＫ結果を、ネットワークＮＷを介して操作端末３０（ＰＣ）に送信する。ステップＳ１３２が終了すると、サーバ制御部は、ステップＳ１４０に処理を移す。

一方、ステップＳ１３３では、サーバ制御部は、投稿された動画データフォルダの映像データの検閲ＮＧ操作があったか否かを判定する。映像データの検閲ＮＧ操作がない場合は判定が満たされず（ステップＳ１３３：ＮＯ）、サーバ制御部は、上記ステップＳ１３１に処理を戻して同様の手順を繰り返す。映像データの検閲ＮＧ操作があった場合は判定が満たされ（ステップＳ１３３：ＹＥＳ）、サーバ制御部は、新たに設けたステップＳ１３４に処理を移す。

ステップＳ１３４では、サーバ制御部は、上記ステップＳ１３０と同様、投稿された動画データフォルダの映像データの公開を拒否するＮＧ結果を操作端末３０（ＰＣ）に送信する。この送信するＮＧ結果には、動画データフォルダの映像データを、いわゆるアバター等の歌唱者を模した所定の静止画または動画等の設定画像に差し替える、旨の通知情報を含ませることができる。ステップＳ１３４が終了すると、サーバ制御部は、新たに設けたステップＳ１３５に処理を移す。

ステップＳ１３５では、サーバ制御部は、サーバ４０のデータ格納部に予め格納して用意してあるアバター（歌唱者を模した所定の静止画または動画の設定図像）を読み出す。そして、サーバ制御部は、動画データフォルダの映像データをアバターに差し替える差し替え処理を行う。ステップＳ１３５が終了すると、サーバ制御部は、ステップＳ１４０に処理を移す。

ステップＳ１４０では、上記図４と同様、サーバ制御部は、動画データフォルダ（投稿データ）をサーバ４０上に公開する。この動画データフォルダは、上記ステップＳ１３２でＯＫ結果を送信した動画データフォルダ（投稿データ）であり、かつ、上記ステップＳ１３５で映像データの差し替え処理を行った動画データフォルダである。その後、サーバ制御部は、本フローの処理を終了する。
なお、このステップＳ１４０が各請求項記載の公開手段として機能する。

次に、上記に対応して、操作端末３０のＣＰＵ３１によって実行される処理手順を図１３により説明する。図１３のフローチャートは、図５に示したフローチャートのステップＳ２３０、ステップＳ２５５、ステップＳ２６０の代わりに、それぞれステップＳ２３２、ステップＳ２５７、ステップＳ２６２を設けた点が異なる。

図１３において、ステップＳ２１０で、上記図５と同様、ＣＰＵ３１は、サーバ４０から動画データフォルダに含まれる歌唱データフォルダの歌唱データの検閲結果（上記図１２のステップＳ１２０又はステップＳ１３０参照）が送られてきたか否かを判定する。サーバ４０から歌唱データの検閲結果が送信されるまで判定が満たされず（ステップＳ２１０：ＮＯ）、ＣＰＵ３１は、ステップＳ２１０の処理をループして待機する。サーバ４０から歌唱データの検閲結果が送信されると判定が満たされ（ステップＳ２１０：ＹＥＳ）、ＣＰＵ３１は、ステップＳ２１５に処理を移す。

また、本変形例のステップＳ２２０では、ＣＰＵ３１は、上記図５と同様、表示部３４に表示された検閲結果がＯＫ結果であるか否かを判定する。表示部３４に表示された検閲結果がＯＫ結果である場合は判定が満たされ（ステップＳ２２０：ＹＥＳ）、その後、ＣＰＵ３１は、本フローの処理を終了する。表示部３４に表示された検閲結果がＯＫ結果でない場合は判定が満たされず（ステップＳ２２０：ＮＯ）、ＣＰＵ３１は、ステップＳ２２５に処理を移す。

ステップＳ２２５では、上記図５と同様、ＣＰＵ３１は、ユーザによるサーバ４０へのアクセス操作があるか否かを判定する。ユーザが操作部３３を用いてサーバ４０へのアクセス操作を行うまでは判定が満たされず（ステップＳ２２５：ＮＯ）、ステップＳ２２５をループして待機する。ユーザがサーバ４０へのアクセス操作を行った場合はステップＳ２２５の判定が満たされ（ステップＳ２２５：ＹＥＳ）、ＣＰＵ３１は、新たに設けたステップＳ２３２に処理を移す。

ステップＳ２３２では、ＣＰＵ３１は、ネットワークＮＷを介してサーバ４０へアクセスする。そして、ＣＰＵ３１は、サーバ４０にアップロードされた動画データフォルダにアクセスする。アクセスされた動画データフォルダには、上述のようにカラオケ楽曲の曲ＩＤが含まれる。この動画データフォルダに含まれる歌唱データフォルダ内の歌唱データには、前述したように、サーバ４０において、公開が不適当とした歌唱データそのものに公開拒否情報を付随させることができる。ダウンロードした動画データフォルダはメモリ３２に格納される。ステップＳ２３２が終了すると、ＣＰＵ３１は、ステップＳ２３５に処理を移す。

ステップＳ２３５では、上記図５と同様、ＣＰＵ３１は、表示部３４に制御信号を出力する。そして、ＣＰＵ３１は、上記アクセスした動画データフォルダに含まれる歌唱データフォルダ内の歌唱データの一覧（この例では例えば３回分の歌唱データ）を表示する。ステップＳ２３５が終了すると、ＣＰＵ３１は、ステップＳ２４０に処理を移す。

ステップＳ２４０では、上記図５と同様、ＣＰＵ３１は、ユーザが表示部３４に表示された歌唱データフォルダ内の複数個の歌唱データの一覧の中からいずれか１つの歌唱データを削除する削除要求操作を行ったか否かを判定する。ユーザは、図１２のステップＳ１３２でサーバ４０から操作端末３０に送信されたＮＧ結果に含まれる公開拒否情報、あるいは操作端末３０の表示部３４に表示された複数の歌唱データのうちの公開拒否の対象となった歌唱データに付随した公開拒否情報を見ることによって、削除すべき歌唱データを知ることができる。これによりユーザは、操作部３３を用いて該当する歌唱データの削除要求操作をサーバ４０に対し行うことができる。ユーザが歌唱データの削除要求操作を行った場合は判定が満たされ（ステップＳ２４０：ＹＥＳ）、ＣＰＵ３１は、ステップＳ２４５に処理を移す。ユーザが歌唱データの削除要求操作を行わなかった場合は判定が満たされず（ステップＳ２４０：ＮＯ）、ＣＰＵ３１は、後述のステップＳ２５０に処理を移す。

ステップＳ２４５では、上記図５と同様、ＣＰＵ３１は、上記ステップＳ２３５で表示された歌唱データフォルダ内の複数の歌唱データのうち、ユーザの削除要求操作の対象となった歌唱データを削除する削除要求（編集要求）をサーバ４０に送信する。サーバ４０のサーバ制御部はこの削除要求を受信し（各請求項記載の受信手段としての機能）た後、さらに編集処理として、当該削除要求の対象となったいずれかの歌唱データを上記歌唱データフォルダから削除する（各請求項記載の実行手段としての機能）。こうしてステップＳ２４５が終了すると、ＣＰＵ３１は、ステップＳ２５０に処理を移す。

ステップＳ２５０では、上記図５と同様、ＣＰＵ３１は、動画フォルダに含まれる歌唱データフォルダ内の複数の歌唱データのうちの、公開拒否対象の全ての歌唱データの削除が完了したか否かを判定する。言い換えれば、ＣＰＵ３１は、歌唱データフォルダを含む動画データフォルダの編集が終了した否かを判定する。歌唱データフォルダ内に公開拒否対象の歌唱データが残っていれば判定が満たされず（ステップＳ２５０：ＮＯ）、ＣＰＵ３１は、上記ステップＳ２３５に処理を戻して同様の手順を繰り返す。歌唱データフォルダ内に公開拒否対象の歌唱データがなくなった場合は判定が満たされ（ステップＳ２５０：ＹＥＳ）、ＣＰＵ３１は、新たに設けたステップＳ２５７に処理を移す。

ステップＳ２５７では、ＣＰＵ３１は、上記図５のステップＳ２５５と同様、公開拒否対象の歌唱データが削除された後に残った歌唱データで歌唱データフォルダを上書きして動画データフォルダを上書き更新する指示をサーバ４０に出力する。これにより、サーバ４０のサーバ制御部は、上記動画データフォルダを更新する。ステップＳ２５７が終了すると、ＣＰＵ３１は、このフローの処理を終了する。

以上説明したように、本変形例３においては、ユーザは、複数の歌唱データを含むデータを投稿して公開しようするとき、カメラ１６で撮影された歌唱者の歌唱している姿を含む映像データを、歌唱データと併せて投稿することができる。そして、上記映像データとともに投稿された上記第１歌唱データ又は第２歌唱データについては、前述と同様、各データごとに編集することができる。なお、上記においては映像データは編集しなかったが、歌唱データと同様に映像データも操作端末３０側から編集可能としてもよい。

また、複数回の録音時にそれぞれ取得された各回の映像データのうち１つの映像データが選択され、その選択された１つの映像データを動画データフォルダに含めて投稿が行われる。これにより、ユーザは、複数の歌唱データを含むデータを投稿して公開しようするとき、いずれかの回における歌唱者の歌唱している姿を含む映像データを、歌唱データと併せて投稿することができる。１つの映像データに限定することにより、データ量が大きくなりすぎるのを防止し、ネットワーク接続及び通信の円滑化を図ることができる。

また、動画データフォルダに含まれていた１つの映像データが公開不可であった場合に、当該１つの映像データに代えて、アバター等の歌唱者を模した所定の静止画または動画の設定画像を公開する。これにより、映像データとともに投稿された複数の歌唱音のデータに、何の視覚的データも付随しなくなるのを防止することができる。

以上の変形例３では、サーバ４０へ投稿した動画データフォルダに対し、操作端末３０からの編集要求に応じてサーバ４０で編集処理を行ったが、これに限られない。すなわち、操作端末３０に代えてカラオケ装置１０からの編集要求に応じてサーバ４０で編集処理を行うようにしてもよい。

（４）歌唱者が、同一カラオケ楽曲の別の歌唱者の動画に合わせてコラボレーション歌唱し、かつ映像を撮影する場合
すなわち、本変形例では、上記変形例１のように、サーバ４０にアップロード済みの特定カラオケ楽曲の動画データが、ダウンロードされる。その後、ダウンロードされた特定カラオケ楽曲の動画再生に合わせて、歌唱者が、当該ダウンロードした動画と競演してコラボレーション歌唱する。そして、そのときの映像データとともに、上記動画フォルダが生成される。

上記コラボレーション歌唱する本変形例４において、図１０と同様、複数回の録音の各回ごとに、歌唱データがグループ化されて組み込まれることで生成される上記動画データフォルダの例を示す説明図を、図１４に示す。図１４（ａ）は、特定の１つのカラオケ楽曲の動画データ（コラボレーション相手となる歌唱者Ｘ）がダウンロードされた状態を表している。このとき、図示のように、上記歌唱者Ｘの動画データに含まれる歌唱データ（曲ＩＤ付き。以下同様）を含む歌唱データフォルダ（録音ＩＤ「０３１」）が生成され、さらにこれを含む動画データフォルダが生成される。

図１４（ｂ）は、１回目の録音として、上記歌唱者Ｘの歌唱データに歌唱者Ａの歌唱データが組み込まれた歌唱データフォルダ（録音ＩＤ「０３２」）が形成された状態を表している。その際、さらに、上記に対し、１回目録音時の歌唱者である歌唱者Ａの姿を撮影した映像データが組み込まれることで、動画データフォルダが形成されている。さらに図１４（ｃ）は、２回目の録音として、上記歌唱者Ｘの歌唱データ及び歌唱者Ａの歌唱データに、上記歌唱者Ｂの歌唱データが組み込まれた歌唱データフォルダ（録音ＩＤ「０３３」）が形成された状態を表している。その際、さらに、上記に対し、１回目録音時の歌唱者である歌唱者Ａの姿を撮影した映像データが組み込まれることで、動画データフォルダが形成されている。

本変形例４でのカラオケ装置１０の制御部２１によって実行される処理手順を図１５に示す。図１５のフローチャートは、図１１に示すフローチャートのステップＳ１０の代わりにステップＳ５を設け、且つこのステップＳ５とステップＳ１５との間にステップＳ６〜ステップＳ８を設け、ステップＳ１５とステップＳ２０との間に図７と同様のステップＳ１７を設けた点が異なる。

図１５において、まず、新たに設けたステップＳ５で、カラオケ装置１０の制御部２１は、特定のカラオケ楽曲について歌唱者による動画（コラボレーション歌唱用動画）の要求があったか否かを判定する。歌唱者が操作部２３の直接操作またはリモコン１２を介した操作により特定のカラオケ楽曲のコラボレーション用動画の要求操作を行うと、そのカラオケ楽曲の曲ＩＤを取得するとともに、コラボレーション動画要求が行われたと判定する。歌唱者によるカラオケ楽曲のコラボレーション動画要求が行われるまで判定が満たされず（ステップＳ５：ＮＯ）、制御部２１は、ステップＳ１１の処理をループして待機する。歌唱者による特定のカラオケ楽曲のコラボレーション動画要求が行われたら判定が満たされ（ステップＳ５：ＹＥＳ）、制御部２１は、新たに設けたステップＳ６に処理を移す。

ステップＳ６では、制御部２１は、ネットワークＮＷを介してサーバ４０にアクセスする。そして、制御部２１は、サーバ４０のデータ格納部に格納されたアップロード済みの動画データの一覧を表示部２８に表示する。ステップＳ６が終了すると、制御部２１は、新たに設けたステップＳ７に処理を移す。

ステップＳ７では、制御部２１は、歌唱者により、表示部２８に表示された動画データの一覧から１つの動画データが選択されたか否かを判定する。歌唱者が操作部２３の直接操作またはリモコン１２を介した操作により特定の動画データの選択操作を行うまで判定が満たされず（ステップＳ７：ＮＯ）、制御部２１は、ステップＳ７の処理をループして待機する。歌唱者が特定の動画データの選択操作を行った場合は判定が満たされ（ステップＳ７：ＹＥＳ）、制御部２１は、新たに設けたステップＳ８に処理を移す。

ステップＳ８では、制御部２１は、ネットワークＮＷを介してサーバ４０にアクセスする。そして、制御部２１は、サーバ４０のデータ格納部に格納されたアップロード済みの動画データの中から上記ステップＳ７で選択した動画データをダウンロードする。そして制御部２１は、上記ダウンロードした動画データに含まれる歌唱データ（第１歌唱データに相当）をカラオケ楽曲の曲ＩＤと対応付けて組み込んだ歌唱データフォルダを作成し、さらにこれを含む動画データフォルダを作成（上記図１４（ａ）参照）して、大容量記憶装置２２に格納する。ステップＳ８が終了すると、ステップＳ１５に処理を移す。

ステップＳ１５では、制御部２１は、上記図１１及び図７と同様、上記ステップＳ７での特定のカラオケ楽曲の動画データの選択に基づき、大容量記憶装置２２から、当該選択に係わる特定のカラオケ楽曲に対応した楽曲データ、及び歌詞データ等を読み出す。そして、音源２５等に、上記楽曲データの再生を開始させるとともに、表示部２８が上記楽曲データの再生と同期して、上記歌詞データの表示を開始する。ステップＳ１５が終了すると、制御部２１は、ステップＳ１７に処理を移す。

ステップＳ１７では、制御部２１は、上記図７と同様、上記ステップＳ８でダウンロードした第１歌唱データ及び映像データを読み出す。そして、制御部２１は、音源２５等に、上記楽曲データの再生と同期して、第１歌唱データの再生を開始させる。また、表示部２８が、上記映像データの再生を開始して表示する。これにより、上記ステップＳ１５で開始されるカラオケ楽曲の再生に同期して、第１歌唱データの再生及び映像データの再生が開始される。歌唱者は、マイクロフォン１４を手にして、カラオケ楽曲の再生に合わせて第１歌唱者の映像を見ながら歌唱する。これにより、歌唱者は、第１歌唱者とコラボレーション歌唱（競演）することができる。歌唱者によるカラオケ楽曲のコラボレーション歌唱でマイクロフォン１４に入力された歌唱音は、マイクロフォン１４で音声信号に変換される。そして、変換された音声信号が第２歌唱データとして音声制御部２６に出力される。ステップＳ１７が終了すると、制御部２１は、ステップＳ２０に処理を移す。

ステップＳ２０の手順は図１１及び図７と同じである。ステップＳ２０において、制御部２１は、マイクロフォン１４から出力された歌唱者の歌唱データ（第２歌唱データ）を取得する。ステップＳ２０が終了すると、制御部２１は、ステップＳ２２に処理を移す。

ステップＳ２２では、制御部２１は、上記図１１と同様、上記ステップＳ２０でのカラオケ楽曲の歌唱データを取得するのに合わせて、当該カラオケ楽曲の歌唱時における歌唱者の姿を撮影した映像データをカメラ１６より取得する。ステップＳ２２が終了すると、ステップＳ２７に処理を移す。

ステップＳ２７〜ステップＳ３７の手順は、図１１と同じであり、説明を省略する。

以上において、上記ステップＳ２２の手順は各請求項記載の映像取得手段として機能し、上記ステップＳ８及びステップＳ２０の手順は各請求項記載の歌唱音取得手段として機能する。

以上説明したように、本変形例４においては、サーバ４０からダウンロードして再生した映像データ（第１歌唱データを含む）とコラボレーション歌唱して、その歌唱時に撮影した歌唱者の姿を含む映像データを、歌唱データと併せて投稿することができる。そして、上記映像データとともに投稿された上記第１歌唱データ又は第２歌唱データについては、前述と同様、各データごとに編集することができる。なお、上記においては撮影した映像データは編集しなかったが、歌唱データと同様に映像データも操作端末３０側から編集可能としてもよい。

なお、図３、図４、図５、図７、図８、図９、図１１、図１２、図１３、図１５に示すフローチャートは本発明を上記フローに示す手順に限定するものではなく、発明の趣旨及び技術的思想を逸脱しない範囲内で手順の追加・削除または順番の変更等をしてもよい。

また、以上既に述べた以外にも、上記実施形態による手法を適宜組み合わせて利用しても良い。

その他、一々例示はしないが、本発明は、その趣旨を逸脱しない範囲内において、種々の変更が加えられて実施されるものである。

１ カラオケシステム
１０ カラオケ装置
１４ マイクロフォン
１６ カメラ
２１ 制御部
２２ 大容量記憶装置
２８ 表示部（表示手段）
３０ 操作端末
３１ ＣＰＵ
３２ メモリ
３３ 操作部（操作手段）
３４ 表示部（表示手段）
４０ サーバ

Claims (4)

1. カラオケ楽曲を再生可能であり、且つ、特定のカラオケ楽曲について、歌唱者により歌唱される歌唱音を複数回録音可能であり、且つ、前記特定のカラオケ楽曲について、歌唱者により過去に録音された少なくとも１つの第１歌唱音に重ねて、新たに入力される第２歌唱音を合わせて出力可能なカラオケ装置と、
   ネットワークを介して前記カラオケ装置と接続可能なサーバと、
   を備えるカラオケシステムであって、
   前記カラオケ装置は、
   前記サーバから前記第１歌唱データをダウンロードするダウンロード手段と、
   前記特定のカラオケ楽曲について録音可能な複数回の歌唱ごとに、歌唱者により歌唱された前記第２歌唱音を取得する歌唱音取得手段と、
   前記歌唱音取得手段が録音可能な複数回の歌唱ごとに前記第２歌唱音を取得するのにしたがい、前記第２歌唱音の歌唱者を撮影可能な撮影手段により撮影された映像データを取得する映像取得手段と、
   前記映像取得手段により取得された各回の映像データのうち、１つの映像データを決定する映像決定手段と、
   複数回の録音可能な回数ごとに、前記歌唱音取得手段により取得された前記第２歌唱音を示す第２歌唱データと、前記第２歌唱音に重ねて出力された前記第１歌唱音を示す第１歌唱データとを、複数回の各回の歌唱データを互いに合成されることなく、互いに独立しつつ１つの歌唱データフォルダ内にグループ化した歌唱データフォルダに、前記映像決定手段により決定された１つの映像データが組み込まれることで形成される動画データフォルダにして、録音歌唱データとして記憶する記憶手段と、
   前記特定のカラオケ楽曲について、複数回録音された前記録音歌唱データの中から、ネットワークに公開するための録音歌唱データを決定する決定手段と、
   前記決定手段により決定された録音歌唱データと、決定された録音歌唱データと合わせて前記記憶手段に記憶された複数回の前記第１歌唱データまたは前記第２歌唱データと、を、ネットワークに接続される前記サーバへ投稿する投稿手段と、
   を備え、
   前記サーバは、
   前記決定手段により決定され、前記ネットワークへ公開された録音歌唱データについて、前記カラオケ装置または前記カラオケシステムに接続可能な端末装置から要求された前記録音歌唱データの編集要求を受信する受信手段と、
   前記受信手段により受信された編集要求に基づいて、ネットワークへ公開された録音歌唱データに対応付けられた前記第１歌唱データ及び前記第２歌唱データを用いて編集処理を実行する実行手段と、
   前記実行手段により編集処理が実行された結果、編集された前記第１歌唱データまたは前記第２歌唱データを、ネットワークへ公開する公開手段と、
   を備え、
   前記投稿手段は、前記ダウンロード手段によりダウンロードした前記第１歌唱データに、前記第２歌唱データと、前記第２歌唱データに示される前記第２歌唱音を歌唱した歌唱者を撮影した前記映像データと、を対応付けて、複数回の各回の歌唱データを互いに合成されることなく、互いに独立しつつ１つの歌唱データフォルダ内にグループ化した歌唱データフォルダに、１つの映像データが組み込まれることで形成される動画データフォルダにして、前記サーバヘ投稿する
   ことを特徴とするカラオケシステム。
2. 請求項１に記載のカラオケシステムにおいて、
   前記受信手段は、
   前記編集要求として、ネットワークへ公開された録音歌唱データに対応付けられた前記第１歌唱データ及び前記第２歌唱データの中から、所望の前記第１歌唱データまたは前記第２歌唱データを除いたデータによる編集要求であって、サーバ側から公開拒否情報が通知された前記カラオケ装置または前記端末装置から、前記公開拒否情報に対する編集要求の指示を受信し、
   前記実行手段は、
   ネットワークへ公開された録音歌唱データに対応付けられた前記第１歌唱データ及び前記第２歌唱データの中から、所望の前記第１歌唱データまたは前記第２歌唱データを除いたデータにより、前記公開拒否情報に対する編集要求の指示に対応する編集処理を、前記編集要求の前記公開拒否情報が示す公開拒否対象のデータが無くなるまで繰り返し実行し、
   前記公開手段は、
   前記実行手段により編集処理が、前記公開拒否情報が示す前記公開可否情報のデータが無くなるまで繰り返し実行された結果、編集された後の、前記公開拒否対象のデータがなくなった前記第１歌唱データまたは前記第２歌唱データを、ネットワークへ公開することを特徴とするカラオケシステム。
3. 請求項２に記載のカラオケシステムにおいて、
   前記カラオケ装置は、
   第１歌唱者により過去に録音された少なくとも１つの前記第１歌唱音に重ねて、前記第１歌唱者とは異なる第２歌唱者により新たに入力される前記第２歌唱音を合わせて出力可能であり、
   前記歌唱音取得手段は、
   録音可能な複数回の歌唱ごとに、前記第２歌唱者により歌唱された前記第２歌唱音を取得し、
   前記サーバにおいて、
   前記実行手段は、
   ネットワークへ公開された録音歌唱データに対応付けられた前記第１歌唱データまたは前記第２歌唱データの中から、所望の前記第１歌唱データまたは前記第２歌唱データを除いたデータにより、編集処理を実行し、
   前記公開手段は、
   前記実行手段により編集処理が実行された結果、編集された前記第１歌唱データまたは前記第２歌唱データを、ネットワークへ公開することを特徴とするカラオケシステム。
4. 請求項１から請求項３のいずれか一項に記載のカラオケシステムにおいて、
   前記サーバにおいて、
   前記受信手段は、前記編集要求として、投稿されている前記映像データの編集要求を受信し、
   前記実行手段は、前記映像データの代わりに、所定の設定画像により、編集処理を実行し、
   前記公開手段は、
   前記実行手段により編集処理が実行された結果、前記設定画像に対応付けられた前記第１歌唱データまたは前記第２歌唱データを、ネットワークへ公開することを特徴とするカラオケシステム。

Images