JP2005141631A - 情報処理端末およびグループ機能制御方法 - Google Patents

Abstract

【課題】 グループの状態変化に応じて、仮想グループに適用するソフトウェア構成を最適化できる情報処理端末およびグループ機能制御方法を提供する。
【解決手段】 通信網を介して接続された複数の端末装置をメンバ端末として仮想的なグループを形成して各メンバ端末と情報を交信する情報処理端末において、グループ活動に適用可能な複数種類のコンポーネントモジュールについて、各コンポーネントモジュールの適用条件を定義したコンポーネント管理テーブルと、グループの状態が変化した時、上記コンポーネント管理テーブルに定義された適用条件をチェックし、適用条件が成立したコンポーネントモジュールを少なくとも１つのメンバ端末に配信するコンポーネント管理ルーチンとを有する。
【選択図】 図２

Description

本発明は、情報処理端末およびグループ機能制御方法に関し、更に詳しくは、無線あるいは有線の通信網を介して接続された複数の端末装置をメンバ端末として仮想的なグループを形成し、上記メンバ端末と情報を交信する情報処理端末およびグループ機能制御方法に関する。

近年、ユビキタス情報社会における複数の情報機器を連携させる技術として、ピア・ツー・ピア（Peer-to-Peer）Ｐ２Ｐやアドホックネットワークが注目されている。Ｐ２Ｐは、管理サーバを経由することなく、端末間で直接データパケットを通信する通信方式であり、アドホックネットワークは、例えば、ワークステーション、パーソナルコンピュータ、ハンドヘルドコンピュータ、携帯電話機などからなる複数の情報処理端末が、無線基地局や有線通信網のアクセスポイントとなるルータ装置によるパケット転送制御機能を利用することなく、端末間でのバケツリレー形式のパケット中継によって、相互に通信する通信方式である。

Ｐ２Ｐを利用して複数の端末を連携した情報システムを構築する場合、ネットワーク空間に存在する複数の端末からなる仮想的なグループを定義し、各端末で動作するシステム利用目的に応じたアプリケーションソフトによるデータ処理結果を上記グループ内に限定して通信する。仮想グループを生成する時、例えば、Brendon J. Wilson著の「ＪＸＴＡ」、New Riders Publishing、２００２年６月、２８５頁〜２８７頁、３３０頁（非特許文献１）に記載されているように、仮想グループに付随させて独自のサービスモジュールを定義することが知られている。この場合、各端末のアプリケーションソフトは、例えば、グループに参入する際の認証機能や、グループ内の他の端末の動作状況を監視するモニタリング機能など、予め定義されたサービスモジュールによる特殊な機能を利用したグループ活動を実現できる。

特開２００１−３４６２６７号公報の第３頁〜第４頁（特許文献１）は、移動端末を対象とした変動型のグループ通信を実現する場合に、移動端末の位置情報のみならず、リアルタイムに変化する移動端末の属性または移動状態も考慮して、グループのメンバ端末を特定し、サービス情報を提供することを提案している。具体的に言うと、例えば、ガソリンスタンド店において、「湘南海岸に行く」、「燃料残量が一定量以下」などのメンバ属性や移動状態を指定し、指定条件に該当した端末からなるグループに対して、その店のコマーシャル情報を配信するようにしている。

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

Brendon J. Wilson著の「ＪＸＴＡ」、New Riders Publishing、２００２年６月、２８５頁〜２８７頁、３３０頁

上記従来技術は、何れも仮想グループの形成時に、グループ活動に適用すべきソフトウェア機能を確定しており、グループ活動の開始後にグループの状態変化に応じて適用すべきソフトウェア機能を動的に変更する構成にはなっていない。

しかしながら、例えば、会議室において参加者が使用する複数の端末で１つの仮想グループを形成し、会議で参照されるプレゼンテーション資料を各参加者の端末（メンバ端末）に配布することによって、全メンバ端末で同一のプレゼンテーション画面を共有した形で会議を進行する電子会議システムにおいて、企業内のメンバによって会議を開催中に、社外者が新たな参加者として会議に加わった時、会議で報告された機密資料が社外者によって持ち出されるのを防止するためのソフトウェア機能を電子会議システムに追加することが望まれる。

このように、グループの状態に適合したソフトウェア構成でグループ活動を行おうとした場合、上述した従来技術によれば、仮想グループの生成時点で最適なソフトウェア構成を予め定義しておく必要がある。従って、グループの状態変化によってソフトウェアの構成を変更したい場合は、既存のグループを一旦解散し、ソフトウェア構成の異なる新たなグループを生成し直す必要がある。

本発明の目的は、グループの状態変化に応じて、仮想グループに適用するソフトウェア構成を最適化できる情報処理端末およびグループ機能制御方法を提供することにある。
本発明の目的は、グループの状態変化に応じて、グループ活動のためのメンバ端末の情報処理機能を動的に変更できる情報処理端末およびグループ機能制御方法を提供することにある。

上記目的を達成するため、本発明は、通信網を介して接続された複数の端末装置をメンバ端末として仮想的なグループを形成し、上記メンバ端末と情報を交信する情報処理端末が、グループ活動に適用可能な複数種類のコンポーネントモジュールについて、各コンポーネントモジュールの適用条件を定義したコンポーネント管理テーブルと、グループの状態が変化した時、上記コンポーネント管理テーブルに定義された適用条件をチェックし、適用条件が成立したコンポーネントモジュールを少なくとも１つのメンバ端末に配信（ローディング）するコンポーネント管理ルーチンとを有することを特徴とする。グループ活動に適用可能なコンポーネントモジュールは、上記情報処理端末が備えるファイル装置に予め蓄積されていてもよいし、必要に応じて上記通信網に接続されたサーバまたは他のメンバ端末から取得してもよい。

更に、詳述すると、本発明の情報処理端末は、グループのメンバとなる端末装置のアドレス情報と端末装置のユーザ情報とを記憶するグループ管理テーブルと、グループへのメンバの参加または離脱の都度、上記グループ管理テーブルを更新し、上記メンバの参加または離脱を前記コンポーネント管理ルーチンにグループの状態変化として通知するグループ管理ルーチンとを有することを特徴とする。

