JP2002259620A - 意味情報ネットワークを用いたくじ運用方法およびシステムと送信端末および受信端末 - 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型」が定義されている。

【０１３９】次に、本実施形態のくじ運用方法について
図面を参照して詳細に説明する。図２０中の括弧内の番
号は、情報が伝送される順番または実行される処理の順
番を示すものであり、以下、この番号順に本実施形態の
動作について説明する。また、図２２は、本実施形態に
おける処理の順番を説明するためのシーケンスチャート
である。

【０１４０】（１）くじ購入者１、２は、端末４１、４
２のくじ購入者用アプリケーションプログラムを用い
て、図２３、２４に示すようなアプリケーション画面か
らくじ購入要求条件を入力する。くじ購入要求条件と
は、具体的には、購入希望枚数と、購入を希望するくじ
の種類とを指定する条件である。例として、くじ購入者
１は、図２３に示すように、５枚のくじを購入するとい
う購入要求条件を入力し、くじ購入者２は、図２４に示
すように、３枚のくじを購入するという購入要求条件を
入力したものとする。本実施形態では、くじの種類は１
種類しかない場合を用いて説明しているため、図２３、
図２４ではくじの種類を特定するための条件はくじ購入
要求条件には含まれていない。

【０１４１】このようにくじ購入要求条件を入力された
購入者用アプリケーションは、乱数等を用いてくじ購入
者宛先名を生成し、イベント受信のためのセッションを
確立し、フィルタオブジェクトの生成を行って、この購
入者宛先名をフィルタ値として設定する。本実施形態で
は、くじ購入者宛先名を乱数を用いて生成しているの
は、くじ主催者がくじ購入者を特定することができない
ようにするためである。従って、くじ購入者を特定する
ことができないようなものであれば、くじ購入者宛先名
は乱数以外を用いて生成するようにしてもよい。

【０１４２】図２５はくじ購入者１の端末４１のくじ購
入者用アプリケーションにより設定されるフィルタ値の
一例を示したものであり、図２６はくじ購入者２の端末
４２のくじ購入者用アプリケーションにより設定される
フィルタ値の一例を示したものである。

【０１４３】（２）次に、くじ購入者用アプリケーショ
ンは、くじ購入要求条件と、くじ購入者宛先名を含むく
じ購入要求メッセージを、発信者を特定することができ
ない通信手段によりくじ主催者に送付する。ここで、発
信者を特定することができない通信手段としては、例え
ば、くじ主催者がフィルタを意味情報ネットワーク１０
に設定し、くじ購入者がくじ購入要求メッセージをイベ
ントとして送信するようにしてもよい。また、発信者を
特定することができない他の通信手段としては、例え
ば、インターネットを介して提供されるｗｅｂページ上
での入力、番号非通知によるＦＡＸ等の発信者を特定す
ることができない手段であればどのような手段であって
もよい。図２７は、くじ購入者１からくじ主催者に対し
て送信されるくじ購入要求メッセージの例を示すもので
あり、図２８は、くじ購入者２からくじ主催者に対して
送信されるくじ購入要求メッセージの例を示すものであ
る。

【０１４４】（３）また、くじ購入者１、２は、乱数等
を用いて発行されたくじ購入者宛先名で、くじ主催者の
口座に振り込みを行う等の方法によりくじの代金を支払
う。

【０１４５】（４）くじ購入者１、２からのくじ購入要
求メッセージを受信したくじ主催者は、端末３０のくじ
主催者用アプリケーションプログラムを用いて、受信し
たくじ購入要求メッセージに含まれている購入希望枚数
に応じた枚数のくじを発行する。そして、くじ主催者の
端末３０は、発行したくじ番号および主催者発行証明を
含んだ発行情報を、くじ購入要求メッセージに含まれて
いたくじ購入者宛先名を条件としたイベントとして意味
情報ネットワーク１０に対して送信する。

【０１４６】くじ主催者の端末３０が、くじ購入者１か
らのくじ購入要求メッセージに基づいて生成したイベン
トを図２９に示し、くじ購入者２からのくじ購入要求メ
ッセージに基づいて生成したイベントを図３０に示す。

