JP2009176269A

JP2009176269A - イベント管理システム及びイベント管理方法並びにイベント管理プログラム

Info

Publication number: JP2009176269A
Application number: JP2008184502A
Authority: JP
Inventors: Katsuhide Asanuma; 克秀浅沼
Original assignee: Fugaku Bussan Co Ltd
Current assignee: Fugaku Bussan Co Ltd
Priority date: 2007-09-18
Filing date: 2008-07-16
Publication date: 2009-08-06
Also published as: US20090265390A1

Abstract

【課題】行事を効率よく且つ適切に管理することのできるイベント管理システムを提供する。
【解決手段】本発明は、イベントに関する管理を行うためのイベント管理システム１であって、行事プランあるいは行事プラン部品を構造化文書により構築し、それらを組み合わせ実行可能な行事プランとして作成する行事プラン作成管理手段５と、イベントの参加者が使用する参加者端末２との間でメッセージの配信やレスポンスの受理を行い、行事の進行の制御を行事実施手段４と、を備えていることを特徴とする。
【選択図】図１

Description

本発明は、情報ネットワークを介して行事の参加者が使用する参加者端末及び行事の主催者が使用する主催者側端末に接続されて構成されたイベント管理システム及びイベント管理方法並びにイベント管理プログラムに関する。

行事を開催する場合、主催者の準備、日程の管理や、参加者の受付、入場管理、経理処理など多岐にわたる情報処理が必要であり、従来から行事を管理するためのイベント管理システムが提案されている。

最も身近なシステムでは、ネットワーク上で行事への入場の申し込みや入場料の支払いなどを行う電子発券システムが広く使われている。特にインターネットの普及に伴って従来のチケットエージェントが使っていた専用のオンラインシステムから、一般の人が使えるインターネット上のシステムに移行している。

特許文献１には、展示会などで携帯端末を関係者に配布し、事前に準備された情報や緊急に変更された情報を関連する携帯端末に配信するイベント管理システムが開示されている。

該システムには、行事に携わる関係者に貸与される同一機能を有する複数の携帯端末と、携帯端末の識別コードと携帯端末に配信される個別情報とをホストコンピュータに登録し配信情報を管理する行事事務局の配信情報管理端末と、携帯端末に対してホストコンピュータに登録された個別情報を配信する行事事務局の情報配信サーバとを備えている。

そして、配信情報管理端末により入力された携帯端末の識別コードと個別情報とを情報配信サーバから携帯端末に配信することによって、携帯端末は、受信した個別情報を表示部に表示し、または音声によって出力して利用することができる。

また、特許文献２には、携帯電話端末やＰＤＡにＧＰＳを搭載し、位置情報から有用な情報を推定又は検索し、行事に参加する個人の行動を管理する行動管理装置が提案されている。

該装置には、所定時間毎に位置情報を取り込む位置情報取得手段と、ＧＰＳから取り込まれた位置情報を記憶する記憶手段と、記憶手段に記憶された所定時間毎の位置情報から行動管理を行うための情報を推定又は検索する行動管理情報推定検索手段と、その推定又は検索された情報を基に行動リストを作成する行動リスト作成手段とを備えている。
特開２００５−１６５９０４号公報特開２００３−７６８１８号公報

しかしながら、上記した従来のイベント管理システムには、以下のような問題があった。
（１）行事の一回性の問題
通常ルーチン業務と異なり、行事は参加者、利用施設、時間帯が一回ごとに異なる可能性が高く、定型化しにくい。さらに、それぞれの行事の性質によって施設依存度や繰り返しの回数等にバラつきが大きく、システムの汎用性を高め、適用範囲を広げるためには頻度が低く、施設依存度の高い行事をシステム内に取り込む方法を考慮する必要がある。

また、繰り返される行事にしてもその価値は内容が前回と異なる点に有る場合が少なくない。マンネリ化した行事の集客力は急速に低下するため、個々の参加者にとって行事は参加する毎に異なっている必要がある。
（２）プランの重要性の問題
業務利用のサービスを除けば行事の目的は参加者に驚きと興味をもたらすことにあるため、提供するサービスをどの様に提供するかがきわめて重要となる。プランを考案企画する能力は、人間の楽しみに対する興味や群集心理へのセンスを必要としており、システム構築に関する技能とは異なっている。この点でシステムを構築するにはプランアプリケーションの作成者と役割分担を考慮する必要がある。

また、上記した行事の一回性の問題から行事に関するサービスを提供しようとすると大量のプランを作成し、消費する必要が生じる。
（３）行事エントリィの問題
インターネットサービスにおいてはサービスの入り口はほぼコンピュータの制御画面からに限られる。しかしながら、享受に身体の移動を必要とする行事サービスにとっては画面からのエントリィは重要な入り口ではあるが唯一ではない。

街頭の看板やディスプレイ、店頭のサービススポットや端末、或いは行事の会場そのものからのエントリィなどが必要となってくる。そのため、これらのインターフェイスの構築費用を個々のサービスで吸収するのは非常に難しい。
（４）参加者情報の管理の問題
現在、インターネット上には第二の人格とでも言うべき仮想人格情報が形成されつつある。コミュニティサイトのアバターなどの個人情報、オンラインゲームのキャラクター情報など、メディアの特性に合わせてアイデンティティをそれぞれ持つというあり方が一般的になりつつある。

現実の社会においても、かつての北米社会における秘密結社の盛隆や宗教儀礼等によるイニシエーションなどで複数の人格をコンテキストによって使い分けると言うあり方は一般的であった。イベント管理システムの訴求力を高め、普及を後押しするためには、このような属人的な参加者情報および企業の顧客情報を取り込む必要があるが、個々のサービスでこれらを実現するのは非常に困難である。
（５）情報提供形式の問題
イベント管理サービスを提供する場合、ＰＣによるサービス提供と異なり、画面への注視を前提とすることは出来ない。また、個々の行事サービスの時間範囲や提供地域は非常に多様となる事が予想される。この場合、提供中の特定の一つのサービスが端末機器のインタフェイスや機能の一部を常に占有する事は不合理である。

これを解決するためには、提供を受けているサービスの内、現在コンテキストに合致する処理のみが端末に呼び出され、そのほかのサービスはサーバ等に待機し、必要なメッセージを配信する程度とするべきである。このためには個々のサービスを管理する上位のシステムが必要となる。

本発明は、上記した各課題を解決すべくなされたものであり、一般的なイベント管理システムをＳＰ（サービスプロバイダ）として構築し、行事の主催者向けにプランアプリケーション作成機能を提供し、その運営を行うと共に、課金処理を行うことのできるイベント管理システム及びイベント管理方法並びにイベント管理プログラムを提供することを目的とするものである。

上記した目的を達成するため、本発明は、イベントに関する管理を行うためのイベント管理システムであって、行事プランあるいは行事プラン部品を構造化文書により構築し、それらを組み合わせ実行可能な行事プランとして作成する行事プラン作成管理手段と、参加者端末との間でメッセージの配信やレスポンスの受理を行い、行事の進行の制御を行う行事実施手段と、を備えていることを特徴とする。

