JP2002259251A - 意味情報ネットワークを用いたグループメンバ間情報配信方法とシステムおよび送信端末と受信端末 - Google Patents

Abstract

(57)【要約】 【課題】 仲介者を必要とせずに、グループメンバ間の
動的な相対距離を確認するとともに特定の条件に合致し
た相手のみに選択的に情報の送受信を行う。 【解決手段】 グループメンバである「正彦」が自己の
位置情報を含めて通知要求イベントを意味情報ネットワ
ーク１０に送信すると、該通知要求イベントを受信した
「正太郎」の移動端末３１では、自己の位置情報と通知
要求イベントに含まれる「正彦」の位置情報から圏外遠
近結果値を得る。移動端末３１は、その圏外遠近結果値
と自己の位置情報を通知要求イベント応答メッセージと
して「正彦」の移動端末３に送信する。「正彦」の移動
端末３３では、受信した通知要求イベント応答メッセー
ジに含まれる「正太郎」の位置情報から圏外遠近評価値
を得る。移動端末３１は圏外遠近結果値い基づいて、移
動端末３３は遠近評価値に基づいて相手の位置を表示す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク上に
分散するコンテンツの中からエンドユーザの興味に合致
するコンテンツを特定する、あるいは、コンテンツプロ
バイダがコンテンツを配布すべき最適なコンシューマを
特定する意味情報ネットワークを用いたグループメンバ
間情報配信方法および運営システムに関する。

【０００２】

【従来の技術】図３６は、従来のグループメンバ間情報
配信システムにより実現されるグループメンバ間情報配
信サービスの仕組みを示している。この従来のグループ
メンバ間情報配信システムでは、グループメンバ１〜５
の端末１０１〜１０５とグループ管理者（仲介者）のサ
ーバ２００とがインターネット５００等の通信網を介し
て接続されている。

【０００３】この従来のグループメンバ間情報配信サー
ビスは、予め登録された複数のグループメンバ間での情
報の配信を行うことにより実現される。仲介者の具体的
な例としては、ブローカ、ポータルサイト、ディレクト
リサーバ等が考えられる。

【０００４】ここで、グループとは、嗜好や趣味の共通
した仲間を指し、グループ内のメンバはお互いにグルー
プ内のメンバとして意識して認めている。グループの例
として、遊び友達、同好会、サークルなどが当てはま
る。

【０００５】ここで、グループ管理者は、ネットワーク
上にサービス実現のための資源を用意し、各グループメ
ンバの情報受信用アドレスを一覧表として管理し、グル
ープメンバからの情報を受信するための受付アドレスを
用意して当該一覧表に関連づけ、当該受付アドレスで受
信した情報を当該一覧表にある各グループメンバの情報
受信用アドレスに転送することにより、グループ内のあ
るメンバからグループ内の他メンバに情報が同報通信さ
れることを可能にする。

【０００６】この従来のグループメンバ間情報配信方法
を図３６を参照して説明する。図３６中の括弧内の番号
は、情報が伝送される順番または実行される処理の順番
を示すものである。

【０００７】（１）グループメンバ１〜５は、端末１０
１〜１０５のグループメンバ用アプリケーションを用い
て、情報受信用アドレスをグループ管理者のサーバ２０
０に送信する。グループ管理者のサーバ２００では、受
信した情報受信用アドレスを保管しておくとともに、受
付アドレスをグループメンバ１〜５の端末１０１〜１０
５にそれぞれ送信する。グループ管理者から受付アドレ
スの提供を受けた端末１０１〜１０５では、その受付ア
ドレスを保管しておく。

【０００８】（２）そして、あるグループメンバが、グ
ループ内の他のグループメンバに送信したい情報がある
場合、グル−プ管理者のサーバ２００から提供された受
付アドレスに対してその情報を送信する。図３６では、
グループメンバ１が、グループ管理者のサーバ２００に
情報を送信した場合を示している。

【０００９】（３）次に、グループメンバ１からの情報
を受信したグループ管理者のサーバ２００は、登録され
ているグループメンバ２〜５の情報受信用アドレスに対
して、グループメンバ１から受信した情報を転送する。

【００１０】上記で説明した方法により、従来のグルー
プメンバ間情報配信システムによれば、グループメンバ
１からグループメンバ２〜５への情報配信が実現され
る。しかし、この従来のグループメンバ間情報配信シス
テムでは、各グループメンバが他のグループメンバの一
部の者のみに情報を配信するような選択的な配信を行う
ことができない。また、特定の条件に合致するグループ
メンバにのみ情報を配信することもできない。

【００１１】図３６に示したような従来のグループメン
バ間情報配信システムでは、端末１０１〜１０５を携帯
電話機等の移動端末とすることにより、移動するグルー
プメンバ間での情報配信を行うこともできる。このよう
な移動端末を用いたグループメンバ間情報配信システム
では、各移動端末にＧＰＳ受信機等の位置情報取得手段
を設けて位置情報を取得し、その位置情報を仲介者であ
るグループ管理者のサーバに送信するようにすれば、各
グループメンバ間の位置関係を特定することができる。
しかし、このような場合でも、自分の現在の位置に近い
位置にいるグループメンバにのみ情報を送信する等の選
択的な配信を行うことはできない。また、このようなグ
ループメンバ間情報配信システムを実現する場合にも、
仲介者であるグループ管理者の存在が必要となる。

【００１２】

【発明が解決しようとする課題】上述した従来のグルー
プメンバ間情報配信システムでは、以下の問題点があ
る。 （１）各グループメンバ間の位置関係を特定することが
できるような、グループメンバ間情報配信システムを実
現しようとする場合、仲介者が必要となる。 （２）予め登録された複数のグループメンバ間での情報
の配信を行うとする場合、仲介者が介在することが必要
となることからリアルタイムな情報配信を行うことがで
きない。 （３）仲介者の存在が必要となることにより、仲介料が
発生する、または、仲介者による広告の付与等が発生す
る。 （４）仲介者の存在が必要となることにより、グループ
メンバ間情報配信サービスを利用するグループメンバの
増加に伴い仲介者の運営するサーバにおける負荷が集中
し、情報配信のリアルタイム性がさらに低下するととも
に高価な大型サーバ機が必要となることにもなる。 （５）グループメンバ間でやりとりされる情報が仲介者
によって一元管理され、仲介者によって利用されている
サーバに侵入が図られたときの危険分散が行われていな
い。また、仲介者の機密情報管理の信頼性が低い場合に
は、仲介者にプライバシ情報を開示すること自体に不安
が伴う。 （６）グループメンバは、やりとりする情報のフォーマ
ット等に関して、仲介者が規定するグループメンバ間情
報配信サービスの運営方針(ポリシ)に従わなければなら
ない。 （７）グループメンバのうちのある特定の者にのみ情報
を配信する等の、選択的な情報の送受信を行うことがで
きない。

【００１３】本発明は上述したような従来の技術が有す
る問題点に鑑みてなされたものであって、仲介者を必要
とせずに、グループメンバ間の動的な相対距離を確認す
るとともに特定の条件に合致した相手のみに選択的に情
報の送受信を行うことができるネットワークを用いたグ
ループメンバ間情報配信サービスの運営を可能とするこ
とにより上記の各問題点を解決し、特に、リアルタイム
な情報配信を可能とし、グループメンバのポリシによる
情報発信が可能となり、グループメンバの機密情報に関
する安全性を向上することができるグループメンバ間情
報配信方法および支援システムを実現することを目的と
する。

【００１４】

【課題を解決するための手段】上記目的を達成するため
に、本発明のグループメンバ間情報配信方法は、データ
をイベントとして送信する送信端末と、イベントとして
送信された前記データを選択的に受信するために、イベ
ントのタイプと取得条件とからなるフィルタが設定され
る受信端末とから構成される意味情報ネットワークを用
いて、予め登録された複数のグループメンバ間での情報
の配信を行う、意味情報ネットワークを用いたグループ
メンバ間情報配信方法であって、前記グループメンバの
移動端末が、通知情報を受け取るための受取条件をフィ
ルタとして前記意味情報ネットワークに設定するステッ
プと、前記グループメンバの移動端末が、他のグループ
メンバに通知したい通知情報の通知内容、自己の現在の
位置情報および返信先情報が含まれた通知要求イベント
を意味情報ネットワークに送信するステップと、通知情
報を受け取るための受取条件が設定されたグループメン
バの移動端末が、イベントとして送信された前記通知要
求を前記意味情報ネットワークから受信し、受信した通
知要求に含まれる他のグループメンバの移動端末の位置
情報と、自己の現在の位置情報とから他のグループメン
バとの距離を求め、予め設定されたエリア定義に基づい
て圏外遠近の評価を行い、その結果を圏外遠近結果値と
するステップと、前記通知要求イベントを受信したグル
ープメンバの移動端末が、前記圏外遠近結果値および自
己の位置情報を含んだ通知要求イベント応答メッセージ
を、受信した前記通知要求イベントに含まれる返信先情
報により特定した返信先に送信するステップと、前記通
知要求イベント応答メッセージを受信したグループメン
バの移動端末が、該通知要求イベント応答メッセージに
含まれる他のグループメンバの移動端末の位置情報と、
自己の現在の位置情報とから他のグループメンバとの距
離を求め、予め設定されたエリア定義に基づいて圏外遠
近の評価を行い、その結果を圏外遠近評価値とするステ
ップと、前記通知要求イベント応答メッセージを受信し
たグループメンバの移動端末が、前記圏外結果値および
前記圏外遠近評価値および他のグループメンバに通知し
たい情報である通知情報を含んだ折り返しメッセージ
を、受信した前記通知要求イベント応答メッセージに含
まれる返信先情報により特定した返信先に通知したい通
知情報を含めて送信するステップと、通知要求イベント
応答メッセージを受信したグループメンバの移動端末
が、該通知要求イベント応答メッセージに含まれた圏外
遠近結果値および得られた圏外遠近評価値がともに圏内
を示している場合に、前記通知要求イベント応答メッセ
ージを発信した他のグループメンバの位置を前記圏外遠
近評価値に基づいて表示するステップと、前記折り返し
メッセージを受信したグループメンバの移動端末が、受
信した該折り返しメッセージに含まれている圏外遠近結
果値および圏外遠近評価値がともに圏内を示している場
合に、前記折り返しメッセージを発信した他のグループ
メンバの位置を前記圏外遠近結果値に基づいて表示する
とともに該折り返しメッセージに含まれている通知情報
の表示を行うステップとを有する。

【００１５】本発明によれば、仲介者を必要とせずに、
グループメンバ間の動的な相対距離を確認するとともに
特定の条件に合致した相手のみに選択的に情報の送受信
を行うことができるネットワークを用いたグループメン
バ間情報配信サービスの運営が可能となるので、リアル
タイムな情報配信、グループメンバのポリシによる情報
発信も可能となり、また、グループメンバの機密情報に
関する安全性の向上を図ることができる。

【００１６】

【発明の実施の形態】本発明を説明する前に、本発明の
前提となる、発信する情報のメッセージ性を高めた分散
型ネットワークシステムについて説明する。

【００１７】分散型指向のネットワークシステムとして
は、ナップスターを用いるものが知られ、さらに、分散
性を高めたネットワークシステムとしては、Ｇｎｕｔｅ
ｌｌａを用いるものが知られている。

【００１８】まず、ナップスターを用いるネットワーク
システムについて説明する。ナップスター利用者は、各
ナップスター利用者が公開するファイルの情報を格納し
たナップスター社のサーバに検索要求を送信し、ナップ
スター社のサーバは検索したファイルを所有するナップ
スター利用者に関するＩＰアドレス等の情報を返信す
る。実際のファイルのやり取りはナップスター社のサー
バを介することなく、ＩＰアドレスを入手した利用者が
直接目的とするファイルを所有するナップスター利用者
にアクセスすることにより行われる。

【００１９】Ｇｎｕｔｅｌｌａを用いるネットワークシ
ステムの場合には、Ｇｎｕｔｅｌｌａ利用者の端末は、
接続している相手端末の状態を定期的に確認し、メッセ
ージやファイルの検索要求を中継し合うことが行われ
る。検索結果は検索要求を行った相手に戻され、その後
のファイル転送はナップスターと同様に利用者間で直接
行われる。これにより、サーバを用いることなくネット
ワークが構築されることとなる。

【００２０】これらの各ネットワークシステムのうち、
ナップスターを用いるものにおいては、本発明が問題点
とする仲介者に相当するサーバを必要とするため、本発
明の目的を達成するものではない。

