JP7053387B2 - サーバ装置 - Google Patents

Description

本発明はサーバ装置に関する。

音楽業界においては、ＣＤ市場の縮小やインタラクティブ配信市場の停滞といった課題ある。一方、同じ音楽業界の中でも、ライブ・エンタテインメント市場は会場不足が深刻な問題になるほど急成長を遂げている。

カラオケ業界においては、ライブ・エンタテインメント市場の急成長をカラオケ歌唱の需要に繋げるべく様々な取り組みがなされている。

たとえば、特許文献１には、コンサート等のリアルタイムイベントにおいて生演奏される楽曲をカラオケ装置に配信し、客がこの楽曲にあわせて歌うことのできるリアルタイムイベント型コンテンツについて記載されている。

特開２００８－１１６７１９号公報

一方、ライブイベントの参加者を、ライブイベント直後にカラオケ店舗に誘引し、カラオケ歌唱を促すようなシステムは存在しない。

本発明の目的は、ライブイベントの参加者に対して、ライブイベント直後にカラオケ歌唱を促すことが可能なサーバ装置を提供することにある。

上記目的を達成するための発明は、ライブイベントを開催する日付及び終了予定時刻を含むスケジュール情報と、当該ライブイベントを行うアーティスト名を含むアーティスト情報と、当該ライブイベントを行う会場の所在地を示す地図情報とを、当該ライブイベントのライブ識別情報と紐付けて記憶する情報記憶部と、前記スケジュール情報と、現在の日付及び現在時刻を含む現在情報とに基づいて、ライブイベントの終了を検出する検出部と、ＧＰＳ機能を備える携帯端末から、当該携帯端末の所有者の位置情報及び当該携帯端末の識別情報を受信する情報受信部と、あるライブイベントの終了が検出された場合、受信した前記位置情報及び前記携帯端末の識別情報と、当該あるライブイベントに対応する前記地図情報とに基づいて、前記所有者の中から当該あるライブイベントの参加者を特定する特定部と、特定した前記参加者に対し、前記あるライブイベントを行うアーティストが歌唱する楽曲のカラオケ歌唱を薦めるリコメンド情報を生成する生成部と、特定した前記参加者の携帯端末に対し、生成した前記リコメンド情報を送信する情報送信部と、を有するサーバ装置である。
本発明の他の特徴については、後述する明細書及び図面の記載により明らかにする。

本発明によれば、ライブイベントの参加者に対して、ライブイベント直後にカラオケ歌唱を促すことができる。

第１実施形態に係るサーバ装置及び所有者が所有する携帯端末を示す図である。 第１実施形態に係るサーバ装置のハードウェア構成例を示す図である。 情報記憶部に記憶される各種情報の例を示す図である。 第１実施形態に係るサーバ装置のソフトウェア構成例を示す図である。 第１実施形態に係るサーバ装置の処理を示すフローチャートである。 第２実施形態に係るサーバ装置のソフトウェア構成例を示す図である。 あるアーティストの楽曲及び各楽曲の歌唱回数を示す図である。 第２実施形態に係るサーバ装置の処理を示すフローチャートである。 第３実施形態に係るサーバ装置のソフトウェア構成例を示す図である。 第３実施形態に係るサーバ装置の処理を示すフローチャートである。 第３実施形態に係るサーバ装置の処理を示すフローチャートである。

＜第１実施形態＞
図１～図５を参照して、本実施形態に係るサーバ装置Ｓについて説明する。

＝＝サーバ装置の概要＝＝
サーバ装置Ｓは、ライブイベントに関する各種情報の管理、携帯端末から送信される情報の処理、携帯端末に対する各種情報の送信等を行うコンピュータである。図１に示すように、本実施形態に係るサーバ装置Ｓは、所有者Ｕ１～所有者Ｕ５が所有する携帯端末Ｍ１～携帯端末Ｍ５と通信可能となっている。また、所有者Ｕ１～所有者Ｕ５のうち、所有者Ｕ１は、会場Ｐで開催されるアーティストのライブイベントＸに参加していたとする。この場合、所有者Ｕ１は、ライブイベントＸの「参加者」に相当する。

携帯端末は、ＧＰＳ機能を備える一般的なスマートフォンやタブレット端末である。ＧＰＳ機能を利用することにより、携帯端末の位置情報（すなわち所有者の位置情報）を入手することができる。また、携帯端末には、位置情報の送信やリコメンド情報（後述）の受信等に使用する専用アプリケーションソフトウェア（以下、「リコメンドアプリ」）がインストールされている。リコメンドアプリは、サーバ装置Ｓや、サーバ装置Ｓが提供するＷｅｂサイトからダウンロードすることで入手できる。