【０１４７】ここで、くじ主催者から送信されるイベン
トに含まれている主催者発行証明は、くじ主催者が発行
した正規のくじであることを証明するための情報であ
り、くじ主催者がくじ番号等からディジタル署名技術等
を用いて発行したくじ毎に生成するものである。この主
催者発行証明は、くじ購入者から当選の申し出があった
場合に、そのくじが正規に発行されたものかどうかをく
じ主催者が確認するために用いられる。

【０１４８】（５）そして、意味情報ネットワーク１０
では、くじ購入者により設定されたフィルタとくじ主催
者により送信されたイベントとの照合が行われ、フィル
タ値に示される条件（くじ購入要求者宛先名）に合致し
たイベントが、当該フィルタを設定したくじ購入者用ア
プリケーションプログラムに転送される。くじ主催者用
アプリケーションが使用したイベントプレースと、くじ
購入者用アプリケーションが使用したイベントプレース
間は、イベントプレースのフェデレーション機能によ
り、情報の相互流通が可能であるため、くじ主催者によ
り送信されたイベントはいくつかのイベントプレースを
経由して、目的のくじ購入者用アプリケーションが使用
しているイベントプレースへ最終的に転送される。

【０１４９】くじ購入者用アプリケーションは、受信し
たイベントに含まれるくじ番号と、このくじ番号に対応
する主催者発行証明を記憶する。くじ番号および主催者
発行証明が暗号化されている場合には復号してから記憶
する。

【０１５０】ここで、意味情報ネットワーク１０には、
図２１に示したイベントタイプとは別に、図３１に示す
ようなイベントタイプがすでに登録されているものとす
る。この登録されているイベントタイプは、イベントタ
イプ名として「当選通知」が定義され、イベントプロパ
ティ名として「くじ名」、「当選番号」が定義されてい
る。また、このイベントプロパティには、イベントプロ
パティ値として「string型」がそれぞれ定義されてい
る。

【０１５１】そして、くじ購入者用アプリケーション
は、フィルタオブジェクトを生成し、受信したイベント
に含まれるくじ番号を「当選番号」のイベントプロパテ
ィ値として設定し、くじの種類が複数ある場合にはくじ
の種類を特定するための情報を「くじ名」のイベントプ
ロパティ値として設定することによりフィルタを生成す
る。図３２に、くじ購入者１が購入した１枚目のくじに
対応して設定するフィルタのフィルタ値の一例を示す。

【０１５２】（６）くじ主催者は、抽選等によりくじの
当選番号が決まると、端末３０のくじ主催者用アプリケ
ーションプログラム等により、当選通知情報として、図
３３に示すような当選番号およびくじの種類を特定する
ための情報を条件とするイベントを生成して意味情報ネ
ットワーク１０に送信する。

【０１５３】（７）意味情報ネットワーク１０では、く
じ購入者１、２が設定したフィルタと当選通知情報のイ
ベントとの照合が行われ、フィルタ値に示される条件
（くじ番号、くじの種類を特定するための情報）に合致
したイベントが、当該フィルタを設定したくじ購入者用
アプリケーションプログラムに転送される。図２０で
は、くじ購入者１は図３２に示すフィルタにより図３３
のイベントを受信する。なお、条件の照合は、フィルタ
に設定された文字列が、イベントの含む文字列の一部と
一致することによっても成功するものとする。くじ購入
者１の端末４１におけるくじ購入者用アプリケーション
は、当選通知を図３４のように表示し、くじ購入者１に
当選を知らせる。

【０１５４】図２０では、くじ購入者２が購入したくじ
は当選しなかったため、くじ主催者の端末３０からの当
選通知はくじ購入者２の端末４２には受信されない。こ
の場合には、購入者２の端末４２には、図３５に示すよ
うな表示がなされる。

【０１５５】当選通知を受信したくじ購入者１は、くじ
主催者の端末３０に、当選したくじ番号や記憶しておい
た主催者発行証明等を含む図３６に示すような当選申出
メッセージを送信する。

【０１５６】（８）くじ購入者１からの当選申出メッセ
ージを受信したくじ主催者は、当選番号、主催者発行証
明等を用いて当選内容の確認を行った後に、賞金の支払
いや賞品の贈呈を行う。

