JP3792664B2 - Entity device, reply notification control method, reply notification control program, and recording medium thereof - Google Patents

Entity device, reply notification control method, reply notification control program, and recording medium thereof Download PDF

Info

Publication number
JP3792664B2
JP3792664B2 JP2003070446A JP2003070446A JP3792664B2 JP 3792664 B2 JP3792664 B2 JP 3792664B2 JP 2003070446 A JP2003070446 A JP 2003070446A JP 2003070446 A JP2003070446 A JP 2003070446A JP 3792664 B2 JP3792664 B2 JP 3792664B2
Authority
JP
Japan
Prior art keywords
event
entity
reply
filter
semantic information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2003070446A
Other languages
Japanese (ja)
Other versions
JP2004282374A (en
Inventor
隆成 星合
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2003070446A priority Critical patent/JP3792664B2/en
Publication of JP2004282374A publication Critical patent/JP2004282374A/en
Application granted granted Critical
Publication of JP3792664B2 publication Critical patent/JP3792664B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

【０００１】
【発明の属する技術分野】
本発明は、イベントに対するリプライ通知制御を行うエンティティ装置、リプライ通知制御方法、リプライ通知制御プログラム及びその記録媒体に関する。
【０００２】
【従来の技術】
従来、インターネットでは、図２３に示すように、「ブローカ型配信モデル」に基づいた情報配信が一般的であった。このビジネスモデルでは、ブローカとして位置付けられる情報配信者（例えば、パソコン通信会社）が、情報提供者の情報を集中管理し、必要に応じてユーザに対して情報の配信を行った。
しかしながら、ブローカ型探索モデルでは、ブローカが情報のメタデータを一括管理しているために、ユーザや情報提供者の多用なニーズにリアルタイムに応えることが困難であるなどから、より自由で、特定のブローカに支配されない新たなビジネスモデルが求められるようになり、このような問題認識から、「ブローカレス型探索モデル」という新たな概念が考え出された。
このブローカレス型探索モデルが、２０００年３月に発表されたGnutellaのような、世界中で注目されるようになったＰ２Ｐ（Ｐｅｅｒ−Ｔｏ−Ｐｅｅｒ）に相当する。また、２００１年４月に発表されたＪＸＴＡもＰ２Ｐ、すなわちブローカレス型探索モデルに相当する。Ｐ２Ｐは、WWW以来の革新技術であり、第３世代と呼ばれている。なお、近年、伝送レイヤにＰ２Ｐの概念を適用したブローカレス型伝送モデルや、ポリシーレイヤにＰ２Ｐの考え方を適用したブローカレス型ポリシーモデルの研究開発が活発化していている。ブローカレス（配信）モデルのディメンションを図２４に示す。このブローカレス型探索モデルの１つがＳＩＯＮｅｔ（Semantic Infomation Oriented Network）である。
【０００３】
SIONetは、意味情報（メタデータ）に基づいて、データと当該データの意味情報とからなるイベントを配送するメタネットワークである。図２５に示すように、イベント受信者は、受信したいイベントの条件を示す意味情報を予めSIONetに登録しておく。イベント送信者からイベントがSIONetに送信されると、SIONetは、当該イベントの意味情報と、登録された意味情報とを照合し、その照合結果に基づいて、当該イベントをイベント受信者に送信する。このように、イベントをSIONetに送信することを「刺激」といい、登録した意味情報とイベントの意味情報とが合致し、当該意味情報を登録したイベント受信者に、当該イベントを通知することを「発火」という。
【０００４】
これにより、ネットワーク上に超分散する不特定多数のエンティティ（端末装置）の中から、特定のエンティティを動的に探索・発見することができる。すなわち、SIONetは、従来のネットワークで用いていた宛先アドレス（誰に対して送信する）の代わりに、意味情報（どういう人に対して送信する）に基づいてイベントを配送するネットワークである。
【０００５】
また、SIONetは、SIONetの構成要素を含めたすべてのエンティティが自律分散協調することにより、ネットワークが自己組織化される自律分散協調ネットワーク（自律分散コンピュータ）である。SIONetのネットワーク構成要素には、「意味情報スイッチ(SI-SW)」、「意味情報ルータ(SI-R)」、「意味情報ゲートウエイ(SI-GW)」、「イベントプレース」、「セッション」などがあり、これらが必要に応じて自己組織化することにより、セキュアーでスケーラブルなP2Pネットワークをボトムアップアプローチで構築することができる。
【０００６】
SIONetの基本概念・原理は単純で一元的である。"エンティティによるフィルタの登録とイベントの送出"という単純操作の繰り返し、すなわち、"エンティティの「刺激」と「発火」が、SIONetのネットワーク構成要素間で「連鎖反応」"することにより、すべてのエンティティを自律分散協調させる点にある。この連鎖反応の振舞いを制御するものが、上述のイベント受信者がSIONetに登録した意味情報であり、これを「フィルタ」という。フィルタに登録するフィルタ値により、エンティティの連鎖反応の仕方を動的に制御することができる。SIONetにおけるもう一つの基本概念がイベントプレースである。イベントプレースは、シェアードリンクにより相互に接続されたエンティティグループであり、これにより連鎖反応の範囲を制限することができる。
なお、SIONetの詳細については非特許文献１、２に記載されている。また、この発明の出願人は、先に、特願２００１−３９４９８０によってSIONetに関する出願を行っている。
【０００７】
【非特許文献１】
星合隆成、小柳恵一、ビルゲー・スクバタール、久保田稔、柴田弘、酒井隆道:"意味情報ネットワークアーキテクチャ”、電子情報通信学会論文誌Ｂ、Ｖｏｌ．Ｊ８４−Ｂ、Ｎｏ．３、ｐｐ．４、１１−４、２，４（２０００．７受付け、 ２００１−３掲載）．
【非特許文献２】
星合隆成、柴田弘、酒井隆道、小柳恵一:”意味情報ネットワークアーキテクチャ:ＳＩＯＮアーキテクチャ“、ＮＴＴ Ｒ＆ｄ、Ｖｏｌ．５０、Ｎｏ．３、ｐｐ．１５７−１６４（２０００．１２受付け、２００１．３掲載）
【０００８】
【発明が解決しようとする課題】
図２８にSIONetが具備する通信方式について示す。
SIONetは、ブロードキャストモード、マルチキャストモード、ユニキャストモード、リプライ通知などの通信モードを提供する。
ブロードキャストでは、イベントプレース内のすべてのエンティティに対して、イベントが転送される。そのため、転送されたイベントによりエンティティが発火するかどうかは、当該エンティティにおけるフィルタとの照合により決定される。
マルチキャストでは、イベントプレースに所属するエンティティの中から、任意の条件を満足するエンティティに対してのみイベントを転送する。
ユニキャストでは、特定のエンティティに対してのみイベントを転送する。
リプライ通知では、イベント受信者がイベント送信元に対して、イベントのリプライ通知を行う場合に、イベント送信元に対して、リプライイベントが転送される。
【０００９】
しかし、上述したような刺激と発火によって、エンティティの連鎖反応の仕方を動的に制御する自律分散ネットワークにおいて、このリプライ通知制御を実際に実現する機能は、現在提案されているものだけでは不十分であり、これを従来アーキテクチャで実現することは、新たなメソッド（機能プログラム）の追加を意味している。
しかし、これでは迅速なシステム開発、開発規模の最小化、デバック工数の削減、開発費用の削減、維持管理の容易性などを望むことは到底不可能であるという問題がある。
【００１０】
本発明はこのような事情に鑑みてなされたもので、刺激と発火によってエンティティの連鎖反応の仕方を動的に制御する自律分散ネットワークにおいて、イベント受信者がイベント送信元に対してイベントのリプライ通知を行うことができるエンティティ装置、リプライ通知制御方法、リプライ通知制御プログラム及びその記録媒体を提供することを目的とする。
【００１１】
【課題を解決するための手段】
この発明は上記の課題を解決すべくなされたもので、請求項１に記載の発明は、第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタと、前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタとを保持する意味情報ルータと、前記第１のフィルタと一致するイベントを受信した第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記意味情報ルータが保持する第２のフィルタとが一致するか否かを照合する照合部と、該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御する制御部とを有する意味情報スイッチとを具備することを特徴とする。
【００１２】
ここで、シェアードリンクとは、第１から第ｎのエンティティ装置間において、双方向のイベント共有を行うためのリンクである。
また、イベントプレースとは、第１から第ｎのエンティティ装置をシェアードリンクを介して接続して構成されるネットワークである。
また、イベントとは、データと、そのデータの意味情報と、制御情報からなるパケットである。
また、意味情報とは、送信データの特性を示す語彙、値であって、ある語彙概念におけるインスタンスである。
また、リプライイベントとは、イベント受信者がイベント送信元に対して返信する返信情報である。
【００１３】
また、請求項２に記載の発明は、第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタを保持する意味情報ルータと、第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するイベントが示す意味情報と、前記意味情報ルータが保持する第１のフィルタとが一致するか否かを照合する照合部と、該照合結果に基づいて、前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタを前記意味情報ルータに設定する制御部とを有する意味情報スイッチとを具備することを特徴とする。
【００１４】
また、請求項３に記載の発明は、請求項２に記載の発明において、前記照合部は、さらに、前記第１のフィルタと一致するイベントを受信した第ｌ（ｌは１＜ｌ＜ｎを満たす自然数 ただしｌ≠ｋ）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合し、前記制御部は、さらに、該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御することを特徴とする。
【００１５】
また、請求項４に記載の発明は、第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタと前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタとを保持する前記エンティティ装置が、前記リプライイベントのイベントルーティングを制御するリプライ通知制御方法であって、前記第１のフィルタと一致するイベントを受信した第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合し、該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御することを特徴とする。
【００１６】
また、請求項５に記載の発明は、第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタを保持する意味情報ルータを有する前記エンティティ装置が、前記イベントに対応するリプライイベントのイベントルーティングを制御するリプライ通知制御方法であって、第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するイベントが示す意味情報と、前記第１のフィルタとが一致するか否かを照合し、該照合結果に基づいて、前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタを前記意味情報ルータに設定することを特徴とする。
【００１７】
また、請求項６に記載の発明は、請求項５に記載の発明において、前記エンティティ装置が、さらに、前記第１のフィルタと一致するイベントを受信した第ｌ（ｌは１＜ｌ＜ｎを満たす自然数 ただしｌ≠ｋ）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合し、該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御することを特徴とする。
【００１８】
また、請求項７に記載の発明は、第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタと前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタとを保持する前記エンティティ装置に、前記リプライイベントのイベントルーティング制御を実行させるためのリプライ通知プログラムであって、前記第１のフィルタと一致するイベントを受信した第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合する処理と、該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御する処理とを実行させるためのリプライ通知制御プログラムである。
【００１９】
また、請求項８に記載の発明は、第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタを保持する意味情報ルータを有する前記エンティティ装置に、前記イベントに対応するリプライイベントのイベントルーティングを制御する処理を実行させるためのリプライ通知制御プログラムであって、第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するイベントが示す意味情報と、前記第１のフィルタとが一致するか否かを照合する処理と、該照合結果に基づいて、前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタを前記意味情報ルータに設定する処理とを実行させるためのリプライ通知制御プログラムである。
【００２０】
また、請求項９に記載の発明は、請求項７に記載の発明において、前記エンティティ装置に、さらに、前記第１のフィルタと一致するイベントを受信した第ｌ（ｌは１＜ｌ＜ｎを満たす自然数 ただしｌ≠ｋ）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合する処理と、該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御する処理とを実行させるためのリプライ通知制御プログラムである。
【００２１】
また、請求項１０に記載の発明は、第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタと前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタとを保持する前記エンティティ装置に、前記リプライイベントのイベントルーティング制御を実行させるためのリプライ通知プログラムを記録した記録媒体であって、前記第１のフィルタと一致するイベントを受信した第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合する処理と、該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御する処理とを実行させるためのリプライ通知制御プログラムを記録した記録媒体である。
【００２２】
また、請求項１１に記載の発明は、第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタを保持する意味情報ルータを有する前記エンティティ装置に、前記イベントに対応するリプライイベントのイベントルーティングを制御する処理を実行させるためのリプライ通知制御プログラムを記録した記録媒体であって、第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するイベントが示す意味情報と、前記第１のフィルタとが一致するか否かを照合する処理と、該照合結果に基づいて、前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタを前記意味情報ルータに設定する処理とを実行させるためのリプライ通知制御プログラムを記録した記録媒体である。
【００２３】
また、請求項１２に記載の発明は、請求項１１に記載の発明において、前記エンティティ装置に、さらに、前記第１のフィルタと一致するイベントを受信した第ｌ（ｌは１＜ｌ＜ｎを満たす自然数 ただしｌ≠ｋ）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合する処理と、該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御する処理とを実行させるためのリプライ通知制御プログラムを記録した記録媒体である。
【００２４】
【発明の実施の形態】
［SIONetの詳細］
＜SIONetエンティティの定義＞
ここでは、パーソナルコンピュータ、ワークステーション、情報携帯端末、携帯電話、ウエアラブルコンピュータなどのあらゆるコンピュータを総称して、ホストと呼ぶ。さらに、SIONetソフトウエアを実装したホストを、「SIONetエンティティ」もしくは単に「エンティティ」と呼ぶ。エンティティ（エンティティ装置）は、図２（ａ）に例を示すように、SIONetソフトウエアを実装したホストを、SIONetにおける自律分散協調の単位として仮想化したものである。SIONetソフトウエアは、個々のエンティティが自律分散協調を行うための仕組みを提供する。このSIONetソフトウエアにより、各ホストが自律分散コンピュータとなることが可能となる。
【００２５】
エンティティは、図２（ｂ）に示すように、主に以下の３つのタイプに分類される。
・サービスとして振る舞うアプリケーション（サービスエンティティ:ＳＥ、サービスエンティティ部）をエンティティ内部に含むもの
・ネットワーク構成要素として振る舞うモジュール（ネットワークエンティティ:ＮＥ）をエンティティ内部に含むもの
・上記ＳＥとＮＥとの両方をエンティティ内部に含むもの
【００２６】
＜エンティティ構造と状態遷移＞
図３は、エンティティの状態遷移を示す図である。この図に示すように、エンティティの状態として、”Non-Existent”、”サスペンド”、”アクティブ”という３つの状態がある。
”Non-Existent”状態は、ホストにSIONetソフトウエアをインストールした時点でのエンティティ状態を表している。
SIONetソフトウエアを実行（ラウンチ）することにより、”Non-Existent”状態から”サスペンド”状態に遷移する。このとき、エンティティ内に、図４に一例を示すように、エンティティ制御部、コントロールパネル、ネットワークエンティティファクトリ（ＮＥファクトリ）、ネットワークエンティティ（ＮＥ）、などの内部モジュールが生成される。以下に、それぞれの役割を簡単に説明する。
【００２７】
エンティティ制御部とは、エンティティの実体であり、他のエンティティやコントロールパネルからの様々な要求（後述するセッションの確立要求、シェアードリンクの確立要求など）を受け付ける。なお、”サスペンド”状態のエンティティに対して、他のエンティティからセッションの確立要求、シェアードリンクの確立要求などを行うことはできない。
【００２８】
コントロールパネルは、人などのエンティティの所有者に対して、GUI（Graphical User Interface）を提供する。コントロールパネルにより、例えば、エンティティの所有者にエンティティ名の入力を促し、入力されたエンティティ名に基づいて、エンティティ制御部が当該エンティティにエンティティ名を付与する。図４の例では、エンティティ名を”エンティティ２”としている。このエンティティ名を、後述する「グローバルエンティティ名」と特に区別して「ローカルエンティティ名」と呼ぶことがある。このローカルエンティティ名は、当該エンティティの所有者等が任意で設定できるものとする。
【００２９】
ＮＥ（ネットワークエンティティ）ファクトリとは、ＮＥを動的に生成する機能を備える。
ＮＥ（ネットワークエンティティ）とは、SI-R（Semantic Information Router、意味情報ルータ）、SI-GW（Semantic Information Gateway、意味情報ゲートウェイ ）、アライブエンティティ、障害処理エンティティ、統計情報収集エンティティなど、ネットワーク制御のために振る舞うモジュールの総称である。
【００３０】
ＳＥ（サービスエンティティ）とは、エンティティが提供するプラグイン機構を用いて、エンティティ内にＳＥとして組み込まれたアプリケーションであり、SIONet上で動作するＰ２Ｐアプリケーションを仮想化したものである。エンティティが提供するプラグイン機構を用いて、アプリケーションをＳＥとしてエンティティ内に組み込むことができる。また、ＳＥは、SI-SWに対して、任意数のセッションを確立することができる。ＳＥはセッションを介してのみ、イベントの送受信が可能である。ＳＥは、SIONetのネットワーク構築・運営に関与しない。なお、ＳＥをエンティティ内に組み込むプラグイン機構については後述する。
【００３１】
図３における”サスペンド”状態のエンティティ（エンティティ２）が、例えば、図５に例を示すように自らイベントプレースを生成したり、図６に例を示すように既存のイベントプレースにJoin（参加）などして、任意のイベントプレースに属し、エンティティグループのメンバーになったときに、エンティティ（エンティティ２）は”サスペンド”状態から”アクティブ”状態へと遷移する。”アクティブ”状態のエンティティのみが自身の存在をアドバタイズ（公開、詳細は後述する）し、他のエンティティからのセッションの確立要求やシェアードリンクの確立要求を受け付けることができる。
【００３２】
ここで、ソフトウェアがホストにインストールされ、ＮＥ、ＮＥファクトリ、エンティティ制御部、コントロールパネルなどを備えるエンティティが生成された後、当該エンティティが”アクティブ”状態となるまでの動作を説明する。エンティティが、当該エンティティの所有者などからコントロールパネルを介して、イベントプレースの生成や他のイベントプレースへの参加の指示を受けたものとする。エンティティのエンティティ制御部は、当該エンティティのＮＥファクトリにSI-SW（Semantic Information Switch、意味情報スイッチ）の生成を依頼する。ＮＥファクトリがSI-SWを生成すると、エンティティ制御部は、生成されたSI-SWと、ＮＥなどの内部モジュールとの間にセッションを確立する。これにより、アドバタイズや、他のエンティティからのセッションの確立要求、シェアードリンクの確立要求等を受け付けることが可能となる。
【００３３】
ここで、図７を参照し、SI-SWとセッションの役割について説明する。
セッションとは、SI-SWとＳＥ間のコネクションであり、ＳＥは、セッションを介してのみイベントの送受信を行うことができる。セッションには、イベントの送信セッション、受信セッション、送受信セッションの３タイプがある。
SI-SWは、意味情報に基づいて、イベントをスイッチングするスイッチング機構を提供する。SI-SWはセッションを介して、ＮＥや、プラグイン機構によりエンティティ内に組み込まれたＳＥやＮＥなどの内部エンティティをスター型で収容する。以下では、ＳＥを例にとり説明するが、ＮＥなど、エンティティに内包された他の内部エンティティも同様である。
【００３４】
ここで、イベントの構成について説明する。図８に一例を示すように、イベントは、制御情報部、意味情報部、データ部から構成される。データ部には、送信データが格納される。送信データとして、テキストデータ、バイナリデータ、リファレンス、プロキシ、エージェントなど、様々なデータ、プログラムを格納することができる。
【００３５】
意味情報部には、送信データの意味情報（語彙とその値）、及び、意味情報の語彙概念（イベントタイプ）が格納される。ここで、意味情報とは、送信データの特性を記述したメタデータであり、イベントタイプのインスタンスである。
また、イベントタイプは意味情報のテンプレートである。イベントタイプ間には継承関係を定義できる。図９に、意味情報体系の一例を示す。この図において、”タイトル；イエスタデイ”、”価格；＄３０”、”アーティスト名；ビートルズ”という意味情報は、”ポピュラー”というイベントタイプに属しており、また”音楽”というイベントタイプにも属している。また、”タイトル；きよしこの夜”、”価格；＄２０”、”シチュエーション；クリスマス”という意味情報は、”BGM”というイベントタイプに属しており、また”音楽”というイベントタイプにも属している。
【００３６】
意味情報体系の記述言語としてはXML（Extensible Markup Language）などがある。なお、ネットワークエンティティ用に一部のイベントタイプ名（SIONetから始まるすべての名称）が予約済みである。
図８に一例を示すイベントの制御情報部は、SIONetの実行制御のために用いられる制御フィールドであり、これのみがSIONetのユーザであるＳＥに対して開放されていない。制御情報部には、合致したフィルタの識別子、合致したフィルタの照合得点、同期型統計情報収集フラグ、イベントプレース内、イベントプレース間におけるＴＴＬ（Time To Live）値、イベントプレース内、イベントプレース間におけるホップ数、ホップ属性などの制御情報が設定される。
【００３７】
図７に示すようなエンティティの構成において、ＳＥの機能を説明する。ＳＥは、受信セッションを介して、イベントの取得条件をSI-SWに登録する。これを「フィルタ」と呼ぶ。フィルタには、取得したいイベントの語彙概念（イベントタイプ）、及び、意味情報との照合条件（例えば、語彙”Price”が”$20から$40の範囲”のものを取得対象とする）等を設定する。なお、当該イベントタイプに定義されているすべての語彙との「完全一致」、一部の語彙との「部分一致」、「重み付け一致」など、照合条件をフィルタ単位で選択することができる。
【００３８】
ＳＥは、一つの受信セッションから、複数のフィルタを登録することが可能であるが、同一セッションを介して登録されたフィルタ間は”or”関係を有する。すなわち、一つのイベントに対して、一つの受信セッションは高々１回しか発火しない。取得したいイベントのイベントタイプにワイルドカードを指定した場合には、すべてのイベントタイプが取得の対象となる。また、意味情報との照合条件に１（論理値が真）が設定された場合には、無条件に意味情報との照合条件が満足されたことを意味する。
【００３９】
また、ＳＥは、送信セッションを介して、SI-SWにイベントの送信を行う。このとき、SI-SWはイベントの意味情報部とフィルタとを照合する。具体的には、まず、受信したいイベントタイプであるかどうかをチェックし、これを満足した場合には、意味情報と照合条件をチェックする。この照合の結果、意味情報が照合条件を満足している場合には、合致したフィルタを登録したエンティティを起動するとともに、当該イベントを通知する。
SIONetでは、イベントの送信を「刺激」、フィルタがイベントに合致することを「反応」、合致したフィルタを登録したエンティティを起動しイベント通知することを「発火」と呼ぶ。
【００４０】
＜エンティティの名称付与方法＞
図５に示すように、エンティティ２が”イベントプレースＡ”と命名したイベントプレースを生成する場合を説明する。エンティティ２の所有者は、コントロールパネルを介するなどして、エンティティ２にイベントプレース名を入力する。ここでは、入力等されたイベントプレース名を「イベントプレースＡ」とする。すると、エンティティ制御部は、ＮＥファクトリにSI-SWの生成を依頼し、生成されたSI-SWと、ＮＥなどの内部モジュールとの間にセッションを確立する。さらに、エンティティ制御部は、生成されたSI-SWの名前を「イベントプレース名+ローカルエンティティ名」、すなわち「イベントプレースＡ+エンティティ２」として記憶する。この名前を「グローバルエンティティ名」と呼ぶ。このグローバルエンティティ名の作成がイベントプレースの生成に相当する。
【００４１】
すなわち、SIONetでは、イベントプレースの生成により、必ずしも何らかの管理実体が生成されるとは限らない。つまり、SIONetでは、イベントプレースに属しているエンティティのメンバー管理を、後述するエンティティ間のシェアードリンクにより実現しているため、メンバー管理を行う集中管理部自体が存在しない。そのため、イベントプレースを生成したエンティティが当該イベントプレースから退去しても、当該イベントプレースに残されたエンティティが自律的に自己組織化することにより、当該イベントプレースの運営が継続される。すなわち、イベントプレースから最後のエンティティが退去することが、イベントプレースの消滅に相当する。
【００４２】
このグローバルエンティティ名は、シェアードリンクやセッションを確立する場合に用いられる。図５に示すようなエンティティ２が、イベントプレースＢをさらに生成し、エンティティ１からのシェアードリンクを確立する動作を、図１０を参照して説明する。
【００４３】
まず、既にイベントプレースＡに参加しているエンティティ２が、イベントプレースＢを生成する動作を説明する。エンティティ２のエンティティ制御部は、前述と同様に、ＮＥファクトリに新たなSI-SWを生成させる。エンティティ制御部は、生成された新たなSI-SWにグローバルエンティティ名として「イベントプレースＢ+エンティティ２」を付与する。これにより、イベントプレースＢが生成される。この時点で、エンティティ２は、「イベントプレースＡ+エンティティ２」と「イベントプレースＢ+エンティティ２」という二つのグローバルエンティティ名（SI-SW名）を持つ。
【００４４】
次に、エンティティ１がイベントプレースＡにJoin（参加）する動作を説明する。上述のようにイベントプレースＡ及びイベントプレースＢに参加したエンティティ２は、“アクティブ”状態となっている。“アクティブ”状態のエンティティは、自身の存在を他のエンティティにアドバタイズ（公開）することができるが、その際にはグローバルエンティティ名が公開される。
【００４５】
エンティティ１がエンティティ２を発見し、当該エンティティ２に対してJoin要求を行うとき、エンティティ１は、Join先のエンティティであるエンティティ２のグローバルエンティティ名が「イベントプレースＡ+エンティティ２」である旨をエンティティ２に通知する。
【００４６】
このように、グローバルエンティティ名により、シェアードリンクを確立するSI-SWを一意に特定することが可能になり、ひいては、イベントプレースＡへの参加が可能になる。このように、シェアードリンクやセッションの確立先であるSI-SWはグローバルエンティティ名として仮想化されるため、エンティティの所有者等は、SI-SWを直接意識することはない。
【００４７】
＜ＳＥのプラグイン方法＞
以下に、図１１に示すエンティティへのＳＥの組み込みの動作を説明する。
（１）エンティティの所有者は、コントロールパネルに対して、アプリケーションのプラグインを指示する。このとき、プラグインするアプリケーションの実行ファイル名をパラメータとして与える。
（２）コントロールパネルは、プラグインの指示を受けた旨と、プラグインするアプリケーションの実行ファイル名とをエンティティ制御部に通知する。
【００４８】
（３）エンティティ制御部は、プラグインする実行ファイル名を記憶するとともに、与えられた実行ファイル名を用いて、アプリケーションを起動し、SI-SWと起動したアプリケーションとの間にセッションを確立する。
すなわち、SIONetにおけるプラグインとは、アプリケーションとSI-SWとの間にセッションを確立することに他ならない。SIONetでは、ＳＥ、ＮＥなどのすべての動作実体は、セッションを介して連携する。そのため、プラグイン/プラグアウト（着脱）を容易に実現できるとともに、プラグイン/プラグアウトが他の動作実体に影響を与えない（超疎結合）。この考え方を拡張することにより、後述するようなエンティティ間でのＳＥ共有が実現できる。
【００４９】
＜PREFERENCEアーキテクチャ＞
SIONetは図１２に一例を示すようなリファレンスモデルの考え方を採用している。図１２に示すPREFERENCEアーキテクチャは、フィルタに意味情報を登録し、イベントの意味情報部に配布条件（照合条件）を設定する 御用聞き社会（御用聞き型サイバーソサイアティ）構築に向けたアーキテクチャであり、ブローカレス型配信モデル、ブローカレス型探索モデル、ブローカレス型ポリシーモデルに対するトータルソリューションを提供する。具体的には、ストリームインターフェース、SIONet、COMNetなどから構成される。
SIONetはイベントの伝達層であり、上位層に対してネットワークインタフェースを提供する。ミドルウエア層がコミュニティ（コミュニティネットワーク:COMNet）であり、SIONetのインテリジェンス層に相当する。このレイヤにおいて、情報の局所化、認証、セキュリティ、情報の権利保証、ポリシー制御などが行われる。そして、最上位層がアプリケーション層となっている。このアプリケーション層には、ＳＥが実装される。ＳＥとしては、例えば、個人TV局、メッセージ交換サービスのスマートメッセンジャーなどがある。
【００５０】
このように、SIONetは、分散コンピューティング、情報交換、コラボレーション、メッセージ配信などのあらゆるＰ２Ｐサービス（ＳＥがサービスを提供する）に対して、共通のＰ２Ｐネットワーク基盤を提供するとともに、プラグイン機構の提供により、アプリケーション開発の効率化をサポートする。
【００５１】
＜SIONetにおけるエンティティの役割＞
SIONetは、個々のエンティティが互いに助け合うことにより、ボランティア型のネットワークを構築する形態であり、それぞれが自律分散協調することにより、ネットワークを自己組織化する。例えば、図６の構成において、エンティティ１の生成したイベントプレースにエンティティ２が参加し、その後、エンティティ１が当該イベントプレースから退去する動作を説明する。
【００５２】
予め、エンティティ１はイベントプレースを生成し、当該イベントプレースに参加している。ここに、エンティティ２がエンティティ１に対して、イベントプレースへのJoin要求を行うと、図１３に示すように、エンティティ２にSI-SWが生成され、さらに、エンティティ１及びエンティティ２のSI-SW間にシェアードリンクが確立され、エンティティグループが形成される。
このようにエンティティ１とエンティティ２のSI-SW間にシェアードリンクが確立され、エンティティ２がイベントプレースに参加した後、イベントプレースの生成者であるエンティティ１がイベントプレースから退去するものとする。すると、SI-SW間のシェアードリンクが解除され、以降は、エンティティ２のみでイベントプレースの構築・運営が継続される。このように、個々のエンティティが自己組織化するため、あるエンティティが退去、消失等しても他のエンティティが当該エンティティの機能を果たす。
【００５３】
ＳＩＯＮｅｔでは、目的に応じてエンティティを配置／組み合わせることにより、様々な形態のＰ２Ｐネットワークを構築することができる。また、異なる形態のＰ２Ｐネットワークをシームレスに連携させることもできる。これは、以下を実現させることにより達成される。
（１）すべてのエンティティを、”刺激と発火に基づく連鎖反応”という一元的かつ単純な仕組みで自律分散協調させること
（２）Ｐ２Ｐネットワーク形態の差異をエンティティの配置・運営問題に帰着させること
このように、単一の仕組みで様々な形態のＰ２Ｐネットワークを構築できる点がSIONetの特徴の一つである。
【００５４】
＜シェアードリンク＞
「シェアードリンク（共有リンク）」は、複数の異なるエンティティ間において、双方向のイベント共有を行うための概念である。例えば、図１４に示すように、エンティティ２がエンティティ１に対して、シェアードリンク(SL: Shared Link)の確立要求を行うことにより、図１５に示すように、SI-SW２とSI-SW１との間にシェアードリンクが確立され、新たなエンティティグループが形成される。
すなわち、シェアードリンクは、エンティティグループを形成するための仕組みであり、また、マルチホップの経路でもある。
【００５５】
図１４において、シェアードリンクの確立に成功したエンティティ２には、エンティティ１からイベントプレース名（グローバルエンティティ名）、当該イベントプレースにおけるイベント転送方式（ルーティング方式）、当該イベントプレースのディスクリプション（説明文）、プラグインされているＳＥ情報等のさまざまな情報が送信される。なお、後述するSI-Rによるフィルタ値の設定によって、SI-SW間に様々なイベントルーティング方式を動的に設定できる。以降において、シェアードリンクの確立の動作を説明し、さらに、SI-Rの役割、仕組みを詳述する。
【００５６】
＜シェアードリンクの確立＞
図１４及び図１５を用いて、シェアードリンク確立までの仕組みを説明する。まず、図１４において、エンティティ２がエンティティ１に対して、シェアードリンクの確立要求を発行した場合を考える。
（１）エンティティ２がエンティティ１に対して、シェアードリンクの確立要求を発行する。
【００５７】
（２）図１５に示すように、エンティティ１のエンティティ制御部は、SL1,2（エンティティ２からのイベントを受信するためのシェアードリンク）を確立するために、ＮＥファクトリに、意味情報に基づいてSI-SW間のイベントルーティング（イベント転送）を行うSI-R1,2 を、エンティティ１内部に動的に生成させる。さらに、エンティティ制御部は、エンティティ２がシェアードリンクの確立要求元であることを記憶する。厳密には、エンティティ２のエントリポイントとグローバルエンティティ名（SI-SW２）とをシェアードリンクの確立要求元として記憶する。
【００５８】
（３）SI-R1,2 は、エンティティ２に対してイベント受信セッションの確立要求を行うことでSI-SW２に対してイベント受信セッションを確立する。このとき、SI-SW２に、エンティティ１が受信するイベントの条件を示すフィルタを登録する。さらに、SI-R1,2 は、自身が属するSI-SW１に対して、イベント送信のためのセッションを確立する。このような、SI-Rが確立する送受信セッションの組み合せをシェアードリンクという。これによりSL1,2 が確立され、例えば、ＳＥ４がSI-SW２に対して送出したイベントは、SI-R1,2 を介して、SI-SW１へも送出される。
【００５９】
（４）このとき、SI-R1,2 がSI-SW２に対して登録するフィルタの設定値により、イベントの転送方式を動的に制御できる。その例を以下に示す。
（ａ）SI-SW２に対して送出されたイベントを、無条件にSI-SW１へと転送する。すなわち、すべてのイベントに対して、SI-R1,2 が発火する。これはSI-RがSI-SWに登録するフィルタとして、「取得する語彙概念にワイルドカードを、及び意味情報（語彙）との照合条件に真」を設定することにより可能になる。これを「無条件ルーティング」と呼ぶ。この設定は、シェアードリンク確立時に一度だけ行えばよい。この方式では、無駄なイベント転送と転送先でのイベント照合処理オーバヘッドが発生する可能性があるが、後述するイベントパス確立（ルーティング情報の設定）のためのオーバヘッドが発生しないため、フィルタ登録数がイベント送出数よりも十分大きい場合に有効な方式である。このルーティング方式は、主に、マルチホップ型ブロードキャスト通信に用いられる。
【００６０】
（ｂ）エンティティ１に取って必要なイベントのみをSI-SW２からSI-SW１へ転送する。これにより、不要なイベント転送を行わない。すなわち、特定のイベントに対してのみ、SI-R1,2 が発火する。これは、SI-Rが語彙概念のみ（照合条件は常に真）をフィルタに設定する「語彙概念によるイベントルーティング」と、語彙概念と語彙との照合条件をフィルタに設定する「語彙によるイベントルーティング」に大別される。前者は主にマルチホップ型属性付きマルチキャスト通信に、後者は主にマルチホップ型ユニキャスト通信、マルチホップ型マルチキャスト通信に用いられる。これは、障害処理通知、統計情報通知、アライブ通知、リプライ通知、アドバタイズメント通知などで用いられている。
なお、マルチホップ型ブロードキャスト通信、マルチホップ型属性付きマルチキャスト通信、マルチホップ型ユニキャスト通信、マルチホップ型マルチキャスト通信のようなマルチホップ通信のほかに、SI-Rの設定するフィルタ値により、通信先エンティティのエントリポイントを用いた直接通信も可能である。なお、マルチホップ型ブロードキャスト通信、マルチホップ型属性付きマルチキャスト通信、マルチホップ型ユニキャスト通信、マルチホップ型マルチキャスト通信については後述する。
【００６１】
（４）前述（２）から（３）の手順は、シェアードリンクの確立要求元であるエンティティ２においても同様に行われる。すなわち、エンティティ２のエンティティ制御部は、エンティティ１（SI-SW１）をシェアードリンクの確立要求先として記憶するとともに、SL2,1 を確立するために、NEファクトリにSI-R2,1 を動的に生成させる。この生成されたSI-R2,1 は、上述と同様にSI-SW１にフィルタを登録し、シェアードリンクを確立する。これにより、SI-SW１とSI-SW２の間に、双方向のシェアードリンクが確立され、エンティティ間でイベントを互いに共有することが可能になる。なお、SI-Rがフィルタの登録を行わないことにより、片方向のシェアードリンクを確立すること、すなわち、SI-Rを発火させないことができる。
【００６２】
＜イベントパスの確立＞
イベント転送（イベントルーティング）のための経路選択情報（SI-Rがイベント共有のために登録するフィルタの集合）を「イベントパス」と呼ぶ。例えば、図１５に示すように、エンティティ２とエンティティ３とが各々エンティティ１とシェアードリンクを確立している構成において、エンティティ２のＳＥ３がSI-SW２に対してフィルタを登録した場合を考える。このとき、エンティティ２のSI-R2,1 はＳＥ３の登録したフィルタを、受信セッションを介して、エンティティ１のSI-SW１に登録する。同様に、エンティティ１のSI-R1,3 は当該フィルタを、受信セッションを介して、エンティティ３のSI-SW３に登録する。このようにＳＥ３によるフィルタ登録をトリガに、SI-Rの登録したフィルタがシェアードリンクに基づいて、順次隣接するSI-Rに波及することにより、イベントパスが確立される。これを「イベントパスの設定、もしくは波及」と呼ぶ。
【００６３】
ここで、上述した「語彙概念によるイベントルーティング」のためのイベントパスの確立について説明する。図１５において、「語彙概念によるイベントルーティング」のためのイベントパスを確立するためには、エンティティ２のＳＥ３がSI-SW２に対して登録したフィルタにおいて、SI-R2,1 は、イベントタイプのみ（照合条件は常に真）をエンティティ１のSI-SW１へのフィルタとして設定する。すなわち、ＳＥ３がフィルタ登録した照合条件を活用しない。つまり、イベントタイプのみを活用することにより、例えば、エンティティ１のＳＥ１がイベント送信したとき、イベントタイプのみをSI-SW１において照合し、その結果、SI-R2,1 が発火すると、SI-R2,1 は当該イベントをSI-SW２へと送出し、意味情報との照合をSI-SW２において行う。
【００６４】
また、上述した「語彙によるイベントルーティング」のためのイベントパスの確立について説明する。図１５において、「語彙によるイベントルーティング」のためのイベントパス確立に際しては、エンティティ２のSI-R2,1 は、ＳＥ３が登録したフィルタ値を、そのままエンティティ１のSI-SW１へのフィルタ値として設定する。すなわち、SI-R2,1 は、ＳＥ３がフィルタ登録したイベントタイプと意味情報との両者をエンティティ１のSI-SW１へとフィルタ登録し、SI-SW１において完全なフィルタリングを行う形態である。
【００６５】
そのため、語彙によるイベントルーティング方式では、無駄なイベント転送が全く発生しないが、ルーティングのためのイベントパス設定オーバヘッドが膨大になるため、フィルタ登録数に比べてイベント送出数が十分大きい場合に有効な方式である。一方、イベントタイプに基づくルーティング方式は、前述の２方式の折衷案的な位置付けにある。すなわち、フィルタ登録数とイベント送出数が同程度の場合、もしくは、フィルタ登録数とイベント送出数の比率を予測できないような利用形態において有効である。これらの仕組みにより、意味情報に基づく、イベントのマルチホップ通信が実現される。なお、イベントプレースの生成時、もしくは、ＳＥからのフィルタ登録時に、イベントルーティング方式を指定できる。
【００６６】
イベントパスの設定要求はイベントプレース内のすべてのSI-Rに対して波及するが、ＴＴＬ値により、その波及範囲を制限することができる。図１６を用いて、その動作を簡単に説明する。ここでは説明の便宜上、語彙概念ルーティングのためのイベントパス確立を前提とするが、これに限られるわけではない。また、各エンティティは、同じ語彙概念をアドバタイズ（フィルタ登録）するものとする。また、ＴＴＬ値を２として説明する。
【００６７】
図１６（ａ）において、エンティティ２のSI-Rがイベントパスの設定要求を開始する。ここでは、ＴＴＬ値が２であるため、エンティティ１、エンティティ３、そしてエンティティ４に対してのみイベントパスの設定要求が波及し、その結果、図１６（ｂ）に示すようにイベントパスが確立される。
【００６８】
上述と同様に、エンティティ１１のSI-Rがイベントパスの設定要求を開始すると、エンティティ１０、及びエンティティ９に対してイベントパスが確立される。図１６に示す構成では、エンティティ２のSI-R及びエンティティ１１のSI-Rがイベントパスの設定要求をすると、エンティティ５にはイベントパスが設定されないため、エンティティ２とエンティティ１１の間では、イベントの共有が行われない。つまり、エンティティ２から生起したイベントは、エンティティ５〜１１に連鎖反応せず、エンティティ５〜１１へはイベントが転送されないことになる。
【００６９】
しかしながら、図１６（ｂ）に示すように、エンティティ５のSI-Rがイベントパスの設定要求を開始することにより、エンティティ４、エンティティ５、エンティティ６、エンティティ７、そしてエンティティ９に対してイベントパスが確立される。結果的に、図１６（ｃ）に示すように、エンティティ８を除く、イベントプレース内のすべてのエンティティに対してイベントパスが確立される。
【００７０】
このように、当該語彙概念が当該イベントプレースにおいて、使用頻度の高いもの（評判が高い、流行しているもの）であるならば、最終的に、イベントプレース内にイベントパスの確立が行き渡ることになる。その逆で、あまり流行していない語彙概念は、いずれ淘汰されることになり、これにより緩やかな連鎖反応を実現できる。なお、図１６におけるイベントパス上の数字は、その多重度を示している。
【００７１】
なお、エンティティは、イベントパスの多重度をエンティティプロパティの属性として公開することができる。一方、エンティティプロパティのディスカバリにより、イベントパスの多重度が高いエンティティを発見することができる。このとき、当該エンティティに対して、シェアードリンクの張り替えを行うことにより、同好の志（同好のエンティティ）が緩やかに近傍に集まることができる（同好エンティティの局所化）。エンティティプロパティの詳細については後述する。
【００７２】
分散オブジェクト技術の観点から、イベントパスを以下のように解釈することもできる。世界中に超分散しているエンティティは、エンティティ間でなんらかの「相関関係」を有する。相関関係を与えるものとしては、エンティティ名、グループ名、属性（位置、興味、評判、流行、サービス）など様々なプロパティがある。エンティティは、相関関係に基づいて、エンティティ間の結びつきを持ち分散協調する。この、エンティティの相関関係を与えるものを、エンティティプロパティという。
【００７３】
SIONetでは、この相関関係を語彙概念と語彙により表現し、シェアードリンクに基づいて、イベントパスとして設定する。また、相関関係の強弱が、語彙概念の汎化・特化、イベントパスの多重度などに相当する。すなわち、SIONetでは、イベントパスにより、エンティティ間の相関関係を動的に制御・管理している。これこそが、フィルタによる連鎖反応の制御である。そのため、エンティティは固定的なエンティティ識別子を有していない。
【００７４】
例えば、IPアドレスは、位置に基づいたエンティティの固定的な識別子であるが、SIONetでは、これの代わりに、エンティティプロパティを語彙概念・語彙として記述したものをエンティティ識別子として用いる。エンティティは、これらをフィルタとしてSI-SWに登録することにより、エンティティのプロパティ（エンティティ識別子）を宣言するとともに、自身のプロパティをシェアードリンクに基づいてアドバタイズする。これがイベントパスの波及に相当する。これにより、イベントパスが確立される。
【００７５】
上述したように、SI-Rは、イベント送信とイベント受信の両者の側面を持つネットワークエンティティであり、一般のサービスエンティティと本質的な違いはない。SIONetでは、SI-RのようなSIONetの制御に用いられるエンティティを、サービスエンティティ（ＳＥ）と特に区別して、ネットワークエンティティ（ＮＥ）と呼ぶ。SIONetにおいては、サービスエンティティ、ネットワークエンティティのすべてのエンティティを共通のエンティティとして扱い、さらに、イベント送出とイベント受信、すなわち刺激と発火の連鎖反応という単純かつ一貫性のある共通ロジックに従って自律動作させることにより、すべてのエンティティが自律分散協調可能な超分散・超疎結合アーキテクチャを提供する。
【００７６】
＜シェアードリンクの解除と再確立＞
イベントプレースに参加しているエンティティが、障害に陥ったり、イベントプレースから退去する場合など、様々な理由により当該エンティティがネットワークの運営に関わることができないケースにおいては、残されたエンティティが自己組織化することによりネットワークサービスを継続できることが必要になる。
SIONetでは、このようなケースにおいては、SI-SW間において確立されているシェアードリンクを解除し、さらにシェアードリンクの再確立を行う。その動作を図１７を参照して説明する。
【００７７】
図１７において、シェアードリンク確立要求の先頭数字（図中▲１▼や▲２▼など）は、それらの要求順序を示している。つまり、シェアードリンク確立要求の順序は、まず、エンティティ２からエンティティ１へシェアードリンクの確立要求を行う。次にエンティティ３からエンティティ２へシェアードリンクの確立要求を行う。最後に、エンティティ４からエンティティ２へシェアードリンクの確立要求を行うものとする。なお、ここで、「各エンティティは、同一イベントプレース内においてシェアードリンクの確立要求を高々1回しかできないが、無制限に確立要求を受け付けることが可能なリンクトポロジーに基づいて、シェアードリンクの確立を行う」リンク確立手法を提案する。これにより、シェアードリンクで結合されたエンティティ間に、ループが発生しないことが保証される。すなわち、この手法を用いることにより、隣接エンティティ間のリンク再確立のみで開リンクトポロジーを簡単に実現できる。
【００７８】
上述した順序で確立要求が成功すると、前述した手順で各SI-SW間にシェアードリンクが確立される。シェアードリンクが確立されると、各エンティティのエンティティ制御部は、自身が確立要求を行ったエンティティと、自身への確立を受け付けたエンティティを記憶している。例えば、エンティティ２は、自身が確立要求を行ったエンティティ１と、自身への確立を受け付けたエンティティ３、エンティティ４のリストを保持している。
この状況において、例えば、エンティティ２の退去、減設などが行われる場合、自身のSI-SW２に対して確立されているシェアードリンクの解除要求を発行し、シェアードリンクの解除を行う。その後、各エンティティは新たなシェアードリンクの確立を行う。以下、その動作を説明する。
【００７９】
（１）エンティティ２が退去する場合、エンティティ２のエンティティ制御部は、自身のシェアードリンクを解除する旨を、１ホップのエンティティ(エンティティ１、エンティティ３、エンティティ４)に対して通知する。これは、イベントのＴＴＬ値を１にしてイベント送出を行うことにより可能になる。なお、このとき、自身へのシェアードリンク確立を受け付けたエンティティ(エンティティ３、エンティティ４)に対しては、自身に代わる新たなシェアードリンクの確立要求先として、自身が確立要求を行ったエンティティ１を教える。なお、自身が確立要求を行ったエンティティが存在しない場合には、自身への確立要求元エンティティ（１ホップ先のエンティティ）の中から任意のエンティティを選択して、これを自身に代わるシェアードリンクの確立要求先とする。
【００８０】
（２）エンティティ２のエンティティ制御部は、自身が確立したシェアードリンク(SL2,1 、SL2,3 、SL2,4 )を解除するために、その旨をSI-R2,1 、SI-R2,3 、SI-R2,4 （図示略）に通知する。なお、SI-R2,1 、SI-R2,3 、SI-R2,4 とはエンティティ２のSI-Rであり、上述したように、エンティティ１、エンティティ３、エンティティ４に対し、シェアードリンクSL2,1 、SL2,3 、SL2,4 を確立したものである。これらのSI-Rは、これをトリガとしてエンティティ２のSI-SW２へのセッションを解除する。
【００８１】
（３）エンティティ１のエンティティ制御部は、SI-R1,2 （図示略）に、シェアードリンクSL1,2 の解除を指示する。SI-R1,2 は、シェアードリンクSL1,2 を解除する。エンティティ１は、エンティティ３、エンティティ４からの確立要求を待つ。
（４）エンティティ３、エンティティ４は、エンティティ１と同様に、自身がSI-SW２（エンティティ２のSI-SW２）に対して確立していたシェアードリンク(SL3,2 、SL4,2 )をすべて解除し、エンティティ２からシェアードリンクの確立要求先として教えられた新たなエンティティ(エンティティ１)に対してシェアードリンクの確立要求を行い、シェアードリンクを再確立する。すなわち、上述と同様に、各々のエンティティ制御部は、ＮＥファクトリに各々SI-R3,1 、SI-R4,1 を生成させ、当該SI-R3,1 、SI-R4,1 にシェアードリンクSL3,1 、SL4,1 を確立させる。
【００８２】
上述したように、シェアードリンクの確立処理、再確立処理は、隣接するエンティティ間においてのみ行われ、他のエンティティには影響を与えない。すなわち、全てのエンティティに対するリンクの再構築を必要としない。
【００８３】
なお、エンティティの退去や減設などの正当な手順を踏んだシェアードリンクの解除要求ばかりでなく、エンティティの障害、電源断、セッション（物理的な通信路）の障害などに起因して、シェアードリンクを再確立しなければならないケースがある。しかしながら、このようなケースにおいては、シェアードリンクの再確立時に必要となる代わりのエンティティを教授できない可能性がある。SIONetでは、このような状況に対応するために、各エンティティはｎホップ（ｎは任意の自然数）のイベントを送出することにより、代わりの確立要求先エンティティの把握を行っている。なお、SIONetでは、ＴＴＬ値とホップ属性を用いることにより、更にきめこまかなホップ制御が可能である。ホップ属性の例として、以下のものがある。
【００８４】
▲１▼シェアードリンクの確立要求先エンティティのみをホップ対象とする。
▲２▼シェアードリンクの確立要求元エンティティのみをホップ対象とする。
▲３▼すべてのエンティティをホップ対象とする。
【００８５】
▲１▼のホップ属性を指定した場合の、イベントの流れの例を図１８の破線で示している。図１８において、(i/j)は各エンティティにおいて記憶しているシェアードリンクの確立情報である。iはエンティティがシェアードリンクの確立要求を行った先のエンティティを示しており、一方、ｊはエンティティがシェアードリンクの確立要求を受け付けたエンティティを示している。例えば、エンティティ３の(2/5、6)は、エンティティ３がエンティティ２に対して確立要求を行い、エンティティ５及びエンティティ６から確立要求を受け付けていることを表している。各エンティティがシェアードリンクの確立情報を保持することにより、例えば、エンティティ３が他のエンティティに対して、更なるシェアードリンクの確立要求を行った場合、その要求をエラーとしてリジェクトすることができる。これにより、前述した開リンクトポロジーの一貫性を保証している。この状況において、エンティティ６が３ホップで、上述▲１▼のホップ属性を持つイベントを送出することにより、エンティティ１とエンティティ２の存在を知ることが可能になり、これらがエンティティ３障害時の代替エンティティとなる。
【００８６】
なお、上述したホップ属性は、障害時の代替エンティティの探索ばかりでなく、シェアードリンクの確立を受け付け可能なエンティティの探索、トップ（誰にもシェアードリンクの確立を行っていない）エンティティの探索などに有効である。SIONetでは、トップのエンティティのみが、他のイベントプレースに対して、フェデレーション（連携、イベントプレース間のシェアードリンクに相当）を確立することができる。
【００８７】
＜オンライン増減設の目的＞
SIONetにおけるエンティティ増減設の目的は、主に以下の二つに大別される。
（１）イベントプレースのトータル処理能力向上の観点から、イベントプレース内のエンティティを増設し、イベントのフィルタリング処理を負荷分散する。その逆の観点から、エンティティを減設する。これは、主に、ハイブリッドＰ２Ｐ、バックボーンＰ２Ｐネットワークの運用において用いられる。
（２）動的に生成されたエンティティに対して、シェアードリンクを柔軟に確立することにより、フレキシブルでグローバルなＰ２Ｐネットワークをボトムアップ的に構築する。これは、主に、ピュアＰ２Ｐネットワークの運営において用いられる。
【００８８】
なお、ハイブリッド型Ｐ２Ｐネットワークとは、例えばネットワークプロバイダなどの運営者がホスト等にイベントプレースをあらかじめ生成し、個人の端末等のサービスエンティティがセッションによりイベントプレースと接続することにより構成されるネットワークである。また、ピュア型Ｐ２Ｐネットワークとは、個人の送受信端末たるエンティティがシェアードリンクで各々接続されることにより構成されるネットワークであり、このネットワークのうち、イベントを共有する最小単位がイベントプレースである。バックボーン型Ｐ２Ｐネットワークとは、ネットワーク間の接続形態のことであり、例えば、複数の地域のピュア型Ｐ２Ｐネットワークをハイブリッド型Ｐ２Ｐネットワークを経由して接続した状態のネットワークのことをいう。
【００８９】
＜増減設の形態＞
SIONでは幾つかの増減設形態を提供しているが、ここでは、図１９、図２０に例を示す代表的な形態について述べる。
（１）イベントプレースの合成と分離
図１９（ａ）に示すように、複数のイベントプレースを合成することができる。ここで合成とは、複数のイベントプレースにそれぞれ属するエンティティを、一つのイベントプレース内のメンバーとして集めることを言う。典型的な例として、異なるサービス運営者間の業務提携に基づく、サービス統合（情報共有）が考えられる。
【００９０】
これは、イベントプレースに属する任意のエンティティ、もしくはイベントプレースに対して合成要求を行うことにより、合成要求先イベントプレース内のエンティティに対してシェアードリンクの確立要求が発行される。その結果、SI-SW間にシェアードリンクが確立され、両者の合成が実現される。なお、合成の要求元及び要求先は、それぞれ、エンティティでもイベントプレースでもどちらであってもかまわない。一方、分割する場合には、確立されているシェアードリンクを解除し、それぞれのイベントプレースに分離する。
【００９１】
（２）イベントプレースへの参加と退去
図１９（ｂ）に示すように、イベントプレース内のエンティティ、もしくは、イベントプレースに対してJoin（参加）要求を行うことにより、要求元エンティティにSI-SWが生成される。そして、要求先エンティティに対してシェアードリンクの確立要求が発行されることにより、SI-SW間にシェアードリンクが確立され、当該イベントプレースに参加することができる。
エンティティがイベントプレースから退去する場合には、上述と同様に、エンティティ間のシェアードリンクを解除し、さらに、シェアードリンクの再構築を行い、当該イベントプレースから退去する。このとき、退去したエンティティの状態は、サスペンド状態へと遷移する。
【００９２】
なお、イベントプレース側からエンティティに対してシェアードリンクの確立を要求することにより、当該エンティティをイベントプレース内に取り込むことも可能である。これを吸収という。その逆を分裂という。
（３）エンティティ（SI-SW）の増減設
図２０（ｃ）に示すように、イベントプレース内のエンティティ、もしくは、イベントプレースに対して、エンティティの増設要求を行うと、指定されたエンティティにSI-SWが新たに生成され、既存のSI-SWとの間にシェアードリンクが確立される。一方、イベントプレースにエンティティの減設要求を行うと、指定されたエンティティに対しシェアードリンクの解除要求が発行され、SI-SW間のシェアードリンクが解除された後、シェアードリンクの再確立が行われ、当該エンティティが削除される。このとき、エンティティの状態は、Non-Existentに遷移する。
【００９３】
（４）イベントプレース間のフェデレーション
図２０（ｄ）に示すように、イベントプレース内のエンティティ、もしくは、イベントプレースに対して、フェデレーション（連携）要求を行うことにより、イベントプレース間でイベントを転送するSI-GWが動的に生成され、セッションを介して両イベントプレースが連携する。なお、フェデレーションの要求元及び要求先は、それぞれ、エンティティでもイベントプレースでもどちらであってもかまわない。
【００９４】
＜エンティティのアドバタイズメント＞
図２１、図２２を参照し、エンティティのアドバタイズメント（公開）について説明する。SIONetにおけるエンティティのアドバタイズメントには、以下の２つの観点がある。
観点１：エントランスのアドバタイズメント
観点２：エンティティプロパティのアドバタイズメント
以下、各々の観点について説明する。
観点１：エントランスのアドバタイズメント
ベースイベントプレースは、エンティティに取って、最適なイベントプレースをいもづる式に探索（ディスカバリ）するためのベース（起点）となるイベントプレースである。つまり、ベースイベントプレースがSIONetへのエントランス（入り口）となる。そのため、ベースイベントプレースに参加しているエンティティは、SIONetのエントランスを公開することができる。ここで、エントランスの公開とは、シェアードリンクの確立要求先となるエンティティのエントリポイントとグローバルエンティティ名をアドバタイズすることを意味する。この公開情報は、後述するブロードキャストを用いた探索により発見される。
【００９５】
観点２：エンティティプロパティのアドバタイズメント
シェアードリンクで接続されている任意のエンティティグループ（ベースイベントプレースを含むすべてのイベントプレース）において、各エンティティは自身のエンティティプロパティをアドバタイズすることができる。これが前述したイベントパスの波及に相当する。この公開情報は、後述するディスカバリイベントの送出により発見される。
【００９６】
以下に、エンティティの公開、探索から、エンティティグループ形成までの流れを説明する。なお、以下では、ベースエンティティ、エンティティ１、エンティティ２、エンティティ３、エンティティ４、エンティティ５、エンティティ６はベースイベントプレースに属しており、エンティティ３、エンティティ１１、エンティティ１２、エンティティ１３はイベントプレースαに属しているものとして説明する。
【００９７】
▲１▼図２１に示すように、SIONetソフトウエアをホストにインストールする。
この時点でのエンティティの状態は、前述したように“Non-Existent”である。説明の便宜上、このエンティティをエンティティＹとする。
▲２▼SIONetソフトウエアを実行することにより、エンティティＹは“Non-Existent”から“サスペンド”状態に遷移する。この状態のエンティティは、SIONetからその存在がまだ認知されていない。
【００９８】
▲３▼“サスペンド”状態のエンティティＹは、SIONetの構成要素としてネットワークに参加するために、ベースイベントプレースに属している他のエンティティのエントランス（エントリポイントとグローバルエンティティ名）を探索する。具体的には、ブロードキャストにより、ベースイベントプレースに参加しているエンティティの中から、近傍のエンティティを探索する。ブロードキャストの方法は、実装に依存する。例えば、無線ネットワークで実装されている場合には、無線の到達範囲すべてのエンティティが探索の対象となる。一方、ＩＰネットワークで実装されている場合には、ＩＰブロードキャストもしくはＩＰマルチキャストを行うことになる。図２１では、ブロードキャストによる探索により、エンティティ１（エンティティ１のエントリポイントとグローバルエンティティ名）が発見されたことを表している。なお、ブロードキャストにより、近傍のエンティティを発見できない場合には、Well-Known（周知）のエンティティを利用することもできる。Well-Knownのエンティティをベースエンティティと呼ぶ。なお、ベースエンティティは、ベースイベントプレースを含むすべてのイベントプレース内に存在することができる。
【００９９】
▲４▼エンティティＹは、発見されたエンティティ１に対して、ベースイベントプレースへのJoin（参加）要求を行う。すなわち、エンティティＹは、エンティティ１のエントリポイントに対して、エンティティ１のグローバルエンティティ名をパラメータとしたJoin要求を行う。エンティティＹからのJoin要求を受けたエンティティ１は、自身の状態遷移が“アクティブ”であり、かつ、エントランスやエンティティプロパティが公開モードの場合のみ、当該Join要求を受け付ける。なお、エンティティＹは、最大Join数を超えてJoin要求を発行することはできない。この最大Join数は、エンティティＹのコントロールパネルで、エンティティＹの所有者等が設定可能である。エンティティ１がエンティティＹのJoin要求を受け付けると、上述と同様の動作により、エンティティＹ及びエンティティ１のSI-SW間にシェアードリンクが確立される。これにより、エンティティＹは、ベースイベントプレース内のネットワーク構成要素として自己組織化される。このとき、エンティティＹは、“サスペンド”状態から“アクティブ”状態へと遷移する。
【０１００】
ベースイベントプレースにJoinしたエンティティＹは、エントランスの公開が可能になる。また、エンティティプロパティをアドバタイズすることもできる。エンティティプロパティには、グローバルエンティティ名（及びエントリポイント）、ニックネーム、グループ名、アライブ（存在だけの表明であり、シェアードリンクの確立先情報となるエントリポイントとグローバルエンティティ名は公開しない、エンティティが非公開モードの場合でも公開の対象）、ディスクリプション（エンティティの説明文）、属性などがある。属性には、プラグインされているＳＥ情報、イベントパス多重度、イベントプレース情報などがある。なお、エンティティプロパティの記述言語としては、XMLなどがある。
【０１０１】
図２１において、例えばエンティティ３のエンティティ制御部は、エンティティ３が同時に参加しているイベントプレースαをエンティティプロパティの属性として公開することができる。さらに、エンティティ制御部は、現在Joinしているイベントプレースばかりでなく、過去にJoinしたイベントプレースのイベントプレース情報を公開することもできる。このイベントプレース情報とは、例えば、イベントプレースのディスクリプション（イベントプレースの説明文、説明情報）や、当該イベントプレースに参加する際にシェアードリンクを確立したエンティティ（意味情報スイッチ）のグローバルエンティティ名（イベントプレース名+エンティティ名、コネクション確立情報）、エントリポイント（エントリポイント情報）などである。この、過去にJoinしたイベントプレース情報をエンティティが保持できる数は任意とし、例えば、コントロールパネルによりエンティティ所有者等が設定できるものとする。この公開されたイベントプレース情報を取得したエンティティは、当該イベントプレース情報をコントロールパネル等により出力することで当該エンティティ所有者に提示する。これにより、エンティティ所有者は、他のイベントプレースの存在を認識することが出来る。
SIONetでは、どこにどのようなイベントプレースがあり当該イベントプレースではどのようなサービスを提供しているか、というようなイベントプレース情報を集中管理する機能がないので、イベントプレース情報を取得しようとする場合、他のエンティティのエンティティプロパティからイベントプレース情報を取得する必要がある。現在参加しているイベントプレースのみならず、過去に参加したイベントプレース情報を公開することにより、イベントプレース情報を取得する機会が増え、自身の求めるサービスを提供するイベントプレースに参加できる確立が高くなる。
【０１０２】
エンティティＹのエントランスの公開時には、これらのエンティティプロパティを、エンティティ内の意味情報スイッチにフィルタとして登録することにより、エンティティプロパティがシェアードリンクに基づいて他のエンティティに波及し、イベントパスが確立される。基本的には、イベントパスの確立要求がイベントプレース内のすべてのエンティティに対して波及するが、ＴＴＬ値で、イベントパス確立要求の波及範囲を制限することができる。なお、グローバルエンティティ名はマルチホップ型ユニキャスト通信時の識別子として、グループ名はマルチホップ型マルチキャスト通信時の識別子として、属性はマルチホップ型属性付きマルチキャスト通信時の識別子として用いられる。例えば、マルチホップ型ユニキャスト通信の代表例として、イベント受信エンティティからイベント送信元エンティティへのリプライ通知がある。
【０１０３】
すなわち、グローバルエンティティ名はマルチホップ型ユニキャスト通信とは、グローバルエンティティ名で特定されるエンティティのSI-SWからｎホップのイベントを送信する通信方式である。また、マルチホップ型マルチキャスト通信とは、グループ名で特定されるグループに属するエンティティのSI-SWにｎホップのイベントを送信する通信方式である。また、マルチホップ型属性付きマルチキャスト通信とは、自身と同様の属性のエンティティのSI-SWにｎホップのイベントを送信する通信方式である。また、マルチホップ型ブロードキャスト通信とは、任意のエンティティのSI-SWにｎホップのイベントを送信する通信方式である。
【０１０４】
▲５▼図２２において、ベースイベントプレースに参加したエンティティＹは、「自身が参加したいイベントプレース」を探索するためのディスカバリイベントを送出することにより、「自身のニーズに合致するエンティティプロパティ」を公開しているエンティティを探索する。このディスカバリイベントは、SIONetの制御のために用いられるイベントであり、ＳＥが送出するイベントと同等のものである。ディスカバリイベントとは、ＮＥを発火させるためのイベントであり、イベントの意味情報部には、エンティティプロパティとの照合条件が設定される。すなわち、SIONetにおける新たな機能追加とは、新たな語彙概念と語彙を規定することを意味する（仕組みの追加ではなく、連鎖反応条件の追加）。これにより、単一な仕組み（連鎖反応）だけで、様々な機能追加を可能にしている。
【０１０５】
ここでは、探索の結果、エンティティ３が発見されたものとする。上述したように、エンティティ３は、ベースイベントプレースと同時にイベントプレースαに参加している。エンティティ３を発見したことにより、エンティティＹはイベントプレースαの存在を知ることができる。
▲６▼エンティティＹは、エンティティ３に対してイベントプレースαへのJoin要求を発行し、イベントプレースαに参加する。なお、エンティティ３は、前述したように、自身の状態遷移が”アクティブ”であり、かつ、公開モードのときに、Join要求（シェアードリンクの確立要求）を受け付ける。
【０１０６】
▲７▼さらに、エンティティＹは、イベントプレースαにおいて、同様の探索のためのイベントを送出することができる。これにより、自身のニーズに合致する新たなエンティティを発見することができる。例えば、ここでは、エンティティ１２が発見されたものとする。すなわち、エンティティＹは、ベースイベントプレースにおいて発見することができなかったエンティティ１２を、エンティティ３を介して発見できるということを意味している。このような操作を繰り返すことにより、自身のニーズに合致したイベントプレースに、次第にたどり着くことが可能になる。
【０１０７】
ここで示したアドバタイズメント方式は以下の効果がある。
（１）エンティティの公開情報を管理するブローカ（管理部）が存在しないため、耐障害性に強い自己組織化ネットワークを低コストで構築することができる。また、膨大な数の公開情報（エントリポイントやエンティティプロパティ）をブローカで管理することは現実的でない。
（２）エンティティに取って相応しいイベントプレースを、芋づる式に絞り込むことができるので、効率的に所望のイベントプレースを探索することができる。例えば、連鎖反応の波及範囲（ディスカバリイベントのホップ数、及び、エンティティプロパティのためのイベントパス設定要求の波及範囲）がＴＴＬ値で制限されたとしても、上述のように、エンティティ３経由でエンティティ１２を発見し、その結果、エンティティ１２が同時に属している別のイベントプレースを発見することができる。なお、連鎖反応の波及範囲を制限することにより、ネットワークトラフィック（イベントの転送回数、イベントパス設定要求の転送回数）を軽減することができる。
【０１０８】
なお、自身は情報を提供することなく（例えば、エンティティプロパティを公開することなく）、他のエンティティからの情報提供を受けるだけのエンティティは、ペナルティーとして、強制的にシェアードリンクが解除され、一定条件を満足しない限り、再度イベントプレースに参加できないようにすることもできる。
【０１０９】
＜ＳＥの共有方法（自動配信）＞
以下に、ゲームイベントプレースにおけるＳＥ（ゲームアプリケーションプログラム）の共有を例に、ＳＥの共有方法の仕組みを示す。
（１）ゲームイベントプレースの運営者であるエンティティ２の所有者はエンティティ２のコントロールパネルを介してイベントプレース名を付与する。なお、ここで付与されたイベントプレース名は「ゲーム」であるものとして説明する。
【０１１０】
（２）エンティティ２のエンティティ制御部は、上述と同様に、ＮＥファクトリにより生成されたSI-SWに対してグローバルエンティティ名「ゲーム＋エンティティ２」を付与する。これにより、イベントプレースが生成される。このとき、ゲームイベントプレースの生成者であるエンティティ２は、イベントプレース生成時に当該イベントプレースに自動的に参加する。
（３）エンティティ２の所有者は、当該エンティティ２のコントロールパネルに対して、ゲームアプリケーションプログラム（ＳＥ）のプラグインを指示する。このとき、プラグインするアプリケーションの実行ファイル名、及び、ＳＥ共有の有無をパラメータとして与える。
【０１１１】
（４）エンティティ２のコントロールパネルはこの旨をエンティティ制御部に通知する。
（５）エンティティ２のエンティティ制御部は、プラグインする実行ファイル名を記憶するとともに、与えられた実行ファイル名を用いてアプリケーション（ＳＥ）を起動し、上述と同様に、SI-SWとアプリケーション間にセッションを確立する。すなわち、SIONetにおけるプラグインとは、アプリケーションとSI-SWとの間にセッションを確立することを意味する。
【０１１２】
（６）エンティティ２のエンティティ制御部は、エンティティ２のエンティティプロパティをアドバタイズ（公開）する。エンティティ２のエンティティプロパティの公開形態としては、例えば、以下のものがある。
・エンティティ２がベースイベントプレースに参加し、ベースイベントプレース内で、エンティティ２のエンティティプロパティを公開する。
・エンティティ２が、芋づる式探索を行うことにより、ゲームイベントプレースと関係の深いイベントプレースを発見、参加し、当該イベントプレース内で、エンティティ２のエンティティプロパティを公開する。
・エンティティ２をベースエンティティとする。すなわち、エンティティ２のエンティティプロパティ（エントリポイントとグローバルエンティティ名）を周知する。
【０１１３】
（７）エンティティ２の存在を知ったエンティティ１が、エンティティ２に対して、ゲームイベントプレースへの参加を要求する。
（８）この要求が承認された場合、エンティティ１は、エンティティ２に対して、シェアードリンクの確立を要求する。そして、上述と同様に、エンティティ１とエンティティ２の間にシェアードリンクが確立する。
（９）シェアードリンクが確立された場合、シェアードリンクの確立要求先（エンティティ２）は確立要求元（エンティティ１）に対して、当該イベントプレース内でイベントの送受信に必要な情報を返却する。具体的には、例えば、イベントプレース名（グローバルエンティティ名）、参加したイベントプレースがベースイベントプレースであるか否か、当該イベントプレースにおけるイベント転送方式（ルーティング方式）、イベントプレースのディスクリプション、プラグインされているＳＥ情報（ＳＥ共有が有りの場合）等である。
【０１１４】
ＳＥ共有を共有する場合にシェアードリンク確立要求元に返却するＳＥ情報とは、具体的には、例えば、上述したプラグインするアプリケーションの実行ファイル名や当該アプリケーションのファイル等である。
（１０）当該ファイルを受けたエンティティ１のエンティティ制御部は、上述と同様に、与えられた実行ファイル名を用いてアプリケーションを起動し、エンティティ１内のSI-SWとアプリケーションとの間にセッションを確立する。これにより、エンティティ１内部に、ゲームアプリケーションプログラムをＳＥとしてプラグインする。
【０１１５】
すなわち、イベントプレースへの参加とは、シェアードリンクにより結合されたエンティティグループを形成し、プラグイン済みのアプリケーションプログラムを参加者が共有することを意味する。これにより、イベントプレースに参加するだけで、当該イベントプレース内のメンバーであるエンティティが、プラグインされているアプリケーションを、自動的に利用することが可能になる。なお、エンティティ１がゲームイベントプレースから退去するとき、プラグインされたゲームアプリケーションプログラムは、プラグアウトされる。なおその際、エンティティ１は、受信した当該ファイルを保有しつづけることもできるし、プラグアウト時に、当該ファイルが削除されることもある。
【０１１６】
上述した動作は、ピュア型のＰ２Ｐネットワーク環境でのアプリケーション共有である。そのため、アプリケーションプログラムの配信は、シェアードリンク確立先エンティティと確立元エンティティの２者間でのみ行われるため、シェアードリンクにより既に結合されている他のエンティティに対して影響を与えない。すなわち、ファイル転送のため処理は２者間に局所化されるため、スケーラブルなＳＥ共有を達成することができる。
【０１１７】
＜ビジネスモデル＞
ここで、上述したSIONetを、サービスとして提供する実施例を説明する。
（１）クライアントサーバモデル
予め決められたエンティティのみでイベントプレースを運営する形態である。すなわち、予め決められたエンティティのみが当該イベントプレースに参加(Join)することが可能であり、参加を許されたエンティティは、エンティティ間のシェアードリンクを確立することにより、エンティティグループを構成する。一方、それ以外のエンティティは当該エンティティグループに対してセッションを確立し、当該セッションを介したイベントの送受信を行う。すなわち、イベントプレース（予め定められたエンティティのグループ）がサーバであり、その以外のエンティティがクライアントに相当する。このビジネスモデルでは、エンティティグループのメンバーである各エンティティは、自律分散コンピュータとして振舞い、任意のエンティティが障害に陥った際には、残されたエンティティが自己組織化しイベントプレースの運営を継続する。また、サーバの処理能力向上を図りたい場合には、新たなエンティティを当該イベントプレースに参加させれば良い。そのため、従来のサーバ実現方式と比べて、耐故障性に強く、安価で、スケーラブルなサーバを実現することができる。
【０１１８】
（２）ハイブリッドモデル
例えば、ゲームイベントプレースの運営者となるエンティティは、ゲームイベントプレースを生成し、当該イベントプレース内でのベースエンティティとなる。一方、ゲームイベントプレースのユーザとして位置付けられるエンティティは、当該イベントプレースに参加することにより、当該イベントプレースでのサービスを享受する。従来のクライアントサーバモデルでは、ユーザ数の増加に比例して新たな設備投資（CPUパワー、ストレージ、通信帯域など）が必要とされたが、本ビジネスモデルは、ユーザがイベントプレースに参加することにより、ユーザ自身のエンティティをサービス運営のために提供するため、イベントプレース運営者は新たな設備投資を必要としない。そのため、安価で、スケーラブルなＰ２Ｐサ-ビス環境を構築できる。なお、ベースエンティティにおいて、当該イベントプレースに参加するユーザ（エンティティ）の認証、課金が可能である。また、ベースエンティティは、ディスカバリイベントを送出することにより、エンティティグループの中から、シェアードリンクの確立が可能なエンティティ（代替エンティティ）を発見し、発見されたエンティティを参加希望のエンティティに対し通知し、両者の間でシェアードリンクを確立させることも可能である。
【０１１９】
（３）ピュアモデル
すべてのエンティティが自由にイベントプレースに対して参加（退去）することが可能なビジネスモデルである。
上述したように、SIONetでは、運営・配置問題に帰着することにより、様々なビジネスモデルを共通の仕組みで実現できる。そのため、開発工数、規模、デバッグ効率、維持管理の容易性等に大きな効果を与える。
【０１２０】
なお、上述したように、“サスペンド”状態のエンティティは、エントランスやエンティティプロパティを公開することはできない。“サスペンド”状態のエンティティは、任意のイベントプレースにJoinすることにより“アクティブ”状態に遷移する。“アクティブ”状態のエンティティのみが、エントランスやエンティティプロパティを公開することが可能である。また、ベースイベントプレースにJoinしているエンティティのみがエントランスの公開が可能である。「コントロールパネルにより、公開が指示されている」かつ「当該エンティティに対するセッション（シェアードリンク）の確立数がデフォルト値を超えていない」を満足するとき、エンティティはエントランスやエンティティプロパティを実際に公開できる。例えば、エンティティの所有者がコントロールパネルを用いて公開を指示しても、デフォルト値を超えてシェアードリンクが確立している場合には、自動的に非公開モードとなる。なお、デフォルト値は、コントロールパネルで設定可能であり、例えば、エンティティの所有者が、当該エンティティの能力等により設定することができる。
【０１２１】
なお、ネットワークエンティティ、ネットワークエンティティファクトリ、
エンティティ制御部、コントロールパネル、サービスエンティティ、意味情報スイッチ、意味情報ルータ、意味情報ゲートウエイは専用のハードウェアにより実現されるものであってもよく、また、メモリ及びＣＰＵ（中央演算装置）により構成され、その機能を実現するためのプログラムをメモリにロードして実行することによりその機能を実現させるものであってもよい。
【０１２２】
また、ネットワークエンティティ、ネットワークエンティティファクトリ、
エンティティ制御部、コントロールパネル、サービスエンティティ、意味情報スイッチ、意味情報ルータ、意味情報ゲートウエイの機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより実現させてもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
【０１２３】
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【０１２４】
［この発明の実施形態］
以下、まず本発明の基本的な考え方について説明する。
本発明においては、イベント受信者がイベント送信元に対して返信する返信情報をリプライ通知、もしくは、リプライイベントと呼ぶ。
たとえば、エンティティ１が送出したイベントに対して、エンティティ２が発火した場合を考えると、エンティティ２は、エンティティ１に対して、返却情報を送信することができる。この返却情報が、リプライ通知、もしくは、リプライイベントに相当する。
【０１２５】
SIONetでは、リプライ通知の制御方法として、以下の三通りの方法を提供する。
▲１▼サービスエンティティがイベントパスを確立する方法
サービスエンティティ間で、予めリプライ通知のための意味情報を規定しておく。そして、各サービスエンティティが、当該意味情報の取得条件をフィルタとして登録することにより、イベント転送用シェアードリンクにイベントパスが確立される。
このイベントパスにより、リプライイベントのための連鎖反応が引き起こされ、イベント送出元のエンティティに対して、リプライイベントが転送される。
【０１２６】
▲２▼エンティティマネージャがイベントパスを確立する方法
SIONetがネットワークエンティティのために予約している意味情報を用いて、エンティティマネージャが、イベント転送用シェアードリンクにリプライイベントのためのイベントパスを確立する。
これは、シェアードリンク確立時に、高々一回確立するだけあり、当該イベントパス確立のための処理を静的な固定分オーバヘッドとしてみなすことができる。
【０１２７】
▲３▼リプライイベント用シェアードリンクにイベントパスを確立する方法
イベント転送用シェアードリンクに基づいたイベント転送をトリガに、リプライイベント用シェアードリンクに対して、リプライイベントのためのイベントパスを動的に確立する。
この方法は、イベントを送出したエンティティの数に比例して動的にイベントパスが確立されるため、比例分オーバヘッドが発生する。
【０１２８】
以下、図１、図２６、２７を用いて、その仕組みを詳述する。
図１に示すように、今、エンティティ１〜３がそれぞれシェアードリンクを介して接続されてイベントプレースを形成している場合について考える。
図１において、エンティティ１とエンティティ２は、シェアードリンクＳＬ１，２、シェアードリンクＳＬ２，１を、エンティティ１とエンティティ３とは、シェアードリンクＳＬ１，３、シェアードリンクＳＬ３，１をそれぞれ確立している。
【０１２９】
シェアードリンクＳＬ１，２、ＳＬ２，１、ＳＬ１，３、ＳＬ３，１は、それぞれイベント転送用シェアードリンクとリプライイベント用シェアードリンクとからなる。
イベント転送用シェアードリンクは、他のエンティティが内包する意味情報スイッチから、自己が内包する意味情報ルータへの間で設定される受信セッション▲１▼と、自己が内包する意味情報ルータから、同様に自己が内包する意味情報スイッチへの間で設定される送信セッション▲２▼とからなる。
また、リプライイベント用シェアードリンクは、自己が内包する意味情報スイッチから、同様に自己が内包する意味情報ルータへの間で設定される受信セッション▲３▼と、自己が内包する意味情報ルータから、他のエンティティが内包する意味情報スイッチへの間で設定される送信セッション▲４▼とからなる。
【０１３０】
図１に示すイベントプレースにおいて、エンティティ２のサービスエンティティであるＳＥ２が、図２６に示すイベントを送出する場合を考える。
図２６に示すように、ＳＥ２が送出するイベントは、意味情報制御部と、制御情報部と、データ部とから構成される。
意味情報制御部は、イベントの転送属性を示すイベントのルーティング制御用の意味情報部と、内部エンティティが設定する内部エンティティ用の意味情報部とからなる。制御用の意味情報には、イベント属性情報として、イベント種別、ホップ属性、ＴＴＬ、転送元エンティティが設定され、フィルタに登録されるイベント転送条件との照合に用いられる。内部エンティティ用の意味情報には、内部エンティティの属性情報が設定され、イベントパスとの照合に用いられる。
例えば、イベント属性として、ＴＴＬ：２と設定した場合、イベントパスの確立をホップ段数が２の範囲内のエンティティ装置までに制限することができる。また、すべてのエンティティ装置において、予め、例えばＴＴＬ：−１をホップ段数無制限と規定しておくことで、ホップ段数によるイベントパスの確立範囲の制限しないことも可能である。
制御情報部には、送出元エンティティ名が設定される。なお、ＳＥ２が使用しているセッションの番号やイベント番号を任意で設定してもよい。この場合、セッションの番号はリプライイベントにより発火させる内部エンティティを限定させるために用いられる。また、イベント番号は送出イベント単位にリプライイベントによる連鎖反応を制御するために用いられる。たとえば、イベント送出後に、当該イベントに対するリプライ通知をキャンセルする場合などに用いられる。
【０１３１】
ここで、ＳＩ−Ｒ１ , ２は、図２７に示すように、ＳＩ−ＳＷ２に対してフィルタ１−２／eを登録しているとする。
図１に示すように、フィルタ１−２／eは、
ホップ属性＝＝上流 ｏｒ 上下流
ＴＴＬ≧１ ｏｒ ＴＴＬ＝−１
であり、ＳＥ２が送出する送出イベントの意味情報部と合致することから、当該フィルタが反応し、セッション▲１▼に刺激が与えられる。その結果、ＳＩ−Ｒ１ , ２が発火することになる。なお、以下、説明の簡略化の観点から、イベントパスとの照合は合致するものとして説明する。
【０１３２】
このとき、ＳＩ−Ｒ１ , ２は、受信セッション▲３▼を介して、リプライイベントを発火させるためのフィルタ１−２／rを登録するとともに、送信セッション▲２▼を介して、受信したイベントを転送する。その結果、フィルタ３−１／eが反応し、ＳＩ−Ｒ３ , １が発火する。
【０１３３】
同様に、ＳＩ−Ｒ３ , １は受信セッション▲３▼を介して、フィルタ３-１／rを登録するとともに、送信セッション▲２▼を介してイベントをＳＩ−ＳＷ３に送出する。
ここでは、その結果、仮にＳＥ３が発火するものとする。
【０１３４】
以下、発火したＳＥ３がイベントを受信し、当該イベントに対してリプライ通知を行う場合を考える。
このときＳＥ３が送出するリプライイベントの構造を図２６に示す。ＳＥ３が送出するリプライイベントは、上記イベントと同様に、意味情報部（制御用）、意味情報部（内部エンティティ用）、制御情報部、データ部戸から構成される。意味情報部（制御用）には、受信イベントの制御情報として、イベント種別と、エンティティ名、セッション番号、イベント番号が設定され、リプライイベントの転送条件との照合に用いられる。
このリプライイベントにより、ＳＩ−Ｒ３ , １が受信セッション▲３▼を介して発火し、そして、ＳＩ−Ｒ３ , １が送信セッション▲４▼を介してイベント送信を行うことにより、ＳＩ−Ｒ１ , ２が発火し、最終的に、ＳＥ２が発火する。
【０１３５】
このように、ＳＥ２が送出したイベントの転送を契機に、リプライ用シェアードリンクに対して、リプライイベントのためのイベントパスが確立される。
なお、イベントパス多重度において説明したように、エンティティ間のリレーションシップ強度は、イベントパスの重み値であるイベントパス多重度により管理される。このイベントパス多重度（リレーションシップ強度）は、時間の経過とともに減衰する。すなわち、時間の経過とともに、予め設定された値（実数値）だけ現行の多重度を減算する。そして、多重度がゼロになるとイベントパスが強制的に解除されることになる。一方、リプライイベントによりＳＩ−Ｒが発火すると、予め設定された値だけ現行の多重度を加算する。このように、リプライイベントによるＳＩ−Ｒの発火率に基づいて、リレーションシップ強度が動的に変更され、イベントパスのライフタイム（寿命）が決定されることになる。
この仕組みは、イベント転送用シェアードリンクに対して確立されたイベントパスにも適用され、イベントパスの寿命管理とともにリレーションシップ強度の表現手段に用いられる。
【０１３６】
図２８にSIONetが具備する通信方式を示する。SIONetは、ブロードキャストモード、マルチキャストモード、ユニキャストモード、リプライ通知などの通信モードを提供する。これらの通信モードは、エンティティ間の連鎖反応の仕方を動的に制御することで可能になる。
すなわち、意味情報ルータがフィルタとして登録するフィルタ値により、エンティティ間の連鎖反応（イベントルーティングやエンティティ間のリレーションシップ）の仕方を制御することが可能となる。
このように、SIONetでは、「連鎖反応」という一元的な仕組みしか存在しない。そして、機能追加は、新たに規定された意味情報を追加することで達成される。
【０１３７】
従来アーキテクチャでは、機能追加は新たなメソッド（機能プログラム）の追加を意味していた。すなわち、機能の数だけメソッドを作成していた。しかし、このような方法では、迅速なシステム開発、開発規模の最小化、デバック工数の削減、開発費用の削減、維持管理の容易性などを望むことは到底不可能となる。
SIONetでは、一旦、連鎖反応のためのメソッドを作成してしまえば、それ以上、新たなメソッドを追加する必要はない。すなわち、メソッド作成後は、必要に応じて新たな連鎖反応を引き起こすための意味情報（データ）を追加すれば良い。
【０１３８】
以上は、SIONetにおける重要なコンセプトの一つであり、以下に、個々の通信機能について説明する。
（Ａ）ブロードキャスト
ブロードキャストでは、イベントプレース内のすべてのエンティティに対して、イベントが転送される。そのため、転送されたイベントによりエンティティが発火するかどうかは、当該エンティティにおけるフィルタとの照合により決定される。これは、無条件ルーティングのイベントパスを確立することにより実現される。なお、このイベントパスは、イベント送信用シェアードリンクの確立時に一度だけ設定され、シェアードリンクの再確立が行われるまで変更されることはない。ブロードキャストモードは、IPマルチキャストやGnutellaの転送方式と等価モデルとして扱うことができる。
【０１３９】
（Ｂ）マルチキャスト
イベントプレースに所属するエンティティの中から、任意の条件を満足するエンティティに対してのみイベントを転送する。これは、語彙概念ルーティングのためのイベントパスを確立することにより実現される。なお、イベントパスの確立契機、確立方法は、キャッチアップモードと探索モードでそれぞれ異なる。
【０１４０】
（Ｃ）ユニキャスト
特定のエンティティに対してのみイベントを転送する。これは、語彙ルーティングのためのイベントパスを確立することにより実現される。なお、イベントパスの確立契機、確立方法は、キャッチアップモードと探索モードでそれぞれ異なる。
【０１４１】
（Ｄ）リプライ通知
イベント受信者がイベント送信元に対して、イベントのリプライ通知を行う場合に、イベント送信元に対して、リプライイベントが転送される。これには、リプライイベント用シェアードリンクに語彙ルーティングのためのイベントパスを設定する方法、イベント転送用シェアードリンクにイベントパスを確立する方法などがある。
【０１４２】
図２９は、分散ファイル検索を例に用いて、SIONetの通信方式と他の通信方式を比較した結果を示す。
ネットワークOS等における分散ファイル検索は、一般的に、図３０に示すように、IPブロードキャストを用いて実現される。
たとえば、ファイルの公開を行った端末は、ポート番号１０に対して送信されたパケットを受信する。一方、ファイル検索の要求元である端末Xは、IPブロードキャストアドレス（全端末）とポート番号１０を指定して、ファイルαの検索パケットを送出する。
そのため、ファイルの公開、つまり、ポート１０番でのパケット受信を指示していない端末Bに対しても検索パケットが送出され、その結果、当該パケットは端末Bで破棄されることになる。一方、ファイルβを公開している端末Cは、検索パケットを受信した後、当該パケットとの照合の結果、これを破棄することになる。
このように、IPブロードキャストを用いたファイル検索では、不要な検索パケットの送出と不要な照合処理が発生する。
【０１４３】
一方、IPマルチキャストを用いた分散ファイル検索では、たとえば、ファイルの公開を行った端末が、マルチキャストグループに参加する。そして、ポート番号１０に対して送信されたパケットを受信する。
一方、ファイルの検索を行う端末は、IPマルチキャストアドレス（グループに属する全端末）とポート番号１０指定して、ファイルαの検索パケットを送出する。
そのため、マルチキャストグループに属するメンバー端末に対してのみ検索パケットが送出されることから、当該パケットがメンバー以外の端末に送出されることはないが、ポート１5番でのパケット受信を要求している端末Bに対して、当該パケットが送出され、その結果、端末Bにおいて当該パケットが破棄されることになる。
また、ファイルβを公開している端末Cとの照合処理により、ここでもパケットが破棄されることになる。
【０１４４】
この方式が、概念モデル上、SIONetのブロードキャストモード（無条件ルーティング）、および、Gnutellaの通信方式に相当する。
SIONetのブロードキャストモード、および、Gnutellaは、IPマルチキャストを用いて実現されているわけではないが、グループ内の端末すべてにパケットを送信し（SIONetでは、グループ内のすべてのエンティティにイベントを送信することをブロードキャストと言う）、すべての端末において、受信パケットとの照合を行うという観点からモデル化すれば、３者を等価モデルとして位置づけることができる。
これに対して、SIONetのマルチキャストモードでは、ファイルαの探索パケットが端末Aと端末Cに対してのみ送出され、端末Bに対して送出されることはない。したがって、SIONetにおいては、不要なパケット送信がネットワークトラヒック増を引き起こすという問題を解消することができる。
【０１４５】
以下、本願発明のエンティティ装置の一実施形態について説明する。上述したように、本実施形態のエンティティ装置は、意味情報スイッチと、意味情報ルータとから構成される。
例えば、図１において、意味情報スイッチ（ＳＩ−ＳＷ１〜３）は、上述したように、フィルタとして登録された意味情報と、イベントに付与された意味情報とを照合し、その結果発火したイベント受信エンティティを起動するスイッチであって、具体的には、送信部、受信部、照合部、制御部とから構成される。
送信部は、照合部で合致、すなわち、発火したイベントをイベントの送信先に送信する。
受信部は、イベント送信元のエンティティ装置からイベントを受信する。
照合部は、第１のフィルタ（例えば、エンティティ装置１におけるフィルタ１−２／ｅやエンティティ装置３におけるフィルタ３−１／ｅ）と一致するイベントを受信した他のエンティティ装置（例えばエンティティ装置３）より受信するリプライイベントが示す意味情報と、意味情報ルータが保持する第２のフィルタ（例えばＳＩ−Ｒ１，２が保持するフィルタ１−２／ｒやＳＩ−Ｒ３，１が保持するフィルタ３−１／ｒや）とが一致するか否かを照合する。
制御部は、照合結果に基づいて、リプライイベントのイベントルーティングを制御する。すなわち、上述したように、ＳＥ２が送出したイベントに対するリプライ通知をＳＥ３が送出した場合、エンティティ装置１において、意味情報スイッチ１は、意味情報部（制御用）に設定されるイベント種別と、エンティティ名、セッション番号、イベント番号とを照合することでＳＩ−Ｒ３ , １が受信セッション▲３▼を介して発火し、そして、ＳＩ−Ｒ３ , １が送信セッション▲４▼を介してリプライイベント送信を行うことにより、ＳＩ−Ｒ１ , ２が発火し、最終的に、ＳＥ２が発火する。
【０１４６】
意味情報ルータは、イベントの取得条件を示す第１のフィルタと、イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタとを保持する。なお、意味情報ルータは、予めイベントの取得条件を示す第１のフィルタのみを保持することも考えられる。
この場合、意味情報スイッチの照合部は、他のエンティティ装置より受信するイベントが示す意味情報と、意味情報ルータが保持する第１のフィルタとが一致するか否かを照合し、制御部は、照合結果に基づいて、イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタを意味情報ルータに設定する。そして、さらに、照合部は、第１のフィルタと一致するイベントを受信した他のエンティティ装置より受信するリプライイベントが示す意味情報と、第２のフィルタとが一致するか否かを照合し、制御部は、照合結果に基づいて、リプライイベントのイベントルーティングを制御する。
【０１４７】
したがって、本実施形態のエンティティ装置によれば、刺激と発火によってエンティティの連鎖反応の仕方を動的に制御する自律分散ネットワークにおいて、イベント受信者がイベント送信元に対してイベントのリプライ通知を行うことができる効果が得られる。
【０１４８】
以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【０１４９】
上述のエンティティ装置は、内部に、コンピュータシステムを有している。
そして、上述したリプライ通知制御処理に関する一連の処理の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。
すなわち、上記エンティティ装置における、各処理手段、処理部は、ＣＰＵ等の中央演算処理装置がＲＯＭやＲＡＭ等の主記憶装置に上記プログラムを読み出して、情報の加工・演算処理を実行することにより、実現されるものである。
ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。
【０１５０】
【発明の効果】
以上説明したように、本発明は、第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタとイベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタとを保持するエンティティ装置が、第１のフィルタと一致するイベントを受信した第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するリプライイベントが示す意味情報と、第２のフィルタとが一致するか否かを照合し、照合結果に基づいて、リプライイベントのイベントルーティングを制御するので、刺激と発火によってエンティティの連鎖反応の仕方を動的に制御する自律分散ネットワークにおいて、イベント受信者がイベント送信元に対してイベントのリプライ通知を行うことができる効果を得ることができる。
【０１５１】
また、本発明は、第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタを保持する意味情報ルータを有するエンティティ装置が、第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するイベントが示す意味情報と、第１のフィルタとが一致するか否かを照合し、照合結果に基づいて、イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタを意味情報ルータに設定し、第１のフィルタと一致するイベントを受信した第ｌ（ｌは１＜ｌ＜ｎを満たす自然数 ただしｌ≠ｋ）のエンティティ装置より受信するリプライイベントが示す意味情報と、第２のフィルタとが一致するか否かを照合し、照合結果に基づいて、リプライイベントのイベントルーティングを制御するので、リプライイベントのためのイベントパスを動的に確立することができる効果が得られる。
【図面の簡単な説明】
【図１】 本発明の一実施形態において、エンティティ１〜３がシェアードリンクを介してイベントプレースを形成する様子を示す図である。
【図２】 同実施形態において、エンティティを説明する図、及び、エンティティの分類を説明する図である。
【図３】 同実施形態において、エンティティの状態遷移を説明する図である。
【図４】 同実施形態において、エンティティの内部構成を説明する図である。
【図５】 同実施形態において、イベントプレースの生成を説明する図である。
【図６】 同実施形態において、エンティティがイベントプレースへ参加する動作を説明する図である。
【図７】 同実施形態において、意味情報スイッチとセッションを説明する図である。
【図８】 同実施形態において、イベントの構成を説明する図である。
【図９】 同実施形態において、意味情報体系を説明する図である。
【図１０】 同実施形態において、グローバルエンティティ名を説明する図である。
【図１１】 同実施形態において、サービスエンティティのプラグインを説明する図である。
【図１２】 同実施形態において、リファレンスモデルを説明する図である。
【図１３】 同実施形態において、シェアードリンクを説明する図である。
【図１４】 同実施形態において、シェアードリンクを説明する図である。
【図１５】 同実施形態において、シェアードリンクを説明する図である。
【図１６】 同実施形態において、イベントパスを説明する図である。
【図１７】 同実施形態において、シェアードリンクの再確立を説明する図である。
【図１８】 同実施形態において、ホップ属性を説明する図である。
【図１９】 同実施形態において、イベントプレース及びエンティティの像減設を説明する図である。
【図２０】 同実施形態において、イベントプレース及びエンティティの像減設を説明する図である。
【図２１】 同実施形態において、エンティティのアドバタイズメントを説明する図である。
【図２２】 同実施形態において、エンティティのアドバタイズメントを説明する図である。
【図２３】 通信ネットワークのビジネスモデルの変遷を示す図である。
【図２４】 Ｐ２Ｐモデルのディメンションを示す図である。
【図２５】 SIONetの概念を説明する図である。
【図２６】 エンティティが送出するイベント及びこれに対応するリプライイベントの構成を示す図である。
【図２７】 各エンティティが内包する意味情報スイッチが管理するフィルタの分類を示す説明図である。
【図２８】 SIONetが具備する通信方式について示す図である。
【図２９】 分散ファイル検索を例に用いて、SIONetの通信方式と他の通信方式を比較した結果を示す図である。
【図３０】 一般的なIPブロードキャスト、ＩＰマルチキャストの様子を示す図である。
【図３１】 分散ファイル検索を例に用いて、SIONetの通信方式と他の通信方式を評価した結果を示す図である。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an entity device that performs reply notification control for an event, a reply notification control method, a reply notification control program, and a recording medium thereof.
[0002]
[Prior art]
Conventionally, on the Internet, as shown in FIG. 23, information distribution based on a “broker type distribution model” has been common. In this business model, an information distributor (for example, a personal computer communication company) positioned as a broker centrally manages information provided by an information provider and distributes information to users as necessary.
However, in the broker-type search model, since the broker manages the metadata of information collectively, it is difficult to meet the various needs of users and information providers in real time. A new business model that is not controlled by the broker has come to be demanded, and from this problem recognition, a new concept of “brokerless search model” has been devised.
This brokerless search model corresponds to P2P (Peer-To-Peer) that has been attracting attention all over the world, such as Gnutella announced in March 2000. JXTA announced in April 2001 also corresponds to P2P, that is, a brokerless search model. P2P is an innovative technology since the WWW and is called the third generation. In recent years, research and development of a brokerless transmission model in which the concept of P2P is applied to the transmission layer and a brokerless policy model in which the concept of P2P is applied to the policy layer have been activated. The dimensions of the brokerless (distribution) model are shown in FIG. One of these brokerless search models is SIONet (Semantic Information Oriented Network).
[0003]
SIONet is a meta network that delivers an event composed of data and semantic information of the data based on semantic information (metadata). As shown in FIG. 25, the event receiver registers semantic information indicating the condition of the event to be received in advance in SIONet. When an event is transmitted from the event sender to the SIONet, the SIONet collates the semantic information of the event with the registered semantic information, and transmits the event to the event receiver based on the collation result. In this way, sending an event to SIONet is called “stimulation”, and the registered semantic information matches the semantic information of the event, and notifying the event recipient who registered the semantic information of the event. It is called “ignition”.
[0004]
As a result, a specific entity can be dynamically searched and discovered from an unspecified number of entities (terminal devices) super-distributed on the network. That is, SIONet is a network that delivers events based on semantic information (sending to whom) instead of the destination address (sending to whom) used in the conventional network.
[0005]
SIONet is an autonomous distributed cooperative network (autonomous distributed computer) in which all entities including the components of SIONet perform autonomous distributed cooperation to self-organize the network. SIONet network components include "Semantic Information Switch (SI-SW)", "Semantic Information Router (SI-R)", "Semantic Information Gateway (SI-GW)", "Event Place", "Session", etc. These can be self-organized as needed to build a secure and scalable P2P network with a bottom-up approach.
[0006]
The basic concept and principle of SIONet is simple and unified. By repeating the simple operation of "registering a filter by an entity and dispatching an event", that is, "entity" stimulation "and" ignition "" chain reaction "between SIONet network components, all entities The thing that controls the behavior of this chain reaction is the semantic information registered in the SIONet by the above-mentioned event receiver, and this is called the “filter”. The method of chain reaction of entities can be dynamically controlled by the filter value registered in the filter. Another basic concept in SIONet is event place. An event place is an entity group connected to each other by a shared link, thereby limiting the scope of a chain reaction.
Details of SIONet are described in Non-Patent Documents 1 and 2. The applicant of the present invention has previously filed an application relating to SIONet according to Japanese Patent Application No. 2001-394980.
[0007]
[Non-Patent Document 1]
Takanari Hoshiai, Keiichi Koyanagi, Birge Sukubatar, Kei Kubota, Hiroshi Shibata, Takamichi Sakai: "Semantic Information Network Architecture", IEICE Transactions B, Vol. J84-B, No. 3, pp. 4, 11-4, 2, 4 (2000.7 accepted, published in 2001-3).
[Non-Patent Document 2]
Takanari Hoshiai, Hiroshi Shibata, Takamichi Sakai, Keiichi Koyanagi: “Semantic Information Network Architecture: SION Architecture”, NTT R & d, Vol. 50, no. 3, pp. 157-164 (200.12 accepted, published in 2001.3)
[0008]
[Problems to be solved by the invention]
FIG. 28 shows a communication system provided in SIONet.
SIONet provides communication modes such as broadcast mode, multicast mode, unicast mode, and reply notification.
In broadcast, events are forwarded to all entities in the event place. Therefore, whether or not the entity is fired by the transferred event is determined by checking with a filter in the entity.
In multicast, an event is transferred only to an entity satisfying an arbitrary condition among entities belonging to an event place.
In unicast, events are forwarded only to specific entities.
In the reply notification, when the event receiver sends an event reply notification to the event transmission source, the reply event is transferred to the event transmission source.
[0009]
However, in the autonomous decentralized network that dynamically controls the way of the chain reaction of entities by the stimulation and firing as described above, the function that actually realizes this reply notification control is not sufficient only by the currently proposed function. Realizing this with the conventional architecture means adding a new method (functional program).
However, there is a problem that it is impossible to hope for rapid system development, minimization of development scale, reduction of debugging man-hours, reduction of development cost, ease of maintenance and the like.
[0010]
The present invention has been made in view of such circumstances, and in an autonomous distributed network that dynamically controls the manner of chain reaction of entities by stimulation and firing, an event receiver notifies the event sender of an event reply. It is an object to provide an entity apparatus, a reply notification control method, a reply notification control program, and a recording medium thereof.
[0011]
[Means for Solving the Problems]
The present invention has been made to solve the above-described problems, and the invention according to claim 1 is an event configured by connecting first to n-th (n is a natural number) entity devices via a shared link. In the place, a semantic information router holding a first filter indicating an event acquisition condition and a second filter indicating a reply event acquisition condition associated with the event matches the first filter. Whether or not the semantic information indicated by the reply event received from the kth entity device (k is a natural number satisfying 1 <k <n) and the second filter held by the semantic information router match. A semantic information switch comprising: a collation unit for collating; and a control unit for controlling event routing of the reply event based on the collation result; Characterized by comprising.
[0012]
Here, the shared link is a link for performing bidirectional event sharing between the first to nth entity devices.
An event place is a network configured by connecting first to nth entity devices via a shared link.
An event is a packet composed of data, semantic information of the data, and control information.
The semantic information is a vocabulary and a value indicating the characteristics of transmission data, and is an instance in a certain vocabulary concept.
The reply event is reply information returned from the event receiver to the event transmission source.
[0013]
The invention according to claim 2 is a first filter indicating an event acquisition condition in an event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link. And the semantic information indicated by the event received from the k-th entity device (k is a natural number satisfying 1 <k <n) match the first filter held by the semantic information router. Semantic information comprising: a collation unit that collates whether or not; and a control unit that sets a second filter indicating an acquisition condition of a reply event associated with the event in the semantic information router based on the collation result And a switch.
[0014]
Further, in the invention described in claim 3, in the invention described in claim 2, the collating unit further receives the event that matches the first filter, where l is 1 (l is 1 <l <n. It is verified whether or not the semantic information indicated by the reply event received from the entity device satisfying the natural number (l ≠ k) matches the second filter, and the control unit further determines whether the second filter matches the semantic information. The event routing of the reply event is controlled.
[0015]
According to a fourth aspect of the present invention, in the event place configured by connecting the first to n-th (n is a natural number) entity devices via a shared link, the first filter indicating an event acquisition condition And a second filter indicating a reply event acquisition condition associated with the event, the entity apparatus is a reply notification control method for controlling event routing of the reply event, wherein the first filter Whether the second filter matches the semantic information indicated by the reply event received from the kth entity device (k is a natural number satisfying 1 <k <n). The event routing of the reply event is controlled based on the collation result.
[0016]
The invention according to claim 5 is a first filter showing an event acquisition condition in an event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link. Wherein the entity device having the semantic information router holds a reply notification control method for controlling event routing of a reply event corresponding to the event, wherein the entity is kth (k is a natural number satisfying 1 <k <n). The second information indicating whether or not the semantic information indicated by the event received from the device matches the first filter and the acquisition condition of the reply event associated with the event based on the comparison result Are set in the semantic information router.
[0017]
Further, in the invention described in claim 6, in the invention described in claim 5, the entity device further receives an event in which an event that matches the first filter is received (where l is 1 <l <n. The semantic information indicated by the reply event received from the entity device satisfying the natural number (l ≠ k) is matched with the second filter, and event routing of the reply event is performed based on the matching result. It is characterized by controlling.
[0018]
The invention according to claim 7 is a first filter showing an event acquisition condition in an event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link. And a second notification filter for causing the entity device to hold the second filter indicating the acquisition condition of the reply event associated with the event to execute event routing control of the reply event, Whether the second filter matches the semantic information indicated by the reply event received from the k-th entity device (k is a natural number satisfying 1 <k <n) that has received the event that matches the first filter. A process for matching and a process for controlling event routing of the reply event based on the matching result. A reply notification control program for executing and.
[0019]
The invention according to claim 8 is a first filter showing an event acquisition condition in an event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link. A reply notification control program for causing the entity device having a semantic information router to hold a process for controlling event routing of a reply event corresponding to the event to the entity device, wherein k is a kth (k is 1 <k <n (Natural number satisfying)) semantic information indicated by an event received from the entity device and processing for verifying whether or not the first filter matches, and a reply associated with the event based on the matching result A reply for executing processing for setting a second filter indicating an event acquisition condition in the semantic information router Is Lee notification control program.
[0020]
The invention according to claim 9 is the invention according to claim 7, wherein the entity device further receives an event corresponding to the first filter, wherein l is 1 <l <n. The natural number to satisfy, where l ≠ k), the semantic information indicated by the reply event received from the entity device and the process for collating whether or not the second filter matches, and based on the collation result, A reply notification control program for executing processing for controlling event routing.
[0021]
The invention according to claim 10 is the first filter indicating an event acquisition condition in an event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link. And a second notification filter for acquiring a reply event associated with the event, a recording medium recording a reply notification program for causing the entity device to execute event routing control of the reply event. The second filter matches the semantic information indicated by the reply event received from the entity device of the k-th (k is a natural number satisfying 1 <k <n) that has received the event that matches the first filter. A process for verifying whether or not to perform the response and an event route of the reply event based on the result of the verification A recording medium recording a reply notification control program for executing a process of controlling the Ingu.
[0022]
The invention according to claim 11 is the first filter indicating an event acquisition condition in an event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link. A recording medium that records a reply notification control program for causing the entity device having a semantic information router to hold a process for controlling event routing of a reply event corresponding to the event, 1 <k <n is a natural number satisfying 1 <k <n) entity information received from the entity device and a process for collating whether or not the first filter matches, and based on the collation result, A process for setting a second filter indicating an acquisition condition of the associated reply event in the semantic information router. A recording medium recording a reply notification control program for causing the row.
[0023]
Further, in the invention described in claim 12, in the invention described in claim 11, the entity apparatus further receives the lth (l is 1 <l <n) when an event matching the first filter is received. The natural number to satisfy, where l ≠ k), the semantic information indicated by the reply event received from the entity device and the process for collating whether or not the second filter matches, and based on the collation result, This is a recording medium on which a reply notification control program for executing processing for controlling event routing is recorded.
[0024]
DETAILED DESCRIPTION OF THE INVENTION
[Details of SIONet]
<Definition of SIONet entity>
Here, all computers such as personal computers, workstations, portable information terminals, mobile phones, and wearable computers are collectively referred to as hosts. Furthermore, a host that implements SIONet software is called a “SIONet entity” or simply an “entity”. As shown in FIG. 2A, an entity (entity device) is a virtualized host in which SIONet software is installed as a unit of autonomous distributed cooperation in SIONet. SIONet software provides a mechanism for individual entities to perform autonomous distributed cooperation. This SIONet software allows each host to become an autonomous distributed computer.
[0025]
Entities are mainly classified into the following three types as shown in FIG.
・ Applications that act as services (service entity: SE, service entity part) are included inside the entity.
· Modules that act as network components (network entity: NE) are included inside the entity
・ Including both SE and NE in the entity
[0026]
<Entity structure and state transition>
FIG. 3 is a diagram illustrating state transition of an entity. As shown in this figure, there are three states of an entity, “Non-Existent”, “Suspend”, and “Active”.
The “Non-Existent” state represents the entity state when the SIONet software is installed on the host.
By executing (launching) the SIONet software, a transition is made from the “Non-Existent” state to the “Suspend” state. At this time, internal modules such as an entity control unit, a control panel, a network entity factory (NE factory), and a network entity (NE) are generated in the entity as shown in FIG. Below, each role is demonstrated easily.
[0027]
The entity control unit is an entity entity, and accepts various requests (session establishment request, shared link establishment request, etc., which will be described later) from other entities and the control panel. Note that a request for establishing a session, a request for establishing a shared link, etc. cannot be made from another entity to an entity in the “suspend” state.
[0028]
The control panel provides a GUI (Graphical User Interface) to owners of entities such as people. For example, the control panel prompts the owner of the entity to input the entity name, and the entity control unit assigns the entity name to the entity based on the input entity name. In the example of FIG. 4, the entity name is “entity 2”. This entity name may be referred to as a “local entity name”, particularly distinguished from a “global entity name” described later. The local entity name can be arbitrarily set by the owner of the entity.
[0029]
The NE (network entity) factory has a function of dynamically generating an NE.
NE (Network Entity) means SI-R (Semantic Information Router), SI-GW (Semantic Information Gateway), alive entity, fault handling entity, statistics collection entity, etc. It is a general term for modules that behave in order to achieve this.
[0030]
The SE (service entity) is an application embedded as an SE in an entity using a plug-in mechanism provided by the entity, and is a virtualized P2P application operating on SIONet. An application can be embedded in an entity as an SE using a plug-in mechanism provided by the entity. Also, the SE can establish an arbitrary number of sessions with the SI-SW. The SE can send and receive events only through a session. SE is not involved in SIONet network construction and operation. A plug-in mechanism for incorporating SE into an entity will be described later.
[0031]
The entity (entity 2) in the “suspend” state in FIG. 3 generates an event place by itself as shown in FIG. 5, for example, or joins (joins) an existing event place as shown in FIG. When the entity (entity 2) belongs to an arbitrary event place and becomes a member of an entity group, the entity (entity 2) transitions from the “suspend” state to the “active” state. Only an entity in the “active” state advertises its existence (public, details will be described later), and can accept a session establishment request or a shared link establishment request from another entity.
[0032]
Here, after the software is installed in the host and the entity including the NE, the NE factory, the entity control unit, the control panel, and the like is generated, the operation until the entity enters the “active” state will be described. Assume that an entity receives an instruction to create an event place or participate in another event place via the control panel from the owner of the entity. The entity control unit of the entity requests the NE factory of the entity to generate SI-SW (Semantic Information Switch). When the NE factory generates SI-SW, the entity control unit establishes a session between the generated SI-SW and an internal module such as NE. This makes it possible to accept advertisements, session establishment requests from other entities, shared link establishment requests, and the like.
[0033]
Here, the role of SI-SW and session will be described with reference to FIG.
A session is a connection between SI-SW and SE, and SE can send and receive events only through the session. There are three types of sessions: event transmission sessions, reception sessions, and transmission / reception sessions.
SI-SW provides a switching mechanism that switches events based on semantic information. The SI-SW accommodates NEs and internal entities such as SEs and NEs incorporated in the entities by a plug-in mechanism through a session in a star shape. In the following, SE will be described as an example, but the same applies to other internal entities included in an entity such as NE.
[0034]
Here, the configuration of the event will be described. As shown in an example in FIG. 8, the event includes a control information part, a semantic information part, and a data part. Transmission data is stored in the data portion. Various data and programs such as text data, binary data, reference, proxy, and agent can be stored as transmission data.
[0035]
The semantic information portion stores semantic information (vocabulary and its value) of transmission data and a vocabulary concept (event type) of semantic information. Here, the semantic information is metadata describing the characteristics of transmission data and is an instance of an event type.
The event type is a semantic information template. You can define inheritance relationships between event types. FIG. 9 shows an example of the semantic information system. In this figure, the meaning information “title; yesterday”, “price; $ 30”, “artist name; beatles” belongs to the event type “popular” and also belongs to the event type “music”. Yes. In addition, the meaning information “Title; Night of Kiyoshi”, “Price; $ 20”, “Situation; Christmas” belongs to the event type “BGM” and also belongs to the event type “Music”. .
[0036]
As a description language of the semantic information system, there is XML (Extensible Markup Language). Note that some event type names (all names starting with SIONet) are reserved for network entities.
The event control information part shown in FIG. 8 is a control field used for SIONet execution control, and only this is not open to the SE who is the user of SIONet. The control information section includes matched filter identifiers, matched filter verification scores, synchronous statistical information collection flags, TTL (Time To Live) values within event places, between event places, within event places, and between event places. Control information such as the number of hops and hop attributes is set.
[0037]
In the entity configuration as shown in FIG. 7, the function of the SE will be described. The SE registers event acquisition conditions in the SI-SW via the reception session. This is called a “filter”. In the filter, set the vocabulary concept (event type) of the event you want to acquire, and the matching condition with the semantic information (for example, the vocabulary “Price” is in the range of “$ 20 to $ 40”) . Note that collation conditions such as “complete match” with all vocabularies defined in the event type, “partial match” with some vocabularies, and “weighted match” can be selected in units of filters.
[0038]
The SE can register a plurality of filters from one reception session, but the filters registered through the same session have an “or” relationship. That is, for one event, one receiving session is fired at most once. If a wildcard is specified for the event type of the event to be acquired, all event types are targeted for acquisition. Further, when 1 (logical value is true) is set as the matching condition with the semantic information, it means that the matching condition with the semantic information is satisfied unconditionally.
[0039]
In addition, the SE transmits an event to the SI-SW via a transmission session. At this time, the SI-SW collates the semantic information part of the event with the filter. Specifically, first, it is checked whether or not the event type is desired to be received. If the event type is satisfied, the semantic information and the matching condition are checked. As a result of the collation, when the semantic information satisfies the collation condition, the entity that registered the matched filter is activated and the event is notified.
In SIONet, event transmission is referred to as “stimulation”, that the filter matches the event as “reaction”, and that the entity that registered the matched filter is activated to notify the event is referred to as “ignition”.
[0040]
<Entity name assignment method>
As shown in FIG. 5, the case where the entity 2 generates an event place named “event place A” will be described. The owner of the entity 2 inputs an event place name to the entity 2 through a control panel or the like. Here, the input event place name is “event place A”. Then, the entity control unit requests the NE factory to generate SI-SW, and establishes a session between the generated SI-SW and an internal module such as NE. Further, the entity control unit stores the name of the generated SI-SW as “event place name + local entity name”, that is, “event place A + entity 2”. This name is called “global entity name”. Creation of this global entity name corresponds to generation of an event place.
[0041]
That is, in SIONet, some management entity is not necessarily generated by generating an event place. That is, in SIONet, member management of entities belonging to an event place is realized by a shared link between entities described later, and therefore there is no centralized management unit itself that performs member management. For this reason, even if the entity that generated the event place leaves the event place, the entity remaining in the event place autonomously self-organizes, whereby the operation of the event place is continued. In other words, the removal of the last entity from the event place corresponds to the disappearance of the event place.
[0042]
This global entity name is used when a shared link or session is established. An operation in which the entity 2 as shown in FIG. 5 further generates an event place B and establishes a shared link from the entity 1 will be described with reference to FIG.
[0043]
First, the operation in which the entity 2 already participating in the event place A generates the event place B will be described. The entity control unit of entity 2 causes the NE factory to generate a new SI-SW, as described above. The entity control unit assigns “event place B + entity 2” as the global entity name to the generated new SI-SW. Thereby, the event place B is generated. At this time, the entity 2 has two global entity names (SI-SW names) “event place A + entity 2” and “event place B + entity 2”.
[0044]
Next, an operation in which the entity 1 joins (joins) the event place A will be described. As described above, the entity 2 participating in the event place A and the event place B is in the “active” state. An entity in the “active” state can advertise (publish) its existence to other entities, in which case the global entity name is published.
[0045]
When entity 1 discovers entity 2 and makes a join request to entity 2, entity 1 indicates that the global entity name of entity 2 that is the join destination entity is “event place A + entity 2”. Entity 2 is notified.
[0046]
In this way, the global entity name can uniquely identify the SI-SW that establishes the shared link, and thus can participate in the event place A. In this way, the SI-SW, which is the shared link or session establishment destination, is virtualized as a global entity name, so that the entity owner or the like is not directly aware of the SI-SW.
[0047]
<SE plug-in method>
The operation of incorporating SE into the entity shown in FIG. 11 will be described below.
(1) The entity owner instructs an application plug-in to the control panel. At this time, the executable file name of the application to be plugged in is given as a parameter.
(2) The control panel notifies the entity control unit that the plug-in instruction has been received and the execution file name of the plug-in application.
[0048]
(3) The entity control unit stores an execution file name to be plugged in, starts an application using the given execution file name, and establishes a session between the SI-SW and the started application.
That is, the plug-in in SIONet is nothing but to establish a session between the application and SI-SW. In SIONet, all operation entities such as SE and NE cooperate through a session. Therefore, plug-in / plug-out (detachment) can be easily realized, and the plug-in / plug-out does not affect other operation entities (super loose coupling). By extending this concept, SE sharing between entities as described later can be realized.
[0049]
<PREFERENCE architecture>
SIONet adopts the concept of a reference model as shown in FIG. The PREFERENCE architecture shown in Fig. 12 is an architecture for building a listening society (a listening-oriented cyber society) in which semantic information is registered in the filter and distribution conditions (matching conditions) are set in the semantic information section of the event. Provides total solutions for less-less distribution model, broker-less search model, and broker-less policy model. Specifically, it consists of a stream interface, SIONet, COMNet, and the like.
SIONet is an event transmission layer and provides a network interface to higher layers. The middleware layer is a community (community network: COMNet), and corresponds to the intelligence layer of SIONet. In this layer, information localization, authentication, security, information right guarantee, policy control, and the like are performed. The highest layer is the application layer. SE is implemented in this application layer. Examples of the SE include a personal TV station and a smart messenger for a message exchange service.
[0050]
In this way, SIONet provides a common P2P network infrastructure for all P2P services (SEs provide services) such as distributed computing, information exchange, collaboration, and message delivery, and also provides a plug-in mechanism. To support efficient application development.
[0051]
<Role of entity in SIONet>
SIONet is a form of constructing a volunteer network by helping each other's entities to help each other, and each network is self-organizing through autonomous distributed cooperation. For example, in the configuration of FIG. 6, an operation in which the entity 2 participates in the event place generated by the entity 1 and then the entity 1 leaves the event place will be described.
[0052]
In advance, the entity 1 generates an event place and participates in the event place. Here, when entity 2 makes a join request to event place for entity 1, as shown in FIG. 13, SI-SW is generated for entity 2, and SI-SW of entity 1 and entity 2 is further generated. A shared link is established between them and an entity group is formed.
In this way, after the shared link is established between the SI-SWs of the entity 1 and the entity 2 and the entity 2 participates in the event place, the entity 1 that is the creator of the event place leaves the event place. Then, the shared link between SI and SW is released, and thereafter, the event place construction / operation is continued only by entity 2. Thus, since each entity self-organizes, even if an entity leaves, disappears, etc., another entity performs the function of the entity.
[0053]
In SIONet, various forms of P2P networks can be constructed by arranging / combining entities according to purposes. Also, different forms of P2P networks can be seamlessly linked. This is achieved by realizing:
(1) All entities are autonomously distributed and coordinated using a simple and simple mechanism called “chain reaction based on stimulation and firing”.
(2) Reducing the difference in P2P network form to the problem of entity placement and management
Thus, one of the features of SIONet is that various types of P2P networks can be constructed with a single mechanism.
[0054]
<Shared link>
The “shared link” is a concept for performing bidirectional event sharing between a plurality of different entities. For example, as shown in FIG. 14, when entity 2 makes a request for establishment of a shared link (SL) to entity 1, as shown in FIG. 15, SI-SW2 and SI-SW1 A shared link is established between them and a new entity group is formed.
That is, the shared link is a mechanism for forming an entity group, and is also a multi-hop route.
[0055]
In FIG. 14, the entity 2 that has successfully established the shared link includes the event place name (global entity name) from the entity 1, the event transfer method (routing method) in the event place, and the description (description) of the event place. Various information such as SE information that is plugged in is transmitted. Various event routing methods can be dynamically set between SI-SWs by setting filter values using SI-R, which will be described later. In the following, the operation of establishing a shared link will be described, and the role and mechanism of SI-R will be described in detail.
[0056]
<Establishment of shared link>
A mechanism up to establishment of a shared link will be described with reference to FIGS. 14 and 15. First, in FIG. 14, consider a case where entity 2 issues a shared link establishment request to entity 1.
(1) The entity 2 issues a shared link establishment request to the entity 1.
[0057]
(2) As shown in FIG. 15, the entity control unit of entity 1 establishes SL1,2 (shared link for receiving an event from entity 2) based on semantic information in the NE factory. SI-R1,2 that performs event routing (event transfer) between SI and SW is dynamically generated inside entity 1. Further, the entity control unit stores that the entity 2 is a shared link establishment request source. Strictly speaking, the entry point of the entity 2 and the global entity name (SI-SW2) are stored as a shared link establishment request source.
[0058]
(3) SI-R1,2 establishes an event reception session for SI-SW2 by requesting entity 2 to establish an event reception session. At this time, a filter indicating a condition of an event received by the entity 1 is registered in the SI-SW 2. Furthermore, SI-R1 and 2 establish a session for event transmission with respect to SI-SW1 to which SI-R1 and 2 belong. Such a combination of transmission and reception sessions established by SI-R is called a shared link. As a result, SL1,2 is established. For example, an event sent by SE4 to SI-SW2 is also sent to SI-SW1 via SI-R1,2.
[0059]
(4) At this time, the event transfer method can be dynamically controlled by the set value of the filter registered by SI-R1,2 to SI-SW2. An example is shown below.
(A) The event sent to SI-SW2 is unconditionally transferred to SI-SW1. That is, SI-R1,2 fires for all events. This is made possible by setting “wildcard for the acquired vocabulary concept and true for the matching condition with semantic information (vocabulary)” as a filter that SI-R registers in SI-SW. This is called “unconditional routing”. This setting only needs to be performed once when the shared link is established. In this method, there is a possibility that unnecessary event transfer and event collation processing overhead at the transfer destination may occur. However, since there is no overhead for event path establishment (routing information setting) described later, the number of registered filters is small. This method is effective when it is sufficiently larger than the number of event transmissions. This routing method is mainly used for multi-hop broadcast communication.
[0060]
(B) Transfer only events necessary for entity 1 from SI-SW 2 to SI-SW 1. Thereby, unnecessary event transfer is not performed. That is, SI-R1,2 fires only for a specific event. This is because SI-R sets only the vocabulary concept (matching condition is always true) in the filter as “event routing by vocabulary concept”, and sets the matching condition between the vocabulary concept and vocabulary as “filter”. It is divided roughly into. The former is mainly used for multicast communication with a multi-hop type attribute, and the latter is mainly used for multi-hop type unicast communication and multi-hop type multicast communication. This is used in failure processing notifications, statistical information notifications, alive notifications, reply notifications, advertisement notifications, and the like.
In addition to multi-hop communication such as multi-hop broadcast communication, multi-hop attribute multicast communication, multi-hop unicast communication, and multi-hop multicast communication, the communication destination can be set according to the filter value set by SI-R. Direct communication using entity entry points is also possible. Multi-hop broadcast communication, multi-hop attributed multicast communication, multi-hop unicast communication, and multi-hop multicast communication will be described later.
[0061]
(4) The procedures (2) to (3) described above are performed in the same way in the entity 2 that is the shared link establishment request source. That is, the entity control unit of entity 2 stores entity 1 (SI-SW1) as a shared link establishment request destination and dynamically sets SI-R2,1 to the NE factory in order to establish SL2,1. Generate. This generated SI-R2,1 registers a filter in SI-SW1 in the same manner as described above, and establishes a shared link. Thereby, a bidirectional shared link is established between SI-SW1 and SI-SW2, and events can be shared among entities. Since SI-R does not register the filter, it is possible to establish a one-way shared link, that is, to prevent SI-R from being fired.
[0062]
<Establishing an event path>
Route selection information for event forwarding (event routing) (a set of filters that SI-R registers for event sharing) is called an “event path”. For example, as shown in FIG. 15, in a configuration in which entity 2 and entity 3 each establish a shared link with entity 1, consider a case where SE3 of entity 2 registers a filter for SI-SW2. At this time, the SI-R2,1 of the entity 2 registers the filter registered by the SE3 in the SI-SW1 of the entity 1 through the reception session. Similarly, the SI-R1,3 of the entity 1 registers the filter in the SI-SW 3 of the entity 3 through the reception session. In this way, with the filter registration by SE3 as a trigger, the SI-R registered filter sequentially spreads to adjacent SI-Rs based on the shared link, thereby establishing an event path. This is called “event path setting or spreading”.
[0063]
Here, the establishment of the event path for the above-described “event routing based on the vocabulary concept” will be described. In FIG. 15, in order to establish an event path for “event routing by vocabulary concept”, SI-R2,1 is the event type only in the filter registered by SE3 of entity 2 with respect to SI-SW2. Set the matching condition is always true) as a filter to entity 1's SI-SW1. That is, the collation condition registered by SE3 as a filter is not used. In other words, by using only the event type, for example, when SE1 of entity 1 sends an event, only the event type is verified in SI-SW1, and as a result, if SI-R2,1 fires, SI-R2, 1 sends the event to SI-SW2, and collates with semantic information in SI-SW2.
[0064]
In addition, establishment of an event path for the above-mentioned “event routing by vocabulary” will be described. In FIG. 15, when establishing an event path for “event routing by vocabulary”, SI-R2,1 of entity 2 sets the filter value registered by SE3 as the filter value to SI-SW1 of entity 1 as it is. To do. That is, SI-R2,1 is a form in which both event type and semantic information registered by SE3 as a filter are registered in SI-SW1 of entity 1 and complete filtering is performed in SI-SW1.
[0065]
Therefore, the event routing method based on vocabulary does not cause any unnecessary event transfer, but the event path setting overhead for routing becomes enormous, so this method is effective when the number of event transmissions is sufficiently larger than the number of registered filters. It is. On the other hand, the routing method based on the event type is positioned as a compromise between the two methods described above. In other words, it is effective when the number of filter registrations and the number of event transmissions are about the same, or when the ratio between the number of filter registrations and the number of event transmissions cannot be predicted. With these mechanisms, multi-hop communication of events based on semantic information is realized. An event routing method can be specified when generating an event place or registering a filter from an SE.
[0066]
The event path setting request is propagated to all SI-Rs in the event place, but the propagation range can be limited by the TTL value. The operation will be briefly described with reference to FIG. Here, for convenience of explanation, it is assumed that an event path is established for vocabulary concept routing, but the present invention is not limited to this. Further, each entity advertises (filter registration) the same vocabulary concept. The description will be made assuming that the TTL value is 2.
[0067]
In FIG. 16A, the SI-R of the entity 2 starts an event path setting request. Here, since the TTL value is 2, the event path setting request is propagated only to entity 1, entity 3, and entity 4, and as a result, the event path is established as shown in FIG. The
[0068]
Similarly to the above, when the SI-R of the entity 11 starts an event path setting request, an event path is established for the entity 10 and the entity 9. In the configuration shown in FIG. 16, when the SI-R of entity 2 and the SI-R of entity 11 make an event path setting request, the event path is not set in entity 5. Is not shared. That is, the event that has occurred from the entity 2 does not cause a chain reaction with the entities 5 to 11, and the event is not transferred to the entities 5 to 11.
[0069]
However, as shown in FIG. 16B, when the SI-R of the entity 5 initiates an event path setting request, the event path for the entity 4, the entity 5, the entity 6, the entity 7, and the entity 9 is determined. Is established. As a result, as shown in FIG. 16C, an event path is established for all entities in the event place except the entity 8.
[0070]
Thus, if the vocabulary concept is frequently used (reputed or popular) in the event place, the event path will eventually be established in the event place. Become. On the other hand, vocabulary concepts that are not so popular will eventually be deceived, which allows a mild chain reaction to be realized. Note that the numbers on the event path in FIG. 16 indicate the multiplicity.
[0071]
An entity can publish the multiplicity of event paths as an attribute of an entity property. On the other hand, an entity having a high multiplicity of event paths can be found by entity property discovery. At this time, by re-sharing the shared link with respect to the entity, it is possible to gradually gather like-minds (like entities) in the vicinity (localization of like-entities). Details of the entity property will be described later.
[0072]
From the viewpoint of distributed object technology, the event path can also be interpreted as follows. Entities that are super-distributed around the world have some “correlation” between them. There are various properties such as an entity name, a group name, and attributes (location, interest, reputation, fashion, service) that give a correlation. Based on the correlation, the entities have a connection between the entities and perform distributed cooperation. This entity that gives an entity correlation is called an entity property.
[0073]
In SIONet, this correlation is expressed by the vocabulary concept and vocabulary and set as an event path based on the shared link. The strength of the correlation corresponds to generalization / specialization of vocabulary concepts, multiplicity of event paths, and the like. That is, in SIONet, the correlation between entities is dynamically controlled and managed by an event path. This is the control of the chain reaction by the filter. Therefore, the entity does not have a fixed entity identifier.
[0074]
For example, an IP address is a fixed identifier of an entity based on a position. In SIONet, instead of this, an entity property described as a vocabulary concept / vocabulary is used as an entity identifier. Entities register these as filters in SI-SW, thereby declaring entity properties (entity identifiers) and advertising their properties based on shared links. This corresponds to the propagation of the event path. Thereby, an event path is established.
[0075]
As described above, SI-R is a network entity having both aspects of event transmission and event reception, and is not fundamentally different from a general service entity. In SIONet, an entity used for SIONet control such as SI-R is called a network entity (NE), particularly distinguished from a service entity (SE). In SIONet, all service entities and network entities are treated as a common entity, and autonomously operated according to a simple and consistent common logic of event transmission and event reception, that is, chain reaction of stimulus and firing. , Provide a super-distributed and super-loosely coupled architecture in which all entities can cooperate autonomously and distributedly.
[0076]
<Release and re-establish shared link>
In cases where an entity participating in the event place falls into a failure or leaves the event place, the remaining entity is not able to participate in the operation of the network for various reasons. By doing so, it is necessary to be able to continue the network service.
In such a case, SIONet releases the shared link established between SI and SW, and re-establishes the shared link. The operation will be described with reference to FIG.
[0077]
In FIG. 17, the first numbers (1) and (2) in the shared link establishment request indicate the order of those requests. That is, in order of the shared link establishment request, first, the shared link establishment request is made from the entity 2 to the entity 1. Next, a request for establishment of a shared link is made from entity 3 to entity 2. Finally, a shared link establishment request is made from entity 4 to entity 2. Here, “Each entity can make a shared link establishment request at most once in the same event place, but establishes a shared link based on a link topology that can accept an unlimited number of establishment requests. Propose a link establishment method. This guarantees that no loop will occur between entities linked by a shared link. That is, by using this method, an open link topology can be easily realized only by link re-establishment between adjacent entities.
[0078]
If the establishment request is successful in the above-described order, a shared link is established between each SI-SW by the above-described procedure. When the shared link is established, the entity control unit of each entity stores the entity that has made the establishment request and the entity that has accepted the establishment to itself. For example, the entity 2 holds a list of the entity 1 that has requested establishment and the entities 3 and 4 that have accepted the establishment of the entity 2.
In this situation, for example, when the entity 2 is moved out or removed, a shared link release request is issued to its own SI-SW 2 to release the shared link. Thereafter, each entity establishes a new shared link. Hereinafter, the operation will be described.
[0079]
(1) When the entity 2 leaves, the entity control unit of the entity 2 notifies the one-hop entity (entity 1, entity 3, entity 4) that the shared link is released. This can be done by sending an event with the TTL value of the event set to 1. At this time, for the entity (entity 3 and entity 4) that has accepted the establishment of the shared link to itself, the entity 1 that has made the establishment request is used as the establishment request destination of the new shared link on behalf of itself. teach. If there is no entity that has made an establishment request, an arbitrary entity is selected from the establishment requesting entities (one hop ahead) to itself, and this is used for the shared link on behalf of itself. The establishment request destination.
[0080]
(2) In order to release the shared link (SL2,1, SL2,3, SL2,4) established by itself, the entity control unit of entity 2 notifies SI-R2,1, SI-R2,3 , Notify SI-R2,4 (not shown). SI-R2,1, SI-R2,3, and SI-R2,4 are SI-Rs of entity 2, and, as described above, shared link SL2, to entity 1, entity 3, and entity 4 1, SL2,3, SL2,4 are established. These SI-Rs use this as a trigger to release the session of entity 2 to SI-SW2.
[0081]
(3) The entity control unit of entity 1 instructs SI-R1,2 (not shown) to release shared link SL1,2. SI-R1,2 releases shared link SL1,2. The entity 1 waits for establishment requests from the entities 3 and 4.
(4) As with entity 1, entity 3 and entity 4 release all shared links (SL3,2 and SL4,2) that they have established for SI-SW2 (SI-SW2 of entity 2). Then, the shared link establishment request is made to the new entity (entity 1) taught from the entity 2 as the shared link establishment request destination, and the shared link is reestablished. That is, as described above, each entity control unit causes the NE factory to generate SI-R3,1 and SI-R4,1 respectively, and the SI-R3,1 and SI-R4,1 share the shared link SL3,1. 1. Establish SL4,1.
[0082]
As described above, the shared link establishment process and re-establishment process are performed only between adjacent entities and do not affect other entities. That is, there is no need to reconstruct links for all entities.
[0083]
The shared link is not only requested to release the shared link by following proper procedures such as moving out or deinstalling the entity, but also due to an entity failure, power failure, session (physical communication path) failure, etc. There are cases where you must re-establish. However, in such cases, it may not be possible to teach alternative entities that are needed when reestablishing a shared link. In SIONet, in order to cope with such a situation, each entity transmits an event of n hops (n is an arbitrary natural number) to grasp an alternative establishment request destination entity. In SIONet, finer hop control is possible by using TTL values and hop attributes. Examples of hop attributes include:
[0084]
(1) Only the entity requesting shared link establishment is targeted for hopping.
(2) Only the entity requesting the establishment of a shared link is a hop target.
(3) All entities are targeted for hopping.
[0085]
An example of an event flow when the hop attribute of (1) is designated is indicated by a broken line in FIG. In FIG. 18, (i / j) is shared link establishment information stored in each entity. i indicates the entity to which the entity has made a shared link establishment request, while j indicates the entity that has accepted the shared link establishment request. For example, (2/5, 6) of the entity 3 indicates that the entity 3 makes an establishment request to the entity 2 and accepts the establishment requests from the entities 5 and 6. Each entity holds shared link establishment information, so that, for example, when the entity 3 makes a further shared link establishment request to another entity, the request can be rejected as an error. This guarantees the consistency of the open link topology described above. In this situation, entity 6 has 3 hops and sends an event having the above-mentioned hop attribute (1), so that it becomes possible to know the existence of entity 1 and entity 2, which are alternatives when entity 3 fails. Become an entity.
[0086]
The hop attribute described above is used not only for searching for an alternative entity at the time of failure, but also for searching for an entity that can accept establishment of a shared link, and for searching for a top entity (nobody establishes a shared link). It is valid. In SIONet, only the top entity can establish a federation (corresponding to a shared link between event places) for other event places.
[0087]
<Purpose of online increase / decrease>
 The purpose of the entity increase / decrease in SIONet is mainly divided into the following two.