そして、前記行事実施手段が行事の進行を制御している間に参加者のログ情報を取得し、参加者がイベント実行時に管理を受けた共通する行事プラン部品の文書あるいはノード識別情報に基づいて主催者提供情報との参照あるいはログ情報の参加者相互参照を可能とするログ公開手段をさらに備えていてもよい。

また、前記行事プラン及び行事プラン部品を公開参照可能なデータベースに登録し、行事プラン作成者が参照した行事プランと、前記行事プラン作成手段が作成した行事プランとの間の構造化文書の異同を判別し、両者の間に類似性があると判定した場合には、前記参加者に対して著作権処理してもよい。

また、本発明は、イベントに関する管理を行うためのイベント管理方法であって、行事プランを構造化文書により構築し、実行可能な行事プランとして作成する行事プラン作成管理ステップと、参加者端末との間でメッセージの配信やレスポンスの受理を行い、行事の進行の制御を行う行事実施ステップと、を備えていることを特徴とする。

そして、行事の進行を制御している間に参加者のログ情報を取得し、公開するログ公開ステップをさらに備えていてもよい。

また、前記ログ公開ステップにおいて公開された参加者のログ情報に基づき、該参加者が参照した行事プランと、前記行事プラン作成手段が作成した行事プランとの間の構造化文書の異同を判別し、両者の間に類似性があると判定した場合には、前記参加者に対して課金する課金ステップをさらに備えていてもよい。

さらに、本発明は、上記した各ステップをコンピュータに実行させるためのイベント管理プログラムである。

本発明によれば、行事を効率よく且つ適切に管理することができる。

以下、図面を参照しつつ、本発明の実施の形態について説明する。

図１に示されているように、本実施の形態に係るイベント管理システム１は、参加者が使用する参加者端末２と、オペレータが使用する主催者側端末３と、システム管理者が管理する行事実施サーバ４、プラン作成管理サーバ５、マーケット管理サーバ６、ログ公開サーバ７、及びデータベース８と、リソース提供者が管理するリソース９と、外部システム１０とを備えて構成されている。

ここで言うリソースとは参加者以外の主催者側がイベント管理に利用するＡＶ機器、ゲーム機器、課金システム端末類やＱＲコードやＩＣチップ、無線等の識別管理手段を備えた物品などの内、行事管理プランからの制御を可能とするインターフェイス用のＡＰＩをもつものである。

このイベント管理システムは最終的にはマーケット上に登録された行事プランを適宜組み合わせ、あるいは構造化言語を利用して構築し、行事実行時のリソース状況、インポート情報に適合させて実行可能な行事プランとして作成し、行事の実施を管理し、行事のプランの再登録、行事データのエクスポートを行う。行事の実施の管理とは参加者端末や会場端末にメッセージの配信を行い、レスポンスの受理を行い、行事の進行の制御を行うことと行事のアトラクションやユーティリティとなる関連アプリケーションの最適な時点での最適な参加者端末やリソースに対する呼出、制御を行うことの二点が主要な機能となる。
（Ａ）行事のプランの独立と構造文書化
本発明の第１の特徴は、行事のプランの独立である。この行事のプランの独立は、コンテキスト情報を抽象化した再利用可能な行事のプランをマーケットに登録し、それに具体的な施設等のリソースや日時等のマニュフェスト情報を付加した実行可能な行事プランを行事実行時エンジンに読み込んで実行する構成を備えている。

図２は行事プランの状態遷移を示す図であり、図３は行事プランの作成フローを示すフローチャートである。マーケットには、行事のプランの構造を記述したシナリオとマニュフェストの内容である施設等のリソース情報をカテゴライズして別々に登録する。これにより、行事のプランの再利用性を高めることができる。ＨＰ等のネット上に配置するサービスと異なり、一回性のある行事のプランは別のコンテキストで実行する場合、同様のプランであっても価値が発生するため、プランの転売市場が成立するため、これは有効である。

本発明の第２の特徴は、行事のプランの構造言語化である。行事のプラン作成者の情報技術レベルは様々である。ここでインターネットの利用拡大が単にシステムの優位性だけではなくｈｔｍｌ言語を採用したｗｗｗの発展にあることを考えると、記述言語に比べてより平易で、ｈｔｍｌと同様の構造化言語を行事のプラン作成に利用すると、イベント管理システムの普及に役立つと考えられる。

行事のプランの記述にこのような縛りを加えることによって、構造言語化が困難なレベルの制御との間で自然なレイヤの分離を行うことができ、プラン作成者は全体の構成とメッセージの内容および配信タイミング、呼び出すサービスの選択に専念することができる。本実施の形態では、構造言語化が困難なレベルの制御をまとめたものをＡＰＩ（Application Program Interface）としており、ＡＰＩは図４に示すフローにより登録される。

あるいはこれらの登録は構造化言語に逐次あるいは意味解釈を伴わない簡易な解釈によって変換可能な構造情報、遷移情報、要素情報を持つ、図２４に示すようなインデント利用テキスト形式や図２５に示すようなＸＭＬ形式で登録してもよい。このような形であれば簡易な変換プログラムを利用するのみで構造化文書の解析システムの蓄積、および知見を利用する事が可能となる。

このＡＰＩは、適宜利用可能な低レベルなコンポーネントである。本システムで提供する低レベルな機能（カットやパフォーマンスの呼出、ログの出力、標準的な配信など）や、各種リソースへアクセスするための機能などである。アトラクションやパフォーマンスは、シーンやカットで記述されるので、ここには分類しない。ＡＰＩは、シーやカットの記述の中から利用することができるし、サービスコンポーネントの中からも利用することができる。サービスコンポーネントもＡＰＩと言ってもよいが、行事のドメインや使用されるシーンを意識して凝集させた、より高度なものである。

また、サービスコンポーネントとしては、グループコミュニケーションコンポーネントの他、誘導、案内、希少性管理、グループ管理などがあり、その他、様々なベンダ提供のサービスコンポーネントが考えられる。アトラクションは、通常、いろいろなサービスの組み合わせで実現されるが、独立したサービスコンポーネントとすることも可能である。

図３０及び図３１に示すように、以上の構造言語化を実現するために行事プラン文書は三つのレベル以上の行事プランの文書からなる文書記述仕様を有している。第一のレベルは行事プランそのものを記述し、場面管理ノード間及び統合されたリソースおよび参加者機器の制御を行うための関連と各要素の挙動を記述する行事プラン記述文書であり、第二のレベルは個々のリソースおよび参加者機器にマニュフェスト可能なインターフェイスを装備するための仕様情報を定義するマニフェストリソース条件定義文書であり、第三のレベルは個々のリソースに第二の文書を適用した結果生成されるマニフェスト用のリソース情報管理文書である。マニフェスト用のリソース管理文書には個々のリソースおよび参加者機器のインターフェイス情報、カテゴリ情報、場所や利用可能時間等の属性情報、所有権情報や参照や属性値などのリソースおよび参加者機器の間の関連情報が含まれる。また、詳細情報を記述するデータ型、照会情報が含まれても良い。

