【課題】分散型ネットワークのコア内のルータにおいて、サービス品質保証を行ったうえで、例えばビデオ、音楽、ソフトウェア等のデジタルコンテンツの配信サービスを提供する。
【解決手段】ルータ１２は、コンテンツの購読予約に対応するフィルタを保存する。ルータ１２は、パケットを受け取ると、属性を含むパケットのペイロードセクションを検査し、コンテンツの購読予約のためのフィルタをこれらの属性に適用する。属性がフィルタを満たす場合、パケットは、次のリンクにルーティングされる。属性がフィルタを満たさない場合、ルータは、パケットを削除する。これらの経路決定は、ネットワークコア１０において、ルータ１２間に配信される。ルータ１２は、データをネットワークコア１０においてローカルにキャッシングする。

【発明の詳細な説明】
【関連出願】
【０００１】
本発明は、引用により本願に援用される、２００２年７月８日に出願された、米国仮出願番号６０／３９４，６３１号、発明の名称「サービス品質管理のためのペイロード検査によるパケットルーティング（Packet Routing Via Payload Inspection for Quality of Service Management）」に対する優先権を主張する。また、本出願は、２００２年７月１９日に出願され、引用により本願に援用される、米国特許出願番号１０／１９９，３５６号、発明の名称「ペイロード検査によるパケットルーティング（Packet Routing Via Payload Inspection）」、米国特許出願番号１０／１９９，３６８号、発明の名称「チャンネルを用いたルータにおけるコンテンツベースの経路選択及びフィルタリングの用の方法及び装置（Method And Apparatus For Content-Based Routing And Filtering At Routers Using Channels）」、米国特許出願番号１０／１９９，４３９号、発明の名称「ネットワークを介して、論理関数を送受する方法（Method for Sending And Receiving A Boolean Function Over A Network）」、米国特許出願番号１０／１９９，３６９号、発明の名称「ネットワークを介して評価、変更、再利用及び配信を可能にするのための論理関数を保存する方法（Method For Storing Boolean Functions To Enable Evaluation, Modification, Reuse, And Delivery Over A Network）」、米国特許出願番号１０／１９９，３８８号、発明の名称「接続ベースのルーティングにおける可変長フィールドを照合するワイルドカードを効率的な実行する方法（Efficient Implementation of Wildcard Matching On Variable-Sized Fields In Connect-Based Routing）」の一部継続出願である。
【０００２】
また、上述した出願の一部継続出願である、２００３年３月２８日に出願された、米国特許出願番号１０／４００，６７１号、発明の名称「信頼性が低いネットワークにおける信頼性が高い発行−購読システムアーキテクチャ（Reliable Publish/Subscribe System Architecture over Unreliable Networks）」、米国特許出願番号１０／４００，４６５号、発明の名称「コンパクトフィルタストレージ及びオフラインの事前計算を用いたコンテンツベースのパケットルーティングのための方法及び装置（Method and Apparatus for Content-Based Packet Routing Using Compact Filter Storage and Off-Line Pre-computation）」、米国特許出願番号１０／４００，４５３号、発明の名称「発行−購読ネットワークにおいて、問合せ−応答インタラクションを実行する方法及び装置（Method and Apparatus for Implementing Query-Response Interactions in a Publish-Subscribe Network）」、米国特許出願番号１０／４００，４６２号、発明の名称「持続的で信頼できるメッセージ配信を実行する方法及び装置（Method and Apparatus for Implementing Persistent and Reliable Message DELIVERY）」、米国特許出願番号１０／４００，４４４号、発明の名称「発行−購読ネットワークにおいて、コンテンツベースを伝搬する方法及び装置（Method and Apparatus for Propagating Content Filters for a Publish-Subscribe Network）」も引用により本願に援用されるものとする。
【技術分野】
【０００３】
本発明は、ネットワークコアにおいて、警告サービス（alert service）を提供するためのパケット内のペイロードの検査（inspection）に基づいて、パケットをルーティングする方法及び装置に関する。
【背景技術】
【０００４】
ネットワークの帯域幅は、指数関数的に拡大している。しかしながら、ネットワークインフラストラクチャ（ルータ、サーバ、デーモン、プロトコル等を含む。）は、未だに比較的古い技術を用いている。この結果、インターネットアプリケーション及びネットワークルータは、帯域幅の拡大の速度に対応することができない。同時に、ネットワークに対応する機器及びアプリケーションも増加している。これらの機器及びアプリケーションによるネットワークノードへの負荷は、著しく大きくなっている。また、ネットワーク負荷及びアプリケーションの数の増加のために、ネットワークアプリケーションを実行し、保守するための複雑性がより高まっている。この結果、ネットワークの帯域幅の増加、及びネットワーク機器及びアプリケーションの偏在的な（ubiquitous）使用により、古いネットワークインフラストラクチャにおけるデータの経路選択及び伝送に、特に、コンテンツを購読者（subscriber）に発行（publishing）するときに、問題が生じている。
【０００５】
ネットワークにおいてサーバからクライアント装置に情報をプッシュするモデルは、発行−購読型（publish-subscribe style）と呼ばれる。このモデルでは、サーバは、どのクライアントが情報に興味を持ち、又はクライアントがネットワーク内のどこに位置するかに拘わらず、その情報の単純化された発行者装置（publisher）として機能する。クライアント装置は、情報の購読者装置（subscriber）となり、潜在的には、その情報がネットワークのどこで利用可能となったかに関する詳細に拘わらず、その情報が利用可能になると、その情報が配信される。そして、ネットワークは、発行された情報を購読者装置に効率的にルーティングし、情報を能動的な購読に適合させ、これらの処理を発行者装置及び購読者装置に対して透過的な方法で実行する責務を負う。
【０００６】
発行−購読モデルにおいては、サーバの構成が著しく簡略化されるので、大型のサーバ（heavyweight server）と小型のクライアント（lightweight client）といった区別はなくなり、これらは、発行者装置、購読者装置又はその両方にもなり得るピアという呼称に統合される。様々な種類のアプリケーションは、ピア間の発行−購読型のインタラクションに近い性質を兼ね備えている。これらの多くのアプリケーションの基底に存在する課題では、発行及び購読される情報は、イベントの形式で提供される。例えば、投資家が株式を購入又は売却することにより、株価が変動する。また、高速道路上で交通事故が発生すると、交通が渋滞する。ソフトウェアシステムのセキュリティホールが発見されると、ソフトウェアのユーザのためにパッチが開発される。インターネットゲームのプレーヤが武器を使用すると、他のプレーヤのアバタが死ぬ。これらの例示的な現象は、全て、多数の購読者が潜在的に興味を有するイベントであり、このようなイベントが生じたことをこれらの購読者に通知するために、ネットワーク内で伝搬（propagate）させることができる。すなわち、イベントは、ある時刻に、ネットワーク上のある場所で発生した、潜在的に興味が持たれる何かに関する、自己充足的（self-contained）で簡潔な情報片（succinct piece of information）である。
【０００７】
発行−購読モデルにおいて、発行されたコンテンツをどこに送信するかをネットワークに指示するための経路決定（routing decision）は、通常、サーバ又は発行者装置が行う。発行者装置は、それが発行したコンテンツに関する購読予約（subscription）を保存している。発行者装置は、新たなコンテンツを受信又は生成すると、そのコンテンツと各購読予約とを比較し、何らかの一致がないかを調べる。コンテンツ（イベント）がいずれかの購読予約を満たす場合、発行者装置は、ネットワークを介して、対応する購読者装置にコンテンツをプッシュする。この従来の発行−購読モデルでは、特に、より多くの機器がネットワークに対応し、購読予約の数が増加すると、発行者装置に大きな負担がかかる。
【０００８】
インターネットにおける無数のアプリケーションの集中度が高まることにより、事象通知（event notification）を利用する可能性も無限になる。ここで、これらの可能性のために、経路決定を効率的に行い、イベントがいつ購読予約を充足するかを効率的に判定して、発行者装置の負担を軽減する手法を実現することが必要である。したがって、普遍的で持続的な事象通知サービス（event notification service）を実現すれば、インターネットアプリケーション並びに他のアプリケーションに、及びそれらの実行に大きな付加価値を与えることができる。
【発明の概要】
【課題を解決するための手段】
【０００９】
本発明に係るルーティング方法は、プロセッサによって実行され、ネットワークにおいて、サービス品質保証に基づいてパケットをルーティングするルーティング方法において、ヘッダ部と、ペイロード部とを有するパケットを受信する受信ステップと、ネットワークコアにおいて、パケットをルーティングする前に、パケットのペイロード部を検査する検査ステップと、パケットの確保された帯域幅に関するサービス品質保証を判定する判定ステップと、検査及びサービス品質保証に基づいて、パケットを選択的にルーティングするルーティングステップとを有する。検査ステップは、ペイロード部からデータ属性を抽出するステップと、抽出したデータ属性を２つ以上の属性フィルタと比較するステップと、２つ以上の属性フィルタのそれぞれが満たされる場合、１組の機能を実行するステップとを有する。各属性フィルタは、購読者が、発行者から受信した興味があるイベントの組を記述している。
【００１０】
本発明に係るルーティング方法は、プロセッサによって実行され、ネットワークにおいて、メッセージをルーティングするルーティング方法において、ヘッダ部と、少なくとも１つの主語と、複数のデータ属性とを有するメッセージを受信する受信ステップと、メッセージから、主語及びデータ属性を読み出す主語／属性読出ステップと、主語に基づいて、複数の属性フィルタを指定する購読予約を読み出す購読予約読出ステップと、メッセージの確保された帯域幅に関するサービス品質保証を判定するステップと、メッセージをどのようにルーティングするかを決定するために、ネットワークコアにおいて、購読予約にデータ属性を適用する適用ステップと、適用及びサービス品質保証に基づいて、メッセージを選択的にルーティングするステップとを有する。適用ステップは、パケットからデータ属性を抽出するステップと、抽出したデータ属性を２つ以上の属性フィルタと比較するステップと、２つ以上の属性フィルタのそれぞれが満たされる場合、１組の機能を実行するステップとを有する。各属性フィルタは、購読者が、発行者から受信した興味があるイベントの組を記述している。
【００１１】
本発明に係るルーティング装置は、プロセッサ及びメモリを有し、ネットワークにおいて、サービス品質保証に基づいてパケットをルーティングするルーティング装置において、ヘッダ部と、ペイロード部とを有するパケットを受信する受信手段と、ネットワークコアにおいて、上記パケットのペイロード部を検査する検査手段と、パケットの確保された帯域幅に関する上記サービス品質保証を判定する判定手段と、検査手段及び判定手段による判定の結果得られた検査結果及びサービス品質保証に基づいて、パケットを選択的にルーティングするルーティング手段とを備える。検査手段は、ペイロード部からデータ属性を抽出し、抽出したデータ属性を２つ以上の属性フィルタと比較し、２つ以上の属性フィルタのそれぞれが満たされる場合、パケットをどのようにルーティングするかを決定し、各属性フィルタは、購読者が、発行者から受信した興味があるイベントの組を記述している。
【００１２】
本発明に係るルーティング装置は、プロセッサ及びメモリを有し、ネットワークにおいて、メッセージをルーティングするルーティング装置において、ヘッダ部と、少なくとも１つの主語と、複数のデータ属性とを有するメッセージを受信する受信手段と、メッセージから、主語及びデータ属性を読み出す主語／属性読出手段と、主語に基づいて、購読予約を読み出す購読予約読出手段と、メッセージを購読者装置にどのようにルーティングするかを決定するために、ネットワークコアにおいて、購読予約を複数のフィルタに照合する照合手段と、パケットの確保された帯域幅に関するサービス品質保証を判定する判定手段とを備える。主語／属性読出手段は、購読予約に対応した複数のフィルタを読み出す手段を備え、各フィルタは、購読者が、発行者から受信した興味があるイベントの組を記述している。
【００１３】
本発明に係るルーティング／キャッシング方法は、マルチキャストネットワークにおいて、データのパケットをルーティング及びキャッシングするルーティング／キャッシング方法において、ヘッダ部と、ペイロード部とを有するパケットを受信する受信ステップと、パケットを購読者装置にどのようにルーティングするかを決定するために、ネットワークコアにおいて、パケットのペイロード部を検査する検査ステップと、検査に基づいて、パケットを選択的にルーティングするルーティングステップと、パケットに対応するチャンネルを判定するステップと、チャンネルのチャンネル特性を読み出すステップと、チャンネル特性から、チャンネルが持続的なチャンネルであるか否かを判定するステップと、チャンネルが持続的なチャンネルである場合、パケットからデータを、ネットワークコアのコアルーティングノードで局所的にキャッシングするステップとを有する。コアルーティングノードは、エッジルーティングノードの上流の購読者装置から離れる方向に位置する。
【００１４】
本発明に係るネットワークは、データのパケットをルーティング及びキャッシングするネットワークにおいて、ヘッダ部と、ペイロード部とを有するパケットを受信して、ルーティングするエッジルーティングノードであって、受信したパケットをルーティングするインテリジェントルータを含むエッジルーティングノードと、ネットワークコア内に位置するコアルーティングノードと、コアルーティングノード内に位置し、インテリジェントルータに動作可能に接続されたキャッシュマネージャとを備える。インテリジェントルータは、パケットを購読者装置にどのようにルーティングするかを決定するために、ネットワークコアにおいて、パケットのペイロード部を検査する命令と、検査に基づいて、パケットを選択的にルーティングする命令とを有し、キャッシュマネージャは、パケットのそれぞれに対応するチャンネルを判定する命令と、チャンネルのチャンネル特性を読み出す命令と、チャンネル特性から、各チャンネルが持続的なチャンネルであるか否かを判定する命令と、チャンネルが持続的なチャンネルである場合、対応するパケットからデータを、コアルーティングノードのローカルキャッシュで局所的にキャッシングする命令とを有する。コアルーティングノードは、エッジルーティングノードの上流の購読者装置から離れる方向に位置する。
【００１５】
本発明に係るルーティング／キャッシング装置は、マルチキャストネットワークにおいて、データのパケットをルーティング及びキャッシングするルーティング／キャッシング装置において、複数のプロセッサと、複数のプロセッサによって実行される命令とを備える。命令は、ヘッダ部と、ペイロード部とを有するパケットを受信する命令と、パケットを購読者装置にどのようにルーティングするかを決定するために、ネットワークコアにおいて、パケットのペイロード部を検査する命令と、検査に基づいて、パケットを選択的にルーティングする命令と、パケットに対応するチャンネルを判定する命令と、チャンネルのチャンネル特性を読み出す命令と、チャンネル特性から、上記チャンネルが持続的なチャンネルであるか否かを判定する命令と、チャンネルが持続的なチャンネルである場合、パケットからデータを、ネットワークコアのコアルーティングノードで局所的にキャッシングする命令とを有する。コアルーティングノードは、エッジルーティングノードの上流の購読者装置から離れる方向に位置する。
【図面の簡単な説明】
【００１６】
【図１】ネットワークコアにおけるこのインテリジェントルーティングを概念的に示すブロック図である。
【図２】発行者装置及び購読者装置用のインテリジェントルータを示すネットワーク図である。
【図３】インテリジェントルータ及びバックボーンルータの例示的なネットワークインフラストラクチャの構成を示す図である。
【図４】インテリジェントルータのハードウェア構成を示す図である。
【図５】発行者装置及び購読者装置の構成を示す図である。
【図６】インテリジェントルータのチャンネルマネージャの構成を示す図である。
【図７】インテリジェントルータを有するネットワークに接続するためのユーザ装置のソフトウェアコンポーネントの構成を示す図である。
【図８】インテリジェントルータのためのソフトウェアコンポーネントの構成を示す図である。
【図９】メッセージのパケット構造を示す図である。
【図１０】発行方法のフローチャートである。
【図１１】購読方法のフローチャートである。
【図１２】チャンネル及び購読者装置の画面を示す図である。
【図１３】コンテンツベースの経路選択方法のフローチャートである。
【図１４】キャッシング方法のフローチャートである。
【図１５】キャッシュインデックスを示す図である。
【図１６】送信メッセージのためのエージェント方法のフローチャートである。
【図１７】受信メッセージのためのエージェント方法のフローチャートである。
【図１８】メッセージの符号化の具体例を説明する図である。
【図１９】購読予約を保存するためのデータベース構造を示す図である。
【図２０】ワイルドカード方法のフローチャートである。
【図２１】デジタルビデオ監視システムの構成を示す図である。
【図２２】２段階法による、デジタルビデオ監視システムのためにプロキシを示す図である。
【図２３】デジタルコンテンツ配信のためのアーキテクチャを示す図である。
【図２４】デジタルコンテンツ配信のための第１の段階のアーキテクチャを示す図である。
【図２５】デジタルコンテンツ配信のための第２の段階のアーキテクチャを示す図である。
【図２６】サービス品質管理のための複数のアウトリンクを示す図である。
【図２７】サービス品質管理のための単一のアウトリンクを示す図である。
【図２８】ＩＳＰの外部におけるフィルタリング及びキャッシングを説明する図である。
【図２９】ネットワーク内のキャッシュを示す図である。
【図３０】上流ルータにおけるバックアップキャッシングを説明する図である。
【図３１】プロキシを有するキャッシュとルータのとの間のインタラクションを示す図である。
【図３２】購読予約に対するキャッシュの作成を説明する図である。
【図３３】インデックスツリーを示す図である。
【図３４】複数のキャッシュからの検索を示す図である。
【図３５】キャッシュマネージャと、システム内の他のモジュールとのインタラクションを示す図である。
【図３６】キャッシュのためのファイルディレクトリ構造を示す図である。
【発明を実施するための形態】
【００１７】
概観
インターネット規模又は他の分散ネットワーク規模においては、事象通知システム（event notification system）により、アプリケーションにおいて、強力で柔軟な発行−購読ネットワーク（publish-subscribe networking）が実現される。この事象通知システムでは、アプリケーションプログラムは、通知アプリケーションプログラムインタフェース（application program interface：以下、ＡＰＩという。）を用いて、ネットワーク内で発生するイベントに関する通知を発行し及び／又は通知を購読又は受信する。
【００１８】
この事象通知システムにおける通知には、主語（subject）が与えられており、主語は、文字列（string）、又は通知がカプセル化している情報の種類を分類する（classify）他のデータ構造として示される。また、通知には、その通知に特有の情報を含む１組の属性によって完結されている。例えば、アプリケーションは、subject quotes.nyse（ニューヨーク証券取引所における主語の株価）と、属性シンボル及び価格とを用いて、ニューヨーク証券取引所における取引に関する通知を発行してもよい。例えば、アプリケーションは、ＳＮＥ（ソニー株式会社（商標）の株価表示板のシンボル）に等しいシンボルと、８５．２５ドルの株価とを含む特定の属性値を有する個々の通知を発行する。通知の全ての属性ではなく、殆どの属性は、主語が同じファミリに関する全ての通知において見出されるという意味で、予め定義されている。なお、発行者は、イベント固有の情報を追加するために、通知毎に又は他の単位で、通知に任意の属性を加えることができる。したがって、一部又は全ての属性は、予め定義されている必要はない。
【００１９】
この事象通知システムでは、購読者は、主語又は全チャンネルの購読のみに制限されるわけではない。チャンネルについては、後に説明し、定義する。チャンネルは、例えば主語フィールド及び関連したサブフィールド（サブ主語）の１つ以上のレベルを指定する階層構造を含むことができる。したがって、購読者は、通知の属性に対して、コンテンツベースのフィルタを指定することによって、興味に応じてより精密に調整された表現を指定することができる。例えば、購読者は、ＳＮＥに等しいシンボルと、９０．００ドルより高い価格（例えば、購読者が所有している株式の売りの指値）とを有するsubject quotes.nyseに対する全ての通知を購読予約してもよい。購読予約に一致する全ての通知は、コールバック、あるいは購読者が購読予約を登録したときの又は他の時点における他の種類の機能によって、購読者に配信される。１つの購読予約は、複数のフィルタに分割することができる。
【００２０】
コールバックは、多くの計算（computation）を実行することができ、これらには、例えば端末機器にメッセージを書き込む又は電子メールを送信する等の単純な処理から、例えば株式の売却を開始する等のより複雑な処理、新たな発行−購読活動を開始する（例えば、既存の購読予約を７５．００ドルの買いの指値とする新たな購読予約に置き換え、又は購読者のポートフォリオが手直しされた新たな通知を発行する）等の更に複雑な処理までの処理が含まれる。
【００２１】
アプリケーションにおける発行及び購読活動は、例えば、エージェントによって支援してもよい。エージェントは、プロキシを使用することができ、又はプロキシによって実現することができる。エージェントは、それが用いられるときには、通知及び購読予約を出力するネットワーク接続性と、照合通知（matching notification）を購読者装置に入力する配信とを提供する。通知がネットワークに出されると、この事象通知システムのルータのネットワークは、その通知に購読予約が一致する全ての購読者装置に通知を伝搬（propagate）する。この処理を実現する一手法は、ネットワーク内の全ての点に通知を同報通信し、アプリケーションエージェントに、対応する購読者装置にその通知が関連するか否かを判定させる手法がある。しかしながら、これは必ずしも拡張性がある手法であるというわけではなく、通常、ネットワークは、特に多数の活発で冗長な購読者装置がある場合、メッセージトラヒックの負荷によって、急速に機能しなくなる（overwhelmed）。更に、帯域幅が十分な場合でさえも、購読者装置は、大量の通知を処理しきれなくなると考えられる。
【００２２】
本発明に基づくシステムの一例として示すネットワークは、非常に効率的に通知をルーティングする。まず、このネットワークは、マルチキャストルーティングを用いて、例えば、ネットワーク内の全てのリンクにおいて最大で１回、通知を伝搬させることができる。次に、このネットワークは、フィルタに対して多数の高度な最適化処理を採用して、通知の伝搬の回数を可能な限り削減することができる。
【００２３】
図１は、ネットワークコア１０におけるこのインテリジェントルーティングを概念的に示す図である。発行者装置１４は、エッジルータ（edge router）１６を介して、発行−購読ネットワークにおいて用いられているネットワークコア１０にメッセージのコンテンツを送信する。発行−購読ネットワークは、発行者装置１４から購読者装置２４にデータ又はコンテンツをルーティングするためのあらゆる種類のネットワークであってもよい。コンテンツは、ルータ間又は他の機器間の論理的接続を表す１つ以上のチャンネル１８を介して伝送される。ネットワークコア１０におけるインテリジェントルータ１２は、メッセージをルーティング又は転送するか否かを判定する。特に、インテリジェントルータ１２は、メッセージが購読者装置２４によって購読予約されているコンテンツを含んでいるか否かを判定することができる。
【００２４】
各購読予約は、主語フィルタ（subject filter）と属性フィルタ（attribute filter）とをカプセル化している。ルータは、主語フィルタを一致する主語の集合に拡張し、又は主語毎に属性フィルタを併合することができる。インテリジェントルータは、通知の主語に対して主語フィルタを評価し、通知における属性値に対して属性フィルタを評価する。主語フィルタの構文では、ワイルドカードを用いることができ、属性フィルタの構文では、論理式（Boolean expression）を用いることができ、これらについては、後に更に詳細に説明する。「フィルタ」という用語は、購読者装置が発行者装置から受信を望んでいる１組のイベントを意味する。経路選択規則（routing rule）は、フィルタから生成され、インテリジェントルータは、この規則を用いて経路決定を行う。
【００２５】
したがって、メッセージ２６がフィルタ集合の全部を充足していない場合、例えば、インテリジェントルータ１２は、メッセージ２６をドロップ（破棄）し、これは、メッセージ２６が転送されないことを意味する。主語フィルタ及び属性フィルタの評価に基づき、メッセージ２０がフィルタの集合の一部又は全部を充足していると判定された場合、例えば、インテリジェントルータ１２は、エッジルータ２２及び他の機器を介して、購読者装置にメッセージ２０をルーティング（転送）し、又は、一致したフィルタについて規定されている全ての経路選択及び／又は動作規則（action rule）に基づいて、インテリジェントルータ１２内でメッセージ２０に対する他の機能を実行する。検索は、フィルタの集合全体に対する処理が完了するまで、又は全ての規則に関する判定が得られるまで続けられ、どちらが最初であってもよい。この２つの条件のいずれか１つが満たされると終了する。
【００２６】
ネットワークコア内のこの種類のインテリジェントなコンテンツベースの経路選択は、例えば警告及び更新のためのリアルタイムデータ配信を実現する。警告のためのリアルタイムデータ配信の具体例としては、以下に限定されるものではないが、例えば、株価速報（stock quot）、交通情報、ニュース、旅行、天気、不正検出（fraud detection）、セキュリティ、テレマティックス、ファクトリオートメーション、サプライチェーン管理（supply chain management）及びネットワーク管理等がある。更新のためのリアルタイムデータ配信の具体例としては、以下に限定されるものではないが、例えば、ソフトウェアの更新、アンチウイルスの更新、映画及び音楽配信、ワークフロー、保管管理（storage management）及びキャッシュコンシステンシ（cache consistency）等がある。購読予約された情報を配信するシステムは、他の様々な分野に応用することができる。
【００２７】
表１は、フィルタ用の主語（subject）及び述語（predicate）によって保存される購読予約を示している。購読予約は、希望されれば、又は必要に応じて、ネットワークの如何なる場所に、あらゆる種類のデータ構造を用いて保存してもよい。後述するように、述語は、購読予約の構成要素である。購読予約は、如何なる形式で表現してもよく、その具体例を以下に示す。
【００２８】
【表１】