【００２１】Ｇｎｕｔｅｌｌａを用いるネットワークシ
ステムにおいては、サーバを用いることなくメッセージ
やファイルの検索要求が行われるものの、発信する情報
が単なるファイルの検索要求であり、この応答を確認し
た利用者によるファイルの転送が利用者間で行われるも
のであるため、オークションや逆オークション等の１対
複数でのやり取りが必要となる形態にはそぐわない。

【００２２】発信する情報のメッセージ性を高めた分散
型ネットワークシステムとして以下に説明する意味情報
ネットワークシステムがあり、本発明は、このような意
味情報ネットワークシステムを用いることを前提とす
る。

【００２３】まず、意味情報ネットワーク（Semantic I
nformation-Oriented Network、以下、ＳＩＯＮと称す
る）について概要を説明する。ＳＩＯＮは、意味情報に
基づいて、イベントを目的地まで配送することが可能な
ネットワークである。図１に、ＳＩＯＮの概念モデルを
示す。図１において、各端末２は、意味情報（Semantic
Information：ＳＩ）をＳＩＯＮ１に対して登録する。
一方、イベントを送信する端末２は、図２に示す意味情
報（Semantic information）とデータ（Data）から構成
されるイベントをＳＩＯＮ１に送出する。ここでいう、
意味情報とは、イベントに含まれるデータの特性を記述
したものであり、データのメタ情報として位置づけられ
る。例えば、意味情報は、 ・データを“東京在住者”に配送する。 ・データを“クラシックに興味のある人”に配送する。 ・データを“１Ｍｂｐｓ以上の通信環境を有する人”に
配送する。 ・データを“目白通りを通行中の人”に配送する。 ・データを“キーワード（例えば旅行）に合致するコン
テンツを有するコンテンツプロバイダ”に配送する。 等の表現が用いられる。

【００２４】ＳＩＯＮは、上述したような意味情報に基
づいて、データを配送すべき対象（端末、人、ソフトウ
エアなど）を動的に決定し、特定された対象者に対し
て、データの配送および通知を行うことが可能な自律分
散型のメタネットワークである。このＳＩＯＮを用いる
ことにより、ブローカを介することなく、情報提供者が
提供するに相応しいユーザに対してのみ、自身の情報を
直接提案することが可能になる。このような、ブローカ
非介在型（非ブローカモデル）でpeer-to-peerの情報提
案が可能なビジネスモデルを、ここでは、御用聞きモデ
ル（または、御用聞き型情報提案モデル、非ブローカモ
デル）と呼ぶ。同様に、検索サービス（ブローカ）を介
することなく、ユーザが希望する情報を直接探索可能
な、リアルタイム情報検索も可能である。なお、御用聞
き型情報提案サービスとして、以下のサービス等に適用
することが可能である。 （１）製造会社：自社製品に興味を持ってくれそうなお
客様を中心に製品案内を送りたい。 （２）広告主：お客様ごとにパーソナライズされた広告
を送りたい。 （３）物々交換：ユーザ間の合意に基づいて、製品を売
買したり、交換したい。

【００２５】なお、イベントのデータ部にどのような情
報を設定するかは、サービス依存である。例えば情報の
実体、情報へのリファレンス（ＵＲＬ、分散オブジェク
ト識別子等）、プロキシ（Ｊｉｎｉプロキシ等）、モバ
イルエージェントなど様々な利用形態が可能である。

【００２６】次に、ＳＩＯＮの詳細について説明する。

【００２７】＜ＳＩＯＮアーキテクチャ＞まず、ＳＩＯ
Ｎのネットワークアーキテクチャについて説明する。図
３にＳＩＯＮのネットワークモデルを示す。ここで、説
明の便宜上、端末２を、イベント送信者の送信端末２１
とイベント受信者の受信端末２２とに区別して表記す
る。イベント受信者は、受信端末２２を用いて自身が受
信することを希望するイベントの意味情報（受信するイ
ベントのタイプと取得条件）をメタデータとしてＳＩＯ
Ｎ１に登録する。これをフィルタ（Filter）と呼ぶ。一
方、イベント送信者は、送信端末２１を用いてＳＩＯＮ
１にイベントを送出することにより、ＳＩＯＮに刺激
（Incentive）を与える。このイベントは、図２に示す
ようにイベントの特性を記述した意味情報とデータから
構成される。意味情報の定義を図４に示す。意味情報
は、イベントのメタデータであり、かつ、意味情報タイ
プ（イベントタイプ）のインスタンスである。

【００２８】ＳＩＯＮ１は、イベント受信者が登録した
フィルタに対して、イベント送信者が送出したイベント
を照合（フィルターリング）させるための自律分散型の
照合ネットワークである。照合の結果、イベントが通過
した（イベントに反応した）フィルタは発火（Ignitio
n）し、対応するイベント受信者の受信端末２２が自律
起動する。この仕組みにより、不特定多数の端末２の中
から、対象となる端末２をスケーラブルかつリアルタイ
ムに探索・発見することが可能になる。

【００２９】次に、イベントタイプについて説明する。
図５に、イベントのテンプレートであるイベントタイプ
の定義例を示す。図５に示すように、イベントタイプ
は、イベントタイプ名（Event type name）と条件名
（図５においては、”Service”や”CPU power”が相当
する）、およびそれぞれの条件名に対するデータ型（St
ringやLongが相当する）と条件式（＝＝や＞＝が相当す
る）が定義されたものである。イベントタイプ名は、イ
ベントタイプを一意に識別するための名称である。

【００３０】なお、イベントタイプの親タイプを継承可
能である。

【００３１】図６に示すように、イベントタイプのデー
タ構造に従って、イベントを作成する。イベントは、イ
ベントタイプ名、条件名と条件値の組み合せ、および、
データ部から構成される。イベントの中で定義された条
件名、条件式、条件値が、イベントタイプと一致しない
場合は、エラーになる。但し、イベントの中で使用され
る条件名は、イベントタイプのサブセットでも良い。

【００３２】図７にフィルタの定義例を示す。フィルタ
は、受け付けるイベントタイプ名（Event type nam
e）、属性名（図７においては、”CPU power”や”Ag
e”が相当する）と属性値（図７においては、２００や
２５が相当する）のペアーから成る。受け付けるイベン
トタイプ名で定義されたイベントタイプに属するイベン
トのみが、フィルタリングの対象となる。ここには、複
数のイベントタイプ名を定義することができ、さらに、
ワイルドカード（＊．＊）を指定することにより、全て
のイベントを対象とすることも可能である。なお、フィ
ルタで定義された属性名が、受け付けるイベントタイプ
名で定義されたイベントタイプの条件名の中に存在しな
い場合には、エラーとなる。但し、イベントタイプのサ
ブセットでも良い。

【００３３】次に、ＳＩＯＮ１の構成を説明する。図８
は、ＳＩＯＮ１の構成を示す図である。図８に示すよう
にＳＩＯＮ１は、意味情報スイッチ（Semantic Informa
tion-Switch、図面ではＳＩ−ＳＷと図示する）、意味
情報ルータ（Semantic Information -Router、図面では
ＳＩ−Ｒと図示する）、意味情報ゲートウェイ（Semant
ic Information-Gateway、図面ではＳＩ−ＧＷと図示す
る）から構成される。

【００３４】意味情報スイッチ（ＳＩ−ＳＷ）は、フィ
ルタとして登録された意味情報と、イベントに付与され
た意味情報を照合し、その結果、発火したイベント受信
者の端末２を起動するスイッチング機構を提供する。意
味情報スイッチ（ＳＩ−ＳＷ）と各端末２はスター型で
結合される。

【００３５】意味情報ルータ（ＳＩ−Ｒ）は、意味情報
スイッチ間のイベント経路選択を行うとともに、端末２
から意味情報スイッチに対して送出されたイベントを他
の意味情報スイッチに転送する役割を担う。これは、意
味情報に基づく動的なイべントルーティングにより達成
される。

【００３６】意味情報ゲートウェイ（ＳＩ−ＧＷ）は、
イベントプレース（Event place）間でのイベントの転
送を行う。ここで、イベントプレースは、共通の意味情
報空間を保証する最小単位（オントロジードメイン）で
ある。イベントプレース内では、イベントタイプの名
称、概念、語彙、意味、関連などのオントロジー体系の
一意性が保証され、共通のオントロジーに基づいて意味
情報が記述されることになる。基本的には、イベント送
信者の端末２から送出したイベントは、イベントプレー
ス内のみで流通するが、意味情報ゲートウェイ（ＳＩ−
ＧＷ）を介することにより、異なるオントロジー体系を
有するイベントプレース間でのイベントの相互流通が可
能になる。このとき、意味情報ゲートウェイ（ＳＩ−Ｇ
Ｗ）はイベントのオントロジー変換を行った後、異なる
イベントプレースヘイベントを転送する。

【００３７】＜動作メカニズムとインタフェース仕様＞
ＳＩＯＮ１の実現方法の一例として、分散オブジェクト
技術を用いた実装方法を示す。ここで、ＳＩ−ＳＷｓＳ
Ｉ−Ｒ，ＳＩ−ＧＷは、それぞれ、イベントプレースオ
ブジェクト（ＥＰＯ）、シェアードリンクオブジェクト
（ＳＬＯ）、フェデレーションエージェント（ＦＡ）と
呼ばれる分散オブジェクトとして実装される。図９を用
いて、ＳＩＯＮ１の動作メカニズムと制御インタフェー
スを詳述する。また、ＳＩＯＮ−ＭＴ（Ｍａｎａｇｅｍ
ｅｎｔ Ｔｏｏｌ）やＳＩＯＮインタフェーサを用いる
ことにより、ＳＩＯＮ１のネットワークインタフェース
を使用することができる。また、ＭＴを用いて、ＥＰＯ
の撤収・増減設、物理リンク情報の動的変更、ＰＯマイ
グレーション（ＰＯのバインド先ＥＰＯの動的変更）、
発火率の収集、人気の高い惰報や流行している情報の統
計情報収集などを簡単に行うことができる。

【００３８】・イべントプレースファクトリの起動＆初
期化（図９（１）） まず、ＳＩＯＮ運営者は、任意のホスト上にイベントプ
レースファクトリ（ＥＰＦ）を起動し、続いて、ＥＰＦ
の初期化を行う。この時、ＥＰＦに対して、イべントプ
レース（ＥＰ）を生成可能なホスト名、およびＥＰの実
行ファイルの格納先を与える。これらを、ＥＰ生成情報
と呼ぶ。

【００３９】・イべントプレースの生成要求（図９
（２）） 次に、ＥＰ運営者は、ＥＰＦに対して、ＥＰの生成を要
求する。このとき、ＥＰ名、およびＥＰ属性を与える。
ここで、ＥＰ属性とは、生成されたＥＰが、御用聞きモ
デルもしくは問い合せモデルのどちらの目的で使用され
るかを表したものであり、イべントの流れの方向性を表
すものである。

【００４０】・イべントプレースの生成（図９（３）） 次に、ＥＰ生成要求を受け取ったＥＰＦは、ＥＰを生成
する。具体的には、このとき、ＥＰの管理を司るイべン
トプレースマネージメントオブジェクト（ＥＰＭＯ）が
生成される。すなわち、ＥＰへの処理要求は、ＥＰＭＯ
への処理要求と同義である。ＥＰＦは、生成要求元に生
成したＥＰ（すなわち、ＥＰＭＯ）の識別子を返却す
る。なお、ＥＰＭＯは、図９の（１）において指定され
た、ＥＰを生成可能なホストの中から、動的に決定され
たホストに対して生成される。ＥＰＭＯの起動先ホスト
の決定方法として、サイクリックに起動先を決定する、
トラヒックに応じて決定する、起動先ホストを明示的に
指定する、等の方法を選択できる。

【００４１】・イべントプレースの初期化要求（図９
（４）） 次に、ＥＰ運営者は、ＥＰの初期化をＥＰＭＯに依頼す
る。このとき、シングルイべントプレースオブジェクト
もしくは、マルチプルイべントプレースオブジェクトの
指定を行う。マルチプルイべントプレースオブジェクト
を指定した場合には、イべントプレースオブジェクト
（ＥＰＯ）の物理リンク情報（トポロジ）も併せて与え
る必要がある。ここで、ＥＰＯの物理リンク情報は、任
意のＥＰＯが他のどのＥＰＯの存在を知っているかを表
現したものである。

