(57)【要約】【課題】音楽愛好家、音楽家、音楽会場運営者、情報提供会社にあった情報提供とスケジュール調整を可能にする。【解決手段】ＩＣカード等の記録媒体とＩＣカードを読み取るリーダ、端末、ネットワーク、運営会社のサーバを利用することにより音楽愛好家、音楽家、音楽会場運営者、情報提供会社をＷｅｂサイトへのログインはＩＣカード等内の情報を元に属性（音楽愛好家、音楽家  等）を判断し、それぞれのＷｅｂ画面を表示させ、運営会社サーバのデータベース情報を元に人気度の高い音楽家、音楽会場運営者順に表示させ、音楽家、音楽会場運営者間では、それぞれが運営サーバに情報を登録することによりスケジュール調整や出演依頼を実施する。【選択図】  図１
2005031717.tif 000002
【特許請求の範囲】
【請求項１】
音楽家によって操作される音楽家端末およびライブハウスに設置されたライブハウス端末と通信回線を介して接続し、ライブの開催予定に関するライブ予定情報を含むスケジュールＤＢを格納した記憶装置を有する運営会社サーバにおける音楽コミュニティ提供方法であって、
前記運営会社サーバは、
前記ライブハウス端末から、ライブの予定日時に関する日時情報およびライブハウスを識別するライブハウス識別情報とをライブ予定入力要求情報として受信し、
前記ライブ予定情報として当該ライブ予定情報を識別するスケジュール識別情報と前記受信したライブハウス識別情報と日時に関する日時情報と当該ライブ開催予定に関する出演交渉について出演予定の音楽家とライブハウスが未契約であることを示す情報を対応付けて前記スケジュールＤＢに格納し、
前記音楽家端末から受信した未契約情報表示要求に応じて、前記未契約であることを示す情報と対応付けて格納されたライブ予定情報を前記スケジュールＤＢから読出し前記音楽家端末に送信し、
送信したライブ予定情報に基づいて選択されたスケジュール識別情報と前記音楽家を識別する音楽家識別情報とを前記音楽家端末から受信し、
前記スケジュールＤＢに格納したライブ予定情報のうち、前記音楽家端末から受信したスケジュール識別情報に対応するライブ予定情報に契約済であることを示す情報と前記受信した音楽家識別情報とを対応付けて前記スケジュールＤＢに格納することを特徴とする音楽コミュニティ提供方法。
【請求項２】
請求項１記載の音楽コミュニティ提供方法において、
前記運営会社サーバは、
音楽家の識別情報と該音楽家に関する連絡先とを対応付けて予め記憶装置に格納し、
前記受信したライブ予定入力要求情報に応じて、１以上の音楽家の音楽家識別情報からなるリストを前記ライブハウス端末に送信し、
前記送信したリストに含まれる音楽家識別情報を前記ライブハウス端末から受信し、
前記記憶装置に格納された連絡先のうち当該ライブハウスから受信した音楽家識別情報に対応付けられた連絡先によって識別される送信先へ、前記ライブハウス端末から受信したライブハウス識別情報と日時情報とに基づくライブハウス出演依頼情報を送信することを特徴とする音楽コミュニティ提供方法。
【請求項３】
請求項２記載の音楽コミュニティ提供方法において、
前記運営会社サーバは、
音楽家の識別情報を会員ＤＢとして前記記憶装置に格納し、
ライブに出演予定である音楽家の識別情報をそのライブに関する日時情報と対応付けて前記記憶装置に格納し、
前記運営会社サーバが送信する１以上の音楽家識別情報は、
前記ライブハウス端末から受信した日時情報に対応する音楽家の識別情報を前記記憶装置から読出し、
会員ＤＢに含まれる音楽家識別情報のうち、前記読み出した音楽家識別情報を除く音楽家識別情報であることを特徴とする音楽コミュニティ提供方法。
【請求項４】
請求項１ないし請求項３記載の音楽コミュニティ提供方法において、
前記ライブハウス端末は、
操作者の入力を受け付ける入力装置とＩＣカードリーダライタとを有し、
前記入力装置から音楽家識別情報の入力を受付け、
前記ＩＣカードリーダライタから会員を識別する会員識別情報の入力を受け付け、
前記入力された会員識別情報の数を集計し、
前記集計により得た数と前記入力された音楽家の識別情報とを対応付けて前記前記運営会社サーバに送信することを特徴とする音楽コミュニティ提供方法。
【請求項５】
請求項４記載の音楽コミュニティ提供方法において、
前記運営会社サーバが送信した１以上の音楽家識別情報は、前記運営会社サーバが前記ライブハウス端末から受信した、音楽家識別情報ごとに集計により得た数に基づき並べ替えられたものであることを特徴とする音楽コミュニティ提供方法。
【請求項６】
音楽家によって操作される音楽家端末およびライブハウスの従業員によって操作されるライブハウス端末と通信回線を介して接続し、ライブの予定に関する情報を格納するスケジュールＤＢを有する運営会社サーバにおける音楽コミュニティ提供システムであって、
前記運営会社サーバは、
前記ライブハウス端末から、前記ライブハウスを識別するライブハウス識別情報と日時に関する日時情報とを受信し、前記音楽家端末からライブハウス識別情報と日時情報と前記音楽家を識別する音楽家識別情報とを受信する受信手段と、
前記ライブハウス端末から受信したライブハウス識別情報と日時情報とを対応付けるライブ予定情報をスケジュールＤＢとして格納する記憶手段と、
前記スケジュールＤＢに格納されたライブ予定情報のうち、前記音楽家端末から受信したライブハウス識別情報と日時情報とに対応するライブ予定情報を前記受信した音楽家識別情報と対応付けて前記スケジュールＤＢに格納する処理を実行する処理手段とを備えることを特徴とする音楽コミュニティ提供システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、音楽愛好家、音楽家、ライブハウス等の音楽会場提供者、情報提供会社にとって利便性の向上を図った音楽コミュニティ提供システムに関する。
【０００２】
【従来の技術】
一般的な音楽愛好家は各種音楽雑誌等を購入し、ライブスケジュールや音楽家情報を得たり、有名でない音楽家や新人等の情報を得る場合は、ライブハウスへの問合せや友人に問い合わせる等にて情報を得ていた。しかし、営業時間や不在により音楽愛好家、音楽家、音楽会場提供、情報提供会社にとって機会を損失している。
【０００３】
上記の機会の損失を解消する手段の１つとして特許文献１ではＷｅｂシステムにて音楽会場運営者のライブハウスの日程と出演者の楽曲を連動させ、ライブ視聴の予約、楽曲の購入システムを提供することで問題解決を図っている。
【０００４】
【特許文献１】
特開２００２−５６２０６号公報
【０００５】
【発明が解決しようとする課題】
しかし、音楽愛好家への情報提供は実現可能であるが、音楽家や音楽会場運営者間とのスケジュール調整や出演交渉、また、良い音楽家や音楽会場運営者の人気度等、音楽愛好家がほしい情報を提供することはできない。そして、楽曲やライブビデオを提供する際にも複製を禁止するための措置が無い。本発明では、上記問題点を音楽愛好家、音楽家、音楽会場提供者、情報提供会社との間に情報を整理配信する運営会社をたてることにより解決することができ、音楽家や音楽会会場運営者間の交渉時間を削減することや販売機会を増やすことができる。
【０００６】
【課題を解決するための手段】
本発明の一形態は、音楽家によって操作される音楽家端末およびライブハウスに設置されたライブハウス端末と通信回線を介して接続し、ライブの開催予定に関するライブ予定情報を含むスケジュールＤＢを格納した記憶装置を有する運営会社サーバにおける音楽コミュニティ提供方法であって、運営会社サーバは、ライブハウス端末からライブ予定入力を要求する旨の情報を受信し、受信した情報に基づき生成したライブ予定情報をスケジュールＤＢに格納し、音楽家端末から受信した未契約情報表示要求に応じて、ライブ予定情報のうち音楽家と未契約であるライブ予定に関するライブ予定情報を前記スケジュールＤＢから読出し音楽家端末に送信し、送信したライブ予定情報に基づいて選択されたライブ予定情報を識別する情報を音楽家端末から受信し、受信した情報に対応するライブ予定情報に契約済であることを示す情報を対応付けてスケジュールＤＢに格納することを特徴とする音楽コミュニティ提供方法である。
【０００７】
【発明の実施の形態】
本実施の形態の概要を説明する。
ＩＣカード等の記録媒体とＩＣカードを読取るリーダ、端末、ネットワーク、運営会社のサーバで構成される。ＩＣカードは音楽愛好家、音楽家、音楽会場運営者、情報提供会社が保持し、ＷｅｂサイトへのログインはＩＣカード等内の情報を元に属性（音楽愛好家、音楽家  等）を判断する。判断した情報を元に音楽愛好家、音楽家、音楽会場運営者、情報提供会社専用のＷｅｂ画面を表示する。表示されたＷｅｂ画面より音楽愛好家は、音楽家、音楽会場運営者、情報提供会社の情報が表示させることが可能であり、運営会社サーバのデータベース情報を元に人気度の高い音楽家、音楽会場運営者順に表示できる。人気度は、音楽愛好家より投票してもらい投票結果を元に音楽家の人気度を計るデータとし、音楽会場運営者は、投票数と来場者数と宣伝広告費とにより人気度を計るデータとする。音楽家、音楽会場運営者間では、それぞれが運営サーバに情報を登録することによりスケジュール調整や出演依頼をすることが可能である。音楽会場運営者は音楽家が登録した楽曲を元に実力を測るために参考となる情報を得ることが可能な手段が提供される。
【０００８】
以下、本実施形態について、図面を参照しながら詳細に説明する。
【０００９】
以下の説明では、音楽コミュニティ提供システムの一例として、ＩＣカードを利用した音楽コミュニティ提供システムを説明するが、音楽関連以外のコミュニティに対しても適用できることは言うまでもない。また、データベースは必要に応じてＤＢと略記する。
【００１０】
図１に例示されるように、本実施の形態の音楽コミュニティ提供システムは、音楽コミュニティ提供システムの運用をする運営会社とサービス提供契約を結んだ音楽愛好家（以下、会員とする）が操作する端末１００、ＩＣカード読取装置（以下、ＲＷとする）２００、ＩＣカード３００、インターネットなどの通信回線のネットワークである公衆網４００、運営会社で管理するサーバ５００、音楽家の端末６００、音楽会場運営者（以下、ライブハウスとする）内端末７００、情報提供会社８００を備える。また、音楽家の端末６００、音楽会場運営者内端末７００、情報提供会社内端末８００は、ＲＷ２００およびＩＣカード３００を備える。
【００１１】
音楽家端末６００、音楽会場運営者内端末７００、および情報提供会社内端末８００の代表構成を端末１００として図１に示す。端末１００は、情報を処理する処理部１０１と、情報を表示するディスプレイ等の表示部１０２と、キーボード、マウス等の入力部１０３と、情報を保持するメモリ部１０４と、制御用プログラムが入った制御プログラム１０５と、情報の入出力を実施するインターフェース部１０６と、を備えている。
【００１２】
ＩＣカード３００は、情報を処理する処理部３０１と、情報の入出力を実施するインターフェース部３０２と、情報を保持するメモリ部３０３と、制御用プログラムが入った制御プログラム３０４と、を備えている。
【００１３】
ＩＣカード内データ３０３のデータ構成図を図１３に示す。ＩＣカード内データ３０３においては会員Ｎｏ３０３１、氏名３０３２、生年月日３０３３、ＩＣカード所有者の属性３０３４（会員、音楽家、ライブハウス、情報提供会社の別を示す）、ＩＣカードの所有者を認証するためのパスワード３０３、および暗号キー３０３６を対応付けて格納する。暗号キー３０３６については後述する。図中暗号化キーは１つのみ示されているが、ＩＣカード内データ３０３において複数の暗号化キーが格納される場合もある。
【００１４】
運営会社のサーバ５００は、情報を処理する処理部５０１と、情報を表示するディスプレイ等の表示部５０２と、キーボード、マウス等の入力部５０３と、情報を保持するメモリ部５０４と、制御用プログラムが入った制御プログラム５０５と、情報の入出力を実施するインターフェース部５０６と、会員ＤＢ５０７と、スケジュールＤＢ５０８と、デモテープＤＢ５０９と、フレームＤＢ５１１と、ライブ出演ＤＢ５１２と、音楽家ランキングＤＢ５１３と、音楽家ランキングログＤＢ５１４と、ライブハウスランキングＤＢ５１５と、ライブハウスランキングログＤＢ５１６と、来場ログＤＢ５１７と、広告宣伝費ＤＢ５１８と、を備えている。
【００１５】
図１４に会員情報を保持している会員ＤＢ５０７のデータ構成図を示す。会員ＤＢ５０７においては、各会員の会員Ｎｏ５０７１、氏名５０７２、ニックネーム５０７３、郵便番号５０７４、住所５０７５、生年月日５０７６、電話番号５０７７、メールＩＤ５０７８、および属性５０７９を対応付けて格納する。
【００１６】
図１５に示すとおり、ライブハウス等のスケジュール情報を保持しているスケジュールＤＢは、各スケジュールを識別するスケジュールＮｏ５０８１、ライブが行われる日時５０８２、ライブが行われるライブハウスの会員ＮｏであるライブハウスＮｏ５０８３、ライブの出演者である音楽家の会員Ｎｏである出演者Ｎｏ５０８４、ライブの入場料である料金５０８５、およびライブハウスと出演者との出演交渉のステータスを示す出演依頼フラグ５０８６を対応付けて格納する。スケジュールＤＢ５０８の各レコードは、日時５０８２とライブハウスＮｏ５０８３と出演者Ｎｏ５０８４とを含み、ライブ予定を表す情報（以下、ライブ予定情報）である。さらに出演依頼フラグ５０８６を備えるため、ライブに出演する音楽家と出演について同意が取れているか否かの状況を表すことができる。レコードを特定する際には、スケジュールＮｏ５０７１を用いて識別しても良いし、スケジュールＮｏ５０７１を具備しない場合には、日時５０８２とライブハウスＮｏと出演者Ｎｏの複合キーによって識別しても良い。出演依頼フラグはデフォルトでＮｕｌｌであり、ライブハウス内端末からのライブ予定入力により、「契約済」または「未契約」を示す情報が書き込まれる。
【００１７】
図１６に示すとおり、音楽家の楽曲情報（以下、デモテープとする）保持しているデモテープＤＢ５０９は、デモテープを登録した会員の会員Ｎｏ５０９１、デモテープのタイトル５０９２、およびデモテープのコンテンツのデータを識別するファイル名５０９３を対応付けて格納する。
【００１８】
図１７に示すとおり、ライブハウスの映像情報を保持しているライブビデオＤＢ５１０は、ライブの出演者の会員Ｎｏ５１０１、ライブのタイトル５１０２、録画されたライブの映像情報を識別するファイル名１５０３、および暗号化キー５１０４を対応付けて格納する。
【００１９】
図１７に示すとおり、会員、音楽家、ライブハウス、情報提供会社など会員の属性の別によって表示画面を変更するためのフレームＤＢ５１１は、会員の属性５１１１、フレームの格納された場所に対応するＵＲＬ５１１２を格納する。
【００２０】
図１８に示すとおり、ライブハウスから音楽家が音楽家の出演交渉を打診する際に利用するライブ出演ＤＢ５１２は、ライブのスケジュールを識別するスケジュールＮｏ５１２１、ライブへの出演者をの会員Ｎｏである出演者Ｎｏ５１２２、ライブの行われるライブハウスの会員ＮｏであるライブハウスＮｏ５１２３、およびライブハウスと出演者の出演交渉のステータスを示す出演依頼フラグ５１２４を対応付けて格納する。
【００２１】
図２０に示すとおり、音楽家の人気度情報を保持する音楽家ランキングＤＢ５１３は、人気度の計られる音楽家の会員Ｎｏ５１３１および音楽家への会員の人気投票の集計結果である投票数５１３２を対応付けて格納する。
【００２２】
図２０に示すとおり、音楽家の人気度を図るためのログ情報を保持する音楽家ランキングログＤＢ５１４は、投票により人気度を計られる音楽家の会員Ｎｏ５１４１および人気投票をした会員の会員Ｎｏ５１４２を対応付けて格納する。
【００２３】
図２１に示すとおり、ライブハウスの人気度を保持するためのライブハウスランキングＤＢ５１５は、人気度を計られるライブハウスの会員Ｎｏ５１５１、ライブハウスへの人気投票数に基づき算出（定数を乗じるなど）したポイントである投票ポイント５１５２、来場者数に基づき算出（定数を乗じるなど）したポイントである来場者ポイント５１５３、およびライブハウスが運営会社に支払った広告宣伝費に基づき算出（定数を乗じるなど）したポイントである広告宣伝費ポイント５１５４を対応付けて格納する。
【００２４】
図２２に示すとおり、ライブハウスのランキングのログ情報を保持するためのライブハウスランキングログＤＢ５１６は、投票により人気度を計られるライブハウスの会員Ｎｏ５１６１と当該ライブハウスへの投票した会員の会員Ｎｏ５１６２とを対応付けて格納する。
【００２５】
図２３に示すとおり、ライブハウスに来場した人をカウントするための来場ログＤＢ５１７はライブハウスの会員Ｎｏ５１７１、来場者数をカウントされたライブに対応するスケジュールＮｏ５１７２、および来場した会員の会員Ｎｏ５１７３を対応付けて格納する。
【００２６】
図２３に示すとおり、広告宣伝費をランキング情報に反映させるための広告宣伝費ＤＢ５１８は、広告宣伝費を支払ったライブハウスの会員Ｎｏ５１８１と支払った広告宣伝費の金額５１８２を対応付けて格納する。
【００２７】
上記ＤＢの説明においては、本実施の技術を実施する上で各ＤＢに格納される可能性のあるデータを説明したが、全てのデータ項目を備える必要はなく、例えばライブ出演ＤＢ５１２においては出演者ＮｏとライブハウスＮｏとは、スケジュールＮｏに基づいてスケジュールＤＢから取得できる内容であるため、省略可能である。
【００２８】
以下、図２のフローチャートを参照して本実施形態の音楽コミュニティ提供システムの処理手順の一例について説明する。ステップ１ａにてサービス申込みがあった場合は、ステップ１ｂにて入力部５０３にて氏名、生年月日、性別を入力し、会員ＤＢ５０７内の氏名５０７２と生年月日５０７６と性別５０７ａを、ステップ１ｃにて比較し、重複が無ければステップ１ｄに重複があればステップ１ｇの処理を実施する。ステップ１ｄでは、申込書より会員ＤＢ５０７に情報を登録し、同様の内容をＩＣカード３００内のメモリ３０３内に登録し、ステップ１ｅにてＲＷ２００といっしょに送付し、ステップ１ｆで終了する。ステップ１ｇの同一登録がある場合は登録済みと表示部５０２に表示し、申込みのあった会員に連絡する。複数の申込みがある場合は上記処理を繰り返す。また、申込みは紙、電子データ等の媒体は問わないものとする。
【００２９】
図３のフローチャートではログイン処理と表示画面の切り替え処理について説明する。ステップ２ａにてＩＣカード３００がＲＷ２００に挿入されると、ＲＷ２００に接続された音楽家端末などの端末は、ステップ２ｂにてＩＣカード３００のメモリ３０３の会員Ｎｏ３０３１を読み出し、端末は会員Ｎｏ３０３１を運営機関サーバ５００に送信し、運営機関サーバ５００は、ステップ２ｃにて会員かどうかの判断をする。もし属性３０３４が会員を示す情報であれば会員と判断しステップ２ｆへ、会員を示す情報以外であれば、ステップ２ｄへ移る。ステップ２ｆでは、フレームＤＢ５１１内のＵＲＬ５１１２の会員用ＵＲＬを読み込み、ステップ２ｊにて表示部１０２に表示する。ステップ２ｄでは、属性３０３４が音楽家を示す情報であれば音楽家と判断し、ステップ２ｇにてフレームＤＢ５１１内のＵＲＬ５１１２の音楽家用ＵＲＬを読み込み、ステップ２ｊにて表示部１０２に表示する。ステップ２ｄにて属性３０３４が音楽家を示す情報以外であればステップ２ｅにて、属性３０３４がライブハウスを示す情報であればライブハウスと判断し、ステップ２ｈにてフレームＤＢ５１１内のＵＲＬ５１１２のライブハウス用ＵＲＬを読み込み、ステップ２ｊにて表示部１０２に表示する。ステップ２ｅに属性３０３４がライブハウスを示す情報以外であればステップ２ｉにて、情報提供会社と判断し、フレームＤＢ５１１内のＵＲＬ５１１２の情報提供会社用ＵＲＬを読み込み、ステップ２ｊにて表示部１０２に表示する。
【００３０】
ここで端末は会員Ｎｏ３０３１を運営会社サーバ５００に送信するとして説明したが、会員Ｎｏ３０３１と属性３０３４とをＩＣカードから読み出し、運営機関サーバ５００に送信しても良い。この場合、運営会社サーバ５００は受信した属性をキーにフレームＤＢ５１１から各属性に対応するＵＲＬを読出し、端末に送信する。
【００３１】
表示画面の種別について説明する。図２５から図２９に示すような表示画面が会員用ＵＲＬに対応する。ユーザが、表示画面のメニュー部に示された文字列（メニュー項目）をクリックするなど選択したことを端末１００で検知すると、選択されたメニュー項目により異なる要求を端末１００は運営会社５００に送信する。音楽家用ＵＲＬに対応する表示画面は、図２５に示す会員用ＵＲＬに対応する表示画面のメニュー部のメニュー項目に加え、図３０、図３１、および図３２に示すように、メニュー部にメニュー項目「デモテープ登録」、「出演申込」、および「出演依頼状況」を更に備える。ライブハウス用ＵＲＬに対応する表示画面は、図２５に示す会員用ＵＲＬに対応する表示画面のメニュー部のメニュー項目に加え、図３３、および図３４に示すように、メニュー部にメニュー項目「ライブビデオ登録」、「出演依頼」、および「出演申込状況」を更に備える。
【００３２】
以下、表示画面上でマウスやキーボードなどのユーザインタフェースによって行われる共通の操作について説明する。以下の説明中、画面上の項目を選択するとは、これらユーザインタフェースを介したユーザからの指示により、画面上に表示されたハイパーリンクなどの項目の一部を特定することをいう（マウスによる画面上の項目のクリックなど）。
【００３３】
図４のフローチャートでは、ステップ３ａにて図２５の表示画面における音楽家情報のランキング順またはライブハウス情報のランキング順が選択された場合、運営会社サーバ５００にていずれかのランキング情報が選択されたことを受信し、ステップ３ｂにて音楽家のランキング表示要求の場合には、ステップ３ｃにて音楽家ランキングＤＢ５１３に登録されている内容を表示部１０２に表示する。
【００３４】
図２６に音楽家のランキング表示画面を示す。図２６に示す表示画面に表示した氏名は、音楽家ランキングＤＢ５１３から得た会員Ｎｏ５１４１をキーとして会員ＤＢ５０７から得た氏名５０７２である。
【００３５】
ステップ３ｂにてライブハウスのランキング表示要求の場合には、ステップ３ｄにてライブハウスランキングＤＢ５１５に登録されている内容を反映した表示画面を表示部１０２に表示する。表示する内容は、ライブハウスランキングＤＢ５１５の内容そのものを全て出すのではなく、例えば、投票ポイント５１５２、来場者ポイント５１５３、および広告宣伝費ポイント５１５４のそれぞれに係数を乗じることにより重み付けをして足し合わせて得た数によって作成したランキングの順に並べたライブハウス名とすることができる。ここでライブハウス名は、ライブハウスランキングＤＢ５１５の会員Ｎｏ５１５１をキーとして会員ＤＢ５０７から得たニックネーム５０７３である。
【００３６】
なお、ステップ３ｂにて音楽家、ライブハウスを判断するのは、メニュー２８０１に表示されている選択した文字の位置により判断するものである。会員に限らず、音楽家、ライブハウス、情報提供会社での表示画面でも同様な処理を実施するものである。
【００３７】
図５のフローチャートでは、ステップ４ａにて図２５の表示画面のメニュー２８０１の都道府県別情報が選択された場合、ステップ４ｂにて会員ＤＢ５０７内の属性５０７９がライブハウスを示す情報である情報を抜き出し郵便番号５０７４にて並び変え、ステップ４ｃにて住所５０７５とニックネーム５０７３を表示部１０２に表示する。会員に限らず、音楽家の端末６００、ライブハウス内端末７００、情報提供会社８００での表示画面でも同様な処理を実施するものである。
【００３８】
図６のフローチャートでは、ステップ５ａにて図２５の表示画面のメニューのあいうえお順が選択された場合、ステップ５ｂにて音楽家のあいうえお順が選択された場合には、ステップ５ｃにて会員ＤＢ５０７内の属性５０７９が音楽家を示す情報である情報を抜き出しニックネーム５０７３順に並べ替え、ステップ５ｄにて表示部１０２に表示する。ステップ５ｂにてライブハウスのあいうえお順が選択された場合には、ステップ５ｅにて会員ＤＢ５０７内の属性５０７９がライブハウスを示す情報である情報を抜き出し、ニックネーム５０７３順に並べ替え、ステップ５ｆにて表示部１０２に表示する。なお、ステップ５ｂにて音楽家、ライブハウスを判断するのは、図２５のメニューに表示されている選択した文字の位置により判断するものである。会員に限らず、音楽家の端末６００、ライブハウス内端末７００、情報提供会社８００での表示画面でも同様な処理を実施するものである。
【００３９】
図７のフローチャートでは、音楽家のプロフィール情報が選択された場合の処理を示す。ステップ６ａでは、図２６の音楽家のランキング情報の「鈴木次郎」が選択された場合に、ステップ６ｂでは会員ＤＢ５０７の「鈴木次郎」のレコードより氏名５０７２とメールＩＤ５０７８を取得、ステップ６ｃでは、スケジュールＤＢ５０８の出演者Ｎｏ５０８４より「鈴木次郎」に該当する会員Ｎｏの情報を取得、ステップ６ｄでは、デモテープＤＢ５０９より「鈴木次郎」に該当する会員Ｎｏの情報を取得、ステップ６ｅでは、上記６ｂ、６ｃ、６ｄにて取得した情報を図２８のように表示部１０２に表示する。
【００４０】
図８のフローチャートでは、投票情報が選択された場合の処理を示す。ステップ７ａにて投票ボタン３２０１が選択されたとき、ステップ７ｂにてＩＣカード３００内の会員Ｎｏ３０３１と投票する音楽家の会員Ｎｏ５０７１を抜き出し、音楽家ランキングログＤＢ５１４に同一組合せをチェックし、ステップ７ｃにて同一組合せが無い場合は、ステップ７ｄにて音楽家ランキングログＤＢ５１４にＩＣカード３００内の会員Ｎｏ３０３１の情報と音楽家の会員Ｎｏ５０７１の情報を記録し、ステップ７ｅにて例えば１週間毎で音楽家ランキングログＤＢ５１４を会員Ｎｏ毎に集計し、音楽家ランキングＤＢ５１３に集計結果を記録する。ステップ７ｃにて組合せが有る場合は、ステップ７ｆにて表示部１０２に「すでに登録済み」のメッセージを表示する。また、ライブハウスの投票の場合は、上記記載の音楽家ランキングＤＢ５１３はライブハウスランキングＤＢ５１５に、音楽家ランキングログＤＢ５１４はライブハウスランキングログＤＢ５１６を置き換えることにより実現可能となる。
【００４１】
図９のフローチャートでは、ライブハウス端末７００の置かれたライブハウスへの来場者数を数える処理を示す。ステップ８ａでは、ライブハウス内端末７００にＩＣカード挿入を促すメッセージを表示させ、ステップ８ｂにてＩＣカード３００がＩＣカードＲＷ２００に挿入されると、ステップ８ｃにてカード内会員Ｎｏ３０３１を読み取り、ステップ８ｄにてライブハウス内端末７００の来場ログ情報に同一会員Ｎｏがある場合に、ステップ８ｅにてライブハウス内端末７００に「すでに登録済みです」と表示させ、無い場合はステップ８ｆにてライブハウス内端末のログ情報に記録する。ステップ８ｇでは、ライブイベント終了時にログ情報を運営会社のサーバ５００へ、スケジュールＮｏと対応付けて送信し、ライブハウスの端末内の来場ログ情報は削除する。ここでライブハウス内端末７００がログ情報とスケジュールＮｏとを対応付けて送信すると説明したが、ログ情報を送信し、運営会社のサーバ５００が受信したログ情報の送信元に対応する会員Ｎｏと受信日時とをキーとしてスケジュールＤＢ５０８からスケジュールＮｏを特定しても良い。ステップ８ｈではライブハウス内端末７００より送信されてきたデータを来場ログＤＢ５１７へライブハウス会員ＮｏとスケジュールＮｏと来場者の会員Ｎｏを書き込み、来場ログＤＢ５１７に格納されたレコード数をライブハウス毎に集計し、ライブハウスランキングＤＢ５１５のトータル来場者数５１５３のデータに加算し記録する。
【００４２】
図２３に来場ログＤＢ５１７のデータ構成図を示す。来場ログＤＢ５１７においては、ライブハウスの会員Ｎｏ５１７１とスケジュールＮｏ５１７２と会員Ｎｏ５１７３とを対応付けて格納する。
【００４３】
図１０のフローチャートでは、ライブハウスが運営会社５００に広告宣伝費を払うことによりランキング情報表示に反映させる処理を示す。ステップ９ａでは、ライブハウスが運営会社５００に宣伝広告費を払い、ステップ９ｂでは払った広告宣伝費を例えば１０，０００で割った値をポイントとし、ライブハウスランキングＤＢ５１５の広告宣伝費ポイント５１５４のデータに加算する。ただし、割る数は任意の値とする
図１１では、ライブハウス内端末７００から音楽家の端末６００に対して出演交渉の処理をする図を示す。ライブハウス内端末７００の操作者がシステムにログインすると、ライブハウス内端末７００は、会員Ｎｏ３０３１をＩＣカードから読取り、運営会社サーバ５００に送信する。この会員Ｎｏを送信するタイミングは、ログインの前後でも、その他の情報を運営会社サーバ５００に送信するときでも良く、運営会社サーバ５００が、受信した情報の送信元を特定できれば良い。
【００４４】
ライブハウス内端末７００は、ライブ予定の日時、料金の入力を受付け、ライブ予定入力が選択されると、運営会社の運営会社サーバ５００の処理部５０１に、入力された日時の情報と料金の情報とライブ予定入力の処理を要求する旨の情報とを送信する（ステップ１５０１）。運営会社サーバ５００は、受信した情報に基づき、スケジュールＤＢ５０８内のレコードにスケジュールＮｏ５０８１、日時５０８２、ライブハウスＮｏ５０８３、料金５０８５を格納し、スケジュールＤＢ５０８の出演依頼フラグ５０８６に「未契約」を表す情報を格納する。データ格納終了後は、スケジュールＤＢ５１１に格納されたレコードのうちライブハウス内端末７００から受信した日時に対応するレコードのスケジュールＮｏをキーに、ライブ出演ＤＢ５１２からレコードを読み出す。これにより、ライブハウス内端末７００から受信したライブ予定日時に他のライブハウスでライブをする予定の音楽家の会員Ｎｏの一覧が得られる。
【００４５】
運営会社サーバ５００の処理部５０１は、この読み出したレコードに含まれる出演者Ｎｏを含まないレコードを会員ＤＢから読出す。これにより、ライブハウス内端末７００から受信したライブ予定日時に予定が格納されていない音楽家のリストである音楽家一覧が得られる。運営会社サーバ５００は、この音楽家一覧に含まれる音楽家の識別情報（音楽家の名前でも音楽家の会員Ｎｏでもよい）を、音楽家ランキングＤＢ５１３の順番にて並び替え、ライブハウス内端末７００に送信する。ライブハウス内端末７００は、空き日時情報と音楽家の一覧情報を受信し、受信した情報に基づき図３３のようなライブ予定の日時、場所、料金と日時ごとの音楽家の一覧をライブハウス内端末７００の表示部１０２に図３３を表示させる（ステップ１５０２）。
【００４６】
ライブハウス内端末７００は、図３３の依頼ボタン３９０１が押されたことを検知すると、運営会社のサーバ５００の処理部５０１に、押された依頼ボタンに対応する音楽家の会員ＮｏとスケジュールＮｏとを含む出演依頼情報を送信する。運営会社サーバ５００は、受信した音楽家の会員ＮｏとスケジュールＮｏとを対応付けて、ライブ出演ＤＢ５１２に格納し、当該レコードの出演依頼フラグ５１２４に「依頼中」を示す情報を格納する。選択された音楽家の識別情報を図３３の表示画面から削除したものを表示する（ステップ１５０３）。ステップ１５０３にて押された依頼ボタンに対応する音楽家の会員Ｎｏに対応する、会員ＤＢ５０７内のメールＩＤを元に運営会社のサーバ５００の処理部５０１は電子メールなど通知するための手段を用いて出演依頼情報を送信する（ステップ１５０４）。
【００４７】
電子メールには、出演依頼があった旨が記載されている。必ずしも電子メールでなくてもよく、何らかの通信手段により音楽家に対し出演依頼があった旨を伝える出演依頼通知情報であればよい。この出演依頼通知情報には、出演依頼をしたライブハウスの識別情報を含めることもでき、音楽家の端末はこの通知情報に含まれるライブハウス識別情報を運営会社サーバ５００に送信することにより、対応する出演依頼情報を運営会社サーバから受信し、参照することができる。
【００４８】
音楽家の端末６００は、送信されたメールを元に運営会社サーバ５００にログインする。音楽家端末６００は、音楽家用表示画面を表示し、表示画面上の「出演依頼状況」選択されたとき、出演依頼状況を要求する未契約情報要求情報を、運営会社サーバに送信する（ステップ１５０４１）。図３２に示すような、音楽家に対応するページを運営会社サーバ５００から受信し表示部１０２に表示させるために、運営会社サーバ５００の処理部５０１は、ライブ出演ＤＢ５１２のレコードのうち、ログインにおいて受信した音楽家Ｎｏとライブ出演ＤＢ５１２の出演者Ｎｏ５１２２が対応し、出演依頼フラグ５１２４に「依頼中」を示す情報が格納されているものを読み出し一次メモリに格納し、読み出したレコードのスケジュールＮｏをキーにスケジュールＤＢ５０８より対応するライブ予定情報（特にライブハウスＮｏ５０８３と日時情報５０８２）とを読出し、一次メモリに格納しておいたレコードに追加し、ライブハウスランキングＤＢ５１５の順番に並び替えを実施し、音楽家端末６００に送信する（ステップ１５０４２）。
【００４９】
ステップ１５０４２で送信する情報は、スケジュールＤＢ５０８の出演依頼フラグ５０８６に「未契約」を表す情報が格納されているライブ予定情報のうち、スケジュールＮｏによって対応付けられたライブ出演ＤＢ５１２の出演者Ｎｏ５１２２が、ログインにおいて受信した音楽家Ｎｏと対応するものであっても良い。
【００５０】
データベースの構成が本実施例と異なる場合であっても、ログインした音楽家に関するライブ予定情報として、ライブハウスの識別情報と日時情報とを音楽家の会員Ｎｏをキーにデータベースから読出し、音楽家端末６００に送信すれば良い。
【００５１】
音楽家端末６００は、音楽家端末６００の操作者により音楽家に対応するページに表示されたライブハウス名が選択されたことを検知すると、選択されたライブハウス名に対応するライブハウス識別情報を含むライブハウス情報要求を運営会社サーバ５００に送信する（ステップ１５０５）。運営会社サーバ５００は、受信したライブハウス情報要求に対応する会員Ｎｏを持つライブハウスの情報を会員ＤＢ５０７から読出し、音楽家端末６００に送信し、音楽家端末６００は、表示部１０２に図３２のように表示する。（ステップ１５０６）。
【００５２】
音楽家端末６００に表示されたライブハウス情報を操作者が気に入った場合など出演を承諾する場合は、音楽家が図３２の確認ボタン３８０１を選択すると、音楽家端末６００は確認ボタン３８０１が選択されたことを検知し、運営会社のサーバ５００に出演依頼を承諾する旨を示す確認情報を送信する（ステップ１５０７）。確認情報には、対応するスケジュールの識別情報（スケジュールＮｏなど）が含まれ、出演依頼の承認がされたスケジュールを運営会社サーバ５００に通知することができる。
【００５３】
確認情報にさらに音楽家の識別情報（音楽家の会員Ｎｏなど）を含めることもでき、この情報を用いて運営会社サーバ５００は、誰が出演依頼を承認したかを判別可能とできる。運営会社サーバ５００は、選択された確認ボタンに対応するライブ予定情報を除外した表示画面の情報を音楽家端末６００に送信し、音楽家端末６００は、これに基づく画面表示をする。確認情報に音楽家の識別情報を含めない場合、運営会社サーバ５００は、音楽家端末７００のログインにおいて受信した音楽家識別情報を、ステップ１５０１からステップ１５０６までの一連のセッションの間、記憶装置など格納しておき、ステップ１５０６で誰が出演依頼を承認したかを判別しても良い。
【００５４】
音楽家がライブハウスを気に入らなかった場合など、出演を拒否する場合、音楽家が図３２の依頼拒否ボタン３８０２を選択すると、音楽家端末６００は依頼拒否ボタン３８０２が選択されたことを検知し、運営会社サーバ５００に出演依頼を拒否する旨を示す依頼拒否情報を送信する（ステップ１５０７）。
【００５５】
依頼拒否ボタンは、表示画面上に示された複数のライブ予定情報に対し１つ設けてもよいし、ライブ予定情報毎に１つ設けても良い。複数のライブ予定情報に対して依頼拒否ボタンを１つ設ける場合、依頼拒否情報には、画面に表示された依頼承認待ちのライブ予定情報のスケジュール識別情報が含まれる。ライブ予定情報ごとに依頼拒否ボタンを設けた場合、依頼拒否情報には、選択された依頼拒否ボタンに対応するライブ予定情報のスケジュール識別情報が含まれる。
【００５６】
運営会社サーバ５００の処理部５０１は、確認情報を受信すると、受信した確認情報に基づきライブ出演ＤＢ５１２に出演依頼が承認された旨を格納する。具体的には、受信した確認情報に含まれるスケジュール識別情報にライブ出演ＤＢ５１２において対応するレコードの出演依頼フラグ５１２４に「依頼承認」を書き込む。
【００５７】
依頼拒否情報を受信するとライブ出演ＤＢ５１２の出演依頼フラグ５１２４に「依頼拒否」を書き込む処理を行う。具体的には、受信した依頼拒否情報に含まれるスケジュール識別情報をキーにライブ出演ＤＢ５１２の出演依頼フラグ５１２４に「依頼拒否」を示す情報を格納する。
【００５８】
運営会社サーバ５００の処理部５０１は、ライブ出演ＤＢ５１２の同一スケジュールＮｏ５１２１を抜き出し、すべての出演依頼フラグ５１２４が「依頼承認」以外でなければ、出演依頼を承認した音楽家が存在することを意味するので、スケジュールＤＢ５０８の該当するスケジュールＮｏの出演依頼フラグ５０８６に「契約済」を示す情報を書き込む、スケジュールＤＢ更新処理を実施する（ステップ１５０８）。
【００５９】
運営会社サーバ５００は、ライブハウス内端末７００に対し、会員ＤＢ５０７においてライブハウスの会員ＩＤに対応付けられたメールＩＤ５０７８を利用し、音楽家の承認または拒否をライブ出演ＤＢ５１２に登録したことを通知する（ステップ１５０９）。音楽家端末８００に対し、会員ＤＢ５０７のメールＩＤ５０７８を利用し、登録させたことを通知する（ステップ１５１０）。ライブハウス内端末７００における操作者がライブハウス用表示画面の「出演申込状況」を操作すると、ライブハウス内端末７００はライブハウスの会員Ｎｏと出演申込状況を要求する旨の情報とを運営会社サーバ５００に送信する（ステップ１５１１）。
【００６０】
運営会社サーバ５００の処理部５０１は、受信したライブハウスの会員Ｎｏをキーにライブ出演ＤＢ５１２のライブ予定情報を読出して一次メモリに格納し、スケジュールＤＢ５０８の日時５０８２を参照し、現在の日時以前のライブ予定は一次メモリに格納したライブ予定情報から削除し、ライブハウス内端末７００の表示部１０２に出演依頼一覧として表示する。表示するライブ予定情報のうち出演依頼フラグ５１２４が「依頼承認」を示す情報であるライブ予定情報については「承認済」を示す情報を付加し、出演依頼フラグ５１２４が「依頼中」であるライブ予定情報を読み出して「依頼中」を示す情報を付加し、出演依頼フラグ５１２４が「依頼拒否」であるライブ予定情報を読み出して「依頼拒否」を示す情報を付加し、図３４のように表示する（ステップ１５１２）。これによりライブハウス内端末７００における操作者は出演依頼への申込状況一覧を確認できる。
【００６１】
図１２では、音楽家の端末６００からライブハウス内端末７００に対して出演交渉処理をする図を示す。ライブハウス内端末７００の処理部１０１は図３３に示すライブハウス用表示画面（ライブ予定記入画面）でライブ予定を記入するときに依頼ボタン３９０１を操作せずに送信ボタン３９０２が押されたことを検知すると、ライブハウス内端末７００の処理部１０１は、運営センタ５００に、音楽家を特定せず出演者を募集する旨の情報と日時情報とを含むライブ予定入力要求情報を送信する（ステップ１６０１）。ステップ１６０１におけるライブ予定入力要求は、以下の説明のとおり、ステップ１５０３と異なり出演者を特定せずにライブ予定を入力する点で、出演者を募集するための処理を要求する情報（以下、出演者募集情報）である。
【００６２】
運営会社サーバ５００の処理部５０１は、受信した出演者募集情報に基づき、ライブ予定情報として、ライブ予定情報を識別するスケジュールＮｏとライブハウス内端末７００より受信した日時情報とライブハウスの会員Ｎｏとを対応付けてスケジュールＤＢ５０８に格納する。このライブ予定情報の出演依頼フラグに「未契約」を示す情報を書き込む。ライブハウスの会員Ｎｏは、ライブハウス内端末７００のログイン処理のときにライブハウス内端末７００から予め受信しておいたものでもよいし、出演者募集情報に含まれるようにして受信したものであってもよい。
【００６３】
運営会社サーバ５００は、格納したライブ予定情報のスケジュールＮｏをライブ出演ＤＢ５１２に格納し、ライブ出演ＤＢ５１２の出演依頼フラグ５１２４に「依頼中」を示す情報を格納する。出演者Ｎｏ５１２２はこの時点で格納しない。このようにライブ出演ＤＢ５１２において出演依頼フラグ５１２４が「依頼中」で、かつ出演者Ｎｏ５１２２にデータが格納されていないレコードは、出演者を特定せずにライブハウスが出演者を公募中であるライブ予定に対応する。
【００６４】
音楽家の端末６００は、音楽家の端末６００の操作者がＩＣカードをＲＷ２００に挿入しログインすると、ＩＣカードから会員Ｎｏを読取り、運営会社サーバ５００に未契約の情報を表示するよう、未契約情報要求情報を送信する（ステップ１６０２）。ステップ１６０２における未契約情報要求情報は、図１１で説明した出演依頼と異なり、出演者が特定されていないため、出演者の募集状況を要求する情報である。
【００６５】
運営会社サーバ５００は、ライブ出演ＤＢ５１２のレコードのうち、出演者公募中に対応するレコードのスケジュールＮｏに対応するライブ予定情報をスケジュールＤＢ５０８から読出し、読み出したライブ予定情報のライブハウスＮｏごとに、ライブハウスランキングＤＢ５１５の投票ポイント５１５２と来場ポイント５１５３と広告ポイント５１５４を足した合計値を算出し、読み出したライブ予定情報を合計値の上位から順に並べ替え、上位より任意の数のライブ予定情報を音楽家の端末６００に送信し、音楽家の端末６００は、表示部１０２に図３１のように現在申し込み可能なスケジュールを表示させる（ステップ１６０３）。
【００６６】
ステップ１６０３で運営会社サーバ５００は、出演公募中のレコードを読み出すこととしたが、ステップ１６０３で送信する情報は、スケジュールＤＢ５０８の出演依頼フラグ５０８６に「未契約」を表す情報が格納されているライブ予定情報のうち、ライブ予定情報のスケジュールＮｏ５０８１によって対応付けられたライブ出演ＤＢ５１２の出演者Ｎｏ５１２２にデータが格納されていないものであっても良い。
【００６７】
音楽家の端末６００の表示部１０２の図３１の申込みボタン３７０１が押されたことを検知すると、押された申込ボタンに対応するスケジュールＮｏなどスケジュールを識別する情報と音楽家の識別情報（音楽家の会員Ｎｏ）とを運営会社サーバ５００に送信する（ステップ１６０４）。運営会社５００の処理部５０１は、受信したスケジュール識別情報にライブ出演ＤＢ５１２において対応するレコードの出演者Ｎｏに、受信した音楽家の識別情報を、および出演依頼フラグ５１２４に「依頼中」を書き込む処理を実施する。
【００６８】
ライブハウス内端末７００の表示部１０２は、操作者がライブハウス内端末７００にログインすることで、運営会社５００の処理部５０１に未契約情報表示要求情報を送る（ステップ１６０５）。運営会社サーバ５００は受信した未契約情報表示要求情報に応じ、ライブハウス出演ＤＢ５１２の出演フラグ５１２４の「依頼中」の情報を取得し、取得した情報のスケジュールＮｏに基づいてスケジュールＤＢ５０８から対応するライブ予定情報を読み出す。読み出したライブ予定情報を音楽家ランキングＤＢ５１４の上位者より順番に並べ替え、ライブハウス内端末７００に送信する（ステップ１６０６）。ライブハウス内端末７００は、受信した情報をライブハウス内端末７００の表示部１０２に図３４の表示画面を表示させる。
【００６９】
ライブハウス内端末７００は、表示された一覧からいずれかの音楽家が選択されたことを処理部１０２が検知すると、選択された音楽家の会員Ｎｏに基づいて運営会社サーバ５００のデモテープＤＢ５０９の情報を取得し、ライブハウス内端末７００の処理部１０２にて表示と再生する（ステップ１６０７、ステップ１６０８）。ライブハウス内端末７００の表示部１０２の図３４の依頼ボタン４００１が選択されると、そのことを処理部１０２が検知しその旨を運営会社サーバ５００に送信し（ステップ１６０９）、運営会社サーバ５００の処理部５０１は、ライブＤＢ５１２の出演依頼フラグ５１２４に「依頼承認」を書き込む。
【００７０】
運営会社サーバ５００は選択された音楽家の識別情報を削除した表示画面情報をライブハウス内端末７００に送信し、ライブハウス内端末７００は受信した表示画面情報を表示部に表示する。ライブハウス内端末７００の表示部１０２の図３４の確認ボタン４００２が選択された場合、ライブハウス内端末７００は、このことを検知し運営会社サーバ５００にその旨の情報と表示画面上に残ったライブ予定のスケジュールの識別情報（スケジュールＮｏなど）とを送信する（ステップ１６０９）。運営会社サーバ５００の処理部５０１は、受信したスケジュールＮｏに対応するライブ出演ＤＢ５１２のレコードの出演依頼フラグ５１２４に「依頼拒否」を示す情報を書き込む処理をし、スケジュールＤＢ５０８の該当するレコードの出演依頼フラグ５０８６に「契約済」を示す情報を書き込むスケジュールＤＢ更新処理をする（ステップ１６１０）。
【００７１】
出演申込状況一覧の表示の処理は図１１で説明したのと同様に可能である。
【００７２】
本実施例によれば、音楽家に関する情報とライブハウスに関する情報とを運営会社サーバ５００において管理するので、音楽家とライブハウスの間で情報を明示的にやり取りせずとも、互いにスケジュールを確認できる。またライブハウスランキング情報を反映したスケジュールを音楽家に提示し、音楽家ランキング情報を反映したスケジュールをライブハウスに提示可能なので、出演交渉において便宜が図れる。
【００７３】
【発明の効果】
本発明によれば、音楽家とライブハウスの間のスケジュール調整や出演依頼が可能となる。
【図面の簡単な説明】
【図１】本実施例に係るシステム構成を表すブロック図である。
【図２】本実施例に係る会員申込み受付処理手順を表すフローチャート図である。
【図３】本実施例に係るＩＣカード内情報により表示画面を切り替える手順を表すフローチャート図である。
【図４】本実施例に係るランキング別の表示手順を表すフローチャート図である。
【図５】本実施例に係る都道府県別の表示手順を表すフローチャート図である。
【図６】本実施例に係るあいうえお順の表示手順を表すフローチャート図である。
【図７】本実施例に係る音楽家のデモテープ視聴をする手順を表すフローチャート図である。
【図８】本実施例に係るランキングの基礎データとなる投票処理を表すフローチャート図である。
【図９】本実施例に係るライブハウスの来場処理を表すフローチャート図である。
【図１０】本実施例に係るライブハウスの広告宣伝費の処理手順を表すフローチャート図である。
【図１１】本実施例に係るライブハウスから音楽家に対するスケジュール調整の手順を表す処理フロー図である。
【図１２】本実施例に係る音楽家からライブハウスに対するスケジュール調整の手順表す処理フロー図である。
【図１３】本実施例に係るＩＣカード内データ構成図である。
【図１４】本実施例に係る会員ＤＢ構成図である。
【図１５】本実施例に係るスケジュールＤＢ構成図である。
【図１６】本実施例に係るデモテープＤＢ構成図である。
【図１７】本実施例に係るフレームＤＢ構成図である。
【図１８】本実施例に係るライブ出演ＤＢ構成図である。
【図１９】本実施例に係る音楽家ランキングＤＢ構成図である。
【図２０】本実施例に係る音楽家ランキングログＤＢ構成図である。
【図２１】本実施例に係るライブハウスランキングＤＢ構成図である。
【図２２】本実施例に係るライブハウスランキングログＤＢ構成図である。
【図２３】本実施例に係る来場者ログＤＢ構成図である。
【図２４】本実施例に係る広告宣伝費ＤＢ構成図である。
【図２５】本実施例に係るトップページ画面例である。
【図２６】本実施例に係るランキング表示画面例である。
【図２７】本実施例に係る音楽家プロフィール表示画面例である。
【図２８】本実施例に係るライブハウス表示画面例である。
【図２９】本実施例に係る会員情報表示画面例である。
【図３０】本実施例に係るデモテープ登録画面例である。
【図３１】本実施例に係る音楽家の申込み可能なライブハウス画面例である。
【図３２】本実施例に係る音楽家のライブハウスからの依頼とライブハウスに依頼した結果の表示画面例である。
【図３３】本実施例に係るライブハウスの募集入力画面例である。
【図３４】本実施例に係る音楽家からライブハウスへの出演依頼と出演同意の表示画面例である。
【符号の説明】
１００：会員端末、１０１：処理部、１０２：表示部、１０３：入力部、１０４：メモリ、１０５：制御プログラム、１０６：インターフェース部、２００：ＩＣカード読書装置、３００：ＩＣカード、３０１：処理部、３０２：インターフェース部、３０３：メモリ、３０４：制御プログラム、４００：公衆網、５００：運営会社サーバ、５０１：処理部、５０２：表示部、５０３：入力部、５０４：メモリ、５０５：制御プログラム、５０６：インターフェース部、５０７：会員ＤＢ、５０８：スケジュールＤＢ、５０９：デモテープＤＢ、５１１：フレームＤＢ、５１２：ライブ出演ＤＢ、５１３：音楽家ランキングＤＢ、５１４：音楽家ランキングログＤＢ、５１５：ライブハウスランキングＤＢ、５１６：ライブハウスランキングログＤＢ、５１７：来場ログＤＢ、５１８：広告宣伝費ＤＢ、６００：音楽家端末、７００：ライブハウス端末、８００：情報提供会社端末
【図１】
2005031717.tif 000003
【図２】
2005031717.tif 000004
【図３】
2005031717.tif 000005
【図４】
2005031717.tif 000006
【図５】
2005031717.tif 000007
【図６】
2005031717.tif 000008
【図７】
2005031717.tif 000009
【図８】
2005031717.tif 000010
【図９】
2005031717.tif 000011
【図１０】
2005031717.tif 000012
【図１１】
2005031717.tif 000013
【図１２】
2005031717.tif 000014
【図１３】
2005031717.tif 000015
【図１４】
2005031717.tif 000016
【図１５】
2005031717.tif 000017
【図１６】
2005031717.tif 000018
【図１７】
2005031717.tif 000019
【図１８】
2005031717.tif 000020
【図１９】
2005031717.tif 000021
【図２０】
2005031717.tif 000022
【図２１】
2005031717.tif 000023
【図２２】
2005031717.tif 000024
【図２３】
2005031717.tif 000025
【図２４】
2005031717.tif 000026
【図２５】
2005031717.tif 000027
【図２６】
2005031717.tif 000028
【図２７】
2005031717.tif 000029
【図２８】
2005031717.tif 000030
【図２９】
2005031717.tif 000031
【図３０】
2005031717.tif 000032
【図３１】
2005031717.tif 000033
【図３２】
2005031717.tif 000034
【図３３】
2005031717.tif 000035
【図３４】
2005031717.tif 000036