＝＝サーバ装置の具体的な構成＝＝
図２はサーバ装置Ｓのハードウェア構成例を示す図である。サーバ装置Ｓは、記憶部１０、通信部２０、及び制御部３０を備える。各構成はインターフェース（図示なし）を介してバスＢに接続されている。

［記憶部］
記憶部１０は、各種のデータを記憶する大容量の記憶装置である。記憶部１０は、たとえば、カラオケ装置でカラオケ歌唱する際に利用する伴奏データ、楽曲名やアーティスト名を含む楽曲情報を記憶している。

また、本実施形態に係る記憶部１０の記憶領域の一部は、情報記憶部１０ａとして機能する。

情報記憶部１０ａは、スケジュール情報、アーティスト情報、及び地図情報を、ライブ識別情報と紐付けて記憶する。

スケジュール情報は、ライブイベントを開催する日付（年月日）、及びライブイベントの終了予定時刻を含む。アーティスト情報は、ライブイベントを行うアーティスト名を含む。地図情報は、ライブイベントを行う会場の所在地を示す。ライブ識別情報は、複数あるライブイベントを区別するための識別子（イベントＩＤ）である。

情報記憶部１０ａは、各種情報をライブイベント毎に記憶している。図３は、情報記憶部１０ａに記憶される各種情報の例を示している。新たなライブイベントの予定が確定する都度、サーバ装置Ｓは、ライブ識別情報と紐付けて各種情報を記憶する。一方、記憶されているライブイベントが終了した場合、サーバ装置Ｓは、情報記憶部１０ａから終了したライブイベントのライブ識別情報及びそれに紐付けられている各種情報を消去する。

また、情報記憶部１０ａは、リコメンドアプリがインストールされている携帯端末の識別情報（端末ＩＤ）を記憶している。

更に、本実施形態に係る情報記憶部１０ａは、歌唱履歴を所有者毎に記憶している。歌唱履歴は、所有者が過去に行ったカラオケ歌唱に関する各種情報であり、少なくとも過去にカラオケ歌唱を行った楽曲のアーティスト名を含む。本実施形態において、歌唱履歴は、所有者が所有する携帯端末の識別情報と関連付けて記憶されている。

［通信部・制御部］
通信部２０は、サーバ装置Ｓと各携帯端末とを接続するためのインターフェースを提供する。制御部３０は、サーバ装置Ｓにおける各種の制御を行う。制御部３０は、ＣＰＵおよびメモリ（いずれも図示なし）を備える。ＣＰＵは、メモリに記憶されたプログラムを実行することにより各種の機能を実現する。

＝＝ソフトウェア構成＝＝
図４はサーバ装置Ｓのソフトウェア構成例を示す図である。本実施形態に係る制御部３０は、検出部１００、情報受信部２００、特定部３００、取得部４００、生成部５００、及び情報送信部６００として機能する。検出部１００、情報受信部２００、特定部３００、取得部４００、生成部５００、及び情報送信部６００は、制御部３０のＣＰＵがメモリに記憶されるプログラムを実行することにより実現される。

［検出部］
検出部１００は、スケジュール情報と、現在情報とに基づいて、ライブイベントの終了を検出する。現在情報は、現在の日付（年月日）及び現在時刻を含む。

検出部１００は、現在情報とスケジュール情報とを定期的（たとえば１分間隔）に比較する。現在の日付及び現在時刻と一致するスケジュール情報が記憶されている場合、検出部１００は、当該スケジュール情報が紐付けられたライブ識別情報に対応するライブイベントが終了したことを検出する。検出部１００は、終了したライブイベントに対応するライブ識別情報を情報送信部２００及び特定部３００に出力する。

［情報受信部］
情報受信部２００は、ＧＰＳ機能を備える携帯端末から、当該携帯端末の所有者の位置情報及び当該携帯端末の識別情報を受信する。

情報受信部２００は、各携帯端末に対して所定のタイミングで位置情報の問い合わせを行う。所定のタイミングは、たとえば、検出部１００によりライブイベントの終了が検出されたタイミングに基づいて決定することができる。具体的には、ライブイベントの終了と同時のタイミング、或いは会場を出る時間を考慮してライブイベント終了時刻の１０分後のタイミング等が可能である。

リコメンドアプリを起動している携帯端末は、当該位置情報の問い合わせに対し、ＧＰＳ機能により取得した位置情報（所有者の位置情報）を携帯端末の識別情報（端末ＩＤ）と併せてサーバ装置Ｓに送信する。

情報受信部２００は、各携帯端末から送信された所有者の位置情報及び端末ＩＤを受信する。情報受信部２００は、受信した所有者の位置情報及び端末ＩＤを特定部３００に出力する。