【００４２】例えば、図１０に示すように、ＥＰＯ２・
３２は、ＥＰＯ１・３１、ＥＰＯ３・３３、ＥＰＯ４・
３４の存在を知っているが、ＥＰＯ３・３３はＥＰＯ２
・３２の存在しか知らないことを表現している。このよ
うに、マルチプルＥＰＯは、ＥＰ内でのイべント照合処
理の負荷分散によるスケラビリティ向上を目的としたも
のである。

【００４３】ＥＰＭＯは、図９の（１）において指定さ
れた、ＥＰを生成可能なホストリストの中から、ＥＰＯ
を生成するホストを動的に決定し、そこにＥＰＯを生成
する。このとき、各ＥＰＯには、それぞれ一つのフィル
タファクトリ（ＦＦ）と統計情報収集オブジェクト（Ｓ
Ｏ）が常に付随して生成され、これらが、ＳＩ−ＳＷに
相当する。さらに、物理リンク数に応じて、シェアード
リンクオブジェクト（ＳＬＯ）が各ＥＰＯに付随して生
成される。例えば、ＥＰＯ２・３２に対しては３個のＳ
ＬＯが生成され（図中のＳＬＯ2,1、ＳＬＯ2,3、ＳＬＯ
2,4に対応する）、これらが、ＳＩ−Ｒに相当する。Ｅ
ＰＯの起動先の決定方法は、ＥＰＭＯのそれと同様であ
るが、イべントタイプ毎に使用するＥＰＯを固定化する
ことも可能である。なお、ＥＰＭＯは、ＥＰ内にイべン
トタイプファクトリ（ＥＴＦ）を生成する。ＥＰ内では
一元的なイベントタイプの名前空間がＥＴＦにより保証
される。

【００４４】・イべントプレースに対するイべント送信
のためのセッション確立要求（図９（５）） 次に、ＥＰにセッションの確立を要求する。ＥＰＭＯ
は、セッション要求毎にプロキシオブジェクト（ＰＯ）
を生成する。要求元へは、ＰＯの識別子であるセッショ
ン識別子を返却する。

【００４５】なお、ＥＰＭＯは、ＰＯの生成時に、ＰＯ
に対して、どのＥＰＯを使用する（どのＥＰＯとバイン
ドする）かを指示する。この指示は、マルチプルＥＰＯ
において必要となるが、バインドするＥＰＯの決定方法
は、ＥＰＭＯのそれと同様である。ＥＰへのセッション
確立要求時に、イべント送信のためのセッションである
か、イべント受信のためのセッションであるかを指定す
る必要がある。本例においては、イべント送信のための
セッションを指定する。

【００４６】・イべントタイプの登録（図９（６）） 次に、ＰＯに対して、イべントタイプの登録を要求す
る。このとき、ＰＯは、ＥＴＦにイべントタイプオブジ
ェクト（ＥＴＯ）の生成を要求する。さらに生成された
ＥＴＯにイべントタイプを格納する。一方、ＥＰに、イ
べントタイプ登録を要求することができる。このとき、
ＥＰＭＯは、ＥＴＦにＥＴＯの生成を要求し、生成され
たＥＴＯにイべントタイプを格納する。一般的に、イべ
ント送信者がイべントタイプを登録する場合は、ＰＯ経
由で行う。一方、ＥＰ運営者は、ＥＰに、イべントタイ
プ登録を行う。なお、同じ名前のイベントタイプを登録
するとエラーになる。

【００４７】・イべントプレースに対するイべント受信
のためのセッション確立要求（図９（７）） 次に、ＥＰに対してイベント受信のためのセッションの
確立を要求する。このとき、セッション確立の要求者
（イべント受信オブジェクト）は、イべントの通知先で
あるイべント受信オブジェクトの識別子、および、イべ
ントの通知方法（発火型、ルックイン型）をパラメータ
として与える。

【００４８】続いて、ＥＰＭＯは、セッション要求毎に
ＰＯを生成する。要求元へは、セッション識別子を返却
する。なお、ＥＰＭＯは、ＰＯの生成時に、ＰＯに対し
て、使用するＥＰＯを指示する。この指示は、マルチプ
ルＥＰＯにおいて必要となるが、バインドするＥＰＯの
決定方法は、ＥＰＭＯのそれと同様である。

【００４９】・フィルタオブジェクトの生成要求（図９
（８）） 次に、ＰＯに対して、フィルタオブジェクト（ＦＯ）の
生成を依頼する。このとき、ＰＯは、ＦＦにＦＯの生成
を要求する。このとき、ＰＯとバインドされたＥＰＯに
付随したＦＦが使用される。なお、ＦＯの生成要求元に
は、生成されたＦＯの識別子がＰＯ経由で返却される。

【００５０】・フィルタ値の設定（図９（９）） 次に、ＦＯ識別子をパラメータとして、ＦＯへのフィル
タ値の設定を、ＰＯへ依頼する。なお、フィルタオブジ
ェクトの中に格納されているイべントタイプ名（すなわ
ち、フィルターリングの対象とするイべントタイプ名）
をキーに、ＦＯのデータ構造（フィルタ値）が正しいか
どうかのチェックをＥＴＯに依頼することが選択的に可
能である。正しくない場合は、エラーとなる。但し、ワ
イルドカードが指定された場合には、このチェック処理
を一切行わない。

【００５１】・フィルタ登録（図９（１０）） 次に、ＦＯにフィルタ値を設定した後、Ｆのフィルタ識
別子をパラメータとして、ＰＯに対しフィルタの登録を
依頼する。このとき、登録要求元にフィルタ識別子が返
却される。これを契機に、イべントの受信が可能にな
る。なお、一つのＰＯを介して、複数のフィルタ登録が
可能であるが（これには、一つのＰＯを介して異なる複
数のＦＯをフィルタとして登録する、もしくは、同一の
ＦＯを複数回、フィルタとして登録する場合が考えられ
るが）、一つのＰＯに対して登録されたすべてのフィル
タは、“ＯＲの関係”を持つ。

【００５２】・イべント送信（図９（Ａ）） 次に、イベント送信者は、ＰＯに対して、イべントを送
信する。このとき、ＰＯは、イべントの中に格納されて
いるイべントタイプ名をキーに、イべントのデータ構造
が正しいかどうかのチェックをＥＴＯに依頼することが
選択的に可能である。このチェック処理を選択したと
き、正しい場合は、次の処理（図９（Ｂ））へ、正しく
ない場合は、エラーとなる。

【００５３】・イベントの照合依頼（図９（Ｂ）） 次に、ＰＯはイベントをＥＰＯに転送する。このとき、
ＥＰＯがスレッドを生成する。なお、スレッドはイベン
ト毎に生成され、各スレッドはイベントの多重処理を行
う。

【００５４】・フィルタとの照合（図９（Ｃ）） 次に、スレッド（ＥＰＯ）は、イベントとフィルタを照
合することにより、フィルターリング処理を行う。これ
には、完全一致、部分一致、重みづけ一致などがあり、
フィルタ値の設定時に指定することができる。

【００５５】・プロキシオブジェクトの起動（図９
（Ｄ）） 次に、フィルタとの照合の結果、イベントがフィルタを
通過すると、対応するＰＯが起動されこのイベントを受
け取る。このとき、ＰＯは、受信したイベントのタイ
プ、値、イベントＩＤ等をＳＯに登録することが選択的
に可能である。これらの情報から、ＳＯはイベントの発
火率（イベントタイプ毎、イベント毎）や、ＥＰ内で流
行している評判の高いイベントを測定することが可能に
なる。

【００５６】・イベント受信オブジェクトの起動（図９
（Ｅ）） 次に、ＰＯは、イベント受信オブジェクトを起動すると
ともに、イベント受信オブジェクトに対してこのイベン
トを渡す。これが、発火型（割り込み型）のイベント通
知に対応する。

【００５７】・ルックイン型のイベント通知（図９
（Ｆ）） 一方、ＰＯがイベント受信オブジェクトを起動するので
はなく、イベント受信オブジェクト自身が、イベント受
信オブジェクトに対応するＰＯにスプールされているイ
ベントを、取り出すことも可能である。これがルックイ
ン型のイベント通知に対応する。イベント受信オブジェ
クトの起動契機は、サービス形態に依存して種々存在す
るが、典型的な例として、エンドユーザがイベント受信
オブジェクトにコンテンツの提案要求を行った場合が考
えられる。

【００５８】＜フィルタの管理方法＞次に、各ＥＰＯに
おけるフィルタの管理方法を説明する。

【００５９】まず、イベント受信のためのセッションを
確立する。このとき、セッション要求毎に一つのＰＯが
生成され、このＰＯは任意の一つのＥＰＯにバインドさ
れる。このＥＰＯには、それぞれ、一つのＦＦが付随し
ている。これにより、ＰＯが使用するＥＰＯが一意に決
定され、以降の処理はすべて、ＰＯ（イベント受信用セ
ッション）を介して行われる。

【００６０】次に、ＦＯを生成し、ＦＯに対してフィル
タ値（受信するイベントのタイプとその取得条件）を設
定する。続いて、ＦＯ識別子をパラメータとして、フィ
ルタの登録を行う。このとき、各フィルタには、ＦＯ識
別子が格納される。各ＥＰＯは、ＰＯを介して登録され
たフィルタを以下に示す規則に基づいて管理する。

【００６１】まず、フィルタに格納されているＦＯ識別
子を用いて、ＦＯに設定されている“受信するイベント
のタイプ”を参照する。続いて、受信するイベントのタ
イプ毎にフィルタを分類し、イベントタイプ毎に分類さ
れたフィルタを、さらにＰＯ毎に細分類し、管理する。

【００６２】この管理規則について図１１を参照して、
ＰＯ１を介して、フィルタを登録する場合について説明
する。ここでは、フィルタ登録時に指定するＦＯの中
に、受信するイベントのタイプとして、“イベントタイ
プＸ”が設定されているものとする。このとき、ＥＰＯ
に登録されるフィルタは、図１１のフィルタ１が相当
し、同様に、ＰＯ２を介して登録されたフィルタにはフ
ィルタ２が相当する。また、各ＰＯにおいて、複数のフ
ィルタを登録することが可能であるが、登録されたフィ
ルタは“ＯＲ関係”を有するものとする。

【００６３】まず、イベントタイプＸのイベントがＥＰ
Ｏに到着したとき、フィルタ１との照合が行われる。そ
の結果、フィルタ１が発火するとＰＯ１が起動される。
次に、フィルタ２との照合が行われ、その結果、フィル
タ２が発火するとＰＯ２が起動される。このとき、フィ
ルタ２とフィルタ３は“ＯＲ関係”を有するため、フィ
ルタ３との照合は行われない。このようなフィルタ管理
方法を用いることにより、一つのイベントに対する各Ｅ
ＰＯでの照合処理回数を、基本的にＰＯ数（受信用セッ
ション数）以下にすることができる。

【００６４】＜イベントルーティング方法＞次に、イベ
ントルーティング方法について説明する。

【００６５】ＥＰＯ（ＳＩ−ＳＷ）は、イベントの送受
信者（端末などのエンティティ）をセッションを介して
スター型で収容する。さらに、ＥＰＯ（ＳＩ−ＳＷ）
は、イベント受信者（イベント受信オブジェクト）が登
録したフィルタと、イベント送信者が送出したイベント
を照合し、その結果、発火したフィルタに対応するイベ
ント受信者のみにイベントを通知する（合致するイベン
ト受信者にのみイベントを配送する）照合スイッチであ
る。

【００６６】そのため、イベントの送信者数（イベント
数）やイベントの受信者数（フィルタ数）が増加する
と、それに比例してＥＰＯの処理能力が飽和する。そこ
で、ＳＩＯＮアーキテクチャでは、スケラビリティの高
いＥＰを実現する手段として、マルチプルＥＰＯを提供
する。マルチプルＥＰＯとは、ＥＰＯ数に比して、ＥＰ
のトータル処理能力をスケーラブルに向上させることを
目的とし、具体的には、以下の２つの観点からＥＰの高
いスケラビリティを達成する。

【００６７】第一点は、負荷分散と自律分散である。こ
れは、複数のＥＰＯに、イベントの送受信者を分散させ
ることにより、イベントのフィルターリング処理の負荷
分散を行い、処理の集中に伴うボトルネック要因を作ら
ないようにするものである。。さらに、各ＥＰＯが他の
ＥＰＯの影響を受けることなく、自律的に動作可能な機
構による分散協調を達成する。

