JP2009080785A - イベント管理システム - Google Patents

Abstract

【課題】システム構築・運用の負担が低減され、参加者への効果的なアプローチを行うことができるイベント管理システムを提供する。
【解決手段】ハードウェアリソース及びソフトウェアコンポーネントを利用可能にするＡＰＩを格納するＡＰＩデータベースと、イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、所定の規格に適合するＡＰＩをＡＰＩデータベースに登録するＡＰＩ登録処理部と、ＡＰＩデータベースに格納されたＡＰＩをコンポーネントとして利用してイベント実行プログラムを生成するイベント生成処理部と、生成されたイベント実行プログラムのうち、所定の規格に適合するイベント実行プログラムをイベントデータベースに登録するイベント登録処理部と、イベント実行プログラムを実行するイベント実行処理部とを備えたイベント管理システム。
【選択図】図２Ａ

Description

本発明は、コンピュータネットワークを利用してイベントの運営及び管理を行うためのイベント管理システムに関するものである。

ネットワーク通信機能を備えた携帯端末（携帯電話機、ＰＤＡ等）の普及により、インターネットを利用してイベントの運営を行うことが一般的となってきている。
イベントの運営者である企業等は、インターネット上にイベント運営用サーバを設置し、ユーザが携帯端末やＰＣ端末からサーバにアクセスすると、所定の行為を行ったり、所定の情報を得たりすることができるようにして、ユーザ参加型のイベントが進行する。

例えば、特許文献１には、展示会などで携帯端末を関係者に配布し、事前に準備された情報や緊急に変更された情報を、関連する携帯端末に配信するシステムが開示されている。
このシステムでは、イベントに携わる関係者に貸与される同一機能を有する複数の携帯端末と、携帯端末の識別コードと携帯端末に配信される個別情報とをホストコンピュータに登録し配信情報を管理するイベント事務局の配信情報管理端末と、携帯端末に対してホストコンピュータに登録された個別情報を配信するイベント事務局の情報配信サーバとを備え、配信情報管理端末により入力された携帯端末の識別コードと個別情報とを情報配信サーバから携帯端末に配信することによって、携帯端末は、受信した個別情報を表示部に表示し、または音声によって出力して利用することができるものとなっている。

また、特許文献２には、携帯電話端末やＰＤＡにＧＳＰを搭載し、位置情報から有用な情報を推定又は検索し、個人の行動を管理できるようにしたシステムが開示されている。
このシステムでは、携帯電話端末やＰＤＡに搭載されたＧＰＳ機能により、所定時間毎に位置情報が取り込まれ、当該位置情報から、その場所を代表するような場所情報や、止まっているか、歩いているか、乗り物に乗っているか等の行動情報が取得される。これらの情報を基に行動リストが作成され、個人の一日の行動が管理される。

特開２００５−１６５９０４号公報

特開２００３−７６８１８号公報

上記したようなイベント管理システムを運営・管理するためには、イベント主催者がインターネット上にイベント運営用サーバを設置し、当該サーバ上で稼動するイベント管理用プログラムを開発し、イベント開催中はシステム運用を行うこととなる。このようにイベントの開催に膨大な手間とコストがかかる上に、１つのイベントのために構築したシステムを他のイベントに流用することは難しく、個々のイベントごとにシステム開発及び運用を行わなければならないため、イベント開催の費用対効果が思うように得られないという問題があった。
また、ユーザ端末にも様々な付加機能（例えば、バーコードリーダー、動画撮像機能、赤外線送受信機能など）が存在するが、これらを利用可能とするためのシステム設計も煩雑で手間がかかるものとなっている。

一方で、イベント開催の費用対効果を向上させるには、参加者に対する効果的な広告配信を行ったり、イベントを通じて得られる参加者の属性情報等を利用して参加者のモチベーションを高めたりする方策が有効と考えられるが、従来のイベント管理システムでは、そのような方策を取るための技術的手段は何ら実現されていなかった。

本発明は、このような実情に鑑みてなされたものであり、システム構築・運用の負担が低減され、参加者への効果的なアプローチを行うことができるイベント管理システムを提供しようとするものである。

上記解決課題に鑑みて鋭意研究の結果、本発明者は、イベントの管理及び運用におけるサーバの基本的な機能をＡＰＩ（Application Program Interface）として構築し、あらゆるイベントの実行環境構築に適用可能なＡＰＩの集約として提供するイベント管理システムを発明した。例えば、参加者端末との通信機能ＡＰＩ、参加者情報管理ＡＰＩ、イベントの各シーン生成用ＡＰＩ、シーン実行用ＡＰＩ等の場面管理ノード管理ＡＰＩ、物品売買用のマーケットＡＰＩ、広告配信用ＡＰＩ、参加者端末付属機器対応インターフェイスなどである。

また、本発明者は、イベントを通じて得られる参加者の属性情報や行動情報（例えば、撮像画像、シーンに参加した場所、チャットログなど）をライフログとして蓄積し、これを利用して、参加者が関心の高そうな関連情報を配信したり、共通の情報素材を介して参加者同士のコミュニケーションを促進したりする機能を備えたイベント管理システムを発明した。

また、本発明者は、イベント主催者が広告配信用ＡＰＩを利用して広告をユーザに配信することにより広告主から広告料を収受することができる機能を備えたイベント管理システムを発明した。

より具体的には、本発明は、ハードウェアリソース及びソフトウェアコンポーネントを利用可能にするＡＰＩを格納するＡＰＩデータベースと、イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、所定の規格に適合するＡＰＩを前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、前記ＡＰＩデータベースに格納されたＡＰＩをコンポーネントとして利用してイベント実行プログラムを生成するイベント生成処理部と、前記生成されたイベント実行プログラムのうち、所定の規格に適合するイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、前記イベント実行プログラムを実行するイベント実行処理部と、ネットワークを通じてイベント参加者端末との間で情報の送受信を行う通信処理部とを備えたイベント管理システムを提供するものである。

本発明のイベント管理システムにおいて操作可能なリソースカテゴリ情報を持つイベント管理ＡＰＩとイベント管理ＡＰＩに対応するカテゴリ情報を持つリソースＡＰＩに分けて登録することを特徴とする。

本発明のデータベースに登録されるイベント実行プログラムはイベント管理ＡＰＩを順次実行する手順情報を内容とし、イベント実行前に対応するカテゴリのリソースＡＰＩを適用させることを特徴とする。

本発明のイベント管理システムにおいて、前記ＡＰＩデータベースに広告配信機能を提供するＡＰＩを格納しており、イベント実行プログラムの実行時に、イベント参加者端末に広告配信を行うことが可能であることを特徴とする。

本発明のイベント管理システムにおいて、前記広告配信を行う際に、当該イベントの主催者が過去に行ったイベントの実績情報に基づいて、当該イベントの動員人数を推計し、当該推計された動員人数に応じて広告料を自動計算することを特徴とする。

本発明のイベント管理システムにおいて、イベント実行中に参加者端末から、参加者端末において撮像した画像データ及び動画データ、録音した音声データ、掲示板、ブログ又はチャット等に投稿したメッセージデータのうち少なくとも１つを含む情報素材を受信し、当該イベントにおける当該参加者のログデータとして前記イベントデータベースに格納することを特徴とする。

本発明のイベント管理システムにおいて、イベント実行中に参加者端末から、当該参加者が関与したイベント中の場面管理ノード（後述するセッション、シーン、エリア）に関する情報を受信し、上記情報素材と関連付けて当該イベントにおける当該参加者のログデータとして前記イベントデータベースに格納することを特徴とする。

本発明のイベント管理システムにおいて、各参加者のログデータを参照し、関連性の高いログデータ同士にリンクを付与することを特徴とする。

本発明のイベント管理システムにおいて、イベント管理プログラムデータを解析してＡＰＩ呼び出しトリガの時間軸、位置範囲を拡大した拡張コンテキスト情報を抽出することを特徴とする。

