JP2003044502A - オントロジー対応情報生成装置、方法、プログラム、記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 特定のオントロジー体系に基づいた情報を他
のオントロジー体系の情報に変換するオントロジー対応
情報を生成するオントロジー対応情報生成装置、方法、
プログラム、記録媒体を提供する。 【解決手段】 意味情報体系取得部１５は、対応元のイ
ベントプレースと対応先のイベントプレースから、オン
トロジーを取得する。オントロジー対応情報生成部１６
は、対応元のオントロジーのスロットと対応先のオント
ロジーのスロットの類似度を、各々のスロットの組み合
わせについて算出し、特定値以上の類似度を算出するス
ロットの組み合わせを取得し、さらに、対応元のオント
ロジーのクラスと対応先のオントロジーのクラスの類似
度を、クラス名と、取得したスロットの組み合わせの類
似度とを用いて各々のクラスの組み合わせについて算出
し、特定の値以上の類似度を算出するクラスの組み合わ
せを取得する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、異なるオントロジ
ー間の対応関係を記述するオントロジー対応情報を自動
生成する方法、また、ある特定のオントロジーに基づい
て記述された情報を、該オントロジーとは異なる別のオ
ントロジーに基づいた情報へと自動変換するオントロジ
ー対応情報生成装置、方法、プログラム、記憶媒体に関
するものである。

【０００２】

【従来の技術】近年の急速なインターネットの普及に伴
い、あらゆる情報源がインターネットに接続されるよう
になってきている。このような複数の情報源から取得し
た情報を容易に統合することができれば、膨大かつリア
ルタイム性に優れた情報を用いた、より柔軟かつ高度な
情報活用が可能となる。

【０００３】しかし、これらの情報源は、あらかじめ規
定された規則に基づいてトップダウン的に構築されたも
のではなく、多種多様な設計思想、言語、オントロジー
（「概念化の明示的な規約」のこと）、フォーマット等
に基づいてボトムアップ的に構築されたものである。つ
まり、分散しているというだけではなく、ヘテロである
という特徴を有しているため、情報を統合する際には、
このような情報源ごとの違いに対処する仕組みが必要で
ある。

【０００４】特に、オントロジーの異なる情報を統合す
ることに関しては、コンピュータ等による自動化が困難
であり、従来、人間が手動で統合を行うしか方法がなか
った。しかし、近年、その負担を軽減することを目的と
して、異なるオントロジー間の対応関係を自動生成可能
な技術として「EBFM(Example Based Frame Mapping)
（伊藤史朗 上田隆也 池田裕治、“分散情報源に対する
情報エージェントのための事例に基づくフレームマッピ
ング”、電子情報通信学会論文誌 D-I Vol．J81-D-I
No．5 pp．433-442 1998年5月）」と「オントロジ
ー対応付け情報生成装置（特開2001-14166）」が発表さ
れている。

【０００５】「EBFM」は、フレーム形式において、同じ
属性を表現しているスロットを自動的に対応付ける、事
例ベースのフレームマッピング方法であり、語彙レベル
で異なるオントロジーを自動統合できる技術である。
「オントロジー対応付け情報生成装置」は、複数のオン
トロジーのノード情報を抽出し、知識処理部の知識を活
用してそれらノード情報単位の対応付けを行う技術であ
る。

【０００６】

【発明が解決しようとする課題】従来の技術には、以下
の課題がある。まず、「EBFM」は事例ベースのマッピン
グ方式であるため、複数のインスタンスの事例を用意す
る必要があるのと同時に、同一の対象を表現している事
例の存在に依存する面が大きいという課題を有してい
る。また、スロット間類似度の算出に最適照合検索を利
用しているため、あらかじめ背景知識を用意しておかな
くて良いという利点を有しているものの、類似度の正確
さに欠けるという課題を有している。

【０００７】次に、「オントロジー対応付け情報生成装
置」は、オントロジーの対応付け処理において用いられ
るであろう知識の例や、EDRなどの意味辞書の利用に関
する言及はあるものの、実際に知識をどう活用するの
か、EDRをどう利用するのか、等々具体的な実装に関す
る記載が不十分であるため、実施が困難であるという課
題を有している。

【０００８】本発明はこのような課題に鑑みてなされた
ものであり、インスタンスの事例を用いなくとも、異な
るオントロジー間の対応関係を記述するオントロジー対
応情報を自動生成することが可能なオントロジー対応情
報生成装置、方法、プログラム、記憶媒体を提供するこ
とを目的とする。また、該オントロジー対応情報を用い
て、自動でオントロジー変換を行うことも可能となる。
ここでオントロジー変換とは、ある特定のオントロジー
に基づいて記述された情報を、該オントロジーとは異な
る別のオントロジーに基づいた情報へと変換することを
いう。

【０００９】

【課題を解決するための手段】本発明は上記の目的を達
成するためになされたもので、本発明は、異なるオント
ロジー間の対応関係を記述するオントロジー対応情報を
生成するオントロジー対応情報生成装置であって、少な
くともクラス名、複数のスロットを含む対応元オントロ
ジーと、少なくともクラス名、複数のスロットを含む対
応先オントロジーを取得する意味情報体系取得部と、前
記対応元のオントロジーのスロットと前記対応先のオン
トロジーのスロットの類似度を、各々のスロットの組み
合わせについて算出し、特定値以上の類似度を算出する
スロットの組み合わせを取得し、前記対応元のオントロ
ジーのクラスと前記対応先のオントロジーのクラスの類
似度を、少なくともクラス名と、前記取得したスロット
の組み合わせの類似度とを用いて各々のクラスの組み合
わせについて算出し、特定の値以上の類似度を算出する
クラスの組み合わせを取得するオントロジー対応情報生
成部とを備えることを特徴とする。

【００１０】また、本発明は、異なるオントロジー間の
対応関係を記述するオントロジー対応情報を生成するオ
ントロジー対応情報生成装置であって、少なくともクラ
ス名、複数のスロットを含む対応元オントロジーと、少
なくともクラス名、複数のスロットを含む対応先オント
ロジーを取得する意味情報体系取得部と、前記対応元の
オントロジーのクラスと前記対応先のオントロジーのク
ラスの類似度を、少なくともクラス名を用いて各々のク
ラスの組み合わせについて算出し、特定の値以上の類似
度を算出するクラスの組み合わせを取得し、前記対応元
のオントロジーのスロットと前記対応先のオントロジー
のスロットの類似度を、前記決定したクラスの組み合わ
せごとに各々のスロットの組み合わせについて算出し、
特定値以上の類似度を算出するスロットの組み合わせを
取得するオントロジー対応情報生成部とを備えることを
特徴とする。

【００１１】また、本発明は、異なるオントロジー間の
対応関係を記述するオントロジー対応情報を生成するオ
ントロジー対応情報生成方法であって、少なくともクラ
ス名、複数のスロットを含む対応元オントロジーと、少
なくともクラス名、複数のスロットを含む対応先オント
ロジーを取得する過程と、前記対応元のオントロジーの
スロットと前記対応先のオントロジーのスロットの類似
度を、各々のスロットの組み合わせについて算出し、特
定値以上の類似度を算出するスロットの組み合わせを取
得する過程と、前記対応元のオントロジーのクラスと前
記対応先のオントロジーのクラスの類似度を、少なくと
もクラス名と、前記取得したスロットの組み合わせの類
似度とを用いて各々のクラスの組み合わせについて算出
し、特定の値以上の類似度を算出するクラスの組み合わ
せを取得する過程とを特徴とする。

【００１２】また、本発明は、異なるオントロジー間の
対応関係を記述するオントロジー対応情報を生成するオ
ントロジー対応情報生成方法であって、少なくともクラ
ス名、複数のスロットを含む対応元オントロジーと、少
なくともクラス名、複数のスロットを含む対応先オント
ロジーを取得する過程と、前記対応元のオントロジーの
クラスと前記対応先のオントロジーのクラスの類似度
を、少なくともクラス名を用いて各々のクラスの組み合
わせについて算出し、特定の値以上の類似度を算出する
クラスの組み合わせを取得する過程と、前記対応元のオ
ントロジーのスロットと前記対応先のオントロジーのス
ロットの類似度を、前記決定したクラスの組み合わせご
とに各々のスロットの組み合わせについて算出し、特定
値以上の類似度を算出するスロットの組み合わせを取得
する過程とを特徴とする。

【００１３】また、本発明は、異なるオントロジー間の
対応関係を記述するオントロジー対応情報を生成するオ
ントロジー対応情報生成プログラムであって、少なくと
もクラス名、複数のスロットを含む対応元オントロジー
と、少なくともクラス名、複数のスロットを含む対応先
オントロジーを取得するステップと、前記対応元のオン
トロジーのスロットと前記対応先のオントロジーのスロ
ットの類似度を、各々のスロットの組み合わせについて
算出し、特定値以上の類似度を算出するスロットの組み
合わせを取得するステップと、前記対応元のオントロジ
ーのクラスと前記対応先のオントロジーのクラスの類似
度を、少なくともクラス名と、前記取得したスロットの
組み合わせの類似度とを用いて各々のクラスの組み合わ
せについて算出し、特定の値以上の類似度を算出するク
ラスの組み合わせを取得するステップとをコンピュータ
に実行させるオントロジー対応情報生成プログラムであ
る。

【００１４】また、本発明は、異なるオントロジー間の
対応関係を記述するオントロジー対応情報を生成するオ
ントロジー対応情報生成プログラムであって、少なくと
もクラス名、複数のスロットを含む対応元オントロジー
と、少なくともクラス名、複数のスロットを含む対応先
オントロジーを取得するステップと、前記対応元のオン
トロジーのクラスと前記対応先のオントロジーのクラス
の類似度を、少なくともクラス名を用いて各々のクラス
の組み合わせについて算出し、特定の値以上の類似度を
算出するクラスの組み合わせを取得するステップと、前
記対応元のオントロジーのスロットと前記対応先のオン
トロジーのスロットの類似度を、前記決定したクラスの
組み合わせごとに各々のスロットの組み合わせについて
算出し、特定値以上の類似度を算出するスロットの組み
合わせを取得するステップとをコンピュータに実行させ
るオントロジー対応情報生成プログラムである。

【００１５】また、本発明は、請求項５又は請求項６に
記載のプログラムを記録したコンピュータ読み取り可能
な記録媒体である。

