JP4440672B2 - イベント企画システム - Google Patents

Description

本発明は、デパート、ショッピングセンタ、駅ビル、あるいは公共団体等の各種団体が主催する物産展、季節商品の販売等の各種イベントの企画を行うイベント企画システムに係わり、特に通信ネットワークを使用して各種イベントの企画を行うイベント企画システムに関する。

デパート、ショッピングセンタ、駅ビル、あるいは公共団体等の各種団体（以下、適宜、デパートと略称する。）は、期間をそれぞれ限定して各種のイベント（催し）を開催しており、集客と商品の販売の増進に努めている。このようなデパートの開催するイベントは専門の企画会社が企画することが多い。企画会社は、それぞれのデパートとイベントを単独で行おうとする者あるいはイベントに参加しようとする者（以下、イベントを単独で行う者あるいはイベントに参加する者を含めて、ユーザと適宜略称する。）を結びつける役割をしている。

従来から、企画会社は独自に築いた人脈やノウハウを活用して、デパートにイベントの提案を行うと共にイベントに商品を出品するユーザの発掘と選別を行っている。イベントの場所を提供するデパート側では、企画力のある企画会社に企画を行わせることで、魅力あるイベントの実現によって顧客吸引力を増大し、また売り上げの増大を図ることができる。したがって、デパートにおけるイベントの企画は、企画会社等の特定のスタッフの能力や経験等に負うところが多い。このため、企画会社の担当者は、多くの人脈を構築して、有望なイベントを実現する新たなユーザや商品を発掘すると共に、今まで取引のあったユーザや商品を適性に評価しながら、デパートや消費者等の要求にマッチしたイベントの実現に努めている。

しかしながら、全国の津々浦々から各種イベントの開催に最も適したユーザや商品を見つけ出すことは大変難しい。そこでインターネット等の通信網を積極的に使用することが提案されている（たとえば特許文献１参照。）。

図１８は、この提案のイベント企画システムの原理的な構成を示したものである。このイベント企画システム１００では、イベントの参加を受け入れる受入団体１０１と、慰問演奏のイベントに参加して演奏を行いたいユーザとしての演奏団体１０２と、これらの仲介役を行うサーバとしての仲介者サーバ１０３と、無線中継用の基地局１０４を介した携帯型電話機１０５とがインターネット１０６に接続されている。仲介者サーバ１０３には、受入団体１０１と演奏団体１０２の仲介を行うためのデータベース１０７が備えられている。

このイベント企画システム１００では、仲介者サーバ１０３が受入団体１０１に対して、希望するイベントの内容を登録させ、データベース１０７に保存する。また、イベントに参加して演奏を行いたい演奏団体１０２のアクセスを同様に受け付けておいて、希望するイベントの内容をデータベース１０７に蓄積しておく。受入団体の登録が行われた後、仲介者サーバ１０３はデータベース１０７内で登録内容の照合と比較を行って、登録内容が適合する演奏団体１０２を特定する。特定した演奏団体１０２は受入団体１０１に提示される。

具体的には、音楽ジャンル、演奏スペース、演奏音量、演奏レベル、開催日程、開催地域、謝礼額等を考慮して、仲介者サーバ１０３は登録内容が適合する演奏団体１０２を特定することになる。したがって、演奏団体１０２はこれらの項目を含んだ所定のフォーマットに記入を行って仲介者サーバ１０３に対して登録を行う。受入団体１０１も同様のフォーマットに記入して登録を行って、施設の慰問演奏を行う団体の斡旋を要求する。仲介者サーバ１０３は受入団体１０１の希望する条件と一致する演奏団体１０２を検索して慰問演奏の斡旋を行うことになる。
特開２００２−２３０３３９号公報（第００２７段落、図１）

このように従来提案されたイベント企画システム１００では、仲介者サーバ１０３が受入団体１０１と演奏団体１０２のそれぞれが記入したフォーマットの単純な照合を行って、これらの間で機械的に条件が一致したものを選別することにしていた。施設の慰問演奏のように奉仕的な活動であれば、当事者同士の条件が一致することを最優先にしたイベントの実行が可能である。すなわち、ユーザとしての演奏団体１０２を選別するための条件は、施設の広さや予算等の予め常識的に定まる項目となり、仲介者サーバ１０３は普遍的な条件を網羅したフォーマットを作成しておいて受入団体１０１と演奏団体１０２のそれぞれに記入させ、比較、照合を行えば慰問演奏の斡旋を行うことが実現する。

ところがデパート、ショッピングセンタ、駅ビル、あるいは公共団体等の各種団体が主催する物産展、季節商品の販売等のイベントの場合には、イベントのテーマや参加者としてのユーザの出品する商品といった企画内容によって、その成否が大きく影響する。企画内容は、その時々の消費者動向や対象商品の在庫状況、主催者のステータス等の各種要因をにらんで決定されるものであり、まさに企画会社の腕が発揮される分野である。したがって、図１８に示した提案のイベント企画システム１００をデパートのイベントに単純に適用しようとすると、たとえば次のような問題が発生することになる。

