JP6774133B1 - メンバースコープを用いて参加者の相互作用を制御するイベント管理システム - Google Patents

Abstract

【課題】実行可能なプログラムをイベント生成者が容易に生成する。【解決手段】イベント実行管理ＡＰＩ及びリソース管理ＡＰＩを格納するＡＰＩデータベースと、イベントデータベースと、ＡＰＩ登録処理部と、イベント生成処理部と、イベント実行プログラムが、基準に適合することを評価し、その結果が肯定であるイベント実行プログラムをイベントデータベースに登録するイベント登録処理部と、送受信を行う通信処理部とを備えたイベント管理システムであって、イベント実行プログラムは、グループの配列であり、参加者グループの集合であるメンバースコープというオブジェクトを用いて、複数のイベント参加者又は複数の機器間の相互作用を制御する。さらに、属性と、現在処理グループと、集合操作もしくは関連性抽出操作を行う一つ又は複数の関数とを用いて制御を実行する。【選択図】図１

Description

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

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

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

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

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

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

しかし、イベントを生成する立場、イベントに参加する立場からは、より簡易なユーザインタフェースが願われていた。さらに、参加者相互の相互作用制御に優れたものが望ましい。

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

本発明は、グループの配列であり、参加者グループの集合であるメンバースコープというオブジェクトを用いて、複数のイベント参加者、複数の機器間の相互作用を制御することを特徴とするイベント管理システムを提供するものである。

本発明のイベント管理システムは、イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、及び 前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩを格納するＡＰＩデータベースと、
イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
イベント生成者が用いるイベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、前記イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
前記生成されたイベント実行プログラムが、当システムにおける実行可能性の所定基準に適合することを評価し、その結果が肯定的であるイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
ネットワークを通じてイベント参加者が用いるイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部とを備えたイベント管理システムであって、
前記イベント実行プログラムは、
グループの配列であり、参加者グループの集合であるメンバースコープというオブジェクトを用いて、当該メンバースコープによる参加者の限定をすることにより、複数の前記イベント参加者又は複数の前記機器間の相互作用を制御することを特徴とする
これらにより、参加者の相互作用に優れたイベント管理システムを提供できる。

前記イベント実行プログラムは、
さらに、
前記メンバースコープを構成するオブジェクトのいずれか一つ以上について定義され、オブジェクトインスタンスに対してユニークな属性値を持つ属性と、
処理に対するグループコンテキストによる属性値の特定手段と、
集合操作もしくは関連性抽出操作を行う一つ又は複数の関数と
を用いて制御を実行することを特徴とする。
これにより、複数のグループの関係を制御しつつ、参加者相互の相互作用を制御できる。

前記属性値の特定手段は、
メンバースコープによる参加者の限定、メンバースコープの現在処理グループ、又は包含関係による上位のメンバースコープによる参加者の限定のうちのいずれか一つ以上を含むことを特徴とする。
これにより、複数のグループの関係を制御しつつ、参加者相互の相互作用を制御できる。

また、前記集合操作もしくは関連性抽出操作を行う一つ又は複数の関数は、
論理演算を実行する関数と、
メンバーシップオブジェクト間の関連性抽出を実行する関数と、
メンバースコープメンバーグループ追加削除を実行する関数と、
メンバースコープメンバー追加削除を実行する関数と
を含むことを特徴とする。
これにより、メンバーの追加、削除などがなされても、全体の相互作用制御が確実になされる。

シナリオ又はタイムゾーンを、前記イベント実行ブログラムのブロックであるユーザインターフェイスブロック、プログラムブロック及びプログラムブロックの遷移木である評価範囲の組み合わせにより親子関係で表現することを特徴とする。
これにより、イベント作成者にとって理解しやすいプログラミングを実現できる。

シナリオ又はタイムゾーンを、前記イベント実行プログラムのブロックであるユーザインターフェイスブロック又はプログラムブロックを複数包含する包含ブロックにより親子関係で表現することを特徴とする。
これにより、イベント作成者にとって理解しやすく、自由度の高いプログラミングを実現できる。

前記ユーザインターフェイスブロックは、イベント生成者ユーザインターフェイスブロックと、イベント参加者ユーザインターフェイスブロックとからなり、
前記イベント実行プログラムは、複数のイベント生成者ユーザインターフェイスブロックの相互割込みにより実行されることを特徴とする。
これにより、イベント作成者にとって、わかりやすいプログラミングを実現できる。

前記イベント実行プログラムは、
ブロック開始条件として機能する制約を有し、
前記複数のイベント生成者ユーザインタフェイスブロックの相互割込みは、前記制約によって統合的に管理されることを特徴とする。
これにより、イベント作成者にとって、わかりやすいプログラミングを実現できる。

さらに、 前記イベント実行プログラムは、
ブロック開始条件として機能する制約を有し、
前記メンバースコープは、前記制約によって統合的に管理されることを特徴とする。
これにより、イベント作成者にとって、わかりやすい参加者管理ができる。

前記イベント実行プログラムは、遷移元の評価時間情報及びグループ情報を取得して、遷移元のグループの遷移が発生した時に、条件を満たすと遷移先のグループに評価時間を返すプログラムブロックである相互作用コネクタを有し、
前記相互作用コネクタを用いて全体処理及び相互処理の管理を実行することを特徴とする。
これにより、イベント作成者にとって、わかりやすい遷移が可能となる。

前記イベント駆動評価処理部は、前記評価を実行するプロセスにおいて、ページ表示及びユーザ入出力を実行することを特徴とする。
これにより、イベント作成者は、実行可能性の高いプログラミングを行える。

前記イベント実行プログラムは、遷移のタイミング管理を、評価時間同士、加算時間の演算と現在時刻の比較制御で実行することを特徴とする。
これにより、遷移のタイミングを適切に管理できる。

前記イベント実行プログラムは、
ユーザインタフェイスブロック、プログラムブロック、及び入出力ポートを含むアイコンをグラフィカルに表示することを特徴とする。
これにより、イベント作成者は、グラフィカルにプログラミングができる。

前記イベント実行プログラムは、ユーザインタフェイスブロック、プログラムブロック、及び入出力ポートのうち関連するアイコンにイベントが発生した時に当該アイコンにつながる遷移矢を表示し、その他の時点では相互のポートを示すアイコンのみを表示することを特徴とする。
これにより、煩雑な表示を避けて、必要な遷移矢のみの表示ができる。
前記メンバースコープで参加者を限定された前記包含ブロック中で定義された新たな下位のメンバースコープは、上位のメンバースコープで参加者を限定した子プロセスで生成管理され、
当該下位のメンバースコープの所属グループのメンバーは上位メンバースコープのアクティブグループの部分集合となる
ことを特徴とする。
これにより、親子関係で表現されるメンバースコープが適切に形成される。

さらにまた、前記イベント実行プログラムは、
ユーザインターフェイスと、当該ユーザインターフェイスのタイミング、コンテキスト制御に用いるユーザインターフェイスブロック（ＵＩＢ）と、
制御の詳細を定義するプログラムブロック（ＰＢ）と
を組み合わせてなり、
前記イベント登録処理部は、前記イベント実行プログラムに対して、変数ブロックで囲まれたプログラムブロックの遷移木である評価範囲によるイベント駆動評価処理を実行することにより、前記実行可能性の所定基準に適合するイベント実行プログラムを前記イベントデータベースに登録することを特徴とする。
これにより、プログラムの妥当性を評価する範囲を定めて、適切な駆動評価処理ができる。

以上、説明したように、参加者の相互作用に優れたイベント管理システムを提供できる。

