(57)【要約】  【課題】  人や物品の動態に基づいて、自動的に談話への参加が通知され、談話が形成される。  【解決手段】  ＩＤ検出・配送サービス１００、１１０にはセンサ１０１、１０２、１１１が接続され、個人用移動端末２００、２１０にはタグ２０１、２１１が接続される。センサ１０１、１０２、１１１はタグ２０１、２１１の識別子を読み取ることができ、一定範囲のエリア内のタグ２０１、２１１の存在を検出できる。  談話形成イベント配送サービス１０は、センサの検出イベントに基づいて参加メンバの招集やメンバの維持処理を行なう。談話形成イベント管理サービス２０は、イベントに基づいて行なう処理の設定を管理する。ユーザが移動したり、物品が搬送されたりして、そのタグがセンサに認識され、談話形成支援が行なわれる。【選択図】  図１
2005182596.tif 000002
【特許請求の範囲】
【請求項１】
対象物の動態を検知する動態検知手段と、
コミュニティごとに参加メンバの情報および談話形成条件の情報を記憶する記憶手段と、
上記動態検知手段の検知結果と上記コミュニティごとの談話形成条件に基づいて談話形成対象のコミュニティを特定し、上記談話形成対象のコミュニティの上記参加メンバに関する情報に基づいて決定されたメンバ宛に談話形成通知を送信する通知手段とを有することを特徴とする談話形成支援装置。
【請求項２】
上記対象物は人または物品である請求項１記載の談話形成支援装置。
【請求項３】
上記記憶手段は、上記コミュニティごとにさらにメンバを新たに参集させる参入条件およびメンバを離脱させる離脱条件の少なくとも一方を記憶し、上記参入条件および離脱条件の少なくとも一方に基づいてメンバの付加および削除を行なう請求項１または２記載の談話形成支援装置。
【請求項４】
上記メンバの付加および削除は、コミュニティの談話形成後の所定のライフタイムに行なわれる請求項３記載の談話形成支援装置。
【請求項５】
上記メンバの付加および削除は、上記談話形成通知が行なわれたのちの所定のライフタイムに行なわれる請求項４記載の談話形成支援装置。
【請求項６】
上記談話形成条件はルールベースで既述される請求項１、２、３、４または５記載の談話形成支援装置。
【請求項７】
上記記憶手段はユーザごとに談話形成通知を受領する条件を記憶し、この条件に従って上記談話形成通知が行なわれる請求項６記載の談話形成支援装置。
【請求項８】
上記記憶手段は、ユーザ毎にコミュニティのメンバに付加されることを許容する条件を記憶し、この条件に従って上記メンバの付加が行なわれる請求項６または７記載の談話形成支援装置。
【請求項９】
上記記憶手段は、ユーザ毎にコミュニティのメンバから外されることを許容する条件を記憶し、この条件に従って上記メンバの削除が行なわれる請求項６、７または８記載の談話形成支援装置。
【請求項１０】
動態検知手段により対象物の動態を検知するステップと、
記憶手段によりコミュニティごとに参加メンバの情報および談話形成条件の情報を記憶するステップと、
上記動態検知手段の検知結果と上記コミュニティごとの談話形成条件に基づいて談話形成対象のコミュニティを特定し、上記談話形成対象のコミュニティの上記参加メンバに関する情報に基づいて決定されたメンバ宛に通知手段により談話形成通知を送信するステップとを有することを特徴とする談話形成支援方法。
【請求項１１】
動態検知手段により対象物の動態を検知するステップと、
記憶手段によりコミュニティごとに参加メンバの情報および談話形成条件の情報を記憶するステップと、
上記動態検知手段の検知結果と上記コミュニティごとの談話形成条件に基づいて談話形成対象のコミュニティを特定し、上記談話形成対象のコミュニティの上記参加メンバに関する情報に基づいて決定されたメンバ宛に通知手段により談話形成通知を送信するステップとをコンピュータに実行させるために用いられることを特徴とする談話形成支援用コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、任意の契機に基づいて複数の人を参集させて談話を形成する談話形成支援技術に技術に関する。
【背景技術】
【０００２】
企業組織において、コミュニティと呼ばれるインフォーマルな人脈ネットワークの重要性が指摘されている。インフォーマルな対話やそれにもとづくコミュニティの形成はしばしば組織の活動の円滑化や新しい発想（知識創造）の契機をもたらす。そうしたインフォーマルな対話は個人席周辺や喫煙室や食堂や廊下などの物理的境界条件と、たまたまその場所で顔を合わせたという偶発的条件に依存して成立する。上記の条件の充足は難しいため、インフォーマルな対話の場が実体化される機会は容易に制御できるものではない。さらに、個人席の周辺と喫煙室とでは、インフォーマルな対話の成立・維持・解消を制御するソーシャル・キュー（プロトコル）が全く異なることが観察されており、そうした物理的境界条件に依存したソーシャル・キュー（プロトコル）を知らないとインフォーマルな対話のライフサイクル管理が不可能である。
【０００３】
なお、この発明と関連する先行技術としては、地理的基準により区分された複数のチャットルームに対して、ユーザの位置に基づいた適切なチャットルームを利用できるようにするものや（特許文献１）、地理的な座標にメッセージを残すことができるようにして、地理的境界に応じて情報へのアクセスを統制するもの（特許文献２）がある。これらには所定の契機に基づいて談話を形成することについては何ら開示がなく、またコミュニティを維持して管理することについても何ら開示がない。
【特許文献１】特開２００１−３２５１９９
【特許文献２】特開２００２−１９９４２３
【発明の開示】
【発明が解決しようとする課題】
【０００４】
この発明は、以上の事情を考慮してなされたものであり、上記のような対話の場の実体化ならびにライフサイクル管理を明示的に支援することにより、コミュニティにおけるインフォーマルな対話を促進し、さらに、そうした対話の活性化を通じて、新たなコミュニティ形成を促進することができるも談話形成支援技術を提供することを目的としている。
【課題を解決するための手段】
【０００５】
この発明によれば、上述の目的を達成するために、特許請求の範囲に記載のとおりの構成を採用している。
【０００６】
この発明の原理的な構成例では、ユーザや物品の動態を検知するセンサを備え、センサの検出結果の変化に基づいて自律的にコミュニティ形成サービスを起動する。ユーザは明示的にシステムにサービス起動の指示を行う必要が無い。ユーザや物品は一例であり、動態検知の対象物であればよく、例えば、動物等であってもよい。コミュニティは人間の集合である。
【０００７】
このコミュニティ形成サービスは、コミュニティの参加メンバへの談話参加を促す通知を出すのみならず、参加メンバを自動的に加えたり外したりすることができ、コミュニティのライフサイクル管理を包括的に行う能力を持つ。コミュニティで行なわれる談話は、実世界のものでもよいし、電子掲示板等を利用した仮想世界のものでもよい。基本的には、談話が行なわれる環境は有限な時間を有する。
【０００８】
このコミュニティ形成サービスは、その挙動をルールベースで規定することができ、コミュニティに応じた様々な挙動をプログラミングできる。
【０００９】
さらに、補足的な特徴として、このコミュニティ形成サービスは、ユーザ各自がシステムからの割り込みを各自のポリシーに則って制御できる機能を備え、ユーザ各自がコミュニティとの関わり方を自己決定できるようにしている。
【００１０】
さらに、この発明を説明する。ここでは、発明を詳細に説明するのに先だって、特許請求の範囲の記載について補充的に説明を行なっておく。
【００１１】
すなわち、この発明の一側面によれば、上述の目的を達成するために、談話形成支援装置に：対象物の動態を検知する動態検知手段と；コミュニティごとに参加メンバの情報および談話形成条件の情報を記憶する記憶手段と；上記動態検知手段の検知結果と上記コミュニティごとの談話形成条件に基づいて談話形成対象のコミュニティを特定し、上記談話形成対象のコミュニティの上記参加メンバに関する情報に基づいて決定されたメンバ宛に談話形成通知を送信する通知手段とを設けるようにしている。
【００１２】
メンバ宛の通知の送信は、典型的にはメンバの端末、好ましくは携帯している移動端末に行なう。もちろん、これに限らず、メンバ宛の通知に種々の手段を採用できる。要するに、なんらかの談話形成条件が成立したら、それをもとにメンバの行動を促すようにシステムから働きかけることができればよく、例えば、メンバの位置を検出していることを前提とすれば、メンバの位置で利用可能なデバイス(内線電話や共有ＰＣの画面表示など)に対して通知を行ったり、構内放送をかけたりしてもよい。当該メンバの近くにいることが予想される人や当該メンバに直ちに連絡が可能な人、例えば当該メンバの秘書や上司に対して通知を行なって、その人から間接的に通知内容を知得させるようにしても良いし、さらにその人から何らかの通知手段で目的の人に通知が行なわれるように依頼するものでもよい。
【００１３】
この構成においては、対象物、例えば人や物品の動態に基づいて、自動的に談話への参加が通知され、談話が形成される状態となる。例えば、中心人物が頻繁に活動しだしたときに、これを判別し談話を自動的に形成する。
【００１４】
この構成において、上記記憶手段は、上記コミュニティごとにさらにメンバを新たに参集させる参入条件およびメンバを離脱させる離脱条件の少なくとも一方を記憶し、上記参入条件および離脱条件の少なくとも一方に基づいてメンバの付加および削除を行なうようにしてもよい。この場合、上記メンバの付加および削除は、コミュニティの談話形成後の所定のライフタイムに行なわれるようにしてもよい。上記メンバの付加および削除は、上記談話形成通知が行なわれたのちの所定のライフタイムに行なわれるようにしてもよい。
【００１５】
また、上記記憶手段はユーザごとに談話形成通知を受領する条件を記憶し、この条件に従って上記談話形成通知が行なわれるようにしてもよい。また、上記記憶手段は、ユーザ毎にコミュニティのメンバに付加されることを許容する条件を記憶し、この条件に従って上記メンバの付加が行なわれるようにしてもよい。さらに、上記記憶手段は、ユーザ毎にコミュニティのメンバから外されることを許容する条件を記憶し、この条件に従って上記メンバの削除が行なわれるようにしてもよい。
【００１６】
なお、この発明は装置またはシステムとして実現できるのみでなく、方法としても実現可能である。また、そのような発明の一部をソフトウェアとして構成することができることはもちろんである。またそのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品もこの発明の技術的な範囲に含まれることも当然である。
【００１７】
この発明の上述の側面および他の側面は特許請求の範囲に記載され以下実施例を用いて詳述される。
【発明の効果】
【００１８】
この発明によれば、対象物、例えば人や物品の動態に基づいて、自動的に談話への参加が通知され、談話が形成される状態となる。
【発明を実施するための最良の形態】
【００１９】
以下、この発明の実施例について説明する。
【００２０】
図１は実施例の談話形成支援装置の装置要素を示しており、図２はその装置要素の物理的な配置関係を示している。
【００２１】
図１において、談話形成支援装置は談話形成イベント配送サービス（談話形成イベント配送装置）１０、談話形成イベント管理サービス（談話形成イベント管理装置）２０、ＩＤ検出・配送サービス１００、１１０、個人用移動端末２００、２１０等がネットワーク３００に接続されている。ネットワーク３００は例えばＬＡＮであるが、これに限らず、どのようなネットワークでも用いることができる。談話形成イベント配送サービス１０および談話形成イベント管理サービス２０は図２の談話形成イベント配送・管理サーバ装置３１０に実装され、ＩＤ検出・配送サービス１００、１１０は図２のＩＤ検出・配送サーバ装置３２０、３３０に実装される。ＩＤ検出・配送サービス１００、１１０にはセンサ１０１、１０２、１１１が接続され、個人用移動端末２００、２１０にはタグ２０１、２１１が接続される。
【００２２】
センサ１０１、１０２、１１１はタグ２０１、２１１の識別子を読み取ることができ、一定範囲のエリア内のタグ２０１、２１１の存在を検出できる。このような技術は、微弱電波通信のＢｌｕｅｔｏｏｔｈ（商標）や無線ＬＡＮや赤外線やＲＦＩＤ（無線認識）に基づく様々なものが利用可能である。本実施例ではタグ２０１、２１１はユーザが常に携行する個人用移動端末２００、２１０に内蔵されているものとし、これによってユーザの位置情報が取得できる。さらに、センサ１０１、１０２、１１１はユーザのタグ２０１、２１１のみならず、物品に予め付加されているタグや物品の状態そのものを検出できるようにする。前者の検出を行うセンサは赤外線に基づいた技術を用い、後者の検出を行うセンサは、物品に付加されているタグの識別にはＲＦＩＤに基づいた技術を用い、物品の状態は物品に応じた専用の状態検出機構を付ける。
【００２３】
談話形成イベント配送サービス１０は、談話形成支援の中核の機能を集約したサービスであり、例えば、センサの検出イベントに基づいて参加メンバの招集やメンバの維持処理を行なう。その詳細については図６および図７等を参照して後に詳述する。談話形成イベント配送サービス１０は、記憶部１１の各種テーブル（図３、図４、図５参照）を利用してサービスを提供する。記憶部１１は、例えば、図２の談話形成イベント配送・管理サーバ装置３１０に実装されている。
【００２４】
談話形成イベント管理サービス２０は、イベントに基づいて行なう処理の設定を管理するものである。すなわち、参加メンバの招集やメンバの維持等のサービスを管理するためのユーザインタフェースはＷｅｂ経由で行なうものとし、談話形成イベント管理サービス２０がＷｅｂのインタフェースを提供する。ユーザは自席のＰＣや個人用移動端末２００、２１０（無線によりネットワーク３００に接続されているものとする）のＷｅｂブラウザを通して、様々な設定を行える。
【００２５】
この実施例の談話形成支援装置が用いられる環境は図２に示すようなものである。図２のレイアウト例では、屋内に個人用の居室（あるいは個人スペース）４００、共有エリア４１０、廊下４２０等が配されている。また所定のエリアにＩＤ検出・配送サーバ装置３２０、３３０、談話形成イベント配送・管理サーバ装置３１０が設けられている。
【００２６】
ユーザが移動したり、物品が搬送されたりして、そのタグがセンサに認識され、後述する談話形成支援が行なわれる。
【００２７】
図３〜図５は談話形成イベント配送サービス１０の管理するデータ構造である。これらデータ（テーブル）は先に述べたように例えば図２の談話形成イベント配送・管理サーバ装置３１０の記憶部１１（図１参照）に記憶管理されている。
【００２８】
図３はユーザ個人に対応したデータを保持するユーザ・テーブルの例を示しており、ユーザ・テーブルのレコードは、ユーザＩＤ、ユーザ名、キーワードリスト、タグＩＤ、通知先端末ＩＤ、談話参加ポリシーの各属性を含んでいる。
【００２９】
図４はコミュニティに対応したデータを保持するコミュニティ・サブスクリプション・テーブルを示しており、このコミュニティ・サブスクリプション・テーブルの各レコードは、コミュニティＩＤ、コミュニティ名、キーワードリスト、談話形成ルール、参加ユーザＩＤリスト（現在参加しているユーザ）の各属性を含んでいる。これらのデータはユーザがＷｅｂのインタフェースを通じて談話形成イベント管理サービスを利用して設定可能である。
【００３０】
図５はセンサの検出内容に関するデータを保持するセンサ・テーブルを示しており、このセンサ・テーブルは当該センサのエリアＩＤ、エリア名、検出タグＩＤリスト（現在検出しているタグ）の各属性を含んでいる。センサ・テーブルの内容は、ＩＤ検出・配送サービス１００、１１０からのセンサ情報に基づいて常に自動更新される。
【００３１】
図６は本実施例における参加メンバ招集処理を表すフローチャートである。この処理はセンサ情報の更新に伴って起動される。この処理では、各コミュニティの談話形成ルールを評価し、招集可能であるコミュニティについて、現状に照らして自身が排他されるべきであるかどうか判定し、排他されなければ、コミュニティのユーザの談話参加ポリシーに従って招集通知を出し、さらに、コミュニティの参加メンバ維持処理をスケジュールする。
【００３２】
図６の処理は、センサ情報の更新に伴ったイベント駆動で行なわれ、その処理内容は以下のとおりである。
【００３３】
［ステップＳ１１］：センサ情報の更新があるまで待機する。更新があればステップＳ１２へ進む。
［ステップＳ１２］：集合Ｓを空集合に初期化する。
［ステップＳ１３］：コミュニティＩＤ集合の各要素であるｉｄについて、ｉｄに対応するコミュニティの談話形成ルールの「招集可能性」を評価し、その評価結果が真であるｉｄを集合Ｓに追加する。
［ステップＳ１４］：集合Ｓが空集合かどうか判定する。空集合であればステップＳ１１に戻る。空集合でなければステップＳ１５へ進む。
［ステップＳ１５］：集合Ｓの要素である各ｉｄについて、ｉｄに対応するコミュニティの談話形成ルールの「排他判定」を評価し、それが真であるｉｄを集合Ｓから同時に削除する。
［ステップＳ１６］：集合Ｓの要素である各ｉｄについて、ｉｄに対応するコミュニティの参加ユーザの各々に対して、当該ユーザの談話室ポリシーの「招集受理」を評価し、その評価結果が真であるユーザに対して招集通知を発行する。
［ステップＳ１７］：集合Ｓの要素である各ｉｄについて、ｉｄに対応するコミュニティの談話形成ルールの「招集待ち時間」を評価し、その評価結果ｔミリ秒後に当該ｉｄに対応するコミュニティの参加メンバの維持処理を起動するようスケジュールする。
【００３４】
図７は上述した参加メンバ維持処理であり、ユーザの談話参加ポリシーに従ってコミュニティへの新たなユーザの参加および既存ユーザの離脱処理を自動的に行う。図７の処理は以下のとおりである。
【００３５】
［ステップＳ２１］：処理対象のコミュニティＩＤを取得し、当該ＩＤに対応するコミュニティの談話形成ルールの「参入メンバ」と「離脱メンバ」を評価し、各評価結果のユーザＩＤ集合を集合Ｓ１、Ｓ２に代入する。
［ステップＳ２２］：集合Ｓ１の各要素であるｉｄについて、ｉｄに対応するユーザの談話参加ポリシーの「参入受理」を評価し、その評価結果が真であるユーザＩＤを処理対象のコミュニティの参加ユーザＩＤリストに加える。
［ステップＳ２３］：集合Ｓ２の各要素であるｉｄについて、ｉｄに対応するユーザの談話参加ポリシーの「離脱受理」を評価し、その評価結果が真であるユーザＩＤを処理対象のコミュニティの参加ユーザＩＤリストから削除する。
【００３６】
談話形成ルールと談話参加ポリシーは、本実施例ではＰｙｔｈｏｎ言語（商標）のスクリプトで記述する。このスクリプトは複数のテンプレートが用意され、後述するＵ／Ｉを通してユーザがテンプレートを選択し、必要なパラメータを左記テンプレートに埋め込むことで記述される。もちろん、ユーザが自由に記述しても、外部から新たなテンプレートを導入しても構わない。
【００３７】
そのようにして生成された記述はＰｙｔｈｏｎ言語のクラスである。談話形成イベント配送サービス１０は起動時に各クラスのインスタンスを生成しておき、図６および図７の処理時に対応するインスタンスの所定のメソッドを呼び出すことでルールの評価を行う。
【００３８】
図８のリスト１は談話形成ルールの例である。このルールでは、ある特定ユーザが良く動き回り始めたら、そのコミュニティが招集可能となる（Ｐ０１）。また招集待ち時間は５分である（Ｐ０２）。また、上記ユーザのいるエリアに３人以上集まっている際に、その場に一緒にいる、コミュニティメンバでないユーザが自動的にコミュニティに加えられる（Ｐ０３）。コミュニティメンバの離脱に関しては離脱メンバなしとしている（Ｐ０４）。さらに、排他反対により、直近１０分以内にコミュニティＩＤが１０〜３２のものがある場合には招集を行なわないようにしている（Ｐ０５）。
【００３９】
なお、図６における評価対象と、ルールを記述するクラスの各メソッドの対応は図９の表１のとおりである。
【００４０】
図１０のリスト２はユーザ毎の談話参加ポリシーの例である。このルールでは、いかなる場合でも許可を行うことを意味する。
【００４１】
なお、図７における評価対象と、ルールを記述するクラスの各メソッドの対応は図１１の表２のとおりである。
【００４２】
リスト１およびリスト２は単純な例であるが、他にも例えば、新しい物品が誰かの席に来たことをもとに招集を行ったり、キーワードが十分に類似しているコミュニティに対する参入のみを受理したりなど、様々な挙動を柔軟にプログラミング可能であることは容易に理解できる。
【００４３】
図１２はコミュニティ設定フォームである。このフォームはコミュニティのトピックとキーワードと談話形成ルールと初期メンバ等を設定する。このＵ／Ｉからは、談話形成ルールはあらかじめ用意されているテンプレートを選択するようにしている。そのコミュニティのライフサイクルに見合った方式を選択すれば良い。もちろん談話形成ルールのスクリプトの全部または一部を既述するようにしても良い。
【００４４】
図１３は談話参加ポリシー設定フォームである。このフォームはキーワードと、招集、参入、離脱の各ポリシー等を設定する。このＵ／Ｉでは、談話参加ポリシーの設定方法が非常に定型的であるので、対応するスクリプトは固定的な手順により生成可能である。もちろん談話参加ポリシーのスクリプトの全部または一部を既述するようにしても良い。
【００４５】
図１４および図１５はそれぞれ、招集通知および新規参入確認のダイアログである。コミュニティ関連イベントは、ユーザの持ち歩いてるＰＤＡの画面上へのダイアログのポップアップとＰＤＡからの音声出力による、ユーザへの割込みの形で具体化される。
【００４６】
図１６および図１７は本発明の別の側面を表す実施例である。図１６においては、人の動態ではなく、機器の状況をトリガーにして招集をかけるルールを選択している。この例では「コーヒー友の会」に対し、特定のコーヒーサーバが満杯になったときに招集が発行され、図１７に示すような招集通知が行なわれる。
【００４７】
他にも、未知の物品がフロアに搬入されたときに人を集めたり、共有スペースのＴＶがオンになっていたときに人を集めたり、サーバルームの機器がダウンしたときに人を集めたりなども同様の構成で実現できる。
【００４８】
もちろん、人の動態や物品の動態や機器の状態を複合させて、より巧妙なソーシャル・キューを扱うことも可能である。
【００４９】
図１８は参加メンバ維持処理の変形例を示す。図１８において図７と対応する箇所には対応する符号を付した。
【００５０】
図１８においては、コミュニティのメンバが実際に集まっているであろう時刻に、「サブコミュニティ」が出来ていることが認められたら、新たなサブコミュニティを生成する処理を付け加える（Ｓ２４）。
【００５１】
対応するルールの例は図１９のリスト３である。ここではｄｅｔｅｃｔ＿ｓｕｂｃｏｍｍｕｎｉｔｙというメソッドを用いる。この例では、インフラストラクチャが最近ｎ回の招集毎のユーザの集まり具合を履歴管理する機能を備えていることを想定しており、特定ユーザが離れた位置に集まることが頻出したらそれをユーザクラスタと認識し、それをサブコミュニティとして扱う。
【００５２】
例えば、ユーザＡ，Ｂが同じ場所にいつも出現し、ユーザＣ，Ｄ，Ｅが左記場所とは異なる同じ場所にいつも出現していると、インフラストラクチャのｄｅｔｅｃｔ＿ｕｓｅｒ＿ｃｌｕｓｔｅｒメソッドは、［［ＩＤＡ，ＩＤＢ］，［ＩＤＣ，ＩＤＤ，ＩＤＥ］］というような結果を返す。図１８のステップＳ２４において、それ結果を受けて、コミュニティサブスクリプションテーブルに対し、上記リストの各要素、すなわち、それぞれユーザＩＤリストとして［ＩＤＡ，ＩＤＢ］および［ＩＤＣ，ＩＤＤ，ＩＤＥ］を持ち、その他のフィールドをもとのコミュニティからコピーした新たなコミュニティ定義を２つ生成し、テーブルに追加する。このようにして自動生成されたサブコミュニティの定義の微調整は必要に応じて後にユーザが手動で行える。
【図面の簡単な説明】
【００５３】
【図１】この発明の実施例の構成を説明する図である。
【図２】上述実施例の利用環境を説明する図である。
【図３】上述実施例で用いるユーザ・テーブルの例を説明する図である。
【図４】上述実施例で用いるコミュニティ・サブスクリプション・テーブルの例を説明する図である。
【図５】上述実施例で用いるセンサ・テーブルの例を説明する図である。
【図６】上述実施例の参加メンバ招集処理を説明するフローチャートである。
【図７】上述実施例の参加メンバ維持処理を説明するフローチャートである。
【図８】上述実施例の談話形成ルールを説明する図である。
【図９】上述談話形成ルールで用いられるメソッドの対応を説明する図である。
【図１０】上述実施例の談話参加ポリシーを説明する図である。
【図１１】上述談話参加ポリシーで用いられるメソッドの対応を説明する図である。
【図１２】上述実施例のコミュニティ設定フォームの例を説明する図である。
【図１３】上述実施例の談話参加ポリシー設定フォームの例を説明する図である。
【図１４】上述実施例の談話招集通知ダイアログの例を説明する図である。
【図１５】上述実施例のコミュニティ新規参入確認ダイアログの例を説明する図である。
【図１６】この発明の他の実施例におけるコミュニティ設定フォームの例を説明する図である。
【図１７】上述他の実施例の談話招集通知ダイアログの例を説明する図である。
【図１８】上述実施例の参加メンバ維持処理の変形例を説明するフローチャートである。
【図１９】図１８の処理で用いられる追加的なメソッドの例を説明する図である。
【符号の説明】
【００５４】
１０      談話形成イベント配送サービス
１１      記憶部
２０      談話形成イベント管理サービス
１００      ＩＤ検出・配送サービス
１０１、１０２、２０１      センサ
２００、２１０      個人用移動端末
２０１、２１１      タグ
３００      ネットワーク
３１０      談話形成イベント配送・管理サーバ装置
３２０、３３０      ＩＤ検出・配送サーバ装置
４００      居室
４１０      共有エリア
４２０      廊下
【図１】
2005182596.tif 000003
【図２】
2005182596.tif 000004
【図３】
2005182596.tif 000005
【図４】
2005182596.tif 000006
【図５】
2005182596.tif 000007
【図６】
2005182596.tif 000008
【図７】
2005182596.tif 000009
【図８】
2005182596.tif 000010
【図９】
2005182596.tif 000011
【図１０】
2005182596.tif 000012
【図１１】
2005182596.tif 000013
【図１２】
2005182596.tif 000014
【図１３】
2005182596.tif 000015
【図１４】
2005182596.tif 000016
【図１５】
2005182596.tif 000017
【図１６】
2005182596.tif 000018
【図１７】
2005182596.tif 000019
【図１８】
2005182596.tif 000020
【図１９】
2005182596.tif 000021