【００６８】第二点は、ネットワークトラヒックの削減
とフィルターリング処理の最適化である。これは、ＥＰ
Ｏ間で不要なイベントを転送しないことによる通信量の
最小化と、それに伴う無駄なフィルタリング処理の削減
を行うものである。

【００６９】図１０において、ＥＰＯ３・３３に対し、
受信するイベントのタイプとして、イベントタイプＸの
フィルタが登録される場合を考える。ここで、イベント
タイプＸのイベントがＥＰＯ４に対して送出されたと
き、ＥＰＯ２経由でこのイベントをＥＰＯ３に転送する
必要がある。このとき、イベントタイプＸのフィルタが
登録されていないＥＰＯ１に対して、当該イベントが転
送されてはならない。このようなＥＰＯ間のイベントの
ルーティング制御を行うものが、シェアードリンクオブ
ジェクト（ＳＬＯ）であり、前述したＳＩ−Ｒに相当す
る。

【００７０】以下にＳＩ−Ｒについて詳細を説明する。

【００７１】まず、ＥＰの初期化時に、物理リンク情報
（ＥＰＯのトポロジ）に基づいて、ＳＬＯが各ＥＰＯに
付随して生成される。例えば、図９において、ＥＰＯ２
に対して３個のＳＬＯが生成される。これらは、図中の
ＳＬＯ2,1、ＳＬＯ2,3、ＳＬＯ2,4に対応する。このＳ
ＬＯi,jは、ＥＰＯjからＥＰＯjへのイベント転送を行
うシェアードリンク（ＳＬi,j）を確立する。すなわ
ち、図９および図１２に示すように、ＳＬＯi,jは、Ｅ
ＰＯjに対してイベント受信のセッションを確立し、一
方、ＥＰＯiに対してイベント送信のセッションを確立
することにより、イベント転送のための論理リンクであ
るシェアードリンクＳＬi,jを確立する（シェアードリ
ンクとは、ＥＰの初期化時における、ＳＬＯによるセッ
ションの確立を意味し、フィルタ登録処理を含まな
い）。

【００７２】ＥＰの初期化後に、イベント受信者は、Ｅ
Ｐへのセッションを確立し、セッションを介してフィル
タを登録することが可能になる。このとき、確立済みの
シェアードリンクに従って、イベントパスが設定され
る。例えば、図１２において、イベント受信者（Event
Receiver）３がＰＯ３を介して、“イベントタイプＸの
イベント受信を行うフィルタを、ＥＰＯ３へ登録した場
合において、ＰＯ３は、ＥＰＯ３ヘイベントタイプＸの
フィルタを登録するとともに、その旨をＳＬＯ3,j（こ
こでは、ＳＬＯ3,2）に通知する。ＳＬＯ3,2はＳＬ3,2
を用いて、ＥＰＯ２に対してイベントタイプＸのフィル
タを登録する。これは、前述したように、ＳＬＯ3,2に
対して割り当てられた受信用セッションのＰＯを介して
行われる。同様に、このＰＯは、その旨を、ＳＬＯ2,3
を除くその他のＳＬＯ2,jに対して通知する。ＳＬＯ2,j
（ｊ≠３）は、ＳＬ2,jを用いて、ＥＰＯヘフィルタを
登録する。順次同様に、すべてのＥＰＯにイベントＸに
対するパスが設定されるまで、繰り返される。

【００７３】このように、イベントタイプＸに対して確
立された一連のパスを、イベントパスと呼ぶ。これは、
ＰＯ３を介したフィルタ登録がトリガとなって、すべて
のＥＰＯへ、イベントタイプ毎のイベントパス設定要求
が順次、自律的に波及していくものである。すなわち、
個々のＥＰＯは隣接するＥＰＯのみを認識すれば良い。
そのため、イベントパスの集中管理やブロードキャスト
によるイベントパスの設定・管理方法に比べて、簡単か
つ一元的な自律ロジックでイベントパスを確立すること
が可能になる。

【００７４】この時点でのＥＰＯ１におけるフィルタの
登録状況を図１３に示す。イベント受信者３がＰＯ３を
介してフィルタを登録した結果、フィルタ１がＥＰＯ１
に登録されることになる。イベントパスの設定とは、シ
ェアードリンク情報に基づいて、一連のＥＰＯにイベン
ト転送のためのフィルタを登録することを指す。また、
ＳＬＯが登録するフィルタには、受信するイベントタイ
プ名が設定されるのみであり、取得条件は設定されず、
イベントタイプ名のみのフィルターリングを行う。

【００７５】この状況において、イベント受信者２がＰ
Ｏ２を介して、イベントタイプＸのフィルタを、ＥＰＯ
２へ登録したとき、前述と同様に新たなイベントパスの
設定がすべてのＥＰＯへ波及し、その結果として、フィ
ルタ２がＥＰＯ１へ登録されることになり、イベントパ
ス設定の要求毎にフィルタが登録されることになる。

【００７６】このとき、ＥＰＯ１にイベントタイプＸの
イベントが送出されると、フィルタ１が発火し、ＳＬＯ
2,1が起動される。ＳＬＯ2,1が、このイベントをＥＰＯ
２へ送出することにより、ＳＬＯ3,2が起動される。さ
らに、ＳＬＯ3,2を介して、当該イベントがＥＰＯ３へ
も転送されることになる。また、ＳＬ2,3とＳＬ3,2間で
のイベントの無限転送を防止するために、イベントは、
制御情報の一つとして、通過したＥＰＯの識別子を、最
新順に最大２つ保持する。

【００７７】なお、前述したように、フィルタ１とフィ
ルタ２は、ＯＲ関係を有するため、フィルタ１が発火し
た場合にはフィルタ２との照合は行われない。そのた
め、フィルタ１が存在するにも関わらず、新たにフィル
タ２を登録したことに伴う、フィルターリング処理の冗
長オーバヘッドを全く生じないようにすることができ
る。これは、イベントパスを設定したときに、既設のイ
ベントパスを含めた全イベントパスの再構築を全く必要
としないことを意味し、簡単かつ一元的なイベントパス
の自律的な設定が可能になる。

【００７８】また、ＥＰＯ１内に、イベント受信者が確
立したセッションおよびそれを介したフィルタ登録があ
る場合には（ＰＯｎのフィルタ３に対応）、ＳＬＯ対応
のフィルタリング処理がすべて完了した後に、ＰＯｎ対
応のフィルターリング処理が行われる。すなわち、他の
ＥＰＯへのイベント転送処理を優先して行い、その後、
自ＥＰＯでの照合処理が開始される。

【００７９】以上説明した、イベントルーチング方法の
更なる効果として、フィルタ登録解除時に、イベントパ
スの再構築が必要ない点が挙げられる。例えば、イベン
ト受信者３がＰＯ３を介して、登録したフィルタの登録
解除を行った場合、登録の場合と同様に、解除要求が順
次、自律的に波及する。その結果、ＥＰＯ１において、
フィルタ１の登録のみが解除されることになるが、フィ
ルタ２は存命する（これ以降は、フィルタ２がフィルタ
１の代わりにイベントを転送する）ため、イベントパス
の再構築なしに、すべての既設イベントパスの一貫性が
保証される。

【００８０】このような自律分散型のルーティング制御
方法を用いることによって、ＥＰＯの相互接続と分散協
調を容易に実現することが可能になる。これに伴い、小
規模なネットワークから大規模なネットワークヘの移
行、ローカルなネットワークからグローバルなネットワ
ークヘの移行等をスムーズに行うことができる。また、
ボトムアップアプローチによるグローバルネットワーク
化を、共通のロジックで容易に達成することができる。

【００８１】図１４ないし図１７はリング型結合を持つ
物理リンクにおけるＳＩ−Ｒについて説明するために図
である。

【００８２】例えば、図１５に示すように、リング型結
合を持つ物理リンクにおいて、ＥＰＯ２は、ＥＰＯ１、
ＥＰＯ３の存在を知っていることを表現している。この
ように、マルチプルＥＰＯは、ＥＰ内でのイべント照合
処理の負荷分散によるスケラビリティ向上を目的とした
ものである。

【００８３】ＥＰＭＯは、図１４の（１）において指定
された、ＥＰを生成可能なホストリストの中から、ＥＰ
Ｏを生成するホストを動的に決定し、そこにＥＰＯを生
成する。このとき、各ＥＰＯには、それぞれ一つのフィ
ルタファクトリ（ＦＦ）と統計情報収集オブジェクト
（ＳＯ）が常に付随して生成され、これらが、ＳＩ−Ｓ
Ｗに相当する。さらに、物理リンクに応じて、シェアー
ドリンクオブジェクト（ＳＬＯ）が各ＥＰＯに付随して
一つ生成される。たとえば、ＥＰＯ２に対しては、図中
のＳＬＯ２，３が生成される。これが、ＳＩ−Ｒに相当
する。ＥＰＯの起動先の決定方法は、ＥＰＭＯのそれと
同様であるが、イベントタイプ毎に使用するＥＰＯを固
定化することも可能である。なお、ＥＰＭＯは、ＥＰ内
にイベントタイプファクトリ（ＥＴＦ）を生成する。Ｅ
Ｐ内では一元的なイベントタイプの名前空間がＥＴＦに
より保証される。

【００８４】以下にＳＩ−Ｒについて詳細を説明する。

【００８５】まず、ＥＰの初期化時に、物理リンク情報
（ＥＰＯのトポロジ）に基づいて、ＳＬＯが各ＥＰＯに
付随して生成される。たとえば、図１４において、ＥＰ
Ｏ２に対してＳＬＯ2,3が生成される。このＳＬＯi,j
は、ＥＰＯjからＥＰＯiへのイベント転送を行うシェア
ードリンク（ＳＬi,j）を確立する。すなわち、図１４
および図１６に示すように、ＳＬＯi,jは、ＥＰＯjに対
してイベント受信のセッションを確立し、一方、ＥＰＯ
iに対してイベント送信のセッションを確立することに
より、イベント転送のための論理リンクであるシェアー
ドリンクＳＬi,jを確立する（シェアードリンクとは、
ＥＰの初期化時における、ＳＬＯによるセッションの確
立を意味し、フィルタ登録処理を含まない）。これによ
って、片方向のリング状のシェアードリンクＳＬi,jが
確立される。

【００８６】ＥＰの初期化後に、イベント受信者は、Ｅ
Ｐへのセッションを確立し、セッションを介してフィル
タを登録することが可能になる。このとき、確立済みの
シェアードリンクに従って、イベントパスが設定され
る。例えば、図１６において、イベント受信者（Event
Receiver）３がＰＯ３を介して、イベントタイプＸのイ
ベント受信を行うフィルタを、ＥＰＯ３へ登録した場合
を考える。このとき、ＰＯ３は、ＥＰＯ３ヘイベントタ
イプＸのフィルタを登録するとともに、その旨をＳＬＯ
3,1に通知する。このとき、ＳＬＯ3,1には、フィルタ登
録の要求発生元がＥＰＯ３である旨がパラメータとして
与えられる。ＳＬＯ3,1はＳＬ3,1を用いて、ＥＰＯ１に
対してイベントタイプＸのフィルタを登録する。これ
は、前述したように、ＳＬＯ3,1に対して割り当てられ
た受信用セッションのＰＯを介して行われる。同様に、
このＰＯは、その旨を、ＳＬＯ1,2に対して通知する。
ＳＬＯ1,2は、ＳＬ1,2を用いて、ＥＰＯ２ヘフィルタを
登録する。順次同様に、すべてのＥＰＯにイベントＸに
対するパスが設定されるまで、繰り返される。なお、こ
の処理は、フィルタ登録の要求発生元（ここでは、ＥＰ
Ｏ３）の直前まで繰り返される。すなわち、ＳＬＯ2,3
は、ＥＰＯ３にフィルタを登録しない。

【００８７】この時点でのＥＰＯ１におけるフィルタの
登録状況を図１７に示す。イベント受信者３がＰＯ３を
介してフィルタを登録した結果、フィルタ１がＥＰＯ１
に登録されることになる。イベントパスの設定とは、シ
ェアードリンク情報に基づいて、一連のＥＰＯにイベン
ト転送のためのフィルタを登録することを指す。なお、
ＳＬＯが登録するフィルタには、受信するイベントタイ
プ名が設定されるのみであり、取得条件は設定されず、
イベントタイプ名のみのフィルターリングを行う。