本発明の１実施例では、上記コンポーネント管理ルーチンが、適用条件が成立したコンポーネントモジュールをグループのメンバとなる全端末装置に配信すると共に、該コンポーネントモジュールを自端末でも実行可能とする。また、コンポーネント管理テーブルが、各コンポーネントモジュールの適用条件と対応して、該コンポーネントモジュールの実行に際してグループ内での同期の要否を示す情報を含み、上記コンポーネント管理ルーチンが、前記配信コンポーネントモジュールが同期を要するコンポーネントモジュールの場合、コンポーネントモジュールの配信先となった端末装置が上記コンポーネントモジュールを受信したことを確認して、該コンポーネントモジュールの実行開始を指示する。

本発明によるグループ機能制御方法は、通信網を介して接続された他の複数の端末装置をメンバ端末として仮想的なグループを形成し、上記メンバ端末と情報を交信する情報処理端末が、グループの状態変化を検出する第１ステップと、グループの状態変化が検出された時、該状態変化が予め定義されたサービスコンポーネントの適用条件に該当するか否かをチェックする第２ステップと、グループの状態変化がサービスコンポーネントの適用条件に該当した場合、少なくとも１つのメンバ端末に上記サービスコンポーネントを配信する第３ステップとを実行し、上記メンバ端末が、上記配信されたサービスコンポーネントを適用して、上記仮想グループにおけるデータ処理および通信を実行するようにしたことを特徴とする。

本発明によれば、グループの状態変化に応じてメンバ端末のソフトウェア機能を動的に変更できるため、仮想グループを再生成することなく、状況変化に柔軟に対応した形でグループ活動を継続できる。また、グループの各メンバ端末は、グループ活動に適用すべきコンポーネントモジュールが必要時に他の装置から提供されるため、使用可能性のある多数のコンポーネントモジュールを予め備える必要がない。従って、これらのソフトウェアを蓄積するための大容量のメモリが不要となり、ハードウェア規模を小型化できる。

以下、本発明の実施例について、図面を参照して説明する。
図１は、本発明によるサービスプロラムモジュールの動的配布を実現する計算機ネットワークの第１の実施例を示すシステム構成図である。

本実施例の計算機ネットワークは、通信ネットワーク１に接続されたワークステーション、パーソナルコンピュータ、ハンドヘルドコンピュータ、携帯端末などの複数の情報処理端末（以下、単に端末と言う）からなる。これらの端末のうちの幾つかが、ネットワーク空間でサービス目的に応じた仮想的なグループを構成する。本実施例では、仮想グループ内の１つの端末１０が、仮想グループの構成管理とサービスプロラムモジュールの動的配布に関するマネージャ（以下、マスタ端末と言う）となり、仮想グループのその他の端末２０（２０−１、２０−２、…）がメンバ端末となる。３０は通信ネットワーク１に接続された各種サーバのうちの１つを示す。但し、サーバ３０は、本発明による仮想グループ活動における必須の要件ではない。

図２は、マスタ端末１０の１実施例を示すブロック構成図である。
マスタ端末１０は、プロセッサ１１と、通信ネットワーク１に接続するための通信インタフェース１２と、表示装置１３と、入力装置１４と、プログラムメモリ１５と、データメモリ１６と、コンポーネントモジュールファイル１７および個人情報ファイル１８からなり、これらの要素はバス１９によって相互に接続されている。

プログラムメモリ１５には、仮想グループの構成を管理するグループ管理ルーチン１００Ａと、コンポーネントモジュールを仮想グループの状況変化に応じてグループメンバとなる各端末に配布するコンポーネント管理ルーチン２００と、表示装置１３にユーザインタフェース画面を提供するためのユーザインタフェース制御ルーチン３００と、仮想グループ活動となるデータ処理を実行するためのサービスアプリケーションプログラム４００と、仮想グループ活動に適用中のコンポーネントモジュール７００とが格納される。

データメモリ１６には、仮想グループの構成メンバに関する情報を記憶するためのグループ管理テーブル５０と、仮想グループ活動へのコンポーネントモジュールの適用条件を定義したサービスコンポーネント管理テーブル６０と、仮想グループ活動に適用中のコンポーネントモジュールの識別子を記憶する適用コンポーネントテーブル７０とが形成されている。

コンポーネントモジュールファイル１７には、仮想グループ活動に適用可能な複数種類のコンポーネントモジュールが格納してある。コンポーネント管理ルーチン２００は、これらの複数種類のコンポーネントモジュールの中から、仮想グループの状態変化に応じた適当なコンポーネントモジュールを動的に選択し、これをプログラムメモリ１５に適用コンポーネントモジュール７００としてロードすると共に、グループメンバとなる各端末に配布する。適用コンポーネントテーブル７０には、適用コンポーネントモジュール７００となったコンポーネントモジュールの識別子が登録される。

個人情報ファイル１８は、仮想グループの構成メンバとなり得る各ユーザの個人情報を記憶したファイルであり、例えば、端末２０−１〜２０−ｎのうちの何れかがグループ活動への参加を要求した時、要求元のユーザについて、個人情報ファイル１８を参照したユーザ認証が行われる。
以下、本発明の１実施例として、電子会議用プログラムをサービスアプリケーション４００とした仮想グループにおけるマスタ端末１０とメンバ端末２０の動作について説明する。

図３は、グループ管理テーブル５０の１実施例を示す。
グループ管理テーブル５０には、仮想グループ（この例では、電子会議）を識別するためのグループ識別子５１と、仮想グループの表示名称となるグループ名５２と、サービスアプリケーションを識別するためのサービス識別子５３と、仮想グループにおける通信データに適用される暗号化方式、暗号鍵などのセキュリティ情報５４とが記憶され、仮想グループの構成メンバと対応した複数のユーザエントリ５００（５００−１、５００−２、…）が登録されている。

各ユーザエントリ５００は、例えば、ユーザ識別子５０１と、ユーザ端末のＩＰアドレス５０２と、ユーザの氏名５０３と、ユーザの所属、職位などを示すユーザ属性情報５０４と、グループへの参加時刻５０５および離脱時刻５０６を示している。