【０１５７】以上に述べた本実施形態におけるくじ運用
方法では、くじ主催者がくじ発行時にくじ購入者につい
て知りうるのはくじ購入者が乱数等を用いて決めたくじ
購入者宛先名のみである。そのため、くじ主催者は、誰
がどの番号のくじを購入したかというくじ購入者のプラ
イバシを知ることはできない。また本実施形態のくじ運
用システムでは、仲介者は存在しないため、仲介者に誰
がどの番号のくじを購入したかという事項を知られるこ
ともない。また、仲介者が存在しないことにより仲介者
のサーバにおいて負荷が集中する等の弊害が発生しな
い。

【０１５８】さらに、当選通知の際には、くじ主催者は
当選番号をイベントとして意味情報ネットワーク１０に
送信するのみでよいため、くじの当選者が誰であるか知
ることはなく、またくじ購入者が購入したくじを他者に
譲り渡した場合にも、くじを譲り受けた者がフィルタを
設定すれば、当選通知は譲り受けた者に届く。

【０１５９】また、くじ購入者宛先名は乱数等で決定す
るため、複数のくじ購入者間で偶然同一の値になってし
まう可能性があるが、十分に大きい桁数の宛先名を用い
ればそうしたことはほとんど生じないため、実用上問題
にはならない。

【０１６０】

【発明の効果】以上説明したように、本発明は、下記の
ような効果を有する。 （１）誰がどの番号のくじを購入したかというくじ購入
者のプライバシが主催者に知られることもなく、また、
仲介者の存在が不要のためくじ購入者のプライバシが仲
介者に知られることもないので、くじ購入者のプライバ
シの保護が図れる。 （２）くじ主催者は当選通知を行うために、単に当選番
号を含む情報を意味情報ネットワークにイベントとして
送信するだけでよいため、くじ購入者が発行を受けたく
じを他人に譲り渡すことが仲介者を必要とせず可能とな
る （３）また、仲介者の存在が不要なことにより、仲介料
の発生を不要とし、負荷が仲介者の運営するサーバに集
中することがない。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図２０】本発明の一実施形態のくじ運用システムを示
す図である。

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

【図２２】図２０に示すくじ運用システムの動作を示す
シーケンスチャートである。

【図２３】くじ購入者１が、くじ購入要求条件を設定す
る際に、端末４１に表示されるくじ購入者用アプリケー
ションの画面の一例を示す図である。

【図２４】くじ購入者２が、くじ購入要求条件を設定す
る際に、端末４２に表示されるくじ購入者用アプリケー
ションの画面の一例を示す図である。

【図２５】くじ購入者１の端末４１のくじ購入者用アプ
リケーションにより設定されるフィルタ条件の一例を示
す図である。

【図２６】くじ購入者２の端末４２のくじ購入者用アプ
リケーションにより設定されるフィルタ値の一例を示す
図である。

【図２７】くじ購入者１からくじ主催者に対して送信さ
れるくじ購入要求メッセージの例を示す図である。

【図２８】くじ購入者２からくじ主催者に対して送信さ
れるくじ購入要求メッセージの例を示す図である。

【図２９】くじ主催者の端末３０が、くじ購入者１から
のくじ購入要求メッセージに基づいて生成したイベント
を示す図である。

【図３０】くじ主催者の端末３０が、くじ購入者２から
のくじ購入要求メッセージに基づいて生成したイベント
を示す図である。

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

【図３２】くじ購入者１が購入した１枚目のくじに対応
して設定するフィルタのフィルタ値の一例を示す。

【図３３】端末３０のくじ主催者用アプリケーションプ
ログラム等により、当選通知情報として意味情報ネット
ワーク１０に送信されるイベントの一例を示す図であ
る。

【図３４】購入したくじが当選したくじ購入者１の端末
４１に表示される当選通知の一例を示す図である。

【図３５】購入したくじ番号が当選しなかったくじ購入
者２の端末４２に表示される通知の一例を示す図であ
る。

【図３６】当選通知を受信したくじ購入者１が、くじ主
催者の端末３０に送信する当選申出メッセージの一例を
示す図である。

【図３７】従来のくじ運用システムの一例を説明するた
めの図である。

【図３８】従来のくじ運用システムの他の例を説明する
ための図である。

【符号の説明】

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

フロントページの続き (72)発明者 星合 隆成 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 (72)発明者 酒井 隆道 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 (72)発明者 小柳 恵一 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 (72)発明者 前田 潤 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 金杉 恵次 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内

Claims (6)