【００１６】これにより、転送元のオントロジーのクラ
スと転送先のオントロジーのクラスの対応関係を示す情
報と、転送元のオントロジーのスロットと転送先のオン
トロジーのスロットの対応関係を示す情報とが取得でき
る。このように取得したオントロジー対応情報を用い
て、例えば、オントロジー変換を自動で行うことができ
る。

【００１７】

【発明の実施の形態】以下、本発明をSIONに適用した場
合の実施の形態の一例を、図面を参照して説明する。 ＜非ブローカモデルとSION＞従来ネットワークは、図１
６に示すネットワークモデルにより概念的に表現され
る。図１６において、各端末は、端末アドレス（例え
ば、ネットワークアドレスとホストアドレス）を自身の
識別子としてネットワークに登録する。一方、送信端末
は、図１７に示す宛先アドレス（送信先の端末アドレ
ス）とデータから構成されるイベント（パケット）をネ
ットワークに送出する。すなわち、従来の情報ネットワ
ークの基本概念は、宛先アドレスに基づいて、イベント
を目的地まで正しく配送することにある。

【００１８】このネットワークを用いて、提案型サービ
ス（ユーザ毎にパーソナライズされた情報を提案するパ
ーソナライズ情報提案サービス、および、検索サービス
などのイエローページサービス）を実現する場合を考え
る。従来は、パーソナライズ情報提案サービスを実現す
るために、図１８に示すような集中型のサーバシステム
（ブローカ）を常に介在させる必要がある。同様に、イ
エローページサービスにおいても、検索サービスと呼ば
れるブローカ（仲介者）を前提とする必要がある。この
ようなブローカを介した中央集権的なビジネスモデル
を、ブローカモデルと呼ぶ。このブローカモデルでは、
ブローカが情報提供者とユーザを結びつける役割を担
う。すなわち、ブローカを介してのみユーザと情報提供
者が出会うことが可能である。

【００１９】図１９を用いて、上記ブローカモデルの詳
細な説明を行う。図１９に示すように、エンドユーザ
（図中ではコンシューマ１０１）、情報提供者（コンテ
ンツプロバイダ１０２）に加えて、サービスプロバイダ
（コンテンツ情報プロバイダ）１０３の３つのビジネス
ロールから構成されるビジネスモデルにおいて、サービ
スプロバイダ１０３は、情報提供者（コンテンツプロバ
イダ１０２）から登録されるコンテンツ情報、及びエン
ドユーザ（コンシューマ１０１）から登録されるエンド
ユーザ嗜好情報を管理するとともに、登録されたコンテ
ンツ情報とエンドユーザ嗜好情報を照合することによ
り、エンドユーザ（コンシューマ１０１）に相応しいコ
ンテンツを提案する提案型サービスが実現されていた。
このようなサービスプロバイダがブローカに相当する。

【００２０】具体的なサービスとしては、ヤフー（Ｙａ
ｈｏｏ）等の検索サービス、トレーディングサービス、
エンドユーザの直接的な介在なしに、エンドユーザの興
味に合致するコンテンツを提案するパーソナライズ情報
提案サービスがある。これらのサービスは、図２０に示
すように、ネットワーク網１０９、もしくはコンテンツ
流通網１１０上に存在する個々のサービスプロバイダ１
０３において、それぞれ一体型のサービスシステム（サ
ービスアプリケーション）として実現されていた。

【００２１】これらに起因して、ブローカモデルでは、
次のような問題点があった。 （１） 情報提供者（コンテンツプロバイダ１０２）
が、第三者を介在せずにエンドユーザ（コンシューマ１
０１）に対してコンテンツ情報をアナウンスする手段が
存在しなかったため、情報提供者（コンテンツプロバイ
ダ１０２）自身がコンテンツ情報を流通させる情報提供
者（コンテンツプロバイダ）主導型の御用聞き社会を実
現することができなかった。すなわち、コンテンツの提
供元である情報提供者（コンテンツプロバイダ１０２）
は、第三者を介在することなく自身のポリシでコンテン
ツ情報を流通させることができなかった。

【００２２】（２）サービスプロバイダ１０３の提案サ
ービスを享受するためには、サービスプロバイダ１０３
の存在、位置、及びアクセス方法を、エンドユーザ（コ
ンシューマ１０１）が明示的に認識しなければならなか
った。 （３）異なるサービスプロバイダ１０３間で、コンテン
ツ、コンテンツ情報、エンドユーザ嗜好情報を共有する
ことを容易に実現できなかった。これまでは、個々のサ
ービスプロバイダ１０３間で事前に取り決めたプロトコ
ルに従って、情報のやり取りを行うことにより、情報を
共有していた。

【００２３】（４）サービスプロバイダ１０３における
コンテンツ情報及びエンドユーザ嗜好情報の集中管理に
起因して、スケラビリティの高いシステムを構築するこ
とが容易ではなかった。これまでは、コンテンツ情報及
びエンドユーザ嗜好情報を管理するサーバシステムを複
数用意する等の古典的な手法が用いられてきた。

【００２４】ところで、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ
Ｗｅｂ）、ＣＯＲＢＡなどの分散処理技術は、異機種分
散システム上に分散配置されたコンテンツを居ながらに
して簡単に入手できる環境を提供するとともに、誰もが
容易にコンテンツ提供者になれることを可能にした。そ
の反面、世界中に氾濫する膨大なコンテンツの中から、
エンドユーザが所望するコンテンツを見つけ出すことは
容易でなく、そのための実現技術の早期確立が望まれて
いる。

【００２５】このような事情や上記ブローカモデルの問
題点に鑑み、情報提供者（コンテンツプロバイダ）が、
ブローカの存在を仮定することなく自身のコンテンツに
相応しいエンドユーザに対して、直接コンテンツを提供
することが可能な非ブローカモデルが提唱された。非ブ
ローカモデルの実現技術として、Ｇｎｕｔｅｌｌａ、Ｓ
ＵＮによる発明（US Patent 5、870、605：文献１）、
ＮＥＣによる発明（特開２０００−１６５４４９：文献
２）がある。

【００２６】Ｇｎｕｔｅｌｌａは、Ｐ２Ｐ（Peer-to-Pe
er）インタラクションモデルに基づいて、インターネッ
ト上に分散する不特定多数のエンティティ（情報）の中
から、特定のエンティティを探索・発見するネットワー
クである。なお、Ｇｎｕｔｅｌｌａではエンティティの
ことをサーバントとも呼ぶ。すなわち、個々の情報提供
者がメタデータ（メタファイル）を超分散管理し、メタ
ファイル間（メタファイルが格納されているホスト間）
に任意のコネクションを設定することにより、情報提供
者のみでメタデータに関する超分散データベースを構築
する。そして、情報提供者同士が互いに分散協調するこ
とにより、ブローカを必要としない、メタデータの検索
ネットワークの構築を可能にした。

【００２７】しかしながら、消費者からの検索要求パケ
ットが、コネクションに基づいて全ての情報提供者に対
してブロードキャストされる。すなわち、Ｐ２Ｐ方式の
インタラクションを、コネクション情報に基づき、全て
のホストに対して繰り返すため、ホスト数や扱うメタデ
ータ種別の増加に比例して、不要なトラフィックが増大
し、スケラビリティが極端に低下する問題がある。さら
に、スケラビリティのみでなく、相互運用性、情報共有
性、拡張性、セキュリティ、プライバシなどの面におい
ても問題を有している。

【００２８】文献１は、内容ベースのルーティングを行
うネットワークシステムによって、情報提供者（Ｐｕｂ
ｌｉｓｈｅｒ）とユーザ（Ｓｕｂｓｃｒｉｂｅｒ）が互
いに相手に関する知識を有していない状況において、情
報の要求と利用をブローカ不在で可能とする方法を示し
た。しかしながら、不要なイベント転送を抑止するよう
なルーティングの仕組みを有していないため、スケラビ
リティに問題がある。さらに、テリトリ間のオントロジ
ー（イベント辞書を変換する仕組みなど）を有していな
いため、相互運用性、情報共有性、拡張性などの面にお
いても問題を有している。すなわち、文献１では、共通
のイベント辞書（event dictionary）を共有するテリト
リという概念を規定しているが、テリトリの実現方法
や、異なるテリトリ間で情報を共有するための方法が明
確化されていない。そのため、テリトリに関しては具体
的実現性の記述に乏しい。

【００２９】文献２は、特定の宛先アドレスを有するパ
ケットのみならず、関心領域の指定を含むだけのパケッ
トもルーティングすることが可能な情報ルーティングを
提案している。情報ルーティングによって、ブローカを
必要としない探索が実現できる。しかしながら、オント
ロジーの一意性やイベントの波及範囲を限定するイベン
トプレースや、ゲートウェイ、セッションという概念が
ない。そのため、スケラビリティ、セキュリティ、プラ
イバシ、相互運用性、情報共有性、拡張性などの面にお
いて問題を有している。

【００３０】このように、従来の非ブローカモデルの実
現技術は、大きく分けて以下の４つの課題を有してい
る。 ○セキュリティとプライバシの保護の欠如 ・情報を流通させる範囲を限定する機構がない。つま
り、イベントの波及先の限定が行えない。そのために、
ネットワークに接続している人であれば誰でも情報を見
ることが可能になる。 ・また、情報の終端点が、エンドユーザの端末となり、
外部からこれを参照可能である。そのために、外部に公
開を望まない情報の載っている端末であっても、ネット
ワークに接続する場合は、情報を公開する可能性があ
る。 ・セッションの概念がないため、イベント送受信端末の
みでのネットワーク構築はできるが、ネットワークプロ
バイダ（運営者）とイベント送受信者を分離できない。

【００３１】○相互運用性の欠如 ・意味情報体系（オントロジー）が異なる領域を作る場
合は、それらの領域を接続する仕組みを有していないた
め、それらの間でのイベントの共有ができない。 ・必要なイベントのみの転送ができない。

【００３２】○拡張性の欠如 ・動的な機能の追加・削除が困難である。 ・ネットワーク規模を拡張することが容易でない。 ○スケラビリティの欠如 ・イベントの送受信者数の増大に対処できない。 ・意味情報種別（メタデータ種別）の増大に対処できな
い。 ・不要なイベント転送を抑止できない。

【００３３】SIONは、このような課題を克服するもので
あり、ネットワーク上に分散する膨大な情報の中から、
エンドユーザが最適な情報を直接特定することができ、
あるいは、情報提供者が情報を配布すべき最適なユーザ
を直接特定することができ、さらに、ブローカを介する
ことなく、コミュニケートすべきエンティティを、直
接、探索・発見・特定することを可能とする。