なお、サーバ装置Ｓによるリコメンド情報を取得するためには、携帯端末の所有者がリコメンドアプリを予め起動しておくことが推奨される。本実施形態の説明においては、図１に示した所有者Ｕ１～所有者Ｕ５のいずれもが自己の携帯端末でリコメンドアプリを起動しているとする。

［特定部］
特定部３００は、あるライブイベントの終了が検出された場合、受信した位置情報及び携帯端末の識別情報と、当該あるライブイベントに対応する地図情報とに基づいて、所有者の中から当該あるライブイベントの参加者を特定する。

特定部３００は、終了したライブイベントに対応する地図情報と、受信した位置情報を比較し、地図情報と一致する位置情報を送信した携帯端末（或いは、地図情報が示す位置を含む所定範囲に含まれる位置情報を送信した携帯端末）の所有者をライブイベントの参加者として特定する。特定部３００は、特定した参加者が所有する携帯端末の識別情報（情報受信部２００で受信した端末ＩＤ）を情報送信部６００に出力する。

たとえば、図１の例において、会場ＰにおけるライブイベントＸが終了したとする。この場合、情報受信部２００は、携帯端末Ｍ１～携帯端末Ｍ５に位置情報の問い合わせを行う。各携帯端末は、自らの位置情報及び端末ＩＤをサーバ装置Ｓに送信する。

特定部３００は、各携帯端末から送信された位置情報と、ライブイベントＸに対応する地図情報とを比較し、リコメンドアプリを起動している携帯端末の所有者の中から、ライブイベントＸの参加者（当該参加者が所有する携帯端末）を特定する。たとえば図１の例であれば、特定部３００は、携帯端末Ｍ１を所有する所有者Ｕ１をライブイベントＸの参加者として特定する。特定部３００は、携帯端末Ｍ１の端末ＩＤを情報送信部６００に出力する。

なお、特定部３００は、受信した位置情報及び端末の識別情報と、あるライブイベントの地図情報と、歌唱履歴とに基づいて、当該あるライブイベントの参加者を特定することが可能である。

上述の通り、情報記憶部１０ａは所有者の歌唱履歴を記憶している。ここで、所有者の歌唱履歴に、あるライブイベントで歌唱したアーティストが含まれる場合、当該所有者は、あるライブイベントに参加している可能性が高い。一方、あるライブイベントで歌唱したアーティストが歌唱履歴に含まれない場合、特定した携帯端末の所有者は、あるライブイベントに参加していない可能性が高い（たとえば、別の会場で行われたライブイベントに参加し、たまたま帰り道に会場Ｐ付近を通りかかった等）。このように歌唱履歴を利用することにより、あるライブイベントの参加者をより正確に特定することが可能となる。

具体的に、特定部３００は、終了したライブイベントに対応する地図情報と、受信した位置情報を比較し、地図情報と一致する位置情報を送信した携帯端末を特定する。特定部３００は、特定した携帯端末の端末ＩＤに基づいて、所有者の歌唱履歴を参照する。そして、あるライブイベントで歌唱したアーティストが、特定した携帯端末の所有者の歌唱履歴に含まれる場合、特定部３００は、当該所有者を、あるライブイベントの参加者として特定する。一方、あるライブイベントで歌唱したアーティストが、特定した携帯端末の所有者の歌唱履歴に含まれない場合、特定部３００は、当該所有者を、あるライブイベントの参加者とはみなさない。

［取得部］
取得部４００は、あるライブイベントで歌唱された楽曲名及び曲順を含むセットリスト情報を取得する。

セットリスト情報の取得は、様々な方法を用いることが可能である。たとえば、予めアーティスト側からセットリスト情報を入手しておき、その情報を情報記憶部１０ａに登録しておく。そして、取得部４００は、情報記憶部１０ａからセットリスト情報を読み出すことでセットリスト情報を取得することができる。

或いは、ライブイベントのセットリスト情報を公開しているＷｅｂサイトが多数存在する（たとえば、“ＬｉｖｅＦａｎｓ” ライブファンズ株式会社 （ HYPERLINK "http://www.livefans.jp/" http://www.livefans.jp/））。取得部４００は、これらのＷｅｂサイトにアクセスし、あるライブイベントのセットリスト情報を取得することも可能である。これらのＷｅｂサイトの情報（ＵＲＬ情報）は、情報記憶部１０ａに記憶されている。

取得部４００は、取得したセットリスト情報を生成部５００に出力する。

［生成部］
生成部５００は、特定した参加者に対し、あるライブイベントを行うアーティストが歌唱する楽曲のカラオケ歌唱を薦めるリコメンド情報を生成する。

本実施形態において、生成部５００は、取得したセットリスト情報に基づいてリコメンド情報を生成する。生成部５００は、生成したコメンド情報を情報送信部６００に出力する。