【００２９】
表２は、株価速報サーバ（quote server）用の発行及び購読予約の具体例を示している。この具体例は、説明を目的とする例示的な具体例に過ぎず、購読予約は、あらゆる種類のデータ又はコンテンツに対するあらゆる数の及び種類のパラメータを含むことができる。
【００３０】
【表２】

【００３１】
述語は、購読予約用の論理式を提供し、主語は、購読予約用のチャンネルの指標（indication）を提供する。購読予約は、他の様々な手法で表現することができる。論理式は、このような手法の一例であり、論理式を用いることにより、購読予約を主語フィルタと属性フィルタに容易に変換する機能を、コンテンツベースの経路選択に提供する。これに代えて、主語を参照することなく、購読予約を表現することもできるが、主語又はチャンネル（後に詳細に説明する。）を用いることにより、フィルタを解釈して、属性に適用するコンテキスト（context）を提供する。
【００３２】
経路決定は、ネットワークコアで行って、ネットワークを介して配信することができるので、発行者装置及び購読者装置の機器の負担を軽減し、ネットワーク効率を大幅に高めることができる。図１では、説明を目的として、単一の発行者装置１４、単一の購読者装置２４及び単一のインテリジェントルータ１２のみを示しているが、実際には、発行者装置、購読者装置及びインテリジェントルータは、それぞれ複数設けることができる。インテリジェントルータという用語は、ネットワークコア又は他の位置において、パケット又はメッセージのペイロードを検査することによって経路を決定する能力を有するルータ又は他のエンティティ（entity）を意味する。
【００３３】
ネットワークインフラストラクチャ
図２は、発行者装置及び購読者装置用のインテリジェントルータを示すネットワーク図である。例えば、チャンネルサービスを提供する経路選択エンティティ（以下、チャンネルサービスともいう。）３０は、後述するように、インテリジェントルータ３８、４０、４２、４４、４６、４８間でメッセージをルーティングするために、ネットワークインフラストラクチャ上に効果的に階層化されている。例えば、発行者装置３２は、概念的に、発行されたコンテンツの指標、例えばコンテンツを検索するためのポインタを受信するアプリケーション３４と、チャンネルサービス３０を介したネットワーク伝送のためにコンテンツを符号化するエージェント３６とを含む。論理的に互いに接続されたインテリジェントルータ３８、４０、４２、４４、４６、４８の集合は、購読予約の主語フィルタ及び属性フィルタから生成された経路選択規則を用いて、発行者装置３２からのコンテンツをルーティングする。複数のリンク３９、４１、４３、４５は、インテリジェントルータ３８、４０、４２、４４、４６、４８間を論理的に接続する。他のリンク３７、４７は、それぞれ、発行者装置３２とインテリジェントルータ３８間及び購読者装置５４とインテリジェントルータ４６間を論理的に接続する。購読者装置５４は、購読するコンテンツを検出して、受信するエージェント５０と、コンテンツを表示するアプリケーション５２とを備えている。
【００３４】
チャンネルは、例えば、分散方式によって実行される論理的なマルチキャスト接続の関連した集合を含むことができる。この例示的な実施例におけるチャンネルは、コンテンツを交換する発行者装置と購読者装置のコミュニティとして機能する論理的に関連したネットワークリソースの集合である。コンテンツは、チャンネル主語名前空間（channel subject namespace）に従って分類され、ネットワークリソースは、チャンネルマネージャ（channel manager）によって提供されるチャンネルサービス３０を介して、管理され、制御され、供給される。複数のチャンネルが同じネットワークリソースを共有してもよい。チャンネルは、非常に拡張性があるディレクトリサービス、例えば、以下に限定されるものではないが、発行者及び購読者の情報、認証（authentication）及び許可（authorization）情報、メッセージの種類、管理情報、会計及び課金情報（accounting and billing information）が含まれる。また、チャンネルは、例えば、キャッシングによる持続性（persistence through caching）、高速データ配信機構、セキュリティ、ユーザ及びネットワーク管理等を提供することができる。また、チャンネルは、他の如何なる目的にも利用することができる。
【００３５】
インテリジェントルータによるフィルタリングをネットワークコアで行って、経路決定をネットワーク内に配信することができる。更に、インテリジェントルータは、発行者装置又は購読者装置等のユーザ機器をネットワークコアに接続するエッジルータとして機能することができる。また、ネットワークに接続された同じ機器が、ネットワークにおける経路決定に基づいて、購読者装置にコンテンツをプッシュする発行者装置と、プッシュされたコンテンツを受信する購読者装置との両方として機能することができる。インテリジェントルータ及びチャンネルは、特定の実施例における必要又は要望に応じて、如何なる構成で接続してもよく、図２の構成は例示的に示しているに過ぎない。
【００３６】
図３は、インテリジェントルータ及び従来のバックボーンルータの例示的なネットワークインフラストラクチャの構成を示しており、チャンネルの論理的接続も示している。この実施例におけるインテリジェントルータ６１〜７０は、インターネット又は他の分散ネットワーク等のネットワークの既存のバックボーンルータを用いており、したがって、インテリジェントルータ６１〜７０は、バックボーンルータ上に効果的に階層化されている。この実施例では、インターネットサービスプロバイダ（Internet Service Provider：以下、ＩＳＰという。）ネットワーク５８、５９、６０は、メッセージ又はパケットの従来の経路選択を行う幾つかのバックボーンルータをそれぞれ備えている。複数のインテリジェントルータ６１〜７０は、ＩＳＰネットワーク５８、５９、６０内の１つ以上のバックボーンルータによって接続されている。また、インテリジェントルータ６１〜７０は、実際のリンクを例示的に示す複数のリンク７３〜８５によって、互いに接続されており、また、これらのリンク７３〜８５を介して、エンドユーザ機器にも接続することができる。インテリジェントルータ６１〜７０は、例えばエンティティ７１等の１つ以上の管理装置（administrator machine）及び例えばエンティティ７２等の１つ以上の仮想私設ネットワーク（virtual private network：以下、ＶＰＮという。）コントローラによって制御される。ＩＳＰネットワーク５８、５９、６０は、発行者装置及び購読者装置（図３には示していない。）に接続してもよい。ＩＳＰネットワーク５８、５９、６０内及び間のバックボーンルータは、既存のネットワークインフラストラクチャにおいて、従来の如何なる手法で互いに接続してもよい。
【００３７】
図３に示すように、既存のネットワークインフラストラクチャを用いて、インテリジェントルータ６１〜７０及びリンク７３〜８５を実現することができ、これらは、ネットワークコアにおけるコンテンツベースの経路選択を提供する。リンク７３〜８５は、インテリジェントルータ６１〜７０間の論理的接続を表し、例えば、既存のネットワークインフラストラクチャ又は他の機器を用いて実現することができる。リンクは、例えば、トンネル（tunnel）と呼ばれる論理的接続を用いて実現することができる。トンネルは、ハードウェアと、ソフトウェアと、リンクを実現するためのネットワークインフラストラクチャとを含み、１つのトンネルは、複数のチャンネルの一要素であってもよい。チャンネルは、特定の種類のコンテンツのための論理的な構成を提供することによって、インテリジェントルータにおけるコンテンツベースの経路選択を容易にし、したがって、チャンネルを介して伝送される属性にコンテキストを提供する。インテリジェントルータは、チャンネルを用いることなく、経路決定を行うこともできるが、チャンネルは、ネットワークコアにおけるインテリジェントルータによるコンテンツベースの経路選択の効率を高める。
【００３８】
この例示的な実施例は、チャンネルとリンクの使用を含んでいる。リンクは、例えばインテリジェントルータである２つのルータ間の接続を表す。チャンネルは、ルータの（通常は大きな）集合を含むネットワークエンティティであり、相互接続リンク（interconnecting link）によって静的又は動的に構成されており、１対多又は多対多の論理的接続を実現する。特に、チャンネルは、チャンネルの本質的特徴を記述する最上位レベルの論理的エンティティである。１つのチャンネルには、多くの主語が存在することができる。各主語は、互いに接続されたルータの集合を含むサブネットワーク（例えばマルチキャストツリー）を形成する。これらの主語ベースのサブネットワークは、様々な手法で、割当、適応化及び構成を行うことができる。全てのサブネットワークの集合であり、その下に主語を形成するチャンネルは、例えばネットワークのメッシュ（mesh of networks）に似ている。
【００３９】
図４は、インテリジェントルータ９２のハードウェア構成要素を示しており、インテリジェントルータ９２は、符号が付された他の如何なるインテリジェントルータに対応させることができる。ネットワークノード９０は、従来のバックボーンルータ９５に接続されたインテリジェントルータ９２を備えている。インテリジェントルータ９２は、メモリ９４及び補助記憶装置９７（例えば、独立した装置として実現してもよい。）に接続されたプロセッサ９３を備え、メモリ９４及び補助記憶装置９７は、いずれも、キャッシュデータを含むデータを保存し、及びプロセッサ９３によって実行されるアプリケーションプログラムを保存する。補助記憶装置９７は、データの不揮発性記憶装置である。後述するように、プロセッサ９３は、ソフトウェアによって制御され、バックボーンルータ９５にインストラクション（instruction）を発行し、このインストラクションに応じて、バックボーンルータ９５は、購読予約の主語フィルタ及び属性フィルタから生成された経路選択規則に基づいて、メッセージ又はパケットをルーティング（転送）し又はルーティングしない（破棄する）。ここでは、インテリジェントルータ９２をプロセッサによって制御される独立した装置として示しているが、インテリジェントルータ９２は、ソフトウェアを組み込むことによって、ハードウェアにインテリジェント経路選択機能を提供する特定用途向け集積回路（application specific integrated circuit：ＡＳＩＣ）９１によって実現することができる。また、これに代えて、インテリジェント経路選択機能は、１つ又は複数の経路選択機器において、ソフトウェアとハードウェアの組合せとして実現することができる。
【００４０】
図５は、発行者装置及び購読者装置の具体的な構成を示している。発行者装置１００、１１８は、例えば、１つ以上の発行者アプリケーション１０４及びエージェントアプリケーション１０６を記憶するメモリ１０２と、データの不揮発性記憶装置である補助記憶装置１１２と、情報又はコマンドを入力する入力装置１０８と、メモリ１０２に記憶されている又は他の記憶装置から受け取ったアプリケーションを実行するプロセッサ１１４と、情報を出力する出力装置１１０と、情報を視覚的に表示する表示装置１１６とを備えている。
【００４１】
購読者装置１２２、１４０は、例えば、１つ以上のアプリケーション１２６及びエージェントアプリケーション１２８を記憶するメモリ１２４と、データの不揮発性記憶装置である補助記憶装置１３０と、情報又はコマンドを入力する入力装置１３２と、メモリ１２４に記憶されている又は他の記憶装置から受け取ったアプリケーションを実行するプロセッサ１３４と、情報を出力する出力装置１３６と、情報を視覚的に表示する表示装置１３８とを備えている。発行者装置１００、１１８及び購読者装置１２２、１４０は、如何なる構成であってもよく、上述したものとは異なる構成要素を備えていてもよく、構成要素は、上述したものより多くても少なくてもよい。
【００４２】
発行者装置１００、１１８は、上述したネットワーク等のネットワーク１２０を介して購読者装置１２２、１４０に接続されている。ネットワーク１２０は、ネットワークコアにおいて、パケット又はメッセージを介して、データ又はコンテンツの分散経路選択（distributed routing）を行うインテリジェントルータを含んでいる。ここでは、それぞれ２つの発行者装置１００、１１８及び購読者装置１２２、１４０のみを示しているが、より多くの発行者装置及び購読者装置を含むようにネットワーク１２０を拡張することができる。発行者装置１００、１１８及び購読者装置１２２、１４０は、プロセッサによって制御される如何なる装置、例えば、以下に限定されるものではないが、サーバ、パーソナルコンピュータ、ノートブックコンピュータ、携帯情報端末、電話機、携帯電話機、ページャ又は他の機器によって実現することができる。また、インテリジェントルータを有するネットワーク１２０は、有線機器、無線機器又はその両方を接続する如何なる有線又は無線分散ネットワークを含むことができる。また、ネットワーク１２０は、潜在的には、既存の又は従来のネットワークインフラストラクチャを用いることができる。
【００４３】
図６は、インテリジェントルータのためのチャンネルマネージャ（channel manager）１５０の構成を示している。この実施例では、チャンネルマネージャ１５０は、複数のサーバ１５２、１５４、１５６によって実現されている。各サーバ１５２、１５４、１５６は、それ自体の局部記憶装置（local storage）１５８、１６０、１６２を備えている。インテリジェントルータ１６４、１６６、１６８は、特定のチャンネルに関する情報を得るために、チャンネルマネージャ１５０に接触する。また、チャンネルマネージャ１５０は、データ持続性（data persistence）、フェイルオーバ機能（fail over function）及び他の機能を提供することができる。したがって、チャンネルマネージャ１５０は、ネットワークの任意の場所において、例えばチャンネル関連情報、データ持続性の属性、発行者及び購読者のユーザ情報、及びインフラストラクチャ情報を指定するデータベース又はデータベースの集合を含むチャンネルサービスを提供する。インフラストラクチャ情報は、例えば、インテリジェントルータ１６４、１６６、１６８及びこれらを接続するトンネルの識別情報、チャンネルの主語、及びチャンネルの属性（各属性の名称と種類）を含むことができる。また、パケット又はメッセージは、固定の属性及び可変の属性の識別情報を含むチャンネル関連情報を搬送することができる。
【００４４】
ユーザは、オンラインのとき、経路情報（channel information）をダウンロードすることができる。例えば、ユーザは、ユーザ名とパスワードを用いて、自らを登録することができる。ユーザのログオンが認証されると、ユーザは、チャンネルを開き（呼び出し）、チャンネルマネージャ１５０からチャンネルに関する情報を検索することができる。発行者装置は、コンテンツを発行する際に、この情報を用いることができ、購読者装置は、購読予約を入力及び登録するために、この情報を用いることができる。
【００４５】
この実施例では、チャンネルマネージャ１５０の各サーバ１５２、１５４、１５６は、各インテリジェントルータ１６４、１６６、１６８のためのプライマリ（primary）として機能する。特に、この実施例では、各インテリジェントルータ１６４、１６６、１６８は、２つのインターネットプロトコル（Internet Protocol：以下、ＩＰという。）アドレスが供給され、一方のＩＰアドレスは、プライマリチャンネルマネージャ用であり、他方のＩＰアドレスは、バックアップチャンネルマネージャ用である。インテリジェントルータ１６４、１６６、１６８は、これらのＩＰアドレスを用いて、チャンネルマネージャ１５０の各サーバ１５２、１５４、１５６に接触し、経路情報を検索する。プライマリチャンネルマネージャに障害が発生すると、インテリジェントルータ１６４、１６６、１６８は、バックアップチャンネルマネージャと接触することができる。したがって、チャンネルマネージャ１５０のサーバ１５２、１５４、１５６は、これらを繋ぐ線によって示すように、チャンネル属性及び他の情報に関するデータを共有する。また、各サーバ１５２、１５４、１５６は、所定のバックアップチャンネルマネージャを有し、プライマリチャンネルマネージャに障害が生じた場合、他のバックアップチャンネルマネージャに処理を引き継がせることができる。ネットワーク内の機器は、コマンド、例えば経路情報を検索するコマンドを用いることができ、表３は、コマンドの具体例を示している。これに代えて、インテリジェントルータ１６４、１６６、１６８は、プライマリチャンネルマネージャのみを有していてもよく、あるいは３つ以上のチャンネルマネージャを有していてもよい。
【００４６】
図７は、ユーザ装置又は機器をインテリジェントルータを有するネットワークに接続するためのユーザ装置又は機器内の具体的なソフトウェアコンポーネントのスタック１８０を示している。ユーザ装置は、発行者装置、購読者装置又はこれらの両方として用いることができ、ユーザ装置は、具体例として上述した様々な機器を含むことができる。スタック１８０は、１つ以上のユーザアプリケーション１８２を含むことができ、ユーザアプリケーション１８２は、ユーザからの購読予約の受信、発行者装置からの経路情報の受信又は発行するコンテンツ又はデータの受信に用いることができる。また、ユーザアプリケーション１８２は、ユーザ装置又は機器によって実行される他のあらゆる種類のアプリケーションを含んでいてもよい。
【００４７】
また、スタック１８０は、例えば、エージェント１８４と、イベントライブラリ１８６と、キャッシュライブラリ１８８と、チャンネルライブラリ１９０と、メッセージングライブラリ１９２と、ディスパッチャライブラリ１９４とを含んでいてもよい。エージェント１８４は、ネットワーク接続の確立又は他の機能を提供し、表３は、エージェント１８４によって実行されるコマンドの具体例を示しており、エージェント１８４は、プロキシコマンド又は他の種類のコマンドを用いることができる。イベントライブラリ１８６は、ユーザ装置に関するイベント又は他のイベント又は情報を記録する。キャッシュライブラリ１８８は、データのローカルキャッシングを行う。チャンネルライブラリ１９０は、チャンネルの識別情報と、それらのチャンネルに関する情報とを保存する。ディスパッチャライブラリ１９４は、制御パス１９６、チャンネルマネージャ１９８、１つ以上のインテリジェントルータ２００への接続を提供し、ディスパッチャライブラリ１９４は、表４に示す例示的な機能を含むことができる。メッセージングライブラリ１９２は、データパス２０４への接続を提供する。
【００４８】
Ｃプログラミング言語で書かれたメッセージングＡＰＩ（以下、単にＡＰＩという。）の具体例を表５〜表９に示す。表５及び表６は、メッセージを送信及び検索するＡＰＩの具体例を示している。表７及び表８は、通知を送信及び検索するＡＰＩの具体例を示している。表９は、制御メッセージを送信及び検索するＡＰＩの具体例を示している。ここに示す特定の機能又は特徴を実現するＡＰＩ及び他のＡＰＩ、プログラム及びデータ構造は、例示的に示しているに過ぎず、これらの機能は、如何なるプログラミング言語で書かれたあらゆる種類のＡＰＩ又は他のソフトウェアエンティティとして実現してもよい。
【００４９】
【表３】