【００３４】＜意味情報と意味情報ネットワークＳＩＯ
Ｎ＞まず、意味情報ネットワーク（Semantic Informati
on-Oriented Network、以下、ＳＩＯＮと称する）につ
いて概要を説明する。ＳＩＯＮは、意味情報に基づい
て、イベントを目的地まで配送することが可能なネット
ワークである。図１に、ＳＩＯＮの概念モデルを示す。
図１において、各端末２は、意味情報（Semantic Infor
mation：ＳＩ）をＳＩＯＮ１に対して登録する。一方、
イベントを送信する端末２は、図２に示す意味情報とデ
ータ（Data）から構成されるイベントをＳＩＯＮ１に送
出する。

【００３５】ここでいう、意味情報とは、イベントに含
まれるデータの特性を記述したものであり、データのメ
タ情報として位置づけられる。例えば、意味情報は、 ・データを"東京在住者"に配送する。 ・データを"クラシックに興味のある人"に配送する。 ・データを"１Ｍｂｐｓ以上の通信環境を有する人"に配
送する。 ・データを"目白通りを通行中の人"に配送する。 ・データを"キーワード（例えば旅行）に合致するコン
テンツを有するコンテンツプロバイダ"に配送する。 等の表現が用いられる。

【００３６】ＳＩＯＮは、上述したような意味情報に基
づいて、データを配送すべき対象（端末、人、ソフトウ
エアなど）を動的に決定し、特定された対象者に対し
て、データの配送および通知を行うことが可能な自律分
散型のメタネットワークである。図２１はＳＩＯＮ（図
中のコンテンツ情報流通網（自律分散照合環境）１２
３）の位置づけを示す。ＳＩＯＮを用いることにより、
ブローカ（第三者のサービスプロバイダとして実現され
ることが多い）を介することなく、情報提供者（図中の
コンテンツプロバイダ１１０）が提供するに相応しいユ
ーザ（図中のコンシューマ（エンドユーザ）１１１）に
対してのみ、自身の情報を直接提案することが可能にな
る。また、従来のブロードキャスト型のみの照合に対し
て、マルチキャスト型の照合形態をも実現できる。

【００３７】このような、ブローカ非介在型（非ブロー
カモデル）でpeer-to-peerの情報提案が可能なビジネス
モデルを、ここでは、御用聞き型モデル（または、御用
聞き型情報提案モデル）と呼ぶ。同様に、検索サービス
（ブローカ）を介することなく、ユーザが希望する情報
を直接探索可能な、リアルタイム情報検索も可能であ
る。このビジネスモデルを御用聞き型モデルに対して、
御問い合せ型モデルという。この両者の違いは、イベン
トの方向性の違いである。

【００３８】図２１において、ＳＩＯＮはネットワーク
網１２１上に御用聞き社会を構築するために、コンテン
ツ情報の照合を行うことを目的とした、仮想的なネット
ワーク網であり、コンテンツ流通網１２２の上位レイヤ
に位置づけられる。なお、御用聞き型情報提案サービス
として、以下のサービス等に適用することが可能であ
る。 （１）製造会社：自社製品に興味を持ってくれそうなお
客様を中心に製品案内を送りたい。 （２）広告主：お客様ごとにパーソナライズされた広告
を送りたい。 （３）物々交換：ユーザ間の合意に基づいて、製品を売
買したり、交換したい。

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

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

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

【００４２】次に、イベントタイプについて説明する。
図５に、イベントのテンプレートであるイベントタイプ
の定義例を示す。なお、イベントタイプは、イベントと
意味情報との関係から、意味情報のテンプレートとも言
うことができる。図５に示すように、イベントタイプ
は、イベントタイプ名（Event type name）と条件名
（図５においては、"Service"や"CPU power"が相当す
る）、およびそれぞれの条件名に対するデータ型（Stri
ngやlongが相当する）と条件式（＝＝や＞＝が相当す
る）が定義されたものである。イベントタイプ名は、イ
ベントタイプを一意に識別するための名称である。

【００４３】なお、必要に応じて項目“Inherited even
t type”に継承するイベントタイプ名を指定する値を設
定することにより、イベントタイプの親タイプも継承可
能である。図６に示すように、イベントタイプのデータ
構造に従って、イベントを作成する。イベントは、イベ
ントタイプ名、条件名と条件値の組み合わせ、および、
データ部から構成される。イベントの中で定義された条
件名、条件式、条件値が、イベントタイプと一致しない
場合は、エラーになる。但し、イベントの中で使用され
る条件名は、イベントタイプのサブセットでも良い。

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

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

【００４６】意味情報スイッチ（ＳＩ−ＳＷ）は、フィ
ルタとして登録された意味情報と、イベントに付与され
た意味情報を照合し、その結果、発火したイベント受信
者の端末２を起動するスイッチング機構を提供する。意
味情報スイッチ（ＳＩ−ＳＷ）と各端末２はスター型で
結合される。意味情報ルータ（ＳＩ−Ｒ）は、意味情報
スイッチ間のイベント経路選択を行うとともに、端末２
から意味情報スイッチに対して送出されたイベントを他
の意味情報スイッチに転送する役割を担う。これは、意
味情報に基づく動的なイベントルーティングにより達成
される。

【００４７】意味情報ゲートウェイ（ＳＩ−ＧＷ）は、
イベントプレース（EP: Event Place）間でのイベント
の転送を行う。イベントプレースは、イベントの照合す
る場を提供し、共通の意味情報空間を保証する最小単位
（オントロジードメイン）であり、イベントの波及範囲
を限定する。イベントプレースがオントロジードメイン
であることは、イベントプレース内では、イベントタイ
プの名称、概念、語彙、意味、関連などのオントロジー
体系の一意性が保証され、共通のオントロジーに基づい
て意味情報が記述されることを意味し、イベント種別の
増大を防ぐ効果を有する。イベントの波及範囲を限定す
ることにより、図２１のネットワーク網１２１やコンテ
ンツ流通網１２２でつながるすべてのホスト・端末にイ
ベントを送信するような規模の増大を防ぐことができ
る。イベントプレースは、運営者、セキュリティ、サー
ビス、物理的サブネット等を単位に生成することができ
る。

【００４８】基本的には、イベント送信者の端末２から
送出したイベントは、イベントプレース内のみで流通す
るが、意味情報ゲートウェイ（ＳＩ−ＧＷ）を介するこ
とにより、異なるオントロジーを有するイベントプレー
ス間でのイベントの相互流通が可能になる。このとき、
意味情報ゲートウェイ（ＳＩ−ＧＷ）はイベントのオン
トロジー変換を行った後、異なるイベントプレースヘイ
ベントを転送する。

【００４９】＜ＳＩＯＮを使用するエンティティ：ＵＡ
とＣＡ＞ＳＩＯＮの使用例として、ＳＩＯＮ上で動作す
るエンティティ（ＵＡ、ＣＡ）について図２２を用いて
説明する。 （１）ユーザ・エージェント（ＵＡ） ユーザ・エージェントＵＡはエンドユーザの代理人であ
り、ＳＩＯＮを利用する一エンティティと位置づけられ
る。ＵＡは運用形態（御用聞き、御問い合せ）により、
イベント送信者、イベント受信者になり得る。前述した
ように、例えば、イベント受信者になる場合は、フィル
タとしてエンドユーザの嗜好に基づいたエンドユーザ嗜
好情報をイベントプレースに登録する。

【００５０】（２） コンテンツ・エージェント（Ｃ
Ａ） エンドユーザとＵＡの関係と同様に、コンテンツ・エー
ジェントＣＡは情報提供者（コンテンツプロバイダ）の
代理人で、ＳＩＯＮを利用する一エンティティである。
ＣＡもイベント送信者にもイベント受信者にもなり得
る。例えば、イベント送信者になる場合は、コンテンツ
キーワード（コンテンツ情報）をイベントの意味情報と
して、コンテンツ識別子をイベントのデータとして、イ
ベントの送信を行う。ここで、ＣＡは主に２つの使用形
態に大別される。１つは、サービスプロバイダ（コンテ
ンツ情報プロバイダ）の立場から使用されるＣＡであ
り、他方は、情報提供者としてのそれである。後者は、
情報提供者自身が、容易にコンテンツ情報プロバイダに
なるための手段として利用される。

【００５１】（３）照合の場とイベント受信者とイベン
ト送信者 ここの例で述べているイベント送信者であるＣＡとイベ
ント受信者であるＵＡにとって、ＥＰは、ＵＡが登録し
たフィルタに対して、ＣＡが送出したイベントを照合さ
せるための場を提供する。これにより、ＣＡ主導の御用
聞き型照合を実現できる。起動された個々のＵＡは、そ
れぞれ独立にイベントとして取得したコンテンツ識別子
を用いて、所望のコンテンツにアクセスすることができ
る。なお、ＣＡがコンテンツキーワードをフィルタとし
て登録し、一方、ＵＡがエンドユーザ嗜好情報をイベン
トとして送出することにより、ＵＡ主導の御問い合せ型
照合もＳＩＯＮを用いて容易に実現できる。また、図２
３にＳＩＯＮのビジネスモデルを示す。ＳＩＯＮは、基
本的にはサービスプロバイダ（コンテンツ情報プロバイ
ダ）もしくはコンテンツプロバイダにより運営される。

【００５２】＜イベントとフィルタ値の例＞ＳＩＯＮに
設定されるフィルタ及びイベントの使用例について説明
する。 （１）エンドユーザ嗜好属性とコンテンツ条件 ＳＩＯＮでコンテンツ情報を配送する場合を考える。つ
まり、取り扱う情報がコンテンツ情報である場合であ
り、エンドユーザがコンテンツを受信し、情報提供者が
イベントを送信する場合である。コンテンツ情報をコン
テンツ条件で、ユーザ嗜好情報をユーザ嗜好属性で表現
する。コンテンツ条件とは、コンテンツを提供するのに
相応しいエンドユーザ（ＵＡ）の条件を定義したもので
あり、一例として図２４のように記述できる。

【００５３】一方、エンドユーザ嗜好属性とは、ユーザ
（ＵＡ）の特性を定義したものであり、一例として図２
５のように記述できる。従来は、コンテンツ情報として
コンテンツ属性を、エンドユーザ嗜好情報としてエンド
ユーザ嗜好条件（検索条件）を用いることが一般的であ
った。しかしながら、コンテンツプロバイダが本当に相
応しいエンドユーザに対してのみコンテンツを提供する
御用聞き型に対しては、コンテンツ情報の提供に値する
エンドユーザの条件を記述し、エンドユーザ嗜好情報に
ＵＡの属性を記述する形態が、従来の形態と比較して御
用聞き型照合との親和性が高いことから、上述の表現を
新たに定義した。