プラン記述文書中のサービスコンポーネント適用情報には統合可能なリソースのカテゴリ情報が含まれ、それぞれにマニフェストのための識別名あるいはコードが付けられる。マニフェスト時にはこれらの識別子はプラン文書毎に抽出統合され、マニフェスト条件が生成される。マニフェスト条件の抽出については後述するが、その結果、識別子毎の行事実施に必要なリソースのカテゴリとリソース数が要求リソース条件として検証される。場所、時間条件は最終的に統合された行事プラン部品の場所、時間条件がその条件となる。

カテゴリ定義文書には交信とプラン側の要求するリソースの挙動を実現可能とするインターフェイス定義情報が含まれる。この要求にはセッション時の挙動実現の他にマニフェストのためにリソースのサマリ情報をＵＤＤＩ等の照会用レジストリに登録する仕様、システム側の要求によってサマリ情報を更新する仕様、参加要請を受け取り、参加可能情報を返送する仕様、自身が統合されるマニフェスト条件を受け取り登録する仕様が含まれていてもよい。この形式はＷＳＤＬのポートタイプ定義等の高度の機能要求を行うものであることが望ましい。またカテゴリ情報に従って第三の文書を生成するアプリケーションが添付されていてもよい。

次に、主に図３３を参照しつつ、行事プラン部品のリソース条件の統合に関する仕様上の特徴に関する説明を行う。

受理時にはリソース条件と合致する選択されたリソース情報との適合がなされるが、このために内部のプラン部品のリソース条件情報、および属性のスコープ情報を統合する必要がある。

このため、本システムにおいてはプラン部品を階層化し、最上位の文書の要素として統合する。また、各プラン部品の属性やリソースの定義情報は部品毎にローカル定義であるか、グローバル定義であるかが定義される。上位のプラン部品においては統合された下位の部品の定義をさらにグローバル定義として上位の部品の定義に任せるか、その階層でローカル定義するかの記述がなされていなくてはならない。最終的に最上位のプラン部品の定義においてグローバル定義された要素がマニフェスト条件となり、適合の対象となる。

ここで定義されるリソースの情報とは、そのマーケット上のカテゴリ情報、重要な状態遷移情報であり、後述の要求リソース情報としてプラン部品の状態遷移関係を参照して整理され上位のプラン部品の要求リソースとして統合される。

リソースのローカル定義とはプラン部品作成段階で具体的なリソースと適合が行われる形で部品のマーケットへの提供がなされることを意味する。ローカル定義されたリソースはリソースの選択が不可能で具体的なリソースＩＤが定義情報に記述されている。

属性の定義とはその属性値をどの段階で保持するかの定義である。グローバル定義された属性はその上位の何れかの階層で値が保持される。上位の階層ではグローバル定義された下位階層の属性情報をローカルに定義するか、さらに上の階層へ上げるかを記述する必要がある。また、属性型が同一かコンバートできる属性型同士をマッピング記述し、複数の下位でグローバル定義された属性同士を、一つのそれ未満の階層でのグローバル属性として再定義することができる。最上位でグローバル定義された属性情報はマニフェスト時に扱いが決定される。

すなわち、実行時には属性定義情報、もしくは下位の属性情報あるいはマッピング情報が保持されているマッピング情報を読み込んだ解析機はグローバル定義されている場合には、その定義情報を保持し、上位のマッピング及びスコープ定義記述を参照し、リストに追加情報を保持する。また、ローカル定義されている場合には、その階層のシーケンスオブジェクト領域に再定義された属性型の領域およびマッピングされた属性の参照情報保持領域を確保する。

属性の初期値についてもローカル定義時点で扱いが決定される。デフォルト値を定義するのか、外部参照を行うのかを指定することになる。

図３１に示すように、マニフェスト時のプラン管理システムと各文書の動作は以下のとおりである。

まず、プラン記述文書を登録したマニフェストシステムはセッション情報登録待ち受け状態となる。この時登録したプラン登録文書名と関連付けられたセッション情報が入力されるとマニフェストが始まる。セッション情報には行事開始時間情報、マニフェスト条件となる行事プラン部品の場所情報が含まれる。

マニフェストが開始されるとマニフェスト条件が統合検証される。この統合時には関連出願によるリソース数量の統合の検証が行われ、また、仕様に従って文法の検証が行われる。さらに、定義間の依存関係が検証される。所有権、参照や属性値などリソース間の関連情報を条件、あるいは引数として利用した結果関数によって得られる属性値を条件とするマニフェスト条件が抽出される。その結果、他のマニフェスト条件への依存の存在しないリソース、参加者のマニフェスト条件からチェックされ、他のマニフェスト条件に依存する項はすでにチェックされたマニフェスト条件にのみ依存するかを検証し、そうならチェックされる。これを繰り返し、先にチェックした条件を優先的に並べたマニフェスト条件のチェックシーケンスを生成する。共依存関係が存在するなら文法上の例外となる。

さらに、この共依存関係に対する制限を緩和するために依存関係に計算上の優先関係を設定してもよい。この場合、優先順位のレベルごとにチェックシーケンスがつくられる。最初の文法チェックにおいては各依存関係のレベル内で共依存が発生していなければ例外は発生しない。

その後、さらに参加要請が開始される。他のリソースに依存しないマニフェスト条件と合致するサマリ情報が照会レジストリで検索され、合致したリソースに情報更新要求がなされる。更新された情報とリソース条件の適用に問題が無ければリソースにオファーが送信される。この更新情報はサマリよりも詳細にすることもできる。このことにより、位置状態など変動が激しい詳細情報をサマリに登録することによって適用可能なリソース数を少なくすることを防げることができる。

オファーに対して規定時間内にリソースより参加可能メッセージが返信された場合、統合条件に従って規定数のリソースが確定され統合される。この時、チェックシーケンスの優先順位に従って条件が検証される。関連情報についてはすでに確定されたリソースとの関連条件を満たさなければ統合条件を満たしたとは確定されない。もし、依存関係に優先順位が存在する場合には、優先順位の低い依存関係は最初の計算時には無視される。そして、確定したリソース、参加者情報に対して低い関係によるチェックシーケンスが適用され、さらに確定するリソースが絞られる。これをすべての依存関係のレベルごとに行い、最終的に参加するリソース、参加者が確定される。

確定されたリソースに登録情報が返され、システム側に個々のインターフェイス情報を含んだリソース管理用のインスタンスが生成される。