生成部５００は、取得したセットリスト情報をそのままリコメンド情報としてもよいし、セットリスト情報の一部（たとえば、本編のみ、アンコールのみ）を抽出してリコメンド情報としてもよい。或いは、生成部５００は、セットリスト情報の中から、特定した参加者の歌唱履歴に含まれる楽曲のみを抽出してリコメンド情報としてもよい。また、リコメンド情報は、楽曲名のみであってもよいし、楽曲名と併せて楽曲ＩＤ（カラオケ装置で予約する際に入力するＩＤ）を含んでいてもよい。

［情報送信部］
情報送信部６００は、特定した参加者の携帯端末に対し、生成したリコメンド情報を送信する。

情報送信部６００は、特定部３００から受信した携帯端末の端末ＩＤを元に、特定した参加者が所有する携帯端末にリコメンド情報を送信する。リコメンド情報を受信した参加者は、ライブイベントの直後に、自己の携帯端末上でリコメンド情報に含まれる楽曲名等を確認することができる。

＝＝サーバ装置における処理について＝＝
次に、図５を参照して本実施形態に係るサーバ装置Ｓにおける処理の具体例について述べる。図５は、サーバ装置Ｓにおける処理例を示すフローチャートである。この例では、サーバ装置Ｓの情報記憶部１０ａは、少なくともスケジュール情報と、アーティスト情報と、地図情報とを、ライブ識別情報と紐付けて記憶している。また、図１に示すように、所有者Ｕ１～所有者Ｕ５が携帯端末Ｍ１～携帯端末Ｍ５を所有しており、所有者Ｕ１が会場ＰでライブイベントＸに参加していたとする。

検出部１００は、スケジュール情報と、現在の日付及び現在時刻を含む現在情報とに基づいて、ライブイベントＸの終了を検出する（ライブイベントＸの終了を検出。ステップ１０）。

ライブイベントＸの終了が検出された場合、情報受信部２００は、各所有者の携帯端末に対して位置情報の問い合わせを行う（位置情報の問い合わせ。ステップ１１）。情報受信部２００は、各携帯端末から、当該携帯端末の所有者の位置情報及び当該携帯端末の識別情報を受信する（位置情報等を受信。ステップ１２）。

特定部３００は、ステップ１２で受信した位置情報及び携帯端末の識別情報と、ライブイベントＸに対応する地図情報とに基づいて、所有者の中からライブイベントＸの参加者（所有者Ｕ１）を特定する（参加者を特定。ステップ１３）。

取得部４００は、ライブイベントＸで歌唱された楽曲名及び曲順を含むセットリスト情報を取得する（セットリスト情報を取得。ステップ１４）。セットリスト情報は、情報記憶部１０ａからセットリスト情報を読み出すことで取得してもよいし、ライブイベントのセットリスト情報を公開しているＷｅｂサイトから取得することでもよい。

生成部５００は、ステップ１４で取得したセットリスト情報に基づいて、ライブイベントＸを行うアーティストが歌唱する楽曲のカラオケ歌唱を、ステップ１３で特定した所有者Ｕ１に対して薦めるリコメンド情報を生成する（リコメンド情報を生成。ステップ１５）。

情報送信部６００は、ステップ１３で特定した所有者Ｕ１が所有する携帯端末に対し、ステップ１５で生成したリコメンド情報を送信する（リコメンド情報を送信。ステップ１６）。

以上から明らかなように、本実施形態に係るサーバ装置Ｓは、ライブイベントを開催する日付及び終了予定時刻を含むスケジュール情報と、当該ライブイベントを行うアーティスト名を含むアーティスト情報と、当該ライブイベントを行う会場の所在地を示す地図情報とを、当該ライブイベントのライブ識別情報と紐付けて記憶する情報記憶部１０ａと、スケジュール情報と、現在の日付及び現在時刻を含む現在情報とに基づいて、ライブイベントの終了を検出する検出部１００と、ＧＰＳ機能を備える携帯端末から、当該携帯端末の所有者の位置情報及び当該携帯端末の識別情報を受信する情報受信部２００と、あるライブイベントの終了が検出された場合、受信した位置情報及び携帯端末の識別情報と、当該あるライブイベントに対応する地図情報とに基づいて、所有者の中から当該あるライブイベントの参加者を特定する特定部３００と、特定した参加者に対し、あるライブイベントを行うアーティストが歌唱する楽曲のカラオケ歌唱を薦めるリコメンド情報を生成する生成部５００と、特定した参加者の携帯端末に対し、生成したリコメンド情報を送信する情報送信部６００と、を有する。