【００５０】
【表４】

【００５１】
【表５】

【００５２】
【表６】

【００５３】
【表７】

【００５４】
【表８】

【００５５】
【表９】

【００５６】
図８は、上述したようなインテリジェントルータ及び図４に示すインテリジェントルータ９２等のインテリジェントルータの例示的なソフトウェアコンポーネント２１０を示している。ソフトウェアコンポーネント２１０は、例えば、インテリジェントルータ９２のメモリ９４に格納されており、プロセッサ９３によって実行することができる。ソフトウェアコンポーネント２１０は、例えば、フィルタリングデーモン２１２と、ディスパッチャ２１４と、経路選択デーモン２１６と、キャッシュマネージャ２１８とを含んでいる。フィルタリングデーモン２１２は、後述するように、購読予約のコンテンツを経路選択規則に基づいて処理するフィルタリングを、コンテンツベースの経路選択に提供する。ディスパッチャ２１４は、パス２２０を介してフィルタを伝搬するために必要な制御メッセージの通信を行い、また、ディスパッチャ２１４は、ユーザのエントリの単一点及びチャンネルマネージャを有する１つの安全なソケット（one secure socket）を提供することができ、ネットワークのセキュリティを向上させる。換言すれば、この具体例では、ユーザは、チャンネルマネージャに直接接触しないが、他の実施例において、ユーザは、チャンネルマネージャと直接接触してもよい。ディスパッチャ２１４は、制御メッセージを用いて、チャンネルマネージャから属性（名称−値の対）を得る。
【００５７】
経路選択デーモン２１６は、データパス２２２による通信を行い、データパス２２２は、図４に示すような従来のバックボーンルータ９５又は他の経路選択機器によって形成することができる。キャッシュマネージャ２１８は、対応するインテリジェントルータを含むネットワークノードにおけるデータのローカルキャッシングを行う。キャッシュマネージャ２１８の動作は、後に詳細に説明するが、キャッシュマネージャ２１８は、ネットワークコアを介したデータの分散キャッシングを行う。
【００５８】
コンテンツベースの経路選択は、アプリケーションレベルではなく、カーネルレベルにおいて実行することができる。カーネルによってアクセス可能なメモリは、アプリケーション層におけるメモリから独立している。アプリケーションにおいて、コンテンツベースの経路選択を実行するためには、例えば、メッセージデータをカーネルメモリ領域からアプリケーション領域にコピーし、アプリケーションのコンテキスト（context）をカーネルのコンテキストから、経路選択アプリケーションのコンテキストに切り換える必要がある。これらの処理は、いずれもかなりのオーバヘッドを引き起こす。ここで、コンテンツベースの経路選択をサポートするようにカーネルを変更すれば、上述したオーバヘッドが取り除かれ、経路選択をより高速に行うことができるようになる。
【００５９】
このようなカーネルにおけるコンテンツベースの経路選択機能により、経路選択デーモン２１６は、実装例に応じて、データパス２２２を介してデータを直接又は間接的に送信又は受信することができる。経路選択デーモン２１６は、アプリケーション層において実行されるプロセスであり、カーネルに導入する（inject）コンテンツベースの経路選択テーブル（content-based routing table）を予め計算する（pre-computing）プロセスである。なお、カーネルは、経路選択テーブルが一旦導入されると、経路選択テーブルを用いて、経路決定を行うことができる。同様に、フィルタリングデーモン２１２は、フィルタリングテーブル（filtering table）を予め計算し、フィルタリングテーブルをカーネルに導入する。このカーネルの実行において、経路選択デーモン２１６もフィルタリングデーモン２１２もデータパス２２２とは直接インタラクトしない。
【００６０】
図９は、購読予約のコンテンツを含むことができるメッセージのパケット構造２３０の具体例を示している。コンテンツベースの経路選択に用いられるパケット又はメッセージは、例えば、ヘッダ部とペイロード部を含んでいる。ヘッダ部は、経路選択又は他の情報を指定する。ペイロード部は、データ又はコンテンツ、あるいはデータ又はコンテンツの指標（indication）を指示する。パケット構造２３０は、ＩＰヘッダ２３２と、ユーザデータグラムプロトコル（User Datagram Protocol：以下、ＵＤＰという。）の伝送制御プロトコル（Transmission Control Protocol：以下、ＴＣＰという。）ヘッダ２３４と、長さの値２３８と、１つ以上の主語フィールド２４０と、１つ以上の属性２４２とを含んでいる。パケット構造２３０は、長さの値、主語及び属性のための基本構造を示している。また、コンテンツベースの経路選択で用いられるパケットは、例えば、後述する図１８の実施例に示すように、他の又は異なる要素を含むことができ、コンテンツベースの経路選択のためのパケットは、如何なる手法で構成してもよい。また、属性は、例えば、メッセージの最後に付加される任意の属性を含むことができる。これらの任意の属性は、例えば発行者装置（又はルータ）によって追加される特別の情報（ad-hoc information）であり、必ずしもチャンネルに対して定められたメッセージフォーマットを用いて搬送する必要はない情報である。
【００６１】
発行者装置及び購読者装置における方法（Publisher and Subscriber Methodologies ）
図１０は、発行者装置によって、チャンネルを設定し、コンテンツを発行する例示的な発行方法２５０のフローチャートである。発行方法２５０は、例えば、発行者装置１００内のプロセッサ１１４によって実行されるエージェントアプリケーション（以下、単にエージェントという。）１０６を含むソフトウェアモジュールによって実現することができる。発行方法２５０において、発行者装置１００のエージェント１０６は、チャンネル用のプロキシの発行者生成（publisher creation）を受信する（ステップ２５２）。プロキシは、ネットワークとの通信を行う。エージェント１０６は、インタフェースを介してチャンネルにおいて用いられるメッセージフォーマットを判定する（ステップ２５３）。フォーマット情報は、例えば、チャンネルマネージャ又はネットワークにおける他のエンティティから得ることができる。エージェント１０６は、受信経路情報を用いて、チャンネルのプロキシを設定し（ステップ２５４）、この処理は、チャンネルの属性を受信し（ステップ２５６）、チャンネルへの通知を生成する（ステップ２５８）ことを含む。この通知は、チャンネル上でコンテンツを「待機（listening）」している機器にコンテンツを提供する。属性は、通知のパラメータ及び特性を定義する。
【００６２】
エージェント１０６は、チャンネルの識別子（ＩＤ）及びコンテンツ情報を、ネットワークコア内の又は購読予約を処理するためにそれらを用いる他の場所内のインテリジェントルータに送信する（ステップ２６０）。発行者装置１００は、通知属性に適切な値を設定し（ステップ２６１）、そして、発行者装置１００は、チャンネル属性に基づいて、通知に関するコンテンツを発行することができる（ステップ２６２）。この実施例におけるステップ２６０〜２６２により、通知の発行が完了する。この処理は、実際の個々の実施例に応じて、他の又は更なるステップを含んでいてもよい。したがって、この実施例における通知に関連した情報は、順序正しい一連の属性に区切られ、各属性は、名称と、通知内の位置（１から始まる）と、種類と、値とを有する。これに代えて、属性は、個々の実施例に応じて、異なる特性を有していてもよい。例えば、属性は、予め定義された属性、任意の属性又はこれらの両方を含むことができる。
【００６３】
インテリジェントルータは、パケット内のチャンネルＩＤを用いて、対応するチャンネルの属性を得ることができる。この属性は、チャンネルを介して伝送されるパケットの構造と又はフォーマットを決定している。特に、各パケットは、例えば、チャンネルＩＤに関連したタグと、発行者ＩＤ又は主語のような他のヘッダ情報とを含むことができる。このタグは、例えば図１８の具体例に示すように、主語をメッセージフォーマットの番号にマッピングするために用いることができる。この番号には、小さな整数値、例えば１６ビットの値を用いることができる。これに代えて、他のあらゆる種類の番号又は情報を用いて、主語をマッピングすることができる。主語を番号にマッピングすることにより、特別な利点が得られる。例えば、これにより、メッセージフォーマット内の空間を節約でき、メッセージにおいて主語の指標を指定する一様な又は標準化された手法を提供することができ、この手法により、主語を速やかに検出し、識別できるようになる。インテリジェントルータは、マッピングを局所的に保存することができ、あるいは、これに代えて番号を用い、コマンドによって、リモートから対応する主語を取得することができる。
【００６４】
表１０は、主語を番号にマッピングするための構造を示しており、この具体例では、番号に整数値を用いている。表１０における主語ツリーパラメータは、主語が階層関係内に１つ以上の主語フィールドを含むことができることを示しており、例えば、主語ツリーは、特定のシンボルによって区切られた一連の主語フィールドを含むことができる。主語ツリーの具体例は、表２に示されている。例えば、subject tree quotes.nyse（ニューヨーク証券取引所における主語ツリーの株価）は、主語「quote」とサブフィールド「nyse」を含んでおり、これらの２つの用語は、ＵＲＬ又は他のネットワークアドレスのように、「.（ピリオド）」によって区切られている。ピリオド及びＵＲＬ型の文字列を用いる代わりに、如何なる文字及び区切りのためのシンボルを用いて、如何なる手法で主語ツリーを指定してもよい。
【００６５】
【表１０】

【００６６】
特定のチャンネルのパケットフォーマット又は構造を知ることにより、インテリジェントルータは、コンテンツベースの経路選択のためのパケット内において、主語及び属性、又は他の情報を速やかに検出することができる。例えば、チャンネルは、パケット内のバイトを数えることによって、チャンネルを介して伝送されてきた主語及び属性のバイト位置を容易に特定でき、主語及び属性を簡単に検出することができる。これに代えて、インテリジェントルータは、パケットを解析して、主語及び属性、又は他の情報を検出することができる。
【００６７】
表１１は、Ｃ＋＋プログラミング言語で書かれた発行者プログラムの具体例を示している。表１２は、チャンネルを生成するＡＰＩの具体例を示している。表１３は、チャンネルマネージャによって維持されるチャンネル設定ファイルの具体例（図６参照）と、チャンネル関連情報とを示している。これに代えて、システムは、処理負荷を分散させるために、ローカルチャンネルマネージャとして機能する地理的に分散した複数のサーバのＩＰアドレスを提供する広域チャンネルマネージャ（global channel manager）を備えていてもよい。
【００６８】
【表１１】

【００６９】
【表１２】

【００７０】
【表１３】

【００７１】
図１１は、購読予約を受信及び処理するのに用いられる購読方法２６４のフローチャートである。購読方法２６４は、例えば、購読者装置１２２内のプロセッサ１３４によって実行されるエージェントアプリケーション（以下、単にエージェントという。）１２８を含むソフトウェアモジュールによって実現することができる。購読方法２６４において、例えば、グラフィカルユーザインタフェース（graphical user interface；以下、ＧＵＩという。）は、利用可能なチャンネルの指標をユーザに表示する（ステップ２６６）。この処理は、アプリケーション１２６によって行われる。チャンネルを識別する情報は、例えば、チャンネル関連情報を提供するチャンネルマネージャから受信することができる。あらゆる種類のアプリケーション１２６を用いて、如何なる特別な手法又はフォーマットによって、チャンネルを識別する情報を表示してもよい。アプリケーション１２６は、ユーザが選択したチャンネルを受信し（ステップ２６８）、選択されたチャンネルのＡＰＩ又は他のプログラムを呼び出す（ステップ２７０）。ＡＰＩは、選択されたオプションに対応したチャンネルの購読予約オプションをユーザに表示する（ステップ２７２）。ＡＰＩは、ユーザから購読予約に関する値を受け取り（ステップ２７４）、購読予約を、後述する処理のために、エージェント１２８に送る（ステップ２７６）。
【００７２】
購読予約のパラメータは、例えば表１に示すような述語を含むことができる。各チャンネルは、例えば、対応するチャンネルに関する特定の要求又はパラメータに基づいて、購読予約を処理するために、それ自体のＡＰＩを用いることができる。これらのＡＰＩは、例えば、購読予約を受け取るウェブベースの又はJavaベースのＡＰＩを含むことができ、あらゆる種類のユーザインタフェース及び処理を用いて、購読予約に関する情報を受け取り、この情報をエージェント１２８に渡すことができる。
【００７３】
図１２は、チャンネル及び購読者画面（すなわちＧＵＩ）２７８、２８４を概念的に示す図であり、これらは、購読予約を受信する購読方法２６４に関連して用いられる。購読者画面２７８は、ユーザによって選択される利用可能なチャンネルを識別する複数の領域領域２８２を含んでいる。特定のチャンネルが選択されると、購読者画面２８４に示すように、購読予約のユーザの値を入力する領域２８６が表示される。ユーザが領域２８８を選択すると、購読予約が確定し、又は、ユーザが領域２９０を選択すると、購読予約が中止される。購読者画面２７８、２８４は、例えば、ハイパーテキストマークアップ言語（HyperText Markup Language：以下、ＨＴＭＬという。）のウェブページとしてフォーマットしてもよく、又は如何なる他の形式でフォーマットしてもよい。また、購読者画面２７８、２８４は、領域及びコンテンツのあらゆる構成を含むことができ、例えば、所望の、ユーザフレンドリで視覚的に魅力的なインタフェースを、購読者に提供するために、例えばテキスト、図形、画像、様々な色又はマルチメディア情報を含むことができる。また、購読者画面２７８、２８４は、例えば、従来と同様のブラウザ機能を提供するツールバー２８０を含んでいてもよい。
【００７４】
表１４は、Ｃ＋＋プログラミング言語で書かれた購読者プログラムの具体例を示している。
【００７５】
【表１４Ａ】

【００７６】
【表１４Ｂ】