この構造言語の仕様は効率よく行事を管理するために以下のようにすることができる。場面を管理する行事プラン部品の制御内容記述を要素としてその構造化された集合として行事プランを構成する。各要素はＡＰＩの呼び出しか、下位要素の呼び出し記述とそれらの呼び出し条件、タイミング、参加者やリソースなどのＡＰＩの適用先情報を有している。また、下位の要素およびその要素内で利用されるリソースの定義情報を有していてもよい。

図３２に示すように、ＡＰＩおよび適用対象のリソース、参加者情報は管理機器とのコミュニケーション方法によってカテゴライズされる。カテゴリはプラン管理システムサーバ、ＡＰＩ管理サーバ（プラン管理サーバのコンポーネント）、リソース、参加者の管理機器（図中ではクライアント）のそれぞれが利用可能なＷＳＤＬのポートタイプの組み合わせの集合で定義される。リソース、参加者のカテゴリ情報はそれぞれの管理機器がプラン管理サーバ、ＡＰＩ管理サーバから受け取り可能なポートタイプ、メッセージ情報で構成される。ＡＰＩのカテゴリ情報は適用可能なリソース、参加者のカテゴリ情報あるいは直接的にポートタイプ、メッセージ情報で構成され、プラン管理サーバとの交信のためのポートタイプ、メッセージ情報が付け加えられる。またプランが管理すべきパート情報を抽出列記してもよい。

下位要素あるいはＡＰＩの呼び出し記述はその要素が呼び出された時にどのようなプロセスと条件で呼び出されてゆくかは行事プラン部品の制御構造に従って記述される。要素の定義は下記のプラン部品の統合上の仕様によって記述される。リソースの必要数量の検定のために関連出願の利用を行ってもよい。

ＷＳＤＬをカテゴリ定義に利用する場合、マニフェスト時には文書のマニフェスト条件を有する項のポートタイプ情報にインスタンス毎に合致するバインディング情報がセットされる。

以上の仕様を解釈可能な解析機を行事実施サーバに設置することによって行事部品を構造化文書の要素として記述することが可能となり、各行事部品の定義が必要な要素をマニフェスト時に効率よく確実に抽出、適合させることが可能となる。
（Ｂ）ログ利用
行事実行オブジェクトが構造化文書として記述されていることによって参加者の行事体験を容易にネット上にアップロードし、またその他のユーティリティに活用が可能となる。セッション内に存在し、あるいは生成されるオブジェクトには所有者が存在する。それぞれの実行時のログ情報が取得され、参照データとして参加者端末２で撮影されたデータにセッションのコンテキスト情報がタグとして添付される。

ログは、図５に示すように、状態を変える。ログは、行事実施中であっても参照することができ、例えば、シーンが切り替わる場合に、前のシーンのログが後続のシーンから参照することができる。また、行事が終了し、後処理中に、行事やシナリオ、シーン、カットなどの基本的な構造はタグ付けして永久に保存される。この行事の実施時にロギングされた実施ログは、公開前にコピーされた後、削除される。さらに、収集されたログを公開可能な状態に加工した公開ログは、一定期間保存された後、削除されるが、この保存期間は所有者により設定可能である。

添付されログとして出力されたものはそれぞれの所有者がどう処理するか決定できる。

具体的には、ログの利用は参加者が管理を受けた行事プランの管理オブジェクトに対応付けられた参加者の取得データ、主催者の提供する管理オブジェクトのタイトルおよび関連情報、配信を受けたメッセージ情報、主催者の撮影データ等の参照データを管理オブジェクトとの対応関係をキーに参照することによって行われる。管理オブジェクトログは参加者の場面遷移履歴によって参加者の行事参加の履歴と対応付けられている。

この事によって各参加者は場面を共有した他参加者情報、また、履歴の共通性を解析することによって行事の履歴を共有した他参加者情報を抽出できる。また、既にネットワーク上に公開されたイベントの他参加者の公開ログ情報に埋め込まれたタグ情報からも共有場面情報を抽出することも出来る。

以上の過程により抽出された場面共有情報、場面情報と関連付けられた参照データをその場面情報の関連および構造情報によって利用する。場面情報を構造化文書間の変換機能を利用してhtmlデータあるいはsmil等のストリーム配信提供情報に転換したり、場面共有情報を利用し、上記のオブジェクト上、あるいは電子名刺等でのイベントログデータの相互参照、リンクを行うと言うものである。

以上の処理は、図６及び図７ａ，７ｂ〜図１１に示されているように、ログ取得（Ｓ１００）、関連情報の抽出（Ｓ２００）、及びｈｔｍｌ変換処理（Ｓ３００）又はスライドビュー処理（ストリームデータ化）（Ｓ４００）又は関連リストの作成処理（名刺情報添付）（Ｓ５００）を経て行われ、関連リストの作成処理の前には所定の前工程が行われる。これにより、参加者取得データを参加者が利用しやすい形で自己のブログ等にアップロードすることができ、相互参照も容易に行うことができる。
（Ｃ）行事エントリィの整理
行事への参加者の導入についてはマニュフェスト時の登録と行事実行中のエントリィの二つの方法によって可能である。行事をｗｅｂサイトの周辺サービスとして利用する場合は、サイトにて参加者情報の受付をしてマニュフェスト条件に合致する参加者の登録を行う。参加者はマニュフェスト時点で確定され、セッション実行時にメンバとして管理される。

実行中のセッションは参加者のエントリィを制御するフレームを実行中のセッションにインデックスとして添付し、エントリィ処理を行えば行事に参加することができる。セッション中途からの参加はローカルエントリィからの参加とする。
（Ｄ）セッション実行時エンジン
セッション実行時エンジンについての説明を行う。この記述は、レイヤ構造においてイベント管理アプリケーション支援レイヤからそれ以下の階層にまたがるセッション実行エンジンと関連機能部分が該当する。

図１２には制御構造の全体が示されている。セッションはカット、シーン、シーンシーケンスの多層構造で示されており、シーン間の遷移関係はシーンシーケンスに遷移情報として保持される。参加者、リソース、主催者側メンバ管理はシーンのメンバとして遷移先のシーンの制御を受ける。

行事プラン部品はシーンやシーケンス等の記述をデータベースに登録したもので、それらは構造化文書として構成されているので、文書をマージし、シーン遷移記述、リソース利用条件を集約記述することによって行事プランの一部として利用する事が可能となる。図１２において多層構造をなしてシーケンスおよびシーンの実行が行われるのはこの機能を実現するためである。

なお、セッション制御に記述されているように読み込みはシーンシーケンス単位で行われる。メンバには制御過程に応じて適宜メンバシーンが生成され、制御を受ける。カットはメッセージの配信、レスポンス受付、行動評価の基本ブロックの繰り返しによって記述される。図１２には示されていないが、さらに高度な処理を行う場合はサービス機能と連携して処理が行われる。