このようなサーバ装置Ｓによれば、ライブイベントの参加者に対し、ライブイベント直後に、ライブイベントを行ったアーティストが歌唱する楽曲をリコメンド情報として提供することができる。直前までライブイベントに参加していた参加者は、通常よりも音楽に対する関心が高まっていると考えられる。そのような参加者に対してリコメンド情報を提供することにより、参加者のカラオケ歌唱に対する意欲を高めることができる。すなわち、本実施形態に係るサーバ装置Ｓによれば、ライブイベントの参加者に対して、ライブイベント直後にカラオケ歌唱を促すことができる。その結果、ライブイベントの参加者をカラオケ店舗に誘引することができる。

また、情報記憶部１０ａは、過去にカラオケ歌唱を行った楽曲のアーティスト名を含む歌唱履歴を、所有者毎に記憶し、特定部３００は、受信した位置情報及び携帯端末の識別情報と、あるライブイベントの地図情報と、歌唱履歴とに基づいて、当該あるライブイベントの参加者を特定することができる。このように、歌唱履歴を含めてライブイベントの参加者を特定することにより、たまたまライブイベントの会場付近を通った者等と実際にライブイベントに参加していた者とを区別することができる。すなわち、このようなサーバ装置Ｓによれば、ライブイベントの参加者を正確に特定することができる。

また、本実施形態に係るサーバ装置Ｓは、あるライブイベントで歌唱された楽曲名及び曲順を含むセットリスト情報を取得する取得部４００を有し、生成部５００は、取得したセットリスト情報に基づいてリコメンド情報を生成することができる。このように、セットリスト情報をリコメンド情報とすることにより、特定された参加者は、直前まで聴いていたセットリストを知ることができる。ライブイベントの参加者にとってセットリスト情報はその日歌唱された楽曲を確認したり、その日の盛り上がり思い出したりすることができる貴重な情報である。従って、セットリスト情報に基づいたリコメンド情報をライブイベント直後に提供することにより、参加者のカラオケ歌唱に対する意欲をより高めることが可能となる。

＜第２実施形態＞
次に、図６～図８を参照して、本実施形態に係るサーバ装置Ｓについて説明する。本実施形態では、セットリスト情報の代わりに、あるアーティストが歌唱する複数の楽曲の中から抽出したいくつかの楽曲に基づいてリコメンド情報を生成する例について述べる。第１実施形態と同様の構成については詳細な説明を省略する。

＝＝ソフトウェア構成＝＝
図６はサーバ装置Ｓのソフトウェア構成例を示す図である。本実施形態に係る制御部３０は、検出部１００、情報受信部２００、特定部３００、生成部５００、情報送信部６００、及び抽出部７００として機能する。検出部１００、情報受信部２００、特定部３００、生成部５００、情報送信部６００、及び抽出部７００は、制御部３０のＣＰＵがメモリに記憶されるプログラムを実行することにより実現される。

［抽出部］
抽出部７００は、あるライブイベントを行ったアーティストが歌唱する楽曲の中から所定の楽曲を抽出する。

楽曲の抽出は、様々な方法を用いることが可能である。たとえば、サーバ装置Ｓの記憶部１０は、楽曲毎の歌唱回数を記憶している。図７は、アーティスト「ブラック砂漠」が歌唱する楽曲群とその歌唱回数を示している。抽出部７００は、図７に示した楽曲群の中から、上位１０曲や歌唱回数が所定回以上（たとえば、３０００回以上）の楽曲を所定の楽曲として抽出する。

或いは、抽出部７００は、アーティストが歌唱する楽曲群の中からリリース年度が新しい１０曲を所定の楽曲として抽出したり、ＣＭやテレビ番組のタイアップのみを所定の楽曲として抽出してもよい。リリース年度やタイアップの有無に関する情報は、記憶部１０が記憶する楽曲情報に予め含めておくことが可能である。

抽出部７００は、抽出した楽曲に対応する情報（楽曲名、楽曲ＩＤ等）を生成部５００に出力する。

［生成部］
本実施形態に係る生成部５００は、生成部５００は、抽出した楽曲に基づいてリコメンド情報を生成する。生成部５００は、生成したコメンド情報を情報送信部６００に出力する。

生成部５００は、抽出した楽曲をそのままリコメンド情報としてもよいし、抽出した楽曲の一部をリコメンド情報としてもよい。或いは、生成部５００は、抽出した楽曲の中から、特定した参加者の歌唱履歴に含まれる楽曲のみを抽出してリコメンド情報としてもよい。