【特許請求の範囲】
1. 【請求項１】 データをイベントとして送信する送信端
   末と、イベントとして送信された前記データを選択的に
   受信するために、イベントのタイプと取得条件とからな
   るフィルタが設定される受信端末とから構成される意味
   情報ネットワークを用いて、くじの購入を希望するくじ
   購入者が、くじの販売を行っているくじ主催者からくじ
   を購入し、くじの抽選が行われ当選したくじが決定した
   場合には、その当選したくじを購入したくじ購入者に対
   して、購入したくじが当選した旨を通知する、意味情報
   ネットワークを用いたくじ運用方法であって、前記くじ
   購入者の端末が、くじの購入者を特定することができな
   いようなくじ購入者宛先名を生成し、該くじ購入者宛先
   名をイベントの取得条件としたフィルタを前記意味情報
   ネットワークに設定するステップと、 前記くじ購入者の端末が、購入するくじの枚数である購
   入希望枚数と購入を希望するくじの種類からなるくじ購
   入条件と、前記くじ購入者宛先名の情報とを含んだくじ
   購入要求メッセージを、発信者を特定することができな
   い通信手段により、前記くじ主催者の端末に送信するス
   テップと、 前記くじ購入要求メッセージを受信したくじ主催者の端
   末が、受信したくじ購入要求メッセージに含まれている
   購入希望枚数に応じた枚数のくじを発行し、発行したく
   じ番号および当該くじがくじ主催者が発行した正規のく
   じであることを証明するための情報である主催者発行証
   明を含んだくじ発行情報を、受信したくじ購入要求メッ
   セージに含まれていたくじ購入者宛先名を条件としたイ
   ベントとして前記意味情報ネットワークに対して送信す
   るステップと、 くじ購入者宛先名を取得条件とするフィルタを設定して
   いる前記くじ購入者の端末が、イベントとして送信され
   た前記くじ発行情報を前記意味情報ネットワークから受
   信し、受信したイベントに含まれるくじ番号および該く
   じの種類を特定するための情報をフィルタとして前記意
   味情報ネットワークに設定するステップと、 前記くじ主催者の端末が、くじの抽選が行われ当選した
   くじ番号が決定されると、該当選番号およびくじの種類
   を特定するための情報を条件とした当選通知情報をイベ
   ントとして前記意味情報ネットワークに送信するステッ
   プと、 くじ番号および該くじの種類を特定するための情報をフ
   ィルタとして設定しているくじ購入者の端末が、イベン
   トとして送信された前記当選通知情報を前記意味情報ネ
   ットワークから受信するステップと、 前記当選通知情報をイベントとして受信した前記くじ購
   入者の端末が、前記くじ主催者の端末に購入したくじが
   当選した旨を申し出るステップとを有する、意味情報ネ
   ットワークを用いたくじ運用方法。
2. 【請求項２】 データをイベントとして送信する送信端
   末と、イベントとして送信された前記データを選択的に
   受信するために、イベントのタイプと取得条件とからな
   るフィルタが設定される受信端末とから構成される意味
   情報ネットワークを用いて、くじの購入を希望するくじ
   購入者が、くじの販売を行っているくじ主催者からくじ
   を購入し、くじの抽選が行われ当選したくじが決定した
   場合には、その当選したくじを購入したくじ購入者に対
   して、購入したくじが当選した旨を通知する、意味情報
   ネットワークを用いたくじ運用方法であって、 前記くじ主催者の端末が、購入するくじの枚数である購
   入希望枚数と購入を希望するくじの種類からなるくじ購
   入条件と、前記くじ購入者の端末により生成された、く
   じの購入者を特定することができないようなくじ購入者
   宛先名の情報とを含んだくじ購入要求メッセージを、発
   信者を特定することができない通信手段により、前記く
   じ主催者の端末から受信するステップと、 前記くじ購入要求メッセージを受信したくじ主催者の端
   末が、受信したくじ購入要求メッセージに含まれている
   購入希望枚数に応じた枚数のくじを発行し、発行したく
   じ番号および当該くじがくじ主催者が発行した正規のく
   じであることを証明するための情報である主催者発行証
   明を含んだくじ発行情報を、受信したくじ購入要求メッ
   セージに含まれていたくじ購入者宛先名を条件としたイ
   ベントとして前記意味情報ネットワークに対して送信す
   るステップと、 前記くじ主催者の端末が、くじの抽選が行われ当選した
   くじ番号が決定されると、該当選番号およびくじの種類
   を特定するための情報を条件とした当選通知情報をイベ
   ントとして前記意味情報ネットワークに送信するステッ
   プとを有する、意味情報ネットワークを用いたくじ運用
   方法。