本発明のイベント管理システムにおいて、上記の拡張コンテキスト情報を利用して端末インターフェイスの切り替え制御を行うことを特徴とする。また、上記の拡張コンテキスト情報を利用して端末で利用するオブジェクトのトリガ発生前に配信を行うことを特徴とする。

本発明のイベント管理システムにおいて、前記イベント生成処理部は、前記ＡＰＩデータベースに格納されたＡＰＩをコンポーネントとして利用してイベント実行プログラムを生成する際に、当該各ＡＰＩで利用するリソース間の適合性をチェックすることを特徴とする。
本発明のイベント管理システムにおいて、前記イベント生成処理部は、前記ＡＰＩデータベースに格納されたＡＰＩをコンポーネントとして利用してイベント実行プログラムを生成する際に、当該各ＡＰＩで利用する複数のリソースを１つのリソース情報に集約することを特徴とする。

以上、説明したように、本発明のイベント管理システムによれば、イベント実行プログラム作成のための共通コンポーネントがＡＰＩとして提供されているので、システム構築・運用の負担が大幅に低減される。
また、イベント参加者の属性情報や行動情報をライフログとして蓄積し利用することができるので、参加者間でのインタラクティブなコミュニケーションが活発化され、参加者のモチベーションが高められる。また、広告配信ＡＰＩを利用することにより、参加者に対して効果的な広告配信を行うことが可能となっている。

以下、添付図面を参照しながら、本発明のイベント管理システムを実施するための最良の形態を詳細に説明する。図１〜図４は、本発明の実施の形態を例示する図であり、これらの図において、同一の符号を付した部分は同一物を表わし、基本的な構成及び動作は同様であるものとする。

以下に記述されるローカルインターフェイスとは端末間での通信ネットワークを利用しない端末備え付けの交信機器を利用して相互に情報交換を行うものであって、赤外線、ＲＦＩＤ、無線ＬＡＮ等の電磁波、ＱＲコード、バーコード等のパターン認識を利用した光学手段、モデム等の音声、超音波、人体誘導等によって相互のデータ交信を行うものである。

システム構成
図１は、本発明のイベント管理システムの利用形態を概念的に説明する図である。
図１において、コンピュータシステムから構成されるイベント管理システムはインターネットに接続されており、参加者端末、イベント主催者端末、ＡＰＩ提供者端末、リソース提供者端末、広告主端末、システム管理者端末などがインターネット経由でイベント管理システムを利用する。

上記各端末は、ＰＣ端末、通信機能付き携帯電話端末、ＰＤＡその他の情報端末であってもよい。特に、参加者端末は、移動しながらシステム利用が可能な携帯端末を用いるのが好ましい。また、参加者端末は、静止画・動画撮像機能、バーコード読み取り機能、音声録音機能、赤外線通信機能、人体誘導機能等を備えている場合もあるが、本システムにおいてこれらの機能を適宜利用することも可能である。

図２Ａは、図１に示すイベント管理システムの内部構成を概略的に示す機能ブロック図である。
図２Ａに示すように、本発明のイベント管理システムは、Ｗｅｂサーバ、イベント実行部、イベント生成部、ユーザ登録管理部、ＡＰＩ登録部、イベント登録部、ユーザ登録ＤＢ、ＡＰＩ登録ＤＢ及びイベント登録ＤＢを有している。これらの処理部及びＤＢは、それぞれ独立したコンピュータで構成してもよいし、コンピュータ上のソフトウェアとして構成してもよい。

図２Ａに示すイベント管理システムにおいて、ユーザ登録管理部は、本システムのユーザ、すなわち、イベント参加者、イベント主催者、ＡＰＩ提供者、リソース提供者、広告主、システム管理者などに関する情報をユーザ登録ＤＢにおいて管理する。

ＡＰＩ登録部は、本システムにおいて利用されるＡＰＩに関する情報をＡＰＩ登録ＤＢにおいて管理する。ＡＰＩ提供者は、ＡＰＩ提供者端末より本システムにアクセスし、自己が提供するＡＰＩをＡＰＩ登録ＤＢに登録することができる。
本システムにおいて利用されるＡＰＩは、大きく二つに分けられる。一つはイベント管理用のＡＰＩでありイベント内の各シーン（イベント中のアクションの１単位）の実行、メッセージ配信およびレスポンス処理、ＧＰＳナビゲーションやゲームアトラクション実行用のサービスコンポーネント、ログデータ収集、広告配信などを行うための共通コンポーネントなどが該当する。管理ＡＰＩは直接的な操作機器やシステムを持たず、リソースＡＰＩもしくは参加者端末との交信制御手段を持つのみである。一方、イベント管理用ＡＰＩによって操作される通信接続された施設端末、ＡＶ機器、ＰＯＳシステム、カーナビ、スタッフ所持の端末、イベントで利用される食器、食品、商品、賞品、景品などの消耗品、所持品などで、通信機能あるいは記号、バーコード、ＩＣチップ等の識別機能が添付されシステムによって管理可能なイベントで利用される物品、施設、機器等のシステム利用可能な物理的実体を指すリソースや、さらにそれらのリソースを所在情報によって統合したエリアなどリソースグループ情報を利用可能なリソース管理ＡＰＩである。リソース管理ＡＰＩは適用される管理用ＡＰＩとの交信、動作を保障するためカテゴリごとに利用仕様やＡＰＩとの交信インターフェイス仕様、位置、利用可能時間、所有権、使用履歴、開封情報などの管理が必要なリソース実体の物理的、社会的な状態遷移情報を含む補足情報の利用仕様等、カテゴリ仕様を満たしている必要がある。リソースＡＰＩは個々のリソースの管理システムとの通信制御インターフェイスを持ち、実行時には通信制御が可能あるいはイベント実行中に参加者あるいはスタッフの利用する機器によってシステム的に識別可能となる機能を有している必要がある。
管理用ＡＰＩは操作可能なリソースＡＰＩのカテゴリ情報を持ち、リソースＡＰＩは管理ＡＰＩの操作仕様に対応したカテゴリ情報を持つ。

イベント登録部は、本システムにおいて実施されるイベントに関する情報をイベント登録ＤＢにおいて管理する。イベント生成部は、本システムにおいて実施されるイベントの生成を行う。イベント主催者は、イベント主催者端末より本システムにアクセスし、本システムが提供するＡＰＩを利用して自己が実施するイベントを生成し、イベント登録ＤＢに登録することができる。登録されるイベント管理プログラムはイベント管理ＡＰＩと対応するリソースカテゴリ情報を持つ。
イベントの生成及び実行には、主催者以外にも行事プランナ、ディレクタ、オペレータ、スタッフといった主体がそれぞれの権限内で関与するようにしてもよい。

イベント実行部は、イベント登録ＤＢに登録された各イベントの実行を管理する。すなわち、登録されたイベント管理プログラムに主催者がデータベースより選択したカテゴリ情報に合致するリソースを適合させ、実行可能なイベント管理プログラムを生成し、イベントを開始したならイベント参加者端末、イベント主催者端末等からの情報を受信して、所定の処理を行い、処理結果を返信することにより、イベントの進行を管理する。イベント実行時にイベント参加者端末、イベント主催者端末等に表示される画面はＷｅｂサーバにおいて生成され、送信される。

図２Ａでは、本発明のイベント管理システムの内部構成を各機能ブロックの集合として示しているが、本システムの構成はこれに限定されるものではなく、下記に説明する本システムの諸機能を実現できる任意のシステム構成をとることができる。