【００５４】（２）イベントとフィルタの定義 コンテンツ・エージェントＣＡは、コンテンツ条件をイ
ベントとして送出する。このイベントの作成手順を以下
に示す。まず、図５に示すように、イベントのテンプレ
ートであるイベントタイプを定義する。ここで、イベン
トタイプ名は、イベントタイプを一意に識別するための
名称である。また、条件名、及び条件名に対するデータ
型と条件式を定義する。

【００５５】イベントタイプをイベントプレースに登録
する。イベントタイプのデータ構造に従って、イベント
を作成する（図６参照）。イベントは、イベントタイプ
名、条件名と条件値の組み合わせから成る。また、デー
タ部には、コンテンツ識別子が設定される。イベントを
イベントプレースに送出する。なお、イベントの中で定
義された条件名や条件式が、イベントタイプと一致しな
い場合は、送出エラーになる。但し、イベントの中で使
用される条件名は、イベントタイプのサブセットでも良
い。一方、ユーザ・エージェントＵＡはユーザ嗜好属性
をフィルタとして、イベントプレースに登録する。この
フィルタの作成手順を以下に示す。

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

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

【００５８】・イベントプレースファクトリの起動＆初
期化（図９（１）、図２６のステップＳ１） まず、ＳＩＯＮ運営者は、任意のホスト上にイベントプ
レースファクトリ（ＥＰＦ）を起動し、続いて、ＥＰＦ
の初期化を行う。この時、ＥＰＦに対して、イベントプ
レース（ＥＰ）を生成可能なホスト名、およびＥＰの実
行ファイルの格納先を与える。これらを、イベントプレ
ース生成情報と呼ぶ。ＳＩＯＮ運営者は、主に情報提供
者、もしくはサービスプロバイダ（Ｙａｈｏｏのような
コンテンツ情報プロバイダ）に相当する。・ イベントプレースの生成要求（図９（２）、図２６の
ステップＳ２） 次に、ＥＰを生成する者（以下、ＥＰ運営者）は、ＥＰ
Ｆに対して、ＥＰの生成を要求する。このとき、ＥＰ
名、およびＥＰ属性をＥＰ生成要求のパラメータとして
与える。ここで、ＥＰ属性とは、生成されたＥＰが、御
用聞き型モデル、もしくは、御問い合せ型モデルのどち
らの目的で使用されるかを表したものであり、イベント
の流れの方向性を表すものである。

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

【００６０】・イベントプレースの初期化要求（図９
（４）、図２６のステップＳ４） 次に、ＥＰ運営者は、ＥＰの初期化をＥＰＭＯに依頼す
る。このとき、シングルイベントプレースオブジェクト
もしくは、マルチプルイベントプレースオブジェクトの
指定を行う。さらに、イベントプレースオブジェクト等
を生成可能なホスト、及びイベントプレースオブジェク
ト等の実行ファイルの格納先を与える。これを、イベン
トプレースオブジェクト生成情報と呼ぶ。なお、これが
省略された場合には、イベントプレース生成情報が使用
される。

【００６１】マルチプルイベントプレース・オブジェク
トは、イベントプレース内でのイベント照合処理の負荷
分散によるスケラビリティ向上を目的として使用され
る。マルチプルイベントプレースオブジェクトを指定し
た場合には、イベントプレースオブジェクト（ＥＰＯ）
の物理リンク情報（トポロジ）も併せて与える必要があ
る。ここで、ＥＰＯの物理リンク情報は、任意のＥＰＯ
が他のどのＥＰＯの存在を知っているかを表現したもの
である。例えば、図１０に示すように、ＥＰＯ２・３２
は、ＥＰＯ１・３１、ＥＰＯ３・３３、ＥＰＯ４・３４
の存在を知っているが、ＥＰＯ３・３３はＥＰＯ２・３
２の存在しか知らないことを表現している。マルチプル
ＥＰＯは、ＥＰ内でのイベント照合処理の負荷分散によ
るスケラビリティ向上を目的としたものである。

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

【００６３】・イベントプレースに対するイベント送信
のためのセッション確立要求（図９（５）、図２６のス
テップＳ５） 次に、ＥＰにセッションの確立を要求する。ＥＰＭＯ
は、セッション要求毎にプロキシオブジェクト（ＰＯ）
を生成する。要求元へは、ＰＯの識別子であるセッショ
ン識別子を返却する。なお、ＥＰＭＯは、ＰＯの生成時
に、ＰＯに対して、どのＥＰＯを使用するか（どのＥＰ
Ｏとバインドするか）を指示する。この指示は、マルチ
プルＥＰＯにおいて必要となるが、バインドするＥＰＯ
の決定方法は、ＥＰＭＯのそれと同様である。ＥＰへの
セッション確立要求時に、イベント送信のためのセッシ
ョンであるか、イベント受信のためのセッションである
かを指定する必要がある。本例においては、イベント送
信のためのセッションを指定する。

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

【００６５】・イベントプレースに対するイベント受信
のためのセッション確立要求（図９（７）、図２６のス
テップＳ７） 次に、ＥＰに対してイベント受信のためのセッション確
立を要求する。このとき、セッション確立の要求者（イ
ベント受信オブジェクト）は、イベントの通知先である
イベント受信オブジェクトの識別子、および、イベント
の通知方法（発火型、ルックイン型）をパラメータとし
て与える。さらに、イベント受信であることもパラメー
タとして含んでもよい。続いて、ＥＰＭＯは、セッショ
ン要求毎にＰＯを生成する。要求元へは、セッション識
別子（ＰＯの識別子）を返却する。なお、ＥＰＭＯは、
ＰＯの生成時に、ＰＯに対して、使用するＥＰＯを指示
する。この指示は、マルチプルＥＰＯにおいて必要とな
るが、バインドするＥＰＯの決定方法は、ＥＰＭＯのそ
れと同様である。

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

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

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

【００６９】・イベントの照合依頼（図９（Ｂ）、図２
７のステップＳ１２） 次に、ＰＯはイベントをＥＰＯに転送する。このとき、
ＥＰＯがスレッドを生成する。なお、スレッドはイベン
ト毎に生成され、各スレッドはイベントの多重処理を行
う。 ・フィルタとの照合（図９（Ｃ）、図２７のステップＳ
１３） 次に、ＥＰＯにおいて、スレッドは、イベントとフィル
タを照合することにより、フィルタリング処理を行う。
これには、完全一致、部分一致、重みづけ一致などがあ
り、フィルタ値の設定時に指定することができる。 ・プロキシオブジェクトの起動（図９（Ｄ）、図２７の
ステップＳ１４） 次に、フィルタとの照合の結果、イベントがフィルタを
通過すると、対応するＰＯが起動されこのイベントを受
け取る。このとき、ＰＯは、受信したイベントのタイ
プ、値、イベントＩＤ等をＳＯに登録することが選択的
に可能である。これらの情報から、ＳＯはイベントの発
火率（イベントタイプ毎、イベント毎）や、ＥＰ内で流
行している評判の高いイベントを測定することが可能に
なる。

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

【００７１】＜フィルタの管理方法＞次に、各ＥＰＯに
おけるフィルタの管理方法を説明する。まず、イベント
受信のためのセッションを確立する。このとき、セッシ
ョン要求毎に一つのＰＯが生成され、このＰＯは任意の
一つのＥＰＯにバインドされる。このＥＰＯには、それ
ぞれ、一つのＦＦが付随している。これにより、ＰＯが
使用するＥＰＯが一意に決定され、以降の処理はすべ
て、ＰＯ（イベント受信用セッション）を介して行われ
る。次に、ＦＯを生成し、ＦＯに対してフィルタ値（受
信するイベントのタイプとその取得条件）を設定する。
続いて、ＦＯ識別子をパラメータとして、フィルタの登
録を行う。このとき、各フィルタには、ＦＯ識別子が格
納される。各ＥＰＯは、ＰＯを介して登録されたフィル
タを以下に示す規則に基づいて管理する。

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

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

【００７４】＜イベントルーティング方法：任意のトポ
ロジにおけるルーティング方法＞次に、イベントルーテ
ィング方法について説明する。ＥＰＯ（ＳＩ−ＳＷ）
は、イベントの送受信者をセッションを介してスター型
で収容する。さらに、ＥＰＯ（ＳＩ−ＳＷ）は、イベン
ト受信者が登録したフィルタと、イベント送信者が送出
したイベントを照合し、その結果、発火したフィルタに
対応するイベント受信者のみにイベントを通知する（合
致するイベント受信者にのみイベントを配送する）照合
スイッチである。

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

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

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

【００７８】以下にＳＩ−Ｒについて詳細を説明する。
まず、ＥＰの初期化時に、物理リンク情報（ＥＰＯのト
ポロジ）に基づいて、ＳＬＯが各ＥＰＯに付随して生成
される。例えば、図９において、ＥＰＯ２に対して３個
のＳＬＯが生成される。これらは、図中のＳＬＯ2、1、
ＳＬＯ2、3、ＳＬＯ2、4に対応する。このＳＬＯi、j
は、ＥＰＯjからＥＰＯiへのイベント転送を行うシェア
ードリンク（ＳＬ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）Ｂに対してフェデレーションを確立する場合を
考える。まず、イベントプレースＡに属するＦＡが、イ
ベントプレースＢに対して、フィルタを登録する。この
とき、イベントプレースＢに属するイベント送信者がイ
ベントを送出し、その結果、このフィルタが発火する
と、ＦＡが自律起動する。これは、ＦＡをイベントプレ
ースＢに属する一つのイベント受信者として見なすこと
ができる。次に、ＦＡは取得したイベントを、自身が属
するイベントプレースＡに対して再送出する。これは、
ＦＡを、イベントプレースＡに属する一つのイベント送
信者として見なすことができる。

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

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

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

【０１１４】＜オントロジー変換方法＞上記で述べた３
つのオントロジー変換方法に関して、より詳細な説明を
行い、それらの方法の比較を示す。 １．オントロジー変換方法１（標準オントロジーを利用
する） この方法は、標準オントロジー（グローバルな共通体
系）を規定し、それをイベントプレース間のフェデレー
ションに利用するものである。図３３は、本方法の仕組
みを表している。まず、この図は、イベントプレース５
０１とイベントプレース５０２、およびイベントプレー
ス５０２とイベントプレース５０３がそれぞれＦＡ１と
ＦＡ２によって連結されており、イベントプレース５０
１において送信されたイベント１が、ＦＡ１によってイ
ベントプレース５０２へ、さらにＦＡ２によってイベン
トプレース５０３に転送される様子を表している。ま
た、図中のイベントの括弧（）内の数字は、当該イベン
トがどのイベントプレースのオントロジーに基づいて記
述されたものであるかを表している。

