(57)【要約】【課題】楽曲などのオーディションを一般視聴者からの投票によって行なう場合に、それらの評価が公平になされるシステム等を提供することを目的とする。【解決手段】サーバー１内には、評価対象となる楽曲が記憶されており、その楽曲数と評価者数から、一人の評価者に提示する適切な楽曲数を決定する。そして、サーバー１内に記憶されている、一人何回まで評価ができるかという評価許容回数データと、オーディションをいつの時点で締め切るかという締め切り時データを参照し、これらを満たしている場合に、評価者に所定数の楽曲を提示する。評価者は楽曲を試聴後、評価した点数をサーバー１に送信し、サーバー１は、その評価が有効か否かを判断し、有効である時のみ、その評価点数を集計して順位付けを行なう。 【選択図】  図２
2005165889.tif 000002
【特許請求の範囲】
【請求項１】
複数の評価対象物を記憶する手段と、
評価者に提示する提示対象物数を記憶する手段と、
前記評価対象物の中から前記提示対象物数の数だけ前記評価対象物を抽出する評価対象物抽出手段と、
その抽出した前記評価対象物を評価者が利用する評価手段に送信する手段と、
前記評価手段から前記評価対象物に関する評価を受け付けそれを集計処理する手段とを備えることを特徴とする評価システム。
【請求項２】
前記集計処理に基づいて前記評価対象物の順位を決定する手段を備えることを特徴とする請求項１記載の評価システム。
【請求項３】
前記評価対象物抽出手段には、その抽出した評価対象物の組合せを作成する組合せ作成手段が含まれることを特徴とする請求項１乃至２記載の評価システム。
【請求項４】
評価者数並びに評価者数と提示対象物数とが対応付けられている提示対象物数情報を記憶する手段と、
前記提示対象物数を、前記評価者数に基づいて前記評価対象物数情報を検索し対応する提示対象物数を抽出することにより決定する手段とを備えることを特徴とする請求項１乃至３記載の評価システム。
【請求項５】
評価者を特定する評価者特定情報及び評価許容回数情報を記憶する手段と、
前記評価者特定情報及び前記評価許容回数情報に基づいて同一評価者による複数回の評価を制限する手段とを備えることを特徴とする請求項１乃至４記載の評価システム。
【請求項６】
前記評価許容回数情報は、任意の評価対象物が抽出される確率と評価許容回数が対応付けられていることを特徴とする請求項５記載の評価システム。
【請求項７】
前記組合せ作成手段は、各組合せを相互に重複しない異なる組合せとする手段であることを特徴とする請求項１乃至６記載の評価システム。
【請求項８】
評価対象物の相互に重複しない異なる組合せ情報を記憶する手段と、
前記組合せ情報を検索し未抽出の組合せの中から任意の組合せを抽出することで評価対象物の組合せを作成する前記組合せ作成手段とを備えることを特徴とする請求項１乃至７記載の評価システム。
【請求項９】
前記組合せ作成手段は、各組合せを相互に重複しない異なる組合せとするものであって、乱数を用いて評価対象物の任意の組合せを作成する手段であることを特徴とする請求項５記載の評価システム。
【請求項１０】
評価の締め切りに関する締め切り時情報を記憶する手段と、
前記締め切り時情報に基づいて評価を締め切る手段とを備えることを特徴とする請求項１乃至９記載の評価システム。
【請求項１１】
前記締め切り時情報は、評価対象物の相互に重複しない異なる組合せの提示回数と評価対象物数とが対応付けられていることを特徴とする請求項１０記載の評価システム。
【請求項１２】
前記締め切り時情報は、予め設定された日時に関する情報であることを特徴とする請求項１０記載の評価システム。
【請求項１３】
評価対象物を評価手段に送信する際に、前記評価対象物に関する情報は伏せて送信する手段を備えることを特徴とする請求項１乃至１２記載の評価システム。
【請求項１４】
評価者が視聴した時間に関する視聴時間情報を記憶する手段と、
評価者が利用する評価手段から視聴時間を受信し、前記視聴時間及び前記視聴時間情報に基づいて評価者による評価が有効であるか否かを判断する手段とを備えることを特徴とする請求項１乃至１３記載の評価システム。
【請求項１５】
コンピュータを、
複数の評価対象物を記憶する手段と、
評価者に提示する提示対象物数を記憶する手段と、
前記評価対象物の中から前記提示対象物数の数だけ前記評価対象物を抽出する評価対象物抽出手段と、
その抽出した前記評価対象物を評価者が利用する評価手段に送信する手段と、
前記評価手段から前記評価対象物に関する評価を受け付けそれを集計処理する手段として機能させることを特徴とする評価プログラム。
【請求項１６】
前記集計処理に基づいて前記評価対象物の順位を決定する手段として機能させることを特徴とする請求項１５記載の評価プログラム。
【請求項１７】
前記評価対象物抽出手段には、その抽出した評価対象物の組合せを作成する組合せ作成手段が含まれることを特徴とする請求項１５乃至１６記載の評価プログラム。
【請求項１８】
評価者数並びに評価者数と提示対象物数とが対応付けられている提示対象物数情報を記憶する手段と、
前記提示対象物数を、前記評価者数に基づいて前記評価対象物数情報を検索し対応する提示対象物数を抽出することにより決定する手段として機能させることを特徴とする請求項１５乃至１７記載の評価プログラム。
【請求項１９】
評価者を特定する評価者特定情報及び評価許容回数情報を記憶する手段と、
前記評価者特定情報及び前記評価許容回数情報に基づいて同一評価者による複数回の評価を制限する手段として機能させることを特徴とする請求項１５乃至１８記載の評価プログラム。
【請求項２０】
前記評価許容回数情報は、任意の評価対象物が抽出される確率と評価許容回数が対応付けられていることを特徴とする請求項１９記載の評価プログラム。
【請求項２１】
前記組合せ作成手段は、各組合せを相互に重複しない異なる組合せとする手段であることを特徴とする請求項１５乃至２０記載の評価プログラム。
【請求項２２】
評価対象物の相互に重複しない異なる組合せ情報を記憶する手段と、
前記組合せ情報を検索し未抽出の組合せの中から任意の組合せを抽出することで評価対象物の組合せを作成する前記組合せ作成手段として機能させることを特徴とする請求項１５乃至２１記載の評価プログラム。
【請求項２３】
前記組合せ作成手段は、各組合せを相互に重複しない異なる組合せとするものであって、乱数を用いて評価対象物の任意の組合せを作成する手段であることを特徴とする請求項１９記載の評価プログラム。
【請求項２４】
評価の締め切りに関する締め切り時情報を記憶する手段と、
前記締め切り時情報に基づいて評価を締め切る手段として機能させることを特徴とする請求項１５乃至２３記載の評価プログラム。
【請求項２５】
前記締め切り時情報は、評価対象物の相互に重複しない異なる組合せの提示回数と評価対象物数とが対応付けられていることを特徴とする請求項２４記載の評価プログラム。
【請求項２６】
前記締め切り時情報は、予め設定された日時に関する情報であることを特徴とする請求項２４記載の評価プログラム。
【請求項２７】
評価対象物を評価手段に送信する際に、前記評価対象物に関する情報は伏せて送信する手段として機能させることを特徴とする請求項１５乃至２６記載の評価プログラム。
【請求項２８】
評価者が視聴した時間に関する視聴時間情報を記憶する手段と、
評価者が利用する評価手段から視聴時間を受信し、前記視聴時間及び前記視聴時間情報に基づいて評価者による評価が有効であるか否かを判断する手段として機能させることを特徴とする請求項１５乃至２７記載の評価プログラム。
【請求項２９】
コンピュータが、
複数の評価対象物を記憶するステップと、
評価者に提示する提示対象物数を記憶するステップと、
前記評価対象物の中から前記提示対象物数の数だけ前記評価対象物を抽出する評価対象物抽出ステップと、
その抽出した前記評価対象物を評価者が利用する評価手段に送信するステップと、
前記評価手段から前記評価対象物に関する評価を受け付けそれを集計処理するステップとから構成されることを特徴とする評価方法。
【請求項３０】
前記集計処理に基づいて前記評価対象物の順位を決定するステップとから構成されることを特徴とする請求項２９記載の評価方法。
【請求項３１】
前記評価対象物抽出ステップには、その抽出した評価対象物の組合せを作成する組合せ作成ステップが含まれることを特徴とする請求項２９乃至３０記載の評価方法。
【請求項３２】
評価者数並びに評価者数と提示対象物数とが対応付けられている提示対象物数情報を記憶するステップと、
前記提示対象物数を、前記評価者数に基づいて前記評価対象物数情報を検索し対応する提示対象物数を抽出することにより決定するステップとから構成されることを特徴とする請求項２９乃至３１記載の評価方法。
【請求項３３】
評価者を特定する評価者特定情報及び評価許容回数情報を記憶するステップと、
前記評価者特定情報及び前記評価許容回数情報に基づいて同一評価者による複数回の評価を制限するステップとから構成されることを特徴とする請求項２９乃至３２記載の評価方法。
【請求項３４】
前記評価許容回数情報は、任意の評価対象物が抽出される確率と評価許容回数が対応付けられていることを特徴とする請求項３３記載の評価方法。
【請求項３５】
前記組合せ作成ステップは、各組合せを相互に重複しない異なる組合せとするステップであることを特徴とする請求項２９乃至３４記載の評価方法。
【請求項３６】
評価対象物の相互に重複しない異なる組合せ情報を記憶するステップと、
前記組合せ情報を検索し未抽出の組合せの中から任意の組合せを抽出することで評価対象物の組合せを作成する前記組合せ作成ステップとから構成されることを特徴とする請求項２９乃至３５記載の評価方法。
【請求項３７】
前記組合せ作成ステップは、各組合せを相互に重複しない異なる組合せとするものであって、乱数を用いて評価対象物の任意の組合せを作成するステップであることを特徴とする請求項３３記載の評価方法。
【請求項３８】
評価の締め切りに関する締め切り時情報を記憶するステップと、
前記締め切り時情報に基づいて評価を締め切るステップとから構成されることを特徴とする請求項２９乃至３７記載の評価方法。
【請求項３９】
前記締め切り時情報は、評価対象物の相互に重複しない異なる組合せの提示回数と評価対象物数とが対応付けられていることを特徴とする請求項３８記載の評価方法。
【請求項４０】
前記締め切り時情報は、予め設定された日時に関する情報であることを特徴とする請求項３８記載の評価方法。
【請求項４１】
評価対象物を評価手段に送信する際に、前記評価対象物に関する情報は伏せて送信するステップとから構成されることを特徴とする請求項２９乃至４０記載の評価方法。
【請求項４２】
評価者が視聴した時間に関する視聴時間情報を記憶するステップと、
評価者が利用する評価手段から視聴時間を受信し、前記視聴時間及び前記視聴時間情報に基づいて評価者による評価が有効であるか否かを判断するステップとから構成されることを特徴とする請求項２９乃至４１記載の評価方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、楽曲などを一般視聴者からの投票によって公平に評価するシステム等に関するものである。
【背景技術】
【０００２】
従来、インターネット等の通信手段を介して楽曲などのオーディションを一般視聴者からの投票によって行なう場合、その評価の対象となる全作品のリストを掲載し、評価者はそのリストの中から任意の曲を選択・試聴して投票を行なうのが一般的であった。
【０００３】
【特許文献１】特開２００３−２８０６６９号公報（第７頁）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしこの方法だと、例えば５０曲のリストがあった場合、全ての楽曲を試聴するには膨大な時間と手間がかかるので、評価者の多くは全ての楽曲を試聴することなく、ほんの数曲を試聴しただけで投票をしてしまったり、十分吟味することなく評価をしてしまったりしていた。
また、例えば５０曲のリストを提示して、試聴及び評価を評価者の自由な選択に任せると、リストに掲載されているもののうち、その前半部分に試聴及び評価が偏り、試聴の機会が公平に確保されているとは言い難かった。
このように、リストに載っていてオーディションの対象となっている楽曲が試聴すらされず無視されてしまったり、十分吟味することなく評価されてしまったりするということは、公平性に欠け、またそのような評価を基にした順位は不確かなものといえる。
また、評価対象となる全作品のリストを掲載し評価を促す場合には、自己又は知人の作品に対して有利な評価を下したり、複数回にわたって繰り返し有利な評価を行なったりなどの不正投票を阻止することができず、その評価は公平性に欠けるという問題があった。
本発明はこのような問題に鑑みてなされたものであり、楽曲などのオーディションを一般視聴者からの投票によって行なう場合に、それらの評価が公平になされるシステム等を提供するものである。
【課題を解決するための手段】
【０００５】
本発明は、例えば、次のようなシステム、次のような処理を行わせる方法、コンピュータプログラムである。
（１）複数の評価対象物を記憶する手段と、評価者に提示する提示対象物数を記憶する手段と、前記評価対象物の中から前記提示対象物数の数だけ前記評価対象物を抽出する評価対象物抽出手段と、その抽出した前記評価対象物を評価者が利用する評価手段に送信する手段と、前記評価手段から前記評価対象物に関する評価を受け付けそれを集計処理する手段とを備えている。
（２）前記集計処理に基づいて前記評価対象物の順位を決定する手段を備えている。
（３）前記評価対象物抽出手段には、その抽出した評価対象物の組合せを作成する組合せ作成手段が含まれている。
（４）評価者数並びに評価者数と提示対象物数とが対応付けられている提示対象物数情報を記憶する手段と、前記提示対象物数を、前記評価者数に基づいて前記評価対象物数情報を検索し対応する提示対象物数を抽出することにより決定する手段とを備えている。
（５）評価者を特定する評価者特定情報及び評価許容回数情報を記憶する手段と、前記評価者特定情報及び前記評価許容回数情報に基づいて同一評価者による複数回の評価を制限する手段とを備えている。
（６）前記評価許容回数情報は、任意の評価対象物が抽出される確率と評価許容回数が対応付けられている。
（７）前記組合せ作成手段は、各組合せを相互に重複しない異なる組合せとする手段である。
（８）評価対象物の相互に重複しない異なる組合せ情報を記憶する手段と、前記組合せ情報を検索し未抽出の組合せの中から任意の組合せを抽出することで評価対象物の組合せを作成する前記組合せ作成手段とを備えている。
（９）前記組合せ作成手段は、各組合せを相互に重複しない異なる組合せとするものであって、乱数を用いて評価対象物の任意の組合せを作成する手段である。
（１０）評価の締め切りに関する締め切り時情報を記憶する手段と、前記締め切り時情報に基づいて評価を締め切る手段とを備えている。
（１１）前記締め切り時情報は、評価対象物の相互に重複しない異なる組合せの提示回数と評価対象物数とが対応付けられている。
（１２）前記締め切り時情報は、予め設定された日時に関する情報である。
（１３）評価対象物を評価手段に送信する際に、前記評価対象物に関する情報は伏せて送信する手段を備えている。
（１４）評価者が視聴した時間に関する視聴時間情報を記憶する手段と、評価者が利用する評価手段から視聴時間を受信し、前記視聴時間及び前記視聴時間情報に基づいて評価者による評価が有効であるか否かを判断する手段とを備えている。
【発明の効果】
【０００６】
本発明には次のような効果がある。
（１）本発明では、評価の対象となる全作品を提示することはせず、少数の組合せとして提示するので、確実に試聴し十分吟味した上で評価付けがなされることが期待できる。また、評価者に対して提示される数は、評価対象となる全作品数と評価者総数により決められるので、吟味する上で適切な数とすることができる。
（２）評価者が作品を評価する際、評価者に持ち点を与えて点数により評価を行なうこととするので、優劣の差が明確となり、評価に基づく順位が確かなものとなる。
（３）評価回数を制限するので、同一評価者による複数回の不正な評価を阻止できる。また、評価対象作品が提示される確率に応じて評価回数を決めるようにするので、より適切に不正な評価を阻止することが可能となる。
（４）評価の対象となる作品を提示する際、曲名やアーティスト名など、その作品に関する詳細な情報は伏せて提示するので、不正な評価を阻止することができる。
（５）十分吟味せずに評価した場合、例えば楽曲を実際に試聴せず評価したり、ほんのわずかしか聞かずに評価したりした場合、その評価は無効とするので、公正な評価が期待できる。
【発明を実施するための最良の形態】
【０００７】
本発明は、楽曲などを一般視聴者からの投票によって公平に評価するシステム等に関するものである。以下、図面に基づいて説明する。
【実施例１】
【０００８】
本発明の実施形態を図に基づいて説明する。図１は本発明の実施に必要なハードウェアとそのハードウェアの結びつきを表した概略図である。
これらハードウェアは、サーバー１（オーディションなどを開催し作品の順位付けを行なう会社が利用するサーバー）と、評価者（ユーザー）が利用するコンピュータ２（ＰＣ２）とからなる。
このサーバー１、ＰＣ２は各々インターネット３（あるいはその他の通信手段）を通じてデータの送受信が可能になるよう接続されている。
サーバー１、ＰＣ２はデータを記憶するための記憶装置とデータを送受信するためのデータ送信部並びにデータ受信部とを各々内蔵し、それらを用いてデータの送受信を行う。
【０００９】
各々の記憶装置には本発明を実現するためのコンピュータプログラムや所定のデータが記憶されており、サーバー１、ＰＣ２はこのコンピュータプログラムの処理命令に従って所定の処理を行い、本発明を実施する。
ＰＣ２にはデータを表示するための表示モニタ１１、データ入力用のキーボード１２、入力用のマウス１３が備えられている。
なお、ここではサーバー１が処理手段としての役割を果たし、サーバー１に備えられている記憶装置が記憶手段としての役割を果たし、ＰＣ２が評価手段としての役割を果たす。
また本実施形態では、ＰＣ２を利用しているがこれに限るものではなく、例えば、携帯電話やＰＤＡ等の通信機能を備えた携帯型移動端末等にしてもよい。また、双方向機能をもったテレビ受像機等にしてもよい。
【００１０】
次に、本発明を実現するための処理手順について説明する。なお、ここでは便宜的に、評価の対象となるものを「楽曲」とするがこれに限るものではない。本発明の処理手順は、＜ユーザー確認処理＞→＜評価者登録処理＞→＜提示楽曲数抽出処理＞→＜組合せ算出処理＞→＜提示確率算出処理＞→＜評価許容回数抽出処理＞→＜評価許容判断処理＞→＜締め切り時抽出処理＞→＜楽曲提示処理＞→＜評価判断処理＞→＜点数計算処理＞→＜順位付け処理＞の手順で行う。以下、これら処理について説明する。
【００１１】
＜ＳＴＥＰ１：ユーザー確認処理＞
ドリームミュージックという会社は、楽曲のオーディションを、インターネットを利用した一般視聴者からの投票によって決定する事業を行なっている。
なおドリームミュージックと楽曲の著作者との間で、楽曲を自動公衆送信することに関しての契約を取り交わしておくのが望ましい。
東京都在住の佐藤一郎さんは、この楽曲オーディションの投票に参加したいと考え、自宅にあるＰＣ２を利用してドリームミュージックが運営するホームページにアクセスした。これによりＰＣ２の表示モニタ１１には、図３のような内容が表示される。なお、佐藤さんは既にこのドリームミュージックの会員になっており、住所や氏名などは登録済みであり、この会社のユーザーＩＤも既に取得済みであるとする。
【００１２】
佐藤さんは、表示画面に従って自分のユーザーＩＤとパスワードを入力し、画面下の「送信」をクリックする。これにより、ＰＣ２はユーザー確認データ「ユーザーＩＤ：Ｕ０１５／パスワード：１５４９」を作成し、これをサーバー１に送信する。ユーザー確認データを受信したサーバー１は、これを記憶装置に記憶する。
サーバー１にはユーザーファイルが記憶されている（図４）。このユーザーファイルは複数のユーザーレコードからなるものであり、佐藤さんの情報（レコード：図４）「ユーザーＩＤ：Ｕ０１５／パスワード：１５４９／名前：佐藤一郎／住所：東京都港区赤坂○−○−○／年齢：２５／性別：男／電話番号：０３−３５８２−△△△△／電子メール：sato@tokyo.co.jp」も既にこのファイルに組み込まれているものとする。
サーバー１は、ユーザー確認データに含まれる「ユーザーＩＤ：Ｕ０１５」に基づいてユーザーファイルを検索し、検索したレコードのパスワードとログイン時に入力したパスワードとを照合し、それが一致する場合は、次の処理＜評価者登録処理＞を行う。一方、一致しない場合は「パスワードが一致しません。再度入力して下さい」などのメッセージをＰＣ２に送信する。
本実施例では、このユーザーＩＤが評価者特定情報としての役割を果たす。
【００１３】
＜ＳＴＥＰ２：評価者登録処理＞
サーバー１には複数の評価者レコードからなる評価者ファイルが記憶されており（図５）、上記ＳＴＥＰ１でユーザー確認がなされた佐藤さんの情報（レコード：図５）「登録番号：９６９／ユーザーＩＤ：Ｕ０１５／パスワード：１５４９／名前：佐藤一郎／住所：東京都港区赤坂○−○−○／年齢：２５／性別：男／電話番号：０３−３５８２−△△△△／電子メール：sato@tokyo.co.jp／評価回数０」も、この評価者ファイルに登録される。
【００１４】
＜ＳＴＥＰ３：提示楽曲数抽出処理＞
次にサーバー１は、評価者（佐藤さん）に対して提示する楽曲数を決定する処理を行う。つまり、従来のように評価対象となる全楽曲を提示するのではなく、何曲かをサーバー１が選択・抽出して、評価者に提示する。この「評価者に何曲を提示するか」が、本処理である。
【００１５】
サーバー１の記憶装置には、図６に示す通り、提示楽曲数データが記憶されている。これは、評価者数と評価者に対して提示する楽曲数が対応付けられて記憶されているデータである。
サーバー１内には、図８に示す通り、評価の対象となる楽曲ファイルが記憶されており、今回の評価に関しては全５０の楽曲レコードから成っているとする。
ここで今回のオーディションの評価者数を６０００人とすると、サーバー１は、サーバー１内に記憶されているこの「評価者数６０００」に基づいて図６の提示楽曲数データを参照し、一人の評価者に対しては、２曲を提示することを決定する。このようにして評価者に対して提示する楽曲数を決めるようにすれば、全楽曲数に対して評価者の数が多かった時には、提示曲数は少なくなり、逆に全楽曲数に対して評価者の数が少なかった時には、一人の評価者に対して提示する楽曲数を多くすることができ、評価者に対して提示する楽曲数を適切な数とすることができる。
【００１６】
なお図６では、評価者数と評価者に対して提示する楽曲数が対応付けられて記憶されているデータを用いているが、オーディション対象となる全楽曲数と評価者に対して提示する楽曲数が対応付けられて記憶されているデータを用いてもよい。
また、評価者数と全楽曲数に基づいて提示楽曲数を決めるようにしてもよい。例えば図７のように、評価者数を全楽曲数で割った数値と提示楽曲数が対応付けられているデータを用いる等である。
また一律に、提示する楽曲数は２曲などと、一定の数に決めておいても良い。なお、提示する楽曲数は１曲であっても構わない。
本実施例においては、この提示楽曲数データが提示対象物数情報としての役割を果たす。
【００１７】
＜ＳＴＥＰ４：組合せ算出処理＞
ＳＴＥＰ３で、評価者一人に対して提示する楽曲数が２曲と決まったら、次にサーバー１は、一人の評価者に対して提示される２曲の楽曲の組合せを算出する処理を行う。具体的には以下の通りである。
サーバー１内には、図８に示す通り、評価の対象となる楽曲ファイルが記憶されており、今回の評価に関しては全５０の楽曲レコードから成っているとする。各楽曲レコードにはそれぞれ１〜５０のエントリーＮＯ.が付されている。ここで５０曲を一人の評価者に対して２曲ずつ提示する場合、その組合せは、全て異なる組合せとした場合、（１，２）、（１，３）・・・（１，５０）、（２，３）、（２，４）、・・・（２，５０）…、（４９，５０）のように、１２２５通り存在する。つまり、５０Ｃ２＝５０×４９／２×１＝１２２５通りと算出される。なお、「Ｃ」は「Combination」の略である。
【００１８】
サーバー１内には、上記公式「ｎＣｒ＝ｎ（ｎ−１）（ｎ−２）…（ｎ−ｒ＋１）／ｒ（ｒ−１）（ｒ−２）…２×１」が記憶されており（ｎを全楽曲数、ｒを提示曲数とする）、ｎに全楽曲数の「５０」を、ｒに提示楽曲数の「２」を代入することで重複しない異なる組合せ数を算出する。
そしてサーバー１は、この１２２５通りの、重複しない全ての異なる組合せを乱数を利用するなどして作成し、記憶装置に記憶する（図９）。
以上が、組合せ算出処理である。
【００１９】
＜ＳＴＥＰ５：提示確率算出処理＞
次にサーバー１は、ある楽曲が一人の評価者に対して提示される確率を算出する処理を行う。つまり、ある評価者が、評価対象の５０曲のうち例えばエントリーＮＯ.１の楽曲にあたる確率を算出する。
【００２０】
ここで、本ステップの実際の処理内容の説明に入る前に、まずここでなぜ「提示確率」を算出するのか、について説明する。
一般に、インターネットによるオーディションの投票においては、「投票は一人○回まで」など、投票回数を制限することが多い。この場合、一律に、例えば「２回まで」などと決めてしまうのも一つの方法であるが、本実施例においては、この投票回数を、「ある楽曲が一人の評価者に対して提示される確率」に応じて決めるようにするのが狙いである。例えばここに、エントリーＮＯ.１の楽曲の作成者が、自分の楽曲に対して自ら高得点をつけてオーディションの上位に食い込もうとする不正投票を目論んでいるとする。この場合、例えば、オーディション対象の全楽曲数が、わずか５曲しかない場合、エントリーＮＯ.１の楽曲の作成者にエントリーＮＯ.１の楽曲が提示される確率は極めて高くなるので、投票回数を「一人１回まで」などと少なく制限しておかないと不正投票を有効に阻止できない。しかし一方で、たとえ不正投票を目論んでいたとしても、例えばオーディション対象の全楽曲数が１００曲もあれば、エントリーＮＯ.１の楽曲の作成者にエントリーＮＯ.１の楽曲が提示される確率は極めて低くなるので、投票回数を「一人４回まで」などと複数回の投票を認めても、不正投票が行なわれる可能性はそれほど高くない。つまり、ある楽曲が一人の評価者に対して提示される確率が高い場合には、一人が投票できる回数を少なくしておいて、不正投票を有効に阻止できるようにし、逆に、ある楽曲が一人の評価者に対して提示される確率が低い場合には、一人で何度か繰り返し投票することも許容する、というものである。
よって、次の＜ＳＴＥＰ６＞で、一人何回まで投票可能かという投票回数を決める前提となる、「ある楽曲が一人の評価者に対して提示される確率」を算出するのが、本ステップの処理である。
【００２１】
この、ある楽曲が一人の評価者に対して提示される確率は、次の計算式：確率Ｐ＝ｎ−１Ｃｒ−１／ｎＣｒによって求められる。サーバー１内には、上記公式「Ｐ＝ｎ−１Ｃｒ−１／ｎＣｒ」が記憶されており、ｎに全楽曲数の「５０」を、ｒに提示楽曲数の「２」を代入することで、４％という確率が算出される。つまり、全楽曲５０曲を一人に対して２曲ずつ提示する場合、例えばエントリーＮＯ.１の楽曲がある一人の評価者に提示される確率は４％となる。
【００２２】
なお＜ＳＴＥＰ９：楽曲提示処理＞で後述するように、乱数を用いた方式により、提示する楽曲の組合せを決定する場合には、上記＜提示確率算出処理＞は不要である。評価者に提示する２曲の組合せを、乱数を用いてランダムに決する場合には、「ある楽曲が一人の評価者に対して提示される確率」というのは意味を成さないからである。
以上が、提示確率算出処理である。
【００２３】
＜ＳＴＥＰ６：評価許容回数抽出処理＞
これは、今回のオーディションにおいて同一の評価者による評価は何回まで可能であるかの判断を行なう処理である。
サーバー１は、上記＜ＳＴＥＰ５：提示確率算出処理＞で算出した４％という数値を基に、評価許容回数データ（図１０）を参照する。これは、ある楽曲が一人の評価者に提示される確率と、同一評価者による評価許容回数が対応付けられているデータである。よってサーバー１は、「提示確率４％」に基づいて図１０の評価許容回数データを参照し、「評価許容回数４回」を抽出する。つまり一人４回まで評価できることになる。このように、ある楽曲が一人の評価者に提示される確率と、評価許容回数を対応付けている理由は、つまるところ、不正投票（身内投票）の防止である。つまり、例えばエントリーＮＯ.１の楽曲の作成者が、自分の作成した楽曲に投票しようとしても、そのエントリーＮＯ.１の楽曲が提示される確率に応じて、評価回数が制限されるので、ある程度身内投票が防止できる。このことは図１０に示す通り、ある楽曲が提示される確率が高い場合には評価許容回数を少なくし、評価回数を制限するようにしていることからも明らかである。
本実施例においては、この評価許容回数データが評価許容回数情報としての役割を果たす。
なお同一評価者の評価許容回数は、一律２回までなどと一定の回数に決めておいても良い。これは＜ＳＴＥＰ９：楽曲提示処理＞で後述するように、乱数を用いた方式で提示する楽曲の組合せを決定した場合に効果的である。
【００２４】
＜ＳＴＥＰ７：評価許容判断処理＞
ＳＴＥＰ６で評価許容回数が４回と算出されたら、次にサーバー１は、佐藤さんの評価回数が４回以下であるか否かの判断処理を行う。具体的には、佐藤さんの「ユーザーＩＤ：Ｕ０１５」に基づいて、図５の評価者ファイルを検索し、佐藤さんのレコードを抽出し、この中の「評価回数」欄を参照する。評価回数が「０」「１」「２」「３」であれば次の＜締め切り抽出処理＞に進み、評価回数が既に「４」以上であれば、サーバー１の記憶装置にあらかじめ記憶されている「残念ながら投票はお一人様４回までとなっています。」などのメッセージをＰＣ２に送信する。
【００２５】
また、評価（投票）する際に会員登録を要求しない場合、すなわちユーザーＩＤやパスワードを要求せず、不特定の者から自由に評価を受け付ける場合に、その評価者が何度目の評価（投票）であるかを判断するには、例えば送信者（評価者）のＰＣのＩＰアドレスを記憶するようにしておけばよい。即ちサーバー１は、送信者（評価者）からアクセスがあった場合、ＩＰパケットのヘッダ部の送信元ＩＰアドレスを参照し、これをサーバー１内の記憶装置に記憶する。そしてこのＩＰアドレスを基にした評価者ファイルを作成し、以後、同一のＩＰアドレスからのアクセスは同一者のアクセスとみなすようにする等すればよい。
なお、ネットワークに接続するたびにそのＩＰアドレスが変動する、いわゆる動的（変動）ＩＰアドレスの場合には、例えば次のように判断すればよい。ＩＰアドレスは通常、３桁の「．」で区切られた数字４組からなり、上位３組がネットワークアドレス、最下位の組がホストアドレスと呼ばれるが、動的ＩＰアドレスにおいて変動するのは、このホストアドレス部分である。よって、上位３組のネットワークアドレス部分で判断し、この部分が同一であれば同一人物による繰り返しのアクセスであるとみなせばよい。
【００２６】
＜ＳＴＥＰ８：締め切り時抽出処理＞
佐藤さんの評価回数が評価許容回数以内（４回以内）であると判断されたならば、次にサーバー１は、この評価がオーディションの締め切り時内であるか否かの判断を行う。評価の締め切り時について具体的には、以下の判断を行なう。
例えば＜ＳＴＥＰ４：組合せ算出処理＞にあるように、エントリーＮＯ.１〜５０の全楽曲５０曲を一人の評価者に対して２曲ずつ提示する場合、その組合せは、全て異なる組合せとした場合、（１，２）、（１，３）・・・（１，５０）、（２，３）、（２，４）、・・・（２，５０）のように、１２２５通り存在する。よって１２２５人に対しては、全て異なる組合せを提示できるが、１２２６人目からは、また最初の組合せに戻って提示されることになる。つまり評価者１２２５人で全ての組合せが一巡し、１２２６人目から二巡目の組合せとなる。そして２４５０人（１２２５×２）で２巡目が終了し、２４５１人目から３巡目に入る。よって締め切り時を、この「何巡目が終了した時点で締め切るか」を決定するのが本ステップの処理である。
【００２７】
以下、この評価が締め切り時以内であるか否かの判断に関して実際のサーバー１の処理について説明する。サーバー１は、図１１に示す「締め切り時データ」を参照する。これは、オーディション対象となる全楽曲数と、提示する組合せが何巡目に達した時に評価を締め切るかが対応付けられて記憶されているデータである。今回の総楽曲数は５０曲であるので、提示される組合せが４巡目終了まで評価可能であることになる。すなわち、１２２５通りで一巡するので、１２２５×４＝４９００より、サーバー１は、サーバー１内に記憶されている評価回数を参照し、現在までの評価回数が４９００回以下であるか否かの判断処理を行う。そして４９０１回以上であると判断した場合、評価を締め切る。
佐藤さんが今１巡目（登録番号９６９）であるとすると、佐藤さんは評価可能であると判断され、次の＜楽曲提示処理＞へと進む。もしも例えば５巡目以上（評価（投票）回数が４９０１回以上）であれば、サーバー１内に記憶されている「残念ながら投票は既に締め切りました」などのメッセージをＰＣ２に送信する。
本実施例においては、この締め切り時データが締め切り時情報としての役割を果たす。
【００２８】
なお、図１１のような全楽曲数との対応データを用いずに、例えば一律３巡目まで評価可能というように一定の数に決めておいても良い。
また、評価の締め切り時を日時（何月何日何時何分）で定めておき、サーバー１内の日時計測手段を参照することで、評価が可能か否かを判断するようにしても良い。
さらに、ある楽曲が所定評価に達した時（例えば評価者からの評価点数の合計が１０００点に到達した時など）に締め切るなどとしてもよい。この場合には、全ての異なる組合せが一巡した時点で、サーバー１は、図８の各楽曲レコードの獲得点数欄を参照し、所定評価に達しているか否かを判断する。
【００２９】
＜ＳＴＥＰ９：楽曲提示処理＞
上述のように、一人の評価者に対しては２曲を提示することが決定し、一人の評価許容回数及び評価締め切り時の制限も満たした場合、楽曲が佐藤さんに対して提示される。具体的には、サーバー１内の記憶装置に、＜ＳＴＥＰ４：提示確率算出処理＞で算出したように、１２２５通りの、重複しない異なる２曲の組合せが記憶されており（図９）、これをサーバー１は評価者の佐藤さんに対して提示する。例えば、サーバー１の記憶装置に記憶されている、重複しない１２２５通りの異なる２曲の組合せの中から任意に選択した組合せを提示し、その後の評価者に対しては、その一旦提示した組合せ以外の組合せの中から任意に選択した組合せを提示するなどである。つまり、一度抽出（選択）して評価者に提示した組合せは重複して提示しないという制限の下で、任意に選択した組合せを評価者に提示するのである。そして、１２２５通り全て提示し終えたならば、また最初から同様の処理を繰り返す。つまり２巡目の提示に入る。このような処理を、＜ＳＴＥＰ６：評価許容回数抽出処理＞で抽出された「４巡目」まで繰り返す。例えば、乱数を利用して、「３」が抽出された場合、佐藤さんに対して３番の組合せの（１，１９）をＰＣ２に送信する（図９）。
また他の提示方法としては、例えば佐藤さんが９６９番目の評価者であるとすれば、サーバー１は、９６９番目の組合せの（１３，４９）をＰＣ２に送信するようにしてもよい（図９）。
【００３０】
さらに他の楽曲提示方法としては、例えば乱数を用いて楽曲の組合せを完全にランダムに決定する方式でもよい。これは、サーバー１に内蔵された既知の乱数発生装置で乱数を発生させ、その数の組合せをエントリーＮＯ.として、評価者に提示する。例えば上記のように、一人の評価者に対しては２曲ずつ提示する場合であれば、サーバー１内の乱数発生装置により、例えば「７」と「２３」という乱数が発生した場合、評価者には、エントリーＮＯ.７とエントリーＮＯ.２３の２曲の楽曲を提示するという方法である。
【００３１】
ここで、この楽曲を提示する際には、例えばエントリーＮＯ.を用いて、（１３，４９）と提示する（評価者のＰＣの画面上に表示させる）など、提示する楽曲名やその楽曲の作成者名など、その楽曲の内容に関する情報は伏せて提示するようにすることが望ましい。これは、例えばその楽曲の作成者が、自分の楽曲に投票してもらうよう友人知人に依頼するなどの、いわゆる身内投票を防止するためである。
また逆に、楽曲の内容に関する情報を伏せずに、候補対象物に関する参考情報欄を設けて、例えば候補者のコメント、写真、プロフィール、楽曲のコンセプト等を積極的に提示するものであっても構わない。
本実施例においては、この楽曲の内容に関する情報が評価対象物に関する情報としての役割を果たす。
なお楽曲を提示する際には、その複製を防止するため、ＳＣＭＳ（Serial Copy Management System）などのいわゆるコピープロテクション技術を施して評価者に提示するのが好ましい。
【００３２】
＜ＳＴＥＰ１０：評価判断処理＞
佐藤さんは、提示された楽曲番号（エントリーＮＯ.）をクリックし、当該楽曲データの送信要求をサーバー１に送信する。この送信要求を受信したサーバー１は、佐藤さんのＰＣにエントリーＮＯ.１３の楽曲データ及びエントリーＮＯ.４９の楽曲データを送信する。佐藤さんはこの楽曲データを受信して試聴する。試聴後、提示された２曲に関しての評価をサーバー１に送信する。評価は、例えば「優れていると思われる方（最も優れていると思われるもの）に投票する」でもよいし、「勝ち」「負け」「引き分け」のうちいずれかを選択するようにしても良い。また「非常に良い」「良い」「普通」「あまり良くない」「良くない」等から選択するようにしてもよい。
【００３３】
また、評価者に対して、例えば１０点満点中その楽曲は何点であると思われるかの点数をつけてもらう方式も考えられる。この方式であれば、優劣の差がはっきりと表れ、後述する順位付けが確かなものとなる。
佐藤さんは、図１２に示すようにエントリーＮＯ.１３の楽曲に対しては１０点満点中８点、エントリーＮＯ.４９の楽曲に対しては１０点満点中２点の点数をつけ、サーバー１に送信した。
これを受信したサーバー１は、佐藤さんに提示した２曲の楽曲（１３，４９）を佐藤さんが十分に試聴した上で評価をしたか否かの判断を行う。
【００３４】
ここで、一般的に楽曲の再生方法には、楽曲データを受信しながら同時に再生を行なういわゆるストリーミング方式と、全ての楽曲データの受信を完了してから再生を開始するいわゆるダウンロード方式とがある。本発明において、楽曲の再生方法はどちらかに限るものではないが、サーバー１は、佐藤さんが楽曲データの全部を完全に試聴した後、評価したか、あるいは一定以上試聴した後、評価したかどうかの判断を行なう。一定以上試聴した後の評価でも有効とするのは、一定以上聞けばその楽曲の良し悪し（優劣）がわかる場合もあるからである。
【００３５】
具体的には、評価者のＰＣ２は、ＰＣ２に内蔵されている時間計測手段により、評価者が楽曲を試聴している時間を計測して記憶し、この試聴時間を評価者による評価点数とともにサーバー１に送信する。サーバー１内には、所定の時間以上試聴したかどうかを判断する視聴時間データが記憶されており（図１３）、この視聴時間データに基づいて、所定の時間以上、楽曲を試聴した上で評価をしたか否を判断する。本実施例においては、佐藤さんが２分以上楽曲を試聴した上で評価をしたかどうかが判断される。そしてサーバー１は、２分以上試聴せずに評価をしたと判断した場合には、その評価は無効であるとみなし、２分以上試聴した上で評価をしたと判断すれば、その評価は有効であるとみなす。なお本実施例において、この視聴時間データが視聴時間情報としての役割を果たす。
【００３６】
サーバー１は、佐藤さんからの評価が無効であれば、サーバー１内に記憶されている「最後まで試聴した上で投票をお願いします。」等のメッセージをＰＣ２に送信する。なお、評価が無効である場合に、以後評価ができないよう、佐藤さんからのアクセスを以後は拒否するようにしてもよい。
佐藤さんからの評価が有効である（所定時間以上試聴した上で評価したものである）と判断した場合には、佐藤さんの「ユーザーＩＤ：Ｕ０１５」に基づいて、図５の評価者ファイルを検索し、佐藤さんのレコードを抽出し、この中の「評価回数０」欄を「評価回数１」に更新し、次の＜点数計算処理＞へと進む。
【００３７】
また、サーバー１内に記憶されている全体の評価（投票）回数を一つカウントして「９６９」に更新する。なお、これは登録番号９６９の佐藤さんが９６９人目の評価者である場合である。つまり、一人の評価者が２回、３回と複数回評価できるため、必ずしも評価者に付される登録番号と全体の評価（投票）回数は一致しないからである。
【００３８】
＜ＳＴＥＰ１１：点数計算処理＞
図１２に示すように、佐藤さんは、エントリーＮＯ.１３の楽曲に対しては８点、エントリーＮＯ.４９の楽曲に対しては２点の点数をつけ、サーバー１に送信した。この場合、サーバー１は、エントリーＮＯ.１３の楽曲レコードの獲得点数を８に更新し、またエントリーＮＯ.４９の楽曲レコードの獲得点数を２に更新する（図８）。
このようにしてサーバー１は、各評価者からの評価を受け付け、各楽曲が獲得した獲得点数を集計処理していく。
【００３９】
なお評価を、例えば「優れていると思われる方（最も優れていると思われるもの）に投票する」としていた場合には、投票がされたものについては所定点数（例えば１点）を獲得したものとして獲得点数欄を更新するようにすれば良い。評価を「勝ち」「負け」「引き分け」のうちいずれかを選択するようにした場合や、「非常に良い」「良い」「普通」「あまり良くない」「良くない」等から選択するようにした場合も同様である。例えば、「非常に良い」・・・５点、「良い」・・・４点、「普通」・・・３点、「あまり良くない」・・・２点、「良くない」・・・１点として計算する等である。
【００４０】
＜ＳＴＥＰ１２：順位付け処理＞
サーバー１は、評価の締め切り時、即ち＜ＳＴＥＰ８：締め切り時抽出処理＞及び図１１に示すように、４巡目が終了する時点まで、＜ＳＴＥＰ１：ユーザー確認処理＞から＜ＳＴＥＰ１１：計算処理＞までの処理を繰り返す。そして評価を締め切った場合、サーバー１は以下のように、順位を決定する処理を行う。
即ちサーバー１は、各楽曲レコードの獲得点数欄を参照し（図８）、獲得点数が多い順に楽曲レコードを並べ替え、最も多くの点数を獲得した楽曲を１位とし、以下２位、３位・・・とする。つまり、獲得点数が多い順にそのまま順位が決定する。
【００４１】
なお、評価の締め切りを日時（何月何日何時何分）を以って定めた場合には、以下のように処理する。
まず、＜ＳＴＥＰ４：組合せ算出処理＞にあるように、全楽曲５０曲を一人の評価者に対して２曲ずつ異なる組合せで提示する場合、１２２５通りの組合せが存在し、これで全ての組合せが一巡する。そして１２２６人目からは２巡目の組合せとなる。よって期間を設けて日時で締め切った場合には、例えば３巡目までは終了し、４巡目の途中で締め切りとなるケースが考えられる。この場合一つの方法としては、３巡目までの獲得点数で計算し、途中で締め切りに達した４巡目の獲得点数は切り捨てることとしてもよい。この場合には例えば、図１４に示す楽曲レコードにおいて、１巡目における提示回数及び獲得点数、２巡目における提示回数及び獲得点数・・・を記憶し、これを基に獲得点数を算出するようにする等すればよい。つまり図１４において、エントリーＮＯ.１の獲得点数を、２４０＋２９５＋２６０により、「７９５点」と算出するという方法である。
【００４２】
また他の方法としては、４巡目に提示された楽曲が、その４巡目に獲得した点数の平均点を算出し、それを３巡目までに獲得した点数に加算するようにしてもよい。つまり図１４に示すように、例えばエントリーＮＯ.１の楽曲が４巡目の途中で締め切りとなった場合、４巡目では評価者に対して７回提示されて５６点を獲得していたとする。この場合、獲得点数の平均は８点であるから、この８点も、１〜３巡目までに獲得した点数に加算し、エントリーＮＯ.１の獲得点数を、２４０＋２９５＋２６０＋８により、「８０３点」と算出するという方法である。
【００４３】
また、＜ＳＴＥＰ９：楽曲提示処理＞において、２曲の組合せを乱数発生装置を用いて完全にランダムで提示するようにした場合には、それぞれの楽曲が得た獲得点数の平均点を算出し、これにより順位付けを行なうようにする。この場合には例えば、図８の楽曲レコードにおいて、「獲得点数」欄の他に「提示回数」欄を設け、これらを参照して平均点を算出すればよい。
【００４４】
このようにして全楽曲の順位付けを行い、この結果をドリームミュージックが運営するホームページ上にアップロードするなどして、一般視聴者の評価（投票）による楽曲オーディションが終了する。
【００４５】
上記実施例においては特定のケースについて説明したが、本発明はこれら特定のケースに限るものではない。例えば、次のようなケースであっても構わない。
（１）上記実施例では、特定のケースについて説明したが、本発明はこれに限るものではない。例えば音楽作品に限るものではなく、映画や俳句、川柳、タレントの人気調査、新商品のパッケージのデザイン調査など、また金融商品や旅行会社が提供する旅行情報といったサービスなど、優劣を決し順位をつけることができるもの全てに対して用いることができる。
（２）データの内容は実施例で説明したデータに限らない。即ち、同様の役割を果たすことができれば、他のどのようなデータであっても構わない。
（３）ハードウェアも実施例で説明したものに限らない。即ち、同様の役割を果たすことができれば、他のどのようなハードウェアであっても構わない。例えば、ＰＣ２の代わりに双方向機能を備えたテレビ受像機を使用して同様の処理をさせてもよい。
（４）処理の内容や手順についても実施例で説明したものに限らない。即ち、同様の役割を果たすことができれば、他のどのような処理内容・処理手順であっても構わない。
（５）上記実施例に登場するデータ（データレコード、ファイル）のデータ（データ項目）は、原則として各々関連づけられて（対応づけられて）記憶装置に記憶されているものとする。図面に表されたものについても同様である。
（６）本発明において、「投票」には「評価」の概念が含まれるものとし、また「評価」には「投票」の概念が含まれるものとする。また「提示」には、「送信」の概念が含まれるものとし、また「送信」には「提示」の概念が含まれるものとする。
【図面の簡単な説明】
【００４６】
【図１】本発明を実現するための装置の概略を表した図である。
【図２】本発明の処理フローを表した図である。
【図３】ログイン画面を表した図である。
【図４】ユーザーファイルを表した図である。
【図５】評価者ファイルを表した図である。
【図６】提示楽曲数データを表した図である。
【図７】提示楽曲数データを表した他の図である。
【図８】楽曲ファイルを表した図である。
【図９】組合せデータを表した図である。
【図１０】評価許容回数データを表した図である。
【図１１】締め切り時データを表した図である。
【図１２】評価送信画面を表した図である。
【図１３】視聴時間データを表した図である。
【図１４】楽曲ファイルを表した図である。
【符号の説明】
【００４７】
１  サーバー
２  ＰＣ（パーソナルコンピュータ）
３  インターネット
１１  表示モニタ
１２  キーボード
１３  マウス
【図１】
2005165889.tif 000003
【図２】
2005165889.tif 000004
【図３】
2005165889.tif 000005
【図４】
2005165889.tif 000006
【図５】
2005165889.tif 000007
【図６】
2005165889.tif 000008
【図７】
2005165889.tif 000009
【図８】
2005165889.tif 000010
【図９】
2005165889.tif 000011
【図１０】
2005165889.tif 000012
【図１１】
2005165889.tif 000013
【図１２】
2005165889.tif 000014
【図１３】
2005165889.tif 000015
【図１４】
2005165889.tif 000016