（ａ）新しい商品を開発した場合のように、新規な分野で商品の売込みを行うユーザがいたような場合、そのようなユーザの取り扱う商品はデパートといったイベント主催者側あるいは企画会社から見れば未知な分野の商品である。したがって、そのような商品を取り扱うイベントの開催の要求を、サーバ側が予め用意した、既知の商品やイベント内容の開示を前提としたフォーマットへ記入することによって行うことは無理があり、新たな時代に即応したイベントの実現が困難である。既存の人脈等の情報源を活用することは重要であるが、既存の情報の範囲に情報の入手範囲が限られる可能性がある。したがって、実際に商品を出品しようとする者から直接情報を取得することも必要である。
（ｂ）消費者は個性化しており、毎年同一内容のイベントを繰り返し開催するだけでは、イベントの内容が飽きられ、時代に取り残されてしまう。サーバ側が予め用意したフォーマットに基づいてイベントを開催するだけでは、ありきたりの企画しか行うことができない。他のデパートが開催しない斬新で顧客の意向をより重視した、ユニークなイベントを創造する必要がある。
（ｃ）イベントのユーザが固定化しイベントがマンネリ化する１つの原因に、ユーザにある程度の資金力が必要であることが挙げられる。イベントに商品を出品し販売する場合には、自分の店舗で商品を販売する場合と異なり、イベントによる商品の売上げが開催者経由で現金化されることが多い。したがって、ユーザが商品の売り上げによる現金を取得するまでに数ヶ月程度の時間を要する場合がある。特に中小規模の会社や団体にとっては、これにより事業運転資金が一時的に回転しない状態となり、資金繰りがつかなくなる可能性がある。また、イベントでの売上げはイベントの開催前の段階で判断することができないので、売上げ予想額を前提として金融機関で資金を調達することも難しい。

以上のような問題は、従来のイベント企画だけでなく、インターネットを利用した図１８に示す提案でも解決できないものである。

そこで本発明の目的は、画一的なイベントの企画を打破して魅力のあるイベントを実現することのできるイベント企画システムを提供することにある。

本発明の他の目的は、イベントで商品の販売を行うユーザに経済的なサポートを行うことのできるイベント企画システムを提供することにある。

本発明では、（イ）イベントの企画者の企画したイベントに出品した出品物が販売されるたびにこれらの出品物に付されたタグに表わされる販売価格およびイベントの出品者を少なくとも表わしたコード情報を用いて前記した出品者ごとの日々の売上額を集計する集計手段と、この集計手段の日々の集計結果を前記したイベントに前記した出品者を参加させた前記した企画者宛に通信する売上額送信手段とを備えたイベント開催者側装置と、（ロ）前記した売上額送信手段によって出品者別の日々の売上額が通信されてきたときこれを受信する売上額受信手段と、この売上額受信手段の受信した出品者別の日々の売上額を基に前記したイベントの期間における特定期間ごとの前記した出品者の売上額を算出する期間別売上額算出手段と、イベントの出品者への直接の支払いの代わりに前記したイベントの開催者が前記したイベントの企画者に対してイベント終了までの販売に対する支払いを行うとき、前記したイベントの開催者が前記したイベントの出品者へ直接支払いを行うとする場合よりも早くこのイベントの企画者が前記したイベントの出品者にその売上に対して先払いを行うとする条件の下に、前記した出品者の売上額に対する数値“１”未満で表わされる先払い額の掛け率を先払いの行われる出品物の置かれる各種状況に関する前記したイベントの企画者と出品者の合意内容に基づいてリスト化したデータベースと、前記したイベントの出品者から前記したイベントの企画者の行う前記した先払いについての金額の提示の要求があったとき、前記したデータベースを検索して先払い額の掛け率を求める掛け率算出手段と、この掛け率算出手段で算出した先払いの額に対する先払いを行うまでの日数に基づく金利を算出する金利算出手段と、これら掛け率算出手段および金利算出手段で算出した額によって定まる前記した特定期間の前記した出品者の出品物の販売に対する先払いの金額を前記したイベントの出品者に通信で提示する先払い金額提示手段とを備えた企画者側装置とをイベント企画システムが具備する。

以上説明したように本発明によれば、イベントの企画を実行に移すとき、企画者側装置が出品者の現実の売り上げを特定期間ごとに把握しながら仕入れ代金等の先払いをするようなファイナンシャルサポートを行うので、出品者は次々とイベントを開催しても資金が底を尽くことがなく、特に短期に集中して販売する商品や資金力の弱い出品者を助け、これらの者の商品の販売を拡大させる大きな力となることができる。

以下実施例につき本発明を詳細に説明する。

＜新規イベントの提案＞

図１は、本発明の一実施例におけるイベント企画システムの概要を表わしたものである。このイベント企画システム２００は、各種のデータを通信する通信手段としてインターネット２０１を利用することにしている。インターネット２０１には、企画会社の運営するイベント企画サーバ２０２と、ファイナンシャルサポートを行うファイナンシャルサーバ２０３と、イベントに商品を出品したり販売するユーザの各種端末（ユーザ端末）が直接、あるいは間接的に接続されている。このようなユーザ端末としては、図示しないモデム（変復調装置）やルータを介して接続されるパーソナルコンピュータ２０４や、携帯電話網２０５および基地局２０６を介して接続される携帯電話機２０７や、ＣＡＴＶ（Community Antenna TeleVision,CAble TeleVision）網２０８を介して接続されるゲーム端末２０９等が存在する。なお、ゲーム端末２０９はコントローラ２１１等の入力端末を操作してＣＲＴ（CathodeRay Tube）や液晶等からなるディスプレイ２１２にデータを表示して入力操作を行うことができる。ゲーム端末２０９は、前記したモデム等を介してインターネット２０１に直接接続する形態（機種）も存在する。イベント企画サーバ２０２とイベントを開催するデパート２１４の間には、電話回線等の通信手段２１５が存在している。デパート２１４における各ユーザの１日ごとの売上げ等の情報は、電話、ファクシミリ、電子メール等の手段で各売り場からイベント企画サーバ２０２のオペレータへと伝達されるようになっている。

図１では、パーソナルコンピュータ２０４、携帯電話網２０５、基地局２０６、携帯電話機２０７、ＣＡＴＶ網２０８、ゲーム端末２０９およびデパート２１４を１つずつ図示している。これらは図示および説明の簡略化のためであり、たとえばパーソナルコンピュータ２０４等のユーザ端末は、少なくともユーザの使用する数だけ用意されている。