【００７７】
ペイロード検査によるコンテンツベースの経路選択及びチャンネル
図１３は、コンテンツベースの経路選択のためのペイロード検査方法３００のフローチャートである。ペイロード検査方法３００は、例えば、インテリジェントルータ９２内のプロセッサ９３によって実行され、フィルタリングデーモン２１２として表されるソフトウェアモジュールによって実現することができる。これに代えて、このぺイロード検査方法３００は、ＡＳＩＣによって実現してもよく、あるいはハードウェアとソフトウェアの組合せによって実現してもよい。ペイロード検査方法３００として示すコンテンツベースの経路選択は、インテリジェントルータ内、あるいは、例えばネットワークコア又はエッジルータのようなネットワーク内の任意の場所において実行することができる。
【００７８】
一般的な意味では、コンテンツベースの経路選択は、パケットをどのように処理するかを決定するために、パケットのペイロード部を検査することが必要である。このコンテンツベースの経路選択方法は、例えば、購読予約のリストを任意の順序で（例えば、フィルタを用いて）処理し、経路選択規則に基づいて、メッセージを主語毎及び属性毎に比較し、メッセージの経路選択を決定し、ネットワークコアにおける処理を実行することを含む。この経路選択規則は、ルータにおける処理を制御する規則又はフィルタに関連したあらゆる規則を含むことができる。したがって、これらの経路決定は、ネットワークコアを介して配信することができる。主語をチャンネルとして表すことにより、メッセージフォーマットが決定され、したがって、インテリジェントルータは、例えば、特定のチャンネルのメッセージ又はパケット内の属性のバイト位置を知ることによって、メッセージ内の属性の位置を速やかに検出できる。
【００７９】
ペイロード検査方法３００において、インテリジェントルータ９２は、メッセージのパケットを受信する（ステップ３０２）。インテリジェントルータ９２は、パケットから、対応するメッセージのチャンネルＩＤを判定し（ステップ３０４）、このチャンネルＩＤを用いて、チャンネルの属性を読み出す（ステップ３０６）。この実施例では、チャンネルの種類（チャンネルＩＤから判定される。）は、パケット内の属性の位置及びデータタイプを決定している。チャンネルの属性は、局所的に保存し、例えばチャンネルマネージャを介して遠隔から読み出すこともできる。インテリジェントルータ９２は、購読予約に対応するフィルタを検索する（ステップ３０８）。フィルタは、購読予約に対する１つ以上の属性テスト（attribute test）、多くの場合、属性テストのグループを含んでいる。インテリジェントルータ９２は、フィルタ記述（filter description）のうちの対応する属性テストを、パケットの属性に適用する（ステップ３１０）。
【００８０】
フィルタ記述の全ての属性テストの結果が肯定的である場合（ステップ３１２）、すなわち、属性が全ての属性テストを満たす場合、インテリジェントルータ９２は、フィルタに関連した規則によって定められた１組の機能を実行する（ステップ３１４）。これらの機能には、例えば、次のリンクにパケットをルーティングすること、及び／又はローカルルータにおいて、パケットのコンテンツに対して、規則で定められた何らかの働き又は演算を実行することが含まれる。この働き又は次のリンクは、例えば、対応する購読予約を指定するデータ構造において識別される。規則がリンクである場合、規則は、通常、パケットを受信する次のネットワークノードを識別し、次のネットワークノードには、インテリジェントルータ、バックボーンルータ、ネットワークに接続された機器又は他のエンティティが含まれる。これに代えて、次のリンクは、他の手法で指定し又は購読予約に関係付けることができる。
【００８１】
フィルタ記述の全ての属性テストの結果が肯定的でない場合（ステップ３１２）、すなわち、属性が全ての属性テストを満たさない場合、フィルタは、不一致（mismatch）が宣言される（ステップ３１５）。インテリジェントルータ９２は、フィルタ記述の全ての属性テストが終了するまで、又は最初の否定的結果が得られるまで、上述した処理を繰り返す。
【００８２】
インテリジェントルータ９２は、このフィルタに対する全ての属性テストを行った後、更なるフィルタが存在するかを判定し（ステップ３１６）、更なるフィルタが存在する場合、インテリジェントルータ９２は、ステップ３０８に戻り、次のフィルタに対する属性テストを読み出して、次のフィルタの属性を処理する。マッチング処理（ステップ３０８、３１０、３１２、３１４、３１５、３１６）は、フィルタの全集合に対する処理が終了するまで、あるいは全ての働き又は全ての規則に対する結果が判定されるまで続けられる。パケットがあるフィルタを満たさない場合、そのフィルタは、ドロップ（破棄）されて、転送されない。
【００８３】
インテリジェントルータ９２は、フィルタをある特定の順序に配列することができる。例えば表１５に示すように、インテリジェントルータ９２は、購読予約のフィルタを、ファイル又は経路選択テーブル内に保存することができ、属性にフィルタを適用する（属性テストの）ために、これらのフィルタを直線的に順序付けることができる。これに代えて、経路選択テーブルは、フィルタへのリンク又はポインタを含んでいてもよい。
【００８４】
コンテンツベースの経路選択では、アプリケーション及び性能向上ヒューリスティックス（performance-enhancing heuristics）、例えばトラヒック条件に基づくアルゴリズムの切換に基づいて、複数の方法を選択的に同時に用いることができる。コンテンツベースの経路選択に関するペイロード部を検査するために、処理用のフィルタは、ネットワーク内のルータにおいて、選択的に暗号化、復号、変換及び併合することができる。例えば、アプリケーションにおける発行（publication）が、小数点以下２桁より小さい通貨属性を含まない場合、購読予約、例えば「価格＞３．５４１２２ドル」は、「価格＞３．５４ドル」に切り捨てられる。また、例えば、海外からの発行が、米国内に位置する最初のルータに到達したときに、外貨を、米国の通貨に換算してもよい。
【００８５】
インテリジェントルータ９２は、線形的な手法に代えて、処理の速度と効率を高めることができる他の順序で、又は様々なアルゴリズムに基づいて、処理するフィルタを選択することができる。表１６は、購読予約と対応するリンクの具体例を示す。これらの具体例において、主語は、特定のチャンネルに関連し、主語の購読予約は、フィルタの経路選択規則によって表すことができる。主語は、例えば、ユニフォームリソースロケータ（Uniform Resource Locator：ＵＲＬ）のようなコンテンツの供給源装置（source）を識別するネットワークアドレスを含むことができる。
【００８６】
【表１５】

【００８７】
【表１６】

【００８８】
図１４は、キャッシング方法３２０のフローチャートである。キャッシング方法３２０は、例えば、インテリジェントルータ９２内のプロセッサ９３によって実行され、キャッシュマネージャ２１８として表されるソフトウェアモジュールによって実現することができる。これに代えて、このキャッシング方法３００は、対応するインテリジェントルータと同じ又は異なる物理機器内のＡＳＩＣによって実現してもよく、あるいはハードウェアとソフトウェアの組合せによって実現してもよい。キャッシング方法３２０において、インテリジェントルータ９２は、データ又はコンテンツと、チャンネルＩＤと、主語とを含むメッセージを受信する（ステップ３２２）。インテリジェントルータ９２は、データにタイムマークを付して（time mark）（ステップ３２４）、データを、例えばメモリ９４又は補助記憶装置９７に局所的に格納する（ステップ３２６）。インテリジェントルータ９２は、キャッシュデータに、チャンネルＩＤ、主語及びタイムスタンプによって、インデックスを付ける（ステップ３２８）。
【００８９】
インテリジェントルータ９２がデータの要求を受信した場合（ステップ３３０）、インテリジェントルータ９２は、その要求に基づき、インデックスを用いて、キャッシュデータを検索する（ステップ３３２）。インテリジェントルータ９２は、最終的に要求者装置（requester）又は他のエンティティに伝送するために、キャッシュデータを、バックボーンルータ９５又は他の経路選択エンティティに転送する。キャッシング方法３２０は、継続的にデータをキャッシュに格納し、キャッシュデータ（cached data）を、要求に応じて検索するために、繰り返し実行することができる。
【００９０】
図１５は、キャッシング方法３２０に用いられるキャッシュインデックス３３６の具体例を示している。キャッシュインデックス３３６は、データ３３８が入力され、これをタイムスタンプ３４０とともに保存する。データを収集する際、全てのデータには期間Δｔ毎にマークが付される。ここで、期間Δｔは、マーク間の時間、例えばｔ２−ｔ１を表す。タイムマークの付与（time marking）のために、他のあらゆる種類のインデックスを用いてもよい。
【００９１】
表１７は、キャッシュデータに用いられるインデックスを概念的に示している。表１８は、キャッシングのための接続履歴を保存するためのデータ構造を概念的に示している。表１９は、インテリジェントルータを有するネットワークノードにおいて、データを局所的にキャッシュに格納するために用いられるデータ構造の具体例を示している。
【００９２】
タイムマークの付与は、固定された如何なる間隔で行ってもよく、可変の時間間隔で行ってもよい。例えば、データを５分毎にキャッシュに格納して、インデックスを付けてもよい。キャッシュマネージャ２１８は、ステップ３３２において、時刻及び主語を指定した、キャッシュデータを読み出すコマンド（例えば、#.getCache）を受信すると、キャッシュインデックスを用いて、要求に対応するキャッシュデータを読み出すことができるか否かを判定する。
【００９３】
各主語又はチャンネルは、例えば、マルチキャストツリー及び１組のインテリジェントルータにおけるそれ自体のＩＰアドレスを含むことができる。したがって、表１８は、ユーザ装置に局所的に保存できる、このようなルータ間の接続履歴を示している。エッジルータが故障した場合、ユーザ装置は、エッジルータがオンラインに戻ったときに、チャンネルの上流（upstream）のルータにどのように再接続すべきかを決定するために、この接続履歴にアクセスすることができる。また、ユーザ装置は、例えば、それが切断されていた期間における購読予約に関する保留中のコンテンツを取得するために、ゲットキャッシュコマンド（get cache command）を実行することができる。
【００９４】
【表１７】

【００９５】
【表１８】

【００９６】
【表１９Ａ】

【００９７】
【表１９Ｂ】

【００９８】
これらの例示的なデータ構造は、以下の情報を含んでいる。主語ノード（subject node）は、主語識別子（subject identifier）と、主語レベル（subject level）と、親チャンネル（parent channel）又は主語ノードへのポインタと、それ自体のディレクトリのためのファイル記述子（file descriptor）と、その次のレベルの主語ノードを含むハッシュテーブル（hash table）へのポインタと、データノード（data node）へのポインタとを含んでいる。データノードは、主語親ノード（subject parent node）へのポインタと、データディレクトリ（data directory）のためのファイル記述子と、各記憶装置に保存されたデータのデータ構造を含む循環バッファ（circular buffer）と、バッファの最初及び最後と、検索及び保存中にデータノードをロックするロックとを含んでいる。保存された時間単位ノード（time grain node）は、実際のデータファイルを表すノードであり、最後の時間単位ノードは、メモリには維持されているが、記憶装置にはまだ保存されていない最後のバッファを表す。この実施例におけるキャッシング及びデータ記憶スレッドは、最後の時間単位ノードに対する同時アクセスを防止する、最後の時間単位ノードのミューテックス（mutex）を用いる。
【００９９】
エージェントの処理
図１６は、送信購読予約メッセージのためのエージェント方法３５０のフローチャートである。エージェント方法３５０は、例えば、購読者装置（以下、ユーザ装置ともいう。）１２２内のプロセッサ１３４によって実行され、エージェント１２８として表されるソフトウェアモジュールによって実現することができる。エージェント方法３５０において、エージェント１２８は、例えば、図１１及び図１２を用いて説明した購読方法２６４によって生成された購読予約を受信する（ステップ３５２）。エージェント１２８は、購読予約用の論理式を指定する文字列を生成し（ステップ３５４）、文字列を解析して、購読予約内のエラーを検出する（ステップ３５６）。エラーが存在する場合、エージェント１２８は、ユーザがエラーを修正し、購読予約を再入力するように促すエラーメッセージをユーザに表示する（ステップ３６０）。購読予約がエラーを全く含んでいない場合（ステップ３５８）、エージェント１２８は、例えば後続するステップのように、論理式をデータ構造内に保存する（ステップ３６２）。エージェント１２８は、データ構造内の構成要素である不等号式（constituent not-equal expression）を肯定的形式に変換し（ステップ３６４）、更にデータ構造を対応する論理和標準形式（disjunctive normal form：以下、ＤＮＦという。）に変換する（ステップ３６６）。また、エージェント１２８は、範囲フィルタ（range filter）及びメンバシップテスト（membership test）のみが含まれるように、ＤＮＦ構造のＡＮＤ式（AND expression）を単純化する（ステップ３６８）。
【０１００】
ＤＮＦは、周知の標準形式（canonical form）であり、その標準形式においては、論理式は、１つ以上の部分式（sub-expressions）のＯＲ（選言肢（disjunct）と呼ばれる）として表され、各部分式は、１つ以上の属性テストのＡＮＤで表される。例えば、論理式「price >= 10 AND (symbol ="LU" OR symbol ="T")」に等価なＤＮＦの論理式は、論理式「(price >= 10 AND symbol ="LU") OR (price >= 10 AND SYMBOL ="T")」である。
【０１０１】
ステップ３６４における変換では、「不等号（not-equal）」演算子（例示的な構文では、!=で表す。）を有する論理式を、１つの許可されていない値ではなく、全ての許可される値を指定する等価な「肯定的（positive）」形式に変換することが必要である。この実施例のルータは、肯定的形式の式を要求するので、この変換は、ＤＮＦを生成する前に行われる。例えば、論理式「price != 80」は、等価な肯定的論理式「price<= 79 OR price >=81」に変換することができる。
【０１０２】
ステップ３６８における変換は、ＤＮＦが生成された後に実行されるので、得られるＡＮＤ式を更に単純化しなければならず、また、この変換は、この実施例におけるルータの作業を単純化するために実行される。特に、同じ属性に対する複数の属性テストのＡＮＤは、１つの下限、１つの上限、下限及び上限の両方、又は等号テスト（equality test）の場合における単一の値のいずれかを標準的な（canonical）「範囲フィルタ」に単純化することができる。そして、特定の種類の範囲フィルタは、例えば表２２に基づいて符号化される。
【０１０３】
例えば、論理式「price >= 10 AND price <= 80 AND price >=20 AND price <= 100」は、論理式「price >= 20 AND price <= 80」に単純化することができ、これは、下限と上限の両方を有する範囲フィルタの具体例である。単純化後の他の種類の具体例としては、「price >= 20（下限のみ）」、「price <= 80（上限のみ）」、「price = 50（単一の値）」等がある。これらの範囲フィルタを生成する際、何らかの部分式を真又は偽に単純化することができ、その場合、部分式は、論理代数の法則に従って削除することができ、これにより、メッセージ内の論理式の符号化が更に最適化される。例えば、論理式「price >= 50 AND price <= 20」は、論理式を満足させる「price」の値がないので、偽に単純化することができる。フィルタの論理式（filter expression）全体が偽に単純化される特別な場合、エージェント１２８は、メッセージを生成する必要がなく、これにより、ルータを不要な作業から解放することができる。
【０１０４】
主語フィルタがワイルドカードを含んでいる場合、エージェント１２８は、後述するように、それらを選択的に変換することができる（ステップ３７０）。これに代えて、如何なるワイルドカードもユーザ装置１２２又は他の機器ではなく、ネットワーク内において変換してもよい。この例示的な実施例では、主語フィルタの構文は、ワイルドカードを用いる唯一の構文であり、属性フィルタの構文は、論理式を用いる唯一の構文である。これに代えて、実施例において、主語フィルタ及び属性フィルタの異なる又は様々な種類の構文を用いてもよい。
【０１０５】
エージェント１２８は、生成されたＤＮＦの論理式をメッセージに符号化し（ステップ３７２）、メッセージをインテリジェントルータに転送する（ステップ３７４）。この符号化は、購読予約を、一連のデータから構成されることを意味する平坦な（flat）メッセージフォーマットに変換することを含む。また、この転送は、購読予約に対する主語フィルタ及び属性フィルタから生成される経路選択規則を、ネットワーク内の１つ以上のインテリジェントルータ又は他の経路選択エンティティに伝搬することを含む。この伝搬のために、例えば、購読予約の論理式を従来のパケット構造にマッピングすることができる。
【０１０６】
ステップ３７２における符号化は、チャンネルの購読予約を、チャンネル全体に亘って伝搬するために、メッセージングＡＰＩのメッセージフォーマットに配列（marshalling）することを含む。例えば、購読予約は、主語#.SUBSCRIPTIONを含む通知として内部的に送られる（messaged）。主語フィルタフィールドの変数（variable number）と属性テストの変数の両方があるので、この実施例では、主語フィルタフィールドの変数を保存するために、１対のバイトが用いられ、属性テストの変数を保存するために、もう１対のバイトが用いられる。主語フィルタの個々のフィールドは、連続して、例えば元の購読予約で指定された順番で配列され、各フィールドは、メッセージの２バイト部分に配列される。ワイルドカードフィールドの配列については後述する。
【０１０７】
属性テストの配列においては、属性テストのオペランドは、通知の属性値の配列と同様な方法で、メッセージの最後に配列される。属性テスト及びオペランドは、配列される前に、所定の属性に対する位置順（position order）のテストと、これに続く任意の属性に対する名称順（name order）のテストとによって、ＤＮＦの各選言肢内で属性順（attribute order）にソートされる。更に、各選言肢内のスカラ値の（scalar valued）属性に対する１組の関係テスト（relational tests）は、１つの限界値（limit）（左が開いた範囲（left-open range）又は右が開いた範囲（right-open range）又は等号（equality）のテスト）、又は２つの限界値（異なる限界値間の閉じられた範囲のテスト）を有する範囲フィルタとして、標準形式に単純化される。属性テストに関する残りの情報は、オペランドと同じ順番で、例えば２バイト対（two-byte pairs）に符号化され、この２バイト対のシーケンスは、メッセージ内において、主語フィルタフィールドの２バイト符号化のシーケンスの直後に配置される。２バイト対は、属性テストの連続したビット列の符号化の１つの形式を構成することができ、これは、２バイト対とは別に、他の種類の符号化を表すためにも用いることができる。属性テストの具体例については、後述する。
【０１０８】
表２０は、属性テストの符号化規則を示している。表２１は、２バイト対の符号化を示し、表２２は、２バイト対の演算子ＩＤの符号化を示している。
【０１０９】
【表２０】

【０１１０】
【表２１】

【０１１１】
【表２２】