また、セッションメンバは複数のシーン（あるいはセッション）に同時にメンバとして制御されることが可能である。この場合、端末の制御画面のシーン管理窓のアクティブ／パッシブ制御および、画面構造をどうするかとメンバステイタスや属性をどのシーンが制御可能なのか決定しなければならない。
（Ｅ）メンバシーン制御
図１３にはメンバシーンの制御が示されている。メンバシーンはメンバそれぞれに対応してカットの実行時に対応して生成処理されるメンバのインターフェイス制御スレッドである。基本ブロックの配信、レスポンスをインタプリタ記述にしたがって処理し、シーンのステイタスに行動評価を通じて影響を及ぼす。

図１３にはそれぞれの制御機構としてキューが配置されている。メンバ属性はシーンあるいはシーンシーケンス（セッション（グローバル））の各層、インポート（グローバル）レベルの寿命制御のものが存在する。インポート属性の所有権は参加者にあるが、シーンシーケンス以下の属性は主催者側にある。但し、主催者側が指定すれば参加者ログに状態を記述されるメンバ属性とすることもできる。
（Ｆ）メンバレスポンス制御
図１４にはメッセージの配信、レスポンス受付、評価についての機構が示されている。リソースにはメンバとしてメンバシーン（制御スレッド）を持つメンバリソースと持たないリソースの双方がある。メンバとなる可能性があるのは、ディスプレイやＤＭＸなどカットを呼び出して継続的に制御を受ける可能性のあるリソースである。メンバインターフェイス制御は、端末を利用して参加者、主催側スタッフの管理を行う場合に適用される。

参加者インターフェイス制御は端末の種別に係わらず同一であるが、メッセージ内容が生成時にコントロールされる。参加者端末としてはＰＣ、携帯端末の双方が該当する。現在位置等端末のコンテキスト情報はメンバのメンバ位置、メンバクラスに受けられる。メンバレスポンスはメンバ端末からのみでなく、他端末のＬＩ（Local Interface）情報、リソースのＬＩ情報、入力情報よりメンバ識別制御を通じて取得される。なお、本実施の形態では、ブロックの三要素がすべて揃った形でなされているが、配信のみ、レスポンスのみの場合も可能である。
（Ｇ）メッセージ構成
図１５にはメッセージとして扱われるデータが示されている。想定する配信メッセージの主たる形式はＨＴＭＬ形式であるが、ＳＭＩＬ等のストリーム配信形式や端末インターフェイスに依存した形式も取り扱うことができる。レスポンスは配信内容に対応する端末への入力とＬＩを利用した他端末との交信の二種類を考慮し、それに端末アプリケーションが自動取得するコンテキスト情報と端末の制御情報が加わる。

その他の端末には他の参加者、スタッフ携帯端末とのＬＩ交信と会場の設置端末やゲート等の位置確認システムが想定される。本システムにおいては携帯端末間のコンタクトを参加者同士の人的接触のシステム的証明として扱う。メッセージとして扱われる情報にはメッセージ付加情報が加えられ識別される。レスポンスメッセージには取得した他メンバの識別情報が付加される。この情報はレスポンス制御時に他メンバのレスポンスとして扱われる。
（Ｈ）サービス機能との連携
図１６にはサービス機能との連携が示されている。サービスコンポーネントはシーンとして機能する場合とカットとして機能する場合がある。基本のメッセージングブロックと組み合わせて利用する場合はカットとしてのインターフェイスを実装する必要がある。サービスコンポーネントは通常のインターフェイスを利用する場合と端末アプリケーションを独自に起動して利用する場合がある。その場合の画面制御は機器依存となる。

なお、図１６にはサービスコンポーネントと通常シーン間の情報のやりとりは示されていないが、属性情報を保持するのみの機能を持つ（サーバ内の仮想の）リソースをメンバとしてインポートするか、参加者の（セッショングローバルな）属性に保持することによって行うことも可能である。
（Ｉ）実行時のロギング
図１７には実行時のロギングが示されている。ログはセッションの状態情報の遷移を記録すると共に参照データとして参加者端末、スタッフ端末、リソースの撮影機材等で記録されたデータに状態情報をタグ付けする。セッション内の所有権に従ってログの利用可能者が決定される。
(Ｊ)例外制御
図１８にはシーンの例外監視制御が示されている。シーンの例外発生は例外監視制御によって監視される。例外発生後の処理は処理シーンを呼び出して行われる。システムとしての標準の対処シーンをオーバーライドする形で処理記述を行う。

次に、図１９〜図２３を参照しつつ、本発明の実施の形態に係るイベント管理システムの全体フローについて説明する。

図１９に示されているように、マーケットへのコンテンツの登録がなされると、それらのコンテンツは再利用可能なプランの作成に利用される。再利用可能なプランはリソースのカテゴリ記述、参加者条件等のマニュフェスト条件とシナリオによって構成される。次に、マニュフェスト条件に実際の利用可能なリソースやコンテキスト情報を適用して実行可能なプランを作成する。

そして、行事の実施が行われると、図２０に示すように、リソースや参加者のチェック等の前処理を行う。プランの修正が完了すると、図２１に示されているように、本処理が行われる。セッションの実行が終了すると、図２２に示されているように、同期処理の必要な属性データの行事実行反映値をエクスポートし、行事ログを生成してログ利用を行う。その後、マニュフェストの抽象化を行い、プランをマーケットに登録する。

さらに、図２３に示す論理モデルにより著作権チェック処理が行われる。本システムの特徴は、マーケットに登録する行事プランを参加者端末やその他の操作対象（リソース）をメンバとして有する場面管理オブジェクト（シーケンス、シーン、カット）の集合と内部に配置されるＡＰＩ群として登録することにある。また、場面管理オブジェクト間に階層関係と遷移関係が存在することにより、構造化文書として全体を扱うことができ、ＸＭＬ等の操作アプリケーションを簡単な変換によって利用することができる。

著作権チェックにより行事プランの原本が確認された場合、課金処理、あるいは利用許諾要請の配信等の著作権処理が行われる。

さらに、本システムの特徴は、マーケットのコンテンツを可視、非可視に分割し、マーケット登録者はいずれも選択することができることである。非可視のコンテンツは著作権が厳密に保護されるが、利便性が比較的低くなり、可視のコンテンツは一定レベルで保護され、改変性が高いため、利便性が高い。そして、行事プランのロード時にマーケットよりアクセス履歴を参照し、アクセシビリティをマーケット上で追跡することができ、可視情報については構造を比較し、可視情報について課金処理が行われる。

実施例においては、可視情報は登録者が公開した構造化プラン情報およびメッセージ内容、ＡＰＩ呼び出し情報からなり、非可視情報は登録者が非公開とした構造化プラン情報およびメッセージ内容、ＡＰＩ呼び出し情報および、バイナリデータ、その他のプログラム情報となる。