図２は、イベント企画サーバの構成を表わしたものである。イベント企画サーバ２０２は、ＣＰＵ（Central Processing Unit）２２１を備えている。ＣＰＵ２２１は、バス２２２を通じてプログラム記憶媒体２２３、作業用メモリ２２４、入出力回路２２５、通信制御回路２２６、コンテンツ格納部２２７およびデータベース２２８と接続されている。ここで、プログラム記憶媒体２２３は、イベント企画サーバ２０２としての各種制御を行う制御プログラムを格納した磁気ディスク等のプログラム記憶媒体から構成されている。作業用メモリ２２４は、ＣＰＵ２２１が制御プログラムを実行する際に一時的に必要とされる各種データを格納するメモリで構成されている。

入出力回路２２５は、キーボード２３１、マウス２３２等の入力機器と、液晶ディスプレイ２３３等の出力機器を接続しており、オペレータや保守要員とのインターフェースをとるようになっている。通信制御回路２２６は、図１に示したインターネット２０１および必要に応じて電話回線等の通信手段２１５と接続するようになっている。コンテンツ格納部２２７は、このイベント企画サーバ２０２が所有するホームページのコンテンツを格納するようになっている。このコンテンツの中には、後に説明するように各種申込書等のページも含まれている。データベース２２８には、イベントの参加者の履歴や、デパート（ショッピングセンタ、駅ビル、あるいは公共団体等の各種団体を包括している。）の売り場の配置、過去に開催した各種イベント等の新たに開催するイベントの参考になる各種情報が格納されている。ホームページのコンテンツには、一般向けのイベント情報が存在しており、これによってイベントに出品する者の商品の宣伝効果が得られる。

なお、図１に示したファイナンシャルサーバ２０３もイベント企画サーバ２０２と同様にＣＰＵやプログラム記憶媒体を備えたサーバとして構成されているので、その具体的な図示は省略する。ファイナンシャルサーバ２０３の場合には、商品別に過去のイベントにおけるユーザごとの売上高や、イベント企画サーバ２０２を運営する企画会社との取引の履歴が格納されており、イベント企画サーバ２０２から現在開催しているイベントについてのユーザごとの日々の売上げの額がインターネット２０１を介して送られてくると、報告があった売上額の総額を基にして事業運転資金の先払い可能額や手数料率が算出されるようになっている。

ここで、イベントに商品を展示し販売するユーザごとの日々の売上げの額の報告は、図１に示した通信手段２１５によって、デパート２１４の売り場での個々のユーザから電話、ファクシミリあるいは電子メールといった手段によって取得される。事業運転資金の貸し出し可能額は、このようにして得られたユーザごとのイベント期間中の総売上げの報告された額に対して、数値“１”未満で表わされる掛け率を掛けた値によって算出される。本実施例では、イベント期間中の総売上げに対するデパート２１４からの支払を、企画会社を経由してユーザに行うようにしている。したがって、企画会社は、ファイナンシャルサポートを受ける各ユーザの売上げに対するデパート２１４側の支払を担保とすることで、特別の担保を要求することなく、事業運転資金を安全にユーザに貸し出すことができる。事業運転資金の先払いは、貸し出しの行われる期間や、イベント参加者が過去に企画会社から事業運転資金の先払いを受けた回数等によって設定される。

なお、ファイナンシャルサーバ２０３の機能をイベント企画サーバ２０２内に組み込むことが可能である。また、複数の企画会社がそれぞれ独自にイベント企画サーバ２０２を所持する場合に、ファイナンシャルサーバ２０３をこれらの共用サーバとして共同で使用することも可能である。

図３は、本実施例のイベント企画システムを用いたイベント企画におけるユーザ端末側の新企画提案提出までの制御の概要を表わしたものである。図１および図２を用いて説明を行う。自分の新たに取り扱う商品あるいは既に取り扱っている商品（在庫のある商品）ではあるが新たな切り口で販売を行おうとしている商品が存在するものとする。このような商品のためにイベントの新企画を実現しようとする者としてのユーザは、イベント企画サーバ２０２によって公開されているホームページ（以下、イベントホームページと称する。）にユーザ端末を使用してアクセスする（ステップＳ３０１）。ユーザ端末は、図１に示すパーソナルコンピュータ２０４、携帯電話機２０７、ゲーム端末２０９のいずれであっても構わない。図１に示していないＰＤＡ（Personal Digital Assistant）等の他のインターネットアクセス手段をユーザ端末として使用してもよい。

イベントホームページには、企画会社の企画した各種イベントを紹介し宣伝するイベント宣伝用のページや企画会社自体を紹介するページ等の他に、新規イベント提案のページが存在している。この例の場合、ユーザは新たなイベントの提案を希望しているので、ユーザ端末を用いて新規イベント提案のページを閲覧することになる（ステップＳ３０２）。新規イベント提案のページには、所定の新企画提案フォーマットとその記入に関する説明書きが存在している。新規イベント提案者は新企画提案フォーマットに必要事項を記入する（ステップＳ３０３）。

図４は、この新企画提案フォーマットの一例を示したものである。新企画提案フォーマット２４１に、企画したイベントの内容と、参加希望会社としてのユーザの氏名、連絡先を記入する。ここで、「協力」という項目には、イベント企画サーバ２０２を運営している企画会社としてのＡＢＣ企画株式会社の名称が予め記載されている。「値札」の欄には、「値札」に付けられる販売者の名称が記される。デパートでイベントが開催される場合には、そのデパートの名前が記される。