＝＝サーバ装置における処理について＝＝
次に、図８を参照して本実施形態に係るサーバ装置Ｓにおける処理の具体例について述べる。図８は、サーバ装置Ｓにおける処理例を示すフローチャートである。この例では、サーバ装置Ｓの情報記憶部１０ａは、スケジュール情報と、アーティスト情報と、地図情報とを、ライブ識別情報と紐付けて記憶している。また、第１実施形態と同様、所有者Ｕ１～所有者Ｕ５が携帯端末Ｍ１～携帯端末Ｍ５を所有しており、所有者Ｕ１が会場ＰでライブイベントＸに参加していたとする。

ステップ２０～２３、及びステップ２６は、第１実施形態で説明したステップ１０～１３、及びステップ１６と同様の処理であるため、詳細な説明を省略する。

抽出部７００は、ライブイベントＸを行ったアーティストが歌唱する複数の楽曲の中から所定の楽曲を抽出する（所定の楽曲を抽出。ステップ２４）。

生成部５００は、ステップ２４で抽出した楽曲に基づいて、ライブイベントＸに対応するアーティスト情報が示すアーティストが歌唱する楽曲のカラオケ歌唱を、ステップ２３で特定した所有者Ｕ１に対して薦めるリコメンド情報を生成する（リコメンド情報を生成。ステップ２５）。

以上から明らかなように、本実施形態に係るサーバ装置Ｓは、あるライブイベントを行ったアーティストが歌唱する複数の楽曲の中から所定の楽曲を抽出する抽出部７００を有し、生成部５００は、抽出した所定の楽曲に基づいてリコメンド情報を生成する。

このように、ライブイベントを行ったアーティストが歌唱する複数の楽曲の中から抽出した所定の楽曲に基づいてリコメンド情報を生成することにより、セットリスト情報が入手できないような場合（ライブイベント直後にセットリスト情報がＷｅｂサイトに掲載されない場合や、マイナーなアーティストであってセットリスト情報自体が掲載されない場合等）であっても、参加者に対してカラオケ歌唱を促すことができる。

＜第３実施形態＞
次に、図９～図１０Ｂを参照して、本実施形態に係るサーバ装置Ｓについて説明する。本実施形態では、セットリスト情報の取得可否によって、リコメンド情報の基となる情報を変更する例について述べる。第１実施形態及び第２実施形態と同様の構成については詳細な説明を省略する。

＝＝ソフトウェア構成＝＝
図９はサーバ装置Ｓのソフトウェア構成例を示す図である。本実施形態に係る制御部３０は、検出部１００、情報受信部２００、特定部３００、取得部４００、生成部５００、情報送信部６００、及び抽出部７００として機能する。検出部１００、情報受信部２００、特定部３００、取得部４００、生成部５００、情報送信部６００、及び抽出部７００は、制御部３０のＣＰＵがメモリに記憶されるプログラムを実行することにより実現される。

［生成部］
本実施形態に係る生成部５００は、取得部４００によりセットリスト情報が取得できた場合、取得したセットリスト情報に基づいてリコメンド情報を生成し、取得部４００によりセットリスト情報が取得できなかった場合、抽出した所定の楽曲に基づいてリコメンド情報を生成する。

具体的に、取得部４００は、あるライブイベントの終了が検出された場合に、当該あるライブイベントのセットリスト情報の取得を試みる。セットリスト情報が取得できた場合、取得部４００は、取得したセットリスト情報を生成部５００に出力する。生成部５００は、取得したセットリスト情報に基づいてリコメンド情報を生成し、情報送信部６００に出力する。

一方、セットリスト情報が取得できなかった場合、取得部４００は、その旨の信号を生成部５００に出力する。当該信号の入力を受けた生成部５００は、抽出部７００に対し、あるライブイベントを行ったアーティストが歌唱する複数の楽曲の中から所定の楽曲を抽出するよう指示する。抽出部７００は、当該指示に基づいて、所定の楽曲を抽出し、生成部５００に出力する。生成部５００は、抽出した所定の楽曲に基づいてリコメンド情報を生成し、情報送信部６００に出力する。

なお、上記の構成によれば、ライブイベント直後にセットリストが取得できない場合には、抽出した所定の楽曲に基づいて生成されたリコメンド情報が参加者に提供される。一方、当該リコメンド情報を参照してカラオケ歌唱を行いたいと考えた参加者が、カラオケ歌唱を始める前に（たとえば、カラオケ店舗に移動している途中で）、Ｗｅｂサイト上にセットリストが掲載されることもありうる。

そこで、生成部５００は、情報送信部６００により、特定した参加者の携帯端末に対し、抽出した所定の楽曲に基づいてリコメンド情報を送信した後、所定時間以内に取得部４００によりセットリスト情報が取得された場合、取得したセットリスト情報に基づいて新たなリコメンド情報を生成することも可能である。