具体的には、図２３に示すように、マーケット管理サーバ６に接続された構造データ処理サーバ１０が、ＸＭＬパス等の構造化文書処理コンポーネントと同等の機能を備え、構造化文書の木構造、遷移構造、ＡＰＩ種別、マーケット登録名称を語彙として異同、類似性の判定を行う。そして、類似性が一定以上の場合には、同一パスのノードを比較精査し、メッセージの文章、同一ＡＰＩの引数を比較し、最終的な異同、類似性の判定を行う。

このようにプラン（プログラム）の内部表現の内、変数名やタイトル等の容易に変更可能な内部表現を除き、参加者のイベント実行時の管理オブジェクト変遷、メッセージ、あるいはプログラム外の接続対象に対する表現部分の異同、類似を判定する事が可能となる。

また、この判定時に登録情報に付記された実行地域制御情報に基づき実行プランの実行地域を制御する事が出来る。これによって登録時のプラン実行者に配慮した形でマーケットへの登録を行う事が出来る。

次に、メンバシーンの制御用のＡＰＩの呼び出し記述の効率化のために場面管理ノード（シーン、シーケンス等の行事プラン部品）に処理種別情報を追加し、ノード間の遷移記述にリソースおよび参加者のメンバシーンの対象範囲情報を付与する仕様上の特徴について説明する。

図２６は本発明の実施の形態に係るイベント管理システムのシーン内処理種別差異を示す図である。

場面管理ノード記述には各参加者端末への配信やＡＰＩ適用処理を行う処理記述が含まれる。また行事に利用される機器類等のリソース制御、またリソースから各参加者へのサービス呼び出し記述も含まれる。このメンバシーン管理対象を特定する記述は行事管理システムが持つ特徴によって困難が生じる。つまり行事管理システムは多数の参加者とサービス提供側のリソースを管理対象とするが、特にリソースの処理記述がどの参加者を対象とするか特定する場合、それぞれの参加者に一度ずつ行うのか、ある集団に対して一度行うのか、あるいは行事の中で一度であり、その時点で条件に合致した参加者に対して行うのか特定しなくてはならない。これらの処理ステップ記述はそのほかの参加者に対する配信等の記述とイベント管理に必要な順序関係を保って記述せねばならないため、その都度対象を特定する記述を含めると記述量が増加し、また通常参加者への処理適用を中心に考慮し記述されるため関連及びステップの実行タイミングを特別に設定する記述が必要となることが多くなる。例えばあるグループを店舗まで誘導する行事プランを構築する場合、処理記述はグループのメンバ参加者に順次サービスを配信する順番で記述し、最後に店舗のＡＶ端末で感謝映像を配信する記述をする場合、参加者一人一人が店舗に到達した時点で各々に行うのか、あるタイミング、例えば最後の一人が到達した時に行うのか決めねばならない。この場合、一人ひとりに処理を行うなら単純に順番に記述し、条件設定を満たした順番にＡＶ機器を利用すればよいが、グループ全体に対して処理を行う場合は一人一人へのリソース処理と全体処理が混在するので記述が複雑になる。特に一人一人の処理を、レスポンスを受けながら処理してゆくとタイミングがずれて行くのでそれを整合するための記述が必要となり、他のイベント参加者の情報を取得判定する記述が必要となる。記述の仕様を全てこの基準で設定すると個々の処理で済むサービスの記述量が不必要に増加する可能性が高い。さらにコンサートのセットリストの進行に従って参加者端末に曲情報を配信するなどリソースの処理が中心となる行事の場合、特に参加者の行事参加タイミングがコンサートの途中でも可能となるなら、記述者にとってはリソースの処理進行に従って記述を行うのが自然であるが、一人一人への配信を参加者の参加から順に記述する仕様では独自のタイミングで動くリソースの処理記述を記述することが難しくなる。しかしリソース処理のタイミングで処理される場面管理ノードが存在すれば、これらの記述は非常に容易となる。

これらの場面管理ノード間を遷移情報に従って参加者はノード間を遷移し、それぞれのノードで記述されたサービス配信を受けるが、上記したような複数のタイプの場面管理ノードが存在する場合、遷移ステイタス情報を個々のメンバシーンに対して発行する仕様であるなら処理に矛盾が生じる場合が多くなる。特にグループ処理やリソース処理ノードからグループ処理、あるいはリソース処理ノードへ遷移する場合で、遷移先の処理開始が遷移ステイタス情報である場合、何も規定が無ければ遷移した参加者の数だけグループ処理ノード処理、リソース処理ノード処理が発生してしまうことになる。またノード内のタイミング（トリガ）情報に遷移ステイタスを利用する場合も同様の困難が発生する。これを防ぐために遷移ステイタス情報にメンバシーンを生成する可能性のある対象、つまりどの参加者、時にリソースを対象とするかの集合的な範囲情報を付与する。こうすれば同時発生する遷移ステイタスの処理を例えば相手ノードに同じノードよりの遷移情報は条件により集合的に処理するなどの機能を付与するかして対応する場合と比べて遷移処理機構管理に複雑な処理規定の記述を持ち込まずにすみ、また元のノード処理で規定されるはずの遷移ステイタスの性質を遷移処理機構や相手ノードが解釈するという矛盾を避けることができる。

そうした要求を考慮し場面管理ノード処理機能に三つ以上の種別を設け、場面間の遷移情報に遷移元の処理規定に応じた範囲情報を付与する機能をシステムは備える。これにより複数の処理種別を持つ場面管理ノード間の遷移処理を合理的に制御する。三つの管理ノードの処理種別の一つは参加者個々と関連するリソースを処理対象とし、集合的な処理規定が存在せず、処理記述はドキュメントオーダに従い、参加者のノード遷移時点から順に処理される。発生する遷移情報は最低でも個々の参加者を対象とする。二つ目は参加者のグループと関連するリソースを処理対象とし、集合的な処理規定が存在し、ノード内の各参加者の行動評価を集計し、そのタイミング情報に従ってリソース処理を行う機能を備える。その処理記述は参加者グループの誰かのノード遷移時点から順に処理される。シーンのメンバとなる参加者管理オブジェクトの属性によるユーザグループ設定が存在するなら、処理は記述された条件に依るがユーザグループ設定に合致する属性グループ全員のエントリィが行われたか参照しながら行動評価が行われる。発生する遷移情報はグループ固有でありシーン内の各参加者を範囲とするか、個々の参加者を対象とする。三つ目はリソースと各処理発生時点の場面ノードの参加者を処理対象とし、集合的な処理規定が存在し、ノード内の各参加者の行動評価を集計し、そのタイミング情報に従ってリソース処理もしくは配信処理を行う機構を備える。また特定の開始ステイタス情報を持つ。開始（エントリィ）ステイタスに対応した遷移ステイタスを受け取ると処理記述はドキュメントオーダに従って処理される。開始ステイタスあるいはその他の遷移ステイタスによってノードにエントリィした参加者はその時点で未処理の配信、処理を受ける。発生する遷移情報はその現在参加者を範囲とするか、あるいはノード内の参加者グループ固有であり各参加者を範囲とするか、または個々の参加者を対象とする。