図５は、値札の一例を表わしたものである。値札２５１には、イベントを開催するデパートの名称２５２としての「Ｓｈｉｎｊｕｋｕｙａ」と、コード情報２５３としての「ＡＢ １２３４５−６７８９ ０Ｔ」と、販売価格２５４としての「￥５，０００．」と、バーコード情報２５５と、製造販売者２５６としての「千田商会」やその他の情報が記されている。値札の大きさや付けられる商品との関係でも記載される内容は異なる。一般に、コード情報２５３は、イベントの売り上げに対する支払い先を特定する情報や、その支払い先が独自に付加する情報およびイベント開催側のデパート側が独自に付加する情報等の情報で構成されている。

本実施例で使用する値札２５１では、コード情報２５３の上位２桁の文字がイベントの売り上げに対する支払い先を示している。通常のイベント開催の場合、この支払い先にはユーザを表わす情報が記されたり、企画会社を通じて、すなわち企画会社の口座を利用して出店している場合には、企画会社を表わす情報が記されている。そして、ユーザの売り上げに相当する金額が、このコード部分を基にしてユーザ側、あるいは企画会社を通じて出店している場合には、主催者から企画会社に一度入金され、企画会社からユーザに支払いが行われることになる。本実施例ではユーザが企画会社からファイナンシャルサポートを受けることを条件として、この支払い先を示すコード部分に企画会社を表わすコード情報が割り当てられる。たとえばコード情報「ＡＢ」は、ＡＢＣ企画株式会社を特定するコード情報である。このようにＡＢＣ企画株式会社の名称を記載した場合には、デパートからの支払がＡＢＣ企画株式会社を経由してユーザに行われることになる。したがって、この場合にはＡＢＣ企画株式会社がそのユーザに対して、デパートの支払を担保とする独自のファイナンシャルサポートを行うことが可能になる。これについては後に詳細に説明する。

新企画提案フォーマット２４１への記載が終了したら、ユーザはユーザ端末を使用して、新企画提案フォーマット２４１の記されたページに配置された「送信ボタン」をクリックする（ステップＳ３０４：Ｙ）。これにより、記入内容がイベント企画サーバ２０２の作業用メモリ２２４における企画担当用メモリ領域に送信されることになる（ステップＳ３０５）。

なお、図４に示した新企画提案フォーマット２４１では、イベントの開催される「期間」を１通りだけ記載することにしているが、幾通りかの開催希望の「期間」を希望順位と共に記載できるようにしてもよいし、ある程度長い期間（たとえば１ヶ月）を設定して、その中の任意の期間（たとえば１週間）に開催を希望するといった指定を行うことも可能である。「展開会場」については、場所とデパートの名称を具体的に指定することもできるし、単に場所を指定して、会場を一任したり、あるいは逆にデパート名を具体的に指定して場所を東京都内というように広範囲に指定することも可能である。

図６は、受信した新企画提案に対する企画会社側の処理の流れを表わしたものである。ＡＢＣ企画株式会社側では、イベント企画サーバ２０２の企画担当用メモリ領域から新企画提案の内容を読み出して（ステップＳ３２１）、イベントを開催する期間や会場の希望、提案したユーザに割り当てられる売り場面積等に沿って、データベース２２８（図２）から新規イベント提案者の提案するイベントの開催が可能な会場と開催期間の候補を探し出す（ステップＳ３２２）。このとき、ユーザ側が希望する優先順位の高いものに合致する候補については得点を高くする。候補が複数の場合には、最も適する候補から順位が付けられる。このようにして得られた会場等の選別結果および新企画提案の内容は、イベント企画サーバ２０２のディスプレイに表示される（ステップＳ３２３）。オペレータは、選別結果と新企画提案の内容とを比較して、内容的に満足のいくものであれば液晶ディスプレイ２３３（図２）に表示された送信ボタンを選択する（ステップＳ３２４：Ｙ）。この場合には、選別結果を基に、予め用意された所定のフォーマットの企画書の作成が行われ（ステップＳ３２５）、これがイベント企画サーバ２０２から新企画提案フォーマット２４１を提出したユーザ端末に送信される（ステップＳ３２６）。企画書は、たとえば電子メールの形でパーソナルコンピュータ２０４等のユーザ端末に送られるが、内容によってはファクシミリで送信することも可能である。複数の候補内容の列挙が可能であれば、企画書には、これらが併記される。

一方、ステップＳ３２３で表示された選別結果が満足のいかないものであった場合、すなわち会場等の既存の項目に対する検索結果が新たな企画の実現に不十分で改良の余地があるとオペレータが判別した場合、そのオペレータは同じく液晶ディスプレイ２３３に表示されている修正ボタンを押す（ステップＳ３２４：Ｎ、Ｓ３２７：Ｙ）。この場合には所定の修正処理が行われ（ステップＳ３２８）、その後にステップＳ３２２の処理に戻ることになる。このようにして、オペレータとしての企画会社の担当者が自己の経験等を用いて満足する企画内容が出来上がったと判別した時点で、その内容を基にした企画書が所定のフォーマットで自動的に作成され（ステップＳ３２５）、ユーザに送出されることになる。

図７は、企画会社の行う企画およびデータベースの修正処理の内容を示したものであり、図６のステップＳ３２８で示した処理を具体的に表わしたものである。図６のステップＳ３２７で企画会社のオペレータが修正ボタンを選択した場合には、ステップＳ３２８で修正処理が行われることになるが、オペレータはユーザの提示した新企画提案の内容が十分具体化され内容的に特定されたものであるかどうかを判別し、その結果に応じて「特定済み」であるか否かを示すボタン操作を、図２に示したキーボード２３１あるいはマウス２３２を使用して行う（ステップＳ３４１）。新企画提案の内容の記載が不正確であったり、必要な事項が記入されていないことにより企画書作成のための元となるデータが不完全なものである場合には（Ｎ）、企画会社のオペレータによる企画提案内容の再入力が行われる（ステップＳ３４２）。