【０１１２】
テストの２バイト対が、既に、テストのオペランドの種類と、テストが所定又は任意の属性に適用された否かの両方を表しているので、任意の属性又はそれらの種類に対して実行されたテストの回数を別に配列する必要はない。この方式では、通知内の所定の属性の数が１２７個以下であると仮定している。これに代えて、この設計では、属性テストを符号化するために、より多くのビットを用いることができる。
【０１１３】
この配列規則は、属性フィルタのＤＮＦに基づいて、属性テストを順序付け及びグループ化する（group）が、インフラストラクチャの構成要素（例えば、ルータ）は、属性フィルタの全体評価をより効率的に行うために、属性テストを別の順序で（例えば、異なる属性テストの成功又は失敗の確率に関して動的に導出されたローカルデータに基づいて）評価するように選択することができる。メッセージの購読予約ＩＤフィールドは、購読予約を変更又は取り消す（unsubscribe）後続の要求において、エージェントのエッジルータに対して購読予約を一義的に識別するための、エージェントによって生成された値である。特に、購読予約の属性フィルタに対する動的な変更は、主語が#.RESUBSCRIPTIONであり、且つ購読予約ＩＤが既に登録されたものであって、変更する購読予約ＩＤである場合を除いて、図１８の実施例に示すメッセージフォーマットを用いて伝搬される。購読停止（unsubscription）は、例えば、主語を#.UNSUBSCRIPTIONとし、購読予約ＩＤを、既に登録されたものであって、登録を取り消す（unsubscribed）購読予約ＩＤを有する図１８に示すメッセージフォーマットを用い、購読予約ＩＤフィールドによって伝搬される。
【０１１４】
以下、上述したエージェントによる変換及び符号化の具体例を説明する。具体的な属性フィルタの論理式「price >= 10 AND (symbol == "LU" OR (volume >= 1000 AND volume <= 10000))」について考察する。図１９は、ステップ３６２において、論理式を保存するためにエージェントによって用いられるオブジェクト（object）を表した統一モデリング言語（Unified Modeling Language：以下、ＵＭＬという。）３９０を示している。この図１９は、変数値、定数値又はその両方を含むことができる購読予約を指定するための階層関係を示している。図１９のオブジェクトは、特定の実施例に基づく、フィルタクラスの例である。各単純フィルタ（simple filter）のオブジェクトは、フィルタの論理式の対応する属性テストに関する情報を保存するために用いられる属性の値を表している。図１９に示す表現では、ＯＲフィルタ３９６は、２つのＡＮＤフィルタ３９２、４００に接続している。ＡＮＤフィルタ３９２は、購読予約の属性を有する単純フィルタ３９４を含んでいる。同様に、ＯＲフィルタ３９６は、単純フィルタ３９８を含み、ＡＮＤフィルタ４００は、単純フィルタ４０２、４０４を含んでいる。
【０１１５】
この実施例においては、属性price、symbol、volumeは、関連したチャンネルの所定の属性であり、それぞれ位置０、１、２が定義されているものとする。更に、各属性の種類は、それぞれ符号なし整数（タイプコード６）、文字配列（character array）（タイプコード１２）、符号なし整数（タイプコード６）であるものとする。
【０１１６】
次に、その属性フィルタとして、上述した具体的な属性フィルタの論理式を含む購読予約について考察する。図１８は、購読予約をメッセージに配列した具体例を示している。図１８の左側の配列３８６は、実際のメッセージ内容を示しており、図１８の右側の配列３８８は、メッセージの各部分の説明を示している。各配列の横幅は、４バイトに対応している。配列する前に、属性フィルタは、その等価なＤＮＦの論理式「(price >= 10 AND symbol == "LU") OR (price >= 10 AND volume >= 1000 AND volume <= 10000)」に変換されている。
【０１１７】
１６ビットの属性テストの符号化は、異なる部分を分離するギャップ（gap）を有するビットシーケンスとして示される。なお、この実施例においては、priceに対する２つのテストは、それぞれ別の選言肢内に存在するので、結合することができず、したがって、これらは、右の限界値（bound）がない範囲（右が開いた範囲）として別々に配列される。一方、volumeに対する２つのテストは、同じ選言肢内に存在するので、結合することができ、したがって、これらは、単一の「閉じた範囲」のテストとして配列される。
【０１１８】
また、特定のフィールドは、「仮定（assumed）」として特徴付けられ、これは、この具体例においては、これらのフィールドの値が、任意に選択され、通常、配列された購読予約から独立していることを意味する。更に、購読予約の主語フィルタは、「>」として任意に選択され、これは、関連したチャンネルによって定義された如何なる主語にも一致する。上述し、図１８及び図１９に示した具体例は、例示的なものであり、配列は、他のあらゆる種類の購読予約とともに用いてもよい。また、エージェント方法３５０は、購読予約を配列する一具体例に過ぎず、購読予約は、他の如何なる方法によって配列することができる。
【０１１９】
図１７は、受信メッセージのためのエージェント方法３７６のフローチャートである。エージェント方法３７６は、例えば、ユーザ装置１２２のエージェント１２８及びアプリケーション１２６によって実現することができる。エージェント方法３７６において、エージェント１２８は、インテリジェントルータから購読予約に対応するメッセージを受信する（ステップ３７８）。エージェント１２８は、購読予約に対応するチャンネルを、例えばメッセージのチャンネルＩＤによって判定し（ステップ３８０）、チャンネルのＡＰＩを呼び出す（ステップ３８２）。ＡＰＩは、ユーザ装置１２２において、購読予約のデータをＧＵＩ又は他のフォーマットで表示する（ステップ３８４）。受信メッセージの処理としては、上述した符号化処理の逆のデータ復号処理を用いることができ、この復号（逆符号化）は、ルータ又は他のネットワークエンティティにおいて実行することができる。
【０１２０】
ワイルドカード処理
図２０は、ワイルドカード方法４１０のフローチャートである。ワイルドカード方法４１０は、フィルタの１組の経路選択規則を用いて、ワイルドカードを購読予約の論理式に変換する具体例を示している。ワイルドカード方法４１０は、例えば、ユーザ装置１２２内のプロセッサ１３４によって実行され、エージェント１２８として表されるソフトウェアモジュールによって実現することができる。これに代えて、ワイルドカードは、ネットワークにおいて、インテリジェントルータ９２内のソフトウェア制御のプロセッサ９３によって、又はＡＳＩＣ９１内の対応する機能によって処理することができる。ワイルドカードは、空のフィールド（open fields）又は可変長のフィールドを含んでおり、表２１は、このようなフィールドの具体例を示している。
【０１２１】
ワイルドカード方法４１０において、エージェント１２８又は他のエンティティは、ワイルドカードを含む購読予約を受信する（ステップ４１２）。購読予約の主語長は、発行者がコンテンツを発行する際に指定でき、主語は、発行者装置１００において前処理することができ、例えば主語のフィールドを数え、したがって、フィールド数（長）を得ることができる。エージェント１２８は、フィルタオペランド内のフィールドの数を数え（ステップ４１４）、フィールド長＝Ｎの新たな規則（フィルタ）を初期化する（ステップ４１６）。エージェント１２８は、購読予約のサブフィールドを読み出し（ステップ４１８）、フィルタオペランドのサブフィールドＯ［ｉ］がワイルドカードであるか否かを判定する（ステップ４２０）。フィルタオペランドのサブフィールドＯ［ｉ］がワイルドカードでない場合、エージェント１２８は、接続詞（conjunctive clause）を規則に追加し、フィールド［ｉ］＝Ｏ［ｉ］とする（ステップ４２２）。フィルタオペランドが更なるサブフィールドを有している場合（ステップ４２４）、エージェント１２８は、ステップ４１８に戻り、この更なるサブフィールドを処理する。パラメータ［ｉ］は、フィールドを表し、ｉは、この実施例においては、フィールド番号を表す整数である。
【０１２２】
エージェント１２８は、サブフィールドを処理した後に、フィルタオペランドの最後のサブフィールドが「>」であるか否かを判定し（ステップ４２６）、フィルタオペランドの最後のサブフィールドが「>」である場合、長さの制約（constraint）をフィールド長＞Ｎ−１に変更する（ステップ４２８）。ワイルドカード処理は、あらゆる種類のシンボルを用いることができ、「>」は、その一例に過ぎない。この具体例においては、「a.>」は、a.b、a.c、a.d等を表し、全てのレベルにおけるこれらの全てのサブ主語（例えば、a.b.x、a.c.x、a.b.x.y等）を表すことができる。また、他のシンボルをワイルドカードとして用いてもよい。
【０１２３】
必要に応じて、エージェント１２８は、変更された規則（transformed rule）をインテリジェントルータ９２又はネットワークにおける他のエンティティに伝搬する（ステップ４３０）。したがって、ワイルドカード方法４１０は、ワイルドカード規則を、ワイルドカードを含まないことを意味する非ワイルドカード規則に変換するために、全てのサブフィールドに対して繰り返される。ワイルドカードの変換は、ネットワーク内の任意の場所、例えば、購読者装置１２２又はインテリジェントルータにおいて行うことができる。したがって、この変換は、他のエンティティに伝搬された、変更された規則を有する１つのエンティティで行い、又は動的に行うことができる。
【０１２４】
表２３は、ワイルドカードを処理するこれらの例示的な経路選択規則の概要をその具体例とともに示している。これらの経路選択規則は、例えば、インテリジェントルータで生成してもよく、又は他のネットワークエンティティで生成し、インテリジェントルータに伝搬してもよい。更に、表２３の経路選択規則は、説明のために例示的に示しているに過ぎず、他の経路選択規則を用いてワイルドカードを変換してもよい。
【０１２５】
【表２３】