【００８８】この状況において、イベント受信者２がＰ
Ｏ２を介して、イベントタイプＸのフィルタを、ＥＰＯ
２へ登録したとき、前述と同様に新たなイベントパスの
設定がすべてのＥＰＯへ波及し、その結果として、フィ
ルタ２がＥＰＯ１へ登録されることになり、イベントパ
ス設定の要求毎にフィルタが登録されることになる。

【００８９】このとき、ＥＰＯ１にイベントタイプＸの
イベントが送出されると、フィルタ１が発火し、ＳＬＯ
3,1が起動される。ＳＬＯ3,1が、当該イベントをＥＰＯ
３へ送出することにより、ＳＬＯ2,3が起動される。さ
らに、ＳＬＯ2,3を介して、当該イベントがＥＰＯ２へ
も転送されることになる。なお、イベントの無限巡回を
防止するために、イベントは、制御情報の一つとして、
イベントが生起したＥＰＯの識別子を保持し、イベント
の生起元ＥＰＯ（ＳＬＯ）に当該イベントが巡回して戻
って来たときに、当該イベントを破棄する。

【００９０】次に、前述したイベントルーティング方法
とは異なるイベントルーティング方法を説明する。この
ルーティング方法は、シェアードリンク（論理リンク）
を確立するまでの手順は、前述した方法と同様である。
このイベントルーティング方法が前述した方法と異なる
のは、イベントパスを確立しない点であり、ＳＬＯi,j
がシェアードリンクＳＬi,jを確立する時に同時に、唯
一のフィルタを登録するようにするものである。このと
き、登録されるフィルタには、受信するイベントのタイ
プとしてワイルドカードを指定する。これによって、す
べてのイベントを転送の対象とし、イベントタイプ毎の
イベントパスを確立しないようにする。

【００９１】このように意味情報にワイルドカードを指
定することによって、リング状のシェアードリンクＳＬ
i,j内をイベントが巡回するため、全てのＥＰＯに対し
てイベントを配送することが可能となる。

【００９２】＜フェデレーション方法＞次に、図１８を
参照してフェデレーション方法について説明する。フェ
デレーションエージェント（ＦＡ）とは、イベントプレ
ース間のフェデレーションを確立するエージェントであ
り、前述したＳＩ−ＧＷに相当する。例えば、イベント
プレース（Event Place）Ａがイベントプレース（Event
Place）Ｂに対してフェデレーションを確立する場合を
考える。まず、イベントプレースＡに属するＦＡが、イ
ベントプレースＢに対して、フィルタを登録する。この
とき、イベントプレースＢに属するイベント送信者がイ
ベントを送出し、その結果、このフィルタが発火する
と、ＦＡが自律起動する。これは、ＦＡをイベントプレ
ースＢに属する一つのイベント受信者として見なすこと
ができる。次に、ＦＡは取得したイベントを、自身が属
するイベントプレースＡに対して再送出する。これは、
ＦＡを、イベントプレースＡに属する一つのイベント送
信者として見なすことができる。

【００９３】このように両者の役割を併せ持つＦＡを用
いて、イベントプレース間のフェデレーションを容易に
実現できる。すなわち、単一イべントプレースと同じ制
御論理で、イベントプレース間のフェデレーションを実
現することが可能である。この機構を用いて、ＳＩＯＮ
１の基本構成単位であるイベントプレースを相互接続す
ることにより、グローバルな照合ネットワークをボトム
アップアプローチで構築することが可能となり、イベン
トプレース間に跨るイベントの共有を実現することがで
きる。なお、イベントプレースＡとイベントプレースＢ
がそれぞれ異なるオントロジーを持つ場合、イベントプ
レースＡに属するＦＡは、イベントプレースＢから取得
したイベントを、イベントプレースＡのオントロジーに
変換した後、イベントプレースＡに送出する。

【００９４】異なるオントロジー体系に跨ってイベント
転送を行う場合には、オントロジー変換が必要になる。
この変換を行う従来技術として、標準オントロジーを規
定し、他のイベントプレースにイベントを転送する場合
には、一旦、標準オントロジーに準拠した形式に変換し
た後に、イベントの転送を行う方法や、イベントプレー
スの組み合わせの数だけオントロジー変換テーブルを事
前に用意しておくなどの方法がある。

【００９５】しかしながら、イベントプレースの動的な
フェデレーション（フェデレーションの動的な開始、開
始解除）に対応するためには、従来の方法は柔軟性に欠
ける。そこで、本発明では、図１８に示すように、ＦＡ
が隣接するイベントプレースのオントロジー情報との差
分（変換情報）のみを、オントロジー変換テーブルに保
持するようにしている。すなわち、これは、各ＦＡが変
換情報をそれぞれ分散して保有し、全体でオントロジー
体系の一貫性を保証する方法である。これは、イベント
プレース間の動的なフェデレーションに容易に対応する
ことが可能になるが、その反面、イベントがイベントプ
レースを跨る毎に、オントロジー変換処理が発生するた
め、従来方法に比べて、変換処理オーバヘッドが増大す
るという特徴を有している。

【００９６】＜コミュニティと進化型ネットワーク＞次
に、ＳＩＯＮ１のキラーサービスの一つであるコミュニ
ティサービスについて説明する。コミュニティサービス
におけるエンティティは、自身のポリシに基づいて、学
習・進化・退化・消滅等を繰り返すことにより、その活
動様式を動的に決定することが可能な自律分散型の動作
主体である。コミュニティは、このようなエンティティ
に対して効率的なコミュニケーションの場を提供するも
のである。すなわち、コミュニティ内のエンティティ
は、自身とコミュニケートすべきエンティティや、自身
の振る舞いに影響を与えるエンティティを動的に探索・
発見・特定し、特定されたエンティティとインタラクシ
ョンを行うことが可能である。

【００９７】このコミュニティは、特に以下の特徴を持
つエンティティを取り扱うことができる。

【００９８】（１）極小粒度で、膨大な数のエンティテ
ィがコミュニティに存在する（不特定多数のエンティテ
ィ）。

【００９９】（２）エンティティの属性がリアルタイム
に変化する。典型的なエンティティの属性として、位置
情報、時刻等がある。

【０１００】（３）コミュニティ内のエンティティの振
る舞いに規則性がなく、行動予測が困難である。

【０１０１】（４）コミュニティヘの参加、コミュニテ
ィからの退去、消滅、複製等が頻繁かつ不規則に発生す
る。

【０１０２】（５）コミュニティ内のエンティティは、
ポリシ、属性、シナリオ等に基づいて相互にリアルタイ
ムに出会う必要がある。

【０１０３】このような特性を持つエンティティをサー
バやメディエータ（ブローカ）で管理し、相互にリアル
タイムに探索・発見することは性能上、容易でない。Ｓ
ＩＯＮ１のＥＰは、このような特徴を持つコミュニティ
の実行環境として位置づけられる。すなわち、コミュニ
ティはＥＰのメタ実行環境であり、ＥＰを直接用いるこ
とに比して、抽象度の高いコミュニケーションの場を提
供するものである。コミュニティの実行環境にＥＰを用
いることにより、コミュニティ内のすべてのエンティテ
ィは、ブローカを介することなく、コミュニケーション
すべきエンティティを直接発見することができる。これ
は、コミュニティ内のエンティティのコミュニケーショ
ンは、ＥＰ内のイベントの送受信として実装されるため
である。

【０１０４】図１９にコミュニティの概念モデルを示
す。ユーザエージェント（ＵＡ）、情報・サービス提供
エージェント（ＩＳＡ）がコミュニティ内のエンティテ
ィに相当する。ＵＡはユーザの代理人として自律的に振
る舞うエージェントであり、ユーザの嗜好、動作環境、
位置情報、状況、傾向などに応じて、自身の振る舞いを
動的に決定し、インタラクションすべきＩＳＡや他のＵ
Ａを探索し、それらとインタラクションする。ＩＳＡは
情報提供者やサービス提供者の代理人として自律的に振
る舞うエージェントであり、提供者の意図に基づいて、
インタラクションすべきＵＡや他のＩＳＡを探索する。
すなわち、自身の情報を提供するのに相応しいユーザを
探索して特定する。

【０１０５】一方、コミュニティエージェント（Ｃｏｍ
Ａ）は、コミュニティの運営を司るエージェントであ
る。ＥＰ運営者は、運営ポリシに基づいて、ＳＩＯＮ−
ＭＴを介したＳＩＯＮの制御・運営を行う。従って、Ｃ
ｏｍＡは、ＥＰ運営者をエージェント化したものと見な
すことができる。基本的に、コミュニティの運営ポリシ
はＣｏｍＡによって規定される。例えば、ＵＡ、ＩＳＡ
などのエンティティに対するコミュニティヘの参加、退
去、消滅、複製などの認可、コミュニティ内に流通させ
る情報の把握と統制（相応しくないイベントの削除な
ど）、コミュニティ内の統計情報（トレンド情報、評判
の高い情報など）の管理などを自身の運営ポリシに基づ
いて司る。

【０１０６】また、コミュニティの高いスケーラビリテ
ィやリライアビリティの保証を達成するため、負荷状況
や障害状況に応じて、ＥＰおよびＥＰＯの増減設、撤
収、マイグレーション等のＳＩＯＮ制御を実行する。す
なわち、ＳＩＯＮ１とＣｏｍＡを組み合わせることによ
り、ＳＩＯＮ１は自律分散型ネットワークから、学習、
成長、進化が可能な進化型ネットワークヘと発展する。
このように、ＣｏｍＡはコミュニティ内のエンティティ
の振る舞いを統制するとともに、ＳＩＯＮ１を自己組織
化するための役割を担う。さらに、コミュニティ間のコ
ラボレーションにより、コミュニティ間での情報の共有
が可能である。例えば、コミュニティＡにおいて流通し
ている情報の中で、人気が高いトップ１０のみを、コミ
ュニティＢに流通させることができる。以下に処理の流
れを示す。

【０１０７】まず、コミュニティＢのＣｏｍＡが、イベ
ントプレースＢのＦＡに対して、“コミュニティＡにお
いて流通している情報の中で、人気が高いトップ１０の
みを、コミュニティＢに流通させる”旨を指示する。

【０１０８】次にＦＡは、イベントプレースＡに対し
て、トップ１０のイベントタイプを問い合わせる。これ
を受けて、イベントプレースＡは、配下の統計情報収集
オブジェクト（ＳＯ）に問い合わせ、その結果を、ＦＡ
に返却する。

【０１０９】次に、ＦＡは取得したイベントタイプを基
に、オントロジー変換テーブルを作成するとともに、イ
ベントプレースＡに対しフィルタを設定する。以降、Ｆ
Ａは、イベントプレースＡから、当該イベントを受信可
能になる。

【０１１０】次にＦＡは、イベントプレースＡから取得
したイベントを、オントロジー変換テーブルに基づいて
オントロジー変換し、それをイベントプレースＢへと送
出する。

【０１１１】以上説明したような形態によれば、以下の
２点の効果を得ることができる。

【０１１２】第１に、分散オブジェクト環境上にＳＩＯ
Ｎのネットワーク環境を容易に構築できる。

【０１１３】第２に、サービスアプリケーションをエン
ティティとしてコミュニティに参加させることにより、
簡単にイベントを送出したり、必要なイベントをピック
アップすることが可能になり、相互にコミュニケション
を図ることが可能になる。

【０１１４】以上説明したように、ＳＩＯＮでは、以下
の効果を得ることができる。

【０１１５】ＦＡを介したイベントプレース間のフェデ
レーション機構により、他のイベントプレースのみで流
通していたイベントを、自イベントプレース内に取り込
むことができる。逆に、他のイベントプレースにイベン
トを送出することにより、自イベントプレース内で流通
しているイベントをアドバタイズできる。このように、
異なるイベントプレース間で、イベントの共有が可能に
なるとともに、オントロジーを考慮したイベントプレー
ス間の相互運用により、ボトムアップアプローチによる
グローバルな自律分散型の照合ネットワークを構築する
ことが可能になる。

【０１１６】マルチプルＥＰＯの機構により、フィルタ
リング処理を複数のＥＰＯに負荷分散させることが可能
になるとともに、自律的に動作するＥＰＯ間のイベント
ルーチング機構により、ネットワークトラヒックを最小
限に抑えることが可能になる。これにより、結果的にＥ
Ｐのトータルスループットをスケーラブルに向上させる
ことが可能となる。