図２Ｂは、本システムの諸機能同士の関係を階層的に示す図である。
本図に示すように、本システムの諸機能をその共通利用性に基づき分類すると、アプリケーションレイヤ、アプリケーション支援レイヤ、共通コンポーネントレイヤ、共通基盤レイヤの４層構造となる。共通基盤レイヤ及び共通コンポーネントレイヤは、ユーザインターフェイスや外部システムに依存しない共通利用性の高い機能コンポーネントからなり、共通基盤レイヤについては、イベント管理システム以外のシステムにも適用可能な基本的な機能コンポーネントからなる。アプリケーション支援レイヤは、イベント管理システムで生成されるアプリケーション内で共通利用可能な機能コンポーネントからなり、アプリケーションレイヤは、各アプリケーション固有の機能コンポーネントからなる。
また、アプリケーションレイヤ及びアプリケーション支援レイヤの機能コンポーネントは、ユーザインターフェイス層、アプリケーションコントロール層、ドメイン層、データアクセス層の４層に機能分散される。
このような階層構造に従って、各機能コンポーネントはその下位の機能コンポーネントを利用して自己の機能を実現することができるので、各機能は独立性及び共通利用性が高くなり、本発明のイベント管理システムの特徴である外部提供ＡＰＩの登録及び利用が容易に実現できることとなる。
また本システムではイベント実行時、カテゴリ情報によってリソースと適合させる管理ＡＰＩの挙動を保障するためにリソースグループ情報をイベント実行プログラムに組み込む事が出来る。リソースグループ情報は利用可能なＡＰＩ情報とそのリソースグループに統合可能なリソースカテゴリ、その他のリソース相互の位置範囲や相互のデータ状態許容範囲、グループの可能なリソース総数情報などグループのリソース間の検証可能な条件情報を含む。利用可能なＡＰＩ情報は含まれる可能性のあるリソースのカテゴリ全てと適合可能でなくてはならない。またリソースグループに統合されるリソース情報からの抽出可能な情報を集計することによって得られるリソースグループ固有の情報を利用してリソースグループ相互の検証可能な条件情報を含め、リソースグループをメンバとして統合できるようにしても良い。
リソースグループは検証する関係性情報をリソース情報から処理する関係性処理ルーチンをもつ。検証される関係性については登録位置情報もしくはＧＰＳ情報によって得られる緯度経度情報からリソース相互の位置関係を検証するエリア条件検証ルーチン、稼働時間情報から同時稼動する時間が規定以上あり且つ適切な時間帯に稼動可能であるか検証する同時稼動条件検証ルーチン、リソースの所有権情報から同一所有者、あるいは指定した所有者群の所有するリソースであるか検証する所有条件検証ルーチン等を含んでも良い。
プログラム上の管理用ＡＰＩはリソースカテゴリではなく、利用可能なＡＰＩに含まれるならリソースグループを適合対象、あるいは条件として利用しても良い。
リソースグループは具体的なリソースを適合時に統合する。この時、条件情報がチェックされる。
リソースグループ情報はイベント実行プログラムの定義部分に記述される。また適合する実行プログラムの適合リソース情報には条件情報として統合先のリソースグループ情報が付記される。