この再入力は、企画会社に送信されてきた新企画提案フォーマット２４１の内容の部分的な追加、削除等の訂正である場合が多い。この際、オペレータは新企画提案フォーマット２４１を提出したユーザに直接、電話を掛けたり、あるいは電子メールやファクシミリといった通信手段を使用して、企画内容を特定させる作業を行うことになる。このときに、知識と経験を基にして企画会社から企画内容のアドバイスも必要に応じて行われ、抽象的な企画内容あるいは開催期間等の記載内容に不備のある企画内容をユーザの商品の売り込みに最も適した企画内容に訂正する。場合によっては、ユーザから新企画提案フォーマット２４１の記載内容を再提出させることもできるが、この場合には図６に示した処理がステップＳ３２１から再開することになる。

一方、ステップＳ３４１でユーザの提出あるいは訂正した新企画提案の内容が十分特定されたものであるにもかかわらず（Ｙ）、開催可能なデパートがデータベース上に存在しないような理由で、ユーザが新規イベントを開催できない場合がある。このような場合、企画会社のオペレータはデータベース２２８の開催会場としての「デパート」の項目における新たなデパートの追加等の修正によってそのユーザがイベントを開催できるようになるか否かを判別する（ステップＳ３４３）。そして、可能な場合には（Ｙ）、その結果をデータベース２２８の修正の形でキーボード２３１等で入力操作を行う（ステップＳ３４４）。

たとえば、中古デジタルカメラと中古周辺機器の展示即売会を東京地区で２月１０日ごろから１週間開催したいという新規イベントの企画が依頼されたものとする。企画会社のデータベース２２８では、その期間の現在登録しているデパートの催し物会場がすべて予約で埋まっていたとする。この場合には、東京都内の他のデパートの催し物会場で予約がされていないものを調べ、そのデパートと交渉し、イベントが開催可能であればその内容をデータベース２２８に追加する。また、カメラ売り場やこれに隣接する他の商品の売り場に若干のスペースがあるデパートをデータベース２２８で検索して、ユーザの希望する売り場面積との関係で、カメラ売り場の一角で中古デジタルカメラと中古周辺機器の展示即売会が可能であるかも調査する。このような形式でイベントが開催可能であればその内容をデータベース２２８における「デパート」の項目に追加する。このようにして、既存のデータベースに対する修正登録が行われる（ステップＳ３４４）。

データベース２２８に対する以上のような修正が不可能な場合には（ステップＳ３４３：Ｎ）、ステップＳ３４２の処理に進み、ユーザ側と話し合って企画提案内容の修正が行われることになる。たとえば、開催期間を変更して新規イベントを開催することをユーザに打診して、新企画提案フォーマット２４１の内容の修正を行うことになる。

なお、斬新な企画が登場したような場合には、データベース２２８に設定された「デパート」の項目の中からイベントに最適な会場を探し出せない場合がある。このような場合、オペレータはイベントの趣旨をユーザと論議した後、必要により新たな項目をデータベース２２８に追加する。たとえば浜辺でのイベントが最適であると判断した場合には、「浜辺」の項目を新設し、候補地となる幾つかの浜辺をデータベース２２８に追加する。このようにして、データベース自体が発展し進化していく。このようなデータベース２２８は、たとえば定期的に登録されている情報を最新の情報に更新することも必要である。

図８は、企画会社から企画書の送信があった際のユーザ端末側の処理の流れを示したものである。ユーザ端末は、送信されてきた企画書の内容をそのディスプレイに表示して（ステップＳ３６１）、この内容を検討する。この結果、１つあるいは複数の候補内容の中から満足するものがあれば（ステップＳ３６２：Ｙ）、希望する企画の内容を選択してイベント企画サーバ２０２側の契約用メモリ領域に送信する（ステップＳ３６３）。

これに対して、企画内容に満足しない場合には（ステップＳ３６２：Ｎ）、新企画提案フォーマット２４１に修正案を記入する（ステップＳ３６４）。ただし、この段階でユーザは企画会社のオペレータとパーソナルコンピュータ２０４等のユーザ端末を使用して電子メール等で話し合いを行い、有効かつ実現可能な新規イベントの開催に関するアドバイスを受ける。新企画提案フォーマット２４１の修正案の記入が終了したら、ユーザは「送信ボタン」をクリックする（ステップＳ３６５：Ｙ）。これにより、記入内容がイベント企画サーバ２０２の作業用メモリ２２４における企画担当用メモリ領域に送信されることになる（ステップＳ３６６）。

図９は、企画内容が確定した場合のイベント企画サーバ側の処理を表わしたものである。作業用メモリ２２４における契約用メモリ領域にユーザの希望する企画内容が格納されると（ステップＳ３８１：Ｙ）、イベント企画サーバ２０２はこれを読み出して、新規イベントを開催するユーザがその企画会社で新規の顧客であるかどうかをデータベース２２８を用いて検索する（ステップＳ３８２）。新規である場合には（Ｙ）、そのユーザの取引先の概要を示す取引先概要書類と今回のイベントの企画についての契約書の提出を電子メール等の通信手段を使用してユーザ端末に要求する（ステップＳ３８３）。

ステップＳ３８２でそのユーザがその企画会社で過去に取引があるものであることが判明した場合には、すなわち、そのユーザの取引先概要書類が存在した場合には（Ｎ）、今回のイベントの企画についての契約書の提出のみの要求を行う（ステップＳ３８４）。ただし、ユーザの取引先概要書類が存在している場合であっても、最近の取引から所定の年月が経過しているような場合には、最新の取引先概要書類の提出を要求することは可能である。

