(57)【要約】分散型ネットワーク（１０）のコア内のルータ（１２）において、例えばビデオ、音楽、ソフトウェア等のデジタルコンテンツを配信し、及びサービス品質保証に基づいて、アラートサービスを提供するためのペイロード検査を用いたパケットのルーティングを提供する。パケットは、ルーティング情報に加えて、サブジェクトと属性を含んでいる。サブジェクトは、特定の種類のコンテンツに対する購読予約に対応し、属性は、データ又はコンテンツをカプセル化する。購読予約は、特定のサービス品質保証又はサービスのレベルに関連付けてもよい。ルータ（１２）は、コンテンツの購読予約に対応するフィルタを保存する。ルータ（１２）は、パケットを受け取ると、属性を含むパケットのペイロードセクションを検査し、カメラからのコンテンツの購読予約のためのフィルタをこれらの属性に適用する。属性がフィルタを満たす場合、パケットは、次のリンクにルーティングされる。属性がフィルタを満たさない場合、ルータは、パケットを削除する。これらの経路決定は、ネットワークコア（１０）において、ルータ（１２）間に配信される。ルータ（１２）は、データをネットワークコア（１２）においてローカルにキャッシングする。
2005532748.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークにおいて、アラートサービスを提供するために、パケットをルーティングするルーティング方法において、
ヘッダセクションと、特定のカメラからのビデオクリップに関連する情報を含むペイロードセクションとを有するパケットを受け取る受信ステップと、
ネットワークコアにおいて、上記特定のカメラからの情報を含むパケットを購読者にどのようにルーティングするかを決定するために上記パケットのペイロードセクションを検査する検査ステップと、
上記検査に基づいて、上記パケットを選択的にルーティングするルーティングステップとを有するルーティング方法。
【請求項２】
上記検査ステップは、コンテンツ述語情報を対応するネットワークの宛先に関連付ける構造において、上記ペイロードセクションの情報が該コンテンツ述語情報に一致するか否かを判定するステップを含むことを特徴とする請求項１記載のルーティング方法。
【請求項３】
上記ネットワークコア内のルータで上記検査を実行するステップを更に有する請求項１記載のルーティング方法。
【請求項４】
上記検査ステップは、上記ペイロードセクション内の情報にフィルタを適用するステップを含むことを特徴とする請求項１記載のルーティング方法。
【請求項５】
上記検査を実行するために用いられるフィルタを上記ネットワーク内のルータに伝播するステップを更に有する請求項４記載のルーティング方法。
【請求項６】
上記受信ステップ、検査ステップ及びルーティングステップを実行するために上記ネットワーク内のルータをプログラミングするステップを更に有する請求項１記載のルーティング方法。
【請求項７】
上記検査ステップは、上記パケットをどのようにルーティングするかを決定するために用いる属性を検査するステップを含むことを特徴とする請求項１記載のルーティング方法。
【請求項８】
上記ルーティングステップは、上記パケットをデジタルビデオ監視システムに選択的にルーティングするステップを含むことを特徴とする請求項１記載のルーティング方法。
【請求項９】
上記検査ステップをローカルエリアネットワークにおいて実行するステップを更に有する請求項１記載のルーティング方法。
【請求項１０】
上記検査ステップをインターネットサービスプロバイダ位置で実行するステップを更に有する請求項１記載のルーティング方法。
【請求項１１】
上記特定のカメラは、デジタルビデオレコーダ及び電荷結合素子を備えることを特徴とする請求項１記載のルーティング方法。
【請求項１２】
上記デジタルビデオレコーダは、上記ヘッダセクションと、上記特定のカメラからビデオクリップに関連する情報を含むペイロードセクションとを有する上記パケットを生成することを特徴とする請求項１１記載のルーティング方法。
【請求項１３】
ネットワークにおいて、アラートサービスを提供するために、パケットをルーティングするルーティング方法において、
ヘッダセクションと、少なくとも１つのサブジェクトと、特定のカメラからのビデオクリップに関連する少なくとも１つの属性とを含むメッセージを受け取る受信ステップと、
上記メッセージから上記サブジェクトと上記属性を読み出すサブジェクト／属性読出ステップと、
上記サブジェクトに基づいて購読予約を読み出す購読予約読出ステップと、
ネットワークコアにおいて、上記購読予約に上記属性を適用し、上記メッセージを購読者にどのようにルーティングするかを決定する適用ステップとを有するルーティング方法。
【請求項１４】
上記購読予約読出ステップは、上記購読予約に対応するフィルタを読み出すステップを含むことを特徴とする請求項１３記載のルーティング方法。
【請求項１５】
上記属性が上記購読予約を満たす場合、上記メッセージをルーティングするステップを更に有する請求項１３記載のルーティング方法。
【請求項１６】
上記属性が上記購読予約を満たさない場合、上記メッセージを削除するステップを更に有する請求項１３記載のルーティング方法。
【請求項１７】
複数の購読予約に対応する複数のフィルタを読み出すステップと、
上記メッセージから複数の属性を読み出すステップと、
上記各フィルタに上記各属性を適用し、対応する購読予約のいずれかが満たされているか否かを判定するステップと、
上記購読予約のいずれかが満たされているか否かに基づいて、上記メッセージを選択的にルーティングするステップとを有する請求項１３記載のルーティング方法。
【請求項１８】
ネットワークコア内のルータにおいて、上記適用ステップを実行するステップを更に有する請求項１３記載のルーティング方法。
【請求項１９】
上記特定のカメラは、デジタルビデオレコーダ及び電荷結合素子を備えることを特徴とする請求項１３記載のルーティング方法。
【請求項２０】
上記デジタルビデオレコーダは、上記ヘッダセクションと、上記特定のカメラからビデオクリップに関連する情報を含むペイロードセクションとを有する上記メッセージを生成することを特徴とする請求項１９記載のルーティング方法。
【請求項２１】
ネットワークにおいて、アラートサービスを提供するために、パケットをルーティングするルーティング方法において、
ヘッダセクションと、特定のアラートサービスのイベントに関する情報を含むペイロードセクションとを有するパケットを受け取る受信ステップと、
ネットワークコアにおいて、上記アラートサービスの情報を含むパケットを購読者にどのようにルーティングするかを決定するために上記パケットのペイロードセクションを検査する検査ステップと、
上記検査に基づいて、上記パケットを選択的にルーティングするルーティングステップとを有するルーティング方法。
【請求項２２】
ネットワークにおいて、アラートサービスを提供するために、パケットをルーティングするパケットルーティング装置において、
ヘッダセクションと、特定のカメラからのビデオクリップに関連する情報を含むペイロードセクションとを有するパケットを受け取る受信モジュールと、
ネットワークコアにおいて、上記特定のカメラからの情報を含むパケットを購読者にどのようにルーティングするかを決定するために上記パケットのペイロードセクションを検査する検査モジュールと、
上記検査に基づいて、上記パケットを選択的にルーティングするルーティングモジュールとを有するルーティング装置。
【請求項２３】
上記検査モジュールは、コンテンツ述語情報を対応するネットワークの宛先に関連付ける構造において、上記ペイロードセクションの情報が該コンテンツ述語情報に一致するか否かを判定するモジュールを備えることを特徴とする請求項２２記載のルーティング装置。
【請求項２４】
上記ネットワークコア内のルータで上記検査を実行するモジュールを更に有する請求項２２記載のルーティング装置。
【請求項２５】
上記検査モジュールは、上記ペイロードセクション内の情報にフィルタを適用するモジュールを含むことを特徴とする請求項２２記載のルーティング装置。
【請求項２６】
上記検査を実行するために用いられるフィルタを上記ネットワーク内のルータに伝播するモジュールを更に備える請求項２５記載のルーティング装置。
【請求項２７】
上記受信、検査及びルーティングを実行するために上記ネットワーク内のルータをプログラミングするモジュールを更に備える請求項２２記載のルーティング装置。
【請求項２８】
上記検査モジュールは、上記パケットをどのようにルーティングするかを決定するために用いる属性を検査するモジュールを含むことを特徴とする請求項２２記載のルーティング装置。
【請求項２９】
当該ルーティング装置は、デジタルビデオレコーダを備えるネットワーク内に配設されていることを特徴とする請求項２２記載のルーティング装置。
【請求項３０】
上記特定のカメラは、デジタルビデオレコーダ及び電荷結合素子を備えることを特徴とする請求項２２記載のルーティング装置。
【請求項３１】
ネットワークにおいて、アラートサービスを提供するために、パケットをルーティングするルーティング装置において、
ヘッダセクションと、少なくとも１つのサブジェクトと、特定のカメラからのビデオクリップに関連する少なくとも１つの属性とを含むメッセージを受け取る受信モジュールと、
上記メッセージから上記サブジェクトと上記属性を読み出すサブジェクト／属性読出モジュールと、
上記サブジェクトに基づいて購読予約を読み出す購読予約読出モジュールと、
ネットワークコアにおいて、上記購読予約に上記属性を適用し、上記メッセージを購読者にどのようにルーティングするかを決定する適用モジュールとを備えるルーティング装置。
【請求項３２】
上記購読予約読出モジュールは、上記購読予約に対応するフィルタを読み出すモジュールを備えることを特徴とする請求項３１記載のルーティング装置。
【請求項３３】
上記属性が上記購読予約を満たす場合、サービス品質保証に基づいて、上記メッセージを選択的にルーティングするモジュールを更に有する請求項３１記載のルーティング装置。
【請求項３４】
上記属性が全ての購読予約を満たさない場合、上記メッセージを削除するモジュールを更に有する請求項３１記載のルーティング装置。
【請求項３５】
複数の購読予約に対応する複数のフィルタを読み出すモジュールと、
上記メッセージから複数の属性を読み出すモジュールと、
上記各フィルタに上記各属性を適用し、対応する購読予約のいずれかが満たされているか否かを判定するモジュールと、
上記購読予約のいずれかが満たされているか否かに基づいて上記メッセージを選択的にルーティングするモジュールとを有する請求項３１記載のルーティング装置。
【請求項３６】
上記ネットワークコア内のルータにおいて、上記適用を実行するモジュールを有する請求項３１記載のルーティング装置。
【請求項３７】
当該ルーティング装置は、デジタルビデオレコーダを備えるネットワーク内に配設されていることを特徴とする請求項３１記載のルーティング装置。
【請求項３８】
上記特定のカメラは、デジタルビデオレコーダ及び電荷結合素子を備えることを特徴とする請求項３１記載のルーティング装置。
【請求項３９】
ネットワークにおいて、アラートサービスを提供するために、パケットをルーティングするルーティングシステムにおいて、
デジタルビデオ出力を生成する複数のデジタルビデオカメラと、
上記デジタルビデオカメラに接続されたローカルエリアネットワーク（ＬＡＮ）と、
上記ＬＡＮに接続され、上記デジタルビデオ出力を発行する発行者エージェントと、
上記発行者エージェントに接続された発行−購読ネットワークと、
上記発行−購読ネットワークを介して上記発行されたデジタルビデオ出力を受信するデジタルビデオ監視システム（ＤＶＳＳ）とを備えるルーティングシステム。
【請求項４０】
上記発行−購読ネットワークに接続され、上記デジタルビデオ出力を購読予約し、該購読されたデジタルビデオ出力を上記ＤＶＳＳにプッシュする購読者エージェントを更に備える請求項３９記載のルーティングシステム。
【請求項４１】
上記発行−購読ネットワークは、複数のインテリジェントルータを備えることを特徴とする請求項３９記載のルーティングシステム。
【請求項４２】
上記インテリジェントルータは、
ヘッダセクションと、複数のデジタルビデオカメラの１つからのデジタルビデオコンテンツに関連する情報を含むペイロードセクションとを有するパケットを受け取る受信モジュールと、
ネットワークコアにおいて、上記デジタルビデオカメラからの情報を含むパケットを購読者にどのようにルーティングするかを決定するために上記パケットのペイロードセクションを検査する検査モジュールと、
上記検査に基づいて、上記パケットを選択的にルーティングするルーティングモジュールとを備えることを特徴とする請求項４１記載のルーティングシステム。
【請求項４３】
購読者にデジタルコンテンツを配信するためのネットワークにおいて、
複数のユーザマシンと、
デジタルコンテンツを定期的に配信するセントラルディストリビュータと、
上記配信されたデジタルコンテンツを受け取って、キャッシングし、該キャッシングされたいずれかのデジタルコンテンツについて、上記ユーザマシンからユーザ要求を定期的に受信し、該要求されたデジタルコンテンツを該ユーザマシンに送信する複数のキャッシュサーバと、
上記配信されたデジタルコンテンツをセントラルディストリビュータからのファイルとして受信し、上記デジタルコンテンツファイルを発行とし、上記ユーザ要求を購読予約として、発行−購読コンテンツベースのルーティングを用いて上記デジタルコンテンツファイルを複数のキャッシュサーバに移すルーティングボックスとを備えるネットワーク。
【請求項４４】
上記ルーティングボックスは、第１のルーティングボックスであり、当該ネットワークは、上記複数のキャッシュサーバと同じ場所に配設された第２のルーティングボックスを備え、上記第１のルーティングボックスは、上記複数のキャッシュサーバの少なくとも１つと同じ場所に配設された該第２のルーティングボックスに上記デジタルコンテンツファイルをルーティングすることを特徴とする請求項４３記載のネットワーク。
【請求項４５】
上記複数のキャッシュサーバは、ネットワークサービスプロバイダに配設されていることを特徴とする請求項４３記載のネットワーク。
【請求項４６】
上記複数のキャッシュサーバは、上記セントラルディストリビュータによって配信された全てのデジタルコンテンツを保存する第１のレベルのキャッシュサーバであることを特徴とする請求項４３記載のネットワーク。
【請求項４７】
上記セントラルディストリビュータによって配信された上記デジタルコンテンツの一部を保存する第２のレベルのキャッシュサーバを更に備える請求項４６記載のネットワーク。
【請求項４８】
上記ルーティングボックスは、第１のルーティングボックスであり、当該ネットワークは、上記第２のレベルのキャッシュサーバと同じ場所に配設された第２のルーティングボックスを備え、上記第１のルーティングボックス及び上記第２のルーティングボックスは、発行−購読コンテンツベースのルーティングを用いて、上記第１のレベルのキャッシュサーバから第２のレベルのキャッシュサーバに上記デジタルコンテンツファイルを転送することを特徴とする請求項４７記載のネットワーク。
【請求項４９】
上記各ルーティングボックスは、
ヘッダセクションと、デジタルコンテンツファイルに関連する情報を含むペイロードセクションとを有するパケットを受け取る受信モジュールと、
上記パケットをどのようにルーティングするかを決定するために上記パケットのペイロードセクションを検査する検査モジュールと、
上記検査に基づいて、上記第１のレベルのキャッシュサーバから上記第２のレベルのキャッシュサーバに上記パケットを選択的にルーティングするルーティングモジュールとを有する請求項４８記載のネットワーク。
【請求項５０】
上記第２のレベルのキャッシュサーバによって保存される上記デジタルコンテンツの部分は、受信されたユーザ要求に関する履歴に基づいて決定されることを特徴とする請求項４７記載のネットワーク。
【請求項５１】
上記第２のレベルのキャッシュサーバは、上記ユーザ要求を直接受信し、該第２のレベルのキャッシュサーバに保存されていないデジタルコンテンツについて、該ユーザ要求を上記第１のレベルのキャッシュサーバに転送することを特徴とする請求項４７記載のネットワーク。
【請求項５２】
上記ルーティングボックスは、
ヘッダセクションと、デジタルコンテンツファイルに関連する情報を含むペイロードセクションとを有するパケットを受け取る受信モジュールと、
上記パケットをどのようにルーティングするかを決定するために上記パケットのペイロードセクションを検査する検査モジュールと、
上記検査に基づいて、上記セントラルディストリビュータからから上記複数のキャッシュサーバに上記パケットを選択的にルーティングするルーティングモジュールとを有する請求項４３記載のネットワーク。
【請求項５３】
上記セントラルディストリビュータは、１つ以上のサーバを備えることを特徴とする請求項４３記載のネットワーク。
【請求項５４】
上記デジタルコンテンツは、ビデオ、音楽及びソフトウェアを含むことを特徴とする請求項４３記載のネットワーク。
【請求項５５】
ネットワークの購読者にデジタルコンテンツを配信する配信方法において、
上記デジタルコンテンツをセントラルディストリビュータから配信する配信ステップと、
上記配信されたデジタルコンテンツを複数のキャッシュサーバにコンテンツベースでルーティングするコンテンツルーティングステップと、
上記コンテンツベースでルーティングされたデジタルコンテンツを上記複数のキャッシュサーバにキャッシングするキャッシングステップと、
要求されたキャッシングされたデジタルコンテンツに対するユーザ購読予約を受け取る受信ステップと、
上記受信されたユーザ購読予約に基づいて、上記複数のキャッシュサーバからユーザに上記要求されたデジタルコンテンツを転送する転送ステップとを有する配信方法。
【請求項５６】
上記コンテンツルーティングステップは、
ヘッダセクションと、デジタルコンテンツファイルに関連する情報を含むペイロードセクションとを有するパケットを受け取るステップと、
上記パケットをどのようにルーティングするかを決定するために上記パケットのペイロードセクションを検査するステップと、
上記検査に基づいて、上記パケットを選択的にルーティングするルーティングステップとを有することを特徴とする請求項５５記載の配信方法。
【請求項５７】
上記検査ステップは、コンテンツ述語情報を対応するネットワークの宛先に関連付ける構造において、上記ペイロードセクションの情報が該コンテンツ述語情報に一致するか否かを判定するステップを含むことを特徴とする請求項５６記載の配信方法。
【請求項５８】
上記検査ステップは、上記ペイロードセクション内の情報にフィルタを適用するステップを含むことを特徴とする請求項５６記載の配信方法。
【請求項５９】
上記検査を実行するために用いられる上記フィルタを上記ネットワーク内のルーティングボックスに伝播するステップを更に有する請求項５８記載の配信方法。
【請求項６０】
上記受信ステップ、検査ステップ及びルーティングステップを実行するために上記ネットワーク内のルーティングボックスをプログラミングするステップを更に有する請求項５６記載の配信方法。
【請求項６１】
上記検査ステップは、上記パケットをどのようにルーティングするかを決定するために用いる属性を検査するステップを含むことを特徴とする請求項５６記載の配信方法。
【請求項６２】
上記検査ステップをルーティングボックスにおいて実行するステップを更に有する請求項５６記載の配信方法。
【請求項６３】
上記複数のキャッシュサーバは、第１のレベルのキャッシュサーバであり、当該配信方法は、コンテンツベースのルーティングを用いて、キャッシングされたデジタルコンテンツを第２のレベルのキャッシュサーバに転送するステップを更に有することを特徴とする請求項５５記載の配信方法。
【請求項６４】
上記要求されたデジタルコンテンツが上記第２のレベルのキャッシュサーバに格納されているか否かを判定するステップを更に有する請求項６３記載の配信方法。
【請求項６５】
上記判定に基づいて、上記受信されたユーザ購読予約を上記第１のレベルのキャッシュサーバに転送するステップを更に有する請求項６４記載の配信方法。
【請求項６６】
上記転送するステップは、受信されたユーザ購読予約に関する履歴に基づいて、コンテンツベースのルーティングを用いて、上記キャッシングされたデジタルコンテンツを上記第２のレベルのキャッシュサーバに転送することを特徴とする請求項６３記載の配信方法。
【請求項６７】
ネットワークにおいて、サービス品質保証に基づいてパケットをルーティングするルーティング方法において、
ヘッダセクションと、ペイロードセクションとを有するパケットを受け取る受信ステップと、
ネットワークコアにおいて、上記パケットをどのようにルーティングするかを決定するために上記パケットのペイロードセクションを検査する検査ステップと、
上記パケットのためのサービス品質保証を判定する判定ステップと、
上記検査及び上記サービス品質保証に基づいて、上記パケットを選択的にルーティングするルーティングステップとを有するルーティング方法。
【請求項６８】
上記検査ステップは、コンテンツ述語情報を対応するネットワークの宛先に関連付ける構造において、上記ペイロードセクションの情報が該コンテンツ述語情報に一致するか否かを判定するステップを含むことを特徴とする請求項６７記載のルーティング方法。
【請求項６９】
上記ネットワークコア内のルータで上記検査を実行するステップを更に有する請求項６７記載のルーティング方法。
【請求項７０】
上記検査ステップは、上記ペイロードセクション内の情報にフィルタをかけるステップを含むことを特徴とする請求項６７記載のルーティング方法。
【請求項７１】
上記検査を実行するために用いられるフィルタを上記ネットワーク内のルータに伝播するステップを更に有する請求項７０記載のルーティング方法。
【請求項７２】
上記受信ステップ、検査ステップ及びルーティングステップを実行するために上記ネットワーク内のルータをプログラミングするステップを更に有する請求項６７記載のルーティング方法。
【請求項７３】
上記検査ステップは、上記パケットをどのようにルーティングするか又は上記パケットを削除するか否かを決定するために用いる属性を検査するステップを含むことを特徴とする請求項６７記載のルーティング方法。
【請求項７４】
ネットワークにおいて、メッセージをルーティングするルーティング方法において、
ヘッダセクションと、少なくとも１つのサブジェクトと、少なくとも１つの属性とを含むメッセージを受け取る受信ステップと、
上記メッセージから上記サブジェクトと上記属性を読み出すサブジェクト／属性読出ステップと、
上記サブジェクトに基づいて購読予約を読み出す購読予約読出ステップと、
上記メッセージのサービス品質保証を判定するステップと、
ネットワークコアにおいて、上記購読予約に上記属性を適用し、上記メッセージをどのようにルーティングするかを決定する適用ステップと、
上記適用と上記サービス品質保証とに基づいて、上記メッセージを選択的にルーティングするステップとを有するルーティング方法。
【請求項７５】
上記購読予約読出ステップは、上記購読予約に対応するフィルタを読み出すステップを含むことを特徴とする請求項７４記載のルーティング方法。
【請求項７６】
上記属性が上記購読予約を満たす場合、上記メッセージをルーティングするステップを更に有する請求項７４記載のルーティング方法。
【請求項７７】
上記属性が上記購読予約を満たさない場合、上記メッセージを削除するステップを更に有する請求項７４記載のルーティング方法。
【請求項７８】
複数の購読予約に対応する複数のフィルタを読み出すステップと、
上記メッセージから複数の属性を読み出すステップと、
上記各フィルタに上記各属性を適用し、対応する購読予約のいずれかが満たされているか否かを判定するステップと、
上記購読予約のいずれかが満たされているか否かに基づいて、上記メッセージを選択的にルーティングするステップとを有する請求項７４記載のルーティング方法。
【請求項７９】
ネットワークコア内のルータにおいて、上記検査ステップを実行するステップを有する請求項７４記載のルーティング方法。
【請求項８０】
ネットワークにおいて、サービス品質保証に基づいてパケットをルーティングするルーティング装置において、
ヘッダセクションと、ペイロードセクションとを有するパケットを受け取る受信モジュールと、
ネットワークコアにおいて、上記パケットをどのようにルーティングするかを決定するために上記パケットのペイロードセクションを検査する少なくとも１つの検査モジュールと、
上記パケットのためのサービス品質保証を判定する判定モジュールと、
上記検査モジュール及び判定モジュールによる判定の結果得られた検査結果及びサービス品質保証に基づいて、上記パケットを選択的にルーティングするルーティングモジュールとを備えるルーティング装置。
【請求項８１】
上記検査モジュールは、コンテンツ述語情報を対応するネットワークの宛先又は対応するルータ内処理を支配する規則に関連付ける構造において、上記ペイロードセクションの情報が該コンテンツ述語情報に一致するか否かを判定するモジュールを備えることを特徴とする請求項８０記載のルーティング装置。
【請求項８２】
上記ネットワークコア内のルータで上記検査を実行するモジュールを更に備える請求項８０記載のルーティング装置。
【請求項８３】
上記検査モジュールは、上記ペイロードセクションの情報をフィルタにかけるモジュールを更に備えることを特徴とする請求項８０記載のルーティング装置。
【請求項８４】
上記検査を実行するために用いられる上記フィルタを上記ネットワーク内のルータに伝播するモジュールを更に備える請求項８３記載のルーティング装置。
【請求項８５】
上記受信、検査及びルーティングを実行するために上記ネットワーク内のルータをプログラミングするモジュールを更に備える請求項８０記載のルーティング装置。
【請求項８６】
当該ルーティング装置は、ルータであることを特徴とする請求項８０記載のルーティング装置。
【請求項８７】
ネットワークにおいて、メッセージをルーティングするルーティング装置において、
ヘッダセクションと、少なくとも１つのサブジェクトと、少なくとも１つの属性とを有するメッセージを受け取るための受信モジュールと、
上記メッセージから上記サブジェクトと上記属性を読み出すサブジェクト／属性読出モジュールと、
上記サブジェクトに基づいて購読予約を読み出す購読予約読出モジュールと、
ネットワークコアにおいて、上記購読予約に上記属性を適用し、上記メッセージを購読者にどのようにルーティングするかを決定する適用モジュールと、
上記パケットのためのサービス品質保証を判定する判定モジュールとを備えるルーティング装置。
【請求項８８】
上記購読予約読出モジュールは、上記購読予約に対応するフィルタを読み出すモジュールを備えることを特徴とする請求項８７記載のルーティング装置。
【請求項８９】
上記属性が上記購読予約を満たす場合、上記サービス品質保証に基づいて、上記メッセージを選択的にルーティングするモジュールを更に有する請求項８７記載のルーティング装置。
【請求項９０】
上記属性が全ての購読予約を満たさない場合、上記メッセージを削除するモジュールを更に有する請求項８７記載のルーティング装置。
【請求項９１】
複数の購読予約に対応する複数のフィルタを読み出すモジュールと、
上記メッセージから複数の属性を読み出すモジュールと、
上記各フィルタに上記各属性を適用し、対応する購読予約のいずれかが満たされているか否かを判定するモジュールと、
上記購読予約のいずれかが満たされているか否かに基づいて上記メッセージを選択的にルーティングするモジュールとを有する請求項８７記載のルーティング装置。
【請求項９２】
上記ネットワークコア内のルータにおいて、上記フィルタリングを実行するための１つ以上のモジュールを更に備える請求項８７記載のルーティング装置。
【請求項９３】
当該装置は、ルータであることを特徴とする請求項８７記載のルーティング装置。
【請求項９４】
マルチキャストネットワークにおいて、データのパケットをルーティング及びキャッシングするルーティング／キャッシング方法において、
ヘッダセクションと、ペイロードセクションとを有するパケットを受け取る受信ステップと、
ネットワークコアにおいて、上記パケットを購読者にどのようにルーティングするかを決定するために上記パケットのペイロードセクションを検査する検査ステップと、
上記検査に基づいて、上記パケットを選択的にルーティングするルーティングステップと、
上記ネットワークコアにおいて、上記パケットからのデータをローカルにキャッシングするステップとを有するルーティング／キャッシング方法。
【請求項９５】
上記検査をルータで実行するステップを更に有する請求項９４記載のルーティング／キャッシング方法。
【請求項９６】
上記検査ステップは、上記ペイロードセクション内の情報にフィルタを適用するステップを含むことを特徴とする請求項９４記載のルーティング／キャッシング方法。
【請求項９７】
上記検査を実行するために用いられるフィルタを上記ネットワーク内のルータに伝播するステップを更に有する請求項９６記載のルーティング／キャッシング方法。
【請求項９８】
上記受信ステップ、検査ステップ及びルーティングステップを実行するために上記ネットワーク内のルータをプログラミングするステップを更に有する請求項９４記載のルーティング／キャッシング方法。
【請求項９９】
上記検査ステップは、上記パケットをどのようにルーティングするかを決定するために用いる属性を検査するステップを含むことを特徴とする請求項９４記載のルーティング／キャッシング方法。
【請求項１００】
上記キャッシングされたデータに時間的なマークを付すステップを更に有する請求項９４記載のルーティング／キャッシング方法。
【請求項１０１】
上記キャッシングされたデータにインデクスを付すステップを更に有する請求項９４記載のルーティング／キャッシング方法。
【請求項１０２】
データ要求を受信するステップと、
上記キャッシングされたデータが上記データ要求を満たすか否かを判定するステップとを更に有する請求項９４記載のルーティング／キャッシング方法。
【請求項１０３】
エッジルーティングノードにおいて、上記パケットからのデータをローカルにキャッシングするステップを更に有する請求項９４記載のルーティング／キャッシング方法。
【請求項１０４】
タイムフレームＴの経過後に、上記キャッシングされたデータを削除するステップを更に有する請求項９４記載のルーティング／キャッシング方法。
【請求項１０５】
データのパケットをルーティング及びキャッシングするネットワークにおいて、
ヘッダセクションと、ペイロードセクションとを有するパケットを受け取るエッジルーティングノードを備え、該エッジルーティングノードは、
ネットワークコアにおいて、上記パケットを購読者にどのようにルーティングするかを決定するために上記パケットのペイロードセクションを検査するための命令と、上記検査に基づいて、上記パケットを選択的にルーティングするための命令とを有し、上記受け取ったパケットをルーティングするインテリジェントルータと、
上記インテリジェントルータに動作可能に接続され、上記パケットからデータをローカルキャッシュにローカルにキャッシングするための命令を有するキャッシュマネージャと、
上記パケットを受け取り、ルーティングする１つ以上のコアルーティングノードとを備えるネットワーク。
【請求項１０６】
上記エッジルーティングノードに動作可能に接続され、上記キャッシングされたデータの位置を判定する命令と、上記ローカルキャッシュから上記キャッシングされたデータを読み出す命令と、上記読み出したキャッシングされたデータを処理するための命令とを有するエージェントを更に備える請求項１０５記載のネットワーク。
【請求項１０７】
上記１つ以上のコアルーティングノードの１つは、上記エッジルーティングノードからアップストリームにあり、
上記アップストリームのコアルーティングノードは、
ネットワークコアにおいて、上記パケットを購読者にどのようにルーティングするかを決定するために上記パケットのペイロードセクションを検査する命令と、上記検査に基づいて、上記パケットを選択的にルーティングするための命令とを有し、上記受け取ったパケットをルーティングするインテリジェントルータと、
上記インテリジェントルータに動作可能に接続され、上記パケットからデータをローカルキャッシュにローカルにキャッシングするための命令を有するキャッシュマネージャとを備えることを特徴とする請求項１０５記載のネットワーク。
【請求項１０８】
複数のチャンネルのプロパティを提供する複数のチャンネルマネージャを更に備える請求項１０５記載のネットワーク。
【請求項１０９】
上記キャッシュマネージャは、
上記キャッシングされたデータに時間的なマークを付すための命令を更に有することを特徴とする請求項１０５記載のネットワーク。
【請求項１１０】
上記キャッシュマネージャは、上記キャッシングされたデータにインデクスを付すための命令を更に有することを特徴とする請求項１０５記載のネットワーク。
【請求項１１１】
上記キャッシュマネージャは、
データ要求を受信するための命令と、
上記キャッシングされたデータが上記データ要求を満たすか否かを判定するための命令とを更に有することを特徴とする請求項１０５記載のネットワーク。
【請求項１１２】
マルチキャストネットワークにおいて、データのパケットをルーティング及びキャッシングするルーティング／キャッシング装置において、当該ルーティング／キャッシング装置は、
プロセッサと、
ヘッダセクションと、ペイロードセクションとを有するパケットを受け取るための命令と、
ネットワークコアにおいて、上記パケットを購読者にどのようにルーティングするかを決定するために上記パケットのペイロードセクションを検査するための命令と、
上記検査に基づいて、上記パケットを選択的にルーティングするための命令と、
上記ネットワークコアにおいて、上記パケットからのデータをローカルにキャッシングするための命令とを有するルーティング／キャッシング装置。
【請求項１１３】
上記プロセッサは、
上記検査するための命令と、選択的にルーティングするための命令とを実行する第１のプロセッサと、
上記ローカルにキャッシングするための命令を実行する第２のプロセッサとを含むことを特徴とする請求項１１２記載のルーティング／キャッシング装置。
【発明の詳細な説明】
【関連出願】
【０００１】
本発明は、引用により本願に援用される、２００２年７月８日に出願された、米国仮出願番号６０／３９４，６３１号、発明の名称「サービス品質管理のためのペイロード検査を介したパケットルーティング（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）」も引用により本願に援用されるものとする。
【技術分野】
【０００３】
本発明は、ネットワークコアにおいて、アラートサービスを提供するためのパケット内のペイロードの検査（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 service）が実現すれば、インターネットアプリケーション並びに他のアプリケーション及びインプリメンテーションに大きな付加価値が与えられる。
【発明の開示】
【課題を解決するための手段】
【０００９】
本発明は、上述した従来の技術の欠点を克服し、ネットワークにおいて、アラートサービスを提供するために、パケットをルーティングする方法及び装置を提供する。本発明に基づく方法及び装置により、例えば、ビデオクリップの処理及びルーティングのためのネットワークの負担を大幅に低減できる。更に、本発明により、ビデオクリップをルーティングするための帯域幅要件を削減することができる。また、本発明により、デジタルビデオレコーダのローカルエリアネットワークに関して、ローカルトラヒックを低減させることができる。
【００１０】
これらの利点を実現するために、本発明の一実施例では、ヘッダセクションと、特定のカメラからのビデオクリップに関連する情報を含むペイロードセクションとを有するパケットを受け取る。ネットワークコアにおいて、特定のカメラからの情報を含むパケットを購読者にどのようにルーティングするかを決定するためにパケットのペイロードセクションを検査し、検査に基づいて、パケットを選択的にルーティングする。また、これらのステップを実行するためのモジュールを備える装置によっても、上述の及びこの他の利点を実現できる。
【００１１】
また、これらの及びこの他の利点を実現するために、本発明は、ネットワークにおいて、アラートサービスを提供するために、パケットをルーティングするルーティング方法を提供する。このルーティング方法は、ヘッダセクションと、少なくとも１つのサブジェクトと、特定のカメラからのビデオクリップに関連する少なくとも１つの属性とを含むメッセージを受け取る受信ステップと、メッセージからサブジェクトと属性を読み出すサブジェクト／属性読出ステップと、サブジェクトに基づいて購読予約を読み出す購読予約読出ステップと、ネットワークコアにおいて、購読予約に属性を適用し、メッセージを購読者にどのようにルーティングするかを決定する適用ステップとを有する。また、これらのステップを実行するためのモジュールを備える装置によっても、上述の及びこの他の利点を実現できる。
【００１２】
また、これらの及びこの他の利点を実現するために、本発明は、ネットワークにおいて、アラートサービスを提供するために、パケットをルーティングするルーティング方法を提供する。このルーティング方法は、ヘッダセクションと、特定のアラートサービスのイベントに関する情報を含むペイロードセクションとを有するパケットを受け取る受信ステップと、ネットワークコアにおいて、アラートサービスの情報を含むパケットを購読者にどのようにルーティングするかを決定するためにパケットのペイロードセクションを検査する検査ステップと、検査に基づいて、パケットを選択的にルーティングするルーティングステップとを有する。また、これらのステップを実行するためのモジュールを備える装置によっても、上述の及びこの他の利点を実現できる。
【発明を実施するための最良の形態】
【００１３】
概観
インターネット規模又は他の分散型ネットワーク規模のイベント通知システムにより、アプリケーションにおいて、強力で柔軟な発行−購読ネットワーキング（publish-subscribe networking）が実現される。このシステムでは、アプリケーションプログラムは、イベント通知アプリケーションプログラムインタフェース（application program interface：以下、ＡＰＩという。）を用いて、ネットワーク内部で発生するイベントに関する通知を発行し及び／又は通知を購読又は受信する。
【００１４】
このシステムにおける通知には、サブジェクトが与えられ、サブジェクトは、通知がカプセル化している情報の種類を分類するための文字列又はこの他のデータ構造として示される。また、通知は、その通知に特有の情報を含む属性の組によって完結されている。例えば、アプリケーションは、サブジェクトクォート．ｎｙｓｅ（subject quotes.nyse）と、属性シンボル及び価格とを用いて、ニューヨーク証券取引所における取引に関する通知を発行してもよい。例えば、アプリケーションは、ＳＮＥ（ソニー株式会社の相場受信機のシンボル）及び８５．２５ドルの株価を含む特定の属性値を有する個々の通知を発行する。全てではなくとも、殆どの通知の属性は、同じサブジェクトのファミリーに関する全ての通知において見出されるという意味で、予め定められている。なお、発行者は、イベント固有の情報を追加するために、通知毎に又は他の単位で、通知に任意の属性を加えることができる。したがって、一部又は全ての属性は、予め定義されたものではなくてもよい。
【００１５】
このシステムでは、購読者は、サブジェクト又はチャンネル全体の購読のみに制限されるわけではない。チャンネルついては、後に説明し、定義する。チャンネルは、例えばサブジェクトフィールド及び関連するサブフィールド（サブサブジェクト）の１つ以上のレベルを指定する階層構造を含むことができる。したがって、購読者は、通知の属性に対して、コンテンツ毎のフィルタを指定することによって、興味に応じてより精密に調整された表現を特定することができる。例えば、購読者は、ＳＮＥのシンボルを有し、価格が９０．００ドル以上であるサブジェクトクォート．ｎｙｓｅ（例えば、購読者が所有している株の売りの好機を示している）について、全ての通知を購読予約してもよい。購読予約に一致する全ての通知は、コールバック又は購読者が購読予約を登録したとき、又は他の時点で特定した他の種類の機能を介して、購読者に配信される。１つの購読予約は、複数のフィルタに分割することもできる。
【００１６】
コールバックは、多くの処理を実行することができ、これらには、例えば、端末機器にメッセージを送信し又は電子メールを送信する等の単純な処理から、株の一部を売却する等のより複雑な処理や、新たな発行−購読アクティビティを開始する（例えば、既存の購読予約を７５．００ドルの株価を買いの好機とする新たな購読予約に置き換え、又は購読者のポートフォリオが修正された新たな通知を発行する等）等の更に複雑な処理が含まれる。
【００１７】
アプリケーションにおける発行及び購読アクティビティは、例えば、エージェントによって支援してもよい。エージェントは、プロキシを利用してもよく又はプロキシとして実現してもよい。エージェントは、送信される通知及び購読予約、及び購読者に受信される照合通知の配信のための接続を提供する。通知がネットワークに出されると、このシステムのルータのネットワークは、その通知に購読予約が一致する全ての購読者に通知を伝播（propagate）する。この処理を実現する一手法は、ネットワーク内の全ての点の通知を同報通信し、アプリケーションエージェントにより、対応する購読者にその通知が関連するか否かを判断させる手法がある。しかしながら、これは必ずしもスケーラブルな手法であるというわけではない。通常、ネットワークは、特に膨大な数のアクティブな購読者がいる場合、メッセージトラヒックの負荷によって正常に機能できなくなる。更に、帯域幅が十分に確保された場合でも、購読者は、膨大な量の通知を処理しきれなくなると考えられる。
【００１８】
本発明に基づくシステムの一例として示すネットワークは、非常に効率的に通知をルーティングする。まず、このネットワークは、マルチキャストルーティングを用いて、例えば、ネットワーク内の全てのリンクにおいて最大で１回、通知を伝播させることができる。次に、このネットワークは、フィルタに対する多数の高度な最適化処理を採用でき、これにより、通知の伝播の回数を可能な限り削減することができる。
【００１９】
図１は、ネットワークコアにおけるこのインテリジェントルーティングを概念的に示す図である。発行者１４は、エッジルータ１６を介して、発行−購読ネットワークにおいて用いられているネットワークコア１０にメッセージのコンテンツを送信する。発行−購読ネットワークは、発行者から購読者にデータ又はコンテンツをルーティングするための如何なる種類のネットワークであってもよい。コンテンツは、ルータ間又は他の機器間の論理的接続を表す１個以上のチャンネル１８を介して伝送される。ネットワークコア１０におけるインテリジェントルータ１２は、メッセージをルーティング又は転送するか否かを決定する。具体的には、インテリジェントルータ１２は、メッセージが購読者２４によって購読予約されているコンテンツを含んでいるか否かを判定することができる。
【００２０】
各購読予約は、サブジェクトフィルタと属性フィルタとをカプセル化している。ルータは、サブジェクトフィルタを一致するサブジェクトの組に拡張し、又はサブジェクト毎に属性フィルタを併合することができる。インテリジェントルータは、通知のサブジェクトに対してサブジェクトフィルタを評価し、及び通知における属性値に対して属性フィルタを評価する。サブジェクトフィルタのための構文では、ワイルドカードを用いることができ、属性フィルタのための構文では、論理式（Boolean expression）を用いることができ、これらについては、後に更に詳細に説明する。「フィルタ」という用語は、購読者が発行者から受信を望んでいる１組のイベントを意味する。ルーティング規則は、フィルタから生成され、インテリジェントルータは、この規則を用いて経路決定を行う。
【００２１】
したがって、メッセージ２６が全体のフィルタセットを充足していない場合、例えばインテリジェントルータ１２は、メッセージ２６を除外（削除）し、これは、メッセージが転送されないことを意味する。サブジェクトと属性フィルタの評価に基づき、メッセージ２０がフィルタの組の一部又は全体を充足していると判定された場合、例えばインテリジェントルータ１２は、エッジルータ２２及び可能であれば他の機器を介して、購読者にメッセージ２０をルーティング（転送）し、又は、一致したフィルタについて規定されている全てのルーティング及び／又は動作規則に基づいて、インテリジェントルータ１２内部でメッセージ２０に対する他の機能を実行する。検索は、フィルタの組全体に対する処理が完了するまで、又は全ての規則に関する判定が得られるまで続けられ、この２つの条件のいずれかが満たされると終了する。
【００２２】
ネットワークコアにおける、このようなインテリジェントなコンテンツベースのルーティングは、例えば、警告及び更新のための実時間データ配信を実現する。警告のための実時間データ配信の具体例としては、以下に限定されるものではないが、例えば、株価、交通情報、ニュース、旅行、天気、不正検出、セキュリティ、テレマティックス、ファクトリオートメーション、サプライチェーン管理及びネットワークマネージメント等がある。更新のための実時間データ配信の具体例としては、以下に限定されるものではないが、例えば、ソフトウェア更新、アンチウィルス更新、映画及び音楽配信、ワークフロー、ストレージ管理及びキャッシュ一貫性（cache consistency）等がある。購読予約された情報を配信するシステムは、他の様々な分野に応用することができる。
【００２３】
表１は、フィルタリングのために保存される購読予約をサブジェクト及び述語（predicate）とともに示している。これらは、希望されれば、又は必要に応じて、ネットワークの如何なる部分に、如何なる種類のデータ構造を用いて保存してもよい。後述するように、述語は、購読予約の要素である。購読予約は、如何なる形式で表現してもよく、その具体例を以下に示す。
【００２４】
【表１】
2005532748.tif 000003
【００２５】
表２は、クォートサーバ（quote server）のための発行及び購読予約の具体例を示している。これらは、説明を目的とする例示的な具体例に過ぎず、購読予約は、如何なる種類のデータ又はコンテンツについて、如何なる数及び種類のパラメータも含んでいてもよい。
【００２６】
【表２】
2005532748.tif 000004
【００２７】
述語は、購読予約のための論理式を提供し、サブジェクトは、購読予約に関するチャンネルを示す。購読予約は、この他の様々な手法で表現することができる。論理式は、このような手法の一例であり、これを用いることにより、コンテンツベースのルーティングのために、購読予約をサブジェクトフィルタと属性フィルタに変換するための機能を容易に実現することができる。これに代えて、サブジェクトを参照することなく購読予約を表現することもできるが、サブジェクト又はチャンネル（後に詳細に説明する。）を用いることにより、属性を解釈し、フィルタを属性に適用するためのコンテキストが実現される。
【００２８】
ネットワークコアにおいて、経路決定を実行し、これをネットワークを介して配信することができ、これにより、発行者と購読者の装置における処理負担を軽減し、ネットワーク効率を著しく高めることができる。図１では、説明を目的として、単一の発行者、単一の購読者及び単一のインテリジェントルータのみを示しているが、実際には、発行者、購読者及びインテリジェントルータをそれぞれ複数設けてもよい。インテリジェントルータという用語は、ネットワークコア又はこの他の位置において、パケット又はメッセージのペイロードを検査することによって経路を決定する能力を有するルータ又は他のエンティティを意味する。
【００２９】
ネットワークインフラストラクチャ
図２は、発行者及び購読者のためのインテリジェントルータを示すネットワーク図である。例えば、サービスをチャンネルに供給するルーティングエンティティ３０は、後述するように、インテリジェントルータ間でメッセージをルーティングするために、ネットワークインフラストラクチャ内に効果的に階層化される。例えば、発行者３２は、概念的に、発行されたコンテンツの指示情報、例えばコンテンツを検索するためのポインタを受け取るためのアプリケーション３４と、チャンネルサービス３０を介したネットワーク伝送のためにコンテンツを符号化するためのエージェント３６とを含む。論理的に相互接続された一群のインテリジェントルータ３８、４０、４２、４４、４６、４８は、購読予約のためのサブジェクトフィルタ及び属性フィルタから生成されたルーティング規則を用いて、発行者からのコンテンツをルーティングする。複数のリンク３９、４１、４３、４５は、インテリジェントルータ３８、４０、４２、４４、４６、４８間を論理的に接続する。他のリンク３７、４７は、それぞれ、発行者３２とインテリジェントルータ３８の間及び購読者５４とインテリジェントルータ４６の間を論理的に接続する。購読者５４は、購読されたコンテンツを検出し、受け取るためのエージェント５０と、コンテンツを表現するためのアプリケーション５２とを備えている。
【００３０】
チャンネルは、例えば、分散型方式によって実現された論理的なマルチキャスト接続の関連する組を含むことができる。この例示的な実施例におけるチャンネルとは、コンテンツを交換するために発行者と購読者に共用される論理的に関連するネットワーク資源の集合である。コンテンツは、チャンネルサブジェクトネームスペースに従って分類され、リソースは、チャンネルマネージャが提供するチャンネルサービスを介して管理され、制御され、供給される。複数のチャンネルが同じリソースを共有してもよい。チャンネルは、スケーラビリティが高いディレクトリサービスを提供でき、このサービスは、以下に限定されるものではないが、発行者及び購読者情報、認証及び認可情報メッセージの種類、管理情報、課金処理と支払い情報等が含まれる。また、例えば、チャンネルは、提供できる持続的なスルーキャッシング（persistence through caching）、高速データ配信メカニズム、セキュリティ、ユーザ及びネットワーク管理等を提供できる。また、チャンネルは、他の如何なる目的にも利用できる。
【００３１】
インテリジェントルータによるフィルタリングをネットワークコアで行い、経路決定をネットワーク内に配信してもよい。更に、インテリジェントルータは、発行者又は購読者等のユーザ機器をネットワークコアに接続するエッジルータとして機能できる。また、ネットワークに接続された同じ機器が、ネットワークにおける経路決定に基づいて購読者にコンテンツをプッシュする発行者及びプッシュされたコンテンツを受信する購読者の両方として機能することができる。インテリジェントルータ及びチャンネルは、特定の実施例における必要又は要望に応じて、如何なる構成で接続してもよく、図２の構成は例示的に示しているに過ぎない。
【００３２】
図３は、インテリジェントルータと従来のバックボーンルータのための例示的なネットワークインフラストラクチャの構成を示しており、この図面は、チャンネルの論理的接続も示している。この実施例におけるインテリジェントルータは、インターネットや他の分散型ネットワーク等のネットワークにおいて、既存のバックボーンルータを用いており、インテリジェントルータは、これにより、バックボーンルータ上に効果的に階層化されている。この実施例では、インターネットサービスプロバイダ（Internet Service Provider：以下、ＩＳＰという。）ネットワーク５８、５９、６０は、メッセージ又はパケットの従来型のルーティングを行うために、それぞれ幾つかのバックボーンルータを備えている。ＩＳＰネットワーク５８、５９、６０においては、複数のインテリジェントルータ６１〜７０が１つ以上のバックボーンルータに接続されている。また、インテリジェントルータ６１−７０は、実際のリンクを例示的に示す複数のリンク７３〜８５によって相互接続され、またこれらのリンクを介して、エンドユーザ機器にも接続することができる。インテリジェントルータ６１〜７０は、例えばエンティティ７１等の１つ以上の管理者装置（administrator machines）及び例えばエンティティ７２等の１つ以上の仮想プライベートネットワーク（virtual private network：以下、ＶＰＮという。）コントローラによって制御される。ＩＳＰネットワーク５８、５９、６０は、発行者装置及び購読者装置（図３には示していない。）に接続してもよい。ＩＳＰ５８、５９、６０内及びこれらの間のバックボーンルータは、既存のネットワークインフラストラクチャにおいて、従来の如何なる手法で相互接続してもよい。
【００３３】
図３に示すように、既存のネットワークインフラストラクチャを用いて、インテリジェントルータ６１〜７０とリンク７３〜８５を実現することができ、これらは、ネットワークコアにおけるコンテンツベースのルーティングを提供する。リンク７３〜８５は、インテリジェントルータ６１〜７０の間の論理的接続を表し、例えば、既存のネットワークインフラストラクチャ又は他の機器を用いて実現することができる。リンクは、例えば、トンネル（tunnel）と呼ばれる論理的接続を用いて実現してもよい。トンネルは、ハードウェアと、可能であればソフトウェアと、リンクを実現するためのネットワークインフラストラクチャとを含み、トンネルは、複数のチャンネルの一要素であってもよい。チャンネルは、特定の種類のコンテンツのための論理的な構成を提供することによって、インテリジェントルータにおけるコンテンツベースのルーティングを容易にし、これにより、チャンネルを介して送信される属性のためのコンテキストを提供する。インテリジェントルータは、チャンネルを用いることなく経路決定を行うこともできるが、チャンネルは、ネットワークコアにおけるインテリジェントルータによるコンテンツベースのルーティングの効率を向上させる。
【００３４】
この例示的な実施例は、チャンネルとリンクの使用を含んでいる。リンクは、例えばインテリジェントルータである２つのルータ間の接続を表す。チャンネルは、相互接続リンクによって静的又は動的に構成され、１対多又は多対多の論理的接続を実現する一群の（通常多数の）ルータを含むネットワークエンティティである。特に、チャンネルは、チャンネルの本質的な特徴を記述する最上位レベルの論理的エンティティである。１個のチャンネルには、多くのサブジェクトが存在していてもよい。各サブジェクトは、相互接続された一群のルータを含む（マルチキャストツリー等の）サブネットワークを形成する。これらのサブジェクトベースのサブネットワークは、様々な手法で、割当、適応化、構成を行うことができる。全てのサブネットワークの集合体であり、その下にサブジェクトを形成するチャンネルは、例えば、網状組織（mesh of networks）に例えばることもできる。
【００３５】
図４は、インテリジェントルータ９２の具体的な構成例を示しており、インテリジェントルータ９２は、符号が付された他の如何なるインテリジェントルータに対応していてもよい。ネットワークノード９０は、従来のバックボーンルータ９５に接続されたインテリジェントルータ９２を備えている。インテリジェントルータ９２は、メモリ９４と補助記憶装置９７（例えば、独立した装置として実現してもよい。）とに接続されたプロセッサ９３を備え、メモリ９４及び補助記憶装置９７は、いずれも、キャッシュデータを含むデータを保存し、及びプロセッサ９３によって実行されるアプリケーションプログラムを保存する。補助記憶装置９７は、不揮発性のデータ記憶装置である。後述するように、プロセッサ９３は、ソフトウェアに制御されて、バックボーンルータ９５に対して命令を発し、この命令に応じて、バックボーンルータ９５は、購読予約に対するサブジェクトフィルタ及び属性フィルタから生成されたルーティング規則に基づいて、メッセージ又はパケットをルーティング（転送）し又はルーティングしない（削除する）。ここでは、インテリジェントルータ９２をプロセッサに制御される独立した装置として示しているが、インテリジェントルータ９２は、バックボーンルータ９５内の特定用途向け集積回路（application specific integrated circuit：ＡＳＩＣ）として実現し、ハードウェアにおいて、インテリジェントルーティング機能を提供してもよく、また、このハードウェアにソフトウェアを組み込んでもよい。また、これに代えて、インテリジェントルーティング機能は、１つ又は複数のルーティング装置において、ソフトウェアとハードウェアの組合せとして実現してもよい。
【００３６】
図５は、発行者装置及び購読者装置の具体的構成例を示している。発行者装置１００又は１１８は、例えば、１つ以上の発行者アプリケーション１０４とエージェントアプリケーション１０５を保存するメモリ１０２と、不揮発性記憶装置である補助記憶装置機器１１２と、情報又はコマンドを入力するためのための入力装置１０８と、メモリ１０２に保存されている又は他のストレージ装置から受け取ったアプリケーションを実行するためのプロセッサ１１４と、情報を出力するための出力装置１１０と、情報を視覚的に表示する表示装置１１６とを備えている。
【００３７】
購読者装置１２２又は購読者装置１４０は、例えば、１つ以上のアプリケーション１２６とエージェントアプリケーション１２８を保存するメモリ１２４と、不揮発性記憶装置である補助記憶装置機器１３０と、情報又はコマンドを入力するための入力装置１３２と、メモリ１２４に保存されている又は他のストレージ装置から受け取ったアプリケーションを実行するためのプロセッサ１３４と、情報を出力するための出力装置１３６と、情報を視覚的に表示するための表示装置１３８とを備えている。発行者装置及び購読者装置は、如何なる構成であってもよく、上述したものとは異なる構成要素を備えていてもよく、構成要素は、上述したものより多くても少なくてもよい。
【００３８】
発行者装置１００、１１８は、上述したネットワーク１２０等のネットワークを介して購読者装置１２２、１４０に接続されるネットワーク１２０は、ネットワークコアにおいて、パケット又はメッセージを介して、データ又はコンテンツの分配型ルーティングを実現するためのインテリジェントルータを含んでいる。ここでは、それぞれ２つの発行者装置及び購読者装置のみを示しているが、より多くの発行者装置及び購読者装置を含むようにネットワーク１２０をスケーリングできる。発行者装置及び購読者装置は、プロセッサにより制御される如何なる装置として実現してもよく、これらの装置としては、以下に限定されるものではないが、例えば、サーバ、パーソナルコンピュータ、ノートブックコンピュータ、携帯情報端末、電話、携帯電話、ページャ、又はこの他の機器が含まれる。インテリジェントルータを含むネットワーク１２０は、有線機器、無線機器又はその両方を接続する如何なる有線又は無線の分散型ネットワークであってもよい。また、ネットワーク１２０としては、潜在的に既存の又は従来のネットワークインフラストラクチャを用いることができる。
【００３９】
図６は、インテリジェントルータのためのチャンネルマネージャ１５０の構成を示している。この実施例では、チャンネルマネージャ１５０は、複数のサーバ１５２、１５４、１５６によって実現されている。各サーバは、それぞれローカルのストレジ装置１５８、１６０、１６２を備えている。インテリジェントルータ１６４、１６６、１６８は、チャンネルマネージャから特定のチャンネルに関する情報を得る。また、チャンネルマネージャは、データ持続（data persistence）、障害迂回機能（fail over functions）及び他の機能を提供することができる。これにより、チャンネル管理プログラムは、ネットワークの任意の場所において、例えばチャンネル関連情報、データ持続のためのプロパティ、発行者及び購読者のためのユーザ情報、インフラストラクチャ情報等を特定するデータベース又はデータベースの組を含むチャンネルサービスを提供するインフラストラクチャ情報は、例えばインテリジェントルータ及びこれらを接続するトンネルの識別情報、チャンネルのサブジェクト、チャンネルの属性（各属性の名称と種類）等を含むことができる。また、パケット又はメッセージは、固定的な属性及び可変の属性の識別情報を含むチャンネル関連情報を伝送することができる。
【００４０】
ユーザは、オンライン状態で、チャンネル情報をダウンロードすることができる。例えば、ユーザは、ユーザ名とパスワードを用いて、自らを登録することができる。ユーザのログオンが認証されると、ユーザは、チャンネルを開き（呼び出し）、チャンネルマネージャからチャンネルに関する情報を検索できる。発行者は、コンテンツを発行する際にこの情報を用いることができ、購読者は、購読予約を入力及び登録する際にこの情報を用いることができる。
【００４１】
チャンネルマネージャ１５２、１５４、１５６は、好ましくは、持続的で、信頼性が高いチャンネルディレクトリサービスを実行するためのグループを構成する。チャンネルマネージャの１つはプライマリマネージャであり、他のチャンネルマネージャは、バックアップ用チャンネルマネージャである。プライマリチャンネルマネージャに障害が発生すると、このプライマリチャンネルマネージャに隣接するチャンネルマネージャが新たなプライマリチャンネルマネージャとしての機能を引き受け、これにより、サービスの信頼度が維持される。各インテリジェントルータは、これらのチャンネルマネージャのアドレスを維持する。インテリジェントルータがアクセスできないチャンネルマネージャがある場合、インテリジェントルータは、情報を得るために他のチャンネルマネージャを検索する。ネットワーク機器は、例えば、表３に示すような、チャンネル情報を得るためのコマンドを用いることができる。これに代えて、インテリジェントルータは、プライマリチャンネルマネージャのみを有していてもよく、又は２以上のチャンネルマネージャを有していてもよい。
【００４２】
図７は、インテリジェントルータを有するネットワークに接続するためのユーザ装置又は機器におけるソフトウェアコンポーネントのスタック１８０の具体例を示している。ユーザ装置は、発行者、購読者又はこれらの両方として用いることができ、ユーザ装置は、具体例として先に例示した様々な機器を含むことができる。スタック１８０は、１つ以上のユーザアプリケーション１８２を含むことができ、ユーザアプリケーション１８２は、ユーザからの購読予約の受信、発行者からのチャンネル情報の受信又は発行すべきコンテンツ又はデータの受信に用いることができる。また、ユーザアプリケーション１８２は、ユーザ装置又は機器によって実行される他の如何なる種類のアプリケーションを含んでいてもよい。
【００４３】
またスタック１８０は、エージェント１８４、イベントライブラリ１８６、キャッシュライブラリ１８８、チャンネルライブラリ１９０、メッセージングライブラリ１９２、ディスパッチャライブラリ１９４を含んでいてもよい。エージェント１８４は、ネットワーク接続の確立又はこの他の機能を提供し、表３は、エージェント１８４によって実現されるコマンドの具体例を示しており、これらは、プロキシコマンド又は他の種類のコマンドとして用いることができる。イベントライブラリ１８６は、ユーザ装置に関するイベント又はこの他のイベント又は情報のログを記録する。キャッシュライブラリ１８８は、データのローカルなキャッシング機能を提供する。チャンネルライブラリ１９０は、チャンネルの識別情報と、そのチャンネルに関する情報とを保存する。ディスパッチャライブラリ１９４は、制御パス１９６、チャンネルマネージャ１９８、１つ以上のインテリジェントルータ２００への接続を提供し、及び表４に例示的に示す機能を含むことができる。メッセージングライブラリ１９２は、データパス２０４への接続を提供する。
【００４４】
Ｃプログラミング言語で書かれたメッセージングＡＰＩの具体例を表５〜表９に示す。表５及び表６は、メッセージの送信及び検索のためのＡＰＩの具体例を示している。表７及び表８は、通知の送信及び検索のためのＡＰＩの具体例を示している。表９は、制御メッセージの送信及び検索のためのＡＰＩの具体例を示している。ここに示す特定の機能又は特徴を実現するＡＰＩ及び他のＡＰＩ、プログラム及びデータ構造は、例示的に示しているに過ぎず、これらの機能は、如何なるプログラミング言語で書かれた如何なる種類のＡＰＩ又はこの他のソフトウェアエンティティとして実現してもよい。
【００４５】
【表３】
2005532748.tif 000005
【００４６】
【表４】
2005532748.tif 000006
【００４７】
【表５】
2005532748.tif 000007
【００４８】
【表６】
2005532748.tif 000008
【００４９】
【表７】
2005532748.tif 000009
【００５０】
【表８】
2005532748.tif 000010
【００５１】
【表９】
2005532748.tif 000011
【００５２】
図８は、上述したようなインテリジェントルータ及び図４に示すインテリジェントルータ９２等のインテリジェントルータのための例示的なソフトウェアコンポーネント２１０を示している。ソフトウェアコンポーネント２１０は、例えば、メモリ９４に格納され、インテリジェントルータ９２のプロセッサ９３によって実行することができる。コンポーネント２１０は、例えばフィルタリングデーモン２１２、ディスパッチャ２１４、ルーティングデーモン２１６、キャッシュマネージャ２１８を備える。フィルタリングデーモン２１２は、後述するように、購読予約のためのコンテンツを処理するための、コンテンツベースのルーティングにおけるルーティング規則に基づくフィルタリング機能を提供する。ディスパッチャ２１４は、パス２２０を介してフィルタを伝播するために必要である制御メッセージの通信を担い、また、ディスパッチャ２１４は、ユーザのためのエントリの単一のポイント及びチャンネルマネージャを有する１個の安全なソケットを提供し、ネットワークのセキュリティを向上させる。換言すればこの具体例では、ユーザは、チャンネルマネージャと直接通信を行うことがない。但し、変形例として、ユーザは、チャンネルマネージャと直接通信を行ってもよい。ディスパッチャ２１４は、制御メッセージを用いて、チャンネルマネージャから属性（名称−値の組）を得る。
【００５３】
ルーティングデーモン２１６は、図４に示すような従来のバックボーンルータ又は他のルーティング機器を介して行われるデータパス２２２を経由する通信機能を提供する。キャッシュマネージャ２１８は、対応するインテリジェントルータを含むネットワークノードにおけるデータのローカルなキャッシング機能を提供する。キャッシュマネージャ２１８の動作は、後に詳細に説明するが、キャッシュマネージャ２１８は、ネットワークコアを介したデータの分散型キャッシング機能を提供する。
【００５４】
コンテンツベースのルーティングは、アプリケーションレベルではなく、カーネルレベルで実現してもよい。カーネルによってアクセス可能なメモリは、アプリケーション層におけるメモリから独立している。アプリケーションにおいて、コンテンツベースのルーティングを実行するためには、例えば、メッセージデータをカーネル記憶領域からアプリケーション領域にコピーし、アプリケーションのコンテキストをカーネルのコンテキストから、ルーティングアプリケーションのコンテキストに切り換える必要がある。これらの処理は、いずれもかなりのオーバーヘッドを引き起こす。ここで、コンテンツベースのルーティングをサポートするようにカーネルを変更すれば、上述したオーバヘッドが取り除かれ、ルーティングをより高速に行うことができるようになる。
【００５５】
このようなカーネルにおけるコンテンツベースのルーティング機能により、ルーティングデーモン２１６は、具体例に応じて、データパス２２２を介してデータを直接又は間接的に送信又は受信することができる。デーモンは、アプリケーション層において実行され、カーネルに挿入すべきコンテンツベースのルーティングテーブルを予め算出する処理である。但し、カーネルは、ルーティングテーブルが挿入された後は、ルーティングテーブルを用いて経路決定を行うことができる。同様に、フィルタリングデーモンは、フィルタリングテーブルを予め算出し、算出したフィルタリングテーブルをカーネルに挿入する。この具体例におけるカーネルでは、ルーティングデーモンもフィルタリングデーモンもデータパスとは直接インタラクトしない。
【００５６】
図９は、購読予約のコンテンツを含むことができるメッセージのためのパケット構造２３０の具体例を示している。コンテンツベースのルーティングに用いられるパケット又はメッセージは、例えば、ヘッダセクションとペイロードセクションを含んでいる。ヘッダセクションは、ルーティング又は他の情報を特定する。ペイロードセクションは、データ又はコンテンツを特定し、又は、データ又はコンテンツを指示する。パケット構造２３０は、ＩＰヘッダ２３２、ユーザデータグラムプロトコル（User Datagram Protocol：以下、ＵＤＰという。）伝送制御プロトコル（Transmission Control Protocol：以下、ＴＣＰという。）ヘッダ２３４、レングス値２３８、１つ以上のサブジェクトフィールド２４０及び１つ以上の属性２４２を含んでいる。パケット構造２３０は、レングス値、サブジェクト及び属性のための基本構造を示している。また、コンテンツベースのルーティングで用いられるパケットは、例えば、後述する図１８の実施例に示すように、他の又は異なる要素を含むことができ、コンテンツベースのルーティングのためのパケットは、如何なる手法で構成してもよい。また、属性は、例えば、メッセージの最後に追加される任意の属性を含むことができる。これらの任意の属性は、例えば発行者（又はルータ）によって追加される臨時の情報であり、必ずしもチャンネルについて定められているメッセージフォーマットを用いて伝送する必要はない情報である。
【００５７】
発行者と購読者における処理（Publisher and Subscriber Methodologies ）
図１０は、発行者によって、チャンネルをセットアップし、コンテンツを発行するための例示的な発行処理２５０のフローチャートである。処理２５０は、例えば、発行者装置１００におけるプロセッサ１１４によって実行されるエージェント１０６を含むソフトウェアモジュールによって実現することができる。処理２５０において、発行者装置のエージェント１０６は、発行者が作成したチャンネルのプロキシを受け取る（ステップ２５２）。プロキシは、ネットワークとの通信に用いられる。エージェント１０６は、インタフェースを介してチャンネルにおいて用いるメッセージフォーマットを判定する（ステップ２５３）。フォーマット情報は、例えば、チャンネルマネージャ又はネットワークにおける他のエンティティから得ることができる。エージェント１０６は、受け取ったチャンネル情報を用いてチャンネルのプロキシをセットアップし（ステップ２５４）、この処理は、チャンネルの属性を受け取るステップ（ステップ２５６）と、チャンネルへの通知を作成するステップ（ステップ２５８）とを含む。この通知は、チャンネル上でコンテンツを「待機（listening）」している機器にコンテンツを提供する。属性は、通知のパラメータ及び特性を定義する。
【００５８】
１０６エージェントは、ネットワークコアにおいて又は他の場所において、購読予約を処理するためにチャンネル及びコンテンツ情報の識別子（ＩＤ）をインテリジェントルータに送信する（ステップ２６０）。発行者は、通知属性に適切な値を設定し（ステップ２６１）、これにより、発行者は、チャンネル属性に基づいて、通知に関するコンテンツを発行できる（ステップ２６２）。この実施例におけるステップ２６０〜２６２により、通知の発行が完了する。この処理は、実際の個々の実施例に応じて、この他の又は更なるステップを含んでいてもよい。ここで、この実施例における通知に関連する情報は、所定の順序に基づく一連の属性に区切られ、各属性は、名称と、通知内の位置（１から始まる）と、種類と、値とを有する。これに代えて、属性は、個々の実施例に応じて、異なる特徴を有していてもよい。例えば、属性は、予め定められた属性、任意の属性又はこれらの両方を含むことができる。
【００５９】
インテリジェントルータは、パケット内のチャンネルＩＤに基づいて、対応するチャンネルの属性を知ることができ、この属性により、チャンネルを介して送信されるパケットの構造又はフォーマットが決定されている。具体的には、各パケットは、例えば、チャンネルＩＤ及び発行者ＩＤやサブジェクト等の他のヘッダ情報に関連するタグを含むことができる。このタグは、例えば図１８に具体例を示すように、サブジェクトをメッセージフォーマットの番号にマッピングするために用いることができる。この番号には、小さい整数値、例えば、１６ビット値を用いることができる。これに代えて、他の如何なる種類の番号又は情報を用いてサブジェクトをマッピングしてもよい。サブジェクトを番号にマッピングすることにより、例えば次のような利点が得られる。すなわち、これにより、メッセージフォーマットにおける空間を節約でき、メッセージにおいてサブジェクトを指定するための均一又は標準化された手法を提供でき、これにより、サブジェクトを速やかに特定し、識別できるようになる。インテリジェントルータは、マッピングをローカルに保存してもよく、これに代えて、番号を用いて、コマンドにより、リモートから対応するサブジェクトを入手してもよい。
【００６０】
表１０は、サブジェクトを番号にマッピングするための構造を示しており、この具体例では、番号に整数値を用いている。表１０におけるサブジェクトツリーパラメータは、サブジェクトが階層関係内に１つ以上のサブジェクトフィールドを含むことができることを示しており、例えばサブジェクトツリーは、特定のシンボルによって仕切られる一連のサブジェクトフィールドを含むことができる。サブジェクトツリーの具体例は、表２に示されている。例えば、サブジェクトツリーｑｕｏｔｅｓ．ｎｙｓｅは、サブジェクト「ｑｕｏｔｅ」とサブフィールド「ｎｙｓｅ」を含んでおり、これらの２つの項は、ＵＲＬ又は他のネットワークアドレスと同様に、「．」（ピリオド）によって区切られている。ピリオド及びＵＲＬ型の文字列を用いる代わりに、如何なる文字及び区切りのためのシンボルを用いて、如何なる手法でサブジェクトツリーを特定してもよい。
【００６１】
【表１０】
2005532748.tif 000012
【００６２】
特定のチャンネルのパケットフォーマット又は構造を知ることにより、インテリジェントルータは、パケット内におけるサブジェクトと属性又はコンテンツベースのルーティングのための他の情報の位置を速やかに特定することができる。例えば、チャンネルは、パケット内のバイトを数えることによって、チャンネルを介して伝送されたサブジェクト及び属性のバイト位置を容易に特定できる。これに代えて、インテリジェントルータは、パケットを解析してサブジェクト及び属性又は他の情報の位置を検出することもできる。
【００６３】
表１１は、Ｃ＋＋プログラミング言語で書かれた発行者プログラムの具体例を示している。表１２は、チャンネルを作成するためのＡＰＩの具体例を示している。表１３は、チャンネルマネージャによって維持されるチャンネル設定ファイルの具体例と（図６参照）、チャンネル関連情報を示している。これに代えて、システムは、処理負荷を分散させるために、ローカルチャンネルマネージャとして機能する地理的に分散しているサーバのＩＰアドレスを提供する包括的チャンネルマネージャを備えていてもよい。
【００６４】
【表１１】
2005532748.tif 000013
【００６５】
【表１２】
2005532748.tif 000014
【００６６】
【表１３】
2005532748.tif 000015
【００６７】
図１１は、購読予約の受信及び処理のための購読処理２６４のフローチャートである。処理２６４は、例えば、購読者装置１２２におけるプロセッサ１３４によって実行されるエージェント１２８を含むソフトウェアモジュールによって実現することができる。処理２６４において、例えば、グラフィカルユーザインタフェース（graphical user interface；以下、ＧＵＩという。）は、利用可能なチャンネルを示す情報をユーザに表示する（ステップ２６６）。この処理は、アプリケーション１２６によって実現される。チャンネルを特定する情報は、例えば、チャンネル関連の情報を提供するチャンネルマネージャから受け取ることができる。如何なる種類のアプリケーション１２６を用いて、如何なる特定の手法又はフォーマットに基づいて、チャンネルを示す情報を表示してもよい。アプリケーションは、ユーザが選択したチャンネルを受信し（ステップ２６８）、選択されたチャンネルのためのＡＰＩ又は他のプログラムを呼び出す（ステップ２７０）。ＡＰＩは、選択されたオプションに対するチャンネルの購読予約オプションをユーザに表示する（ステップ２７２）。ＡＰＩは、購読予約に関する値をユーザから値を受け取り（ステップ２７４）、後述する処理のために、エージェント１２８に購読予約を供給する（ステップ２７６）。
【００６８】
購読予約のためのパラメータは、例えば表１に示すような述語を含むことができる。各チャンネルは、例えば、対応するチャンネルに関する特定の要求又はパラメータに従って購読予約を処理するために自らのＡＰＩを用いることができる。これらのＡＰＩは、例えば、購読予約を受け取るためのウェブベースの又はＪａｖａベースのＡＰＩを含んでいてもよく、如何なる種類のユーザインタフェース及び処理を用いて購読予約に関する情報を受け取り、この情報をエージェントアプリケーションに転送してもよい。
【００６９】
図１２は、チャンネル及び購読者画面又はＧＵＩ２７８、２８４を概念的に示す図であり、これらは、購読予約を受け取るための処理２６４に関連して用いられる。画面２７８は、ユーザによって選択される利用可能なチャンネルを示す複数のセクション２８２を含んでいる。特定のチャンネルが選択されると、画面２８４に示すように、購読予約のためのユーザの値を受け取るためのセクション２８６が表示される。ユーザがセクション２８８を選択すると、購読予約が確定し、又は、ユーザがセクション２９０を選択すると、購読予約が中止される。例えば、画面２７８、２８４は、ハイパーテキストマークアップランゲージ（HyperText Markup Language：以下、ＨＴＭＬという。）ウェブページとしてフォーマットしてもよく、又は他の如何なる他のフォーマットを用いてもよい。また、画面は、セクションとコンテンツの如何なる構成を含んでいてもよく、可能であれば、必要に応じて、例えばテキスト、図形、ピクチャ、様々な色又はマルチメディア情報を含み、購読者のために、ユーザフレンドリで視覚的に魅力的なインタフェースを提供する。また、画面は、例えば、従来と同様のブラウザ機能を提供するツールバー２８０を含んでいてもよい。
【００７０】
表１４は、Ｃ＋＋プログラミング言語で書かれた購読者プログラムの具体例を示している。
【００７１】
【表１４Ａ】
2005532748.tif 000016
【００７２】
【表１４Ｂ】
2005532748.tif 000017
【００７３】
ペイロード検査及びチャンネルを介したコンテンツベースのルーティング
図１３は、コンテンツベースのルーティングのためのペイロード検査処理３００のフローチャートである。処理３００は、例えば、フィルタリングデーモン２１２として表される、インテリジェントルータ９２におけるプロセッサ９３によって実行されるソフトウェアモジュールにおいて実現される。これに代えて、この処理をＡＳＩＣで実現してもよく、或いはハードウェアとソフトウェアの組合せによって実現してもよい。処理３００として示すコンテンツベースのルーティングは、例えば、ネットワークコアやエッジルータ等ネットワーク内の任意の部分におけるインテリジェントルータにおいて実行できる。
【００７４】
包括的に言えば、コンテンツベースのルーティングは、パケットをどのように処理するかを決定するためにパケットのペイロードセクションを検査する処理を含む。このコンテンツベースのルーティング処理は、例えば、購読予約のリストを任意の順序で（例えば、フィルタを用いて）処理し、ルーティング規則に基づいて、メッセージをサブジェクト毎及び属性毎に比較し、メッセージのルーティングを決定し、ネットワークコアにおける処理を実行するステップを有する。この規則は、ルータにおける処理を支配する規則又はフィルタに関連する如何なる規則を含んでいてもよい。これにより、ネットワークコア内にこれらの経路決定を伝えることができる。サブジェクトをチャンネルとして表すことにより、メッセージフォーマットが決定され、これにより、インテリジェントルータは、例えば、特定のチャンネルのメッセージ又はパケットにおいて、属性のバイト位置を知ることによって、メッセージにおける属性の位置を速やかに検出できるようになる。
【００７５】
処理３００において、インテリジェントルータ９２は、メッセージに関するパケットを受け取る（ステップ３０２）。インテリジェントルータ９２は、パケットから、対応するメッセージのチャンネルＩＤを判定し（ステップ３０４）、チャンネルＩＤを用いて、チャンネルの属性を読み出す（ステップ３０６）。この実施例では、チャンネル（チャンネルＩＤから判定される。）の種類は、パケットにおける属性の位置とデータタイプを決定する。チャンネルの属性は、ローカルに保存してもよく、例えばチャンネルマネージャを介してリモートから読み出してもよい。インテリジェントルータ９２は、購読予約に対応するフィルタを検索する（ステップ３０８）。フィルタは、１つ以上の属性検査、多くの場合、購読予約のための属性検査のグループを含んでいる。インテリジェントルータ９２は、フィルタ記述内の対応する属性検査をパケット内の属性に適用する（ステップ３１０）。
【００７６】
フィルタ記述における全ての属性検査の結果が肯定的である場合（ステップ３１２）、すなわち、属性が全ての属性検査の条件を満たしていれば、インテリジェントルータ９２は、フィルタに関連する規則によって予め定められている一組の処理を実行する（ステップ３１４）。これらの処理としては、例えば、次のリンクにパケットをルーティングする処理及び／又は規則に基づき、ローカルルータにおいて、パケットのコンテンツに対して何らかの操作又は演算を実行する処理等が含まれる。この操作又は次のリンクは、例えば、対応する購読予約を指定するデータ構造において特定される。規則がリンクである場合、規則は、通常、パケットを受け取るための次のネットワークノードを指定し、このネットワークノードとしては、インテリジェントルータ、バックボーンルータ、ネットワークに接続された機器又は他のエンティティが含まれる。これに代えて、この他の手法で、次のリンクを特定し又は購読予約に関連付けてもよい。
【００７７】
フィルタ記述における全ての属性検査の結果が肯定的ではなかった場合（ステップ３１２）、すなわち、属性が全ての属性検査の条件を満たしていなければ、フィルタの不一致が宣言される（ステップ３１５）。インテリジェントルータは、フィルタ記述における全ての属性検査が完了するまで又は、最初の否定的結果が得られるまで上述した処理を繰り返し、この２つの条件のいずれかが満たされると処理を終了する。
【００７８】
インテリジェントルータは、このフィルタについて、全ての属性検査を行った後、更なるフィルタが存在するか否かを判定し（ステップ３１６）、更なるフィルタが存在する場合、処理は、ステップ３０８に戻り、次のフィルタに関する属性検査が読み出され、そのフィルタに関する検査を実行する。照合処理（ステップ３０８、３１０、３１２、３１４、３１５、３１６）は、フィルタの組全体に対する処理が完了するまで、又は全ての規則に関する判定が得られるまで続けられ、この２つの条件のいずれかが満たされると終了する。パケットがフィルタの条件を満たさない場合、そのフィルタは除外（削除）され、転送されない。
【００７９】
インテリジェントルータ９２は、如何なる特定の順序でフィルタを用いた一連の処理を行ってもよい。例えば表１５に示すように、インテリジェントルータ９２は、ファイル又はルーティングテーブル内に購読予約のためのフィルタを保存でき、これらを順次読み出して、属性にフィルタを適用する（属性検査を行う）ことができる。これに代えて、ルーティングテーブルは、フィルタへのリンク又はポインタを含んでいてもよい。
【００８０】
コンテンツベースのルーティングでは、アプリケーション及び例えばトラヒック条件に基づくアルゴリズムの切換等性能向上ヒューリスティックスに基づいて、任意に２つ以上の手法を同時に用いてもよい。コンテンツベースのルーティングに関するペイロードセクションの検査において用いるために、処理に用いるフィルタは、ネットワーク内のルータにおいて任意に暗号化し、復号し、変形し、併合してもよい。例えば、アプリケーションにおける発行情報が小数点以下２桁より小さい通貨情報を含まない場合、＞３．５４１２２ドルの購読情報の端数を丸めて＞３．５４ドルにしてもよい。また、海外からの発行情報が米国内に存在する最初のルータに到達した時点で、外国通貨を米国の通貨に換算してもよい。
【００８１】
インテリジェントルータ９２は、線形的な手法に代えて、処理の速度と効率を向上させることができる他の順序で又は様々なアルゴリズムに基づいて、処理に用いるフィルタを選択してもよい。表１６は、購読予約と対応するリンクの具体例を示す。これらの具体例において、サブジェクトは、特定のチャンネルに関連し、サブジェクトに関する購読予約は、フィルタに関するルーティング規則によって表すことができる。サブジェクトは、例えば、ユニフォームリソースロケータ（Uniform Resource Locator：ＵＲＬ）等、コンテンツのソースを特定するためのネットワークアドレスを含むことができる。
【００８２】
【表１５】
2005532748.tif 000018
【００８３】
【表１６】
2005532748.tif 000019
【００８４】
図１４は、キャッシング処理３２０のフローチャートである。処理３２０は、例えば、キャッシュマネージャ２１８として表される、インテリジェントルータ９２におけるプロセッサ９３によって実行されるソフトウェアモジュールにおいて実現される。これに代えて、この処理をＡＳＩＣで実現してもよく、或いはハードウェアとソフトウェアの組合せによって実現してもよい。これらは、対応するインテリジェントルータと同じ物理機器であっても異なる物理機器であってもよい。処理３２０において、インテリジェントルータ９２は、データ又はコンテンツと、チャンネルＩＤと、サブジェクトとを含むメッセージを受け取る（ステップ３２２）。インテリジェントルータ９２は、データに時刻を表すマークを付し（ステップ３２４）、メモリ９４や補助記憶装置９７等のローカルメモリにキャッシングする（ステップ３２６）。インテリジェントルータ９２は、キャッシングされたデータにチャンネルＩＤ、サブジェクト及びタイムスタンプによりインデクスを付す（ステップ３２８）。
【００８５】
インテリジェントルータ９２がデータの要求を受け取った場合、（ステップ３３０）インテリジェントルータ９２は、その要求に基づき、インデクスを用いて、キャッシングされたデータを検索する（ステップ３３２）。インテリジェントルータ９２は、バックボーンルータ９５又は他のルーティングエンティティにキャッシングされたデータを転送し、このデータは最終的に要求者又は他のエンティティに送信される。処理３２０は、継続的にデータをキャッシングし、キャッシングされたデータを要求に応じて検索できるように、繰り返し実行してもよい。
【００８６】
図１５は、処理３２０に用いられるキャッシュインデクス（３３６）の具体例を示している。キャッシュインデクス（３３６）は、データ（３３８）を受け取り、これをタイムスタンプ（３４０）とともに保存する。データを収集する際、各データにはΔｔの各期間毎にマークが付される。ここで、Δｔは、マーク間の時間、例えばｔ２〜ｔ１間の期間を表す。時刻を表すマークのために他の如何なる種類のインデクスを用いてもよい。
【００８７】
表１７は、キャッシングされたデータに用いられるインデクスを概念的に示している。表１８は、キャッシングのための接続履歴を保存するためのデータを概念的に示している。表１９は、インテリジェントルータを有するネットワークノードにおいて、ローカルにキャッシングされるデータに用いられるデータ構造の具体例を示している。
【００８８】
時刻を表すマークの付与は、固定された如何なる間隔で行ってもよく、可変の時間間隔で行ってもよい。例えば、データを５分毎にキャッシングしてインデクスを付してもよい。チャンネルマネージャ２１８は、時刻及びサブジェクトを指定した、キャッシングされたデータを読み出すコマンドを受け取ると（例えば、＃．ｇｅｔＣａｃｈｅ）キャッシュインデクスを用いて、ステップ３３２における要求に対応するキャッシングされたデータを読み出すことができるか否かを判定する。
【００８９】
各サブジェクト又はチャンネルは、例えば、マルチキャストツリーにおけるそれ自身のＩＰアドレスと、１組のインテリジェントルータとを含むことができる。表１８は、ユーザ装置にローカルに保存することができるこのようなルータ間の接続履歴を示している。エッジルータに障害が発生した場合、装置は、接続履歴にアクセスし、エッジルータがオンラインに戻った際にチャンネルのアップストリームのルータにどのように再接続できるかを調べる。また、装置は、自らが接続されていなかった期間について、キャッシュデータを取得するためのコマンド（get cache command）を実行して、購読予約に関するペンディング中のコンテンツを得ることができる。
【００９０】
【表１７】
2005532748.tif 000020
【００９１】
【表１８】
2005532748.tif 000021
【００９２】
【表１９Ａ】
2005532748.tif 000022
【００９３】
【表１９Ｂ】
2005532748.tif 000023
【００９４】
これらの例示的なデータ構造は、以下の情報を含んでいる。サブジェクトノードは、サブジェクト識別子と、サブジェクトレベルと、親チャンネル又はサブジェクトノードへのポインタと、自らのディレクトリのためのファイル記述子と、次のレベルのサブジェクトノードを含むハッシュテーブルへのポインタと、データノードへのポインタとを含んでいる。データノードは、サブジェクト親ノードへのポインタと、データディレクトリのためのファイル記述子と、各ストレージデバイスに保存されたデータのためのデータ構造を含む循環型のバッファと、バッファのヘッド及びテールと、読出及びストレージの間にデータノードをロックするためのロックとを含んでいる。保存されたタイムグレインノード（time grain node）は、実際のデータファイルを表すノードであり、最後のグレインノードは、ストレージデバイスにはまだ保存されていないがメモリに保持されているバッファを表す。この実施例におけるキャッシング及びデータ格納スレッドは、最後のタイムグレインノードのミューテックスを用いて、最後のタイムグレインノードが同時にアクセスされることを防いでいる。
【００９５】
エージェントにおける処理
図１６は、送信される購読予約メッセージのためのエージェント処理３５０のフローチャートである。処理３５０は、例えば、ユーザ（購読者）装置１２２におけるプロセッサ１３４によって実行されるエージェント１２８を含むソフトウェアモジュールによって実現することができる。処理３５０において、エージェント１２８は、例えば、図１１及び図１２を用いて上述した処理（ステップ３５２）によって生成された購読予約を受け取る。エージェント１２８は、購読予約のための論理式を特定するストリングを作成し（ステップ３５４）、ストリングを解析して、購読予約におけるエラーを検出する（ステップ３５６）。エラーが存在している場合、エージェント１２８は、ユーザにエラーメッセージを示し（ステップ３６０）、ユーザがエラーを修正し、購読予約を再入力するように促す。購読予約がエラーを全く含んでいない場合（ステップ３５８）、エージェント１２８は、後述するように、データ構造内の表現を保存する（ステップ３６２）。エージェント１２８は、データ構造に含まれる不等価演算子を正の形式に変換し（ステップ３６４）、更にデータ構造を対応する選言標準形（disjunctive normal form：以下、ＤＮＦという。）に変換する（ステップ３６６）。また、エージェント１２８は、範囲フィルタ及びメンバーシップ検査のみが含まれるように、ＤＮＦ構造のＡＮＤ式を簡約する（ステップ３６８）。
【００９６】
ＤＮＦは、論理式が１つ以上の部分式のＯＲ（選言と呼ばれる）として表され、各部分式が１つ以上の属性検査のＡＮＤで表されるよく知られている標準形である。例えば、論理式（price >= 10 AND (symbol ="LU" OR symbol ="T")）に同等なＤＮＦ表現は、（(price >= 10 AND symbol ="LU") OR (price >= 10 AND SYMBOL ="T")）である。
【００９７】
ステップ３６４における変換は、「不等価」演算子（例示的な構文では、！＝と表す。）を有する表現を、許可されていない１つの値に代えて、許可されている全ての値を特定する同等な「正」の形式に変換する処理を含む。この実施例に用いるルータは、正の形式の式を要求するため、この変換は、ＤＮＦを生成する前に行われる。例えば、表現（price != 80）は、同等な正の表現（price<= 79 OR price >=81）に変換される。
【００９８】
ステップ３６８における変換は、ＤＮＦが作成された後に実行され、ここで生成されたＡＮＤ式を更に簡約する処理を含み、これにより、この実施例におけるルータの処理が簡約される。具体的には、特に、同じ属性に関する複数の属性検査のＡＮＤは、１つの下限、１つの上限、下限及び上限の両方及び等価検査の場合、単一の値のいずれかを含む正準な「範囲フィルタ」に簡約できる。特定の種類の範囲フィルタは、例えば表２２に基づいて符号化される。
【００９９】
例えば、表現（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）は、表現を満足させる「ｐｒｉｃｅ」の値がないので、偽に簡約することができる。フィルタ表現全体が偽に簡約される特別な場合、エージェントは、メッセージを作成する必要がなく、これによりルータを不要な作業から解放することができる。
【０１００】
サブジェクトフィルタがワイルドカードを含んでいる場合、エージェント１２８は、後述するように、それらを任意に変換することができる（ステップ３７０）。これに代えて、如何なるワイルドカードもユーザ装置又は他の機器ではなく、ネットワークにおいて変換してもよい。この例示的な実施例では、サブジェクトフィルタのための構文は、ワイルドカードを用いる唯一の構文であり、属性フィルタのための構文は、論理式を用いる唯一の構文である。これに代えて、サブジェクトフィルタと属性フィルタについて、異なる又は可変の種類の構文を用いてもよい。
【０１０１】
エージェント１２８は、生成されたＤＮＦ表現をメッセージに符号化し（ステップ３７２）、メッセージをインテリジェントルータに転送する（ステップ３７４）。この符号化は、購読予約をフラットなメッセージフォーマットに変換処理を含み、これは、フラットなメッセージフォーマットとは、データのストリングから構成されるフォーマットを意味する。また、この転送の処理は、購読予約に関してサブジェクトフィルタと属性フィルタによって生成されたルーティング規則をネットワークにおける１つ以上のインテリジェントルータ又は他のルーティングエンティティに伝播させる処理を含む。この伝播のために、例えば、購読予約の表現を従来のパケット構造にマッピングすることができる。
【０１０２】
ステップ３７２における符号化は、チャンネルを介した伝播のために、チャンネルに対応する購読予約をメッセージングＡＰＩのメッセージングフォーマットに変換する処理を含む。例えば、購読予約は、サブジェクト＃．ＳＵＢＳＣＲＩＰＴＩＯＮを含む通知として内部的にメッセージングされる。任意の個数のサブジェクトフィルタフィールドと任意の個数の属性検査の両方があるので、この実施例では、１組のバイトを用いてサブジェクトフィルタフィールドの個数を保存し、もう１組のバイトを用いて属性検査の個数を保存する。サブジェクトフィルタの個々のフィールドは、例えば元の購読予約で指定された順序に並べ替えられ、それぞれメッセージの２バイトの部分に格納される。ワイルドカードフィールドの整理については後述する。
【０１０３】
属性検査の配列においては、検査のオペランドは、通知における属性値の配置と同様、メッセージの最後に配置される。属性検査とオペランドを配置する前に、これらは、所定の属性に対する位置順の検査と、これに続く任意の属性に対する名称順の検査によって、ＤＮＦの各選言肢内で属性順にソートされる。更に、各選言肢内のスカラ的に評価された属性に対する関係検査の組は、１つの極限を有する範囲フィルタ（右又は左が開いている範囲又は等価検査）又は、２つの極限（別個の極限の間の閉じられた範囲）として、標準形に簡約される。検査に関する残りの情報は、オペランドと同じ順序で例えば、２つのバイトの対に符号化される。この２つのバイトの対のシーケンスは、メッセージ内において、サブジェクトフィルタフィールドの２バイトの符号化データのシーケンスの直後に配置される。２つのバイトの対は、属性検査のビットストリング符号化データのシーケンスの１つの形式を構成でき、これは、２つのバイトの対とは別に、他の種類の符号化データを表すためにも用いることができる。属性検査の具体例については、後述する。
【０１０４】
表２０は、属性検査の符号化のための手法を示している。表２１は、２つのバイトの対による符号化を示し表２２は、２つのバイトの対における演算子ＩＤの符号化を示している。
【０１０５】
【表２０】
2005532748.tif 000024
【０１０６】
【表２１】
2005532748.tif 000025
【０１０７】
【表２２】
2005532748.tif 000026
【０１０８】
検査のための２つのバイトの対が既に検査のオペランドの両方の種類を示しているので、検査が所定の属性に適用されるか任意の属性に適用されるか否かに関わらず、任意の属性又はそれらの種類に対して実行される複数の検査を個別に整理する必要はない。この手法では、通知における所定の属性の数が１２７個以下であると仮定している。これに代えて、この設計において、より多くのビットを用いて属性検査を符号化してもよい。
【０１０９】
この配列の取り決めでは、属性フィルタのＤＮＦに基づいて、属性検査の順序を決定し及びこれらをグループ化するが、インフラストラクチャ要素（例えば、ルータ）は、属性フィルタの包括的な評価をより効率的に行うために、検査を別の順序で（例えば、異なる検査の成功又は失敗の確率に関するローカルデータから動的に導出される順序で）選択して評価してもよい。メッセージの購読予約ＩＤフィールドは、後続する要求において、エージェントのエッジルータへの購読予約を固有に識別し、購読予約を変更又は取り消すためにエージェントによって生成される値である。具体的には、購読予約の属性フィルタへの動的な変更は、サブジェクトが＃．ＲＥＳＵＢＳＣＲＩＰＴＩＯＮである点及び購読予約ＩＤが事前に登録され、現在変更されている購読予約のＩＤである点を除いて、図１８の実施例に示されるメッセージフォーマットを用いて伝播される。購読停止（unsubscription）は、例えば、サブジェクトを＃．ＵＮＳＵＢＳＣＲＩＰＴＩＯＮとし、購読予約ＩＤを先に登録され、購読停止処理が行われている購読予約のＩＤとして、購読予約ＩＤフィールドを介して、図１８に示すメッセージフォーマットを用いて伝播される。
【０１１０】
以下、上述したエージェントによる変換及び符号化の具体例を説明する。まず、次のような属性フィルタ表現の具体例について考察する。すなわち、ｐｒｉｃｅ＞＝１０及び（symbol == "LU" 又は(volume >= 1000且つvolume <= 10000)）。図１９は、ステップ３６２において、表現を保存するためにエージェントによって用いられるオブジェクトを統一モデリング言語（ＵＭＬ）によって表したダイアグラム３９０を示している。このダイアグラム３９０は、変数、定数又はその両方を含むことができる購読予約を特定するための階層関係を示している。ダイアグラム３９０内のオブジェクトは、個々の実施例に応じて、フィルタクラスのインスタンスであってもよい。各ＳｉｍｐｌｅＦｉｌｔｅｒオブジェクトは、フィルタ表現の対応する属性検査に関する情報を保存するために用いられる属性の値を表している。図１９に示す表現では、ＯＲフィルタ３９６は、２つのＡＮＤフィルタ３９２、４００を結合している。ＡＮＤフィルタ３９２は、購読予約のための属性を有するシンプルフィルタ（simple filter）３９４を含んでいる。同様に、ＯＲフィルタ３９６は、シンプルフィルタ３９８を含み、ＡＮＤフィルタ４００は、シンプルフィルタ４０２と４０４を含んでいる。
【０１１１】
この実施例においては、関連するチャンネルの属性として、属性価格（price）、シンボル（symbol）及びボリューム（volume）が予め定義されているとし、これらの属性について、それぞれ位置０、１、２が定義されているものとする。更に、各属性の種類をそれぞれ、符号なし整数（タイプコード６）、文字アレー（タイプコード１２）、符号なし整数（タイプコード６）とする。
【０１１２】
次に、属性フィルタとして上述した属性フィルタ表現を含む購読予約について考察する。図１８は、購読予約をメッセージに配列した具体例を示している。図１８の左側のデータ構造３８６は、実際のメッセージのコンテンツを示しており、図１８の右側のデータ構造３８８は、メッセージの各部分の説明を示している。この図面における各データ構造の幅は、４バイトに対応している。配列を行う前に、フィルタは、（price >= 10 and symbol == "LU"）又は、（price >= 10 and volume >= 1000 and volume <= 10000）のような同等なＤＮＦに変換される。
【０１１３】
１６ビットの属性検査符号化データは、異なる部分を分離するギャップを有するビットシーケンスとして示される。なお、この実施例においては、価格に対する２つの検査は、それぞれ別々の選言肢内に存在するので、結合することができず、したがって、これらは、右側の境界を有さない範囲（右側が開いた範囲）として個別に配列される。一方、ボリュームに対する２つの検査は、同じ選言肢内に存在するので、結合することができ、したがって、これらは、単一の「閉じた範囲」の検査として整理される。
【０１１４】
また、あるフィールドは「仮定（assumed）」として特徴付けられ、これは、この具体例においては、これらのフィールドの値が、任意に選択され、通常、配列された購読予約から独立していることを意味する。更に、購読予約のためのサブジェクトフィルタは、「＞」として任意に選択され、これは、関連するチャンネルによって定義された如何なるサブジェクトにも一致する。上述し、図１８及び図１９に示した具体例は例示的なものであり、この整理は、他の如何なる種類の購読予約とともに用いてもよい。また、処理３５０は、購読予約の整理の一例に過ぎず、購読予約は、他の如何なる方法によって整理してもよい。
【０１１５】
図１７は、送信されてきたメッセージのためのエージェント処理３７６のフローチャートである。処理３７６は、例えばユーザ装置１２２内のエージェント１２８及びアプリケーション１２６によって実現することができる。処理３７６において、エージェント１２８は、インテリジェントルータから購読予約に対応するメッセージを受け取る（ステップ３７８）。１２８エージェントは、例えば、メッセージのチャンネルＩＤによって購読予約に対応するチャンネルを判定し（ステップ３８０）、チャンネルのＡＰＩを呼び出す（ステップ３８２）。ＡＰＩは、ユーザ装置において、購読予約のためのデータをＧＵＩ又は他のフォーマットで表示する（ステップ３８４）。入力メッセージに対する処理としては、上述した符号化処理の逆のデータ復号処理を用いることができ、この復号（逆符号化）は、ルータ又は他のネットワークエンティティにおいて実行することができる。
【０１１６】
ワイルドカード処理
図２０は、ワイルドカード処理４１０のフローチャートである。処理４１０は、フィルタのルーティング規則の組を用いて、ワイルドカードを購読予約のための表現に変換する処理の一例である。処理４１０は、例えば、ユーザ装置１２２内のプロセッサ１３４によって実行されるエージェント１２８によって表されるソフトウェアモジュールとして実現してもよい。これに代えて、ネットワークにおいて、ソフトウェア制御の下で、インテリジェントルータ９２又は対応する機能を有するＡＳＩＣ９１内のプロセッサ９３によりワイルドカードを処理してもよい。ワイルドカードは、開かれたフィールド又は可変長フィールドを含んでおり、表２１はこのようなフィールドの具体例を示している。
【０１１７】
処理４１０において、エージェント１２８又は他のエンティティは、ワイルドカードを含む購読予約を受け取る（ステップ４１２）。購読予約のサブジェクト長は、発行者がコンテンツを発行する際に指定でき、サブジェクトは、発行者装置において前処理してもよく、例えばサブジェクトのフィールドを数え、これによりフィールドカウント（長さ）を算出してもよい。１２８エージェントは、フィルタオペランド内のフィールドの数を数える（ステップ４１４）新たな規則（フィルタ）をフィールド長＝Ｎとして初期化する（ステップ４１６）。エージェント１２８は、購読予約のサブフィールドを読み出し（ステップ４１８）、フィルタオペランドサブフィールド０［ｉ］がワイルドカードであるか否かを判定する（ステップ４２０）。フィルタオペランドサブフィールドがワイルドカードでない場合、エージェント１２８は、連言項（conjunctive clause）を規則に追加し、フィールド［ｉ］＝０［ｉ］とする（ステップ４２２）。フィルタオペランドが更なるサブフィールドを有している場合（ステップ４２４）、エージェント１２８は、ステップ４１８に戻り、この更なるサブフィールドを処理する。パラメータ「ｉ」は、フィールドを表し、ｉは、この実施例においては、フィールド番号を表す整数である。
【０１１８】
サブフィールドを処理した後にエージェント１２８は、最後のフィルタオペランドサブフィールドが「＞」であるか否かを判定し（ステップ４２６）、最後のフィルタオペランドサブフィールドが「＞」である場合、長さの制約条件をフィールド長＞Ｎ−１に変更する（ステップ４２８）。ワイルドカード処理は、如何なる種類のシンボルを用いてもよく「＞」は、その一例に過ぎない。この具体例においては、「ａ．＞」により、ａ．ｂ、ａ．ｃ、ａ．ｄ等及び全てのレベルにおけるこれらの全てのサブサブジェクト（例えば、ａ．ｂ．ｘ、ａ．ｃ．ｘ、ａ．ｂ．ｘ．ｙ等）を表すことができる。また、他のシンボルをワイルドカードとして用いてもよい。
【０１１９】
必要であれば、エージェント１２８は、変形した規則をインテリジェントルータ又はネットワークにおける他のエンティティに伝播する（ステップ４３０）。処理は、全てのサブフィールドについて繰り返され、これにより、ワイルドカードが非ワイルドカード規則に変換される。非ワイルドカード規則とは、ワイルドカードを含まない規則を意味する。ワイルドカードの変換は、ネットワーク内のどこで行ってもよく、例えば、購読者装置又はインテリジェントルータにおいて行ってもよい。したがって、この変換は、変形規則によって１つのエンティティで行い、他のエンティティに伝播させてもよく、又はこの変換を動的に行ってもよい。
【０１２０】
表２３は、ワイルドカードの処理のためのこれらの例示的なルーティング規則の概要をその具体例とともに示している。これらのルーティング規則は、例えば、インテリジェントルータで生成してもよく、又は他のネットワークエンティティで生成し、インテリジェントルータに伝播させてもよい。更に、表２３のルーティング規則は、説明のために例示的に示しているに過ぎず、他のルーティング規則を用いてワイルドカードを変換してもよい。
【０１２１】
【表２３】
2005532748.tif 000027
【０１２２】
アラートサービス
上述したインテリジェントなコンテンツベースのルーティングは、様々な用途に用いることができ、その１つとして、デジタルビデオ監視システム（digital video surveillance system：以下、ＤＶＳＳという。）がある。例えば、警察又は又は警備会社等のユーザは、特定の位置のカメラからのビデオクリップを購読予約することができる。カメラは、デジタルビデオクリップを撮像し、例えばインターネット等、コンテンツベースのルーティングを有するネットワークを介してこれらのクリップを送信し、ネットワークコアは、購読予約に基づいて、ビデオクリップを処理する。これにより、ユーザは、興味があるビデオクリップを受信し、これらのフィルタリングは、ネットワークを介して配信することができる。ビデオクリップに加えて例えば、機密保護違反、発火、不正検出等に対する如何なる種類の警告を提供するために、他の如何なる種類のコンテンツを配信してもよい。
【０１２３】
他の実施例としてカメラは、関連する動きセンサを備えていてもよい。この運動センサは、動きを検出すると、カメラをトリガし、撮像と同時にビデオクリップをネットワークに送信させ、ネットワークは、コンテンツベースのルーティングを用いて、購読者にビデオクリップをルーティングする。
【０１２４】
このように、上述したコンテンツベースのルーティングにより、ビデオクリップの処理及びルーティングに関するネットワークの負担を大幅に削減することができる。例えば、各電荷結合素子（charge coupled device：ＣＣＤ）によって生成されたビデオ信号を、デジタルビデオレコーダ（ＤＶＲ）によって、ＤＶＲによって管理されたローカルストレージ、ネットワークに付属するグローバルストレージ、ＤＶＳＳシステム、及びＩＤＳＳ管理サーバといった４つの異なる宛先に書き込む必要があるとする。このような巨大なデータ量を搬送するためのネットワーク帯域幅を考慮すると、ＩＤＳＳによって管理されるＣＣＤ又はＤＶＲの容量が顧客の能力要求を満たさない場合がある。したがって、例えば、媒体又は大口顧客のための技術を用いて、帯域幅を制限する必要がある。図２１は、各ＤＶＲが、４個又は１６個のＣＣＤＳを管理できる監視システムの包括的なアーキテクチャを示している。
【０１２５】
アーキテクチャ概要： 
図２２は、主に上述した技術に基づいて、図２１に示す監視システムの能力を向上させる２つの拡張例を示している。図２２に示すように、第１の拡張は、ＤＶＲバックボーントラヒックを低減することを目的とし、第２の拡張は、上述したようなデータ配信効率を向上させるための機能と同様なコンテンツベースのルーティング機能を提供するｚボックス（z-box）と呼ばれる機器を用いる。
【０１２６】
ＤＶＲバックボーンのローカルトラヒックの低減：
データ配信スキームが非効率であると、重大なスケーラビリティ問題が生じることがある。すなわち、ＴＣＰベースのプロトコルを用いて、ＤＶＲによって生成される画像ファイルを他のボックスに供給する場合、使用される帯域幅は、ローカルエリアネットワーク（ＬＡＮ）に接続されている機器の数に比例して大きくなる。例えば、ＩＤＳＳについて言えば、同じストリーミングビデオデータは、ネットワークに接続されたストレージ（ＳＡＮ又はＮＡＳ）、ＩＤＳＳモニタ、及び遠隔モニタリングソフトウェアである各ＤＶＳＳに送信する必要がある。
【０１２７】
この問題を解決する１つの手法として、各ＤＶＲが１つのみのデータストリームをＬＡＮに発行し、ネットワークに接続された他の機器が購読予約の結果としてこのデータストリームを受け取るようにしてもよい。この場合、ＤＶＲの出力レートが１０メガビット／秒（Ｍｂｐｓ）であれば、例えば、ネットワーク上に３個の購読機器に情報を提供するために必要な出力レートは、３０Ｍｂｐｓではなく、１０Ｍｂｐｓで足りる。
【０１２８】
このような発行−購読構造を実現するために、ＤＶＲボックス又はＤＶＲデータを利用する他の何らかの機器（例えば、ＩＤＳＳ、グローバルストレージ）において、上述したイベント通知ＡＰＩを用いることができる。このＡＰＩは、単純であるが有効であり、ここではＩＰマルチキャスティング及び回復プロトコルを用いることができる。また、このＡＰＩは、上述の発行−購読モデルに基づいて実現でき、このため、他のインプリメンテーションはコードを変える必要はなく、単に、ＡＰＩを提供するライブラリの完全なバージョンに再リンクさせればよい。
【０１２９】
ＤＶＳＳのためのプロキシ：
各ＤＶＳＳは、（ＴＣＰベースで）ＤＶＲボックスへの１つの接続を確立し、ストリーミングビデオデータを受け取ることができる。
【０１３０】
図２２に示すように、この手法は、２つの段階によって説明することができる。第１の段階であるステージ１では、ＬＡＮ側において、全てのＤＶＳＳ発信データ（すなわちＤＶＲからＤＶＳＳに供給されるデータ）を処理するためのプロキシサーバ（例えば、ｚボックス１）を準備する。このプロキシサーバは、ＬＡＮ上の全てのＤＶＲデータを購読し、外部のネットワーク（例えば、インターネット）にそのデータを発行する。ＤＶＳＳは、このデータを購読する。したがって、プロキシサーバであるｚボックス１は、購読者エージェント（例えば、エージェント１２８）と、ＤＶＲからデータを集める上述した発行−購読ネットワーク等の発行−購読ネットワークを介してこのデータを発行する発行者エージェント（例えば、エージェント３６）とを提供する。
【０１３１】
ステージ１により、ＬＡＮ側において、トラヒックを大幅に削減することができるが、特に幾つかの国において、典型的な非対称デジタル加入者線（ＡＤＳＬ）が６４のキロビット／秒（ｋｂｐｓ）のアップリンク速度しか有していないような場合、送信リンクにおけるトラヒックの問題が残る。
【０１３２】
更に図２２を用いて説明すると、ステージ２では、好ましくは、サービスプロバイダの機械室（machine room）を借り受け又は他の手法で確保し、ここに第２のｚボックス機器、例えばｚボックス２を配設する。例えば、ｚボックス機器は、ハイネットバックボーン上に配設してもよい。この機器から顧客の敷地内において、ｚボックス２への単一の接続（トンネル）を確立できる。
【０１３３】
この場合顧客の敷地内のｚボックス２は、購読者エージェント（例えば、エージェント１２８）として機能する。また、ｚボックス２は、ルーティングデーモン（例えば、ルーティングデーモン２１６）としても機能できる。ｚボックス２は、購読者エージェントとして（例えば、ハイネット機械室（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）（チャンネル、サブジェクト、フィルタ、ｌｏｃａｌ＿ｐｕｂｓ、ｔｉｍｅ＿ｐｅｒｉｏｄ、ＦＩＦＯ、ルータのアレーメッセージをＡＰＩ５５４が接続されていた最後のエッジキャッシュに送信する。キャッシュマネージャ２１８は、好ましくは、チャンネルＩＤ、サブジェクト及びタイムスタンプに基づいてデータをプルし、このデータをエージェント１２８に戻す。キャッシュマネージャ２１８によるデータの供給が完了すると、キャッシュマネージャ２１８は、キャッシュ完了イベント（DoneCache event）をキャッシュＡＰＩに渡し、データの転送がキャッシングされた全てのデータが配信されたことを示す。
【０１８６】
キャッシュマネージャ２１８がデータをローカルで検出できない場合、キャッシュマネージャ２１８は、エージェント１２８によって提供される「ルータのリスト」を用いて、必要なデータを検索する。キャッシュマネージャ２１８が必要な全てのデータを集めると、キャッシュマネージャ２１８は、必要なデータを照合し、重複削除を行った後に、このデータをエージェント１２８に供給する。
【０１８７】
キャッシュ接続履歴：
キャッシュ５４６からのデータの検索を可能にするために、好ましくは、エージェント１２８において、アップストリームのキャッシュと同様に両方の側のキャッシュに関するキャッシュ接続履歴が維持される。この情報は、エージェント１２８がシャットダウン及びクラッシュした場合に必要であるので、この情報は、ファイルに持続的に保存する必要がある。キャッシュ接続履歴は、好ましくは、以下のようなファイル及びフォーマットによってディスクに保存される。
【０１８８】
エッジキャッシュ位置： 
エッジキャッシュの位置（例えば、エッジルーティングノード５４６のキャッシュ５４６）は、好ましくは、チャンネルマネージャ／チャンネルライブラリから得られる。これは、起動時及びこれに続く、例えば、接続の切断／再接続、接続の変更等によってエッジキャッシュが変化した、如何なる時点でも発生する。ディスパッチャは、エッジキャッシュ接続の全ての変化をエージェント１２８に通知し、これらの変化は、エージェント１２８のキャッシュライブラリに伝えられる。変化が起こるたび、その情報は持続される。
【０１８９】
持続的なストレージ：ＣＡＣＨＥ＿ＲＯＯＴ／ｃｈａｎｎｅｌ＿ｉｄ／Ｃｈａｎｎｅｌ−キャッシングされたデータのためのパスの具体例
データは、好ましくは次のようなフォーマットで保存される。
エッジキャッシュの数；
エッジキャッシュ１：インターバルの数、ＳｔａｒｔＴｉｍｅｌ：ＥｎｄＴｉｍｅｌ，  ＳｔａｒｔＴｉｍｅ２：ＥｎｄＴｉｍｅ２，．．．；
エッジキャッシュ２：インターバルの数、ＳｔａｒｔＴｉｍｅｌ：ＥｎｄＴｉｍｅｌ，  ＳｔａｒｔＴｉｍｅ２：ＥｎｄＴｉｍｅ２，．．．；・・・
ここで、最後のタイムスタンプがリストの最初に設けられる。なお、２つの異なるエッジキャッシュが重複する期間を有することはない（エージェント１２８は、一度に１つのエッジキャッシュのみに接続されるため）。新たなエントリが追加される毎に、古いエントリは、それらがまだ有効であるか確認され、それらが無効である場合、このエントリは、削除される。期間は、時刻ＥｎｄＴｉｍｅ＋チャンネルの持続期間＜現在の時刻となった場合、無効となる。
【０１９０】
エッジキャッシュエントリは、エントリ内の全ての期間が無効になった場合、無効になる。なお、「ＥｎｄＴｉｍｅ」が０であるということは、その期間が現在有効であることを意味する。
【０１９１】
アップストリームのキャッシュ位置：
アップストリームのキャッシュ（例えば、コアルーティングノード５４８のキャッシュ５４６）の位置は、サブジェクトに依存している。各サブジェクトは、それ自身のマルチキャストツリーを有し、したがって、第１のレベルのアップストリームのキャッシュの組は、サブジェクトの関数である。ユーザがサブジェクトを購読予約すると、インテリジェントルータ９２は、必ずサブジェクトに関連しているアップストリームのキャッシュのリストを返す。同様に、障害又はマルチキャストツリーの再構成に起因するアップストリームのキャッシュ位置のあらゆる変化は、制御パスを介してエージェント１２８に伝えられる。これらの変化は、持続的なメモリ（ファイル）にローカルに記録される。
【０１９２】
持続的なストレージ：ＣＡＣＨＥ＿ＲＯＯＴ／ｃｈａｎｎｅｌ＿ｉｄｅｎｔｉｆｉｅｒ／ｓｕｂｊｅｃｔ（階層ではなく、完全なサブジェクト）−キャッシングされたデータのためのパスの具体例
データは、好ましくは、以下のフォーマットで保存される。
アップストリームキャッシュの数；
アップストリームキャッシュ１：インターバルの数、ＳｔａｒｔＴｉｍｅｌ：ＥｎｄＴｉｍｅｌ，  ＳｔａｒｔＴｉｍｅ２：ＥｎｄＴｉｍｅ２，．．．；
アップストリームキャッシュ２：インターバルの数、ＳｔａｒｔＴｉｍｅｌ：ＥｎｄＴｉｍｅｌ，  ＳｔａｒｔＴｉｍｅ２：ＥｎｄＴｉｍｅ２，．．．；・・・
ここでも、最後のタイムスタンプがリストの最初に設けられる。エッジキャッシュ期間とは異なり、エージェント１２８は、所定のサブジェクトについて、複数のアップストリームのキャッシュを有することができるので、２つのアップストリームキャッシュが重複する期間を有することがある。また、アップストリームのキャッシュファイルのコンテンツは、エッジキャッシュの場合と同様なアルゴリズムを用いて集められたガーベージである。
【０１９３】
データ検索の間のキャッシュ妥当性：
エージェント１２８が有効な間、エージェント１２８は、接続を介して、異なるエッジルータ及びアップストリームルータ間を移動する。エージェントキャッシュＡＰＩ５５４は、好ましくは、この接続履歴をローカルメモリに保存する。エージェント１２８が、キャッシュ５４６からデータの最後のＴ期間を読み出す必要がある場合、エージェントキャッシュＡＰＩ５５４は、好ましくは、接続履歴を調べ、そのデータにアクセスするためのキャッシュを判定する。これのために用いられるアルゴリズムは、好ましくは以下の通りである。（１）キャッシュライブラリは、全てのエッジキャッシュ期間を探検し、Ｔタイムフレーム内に含まれる期間を確認する。（２）リストＬｅは、期間開始時刻に基づいて、リストＬｅをソートする。（３）ＬＥ内のエッジキャッシュによってカバーされていない各期間について、アップストリームキャッシュを探索し、この期間をカバーできる全てのアップストリームキャッシュ期間に関する情報を得て、有効な期間をリストＬｕに加え、ＬｅにＬｕを追加し、期間開始時刻を用いてＬｅをソートし、Ｌを作成する。
【０１９４】
このアルゴリズムによりキャッシュのリストＬが生成され、各キャッシュについて、データを読み出すための期間が得られる。次に、このキャッシュのリストＬは、（４）キャッシュ読出メッセージに組み込まれ、キャッシュマネージャ２１８に送信される。キャッシュマネージャ２１８側では、キャッシュマネージャ２１８は、好ましくは、（５）ゲットキャッシュメッセージからキャッシュ期間を取り出し、開始時刻順にソートされたリストＬを再構築する。リストＬの各期間の間、キャッシュマネージャ２１８は、好ましくは、（６）前の期間と現在の期間の間に、隙間があるか否かを確認し、隙間があれば、そのデータのローカルキャッシュを要求する。このような隙間がなければ、キャッシュマネージャ２１８は、好ましくは（７）関連するキャッシュにデータを読み出すよう指示する。キャッシュマネージャ２１８は、好ましくは（８）全てのキャッシュからのデータを照合し、このデータをエージェント１２８に送信する。
【０１９５】
ルータキャッシュＡＰＩ：
インテリジェントルータ９２側のルータキャッシュＡＰＩ５５２は、特定のサブジェクトのためのキャッシングを作成し、消去し、停止し、再開するためにキャッシュマネージャ２１８を呼び出す。また、ルータキャッシュＡＰＩ５５２は、初期の構成を処理する。すなわち、ルータキャッシュＡＰＩ５５２は、インテリジェントルータ９２からチャンネルマネージャ１５０にキャッシュアドレスをアップロードし、これにより、エージェント１２８側（エージェントキャッシュＡＰＩ５５４）は、必要なときにこの情報を得ることができる。更に、ルータキャッシュＡＰＩ５５２は、他のルータのキャッシュ５４６の位置を読み出す（この位置は例えば、購読予約に対する応答において及びサブジェクトツリーの変更の後にインテリジェントルータ９２が所定のサブジェクトのためのアップストリームキャッシュをエージェント１２８に通知する際に用いられる）。
【０１９６】
プルのためのキャッシュの使用： 
上述の説明では、持続的なチャンネルを実現し、購読者がネットワークからデータをプルすることによって情報を返すためのキャッシュの使用に焦点をあてた。変形例では、如何なる購読者（新たな購読者又は復帰した購読者）もキャッシュ５４６から（例えば、購読者が購読予約していないが、他の誰かの購読予約のためにキャッシュ５４６に保存されているデータを含む）あらゆる種類のデータをプルすることができる。この実施例と先の実施例との違いは、復帰した購読者については、データの存在が保証され、データの位置は、既知であるが、新たな購読者については、保存されているデータの位置が未知であるという点である。この変形例を実現する単純な手法は、チャンネルにおいて「キャッシュ検出（FindCache）」要求を発行することである。キャッシュ検出要求は、チャンネルＩＤ、サブジェクト、フィルタ、期間及び要求されたキャッシングされたデータを有するキャッシュ５４６を探すエージェント１２８の位置を含んでいる。全てのキャッシュ５４６がキャッシュ検出要求を待機している。各キャッシュ５４６が要求を受け取ると、キャッシュ５４６は、対応するデータが自らのデータストアにあるか否かを確認し、自らがそのデータを保存している場合、自らの位置をユニキャストメッセージとして返す。エージェント１２８は、キャッシュ５４６の１つを選択し、そのキャッシュ５４６をキャッシュ読出処理によって呼び出し、そのデータを得る。
【０１９７】
最新データプル：
他の実施例では、購読者アプリケーション（例えば、アプリケーション１２６）が所定のサブジェクトについて、最新のメッセージを得ることができる最新データプルを実現する。これは、例えば、株価アラート等のデータに有効であり、この場合、ユーザは、履歴ではなく、最新の株価に関する情報のみを希望する。
【０１９８】
キャッシュマネージャの実現：
キャッシュマネージャ２１８の実現においては、好ましくは、３種類のスレッドを用いる。データキャッシングスレッド−データキャッシングスレッドは、好ましくは、インテリジェントルータ９２への接続からデータを取り出し、データにインデクスを付してメモリに保存する。データストレージスレッド−期間の最後に到達すると、データストレージスレッドは、メモリに保存されているデータをディスクに移動させ、及びこの処理において、期限切れのデータに関するガーベージコレクションを実行する。データ検索スレッド−データ検索スレッドは、好ましくは、キャッシングされたデータの要求を受け、キャッシュ５４６からデータを検索する。これらの３つの種類のスレッドは、単一のスレッドとして実現してもよく、スレッドのプールとして実現してもよい。好ましくは、データキャッシングスレッドとデータストレージスレッドは、データがディスクに移動される時刻に同期される。このようにデータストレージスレッドとデータ検索スレッドとを同期させることにより、データの検索中にデータが消去されることが防止される。
【０１９９】
データ構造： 
キャッシングのためのデータ構造の具体例は、表１９及びこれに関連する説明に記した通りである。
【０２００】
データストレージ：
図３６は、「アクイラキャッシュ（Aquila Cache）」と呼ばれるキャッシュ５４６にデータファイルを保存するために用いられる好適なディレクトリ構造を示している。なお、各サブジェクトレベルのディレクトリは、好ましくは、そのサブジェクトについて発行されるデータを保存するデータディレクトリに加えて、１組の子サブジェクトディレクトリを有する。例えば、エンターテインメントチャンネルにおいて、ＦＯＸムービーから発行されたデータは、ＡｑｕｉｌａＣａｃｈｅ／エンターテインメント／ＦＯＸ／ムービー／データ（AquilaCache/Entertainment/FOX/Movies/Data）のディレクトリのファイルに格納され、サブジェクトＦＯＸについて発行されたデータは、ＡＱＵＩＬＡＣＡＣＨＥ／エンターテインメント／フォックス／データ（AquilaCache/Entertainment/FOX/Data）のディレクトリのファイルに格納される。データのストレージを高速に行うために、好ましくは、インテリジェントルータ９２がキャッシュ５４６に対し、所定のチャンネルとサブジェクトに関するキャッシングを開始するよう要求した時点で、特定のサブジェクトのディレクトリ階層を構築する。
【０２０１】
データ検索：
キャッシュ５４６からのデータ検索は、データのストレージを妨げないように、及びキャッシュ５４６がホールドアップしないように、効率的に行う必要がある。このデータ検索では、ディスクとメモリの両方からデータを読み出す。データ検索においては、好ましくは以下のようなステップを実行する。（１）データノードの位置を検出する。（２）データノードをロックする。（３）呼び出す必要があるデータのタイムスタンプを検出する。（４）データを読み出し、メモリに保存する。（５）データノードをロック解除する。（６）メモリに保存され、読み出されたデータをフィルタリングし、並べ替えた後、エージェント１２８クライアントにプッシュする。
【０２０２】
以上、例示的な実施例を用いて本発明を説明してきたが、これらの実施例を様々に変形できることは当業者にとって明らかであり、本発明は、これらの如何なる適応化又は変形をも含む。例えば、本発明の範囲から逸脱することなく、様々な種類の発行者装置、ユーザ又は購読者装置、これらのチャンネル及び構成、コンテンツベースのルーティング及び他の機能のハードウェア及びソフトウェアによる実現が可能である。この発明は、特許請求の範囲及びその均等物によってのみ制限される。
【図面の簡単な説明】
【０２０３】
【図１】ネットワークコアにおけるこのインテリジェントルーティングを概念的に示すブロック図である。
【図２】発行者及び購読者のためのインテリジェントルータを示すネットワーク図である。
【図３】インテリジェントルータとバックボーンルータのための例示的なネットワークインフラストラクチャの構成を示す図である。
【図４】インテリジェントルータのハードウェア構成を示す図である。
【図５】発行者装置及び購読者装置の構成を示す図である。
【図６】インテリジェントルータのチャンネルマネージャの構成を示す図である。
【図７】インテリジェントルータを有するネットワークに接続するためのユーザ装置のソフトウェアコンポーネントの構成を示す図である。
【図８】インテリジェントルータのためのソフトウェアコンポーネントの構成を示す図である。
【図９】メッセージのためのパケット構造を示す図である。
【図１０】発行処理のフローチャートである。
【図１１】購読処理のフローチャートである。
【図１２】チャンネル及び購読者画面を示す図である。
【図１３】コンテンツベースのルーティング処理のフローチャートである。
【図１４】キャッシング処理のフローチャートである。
【図１５】キャッシュインデクスを示す図である。
【図１６】送信メッセージのためのエージェント処理のフローチャートである。
【図１７】受信メッセージのためのエージェント処理のフローチャートである。
【図１８】メッセージの符号化の具体例を説明する図である。
【図１９】購読予約を保存するためのデータベース構造を示す図である。
【図２０】ワイルドカード処理のフローチャートである。
【図２１】デジタルビデオ監視システムの構成を示す図である。
【図２２】２段階法による、デジタルビデオ監視システムのためにプロキシを示す図である。
【図２３】デジタルコンテンツ配信のためのアーキテクチャを示す図である。
【図２４】デジタルコンテンツ配信のためのフェーズ１アーキテクチャを示す図である。
【図２５】デジタルコンテンツ配信のためのフェーズ２アーキテクチャを示す図である。
【図２６】サービス品質管理のための複数のアウトリンクを示す図である。
【図２７】サービス品質管理のための単一のアウトリンクを示す図である。
【図２８】ＩＳＰの外部におけるフィルタリング及びキャッシングを説明する図である。
【図２９】ネットワーク内のキャッシュを示す図である。
【図３０】アップストリームルータにおけるバックアップキャッシングを説明する図である。
【図３１】プロキシを有するキャッシュとルータのとの間のインタラクションを示す図である。
【図３２】購読予約に対するキャッシュの作成を説明する図である。
【図３３】インデクスツリーを示す図である。
【図３４】複数のキャッシュからの検索を示す図である。
【図３５】キャッシュマネージャと、システム内の他のモジュールとのインタラクションを示す図である。
【図３６】キャッシュのためのファイルディレクトリ構造を示す図である。
【図１】
2005532748.tif 000028
【図２】
2005532748.tif 000029
【図３】
2005532748.tif 000030
【図４】
2005532748.tif 000031
【図５】
2005532748.tif 000032
【図６】
2005532748.tif 000033
【図７】
2005532748.tif 000034
【図８】
2005532748.tif 000035
【図９】
2005532748.tif 000036
【図１０】
2005532748.tif 000037
【図１１】
2005532748.tif 000038
【図１２】
2005532748.tif 000039
【図１３】
2005532748.tif 000040
【図１４】
2005532748.tif 000041
【図１５】
2005532748.tif 000042
【図１６】
2005532748.tif 000043
【図１７】
2005532748.tif 000044
【図１８】
2005532748.tif 000045
【図１９】
2005532748.tif 000046
【図２０】
2005532748.tif 000047
【図２１】
2005532748.tif 000048
【図２２】
2005532748.tif 000049
【図２３】
2005532748.tif 000050
【図２４】
2005532748.tif 000051
【図２５】
2005532748.tif 000052
【図２６】
2005532748.tif 000053
【図２７】
2005532748.tif 000054
【図２８】
2005532748.tif 000055
【図２９】
2005532748.tif 000056
【図３０】
2005532748.tif 000057
【図３１】
2005532748.tif 000058
【図３２】
2005532748.tif 000059
【図３３】
2005532748.tif 000060
【図３４】
2005532748.tif 000061
【図３５】
2005532748.tif 000062
【図３６】
2005532748.tif 000063
【国際調査報告】
2005532748.tif 000064