【０１１７】ブローカを介することなく、自身に相応し
いエンティティを直接探索・発見することが可能とな
る。例えば、情報提供者は、ユーザの存在を知ることな
く、自身が提供する情報に相応しいユーザを特定するこ
とができる。同様に、ユーザは情報提供者の存在を知る
ことなく、自身の嗜好に相応しい情報提供者を探索・発
見することができる。すなわち、ユーザと情報提供者は
互いに等価的である。これにより、特定のブローカに頼
ることなく、自身のポリシに従って、リアルタイムに情
報を発信することが可能になる。また、探索対象となる
エンティティの数が膨大な場合やエンティティが探索対
象ドメインに頻繁に出入りする場合において、非ブロー
カモデルに基づく探索技術が特に有効となる。

【０１１８】ＳＩＯＮにおいては、意味情報の終端点が
ネットワークとなる。一方、端末間でpeer-to-peer接続
を行う方法においては、意味情報の終端点が端末になる
ため、端末の中身を外部に公開することになる。従っ
て、ＳＩＯＮは後者の方法と比べて、高いセキュリティ
とプライバシ保護を実現することが可能である。

【０１１９】次に、上記のような内容を備える意味情報
ネットワークシステムを用いた本発明の実施形態につい
て説明する。

【０１２０】図２０は、本発明の一実施形態のグループ
メンバ間情報配信システムにより提供されるグループメ
ンバ間情報配信サービスを説明するためのシステム図で
ある。本実施形態では、ある同好会を構成するメンバの
一部である予め登録された５人のグループメンバ（正太
郎、正弘、正彦、正美、正之助）間で情報の送受信を行
う例を用いて説明する。

【０１２１】本実施形態のグループメンバ間情報配信シ
ステムでは、グループメンバの各移動端末３１〜３５が
意味情報ネットワーク１０を介して接続されている。本
実施形態では、図２０における意味情報ネットワーク１
０を、上述したイベントプレースを用いて実現している
が、意味情報ネットワーク１０の実現方法はこの限りで
はない。

【０１２２】グループメンバの移動端末３１〜３５は、
それぞれ通知情報をイベントとして意味情報ネットワー
ク１０に送信する送信端末として機能するとともに、イ
ベントとして送信された通知情報を選択的に受信するた
めに、イベントのタイプと取得条件とからなるフィルタ
が設定されている受信端末としても機能する。

【０１２３】各グループメンバ（正太郎、正弘、正彦、
正美、正之助）はそれぞれ使用するＰＣ等の移動端末３
１〜３５に、ＣＯＲＢＡ準拠のＯＲＢ等のミドルウェア
と、上述したイベントプレースファクトリ生成機構をイ
ンストールして自身の端末においてイベントプレースを
生成するか、あるいは、他のネットワークノード上にあ
るイベントプレースへアクセスしてセッションを確立
し、意味情報ネットワーク１０に接続されていることを
前提とする。また、意味情報ネットワーク１０には、一
例として、図２１のようなイベントタイプが登録されて
いるとする。

【０１２４】また、各移動端末３１〜３５は、ＧＰＳ
（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅ
ｍ）受信機等の位置情報取得手段が備えられており、現
在の位置情報を収集することができるようになってい
る。

【０１２５】図２１に示すイベントタイプは、イベント
タイプ名として「グループメンバ通知」が定義され、イ
ベントプロパティ名として、「グループ名」、「暗証コ
ード」、「受取条件」が定義されているものとする。ま
た、これらのイベントプロパティには、イベントプロパ
ティ値として「string型」がそれぞれ定義されている。

【０１２６】ここで、「グループ名」とは、情報配信を
行おうとするグループの名称を示すイベントプロパティ
であり、「暗証コード」とは、グループのメンバである
ことを確認するための暗証コードを示すイベントプロパ
ティであり、「受取条件」とは、受取を行うことを希望
する情報の条件を示すイベントプロパティである。

【０１２７】次に、本実施形態のグループメンバ間情報
配信方法について図面を参照して詳細に説明する。図２
０中の括弧内の番号は、情報が伝送される順番または実
行される処理の順番を示すものであり、以下、この番号
順に本実施形態の動作について説明する。

【０１２８】（１）先ず、各グループメンバは、グルー
プメンバ用アプリケーションプログラムを使用して、図
２２または図２３に示すようなアプリケーション画面か
ら、グループ登録情報と自メンバ登録情報、さらに他メ
ンバとの距離を通知圏外と圏内、さらに圏内の場合は遠
近（必ずしも「近」と「遠」の二つとは限らず「中」な
どの多段設定もある）を指定するエリア定義情報を入力
し、グループメンバ間のメッセージ送受信を準備する。
図２２は「正太郎」が、グループ登録情報、自メンバ登
録情報、エリア定義情報を入力した場合の一例を示した
ものであり、図２３は「正彦」が、グループ登録情報、
自メンバ登録情報、エリア定義情報を入力した場合の一
例を示したものである。

【０１２９】ここで、エリア定義は各メンバが任意に決
め得る定義となっていて、メンバ２者間の距離をどう認
識するかは互いに独立である。例えば、図２４に示すよ
うに、「正太郎」と「正彦」との間の距離が０．８ｋｍ
の場合に、「正太郎」の設定したエリア定義によれば
「正彦は近くにいる」と認識されるのに対して、「正
彦」の設定したエリア定義によれば「正太郎は遠くにい
る」と異なって認識されることになる場合もあり得る。

【０１３０】このようにして、グループ登録情報、自メ
ンバ登録情報、エリア定義情報が入力された各移動端末
３１〜３５は、各移動端末３１〜３５に備えられている
位置情報取得手段により現在の位置情報の収集を開始す
る。

【０１３１】（２）次に、各グループメンバは、移動端
末３１〜３５のグループメンバ用アプリケーションプロ
グラム等を使用し、図２５、図２６に示すようなアプリ
ケーション画面から、通知伝言の入力と通知内容種別、
受取条件、相互通知形態を選択する。図２５は、「正太
郎」が通知伝言の入力と通知内容種別、受取条件、相互
通知形態を選択を行った場合の画面の一例を示すもので
あり、図２６は、「正彦」が通知伝言の入力と通知内容
種別、受取条件、相互通知形態を選択を行った場合の画
面の一例を示すものである。ここで、図２５、図２６中
の通知内容、受取条件の選択肢は一例であり、また受取
条件の選択は一つに限らない。

【０１３２】このとき、グループメンバ用アプリケーシ
ョンプログラムは、イベント受信のためのセションを確
立すると、フィルタオブジェクトの生成を行い、このフ
ィルタオブジェクトに図２７、図２８に示すようなフィ
ルタ値を設定する。図２７は「正太郎」の移動端末３１
のグループメンバ用アプリケーションにより設定された
フィルタの設定例であり、図２８は「正彦」の移動端末
３３のグループメンバ用アプリケーションにより設定さ
れたフィルタの設定例である。図２０では、設定される
フィルタを黒丸にして示している。

【０１３３】「正太郎」の場合は、“お誘い”と“待合
せ”の２つ受取条件が入力されたため、図２７（ａ）、
図２７（ｂ）に示すようにフィルタも２つ設定されてい
る。また、「正彦」の場合は、受取条件を限定しないよ
うに入力されているため受け取る情報を特定しない“do
n't care”が受取条件として設定されている。

【０１３４】（３）また、フィルタの設定を行った各グ
ループメンバ用アプリケーションは、図２９、図３０に
示すようなイベントを生成して、意味情報ネットワーク
１０に送信する。図２９は「正太郎」の移動端末３１の
グループメンバ用アプリケーションにより生成されるイ
ベントの一例を示す図であり、図３０は「正彦」の移動
端末３３のグループメンバ用アプリケーションにより生
成されるイベントの一例を示す図である。このイベント
には、各移動端末に備えられた位置情報受信手段により
得られた位置情報、および当該イベントを発信したグル
ープメンバに返信を行う際の返信先の情報が含まれてい
る。

【０１３５】意味情報ネットワーク１０において、移動
端末３１〜３３のグループメンバ用アプリケーションに
より意味情報ネットワーク１０に送信されたイベント
と、グループメンバ用アプリケーションにより設定され
たフィルタとの照合が行われ、フィルタ値に示される条
件に合致したイベントは、当該フィルタを設定した者に
転送される。ここで、イベントの通知内容は、フィルタ
の受取条件と照合される。

【０１３６】或るグループメンバのグループメンバ用ア
プリケーションが使用したイベントプレースと、別のグ
ループメンバのグループメンバ用アプリケーションが使
用したイベントプレース間は、上記で説明したようなイ
ベントプレースのフェデレーション機能により、情報の
相互流通が可能であるため、このイベントはいくつかの
イベントプレースを経由して、目的のグループメンバ用
アプリケーションが使用しているイベントプレースへ最
終的に転送される。「正弘」、「正美」、「正之助」の
各移動端末３２、３４、３５のグループメンバ用アプリ
ケーションも、それぞれフィルタ条件に合致したイベン
トを受信するが、図２０では説明を簡単にするために省
略する。図２０では、「正太郎」と「正彦」に着目し
て、各グループメンバが通知伝言を発信したとき、最終
的に「正太郎」と「正彦」がイベント群を受信する場合
を示している。以降は説明を簡単にするために、「正太
郎」と「正彦」の通知伝言送受信に着目して説明する。

【０１３７】尚、下記の説明では、「正太郎」と「正
彦」の間で送受信される通知伝言を図３１のシーケンス
チャートを用いて説明する。図３１では、「正太郎」と
「正彦」との間のフローのうち、「正彦」から通知を発
する場合を示す。

【０１３８】（４）「正彦」からの通知要求イベントを
受信した「正太郎」の移動端末３１では、グループメン
バ用アプリケーションが、受信した通知要求イベントに
含まれる「正彦」の位置情報と自らの位置情報取得手段
により得られた位置情報とから「正彦」との距離を求
め、既に設定済みのエリア定義に基づいて、圏外遠近の
判定を行い、その結果を圏外遠近結果とする。

【０１３９】ここでは、「正彦」と「正太郎」の間の距
離は、図２４に示すように０．８ｋｍであるとして説明
する。そのため、「正太郎」の移動端末３１では、圏外
遠近結果として、“近い（圏内）”という情報が得られ
る。

【０１４０】そして、「正太郎」の移動端末３１は、受
信した通知要求イベントに含まれる返信先情報により返
信先を特定し、特定したイベント送信元に対して、該圏
外遠近結果値および自己の位置情報を含んだ通知要求イ
ベント応答メッセージとして返信する。このようにして
「正太郎」から「正彦」に対して送信される通知要求イ
ベント応答メッセージを図３２（ｂ）に示す。

【０１４１】また、図３２（ａ）は「正太郎」からの
「待ち合わせ」伝言を「正彦」が受け取った後に、「正
彦」が「正太郎」に対して返信する通知要求イベント応
答メッセージの一例を示す図である。

【０１４２】（５）次に、「正太郎」への通知要求イベ
ントを送信した「正彦」の移動端末３３のグループメン
バ用アプリケーションは、予め定められた期間、通知要
求イベントに対する返信を待ち、その期間に受信した
「正太郎」からの通知要求イベント応答メッセージ（図
３３（ｂ））を受信する。

【０１４３】次に、「正彦」の移動端末３３のグループ
メンバ用アプリケーションは、受信した通知要求イベン
ト応答メッセージ中に含まれている圏外遠近結果が圏内
の場合、この通知要求イベント応答メッセージ中に含ま
れている「正太郎」の位置情報と自らの位置情報とから
距離を求め、既に設定済みのエリア定義から圏外遠近を
評価し、通知要求イベント応答メッセージ中にある返信
先情報をもとにメッセージ送信元のメンバである「正太
郎」に図３３（ｂ）に示すような折り返しメッセージを
返信する。

【０１４４】また、図３３（ａ）は「正彦」からの応答
を「正太郎」が受け取った後「正彦」に返信した折り返
しメッセージの設定例である。

【０１４５】ここでは、「正彦」と「正太郎」の間の距
離は、図２４に示すように０．８ｋｍであるとして説明
しているため、「正彦」の移動端末３３では、圏外遠近
評価として、“遠い（圏内）”という情報が得られる。

【０１４６】ここで、圏外遠近結果と圏外遠近評価の違
いについて説明する。