図１０は、企画会社側がユーザ側に要求する取引先概要書類の一例を示している。また、図１１は契約書の一例を示している。これらはユーザがパーソナルコンピュータ２０４等のユーザ端末を使用して、イベント企画サーバ２０２のホームページからダウンロードすることができる。これらの書類が事前にホームページ上で公開されることで、ユーザは契約内容を事前に十分理解することができ、また契約内容の不明な点を企画会社に問い合わせることができる。もちろん、特殊な契約条項を設けることが必要な場合には、ユーザ側から、あるいは企画会社側からその旨の提案が行われ、当事者間に有効な契約書の作成が電子メール等の通信手段を使用して検討されることは可能である。図１１に示した契約書における「掛け率」については、後に説明するように、企画会社側がユーザとの過去の取引や、今回取り扱う商品の性格等によって提案し、双方の合意によって定められる。商品の性格とは、商品の希少性、返品率や故障の割合等をいう。本実施例では、基本的にはユーザは企画会社の口座を利用して出店している。このため、ユーザに対するデパートの支払いが企画会社を経由して行われることをユーザ側が承諾した場合、企画会社はデパートからの支払いを担保としてファイナンシャルサポートを行うことができるが、商品の返品率が高いような場合には、ファイナンシャルサポートとして算出される金額の上限を抑えたり、手数料を高めに設定する必要があるからである。

以上のようにして契約書の提出があると、新規イベントの開催の契約が成立し、ユーザは契約内容のイベントを開催することができる。ファイナンシャルサポートについては後に一括して説明する。

＜企画会社開催イベントへの参加＞

以上の説明では、新規イベントの開催を企画会社に依頼する場合を示したが、企画会社がいくつかのイベントを提示し、ユーザがこの中から所望のイベントを選択して参加を依頼する場合もある。この場合を次に説明する。

図１２は、企画会社がホームページ上に提示したイベントにユーザが参加を依頼する場合のユーザ端末の処理の流れを表わしたものである。イベントホームページには、図３で説明した新規イベント提案者のページの他に、企画会社の企画した各種イベントを紹介し参加を募集するイベント参加用のページが存在している。この例の場合、ユーザはイベント企画サーバ２０２のホームページにアクセスして（ステップＳ４０１）、イベント参加用のページを閲覧することになる（ステップＳ４０２）。イベント参加用のページには、企画会社の企画したイベント案内が掲載されている。

図１３は、ホームページに示されたイベント案内の一例を示したものである。この例では文字のみの情報として示しているが、適宜、カラー写真等の写真やイラストを挿入することで、イベントの内容を分かり易く紹介してもよい。また、ここではホームページに挙げられたイベントの１つの例を示したが、分野別に複数のイベントを掲載し、これらの中から所望のイベントをユーザ側がサーチできるようにしてもよい。

ユーザは参加したいイベントが存在したら、イベント参加応募フォーマットに必要事項を記入する（ステップＳ４０３）。イベント参加応募フォーマットは、図４に示した新企画提案フォーマットに準じたものとなるので、ここでは図示を省略する。イベント参加応募フォーマットには、参加したいイベント名と、ユーザの会社のセールスポイント、販売目標、出品する商品、希望する売り場面積等が記載されることになる。

イベント参加応募フォーマットへの記載が終了したら、ユーザはユーザ端末を使用して、イベント参加応募フォーマットの記されたページに配置された「送信ボタン」をクリックする（ステップＳ４０４：Ｙ）。これにより、記入内容がイベント企画サーバ２０２の作業用メモリ２２４における応募担当用メモリ領域に送信されることになる（ステップＳ４０５）。

図１４は、受信したイベント参加応募に対する企画会社側の処理の流れを表わしたものである。企画会社側では、イベント企画サーバ２０２の応募担当用メモリ領域からイベント参加応募内容を読み出して（ステップＳ４２１）、当該イベントにおけるユーザの希望した売り場面積が存在するか等の所定の条件を応募内容が満たしているかどうかを、データベース２２８に格納されているそのイベントの必要条件および残っている売り場の区画等を用いてチェックする。

イベント企画サーバ２０２は、所定の条件を応募内容が満たしていると判別した場合（ステップＳ４２２：Ｙ）、該当するユーザがその企画会社で新規の顧客であるかどうかをデータベース２２８を用いて検索する（ステップＳ４２３）。新規である場合には（Ｙ）、そのユーザの取引先の概要を示す取引先概要書類と今回のイベント参加についての契約書の提出を電子メール等の通信手段を使用してユーザ端末に要求する（ステップＳ４２４）。

ステップＳ４２３でそのユーザがその企画会社で過去に取引があるものであることが判明した場合には、すなわち、そのユーザの取引先概要書類が存在した場合には（Ｎ）、今回のイベント参加についての契約書の提出のみの要求を行う（ステップＳ４２５）。ただし、ユーザの取引先概要書類が存在している場合であっても、最近の取引から所定の年月が経過しているような場合には、最新の取引先概要書類の提出を要求することは可能である。以上の処理は図９のステップＳ３８２〜Ｓ３８４と同様である。取引先概要書類および契約書については、図１０および図１１で説明した。

一方、ステップＳ４２２で条件の少なくとも１つを満足していないと判別された場合には（Ｎ）、満足していない条件が液晶ディスプレイ２３３（図２）に表示される（ステップＳ４２６）。この段階で、イベント企画サーバ２０２のオペレータはイベントに参加しようとしているユーザと、電話、ファクシミリあるいは電子メール等の通信手段を使用して条件について話し合い、応募内容の修正入力を行う（ステップＳ４２７）。たとえば、ユーザの希望した区画は確保できないが、１つ小さい区画や１つ大きい区画が空いているような場合には、区画の変更について交渉することになる。このような修正によって条件が満たされれば、図示しない「完了」ボタンが押され（ステップＳ４２８：Ｙ）、ステップＳ４２３に処理が移ることになる。

