JP6774117B2 - 一般ユーザ相互作用管理部を備えるイベント管理システム - Google Patents

Description

本発明は、コンピュータネットワークを利用してイベントの運営及び管理を行うイベント管理システムに関する。とりわけ、イベントに参加する複数参加者間の相互作用を管理する一般ユーザ相互作用管理部を備えるものに関する。

団体旅行、グループ旅行、出版記念パーティ、賀詞交換会、名刺交換会、誕生パーティ、オフ会、クイズ大会、音楽コンサート、ライブコンサート、スタンプラリー、オリエンテーリング、結婚披露宴などのイベントを開催する際に、参加者は、自己の趣味や趣向といった個人情報と統計的に相関度が高い個人情報を検索したいという欲求がある。また、多くの場合、その検索作業は、携帯電話やスマートフォンなどの画面が比較的小さい携帯端末機器を用いてなされるので、表示画面が小さくても効率のよい検索が出来るように工夫がなされる。特許文献１には、そのような検索を可能にする情報提供システムが開示されている。

また、イベントの開催者と参加者とがいずれも会員として登録され、イベントが円滑に開催されて、開催者と参加者とを適切に管理し得るイベント管理システム及び方法が望まれる。特許文献２には、そのような課題にこたえるべく、会員端末とイベント管理サーバとから構成され、イベントの進行をイベント管理サーバ側で管理するイベント管理システムであって、イベント管理サーバが会員情報記憶手段と、イベント開催・参加条件情報受信手段と、参加可能会員抽出手段と、イベント開催通知手段と、参加申し込み受信手段と、参加ポイント付与手段と、アンケート実施手段と、アンケートポイント付与手段とを有し、会員端末は、イベント開催情報受信手段と、イベント参加申込送信手段と、アンケート応答手段とを有するものである。

さらにまた、イベント管理サーバで稼動するイベント管理プログラムは、他のイベントに流用可能とすることが困難であるため、イベント開催の費用対効果が思うように得られない。ユーザ端末の付加機能であるバーコードリーダー、動画撮像機能、赤外線送受信機能などを利用可能とするためのシステム設計が煩雑で手間がかかる。特許文献３には、そのような課題にこたえるべく、イベントの管理及び運用におけるサーバの基本的な機能をＡＰＩ（アプリケーションプログラムインタフェース）として構築することを提案している。通信機能ＡＰＩ、参加者情報管理ＡＰＩ、場面ノード管理ＡＰＩ（イベントの各シーン生成用ＡＰＩ、シーン実行用ＡＰＩなど）、物品売買用のマーケットＡＰＩ、広告配信用ＡＰＩ、参加者端末付属機器対応インターフェースなどである。
さらに、特許文献３には、イベントを通じて得られる参加者の属性情報を利用して参加者のモチベーションを高めるべく、参加者の属性情報や行動情報をライフログとして蓄積し、これを利用して参加者同士のコミュニケーションを促進する機能が設けられている。

特許文献４には、行事プランあるいは行事プラン部品を構造化文書により構築し、それらを組み合わせ実行可能な行事プランとして作成する行事プラン作成管理手段と、参加者端末との間でメッセージの配信やレスポンスの受理を行い、行事の進行の制御を行う行事実施手段とを備えているイベント管理システムが開示されている。

特許５１５８３０２号公報 特許５０７２００３号公報 特許５１８２８５４号公報 特開２００９−１７６２６９号公報

しかし、イベントを生成する立場、イベントに参加する立場からは、より簡易なユーザインタフェースが願われていた。
一方で、システムとしては、ＨＴＭＬなどの構造化文書に準じた構造化が求められる。

本発明は、このような実情に鑑みてなされたものであり、ユーザにとっては、イベント生成、イベント参加がしやすく、しかも、解析構造体としても優れたプログラムを実現可能なイベント管理システムを提供しようとするものである。

上記解決しようとする課題に鑑みて鋭意研究の結果、本発明者は、プログラムのモジュールをネストしたシナリオであるとして扱うことにより、課題解決が可能であることに想到した。
すなわち、本発明は、シナリオ、記述子などを用いて、高度なプログラミングを実現し、なおかつ解釈処理により構造体としても優れたイベント管理システムを提供するものである。

本発明のイベント管理システムは、
イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、及び
前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩを格納するＡＰＩデータベースと、
イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
イベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
前記生成されたイベント実行プログラムのうち、当システムにおける実行可能性の所定基準及び管理者が任意で設定するイベントの妥当性基準に適合するイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
ネットワークを通じてイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部と、
前記イベントに参加する複数参加者間の相互作用を管理する全体処理用のグラフィカルな作成アイコンを利用してメンバスコープの遷移系列での都度評価を通じてその時点のサービス対象者を確定可能である一般ユーザ相互作用管理部と
を備えたイベント管理システムであって、
前記イベント実行プログラムのモジュールによって重層化されたオブジェクトの動作を各モジュールに付属するシナリオに前記イベント生成者が記述するものであり、
前記シナリオを記述するための記述子を用いるものであり、
前記イベント管理システムは、さらに、
完成したシナリオにおいて、コンテンツおよび前記記述子の他の記述子への部位配置情報、及び前記記述子又は前記記述子部位の結合関係を解釈するシナリオ構造解釈部を備えることを特徴とする。

一般ユーザ相互作用管理部を設けることにより、イベントの参加者へのサービス提供の範囲を直感的に絞り込むことが可能である。

ここで、シナリオチャートを記述するための記述子には、部位配置情報を含むことができる。部位配置情報により、記述子と他の記述子、記述子と他の記述子部位との結合関係を示すことができる。オブジェクトの配置に関してはチャート画面をオブジェクトアダプタに分割あるいは追加記述フォーム、小画面を追加しそのアダプタ間の関係、オブジェクトの隣接関係にゾーンの包含関係、接続関係情報を持たせ、オブジェクトのアダプタへの配置によって上記機能を実現する事も出来る。

具体的には、実施例として次のようなものが考えられる（図５９参照）。
チャートは一つ以上のコラムに最上位タイムゾーンかフィールドゾーンを割り付ける。コラムはオブジェクト割り付けエリアと下位コラム割り付けエリアに分割される。下位コラム割り付けエリアには更に被包含関係を為す同種のゾーンを割り付け分割する事が出来る。オブジェクト割り付けエリアにはオブジェクトアダプタが並びオブジェクトを配置できる。各オブジェクトは割り付けエリアでの位置関係（シーケンスな配置順や隣接関係）、実施順を制御したり遷移情報を記述する記述子オブジェクトやオブジェクト追加マーカーを適切な位置に配置する事によって遷移矢とゾーンによるものと同様のゾーンによって構造化された解釈を行う。またこの画面は見易い様にコラムごとに表示制御を行う事が出来る。この表示制御に関してはサブ画面もしくはウィンドウを開く形にしても良い。

また、前記シナリオ構造解釈部が解釈する内容としては、「コンテンツおよび前記記述子の前記タイムゾーンに対しての包含関係」のほかに、前記タイムゾーンの構造、前記チャートに配置されたフィールドゾーン情報、コンテンツおよび前記記述子の他のアイコンへの部位配置情報、及び結合関係（前記アイコンおよび前記アイコン部位）を含むことができる。

なお、「最上位がタイムゾーンの場合は前記フィールドゾーンを、最上位がフィールドゾーンの場合は前記タイムゾーンを参照情報として追加することができる。」そしてそれは、「構造化要素がタイムゾーンなら被包含要素のフィールドゾーン包含関係情報を双方に付記し、構造化要素がフィールドゾーンなら被包含要素のタイムゾーン包含関係情報を双方に付記し、」と書き換えることができる。

さらに、ユーザチェック部を有し、
イベント参加者が、自分が通過中のノードに対応した二次元バーコードページを生成選択する。これによって、自分の状況を、管理者や他のユーザが対応可能な形で管理者や他ユーザに告知することを可能とする。

ユーザチェック部（2-11,2-12)を設けることにより、イベント管理においてはノード毎のイベント参加者通過情報をイベントモニター（該当項参照）においてリアルタイムにコンテキスト毎に集合的に把握、或いは緊急事態発生を感知できるので管理者トリガ、或いはイベントモニターの緊急対応手段をもってイベントの進行を制御する事が出来る。

また参加者も2-11で自分の通過中のノードに対応した二次元バーコードページを生成選択する事によって自分の状況をユーザチェック2-12によって類型化されたシステムによって対応可能な形で管理者や他ユーザに告知できる。

また、本発明に係るイベント管理システムは、
アイコンを、遷移を表現するグラフィックの適切な位置に配置することによって、
イベント処理時に前記複数参加者間の相互作用のトランザクション処理用のキーを自動生成することを特徴とする。

これにより、シナリオ作成時、シナリオ参加時のユーザインタフェースをわかりやすくしつつも、ＨＴＭＬなどの構造化文書に準じた構造を有するイベント管理システムを提供できる。

前記イベント管理システムは、前記イベントが実行されている際に前記一般ユーザが当該イベントに参加することを処理する一般ユーザ参加処理部をさらに有し、
前記一般ユーザ参加処理部は、
前記一般ユーザが参加者として行動して、管理者ユーザが生成したイベントにトリガ発生をする処理をアイコンを画面上に配置することにより実行することが可能であることを特徴とする。
これにより、一般ユーザがイベントに参加することを一般ユーザが認識、自覚しやすい。

前記イベント管理システムは、前記イベントに参加する前記一般ユーザの行動を確認するユーザ行動確認部をさらに有し、
前記ユーザ行動確認部は、
前記一般ユーザが二次元バーコード、一次元バーコード、ＩＣチップ、ＲＦＩＤ又は赤外線情報などのうちのいずれか一つを端末で読み取って送信することにより、前記一般ユーザの行動を確認可能であり、
前記イベント生成処理部は、当該処理を可能とすべく、前記一般ユーザの行動確認をアイコンを利用してシナリオに組み込み可能とすることを特徴とする。
これにより、土地に定着した二次元バーコード、一次元バーコード、ＩＣチップ、ＲＦＩＤ又は赤外線情報などのうちのいずれか一つとの関係で、ユーザの行動確認をより確かなものとすることができる。

前記イベント生成処理部は、前記一般ユーザの行動管理に必要なメッセージ配信を重要度に応じてユーザに認識させるよう、シナリオ作成し、
前記ユーザ行動確認部は、前記一般ユーザの行動管理に必要なメッセージ配信を重要度に応じてユーザに認識させるよう、シナリオ実行中の前記一般ユーザの行動遷移の管理を行うことを可能としたことを特徴とする。
これにより、イベントに参加する一般ユーザに対して、本人の趣味嗜好、状況に合わせた案内をメッセージ配信により行い、注意喚起することが可能となる。

前記イベント生成処理部は、
参加者の携帯する端末機器の端末アプリを利用した相互の接触確認プロセス（ユーザチェック）を設定することが可能であり、
管理者ユーザが一般ユーザとの間でユーザチェックをすることで、当該一般ユーザが行動をすることの制限を課すことができ、
一般ユーザ同士のユーザチェックにより、グルーピングがなされることを特徴とする。

前記一般ユーザ相互作用管理部は、
前記複数参加者間のグループ行動の制御のために、全体処理属性と呼ぶオブジェクトを利用するものであり、
前記全体処理属性は、メンバの個別の属性値だけでなく代表値、代表プロパティを含む全体処理用の情報を持つことを特徴とする。

3-3-1-3：属性
属性はユーザの行動情報の記録制御および保持情報のシナリオ上での利用、グループ行動の制御の為に利用されるオブジェクトである。変数と似ているが名前空間は持たずスコープの意味は異なっている。また属性は必ずユーザ、もしくはモジュール（あるいはその双方）と括り付けられ属性値を持つ。
また大別して二種類に分かれる。シナリオ属性、参加者属性である。シナリオ属性は更に代表値とメンバ情報を持つかによって通常のシナリオ属性と全体処理属性に分かれる。さらに各種の属性やユーザのプロパティを切り出し使用する為に属性プロパティ属性化アイコンが存在する。
そのチャートで利用できる属性は全て属性パレットと呼ばれるアイコンのコンテナに表示される（新規のブランクのアイコンも）。
そのアイコンをチャート上或いは記事編集画面にドラッグ等によって配置して値の変更、条件、フォームの代入先として利用する。
属性のアイコンはその種類ごとにチャート上に配置できる場所が異なり機能も異なる。
属性は定義時に付番されるＩＤで識別される。
データ構造としては
ＩＤ
名称
種別
型
(属性値リスト)
定義モジュール
メンバ情報
属性値
となり
全体処理属性は更に一階層個々のメンバ情報にユーザメンバー情報と属性値がぶら下がる。
参加者属性は参加者タイプ（図３４参照）別アクティブ情報とインポート属性の種別と連携先情報、コメントが加わる。

3-3-1-3-1：スコープ＃定義/スコープ
このシステムにおける属性のスコープとはどのモジュール（シナリオ）もしくはコンテンツの属性パレットに表示されるかを表す。
参加者属性は3-3-6-1：属性登録で定義されシナリオ中の全ての属性パレットで利用できる。但し参加者タイプ（図３４参照）によってはノンアクティブなタイプの場合、値を持たない場合がある。
シナリオ属性は定義されたモジュールかそれ以下の階層のモジュールかコンテンツのパレットで利用できる。図５及び1-4-1項参照。

3-3-1-3-2：型
通常の属性は属性値タイプとして真偽、数値、文字列、文字列（リスト）、データの型を持ちうる。一方全体処理属性は集団行動を制御する為に特別な型を持つ。
真偽：真値と偽値を持つ。参加ユーザはスコープ内ではデフォルトで偽値を持つとして扱われる。参加者属性ではノンアクティブな参加者タイプ（図３４参照）、全体処理属性ではメンバ外はいかなる値も持たない。
数値：数値情報を持つ。参加ユーザはスコープ内ではデフォルトで０を持つとして扱われる。参加者属性ではノンアクティブな参加者タイプ（図３４参照）、全体処理属性ではメンバ外はいかなる値も持たない。
文字列：文字列情報を持つ。参加ユーザはスコープ内ではデフォルトで空白値を持つとして扱われる。参加者属性ではノンアクティブな参加者タイプ（図３４参照）、全体処理属性ではメンバ外はいかなる値も持たない。
文字列（リスト）：予め予約された文字列の情報を持つ。定義時に指定されなくてはならない。参加ユーザはスコープ内ではデフォルトで空白値を持つとして扱われる。参加者属性ではノンアクティブな参加者タイプ（図３４参照）、全体処理属性ではメンバ外はいかなる値も持たない。
データ：定義時にデータ形式を指定しなくてはならない（アイコンに拡張子の記号が現れる）。画面パーツ、外部モジュールが要求する形式のデータを型として指定できる。参加ユーザはスコープ内ではデフォルトで空白値を持つとして扱われる。参加者属性ではノンアクティブな参加者タイプ（図３４参照）、全体処理属性ではメンバ外はいかなる値も持たない。それ以外の状況では文字列タイプとして扱われる。
指定可能なデータ形式はある形式を利用する画面パーツ、外部モジュールをパレットに型として登録した時点で追加される。（公式の画面パーツ、外部モジュールに必要な形式はデフォで指定可能）＃外部データ利用

3-3-1-3-3：シナリオ属性
シナリオ上でユーザやイベントの進行を制御する為に使用する属性タイプのオブジェクト。シナリオ属性はユーザに属し理論上はスコープ内では一旦定義されたなら全てのユーザがその属性を持つ。
一部の配置場所では遷移制御モードとして遷移制御の為に条件情報として以外は真偽値型とカウンタ型どちらかとして扱われる。＃遷移制御
真偽：真偽値型（偽：偽/真：真）
文字列：真偽値型（偽：空白値/真：”1”）
文字列：真偽値型（偽：空白値/真：リストの一番目の値）
数値：カウンタ型
図２８の配置可能な場所に配置する事が出来、真偽タイプは図２３のモード通りにユーザの属性の状態を変化させ、カウンタータイプは増減させる（反転配置は不可能）。
その他の記述子のループ値、遷移値配置部、カウンタ配置部にカウンタータイプは配置可能となる。
遷移制御モードのシナリオ属性の配置可能な場所
ターミナルステイタス
評価ステイタス
終了レセプタ
コンテント開始時
遷移未開始
トリガレセプタ
タイムイン
タイムアウト
フィールドイン
フィールドアウト
強制終了レセプタ
処理アイコン（評価開始時/カウンタータイプは評価開始時と終了時：アイコン上部と下部）
計算チャートでは通常の型として利用されるが記述子の論理遷移矢の制御に利用されるときは遷移制御モードと同じ挙動をする。（代入遷移矢と結合したら通常の型として機能）＃計算ゾーン
双方のチャート上で
属性パターンフィルタの属性ドロップ部に配置された属性は条件情報としてパターンフィルタの挙動を制御する。

3-3-1-3-4：参加者属性＃保存属性管理
参加者属性はユーザや管理者側が提供する嗜好や価値情報をシナリオ中で利用する為に使われる。ユーザがその属性を持つかはイベント参加時に決まる参加者タイプ（図３４参照）によって決まる。スコープはシナリオとなる。データ型はなくどうしても指定する必要があるときは文字列にURLを保持、（適切なものがあれば）外部モジュールにレセプトしてデータ型のシナリオ属性に転換。
保存属性との連携などイベント外の情報の連携を行う。

3-3-1-3-5：全体処理属性 ＃全体処理＃メンバスコープ
定義モジュールインスタンスに対してユニークなモジュールのメンバスコープか指定域、或いは指定した下位の全体処理TZ或いは全体処理モジュールインスタンスをメンバ情報として持つ属性。グループなど集団行動を管理する為に使用される。
メンバの個別の属性値だけで無く代表値、代表プロパティなどの全体処理用の情報を持つ。
全体処理TZ或いは全体処理モジュールインスタンスを依存先として持つ値は通常型の他にユーザオブジェクトを値として持ちうる。メンバ計算ＴＺかオナータイプのグループプロパティ取得モード（3-3-1-3-6：属性チャート上挙動個別説明b）項）でこの型が付与されたら該当するメンバ情報が代入される。
定義モジュールインスタンスに対する代表値とメンバに対するメンバ属性値を持ちうる。
全体処理モジュールか全体処理記述のあるモジュールでのみ機能する。
また特別に全体処理属性はオーダー型、グループ型を数値型メンバ属性値、リスト文字列型と組み合わせて取りうる。

オーダー型は各メンバにユニークな順序情報を持つ（保障）。スコープの属性制約などでメンバが分割されたならその分割内でのオーダーに再編成される。

オーダー型の順序生成方法
数値型：数値の小さい順。同数値の場合は付与時間が早い方が優先される。
リスト文字列型：属性値がリストの上位順。同文字列の場合は付与時間が早い方が優先される。

グループ型は同値のメンバ属性値を持つユーザをそれをキーとしてグループ化する。トリガコネクタをグループ型で制約し他の全体処理ＴＺかモジュールに生成遷移するとグループ毎にインスタンスが生成される。（そのインスタンスのメンバスコープはグループメンバとなる）
＃グループ管理
インスタンス型はメンバが全体処理エリア、全体処理関連個別処理をメンバとするタイプ。潜在的に配置されたモジュール内の全てのインスタンスがメンバである。準拠するとその記述のインスタンスがメンバに追加される。（個別処理の（複数遷移による多重生成などの）インスタンス制御は厳密に言えば全体処理では無いが複雑な操作となるので全体処理属性（全体処理関連個別処理エリア）での制御の範囲とする）＃インスタンス管理

全体処理属性の型
代表値
真偽
数値
文字列
文字列（リスト）
データ
ユーザオブジェクト
省略（メンバ属性値のみ）
メンバ属性値
真偽
インスタンス型真偽
数値
オーダー型数値
グループ型数値
インスタンス型数値
文字列
インスタンス型文字列
データ
インスタンス型データ
文字列（リスト）
オーダー型文字列（リスト）
グループ型文字列（リスト）
インスタンス型文字列（リスト）
ユーザオブジェクト（自動的にインスタンス型）
省略（代表値のみ）

前記イベント生成処理部は、
グローバルトリガ、ＲＳＳ、ユーザ情報付ＲＳＳ、連携システムからのデータ、ユーザ情報付データ、シナリオステイタスのいずれかにユーザの個別シナリオインスタンスを生成する機能を付与したエントリートリガによりユーザの個別インスタンスを発生させるのみならず、
ユーザが携帯する端末アクション、フィールドインのみを受け取るエントリートリガであるローカルエントリィにより、ローカルエントリィプロセスを開始することができることを特徴とする。
これにより、参加者が地理的に参加しやすいイベントに二次元バーコード等の付された看板、ポスターやデジタルサイネイージを介してあるいはそれらが視界に入った時点での端末操作によって参加することができる。

生成された前記解析構造体に対応し、当該構造を継承する形で前記イベント参加者の参加ログを、前記イベントに対するコンテキストでクラス化された時間と場所で構造化されたログとして生成するログ生成部とログ解析部とをさらに有し、
前記ログ生成部は、参加者のゾーン、モジュール通過情報とサービス利用情報をログとして生成し、
前記ログ解析部は、
全ての参加者の通過情報を集約して特定のノードの重要性の解析、遷移先、遷移元との関連情報を解析し、
又は特定の参加者の行動をノードのコンテンツ情報や管理者のノードに付与するコンテキスト情報から解析して参加者の行動特性、嗜好を抽出することができる。
これにより、ビッグデータの活用又は特定参加者の管理を可能とする。

ログ生成の実施例
１：参加者のゾーン、モジュール通過情報とサービス利用情報をログとして生成する（これは参加者毎のリストでも元構造体の通過参加者情報として保存しても良い）。通過情報は元の構造体との対応関係を伴う。
２：解析時には全ての参加者の通過情報を集約して特定のノードの重要性の解析、遷移先、遷移元との関連情報を解析する。
３：或いはある参加者の行動をノードのコンテンツ情報や管理者のノードに付与するコンテキスト情報から解析して参加者の行動特性、嗜好を抽出しても良い。

さらに、イベントモニタ部及び緊急対応部を有し、
前記イベントモニタ部は、
ノード毎のイベント参加者通過情報をイベントモニタにおいてリアルタイムにコンテキスト毎に集合的に把握、或いは緊急事態発生を感知し、
前記緊急対応部は、
ノードごとの緊急事態に対応するためのイベントの進行の制御をすることができる。
これにより、リアルタイムなノード毎のイベント管理を可能とする。
イベントに対するコンテキストでクラス化された時間と場所で構造化されたログは解析とイベントでの参加者管理が容易でありビッグデータでの活用を効率的に行う事が出来る。
さらに、ユーザチェック部を有し、イベント参加者が、自分が通過中のノードに対応した二次元バーコードページを生成選択する。これによって、自分の状況を、管理者や他のユーザが対応可能な形で管理者や他ユーザに告知することを可能とする。
前記一般ユーザ参加処理部は、ユーザが登録したタグを択一的公式タグによって類型化し、参加者属性として登録させる。これにより参加者の属性のチェックを実行することができる。
前記イベント処理部が計算処理の際に扱う属性やデータは、表計算の表、又はデータベースのコラムを利用した行列計算、クエリー計算を含む。これにより、外部の情報など、広く利用することが可能になる。
前記モジュール、前記タイムゾーン及び前記フィールドゾーンは、内部ロジックによる期待時間要素を有し、前記イベント生成処理部は、期待時間計算処理部をさらに有し、前記期待時間計算処理部が計算した結果に基づいて、シナリオの妥当性を判断することを特徴とする。
さらに、場所イベント管理部を有し、前記場所イベント管理部は、その場所と時間制限情報を規格化することにより、各場所イベントの開始もしくは想定開始時間を算出し、それにより、遅延管理、推奨ルート設定又は未来タイムライン表示のうちの少なくとも一つを可能にすることを特徴とする。
前記場所イベント管理部は、マップ上に配置された特定のカテゴリーのユーティリティポイントリストから特定された指定ポイントへの誘導を行うことを特徴とする。
前記場所イベント管理部は、複数の参加者をグループ化し、グループ行動に必要なユーティリティ機能を提供することを特徴とする。
アイコンを、遷移を表現するグラフィックの適切な位置に配置することによってイベント処理時に相互作用のトランザクション処理用のキーを自動生成することを特徴とする。
アイコンを使用してＨＴＭＬエディタにリンクやデータ受け渡し用のタグを生成することを特徴とする。
グラフィカルにモジュール内外のイベント処理と引数、戻り値を設定することを特徴とする。
参加者の位置情報処理について所在タイル登録処理とイベント処理用タイル指定をおこなうことによって計算量を削減することを特徴とする。
タブのリストとページを結合したランディングページを相互に遷移させて、斜めの遷移バー又は扇状の遷移バーのうちのいずれかを利用することにより、スクロール管理アイコンを用いずに、スクロールを実行することを特徴とする。
解釈構造体の出力及び入力について、マークアップ言語、構造を入れ子で記述出来る言語、ＪＳＯＮ（javascript object notation)又はオブジェクト構造を記述できるデータ記述言語を利用して、記述を包含するゾーンに対応するオブジェクトの記法を設定し、入れ子構造もしくは所属関係を示すリスト情報を付加することを特徴とする。
完成したチャート図において、コンテンツおよび前記記述子の他のアイコンへの部位配置情報、及び前記遷移矢の結合関係（前記アイコンおよび前記アイコン部位）を解釈することを特徴とする。

以上、説明したように、本発明のイベント管理システムは、シナリオ作成時、シナリオ参加時のユーザインタフェースをわかりやすくしつつも、ＨＴＭＬなどの構造化文書に準じた構造を有するイベント管理システムを提供できる。

シナリオ実施の流れを示す図である。 一般ユーザアカウントとディレクターアカウントとについて、対比しつつ説明する図である。 シナリオチャート記述のレベルを説明する図である。 トリガについて説明する図である。 コンテンツ、属性のスコープとインスタンスの関係について、説明する図である。 ユーザ画面の遷移を説明する図である。 ユーザーホーム、参加イベントホーム、コンテンツフル表示、それぞれの例を示す図である。 属性ホルダ、ペルソナ管理の図である。 シナリオ作成の画面である。 シナリオ管理の画面である。 イベントモニタの画面である。 実施可能シナリオの図である。 シナリオの現在状態とスタートオプションの説明図である。 参加者管理と属性管理を説明する図である。 チャートモニタの説明図である。 例外モジュールモニタ（図１６参照）と管理者トリガ管理（図１６参照）の図である。 記事状態遷移の図である。 ユーザサイドから見た記事（図１８参照）の説明図である。 記事を作成することについて説明する図である。 記事作成のアイコンなどを説明する図である。 シナリオチャートの作成の仕方を説明する図である。 チャート上ではシナリオ属性は、原則的に遷移制御モードとなる。 処理アイコンを示す図である。 フィールドゾーンの説明図である。 タイムゾーンを示す図である。 計算サブモジュールを説明する図である。 ネストタイプのモジュールチャート記述画面を説明する図である。 モジュールは基本的にネストしたシナリオであることを説明する図である。 外部モジュールのプロパティ画面を説明する図である。 全体処理について説明する図である。 全体処理についての追加の記述をした図である。 コンテントリスト（図３２参照）を示す図である。 参加者属性管理を示す図である。 参加者タイプを示す図である。 スタンプラリーのタイムゾーンＡ、フィールドゾーンＡについて説明する図である。 スタンプラリーのタイムゾーンＡ，タイムゾーンＢについて説明する図である。 ツアーガイドについて説明する図である。 イベントアフターパーティについて、説明する図である。 レストランへの誘導、クイズ大会について説明する図である。 クライマックス視聴と、クイズ待機のタイムゾーンについて示す図である。 移動準備と移動のタイムゾーンについて示す図である。 ライブクイズモジュールについて示す図である。 クイズ処理について説明する図である。 優勝者決定について説明する図である。 ユーザ画面デザインについて説明する図である。 ユーザ画面デザインについての説明（続き）である。 アプリ独自画面について、説明する図である。 マップタイプチャートを説明する図である。 シナリオ作成を説明する図である。 トリガを整理して説明する図である。 特殊チャートを整理して説明する図である。 ライブラリデータの利用及びグローバルトリガに関する要求を整理して説明する図である。 オブジェクトの設定指定を整理して説明する図である。 設定バー以外の入力の方法を整理して説明する図である。 要素間の整理を説明する図である。 フィールドオブジェクトの種類、構造について説明する図である。 イベント管理システムのハードウェア構成を示す図である。 イベント管理システムを構成するサーバコンピュータの構成を示す図である。 遷移矢を用いずに、シナリオチャートをグラフィカルに記述する実施例を示す図である。 期待時間計算について説明する図である。 対象／比較ゾーン遷移置換作業について説明する図である。 遷移矢展開作業について説明する図である。 遷移制御モードの時系列について説明する図である。 期待時間計算での要素の種別について説明する図である。 遷移系列期待時間計算について説明する図である。 期待時間合成について説明する図である。 焦点比較ゾーン内外遷移チェックについて説明する図である。 実行動期待時間加算について説明する図である。 フィールド編集画面の例である。 フィールド構造模式図である。 制御モジュールプロパティ詳細を示す図である。 場所／時間制約の指定を説明する図である。 相互作用の主体、相互作用の場、相互作用の様相を示す図である。 シナリオ（全体処理）属性を示す図である。 キーの構造、属性準拠時のＭＳとキーを示す図である。 全体処理での遷移を示す図である。 記事新仕様を示す図である。 エミッタとステイタス、フィールドゾーンの範囲指定を示す図である。 ユーザ画面デザイン（ブラウザ、アプリ）を示す図である。 ユーザ画面の領域を説明する図である。

以下、添付図面を参照しながら、本発明の管理システムを実施するための最良の形態を詳細に説明する。までは、本発明の実施の形態を例示する図であり、これらの図において、同一の符号を付した部分は同一物を表わし、基本的な構成及び動作は同様であるものとする。
図５７は、イベント管理システムのハードウェア構成を示す図である。図５７の中央に楕円で示すインターネット網には、サーバ（サーバコンピュータ）１０、イベント作成をする管理者ユーザが管理者ユーザアカウントを取得してサーバ１０にアクセスする管理者ユーザ端末２１，２２，２３，２４、一般ユーザ端末３１，３２，３３，３４を示している。管理者ユーザ端末、一般ユーザ端末は、いわゆるスマホ、またはタブレットコンピュータであり得る。図５７では、端末が直接インターネットとやりとりしているように描いているが、ワイファイ機器を介してインターネットにつながるのでもよい。また、携帯電話ネットワークを介してインターネットにつながるのでもよい。

図５８は、イベント管理システムを構成するサーバコンピュータ１０の構成を示す図である。イベントの構成単位であるシナリオの実行、イベント参加端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信などを実行管理するイベント実行管理ＡＰＩ（アプリケーションプログラムインタフェース）、端末、機器、物品、建物、場所、移動手段、通信手段などの物理的リソースを各々識別して管理するリソース管理ＡＰＩを格納するＡＰＩデータベース装置５１、イベント実行プログラム及びイベント実行中に生じたログデータを格納するイベントデータベース装置５２、ユーザのアカウント情報などを有するユーザデータベース装置５３、ポイントに関する情報を有するポイントデータベース装置５４を有する。
さらに、ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部６１を有する。
また、イベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部６２を有する。
前記生成されたイベント実行プログラムのうち、当システムにおける実行可能性の所定基準及び管理者が任意で設定するイベントの妥当性基準に適合するイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部６３を有する。
ネットワークを通じてイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部６４を有する。
完成したチャート図において、前記タイムゾーンの構造、前記チャートに配置されたフィールドゾーン情報、コンテンツおよび前記記述子の前記タイムゾーンに対しての包含関係、コンテンツおよび前記記述子の他のアイコンへの部位配置情報、及び前記遷移矢の結合関係（前記アイコンおよび前記アイコン部位）を解釈するチャート図解釈部６５を有する。
前記チャート図解釈部が解釈した情報に従って、
前記タイムゾーンの入れ子関係を解析してプレーンのフィールドを最上位タイムゾーンとしてプロパティ情報と共に構造化し、
前記フィールドゾーンを最上位の要素として追加し、
それぞれの前記タイムゾーンに包含されたコンテンツおよび記述子を構造体の該当位置に要素としてプロパティ情報と共にリスト化し、
部位配置された前記アイコンを各要素（プロパティ）の子要素として追加し、
遷移情報をプロパティと指示情報として双方向から追加し、
これらにより解析構造体を生成し、チャート、すなわちモジュールに固有の構造体とし、マークアップ言語によるプログラミングと同等のチャート解釈を実現する解析構造体生成部６６を有する。なお、この解析構造体を生成せずに、モジュール単位のインタープリタ言語としての機能を有するものとしてもよい。
管理者ユーザが一般ユーザに対して付与する利益であるポイントや称号を管理するポイント管理部６７を有する。ここで、ポイントは、たとえば、電子マネーに変換できるなど、金銭的価値をもつものである。称号は、名誉的な肩書きである。
イベントが実行されている際に一般ユーザが当該イベントに参加することを処理する一般ユーザ参加処理部６８を有する。
イベントに参加する一般ユーザの相互作用を管理する一般ユーザ相互作用管理部６９を有する。
イベントに参加する一般ユーザの行動を確認するユーザ行動確認部７０を有する。

以下、本発明の管理システムをサーバコンピュータと、ユーザの端末とをインターネットで接続して構成する場合に、主にサーバコンピュータにインストールするコンピュータプログラムの仕様を中心に説明する。

≪目次≫
１：概念記述
1-1：サービスのユースケース（図３８、図３９、図４０、図４１、図４２、図４３、図４４、図４５、図４６参照）
1-2：シナリオ利用の流れ（管理者/ユーザ）
1-3：アカウント（管理者/ユーザ）
1-4：特徴
1-4-1：シナリオ構造とオブジェクトのスコープ
1-5：システム構成
1-6：重要/共通ロジック/ビジネスロジック
2：ユーザ画面
2-1：画面遷移
2-1-1：ナヴィゲーションバーの挙動
2-2：管理系画面
2-2-1：ログイン画面
2-2-2： 新規登録
2-2-3： アカウント
2-2-4： ペルソナ管理
2-2-5： ユーザホーム
2-2-6：属性ホルダ#保存属性管理
2-3：イベントホーム（イベント利用時の遷移）
2-3-1：基本フォーム
2-3-2：イベント利用時の遷移について（イベント開始画面と招待イベント参加認証プロセス）
2-3-3：招待イベント個別ホーム
2-3-4：参加イベントホーム（未開始）
2-3-5：参加イベントホーム（開始後）
2-3-6：参加終了イベントホーム（終了後）
2-4：コンテンツ
2-4-1：フル表示
2-4-2：特殊記事
2-4-3：外部サービス
2-5：リスト
2-5-1：表示中コンテントリスト（図３２参照）
2-5-2：待機中コンテントリスト（図３２参照）
2-5-3：参加中イベントリスト
2-5-4：招待中イベントリスト
2-5-5：イベントログリスト
2-5-6：参加イベント表示中コンテンツ
2-5-7：参加イベント待機コンテンツ
2-5-8：参加イベントコンテンツログ
2-6：トリガチェッカーとローカルエントリ
2-6-1：トリガチェッカーエントリィ
2-6-2：参加可能ローカルエントリィ
2-6-3：トリガマップ
2-6-4：ローカルエントリィ
2-7：タグについて
2-8：保存属性について
2-8-1:属性と保存属性
2-8-2:公式属性
2-8-3:タグ関連属性
2-8-4:保存推奨属性
2-9：メール配信
2-9-1:コンテント配信
2-9-2：告知配信
2-9-3：警告配信
2-9-4：プッシュ連動
2-10:トリガ(ユーザ側)
2-11：識別二次元バーコード
2-12：ユーザチェック
2-13:終了マージン
3:管理者画面
3-1：画面遷移
3-2：メインパート/管理系画面
3-2-1：ログイン/ログアウト＃ログイン/ログアウト
3-2-2：新規登録
3-2-3：アカウント
3-2-4：ようこそページ
3-3：メインパート/シナリオ作成
3-3-1：概念説明
3-3-1-1-1：チャート操作
3-3-1-1-1-1：パレットアイコンドラッグ
3-3-1-1-1-1-1：チャートフィールドへの配置
3-3-1-1-1-1-2：アイコン上、アイコン部位への配置
3-3-1-1-1-2： ゾーンの配置
3-3-1-1-1-3：アイコンの画面内の移動とアイコンの変形
3-3-1-1-1-4：遷移矢の結合操作
3-3-1-1-1-5：アイコン詳細動作（クリック）
3-3-1-1-1-6：動作制限
3-3-1-1-1-7：部位
3-3-1-1-2：解釈と解析
3-3-1-1-2-1：解釈される情報
3-3-1-1-2-2：解析構造体
3-3-1-2：コンテント
3-3-1-2-1：定義、編集と操作
3-3-1-2-1-1：テンプレートとフィルアップ
3-3-1-2-1-2：コンテントの状態
3-3-1-2-2：記事とメッセージ
3-3-1-2-3：通常モジュールと例外管理
3-3-1-2-4：ネストタイプモジュールと外部モジュール
3-3-1-2-5:例外終了マージン
3-3-1-2-6：コンテントチャート上挙動個別説明
3-3-1-3：属性
3-3-1-3-1：スコープ
3-3-1-3-2：型
3-3-1-3-3：シナリオ属性
3-3-1-3-4：参加者属性
3-3-1-3-5：全体処理（図３０、図３１参照）属性
3-3-1-3-5-1：全体処理（図３０、図３１参照）属性のメンバスコープ
3-3-1-3-6:属性プロパティ属性化アイコン
3-3-1-3-7：属性チャート上挙動個別説明
3-3-1-4：ゾーン
3-3-1-4-1:ゾーンクラス化
3-3-1-4-2：タイムゾーン
3-3-1-4-2-1：タイムゾーンの終了
3-3-1-4-2-2：計算ゾーン
3-3-1-4-3：フィールドゾーン
3-3-1-4-3-1：所属フィールドゾーン
3-3-1-4-3-1：範囲設定
3-3-1-4-4:ゾーンアウトマージン
3-3-1-4-5:ゾーンおよび付随アイコンチャート上挙動個別説明
3-3-1-4-5-1-:タイムゾーン
3-3-1-4-5-2:フィールドゾーン
3-3-1-5：記述子（処理アイコンと遷移矢、トリガアイコン）
3-3-1-5-1：記述子チャート（全体処理以外）上挙動個別説明
3-3-1-6：タイミング設定
3-3-1-7：ターミナルステイタスとステイタスエミッタ
3-3-1-8：パレット
3-3-1-9：全体記述
3-3-1-9-1：全体処理（図３０、図３１参照）記述と全体処理（図３０、図３１参照）エリア
3-3-1-9-2：全体処理（図３０、図３１参照）インスタンス
3-3-1-9-3：メンバスコープ
3-3-1-9-4： 全体処理（図３０、図３１参照）モジュール
3-3-1-9-5：全体処理（図３０、図３１参照）タイムゾーン
3-3-1-9-6： 全体処理（図３０、図３１参照）配置チャート個別処理
3-3-1-9-7：全体処理（図３０、図３１参照）と全体処理（図３０、図３１参照）エリア内個別処理の相互作用
3-3-1-9-8： グループ処理
3-3-1-9-9：メンバ計算タイムゾーンと全体処理（図３０、図３１参照）を含んだ計算
3-3-1-9-10：全体処理（図３０、図３１参照）記述子
3-3-1-10：計算モジュール＃シナリオ/計算チャート＃計算ゾーン
3-3-1-10-1：（個別）計算チャートもしくは計算ゾーン
3-3-1-10-2:全体処理（図３０、図３１参照）を含めた属性計算
3-3-1-10-3：タイミング設定チャートと属性条件チャート
3-3-1-11： コンテンツログ
3-3-1-12:ログの記録
3-3-1-13：参加者タイプ（図３４参照）＃参加者タイプ（図３４参照）決定プロセス
3-3-2：シナリオ（メイン画面）
3-3-3：シナリオチャート
3-3-3-1：画面の基本構造
3-3-3-2：チャートエリア（チャートの説明）
3-3-3-3：パレットエリア（パレットの説明）
3-3-3-4：ユーティリティバー
3-3-3-5：シナリオ属性登録プロセス
3-3-4：モジュール
3-3-4-1：ネストタイプモジュール
3-3-4-2：例外管理
3-3-4-3：外部モジュール
3-3-4-3-1:外部トリガ記述モジュール
3-3-4-3-1-1：エントリィトリガとローカルエントリィ
3-3-4-3-1-2：ユーザチェック関連モジュールと利用プロセス
3-3-4-3-2:ガイドモジュール
3-3-4-3-3:ページアダプタ
3-3-4-3-4:会場危機管理システム
3-3-4-3-5:シナリオステイタスレセプタモジュール
3-3-4-4：テンプレート化
3-3-4-5：ライブラリ利用
3-3-5：記事/メッセージ
3-3-5-1： ユーザ画面
3-3-5-2：記事状態遷移
3-3-5-3：ターミナルステイタス/チェック/選択拘束
3-3-5-4：記事記述画面
3-3-5-4-1：画面パーツ
3-3-5-4-1-1:画面パーツの種類
3-3-5-5：記事メインパート
3-3-5-6：パレットエリア
3-3-5-7：ユーティリティバー
3-3-5-8：メインパート記述
3-3-5-9：テンプレート化
3-3-5-10：特殊記事
3-3-6：参加者属性管理（図３３参照）
3-3-6-1：メイン画面説明
3-3-6-2：属性登録/編集画面
3-3-6-3：参加者タイプ（図３４参照）登録/編集画面
3-3-7：コンテンツリスト
3-3-7-1:コンテンツリスト（メイン）
3-3-7-2:シナリオ属性リスト
3-3-7-3:サブ要素リスト
3-3-7-4:ライブラリ登録
3-3-7-5:シナリオ構造表示画面
3-3-8：二次元バーコード生成
3-3-9：概形チェック
3-4：メインパート/シナリオ管理
3-4-1：概説
3-4-1-1：実施可能シナリオ
3-4-1-2：登録推奨属性
3-4-2：実施可能シナリオ
3-4-3：参加者管理
3-4-4：登録推奨属性管理
3-4-4-1：属性承認管理
3-4-5：ライブラリ
3-4-5-1：プライベートライブラリ
3-4-5-2：標準化ライブラリ
3-4-5-3：ライブラリ画面
3-4-5-4：データアップロード
3-4-6：ユーティリティ
3-4-6-1:告知メール配信
3-4-6-2：二次元バーコード生成
3-5：メインパート/イベントモニタ
3-5-1：概説
3-5-1-1：管理者トリガ
3-5-1-2：管理者コール
3-5-2：チャートモニタ（図１５参照）
3-5-2-1：チャートモニタメイン
3-5-2-2：サブモニタ（属性モニタ、参加者モニタ、ログモニタ）
3-5-2-3：ユーティリティバー
3-5-3：例外モジュールモニタ（図１６参照）
3-5-4：管理者コール
3-5-5：管理者トリガ管理（図１６参照）
3-6：新規登録
3-7：外部連携
X-1：ベータ時のライブラリ仕様の修正
X-2：ユーザ画面の仕様変更
X-3：多言語仕様の準備
Ｙ-1：トリガ機能の整理統合（文書末にまとめて）
Ｙ-2：リスト型、数値型属性の付番機能の明確化（文中で修正）
Ｙ-3：ワイルドカードアイコンの機能の整理（文中で修正）
Ｙ-4：ユーザ画面の仕様再変更（小画面への最適化の再検討）（文中で修正）
Ｙ-5：概形チェックの項目候補洗い出し（#概形チェック/要件定義時に再チェック）
Ｙ-6：アイコンプロパティの項目洗い出し（要件定義時に再チェック）
Ｙ-7：実行可能イベントのオプション仕様のタイミング設定チャートへの統合（文中で修正）
Ｚ-1：参加者画面整理（文書末にまとめて）
Ｚ-2：マップタイプチャート編集画面の追加（文書末にまとめて）
Ｚ-3：参照用サブチャート窓
Ｚ-4：期待時間計算（図６０参照）
Ｚ-5：対象／比較ゾーン遷移置換作業（図６１参照）
Ｚ-6：遷移矢展開作業（図６２参照）
Ｚ-7：遷移制御モードの時系列（図６３参照）
Ｚ-8：期待時間計算での要素の種別（図６４参照）
Ｚ-9：遷移系列期待時間計算（図６５参照）
Ｚ-10：期待時間合成（図６６参照）
Ｚ-11：焦点比較ゾーン内外遷移チェック（図６７参照）
Ｚ-12：実行動期待時間加算（図６８参照）

≪内容≫
１：概念記述
このサービスはイベント主催者(管理者ユーザ)が携帯端末を持った参加者(一般ユーザ)を端末配信の利用により場所やリアルな状況（コンテキスト）に応じた配信サービスを行う簡易アプリ構築の為のヴィジュアルプログラミングシステムである。
その為管理者ユーザはイベントのシナリオを作成又はライブラリからインポート後ローカライズしてイベントを実施する。その為にシステムは以下のサービスを管理者一般ユーザに提供する。
管理者ユーザ
１：イベントシナリオ作成
２：イベントシナリオ実施管理
３：イベント実施
４：イベント内で発生した価値（属性）の管理と公開、提携
５：シナリオ及びシナリオ素材のストレージ及びライブラリ提供
６：上記ライブラリでの素材の流通
７：自己サービスや施設へのイベント性を含んだローカルな誘導手段
一般ユーザ
１：携帯端末や設置端末を通じた全体でイベントを構成する配信サービスを受ける（イベントに参加する）
２：イベント内で発生した価値の管理と他イベントでの利用
３：他の連携サービスへのイベント性を含んだローカルな入口

目標とする商業的な機能は
１：ツアー支援アプリ（L1）
２：屋外イベントユーザ誘導進行管理（L1）
３：ツアー、屋外イベントグループ行動、アトラクション、希少性管理（L2~3）
４：ライブRPG（ゲーム）メイキング（モジュール資産形成）（L1〜3+アプリ）
５：ダイレクトな商業施設誘導（L1~2）
６：野外市街での業務チュートリアル（L2+アプリ）
上記のレベルについては1-4-1：シナリオのレベルを参照。（管理者ユーザ或いは開発者に必要な技能レベル）

1-1：サービスのユースケース(図３８、図３９、図４０、図４１、図４２、図４３、図４４、図４５、図４６参照）
サンプルアフターパーティを利用して
付近のアリーナでライブがありバーの経営者は本システムを利用して興行主が提供する素材を利用してライブ帰りの客を自店舗に誘導しようと考えた。
１：興行主が標準化ライブラリに提供するライブ関係のモジュールやデータの検索を行う。
２：検索の結果、クライマックス視聴、ライブクイズ、会場付近のローカルエントリィ（フィールドゾーン定義データ含む）が提供されていたので使用許諾を取得する。またこれらを使用するイベントメインのテンプレートも存在していたので時間、店舗の広さに合いそうなモジュールを確認しておく。
３：管理者ページのシナリオ作成（図４９参照）を開き作成中のシナリオリストから新規作成をチェックする。
４：新規シナリオのシナリオページが開かれる。
５：イベントの次第を考える。
a) ライブは５時に終わるので８時過ぎに店舗内でメインとなるクイズイベントが開始される様に設計する。
b) 移動に一時間前後、受付の締切を６時に設定する。
c) クイズの開始時間は管理者（店長）の判断による。
d) テンプレートのシナリオメインの終了時にイベントが終了する。
６：シナリオチャートページを開きシナリオを作成する。
a) チェックしておいた標準化ライブラリの素材をテンプレートパレットにダウンロードする。
b) 受付、移動、店舗でのイベントの三段階になるので対応するタイムゾーンを処理パレットからドラッグしてチャート上に配置する。それぞれイベント開始から１時間、イベント開始から２時間もしくはトリガ、イベント開始から四時間半にタイムアウトを設定する。
c) 場所はこちらでローカルエントリィの範囲となるライブ会場、移動域の範囲を決めて途中離脱のチェックをする為のレストラン誘導、会場到着判定の為のレストランを作成する。処理パレットからドラッグしてチャートに配置する。なおライブ会場の範囲は興行主よりライブラリデータとして受け取る。
d) クイズ開始トリガを作る為に処理パレットから新規トリガをドラッグして管理者トリガとして配置する。
e) 配置するメッセージおよび記事（図１８参照）を作成する。
f) 必要なユーザ属性を参加者属性管理（図３３参照）で定義する。
g) 記事（図１８参照）やモジュールなどのコンテンツをシナリオの進行上適切なタイムゾーン或いはプレーンフィールドに配置。また遷移制御の為の処理アイコンやシナリオ属性を配置。
h) 必要な遷移矢をステイタストリガからステイタスレセプタに連結し全ての終末を定義する。
i) 特殊記事をシナリオ画面から編集する。
j) 概形チェックを行う。問題があれば前の手順に戻りシナリオを修正する。
７：実行可能シナリオに作成シナリオを登録し、オプションを設定する。（開始時間は当日１７：００の固定、募集は一週間前より開始後１：００まで）
８：（テストを行う）
９：募集を開始する。
１０：時間と成ったらイベントが開始される。
１１：事前募集の参加者は開始時に通常エントリィより遷移を開始する。また開始一時間の間はライブ会場付近のローカルエントリィから登録出来、そこから遷移を開始する。
１２：シナリオに従い参加者の端末に配信を行う。
１３：シナリオに従い参加者の行動によって各参加者の属性値を操作する。
１４：イベントが終了条件に従って終了する。
１５：使用したユーザ属性の中でクイズのポイントとウィナーは保存推奨属性として定義されているので参加者に自分のペルソナの属性ホルダに登録するか配信が行われる。
１６：参加者が登録したら参加者の属性ホルダに保存推奨属性が登録される。
１７：使用したシナリオをプライベートライブラリに登録して再利用に備える。或いは不具合を修正する。
１８：規格を揃えて標準化ライブラリに登録して使用料を狙う。

サンプルとして準備した「ライブイベントアフターパーティ」の場合を参照しつつ、本サービスを説明する。
市営球場でロックコンサートが開催される。その会場に付属する施設又は隣接地において、アフターパーティの会場を提供するスポーツバーがあるとする。そのスポーツバーのローカルエントリィ（ポスター等）から一般ユーザはエントリィする。
コンサート主催者は提携する（広告料を払って球場内にＬＥ：ローカルエントリーを設置した）広告主のイベントに今日のコンサートに関する情報素材を提供する。スポーツバーにはＡＶ（オーディオヴィジュアル）端末が設置され配信されたデータを放映できる。店舗はＧＰＳで確認可能な位置情報を持つ。
エントリィ時には席の予約が行われ、店舗までの誘導がなされる。店舗では入店チェックが行われる。情報素材は二つある。第一に、本日のコンサートの編集映像。第二に、本日の内容に因んだクイズ。各グループにおいて、３問の異なった問題が配信される。店舗には最大三組のアフターパーティグループを収容可能である。クイズは公平に且つグループメンバが希望した時点で行われなくてはならない。グループ別の成績が表示される。パーティが開始されると編集素材がクイズ時以外は放映される。
追加１： クライマックスシーン放映モジュールを追加できる。
追加２： 各グループで競技：全９問のクイズが順に出され、早押しで先に正しい解答をした方がポイントを取得する形式でポイント累計を競う。間違った問題は残りのグループに回答権。
追加３：店舗は飲食店で利用者の携帯端末の入店チェックを行えるチェックモジュールを持っている。

1-2：シナリオ利用の流れ（管理者/ユーザ）
図１を参照しつつ、シナリオ利用の流れを説明する。
管理者ユーザは実施者側ルーチンに従ってイベントを作り配信によって管理する。
1:シナリオ作成（図４９参照）機能を利用、或いはライブラリデータをインポート、ローカライズしてイベントのシナリオを作成する。
2:概形チェックを行い登録可能な状態となったら実施可能リストに登録する。化作業に入る。
3:リストにて詳細設定を行ない実施可能状態となったらユーザの募集を行い、イベントを実施する。
4:イベント終了後属性登録配信を行う。
5:実行済みシナリオとして作成データをライブラリに登録するか再利用をする。
一般ユーザはユーザ側参加ルーチンの手順でイベントに参加する。
１:招待を受けるか招待イベントのイベントページにアクセスする。
２:招待イベントページの招待受付をチェックして招待イベント参加認証プロセスを経て参加をする。
3：エントリィトリガが発生したら実施中のイベントに参加となる。
４:イベントが終了したら属性登録配信で属性ホルダに登録したい属性を登録する。

このサービスは、ローカルエントリから一般ユーザがエントリーする以外に、イベント主催者が携帯端末を持った参加者の端末に配信することによって、一般ユーザが利用可能とすることができる。
図１は、シナリオ実施の流れを示す図である。シナリオは、本システムを構成するプログラムモジュールとして構成され得る。図１の上半分の左側に示されるように、実施者側は、本システムにアクセスし、シナリオを一から作成するか、実行済みシナリオを呼び出して再編集するかによって、シナリオを作成する。このシナリオ作成（図４９参照）は、プログラマーでなくとも、所定の手順によってアイコンをＤＤ（ドラッグ&ドロップ）することなどにより、作成することが可能である。作成途中のシナリオをモジュール化し、当該モジュールを呼び出して、再び作成作業を続けることが可能である。
作成したシナリオが所定の外形的な要件を満たしているなら「実施可能シナリオ」として登録ができる。実施可能シナリオは、「テスト」にかけられて、問題がある場合には、再編集をするように作成者側に返される。不備がなくなるまで、再編集、登録、テストの手続きが踏まれ、実施可能シナリオが完成する。
実施可能シナリオは、参加するユーザを募集する期間の情報（募集開始、募集締切）を持っており、実施トリガによりシナリオの実行が始まり、エントリトリガにより、当該シナリオへのユーザの参加が実現する。実施が終了すると、属性登録の後、実行済みシナリオとなり、モジュール化がなされる。属性登録で登録されたものについては妥当性検証の後に属性保存される。
一般ユーザは、募集告知をみて応募する。招待受付、招待イベント参加認証プロセス（属性チェック、参加者タイプ（図３４参照）決定）を経て、招待登録がなされて、エントリトリガにより実施中シナリオを利用することが可能となる。
属性チェックでは、管理者が参照可能な属性ホルダの属性値と参加者タイプ（図３４参照）の属性条件が比較される。年齢、性別などにより不適合である場合、競業者であるために排除される場合など、参加不能の場合には、その旨が応募した一般ユーザに告知される。参加者タイプ（図３４参照）決定は、属性チェックが終了した後、参加可能参加者タイプ（図３４参照）のリスト（ラジオタイプ）が表示され、応募したユーザが選択するとそのタイプとなる。属性保存では、イベント管理者に保存推奨された属性を属性ホルダに登録するかを決定する。
ポスターに設けられた二次元バーコードからのアクセスなど、ローカルエントリ（ＬＥ）からの一般ユーザの参加も同様の手続きにより受けつけられる。
招待登録は当該シナリオの募集締切のタイミングまでなされ得る。

1-3：アカウント（管理者/ユーザ）
図２を参照しつつ、アカウントについて説明する。
アカウントは一般ユーザと管理者ユーザアカウントに分かれる。
双方とも認証メールアドレスとパスワードで識別を行う。
項目は図に示す通りであるが管理者ユーザはテスト用に一定数の一般ユーザアカウントを発行できる。
レーティング：一般ユーザは参加できるイベントをレーティングによって制限できる。シナリオタグに該当するレーティングがある場合、ユーザはそのイベントに応募できない。（パスワードでロック可能）。
ペルソナ：一般ユーザはイベントで公開する人格をペルソナでコントロールできる。管理者や他の一般ユーザはこのシステム内では特別に公開を決めた情報以外はペルソナで設定した情報しか知る事は出来ない。ペルソナは複数持つことが出来る。ただしメイン以外のペルソナはアプリと紐づけられないとイベントで利用する事は出来ない。
イベントに招く者と招かれる者とは、アカウントを有する者すべてがそれらのいずれにもなり得るとするのが、理想であるかもしれない。しかし、すべての者に対してイベントを運営する能力を要求するのは酷である。もっぱら招かれるのみの一般ユーザのエントランスを出来る限り軽くする。そのために一般ユーザアカウントとディレクターアカウントとを設ける。
図２は、一般ユーザアカウントとディレクターアカウントとを対比しつつ説明する図である。一般ユーザは、その本人認証を認証電子メールアドレス、パスワードにおる行うことができる。また、そのほかにペルソナアカウントで識別することとしてもよい。ディレクター側（シナリオ実施側）が、年齢、性別のみで参加を許可する場合などにはペルソナによる認証が適切である。
ユーザアカウントは、認証メールアドレス、パスワード、プライベート情報（名前、年齢、性別）、レーティング（無制限、Ｒ１８禁止、Ｒ１５禁止から選択）、ペルソナ（端末ごとに設定するが、複数端末で同一のペルソナを利用することも可とする。同一のユーザがスマホとタブレットとを併用する場合など。）、登録端末（複数可）、ペルソナタグ、自己紹介文、各種履歴、などの情報を持つ。図２において、プライベート情報、ペルソナタグ、自己紹介文には、「登録選択」のアイコンが付されている。保存属性ホルダー（タグ登録時、イベント終了時に自動生成される属性ホルダー）に登録可能か否かについての一般ユーザの意思をあらかじめ、またはその都度確認し、一般ユーザが許可するなら属性を保存する。当該イベントに必須の属性である場合には、当該属性を保存することを条件に参加を許可するという手続きもあり得る。
一般ユーザには、当初は課金せずに、無料参加させるかもしれないが、当初から課金情報を登録させて、支払い手段、請求関連情報をあらかじめ登録することができる。
ディレクターアカウントは、認証電子メールアドレスとパスワードとによって本人認証を行う。ディレクターには、個人であっても、企業であってもなり得る。個人の場合には、プライベート情報（名前、年齢、性別、住所、電話番号、使用メールアドレス）を、企業の場合には、企業情報（企業名、担当者名、部署名、住所、電話番号、使用メールアドレス）を登録する。また、アカウントには、たとえばグレード１からグレード５といったグレードを設けて、実施可能なイベントの規模に差を設けて、実績（動員実績、売上実績、支払実績など）に応じてグレードアップできるようにする。各々のディレクターがいずれのグレードであるかについてのアカウントグレード情報を登録する。
また、課金情報（支払手段、請求関連情報）、ディレクターネーム、ディレクタータグ、ディレクター紹介文、各種履歴についての情報を登録する。
収益モデルはディレクターアカウントへの（使用容量に応じた）月額課金と有料モジュール使用料、広告収入、コミュニケーションボード作成手数料を想定する。将来的には対ユーザ課金モジュール使用時のディレクタへのフィー代理徴収手数料、属性ホルダー容量拡大時の使用量、優先ユーザ課金、モジュールマーケットの取引手数料などが考えられる。
一般ユーザアカウントに関して、基本的にディレクター側、広告側が識別するのはペルソナ（年齢、性別のみユーザ許可で利用可能）とする。
ディレクターが自分のシステムでユーザ課金する場合は自システムへの遷移後登録が必要とする（可能な範囲で連携を模索）。

1-4：特徴
モジュールによって重層化されたオブジェクトの動作を各モジュールに付属するシナリオチャートにグラフィックに記述する事で制御する。完成したチャート図において解釈と解析とがなされることにより、マークアップ言語によるプログラミングと同等のプログラミングを実現する。
特徴１：イベント利用時の管理者ユーザ設定のポイントや称号を他の管理者のイベントに持ち越せる自由なシステムである。
特徴２：シナリオ作成（図４９参照）を、フローチャートを配置する様にグラフィカルに行う事が出来る。操作はほとんどについてオブジェクトを収納したパレットブロックからチャートを配置するフィールドブロックにDD（ドラッグ&ドロップ)する事によって実現する。
特徴２-１：現実の配信時に問題となる時間と場所の制限を簡単な操作で取り込める。
特徴２-２：参加者の行動によるイベント（トリガ）発生の処理を簡単なアイコンを画面上に配置する事によって簡単に自由に行う事が出来る。
特徴２−３−１：イベントに必要な計算処理や条件処理を簡易な条件評価矢と代入矢によるオブジェクト間の遷移（結合操作）で行う事が出来る。
特徴２−３−２：複数参加者間の相互作用を管理する全体処理（図３０、図３１参照）用のグラフィカルな作成アイコンを利用してメンバスコープの遷移系列での都度評価を通じて簡単にその時点のサービス対象者を確定できる。
２−４：二次元バーコードを利用したユーザ行動確認システムをアイコン利用にて簡易にシナリオに組み込める。
２−５：ユーザの行動管理に必要なメッセージ配信を重要度に応じてユーザに認識させまたシナリオ中の行動遷移の管理を行う事の出来るシステム。
３：タブとスクロール管理アイコンを利用した親指のみで携帯タッチパネル操作を行う事の出来るユーザインターフェイス。

1-4-1：シナリオ構造とオブジェクトのスコープ
シナリオ制作にあたって組むシナリオで行う事によって複雑さのレベルが存在する。
管理者のアカウントを取得すれば全てが可能となるがチュートリアル、オフィシャルのモジュール化においてレベルは指針となるべきである。
第一レベルは参加者の行動をシステムでは管理せず、実世界の状況に応じてガイドを行うシナリオに適している。
このレベルでは参加者の個別処理のみで相互作用や全体処理（図３０、図３１参照）はシステム上で行わない。また配信の行動管理を行わず例外処理は基本的に記述しないシナリオ記述を行う。この場合、相互作用や例外処理は外部モジュールを使用して処理する。個別シナリオインスタンスをエントリトリガによって生成して個別のユーザ管理を行う。ターミナルステイタスは正規のみを使用。
第二レベルは参加者の行動管理（イベントの進行支援）を行うレベル。
このレベルは参加者の行動をシステムによって誘導、制御する事を前提としたシナリオとなる。その為、重要な参加者の決定、選択をサポートしたり、例外管理の範囲を拡大しイベント目的外の行動を取る参加者に対する多重の誘導を行う仕組みを導入している。
コンテントの処理においてユーザのリアクションをどのように厳密に管理するか終了時のステイタスの種類を区分管理する。
正規行動はイベントの進行において望ましい選択を行っている参加者の選択に割り振られるもので、その終末や重要な経過ポイントに正規ターミナルステイタスを割り振ると発行される。
不正規行動は管理者ユーザがイベントの進行上特に管理すべき選択を参加者が行った場合に割り振るもので、その終末や重要な経過ポイントに不正規ターミナルステイタスを割り振ると発行される。
例外行動はシステム的な例外が発生した場合や高度管理選択時のタイムアウトや例外行動となるフィールドアウトが発生した場合に発生する。コンテントの処理において高度管理を選択すると規定の行動を参加者が行わずにタイムアウトトリガが発生するとタイムアウトが発生して例外管理が行われる。
例外管理指定されたモジュールは特にイベントモニタ（図１１参照）上で管理され、管理者ユーザとの連絡も行う事が出来るようになる。
第三レベルは参加者の相互作用や全体処理（図３０、図３１参照）を行うレベル。
参加者同士の相互作用を想定したアトラクション、コミュニケーション、希少性管理、グループ分けを含むシナリオを実現する為に全体処理（図３０、図３１参照）とグループの概念を導入した。
全体処理（図３０、図３１参照）記述によって処理対象の整理を行ったり、全体処理（図３０、図３１参照）属性と全体処理（図３０、図３１参照）計算チャートを使用して相互作用やイベント全体に関わる処理や参加者のグループ化と処理を行う。
＃シナリオ挙動

1-4-2：トリガ（Y-1を参照）
イベントはトリガと参加者のリアクションの相互作用を管理者がシナリオに記述して進行する。
トリガを発生させる要因は、ステイタストリガとして遷移矢の起点となり3-3-1-5：記述子（処理アイコンと遷移矢、トリガアイコン）に詳述されるステイタスレセプタに結び付けられ、シナリオを駆動する。
エントリィ処理：イベントの開始及び参加者のエントリィは後述する図１２のスタートオプションと図４のエントリィトリガによって制御される。
イベント開始は実施可能シナリオのスタートオプションに規定されて開始される。全体処理（図３０、図３１参照）シナリオインスタンスが（あれば）生成され参加者のエントリィが受付可能となる。
参加者のエントリィがいつ行われるかはETMが第一層の非全体処理（図３０、図３１参照）記述に配置されているかによって決まる。
配置されていない場合はイベントの実施タイミングと参加者のエントリィタイミングは同じで募集締め切りまでのエントリィは全て同一の処理を受ける（タイミングはずれる）。
配置されている場合はID情報付のエントリィが行われたか否かで処理の内容が異なる。
既に参加している参加者は一層かそれ以下の階層か問わずに最初に発行されたETMのトリガによってその遷移線に従って処理が行われる。それ以降のエントリィも都度発生したETMによって処理が行われる（前の（一般）ETMイベント以降に参加した参加者が対象）。
個別IDを受け付けたETMはその参加者をその遷移線に従って処理する。
端末のローカル交信手段（QR含む）と関連付けられたETMはローカルエントリィと呼ばれ、特別に管理される。
トリガチェッカーの各種画面に登録されエントリィ可能なポイントとして一般ユーザに示される。
二層以下の個別ETMはその記述のある全体処理（図３０、図３１参照）インスタンスが生成されていれば機能する。そうでない場合は（ETMとしては）無視される。
また開かれた個別処理インスタンス内のETMはOSTMとして機能する。

1-4-3：シナリオ構造とオブジェクトのスコープ
図５参照
シナリオはモジュールの配置関係によって層構造をなす事がある。
ある階層のチャート記述、あるいは外部モジュールのプロパティ（図２９参照）に配置されたモジュールはその下の階層のモジュールと見做される。最上位はシナリオチャートであり最初に生成される。
それ以下の階層は個別、全体処理（図３０、図３１参照）の生成トリガレセプタが評価された時に生成する。ETMのみは個別であっても同モジュールの全体処理（図３０、図３１参照）インスタンスの挙動に従う。
生成トリガが複数の場合、同一レベルに複数のコンテンツのインスタンスが生成される事もある。
それぞれのチャート、プロパティ画面に記載されたコンテンツはそのモジュールの子要素と見做される。
コンテント、クラス化されたゾーン及び属性は定義モジュールを持ち、それ以下の階層で参照可能かつ配置可能となる。また属性は属性値を共有する（コンテンツの挙動は配置モジュール毎に異なる）。
ユーザ属性はシナリオに属する。

1-5：システム構成
シナリオを作成し、一般ユーザ（一般ユーザアカウントを有するユーザ）の参加するイベントを管理する管理者ユーザ（ディレクターアカウントを有するユーザ）と携帯端末の機能を使ってイベントに参加する一般ユーザとのそれぞれに対して、以下のサービスを提供するネットサービスである。
管理者ユーザに提供するサービス
１：イベントシナリオ作成（図４９参照）
２：イベントシナリオ実施管理
３：イベント実施
４：イベント内で発生した価値の管理と公開
５：シナリオ及びシナリオ素材のストレージ及びライブラリ提供
６：上記ライブラリでの素材の流通
７：自己サービスや施設へのイベント性を含んだローカルな誘導手段
一般ユーザに提供するサービス
１：携帯端末や設置端末を通じた全体でイベントを構成する配信サービスを携帯端末の参加者認証機能を利用して受ける
２：イベント内で発生した価値の管理と他イベントでの利用
３：他の連携サービスへのイベント性を含んだローカルな入口

1-5-1：提供手段
管理者ユーザにはブラウザを利用したｗｅｂサービスとして管理者画面及び緊急対応用の通話機器を利用して提供される。
一般ユーザには携帯端末のブラウザを利用したｗｅｂサービスもしくは1-5-2の機能を持った端末内のアプリを通じて提供される。1〜4）の機能はブラウザでも実現できるようにする。

1-5-2：アプリ
機能
１）ＧＰＳ位置定期確認
２）二次元バーコード読み取り
３）写真アップロード
４）メール配信時プッシュ通知
５）ユーザチェックコード括り付け（管理者向け）
６) ページ閲覧

1-6：重要/共通ロジック/ビジネスロジック
重要な共通ロジック、ビジネスロジックをここに列挙する。
＃ログイン/ログアウト
＃コンテンツリスト（切り出し）
＃フォーム入力検証
＃認証メールによる真実性確認
＃端末登録プロセス
＃アプリダウンロード
＃タグ-属性転換機構
＃ホットコンテンツ表示順算出プロセス
＃イベント/コンテンツユーザリスト表示モードセット
＃ログコンテンツ表示
＃参照可能ユーザ確定プロセス
＃招待イベント参加認証プロセス
＃コンテント状態制御
＃二次元バーコードページ生成
#緊急処理
＃場所トリガ取得表示
＃ローカルエントリィプロセス
＃保存属性管理
＃終了マージン
＃概形チェック
＃シナリオ遷移制御
＃ライブラリ遷移
＃記事記述-ユーザイメージ転換
＃インポート可能属性リスト
＃シナリオ/計算チャート
＃メール配信
＃チャートモニタ（図１５参照）
＃ログ管理
＃イベントアクティビティ
＃マウスポインタモード
＃チャート解釈
＃メンバ制約
＃パレット
＃定義/スコープ
＃クラス/テンプレート
＃外部連携
＃メンバスコープ
＃グループ管理
＃インスタンス管理
＃外部データ利用
＃遷移制御
＃代表値
＃計算ゾーン
＃タイミング設定
＃参加者タイプ（図３４参照）決定プロセス
＃シナリオ属性登録プロセス
＃時制検索編集フォーム
＃全体処理（図３０、図３１参照）
＃持続設定

図３は、シナリオチャート記述のレベルを説明する図である。
基本記述では、参加者相互作用無し、全体処理（図３０、図３１参照）属性なし、斉一記述に一定の制限がある。基本記述では、実施可能シナリオ、実施トリガ、エントリトリガ、条件を満たした参加者の個別シナリオインスタンス、個別シナリオインスタンス内部に記述されたモジュール（個別）が扱われる。
全体処理（図３０、図３１参照）導入においては、全体処理（図３０、図３１参照）モジュール、全体処理属性を利用した相互作用、斉一配信処理、対インスタンス処理がある。
第一層全体処理タイムゾーン（TZ)は実施トリガ発生時を開始時点とした全体処理シナリオインスタンス上のTZとして挙動する。
全体処理モジュールは全体処理を駆動し、メンバスコープをなすメンバに対するシグナルを発する。
全体処理（図３０、図３１参照）は全体処理（図３０、図３１参照）シナリオインスタンス上で機能する。全体処理記述を利用して行われる。
全体処理（インスタンス）は個別インスタンスとは幾つかの接合記述を介して接続するが基本的には全体処理遷移矢による遷移によって駆動される。
モジュールインスタンス（個別）は、対個別インスタンス処理（メンバではなくインスタンスが対象）である。
全体処理導入レベルの記述は複雑さが増すのでインターフェイスに関門を設け確認を取る必要（簡易処理では全体処理記述は全体処理モジュールの配置に留める）がある。

図４は、トリガについて説明する図である。
トリガは、実施トリガとエントリトリガとが準備される。
第一層記述にエントリトリガが配置されていない場合には、実施トリガとエントリトリガとは、同一の意味を持つ。実施トリガ発生時に登録者に斉一にシナリオインスタンスと全体処理インスタンスが生成される。
第一層記述にエントリトリガが配置されていると、実施トリガとエントリトリガとは、異なる意味を持つ。実施トリガ発生時に全体処理インスタンスが生成され、エントリトリガ発生時に逐次的にシナリオインスタンスが生成される。
外部トリガ記述モジュール（ＯＳＴＭ）は、外部トリガとして指定可能なイベントのリストから選択発生条件を設計する。外部モジュールである。個別ベント内では個別ユーザＩＤを乗せる機能のあるＯＳＴＭは別ＩＤを無視する。
エントリトリガ記述モジュール（ＥＴＭ）は、ユーザのエントリトリガを発生させる機能を付与した外部トリガ記述モジュール（ＯＳＴＭ）である。個別ユーザＩＤを付与できる場合もある。
ローカルエントリ（ＬＥ）は、トリガにローカルな手段（端末アクション）で個別ユーザＩＤを乗せる機能のあるＥＴＭである。LEは参加登録と個別インスタンス生成機能を持つ。
エントリトリガアイコンを利用可能とするとユーザ勧誘の自由度がアップし、複雑なシステムにすることができる。
或いはこのエントリ記述に関する仕様は第一層が全体処理モジュールであるか個別の通常処理（のみ）を行うものであるかによって判別しても良い。
第一層が個別処理（のみ）の場合はエントリィトリガは単なる外部トリガとして処理されエントリィ処理（個別参加者のシナリオインスタンス生成処理）は招待済みの参加者は実施トリガ発生時に全てエントリされ、以降の募集期間での参加者は随時エントリィトリガを受け取った時点で第一層から処理が始まる。参加者の経路は参加時点で付与される参加者属性によってのみ区別される）。
第一層が全体処理である場合は参加者はエントリトリガが無い場合はメンバースコープに編入される事になる。実施トリガによる全体処理の進行によって随時個別処理を受ける形になる。エントリィトリガが有る場合はエントリィトリガ生成時の招待者（待機者）、或いは括り付けられた個別ＩＤ保持者がトリガから始まる遷移に従ったサービスを受ける事になる。
外部トリガとして記述可能なトリガのうち、端末アクションとして個別ユーザと括り付けられるものは、次の三つを含む。
バーコード検知：ポスターなどの専用二次元バーコード等の読み取り。
アプリ入力：連携システムのアプリのエントリィ入力。ＩＣ読み込み、端末近接交信手段など。
位置情報（場所トリガ）：アプリがフィールドゾーンと関連付けられた位置情報を取得した時。
外部トリガとして記述可能なトリガには、グローバルトリガもある。たとえば、指定したＵＲＬの特定キーワード、タグを含む記事（図１８参照）の配信(RSS)である。
外部トリガとして記述可能なトリガには、連携したシステムからのシグナルも含まれる。個別ユーザと括り付けの可能性がある。
個別ＩＤと関係づけられていないトリガは発生時に登録されたすべてのユーザの個別インスタンスを発生させる。
第一層にエントリィトリガが配置されていない場合の二層以下のエントリィトリガは単なる外部トリガと見做される。
エントリィを発生させなかったＥＴＭの個別インスタンス内での扱いは、ＯＳＴＭ扱いになる。

図５は、コンテンツ、属性のスコープとインスタンスの関係について説明する図である。図５に示すように、第一層、第二層（一層チャート）、第三層（二層チャート）、第四層（三層チャート）と階層があり、シナリオは第一層に記述される。記事（図１８参照）などのコンテンツは、他の層に記述される。
第一層には、モジュールテンプレート、シナリオ、実施トリガ、エントリトリガ、個別シナリオインスタンス、全体シナリオインスタンスが記述される。テンプレートにも定義モジュールを付ける事が出来る。これはライブラリでのモジュール運用及びパレット反映を減らすためである。
コンテントは、シナリオ属性定義モジュールのチャートかそれ以下の階層で使用が可能である。
定義は、同名で定義されても別モジュール上ならアイコン上に上に付記されて別属性として使用可である。
基本的にシナリオ属性は定義されたモジュールに対して一つの値である。以下の階層での入力は全て一か所に入る。
コンテントの定義は基本的に参照可能性を定義する。定義位置に関わらず子要素となったコンテンツは発生トリガを受ければインスタンスを生成する。（外部モジュールの挙動は保証しない＝定義に対してユニークである場合も許容）。
図５では、第三層においてＢ記事インスタンスにＰインスタンスが定義され、さらにもう一つのＢ記事インスタンスにＰ’インスタンスｇ定義されている。また、第四層において、Ｄネストモジュールインスタンスが複数、記述されており一方にはＰインスタンスが定義され、他方は、Ｐ’インスタンスが定義されている。この様な場合シナリオ属性はフォームなどで入力されれば別インスタンスに格納される。定義に対してユニークな為である。

2：ユーザ画面
2-1：画面遷移
図６は、ユーザ画面の遷移を説明する図である。
サイトにアクセスした未認証のユーザはログインページに入る。認証済みのユーザ、ログインしたユーザはメインペルソナのユーザホーム（図７）に入る。＃ログイン/ログアウト
ログインページの未認証のユーザはアカウントが入力出来ればログイン、出来なければ新規登録ページに遷移する。
新規登録ページでアカウント作成に成功したユーザはアカウントページに遷移する。各ページは全画面共通ナヴィ、種別共通ナヴィを持つ。
ログイン（アウト）画面、コンテントフル表示、ローカルエントリィは全画面共通ナヴィを持たない。
全画面共通ナヴィは、アカウント、ユーザホーム（ペルソナが特定されない状況ではメインペルソナのユーザホーム）、トリガチェッカーエントリィ、ログアウトにそれぞれ遷移する。
・アカウントからペルソナ管理へ遷移する。
コンテンツのリストからペルソナ管理へ遷移する。
・ペルソナ管理系のページは、ペルソナ管理、ユーザホーム、属性ホルダ、ペルソナ総合リストページの表示中コンテントリスト（図３２参照）、待機中コンテントリスト（図３２参照）、参加中イベントリスト、招待中イベントリスト、イベントログリストにそれぞれ遷移する。
ペルソナ管理系共通ナヴィはペルソナ管理系の各ページに遷移する。
メインブロックからの遷移が発生するのは
・ユーザホーム（サブ含めて）の可能な遷移先
コンテンツ（図７該当図下部）のリストから
ホットコンテンツから
参加イベントホーム（開始後）該当コンテンツのタブを最前表示
最近アクションのあった参加イベントから
（内容によって）
参加イベントホーム（開始後）
参加イベントホーム（未開始）
招待イベントピックアップ！から
招待イベント個別ホーム
・表示中コンテントリスト（図３２参照）のコンテンツのリストから
参加イベントホーム（開始後）該当サブ画面
・待機中コンテントリスト（図３２参照）のコンテンツのリストから
参加イベントホーム（開始後）該当サブ画面
・参加中イベントリストのコンテンツのリストから
参加イベントホーム（遷移に応じて＊２−３項参照、参加イベントホーム（開始後）、参加イベントホーム（未開始））
・招待中イベントリストのコンテンツのリストから
参加イベントホーム（遷移に応じて＊２−３項参照、招待イベント個別ホーム）
・イベントログリストのコンテンツのリストから参加終了イベントホーム
・イベントホームについてイベントの状態によって三態（図６中央招待イベント個別ホーム、参加イベントホーム（未開始）、参加イベントホーム（開始後））に変化する。＊2-3イベントホームの項参照。
・招待イベント系のページは
招待イベント個別ホーム
招待イベント参加認証プロセス
共通ナヴィは招待イベント系の各ページに遷移に加え以下に遷移。
招待中イベントリスト
参加中イベントリスト
・招待イベント個別ホーム
サブ画面から
イベント説明ページフル画面
イベントによりサブ画面に以下が追加される事がある。
招待状
・招待イベント参加認証プロセス
また状態遷移により
参加イベントホーム（未開始）
・参加イベントホーム（未開始）から
共通ナヴィから
参加中イベントリスト
招待中イベントリスト
参加イベント離脱
サブ画面から
イベント説明ページフル画面
また状態遷移により
イベント開始画面
・イベント開始画面
状態遷移により参加イベントホーム（未開始）から参加イベントホーム（開始後）
・開始後イベント系のページは
参加イベントホーム（開始後）
参加イベントコンテンツログ
参加イベント待機コンテンツ
参加イベント表示中コンテンツ（リスト形式）
共通ナヴィは招待イベント系の各ページに遷移に加え以下に遷移。
参加中イベントリスト
参加イベント離脱
・参加イベントホーム（開始後）は
サブ画面から
表示中のコンテンツのフル画面
イベント説明ページフル画面
・参加終了イベントホームから
共通ナヴィから
参加イベントコンテンツログ
イベントログリスト
サブ画面から
イベントログフルページ
イベントによりサブ画面に以下が追加される事がある。
保存推奨属性登録画面
アフターフォロー画面
・イベント関連リストは遷移元の参加イベントに関連付けられている（参加中のイベントごとにページが存在）。
・参加イベントコンテンツログのコンテンツのリストから
コンテンツフル表示/ログ
・参加イベント待機コンテンツのリストから
コンテンツフル表示/待機コンテンツ
・参加イベント表示中コンテンツ（リスト形式）のコンテンツのリストから
コンテンツフル表示
・コンテンツフル表示から
ヘッダークリックにより
参加イベントホーム/該当コンテンツのタブを最前表示
・イベント説明ページフル表示
ヘッダークリックにより
イベントホーム/イベントの状態遷移に応じて＊2-3項で説明
・トリガチェッカー系ページは
エントリィ画面
トリガマップ
参加可能ローカルエントリ
共通ナヴィは招待イベント系の各ページに遷移
・トリガマップから
招待イベント個別ホーム
・参加可能ローカルエントリ
招待イベント個別ホーム
・ローカルエントリィより
招待イベント個別ホーム

2-1-1：ナヴィゲーションバーの挙動
ナヴィゲーションバーの挙動は、全画面共通である。画面系ナヴィゲーションバーはアイコンとしてヘッダー上に配置される。
クリックするとサブ画面とのの間にバーが出現しアイコンをクリックすると遷移する。配置は効率的に双方が呼び出されたなら全画面共通と画面系は並列でバー上に並べる事。再びヘッダーのアイコンをクリックすると消える。
残余の画面は下スクロールにより出現する。

2-2：管理系画面
2-2-1：ログイン画面
括り付け
なし
必須の画面要素
１）認証メールアドレスとパスワードの入力フォーム
２）新規登録ページへのリンク（説明文と共に）
１）への入力がアカウントとマッチしたならログインセッション開始。マッチしないなら画面上に警告アラート挿入し回帰。＃ログイン/ログアウト

2-2-2： 新規登録
括り付け
新規登録
必須の画面要素
１） メールアドレスとパスワードの入力フォーム
a)メールアドレスの真実性確保のプロセス必須。＃認証メールによる真実性確認
b)パスワードの堅牢性チェック考慮。＃フォーム入力検証
入力されたパスワードに対して、例えば
* 大文字が入っているか
* 小文字が入っているか
* 数字が入っているか
を走査して確認、それぞれの条件を満たしていて、なおかつ 8 文字（例）以上なら OK というような記述をすれば OK
入力がa,bのチェックに成功したならアカウント作成、アカウントページに遷移。
c)パスワードは平文では保存せず、SHA-256 などでハッシュ化して保存（この手のハッシュは復号できないので、システムの管理者でも各ユーザーのパスワードは閲覧できない）

2-2-3： アカウント
括り付け
ユーザＩＤ（以下の画面説明では省略）
必須の画面要素
１） 認証メールアドレス表示#メール配信
２） パスワード変更入力フォーム
３） パスワード忘却時のリンク先
４） プライベート情報入力フォーム（選択）と入力済み情報の表示
3-1）氏名
3-2）性別
3-3）生年月日
５） レーティング
無制限、Ｒ１８禁止、Ｒ１５禁止の三択ラジオ式
６） 課金情報 詳説せず 適切なAPIを利用（ペイパルAPI決済）
７） 登録ペルソナリスト（リンク）
８） 新規ペルソナ登録（リンク）
９） 全画面共通ナヴィ（ペルソナ登録後に機能）
a)２）は通常時は「パスワード変更」の文字列のみ表示。＃フォーム入力検証
クリックすると一列の現パスワード入力フォーム。
入力すると二列の新規パスワード入力フォーム
正確な入力に成功すればパスワード変更。
b)４）は入力後、再編修用の入力フォームは隠し、再編集ボタンを項の末尾に配置3-3）について生年月日入力後は年齢と生年月日の表示。
c)３）はパスワードをリセットして再設定用のフォームを認証メアドに送付。＃認証メールによる真実性確認＃メール配信
d)6,7)のリンク先はペルソナ管理ページ

2-2-4： ペルソナ管理
ペルソナ情報の登録と編集閲覧、管理を行う。
括り付け
新規登録
ペルソナID
必須の画面要素
１） 登録端末情報
休眠チェック
削除
２） 新規端末登録
３） ニックネーム入力と表示
４） 一言紹介（４０字以内）
５） タグ入力フォーム
６） 自己紹介入力フォーム
７） メイン選択（選択ボタン）
８） 参加ログ（表示選択ボタン）＃ログ管理
９） 全画面共通ナヴィ
10)ペルソナ系共通ナヴィ
a) ペルソナは複数登録する事が出来、ペルソナＩＤが割り当てられる。ユーザはこの登録したペルソナの内、一つにメイン指定を行わなくてはならない。デフォルトは最初に登録したペルソナ。
b) 端末登録はアプリストアからスマートフォン・タブレット端末にアプリをダウンロードさせるように誘導し、アプリを開いてログインし、管理画面から使用するペルソナを選択させる。この場合、公式保存属性（公開）に「アプリユーザ」が加わる。ダウンロードしたアプリには愛称が必要。＃アプリダウンロード＃端末登録プロセス＃認証メールによる真実性確認＃メール配信
c) どの端末にもアプリケーションをＤＬしない場合はメインペルソナがどの端末でも利用されることになる。（端末登録が無い場合は他の登録ペルソナはメインにならないと利用できない。メインの変更は参加中のイベントがあると不可能）
d) 登録した端末はどれでもペルソナ管理画面で愛称、所属情報を見ることが出来る。また所属ペルソナをペルソナ選択で該当ペルソナに変更できる。
e) 3,4,6項についてはフォームの入力内容を単純にフォーム内に表示する仕様で良い。
f) ５項タグの入力はフォームをクリックすると公式タグが選択可能なサブ画面が出現する。タグについては2-7項参照。
サブ画面には
公式タグ
グループ化されて表示される択一的公式タグ
プライベートタグ入力フォーム
が表示される。
ｄ-1）公式タグが選択されたらクリックされたフォームに該当タグが表示登録
ｄ-2）択一的公式タグが選択されたら図８のタグ登録プロセスを辿って（アラートで駆動）登録。
ｄ-3）プライベートタグ入力フォームに入力されたらクリックされたフォームに該当タグが表示登録
e)８項の参加ログについては通常時は閉めておき、参加ログ表示ボタンがクリックされたら画面下部を延長して表示。ログについては3-3-1-9項を参照。＃タグ-属性転換機構

2-2-5： ユーザホーム
ユーザ（ペルソナ）の活動のベースとなり新規情報の確認が出来る。
括り付け
ペルソナID
必須の画面要素
１） ホットコンテンツ（リスト）
２） ホットコンテンツ拡大ボタン
３） 最近アクションのあった参加イベント（リスト）
４） 最近アクションのあった参加イベント拡大ボタン
５） 招待イベントピックアップ！（リスト）
６） 招待イベントピックアップ！拡大ボタン
７） 全画面共通ナヴィ
８） ペルソナ系共通ナヴィ
a) ホットコンテンツは参加中の全イベントのコンテンツを対象に重要度の高い「記事表示中未選択」記事、「待機中」記事もしくは入力待ちの外部モジュールインスタンスを抽出リスト化する。（図１７参照）
重要度の算出ロジック（Wtの高いコンテンツを上位に）
（明示されたタイムアウト残時間*Wt1+表示開始時間からの経過時間*Wt2+選択拘束付状態有記事か？（0/1）*Wt3+属性値入力（フォーム）ありか？（0/1）*Wt4）*シナリオの重要度（システム指定）Wts＝Wt＃ホットコンテンツ表示順算出プロセス
b)最近アクションのあった参加イベントは参加中の全イベントを直近でコンテンツ表示がされた順でソートしてリスト化する。
c)招待イベントピックアップ！は条件（3-4-1-1項参照）の合う招待イベントにシナリオの重要度（システム指定）Wtsで荷重を付けリスト化する。同Wｔの場合は新着順となる。
d)1,3,5項についてはリスト上位の表示可能な数の項を抽出表示する。
e)2,4,6項についてはクリックされると該当項の全リスト表示にコンテンツ部が変化する。＃イベント/コンテンツユーザリスト表示モードセット

図７は、ユーザーホーム、参加イベントホーム、コンテンツフル表示、それぞれの例を示す。ユーザーホームでは、表示中コンテンツリスト、待機中コンテンツリスト、参加中イベントリスト、招待中イベントリスト、属性ホルダ、ペルソナ管理、ユーザホーム、ペルソナナヴィ、共通ナヴィへそれぞれ遷移可能なボタンが表示されている。
参加イベントホームでは、秋の富士五湖スタンプラリーに参加している例について示してある。へのもへ子さんというユーザの参加イベントホームであって、「スタンプラリーエリアに到着しました」、「ガイドモジュール（第一ポイント）」、「イベント離脱画面」、「待機中呼び出し」、「イベント説明ページ」にそれぞれ遷移するためのタグ、及びイベントナヴィ、共通ナヴィに遷移するためのボタンが表示されている。

2-2-6：属性ホルダ#保存属性管理
括り付け
ペルソナID
必須の画面要素
１） 保存属性リスト
1-1） 属性名
1-2） 属性値
1-3） 属性種別（提供主）
1-4） 属性値タイプ
1-5） 公開設定
1-6） 削除項
２）全画面共通ナヴィ
３）ペルソナ系共通ナヴィ
ここで扱うものは保存属性となる。保存属性そのものについては2-8項を参照。
a)1-2属性値は値が表示されるが属性のプロパティが編集可能となっている場合はフォームとなり属性値を書き換えられるようにする。
b)1-5公開設定は属性のプロパティが表示されるが公開選択可の場合はチェックボックスとなりチェックされた場合公開と同じ扱いとなる。
c)1-6削除可能なプロパティの属性にはチェックボックスが現れる。チェックされるとアラートが出現して削除可となったらその属性は削除される。
d)1-3）属性種別で提供主が存在する場合はディレクターページへのリンクとなる。

図８は、属性ホルダ、ペルソナ管理の表示例、タグ登録の流れを示す。
属性ホルダは、各ユーザについて、属性名、属性値、属性種別、属性値タイプ、公開非公開の別の情報を持っている。属性名は、たとえば、性別、年齢、在住県、職業、参加シナリオなどである。属性値は、女性、２９、和歌山県など。属性種別は、当該属性の提供主。属性値タイプは、文字列、数値、真偽など。
属性の公開設定は他の管理者ユーザが参照できるかを示す。チェックボックスが存在する属性は選択可な属性でチェックを入れると公開となる。
属性値がフォーム内に記載されている属性はユーザが編集可能な属性で記入かプルダウンで選択できる。参加シナリオ内で属性インポートされている場合、参加中は編集不能である。
タグ関連属性はタグに依存、タグが削除されると属性も削除される（偽）。

2-3：イベントホーム（イベント利用時の遷移）
2-3-1：基本フォーム
括り付け
ペルソナID
イベントID
必須の画面要素
1) サブ画面
2) 全画面共通ナヴィ
3) 遷移に応じたイベントナヴィ
a) １のサブ画面はコンテント表示領域とコンテントタブ領域に分かれる。
a-1)ユーザがクリックして選択したコンテントを表示する。
a-2)コンテントの空き領域をダブルクリックするとフル画面に遷移する。
a-3)表示中のタブをダブルクリックするとアラートが発生しコンテントを閉じるか確認される。閉じるを選択すると表示が消え終了、もしくは待機中にモードが変更される。#コンテンツ状態制御
a-4)各遷移状態でタブに何が表示されるかは変わる。
a-5)タブについては三段までドラッグにより横スクロール可能とする。
a-6)ユーザのドラッグによる配置変更を可能とする。
b) ログモード
参加イベントホーム（開始後）および参加終了イベントホームではサブ画面でログを表示するログモードが存在する。ログ形式（3-3-1-10： コンテンツログ）のコンテンツを閲覧可能なモードでタブが反転したログ画面がサブ画面に追加される。ログのタブがすべて消えるとログモードは終了する。ログモードではログが操作不能である旨のメッセージがヘッダーに表示される。＃ログコンテンツ表示

2-3-2：イベント利用時の遷移について（イベント開始画面と招待イベント参加認証プロセス）図１及び図１４を参照。＃シナリオ遷移制御
１）ユーザは何らかの形でイベントの招待リストに登録されると招待状態になる。
これには
1：招待イベントピックアップ！にオンリスト後イベントホーム閲覧時にチェック
2：参加可能ローカルエントリにオンリスト後イベントホーム閲覧時にチェック
3：招待メールを受け取りチェックした場合
4：ローカルエントリィに接触した場合
5：ウェブ上の誘導サイトでクッキーを取得した場合
が当たる。＃参照可能ユーザ確定プロセス
２）ユーザが説明ページのチェックを押すとアラートが発生し招待イベント参加認証プロセスが開始される。
３） レーティングチェックが行われる。ユーザのレーティング情報とシナリオタグのレーティング情報を比較して該当する制限に引っかかった場合はプロセスは停止する。
４）属性チェックが行われる。属性チェックでは管理者が参照可能な属性ホルダの保存属性値と参加者タイプ（図３４参照）の属性条件が比較される。＃保存属性管理＃参加者タイプ（図３４参照）決定プロセス
１：参加可能な参加者タイプ（図３４参照）のリスト
２：ユーザ側で即時の付与が可能(タグ、属性ホルダ操作)。
また編集を推奨し再び参加受付をお願いするアラートが表示される（従えば属性ホルダに遷移）。
ユーザ側はそれが非公開属性であれば設定を変更、タグ関連属性であればタグを取得して条件を合わせられる。
３：どのタイプに対しても１，２に当てはまらなければ参加不能となりアラートが発生し参加不能が告知される。
４：１の参加可能な参加者タイプ（図３４参照）のリストが生成された場合はサブ画面が生成され選択がなされる。参加可能参加者タイプ（図３４参照）のリスト（ラジオタイプ）がサブ画面に表示され選択するとそのタイプとなる。
但し属性チェック２の条件に当てはまるユーザには条件を整えた後再選択をするかの警告文が表示される。
リストはエントリトリガが発生するまで変更可能でサブ画面の一つとして残る。
５）属性条件を満たし参加者タイプ（図３４参照）を選択したユーザは「属性条件達成」となり参加イベントホーム（未開始）が表示されるようになる。＃招待イベント参加認証プロセス
６）エントリィトリガが発生するとホットリストの最上位にイベント開始ページが載る。
参加イベントホーム（開始後）ページが表示されるようになる。
７）イベントが終了するとイベント終了画面が表示され参加終了イベントホームが表示される。
８）2-8-4:保存推奨属性の登録利用プロセスの3-6)項〜の保存推奨属性登録画面が配信され保存推奨属性の登録が行われる。＃保存属性管理

2-3-3：招待イベント個別ホーム
a) 招待イベントイベントナヴィ表示
b) サブ画面にはイベント説明ページが表示される。

2-3-4：参加イベントホーム（未開始）
a) 未開始イベントナヴィ表示
b) サブ画面にはイベント説明ページと参加者タイプ（図３４参照）選択画面が表示される。

2-3-5：参加イベントホーム（開始後）
a) 開始後イベント共通ナヴィ表示
b) サブ画面には閉じられていないメッセージおよび表示中モードの記事（図１７）とアクティブな外部モジュールのサービス画面、閉じられていないイベント説明ページと参加者タイプ（図３４参照）選択画面が表示される。さらに特殊なタブとして待機中表示タブが置かれる。
c) タブのソートは新着順とする。可能な操作があれば参加イベントおよび表示中で制限されたホットコンテンツを表示させるモードが欲しい。＃イベント/コンテンツユーザリスト表示モードセット
d) 待機中表示タブが選択されると2-5-6項参加イベント待機コンテンツに遷移する。

2-3-6：参加終了イベントホーム（終了後）
a) 参加終了イベント共通ナヴィ表示
b) サブ画面には画面ログが表示され、アフターフォローがあればアクティブページとして表示される。＃ログコンテンツ表示

2-4：コンテンツ
ユーザがこの画面で利用できるコンテンツは記事（図１８参照）と外部モジュールのサービス画面となる。また特殊な記事としてイベント説明ページ（招待メッセージ含む）、参加者タイプ（図３４参照）選択画面、イベント開始ページが存在する。
生成されたコンテンツはメールで配信され、アクティブモードとしてユーザ画面に登録される。
コンテンツメール配信：コンテンツが生成されるとユーザの端末指定のメアドに外見が同じhtmlメールが送られる。最初のアクション時もしくはイベントの設定されて居ない場所を選択するとブラウザ若しくはアプリが呼び出されて表示が行われる。
＃メール配信
生成されたコンテンツは
アクティブ
待機
終了
の三つのモードを持つ。
アクティブモードのコンテンツは表示中の記事（図１８参照）、アクティブなサービス提供を行っている外部モジュールサービス画面が含まれる。
アクティブモードのコンテンツはタブ操作、記事中の閲覧終了処理、外部モジュールの状態制御によって待機モードか終了モードとなる。図１７参照。
待機モードのコンテンツは待機中の記事、待機中の外部モジュールサービス画面が含まれる。
終了モードのコンテンツは終了状態となった記事および外部モジュールサービス画面
特殊な記事は消されると待機モードに移行する。＃コンテント状態制御

2-4-1：フル表示
コンテントのフル表示を行う。ヘッダーをクリックすると元画面に戻る。

2-4-2：特殊記事
特殊記事は図９のシナリオ画面の特殊記事に登録され管理者のトリガによって配信される。終了状態はなくイベントがログとして格納するまで閉鎖されても待機となる。フォームを仕込む事も可能でユーザが参加状態となれば属性値に反映される。
1) イベント説明：イベントを説明する。複数P作成する事も可能でその場合は特殊記事でのシーケンス順に配置される。最低１Pにチェックが存在する必要がある。押すと2-3-2 ２）のプロセスが開始。＃招待イベント参加認証プロセス
2) 招待状：事前告知用の記事。募集開始後3-4-6-1:告知メール配信で配信可能。記事のチェックを押すと招待状態に成る。＃参照可能ユーザ確定プロセス
3) 参加者タイプ（図３４参照）選択：2-3-2 ３）のプロセスを行う要件を満たす必要。自動生成。＃参加者タイプ（図３４参照）決定プロセス
4) 保存推奨属性登録画面：2-3-2 ７）のプロセスを行う要件を満たす必要。自動生成。＃保存属性管理
5) アフターフォロー：事後告知記事。イベント終了後3-4-6-1:告知メール配信で配信可能だが参加者に限られる。
6) 識別二次元バーコード：2-11：識別二次元バーコードに記述された二次元バーコードを表示する。参加中有効。＃二次元バーコードページ生成
7) 緊急チャット：管理者コール時に呼び出されるページ。チャットで管理者とコンタクトをとる事が出来る。自動生成。常に最前面に表示される。＃緊急処理

2-4-3：外部サービス＃外部連携
ユーザは外部のサービスを三つの形態で利用できる。
A：サービス提供画面：上記コンテンツの制限に従う外部のサービスをコンテンツとして利用できる。これを外部モジュールのサービス提供画面と呼ぶ。
B:連携サービス：記事の埋め込み連携画面パーツから連携する携帯アプリ、ウェブサービスを利用できる。画面遷移が起こる場合もそうでない場合もある。画面遷移が起こる場合は独立したサービスとしてイベントの進行とは切り離されて提供される。（内容は認証を受けている）サービスの継続の有無にかかわらず連携元のコンテンツが終了した場合、連携は終了する。
C:リンク：リンクによる遷移でサービスを受ける事も出来る。この場合遷移以降のサービスについてシナリオは無関係となる。遷移時にその旨の警告がアラートされる。
ユーザ認証：A,Bの外部サービスを利用する際、アカウント、連携するサービスの個人情報が利用される場合は認証確認画面が現れ利用の確認がなされなくては成らない。＃ログイン/ログアウト

2-5：リスト
リストは全て新着順、逆順、荷重順（2-2-5： ユーザホーム参照、ログ以外のコンテンツ）＃ホットコンテンツ表示順算出プロセス、コンテンツ生成があった順（イベントリスト）が出来る必要。＃イベント/コンテンツユーザリスト表示モードセット＃コンテント状態制御

2-5-1：表示中コンテントリスト（図３２参照）
括り付け
ペルソナID
必須の画面要素
１）表示中コンテントリスト（図３２参照）
コンテント名
イベント名
生成時間
２）全画面共通ナヴィ
３）ペルソナ系共通ナヴィ
参加中（未開始、開始後）のアクティブなコンテンツのリスト生成表示。
コンテンツ名をクリックするとイベントホームに遷移し、サブ画面の表示を該当コンテンツにする。

2-5-2：待機中コンテントリスト（図３２参照）
括り付け
ペルソナID
必須の画面要素
１）待機中コンテントリスト（図３２参照）
コンテント名
イベント名
生成時間
２）一括表示中ボタン
３）全画面共通ナヴィ
４）ペルソナ系共通ナヴィ
a)ペルソナのすべての参加イベント（未開始、開始後）の待機中コンテントのリスト。
コンテンツ名をクリックするとそのコンテンツは表示中に変更になりイベントホームに遷移し、サブ画面の表示を該当コンテンツにする。
ｂ）一括表示中ボタンはクリックするとリストが全て表示中に変更。

2-5-3：参加中イベントリスト
括り付け
ペルソナID
必須の画面要素
１）参加中イベントリスト
イベント名
エントリィ時間
２）全画面共通ナヴィ
３）ペルソナ系共通ナヴィ
ペルソナの参加中のイベント（未開始、開始後）のリスト。
コンテント名をクリックすると該当イベントのイベントホームに遷移。

2-5-4：招待中イベントリスト
括り付け
ペルソナID
必須の画面要素
１）招待中イベントリスト
イベント名
エントリィ時間
２）全画面共通ナヴィ
３）ペルソナ系共通ナヴィ
ペルソナの招待中のイベントのリスト。範囲は2-3-2参照。
コンテント名をクリックすると該当イベントのイベントホームに遷移。

2-5-5：イベントログリスト＃ログコンテンツ表示
括り付け
ペルソナID
必須の画面要素
１）参加終了イベントリスト
イベント名
エントリィ時間
２）全画面共通ナヴィ
３）ペルソナ系共通ナヴィ
ペルソナの参加終了イベントのリスト。各項は参加終了イベントホームとリンク。

2-5-6：参加イベント表示中コンテンツ
括り付け
ペルソナID
イベントID
必須の画面要素
1) 参加イベント表示中コンテンツリスト
コンテント名
イベント名
生成時間
2) 全画面共通ナヴィ
3) 開始後イベント共通ナヴィ
参加イベントの表示中のコンテンツのリスト。
クリックするとコンテンツのフル表示に遷移。

2-5-7：参加イベント待機コンテンツ
括り付け
ペルソナID
イベントID
必須の画面要素
1)参加イベント待機コンテンツリスト
コンテント名
イベント名
生成時間
2) 一括表示中ボタン
3)全画面共通ナヴィ
4)開始後イベント共通ナヴィ
参加イベントの待機中のコンテンツのリスト。
クリックすると表示中に変わりコンテンツのフル表示に遷移。
ソートはホットコンテンツと同様（表示中は除外）
一括表示中ボタンはクリックするとリストが全て表示中に変更。

2-5-8：参加イベントコンテンツログ＃ログコンテンツ表示
括り付け
ペルソナID
イベントID
必須の画面要素
1)参加イベントコンテンツログリスト
コンテント名
イベント名
生成時間
2)全画面共通ナヴィ
3)開始後イベント共通ナヴィ
参加イベントの終了状態のコンテントのリスト
クリックすると参加イベントホームのログモードに遷移し、該当コンテンツの表示を行う。

2-6：トリガチェッカーとローカルエントリ
2-6-1：トリガチェッカーエントリィ
括り付け
ペルソナＩＤ
必須の画面要素
1) 識別二次元バーコード＃二次元バーコードページ生成
2) 全画面共通ナヴィ
3) トリガチェッカー共通ナヴィ
a)１）の識別二次元バーコードは2-11：識別二次元バーコードで記述された二次元バーコードを表示させる。このコードはユーザ（ペルソナ）に対してユニークでローカルエントリィ専用と注意書きを。

2-6-2：参加可能ローカルエントリィ
括り付け
ペルソナＩＤ
必須の画面要素
1) 参加可能ローカルエントィリスト
ローカルエントリィ名
イベント名
距離
2)リスト化距離入力フォーム
3)全画面共通ナヴィ
4)トリガチェッカー共通ナヴィ
a)付近のユーザ側トリガ（2-10参照）より2)のリスト化距離以内のローカルエントリィについて抽出表示。
b)リスト化距離入力フォームについてはプルダウンの選択式（100ｍ/300ｍ/500ｍ/1km/10km）＃場所トリガ取得表示

2-6-3：トリガマップ
括り付け
ペルソナＩＤ
必須の画面要素
1) トリガマップ
2) 種別選択フォーム
3) 全画面共通ナヴィ
4) トリガチェッカー共通ナヴィ
a) 付近のユーザ側トリガ（2-10参照）をマップ上にドロップして表示。インフォームではイベント名と種別（ローカルエントリィ、場所トリガ）のみが分かる。
b) 種別選択フォームでは表示する場所トリガの種類を限定できる。
ローカルエントリィ
開始後イベント（参加中）＃場所トリガ取得表示

2-6-4：ローカルエントリィ
図４を参照する。
ローカルエントリィプロセス
1) 非休眠中の端末が場所トリガあるいはローカルな二次元バーコード、アプリ連携などの手段によってローカルエントリィの存在を感知する。
2) 端末のペルソナ、メインパルソナのセッション開始。
3) 該当イベントに参加ユーザなら直ちにエントリィ、そうでないならローカルエントリィに関連付けられた記事（イベント説明ページ）を表示。説明Ｐ表示にローカルエントリィである旨の表示を。＃ローカルエントリィプロセス

2-7：タグについて
タグは図８にあるような構造を持つ。
公式タグは属性値を持つ公式重要タグを含み、公式重要タグの一部はグループ化されてグループラベルとタグの値を持つ。これを択一的公式タグと呼ぶ。
択一的公式タググループの一例
グループラベル：永遠の年齢
タグ タグ値（型）
0〜
永遠の22歳 22（数値）
永遠の23歳 23（数値）
永遠の24歳 24（数値）
〜90まで
通常の公式重要タグは属性に転換される場合真偽値を取る。
択一的公式タグはグループラベルを属性名、タグ値を属性値とする。
削除されたタグの属性は自動的に削除される。＃タグ-属性転換機構

2-8：保存属性について＃保存属性管理
2-8-1:属性と保存属性
図８を参照する。属性はイベントを駆動する為に管理者側がシナリオ上で設定し運用するものである。一方、そこで発生した何らかの成果をユーザ側、或いは提供者側が単一のイベントを超えて保持成長させたいと考える場合もある。またユーザ側の情報を管理者側がシナリオ中で利用したいと考える場合もある。
この価値の相互運用を実現する為に管理者側、ユーザ側にそれぞれ管理権のある保存属性を設定管理出来るようにした。この管理の為に管理者側は3-4-4登録推奨保存属性管理、ユーザ側は2-2-6属性ホルダを利用出来る。管理者側がシナリオで利用する為には利用可能な保存属性をインポート属性の参照先として指定し参加者タイプ（図３４参照）の属性条件として指定する必要がある。
保存属性のプロパティ
1)属性名
2)属性値
3)属性種別
4)属性値タイプ
5)ユーザ編集可能性
6)公開設定
7)ユーザ削除可能性
8)インポート時編集可能性
a)詳説
1)属性名：属性情報より
2)属性値：属性情報より。ユーザ編集可能な場合がある。
3)属性種別：図８属性種別参照。公式属性、タグ関連属性、保存推奨属性の三種があり、保存推奨属性には管理者IDが紐づけられている。
4)属性値タイプ：属性情報より
5)ユーザ編集可能性：属性値をユーザが編集可能かどうか？保存推奨属性のみ（他についてもアカウント編集、タグ操作を通じて間接的に行う事は可能）属性値がフォーム内に記載されている属性はユーザが編集可能な属性で記入かプルダウンで選択できる。（参加シナリオ内で属性インポートされている場合、参加中は編集不能）
6)公開設定：保存属性を管理者がインポート属性として利用できるか？の設定。公開、公開選択可、非公開の三種。保存推奨属性は管理者側が設定。公開選択可は属性ホルダ上でユーザが指定できる。保存推奨属性の管理者はこの設定に関わらず自己提供の属性を操作できる。
7)ユーザ削除可能性：ユーザが属性ホルダ上で属性を削除できるか？保存推奨属性は全て該当する。
8)インポート時編集可能性：公開（承認済み）設定の保存推奨属性のみ有効。属性登録時（図３３参照）の同期属性として設定可能かどうか？公式、タグ関連属性は参照のみ。
同期は図１属性登録の時点で行われる。

2-8-2:公式属性
ユーザのアカウント情報由来の属性。属性値としては編集不能であり公開選択可となる。性別（文字列選択）、実年齢（数値）の二つが該当。また登録端末にアプリをダウンロードしたユーザは「アプリユーザ」属性（真偽）を得る。

2-8-3:タグ関連属性＃タグ-属性転換機構
タグ由来の属性。2-7（図８）で詳述されたプロセスによって属性として自動的に登録削除される。全て公開かつ編集不能となる。

2-8-4:保存推奨属性＃保存属性管理＃インポート可能属性リスト
保存推奨属性は管理者側が管理権を持つ保存属性で管理権のある管理者IDが紐付いている。保存推奨属性の定義、管理は3-4-4登録推奨保存属性管理ページで行われる。
登録利用プロセス
1)管理権のある管理者側登録手続き
図１４登録推奨属性新規登録プロセス参照
1-1) 新規登録ボタンをクリック
1-2) 属性登録フォームを呼び出す。図３３参照。
1-3) 保存設定フォーム呼び出し。
1-4) フォームからユーザ編集可能性設定
1-5) フォームから公開設定およびインポート時編集可能性を合成リストより設定
1-6) 公開（承認）同期の場合、付与を許容するか？（初期値設定）、
1-7) 公開（承認）同期の場合、相手イベントでの属性値の変更可能範囲の設定を行う事が出来る。文字列選択、数値の属性値タイプに限る。図を参照。
1-8) 登録推奨保存属性管理ページに該当属性が登録される。
2)インポート側管理者側の利用手続き
図３３参照 求めるインポート元保存属性を図３３インポート可能属性リストから検索。もし公開同期ならプロセスに進む。
承認同期なら承認チェックをクリックする。相手先承認（否認）が得られるとメールが入る。それ以降リストを確認すると承認済みとなっていて公開と同じ扱いになる。否認された場合は否認済みとなりその管理者ユーザはその属性を利用できない。
保存属性として保管され得るのは公開（承認済み）同期（もしくは自己属性）に限るのでそのプロセスのみ抽出。＃参加者タイプ（図３４参照）決定プロセス
2-1)新属性登録時、保存推奨属性にチェック
2-2)参加者タイプ（図３４参照）設定でインポート元保存属性が必須の属性条件に入っているか？（NOT/OR条件で無く全ての条件分岐でAND条件）属性に入っているなら入っているなら次の処理へ。
2-3）入って居ない場合その参加者タイプ（図３４参照）で該当属性がアクティブな場合、インポート元属性の付与許容設定が許可になっているなら次の処理へそうで無いならチェックは警告文と共に外れる。
2-4）全ての参加者タイプ（図３４参照）で2-2〜2-3の処理をして保存属性チェックが残って居れば保存属性として登録。（属性条件、アクティブ設定が変更になったら2-2〜2-3処理を）
3)イベント終了時の属性登録処理（図１参照）
3-1)参加ユーザで保存推奨属性がアクティブなユーザを抽出する。各属性に次からの処理。各ステップの条件を満たしていないなら処理は停止して次の属性に。
3-2）属性は保存推奨属性として条件を満たしているか？公開同期か認証公開同期且つ承認先であるのかなど
3-3) 自己属性でもなく付与許可が無いインポート元属性なのに付与されているか？
3-4)属性値の変更の範囲が上ステップ1-7)での授権の範囲にとどまっているか？
3-5)各保存推奨属性について3-2〜3-4のステップが終了したならチェックを通った属性をリスト化する。
3-6)属性リストをユーザの参加終了イベントホームに保存推奨属性登録画面の形で配信してチェックを付けて貰う。
3-7)上項でチェックされた保存推奨属性はユーザの属性ホルダに追加される。

2-9：メール配信＃メール配信
2-9-1:コンテント配信
各イベントでコンテンツが生成された時に2-2-4：ペルソナ管理の端末メールアドレスにログ形式（3-3-1-8：ログ）のコンテンツがｈｔｍｌ形式で配信される。ユーザがその画面をクリックするか最初のアクションを起こすと該当コンテンツのサブ画面表示をブラウザで呼出し表示する。

2-9-2：告知配信
3-4-6-1:告知メール配信参照。

2-9-3：警告配信
システム側より何らかの警告がなされる時は定型的な自動発信メールが送られる。

2-9-4：プッシュ連動
アプリDL端末にメール配信が為される時は同時にプッシュ通信がなされる。
利用するサービスに合わせた仕様で行う。mBaaSなど。

2-10:トリガ(ユーザ側) ＃場所トリガ取得表示
トリガはイベント全体を駆動する為の“イベント”を指すが、ユーザ側に取っては参加中のイベントにおいて現在受け取り可能なフィールドゾーンと関連付けられたトリガを指す。これを仮に場所トリガと呼ぶ。
フィールドインアウトに関連付けされた最終的に例外管理に遷移しないアクティブなタイムゾーンのコンテンツに遷移矢が発するフィールドゾーンが場所トリガの定義となる(属性による制限も明示的なものは考慮する)。例外遷移する例外場所トリガも定義しておく。

2-11：識別二次元バーコード＃二次元バーコードページ生成
ユーザはサブ画面の特殊記事、あるいはトリガチェッカーエントリィ、ユーザチェック二次元バーコード発行モジュールにおいてユーザの端末の識別を行う端末とシナリオ上のコンテキストに対してユニークな二次元バーコードを生成して表示させる事が出来る。
これを管理者側の二次元バーコードリーダ或いはユーザアプリの読み取り機能に識別させる事によってトリガを発生させる事が出来る。トリガの識別は3-3-4-3-1:外部トリガ記述モジュールで管理者側の二次元バーコードを登録して行う。
アプリの無いユーザ同士のコンタクトの為イベント中有効な入力コードと入力フォームも同時に表示する。

2-12：ユーザチェック＃二次元バーコードページ生成
ユーザはページに表示される二次元バーコードあるいは上記入力コード利用によって管理者側の機器あるいはユーザ同士で接触情報を発信する事が出来る。これをユーザチェックと呼ぶ。

2-13:終了マージン＃終了マージン
例外終了マージン及びゾーンアウトマージンが適用された時はメッセージが警告配信（2-9-2）される。カウントダウンをユーザ側がゆるす設定になっている時は一定時間ごとにカウントダウンが警告配信される。

３：管理者画面
3-1：画面遷移
新規登録は3-6新規登録項に。認証を持つ管理者ユーザの画面遷移を記述。
画面はヘッダーに来るメインナヴィ、縦に伸びるサブナヴィ、内容を表示するメインブロックに分れる。図１０参照。
メインナヴィの内容は全画面共通でメインナヴィの選択に従ってサブナヴィの遷移リストが変更される。
・メインナヴィより
シナリオ作成（図４９参照）
シナリオ管理
イベントモニタ（図１１参照）
アカウント
ログアウト
・アカウントより
サブナヴィは存在しない。
グレードアップなど契約更改ページ
支払ページ
問い合わせ
利用できる既存のAPIが有れば積極的に利用
・ようこそページ
・シナリオ作成（図４９参照）系
サブナヴィより
ようこそページ
シナリオ選択後（プルダウンでシナリオリストと新規作成）
シナリオ
シナリオチャート
記事作成（図２０参照）
モジュール作成
コンテンツリスト
参加者属性管理（図３３参照）
・シナリオ
新記事作成（特殊記事）
参加者属性管理（図３３参照）（登録ずみ）
モジュール化（データコンヴァート）＃シナリオ遷移制御
概形チェック（遷移）＃概形チェック
実施可能シナリオ（データコンヴァート）＃シナリオ遷移制御
・シナリオチャート
ユーティリティバーより
新計算モジュール
新記事
新モジュール
新シナリオ属性
シナリオ属性管理＃コンテンツリスト（切り出し）
プライベートライブラリ（シナリオID）＃ライブラリ遷移
標準化ライブラリ（シナリオID）＃ライブラリ遷移
・記事作成（図２０参照）
記事リスト画面＃コンテンツリスト（切り出し）
新規制作
作成中記事
ユーティリティバーより
プレヴュー＃記事記述-ユーザイメージ転換
プライベートライブラリ（シナリオID,記事ID）＃ライブラリ遷移
標準化ライブラリ（シナリオID,記事ID）＃ライブラリ遷移
モジュール編集画面（フィルアップ）＃クラス/テンプレート
モジュール編集画面（定義変更）＃コンテンツリスト（切り出し）
コンテントリスト（図３２参照）（モジュール）
シナリオ
・モジュール作成
モジュールリスト画面＃コンテンツリスト（切り出し）
新規制作
作成中モジュール
ユーティリティバーより
新計算モジュール
新記事
新モジュール
新シナリオ属性
シナリオ属性管理
フィルアップ＃クラス/テンプレート
定義モジュール変更＃定義/スコープ
プライベートライブラリ（シナリオID）＃ライブラリ遷移
標準化ライブラリ（シナリオID）＃ライブラリ遷移
・コンテンツリスト＃コンテンツリスト（切り出し）
コンテンツ表示
属性表示
サブ要素表示
階層化表示
各コンテンツ編集画面（記事ID）
・参加者属性管理（図３３参照）
新属性登録フォームより
インポート可能属性リスト＃インポート可能属性リスト
参加者タイプ（図３４参照）
属性チャート呼出＃シナリオ/計算チャート
・シナリオ管理系
サブナヴィより
ようこそページ
実施可能シナリオ
参加者管理
登録推奨属性管理＃保存属性管理
プライベートライブラリ＃ライブラリ遷移
外部標準化ライブラリ＃ライブラリ遷移
告知メール配信＃メール配信
二次元バーコード生成
・実施可能シナリオ
各シナリオ作成（図４９参照）画面
・参加者管理
参加者属性閲覧画面＃保存属性管理
招待イベントリスト＃参照可能ユーザ確定プロセス
・登録推奨属性管理＃保存属性管理
属性詳細インフォーム
属性登録フォーム呼出
・プライベートライブラリ＃ライブラリ遷移
・外部標準化ライブラリ＃ライブラリ遷移
・告知メール配信
・二次元バーコード生成
・イベントモニタ（図１１参照）系
サブナヴィより
ようこそページ
シナリオ選択後（実行中イベントのリスト）
チャートモニタ（図１５参照）＃チャートモニタ
管理者トリガ管理（図１６参照）＃遷移制御
例外モジュールモニタ（図１６参照）
・チャートモニタ（図１５参照）
属性値のリスト＃イベントアクティビティ
参加者リスト＃ログ管理
上位チャートモニタ
コンテンツプロパティ画面（コンテンツID）＃イベントアクティビティ
・管理者トリガ管理（図１６参照）
モジュールのチャートモニタ＃チャートモニタ
・例外モジュールモニタ（図１６参照）
モジュールプロパティ（モジュールID）＃イベントアクティビティ
アクティブティ（モジュールID）＃イベントアクティビティ
管理者コール（モジュールID）
ユーザログ表示（ユーザID）＃ログ管理
モジュールプロパティ（モジュールID ）＃イベントアクティビティ
アクティブティ（モジュールID）＃イベントアクティビティ
チャートモニタ（ユーザID）＃チャートモニタ
緊急通話＃緊急処理
アクティブティ（モジュールID）＃イベントアクティビティ

3-2：メインパート/管理系画面
3-2-1：ログイン/ログアウト＃ログイン/ログアウト
括り付け
なし
必須の画面要素
１）認証メールアドレスとパスワードの入力フォーム＃認証メールによる真実性確認
２）新規登録ページへのリンク（説明文と共に）
１）への入力がアカウントとマッチしたならログインセッション開始。マッチしないなら画面上に警告アラート挿入し回帰。

3-2-2：新規登録
3-6新規登録参照

3-2-3：アカウント
括り付け
管理者ID
必須の画面要素
１） 認証メールアドレス表示
２） 管理者情報（イニシャル登録時は画面上で変更可能）
３） アカウントグレード情報
４） パスワード変更入力フォーム＃フォーム入力検証
５） 課金情報 （イニシャル登録時は不要）
６） ディレクターネーム表示編集フォーム
７） ディレクタータグ表示編集フォーム＃フォーム入力検証
８） ディレクタ紹介文表示編集フォーム
９） ディレクターログ表示ボタン＃ログ管理
１０） グレードアップサイトへのリンク
１１） 問い合わせフォーム

3-2-4：ようこそページ
括り付け
管理者ID
必須の画面要素
なし
a)グリーティングページ。具体的にシナリオ作成（図４９参照）がなされていない時のメインページ。チュートリアルなどへのリンクがあってもよい。

3-3：メインパート/シナリオ作成（図４９参照）
3-3-1：概念説明
シナリオを作成して実施可能シナリオとして登録するまでのプロセスを行う部分。3-3-1-1：チャート＃シナリオ/計算チャート
チャートは3-3-3：シナリオチャート、3-3-4-1：ネストタイプモジュール、3-3-3-6：計算モジュール3-3-1-6：タイミング設定、3-3-6-2：参加者タイプ（図３４参照）で利用されるグラフィカルなイベント参加者の携帯端末および関連機器への記事配信および外部連携サービス提供の制御、および内部のオブジェクトの挙動制御を行う仕組みである。
完成されたチャートはコンテントが遷移矢で結ばれ制御用のオブジェクト（記述子、ゾーン、属性）のアイコンで遷移矢が中継されたりまた区分されたりするフローチャート状を呈する。
コンテンツ、記述子の関係を遷移矢およびタイムゾーン（3-3-1-4-1）による区分関係、画面上の位置を利用して解析する事によって挙動制御情報を抽出する。
チャートはコンテンツの状態遷移を管理するシナリオ（モジュール）チャートと属性計算と条件分岐を定義する計算チャート（ヴァリエーションでタイミング設定チャート、属性条件チャートがある）の二種類（五種類）があり使えるオブジェクトも一部異なる。
五つのチャートは同一の（合成した）機能で出現するパレットのみが異なるようにしたい(シナリオ系と計算系の配置可能アイコンの差は計算ゾーンで区分されていると見做す。またモジュールの機能の違いによる配置後の解釈の違いは残る)。
チャートは利用される画面によって幾つかに分かれ出現するパレットの種類が異なる。
シナリオチャート：シナリオチャート（3-3-3-2：チャートエリア）
モジュールチャート：ネストタイプモジュール（3-3-4-1：ネストタイプモジュール）
計算チャート：計算サブモジュール（3-3-3-7：計算サブモジュール）
タイミング設定チャート：タイミング設定（3-3-1-6：タイミング設定）
属性条件チャート：参加者タイプ（図３４参照）編集（3-3-6-2：参加者タイプ（図３４参照））、メンバ制約部
何もアイコンの置かれて居ないチャート表面をチャートフィールドと呼び、タイムゾーンに包含されて居ないチャートフィールドをプレーンチャートフィールドと呼ぶ。

3-3-1-1-1：チャート操作＃シナリオ/計算チャート
使用する動作はクリックとダブルクリック、ドラッグアンドドロップ（DD）の三つの動作となる。
チャートフィールド上のアイコンのモード：クリックで選択されたアイコンもしくは部位は強調表示される。以下の操作は全て選択された部位もしくはアイコンに対する操作となる。
マウスポイントのモード：パレット上で遷移矢のみはダブルクリックするとマウスポイントが該当する種類の遷移矢に似た形状になり特別な挙動をする。これは再び遷移矢をクリック、ダブルクリックすると解除される。

3-3-1-1-1-1：パレットアイコンドラッグ＃パレット
3-3-1-1-1-1-1：チャートフィールドへの配置
パレット上のアイコンをDDするとアイコンのシルエットがマウスポイントと共に移動する。チャートフィールド上の空部位に展開後のアイコンが配置可能（3-3-1-1-1-5：動作制限動作制限参照）だとアイコン表示に変わる。その位置でドロップするとアイコンがフィールド上での設定された姿でその位置で表示される。

3-3-1-1-1-1-2：アイコン上、アイコン部位への配置
DDされたアイコンが他のアイコン上で配置可能な位置にくると枠線が強調色に変化する。その位置でドロップすると該当するアイコン部位に配置された姿に相手アイコンが変化する。結合されたアイコン、或いは部位をダブルクリックすると配置が解除され、分離したアイコンが表示される。フィールド上に表示不能なアイコンは消滅する。
フィールドゾーンはFZアイコン上のDDエリアをDDする事によって他アイコン上に配置できる。

3-3-1-1-1-2： ゾーンの配置＃マウスポインタモード
コンテンツと同様であるが処理パレットのアイコンをチャートフィールド上に配置いてプロパティを決定する。

3-3-1-1-1-3：アイコンの画面内の移動とアイコンの変形＃マウスポインタモード
チャートフィールド上の選択されたアイコンは遷移矢と配置アイコンとの関係を保ったままDDで移動させる事が出来る。その他の制限は3-3-1-1-1-1-1：チャートフィールドへの配置と同じ。

3-3-1-1-1-4：遷移矢の結合操作＃マウスポインタモード
チャートフィールドへの配置によってチャート上に現れた遷移矢は両端の部位が選択されうる。選択された端はDDによって3-3-1-1-1-1-2：アイコン上、アイコン部位への配置と同様に結合可能な部位（起点：ステイタストリガ/終点：ステイタスレセプタ）に一端が固定される。解除もダブルクリックで可能。両端が結合された遷移矢は強調表示される。
マウスポイントが特定の遷移矢に変化した場合、起点がステイタストリガをクリックすると起点を固定され先端をポイントに追従する遷移矢が出現する。その状態で終点がステイタスレセプタをクリックすると結合される。またモード指定で遷移矢をダブルクリックするとその遷移矢は消滅する。

3-3-1-1-1-5：アイコン詳細動作（クリック）
選択したアイコン、アイコン部位をクリックすると詳細情報もしくはアイコン単独の動作に関するメニューが出現する（設定があれば）。
アイコンの削除はこちらから行う。

3-3-1-1-1-6：動作制限＃概形チェック
遷移矢を除くアイコンは他のアイコンと重なって配置する事が出来ない。
またフィールドゾーンはプレーンのフィールドにしか配置できない。
計算ゾーンに配置可能なアイコン制限と拡大。
完成時のチャート：以下の要件を満たす必要。＃遷移制御
１：チャート上の遷移矢は全てステイタストリガとステイタスレセプタを結んでいなくてはならない。
２：全てのターミナルステイタスは遷移矢か終末アイコンで遷移先が決まっていなくてはならない。（付随ステイタストリガは全て遷移する必要はない）
３：全てのタイムゾーンのタイムインレセプタはtriggerが生きているならトリガもしくは外部トリガと連結されている必要がある。またそうでないならタイミング設定で時刻指定されていなくてはならない。＃タイミング設定

3-3-1-1-1-7：部位
１） メンバ制約部：ある処理が行われる条件をアイコンの一部に設置する事が出来るアイコンが存在する。＃メンバ制約
メンバ制約部には
属性配置
属性パターンフィルタ
属性条件チャートを持つ条件モジュール
が配置可能。
これらを使用してドロップ、結合すれば範囲を更に制約。
２） 判定値配置部
此処には数値型属性値の属性が配置可能。計算チャートでは代入遷移矢の代入先にもなる。また数値入力フォームで直接値を入れる事も可能。
３）条件属性部:ここにはあらゆる属性が配置可能。計算チャートでは代入遷移矢の代入先にもなる。また入力フォームで直接値を入れる事も可能。
４) 属性パターン配置部
ここにはあらゆる属性が複数配置可能。

3-3-1-1-2：解釈と解析＃チャート解釈
3-3-1-1-2-1：解釈される情報
完成したチャート図において解釈上意味のある情報は次の通りである。
１：タイムゾーンの構造
２：チャートに配置されたフィールドゾーン情報
３：コンテンツおよび記述子のタイムゾーンに対しての包含関係
４： コンテンツおよび記述子の他のアイコンへの部位配置情報
５：遷移矢の結合関係（アイコンおよびアイコン部位）

3-3-1-1-2-2：解析構造体
3-3-1-1-2-1：解釈される情報に従って次の手順で解析構造体を生成する（htmlの生成情報から抽出）。
１：タイムゾーンの入れ子関係を解析してプレーンのフィールドを最上位TZとして構造化する。（プロパティ情報と共に）
２：フィールドゾーンを最上位の要素として追加
３：それぞれのTZに包含されたコンテンツおよび記述子を構造体の該当位置に要素としてリスト化。（プロパティ情報と共に）
４：部位配置されたアイコンを各要素（プロパティ）の子要素として追加
５：遷移情報をプロパティと指示情報として追加（双方向）
これはチャート＝モジュールに固有の構造体となる。
以上によってチャートの解釈はマークアップ言語によるプログラミングと同等に成る。
上記の作業は配置、結合、分離動作と共に行われるのが制限動作の警告および将来的なガイド情報の提示の為にのぞましい。

3-3-1-2：コンテント
複数集合概念でコンテンツ。
コンテントはユーザが実際に携帯端末で利用するサービス（および下位モジュール）をシナリオ上で表現したものになる。コンテントのアイコンは遷移矢を受けてターミナルステイタス、付属フィールドゾーン、或いはシステムステイタスが表現された付属のアイコンで挙動情報をステイタスの形で発する。内部に入力フォームが有った場合は参加者属性に変更が加えられる場合もある。これはコンテンツリストの使用属性で確認できる。＃遷移制御
コンテントは記事とモジュールに大別される。
記事はメッセージと（状態有）記事に分けられる。
モジュールは通常モジュールと例外管理の軸とネストタイプモジュールと外部モジュールの軸によって四区分される。
コンテントはメンバ制約部があり生成出来る属性条件を設定出来る。＃メンバ制約

3-3-1-2-1：定義、編集と操作
全てチャート上に配置されるコンテントはコンテンツパレットと呼ばれるアイコンのコンテナに表示される（新規のブランクのアイコンも）。そのアイコンをチャート上或いは記事編集画面にドラッグ等によって配置して使用する。＃パレット
コンテントの定義について新規についてはサブナヴィ、あるいは新規アイコンクリック、既存のコンテンツの編集に関してはチャート上、パレット上、コンテントリスト（図３２参照）上のアイコンクリックで編集画面を呼び出して行う。
編集画面について記事は3-3-5-4：記述画面、モジュールは3-3-4-1：ネストタイプモジュールで内容が定義される。また外部モジュールはテンプレート（次項）として呼び出される。＃定義/スコープ
パレット上のアイコンとチャート上のアイコンの関係はクラスとまったく同様の内容を持つ子クラスの関係となり、基本的にはどこで編集して内容を変更してもその変更は他のすべてに反映される。ただしコピーとして編集とすると別のアイコンがパレット上に出現し別クラスとなる。なお、アイコンに他のアイコンをドロップする操作は編集には当たらない。＃クラス/テンプレート
スコープ：新規作成が呼び出されたモジュールが定義モジュールとなるが、編集画面の定義モジュールの変更を利用して変更する事が可能である。上位の階層で定義し直してスコープを拡大するのは容易であるが階層を下げたりスコープ外で定義し直すとスコープから外れた配置コンテンツはそれぞれ独立したコピーコンテンツになってしまう。
スコープの範囲は1-4-1の説明の通り。＃定義/スコープ

そのモジュールが定義モジュールのコンテンツはコンテンツパレット上で反転して示される。＃定義/スコープ

3-3-1-2-1-1：テンプレートとフィルアップ＃クラス/テンプレート
図５及び1-4-1項参照。通常の編集では少しでも内容を変更した場合は別クラスとしてコピーしなければ影響がすべてに及ぶ。しかし指定可能な種類の内部のアイコンを可変アイコンとして指定すればテンプレートとしてそのコンテントは機能し可変部以外への変更は全体に及ぶが可変部分の変更はフィルアップ内にとどまる。
1:可変アイコンを含むコンテンツはテンプレートとしてコンテンツパレット上でスコープ内のテンプレートエリアに表示される。
2:編集画面内のフィルアップを選択するとそのモジュール内のコンテンツパレットの通常エリアにフィルアップが表示されるようになり編集画面はそちらのものに遷移する。
3:編集中のフィルアップ(可変アイコンが残っている)はフィルアップとして弱色表示されチャート上に配置することが出来ない。
4:アイコンのフィルアップは以下の手順で行われる。
4-1:可変アイコンの外形仕様を満たすコンテンツ或いは属性を探す、或いは作成する。
外形仕様とはコンテンツの種別、遷移矢の発する或いは帰着するステイタスの種類、使用属性のパターンと種別、型、属性の種別、型である。全体処理属性のメンバー情報は保証されない。（ターミナルがドロップされているステイタスは除外される）
4-2:該当するアイコンを可変アイコン上にドロップする。外形チェックが行われ通れば置換される。この場合、遷移矢は一旦外れる。
4-3:外れた遷移矢を適切な部位に再連結する。
5:全ての可変アイコンが置換されたらテンプレートを持つコンテンツの型としてチャート上に配置出来るようになる。
記事の可変アイコンは属性のみ指定できる。
モジュールの可変アイコンはコンテンツ、ワイルドカード及び属性となる。
同一のコンテンツ、属性が複数配置されている場合、一か所を指定すると全てが指定され一か所を置換すると全てが置換される。この場合の外形仕様は（特に遷移矢の排出すステイタスは）合成される。

3-3-1-2-1-2：コンテントの状態＃コンテント状態制御
コンテントの状態として2-4：コンテンツでは
アクティブ
待機
終了
の三モードがあると記述したがシナリオ記述の為にイベントの進行を管理する為にはもう少し複雑となる。
図１７に記事の状態表があるがこれと同様にコンテンツ全体にこの状態がある。
状態管理においてコンテントは高度管理指定を行う事が出来る。
高度管理指定コンテント：高度管理を行うコンテントは拘束選択ターミナルステイタスが発行されない限りタイムアウトを発生させ例外終了となる。
記事およびネストモジュールで高度管理指定を行うと選択拘束ボックスが呼び出し可能となり、その中にステイタスエミッタを配置できるようになる。このステイタスエミッタの何れかが踏まれないと最終的にタイムアウトが発生し例外処理扱いになる。

・通常コンテントの状態
正規処理済みコンテント
正規終了（終了）
正規ステイタス発行済みアクティブ（アクティブ）
不正規処理コンテント
不正規終了（終了）
正規ステイタス未発行アクティブ（アクティブ）
待機（待機）

正規ステイタス未発行アクティブと待機は所属タイムゾーンのタイムアウトトリガが発生すると不正規終了となる。

・高度管理指定コンテントの状態
正規処理済みコンテント
選択拘束正規終了（終了）
選択拘束正規ステイタス発行済みアクティブ（アクティブ）
不正規処理コンテント
選択拘束不正規終了（終了）
選択拘束不正規ステイタス発行済みアクティブ（アクティブ）
例外処理コンテント
例外終了（終了）
選択拘束ステイタス未発行アクティブ（アクティブ）
待機（待機）/記事と外部モジュールサービス画面のみ
選択拘束ステイタス未発行アクティブと待機（待機）はタイムアウトトリガが発生するとタイムアウトを発生させ例外終了となる。
タイムアウト前に例外処理コンテントあるいはタイムゾーンが存在するとタイムアウトまでTZは閉鎖できない。
外部モジュールに置いてはモジュールの仕様として要請する。
ネストタイプモジュールにおいて
通常指定では内部で例外処理が発生しても例外終了とならない。高度管理指定では例外終了が発生し得る。
ネストタイプモジュールにおいては内部遷移と外部のTZや上位モジュールの終了イベント双方によって状態が規定される。
・通常指定
正規終了：正規処理ステイタスエミッタの何れかが踏まれて未帰着の遷移矢が存在せず呼び出しコンテンツが全て正規処理されたなら持続設定の無いモジュールは閉じ、正規終了ステイタスが発行される。持続設定があるならタイムアウトトリガ発生後正規終了。
正規ステイタス発行済みアクティブ：正規ステイタスがそのモジュールからはっせられた場合。タイムアウトトリガが発生すると正規終了に。
不正規終了：全ての未帰着の遷移矢が存在せず呼び出しコンテンツ、TZが全て終了したなら持続設定の無いモジュールは閉じ、不正規終了ステイタスが発行される。持続設定があるならタイムアウトトリガ発生後不正規終了。
強制終了レセプタが踏まれたなら持続設定の有無にかかわらず終了。
正規ステイタス未発行アクティブ：生成されて上記以外の状態。タイムアウトトリガ或いは外部要因での強制終了が発生すると不正規終了に。
待機：待機状態は存在しない。
・高度管理指定
選択拘束正規終了：選択拘束正規処理ステイタスエミッタの何れかが踏まれて未帰着の遷移矢が存在せず呼び出しコンテンツが全て正規処理されたなら持続設定の無いモジュールは閉じ、正規終了ステイタスが発行される。
選択拘束正規ステイタス発行済みアクティブ：選択拘束正規処理ステイタスエミッタの何れかが踏まれてその時点で例外処理コンテンツ、TZが存在しない場合。
選択拘束不正規終了：選択拘束不正規処理ステイタスエミッタの何れかが踏まれて未帰着の遷移矢が存在せず呼び出しコンテンツが全て正規処理或いは不正規処理されたなら持続設定の無いモジュールは閉じ、不正規終了ステイタスが発行される。持続設定があるなら強制終了トリガ発生後正規終了。
選択拘束不正規ステイタス発行済みアクティブ：選択拘束不正規処理ステイタスエミッタの何れかが踏まれてその時点で例外処理コンテンツ、TZが存在しない場合。
例外終了：上記以外で強制終了された場合。
選択拘束ステイタス未発行アクティブ：上記以外の強制終了されて居ない状態。タイムアウトトリガが発生するとタイムアウトを発生させ例外終了に。
待機：待機状態は存在しない。
記事においては図１７及び 3-3-5-2：記事状態遷移の通り。

3-3-1-2-1-3:コンテントでのデータ利用＃外部データ利用＃ライブラリ遷移
コンテントで画像や映像、設定情報など外部のデータを利用する場合、利用者のタイプによって利用方法が異なる。
管理者ユーザは認められた形式のデータをライブラリに登録する事によってライブラリデータパレットからコンテントや画面パーツのデータレセプタにドロップして利用する。
登録出来るデータ形式は対応するレセプタを持つコンテントや画面パーツのパレット記載によって可能となる。
ユーザはより限定された方法で可能となる。
ユーザに提供される記事の画面パーツや外部モジュールの指示に従って自己端末上のデータを該当オブジェクトにアップロードする。この時、データの形式及び生成タイミングが制限される事が多い。
タイミングはそのオブジェクトの生成期間内に作成されたもので有る事が推奨される。またタイミング設定チャートで詳細な設定を行えるよう呼び出しをオブジェクトに組み込む事も可能である。

3-3-1-2-2：記事とメッセージ
記事とメッセージは共に3-3-5：記事/メッセージで作成編集されるブログ形式のコンテンツである。機能としてイベント中に…
１：記事を参加者に読ませる
２：画像、映像を参加者に閲覧させる
３：フォームに入力させる
４：埋め込み画面パーツを利用させる
５：外部リンクを踏ませる
６：参加者に行動を選択させる
機能を担っている。
単に記事を閲覧させる機能からイベントの参加者の行動制御まで担って居る為3-3-5-2：記事状態遷移に説明されている通りの複数の状態情報を持つ。
これを作成者に明瞭にする為、状態情報が配信のみの記事をメッセージ、それ以外を記事としてアイコンも区別する。＃コンテント状態制御

3-3-1-2-3：通常モジュールと例外管理
モジュール（3-3-4：モジュールで詳説）はシナリオのイベント管理プロセスの一部を扱い易い様に別オブジェクトとして切り出したものである。内部挙動のいかんにかかわらずコンテントとしてのインターフェイスを持つ。これらのモジュールはシナリオとしてのインターフェイスを持つ最上位のモジュールの子要素と見做す事が出来る。ネストタイプのモジュールは更に子要素としてモジュールを持ちうるので階層化して扱われる。
このモジュールの構造関係はシナリオの構造として内部で把握されなくてはならない（スコープ）。＃遷移制御
例外管理は3-3-4-2：例外管理で詳述されるが3-5-3：例外モジュールモニタ（図１６参照）でイベント中は監視され、3-5-4：管理者コールを実現するアイコンを配置できる。このアイコンは外部モジュールとして扱われる。

3-3-1-2-4：ネストタイプモジュールと外部モジュール
モジュールは内部がシナリオチャートによって制御されるネストタイプモジュールとプロパティ画面で制御される外部モジュールに区分される。
ネストタイプについては3-3-4-1：ネストタイプモジュールで詳述されるがコンテントとしてのインターフェイスを得る為にターミナルステイタスエミッタをチャート上に配置する必要がある。階層化構造の一部となる。＃遷移制御＃定義/スコープ
外部モジュールは3-3-4-3：外部モジュール、3-7：外部連携で詳説されるがネストタイプでは実現できない機能を担う為に外部のアプリやサービス、計算資源を利用する為のものである。外部の情報を受ける外部トリガ記述モジュールや目的地へのガイドを行うガイドモジュールなどが有る。またデータ形式のライブラリのデータを受け入れ設定や事前のデータ入力を行う事も出来る。＃外部連携＃外部データ利用

3-3-1-2-5:例外終了マージン＃終了マージン
例外終了が発生した時に実際の適用をどの程度遅らせるかの設定。
それぞれの設定で時間を指定して決定するがモジュール、シナリオ単位で設定する事も可能。
ユーザに対しては検知時点でメッセージが発せられ、ホットコンテンツの最上位にリストされる。ネストモジュールの場合は待機及び表示中の正規処理されて居ない内部コンテンツのホットコンテンツのwtが一定値荷重される。

3-3-1-2-6：コンテントチャート上挙動個別説明＃遷移制御＃コンテント状態制御
コンテンツのアイコンはチャート上に配置されると幾つかの付随するアイコンを生成付属させる。また属性もしくはフィールドゾーンを部位配置として受け入れる。
ステイタストリガとしてプロパティに従って
正規ターミナルステイタス（正規）
不正規ターミナルステイタス（不正規）
終了状態ステイタス
発生ステイタス（トリガ）
遷移不生成ステイタスを付随させる。（例外/不正規）
この内終了状態ステイタスは使用に三つのモードで使用可能でありクリックすると
正規終了（正規）
不正規終了（不正規）
例外終了（例外）
のリストが現れ選択するとそのモードのアイコンが付随し、隣に未定義の終了状態ステイタスが出現する。三モード全て出現するとそれ以上増えない。
これらは内部挙動に従ってステイタスを発行しもし結合する遷移矢があればそれを評価する。終了状態ステイタスが発行されるとそのコンテンツは終了状態となる。
ステイタスレセプタとしてプロパティに従って
発生ステイタス
トリガレセプタ
を付随させる。
これらは結合された遷移矢が評価されると内部動作を駆動するイベントを発生させる。
発生ステイタスは評価されるとコンテンツのインスタンスを生成する。
トリガレセプタは内部の対応するトリガアイコンにステイタスを発行させる。
以上のステイタストリガおよびステイタスレセプタにはシナリオ属性アイコンを部位配置させることが出来る。配置された属性アイコンは配置時のモードに従って属性値を変化させる。3-3-1-3-5：属性チャート上挙動個別説明参照。
フィールドゾーンはアイコン本体に部位配置されると所属フィールドゾーンとなり小FZアイコンと遷移不生成アイコンとフィールドアウトアイコンを付随させる。3-3-1-4-2-1：所属フィールドゾーン参照
遷移不生成（例外）
フィールドアウト（例外）
設定
例外終了マージン設定：時間を設定。モジュール、シナリオのデフォルトが当初は記述。＃終了マージン
メンバ制約：メンバ制約部が左肩に存在。アイコンが配置されて条件が引っ掛かると遷移不生成が発行。＃メンバ制約

3-3-1-3：属性
属性はユーザの行動情報の記録制御および保持情報のシナリオ上での利用、グループ行動の制御の為に利用されるオブジェクトである。変数と似ているが名前空間は持たずスコープの意味は異なっている。また属性は必ずユーザ、もしくはモジュール（あるいはその双方）と括り付けられ属性値を持つ。
また大別して二種類に分かれる。シナリオ属性、参加者属性である。シナリオ属性は更に代表値とメンバ情報を持つかによって通常のシナリオ属性と全体処理属性に分かれる。さらに各種の属性やユーザのプロパティを切り出し使用する為に属性プロパティ属性化アイコンが存在する。
そのチャートで利用できる属性は全て属性パレットと呼ばれるアイコンのコンテナに表示される（新規のブランクのアイコンも）。
そのアイコンをチャート上或いは記事編集画面にドラッグ等によって配置して値の変更、条件、フォームの代入先として利用する。
属性のアイコンはその種類ごとにチャート上に配置できる場所が異なり機能も異なる。
属性は定義時に付番されるＩＤで識別される。
データ構造としては
ＩＤ
名称
種別
型
(属性値リスト)
定義モジュール
メンバ情報
属性値
となり
全体処理属性は更に一階層個々のメンバ情報にユーザメンバー情報と属性値がぶら下がる。
参加者属性は参加者タイプ（図３４参照）別アクティブ情報とインポート属性の種別と連携先情報、コメントが加わる。

3-3-1-3-1：スコープ＃定義/スコープ
このシステムにおける属性のスコープとはどのモジュール（シナリオ）もしくはコンテンツの属性パレットに表示されるかを表す。
参加者属性は3-3-6-1：属性登録で定義されシナリオ中の全ての属性パレットで利用できる。但し参加者タイプ（図３４参照）によってはノンアクティブなタイプの場合、値を持たない場合がある。
シナリオ属性は定義されたモジュールかそれ以下の階層のモジュールかコンテンツのパレットで利用できる。図５及び1-4-1項参照。

3-3-1-3-2：型
通常の属性は属性値タイプとして真偽、数値、文字列、文字列（リスト）、データの型を持ちうる。一方全体処理属性は集団行動を制御する為に特別な型を持つ。
真偽：真値と偽値を持つ。参加ユーザはスコープ内ではデフォルトで偽値を持つとして扱われる。参加者属性ではノンアクティブな参加者タイプ（図３４参照）、全体処理属性ではメンバ外はいかなる値も持たない。
数値：数値情報を持つ。参加ユーザはスコープ内ではデフォルトで０を持つとして扱われる。参加者属性ではノンアクティブな参加者タイプ（図３４参照）、全体処理属性ではメンバ外はいかなる値も持たない。
文字列：文字列情報を持つ。参加ユーザはスコープ内ではデフォルトで空白値を持つとして扱われる。参加者属性ではノンアクティブな参加者タイプ（図３４参照）、全体処理属性ではメンバ外はいかなる値も持たない。
文字列（リスト）：予め予約された文字列の情報を持つ。定義時に指定されなくてはならない。参加ユーザはスコープ内ではデフォルトで空白値を持つとして扱われる。参加者属性ではノンアクティブな参加者タイプ（図３４参照）、全体処理属性ではメンバ外はいかなる値も持たない。
データ：定義時にデータ形式を指定しなくてはならない（アイコンに拡張子の記号が現れる）。画面パーツ、外部モジュールが要求する形式のデータを型として指定できる。参加ユーザはスコープ内ではデフォルトで空白値を持つとして扱われる。参加者属性ではノンアクティブな参加者タイプ（図３４参照）、全体処理属性ではメンバ外はいかなる値も持たない。それ以外の状況では文字列タイプとして扱われる。
指定可能なデータ形式はある形式を利用する画面パーツ、外部モジュールをパレットに型として登録した時点で追加される。（公式の画面パーツ、外部モジュールに必要な形式はデフォで指定可能）＃外部データ利用

3-3-1-3-3：シナリオ属性
シナリオ上でユーザやイベントの進行を制御する為に使用する属性タイプのオブジェクト。シナリオ属性はユーザに属し理論上はスコープ内では一旦定義されたなら全てのユーザがその属性を持つ。
一部の配置場所では遷移制御モードとして遷移制御の為に条件情報として以外は真偽値型とカウンタ型どちらかとして扱われる。＃遷移制御
真偽：真偽値型（偽：偽/真：真）
文字列：真偽値型（偽：空白値/真：”1”）
文字列：真偽値型（偽：空白値/真：リストの一番目の値）
数値：カウンタ型
図２８の配置可能な場所に配置する事が出来、真偽タイプは図２３のモード通りにユーザの属性の状態を変化させ、カウンタータイプは増減させる（反転配置は不可能）。
その他の記述子のループ値、遷移値配置部、カウンタ配置部にカウンタータイプは配置可能となる。
遷移制御モードのシナリオ属性の配置可能な場所
ターミナルステイタス
評価ステイタス
終了レセプタ
コンテント開始時
遷移未開始
トリガレセプタ
タイムイン
タイムアウト
フィールドイン
フィールドアウト
強制終了レセプタ
処理アイコン（評価開始時/カウンタータイプは評価開始時と終了時：アイコン上部と下部）
計算チャートでは通常の型として利用されるが記述子の論理遷移矢の制御に利用されるときは遷移制御モードと同じ挙動をする。（代入遷移矢と結合したら通常の型として機能）＃計算ゾーン
双方のチャート上で
属性パターンフィルタの属性ドロップ部に配置された属性は条件情報としてパターンフィルタの挙動を制御する。

3-3-1-3-4：参加者属性＃保存属性管理
参加者属性はユーザや管理者側が提供する嗜好や価値情報をシナリオ中で利用する為に使われる。ユーザがその属性を持つかはイベント参加時に決まる参加者タイプ（図３４参照）によって決まる。スコープはシナリオとなる。データ型はなくどうしても指定する必要があるときは文字列にURLを保持、（適切なものがあれば）外部モジュールにレセプトしてデータ型のシナリオ属性に転換。
保存属性との連携などイベント外の情報の連携を行う。

3-3-1-3-5：全体処理属性 ＃全体処理＃メンバスコープ
定義モジュールインスタンスに対してユニークなモジュールのメンバスコープか指定域、或いは指定した下位の全体処理TZ或いは全体処理モジュールインスタンスをメンバ情報として持つ属性。グループなど集団行動を管理する為に使用される。
メンバの個別の属性値だけで無く代表値、代表プロパティなどの全体処理用の情報を持つ。
全体処理TZ或いは全体処理モジュールインスタンスを依存先として持つ値は通常型の他にユーザオブジェクトを値として持ちうる。メンバ計算ＴＺかオナータイプのグループプロパティ取得モード（3-3-1-3-6：属性チャート上挙動個別説明b）項）でこの型が付与されたら該当するメンバ情報が代入される。
定義モジュールインスタンスに対する代表値とメンバに対するメンバ属性値を持ちうる。
全体処理モジュールか全体処理記述のあるモジュールでのみ機能する。
また特別に全体処理属性はオーダー型、グループ型を数値型メンバ属性値、リスト文字列型と組み合わせて取りうる。

オーダー型は各メンバにユニークな順序情報を持つ（保障）。スコープの属性制約などでメンバが分割されたならその分割内でのオーダーに再編成される。

オーダー型の順序生成方法
数値型：数値の小さい順。同数値の場合は付与時間が早い方が優先される。
リスト文字列型：属性値がリストの上位順。同文字列の場合は付与時間が早い方が優先される。

グループ型は同値のメンバ属性値を持つユーザをそれをキーとしてグループ化する。トリガコネクタをグループ型で制約し他の全体処理ＴＺかモジュールに生成遷移するとグループ毎にインスタンスが生成される。（そのインスタンスのメンバスコープはグループメンバとなる）
＃グループ管理
インスタンス型はメンバが全体処理エリア、全体処理関連個別処理をメンバとするタイプ。潜在的に配置されたモジュール内の全てのインスタンスがメンバである。準拠するとその記述のインスタンスがメンバに追加される。（個別処理の（複数遷移による多重生成などの）インスタンス制御は厳密に言えば全体処理では無いが複雑な操作となるので全体処理属性（全体処理関連個別処理エリア）での制御の範囲とする）＃インスタンス管理

全体処理属性の型
代表値
真偽
数値
文字列
文字列（リスト）
データ
ユーザオブジェクト
省略（メンバ属性値のみ）
メンバ属性値
真偽
インスタンス型真偽
数値
オーダー型数値
グループ型数値
インスタンス型数値
文字列
インスタンス型文字列
データ
インスタンス型データ
文字列（リスト）
オーダー型文字列（リスト）
グループ型文字列（リスト）
インスタンス型文字列（リスト）
ユーザオブジェクト（自動的にインスタンス型）
省略（代表値のみ）

3-3-1-3-5-1：全体処理属性のメンバスコープ＃メンバスコープ
全体処理チャートフィールド上に配置、或いは上のシナリオ属性配置部に配置された全体処理属性は準拠矢を飛ばす事によってメンバを指定出来る。複数回指定された場合はアクティブユーザとノンアクティブユーザが発生しうる。ノンアクティブユーザの属性値は保持されるがその間はイベントに影響を与えない。差分指定で値を操作する事が出来る。

3-3-1-3-6:属性プロパティ属性化アイコン
属性のプロパティを属性化して通常フィールドでシナリオ属性として機能させるアイコン。先にブランクのシナリオ属性として配置した後対象の属性を配置する。*は参照のみ可能。
シナリオ、参加者属性
・ペルソナ名*
全体処理属性＃代表値
・代表値（属性値：全体処理配置チャート通常フィールドで代表値を利用する為）
・メンバ数*
・ペルソナ名*
・順序（オーダー型の順序情報）*
・順序（逆順のオーダー型の順序情報）*
・グループ値（グループの識別属性値（数値か文字列）*＃グループ管理
・メンバ(全体処理上でメンバ情報)*
・真値メンバ数*（真偽型）
・偽値メンバ数*（真偽型）
・差分メンバ数（差分準拠に準拠）
代表値メンバオブジェクト
・代表値メンバペルソナ名*
・代表値メンバ属性抽出（他にユーザ、シナリオ属性の配置が必要）
記述インスタンスプロパティアイコン*(準拠矢で抽出オブジェクトを指定、コネクタなどに配置ですでに準拠対象が明示されているなら不要) ＃インスタンス管理

3-3-1-3-7：属性チャート上挙動個別説明
属性アイコンが配置可能なチャート上の場所は以下の通りである。＃遷移制御
１） チャートフィールド（通常）
２） チャートフィールド（代入遷移矢接続）
３） シナリオ属性付与部位
４） 条件属性部
５） 属性パターン配置部
６） 判定値配置部
７） メンバ制約部
８） プロパティ属性化アイコン
a) 一部の配置場所ではシナリオ属性、全体処理属性アイコンは遷移制御モードとして他の配置場所と異なる挙動を示す。3-3-1-3-3：シナリオ属性参照。＃遷移制御
遷移制御モードではアイコンは四つの状態を取り得る（配置モード）。状態の変更は配置後属性部位を選択クリックすると順に状態選択されて行く。
真値（+1）付与（アイコンはそのまま）
偽値（-1）付与（アイコンにマイナスマーク）
値反転（反転）
プロパティ取得モード(アイコンにPマーク)
プロパティ取得モードでは更にプロパティ取得リストが出現するので属性型で可能なプロパティを選択する。
あ)コンテンツ、TZ生成、アイドリング開始からの経過時間(秒):数値
い)ステイタス名:文字列
う)コンテンツ名:文字列
え)(全て)正規処理か？:真偽値
お)(全て)不正規処理か？:真偽値
か)(全て)例外処理か？:真偽値
き)(一つでも)正規処理か？:真偽値
く)(一つでも)不正規処理か？:真偽値
け)(一つでも)例外処理か？:真偽値
＃コンテント状態制御
b)全体処理属性は更に全体処理関連個別処理エリアではグループプロパティ取得状態を取りうる。＃代表値
グループプロパティ取得(アイコンにGマーク)
あ）オーダー(グループでその遷移を通過した順がオーダーとして):オーダー型数値（属性値には順位が入力）
代表値には現在の最大順位
い)グルーピング(コンテンツ内(主に外部モジュール)でユーザがグループ化した場合、先頭通過者の属するグループから整数番号が割り振られる):グループ型数値
代表値にはグループの総数＃グループ管理
う)オナー(オーダーとメンバ属性では同機能。指定した順位のメンバを代表値に入力する。
代表値には指定した順位のメンバオブジェクト
全体処理外の通常フィールドでは普通のシナリオ属性として機能。全体処理関連個別処理エリア上ではメンバ属性値、全体処理タイムゾーン上では代表値が変化。グループプロパティ取得モードでは型に従ってその遷移に関する関連情報を取得する。
１） チャートフィールド（通常）：シナリオ属性、全体処理属性のみ配置可能。遷移制御モード。合流分岐アイコンと同じ機能を持つ。
２） チャートフィールド(代入遷移矢接続):全ての属性値が可能。遷移起点の場合は先の計算子に属性値を送る機能、遷移先の場合は計算子より値を受け取り、属性値を書き換える機能を持つ。
計算クラスタの一部として論理遷移矢(通常や)を受け取り発する機能も持つ。
３） シナリオ属性付与部位:シナリオ属性、全体処理属性のみ配置可能。遷移制御モード。
４） 条件属性部：全てのタイプの属性を配置可能。全体処理属性の全体処理では代表値が属性値として機能。
５） 属性パターン配置部:全てのタイプの属性を配置可能。全体処理属性の全体処理では代表値となる。
６） 判定値配置部:数値型の属性を配置可能。その回数処理アイコンが反応すると遷移矢を放つ。
７） メンバ制約部:条件制約の為に属性アイコンをドロップする事が出来る。
８） プロパティ属性化アイコン:対象となる属性を特定する為に属性アイコンをドロップして結合させる。

3-3-1-4：ゾーン
シナリオチャート上で経過時間及び移動の制御及びコンテンツの寿命制御の為にゾーンと呼ばれるオブジェクトが使用される。ゾーンは時間軸、あるいは地理的な広がりの一部をゾーンとして区分する。またその区分をユーザ（端末）が越境した時点でステイタスが発生する。ステイタスは進入と脱出で異なるステイタスを発するのでユーザがゾーン内に居るか居ないかの情報を持つ必要がある。

3-3-1-4-1:ゾーンクラス化＃パレット＃クラス/テンプレート
設定が終わったゾーンは設定でクラス化を選択するとコンテンツ扱いとなりコンテントパレット上に出現させられる。定義モジュールでタイムゾーンはクラス化したモジュールとなりフィールドゾーンはシナリオとなる。性質上同一チャートで配置できるのは一種類につき一つ。
ライブラリからインポートしたフィールドゾーンもコンテントパレットに表示される。

3-3-1-4-2：タイムゾーン＃遷移制御
図２５参照。タイムゾーンはイベントの経過時間とタイミングの管理及び内部に配置されたコンテンツの寿命管理の為に利用されるチャートの一部を切り取るように配置されるオブジェクトである。付随するトリガを管理する為に周囲に「タイムイン」「タイムアウト」「遷移不生成時刻設定」「正規終了」の四つのアイコンを付随させる。
また枠内には名称、タイミング設定が表示される。
タイムゾーン内に配置されたコンテンツ及びタイムゾーンの寿命はタイムゾーンの寿命の範囲でしか生成存在出来ない。タイムゾーンは入れ子に出来る。
タイムゾーンの枠を交差する事は出来ず遷移矢以外のアイコンは枠を跨る事が出来ない。
タイムゾーンの状態遷移は図２５に示した通りである。
コンテントの終了が時間内に終わらなかった場合はタイムアウトが発生する。
コンテントが正常に終了した場合、タイムアウトは発生しない一方、タイムアウトが発生すると内部の呼び出しコンテンツ、生成タイムゾーンは例外終了する。
タイムゾーンの生成タイミング（タイムイン）、生成の遷移不生成り（遷移不生成時刻設定）、強制終了タイミング（タイムアウト）をタイムゾーンのタイミング設定と呼び同じ方法で行われる。3-3-1-6：タイミング設定に詳述。
タイムゾーンは下記の終了条件を満たしてもタイムアウトが発生するまで終了しない持続設定を行う事が出来る。
また左肩にメンバ制約部が存在し条件を配置する事が出来る。

3-3-1-4-2-1：タイムゾーンの終了＃コンテント状態制御
持続設定が無い場合に。
生成したタイムゾーンにおいて不正規処理コンテンツと評価中の評価遷移矢と記述子が存在せず呼び出しコンテンツが全て正規処理され正規処理を起点として排出遷移を行ったか？
この条件が満たされるとそのタイムゾーンは正規終了されたとみなされ正規終了トリガが発行される。3-3-1-2-1-2：コンテントの状態を参照。
同様に上記条件を拡大して未帰着の評価遷移矢と記述子が存在せず呼び出しコンテンツが全て正規処理済みか不正規終了をおこなったとしてもタイムゾーンはタイムアウトを待たずして終了する（不正規終了）。
この条件が満たされるとそのタイムゾーンは不正規終了されたとみなされ不正規終了トリガが発行される。3-3-1-2-1-2：コンテントの状態を参照。

3-3-1-4-2-2：計算ゾーン＃計算ゾーン
計算ゾーンは計算モジュールと同等の機能を持った特殊なタイムゾーンで寿命は一瞬として扱われる（開始時点でゾーン内の処理が最優先される）。計算ゾーンを配置すると計算子パレットが呼び出される。付随トリガは存在しない。
計算子は計算ゾーン以外には配置できず、またコンテンツも計算ゾーン内には配置できない。

3-3-1-4-3：フィールドゾーン＃遷移制御
図２４参照。フィールドゾーンは移動の管理と関連付けられたコンテンツの寿命管理の為に使用される。
付随するトリガを管理する為に周囲に「フィールドイン」「フィールドアウト」また関連付けられた場合、メンバ制約がされた場合は「遷移不生成」アイコンが出現する。
タイムゾーンがアイコンをチャート上で包含する形で関係を表現するのに対してフィールドゾーンはチャートの端に設置されてゆく形でトリガの管理を行う。

3-3-1-4-3-1：所属フィールドゾーン＃コンテント状態制御
コンテンツの寿命管理を行う場合はコンテンツに関連子をドラッグする事によって関連付けを行う。
関連付けられたコンテンツはフィールドインしている間しか生成存在出来ない。強制終了時に初めて関連付けられたフィールドアウトが例外として発生する。フィールドアウト以前に正規処理されたコンテンツはフィールドアウトを発生させない。「遷移不生成」はフィールドアウトしている間に生成遷移が発生した場合に発生する。
生成設定:所属フィールドゾーンはアイコンの設定でフィールドインしたら所属コンテントの生成を行うよう設定出来る。タイムゾーンや配置モジュールが生成していなければ生成は起こらない。

3-3-1-4-3-1：範囲設定
図２４のように呼び出された地図上にポイントマーカーをドロップする事によって行う。
フィールドゾーンの定義方法：以下のモードを選択するアイコンをクリックした後にマーカーをドロップ。
１）ポイント指定：マップ上の一点を指定し有効範囲（半径）を指定して定義。有効範囲の指定は可能ならポイントからのドラッグで。
２）エリア指定：複数のポイントを指定しそれで規定される多角形の内側として定義。
３）データ利用：使用マップで定義された領域指定方法があればそのデータを利用する。＃外部データ利用

3-3-1-4-4:ゾーンアウトマージン＃終了マージン
タイムゾーンにてタイムアウト発生イベントが有ってから実際にタイムアウトが起こるまでの時間及びフィールドゾーンにてフィールドアウト発生イベントが検知されてから実際にフィールドアウトが発生するまでの時間及びボーダーからの距離をゾーンアウトマージンと呼ぶ。
それぞれの設定で時間及び距離を指定して決定するがモジュール、シナリオ単位で設定する事も可能。
ユーザに対しては検知時点でメッセージが発せられ、ホットコンテンツの最上位にリストされる。

3-3-1-4-5:ゾーンおよび付随アイコンチャート上挙動個別説明
3-3-1-4-5-1-:タイムゾーン＃遷移制御
ゾーン指定枠:タイムゾーンはチャートフィールドを区分する為に指定枠を持つ。フィールドゾーンもゾーンとしての共通性を強調する為に似たアイコンを持つがこちらは只のアイコンである。
矩形でドラッグによって移動及び変形が出来るようドラッグポイントを配置する(標準的なもので構わない)。
矩形は遷移矢以外が横切ってはならない(メンバ制約部は別)。
準拠矢のみは枠そのものと結合出来る(ドラッグポイントなど？)
タイムイン:矢印形で生成タイミング設定が為されると指定枠の上部に自動配置。先端がステイタストリガで根元がステイタスレセプタ。ただし開始タイミング設定にtriggerもしくはtrigger+記述が無いとレセプタは機能しない。その場合、結合する遷移矢が評価されると開始タイミング設定が評価されtz生成となったらステイタストリガが発行される。
タイムアウト:タイムインと逆向きの矢印で終了タイミング設定が為されると指定枠の下部に自動配置。先端がステイタストリガで根元がステイタスレセプタ。ただし終了タイミング設定にtriggerもしくはtrigger+記述が無いとレセプタは機能しない。その場合、結合する遷移矢が評価されると終了タイミング設定が評価されタイムアウトとなったらステイタストリガが発行される。
遷移不生成時刻設定:タイムインと形状の異なる矢印でタイムインアイコンの隣に遷移不生成タイミング設定もしくはメンバ制約部に何かが配置されると自動配置。先端がステイタストリガで根元がステイタスレセプタ。ただし遷移不生成タイミング設定にtriggerもしくはtrigger+記述が無いとレセプタは機能しない。その場合、結合する遷移矢が評価されると遷移不生成タイミング設定が評価され遷移不生成となったらステイタストリガが発行される。遷移不生成されたTZは生成されない。
正規終了:タイムアウトと形状の異なる矢印で枠下部に自動配置。先端がステイタストリガとなる。タイムゾーンが正規終了するとトリガが発行される。
アイコンをクリックすると不正規終了モードに変化し、隣に正規終了アイコンがもう一つ現れる(こちらはクリックしても変化なし)
設定アイコン:枠内の一部にアイコン。設定の文字。クリックすると詳細設定が現れる。
設定表示され以下の処理も行える。＃シナリオ/計算チャート＃遷移制御
1:名称：ＴＺは名称なしでも機能するが識別用に名称を入力できる。枠内左上に表示される。
2:生成タイミング設定:タイミング設定チャートが呼び出され生成タイミング設定を行う。
行われると右上に条件設定が条件フィルタ一つまでは文字で生成設定が表示、それ以上は生成と記された条件アイコンが該当位置に出現。タイムインアイコンが出現。
3:終了タイミング設定: タイミング設定チャートが呼び出され終了タイミング設定を行う。
行われると右上に条件設定が条件フィルタ一つまでは文字で終了設定が表示、それ以上は終了と記された条件アイコンが該当位置に出現。タイムアウトアイコンが出現。
4:遷移不生成タイミング設定: タイミング設定チャートが呼び出され遷移不生成タイミング設定を行う。
行われると右上に条件設定が条件フィルタ一つまでは文字で遷移不生成設定が表示、それ以上は遷移不生成と記された条件アイコンが該当位置に出現。遷移不生成設定アイコンが出現。
5:持続設定:正規、不正規終了によるタイムゾーンの自動終了を行わずタイムアウトを発生させる。
6:タイムアウトマージン設定：トリガによる終了設定時の時のマージン時間を設定。モジュールもしくはシナリオで一律に設定した時に適用するか否かの選択（適用がデフォ）も出来る。＃終了マージン
7:全体処理タイムゾーン:タイムゾーンを全体処理タイムゾーンに。色が変化。
8:個別/メンバ計算ゾーン:タイムゾーンを個別計算ゾーンに。付随トリガは消える。
9:全体処理計算ゾーン:タイムゾーンを全体処理計算ゾーンに。付随トリガは消える。色が変化。＃計算ゾーン
メンバ制約部:枠左上にレセプタアイコンが。制約で跳ねられると遷移不生成が発生。＃メンバ制約

3-3-1-4-5-2:フィールドゾーン＃遷移制御＃遷移制御
ゾーンアイコン:矩形の枠状。内部にメンバ制約部(左肩)、設定アイコン、関連子アイコンが現れ、付随してフィールドイン、フィールドアウトトリガが出現する。制約が機能すると遷移不生成アイコンが付随する。
フィールドイン:下部に自動配置。矢印形で先端にステイタストリガ。フィールドゾーン内部にユーザ端末が侵入したときに発行。
フィールドアウト:下部に自動配置。矢印形で先端にステイタストリガ。フィールドゾーン外部にユーザ端末が出たときに発行。
関連子アイコン：矩形内部に自動配置。ドラッグを思わせるイメージのアイコン。ここをコンテントにＤＤすると所属フィールドゾーンになる。
遷移不生成アイコン：メンバ制約が機能するとアイコン上部に出現。弓矢形で先端にステイタストリガ。
所属フィールドゾーンアイコン：所属させるコンテントの一部に出現。矩形のフィールゾーンの雛形形。小さなフィールドアウトと遷移不生成アイコンが付随する。
メンバ制約部:枠左上にレセプタアイコンが。制約で跳ねられると遷移不生成が発生。＃メンバ制約
設定：枠内の一部にアイコン。設定の文字。クリックすると詳細設定が現れる。
設定表示され以下の処理も行える。
1: 名称：ＦＺは名称なしでも機能するが識別用に名称を入力できる。枠内左上に表示される。ただしクラス化する時には名称は必要。
2:設定マップを開く：開いた場合、マップが現れ以下の方法で領域を設定できる。
１）ポイント指定：マップ上の一点を指定し有効範囲（半径）を指定して定義。有効範囲の指定は可能ならポイントからのドラッグで。
２）エリア指定：複数のポイントを指定しそれで規定される多角形の内側として定義。
３）データ利用：使用マップで定義された領域指定方法があればそのデータを利用する。ライブラリデータパレットが、設定マップが開くと出現。DDし地図に落とすと設定。＃外部データ利用＃パレット
3: フィールドアウトマージン設定：トリガによるフィールドアウト感知時の時のマージン時間と距離を設定（AND/OR）。モジュールもしくはシナリオで一律に設定した時に適用するか否かの選択（適用がデフォ）も出来る。＃終了マージン

4:所属コンテンツリスト：そのフィールドゾーンを所属フィールドゾーンに持つコンテンツのリスト。選択するとその配置モジュールに飛ぶ。＃コンテンツリスト（切り出し）
5:フィールドゾーンのクラス化：1〜3の項が設定されたフィールドゾーンをクラス化する。
＃クラス/テンプレート

3-3-1-5：記述子（処理アイコンと遷移矢、トリガアイコン）＃遷移制御
シナリオチャート、計算チャートでコンテンツの状態を管理する為にゾーンと共に使用されるアイコンである。図２２、図２３参照。全体処理に関わる記述子は全体処理で記述。
処理パレットに現れる処理アイコンに加えて遷移矢、トリガアイコン、強制終了レセプタが通常の記述子である。これに例外管理用の管理者コールと計算チャート用の記述子、全体記述用の記述子を加えたものが拡大された記述子である。
遷移矢はステイタストリガから伸ばす事が出来、ステイタスレセプタと結ぶ事が出来る。
・ステイタストリガ＃遷移制御
ターミナルステイタス（評価ステイタス）
コンテンツの終了状態ステイタス
コンテンツアイコンの生成/未生成ステイタス
トリガアイコン
ゾーンの付随トリガ
処理アイコンの特定部位（個別説明）
チャート上に直置きされたシナリオ属性アイコン

・ステイタスレセプタ＃遷移制御
コンテンツの発生ステイタスアイコン
コンテンツのトリガレセプタ
タイミング設定にtrigger記述のあるゾーンの付随トリガ
処理アイコンの特定部位（個別説明）
チャート上に直置きされたシナリオ属性アイコン
強制終了レセプタ
遷移矢：ステイタスが発生した場合の処理の流れを表す。一つのステイタスからは一つの遷移矢のみ生成。行き先の無い遷移矢が残っているとシナリオは完成されない。
単遷移矢：細線（トリガに一回のみ反応）
複遷移矢：太線（トリガに複数回反応）
複遷移矢はトリガが発生するたび評価。単遷移矢は最初に発生したトリガにのみ評価。
複遷移矢で続く遷移先に発生レセプタがあるとそのコンテンツは複数のインスタンスを持ちうる。
遷移矢のタイムゾーン枠の侵入と排出：遷移矢はタイムゾーンの枠を超えて延長する事が出来る。この配置は処理上特別な意味を持つ。
侵入する遷移矢はタイムゾーンの生存期間しか機能しない。そうした遷移が発生した場合、特別に内部コンテンツの生存期間でなくても「遷移不生成ステイタス」が（内部コンテンツに）発生する。＃コンテント状態制御
モジュールがアクティブ状態の期間中（ある時点）に実際に遷移が行われた遷移矢を評価遷移矢、評価がなされなかった遷移矢を非評価遷移矢（未評価遷移矢）と呼ぶ。
処理アイコン：処理アイコンはコンテントに向かう遷移矢を中継、条件処理あるいは端末処理をしてシナリオの制御を行う。
通常で七種類の処理アイコンが存在する。図２３参照
１）終末アイコン（遷移管理）
２）合流分岐アイコン（遷移管理）
３）遷移矢カウンタ（遷移管理）
４）属性パターンフィルタ（条件処理）
５）比較条件フィルタ（条件処理）
６）ループカウンタ（遷移管理）
７）ワイルドカード（記述効率化）

１） 終末アイコン（遷移管理）：ステイタス、ターミナルステイタスの遷移を終わらせたい時に使用する。遷移矢をステイタスから延長して配置するかステイタスにドロップして配置。
帰結終末:計算チャートでは論理遷移矢の終末の一つのみに帰結終末ステイタスエミッタをドロップ出来る。
２）合流分岐アイコン（遷移管理）：遷移矢を合流させまた分岐させられる。遷移矢の種類に従った処理が行われる。
合流側のいずれかの遷移矢が評価されると分岐側のすべての遷移矢が評価される。分岐側の単遷移矢は一回のみ反応だが複遷移矢は合流側が評価さされるたび評価。
シナリオ属性が遷移管理モードで上端に配置可能で合流側の矢が評価される度に属性値が変化する。
３）遷移矢カウンタ（遷移管理）：カウンタータイプの合流分岐アイコン。遷移が一定数流れ込むと下端の遷移が発生する。判定値配置部がありそこに数値型の属性アイコンをドロップするか数値を直に入力するとその数値回評価されると分岐側の矢が評価される。複遷移が結合されていると再び数値回評価されると再反応（繰り返し）。
４）属性パターンフィルタ（条件処理）：ＹとＮのステイタストリガを持ち条件属性部にドロップされた属性の所持パターンに合致するユーザの評価がＹのステイタスを発行させ、合致しないユーザの評価がＮを発行させる。ドロップ出来る属性の数に制限は無いが表示できるのは三つまで。クリックすれば展開。単項、ＡＮＤ（論理積）とＯＲ（論理和）の三つのモードがある。
５）比較条件フィルタ（条件処理）：ＹとＮのステイタストリガを持ち、二項の比較を行って真偽を判定しＹとＮステイタスを発行する。二か所の条件属性部があり、また合同、数値比較（イコール含む）、数値比較の三つのモードがある。一方のドロップ部に数値や文字列、真偽値（Ｔ/Ｆ）を入力する事も出来る。
６）ループカウンタ（遷移管理）：二組のアイコンで（結合点線で結ばれている）下向きのアイコンに遷移が行われると上端から伸びている遷移矢が評価される。そしてループ下端に到達した遷移は上端に遷移し再び遷移が開始される。この時ループさせる遷移部分は複遷移矢で結ばれていなくてはならない。それぞれのアイコンが評価される回数を数値型属性ドロップあるいは直接の数値入力で決める事が出来る。無限定とする事も出来る。その場合は条件によって離脱する事になる。ループに対して複遷移矢が結合しているとその評価が行われる度に回数が消費され遷移が発生する。この状況は遷移矢カウンタを組み込むことで整理できる。複遷移の回数を制限する為にこの機構を利用する事も出来る。
ループは同一のタイムゾーン内に無ければならない。
なお、遷移矢のみでループを形成すると外形チェックで警告を受ける。
タイムゾーンを遷移矢のみのループがまたぐとリジェクトされる（少なくとも子ＴＺを挟む場合はループカウンタを挟むこと）。
これは意図しないループをチェックする為とタイムゾーンをまたぐループを形成して時間管理が困難になるのを防ぐためである。＃概形チェック
７）ワイルドカード（記述効率化）：ワイルドカードは複数のコンテンツもしくはフィールドゾーンを束ねて条件に従って実行させる処理アイコンである。
コンテントの収納タイプは数値がデフォルトで付番され遷移がループなどで発生するたびに順番に若い数値から実行してゆく。ただし各コンテンツのメンバ制約部の条件を満たすコンテンツが実行される。遷移の状況によって制約が解けた場合は付番がその時点で一番若いコンテンツが実行される。
ターミナルステイタスはワイルドカードに集約して配置される。複遷移矢が結合していない場合評価されるのは最初の一回のみである。この時元のコンテンツのステイタスは薄く表示される。このステイタスは遷移を必要としない。こちらを利用する事も可能で遷移矢の配置されたステイタスは元の濃さにもどる。
ワイルドカードに条件子共にコンテンツをドロップすると内部に収納されカードアイコンをクリックするとそのリストを閲覧できるようになる。
フィールドゾーン収納タイプはフィールドインアウトを付随。
収納するフィールドゾーンはシーケンス順にトリガの受付を行うシーケンス制限プロパティを付ける事が出来る。無ければフィールドインアウトが発生する度にトリガが発生する。
メンバ制約を受ける事も出来る。
このフィールドゾーンワイルドカードと遷移矢で結ばれたコンテントワイルドカードのコンテントにトリガ発生所属フィールドゾーンのコンテントが有れば優先的に起動される。複数の場合はカードの順序指定順。
＃メンバ制約
トリガアイコン：トリガアイコンはモジュール外のトリガをチャート内に導入する為のアイコンである。
チャート上にはスタートトリガアイコンがデフォルトで配置されていてこれは除去する事は出来ない。
新規のトリガアイコンは二つのモードで配置しうる。
一つは管理者トリガで生成時に名称を付ける。これはシナリオにおいてユニークで名称+定義モジュール名で登録される。一旦登録された管理者トリガは管理者トリガパレットから呼び出せる。イベントモニタ（図１１参照）の3-5-1-1：管理者トリガで運用する。
もう一つはトリガレセプタと対応する一般トリガで生成すると自動的に付番されチャート上に出現する。これはモジュールのアイコン上に対応するトリガレセプタを生成する。いずれもタイムゾーン内部にも配置できその場合TZの生存期間内にしか機能しない。
強制終了レセプタ:モジュールを強制終了させるステイタスレセプタ。評価されるとモジュールは終了し、不正規終了となる。＃遷移制御

3-3-1-5-1：記述子チャート（全体処理以外）上挙動個別説明＃遷移制御
遷移矢： 3-3-1-1-1：チャート操作、3-3-1-1-1-4：遷移矢の結合操作参照。
単遷移矢
複遷移矢
終末アイコン:終末である事を強調するデザインのアイコン。
合流分岐アイコン:アイコンの上部がステイタスレセプタ、下部がステイタストリガとなる。
遷移矢カウンタ:合流分岐アイコンと似ているが判定値配置部を強調するデザイン。ステイタスレセプタ、ステイタストリガ、判定値配置部が存在する。
属性パターンフィルタ:条件子である事を強調するデザイン。アイコン上部にステイタスレセプタ、下部に論理帰結部のY、Nのターミナルステイタス。右肩に条件属性部が存在する。左肩にモードを示すモード表示部がある。
モード表示部は条件属性部の属性が1以下の場合は無表示。2以上の場合はANDとORの二つのモードを取り、表示部をクリックする事でモードが入れ替わる。
比較条件フィルタ:属性パターンフィルタと似たデザインをし、ステイタスレセプタと論理帰結部は同じ。左右に条件属性部(フォームのタイプ)が存在し通常は入力フォームを表示しているが属性を一つだけドロップする事が出来る。選択すると大きく表示され数値、文字列、真偽値を入力出来る。プルダウンで三種類を選べフォームの見出しが変わる。
真ん中にモード表示部があり、クリックすると合同、イコール比較、比較、逆方向イコール比較、逆方向比較の５モードが切り替わる。
ループカウンタ:パレット上では同じアイコンだが、チャートに配置されると線で結ばれた上端アイコンと下端アイコンが現れる。上端アイコンは上部にステイタスレセプタ、下部にステイタストリガが存在、下端も同様。ただしデザインは逆向きに。双方に判定値配置部があり属性をドロップ出来る。どちらでも判定値だけ該当アイコンが反応したら下端のステイタストリガが発行される。何も配置されない判定値配置部は無限回となる。
ワイルドカード:コンテントライクなアイコン。コンテントアイコンをDDすると収納される。収納コンテントのターミナルステイタスが現れる。
クリックすると内部のコンテントのリストが呼び出される。
コンテントリスト（図３２参照）の編集部分を除いた内容。但し展開のボタン列が追加されている。
展開を選択するとリストが消えそのマウスポインタがコンテントのシルエットに変形。フィールド上でクリックするとその場にワイルドカードと結ばれたコンテントのアイコンが表示される。そのアイコンはステイタストリガのみが機能する。
トリガアイコン:トリガを強調するデザイン。ステイタストリガが存在する。またスタートトリガは色が異なりスタートの文字が。管理者トリガはトリガ名が表示。通常のトリガは付番が表示される。
配置されると管理者か通常か選択するリストが表示される。選択されないか通常が選択されると付番された通常トリガが配置、管理者が選択されると名前の入力フォームが現れ、入力されると管理者トリガとして配置。
強制終了レセプタ:その意味を強調するデザイン。全部がステイタスレセプタ。

3-3-1-6：タイミング設定＃タイミング設定
図２５参照。タイムゾーンのタイミング設定、強制終了レセプタのタイミング設定は同様の方法で行われる。
タイミングに必要な情報は三つの方法で取得される。
トリガ
時間設定
属性
である。
トリガは付随アイコン、あるいは遷移矢を受けるアイコンが遷移を受けるたびに発生する。トリガの内容を区分できないが属性を使用する事によって実際上は可能である。＃遷移制御
時間設定は表にあるように５種類の方法で設定できる。
１）グローバル時間記述
２）基準モジュールインスタンス開始時指定
３）相対時間記述
４）タイムイン経過
５）Trigger記述アイコン
説明：評価はアイコン化された各情報を計算チャートの編集として配置して行われる。＃シナリオ/計算チャート
後述のタイミング設定チャートではパレットからトリガアイコンを配置した後に入力フォームが出現、指定。基準モジュールインスタンス開始時指定の場合はコンテントリスト（図３２参照）の上位ネストモジュール部分が出現。
１）グローバル時間記述：実時刻によって指定する。日本時間。
GMT+9 2018：00：00
２） 基準モジュールインスタンス開始時指定：基準モジュールインスタンス生成時点からの時間によって指定。
２−１）自己モジュールより上位（自身も可能）の基準モジュールをコンテントリスト（図３２参照）で指定。
２−２）全体処理インスタンスか個別インスタンスか指定。
２−３）経過時間を入力
$01:00-GameEntry/w $00:50-senario
３）相対時間記述：モジュールインスタンス生成時からの時間によって指定する。
00：00
４）タイムイン経過：in+XX:XXでタイムイン発生からの一定時間経過（タイムイントリガ以外）
該当項目をクリックすると計算チャートが呼び出され属性パレットと図２５のトリガのアイコンが表示されるトリガパレットが表示されそれを使用して設定を行う。
５）Trigger記述アイコンは＋Xアイコンの二種出現。Triggerアイコンは存在するとトリガが発生するたび評価される。
時刻及び時間入力は配置後にトリガアイコンをクリックすると現れる日時分の各入力フォームにカーソルが置かれると現れるプルダウンを使用する。
単一の属性パターンフィルタのみで設定が終了する場合は文字列でタイミング設定がスペースに表示される。

3-3-1-10-3：タイミング設定チャートと属性条件チャート参照。

3-3-1-7：ターミナルステイタスとステイタスエミッタ＃遷移制御
図２２、図２８参照。
チャート上においてコンテンツはユーザによってカスタマイズされた遷移矢の起点としてターミナルステイタスアイコンを出現されうる。この機能はモジュールチャート、記事編集画面の可能な部位にステイタスエミッタをドロップする事によってその評価が行われた時にステイタスを発生させる事が出来るようにする事で実現される。
ステイタスとエミッタは同一のアルファベット一文字（〜二文字）が対応する。ステイタスエミッタパレット上にはそれらのアイコンが表示される。
正規ステイタスと不正規ステイタス、論理帰結ステイタス：シナリオ処理上で進行が上手くいっている処理と対応が必要な事態を区別する為にステイタスは二種類が存在する。正規ステイタスエミッタアイコンは配置された事態が起こると正規ステイタスを発行し、不正規ステイタスエミッタは不正規ステイタスを発行する。一文字の空間ではアルファベットの後方10文字を予約する。ＹとＮは論理帰結ステイタスに予約されている。
論理帰結ステイタスは条件系の処理アイコンの論理帰結部に表示されるターミナルステイタスでＹは真値、Ｎは偽値に対応。
帰結終末エミッタ:タイミング設定チャートと属性条件チャートではステイタスエミッタパレットに一つだけ帰結終末エミッタが記載される。一つ以上の終末アイコンのみに配置可能。

3-3-1-8：パレット＃パレット
パレットはチャートや記事の記述画面にシナリオ進行に必要なオブジェクトを配置する為にドラッグ元として表示する為のものである。
・パレットの種類
コンテントパレット（シナリオチャート、モジュールチャート）
計算モジュール制限の付いたコンテントパレット（計算チャート、タイミング設定チャート、属性条件チャート）
属性パレット（シナリオチャート、モジュールチャート、記事記述画面、計算チャート、タイミング設定チャート、属性条件チャート）
処理パレット（シナリオチャート、モジュールチャート、計算チャート、タイミング設定チャート、属性条件チャート）
管理者トリガパレット（シナリオチャート、モジュールチャート）
画面パーツパレット（記事記述画面）
ステイタスエミッタパレット（モジュールチャート、計算チャート、タイミング設定チャート※、属性条件チャート※）
計算子パレット（計算チャート）
トリガパレット（タイミング設定チャート）
ライブラリデータパレット

パレットに出現するアイコンはそのモジュール、或いは記事がスコープ内のものに限られる。定義モジュールが異なるアイコンは名称+定義モジュール名(ルート)で表示される。

パレットは図２１、図２６、図２７、図１９にあるようにアイコンのコンテナとなる画面上のブロックで形状、位置は可変である。また3-3-3-5：操作にあるように内部のアイコンをドラッグしてチャート上にドロップするとチャート上に子要素が配置され遷移管理が出来る様な付属のアイコンが出現する。
基本的にパレットに収納されるアイコンは数が多く全てを表示するのは不可能である場合が多い。その為三つの機能を持たせる。
1) 形状可変
2) スクロール
3) 検索
a) 1) 形状可変四隅にドラッグ用のポイント、ヘッダーに折り畳み/展開用のボタンを用意する。
内部のアイコンは横幅に応じて整列して横列を増やす。
折り畳みボタンを押すとヘッダーのみのバーとなり、展開させるとドラッグで指定した大きさに復帰する。
b) 2)内部のアイコンが表示不可能なほど多い時は縦スクロールを行えるようにする。
c) 文字列一致およびタグ#で種別を指定できるように検索表示を行えるようにする。#の入力が有った場合にタグリストが表示されるようにする。タグ文字列は空欄ANDで｜ORで（AND優先）＜＜利用できる内部検索システムがあれば導入
表示されているアイコンの上をポインタが通過するとアイコンの名称が表示される。

コンテントパレット＃クラス/テンプレート:そのスコープで使用可能なコンテント、コンテント化されたフィールドゾーンおよびテンプレートが収納される。テンプレートは内部にサブのテンプレートパレットの収納物として扱われる。テンプレートパレットはメインのコンテントパレットの形状変化に追随し上下の変形のみ可能。折りたたまれるとパレット最下部にバー状に配置される。
検索はメインの検索条件によって同時にスクリーニングされる。
コンテントに該当するのは作成中の全ての記事、モジュールとなる。
計算チャートでは計算モジュールのみの表示となる。
表示されているモジュールが定義モジュールのコンテントは枠が強調される。
また定義モジュールが別のコンテントはコンテント名プラスモジュール名が表示。
属性パレット:そのスコープで使用可能な属性アイコンが収納される。
シナリオ属性、参加者属性、属性化アイコンが表示され、チャートが全体処理エリアなら全体処理属性と関連する属性化アイコンが追加される。
表示されているモジュールが定義モジュールのコンテントは枠が強調される。
また定義モジュールが別のコンテントはコンテント名プラスモジュール名が表示。
参加者タイプ（図３４参照）の属性条件チャートでは属性でなく保存属性が出現する。
処理パレット:遷移矢、処理アイコン、トリガ、タイムゾーン、計算ゾーン、フィールドゾーン、全体処理タイムゾーン、全体処理計算ゾーンが収納されている。
全体処理エリアの場合は全体処理アイコン、全体処理遷移矢、準拠矢が追加される。＃全体処理
管理者トリガパレット:登録された管理者トリガが収納されたパレット。
画面パーツパレット:記述編集で使用する画面パーツが収納されている。
ステイタスエミッタパレット＃遷移制御:不正規エミッタ用のサブパレットが存在。機能はテンプレート用と同様。
自動付番された正規エミッタが５(ＡからＥ)が表示。パレットのフィールドがクリックされると５ずつ追加。ダブルクリックで使用されて居ないアイコンが５ずつ削減。
不正規エミッタも同様。当初Z、Ｗ、V、X、Uが表示。予約文字を順に表示して行く。
計算子パレット:計算子と論理遷移矢(通常細矢と同じ)、代入遷移矢が表示される。遷移矢の扱いは処理パレットと同じ。
トリガパレット:タイミング設定で詳述されたトリガアイコンが収納される。
ライブラリライブラリデータパレット：ライブラリに登録された画面パーツ、フィールドゾーン定義で使用可能な形式のデータが収納される。反映されるためにはライブラリ側でインポート作業が必要とされる。DDで画面パーツのデータレセプタに落とすと反映される。＃外部データ利用

3-3-1-9：全体記述＃全体処理
全体処理の目的は以下の通りである。
１：イベント全体の挙動制御（特にタイムゾーン）
２：全体処理属性計算
３：グループ行動の誘導
４：共通行動グループの析出
５：全体処理モジュールの挙動制御

3-3-1-9-1：全体処理記述と全体処理エリア
全体処理は全体処理インスタンス上で稼働する全体処理記述によって駆動される。
全体処理記述は全体処理エリアに記述される必要がある。

全体処理エリア
1:全体処理タイムゾーン
2:全体処理モジュール(内部のチャート)

全体処理エリアに記述可能（b,c内は全体処理エリアから除外）
a：全体処理記述
b:全体処理内個別タイムゾーン
c:全体処理内個別処理モジュール

全体処理関連個別処理エリア
1:全体処理タイムゾーンの存在するチャート内のそれ以外の領域
2: 全体処理内個別タイムゾーン
3: 全体処理内個別処理モジュール

全体処理記述
１：全体処理モジュール
２：全体処理タイムゾーン
３：全体処理アイコン
４：全体処理属性(代表値)
５：属性(メンバ制約情報として:全体処理属性はメンバ属性化アイコン、シナリオ属性は真値、参加者属性はアクティブ)

全体処理記述はトリガコネクタを除いて全体処理遷移矢のみが接続可能である。
全体処理エリア上では全体処理属性しか利用できない。
全体処理記述可能エリア内にも個別処理を記述可能であり全体処理関連個別処理エリアとなる。

3-3-1-9-2：全体処理インスタンス＃インスタンス管理
全体処理インスタンスは全体処理エリア毎に生成される。複数遷移やグループ処理によって同一のエリアでも複数のインスタンスを持ちうる。全体処理インスタンスは全体処理遷移矢の駆動によって独自の挙動を示す。
隷属関係に無い個別処理と全体処理は例え同じチャートフィールドに記述してあっても全く別のタイミングで動く。ただし同一チャート内の両者はコネクタを使用して相互に遷移評価による関連を持つ事が出来る。
全体処理インスタンスは全体処理記述がなされて居ない階層について個別処理インスタンスのいずれかが生成した下位の階層での生成トリガが発生した場合、未生成とならずブランクの階層を生成して該当記述をアクティブとする。
全体処理記述がある場合はその処理に従う。

3-3-1-9-3：メンバスコープ＃メンバスコープ
全体処理インスタンスとユーザの相互作用の範囲を規定するのがメンバスコープである。
具体的にはコネクタの範囲記述とタイムゾーン、内部モジュールの基本メンバスコープ指定、全体処理属性のメンバ指定及びアクティブメンバ差分評価時のアクティブ、ノンアクティブメンバ指定を行う為の記述方法である。
基本メンバスコープ:モジュールとタイムゾーンは基本メンバスコープを持つ。基本メンバスコープは時系列でアクティブメンバが入れ替わる為に絶えず変動する。基本メンバスコープはアドホックなメンバのリストでそのモジュールを個別インスタンスで利用しているユーザ或いは内部タイムゾーン、モジュールのインスタンスが対象となる。
通常モジュール内の全体処理の基本メンバスコープはモジュールのアクティブユーザと内部要素インスタンスである。
全体処理モジュールは子モジュールをアクティブで利用しているユーザと内部要素インスタンスが基本メンバスコープとなる。
準拠を行うことの出来るアイコン(準拠主体)
1) トリガコネクタ
2) 全体処理属性
3) 全体処理タイムゾーン＊
4) 全体処理モジュール＊
5) グループ遷移カウンタ＊（判定値の代わりとして）
＊はユーザ準拠のみ。
記述方法
1)配置モジュールのメンバスコープ
2)個別タイムゾーン、モジュールインスタンス参照(ユーザ、インスタンス)
3)全体処理属性メンバ参照
4)差分範囲
5)条件制約
チャート上での操作
1)デフォルト
2)準拠矢単指定
3)準拠矢複指定
4)メンバ制約部への条件配置

a) 記述方法
1)範囲メンバ指定のあるアイコンをチャート上に配置するとそのチャートを持つモジュールの基本メンバスコープが適用される。
2)準拠矢を使用して全体処理エリア内の個別処理インスタンスのステイタストリガあるいはレセプタを指定すると準拠トリガ発生時点でのそのメンバ或いはインスタンスをメンバスコープとして指定出来る(遷移時系列が後の場合)。個別処理そのものを指定すると準拠時点での現在アクティブメンバを指定。
3)チャート上に配置された全体処理属性のアイコンを指定するとその配置評価時点でのメンバを指定出来る。評価されていなければゼロ。
4)準拠矢を同じ個別記述のトリガと現在値、同一対象準拠のコネクタ(全体処理属性)と個別記述と二箇所に指定するとその差分メンバが範囲として指定される。不正規、例外処理のメンバ確定などに使われる。
5)上記の方法で指定したメンバは更に属性条件などで計算モジュール或いは属性配置で範囲を限定出来る。

b) チャート上での操作
1) デフォルト:単純にチャートフィールド上に配置するとa-1が適用。
2) 準拠矢の単指定先
個別処理タイムゾーン本体
個別処理タイムゾーンの付随トリガ／レセプタ
個別処理モジュール
個別処理モジュールの付随トリガ／レセプタ
全体処理タイムゾーン発生トリガ／レセプタ
全体処理タイムゾーン本体
全体処理モジュール発生トリガ／レセプタ
全体処理モジュール本体
全体処理属性アイコン
基本的に準拠は対象メンバスコープの確認となる。
ただし、トリガコネクタ及び全体処理属性の場合は対象オブジェクトのインスタンスである場合がある。グループ指定の場合は双方となる。
3) 準拠矢の複指定
上記b-2)の指定先に加えて
同一処理(本体か付随トリガを問わず)か属性への準拠を行った準拠主体。
これらの二種類間のメンバ差分a-4参照
4) メンバ制約部への指定
3-3-1-1-1-7：部位参照。（全体処理エリアではメンバスコープの範囲の限定に使用）

3-3-1-9-4： 全体処理モジュール
全体処理モジュールは全体処理インスタンス上で駆動し内部が通常のチャートである事もあるし外部モジュールでも有り得る。
エリアとしての機能は全体処理ＴＺと同じであるが外部の個別処理モジュール内に子記述を配置する事が出来、それによってメンバスコープが変化する。また子モジュールへの遷移が行われた場合の個別ＩＤを持つトリガアイコンが生成される。
全体処理モジュールの生成前に子モジュールに遷移が行われるとイベントの発生しないモジュールが開始される。この場合全体モジュール生成と共に子モジュール発生トリガが発行される。
全体処理モジュールはメンバ制約部を持ち上項b-4の条件を組み込める。
基本のメンバスコープは子モジュールインスタンスが生成されている全てのユーザ。

3-3-1-9-5：全体処理タイムゾーン＃遷移制御
全体処理タイムゾーンは全体処理インスタンス上で処理される。
全体処理タイムゾーンは全体処理エリアおよび通常モジュールのプレーンチャートフィールド上に記述できる（入れ子として機能）。
全体処理タイムゾーンはメンバ制約部を持ち上項b-4の条件を組み込める。
基本のメンバスコープはＴＺ記述のあるモジュールの個別インスタンスが記述されている（生成されうる）全てのユーザ

3-3-1-9-6： 全体処理配置チャート個別処理
全体処理関連個別処理エリアの記述は記述された全体処理のメンバスコープによって制約される。
また全体処理属性およびグループ遷移カウンタ、全体処理計算ゾーンをエリア内で使用できる（メンバ属性値及び属性化した代表値）。
準拠矢の対象となりユーザインスタンス、オブジェクトインスタンス情報を提供する。

3-3-1-9-7：全体処理と全体処理エリア内個別処理の相互作用＃遷移制御
標記相互作用はトリガコネクタとグループ遷移カウンタ及び全体処理属性を利用して行われる。
トリガコネクタは全体処理から全体処理エリア内個別処理への遷移、グループ遷移カウンタは全体処理エリア内個別処理から全体処理への遷移を行う。
基本的にはトリガコネクタはその処理のメンバスコープのユーザあるいは処理インスタンスに対してメンバ遷移部から遷移を行う。
グループ遷移カウンタは個別処理を集合的に管理して全体処理に全体処理遷移を行う（個別処理に再遷移も行える）。
全体処理属性はメンバスコープの個別値と定義モジュールに対してユニークな代表値を保持してメンバと代表値の属性値操作を行い、遷移制御を行う。
１） トリガコネクタ：トリガコネクタはメンバ遷移部から斉一的集合的な遷移を行う。それには三つの種類があり対象と様相が異なる。
１−１）ユーザ遷移：遷移矢は通常。ユーザの個別インスタンスが対象。生成遷移は個別インスタンスを生成する。メンバスコープによって範囲を規定。＃メンバスコープ
１−２）全体処理インスタンス遷移：遷移矢は全体処理。対象の全体処理インスタンスそのものが対象。生成遷移は準拠メンバあるいはインスタンス型全体処理属性をメンバ制約に使用して全体処理インスタンスを生成する。それぞれのインスタンスは準拠したメンバと関連付けされる。＃インスタンス管理
１−３）個別処理インスタンス遷移：遷移矢は通常。ユーザの処理インスタンスそのものが対象。生成遷移は準拠メンバあるいはインスタンス型全体処理属性をメンバ制約に使用して個別処理インスタンスを生成する。それぞれのインスタンスは準拠したメンバと関連付けされる。＃インスタンス管理
１−４）グループ遷移：遷移矢は全体処理。対象の全体処理インタンスと共にそれぞれに関連付けられたユーザの個別インスタンスが対象。生成遷移時は各グループのメンバをメンバスコープとする全体処理インスタンスを生成する。グループ型全体処理属性をメンバ制約に使用して管理を行う。それぞれのインスタンスは準拠したメンバ（グループＩＤ）と関連付けされる。＃グループ管理
２） グループ遷移カウンタ：グループ遷移カウンタは各個別処理インスタンスがその処理をどれだけ評価したかをカウントするタイプのカウンタである。一定値以上になればステイタストリガが発行される。
一定値以上の処理を何で指定するかは定数と充足率の二つの方法がある（ＴＺを挟めば時間管理も可能）。モードを決め方法指定部に属性を落とすか数値入力を行って指定する。
（集計を行う）メンバ制約を行う事が出来る（メンバ制約部）。
グループ型全体処理属性で制約を行うと処理はグループ毎に行える。（戻り先の全体処理にグループ情報が無いときは複遷移が行われたと見做す（実際の遷移矢が単遷移なら最初の一回のみ反応）。
トリガ部分は通常遷移も全体処理遷移もグループ遷移（グループ型全体処理属性で制約）も行う事が出来る。
３） 全体処理属性：全体処理属性のメンバ情報、グループキー情報はメンバ制約に使用する事によってメンバ遷移時に遷移制御に利用できる。
グループ型全体処理属性のグループキー情報
インスタンス型全体処理属性の属性値が互いにユニークである場合
全体処理インスタンスの生成遷移に利用されると各インスタンスに識別キーが付与される。それ以降属性値のキーが一致する全体処理インスタンス遷移は該当する識別キーを持つインスタンスに届く（グループインスタンスの挙動をキーの制約によって制御可能）。＃グループ管理＃インスタンス管理

3-3-1-9-8： グループ処理＃グループ管理
グループ処理は全体処理のメンバスコープのユーザをグルーピングし、グループ型全体処理属性を付与し、コネクタのグループ遷移でグループ管理用の全体処理インスタンスを生成して行う。
グルーピング：個別処理内でグループ型全体処理属性の属性値に同値を代入されたユーザ、また外部モジュールで付与されたグループ情報を3-3-1-3-5-1：全体処理属性のメンバスコープのグルーピングなどで付与されたユーザはグループ化キーを持つことになる。
グループ処理全体インスタンス：3-3-1-9-7：全体処理と全体処理エリア内個別処理の相互作用のグループ遷移で生成したモジュール及びタイムゾーンは識別キーとして利用したグループ型全体処理属性のキー属性値を持つ。またそのグループ化キーを持つユーザをメンバスコープとする。
それ以降のグループ処理全体インスタンスに対する遷移はユーザ、インスタンス双方に可能だがインスタンスを特定した遷移はキー情報をインスタンス型属性値もしくは生成に利用したグループ型全体処理属性が必要になる。

3-3-1-9-9：メンバ計算タイムゾーンと全体処理を含んだ計算＃計算ゾーン
3-3-3-7：計算モジュールに記述集約

3-3-1-9-10：全体処理記述子
全体処理遷移矢：全体処理を駆動する遷移矢。通常と同様に単遷移と複遷移の二種類がある。全体処理遷移矢は全体処理記述間を結ぶ事が出来、また外部のグループ遷移カウンタと全体処理記述を結ぶ事が出来る。
準拠矢：遷移矢と同等の操作方法。3-3-1-9-3：メンバスコープで記述された準拠を行う。
トリガコネクタ：トリガコネクタアイコンは全体処理用のステイタスレセプタとステイタストリガそれからメンバ遷移部、メンバ制約部を持つ。トリガとレセプタ（図５０参照）には全体処理遷移矢のみが結合し、メンバ遷移部には3-3-1-9-7：全体処理と全体処理エリア内個別処理の相互作用に従い個別処理あるいは全体処理遷移矢に対してステイタストリガとして働く。メンバ制約部には通常の制限に従い条件が入る。
（全体処理）処理アイコン：全体処理記述内で使用される。通常と同等の機能があるが、張れる属性は全体処理属性（代表値）のみとなる。
グループ遷移カウンタ：このアイコンにはステイタスレセプタ及びステイタストリガが存在し、方法指定部、メンバ制約部が存在する。ステイタスレセプタは個別処理遷移矢のみ受ける事が出来るがトリガは全体処理、個別双方の遷移矢を発する事が出来る。
方法指定部はクリックする事により定数入力、充足率入力二つのフォームが入れ替わり表示される。定数入力モードの時は数値型の属性をドロップする事が出来る。

3-3-1-10：計算モジュール＃シナリオ/計算チャート（図５１参照）＃計算ゾーン
ここでは計算ゾーンを含むチャートを使用した計算モジュールの記述を行う。
計算はユーザ個別処理計算とそれに全体処理を含む計算を加えたメンバ計算がある。全体処理を利用するには全体処理計算ゾーンが含まれたチャートか全体計算モジュール内のチャートである必要がある。
まず基本の個別計算チャート（図５１参照）から説明する。

3-3-1-10-1：（個別）計算チャート（図５１参照）もしくは計算ゾーン
計算用サブモジュールは属するモジュールのシナリオ属性および参加者属性を利用して真偽評価計算もしくは参加者属性の再評価を行うモジュールである。
なお、計算子は計算ゾーン以外には配置できず、またコンテンツも計算ゾーン内には配置できない。個別、全体処理双方に存在。全体処理中の個別計算ゾーンはメンバ計算ゾーンとして該当全体処理のメンバスコープの逐次計算を行う。
最終的にターミナルステイタスが配置されない計算サブモジュールは計算サブモジュールとなりターミナルステイタスが配置された計算サブモジュールが条件サブモジュールとなる。これには属性計算クラスタが含まれていても良い。
この計算モジュールに計算ＴＺで囲まれた計算ゾーンを計算フィールドと呼ぶ。
計算フィールド内ではいくつか特有の記述子が使用される。
計算ゾーンおよび計算モジュールでは計算は遷移時に一瞬で行われる。
属性などは遷移時点でフィックスされ、計算結果が出た後にその他の影響を受ける（開始時系列による最優先処理）。
計算フィールドにおける演算は下記の論理遷移矢を条件フィルタで評価して計算クラスタを構成する代入遷移矢で結ばれた演算を手続き的に実行して行き結果を得る。
またその遷移の終末をステイタスエミッタで修飾し評価されたステイタスを発行して条件計算を同時に行う事が出来る。
・出現パレットの種類
計算モジュール制限の付いたコンテントパレット
属性パレット
処理パレット
ステイタスエミッタパレット
計算子パレット
計算モジュール制限のついたコンテントパレットはコンテンツの内計算モジュールのみが出現する。
論理遷移矢：条件選択や手続き的な計算過程を実現する為に利用される。これは実際のところ通常の遷移矢と同じである。計算ゾーンの場合外部から通常遷移矢を伸ばして計算の評価タイミングを制御する事も可能である。
計算フィールド内特有の結合先としては計算クラスタを構成するアイコンへの接続がある。
論理遷移矢は実計算をすると評価遷移矢と非評価遷移矢が発生する。
代入遷移矢：代入遷移矢は値を取得する属性などと計算子を結びまたその値を代入あるいは利用する属性や条件属性部などを結ぶ。
代入遷移矢で結ばれたアイコン群は計算クラスタを形成する。
起点を代入元、終点を代入先と呼ぶ。また計算子を代入先とする代入遷移矢を入力矢、計算子から代入先に延びる矢を出力矢と呼ぶ。
ドロップされた属性もしくは数値フォームと計算アイコンもしくは計算アイコンと属性、比較条件フィルタの条件属性部、ループカウンタおよび遷移カウンタ数値部を結ぶ事が出来る。なお属性や数値入力フォームから計算子を挟まずに直接属性を出力先として指定すると同値を代入する事になる。
入力矢の起点
属性アイコン
定数入力フォーム
計算子（相手計算子の代入先）
出力矢の終点
属性アイコン
比較条件フィルタの条件属性部
判定値配置部
計算子
計算子：計算子は入力矢の情報を加工計算して出力矢に出力するアイコンである。入力矢を受けるレセプタを一つ以上持ち、出力矢を発するトリガを一ヶ所持つ。
計算子レセプタは単入力と複入力の二種類がありまた機能を推測させる固有の記号を付ける事がある。それぞれの入出力には型情報があり合致した値しか受け付けられない。
単入力のレセプタには一本の入力矢、複入力のレセプタには複数の入力矢を結びつける事が出来る。
例1) 加減乗除べき乗
加算子:Ａ/複入力(数値) Ａへの入力を全て加算。
減算子:Ａ/複入力(数値) Ｂ/複入力(数値) Ａ、Ｂ双方への入力を全て加算、ＡからＢを引く。
乗算子:Ａ/複入力(数値) Ａへの入力を全て乗じる
除算子 :Ａ/複入力(数値) Ｂ/複入力(数値) Ａ、Ｂ双方への入力を全て乗じる。、ＡをＢで割る。
べき乗計算子:Ａ/単入力(数値) Ｂ/単入力(数値) Ａ^Ｂ
例2) 平均値、最大最小値
平均計算子: Ａ/複入力(数値) Ａへの入力全ての平均
最大値計算子: Ａ/複入力(数値) Ａへの入力の最大値を出力。
最小値計算子: Ａ/複入力(数値) Ａへの入力の最小値を出力。
例3) 切上、切下、乱数発生
例4) 文字列結合、文字列切り出し
例5) 論理計算子
記述子: 終末、分岐合流、遷移矢カウンタ、属性パターンフィルタ、比較条件フィルタ、ループカウンタの６種の処理アイコンが使用可能である。
全て論理遷移矢の条件分岐及び手続き的計算を実現する為に利用される。
通常のフィールドと同じように機能する。
定数入力フォーム:入力フォームから値を入力可能で代入遷移矢で計算子に値を送る事が出来る。
計算ゾーン:
計算:以上の要素を組み合わせた論理遷移矢による有向グラフは展開すると
始点 条件分岐
計算クラスタ
条件分岐 条件分岐
計算クラスタ
終末点
評価済み単遷移
計算クラスタ 条件分岐
計算クラスタ
終末点
評価済み単遷移
始点は複数許され、遷移は合流する事も可能だが分解すればこのような樹状グラフとなる。
実際の計算が行われると条件分岐で評価遷移矢沿いの計算が行われて行き終末点か遷移停止に至る。
計算モジュールではこのルート上にステイタスエミッタを配置する事が出来、その場合、条件モジュールとなる。条件モジュールに於いても属性計算は行われ属性値の変更が行われる事がある。
この時別の評価遷移系に同じ属性が入る計算クラスタが有ると結果が保証出来ない。
条件設定などにより同時に評価されない可能性も有るがこの様な事態は警告されるべきである。

3-3-1-10-2:全体処理を含めた属性計算
全体処理計算フィールド:全体処理計算モジュール若しくは全体処理計算ゾーンを全体処理計算フィールドと呼ぶ。全体処理計算フィールドでは全体処理エリア内で使用出来る属性値を利用して個別計算フィールドと同じ計算が出来る。
利用出来る属性
全体処理属性代表値
インスタンス型全体処理属性メンバ属性値
全体処理属性のプロパティ属性化アイコン
メンバ制約情報として利用出来る属性値
メンバスコープを利用した個別計算と全体処理計算の連携:全体処理計算フィールド中の個別計算ゾーン(メンバ制約可能)、メンバ制約部にインスタンス型かグループ型全体処理属性値を置いた全体処理計算ゾーンはメンバスコープのメンバ計算を行う。
また全体処理の代入先への代入遷移矢(それぞれのメンバの個別計算に全体値を代入)、代入元からの代入遷移矢を受け入れる事が出来る。
また全体処理計算フィールド内の計算子の複入力はメンバ計算の結果を受け入れる事が出来、メンバスコープの個別値を全て入力されたものと見做して計算を行う。

3-3-1-10-3：タイミング設定チャートと属性条件チャート＃タイミング設定
タイミング設定チャート（3-3-1-6：タイミング設定）と属性条件チャート（3-3-6-2：参加者タイプ（図３４参照）、メンバ制約部）は計算チャート（図５１参照）の派生形であり出現するパレット及び内容が異なる。
これらのチャートはモジュールでは無くコンテントパレットに収納される事もない。
共通のパレットとして帰結終末エミッタのみが収納されたステイタスエミッタパレットが出現。これらのチャートは条件を判別する為、最終的に終末アイコンの一つ以上に帰結終末エミッタを配置する必要がある。その条件が満たされるとタイミングもしくは属性条件が満たされた事になる。
タイミング設定チャート：値の評価ではなくトリガの計算が含まれる為瞬時では無くトリガ情報の生起に従って段階的に行われる。それに伴い属性パターンフィルタのモードの解釈が一部異なる。
AND処理：二つ以上のトリガがふくまれる場合、すべてが発生して初めて評価が行われる。
OR処理：二つ以上のトリガがふくまれる場合いづれか一つが発生すれば評価が行われる。
・パレットの種類
属性パレット
処理パレット
ステイタスエミッタパレット（帰結終末のみ）
トリガパレット
全体処理エリアでは処理エリアで可能な要素が出現する。
属性条件チャート：属性条件を指定する必要のある部分で出現する。
出現場所
メンバ制約部
参加者属性条件
・パレットの種類
属性パレット
処理パレット
ステイタスエミッタパレット（帰結終末のみ）
出現場所によって属性パレットの内容が変わる。
メンバ制約部は通常の場所の制限に従った属性が出現（スコープ、全体処理エリアか？）。
参加者属性条件ではインポート可能な保存属性が真偽値型として収納される。

3-3-1-11： コンテンツログ＃ログコンテンツ表示
終了したコンテンツはコンテンツログとしてユーザイベントホームから閲覧可能となる。シナリオ進行上の機能は失っていてフォームおよびステイタスリンクは機能を失い、外部連携からの属性とステイタス変更は受け付けなくなる。その他のリンクや映像閲覧機能などは残る。

3-3-1-12:ログの記録＃ログ管理
ログはシナリオ構造に従ったユーザ或いは全体の履歴として構造化言語で記述される。モジュール処理へのエントリと離脱記述の間にそのモジュールで発生したイベントが時間場所情報と共に記載される。
詳細なログ、コンテンツデータは管理者側のコストで保管。
ユーザは参照用及び最低限のログを保持。
ユーザが詳細な情報を必要（自動ブログ生成時など）とする時は管理者側がそのデータを開放若しくは保持している場合、参照可能となる。

3-3-1-13：参加者タイプ（図３４参照）＃参加者タイプ（図３４参照）決定プロセス
参加者タイプ（図３４参照）は保存属性をインポートした参加者属性情報からタイプ分けされ、（可能なら）ユーザの選択によって決定されるイベント中での可能な行動を規定するタイプ情報である。参加者は自分の参加者情報を特殊記事で確認できる。
代表属性（真偽）でシナリオ中では制御される。

3-3-2：シナリオ（メイン画面）
括り付け
管理者ID
シナリオID
必須の画面要素
１） 特殊記事表示ブロック
１−２）特殊記事タブ
１−３）配信アイコン
１−４）メイン画面
１−５）タイプ設定バー
２） 特殊処理ブロック
２−１）モジュール化
２−２）概形チェック
２−３）イベント登録
２−４）シナリオ削除
３） シナリオタグ編集
４） 参加者タイプ（図３４参照）リスト
４−１）参加者タイプ（図３４参照）名称
４−２）説明
４−３）必須属性
４−４）再編集
５） 作成ログ
６） シナリオ構造表示ボタン
a)１）特殊記事表示ブロックについて
シナリオの特殊記事（2-4-2：特殊記事参照）を管理するブロック。１−２）のタブで選択された特殊記事が１−４）メイン画面に表示される。この時シーケンス番号をどこかに表示する事。また１−５タイプ設定バーのチェック項目もタブの選択に従って変化する。
タブの最後には新規制作のタブがあり選択するとタイプをチェックした後にクリックとの表示のあるブロック画面が現れる。チェック後にクリックすると3-3-5-11：特殊記事を編集するモードの図１９の記事編集画面に遷移。
１−３）配信アイコンは2-3-2：イベント利用時の遷移についての該当記事のタイプが配信可能なタブが選択されている時に表示される。＃メール配信
b)２）特殊処理ブロックについて
２−１）モジュール化：作成したシナリオをコンテントのモジュールとして編集できる。内容をコピーしたネストシナリオ画面に遷移し、ターミナルトリガを配置する。またライブラリに登録も選択可能。＃ライブラリ遷移
２−２）概形チェック：シナリオの概形チェックを行う。3-3-8：概形チェック参照＃概形チェック
２−３）イベント登録：作成したシナリオを実現可能シナリオリストに登録する。概形的チェックが行われ、不適合ならこの画面に差し戻される。＃シナリオ遷移制御＃概形チェック
２−４）シナリオ削除は該当する作成中のシナリオを削除しメイン画面に戻る。
c) ３）シナリオタグ編集について＃タグ-属性転換機構
公式タグのリストが表示され選択されると表示される。
d)４）参加者タイプ（図３４参照）リストについて＃参加者タイプ（図３４参照）決定プロセス＃保存属性管理
3-3-6-2：参加者タイプ（図３４参照）で登録された内容を表示する。必須属性は2-8-4:保存推奨属性2-2で保存属性の必須条件を抽出したのと同じ方法で必須属性を抽出してリスト化。（NOT/OR条件で無く全ての条件分岐でAND条件）
４−４）再編集では列の該当する3-3-6-5：参加者タイプ（図３４参照）登録/編集画面に遷移。
e)作成ログはシナリオ作成（図４９参照）の編集履歴をスクロールで確認できるようにするものである。＃ログ管理
１：要素の追加/削除
２：状態遷移
３：テスト/チェック結果

3-3-3：シナリオチャート
図２１参照。シナリオチャート作成画面。
括り付け
管理者ID
シナリオID

3-3-3-1：画面の基本構造
画面は大きく分けてメインエリアと上部のユーティリティバーに分かれる。
メインエリアは基本的にチャートが拡がり、その上に各種パレットが乗っている形になる。パレットの位置は可変である。デフォルトでは画面の左サイドにパレットを配置してパレットエリアとする。
必須の画面要素
ユーティリティバー
１） 新計算モジュール
２） 新記事
３） 新モジュール
４） 新シナリオ属性
５） シナリオ属性管理
６） プライベートライブラリ
７） 標準化ライブラリ
メインエリアは次項以降

3-3-3-2：チャートエリア（チャートの説明）＃シナリオ/計算チャート（図５１参照）
シナリオチャートが表示。
3-3-3-3：パレットエリア（パレットの説明）＃パレット
チャート画面でのパレットはメインエリア上に展開可能で初期は左サイドに整列している。
コンテントパレット
属性パレット
処理パレット（代入遷移矢が非表示）
管理者トリガパレット
がシナリオチャートでは表示される。

3-3-3-4：ユーティリティバー
１）新計算モジュール
3-3-3-7：計算モジュールの編集画面が開き、同時にコンテントパレットに該当モジュールを定義モジュールとして登録される。＃定義/スコープ
２）新記事
3-3-5-4：記述画面が開き同時にコンテントパレットに該当モジュールを定義モジュールとして登録される。＃定義/スコープ
３）新モジュール
3-3-4-1：ネストタイプモジュール編集画面が開き該当モジュールを定義モジュールとして登録される。＃定義/スコープ
４）新シナリオ属性
3-3-3-8：シナリオ属性登録プロセスが開始され該当モジュールを定義モジュールとして登録される。＃シナリオ属性登録プロセス＃定義/スコープ
５)シナリオ属性管理
属性パレットの範囲の属性リストが呼び出される。3-3-7-2:シナリオ属性リスト参照。＃コンテンツリスト（切り出し）
６)プライベートライブラリ＃ライブラリ遷移
3-3-4-4：ライブラリ利用のプライベートライブラリに遷移する。（該当モジュールのID情報を持って）
７）標準化ライブラリ＃ライブラリ遷移
3-3-4-4：ライブラリ利用の標準化ライブラリに遷移する。（該当モジュールのID情報を持って）

3-3-3-5：シナリオ属性登録プロセス＃シナリオ属性登録プロセス
遷移制御モードのシナリオ属性を選ぶ画面に通常のタイプ選択画面がリンクされた形で型選択を行い、名称を登録する。
1) 遷移制御モード属性選択画面:マーカタイプ(真偽値型)、カウンタタイプ(数値型)の二つのリスト選択と詳細型選択画面へのリンクが表示。
2) 詳細選択画面: 3-3-1-3-3：シナリオ属性、3-3-1-3-5：全体処理属性の全ての型のリスト選択が表示される。
3) 登録画面:型の選択が為されると名称入力画面が現れ入力を行うとシナリオ若しくは全体処理属性が登録されアイコンが属性パレットに出現する。
名称はアルファベット1?2文字の自動付号名称がフォームに入っている状態。

3-3-4：モジュール
新モジュールで呼び出される登録画面はネストタイプのモジュールの作成画面である。
またサブナヴィのモジュール作成を選択するとモジュールのコンテントリスト（図３２参照）が開き、リストの最後に新規作成ボタンが現れる。ここで作成されるとスコープはシナリオとなる。＃コンテンツリスト（切り出し）＃定義/スコープ
例外管理作成はモジュールオプションの例外管理を選択すれば処理パレットに管理者コールが出現し、例外管理作成画面となる。
外部モジュールは標準化ライブラリから引っ張ってくる必要がある。選択したライブラリはテンプレートとしてテンプレート画面に登録される。
3-3-1-2-3：通常モジュールと例外管理参照。
括り付け
管理者ID
シナリオID
コンテンツID

3-3-4-1：ネストタイプモジュール
ネストタイプのモジュールの編集画面の説明。
必須の画面要素
１） ユーティリティバー
１−１）新計算モジュール
１−２）新記事
１−３）新モジュール
１−４）新シナリオ属性
１−５）シナリオ属性管理
１−６）モジュールオプション
１−７）プライベートライブラリ
１−８）標準化ライブラリ
１−９）配置モジュールへ
２） メイン画面
２−１）モジュールチャート
２−２）パレット
a) ユーティリティバー
1-1〜1-5項シナリオチャートと同じ。定義モジュールが開いたモジュールになる。
１−６）モジュールオプション
クリックすると以下のアイコンの収納されたパレットが現れる。
1：隠ぺい
2：可変化
3：フィルアップ
4：定義モジュール変更
5：例外管理化
6：高度管理化
7: 時制検索編集フォーム
説明
1：隠ぺい：指定（クリック）すると内部定義のコンテント、サブ要素やシナリオ属性がコンテントリスト（図３２参照）上に記載されなくなる。再クリックで
2,3:可変化及びフィルアップ：3-3-4-4：テンプレート化参照。可変化はクリックするとマウスポインタが可変化モードに変化。再クリックで解除。フィルアップはクリックするとテンプレートの定義モジュールのパレット内にクラスが生成されて該当編集画面に移行。
3-3-1-2-1-1：テンプレートとフィルアップ参照。＃クラス/テンプレート＃マウスポインタモード

4：定義モジュール変更：コンテントリスト（図３２参照）が呼び出されモジュールもしくはシナリオアイコンを選択すると変更。（シナリオ構造表示でも可）＃定義/スコープ

5：例外管理化：指定すると例外管理にモジュールのタイプが変更になる。処理パレットに管理者コールアイコンが出現する。
6：高度管理化：3-3-1-2-1-2：コンテントの状態で詳述した高度管理コンテントとなる。指定中は画面隅に選択拘束ボックスが出現しここに配置済みエミッタを一つ以上配置する事が必要となる。＃コンテント状態制御
7:時制検索編集フォーム：モジュール内の隠ぺいされていないモジュールのタイムゾーン、強制終了のタイミング設定トリガ記述を呼出し記述の変更を一括して行う事が出来る。通常のワープロソフトの検索置換処理のように記述を一覧表示、選択した記述をその場所だけあるいは一括して変更できる。＃時制検索編集フォーム
１−９）配置モジュールへ
クリックすると定義モジュール、配置モジュールのリストが出現。選択するとその編集画面に移動。
b) メイン画面
シナリオチャートと同様の機能を持つが、ステイタスエミッタの配置と要素の可変化が行えるようになる。ステイタスエミッタは以下の場所に配置可能（図２８参照）。＃遷移制御
ターミナルステイタス
評価ステイタス
終了レセプタ
コンテント開始時
遷移未開始
トリガレセプタ
タイムイン
タイムアウト
フィールドイン
フィールドアウト
強制終了レセプタ上
処理アイコン（評価開始時/カウンタータイプは評価開始時と終了時：アイコン上部と下部）
出現パレット
コンテントパレット
属性パレット
処理パレット
管理者トリガパレット
ステイタスエミッタパレット

3-3-4-2：例外管理
イベントの進行上重点的に管理するべきモジュールは例外管理に指定できる。基本的には通常のシステムによる進行が困難になりそうなモジュールを指定する。
例外管理モジュールのタイプ選択を受けたモジュールはイベントモニタ（図１１参照）で特別扱いされ、常時モニタされる。
また管理者コールが処理アイコンとして配置可能となり（アイコンとしての扱いは終末アイコンと同等）ユーザと直接コンタクトを取る事が可能となる。イベントモニタの管理者コール機能参照。

3-3-4-3：外部モジュール＃外部連携
外部モジュールはユーザ向けのサービス提供画面と管理者向けのプロパティ管理画面を持つ外部のＡＰＩである。
挙動はモジュール（コンテント）としての制限に従うよう求められる（テンプレートとして出現）。
コンテントに必要なステイタスが発行される。
終了ステイタス
開始
開始未達
サービス提供画面についてはユーザ向けコンテンツ画面の仕様に従うよう求められる。
プロパティ管理に求められる仕様。
必須
フィルアップが可能
定義モジュール変更

推奨
例外管理化が可能
高度管理化が可能（管理者側のコントロール可能）
可変化
関連参照リスト呼出し
ライブラリアクセス
グラフィカルなインターフェイス
プロパティ指定に必要な種類の新要素定義（計算モジュール、モジュール、シナリオ属性、記事など）
パレット（コンテント、属性、エミッタ、ライブラリデータ）
ステイタスエミッタレセプタ
コンテントレセプタ
属性レセプタ
データレセプタ

3-3-4-3-1:外部トリガ記述モジュール（ＯＳＴＭ）＃外部データ利用
外部トリガとして指定可能なイベントのリストから選択発生条件を設計する。外部モジュール。
OSTMは配置されるとライブラリデータパレットを呼び出す。このパレットは機能制限があり、外部トリガとして登録されたデータしか表示されない。
プロパティ画面は基本的にデータレセプタしか存在しない。
またデータに（個別ID以外の）プロパティがあるトリガを受け取る為に属性レセプタのあるタイプも存在しうる。
このレセプタに外部トリガのデータアイコンを配置するとイベント時このモジュールの生存期間中に外部トリガが発生すればトリガが発行される。
個別ベント内では個別ユーザＩＤを乗せる機能のあるＯＳＴＭは別ＩＤを無視する。
タイミング設定チャートを呼び出す複雑な制御を行うモジュールもある。＃タイミング設定
この場合、外部トリガはトリガと同じ扱いとなる。
外部トリガの種類
グルーバルトリガ
RSS
ユーザ情報付RSS＊
連携システムからのデータ
ユーザ情報付データ＊
端末アクション＊
二次元バーコード読取
アプリ入力
＊のある外部トリガはユーザ情報を持つ。

3-3-4-3-1-1：エントリィトリガとローカルエントリィ
外部トリガにユーザの個別シナリオインスタンスを生成する機能を付与したものをエントリィトリガと呼ぶ。データの種別によって個別IDの指定があるものと無い物がある。
無いエントリィトリガはその時点で参加状態のユーザ全てに個別シナリオインスタンスを生成する。
エントリィトリガは複数の階層に複数を配置可能。ユーザＩＤと組み合わさり最初に発生したエントリトリガがそのユーザの個別インスタンスを発生させる。その時点で他のエントリトリガは単なる外部トリガと見做される。二層以下のエントリィトリガもその階層での個別インスタンスを発生させる。
エントリィアイコンは無設定のままでも次の使用法が行える。
１：第一層にエントリィイベントが記述されていないが下位階層にエントリィアイコンが配置されている場合、そのままでは単なる外部トリガ扱いになってしまう。第一層にブランクのエントリィトリガを配置すると下位のエントリィトリガアイコンの生存中に生成トリガが発生すればエントリィが発生する。
２：フィールドゾーンの付随トリガにブランクのアイコンを配置するとそのトリガでエントリィを発生させられる。
ローカルエントリィは端末アクション、フィールドインのみを受け取るエントリィトリガで登録ユーザはその場でローカルエントリィプロセスを開始する（ただちにエントリィとはならない場合がある。）。＃ローカルエントリィプロセス

3-3-4-3-1-2：ユーザチェック関連モジュールと利用プロセス＃遷移制御＃二次元バーコードページ生成＃ユーザチェック
参加者携帯端末アプリを利用して、管理者ユーザと一般ユーザ、一般ユーザと他の一般ユーザとの間で相互に接触確認プロセスを設ける。
ユーザチェックをシナリオ中で利用する為の仕組み。
二種類のモジュールが関連
ユーザチェックモジュール
全体処理化ユーザチェックモジュール
特別ＱＲページ発行モジュール
１：管理者側とのユーザチェック処理
管理者が特定のモジュールでユーザチェックをトリガとして使用したい場合。
1-1：管理者はプレーンフィールド、あるいは範囲を限定したい場合はＴＺ内やＦＺ関連付けメンバ制約を行ってユーザチェックモジュールをチャート上に配置できる。
1-2：配置されたモジュールは設定でクラスに対してユニークなユーザチェックコードを発行する。
1-3：管理者はスタッフの端末アプリ、或いは連携機器でユーザチェックコード受け入れ可能なインターフェイスを持つ対象にユーザチェックコードを入力する。
これによってその機器がそのユーザチェックモジュールのクラスと関連付けられる。
1-4：該当機器のいずれかと制約内のユーザがローカルコンタクトを取るとそのクラスの配置モジュールからトリガが発行される。（注意してほしいのは配置されたモジュールやコンテキストが異なれば条件を満たすモジュールのみで発行が行われると言う事である）。
２：ユーザ同士のユーザチェック
特定のコンテキスト同士のユーザがユーザチェックを相互に行うとグルーピングが発生する。グループ型全体処理属性をプロパティに配置する事によって二ユーザの組のグルーピングがなされる。また条件によって双方の処理を変えることも可能（スタッフによるチェックの第二の方法）。中で条件設定をしないならＡステイタスにグループ型属性を割り付けてもグルーピングは可能。
2-1：全体処理化ユーザチェックモジュールを全体処理エリアに配置して挙動制御。
2-2:子ユーザチェックモジュールを指定可能な個別処理エリアに配置。
2-3：プロパティでＡ対象とＢ対象のメンバ制約部に条件を配置。
2-4：同コンテキスト同士のユーザチェックが行われたらＡ条件とＢ条件をそれぞれに走査する。入れ替えて双方全てが成立しないならユーザチェックは否定。対象外の通知。条件付けが双方空欄の場合は全てＡステイタスから遷移。
2-5：結果（成立した場合）
１ユーザ：Ａ 2ユーザ：Ｂ ＞ １ユーザ：Ａ 2ユーザ：Ｂ
1ユーザ：Ｂ 2ユーザ：Ａ ＞ 1ユーザ：Ｂ 2ユーザ：Ａ
１ユーザ：ＡＢ ２ユーザ：Ａ ＞ 1ユーザ：Ｂ 2ユーザ：Ａ
１ユーザ：ＡＢ ２ユーザ：Ｂ ＞ １ユーザ：Ａ 2ユーザ：Ｂ
１ユーザ：Ａ ２ユーザ：ＡＢ ＞ １ユーザ：Ａ 2ユーザ：Ｂ
１ユーザ：Ｂ ２ユーザ：ＡＢ ＞ 1ユーザ：Ｂ 2ユーザ：Ａ
１ユーザ：ＡＢ ２ユーザ：ＡＢ ＞ ランダムで割り付け
2-6：割り付けられた全体処理属性でグルーピングされ、グループキーが割付けられ る。
2-7：ステイタスが割り付けられたユーザはＡ，Ｂいずれかでトリガが発行される。
特別ＱＲページ発行モジュールを配置するとそこを踏んだ時点で特別ＱＲページが配信される。シナリオのＱＲページは待機状態に。
プロパティでモジュールを指定ＱＲページとして落とすとそれでもコンテキストを制限できる。

3-3-4-3-2:ガイドモジュール
上記の仕様に従って特定地点にユーザを誘導するガイドモジュールを作成する。サービス上重要。

3-3-4-3-3:ページアダプタ
URLをライブラリデータ化すると特定のウェブページを外部モジュール化出来る。
基本的にメッセージ扱いとなる。生成トリガが発生すると相手先ページを呼び出し表示する。
コンテントページに取り込んで表示するかリンクするか設定で選択可能となる。
3-3-4-3-4:会場機器管理システム
会場に設置したAV機器などの操作を外部モジュール化したもの。
管理用のプロパティ画面とコンテンツやユーザ提供情報などをを利用する為のデータレセプタ、属性レセプタが必要となる。
＃シナリオ挙動
3-3-4-3-5:シナリオステイタスレセプタモジュール
評価されるとシナリオステイタスを発行または遷移先のエントリィトリガのライブラリデータを含んだ設定チャートで指定して参加者についてシナリオを越えて遷移させる。
全体処理配置ではその時点のメンバスコープ全てに遷移を発生させる。
配置されるとシナリオ画面に表示され、実現可能となるとシナリオステイタスとなるライブラリデータを生成する。

3-3-4-4：テンプレート化＃クラス/テンプレート
モジュールにおけるテンプレートではコンテンツと属性、フィールドゾーンを可変アイコンとして指定可能。これらは一か所を指定すると同一クラスの全ての配置が可変アイコンとなり、一か所をフィルアップすれば同一の要素が反映。

3-3-4-5：ライブラリ利用＃ライブラリ遷移
3-4-5：ライブラリ参照。チェックしたコンテンツをライブラリ登録。

3-3-5：記事/メッセージ
シナリオは記事(と外部モジュールのサービス画面)を参加ユーザに適切な場所と時間、条件で配信する為に存在している。記事はユーザと主催者のコミュニケーションの基本となる。
記事の機能
１：記事を参加者に読ませる
２：画像、映像を参加者に閲覧させる
３：フォームに入力させる
４：埋め込み画面パーツを利用させる
５：外部リンクを踏ませる
６：参加者に行動を選択させる
その為重要な配信には状態管理を導入し、配信に対するユーザのリアクションがイベントの進行にとって正規行動なのか不正規行動なのか、例外が発生したのか判別出来るようにした。記事状態遷移に詳細。

3-3-5-1： ユーザ画面＃記事記述-ユーザイメージ転換
ユーザ画面は画面の何処かにチェックボタンのある(メッセージ以外)ブログ記事に見える。
ユーザ画面のサブ画面、或いはフル画面表示で表示され文章や映像などの閲覧、フォーム入力、リンクや選択などを行える。
記事の読了後はチェックボタンを押して確認するよう推奨される。
枠外などにメッセージ表示。
チェックボタンが押されて記事が正式に閉じる為に必要な作業がある場合がある。この場合は必要な作業を行わずにチェックするとその旨が表示される。
必要な作業が何かは明示される場合も有れば明示されない場合もある。チェックが選択されると確認メッセージが表示される。

3-3-5-2：記事状態遷移＃コンテント状態制御
記事の状態管理を実施する為に記事には幾つかの種類が存在し、イベント実行時のステイタスの発行状況によって幾つかの状態に変化する。
記事の種類 例外発生選択 選択拘束あり
1)メッセージ なし なし
2) 状態有記事 あり なし
3) 選択拘束付状態有記事 あり あり
2)、3)のタイプは閲覧管理を行う事により状態が発生する記事であり、１をメッセージ、２以降を記事とコンテンツの種類を分ける（操作、作成方法は同じ）。
選択拘束付状態有記事は高度管理指定コンテントに当たる。
記事状態遷移 A)正規ST/ B)不正規ST/ C)未発生 F)終了/O)表示中 状態
メッセージ A/B/C F/O メッセージ表示済み
状態有記事 A F 正規終了記事
A O 正規発生済記事表示中
B F 不正規終了記事
B O 不正規発生済記事表示中
C F 待機記事
C O 不正規発生済記事表示中
選択拘束付状態有記事 拘束選択A F 正規終了記事
拘束選択A O 正規発生済記事表示中
拘束選択B F 不正規終了記事
拘束選択B O 不正規発生済記事表示中
A F 待機記事
A O 記事表示中未選択
B F 待機記事
B O 記事表示中未選択
C F 待機記事
C O 記事表示中未選択
状態：各状態はタイムゾーンにタイムアウトを発生させるか、また正規、不正規、例外のどの処理を受けるかで評価される。
メッセージ表示済み：メッセージが配信された時点でこの状態となる。ステイタスなどを発行しても良いがそれが記事の状態に影響を与えず、記事が閉じられるとすぐに正規終了となる。タイムアウトを発生しない。
正規終了記事：正規処理がなされて記事が閉じられた事を示す状態。正規終了、タイムアウトを発生しない。正規処理済み。
正規発生済記事表示中：正規処理が為されたけどまだ記事が閉じられていない状態。閉じられると正規終了、タイムアウトを発生しない。正規処理済み。
不正規終了記事：不正規処理がなされて記事が閉じられた事を示す状態。不正規終了、タイムアウトを発生しない。不正規処理済み。
不正規発生済記事表示中：不正規処理が為され記事が閉じられていない状態。不正規終了、タイムアウトを発生しない。不正規処理済み。
記事表示中未選択：記事が開いているが拘束選択が為されて居ない状態。閉じられると待機状態となる。タイムアウトを発生させる。
待機記事：待機状態となって表示中の一覧からは外れているが呼び出されるとステイタスを発行可能な記事。状態有記事の場合は不正規処理済みと見做され、選択拘束が付いているとタイムアウトを発生させる。

3-3-5-3：ターミナルステイタス/チェック/選択拘束＃遷移制御
記事やメッセージはコンテントとしてターミナルステイタスを発行可能である。また閲覧管理をユーザに意識して貰う為にチェックボタンに機能の前提となる操作情報を登録出来る様にした。更にイベント進行のソリッドな管理を行える様に選択拘束機能を持つ。
これらの機能の詳細決定を行うのがターミナルステイタスエミッタである。
エミッタそのものの説明は%%を参照。
記述画面でエミッタを配置可能な場所
1)チェックボタン
2)記事配信完了
3)閲覧終了
4)ステイタスエミッタレセプタ
5)外部リンク記述画面パーツ
6)ステイタスリンク記述画面パーツ
同じエミッタを複数の場所に配置した場合、何処かでイベントが起こればターミナルステイタスは発行される。
チェックボックス:チェックボックスには配置済みのエミッタをドロップする事が出来る。ドロップされたのと同じ種類のエミッタが全て踏まれた時点でチェックボタンが機能し始める。何も無いボックスは前提条件無しでチェックボタンを機能させる。
チェックボタンが使用可能になると「チェック可能」のインフォームと共に強調表示。不能時にクリックすると「条件を満たしていません」のインフォーム。
ボックス内のテキストフォームでインフォームを編集可能。
拘束選択ボックス:拘束選択ステイタスを設定するボックス。指定する配置済みのステイタスエミッタをドロップ可能。ここに配置されたステイタスの何れかが発行されないとTZが閉じるまで終了状態になれない。またその場合でも例外終了となる。

3-3-5-4：記事記述画面
画面構成:上部にユーティリティバー、下部に記事メインパートとパレットが配置される。
パレットは可動で下部内なら自由に移動出来る。

3-3-5-4-1：画面パーツ＃記事記述-ユーザイメージ転換＃遷移制御
映像や入力フォーム、リンク、プラグイン、選択を記事画面中でユーザが行う為に画面パーツを記事に組み込む事が出来る。
画面パーツは画面パーツパレットに収納されDDによって記事の可能な部位に配置される。
ユーザイメージと記述フォーム、レセプタタブ:画面パーツは種別のイメージと種別名でパレット上には存在する。これを記事に配置すると記述フォームとレセプタタブが開かれる。これは占有スペースと異なっているのでユーザイメージアイコンをクリックする事によってその時点の編集によるユーザイメージが指定位置に出現する。記述フォームアイコンをクリックすると編集に戻る。
記述フォームは画面パーツの内容を編集するエディタで種類毎にインターフェイスは異なる。
レセプタタブは属性レセプタとステイタスエミッタレセプタ、データレセプタをまとめてタブ状にしたもので記述フォームの周辺に自動配置される。
チェック確定プロパティ:入力系の画面パーツにはチェック確定プロパティが存在する事が多い。このプロパティが設定されるとフォーム入力時では無く、チェック時にエミッタが踏まれる。その間は入力内容を変更出来る。＃遷移制御
択一選択グループ：ある入力画面パーツで同種類のものが複数配置されている場合、複数をグループ化して択一選択をさせる事が出来る。この場合、自動的にチェック確定プロパティとなる。
択一設定：プルダウンで同種の配置済み入力フォームのタイトルが表示。選択すると択一設定がリストアップされてゆく。＃遷移制御
ステイタスエミッタレセプター：フォームの返り値を数個に類型化してターミナルステイタスを張り付けられるようにする。
例
１：正常終了
２：不正終了
３：リクエスト
それぞれのレセプタにはチェック確定プロパティが存在する（クリックすればチェック確定モードに）。発生時もしくはチェック時に落とされたターミナルステイタスが発行される。
チェック確定属性ありのレセプタは番号の若いレセプタのステイタスが優先される。

3-3-5-4-1-1:画面パーツの種類
映画像コンテナ:ライブラリデータパレットから映像、画像、音声データを受けて再生する機能を持つ。
配置されたデータをシーケンスに再生して行く。画像はスライドショウ。一枚のみ単なる静止画。
最初に落とされたデータの種類で受け入れデータ種別を判別。
ユーザイメージでは静止画は枠なしの画像。
映像、スライドショウでは表示部の外に枠を入れ、再生、停止、早送り巻き戻し、前後のデータのコントロールボックスが枠クリックで表示。
設定では規定視聴時間、ランダム再生が選択出来る。
規定視聴時間:設定すると時間入力フォームが現れ時間を入力出来る。ユーザ側では規定時間サービスが提供されると枠が強調される。
ランダム:設定されると放映順がシーケンスでは無くランダムに変わる。
レセプタタブ:データレセプタ*2、ステイタスエミッタレセプタの三つ。
データレセプタは一種類のデータアイコン、データ型属性を落とせる。最初５程度の枠で埋まると拡張されて行く。この並び順が再生シーケンスとなる。
入ったデータは記述フォームでサムネイルをクリックする毎にサムネイルがシーケンスで切り替わる。ダブクリで再生可能なデータは再生。
データレセプタ２＃外部データ利用
パラグラフ装飾用のCSSデータをドロップ可能。
ステイタスエミッタレセプタ
静止画:ロード成功/ロード失敗
他:完全再生/再生/例外/ロード成功/ロード失敗/(規定視聴時間クリア)
属性入力フォーム：属性値をユーザが入力する為のフォーム。
同種のフォームは択一選択グループを形成できる。
入力フォームの種類
テキスト入力：文字列
選択ボタン：真偽/（択一選択グループならリスト型文字列も入力可能）
チェックボックス：真偽
数値入力フォーム：数値
ボタン：真偽
ユーザイメージはフォームとタイトル。
記述フォームはタイトル入力フォーム。
チェック確定プロパティ設定可能。
択一選択グループ設定可能。
レセプタタブ
属性レセプタ（一つ）
ステイタスエミッタレセプタ
反映成功/入力/例外
データレセプタ＃外部データ利用
パラグラフ装飾用のCSSデータをドロップ可能。
属性別記述フォーム：配置パラグラフに参加者属性別の記述を反映させる。
ユーザイメージはパラグラフ（最大入力文字数）。
記述フォームはタブに属性名の書かれたフォーム。タブを選択すると該当属性のフォームと今までの入力内容が表示。
レセプタタブ
複数の属性レセプタ
属性がドロップされると記述フォームのタブが増える（遷移制御モードで真偽値として判定）。複数の属性が当てはまるのは属性レセプタのシーケンス順に優先される。
データレセプタ＃外部データ利用
パラグラフ装飾用のCSSデータをドロップ可能。
属性がブランクでも一枚のフォームは存在。これでパラグラフの画面パーツ化を行う。
外部リンク記述フォーム：外部ＵＲＬへのリンク記述フォーム。ユーザイメージは下線の強調表示文字列。
記述フォームはタイトル入力とＵＲＬ入力の文字列入力フォーム（ＵＲＬ形式チェック）
チェック確定プロパティ設定可能。
レセプタタブ
ステイタスエミッタレセプタ
リンク踏み
データレセプタ＃外部データ利用
パラグラフ装飾用のCSSデータをドロップ可能。
ステイタスリンク記述フォーム：ユーザイメージではクリックするとサブミット画面が現れタイトルの選択をしたことを確認させる文字列を表示（選択後は強調表示）。
記述フォームはタイトル文字列入力フォーム。
チェック確定プロパティ設定可能。
択一選択グループ設定可能。
レセプタタブ
ステイタスエミッタレセプタ
サブミット
データレセプタ＃外部データ利用
パラグラフ装飾用のCSSデータをドロップ可能。＃遷移制御
埋め込み連携オブジェクト：ライブラリに外部モジュールをこの形式で登録可能。
ユーザイメージ、記述フォーム、レセプタタブの仕様を守る必要。
外部埋め込みフォーム：外部の埋め込み用のデータを配置可能。SNSなどの埋め込み画面がユーザイメージとなる。＃外部連携
https://dev.twitter.com/web/sign-inhttps://dev.twitter.com/ja/web/embedded-tweetsなど
リンクを踏んだり再生など操作を行うとステイタスが発行される。＃外部データ利用
レセプタタブ
ステイタスエミッタレセプタ
データレセプタ１
埋め込み記述のリンク先記述をドロップ。
データレセプタ２
パラグラフ装飾用のCSSデータをドロップ可能。
チェックボタン：チェックボタンは独特のイメージのボタン。
ユーザイメージ、記述フォーム、レセプタタブの仕様を守る必要。
チェックボタン：チェックボタンは独特のイメージのボタン。
ユーザイメージはボタンとクリック、ドラッグオーヴァー時のインフォーム。
記述フォームはドラッグオーヴァー、条件未達クリック、条件達成クリックのインフォーム用文字列入力フォームがタブ形式で。条件が無い場合、条件未達クリックは表示されない。
レセプタタブ
ステイタスエミッタレセプタ
サブミット
条件達成クリック/条件未達クリック
データレセプタ＃外部データ利用
パラグラフ装飾用のCSSデータをドロップ可能。
画映像アップロードフォーム：ユーザは撮影した自己端末内の画映像データをアップロード出来る。撮影端末は携帯かスマホに限られ、画像の撮影時間チェックも行われる。
デフォルトの設定は該当記事の生成時間内で有る事。時間制限はユーザイメージに明記される事。設定でタイミング設定チャートを呼び出して詳細な指定をする事も出来る。その場合、現時点がタイミング未到来の場合、その旨の表示がユーザイメージに示される。
属性に入力する場合はデータ型のシナリオ属性のレセプタに配置。
＃外部データ利用
レセプタタブ
ステイタスエミッタレセプタ
アップロード成功/不適切データ/アップロード失敗/タイミング到来
属性レセプタ(データ型用)
データレセプタ＃外部データ利用
パラグラフ装飾用のCSSデータをドロップ可能。
特殊記事用画面パーツ：以下の種類がある。
レセプタタブはパラグラフ装飾用のデータレセプタのみ。
参加者タイプ（図３４参照）選択入力フォーム：可能な参加者タイプ（図３４参照）（付与タイプ含む）のリストとサブミットボタンが必要。
保存推奨属性登録フォーム：属性値を含む推奨属性のリストと選択チェックボックス、サブミットボタン。
二次元バーコード表示パーツ：二次元バーコード表示、コード表示、コード入力フォーム。
二次元バーコードタイトル表示パーツ：二次元バーコードタイトル。
緊急チャットフォーム：チャット窓。

3-3-5-5：記事メインパート
記事メインパートはユーザ画面編集部とボックス部に分かれる。
ボックス部は記事の遷移制御や画面構成の為にエミッタや修飾データを落とす事が出来るスペースである。
選択拘束ボックス
チェックボックス
記事配信完了ボックス
閲覧終了ボックス
修飾データレセプタ
がある。
ユーザ画面編集部はブログの編集画面と同じでプレーンの記述用のパレットとエディタが存在している。
既存のブログエディタをプラグインする仕様が望ましい。(管理者顧客やシステムに組み込む提携者の使用システムを流用したい。例:SNSの記事編集の追加サービスに当システムを使用する)。
この編集画面に画面パーツをドロップ出来、画面パーツ配置部にはエミッタをドロップ可能とする。またデータのアップロードは当システムのライブラリ経由とする制限を掛ける(プロセスのショートカットは組み込んで良い)。
ボックス部
選択拘束ボックス、チェックボックス：3-3-5-3：ターミナルステイタス/チェック/選択拘束で詳述。
記事配信完了ボックス：記事画面が全てロードされるとここに配置されたステイタスが発行される。コンテント生成はインスタンス生成時に発行されるので若干タイミングがずれる。
閲覧終了ボックス：外的な要因（タブ削除、例外発生）含め記事が閉じられた場合閲覧終了となる。単にブラウザが閉じられても反応しないがアイコンをクリックするとブラウザの閉鎖にも反応するように出来る。
修飾データレセプタ：データパレットの修飾データをここに落とす事が出来る。修飾はユーザイメージのプレヴューで確認できる。

3-3-5-6：パレットエリア＃パレット
デフォでは画面左端にパレットが集められ、記事メインパートがその他の部分を占める。パレット自体は移動可能。
展開するパレット
1) 画面パーツパレット
2) ライブラリデータパレット
3) 属性パレット
4) ステイタスエミッタパレット
a)説明
1) 画面パーツパレット
基本の画面パーツおよび、ライブラリよりインポートされた画面パーツが収納される。
2) ライブラリデータパレット
ライブラリに登録された画面パーツで使用可能な形式のデータが収納される。反映されるためにはライブラリ側でインポート作業が必要とされる。DDで画面パーツのデータレセプタに落とすと反映される。＃外部データ利用
3) 属性パレット
通常の属性パレット。スコープで利用可能な属性がリストアップ。
4) ステイタスエミッタパレット
通常のステイタスエミッタパレット。

3-3-5-7：ユーティリティバー
不正規発生選択：これをクリックすると強調表示となり分類が記事となる（再クリックで解除）。3-3-5-2：記事状態遷移参照＃コンテント状態制御
プレヴュー：現状でのユーザ閲覧画面が呼び出される。＃記事記述-ユーザイメージ転換
可変化及びフィルアップ：3-3-5-9：テンプレート化参照。可変化はクリックするとマウスポインタが可変化モードに変化。再クリックで解除。フィルアップはクリックするとテンプレートの定義モジュールのパレット内にクラスが生成されて該当編集画面に移行。
3-3-1-2-1-1：テンプレートとフィルアップ参照。＃クラス/テンプレート
定義モジュール変更：コンテントリスト（図３２参照）が呼び出されモジュールもしくはシナリオアイコンを選択すると変更。（シナリオ構造表示でも可）＃定義/スコープ＃コンテンツリスト（切り出し）
特殊記事として作成：3-3-2：シナリオ（メイン画面）に遷移。特殊記事の新規作成タブが最前面表示。
標準ライブラリ及びプライベートライブラリ：3-4-5：ライブラリに詳述。遷移元のＩＤを背負う。＃ライブラリ遷移
配置モジュールへ：クリックすると定義モジュール、配置モジュールのリストが出現。選択するとその編集画面に移動。

3-3-5-8：メインパート記述
１：画面編集部にブログの仕様に従って入力
２：画面パーツをパレットよりＤＤして入力可能な部分に配置。
３：属性及びエミッタをパレットよりレセプタタブ及びボックスに配置。
４：詳細設定を行う。各種データレセプタに設定用のライブラリのデータをドロップする事も可能。＃外部データ利用
5：随時プレヴューなどでユーザイメージを確認

3-3-5-9：テンプレート化＃クラス/テンプレート
記事におけるテンプレートでは画面パーツと属性を可変アイコンとして指定可能。画面パーツは指定したアイコン一つ一つがそれぞれ別のクラスと認識される。属性は同一属性複数配置の場合、一か所を指定すると全ての配置が可変アイコンとなり、一か所をフィルアップすれば同一の属性が反映。

3-3-5-10：特殊記事
特殊記事管理ブロック（3-3-2：シナリオ（メイン画面））からの遷移によって特殊記事編集モードとして記事記述画面が開かれる。ステイタスエミッタパレットは出現しない。属性パレットは参加者属性のみ表示。
参加後には参加者属性はアクティブとなるのでそれを使った表示と入力は可能。参加前には機能せずその旨の表示。
1)イベント説明：ステイタスリンクは配置不可能。シーケンス上で一か所はチェックボタンを配置可能。
2)招待状： ステイタスリンクは配置不可能。
3)参加者タイプ（図３４参照）選択：2-3-2 ３）のプロセスを行う要件を満たす必要。自動生成。＃参加者タイプ（図３４参照）決定プロセス
選択部は画面パーツとして配置されているのでそれ以外の部分は編集可能。ステイタスリンクは配置不可能。
4)保存推奨属性登録画面：2-3-2 ７）のプロセスを行う要件を満たす必要。自動生成。登録部は画面パーツとして配置されているのでそれ以外の部分は編集可能。ステイタスリンクは配置不可能。＃保存属性管理
5)アフターフォロー： ステイタスリンクは配置不可能。ステイタスリンクは配置不可能。
6)識別二次元バーコード：2-11：識別二次元バーコードに記述された二次元バーコードを表示する。参加期間中有効。この二次元バーコードはシナリオＩＤと括り付けられていてユーザチェック時ユーザのコンテキストがシナリオ単位で可能。
コード部は画面パーツとして配置されているのでそれ以外の部分は編集可能。ステイタスリンクは配置不可能。＃二次元バーコードページ生成
7)緊急チャット：チャット窓が画面パーツとして提供される。ステイタスリンクは配置不可能。＃緊急処理

3-3-6：参加者属性管理（図３３参照）＃参加者タイプ（図３４参照）決定プロセス
この画面に置いては参加者のタイプ情報と参加者属性編集とタイプへの適用を行う。
参加者属性：参加者属性はユーザのシナリオの遷移管理と離れた属性情報を管理する為の属性で3-3-1-3-4：参加者属性に詳述。
参加者タイプ（図３４参照）：3-3-1-13：参加者タイプ（図３４参照）に詳述。

3-3-6-1：メイン画面説明
括り付け
管理者ＩＤ
シナリオＩＤ
必須の画面要素
１） 参加者タイプ（図３４参照）編集画面
1-1) 参加者タイプ（図３４参照）情報
1-2) 属性アイコン
1-3) 属性名
1-4) 属性タイプ
1-5) アクティブチェックボックス
1-6) インポートタイプ
1-7) 削除チェックボックス
1-8) 属性メモ
1-9) 新属性登録
1-10) 属性削除
1-11) 参加者タイプ（図３４参照）削除
２） 参加者タイプ（図３４参照）タブ
2-1）参加者タイプ（図３４参照）
2-2）新タイプ登録
a) 代表属性：各参加者タイプ（図３４参照）は参加者タイプ（図３４参照）名と同名の真偽型の参加者属性を生成する。。またタイプ画面ではアクティブ設定を操作できず属性として削除も出来ない。（自己属性でアクティブ、それ以外では不可能。
b) 説明
１） 参加者タイプ（図３４参照）編集画面：1-2〜1-8項までは属性ごとのリスト表示
1-1) 参加者タイプ（図３４参照）情報：現在選択されている参加者タイプ（図３４参照）名とタイプのメモの表示。
1-2) 属性アイコン：登録された参加者属性のアイコン。クリックすると編集画面に遷移。
1-3) 属性名：属性名
1-4) 属性タイプ：属性タイプ
1-5) アクティブチェックボックス：代表属性以外の参加者属性はチェックするとそのタイプにとってアクティブとなり値を持てるようになる。
1-6) インポートタイプ：アイコンで値の参照か同期か表示。また保存推奨属性として選択したならそのアイコンも表示。クリックすると参照先の保存推奨属性情報がインフォームされる。
1-7) 削除チェックボックス：削除する属性をチェック。属性削除で削除。
1-8) 属性メモ：属性メモが表示される。
1-9) 新属性登録：属性登録画面が呼び出され新属性の登録プロセスが開始される。
1-10) 属性削除：チェックした属性を削除する。
1-11) 参加者タイプ（図３４参照）削除：選択された参加者タイプ（図３４参照）が削除される。
２） 参加者タイプ（図３４参照）タブ
2-1）参加者タイプ（図３４参照）：登録された参加者タイプ（図３４参照）がタブとして表示。選択すると該当画面が表示される。
2-2）新タイプ登録：クリックすると参加者タイプ（図３４参照）登録画面が呼び出される。

3-3-6-2：属性登録/編集画面
括り付け
管理者ID
シナリオID
参加者属性ID
必須の画面要素
1) 登録属性名入力フォーム
2) 属性タイプ入力フォーム
3) 属性インポート指定
4) メモ入力フォーム
a)説明
1) 登録属性名入力フォーム：属性名を登録する文字列入力フォーム。シナリオ中でユニークな必要があるのでチェック機構が必要。
2) 属性タイプ入力フォーム：真偽、数値、文字列、文字列リストが選択でき、リストの場合はリスト入力フォームが現れる。初期値入力フォームが用意されていて初期値を設定できる。
3) 属性インポート指定：参照タイプか同期タイプか選択。型及び指定可能範囲からインポート可能な保存属性がリストアップされ選択可能となる。承認可能な属性には承認チェックが入れられる。＃インポート可能属性リスト
インポート可能な属性
１：公式属性（公式）
２：公式タグ関連属性（公式）
３：他のディレクタによって公開された保存推奨属性
４：他のディレクタによって承認可能な保存推奨属性（2-8-4:保存推奨属性）
５：自己の保存推奨属性（許容操作は全て同期（変動制限なし））
保存属性にするか同期タイプならチェックできるボックスが出現。
4) メモ入力フォーム：属性の説明を入力できる。

3-3-6-3：参加者タイプ（図３４参照）登録/編集画面
括り付け
管理者ID
シナリオID
参加者タイプ（図３４参照）ID
必須の画面要素
1) 参加者タイプ（図３４参照）名入力フォーム
2) 属性条件入力フォーム
3) メモ入力フォーム
a) 説明
1) 参加者タイプ（図３４参照）名入力フォーム：参加者タイプ（図３４参照）名を登録する文字列入力フォーム。シナリオ中でユニークな必要があるのでチェック機構が必要。
2) 属性条件入力フォーム：クリックすると属性条件チャートが呼び出され属性条件の編集ができる。呼び出される属性パレットにはインポート可能な保存属性が』収納される。＃シナリオ/計算チャート（図５１参照）
3) メモ入力フォーム：参加者タイプ（図３４参照）の説明入力。シナリオ画面及びユーザのタイプ決定時に利用される。

3-3-7：コンテンツリスト＃コンテンツリスト（切り出し）
括り付け
管理者ＩＤ
シナリオＩＤ

3-3-7-1:コンテンツリスト（メイン）
必須の画面要素
１)コンテントリスト（図３２参照）
1) コンテントアイコン
2) コンテント名
3) コンテントタイプ
4) テンプレート
5) 定義モジュール
6) 配置モジュール
7) メンバ制約
8) ステイタスレセプタ
9) ターミナルステイタス
10) 使用属性
11) コピーチェック
12) プライベートライブラリ登録チェック
13) 削除チェック
２)サブミット
３)シナリオ属性リストへのリンク
４)サブ要素リストへのリンク
５)シナリオ構造表示
a)コンテントリスト（図３２参照）説明
アイコンで表示する項目がある。
リスト項目の高さに合うようミニチュア化。複数ある場合は重なった陰影付きの表示に。クリックするとインフォームが出現してアイコンを整列させて表示。
1)コンテントアイコン:コンテントのアイコン。クリックすると編集画面に遷移。
2)コンテント名:コンテント名。リネイム可能。
3)コンテントタイプ:コンテントのタイプ
メッセージ
記事
ネスト通常モジュール
ネスト例外管理
外部モジュール
外部例外管理
計算モジュール
条件モジュール
タイミング設定モジュール
属性条件モジュール
クラス化フィールドゾーン
クラス化タイムゾーン
テンプレート
4)テンプレート:コンテントにテンプレートが有ればアイコン表示。クリックするとテンプレートの編集画面に遷移
5)定義モジュール:コンテントの定義モジュール。クリックすると定義モジュールの編集画面に遷移。小さく付与された変更ボタンをクリックしたら直接定義モジュールの変更画面に遷移。
6)配置モジュール:配置されたモジュールが有ればアイコン表示。複数の可能性。クリックすると配置モジュールの編集画面に遷移。小さく付与された追加のボタンをクリックしたら追加画面に遷移。
7)メンバ制約:メンバ制約のアイコン表示。モジュールの場合は編集画面へ遷移。
8)ステイタスレセプタ:アイコン表示。複数の可能性。
9)ターミナルステイタス:アイコン表示。複数の可能性。
10)使用属性:属性のアイコン表示。複数の可能性。クリックするとシナリオ属性リストもしくは参加者管理画面の該当属性表示に遷移。
11)コピーチェック:コンテントのコピー作成するかのチェック。
12)プライベートライブラリ登録チェック:プライベートライブラリ登録するかのチェック。
13)削除チェック:コンテントを削除するかのチェック。
b)サブミットは11、12、13項目のチェックをまとめて実行するボタン。
c)リンクは該当画面への遷移。
d)コピーは名称にコピーが付与された同じ内容の項目がリストに追加される。

3-3-7-2:シナリオ属性リスト
括り付け
管理者ＩＤ
シナリオＩＤ
必須の画面要素
１) シナリオ/全体処理属性リスト
1)属性アイコン
2)属性種別
3)属性名
4)属性型
5)定義モジュール
6)配置モジュール
7)メンバ要素
7-1)メンバ種別
7-2)属性型
8)コピーチェック
9)削除チェック
２) サブミット
３) コンテントリスト（図３２参照）へのリンク
４) サブ要素リストへのリンク
５) シナリオ構造表示
a) シナリオ中のシナリオ属性及び全体処理属性のリスト
１) 属性アイコン:アイコンを表示
２) 属性種別:シナリオ属性か全体処理属性
３) 属性名:属性名の表示。リネイム可能。
４) 属性型:3-3-1-3-2:型参照。
５) 定義モジュール:属性の定義モジュール。クリックすると定義モジュールの編集画面に遷移。小さく付与された変更ボタンをクリックしたら直接定義モジュールの変更画面に遷移。
６) 配置モジュール:配置されたモジュールが有ればアイコン表示。複数の可能性。クリックすると配置モジュールの編集画面に遷移。小さく付与された追加のボタンをクリックしたら追加画面に遷移。
７) メンバ要素:全体処理属性のメンバ属性の情報
7-1)メンバ種別はユーザ、記述インスタンス、グループの三種類
7-2)型は3-3-1-3-5:全体処理属性のメンバ属性値の項の通り。
８) コピーチェック:属性のコピーを作成するかのチェック
９) 削除チェック:属性を削除するかのチェック
b) サブミット:チェックされた項目の実施ボタン
c) リンク:３）?５）は関連ページへのリンク

3-3-7-3:サブ要素リスト
括り付け
管理者ＩＤ
シナリオＩＤ
必須の画面要素
１)サブ要素リスト
1)サブ要素アイコン
2)サブ要素種別
3)サブ要素名
4)配置モジュール
5)メンバ制約
6)削除チェック
２)サブミット
３)コンテントリスト（図３２参照）へのリンク
４)サブ要素リストへのリンク
５)シナリオ構造表示
a)サブ要素リストにはシナリオ中に配置された以下の種類の要素が含まれる。

1:タイムゾーン
2:フィールドゾーン
3:管理者トリガ
4:通常トリガ
5:記事画面パーツ(記述呼出)
6:記事画面パーツ(オブジェクトキャリア)
7:記事画面パーツ(属性値入力フォーム)
8:記事画面パーツ(連携)
b)サブ要素リスト要素
１)サブ要素アイコン:アイコンを表示
２)サブ要素種別:a)項リスト項目
3)サブ要素名:サブ要素名があれば表示。リネイム可。
4)配置モジュール:配置されたモジュールのアイコン表示。クリックすると配置モジュールの編集画面に遷移。
5)メンバ制約: メンバ制約のアイコン表示。モジュールの場合は編集画面へ遷移。
6)削除チェック:属性を削除するかのチェック
d) サブミット:チェックされた項目の実施ボタン
e) リンク:３）から５）までは関連ページへのリンク

3-3-7-4：ライブラリ登録＃ライブラリ遷移
3-4-5：ライブラリ参照。チェックしたコンテンツをライブラリ登録。

3-3-7-5:シナリオ構造表示画面
コンテントリスト（図３２参照）でモジュールの所属関係をツリータブにしてリストの表示の制御を行うモード（https://nob-log.info/2012/01/12/javascript/）などを利用。
各モジュールは
定義モジュールコンテント
配置コンテント
定義属性
配置属性
配置サブモジュール
のディレクトリをツリーに下げた形で表示する。
通常のツリータブのように開閉で画面を整理できる。

3-3-8：二次元バーコード生成＃二次元バーコードページ生成
ページにはシナリオユニークな二次元バーコードが生成されている。印刷を行うとシナリオ名とこのコードが印刷される。
他にコードページ生成ボタンと生成ページリストが存在。
コードページ生成ボタンを押すとページタイトル入力フォームが現れそれを入力するとプリント用二次元バーコードと外部トリガ記述モジュール入力用コードが生成表示される。またこの入力コードはデータとしてライブラリに登録される。＃ライブラリ遷移
このページを印刷するとタイトルと二次元バーコードが印刷される。
生成ページリストには今まで生成したページが存在。

3-3-9：概形チェック＃概形チェック
実際の仕様を確認しながらチェック項目の確定を行う。

3-4：メインパート/シナリオ管理
3-4-1：概説
稼働可能なイベントとなったシナリオの管理、（登録）参加者管理、保存推奨属性管理、ライブラリ管理を行う。

3-4-1-1：実施可能シナリオ＃シナリオ遷移制御
実施可能シナリオは概形チェックを経て実施可能シナリオページにアップロードされたシナリオのオブジェクトで設定の付与をして実際に実施可能状態に成る。またこの時テストシュミレーションを使用して事前のシミュレーションを行う事も出来る。実施可能状態になったシナリオは募集、開始をページ上で行う事が出来る。実施中のシナリオはイベントと呼ばれる。

3-4-1-2：登録推奨属性＃保存属性管理
管理者ユーザは自分のイベントあるいは公開で他の管理者ユーザのイベントに過去の自分のイベントで参加者に付与したポイントや称号などの使用を行えるようユーザに推奨する事が出来る。イベント後に同意したユーザは自分の属性ホルダにその属性を保存しておけ、参照可能な管理者ユーザはその属性を自分のシナリオに使用できる。

3-4-2：実施可能シナリオ＃シナリオ遷移制御
括り付け
管理者ＩＤ
必須な画面要素
リスト
１） シナリオ名
２） 現在状態
３） スタートオプション
４） スタート制御ボタン
５） 募集状況
６） 募集オプション
７） 募集制御ボタン
８） 特殊記事配信
a) 説明は、図１３を参照。
３）６）スタートオプション、募集オプションはデフォルトでは管理者トリガ、シナリオで特殊モジュール（3-3-3-4：ユーティリティバー参照）が作成されていればそちらの指定に従う。

3-4-3：参加者管理＃参照可能ユーザ確定プロセス
ここでいう参加者とは
管理者の運営するイベントの招待者
管理者の運営するイベントの参加者
管理者の運営するイベントの過去イベント参加者
管理者所有保存推奨属性保持者
となる。特に特定する場合は参照可能ユーザ。
これらのユーザについては管理イベントへの参加状況がモニター出来、随時メール配信を行う事が出来る。
括り付け
管理者ID
必須の画面要素
リスト
１） ペルソナニックネーム
２） 登録タグ＃タグ-属性転換機構
３） 参照可能な属性ホルダの内容＃保存属性管理
４） コメント
５） 参加/招待中のイベント
５−１）イベント名
５−２）参加状況
５−３）参加者タイプ（図３４参照）
６） 招待
図１４参照。
・参照可能な属性ホルダの内容
参加者の参加者属性閲覧画面を呼び出す。管理者ユーザが参照可能な属性が表示される。
自アカウントの保存推奨属性
公開設定属性
また参加者のタグ情報も表示される。
・参加状況について
招待：ユーザは何らかの形でイベントの招待リストに登録されると招待状態になる。これには招待イベントピックアップ！にオンリスト、参加可能ローカルエントリにオンリスト、招待メールを受け取りチェックした場合が当たる。
属性条件達成：募集期間中で必要な参加者属性を所持した参加者（ここから参加者となる）
イベント参加中：イベントに参加中の参加者
離脱：イベントを中断した参加者
終了：イベントを終了した参加者
招待ボタンを押すとシナリオ画面が呼び出され特殊記事の配信をこのユーザに対して行える。

3-4-4：登録推奨属性管理＃保存属性管理＃インポート可能属性リスト
括り付け
管理者ID
必須な画面要素
リスト
１） 属性名
２） 属性タイプ
３） 編集可能
４） 公開設定
５） 登録ユーザ数
６） 削除ボックス
リスト外
１） 新規作成
２） 削除
説明：図１４参照

3-4-4-1：属性承認管理＃保存属性管理＃インポート可能属性リスト
自己の登録推奨属性に使用申請が来ると開く。
括り付け
管理者ID
必須な画面要素
リスト
１） 属性名
２） 公開設定
３） 申請管理者名
４） 発信日時
５） 承認ボックス
６） 否認ボックス
説明：図１４参照

3-4-5：ライブラリ＃ライブラリ遷移
ライブラリは管理者ユーザが利用できるシナリオの素材を保存し、全てのシナリオ作成（図４９参照）モードで使用可能にするものである。
参照コンテキスト表示：ライブラリはチェックしたコンテンツを参照元のパレットに収納し、定義モジュールとする操作が必要とされる為、参照元画面から遷移した場合は参照コンテンツが操作に括り付けられ画面に参照コンテキストが表示される。
参照コンテキストは
管理者ＩＤ
シナリオＩＤ
参照元コンテンツＩＤ
となる。
プライベートライブラリと標準化ライブラリ：ライブラリは二種類が用意されている。
プライベートライブラリは管理者がシナリオ作成（図４９参照）で出来た派生物やデータ素材を一時的に保管しておくライブラリである。アップロード時のデータセキュリティを行う。
プライベートライブラリの保管物はパレットに送られクラス化される。
標準化ライブラリは標準化されたコンテンツ及び公式、ベンダーの外部モジュール、データが保管される。
標準化ライブラリの保管物はテンプレートとしてテンプレートパレットに送られる。
モジュールダウンロード時の時制＃時制検索編集フォーム：モジュール内のタイムゾーン等のタイミング設定をどの様にするか決定する必要がある。
時制検索編集フォームが呼び出され編集を行う。
ただしこの時はデフォルトの処理が提案される。入力要請をこの時点で留保するとブランクのトリガが代わりに配置される（そのまま実施されると外形チェックに引っかかる）
１）グローバル時間記述：入力要請
２）基準モジュールインスタンス開始時指定：ダウンロードするモジュールより上位モジュールインスタンスが指定されていた場合は入力要請（全体処理：シナリオ開始/個別処理：エントリ）。そうでない場合は無修正。
３）相対時間記述：無修正
４）タイムイン経過：無修正
５）Trigger記述アイコン：無修正
＃シナリオ挙動
ライブラリデータ（図５２参照）：＃外部データ利用 ライブラリへは公式に指定された形式、外部モジュールテンプレートインポート時にその外部モジュールによって指定される形式のデータをアップロードが可能。データの評価は記述モジュール、コンテンツ、アイコンの評価時点に行われる。

3-4-5-1：プライベートライブラリ＃クラス/テンプレート＃外部データ利用
保管物
コンテンツ
テンプレート
クラス化されたゾーン
アップロードデータ
画面パーツ
コンテンツ、テンプレート、クラス化されたゾーンはコンテンツリストもしくは編集画面から対象を指定してアップロードするとプライベートライブラリに登録される。
テンプレートがあるコンテンツのテンプレート情報は失われる。
ダウンロードは参照コンテキストを持ってライブラリにアクセスすると参照元に行う事が出来る。参照コンテキストは編集画面からアクセスすると連携される。
参照コンテンツはモジュールの場合は定義モジュールとして、記事の場合は所属するモジュールが定義モジュールとなる。データおよび画面パーツは呼び出した編集画面にのみ現れる。

3-4-5-2：標準化ライブラリ＃クラス/テンプレート＃外部データ利用
保管物
テンプレート
外部モジュール
追加画面パーツ
公式データ
ダウンロードは参照コンテキストを持ってライブラリにアクセスすると参照元に行う事が出来る。参照コンテキストは編集画面からアクセスすると連携される。
参照コンテンツはモジュールテンプレートの場合は定義モジュールとして、記事テンプレートの場合は所属するモジュールが定義モジュールとなる。追加画面パーツ、データはシナリオで参照可能。

3-4-5-3：ライブラリ画面
括り付け
参照コンテキスト
必須の画面要素
１） ライブラリ名
２） 参照コンテキスト
３） 保管物アイコン
４） 保管物名
５） 保管物種別
６） 提供元情報
７） 説明メモ
８） ダウンロードチェック
９） 削除チェック
１０） ダウンロード
１１） 削除
１２） データアップロード（リスト外）
説明
１） ライブラリ名：プライベートか標準か
２） 参照コンテキスト：参照コンテキストを表示
３） 保管物アイコン：ここからリスト。クリックすると内容表示（編集画面：参照のみ）
４） 保管物名：保管物名
５） 保管物種別：前項保管物参照
７） 提供元情報：標準化ライブラリでのベンダー情報
８） 説明メモ
９） ダウンロードチェック：参照元にダウンロードする保管物をチェック
１０） 削除チェック：プライベートラブラリにおいて削除したい保管物を指定。
１１） ダウンロード：ダウンロードのサブミット
１２） 削除：削除のサブミット

3-4-5-4：データアップロード＃外部データ利用
種別（拡張子）をリストから指定すると機器のファイル情報が開かれ選択。ライブラリへのアップロードが可能。セキュリティチェックが行われ登録可能な形式を持っている事を確認する。

3-4-6：ユーティリティ
3-4-6-1:告知メール配信＃メール配信
特定のタグ、保存属性、履歴のユーザ宛に告知通知メールを配信出来るアドホックの送信用メールアドレスを発行。そのアドレスに使用メーラーから配信すると同一内容のメールが指定ユーザに配信される。
規模によって料金が発生する。通常の形式のメールを配信。

3-5：メインパート/イベントモニタ（図１１参照）
3-5-1：概説
イベントモニタ（図１１参照）は実施中のイベントの状態を監視するパートであり、リアルタイムでのログとアクティヴィティの閲覧、例外管理、管理者への直接連絡を取る管理者コール手段を提供する。

3-5-1-1：管理者トリガ＃遷移制御
管理者トリガの管理はイベントモニタ（図１１参照）の管理者トリガ画面で集中的に行うかチャートモニタ（図１５参照）の管理者アイコンを直接クリックするかで行う。複数回可能かどうかはシナリオの設定による。

3-5-1-2：管理者コール＃緊急処理＃緊急処理＃緊急処理
管理者と直接リアルタイムで交信可能な管理者コール手段も用意されている。
ユーザ側はチャート上の行動で
管理者コールアイコンを評価したなら可能となりチャット画面が呼び出される。
管理者側は参加者モニタから随時可能。
緊急コールは管理者側からのみ可能。WEBRTCを考慮
ネット上のシステムを間に挟み双方が直接電話番号を知る事が無いようにする。

3-5-2：チャートモニタ（図１５参照）
括り付け
管理者ＩＤ
(シナリオＩＤ)
(モジュールＩＤ)
チャートモニタ（図１５参照）の画面構成はチャートモニタメインとサブモニタ、ユーティリティバーで構成される。シナリオ全体、実施中全体を選ぶ事も出来、その時はチャートは無くサブモニタだけの表示となる。

3-5-2-1：チャートモニタメイン＃チャートモニタ
必須の画面要素
1) モジュールチャート
2) モニタオブジェクト
2-1)プロパティ部
2-2)アクティヴィティ部＃イベントアクティビティ
2-3)ログレセプタ＃ログ管理
3)管理者トリガ

a) 説明
１) モジュールチャート:該当モジュールのチャート画面と同じだが下記の限定した操作しか出来ない。
２) モニタオブジェクト
種別
配置コンテント
タイムゾーン
フィールドゾーン
付随トリガ
トリガアイコン
処理アイコン
これらのアイコンにはプロパティ部、アクティヴィティ部が現れる。また従来のシナリオ属性配置可能な場所はログレセプタとして後述のログマーカが配置可能。
プロパティ部をクリックするとオブジェクトの内容が表示される。（文書ならユーザ用画面、モジュールならモジュールのチャートモニタ（図１５参照）、外部モジュールならプロパティ、ゾーンなら定義情報。
アクティヴィティ部をクリックするとアクティヴィティ情報が表示
１：遷移者数
２：遷移者リスト
３：処理中者数
４：処理中者リスト（発行ステイタス）
５：終了者リスト
６：終了者リスト（発行ステイタス）
例外モジュールの場合は主催者コール情報が閲覧できる。
ログレセプタにログマーカを落とすとログモニタに落とした場所のリアルタイムなモニタ情報が次々表示される。

3-5-2-2：サブモニタ（属性モニタ、参加者モニタ、ログモニタ）
必須の画面要素
１) 属性モニタ
1-1)属性アクティヴィティ＃イベントアクティビティ
２) 参加者モニタ
2-1)モニタ
2-2)参加者
2-3)ログ＃ログ管理
2-4)緊急対応＃緊急処理
2-5)管理者コール
３) ログモニタ＃ログ管理
a) 属性モニタは属性パレットと同じインターフェイスをした属性アイコンのリストでクリックすると属性アクティヴィティを確認出来る。
属性アクティヴィティは属性保持者の属性値を含むリストである。
参加者モニタには個別インスタンスを持つ参加者のリストが表示される。個々の参加者名をクリックで該当参加者の選択となり、モニタ下部の参加者ボタンで参加者管理画面が、ログアイコンクリックでログが表示される。緊急対応ボタンを押すと緊急対応モードに遷移、管理者コールボタンを押すと管理者コール画面が呼び出せる。
１：遷移オブジェクト名と時間
２：発行ステイタス
３：終了オブジェクト名と時間
４：主催者コール
ログモニタではログマーカを配置したアイコンでイベントが発生するとログモニタ上にイベント内容の記述が発生する。
１：遷移
２：ステイタス/トリガ発生
３：処理終了
４：主催者コール

3-5-2-3：ユーティリティバー
必須の画面要素
１) ログマーカ
２) 緊急対応マーカー
ログマーカはクリックすると自動的に付番するアイコンで配置可能な場所に配置するとその付番を頭にしてログモニタで閲覧可能な情報が取得出来る様になる。
ログマーカをクリックするとモードが変更してクリックした場所にログマーカをドロップする。＃ログ管理
緊急対応マーカーは個人と括り付けられたチャートモニタ（図１５参照）が開くと出現する。ドロップした場所において管理者コールで可能な変更を行う事が出来る。＃緊急処理
１：ステイタス発行（チャートモニタで該当位置にドロップ）
２：強制遷移（チャートモニタでドロップ）
３：属性値修正（属性モニタ上にドロップすると属性管理画面に遷移）
を行う事が出来る。

3-5-3：例外モジュールモニタ（図１６参照）
あるシナリオ、全てのシナリオで稼働する例外記述のモニタを行う。
括り付け
管理者ＩＤ
(シナリオＩＤ)
必須の画面要素
１) 例外管理名
２) シナリオ名(シナリオ括り付けでは無記)
３) プロパティアイコン
４) アクティビティアイコン＃イベントアクティビティ
５) 管理者コール
a) 説明
範囲中(イベント毎か実施中全て)の例外管理のリスト。
例外モジュールのリスト順は優先で管理者コールの発生時間から最も経過した時間を荷重化して優先順を決める。それ以外は処理中参加者数。
プロパティをクリックすると外部モジュールのプロパティ画面（図２９参照）かチャートモニタ（図１５参照）が表示。
アクティブティはチャートモニタ（図１５参照）のオブジェクトのアクティヴィティと同じ
管理者コールは例外モジュールに含まれている可能性のあるサービスで発生すると専用のチャットおよび必要があるなら管理者側から通話を行う事が出来る。表記は現在発生している件数でクリックするとユーザ名のリスト。選択すると管理者コールが呼び出される。

3-5-4：管理者コール
括り付け
管理者ＩＤ
シナリオＩＤ
例外管理ＩＤ
ユーザＩＤ
必須の画面要素
１) ユーザ名
２) 例外管理名
３) シナリオ名
４) 参加者ログ表示＃ログ管理
５) 緊急対応＃緊急処理
６) 緊急コール＃緊急処理
７) 緊急チャット＃緊急処理
a) 説明
1-3はコンテキスト情報を表示
参加者ログは参加者モニタのものと同様。
緊急対応を押すと参加者と括り付けられたチャートモニタ（図１５参照）が開き緊急対応マーカーを使用可能になる。
緊急コールはシステム経由の双方の電話番号がわからない形で通話を行う。
緊急チャットはユーザ側のサブ画面に出現するチャットとチャットを行う事が出来る。

3-5-5：管理者トリガ管理（図１６参照）＃遷移制御
括り付け
管理者ＩＤ
シナリオＩＤ
必須の画面要素
1)管理者トリガ名
2)モジュール名
3)シナリオ名
4)チャートモニタ
5)トリガ発行
説明:3-８図参照。

3-6：新規登録
管理者ユーザ会員種別などを使用データ量などから検討する。

3-7：外部連携
システムが外部連携として想定しているのは以下の場合である。
ｗｅｂサービス
埋め込み（他SNSタグの埋め込み）
リンク
ＡＰＩの利用の形式として（ガイドサービスなど外部のサービスをシナリオの一部として利用する形式）
外部モジュール
画面パーツ
ＡＰＩの利用の対象として
端末アプリ（管理システム）
外部顧客管理、ＰＯＳまたは会場内ロケーション管理システム
外部サービス
経路ガイドサービス
コンテキスト提供（天気予報サービス、交通情報など）
エンターテイメント（ゲーム、映像、インタラクティブエンターテイメントシステムなど）

データの利用
フィールドゾーン定義データ
時刻/時間データ
外部トリガ（ＵＲＬ）/シナリオステイタス/エントリィトリガURL
装飾用データ（ＣＳＳ）
埋め込みデータ
ＡＶデータ
リンク先データ
その他外部モジュール/画面パーツ対応データ

X-1：ベータ時のライブラリ仕様の修正
プライベートと標準化ライブラリは統合する。将来的なマーケット機能の拡張を考慮する。
ライブラリの登録データは公開、プライベートの選択が可能とする。
公開の場合は編集自由、フィックス、内部不可視の三つのモードを選べる。
コメントメモと参照用URLを登録できる。
他者パレットにダウンロードされたらダウンロードポイントがそのデータに付与される。
組み込まれたシナリオが実施されたらポイントがそのデータに付与される。
組み込まれたシナリオ実施後にユーザ評価がなされたらそれも付与される。
テンプレートのフィルアップ入力の集約入力フォームの作成。

Ｘ-2：ユーザ画面の仕様変更
端末ブラウザのユーザ画面は図表57-59Ｐの使用に従って設計する。
スマートフォンの画面操作において親指のみで操作可能とする画面構成。
複数の表示画面とナヴィゲーション、リストを表示内容として持つサービス画面のモード遷移と表示アイコン。
１） 表示画面は全て上下にタブを持つ。（通常は一方は隠れている）Aモード参照。
２） リスト表示時はタブが上下から引き出されて複数並ぶ形となる。Bモード参照
３） Bモードにおいて現在選択中の画面はページの一部が見える状態でありその幅はタブのドラッグで調整できる。
４） 画面中親指がレスト出来る位置に操作アイコンが配置可能。これは全ての状態で左右のドラッグ、フリック、スワイプで画面端に収納できる。
５） 収納した操作アイコンは画面端からのドラッグ、フリック、スワイプか全画面の操作に置いてユニークな操作（ほとんど利用されないシェイクなど）を割り付けて展開。
６） A,Bモードにおいてナヴィバーを画面上に被せるように展開できる。これは画面の上下端（ナヴィバー１タイプ）かもしくは操作アイコンにレストした親指がそのまま移動できる斜め位置あるいは扇状（ナヴィバー２タイプ）となる。上下にドラッグする事によって１タイプ２タイプは相互に遷移出来る。また２タイプは左右にドラッグする事によって傾斜を変えられるようにする。
７） 操作アイコンは中央部と上下端に操作可能な部位がある。中央部は互いに区別されたタップ系操作でAモード（リストの選択画面）＜＞Bモードの遷移かナヴィバーの展開＜＞収納（６で1タイプ２タイプ双方が可能とするなら更に操作を追加）を行う事が出来る。
８） 操作アイコンの上下端は互いに区別されたタップ系操作で画面の上下方向への移動、ジャンプを行う。これは表示画面内の場合もリストの場合も同様。操作の明確さを生むため操作に割り付ける位置を若干ずらしても良い。例：ジャンプ操作に割り付けるのは突端部、移動には中間部など。
９） 上下への操作はアイコンにドラッグ系の操作を行う事によって実現しても良い。
１０） ２タイプのナヴィバーの場合、操作アイコンの位置によって傾斜の方向を変えても良い。中央部で傾斜が反転。
１１） 以上の操作は操作アイコン以外の場所に割り付けても構わない（実施例）。
１２） 以上の操作はスマホ操作（タップ、ダブルタップ、ロングタップ、ドラッグ、フリック、スワイプなど）
１３）ナヴィバーは展開幅広方向にスクロールして選択できるようにする。（一度に表示されるボタンの数を減らす）

X-3：多言語仕様の準備
多言語仕様に対応できるよう準備を行う。

＃シナリオ挙動

Ｙ-1：トリガ機能の整理統合
1-4-2：トリガ/3-3-1-5：記述子（処理アイコンと遷移矢、トリガアイコン）/3-3-1-6：タイミング設定/3-3-4-3-1:外部トリガ記述モジュール/3-3-4-3-5:シナリオステイタスレセプタモジュールについて以下の記述を優先
トリガアイコン、外部トリガ記述モジュール、（タイミング設定チャートの）トリガアイコンは制御トリガ、外部トリガに整理統合される。またこの二つの種類のトリガはトリガパレットに登録されて通常のモジュール（シナリオ）編集画面でも利用可能となる。
制御トリガはＴＺなどと同じ処理アイコン扱いとなり外部トリガはシナリオレベルのコンテンツクラス扱いとなる。インポートされたモジュールに組み込まれた外部トリガはどのレベルのパレットにも登録される事となる。管理者トリガ、シナリオステイタスレセプタはインポート時点でリネームされる（組み込まれたモジュール名を追加）。
ブランクの制御トリガ、外部トリガはチャート上に配置されるとプロパティ編集画面が開き指定の内容を入力するとパレットに登録される。
制御トリガ：トリガアイコンのスタートトリガ、通常トリガ、（タイミング設定チャートの）トリガアイコンはこちらとなる。
プロパティ編集画面
１） 種別選択
a) スタート
b) 通常
c) タイミング（（タイミング設定チャートの）トリガアイコン）
２） 詳細設定
スタートだと無し（なおスタートトリガとそれからの遷移は省略可能）＃概形チェック
通常だと付番とメモ
タイミングでは3-3-1-6：タイミング設定の記述に従って時間の指定を行う。
外部トリガ：外部モジュールからトリガアイコンに変更。3-3-4-3-1:外部トリガ記述モジュール、管理者トリガ、3-3-4-3-5:シナリオステイタスレセプタモジュールはこちらに変更される。
プロパティ編集画面
１） 種別選択
a) グローバルトリガ（外部トリガ記述モジュール）
b) 管理者トリガ
c) シナリオステイタスレセプタ（モジュール）
２） 詳細設定
3-3-4-3-1:外部トリガ記述モジュール、3-3-4-3-5:シナリオステイタスレセプタモジュールを参照。
管理者トリガはシナリオにおいてユニークな名称を登録。複数回可能か一回のみか指定。

Ｚ-1：参加者画面整理（文書末にまとめて）
2-6-2：参加可能ローカルエントリィ＞＞削除
2-6：トリガチェッカーメイン（ＱＲページ）とトリガマップへの遷移はメインナヴィバーに記述。トリガチェッカーナヴィは廃止。
2-5：リスト＞＞コンテンツリストは統合、イベントリストも統合；３Ｐに集約。
表示中、待機中、ログＰ、参加中イベント、招待中イベント、イベントログはタグのカラーとスタイルを区分けして識別できるようにする。
ナヴィに検索バンド追加
検索バンド表示項目
１：チェックボックス
ペルソナ管理系共通ナヴィ：表示中、待機中、参加中、招待中、イベントログ、ローカルエントリィ
開始後イベント共通ナヴィ：表示中、待機中、参加中、ログＰ
参加後イベント共通ナヴィ：表示中（特殊Ｐ）、ログＰ、参加中イベント、招待中イベント、イベントログ、ローカルエントリィ
その他イベント共通ナヴィ：参加中イベント、招待中イベント、イベントログ、ローカルエントリィ
チェックされた対象のみ表示
各Ｐの表示対象は2-1図の遷移に従う。ローカルエントリィはローカルエントリィ経由でポップされた招待中イベントを表示。
２：キーワード検索窓：タグ名称の検索用
コンテントリスト（図３２参照）
＜2-5-1：表示中コンテントリスト（図３２参照）
＜2-5-2：待機中コンテントリスト（図３２参照）
イベントリスト
＜2-5-3：参加中イベントリスト
＜2-5-4：招待中イベントリスト
＜2-5-5：イベントログリスト
参加イベントコンテンツリスト
＜2-5-6：参加イベント表示中コンテンツ
＜2-5-7：参加イベント待機コンテンツ
＜2-5-8：参加イベントコンテンツログ

Ｚ-2：マップタイプチャート編集画面の追加（文書末にまとめて）
比較的時間的構造が単純で地理的要因に依存性の高いシナリオを編集する為、或いは通常画面の作成途中で地理的要因の確認を行うためにマップタイプチャートモードをシナリオ、ネストタイプモジュール編集画面に追加する。双方はユーティリティバーのアイコンを押すことによって相互に遷移する。3-3-1-4-4図４８参照
双方はアイコンの機能は一部を除いて全く同一である。
画面構成
ユーティリティバー
パレットエリア
マップタイプチャートフィールド
サブチャート窓
プレーンサブチャート
FZ付サブチャート
説明：ユーティリティバーおよびパレットエリアは通常チャートと同じ。
マップタイプチャートフィールドは地図そのものでチャートエリアに対して地図（チャートフィールド）はスクロールする。サブチャートも同様でチャート窓に対してチャートがスクロール（縮尺変更）する。
それぞれにアイコンを配置できその位置はチャートに対して固定されているがチャートをまたぐ遷移矢だけは窓とチャート、ＦＺのフォーカスアイコンそれぞれの相対位置の変化に応じてアイコンとの接点もしくは窓ヘリ（窓外のアイコン）を起点として形状を変化させる。（同一チャート内の双方のアイコンが窓外の場合、矢は消える）
窓ヘリのどこを起点とするかは四辺中央、角のどこに窓外アイコンが近いかによって決定される。
窓枠にはスクロール用のバーが配置される。
マップチャートは地図或いはフィールドオブジェクトが張られたチャートである。地図上の情報で地理的意味があるのはフィールドゾーンのエリアとフォーカスアイコンのみとなる（フォーカスアイコン間の距離、移動情報も表示）。その他の配置されたアイコンは遷移関係のみが意味がある（見やすさと関係把握のために位置を移動する事は可能）。フィールドゾーンはこのモードではマップチャート上にのみ配置できる。
ユーティリティバーのハイライトをクリックすると通常の地図と白地図に表示を変えられる。
フォーカスアイコン間に距離矢を張るとガイドモジュールがプロパティ設定画面で呼びだされ経路情報が計算される。経路を選択すると距離と所要時間が距離矢に表示される。
プレーンサブチャートは画面に対して位置がフィックスされたチャート窓に配置される上記の制限に従う通常モードの他にアイコンが相対位置の変化だけ窓に従い地図上に表示されるシースルーモードがある（スクロールバーのみ表示）。どちらに属するかは配置時、あるいは設定で選択。
フィールドオブジェクトは位置情報を持つ画像とその上に設定されるＦＺ情報、コンテンツ情報（接続情報）を持つオブジェクト。地図オブジェクトはそれに地図座標情報が付与されたクラス、ブロックフィールドオブジェクトは画像上を区切るブロック情報とブロック相互の連結情報を持つ。関係を記述できるプロパティ情報をブロック、連結情報は持ちうる。また指定した要素間の関係情報を吐き出すメソッドを持ちうる。
サブチャートとしての制限も付けられる。
FZ付サブチャートはマップチャートに対して位置をフィックスされたサブチャート窓に配置されるチャートである。ＦＺに関連付けられていてＦＺのフォーカスアイコンをクリックする事によって付近に展開しまた収納される。収納されたアイコンの遷移矢はフォーカスアイコンを起点として張られる。FZ付サブチャートに配置されたアイコンは全てそのＦＺの所属となる。
このチャートはマップチャートの子クラスとして作成。包含的ならＦＺ内に更にＦＺを追加する事は可能。コンテンツの配置はＦＺエリアに限定されない。
フィールドゾーン：マップチャート上にＦＺを配置するのは3-3-1-4-3-1：範囲設定と同様に行う。フィールドゾーンのアイコンを地図上に配置すると一旦消えポイントマーカーが出現する。
設定が終わると範囲表示とフォーカスアイコン、付随トリガが出現する。フォーカスアイコンはポイントの場合は不可動、範囲の場合は範囲内を自由に動かす事が出来る。クリックするとFZ付サブチャートが周辺に現れ、もう一度クリックすると消える。距離矢を他のフォーカスアイコンに張るとガイドモジュールを呼び出すことが出来る。
タイムゾーン：このモードではタイムゾーンは関連子アイコンと所属タイムゾーンアイコンを持ち、サブチャートのそれぞれにインスタンスを配置できる（入れ子関係がある場合は一番下層のＴＺの情報が表示される）。
パレットからはどのサブチャートに対しても通常に配置できる。
関連子、あるいはクラス化した場合はパレットからドラッグしてインスタンスが配置されていないチャートに落とされるとそこにインスタンスを生成する。またアイコンに落とした場合はそこに所属タイムゾーンアイコンを発生させる（インスタンスとして機能、同クラスのＴＺ内に入ったら消える）。
関連子をＤクリックするとそのＴＺ及び子ＴＺに属するアイコン以外は消えて見える。
インスタンスはそれぞれ遷移を発着させられるがそれらの機能は位置によって異なる事は無い（見た目の整理の為の機能）。
このインスタンスはクラス化によって別々のモジュールに配置されるインスタンスとは異なり見た目上のものである。
自由フォーカスアイコン：このモードのみ処理パレットに収納されるアイコンで経路計算の為だけにマップチャート上に配置可能となる。機能はフィールドゾーンのフォーカスアイコンと同様の機能を果たす。
距離矢：このモードのみ処理パレットに収納されるアイコンで経路計算の為だけにマップチャート上に配置可能となる。フォーカスアイコン間のみを結ぶ事が出来る。
モード間のアイコン移動：モードを切り替えた時にそれぞれのチャートにすでに配置されているアイコンは次の法則に従って移行する。その後、ＦＺ，ＴＺ以外の配置は自由に変更でき（サブチャートをまたいで）その情報は再度移行し戻ってきても保持される。
通常チャートからマップタイプ：所属ＦＺのあるアイコンは該当FZ付サブチャートに相互の位置関係を保持して移行する（ＴＺがある場合は所属タイムゾーンアイコンを付与）。それ以外のアイコンはプレーンサブチャートに相互の位置関係を保ったまま移行する既存ＴＺもこちらに移行する。
マップタイプから通常チャートに所属ＴＺの枠内の空白部分に配置される（無い場合はプレーンに）。枠が狭くて配置不能の場合は下方向に全体が移動し枠を拡大する。
以上、述べたように、マップタイプのユーザインタフェースでは、タイムゾーンではなく、フィールドゾーンを包含関係で構造化して管理している。このように、タイムゾーンとフィールドゾーンは、双方若しくは片方のゾーンを用いて構造化することができる。

Ｚ−３：参照用サブチャート窓
何らかの理由によって簡易な処理をモジュール化した場合、モジュール内の処理を見るには編集画面を開き画面遷移を伴った処理を行わねばならない。この場合の閲覧性の低下を防ぐためにマップタイプでのサブチャート窓の機能と同様のウィンドウ機能をネストタイプモジュールに装備する。窓の機能はサブチャート窓と同じだが編集を行うには編集画面に切り替える必要がある（パレットの内容が異なるため）。

Ｚ-4：期待時間計算（図６０参照）
≪期待時間計算≫
イベントが終了する見込み時間、或いは時間的な整合性をチェックする為にシナリオ開発時随時チャートの遷移関係のチェックを行う機構を組み込む。この機構を組み込む場合、チャートは以下の制限を持つ。
・コンテント（モジュールと記事）及びＴＺ、ＦＺは内部ロジックによる期待時間要素を持つ。
対象ゾーン内の遷移情報により外部遷移期待時間要素も計算される（レセプタ、トリガも持つ）
・閉路はループカウンタに限る/ループカウンタはＴＺをまたげない
・隠ぺいされたモジュール及び全ての記事は内部ロジックを遷移系列に分解されない。隠ぺいされたモジュールとは設定により内部の処理を公開しない事にしたモジュール或いは外部モジュールを指す。
≪制約計算≫
制約計算は対象ゾーンに関して参照専用もしくは範囲情報のある参加者属性のセット及び例外除外/不正規除外条件での遷移可能な遷移系列を抽出する計算である。
≪対象／比較ゾーン遷移置換作業≫
＞＞対象ゾーンに関してゾーン化作業を行う。また内部のタイムゾーンについて比較ゾーン化作業を行ってチャートを統合する。これは隠ぺいされたモジュール或いは記事に到達するまで行う。
対象ゾーンとなりうるオブジェクト：ＴＺ、ネストモジュール（シナリオ）
比較ゾーンとなりうるオブジェクト：上記に加えコンテント
比較ゾーン：内部遷移などの内部ロジックと対象ゾーン内の外部遷移情報による期待時間情報を持つオブジェクト。双方の整合性は約束されていない。
≪遷移矢展開作業≫
＞＞ループカウンタを展開する。同時に禁止されている自然発生的なループが存在しないかチェックする。
≪制約抽出作業≫
＞＞参加者属性に関して制約条件の補集合を利用するメンバ制約、条件フィルタ、制約条件と関連付けられたコンテントのステイタス（モジュールのプロパティに設定されている場合）を抽出してそれが必要となる遷移を遷移系列から除外する。
またステイタスに注目して例外、不正規のステイタスから発する遷移系列および例外管理とそれに続く遷移系列を除外する。他の遷移に合流する場合はそのノードへ至るまでの遷移を除外。
≪実行動期待時間加算≫
＞＞期待時間計算による時間範囲の縮約と正確化を行うため参加者の実行動による制約を遷移系列に取り込む。実行動が予測できるノード間に行動時間算出矢を張り実行動期待時間加算を行う。
≪遷移系列期待時間計算≫
＞＞抽出された遷移系列に対して要素の遷移系列における評価を行い時間計算遷移系列に転換する。
１）対象ゾーンと比較ゾーンの範囲情報から制御トリガの転換を行う。
２）期待時間加算要素を持つ要素は要素内遷移に加算要素を割り当て、トリガの種別評価を行う。＄遷移系列期待時間計算の期待時間加算要素参照
３）その他の要素の評価を行う。
≪遷移系列期待時間計算≫
＞＞期待時間計算を行う。不能検定で問題点が出たら評価決定或いはチャートの再編集を行い不能検定の解決を行う。
≪焦点比較ゾーン内外遷移チェック≫
＞＞基礎要素の期待時間計算を行ったらＴＺや中間的なモジュールの内部遷移と外部遷移の整合性が取れているか検証を行う。
それぞれの比較ゾーンを焦点化して不能検定を行いその解決を行う。
遷移系列：遷移矢とシステム的なトリガ情報によってある対象ゾーンの遷移関係を０次入力の頂点が一つだけの有向非巡回グラフ（ＤＡＧ）に展開したもの。
なお、全ての経路計算が計算量的に困難な場合は隠ぺいモジュール自動設定による対象ゾーンの分割、深度重視の探索試行を可能な回数行う経路抽出シミュレーションなどによって時間的な最適化を行う事も出来る。この場合、制約条件と探索目標をリンクさせる（例外を含む制約では例外モジュールを標的とする試行を優先、あるいは属性判別要素を標的など）事によってシミュレーションの効率化を行う事も出来る。

Ｚ-5：対象／比較ゾーン遷移置換作業（図６１参照）
この操作を範囲内の比較ゾーン全体に行って全ての遷移系列をモジュールのスタート及びＴＺのタイムインからの遷移系列に転換する
＃この分解は隠ぺいモジュールと記事の内部には及ばず、付随トリガ、タイミング設定の置換で終了する。
１：対象/比較ゾーン内のモジュールの通常トリガにスタートトリガから遷移矢を張る。
２：対象/比較ゾーン内のＴＺに関してΑ、Ｂの操作を行う。モジュールに関してＢ操作を行う。またその他の外部からの遷移に関してはゾーン外トリガを挟む（そして開始トリガから待受開始遷移矢を張る）。
３：発生遷移矢の存在しないノードについては直上の所属ＴＺ，モジュールのスタートトリガから遷移矢を張る（ＦＺのトリガを含む）。
４：また対象ゾーンに内包されるモジュールはスタート、通常、子モジュールトリガをモジュール入力遷移矢、対象ゾーン内の子モジュール発生と遷移矢で連結、ステイタスエミッタとステイタス、強制終了レセプタと不正規終了/例外終了についても同様とする
５：終了トリガを設置。全ての端末、タイムアウト遷移、強制終了遷移はその包含比較ゾーンの終了トリガに遷移矢を張る。
タイムインと最終的に連結せずかつ外部からの遷移によって生成されるノード
ＦＺの所属関係は遷移条件付きカウンタをＴＩ，ＴＯへの遷移に追加して行う。
タイムアウトについて内部からの遷移についてはそのまま（足切りは内部遷移は禁止（次項の置換で閉路となるので））
対象ゾーン外の遷移は消える（遷移タイミング情報は標準範囲情報が無ければ失われる）
期待時間範囲の縮約が可能になるので遷移条件付きカウンタに置換される。但し対象ゾーン外からの遷移が被判定の場合はゾーン外トリガに置換

Ｚ-6：遷移矢展開作業（図６２参照）
ループ内を対象ゾーンとして期待時間計算また所属ＴＺを対象として期待時間計算：所属ＴＺ最長期待時間/ループ内最短時間と判定値の少ない方が最大ループ数（マージンを付けても良い）となる。なお、判定値による制限が無く所属するＴＺやモジュールの最長期待時間が発散（∞）となる場合は計算対象ゾーンを１レベル引き上げる。所属ＴＺ、モジュールの制約が最後まで発生しない場合は警告を行い、処理を停止するか定数或いはシナリオの上限時間の入力を求める。
隠ぺいモジュール、記事のステイタスからの複遷移の分解は設定が存在すればその通りに、無ければ短遷移として扱う。
上記要素のステイタスの設定として
制約
（要素内遷移毎の）期待時間加算要素
（複遷移の場合）数
＃複遷移の場合はそれぞれに期待時間要素が付く。
たとえばＡの最大ループ数が３なら以下の通りに展開（上は単遷移が分岐より発出/下は複遷移）
カウンタ以外の複遷移流出はルートごとに分解。
遷移系列はそのままで期待時間合成を行う ＄期待時間合成を参照
期待時間合成時に分解

Ｚ-7：遷移制御モードの時系列（図６３参照）
いずれも遷移系列から真偽を判定する事は出来ない
（時系列を確定できない。カウンタ等で時系列を確定できる場合の処理は要検討）
なお、遷移制御モードのシナリオ属性の機能はマイナス、反転感知機能を持つカウンターの作成、或いは遷移矢の種類を増やすことで遷移矢でも同様の機能は実現可能である
（ただし一意に置換は不可能（管理者が記述可能と言う事）。巡路の共有をする訳では無いので真偽の判定は出来るとは限らない。そして遷移の数自体は既に増えている）
ノードを削除して要素が端末になったら端末を補う。

Ｚ-8：期待時間計算での要素の種別（図６４参照）
対象ゾーンとなりうるオブジェクト：ＴＺ、ネストモジュール（シナリオ）
焦点ゾーンとなりうるオブジェクト：上記に加えコンテント、ＦＺ
対象ゾーンとの配置の関係によって決まる。
開始トリガ
内部配置トリガ
/外部配置（通常トリガ、子モジュールトリガ、通過遷移矢）
基準モジュールと対象ゾーンの包含関係によって決まる

Ｚ-9：遷移系列期待時間計算（図６５参照）
≪時間計算遷移系列の詳細≫
ある時間計算遷移系列は開始トリガから発する有向遷移矢で結ばれた要素で出来た有向非巡回グラフ（ＤＡＧ）をなす。要素の遷移矢との結合点は受ける方をレセプタ、発する方をトリガと呼び、ある要素のレセプタとトリガの全てを結んだ要素内有向遷移と遷移矢で構成されるDAGをなす。この時のレセプタとトリガをノードと呼ぶ。
なお無時間要素は単純に一つのノードをなす。
≪期待時間≫
ある（ノードまでの）遷移系列が最短で終了する期待時間と最長で終了する期待時間の組。
加えてもっとも可能性の高い終了時間の範囲。
≪期待時間計算≫
期待時間計算
１）開始トリガから初めて全ての遷移を辿ってノードごとにノード遷移系列期待時間を置いてゆく。
２）要素内有向遷移を通過する時には期待時間加算要素を期待時間にそれぞれ加算して行く。
３）合流及び分岐時には＄期待時間合成に従って期待時間が合成される。
４）条件付きカウンタでは単純不能検定が行われる。
５）その結果について完全成立で無い場合は$焦点比較ゾーン内外遷移チェックの検証スキームを使用して適正化を行う。（進行はストップ）
６）ゾーン終了トリガに到達すると一旦期待時間計算は終了する。
≪期待時間加算要素≫
ある要素内有向遷移は期待時間に関する加算要素を持ちうる。それぞれの期待時間の要素に対する加算値の形を取るが
最短時間＜＝最長時間
標準最短＜＝標準最長
でなくてはならない。
（+MN +MX）（+MNs +MXs）/
+ＭＮ +ＭＸ
+MNs +MXs
詳細は＄要素種別期待時間加算要素を参照。
≪遷移系列期待時間≫
対象ゾーンの遷移系列を追って行き最終端末（対象ゾーンの終了レセプタに連結するノードの期待時間及び終了レセプタの期待時間
≪ノード遷移系列期待時間≫
遷移系列の開始トリガから任意のレセプタ、トリガ（ノード）までの期待時間。
最短時間 最長時間
標準最短 標準最長
（MN MX）（MNs MXs）/
ＭＮ ＭＸ
MNs MXs

Ｚ-10：期待時間合成（図６６参照）
ノードに流入する遷移矢が複数ある場合期待時間の最小最長の組（MN MX)を合成する。単純カウンタの合成を参照。
合流ノード
カウンター以外のの単遷移を流出するノードはＣ＝１と見做す。
（流入最短最長値の中で最少を採用する）
複数の流出があっても値は同じ
≪比較ゾーンの(単純)不能検定≫
比較ゾーンの開始トリガの期待時間の組（MNS MXS)と終了トリガ(MNF MXF)の範囲情報による不能検定。
MXF＜MNSなら不能。
MXS＜＝MNFなら完全成立。
修了トリガの期待時間範囲は(MNF/MNS|MNF＜MNS MXF/MNS|MXF＜MNS)に合成される。
≪単純カウンタの合成≫
N個の入力矢からN＞＝CのC回遷移を受けるカウンタの最短時間は遷移矢の最短値を小さい順にソートしＣ個採用した最大値とする。
通常の無時間ノードはＣ値を１とする。
N個の入力矢からN＞＝CのC回遷移を受けるカウンタの最長時間は遷移矢の最長値を小さい順にソートしＣ個採用した最大値とする。
通常の無時間ノードはＣ値を１とする。
複遷移の場合はカウンタ数で入力数を割った商に分解し二回目以降の値はそれぞれソートしたＮ×Ｃ個採用の最大値。
Ｃが範囲の場合は最短時間は範囲のそれぞれのＣ値の最大値の最小を採用。最長時間は同様のＣ値最大値の最大を採用。
≪条件付きカウンタ、トリガ依存トリガの期待時間合成と単純不能検定≫
被判定遷移期待時間が存在しない場合は条件遷移の値を利用する。
MN＜MX＜MNcなら不能。（Y/N）分岐ならNのみ遷移系統として残す。
MXc＜＝MN＜MXなら完全成立。（Y/N）分岐ならYのみ遷移系統として残す。
Y遷移（正値遷移）の期待時間は(MN/MNc|MN＜MNc MX/MNc|MX＜MNc)
N遷移の期待時間は（MN/MXc|MXc＜＝MN MX/MXc|MXc＜＝MX)
依存トリガの場合は生成トリガを条件とし被判定を受け取るトリガとする。
≪要素種別期待時間加算要素≫
期待時間合成を行って系列計算を行う。
＄期待時間合成参照
内部遷移を展開してチャートの一部となる。
一次的な計算が終了した後
$焦点比較ゾーン内外遷移チェック
を行い内部遷移と外部遷移の整合性を検証する（比較ゾーンの内遷移が全て終了トリガに集約している場合（させた場合）は一回目の計算でチェックは終わる）。
≪不定トリガ≫
いつ発生するか範囲ゾーン情報からでは推測出来ないトリガ。指定の無い場合は（+0 +∞）（+0 +∞）となる。
≪対象ゾーン開始トリガ≫
対象ゾーンの開始トリガ。（0 0）（0 0）となる。グローバル時間の相対化の為に開始GTMを入力できる。
≪単純加算トリガ≫
単純に時間経過させるトリガ。（+X +X）（+X +X）｜Xは指定値
≪グローバル時間≫
特定の固定の時間をトリガとする。開始トリガに開始GTMが入力されると単純加算トリガに、されないと不定トリガとなる。
≪隠蔽オブジェクト≫
終了状態ごとに期待時間加算情報を持つ。これは生成から終了トリガ発生までの内部ロジックによる情報である。
通常レセプタへの遷移を考慮に入れてオブジェクトが設計されている場合はステイタスの性質が合流ノード、単純カウンタ、遷移条件付きカウンタのどれか指定しなければならない。
ステイタス毎に保持する事も可能だが全体の情報に制約される。指定の無い場合は（+Z +∞）（X Y)｜X,Y,Zはアイコンに対するシステム規定値

Ｚ-11：焦点比較ゾーン内外遷移チェック（図６７参照）
イベントの時間的管理の枠組みであるモジュールとＴＺの内部処理と寿命設定など外部からの時間的制約の整合性チェックを行う。
１）＄対象/比較ゾーン遷移置換作業で比較ゾーンについて置換した遷移系列を抽出して外遷移とする。
２）タイムアウトや強制終了レセプタなどのゾーン強制終了イベントへの内部遷移を合流分岐への遷移としてそこから強制終了イベントへ単遷移を張る。
３）比較ゾーン外への遷移（モジュールのステイタスエミッタ含む）に仮想の端末を配置する。
４）２，３のレセプタ、トリガへの遷移の期待時間を計算する。
それぞれのMNI MXIとMNX MXX
MNSI MXSIとMNSX MXSX
で 開始トリガの代わりに
各内部遷移値を使って不能検定を行う。
$比較ゾーンの(単純)不能検定参照
１）全ての組が完全成立なら自動的に検証済みとなる。
２）一つでも不能ならチャートの修正が必要となる。
３）それ以外はチャートの修正か検証の承認を行う必要がある。
４）全てのゾーン外への遷移が検証済みとなったらその比較ゾーンは検証済みとなる。
・外部遷移によるタイムアウト等の強制終了イベントが無い場合は自動的に検証済みとなる。
・再計算の為に外部への遷移に対して
これを全ての可能な比較ゾーンに行い、全体の時間遷移の整合性を検証する。
複数のチェック可能な比較ゾーンが有る場合は遷移系列の上流にある
（外部遷移を他の未検証の比較ゾーンに依存していない）ゾーンを優先して行う。
内部に未検証の比較ゾーンを持たない比較ゾーンは焦点比較ゾーンとして内外遷移チェックを行う事が出来る。

Ｚ-12：実行動期待時間加算（図６８参照）
あるFZのトリガから対象ゾーン内への遷移矢が出ている時、別のFZの遷移矢が発出しているトリガへ移動時間算出矢を引くことが出来る。

発出トリガの期待時間にガイド計算による期待時間時間加算情報を載せて対象トリガの遷移による期待時間を置換する。
元々の遷移を開始トリガと見做して不能検定を行動時間算出矢に対して行う。
$比較ゾーンの(単純)不能検定参照
$焦点比較ゾーン内外遷移チェック
の検証スキームを使用して算出矢を検証済みに出来れば修正された期待時間情報を利用できる
ＦＺ間と同様に単純にあるトリガ、レセプタから別の対象ゾーン内のトリガ、レセプタに行動時間算出矢を引くことが出来る。
この時の所要時間情報は管理者が入力する。
加算は最短最長と標準範囲の双方或いは片方でもよい。加算されなかった値は元の値が残る。（実際の遷移系列が順列に連結されていない場合などは移動など物理的に完全に制約されない限り最短最長は利用しないか遷移を通す方が安全）

≪管理システムの動作≫
図５８には、「○○部」という記載を多用している。ここで、「○○部」とは、サーバ（コンピュータ）１０のＣＰＵが必要なソフトウェアをそのつど読み込んで実現するものである。したがって、「○○部」は、物の発明の構成要素である。

≪フィールドタイプモジュールの追加の実施例≫
以下、図６９から図７２までを用いてフィールドタイプモジュールを追加した実施例について説明する。
イベントの構成要素となる個々の最終的に場所と時間の範囲が確定するサービスを提供するモジュールの処理をスロットタイプに規格化することにより、イベント作成のさらなる簡易化を行うことができる。これによって多様なユーティリティ処理が可能となる。その際に使用するフィールド編集画面を図６９に示す。
図６９は、フィールド編集画面の例である。
図７０は、フィールド構造模式図である。
図７０を参照しつつ全体の構造を解説する。
フィールドはフィールドユニットと呼ばれる子モジュールを編集画面のスロットに配置する事によってイベントの処理を行う。
フィールドは全体処理モジュール或いは個別処理モジュールどちらの様相も持つことが出来る。またアトラクションとして他のフィールドの実行単位となる事も出来る。
フィールドユニットは時間と場所の特定された（特定されないものも可能であるがフィールドの機能は時間と場所の特定されたモジュールの制御を行う事に特化している）処理を行うアトラクション、フィールドの処理を行う制御モジュール（フィールドと一体化していても良い）、フィールドの処理に特定の機能を追加するユーティリティ（フィールドと一体化していても良い）の種別があり特定のスロットを使用する。
制御モジュールによって提供される制御タイプは時間順にアトラクションを実行（予定時刻指定可）するステージ、特定の地点にアトラクションが配置（場所アトラクション）されているスタンプラリー、場所アトラクションに生成順（予定時刻がある）があるツアー、アトラクションごとに生成条件と序列を指定するメイズ、その他の処理がある。制御のプロパティには割り込み指定と遅延管理、最適ルート算出の三種別がある。詳細は図７１に記載されている。
ステージタイプはスロットナンバー順に時間制約の範囲内でアトラクションを実行してゆく。各アトラクションの時間指定によって特定のアトラクションが実行不能と判明すると遅延管理が行われる。またアトラクションの並行実施は不可能であり、スロット付番を利用する。
ツアータイプはスロットナンバー順にアトラクションが実行される。前のナンバーの終了が次のアトラクションの開始条件待受けの条件となる。またアトラクションの並行実施は不可能であり、スロット付番を利用する。
スタンプラリータイプはアトラクションの開始条件が満たされるとそのアトラクションが実行される。複数のアトラクションは並行的に実施され得ない。またアトラクションの並行実施は不可能であるが、スロット付番は利用しない。
メイズタイプはアトラクションの開示条件が満たされるとそのアトラクションが実行される。アトラクション間の序列及び並行実施が可能かを指定する制御＃タグが発行される。 またアトラクションの並行実施が可能かどうかは制御タグによって指定され、スロット付番は利用しない。
制御の詳細として
割り込み指定はスロット付番が為されたタイプで指定されると指定されたアトラクションは独立に生成トリガが生起し、実行中の通常アトラクションは中断、もしくは終了後に指定アトラクションが実施される。別の制御タグが発行される。
スロット付番が無いタイプで指定されるとそのアトラクションは最適ルート算出から除外される。実施中のアトラクションを中断するか実施される。
最終アトラクション指定：この指定がされた制御タグで実行されたアトラクションが終了するとそのフィールドは終了する。
遅延管理はスロット付番が為されたタイプで指定されると指定されたアトラクションは独立に生成トリガが生起し、実行中の通常アトラクションは中断、もしくは終了後に指定アトラクションが実施される。別の制御タグが発行される。
スロット付番が無いタイプで指定されるとそのアトラクションは最適ルート算出から除外される。実施中のアトラクションを中断するか実施される。
最終アトラクション指定：この指定がされた制御タグで実行されたアトラクションが終了するとそのフィールドは終了する。
最適ルート算出はスロット付番がされない制御タイプに置いて割り込み指定されたアトラクションを除いて移動時間による経路探索を行い、最適ルートを算出する。また時間制約がある場合は時間制約のあるアトラクションの可能な組み合わせを場合分け計算として行い、その時間指定アトラクション間それぞれについて経路探索を行い（後の区間の経路計算では前の計算で使用したアトラクションは排除）その結果の全てで比較し最も時間の短いルートを最適と見做す。
全結果ではなく条件を緩和して計算時間を短縮しても良い。

図７１は、制御モジュールプロパティ詳細を示す図である。
制御モジュールの制御フローは図７１下部に記載の通りで開始された処理は各フィールドユニットのタグ記述を読み取り、制約情報を読み取り、その情報を基にアトラクションの時空配置の最適化を行い、開始条件がそろったアトラクションを呼び出し実行して行く。この条件は場所と時間、属性条件がすべて満たされなければならない。図７１にあるように一定時間ごと、アトラクション終了時に時空配置の再計算が行われる。また割り込みアトラクション処理が割り込み指定条件を満たせば発生し、フィールド終了条件が満たされると過程は終了する。
なお、アトラクションの開始条件はシンプルな条件（属性制約が参加者属性のみで行われ、タイミング設定が使用されない制御（トリガや条件が独立）＞生成管理は全て制御Ｍの内部挙動で行われる。制御モジュールでシンプルな条件を要求するものが有る場合はこの設定がなされ属性制約と時間制約のモードの選択制限がなされる）を選択可能である。
また逆に遷移矢や遷移を制御するマーカー配置から依存関係を解析しその順序条件を制御に取り込んでも良い。
制御タイプと制御プロパティの詳細は図７１を参照されたい。

図７２は、場所／時間制約の指定を説明する図である。制御モジュール/フィールド編集画面主機能が図７２に描かれている。また、記述の時間場所制約が説明されている。
制御モジュールスロットは、パレットのフィールドユニットを配置可能なスロットである。ユニットの種類によって配置可能なスロット位置が異なる。アトラクションスロットとユーティリティスロットには複数のユニットを配置できる。（下方に延長してゆく）
アトラクションスロットにはスロットごとに付番がされている。この付番（マーカの順位づけ）は明示的でなくともスロットの位置、順序を明示する配置が必須のマーカーやタグなどで実現されても良い（割り込み指定アトラクションは除外）。自動的に並べ替えを行っても良い。
ユニット♯タグフォームは、スロットに配置されたフィールドユニットのタグ情報を編集するフォームである。ユニット内部タグを抽出表示し、制御タグを書き込む。内部タグはここでは編集不能。ここを検査して制御モジュールは制御を行う。
制御タイプとプロパティは、制御タイプ、制御プロパティ、ユーティリティ提供プロパティ、フィールドの（内部設定）制約の設定を行い、制御＃タグをフォームに表示させる。
ユーティリティ提供プロパティは、フィールドのスロットに配置されたユーティリティのプロパティ設定フォームである。制御と密接に関連したプロパティはこちらで制御可能である。
制御♯タグは、制御モジュールがアトラクションやユーティリティを特定管理する為のタグである。タグフォームに配置する。図７２を参照。
また制御タグの役割はグラフィックなマーカーによって実現されても良い。
時間、場所制約、属性制約は、内部制約編集用のフォームである。フィールド用と各アトラクション、ユーティリティ用がある。図７２を参照。
属性制約は、対応するモジュールのメンバ制約を行う。インターフェイスはメンバ制約部と同じである。
時間制約は、対応するモジュールの時間制約を行う。時間制約は実施時には絶対時間範囲でタイムインアウトされるタイムゾーンと同じ働きになる。アトラクションやモジュールの内容による制約に対する条件、管理者が個別に設定する条件を加味して実施時の確定を行うため六つのモードによる設定を行う事が出来る。
制御モジュール管理はアトラクション側で詳細な指定を行わずアトラクションのカテゴリー情報などから最適な時間範囲を制御モジュールが行うモードである。
配置時間帯-必要時間指定はそのアトラクションに必要な推奨時間を必要時間として指定し、その時間が配置可能な時間帯を絶対時間指定、曜日やデイリーの時間帯情報などで指定するモードである。これは双方必ず指定せずとも良い。その場合非指定は制御モジュール管理と同様の扱いとなる。
絶対時間指定はアトラクションの開始時間とタイムアウト時間を絶対時間で指定するモード。
リスト指定は複数の絶対時間指定、或いは配置時間帯-必要時間指定のリストで指定するモード。
データ/属性配置は指定を配置されたグラフィックオブジェクトの値で行うモード。
タイミング設定はタイミング設定部を配置するモード。
場所制約は、対応するモジュールの場所制約を行う。時間制約は実施時にはある範囲指定されたフィールドゾーンと同じ働きになる。アトラクションやモジュールの内容による制約に対する条件、管理者が個別に設定する条件を加味して実施時の確定を行うため五つのモードによる設定を行う事が出来る。
制御モジュール管理はアトラクション側で詳細な指定を行わずアトラクションのカテゴリー情報などから最適な場所指定を制御モジュールが行うモードである。
配置範囲-形状指定はそのアトラクションに必要な場所の大きさと形状を指定し、その場所が配置可能な範囲を指定するモード。これは双方必ず指定せずとも良い。その場合非指定は制御モジュール管理と同様の扱いとなる。制御モジュールアトラクション配置フローの地図タイル指定タイプ確定プロセスと場所範囲情報のリスト化プロセスでリスト指定に帰結させる。
ＦＺ指定は特定のフィールドゾーンを指定するモード。
リスト指定は複数のＦＺ指定、或いは配置範囲-形状指定のリストで指定するモード。
データ/属性配置は指定を配置されたグラフィックオブジェクトの値で行うモード。
個別の条件は絶対的な指定、範囲・リストから制御可能な確定値を制御モジュールが指定、属性やライブラリデータによる外部の条件（データ不定指定）、制御モジュールによる完全管理の四方式（５〜６モード）で指定される。最終的に制御モジュールが確定する方式は制御不定指定と呼ばれる。
ステイタストリガ/レセプタ、属性（データ）レセプタ：アトラクション及びユーティリティはその個別の挙動を制御する為にモジュールのステイタストリガ/レセプタ、属性（データ）レセプタに対応するアイコンを装備できる。その詳細はアトラクションの内部記述によって決定される。
これにはステイタストリガとステイタスレセプタ、属性レセプタ、ライブラリデータレセプタの四種類があり、モジュールの同等の機能部（Ｃ−２図、３-14図）と同じインターフェイスを持つ。
予約（属性）レセプタ/トリガとフリー（属性）レセプタ システム制御オブジェクト
予約（属性）レセプタ/トリガは制御モジュールが使用するレセプタ/トリガで制御モジュールが専有する。属性を配置する事も遷移矢の終点とする事も出来ない（エミッタは配置可能）。どのレセプタが予約となるかは制御モジュール毎にステイタス及びレセプタ、属性（データ）レセプタの付番によって決定される（制御モジュールの要求する機能仕様をアトラクション、ユーティリティは満たして設計されなくてはならない）。
またシステムの用意したアトラクション、ユーティリティの挙動管理に使われるオブジェクトもある。これを非表示制御オブジェクトとし、生成、遷移不生成、強制終了、所属フィールドゾーン、所属タイムゾーンがこれに当たる。
フリー（属性）レセプタは編集者が遷移矢や属性アイコン、エミッタを配置可能なレセプタ/トリガでユーティリティやアトラクションの稼働の詳細を決定する為にある。これは予めアトラクションやユーティリティで用意しなくてはならない。
これらの予約（属性）レセプタ/トリガ、フリー（属性）レセプタの指定はアトラクションのカテゴリー情報によって決定され、そのカテゴリー情報を基に制御モジュール、ユーティリティがそれぞれのステイタスやトリガのステイタスエミッタ/ステイタストリガロジックによって予約された付番情報と関連付けられて処理されるが、レセプタやトリガの序列情報、予約名称情報によって識別されても良い。
遷移矢とエミッタ、属性（データ）
遷移矢とエミッタを編集画面の幾つかの箇所に配置結合可能。
遷移矢起点：画面内の全てのステイタス
遷移矢終点：予約を除く画面内のトリガとタイミング設定
ステイタスエミッタ：画面内の全てのステイタスとトリガ、タイミング設定
属性エミッタ：配置された全ての属性アイコン
属性（ライブラリデータ）アイコン：予約を除く属性レセプタ、属性制約
アトラクション内部編集
アトラクションは内部の編集画面を開いて内容を編集できる。アトラクションタイプのモジュールは場所制約、時間制約を内部で編集出来るようサブ編集画面が用意されている（外部モジュールの場合はプロパティ設定画面に統合、ネストタイプは設定バーから呼出し）。
またアトラクション紹介用のモジュールを指定できる（そのモジュールは制約と関係なしに呼び出すことが出来る（ステイタストリガ１からの遷移で指定）。
ユーティリティ内部編集
ユーティリティは内部のプロパティ設定画面を呼び出しプロパティを編集する事が可能。制御モジュールプロパティの編集とは相互に反映し合う。
パレット
フィールドのパレット配置オブジェクトには一定の制限が掛かる。
コンテントパレット：フィールドユニット、属性条件モジュール、タイミング設定モジュール
属性パレット：制限なし
処理パレット：通常遷移矢のみ
ステイタスエミッタパレット：制限なし
ライブラリデータパレット：予約以外のデータレセプタが配置されているなら対応するデータが配置

主要ユーティリティを解説する。
未来タイムラインは、フィールドおよびアトラクションとして配置された子フィールドの推定アトラクション開始時間情報と関連情報を抽出してタイムライン或いはリストとしてユーティリティ配置フィールド実施中は表示できる（待機可能）。また関連サービスを実施する。
タイムライン／リスト表示は、ユーザサービスページもしくはページ集としてタイムラインもしくはリスト（開始時間情報が無い時）としてアトラクションタイトルと編集されたコメントが表示。一部を選択すると（タブを選択すると）紹介用モジュールが呼びだされる。（部分的なタイムラインがあれば混在して表示可能）
並行処理が可能或いは相互に割り込みを行う設定ならツリー状になる場合もある（連結情報を示した部分ＴＬ表示）
部分的なタイムラインは、ユーザの指定やメイズなどの一部、経由アトラクション情報などによって一部にタイムラインが成立する場合がある。開始時間が特定されているならそれを表示、無ければＴＬの最初のアトラクション開始時点からの時間表示を行う。
アラーム設定は、アラーム対象としてアトラクション（やフィールドの開始、終了など）を指定すると推定アトラクション開始時間情報から指定した時間を遡ってアラームを行う。最優先表示されたページが呼び出される。また定期走査時に遅れ（終了時刻の追加差分）が一定時間以上なら遅延警告も行う。
実施アトラクション選択は、参加者がタイムライン／リストから実施する或いは優先/劣後するアトラクションを指定する機能である。これが為されると推定アトラクション開始時間情報は参加者の選択に従って再計算される。
《注意》期待時間計算で何らかの手段で指定したモジュールの表示遷移系列を正規、最短、中間、最長などのロジックで抽出してその開始時刻を推定アトラクション開始時間情報として使用しても良い。
ガイドは、タイムライン上の移動及び現在位置から指定したアトラクション、指定ポイントへの移動時のガイドを提供する。また配置された通常ガイドモジュールを関連モジュールとして挙動管理し同時に複数のガイドが立ち上がらない様に管理する。アトラクションゾーン内では通常ガイドを優先する。
移動時間提示は、現在位置からフィールドおよび子フィールドに配置されたアトラクションまでの移動時間情報を提供する（タイムライン/リストに追加表示）。
経由アトラクション情報提示は、タイムラインが存在しないフィールド内では推奨移動ルート或いは全てのルートが特定のアトラクションのゾーン内を通過していた場合、経由アトラクション情報として制御モジュールに提供を行う。利用設定が為されていれば部分的なタイムラインとして使用される。
ユーティリティポイント誘導は、マップ上に配置された特定のカテゴリーのユーティリティポイントリストから特定の条件で選択された指定ポイントへの誘導を行う。指定ポイントが確定したら割り込みアトラクションとして登録され、タムライン、ルート算出に組み込まれる。また特定のアトラクションと関連付けする事が出来、到着したらそのアトラクションが指定ポイントを場所ゾーンとして呼び出される。アトラクションの指定は発行される制御#タグで行われる。指定ポイントは最適条件のグループの中から距離、移動時間、ユーザの選択などによって決定されても良い。
サービス画面呼出しＭ（関連Ｍ）は、アトラクション内に配置された画面呼出しＭが踏まれたら指定ポイント指定画面が呼び出される。
指定ポイントは、指定方法は条件に適合する最も移動時間が短いポイント、参加者指定の何れかで行われる。また緊急かどうかも設定可能で緊急なら直後に割り込み、そうでないなら最適化されてタイムラインに組み込まれる。
グループ管理Mは、複数の参加者をグループ化し、グループ行動に必要なユーティリティを提供する。ユーティリティが持つグループ化アトラクションがフィールドの最初に割り込みされ参加者が指定の方法でグループ化される。
アトラクション呼出し条件設定は、アトラクションの呼出し、終了条件をグループ処理との関連で詳細設定できる。全員、先頭到達者、一定率指定、迷子指定除外の四種類から選択設定。
迷子処理は、位置走査時にグループの重心位置、或いはリーダー指定されたメンバーから一定以上の距離やその偏差値のメンバーが迷子指定される。迷子指定が一定比率以上の場合は状況確認画面が送られ、迷子処理対象の確定、もしくは一時的なグループ分割を行う。分割されたグループは一定範囲以内に集合した場合、合同確認が行われる。また迷子は緊急対応モジュール/ユーティリティ/アトラクションが指定されているならその呼び出しを行う事が出来る。専用ページが呼び出される。以上の処理はグループ参加者の位置座標でクラスター分析を行い複数のグループ内グループメンバと重心を算出して迷子指定（全ての重心からの距離や偏差）、グループ分割を行っても良い。クラスター分析は当初のグルーピング時にも利用して推定グループの提示を行う事にしても良い。
Ｗｅｂステージ（ライブストリーム）は、イベントに対応したライブストリーム閲覧用のwebページを生成する。取得する情報は関連モジュールをアトラクション中二配置して行う。ページではイベントや取得情報、参加者に対する評価を行う事が出来る。
アップローダ（関連モジュール）は、参加者端末、関連付けされた録画機器などにより取得したデータをストリームページに送る。
参加者評価表示は、参加者にwebページでの評価情報を提示するページを生成するモジュール。アトラクション中に配置されてユーザにページを提供する。
Ｗｅｂデータ連携は、遅延管理や情報提示の為にｗｅｂシステムで生成された情報を取得、属性やライブラリデータの形で提供するユーティリティ。フリー属性レセプタで情報の受け渡しを行う。鉄道の時刻表情報、店舗等のチェックイン情報など。

未来タイムライン表示、ユーティリティポイント誘導、グループ管理は、本発明における技術事項として抽出かのうである。
場所イベント管理モジュールを特定してその場所と時間制限情報を規格化する事によって管理プログラムによって自動的に各場所イベントの開始もしくは想定開始時間を算出管理するモジュールである。
それによって遅延管理、推奨ルート設定、未来タイムライン表示などが可能となる。

≪全体処理≫
図７３以降を用いて、全体処理について説明する。
全体処理のクラス構造を整理し相互作用の記述を行い易いようにメンバスコープの対象を個別記述対象とインスタンスに整理し、編入の方法も変更した。図７３は全体処理の処理構造を整理記述したものである。
相互作用の主体において個別記述対象とあるのは参加者及び一部の機器を処理の参加者として処理対象とする事を定義したものである。個別記述対象は図中段の個別記述によって管理駆動される。個別記述の実体は個別記述タイムゾーンと個別記述モジュールである。
その個別処理対象は相互作用の様相を記述する全体記述にメンバースコープとして編入され相互作用を行う。相互作用の管理はインスタンス或いは後述のキー、メンバースコープのメンバを属性値の保持対象とする全体処理属性によってなされる。
その関係を記述したのが相互作用の場である。全体記述は全体処理タイムゾーンと全体処理モジュールが担う。
その記述の挙動は図中、相互作用の様相によって定義される。相互作用の記述は上段一般化にある通り全体記述の中にメンバースコープのメンバの挙動を記述する個別記述が入れ子となって配置されメンバーの属性やタイプ、遷移によって異なった記述が割り当てられる。また特定のメンバー間の相互作用を記述する為にサブ全体記述がより限定されたメンバースコープを割り当てられ記述される。
個別記述が相互作用の何を反映するかは中段の幾つかの様相に表現されている。
抽出され限定されたメンバー間の相互記述はメンバースコープの抽出と個別の場で発生した価値をより上位へ持ち込むために使用される全体処理属性によって行われる。
全体処理属性：全体処理属性の挙動と相互作用のトランザクションを確保するキーの挙動は図７３と図７４に記述されている。
図７３は、相互作用の主体、相互作用の場、相互作用の様相を示す図である。
図７４は、シナリオ（全体処理）属性を示す図である。
通常のシナリオ属性は図７４にあるようにシナリオの全ての個別処理対象を潜在的な属性値保持の対象としている。
一方全体処理属性は三種類に分けられ、あるメンバースコープのメンバである個別記述処理対象を属性値の保持対象とするメンバースコープ属性、キーや（キーが定義されていない場合は）インスタンスを属性値保持対象とするインスタンス型属性とグループ型属性である。グループ型はインスタンス型とはメンバースコープの保持形態が異なり異なるキー、インスタンスのメンバースコープの構成員が重複しない。
属性情報の参照は属性アイコンが配置されたゾーンによって異なる。図７４中央の記述にある通りインスタンス/グループ型はキーを割り当てられた全体、個別記述中では該当するキーが保持する個別属性値が参照され、それ以外では属性のメンバ全ての属性値が配列として参照される。一般及びメンバースコープ属性は対象の個別記述内では対象の個別属性値が参照される。インスタンス型のメンバースコープの場合は配置場所によって上位（最下層）の全体記述のインスタンスの所属するキーの個別属性値或いはキーに制約された個別属性値の配列（個別記述外）が参照される。上位にキーを持つ全体処理記述が存在せず、複数の属性値を持つ場合はその個別処理対象の保有する属性値の配列参照となる。
全体処理属性は図７４に記載のメンバー情報を持ちうる。
キー：キーはある全体処理属性の一部のメンバーとインスタンスに割り振られるトランザクション識別用のコードで属性は複数のキーを保持できそれぞれにメンバースコープが定義されている。キーは個別処理対象のみならずインスタンスもメンバースコープとして保持できる。図７５キーの構造にはキーの保持するプロパティが記述されている。キーはキーを共有する全体処理属性を複数持ち得る。属性相互の準拠によってあるキーのセットを持つ属性群はキー関連情報の同期によってメンバースコープとキーのセットを共有する属性のクラスターを形成する。この過程は図７４のシナリオ属性の準拠とキー継承に記述されている。
キーは準拠もしくはある記述のトリガレセプタ上への配置によって発行される。図７５のトリガ/レセプタ上への配置及び属性準拠時のＭＳとキーにはその詳細が記載されている。
またキーを保持する属性で制約された或いはキーを保持する全体処理遷移によるインスタンスの生成遷移をコネクタや通常の全体遷移によって行う事によってキーのインスタンスメンバースコープに生成したインスタンスを編入する。７６図参照。
編入されたインスタンスの記述ではキーに属するメンバースコープを対象に処理を行う事が出来、インスタンス記述および個別記述主体の個別記述ではキーに関連する属性値を利用してそのメンバースコープ固有の処理を行う事が出来る。 図７５の下段には準拠の新方式が記述されている。準拠矢にプラスとマイナスの種別を導入。単指定と複指定の種別を無くして複数指定に統合。プラスの矢の準拠先（複数）とマイナスの矢の準拠先（複数）の準拠評価時点での集合計算を行いメンバを確定する。
図７５は、キーの構造、属性準拠時のＭＳとキーを示す図である。
図７６は、全体処理での遷移を示す図である。
キー及び全体処理を利用した遷移処理：図７６には全体処理での遷移処理の特徴が記述されている。全体処理単遷移はキー毎に一回の遷移を行う事が出来る。図左、中央には処理アイコン、インスタンスを持ちうるシナリオオブジェクト（図７４左下段参照）通過時のキー情報の保持方法が記載されている。
図７６右にはコネクタのメンバ遷移部の挙動が記述されている。コネクタのメンバ遷移は個別記述メンバースコープのメンバ個別処理、キー毎に一つの記述インスタンスを生成しうる。

アイコンを、遷移を表現するグラフィックの適切な位置に配置する事によってイベント処理時に相互作用のトランザクション(セッション)処理用のキーを自動生成する方法或いはそのキーを利用する対象を確定する方法は、本発明の特徴的な技術事項である。

≪記事の新仕様≫
図７７は、記事新仕様を示す図である。
記事の新仕様においてはｈｔｍｌエディタによる編集を基本とし、そこに制御用のタグを挿入する形式に変更する。図７７にはその仕様が記述されている。編集画面はhtmlエディタとステイタス生成/合成フォーム、管理用ボックスで構成される。
左のエディタにhtml記述を行い、中央のフォームでエミッタに対応したタグを生成、或いはエミッタの合成を行う。
フォームにはフィックスチェックボックス、生成ステイタス選択、フォーム、ステイタスアイコン生成チェック、コメント欄がある。
生成ステイタス選択をプルダウン等によって行い、フォームのモードを選択するとフィックスが可能となる。フィックスが行われると次のフォーム（ブロック）が出現する。詳細は図７７を参照。エミッタの機能については次項を参照。
またフォームには埋め込み用のｈｔｍｌタグか、ステイタスの合成が行われるならステイタス配置ボックスが出現する。
ステイタスはその記事の発行ステイタスに対応するが、記事アイコン上にステイタスとして表示されるかはコントロール出来る。
ステイタスの合成においては配置されたステイタスアイコンのどれかが踏まれる、或いはその全てが踏まれる事によって生成ステイタスが発行される。
属性エミッタは画面上の入力フォーム或いは表示データ或いはスクリプト等で利用されるデータインポートに対応する。
またフォームの生成ステイタスのアイコンはドラッグ＆ドロップが可能でステイタス配置ボックスに配置可能となる。
アイコンを使用してHTMLエディタにリンクやデータ受け渡し用のタグを簡易に生成する方法(請求項としては次項ステイタスエミッタに依存)が可能である。

図７８は、エミッタとステイタス、フィールドゾーンの範囲指定を示す図である。
ステイタスエミッタによるモジュールのステイタス及び属性レセプタ生成する。
モジュール中に配置可能なエミッタは四種類ある。正規ステイタスエミッタ、非正規ステイタスエミッタ、属性タブ引数エミッタ、属性タブ戻り値エミッタである。詳細は図７８左を参照。
トリガ/レセプタに配置されたステイタスエミッタはモジュールアイコンにステイタスを生成する。遷移モードのシナリオ属性に配置された属性タブエミッタはアイコン上にシナリオ属性を配置可能な属性レセプタタブを生成する。タブは引数タブと戻り値タブが存在し、引数タブは配置された属性値を内部のシナリオ属性に遷移評価時に代入し、戻り値タブは配置された属性値に内部遷移評価時に代入を行う。

グラフィカルにモジュール内外のイベント処理と引数、戻り値を設定する方法は、本発明に特徴的な技術事項である。

≪フィールドゾーンの範囲確定の新仕様（タイル選択方式）≫
範囲指定の簡易化及び実施時の計算量削減の為にマップに予め指定したタイル領域を設定し現在地測定を行った参加者端末を特定のタイルに関連付けタイルが移動した時だけ再計算を行う事によって計算量を削減する方式に変更した。
範囲指定：フィールドゾーンの範囲指定はマップを埋め尽くす多角形のタイルを指定する事によって行う。図は一部を東西にずらした方形のタイル指定。緯度によってタイルの面積を変える事無くずらす長さを調整する事によって大体の関係を維持する。
タイル表示がなされたFZの範囲設定画面からタイルを指定する事によって範囲を特定する。
基準タイルと実効タイル：測地システムの精度に問題がある時及び計算量の削減の為にユーザが指定する基準タイルより大きめの実効タイルを設定する事が出来る。実効タイルによって実際の所在タイル登録がなされる。実効タイルは複数の種類を用意して良く再計算の頻度を削減する為に参加イベントのＦゾーンが離れている時は目が粗く、接近すると目の細かいものを使用する。（参加者タイプによって変更しても良い）
ＦＺの範囲判定は基準タイルの指定範囲を包括する実行タイルの判定範囲を使用する。
所在タイル特定：一定時間ごとに位置情報の取得を行い、所在タイルを特定する。
所在タイル情報を基にその変更がある度フィールドインアウト判定、イベントでアクティブなフィールドゾーンのクラスタとの距離計算を行う。
距離計算の結果によって実効タイルの大きさや所在走査時間間隔の調整を行う。これによって計算量を削減する。
距離計算は重心や長径や方位径の中間値など代表点間に軸を形成し最も近い範囲端の軸上投影位置や範囲端の座標からの距離を実効距離とするなど通常の緯度経度からの計算でもよいし多角形タイル配置の方位に関する特性から（経路探索方向の制限や特定方向に対する同一距離タイルの設定などで）間隔タイル数を計算して概算値を算出するなどしても良い。
また所在タイルの変動を最小限に抑える為、周囲にマージンを設定しその範囲内で位置情報が取得されたなら所在タイルを変更しないとする。この処理の回数に制限を設けても良い。
図７９は、ユーザ画面デザイン（ブラウザ、アプリ）を示す図である。

参加者の位置情報処理について所在タイル登録処理とイベント処理用タイル指定を行う事によって計算量を削減する方法は、本発明に特徴的な技術事項である。

≪参加者画面の新仕様≫
参加者の操作の利便性の向上の為、図８０のように仕様を変更。操作アイコンを廃止してページをランディングページ化した。請求の別実施例として登録。
請求項の要件からスクロール管理アイコンを外す改善(タブのリストとページを結合したランディングページを相互に遷移させ、斜め或いは扇状の(その方向にスクロールする引き出し式の)遷移バーを利用)をした。これは本発明に特徴的な技術事項となる。
図８０は、ユーザ画面の領域を説明する図である。
１） 新仕様においても段落０２４２に記載した１）のように上下からタブを引き出すことが出来る。これで画面下方の親指の根元を起点とした扇状の領域で操作を完了できる（左右に反転可能）。必要ならＢモードのＢ-1領域は下方に位置を設定可能とすることも出来る。またステイタス/エミッタによって識別されたページの重要操作項目を集約したポップを下部操作域に出現させる事も出来る。
２） Ａモード、Ｂモードの閲覧時に上下に羅列したページ要素リストのどの位置を閲覧しているか簡易に把握出来るようにタブ領域、間隔領域に位置を示す数値や記号、位置によって変化するキャラクター、配色や輝度など色調がグラディエーションするカラーリング領域を持ちうる。これはタブの位置でも全てでも、配色ならページの種別によって色系統を変化させても良い。

≪解釈構造体について≫
解釈構造体の出力及び入力についてはマークアップ言語、または構造を入れ子で記述出来る、或いはＪＳＯＮ（javascript object notation) の様なオブジェクト構造を記述できるデータ記述言語を利用することが出来る。この場合、記述を包含するゾーンに対応するオブジェクトの記法が設定され、入れ子構造もしくは所属関係を示すリスト情報が付加される。

≪高度管理について≫
レベル２高度管理の手法について
１）段落００４７正規、不正規管理と例外管理を区分し、例外発生時は段落０１８２例外管理によってイベント管理者が集中的に管理できるようにすること。
２）段落０１２３拘束選択ステイタスの設定により必須操作が為されねば所属オブジェクト終了のタイミング設定で確認可能な指定時間、指定時間経過後、或いは例外確認トリガ発生後に例外が発生すること。
３）段落０１２８例外終了マージンもしくは時刻指定など独立に予測可能な形で発生する終了については注意喚起を配信やアラーム、サービス画面表示の変化で警告するなどの実施例の機構を例示した。
４）段落０２４８期待時間計算、フィールドモジュール内制御によって内部のモジュールの終了時間予測が可能となった高度管理コンテントについてはその予測時間に従って警告を行う事も出来る。

本システムは、団体旅行、グループ旅行、旅行社が企画するツアーガイド（図３７参照）、出版記念パーティ、賀詞交換会、名刺交換会、誕生バーティ、オフ会、クイズ大会、音楽コンサート、ライブコンサート、スポーツ観戦、スタンプラリー（図３５、図３６参照）、オリエンテーリング、携帯端末を使用した複数参加者のコミュニケーションや競技を行うゲーム、結婚披露宴、同窓会などにも応用可能である。

本願は、原出願の特許査定から３０日以内に特許庁に提出した分割出願である。原出願は、２０１９−５１２３２９であり、その国内書面提出日は、平成３１年３月１日である。原出願は、国際出願日が２０１８年１２月２７日、優先日が２０１８年１０月１５日であるＰＣＴ／ＪＰ２０１８／０４８１１８を日本国に国内移行したものである。
そして、本願と同日で特許庁に提出した分割出願は、全部で１０件ある。本願は、その１０件のうちの２件目である。分割出願が１０件あるうちの１件目は、出願当初の請求項数が３０項であり、２件目（本願）、３件目、４件目は、出願当初の請求項数がそれぞれ３項であり、５件目から１０件目までは、出願当初の請求項数がそれぞれ１項である。
以下、出願人、特許庁、第三者の便宜のために、親出願の出願当初の請求項、親出願の特許査定時の請求項、本願の請求項を転記する。

≪親出願の出願当初の請求項≫
≪請求項１≫
イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、及び
前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩ
を格納するＡＰＩデータベースと、
イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
イベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
前記生成されたイベント実行プログラムのうち、当システムにおける実行可能性の所定基準及び管理者が任意で設定するイベントの妥当性基準に適合するイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
ネットワークを通じてイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部とを備えたイベント管理システムであって、
前記イベント実行プログラムのモジュールを、ネストしたシナリオであるとして扱い、モジュールによって重層化されたオブジェクトの動作を各モジュールに付属するシナリオチャートに前記イベント生成者がグラフィックに記述するものであり、
前記オブジェクトとして、タイムゾーン及びフィールドゾーンを含むゾーンと呼ぶオブジェクトを用いるものであり、
前記シナリオチャートをグラフィックに記述するためのアイコン及び記述子を用いるものであり、
前記イベント管理システムは、さらにチャート図解釈部を備え、
前記チャート図解釈部は、
完成したチャート図において、前記タイムゾーンの構造、前記チャートに配置されたフィールドゾーン情報、コンテンツおよび前記記述子の前記タイムゾーンに対しての包含関係、コンテンツおよび前記記述子の他のアイコンへの部位配置情報、及び前記遷移矢の結合関係（前記アイコンおよび前記アイコン部位）を解釈し、
これらにより、マークアップ言語によるプログラミングと同等のチャート解釈を実現することを特徴とするイベント管理システム。
≪請求項２≫
イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、
及び
前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩ
を格納するＡＰＩデータベースと、
イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
イベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
前記生成されたイベント実行プログラムのうち、当システムにおける実行可能性の所定基準及び管理者が任意で設定するイベントの妥当性基準に適合するイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
ネットワークを通じてイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部とを備えたイベント管理システムであって、
前記イベント実行プログラムのモジュールを、ネストしたシナリオであるとして扱い、モジュールによって重層化されたオブジェクトの動作を各モジュールに付属するシナリオチャートに前記イベント生成者がグラフィックに記述するものであり、
前記オブジェクトとして、タイムゾーン及びフィールドゾーンを含むゾーンと呼ぶオブジェクトを用いるものであり、
前記シナリオチャートをグラフィックに記述するためのアイコン及び記述子を用いるものであり、
前記イベント管理システムは、さらにチャート図解釈部と解析構造体生成部とを備え、
前記チャート図解釈部は、
完成したチャート図において、前記タイムゾーンの構造、前記フィールドゾーンの構造、前記チャートに配置されたフィールドゾーン情報、コンテンツおよび前記記述子の前記タイムゾーン又はフィールドゾーンに対しての包含関係、コンテンツおよび前記記述子の他のアイコンへの部位配置情報、及び結合関係（前記アイコンおよび前記アイコン部位）を解釈し、
前記解析構造体生成部は、
前記チャート図解釈部が解釈した情報に従って、
前記タイムゾーン又はフィールドゾーンの入れ子関係を解析してプレーンのフィールドを最上位タイムゾーン又は最上位フィールドゾーンとしてプロパティ情報と共に構造化し、
前記フィールドゾーン又は前記タイムゾーンを参照情報として追加し、
それぞれの前記タイムゾーン又は前記フィールドゾーンに包含されたコンテンツおよび記述子を構造体の該当位置に要素としてプロパティ情報と共にリスト化し、
部位配置された前記アイコンを各要素（プロパティ）の子要素として追加し、
遷移情報をプロパティと指示情報として双方向から追加し、
これらにより解析構造体を生成し、チャート、すなわちモジュールに固有の構造体とし、マークアップ言語によるプログラミングと同等のチャート解釈を実現することを特徴とするイベント管理システム。
≪請求項３≫
前記イベント生成者が複数存在し、それらを管理者ユーザとして扱い、イベントを利用する一般ユーザと、イベントを生成する管理者ユーザとを区別して扱い、
前記イベント管理システムは、さらに管理者ユーザが一般ユーザに対して付与する利益であるポイントや称号を管理するポイント管理部を有し、
前記ポイント管理部は、
個々のイベント利用時に管理者ユーザが設定するポイントや称号を他の管理者の生成するイベントに持ち越せることを特徴とする請求項１又は請求項２に記載のイベント管理システム。
≪請求項４≫
前記イベント生成処理部は、
前記イベント生成の際に、管理者ユーザが行うシナリオ作成は、フローチャートを配置する様にグラフィカルに行うことが可能であり、操作はオブジェクトを収納したパレットブロックからチャートを配置するフィールドブロックにドラッグ＆ドロップすることによって実現することを特徴とする請求項１から請求項３までのいずれか１項に記載のイベント管理システム。
≪請求項５≫
前記イベント生成処理部は、
前記ドラッグ＆ドロップの操作の際に、現実の配信時に問題となる時間と場所の制限を取り込み、実現不可能な場合には、当該操作が不能であることをビジュアルに操作者に通知することを特徴とする請求項４に記載のイベント管理システム。
≪請求項６≫
前記イベント管理システムは、前記イベントが実行されている際に前記一般ユーザが当該イベントに参加することを処理する一般ユーザ参加処理部をさらに有し、
前記一般ユーザ参加処理部は、
前記一般ユーザが参加者として行動して、管理者ユーザが生成したイベントにトリガ発生をする処理をアイコンを画面上に配置することにより実行することが可能であることを特徴とする請求項１又は請求項２に記載のイベント管理システム。
≪請求項７≫
前記イベント生成処理部は、
イベントに必要な計算処理や条件処理を条件評価矢と代入矢によるオブジェクト間の遷移、すなわち結合操作で実行可能とすることを特徴とする請求項４に記載のイベント管理システム。
≪請求項８≫
前記イベント管理システムは、前記イベントに参加する前記一般ユーザの相互作用を管理する一般ユーザ相互作用管理部をさらに有し、
前記一般ユーザ相互作用管理部は、
複数参加者間の相互作用を管理する全体処理用のグラフィカルな作成アイコンを利用してメンバスコープの遷移系列での都度評価を通じてその時点のサービス対象者を確定可能であることを特徴とする請求項４から請求項７までのいずれか１項に記載のイベント管理システム。
≪請求項９≫
前記イベント管理システムは、前記イベントに参加する前記一般ユーザの行動を確認するユーザ行動確認部をさらに有し、
前記ユーザ行動確認部は、
前記一般ユーザが二次元バーコード、一次元バーコード、ＩＣチップ、ＲＦＩＤ又は赤外線情報などのうちのいずれか一つを端末で読み取って送信することにより、前記一般ユーザの行動を確認可能であり、
前記イベント生成処理部は、当該処理を可能とすべく、前記一般ユーザの行動確認をアイコンを利用してシナリオに組み込み可能とすることを特徴とする請求項４から請求項８までのいずれか１項に記載のイベント管理システム。
≪請求項１０≫
前記イベント生成処理部は、前記一般ユーザの行動管理に必要なメッセージ配信を重要度に応じてユーザに認識させるよう、シナリオ作成し、
前記ユーザ行動確認部は、前記一般ユーザの行動管理に必要なメッセージ配信を重要度に応じてユーザに認識させるよう、シナリオ実行中の前記一般ユーザの行動遷移の管理を行う
ことを可能としたことを特徴とする請求項９に記載のイベント管理システム。
≪請求項１１≫
前記イベント生成処理部は、タブとスクロール管理アイコンを利用した親指のみで携帯タッチパネル操作を行って、イベント生成又はイベント参加が可能なユーザインターフェイスを有することを特徴とする請求項１から請求項１０までのいずれか１項に記載のイベント管理システム。
≪請求項１２≫
前記イベント生成処理部は、
前記シナリオを記述するに際して、基本記述（レベル１）、高度管理導入（レベル２）、全体処理導入（レベル３）と三層のレベルの制限をユーザインタフェースもしくはユーザ資格でコントロールするように構成し、
基本記述（レベル１）では、ユーザの行動を制約せず行動に従ったガイドを行い、 高度管理導入（レベル２）では、ユーザの行動をイベントの進行のために制御し、
全体処理導入（レベル３）では、複数のユーザの間の相互作用を制御する
ようにしたことを特徴とする請求項１から請求項１１までのいずれか１項に記載のイベント管理システム。
≪請求項１３≫
前記イベント生成処理部は、
グラフィカルに作成したシナリオ部品をライブラリ登録する共用モジュールに転換することが可能であり、
それにより、プログラムの一部をテンプレート化することが可能であることを特徴とする請求項１から請求項１２までのいずれか１項に記載のイベント管理システム。
≪請求項１４≫
前記イベント生成処理部は、
前記タイムゾーンの構造を示す通常の編集画面と、前記フィールドゾーンの構造を示すマップタイプの編集画面を相互に切り替えて、編集可能である
ことを特徴とする請求項１から請求項１３までのいずれか１項に記載のイベント管理システム。
≪請求項１５≫
前記イベント生成処理部は、
参加者の携帯する端末機器の端末アプリを利用した相互の接触確認プロセス（ユーザチェック）を設定することが可能であり、
管理者ユーザが一般ユーザとの間でユーザチェックをすることで、当該一般ユーザが行動をすることの制限を課すことができ、
一般ユーザ同士のユーザチェックにより、グルーピングがなされる
ことを特徴とするイベント管理システム。
≪請求項１６≫
前記イベント生成処理部は、
グローバルトリガ、ＲＳＳ、ユーザ情報付ＲＳＳ、連携システムからのデータ、ユーザ情報付データ、シナリオステイタスのいずれかにユーザの個別シナリオインスタンスを生成する機能を付与したエントリートリガによりユーザの個別インスタンスを発生させるのみならず、
ユーザが携帯する端末アクション、フィールドインのみを受け取るエントリートリガであるローカルエントリィにより、ローカルエントリィプロセスを開始することができる
ことを特徴とする請求項１から請求項１５までのいずれか１項に記載したイベント管理システム。
≪請求項１７≫
前記ローカルエントリィの位置指定情報は、範囲情報のほかに、位置ポイント情報を特定することができ、
位置ポイント情報は、ユーザの指定、又は範囲の重心などの位置指定情報から導かれるものであることを特徴とする請求項１６に記載したイベント管理システム。
≪請求項１８≫
前記ローカルエントリィプロセスを実現する際に用いるマップであるトリガマップ上には、参加中のコンテキストの特定されたフィールドゾーン情報のほかにコンテキストを特定された稼働中のローカルエントリィ位置情報が表示され、
表示されるローカルエントリィ情報は管理者側が無制限な範囲指定を行わないようにローカルエントリィの一ポイント情報に限定し、一つのシナリオ、あるいは管理者ユーザから提供される位置ポイント情報を制限する
ことを特徴とする請求項１６または請求項１７に記載のイベント管理システム。
≪請求項１９≫
生成された前記解析構造体に対応し、当該構造を継承する形で前記イベント参加者の参加ログを、前記イベントに対するコンテキストでクラス化された時間と場所で構造化されたログとして生成するログ生成部とログ解析部とをさらに有し、
前記ログ生成部は、参加者のゾーン、モジュール通過情報とサービス利用情報をログとして生成し、
前記ログ解析部は、
全ての参加者の通過情報を集約して特定のノードの重要性の解析、遷移先、遷移元との関連情報を解析し、
又は特定の参加者の行動をノードのコンテンツ情報や管理者のノードに付与するコンテキスト情報から解析して参加者の行動特性、嗜好を抽出する
ことにより、ビッグデータの活用又は特定参加者の管理を可能とする請求項２に記載のイベント管理システム。
≪請求項２０≫
さらに、イベントモニタ部及び緊急対応部を有し、
前記イベントモニタ部は、
ノード毎のイベント参加者通過情報をイベントモニタにおいてリアルタイムにコンテキスト毎に集合的に把握、或いは緊急事態発生を感知し、
前記緊急対応部は、
ノードごとの緊急事態に対応するためのイベントの進行の制御をする
ことにより、リアルタイムなノード毎のイベント管理を可能としたことを特徴とする請求項１９に記載したイベント管理システム。
≪請求項２１≫
さらに、ユーザチェック部を有し、
イベント参加者が、自分が通過中のノードに対応した二次元バーコードページを生成選択することによって、自分の状況を、管理者や他のユーザが対応可能な形で管理者や他ユーザに告知することを可能としたことを特徴とする請求項１９又は請求項２０に記載したイベント管理システム。
≪請求項２２≫
前記一般ユーザ参加処理部は、
ユーザが登録したタグを択一的公式タグによって類型化し、参加者属性として登録させて参加者の属性のチェックを実行することを特徴とする請求項６に記載したイベント管理システム。
≪請求項２３≫
前記イベント処理部が計算処理の際に扱う属性やデータは、
表計算の表、又はデータベースのコラムを利用した行列計算、クエリー計算を含むことを特徴とする請求項７に記載したイベント管理システム。
≪請求項２４≫
前記モジュール、前記タイムゾーン及び前記フィールドゾーンは、内部ロジックによる期待時間要素を有し、
前記イベント生成処理部は、
期待時間計算処理部をさらに有し、
前記期待時間計算処理部が計算した結果に基づいて、シナリオの妥当性を判断することを特徴とする請求項１から請求項２３までのいずれか１項に記載したイベント管理システム。
≪請求項２５≫
さらに、場所イベント管理部を有し、
前記場所イベント管理部は、その場所と時間制限情報を規格化することにより、各場所イベントの開始もしくは想定開始時間を算出し、
それにより、遅延管理、推奨ルート設定又は未来タイムライン表示のうちの少なくとも一つを可能にすることを特徴とする請求項１から請求項２４までのいずれか１項に記載したイベント管理システム。
≪請求項２６≫
前記場所イベント管理部は、マップ上に配置された特定のカテゴリーのユーティリティポイントリストから特定された指定ポイントへの誘導を行うことを特徴とする請求項２５に記載したイベント管理システム。
≪請求項２７≫
前記場所イベント管理部は、複数の参加者をグループ化し、グループ行動に必要なユーティリティ機能を提供することを特徴とする請求項２５又は請求項２６に記載したイベント管理システム。
≪請求項２８≫
アイコンを、遷移を表現するグラフィックの適切な位置に配置することによってイベント処理時に相互作用のトランザクション処理用のキーを自動生成することを特徴とする請求項１から請求項２７までのいずれか１項に記載したイベント管理システム。
≪請求項２９≫
アイコンを使用してＨＴＭＬエディタにリンクやデータ受け渡し用のタグを生成することを特徴とする請求項１から請求項２８までのいずれか１項に記載したイベント管理システム。
≪請求項３０≫
グラフィカルにモジュール内外のイベント処理と引数、戻り値を設定することを特徴とする請求項１から請求項２９までのいずれか１項に記載したイベント管理システム。
≪請求項３１≫
参加者の位置情報処理について所在タイル登録処理とイベント処理用タイル指定をおこなうことによって計算量を削減することを特徴とする請求項１から請求項３０までのいずれか１項に記載したイベント管理システム。
≪請求項３２≫
タブのリストとページを結合したランディングページを相互に遷移させて、斜めの遷移バー又は扇状の遷移バーのうちのいずれかを利用することにより、スクロール管理アイコンを用いずに、スクロールを実行することを特徴とする請求項１から請求項３１までのいずれか１項に記載したイベント管理システム。
≪請求項３３≫
解釈構造体の出力及び入力について、マークアップ言語、構造を入れ子で記述出来る言語、ＪＳＯＮ（javascript object notation)又はオブジェクト構造を記述できるデータ記述言語を利用して、記述を包含するゾーンに対応するオブジェクトの記法を設定し、入れ子構造もしくは所属関係を示すリスト情報を付加することを特徴とする請求項１から請求項３２に記載したイベント管理システム。

≪親出願の特許査定時の請求項（国内書面提出時に請求項３４、請求項３５を追加）≫
≪請求項１≫
イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、及び
前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩ
を格納するＡＰＩデータベースと、
イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
イベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
前記生成されたイベント実行プログラムのうち、当システムにおける実行可能性の所定基準及び管理者が任意で設定するイベントの妥当性基準に適合するイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
ネットワークを通じてイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部とを備えたイベント管理システムであって、
前記イベント実行プログラムのモジュールを、ネストしたシナリオであるとして扱い、モジュールによって重層化されたオブジェクトの動作を各モジュールに付属するシナリオチャートに前記イベント生成者がグラフィックに記述するものであり、
前記オブジェクトとして、タイムゾーン及びフィールドゾーンを含むゾーンと呼ぶオブジェクトを用いるものであり、
前記シナリオチャートをグラフィックに記述するためのアイコン及び記述子を用いるものであり、
前記イベント管理システムは、さらにチャート図解釈部を備え、
前記チャート図解釈部は、
完成したチャート図において、前記タイムゾーンの構造、前記チャートに配置されたフィールドゾーン情報、コンテンツおよび前記記述子の前記タイムゾーンに対しての包含関係、コンテンツおよび前記記述子の他のアイコンへの部位配置情報、及び前記遷移矢の結合関係（前記アイコンおよび前記アイコン部位）を解釈し、
これらにより、マークアップ言語によるプログラミングと同等のチャート解釈を実現することを特徴とするイベント管理システム。
≪請求項２≫
イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、
及び
前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩ
を格納するＡＰＩデータベースと、
イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
イベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
前記生成されたイベント実行プログラムのうち、当システムにおける実行可能性の所定基準及び管理者が任意で設定するイベントの妥当性基準に適合するイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
ネットワークを通じてイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部とを備えたイベント管理システムであって、
前記イベント実行プログラムのモジュールを、ネストしたシナリオであるとして扱い、モジュールによって重層化されたオブジェクトの動作を各モジュールに付属するシナリオチャートに前記イベント生成者がグラフィックに記述するものであり、
前記オブジェクトとして、タイムゾーン及びフィールドゾーンを含むゾーンと呼ぶオブジェクトを用いるものであり、
前記シナリオチャートをグラフィックに記述するためのアイコン及び記述子を用いるものであり、
前記イベント管理システムは、さらにチャート図解釈部と解析構造体生成部とを備え、
前記チャート図解釈部は、
完成したチャート図において、前記タイムゾーンの構造、前記フィールドゾーンの構造、前記チャートに配置されたフィールドゾーン情報、コンテンツおよび前記記述子の前記タイムゾーン又はフィールドゾーンに対しての包含関係、コンテンツおよび前記記述子の他のアイコンへの部位配置情報、及び結合関係（前記アイコンおよび前記アイコン部位）を解釈し、
前記解析構造体生成部は、
前記チャート図解釈部が解釈した情報に従って、
前記タイムゾーン又はフィールドゾーンの入れ子関係を解析してプレーンのフィールドを最上位タイムゾーン又は最上位フィールドゾーンとしてプロパティ情報と共に構造化し、
前記フィールドゾーン又は前記タイムゾーンを参照情報として追加し、
それぞれの前記タイムゾーン又は前記フィールドゾーンに包含されたコンテンツおよび記述子を構造体の該当位置に要素としてプロパティ情報と共にリスト化し、
部位配置された前記アイコンを各要素（プロパティ）の子要素として追加し、
遷移情報をプロパティと指示情報として双方向から追加し、
これらにより解析構造体を生成し、チャート、すなわちモジュールに固有の構造体とし、マークアップ言語によるプログラミングと同等のチャート解釈を実現することを特徴とするイベント管理システム。
≪請求項３≫
前記イベント生成者が複数存在し、それらを管理者ユーザとして扱い、イベントを利用する一般ユーザと、イベントを生成する管理者ユーザとを区別して扱い、
前記イベント管理システムは、さらに管理者ユーザが一般ユーザに対して付与する利益であるポイントや称号を管理するポイント管理部を有し、
前記ポイント管理部は、
個々のイベント利用時に管理者ユーザが設定するポイントや称号を他の管理者の生成するイベントに持ち越せることを特徴とする請求項１又は請求項２に記載のイベント管理システム。
≪請求項４≫
前記イベント生成処理部は、
前記イベント生成の際に、管理者ユーザが行うシナリオ作成は、フローチャートを配置する様にグラフィカルに行うことが可能であり、操作はオブジェクトを収納したパレットブロックからチャートを配置するフィールドブロックにドラッグ＆ドロップすることによって実現することを特徴とする請求項１から請求項３までのいずれか１項に記載のイベント管理システム。
≪請求項５≫
前記イベント生成処理部は、
前記ドラッグ＆ドロップの操作の際に、現実の配信時に問題となる時間と場所の制限を取り込み、実現不可能な場合には、当該操作が不能であることをビジュアルに操作者に通知することを特徴とする請求項４に記載のイベント管理システム。
≪請求項６≫
前記イベント管理システムは、前記イベントが実行されている際に前記一般ユーザが当該イベントに参加することを処理する一般ユーザ参加処理部をさらに有し、
前記一般ユーザ参加処理部は、
前記一般ユーザが参加者として行動して、管理者ユーザが生成したイベントにトリガ発生をする処理をアイコンを画面上に配置することにより実行することが可能であることを特徴とする請求項１又は請求項２に記載のイベント管理システム。
≪請求項７≫
前記イベント生成処理部は、
イベントに必要な計算処理や条件処理を条件評価矢と代入矢によるオブジェクト間の遷移、すなわち結合操作で実行可能とすることを特徴とする請求項４に記載のイベント管理システム。
≪請求項８≫
前記イベント管理システムは、前記イベントに参加する前記一般ユーザの相互作用を管理する一般ユーザ相互作用管理部をさらに有し、
前記一般ユーザ相互作用管理部は、
複数参加者間の相互作用を管理する全体処理用のグラフィカルな作成アイコンを利用してメンバスコープの遷移系列での都度評価を通じてその時点のサービス対象者を確定可能であることを特徴とする請求項４から請求項７までのいずれか１項に記載のイベント管理システム。
≪請求項９≫
前記イベント管理システムは、前記イベントに参加する前記一般ユーザの行動を確認するユーザ行動確認部をさらに有し、
前記ユーザ行動確認部は、
前記一般ユーザが二次元バーコード、一次元バーコード、ＩＣチップ、ＲＦＩＤ又は赤外線情報などのうちのいずれか一つを端末で読み取って送信することにより、前記一般ユーザの行動を確認可能であり、
前記イベント生成処理部は、当該処理を可能とすべく、前記一般ユーザの行動確認をアイコンを利用してシナリオに組み込み可能とすることを特徴とする請求項４から請求項８までのいずれか１項に記載のイベント管理システム。
≪請求項１０≫
前記イベント生成処理部は、前記一般ユーザの行動管理に必要なメッセージ配信を重要度に応じてユーザに認識させるよう、シナリオ作成し、
前記ユーザ行動確認部は、前記一般ユーザの行動管理に必要なメッセージ配信を重要度に応じてユーザに認識させるよう、シナリオ実行中の前記一般ユーザの行動遷移の管理を行う
ことを可能としたことを特徴とする請求項９に記載のイベント管理システム。
≪請求項１１≫
前記イベント生成処理部は、タブとスクロール管理アイコンを利用した親指のみで携帯タッチパネル操作を行って、イベント生成又はイベント参加が可能なユーザインターフェイスを有することを特徴とする請求項１から請求項１０までのいずれか１項に記載のイベント管理システム。
≪請求項１２≫
前記イベント生成処理部は、
前記シナリオを記述するに際して、基本記述（レベル１）、高度管理導入（レベル２）、全体処理導入（レベル３）と三層のレベルの制限をユーザインタフェースもしくはユーザ資格でコントロールするように構成し、
基本記述（レベル１）では、ユーザの行動を制約せず行動に従ったガイドを行い、 高度管理導入（レベル２）では、ユーザの行動をイベントの進行のために制御し、
全体処理導入（レベル３）では、複数のユーザの間の相互作用を制御する
ようにしたことを特徴とする請求項１から請求項１１までのいずれか１項に記載のイベント管理システム。
≪請求項１３≫
前記イベント生成処理部は、
グラフィカルに作成したシナリオ部品をライブラリ登録する共用モジュールに転換することが可能であり、
それにより、プログラムの一部をテンプレート化することが可能であることを特徴とする請求項１から請求項１２までのいずれか１項に記載のイベント管理システム。
≪請求項１４≫
前記イベント生成処理部は、
前記タイムゾーンの構造を示す通常の編集画面と、前記フィールドゾーンの構造を示すマップタイプの編集画面を相互に切り替えて、編集可能である
ことを特徴とする請求項１から請求項１３までのいずれか１項に記載のイベント管理システム。
≪請求項１５≫
前記イベント生成処理部は、
参加者の携帯する端末機器の端末アプリを利用した相互の接触確認プロセス（ユーザチェック）を設定することが可能であり、
管理者ユーザが一般ユーザとの間でユーザチェックをすることで、当該一般ユーザが行動をすることの制限を課すことができ、
一般ユーザ同士のユーザチェックにより、グルーピングがなされる
ことを特徴とするイベント管理システム。
≪請求項１６≫
前記イベント生成処理部は、
グローバルトリガ、ＲＳＳ、ユーザ情報付ＲＳＳ、連携システムからのデータ、ユーザ情報付データ、シナリオステイタスのいずれかにユーザの個別シナリオインスタンスを生成する機能を付与したエントリートリガによりユーザの個別インスタンスを発生させるのみならず、
ユーザが携帯する端末アクション、フィールドインのみを受け取るエントリートリガであるローカルエントリィにより、ローカルエントリィプロセスを開始することができる
ことを特徴とする請求項１から請求項１５までのいずれか１項に記載したイベント管理システム。
≪請求項１７≫
前記ローカルエントリィの位置指定情報は、範囲情報のほかに、位置ポイント情報を特定することができ、
位置ポイント情報は、ユーザの指定、又は範囲の重心などの位置指定情報から導かれるものであることを特徴とする請求項１６に記載したイベント管理システム。
≪請求項１８≫
前記ローカルエントリィプロセスを実現する際に用いるマップであるトリガマップ上には、参加中のコンテキストの特定されたフィールドゾーン情報のほかにコンテキストを特定された稼働中のローカルエントリィ位置情報が表示され、
表示されるローカルエントリィ情報は管理者側が無制限な範囲指定を行わないようにローカルエントリィの一ポイント情報に限定し、一つのシナリオ、あるいは管理者ユーザから提供される位置ポイント情報を制限する
ことを特徴とする請求項１６または請求項１７に記載のイベント管理システム。
≪請求項１９≫
生成された前記解析構造体に対応し、当該構造を継承する形で前記イベント参加者の参加ログを、前記イベントに対するコンテキストでクラス化された時間と場所で構造化されたログとして生成するログ生成部とログ解析部とをさらに有し、
前記ログ生成部は、参加者のゾーン、モジュール通過情報とサービス利用情報をログとして生成し、
前記ログ解析部は、
全ての参加者の通過情報を集約して特定のノードの重要性の解析、遷移先、遷移元との関連情報を解析し、
又は特定の参加者の行動をノードのコンテンツ情報や管理者のノードに付与するコンテキスト情報から解析して参加者の行動特性、嗜好を抽出する
ことにより、ビッグデータの活用又は特定参加者の管理を可能とする請求項２に記載のイベント管理システム。
≪請求項２０≫
さらに、イベントモニタ部及び緊急対応部を有し、
前記イベントモニタ部は、
ノード毎のイベント参加者通過情報をイベントモニタにおいてリアルタイムにコンテキスト毎に集合的に把握、或いは緊急事態発生を感知し、
前記緊急対応部は、
ノードごとの緊急事態に対応するためのイベントの進行の制御をする
ことにより、リアルタイムなノード毎のイベント管理を可能としたことを特徴とする請求項１９に記載したイベント管理システム。
≪請求項２１≫
さらに、ユーザチェック部を有し、
イベント参加者が、自分が通過中のノードに対応した二次元バーコードページを生成選択することによって、自分の状況を、管理者や他のユーザが対応可能な形で管理者や他ユーザに告知することを可能としたことを特徴とする請求項１９又は請求項２０に記載したイベント管理システム。
≪請求項２２≫
前記一般ユーザ参加処理部は、
ユーザが登録したタグを択一的公式タグによって類型化し、参加者属性として登録させて参加者の属性のチェックを実行することを特徴とする請求項６に記載したイベント管理システム。
≪請求項２３≫
前記イベント処理部が計算処理の際に扱う属性やデータは、
表計算の表、又はデータベースのコラムを利用した行列計算、クエリー計算を含むことを特徴とする請求項７に記載したイベント管理システム。
≪請求項２４≫
前記モジュール、前記タイムゾーン及び前記フィールドゾーンは、内部ロジックによる期待時間要素を有し、
前記イベント生成処理部は、
期待時間計算処理部をさらに有し、
前記期待時間計算処理部が計算した結果に基づいて、シナリオの妥当性を判断することを特徴とする請求項１から請求項２３までのいずれか１項に記載したイベント管理システム。
≪請求項２５≫
さらに、場所イベント管理部を有し、
前記場所イベント管理部は、その場所と時間制限情報を規格化することにより、各場所イベントの開始もしくは想定開始時間を算出し、
それにより、遅延管理、推奨ルート設定又は未来タイムライン表示のうちの少なくとも一つを可能にすることを特徴とする請求項１から請求項２４までのいずれか１項に記載したイベント管理システム。
≪請求項２６≫
前記場所イベント管理部は、マップ上に配置された特定のカテゴリーのユーティリティポイントリストから特定された指定ポイントへの誘導を行うことを特徴とする請求項２５に記載したイベント管理システム。
≪請求項２７≫
前記場所イベント管理部は、複数の参加者をグループ化し、グループ行動に必要なユーティリティ機能を提供することを特徴とする請求項２５又は請求項２６に記載したイベント管理システム。
≪請求項２８≫
アイコンを、遷移を表現するグラフィックの適切な位置に配置することによってイベント処理時に相互作用のトランザクション処理用のキーを自動生成することを特徴とする請求項１から請求項２７までのいずれか１項に記載したイベント管理システム。
≪請求項２９≫
アイコンを使用してＨＴＭＬエディタにリンクやデータ受け渡し用のタグを生成することを特徴とする請求項１から請求項２８までのいずれか１項に記載したイベント管理システム。
≪請求項３０≫
グラフィカルにモジュール内外のイベント処理と引数、戻り値を設定することを特徴とする請求項１から請求項２９までのいずれか１項に記載したイベント管理システム。
≪請求項３１≫
参加者の位置情報処理について所在タイル登録処理とイベント処理用タイル指定をおこなうことによって計算量を削減することを特徴とする請求項１から請求項３０までのいずれか１項に記載したイベント管理システム。
≪請求項３２≫
タブのリストとページを結合したランディングページを相互に遷移させて、斜めの遷移バー又は扇状の遷移バーのうちのいずれかを利用することにより、スクロール管理アイコンを用いずに、スクロールを実行することを特徴とする請求項１から請求項３１までのいずれか１項に記載したイベント管理システム。
≪請求項３３≫
解釈構造体の出力及び入力について、マークアップ言語、構造を入れ子で記述出来る言語、ＪＳＯＮ（javascript object notation)又はオブジェクト構造を記述できるデータ記述言語を利用して、記述を包含するゾーンに対応するオブジェクトの記法を設定し、入れ子構造もしくは所属関係を示すリスト情報を付加することを特徴とする請求項１から請求項３２に記載したイベント管理システム。
≪請求項３４≫
イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、及び
前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩを格納するＡＰＩデータベースと、
イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
イベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
前記生成されたイベント実行プログラムのうち、当システムにおける実行可能性の所定基準及び管理者が任意で設定するイベントの妥当性基準に適合するイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
ネットワークを通じてイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部とを備えたイベント管理システムであって、
前記イベント実行プログラムのモジュールによって重層化されたオブジェクトの動作を各モジュールに付属するシナリオチャートに前記イベント生成者がグラフィックに記述するものであり、
前記シナリオチャートをグラフィックに記述するためのアイコン及び記述子を用いるものであり、
前記イベント管理システムは、さらにチャート図解釈部を備え、
前記チャート図解釈部は、
完成したチャート図において、コンテンツおよび前記記述子の他のアイコンへの部位配置情報、及び前記遷移矢の結合関係（前記アイコンおよび前記アイコン部位）を解釈することを特徴とするイベント管理システム。
≪請求項３５≫
イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、
及び
前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩを格納するＡＰＩデータベースと、
イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
イベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
前記生成されたイベント実行プログラムのうち、当システムにおける実行可能性の所定基準及び管理者が任意で設定するイベントの妥当性基準に適合するイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
ネットワークを通じてイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部とを備えたイベント管理システムであって、
前記イベント実行プログラムのモジュールによって重層化されたオブジェクトの動作を各モジュールに付属するシナリオに前記イベント生成者が記述するものであり、
前記シナリオを記述するための記述子を用いるものであり、 前記イベント管理システムは、さらにシナリオ構造解釈部を備え、
前記シナリオ構造解釈部は、
完成したシナリオにおいて、コンテンツおよび前記記述子の他の記述子への部位配置情報、及び前記遷移矢の結合関係（前記記述子および前記記述子部位）を解釈することを特徴とするイベント管理システム。

≪本願の出願当初の請求項（親の請求項８をさらに上衣概念にしたものをメインにして、親の請求項２８の構成要件に基づいて請求項２、段落０１３５の記載に基づいて請求項３を設けた） ≫
≪請求項１≫
イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、及び
前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩを格納するＡＰＩデータベースと、
イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
イベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
前記生成されたイベント実行プログラムのうち、当システムにおける実行可能性の所定基準及び管理者が任意で設定するイベントの妥当性基準に適合するイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
ネットワークを通じてイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部と、
前記イベントに参加する複数参加者間の相互作用を管理する全体処理用のグラフィカルな作成アイコンを利用してメンバスコープの遷移系列での都度評価を通じてその時点のサービス対象者を確定可能である一般ユーザ相互作用管理部と
を備えたイベント管理システムであって、
前記イベント実行プログラムのモジュールによって重層化されたオブジェクトの動作を各モジュールに付属するシナリオに前記イベント生成者が記述するものであり、
前記シナリオを記述するための記述子を用いるものであり、
前記イベント管理システムは、さらに、
完成したシナリオにおいて、コンテンツおよび前記記述子の他の記述子への部位配置情報、及び前記記述子又は前記記述子部位の結合関係を解釈するシナリオ構造解釈部を備えることを特徴とするイベント管理システム。
≪請求項２≫
アイコンを、遷移を表現するグラフィックの適切な位置に配置することによって、
イベント処理時に前記複数参加者間の相互作用のトランザクション処理用のキーを自動生成することを特徴とする請求項１に記載したイベント管理システム。
≪請求項３≫
前記一般ユーザ相互作用管理部は、
前記複数参加者間のグループ行動の制御のために、全体処理属性と呼ぶオブジェクトを利用するものであり、
前記全体処理属性は、メンバの個別の属性値だけでなく代表値、代表プロパティを含む全体処理用の情報を持つことを特徴とする請求項１又は請求項２に記載したイベント管理システム。
ムを前記イベントデータベースに登録するイベント登録処理部と、
ネットワークを通じてイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部とを備えたイベント管理システムであって、
前記イベント実行プログラムのモジュールによって重層化されたオブジェクトの動作を各モジュールに付属するシナリオに前記イベント生成者が記述するものであり、
前記シナリオを記述するための記述子を用いるものであり、
前記イベント管理システムは、さらにシナリオ構造解釈部を備え、
前記シナリオ構造解釈部は、
完成したシナリオにおいて、コンテンツおよび前記記述子の他の記述子への部位配置情報、及び前記記述子又は前記記述子部位の結合関係を解釈することを特徴とするイベント管理システム。

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

１０ サーバ
２１，２２，２３，２４ 管理者ユーザ端末
３１，３２，３３，３４ 一般ユーザ端末
５１ ＡＰＩデータベース（ＡＰＩデータベース装置）
５２ イベントデータベース（イベントデータベース装置）
５３ ユーザデータベース（ユーザデータベース装置）
５４ ポイントデータベース（ポイントデータベース送致）
６１ ＡＰＩ登録処理部
６２ イベント生成処理部
６３ イベント登録処理部
６４ 通信処理部
６５ チャート図解釈部
６６ 解析構造体生成部
６７ ポイント管理部
６８ 一般ユーザ参加処理部
６９ 一般ユーザ相互作用管理部
７０ ユーザ行動確認部

Claims (1)

1. イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、及び
   前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩを格納するＡＰＩデータベースと、
   イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
   ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
   イベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
   前記生成されたイベント実行プログラムのうち、当システムにおける実行可能性の所定基準及び管理者が任意で設定するイベントの妥当性基準に適合するイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
   ネットワークを通じてイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部と、
   前記イベントに参加する複数参加者間の相互作用を管理する全体処理用のグラフィカルな作成アイコンを利用してメンバスコープの遷移系列での都度評価を通じてその時点のサービス対象者を確定可能である一般ユーザ相互作用管理部と
   を備えたイベント管理システム。

Images