【０１４７】圏外遠近結果とは、通知要求イベントを受
信したグループメンバ側で設定されているエリア定義に
基づいた、通知要求イベントを発信したグループメンバ
と受信したグループメンバ間の距離の遠近判定値であ
る。つまり、図３１に示す例では、「正太郎」側で設定
されたエリア定義に基づいた、「正太郎」と「正彦」の
間の距離の遠近判定値である。

【０１４８】また、圏外遠近評価とは、通知要求イベン
トを発信したグループメンバ側で設定されているエリア
定義に基づいた、通知要求イベントを発信したグループ
メンバと受信したグループメンバ間の距離の遠近判定値
である。つまり、図３１に示す例では、「正彦」側で設
定されたエリア定義に基づいた、「正太郎」と「正彦」
の間の距離の遠近判定値である。

【０１４９】（６）そして、「正彦」の移動端末３３で
は、受信した通知要求イベント応答メッセージ中に含ま
れる登録情報をもとに相手メンバを特定し、圏外遠近評
価値に従って図３４のようなアプリケーション画面に表
示する。

【０１５０】「正彦」の移動端末３３のグループメンバ
用アプリケーションは、「正太郎」から受信した通知要
求イベント応答メッセージ中に含まれている圏外遠近結
果が圏外の場合には、「正太郎」の表示をアプリケーシ
ョン画面に表示しない。

【０１５１】また、「正彦」への通知要求イベント応答
メッセージを送信した「正太郎」の移動端末３１のグル
ープメンバ用アプリケーションは、「正彦」からの折り
返しメッセージを受信すると、この折り返しメッセージ
中にある圏外遠近評価が圏内の場合、折り返しメッセー
ジ中に含まれている登録情報をもとに相手メンバを特定
し、折り返しメッセージ中の回送されて来た圏外遠近結
果値に従って、図３５のようなアプリケーション画面に
表示する。

【０１５２】また、「正太郎」の移動端末３１のグルー
プメンバ用アプリケーションは、「正彦」から受信した
折り返しメッセージに含まれる圏外遠近評価が圏外の場
合、「正彦」の表示をアプリケーション画面には表示し
ない。

【０１５３】図３４で「正彦」の画面に「正弘」が表示
されていないのは距離が圏外にあるためである。また、
図３５で「正太郎」の画面に「正之助」が表示されてい
ないのは、受取条件が合わないためである。

【０１５４】上記で説明した「正太郎」と「正彦」の例
では、圏外遠近結果、圏外遠近評価がともに圏内となっ
ているため、「正太郎」と「正彦」の移動端末３１、３
３には、互いに相手の表示がされている。しかし、２人
のグループメンバ間において、圏外遠近結果、圏外遠近
評価のいずれかが圏外となった場合には、どちらの移動
端末にも相手の表示が行われない。このようにしている
のは、一方のグループメンバには圏内であると表示し、
他方のグループメンバには圏外であるため表示しないの
は不公平であるためである。つまり、相手は自分の存在
を知ることができるのに、自分は相手の存在を知ること
ができないのは不公正であるからである。

【０１５５】また、本実施形態のグループメンバ間情報
配信システムによれば、通知イベントが送信された時点
での各グループメンバ間の距離が、各移動端末において
定義されているエリア定義に基づいて表示される。しか
し、移動端末３１〜３５は、移動可能であるため、各グ
ループメンバ間の位置関係は刻々と変化する。そのた
め、各グループメンバのグループメンバ用アプリケーシ
ョンは、自らの位置の変化量がある一定値を超えた時新
たな位置情報を付加したイベントを送信する。このイベ
ント送出は（３）〜（６）のフローにより自アプリケー
ション画面上と一般に複数の相手アプリケーション画面
上に互いのメンバ表示を経時的に更新させる効果をも
ち、前記各グループメンバの移動に伴って時々刻々と変
化する互いの位置関係が前記各グループメンバのアプリ
ケーション画面に現れることになる。また、（どちらか
のグループメンバが圏外に移動した場合には互いの画面
に表示されなくなる）。

【０１５６】また、図２６で、「正彦」が通知内容を
「お誘い」から「お知らせ」に変えた場合、「正太郎」
は受取条件から「正彦」のイベントを受けることがなく
なり互いの古い位置関係が両者のアプリケーション画面
にそのまま残ってしまう可能性がある。そのため、この
ような場合を解決するために「正彦」のグループメンバ
用アプリケーションは、「お知らせ」のイベントを送出
する前に、図３０で位置情報を巨大値（距離を意図的に
圏外とする）にしたイベントを送出する。このイベント
送出は(３)〜（５）のフローにより自アプリケーション
画面上と一般に複数の相手アプリケーション画面上から
互いのメンバ表示を削除する効果をもち、常に新しいメ
ンバ一覧が維持される。

【０１５７】さらに、図２６で、「正彦」が受取条件を
「何でも」から「お誘い」に変えた場合、「何でも」に
対応するフィルタの設定解除によって「正太郎」は通知
内容から「正彦」にイベントを送ることがなくなり互い
の古い位置関係が両者のアプリケーション画面にそのま
ま残ってしまう可能性があるので、このような場合を解
決するために「正彦」のグループメンバ用アプリケーシ
ョンは、「お誘い」のフィルタを設定する前に、図３０
で位置情報を巨大値にし通知内容を限定しない（受取条
件との照合をしない）“don't care”としたイベントを
送出して、さらに、「正彦」の現通知内容「お誘い」
（受取条件と同時に通知内容を変えた場合は新通知内
容）に対応するイベントを送出する。この２つのイベン
ト送出は、前者が（３）〜（５）のフローによりすべて
の他グループメンバのアプリケーション画面から「正
彦」のメンバ表示をいったん削除し、後者が（３）〜
（６）のフローにより現通知内容に基づく相互メンバ表
示を復元し、全体として、旧フィルタに基づく相互メン
バ表示だけを削除する効果をもち、常に新しいメンバ一
覧が維持される。

【０１５８】上記で説明したように本実施形態のグルー
プメンバ間情報配信システムによれば、各グループメン
バは、グループメンバ用アプリケーション画面に、自ら
が設定したエリア定義により圏内となっている他のグル
ープメンバのうち、通知伝言がない場合はすべてのメン
バとの、通知伝言が有る場合は互いに通知条件や受取条
件が合ったメンバだけとの、随時変化する位置関係が相
互に表示されて、グループ内の動きを知り合い必要なら
通知伝言をもって意思を伝えることもできる。そのた
め、例えば、互いに近くに居る表示メンバの連絡先へ電
話をして行動を共にするなど、グループ内のコミュニケ
ーションの密度を高めたり、互いの位置確認のために無
用に電話を掛け合う機会を減らしたり、相互通知を停止
してプライバシを守ったりすることができる。

【０１５９】

【発明の効果】以上説明したように、本発明は、下記の
ような効果を有する。 （１）各グループメンバ間の位置関係を特定することが
できるような、グループメンバ間情報配信システムを仲
介者不要で実現することができる。 （２）リアルタイムな情報配信を可能とすることができ
る。 （３）グループメンバのポリシに基づく情報配信が可能
となる。 （４）グループメンバのプライバシ・機密情報の安全性
が向上する。 （５）仲介者が存在しないことにより負荷のボトルネッ
クが発生しない。 （６）仲介料が発生しない。 （７）グループメンバのうちのある特定の者にのみ情報
を配信する等の、選択的な情報の送受信が可能となる。

【図面の簡単な説明】

【図１】本発明の一実施形態の構成を示すブロック図で
ある。

【図２】イベントの構成を示す説明図である。

【図３】意味情報ネットワークのモデルを示す図であ
る。

【図４】意味情報の定義を示す説明図である。

【図５】イベントタイプの定義例を示す説明図である。

【図６】イベントの一例を示す説明図である。

【図７】フィルタの定義例を示す説明図である。

【図８】意味情報ネットワークの構成を示す図である。

【図９】意味情報ネットワークの動作メカニズムと制御
インタフェースを示す説明図である。

【図１０】物理リンクを示す説明図である。

【図１１】フィルタの管理方法を示す説明図である。

【図１２】イベントルーティング方法を示す説明図であ
る。

【図１３】フィルタの登録状況を示す説明図である。

【図１４】意味情報ネットワークの動作メカニズムと制
御インタフェースを示す説明図である。

【図１５】物理リンクを示す説明図である。

【図１６】イベントルーティング方法を示す説明図であ
る。

【図１７】フィルタの登録状況を示す説明図である。

【図１８】フェデレーション方法を示す説明図である。

【図１９】コミュニティモデル示す説明図である。

【図２０】本発明の第１の実施形態のグループメンバ間
情報配信システムを示す図である。

【図２１】図２０に示される意味情報ネットワーク１０
に登録されているイベントタイプの一例を示す図であ
る。

【図２２】グループメンバがグループにメンバ登録をす
る際の、移動端末におけるアプリケーション画面（「正
太郎」の例）を示す図である。

【図２３】グループメンバがグループにメンバ登録をす
る際の、移動端末におけるアプリケーション画面（「正
彦」の例）を示す図である。

【図２４】距離に関するグループメンバ間の相互認識の
違いを説明するための図である。

【図２５】グループメンバが通知と通知伝言に関する設
定をする際の、グループメンバ端末におけるアプリケー
ション画面（「正太郎」の例）を示す図である。

【図２６】グループメンバが通知と通知伝言に関する設
定をする際の、グループメンバ端末におけるアプリケー
ション画面（「正彦」の例）を示す図である。

【図２７】グループメンバが通知要求を受け付けるた
め、意味情報ネットワークに設定するフィルタ条件の一
例（「正太郎」の例）を示す図である。

【図２８】グループメンバが通知要求を受け付けるた
め、意味情報ネットワークに設定するフィルタ条件の一
例（「正彦」の例）を示す図である。

【図２９】グループメンバが通知要求を送信するため、
意味情報ネットワークに発信するイベントの一例（「正
太郎」の例）を示す図である。

【図３０】グループメンバが通知要求を送信するため、
意味情報ネットワークに発信するイベントの一例（「正
彦」の例）を示す図である。

【図３１】メンバ間の代表的なフロー（「正太郎」と
「正彦」の間に着目）を示す図である。

【図３２】通知要求イベントを受け付けたグループメン
バが結果を返すため、直接イベント送出元に返信する通
知要求イベント応答メッセージの一例（「正太郎」と
「正彦」の例）を示す図である。

【図３３】通知要求イベント応答メッセージを受けたグ
ループメンバが結果を返すため、直接通知要求イベント
応答メッセージ送出元に返信する折り返しメッセージの
一例（「正太郎」と「正彦」の例）を示す図である。

【図３４】グループメンバが他メンバの状況を知る際
の、グループメンバ端末におけるアプリケーション画面
（「正彦」の例）を示す図である。

【図３５】グループメンバが他メンバの状況を知る際
の、グループメンバ端末におけるアプリケーション画面
（「正太郎」の例）を示す図である。

【図３６】従来のグループメンバ間情報配信システムに
よるグループメンバ間情報配信サービスを説明するため
の図である。

【符号の説明】