【０１１５】図３３を用いて本方法の処理を説明する。 （１）まず、イベントプレース５０１においてイベント
１が送信される。このとき、送信されたイベント１は、
イベントプレース５０１のオントロジーに基づいて記述
されている。 （２）ＦＡ１は、上記イベント１によって自律起動され
当該イベント１を受信する。そして、ＦＡ１はイベント
１を標準オントロジーに基づいたイベント２へとオント
ロジー変換を行う。

【０１１６】（３）ＦＡ１は、上記イベント２をＦＡ２
に転送する。この際、イベントプレース５０２をトンネ
リングさせることで、ダイレクトにＦＡ２にイベント２
を引き渡す。また、ＦＡ１は当該イベント２を、イベン
トプレース５０２のオントロジーに基づいたイベント３
へとオントロジー変換を行った後、当該イベント３をイ
ベントプレース５０２へ送出する。 （４）上記（３）によってイベント２を受け取ったＦＡ
２は、イベント２をイベントプレース５０３のオントロ
ジーに基づいたイベント４へとオントロジー変換を行
う。そして、ＦＡ２は当該イベント４を、イベントプレ
ース５０３に送出する。つまり、本方法ではイベントプ
レース間でのイベント転送を行う際に、いったんイベン
トを標準オントロジーに基づいたものに変換し、その
後、イベントの送信先イベントプレースのオントロジー
に基づいたものに変換する。

【０１１７】２．オントロジー変換方法２（送信元イベ
ントプレースと送信先イベントプレース間でオントロジ
ー変換を行う） この方法は、各ＦＡにおいてイベントの送信元イベント
プレースのオントロジーに基づいたイベントから、送信
先イベントプレースのオントロジーに基づいたイベント
へと変換を行う方法である。本方法を、図３４を用いて
説明する。図３４は、図３３と同様、イベントプレース
５０１とイベントプレース５０２、およびイベントプレ
ース５０２とイベントプレース５０３がそれぞれＦＡ１
とＦＡ２によって連結されており、イベントプレース５
０１において送信されたイベント１が、ＦＡ１によって
イベントプレース５０２へ、さらにＦＡ２によってイベ
ントプレース５０３に転送される様子を表している。ま
た、図中のイベントの括弧（）内の数字は、当該イベン
トがどのイベントプレースのオントロジーに基づいて記
述されたものであるかを表している。

【０１１８】図３４を用いて本方法の処理を説明する。 （１）まず、イベントプレース５０１においてイベント
１が送信される。このとき、送信されたイベント１は、
イベントプレース５０１のオントロジーに基づいて記述
されている。 （２）ＦＡ１は、上記イベント１によって自律起動され
当該イベント１を受信する。ＦＡ１は、当該イベント１
をＦＡ２に転送する。この際、イベントプレース５０２
をトンネリングさせることで、ダイレクトにＦＡ２にイ
ベント１を引き渡す。また、ＦＡ１は当該イベント１
を、イベントプレース５０２のオントロジーに基づいた
イベント２へとオントロジー変換を行った後、当該イベ
ント２をイベントプレース５０２へ送出する。

【０１１９】（３）上記（２）においてイベント１を受
け取ったＦＡ２は、イベント１をイベントプレース５０
３のオントロジーに基づいたイベント３へとオントロジ
ー変換を行う。そして、ＦＡ２は当該イベント３を、イ
ベントプレース５０３に送出する。 ３．オントロジー変換方法３（隣接するイベントプレー
ス間でオントロジー変換を行う）

【０１２０】本方法は、イベントを常に隣接するイベン
トプレースのオントロジーに変換していくものである。
本方法を、図３５を用いて説明する。図３５は、図３３
や図３４と同様、イベントプレース５０１とイベントプ
レース５０２、およびイベントプレース５０２とイベン
トプレース５０３がそれぞれＦＡ１とＦＡ２によって連
結されており、イベントプレース５０１において送信さ
れたイベント１が、ＦＡ１によってイベントプレース５
０２へ、さらにＦＡ２によってイベントプレース５０３
に転送される様子を表している。また、図中のイベント
の括弧（）内の数字は、当該イベントがどのイベントプ
レースのオントロジーに基づいて記述されたものである
かを表している。

【０１２１】図３５を用いて本方法の処理を説明する。 （１）まず、イベントプレース５０１においてイベント
１が送信される。このとき、送信されたイベント１は、
イベントプレース５０１のオントロジーに基づいて記述
されている。 （２）ＦＡ１は、上記イベント１によって自律起動され
当該イベント１を受信する。そして、ＦＡ１は当該イベ
ント１をイベントプレース５０２のオントロジーに基づ
いたイベント２へとオントロジー変換を行った後、当該
イベント２をイベントプレース５０２へ送出する。

【０１２２】（３）ＦＡ２は、上記イベント２によって
自律起動され当該イベント２を受信する。そして、オン
トロジーＦＡ２は、イベント２をイベントプレース５０
３のオントロジーに基づいたイベント３へとオントロジ
ー変換を行う。そして、ＦＡ２は当該イベント３を、イ
ベントプレース５０３に送出する。上記の３つのオント
ロジー変換方法に関して、３つの比較項目から比較を行
ったものを図３６に示す。縦軸に上記３つのオントロジ
ー変換方法を並べ、横軸に３つの比較項目を記述してあ
る。

【０１２３】まず、比較項目「各ＦＡが保持するオント
ロジー変換情報の数（Ａ）」とは、一つの各ＦＡが、オ
ントロジー変換のために保持しなければならないオント
ロジー変換情報の数を示している。オントロジー変換方
法１、３は、それぞれ高々２、１個のオントロジー変換
情報を必要とするだけであるが、オントロジー変換方法
２は、最大（イベントプレースの数―１）個のオントロ
ジー変換情報を必要とする。次に、比較項目「各ＦＡ
で、特定のイベントに対して、オントロジー変換を行う
回数（Ｂ）」とは、各ＦＡにおいて、受信した一つのイ
ベントに対してオントロジー変換の処理を行う回数であ
る。オントロジー変換方法１、２、３について、それぞ
れ高々２、１、１回となる。すなわち、本比較項目に関
しては、オントロジー変換方法間の優劣の差が微小であ
る。

【０１２４】最後に、比較項目「複数のイベントプレー
スを跨ってイベントが転送される際に、当該イベントに
対してオントロジー変換が行われる回数（Ｃ）」とは、
ある特定のイベントに着目した場合、当該イベントが複
数のイベントプレースを跨って転送されていくときに、
オントロジー変換の処理が当該イベントに対して行われ
る回数のことである。オントロジー変換方法１、２に関
しては、高々２、１回でよいのに対し、オントロジー変
換方法３では、最大（通過したＦＡの数−１）回のオン
トロジー変換処理がなされる。