図４は、サービスコンポーネント管理テーブル６０の１実施例を示す。
サービスコンポーネント管理テーブル６０は、コンポーネント適用条件を示す複数のエントリ６００（６００−１、６００−２、…）からなり、各エントリ６００は、コンポーネント適用条件６１と、適用コンポーネント識別子６２と、同期化の要否６３と、グループ状態変更イベント６４と、有効性フラグ６５とを示している。

ここで、コンポーネント適用条件６１は、適用コンポーネント識別子６２で特定されるコンポーネントモジュールの仮想グループへの適用条件を示す。また、同期化の要否６３は、識別子６２が示す新たなコンポーネントモジュールを運用する際に、仮想グループ内の全メンバ（端末）の同期化が必要か否かを示し、グループ状態変更イベント６４は、コンポーネント管理ルーチン２００によるコンポーネント適用条件６１の判定を必要とする仮想グループの状態変化（イベント発生）の種類を示している。

例えば、エントリ６００−１は、グループ状態変更イベント６４が示すように、仮想グループに新たなメンバが参加した時、または何れかのメンバが仮想グループから離脱した時、仮想グループがコンポーネント適用条件６１が示す「会社幹部で構成されるグループ」か否かを判定し、もし、コンポーネント適用条件が満たされた場合は、適用コンポーネント識別子６２が示す暗号化／復号化モジュールを適用することを意味している。コンポーネント適用条件が成立した場合、本実施例では、マスタ端末１０からメンバ端末２０に暗号化／復号化モジュールが配布され、各端末がデータパケットを暗号化してネットワークに送信し、これを受信側で復号化することになる。

エントリ６００−２は、仮想グループに新たなメンバが参加した時、または何れかのメンバが仮想グループから離脱した時、コンポーネント適用条件６１が示すように「グループメンバに社外者が含まれる」か否かを判定し、もし、コンポーネント適用条件が満たされた場合は、適用コンポーネント識別子６２が示す不正コピーの防止モジュールを適用することを意味している。この場合、マスタ端末１０からメンバ端末２０に不正コピー防止モジュールが配布され、電子会議において社外者端末に配布される機密資料は、この不正コピー防止モジュールによって複写を禁止した形式となるため、機密資料の社外への持ち出しを防止できる。また、エントリ６００−３は、例えば、会議の状況に応じてメンバの投票による議決が必要となった場合に、グループ状態変更イベント６４が示すユーザ（会議の進行役）からのコマンド入力によって、適用コンポーネント識別子６２が示す投票モジュールを配布することを意味している。

有効性フラグ６５は、各エントリが示すコンポーネントモジュールがグループ活動に既に適用中か否かを示している。例えば、既に社外者を含むグループ（この例では会議）に新たな社外者が加わった時、有効性フラグは既に“１”となっている。この場合、他のメンバに対しては既に不正コピー防止モジュールが配布済みとなっているため、不正コピー防止モジュールは新たな参加者に対してのみ配布される。この時、例えば、有効性フラグ６５が“１”のエントリが複数存在していた場合は、新たな参加者には、これらのエントリが示す複数のコンポーネントモジュールが配布されることになる。

図５は、適用コンポーネントテーブル７０の１実施例を示す。
適用コンポーネントテーブル７０には、適用コンポーネントモジュール７００となったコンポーネントモジュールの識別子７００−１、…が登録され、サービスアプリケーション４００は、適用コンポーネントテーブル７０に登録されたコンポーネントモジュールを利用して、仮想グループ活動となるデータ処理および通信を実行する。

図６は、マスタ端末１０の表示装置１３に出力される本発明に関係する表示画面の１例を示す。
８０は、グループ管理ルーチン１００Ａがユーザインタフェース制御ルーチン３００を介して表示画面に生成するグループ管理用のウインドウ、９０は、サービスアプリケーション４００が動作する電子会議用のウインドウを示す。ウインドウ８０は、例えば、コマンド入力用の複数のボタン８２、８３、…とデータ入力ボックス８４とを含むコマンドメニュー８１と、仮想グループ（電子会議）の参加メンバリストの表示領域８７とからなっている。

ここに示した例では、コマンドメニュー８１には、グループの生成を指令するためのボタン８２Ａ、グループの解散を指令するためのボタン８３Ｂ、会議（サービスアプリケーション４００）の開始を指令するためのボタン８３Ａ、会議の終了を指令するためのボタン８３Ｂ、投票モジュールの適用を指令するためのボタン８３Ｃ、その他が用意されている。データ入力ボックス８４は、グループ活動への参加を呼びかける広告メッセージに載せる案内情報の入力に利用される。参加メンバリストの表示領域８７には、グループ管理テーブル５０に登録されたユーザエントリ５００と対応するユーザ情報（例えば、氏名、所属／職位など）がスクロール可能に表示される。

図７は、メンバ端末２０の１実施例を示すブロック構成図である。
メンバ端末２０は、プロセッサ２１と、通信ネットワーク１に接続するための通信インタフェース２２と、表示装置２３と、入力装置２４と、プログラムメモリ２５と、データメモリ２６とからなり、これらの要素はバス２９によって相互に接続されている。

本実施例では、メンバ端末２０のプログラムメモリ２５には、メンバ端末用のグループ管理ルーチン１００Ｂと、表示装置２３にユーザインタフェース画面を提供するためのユーザインタフェース制御ルーチン３００と、仮想グループ活動となるデータ処理を実行するためのサービスアプリケーションプログラム４００と、仮想グループ活動に適用中のコンポーネントモジュール７００が格納される。また、データメモリ２６には、仮想グループ活動に適用中のコンポーネントモジュールの識別子を記憶する適用コンポーネントテーブル７０が形成される。

以下、図８〜図１１を参照して、マスタ端末１０とメンバ端末２０の動作について説明する。
図８は、コマンドメニュー８１でグループ生成ボタン８２Ａが選択された時、マスタ端末１０が実行を開始するグループ管理ルーチン１００Ａのフローチャートを示し、図９は、マスタ端末１０とメンバ端末２０との間で交信される制御メッセージのフォーマットを示す。