3. 【請求項３】 データをイベントとして送信する送信端
   末と、イベントとして送信された前記データを選択的に
   受信するために、イベントのタイプと取得条件とからな
   るフィルタが設定される受信端末とから構成される意味
   情報ネットワークを用いて、くじの購入を希望するくじ
   購入者が、くじの販売を行っているくじ主催者からくじ
   を購入し、くじの抽選が行われ当選したくじが決定した
   場合には、その当選したくじを購入したくじ購入者に対
   して、購入したくじが当選した旨を通知する、意味情報
   ネットワークを用いたくじ運用方法であって、 前記くじ購入者の端末が、くじの購入者を特定すること
   ができないようなくじ購入者宛先名を生成し、該くじ購
   入者宛先名をイベントの取得条件としたフィルタを前記
   意味情報ネットワークに設定するステップと、 前記くじ購入者の端末が、購入するくじの枚数である購
   入希望枚数と購入を希望するくじの種類からなるくじ購
   入条件と、前記くじ購入者宛先名の情報とを含んだくじ
   購入要求メッセージを、発信者を特定することができな
   い通信手段により、前記くじ主催者の端末に送信するス
   テップと、 くじ購入者宛先名を取得条件とするフィルタを設定して
   いる前記くじ購入者の端末が、前記くじ購入要求メッセ
   ージを受信したくじ主催者の端末によりイベントとして
   送信され、受信したくじ購入要求メッセージに含まれて
   いたくじ購入者宛先名を条件とした、受信したくじ購入
   要求メッセージに含まれている購入希望枚数に応じた枚
   数だけ発行されたくじの番号および当該くじがくじ主催
   者が発行した正規のくじであることを証明するための情
   報である主催者発行証明を含んだくじ発行情報を前記意
   味情報ネットワークから受信し、受信したイベントに含
   まれるくじ番号および該くじの種類を特定するための情
   報をフィルタとして前記意味情報ネットワークに設定す
   るステップと、 くじ番号および該くじの種類を特定するための情報をフ
   ィルタとして設定しているくじ購入者の端末が、くじの
   抽選が行われ当選したくじ番号が決定された後に前記く
   じ主催者の端末によりイベントとして送信された該当選
   番号およびくじの種類を特定するための情報を条件とし
   た当選通知情報を、前記当選通知情報を前記意味情報ネ
   ットワークから受信するステップと、 前記当選通知情報をイベントとして受信した前記くじ購
   入者の端末が、前記くじ主催者の端末に購入したくじが
   当選した旨を申し出るステップとを有する、意味情報ネ
   ットワークを用いたくじ運用方法。
