意味情報ネットワークを用いた移動するサービス提供者探索方法および探索システムと送信端末および受信端末
【課題】 仲介者を介することなくネットワークを用いて移動するサービス提供者の探索を可能とする。
【解決手段】 タクシー運転手１〜３は、ＧＰＳ受信機等により位置情報を所得し、この位置情報をフィルタとして意味情報ネットワーク１０に対して設定する。タクシー要求者は、携帯端末４０に設けられているＧＰＳ受信機等により位置情報を取得し、この位置情報を含むタクシー要求をイベントとして意味情報ネットワーク１０に送信する。タクシー要求イベントを受信したタクシー運転手は、このタクシー要求を受け付け、タクシー要求者に対して自己の位置情報を含む応答を通知する。タクシー要求者は、この応答を受信し、サービスを受けることを決定した旨の通知をそのタクシー運転手に対して行う。この通知を受けたタクシー２のタクシー運転手は、設定しているフィルタを解除し、タクシー要求者の所在地に向かいタクシーサービスを提供する。
【解決手段】 タクシー運転手１〜３は、ＧＰＳ受信機等により位置情報を所得し、この位置情報をフィルタとして意味情報ネットワーク１０に対して設定する。タクシー要求者は、携帯端末４０に設けられているＧＰＳ受信機等により位置情報を取得し、この位置情報を含むタクシー要求をイベントとして意味情報ネットワーク１０に送信する。タクシー要求イベントを受信したタクシー運転手は、このタクシー要求を受け付け、タクシー要求者に対して自己の位置情報を含む応答を通知する。タクシー要求者は、この応答を受信し、サービスを受けることを決定した旨の通知をそのタクシー運転手に対して行う。この通知を受けたタクシー２のタクシー運転手は、設定しているフィルタを解除し、タクシー要求者の所在地に向かいタクシーサービスを提供する。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、ネットワーク上に分散するコンテンツの中からエンドユーザの興味に合致するコンテンツを特定する、あるいは、コンテンツプロバイダがコンテンツを配布すべき最適なコンシューマを特定する意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、移動するサービス提供者探索方法および探索システムに関する。
【０００２】
【従来の技術】最近、携帯電話等の携帯端末を使用して様々なサービスを提供するサービス提供者を探索することができるようになっている。しかし、これらのシステムでは、サービス提供者は移動しないことが前提となっているため、タクシー、屋台等の移動していて現在位置を特定することができない移動するサービス提供者を探索することはできない。また、サービス要求者も携帯端末を保有することにより移動しているため、従来のシステムでは、ある位置に居るサービス要求者に対して最も迅速にサービスを行うことができる移動するサービス提供者を探索するようなことを行うことはできなかった。
【０００３】また、一般にサービス要求者が複数の不特定のサービス提供者の探索を行う場合には、サービス提供者とサービス要求者との仲介を行うための仲介者が必要となる。そして、仲介者が存在することにより、仲介料の発生、仲介者における照合処理負荷の集中化、設定している情報のリアルタイムな変化が不可能であるといった問題が発生する。特にサービス要求者、サービス提供者がともに移動する者である場合、これらの者の間の仲介を行うためには位置情報のリアルタイムな変更が不可欠となり、仲介者が必要となるようなシステムではこのようなリアルタイムに変化する情報を扱うことは困難である。
【０００４】
【発明が解決しようとする課題】上述した従来のサービス提供者探索システムでは、サービス提供者と、そのサービスを受けるサービス要求者とが共に移動しているような場合、サービス提供者の現在の位置と、サービス要求者の現在の位置の両方を考慮して、そのサービス要求者に最も近いサービス提供者を探索するようなシステムを実現することができなかった。また、サービス要求者が複数の不特定のサービス提供者の探索を行う場合には、サービス提供者とサービス要求者との仲介を行うための仲介者が必要となる。
【０００５】本発明は上述したような従来の技術が有する問題点に鑑みてなされたものであって、複数の移動するサービス提供者の中から、サービス要求者に最も近いサービス提供者を探索することを、仲介者を必要とすることなく可能とする移動するサービス提供者探索方法および検出システムを実現することを目的とする。
【０００６】
【課題を解決するための手段】上記目的を達成するために、本発明の移動するサービス提供者探索方法は、データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス提供者の端末が、イベントとして送信された前記サービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報を含めて前記サービス要求者の携帯端末へ送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきた応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する。
【０００７】本発明によれば、サービス提供者はサービス提供者の端末に設けられた位置情報取得手段により取得された位置情報をフィルタとして設定し、サービス要求者はサービス要求者の携帯端末に設けられた位置情報取得手段により取得された位置情報を含むサービス要求をイベントとして意味情報ネットワークに送信するようにし、サービス提供者からの応答に含まれている位置情報に基づいてサービスを受けるサービス提供者を決定しているので、複数の移動するサービス提供者の中から、サービス要求者に最も近いサービス提供者を探索することが、仲介者を必要とすることなく可能となる。
【０００８】また、本発明の他の移動するサービス提供者探索方法は、データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス提供者の端末が、イベントとして送信された前記サービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置および目的地に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報を含めて前記サービス要求者の携帯端末へ送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきた応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する。
【０００９】本発明によれば、サービス要求者は、サービス要求を、サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして送信し、サービス提供者は、イベントとして送信されたサービス要求を受信すると、サービスを提供するサービス要求者をサービス要求者の位置および目的地に基づいて決定するようにしているので、サービス提供者は自己にとって都合のよいサービス要求者を選択することができる。
【００１０】本発明の他の移動するサービス提供者探索方法は、データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス提供者の端末が、イベントとして送信された前記サービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置および目的地に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報および前記目的地の情報から算出したサービス料金の情報を含めて前記サービス要求者の携帯端末へ送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきた応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置およびサービス料金に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する。
【００１１】本発明によれば、サービス要求者は、サービス要求を、サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして送信し、サービス提供者は、イベントとして送信されたサービス要求を受信すると、サービスを提供するサービス要求者をサービス要求者の位置および目的地に基づいて決定するようにしているので、サービス提供者は自己にとって都合のよいサービス要求者を選択することができる。さらに、サービス要求者は、サービス提供者からの応答を受信すると、サービス提供者からの応答に含まれている位置情報およびサービス料金の情報に基づいてサービスを受けるサービス提供者を決定しているので、複数の移動するサービス提供者の中から、サービス要求者からの距離およびサービス料金の額を総合的に考慮して最も最適と考えられるサービス提供者を探索することが可能となる。
【００１２】また、本発明の他の移動するサービス提供者探索方法は、前記サービス提供者がタクシー運転手であり、前記サービス要求者がタクシーの乗車を希望するタクシー要求者である。
【００１３】また、本発明の移動するサービス提供者探索方法は、前記位置情報手段をＧＰＳ受信機とするようにしてもよい。
【００１４】
【発明の実施の形態】本発明を説明する前に、本発明の前提となる、発信する情報のメッセージ性を高めた分散型ネットワークシステムについて説明する。
【００１５】分散型指向のネットワークシステムとしては、ナップスターを用いるものが知られ、さらに、分散性を高めたネットワークシステムとしては、Ｇｎｕｔｅｌｌａを用いるものが知られている。
【００１６】まず、ナップスターを用いるネットワークシステムについて説明する。ナップスター利用者は、各ナップスター利用者が公開するファイルの情報を格納したナップスター社のサーバに検索要求を送信し、ナップスター社のサーバは検索したファイルを所有するナップスター利用者に関するＩＰアドレス等の情報を返信する。実際のファイルのやり取りはナップスター社のサーバを介することなく、ＩＰアドレスを入手した利用者が直接目的とするファイルを所有するナップスター利用者にアクセスすることにより行われる。
【００１７】Ｇｎｕｔｅｌｌａを用いるネットワークシステムの場合には、Ｇｎｕｔｅｌｌａ利用者の端末は、接続している相手端末の状態を定期的に確認し、メッセージやファイルの検索要求を中継し合うことが行われる。検索結果は検索要求を行った相手に戻され、その後のファイル転送はナップスターと同様に利用者間で直接行われる。これにより、サーバを用いることなくネットワークが構築されることとなる。
【００１８】これらの各ネットワークシステムのうち、ナップスターを用いるものにおいては、本発明が問題点とする仲介者に相当するサーバを必要とするため、本発明の目的を達成するものではない。
【００１９】Ｇｎｕｔｅｌｌａを用いるネットワークシステムにおいては、サーバを用いることなくメッセージやファイルの検索要求が行われるものの、発信する情報が単なるファイルの検索要求であり、この応答を確認した利用者によるファイルの転送が利用者間で行われるものであるため、オークションや逆オークション等の１対複数でのやり取りが必要となる形態にはそぐわない。
【００２０】発信する情報のメッセージ性を高めた分散型ネットワークシステムとして以下に説明する意味情報ネットワークシステムがあり、本発明は、このような意味情報ネットワークシステムを用いることを前提とする。
【００２１】まず、意味情報ネットワーク（Semantic Information-Oriented Network、以下、ＳＩＯＮと称する）について概要を説明する。ＳＩＯＮは、意味情報に基づいて、イベントを目的地まで配送することが可能なネットワークである。図１に、ＳＩＯＮの概念モデルを示す。図１において、各端末２は、意味情報（Semantic Information：ＳＩ）をＳＩＯＮ１に対して登録する。一方、イベントを送信する端末２は、図２に示す意味情報（Semantic information）とデータ（Data）から構成されるイベントをＳＩＯＮ１に送出する。ここでいう、意味情報とは、イベントに含まれるデータの特性を記述したものであり、データのメタ情報として位置づけられる。例えば、意味情報は、・データを“東京在住者”に配送する。
・データを“クラシックに興味のある人”に配送する。
・データを“１Ｍｂｐｓ以上の通信環境を有する人”に配送する。
・データを“目白通りを通行中の人”に配送する。
・データを“キーワード（例えば旅行）に合致するコンテンツを有するコンテンツプロバイダ”に配送する。
等の表現が用いられる。
【００２２】ＳＩＯＮは、上述したような意味情報に基づいて、データを配送すべき対象（端末、人、ソフトウエアなど）を動的に決定し、特定された対象者に対して、データの配送および通知を行うことが可能な自律分散型のメタネットワークである。このＳＩＯＮを用いることにより、ブローカを介することなく、情報提供者が提供するに相応しいユーザに対してのみ、自身の情報を直接提案することが可能になる。このような、ブローカ非介在型（非ブローカモデル）でpeer-to-peerの情報提案が可能なビジネスモデルを、ここでは、御用聞きモデル（または、御用聞き型情報提案モデル、非ブローカモデル）と呼ぶ。同様に、検索サービス（ブローカ）を介することなく、ユーザが希望する情報を直接探索可能な、リアルタイム情報検索も可能である。なお、御用聞き型情報提案サービスとして、以下のサービス等に適用することが可能である。
（１）製造会社：自社製品に興味を持ってくれそうなお客様を中心に製品案内を送りたい。
（２）広告主：お客様ごとにパーソナライズされた広告を送りたい。
（３）物々交換：ユーザ間の合意に基づいて、製品を売買したり、交換したい。
【００２３】なお、イベントのデータ部にどのような情報を設定するかは、サービス依存である。例えば情報の実体、情報へのリファレンス（ＵＲＬ、分散オブジェクト識別子等）、プロキシ（Ｊｉｎｉプロキシ等）、モバイルエージェントなど様々な利用形態が可能である。
【００２４】次に、ＳＩＯＮの詳細について説明する。
【００２５】＜ＳＩＯＮアーキテクチャ＞まず、ＳＩＯＮのネットワークアーキテクチャについて説明する。図３R>３にＳＩＯＮのネットワークモデルを示す。ここで、説明の便宜上、端末２を、イベント送信者の送信端末２１とイベント受信者の受信端末２２とに区別して表記する。イベント受信者は、受信端末２２を用いて自身が受信することを希望するイベントの意味情報（受信するイベントのタイプと取得条件）をメタデータとしてＳＩＯＮ１に登録する。これをフィルタ（Filter）と呼ぶ。一方、イベント送信者は、送信端末２１を用いてＳＩＯＮ１にイベントを送出することにより、ＳＩＯＮに刺激（Incentive）を与える。このイベントは、図２に示すようにイベントの特性を記述した意味情報とデータから構成される。意味情報の定義を図４に示す。意味情報は、イベントのメタデータであり、かつ、意味情報タイプ（イベントタイプ）のインスタンスである。
【００２６】ＳＩＯＮ１は、イベント受信者が登録したフィルタに対して、イベント送信者が送出したイベントを照合（フィルターリング）させるための自律分散型の照合ネットワークである。照合の結果、イベントが通過した（イベントに反応した）フィルタは発火（Ignition）し、対応するイベント受信者の受信端末２２が自律起動する。この仕組みにより、不特定多数の端末２の中から、対象となる端末２をスケーラブルかつリアルタイムに探索・発見することが可能になる。
【００２７】次に、イベントタイプについて説明する。図５に、イベントのテンプレートであるイベントタイプの定義例を示す。図５に示すように、イベントタイプは、イベントタイプ名（Event type name）と条件名（図５においては、”Service”や”CPU power”が相当する）、およびそれぞれの条件名に対するデータ型（StringやLongが相当する）と条件式（＝＝や＞＝が相当する）が定義されたものである。イベントタイプ名は、イベントタイプを一意に識別するための名称である。
【００２８】なお、イベントタイプの親タイプを継承可能である。
【００２９】図６に示すように、イベントタイプのデータ構造に従って、イベントを作成する。イベントは、イベントタイプ名、条件名と条件値の組み合せ、および、データ部から構成される。イベントの中で定義された条件名、条件式、条件値が、イベントタイプと一致しない場合は、エラーになる。但し、イベントの中で使用される条件名は、イベントタイプのサブセットでも良い。
【００３０】図７にフィルタの定義例を示す。フィルタは、受け付けるイベントタイプ名（Event type name）、属性名（図７においては、”CPU power”や”Age”が相当する）と属性値（図７においては、２００や２５が相当する）のペアーから成る。受け付けるイベントタイプ名で定義されたイベントタイプに属するイベントのみが、フィルタリングの対象となる。ここには、複数のイベントタイプ名を定義することができ、さらに、ワイルドカード（＊．＊）を指定することにより、全てのイベントを対象とすることも可能である。なお、フィルタで定義された属性名が、受け付けるイベントタイプ名で定義されたイベントタイプの条件名の中に存在しない場合には、エラーとなる。但し、イベントタイプのサブセットでも良い。
【００３１】次に、ＳＩＯＮ１の構成を説明する。図８は、ＳＩＯＮ１の構成を示す図である。図８に示すようにＳＩＯＮ１は、意味情報スイッチ（Semantic Information-Switch、図面ではＳＩ−ＳＷと図示する）、意味情報ルータ（Semantic Information -Router、図面ではＳＩ−Ｒと図示する）、意味情報ゲートウェイ（Semantic Information-Gateway、図面ではＳＩ−ＧＷと図示する）から構成される。
【００３２】意味情報スイッチ（ＳＩ−ＳＷ）は、フィルタとして登録された意味情報と、イベントに付与された意味情報を照合し、その結果、発火したイベント受信者の端末２を起動するスイッチング機構を提供する。意味情報スイッチ（ＳＩ−ＳＷ）と各端末２はスター型で結合される。
【００３３】意味情報ルータ（ＳＩ−Ｒ）は、意味情報スイッチ間のイベント経路選択を行うとともに、端末２から意味情報スイッチに対して送出されたイベントを他の意味情報スイッチに転送する役割を担う。これは、意味情報に基づく動的なイべントルーティングにより達成される。
【００３４】意味情報ゲートウェイ（ＳＩ−ＧＷ）は、イベントプレース（Event place）間でのイベントの転送を行う。ここで、イベントプレースは、共通の意味情報空間を保証する最小単位（オントロジードメイン）である。イベントプレース内では、イベントタイプの名称、概念、語彙、意味、関連などのオントロジー体系の一意性が保証され、共通のオントロジーに基づいて意味情報が記述されることになる。基本的には、イベント送信者の端末２から送出したイベントは、イベントプレース内のみで流通するが、意味情報ゲートウェイ（ＳＩ−ＧＷ）を介することにより、異なるオントロジー体系を有するイベントプレース間でのイベントの相互流通が可能になる。このとき、意味情報ゲートウェイ（ＳＩ−ＧＷ）はイベントのオントロジー変換を行った後、異なるイベントプレースヘイベントを転送する。
【００３５】＜動作メカニズムとインタフェース仕様＞ＳＩＯＮ１の実現方法の一例として、分散オブジェクト技術を用いた実装方法を示す。ここで、ＳＩ−ＳＷ，ＳＩ−Ｒ，ＳＩ−ＧＷは、それぞれ、イベントプレースオブジェクト（ＥＰＯ）、シェアードリンクオブジェクト（ＳＬＯ）、フェデレーションエージェント（ＦＡ）と呼ばれる分散オブジェクトとして実装される。図９を用いて、ＳＩＯＮ１の動作メカニズムと制御インタフェースを詳述する。また、ＳＩＯＮ−ＭＴ（Ｍａｎａｇｅｍｅｎｔ Ｔｏｏｌ）やＳＩＯＮインタフェーサを用いることにより、ＳＩＯＮ１のネットワークインタフェースを使用することができる。また、ＭＴを用いて、ＥＰＯの撤収・増減設、物理リンク情報の動的変更、ＰＯマイグレーション（ＰＯのバインド先ＥＰＯの動的変更）、発火率の収集、人気の高い惰報や流行している情報の統計情報収集などを簡単に行うことができる。
【００３６】・イべントプレースファクトリの起動＆初期化（図９（１））
まず、ＳＩＯＮ運営者は、任意のホスト上にイベントプレースファクトリ（ＥＰＦ）を起動し、続いて、ＥＰＦの初期化を行う。この時、ＥＰＦに対して、イべントプレース（ＥＰ）を生成可能なホスト名、およびＥＰの実行ファイルの格納先を与える。これらを、ＥＰ生成情報と呼ぶ。
【００３７】・イべントプレースの生成要求（図９（２））
次に、ＥＰ運営者は、ＥＰＦに対して、ＥＰの生成を要求する。このとき、ＥＰ名、およびＥＰ属性を与える。ここで、ＥＰ属性とは、生成されたＥＰが、御用聞きモデルもしくは問い合せモデルのどちらの目的で使用されるかを表したものであり、イべントの流れの方向性を表すものである。
【００３８】・イべントプレースの生成（図９（３））
次に、ＥＰ生成要求を受け取ったＥＰＦは、ＥＰを生成する。具体的には、このとき、ＥＰの管理を司るイべントプレースマネージメントオブジェクト（ＥＰＭＯ）が生成される。すなわち、ＥＰへの処理要求は、ＥＰＭＯへの処理要求と同義である。ＥＰＦは、生成要求元に生成したＥＰ（すなわち、ＥＰＭＯ）の識別子を返却する。なお、ＥＰＭＯは、図９の（１）において指定された、ＥＰを生成可能なホストの中から、動的に決定されたホストに対して生成される。ＥＰＭＯの起動先ホストの決定方法として、サイクリックに起動先を決定する、トラヒックに応じて決定する、起動先ホストを明示的に指定する、等の方法を選択できる。
【００３９】・イべントプレースの初期化要求（図９（４））
次に、ＥＰ運営者は、ＥＰの初期化をＥＰＭＯに依頼する。このとき、シングルイべントプレースオブジェクトもしくは、マルチプルイべントプレースオブジェクトの指定を行う。マルチプルイべントプレースオブジェクトを指定した場合には、イべントプレースオブジェクト（ＥＰＯ）の物理リンク情報（トポロジ）も併せて与える必要がある。ここで、ＥＰＯの物理リンク情報は、任意のＥＰＯが他のどのＥＰＯの存在を知っているかを表現したものである。
【００４０】例えば、図１０に示すように、ＥＰＯ２・３２は、ＥＰＯ１・３１、ＥＰＯ３・３３、ＥＰＯ４・３４の存在を知っているが、ＥＰＯ３・３３はＥＰＯ２・３２の存在しか知らないことを表現している。このように、マルチプルＥＰＯは、ＥＰ内でのイべント照合処理の負荷分散によるスケラビリティ向上を目的としたものである。
【００４１】ＥＰＭＯは、図９の（１）において指定された、ＥＰを生成可能なホストリストの中から、ＥＰＯを生成するホストを動的に決定し、そこにＥＰＯを生成する。このとき、各ＥＰＯには、それぞれ一つのフィルタファクトリ（ＦＦ）と統計情報収集オブジェクト（ＳＯ）が常に付随して生成され、これらが、ＳＩ−ＳＷに相当する。さらに、物理リンク数に応じて、シェアードリンクオブジェクト（ＳＬＯ）が各ＥＰＯに付随して生成される。例えば、ＥＰＯ２・３２に対しては３個のＳＬＯが生成され（図中のＳＬＯ2,1、ＳＬＯ2,3、ＳＬＯ2,4に対応する）、これらが、ＳＩ−Ｒに相当する。ＥＰＯの起動先の決定方法は、ＥＰＭＯのそれと同様であるが、イべントタイプ毎に使用するＥＰＯを固定化することも可能である。なお、ＥＰＭＯは、ＥＰ内にイべントタイプファクトリ（ＥＴＦ）を生成する。ＥＰ内では一元的なイベントタイプの名前空間がＥＴＦにより保証される。
【００４２】・イべントプレースに対するイべント送信のためのセッション確立要求（図９（５））
次に、ＥＰにセッションの確立を要求する。ＥＰＭＯは、セッション要求毎にプロキシオブジェクト（ＰＯ）を生成する。要求元へは、ＰＯの識別子であるセッション識別子を返却する。
【００４３】なお、ＥＰＭＯは、ＰＯの生成時に、ＰＯに対して、どのＥＰＯを使用する（どのＥＰＯとバインドする）かを指示する。この指示は、マルチプルＥＰＯにおいて必要となるが、バインドするＥＰＯの決定方法は、ＥＰＭＯのそれと同様である。ＥＰへのセッション確立要求時に、イべント送信のためのセッションであるか、イべント受信のためのセッションであるかを指定する必要がある。本例においては、イべント送信のためのセッションを指定する。
【００４４】・イべントタイプの登録（図９（６））
次に、ＰＯに対して、イべントタイプの登録を要求する。このとき、ＰＯは、ＥＴＦにイべントタイプオブジェクト（ＥＴＯ）の生成を要求する。さらに生成されたＥＴＯにイべントタイプを格納する。一方、ＥＰに、イべントタイプ登録を要求することができる。このとき、ＥＰＭＯは、ＥＴＦにＥＴＯの生成を要求し、生成されたＥＴＯにイべントタイプを格納する。一般的に、イべント送信者がイべントタイプを登録する場合は、ＰＯ経由で行う。一方、ＥＰ運営者は、ＥＰに、イべントタイプ登録を行う。なお、同じ名前のイベントタイプを登録するとエラーになる。
【００４５】・イべントプレースに対するイべント受信のためのセッション確立要求（図９（７））
次に、ＥＰに対してイベント受信のためのセッションの確立を要求する。このとき、セッション確立の要求者（イべント受信オブジェクト）は、イべントの通知先であるイべント受信オブジェクトの識別子、および、イべントの通知方法（発火型、ルックイン型）をパラメータとして与える。
【００４６】続いて、ＥＰＭＯは、セッション要求毎にＰＯを生成する。要求元へは、セッション識別子を返却する。なお、ＥＰＭＯは、ＰＯの生成時に、ＰＯに対して、使用するＥＰＯを指示する。この指示は、マルチプルＥＰＯにおいて必要となるが、バインドするＥＰＯの決定方法は、ＥＰＭＯのそれと同様である。
【００４７】・フィルタオブジェクトの生成要求（図９（８））
次に、ＰＯに対して、フィルタオブジェクト（ＦＯ）の生成を依頼する。このとき、ＰＯは、ＦＦにＦＯの生成を要求する。このとき、ＰＯとバインドされたＥＰＯに付随したＦＦが使用される。なお、ＦＯの生成要求元には、生成されたＦＯの識別子がＰＯ経由で返却される。
【００４８】・フィルタ値の設定（図９（９））
次に、ＦＯ識別子をパラメータとして、ＦＯへのフィルタ値の設定を、ＰＯへ依頼する。なお、フィルタオブジェクトの中に格納されているイべントタイプ名（すなわち、フィルターリングの対象とするイべントタイプ名）をキーに、ＦＯのデータ構造（フィルタ値）が正しいかどうかのチェックをＥＴＯに依頼することが選択的に可能である。正しくない場合は、エラーとなる。但し、ワイルドカードが指定された場合には、このチェック処理を一切行わない。
【００４９】・フィルタ登録（図９（１０））
次に、ＦＯにフィルタ値を設定した後、Ｆのフィルタ識別子をパラメータとして、ＰＯに対しフィルタの登録を依頼する。このとき、登録要求元にフィルタ識別子が返却される。これを契機に、イべントの受信が可能になる。なお、一つのＰＯを介して、複数のフィルタ登録が可能であるが（これには、一つのＰＯを介して異なる複数のＦＯをフィルタとして登録する、もしくは、同一のＦＯを複数回、フィルタとして登録する場合が考えられるが）、一つのＰＯに対して登録されたすべてのフィルタは、“ＯＲの関係”を持つ。
【００５０】・イべント送信（図９（Ａ））
次に、イベント送信者は、ＰＯに対して、イべントを送信する。このとき、ＰＯは、イべントの中に格納されているイべントタイプ名をキーに、イべントのデータ構造が正しいかどうかのチェックをＥＴＯに依頼することが選択的に可能である。このチェック処理を選択したとき、正しい場合は、次の処理（図９（Ｂ））へ、正しくない場合は、エラーとなる。
【００５１】・イベントの照合依頼（図９（Ｂ））
次に、ＰＯはイベントをＥＰＯに転送する。このとき、ＥＰＯがスレッドを生成する。なお、スレッドはイベント毎に生成され、各スレッドはイベントの多重処理を行う。
【００５２】・フィルタとの照合（図９（Ｃ））
次に、スレッド（ＥＰＯ）は、イベントとフィルタを照合することにより、フィルターリング処理を行う。これには、完全一致、部分一致、重みづけ一致などがあり、フィルタ値の設定時に指定することができる。
【００５３】・プロキシオブジェクトの起動（図９（Ｄ））
次に、フィルタとの照合の結果、イベントがフィルタを通過すると、対応するＰＯが起動されこのイベントを受け取る。このとき、ＰＯは、受信したイベントのタイプ、値、イベントＩＤ等をＳＯに登録することが選択的に可能である。これらの情報から、ＳＯはイベントの発火率（イベントタイプ毎、イベント毎）や、ＥＰ内で流行している評判の高いイベントを測定することが可能になる。
【００５４】・イベント受信オブジェクトの起動（図９（Ｅ））
次に、ＰＯは、イベント受信オブジェクトを起動するとともに、イベント受信オブジェクトに対してこのイベントを渡す。これが、発火型（割り込み型）のイベント通知に対応する。
【００５５】・ルックイン型のイベント通知（図９（Ｆ））
一方、ＰＯがイベント受信オブジェクトを起動するのではなく、イベント受信オブジェクト自身が、イベント受信オブジェクトに対応するＰＯにスプールされているイベントを、取り出すことも可能である。これがルックイン型のイベント通知に対応する。イベント受信オブジェクトの起動契機は、サービス形態に依存して種々存在するが、典型的な例として、エンドユーザがイベント受信オブジェクトにコンテンツの提案要求を行った場合が考えられる。
【００５６】＜フィルタの管理方法＞次に、各ＥＰＯにおけるフィルタの管理方法を説明する。
【００５７】まず、イベント受信のためのセッションを確立する。このとき、セッション要求毎に一つのＰＯが生成され、このＰＯは任意の一つのＥＰＯにバインドされる。このＥＰＯには、それぞれ、一つのＦＦが付随している。これにより、ＰＯが使用するＥＰＯが一意に決定され、以降の処理はすべて、ＰＯ（イベント受信用セッション）を介して行われる。
【００５８】次に、ＦＯを生成し、ＦＯに対してフィルタ値（受信するイベントのタイプとその取得条件）を設定する。続いて、ＦＯ識別子をパラメータとして、フィルタの登録を行う。このとき、各フィルタには、ＦＯ識別子が格納される。各ＥＰＯは、ＰＯを介して登録されたフィルタを以下に示す規則に基づいて管理する。
【００５９】まず、フィルタに格納されているＦＯ識別子を用いて、ＦＯに設定されている“受信するイベントのタイプ”を参照する。続いて、受信するイベントのタイプ毎にフィルタを分類し、イベントタイプ毎に分類されたフィルタを、さらにＰＯ毎に細分類し、管理する。
【００６０】この管理規則について図１１を参照して、ＰＯ１を介して、フィルタを登録する場合について説明する。ここでは、フィルタ登録時に指定するＦＯの中に、受信するイベントのタイプとして、“イベントタイプＸ”が設定されているものとする。このとき、ＥＰＯに登録されるフィルタは、図１１のフィルタ１が相当し、同様に、ＰＯ２を介して登録されたフィルタにはフィルタ２が相当する。また、各ＰＯにおいて、複数のフィルタを登録することが可能であるが、登録されたフィルタは“ＯＲ関係”を有するものとする。
【００６１】まず、イベントタイプＸのイベントがＥＰＯに到着したとき、フィルタ１との照合が行われる。その結果、フィルタ１が発火するとＰＯ１が起動される。次に、フィルタ２との照合が行われ、その結果、フィルタ２が発火するとＰＯ２が起動される。このとき、フィルタ２とフィルタ３は“ＯＲ関係”を有するため、フィルタ３との照合は行われない。このようなフィルタ管理方法を用いることにより、一つのイベントに対する各ＥＰＯでの照合処理回数を、基本的にＰＯ数（受信用セッション数）以下にすることができる。
【００６２】＜イベントルーティング方法＞次に、イベントルーティング方法について説明する。
【００６３】ＥＰＯ（ＳＩ−ＳＷ）は、イベントの送受信者（端末などのエンティティ）をセッションを介してスター型で収容する。さらに、ＥＰＯ（ＳＩ−ＳＷ）は、イベント受信者（イベント受信オブジェクト）が登録したフィルタと、イベント送信者が送出したイベントを照合し、その結果、発火したフィルタに対応するイベント受信者のみにイベントを通知する（合致するイベント受信者にのみイベントを配送する）照合スイッチである。
【００６４】そのため、イベントの送信者数（イベント数）やイベントの受信者数（フィルタ数）が増加すると、それに比例してＥＰＯの処理能力が飽和する。そこで、ＳＩＯＮアーキテクチャでは、スケラビリティの高いＥＰを実現する手段として、マルチプルＥＰＯを提供する。マルチプルＥＰＯとは、ＥＰＯ数に比して、ＥＰのトータル処理能力をスケーラブルに向上させることを目的とし、具体的には、以下の２つの観点からＥＰの高いスケラビリティを達成する。
【００６５】第一点は、負荷分散と自律分散である。これは、複数のＥＰＯに、イベントの送受信者を分散させることにより、イベントのフィルターリング処理の負荷分散を行い、処理の集中に伴うボトルネック要因を作らないようにするものである。。さらに、各ＥＰＯが他のＥＰＯの影響を受けることなく、自律的に動作可能な機構による分散協調を達成する。
【００６６】第二点は、ネットワークトラヒックの削減とフィルターリング処理の最適化である。これは、ＥＰＯ間で不要なイベントを転送しないことによる通信量の最小化と、それに伴う無駄なフィルタリング処理の削減を行うものである。
【００６７】図１０において、ＥＰＯ３・３３に対し、受信するイベントのタイプとして、イベントタイプＸのフィルタが登録される場合を考える。ここで、イベントタイプＸのイベントがＥＰＯ４に対して送出されたとき、ＥＰＯ２経由でこのイベントをＥＰＯ３に転送する必要がある。このとき、イベントタイプＸのフィルタが登録されていないＥＰＯ１に対して、当該イベントが転送されてはならない。このようなＥＰＯ間のイベントのルーティング制御を行うものが、シェアードリンクオブジェクト（ＳＬＯ）であり、前述したＳＩ−Ｒに相当する。
【００６８】以下にＳＩ−Ｒについて詳細を説明する。
【００６９】まず、ＥＰの初期化時に、物理リンク情報（ＥＰＯのトポロジ）に基づいて、ＳＬＯが各ＥＰＯに付随して生成される。例えば、図９において、ＥＰＯ２に対して３個のＳＬＯが生成される。これらは、図中のＳＬＯ2,1、ＳＬＯ2,3、ＳＬＯ2,4に対応する。このＳＬＯi,jは、ＥＰＯjからＥＰＯjへのイベント転送を行うシェアードリンク（ＳＬi,j）を確立する。すなわち、図９および図１２に示すように、ＳＬＯi,jは、ＥＰＯjに対してイベント受信のセッションを確立し、一方、ＥＰＯiに対してイベント送信のセッションを確立することにより、イベント転送のための論理リンクであるシェアードリンクＳＬi,jを確立する（シェアードリンクとは、ＥＰの初期化時における、ＳＬＯによるセッションの確立を意味し、フィルタ登録処理を含まない）。
【００７０】ＥＰの初期化後に、イベント受信者は、ＥＰへのセッションを確立し、セッションを介してフィルタを登録することが可能になる。このとき、確立済みのシェアードリンクに従って、イベントパスが設定される。例えば、図１２において、イベント受信者（Event Receiver）３がＰＯ３を介して、“イベントタイプＸのイベント受信を行うフィルタを、ＥＰＯ３へ登録した場合において、ＰＯ３は、ＥＰＯ３ヘイベントタイプＸのフィルタを登録するとともに、その旨をＳＬＯ3,j（ここでは、ＳＬＯ3,2）に通知する。ＳＬＯ3,2はＳＬ3,2を用いて、ＥＰＯ２に対してイベントタイプＸのフィルタを登録する。これは、前述したように、ＳＬＯ3,2に対して割り当てられた受信用セッションのＰＯを介して行われる。同様に、このＰＯは、その旨を、ＳＬＯ2,3を除くその他のＳＬＯ2,jに対して通知する。ＳＬＯ2,j（ｊ≠３）は、ＳＬ2,jを用いて、ＥＰＯヘフィルタを登録する。順次同様に、すべてのＥＰＯにイベントＸに対するパスが設定されるまで、繰り返される。
【００７１】このように、イベントタイプＸに対して確立された一連のパスを、イベントパスと呼ぶ。これは、ＰＯ３を介したフィルタ登録がトリガとなって、すべてのＥＰＯへ、イベントタイプ毎のイベントパス設定要求が順次、自律的に波及していくものである。すなわち、個々のＥＰＯは隣接するＥＰＯのみを認識すれば良い。そのため、イベントパスの集中管理やブロードキャストによるイベントパスの設定・管理方法に比べて、簡単かつ一元的な自律ロジックでイベントパスを確立することが可能になる。
【００７２】この時点でのＥＰＯ１におけるフィルタの登録状況を図１３に示す。イベント受信者３がＰＯ３を介してフィルタを登録した結果、フィルタ１がＥＰＯ１に登録されることになる。イベントパスの設定とは、シェアードリンク情報に基づいて、一連のＥＰＯにイベント転送のためのフィルタを登録することを指す。また、ＳＬＯが登録するフィルタには、受信するイベントタイプ名が設定されるのみであり、取得条件は設定されず、イベントタイプ名のみのフィルターリングを行う。
【００７３】この状況において、イベント受信者２がＰＯ２を介して、イベントタイプＸのフィルタを、ＥＰＯ２へ登録したとき、前述と同様に新たなイベントパスの設定がすべてのＥＰＯへ波及し、その結果として、フィルタ２がＥＰＯ１へ登録されることになり、イベントパス設定の要求毎にフィルタが登録されることになる。
【００７４】このとき、ＥＰＯ１にイベントタイプＸのイベントが送出されると、フィルタ１が発火し、ＳＬＯ2,1が起動される。ＳＬＯ2,1が、このイベントをＥＰＯ２へ送出することにより、ＳＬＯ3,2が起動される。さらに、ＳＬＯ3,2を介して、当該イベントがＥＰＯ３へも転送されることになる。また、ＳＬ2,3とＳＬ3,2間でのイベントの無限転送を防止するために、イベントは、制御情報の一つとして、通過したＥＰＯの識別子を、最新順に最大２つ保持する。
【００７５】なお、前述したように、フィルタ１とフィルタ２は、ＯＲ関係を有するため、フィルタ１が発火した場合にはフィルタ２との照合は行われない。そのため、フィルタ１が存在するにも関わらず、新たにフィルタ２を登録したことに伴う、フィルターリング処理の冗長オーバヘッドを全く生じないようにすることができる。これは、イベントパスを設定したときに、既設のイベントパスを含めた全イベントパスの再構築を全く必要としないことを意味し、簡単かつ一元的なイベントパスの自律的な設定が可能になる。
【００７６】また、ＥＰＯ１内に、イベント受信者が確立したセッションおよびそれを介したフィルタ登録がある場合には（ＰＯｎのフィルタ３に対応）、ＳＬＯ対応のフィルタリング処理がすべて完了した後に、ＰＯｎ対応のフィルターリング処理が行われる。すなわち、他のＥＰＯへのイベント転送処理を優先して行い、その後、自ＥＰＯでの照合処理が開始される。
【００７７】以上説明した、イベントルーチング方法の更なる効果として、フィルタ登録解除時に、イベントパスの再構築が必要ない点が挙げられる。例えば、イベント受信者３がＰＯ３を介して、登録したフィルタの登録解除を行った場合、登録の場合と同様に、解除要求が順次、自律的に波及する。その結果、ＥＰＯ１において、フィルタ１の登録のみが解除されることになるが、フィルタ２は存命する（これ以降は、フィルタ２がフィルタ１の代わりにイベントを転送する）ため、イベントパスの再構築なしに、すべての既設イベントパスの一貫性が保証される。
【００７８】このような自律分散型のルーティング制御方法を用いることによって、ＥＰＯの相互接続と分散協調を容易に実現することが可能になる。これに伴い、小規模なネットワークから大規模なネットワークヘの移行、ローカルなネットワークからグローバルなネットワークヘの移行等をスムーズに行うことができる。また、ボトムアップアプローチによるグローバルネットワーク化を、共通のロジックで容易に達成することができる。
【００７９】図１４ないし図１７はリング型結合を持つ物理リンクにおけるＳＩ−Ｒについて説明するために図である。
【００８０】例えば、図１５に示すように、リング型結合を持つ物理リンクにおいて、ＥＰＯ２は、ＥＰＯ１、ＥＰＯ３の存在を知っていることを表現している。このように、マルチプルＥＰＯは、ＥＰ内でのイべント照合処理の負荷分散によるスケラビリティ向上を目的としたものである。
【００８１】ＥＰＭＯは、図１４の（１）において指定された、ＥＰを生成可能なホストリストの中から、ＥＰＯを生成するホストを動的に決定し、そこにＥＰＯを生成する。このとき、各ＥＰＯには、それぞれ一つのフィルタファクトリ（ＦＦ）と統計情報収集オブジェクト（ＳＯ）が常に付随して生成され、これらが、ＳＩ−ＳＷに相当する。さらに、物理リンクに応じて、シェアードリンクオブジェクト（ＳＬＯ）が各ＥＰＯに付随して一つ生成される。たとえば、ＥＰＯ２に対しては、図中のＳＬＯ２，３が生成される。これが、ＳＩ−Ｒに相当する。ＥＰＯの起動先の決定方法は、ＥＰＭＯのそれと同様であるが、イベントタイプ毎に使用するＥＰＯを固定化することも可能である。なお、ＥＰＭＯは、ＥＰ内にイベントタイプファクトリ（ＥＴＦ）を生成する。ＥＰ内では一元的なイベントタイプの名前空間がＥＴＦにより保証される。
【００８２】以下にＳＩ−Ｒについて詳細を説明する。
【００８３】まず、ＥＰの初期化時に、物理リンク情報（ＥＰＯのトポロジ）に基づいて、ＳＬＯが各ＥＰＯに付随して生成される。たとえば、図１４において、ＥＰＯ２に対してＳＬＯ2,3が生成される。このＳＬＯi,jは、ＥＰＯjからＥＰＯiへのイベント転送を行うシェアードリンク（ＳＬi,j）を確立する。すなわち、図１４および図１６に示すように、ＳＬＯi,jは、ＥＰＯjに対してイベント受信のセッションを確立し、一方、ＥＰＯiに対してイベント送信のセッションを確立することにより、イベント転送のための論理リンクであるシェアードリンクＳＬi,jを確立する（シェアードリンクとは、ＥＰの初期化時における、ＳＬＯによるセッションの確立を意味し、フィルタ登録処理を含まない）。これによって、片方向のリング状のシェアードリンクＳＬi,jが確立される。
【００８４】ＥＰの初期化後に、イベント受信者は、ＥＰへのセッションを確立し、セッションを介してフィルタを登録することが可能になる。このとき、確立済みのシェアードリンクに従って、イベントパスが設定される。例えば、図１６において、イベント受信者（Event Receiver）３がＰＯ３を介して、イベントタイプＸのイベント受信を行うフィルタを、ＥＰＯ３へ登録した場合を考える。このとき、ＰＯ３は、ＥＰＯ３ヘイベントタイプＸのフィルタを登録するとともに、その旨をＳＬＯ3,1に通知する。このとき、ＳＬＯ3,1には、フィルタ登録の要求発生元がＥＰＯ３である旨がパラメータとして与えられる。ＳＬＯ3,1はＳＬ3,1を用いて、ＥＰＯ１に対してイベントタイプＸのフィルタを登録する。これは、前述したように、ＳＬＯ3,1に対して割り当てられた受信用セッションのＰＯを介して行われる。同様に、このＰＯは、その旨を、ＳＬＯ1,2に対して通知する。ＳＬＯ1,2は、ＳＬ1,2を用いて、ＥＰＯ２ヘフィルタを登録する。順次同様に、すべてのＥＰＯにイベントＸに対するパスが設定されるまで、繰り返される。なお、この処理は、フィルタ登録の要求発生元（ここでは、ＥＰＯ３）の直前まで繰り返される。すなわち、ＳＬＯ2,3は、ＥＰＯ３にフィルタを登録しない。
【００８５】この時点でのＥＰＯ１におけるフィルタの登録状況を図１７に示す。イベント受信者３がＰＯ３を介してフィルタを登録した結果、フィルタ１がＥＰＯ１に登録されることになる。イベントパスの設定とは、シェアードリンク情報に基づいて、一連のＥＰＯにイベント転送のためのフィルタを登録することを指す。なお、ＳＬＯが登録するフィルタには、受信するイベントタイプ名が設定されるのみであり、取得条件は設定されず、イベントタイプ名のみのフィルターリングを行う。
【００８６】この状況において、イベント受信者２がＰＯ２を介して、イベントタイプＸのフィルタを、ＥＰＯ２へ登録したとき、前述と同様に新たなイベントパスの設定がすべてのＥＰＯへ波及し、その結果として、フィルタ２がＥＰＯ１へ登録されることになり、イベントパス設定の要求毎にフィルタが登録されることになる。
【００８７】このとき、ＥＰＯ１にイベントタイプＸのイベントが送出されると、フィルタ１が発火し、ＳＬＯ3,1が起動される。ＳＬＯ3,1が、当該イベントをＥＰＯ３へ送出することにより、ＳＬＯ2,3が起動される。さらに、ＳＬＯ2,3を介して、当該イベントがＥＰＯ２へも転送されることになる。なお、イベントの無限巡回を防止するために、イベントは、制御情報の一つとして、イベントが生起したＥＰＯの識別子を保持し、イベントの生起元ＥＰＯ（ＳＬＯ）に当該イベントが巡回して戻って来たときに、当該イベントを破棄する。
【００８８】次に、前述したイベントルーティング方法とは異なるイベントルーティング方法を説明する。このルーティング方法は、シェアードリンク（論理リンク）を確立するまでの手順は、前述した方法と同様である。このイベントルーティング方法が前述した方法と異なるのは、イベントパスを確立しない点であり、ＳＬＯi,jがシェアードリンクＳＬi,jを確立する時に同時に、唯一のフィルタを登録するようにするものである。このとき、登録されるフィルタには、受信するイベントのタイプとしてワイルドカードを指定する。これによって、すべてのイベントを転送の対象とし、イベントタイプ毎のイベントパスを確立しないようにする。
【００８９】このように意味情報にワイルドカードを指定することによって、リング状のシェアードリンクＳＬi,j内をイベントが巡回するため、全てのＥＰＯに対してイベントを配送することが可能となる。
【００９０】＜フェデレーション方法＞次に、図１８を参照してフェデレーション方法について説明する。フェデレーションエージェント（ＦＡ）とは、イベントプレース間のフェデレーションを確立するエージェントであり、前述したＳＩ−ＧＷに相当する。例えば、イベントプレース（Event Place）Ａがイベントプレース（Event Place）Ｂに対してフェデレーションを確立する場合を考える。まず、イベントプレースＡに属するＦＡが、イベントプレースＢに対して、フィルタを登録する。このとき、イベントプレースＢに属するイベント送信者がイベントを送出し、その結果、このフィルタが発火すると、ＦＡが自律起動する。これは、ＦＡをイベントプレースＢに属する一つのイベント受信者として見なすことができる。次に、ＦＡは取得したイベントを、自身が属するイベントプレースＡに対して再送出する。これは、ＦＡを、イベントプレースＡに属する一つのイベント送信者として見なすことができる。
【００９１】このように両者の役割を併せ持つＦＡを用いて、イベントプレース間のフェデレーションを容易に実現できる。すなわち、単一イべントプレースと同じ制御論理で、イベントプレース間のフェデレーションを実現することが可能である。この機構を用いて、ＳＩＯＮ１の基本構成単位であるイベントプレースを相互接続することにより、グローバルな照合ネットワークをボトムアップアプローチで構築することが可能となり、イベントプレース間に跨るイベントの共有を実現することができる。なお、イベントプレースＡとイベントプレースＢがそれぞれ異なるオントロジーを持つ場合、イベントプレースＡに属するＦＡは、イベントプレースＢから取得したイベントを、イベントプレースＡのオントロジーに変換した後、イベントプレースＡに送出する。
【００９２】異なるオントロジー体系に跨ってイベント転送を行う場合には、オントロジー変換が必要になる。この変換を行う従来技術として、標準オントロジーを規定し、他のイベントプレースにイベントを転送する場合には、一旦、標準オントロジーに準拠した形式に変換した後に、イベントの転送を行う方法や、イベントプレースの組み合わせの数だけオントロジー変換テーブルを事前に用意しておくなどの方法がある。
【００９３】しかしながら、イベントプレースの動的なフェデレーション（フェデレーションの動的な開始、開始解除）に対応するためには、従来の方法は柔軟性に欠ける。そこで、本発明では、図１８に示すように、ＦＡが隣接するイベントプレースのオントロジー情報との差分（変換情報）のみを、オントロジー変換テーブルに保持するようにしている。すなわち、これは、各ＦＡが変換情報をそれぞれ分散して保有し、全体でオントロジー体系の一貫性を保証する方法である。これは、イベントプレース間の動的なフェデレーションに容易に対応することが可能になるが、その反面、イベントがイベントプレースを跨る毎に、オントロジー変換処理が発生するため、従来方法に比べて、変換処理オーバヘッドが増大するという特徴を有している。
【００９４】＜コミュニティと進化型ネットワーク＞次に、ＳＩＯＮ１のキラーサービスの一つであるコミュニティサービスについて説明する。コミュニティサービスにおけるエンティティは、自身のポリシに基づいて、学習・進化・退化・消滅等を繰り返すことにより、その活動様式を動的に決定することが可能な自律分散型の動作主体である。コミュニティは、このようなエンティティに対して効率的なコミュニケーションの場を提供するものである。すなわち、コミュニティ内のエンティティは、自身とコミュニケートすべきエンティティや、自身の振る舞いに影響を与えるエンティティを動的に探索・発見・特定し、特定されたエンティティとインタラクションを行うことが可能である。
【００９５】このコミュニティは、特に以下の特徴を持つエンティティを取り扱うことができる。
【００９６】（１）極小粒度で、膨大な数のエンティティがコミュニティに存在する（不特定多数のエンティティ）。
【００９７】（２）エンティティの属性がリアルタイムに変化する。典型的なエンティティの属性として、位置情報、時刻等がある。
【００９８】（３）コミュニティ内のエンティティの振る舞いに規則性がなく、行動予測が困難である。
【００９９】（４）コミュニティヘの参加、コミュニティからの退去、消滅、複製等が頻繁かつ不規則に発生する。
【０１００】（５）コミュニティ内のエンティティは、ポリシ、属性、シナリオ等に基づいて相互にリアルタイムに出会う必要がある。
【０１０１】このような特性を持つエンティティをサーバやメディエータ（ブローカ）で管理し、相互にリアルタイムに探索・発見することは性能上、容易でない。ＳＩＯＮ１のＥＰは、このような特徴を持つコミュニティの実行環境として位置づけられる。すなわち、コミュニティはＥＰのメタ実行環境であり、ＥＰを直接用いることに比して、抽象度の高いコミュニケーションの場を提供するものである。コミュニティの実行環境にＥＰを用いることにより、コミュニティ内のすべてのエンティティは、ブローカを介することなく、コミュニケーションすべきエンティティを直接発見することができる。これは、コミュニティ内のエンティティのコミュニケーションは、ＥＰ内のイベントの送受信として実装されるためである。
【０１０２】図１９にコミュニティの概念モデルを示す。ユーザエージェント（ＵＡ）、情報・サービス提供エージェント（ＩＳＡ）がコミュニティ内のエンティティに相当する。ＵＡはユーザの代理人として自律的に振る舞うエージェントであり、ユーザの嗜好、動作環境、位置情報、状況、傾向などに応じて、自身の振る舞いを動的に決定し、インタラクションすべきＩＳＡや他のＵＡを探索し、それらとインタラクションする。ＩＳＡは情報提供者やサービス提供者の代理人として自律的に振る舞うエージェントであり、提供者の意図に基づいて、インタラクションすべきＵＡや他のＩＳＡを探索する。すなわち、自身の情報を提供するのに相応しいユーザを探索して特定する。
【０１０３】一方、コミュニティエージェント（ＣｏｍＡ）は、コミュニティの運営を司るエージェントである。ＥＰ運営者は、運営ポリシに基づいて、ＳＩＯＮ−ＭＴを介したＳＩＯＮの制御・運営を行う。従って、ＣｏｍＡは、ＥＰ運営者をエージェント化したものと見なすことができる。基本的に、コミュニティの運営ポリシはＣｏｍＡによって規定される。例えば、ＵＡ、ＩＳＡなどのエンティティに対するコミュニティヘの参加、退去、消滅、複製などの認可、コミュニティ内に流通させる情報の把握と統制（相応しくないイベントの削除など）、コミュニティ内の統計情報（トレンド情報、評判の高い情報など）の管理などを自身の運営ポリシに基づいて司る。
【０１０４】また、コミュニティの高いスケーラビリティやリライアビリティの保証を達成するため、負荷状況や障害状況に応じて、ＥＰおよびＥＰＯの増減設、撤収、マイグレーション等のＳＩＯＮ制御を実行する。すなわち、ＳＩＯＮ１とＣｏｍＡを組み合わせることにより、ＳＩＯＮ１は自律分散型ネットワークから、学習、成長、進化が可能な進化型ネットワークヘと発展する。このように、ＣｏｍＡはコミュニティ内のエンティティの振る舞いを統制するとともに、ＳＩＯＮ１を自己組織化するための役割を担う。さらに、コミュニティ間のコラボレーションにより、コミュニティ間での情報の共有が可能である。例えば、コミュニティＡにおいて流通している情報の中で、人気が高いトップ１０のみを、コミュニティＢに流通させることができる。以下に処理の流れを示す。
【０１０５】まず、コミュニティＢのＣｏｍＡが、イベントプレースＢのＦＡに対して、“コミュニティＡにおいて流通している情報の中で、人気が高いトップ１０のみを、コミュニティＢに流通させる”旨を指示する。
【０１０６】次にＦＡは、イベントプレースＡに対して、トップ１０のイベントタイプを問い合わせる。これを受けて、イベントプレースＡは、配下の統計情報収集オブジェクト（ＳＯ）に問い合わせ、その結果を、ＦＡに返却する。
【０１０７】次に、ＦＡは取得したイベントタイプを基に、オントロジー変換テーブルを作成するとともに、イベントプレースＡに対しフィルタを設定する。以降、ＦＡは、イベントプレースＡから、当該イベントを受信可能になる。
【０１０８】次にＦＡは、イベントプレースＡから取得したイベントを、オントロジー変換テーブルに基づいてオントロジー変換し、それをイベントプレースＢへと送出する。
【０１０９】以上説明したような形態によれば、以下の２点の効果を得ることができる。
【０１１０】第１に、分散オブジェクト環境上にＳＩＯＮのネットワーク環境を容易に構築できる。
【０１１１】第２に、サービスアプリケーションをエンティティとしてコミュニティに参加させることにより、簡単にイベントを送出したり、必要なイベントをピックアップすることが可能になり、相互にコミュニケションを図ることが可能になる。
【０１１２】以上説明したように、ＳＩＯＮでは、以下の効果を得ることができる。
【０１１３】ＦＡを介したイベントプレース間のフェデレーション機構により、他のイベントプレースのみで流通していたイベントを、自イベントプレース内に取り込むことができる。逆に、他のイベントプレースにイベントを送出することにより、自イベントプレース内で流通しているイベントをアドバタイズできる。このように、異なるイベントプレース間で、イベントの共有が可能になるとともに、オントロジーを考慮したイベントプレース間の相互運用により、ボトムアップアプローチによるグローバルな自律分散型の照合ネットワークを構築することが可能になる。
【０１１４】マルチプルＥＰＯの機構により、フィルタリング処理を複数のＥＰＯに負荷分散させることが可能になるとともに、自律的に動作するＥＰＯ間のイベントルーチング機構により、ネットワークトラヒックを最小限に抑えることが可能になる。これにより、結果的にＥＰのトータルスループットをスケーラブルに向上させることが可能となる。
【０１１５】ブローカを介することなく、自身に相応しいエンティティを直接探索・発見することが可能となる。例えば、情報提供者は、ユーザの存在を知ることなく、自身が提供する情報に相応しいユーザを特定することができる。同様に、ユーザは情報提供者の存在を知ることなく、自身の嗜好に相応しい情報提供者を探索・発見することができる。すなわち、ユーザと情報提供者は互いに等価的である。これにより、特定のブローカに頼ることなく、自身のポリシに従って、リアルタイムに情報を発信することが可能になる。また、探索対象となるエンティティの数が膨大な場合やエンティティが探索対象ドメインに頻繁に出入りする場合において、非ブローカモデルに基づく探索技術が特に有効となる。
【０１１６】ＳＩＯＮにおいては、意味情報の終端点がネットワークとなる。一方、端末間でpeer-to-peer接続を行う方法においては、意味情報の終端点が端末になるため、端末の中身を外部に公開することになる。従って、ＳＩＯＮは後者の方法と比べて、高いセキュリティとプライバシ保護を実現することが可能である。
【０１１７】次に、上記のような内容を備える意味情報ネットワークシステムを用いた本発明の実施形態について説明する。
【０１１８】（第１の実施形態）図２０は、本発明の第１の実施形態の移動するサービス提供者探索方法によるサービスを説明するためのシステム図である。本実施形態では、サービス要求者としてタクシーの乗車を希望しているタクシー要求者が、最も迅速にタクシーによる輸送というサービスを提供してくれるサービス提供者を検索する場合を用いて説明する。
【０１１９】本実施形態では、図２０における意味情報ネットワーク１０を、上述したイベントプレースを用いて実現しているが、意味情報ネットワーク１０の実現方法はこの限りではない。
【０１２０】本実施形態の移動するサービス提供者探索システムでは、タクシー要求者の携帯端末４０と、タクシー運転手１〜３の携帯端末３１〜３３が意味情報ネットワーク１０を介して接続されている。
【０１２１】タクシー要求者の携帯端末４０は、タクシー要求をイベントとして意味情報ネットワーク１０に送信する送信端末として機能し、タクシー運転者の携帯端末３１〜３３は、イベントとして送信されたタクシー要求を選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末として機能する。
【０１２２】また、タクシー要求者の携帯端末４０、タクシー運転手の携帯端末３１〜３３ともに、 ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信機等の位置情報取得手段が設けられていて、その携帯端末が現在位置している場所を示す位置情報を取得することができるようになっている。
【０１２３】タクシー要求者が使用する携帯電話等の携帯端末４０およびタクシー運転手が使用する携帯端末３１〜３３に、ＣＯＲＢＡ準拠のＯＲＢ等のミドルウェアと、上述したイベントプレースファクトリ生成機構をインストールして自身の端末においてイベントプレースを生成するか、あるいは、他のネットワークノード上にあるイベントプレースへアクセスしてセッションを確立し、意味情報ネットワーク１０に接続されていることを前提とする。また、意味情報ネットワーク１０には、図２１２１のようなイベントタイプが登録されているとする。
【０１２４】この登録されているイベントタイプは、イベントタイプ名として「タクシー探索」が定義され、イベントプロパティ名として「緯度」、「軽度」、「地名」、「目印」、「目的地」が定義されている。また、これらのイベントプロパティには、イベントプロパティ値として、それぞれ「float型」、「float型」、「float型」、「string型」、「string型」、「string型」が定義されている。
【０１２５】次に、本実施形態の移動するサービス提供者探索方法について図面を参照して詳細に説明する。図２０２０中の括弧内の番号は、伝送される情報について、生起順に付されており、以下、この番号順に本実施形態の動作について説明する。
【０１２６】（１）先ず、タクシーサービスを行おうとするタクシー運転手１〜３が携帯端末３１〜３３のタクシー運転手アプリケーションを起動すると、携帯端末３１〜３３に設けられているＧＰＳ受信機等の位置情報取得手段は、携帯端末３１〜３３の現在の位置を位置情報として取得する。ここでは、位置情報として、タクシーの現在位置を、緯度、経度により取得するものとする。そして、位置情報取得手段は、この位置情報を一定時間間隔で継続的に取得する。
【０１２７】（２）そして、次に、タクシー運転手アプリケーションにより得られた位置情報を、図２２に示すようなフィルタとして意味情報ネットワーク１０に対して設定する。尚、図２０では、設定されるフィルタを概念的に黒丸にて示す。
【０１２８】この場合、タクシー運転手アプリケーションは、得られた緯度、経度に対してある程度幅を持たせてフィルタ値を設定する。例えば、ＧＰＳ受信機により得られた位置情報が、北緯４０．５５度、東経１３５．５５度の場合、４０．２〜４０．９度の範囲の緯度、および１３５．３〜１３５．８度の範囲の経度をフィルタ値として設定する。また、タクシー運転手アプリケーションは、得られた位置情報とデジタル地図を照合し、位置情報を都道府県、市町村等の地名情報に変更してフィルタの「地名」として設定する。図２２では、“北緯４０．５５度、東経１３５．５５度”という位置情報が、“東京都武蔵野市中町＊”という地名情報に変換された場合を例として用いている。
【０１２９】そして、携帯端末３１〜３３のタクシー運転手アプリケーションは、一旦設定したフィルタを、位置情報取得手段により得られた位置情報を用いて予め設定された一定期間毎に更新する。
【０１３０】（３）次に、タクシー要求者が、タクシー要求を意味情報ネットワーク１０に送信しようとして、携帯端末４０のタクシー要求者用アプリケーションを起動すると、携帯端末４０に設けられているＧＰＳ受信機等の位置情報取得手段は携帯端末４０の現在の位置を示す情報を位置情報として取得する。
【０１３１】（４）次に、携帯端末４０のタクシー利用者用アプリケーションは、位置情報取得手段により得られた位置情報とデジタル地図を照合し、この位置情報を都道府県、市町村、番地表現等の地名情報に変更する。
【０１３２】そして、タクシー要求者用アプリケーションは、タクシー要求者に対して、タクシーサービスを利用して行くこと希望する目的地の入力を促す。図２３に、タクシー要求者がタクシー要求を発信しようとする際、携帯端末４０において表示されるタクシー要求者用アプリケーションの画面の一例を示す。ここでは、目的地として“東京都千代田区外神田 ＪＲ秋葉原駅”が入力された場合を示している。
【０１３３】そして、タクシー要求者が目的地を入力すると、携帯端末４０のタクシー要求者用アプリケーションは、「緯度」、「経度」、「地名」、「目的地」を設定したイベントを、タクシーサービスの提供を希望する旨を通知するためのタクシー要求イベントとして意味情報ネットワーク１０に対して送信する。図２４にタクシー要求者用アプリケーションにより送信されるイベントの一例を示す。
【０１３４】（５）次に、設定しているフィルタ条件が、イベント条件と合致したタクシー運転手の携帯端末により、タクシー要求者からのタクシー要求が意味情報ネットワーク１０から受信されることになる。ここでは、タクシー１、２の携帯端末３１、３２のみが設定したフィルタの条件と、イベントの条件とが一致してタクシー要求者からのタクシー要求イベントを意味情報ネットワーク１０から受信したものとする。
【０１３５】図２５に、タクシー運転手の携帯端末がタクシー要求を受信した際に、タクシー運転手用アプリケーションにより表示される画面の一例を示す。タクシー要求イベントを意味情報ネットワーク１０から受信したタクシー運転手の携帯端末には、タクシー要求者の現在の位置情報と、目的地が表示される。
【０１３６】タクシー要求を受信したタクシー運転手は、このタクシー要求に含まれるタクシー要求者の位置情報および目的地の情報に基づいてタクシーサービスを提供するタクシー要求者を決定する。この決定を行う際、タクシー運転手は、例えば、自分からの位置は遠いが目的地が自宅、会社等の方向である、自分が詳しい地域である等の事情を考慮して、自己にとって都合のよいタクシー要求者を選択する。
【０１３７】そして、タクシー運転手は、タクシーサービスを提供することを決定したサービス要求者の携帯端末４０に対して、タクシー要求を受信した旨の応答を自己の携帯端末の位置検出手段により取得された位置情報含めて通知する。
【０１３８】（６）そして、タクシー運転手から、タクシー要求を受信した旨の応答を受信したタクシー要求者用アプリケーションは、携帯端末４０上に図２６に示されるような表示を行う。図２６に、タクシー運転手からの応答を受信した際に、タクシー要求者用アプリケーションにより表示される画面の一例を示す。
【０１３９】そして、このタクシー運転手からの応答を受信したタクシー要求者は、この応答の中からサービスを受けるタクシー運転手を決定し、サービスを受けることを決定した旨の通知をそのタクシー運転手の携帯端末に対して行う。複数の応答があった場合には、この複数の応答の中から最も条件のよいもの、一般的には最も近い位置にあるタクシーを、この応答の中に含まれている位置情報に基づいて選択して決定することとなる。図２０R>０では、タクシー要求者が、タクシー１、２のうちタクシー２を選択した場合を示している。そのため、携帯端末３２に対してのみサービスを受けることを決定した旨の通知が送信される。
【０１４０】そして、この通知を受けたタクシー２のタクシー運転手は、設定しているフィルタを解除し、タクシー要求者の所在地に向かいタクシーサービスを提供する。
【０１４１】次に、上記で説明した本実施形態の移動するサービス提供者探索システムにおける処理を、タクシー要求者により行われるタクシー探索処理と、タクシー運転手により行われるクシー要求者探索処理に分けて説明する。
【０１４２】先ず、タクシー要求者により行われるタクシー探索処理を図２７のフローチャートを参照して説明する。
【０１４３】タクシー要求者がタクシーの乗車を希望して、携帯端末４０のタクシー要求者用アプリケーションを起動すると、携帯端末４０に設けられているＧＰＳ受信機等の位置情報取得手段は携帯端末４０の現在の位置を示す情報を位置情報として取得する。そして、タクシー要求者が目的地を入力すると、携帯端末４０のタクシー要求者用アプリケーションは、位置情報、目的地等の情報を含んだイベントを、タクシーサービスの提供を希望する旨を通知するためのタクシー要求イベントとして意味情報ネットワーク１０に対して送信する（ステップ７０１）。そして、タクシー要求者はある期間（例えば数分間）だけ、タクシー運転手からの応答を待つ（ステップ７０２）。
【０１４４】ステップ７０２においてタクシー運転手からの応答があった場合、タクシー要求者は、その応答の中から乗車を希望するタクシーを、タクシー運転手の携帯端末の位置情報に基づいて選択し、選択したタクシー運転手に対してサービスを受けることを決定した旨の通知を送信する（ステップ７０５）。そして、迎えにきたタクシーに乗車し、目的地へ向かう（ステップ７０６）。
【０１４５】ステップ７０２においてタクシー運転手からの応答がなかった場合、タクシー要求者は、タクシーへの乗車をあきらめるかどうか検討し（ステップ７０３）、あきらめる場合にはタクシー探索モードを終了する（ステップ７０４）。ステップ７０３において、タクシーへの乗車をあきらめない場合、少し時間をおく、または少し場所を移動する等してから再度ステップ７０１の処理を繰り返すことによりタクシー探索処理を継続する。
【０１４６】次に、タクシー運転手により行われるタクシー要求者探索処理を図２８のフローチャートを参照して説明する。
【０１４７】先ず、タクシーサービスを行おうとするタクシー運転手が携帯端末のタクシー運転手アプリケーションを起動すると、携帯端末に設けられているＧＰＳ受信機等の位置情報取得手段は、携帯端末の現在の位置を位置情報として取得し、得られた位置情報を、図２２に示すようなフィルタとして意味情報ネットワーク１０に対して設定する（ステップ８０１）。
【０１４８】そして、タクシー運転手はある期間（例えば数分間）だけ、タクシー要求者からのタクシー要求イベントの受信を待つ（ステップ８０２）。
【０１４９】ステップ８０２においてタクシー要求者からのタクシー要求イベントを受信した場合、そのタクシー要求者のうちのどれか１人を、タクシー要求者の位置および目的地に基づいて選択して応答を送信する（ステップ８０３）。そして、タクシー要求者からの決定通知の受信を待つ（ステップ８０４）。
【０１５０】ステップ８０４においてタクシー要求者からの決定通知を受信した場合には、タクシー運転手は、設定しているフィルタを解除し（ステップ８０５）、決定通知を送信してきたタクシー要求者の所在地へ向かい、タクシー要求者に対してタクシーサービスを提供する（ステップ８０６）。
【０１５１】ステップ８０２においてタクシー要求者からのタクシー要求イベントを受信した場合、またはステップ８０４においてタクシー要求者からの決定通知を受信しなかった場合、ステップ８０１の処理に戻りタクシー要求者探索処理を継続する。
【０１５２】上記のようにして行われる本実施形態の移動するサービス提供者探索システムによれば、タクシー運転手は、タクシー運転手の携帯端末３１〜３３に設けられた位置情報取得手段により取得された位置情報をフィルタとして設定し、タクシー要求者はタクシー要求者の携帯端末４０に設けられた位置情報取得手段により取得された位置情報を含むサービス要求をイベントとして意味情報ネットワーク１０に送信するようにし、タクシー運転手からの応答に含まれている位置情報に基づいてサービスを受けるタクシー運転手を決定しているので、サービス要求者であるタクシー要求者は、サービス提供者である複数のタクシー運転手の中から、サービス要求者に最も近いタクシー運転手を探索することが可能となる。
【０１５３】また、タクシー運転手は、タクシー要求者からのタクシー要求に含まれている、タクシー要求者の位置情報および目的地に基づいて、タクシーサービスの提供を行うタクシー要求者を決定しているので、自己にとって都合のよいタクシー要求者を選択することができる。
【０１５４】さらに、意味情報ネットワーク１０を用いてこのシステムを実現しているため、サービス提供者とサービス要求者の間の仲介を行う仲介者の存在を必要とすることがない。
【０１５５】本実施形態では、サービス要求者がタクシーの乗車を希望するタクシー要求者で、サービス提供者がタクシー運転手の場合を用いて説明したが、本発明はこのような場合に限定されるものではなく、サービス提供者が屋台、移動図書館、献血車、弁当販売等のように移動しながらサービスの提供を行い、サービス要求者がそのサービス提供者からサービスの提供を受けるような場合であれば同様に本発明を適用することができるものである。例えば、サービス提供者が屋台の場合には、本発明を用いることにより、サービス要求者は自分が現在位置している場所に最も近い屋台を探索することができる。
【０１５６】また、本実施形態では、タクシー運転手１〜３は、携帯端末３１〜３３を用いてタクシー要求者探索処理を行っていたが、携帯端末３１〜３３はタクシーに据え付けられているような携帯することができない端末であってもよい。さらに、本実施形態では、タクシー要求者からのタクシー要求に、タクシー要求者の位置および目的地を情報として含めるようにしているが、目的地の情報を含めないでタクシー要求を送信するようにしてもよい。この場合には、タクシー運転手は、タクシー要求者の位置にのみ基づいてタクシーサービスの提供を行うタクシー要求者を選択することになる。また、サービスの形態によっては、目的地という情報そのものが存在しない場合もあるため、このようなサービスに本発明を適用した場合には、サービス要求者からのサービス要求には目的地という情報は含まれない。
【０１５７】（第２の実施形態）次に、本発明の第２の実施形態の移動するサービス提供者探索方法について説明する。
【０１５８】図２９は、本発明の第２の実施形態の移動するサービス提供者探索方法によるサービスを説明するためのシステム図である。
【０１５９】上記第１の実施形態では、サービス提供者であるタクシー運転手は、タクシー要求を受信した旨の応答に自己の位置情報のみを含めてタクシー要求者に送信していたが、本実施形態では、自己の位置情報のみではなくサービス料金であるタクシー料金をも含めるようにした点が第１の実施形態とは異なっている。
【０１６０】本実施形態では、タクシー１〜３の運転手から、タクシー要求者に対してタクシー要求を受け付けた旨の応答を送信する場合、図２９に示すように、それぞれ“８０元”、“６０元”、“１００元”というタクシー料金の情報を含めて送信する。
【０１６１】このタクシー料金は、タウシー要求者の携帯端末４０から送信されてくるタクシー要求イベントに含まれる目的地の情報から算出される料金である。タクシー料金の料金体系が決まっている場合には、このような料金の差は発生しないが、タクシー料金の料金体系がタクシー会社毎に異なっているような場合も有り得るからである。
【０１６２】タクシー運転手１〜３からの、位置情報およびタクシー料金の情報が含まれた応答を受信した、携帯端末４０のタクシー要求者用アプリケーションは、図３０３０に示されるような表示を行う。
【０１６３】そして、タクシー運転手１〜３からの、応答を受信したタクシー要求者は、携帯端末４０上に表示されたタクシー運転者の携帯端末３１〜３３の位置情報およびタクシー料金の情報に基づいて乗車を希望するタクシーを決定する。この決定の際には、単純に最も自分からの距離が短いタクシーを選択してもよいし、最もタクシー料金の低いタクシーを選択してもよいし、または、自分からの距離およびタクシー料金を総合的に考慮して最も最適と考えるタクシーを選択するようにしてもよい。
【０１６４】次に、図３１を用いて、タクシー要求者が乗車を希望するタクシーを決定する際の方法を具体的に説明する。図３１は、本発明の第２の実施形態のサービス提供者探索方法を説明するために、タクシー要求者とタクシー１〜３の位置関係を示す図である。
【０１６５】例えば、タクシー要求者が目的地を“成都空港”と入力したことにより、タクシー１、２、３の運転手からがそれぞれ、“８０元”、“６０元”、“１００元”というタクシー料金を提示してきて、タクシー１、２、３が図３１に示すような場所に位置している場合を用いて説明する。
【０１６６】タクシー要求者が目的地へ到達するための時間の短縮を第１優先と考える場合、例えば飛行機の出発時間が迫っているような場合には自分からの距離が最も短いタクシー１を選択することとなる。また、時間には余裕があり料金が最も低いことをタクシー要求者が望む場合には、タクシー２を選択することとなる。このように、本実施形態によれば、タクシー要求者は、応答を送信してきた複数のタクシーの中から、自分からの距離とタクシー料金とを総合的に考慮して、最も適したタクシーを選択することができるようになる。
【０１６７】
【発明の効果】以上説明したように、本発明によれば、複数の移動するサービス提供者の中から、サービス要求者に最も近いサービス提供者を仲介者を必要となることなく探索することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態の構成を示すブロック図である。
【図２】イベントの構成を示す説明図である。
【図３】意味情報ネットワークのモデルを示す図である。
【図４】意味情報の定義を示す説明図である。
【図５】イベントタイプの定義例を示す説明図である。
【図６】イベントの一例を示す説明図である。
【図７】フィルタの定義例を示す説明図である。
【図８】意味情報ネットワークの構成を示す図である。
【図９】意味情報ネットワークの動作メカニズムと制御インタフェースを示す説明図である。
【図１０】物理リンクを示す説明図である。
【図１１】フィルタの管理方法を示す説明図である。
【図１２】イベントルーティング方法を示す説明図である。
【図１３】フィルタの登録状況を示す説明図である。
【図１４】意味情報ネットワークの動作メカニズムと制御インタフェースを示す説明図である。
【図１５】物理リンクを示す説明図である。
【図１６】イベントルーティング方法を示す説明図である。
【図１７】フィルタの登録状況を示す説明図である。
【図１８】フェデレーション方法を示す説明図である。
【図１９】コミュニティモデル示す説明図である。
【図２０】本発明の第１の実施形態のサービス提供者探索システムを示す図である。
【図２１】図２０に示される意味情報ネットワーク１０に登録されているイベントタイプを示す図である。
【図２２】タクシー運転手が、タクシーサービスを行うために、得られた位置情報を意味情報ネットワークに設定するフィルタ条件の一例を示す図である。
【図２３】タクシー要求者がタクシー要求を発信しようとする際に、携帯端末４０において表示されるタクシー要求者用アプリケーションの画面の一例を示す図である。
【図２４】タクシー要求者用アプリケーションにより送信されるイベントの一例を示す図である。
【図２５】タクシー運転手の携帯端末がタクシー要求を受信した際に、タクシー運転手用アプリケーションにより表示される画面の一例を示す図である。
【図２６】タクシー運転手からの応答を受信した際に、タクシー要求者用アプリケーションにより表示される画面の一例を示す図である。
【図２７】タクシー要求者により行われるタクシー探索処理を示すフローチャートである。
【図２８】タクシー運転手により行われるタクシー要求者探索処理を示すフローチャートである。
【図２９】本発明の第２の実施形態のサービス提供者探索システムを示す図である。
【図３０】本発明の第２の実施形態において、タクシー運転手からの応答を受信した際に、タクシー要求者用アプリケーションにより表示される画面の一例を示す図である。
【図３１】本発明の第２の実施形態のサービス提供者探索方法を説明するために、タクシー要求者とタクシー１〜３の位置関係を示す図である。
【符号の説明】
１ 意味情報ネットワーク（ＳＩＯＮ）
２ 端末
１０ 意味情報ネットワーク
２１ 送信端末
２２ 受信端末
３１〜３３ タクシー運転手の携帯端末
４０ タクシー要求者の携帯端末
７０１〜７０６ ステップ
８０１〜８０６ ステップ
ＳＩ−ＳＷ 意味情報スイッチ
ＳＩ−Ｒ 意味情報ルータ
ＳＩ−ＧＷ 意味情報ゲートウェイ
ＥＰＯ イベントプレースオブジェクト
ＳＬＯ シェアードリンクオブジェクト
ＦＡ フェデレーションエージェント
【０００１】
【発明の属する技術分野】本発明は、ネットワーク上に分散するコンテンツの中からエンドユーザの興味に合致するコンテンツを特定する、あるいは、コンテンツプロバイダがコンテンツを配布すべき最適なコンシューマを特定する意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、移動するサービス提供者探索方法および探索システムに関する。
【０００２】
【従来の技術】最近、携帯電話等の携帯端末を使用して様々なサービスを提供するサービス提供者を探索することができるようになっている。しかし、これらのシステムでは、サービス提供者は移動しないことが前提となっているため、タクシー、屋台等の移動していて現在位置を特定することができない移動するサービス提供者を探索することはできない。また、サービス要求者も携帯端末を保有することにより移動しているため、従来のシステムでは、ある位置に居るサービス要求者に対して最も迅速にサービスを行うことができる移動するサービス提供者を探索するようなことを行うことはできなかった。
【０００３】また、一般にサービス要求者が複数の不特定のサービス提供者の探索を行う場合には、サービス提供者とサービス要求者との仲介を行うための仲介者が必要となる。そして、仲介者が存在することにより、仲介料の発生、仲介者における照合処理負荷の集中化、設定している情報のリアルタイムな変化が不可能であるといった問題が発生する。特にサービス要求者、サービス提供者がともに移動する者である場合、これらの者の間の仲介を行うためには位置情報のリアルタイムな変更が不可欠となり、仲介者が必要となるようなシステムではこのようなリアルタイムに変化する情報を扱うことは困難である。
【０００４】
【発明が解決しようとする課題】上述した従来のサービス提供者探索システムでは、サービス提供者と、そのサービスを受けるサービス要求者とが共に移動しているような場合、サービス提供者の現在の位置と、サービス要求者の現在の位置の両方を考慮して、そのサービス要求者に最も近いサービス提供者を探索するようなシステムを実現することができなかった。また、サービス要求者が複数の不特定のサービス提供者の探索を行う場合には、サービス提供者とサービス要求者との仲介を行うための仲介者が必要となる。
【０００５】本発明は上述したような従来の技術が有する問題点に鑑みてなされたものであって、複数の移動するサービス提供者の中から、サービス要求者に最も近いサービス提供者を探索することを、仲介者を必要とすることなく可能とする移動するサービス提供者探索方法および検出システムを実現することを目的とする。
【０００６】
【課題を解決するための手段】上記目的を達成するために、本発明の移動するサービス提供者探索方法は、データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス提供者の端末が、イベントとして送信された前記サービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報を含めて前記サービス要求者の携帯端末へ送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきた応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する。
【０００７】本発明によれば、サービス提供者はサービス提供者の端末に設けられた位置情報取得手段により取得された位置情報をフィルタとして設定し、サービス要求者はサービス要求者の携帯端末に設けられた位置情報取得手段により取得された位置情報を含むサービス要求をイベントとして意味情報ネットワークに送信するようにし、サービス提供者からの応答に含まれている位置情報に基づいてサービスを受けるサービス提供者を決定しているので、複数の移動するサービス提供者の中から、サービス要求者に最も近いサービス提供者を探索することが、仲介者を必要とすることなく可能となる。
【０００８】また、本発明の他の移動するサービス提供者探索方法は、データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス提供者の端末が、イベントとして送信された前記サービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置および目的地に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報を含めて前記サービス要求者の携帯端末へ送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきた応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する。
【０００９】本発明によれば、サービス要求者は、サービス要求を、サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして送信し、サービス提供者は、イベントとして送信されたサービス要求を受信すると、サービスを提供するサービス要求者をサービス要求者の位置および目的地に基づいて決定するようにしているので、サービス提供者は自己にとって都合のよいサービス要求者を選択することができる。
【００１０】本発明の他の移動するサービス提供者探索方法は、データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス提供者の端末が、イベントとして送信された前記サービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置および目的地に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報および前記目的地の情報から算出したサービス料金の情報を含めて前記サービス要求者の携帯端末へ送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきた応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置およびサービス料金に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する。
【００１１】本発明によれば、サービス要求者は、サービス要求を、サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして送信し、サービス提供者は、イベントとして送信されたサービス要求を受信すると、サービスを提供するサービス要求者をサービス要求者の位置および目的地に基づいて決定するようにしているので、サービス提供者は自己にとって都合のよいサービス要求者を選択することができる。さらに、サービス要求者は、サービス提供者からの応答を受信すると、サービス提供者からの応答に含まれている位置情報およびサービス料金の情報に基づいてサービスを受けるサービス提供者を決定しているので、複数の移動するサービス提供者の中から、サービス要求者からの距離およびサービス料金の額を総合的に考慮して最も最適と考えられるサービス提供者を探索することが可能となる。
【００１２】また、本発明の他の移動するサービス提供者探索方法は、前記サービス提供者がタクシー運転手であり、前記サービス要求者がタクシーの乗車を希望するタクシー要求者である。
【００１３】また、本発明の移動するサービス提供者探索方法は、前記位置情報手段をＧＰＳ受信機とするようにしてもよい。
【００１４】
【発明の実施の形態】本発明を説明する前に、本発明の前提となる、発信する情報のメッセージ性を高めた分散型ネットワークシステムについて説明する。
【００１５】分散型指向のネットワークシステムとしては、ナップスターを用いるものが知られ、さらに、分散性を高めたネットワークシステムとしては、Ｇｎｕｔｅｌｌａを用いるものが知られている。
【００１６】まず、ナップスターを用いるネットワークシステムについて説明する。ナップスター利用者は、各ナップスター利用者が公開するファイルの情報を格納したナップスター社のサーバに検索要求を送信し、ナップスター社のサーバは検索したファイルを所有するナップスター利用者に関するＩＰアドレス等の情報を返信する。実際のファイルのやり取りはナップスター社のサーバを介することなく、ＩＰアドレスを入手した利用者が直接目的とするファイルを所有するナップスター利用者にアクセスすることにより行われる。
【００１７】Ｇｎｕｔｅｌｌａを用いるネットワークシステムの場合には、Ｇｎｕｔｅｌｌａ利用者の端末は、接続している相手端末の状態を定期的に確認し、メッセージやファイルの検索要求を中継し合うことが行われる。検索結果は検索要求を行った相手に戻され、その後のファイル転送はナップスターと同様に利用者間で直接行われる。これにより、サーバを用いることなくネットワークが構築されることとなる。
【００１８】これらの各ネットワークシステムのうち、ナップスターを用いるものにおいては、本発明が問題点とする仲介者に相当するサーバを必要とするため、本発明の目的を達成するものではない。
【００１９】Ｇｎｕｔｅｌｌａを用いるネットワークシステムにおいては、サーバを用いることなくメッセージやファイルの検索要求が行われるものの、発信する情報が単なるファイルの検索要求であり、この応答を確認した利用者によるファイルの転送が利用者間で行われるものであるため、オークションや逆オークション等の１対複数でのやり取りが必要となる形態にはそぐわない。
【００２０】発信する情報のメッセージ性を高めた分散型ネットワークシステムとして以下に説明する意味情報ネットワークシステムがあり、本発明は、このような意味情報ネットワークシステムを用いることを前提とする。
【００２１】まず、意味情報ネットワーク（Semantic Information-Oriented Network、以下、ＳＩＯＮと称する）について概要を説明する。ＳＩＯＮは、意味情報に基づいて、イベントを目的地まで配送することが可能なネットワークである。図１に、ＳＩＯＮの概念モデルを示す。図１において、各端末２は、意味情報（Semantic Information：ＳＩ）をＳＩＯＮ１に対して登録する。一方、イベントを送信する端末２は、図２に示す意味情報（Semantic information）とデータ（Data）から構成されるイベントをＳＩＯＮ１に送出する。ここでいう、意味情報とは、イベントに含まれるデータの特性を記述したものであり、データのメタ情報として位置づけられる。例えば、意味情報は、・データを“東京在住者”に配送する。
・データを“クラシックに興味のある人”に配送する。
・データを“１Ｍｂｐｓ以上の通信環境を有する人”に配送する。
・データを“目白通りを通行中の人”に配送する。
・データを“キーワード（例えば旅行）に合致するコンテンツを有するコンテンツプロバイダ”に配送する。
等の表現が用いられる。
【００２２】ＳＩＯＮは、上述したような意味情報に基づいて、データを配送すべき対象（端末、人、ソフトウエアなど）を動的に決定し、特定された対象者に対して、データの配送および通知を行うことが可能な自律分散型のメタネットワークである。このＳＩＯＮを用いることにより、ブローカを介することなく、情報提供者が提供するに相応しいユーザに対してのみ、自身の情報を直接提案することが可能になる。このような、ブローカ非介在型（非ブローカモデル）でpeer-to-peerの情報提案が可能なビジネスモデルを、ここでは、御用聞きモデル（または、御用聞き型情報提案モデル、非ブローカモデル）と呼ぶ。同様に、検索サービス（ブローカ）を介することなく、ユーザが希望する情報を直接探索可能な、リアルタイム情報検索も可能である。なお、御用聞き型情報提案サービスとして、以下のサービス等に適用することが可能である。
（１）製造会社：自社製品に興味を持ってくれそうなお客様を中心に製品案内を送りたい。
（２）広告主：お客様ごとにパーソナライズされた広告を送りたい。
（３）物々交換：ユーザ間の合意に基づいて、製品を売買したり、交換したい。
【００２３】なお、イベントのデータ部にどのような情報を設定するかは、サービス依存である。例えば情報の実体、情報へのリファレンス（ＵＲＬ、分散オブジェクト識別子等）、プロキシ（Ｊｉｎｉプロキシ等）、モバイルエージェントなど様々な利用形態が可能である。
【００２４】次に、ＳＩＯＮの詳細について説明する。
【００２５】＜ＳＩＯＮアーキテクチャ＞まず、ＳＩＯＮのネットワークアーキテクチャについて説明する。図３R>３にＳＩＯＮのネットワークモデルを示す。ここで、説明の便宜上、端末２を、イベント送信者の送信端末２１とイベント受信者の受信端末２２とに区別して表記する。イベント受信者は、受信端末２２を用いて自身が受信することを希望するイベントの意味情報（受信するイベントのタイプと取得条件）をメタデータとしてＳＩＯＮ１に登録する。これをフィルタ（Filter）と呼ぶ。一方、イベント送信者は、送信端末２１を用いてＳＩＯＮ１にイベントを送出することにより、ＳＩＯＮに刺激（Incentive）を与える。このイベントは、図２に示すようにイベントの特性を記述した意味情報とデータから構成される。意味情報の定義を図４に示す。意味情報は、イベントのメタデータであり、かつ、意味情報タイプ（イベントタイプ）のインスタンスである。
【００２６】ＳＩＯＮ１は、イベント受信者が登録したフィルタに対して、イベント送信者が送出したイベントを照合（フィルターリング）させるための自律分散型の照合ネットワークである。照合の結果、イベントが通過した（イベントに反応した）フィルタは発火（Ignition）し、対応するイベント受信者の受信端末２２が自律起動する。この仕組みにより、不特定多数の端末２の中から、対象となる端末２をスケーラブルかつリアルタイムに探索・発見することが可能になる。
【００２７】次に、イベントタイプについて説明する。図５に、イベントのテンプレートであるイベントタイプの定義例を示す。図５に示すように、イベントタイプは、イベントタイプ名（Event type name）と条件名（図５においては、”Service”や”CPU power”が相当する）、およびそれぞれの条件名に対するデータ型（StringやLongが相当する）と条件式（＝＝や＞＝が相当する）が定義されたものである。イベントタイプ名は、イベントタイプを一意に識別するための名称である。
【００２８】なお、イベントタイプの親タイプを継承可能である。
【００２９】図６に示すように、イベントタイプのデータ構造に従って、イベントを作成する。イベントは、イベントタイプ名、条件名と条件値の組み合せ、および、データ部から構成される。イベントの中で定義された条件名、条件式、条件値が、イベントタイプと一致しない場合は、エラーになる。但し、イベントの中で使用される条件名は、イベントタイプのサブセットでも良い。
【００３０】図７にフィルタの定義例を示す。フィルタは、受け付けるイベントタイプ名（Event type name）、属性名（図７においては、”CPU power”や”Age”が相当する）と属性値（図７においては、２００や２５が相当する）のペアーから成る。受け付けるイベントタイプ名で定義されたイベントタイプに属するイベントのみが、フィルタリングの対象となる。ここには、複数のイベントタイプ名を定義することができ、さらに、ワイルドカード（＊．＊）を指定することにより、全てのイベントを対象とすることも可能である。なお、フィルタで定義された属性名が、受け付けるイベントタイプ名で定義されたイベントタイプの条件名の中に存在しない場合には、エラーとなる。但し、イベントタイプのサブセットでも良い。
【００３１】次に、ＳＩＯＮ１の構成を説明する。図８は、ＳＩＯＮ１の構成を示す図である。図８に示すようにＳＩＯＮ１は、意味情報スイッチ（Semantic Information-Switch、図面ではＳＩ−ＳＷと図示する）、意味情報ルータ（Semantic Information -Router、図面ではＳＩ−Ｒと図示する）、意味情報ゲートウェイ（Semantic Information-Gateway、図面ではＳＩ−ＧＷと図示する）から構成される。
【００３２】意味情報スイッチ（ＳＩ−ＳＷ）は、フィルタとして登録された意味情報と、イベントに付与された意味情報を照合し、その結果、発火したイベント受信者の端末２を起動するスイッチング機構を提供する。意味情報スイッチ（ＳＩ−ＳＷ）と各端末２はスター型で結合される。
【００３３】意味情報ルータ（ＳＩ−Ｒ）は、意味情報スイッチ間のイベント経路選択を行うとともに、端末２から意味情報スイッチに対して送出されたイベントを他の意味情報スイッチに転送する役割を担う。これは、意味情報に基づく動的なイべントルーティングにより達成される。
【００３４】意味情報ゲートウェイ（ＳＩ−ＧＷ）は、イベントプレース（Event place）間でのイベントの転送を行う。ここで、イベントプレースは、共通の意味情報空間を保証する最小単位（オントロジードメイン）である。イベントプレース内では、イベントタイプの名称、概念、語彙、意味、関連などのオントロジー体系の一意性が保証され、共通のオントロジーに基づいて意味情報が記述されることになる。基本的には、イベント送信者の端末２から送出したイベントは、イベントプレース内のみで流通するが、意味情報ゲートウェイ（ＳＩ−ＧＷ）を介することにより、異なるオントロジー体系を有するイベントプレース間でのイベントの相互流通が可能になる。このとき、意味情報ゲートウェイ（ＳＩ−ＧＷ）はイベントのオントロジー変換を行った後、異なるイベントプレースヘイベントを転送する。
【００３５】＜動作メカニズムとインタフェース仕様＞ＳＩＯＮ１の実現方法の一例として、分散オブジェクト技術を用いた実装方法を示す。ここで、ＳＩ−ＳＷ，ＳＩ−Ｒ，ＳＩ−ＧＷは、それぞれ、イベントプレースオブジェクト（ＥＰＯ）、シェアードリンクオブジェクト（ＳＬＯ）、フェデレーションエージェント（ＦＡ）と呼ばれる分散オブジェクトとして実装される。図９を用いて、ＳＩＯＮ１の動作メカニズムと制御インタフェースを詳述する。また、ＳＩＯＮ−ＭＴ（Ｍａｎａｇｅｍｅｎｔ Ｔｏｏｌ）やＳＩＯＮインタフェーサを用いることにより、ＳＩＯＮ１のネットワークインタフェースを使用することができる。また、ＭＴを用いて、ＥＰＯの撤収・増減設、物理リンク情報の動的変更、ＰＯマイグレーション（ＰＯのバインド先ＥＰＯの動的変更）、発火率の収集、人気の高い惰報や流行している情報の統計情報収集などを簡単に行うことができる。
【００３６】・イべントプレースファクトリの起動＆初期化（図９（１））
まず、ＳＩＯＮ運営者は、任意のホスト上にイベントプレースファクトリ（ＥＰＦ）を起動し、続いて、ＥＰＦの初期化を行う。この時、ＥＰＦに対して、イべントプレース（ＥＰ）を生成可能なホスト名、およびＥＰの実行ファイルの格納先を与える。これらを、ＥＰ生成情報と呼ぶ。
【００３７】・イべントプレースの生成要求（図９（２））
次に、ＥＰ運営者は、ＥＰＦに対して、ＥＰの生成を要求する。このとき、ＥＰ名、およびＥＰ属性を与える。ここで、ＥＰ属性とは、生成されたＥＰが、御用聞きモデルもしくは問い合せモデルのどちらの目的で使用されるかを表したものであり、イべントの流れの方向性を表すものである。
【００３８】・イべントプレースの生成（図９（３））
次に、ＥＰ生成要求を受け取ったＥＰＦは、ＥＰを生成する。具体的には、このとき、ＥＰの管理を司るイべントプレースマネージメントオブジェクト（ＥＰＭＯ）が生成される。すなわち、ＥＰへの処理要求は、ＥＰＭＯへの処理要求と同義である。ＥＰＦは、生成要求元に生成したＥＰ（すなわち、ＥＰＭＯ）の識別子を返却する。なお、ＥＰＭＯは、図９の（１）において指定された、ＥＰを生成可能なホストの中から、動的に決定されたホストに対して生成される。ＥＰＭＯの起動先ホストの決定方法として、サイクリックに起動先を決定する、トラヒックに応じて決定する、起動先ホストを明示的に指定する、等の方法を選択できる。
【００３９】・イべントプレースの初期化要求（図９（４））
次に、ＥＰ運営者は、ＥＰの初期化をＥＰＭＯに依頼する。このとき、シングルイべントプレースオブジェクトもしくは、マルチプルイべントプレースオブジェクトの指定を行う。マルチプルイべントプレースオブジェクトを指定した場合には、イべントプレースオブジェクト（ＥＰＯ）の物理リンク情報（トポロジ）も併せて与える必要がある。ここで、ＥＰＯの物理リンク情報は、任意のＥＰＯが他のどのＥＰＯの存在を知っているかを表現したものである。
【００４０】例えば、図１０に示すように、ＥＰＯ２・３２は、ＥＰＯ１・３１、ＥＰＯ３・３３、ＥＰＯ４・３４の存在を知っているが、ＥＰＯ３・３３はＥＰＯ２・３２の存在しか知らないことを表現している。このように、マルチプルＥＰＯは、ＥＰ内でのイべント照合処理の負荷分散によるスケラビリティ向上を目的としたものである。
【００４１】ＥＰＭＯは、図９の（１）において指定された、ＥＰを生成可能なホストリストの中から、ＥＰＯを生成するホストを動的に決定し、そこにＥＰＯを生成する。このとき、各ＥＰＯには、それぞれ一つのフィルタファクトリ（ＦＦ）と統計情報収集オブジェクト（ＳＯ）が常に付随して生成され、これらが、ＳＩ−ＳＷに相当する。さらに、物理リンク数に応じて、シェアードリンクオブジェクト（ＳＬＯ）が各ＥＰＯに付随して生成される。例えば、ＥＰＯ２・３２に対しては３個のＳＬＯが生成され（図中のＳＬＯ2,1、ＳＬＯ2,3、ＳＬＯ2,4に対応する）、これらが、ＳＩ−Ｒに相当する。ＥＰＯの起動先の決定方法は、ＥＰＭＯのそれと同様であるが、イべントタイプ毎に使用するＥＰＯを固定化することも可能である。なお、ＥＰＭＯは、ＥＰ内にイべントタイプファクトリ（ＥＴＦ）を生成する。ＥＰ内では一元的なイベントタイプの名前空間がＥＴＦにより保証される。
【００４２】・イべントプレースに対するイべント送信のためのセッション確立要求（図９（５））
次に、ＥＰにセッションの確立を要求する。ＥＰＭＯは、セッション要求毎にプロキシオブジェクト（ＰＯ）を生成する。要求元へは、ＰＯの識別子であるセッション識別子を返却する。
【００４３】なお、ＥＰＭＯは、ＰＯの生成時に、ＰＯに対して、どのＥＰＯを使用する（どのＥＰＯとバインドする）かを指示する。この指示は、マルチプルＥＰＯにおいて必要となるが、バインドするＥＰＯの決定方法は、ＥＰＭＯのそれと同様である。ＥＰへのセッション確立要求時に、イべント送信のためのセッションであるか、イべント受信のためのセッションであるかを指定する必要がある。本例においては、イべント送信のためのセッションを指定する。
【００４４】・イべントタイプの登録（図９（６））
次に、ＰＯに対して、イべントタイプの登録を要求する。このとき、ＰＯは、ＥＴＦにイべントタイプオブジェクト（ＥＴＯ）の生成を要求する。さらに生成されたＥＴＯにイべントタイプを格納する。一方、ＥＰに、イべントタイプ登録を要求することができる。このとき、ＥＰＭＯは、ＥＴＦにＥＴＯの生成を要求し、生成されたＥＴＯにイべントタイプを格納する。一般的に、イべント送信者がイべントタイプを登録する場合は、ＰＯ経由で行う。一方、ＥＰ運営者は、ＥＰに、イべントタイプ登録を行う。なお、同じ名前のイベントタイプを登録するとエラーになる。
【００４５】・イべントプレースに対するイべント受信のためのセッション確立要求（図９（７））
次に、ＥＰに対してイベント受信のためのセッションの確立を要求する。このとき、セッション確立の要求者（イべント受信オブジェクト）は、イべントの通知先であるイべント受信オブジェクトの識別子、および、イべントの通知方法（発火型、ルックイン型）をパラメータとして与える。
【００４６】続いて、ＥＰＭＯは、セッション要求毎にＰＯを生成する。要求元へは、セッション識別子を返却する。なお、ＥＰＭＯは、ＰＯの生成時に、ＰＯに対して、使用するＥＰＯを指示する。この指示は、マルチプルＥＰＯにおいて必要となるが、バインドするＥＰＯの決定方法は、ＥＰＭＯのそれと同様である。
【００４７】・フィルタオブジェクトの生成要求（図９（８））
次に、ＰＯに対して、フィルタオブジェクト（ＦＯ）の生成を依頼する。このとき、ＰＯは、ＦＦにＦＯの生成を要求する。このとき、ＰＯとバインドされたＥＰＯに付随したＦＦが使用される。なお、ＦＯの生成要求元には、生成されたＦＯの識別子がＰＯ経由で返却される。
【００４８】・フィルタ値の設定（図９（９））
次に、ＦＯ識別子をパラメータとして、ＦＯへのフィルタ値の設定を、ＰＯへ依頼する。なお、フィルタオブジェクトの中に格納されているイべントタイプ名（すなわち、フィルターリングの対象とするイべントタイプ名）をキーに、ＦＯのデータ構造（フィルタ値）が正しいかどうかのチェックをＥＴＯに依頼することが選択的に可能である。正しくない場合は、エラーとなる。但し、ワイルドカードが指定された場合には、このチェック処理を一切行わない。
【００４９】・フィルタ登録（図９（１０））
次に、ＦＯにフィルタ値を設定した後、Ｆのフィルタ識別子をパラメータとして、ＰＯに対しフィルタの登録を依頼する。このとき、登録要求元にフィルタ識別子が返却される。これを契機に、イべントの受信が可能になる。なお、一つのＰＯを介して、複数のフィルタ登録が可能であるが（これには、一つのＰＯを介して異なる複数のＦＯをフィルタとして登録する、もしくは、同一のＦＯを複数回、フィルタとして登録する場合が考えられるが）、一つのＰＯに対して登録されたすべてのフィルタは、“ＯＲの関係”を持つ。
【００５０】・イべント送信（図９（Ａ））
次に、イベント送信者は、ＰＯに対して、イべントを送信する。このとき、ＰＯは、イべントの中に格納されているイべントタイプ名をキーに、イべントのデータ構造が正しいかどうかのチェックをＥＴＯに依頼することが選択的に可能である。このチェック処理を選択したとき、正しい場合は、次の処理（図９（Ｂ））へ、正しくない場合は、エラーとなる。
【００５１】・イベントの照合依頼（図９（Ｂ））
次に、ＰＯはイベントをＥＰＯに転送する。このとき、ＥＰＯがスレッドを生成する。なお、スレッドはイベント毎に生成され、各スレッドはイベントの多重処理を行う。
【００５２】・フィルタとの照合（図９（Ｃ））
次に、スレッド（ＥＰＯ）は、イベントとフィルタを照合することにより、フィルターリング処理を行う。これには、完全一致、部分一致、重みづけ一致などがあり、フィルタ値の設定時に指定することができる。
【００５３】・プロキシオブジェクトの起動（図９（Ｄ））
次に、フィルタとの照合の結果、イベントがフィルタを通過すると、対応するＰＯが起動されこのイベントを受け取る。このとき、ＰＯは、受信したイベントのタイプ、値、イベントＩＤ等をＳＯに登録することが選択的に可能である。これらの情報から、ＳＯはイベントの発火率（イベントタイプ毎、イベント毎）や、ＥＰ内で流行している評判の高いイベントを測定することが可能になる。
【００５４】・イベント受信オブジェクトの起動（図９（Ｅ））
次に、ＰＯは、イベント受信オブジェクトを起動するとともに、イベント受信オブジェクトに対してこのイベントを渡す。これが、発火型（割り込み型）のイベント通知に対応する。
【００５５】・ルックイン型のイベント通知（図９（Ｆ））
一方、ＰＯがイベント受信オブジェクトを起動するのではなく、イベント受信オブジェクト自身が、イベント受信オブジェクトに対応するＰＯにスプールされているイベントを、取り出すことも可能である。これがルックイン型のイベント通知に対応する。イベント受信オブジェクトの起動契機は、サービス形態に依存して種々存在するが、典型的な例として、エンドユーザがイベント受信オブジェクトにコンテンツの提案要求を行った場合が考えられる。
【００５６】＜フィルタの管理方法＞次に、各ＥＰＯにおけるフィルタの管理方法を説明する。
【００５７】まず、イベント受信のためのセッションを確立する。このとき、セッション要求毎に一つのＰＯが生成され、このＰＯは任意の一つのＥＰＯにバインドされる。このＥＰＯには、それぞれ、一つのＦＦが付随している。これにより、ＰＯが使用するＥＰＯが一意に決定され、以降の処理はすべて、ＰＯ（イベント受信用セッション）を介して行われる。
【００５８】次に、ＦＯを生成し、ＦＯに対してフィルタ値（受信するイベントのタイプとその取得条件）を設定する。続いて、ＦＯ識別子をパラメータとして、フィルタの登録を行う。このとき、各フィルタには、ＦＯ識別子が格納される。各ＥＰＯは、ＰＯを介して登録されたフィルタを以下に示す規則に基づいて管理する。
【００５９】まず、フィルタに格納されているＦＯ識別子を用いて、ＦＯに設定されている“受信するイベントのタイプ”を参照する。続いて、受信するイベントのタイプ毎にフィルタを分類し、イベントタイプ毎に分類されたフィルタを、さらにＰＯ毎に細分類し、管理する。
【００６０】この管理規則について図１１を参照して、ＰＯ１を介して、フィルタを登録する場合について説明する。ここでは、フィルタ登録時に指定するＦＯの中に、受信するイベントのタイプとして、“イベントタイプＸ”が設定されているものとする。このとき、ＥＰＯに登録されるフィルタは、図１１のフィルタ１が相当し、同様に、ＰＯ２を介して登録されたフィルタにはフィルタ２が相当する。また、各ＰＯにおいて、複数のフィルタを登録することが可能であるが、登録されたフィルタは“ＯＲ関係”を有するものとする。
【００６１】まず、イベントタイプＸのイベントがＥＰＯに到着したとき、フィルタ１との照合が行われる。その結果、フィルタ１が発火するとＰＯ１が起動される。次に、フィルタ２との照合が行われ、その結果、フィルタ２が発火するとＰＯ２が起動される。このとき、フィルタ２とフィルタ３は“ＯＲ関係”を有するため、フィルタ３との照合は行われない。このようなフィルタ管理方法を用いることにより、一つのイベントに対する各ＥＰＯでの照合処理回数を、基本的にＰＯ数（受信用セッション数）以下にすることができる。
【００６２】＜イベントルーティング方法＞次に、イベントルーティング方法について説明する。
【００６３】ＥＰＯ（ＳＩ−ＳＷ）は、イベントの送受信者（端末などのエンティティ）をセッションを介してスター型で収容する。さらに、ＥＰＯ（ＳＩ−ＳＷ）は、イベント受信者（イベント受信オブジェクト）が登録したフィルタと、イベント送信者が送出したイベントを照合し、その結果、発火したフィルタに対応するイベント受信者のみにイベントを通知する（合致するイベント受信者にのみイベントを配送する）照合スイッチである。
【００６４】そのため、イベントの送信者数（イベント数）やイベントの受信者数（フィルタ数）が増加すると、それに比例してＥＰＯの処理能力が飽和する。そこで、ＳＩＯＮアーキテクチャでは、スケラビリティの高いＥＰを実現する手段として、マルチプルＥＰＯを提供する。マルチプルＥＰＯとは、ＥＰＯ数に比して、ＥＰのトータル処理能力をスケーラブルに向上させることを目的とし、具体的には、以下の２つの観点からＥＰの高いスケラビリティを達成する。
【００６５】第一点は、負荷分散と自律分散である。これは、複数のＥＰＯに、イベントの送受信者を分散させることにより、イベントのフィルターリング処理の負荷分散を行い、処理の集中に伴うボトルネック要因を作らないようにするものである。。さらに、各ＥＰＯが他のＥＰＯの影響を受けることなく、自律的に動作可能な機構による分散協調を達成する。
【００６６】第二点は、ネットワークトラヒックの削減とフィルターリング処理の最適化である。これは、ＥＰＯ間で不要なイベントを転送しないことによる通信量の最小化と、それに伴う無駄なフィルタリング処理の削減を行うものである。
【００６７】図１０において、ＥＰＯ３・３３に対し、受信するイベントのタイプとして、イベントタイプＸのフィルタが登録される場合を考える。ここで、イベントタイプＸのイベントがＥＰＯ４に対して送出されたとき、ＥＰＯ２経由でこのイベントをＥＰＯ３に転送する必要がある。このとき、イベントタイプＸのフィルタが登録されていないＥＰＯ１に対して、当該イベントが転送されてはならない。このようなＥＰＯ間のイベントのルーティング制御を行うものが、シェアードリンクオブジェクト（ＳＬＯ）であり、前述したＳＩ−Ｒに相当する。
【００６８】以下にＳＩ−Ｒについて詳細を説明する。
【００６９】まず、ＥＰの初期化時に、物理リンク情報（ＥＰＯのトポロジ）に基づいて、ＳＬＯが各ＥＰＯに付随して生成される。例えば、図９において、ＥＰＯ２に対して３個のＳＬＯが生成される。これらは、図中のＳＬＯ2,1、ＳＬＯ2,3、ＳＬＯ2,4に対応する。このＳＬＯi,jは、ＥＰＯjからＥＰＯjへのイベント転送を行うシェアードリンク（ＳＬi,j）を確立する。すなわち、図９および図１２に示すように、ＳＬＯi,jは、ＥＰＯjに対してイベント受信のセッションを確立し、一方、ＥＰＯiに対してイベント送信のセッションを確立することにより、イベント転送のための論理リンクであるシェアードリンクＳＬi,jを確立する（シェアードリンクとは、ＥＰの初期化時における、ＳＬＯによるセッションの確立を意味し、フィルタ登録処理を含まない）。
【００７０】ＥＰの初期化後に、イベント受信者は、ＥＰへのセッションを確立し、セッションを介してフィルタを登録することが可能になる。このとき、確立済みのシェアードリンクに従って、イベントパスが設定される。例えば、図１２において、イベント受信者（Event Receiver）３がＰＯ３を介して、“イベントタイプＸのイベント受信を行うフィルタを、ＥＰＯ３へ登録した場合において、ＰＯ３は、ＥＰＯ３ヘイベントタイプＸのフィルタを登録するとともに、その旨をＳＬＯ3,j（ここでは、ＳＬＯ3,2）に通知する。ＳＬＯ3,2はＳＬ3,2を用いて、ＥＰＯ２に対してイベントタイプＸのフィルタを登録する。これは、前述したように、ＳＬＯ3,2に対して割り当てられた受信用セッションのＰＯを介して行われる。同様に、このＰＯは、その旨を、ＳＬＯ2,3を除くその他のＳＬＯ2,jに対して通知する。ＳＬＯ2,j（ｊ≠３）は、ＳＬ2,jを用いて、ＥＰＯヘフィルタを登録する。順次同様に、すべてのＥＰＯにイベントＸに対するパスが設定されるまで、繰り返される。
【００７１】このように、イベントタイプＸに対して確立された一連のパスを、イベントパスと呼ぶ。これは、ＰＯ３を介したフィルタ登録がトリガとなって、すべてのＥＰＯへ、イベントタイプ毎のイベントパス設定要求が順次、自律的に波及していくものである。すなわち、個々のＥＰＯは隣接するＥＰＯのみを認識すれば良い。そのため、イベントパスの集中管理やブロードキャストによるイベントパスの設定・管理方法に比べて、簡単かつ一元的な自律ロジックでイベントパスを確立することが可能になる。
【００７２】この時点でのＥＰＯ１におけるフィルタの登録状況を図１３に示す。イベント受信者３がＰＯ３を介してフィルタを登録した結果、フィルタ１がＥＰＯ１に登録されることになる。イベントパスの設定とは、シェアードリンク情報に基づいて、一連のＥＰＯにイベント転送のためのフィルタを登録することを指す。また、ＳＬＯが登録するフィルタには、受信するイベントタイプ名が設定されるのみであり、取得条件は設定されず、イベントタイプ名のみのフィルターリングを行う。
【００７３】この状況において、イベント受信者２がＰＯ２を介して、イベントタイプＸのフィルタを、ＥＰＯ２へ登録したとき、前述と同様に新たなイベントパスの設定がすべてのＥＰＯへ波及し、その結果として、フィルタ２がＥＰＯ１へ登録されることになり、イベントパス設定の要求毎にフィルタが登録されることになる。
【００７４】このとき、ＥＰＯ１にイベントタイプＸのイベントが送出されると、フィルタ１が発火し、ＳＬＯ2,1が起動される。ＳＬＯ2,1が、このイベントをＥＰＯ２へ送出することにより、ＳＬＯ3,2が起動される。さらに、ＳＬＯ3,2を介して、当該イベントがＥＰＯ３へも転送されることになる。また、ＳＬ2,3とＳＬ3,2間でのイベントの無限転送を防止するために、イベントは、制御情報の一つとして、通過したＥＰＯの識別子を、最新順に最大２つ保持する。
【００７５】なお、前述したように、フィルタ１とフィルタ２は、ＯＲ関係を有するため、フィルタ１が発火した場合にはフィルタ２との照合は行われない。そのため、フィルタ１が存在するにも関わらず、新たにフィルタ２を登録したことに伴う、フィルターリング処理の冗長オーバヘッドを全く生じないようにすることができる。これは、イベントパスを設定したときに、既設のイベントパスを含めた全イベントパスの再構築を全く必要としないことを意味し、簡単かつ一元的なイベントパスの自律的な設定が可能になる。
【００７６】また、ＥＰＯ１内に、イベント受信者が確立したセッションおよびそれを介したフィルタ登録がある場合には（ＰＯｎのフィルタ３に対応）、ＳＬＯ対応のフィルタリング処理がすべて完了した後に、ＰＯｎ対応のフィルターリング処理が行われる。すなわち、他のＥＰＯへのイベント転送処理を優先して行い、その後、自ＥＰＯでの照合処理が開始される。
【００７７】以上説明した、イベントルーチング方法の更なる効果として、フィルタ登録解除時に、イベントパスの再構築が必要ない点が挙げられる。例えば、イベント受信者３がＰＯ３を介して、登録したフィルタの登録解除を行った場合、登録の場合と同様に、解除要求が順次、自律的に波及する。その結果、ＥＰＯ１において、フィルタ１の登録のみが解除されることになるが、フィルタ２は存命する（これ以降は、フィルタ２がフィルタ１の代わりにイベントを転送する）ため、イベントパスの再構築なしに、すべての既設イベントパスの一貫性が保証される。
【００７８】このような自律分散型のルーティング制御方法を用いることによって、ＥＰＯの相互接続と分散協調を容易に実現することが可能になる。これに伴い、小規模なネットワークから大規模なネットワークヘの移行、ローカルなネットワークからグローバルなネットワークヘの移行等をスムーズに行うことができる。また、ボトムアップアプローチによるグローバルネットワーク化を、共通のロジックで容易に達成することができる。
【００７９】図１４ないし図１７はリング型結合を持つ物理リンクにおけるＳＩ−Ｒについて説明するために図である。
【００８０】例えば、図１５に示すように、リング型結合を持つ物理リンクにおいて、ＥＰＯ２は、ＥＰＯ１、ＥＰＯ３の存在を知っていることを表現している。このように、マルチプルＥＰＯは、ＥＰ内でのイべント照合処理の負荷分散によるスケラビリティ向上を目的としたものである。
【００８１】ＥＰＭＯは、図１４の（１）において指定された、ＥＰを生成可能なホストリストの中から、ＥＰＯを生成するホストを動的に決定し、そこにＥＰＯを生成する。このとき、各ＥＰＯには、それぞれ一つのフィルタファクトリ（ＦＦ）と統計情報収集オブジェクト（ＳＯ）が常に付随して生成され、これらが、ＳＩ−ＳＷに相当する。さらに、物理リンクに応じて、シェアードリンクオブジェクト（ＳＬＯ）が各ＥＰＯに付随して一つ生成される。たとえば、ＥＰＯ２に対しては、図中のＳＬＯ２，３が生成される。これが、ＳＩ−Ｒに相当する。ＥＰＯの起動先の決定方法は、ＥＰＭＯのそれと同様であるが、イベントタイプ毎に使用するＥＰＯを固定化することも可能である。なお、ＥＰＭＯは、ＥＰ内にイベントタイプファクトリ（ＥＴＦ）を生成する。ＥＰ内では一元的なイベントタイプの名前空間がＥＴＦにより保証される。
【００８２】以下にＳＩ−Ｒについて詳細を説明する。
【００８３】まず、ＥＰの初期化時に、物理リンク情報（ＥＰＯのトポロジ）に基づいて、ＳＬＯが各ＥＰＯに付随して生成される。たとえば、図１４において、ＥＰＯ２に対してＳＬＯ2,3が生成される。このＳＬＯi,jは、ＥＰＯjからＥＰＯiへのイベント転送を行うシェアードリンク（ＳＬi,j）を確立する。すなわち、図１４および図１６に示すように、ＳＬＯi,jは、ＥＰＯjに対してイベント受信のセッションを確立し、一方、ＥＰＯiに対してイベント送信のセッションを確立することにより、イベント転送のための論理リンクであるシェアードリンクＳＬi,jを確立する（シェアードリンクとは、ＥＰの初期化時における、ＳＬＯによるセッションの確立を意味し、フィルタ登録処理を含まない）。これによって、片方向のリング状のシェアードリンクＳＬi,jが確立される。
【００８４】ＥＰの初期化後に、イベント受信者は、ＥＰへのセッションを確立し、セッションを介してフィルタを登録することが可能になる。このとき、確立済みのシェアードリンクに従って、イベントパスが設定される。例えば、図１６において、イベント受信者（Event Receiver）３がＰＯ３を介して、イベントタイプＸのイベント受信を行うフィルタを、ＥＰＯ３へ登録した場合を考える。このとき、ＰＯ３は、ＥＰＯ３ヘイベントタイプＸのフィルタを登録するとともに、その旨をＳＬＯ3,1に通知する。このとき、ＳＬＯ3,1には、フィルタ登録の要求発生元がＥＰＯ３である旨がパラメータとして与えられる。ＳＬＯ3,1はＳＬ3,1を用いて、ＥＰＯ１に対してイベントタイプＸのフィルタを登録する。これは、前述したように、ＳＬＯ3,1に対して割り当てられた受信用セッションのＰＯを介して行われる。同様に、このＰＯは、その旨を、ＳＬＯ1,2に対して通知する。ＳＬＯ1,2は、ＳＬ1,2を用いて、ＥＰＯ２ヘフィルタを登録する。順次同様に、すべてのＥＰＯにイベントＸに対するパスが設定されるまで、繰り返される。なお、この処理は、フィルタ登録の要求発生元（ここでは、ＥＰＯ３）の直前まで繰り返される。すなわち、ＳＬＯ2,3は、ＥＰＯ３にフィルタを登録しない。
【００８５】この時点でのＥＰＯ１におけるフィルタの登録状況を図１７に示す。イベント受信者３がＰＯ３を介してフィルタを登録した結果、フィルタ１がＥＰＯ１に登録されることになる。イベントパスの設定とは、シェアードリンク情報に基づいて、一連のＥＰＯにイベント転送のためのフィルタを登録することを指す。なお、ＳＬＯが登録するフィルタには、受信するイベントタイプ名が設定されるのみであり、取得条件は設定されず、イベントタイプ名のみのフィルターリングを行う。
【００８６】この状況において、イベント受信者２がＰＯ２を介して、イベントタイプＸのフィルタを、ＥＰＯ２へ登録したとき、前述と同様に新たなイベントパスの設定がすべてのＥＰＯへ波及し、その結果として、フィルタ２がＥＰＯ１へ登録されることになり、イベントパス設定の要求毎にフィルタが登録されることになる。
【００８７】このとき、ＥＰＯ１にイベントタイプＸのイベントが送出されると、フィルタ１が発火し、ＳＬＯ3,1が起動される。ＳＬＯ3,1が、当該イベントをＥＰＯ３へ送出することにより、ＳＬＯ2,3が起動される。さらに、ＳＬＯ2,3を介して、当該イベントがＥＰＯ２へも転送されることになる。なお、イベントの無限巡回を防止するために、イベントは、制御情報の一つとして、イベントが生起したＥＰＯの識別子を保持し、イベントの生起元ＥＰＯ（ＳＬＯ）に当該イベントが巡回して戻って来たときに、当該イベントを破棄する。
【００８８】次に、前述したイベントルーティング方法とは異なるイベントルーティング方法を説明する。このルーティング方法は、シェアードリンク（論理リンク）を確立するまでの手順は、前述した方法と同様である。このイベントルーティング方法が前述した方法と異なるのは、イベントパスを確立しない点であり、ＳＬＯi,jがシェアードリンクＳＬi,jを確立する時に同時に、唯一のフィルタを登録するようにするものである。このとき、登録されるフィルタには、受信するイベントのタイプとしてワイルドカードを指定する。これによって、すべてのイベントを転送の対象とし、イベントタイプ毎のイベントパスを確立しないようにする。
【００８９】このように意味情報にワイルドカードを指定することによって、リング状のシェアードリンクＳＬi,j内をイベントが巡回するため、全てのＥＰＯに対してイベントを配送することが可能となる。
【００９０】＜フェデレーション方法＞次に、図１８を参照してフェデレーション方法について説明する。フェデレーションエージェント（ＦＡ）とは、イベントプレース間のフェデレーションを確立するエージェントであり、前述したＳＩ−ＧＷに相当する。例えば、イベントプレース（Event Place）Ａがイベントプレース（Event Place）Ｂに対してフェデレーションを確立する場合を考える。まず、イベントプレースＡに属するＦＡが、イベントプレースＢに対して、フィルタを登録する。このとき、イベントプレースＢに属するイベント送信者がイベントを送出し、その結果、このフィルタが発火すると、ＦＡが自律起動する。これは、ＦＡをイベントプレースＢに属する一つのイベント受信者として見なすことができる。次に、ＦＡは取得したイベントを、自身が属するイベントプレースＡに対して再送出する。これは、ＦＡを、イベントプレースＡに属する一つのイベント送信者として見なすことができる。
【００９１】このように両者の役割を併せ持つＦＡを用いて、イベントプレース間のフェデレーションを容易に実現できる。すなわち、単一イべントプレースと同じ制御論理で、イベントプレース間のフェデレーションを実現することが可能である。この機構を用いて、ＳＩＯＮ１の基本構成単位であるイベントプレースを相互接続することにより、グローバルな照合ネットワークをボトムアップアプローチで構築することが可能となり、イベントプレース間に跨るイベントの共有を実現することができる。なお、イベントプレースＡとイベントプレースＢがそれぞれ異なるオントロジーを持つ場合、イベントプレースＡに属するＦＡは、イベントプレースＢから取得したイベントを、イベントプレースＡのオントロジーに変換した後、イベントプレースＡに送出する。
【００９２】異なるオントロジー体系に跨ってイベント転送を行う場合には、オントロジー変換が必要になる。この変換を行う従来技術として、標準オントロジーを規定し、他のイベントプレースにイベントを転送する場合には、一旦、標準オントロジーに準拠した形式に変換した後に、イベントの転送を行う方法や、イベントプレースの組み合わせの数だけオントロジー変換テーブルを事前に用意しておくなどの方法がある。
【００９３】しかしながら、イベントプレースの動的なフェデレーション（フェデレーションの動的な開始、開始解除）に対応するためには、従来の方法は柔軟性に欠ける。そこで、本発明では、図１８に示すように、ＦＡが隣接するイベントプレースのオントロジー情報との差分（変換情報）のみを、オントロジー変換テーブルに保持するようにしている。すなわち、これは、各ＦＡが変換情報をそれぞれ分散して保有し、全体でオントロジー体系の一貫性を保証する方法である。これは、イベントプレース間の動的なフェデレーションに容易に対応することが可能になるが、その反面、イベントがイベントプレースを跨る毎に、オントロジー変換処理が発生するため、従来方法に比べて、変換処理オーバヘッドが増大するという特徴を有している。
【００９４】＜コミュニティと進化型ネットワーク＞次に、ＳＩＯＮ１のキラーサービスの一つであるコミュニティサービスについて説明する。コミュニティサービスにおけるエンティティは、自身のポリシに基づいて、学習・進化・退化・消滅等を繰り返すことにより、その活動様式を動的に決定することが可能な自律分散型の動作主体である。コミュニティは、このようなエンティティに対して効率的なコミュニケーションの場を提供するものである。すなわち、コミュニティ内のエンティティは、自身とコミュニケートすべきエンティティや、自身の振る舞いに影響を与えるエンティティを動的に探索・発見・特定し、特定されたエンティティとインタラクションを行うことが可能である。
【００９５】このコミュニティは、特に以下の特徴を持つエンティティを取り扱うことができる。
【００９６】（１）極小粒度で、膨大な数のエンティティがコミュニティに存在する（不特定多数のエンティティ）。
【００９７】（２）エンティティの属性がリアルタイムに変化する。典型的なエンティティの属性として、位置情報、時刻等がある。
【００９８】（３）コミュニティ内のエンティティの振る舞いに規則性がなく、行動予測が困難である。
【００９９】（４）コミュニティヘの参加、コミュニティからの退去、消滅、複製等が頻繁かつ不規則に発生する。
【０１００】（５）コミュニティ内のエンティティは、ポリシ、属性、シナリオ等に基づいて相互にリアルタイムに出会う必要がある。
【０１０１】このような特性を持つエンティティをサーバやメディエータ（ブローカ）で管理し、相互にリアルタイムに探索・発見することは性能上、容易でない。ＳＩＯＮ１のＥＰは、このような特徴を持つコミュニティの実行環境として位置づけられる。すなわち、コミュニティはＥＰのメタ実行環境であり、ＥＰを直接用いることに比して、抽象度の高いコミュニケーションの場を提供するものである。コミュニティの実行環境にＥＰを用いることにより、コミュニティ内のすべてのエンティティは、ブローカを介することなく、コミュニケーションすべきエンティティを直接発見することができる。これは、コミュニティ内のエンティティのコミュニケーションは、ＥＰ内のイベントの送受信として実装されるためである。
【０１０２】図１９にコミュニティの概念モデルを示す。ユーザエージェント（ＵＡ）、情報・サービス提供エージェント（ＩＳＡ）がコミュニティ内のエンティティに相当する。ＵＡはユーザの代理人として自律的に振る舞うエージェントであり、ユーザの嗜好、動作環境、位置情報、状況、傾向などに応じて、自身の振る舞いを動的に決定し、インタラクションすべきＩＳＡや他のＵＡを探索し、それらとインタラクションする。ＩＳＡは情報提供者やサービス提供者の代理人として自律的に振る舞うエージェントであり、提供者の意図に基づいて、インタラクションすべきＵＡや他のＩＳＡを探索する。すなわち、自身の情報を提供するのに相応しいユーザを探索して特定する。
【０１０３】一方、コミュニティエージェント（ＣｏｍＡ）は、コミュニティの運営を司るエージェントである。ＥＰ運営者は、運営ポリシに基づいて、ＳＩＯＮ−ＭＴを介したＳＩＯＮの制御・運営を行う。従って、ＣｏｍＡは、ＥＰ運営者をエージェント化したものと見なすことができる。基本的に、コミュニティの運営ポリシはＣｏｍＡによって規定される。例えば、ＵＡ、ＩＳＡなどのエンティティに対するコミュニティヘの参加、退去、消滅、複製などの認可、コミュニティ内に流通させる情報の把握と統制（相応しくないイベントの削除など）、コミュニティ内の統計情報（トレンド情報、評判の高い情報など）の管理などを自身の運営ポリシに基づいて司る。
【０１０４】また、コミュニティの高いスケーラビリティやリライアビリティの保証を達成するため、負荷状況や障害状況に応じて、ＥＰおよびＥＰＯの増減設、撤収、マイグレーション等のＳＩＯＮ制御を実行する。すなわち、ＳＩＯＮ１とＣｏｍＡを組み合わせることにより、ＳＩＯＮ１は自律分散型ネットワークから、学習、成長、進化が可能な進化型ネットワークヘと発展する。このように、ＣｏｍＡはコミュニティ内のエンティティの振る舞いを統制するとともに、ＳＩＯＮ１を自己組織化するための役割を担う。さらに、コミュニティ間のコラボレーションにより、コミュニティ間での情報の共有が可能である。例えば、コミュニティＡにおいて流通している情報の中で、人気が高いトップ１０のみを、コミュニティＢに流通させることができる。以下に処理の流れを示す。
【０１０５】まず、コミュニティＢのＣｏｍＡが、イベントプレースＢのＦＡに対して、“コミュニティＡにおいて流通している情報の中で、人気が高いトップ１０のみを、コミュニティＢに流通させる”旨を指示する。
【０１０６】次にＦＡは、イベントプレースＡに対して、トップ１０のイベントタイプを問い合わせる。これを受けて、イベントプレースＡは、配下の統計情報収集オブジェクト（ＳＯ）に問い合わせ、その結果を、ＦＡに返却する。
【０１０７】次に、ＦＡは取得したイベントタイプを基に、オントロジー変換テーブルを作成するとともに、イベントプレースＡに対しフィルタを設定する。以降、ＦＡは、イベントプレースＡから、当該イベントを受信可能になる。
【０１０８】次にＦＡは、イベントプレースＡから取得したイベントを、オントロジー変換テーブルに基づいてオントロジー変換し、それをイベントプレースＢへと送出する。
【０１０９】以上説明したような形態によれば、以下の２点の効果を得ることができる。
【０１１０】第１に、分散オブジェクト環境上にＳＩＯＮのネットワーク環境を容易に構築できる。
【０１１１】第２に、サービスアプリケーションをエンティティとしてコミュニティに参加させることにより、簡単にイベントを送出したり、必要なイベントをピックアップすることが可能になり、相互にコミュニケションを図ることが可能になる。
【０１１２】以上説明したように、ＳＩＯＮでは、以下の効果を得ることができる。
【０１１３】ＦＡを介したイベントプレース間のフェデレーション機構により、他のイベントプレースのみで流通していたイベントを、自イベントプレース内に取り込むことができる。逆に、他のイベントプレースにイベントを送出することにより、自イベントプレース内で流通しているイベントをアドバタイズできる。このように、異なるイベントプレース間で、イベントの共有が可能になるとともに、オントロジーを考慮したイベントプレース間の相互運用により、ボトムアップアプローチによるグローバルな自律分散型の照合ネットワークを構築することが可能になる。
【０１１４】マルチプルＥＰＯの機構により、フィルタリング処理を複数のＥＰＯに負荷分散させることが可能になるとともに、自律的に動作するＥＰＯ間のイベントルーチング機構により、ネットワークトラヒックを最小限に抑えることが可能になる。これにより、結果的にＥＰのトータルスループットをスケーラブルに向上させることが可能となる。
【０１１５】ブローカを介することなく、自身に相応しいエンティティを直接探索・発見することが可能となる。例えば、情報提供者は、ユーザの存在を知ることなく、自身が提供する情報に相応しいユーザを特定することができる。同様に、ユーザは情報提供者の存在を知ることなく、自身の嗜好に相応しい情報提供者を探索・発見することができる。すなわち、ユーザと情報提供者は互いに等価的である。これにより、特定のブローカに頼ることなく、自身のポリシに従って、リアルタイムに情報を発信することが可能になる。また、探索対象となるエンティティの数が膨大な場合やエンティティが探索対象ドメインに頻繁に出入りする場合において、非ブローカモデルに基づく探索技術が特に有効となる。
【０１１６】ＳＩＯＮにおいては、意味情報の終端点がネットワークとなる。一方、端末間でpeer-to-peer接続を行う方法においては、意味情報の終端点が端末になるため、端末の中身を外部に公開することになる。従って、ＳＩＯＮは後者の方法と比べて、高いセキュリティとプライバシ保護を実現することが可能である。
【０１１７】次に、上記のような内容を備える意味情報ネットワークシステムを用いた本発明の実施形態について説明する。
【０１１８】（第１の実施形態）図２０は、本発明の第１の実施形態の移動するサービス提供者探索方法によるサービスを説明するためのシステム図である。本実施形態では、サービス要求者としてタクシーの乗車を希望しているタクシー要求者が、最も迅速にタクシーによる輸送というサービスを提供してくれるサービス提供者を検索する場合を用いて説明する。
【０１１９】本実施形態では、図２０における意味情報ネットワーク１０を、上述したイベントプレースを用いて実現しているが、意味情報ネットワーク１０の実現方法はこの限りではない。
【０１２０】本実施形態の移動するサービス提供者探索システムでは、タクシー要求者の携帯端末４０と、タクシー運転手１〜３の携帯端末３１〜３３が意味情報ネットワーク１０を介して接続されている。
【０１２１】タクシー要求者の携帯端末４０は、タクシー要求をイベントとして意味情報ネットワーク１０に送信する送信端末として機能し、タクシー運転者の携帯端末３１〜３３は、イベントとして送信されたタクシー要求を選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末として機能する。
【０１２２】また、タクシー要求者の携帯端末４０、タクシー運転手の携帯端末３１〜３３ともに、 ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信機等の位置情報取得手段が設けられていて、その携帯端末が現在位置している場所を示す位置情報を取得することができるようになっている。
【０１２３】タクシー要求者が使用する携帯電話等の携帯端末４０およびタクシー運転手が使用する携帯端末３１〜３３に、ＣＯＲＢＡ準拠のＯＲＢ等のミドルウェアと、上述したイベントプレースファクトリ生成機構をインストールして自身の端末においてイベントプレースを生成するか、あるいは、他のネットワークノード上にあるイベントプレースへアクセスしてセッションを確立し、意味情報ネットワーク１０に接続されていることを前提とする。また、意味情報ネットワーク１０には、図２１２１のようなイベントタイプが登録されているとする。
【０１２４】この登録されているイベントタイプは、イベントタイプ名として「タクシー探索」が定義され、イベントプロパティ名として「緯度」、「軽度」、「地名」、「目印」、「目的地」が定義されている。また、これらのイベントプロパティには、イベントプロパティ値として、それぞれ「float型」、「float型」、「float型」、「string型」、「string型」、「string型」が定義されている。
【０１２５】次に、本実施形態の移動するサービス提供者探索方法について図面を参照して詳細に説明する。図２０２０中の括弧内の番号は、伝送される情報について、生起順に付されており、以下、この番号順に本実施形態の動作について説明する。
【０１２６】（１）先ず、タクシーサービスを行おうとするタクシー運転手１〜３が携帯端末３１〜３３のタクシー運転手アプリケーションを起動すると、携帯端末３１〜３３に設けられているＧＰＳ受信機等の位置情報取得手段は、携帯端末３１〜３３の現在の位置を位置情報として取得する。ここでは、位置情報として、タクシーの現在位置を、緯度、経度により取得するものとする。そして、位置情報取得手段は、この位置情報を一定時間間隔で継続的に取得する。
【０１２７】（２）そして、次に、タクシー運転手アプリケーションにより得られた位置情報を、図２２に示すようなフィルタとして意味情報ネットワーク１０に対して設定する。尚、図２０では、設定されるフィルタを概念的に黒丸にて示す。
【０１２８】この場合、タクシー運転手アプリケーションは、得られた緯度、経度に対してある程度幅を持たせてフィルタ値を設定する。例えば、ＧＰＳ受信機により得られた位置情報が、北緯４０．５５度、東経１３５．５５度の場合、４０．２〜４０．９度の範囲の緯度、および１３５．３〜１３５．８度の範囲の経度をフィルタ値として設定する。また、タクシー運転手アプリケーションは、得られた位置情報とデジタル地図を照合し、位置情報を都道府県、市町村等の地名情報に変更してフィルタの「地名」として設定する。図２２では、“北緯４０．５５度、東経１３５．５５度”という位置情報が、“東京都武蔵野市中町＊”という地名情報に変換された場合を例として用いている。
【０１２９】そして、携帯端末３１〜３３のタクシー運転手アプリケーションは、一旦設定したフィルタを、位置情報取得手段により得られた位置情報を用いて予め設定された一定期間毎に更新する。
【０１３０】（３）次に、タクシー要求者が、タクシー要求を意味情報ネットワーク１０に送信しようとして、携帯端末４０のタクシー要求者用アプリケーションを起動すると、携帯端末４０に設けられているＧＰＳ受信機等の位置情報取得手段は携帯端末４０の現在の位置を示す情報を位置情報として取得する。
【０１３１】（４）次に、携帯端末４０のタクシー利用者用アプリケーションは、位置情報取得手段により得られた位置情報とデジタル地図を照合し、この位置情報を都道府県、市町村、番地表現等の地名情報に変更する。
【０１３２】そして、タクシー要求者用アプリケーションは、タクシー要求者に対して、タクシーサービスを利用して行くこと希望する目的地の入力を促す。図２３に、タクシー要求者がタクシー要求を発信しようとする際、携帯端末４０において表示されるタクシー要求者用アプリケーションの画面の一例を示す。ここでは、目的地として“東京都千代田区外神田 ＪＲ秋葉原駅”が入力された場合を示している。
【０１３３】そして、タクシー要求者が目的地を入力すると、携帯端末４０のタクシー要求者用アプリケーションは、「緯度」、「経度」、「地名」、「目的地」を設定したイベントを、タクシーサービスの提供を希望する旨を通知するためのタクシー要求イベントとして意味情報ネットワーク１０に対して送信する。図２４にタクシー要求者用アプリケーションにより送信されるイベントの一例を示す。
【０１３４】（５）次に、設定しているフィルタ条件が、イベント条件と合致したタクシー運転手の携帯端末により、タクシー要求者からのタクシー要求が意味情報ネットワーク１０から受信されることになる。ここでは、タクシー１、２の携帯端末３１、３２のみが設定したフィルタの条件と、イベントの条件とが一致してタクシー要求者からのタクシー要求イベントを意味情報ネットワーク１０から受信したものとする。
【０１３５】図２５に、タクシー運転手の携帯端末がタクシー要求を受信した際に、タクシー運転手用アプリケーションにより表示される画面の一例を示す。タクシー要求イベントを意味情報ネットワーク１０から受信したタクシー運転手の携帯端末には、タクシー要求者の現在の位置情報と、目的地が表示される。
【０１３６】タクシー要求を受信したタクシー運転手は、このタクシー要求に含まれるタクシー要求者の位置情報および目的地の情報に基づいてタクシーサービスを提供するタクシー要求者を決定する。この決定を行う際、タクシー運転手は、例えば、自分からの位置は遠いが目的地が自宅、会社等の方向である、自分が詳しい地域である等の事情を考慮して、自己にとって都合のよいタクシー要求者を選択する。
【０１３７】そして、タクシー運転手は、タクシーサービスを提供することを決定したサービス要求者の携帯端末４０に対して、タクシー要求を受信した旨の応答を自己の携帯端末の位置検出手段により取得された位置情報含めて通知する。
【０１３８】（６）そして、タクシー運転手から、タクシー要求を受信した旨の応答を受信したタクシー要求者用アプリケーションは、携帯端末４０上に図２６に示されるような表示を行う。図２６に、タクシー運転手からの応答を受信した際に、タクシー要求者用アプリケーションにより表示される画面の一例を示す。
【０１３９】そして、このタクシー運転手からの応答を受信したタクシー要求者は、この応答の中からサービスを受けるタクシー運転手を決定し、サービスを受けることを決定した旨の通知をそのタクシー運転手の携帯端末に対して行う。複数の応答があった場合には、この複数の応答の中から最も条件のよいもの、一般的には最も近い位置にあるタクシーを、この応答の中に含まれている位置情報に基づいて選択して決定することとなる。図２０R>０では、タクシー要求者が、タクシー１、２のうちタクシー２を選択した場合を示している。そのため、携帯端末３２に対してのみサービスを受けることを決定した旨の通知が送信される。
【０１４０】そして、この通知を受けたタクシー２のタクシー運転手は、設定しているフィルタを解除し、タクシー要求者の所在地に向かいタクシーサービスを提供する。
【０１４１】次に、上記で説明した本実施形態の移動するサービス提供者探索システムにおける処理を、タクシー要求者により行われるタクシー探索処理と、タクシー運転手により行われるクシー要求者探索処理に分けて説明する。
【０１４２】先ず、タクシー要求者により行われるタクシー探索処理を図２７のフローチャートを参照して説明する。
【０１４３】タクシー要求者がタクシーの乗車を希望して、携帯端末４０のタクシー要求者用アプリケーションを起動すると、携帯端末４０に設けられているＧＰＳ受信機等の位置情報取得手段は携帯端末４０の現在の位置を示す情報を位置情報として取得する。そして、タクシー要求者が目的地を入力すると、携帯端末４０のタクシー要求者用アプリケーションは、位置情報、目的地等の情報を含んだイベントを、タクシーサービスの提供を希望する旨を通知するためのタクシー要求イベントとして意味情報ネットワーク１０に対して送信する（ステップ７０１）。そして、タクシー要求者はある期間（例えば数分間）だけ、タクシー運転手からの応答を待つ（ステップ７０２）。
【０１４４】ステップ７０２においてタクシー運転手からの応答があった場合、タクシー要求者は、その応答の中から乗車を希望するタクシーを、タクシー運転手の携帯端末の位置情報に基づいて選択し、選択したタクシー運転手に対してサービスを受けることを決定した旨の通知を送信する（ステップ７０５）。そして、迎えにきたタクシーに乗車し、目的地へ向かう（ステップ７０６）。
【０１４５】ステップ７０２においてタクシー運転手からの応答がなかった場合、タクシー要求者は、タクシーへの乗車をあきらめるかどうか検討し（ステップ７０３）、あきらめる場合にはタクシー探索モードを終了する（ステップ７０４）。ステップ７０３において、タクシーへの乗車をあきらめない場合、少し時間をおく、または少し場所を移動する等してから再度ステップ７０１の処理を繰り返すことによりタクシー探索処理を継続する。
【０１４６】次に、タクシー運転手により行われるタクシー要求者探索処理を図２８のフローチャートを参照して説明する。
【０１４７】先ず、タクシーサービスを行おうとするタクシー運転手が携帯端末のタクシー運転手アプリケーションを起動すると、携帯端末に設けられているＧＰＳ受信機等の位置情報取得手段は、携帯端末の現在の位置を位置情報として取得し、得られた位置情報を、図２２に示すようなフィルタとして意味情報ネットワーク１０に対して設定する（ステップ８０１）。
【０１４８】そして、タクシー運転手はある期間（例えば数分間）だけ、タクシー要求者からのタクシー要求イベントの受信を待つ（ステップ８０２）。
【０１４９】ステップ８０２においてタクシー要求者からのタクシー要求イベントを受信した場合、そのタクシー要求者のうちのどれか１人を、タクシー要求者の位置および目的地に基づいて選択して応答を送信する（ステップ８０３）。そして、タクシー要求者からの決定通知の受信を待つ（ステップ８０４）。
【０１５０】ステップ８０４においてタクシー要求者からの決定通知を受信した場合には、タクシー運転手は、設定しているフィルタを解除し（ステップ８０５）、決定通知を送信してきたタクシー要求者の所在地へ向かい、タクシー要求者に対してタクシーサービスを提供する（ステップ８０６）。
【０１５１】ステップ８０２においてタクシー要求者からのタクシー要求イベントを受信した場合、またはステップ８０４においてタクシー要求者からの決定通知を受信しなかった場合、ステップ８０１の処理に戻りタクシー要求者探索処理を継続する。
【０１５２】上記のようにして行われる本実施形態の移動するサービス提供者探索システムによれば、タクシー運転手は、タクシー運転手の携帯端末３１〜３３に設けられた位置情報取得手段により取得された位置情報をフィルタとして設定し、タクシー要求者はタクシー要求者の携帯端末４０に設けられた位置情報取得手段により取得された位置情報を含むサービス要求をイベントとして意味情報ネットワーク１０に送信するようにし、タクシー運転手からの応答に含まれている位置情報に基づいてサービスを受けるタクシー運転手を決定しているので、サービス要求者であるタクシー要求者は、サービス提供者である複数のタクシー運転手の中から、サービス要求者に最も近いタクシー運転手を探索することが可能となる。
【０１５３】また、タクシー運転手は、タクシー要求者からのタクシー要求に含まれている、タクシー要求者の位置情報および目的地に基づいて、タクシーサービスの提供を行うタクシー要求者を決定しているので、自己にとって都合のよいタクシー要求者を選択することができる。
【０１５４】さらに、意味情報ネットワーク１０を用いてこのシステムを実現しているため、サービス提供者とサービス要求者の間の仲介を行う仲介者の存在を必要とすることがない。
【０１５５】本実施形態では、サービス要求者がタクシーの乗車を希望するタクシー要求者で、サービス提供者がタクシー運転手の場合を用いて説明したが、本発明はこのような場合に限定されるものではなく、サービス提供者が屋台、移動図書館、献血車、弁当販売等のように移動しながらサービスの提供を行い、サービス要求者がそのサービス提供者からサービスの提供を受けるような場合であれば同様に本発明を適用することができるものである。例えば、サービス提供者が屋台の場合には、本発明を用いることにより、サービス要求者は自分が現在位置している場所に最も近い屋台を探索することができる。
【０１５６】また、本実施形態では、タクシー運転手１〜３は、携帯端末３１〜３３を用いてタクシー要求者探索処理を行っていたが、携帯端末３１〜３３はタクシーに据え付けられているような携帯することができない端末であってもよい。さらに、本実施形態では、タクシー要求者からのタクシー要求に、タクシー要求者の位置および目的地を情報として含めるようにしているが、目的地の情報を含めないでタクシー要求を送信するようにしてもよい。この場合には、タクシー運転手は、タクシー要求者の位置にのみ基づいてタクシーサービスの提供を行うタクシー要求者を選択することになる。また、サービスの形態によっては、目的地という情報そのものが存在しない場合もあるため、このようなサービスに本発明を適用した場合には、サービス要求者からのサービス要求には目的地という情報は含まれない。
【０１５７】（第２の実施形態）次に、本発明の第２の実施形態の移動するサービス提供者探索方法について説明する。
【０１５８】図２９は、本発明の第２の実施形態の移動するサービス提供者探索方法によるサービスを説明するためのシステム図である。
【０１５９】上記第１の実施形態では、サービス提供者であるタクシー運転手は、タクシー要求を受信した旨の応答に自己の位置情報のみを含めてタクシー要求者に送信していたが、本実施形態では、自己の位置情報のみではなくサービス料金であるタクシー料金をも含めるようにした点が第１の実施形態とは異なっている。
【０１６０】本実施形態では、タクシー１〜３の運転手から、タクシー要求者に対してタクシー要求を受け付けた旨の応答を送信する場合、図２９に示すように、それぞれ“８０元”、“６０元”、“１００元”というタクシー料金の情報を含めて送信する。
【０１６１】このタクシー料金は、タウシー要求者の携帯端末４０から送信されてくるタクシー要求イベントに含まれる目的地の情報から算出される料金である。タクシー料金の料金体系が決まっている場合には、このような料金の差は発生しないが、タクシー料金の料金体系がタクシー会社毎に異なっているような場合も有り得るからである。
【０１６２】タクシー運転手１〜３からの、位置情報およびタクシー料金の情報が含まれた応答を受信した、携帯端末４０のタクシー要求者用アプリケーションは、図３０３０に示されるような表示を行う。
【０１６３】そして、タクシー運転手１〜３からの、応答を受信したタクシー要求者は、携帯端末４０上に表示されたタクシー運転者の携帯端末３１〜３３の位置情報およびタクシー料金の情報に基づいて乗車を希望するタクシーを決定する。この決定の際には、単純に最も自分からの距離が短いタクシーを選択してもよいし、最もタクシー料金の低いタクシーを選択してもよいし、または、自分からの距離およびタクシー料金を総合的に考慮して最も最適と考えるタクシーを選択するようにしてもよい。
【０１６４】次に、図３１を用いて、タクシー要求者が乗車を希望するタクシーを決定する際の方法を具体的に説明する。図３１は、本発明の第２の実施形態のサービス提供者探索方法を説明するために、タクシー要求者とタクシー１〜３の位置関係を示す図である。
【０１６５】例えば、タクシー要求者が目的地を“成都空港”と入力したことにより、タクシー１、２、３の運転手からがそれぞれ、“８０元”、“６０元”、“１００元”というタクシー料金を提示してきて、タクシー１、２、３が図３１に示すような場所に位置している場合を用いて説明する。
【０１６６】タクシー要求者が目的地へ到達するための時間の短縮を第１優先と考える場合、例えば飛行機の出発時間が迫っているような場合には自分からの距離が最も短いタクシー１を選択することとなる。また、時間には余裕があり料金が最も低いことをタクシー要求者が望む場合には、タクシー２を選択することとなる。このように、本実施形態によれば、タクシー要求者は、応答を送信してきた複数のタクシーの中から、自分からの距離とタクシー料金とを総合的に考慮して、最も適したタクシーを選択することができるようになる。
【０１６７】
【発明の効果】以上説明したように、本発明によれば、複数の移動するサービス提供者の中から、サービス要求者に最も近いサービス提供者を仲介者を必要となることなく探索することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態の構成を示すブロック図である。
【図２】イベントの構成を示す説明図である。
【図３】意味情報ネットワークのモデルを示す図である。
【図４】意味情報の定義を示す説明図である。
【図５】イベントタイプの定義例を示す説明図である。
【図６】イベントの一例を示す説明図である。
【図７】フィルタの定義例を示す説明図である。
【図８】意味情報ネットワークの構成を示す図である。
【図９】意味情報ネットワークの動作メカニズムと制御インタフェースを示す説明図である。
【図１０】物理リンクを示す説明図である。
【図１１】フィルタの管理方法を示す説明図である。
【図１２】イベントルーティング方法を示す説明図である。
【図１３】フィルタの登録状況を示す説明図である。
【図１４】意味情報ネットワークの動作メカニズムと制御インタフェースを示す説明図である。
【図１５】物理リンクを示す説明図である。
【図１６】イベントルーティング方法を示す説明図である。
【図１７】フィルタの登録状況を示す説明図である。
【図１８】フェデレーション方法を示す説明図である。
【図１９】コミュニティモデル示す説明図である。
【図２０】本発明の第１の実施形態のサービス提供者探索システムを示す図である。
【図２１】図２０に示される意味情報ネットワーク１０に登録されているイベントタイプを示す図である。
【図２２】タクシー運転手が、タクシーサービスを行うために、得られた位置情報を意味情報ネットワークに設定するフィルタ条件の一例を示す図である。
【図２３】タクシー要求者がタクシー要求を発信しようとする際に、携帯端末４０において表示されるタクシー要求者用アプリケーションの画面の一例を示す図である。
【図２４】タクシー要求者用アプリケーションにより送信されるイベントの一例を示す図である。
【図２５】タクシー運転手の携帯端末がタクシー要求を受信した際に、タクシー運転手用アプリケーションにより表示される画面の一例を示す図である。
【図２６】タクシー運転手からの応答を受信した際に、タクシー要求者用アプリケーションにより表示される画面の一例を示す図である。
【図２７】タクシー要求者により行われるタクシー探索処理を示すフローチャートである。
【図２８】タクシー運転手により行われるタクシー要求者探索処理を示すフローチャートである。
【図２９】本発明の第２の実施形態のサービス提供者探索システムを示す図である。
【図３０】本発明の第２の実施形態において、タクシー運転手からの応答を受信した際に、タクシー要求者用アプリケーションにより表示される画面の一例を示す図である。
【図３１】本発明の第２の実施形態のサービス提供者探索方法を説明するために、タクシー要求者とタクシー１〜３の位置関係を示す図である。
【符号の説明】
１ 意味情報ネットワーク（ＳＩＯＮ）
２ 端末
１０ 意味情報ネットワーク
２１ 送信端末
２２ 受信端末
３１〜３３ タクシー運転手の携帯端末
４０ タクシー要求者の携帯端末
７０１〜７０６ ステップ
８０１〜８０６ ステップ
ＳＩ−ＳＷ 意味情報スイッチ
ＳＩ−Ｒ 意味情報ルータ
ＳＩ−ＧＷ 意味情報ゲートウェイ
ＥＰＯ イベントプレースオブジェクト
ＳＬＯ シェアードリンクオブジェクト
ＦＡ フェデレーションエージェント
【特許請求の範囲】
【請求項１】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス提供者の端末が、イベントとして送信された前記サービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報を含めて前記サービス要求者の携帯端末へ送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきた応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項２】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス提供者の端末が、前記サービス要求者の携帯端末からイベントとして送信されたサービスの提供を希望する旨を通知するためのサービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報を含めて前記サービス要求者の携帯端末へ送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項３】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきたサービス要求を受信した旨の応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項４】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス提供者の端末が、イベントとして送信されたサービスの提供を希望する旨を通知するためのサービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置および目的地に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報を含めて前記サービス要求者の携帯端末へ送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項５】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきたサービス要求を受信した旨の応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項６】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス提供者の端末が、イベントとして送信された前記サービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置および目的地に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報を含めて前記サービス要求者の携帯端末へ送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきた応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項７】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして送信するステップと、前記サービス提供者の端末が、イベントとして送信された前記サービス要求を受信し、サービスを提供するサービス要求者を前記サービス要求者の位置および目的地に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報および前記目的地の情報から算出したサービス料金の情報を含めて前記サービス要求者の携帯端末へ送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきた応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置およびサービス料金に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項８】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス提供者の端末が、イベントとして送信されたサービスの提供を希望する旨を通知するためのサービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置および目的地に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報および前記目的地の情報から算出したサービス料金の情報を含めて前記サービス要求者の携帯端末へ送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項９】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきたサービス要求を受信した旨の応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置およびサービス料金に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項１０】 前記サービス提供者がタクシー運転手であり、前記サービス要求者がタクシーの乗車を希望するタクシー要求者である請求項１から９のいずれか１項記載の意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項１１】 前記位置情報取得手段が、ＧＰＳ受信機である請求項１から１０のいずれか１項記載の意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項１２】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索システムであって、現在の位置を位置情報として取得する第１の位置情報取得手段を有し、前記第１の位置情報取得手段により取得された位置情報をフィルタとして設定し、前記サービス要求者の携帯端末からイベントとして送信されたサービス要求を前記意味情報ネットワークから受信すると、サービスを提供するサービス要求者をサービス要求者の位置に基づいて決定し、前記サービス要求を受信した旨の応答を、前記第１の位置情報取得手段により取得された位置情報を含めて、前記サービス要求者の携帯端末へ送信するサービス提供者の端末と、現在の位置を位置情報として取得する第２の位置情報取得手段を有し、サービスの提供を希望する旨を通知するためのサービス要求を、前記第２の位置情報取得手段により取得された位置情報を含めて前記イベントとして前記意味情報ネットワークに送信し、前記サービス提供者の端末から送信されてきた応答を受信すると、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するサービス要求者の携帯端末とから構成される、意味情報ネットワークを用いた移動するサービス提供者探索システム。
【請求項１３】 データをイベントとして送信し、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定されている複数の端末とから構成される意味情報ネットワークに対して、データをイベントとして送信する送信端末であって、現在の位置を位置情報として取得する位置情報取得手段を有し、サービスの提供を希望する旨を通知するためのサービス要求を、前記位置情報取得手段により取得された位置情報を含めて前記イベントとして前記意味情報ネットワークに送信し、サービス提供者の端末から送信されてきた応答を受信すると、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信する送信端末。
【請求項１４】 送信端末からイベントとして送信されたデータを、意味情報ネットワークを介して選択的に受信するためにイベントのタイプと取得条件とからなるフィルタが設定されている受信端末であって、現在の位置を位置情報として取得する位置情報取得手段を有し、前記位置情報取得手段により取得された位置情報をフィルタとして設定し、サービス要求者の携帯端末からイベントとして送信されたサービス要求を前記意味情報ネットワークから受信すると、サービスを提供するサービス要求者をサービス要求者の位置に基づいて決定し、前記サービス要求を受信した旨の応答を、前記第１の位置情報取得手段により取得された位置情報を含めて、前記サービス要求者の携帯端末へ送信する受信端末。
【請求項１５】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索システムであって、現在の位置を位置情報として取得する第１の位置情報取得手段を有し、前記第１の位置情報取得手段により取得された位置情報をフィルタとして設定し、前記サービス要求者の携帯端末からイベントとして送信されたサービス要求を前記意味情報ネットワークから受信すると、サービスを提供するサービス要求者をサービス要求者の位置および目的地に基づいて決定し、前記サービス要求を受信した旨の応答を、前記第１の位置情報取得手段により取得された位置情報を含めて、前記サービス要求者の携帯端末へ送信するサービス提供者の端末と、現在の位置を位置情報として取得する第２の位置情報取得手段を有し、サービスの提供を希望する旨を通知するためのサービス要求を、前記第２の位置情報取得手段により取得された位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信し、前記サービス提供者の端末から送信されてきた応答を受信すると、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するサービス要求者の携帯端末とから構成される、意味情報ネットワークを用いた移動するサービス提供者探索システム。
【請求項１６】 データをイベントとして送信し、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定されている複数の端末とから構成される意味情報ネットワークに対して、データをイベントとして送信する送信端末であって、現在の位置を位置情報として取得する位置情報取得手段を有し、サービスの提供を希望する旨を通知するためのサービス要求を、前記位置情報取得手段により取得された位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信し、サービス提供者の端末から送信されてきた応答を受信すると、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信する送信端末。
【請求項１７】 送信端末からイベントとして送信されたデータを、意味情報ネットワークを介して選択的に受信するためにイベントのタイプと取得条件とからなるフィルタが設定されている受信端末であって、現在の位置を位置情報として取得する位置情報取得手段を有し、前記位置情報取得手段により取得された位置情報をフィルタとして設定し、サービス要求者の携帯端末からイベントとして送信されたサービス要求を前記意味情報ネットワークから受信すると、サービスを提供するサービス要求者をサービス要求者の位置および目的地に基づいて決定し、前記サービス要求を受信した旨の応答を、前記第１の位置情報取得手段により取得された位置情報を含めて、前記サービス要求者の携帯端末へ送信する受信端末。
【請求項１８】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索システムであって、現在の位置を位置情報として取得する第１の位置情報取得手段を有し、前記第１の位置情報取得手段により取得された位置情報をフィルタとして設定し、前記サービス要求者の携帯端末からイベントとして送信されたサービス要求を前記意味情報ネットワークから受信すると、サービスを提供するサービス要求者をサービス要求者の位置および目的地に基づいて決定し、前記サービス要求を受信した旨の応答を、前記第１の位置情報取得手段により取得された位置情報および前記目的地の情報から算出したサービス料金の情報を含めて、前記サービス要求者の携帯端末へ送信するサービス提供者の端末と、現在の位置を位置情報として取得する第２の位置情報取得手段を有し、サービスの提供を希望する旨を通知するためのサービス要求を、前記第２の位置情報取得手段により取得された位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信し、前記サービス提供者の端末から送信されてきた応答を受信すると、サービスを受けるサービス提供者を前記サービス提供者の端末の位置およびサービス料金に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するサービス要求者の携帯端末とから構成される、意味情報ネットワークを用いた移動するサービス提供者探索システム。
【請求項１９】 データをイベントとして送信し、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定されている複数の端末とから構成される意味情報ネットワークに対して、データをイベントとして送信する送信端末であって、現在の位置を位置情報として取得する位置情報取得手段を有し、サービスの提供を希望する旨を通知するためのサービス要求を、前記位置情報取得手段により取得された位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信し、サービス提供者の端末から送信されてきた応答を受信すると、サービスを受けるサービス提供者を前記サービス提供者の端末の位置およびサービス料金に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信する送信端末。
【請求項２０】 送信端末からイベントとして送信されたデータを、意味情報ネットワークを介して選択的に受信するためにイベントのタイプと取得条件とからなるフィルタが設定されている受信端末であって、現在の位置を位置情報として取得する位置情報取得手段を有し、前記位置情報取得手段により取得された位置情報をフィルタとして設定し、サービス要求者の携帯端末からイベントとして送信されたサービス要求を前記意味情報ネットワークから受信すると、サービスを提供するサービス要求者をサービス要求者の位置および目的地に基づいて決定し、前記サービス要求を受信した旨の応答を、前記第１の位置情報取得手段により取得された位置情報および前記目的地の情報から算出したサービス料金の情報を含めて、前記サービス要求者の携帯端末へ送信する受信端末。
【請求項２１】 前記サービス提供者がタクシー運転手であり、前記サービス要求者がタクシーの乗車を希望するタクシー要求者である請求項１２、１５および１８のいずれか１項記載の意味情報ネットワークを用いた移動するサービス提供者探索システム。
【請求項２２】 前記第１および第２の位置情報取得手段が、ＧＰＳ受信機である請求項１２、１５、１８および２１のいずれか１項記載の意味情報ネットワークを用いた移動するサービス提供者探索システム。
【請求項１】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス提供者の端末が、イベントとして送信された前記サービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報を含めて前記サービス要求者の携帯端末へ送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきた応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項２】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス提供者の端末が、前記サービス要求者の携帯端末からイベントとして送信されたサービスの提供を希望する旨を通知するためのサービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報を含めて前記サービス要求者の携帯端末へ送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項３】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきたサービス要求を受信した旨の応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項４】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス提供者の端末が、イベントとして送信されたサービスの提供を希望する旨を通知するためのサービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置および目的地に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報を含めて前記サービス要求者の携帯端末へ送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項５】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきたサービス要求を受信した旨の応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項６】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信するステップと、前記サービス提供者の端末が、イベントとして送信された前記サービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置および目的地に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報を含めて前記サービス要求者の携帯端末へ送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきた応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項７】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして送信するステップと、前記サービス提供者の端末が、イベントとして送信された前記サービス要求を受信し、サービスを提供するサービス要求者を前記サービス要求者の位置および目的地に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報および前記目的地の情報から算出したサービス料金の情報を含めて前記サービス要求者の携帯端末へ送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきた応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置およびサービス料金に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項８】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス提供者の端末に設けられている位置情報取得手段により、当該サービス提供者の端末の位置情報を取得し、該位置情報をフィルタとして設定するステップと、前記サービス提供者の端末が、イベントとして送信されたサービスの提供を希望する旨を通知するためのサービス要求を前記意味情報ネットワークから受信し、サービスを提供するサービス要求者を前記サービス要求者の位置および目的地に基づいて決定し、サービス要求を受信した旨の応答を、サービスを提供することを決定した当該サービス要求者の携帯端末に対して、前記サービス提供者の端末の位置情報および前記目的地の情報から算出したサービス料金の情報を含めて前記サービス要求者の携帯端末へ送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項９】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索方法であって、前記サービス要求者の携帯端末に設けられている位置情報所得手段により、当該サービス要求者の携帯端末の位置情報を取得するステップと、前記サービス要求者の携帯端末から、サービスの提供を希望する旨を通知するためのサービス要求を、前記サービス要求者の携帯端末の位置情報および目的地の情報を含めて前記イベントとして送信するステップと、前記サービス要求者の携帯端末が、前記サービス提供者から送信されてきたサービス要求を受信した旨の応答を受信し、サービスを受けるサービス提供者を前記サービス提供者の端末の位置およびサービス料金に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するステップとを有する、意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項１０】 前記サービス提供者がタクシー運転手であり、前記サービス要求者がタクシーの乗車を希望するタクシー要求者である請求項１から９のいずれか１項記載の意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項１１】 前記位置情報取得手段が、ＧＰＳ受信機である請求項１から１０のいずれか１項記載の意味情報ネットワークを用いた移動するサービス提供者探索方法。
【請求項１２】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索システムであって、現在の位置を位置情報として取得する第１の位置情報取得手段を有し、前記第１の位置情報取得手段により取得された位置情報をフィルタとして設定し、前記サービス要求者の携帯端末からイベントとして送信されたサービス要求を前記意味情報ネットワークから受信すると、サービスを提供するサービス要求者をサービス要求者の位置に基づいて決定し、前記サービス要求を受信した旨の応答を、前記第１の位置情報取得手段により取得された位置情報を含めて、前記サービス要求者の携帯端末へ送信するサービス提供者の端末と、現在の位置を位置情報として取得する第２の位置情報取得手段を有し、サービスの提供を希望する旨を通知するためのサービス要求を、前記第２の位置情報取得手段により取得された位置情報を含めて前記イベントとして前記意味情報ネットワークに送信し、前記サービス提供者の端末から送信されてきた応答を受信すると、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するサービス要求者の携帯端末とから構成される、意味情報ネットワークを用いた移動するサービス提供者探索システム。
【請求項１３】 データをイベントとして送信し、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定されている複数の端末とから構成される意味情報ネットワークに対して、データをイベントとして送信する送信端末であって、現在の位置を位置情報として取得する位置情報取得手段を有し、サービスの提供を希望する旨を通知するためのサービス要求を、前記位置情報取得手段により取得された位置情報を含めて前記イベントとして前記意味情報ネットワークに送信し、サービス提供者の端末から送信されてきた応答を受信すると、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信する送信端末。
【請求項１４】 送信端末からイベントとして送信されたデータを、意味情報ネットワークを介して選択的に受信するためにイベントのタイプと取得条件とからなるフィルタが設定されている受信端末であって、現在の位置を位置情報として取得する位置情報取得手段を有し、前記位置情報取得手段により取得された位置情報をフィルタとして設定し、サービス要求者の携帯端末からイベントとして送信されたサービス要求を前記意味情報ネットワークから受信すると、サービスを提供するサービス要求者をサービス要求者の位置に基づいて決定し、前記サービス要求を受信した旨の応答を、前記第１の位置情報取得手段により取得された位置情報を含めて、前記サービス要求者の携帯端末へ送信する受信端末。
【請求項１５】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索システムであって、現在の位置を位置情報として取得する第１の位置情報取得手段を有し、前記第１の位置情報取得手段により取得された位置情報をフィルタとして設定し、前記サービス要求者の携帯端末からイベントとして送信されたサービス要求を前記意味情報ネットワークから受信すると、サービスを提供するサービス要求者をサービス要求者の位置および目的地に基づいて決定し、前記サービス要求を受信した旨の応答を、前記第１の位置情報取得手段により取得された位置情報を含めて、前記サービス要求者の携帯端末へ送信するサービス提供者の端末と、現在の位置を位置情報として取得する第２の位置情報取得手段を有し、サービスの提供を希望する旨を通知するためのサービス要求を、前記第２の位置情報取得手段により取得された位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信し、前記サービス提供者の端末から送信されてきた応答を受信すると、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するサービス要求者の携帯端末とから構成される、意味情報ネットワークを用いた移動するサービス提供者探索システム。
【請求項１６】 データをイベントとして送信し、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定されている複数の端末とから構成される意味情報ネットワークに対して、データをイベントとして送信する送信端末であって、現在の位置を位置情報として取得する位置情報取得手段を有し、サービスの提供を希望する旨を通知するためのサービス要求を、前記位置情報取得手段により取得された位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信し、サービス提供者の端末から送信されてきた応答を受信すると、サービスを受けるサービス提供者を前記サービス提供者の端末の位置に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信する送信端末。
【請求項１７】 送信端末からイベントとして送信されたデータを、意味情報ネットワークを介して選択的に受信するためにイベントのタイプと取得条件とからなるフィルタが設定されている受信端末であって、現在の位置を位置情報として取得する位置情報取得手段を有し、前記位置情報取得手段により取得された位置情報をフィルタとして設定し、サービス要求者の携帯端末からイベントとして送信されたサービス要求を前記意味情報ネットワークから受信すると、サービスを提供するサービス要求者をサービス要求者の位置および目的地に基づいて決定し、前記サービス要求を受信した旨の応答を、前記第１の位置情報取得手段により取得された位置情報を含めて、前記サービス要求者の携帯端末へ送信する受信端末。
【請求項１８】 データをイベントとして送信する送信端末と、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定される受信端末とから構成される意味情報ネットワークを用いて、サービス要求者が移動しながらサービスの提供を行っているサービス提供者を探索するための、意味情報ネットワークを用いた移動するサービス提供者探索システムであって、現在の位置を位置情報として取得する第１の位置情報取得手段を有し、前記第１の位置情報取得手段により取得された位置情報をフィルタとして設定し、前記サービス要求者の携帯端末からイベントとして送信されたサービス要求を前記意味情報ネットワークから受信すると、サービスを提供するサービス要求者をサービス要求者の位置および目的地に基づいて決定し、前記サービス要求を受信した旨の応答を、前記第１の位置情報取得手段により取得された位置情報および前記目的地の情報から算出したサービス料金の情報を含めて、前記サービス要求者の携帯端末へ送信するサービス提供者の端末と、現在の位置を位置情報として取得する第２の位置情報取得手段を有し、サービスの提供を希望する旨を通知するためのサービス要求を、前記第２の位置情報取得手段により取得された位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信し、前記サービス提供者の端末から送信されてきた応答を受信すると、サービスを受けるサービス提供者を前記サービス提供者の端末の位置およびサービス料金に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信するサービス要求者の携帯端末とから構成される、意味情報ネットワークを用いた移動するサービス提供者探索システム。
【請求項１９】 データをイベントとして送信し、イベントとして送信された前記データを選択的に受信するために、イベントのタイプと取得条件とからなるフィルタが設定されている複数の端末とから構成される意味情報ネットワークに対して、データをイベントとして送信する送信端末であって、現在の位置を位置情報として取得する位置情報取得手段を有し、サービスの提供を希望する旨を通知するためのサービス要求を、前記位置情報取得手段により取得された位置情報および目的地の情報を含めて前記イベントとして前記意味情報ネットワークに送信し、サービス提供者の端末から送信されてきた応答を受信すると、サービスを受けるサービス提供者を前記サービス提供者の端末の位置およびサービス料金に基づいて決定し、サービスを受けることを決定した旨の通知をサービスを受けることを決定した当該サービス提供者の端末に対して送信する送信端末。
【請求項２０】 送信端末からイベントとして送信されたデータを、意味情報ネットワークを介して選択的に受信するためにイベントのタイプと取得条件とからなるフィルタが設定されている受信端末であって、現在の位置を位置情報として取得する位置情報取得手段を有し、前記位置情報取得手段により取得された位置情報をフィルタとして設定し、サービス要求者の携帯端末からイベントとして送信されたサービス要求を前記意味情報ネットワークから受信すると、サービスを提供するサービス要求者をサービス要求者の位置および目的地に基づいて決定し、前記サービス要求を受信した旨の応答を、前記第１の位置情報取得手段により取得された位置情報および前記目的地の情報から算出したサービス料金の情報を含めて、前記サービス要求者の携帯端末へ送信する受信端末。
【請求項２１】 前記サービス提供者がタクシー運転手であり、前記サービス要求者がタクシーの乗車を希望するタクシー要求者である請求項１２、１５および１８のいずれか１項記載の意味情報ネットワークを用いた移動するサービス提供者探索システム。
【請求項２２】 前記第１および第２の位置情報取得手段が、ＧＰＳ受信機である請求項１２、１５、１８および２１のいずれか１項記載の意味情報ネットワークを用いた移動するサービス提供者探索システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図１５】
【図７】
【図８】
【図１０】
【図１１】
【図１２】
【図１３】
【図１６】
【図９】
【図１４】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２５】
【図２４】
【図２６】
【図３０】
【図２７】
【図２８】
【図２９】
【図３１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図１５】
【図７】
【図８】
【図１０】
【図１１】
【図１２】
【図１３】
【図１６】
【図９】
【図１４】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２５】
【図２４】
【図２６】
【図３０】
【図２７】
【図２８】
【図２９】
【図３１】
【公開番号】特開２００２−１８３８７４（Ｐ２００２−１８３８７４Ａ）
【公開日】平成１４年６月２８日（２００２．６．２８）
【国際特許分類】
【出願番号】特願２０００−３８００８６（Ｐ２０００−３８００８６）
【出願日】平成１２年１２月１４日（２０００．１２．１４）
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り 平成１２年９月２５日 社団法人電子情報通信学会発行の「電子情報通信学会 論文誌 ＶＯＬ．Ｊ８３−Ｄ−▲Ｉ▼ ＮＯ．９」に発表
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成１４年６月２８日（２００２．６．２８）
【国際特許分類】
【出願日】平成１２年１２月１４日（２０００．１２．１４）
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り 平成１２年９月２５日 社団法人電子情報通信学会発行の「電子情報通信学会 論文誌 ＶＯＬ．Ｊ８３−Ｄ−▲Ｉ▼ ＮＯ．９」に発表
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]