マスタ端末１０のユーザは、コマンドメニュー８１に用意されたデータ入力ボックス８４に会議への参加を呼びかける案内情報を入力した後、グループ生成ボタン８２Ａを選択して、マスタ端末１０に仮想グループの構成をスタートさせる。
マスタ端末のプロセッサ１１は、グループ管理ルーチン１００Ａを実行すると、先ず、グループ管理テーブル５０を初期化して、ユーザエントリ領域の不要データをクリアし（ステップ１０１）、周期タイマＴを起動する（１０２）。この後、仮想グループに参加を呼びかける会議広告メッセージＭ１をネットワーク１にブロードキャストし（１０３）、他の端末からの応答を待つ（１０４）。

会議広告メッセージＭ１は、図９の（Ａ）に示すように、パケットヘッダ４０をもつパケットのペイロード部４１に設定される。本実施例では、パケット形式としてＩＰパケットを採用し、パケットヘッダ４０の送信元アドレス４０１にマスタ端末１０のＩＰアドレス、宛先アドレス４０２にブロードキャスト用のアドレスを含むものとして説明するが、会議広告メッセージＭ１と後述するメッセージＭ２〜Ｍ６には、ＩＰパケット以外のパケット形式を適用してもよい。

会議広告メッセージＭ１は、メッセージ種類４１１に続いて、サービス識別子４１２、グループ識別子４１３、グループ名４１４、案内情報４１５用のフィールドを有し、メッセージ種類４１１には、このメッセージＭ１がグループ活動（会議）の広告用のものであることを示すコードが設定される。サービス識別子４１２、グループ識別子４１３、グループ名４１４には、それぞれグループ管理テーブル５０が示すサービス識別子５３、グループ識別子５１、グループ名５２が設定され、案内情報４１５には、ユーザがデータ入力ボックス８４で入力したテキスト情報が設定されている。

ネットワーク１に接続された他の端末は、上記会議広告メッセージＭ１を受信すると、表示画面に案内情報４１５を表示し、ユーザが会議への参加を希望した場合は、マスタ端末１０宛に、会議への参加要求メッセージＭ２を送信する。参加要求メッセージＭ２は、図９の（Ｂ）に示すように、このメッセージが参加要求であることを示すメッセージ種類４１１に続いて、サービス識別子４１２、グループ識別子４１３、グループ名４１４と、ユーザ識別子４１６、ユーザのパスワード４１７、その他の情報４２０用のフィールドを含む。

マスタ端末１０（グループ管理ルーチン１００Ａ）は、他の端末からメッセージを受信すると（１０４）、それが会議への参加要求メッセージＭ２か否かを判定し（１０５）、参加要求メッセージＭ２の場合は、ユーザ識別子４１６に基づいて個人情報ファイル１８を参照し、パスワード４１７によるユーザ認証処理を実行する（１０６）。尚、個人情報ファイル１８に登録エントリをもたない社外者については、例えば、会議場への入場の際に、社外者であることを示す個人コードと、使用すべきパスワードを与えておき、参加要求メッセージＭ２がこれらの個人コードとパスワードを含む場合は、個人情報ファイル１８に該当エントリがなくても、グループ管理ルーチン１００Ａが会議への参加を許諾するようにすればよい。

認証結果を判定し（１０７）、ユーザに会議への参加を許諾する場合は、許諾ユーザ用の新たなエントリ５００−ｉを生成し、これをグループ管理テーブル５０に登録する（１０８）。エントリ５００−ｉのＩＰアドレス５０２には、参加要求メッセージＭ２の送信元アドレスが適用され、ユーザ属性情報５０４の内容は、個人情報ファイル１８から得られる。氏名５０３は、個人情報ファイル１８から得られたものを使用してもよいし、参加要求メッセージＭ２にその他の情報４２０として設定されたものを使用してもよい。尚、グループ管理テーブル５０の内容は、会議参加メンバリスト８７として、マスタ端末の表示画面に出力される。

グループ管理ルーチン１００Ａは、グループ管理テーブル５０に新たなユーザエントリを登録すると、コンポーネント管理ルーチン２００に対して、ユーザ識別子４１６をもつ新たなユーザの参加を示すグループ状態変更イベントを発行し（１０９）、参加要求メッセージＭ２の送信元端末に対して、参加許諾を示す応答メッセージＭ３を送信する（１１０）。これによって、参加要求メッセージＭ２の送信元端末は、仮想グループ（会議）への参加資格をもつメンバ端末２０となる。

上記応答メッセージＭ３は、図９の（Ｃ）に示すように、このメッセージが参加要求応答であることを示すメッセージ種類４１１に続いて、サービス識別子４１２と、グループ識別子４１３と、参加の可否４１８と、認証トークンや暗号鍵（復号鍵）４１９を含んでいる。ユーザ認証の結果、参加を断ったユーザ端末に対しては、フィールド４１８に参加拒否コードを設定し、暗号鍵（復号鍵）４１９を省略した応答メッセージＭ３が送信される。

グループ管理ルーチン１００Ａでは、参加要求元へ応答メッセージＭ３を送信した後、コマンドメニュー８１からグループ解散の指令が入力されたか否かを判定し（１２５）、解散指令がなければ、周期タイマＴのタイムアップによる割り込みの有無を判定する（１２７）。タイマ割り込みがなければ、ステップ１０４に戻り、他の端末からのメッセージの受信を待つ。タイマ割り込みがあった場合は、ステップ１０３に戻り、会議広告メッセージを再度送信してから、他の端末からのメッセージの受信を待つ。このように、会議広告メッセージＭ１を周期的にブロードキャストすることによって、最初のメッセージに応答できなかったユーザ端末をグループ活動に参加させることができる。

マスタ端末１０（グループ管理ルーチン１００Ａ）は、他の端末からの受信メッセージが参加要求メッセージＭ２でなかった場合（１０５）、受信メッセージが会議からの離脱要求メッセージＭ４か否かを判定する（１２０）。受信メッセージが離脱要求メッセージＭ４でなければ、ステップ１２５でグループ解散の指令が入力されたか否かを判定する。