シナリオの構造を示す図である。 ＢＵＩ機能モデル（グラフィック要素を除いた制御ユニットー基本層）を示す図である。 ビジネスプログラムブロック（ＢＰＢ）を説明する図である。 包含型を説明する図である。 モジュールについて説明する図である。 ＢＵＩグループについて説明する図である。 ＢＵＩグループ（グループコンテキスト）について説明する図である。 ブロックの参照範囲と機能シートとについて説明する図である。 変数と属性について説明する図である。 ＵＩＢ（ユーザインタフェイスブロック）の評価範囲について説明する図である。 Ｂ−ＵＩＢのＰＢ評価範囲について説明する図である。 ＢＵＩ（ビジネスユーザインタフェイス）機能モデル−編集操作モデル（一部ＧＵＩを考慮）を説明する図である。 モデル機能操作マッピングの図である。 ＢＵＩ機能モデル（グラフィック要素を除いた制御ユニット−実用層）を説明する図である。 メンバースコープがグループコンテキストをＢＵＩＢに与えることを示す図である。 システム設定属性について説明する図である。 エントリー条件定義及び関連参加者指定について説明する図（その１）である。 エントリー条件定義及び関連参加者指定について説明する図（その２）である。 オブジェクト関係定義、制約定義、ＭＳ属性定義、タイミング遷移について説明する図である。 相互作用コネクタ、表示とレスポンス、制約、メンバースコープ制約、ＭＳログ取得、属性について説明する図である。 タイムゾーン制約、フィールドゾーン制約、ＢＵＩＢプロセス、基本的なＰＢについて説明する図である。 序列算出、管理者トリガ、外部トリガ待受けＰＢ、レスポンスＢＵＩＢ、イベントステイタス生成、コンテキスト限定ページ発行、ＵＲＬ発行について説明する図である。 制約の機能を接続したＵＩＢに与えること、ステイタス評価、管理者コンタクトについて説明する図である。 モジュールリストについて説明する図である。 オブジェクト数抽出と、アクティブグループ指定について説明する図である。 ヘッダーの機能を説明する図である。 制約とヘッダー、フッターの関係を示す図である。 ＢＵＩにおけるグラフィカルユニット（アイコンとパレット）について説明する図である。 フィールドゾーン定義属性アイコンを説明する図である。 区分例を示す図である。 区分例を示す図（続き）である。 遷移矢について説明する図である。 ステイタスアイコン化／表示を説明する図である。 区分例におけるグラフィカル操作（機能モデル関連）を説明する図である。 区分例におけるグラフィカル操作（機能モデル関連）を説明する図（続き）である。 表示コンテキスト指定タグを説明する図である。 図３８から図４１までの配置関係を説明する図である。 実施例の説明図（その１）である。 実施例の説明図（その２）である。 実施例の説明図（その３）である。 実施例の説明図（その４）である。 イベント管理システムのハードウェア構成を示す図である。 イベント管理システムを構成するサーバコンピュータの構成を示す図である。 相互作用の様相を示す図（図４４(a)）と、メンバースコープの親子関係を示す図(図４４(b)）である。

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

図４２は、イベント管理システムのハードウェア構成を示す図である。図４２の中央に楕円で示すインターネット網には、サーバ（サーバコンピュータ）１０、イベント作成をする管理者ユーザ（ビジネスユーザ）が管理者ユーザアカウントを取得してサーバ１０にアクセスする管理者ユーザ端末２１，２２，２３，２４、一般ユーザ（参加者ユーザ）端末３１，３２，３３，３４を示している。管理者ユーザ端末、一般ユーザ端末は、いわゆるスマホ、タブレットコンピュータ、ＩＣカードやＱＲ記載カードと読み取り機器及び表示、発音機器の組み合わせであり得る。図４２では、端末が直接インターネットとやりとりしているように描いているが、ワイファイ機器を介してインターネットにつながるのでもよい。また、携帯電話ネットワークを介してインターネットにつながるのでもよい。

図４３は、イベント管理システムを構成するサーバコンピュータ１０の構成を示す図である。イベントの構成単位であるシナリオの実行、イベント参加端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信などを実行管理するイベント実行管理ＡＰＩ（アプリケーションプログラムインタフェース）、端末、機器、物品、建物、場所、移動手段、通信手段などの物理的リソースを各々識別して管理するリソース管理ＡＰＩを格納するＡＰＩデータベース装置５１、イベント実行プログラム及びイベント実行中に生じたログデータを格納するイベントデータベース装置５２、ユーザのアカウント情報などを有するユーザデータベース装置５３、ポイントに関する情報を有するポイントデータベース装置５４を有する。
さらに、ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部６１を有する。
また、イベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部６２を有する。
前記生成されたイベント実行プログラムが、当システムにおける実行可能性の所定基準に適合するか否かを評価し、その結果、基準に適合するイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部６４を有する。
ネットワークを通じてイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部６５を有する。
管理者ユーザが一般ユーザに対して付与する利益であるポイントや称号を管理するポイント管理部６６を有する。ここで、ポイントは、たとえば、電子マネーに変換できるなど、金銭的価値をもつものである。称号は、名誉的な肩書きである。
イベントが実行されている際にイベント参加者が当該イベントに参加することを処理するイベント参加者参加処理部６７を有する。
イベントに参加するイベント参加者相互作用を管理するイベント参加者相互作用管理部６８を有する。
イベントに参加する一般ユーザの行動を確認するユーザ行動確認部６９を有する。

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

図１は、シナリオの構造を示す図である。シナリオは、例えば、スタンプラリーや、グループツアーなど、イベント作成者が作成し、イベント参加者が参加するイベントのシナリオのことである。
図１で、ＢＵＩＢとあるのは、ビジネスユーザインターフェイスブロックの略である。ここでビジネスユーザは、イベント作成者である。ユーザインターフェイスブロックは、イベント実行プログラムを構成する要素である。ユーザインタフェイスブロックと、プログラムブロック（ＰＢ）とがイベント実行プログラムを構成する。
図１の上部左側に描かれている包含型は、包含型ＢＵＩＢを意味する。図１の左側の破線に囲まれた部分は、包含機能シートを示す。図１の右側の破線に囲まれた部分は、ＢＵＩＢプロセスのモデル図を示している。

包含機能シートには、複数のＢＵＩＢプロセス、トリガ、レスポンス、制約、属性／ＰＢモジュールなどがが含まれる。それらを結ぶ遷移矢が複数描かれている。遷移矢は、ブロック間の処理の呼び出し関係を表している。タイミング情報をメンバー情報を加えたデータの入出力関係を表しているとも言える。ＧＵＩでないＡＰＩの場合は相手を引数として記述する形となる。どちらが呼び出し側になるかは実装による。イベント評価ステップ内ではステップの評価時点で同時に処理される。
タイムゾーンは現在時刻とＴＺ遷移による加工された時間情報との比較によって時間管理を行う。ＴＺ遷移は、「ＴＺ」と表示される遷移矢である。ＴＺは、タイムゾーンを意味する。タイムゾーンは、イベントの経過時間とタイミングの管理、内部に配置されたコンテンツの儒秒管理のために利用されるオブジェクトである。
包含機能シートの上部左側には、星印００１と描いた部分がある。これは、「機能シートが開かれると子プロセスの待ち受け開始」を意味する。子プロセスについては、図４を参照されたい。
ＭＳと略して表記してあるのは、メンバースコープを意味する。図１において、包含機能シートに対しては、メンバースコープ（グループコンテキスト）がメンバースコープ制約を与えている。。内部の属性参照コンテキストを包含のＭＳ制約は付与する。内部のＢＵＩＢプロセスの制約に加えてコンテキストが付加される（その属性が使用されていた場合であるが）。メンバースコープについては、図１４、図１５、図１６を参照されたい。

図１の右側に描いたＢＵＩＢプロセスのモデル図は、ＢＵＩＢプロセスの一例を示している。プログラムブロック（ＰＢ）評価範囲にしたがって、当該ＢＵＩＢのヘッダーに遷移すると、処理ステップ、非ヘッダー待機、処理ステップ、コンテンツ、ＩＦ、処理ステップ、処理ステップ、非ヘッダー待機、フッターと、一連の処理のプロセスを実行する。コンテンツからの例外処理、ＩＦからのＮＯの場合の処理も描かれている。
ここで、最上位のヘッダーとシナリオのスタートブロックは同一である。

図２は、ＢＵＩ機能モデル（グラフィック要素を除いた制御ユニットー基本層）を示す図である。待ち受けと割込み発生については包含ブロック内の割込み処理も含めて調整する。割込みはトランザクションにプロセスを分解してシナリオ単一あるいは包含ブロックごとのＩＦ巡回、あるいはトリガ、アラーム、定期巡回などシステムイベント発生時にＩＦシーケンスを走らせるなどで管理する。優先度条件や参加者へのトリガ告知プロセスを挿入することも考慮する。
ＢＵＩＢプロセスはヘッダーを頭に分岐を含む樹状でそれぞれのブランチはフッターで終わる必要がある。
割込みを受付ない一連のＢＵＩＢのプロセスをトランザクションと呼ぶ。
待機型は待ち受け中にのみ割込みを受ける。レスポンスは、参加者ユーザの端末経由のイベントの取得、アプリ画面上のイベント、フィールドゾーン状態遷移、ユーザチェック（ユーザ相互、機器）を意味する。ここで、フィールドゾーンは、移動の管理と関連付けられたコンテンツの寿命管理の為に使用される。

図２で、処理ステップにおけるステイタスは、終了例外ステイタス管理用である。処理ステップのシーケンスは割込みを受けない。処理ステップのフッターは、終了後に待ち受けを受け入れる。
コンテンツは、開始前と開始後に割込みを受け入れる。包含型実施中に割込みを受け入れるかはプロパティで規定する（中断とはならない）。
包含型は子プロセスの生存管理と内部プロセス全体の終了管理を行う。
ダイアローグは、子プロセスを持つ表示。表示中でのイベントを受け取るレスポンスＵＩＢを配置できる。また配置されたレスポンスに対応する処理を行う。

図３は、ビジネスプログラムブロック（ＢＰＢ）を説明する図である。
属性は、遷移日時が最も新しい値、条件を満たさない場合はデフォルトを返す。入力型と出力型は異なる場合がある。
演算は、基本的には、出力と代入の値と型情報は同じである。
トリガ管理出力は、トリガのタイミング制御のために真偽、あるいは数値カウンタなどによって待機判定を引く。

図４は、包含型を説明する図である。
子プロセスは包含型ＢＵＩＢが開始するとヘッダーが待ち受け状態となる。
子プロセス終了については、第一に、子プロセスは、包含ブロック終了フッターが踏まれると閉じられる（内部プロセス終了）。必須入力指定されたフッターが踏まれていない場合は非正規終了となる。第二に、包含ブロックが中断遷移を受けた場合は全プロセスが終了する。第三に、終了処理は割込みに対するトランザクション単位で行われる。
ダイアローグの子プロセス中に配置されたレスポンスは親の表示で対応するイベントが発生した場合、スタイタスを返す。配置時に生成したタグなどで関連付ける。

図５は、モジュールについて説明する図である。モジュールはブロックの集合である。同一（機能）シート状にあると解釈される。異なるシートのブロックを選択することはできない。ただし包含ブロックを指定すれば内部プロセスはそれに含まれると考えられる。モジュールは、同名モジュールを一覧にて識別できるように工夫される。
長円又は円で表示しているのは、モジュールの入出力である。モジュールの入出力は指定ブロック間の入出力を取り除いた入出力の全体となる。
指定ブロックにされた型データは（モジュール）グローバルか、（モジュール）ローカルかのプロパティを持つ。グローバルに指定された型データは値を共通に持つ。ローカル指定された型データはモジュール内のスコープを持ち、値は展開されたモジュールインスタンス毎に保持される。
モジュールは関数としてシナリオ上のどこにでも展開できる。モジュールに加えられた変更は展開された全てのモジュールに適用される。
モジュールは内部で定義されたモジュールの配置を外部で許さないプロパティを持つことができる。これによってインポートされたモジュールのグローバル型データのみだりな参照を制限することができる。

図６は、ＢＵＩグループについて説明する図である。グループは、参加者をメンバーとして所属させることができる。グループに参加したシナリオ参加者はそのグループのメンバーシップを持つ。
グループは、型データをグループ属性として定義することができる。定義するときにプロパティとしてグループ属性かメンバー属性かを選ぶ必要がある。複数のグループと属性定義を行った型データはそれぞれに対して値を持つ。
グループ属性はグループオブジェクトに対して一つの値を持ちメンバーシップを持つ参加者は参照し操作をすることができる。
メンバー属性は参加者の各メンバーシップに対して一つの値を持ち該当するメンバーシップを持つ参加者（のブロックインスタンス）のみが操作することができる。

図７は、ＢＵＩグループ（グループコンテキスト）について説明する図である。
あるＢＵＩＢは一つ以上のＢＵＩグループをグループコンテキストとして定義することができる。そのＢＵＩＢのＰＢ（プログラムブロック）評価範囲の属性はその属性定義を行ったグループおよびメンバーシップに対する属性値が参照されることになる。
さらにグループコンテキストはイベント評価ステップ、ＢＵＩＢプロセスなど処理対象参加者を特定する必要のあるシナリオ内の一連の処理記述に対して定義する事も出来る。これによりグループの各メンバー、グループ共通の価値や属性を利用した参加者の相互作用について個々の属性ごとに関連性を定義せずとも処理の対象となる（属性との関連性を定義された）グループを特定するだけで矛盾なくスムーズに記述を行う事が出来る。
もし同一属性と複数のコンテキストグループが定義された場合、エラーとはならずそのＢＵＩＢを含むトランザクションが属性参照において衝突するＢＵＩグループ毎に複製され割込みプロセスとして分割される。トランザクション実施の条件として分割原因となったグループの実施制御を割込み条件で制御する（実際にどのような条件が組み込まれるかは上位層で決められる）。以上の処理はトランザクションが参加者端末の占有処理を含まないときは単に並列処理を行うことによって解決する。実装上はメンバースコープのアクティブグループ処理で解決する。
シナリオの参加者全体はデフォルトでシナリオグループのメンバーシップを持つ。

図８は、ブロックの参照範囲と機能シートとについて説明する図である。
シナリオ第一層のプロセス、包含型の子プロセス、モジュールの指定ブロックおよびモジュールの全集合を機能シートと呼ぶ。その範囲でのみブロックは参照しあうことができる。ＵＩ（ユーザインタフェイス上のシートとほぼ同じだが区別する（領域型のモジュール、包含ブロックなど複数の機能シートがマージされている可能性があるため）。
またブロックは配置された機能シートで定義される。
モジュール化されたオブジェクトのみが複数の機能シートにインスタンスを配置できる。型データなどの値がグローバルに保持されるかは型データのグローバルプロパティに拠る。
包含型は、デフォルトでモジュール指定されるオブジェクトを指定することもできる。参加者属性や複数の機能シートで使われることが前提のオブジェクトである。
モジュールに関してはデフォルトではモジュール内のどの場所で定義されても入れ子関係は持たないが、配置制限をモジュールのプロパティで掛けることもできる。（入れ子関係を定義することもできる）。

図９は、変数と属性について説明する図である。変数は、本プログラムのコアプロセスでの値の保存機能を表すものでシステム変数やユーザが操作不能な変数も含む。属性は、本プログラムのビジネスユーザーインターフェースの機能を示す部分である。属性はＢＵＩのオブジェクトに付属する属性を表し、シナリオ、メンバースコープ、参加者の各オブジェクトに対して定義される。属性はオブジェクト（クラス）に定義された場合、オブジェクトインスタンスそれぞれに対して値をもちグループコンテキストによって参照する値を特定しながらイベントの進行を制御する。グローバル変数の機能はシナリオグループ属性かつモジュールグローバルな属性が担う。どこにでも配置でき値がシナリオで一つである。
「属性定義されたメンバーグループ（総体）にメンバグループが追加」から、「グループ」への矢印がひかれている意味は、属性定義されたメンバーグループにメンバーグループが追加されると、定義されたグループ属性に対応するグループ変数が追加されることを意味する。
「属性定義されたメンバーグループ（総体）にメンバグループが追加」から、「ローカル」へ矢印がひかれている意味は、「属性定義されたメンバーグループにメンバーグループが追加されると、定義されたメンバ属性に対応するローカル変数が追加（メンバーにたいしてのみアクティブ）されることを意味する。
ここで、メンバースコープ、メンバグループは、グループ属性や、メンバ属性により定義されるが、グループオブジェクトは、直接定義する手段がない。したがって、メンバスコープ、メンバグループにより制御され、管理される。

図９の下にある破線の矩形に囲まれた部分は、メンバースコープに関する属性処理とモジュールにかかわる属性処理は複合することを示すものである。
定義モジュールから対応変数への矢印は、属性の含まれるモジュールが定義されると変数を追加することを意味する。
配置モジュールから対応変数への矢印は、属性の含まれるモジュールが配置されるごとに変数を追加することを意味する。

図１０は、ＵＩＢ（ユーザインタフェイスブロック）の評価範囲について説明する図である。
ＰＢ（プログラムブロック）の遷移は、ＰＢ出力からＵＩＢＰＢ（ユーザインタフェイスブロックプログラムブロック）への入力または、ＰＢ出力からＰＢ入力への遷移として実現する。
ＵＩＢの遷移は、ＵＩＢ出力からＵＩＢ入力への遷移として実現する。
代入遷移は、ステイタスから属性入力への遷移として実現する。

図１１は、Ｂ−ＵＩＢのＰＢ評価範囲について説明する図である。
評価範囲は、記述式のコンピュータプログラムにおける行に相当するものである。
ステップ評価時点での属性情報を利用して各ユーザに対する計算、表示、レスポンス、トリガ処理を行う。またその結果によって次の評価先を変更することもできる。（グラフィカルな表現として処理をステップの基準アイコンの外部に配置する場合もあれば内部に配置する場合もある）。
実現例においてはＵＩＢ（ユーザインタフェイスブロック）遷移を受けたＢＵＩＢは処理要求情報をＰＢ遷移を通じてＢＰＢ（ビジネスブログラムブロック）に送り、属性もしくは入力のないＢＰＢに到達した時点で端末ＢＰＢの処理を行い出力値を返す。返されたＢＰＢはすべての入力が揃った時点で処理を行い出力値を返す。最後にＢＵＩＢに評価を返し、ＢＵＩＢの処理を行う。
属性値は評価要求を受けた時点で代入元のステイタス情報を参照し最新の代入値あるいはデフォルト値を返す。

機能面で実現例では呼び出し関係以外のアルゴリズムを持てないが繰り返し、条件別処理など評価ステップの制御構造にて実現している機能を取り込むこともできる。（定義から範囲内部処理での待受け機能は持ち得ない）。
評価時点ではＵＩＢの出力処理を代入だけではなく一般のＢＰＢの処理も行えるようにし、評価ステップの処理に柔軟性を持たせることもできる。（この場合は出力＝処理要求となる。）
あるいはあらかじめ処理を行うＰＢの範囲を指定しておき処理を割り付ける、あるいは処理要求を入出力と切り離し単独のＰＢに対する命令としておくこともできる。

図１２は、ＢＵＩ（ビジネスユーザインタフェイス）機能モデル−編集操作モデル（一部ＧＵＩを考慮）を説明する図である。
ＧＵＩ（グラフィカルユーザインタフェイス）機能操作は、ＧＵＩで表現されるべき機能操作である。機能モデルでの操作はこれに還元される。一方、ＧＵＩ操作そのものはＧＵＩ機能操作とグラフィカル表現操作からなる。
ポート追加／削除は、特定のブロックの内部配置で行うか、ブロックのポート配置部で行う。
遷移矢を機能オブジェクトとして扱うこともできる。

図１３は、モデル機能操作マッピングの図である。
機能モデルの操作をＧＵＩ機能操作に沿った形で抽出したマッピングである。
グロック共通操作における外部ＢＵＩ呼び出しは、外部のモジュールで独自のプロパティ定義管理用ＵＩを備えているものは呼び出せる。
「遷移種別定義」は、ポートの種別と遷移先によってある程度固定される。
モジュールリスト操作において、内部定義されたモジュールは自動的に登録される。

図１４は、ＢＵＩ機能モデル（グラフィック要素を除いた制御ユニット−実用層）を説明する図である。
メンバースコープは、グループ機能の動的な管理を行う機能モデルであり基本的にはグループの集合あるいは配列であり、属するグループをメンバーグループと呼ぶ。シナリオの記述においては、メンバースコープが処理単位として記述されメンバーグループに対しては基本的に直接的な指示は記述しない。代わりにアクティブグループ指定などグループコンテキスト、ＰＢ（関数）による集合、関連操作によって処理対象のグループの特定を行う。これによってイベント内のアドホックに発生した参加者グループに関する処理を動的に処理可能となる。
メンバースコープ（ＭＳ）は複数のメンバーグループを持つことができる。ＭＳ自体もグループすべてのメンバの和集合のメンバで構成されるグループを持つ。またＭＳはメンバーグループのメンバ同士が排他的なグループ型と非グループ型のどちらかのプロパティを持つ。
メンバースコープはメンバーグループの代わりに他のメンバースコープをメンバーグループとして持つことができる。子ＭＳのＭＳメンバがメンバーグループのメンバとなる。
メンバースコープは型データと属性定義を行うことができる。属性値を持つ対象によってメンバースコープタイプ、メンバーグループタイプ、メンバータイプ、（ＭＳメンバータイプ）の三つ（四つ）のタイプに分かれる。ＭＳと属性定義した属性は複数のタイプ設定は不可能で他のグループやＭＳの属性にはなれない。

メンバースコープを管理するメンバ、グループの追加削除、アクティブ状態を制御するＢＰＢ（ビジネスプログラムブロック）が存在する。
メンバースコープは他のＭＳの子メンバースコープとして定義が可能である。この場合、このＭＧ（メンバグループ）メンバは親の定義先グループメンバの部分集合となる。
定義は属性と同じようにＭＳのグループに対して定義されるか、ＭＧのグループの部分集合として定義されるかを選択できる。ＭＧの部分集合とするとＭＧごとにＭＳのインスタンスが生成されることになる）。
ＭＳ制約がなされた包含機能シート内部で定義される非モジュールグローバルなメンバースコープは何の定義もなされない場合は制約ＭＳに対してＭＧメンバ部分集合定義となる。モジュールグローバルなＭＳは関連定義されない場合は独立ＭＳとみなされる。
属性制約については真上のＭＳの制約内で包含内部に引き継がれる。

図１５は、メンバースコープがグループコンテキストをＢＵＩＢに与えることを示す図である。
メンバースコープはグループコンテキストをＢＵＩＢに与えることができる。実際のコンテキストは属するメンバーグループによって与えられる。
遷移を受けたメンバースコープでグループコンテキストを定義されたＢＵＩＢはアクティブグループのみを実行する。初めて遷移を受けたＢＵＩＢのＭＳのメンバーグループは基本的に全てアクティブとなる。アクティブグループのフラグは一度実行されると消える。二度目以降の遷移では一回目以降新規に追加されたメンバーグループにアクティブグループが付与される。これは基本的な仕様で有り遷移の度にすべてのグループがアクティブとなる場合もあり、またＰＢによる操作でアクティブグループが指定される場合がある。
これらアクティブグループによる制御はイベントの進行に従ってアドホックに発生するグループを取り込んだ場合、メンバースコープを構成するメンバーグループのおのおののグループに重複する参加者が存在する可能性が有るために行われる。 メンバーグループのメンバーシップの重複を排除した定義を行う事も出来る（図１４上部の「グループ型か？」の記述はそのプロパティを示す）。
包含ブロックの子ＢＵＩＢには上位のＢＵＩＢブロックのグループコンテキストが付与される。上位のメンバースコープに対して定義された属性が子プロセスで使用された場合はそのグループコンテキストに従って属性値が参照される。

図１６は、システム設定属性について説明する図である。
メンバースコープでグループコンテキストを定義されたＢＵＩＢはダミー参加者（ルート参加者）を生成する。ＭＳとグループメンバのそれぞれにＢＵＩＢ実行期間だけ生存するルート参加者が生成される。それには特別な属性が振り出される。
通常の記述では実行されない記述が挿入されるものとする。
ブロックが包含タイプの場合は、その内部での記述に利用できる。
またシナリオ（グループ）にもダミー参加者が付随して生成される。これはグル−プ属性に対して処理が行われる場合、参加者記述にグループ条件付きで記述されるとなると実行回数について混同が生じる可能性が高いために別の属性の処理プロセスとして記述可能とする為である。

図１７は、エントリー条件定義及び関連参加者指定について説明する図（その１）である。
エントリィ機能はその実現ブロックをルート参加者を含む他参加者のプロセスに配置する。そのブロックが待ち受け可能となって以降のエントリィ情報を受付場所及びユーザ情報、エントリィ時刻情報を条件として発火する。
割込みＵＩＢもしくはＰＢトリガとして機能する。また発生するとその時点以降配置シート及び包含上位のトリガの内部待受け状態なりうるトリガを待受け状態にする。
図１７におけるローカルエントリィはフィールドゾーン制約の掛かったイベントエントリィである。
集合の論理演算について。メンバースコープではログ及び退出ＭＳ、元ＭＳ間の論理操作では対応グループ同士で演算が行われる。

関連参加者（集合）指定については、第一に、参加者集合（オブジェクト集合）にて、参加者集合の各メンバをログ或いは指定により現メンバに持つＵＩＢを抽出する。第二に、属性集合にて、その属性がＢに対して関連属性として定義されているＢを抽出する。第三に、グループ／メンバーシップ／ＵＩＢ集合にて、そのオブジェクト集合と関連（親子関係もしくはコンテキストグループ／ＭＳ関係）を持つＢを抽出する。Ｂは、図１７に描かれた「Ｂ」。

抽出母体オブジェクト集合については、その属性条件は、参加者集合の各メンバにデフォルト値以外を持つ属性を抽出する。
メンバーシップオブジェクト抽出についてはメンバーシップを持つオブジェクトをＡ入力した場合にメンバー集合を指すのかオブジェクトを指すのかデフォルトをそれぞれで決める必要がある。

図１８は、エントリー条件定義及び関連参加者指定について説明する図（その２）である。
図１８における一番上のＭＳメンバーグループ追加削除は、Ａ入力のグループをＢ入力のメンバースコープのメンバグループとして追加あるいは削除する。
代入出力は新たな組成のメンバースコープである。
Ｂが存在しない場合は新たなメンバースコープとして生成される。

図１８の「２−３−４」におけるＭＳメンバ追加削除は、Ａ入力の参加者集合をＢ入力のグループのメンバーとして追加或いは削除する。
Ｂ：メンバースコープ（非グループ型）＞＞すべてのグループに参加者集合がメンバとして加わる。
Ｂ：メンバースコープ（グループ型）＞＞新たなメンバグループとして参加者集合が追加される。
Ｂ：グループ集合（非グループ型）＞＞すべてのグループに参加者集合がメンバとして加わる。
Ｂ：グループ集合（グループ型）＞＞処理は行われず偽値を返す。
代入出力は新たな組成のメンバースコープ、グループ集合。
Ｂが存在しない場合は新たなメンバースコープとして生成される。

図１８の「２−３−５」におけるメンバースコープ／グループ集合への追加プロパティの指定は、代入ではなくメンバが新規メンバーグループとして追加される。
図１８の「２−３−５」における参加者オブジェクト（集合）／グループへの追加プロパティの指定は、代入ではなくメンバが格納値に追加される。

図１９は、オブジェクト関係定義、制約定義、ＭＳ属性定義、タイミング遷移について説明する図である。
図１９の「２−３−６」の制約定義については、条件比較が入る場合は、Ｂポートとパラメータを使用する。
図１９の「２−４−１」の評価時間保持型データ（属性）はデフォルトで未来値（或いはデフォルト値を呼び出す特別処理を要求する値）を保有する。また時間型は、代入遷移を受け最終評価時間を変数値として保持する。出力は時間型である。
図１９の「２−４−２」のタイミング遷移（時間型ＰＢ遷移）においてタイミング管理（真偽）は、現在時刻と比較してＡが未来時の場合は、偽、過去時の場合は真を返す。
図１９の「２−４−３」のタイミング管理は、、遷移タイミングに注目して管理する。第一に、現在時刻より未来の引数は無視する（全てが未来時の場合は未来時を返す）。第二に、無視する引数が無くなったなら最新の時間を返す（論理積）。第三に、一つでも過去の遷移があればその最初の時間を返す（論理和）。第四に、第三と同様にＸ番目に反応する。
図１９の「２−４−３」のタイミング管理において、ある待機ＢＵＩＢのタイミング管理は評価時間情報で行う。この為には関連するブロックやトリガの代入出力を評価時間保持型データで受けてそこからの時間管理型ＰＢによる評価を通じて最終的にタイミング管理ＢＰＢ（真偽）タイプで行う必要がある。
図１９の「２−４−４」の「数値」は、時間型に数値型を加減し、特定時間値を計算する。

図２０は、相互作用コネクタ、表示とレスポンス、制約、メンバースコープ制約、ＭＳログ取得、属性について説明する図である。
図２０の「２−４−５」の相互作用コネクタは、型データタイプのＰＢである。遷移元の評価時間情報及びグループ情報を得て遷移元のグループの遷移が発生した時に条件を満たすと遷移先のグループに評価時間を返す（デフォルト時は未来時）。Ｂ入力を定義しない場合は評価を受けた遷移元の集団的な条件が満たされたかはプロパティで行ってもよいし、論理和設定にして条件計算を遷移元ＰＢ評価範囲で別のＰＢ（プログラムブロック）で行ってからでもよい。
図２０の「２−５−１」のタグ生成型代入ＰＢは、親ノード中に配置されると表示テキストと関連付けるタグを生成し、ＰＢの評価時点での情報をタグの配置場所に更新表示する。親ブロックの開始時に一度ＰＢは評価される。
図２０の「２−５−１」のレスポンスは、配置されると表示テキストと関連付けられたタグを生成する。テキストに配置されたタグでイベントが発生すると対応した情報を返しステイタスを更新する。
図２０の「２−５−１」のダイアローグ（文書型包含）の内部には、入出力情報の評価プロセスを記述する。
図２０の「２−５−１」の星印００２は、「内部配置された表示ＵＩＢは別の画面を生成する」ことを意味する。
図２０の「２−５−１」のタグ生成型代入ＰＢからタグへの矢印と、レスポンスからタグへの矢印があることの意味は、このダイアローグが配置されると親ブロック（メインのテキスト）と関連付けされたタグを生成することを意味する。

図２０の「２−６−１」における制約について：
制約は一連のコンテキストが似通った一連の処理のコンテキスト条件付けを簡易にまとめるために時間、場所、属性を含む参加者メンバーシップについて類型化し各プロセスを定義可能としたものである。これによって機能シート上に属性やメンバースコープ、サービスを提供する場所や時間ごとの処理を並列的に記述しその関係をタイムゾーン遷移などで関連付けする事によって、各シナリオ参加者の類型ごとのダイアローグやチャットとしてシナリオを記述することが可能となる。また通常の参加者だけではなく、現場で通常参加者と応答する機器や器具も参加者としてとり扱え、機器を含めた相互作用が特にサービスの処理記述段階では明確に識別できる。
１： 制約はブロック開始条件として機能する。待機プロパティを指定すると待機型となり開始ＵＩＢ遷移を受けてすべての制約（メンバースコープは一つ絵もメンバグループが成立したなら）を満たすまで待ち受けとなる。このプロパティはデフォルトでは一括だが個別に設定することもできる。非待機の場合は条件を満たさないとそのブロックはスキップされる。
２： 制約は例外条件として機能する。制約条件を一つでも満たさなくなると中断が発生しブロックは終了する。ＭＳ制約が入っている場合はグループすべてが終了かその参加者のみ退出かプロパティで決定する。
３： 条件として指定できる要素がそれぞれ限定される。

図２０の「２−６−２」のメンバースコープ制約は、一つのメンバースコープオブジェクトを指定する。指定されたＢＵＩＢは、コンテキストグループとなる。
図２０の「２−６−２−１」のＭＳログ取得ＰＢについて：ＭＳ制約ブロックの実行中はアクティブグループメンバーの変動をブロックするプロパティを指定可能である。メンバーの変動を許容する場合は途中加入／離脱メンバーを指定漢方な退出者ＭＳを自動生成する。またメンバーの差分を計算する為ログ取得ＰＢを作成する。
図２０の「２−６−３」の属性について：属性条件は属性一つ以上を指定可能（論理積）。属性値による条件も指定可能。ｉｆ型の属性条件をＰＢで指定。グループコンテキストを指定するメンバースコープのグループも条件などで指定可能（条件を指定）。

図２１は、タイムゾーン制約、フィールドゾーン制約、ＢＵＩＢプロセス、基本的なＰＢについて説明する図である。
図２１の「２−６−４」の、タイムゾーン制約は、時間に関する開始条件と例外条件である。包含タイプ及び待機型においては（待受け）開始、中断（、待機終了）の二つの条件を定義する。通常は開始のみである。真偽型のタイミング管理ＰＢで指定する必要がある。
図２１の「２−６−５」のフィールドゾーン制約は、フィールドゾーンを一つ指定する。フィールドゾーン制約はフィールドインが開始条件となる。フィールドアウトが発生したら中断する。
図２１の「２−６−６」のＢＵＩＢプロセスにおいてはヘッダーのメンバースコープ、属性、フィールドゾーン制約は全てに影響を与える。個別で制約が変わる場合は論理積条件となる。その場合でデフォルトで制約の待機プロパティはヘッダーが待機、プロセス中ブロックはスキップとなる。
図２１の「２−７−１」の文字列合成において、テキストに対して他の型をフォーマット合成するものもあると望ましい。

図２２は、序列算出、管理者トリガ、外部トリガ待受けＰＢ、レスポンスＢＵＩＢ、イベントステイタス生成、コンテキスト限定ページ発行、ＵＲＬ発行について説明する図である。
図２２の「２−７−２」のオーダー化について：メンバ、メンバグループの数値型、時間型属性情報から序列を算出し値に代入する。同順位は存在しない。ＭＳの構成更新時に再計算できる仕様が望ましい。
図２２の「２−７−２」におけるメンバースコープについて：同一メンバースコープのグループ属性同士かメンバ属性同士である必要がある。
図２２の「２−８−１」の外部トリガ待受けＰＢについて：記述された包含ブロックが開始されると待ち受けを開始する。通常出力は遷移タイミング管理用の真偽か数値（カウンタ）型。
図２２の「２−８−１」では、「管理者トリガ」から「外部トリガ待受けＰＢ」に向けて矢印が引かれているが、そのたウェブ上のイベントなど、どのメンバースコープに対するものでもあり得る。
図２２の「２−８−１」のレスポンスＢＵＩＢについて：端末アプリやブラウザで取得できる情報である。
図２２の「２−９−１」のコンテキスト限定ページ発行は、指示した表示ＵＩＢページをカレントにしてＱＲチェックもしくはその他の近接交信手段でチェックするとそのコンテキスト（指示したユーザチェックでのトリガ発生）でチェックが発生する。双方異なるページでのチェック発生時には確認するシステムレスポンスが開かれる。
図２２の「２−９−２」のＵＲＬは、ウェブページのＵＲＬを送ることを意味する。

図２３は、制約の機能を接続したＵＩＢに与えること、ステイタス評価、管理者コンタクトについて説明する図である。
図２３の「２−１０−１」は、制約の機能を接続したＵＩＢに与えることの説明である。
図２３の「２−１０−１」の型データは、複数の代入を受け入れ最新の評価時間の値を受け入れる（変数の機能を実現する為）。
図２３の「２−１０−１」において、星印００３は、「ステイタス型は[ステイタス側評価時間，出力名，型，値，（グループオブジェクト）］の構造を持つ。」を意味する。
図２３の「２−１０−１」における星印００４は、「評価時間が存在しない（遷移元が全て未評価か代入が存在しない型データはデフォルトの値を持つ。包含ブロック内でステイタスターミナル限定をされた型データブロックは包含ブロック外側に出力ポーとを生成する。型データが評価される度にポートはステイタスを発行する。ステイタスの内訳は、評価時間：型データのＵＩＢ評価範囲の評価時間，出力名：型データの名称，型：型データの型，値：現在値，メンバー：実行中参加者／ＭＳ制約中なら所属グループ」を意味する。
図２３の「２−１０−２」のステイタス評価は、包含ブロック内でステイタスターミナルと対になる機能である。ステイタス評価ＵＩＢを配置すると型やり取りする型情報をプロパティ指定する。すると対応したＰＢ評価遷移ポートが外部に出現する。外部のポートは指定した型を受け入れ、ＵＩＢ名を入力名称として表示する。またステイタス評価ＵＩＢはその値を出力するステイタスポートを持つ。
図２３の「２−１０−３」の管理者コンタクトは、表示ＵＩＢあるいは文書型の包含ＵＩＢになる。管理者との連絡手段の呼び出し機能を持つ。ここでの管理者は、このイベント管理システムの管理者である。

図２４は、モジュールリストについて説明する図である。
モジュールリストは、定義されたモジュールのリストである。シナリオ内定義のほかに外部のデータもこちらで取り扱われる。
内部定義モジュールは、どれか一つの機能シートで定義されるとモジュールリストに追加される。
外部定義モジュールは、何らかのインポート処理された外部定義のモジュールである。使用上の参加者属性やライブラリから引っ張ってくるオブジェクトは外部定義モジュールとして取り扱われる。
機能シートは、一つの機能シートに一つのインスタンスのみ配置できる。
フィルタリングは、モジュールのプロパティによる閲覧制限によって自動的なフィルタリングをするものである。通常のスコープ機能の代替として用いられる。

図２５は、オブジェクト数抽出と、アクティブグループ指定について説明する図である。
オブジェクト数抽出は、Ａのオブジェクト集合のオブジェクト要素数もしくはメンバー（参加者）数を抽出する。
アクティブグループ指定について： アクティブグループ指定ＰＢが一度結合でヘッダーに接続されている場合、デフォルトのアクティブグループ指定は初期化されチェックされる。

図２６は、ヘッダーの機能を説明する図である。

図２７は、制約とヘッダー、フッターの関係を示す図である。
属性：オーダー型からプログラムブロック（ＰＢ）へのオーダーは、ＭＧ（メンバーグループ）もしくはＭＧメンバのオーダー属性順によるシーケンスを実行する。
ヘッダーにつながるＰＢのうち、下のＰＢは、ｂｏｏｌであり、繰り返し終了のＰＢ入力ポートである。真値で繰り返し終了する。
フッターのブレイクは、繰り返し実行は終了する。
フッターのコンティニューは、繰り返し実行を続ける。無記も同様である。

図２８は、ＢＵＩにおけるグラフィカルユニット（アイコンとパレット）について説明する図である。
図２８において、星印００５が３カ所に出現する。これらは、「ブロック内の何らかの線描修飾による区別」を意味する。
図２９は、フィールドゾーン定義属性アイコンを説明する図である。破線の矩形で囲んだ二つの図形は、フィールドゾーン定義属性アイコンとして扱う。
図３０は、区分例を示す図である。型データは、上下又は左右に反転可能としてもよい。
図３１は、区分例を示す図（続き）である。図３１の上部に描かれた二つの破線で描かれた矩形（破線の囲い）は、いずれも単純な領域又はメモを意味する。メモは不透明にできる。
ポートにはポート名と型名が付属される。表示は外と中どちらでも選択可能であることが望ましい。
タブによる表示方式は、選択されたプロパティタブやポートなどのプロパティ情報をプロパティ表示ボックスの表示する。
メモ連携による表示方式の場合、プロパティ表示ボックスにはプロパティアイコンが並ぶ。ポートやプロパティアイコンとメモ領域を結ぶとメモはプロパティ表示モードとなりそこに該当項目の情報が表示される。複数の情報メモを周囲に配置することが可能である。
全体情報：タブ方式ではブロックプロパティタブ、メモ連携ではブロックプロパティアイコンと結ぶ全体のサマリーが表示される。
プロパティ修正：プロパティ情報表示部分やボックスの地をクリックすると全体のプロパティ設定画面が現れる。

図３２は、遷移矢について説明する図である。ＵＩＢ遷移の矢軸だけ太さを若干太めにする。時間型のＰＢ遷移は他と区別する。
図３３は、ステイタスアイコン化／表示を説明する図である。ステイタスアイコンには相手ボックス名とポート名が表示される。
ステイタスアイコン化された遷移があるブロックにマウスが移動すると全てのステイタスアイコンが遷移矢に戻る。
通常ＢＰＢの表示では、ステイタスアイコンにマウスが移動するとそのポートのアイコンが遷移矢に戻る。クリックすると全表示モードと縮小モードを行き来する。
図３４は、区分例におけるグラフィカル操作（機能モデル関連）を説明する図である。
図３５は、区分例におけるグラフィカル操作（機能モデル関連）を説明する図（続き）である。
図３６は、表示コンテキスト指定タグを説明する図である。ウインドウとブロック、ポップアップは、（シナリオ）属性として定義される。（関連性の定義も同様）。
ウインドウ＋名称＋クラス。
ブロック＋名称＋表示区分＋所沿いウインドウ（所属クラス）＋プロパティ＋指示ウインドウ＋テキストＵＲＬ。
ブロック＋名称＋表示区分＋所属ウインド（所属クラス）。

≪実施例：中国茶の入れ方 チュートリアル≫
図３７は、図３８から図４１までの４枚の図の配置（つながり）の関係を示す図である。図３８の右側には図４１がつながる。図３８の下側には図４０がつながる。図３９の下側には、図４１がつながる。図４０の右側には、図４１がつながる。

図３８から図４１までの４枚の図を参照しつつ、実施例について説明する。
Ｃ）中国茶の入れ方チュートリアル（異なる役割を持つ参加者の相互作用（ダイアローグ/チャット）の記述。）
実施例：プロセス型消費商品の販売プロモーション
中国茶を温度感知機能の付いた茶器で適切な温度で飲むガイド配信。

参加者の種別
Ａ：客
Ｂ：スタッフ
（Ｃ：茶器＜ポット、蓋碗＞＞登録シーンでスタッフが茶器を登録するとダミー参加者が生成。温度変化と指定温度を返すＵＩブロックを持つ）

１：茶器はポット＊、蓋碗＊、茶海、茶碗。＊に温度感知機能があり、その時点での温度を属性に返し、急激な温度変化（上昇、下降）をトリガとして発生させる外部モジュールを持つ。＃急激な温度変化は蓋碗にお湯が注がれた時、お湯を注いだ時に発生。ポットのモジュールは温度変化によるトリガを持たない。
２：進行は登録シーン、受け取り確認シーン、洗茶シーン＊（省略）、一番茶シーン＊、二番茶シーン＊（省略）、三番茶シーン＊（省略）、評価シーンに分かれる。＊印のシーンの開始は蓋碗の温度上昇で開始。注ぎ（温度低下）で終了。３：一番茶シーンから三番茶シーンには適切な温度帯、適切な茶出し時間情報がある。＞＞蓋碗のＵＩブロックから温度上昇のレスポンスの後６０秒±１０秒の間に温度低下レスポンスを受け取ると正常終了。
４：ポットの温度が一定以下になると湯を変える警告が発せられ、ポットが一定温度以上になるまで進行は停止する。＞＞ポットのＵＩブロックから温度低下レスポンスを受け取ると発生。
５：適温からあまりにずれた茶のシーン、急激な温度低下が起こらなかったシーンは例外となりやり直しとなる。（このセンテンス省略）
６：評価シーンでは適温内、茶出し時間をクリアしたシーンが３ポイント、失敗シーンが-1ポイントとして総合ポイントが決められ、９点で優秀メッセージ、５ポイント以上で合格、それ以下で頑張りましょうメッセージが配信される。
７：各シーン終了後には次のシーンの説明記事が配信される。それには映像画面パーツが含まれ最後まで閲覧しないと次に進めず警告が発せられやり直しとなる。
８：登録シーン＞＞個々の機器の識別データをスタッフ参加者がコンタクトして更新する事前のシーンを追加する。（URL化された識別情報を取得してライブラリデータを更新する外部モジュールの設定）茶器はその日に使うセットが複数存在する。
９：受け取り確認シーンでは登録された茶器の内一セットを参加者と関連付けする。

以上のシナリオをイベント管理システムのシナリオに構成した図を示す。これはモデル図ではあるがそれぞれの要素はGUIエディター上でブロックを配置した場合のブロックとブロック間の遷移指示関係と対応している。
シナリオはBUIBの処理プロセス毎に（R-1）などの附番がなされている。この附番に従って解説を行う。
シナリオの全体構成はR-1~R-3とその包含ブロック内部の子プロセスからなる登録ステージ、Sプロセスとその内部からなるセッティングステージ、Cプロセスとその内部からなるコンテンツステージから構成される。
登録ステージでは茶器とスタッフによって端末で識別可能な茶器に茶器属性を持つ参加者として登録します。
セッテイング（受け取り確認）ステージでは顧客登録時に登録した茶器で茶器セットを構成しスタッフが顧客と関連付けします。
コンテンツステージでは一番茶シーンを属性毎の処理プロセスで表現しています。

各プロセスの解説
R-1:シナリオルート（ダミー参加者）のプロセスとしてスタッフ（参加者）属性を持つ参加者のエントリィ処理を行い、茶器の個別の属性をまとめて属性集合を作っています（セッティングプロセスである茶器ががどの属性を持っているか判定する為（属性値で判別すればこの場合はシンプルになるがコンテンツステージで茶器種別属性毎のプロセスを分かりやすく見せるため））
R-2:茶器登録。スタッフ参加者プロセスとして茶器とユーザチェックを行い茶器登録を行うチェック用（ＱＲ/読み取り）コンテキストページの処理を行うダイアローグを呼び出し各スタッフが登録終了確認を行うまでループさせる。確認したスタッフ数は確認計属性に収納される。
Ｒ-2-1：茶器となるアイテムとユーザチェックが行われた場合茶器としてエントリィが行われそのグループ情報がユーザチェック格納0に新たなメンバーグループとして収納される。追加の処理がＲ-3で行われ、その終了情報がＡ待機時間属性で返り包含ブロックを閉じる。
Ｒ-3：エントリィ登録された茶器とスタッフによるグループをまとめたメンバースコープにて茶器の属性登録を行う。終了すると終了時間をＡ属性に収納して終了。
Ｒ-3-1：スタッフが表示された登録申請画面で茶器の種別を数値で入力すると終了。
Ｒ-3-2：茶器のプロセスでありスタッフの入力数値に従って蓋碗かポットの属性値が真となる。
R-4:スタッフの登録処理終了がスタッフ数（エントリィした総数）を超えると次のステージに進む。

S:店舗営業時間での顧客エントリィを行い、茶器とのセッティングを行うステージ（その後の顧客毎のコンテンツプロセスも子プロセスの包含ブロックに収納される。営業終了時間で閉じる。
S-1：顧客エントリィ処理を行い顧客プロセスメンバースコープのメンバグループとして編入する。
S-2:顧客とスタッフがユーザチェックを行いそのコンテキストでスタッフが作った茶器セットを含めてグループ化してコンテンツステージを開く。
S-3:スタッフ用のプロセス。対応に入ると返したスタッフは茶器セットを作るために茶器とユーザチェックを行う。茶器セットが形成されたらS-2の顧客とのユーザチェックへ。
S-4:S-3の茶器とのユーザチェックで生まれたスタッフと茶器のペアのグループの処理。既存の茶器セット（形成途中）グループが有ればそれに茶器を加え（すでに同種の茶器があればはじく）、無ければ茶器セットのメンバースコープに新しいメンバーグループとして追加する。
S-5:茶器セットMSを利用して茶器セットグループを形成する。ループ処理で付け加えられる茶器が茶器セットの構成を満たしているかチェックし満たしているなら処理終了。

C:コンテンツステージ、給茶プロセス。属性ごとの子プロセスで一番茶のサーブを管理する。終了して包含ブロックが閉じられると茶出しの評価点を算出する。
C-1:顧客プロセス。他の参加者のプロセスによるコンテキスト情報に従い給茶を行う。時間制限がある。
C-2:ポットのプロセス。最初の温度上昇と低下、それ以降の上下によってイベントが発生する。
C-3:蓋碗のプロセス。温度上昇と下降によってイベントが発生する。
C-4:スタッフの最初のお湯入れの指示。
C-5：スタッフのお湯が冷めた時のポットへの入れ替え指示。

≪イベント作成者がこのプログラムをつかうことで、イベント作成がしやすいことについて≫
ダイアローグを多用するので、イベント作成者はつくりやすい。（グラフィカルユーザインタフェイスを使う場合は、なお、わかりやすい）。
評価範囲ごとに評価がなされるので、ダメだしが出ても、どこを直せばよいかの範囲が限られているためわかりやすい。
メンバースコープ、属性、タイムゾーンなどの制約にしたがって作成するので、イベント作成者が実行可能性について、気にすることなく作成ができる。
このプログラムは、このように働くので、イベント作成者がコンピュータプログラムに精通していなくても、実行可能なイベントを作成可能である。

≪修正：相互作用の様相と、メンバースコープの親子関係について≫
図１４を参照しつつ、説明した部分に、「メンバースコープはメンバーグループの代わりに他のメンバースコープをメンバーグループとして持つことができる。子ＭＳのＭＳメンバがメンバーグループのメンバとなる。」と書いた（段落００４９）。また、図１５を参照しつつ説明した部分に、「包含ブロックの子ＢＵＩＢには上位のＢＵＩＢブロックのグループコンテキストが付与される。上位のメンバースコープに対して定義された属性が子プロセスで使用された場合はそのグループコンテキストに従って属性値が参照される。」と書いた（段落００５１）。
これらの事項に関連して、図４４を参照しつつ、修正と補充を述べる。
メンバースコープ（ＭＳ）は他のＭＳの子メンバースコープとして定義可能である。この場合、子のＭＧメンバは親の定義先グループメンバの部分集合となる。
定義は属性と同じようにＭＳのグループに対してかＭＧのグループの部分集合として定義されるか選択できる（ＭＧの部分集合とするとＭＧごとにＭＳのインスタンスが生成される事になる）。
MS制約がなされた包含機能シート内部で定義される非モジュールグローバルなメンバースコープは何の定義もなされない場合は制約MSに対してMGメンバ部分集合定義となる。モジュールグローバルなMSは関連定義されない場合は独立のMSとみなされる。
属性制約については直上のMSの制約内で包含内部に引き継がれる。

図４４(a)は、相互作用の様相を示す図である。
相互作用の様相図：MSで成約した包含内部では参加者の処理はアクティブグループに限定される。またそこで子MS、属性で制約された処理のメンバーはアクティブグループのメンバーシップを持つ対象に限られる。MS、属性がグローバルモジュールである場合はメンバーシップは包含関係の制約を受けない。無記のMSがどちらの処理の適用を受けるかはプロパティ/実装による。

図４４(b)は、メンバースコープの親子関係を示す図である。
メンバースコープの親子関係図：子メンバースコープのメンバーグループは親MSのメンバーグループのどれかに属する（部分集合）。
どのメンバーグループに属するかはアクティブグループでの挙動で決定される。
アクティブグループ上（親MSの制約した包含機能シート）で（子MSがその上に配置されて）グループ操作が行われる場合、グループの追加、メンバーの増減はそのアクティブグループのメンバーで行われ、追加されたグループはその上位のメンバーグループに属する。アクティブグループの範囲を超えたグループ操作がなされた場合は無視される。
このメンバースコープの親子関係は各メンバーグループにおいてもアクティブグループの挙動によって子MSのMGにも引き継がれそれぞれがユニークな親MGを持つ事になる。
またこの親子関係によって親MGのグループ属性のグループコンテキストによる参照範囲もその子MGに限定される事になる。
親の制約プロセス外で子MSが配置された場合はそこで生成されるグループは部分集合関係を持たない。

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

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

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

Claims (17)

1. イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、
   及び
   前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩ
   を格納するＡＰＩデータベースと、
   イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
   ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
   イベント生成者が用いるイベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、前記イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
   前記生成されたイベント実行プログラムが、当システムにおける実行可能性の所定基準に適合することを評価し、その結果が肯定的であるイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
   ネットワークを通じてイベント参加者が用いるイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部とを備えたイベント管理システムであって、
   前記イベント実行プログラムは、
   グループの配列であり、参加者グループの集合であるメンバースコープというオブジェクトと、
   前記メンバースコープを構成するオブジェクトのいずれか一つ以上について定義され、オブジェクトインスタンスに対してユニークな属性値を持つ属性と、
   処理に対するグループコンテキストによる属性値の特定手段と、
   集合操作もしくは関連性抽出操作を行う一つ又は複数の関数と
   を有し、
   前記メンバースコープによる参加者の限定をすることにより、複数の前記イベント参加者又は複数の前記機器間の相互作用を制御することを特徴とするイベント管理システム。
2. 前記属性値の特定手段は、
   メンバースコープによる参加者の限定、メンバースコープの現在処理グループ、又は包含関係による上位のメンバースコープによる参加者の限定のうちのいずれか一つ以上を含むことを特徴とする請求項１に記載するイベント管理システム。
3. 前記集合操作もしくは関連性抽出操作を行う一つ又は複数の関数は、
   論理演算を実行する関数と、
   メンバーシップオブジェクト間の関連性抽出を実行する関数と、
   メンバースコープメンバーグループ追加削除を実行する関数と、
   メンバースコープメンバー追加削除を実行する関数と
   を含むことを特徴とする請求項１に記載するイベント管理システム。
4. シナリオ又はタイムゾーンを、前記イベント実行プログラムのブロックであるユーザインターフェイスブロック、プログラムブロック及びプログラムブロックの遷移木である評価範囲の組み合わせにより親子関係で表現することを特徴とする請求項１に記載するイベント管理システム。
5. シナリオ又はタイムゾーンを、前記イベント実行プログラムのブロックであるユーザインターフェイスブロック又はプログラムブロックを複数包含する包含ブロックにより親子関係で表現することを特徴とする請求項１に記載するイベント管理システム。
6. 前記ユーザインターフェイスブロックは、イベント生成者ユーザインターフェイスブロックと、イベント参加者ユーザインターフェイスブロックとからなり、
   前記イベント実行プログラムは、複数のイベント生成者ユーザインターフェイスブロックの相互割込みにより実行されることを特徴とする請求項４又は請求項５に記載するイベント管理システム。
7. 前記イベント実行プログラムは、
   ブロック開始条件として機能する制約を有し、
   前記複数のイベント生成者ユーザインタフェイスブロックの相互割込みは、前記制約によって統合的に管理されることを特徴とする請求項６に記載するイベント管理システム。
8. 前記イベント実行プログラムは、
   ブロック開始条件として機能する制約を有し、
   前記メンバースコープは、前記制約によって統合的に管理されることを特徴とする請求項４から請求項７までのいずれか１項に記載するイベント管理システム。
9. 前記イベント実行プログラムは、
   遷移元の評価時間情報及びグループ情報を取得して、遷移元のグループの遷移が発生した時に、条件を満たすと遷移先のグループに評価時間を返すプログラムブロックである相互作用コネクタ
   を有し、
   前記相互作用コネクタを用いて全体処理及び相互処理の管理を実行することを特徴とする請求項１から請求項８までのいずれか１項に記載するイベント管理システム。
10. 前記イベント実行プログラムは、
    遷移のタイミング管理を、評価時間同士、加算時間の演算と現在時刻の比較制御で実行する
    ことを特徴とする請求項１から請求項９までのいずれか１項に記載するイベント管理システム。
11. 前記イベント実行プログラムは、
    ユーザインタフェイスブロック、プログラムブロック、及び入出力ポートを含むアイコンをグラフィカルに表示する
    ことを特徴とする請求項４から請求項１０までのいずれか１項に記載するイベント管理システム。
12. 前記イベント実行プログラムは、
    ユーザインタフェイスブロック、プログラムブロック、及び入出力ポートのうち関連するアイコンにイベントが発生した時に当該アイコンにつながる遷移矢を表示し、その他の時点では相互のポートを示すアイコンのみを表示することを特徴とする請求項１１に記載するイベント管理システム。
13. 前記メンバースコープで参加者を限定された前記包含ブロック中で定義された新たな下位のメンバースコープは、上位のメンバースコープで参加者を限定した子プロセスで生成管理され、
    当該下位のメンバースコープの所属グループのメンバーは上位メンバースコープのアクティブグループの部分集合となる
    ことを特徴とする請求項５に記載するイベント管理システム。
14. 前記イベント実行プログラムは、
    ユーザインターフェイスと、当該ユーザインターフェイスのタイミング、コンテキスト制御に用いるユーザインターフェイスブロックと、
    制御の詳細を定義するプログラムブロックと
    を組み合わせてなり、
    前記イベント登録処理部は、前記イベント実行プログラムに対して、変数ブロックで囲まれたプログラムブロックの遷移木である評価範囲によるイベント駆動評価処理を実行することにより、前記実行可能性の所定基準に適合するイベント実行プログラムを前記イベントデータベースに登録することを特徴とする請求項１から請求項４までのいずれか１項に記載するイベント管理システム。
15. イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、
    及び
    前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩ
    を格納するＡＰＩデータベースと、
    イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
    ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
    イベント生成者が用いるイベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、前記イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
    前記生成されたイベント実行プログラムが、当システムにおける実行可能性の所定基準に適合することを評価し、その結果が肯定的であるイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
    ネットワークを通じてイベント参加者が用いるイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部とを備えたイベント管理システムであって、
    前記イベント実行プログラムは、
    グループの配列であり、参加者グループの集合であるメンバースコープというオブジェクトを用いて、当該メンバースコープによる参加者の限定をするとともに、
    遷移元の評価時間情報及びグループ情報を取得して、遷移元のグループの遷移が発生した時に、条件を満たすと遷移先のグループに評価時間を返すプログラムブロックである相互作用コネクタ
    をさらに有し、
    前記相互作用コネクタを用いて全体処理及び相互処理の管理を実行することを特徴とするイベント管理システム。
16. イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、
    及び
    前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩ
    を格納するＡＰＩデータベースと、
    イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
    ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
    イベント生成者が用いるイベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、前記イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
    前記生成されたイベント実行プログラムが、当システムにおける実行可能性の所定基準に適合することを評価し、その結果が肯定的であるイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
    ネットワークを通じてイベント参加者が用いるイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部とを備えたイベント管理システムであって、
    前記イベント実行プログラムは、
    グループの配列であり、参加者グループの集合であるメンバースコープというオブジェクトを用いて、当該メンバースコープによる参加者の限定をすることにより、複数の前記イベント参加者又は複数の前記機器間の相互作用を制御するとともに、
    遷移のタイミング管理を、評価時間同士、加算時間の演算と現在時刻の比較制御で実行することを特徴とするイベント管理システム。
17. イベントの構成単位であるシナリオの実行、イベント参加者端末とのメッセージ送受信、イベント参加者端末の位置情報処理、イベント進行記録、ログデータ収集、広告配信のうち少なくとも１以上を実行管理するイベント実行管理ＡＰＩ、
    及び
    前記イベント実行管理ＡＰＩによる操作対象である端末、機器、物品、建物、場所、移動手段、通信手段のうち少なくとも１以上を含む物理的リソースを各々識別して管理するリソース管理ＡＰＩ
    を格納するＡＰＩデータベースと、
    イベント実行プログラム及び当該イベント実行中に生じたログデータを格納するイベントデータベースと、
    ＡＰＩ提供者端末から所定のＡＰＩ定義仕様に適合するＡＰＩを受信し前記ＡＰＩデータベースに登録するＡＰＩ登録処理部と、
    イベント生成者が用いるイベント生成者端末に対して所定のイベント定義仕様、及び前記ＡＰＩデータベースに格納されたＡＰＩのうち任意に選択されたＡＰＩを送信し、前記イベント生成者端末において前記イベント定義仕様に従い受信したＡＰＩをコンポーネントとして生成されるイベント実行プログラムを受信するイベント生成処理部と、
    前記生成されたイベント実行プログラムが、当システムにおける実行可能性の所定基準に適合することを評価し、その結果が肯定的であるイベント実行プログラムを前記イベントデータベースに登録するイベント登録処理部と、
    ネットワークを通じてイベント参加者が用いるイベント参加者端末との間でイベント実行に必要な又はイベント実行に関連する情報の送受信を行う通信処理部とを備えたイベント管理システムであって、
    前記イベント実行プログラムは、
    グループの配列であり、参加者グループの集合であるメンバースコープというオブジェクトを用いて、当該メンバースコープによる参加者の限定をすることにより、複数の前記イベント参加者又は複数の前記機器間の相互作用を制御するとともに、
    ユーザインターフェイスと、当該ユーザインターフェイスのタイミング、コンテキスト制御に用いるユーザインターフェイスブロックと、
    制御の詳細を定義するプログラムブロックと
    を組み合わせてなり、
    前記イベント登録処理部は、前記イベント実行プログラムに対して、変数ブロックで囲まれたプログラムブロックの遷移木である評価範囲によるイベント駆動評価処理を実行することにより、前記実行可能性の所定基準に適合するイベント実行プログラムを前記イベントデータベースに登録することを特徴とするイベント管理システム。

Images