4. 【請求項４】 データをイベントとして送信する送信端
   末と、イベントとして送信された前記データを選択的に
   受信するために、イベントのタイプと取得条件とからな
   るフィルタが設定される受信端末とから構成される意味
   情報ネットワークを用いて、くじの購入を希望するくじ
   購入者が、くじの販売を行っているくじ主催者からくじ
   を購入し、くじの抽選が行われ当選したくじが決定した
   場合には、その当選したくじを購入したくじ購入者に対
   して、購入したくじが当選した旨を通知する、意味情報
   ネットワークを用いたくじ運用システムであって、 くじの購入者を特定することができないようなくじ購入
   者宛先名を生成し、該くじ購入者宛先名をイベントの取
   得条件としたフィルタを前記意味情報ネットワークに設
   定し、購入するくじの枚数である購入希望枚数と購入を
   希望するくじの種類からなるくじ購入条件と、前記くじ
   購入者宛先名の情報とを含んだくじ購入要求メッセージ
   を、発信者を特定することができない通信手段により前
   記くじ主催者の端末に送信し、前記くじ購入要求メッセ
   ージを受信したくじ主催者の端末により発行されたくじ
   の番号および当該くじがくじ主催者が発行した正規のく
   じであることを証明するための情報である主催者発行証
   明を含んだくじ発行情報を前記意味情報ネットワークか
   ら受信し、受信したイベントに含まれるくじ番号および
   該くじの種類を特定するための情報をフィルタとして前
   記意味情報ネットワークに設定し、くじの抽選が行われ
   当選したくじ番号が決定された後に前記くじ主催者の端
   末によりイベントとして送信された該当選番号およびく
   じの種類を特定するための情報を条件とした当選通知情
   報を、前記当選通知情報を前記意味情報ネットワークか
   ら受信し、前記くじ主催者の端末に購入したくじが当選
   した旨を申し出るくじ購入者の端末と、 前記くじ購入要求メッセージを、発信者を特定すること
   ができない通信手段により、前記くじ購入者の端末から
   受信し、受信した該くじ購入要求メッセージに含まれて
   いる購入希望枚数に応じた枚数のくじを発行し、発行し
   たくじ番号および当該くじがくじ主催者が発行した正規
   のくじであることを証明するための情報である主催者発
   行証明を含んだくじ発行情報を、受信したくじ購入要求
   メッセージに含まれていたくじ購入者宛先名を条件とし
   たイベントとして前記意味情報ネットワークに対して送
   信し、くじの抽選が行われ当選したくじ番号が決定され
   ると、該当選番号およびくじの種類を特定するための情
   報を条件とした当選通知情報をイベントとして前記意味
   情報ネットワークに送信するくじ主催者の端末と、から
   構成されるくじ運用システム。
5. 【請求項５】 データをイベントとして送信し、イベン
   トとして送信された前記データを選択的に受信するため
   に、イベントのタイプと取得条件とからなるフィルタが
   設定されている複数の端末とから構成される意味情報ネ
   ットワークに対して、データをイベントとして送信する
   送信端末であって、 購入するくじの枚数である購入希
   望枚数と購入を希望するくじの種類からなるくじ購入条
   件と、くじの購入者を特定することができないようなく
   じ購入者宛先名の情報とを含んだくじ購入要求メッセー
   ジを、発信者を特定することができない通信手段によ
   り、前記くじ購入者の端末から受信し、受信した該くじ
   購入要求メッセージに含まれている購入希望枚数に応じ
   た枚数のくじを発行し、発行したくじ番号および当該く
   じがくじ主催者が発行した正規のくじであることを証明
   するための情報である主催者発行証明を含んだくじ発行
   情報を、受信したくじ購入要求メッセージに含まれてい
   たくじ購入者宛先名を条件としたイベントとして前記意
   味情報ネットワークに対して送信し、くじの抽選が行わ
   れ当選したくじ番号が決定されると、該当選番号および
   くじの種類を特定するための情報を条件とした当選通知
   情報をイベントとして前記意味情報ネットワークに送信
   するくじ主催者の送信端末。
6. 【請求項６】 送信端末からイベントとして送信された
   データを、意味情報ネットワークを介して選択的に受信
   するためにイベントのタイプと取得条件とからなるフィ
   ルタが設定されている受信端末であって、くじの購入者
   を特定することができないようなくじ購入者宛先名を生
   成し、該くじ購入者宛先名をイベントの取得条件とした
   フィルタを前記意味情報ネットワークに設定し、購入す
   るくじの枚数である購入希望枚数と購入を希望するくじ
   の種類からなるくじ購入条件と、前記くじ購入者宛先名
   の情報とを含んだくじ購入要求メッセージを、発信者を
   特定することができない通信手段により前記くじ主催者
   の端末に送信し、前記くじ購入要求メッセージを受信し
   たくじ主催者の端末により発行されたくじの番号および
   当該くじがくじ主催者が発行した正規のくじであること
   を証明するための情報である主催者発行証明を含んだく
   じ発行情報を前記意味情報ネットワークから受信し、受
   信したイベントに含まれるくじ番号および該くじの種類
   を特定するための情報をフィルタとして前記意味情報ネ
   ットワークに設定し、くじの抽選が行われ当選したくじ
   番号が決定された後に前記くじ主催者の端末によりイベ
   ントとして送信された該当選番号およびくじの種類を特
   定するための情報を条件とした当選通知情報を、前記当
   選通知情報を前記意味情報ネットワークから受信し、前
   記くじ主催者の端末に購入したくじが当選した旨を申し
   出るくじ購入者の受信端末。