１ 意味情報ネットワーク（ＳＩＯＮ） ２ 端末 １０ 意味情報ネットワーク ２１ 送信端末 ２２ 受信端末 ３１〜３５ グループメンバの移動端末 １０１〜１０５ グループメンバの端末 ２００ グループ管理者（仲介者）のサーバ ５００ インターネット ＳＩ−ＳＷ 意味情報スイッチ ＳＩ−Ｒ 意味情報ルータ ＳＩ−ＧＷ 意味情報ゲートウェイ ＥＰＯ イベントプレースオブジェクト ＳＬＯ シェアードリンクオブジェクト ＦＡ フェデレーションエージェント

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｑ 7/38 Ｈ０４Ｂ 7/26 １０９Ｍ 7/20 Ｈ０４Ｑ 7/04 Ｚ (72)発明者 星合 隆成 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 (72)発明者 酒井 隆道 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 (72)発明者 小柳 恵一 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 (72)発明者 金杉 恵次 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 前田 潤 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 Ｆターム(参考） 5B075 KK07 ND16 PP02 PP13 PP30 PQ02 QM08 UU40 5K067 AA21 BB21 DD17 DD53 EE02 EE10 EE16 FF23 HH21 HH22 JJ52 JJ56

Claims (6)

【特許請求の範囲】
1. 【請求項１】 データをイベントとして送信する送信端
   末と、イベントとして送信された前記データを選択的に
   受信するために、イベントのタイプと取得条件とからな
   るフィルタが設定される受信端末とから構成される意味
   情報ネットワークを用いて、予め登録された複数のグル
   ープメンバ間での情報の配信を行う、意味情報ネットワ
   ークを用いたグループメンバ間情報配信方法であって、 前記グループメンバの移動端末が、通知情報を受け取る
   ための受取条件をフィルタとして前記意味情報ネットワ
   ークに設定するステップと、 前記グループメンバの移動端末が、他のグループメンバ
   に通知したい通知情報の通知内容、自己の現在の位置情
   報および返信先情報が含まれた通知要求イベントを意味
   情報ネットワークに送信するステップと、 通知情報を受け取るための受取条件が設定されたグルー
   プメンバの移動端末が、イベントとして送信された前記
   通知要求を前記意味情報ネットワークから受信し、受信
   した通知要求に含まれる他のグループメンバの移動端末
   の位置情報と、自己の現在の位置情報とから他のグルー
   プメンバとの距離を求め、予め設定されたエリア定義に
   基づいて圏外遠近の評価を行い、その結果を圏外遠近結
   果値とするステップと、 前記通知要求イベントを受信したグループメンバの移動
   端末が、前記圏外遠近結果値および自己の位置情報を含
   んだ通知要求イベント応答メッセージを、受信した前記
   通知要求イベントに含まれる返信先情報により特定した
   返信先に送信するステップと、 前記通知要求イベント応答メッセージを受信したグルー
   プメンバの移動端末が、該通知要求イベント応答メッセ
   ージに含まれる他のグループメンバの移動端末の位置情
   報と、自己の現在の位置情報とから他のグループメンバ
   との距離を求め、予め設定されたエリア定義に基づいて
   圏外遠近の評価を行い、その結果を圏外遠近評価値とす
   るステップと、 前記通知要求イベント応答メッセージを受信したグルー
   プメンバの移動端末が、前記圏外遠近結果値および前記
   圏外遠近評価値および他のグループメンバに通知したい
   情報である通知情報を含んだ折り返しメッセージを、受
   信した前記通知要求イベント応答メッセージに含まれる
   返信先情報により特定した返信先に通知したい通知情報
   を含めて送信するステップと、 通知要求イベント応答メッセージを受信したグループメ
   ンバの移動端末が、該通知要求イベント応答メッセージ
   に含まれた圏外遠近結果値および得られた圏外遠近評価
   値がともに圏内を示している場合に、前記通知要求イベ
   ント応答メッセージを発信した他のグループメンバの位
   置を前記圏外遠近評価値に基づいて表示するステップ
   と、 前記折り返しメッセージを受信したグループメンバの移
   動端末が、受信した該折り返しメッセージに含まれてい
   る圏外遠近結果値および圏外遠近評価値がともに圏内を
   示している場合に、前記折り返しメッセージを発信した
   他のグループメンバの位置を前記圏外遠近結果値に基づ
   いて表示するとともに該折り返しメッセージに含まれて
   いる通知情報の表示を行うステップとを有する、意味情
   報ネットワークを用いたグループメンバ間情報配信方
   法。
2. 【請求項２】 データをイベントとして送信する送信端
   末と、イベントとして送信された前記データを選択的に
   受信するために、イベントのタイプと取得条件とからな
   るフィルタが設定される受信端末とから構成される意味
   情報ネットワークを用いて、予め登録された複数のグル
   ープメンバ間での情報の配信を行う、意味情報ネットワ
   ークを用いたグループメンバ間情報配信方法であって、 前記グループメンバの移動端末が、他のグループメンバ
   に通知したい通知情報の通知内容、自己の現在の位置情
   報および返信先情報が含まれた通知要求イベントを意味
   情報ネットワークに送信するステップと、 前記通知要求イベントを受信した他のグループメンバの
   移動端末から送信された通知要求イベント応答メッセー
   ジを受信したグループメンバの移動端末が、該通知要求
   イベント応答メッセージに含まれる他のグループメンバ
   の移動端末の位置情報と、自己の現在の位置情報とから
   他のグループメンバとの距離を求め、予め設定されたエ
   リア定義に基づいて圏外遠近の評価を行い、その結果を
   圏外遠近評価値とするステップと、 前記通知要求イベント応答メッセージを受信したグルー
   プメンバの移動端末が、前記圏外延期結果値および前記
   圏外遠近評価値および他のグループメンバに通知したい
   情報である通知情報を含んだ折り返しメッセージを、受
   信した前記通知要求イベント応答メッセージに含まれる
   返信先情報により特定した返信先に通知したい通知情報
   を含めて送信するステップと、 通知要求イベント応答メッセージを受信したグループメ
   ンバの移動端末が、該通知要求イベント応答メッセージ
   に含まれた圏外遠近結果値および得られた圏外遠近評価
   値がともに圏内を示している場合に、前記通知要求イベ
   ント応答メッセージを発信した他のグループメンバの位
   置を前記圏外遠近評価値に基づいて表示するステップと
   を有する、意味情報ネットワークを用いたグループメン
   バ間情報配信方法。
3. 【請求項３】 データをイベントとして送信する送信端
   末と、イベントとして送信された前記データを選択的に
   受信するために、イベントのタイプと取得条件とからな
   るフィルタが設定される受信端末とから構成される意味
   情報ネットワークを用いて、予め登録された複数のグル
   ープメンバ間での情報の配信を行う、意味情報ネットワ
   ークを用いたグループメンバ間情報配信方法であって、 前記グループメンバの移動端末が、通知情報を受け取る
   ための受取条件をフィルタとして前記意味情報ネットワ
   ークに設定するステップと、 通知情報を受け取るための受取条件が設定されたグルー
   プメンバの移動端末が、イベントとして送信された通知
   要求を前記意味情報ネットワークから受信し、受信した
   通知要求に含まれる他のグループメンバの移動端末の位
   置情報と、自己の現在の位置情報とから他のグループメ
   ンバとの距離を求め、予め設定されたエリア定義に基づ
   いて圏外遠近の評価を行い、その結果を圏外遠近結果値
   とするステップと、 前記通知要求イベントを受信したグループメンバの移動
   端末が、前記圏外遠近結果値および自己の位置情報を含
   んだ通知要求イベント応答メッセージを、受信した前記
   通知要求イベントに含まれる返信先情報により特定した
   返信先に送信するステップと、 前記通知要求イベント応答メッセージを受信した他のグ
   ループメンバの移動端末から送信された折り返しメッセ
   ージを受信したグループメンバの移動端末が、受信した
   該折り返しメッセージに含まれている圏外遠近結果値お
   よび圏外遠近評価値がともに圏内を示している場合に、
   前記折り返しメッセージを発信した他のグループメンバ
   の位置を前記圏外遠近結果値に基づいて表示するととも
   に該折り返しメッセージに含まれている通知情報の表示
   を行うステップとを有する、意味情報ネットワークを用
   いたグループメンバ間情報配信方法。
4. 【請求項４】 データをイベントとして送信する送信端
   末と、イベントとして送信された前記データを選択的に
   受信するために、イベントのタイプと取得条件とからな
   るフィルタが設定される受信端末とから構成される意味
   情報ネットワークを用いて、予め登録された複数のグル
   ープメンバ間での情報の配信を行う、意味情報ネットワ
   ークを用いたグループメンバ間情報配信システムであっ
   て、 他のグループメンバに通知したい通知情報の通知内容、
   自己の現在の位置情報および返信先情報が含まれた通知
   要求イベントを意味情報ネットワークに送信し、前記通
   知要求イベントを受信した他のグループメンバの受信端
   末から送信された通知要求イベント応答メッセージを受
   信すると、該通知要求イベント応答メッセージに含まれ
   る他のグループメンバの受信端末の位置情報と、自己の
   現在の位置情報とから他のグループメンバとの距離を求
   め、予め設定されたエリア定義に基づいて圏外遠近の評
   価を行い、その結果を圏外遠近評価値とし、前記圏外遠
   近結果値および前記圏外遠近評価値および他のグループ
   メンバに通知したい情報である通知情報を含んだ折り返
   しメッセージを、受信した前記通知要求イベント応答メ
   ッセージに含まれる返信先情報により特定した返信先に
   通知したい通知情報を含めて送信すし、前記通知要求イ
   ベント応答メッセージに含まれた圏外遠近結果値および
   得られた圏外遠近評価値がともに圏内を示している場合
   に、前記通知要求イベント応答メッセージを発信した他
   のグループメンバの位置を前記圏外遠近評価値に基づい
   て表示するグループメンバの送信端末と、 通知情報を受け取るための受取条件が設定され、イベン
   トとして送信された前記通知要求を前記意味情報ネット
   ワークから受信し、受信した通知要求に含まれる他のグ
   ループメンバの送信端末の位置情報と、自己の現在の位
   置情報とから他のグループメンバとの距離を求め、予め
   設定されたエリア定義に基づいて圏外遠近の評価を行
   い、その結果を圏外遠近結果値とし、前記圏外遠近結果
   値および自己の位置情報を含んだ通知要求イベント応答
   メッセージを、受信した前記通知要求イベントに含まれ
   る返信先情報により特定した返信先に送信し、前記通知
   要求イベント応答メッセージを受信した他のグループメ
   ンバの送信端末により送信された折り返しメッセージを
   受信し、受信した該折り返しメッセージに含まれている
   圏外遠近結果値および圏外遠近評価値がともに圏内を示
   している場合に、前記折り返しメッセージを発信した他
   のグループメンバの位置を前記圏外遠近結果値に基づい
   て表示するとともに該折り返しメッセージに含まれてい
   る通知情報の表示を行うグループメンバの受信端末とを
   有する、意味情報ネットワークを用いたグループメンバ
   間情報配信システム。
5. 【請求項５】 イベントとして送信された前記データを
   選択的に受信するためにイベントのタイプと取得条件と
   からなるフィルタが設定される受信端末を有する意味情
   報ネットワークに対して、データをイベントとして送信
   する送信端末であって、 他のグループメンバに通知したい通知情報の通知内容、
   自己の現在の位置情報および返信先情報が含まれた通知
   要求イベントを意味情報ネットワークに送信し、前記通
   知要求イベントを受信した他のグループメンバの受信端
   末から送信された通知要求イベント応答メッセージを受
   信すると、該通知要求イベント応答メッセージに含まれ
   る他のグループメンバの受信端末の位置情報と、自己の
   現在の位置情報とから他のグループメンバとの距離を求
   め、予め設定されたエリア定義に基づいて圏外遠近の評
   価を行い、その結果を圏外遠近評価値とし、前記圏外遠
   近結果値および前記圏外遠近評価値および他のグループ
   メンバに通知したい情報である通知情報を含んだ折り返
   しメッセージを、受信した前記通知要求イベント応答メ
   ッセージに含まれる返信先情報により特定した返信先に
   通知したい通知情報を含めて送信すし、前記通知要求イ
   ベント応答メッセージに含まれた圏外遠近結果値および
   得られた圏外遠近評価値がともに圏内を示している場合
   に、前記通知要求イベント応答メッセージを発信した他
   のグループメンバの位置を前記圏外遠近評価値に基づい
   て表示するグループメンバの送信端末。
6. 【請求項６】 送信端末からイベントとして送信された
   データを、意味情報ネットワークを介して選択的に受信
   するためにイベントのタイプと取得条件とからなるフィ
   ルタが設定された受信端末であって、 通知情報を受け取るための受取条件が設定され、イベン
   トとして送信された通知要求を前記意味情報ネットワー
   クから受信し、受信した通知要求に含まれる他のグルー
   プメンバの送信端末の位置情報と、自己の現在の位置情
   報とから他のグループメンバとの距離を求め、予め設定
   されたエリア定義に基づいて圏外遠近の評価を行い、そ
   の結果を圏外遠近結果値とし、前記圏外遠近結果値およ
   び自己の位置情報を含んだ通知要求イベント応答メッセ
   ージを、受信した前記通知要求イベントに含まれる返信
   先情報により特定した返信先に送信し、前記通知要求イ
   ベント応答メッセージを受信した他のグループメンバの
   送信端末により送信された折り返しメッセージを受信
   し、受信した該折り返しメッセージに含まれている圏外
   遠近結果値および圏外遠近評価値がともに圏内を示して
   いる場合に、前記折り返しメッセージを発信した他のグ
   ループメンバの位置を前記圏外遠近結果値に基づいて表
   示するとともに該折り返しメッセージに含まれている通
   知情報の表示を行うグループメンバの受信端末。