以下、本発明の一実施の形態を図面を参照しつつ説明する。
図1を用いて、本実施形態の楽曲再生システムの全体構成を説明する。
図1において、楽曲再生システム1は、演奏曲データを用いて演奏曲の再生を行うためのシステムである。この楽曲再生システム1は、カラオケ店舗等のカラオケルームKRにそれぞれに設置された、カラオケ装置100及びリモコン200と、ホストサーバ300と、広告配信サーバ400とを有している。
なお、カラオケ装置100とリモコン200とは、例えば無線又は有線のLocal Area Network(LAN)等のネットワークNW1を介し、互いに情報送受信可能に接続されている。また、カラオケ装置100やリモコン200と、ホストサーバ300と、広告配信サーバ400とは、上記ネットワークNW1と、例えば通信ネットワーク等のネットワークNW2とを介し、互いに情報送受信可能に接続されている。
カラオケ装置100は、演奏曲データを用いて演奏曲の再生サービスを提供する楽曲再生装置である。このカラオケ装置100は、制御部101と、再生手段としての再生部102と、表示部103と、音声出力部104と、操作部105と、通信制御部106と、大容量記憶装置107と備えている。
制御部101は、図示しないCPU及びRAM、ROM等のメモリを備えている。この制御部101は、RAMの一時記憶機能を利用しつつ、ROMや大容量記憶装置107に予め記憶された各種プログラムを実行する。これにより、カラオケ装置100全体の制御を行う。
大容量記憶装置107は、例えばHard Disk Drive(HDD)などから構成される。この大容量記憶装置107には、複数の演奏曲データ、及び、予め広告配信サーバ400より出力された複数の広告情報等の各種情報が記憶されている。演奏曲データには、楽曲データとしてのMusical Instrument Digital Interface(MIDI;登録商標)データ、及び、映像データ等が含まれている。広告情報は、特定の商品等を広告するための動画情報や静止画情報である。
また、この大容量記憶装置107の図示しないテーブル記憶エリアには、ログインテーブル1071(後述の図2参照)、歌唱履歴テーブル1072(後述の図3参照)、ユニットID−歌手IDテーブル1073(後述の図5参照)、及び、ユニット別広告テーブル1074(後述の図6参照)が記憶されている。
なお、この大容量記憶装置107は、各請求項記載の、第2記憶装置、第3記憶装置、及び第4記憶装置に相当する。
再生部102は、上記大容量記憶装置107に記憶された演奏曲データを用いて演奏曲を再生する。またこれと共に、再生部102は、上記大容量記憶装置107に記憶された広告情報を再生する。
表示部103は、例えば液晶ディスプレイなどから構成される。この表示部103は、上記再生部102によって再生された演奏曲や広告情報に係わる動画や静止画の映像を表示する。
音声出力部104は、例えばアンプやスピーカなどから構成される。この音声出力部104は、上記再生部102によって再生された演奏曲や広告情報に係わる音声、及び、図示しないマイクにより入力された当該カラオケ装置100を利用するユーザの歌唱音声等を出力する。
操作部105は、複数のキーやスイッチなどから構成される。ユーザは、この操作部105又は後述のリモコン200の操作部205を用いて、演奏曲に関する選曲操作等の各種操作を行うことができる。
通信制御部106は、リモコン200、ホストサーバ300、広告配信サーバ400との間で、上記ネットワークNW1,NW2を介し行われる情報通信の制御を行う。
リモコン200は、ユーザが演奏曲に関する選曲操作、言い換えれば、演奏曲の予約等の各種操作を行うための操作端末である。このリモコン200は、制御部201と、表示部203と、操作部205と、通信制御部206と、記憶装置207とを備えている。
制御部201は、図示しないCPU及びRAM、ROM等のメモリを備えている。この制御部201は、RAMの一時記憶機能を利用しつつ、ROMや記憶装置207に予め記憶された各種プログラムを実行する。これにより、リモコン200全体の制御を行う。
表示部203は、例えば液晶ディスプレイなどから構成され、各種表示を行う。
操作部205は、複数のキーやスイッチなどから構成される。ユーザは、この操作部205又は上記カラオケ装置100の操作部105を用いて、上記選曲操作等の各種操作を行うことができる。
通信制御部206は、カラオケ装置100、ホストサーバ300、広告配信サーバ400との間で、上記ネットワークNW1,NW2を介し行われる情報通信の制御を行う。
記憶装置207は、例えば不揮発性メモリなどから構成され、各種情報を記憶する。
ホストサーバ300は、制御部301と、通信制御部306と、第1記憶装置としての大容量記憶装置307とを備えている。
制御部301は、図示しないCPU及びRAM、ROM等のメモリを備えている。この制御部301は、RAMの一時記憶機能を利用しつつ、ROMや大容量記憶装置307に予め記憶された各種プログラムを実行する。これにより、ホストサーバ300全体の制御を行う。
通信制御部306は、カラオケ装置100、リモコン200、広告配信サーバ400との間で、上記ネットワークNW2,NW1を介し行われる情報通信の制御を行う。
大容量記憶装置307は、例えばHDDなどから構成される。この大容量記憶装置307の図示しないデータベース記憶エリアには、会員データベース(図示せず)、歌唱履歴データベース(図示せず)、及び、ユーザ別嗜好データベース3071(後述の図4参照)が記憶されている。
会員データベースには、カラオケ装置100による演奏曲の再生サービスに係わる会員として登録されたユーザの会員情報が記憶されている。ユーザの会員情報には、当該ユーザのユーザ識別情報であるユーザID、性別、生年月日等が含まれている。なお、上記会員として登録されたユーザ、言い換えれば、ユーザ識別情報を登録したユーザは、各請求項記載の特定ユーザに相当する。以下適宜、当該ユーザを「登録ユーザ」と称する。
広告配信サーバ400は、複数の広告情報を格納した広告データベース(図示せず)を備えている。この広告配信サーバ400は、上記広告データベースに格納された広告情報を、上記ネットワークNW2,NW1を介しカラオケ装置100等へ出力する。
図2に、上記ログインテーブル1071の記憶内容の一例を示す。
図2に示すように、ログインテーブル1071には、リモコン200の表示部203における登録ユーザ固有の閲覧画面、すなわちいわゆるマイページにアクセス可能となった登録ユーザのユーザID、言い換えればマイページにログインしている登録ユーザのユーザIDが記憶されている。
本実施形態では、登録ユーザによる所定の操作としてのリモコン200の操作部205を介した上記マイページへのログイン操作に基づき、ホストサーバ300により当該登録ユーザが認証されると、当該登録ユーザのユーザIDがログインテーブル1071に記憶されるようになっている。なお、所定の操作としては、上記のようなログイン操作に限られず、他の操作であってもよい。
図3に、上記歌唱履歴テーブル1072の記憶内容の一例を示す。
図3に示すように、歌唱履歴テーブル1072には、上記マイページにログインしている登録ユーザの演奏曲に関する選曲操作に対応した、当該登録ユーザの歌唱履歴情報が記憶されている。
登録ユーザの歌唱履歴情報には、上記選曲操作を行った登録ユーザのユーザIDと、選曲された演奏曲の曲識別情報である曲IDと、選曲された演奏曲の歌手識別情報である歌手IDと、選曲された演奏曲が歌唱された時刻情報である歌唱日時と、が含まれている。
なお、登録ユーザの歌唱履歴情報としては、上記に限られず、例えば選曲された演奏曲の曲ジャンル識別情報であるジャンルID等、上記以外の情報を含めるようにしてもよい。上記曲ID、歌手ID、及びジャンルIDは、それぞれ、各請求項記載の歌唱対象識別情報に相当する。
本実施形態では、ユーザがカラオケ装置100による演奏曲の再生サービスの利用を終了すると、その時点で歌唱履歴テーブル1072に記憶された歌唱履歴情報がホストサーバ300に出力され、当該ホストサーバ300の上記歌唱履歴データベースに記憶される。またこれと共に、その時点で歌唱履歴テーブル1072に記憶された歌唱履歴情報が消去されるようになっている。
図4に、上記ユーザ別嗜好データベース3071の記憶内容の一例を示す。
図4に示すように、ユーザ別嗜好データベース3071には、例えばホストサーバ300の制御部301によって予め実行されたクラスタリングによって、複数の登録ユーザのユーザIDと、互いに嗜好の異なる複数の(この例では100個の)ユニットのユニット識別情報であるユニットIDと、が対応付けられたユーザ分類情報が記憶されている。
クラスタリングとは、例えば公知のK−means法やSelf Organizing Maps(SOM)法などのクラスタリング手法を用いて、複数のデータを外的基準なしに自動的に分類する手法、又は、そのアルゴリズムである。
本実施形態では、上記ホストサーバ300の歌唱履歴データベースに記憶された複数の登録ユーザの歌唱履歴情報に基づき、適宜のタイミングでクラスタリングが実行される。そして、そのクラスタリング結果に対応し、各登録ユーザのユーザIDに対して、上記100個のユニットのいずれかのユニットのユニットID、すなわち当該登録ユーザの嗜好に対応したユニットのユニットIDがそれぞれ対応付けられ、ユーザ分類情報として、ユーザ別嗜好データベース3071に記憶されるようになっている。
なお、ユーザ別嗜好データベース3071に記憶されたユーザ分類情報において、登録ユーザのユーザIDに対応付けられたユニットIDは、各請求項記載の第1ユニット識別情報に相当する。以下適宜、当該ユニットIDを「第1ユニットID」と称する。すなわち、この第1ユニットIDは、登録ユーザの本来の嗜好に対応したユニットのユニットIDを表している。
また、上記100個のユニットIDの中には、予め定められた所定のユニット識別情報として、少なくとも1個の所定ユニットIDが含まれている。所定ユニットIDは、他の人間に対し自分の嗜好を隠したい場合がありうるユニット、例えばアニメ系の嗜好やアイドル系の嗜好などに対応したユニット、のユニットIDを表している。
図5に、上記ユニットID−歌手IDテーブル1073の記憶内容の一例を示す。
図5に示すように、ユニットID−歌手IDテーブル1073には、複数の歌唱対象識別情報(この例では複数の歌手ID)と、上記100個のユニットIDと、が対応付けられた歌唱対象分類情報が予め記憶されている。なお、上記歌唱対象分類情報における複数の歌唱対象識別情報としては、複数の歌手IDに限られず、複数の曲IDや複数のジャンルIDなどであってもよい。
当該歌唱対象分類情報においては、各ユニットIDに対して、n個の歌手IDがそれぞれ対応付けられている。なお、nの値は1以上の整数である。具体的には、各ユニットIDに対して、当該ユニットIDに係わるユニットに属する複数の登録ユーザの間で、演奏曲が多く歌唱された上位n人の歌手に係る歌手ID、言い換えれば、人気の高い上位n人の歌手に係る歌手IDがそれぞれ対応付けられている。なお、各ユニットIDに対して対応付けられるn個の歌手IDとしては、上記のように演奏曲が多く歌唱された歌手に係る歌手IDに限られない。
また、以下適宜、各ユニットIDに対して対応付けられたn個の歌手IDを、上記人気の高い歌手に係る歌手IDから順に、「第1歌手ID」「第2歌手ID」「第3歌手ID」・・・「第n歌手ID」と称する。すなわち、第1歌手IDは、ユニットに属する複数の登録ユーザの間で最も人気のある歌手に係る歌手IDである。第2歌手IDは、ユニットに属する複数の登録ユーザの間で2番目に人気のある歌手に係る歌手IDである。第3歌手IDは、ユニットに属する複数の登録ユーザの間で3番目に人気のある歌手に係る歌手IDである。第n歌手IDは、ユニットに属する複数の登録ユーザの間でn番目に人気のある歌手に係る歌手IDである。
図5に示す例では、例えば、ユニットID「1」に対しては、第1歌手IDとして歌手ID「368」、第2歌手IDとして歌手ID「1725」、第3歌手IDとして歌手ID「8790」、第4歌手IDとして歌手ID「3315」、・・・、第n歌手IDとして歌手ID「41858」が対応付けられている。説明は省略するが、上記以外のユニットID「2」〜ユニットID「100」に対しても、それぞれ同様に、n個の歌手IDが対応付けられている。
図6に、上記ユニット別広告テーブル1074の記憶内容の一例を示す。
図6に示すように、ユニット別広告テーブル1074には、上記100個のユニットのユニットIDと、当該ユニットに属する登録ユーザの嗜好に対応した広告情報として予め定められた広告情報の広告識別情報である広告IDと、が対応付けられて記憶されている。
上記構成の本実施形態の最大の特徴は、登録ユーザの上記ログイン操作に基づいて取得された当該登録ユーザのユーザIDを用いて、上記ユーザ別嗜好データベース3071に記憶されたユーザ分類情報を適用することで、当該登録ユーザに対応する第1ユニットIDを取得し、上記歌唱履歴テーブル1071に記憶された、演奏曲に関する登録ユーザの選曲操作に対応した、当該登録ユーザの歌唱履歴情報に含まれる歌手IDと、当該登録ユーザに関して取得された第1ユニットIDとの整合性を判定することにある。以下、その詳細を説明する。
図7を用いて、カラオケ装置100の制御部101が実行する、広告情報の決定に関する処理に関する制御手順を説明する。
図7において、例えば楽曲再生システム1の管理者によりカラオケ装置100の電源がオンにされることによって、図中「START」位置で表されるように、このフローが開始される。
まずステップS10で、制御部101は、上記ログインテーブル1071(図2参照)を用いて、上記マイページにログインしている登録ユーザが存在するかどうかを判定する。ログインテーブル1071にユーザIDが記憶されていない場合には、マイページにログインしている登録ユーザが存在しないとみなされ、ステップS10の判定が満たされず、ループして待機する。一方、ログインテーブル1071にユーザIDが記憶されている場合には、マイページにログインしている登録ユーザが存在するとみなされ、ステップS10の判定が満たされて、ステップS20に移る。
ステップS20では、制御部101は、上記マイページにログインしている少なくとも1人の登録ユーザのユーザID、すなわち、上記ログインテーブル1071に記憶された少なくとも1つのユーザIDを取得する。なお、マイページに複数の登録ユーザがログインしている場合には、このステップS20では、ログインテーブル1071に記憶された当該複数の登録ユーザのユーザIDが取得される。これは実質的には、登録ユーザの上記ログイン操作に基づいて当該登録ユーザのユーザIDを取得することに相当する。
その後、ステップS30で、制御部101は、ホストサーバ300の上記ユーザ別嗜好データベース3071(図4参照)にアクセスする。そして、ユーザ別嗜好データベース3071に記憶されたユーザ分類情報において、上記ステップS20で取得された各ユーザIDに対応付けられたユニットIDすなわち第1ユニットIDをそれぞれ取得する。これは実質的には、上記ステップS20で取得された登録ユーザのユーザIDに基づき、ユーザ別嗜好データベース3071に記憶されたユーザ分類情報に応じて、当該登録ユーザに対応する第1ユニットIDを取得することに相当する。すなわち、このステップS30の手順が、各請求項記載のユニット情報取得手段として機能する。
そして、ステップS40に移り、制御部101は、上記ステップS30で取得された各第1ユニットIDが、前述の所定ユニットIDに該当するかどうかをそれぞれ判別する。
その後、ステップS50で、制御部101は、上記ステップS40での判別結果に基づき、上記ステップS30で取得された第1ユニットIDの中に、所定ユニットIDに該当する第1ユニットIDが含まれているかどうかを判定する。これは言い換えれば、上記マイページにログインしている登録ユーザの中に、他の人間に対し自分の嗜好を隠したい場合がありうるユニットに属する登録ユーザが存在するかどうかを判定することに相当する。
ステップS50において、上記ステップS30で取得された第1ユニットIDの中に、所定ユニットIDに該当する第1ユニットIDが含まれていない場合がある。この場合には、マイページにログインしている登録ユーザの中に、他の人間に対し自分の嗜好を隠したい場合がありうるユニットに属する登録ユーザが存在しないとみなされ、ステップS50の判定が満たされず、ステップS60に移る。
ステップS60では、制御部101は、上記ステップS30で取得された各第1ユニットIDを、広告対象とするユニットIDとしてそれぞれ決定する。その後、後述のステップS90に移る。
一方、ステップS50において、上記ステップS30で取得された第1ユニットIDの中に、所定ユニットIDに該当する第1ユニットIDが含まれていた場合がある。この場合には、マイページにログインしている登録ユーザの中に、他の人間に対し自分の嗜好を隠したい場合がありうるユニットに属する登録ユーザが存在するとみなされ、ステップS50の判定が満たされて、ステップS70に移る。
ステップS70では、制御部101は、上記ステップS30で取得された第1ユニットIDのうち、上記ステップS40で所定ユニットIDに該当しないと判別された各第1ユニットIDを、広告対象とするユニットIDとしてそれぞれ決定する。
その後、ステップS80で、制御部101は、上記ステップS40で第1ユニットIDが所定ユニットIDに該当すると判別された、言い換えれば、他の人間に対し自分の嗜好を隠したい場合がありうるユニットに属する登録ユーザに関して、上記ステップS20で取得されたユーザIDを、例えば当該制御部101のRAM等のメモリに記憶させる。
そして、ステップS100に移り、制御部101は、所定の歌唱傾向判定処理を実行する。なお、このステップS100の詳細内容については、後述の図8で説明する。
その後、ステップS90で、制御部101は、上記ログインテーブル1071を用いて、上記マイページからすべての登録ユーザがログアウトしているかどうかを判定する。ログインテーブル1071にユーザIDが記憶されている場合には、マイページからすべての登録ユーザがログアウトしていないとみなされ、ステップS90の判定が満たされず、ステップS20に戻り同様の手順を繰り返す。一方、ログインテーブル1071にユーザIDが記憶されていない場合には、マイページからすべての登録ユーザがログアウトしているとみなされ、ステップS90の判定が満たされて、このフローを終了する。
なお、上記において、ステップS40及びステップS50の手順が、各請求項記載の第2判定手段として機能する。
図8を用いて、上記図7のステップS100の詳細手順を説明する。
図8において、まずステップS105で、制御部101は、上記図7のステップS80でメモリに記憶されたユーザIDの中から、まだ取得していないユーザIDを取得する。
その後、ステップS110で、制御部101は、上記歌唱履歴テーブル1072(図3参照)に、上記ステップS105でユーザIDが取得された登録ユーザの歌唱履歴情報が記憶されているかどうかを判定する。歌唱履歴テーブル1072に、上記ステップS105で取得されたユーザIDを含む歌唱履歴情報が記憶されていない場合には、歌唱履歴テーブル1072に、上記ステップS105でユーザIDが取得された登録ユーザの歌唱履歴情報が記憶されていないとみなされ、ステップS110の判定が満たされず、後述のステップS190に移る。一方、歌唱履歴テーブル1072に、上記ステップS105で取得されたユーザIDを含む歌唱履歴情報が記憶されている場合には、歌唱履歴テーブル1072に、上記ステップS105でユーザIDが取得された登録ユーザの歌唱履歴情報が記憶されているとみなされ、ステップS110の判定が満たされて、ステップS120に移る。
ステップS120では、制御部101は、上記歌唱履歴テーブル1072から、上記ステップS105でユーザIDが取得された登録ユーザの歌唱履歴情報に含まれる歌手IDを取得する。なお、歌唱履歴テーブル1072に、上記ステップS105でユーザIDが取得された登録ユーザの歌唱履歴情報が複数レコード記憶されている場合には、このステップS120では、歌唱履歴テーブル1072に記憶された当該登録ユーザの複数の歌唱履歴情報に含まれる歌手IDがそれぞれ取得される。なお、レコードとは、テーブルを構成するデータの単位である。
そして、ステップS130に移り、制御部101は、上記ユニットID−歌手IDテーブル1073(図5参照)に記憶された歌唱対象分類情報における複数の歌手IDのうち、各所定ユニットIDに対して対応付けられた前述の第1歌手IDをそれぞれ取得する。すなわち、このステップS130では、上記他の人間に対し自分の嗜好を隠したい場合がありうる各ユニットにおいて、最も人気の高い歌手に係る歌手ID、言い換えれば、当該ユニットを最も特徴付ける歌手に係る歌手ID、がそれぞれ取得される。
その後、ステップS140で、制御部101は、上記ステップS130で取得された第1歌手IDの中に、上記ステップS120で取得された歌手IDのいずれかと一致する第1歌手IDが含まれているかどうかを判定する。これは言い換えれば、上記ステップS105でユーザIDが取得された、上記他の人間に対し自分の嗜好を隠したい場合がありうるユニットに分類される登録ユーザが、当該登録ユーザの嗜好を隠す必要のない他の人間と共に来場しているかどうか、あるいは、1人で来場しているかどうか、を判定することに相当する。
ステップS140において、上記ステップS130で取得された第1歌手IDの中に、上記ステップS120で取得された歌手IDのいずれかと一致する第1歌手IDがある場合がある。この場合には、上記他の人間に対し自分の嗜好を隠したい場合がありうるユニットに分類される登録ユーザが、当該登録ユーザの嗜好を隠す必要のない他の人間と共に来場している、あるいは、1人で来場している、とみなされ、ステップS140の判定が満たされて、ステップS150に移る。
ステップS150では、制御部101は、上記図7のステップS30で取得された第1ユニットIDのうち、上記ステップS105でユーザIDが取得された登録ユーザに関して取得された第1ユニットIDを、広告対象とするユニットIDとして決定する。その後、後述のステップS190に移る。
一方、ステップS140において、上記ステップS130で取得された第1歌手IDの中に、上記ステップS120で取得された歌手IDのいずれかと一致する第1歌手IDがなかった場合がある。この場合には、上記他の人間に対し自分の嗜好を隠したい場合がありうるユニットに分類される登録ユーザが、他の人間に対し自分の嗜好を隠したい可能性があるとみなされ、ステップS140の判定が満たされず、ステップS160に移る。
ステップS160では、制御部101は、上記歌唱履歴テーブル1072に、上記ステップS105でユーザIDが取得された登録ユーザの歌唱履歴情報が、歌唱傾向判定を行うために必要なレコード数として予め定められたレコード数以上、この例では3レコード以上記憶されているかどうかを判定する。歌唱履歴テーブル1072に、上記ステップS105でユーザIDが取得された登録ユーザの歌唱履歴情報が、3レコード以上記憶されていない場合には、ステップS160の判定が満たされず、後述のステップS190に移る。一方、歌唱履歴テーブル1072に、上記ステップS105でユーザIDが取得された登録ユーザの歌唱履歴情報が、3レコード以上記憶されている場合には、ステップS160の判定が満たされて、ステップS200に移る。
ステップS200では、制御部101は、上記100個のユニットIDの中から、上記ステップS105でユーザIDが取得された登録ユーザに対応付けるユニットIDを決定するユニット情報決定処理を実行する。なお、このステップS200の詳細内容については、後述の図9で説明する。また、このステップS200において、上記ステップS105でユーザIDが取得された登録ユーザに対応付けるユニットIDとして決定されるユニットIDは、各請求項記載の第2ユニット識別情報に相当する。以下適宜、当該ユニットIDを「第2ユニットID」と称する。なお、この第2ユニットIDは、後述のように、登録ユーザの今回の選曲操作に対応したユニットのユニットIDを表している。
そして、ステップS170に移り、制御部101は、上記ステップS105でユーザIDが取得された登録ユーザに関して上記図7のステップS30で取得された第1ユニットIDと、当該登録ユーザに関して上記ステップS200で決定された第2ユニットIDとが、一致するかどうかを判定する。これは実質的には、上記歌唱履歴テーブル1072に記憶された、演奏曲に関する登録ユーザの選曲操作に対応した登録ユーザの歌唱履歴情報のうち、上記ステップS105でユーザIDが取得された登録ユーザの歌唱履歴情報に含まれる歌手IDと、当該登録ユーザに関して上記図7のステップS30で取得された第1ユニットIDとの整合性を判定することに相当する。言い換えれば、当該登録ユーザの本来の嗜好と、当該登録ユーザの今回の選曲操作との整合性を判定するに相当する。さらに言い換えれば、当該登録ユーザが、当該登録ユーザの嗜好を隠す必要のない他の人間と共に来場しているかどうか、あるいは、1人で来場しているかどうか、を判定することに相当する。すなわち、このステップS170の手順が、各請求項記載の第1判定手段として機能する。
ステップS170において、上記ステップS105でユーザIDが取得された登録ユーザに係わる第1ユニットIDと、当該登録ユーザに係わる第2ユニットIDとが一致する場合がある。この場合には、当該登録ユーザの歌唱履歴情報に含まれる歌手IDと、当該登録ユーザに係わる第1ユニットIDとの整合性がとれている、言い換えれば、当該登録ユーザの本来の嗜好と、当該登録ユーザの今回の選曲操作との整合性がとれている、さらに言い換えれば、当該登録ユーザが、当該登録ユーザの嗜好を隠す必要のない他の人間と共に来場している、あるいは、1人で来場している、とみなされ、ステップS170の判定が満たされて、ステップS180に移る。
ステップS180では、制御部101は、上記図7のステップS30で取得された第1ユニットIDのうち、上記ステップS105でユーザIDが取得された所定ユニットに属する登録ユーザに関して取得された第1ユニットIDを、広告対象とするユニットIDとして決定する。又は、当該第1ユニットIDと一致する、当該登録ユーザに関して上記ステップS200で決定された第2ユニットIDを、広告対象とするユニットIDとして決定するようにしてもよい。その後、ステップS190に移る。
一方、ステップS170において、上記ステップS105でユーザIDが取得された登録ユーザに係わる第1ユニットIDと、当該登録ユーザに係わる第2ユニットIDとが一致しない場合がある。この場合には、当該登録ユーザの歌唱履歴情報に含まれる歌手IDと、当該登録ユーザに係わる第1ユニットIDとの整合性がとれていない、言い換えれば、当該登録ユーザの本来の嗜好と、当該登録ユーザの今回の選曲操作との整合性がとれていない、さらに言い換えれば、当該登録ユーザが、他の人間に対し自分の嗜好を隠したい可能性がある、とみなされ、ステップS170の判定が満たされず、ステップS190に移る。すなわち、ステップS170の判定が満たされなかった場合には、上記ステップS105でユーザIDが取得された登録ユーザに関して上記図7のステップS30で取得された第1ユニットIDと、当該登録ユーザに関して上記ステップS200で決定された第2ユニットIDとは、広告対象とするユニットIDとして決定されない。
ステップS190では、制御部101は、上記図7のステップS80でメモリに記憶されたユーザIDの中から、上記ステップS105ですべてのユーザIDが取得されているかどうかを判定する。まだ上記ステップS105ですべてのユーザIDが取得されていない場合には、ステップS190の判定が満たされず、ステップS105に戻り同様の手順を繰り返す。一方、既に上記ステップS105ですべてのユーザIDが取得されている場合には、ステップS190の判定が満たされて、このルーチンを終了する。
図9を用いて、上記図8のステップS200の詳細手順を説明する。
図9において、まずステップS210で、制御部101は、上記歌唱履歴テーブル1072から、上記図7のステップS105でユーザIDが取得された登録ユーザの複数の歌唱履歴情報に含まれる歌手IDをそれぞれ取得する。
その後、ステップS220で、制御部101は、上記100個のユニットIDのいずれかに対応する変数Jの値を1に設定する。
そして、ステップS230に移り、制御部101は、上記ユニットID−歌手IDテーブル1073(図5参照)に記憶された歌唱対象分類情報における複数の歌手IDのうち、この時点での変数Jの値に対応するユニットIDに対して対応付けられた、前述のn個の第1歌手ID〜第n歌手IDをそれぞれ取得する。すなわち、このステップS230では、この時点での変数Jの値に対応するユニットIDに係わるユニットにおいて、人気の高い上位n人の歌手に係る歌手ID、言い換えれば、当該ユニットを特徴付けるn人の歌手に係る歌手IDが取得される。
その後、ステップS240で、制御部101は、上記ステップS230で取得されたn個の第1歌手ID〜第n歌手IDの中に、上記ステップS210で取得された複数の歌手IDがいくつ含まれているかをカウントする。そして、この時点での変数Jの値に対応するユニットIDに係わるカウント値をN(J)として保持する。
そして、ステップS250に移り、制御部101は、変数Jの値がユニットIDの数Jmax(この例ではJmax=100)と等しくなったかどうかを判定する。J<Jmaxである場合には、ステップS250の判定が満たされず、ステップS260に移る。ステップS260では、制御部101は、変数Jの値に1を加える。その後、上記ステップS230に戻り同様の手順を繰り返す。そして、J=Jmaxとなった場合には、ステップS250の判定が満たされて、ステップS270に移る。
ステップS270では、制御部101は、上記ステップS240でのカウント値C(J)が、上記100個のユニットIDのすべてにおいて0となったかどうかを判定する。上記ステップS240でのカウント値C(J)が、上記100個のユニットIDのいずれかにおいて0となっていなかった場合には、ステップS270の判定が満たされず、ステップS280に移る。
ステップS280では、制御部101は、上記ステップS240でのカウント値C(J)が0とならなかったユニットIDのうち、カウント値C(J)が最大となるユニットIDを、上記図8のステップS105でユーザIDが取得された登録ユーザの今回の選曲操作に対応するユニットのユニットIDとして選択する。なお、カウント値C(J)が最大となるユニットIDが複数ある場合には、それらユニットIDのうち、人気の高い歌手に係る歌手ID、すなわち、nの値が小さい歌手IDがより多くカウントされていたユニットIDを、上記図8のステップS105でユーザIDが取得された登録ユーザの今回の選曲操作に対応するユニットのユニットIDとして選択するようにしてもよい。
その後、ステップS290で、制御部101は、上記100個のユニットIDのうち、上記ステップS280で選択されたユニットIDを、上記図8のステップS105でユーザIDが取得された登録ユーザに対応付けるユニットIDすなわち第2ユニットIDとして決定する。すなわち、この第2ユニットIDは、登録ユーザの今回の選曲操作に対応したユニットのユニットIDを表している。その後、このルーチンを終了する。
一方、ステップS270において、上記ステップS240でのカウント値C(J)が、上記100個のユニットIDのすべてにおいて0となっていた場合には、ステップS270の判定が満たされて、ステップS295に移る。
ステップS295では、制御部101は、上記100個のユニットIDのいずれにも該当しない識別情報である「XXX」を、上記図8のステップS105でユーザIDが取得された登録ユーザに対応付けるユニットIDすなわち第2ユニットIDとして決定する。これは実質的には、当該登録ユーザの今回の選曲操作に対応するユニットがなかったため、当該登録ユーザに対して、いずれのユニットIDも対応付けないことを決定することに相当する。その後、このルーチンを終了する。
以上説明したように、ステップS200では、制御部101は、上記歌唱履歴テーブル1071に記憶された、上記図8のステップS105でユーザIDが取得された登録ユーザの歌唱履歴情報に含まれる歌手IDに基づき、上記ユニットID−歌手IDテーブル1073に記憶された歌唱対象分類情報を応じて、上記100個のユニットIDの中から、当該登録ユーザに対応付ける第2ユニットIDを決定する。したがって、このステップS200のすべての手順、すなわち、ステップS210〜ステップS290及びステップS295の手順が、各請求項記載のユニット情報決定手段として機能する。
図10を用いて、カラオケ装置100の制御部101が実行する、広告情報の再生に関する制御手順を説明する。
図10において、例えば楽曲再生システム1の管理者によりカラオケ装置100の電源がオンにされることによって、図中「START」位置で表されるように、このフローが開始される。
まずステップS510で、制御部101は、上記図7のステップS60、又は上記図7のステップS70、又は上記図8のステップS150、又は上記図8のステップS180において広告対象とするユニットIDとして決定されたユニットIDを取得する。なお、広告対象とするユニットIDとして決定されたユニットIDが複数ある場合には、このステップS510では、当該決定された複数のユニットがそれぞれ取得される。
その後、ステップS520で、制御部101は、上記ステップS510で取得されたユニットIDのうち、いずれか1つのユニットIDを選定する。
そして、ステップS530に移り、制御部101は、上記ユニット別広告テーブル(図6参照)から、上記ステップS520で取得されたユニットIDに対応付けられた広告IDを取得する。その後、その取得した広告IDに対応する広告情報を、次に再生部102に再生させる広告情報として決定する。
その後、ステップS540で、制御部101は、1つの演奏曲の再生終了後に、次の演奏曲の予約が行われていない状態、すなわち、いわゆる曲間となっているかどうかを判定する。曲間となるまでは、ステップS540の判定が満たされず、ループして待機する。そして、曲間となったら、ステップS540の判定が満たされて、ステップS550に移る。
ステップS550では、制御部101は、大容量記憶装置107から、上記ステップS530で決定された広告情報を読み出す。
そして、ステップS560に移り、制御部101は、演奏曲の予約が行われるまでの間に、すなわち、次の演奏曲の再生開始までの間に、上記ステップS550で読み出された広告情報、すなわち、広告対象とするユニットIDに対応付けられた広告情報を再生するように、再生部102を制御する。これにより、当該広告情報に係わる映像が表示部103で表示され、当該広告情報に係わる音声が音声出力部104から出力される。なお、広告対象とするユニットIDに対応付けられた広告情報を再生するように再生部102を制御する、すなわち、当該広告情報を再生部102により再生させることは、実質的には、広告対象とするユニットIDに対応付けられた広告情報を出力することに相当する。すなわち、このステップS560の手順が、各請求項記載の広告情報出力手段として機能する。
具体的には、上記図7のステップS50の判定が満たされなかった場合には、上記図7のステップS30で取得された第1ユニットIDが、広告対象とするユニットIDに決定されるので、制御部101は、当該第1ユニットIDに対応付けられた広告情報を再生部102により再生させる。一方、上記ステップS50の判定が満たされた場合には、上記図7のステップS40で所定ユニットIDに該当しないと判別された第1ユニットIDが、広告対象とするユニットIDに決定されるので、制御部101は、当該第1ユニットIDに対応付けられた広告情報を再生部102により再生させる。
また、上記図8のステップS140の判定が満たされた場合には、上記図8のステップS105でユーザIDが取得された登録ユーザに係わる第1ユニットIDが、広告対象とするユニットIDに決定されるので、制御部101は、当該第1ユニットIDに対応付けられた広告情報を再生部102により再生させる。
また、上記図8のステップS170の判定が満たされた場合には、上記図8のステップS105でユーザIDが取得された登録ユーザに係わる第1又は第2ユニットIDが、広告対象とするユニットIDに決定されるので、制御部101は、当該第1又は第2ユニットIDに対応付けられた広告情報を再生部102により再生させる。一方、上記ステップS170の判定が満たされなかった場合には、上記ステップS105でユーザIDが取得された登録ユーザに係わる第1及び第2ユニットIDは、それぞれ、広告対象とするユニットIDに決定されないので、制御部101は、当該第1及び第2ユニットIDにそれぞれ対応付けられた広告情報を再生しないように、再生部102を制御する。なお、当該第1及び第2ユニットIDにそれぞれ対応付けられた広告情報を再生しないように再生部102を制御する、すなわち、当該第1及び第2ユニットIDにそれぞれ対応付けられた広告情報を再生部102により再生させないことは、実質的には、当該第1及び第2ユニットIDにそれぞれ対応付けられた広告情報の出力を禁止することに相当する。
なお、広告情報の再生中に、演奏曲の予約が行われた場合には、広告情報の再生が一時停止され、当該演奏曲の再生が開始される。そして、再び、曲間となったら、一時停止中の広告情報の再生が再開される。そして、1つの広告情報の再生が終了したら、ステップS570に移る。
ステップS570では、制御部101は、所定の終了操作、例えばカラオケ装置100の電源オフ、が行われたかどうかを判定する。終了操作が行われていない場合には、ステップS570の判定が満たされず、上記ステップS510に戻り同様の手順を繰り返す。そして、終了操作が行われたら、ステップS570の判定が満たされて、このフローを終了する。
以上説明したように、本実施形態においては、カラオケ装置100の再生サービスを受けるために登録ユーザが前述のログイン操作を行うと、その操作に基づいて当該登録ユーザのユーザIDが取得される(図7のステップS20を参照)。そして、制御部101が、そのユーザIDを用いて、ホストサーバ300のユーザ別嗜好データベース3071(図4を参照)にアクセスし、ユーザ別嗜好データベース3071に記憶されたユーザ分類情報を適用することで、当該登録ユーザに係わる第1ユニットIDを取得する(図7のステップS30を参照)。
ここで、一般に、ユーザが、演奏曲データを用いた演奏曲の再生サービスを受ける場合、ひとりで来場する場合もあるが、他の人間と連れ立って複数名で来場する場合もある。通常、ユーザが選曲して歌唱する演奏曲の名前や種類等により、ユーザの嗜好を概ね推定することができる。このため、連れ立って利用する者の顔ぶれによっては、ユーザが、本来の歌唱傾向とは異なる、すなわち、ユーザ本来の嗜好とは異なる演奏曲を選曲して歌唱する可能性もある。そこで、本実施形態においては、登録ユーザが選曲操作を行った場合に、制御部101が、前述のようにして取得され当該登録ユーザの本来の嗜好に対応した第1ユニットIDと、上記歌唱履歴テーブル1072(図3を参照)に記憶された、当該特定ユーザの選曲操作の操作内容に対応した歌唱履歴情報に含まれる歌手IDとの整合性を判定する(図8のステップS170を参照)。
これにより、上記ステップS170の判定が満たされて、整合がとれていると判定された場合には、当該登録ユーザがひとりで来場しているか、当該登録ユーザの嗜好を隠す必要のない他の人間とともに来場している、とみなすことができる。この結果、この場合には、当該登録ユーザの本来の嗜好に合致した種々のサービス、例えば上記第1ユニットIDに合致した広告や、おすすめ選曲情報や、おすすめ飲食物情報等の提供を行うことができる。すなわち、自分の嗜好を隠さなくてもよいという、上記登録ユーザの意向に沿ったサービス内容とすることができる。
一方、上記ステップS170の判定が満たされず、整合がとれていないと判定された場合には、上記登録ユーザが、当該登録ユーザの嗜好を隠したい他の人間とともに来場している、とみなすことができる。この結果、この場合には、当該登録ユーザの本来の嗜好に合致した種々のサービスの提供を中止し、自分の嗜好を隠したいという、上記登録ユーザの意向に沿ったサービス内容とすることができる。
また、本実施形態では特に、カラオケ装置100の再生サービスを受けるために登録ユーザが演奏曲の選曲操作を行うと、その操作内容に対応した歌唱履歴情報が、上記歌唱履歴テーブル1072に記憶される。制御部101は、上記のようにして歌唱履歴テーブル1072に記憶された登録ユーザの歌唱履歴情報に含まれる歌手IDに、上記ユニットID−歌手IDテーブル1073(図5を参照)に記憶された前述の歌唱対象分類情報を適用することで、当該登録ユーザに対応付けられる第2ユニットIDを決定することができる(図9を参照)。これにより、制御部101は、上記登録ユーザに関して取得された第1ユニットIDと、上記のようにして決定された当該登録ユーザに係わる第2ユニットIDとが一致するかどうかを判定することで、当該登録ユーザの本来の嗜好と、当該登録ユーザの今回の選曲操作との整合性を判定することができる。
以上のようにして、本実施形態においては、登録ユーザの今回の選曲操作に対応するユニットのユニットIDを決定し、当該ユニットIDと当該登録ユーザの本来の嗜好に対応したユニットのユニットIDとを比較する。これにより、上記登録ユーザの意向を高精度に検出することができるので、当該意向に沿ったサービス内容を確実に実現することができる。
また、本実施形態においては、制御部101は、広告対象とするユニットIDに対応付けられた広告情報を再生部102により再生させる。(図10のステップS560を参照)。一方、ユーザの嗜好がどのようなものであるかにより、相手が誰であってもユーザが自分の嗜好を特に隠さなくてもよい場合があったり、逆に、たいていの相手にはユーザが自分の嗜好を隠したい場合があったりする。ユーザが自分の嗜好を隠したい場合に、当該嗜好に対応した広告情報を出力すると、広告を見た他の人間によりユーザの嗜好が推定できる場合があり、好ましくない。
そこで本実施形態では特に、制御部101は、上記のようにして取得された登録ユーザに係わる第1ユニットIDが前述の所定ユニットID、すなわち、上記のように他の人間に対し隠したい場合がありうるユニットのユニットIDであるかどうかを判定する(図7のステップS40及びステップS50を参照)。当該登録ユーザに係わる第1ユニットIDが所定ユニットIDであった場合には、上記のように当該登録ユーザが他の人間に対し自分の嗜好を隠したい可能性があることから、制御部101は、当該登録ユーザに係わる第1ユニットIDと第2ユニットIDとが一致するかどうかの判定を行う。第1ユニットIDと第2ユニットIDとが一致した場合には、上記ステップS170の判定が満たされて、当該登録ユーザが、1人で来場しているか、当該登録ユーザの嗜好を隠す必要のない他の人間とともに来場している、とみなすことができる。これにより、制御部101は、当該一致した第1又は第2ユニットIDに対応付けられた広告情報を再生部102により再生させる。これにより、上記登録ユーザの意向に沿った形で、当該登録ユーザにとって有益な広告を効果的に提供することができる。
ここで、登録ユーザに係わる第1ユニットIDと第2ユニットIDとが一致しない場合には、上記図8のステップS170の判定が満たされないため、上記登録ユーザが、当該登録ユーザの嗜好を隠す必要のある他の人間とともに来場している、とみなすことができる。本実施形態では特に、これに応じて、上記のように登録ユーザに係わる第1ユニットIDと第2ユニットIDとが一致しないと判定された場合に、制御部101は、当該登録ユーザに係わる第1及び第2ユニットIDにそれぞれ対応付けられた広告情報を再生しないように、再生部102を制御する。これにより、上記登録ユーザの意向に沿った形で、当該登録ユーザ向けの広告の提供を一切中止することができる。
なお、本発明は、上記実施形態に限られるものではなく、その趣旨及び技術的思想を逸脱しない範囲内で種々の変形が可能である。以下、そのような変形例を順次説明する。
(1)第1及び第2ユニットIDが不一致のときは、第2ユニットIDに対応する広告を再生する場合
上記実施形態においては、本来の嗜好に対応した第1ユニットIDと、今回の選曲操作に対応する第2ユニットIDとが、一致しないと判定された場合には、当該第1及び第2ユニットIDにそれぞれ対応付けられた広告情報を再生しないように再生部102を制御していたが、これに限られない。すなわち、このような場合には、今回の選曲操作に対応する第2ユニットIDに対応付けられた広告情報を再生部102により再生させるようにしてもよい。
図11を用いて、本変形例におけるステップS100の詳細手順を説明する。なお、図11は、前述の図8に対応する図である。図8と同等の手順には同符号を付し説明を省略する。
図11において、前述の図8と異なる点は、ステップS170とステップS190との間に、ステップS185を新たに設けた点である。すなわち、ステップS170において、前述のステップS105でユーザIDが取得された登録ユーザに係わる第1ユニットIDと当該登録ユーザに係わる第2ユニットIDとが一致するかどうかを判定し、当該第1ユニットIDと当該第2ユニットIDとが一致しなかった場合には、新たに設けたステップS185に移る。
ステップS185では、制御部101は、前述のステップS105でユーザIDが取得された登録ユーザに関して前述のステップS200で決定された第2ユニットIDを、広告対象とするユニットIDとして決定する。その後、ステップS190に移る。
上記以外の手順は、前述の図8と同様であるので、説明を省略する。
本変形例において、カラオケ装置100の制御部101が実行する、広告情報の再生に関する制御手順は、前述の図10とほぼ同様であるが、ステップS510及びステップS560の手順が少し異なっている。
本変形例におけるステップS510では、上記実施形態におけるステップS510と異なり、制御部101は、前述のステップS60、又は前述のステップS70、又は前述のステップS150、又は前述のステップS180、又は上記図11のステップS185において広告対象とするユニットIDとして決定されたユニットIDを取得する。なお、上記実施形態におけるステップS510と同様、広告対象とするユニットIDとして決定されたユニットIDが複数ある場合には、このステップS510では、当該決定された複数のユニットがそれぞれ取得される。
また、本変形例におけるステップS560では、制御部101は、上記実施形態におけるステップS560とほぼ同様の処理を行う。本変形例においては、上述したように、前述のステップS170の判定が満たされなかった場合には、上記実施形態と異なり、上記図11のステップS185において、前述のステップS105でユーザIDが取得された登録ユーザに係わる第2ユニットIDが、広告対象とするユニットIDに決定される。このような場合には、本変形例におけるステップS560では、上記実施形態におけるステップS560と異なり、制御部101は、当該第2ユニットIDに対応付けられた広告情報を再生部102により再生させる。
ここで、登録ユーザに係わる第1ユニットIDと第2ユニットIDとが一致しない場合には、前述のステップS170の判定が満たされないため、上記登録ユーザが、当該登録ユーザの嗜好を隠す必要のある他の人間とともに来場している、とみなすことができる。本変形例においては、これに応じて、上記のように登録ユーザに係わる第1ユニットIDと第2ユニットIDとが一致しないと判定された場合に、制御部101が、当該登録ユーザの本来の嗜好に相当する第1ユニットIDに対応付けられた広告情報を再生部102により再生させるのではなく、第2ユニットIDに対応付けられた広告情報を再生部102により再生させる。これにより、上記登録ユーザの意向に沿った形で、当該登録ユーザの本来の嗜好を推定できるような広告の提供を中止することができる。
(2)第1及び第2ユニットIDが不一致のときは、第1又は第2ユニットIDに対応する広告を選択的に再生させる場合
すなわち、本来の嗜好に対応した第1ユニットIDと、今回の選曲操作に対応する第2ユニットIDとが、一致しないと判定された場合には、ユニット選択確率を算出して、その算出されたユニット選択確率となるようにしつつ、第1及び第2ユニットIDのどちらか一方に対応付けられた広告情報を再生部102により選択的に再生させるようにしてもよい。
本変形例においては、カラオケ装置100の大容量記憶装置107のテーブル記憶エリアには、ユニット組合せ別係数テーブル1075(後述の図12参照)、及び、歌唱回数別係数テーブル1076(後述の図13参照)が記憶されている。
図12に、上記ユニット組合せ別係数テーブル1075の記憶内容の一例を示す。
図12に示すように、ユニット組合せ別係数テーブル1075には、予め、想定される上記第1ユニットIDと上記第2ユニットIDとの組み合わせに応じて定められた、第1重み付け係数としての係数M1が記憶されている。
係数M1は、第1ユニットIDに対応した嗜好と第2ユニットIDに対応した嗜好との接点の有無を表している。この例では、係数M1の最大値が「1」、最小値が「0」に設定され記憶されている。そして、第1ユニットIDに対応した嗜好と第2ユニットIDに対応した嗜好との接点が多い組み合わせほど、言い換えれば、本来の嗜好の度合いが高いほど、対応する係数M1が大きくなり(この例では1に近くなり)、逆に、第1ユニットIDに対応した嗜好と第2ユニットIDに対応した嗜好との接点が少ない組み合わせほど、言い換えれば、本来の嗜好の度合いが低いほど、対応する係数M1が小さくなる(この例では0に近くなる)ように設定され記憶されている。
図12に示す例では、例えば、第1ユニットID「1」及び第2ユニットID「1」の組み合わせに対応した係数M1は最大値の「1」に設定されている。第1ユニットID「1」及び第2ユニットID「2」の組み合わせに対応した係数M1は「0.5」に設定されている。第1ユニットID「1」及び第2ユニットID「3」の組み合わせに対応した係数M1は「0.5」に設定されている。第1ユニットID「1」及び第2ユニットID「4」の組み合わせに対応した係数M1は「0.1」に設定されている。第1ユニットID「1」及び第2ユニットID「5」の組み合わせに対応した係数M1は「0.8」に設定されている。説明は省略するが、上記以外の組み合わせについても、それぞれ同様に、対応する係数M1が設定されている。
図13に、上記歌唱回数別係数テーブル1076の記憶内容の一例を示す。
図13に示すように、歌唱回数別係数テーブル1076には、予め、上記第2ユニットIDに対応した登録ユーザの歌唱回数の大小に応じて定められた、第2重み付け係数としての係数M2が記憶されている。この例では、係数M2の最大値が「1」に設定され、歌唱回数が多くなるに従って、対応する係数M2が小さくなるように設定され記憶されている。
図13に示す例では、歌唱回数「0回〜3回」に対応した係数M2が最大値の「1」に設定されている。歌唱回数「4回〜5回」に対応した係数M2が「0.9」に設定されている。歌唱回数「6回〜7回」に対応した係数M2が「0.8」に設定されている。歌唱回数「8回以上」に対応した係数M2が最小値の「0.7」に設定されている。
図14を用いて、本変形例におけるステップS100の詳細手順を説明する。なお、図14は、前述の図8及び図11に対応する図である。図8と同等の手順には同符号を付し説明を省略する。
図14において、前述の図8と異なる点は、ステップS170とステップS190との間に、ステップS300を新たに設けた点である。すなわち、ステップS170において、前述のステップS105でユーザIDが取得された登録ユーザに係わる第1ユニットIDと当該登録ユーザに係わる第2ユニットIDとが一致するかどうかを判定し、当該第1ユニットIDと当該第2ユニットIDとが一致しなかった場合には、新たに設けたステップS300に移る。
ステップS300では、制御部101は、所定のユニット情報選択処理を実行する。なお、このステップS300の詳細内容については、後述の図15で説明する。
上記以外の手順は、前述の図8と同様であるので、説明を省略する。
図15を用いて、上記図14のステップS300の詳細手順を説明する。
図15において、まずステップS310で、制御部101は、上記ユニット別係数テーブル1075(図12参照)から、前述のステップS105でユーザIDが取得された登録ユーザに関して前述のステップS30で取得された第1ユニットIDと、当該登録ユーザに関して前述のステップS200で決定された第2ユニットIDと、の組み合わせに対応した上記係数M1を取得する。なお、第1ユニットIDに対応した嗜好と第2ユニットIDに対応した嗜好との接点が多い組み合わせほど、言い換えれば、本来の嗜好の度合いが高いほど、値の大きい係数M1が取得される。逆に、第1ユニットIDに対応した嗜好と第2ユニットIDに対応した嗜好との接点が少ない組み合わせほど、言い換えれば、本来の嗜好の度合いが低いほど、値の小さい係数M1が取得される。例えば、第1ユニットIDが「1」であり、第2ユニットIDが「5」である場合がある。この場合には、ユニット別係数テーブル1075から、第1ユニットID「1」及び第2ユニットID「5」の組み合わせに対応した係数M1(図12に示す例では「0.8」)が取得される。
その後、ステップS320で、制御部101は、上記歌唱履歴テーブル1072(図3参照)に記憶された、前述のステップS105でユーザIDが取得された登録ユーザの歌唱履歴情報のレコード数、すなわち、当該登録ユーザの歌唱回数を検出する。
そして、ステップS330に移り、制御部101は、上記歌唱回数別係数テーブル1076(図13参照)から、上記ステップS320で検出された、前述のステップS105でユーザIDが取得された登録ユーザの歌唱回数に対応した上記係数M2を取得する。なお、歌唱回数が少ないほど、値の大きい係数M2が取得される。逆に、歌唱回数が多いほど、値の小さい係数M2が取得される。例えば、上記ステップS320で、当該登録ユーザの歌唱回数が「2回」であると検出された場合がある。この場合には、歌唱回数別係数テーブル1076から、歌唱回数「2回」に対応した係数M2(図13に示す例では歌唱回数「0回〜3回」までに対応した「1」)が取得される。
その後、ステップS340で、制御部101は、上記ステップS310で取得された係数M1と、上記ステップS330で取得された係数M2とを用いて、ユニット選択確率Pを算出する。この例では、制御部101は、上記ステップS310で取得された係数M1、及び、上記ステップS330で取得された係数M2を乗じて、ユニット選択確率Pを算出する。ユニット選択確率Pは、第1ユニットIDに対応付けられた広告情報と、第2ユニットIDに対応付けられた広告情報とのうち、第1ユニットIDに対応付けられた広告情報を選択する確率である。すなわち、ユニット選択確率Pの値が大きいほど、第1ユニットIDに対応付けられた広告情報が選択される確率が高くなり、逆に、ユニット選択確率Pの値が小さいほど、第1ユニットIDに対応付けられた広告情報が選択される確率が低くなる。なお、ユニット選択確率Pを、第2ユニットIDに対応付けられた広告情報を選択する確率としてもよい。このステップSS340の手順が、各請求項記載の選択確率算出手段として機能する。
そして、ステップS350で、制御部101は、上記ステップS340で算出されたユニット選択確率Pとなるように、前述のステップS105でユーザIDが取得された登録ユーザに関して前述のステップS30で取得された第1ユニットIDと、当該登録ユーザに関して前述のステップS200で決定された第2ユニットIDとを、選択的に広告対象とするユニットIDとして決定する。その後、このルーチンを終了する。
本変形例において、カラオケ装置100の制御部101が実行する、広告情報の再生に関する制御手順は、前述の図10とほぼ同様であるが、ステップS510及びステップS560の手順が少し異なっている。
本変形例におけるステップS510では、上記実施形態におけるステップS510と異なり、制御部101は、前述のステップS60、又は前述のステップS70、又は前述のステップS150、又は前述のステップS180、又は上記図15のステップS350において広告対象とするユニットIDとして決定されたユニットIDを取得する。なお、上記実施形態におけるステップS510と同様、広告対象とするユニットIDとして決定されたユニットIDが複数ある場合には、このステップS510では、当該決定された複数のユニットがそれぞれ取得される。
また、本変形例におけるステップS560では、制御部101は、上記実施形態におけるステップS560とほぼ同様の処理を行う。本変形例においては、上述したように、前述のステップS170の判定が満たされなかった場合には、上記実施形態と異なり、上記図15のステップS350において、前述のステップS105でユーザIDが取得された登録ユーザに係わる第1ユニットIDと、当該登録ユーザに係わる第2ユニットIDとが、選択的に広告対象とするユニットIDに決定される。このような場合には、本変形例におけるステップS560では、上記実施形態におけるステップS560と異なり、制御部101は、上記ステップS360で選択的に決定された第1又は第2ユニットIDに対応付けられた広告情報を再生部102により再生させる。これは実質的には、上記図15のステップS340で算出されたユニット選択確率Pとなるように、第1ユニットIDに対応付けられた広告情報と、第2ユニットIDに対応付けられた広告情報とを、選択的に再生部102により再生させることに相当する。
ここで、ユーザの嗜好の内容によっては、あるいは、当該ユーザの嗜好とは別の他の嗜好との組合せ次第によっては、ユーザの嗜好と上記他の嗜好との接点の有無や、それら2つの嗜好における妥協性の程度について、差がある場合がある。本変形例においては、上記の傾向に鑑みて、予め、上記ユニット組合せ別係数テーブル1075(図12を参照)に、想定される第1ユニットIDと第2ユニットIDとの組み合わせに応じた係数M1が設定され記憶されている。第1ユニットIDと第2ユニットIDとが一致しないと判定された場合には、制御部101が、上記ユニット組合せ別係数テーブル1075の記憶内容を参照して、それら第1ユニットID及び第2ユニットIDの組み合わせに対応した係数M1を用いて、ユニット選択確率Pを算出する(図15のステップS340を参照)。そして、制御部101は、上記算出されたユニット選択確率Pとなるようにしつつ、第1ユニットIDに対応した広告情報と、第2ユニットIDに対応した広告情報とを、選択的に再生部102により再生させる。
これにより、係数M1により確率的な広告提供特性を規定しつつ、きめの細かい広告提供をユーザに対し行うことができる。
また、ユーザが、当該ユーザの嗜好を可能ならば他の人間に対して隠したい、あるいは見えにくくしたいという意向を持つ場合に、その気持ちの程度は、他の人間の顔ぶれやその時々の状況によって種々変化する場合がある。特にユーザの歌唱回数は上記気持ちの程度と相関がある場合がある。すなわち、前述のように第1ユニットIDと第2ユニットIDとが不一致の状態のまま、当該ユーザの歌唱回数が比較的多くなった場合には、当該ユーザの、上記嗜好を隠したいという気持ちは徐々に強まってきている可能性が高い。そこで本変形例においては、上記の傾向に鑑みて、予め、上記歌唱回数別係数テーブル1076(図13を参照)に、ユーザの歌唱回数の大小に応じた係数M2が設定され記憶されている。第1ユニットIDと第2ユニットIDとが一致しないと判定された場合には、制御部101が、上記ユニット組合せ別係数テーブル1075の記憶内容に基づく上記係数M1を用いるとともに、上記登録ユーザの歌唱回数を加味して設定された上記係数M2も用いて、ユニット選択確率Pを算出する。そして、制御部101は、上記算出されたユニット選択確率Pとなるようにしつつ、第1ユニットIDに対応した広告情報と、第2ユニットIDに対応した広告情報とを、選択的に再生部102により再生させる。
これにより、ユーザの意向を高精度に反映した、さらにきめの細かい広告提供を行うことができる。
なお、以上においては、広告配信サーバ400が複数の広告情報を予めカラオケ装置100へ出力しておき、カラオケ装置100の制御部101が、これら複数の広告情報のうち、広告対象とするユニットIDとして決定されたユニットIDに対応付けられた広告情報を、1つの演奏曲の再生終了後、次の再生開始までの間に、再生部102により再生させていたが、これに限られない。例えば、表示部103の表示画面を複数に分割し、そのうち1つの画面には演奏曲に対応した歌詞テロップを表示させると共に、別の画面には当該広告情報を表示させるようにしてもよい。
また、例えば、広告配信サーバ400が広告情報を適宜のタイミングでリモコン200へ出力し、操作部205が一定時間操作されていないと判断された場合に、リモコン200の制御部201が、上記広告対象とするユニットIDとして決定されたユニットIDに対応付けられた広告情報を、表示部203全体に表示させるようにしてもよい。あるいは、表示部203の表示画面を複数に分割し、そのうち1つの画面には演奏曲の選曲画面を表示させると共に、別の画面には当該広告情報を表示させるようにしてもよい。この場合には、リモコン200の制御部201が、各請求項記載の広告情報出力手段として機能する。
また、図7、図8、図9、図10等に示すフローチャートは本発明を上記フローに示す手順に限定するものではなく、発明の趣旨及び技術的思想を逸脱しない範囲内で手順の追加・削除又は順番の変更等をしてもよい。
また、以上既に述べた以外にも、上記実施形態や各変形例による手法を適宜組み合わせて利用しても良い。
その他、一々例示はしないが、本発明は、その趣旨を逸脱しない範囲内において、種々の変更が加えられて実施されるものである。