また、本発明のイベント管理システムでは、イベント実行プログラムを含む実施されるイベントに関わるデータが一貫して構造化言語（例えば、ＸＭＬ）で記述されるようになっている。イベントの管理データは構造化言語に変換可能な場面管理ノードに統合されてノード間の階層関係、リンク関係に従って遷移する。各ノードで管理される情報は場所情報を含むリソース、参加者利用端末と関連付けて管理する参加者情報、それらを操作するためのＡＰＩ呼び出し手順情報、開始と終了に関する時間規定のいずれかを含む。ノードは最上位階層であるイベントそのものを単位とするセッションからイベントの場面管理を行うシーン、各端末に対するシーケンス操作を行うカット等が存在し、それぞれは記述あるいは登録情報の組み込みに応じてそれぞれのレベルでネストして登録される。たとえばイベント内の各シーンにおける参加者の属性情報、行動、利用データなどの項目は所定の規定に従って構造化言語で表現されることとなるので、イベントの利用が容易となり、従来のイベント管理システムと比べて、本システムの利用が大幅に促進されることが期待される。
場面管理ノード間の遷移はノード内のシーケンス操作による行動の結果、イベント実行プログラムに定められた条件を満たすと発生し、呼び出されたノードのシーケンス操作が該当する端末に対して実行される。この時呼び出し元のノードの実行は停止される場合も有れば、並行、あるいは背景処理として実行が継続される場合もある。ノード毎に異なる入力可能なレスポンスメニューを持つインターフェイスを設定しても良く、この場合どのノードのインターフェイスを利用するか、つまりどのノードの行事に参加するかは参加者の選択あるいは(３）取得コンテキスト情報によるインターフェイス管理機能を利用して選択される。
上記の階層化、ノード化により複数の登録されたイベント実行プログラムのノードを互いに組み合わせ階層化し、実行時にリソースと適合する事が可能となるが、この階層化時、参加者情報やイベント管理ＡＰＩを利用するための属性等の管理情報は通常のプログラムの変数管理と同様に統合される階層関係を辿ってノードの階層毎にグローバル情報ローカル情報に定義され統合時にはマッピングされる。すなわち上位シーンＡに下位シーンＢ，Ｃが統合され、さらにＤシーンがシーンＢに統合されるときＤで定義された属性はＤのみで利用される場合はＤのローカル定義、Ｂ以上で定義される場合はグローバル定義とされ、シーンＢで再定義されＢで利用される同じ定義型で共通の属性値を持つ必要のある管理情報とＢの定義域でマッピングされる。その情報がＡあるいはＣにおいて利用されるならさらに定義レベルを上昇させるためＢのローカル定義ではなくＡのローカル定義あるいはグローバル定義として利用される。実行時のリソース適合時にすでに決まった参加者の固有の属性情報（小売チェーンの会員情報など）があり属性型を共有するなら最上位シーンでグローバル定義しても良く、この時適合される。リソース付属の属性情報やカテゴリのみ決まっていたシステム情報なども同様である。
しかしながらこの方法では物理的実体を伴うリソース情報を統合するには不都合がある。リソース情報は時間経過に従って、場所、状態が変化する可能性がある。各場面管理ノードで必要なリソースと状態情報を単に階層関係に従って統合すると場所、状態の異なる同じ物理的な実体を持つリソースを複数適合させなくてはならないことになる。これは無駄であるし、同一のリソースの状態変化を利用するイベントは管理できないことになる。
この問題をクリアするために各ノードの遷移情報毎にそのノードでリソースを利用する場合には利用するリソースのリソースカテゴリ情報、状態情報、数量情報を遷移情報の遷移先側にノード処理に必要なリソース情報として付し、そのノードでさらにリソースの状態変化がある場合には処理が正常に終了し該当する遷移ルートに移る場合には遷移後に残る事を保障されたリソースを変化後のリソース情報と状態情報を遷移情報の遷移元に付することにする。
以下では以上のノード記述で遷移ルートに関連付けられて付記されるリソース情報を必要なリソース情報については要求リソース、保障されたリソース情報を責務リソース情報と記述する。
またノード間の遷移条件情報を処理可能としても良い。この場合、ノード定義部分にルーチン呼び出しやループ回数情報、入力遷移、あるいはグローバル定義された属性情報による可能な出力遷移ルートの変更情報を記載する必要がある。
ここで言うリソースの利用とは管理ＡＰＩによってカテゴリ適合するリソースの操作が行われるシーケンス処理で、通常の利用及び状態変化入力からリソースの状態情報の変更処理を含むものである。管理を行うリソースの状態遷移情報はリソースの消滅、イベント管理外への移行、位置関係情報、システム稼動等の利用可能情報、所有権の移動、使用、開封等のリソースの物理的社会的な状態変化情報、あるいは参加者や参加者グループとの実体的な関連付け情報のいずれかを含む。またリソースグループへの統合移行情報も含まれてよい。ノードの要求リソース情報を受けてノード内での可能な処理を施した結果の内、その遷移関係への遷移がノード内処理によって選択された時に確実に生成されているリソース状態を責務リソースとする。例えばカテゴリＡ、状態-いのリソースが１２個要求リソースとして存在した場合、その遷移関係に至るノード内処理で１つ消費し、３つ以上６つまでの所有権や場所情報が移転して状態-ろになる場合、責務リソースは（Ａ-い）５、（Ａ-ろ）３となる。さらに同じノードで別の遷移関係に移行する処理では３つ消費し、状態-はは４つ移行する場合、そちらの遷移の責務リソースは（Ａ-い）５、（Ａ−は）４となる。
以上では要求リソース、責務リソースという名称を利用したが管理ＡＰＩで利用される引数にリソースが利用される場合、その引数に利用されるリソース情報は要求リソースとして機能するし、管理ＡＰＩにおいて戻り値として変更されたリソース情報が生成される場合は責務リソースとして機能する。いずれにせよイベント管理プログラム中のリソース処理ＡＰＩで、ＡＰＩ間の処理遷移関係が定義されているイベント管理プログラムには適用可能である。
以上の関係を持ったイベント管理プログラムのリソース適合するリソース情報の最も経済的な値はノード中でのリソースの登録が行われない場合、ノード間の遷移関係においてその遷移元方向に合致する責務リソース情報を持たない全ての要求リソース情報の集計となる。この関係を維持することによってイベント進行に支障が無く、経済的なリソースの適合数量を導ける。
また要求リソース情報と責務リソース情報を利用して登録時、あるいはプログラム作成時のデバッグ時に起動する場面管理ノードに付された要求リソース情報、責務リソース情報、もしくは条件情報からイベントプログラムの整合性のチェック、要求リソース集約実行を行うことも出来る。この時属性の階層関係も同時にチェックすることとしても良い。以上は場面管理ノード間の処理であるが、それ以下のリソース処理ＡＰＩ間にもそれらの間の遷移関係が定義されているなら適用可能である。

また、イベント内の各シーンにおける参加者の属性情報、行動、利用データなどが構造化言語データの形態でログとして蓄積されるので、従来のイベント管理システムと比べて、このライフログの利用価値が非常に高くなっている。例えば、ＸＭＬタグの記述の参照により、同一イベント内の同一シーンで同じ行動を取った参加者同士を結びつけることや、ライフログを外部のネット上に公開することで参加者同士のコミュニケーションを促進することなどが可能となる。あるいはデータロード時の著作権チェックなども確実に行うことができる。

システムの動作

次に、上記のように構成された本発明のイベント管理システムの動作について説明する。
図３は、本発明のイベント管理システムにおいて、ＡＰＩ提供者端末によりＡＰＩ登録を行う際の処理の流れを示すフローチャートである。
図３において、ＡＰＩ提供者はまず、イベント管理システムから操作可能なリソースカテゴリに対応したＡＰＩ定義仕様を取得する（ステップＳ３１）。ＡＰＩ提供者は、この定義仕様に従ってＡＰＩを作成し（ステップＳ３２）、イベント管理システムに送信する（ステップＳ３３）。イベント管理システムのＡＰＩ登録部では、受信したＡＰＩの妥当性をチェックし、テスト実行を行う（ステップＳ３４）。このチェック及びテストに問題がない場合、このＡＰＩをＡＰＩ登録ＤＢに登録する（ステップＳ３５）。登録されたＡＰＩは、ＡＰＩ登録部を通じて検索・参照可能となり、イベント生成・実行の際に利用することが可能となる。
尚、リソース提供者端末によりリソースを登録する場合は、カテゴリ毎のリソース定義仕様に従いリソースを構成し、リソース利用ＡＰＩとして登録することができる。

図４は、本発明のイベント管理システムにおいて、イベント主催者端末によりイベントの生成及び登録を行う際の処理の流れを示すフローチャートである。
図４において、イベント生成者（イベント主催者その他）はまず、イベント管理システムからイベント定義仕様を取得し（ステップＳ４１）、さらに、再利用可能コンテンツを取得する（ステップＳ４２）。本発明のイベント管理システムでは、イベント間で共通するコンポーネント部分は予め登録したＡＰＩを用い、特定のリソースやイベント要素に依存しないシステム構成としているため、既に生成したイベントのうち一部のコンテンツを再利用することができる場合がある。
イベント生成者は外部エディタ等を用い、イベント管理システムのイベント生成部の機能を利用して、定義仕様に従ってイベント管理用ＡＰＩと場面管理ノードを利用してイベントを生成し（ステップＳ４３）、イベント管理システムに送信する（ステップＳ４４）。イベント管理システムのイベント登録部では、受信したイベントの妥当性をチェックし、実行可能性の有無のテストを行う（ステップＳ４５）。このチェック及びテストに問題がない場合、このイベントをイベント登録ＤＢに登録する（ステップＳ４６）。登録されたイベントは、イベント登録部を通じて検索・参照可能となり、イベント実行部により実行することが可能となる。またイベント実行時に接続可能なリソースをカテゴリ、位置、利用時間制限等の登録条件を勘案して選択する。実行時の不具合を想定して同カテゴリ近接コンテキストの代替可能なリソース群を対応する管理ＡＰＩに対して選択しておくことが望ましい。

以上のようにして本発明のイベント管理システム上で利用可能となったＡＰＩ、選択されたリソース等を利用して、イベント実行部によりイベントが実行される。

イベント実行時には主催者が選択したリソース情報とイベント管理プログラムがマージされる。カテゴリに（さらに条件がある場合には条件にも）該当するかチェックされたイベント管理プログラムはカテゴリ、条件毎にリソースとの接続チェックを行う。この接続チェックは通信可能なリソースに対しては交信を行い、システム管理可能ではあるが通信不能なリソースに関してはスタッフ端末からの登録トランザクションを呼び出してチェックを行う。ここで適合が行われるリソースはカテゴリ情報と充足数情報を最低限もち、その他の条件情報を持つ場合も有る。要求リソースの集約処理によって生成された情報を利用しても良い。このとき、リソースグループ情報がイベント実行プログラムに組み込まれていればリソースグループの条件情報の検証を行う。代替的なリソースの内でイベント管理ＡＰＩの対象が確保されカテゴリ条件に合致するリソース数あるいはリソースグループ検証等でイベント実行可能性を満たすリソースと接続が確認されたならイベント開始時刻にイベントの実行を開始する。
イベント実行部において場面管理ノードを遷移情報に従って実行してゆくことによってイベントの管理を行う。場面管理ノードが実行されると記述の読み込みがなされ、初期設定がセットされ、リソースとのリンクが確認され、初期の参加者が存在すればそのセットが行われる。重要な操作対象となるリソース、参加者管理には管理スレッドが生成され、ノードの記述（カット）に従ってＡＰＩが呼び出され、各種の操作がなされる。ノードの記述は時系列情報および端末や関連システムからのコンテキスト情報をトリガとして実行されてゆく。操作は大別して基本ブロック実行とサービスコンポーネント呼び出し、参加者場面遷移および参加者インポートに分けられる。基本ブロックは配信ステップ、レスポンスステップ、行動評価ステップからなり参加に対するメッセージの配信とレスポンスの処理を行う。サービスコンポーネントはメッセージ処理では対処できないより高度な処理を行う機能の呼び出しを行うものでＧＰＳナビゲーション、リソースＰＯＳシステム呼び出しなどの機能を持つ。参加者場面遷移によってイベントの遷移記述にしたがって条件を満たした参加者が新たな場面管理シーンを獲得する。参加者は複数の場面管理ノードに管理される事が可能である。参加者端末には現在アクティブでメッセージ内容が表示されレスポンスを返す事が可能なアクティブノードとサムネイルとして表示され選択されるとアクティブノードとなるその他のノード情報が表示される。

イベントが終了すると終了したイベント実行プログラムは実行ログ情報を追加されてデータベースにコンポーネントとして登録可能となる。実行ログには募集時の予定人数と実際の参加者人数情報が含まれる。

イベント実行時における各種機能

本発明のイベント管理システムでは、イベント実行時において下記のような機能が実現される。
（１）ライフログの蓄積及び利用
イベント開催中に参加者が携帯端末等により撮影した静止画・動画、録音した音声、掲示板、ブログ、チャット等に投稿したメッセージなどの情報素材や、イベント中で関与したセッション、シーン、カットなどの場面管理ノードに関する情報をライフログとして蓄積する。ライフログの情報素材は素材が取得された場面管理ノード情報によってタグ付けして分類・検索を容易にするのが好ましい。

これによって参加者のイベント参加ログが主催者の場面ごとの記録映像やイベント成績データなどの提供データと関連付けられて抽出できるようになる。またその場面を共有した参加者同士の情報素材を同じタグ情報で抽出できるようになる。また抽出時に参加イベントの進行上の意味のある単位で情報素材情報をまとめて取り扱うことが出来るようになる。
例えば、参加者がイベントに関連してブログページを作成すると、タグ付けされた情報素材が自動的にページ上に配置されるようにすることができる。また、イベント参加者間で共通するタグ情報をキーとして互いの情報素材をリンクすることにより、参加者同士のコミュニケーションを促進することができる。

（２）広告配信
主催者やスポンサー企業は、広告配信ＡＰＩを利用して、参加者に広告配信を行うことができる。例えば、スポンサー企業が、主催者が払うべき本システムの利用料の一部を肩代わりするといった利用形態も可能である。あるいは、イベント管理システム内に、物品販売リソースとしてマーケットサーバを構築しておき、主催者がこのリソースを利用することを条件に、リソース提供者が本システムの利用料の一部を肩代わりするようにしてもよい。

さらに、本システムによれば、イベントに関連して参加者端末に広告配信する際の広告料を自動的に決定することが可能である。主催者のイベント実行実績などを参照して主催者の参加者動員力を算出し、これを開催予定イベントの予定参加人数とを比較して予想動員数を計算し、人数に応じた広告料を算出することができる。

以上の機能は次の過程によって実現されるが機能を実現するなら任意の過程を利用して実現しても良い。
イベントの主催者はイベント実行プログラム作成時に広告配信を行おうとする広告主の作成した広告ＡＰＩをデータベースから登録、プログラムに組み込むことが出来る。広告ＡＰＩには掛け率情報が付随しており、イベント登録がなされると予定人数と主催者のイベント実行ログの動員率が集計され、予定人数に対する動員予測数が算出され、掛け率情報およびＡＰＩの予定実行回数（組み込み数）が掛け合わされ広告料が算出される。この数値は広告ＡＰＩ登録者、主催者端末に表示される。契約入力が双方の端末からなされると主催者、広告主間の課金処理が行われる。契約がなされないままイベントが実行された場合、ＡＰＩの実行は行われない。なお、課金自体は実際の参加者に対する配信数によって決る事としても良い。この場合、表示されるデータは契約の目安となる。広告配信ＡＰＩは実行されると参加者端末に広告メッセージを配信する機能を持つ。

（３）取得コンテキスト情報によるインターフェイス管理および事前データキャッシュ配信
イベント中に取得されるコンテキスト情報によって場面遷移、ＡＰＩの実行が行われるがトリガとなるコンテキスト情報の範囲を拡大することによって予測機能をも持たせ、場面情報の表示の最適化、配信メッセージの事前配信を行う。トリガの拡大はタイミング情報の時間軸の拡大、位置情報の範囲の拡大によってトリガ時間が近づいたり、トリガ範囲に進入した場合に拡大コンテキストにおいてトリガが発動される。また場所情報を持つローカルインターフェイスの受発信機と参加者端末が交信することをトリガとする場合、該当トリガは位置情報に換算されて範囲の拡大が行われる。
拡大コンテキストに同時に複数該当した場合、時間距離と範囲情報からトリガの価値が計算され拡大コンテキストに価値付けがなされる。

価値付けがなされた拡大コンテキストを所属の場面管理ノードごとに集計して最も価値の高いノードをインターフェイス画面においてアクティブノードとする。また価値の高い幾つかのノード情報をインターフェイス上の表示において上位の見やすい位置に表示させる。
また価値の高い拡大コンテキストのメッセージオブジェクト、場面管理ノードに対応したサービスコンポーネントの参加者端末での処理あるいはインターフェイスプログラムをトリガの発動前に予め参加者端末のストレージにキャッシュしておく。キャッシュされたオブジェクトを利用するトリガが発動されたならサーバからダウンロードする代わりに端末ストレージのキャッシュ情報を利用する。

以上の機能は次の過程によって実現されるが機能を実現するなら任意の過程を利用して実現しても良い。

イベント実行部の各参加者管理において参加者の所属場面管理ノードおよび遷移可能なノード情報が取得される。ノード内の拡大コンテキスト対象のトリガを持つ場面遷移、ＡＰＩ呼び出し機能の記述が抽出される。抽出された記述のトリガ情報を解析し、参加者の属性によって呼び出し対象外となる記述を除外する。処理対象の呼び出し記述の利用コンテキスト情報、種別情報、呼び出し先情報、サイズ情報が取得される。ローカルインターフェイス利用トリガの位置情報から該当とトリガを位置トリガに換算する。既定のタイミング拡張値、範囲拡張値からそれぞれの呼び出し記述を拡大コンテキスト情報に変換する。生成された拡大タイミング情報、範囲情報をマージし、マージ拡張コンテキストを生成する。これをノードの遷移が起こるたび再計算する。また各ノードの対象呼び出し記述の抽出はノードごとに予め計算しておくことにしても良い。またマージ拡張コンテキストは照合回数を減らすためセッション参加者全体やあるいは端末存在エリアごと拡張コンテキストの時間範囲ごと、それ以上の範囲でマージされても良い。

端末よりＧＰＳや基地局情報等の通信手段あるいは赤外線、ＲＦＩＤ等のローカルインターフェイス等を利用した位置情報確定手段により位置情報が取得されるかタイマーによって時間情報が取得されるとその時点での参加者マージ拡張コンテキストとの照合が行われる。合致が確認されるとマージされた拡張コンテキストのどれに該当するか検索が行われ、該当する拡張コンテキスト群が抽出同定される。同定された拡張コンテキストは発生予定時間範囲と現在時間の時間距離、発生予定範囲と現在取得位置情報の距離、ＡＰＩ種類等による乗数が取得され算出式により拡張コンテキストの現時点での価値が決定される。決定された価値を集計してノード情報表示の最適化、事前配信制御が行われる。

ノード表示最適化は同定コンテキストの価値情報をコンテキストの所属するノードごとに集計して参加者の所属ノードの価値合計リストを生成する。最も価値の高いノードをレスポンスの受諾が可能で最大限の情報が表示されるアクティブノードとして指定、端末インターフェイスにて表示を行う。またそのほかの所属ノード情報はサムネイル化されメッセージが配信されたときあるいは参加者が選択したときアクティブ化されるが上位のノードを画面の見やすい位置に配置する。

オブジェクトの配信制御は端末のストレージ容量と通信容量をまず取得する。次に同定された拡張コンテキストの配信オブジェクトのサイズを取得する。配信オブジェクトにはＡＰＩにより配信されるメッセージコンテンツおよび場面遷移によって利用されるサービスコンポーネントの端末側管理オブジェクト、管理オブジェクトの利用するデータオブジェクトのいずれかが含まれる。データ通信容量に比較してサイズの小さいオブジェクトは事前配信の必要性が小さいので一定比率以下の拡張コンテキストは足きりがなされる。この結果配信準備済みオブジェクトリストが生成される。また履歴より事前配信済みのオブジェクトリストが生成される。これから既読のメッセージが削除される。この事前配信オブジェクトリストと準備リストを比較し、準備リストからもれた事前配信オブジェクトの削除依頼を端末に送る。またストレージ容量と残存の事前配信オブジェクトからストレージ残量を算出する。このステージ残量以内で価値が高い拡張コンテキストオブジェクトから事前配信が行われる。事前配信リストに無いコンテキストトリガによる操作が呼び出された場合は割り込みでダウンロードがなされ、リストにある操作が呼び出された場合は端末ストレージからのキャッシュ呼び出し命令が配信される。

（４）利用リソース間の整合性のチェック、要求リソース集約実行システム
イベント登録部においてリソースの適合時やイベント実行プログラムの作成中のデバッグ時に呼び出し可能な、登録されたプログラムの場面管理ノードの最上位ノードに含まれる下位階層のノード群について、最上位ノードの要求リソースとその下位階層に含まれるリソースのリソース情報との整合性のチェック、下位階層のノード群の要求リソース情報の最上位ノードへの要求リソース集約実行を行う。
以上の機能は次の過程によって実現されるが機能を実現するなら任意の過程を利用して実現しても良い。
このシステムには要求リソース情報および責務リソース情報、場面間の遷移情報、あるいは条件情報、場面管理ノード情報を含み、さらに最上位ノードへの外部からの入力遷移情報、外部への出力遷移情報を持つイベント実行プログラムの入力が必要である。整合性チェックにおいては最上位ノードの要求リソース情報が必要となる。リソース情報にはリソースカテゴリ情報、状態情報、数量情報が含まれる。ノード情報には入力遷移ルート情報と付随する要求リソース情報、出力遷移情報と付随する責務リソース情報のうちいずれかが含まれてもよい。また遷移ルートごとの条件情報が含まれても良い。これらの情報を入力されたプログラム情報より抽出し、リスト形式や隣接行列等の形式でシステムのデータストレージに保持する。この時、全てのリソース情報を検索し、利用されるカテゴリ数のデータ保持領域をノード毎に確保する。各保持領域には入力遷移ルートごと、出力遷移ルートごとに要求、責務リソース情報が存在すればそれを保持する。このリソース情報はカテゴリ・状態をステイタスとする集合情報として保持される。たとえばカテゴリＡについて（い）状態が２、（ろ）状態が３であった場合｛Ａ-い，Ａ-い，Ａ-ろ，Ａ-ろ，Ａ-ろ，｝の集合として取り扱われる。存在しないカテゴリのリソース情報は空集合として取り扱われる。

まず条件情報に基づいて処理を行うノード群の展開を行う。これによって条件情報およびループの存在しないＤＡＧ（Directed Acyclic Graph、有向非巡回グラフ）型の構造にノード間構造を変更する。この展開は最上位ノードの始点、つまり下位のノード群への入力遷移ルート毎に行う。この展開はループあるいはルーチンの呼び出し回数制限あるいは条件情報による展開、入力遷移に依存する出力遷移情報によるノードの分割、属性等の与件となる情報による木構造のコピーとして行われる。なお、システムはこれら全ての条件情報処理機能を備える必要は無いが、循環構造が存在する場合はこれを解消しＤＡＧ化する必要がある。予備的あるいは本処理時のグラフ走査により処理回数制限あるいは条件情報の存在しないループ構造が発見された場合は処理不能警告を出力あるいはシステムの規定値による処理を行う。予備的な走査方法の一例を挙げれば最上位全ての始点よりノードの走査を開始し、操作の終了した遷移ルートに走査済みの符号を付する。このとき次のノードの出力遷移ルートの操作を開始するためにはそのルートの入力遷移情報全てが走査済みであるかループあるいはルーチンの条件情報が入力遷移情報に付されている必要があるとする。以上の走査を繰返し、全ての遷移情報が走査済みになる前に処理可能な遷移情報が存在しなくなった場合、未規定のルーチンが存在することになる。

最小限のルーチンの呼び出し回数制限情報を持つノード群の展開処理は以下の通りである。他の条件情報についても同様の処理を行いＤＡＧ化する。回数制限情報はルーチンの戻りノードのルーチンの最終的な入力遷移情報あるいはルーチンの最初の出力遷移情報に付されて居なくてはならない。ノード情報はリスト化されて保持されているとする。またＤＡＧ生成先のリスト領域を確保しておく。
１：ＤＡＧ生成を行う始点の入力を受け付ける。
２：始点の入力遷移情報より最初の処理ノードを指定する。
３：利用した入力遷移情報以外の入力遷移情報を除いた処理ノード情報をＤＡＧ領域にコピーする。
４：出力遷移情報を利用して次のコピーノードを指定する。
５：最上位ノードへの出力遷移情報以外の全ての出力遷移情報について処理が終了したなら次の処理ノードを遷移先のノードから指定する。３へ
６：遷移先のノードに条件情報によって遷移可能な出力ルート情報が１つも無い場合、遷移先のノードを削除する。削除処理が行われた場合、遷移元のノードも再参照し、可能な遷移先情報が一つも無くなれば同様に削除する。これは出力可能なルートが存在するノードに到達するまで繰り返される。この不能ルートは条件指定の方法によるものやノード内部の処理記述によって回避されるものとバグによるものが存在する。この削除履歴情報を警告情報として表示しても良い。この処理によって他の条件情報の処理を行うことも出来る。
７：ルーチンの回数情報を持つ遷移情報に到達した場合、その枝を辿って同じ遷移情報をコピーしたか参照する。コピーして居ない場合、その回数情報マイナス１をＤＡＧ領域上の遷移情報のルーチンの回数情報に入力する。もし、コピー情報が存在する場合、その最初に当る遷移情報の回数情報が０であった場合、その遷移ルートは不可能な遷移ルートとなり、６の処理が行われる。０で無い場合、その回数情報マイナス１をＤＡＧ領域上の遷移情報のルーチンの回数情報に入力する。
処理可能な出力情報が最上位ノードへの出力遷移情報のみとなった場合に処理は終了する。

なお、生成されるＤＡＧの規模を最小限なものにするためにリソース処理を伴わない無条件に遷移が行われる部分グラフやルーチンの除去を予め行ったり、リソース情報が変更されない無条件に遷移する部分グラフの集約を先行して行ったり、注目するリソースカテゴリや利用する属性条件毎のＤＡＧ生成処理を可能としても良い。また条件記述仕様に修正を加えて終点情報からＤＡＧを生成しても良い。さらに上記の方法の他公知の有向グラフの展開法を利用してＤＡＧ化を行っても良い。

次にＤＡＧ領域上の各ノードについて確保されたカテゴリ・ノード領域について要求リソースが一つでもあれば責務リソースが規定されていない出力遷移ルートの責務リソース情報に要求リソース情報を入力する。なお、ノード内部でリソースの登録処理がなされる場合は要求リソースが無く責務リソースのみ存在する場合がある。この処理によりノード内で該当するリソースカテゴリの利用がなされるノードの出力ルートのカテゴリ領域には責務リソースが必ず存在することになる。

次に整合性チェックあるいは要求リソースの集約が行われる。整合性チェックとは最上位の下位の場面管理ノード群の処理フローが開始されるノードへの最上位ノードの入力遷移ルートの要求リソース情報でそのノードに含まれる下階層のノード群の処理全体が賄われるかどうかの検証であり、要求リソースの集約とはそのノード群の処理を行うのに必要な最上位ノードの要求リソースを計算する方法である。
整合性チェックは始点より開始される。最初の責務リソースは最上位ノードの要求リソースとする。チェックはＤＡＧ領域上の検証元ノードの責務リソース情報と遷移先ノードの要求リソース情報を比較することによって行われる。要求リソース情報が責務リソース情報の部分集合であるならそのルートは可能ルートとなり遷移先ノードの処理、あるいはまだ検証していない検証元ノードの出力ノードのチェックを行う。不可能であった場合、その遷移履歴は不可能ルート情報として記録され、その遷移ルートの処理は中止される。この時、可能ルートなら責務リソースと要求リソースの差集合と遷移先の責務リソースの和集合を新たな遷移先の責務リソースとして扱う。これを繰返し終点まで到達した遷移ルートが可能ルートとなる。

全ての処理が終了した時点で不可能ルートが存在しなかった場合、処理は終了する。存在した場合、そのノード群はノード間遷移条件のみによっては終了を保障されないノード群となり不可能ルート情報が表示、出力される。
要求リソースの集約処理はＤＡＧ枝の終点毎に行われる。集約は集約元の要求リソース情報と遷移元の責務リソース情報を比較することによって行われる。責務リソース情報と要求リソース情報の積集合と要求リソース情報の差集合が存在した場合、遷移元の要求リソース情報と差集合の和集合を新たな遷移元の要求リソースとして扱う。これを始点まで繰返し、最初のノードの改定された要求リソース情報をそのＤＡＧ枝の集約された要求リソース情報とする。全ての枝について行った集約情報はリストあるいは全ての枝の要求リソースの和集合として表示、出力される。
上位の集約処理等で該当するノード群の集約情報を利用する場合は和集合情報を利用出力する。

以上は元ノード遷移関係をＤＡＧに展開することによって処理を行ったが、ノードの要求リソース情報と責務リソース情報あるいはノード間遷移の条件情報を利用してステップ数を減少させるため本処理時に関連する条件情報や履歴情報からの抽出情報を保持しておき、それを利用して直接元ノード情報を参照して整合性チェック、集約処理を行う事にしても良い。

（５）リソースグループの検証システム
リソース適合時リソースの選択が行われてリソースグループの検証システムが呼び出されると以下の処理が行われる。
選択されたリソースについて適合先の条件情報にあるリソースグループ情報メンバエリアに選択リソース情報を登録する。全ての選択されたリソースの参照が終了したなら、メンバリソースがリソースグループ条件を満たすか検証ルーチンを呼び出して検証する。またリソースグループの定義情報にさらにそれらを統合するリソースグループが存在した場合、統合先のメンバにリソースグループを登録する。抽出情報から検証を行うが、上位の検証は下位の検証処理が終了してから行われる。
全てのリソース及びリソースグループ処理について検証ルーチン処理において検証が成功したならシステムは適合可能のステイタスを返す。また不能なグループを検出した時点で該当するリソースグループ情報を返す。

イベント実行の詳細に関しては、以下にイベントの実施例を挙げて説明する。
本発明のイベント管理システムの一実施例として、大型展示場においてセキュリティ用品の商品展示会を開催するイベントへの適用例を説明する。２００社ほどの出展者が、国別のブースに分かれて展示商談を行う。会場内の講演エリアでは時間帯ごとに出展者や招待講演者のセミナーが行われる。

本システムは、この展示会の参加者に関して、入場者管理、会場への誘導、商談処理、セッションログ管理、会場内講演の運営・管理を行う。出展企業は配布する資料にＱＲコードを付して、配布管理を可能とする。配布資料は、印刷用データの他に、本システムのリアクションフォーム形式の配信ファイル、あるいは案内シーンオブジェクトを提出することも出来る。また、会場内にてＰＣ端末を開放し、入場者が操作出来るようにする。参加者には、ＩＣチップ読み取り装置、赤外線通信機能のあるデジタルカメラなどを貸与することも可能。
出展企業は、例えば、リアクションフォームを利用してスライド処理とガイド音声による自社出展のガイドを参加者端末に送信するパフォーマンス（ＡＰＩ）を含む会場内での誘導シーンを提出する。

この展示会への参加希望者は、ＰＣ端末又は携帯端末により参加用件情報を入力して、参加申し込みを行う。この時、商談した出展企業に提供される電子名刺情報も入力できる。予め申し込んだ参加者に対する会場受付は、例えば、ＩＣカードを利用することができる。
出展各企業スタッフ又は主催団体スタッフが運営スタッフとなる。出展企業は、自社の製品情報ファイル、製品情報提供シーンを本システムに提供する。

このようなイベントを実行するために必要なハードウェアは、本システムプロセス管理サーバ、主催者サーバ、会場設備管理サーバ、主催者会場コントロール端末、スタッフ端末、出展者サーバ、出展者使用端末、参加者利用可能端末、参加者携帯端末、参加者個人端末、貸与用ＩＣカードなどである。イベントのプログラム実行と参加各端末への情報配信、制御はプロセス管理サーバが行う。

主催者サーバは管理アプリケーションを本システムを利用して作成し、出展者情報、参加者情報を本システムより受け取る。また展示会サイトを運営し、参加受付を行う。
会場施設管理サーバは会場のスクリーン／映写設備、ＩＣチップ感知ゲート設備等を管理する。
主催者会場コントロール端末は本システム、会場設備管理サーバより情報を受け取り、会場の状況のモニタ、ディレクタ命令の発信を行う。
スタッフ端末は主催者側のスタッフの持つ端末でローカルインターフェイス受送信装置を備える。受付にも使用されＩＣカードを会場受付参加者に配布する。
出展者サーバでは印刷情報等提出情報の作成管理、送信を行う。
出展者使用端末はローカルインターフェイス受送信装置を備えて、現地の顧客（参加者）情報の管理を行う。また、出展者使用端末は、パンフレット等に印刷されたＱＲコードを読み取る機能を備え、読み取ったＱＲコードに該当する提供者情報がコンテキストタグ付けされる。
参加者利用可能端末は主催者が参加者が展示会について追加の情報を利用できるように通路、休憩所に配置したものと各ブースに供出してもらったもの。ハード的には供出端末は出展者使用端末と重なる事もありうる。携帯端末のローカルインターフェイスが機器の受送信装置とコンタクト中は本人の端末として利用可能。
参加者携帯端末は本システム受信用アプリケーションを既にインストールしてあるか、参加決定時に当社管理サーバよりインストールする。
参加者個人端末は職場や自宅のＰＣ等でインターネットを通じて主催者サーバと通信可能である。
ＩＣカードは会場のＲＦＩＤ読み取り機器と反応して参加者情報をシステムに送る。

上記イベントを実行するために必要なソフトウェア構成は次の通りである。
主催者ｗｅｂにアクセスした参加希望者がガイドとデータの自動整理を希望した場合、携帯端末アプリケーションがダウンロードされＰＣにクッキーが設定される。ｗｅｂページで出展情報のうち興味のあるものを選択すると個人領域に記録され当日のガイドに反映される。当日は注意喚起のリアクションフォームが送られ、会場まで誘導がなされる。途中、長い乗車時間や中継駅で待ち時間が発生する状況などがあれば興味のある情報に関連したメッセージが配信される（カーナビ連携なども実施可能）。
会場では参加者は携帯端末、利用可能端末を利用してメモ入力、録音を行うことが出来る。この情報は自動的にコンテキストタギング利用でタグ付けがなされて一旦サーバに保存される。利用可能端末ではコンテキスト情報の編集も可能。また、携帯端末、利用可能端末共に地図情報を呼び出して現在位置と現在向かっているエリアが表示される。また、利用可能端末では出展情報の選択をもう一度やり直してあらたなセッション（シークエンス）に登録することが出来る。
会場で利用することの出来るセッション（シークエンス）は三種類ある。一つは特定のブースへの誘導を行う誘導セッション、もう一つは興味のある分野のブースを適時案内し、情報を提供するクルーズセッション、最後にセミナーの管理を行うセミナー会場管理セッションである。これらのセッション情報は参加者端末において現在アクティブなもののメッセージが表示され、サムネイル化されたセッション情報はメッセージが到着した時点で点滅等の表示変更がなされる。
当日受付者は受付にてＩＣカードを受け取る。情報の編集と案内を参加者利用端末を利用して行う事が出来る。
会場を出ると当日のコンテキスト適用情報が整理され参加者個人端末に送信される。この情報を元に簡単な追加編集を行うだけでｗｅｂページ形式のレポートを作成することが出来る。

上記イベントを実行するために利用される本システムのＡＰＩは次の通りである。
ＧＰＳナビゲーションマップ生成：目的地と移動手段を入力するとそこまでの移動経路を出力。車両用は国道上のルート、公共交通機関はその推奨ルートが出てくるが、いずれも座標情報を伴う。その情報を元に誘導シーン用マップの生成を行う。
ＧＰＳナビゲーション呼び出し：マップで利用したナビゲーション情報を端末アプリケーションで呼び出す。また現在位置情報、（公共機関）乗り換え情報を受け取る。
興味分野情報受け取り：ｗｅｂシステム上の出展情報操作画面で選択された興味分野、訪問先情報を受け取る。この情報を元に関連シークエンスを呼び出す。
会場地図大呼出：利用可能端末画面で会場地図大を呼び出し、エリア情報を表示する。メンバシークエンスの切り替え操作と出展情報からの目的エリア選択を行うことが出来る。また興味分野情報を編集する事が出来る。結果は興味情報属性に反映される。
会場地図小呼出：携帯端末で地図表示アプリケーションを呼び出す。現在位置とアクティブシーンの目標エリアがピンポイントで表示される。
クルーズ経路作成エンジン：会場１レベルマップの経路情報から最適な経路を算出する。その順番情報を現在位置エリア情報から順序型属性として生成する。
会場施設管理サーバ：リレーショナルシステムドメイン。ゲートの入退出情報、スクリーンの上映開始、終了情報を受け取る。

上記イベントを実行するために利用される本システムのリソースＡＰＩは次の通りである。
マップ；会場は非座標付き代表点を持つ１レベルエリアで構成されたもの。スタッフ端末、出展者端末、参加者利用可能端末、ＩＣチップ感知ゲートをエリアの確定要素として持つ。特にクルーズの精度向上のため室内会場間の通路にもゲートを配置した。ＧＰＳ情報の利用は会場エリア全体をＧＰＳブロックとして指定。退出入確認に使用する。その他のマップは予め作成はされないが、誘導時にはＡＰＩによって自動生成される。
名刺ファイル；参加者の商談相手へ提供する個人情報ファイル。複数作成できる。セッションではマスカレードとして利用。
出展者提供情報ファイル；出展者の提出パンフ印刷用ファイル、リアクションシートファイル。これらのファイルは参照専用属性として保護される。
出展情報ファイル；出展者情報をエリア、興味分野ごとにタグ付けしたもの。
会場地図ファイル大；各エリアを強調表示可能。ｗｅｂスクリプトで作成。
会場地図ファイル小；エリア位置をポイント表示。携帯端末用アプリケーションとして構成。

以上、本発明のイベント管理システムについて、具体的な実施の形態を示して説明したが、本発明はこれらに限定されるものではない。当業者であれば、本発明の要旨を逸脱しない範囲内において、上記各実施形態における各種サーバ、処理部、データベース等の構成及び機能に様々な変更・改良を加えることが可能である。

本発明のイベント管理システムは、図１等に示すように、コンピュータのＣＰＵ、メモリ、補助記憶装置、ディスプレイ、入力デバイス等を含むハードウェア資源上に構築されたＯＳ、アプリケーション、データベース、ネットワークシステム等によって実現されるものであり、イベントの管理及び運用という情報処理が上記のハードウェア資源を用いて具体的に実現されるものであるから、自然法則を利用した技術的思想に該当するものであり、インターネット上のコンテンツ提供等の産業分野において利用することができるものである。

本発明のイベント管理システムの利用形態を概念的に説明する図である。 図１に示すイベント管理システムの内部構成を概略的に示す機能ブロック図である。 図１に示すイベント管理システムの各機能間の関係を階層的に示す図である。 図３は、本発明のイベント管理システムにおいて、ＡＰＩ提供者端末によりＡＰＩ登録を行う際の処理の流れを示すフローチャートである。 図４は、本発明のイベント管理システムにおいて、イベント主催者端末によりイベントの生成及び登録を行う際の処理の流れを示すフローチャートである。

Claims (13)

1. ハードウェアリソース及びソフトウェアコンポーネントを利用可能にするＡＰＩを格納するＡＰＩデータベースと、
   イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
   所定の規格に適合するＡＰＩを前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
   前記ＡＰＩデータベースに格納されたＡＰＩをコンポーネントとして利用してイベント実行プログラムを生成するイベント生成処理部と、
   前記生成されたイベント実行プログラムのうち、所定の規格に適合するイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
   前記イベント実行プログラムを実行するイベント実行処理部と、
   ネットワークを通じてイベント参加者端末との間で情報の送受信を行う通信処理部とを備えたイベント管理システム。
2. 前記ＡＰＩ登録処理部は、操作可能なリソースカテゴリ情報を持つイベント管理ＡＰＩと、イベント管理ＡＰＩに対応するカテゴリ情報を持つリソースＡＰＩとを区別して登録することを特徴とする請求項１に記載のイベント管理システム。
3. 前記イベント実行プログラムは、イベント管理ＡＰＩを順次実行する手順情報と、イベント実行前に対応するカテゴリのリソースＡＰＩを適用させるための情報とを有していることを特徴とする請求項２に記載のイベント管理システム。
4. 前記ＡＰＩデータベースに広告配信機能を提供するＡＰＩを格納しており、
   イベント実行プログラムの実行時に、イベント参加者端末に広告配信を行うことが可能であることを特徴とする請求項１から３のいずれか１項に記載のイベント管理システム。
5. 前記広告配信を行う際に、当該イベントの主催者が過去に行ったイベントの実績情報に基づいて、当該イベントの動員人数を推計し、当該推計された動員人数に応じて広告料を自動計算することを特徴とする請求項１から４のいずれか１項に記載のイベント管理システム。
6. イベント実行中に参加者端末から、参加者端末において撮像した画像データ及び動画データ、録音した音声データ、掲示板、ブログ又はチャット等に投稿したメッセージデータのうち少なくとも１つを含む情報素材を受信し、当該イベントにおける当該参加者のログデータとして前記イベントデータベースに格納することを特徴とする請求項１から５のいずれか１項に記載のイベント管理システム。
7. イベント実行中に参加者端末から、当該参加者が関与したイベント中の場面管理ノードに関する情報を受信し、当該情報と関連付けられた当該イベントにおける当該参加者のログデータとして前記イベントデータベースに格納することを特徴とする請求項１から６のいずれか１項に記載のイベント管理システム。
8. 各参加者のログデータを参照し、関連性の高いログデータ同士にリンクを付与することを特徴とする請求項６又は７に記載のイベント管理システム。
9. 前記イベント管理プログラムの処理データを解析して、ＡＰＩが利用された時間及び位置に関する拡張コンテキスト情報を抽出する処理部をさらに備えたことを特徴とする請求項１から８のいずれか１項に記載のイベント管理システム。
   
10. 前記拡張コンテキスト情報に基づいて、イベント参加者端末のインターフェイスの切り替えを制御する処理部をさらに備えたことを特徴とする請求項９に記載のイベント管理システム。
11. 前記拡張コンテキスト情報に基づいて、イベント参加者端末で利用するオブジェクトのトリガ発生前に、当該イベント参加者端末に対してコンテンツの配信を行うことを特徴とする請求項９又は１０に記載のイベント管理システム。
12. 前記イベント生成処理部は、前記ＡＰＩデータベースに格納されたＡＰＩをコンポーネントとして利用してイベント実行プログラムを生成する際に、当該各ＡＰＩで利用するリソース間の適合性をチェックすることを特徴とする請求項１から１１のいずれか１項に記載のイベント管理システム。
13. 前記イベント生成処理部は、前記ＡＰＩデータベースに格納されたＡＰＩをコンポーネントとして利用してイベント実行プログラムを生成する際に、当該各ＡＰＩで利用する複数のリソースを１つのリソース情報に集約することを特徴とする請求項１から１２のいずれか１項に記載のイベント管理システム。

Images