【０１２６】
警告サービス
上述したインテリジェントなコンテンツベースの経路選択は、様々な用途に用いることができ、その１つとして、デジタルビデオ監視システム（digital video surveillance system：以下、ＤＶＳＳという。）がある。例えば、警察又は警備会社等のユーザは、特定の位置のカメラからのビデオクリップを購読予約することができる。カメラは、デジタルビデオクリップを捕捉し、例えばインターネット等、コンテンツベースの経路選択を有するネットワークを介してこれらのクリップを伝送し、ネットワークコアは、購読予約に基づいて、ビデオクリップを処理する。これにより、ユーザは、興味があるビデオクリップを受信し、これらのフィルタリングは、ネットワークを介して配信することができる。ビデオクリップに加えて、例えば、機密保護違反、発火、不正検出等に対する如何なる種類の警告を提供するために、他の如何なる種類のコンテンツを配信してもよい。
【０１２７】
他の実施例としてカメラは、関連する動きセンサを備えていてもよい。この動きセンサは、動きを検出すると、カメラを起動し、捕捉と同時にビデオクリップをネットワークに伝送し、ネットワークは、コンテンツベースの経路選択を用いて、購読者にビデオクリップをルーティングする。
【０１２８】
したがって、上述したコンテンツベースの経路選択により、ビデオクリップの処理及びルーティングに関するネットワークの負担を大幅に削減することができる。例えば、各電荷結合素子（charge coupled device：ＣＣＤ）カメラによって生成されたビデオ信号を、デジタルビデオレコーダ（ＤＶＲ）によって、ＤＶＲによって管理された局部記憶装置、ネットワークに取り付けられた広域記憶装置（global storage）、ＤＶＳＳシステム及びＩＤＳＳ管理サーバといった４つの異なる宛先に書き込む必要があるとする。このような膨大なデータ量を搬送するためのネットワーク帯域幅を考慮すると、ＩＤＳＳによって管理されるＣＣＤカメラ又はＤＶＲの容量が顧客の能力要求を満たさない場合がある。したがって、例えば、媒体又は大口顧客のための技術を用いて、帯域幅を制限する必要がある。図２１は、各ＤＶＲが、４台又は１６台のＣＣＤカメラを管理できる監視システムの全体的なアーキテクチャを示している。
【０１２９】
アーキテクチャ概要：
図２２は、主に上述した技術に基づいて、図２１に示す監視システムの能力を向上させる２つの拡張例を示している。図２２に示すように、第１の拡張は、ＤＶＲバックボーントラヒックを低減することを目的とし、第２の拡張は、上述したようなデータ配信効率を向上させるための機能と同様なコンテンツベースの経路選択機能を提供するｚボックス（z-box）と呼ばれる機器を用いる。
【０１３０】
ＤＶＲバックボーンのローカルトラヒックの低減：
データ配信スキームが非効率であると、重大な拡張性の問題が生じることがある。すなわち、ＴＣＰベースのプロトコルを用いて、ＤＶＲによって生成される画像ファイルを他のボックスに供給する場合、使用される帯域幅は、ローカルエリアネットワーク（ＬＡＮ）に接続されている機器の数に比例して大きくなる。例えば、ＩＤＳＳについて言えば、同じストリーミングビデオデータは、ネットワークに接続された記憶装置（ＳＡＮ又はＮＡＳ）、ＩＤＳＳモニタ、及び遠隔監視ソフトウェアである各ＤＶＳＳに送信する必要がある。
【０１３１】
この問題を解決する１つの手法として、各ＤＶＲが１つのみのデータストリームをＬＡＮに発行し、ネットワークに接続された他の機器が購読予約の結果として、このデータストリームを受信するようにしてもよい。この場合、ＤＶＲの出力レートが１０メガビット／秒（Ｍｂｐｓ）であれば、例えば、ネットワーク上に３個の購読機器に情報を提供するために必要な出力レートは、３０Ｍｂｐｓではなく、１０Ｍｂｐｓで足りる。
【０１３２】
このような発行−購読構造を実現するために、ＤＶＲボックス又はＤＶＲデータを利用する他の何らかの機器（例えば、ＩＤＳＳ、広域記憶装置）において、上述した事象通知ＡＰＩを用いることができる。この事象通知ＡＰＩは、単純であるが、有効であり、ここでは、ＩＰマルチキャスティング及び復旧プロトコル（recovery protocol）を用いることができる。また、この事象通知ＡＰＩは、上述の発行−購読モデルに基づいて実現でき、このため、他の実施は、コードを変える必要はなく、単に、事象通知ＡＰＩを提供するライブラリの完全版に再リンクさせればよい。
【０１３３】
ＤＶＳＳのプロキシ：
各ＤＶＳＳは、ＤＶＲボックスへの１つの接続（ＴＣＰベース）を確立し、ストリーミングビデオデータを受信することができる。
【０１３４】
図２２に示すように、この手法は、２つの段階によって説明することができる。第１の段階であるステージ１では、ＬＡＮ側において、全てのＤＶＳＳ発信データ（すなわちＤＶＲからＤＶＳＳに供給されるデータ）を処理するためのプロキシサーバ（例えば、ｚボックス１）を準備する。このプロキシサーバは、ＬＡＮ上の全てのＤＶＲデータを購読し、外部のネットワーク（例えば、インターネット）にそのデータを発行する。ＤＶＳＳは、このデータを購読する。したがって、プロキシサーバであるｚボックス１は、購読者エージェント（例えば、エージェント１２８）と、ＤＶＲからデータを集める上述した発行−購読ネットワーク等の発行−購読ネットワークを介してこのデータを発行する発行者エージェント（例えば、エージェント３６）とを提供する。
【０１３５】
ステージ１により、ＬＡＮ側において、トラヒックを大幅に削減することができるが、特に幾つかの国において、典型的な非対称デジタル加入者線（ＡＤＳＬ）が６４のキロビット／秒（ｋｂｐｓ）のアップリンク速度しか有していないような場合、送信リンクにおけるトラヒックの問題が残る。
【０１３６】
更に図２２を用いて説明すると、ステージ２では、好ましくは、サービスプロバイダの機械室（machine room）を借り受け又は他の手法で確保し、ここに第２のｚボックス機器、例えばｚボックス２を配設する。例えば、ｚボックス機器は、ハイネットバックボーン（Hi-Net backbone）上に配設してもよい。顧客の敷地内において、ｚボックス２から又はへの単一の接続（トンネル）を設定することができる。
【０１３７】
この場合、顧客の敷地内のｚボックス２は、購読者エージェント（例えば、エージェント１２８）として機能する。また、ｚボックス２は、経路選択デーモン（例えば、経路選択デーモン２１６）としても機能することができる。ｚボックス２は、購読者エージェントとして（例えば、ハイネット機械室（Hi-Net machine room）内において）、好ましくは、ＤＶＲがｚボックス１を介して発行する情報を購読する。ｚボックス１とｚボックス２間は、上述のような発行−購読ネットワークである。したがって、ｚボックス１は、ＤＶＲからのビデオ情報を発行し、ｚボックス２は、ＤＶＳＳによる要求に応じて、このビデオ情報を購読する。このように、ここに開示する事象通知システムを用いることによって、警告サービスのデータ配信効率が向上する。ｚボックス機器（例えば、ｚボックス１及びボックス２）は、好ましくは、上述のように、この発行−購読ネットワークを介して発行及び購読を行うためのモジュールを備えている。
【０１３８】
デジタルコンテンツ配信
上述したインテリジェントなコンテンツベースの経路選択は、購読予約を介したビデオ及び音楽の配信、ソフトウェアの更新等、様々な用途に用いることができる。例えば、ユーザは、例えば、ウィルス除去ソフト等のソフトウェアの更新を購読予約することにより、アップデートされたソフトウェアを自動的に受け取ることができる。他の実施例として、ユーザは、特定のビデオ及び音楽コンテンツを購読予約し、その購読されたコンテンツを自動的に受け取るようにしてもよい。ビデオ及び音楽コンテンツは、例えば、ストリーミングデジタルコンテンツとして受信することができる。更に、ネットワークコアにおける分散処理により、ソフトウェア、ビデオ及び音楽コンテンツを提供するためのサーバの処理負担を実質的に軽減することができる。したがって、他の様々な利点とともに、コンテンツを提供するための同じネットワークインフラストラクチャにおいて、ネットワーク帯域幅を有効に活用することができる。
【０１３９】
この経路選択を実現するためのアーキテクチャの一具体例を図２３に示す。なお、このアーキテクチャは、好ましくは、ネットワークサービスプロバイダの同じ設備内に配設されている２つのレベルのキャッシュサーバＣｌ、Ｃ２を想定する。但し、キャッシュサーバＣｌのみを用いても、本発明の利益を享受することができる。キャッシュサーバＣｌ、Ｃ２とは、上述した（図１４、図１５及び対応する説明参照）分散ネットワークキャッシングを提供するサーバである。このアーキテクチャは、例えば、２つの段階によって実現される。キャッシュサーバＣ２が存在しないと仮定する第１の段階では、セントラルディストリビュータ４５０とキャッシュサーバＣｌの間において、高速ファイル転送メカニズムを用いて、大きなメディアファイルを転送するために必要なサーバ負荷と時間を減少させる。この高速ファイル転送メカニズムは、好ましくは、セントラルディストリビュータ４５０とキャッシュサーバＣｌの間にルーティングボックス（図２３における４７０）設けることによって実現される。第２の段階では、キャッシュサーバＣ２において、ルーティングボックスを設け、ユーザ（例えば、ユーザマシン４６０）とキャッシュサーバＣ２の間で上述した購読予約メカニズムを実現する。
【０１４０】
ルーティングボックスを用いる利点：
ルーティングボックス４７０は、好ましくは、上述したようなコンテンツベースの経路選択を実現するためのモジュール（例えば、上述したインテリジェントルータ９２）を備える。上述したコンテンツベースの経路選択を実現するルーティングボックス４７０を用いる主な利点は２つある。これらのルーティングボックス４７０を用いた高速ルーティング及びファイル転送ソリューションにより、ＦＴＰやＲＣＰ等の従来のファイル転送プロトコルに比べて５倍程度ファイル転送を加速できる。また、広域ネットワーク（ＷＡＮ）を介した効率的なマルチキャストを実現できる。中央から受信機のグループにデータを送信する場合、このルーティングソリューションでは、ネットワークマルチキャストトポロジーを利用し、ＷＡＮの上でマルチキャスティングトンネルを構築することによってコンテンツ配信速度が加速され、サーバ負荷とネットワーク帯域幅要求を軽減することができる。
【０１４１】
アーキテクチャ：
メディアコンテンツは、セントラルディストリビュータからキャッシュサーバＣ１に配信される。キャッシュサーバＣｌは、全てのコンテンツファイルを保存する。各キャッシュサーバＣｌは、全てのコンテンツを保存するために、例えば、数テトラバイトのディスク容量を必要とする。ユーザは（例えば、購読者装置１２２等のユーザマシン４６０を用いて）、コンテンツの一部のみを保存するキャッシュサーバＣ２に対してコンテンツを要求する。キャッシュサーバＣ２は、例えば、数百ギガバイトものディスク容量を必要とする。
【０１４２】
ユーザとＣ２キャッシュの間のファイル転送：
ユーザ４６０が購読予約を発行することによってメディアファイルを要求すると、キャッシュサーバＣ２の１つによって処理される要求されたメディアファイルがＣ２サーバに既にキャッシングされている場合、ファイルは、直ちに提供される。これ以外の場合、購読予約は、キャッシュサーバＣ１に送信され、要求されたファイルは、キャッシュサーバＣ１からキャッシュサーバＣ２に転送される。
【０１４３】
ＣｌキャッシュからＣ２キャッシュまでのメディアデータの予備的キャッシング（Pre-caching）：
メディアファイルは、ユーザ購読予約又は購読予約のパターンに基づいて、キャッシュサーバＣ１からキャッシュサーバＣ２に予めキャッシングしてもよい。例えば、キャッシュサーバＣ２に接続するユーザ４６０が主にポップスに関心がある場合、キャッシュサーバＣ１は、ユーザ４６０がキャッシュサーバＣ２に曲を要求する以前に、ポップスの新たな曲をキャッシュサーバＣ２に自動的に供給してもよい。
【０１４４】
導入段階：
第１の段階は、例えば、ディストリビュータ４５０と、全てのキャッシュサーバＣ１との間のコンテンツルーティングを行う高速ファイル転送メカニズムをインストールする処理を含む。ここでは、キャッシュサーバＣ２は、不要である。この場合全てのユーザ４６０は、キャッシュＣｌに直接接続する。キャッシュサーバＣ１は、ディストリビュータ４５０から定期的に新たなメディアファイルを受け取る。図２４は、第１の段階のアーキテクチャを示している。
【０１４５】
なお、図２４において、ディストリビュータ４５０は、上述したインテリジェントなコンテンツベースの経路選択技術に基づき、ルーティングボックス４７０に新たなメディアファイルを一回だけ送信する。したがって、ディストリビュータ４５０の負担が軽減される。ルーティングボックス４７０は、高速ファイル転送メカニズムを用いて、各キャッシュサーバＣ１にファイルを出力する。この場合、受信機４６０の側では、更なるルーティングボックスは不要である。これに代えてキャッシュサーバＣ１のために他の種類のサーバを用いてもよい。
【０１４６】
図２５は、第２段階の実施例のアーキテクチャを示している。この実施例に示す第２の段階では、好ましくは、カーネルを実装するルーティングボックス４７０を用いて、データをルーティング及び送信している。カーネルレイヤソリューションは、バッファコピーを低減し、コンテキスト切換時間を短縮するため、ファイルを送る際のオーバヘッドを更に減少させる。更に、第２の段階のソリューションでは、図２５に示すように、キャッシュサーバＣ２をアーキテクチャに追加する。また、図２５に示すように、好ましくは、Ｃ２側において、サービスプロバイダネットワーク内の同じ位置に、ルーティングボックス４７０が追加されている。これにより、帯域幅要件が大幅に軽減され、帯域幅を数百分の一にできる可能性もある。
【０１４７】
図２５に示すように、キャッシュサーバＣ１とキャッシュサーバＣ２の間で転送されるファイルは、キャッシュサーバＣ１に関連付けられるルーティングボックス４７０と、キャッシュサーバＣ２に関連付けられるルーティングボックス４７０とを介して転送される。このように、これらのルーティングボックス４７０を用いて、キャッシュサーバＣ１、Ｃ２の間において、高速ルーティング及びファイル転送ソリューションが実現される。
【０１４８】
サービス品質の管理
上述したインテリジェントなコンテンツベースの経路選択は、例えば、特定の配信を保証するコンテンツのルーティングのために用いることができる。例えば、サービス品質保証制度（service level agreement：以下、ＳＬＡという。）に基づいて、ＩＳＰ又はコンテンツプロバイダは、サービス品質（quality of service：以下、ＱｏＳという。）を保証するために帯域幅を確保することができる。これは、上述したコンテンツベースのインテリジェントルーティングによって効率的に実現される。
【０１４９】
アーキテクチャ：
コンテンツ配信におけるＱｏＳを保証するために、少なくとも２つの可能な構成がある。第１の構成では、複数のリンクを１つ以上の電話会社（telephone company：以下、ＴＥＬＣＯという。）のネットワークに接続する。第２の構成では、ＴＥＬＣＯネットワークへの１つのネットワークリンクだけを用いる。図２６に示す実施例では、２つのレイヤのルーティングボックス（以下、Ｒボックスともいう。）を設けている。Ｒボックス１は、データパケットのコンテンツに基づいて、Ｒボックス２とＲボックス３にパケットをルーティングする。Ｒボックス２とＲボックス３は、異なるネットワークリンク（例えば、Ｌ１−Ｌ４）にデータパケットをルーティングする。各リンクは、ＴＥＬＣＯネットワークに接続されている。プレミアムユーザ（premium customers）のための帯域幅を確保するために、最も高いＳＬＡに対応する顧客用に生成されたデータパケットは、最も高い帯域幅（最も高い優先順位）でリンクにルーティングされ、これにより、これらの顧客のための特定のＱｏＳが保証される。
【０１５０】
図２７に示す実施例では、Ｒボックス１は、Ｒボックス２及びＲボックス３にデータパケットをルーティングする。Ｒボックス２とＲボックス３は、更に異なる通信リンクにデータパケットをルーティングし、これらの通信リンクは、全てＲボックス４に接続されている。Ｒボックス４は、４つのリンクからそれぞれのリンクのＱｏＳレベルに基づいて、データパケットを受信する。そして、Ｒボックス４は、ネットワークリンク（例えば、Ｌ５）を介して、インターネットＩＳＰにデータパケットを送信する。このシステムは、各リンクからデータを受け取るための様々なアルゴリズムを実装することによって、各リンクについて、帯域幅を動的に割り当てることができ、マルチリンク構成より優れたＱｏＳ管理を行うことができる。
【０１５１】
技術：
ＱｏＳ保証には、インテリジェントで分散型の上述したコンテンツベースの経路選択技術を利用することができる。ルーティングされる各パケットは、コンテンツベースの経路選択のためにタグが付される。このソリューションによって、他の様々な利点とともに、ＡＳＰ／コンテンツプロバイダのためのＱｏＳの展開が経済的に可能になる。
【０１５２】
利点：
このソリューションにより、インターネット接続サービス業者（例えば、ＩＤＣ）又はコンテンツプロバイダ（例えば、メディアオンデマンドの（ＭＯＤ）サービスプロバイダ）は、顧客毎に、それらのＳＬＡＳに基づいて個別に帯域幅を確保できる。
【０１５３】
リアルタイムの警告：
警告に異なる優先順位を付すことができる。例えば、セキュリティ及び火災警報に最も高い優先順位を与え、ニュースの告知には、低い優先順位を与えることができる。ＱｏＳルーティングを行わなければ、優先度が低い警告及び通信によってＡＳＰのネットワーク帯域幅を占領され、最優先の警告がリアルタイムで購読者に届かないこともある。このソリューションは、このような事態の発生を防ぐ。また、警告は、それぞれのＳＬＡＳに基づいて、各顧客に送信することもできる。プレミアムユーザがより多くの料金を支払うことにより、これらのユーザに対してより広い帯域幅を割り当てるようにしてもよい。
【０１５４】
実時間データ配信：
例えば、ビデオオンデマンド（ＶＯＤ）、ＭＯＤ、及びＩＰを介した音声送信（ＶｏＩＰ）等の幾つかの用途では、帯域幅の利用可能性は、サービスの品質に影響する。このソリューションでは、上述のように、パケットのコンテンツを検査することによって、メッセージの種類に基づいてデータパケットをルーティングできる。帯域幅に大きく影響される用途では、それらのデータパケットをより高い優先順位のリンクにルーティングするとよい。メッセージの種類に加えて、購読者のＳＬＡレベルに基づいて、様々な購読者にデータパケットをルーティングしてもよい。このソリューションを用いることにより、ＳＬＡがより高い顧客に対しては、パケットをより高いレベルのリンクにルーティングできる。
【０１５５】
また、このソリューションは、ソフトウェア又はウィルス対策のための更新にも利用できる。例えば、音声用ドライバファイルは、優先順位が低いリンクにルーティングし、アンチウィルスファイルは、優先順位が高いリンクにルーティングすることにより、ウィルス対策のための更新をリアルタイムで行うことができる。
【０１５６】
コンテンツベースのフィルタリング：
図２８に示すように、コロケーションサービスを用いることにより及びＲボックスをＴＥＬＣＯネットワーク内部に配設することにより、システムは、ＩＳＰの外部でフィルタリング及び動的なキャッシングを実行することができる。ＴＥＬＣＯネットワーク内部のＲボックスを用いて、上述したコンテンツのフィルタリング技術に基づいて、データをフィルタリングすることにより、ＩＤＣ／ＩＳＰネットワークにおけるトラヒックを減少させることができる。これにより、例えば、サービス妨害攻撃や不正なデータアクセス等のハッカーアタックを防止することができる。また、Ｒ−ボックスは、要求のコンテンツを検査する能力により、静的及び動的なウェブデータのためのキャッシングボックスとしても機能する。このソリューションは、例えば、機密保護を可能にし、ＴＥＬＣＯとＩＳＰの間のネットワーク帯域幅を節約し、ＩＳＰサーバの負荷を軽減できる等の利点がある。
【０１５７】
選択的なマルチキャスティングによるキャッシング
メッセージの持続性とは、メッセージを保存し、後にこの保存されたメッセージを読み出すことができる性質を指す。例えば電子メールを始めとする多くの特定の用途では、通常、ネットワークを介して通信されるメッセージについて、長いメッセージ持続性が必要とされる。ネットワーク障害が発生しない理想的な条件では、常時接続された購読者は、これらの特定の用途において必要とされる以上の如何なる持続も求めない。しかしながら、現実には、メッセージは、ネットワークを介して伝送されている間に様々な理由のために「失われる」ことがある。この理由としては、例えば、（１）ネットワーク又はユーザ側における故障又はバッファオーバフローや（２）ユーザが自らネットワーク接続を切断した後、所定の期間経過後に再び接続する場合等がある。
【０１５８】
この実施例における事象通知プラットフォームの持続モデルは、短期持続と長期持続の２つのレベルに分割される。短期持続は、ネットワーク輻輳又は短期的なリンク障害のために失われたパケットを復元する。長期持続は、例えば、ユーザ接続の障害、ユーザ装置の障害、アプリケーションの障害及び／又はより長い期間ネットワーク内の障害等を含む他の障害に起因して失われたパケットを復元する。以下では、これらの２つのスキームの具体例について説明する。
【０１５９】
短期持続：データ再送及びフロー制御
データネットワークにおいては、データ損失の原因は、単に、リンク障害とバッファオーバフローの２つに分類できる。事象通知システムについて信頼できるチャンネルを提供するためには、これらの問題を解決する必要がある。リンク障害については、順方向誤り訂正（ＦＥＣ）スキームを実行して、リンク障害によって引き起こされる幾つかのエラーを修正することができる。ここで、エラーが深刻であり、如何なるＦＥＣスキームでもエラーを修正できないような場合、パケットを復元するための更なるスキームを提供する必要がある。また、バッファオーバフローの発生を防止する必要もある。データネットワークにおいて、このような問題を避けるためには、通常、フロー制御スキームが用いられる。
【０１６０】
短期持続スキームにおいては、好ましくは、伝送制御プロトコル（Transmission Control Protocol：以下、ＴＣＰという。）トンネルを用いて、ホップバイホップ方式でイベントルータ（例えば、インテリジェントルータ１２）を接続する。信頼できる転送プロトコル（例えば、ＲＭＴＰ）を用いる代わりに、信頼できるレイヤ−２トンネルを用いる理由は複数ある。短期持続スキームでは、好ましくは、事象通知システムにおいて、メッセージがフィルタ規則を満たさない場合、メッセージは、ルータにおいて、無視される。この結果、受信ルータは、多くの場合、ソースシーケンスナンバー（Source Sequence Number：ＳＳＮ）等のスキームを用いても、パケットの損失を検出できない。また、全ての受信ルータが、受信した各パケットについて肯定応答を行うことも望ましくない。このような処理を行うと、肯定応答のオーバロード（すなわち、ＡＣＫエクスプロージョン（ACK-explosion））が生じる。更にバッファオーバフローを避けるために短期持続モデルは、フロー制御スキームを実現し、これにより、ルータのバッファ容量が一杯になる前に、ルータは、自らにメッセージを送る隣接するルータに、メッセージの供給の速度を遅くするよう要求することができる。これらのスキームは、ＴＣＰによってカバーされている。
【０１６１】
ＴＣＰ伝送ポリシ：
短期持続スキームにおいて用いられるＴＣＰにおいては、好ましくは、データの送信側で、局所的に送信ウィンドウを用いて、再送処理されたデータを監視する。送信ウィンドウを用いる目的は、２つある。第１に、送信ウィンドウにより、送信側は、データが受信機によって正しく受信されたことを明示的に確認でき、第２に、送信ウィンドウにより、チャンネル容量をより有効に活用できる。ＴＣＰにおいては、送信側が送信した各バイトは、暗示的又は明示的に肯定応答を受ける必要がある。送信ウィンドウは、送信側が、送信され、肯定応答されたデータを監視するのに役立つ。送信側は、動作を止めて、先のパケットに関する肯定応答を待機する必要なく、送信ウィンドウ内でデータを送信できるので、また、送信ウィンドウにより、チャンネルの利用効率を向上させることができる。一旦、前のデータが肯定応答されると、ウィンドウは、自動的に進められる。
【０１６２】
また、ＴＣＰでは、受信ウィンドウも維持される。受信ウィンドウは、好ましくは、データ受信端末において、使用可能なバッファ容量を示すために用いられる。使用可能なバッファ容量が送信側に送られ、これにより送信側は、受信側におけるバッファオーバフローをどのように回避できるかを知ることができる。
【０１６３】
ＴＣＰ輻輳制御：
ＴＣＰは、エンドツーエンドトランスポートプロトコルとして設計されているので、短期持続スキームで利用されたＴＣＰは、発行−購読ネットワーク内におけるバッファオーバフローの問題も解決する。この問題を解決するために、短期間の持続モデルのために用いられるＴＣＰは、好ましくは、第３のウィンドウである輻輳ウィンドウ（congestion window）を用いる。送信側は、輻輳ウィンドウを用いて、パスに沿ったルータにおける最大のバッファ容量を推定することができる。簡潔に言えば、送信側がパケットの損失を検出すると輻輳ウィンドウのサイズが縮小され、逆にパケットの損失が検出されないと、輻輳ウィンドウのサイズが拡大される。
【０１６４】
長期持続：持続的なチャンネルのキャッシング
チャンネルは、（例えば、上述のように）持続的であっても又はリアルタイムであってもよい。リアルタイムチャンネルは、実時間においてのみ有用であり、アプリケーション固有の如何なる持続要求も有さないデータを送信する。持続チャンネルは、持続タイムフレームＴの間、ネットワークを介して送受されるデータを保存する。換言すれば持続チャンネルの持続性は、タイムフレームＴの間、保証される。このデータの持続性は、例えば、チャンネルの持続期間の間、それぞれのエッジノードでデータをキャッシングすること、障害が生じた条件下で、ユーザにトランスペアレントなキャッシュからのデータを検索すること、ユーザがキャッシュから明示的にデータを読み出すことができるようにすること、ルータ障害に対する保護及びルータの間で信頼できるトンネルを確立することにより、ネットワークを介したデータのフローを持続的にすること、及び複製によって、障害に対してチャンネル成分を保護すること等によって実現される。
【０１６５】
したがって、後述するように、長期持続スキームにより、購読者の端末に障害が生じ、持続的なチャンネルのためのタイムフレームＴ内に再び復帰すると、持続的なチャンネルに登録された購読者は、直前のタイムフレーム「Ｘ」（Ｘ＜Ｔ）の間、ネットワークにおいてキャッシングされた古いデータを検索することができる。
【０１６６】
長期持続スキームにおいては、購読者アプリケーション（例えば、アプリケーション１２６）は、関連する購読者エージェント（例えば、エージェント１２８）から好ましくは、明示的に、データ（例えば、メッセージ）をプルすることができる。上述のように、エージェントは、プロキシを利用でき又はプロキシによって実現することができる。エージェント又はプロキシがネットワーク内の障害から復帰した後、このエージェントは、キャッシュから、自らがエッジルータから切断されていた期間に対応するデータを好ましくはトランスペアレントに検索する。また購読者は、長期持続スキームにおいて、好ましくは、直前のＴタイムフレームに含まれるデータのみにアクセスすることができる。このため、好ましくは、エージェント（又はプロキシ）が接続されているエッジルータに関して、時間が判定される。検索されたキャッシングされたデータは、好ましくは帯域外で配信され、実時間配信は保証されない。長期持続スキームの実施例は、クラッシュから復帰した、又はエッジルータ（例えば、エッジルータ１６）から切断された既存の購読者を対象とするものである。新たな購読者は、キャッシングされた情報を得ることはできない。
【０１６７】
持続性の定義：
購読者に対する（タイムフレームＴによる）期限付きの持続性は、発行−購読ネットワークから直前のタイムフレームＴに含まれるデータを読み出すことができる能力として定義される。購読者がネットワークから切断されると、購読者の不在の間に受け取られた持続的なチャンネル上の如何なるデータも、（データの受信から）タイムフレームＴの間、ネットワーク内に保存される。購読者がタイムフレームＴ内に復帰した場合、購読者は、如何なるデータも失わない。但し、購読者がＴから２Ｔの期間内に復帰した場合、購読者は、データを失う可能性がある。また、購読者が２Ｔを過ぎて復帰した場合、購読者に対しては、好ましくは、それまでの如何なるデータも保証されない。
【０１６８】
上述の定義により、購読者をリーフとする発行−購読ネットワークツリーは、購読者が切断された後、タイムフレームＴの間保持され、その後に購読者を切り離す必要がある。これにより、購読者が切断された後、タイムフレームＴの間に受信された新たなデータは、タイムフレームＴが経過するまで保持される。
【０１６９】
アーキテクチャ：
図２９は、キャッシングによって持続性を実現する発行−購読ネットワークの一部を示すブロック図である。図２９に示すように、ネットワークは、コアルーティングノード５４８とエッジルーティングノード５４５とを備える。各ルーティングノードは、図４を用いて上述したように、好ましくは、インテリジェントルータ９２（エッジルーティングノードと共に示す）と、従来のバックボーンルータ（図示せず）とを備える。持続的なチャンネルのためのキャッシングを行う必要がある各インテリジェントルータ９２は、図２９に示すように、好ましくは同じ場所にキャッシュマネージャ２１８を備える。キャッシュマネージャ２１８については、図８を用いて上述した通りである。インテリジェントルータ９２は、好ましくは、失われたデータを読み出し又はルータ故障から復元するための短期的な持続性を実現する。キャッシュマネージャ２１８は、チャンネルにおける長期的な持続を実現するために、データをキャッシングする。キャッシュマネージャ２１８は、好ましくは、キャッシュ５４０内にこのデータをキャッシングする。キャッシュ５４０は、好ましくは、メモリとディスク（図示せず）を含んでいる。
【０１７０】
長期持続のためにデータをキャッシングするために、インテリジェントルータ９２に対して、キャッシュマネージャ２１８を設けることには、例えば次のような利点がある。キャッシングされたデータにインデックスを付すための負荷が大きい演算は、独立したプロセッサによって実行でき、したがって、ルーティング及びフィルタリングプロセッサの性能には影響がなく、及びキャッシングされたデータを定期的にディスクに移動するためのディスクＩ／Ｏ動作も他のプロセッサによって実行でき、これにより、ルーティングとフィルタリングからサイクルが奪われることを防ぎ、エッジルータが定期的な入出力動作を行う必要を無くすことができる。
【０１７１】
また、図２９に示すエージェント１２８は、図５を用いて上述したように、好ましくは、購読者装置１２２（図２５Ａでは示していない）内に設けられる。エージェント１２８は、キャッシュマネージャ２１８と通信し、キャッシュ５４０からデータを検索し、検索したデータを受け取り、検索したデータを組織化する。上述のように、エージェント１２８は、プロキシを利用でき又はプロキシによって実現することができる。
【０１７２】
障害が発生しない条件下では、エッジルータノード５４５のみが関連するキャッシュマネージャ２１８を有していればよい。しかしながら、図２９には示していないが、長期持続スキームでは、障害を予期しているので、好ましくは、エッジルーティングノード５４５より上流側にある第１のレベルのコアルーティングノード５４８のそれぞれがデータを保存するためのキャッシュマネージャ２１８を備えている。上流とは、エージェント１２８から遠ざかる（すなわち、購読者装置１２２から遠ざかる）方向である。第１のレベルの上流コアルーティングノードとは、エッジルーティングノード５４５より上流側に隣接するルーティングノードを意味する。発行−購読ネットワークは、多くの場合、複数の第１のレベルのコアルーティングノードを含んでいるが、図２９では、１つの第１のレベルのコアルーティングノード、すなわちコアルーティングノード５４８のみを示している。上述のように、キャッシュマネージャ２１８は、自らが存在するネットワークノードにおいて、データのローカルなキャッシングを実現する。したがって、例えば、コアルーティングノード５４８を含む様々なコアルーティングノードに存在するキャッシュマネージャ２１８の動作は、ネットワークコア内のデータの分散型のキャッシングを実現する。この分配型のキャッシングは、エッジルーティングノードのキャッシングにバックアップを提供する。
【０１７３】
図３０は、上流ルータ（例えば、コアルーティングノード５４８）におけるバックアップキャッシングを説明する図である。各長期持続スキームにおいては、各キャッシュは、次の上流ルータのキャッシュによってバックアップされる。上流のキャッシュは、全ての受信データを保存し、下流の次のレベルの全てのエッジルータのキャッシュのバックアップとして機能する。上流のキャッシュのデータは、好ましくは、エッジルータキャッシングと同じメカニズムを用いて保存される。
【０１７４】
図３１は、持続的なチャンネルのキャッシングのためのアーキテクチャを示しており、このアーキテクチャでは、好ましくは、以下のような４つの異なるモジュールに亘る機能を提供する。キャッシュマネージャ２１８は、好ましくは、インテリジェントルータ９２を通過するデータを保存するサーバ処理を行う。ルータキャッシュＡＰＩ５５２は、好ましくは、インテリジェントルータ９２からキャッシュマネージャ２１８への制御、例えば、キャッシュを作成及び消去する処理に関連する全てのアクセスのためのライブラリである。エージェント（又は、プロキシ）キャッシュＡＰＩ５５４は、好ましくは、エージェント１２８（又はエージェント１２８プロキシ）からキャッシュマネージャ２１８への制御、例えば、データの検索に関連する全てのアクセスのためのライブラリである。エージェント１２８（又はプロキシ）は、好ましくは、キャッシュ５４６から検索されたデータを収集し、このデータを組織化する。
【０１７５】
図３１を用いて、これらの４つのモジュールのインタラクションを説明する。エージェント１２８とインテリジェントルータ９２は、好ましくは、キャッシュＡＰＩライブラリ５５２、５５４を介してキャッシュにアクセスする。キャッシュＡＰＩライブラリ５５２、５５４は、キャッシュ５４６を初期化し、主語のためにキャッシュを作成及び消去し、キャッシュアドレスを検索し、及び最も重要な機能としてキャッシュ５４６からデータを検索するためのＡＰＩを提供する。経路選択デーモン２１６は、好ましくは、キャッシュＡＰＩ５５２を介さず、データパスを介して、キャッシュマネージャ２１８にデータを送信する。キャッシュＡＰＩ５５２、５５４は、データ検索を含む全ての制御メッセージについて、好ましくは制御パスを用いる。
【０１７６】
キャッシュマネージャ−キャッシュ管理：
図３２に示すように、キャッシュマネージャ２１８が新たなチャンネルに遭遇するとキャッシュマネージャ２１８は、好ましくは情報サーバ（例えば、上述したサーバ１５２、１５４及び／又は１５６）を呼び出し、そのチャンネルのためにチャンネルマネージャ１５０を獲得する。キャッシュマネージャ２１８がチャンネルマネージャ１５０のアドレスを得ると、キャッシュマネージャ２１８は、好ましくは、チャンネルマネージャ１５０からチャンネル特性を検索する。チャンネル特性には、例えば、チャンネル主語ツリー及び属性、チャンネルの持続特性、チャンネルの持続タイムフレーム（Ｔ）、及びキャッシングの精度等が含まれる。キャッシュマネージャ２１８が、所定の主語について、チャンネルを介して伝送されるデータのキャッシングを開始する前に、キャッシュマネージャ２１８において、その主語のキャッシュを作成する必要がある。キャッシュマネージャ２１８は、キャッシュ作成メッセージを待機し、そのメッセージに応じて、主語キャッシュを作成する。この主語キャッシュは、要求に応じて、消去され、中断され又は再開される。図３２は、購読予約に対するキャッシュの作成を示している。
【０１７７】
キャッシュマネージャ−キャッシュデータ入力：
キャッシュマネージャ２１８は、好ましくは、以下に示すような様々な手法によって、インテリジェントルータ９２に入るデータにアクセスすることができる。すなわち、インテリジェントルータ９２の入力リンク上の全てデータをキャッシュマネージャ２１８にも送るＩＰと同様のソリューションを用いてもよい。また、スニフィングメカニズムを用いてもよい（この場合、キャッシュマネージャ２１８は、インテリジェントルータ９２のネットワークを介して伝送される全てのパケットを待機する）。また、フィルタリングの後に、インテリジェントルータ９２が、１つ以上のリンクに伝搬させる必要がある各メッセージをキャッシュ５４６に供給してもよい。また、キャッシュマネージャ２１８は、全てのインテリジェントルータ９２に供給されるデータに関する購読者として機能してもよい。
【０１７８】
キャッシュマネージャ−キャッシュデータストレージ：
図３３に示すように、好ましくは、キャッシュマネージャ２１８は、例えば、チャンネルＩＤ、主語、発行者ＩＤ、タイムスタンプ、タイムグレイン（Ｇ）、プライマリキャッシング属性、リンク（キャッシングが障害のために行われる特別な場合）及び他の様々な手法によって、キャッシュ５４６内のデータにインデックスを付す。データにインデックスを付し、ファイルシステム又はメモリ内の階層的ディレクトリ構造に保存してもよい。データは、好ましくは、メモリ内にキャッシングされ、定期的にディスクに移動される。メモリ内のキャッシングは、タイムグレイ「Ｇ」の期間のみ行われる。タイムグレインＧが経過すると、ツリー内の特定のブランチに関連する全てのデータは、好ましくは、そのブランチの下のファイルに移動され、そのブランチの最も古いファイルに上書きされる（なお、各メッセージをディスクに個別に書き込むことは高価であり、Ｇ期間を一回の動作でディスクに書き込んだ方が効率的であるためタイムグレインＧは、好ましくは、スライディングウィンドウとしてではなく、絶対ウィンドウとして実現する）。図３３は、インデックスツリーの具体例を示している。持続性のためにデータをキャッシングする場合、好ましくは、図３３に示す第１のインデックスツリーを用いる。
【０１７９】
図３３に示すように、主語は、好ましくは、階層構造内に保存され、ここで、「ａ」は、例えば「ａ．ｂ」、「ａ．ｃ」、「ａ．ｄ」等の主語の親である。キャッシュマネージャ２１８は、キャッシュ５４６のために、全ての主語を対応するファイル位置にマッピングするハッシュテーブルを保管する。幾つかの具体例では、キャッシュ５４６は、上流ルータ（例えば、コアルーティングノード５４８）がそのリンク上の下流のルータ（例えば、エッジルーティングノード５４５）における障害を検出した場合、障害が発生した条件下で、データを保存する必要がある。復旧のための１つの手法は、下流のルータを再起動することである（この処理は、数分もかかることがある）。下流のルータが再起動されている間、上流ルータは、そのリンクの下流方向に供給するデータをキャッシングする必要がある。このキャッシュ（例えば、図３３ではＦＭキャッシュと示す。）は、好ましくは、出力側のリンク上でインデックスが付される。
【０１８０】
キャッシュマネージャ：ガーベージコレクション：
チャンネルが持続的でない場合、キャッシュ５４６は、データを保存せず、直ちにデータを消去する。チャンネルが持続的である場合、キャッシュ５４６は、データを保存する。特定のチャンネルの持続タイムフレーム「Ｔ」は、それぞれサイズがＧであるＮ個のタイムグレインに分割される。メモリへのキャッシングは、Ｇに対応する期間のみ行われる。キャッシュマネージャが、期間Ｇが経過したと判定すると、データは、ディスクに移動される。キャッシュマネージャ２１８は、持続タイムフレーム期間Ｔの間、データをディスクに保存する。
【０１８１】
期間Ｇに対応するデータは、時間が、そのチャンネル＋期間の上限の持続タイムフレーム期間（Ｔ）を過ぎた場合、ディスクから削除される。具体的には、例えば、チャンネルの持続タイムフレーム期間Ｔが２時間であるとする。ここでは、例示的に、キャッシュマネージャ２１８は、１５分のタイムグレインＧを用いるとする。この場合、データをディスクから削除するための規則は、次の通りである。すなわち、期間Ｇ（１５分）の間に最後にキャッシングされたデータが期間Ｔ（２時間）の間保存された場合、その１５分の期間の間にキャッシングされた全てのデータが破棄される。したがって、その１５分の期間の最初にキャッシングされたデータは、破棄されるまでに、２時間より長く保存されることとなる。この実施例では、各１５分の期間にキャッシングされるデータは、データのブロックである。持続タイムフレームＴがＮ個の期間に分割される場合、如何なる時刻においても、各主語のためのキャッシュ５４６において、Ｎ＋１個（ディスクにＮ個とメモリに１個）のデータのブロックが保存される。
【０１８２】
キャッシュマネージャ−キャッシュデータ検索：
図３４に示すように、エージェント１２８（又はプロキシ）は、好ましくは、キャッシュ読出処理（GetCache operation）を呼び出し、現在の時間から期間Ｔ分遡ったデータを入手する。図３４においては、キャッシュ読出処理を呼び出すためにエージェント１２８が接続するキャッシュマネージャ２１８には、ポータルキャッシュのラベルを付している。ルータ又はエージェント１２８の失敗／切断のため、ポータルキャッシュは、エージェント１２８によって要求されたデータの全てを有していない場合がある。この場合、ポータルキャッシュは、他の全てのキャッシュ（例えば、上流のキャッシュ）からデータを検索し、データを照合し、このデータをエージェント１２８に返す。図３４は、異なるタイムスタンプ（ＴＳ１、ＴＳ２、ＴＳ３）に対する、複数のキャッシュ（Ａ、Ｂ、Ｃ）からの検索を示している。
【０１８３】
キャッシュマネージャ２１８は、好ましくは、タイムグレインＧのデータのブロックのみを検索する。したがって、エージェント１２８には、予期又は要求したデータより多くのデータが提供されることもある。更に複数のキャッシュから検索を行うと、キャッシュ間において、幾つかの期間が重複し、エージェント１２８は、データが重複して供給されることもあり、このため、エージェント１２８は、キャッシュによって提供されるデータストリームにおける重複を削除する必要がある。
【０１８４】
キャッシュマネージャの他のモジュールとのインタラクション：
キャッシュマネージャ２１８は、好ましくは、図３５に示すように、事象通知システムインフラストラクチャにおいて、幾つかのモジュールとインタラクトする。キャッシュマネージャ２１８が（キャッシュ作成時に）新たなチャンネルに遭遇すると、キャッシュマネージャ２１８は、好ましくは、そのチャンネルのチャンネルマネージャ１５０を得るために情報サーバ５５０を呼び出す。一旦、キャッシュマネージャ２１８がチャンネルマネージャ１５０のアドレスを得ると、キャッシュマネージャ２１８は、好ましくは、チャンネルマネージャ１５０からチャンネル特性に関する情報を得る。アドミニストレータモジュール５５２は、好ましくは、キャッシングの分割の度合い等の幾つかの特性を設定／変更することができる。また、アドミニストレータモジュール５５２は、好ましくは、マニュアルでチャンネルキャッシュを作成／削除することもできる。
【０１８５】
エージェントキャッシュＡＰＩ−アプリケーションエージェントインタラクション：
アプリケーション（例えば、アプリケーション１２６）は、好ましくは、エージェントキャッシュＡＰＩ５５４を呼び出し、所定の主語とフィルタとともにキャッシュ５４６を得る。好ましくは、アプリケーションは、既にそのデータを購読予約している場合、キャッシュ５４６からそのデータのみを検索することができる。エージェントキャッシュＡＰＩ５５４は、実際には、好ましくは２つのＡＰＩを提供する。
【０１８６】
第１のＡＰＩにより、購読予約していないアプリケーションは、キャッシュ５４６の購読予約と検索を同時に行うことができる。「ＦＩＦＯ」フラグが設定されている場合、購読予約が作成され、エッジルータノード５４５に送信される。エージェント１２８がキャッシングされた全てのデータを受け取った後に、エージェント１２８は、まず、キャッシングされた全てのデータを配信し、そのデータにおいて、全ての発行者が確認できなかった最後のシーケンスを監視し、この各発行者が確認できなかった最後のシーケンスから、中断されたデータを配信する。
【０１８７】
第２のＡＰＩでは、アプリケーションが既にあるデータを購読予約し、キャッシングされたデータを要求していると仮定する。この場合、アプリケーションには、キャッシュデータに関して、連続的ではない幾つかのデータが既に配信されている。この具体例では、「ＦＩＦＯ」フラグは、単に、キャッシュ５４６から読み出されたデータが自ら順序を決定するが通常のデータストリームと同様の順序である必要はないことを示す。
【０１８８】
エージェント１２８は、好ましくは、１つの大きなデータのブロック内の全てのイベントを読み出す。エージェント１２８は、キャッシュＡＰＩ５５４からデータを読み出した後、好ましくは、コールバック動作を呼び出す前に（上述参照）、データに対して以下のような動作を行う。この動作とは、通知のリストからの通知の生成、各発行者について、最後のシーケンス番号の監視、及びフィルタリングである。エージェント１２８によって全てのイベントをコールバックに渡す処理が完了すると、エージェント１２８は、キャッシュ完了イベント（DoneCache event）をコールバックに渡し、キャッシングされた全てのデータが配信されたことを示す。このとき、購読予約がＦＩＦＯであり、通常のデータが中断されている場合、エージェント１２８は、好ましくは、中断された全ての通知を配信する。このとき、エージェント１２８は、シーケンス番号がキャッシングされたデータにおける最後のシーケンス番号より大きい通知のみを配信する。
【０１８９】
エージェントキャッシュＡＰＩとキャッシュのインタラクション：
購読者がキャッシングされたデータを供給した場合、エージェント１２８側のキャッシュＡＰＩ５５４は、好ましくは、まず、エージェント１２８が接続されているエッジルータに関する履歴を調べ、キャッシュ読出要求（GetCache request）によって定義されている期間を用いて、リストをフィルタリングする。ＡＰＩ５５４は、キャッシュ読出（GetCache）（チャンネル、主語、フィルタ、local_pubs、time_period、ＦＩＦＯ、ルータのアレー）メッセージをＡＰＩ５５４が接続されていた最後のエッジキャッシュに送信する。キャッシュマネージャ２１８は、好ましくは、チャンネルＩＤ、主語及びタイムスタンプに基づいてデータをプルし、このデータをエージェント１２８に戻す。キャッシュマネージャ２１８によるデータの供給が完了すると、キャッシュマネージャ２１８は、キャッシュ完了イベント（DoneCache event）をキャッシュＡＰＩに渡し、データの転送がキャッシングされた全てのデータが配信されたことを示す。
【０１９０】
キャッシュマネージャ２１８がデータをローカルで検出できない場合、キャッシュマネージャ２１８は、エージェント１２８によって提供される「ルータのリスト」を用いて、必要なデータを検索する。キャッシュマネージャ２１８が必要な全てのデータを集めると、キャッシュマネージャ２１８は、必要なデータを照合し、重複削除を行った後に、このデータをエージェント１２８に供給する。
【０１９１】
キャッシュ接続履歴：
キャッシュ５４６からのデータの検索を可能にするために、好ましくは、エージェント１２８において、上流のキャッシュと同様に両方の側のキャッシュに関するキャッシュ接続履歴が維持される。この情報は、エージェント１２８がシャットダウン及びクラッシュした場合に必要であるので、この情報は、ファイルに持続的に保存する必要がある。キャッシュ接続履歴は、好ましくは、以下のようなファイル及びフォーマットによってディスクに保存される。
【０１９２】
エッジキャッシュ位置：
エッジキャッシュの位置（例えば、エッジルーティングノード５４６のキャッシュ５４６）は、好ましくは、チャンネルマネージャ／チャンネルライブラリから得られる。これは、起動時及びこれに続く、例えば、接続の切断／再接続、接続の変更等によってエッジキャッシュが変化した、如何なる時点でも発生する。ディスパッチャは、エッジキャッシュ接続の全ての変化をエージェント１２８に通知し、これらの変化は、エージェント１２８のキャッシュライブラリに伝えられる。変化が起こるたび、その情報は持続される。
【０１９３】
持続的なストレージ：CACHE_ROOT／channel_id／Channel−キャッシングされたデータのためのパスの具体例
データは、好ましくは次のようなフォーマットで保存される。
エッジキャッシュの数；
エッジキャッシュ１：インターバルの数、StartTimel：EndTimel、StartTime2：EndTime2、．．．；
エッジキャッシュ２：インターバルの数、StartTimel：EndTimel、StartTime2：EndTime2、．．．；・・・
ここで、最後のタイムスタンプがリストの最初に設けられる。なお、２つの異なるエッジキャッシュが重複する期間を有することはない（エージェント１２８は、一度に１つのエッジキャッシュのみに接続されるため）。新たなエントリが追加される毎に、古いエントリは、それらがまだ有効であるか確認され、それらが無効である場合、このエントリは、削除される。期間は、時刻EndTime＋チャンネルの持続期間＜現在の時刻となった場合、無効となる。
【０１９４】
エッジキャッシュエントリは、エントリ内の全ての期間が無効になった場合、無効になる。なお、「EndTime」が０であるということは、その期間が現在有効であることを意味する。
【０１９５】
上流のキャッシュ位置：
上流のキャッシュ（例えば、コアルーティングノード５４８のキャッシュ５４６）の位置は、主語に依存している。各主語は、それ自身のマルチキャストツリーを有し、したがって、第１のレベルの上流のキャッシュの組は、主語の関数である。ユーザが主語を購読予約すると、インテリジェントルータ９２は、必ず主語に関連している上流のキャッシュのリストを返す。同様に、障害又はマルチキャストツリーの再構成に起因する上流のキャッシュ位置のあらゆる変化は、制御パスを介してエージェント１２８に伝えられる。これらの変化は、持続的なメモリ（ファイル）に局所的に記録される。
【０１９６】
持続的なストレージ：CACHE_ROOT／channel_identifier／subject（階層ではなく、完全な主語）−キャッシングされたデータのためのパスの具体例
データは、好ましくは、以下のフォーマットで保存される。
上流キャッシュの数；
上流キャッシュ１：インターバルの数、StartTimel：EndTimel、StartTime2：EndTime2，．．．；
上流キャッシュ２：インターバルの数、StartTimel：EndTimel、StartTime2：EndTime2、．．．；・・・
ここでも、最後のタイムスタンプがリストの最初に設けられる。エッジキャッシュ期間とは異なり、エージェント１２８は、所定の主語について、複数の上流のキャッシュを有することができるので、２つの上流キャッシュが重複する期間を有することがある。また、上流のキャッシュファイルのコンテンツは、エッジキャッシュの場合と同様なアルゴリズムを用いて集められたガーベージである。
【０１９７】
データ検索の間のキャッシュ妥当性：
エージェント１２８が有効な間、エージェント１２８は、接続を介して、異なるエッジルータ及び上流ルータ間を移動する。エージェントキャッシュＡＰＩ５５４は、好ましくは、この接続履歴をローカルメモリに保存する。エージェント１２８が、キャッシュ５４６からデータの最後のＴ期間を読み出す必要がある場合、エージェントキャッシュＡＰＩ５５４は、好ましくは、接続履歴を調べ、そのデータにアクセスするためのキャッシュを判定する。これのために用いられるアルゴリズムは、好ましくは以下の通りである。（１）キャッシュライブラリは、全てのエッジキャッシュ期間を探検し、Ｔタイムフレーム内に含まれる期間を確認する。（２）リストＬｅは、期間開始時刻に基づいて、リストＬｅをソートする。（３）ＬＥ内のエッジキャッシュによってカバーされていない各期間について、上流キャッシュを探索し、この期間をカバーできる全ての上流キャッシュ期間に関する情報を得て、有効な期間をリストＬｕに加え、ＬｅにＬｕを追加し、期間開始時刻を用いてＬｅをソートし、Ｌを作成する。
【０１９８】
このアルゴリズムによりキャッシュのリストＬが生成され、各キャッシュについて、データを読み出すための期間が得られる。次に、このキャッシュのリストＬは、（４）キャッシュ読出メッセージに組み込まれ、キャッシュマネージャ２１８に送信される。キャッシュマネージャ２１８側では、キャッシュマネージャ２１８は、好ましくは、（５）ゲットキャッシュメッセージからキャッシュ期間を取り出し、開始時刻順にソートされたリストＬを再構築する。リストＬの各期間の間、キャッシュマネージャ２１８は、好ましくは、（６）前の期間と現在の期間の間に、隙間があるか否かを確認し、隙間があれば、そのデータのローカルキャッシュを要求する。このような隙間がなければ、キャッシュマネージャ２１８は、好ましくは（７）関連するキャッシュにデータを読み出すよう指示する。キャッシュマネージャ２１８は、好ましくは（８）全てのキャッシュからのデータを照合し、このデータをエージェント１２８に送信する。
【０１９９】
ルータキャッシュＡＰＩ：
インテリジェントルータ９２側のルータキャッシュＡＰＩ５５２は、特定の主語のためのキャッシングを作成し、消去し、停止し、再開するためにキャッシュマネージャ２１８を呼び出す。また、ルータキャッシュＡＰＩ５５２は、初期の構成を処理する。すなわち、ルータキャッシュＡＰＩ５５２は、インテリジェントルータ９２からチャンネルマネージャ１５０にキャッシュアドレスをアップロードし、これにより、エージェント１２８側（エージェントキャッシュＡＰＩ５５４）は、必要なときにこの情報を得ることができる。更に、ルータキャッシュＡＰＩ５５２は、他のルータのキャッシュ５４６の位置を読み出す（この位置は例えば、購読予約に対する応答において及び主語ツリーの変更の後にインテリジェントルータ９２が所定の主語のための上流キャッシュをエージェント１２８に通知する際に用いられる）。
【０２００】
プルのためのキャッシュの使用：
上述の説明では、持続的なチャンネルを実現し、購読者がネットワークからデータをプルすることによって情報を返すためのキャッシュの使用に焦点をあてた。変形例では、如何なる購読者（新たな購読者又は復帰した購読者）もキャッシュ５４６から（例えば、購読者が購読予約していないが、他の誰かの購読予約のためにキャッシュ５４６に保存されているデータを含む）あらゆる種類のデータをプルすることができる。この実施例と先の実施例との違いは、復帰した購読者については、データの存在が保証され、データの位置は、既知であるが、新たな購読者については、保存されているデータの位置が未知であるという点である。この変形例を実現する単純な手法は、チャンネルにおいて「キャッシュ検出（FindCache）」要求を発行することである。キャッシュ検出要求は、チャンネルＩＤ、主語、フィルタ、期間及び要求されたキャッシングされたデータを有するキャッシュ５４６を探すエージェント１２８の位置を含んでいる。全てのキャッシュ５４６がキャッシュ検出要求を待機している。各キャッシュ５４６が要求を受け取ると、キャッシュ５４６は、対応するデータが自らのデータストアにあるか否かを確認し、自らがそのデータを保存している場合、自らの位置をユニキャストメッセージとして返す。エージェント１２８は、キャッシュ５４６の１つを選択し、そのキャッシュ５４６をキャッシュ読出処理によって呼び出し、そのデータを得る。
【０２０１】
最新データプル：
他の実施例では、購読者アプリケーション（例えば、アプリケーション１２６）が所定の主語について、最新のメッセージを得ることができる最新データプルを実現する。これは、例えば、株価警告等のデータに有効であり、この場合、ユーザは、履歴ではなく、最新の株価に関する情報のみを希望する。
【０２０２】
キャッシュマネージャの実現：
キャッシュマネージャ２１８の実現においては、好ましくは、３種類のスレッドを用いる。データキャッシングスレッド−データキャッシングスレッドは、好ましくは、インテリジェントルータ９２への接続からデータを取り出し、データにインデックスを付してメモリに保存する。データストレージスレッド−期間の最後に到達すると、データストレージスレッドは、メモリに保存されているデータをディスクに移動させ、及びこの処理において、期限切れのデータに関するガーベージコレクションを実行する。データ検索スレッド−データ検索スレッドは、好ましくは、キャッシングされたデータの要求を受け、キャッシュ５４６からデータを検索する。これらの３つの種類のスレッドは、単一のスレッドとして実現してもよく、スレッドのプールとして実現してもよい。好ましくは、データキャッシングスレッドとデータストレージスレッドは、データがディスクに移動される時刻に同期される。このようにデータストレージスレッドとデータ検索スレッドとを同期させることにより、データの検索中にデータが消去されることが防止される。
【０２０３】
データ構造：
キャッシングのためのデータ構造の具体例は、表１９及びこれに関連する説明に記した通りである。
【０２０４】
データストレージ：
図３６は、「アクイラキャッシュ（Aquila Cache）」と呼ばれるキャッシュ５４６にデータファイルを保存するために用いられる好適なディレクトリ構造を示している。なお、各主語レベルのディレクトリは、好ましくは、その主語について発行されるデータを保存するデータディレクトリに加えて、１組の子主語ディレクトリを有する。例えば、エンターテインメントチャンネルにおいて、ＦＯＸムービーから発行されたデータは、AquilaCache／エンターテインメント／ＦＯＸ／ムービー／データ（AquilaCache/Entertainment/FOX/Movies/Data）のディレクトリのファイルに格納され、主語ＦＯＸについて発行されたデータは、AQUILACACHE／エンターテインメント／フォックス／データ（AquilaCache/Entertainment/FOX/Data）のディレクトリのファイルに格納される。データのストレージを高速に行うために、好ましくは、インテリジェントルータ９２がキャッシュ５４６に対し、所定のチャンネルと主語に関するキャッシングを開始するよう要求した時点で、特定の主語のディレクトリ階層を構築する。
【０２０５】
データ検索：
キャッシュ５４６からのデータ検索は、データのストレージを妨げないように、及びキャッシュ５４６がホールドアップしないように、効率的に行う必要がある。このデータ検索では、ディスクとメモリの両方からデータを読み出す。データ検索においては、好ましくは以下のようなステップを実行する。（１）データノードの位置を検出する。（２）データノードをロックする。（３）呼び出す必要があるデータのタイムスタンプを検出する。（４）データを読み出し、メモリに保存する。（５）データノードをロック解除する。（６）メモリに保存され、読み出されたデータをフィルタリングし、並べ替えた後、エージェント１２８クライアントにプッシュする。
【０２０６】
以上、例示的な実施例を用いて本発明を説明してきたが、これらの実施例を様々に変形できることは当業者にとって明らかであり、本発明は、これらの如何なる適応化又は変形をも含む。例えば、本発明の範囲から逸脱することなく、様々な種類の発行者装置、ユーザ又は購読者装置、これらのチャンネル及び構成、コンテンツベースの経路選択及び他の機能のハードウェア及びソフトウェアによる実現が可能である。この発明は、特許請求の範囲及びその均等物によってのみ制限される。