離脱要求メッセージＭ４は、図９の（Ｄ）に示すように、このメッセージが離脱要求メッセージであることを示すメッセージ種類４１１に続いて、サービス識別子４１２、グループ識別子４１３、ユーザ識別子４１６と、認証トークンや暗号鍵（復号鍵）４１９を含んでいる。

受信メッセージが離脱要求メッセージＭ４の場合、グループ管理ルーチン１００Ａは、コンポーネント管理ルーチン２００に対して、ユーザ識別子４１６をもつユーザの離脱を示すグループ状態変更イベントを発行し（１２１）、グループ管理テーブル５０の該当ユーザエントリに離脱時刻を記録する（１２２）。この後、離脱要求メッセージＭ４の送信元端末に対して、応答メッセージＭ５を送信し（１２３）、ステップ１２５でグループ解散の指令が入力されたか否かを判定する。

離脱要求に対する応答メッセージＭ５は、図９の（Ｅ）に示すように、このメッセージが離脱要求応答メッセージであることを示すメッセージ種類４１１に続いて、サービス識別子４１２、グループ識別子４１３、ユーザ識別子４１６を含んでいる。ステップ１２５でグループ解散の指令が入力されていた場合は、図９の（Ｆ）に示す会議終了（グループ解散）メッセージＭ６をネットワーク１にブロードキャストし（１２６）、このルーチンを終了する。

図１０は、コンポーネント管理ルーチン２００のフローチャートを示す。マスタ端末１０は、マンドメニュー８１でグループ生成ボタン８２Ａが選択された時、グループ管理ルーチン１００Ａと並行して、コンポーネント管理ルーチン２００の実行を開始する。

コンポーネント管理ルーチン２００では、グループ状態変更イベントを待ち受けており（ステップ２０１）、グループ管理ルーチン１００Ａからグループ状態変更イベントを受けると、それが新たなメンバの参加イベントか否かを判定する（２０２）。
参加イベントの場合、図４に示したサービスコンポーネント管理テーブル６０を参照し、新たなユーザの参加によって、何れかのエントリでコンポーネント適用条件６１が成立するか否かをを判定する（２０３）。エントリ６００−ｉでコンポーネント適用条件６１が成立した場合は、そのエントリの有効性フラグ６５をチェックする（２０４）。
有効性フラグが“０”の場合は、エントリ６００−ｉの適用コンポーネント識別子６２が示すコンポーネントモジュールをコンポーネントモジュールファイル１７から読み出し、これをグループ管理テーブル５０に登録されている全メンバに配布する（２２２）。

次に、エントリ６００−ｉの同期化要否６３をチェックし（２２３）、同期化要となっていた場合は、グループ管理テーブル５０に登録された全メンバに、配布コンポーネントの同期化要求メッセージを送信し（２２４）、メンバ端末からの応答を待つ（２２５）。
上記同期化要求に対して全メンバ端末から応答があった時、メンバ端末に上記配布コンポーネントの実行開始要求を送信し（２２６）、エントリ６００−ｉの有効性フラグ６５を“１”に設定する（２２７）。この後、上記コンポーネントモジュールを適用コンポーネントモジュール７００としてメモリ１５に格納し、コンポーネント識別子６２を適用コンポーネントテーブル７０に登録して（２２８）、ステップ２０１に戻る。エントリ６００−ｉで同期化不要となっていた場合は、同期化要求を送信することなく、直ちに配布コンポーネントの実行開始要求を送信する（２２６）。

ステップ２０４で、エントリ６００−ｉの有効性フラグが“１”となっていた場合は、新たに参加したメンバ（追加メンバ）に、適用コンポーネント識別子６２が示すコンポーネントモジュールを配布（２０５）した後、配布コンポーネントの実行開始要求を送信する（２０６）。次に、サービスコンポーネント管理テーブル６０で、エントリ６００−ｉ以外に有効性フラグが“１”のエントリ（コンポーネント）が在るか否かをチェックし（２０７）、有効性フラグが“１”のエントリが他になければ、ステップ２０１に戻る。

有効性フラグが“１”の他のエントリがあった場合は、追加メンバに、該エントリの適用コンポーネント識別子６２が示すコンポーネントモジュールを配布（２０８）し、配布コンポーネントの実行開始要求を送信（２０９）して、ステップ２０７に戻る。このように、有効性フラグ６５を参照することによって、新たな参加メンバに対して、他のメンバに既に配布済みのコンポーネントモジュールを配布することができ、全メンバの端末機能を対等にすることができる。

ステップ２０２で、グループ状態変更イベントが新メンバの参加イベントでなかった場合は、それがメンバ離脱イベントか否かを判定する（２１０）。グループ状態変更イベントがメンバ離脱イベントの場合は、このメンバの離脱によって、何れかのコンポーネント適用条件６１が解消されるか否かを判定する（２１１）。この判定は、例えば、離脱メンバが社外者（または会社幹部）であった場合、グループ管理テーブル５０の登録メンバとして、他に社外者（または会社幹部）が残っているか否かをチェックすることによって達成できる。コンポーネント適用条件６１の解消がない場合は、ステップ２０１に戻って次のイベント発生を待つ。

メンバの離脱によって何れかのコンポーネント適用条件６１が解消される場合は、全メンバに対して、コンポーネント適用条件６１の解消によって不要となったコンポーネントモジュールの識別子６２を指定して、コンポーネントモジュールの無効化要求を送信し（２１２）、該当エントリの有効性フラグ６５を“０”に変更（２１３）した後、適用コンポーネントテーブル７０から上記無効コンポーネントの識別子を削除して（２１４）、ステップ２０１に戻って次のイベント発生を待つ。

ステップ２１０で、グループ状態変更イベントがメンバ離脱イベントでなかった場合（例えば、コマンドメニュー８０から指定された投票イベントの場合）、サービスコンポーネント管理テーブル６０を参照し、該グループ状態変更イベントによって何れかのコンポーネント適用条件６１が成立するか否かを判定する（２２０）。コンポーネント適用条件６１が成立しなければ、ステップ２０１に戻って次のイベント発生を待つ。上記グループ状態変更イベントによって何れかのコンポーネント適用条件６１が成立した場合は、該当エントリの有効性フラグ６５をチェックし（２２１）、有効性フラグが“０”の場合は、ステップ２２２〜２２８を実行し、有効性フラグが“１”の場合は、このイベントを無視して、ステップ２０１に戻る。