具体的に、取得部４００は、あるライブイベントの終了が検出された場合に、当該あるライブイベントのセットリスト情報の取得を試みる。セットリスト情報が取得できなかった場合、取得部４００は、その旨の信号を生成部５００に出力する。一方、取得部４００は、引き続きセットリスト情報の取得を試みる。その後、セットリスト情報が取得できた場合、取得部４００は、取得したセットリスト情報を生成部５００に出力する。

生成部５００は、取得部４００からセットリスト情報を取得した場合、抽出した所定の楽曲に基づくリコメンド情報を送信してからの経過時間を確認する。経過時間が所定時間（たとえば３０分）以内であった場合、生成部５００は、取得したセットリスト情報に基づいて新たなリコメンド情報を生成する。生成部５００は、新たなリコメンド情報を情報送信部６００に出力する。

この場合、情報送信部６００は、特定した参加者の携帯端末（抽出した所定の楽曲に基づくリコメンド情報を先に送信した携帯端末）に対し、新たなリコメンド情報を送信する。

＝＝サーバ装置における処理について＝＝
次に、図１０Ａ及び図１０Ｂを参照して本実施形態に係るサーバ装置Ｓにおける処理の具体例について述べる。図１０Ａ及び図１０Ｂは、サーバ装置Ｓにおける処理例を示すフローチャートである。この例では、サーバ装置Ｓの情報記憶部１０ａは、少なくともスケジュール情報と、アーティスト情報と、地図情報とを、ライブ識別情報と紐付けて記憶している。また、また、第１実施形態及び第２実施形態と同様、所有者Ｕ１～所有者Ｕ５が携帯端末Ｍ１～携帯端末Ｍ５を所有しており、所有者Ｕ１が会場ＰでライブイベントＸに参加していたとする。

ステップ３０～３３は、第１実施形態で説明したステップ１０～１３と同様の処理であるため、詳細な説明を省略する。

取得部４００は、ライブイベントＸで歌唱された楽曲名及び曲順を含むセットリスト情報の取得を試みる。セットリスト情報は、情報記憶部１０ａからセットリスト情報を読み出すことで取得してもよいし、ライブイベントのセットリスト情報を公開しているＷｅｂサイトから取得することでもよい。

セットリスト情報が取得できた場合（ステップ３４でＹの場合）、生成部５００は、取得したセットリスト情報に基づいて、ライブイベントＸに対応するアーティスト情報が示すアーティストが歌唱する楽曲のカラオケ歌唱を、ステップ３３で特定した所有者Ｕ１に対して薦めるリコメンド情報を生成する（セットリスト情報に基づくリコメンド情報を生成。ステップ３５）。

情報送信部６００は、ステップ３３で特定した所有者Ｕ１が所有する携帯端末に対し、ステップ３５で生成したリコメンド情報を送信する（リコメンド情報を送信。ステップ３６）。

一方、セットリスト情報が取得できなかった場合（ステップ３４でＮの場合）、抽出部７００は、ライブイベントＸを行ったアーティストが歌唱する複数の楽曲の中から所定の楽曲を抽出する（所定の楽曲を抽出。ステップ３７）。

生成部５００は、ステップ３７で抽出した楽曲に基づいて、ライブイベントＸに対応するアーティスト情報が示すアーティストが歌唱する楽曲のカラオケ歌唱を、ステップ３３で特定した所有者Ｕ１に対して薦めるリコメンド情報を生成する（所定の楽曲に基づくリコメンド情報を生成。ステップ３８）。

情報送信部６００は、ステップ３３で特定した所有者Ｕ１が所有する携帯端末に対し、ステップ３８で生成したリコメンド情報を送信する（リコメンド情報を送信。ステップ３９）。

ステップ３９でリコメンド情報を送信した後、所定時間以内に取得部４００によりセットリスト情報が取得された場合（ステップ４０でＹの場合）、生成部５００は、取得したセットリスト情報に基づいて新たなリコメンド情報を生成する（新たなリコメンド情報を生成。ステップ４１）。

情報送信部６００は、ステップ３３で特定した参加者の携帯端末に対し、新たなリコメンド情報を送信する（新たなリコメンド情報を送信。ステップ４２）。

以上から明らかなように、本実施形態に係るサーバ装置Ｓは、あるライブイベントで歌唱された楽曲名及び曲順を含むセットリスト情報を取得する取得部４００と、あるライブイベントを行ったアーティストが歌唱する複数の楽曲の中から所定の楽曲を抽出する抽出部７００と、を有し、生成部５００は、取得部４００によりセットリスト情報が取得できた場合、取得したセットリスト情報に基づいてリコメンド情報を生成し、取得部４００によりセットリスト情報が取得できなかった場合、抽出した所定の楽曲に基づいてリコメンド情報を生成する。

