(57)【要約】【課題】  イベントを開催する際のリスクを軽減する事など。【解決手段】  処理手段が、（１）受信したイベント開催希望条件を、イベント開催希望条件ファイルに記憶させ、（２）イベント開催希望条件ファイルのうち、アーティストＩＤとエリアＩＤとイベント開催日との値が一致するレコードにおける希望チケット枚数の値を合算し、（３）合算した希望チケット枚数の値が、アーティストマスタファイルにおける（２）のアーティストＩＤの値に関連付いている最低観客数の値以上であり、かつ、（２）のイベント開催日の値が表すイベント開催日が、システム日付情報の値が表す日付よりも後の日であるか、を判定し、（４）判定条件を満たした場合に、（２）のアーティストＩＤとエリアＩＤとイベント開催日との値に、（２）の希望チケット枚数の値を予定チケット枚数の値として関連付け、イベント開催情報ファイルに記憶させる、イベント開催支援システム。【選択図】図９
2007316975.tif 000002
【特許請求の範囲】
【請求項１】
情報を記憶する記憶手段と、情報を処理する処理手段と、利用者からの命令を受け付ける通信手段とを備えたコンピュータシステムであり、アーティストのライブやコンサート、個展、映画の上映、演芸の上演、演劇の上演などの各種イベントの開催を支援するイベント開催支援システムであって、
前記記憶手段は、
アーティスト個人又はアーティストグループを識別するアーティストＩＤと、イベント開催を希望する地域を表すエリアＩＤと、イベント開催を希望する日を表すイベント開催日と、希望する入場チケット枚数を表す希望チケット枚数と、を関連付けて格納するイベント開催希望条件ファイルと、
前記アーティストＩＤと、当該アーティストがイベントを開催する場合の最低限の予定販売チケット枚数を表す最低観客数と、を関連付けて格納するアーティストマスタファイルと、
前記アーティストＩＤと、前記エリアＩＤと、前記イベント開催日と、イベントを開催した場合の予定販売チケット枚数を表す予定チケット枚数と、を関連付けて格納するイベント開催情報ファイルと、
現在の日付を表すシステム日付情報と、を記憶し、
前記処理手段が、
（１）前記アーティストＩＤと前記エリアＩＤと前記イベント開催日と前記希望チケット枚数とを含んだイベント開催希望条件を、前記通信手段を介して利用者システムから受信し、当該受信したイベント開催希望条件を、前記記憶手段の前記イベント開催希望条件ファイルに記憶させること、
（２）前記記憶手段に記憶されたイベント開催希望条件ファイルのうち、アーティストＩＤとエリアＩＤとイベント開催日との値が一致する論理レコードにおける希望チケット枚数の値を合算すること、
（３）当該合算した希望チケット枚数の値が、前記記憶手段に記憶されたアーティストマスタファイルにおける前記（２）で使用したアーティストＩＤの値に関連付いている最低観客数の値以上であり、かつ、前記（２）で使用したイベント開催日の値が表すイベント開催日が、前記記憶手段に記憶されたシステム日付情報の値が表す日付よりも後の日であるか、を判定すること、
（４）当該（３）の判定条件を満たした場合に、前記（２）で使用したアーティストＩＤとエリアＩＤとイベント開催日との値に、前記（２）で合算した希望チケット枚数の値を前記予定チケット枚数の値として関連付けて、前記記憶手段のイベント開催情報ファイルに記憶させること、
を特徴とするイベント開催支援システム。
【請求項２】
情報を記憶する記憶手段と、情報を処理する処理手段と、利用者からの命令を受け付ける通信手段とを備えたコンピュータシステムであり、アーティストのライブやコンサート、個展、映画の上映、演芸の上演、演劇の上演などの各種イベントの開催を支援するイベント開催支援システムであって、
前記記憶手段は、
アーティスト個人又はアーティストグループを識別するアーティストＩＤと、イベント開催を希望する地域を表すエリアＩＤと、イベント開催を希望する日を表すイベント開催日と、希望する入場チケット枚数を表す希望チケット枚数と、を関連付けて格納するイベント開催希望条件ファイルと、
１つの前記エリアＩＤをキー項目とし、１つ以上の前記エリアＩＤを関連付けて格納する開催エリア近接ファイルと、
１つの前記イベント開催日をキー項目とし、１つ以上の前記イベント開催日を関連付けて格納する類似開催日ファイルと、を記憶し、
前記処理手段が、
（１）前記アーティストＩＤと前記エリアＩＤと前記イベント開催日と前記希望チケット枚数とを含んだイベント開催希望条件を、前記通信手段を介して利用者システムから受信すること、
（２）前記記憶手段の開催エリア近接ファイルのうち、当該受信したイベント開催希望条件に含まれるエリアＩＤの値と同じキー項目の値に関連付いている１つ以上の前記エリアＩＤの値を特定し、
前記記憶手段の類似開催日ファイルのうち、当該受信したイベント開催希望条件に含まれるイベント開催日の値と同じキー項目の値に関連付いている１つ以上の前記イベント開催日の値を特定すること、
（３）前記記憶手段に記憶されたイベント開催希望条件ファイルのうち、前記受信したイベント開催希望条件に含まれるアーティストＩＤとエリアＩＤとイベント開催日との値が一致する論理レコードにおける希望チケット枚数の値を合算し、当該合算した希望チケット枚数の値を当該アーティストＩＤとエリアＩＤとイベント開催日との値の組み合わせに関連付けて、前記通信手段を介して利用者システムに送信すること、
（４）前記記憶手段に記憶されたイベント開催希望条件ファイルのうち、前記受信したイベント開催希望条件に含まれるアーティストＩＤと前記（２）で特定したエリアＩＤと前記（２）で特定したイベント開催日との値の組み合わせごとに、関連付いている希望チケット枚数の値を合算し、当該合算した希望チケット枚数の値を、当該アーティストＩＤとエリアＩＤとイベント開催日との値の組み合わせごとに関連付けて、前記通信手段を介して利用者システムに送信すること、
を特徴とするイベント開催支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アーティストのライブやコンサート、個展、映画の上映、演芸の上演、演劇の上演などの各種イベントの開催を支援するイベント開催支援システムに関するものである。
【背景技術】
【０００２】
従来から、各種イベントを開催する際は、イベント主催者が、イベントの主体となるアーティストとイベント内容を決定し、公衆にイベント内容を告知し、チケットを販売し、当日のイベントを迎えるという手順が一般的である。ここでいうアーティストとは、歌手、演奏家、手品師、芸人などを含む広い意味である。
【０００３】
なお、本出願に関係する先行文献を、本出願人は特に知らない。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、従来のイベント開催方法では、チケットを購入する購入者の予想が困難であり、イベントの内容を決定した時点で、ある程度のコスト予想はできるものの、チケット販売の売り上げ予想が非常に困難であった。
【０００５】
これにより、イベント開催者としては、イベント開催が失敗に終わった場合のコスト負担を常に念頭におく必要があった。また、イベントで主役となるアーティストにとっても、知名度が高くなり、イベントを開催した場合に集客が期待できる前においては、中々イベントを開催することができないという不都合が生じる。さらに、集客があまり期待できない地方等では、イベント開催の頻度がどうしても抑制気味になってしまうという不都合も生じ、地方等に在住する者は、イベント参加のためにイベントが開催される都会へ移動する負担がかかった。
【課題を解決するための手段】
【０００６】
１、  そこで、上記課題を解決するため、本発明に係るイベント開催支援システムは、情報を記憶する記憶手段と、情報を処理する処理手段と、利用者からの命令を受け付ける通信手段とを備えたコンピュータシステムであり、アーティストのライブやコンサート、個展、映画の上映、演芸の上演、演劇の上演などの各種イベントの開催を支援するイベント開催支援システムである。
【０００７】
また、当該イベント開催支援システムの前記記憶手段は、アーティスト個人又はアーティストグループを識別するアーティストＩＤと、イベント開催を希望する地域を表すエリアＩＤと、イベント開催を希望する日を表すイベント開催日と、希望する入場チケット枚数を表す希望チケット枚数と、を関連付けて格納するイベント開催希望条件ファイルと、前記アーティストＩＤと、当該アーティストがイベントを開催する場合の最低限の予定販売チケット枚数を表す最低観客数と、を関連付けて格納するアーティストマスタファイルと、前記アーティストＩＤと、前記エリアＩＤと、前記イベント開催日と、イベントを開催した場合の予定販売チケット枚数を表す予定チケット枚数と、を関連付けて格納するイベント開催情報ファイルと、現在の日付を表すシステム日付情報と、を記憶する。
【０００８】
そして、当該イベント開催支援システムの前記処理手段が、（１）前記アーティストＩＤと前記エリアＩＤと前記イベント開催日と前記希望チケット枚数とを含んだイベント開催希望条件を、前記通信手段を介して利用者システムから受信し、当該受信したイベント開催希望条件を、前記記憶手段の前記イベント開催希望条件ファイルに記憶させること、（２）前記記憶手段に記憶されたイベント開催希望条件ファイルのうち、アーティストＩＤとエリアＩＤとイベント開催日との値が一致する論理レコードにおける希望チケット枚数の値を合算すること、（３）当該合算した希望チケット枚数の値が、前記記憶手段に記憶されたアーティストマスタファイルにおける前記（２）で使用したアーティストＩＤの値に関連付いている最低観客数の値以上であり、かつ、前記（２）で使用したイベント開催日の値が表すイベント開催日が、前記記憶手段に記憶されたシステム日付情報の値が表す日付よりも後の日であるか、を判定すること、（４）当該（３）の判定条件を満たした場合に、前記（２）で使用したアーティストＩＤとエリアＩＤとイベント開催日との値に、前記（２）で合算した希望チケット枚数の値を前記予定チケット枚数の値として関連付けて、前記記憶手段のイベント開催情報ファイルに記憶させること、を特徴とする。
【０００９】
（２）  ここで、「記憶手段」とは、例えばＲＡＭ、ＲＯＭ、ＨＤＤ等のコンピュータシステムにおける記憶装置が該当する。「処理手段」とは、例えばＣＰＵ等のコンピュータシステムにおける演算装置や、通信ネットワークで接続されたコンピュータシステムにおける中央処理サーバコンピュータが該当する。「通信手段」とは、例えば、ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）等の他のコンピュータシステム（携帯電話、携帯情報端末、パーソナルコンピュータなど）と通信するための装置が該当する。この「イベント開催支援システム」は、通信ネットワークで接続されたコンピュータシステムにおいて、「処理手段」は中央処理サーバコンピュータ、「記憶手段」は中央処理サーバコンピュータが管理する記憶装置、「通信手段」は中央処理サーバコンピュータが他のコンピュータシステム（携帯電話、携帯情報端末、パーソナルコンピュータなど）と通信するための通信装置、のように複数のコンピュータにより構成される場合もある。
【００１０】
「イベント開催希望条件ファイル」は、アーティストＩＤ、希望チケット枚数、エリアＩＤ、イベント開催日、の各フィールドを関連付けて１つの論理レコードとして格納するファイル又はＤＢである。「アーティストマスタファイル」は、アーティストＩＤ、最低観客数、の各フィールドを関連付けて１つの論理レコードとして格納するファイル又はＤＢである。「イベント開催情報ファイル」は、アーティストＩＤ、エリアＩＤ、イベント開催日、予定チケット枚数、の各フィールドを関連付けて１つの論理レコードとして格納するファイル又はＤＢである。「システム日付情報」は、例えば「２００６０６０１」のようにして、現在の日付をシステムとして特定するための情報であり、一定の時期に正しい日付情報が設定されると、システムの処理手段が自動的に時間の経過を計算し、システム日付を更新していくように構成されている。
【００１１】
「利用者システム」は、本発明に係るイベント開催支援システムをサーバコンピュータとした場合に、携帯電話、携帯情報端末、パーソナルコンピュータなどのクライアントコンピュータシステムとなるシステムを意味し、本発明に係るイベント開催支援システムと通信ネットワークにより接続している。「アーティストＩＤとエリアＩＤとイベント開催日との値が一致する論理レコードにおける希望チケット枚数の値を合算する」とは、アーティストＩＤとエリアＩＤとイベント開催日との値の組み合わせをキー項目として、各々の論理レコードにおける希望チケット枚数の値を合算することを意味する。「前記（２）で使用したアーティストＩＤの値」とは、（２）ステップにおけるキー項目の一部として使用したアーティストＩＤの値をいい、「前記（２）で使用したイベント開催日の値」とは、（２）ステップにおけるキー項目の一部として使用したイベント開催日の値をいう。
【００１２】
以上の定義は、以下の発明にも適用される。
【００１３】
（３）  本発明を利用すると、利用者システムから受信したイベント開催希望条件を継続的にイベント開催希望条件ファイルに格納し、一定のタイミングで、イベント開催希望条件ファイルのうち、アーティストＩＤとエリアＩＤとイベント開催日との値が一致する論理レコードにおける希望チケット枚数の値を合算する。そして、合算した値が、アーティストが希望する最低観客数の値以上であり、かつ、イベント開催日が現在日よりも後の日であれば、イベントを開催するのに必要なイベント開催情報ファイルが記憶手段に記憶される。
【００１４】
イベント主催者としては、記憶手段に記憶されたイベント開催情報ファイルを元に、イベントに呼ぶアーティスト、イベント開催エリア、イベント開催日、を特定することができるため、リスクを減らしつつイベント開催を行うことが可能である。また、アーティストが希望する最低観客数の値以上でなければ、イベント開催情報ファイルが作成されないため、収益性の観点だけでなく、アーティストの希望する観客数がイベント開催の可否に反映されるという効果を有し、アーティスト自身の満足を高める結果となる。これまでは、主催者やアーティストといった提供する側が主体となってイベントの内容（日や地域）を決定することがほとんどであったのに対し、当システムを使うと、観客の側がイベントに対する自分たちの希望を登録しそれによってイベントが企画されることとなり、観客主導によるイベント内容の決定が促進される環境が構築される。本発明により、イベント開催情報ファイルが記憶手段に格納されたことをもって、イベント開催を本決定としてもよいし、イベント実施を一旦仮決定として、イベント主催者による更なる判断（開催実施か否か）を経る構成としてもよい。
【００１５】
２、  また、他の発明に係るイベント開催支援システムは、情報を記憶する記憶手段と、情報を処理する処理手段と、利用者からの命令を受け付ける通信手段とを備えたコンピュータシステムであり、アーティストのライブやコンサート、個展、映画の上映、演芸の上演、演劇の上演などの各種イベントの開催を支援するイベント開催支援システムである。
【００１６】
当該イベント開催支援システムの前記記憶手段は、アーティスト個人又はアーティストグループを識別するアーティストＩＤと、イベント開催を希望する地域を表すエリアＩＤと、イベント開催を希望する日を表すイベント開催日と、希望する入場チケット枚数を表す希望チケット枚数と、を関連付けて格納するイベント開催希望条件ファイルと、１つの前記エリアＩＤをキー項目とし、１つ以上の前記エリアＩＤを関連付けて格納する開催エリア近接ファイルと、１つの前記イベント開催日をキー項目とし、１つ以上の前記イベント開催日を関連付けて格納する類似開催日ファイルと、を記憶する。
【００１７】
そして、当該イベント開催支援システムの前記処理手段が、（１）前記アーティストＩＤと前記エリアＩＤと前記イベント開催日と前記希望チケット枚数とを含んだイベント開催希望条件を、前記通信手段を介して利用者システムから受信すること、（２）前記記憶手段の開催エリア近接ファイルのうち、当該受信したイベント開催希望条件に含まれるエリアＩＤの値と同じキー項目の値に関連付いている１つ以上の前記エリアＩＤの値を特定し、前記記憶手段の類似開催日ファイルのうち、当該受信したイベント開催希望条件に含まれるイベント開催日の値と同じキー項目の値に関連付いている１つ以上の前記イベント開催日の値を特定すること、（３）前記記憶手段に記憶されたイベント開催希望条件ファイルのうち、前記受信したイベント開催希望条件に含まれるアーティストＩＤとエリアＩＤとイベント開催日との値が一致する論理レコードにおける希望チケット枚数の値を合算し、当該合算した希望チケット枚数の値を当該アーティストＩＤとエリアＩＤとイベント開催日との値の組み合わせに関連付けて、前記通信手段を介して利用者システムに送信すること、（４）前記記憶手段に記憶されたイベント開催希望条件ファイルのうち、前記受信したイベント開催希望条件に含まれるアーティストＩＤと前記（２）で特定したエリアＩＤと前記（２）で特定したイベント開催日との値の組み合わせごとに、関連付いている希望チケット枚数の値を合算し、当該合算した希望チケット枚数の値を、当該アーティストＩＤとエリアＩＤとイベント開催日との値の組み合わせごとに関連付けて、前記通信手段を介して利用者システムに送信すること、を特徴とする。
【００１８】
（２）  ここで、「１つの前記エリアＩＤをキー項目とし、１つ以上の前記エリアＩＤを関連付けて格納する」とは、特定のエリアＩＤの値を検索キー項目とした場合に、関連付いている１つ以上のエリアＩＤの値を特定できるデータ構造になっているということを意味する。「１つ以上の前記イベント開催日を関連付けて格納する」も同義である。
【００１９】
「前記受信したイベント開催希望条件に含まれるアーティストＩＤと前記（２）で特定したエリアＩＤと前記（２）で特定したイベント開催日との値の組み合わせごとに、関連付いている希望チケット枚数の値を合算し、当該合算した希望チケット枚数の値を、当該アーティストＩＤとエリアＩＤとイベント開催日との値の組み合わせごとに関連付け」とは、受信したイベント開催希望条件に含まれるアーティストＩＤの値と、（２）ステップで特定したエリアＩＤの値と、（２）ステップで特定したイベント開催日の値との組み合わせを複数作成し、前記記憶手段に記憶されたイベント開催希望条件ファイルのうち、当該値の組み合わせごとをキー項目として関連付いている希望チケット枚数の値を合算して、当該キー項目とした値の組み合わせに関連付けることをいう。この「値との組み合わせを複数作成」する際には、値の全ての組み合わせを作成する必要は必ずしもなく、例えば、作成できる値の組み合わせのうちランダムに半分に決定することや、作成できる値の組み合わせのうち一定の数に減らす事などを行ってもよい。
【００２０】
以上の定義は、以下の発明にも適用される。
【００２１】
（３）  本発明を利用すると、利用者システムから受信したイベント開催希望条件に含まれるアーティストＩＤとエリアＩＤとイベント開催日との値と一致する、イベント開催希望条件ファイルにおける希望チケット枚数の値を合算する。そして、合算した値を当該アーティストＩＤとエリアＩＤとイベント開催日との値に関連付けて、利用者システムに送信する。また、利用者システムから受信したイベント開催希望条件に含まれるエリアＩＤの値に関連付いている他のエリアＩＤの値を特定し、利用者システムから受信したイベント開催希望条件に含まれるイベント開催日の値に関連付いている他のイベント開催日の値を特定する。そして、利用者システムから受信したイベント開催希望条件に含まれるアーティストＩＤの値と、特定したエリアＩＤの値と、特定したイベント開催日の値との組み合わせについて、イベント開催希望条件ファイルにおける希望チケット枚数の値を合算し、アーティストＩＤの値とエリアＩＤの値とイベント開催日の値に関連付けて、利用者システムに送信する。
【００２２】
これにより、利用者システムから受信したイベント開催希望条件に基づく現状の希望チケット枚数の合算値を提供すると共に、利用者システムから受信したイベント開催希望条件に近似する条件（近接エリア、類似のイベント開催日）での現状の希望チケット枚数の合算値を提供することができる。よって、例えば、利用者が最初に希望したイベント開催の希望条件における希望チケット枚数の合算値があまりに少なく、開催の実現が危ぶまれる場合であっても、最初に希望したイベント開催の希望条件に近似する条件での希望チケット枚数の合算値も併せて表示することができるため、開催の実現性の高い近似する条件を選択して変更することができる。これは、イベントの成立可能性を高めることになり、イベント主催者、アーティスト、イベント参加者のいずれにとっても満足を高める結果となる。
【発明を実施するための最良の形態】
【００２３】
以下、本発明の実施形態を、図面を参照しつつ説明する。
【００２４】
１、  本発明の実施の構成について
【００２５】
（１）  本発明に係るイベント開催支援システムは、携帯電話、携帯情報端末やパーソナルコンピュータ等である利用者システムと通信するための通信手段と、中央処理サーバとしてのコンピュータである処理手段と、当該中央処理サーバが管理するＨＤＤやメモリ等の記憶装置である記憶手段と、から構成されている。本発明に係るイベント開催支援システムと携帯電話、携帯情報端末やパーソナルコンピュータ等の利用者システムとは、通信ネットワークやインターネット等の通信回線を介して接続している。本発明に係るイベント開催支援システムの通信手段として、例えば、ＮＩＣ等の通信インターフェース装置が該当する。
【００２６】
（２）  次に、本発明に係るイベント開催支援システムの中央処理サーバとしてのコンピュータである処理手段が管理する、ＨＤＤやメモリ等の記憶装置である記憶手段に記憶されている各種情報について説明する。図９に図示するように、記憶手段であるＨＤＤには、会員マスタ、アーティストマスタ、エリア別アーティストマスタ、アーティスト予定、エリアマスタ、イベント開催希望条件、イベント開催情報、開催エリア近接、類似開催日、という各情報を、ファイルやデータベースの形式により記憶している。
【００２７】
また、本発明に係るイベント開催支援システムの記憶手段であるＨＤＤには、本発明に係るイベント開催支援処理を行うためのコンピュータプログラムや、ＯＳ等の各種コンピュータプログラムも記憶されている。さらに、イベント開催支援システムの記憶手段であるＨＤＤには、現在の日付を表すシステム日付情報と、当該システム日付情報を更新していくコンピュータプログラムも記憶されている。
【００２８】
そして、本発明に係るイベント開催支援システムの処理手段が、記憶手段としてのＨＤＤに記憶されている各情報やコンピュータプログラムを、記憶手段としてのメモリに読み込むことにより、プログラムやデータの解釈・実行を行なう。また、処理手段としてのコンピュータが、記憶手段に記憶されているＯＳ・その他プログラムと、イベント開催支援プログラムを解釈し、実行する事により、本発明に係るイベント開催支援処理が行なわれるのである。
【００２９】
（３）  続いて、記憶装置である記憶手段に記憶されている各情報について、図９を使用して説明する。図９の論理レコードにおける斜線の項目は、各ファイル又はＤＢの検索キー項目を表している。
【００３０】
「会員マスタ」は、「会員ＩＤ」を検索キー項目としたファイル又はＤＢであり、パスワード、会員登録年月日、氏名、メールアドレス、決済情報、チケット送付先住所、の各項目を有し、本発明に係るイベント開催支援システムを利用する会員（チケット購入予定者）に関する情報を格納する。
【００３１】
会員ＩＤは、個々の会員を識別するために、記号・番号の組み合わせなどから構成される情報を格納する項目である。パスワードは、アクセスしているのが本当に当該会員ＩＤの会員であるかを認証するために、記号・番号の組み合わせなどから構成される情報を格納する項目である。このパスワードの認証情報は、バイオメトリック認証に使用する情報（指紋、顔画像、目の虹彩、血管形状のデータなど）を格納してもよい。決済情報とは、例えば、クレジットカードの認証情報や、料金引き落とし口座の銀行名及び口座種類・番号、などの各種決済情報を格納する項目である。
【００３２】
「アーティストマスタ」は、「アーティストＩＤ」を検索キー項目としたファイル又はＤＢであり、アーティスト名、集計タイミング条件、最低観客数、最大限度観客数、仮・確定区分、キャンセル予想率、の各項目を有し、イベントを開催するために本発明に係るイベント開催支援システムを利用するアーティスト（イベントを行うアーティスト）に関する情報を格納する。
【００３３】
アーティストＩＤは、個々のアーティストを識別するために、記号・番号などから構成される情報を格納する項目である。集計タイミング条件とは、当該アーティストに関するイベント開催希望条件を集計するタイミングに関する情報を格納する項目であり、例えば、イベント開催日まで一定の期間しかなくなった日に１回集計、イベント開催日の３ヶ月前から２ヶ月前まで１日に１回集計、イベント開催日の６ヶ月前から１ヶ月前まで１週間に１回集計、などの情報を格納する。最低観客数とは、当該アーティストがイベントを開催する場合の最低限の予定販売チケット枚数（最低観客数）を表す情報を格納する項目である。最大限度観客数とは、当該アーティストがイベントを開催する場合の最大限の予定販売チケット枚数（最大観客数）を表す情報を格納する項目である。仮・確定区分とは、イベント開催をシステムが確定して決定するか、それともアーティスト自身又はイベント主催者がイベント開催の最終決定をするか、を表す情報を格納する項目である。キャンセル予想率とは、当該アーティストがイベントを開催する場合に販売が予想されるチケット枚数のうち、キャンセルが予想される率の情報を格納する項目である。
【００３４】
「エリア別アーティストマスタ」は、「アーティストＩＤ」と「エリアＩＤ」の組み合わせを検索キー項目としたファイル又はＤＢであり、エリア別最低観客数、エリア別最大限度観客数、エリア別仮・確定区分、エリア別キャンセル予想率、の各項目を有し、エリア別に細分化されたアーティストに関する情報を格納する。
【００３５】
エリアＩＤは、イベントが開催される地域を識別するために、記号・番号などから構成される情報を格納する項目であり、例えば、行政における市区町村の１つ又は複数単位（〜市、〜町、東京２３区など）、都道府県の１つ又は複数単位（東京都、関東、北海道など）、などを表す情報を格納する。エリア別最低観客数は、エリア別における最低観客数を格納する項目である。エリア別最大限度観客数は、エリア別における最大限度観客数を格納する項目である。エリア別仮・確定区分は、エリア別における仮・確定区分を格納する項目である。エリア別キャンセル予想率は、エリア別におけるキャンセル予想率を格納する項目である。これらのエリア別項目を有することにより、特定のアーティストのそれぞれのエリア（イベント開催地域）ごとにおける、細やかな設定及び処理が可能となる。
【００３６】
「アーティスト予定」は、「アーティストＩＤ」と「エリアＩＤ」と「イベント開催日」の組み合わせを検索キー項目としたファイル又はＤＢであり、開催可否、の項目を有し、アーティストの特定の地域における特定日のイベント開催に関する情報を格納する。
【００３７】
イベント開催日とは、イベントが開催される日を識別するために、数字や記号の組み合わせなどから構成される情報を格納する項目である。
【００３８】
「エリアマスタ」は、「エリアＩＤ」を検索キー項目としたファイル又はＤＢであり、エリア名称、エリア別最大限度観客数、の各項目を有し、イベントが開催される地域に関する情報を格納する。
【００３９】
エリア別最大限度観客数は、エリア別における最大限度観客数を格納する項目であり、「エリア別アーティストマスタ」におけるエリア別最大限度観客数は、個々のアーティストが内容を決定する項目であるのに対し、「エリアマスタ」におけるエリア別最大限度観客数は、アーティストに関係なく、エリアに共通の値として格納されている。
【００４０】
「イベント開催希望条件」は、「会員ＩＤ」と「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」の組み合わせを検索キー項目としたファイル又はＤＢであり、登録年月日、更新年月日、希望チケット枚数、購入希望度、当選状態、キャンセル区分、の各項目を有し、特定の会員が希望するイベントの内容に関する情報を格納する。
【００４１】
登録年月日、更新年月日は、それぞれイベント開催希望条件の情報が登録された年月日と情報が更新された年月日の情報を格納する項目である。希望チケット枚数は、会員が希望する入場チケット枚数を表す情報を格納する項目である。購入希望度は、会員の希望した内容のイベントが実現した場合に、希望した入場チケット枚数を購入したいという希望度合いを表す情報を格納する項目であり、例えば、決まったら必ずいく、イベント開催が決まったら行くかどうか検討する、イベント開催が決まったら行くかどうか当選したその時点で判断したい、などを表す情報を格納する。当選状態は、イベント開催希望条件の入力から、当該条件の対象となるイベント開催の成立又は不成立までの進行状況や、当該条件が対象とするイベントが成立（あるいは仮決定）した場合に、当該条件を登録した利用者が当該条件の対象となるイベントについて、入力したとおりにチケットを購入できるかどうかを当選あるいははずれとして表す情報を格納する項目である。例えば、「入力期日前」かつ「集計開始前」、「入力期日前」かつ「集計期間中」かつ「イベント開催はまだ成立していない」、「入力期日前」かつ「集計期間中」かつ「イベント開催が成立した（あるいは仮決定）」かつ「参加者抽選前」、「入力期日到来」かつ「イベント開催が未成立に終わった」、「入力期日到来」かつ「イベント開催が成立した（あるいは仮決定）」かつ「参加者抽選前」、イベント開催成立後（あるいは仮決定後）抽選が実施され当該レコードの登録者は当選しなかった（はずれ）、イベント開催成立後（あるいは仮決定後）抽選が実施され当該レコードの登録者が当選した、などを表す情報を格納する。キャンセル区分は、イベント開催を希望して情報が入力された後にイベント開催希望がキャンセルされたかを表す情報を格納する項目であり、例えば、イベント開催が決まった後、あるいは当選した人が当選の通知を受け取った後にキャンセルしたかどうか、などを表す情報を格納する。
【００４２】
「イベント開催情報」は、「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」の組み合わせを検索キー項目としたファイル又はＤＢであり、予定チケット枚数、の項目を有し、実施が決定又は仮決定したイベントの内容に関する情報を格納する。
【００４３】
予定チケット枚数は、イベントを開催した場合の予定販売チケット枚数を表す情報を格納する項目である。
【００４４】
「開催エリア近接」は、「エリアＩＤ」を検索キー項目としたファイル又はＤＢであり、近接エリアＩＤ１、近接エリアＩＤ２、近接エリアＩＤ３、…のように１つ以上の近接エリアＩＤの項目を有し、特定のエリアに近接するエリアに関する情報を格納する。図９では、便宜的に近接エリアＩＤ４まで存在するとしている。
【００４５】
近接エリアＩＤは、前記エリアＩＤと同様、イベントが開催される地域を識別するための、記号・番号などから構成される情報を格納する項目である。
【００４６】
「類似開催日」は、「イベント開催日」を検索キー項目としたファイル又はＤＢであり、類似開催日１、類似開催日２、類似開催日３、…のように１つ以上の類似開催日の項目を有し、特定のイベント開催日に類似する開催日に関する情報を格納する。図９では、便宜的に類似開催日４まで存在するとしている。
【００４７】
類似開催日は、前記イベント開催日と同様、イベントが開催される日を識別するための、数字や記号の組み合わせなどから構成される情報を格納する項目である。
【００４８】
２、  本発明の実施のフローについて
【００４９】
続いて、本発明に係るイベント開催支援プログラムを、イベント開催支援システムの処理手段である中央処理サーバが解釈・実行して行う処理の動作フローについて説明する。以下、図１−図１４を使用して説明するが、特に図４−図８のフローチャートを中心に説明する。
【００５０】
（図１）  図１は、イベント開催支援システムと通信ネットワークやインターネット等の通信回線を介して接続している、携帯電話、携帯情報端末やパーソナルコンピュータ等である利用者システムにおける入力画面である。
【００５１】
まず、イベント開催支援システムの利用者が利用者システムを使って、インターネットのアドレス等を用い、イベント開催支援システムへ接続すると共に、会員登録を行う。具体的には、利用者システムが会員登録入力画面を表示する情報（会員入力フォーム）をイベント開催支援システムへ要求する。そして、通信手段を介してこの要求を受信したイベント開催支援システムの処理手段は、記憶手段に記憶されている会員登録入力画面を表示する情報を、通信手段を介して利用者システムに送信する。これを受けて、利用者が利用者システムを使って氏名やメールアドレス等の会員に関する情報（会員マスタの各項目に関する情報）を、イベント開催支援システムへ送信する。そして、通信手段を介して会員に関する情報を受信したイベント開催支援システムの処理手段は、既存会員と重複しない新たな会員ＩＤを発行して、発行した会員ＩＤと受信した会員に関する情報を関連付けて、記憶手段の会員マスタに記憶させる。このようにして、順次、新規会員の会員登録処理が行われる。
【００５２】
また、イベント開催支援システムの記憶手段には、アーティストマスタ、エリア別アーティストマスタ、アーティスト予定、エリアマスタ、開催エリア近接、類似開催日、の各ファイル又はＤＢが既に格納されている。このうち、アーティストマスタ、エリア別アーティストマスタ、アーティスト予定、については、イベントを開催するアーティストが、携帯電話、携帯情報端末やパーソナルコンピュータ等を使って、イベント開催支援システムに各情報を送信し、イベント開催支援システムの記憶手段に情報を登録しておく。一方、エリアマスタ、開催エリア近接、類似開催日、については、イベント開催支援システムの管理者が、事前にイベント開催支援システムの記憶手段に情報を登録しておく。
【００５３】
続いて、既に会員登録を終えたイベント開催支援システムの利用者は、利用者システムを使って、インターネットのアドレス等を用い、イベント開催支援システムへ接続すると共に、イベント開催希望条件の入力画面を表示する情報を、イベント開催支援システムへ要求する。そして、通信手段を介してこの要求を受信したイベント開催支援システムの処理手段は、記憶手段に記憶されているイベント開催希望条件の入力画面を表示する情報を、通信手段を介して利用者システムに送信する。これを受けて、利用者システムがイベント開催希望条件の入力画面を表示する情報をディスプレイ等に表示した表示例が、図１である。
【００５４】
図１に示す、登録アーティストリストを表示するための情報（アーティストＩＤ、アーティスト名）は、イベント開催支援システムの記憶手段のアーティストマスタに存在し、登録地域リストを表示するための情報（エリアＩＤ、エリア名称）は、イベント開催支援システムの記憶手段のエリアマスタに存在する。よって、イベント開催支援システムの処理手段は、アーティストＩＤ、アーティスト名、エリアＩＤ、エリア名称、についても記憶手段から読み出し、イベント開催希望条件の入力画面を表示する情報と共に、通信手段を介して利用者システムに送信する。
【００５５】
イベント開催支援システムの利用者は、利用者システムを使って、図１の画面表示例のような状態で、登録アーティストリストからイベントを開催して欲しいアーティストを選択し（選択アーティスト）、登録地域リストからイベントを開催して欲しい地域を選択する（選択地域）。また、イベント開催支援システムの利用者は、イベントを開催して欲しい日をカレンダーから選択し（イベント開催日）、イベント開催が決まったら必ず行くか、当選した時点で判断するかの購入希望度合を選択する（購入希望度）。さらに、イベント開催支援システムの利用者は、イベントが開催された場合に一緒にイベントに参加する予定の、自分以外の同伴者の人数も入力する（同伴者人数）。
【００５６】
（図２）  図２は、利用者システムがイベント開催希望条件の入力画面を表示する情報をディスプレイ等に表示した表示例の他の例が、図２である。イベント開催支援システムの利用者が、利用者システムを使って、図１の画面表示例のような状態で、特定の日付を選択した場合に図２の画面に遷移する。図１と図２の相違点は、図１の画面ではイベント開催を希望する開催日を複数選択できるのに対し、図２の画面ではイベント開催日の日付の選択は既にされており、その他のイベント開催希望条件のみを選択できるという点である。
【００５７】
（図１０）  図１や図２で選択できるイベント開催日の日付に関する説明図が図１０である。図１０に示すように、イベントの一例としてのコンサートを開催して欲しい日（イベント開催日）は、現在の日付より一定日以上（例えば２ヶ月）先でなければいけない、などの入力ルールを定めることが現実的である。このイベント開催日の入力ルールに反するイベント開催日の選択は、利用者システムが入力を排除する方法でもよいし、イベント開催支援システムの処理手段が、利用者システムから受信したイベント開催希望条件のイベント開催日と、記憶手段のシステム日付情報と、記憶手段のイベント開催日の入力ルールとを使い、計算して排除するか否かを判定する方法でもよい。
【００５８】
このように図１及び２の画面表示がなされ、利用者が利用者システムを使ってイベント開催希望条件の入力を行う。これにより、イベント開催日、アーティストＩＤ、エリアＩＤ、希望チケット枚数、購入希望度、というイベント開催希望条件が決定される。そして、利用者が決定したイベント開催希望条件を、利用者システムを使って、自己の会員ＩＤと共にイベント開催支援システムへ送信する。図１及び２では、「新規登録・更新の実行」というボタンをクリックすることにより、イベント開催支援システムへの送信が行われる。通信手段を介して会員ＩＤとイベント開催希望条件を受信したイベント開催支援システムの処理手段は、記憶手段のイベント開催希望条件に会員ＩＤとイベント開催希望条件を格納する。この際、イベント開催支援システムの処理手段は、イベント開催希望条件のうち、登録年月日には記憶手段のシステム日付情報の値を、当選状態には期日前の値を、それぞれ格納させる。
【００５９】
（図３）  図３は、図１及び２の画面表示例で入力されたイベント開催希望条件の論理レコードと、会員マスタ、エリアマスタ、アーティストマスタの状態を表す図である。このようにして、イベント開催支援システムの利用者である様々な会員のイベント開催希望条件が、イベント開催支援システムの記憶手段に格納されていくことになる。なお、図１及び図２における「同伴者人数」と図３における「希望チケット枚数」の関係は、図１及び図２における「同伴者人数」＋１の値が、「希望チケット枚数」の値となる。つまり、同伴者はイベントに参加を希望する者と一緒に同伴する者であるので、同伴者＋１（イベント参加を希望する者）の値が、イベント開催希望条件の「希望チケット枚数」の値となる。
【００６０】
（図４）  図４−図８は、イベント開催支援システムの処理手段が行う処理フロー図であり、以下、このフローに沿って説明する。まず、イベント開催支援システムの処理手段は、イベント開催希望条件の集計を行うタイミングが到来すると、イベント開催希望条件の集計処理を行う（Ｓ４０１）。例えば、毎日１回行う、１週間に１回特定の曜日に行うなどの、集計タイミングの条件を表す情報をイベント開催支援システムの記憶手段に事前に記憶させておく。そして、イベント開催支援システムの処理手段が、イベント開催支援システムの記憶手段に記憶されているシステム日付情報が集計タイミングの条件に合致したと判定した場合に、Ｓ４０１以下の処理を行う。
【００６１】
次に、イベント開催支援システムの処理手段は、アーティスト別に設定している集計タイミング条件を調べる（Ｓ４０２）。具体的には、イベント開催支援システムの処理手段が、記憶手段のアーティストマスタにおけるアーティストごと（アーティストＩＤの値ごと）に集計タイミング条件項目の値を読み出す。この集計タイミング条件項目の値の例としては、イベント開催日まで一定の期間しかなくなった日に１回集計、イベント開催日の３ヶ月前から２ヶ月前まで１日に１回集計、イベント開催日の６ヶ月前から１ヶ月前まで１週間に１回集計、などである。
【００６２】
続いて、イベント開催支援システムの処理手段は、Ｓ４０２で調べたアーティスト別の集計タイミング条件を使って、今回の集計対象となる「イベント開催希望条件」レコードを抽出する（Ｓ４０３）。具体的には、イベント開催支援システムの処理手段が、記憶手段のイベント開催希望条件のレコードを順次読み出して、当該読み出したレコードのアーティストＩＤの値と同じアーティストＩＤの値に関連付いているＳ４０２の集計タイミング条件を特定し、イベント開催希望条件のレコードにおけるイベント開催日と、記憶手段のシステム日付情報と、特定した集計タイミング条件と、により、抽出対象のイベント開催希望条件レコードであるかを判定する。すなわち、イベント開催支援システムの処理手段が、イベント開催希望条件のレコードにおけるイベント開催日と記憶手段のシステム日付情報との間の期間を計算し、当該計算した期間が特定した集計タイミング条件を満たすか否かを判定する。このようにして、イベント開催支援システムの処理手段は、記憶手段のイベント開催希望条件のレコードのうち、対象となるレコード全てを抽出する。なお、イベント開催支援システムの処理手段は、イベント開催希望条件のレコードにおけるイベント開催日の値が表すイベント開催日が、記憶手段のシステム日付情報が表す日付よりも後の日でなければ、抽出対象のレコードとしない。
【００６３】
続いて、イベント開催支援システムの処理手段は、Ｓ４０３で抽出された「イベント開催希望条件」レコードを、「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせを集計単位として、「希望チケット枚数」の値の集計を行う（Ｓ４０４）。このＳ４０４の結果、イベント開催支援システムの処理手段が行う処理によって、「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせごとに、「希望チケット枚数」の集計結果の値を算出できる。なお、Ｓ４０５以下の処理は、Ｓ４０４の集計単位である「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせごとに行うことになる。
【００６４】
次に、イベント開催支援システムの処理手段は、アーティストのコンサート可能日時・可能エリアの情報が登録されているかを判断する（Ｓ４０５）。具体的には、イベント開催支援システムの処理手段が、Ｓ４０４における集計単位として使用した「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせが、記憶手段のアーティスト予定のレコードに存在するか否かを判定する。Ｓ４０５の判定の結果、存在する場合は、Ｓ４０９の処理が行われ、存在しない場合は、Ｓ４０６の処理が行われる。
【００６５】
Ｓ４０５の判定の結果、存在する場合は、イベント開催支援システムの処理手段が、集計キーとしてのイベント開催日・エリアはアーティストがコンサートを行える日・地域として登録されているかを判断する（Ｓ４０９）。具体的には、イベント開催支援システムの処理手段が、Ｓ４０５で存在した記憶手段のアーティスト予定のレコードにおける「開催可否」の項目の値が開催可の情報であるか否かを判定する。Ｓ４０９の判定の結果、開催可の場合は、Ｓ４０６の処理が行われ、開催不可の場合は、Ｓ４１０の処理が行われる。
【００６６】
Ｓ４０９の判定の結果、開催不可の場合は、イベント開催支援システムの処理手段が、Ｓ４０５で判断の対象となった「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせの集計単位を、コンサート開催不可と決定する（Ｓ４１０）。そして、イベント開催支援システムの処理手段が、Ｓ４０３で抽出したイベント開催希望条件のレコードのうち、Ｓ４０５で判断の対象となった「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせを有するレコードを全て抽出し、当該抽出したレコードにおける会員ＩＤの会員のメールアドレスに対して、コンサート開催が不可となった旨のメールを送信する（Ｓ４１１）。また、イベント開催支援システムの処理手段は、当該抽出したレコードにおける当選対象の項目に「開催不可」の値を入力し、記憶手段に記憶させておく。なお、Ｓ４０２におけるアーティストごとの集計タイミング条件項目の値によっては、イベントが開催されるかどうかについて日時を変えて複数回の集計処理が行われることになるため、最後に集計回である場合のみ（イベント開催の可能性がなくなる場合のみ）イベント開催支援システムの処理手段がこのＳ４１１を行う。
【００６７】
Ｓ４０５の判定の結果、存在しない場合、あるいは、Ｓ４０９の判定の結果、開催可の場合は、イベント開催支援システムの処理手段が、Ｓ４０５で判定の対象となった「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせにおける、「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせに関連付いている「エリア別最低観客数」の値が存在するか否かを、記憶手段のエリア別アーティストマスタから検索して、判定する（Ｓ４０６）。
【００６８】
Ｓ４０６の判定の結果、存在しない場合は、イベント開催支援システムの処理手段が、Ｓ４０５で判定の対象となった「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせにおける、「アーティストＩＤ」の値に関連付いている「最低観客数」の値を、記憶手段のアーティストマスタから特定し、当該「最低観客数」の値を「アーティスト希望最低人数」の値として記憶手段に格納する（Ｓ４０７）。
【００６９】
Ｓ４０６の判定の結果、存在した場合は、イベント開催支援システムの処理手段が、Ｓ４０６で存在した「エリア別最低観客数」の値を「アーティスト希望最低人数」の値として記憶手段に格納する（Ｓ４０８）。
【００７０】
（図５）  続いて、イベント開催支援システムの処理手段は、Ｓ４０４で集計した「希望チケット枚数」の集計結果の値が、Ｓ４０７又はＳ４０８で記憶手段に格納した「アーティスト希望最低人数」の値以上であるかを判定する（Ｓ４１２）。Ｓ４１２の判定の結果、「アーティスト希望最低人数」の値以上の場合は、Ｓ４１３の処理が行われ、「アーティスト希望最低人数」の値未満の場合は、Ｓ４２０の処理が行われる。
【００７１】
そして、Ｓ４１２の判定の結果「アーティスト希望最低人数」の値以上の場合は、イベント開催支援システムの処理手段は、Ｓ４０４で集計した「希望チケット枚数」の集計結果の値が、「当社（イベント主催者）設定基準数」の値以上か否かを判定する（Ｓ４１３）。この当社（イベント主催者）設定基準数は、イベント主催者の立場としてのイベント開催のための最低限の観客数であり、事前に記憶手段に記憶させておくのがよい。この際は、記憶手段のエリアマスタの１項目として「当社（イベント主催者）設定基準数」を設けてもよいし、全エリア共通の「当社（イベント主催者）設定基準数」を設けてもよい。Ｓ４１３の判定の結果、「当社（イベント主催者）設定基準数」の値以上の場合は、Ｓ４１４の処理が行われ、「当社（イベント主催者）設定基準数」の値未満の場合は、Ｓ４２０の処理が行われる。
【００７２】
Ｓ４１２の判定の結果「アーティスト希望最低人数」の値未満の場合及びＳ４１３の判定の結果「当社（イベント主催者）設定基準数」の値未満の場合は、イベント開催支援システムの処理手段が、Ｓ４０４で集計単位として使用した「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせが表すコンサートの開催を、開催不可と決定する（Ｓ４２０）。そして、イベント開催支援システムの処理手段が、記憶手段のイベント開催希望条件のレコードのうち、Ｓ４０４で集計単位として使用した「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせを有するレコードを全て抽出し、当該抽出したレコードにおける会員ＩＤの会員のメールアドレスに対して、コンサート開催が不可となった旨のメールを送信する（Ｓ４２１）。また、イベント開催支援システムの処理手段は、当該抽出したレコードにおける当選対象の項目に「開催不可」の値を入力し、記憶手段に記憶させておく。なお、Ｓ４０２におけるアーティストごとの集計タイミング条件項目の値によっては、イベントが開催されるかどうかについて日時を変えて複数回の集計処理が行われることになるため、最後に集計回である場合のみ（イベント開催の可能性がなくなる場合のみ）イベント開催支援システムの処理手段がこのＳ４２１を行う。
【００７３】
Ｓ４１３までは、Ｓ４０４で集計した「希望チケット枚数」の集計結果の値が、アーティストやイベント主催者の最低観客数の値のライン（基準値）を超えているか否かが判断されたが、Ｓ４１４からは最大限度観客数の範囲内であるか否かを判断し、チケットの当選者を決定する処理に移る。イベント開催支援システムの処理手段は、当コンサート（イベント）の最大限度観客数を計算する（Ｓ４１４）。具体的には、イベント開催支援システムの処理手段が、図６の処理を行う。
【００７４】
（図６）  まず、イベント開催支援システムの処理手段は、Ｓ４０４で集計単位として使用した「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせにおける、「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせに関連付いている「エリア別最大限度観客数」の値が存在するかを、記憶手段のエリア別アーティストマスタから検索して、判定する（Ｓ６０１）。Ｓ６０１の判定の結果、存在した場合は、Ｓ６０５の処理が行われ、存在しなかった場合は、Ｓ６０２の処理が行われる。
【００７５】
Ｓ６０１の判定の結果、存在した場合は、イベント開催支援システムの処理手段が、Ｓ６０１で存在した「エリア別最大限度観客数」の値をＳ４１４の「最大限度観客数」の値として記憶手段に格納する（Ｓ６０５）。
【００７６】
Ｓ６０１の判定の結果、存在しない場合は、イベント開催支援システムの処理手段が、Ｓ４０４で集計単位として使用した「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせにおける、「アーティストＩＤ」の値に関連付いている「最大限度観客数」の値が記憶手段のアーティストマスタに存在するか否かと、「エリアＩＤ」の値に関連付いている「エリア別最大限度観客数」の値が記憶手段のエリアマスタに存在するか否か、を判定する（Ｓ６０２）。Ｓ６０２の判定の結果、どちらか一方のみ存在した場合は、Ｓ６０６の処理が行われ、全く存在しなかった場合及び両方存在した場合は、Ｓ６０３の処理が行われる。
【００７７】
Ｓ６０２の判定の結果、どちらか一方のみ存在した場合は、イベント開催支援システムの処理手段が、Ｓ６０２で存在した「最大限度観客数」又は「エリア別最大限度観客数」の値をＳ４１４の「最大限度観客数」の値として記憶手段に格納する（Ｓ６０６）。
【００７８】
Ｓ６０２の判定の結果、全く存在しなかった場合及び両方存在した場合は、イベント開催支援システムの処理手段が、Ｓ６０２の判定の結果が全く存在しなかったのか、それとも両方存在していたのかを判定する（Ｓ６０３）。Ｓ６０３の判定の結果、全く存在しなかった場合は、Ｓ６０４の処理が行われ、両方存在した場合は、Ｓ６０７の処理が行われる。
【００７９】
Ｓ６０３の判定の結果、両方存在した場合は、イベント開催支援システムの処理手段が、Ｓ６０２で存在した「最大限度観客数」又は「エリア別最大限度観客数」の値のうち、少数の値の方をＳ４１４の「最大限度観客数」の値として記憶手段に格納する（Ｓ６０７）。
【００８０】
一方、Ｓ６０３の判定の結果、全く存在しなかった場合は、イベント開催支援システムの処理手段が、Ｓ４１４の「最大限度観客数」の値を無限として記憶手段に格納する（Ｓ６０４）。
【００８１】
以上の図６の処理が行われることにより、（１）記憶手段のエリア別アーティストマスタにおける「エリア別最大限度観客数」の値、（２）記憶手段のエリア別アーティストマスタにおける「エリア別最大限度観客数」の値が不存在であれば、記憶手段のアーティストマスタにおける「最大限度観客数」の値もしくは記憶手段のエリアマスタにおける「エリア別最大限度観客数」の値のうち小さい値あるいは存在する一方の値、（３）上記（１）及び（２）で特定できない場合は無限値、がＳ４１４における「当コンサートの最大限度観客数」の値となる。
【００８２】
次に、イベント開催支援システムの処理手段は、記憶手段のイベント開催希望条件における「購入希望度」項目で、「決まったら必ず行く」と入力している人の抽選を行う（Ｓ４１５）。具体的には、イベント開催支援システムの処理手段が、図７の処理を行う。
【００８３】
（図７）  まず、イベント開催支援システムの処理手段は、Ｓ４０４で「希望チケット枚数」の集計の対象となった記憶手段のイベント開催希望条件のレコードのうち、「購入希望度」項目が「決まったら必ず行く」となっているレコードを抽出する（Ｓ７０１）。
【００８４】
次に、イベント開催支援システムの処理手段は、イベントのチケット当選者を決めるルールを、記憶手段から読み出す（Ｓ７０２）。イベントのチケット当選者を決めるルールは、例えば、アーティストマスタ、エリア別アーティストマスタ、エリアマスタ、のいずれかに項目として設けておく方法がある。アーティストマスタにルール項目を設けた場合は、Ｓ４０４における集計単位として使用した「アーティストＩＤ」の値によりルール項目の値を特定でき、エリア別アーティストマスタにルール項目を設けた場合は、Ｓ４０４における集計単位として使用した「アーティストＩＤ」と「エリアＩＤ」の値の組み合わせによりルール項目の値を特定でき、エリアマスタにルール項目を設けた場合は、Ｓ４０４における集計単位として使用した「エリアＩＤ」の値によりルール項目の値を特定できる。
【００８５】
Ｓ７０２で読み出したイベントのチケット当選者を決めるルールには、大きく分けて３つの方法がある。（１）当選の回数をより平等にしていく平等化抽選、（２）先着順、（３）ランダム抽選、である。上記ルール項目の値として、この３種類のいずれかを表す値を採用する。イベント開催支援システムの処理手段は、Ｓ７０２で読み出したイベントのチケット当選者を決めるルールが、平等化抽選、先着順、ランダム抽選、のいずれかであるかを判定する（Ｓ７０３）。
【００８６】
Ｓ７０３の判定の結果、Ｓ７０２で読み出したイベントのチケット当選者を決めるルールが、先着順であった場合は、Ｓ７０４−Ｓ７０６の処理を行う。イベント開催支援システムの処理手段は、Ｓ７０１で抽出したイベント開催希望条件のレコードのうち、「登録年月日」項目の値が少ない、つまり登録が早い順に、Ｓ７０１で抽出したイベント開催希望条件のレコードをソートする（Ｓ７０４）。そして、イベント開催支援システムの処理手段は、Ｓ７０４でソートした昇順にレコードを１件ずつ、当該レコードにおける「希望チケット枚数」の値を足しこんでいき（Ｓ７０５）、足しこんだ「希望チケット枚数」の値がＳ４１４における「当コンサートの最大限度観客数」の値に達するまで、足しこみ処理を続ける（Ｓ７０６）。Ｓ７０１で抽出したイベント開催希望条件のレコードのうち、このＳ７０５及びＳ７０６において、足しこみ処理の対象となったレコードが、開催するイベントのチケットの割り当てがなされる当選となる。イベント開催支援システムの処理手段は、当該足しこみ処理の対象となり当選したレコードの「当選状態」の値を「当選」として記憶手段に記憶させる。一方、Ｓ７０１で抽出したイベント開催希望条件のレコードのうち、このＳ７０５及びＳ７０６において、足しこみ処理の対象とならなかったレコードは、開催するイベントのチケットの割り当てがなされない落選となる。イベント開催支援システムの処理手段は、当該足しこみ処理の対象とならず落選したレコードの「当選状態」の値を「はずれ」として記憶手段に記憶させる。
【００８７】
Ｓ７０３の判定の結果、Ｓ７０２で読み出したイベントのチケット当選者を決めるルールが、ランダム抽選であった場合は、Ｓ７０７−Ｓ７０８の処理を行う。イベント開催支援システムの処理手段は、Ｓ７０１で抽出したイベント開催希望条件のレコードのうち、ランダムにレコードを１件ずつ選択し、当該レコードにおける「希望チケット枚数」の値を足しこんでいき（Ｓ７０７）、足しこんだ「希望チケット枚数」の値がＳ４１４における「当コンサートの最大限度観客数」の値に達するまで、足しこみ処理を続ける（Ｓ７０８）。イベント開催支援システムの処理手段がランダムにレコードを選択する際には、通常用いられている乱数プログラム等を記憶手段に事前に記憶させておき、ランダム選択に使用するとよい。Ｓ７０１で抽出したイベント開催希望条件のレコードのうち、このＳ７０７及びＳ７０８において、足しこみ処理の対象となったレコードが、開催するイベントのチケットの割り当てがなされる当選となる。イベント開催支援システムの処理手段は、当該足しこみ処理の対象となり当選したレコードの「当選状態」の値を「当選」として記憶手段に記憶させる。一方、Ｓ７０１で抽出したイベント開催希望条件のレコードのうち、このＳ７０７及びＳ７０８において、足しこみ処理の対象とならなかったレコードは、開催するイベントのチケットの割り当てがなされない落選となる。イベント開催支援システムの処理手段は、当該足しこみ処理の対象とならず落選したレコードの「当選状態」の値を「はずれ」として記憶手段に記憶させる。
【００８８】
Ｓ７０３の判定の結果、Ｓ７０２で読み出したイベントのチケット当選者を決めるルールが、平等化抽選であった場合は、Ｓ７０９−Ｓ７１０の処理を行う。イベント開催支援システムの処理手段は、Ｓ７０１で抽出したイベント開催希望条件のレコードのうち、平等化アルゴリズムの条件上、高得点である会員ＩＤの会員のレコードを１件ずつ選択し（Ｓ７０９）、当該レコードにおける「希望チケット枚数」の値を足しこんでいき、足しこんだ「希望チケット枚数」の値がＳ４１４における「当コンサートの最大限度観客数」の値に達するまで、足しこみ処理を続ける（Ｓ７１０）。Ｓ７０１で抽出したイベント開催希望条件のレコードのうち、このＳ７０９及びＳ７１０において、足しこみ処理の対象となったレコードが、開催するイベントのチケットの割り当てがなされる当選となる。イベント開催支援システムの処理手段は、当該足しこみ処理の対象となり当選したレコードの「当選状態」の値を「当選」として記憶手段に記憶させる。一方、Ｓ７０１で抽出したイベント開催希望条件のレコードのうち、このＳ７０９及びＳ７１０において、足しこみ処理の対象とならなかったレコードは、開催するイベントのチケットの割り当てがなされない落選となる。イベント開催支援システムの処理手段は、当該足しこみ処理の対象とならず落選したレコードの「当選状態」の値を「はずれ」として記憶手段に記憶させる。
【００８９】
Ｓ７０９における平等化アルゴリズムの条件について、簡単に説明する。まず、（１）前回当選したコンサートから、どれくらい購入の期間が経過しているか、を考慮する。これは、記憶手段のイベント開催希望条件の過去履歴（イベント開催か開催不可かが、既に確定したレコード）において、会員ＩＤの値を検索キー項目として、当選状態の値とキャンセル区分の値を抽出することにより判断できる。次に、（２）過去にコンサートが成立したが、抽選からもれて当選できなかった回数、を考慮する。これも、記憶手段のイベント開催希望条件の過去履歴において、会員ＩＤの値を検索キー項目として、当選状態の値を抽出することにより判断できる。また、（３）過去にコンサート開催が未成立に終わった回数、を考慮する。これも、記憶手段のイベント開催希望条件の過去履歴において、会員ＩＤの値を検索キー項目として、当選状態の値を抽出することにより判断できる。さらに、（４）会員ＩＤを登録してからの経過した期間、を考慮する。これは、記憶手段の会員マスタにおいて、会員ＩＤの値を検索キー項目として、会員登録年月日の値を抽出することにより判断できる。そして、（５）過去当選したにもかかわらずキャンセルした回数、を考慮する。これも、記憶手段のイベント開催希望条件の過去履歴において、会員ＩＤの値を検索キー項目として、当選状態の値とキャンセル区分の値を抽出することにより判断できる。以上のような平等化アルゴリズムを、会員のイベント開催希望条件の過去履歴全体に対して行ったり、あるいは、今回の対象となっているアーティストに関係するイベント開催希望条件の過去履歴に絞って行ったり、両者とも行い、両者間の重みづけを変えることで総合的な判断としたりと、その時々の平等化の方針（ポリシー）に応じて使いわけることもできる。
【００９０】
Ｓ７０９における平等化アルゴリズムの条件の点数付け・重み付けは、イベント開催支援システムの処理手段が行う。点数付け・重み付けは、記憶手段に事前に各条件の点数表を備えておけばよい。上記（１）−（５）により算出される値を、当該点数表により乗算すること等によりＳ７１０の足しこみ処理において優先される最終的な総合値が算出できる。
【００９１】
次に、イベント開催支援システムの処理手段は、Ｓ４１５の集計処理によって、「決まったら必ず行く」という人の集計値が、最大限度観客数に達したか、を判定する（Ｓ４１６）。当該判断において、S４１５の集計処理によって、「決まったら必ず行く」という人の集計値が、最大限度観客数に達しなかったと判定された場合、イベント開催支援システムの処理手段は、記憶手段のイベント開催希望条件における「購入希望度」項目で、「決まったら行くかどうか、当選したらその時点で判断したい」と入力している人の抽選を行う（Ｓ４１７)。具体的には、イベント開催支援システムの処理手段が、図８の処理を行う。
【００９２】
（図８）  図８において、イベント開催支援システムの処理手段が行う処理は、図７における処理と同様であるので、図７の処理と図８の処理との異なる点のみを説明する。
【００９３】
まず、図７では、Ｓ７０１において、Ｓ４０４で「希望チケット枚数」の集計の対象となった記憶手段のイベント開催希望条件のレコードのうち、「購入希望度」項目が「決まったら必ず行く」となっているレコードを抽出する。これに対し、図８では、Ｓ８０１において、Ｓ４０４で「希望チケット枚数」の集計の対象となった記憶手段のイベント開催希望条件のレコードのうち、「購入希望度」項目が「決まったら行くかどうか、当選したらその時点で判断したい」となっているレコードを抽出する。これは、より購入希望度合いが強い会員を、イベントのチケット割り当てにおいて優先するためである。
【００９４】
また、図７のＳ７０６、Ｓ７０８、Ｓ７１０における「最大限度観客数」が、対応する図８のＳ８０６、Ｓ８０８、Ｓ８１０では「最大限度観客数の残＋キャンセル予想数」となっている。つまり、図７では、Ｓ４１４における「当コンサートの最大限度観客数」の値をそのまま処理終了の判断基準の値とするのに対し、図８では、Ｓ４１４における「当コンサートの最大限度観客数」の値から図７の処理で優先的に割り当てられた値を減算した「最大限度観客数の残」の値と、キャンセル予想数の値との合計値を処理終了の判断基準の値とする。
【００９５】
図８における「キャンセル予想数」の値の算出は、Ｓ４１４における「当コンサートの最大限度観客数」の値と、記憶手段のアーティストマスタの「キャンセル予想率」の値又は記憶手段のエリア別アーティストマスタの「エリア別キャンセル予想率」の値とから、イベント開催支援システムの処理手段が行う。例えば、Ｓ４１４における「当コンサートの最大限度観客数」の値が２００で、キャンセル予想率の値が２０％ならば、２００÷（１００％−２０％）より、２５０がＳ４１４における「当コンサートの最大限度観客数」の値＋キャンセル予想数の値であると特定できる。また、イベント開催支援システムの処理手段は、Ｓ４１５及びＳ４１７で抽選に当選した会員の「希望チケット枚数」の値の合計値を、Ｓ４０４で集計単位として使用した「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせに、「予定チケット枚数」の値として関連付けて、記憶手段のイベント開催情報ファイルに記憶させる。Ｓ４１５及びＳ４１７での抽選において、希望した全ての会員が当選していれば、Ｓ４１５及びＳ４１７で抽選に当選した会員の「希望チケット枚数」の値の合計値は、Ｓ４０４で集計した「希望チケット枚数」の値の集計値と等しくなる。これにより、記憶手段のイベント開催情報ファイルには、実際に開催が確定、もしくは仮決定したイベントに関する情報が、順次記憶されていくことになる。
【００９６】
次に、イベント開催支援システムの処理手段は、コンサートが仮決定か確定決定かを判断するためのルールを、記憶手段から読み出し、判定する（Ｓ４１８）。コンサートが仮決定か確定決定かを判断するためのルールは、例えば、アーティストマスタ、エリア別アーティストマスタ、エリアマスタ、のいずれかに項目として設けておく方法がある。アーティストマスタにルール項目を設けた場合は、Ｓ４０４における集計単位として使用した「アーティストＩＤ」の値によりルール項目の値を特定でき、エリア別アーティストマスタにルール項目を設けた場合は、Ｓ４０４における集計単位として使用した「アーティストＩＤ」と「エリアＩＤ」の値の組み合わせによりルール項目の値を特定でき、エリアマスタにルール項目を設けた場合は、Ｓ４０４における集計単位として使用した「エリアＩＤ」の値によりルール項目の値を特定できる。図９では、アーティストマスタ、エリア別アーティストマスタ、の両方に「仮・確定区分」が存在するため、例えば、エリア別アーティストマスタに「エリア別仮・確定区分」の値が存在すればそちらを優先し、存在しなければアーティストマスタの「仮・確定区分」の値を採用する。
【００９７】
Ｓ４１８の判定の結果、確定決定の場合は、イベント開催支援システムの処理手段が、記憶手段のイベント開催希望条件のレコードのうち、Ｓ４０４で集計単位となった「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせを有するレコードを全て抽出し、当該抽出したレコードにおける会員ＩＤの会員のメールアドレスに対して、コンサート開催が確定決定となった旨のメールを送信する（Ｓ４１９）。この際には、チケットに当選した人、はずれた人、両方にメールを送信し、会員が当選したかはずれたかは、記憶手段のイベント開催情報における当選状態の値により判定する。また、イベント開催支援システムの処理手段は、当該抽出したレコードにおけるアーティストＩＤのアーティストのメールアドレスに対しても、コンサート開催が確定決定となった旨のメールを送信する。
【００９８】
例えば、図１２に示すような文面のメールを、イベントを開催するアーティストのメールアドレスに送信する。また、図１２に示すような文面を、メールではなく、イベントを開催するアーティスト用のＷＥＢ画面で表示することとしてもよい。さらに、例えば図１３又は図１４に示すような文面のメールを、チケットが当選した会員のメールアドレスに送信する。
【００９９】
Ｓ４１８の判定の結果、仮決定の場合は、イベント開催支援システムの処理手段が、記憶手段のイベント開催希望条件のレコードのうち、Ｓ４０４で集計単位となった「イベント開催日」と「アーティストＩＤ」と「エリアＩＤ」との値の組み合わせを有するレコードを全て抽出し、当該抽出したレコードにおける会員ＩＤの会員のメールアドレスに対して、コンサート開催が仮決定となった旨のメールを送信する（Ｓ４２２）。この際には、チケットに当選した人、はずれた人、両方にメールを送信し、会員が当選したかはずれたかは、記憶手段のイベント開催情報における当選状態の値により判定する。また、イベント開催支援システムの処理手段は、当該抽出したレコードにおけるアーティストＩＤのアーティストのメールアドレスに対しても、コンサート開催が仮決定となった旨のメールを送信する。
【０１００】
以上のような処理により、イベント開催者としては、イベント開催が失敗に終わった場合のコスト負担が大きく軽減される。また、イベントで主役となるアーティストにとっても、知名度が高くなり、イベントを開催した場合に集客が期待できる前においても、イベント開催の機会が増える。さらに、集客があまり期待できない地方等でも、イベント開催の頻度が増え、地方等に在住する者が、イベント参加のためにイベントが開催される都会へ移動する負担が減る。
【０１０１】
（図１１）  また、本発明に係るイベント開催支援システムは、会員が希望したイベント開催希望条件と近似した条件における、現状の希望チケット枚数の合算値を表示する機能も有している。まず、イベント開催支援システムの処理手段が、アーティストＩＤとエリアＩＤとイベント開催日と希望チケット枚数とを含んだイベント開催希望条件を、通信手段を介して利用者システムから受信する（Ｓ１１０１）。例えば、図１や図２のような利用者システムにおける入力画面から、アーティストＩＤとエリアＩＤとイベント開催日と希望チケット枚数とを含んだイベント開催希望条件の入力が行われる。
【０１０２】
そして、イベント開催支援システムの処理手段が、記憶手段の開催エリア近接ファイルのうち、当該利用者システムから受信したイベント開催希望条件に含まれるエリアＩＤの値と同じキー項目の値に関連付いている１つ以上の近接エリアＩＤの値を特定すると共に、記憶手段の類似開催日ファイルのうち、当該利用者システムから受信したイベント開催希望条件に含まれるイベント開催日の値と同じキー項目の値に関連付いている１つ以上の類似開催日の値を特定する（Ｓ１１０２）。
【０１０３】
さらに、イベント開催支援システムの処理手段が、記憶手段に記憶されたイベント開催希望条件ファイルのうち、利用者システムから受信したイベント開催希望条件に含まれるアーティストＩＤとエリアＩＤとイベント開催日との値が一致する論理レコードにおける希望チケット枚数の値を合算して、当該合算した希望チケット枚数の値を当該アーティストＩＤとエリアＩＤとイベント開催日との値の組み合わせに関連付けて、通信手段を介して利用者システムに送信する（Ｓ１１０３）。
【０１０４】
また、イベント開催支援システムの処理手段が、記憶手段に記憶されたイベント開催希望条件ファイルのうち、利用者システムから受信したイベント開催希望条件に含まれるアーティストＩＤとＳ１１０２で特定したエリアＩＤとＳ１１０２で特定したイベント開催日との値の組み合わせごとに、関連付いている希望チケット枚数の値を合算し、当該合算した希望チケット枚数の値を、当該アーティストＩＤとエリアＩＤとイベント開催日との値の組み合わせごとに関連付けて、通信手段を介して利用者システムに送信する（Ｓ１１０４）。
【０１０５】
上記Ｓ１１０１−Ｓ１１０４の処理により、利用者システムの画面に表示されるのが、図１１の表示例である。星印がついている３本の棒グラフは、会員の希望したイベント開催日における希望チケット枚数の値の合算値を表しており、それ以外の棒グラフは、会員が希望したイベント開催日に類似する開催日における希望チケット枚数の値の合算値を表している。いずれの棒グラフも、会員の希望したエリア及びアーティストについてのものであるが、会員の希望したエリアに近接するエリアについての希望チケット枚数の値の合算値を表すこともできる。
また、イベント開催の基準となる基準線は、上記説明したＳ４１２における「アーティストの希望最低人数」の値とＳ４１３における「当社設定基準数」の値とのうち、いずれが大きい方の値を基準として採用することにより導き出せる。このように、会員が希望したイベント開催日だけでなく、類似する開催日における希望チケット枚数の値の合算値も表示し、会員が希望したエリアだけでなく、類似するエリアにおける希望チケット枚数の値の合算値も表示することによって、会員の希望に沿ったイベントが開催される可能性が低くても（希望チケット枚数の値の合算値が少なくても）、近似する条件（近接エリア、類似のイベント開催日）でのイベント開催に切り替えることが容易になる。
【０１０６】
例えば、利用者が最初に希望したイベント開催の希望条件における希望チケット枚数の合算値があまりに少なく、開催の実現が危ぶまれる場合であっても、最初に希望したイベント開催の希望条件に近似する条件での希望チケット枚数の合算値も併せて表示することができるため、開催の実現性の高い近似する条件を選択して変更することができる。これは、イベントの成立可能性を高めることになり、イベント主催者、アーティスト、イベント参加者のいずれにとっても満足を高める結果となる。
【図面の簡単な説明】
【０１０７】
【図１】利用者システムにおける、イベント開催希望条件の入力画面例１
【図２】利用者システムにおける、イベント開催希望条件の入力画面例２
【図３】図１及び図２の入力画面により入力された情報の図
【図４】イベント開催支援システムの処理手段が行う処理フロー図１
【図５】イベント開催支援システムの処理手段が行う処理フロー図２
【図６】イベント開催支援システムの処理手段が行う処理フロー図３
【図７】イベント開催支援システムの処理手段が行う処理フロー図４
【図８】イベント開催支援システムの処理手段が行う処理フロー図５
【図９】イベント開催支援システムの記憶手段に記憶された各種情報
【図１０】イベント開催日の入力期限や集計日に関する説明図
【図１１】利用者システムにおける、イベント開催希望条件の入力画面例３
【図１２】イベントを開催するアーティストへのイベント開催文例
【図１３】開催されるイベントのチケットに当選した会員への文例１
【図１４】開催されるイベントのチケットに当選した会員への文例２
【図１】
2007316975.tif 000003
【図２】
2007316975.tif 000004
【図３】
2007316975.tif 000005
【図４】
2007316975.tif 000006
【図５】
2007316975.tif 000007
【図６】
2007316975.tif 000008
【図７】
2007316975.tif 000009
【図８】
2007316975.tif 000010
【図９】
2007316975.tif 000011
【図１０】
2007316975.tif 000012
【図１１】
2007316975.tif 000013
【図１２】
2007316975.tif 000014
【図１３】
2007316975.tif 000015
【図１４】
2007316975.tif 000016