【０１２５】以上の比較項目（Ａ）（Ｂ）（Ｃ）を用い
て、オントロジー変換方法１、２、３の特徴を順番に説
明する。オントロジー変換方法１は、（Ａ）（Ｂ）
（Ｃ）のどの比較項目も問題が無く、一番処理効率が優
れている。しかし、本方法１は標準オントロジーを確立
しなければならないという問題点を有している。ＩＰに
おいては、４バイト（IPｖ４の場合）の数値と階層的な
ネーミング規則によって、全世界で一意の標準となるア
ドレス体系を確立することが可能であった。しかし、意
味情報ネットワークにおけるアドレス体系とは、すなわ
ち意味情報体系（オントロジー）のことであり、このよ
うな意味情報に関して全世界で一意な標準体系を確立す
ることは不可能であると考えられる。例えばfacilitato
r（Michael R. Genesereth , Steven P.Ketchpel,“Sof
tware Agents”,Communication of the ACM Vol.37 No.
7 pp.48-53(1994））等では、エージェント間の通信言
語として標準オントロジーを用いる方法が採用されてい
るが、グローバルな環境においてこのような標準オント
ロジーを作成することは現実的には困難であると考えら
れている。よって、適用領域としてグローバルな環境を
対象とした場合、オントロジー変換方法１は用いること
が出来ない。

【０１２６】オントロジー変換方法２に関しては、
（Ｂ）（Ｃ）の項目は問題ないが、（Ａ）の項目に問題
がある。すなわち、オントロジー変換方法２では、フェ
デレーションを行うイベントプレースの数が増加した場
合、それに伴って各ＦＡが保持しなければならないオン
トロジー変換情報の数が比例的に増加する。よって、フ
ェデレーションを行うイベントプレースの数が膨大な場
合（適用領域としてグローバルな環境を対象とした場
合）は、本方法２を用いることがやはり困難である。オ
ントロジー変換方法３は、（Ａ）（Ｂ）の項目は問題な
いが、（Ｃ）の項目に問題がある。つまり、イベントが
通過するイベントプレース（ＦＡ）の数が増大する際、
それに比例してオントロジー変換がなされる回数が増加
するため、オントロジー変換の処理効率が悪いばかり
か、オントロジー変換の際に発生する誤差が蓄積してし
まうという課題を有している。しかし、隣接するイベン
トプレースのみに着目しているため、動的なフェデレー
ション（フェデレーションの動的な開始、解除）が容易
に実現できるという長所を備えている。

【０１２７】上記をまとめると、膨大な数のイベントプ
レースが存在するようなグローバルな適用領域を対象と
した場合、オントロジー変換方法１と２は利用すること
が困難である。そして、いくつかの課題は有しているも
のの、オントロジー変換方法３のみがグローバルな環境
での適用に対応できる。

【０１２８】＜オントロジー自動変換＞以下、オントロ
ジー自動変換の詳細を説明する。まず、ＦＡがオントロ
ジー対応情報を自動生成する動作を説明し、次に自動生
成された該オントロジー対応情報を用いて、イベントの
オントロジー変換を自動で行う動作を説明する。

【０１２９】○ オントロジー対応情報の自動生成 ます、ＦＡ（フェデレーションエージェント）が、オン
トロジー対応情報を自動生成する動作を説明する。従
来、オントロジー対応情報は手動で作成するものであっ
たが、それを自動生成する点に本発明の特微がある。自
動生成することによって、人が手動で行っていた作成作
業の手間を軽減できるという効果を有する。例えば、人
手でオントロジー対応情報を作成する作業の際に、本実
施形態のＦＡによって自動生成したオントロジー対応情
報に基づいた対応関係を表示する（推薦する）ことによ
って、作成作業のサポートを行うことも可能となる。な
お、本実施形態のＦＡによるオントロジー対応情報生成
方法は、上記のオントロジー変換方法１〜３のいずれに
対しても適用することが可能である。また、本実施形態
において、オントロジー変換情報とオントロジー対応情
報は同義である。

【０１３０】以下、オントロジー対応情報を自動生成す
るＦＡが、オントロジー対応情報を自動生成する動作を
説明する。まず、ＦＡ（フェデレーションエージェン
ト）の構成を図４３を用いて説明する。図４３は、ＦＡ
を機能展開して示したブロック図である。この図におい
て、１１はイベント受信部であり、オントロジー変換の
変換元（対応元）イベントプレースからのイベントを受
信する。１２は変換部であり、受信したイベントを、変
換情報管理部１４で管理されているオントロジー対応情
報を用いて変換する。１３はイベント送信部であり、変
換部１２により変換されたイベントを変換先（対応先）
イベントプレースへ送信する。１５は意味情報体系取得
部であり、オントロジー変換の変換元イベントプレース
と変換先イベントプレースの両者から、意味情報体系を
取得する。１６はオントロジー対応情報生成部であり、
オントロジー対応情報を生成する。１７はフェデレーシ
ョン確立部である。１８はフィルタ設定部である。

【０１３１】次に、ＦＡがオントロジー対応情報を生成
する動作を説明する。 《ステップ１》意味情報体系の取得 ＦＡの意味情報体系取得部１５は、オントロジー変換の
変換元（対応元）イベントプレースと変換先（対応先）
イベントプレースの両者から、意味情報体系（オントロ
ジー）を取得する。本実施形態において、意味情報体系
（オントロジー）とは、具体的には各イベントプレース
に登録されているイベントタイプ（クラス）の集合のこ
とである。ＦＡの意味情報体系取得部１５は、ＥＰＭＯ
に依頼することで、イベントプレースに登録されている
すべてのイベントタイプを取得する。

【０１３２】ここで、本自動生成方法が対象とするイベ
ントタイプの形式の一例を図３７に示した。イベントタ
イプは本図で示されるようにフレーム構造で記述されて
いる。すなわち、各イベントタイプは、イベントタイプ
を一意に指定するイベントタイプ名（クラス名）、継承
する親イベントタイプ名を指定する親タイプ名、当該イ
ベントタイプの役割、意味、コメント等を記述した説明
文、複数のスロット、から構成される。なお、説明文を
記述することは必須ではないが、オントロジー自動変換
の精度を向上させるために記述することが推奨される。
また、スロットとは、属性名と属性値のペアのことを指
し、本実施形態においては、属性値としては属性値タイ
プ名、すなわち該イベントタイプのインスタンス（イベ
ント、フィルタ）の属性値がとるタイプ名（型名、例え
ばstring等）を指定する。

【０１３３】《ステップ２》オントロジー対応情報の自
動生成 オントロジー対応情報生成部１６は、上記《ステップ
１》で取得した意味情報体系をもとに、オントロジー対
応情報を生成する。ここでは、オントロジー対応元イベ
ントプレースと対応先イベントプレースの両方におい
て、イベントタイプは図３７に一例を示したようなフレ
ーム形式に基づいて記述されている場合を対象とする。
従って、オントロジー対応関係として、対応元イベント
プレースのどのイベントタイプが、対応先イベントプレ
ースのどのイベントタイプに対応しており、さらに、対
応するイベントタイプ間において、どのスロットがどの
スロットに対応しているかという、イベントタイプとス
ロットの対応関係を求めることが必要となる（図３８参
照）。すなわち、本実施形態において、オントロジー対
応情報（オントロジー変換情報）とは、具体的には、対
応元イベントプレースと対応先イベントプレース間にお
ける、イベントタイプとスロットに関する対応関係を示
すイベントタイプ対とスロット対の集合であると定義す
る。

【０１３４】以下、このようなオントロジー対応情報を
生成するためのオントロジー対応情報生成部１６の動作
を、４つのサブステップ２．１〜２．４に分けて説明す
る。これらのサブステップは、類似度算出方法と、マッ
ピング方法から構成される。前者はイベントタイプ間、
およびスロット間の類似度を算出する方法であり、後者
は算出された類似度をもとに、イベントタイプとスロッ
トの対応関係を決定する方法である。なお、類似度は0
（類似していない）〜１（類似している）の実数値を取
ることとする。

【０１３５】《サブステップ２．１》スロット間類似度
の算出スロット間の類似度は、対応する属性名と属性値
タイプ名の類似度から算出する。ここでは、具体的には
「属性名の類似度」と「属性値タイプ名の類似度」の最
小値によって算出することとする。すなわち、 スロットの類似度=min(「属性名の類似度」、「属性値タイプ名の類似度」) (1) とする。ただし、AND演算と同様の効果を有する演算子
であれば、必ずしもmin演算子を用いる必要は無い。例
えば、以下の式（1a）のように、乗算を用いても良い。

【０１３６】 スロットの類似度=「属性名の類似度」×「属性値タイプ名の類似度」 (1a) 次に、式（１）あるいは式（１a）において、「属性名
の類似度」と「属性値タイプ名の類似度」を算出する方
法を説明する。まず、「属性名の類似度」の算出に関し
ては、既存技術である、語の類似度算出方法を用いる。
既存技術として、例えば、概念ベース（笠原要 松澤和
光 、“概念に基づく単語の類似性判別 −方法論−”日
本ファジィ学会誌Vol．12 No．2 pp．218-227 (2000)）
を用いる方法や、汎用のシソーラスを用いる方法等があ
る。ここでは、「自然言語処理（長尾真著、岩波書
店）」に記載されている、汎用のシソーラスを用いた場
合の、語の類似度算出方法を説明する。ここで、汎用の
シソーラスとは、例えば「日本語語彙体系（ＮＴＴコミ
ュニケーション科学基礎研究所、岩波書店）」、「角川
類語新辞典（角川書店）」、「分類語彙表（国立国語研
究所）」、「EDR電子化辞書（日本電子化辞書研究
所）」、「WordNet（Princeton University）」等のこ
とを指す。

【０１３７】分類シソーラスを用いた場合は、「属性名
の類似度」は、対応元の属性名と対応先の属性名の類似
度を以下の式で算出する（図３９参照）。 属性名の類似度 = d_c/max（深さ） (2) ここで、d_cとは二つの語に共通の上位ノードの深さであ
り、ｍａｘ（深さ）とは、シソーラスツリーの階層の深
さの最大値である。一方、上位下位シソーラスを用いる
場合は、以下の式によって類似度を求める。 属性名の類似度 = (d_c×2)/(d_i×d_j) (3) ここで、 d_i、d_j …各語の深さ d_c …共通の上位ノードの深さ である。

【０１３８】なお、属性名のような語の類似度を算出す
る際は、コーディング（文字コード、大文字・小文字、
全角・半角等）を統一してから処理するものとする。ま
た、一部の表記の揺れ（例えば、外来語（インターフェ
イス、インタフェース）、送り仮名（打ち合わせ、打合
せ）、省略形（特別急行、特急）、等）に対処するた
め、用いるシソーラスの種別によっては、最適照合検索
（best-match retrieval）や Levenshtein 距離に基い
て算出した類似度を重み付けして足し合わせることによ
って、語の類似度を算出することとする。

【０１３９】次に、「属性値タイプ名の類似度」の算出
方法を説明する。基本的に「属性値タイプ名の類似度」
に関しても、前記の「属性名の類似度」と同様の算出方
法を用いる。すなわち、図４０に示すような属性値タイ
プ名（string、 integer、 float等）を要素に持つツリ
ーを作成し、前述の「属性名の類似度」の式（式（２）
および式（３））によって「属性値タイプ名の類似度」
を算出する。

【０１４０】《サブステップ２．２》スロット対応の決
定（マッピング） スロットのマッピングとは、特定のイベントタイプ間に
おいて、最も妥当なスロットの対応関係を求める方法の
ことである。本発明では、簡明な以下のアルゴリズムに
よってマッピングを実現する。

【０１４１】[１] スロット対類似度行列を作成する。
ここでスロット対類似度行列とは、行列の要素A_ijを、
対応元イベントタイプのi番目のスロットと、対応先イ
ベントタイプのj番目のスロットの類似度を前述の式
(１)（あるいは式（１a））によって算出したものであ
る。 [２] スロット対応のペアが作れなくなるまで、以下を
繰り返す（図４１参照）。 [２．１] 該類似度行列の要素A_ijが最大値max(A_ij)を取
るときの、iとjを求める。 if (max(A_ij) > α（閾値となる定数）) { スロット対(i,j)を保管する。 } else { ループを終了する。 } [２．２] 上記i行とj列を削除する。 上記のアルゴリズムによって、スロットの対応関係を示
す複数のスロット対(i,j)が求められる。なお、定数α
は誤ったスロット対の作成を防ぐためのものである。

【０１４２】《サブステップ２．３》イベントタイプ間
の類似度算出 イベントタイプ間の類似度は、イベントタイプ名、説明
文、当該イベントタイプに属するスロットの類似度を基
に算出する。すなわち、 イベントタイプの類似度 = min(「イベントタイプ名の類似度」、「説明文 の類似度」、「スロット対集合の類似度」) (4) とする。ただし、式（１）において説明したのと同様
に、AND演算と同様の効果を有する演算子であれば、必
ずしもmin演算子を用いる必要は無い。例えば、乗算を
用いても良い。また、「説明文の類似度」に関しては、
イベントタイプの類似度算出の際には考慮しない形態も
可能であり、この場合、式（４）は以下の式（4a）で置
き換えられる。 イベントタイプの類似度 = min(「イベントタイプ名の類似度」、「スロッ ト対集合の類似度」) (4a)

【０１４３】式（４）（あるいは式（4a））において、
「イベントタイプ名の類似度」は、前述の属性名の類似
度と同一の方法によって算出する。すなわち、シソーラ
スを用いた語の類似度算出式（式（２）および式
（３））によって算出する。次に、「説明文の類似度」
に関しては、やはり「自然言語処理（長尾真著、岩波書
店）」に記載されている既存技術である、「ベクトル空
間法(vector-spacemodel)」を用いて算出する。すなわ
ち、対応元イベントタイプと対応先イベントタイプの説
明文の索引語ベクトルを、それぞれs、dとすると、「説
明文の類似度」は以下のベクトル内積によって算出でき
る。 説明文の類似度 = (s・d) / (|s||d|) (5)

【０１４４】最後に、「スロット対集合の類似度」は、
《サブステップ２．２》において説明したスロットのマ
ッピング方法を用いて算出されたスロット対の集合を用
いて、以下の式によって算出する。 スロット対集合の類似度 = (Σスロット対の類似度) / スロットの数 (6) この項は、対応するイベントタイプは同様のスロットを
有している、という考えに基づいている。

【０１４５】《サブステップ２．４》イベントタイプ対
応を決定（マッピング） イベントタイプのマッピングは、《サブステップ２．
２》において説明したスロットのマッピング方法と基本
的に同一である。異なるのは、式(4)（あるいは式(4
a)）を用いてイベントタイプ対類似度行列を作成する点
である。 [１] イベントタイプ対類似度行列を作成する。ここで
イベントタイプ対類似度行列とは、行列の要素B_ijを、i
番目の対応元イベントタイプと、j番目の対応先イベン
トタイプのイベントタイプ間の類似度を、前述の式(４)
（あるいは式(4a)）によって算出したものである。

【０１４６】[２] イベントタイプ対応のペアが作れな
くなるまで、以下を繰り返す。 [２．１] 該類似度行列の要素B_ijが、最大値max(B_ij)を
取るときの、iとj求める。 if (max(B_ij) > β（閾値となる定数）) { イベントタイプ対(i,j)を保管する。 } else { ループを終了する。 } [２．２] 上記i行とj列を削除する。 上記のアルゴリズムによって、イベントタイプの対応関
係を示す複数のイベントタイプ対(i,j)が求められる。
なお、定数βは誤ったイベントタイプ対の作成を防ぐた
めのものである。

【０１４７】なお、上記で説明を行った形態とは別の形
態として、イベントタイプの類似度を算出する際に、
「スロット対集合の類似度」を考慮しない形態も可能で
ある。本実施形態では、式（４）から「スロット対集合
の類似度」が削除され、以下の式（７）が用いられる。 イベントタイプの類似度 = 「イベントタイプ名の類似度」、「説明文の類 似度」 (７)

【０１４８】ただし、式（４）において説明したのと同
様、AND演算と同様の効果を有する演算子であれば、必
ずしもmin演算子を用いる必要は無い。例えば、乗算を
用いても良い。また、「説明文の類似度」に関しては、
イベントタイプの類似度算出の際には考慮しない形態も
可能であり、この場合、式（７）は以下の式（７a）で
置き換えられる。 イベントタイプの類似度 = 「イベントタイプ名の類似度」 (７a) この場合、イベントタイプの対応関係を求めるため、
「スロット対集合の類似度」を必要としない。そこで、
先に《サブステップ２．３》と《サブステップ２．４》
を用いてイベントタイプの対応関係を求めておき、次に
得られたイベントタイプ対ごとのスロット対応を《サブ
ステップ２．１》と《サブステップ２．２》を用いて決
定することが可能となる。

【０１４９】○ イベントのオントロジー自動変換 上記で説明したＦＡが、生成したオントロジー対応情報
を用いてイベントのオントロジー変換を自動で行う動作
の詳細を述べる。以下、イベントプレースAに属するＦ
ＡがイベントプレースBに対してフェデレーションを確
立し、イベントのオントロジー変換を行うまでの処理フ
ローを、図４２を参照しながら説明する。 （１）イベントプレースAに属するＦＡは、イベントプ
レースBに対してフェデレーションを確立するよう指示
を受ける。

【０１５０】（２）該ＦＡの意味情報体系取得部１５、
オントロジー対応情報生成部１６は、前述した動作によ
り、イベントプレースBのオントロジーBを対応元、イベ
ントプレースAのオントロジーAを対応先とするオントロ
ジー対応情報を生成する。該オントロジー対応情報は、
具体的にはオントロジーAとオントロジーB間のイベント
タイプの対応関係を示すイベントタイプ対の集合、およ
び、おのおのの該イベントタイプ対ごとに、スロットの
対応関係を示すスロット対の集合から構成される。 （３）該ＦＡのフィルタ設定部１８は、イベントプレー
スBにフィルタを設定する。

【０１５１】（４）該ＦＡは、イベントプレースBより
自律起動され、イベント受信部１１はイベントを受信す
る。例えば、図４２の「イベント（変換前）」は、この
とき該ＦＡが受信するイベントの一例を示している。該
イベントは、イベントタイプ名がイベントタイプ２であ
り、属性名が「TEL」で属性値が「03-xxxx-xxxx」であ
るスロットや、属性名が「名前」で属性値が「○○太
郎」であるスロットを有している。

【０１５２】（５）該ＦＡの変換部１２は、意味情報体
系取得部１５、オントロジー対応情報生成部１６により
生成され、変換情報管理部１４に保管されたオントロジ
ー対応情報を用いて、イベントのオントロジー変換を行
う。具体的には、イベントタイプ対を用いてイベントタ
イプの変換を行い、さらに、スロット対を用いて、スロ
ットの変換を行う。この変換方法の詳細を、図４２を参
照して説明する。まず、該オントロジー対応情報からイ
ベントタイプ対（２、１）を得ることによって、オント
ロジーBにおいて第２番目のイベントタイプである「イ
ベントタイプ２」を、オントロジーAにおいて第1番目の
イベントタイプである「イベントタイプA」へと対応さ
せる。次に、該オントロジー対応情報から該イベントタ
イプ対に対応したスロット対の集合を得る。そして、該
スロット対を用いてスロットの変換を行う。例えば、ス
ロット対（２、４）が得られた場合、属性名が「TEL」
であるイベントタイプ２の第２番目のスロットを、属性
名が「電話番号」であるイベントタイプAの第4番目のス
ロットへと対応させる。なお、本実施形態においては、
スロット内の属性値に関しては、オントロジー変換の対
象としない。すなわち、本例における「03-xxxx-xxxx」
という属性値は、そのままコピーされて対応先スロット
の属性値として用いられる。ＦＡのイベント送信部１３
は、このように、オントロジー変換したイベントをイベ
ントプレースAへ送信する。

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

【０１５４】このコミュニティは、特に以下の特徴を持
つエンティティを取り扱うことができる。 （１）極小粒度で、膨大な数のエンティティがコミュニ
ティに存在する（不特定多数のエンティティ）。 （２）エンティティの属性がリアルタイムに変化する。
典型的なエンティティの属性として、位置情報、時刻等
がある。 （３）コミュニティ内のエンティティの振る舞いに規則
性がなく、行動予測が困難である。 （４）コミュニティヘの参加、コミュニティからの退
去、消滅、複製等が頻繁かつ不規則に発生する。 （５）コミュニティ内のエンティティは、ポリシ、属
性、シナリオ等に基づいて相互にリアルタイムに出会う
必要がある。

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

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

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

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

【０１５９】まず、コミュニティＢのＣｏｍＡが、イベ
ントプレースＢのＦＡに対して、"コミュニティＡにお
いて流通している情報の中で、人気が高いトップ１０の
みを、コミュニティＢに流通させる"旨を指示する。次
にＦＡは、イベントプレースＡに対して、トップ１０の
イベントタイプを問い合わせる。これを受けて、イベン
トプレースＡは、配下の統計情報収集オブジェクト（Ｓ
Ｏ）に問い合わせ、その結果を、ＦＡに返却する。

【０１６０】次に、ＦＡは取得したイベントタイプを基
に、オントロジー変換情報を作成するとともに、イベン
トプレースＡに対しフィルタを設定する。以降、ＦＡ
は、イベントプレースＡから、当該イベントを受信可能
になる。次にＦＡは、イベントプレースＡから取得した
イベントを、オントロジー変換情報に基づいてオントロ
ジー変換し、それをイベントプレースＢへと送出する。

【０１６１】なお、図４３における意味情報体系取得部
１５、オントロジー対応情報生成部１６の機能は、ＦＡ
に含まれることを必須としない。ＦＡは、意味情報体系
取得部１５及びオントロジー対応情報生成部１６の機能
を備えるオントロジー対応情報生成装置により得られた
オントロジー対応情報を利用してもよい。また、意味情
報体系取得部１５及びオントロジー対応情報生成部１６
の機能を備えるオントロジー対応情報生成装置は、本実
施形態で説明したＳＩＯＮネットワーク以外のほかのネ
ットワーク等にも対応可能である。また、図４３におけ
る各部は専用のハードウェアにより実現されるものであ
ってもよく、また、各部はメモリおよびＣＰＵ（中央演
算装置）により構成され、各部の機能を実現するための
プログラムをメモリにロードして実行することによりそ
の機能を実現させるものであってもよい。

【０１６２】図４３のＦＡの各部の機能のうち一部また
はすべてを実現するためのプログラムをコンピュータ読
み取り可能な記録媒体に記録して、この記録媒体に記録
されたプログラムをコンピュータシステムに読み込ま
せ、実行することにより、各部の機能を実現させてもよ
い。なお、ここでいう「コンピュータシステム」とは、
ＯＳや周辺機器等のハードウェアを含むものとする。ま
た、「コンピュータシステム」は、ＷＷＷシステムを利
用している場合であれば、ホームページ提供環境（ある
いは表示環境）も含むものとする。

【０１６３】また、「コンピュータ読み取り可能な記録
媒体」とは、フレキシブルディスク、光磁気ディスク、
ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシス
テムに内蔵されるハードディスク等の記憶装置のことを
いう。さらに「コンピュータ読み取り可能な記録媒体」
とは、インターネット等のネットワークや電話回線等の
通信回線を介してプログラムを送信する場合の通信線の
ように、短時間の間、動的にプログラムを保持するも
の、その場合のサーバやクライアントとなるコンピュー
タシステム内部の揮発性メモリのように、一定時間プロ
グラムを保持しているものも含むものとする。また上記
プログラムは、前述した機能の一部を実現するためのも
のであっても良く、さらに前述した機能をコンピュータ
システムにすでに記録されているプログラムとの組み合
わせで実現できるものであっても良い。以上、この発明
の実施形態を図面を参照して詳述してきたが、具体的な
構成はこの実施形態に限られるものではなく、この発明
の要旨を逸脱しない範囲の設計変更等も含まれる。

【０１６４】

【発明の効果】以上説明したように、本発明によるオン
トロジー対応情報生成装置、方法、プログラム、記憶媒
体によれば、転送元のオントロジーのクラスと転送先の
オントロジーのクラスの対応関係を示す情報と、転送元
のオントロジーのスロットと転送先のオントロジーのス
ロットの対応関係を示す情報とが取得できる。このよう
に取得したオントロジー対応情報を用いることにより、
自動でオントロジー変換を行うことが可能となる。その
効果として、従来人手で行っていたオントロジーの対応
付けやオントロジー変換の作業の軽減化を図ることがで
き、又、人手の作業を不要にすることができる。

【図面の簡単な説明】

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

【図２】 同実施形態において、イベントの構成例を示
す説明図である。

【図３】 同実施形態において、意味情報ネットワーク
のモデルを示す図である。

【図４】 同実施形態において、意味情報の定義を示す
説明図である。

【図５】 同実施形態において、イベントタイプの定義
例を示す説明図である。

【図６】 同実施形態において、イベントの定義例を示
す説明図である。

【図７】 同実施形態において、フィルタの定義例を示
す説明図である。

【図８】 同実施形態において、意味情報ネットワーク
の構成を示す図である。

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

【図１０】 同実施形態において、物理リンクを示す説
明図である。

【図１１】 同実施形態において、フィルタの管理方法
を示す説明図である。

【図１２】 同実施形態において、イベントルーティン
グ方法を示す説明図である。

【図１３】 同実施形態において、フィルタの登録状況
を示す説明図である。

【図１４】 同実施形態において、フェデレーション方
法を示す説明図である。

【図１５】 同実施形態において、コミュニティモデル
を示す説明図である。

【図１６】 同実施形態において、従来技術を示す説明
図である。

【図１７】 同実施形態において、従来技術を示す説明
図である。

【図１８】 同実施形態において、従来技術を示す説明
図である。

【図１９】 同実施形態において、ブローカ型のビジネ
スモデルを示す図である。

【図２０】 同実施形態において、ブローカ型のシステ
ム構成を示す図である。

【図２１】 同実施形態において、コンテンツ情報流通
網の位置づけの説明図である。

【図２２】 同実施形態において、本発明の実施形態に
係るコンテンツ情報流通網の概念図である。

【図２３】 同実施形態において、自律分散照合環境
（ＳＩＯＮ）のビジネスモデルを示す図である。

【図２４】 同実施形態において、コンテンツ条件の定
義例を示す図である。

【図２５】 同実施形態において、ユーザ嗜好属性の定
義例を示す図である。

【図２６】 同実施形態において、自律分散照合環境
（ＳＩＯＮ）の処理メカニズムを示すフローチャートで
ある。

【図２７】 同実施形態において、自律分散照合環境
（ＳＩＯＮ）の処理メカニズムを示すフローチャートで
ある。

【図２８】 同実施形態において、物理リンクを示す説
明図である。

【図２９】 同実施形態において、イベントルーティン
グ方法、フィルタの登録状況を示す説明図である。

【図３０】 同実施形態において、イベントルーティン
グの処理手順をネットワークツリー上に概念的に示した
図である。

【図３１】 同実施形態において、イベントルーティン
グを行う高信頼イベント配送装置の内部構成を示すブロ
ック図である。

【図３２】 同実施形態において、イベントルーティン
グの処理手順をネットワークツリー上に展開して示した
図である。

【図３３】 同実施形態において、第１のオントロジー
変換方法を説明するための図である。

【図３４】 同実施形態において、第２のオントロジー
変換方法を説明するための図である。

【図３５】 同実施形態において、第３のオントロジー
変換方法を説明するための図である。

【図３６】 同実施形態において、各オントロジー変換
方法の比較を示した図である。

【図３７】 同実施形態において、イベントタイプの構
成例を示した図である。

【図３８】 同実施形態において、イベントタイプとス
ロットとの対応について説明した図である。

【図３９】 同実施形態において、分類シソーラスを説
明するための図である。

【図４０】 同実施形態において、属性タイプ名を要素
にもつツリーの一例を示した図である。

【図４１】 同実施形態において、スロット対応の決定
を説明するための図である。

【図４２】 同実施形態において、イベントのオントロ
ジー変換を説明するための図である。

【図４３】 同実施形態において、ＦＡの構成を示すブ
ロック図である。

【符号の説明】

１１：イベント受信部、１２：変換部、１３：イベント
送信部、１４：変換情報管理部、１５：意味情報体系取
得部、１６：オントロジー対応情報生成部、１７：フェ
デレーション確立部、１８：フィルタ設定部

───────────────────────────────────────────────────── フロントページの続き (72)発明者 武本 充治 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 (72)発明者 菊谷 幸雄 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 Ｆターム(参考） 5B075 NK46 PR06 QM08 5B082 GA02 HA05

Claims (7)

【特許請求の範囲】
1. 【請求項１】 異なるオントロジー間の対応関係を記述
   するオントロジー対応情報を生成するオントロジー対応
   情報生成装置であって、 少なくともクラス名、複数のスロットを含む対応元オン
   トロジーと、少なくともクラス名、複数のスロットを含
   む対応先オントロジーを取得する意味情報体系取得部
   と、 前記対応元のオントロジーのスロットと前記対応先のオ
   ントロジーのスロットの類似度を、各々のスロットの組
   み合わせについて算出し、特定値以上の類似度を算出す
   るスロットの組み合わせを取得し、 前記対応元のオントロジーのクラスと前記対応先のオン
   トロジーのクラスの類似度を、少なくともクラス名と、
   前記取得したスロットの組み合わせの類似度とを用いて
   各々のクラスの組み合わせについて算出し、特定の値以
   上の類似度を算出するクラスの組み合わせを取得するオ
   ントロジー対応情報生成部とを備えることを特徴とする
   オントロジー対応情報生成装置。
2. 【請求項２】 異なるオントロジー間の対応関係を記述
   するオントロジー対応情報を生成するオントロジー対応
   情報生成装置であって、 少なくともクラス名、複数のスロットを含む対応元オン
   トロジーと、少なくともクラス名、複数のスロットを含
   む対応先オントロジーを取得する意味情報体系取得部
   と、 前記対応元のオントロジーのクラスと前記対応先のオン
   トロジーのクラスの類似度を、少なくともクラス名を用
   いて各々のクラスの組み合わせについて算出し、特定の
   値以上の類似度を算出するクラスの組み合わせを取得
   し、 前記対応元のオントロジーのスロットと前記対応先のオ
   ントロジーのスロットの類似度を、前記決定したクラス
   の組み合わせごとに各々のスロットの組み合わせについ
   て算出し、特定値以上の類似度を算出するスロットの組
   み合わせを取得するオントロジー対応情報生成部とを備
   えることを特徴とするオントロジー対応情報生成装置。
3. 【請求項３】 異なるオントロジー間の対応関係を記述
   するオントロジー対応情報を生成するオントロジー対応
   情報生成方法であって、 少なくともクラス名、複数のスロットを含む対応元オン
   トロジーと、少なくともクラス名、複数のスロットを含
   む対応先オントロジーを取得する過程と、 前記対応元のオントロジーのスロットと前記対応先のオ
   ントロジーのスロットの類似度を、各々のスロットの組
   み合わせについて算出し、特定値以上の類似度を算出す
   るスロットの組み合わせを取得する過程と、 前記対応元のオントロジーのクラスと前記対応先のオン
   トロジーのクラスの類似度を、少なくともクラス名と、
   前記取得したスロットの組み合わせの類似度とを用いて
   各々のクラスの組み合わせについて算出し、特定の値以
   上の類似度を算出するクラスの組み合わせを取得する過
   程とを特徴とするオントロジー対応情報生成方法。
4. 【請求項４】 異なるオントロジー間の対応関係を記述
   するオントロジー対応情報を生成するオントロジー対応
   情報生成方法であって、 少なくともクラス名、複数のスロットを含む対応元オン
   トロジーと、少なくともクラス名、複数のスロットを含
   む対応先オントロジーを取得する過程と、 前記対応元のオントロジーのクラスと前記対応先のオン
   トロジーのクラスの類似度を、少なくともクラス名を用
   いて各々のクラスの組み合わせについて算出し、特定の
   値以上の類似度を算出するクラスの組み合わせを取得す
   る過程と、 前記対応元のオントロジーのスロットと前記対応先のオ
   ントロジーのスロットの類似度を、前記決定したクラス
   の組み合わせごとに各々のスロットの組み合わせについ
   て算出し、特定値以上の類似度を算出するスロットの組
   み合わせを取得する過程とを特徴とするオントロジー対
   応情報生成方法。
5. 【請求項５】 異なるオントロジー間の対応関係を記述
   するオントロジー対応情報を生成するオントロジー対応
   情報生成プログラムであって、 少なくともクラス名、複数のスロットを含む対応元オン
   トロジーと、少なくともクラス名、複数のスロットを含
   む対応先オントロジーを取得するステップと、 前記対応元のオントロジーのスロットと前記対応先のオ
   ントロジーのスロットの類似度を、各々のスロットの組
   み合わせについて算出し、特定値以上の類似度を算出す
   るスロットの組み合わせを取得するステップと、 前記対応元のオントロジーのクラスと前記対応先のオン
   トロジーのクラスの類似度を、少なくともクラス名と、
   前記取得したスロットの組み合わせの類似度とを用いて
   各々のクラスの組み合わせについて算出し、特定の値以
   上の類似度を算出するクラスの組み合わせを取得するス
   テップとをコンピュータに実行させるオントロジー対応
   情報生成プログラム。
6. 【請求項６】 異なるオントロジー間の対応関係を記述
   するオントロジー対応情報を生成するオントロジー対応
   情報生成プログラムであって、 少なくともクラス名、複数のスロットを含む対応元オン
   トロジーと、少なくともクラス名、複数のスロットを含
   む対応先オントロジーを取得するステップと、 前記対応元のオントロジーのクラスと前記対応先のオン
   トロジーのクラスの類似度を、少なくともクラス名を用
   いて各々のクラスの組み合わせについて算出し、特定の
   値以上の類似度を算出するクラスの組み合わせを取得す
   るステップと、 前記対応元のオントロジーのスロットと前記対応先のオ
   ントロジーのスロットの類似度を、前記決定したクラス
   の組み合わせごとに各々のスロットの組み合わせについ
   て算出し、特定値以上の類似度を算出するスロットの組
   み合わせを取得するステップとをコンピュータに実行さ
   せるオントロジー対応情報生成プログラム。
7. 【請求項７】 請求項５又は請求項６に記載のプログラ
   ムを記録したコンピュータ読み取り可能な記録媒体。