以上の仕様を実現するため図１７のシーンシーケンス処理クラスの遷移処理機能部にシーンオブジェクトからの遷移ステイタスを、範囲情報を含んだ形で受け取るシーンステイタスキューテーブル（図２７参照）を保持し、シーケンス記述にあるステイタス毎の遷移先情報を保持する遷移情報保持部を持つ。シーンステイタスキューテーブルには発生順に発生シーン、ステイタス名、参加者範囲情報が登録される。遷移情報保持部にはシーケンス記述を解釈した遷移情報が保持される。遷移情報はステイタス発生元シーン、遷移ステイタス名、遷移先シーン名、シーン種別情報およびユーザグループ対象参加者属性もしくは開始ステイタス情報を持つことがあり、エントリィステイタス名が保持される。遷移先シーンは一つである必要は無い。図２８にＸＭＬ記述での遷移情報例を記載する。遷移処理機能部は遷移先シーン処理部のステイタス情報を取得する事が可能であり、遷移先シーンの処理開始、参加者エントリィ処理を行う機能が存在する。また参加者情報を参照可能でその属性グループ情報を取得可能である。属性グループ情報には属性情報、インスタンスＩＤ、インスタンスメンバ（参加者）情報が含まれる。また参加者情報を検索し、現在所属のシーン情報を取得可能であるが、これらを遷移処理部にテーブルとして保持しても良い。

図２９は本発明の実施の形態に係るイベント管理システムのシーン遷移処理を示すフローチャートである。

遷移元シーンにおいて遷移ステイタス情報が発行されるとその情報は直上のシーンシーケンスのシーンステイタスキューテーブルに登録される。シーケンス遷移処理機能部は直前処理が終了すると直ちにテーブルの登録情報を読み取り、遷移情報保持部の該当遷移元シーンの該当遷移ステイタス名の遷移先シーン情報を参照する。このとき遷移ステイタスに対応するエントリィステイタス情報を相手シーンに返し、シーン記述内のどの処理を適用するか決定する。

１：遷移先シーンが参加者個々処理シーンであった場合、遷移ステイタスの範囲参加者それぞれについてシーンインスタンスを開設し、処理を開始する。

２：遷移先シーンがグループシーンであった場合、そのシーンに属性グループ指定がなされていないならそのステイタスの範囲参加者をグループメンバとしてエントリィする。属性グループ指定があるなら範囲参加者が属性グループインスタンスの最初の遷移者であるか判定を行う。そうであるなら含まれる属性インスタンス毎にシーンインスタンスを開設し、それぞれのメンバを対象シーンにエントリィを行う。既にその属性インスタンスに対してシーンインスタンスが開設されているなら、該当する属性インスタンスメンバを開設されているシーンにエントリィさせる。このとき未処理のシーン内の処理から適用される。

３：遷移先シーンがステイタスシーンであった場合、それが開始ステイタスであるか判定する。開始ステイタスであるなら新たにシーンインスタンスを開設し、その範囲参加者をエントリィさせる。もし、開始ステイタスでないなら最後に開設されたシーンインスタンスにその範囲参加者をエントリィさせる。この開始ステイタスで無いステイタス時にどのシーンインスタンスにエントリィさせるかは最後では無く、例えば参加者定数設定がシーンになされているなら余剰人員スペースの最も多いシーンにエントリィさせるなどの機能を付け加えても良い。またまだ一つもシーンインスタンスが開設されていない時点で通常の遷移がなされた場合は例外情報を遷移元シーンに返し、遷移は行われない。

なお、参加者へ参加行事のその場面のコンテキストに対応したサービスを提供するために場面管理ノード記述に以下の仕様を組み込みその実現機能を組み込むことができる。

要求リソース：行事のその場面で必要な機器類や物品等のリソースを確実に準備するため、その場面処理開始に必要なリソース種類と数量、および指定場所、時間に存在あるいは稼働しているか、所有権や開封等の重要な状態遷移情報を要求リソース情報として記述できる。記述した要求リソースの状況情報を接続、あるいはローカルインターフェイスやセンサ等の入力情報によって確認できない限り場面の呼び出しが不可能となる。この各場面の記述情報を適合時にシナリオ全体で統合して利用できるように関連出願、特願2007-285407の方法を利用できる。

インターフェイス切り替え制御：参加者が場面に適合した配信等のサービスを一貫した弁別しやすい形で提供を受けられるように場面のインターフェイスを統合して提供できるようにする。場面ノード記述に関してローカルインターフェイスやセンサによる他端末やコンテキスト情報取得時の処理定義情報、端末画面上に表示される機能キーの処理定義情報、ノード内での配信順制御情報として下記のノード種別情報やさらに条件処理、割り込み、スレッド化されたサブノードなどの配信ステップの順序変更情報を場面のインターフェイス制御情報として組み込める。これらは場面に関連したサービスを作成者が容易に編集し、参加者に秩序ある理解しやすい形で提供するためのものである。

インターフェイスを利用者が理解しやすいように統合する方法はＰＣのウィンドウ処理と同等であるが、本システムでは場面管理に利用するためにローカルインターフェイスの情報取得時処理モード識別、ノード内の個々の配信処理群の処理を実施するかについても定義可能なように拡大する。このように場面のインターフェイスを統合した場合、参加者が複数の場面サービスを受ける時に入力の一意性を担保したり、配信制御するためアクティブな場面インターフェイスを切り替えて利用する必要がある。このため参加者のステイタスにシーン等（対応図１７参照）の場面管理ノードの行事実行時のインスタンスごとにアクティブであるかそうでないかの情報を付加する。制御実行時には図１８においてメンバインターフェイス制御に端末より送信された端末取得情報はメンバシーンに送られる時点でアクティブシーン性に従って入力が弁別され異なる制御が実行される。

ローカルインターフェイスによる他端末や場所等のコンテキスト情報を取得した場合、対象のＩＤや位置情報等の取得データは参加者が所属する場面ノード毎の定義情報に従って参加者のアクティブ性に従って各ノード内の処理が行われる。例えば参加者が二つの場面ＡＢに属し、たとえば特定の属性を持つ他参加者とのローカルインターフェイス接触時に場面Ａでは同一グループへのメンバ化処理を行うよう定義され、場面Ｂでは認めないと定義されていた場合、参加者が現在アクティブな場面管理ノードの定義に従って例えば現在Ａにアクティブであった場合、相手参加者は同一グループに属することになる。

配信制御についてはアクティブノードにおいては後述する種別情報等に基づいて個々の配信が実行されるが、その他の所属シーンにおいては配信実施は無視される。この場面間の切り替えは参加者の入力、他シーンでの配信予定時に場面切り替えを促す警告情報を表示させるか、特願2007-285407に記述されているようなコンテキスト情報取得に基づいて自動的に切り替えを行う形としても良い。