上述したように、サービスコンポーネント管理テーブル６０に予め複数のコンポーネント適用条件６１を定義しておき、グループ状態変更イベントが発生した時、コンポーネント管理ルーチン２００によって、何れかのコンポーネント適用条件が成立したか否かを判定し、コンポーネント適用条件が成立した場合に、コンポーネント適用条件と対応するコンポーネントモジュールをメンバ端末に動的に配布することによって、各ユーザ端末にグループ状態変化に応じたデータ処理機能を与えることが可能となる。

図１１は、メンバ端末２０のプロセッサ２１が実行するグループ管理ルーチン１００Ｂのフローチャートを示す。
グループ管理ルーチン１００Ｂでは、ホスト端末１０からの制御メッセージの受信を待ち受けており（１３０）、制御メッセージを受信すると、それが会議広告メッセージＭ１か否かを判定する（１３１）。会議広告メッセージＭ１を受信した場合は、そのメッセージが示す会議が、既に不参加確認済みの会議か否かをチェックし（１３２）、不参加確認済みのものであれば、ステップ１３０に戻る。

会議広告メッセージＭ１が、初めて受信する案内情報を含んだ未確認のメッセージの場合、メッセージ表示ウインドウを表示装置２３に出力し（１３３）、ユーザからの反応を待つ。メッセージ表示ウインドウには、メッセージ内容（この場合は案内情報）の表示領域の他に、例えば、ユーザが会議への参加／不参加を回答するためのコマンド入力ボタンと、会議の途中で離脱するためのコマンド入力ボタンとが用意されている。

上記メッセージ表示ウインドウで、ユーザが会議への参加を示す応答をした場合（１３４）、プロセッサ２１は、メッセージＭ１の送信元であるマスタ端末１０に対して、図９の（Ｂ）に示した参加要求メッセージＭ２を送信し（１３５）、マスタ端末１０からの応答メッセージＭ３を待つ（１３６）。ステップ１３４で、ユーザが会議への不参加を示す応答をした場合、マスタ端末１０からその後に受信する同一の会議広告メッセージを無視するために、会議広告メッセージＭ１が示すサービス識別子４１２とグループ識別子４１３を不参加確認識別子として記憶して（１４０）、ステップ１３０に戻る。ステップ１３２では、受信した会議広告メッセージＭ１が示すサービス識別子４１２とグループ識別子４１３が、上記不参加確認識別子として記憶されたものか否かを判定している。

マスタ端末１０からの応答メッセージＭ３を受信すると、応答メッセージが示す参加可否４１８の内容をメッセージ表示ウインドウに表示する（１３７）。応答メッセージＭ３が会議への参加を許諾していた場合は、サービス識別子４１２と対応するアプリケーションプログラム、この例では、電子会議用のサービスアプリケーション４００の実行を開始し（１３９）、ステップ１３０に戻る。応答メッセージＭ３が会議への参加を拒否していた場合は、メッセージＭ３が示すサービス識別子４１２とグループ識別子４１３を不参加確認識別子として記憶して（１４０）、ステップ１３０に戻る。

ステップ１３１で、受信メッセージが会議広告メッセージＭ１でなかった場合、受信メッセージが、コンポーネントモジュールの配布メッセージか否かを判定する（１４１）。コンポーネントモジュールの配布メッセージの場合は、このメッセージから抽出した配布コンポーネントモジュールをプログラムメモリ２５の適用コンポーネントモジュール領域７００に格納し（１４２）、マスタ端末１０からの次のメッセージを待つ（１４３）。

マスタ端末１０から受信した次のメッセージが、同期化要求メッセージの場合（１４４）、マスタ端末１０に応答メッセージを送信し（１４５）、ステップ１４３で更に次のメッセージを待つ。マスタ端末１０からコンポーネント識別子を含む配布コンポーネント実行開始要求メッセージを受信した場合、上記コンポーネント識別子を適用コンポーネントテーブル７０Ｂに記憶して（１４６）、ステップ１３０に戻る。

ステップ１４１で、受信メッセージがコンポーネントモジュールの配布メッセージでなかった場合、受信メッセージが、コンポーネント無効化要求メッセージか否かを判定する（１５０）。コンポーネント無効化要求メッセージの場合は、このメッセージが指定するコンポーネント識別子を適用コンポーネントテーブル７０Ｂから削除して（１５１）、ステップ１３０に戻る。ステップ１５０で、受信メッセージが、コンポーネント無効化要求メッセージでなかった場合は、受信メッセージが会議終了メッセージか否かを判定する（１５２）。

受信メッセージが会議終了メッセージでなければ、ステップ１３０に戻り、会議終了メッセージであれば、メッセージ表示ウインドウに会議終了を表示し（１５３）、サービスアプリケーション４００の実行を終了して（１５４）、ステップ１３０に戻る。尚、ホスト端末１０から会議終了メッセージを受信する前に、メンバ端末のユーザが、会議からの離脱を示すコマンドを入力した場合は、プロセッサ２１は、マスタ端末１０に対して、図９の（Ｄ）に示した離脱要求メッセージを送信し、マスタ端末１０からの応答を待って、サービスアプリケーション４００の実行を終了すればよい。

上述した第１の実施例では、電子会議の参加メンバリストをマスタ端末側にのみ表示しているが、マスタ端末１０から各メンバ端末２０にグループ管理テーブル５０の内容を配布し、新たなメンバの参加の都度、各メンバ端末２０に新規参加者を示すテーブルエントリを配布することによって、各メンバ端末側でも電子会議の参加メンバリストを表示できる。また、第１の実施例では、マスタ端末１０が個人情報ファイル１８を備えているが、マスタ端末１０のハードウエア規模を小型化するために、個人情報ファイルを他の装置、例えば、図１に示したサーバ３０に保持しておき、マスタ端末が必要に応じてサーバ３０に新規参加者の個人情報の問合せ、または個人認証依頼をするようにしてもよい。同様に、コンポーネントモジュールファイル１７も、サーバ３０のような他の装置に蓄積しておき、マスタ端末１０が、必要に応じて上記サーバから適用コンポーネントモジュールを取得するようにしてもよい。