このように、セットリスト情報の取得状況に応じて、リコメンド情報の基となる情報を変更することにより、セットリスト情報の有無に関わらず、ライブイベントの参加者に対してリコメンド情報を提供することができる。

また、本実施形態に係るサーバ装置Ｓにおける生成部５００は、情報送信部６００により、特定した参加者の携帯端末に対し、抽出した所定の楽曲に基づいてリコメンド情報を送信した後、所定時間以内に取得部４００によりセットリスト情報が取得された場合、取得したセットリスト情報に基づいて新たなリコメンド情報を生成し、情報送信部６００は、特定した参加者の携帯端末に対し、新たなリコメンド情報を送信する。

第１実施形態で述べたように、ライブイベントの参加者にとってセットリスト情報は貴重な情報である。従って、セットリスト情報が取得できた場合には、当該セットリスト情報に基づいて新たなリコメンド情報を提供することにより、参加者のカラオケ歌唱に対する意欲をより高めることが可能となる。

＜その他＞
上記実施形態は、例として提示したものであり、発明の範囲を限定するものではない。上記の構成は、適宜組み合わせて実施することが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。上記実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０ａ 情報記憶部
１００ 検出部
２００ 情報受信部
３００ 特定部
４００ 取得部
５００ 生成部
６００ 情報送信部
７００ 抽出部
Ｍ１～Ｍ５ 携帯端末
Ｓ サーバ装置

Claims (6)

1. ライブイベントを開催する日付及び終了予定時刻を含むスケジュール情報と、当該ライブイベントを行うアーティスト名を含むアーティスト情報と、当該ライブイベントを行う会場の所在地を示す地図情報とを、当該ライブイベントのライブ識別情報と紐付けて記憶する情報記憶部と、
   前記スケジュール情報と、現在の日付及び現在時刻を含む現在情報とに基づいて、ライブイベントの終了を検出する検出部と、
   ＧＰＳ機能を備える携帯端末から、当該携帯端末の所有者の位置情報及び当該携帯端末の識別情報を受信する情報受信部と、
   あるライブイベントの終了が検出された場合、受信した前記位置情報及び前記携帯端末の識別情報と、当該あるライブイベントに対応する前記地図情報とに基づいて、前記所有者の中から当該あるライブイベントの参加者を特定する特定部と、
   特定した前記参加者に対し、前記あるライブイベントを行うアーティストが歌唱する楽曲のカラオケ歌唱を薦めるリコメンド情報を生成する生成部と、
   特定した前記参加者の携帯端末に対し、生成した前記リコメンド情報を送信する情報送信部と、
   を有するサーバ装置。
2. 前記情報記憶部は、過去にカラオケ歌唱を行った楽曲のアーティスト名を含む歌唱履歴を、所有者毎に記憶し、
   前記特定部は、受信した前記位置情報及び前記携帯端末の識別情報と、前記あるライブイベントの地図情報と、前記歌唱履歴とに基づいて、当該あるライブイベントの参加者を特定することを特徴とする請求項１記載のサーバ装置。
3. 前記あるライブイベントで歌唱された楽曲名及び曲順を含むセットリスト情報を取得する取得部を有し、
   前記生成部は、取得した前記セットリスト情報に基づいて前記リコメンド情報を生成することを特徴とする請求項１または２記載のサーバ装置。
4. 前記あるライブイベントを行ったアーティストが歌唱する複数の楽曲の中から所定の楽曲を抽出する抽出部を有し、
   前記生成部は、抽出した前記所定の楽曲に基づいて前記リコメンド情報を生成することを特徴とする請求項１または２記載のサーバ装置。
5. 前記あるライブイベントで歌唱された楽曲名及び曲順を含むセットリスト情報を取得する取得部と、
   前記あるライブイベントを行ったアーティストが歌唱する複数の楽曲の中から所定の楽曲を抽出する抽出部と、
   を有し、
   前記生成部は、
   前記取得部により前記セットリスト情報が取得できた場合、取得した前記セットリスト情報に基づいて前記リコメンド情報を生成し、
   前記取得部により前記セットリスト情報が取得できなかった場合、抽出した前記所定の楽曲に基づいて前記リコメンド情報を生成することを特徴とする請求項１または２記載のサーバ装置。
6. 前記生成部は、
   前記情報送信部により、特定した前記参加者の携帯端末に対し、抽出した前記所定の楽曲に基づいて前記リコメンド情報を送信した後、所定時間以内に前記取得部によりセットリスト情報が取得された場合、取得したセットリスト情報に基づいて新たなリコメンド情報を生成し、
   前記情報送信部は、特定した前記参加者の携帯端末に対し、前記新たなリコメンド情報を送信することを特徴とする請求項５記載のサーバ装置。

Images