条件不備に対する修正が完了せず、オペレータがユーザのイベント参加を断念し、図示しない「断念」ボタンが押されたときには（ステップＳ４２９）、イベント参加が実現せずに処理が終了することになる（エンド）。

なお、ユーザは販売予定の商品が新しく開発されたような場合に、販売商品を売り込むためのリストを添付して、企画会社に送付し、その商品の積極的な売り込みのためのアドバイスを得ることもできる。在庫を抱えた商品についても、同様に売り込みのための専門的なアドバイスを得ることができる。

図１５は、このような販売商品リストの一例を示したものである。

＜ファイナンシャルサポート＞

次に、新企画提案によるイベントの実現、あるいは企画会社のイベント参加におけるファイナンシャルサポートについて説明する。ユーザは銀行等の金融機関に事業運転資金を借りる必要なく、また特別の手続きや担保を要求されることなく、企画会社あるいはその関連会社から事業運転資金を借りることができる。

図１６は、本実施例におけるイベントによる入出金の経路を従来と比較して表わしたものである。従来では、ユーザ５０１が値札２５１（図５）にユーザ自身を支払い先とするコード部分５０２を記すか、あるいは企画会社を通じて出店している場合には企画会社５０７を支払い先とするコード部分５１１を記してイベントを開催し、あるいはイベントに参加していた。このため、デパート２１４はイベントの終了後にデパート２１４側の所定の手数料を差し引いて、ユーザ５０１の指定した金融機関５０４の口座に対して入金５０５を直接行っている。また、企画会社５０７を通じて（企画会社５０７の口座を利用して）出店しているユーザ５０１の場合、デパート２１４は、企画会社５０７の指定した金融機関５２１に対してデパート２１４の所定の手数料を差し引いて入金５２２を行う。企画会社５０７は、デパート２１４からの入金を確認した後、企画会社５０７の所定の手数料を差し引いて、ユーザ５０１の指定した金融機関５２３に入金５０８が行われる。これらの入金５２２、５０８はイベント終了後の数ヶ月経過後である場合もある。

このように、従来ではイベントの開催から、その売り上げを回収するまでに最長で数ヶ月を要していた。このため、ユーザ５０１は金融機関５０４から事業運転資金の仕入れ代金等の融資５０９を受ける必要がある場合があったが、迅速な仕入れ代金等の融資が不可能で、急遽、イベントに参加するチャンスが到来したような場合にも、資金繰りがつかず、参加そのものを断念しなければならない場合も多かった。

一方、本実施例のファイナンシャルサポートでは、ユーザ５０１の取り扱う商品に付ける値札２５１に企画会社を支払い先とするコード部分５１１を付けている。このため、デパート２１４は企画会社５０７にユーザ５０１の売り上げに対応した入金５２２を行う。企画会社５０７は、この入金５２２を待つことなく、ユーザ５０１の求めに応じて、売り上げの予想額に“１”以下の所定の掛け率を掛けた額を最大値とした仕入れ代金等の先払い額を設定し、イベント企画に関与した自社の手数料と、仕入れ代金等の先払いに対する所定の金利手数料の合算された額を差し引いた額をユーザ５０１に振り込むようにしている。

仕入れ代金等の先払いに基づくこの振込みは、イベントが終了してからたとえば１週間以内という迅速さで行うことができ、また、必要な場合にはイベントの開催期間の後半で前半部分の売り上げに見合った金額の仕入れ代金等の先払いを行うことも可能である。企画会社５０７は、イベントが終了して、最長で数ヵ月後にデパートからユーザ５０１の売り上げに対する入金５２２を受けることになる。

なお、仕入れ代金等の先払いの額の基礎となるイベントによる日々の売り上げは、値札ごとの集計結果で売り場ごとに概算を把握することができる。これを企画会社５０７の担当者がデパート２１４の該当する売り場に電話したり、電子メールやファクシミリで報告を受信することで、把握すればよい。

図１７は、ファイナンシャルサポートを行うファイナンシャルサーバの制御の概要を表わしたものである。ファイナンシャルサーバ２０３は、図示しない制御プログラムをＣＰＵが実行することによって実現するもので、独自のデータベース（図示せず）を備えている。ＣＰＵは、イベント企画サーバ２０２から仕入れ代金等の先払い条件をユーザ５０１に提示する要求（ステップＳ６０１）あるいは該当するイベント終了の通知（ステップＳ６０２）が来るのを待機している。

仕入れ代金等の先払い条件提示の要求があった場合には（ステップＳ６０１：Ｙ）、そのデータベースを使用して売り上げに対する仕入れ代金等の先払い額の掛け率を検索する（ステップＳ６０３）。掛け率は、商品の返却率等に応じてリスト化されている。次にＣＰＵはこのデータベースを用いて仕入れ代金等の先払いの際の金利を算出する（ステップＳ６０４）。金利は、ユーザ５０１がこの企画会社５０７を使用した回数や、イベントを催すデパート２１４が実際にイベントに対する支払いを行うまでの期間の予測値等を勘案して設定される。以上のようにして掛け率と仕入れ代金等の先払いまでの日数を基に金利が決定されたら、これらの仕入れ代金等の先払い条件がユーザに電子メール等の通信手段で送出され、提示される（ステップＳ６０５）。