図１２は、本発明によるサービスプログラムモジュールの動的配布を実現する計算機ネットワークの第２の実施例を示す。
第２の実施例のネットワーク１には、それぞれがコンポーネント管理機能を備えた複数のマスタ端末１０（１０−１、１０−２、…）と、コンポーネント管理機能を持たない端末２０（２０−１、２０−２、…）とが接続されている。各マスタ端末１０は、コンポーネントモジュールファイル１７を備え、それぞれ複数種類のコンポーネントモジュールを保持している。この場合、コンポーネントモジュールは、マスタ端末毎に異なっていてもよいし、一部または全部が他のマスタ端末のコンポーネントモジュールと同一であってもよい。

本実施例のように、ネットワーク上に複数のマスタ端末が存在した場合、１つのマスタ端末が主催（広告）した会議（仮想グループ）に、通常のメンバ端末以外に、少なくとも１つの他のマスタ端末を参加させることができる。この場合、会議を主催したマスタ端末が、その会議に参加した他のマスタ端末が保持するコンポーネントモジュールを利用することが可能となる。また、複数のマスタ端末を互いに連係して動作させ、各マスタ端末が保持するコンポーネントモジュールを選択的にグループ活動に適用することによって、更に高度化されたグループ活動を実現できる。

図１３は、本発明によるサービスプログラムモジュールの動的配布を実現する計算機ネットワークの第３の実施例を示す。
第３の実施例では、無線通信機能を備えたマスタ端末１０と、それぞれが無線通信機能を備えた複数のメンバ端末２０（２０−１、２０−２、…）をアドホックネットワークで接続し、１つの仮想グループを形成している。

アドホックネットワークでは、例えば、マスタ端末１０から送信された会議広告メッセージＭ１が、これを受信した端末２０−１によって次の端末２０−２に中継され、端末２０−２から端末２０−３と２０−４に、端末２０−３から端末２０−５と２０−６に、端末２０−４から端末２０−５に、次々と転送される。逆に、各端末が会議広告メッセージＭ１に応答して送信する参加要求メッセージＭ２は、隣接する端末を次々と経由して、マスタ端末１０に到達する。第１実施例で説明したコンポーネントモジュールの配布と、各種の制御メッセージおよびサービスアプリケーション４００による電子会議用のメッセージは、このようなアドホックネットワーク上に形成された仮想グループにも適用できる。

以上、グループ活動の１例として電子会議を行うシステム構成について説明したが、本発明による情報処理端末とグループ機能制御方法は、サービスアプリケーション４００とコンポーネントモジュールファイル１７の内容を変更することによって、電子会議以外の他のグループ活動にも適用できること明らかである。

例えば、カメラや集音マイクを備えた複数の監視端末と、情報中継用の端末と、モニタ端末をアドホックネットワークで接続して１つの仮想グループを形成し、災害現場や事故現場での監視／連絡用のシステムを構築した場合、各監視端末に要求される機能は、現場の状況によって異なったものとなる。この場合、全ての現場で想定される全ての機能を実現できるように、各監視端末に多種類のソフトウェアモジュールを装備しておくと、ハードウェア規模が大型化し、端末操作が複雑化すると言う問題がある。

このような監視用のシステムに本発明を適用すれば、例えば、災害現場が地下で監視端末の視野が暗い場合、現場からモニタ端末に送信される撮像画面を明るくするための画像補正用のコンポーネントモジュールを監視端末に適用し、監視現場の騒音が大きい場合は、ノイズフィルタ機能をもつコンポーネントモジュールを適用し、監視端末と中継端末との位置関係で通信帯域が狭い場合は、送信データの圧縮機能をもつコンポーネントモジュールを適用する等、グループの状態に応じたソフトウェア機能の割当てが可能となる。
この場合、モニタ端末（マスタ端末）には、画像や雑音を分析して、コンポーネント管理ルーチンに状態変更イベントを発生するための状態検出手段を用意してもよいし、モニタ画面を観察するオペレータ入力に従って、コンポーネント適用条件を判定するようにしてもよい。

また、本発明は、特殊な応用例として、例えば、自動車に搭載された料金決済用のＥＴＣ（Electronic Toll Collection System）端末と、大型店舗の駐車場のゲート位置に設置された情報処理装置とで形成される駐車料金自動支払いシステム用の仮想グループに、ユーザ（自動車のドライバおよび乗客）が所有する電子マネーカード（または電子マネー機能を備えた携帯端末）を参加できるようにし、ＥＴＣによる料金支払機能を電子マネー端末の蓄積情報に応じて制御するシステム構成にも適用できる。

この場合、例えば、自動車が駐車場に入る時、ユーザが電子マネーカードを所持していた場合は、電子マネーカードを駐車時間管理用の情報処理装置に一時的に接続する。これにより、情報処理装置が、電子マネーカードが仮想グループに参加したことを検知し、電子マネーカード（またはＥＴＣ）に駐車料金清算用のコンポーネントモジュールを配布する。ユーザが店舗内で買い物をした際に、店舗側のレジスタ端末から上記電子マネーカードに商品の購入金額に応じたサービスポイントを発行し、車両が駐車場を出る時、上記コンポーネントモジュールに、電子マネーカードに蓄積されたサービスポイントを駐車時間管理用の情報処理装置に通知させる。

これによって、上記情報処理装置からＥＴＣ端末に、サービスポイントに応じた駐車時間の料金を無料化して、駐車料金を請求させることができる。尚、ユーザが電子マネーカードを所持していなければ、上記コンポーネントモジュールの配布はなく、従来方法による駐車料金の管理が実行されることになる。また、電子マネーカードを駐車時間管理用の情報処理装置に接続する代わりに、電子マネーカードをＥＴＣ端末に結合しておき、ＥＴＣ端末経由で、電子マネーカードの有無を情報処理装置に通知し、電子マネーカードへのコンポーネントモジュールをローディングをＥＴＣ端末経由で行うようにしてもよい。