(1) From the viewpoint of improving the total processing capacity of the event place, the number of entities in the event place is increased, and the event filtering process is load-balanced. From the opposite point of view, the entity is reduced. This is mainly used in the operation of hybrid P2P and backbone P2P networks.
(2) A flexible and global P2P network is constructed from the bottom up by flexibly establishing a shared link for dynamically generated entities. This is mainly used in the operation of a pure P2P network.
[0088]
The hybrid P2P network is a network configured by, for example, an operator such as a network provider generating an event place in advance on a host or the like, and a service entity such as a personal terminal connecting to the event place through a session. . The pure P2P network is a network configured by connecting entities as individual transmitting / receiving terminals via shared links, and the smallest unit for sharing an event is an event place. The backbone type P2P network is a connection form between networks, for example, a network in a state where pure type P2P networks in a plurality of regions are connected via a hybrid type P2P network.
[0089]
<Type of increase / decrease>
SION provides several types of increase / decrease configurations, but here, typical configurations shown in FIGS. 19 and 20 will be described.
(1) Combining and separating event places
As shown in FIG. 19A, a plurality of event places can be synthesized. Here, composition refers to collecting entities belonging to a plurality of event places as members in one event place. As a typical example, service integration (information sharing) based on a business alliance between different service operators can be considered.
[0090]
This is because a request for establishing a shared link is issued to any entity belonging to the event place or an entity in the event place where the request is made, by issuing a composition request. As a result, a shared link is established between SI and SW, and the combination of both is realized. The request source and the request destination of synthesis may be either an entity or an event place. On the other hand, in the case of division, the established shared link is released and separated into event places.
[0091]
(2) Participating in and leaving the event place
As shown in FIG. 19B, an SI-SW is generated in the request source entity by making a Join request to the entity in the event place or the event place. Then, by issuing a shared link establishment request to the request destination entity, the shared link is established between the SI and SW, and can participate in the event place.
When the entity leaves the event place, the shared link between the entities is released, the shared link is reconstructed, and the entity leaves the event place as described above. At this time, the state of the entity that has moved out transitions to the suspended state.
[0092]
By requesting the entity to establish a shared link from the event place side, the entity can be taken into the event place. This is called absorption. The opposite is called splitting.
(3) Increase / decrease of entities (SI-SW)
As shown in FIG. 20 (c), when an entity expansion request is made to an entity in an event place or an event place, an SI-SW is newly generated for the specified entity, and an existing SI-SW is generated. A shared link is established with the SW. On the other hand, when an entity reduction request is made to the event place, a shared link release request is issued to the specified entity, and after the shared link between SI and SW is released, the shared link is reestablished. , The entity is deleted. At this time, the state of the entity transitions to Non-Existent.
[0093]
(4) Federation between event places
As shown in Fig. 20 (d), a SI-GW that transfers events between event places is dynamically generated by making a federation (cooperation) request to the entities in the event place or to the event place. Both event places cooperate through the session. Note that the federation request source and request destination may be either an entity or an event place.
[0094]
<Entity advertisement>
With reference to FIGS. 21 and 22, the advertisement (publication) of an entity will be described. There are the following two aspects to entity advertisement in SIONet.
Viewpoint 1: Entrance advertisement
Viewpoint 2: Entity property advertisement
Hereinafter, each viewpoint will be described.
Viewpoint 1: Entrance advertisement
The base event place is an event place serving as a base (starting point) for searching for (discovering) an optimal event place based on an entity. In other words, the base event place is the entrance to SIONet. Therefore, entities participating in the base event place can make the SIONet entrance public. Here, opening the entrance means advertising the entry point and the global entity name of the entity that is the shared link establishment request destination. This public information is found by a search using a broadcast described later.
[0095]
Viewpoint 2: Entity property advertisement
In any entity group connected by a shared link (all event places including the base event place), each entity can advertise its entity properties. This corresponds to the propagation of the event path described above. This public information is discovered by sending out a discovery event described later.
[0096]
The flow from entity disclosure and search to entity group formation will be described below. In the following, base entity, entity 1, entity 2, entity 3, entity 4, entity 5, and entity 6 belong to the base event place, and entity 3, entity 11, entity 12, and entity 13 belong to event place α. It will be described as belonging.
[0097]
(1) Install SIONet software on the host as shown in FIG.
The state of the entity at this point is “Non-Existent” as described above. For convenience of explanation, this entity is assumed to be entity Y.
(2) By executing the SIONet software, the entity Y transitions from the “Non-Existent” state to the “Suspend” state. An entity in this state has not yet been recognized by SIONet.
[0098]
{Circle around (3)} The entity Y in the “suspend” state searches for the entrance (entry point and global entity name) of other entities belonging to the base event place in order to participate in the network as a component of SIONet. Specifically, a nearby entity is searched from among entities participating in the base event place by broadcasting. The broadcast method depends on the implementation. For example, when implemented in a wireless network, all entities within the wireless reach are targeted for search. On the other hand, when implemented in an IP network, IP broadcast or IP multicast is performed. FIG. 21 shows that the entity 1 (entry point of the entity 1 and the global entity name) is found by the search by broadcast. If a nearby entity cannot be found by broadcasting, a well-known entity can be used. Well-known entities are called base entities. Note that the base entity can exist in all event places including the base event place.
[0099]
{Circle around (4)} The entity Y makes a join request to the base event place for the discovered entity 1. That is, the entity Y makes a Join request to the entry point of the entity 1 using the global entity name of the entity 1 as a parameter. The entity 1 that has received the join request from the entity Y accepts the join request only when the state transition of the entity 1 is “active” and the entrance and the entity property are in the public mode. The entity Y cannot issue a Join request exceeding the maximum number of Joins. The maximum number of Joins can be set by the owner of the entity Y or the like on the control panel of the entity Y. When the entity 1 receives the join request of the entity Y, a shared link is established between the entity Y and the SI-SW of the entity 1 by the same operation as described above. Thereby, the entity Y is self-organized as a network component in the base event place. At this time, the entity Y transitions from the “suspend” state to the “active” state.
[0100]
Entity Y joined to the base event place can open the entrance. You can also advertise entity properties. Entity properties include global entity name (and entry point), nickname, group name, alive (only assertion exists, entry point and global entity name as shared link establishment information are not disclosed, entity is not disclosed (Even if it is a mode, there are disclosure targets), descriptions (descriptions of entities), attributes, etc. The attributes include plug-in SE information, event path multiplicity, event place information, and the like. The entity property description language includes XML.
[0101]
In FIG. 21, for example, the entity control unit of the entity 3 can publish the event place α in which the entity 3 participates simultaneously as an attribute of the entity property. Furthermore, the entity control unit can disclose not only the event place that is currently joined but also the event place information of the event place that has been joined in the past. This event place information is, for example, a description of the event place (description of the event place, explanation information), or the global entity name of the entity (semantic information switch) that established the shared link when participating in the event place ( Event place name + entity name, connection establishment information), entry point (entry point information), and the like. The number of entities that can hold the event place information joined in the past is arbitrary. For example, the entity owner or the like can be set by the control panel. The entity that has obtained the public event place information presents the event place information to the entity owner by outputting the event place information through a control panel or the like. Thereby, the entity owner can recognize the existence of another event place.
 In SIONet, there is no function to centrally manage event place information such as where and what event place and what service is provided in that event place, so if you want to get event place information, Event place information needs to be obtained from entity properties of other entities. By making public the event place information that participated in the past as well as the event place that you are currently participating in, the chances of acquiring the event place information will increase, and the chances of participating in the event place that provides the service you want will increase. .
[0102]
When the entrance of the entity Y is released, these entity properties are registered as filters in the semantic information switch in the entity, whereby the entity properties are propagated to other entities based on the shared link, and an event path is established. Basically, the event path establishment request is propagated to all the entities in the event place, but the propagation range of the event path establishment request can be limited by the TTL value. The global entity name is used as an identifier during multi-hop type unicast communication, the group name is used as an identifier during multi-hop type multicast communication, and the attribute is used as an identifier during multicast communication with a multi-hop type attribute. For example, as a typical example of multi-hop unicast communication, there is a reply notification from an event reception entity to an event transmission source entity.
[0103]
In other words, the global entity name is multi-hop unicast communication, which is a communication method for transmitting an n-hop event from the SI-SW of the entity specified by the global entity name. Multi-hop multicast communication is a communication method for transmitting n-hop events to SI-SWs of entities belonging to a group specified by a group name. Multi-hop attributed multicast communication is a communication method for transmitting an n-hop event to an SI-SW of an entity having the same attribute as that of itself. Multi-hop broadcast communication is a communication method for transmitting an n-hop event to SI-SW of an arbitrary entity.
[0104]
(5) In FIG. 22, the entity Y who participated in the base event place releases “entity properties that meet his / her needs” by sending out a discovery event to search for the “event place where he / she wants to participate”. Search for the entity This discovery event is an event used for control of SIONet, and is equivalent to an event transmitted by SE. A discovery event is an event for igniting an NE, and a matching condition with an entity property is set in the semantic information portion of the event. In other words, adding a new function in SIONet means defining a new vocabulary concept and vocabulary (not adding a mechanism, but adding a chain reaction condition). As a result, various functions can be added only by a single mechanism (chain reaction).
[0105]
Here, it is assumed that the entity 3 is found as a result of the search. As described above, the entity 3 participates in the event place α simultaneously with the base event place. By discovering the entity 3, the entity Y can know the existence of the event place α.
(6) The entity Y issues a Join request to the event place α to the entity 3 and participates in the event place α. As described above, the entity 3 accepts a Join request (shared link establishment request) when its state transition is “active” and in the public mode.
[0106]
(7) Furthermore, the entity Y can send an event for the same search at the event place α. Thereby, it is possible to find a new entity that meets its own needs. For example, it is assumed here that the entity 12 has been discovered. That is, entity Y means that entity 12 that could not be found in the base event place can be found via entity 3. By repeating such an operation, it is possible to gradually reach an event place that meets its needs.
[0107]
The advertisement method shown here has the following effects.
(1) Since there is no broker (management unit) that manages public information of entities, it is possible to construct a self-organizing network that is strong in fault tolerance at low cost. In addition, it is not realistic to manage a huge number of public information (entry points and entity properties) with a broker.
(2) Since the event place suitable for the entity can be narrowed down to the formula to be determined, a desired event place can be efficiently searched. For example, even if the spillover range of the chain reaction (the hop number of the discovery event and the spillover range of the event path setting request for the entity property) is limited by the TTL value, as described above, the entity 12 via the entity 3 As a result, another event place to which the entity 12 belongs can be found. It should be noted that network traffic (event transfer count, event path setup request transfer count) can be reduced by limiting the spread range of the chain reaction.
[0108]
Note that entities that simply receive information from other entities without providing information (for example, without disclosing entity properties) will be forced to release the shared link as a penalty, As long as you are not satisfied, you can prevent them from participating in the event place again.
[0109]
<SE sharing method (automatic distribution)>
In the following, the mechanism of the SE sharing method will be described by taking SE (game application program) sharing in the game event place as an example.
(1) The owner of the entity 2 who is an operator of the game event place gives an event place name via the control panel of the entity 2. It is assumed that the event place name assigned here is “game”.
[0110]
(2) The entity control unit of entity 2 gives the global entity name “game + entity 2” to the SI-SW generated by the NE factory, as described above. Thereby, an event place is generated. At this time, the entity 2 that is the creator of the game event place automatically participates in the event place when the event place is generated.
(3) The owner of the entity 2 instructs the control panel of the entity 2 to plug in the game application program (SE). At this time, the executable file name of the application to be plugged in and the presence or absence of SE sharing are given as parameters.
[0111]
(4) The control panel of entity 2 notifies the entity control unit of this fact.
(5) The entity control unit of entity 2 stores the name of the executable file to be plugged in, and starts the application (SE) using the given executable file name, and between SI-SW and the application as described above Establish a session on That is, the plug-in in SIONet means establishing a session between the application and SI-SW.
[0112]
(6) The entity control unit of entity 2 advertises (publishes) the entity property of entity 2. Examples of the entity property public form of entity 2 include the following.
Entity 2 participates in the base event place and publishes the entity properties of entity 2 in the base event place.
Entity 2 discovers and participates in an event place that is closely related to the game event place by performing an expression search, and publishes the entity property of entity 2 in the event place.
-Entity 2 is a base entity. That is, the entity properties (entry point and global entity name) of entity 2 are made known.
[0113]
(7) The entity 1 that knows the existence of the entity 2 requests the entity 2 to participate in the game event place.
(8) If this request is approved, entity 1 requests entity 2 to establish a shared link. Then, a shared link is established between entity 1 and entity 2 as described above.
(9) When the shared link is established, the shared link establishment request destination (entity 2) returns information necessary for transmission / reception of the event in the event place to the establishment request source (entity 1). Specifically, for example, an event place name (global entity name), whether or not the event place that participated is a base event place, an event transfer method (routing method) in the event place, a description of the event place, a plug-in SE information (when there is SE sharing) and the like.
[0114]
Specifically, the SE information returned to the shared link establishment request source when sharing the SE share is, for example, an execution file name of the application to be plugged in or a file of the application.
(10) The entity control unit of the entity 1 that has received the file activates the application using the given executable file name as described above, and establishes a session between the SI-SW in the entity 1 and the application. Establish. As a result, the game application program is plugged into the entity 1 as SE.
[0115]
In other words, participation in an event place means that an entity group connected by a shared link is formed, and a participant shares a plug-in-completed application program. As a result, an entity that is a member in the event place can automatically use the plugged-in application simply by participating in the event place. Note that when the entity 1 leaves the game event place, the plugged-in game application program is plugged out. At that time, the entity 1 can continue to hold the received file, or the file may be deleted at the time of plug-out.
[0116]
The operation described above is application sharing in a pure P2P network environment. Therefore, the distribution of the application program is performed only between the two parties, that is, the shared link establishment destination entity and the establishment source entity, and thus does not affect other entities that are already coupled by the shared link. That is, since the processing is localized between the two parties for file transfer, scalable SE sharing can be achieved.
[0117]
<Business model>
Here, an embodiment in which the above-described SIONet is provided as a service will be described.
(1) Client server model
This is a form in which an event place is operated only by a predetermined entity. That is, only a predetermined entity can participate (Join) in the event place, and an entity permitted to participate constitutes an entity group by establishing a shared link between the entities. On the other hand, the other entities establish a session with the entity group, and send and receive events via the session. That is, an event place (a predetermined group of entities) is a server, and other entities correspond to clients. In this business model, each entity that is a member of an entity group behaves as an autonomous distributed computer, and when any entity falls into a failure, the remaining entities are self-organized and continue to operate the event place. In order to improve the processing capacity of the server, a new entity may be added to the event place. Therefore, it is possible to realize a scalable server that is strong in fault tolerance, inexpensive, and scalable as compared with the conventional server realization method.
[0118]
(2) Hybrid model
For example, an entity that is an operator of a game event place generates a game event place and becomes a base entity in the event place. On the other hand, an entity positioned as a user of a game event place enjoys the service at the event place by participating in the event place. In the conventional client server model, new capital investment (CPU power, storage, communication bandwidth, etc.) was required in proportion to the increase in the number of users, but this business model is based on the fact that users participate in the event place. In order to provide the user's own entity for service operation, the event place operator does not need new capital investment. Therefore, an inexpensive and scalable P2P service environment can be constructed. Note that the base entity can authenticate and charge a user (entity) participating in the event place. In addition, the base entity sends out a discovery event to discover an entity that can establish a shared link (alternate entity) from the entity group, and notifies the entity that wants to participate to the discovered entity. It is also possible to establish a shared link between the two.
[0119]
(3) Pure model
This is a business model in which all entities can freely participate (leave) in the event place.
As mentioned above, SIONet can realize various business models with a common mechanism by reducing to operation / placement problem. Therefore, it has a great effect on development man-hours, scale, debugging efficiency, ease of maintenance and the like.
[0120]
As described above, an entity in the “suspended” state cannot disclose an entrance or an entity property. An entity in the “suspend” state transitions to an “active” state by joining an arbitrary event place. Only entities in the “active” state can expose entrances and entity properties. Also, only the entities that are joined to the base event place can open the entrance. An entity can actually publish an entrance or an entity property when satisfying “publication is instructed by the control panel” and “the number of established sessions (shared link) for the entity does not exceed the default value”. For example, even if the owner of an entity instructs the disclosure using the control panel, if the shared link is established beyond the default value, the private mode is automatically set. The default value can be set on the control panel. For example, the entity owner can set the default value based on the ability of the entity.
[0121]
Network entity, network entity factory,
The entity control unit, control panel, service entity, semantic information switch, semantic information router, semantic information gateway may be realized by dedicated hardware, and is configured by a memory and a CPU (central processing unit). The function may be realized by loading a program for realizing the function into a memory and executing the program.
[0122]
Network entity, network entity factory,
A program for realizing the functions of the entity control unit, control panel, service entity, semantic information switch, semantic information router, semantic information gateway is recorded on a computer-readable recording medium, and the program recorded on the recording medium is recorded. You may implement | achieve by making a computer system read and executing. Here, the “computer system” includes an OS and hardware such as peripheral devices.
Further, the “computer system” includes a homepage providing environment (or display environment) if a WWW system is used.
[0123]
The “computer-readable recording medium” refers to a portable medium such as a flexible disk, a magneto-optical disk, a ROM, and a CD-ROM, and a storage device such as a hard disk built in the computer system. Furthermore, the “computer-readable recording medium” dynamically holds a program for a short time, like a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line. In this case, a volatile memory in a computer system serving as a server or a client in that case is also used to hold a program for a certain period of time. The program may be a program for realizing a part of the functions described above, and may be a program capable of realizing the functions described above in combination with a program already recorded in a computer system.
[0124]
[Embodiment of the Invention]
Hereinafter, first, the basic concept of the present invention will be described.
In the present invention, the reply information returned from the event receiver to the event transmission source is called a reply notification or a reply event.
For example, considering the case where the entity 2 fires in response to the event sent by the entity 1, the entity 2 can transmit the return information to the entity 1. This return information corresponds to a reply notification or a reply event.
[0125]
SIONet provides the following three methods for controlling the reply notification.
(1) How a service entity establishes an event path
Semantic information for reply notification is defined in advance between service entities. Each service entity registers the acquisition condition of the semantic information as a filter, thereby establishing an event path in the event transfer shared link.
This event path causes a chain reaction for the reply event, and the reply event is transferred to the entity that sent the event.
[0126]
(2) How an entity manager establishes an event path
Using the semantic information that SIONet has reserved for the network entity, the entity manager establishes an event path for the reply event on the shared link for event forwarding.
This is established only once at the time of establishing a shared link, and the process for establishing the event path can be regarded as a static fixed overhead.
[0127]
(3) How to establish an event path on a shared link for reply events
An event path for a reply event is dynamically established for a shared link for a reply event, triggered by event forwarding based on the shared link for event forwarding.
In this method, since an event path is dynamically established in proportion to the number of entities that have transmitted an event, overhead is generated in proportion to the proportion.
[0128]
Hereinafter, the mechanism will be described in detail with reference to FIGS.
As shown in FIG. 1, consider a case where the entities 1 to 3 are connected via shared links to form an event place.
In FIG. 1, entity 1 and entity 2 are shared links SL.1, 2, Shared link SL2,1Entity 1 and Entity 3 are shared links SL1,3, Shared link SL3,1Are established.
[0129]
Shared link SL1, 2, SL2,1, SL1,3, SL3,1Are each composed of an event transfer shared link and a reply event shared link.
The shared link for event transfer is the same as the receiving session (1) set between the semantic information switch included in another entity and the semantic information router included in itself, and the semantic information router included in itself. It consists of a transmission session {circle around (2)} set between semantic information switches contained in itself.
In addition, the shared link for reply event includes the reception session (3) set between the semantic information switch included in the reply event and the semantic information router included in the self event, and the semantic information router included in the reply event. A transmission session {circle over (4)} set between semantic information switches included in other entities.
[0130]
Consider the case where SE2 which is the service entity of entity 2 sends the event shown in FIG. 26 in the event place shown in FIG.
As shown in FIG. 26, the event transmitted by SE2 includes a semantic information control unit, a control information unit, and a data unit.
The semantic information control unit includes an event routing control semantic information unit indicating an event transfer attribute and an internal entity semantic information unit set by the internal entity. In the semantic information for control, event type, hop attribute, TTL, and transfer source entity are set as event attribute information, and used for matching with event transfer conditions registered in the filter. In the semantic information for the internal entity, attribute information of the internal entity is set and used for matching with the event path.
For example, when TTL: 2 is set as the event attribute, the establishment of the event path can be limited to entity devices within the range where the number of hop stages is two. Also, in all entity devices, for example, by defining TTL: -1 as unlimited number of hop stages, it is possible not to limit the range of event path establishment based on the number of hop stages.
In the control information part, a transmission source entity name is set. Note that the session number and event number used by SE2 may be arbitrarily set. In this case, the session number is used to limit the internal entities fired by the reply event. The event number is used for controlling a chain reaction by a reply event for each transmission event. For example, this is used when canceling a reply notification for an event after the event is sent out.
[0131]
Where SI-R1 , 2Suppose that filter 1-2 / e is registered for SI-SW2, as shown in FIG.
As shown in FIG. 1, the filter 1-2 / e is
Hop attribute == upstream or upstream / downstream
TTL ≧ 1 or TTL = −1
Since it matches the semantic information part of the sending event sent by SE2, the filter reacts and a stimulus is given to session (1). As a result, SI-R1 , 2Will ignite. In the following, from the viewpoint of simplifying the description, it is assumed that the matching with the event path matches.
[0132]
At this time, SI-R1 , 2Registers the filter 1-2 / r for firing a reply event via the reception session (3) and transfers the received event via the transmission session (2). As a result, the filter 3-1 / e reacts and SI-R3 , 1Fires.
[0133]
Similarly, SI-R3 , 1Registers the filter 3-1 / r through the reception session (3) and sends the event to the SI-SW 3 through the transmission session (2).
Here, as a result, it is assumed that SE3 is ignited.
[0134]
Hereinafter, a case where the fired SE3 receives an event and issues a reply notification to the event will be considered.
FIG. 26 shows the structure of the reply event sent by SE3 at this time. Similar to the above event, the reply event sent by SE3 includes a semantic information part (for control), a semantic information part (for internal entity), a control information part, and a data part door. In the semantic information section (for control), an event type, an entity name, a session number, and an event number are set as control information for a received event, and are used for matching with a reply event transfer condition.
Due to this reply event, SI-R3 , 1Ignited via the reception session (3) and SI-R3 , 1Performs event transmission through the transmission session (4), thereby enabling SI-R1 , 2Fires and eventually SE2 fires.
[0135]
Thus, an event path for a reply event is established for the reply shared link, triggered by the transfer of the event sent by SE2.
As described in the event path multiplicity, the relationship strength between entities is managed by the event path multiplicity which is a weight value of the event path. This event path multiplicity (relationship strength) decays with time. That is, with the passage of time, the current multiplicity is subtracted by a preset value (real value). When the multiplicity becomes zero, the event path is forcibly released. On the other hand, when SI-R is fired by a reply event, the current multiplicity is added by a preset value. In this way, the relationship strength is dynamically changed based on the SI-R firing rate due to the reply event, and the lifetime of the event path is determined.
This mechanism is also applied to an event path established for a shared link for event transfer, and is used as a means for expressing relationship strength together with life management of the event path.
[0136]
FIG. 28 shows a communication method provided in SIONet. SIONet provides communication modes such as broadcast mode, multicast mode, unicast mode, and reply notification. These communication modes are possible by dynamically controlling the manner of chain reaction between entities.
That is, it is possible to control the way of chain reaction (event routing or relationship between entities) between entities by the filter value registered as a filter by the semantic information router.
Thus, in SIONet, there is only a unified mechanism called “chain reaction”. The function addition is achieved by adding newly specified semantic information.
[0137]
In the conventional architecture, adding a function means adding a new method (function program). That is, as many methods as the number of functions were created. However, with such a method, it is hardly possible to desire rapid system development, minimization of development scale, reduction in the number of debugging steps, reduction in development costs, ease of maintenance and the like.
In SIONet, once you create a method for chain reaction, you don't need to add a new method any more. That is, after the method is created, semantic information (data) for causing a new chain reaction may be added as necessary.
[0138]
The above is one of the important concepts in SIONet, and each communication function is described below.
(A) Broadcast
In broadcast, events are forwarded to all entities in the event place. Therefore, whether or not the entity is fired by the transferred event is determined by checking with a filter in the entity. This is achieved by establishing an event path for unconditional routing. This event path is set only once when a shared link for event transmission is established, and is not changed until the shared link is reestablished. Broadcast mode can be handled as an equivalent model to IP multicast and Gnutella forwarding methods.
[0139]
(B) Multicast
An event is forwarded only to an entity satisfying an arbitrary condition from entities belonging to the event place. This is achieved by establishing an event path for lexical concept routing. Note that the event path establishment trigger and the establishment method differ between the catch-up mode and the search mode.
[0140]
(C) Unicast
Forward events only to specific entities. This is achieved by establishing an event path for vocabulary routing. Note that the event path establishment trigger and the establishment method differ between the catch-up mode and the search mode.
[0141]
(D) Reply notification
When the event receiver sends an event reply notification to the event transmission source, the reply event is transferred to the event transmission source. This includes a method of setting an event path for vocabulary routing in the shared link for reply events, and a method of establishing an event path in the shared link for event transfer.
[0142]
FIG. 29 shows a result of comparing the SIONet communication method with another communication method using the distributed file search as an example.
Distributed file search in a network OS or the like is generally realized using IP broadcast as shown in FIG.
For example, the terminal that published the file receives the packet transmitted to the port number 10. On the other hand, the terminal X that is the file search request source designates the IP broadcast address (all terminals) and the port number 10 and sends a search packet for the file α.
For this reason, the search packet is also sent to the terminal B that has not instructed the disclosure of the file, that is, the packet reception at the port 10, and as a result, the terminal B discards the packet. On the other hand, after receiving the search packet, the terminal C publishing the file β discards it as a result of collation with the packet.
As described above, in the file search using the IP broadcast, unnecessary search packet transmission and unnecessary collation processing occur.
[0143]
On the other hand, in a distributed file search using IP multicast, for example, a terminal that has released a file participates in a multicast group. Then, the packet transmitted to the port number 10 is received.
On the other hand, a terminal that searches for a file designates an IP multicast address (all terminals belonging to the group) and port number 10 and sends a search packet for file α.
Therefore, since the search packet is transmitted only to the member terminals belonging to the multicast group, the packet is not transmitted to terminals other than the member, but the terminal requesting packet reception at port 15 The packet is transmitted to B, and as a result, the terminal B discards the packet.
Further, the packet is also discarded here by the collation process with the terminal C that discloses the file β.
[0144]
This method corresponds to the broadcast mode (unconditional routing) of SIONet and the communication method of Gnutella on the conceptual model.
SIONet's broadcast mode and Gnutella are not implemented using IP multicast, but send packets to all terminals in the group (in SIONet, send events to all entities in the group If all the terminals are modeled from the viewpoint of matching with the received packet, the three can be positioned as equivalent models.
On the other hand, in the multicast mode of SIONet, the search packet for the file α is transmitted only to the terminal A and the terminal C, and is not transmitted to the terminal B. Therefore, in SIONet, the problem that unnecessary packet transmission causes an increase in network traffic can be solved.
[0145]
Hereinafter, an embodiment of an entity device of the present invention will be described. As described above, the entity device according to the present embodiment includes the semantic information switch and the semantic information router.
For example, in FIG. 1, the semantic information switches (SI-SWs 1 to 3), as described above, collate the semantic information registered as a filter with the semantic information attached to the event, and receive the event fired as a result. A switch that activates an entity, and specifically includes a transmission unit, a reception unit, a verification unit, and a control unit.
The transmission unit transmits the event that is matched by the verification unit, that is, the event that has been fired, to the transmission destination of the event.
The receiving unit receives an event from the event transmission source entity device.
The collation unit receives another event (for example, the entity device 3) that has received an event that matches the first filter (for example, the filter 1-2 / e in the entity device 1 or the filter 3/1 / e in the entity device 3). Semantic information indicated by a reply event received from the second filter and a second filter (for example, SI-R) held by the semantic information router.1, 2Filter 1-2 / r and SI-R held by3,1Is matched with the filter 3-1 / r held by.
The control unit controls event routing of the reply event based on the collation result. In other words, as described above, when SE3 sends a reply notification for an event sent by SE2, in entity device 1, semantic information switch 1 sets the event type and entity name set in the semantic information part (for control). SI-R by checking session number and event number3 , 1Ignited via the reception session (3) and SI-R3 , 1Transmits a reply event via the transmission session (4), and SI-R1 , 2Fires and eventually SE2 fires.
[0146]
The semantic information router holds a first filter indicating an event acquisition condition and a second filter indicating a reply event acquisition condition associated with the event. Note that the semantic information router may hold only a first filter indicating an event acquisition condition in advance.
In this case, the collation unit of the semantic information switch collates whether the semantic information indicated by the event received from the other entity device matches the first filter held by the semantic information router. Based on the collation result, the second filter indicating the acquisition condition of the reply event associated with the event is set in the semantic information router. Further, the collation unit collates whether the semantic information indicated by the reply event received from another entity device that has received the event that matches the first filter matches the second filter, and performs control. The unit controls event routing of the reply event based on the collation result.
[0147]
Therefore, according to the entity device of the present embodiment, in an autonomous distributed network that dynamically controls the manner of chain reaction of entities by stimulation and firing, an event receiver notifies the event sender of an event reply. The effect that can be obtained.
[0148]
The embodiment of the present invention has been described in detail with reference to the drawings. However, the specific configuration is not limited to this embodiment, and includes design changes and the like within a scope not departing from the gist of the present invention.
[0149]
The entity device described above has a computer system therein.
A series of processes relating to the reply notification control process described above is stored in a computer-readable recording medium in the form of a program, and the above process is performed by the computer reading and executing the program.
That is, each processing means and processing unit in the entity device is such that a central processing unit such as a CPU reads the program into a main storage device such as a ROM or a RAM and executes information processing / calculation processing. It is realized.
Here, the computer-readable recording medium means a magnetic disk, a magneto-optical disk, a CD-ROM, a DVD-ROM, a semiconductor memory, or the like. Alternatively, the computer program may be distributed to the computer via a communication line, and the computer that has received the distribution may execute the program.
[0150]
【The invention's effect】
As described above, the present invention provides a first filter indicating an event acquisition condition in an event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link. The entity device that holds the second filter indicating the acquisition condition of the reply event associated with the event receives the event that matches the first filter (k is a natural number satisfying 1 <k <n). Since the semantic information indicated by the reply event received from the entity device is matched with whether or not the second filter matches, the event routing of the reply event is controlled based on the matching result. In an autonomous distributed network that dynamically controls how chain reactions occur, event recipients are It is possible to obtain an effect that can perform reply notification events for.
[0151]
The present invention also provides semantic information for holding a first filter indicating an event acquisition condition in an event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link. The entity device having a router collates whether the semantic information indicated by the event received from the k-th entity device (k is a natural number satisfying 1 <k <n) matches the first filter, and collation Based on the result, the second filter indicating the acquisition condition of the reply event associated with the event is set in the semantic information router, and the lth (where l is 1 <l < It is checked whether the semantic information indicated by the reply event received from the entity device of a natural number satisfying n (l ≠ k) matches the second filter. Based on the comparison result, so it controls the event routing reply event, effects that can be dynamically establish an event path for reply event is obtained.
[Brief description of the drawings]
FIG. 1 is a diagram showing how entities 1 to 3 form an event place via a shared link in an embodiment of the present invention.
FIG. 2 is a diagram for explaining entities and a diagram for explaining classification of entities in the embodiment.
FIG. 3 is a diagram illustrating entity state transition in the embodiment;
FIG. 4 is a diagram illustrating an internal configuration of an entity in the embodiment.
FIG. 5 is a diagram for explaining generation of an event place in the embodiment.
FIG. 6 is a diagram illustrating an operation in which an entity participates in an event place in the embodiment.
FIG. 7 is a diagram illustrating a semantic information switch and a session in the embodiment.
FIG. 8 is a diagram illustrating a configuration of an event in the embodiment.
FIG. 9 is a diagram illustrating a semantic information system in the embodiment.
FIG. 10 is a diagram illustrating a global entity name in the embodiment.
FIG. 11 is a diagram illustrating a service entity plug-in in the embodiment;
FIG. 12 is a diagram illustrating a reference model in the embodiment.
FIG. 13 is a diagram for explaining a shared link in the embodiment.
FIG. 14 is a diagram illustrating a shared link in the embodiment.
FIG. 15 is a diagram illustrating a shared link in the embodiment.
FIG. 16 is a diagram illustrating an event path in the embodiment.
FIG. 17 is a diagram for explaining re-establishment of a shared link in the embodiment.
FIG. 18 is a diagram illustrating a hop attribute in the embodiment.
FIG. 19 is a diagram illustrating event place and entity image reduction in the embodiment;
FIG. 20 is a diagram for explaining event place and entity image reduction in the embodiment;
FIG. 21 is a diagram illustrating advertisement of an entity in the same embodiment.
FIG. 22 is a diagram illustrating entity advertisement in the embodiment;
FIG. 23 is a diagram showing changes in a business model of a communication network.
FIG. 24 is a diagram showing dimensions of a P2P model.
FIG. 25 is a diagram illustrating the concept of SIONet.
FIG. 26 is a diagram illustrating a configuration of an event transmitted by an entity and a reply event corresponding to the event.
FIG. 27 is an explanatory diagram showing filter classification managed by a semantic information switch included in each entity;
FIG. 28 is a diagram illustrating a communication method included in SIONet.
FIG. 29 is a diagram illustrating a result of comparing the SIONet communication method with another communication method using the distributed file search as an example.
FIG. 30 is a diagram illustrating a state of general IP broadcast and IP multicast.
FIG. 31 is a diagram illustrating a result of evaluating a communication method of SIONet and another communication method using a distributed file search as an example.

Claims (12)

第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、
イベントの取得条件を示す第１のフィルタと、前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタとを保持する意味情報ルータと、
前記第１のフィルタと一致するイベントを受信した第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記意味情報ルータが保持する第２のフィルタとが一致するか否かを照合する照合部と、該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御する制御部とを有する意味情報スイッチと
を具備することを特徴とするエンティティ装置。In an event place configured by connecting first to nth (n is a natural number) entity devices via a shared link,
A semantic information router that holds a first filter indicating an event acquisition condition and a second filter indicating a reply event acquisition condition associated with the event;
Semantic information indicated by a reply event received from an entity device of the kth (k is a natural number satisfying 1 <k <n) having received an event that matches the first filter, and a second information held by the semantic information router An entity apparatus comprising: a semantic information switch having a collation unit that collates whether or not a filter matches; and a control unit that controls event routing of the reply event based on the collation result . 第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、
イベントの取得条件を示す第１のフィルタを保持する意味情報ルータと、
第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するイベントが示す意味情報と、前記意味情報ルータが保持する第１のフィルタとが一致するか否かを照合する照合部と、該照合結果に基づいて、前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタを前記意味情報ルータに設定する制御部とを有する意味情報スイッチと
を具備することを特徴とするエンティティ装置。In an event place configured by connecting first to nth (n is a natural number) entity devices via a shared link,
A semantic information router holding a first filter indicating an event acquisition condition;
A collation unit that collates whether or not the semantic information indicated by the event received from the kth entity device (k is a natural number satisfying 1 <k <n) matches the first filter held by the semantic information router. And a semantic information switch having a control unit that sets, in the semantic information router, a second filter indicating an acquisition condition of a reply event associated with the event based on the matching result. Entity device. 前記照合部は、さらに、前記第１のフィルタと一致するイベントを受信した第ｌ（ｌは１＜ｌ＜ｎを満たす自然数 ただしｌ≠ｋ）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合し、
前記制御部は、さらに、該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御する
ことを特徴とする請求項２に記載のエンティティ装置。The collation unit further includes semantic information indicated by a reply event received from an l-th entity device (l is a natural number satisfying 1 <l <n where l ≠ k) that has received an event that matches the first filter. , Check whether the second filter matches,
The entity device according to claim 2, wherein the control unit further controls event routing of the reply event based on the collation result. 第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタと前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタとを保持する前記エンティティ装置が、前記リプライイベントのイベントルーティングを制御するリプライ通知制御方法であって、
前記第１のフィルタと一致するイベントを受信した第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合し、
該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御する
ことを特徴とするリプライ通知制御方法。In an event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link, a first filter indicating an event acquisition condition and a reply event associated with the event The entity device that holds a second filter indicating an acquisition condition is a reply notification control method for controlling event routing of the reply event,
Does the second filter match the semantic information indicated by the reply event received from the kth entity device (k is a natural number satisfying 1 <k <n) that has received the event that matches the first filter? Whether or not
A reply notification control method comprising controlling event routing of the reply event based on the collation result. 第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタを保持する意味情報ルータを有する前記エンティティ装置が、前記イベントに対応するリプライイベントのイベントルーティングを制御するリプライ通知制御方法であって、
第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するイベントが示す意味情報と、前記第１のフィルタとが一致するか否かを照合し、
該照合結果に基づいて、前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタを前記意味情報ルータに設定する
ことを特徴とするリプライ通知制御方法。In the event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link, the entity device includes a semantic information router that holds a first filter indicating an event acquisition condition. Is a reply notification control method for controlling event routing of a reply event corresponding to the event,
The k-th (k is a natural number satisfying 1 <k <n) is collated with the semantic information indicated by the event received from the entity device, and the first filter is matched.
A reply notification control method, comprising: setting a second filter indicating a reply event acquisition condition associated with the event in the semantic information router based on the collation result. 前記エンティティ装置が、さらに、
前記第１のフィルタと一致するイベントを受信した第ｌ（ｌは１＜ｌ＜ｎを満たす自然数 ただしｌ≠ｋ）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合し、
該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御する
ことを特徴とする請求項５に記載のリプライ通知制御方法。The entity device further comprises:
Semantic information indicated by a reply event received from an l-th entity device (l is a natural number satisfying 1 <l <n where l ≠ k) having received an event that matches the first filter, and the second filter Match whether or not
6. The reply notification control method according to claim 5, wherein event routing of the reply event is controlled based on the collation result. 第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタと前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタとを保持する前記エンティティ装置に、前記リプライイベントのイベントルーティング制御を実行させるためのリプライ通知プログラムであって、
前記第１のフィルタと一致するイベントを受信した第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合する処理と、
該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御する処理と
を実行させるためのリプライ通知制御プログラム。In an event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link, a first filter indicating an event acquisition condition and a reply event associated with the event A reply notification program for causing the entity device holding a second filter indicating an acquisition condition to execute event routing control of the reply event,
Does the second filter match the semantic information indicated by the reply event received from the kth entity device (k is a natural number satisfying 1 <k <n) that has received the event that matches the first filter? Processing to verify whether or not,
A reply notification control program for executing processing for controlling event routing of the reply event based on the collation result. 第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタを保持する意味情報ルータを有する前記エンティティ装置に、前記イベントに対応するリプライイベントのイベントルーティングを制御する処理を実行させるためのリプライ通知制御プログラムであって、
第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するイベントが示す意味情報と、前記第１のフィルタとが一致するか否かを照合する処理と、
該照合結果に基づいて、前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタを前記意味情報ルータに設定する処理と
を実行させるためのリプライ通知制御プログラム。In the event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link, the entity device includes a semantic information router that holds a first filter indicating an event acquisition condition. And a reply notification control program for executing processing for controlling event routing of a reply event corresponding to the event,
A process of collating whether or not semantic information indicated by an event received from an entity device of the k-th (k is a natural number satisfying 1 <k <n) matches the first filter;
A reply notification control program for executing processing for setting, in the semantic information router, a second filter indicating an acquisition condition of a reply event associated with the event based on the collation result. 前記エンティティ装置に、さらに、
前記第１のフィルタと一致するイベントを受信した第ｌ（ｌは１＜ｌ＜ｎを満たす自然数 ただしｌ≠ｋ）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合する処理と、
該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御する処理と
を実行させるための請求項８に記載のリプライ通知制御プログラム。The entity device further comprising:
Semantic information indicated by a reply event received from an l-th entity device (l is a natural number satisfying 1 <l <n where l ≠ k) that has received an event that matches the first filter, and the second filter, Processing to check whether or not match,
The reply notification control program according to claim 8, for executing processing for controlling event routing of the reply event based on the collation result. 第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタと前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタとを保持する前記エンティティ装置に、前記リプライイベントのイベントルーティング制御を実行させるためのリプライ通知プログラムを記録した記録媒体であって、
前記第１のフィルタと一致するイベントを受信した第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合する処理と、
該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御する処理と
を実行させるためのリプライ通知制御プログラムを記録した記録媒体。In an event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link, a first filter indicating an event acquisition condition and a reply event associated with the event A recording medium recording a reply notification program for causing the entity device holding a second filter indicating an acquisition condition to execute event routing control of the reply event,
Does the second filter match the semantic information indicated by the reply event received from the kth entity device (k is a natural number satisfying 1 <k <n) that has received the event that matches the first filter? Processing to verify whether or not,
A recording medium recording a reply notification control program for executing processing for controlling event routing of the reply event based on the collation result. 第１から第ｎ（ｎは自然数）のエンティティ装置をシェアードリンクを介して接続して構成されるイベントプレースにおいて、イベントの取得条件を示す第１のフィルタを保持する意味情報ルータを有する前記エンティティ装置に、前記イベントに対応するリプライイベントのイベントルーティングを制御する処理を実行させるためのリプライ通知制御プログラムを記録した記録媒体であって、
第ｋ（ｋは１＜ｋ＜ｎを満たす自然数）のエンティティ装置より受信するイベントが示す意味情報と、前記第１のフィルタとが一致するか否かを照合する処理と、
該照合結果に基づいて、前記イベントと対応付けられたリプライイベントの取得条件を示す第２のフィルタを前記意味情報ルータに設定する処理と
を実行させるためのリプライ通知制御プログラムを記録した記録媒体。In the event place configured by connecting first to n-th (n is a natural number) entity devices via a shared link, the entity device includes a semantic information router that holds a first filter indicating an event acquisition condition. In addition, a recording medium recording a reply notification control program for executing processing for controlling event routing of a reply event corresponding to the event,
A process of collating whether or not semantic information indicated by an event received from an entity device of the k-th (k is a natural number satisfying 1 <k <n) matches the first filter;
A recording medium storing a reply notification control program for executing processing for setting a second filter indicating a reply event acquisition condition associated with the event in the semantic information router based on the collation result. 前記エンティティ装置に、さらに、
前記第１のフィルタと一致するイベントを受信した第ｌ（ｌは１＜ｌ＜ｎを満たす自然数 ただしｌ≠ｋ）のエンティティ装置より受信するリプライイベントが示す意味情報と、前記第２のフィルタとが一致するか否かを照合する処理と、
該照合結果に基づいて、前記リプライイベントのイベントルーティングを制御する処理と
を実行させるための請求項１１に記載のリプライ通知制御プログラムを記録した記録媒体。The entity device further comprising:
Semantic information indicated by a reply event received from an l-th entity device (l is a natural number satisfying 1 <l <n where l ≠ k) that has received an event that matches the first filter, and the second filter, Processing to check whether or not match,
The recording medium which recorded the reply notification control program of Claim 11 for performing the process which controls the event routing of the said reply event based on this collation result.
JP2003070446A 2003-03-14 2003-03-14 Entity device, reply notification control method, reply notification control program, and recording medium thereof Expired - Fee Related JP3792664B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2003070446A JP3792664B2 (en) 2003-03-14 2003-03-14 Entity device, reply notification control method, reply notification control program, and recording medium thereof

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2003070446A JP3792664B2 (en) 2003-03-14 2003-03-14 Entity device, reply notification control method, reply notification control program, and recording medium thereof

Publications (2)

Publication Number Publication Date
JP2004282374A JP2004282374A (en) 2004-10-07
JP3792664B2 true JP3792664B2 (en) 2006-07-05

Family

ID=33287203

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003070446A Expired - Fee Related JP3792664B2 (en) 2003-03-14 2003-03-14 Entity device, reply notification control method, reply notification control program, and recording medium thereof

Country Status (1)

Country Link
JP (1) JP3792664B2 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4544072B2 (en) * 2005-07-20 2010-09-15 ブラザー工業株式会社 Node device, computer program, information distribution system, and network participation method

Also Published As

Publication number Publication date
JP2004282374A (en) 2004-10-07

Similar Documents

Publication Publication Date Title
JP2021513265A (en) Blockchain-based systems and methods for propagating data over networks
JP3850378B2 (en) Entity device, ad hoc network construction method, ad hoc network construction program, and storage medium thereof
JP2021517767A (en) Random differential relay and network coding systems and methods
JP3946658B2 (en) Entity device, event transfer control method, event transfer control program, and recording medium therefor
JP3792664B2 (en) Entity device, reply notification control method, reply notification control program, and recording medium thereof
JP3803329B2 (en) Entity device, alternative entity search method, alternative entity search program, and recording medium thereof
JP3822178B2 (en) Entity device, failure recovery method, and computer program
JP3723126B2 (en) Entity device, name assigning method, recording medium, and program
JP3723127B2 (en) Entity device, information disclosure system, method, recording medium, and program
JP3844747B2 (en) Entity device, shared link re-establishment method, shared link re-establishment program, and recording medium thereof
JP3987817B2 (en) Entity device, service sharing method, and computer program
JP3983187B2 (en) Entity device, link re-establishing method, and computer program
JP3910550B2 (en) Semantic information network data retrieval method, semantic information network system and program
JP3782345B2 (en) Embedded system, method, recording medium, and program
JP3850379B2 (en) Semantic information network construction method, semantic information network system, and program
JP3974054B2 (en) Entity device, shared link control method, authentication method, shared link control program, and recording medium thereof
JP4028429B2 (en) Computer, event place search method, and computer program
JP3732762B2 (en) Semantic information switch, semantic information router, method, recording medium, program
JP3974357B2 (en) Shared link setting method, communication system, entity device, computer program thereof, and recording medium thereof
JP2004265325A (en) Service providing method in semantic information network, semantic information network system, and program
JP3977387B2 (en) Semantic information switch, semantic information router, method, recording medium, program
JP3974158B2 (en) Event place search method, communication system, entity device, computer program thereof, and recording medium thereof
JP3977388B2 (en) Semantic information switch, semantic information router, method, recording medium, program
JP4170322B2 (en) Semantic information switch, semantic information router, method, recording medium, program
JP3977389B2 (en) Semantic information switch, semantic information router, method, recording medium, program

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20040709

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20060315

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20060328

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20060405

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090414

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100414

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100414

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110414

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120414

Year of fee payment: 6

LAPS Cancellation because of no payment of annual fees