イベントが終了し、イベント企画サーバ２０２から仕入れ代金等の先払いを必要とするユーザ５０１についてのイベント終了通知が到来すると（ステップＳ６０２：Ｙ）、ファイナンシャルサーバ２０３のＣＰＵはイベント企画サーバ２０２から同時に送られてきたそのユーザ５０１の売上額の報告された額に、ステップＳ６０５でユーザ５０１に提示した掛け率を掛けた額を上限とする仕入れ代金等の先払い額を算出する（ステップＳ６０６）。そして、これをユーザ５０１側に電子メール等の通信手段で送出して提示し（ステップＳ６０７）、最終的にユーザ５０１側から仕入れ代金等の先払いの額の了承が得られると（ステップＳ６０８：Ｙ）、企画会社５０７による仕入れ代金等の先払いが直ちに実行される（ステップＳ６０９）。仕入れ代金等の先払いの額の了承が得られない場合には（ステップＳ６０８：Ｎ）、仕入れ代金等の先払いが実行されないまま処理が終了する（エンド）。

以上の制御と異なるが、既に説明したように、イベントが長期化するような特殊な場合には、ステップＳ６０２のイベント終了通知の代わりに、イベントの中間的な終了通知とそれまでの売上額の予測値を得て、仕入れ代金等の先払いをその都度行うことも可能である。

このように本実施例のファイナンシャルサポートは、商品の売り上げに対する現金の回収がたとえば１週間以内ときわめて短期間で行われるので、ユーザ５０１は新商品や在庫を抱えた商品等の販売のために各地でイベントを連続して行うときにも、事業運転資金が枯渇することがない。しかも、売り上げが増えるほど仕入れ代金等の先払いの額も増額できるので、商品の販売および仕入れに積極的に取り組むことができる。更に、銀行等の金融機関５０４に仕入れ代金等の融資を依頼する場合と比べて、仕入れ代金等の先払いが確実に行われ、かつ手続きの煩雑さや担保を必要としない利点がある。また、企画会社５０７側もユーザ５０１がデパート２１４から受け取る支払を企画会社経由の形態としたので、貸し出しを安全に行うことができる。

本発明の一実施例におけるイベント企画システムの概要を表わしたシステム構成図である。 実施例におけるイベント企画サーバの構成を表わしたブロック図である。 実施例におけるユーザ端末側の新企画提案提出までの制御の概要を表わした流れ図である。 実施例における新企画提案フォーマットの平面図である。 値札の一例を表わした平面図である。 実施例における新企画提案に対する企画会社側の処理の流れを表わした流れ図である。 実施例における企画会社の行う企画およびデータベースの修正処理の内容を示した流れ図である。 実施例におけるユーザ端末側の企画書受信処理の様子を示した流れ図である。 実施例における企画内容が確定した場合のイベント企画サーバ側の処理を示した流れ図である。 実施例における取引先概要書類の一例を示した平面図である。 実施例における契約書の一例を示した平面図である。 実施例で企画会社が提示したイベントにユーザが参加する場合のユーザ端末の処理を表わした流れ図である。 実施例でホームページに示されたイベント案内の一例を示した説明図である。 実施例でイベント参加応募に対する企画会社側の処理を示した流れ図である。 商品販売リストの一例を示す平面図である。 実施例におけるイベントによる入出金の経路を従来と比較して表わした説明図である。 実施例におけるファイナンシャルサーバの制御の概要を表わした流れ図である。 従来提案されたイベント企画システムの原理的な構成を示したシステム構成図である。

符号の説明

２００ イベント企画システム
２０１ インターネット
２０２ イベント企画サーバ
２０３ ファイナンシャルサーバ
２０４ パーソナルコンピュータ
２０７ 携帯電話機
２０９ ゲーム端末
２１１ コントローラ
２１４ デパート
２２１ ＣＰＵ
２２３ プログラム記憶媒体
２２４ 作業用メモリ
２２７ コンテンツ格納部
２２８ データベース
２５１ 値札
２５２ デパートの名称
２５３ コード情報
２５６ 製造販売者
５０１ ユーザ
５０４ 金融機関
５０７ 企画会社
５１１ 企画会社の値札

Claims (2)

1. イベントの企画者の企画したイベントに出品した出品物が販売されるたびにこれらの出品物に付されたタグに表わされる販売価格およびイベントの出品者を少なくとも表わしたコード情報を用いて前記出品者ごとの日々の売上額を集計する集計手段と、この集計手段の日々の集計結果を前記イベントに前記出品者を参加させた前記企画者宛に通信する売上額送信手段とを備えたイベント開催者側装置と、
   前記売上額送信手段によって出品者別の日々の売上額が通信されてきたときこれを受信する売上額受信手段と、この売上額受信手段の受信した出品者別の日々の売上額を基に前記イベントの期間における特定期間ごとの前記出品者の売上額を算出する期間別売上額算出手段と、イベントの出品者への直接の支払いの代わりに前記イベントの開催者が前記イベントの企画者に対してイベント終了までの販売に対する支払いを行うとき、前記イベントの開催者が前記イベントの出品者へ直接支払いを行うとする場合よりも早くこのイベントの企画者が前記イベントの出品者にその売上に対して先払いを行うとする条件の下に、前記出品者の売上額に対する数値“１”未満で表わされる先払い額の掛け率を先払いの行われる出品物の置かれる各種状況に関する前記イベントの企画者と出品者の合意内容に基づいてリスト化したデータベースと、前記イベントの出品者から前記イベントの企画者の行う前記先払いについての金額の提示の要求があったとき、前記データベースを検索して先払い額の掛け率を求める掛け率算出手段と、この掛け率算出手段で算出した先払いの額に対する先払いを行うまでの日数に基づく金利を算出する金利算出手段と、これら掛け率算出手段および金利算出手段で算出した額によって定まる前記特定期間の前記出品者の出品物の販売に対する先払いの金額を前記イベントの出品者に通信で提示する先払い金額提示手段とを備えた企画者側装置
   とを具備することを特徴とするイベント企画システム。
2. 前記特定期間は前記イベントの期間の全期間または全期間を複数に区分けしたそれぞれの期間であることを特徴とする請求項１記載のイベント企画システム。

Images