【特許請求の範囲】
【請求項１】
プロセッサによって実行され、ネットワークにおいて、サービス品質保証に基づいてパケットをルーティングするルーティング方法において、
ヘッダ部と、ペイロード部とを有するパケットを受信する受信ステップと、
ネットワークコアにおいて、上記パケットをルーティングする前に、該パケットのペイロード部を検査する検査ステップと、
上記パケットの確保された帯域幅に関する上記サービス品質保証を判定する判定ステップと、
上記検査及び上記サービス品質保証に基づいて、上記パケットを選択的にルーティングするルーティングステップとを有し、
上記検査ステップは、
上記ペイロード部からデータ属性を抽出するステップと、
上記抽出したデータ属性を２つ以上の属性フィルタと比較するステップと、
上記２つ以上の属性フィルタのそれぞれが満たされる場合、１組の機能を実行するステップとを有し、
上記各属性フィルタは、購読者が、発行者から受信した興味があるイベントの組を記述していることを特徴するルーティング方法。
【請求項２】
上記検査ステップを、上記ネットワークコア内のルータで実行するステップを更に有する請求項１記載のルーティング方法。
【請求項３】
上記検査を実行するために、上記属性フィルタを、上記ネットワーク内のルータに伝搬するステップを更に有する請求項１記載のルーティング方法。
【請求項４】
上記受信ステップ、検査ステップ及びルーティングステップを実行するために、上記ネットワーク内のルータをプログラミングするステップを更に有する請求項１記載のルーティング方法。
【請求項５】
上記１組の機能は、上記パケットをどのようにルーティングするかを決定することを含むことを特徴とする請求項１記載のルーティング方法。
【請求項６】
プロセッサによって実行され、ネットワークにおいて、メッセージをルーティングするルーティング方法において、
ヘッダ部と、少なくとも１つの主語と、複数のデータ属性とを有するメッセージを受信する受信ステップと、
上記メッセージから、上記主語及び上記データ属性を読み出す主語／属性読出ステップと、
上記主語に基づいて、複数の属性フィルタを指定する購読予約を読み出す購読予約読出ステップと、
上記メッセージの確保された帯域幅に関するサービス品質保証を判定するステップと、
上記メッセージをどのようにルーティングするかを決定するために、ネットワークコアにおいて、上記購読予約に上記データ属性を適用する適用ステップと、
上記適用及び上記サービス品質保証に基づいて、上記メッセージを選択的にルーティングするステップとを有し、
上記適用ステップは、
上記パケットから上記データ属性を抽出するステップと、
上記抽出したデータ属性を２つ以上の属性フィルタと比較するステップと、
上記２つ以上の属性フィルタのそれぞれが満たされる場合、１組の機能を実行するステップとを有し、
上記各属性フィルタは、購読者が、発行者から受信した興味があるイベントの組を記述していることを特徴するルーティング方法。
【請求項７】
上記１組の機能は、上記メッセージをルーティングすることを含むことを特徴する請求項６記載のルーティング方法。
【請求項８】
上記２つ以上の属性フィルタが満たされない場合、上記メッセージを削除するステップを更に有する請求項６記載のルーティング方法。
【請求項９】
上記検査ステップを、上記ネットワークコア内のルータにおいて実行するステップを更に有する請求項６記載のルーティング方法。
【請求項１０】
プロセッサ及びメモリを有し、ネットワークにおいて、サービス品質保証に基づいてパケットをルーティングするルーティング装置において、
ヘッダ部と、ペイロード部とを有するパケットを受信する受信手段と、
ネットワークコアにおいて、上記パケットのペイロード部を検査する検査手段と、
上記パケットの確保された帯域幅に関する上記サービス品質保証を判定する判定手段と、
上記検査手段及び判定手段による判定の結果得られた検査結果及び上記サービス品質保証に基づいて、上記パケットを選択的にルーティングするルーティング手段とを備え、
上記検査手段は、
上記ペイロード部からデータ属性を抽出し、
上記抽出したデータ属性を２つ以上の属性フィルタと比較し、
上記２つ以上の属性フィルタのそれぞれが満たされる場合、上記パケットをどのようにルーティングするかを決定し、
上記各属性フィルタは、購読者が、発行者から受信した興味があるイベントの組を記述していることを特徴すルーティング装置。
【請求項１１】
上記検査を、上記ネットワークコア内のルータで実行する手段を更に備える請求項１０記載のルーティング装置。
【請求項１２】
上記検査を実行するために、上記属性フィルタを、上記ネットワーク内のルータに伝搬する手段を更に備える請求項１０記載のルーティング装置。
【請求項１３】
上記受信、検査及びルーティングを実行するために、上記ネットワーク内のルータをプログラミングする手段を更に備える請求項１０記載のルーティング装置。
【請求項１４】
当該ルーティング装置は、ルータであることを特徴とする請求項１０記載のルーティング装置。
【請求項１５】
プロセッサ及びメモリを有し、ネットワークにおいて、メッセージをルーティングするルーティング装置において、
ヘッダ部と、少なくとも１つの主語と、複数のデータ属性とを有するメッセージを受信する受信手段と、
上記メッセージから、上記主語及び上記データ属性を読み出す主語／属性読出手段と、
上記主語に基づいて、購読予約を読み出す購読予約読出手段と、
上記メッセージを購読者装置にどのようにルーティングするかを決定するために、ネットワークコアにおいて、上記購読予約を複数のフィルタに照合する照合手段と、
上記パケットの確保された帯域幅に関するサービス品質保証を判定する判定手段とを備え、
上記主語／属性読出手段は、
上記購読予約に対応した複数のフィルタを読み出す手段を備え、
上記各フィルタは、購読者が、発行者から受信した興味があるイベントの組を記述していることを特徴するルーティング装置。
【請求項１６】
上記データ属性が上記複数のフィルタのそれぞれを満たす場合、上記サービス品質保証に基づいて、上記メッセージを選択的にルーティングする手段を更に備える請求項１５記載のルーティング装置。
【請求項１７】
上記データ属性が上記複数のフィルタの全てを満たさない場合、上記メッセージを削除する手段を更に備える請求項１５記載のルーティング装置。
【請求項１８】
上記フィルタリングを、上記ネットワークコア内のルータにおいて実行する手段を更に備える請求項１５記載のルーティング装置。
【請求項１９】
当該ルーティング装置は、ルータであることを特徴とする請求項１５記載のルーティング装置。
【請求項２０】
マルチキャストネットワークにおいて、データのパケットをルーティング及びキャッシングするルーティング／キャッシング方法において、
ヘッダ部と、ペイロード部とを有するパケットを受信する受信ステップと、
上記パケットを購読者装置にどのようにルーティングするかを決定するために、ネットワークコアにおいて、該パケットのペイロード部を検査する検査ステップと、
上記検査に基づいて、上記パケットを選択的にルーティングするルーティングステップと、
上記パケットに対応するチャンネルを判定するステップと、
上記チャンネルのチャンネル特性を読み出すステップと、
上記チャンネル特性から、上記チャンネルが持続的なチャンネルであるか否かを判定するステップと、
上記チャンネルが持続的なチャンネルである場合、上記パケットからデータを、上記ネットワークコアのコアルーティングノードで局所的にキャッシングするステップとを有し、
上記コアルーティングノードは、エッジルーティングノードの上流の購読者装置から離れる方向に位置することを特徴するルーティング／キャッシング方法。
【請求項２１】
上記検査ステップを、ルータで実行するステップを更に有する請求項２０記載のルーティング／キャッシング方法。
【請求項２２】
上記検査ステップは、上記ペイロード部内の情報にフィルタを適用するステップを含むことを特徴とする請求項２０記載のルーティング／キャッシング方法。
【請求項２３】
上記検査を実行するために、上記フィルタを、上記ネットワーク内のルータに伝搬するステップを更に有する請求項２２記載のルーティング／キャッシング方法。
【請求項２４】
上記受信ステップ、検査ステップ及びルーティングステップを実行するために、上記ネットワーク内のルータをプログラミングするステップを更に有する請求項２０記載のルーティング／キャッシング方法。
【請求項２５】
上記検査ステップは、上記パケットをどのようにルーティングするかを決定するために、上記属性を検査するステップを含むことを特徴とする請求項２０記載のルーティング／キャッシング方法。
【請求項２６】
上記キャッシングされたデータにタイムマークを付すステップを更に有する請求項２０記載のルーティング／キャッシング方法。
【請求項２７】
上記キャッシングされたデータにインデックスを付すステップを更に有する請求項２０記載のルーティング／キャッシング方法。
【請求項２８】
データ要求を受信するステップと、
上記キャッシングされたデータが上記データ要求を満たすか否かを判定するステップとを更に有する請求項２０記載のルーティング／キャッシング方法。
【請求項２９】
エッジルーティングノードにおいて、上記パケットからデータを局所的にキャッシングするステップを更に有し、
上記コアルーティングノードにキャッシングされたデータは、上記エッジルーティングノードにキャッシングされた全てのデータ及び他の位置にキャッシングされたデータを含むことを特徴する請求項２０記載のルーティング／キャッシング方法。
【請求項３０】
タイムフレームＴの経過後に、上記キャッシングされたデータを削除するステップを更に有する請求項２０記載のルーティング／キャッシング方法。
【請求項３１】
データのパケットをルーティング及びキャッシングするネットワークにおいて、
ヘッダ部と、ペイロード部とを有するパケットを受信して、ルーティングするエッジルーティングノードであって、該受信したパケットをルーティングするインテリジェントルータを含むエッジルーティングノードと、
ネットワークコア内に位置するコアルーティングノードと、
上記コアルーティングノード内に位置し、上記インテリジェントルータに動作可能に接続されたキャッシュマネージャとを備え、
上記インテリジェントルータは、
上記パケットを購読者装置にどのようにルーティングするかを決定するために、上記ネットワークコアにおいて、該パケットのペイロード部を検査する命令と、
上記検査に基づいて、上記パケットを選択的にルーティングする命令とを有し、
上記キャッシュマネージャは、
上記パケットのそれぞれに対応するチャンネルを判定する命令と、
上記チャンネルのチャンネル特性を読み出す命令と、
上記チャンネル特性から、上記各チャンネルが持続的なチャンネルであるか否かを判定する命令と、
上記チャンネルが持続的なチャンネルである場合、上記対応するパケットからデータを、上記コアルーティングノードのローカルキャッシュで局所的にキャッシングする命令とを有し
上記コアルーティングノードは、エッジルーティングノードの上流の購読者装置から離れる方向に位置することを特徴するネットワーク。
【請求項３２】
上記エッジルーティングノードに動作可能に接続されたエージェントを更に備え、
エージェントは、
上記キャッシングされたデータの位置を判定する命令と、
上記ローカルキャッシュから、上記キャッシングされたデータを読み出す命令と、
上記読み出したキャッシングされたデータを処理する命令とを有することを特徴する請求項３１記載のネットワーク。
【請求項３３】
上記チャンネルのチャンネル特性をそれぞれを提供する複数のチャンネルマネージャを更に備える請求項３１記載のネットワーク。
【請求項３４】
上記キャッシュマネージャは、
上記キャッシングされたデータにタイムマークを付す命令を更に有することを特徴とする請求項３１記載のネットワーク。
【請求項３５】
上記キャッシュマネージャは、
上記キャッシングされたデータにインデックスを付す命令を更に有することを特徴とする請求項３１記載のネットワーク。
【請求項３６】
上記キャッシュマネージャは、
データ要求を受信する命令と、
上記キャッシングされたデータが上記データ要求を満たすか否かを判定する命令とを更に有することを特徴とする請求項３１記載のネットワーク。
【請求項３７】
マルチキャストネットワークにおいて、データのパケットをルーティング及びキャッシングするルーティング／キャッシング装置において、
複数のプロセッサと、
上記複数のプロセッサによって実行される命令とを備え、
上記命令は、
ヘッダ部と、ペイロード部とを有するパケットを受信する命令と、
上記パケットを購読者装置にどのようにルーティングするかを決定するために、ネットワークコアにおいて、該パケットのペイロード部を検査する命令と、
上記検査に基づいて、上記パケットを選択的にルーティングする命令と、
上記パケットに対応するチャンネルを判定する命令と、
上記チャンネルのチャンネル特性を読み出す命令と、
上記チャンネル特性から、上記チャンネルが持続的なチャンネルであるか否かを判定する命令と、
上記チャンネルが持続的なチャンネルである場合、上記パケットからデータを、上記ネットワークコアのコアルーティングノードで局所的にキャッシングする命令とを有し、
上記コアルーティングノードは、エッジルーティングノードの上流の購読者装置から離れる方向に位置することを特徴するルーティング／キャッシング装置。
【請求項３８】
上記複数のプロセッサは、
上記検査する命令と、選択的にルーティングする命令とを実行する第１のプロセッサと、
上記局所的にキャッシングする命令を実行する第２のプロセッサとを含むことを特徴とする請求項３７記載のルーティング／キャッシング装置。

【図１】

【図２】

【図３】

【図４】

【図５】

【図６】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９】

【図２０】

【図２１】

【図２２】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７】

【図２８】

【図２９】

【図３０】

【図３１】

【図３２】

【図３３】

【図３４】

【図３５】

【図３６】

【公開番号】特開２０１０−１４８１１８（Ｐ２０１０−１４８１１８Ａ）
【公開日】平成２２年７月１日（２０１０．７．１）
【国際特許分類】
【出願番号】特願２００９−２９６２８８（Ｐ２００９−２９６２８８）
【出願日】平成２１年１２月２５日（２００９．１２．２５）
【分割の表示】特願２００４−５２００２１（Ｐ２００４−５２００２１）の分割
【原出願日】平成１５年７月８日（２００３．７．８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（５０４３６４１２７）プリキャッシュ　インコーポレイテッド (2)
【Ｆターム（参考）】