以上の仕様を解釈可能な解析機を行事実行サーバに配置することにより場面管理ノードを参加者、作成者が参加行事にて体感する場面区分と合致するように構成する事が可能となり、行事プラン作成の容易化、関連サービスの効果を高めることができる。

このように上記した本発明の実施の形態に係るイベント管理システムによれば、以下の効果を得ることができる。
（１）行事の管理を市場に蓄積された雛形に応じて行うことにより効果的な行事の実施をどのようレベルの主催者でも行うことができるようになる。
（２）行事に関する市場を登録者の技術レベル・適性に合わせた形で構成することによって、効率的にプラン資産の蓄積を行う事が出来る。
（３）行事の管理をシステム制御することによって実施の記録を効率的にネット上で利用できるようになる。またネット上のデータを参照する形での行事の実施が可能になる。
（４）遠隔地での同時共催、時間的に間歇的な行事などを容易に開催できるようになるため多様な形の行事や行事が開催できるようになる。
（５）サイトへの連結に限られていたローカルエントリィからの近接店舗へ、あるいは店頭の誘導広告に多様な機能を組み込めるようになる。
（６）ｗｅｂサイトと顧客データベースを利用した従来型のイベント管理に対して行事の進行構造を明示的に参照できるので主催者が効果的な行事を選択可能となる。
（７）タイミングの制御、参加者間のコンタクトなど高度な管理を実現する場合の制御機構が標準で整備されるため、イベント管理を容易且つ確実に行うことができる。

本発明の実施の形態に係るイベント管理システムの構成を示すブロック図である。本発明の実施の形態に係るイベント管理システムの行事プランの状態遷移を示すブロック図である。本発明の実施の形態に係るイベント管理システムの行事プランの作成フローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムのＡＰＩ登録フローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムの行事ログの状態遷移を示すフローチャートである。本発明の実施の形態に係るイベント管理システムのログ利用のフローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムのログ取得のフローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムのログ取得のフローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムの関連情報の抽出フローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムの関連情報の抽出フローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムの関連情報の抽出フローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムのｈｔｍｌ変換のフローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムのｈｔｍｌ変換のフローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムのｈｔｍｌ変換のフローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムのスライドビュー作成のフローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムのスライドビュー作成のフローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムの関連リスト作成のフローを示すフローチャートである。本発明の実施の形態に係るイベント管理システムのシーン及びカットの遷移制御を示すブロック図である。本発明の実施の形態に係るイベント管理システムのメンバシーンの制御を示すブロック図である。本発明の実施の形態に係るイベント管理システムのメンバレスポンスの制御を示すブロック図である。本発明の実施の形態に係るイベント管理システムのメッセージの構成を示すブロック図である。本発明の実施の形態に係るイベント管理システムのサービス機能との連携を示すブロック図である。本発明の実施の形態に係るイベント管理システムの実行時のロギングを示すブロック図である。本発明の実施の形態に係るイベント管理システムのシーン例外監視制御を示すブロック図である。本発明の実施の形態に係るイベント管理システムの全体の流れを示すフローチャートである。本発明の実施の形態に係るイベント管理システムの前処理を示すフローチャートである。本発明の実施の形態に係るイベント管理システムの行事実施処理を示すフローチャートである。本発明の実施の形態に係るイベント管理システムのログ公開処理を示すフローチャートである。本発明の実施の形態に係るイベント管理システムの課金チェックの論理モデルを示すブロック図である。本発明の実施の形態に係るイベント管理システムのシーン遷移定義をインデント利用テキスト形式で示す図である。本発明の実施の形態に係るイベント管理システムのシーン遷移定義をＸＭＬ形式で示す図である。本発明の実施の形態に係るイベント管理システムのシーン内処理種別差異を示す図である。本発明の実施の形態に係るイベント管理システムのシーンステイタスキューテーブルを示す図である。本発明の実施の形態に係るイベント管理システムのＸＭＬ記述での遷移情報例を示す図である。本発明の実施の形態に係るイベント管理システムのシーン遷移処理を示すフローチャートである。本発明の実施の形態に係るイベント管理システムの統合モデルを示す図である。本発明の実施の形態に係るイベント管理システムのマニュフェスト時の動作を示すフローチャートである。本発明の実施の形態に係るイベント管理システムのカテゴリの定義を示すブロック図である。本発明の実施の形態に係るイベント管理システムの行事プラン部品のリソース条件の統合に関する仕様上の特徴を示すブロック図である。

符号の説明

１イベント管理システム
２参加者端末
４行事実施サーバ
５プラン作成管理サーバ
７ログ公開サーバ

Claims

イベントに関する管理を行うためのイベント管理システムであって、
行事プランあるいは行事プラン部品を構造化文書により構築し、それらを組み合わせ実行可能な行事プランとして作成する行事プラン作成管理手段と、
イベントの参加者が使用する参加者端末との間でメッセージの配信やレスポンスの受理を行い、行事の進行の制御を行う行事実施手段と、
を備えていることを特徴とするイベント管理システム。
前記行事実施手段が行事の進行を制御している間に参加者のログ情報を取得し、参加者がイベント実行時に管理を受けた共通する行事プラン部品の文書あるいはノード識別情報に基づいて主催者提供情報との参照あるいはログ情報の参加者相互参照を可能とするログ公開手段をさらに備えている請求項１に記載のイベント管理システム。
前記行事プラン及び行事プラン部品を公開参照可能なデータベースに登録し、行事プラン作成者が参照した行事プランと、前記行事プラン作成手段が作成した行事プランとの間の構造化文書の異同を判別し、両者の間に類似性があると判定した場合には、前記参加者に対して著作権処理する請求項１又は２に記載のイベント管理システム。
イベントに関する管理を行うためのイベント管理方法であって、
行事プランあるいは行事プラン部品を構造化文書により構築し、それらを組み合わせ実行可能な行事プランとして作成する行事プラン作成管理ステップと、
イベントの参加者が使用する参加者端末との間でメッセージの配信やレスポンスの受理を行い、行事の進行の制御を行う行事実施ステップと、
を備えていることを特徴とするイベント管理方法。
行事の進行を制御している間に参加者のログ情報を取得し、参加者がイベント実行時に管理を受けた共通する行事プラン部品の文書あるいはノード識別情報に基づいて主催者提供情報との参照あるいはログ情報の参加者相互参照を可能とするログ公開ステップをさらに備えている請求項４に記載のイベント管理方法。
前記行事プラン及び行事プラン部品を公開参照可能なデータベースに登録し、行事プラン作成者が参照した行事プランと、前記行事プラン作成手段が作成した行事プランとの間の構造化文書の異同を判別し、両者の間に類似性があると判定した場合には、前記参加者に対して著作権処理する著作権処理ステップをさらに備えている請求項４又は５に記載のイベント管理方法。
請求項４〜６のいずれか１の請求項に記載のステップをコンピュータに実行させるためのイベント管理プログラム。