以上の説明では、仮想グループの状態変化に応じて、メンバ端末に適用コンポーネントモジュールを配信したが、コンポーネントモジュールの機能をパラメータ設定によって変更可能な場合は、新たなコンポーネントモジュールを配信する代わりにパラメータを送信し、既にメンバ端末が所持しているコンポーネントモジュールを機能的に変更するようにしてもよい。

本発明によるサービスプログラムモジュールの動的配布を実現する計算機ネットワークの第１の実施例を示すシステム構成図。 図１におけるマスタ端末１０の１実施例を示すブロック構成図。 マスタ端末１０が備えるグループ管理テーブル５０の１例を示す図。 マスタ端末１０が備えるサービスコンポーネント管理テーブル６０の１例を示す図。 マスタ端末１０が備える適用コンポーネントテーブル７０の１例を示す図。 マスタ端末１０に出力される本発明に関係する表示画面の１例を示す図。 図１におけるメンバ端末２０の１実施例を示すブロック構成図。 マスタ端末１０が実行するグループ管理ルーチン１００Ａの１実施例を示すフローチャート。 マスタ端末１０とメンバ端末２０との間で交信される制御メッセージのフォーマットの１実施例を示す図。 マスタ端末１０が実行するコンポーネント管理ルーチン２００の１実施例を示すフローチャート。 メンバ端末２０が実行するグループ管理ルーチン１００Ｂの１実施例を示すフローチャート。 本発明によるサービスプログラムモジュールの動的配布を実現する計算機ネットワークの第２の実施例を示すシステム構成図。 本発明によるサービスプログラムモジュールの動的配布を実現する計算機ネットワークの第３の実施例を示すシステム構成図。

符号の説明

１：通信ネットワーク、１０：マスタ端末、１１：プロセッサ、１２：通信インタフェース、１３：表示装置、１４：入力装置、１５：プログラムメモリ、１６：データメモリ、１７：コンポーネントモジュールファイル、１８：個人情報ファイル、２０：メンバ端末、３０：サーバ、５０：グループ管理テーブル、６０：サービスコンポーネント管理テーブル、７０：適用コンポーネントテーブル、１００：グループ管理ルーチン、
２００：コンポーネント管理ルーチン、３００：ユーザインタフェース制御ルーチン、
４００：サービスアプリケーション、７００：適用コンポーネントモジュール。

Claims (9)

1. 通信網を介して接続された複数の端末装置をメンバ端末として仮想的なグループを形成し、上記メンバ端末と情報を交信する情報処理端末であって、
   グループ活動に適用可能な複数種類のコンポーネントモジュールについて、各コンポーネントモジュールの適用条件を定義したコンポーネント管理テーブルと、
   グループの状態が変化した時、上記コンポーネント管理テーブルに定義された適用条件をチェックし、適用条件が成立したコンポーネントモジュールを少なくとも１つのメンバ端末に配信するコンポーネント管理ルーチンとを有することを特徴とする情報処理端末。
2. 前記グループ活動に適用可能な複数種類のコンポーネントモジュールを蓄積したファイル装置を備え、前記コンポーネント管理ルーチンが、前記適用条件が成立したコンポーネントモジュールを上記ファイル装置から読み出して、前記メンバ端末に配信することを特徴とする請求項１に記載の情報処理端末。
3. 前記コンポーネント管理ルーチンが、前記適用条件が成立したコンポーネントモジュールを前記通信網に接続された他の装置から取得して、前記メンバ端末に配信することを特徴とする請求項１に記載の情報処理端末。
4. グループのメンバとなる端末装置のアドレス情報と端末装置のユーザ情報とを記憶するグループ管理テーブルと、
   グループへのメンバの参加または離脱の都度、上記グループ管理テーブルを更新し、上記メンバの参加または離脱を前記コンポーネント管理ルーチンにグループの状態変化として通知するグループ管理ルーチンとを有することを特徴とする請求項１に記載の情報処理端末。
5. 前記コンポーネント管理ルーチンが、前記適用条件が成立したコンポーネントモジュールをグループのメンバとなる全端末装置に配信すると共に、該コンポーネントモジュールを自端末でも実行可能とすることを特徴とする請求項１または請求項４に記載の情報処理端末。
6. 前記コンポーネント管理テーブルが、各コンポーネントモジュールの適用条件と対応して、該コンポーネントモジュールの実行に際してグループ内での同期の要否を示す情報を含み、
   前記コンポーネント管理ルーチンが、前記配信コンポーネントモジュールが同期を要するコンポーネントモジュールの場合、コンポーネントモジュールの配信先となった端末装置が上記コンポーネントモジュールを受信したことを確認して、該コンポーネントモジュールの実行開始を指示することを特徴とする請求項５に記載の情報処理端末。
7. 通信網を介して接続された他の複数の端末装置をメンバ端末として仮想的なグループを形成し、上記メンバ端末と情報を交信する情報処理端末によるグループ機能制御方法であって、
   グループの状態変化を検出する第１ステップと、
   グループの状態変化が検出された時、該状態変化が予め定義されたサービスコンポーネントの適用条件に該当するか否かをチェックする第２ステップと、
   グループの状態変化がサービスコンポーネントの適用条件に該当した場合、少なくとも１つのメンバ端末に上記サービスコンポーネントを配信する第３ステップとからなり、
   上記メンバ端末が、上記配信されたサービスコンポーネントを適用して、上記仮想グループにおけるデータ処理と通信を実行するようにしたことを特徴とするグループ機能制御方法。
8. 前記第３ステップで、前記適用条件が成立したサービスコンポーネントをグループメンバとなる全端末装置に配信すると共に、該サービスコンポーネントを前記情報処理端末でも実行可能とすることを特徴とする請求項７に記載のグループ機能制御方法。
9. 前記サービスコンポーネントが同期を要するコンポーネントの場合、前記第３ステップで、配信先メンバ端末が上記サービスコンポーネントを受信したことを確認した後、該コンポーネントの実行開始を指示するステップを含むことを特徴とする請求項８に記載のグループ機能制御方法。

Images