(57)【特許請求の範囲】
【請求項１】
内容が更新される情報に興味があるクライアントが指定する情報識別子によって識別される前記情報を、前記内容が更新される毎に、受信情報として、データネットワークを介して前記クライアントに提供する方法であって、
前記クライアントに、前記情報の受信開始に先立って、少なくとも前記情報の識別子を情報識別子としてサブスクリプションテーブルに登録するステップと、
第１のネットワークサーバに、前記第１のネットワークサーバが第２のネットワークサーバから前記情報を受信開始するのに先立って前記情報識別子をサブスクリプションテーブルに登録するステップと、
前記第２のネットワークサーバに、前記第２のネットワークサーバが前記情報の発行者から前記情報を受信開始するのに先立ってサブスクリプションテーブルに前記情報識別子及びその情報識別子に関連付けられた第１のネットワークサーバを登録するステップと、
前記第２のネットワークサーバが前記受信情報を、受信開始以前に登録してある前記情報識別子に関連付けされた第１のネットワークサーバに送信するステップと、を含むことを特徴とする方法。
【請求項２】
前記内容が更新される情報はメタコンテンツを含むものであることを特徴とする請求項１記載の方法。
【請求項３】
前記内容が更新される情報は関連するコンテンツを得るためのリンクをも含むものであることを特徴とする請求項２記載の方法。
【請求項４】
コントローラネットワークサーバに負荷情報、もしくは障害情報を保存するステップをさらに含むことを特徴とする、請求項１記載の方法。
【請求項５】
コントローラネットワークサーバが前記第１ネットワークサーバの１つから、情報識別子に関連するサービスを前記第１ネットワークサーバに対して行うように、前記第２ネットワークサーバの１つを割当てるという要求を、受け取るステップをさらに含むことを特徴とする、請求項１記載の方法。
【請求項６】
前記情報識別子に関連するサービスを前記第１ネットワークサーバに対して行うように、前記第２ネットワークサーバの１つを割当てるステップをさらに含むことを特徴とする、請求項５記載の方法。
【請求項７】
コントローラネットワークサーバがクライアントから、情報識別子に関連するサービスをクライアントに対して行うように、前記第１ネットワークサーバの１つを割当てるという要求を、受け取るステップをさらに含むことを特徴とする、請求項１記載の方法。
【請求項８】
前記情報識別子に関連するサービスを前記クライアントに対して行うように、前記第１ネットワークサーバの１つを割当てるステップをさらに含むことを特徴とする、請求項７記載の方法。
【請求項９】
複数のコンテンツ発行者から複数のクライアントへ更新された情報を配信するためのコンテンツ配信ネットワークであって、
前記複数のクライアントからのコンテンツ要求もしくは、コンテンツ配信へのサブスクライブに対し、更新された情報の転送を行う複数の第１のネットワークサーバと、コンテンツ発行者のコンテンツの更新を検知した場合にその更新された情報を取得する複数の第２のネットワークサーバと、前記更新されるコンテンツに関するサブスクライブを行うべき先となる前記第２ネットワークサーバを前記第１ネットワークサーバに割当てるコントローラネットワークサーバとを含み、
前記複数の第２のネットワークサーバの各々は、前記コンテンツの情報識別子に関して前記コントローラネットワークサーバにより前記第２のネットワークサーバを割当てられている第１のネットワークサーバから前記情報識別子に関するサブスクライブリクエストを始めて受信したら、それ以降、前記情報識別子に対応するコンテンツ発行者から更新された情報を取得したら、これを前記第１のネットワークサーバに転送する
ことを特徴とするコンテンツ配信ネットワーク。
【請求項１０】
請求項９記載のコンテンツ配信ネットワークにおいて、
前記複数の第１のネットワークサーバの各々は、あるクライアントからある情報識別子に関するサブスクライブリクエストを始めて受信したら、前記サブスクライブリクエストを前記コントローラネットワークサーバから割り当てられた第２のネットワークサーバに転送し、ある第２のネットワークサーバからある情報識別子に関して更新された情報を転送された場合は、前記更新された情報を、少なくとも同一の情報識別子に関して、次に更新された情報を転送されるまでは保持することを特徴とするコンテンツ配信ネットワーク。
【請求項１１】
請求項９記載のコンテンツ配信ネットワークにおいて、
前記複数の第１のネットワークサーバの各々は、あるクライアントからある情報識別子に関するコンテンツ要求を始めて受信したら、前記情報識別子に関するサブスクライブリクエストを前記コントローラネットワークサーバから割り当てられた第２のネットワークサーバに発信し、ある第２のネットワークサーバからある情報識別子に関して更新された情報を転送された場合は、前記更新された情報を、少なくとも同一の情報識別子に関して、次に更新された情報を転送されるまでは保持することを特徴とするコンテンツ配信ネットワーク。
【請求項１２】
予めクライアント側ネットワークサーバから情報識別子の指定によりサブスクライブリクエストがあった、一つもしくは複数のコンテンツ発行者が生成するコンテンツにおいて自らがその更新を検知した情報をクライアント側ネットワークサーバへ転送するコンテンツ発行者側ネットワークサーバにおいて、
前記情報に関する情報識別子と、それに関して、前記コンテンツ発行者側ネットワークサーバから前記更新を検知した情報の転送先となるべき前記クライアント側ネットワークサーバのサーバ識別子とを保存するサブスクリプションテーブルを備え、
ネットワークコントローラサーバから前記コンテンツ発行者側ネットワークサーバをサブスクリプションリクエストの転送先として割当てられた前記クライアント側ネットワークサーバからサブスクライブリクエストを受信した際、そこに含まれる情報識別子が前記サブスクリプションテーブルに保存されていない場合は、前記情報識別子を前記テーブルに登録し、
前記サブスクリプションテーブル上に保持された情報識別子で指定されるおのおののコンテンツ発行者から更新された情報を受信した場合は、前記サブスクリプションテーブルを参照して、前記更新された情報に関する情報識別子に対応する全てのクライアント側ネットワークサーバに、前記更新された情報を転送することを特徴とするコンテンツ発行者側ネットワークサーバ。
【請求項１３】
予めコントローラネットワークサーバから割当てを受けたクライアントからの取得リクエストもしくはサブスクライブリクエストに基づいて、複数のコンテンツ発行者から発行された更新された情報を複数のクライアントへ配信するクライアント側ネットワークサーバにおいて、
前記情報に関する情報識別子を保存するサブスクリプションテーブルと、予めコントローラネットワークサーバからサブスクリプションリクエストの転送先として割当てられたコンテンツ発行者側ネットワークサーバから受信した前記更新された情報を保存する手段とを備え、
あるコンテンツ発行者側ネットワークサーバからある情報識別子に関して新たに更新された情報を転送された場合は、前記更新された情報を、すくなくとも次に前記情報識別子と同一のものに関して更新された情報を転送されるまでは保持し、
前記情報識別子に関するクライアントからのアクセスに対して、前記保存する手段で保存された前記情報識別子に関する前記更新された情報を前記クライアントに送信することを特徴とするクライアント側ネットワークサーバ。
【請求項１４】
前記複数のクライアントの一つからある情報識別子に対する情報のアクセス要求を始めて受信した場合は、前記情報識別子に関するサブスクライブリクエストを生成して、これを、コントローラネットワークサーバから割り当てられたコンテンツ発行者側ネットワークサーバに送信することを特徴とする請求項１３記載のクライアント側ネットワークサーバ。
【請求項１５】
請求項１３のクライアント側ネットワークサーバにおいて、前記複数のクライアントの一つからある情報識別子に関するサブスクライブリクエストを始めて受信した場合は、自らを要求者とするサブスクライブリクエストを生成して、コントローラネットワークサーバから割り当てられたコンテンツ発行者側ネットワークサーバに送出することを特徴とするクライアント側ネットワークサーバ。
【請求項１６】
関心をもつ更新された情報の配信を受けるクライアントにおいて、当該クライアントが配信を要求する情報に関する情報識別子及び割り当てられたクライアント側ネットワークサーバのサーバ識別子を登録するサブスクリプションテーブルを備え、
当該クライアントのユーザによって新たに情報識別子が前記サブスクリプションテーブルに登録されたら、前記情報識別子に関して、コントローラネットワークサーバからクライアント側ネットワークサーバの割り当てを要求する手段と、
前記クライアント側ネットワークサーバの割り当てを受けたら、そのサーバ識別子を関連する前記情報識別子に対して前記サブスクリプションテーブルに登録し、サブスクライブリクエストを前記クライアント側ネットワークサーバに送出する手段と、
前記割り当てられたクライアント側ネットワークサーバに対して、更新される情報を取得するために周期的にアクセスする手段とを有していることを特徴とするクライアント。
【請求項１７】
更新される情報に関心を持つ複数のクライアントと通信して更新される情報をサブスクリプションテーブルに基づいて、前記クライアントに配信する複数の第１のネットワークサーバと、コンテンツ発行者と通信して更新される情報の取得を行う複数の第２のネットワークサーバとを含むコンテンツ配信ネットワークにおいて、前記第１及び第２のネットワークサーバに共通に、使用されるコントローラネットワークサーバであって、
あるクライアントからある情報識別子に関する、第１のネットワークサーバの割り当て要求を受けたら、前記複数の第１のネットワークサーバの中から、特定の第１のネットワークサーバを選択し、そのサーバ識別子を前記クライアントに返信する手段と、
ある第１のネットワークサーバから、ある情報識別子に関する、第２のネットワークサーバの割り当て要求を受けたら、前記複数の第２のネットワークサーバの中から、特定の第２のネットワークサーバを選択し、そのサーバ識別子を前記第１のネットワークサーバに返信する手段と
を有することを特徴とすることを特徴とするコントローラネットワークサーバ。
【請求項１８】
前記特定の第１及び第２のネットワークサーバのサーバ識別子、及び、配信される情報の情報識別子を保存するサブスクリプションデータベースを有することを特徴とする請求項１７記載のコントローラネットワークサーバ。
【請求項１９】
ネットワークサーバと所定のメッセージを交換してネットワークサーバの負荷および障害状況を監視する手段と
前記状況を記憶する手段とを有し、
第１のネットワークサーバの選択は複数の第１のネットワークサーバの負荷および障害状況に基づいて行い、第２のネットワークサーバの選択は複数の第２のネットワークサーバの負荷および障害状況に基づいて行うことを特徴とする請求項１７又は１８記載のコントローラネットワークサーバ。
【請求項２０】
第１のネットワークサーバは、各クライアントにユーザが登録した情報識別子毎に割り当てられるのではなく、クライアント毎に割り当てられることを特徴とする請求項９、１０、又は１１の何れか１項に記載のコンテンツ配信ネットワーク。
【請求項２１】
前記複数の第１のネットワークサーバは、新たに更新された情報を指定されたクライアントに配信したデータの総量もしくは配信回数の総和を所定の期間に測定する機能を有し、測定結果を課金情報としてネットワーク全体で集計する手段を有する請求項９、１０、１１、又は２０の何れか１項に記載のコンテンツ配信ネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般にデータネットワークに関し、より詳細には、更新される情報をコンテンツ発行者から登録したユーザ、クライアント等のサブスクライバーに配信する際の負荷分散を達成するための方法およびシステムに関する。尚、本明細書では、コンテンツ発行者装置、クライアント装置を単に、コンテンツ発行者、クライアントと略称して用いるものとする。
【背景技術】
【０００２】
従来のインターネットウェブコンテンツの配信モデルでは、ユーザからウェブサーバ（即ちウェブサイト）に対してリクエストを送信して、当該ウェブサーバに保存されている特定のコンテンツを要求する。ユーザからのリクエストは、クライアントコンピュータ上で動作するウェブ閲覧ソフトウェア（マイクロソフト社のインターネット・エクスプローラ等）を介して送信される。要求されたコンテンツがウェブサーバからクライアントコンピュータに配信され、閲覧ソフトを介してクライアントコンピュータ上に表示される。クライアントコンピュータとウェブサイト間の通信は、周知のＨＴＴＰ（ハイパーテキスト・トランスファー・プロトコル）を用いて行うことができる。このリクエスト／配信モデルは、インターネットを介するデータ通信の分野で周知となっている。
ニュースサイト等ウェブサイトの多くは、その内容が常に更新されている。そのため、上述のような従来の配信モデルでは２つの問題が生じる。第１の問題点は、ウェブサイトでコンテンツや情報の更新が行われたことをユーザ側では知り得ない、という点である。そのため、ユーザはいつウェブサイトにリクエストを送信して、更新されたコンテンツを要求すれば良いのか分からない。そのため、（１）情報が更新されていないのにユーザから不必要に多くのリクエストが送信される、あるいは（２）情報が更新されているのにユーザからリクエストが送信されないため、更新された情報を入手できない、と言った結果になる。従来のウェブ配信モデルに関する第２の問題点は、そのウェブサイトのコンテンツがユーザにとって興味のあるものかどうか、コンテンツ全体をダウンロードし終わるまで分からない、という点にある。このため、ユーザにとって興味のない大量のコンテンツをダウンロードした場合、ネットワーク資源（通信回線やサーバ処理など）が浪費されることになる。
このような問題点を解決するものとして、ＲＳＳ（Ｒｅａｌ  Ｓｉｍｐｌｅ  Ｓｙｎｄｉｃａｔｉｏｎ）を用いたメタデータ配信によるウェブ配信モデル（以下、ＲＳＳモデルともいう）が提案されている。ＲＳＳモデルでは、図１に示すように、ユーザは発行者のウェブサイトの維持する情報チャネルにサブスクライブし、そのクライアントコンピュータは「アグリゲータ」と呼ばれるソフトウェアを実行する。ここで、以下サブスクライブとは、継続的にそのチャネルにアクセスするよう登録することをさす。発行ウェブサイト１０２は、配信可能になり次第新しいコンテンツ１０６を追加する。ウェブサイトは、コンテンツの項目ごとに、新規追加のコンテンツ項目へのリンクと、その項目についての短い説明（メタコンテンツ）１０４を一緒に保存する。メタコンテンツはＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）文書の形式をとるのが一般的である。ＸＭＬはタグおよび該タグと関連付けた数値を用いて電子文書を記述する言語として周知である。より具体的には、ＸＭＬは実際にはメタ言語、すなわち他の言語を記述する言語であり、様々な形式の文書に関してカスタマイズされた記述言語の設計を可能にする。ＸＭＬを使用すると、どんな構造の情報でも保存することができ、また情報を同封または封入することにより、通常では通信不可能なコンピュータ・システム間で情報をやり取りすることが可能になる。ＸＭＬについては、非特許文献１（“Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＸＭＬ）１．０（Ｔｈｉｒｄ  Ｅｄｉｔｉｏｎ）”，Ｗ３Ｃ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ  ０４  Ｆｅｂｒｕａｒｙ  ２００４，Ｆ．Ｙｅｒｇｅａｕ，Ｔ．Ｂｒａｙ，Ｊ．Ｐａｏｌｉ，Ｃ．Ｍ．Ｓｐｅｒｂｅｒｇ−ＭｃＱｕｅｅｎ，Ｅ．Ｍａｌｅｒ，２００４  Ｗ３Ｃ））において、より詳細に記述されており、その内容を本明細書に援用するものとする。これらの短い説明書き（メタコンテンツ）１０４および追加コンテンツ１０６へのリンクは発行者で保存され、ＲＳＳファイルと呼ばれる。
クライアントが利用しているアグリゲータ１０８は、クライアントがアグリゲータ上でサブスクライブしたチャネルに基づき、発行者ウェブサーバ１０２に周期的に更新リクエスト１１０を送信し、発行者はＲＳＳ更新１１２により新バージョンのＲＳＳファイルを返送する。このＲＳＳファイルはＲＳＳフィードと呼ばれることもある。次に、アグリゲータ１０８は新規追加されたコンテンツ項目に関する短い説明文をユーザに対して表示する。ユーザはこの短い説明文を見て、新規コンテンツ項目の中にコンテンツ全体が欲しいものがあれば、コンテンツ・リクエスト１１４によってウェブサーバに全コンテンツを要求する。それに対する応答として、発行者は全コンテンツ１１６を送信する。
上記ＲＳＳモデルは、上述した従来のウェブコンテンツ配信モデルの抱える問題のいくつかを解決しているとは言え、まだ問題を残している。その主なものとして、ＲＳＳモデルの利用者が増加するにつれて、コンテンツ発行者のウェブサーバもしくはそれにつながるアクセス回線への負荷が大きくなるということがある。何百万というクライアントが特定のＲＳＳ情報チャネルにサブスクライブする場合は、これら巨大数のクライアントがコンテンツ発行者に対して周期的に新しいＲＳＳファイルを要求することになる。しかしながら、こうして加わる大量の負荷を拡張性高く扱う方法は現状ではない。
ウェブサーバへの負荷を軽減する従来の方法としては、特許文献１（Ｕｎｉｔｅｄ  Ｓｔａｔｅｓ  Ｐａｔｅｎｔ  Ｎｏ．６，１０８，７０３）に、クライアントがウェブサーバに直接アクセスすることなく、インターネット上に地理的に分散配置されたプロキシキャッシュサーバを介在させることが記述されている。すなわち、ここでは、ウェブサイトにアクセスしようとするクライアントの要求を自動的に最も適切なプロキシキャッシュサーバに誘導し、そのプロキシキャッシュサーバにクライアントの要求したコンテンツがキャッシュされている場合は、それを以ってクライアントの要求に応答する。キャッシュされていない場合は、そのプロキシキャッシュサーバがさらにウェブサーバにコンテンツの要求を行い、その応答としてコンテンツを取得すると、それをキャッシュすると共にさらにその取得したコンテンツを以ってクライアントに応答する。ここでキャッシュとは、コンテンツのコピーを一時的に保持することを指し、記憶容量が不足する、あるいはコンテンツの有効期限が過ぎた等の要因により、そのコピーが削除される場合があることを示唆するものである。なお、クライアントがアクセス下場合、たとえキャッシュされたコンテンツがあっても、その有効期限が過ぎている場合はプロキシーキャッシュサーバがウェブサーバにアクセスする。そして、新たなコンテンツを取得した場合は、それを以って古いコピーに対して上書きする。
しかし、このコンテンツ配信方法では、比較的頻繁に更新されるコンテンツを配信するのに適切なものとは言えない。すなわちプロキシキャッシュサーバが、取得したコンテンツの有効期間が過ぎるまでは新たにコンテンツを取得するためにウェブサイトへアクセスしない場合は、更新されたコンテンツを直ちにクライアントに配信することがいつもできるとは限らないという問題がある。また、これを解決するために、プロキシキャッシュサーバが今度は自ら比較的短い周期でウェブサイトにアクセスする場合、そのウェブサイトを収容しているウェブサーバは、同一のウェブサイトにアクセスしようとした複数のクライアントがそれぞれ誘導された先のプロキシキャッシュサーバの全てから上記の比較的短い周期でアクセスされるので、その上記のようなプロキシキャッシュサーバの数が多いほど、また上記周期が短いほどウェブサイトの負荷を低減する効果がなくなるという問題が生じる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
本発明は、多数のクライアントがあらかじめサブスクライブしたコンテンツ発行者から、内容が更新される情報を同時に獲得しようとしても、コンテンツ発行者に大きな負荷をかけることがなく、かつ、更新後でより速やかに更新されたコンテンツをクライアントに提供する改良された方法およびネットワークを提供することにある。
【課題を解決するための手段】
【０００４】
本発明の第１の態様によれば、
内容が更新される情報に興味があるクライアントが指定する情報識別子によって識別される前記情報を、データネットワークを介して前記クライアントに提供する方法であって、
複数の第１ネットワークサーバの各々に、複数の情報識別子を保存するステップと、
複数の第２ネットワークサーバの各々に、複数の情報識別子およびこれら複数の情報識別子に関連付けされた第１ネットワークサーバを保存するステップと、
前記複数の第２ネットワークサーバにおいて複数のコンテンツ発行者から情報を受信信号として受信するステップと、
前記複数の第２ネットワークサーバの各々が前記受信情報を、該受信情報のための情報識別子に関連付けされた第１ネットワークサーバに送信するステップとを含むことを特徴とする方法が得られる。
本発明の第２の態様によれば、
前記内容が更新される情報はメタコンテンツを含むものであることを特徴とする第１の態様に記載の方法が得られる。
本発明の第３の態様によれば、
前記内容が更新される情報は関連するコンテンツを得るためのリンクをも含むものであることを特徴とする第２の態様に記載の方法が得られる。
本発明の第４の態様によれば、
コントローラネットワークサーバに負荷情報、もしくは障害情報を保存するステップをさらに含むことを特徴とする、第１の態様に記載の方法が得られる。
本発明の第５の態様によれば、
コントローラネットワークサーバが前記第１ネットワークサーバの１つから、情報識別子に関連するサービスを前記第１ネットワークサーバに対して行うように、前記第２ネットワークサーバの１つを割当てるという要求を、受け取るステップをさらに含むことを特徴とする、第１の態様に記載の方法が得られる。
本発明の第６の態様によれば、
前記情報識別子に関連するサービスを前記第１ネットワークサーバに対して行うように、前記第２ネットワークサーバの１つを割当てるステップをさらに含むことを特徴とする、第５の態様に記載の方法が得られる。
本発明の第７の態様によれば、
コントローラネットワークサーバがクライアントから、情報識別子に関連するサービスをクライアントに対して行うように、前記第１ネットワークサーバの１つを割当てるという要求を、受け取るステップをさらに含むことを特徴とする、第１の態様に記載の方法が得られる。
本発明の第８の態様によれば、
前記情報識別子に関連するサービスを前記クライアントに対して行うように、前記第１ネットワークサーバの１つを割当てるステップをさらに含むことを特徴とする、第７の態様に記載の方法が得られる。
本発明の第９の態様によれば、
複数のコンテンツ発行者から複数のクライアントへ更新された情報を配信するためのコンテンツ配信ネットワークであって、
前記複数のクライアントと通信する複数の第１ネットワークサーバであって、各々が複数の情報識別子を保存する複数の第１ネットワークサーバと、
コンテンツ発行者と通信して更新された情報を受信更新情報として受信する複数の第２ネットワークサーバであって、各々が複数の情報識別子およびこれら複数の情報識別子に関連付けされた第１ネットワークサーバを保存する複数の第２ネットワークサーバとを備え、
前記第２ネットワークサーバの各々は、前記受信更新情報のための情報識別子に関連付けされた少なくとも１つの第１ネットワークサーバに前記受信更新情報を送信するように構成されていることを特徴とするコンテンツ配信ネットワークが得られる。
本発明の第１０の態様によれば、
複数の特定の情報識別子に関連するサービスを複数のクライアントに対して行うように、前記第１ネットワークサーバの複数を割当てるコントローラネットワークサーバをさらに含むことを特徴とする、第９の態様に記載のコンテンツ配信ネットワークがえられる。
本発明の第１１の態様によれば、
複数の特定の情報識別子に関連するサービスを前記第１ネットワークサーバの複数に対して行うように、前記第２ネットワークサーバの複数を割当てるコントローラネットワークサーバをさらに含むことを特徴とする、第９の態様に記載のコンテンツ配信ネットワークが得られる。
本発明の第１２の態様によれば、
負荷情報もしくは障害情報を保存するコントローラネットワークサーバをさらに含むことを特徴とする、第９の態様に記載のコンテンツ配信ネットワークが得られる。
本発明の第１３の態様によれば、
データネットワークにおいて、更新される情報に興味のあるクライアントに前記情報を提供する方法であって、
特定の情報に関して前記クライアントの各々が複数の第１ネットワークサーバの１つに割当てられ、
特定の情報に関して前記第１ネットワークサーバの各々が複数の第２ネットワークサーバの１つに割当てられている前記方法において、
前記複数の第２ネットワークサーバが複数のコンテンツ発行者から更新された情報を受信更新情報として受信するステップと、
前記複数の第２ネットワークサーバが、前記受信更新情報に関して該複数の第２ネットワークサーバに割当てられている第１ネットワークサーバに前記受信更新情報を送信するステップと、
前記第１ネットワークサーバが、前記受信更新情報に関して該第１ネットワークサーバに割当てられているクライアントに前記受信更新情報を送信するステップを含むことを特徴とする方法が得られる。
本発明の第１４の態様によれば、
前記複数の第２ネットワークサーバに、複数の情報識別子およびこれら複数の情報識別子に関連付けされた第１ネットワークサーバを保存するステップをさらに含むことを特徴とする、第１３の態様記載の方法が得られる。
本発明の第１５の態様によれば、
コントローラネットワークサーバが、特定の情報に関して前記第１ネットワークサーバに前記クライアントを割当てるステップをさらに含むことを特徴とする、第１３の態様に記載の方法が得られる。
本発明の第１６の態様によれば、
コントローラネットワークサーバが、特定の情報に関して前記第２ネットワークサーバに前記第１ネットワークサーバを割当てるステップをさらに含むことを特徴とする、第１３の態様に記載の方法が得られる。
本発明の第１７の態様によれば、
更新される情報に興味があるクライアントに前記情報を提供するためのネットワークであって、
複数の第１ネットワークサーバと、複数の第２ネットワークサーバと、コントローラネットワークサーバとを備え、
前記複数の第１ネットワークサーバの各々は、特定の情報に関連するサービスを複数のクライアントに対して行うように割当てられており、
前記複数の第２ネットワークサーバの各々は、特定の情報に関連するサービスを前記複数の第１ネットワークサーバのいくつかに対して行うように割当てられており、
前記コントローラネットワークサーバは、前記複数の第１ネットワークサーバ及び前記複数の第２ネットワークサーバの割当てを記憶するメモリを備えていることを特徴とするネットワークが得られる。
本発明の第１８の態様によれば、
前記複数の第１ネットワークサーバの各々は、情報識別子を記憶するメモリを備えていることを特徴とする、第１７の態様に記載のネットワ−クが得られる。
本発明の第１９の態様によれば、
前記複数の第２ネットワークサーバの各々は、情報識別子を記憶するメモリを備えていることを特徴とする、第１７の態様に記載のネットワ−クが得られる。
本発明の第２０の態様によれば、
前記複数の第２ネットワークサーバの各々に備えられるメモリは、該メモリに記憶された情報識別子に関連するサービスを特定の第１ネットワークサーバに対して行うように前記第２ネットワークサーバを割当てるべく、前記特定の第１ネットワークサーバの識別子をも記憶していることを特徴とする、第１９の態様に記載のネットワ−クが得られる。
本発明の第２１の態様によれば、
前記コントローラネットワークサーバのメモリは、前記ネットワーク、もしくは前記複数の第１ネットワークサーバ及び前記複数の第２ネットワークサーバの負荷情報もしくは障害情報をさらに記憶していることを特徴とする、第１７の態様に記載のネットワ−クが得られる。
本発明の第２２の態様によれば、
複数のコンテンツ発行者から複数のクライアントへ更新された情報を配信するためのコンテンツ配信ネットワークであって、
前記複数のクライアントからのアクセスに対し、更新された情報の転送を行う複数の第１のネットワークサーバと、コンテンツ発行者にアクセスして更新された情報を取得する複数の第２のネットワークサーバとを含み、
前記複数の第２のネットワークサーバの各々は、ある第１のネットワークサーバからある情報識別子に関するサブスクライブリクエストを始めて受信したら、それ以降、前記情報識別子に対応するコンテンツ発行者から更新された情報を取得した際は、これを前記第１のネットワークサーバに転送することを特徴とするコンテンツ配信ネットワークが得られる。
本発明の第２３の態様によれば、
第２２の態様に記載のコンテンツ配信ネットワークにおいて、
コントローラネットワークサーバを更に含み、
前記複数の第１のネットワークサーバの各々は、あるクライアントからある情報識別子に関するサブスクライブリクエストを始めて受信したら、前記サブスクライブリクエストを前記コントローラネットワークサーバから割り当てられた第２のネットワークサーバに転送し、ある第２のネットワークサーバからある情報識別子に関して更新された情報を転送された場合は、前記更新された情報を、少なくとも同一の情報識別子に関して、次に更新された情報を転送されるまでは保持することを特徴とするコンテンツ配信ネットワークが得られる。
本発明の第２４の態様によれば、
第２２の態様に記載のコンテンツ配信ネットワークにおいて、
コントローラネットワークサーバを更に含み、
前記複数の第１のネットワークサーバの各々は、あるクライアントからある情報識別子に関するコンテンツ要求を始めて受信したら、前記情報識別子に関するサブスクライブリクエストを前記コントローラネットワークサーバから割り当てられた第２のネットワークサーバに発信し、ある第２のネットワークサーバからある情報識別子に関して更新された情報を転送された場合は、前記更新された情報を、少なくとも同一の情報識別子に関して、次に更新された情報を転送されるまでは保持することを特徴とするコンテンツ配信ネットワークが得られる。
本発明の第２５の態様によれば、
複数のコンテンツ発行者から複数のクライアントへ更新される情報を配信する際に使用されるコンテンツ発行者側ネットワークサーバにおいて、
前記情報に関する情報識別子と、それに関して、前記コンテンツ発行者側ネットワークサーバに割り当てられているクライアント側ネットワークサーバのサーバ識別子とを保存するサブスクリプションテーブルを備え、
前記クライアント側ネットワークサーバからサブスクライブリクエストを受信した際、そこに含まれる情報識別子が前記サブスクリプションテーブルに保存されていない場合は、前記情報識別子を前記テーブルに登録し、
前記サブスクリプションテーブル上に保持された情報識別子で指定されるおのおののコンテンツ発行者から更新された情報を受信した場合は、前記サブスクリプションテーブルを参照して、前記更新された情報に関する情報識別子に対応する全てのクライアント側ネットワークサーバに、前記更新された情報を転送することを特徴とするコンテンツ発行者側ネットワークサーバが得られる。
本発明の第２６の態様によれば、
複数のコンテンツ発行者から複数のクライアントへ更新された情報を配信する際に使用されるクライアント側ネットワークサーバにおいて、
前記情報に関する情報識別子を保存するサブスクリプションテーブルと、コンテンツ発行者ネットワークサーバから受信した前記情報を保存する手段とを備え、
あるコンテンツ発行者側ネットワークサーバからある情報識別子に関して新たに更新された情報を転送された場合は、前記更新された情報を、すくなくとも次に前記情報識別子と同一のものに関して更新された情報を転送されるまでは保持し、
前記情報識別子に関するクライアントからのアクセスに対して、前記保存する手段で保存された前記情報識別子に関する前記更新された情報を前記クライアントに送信することを特徴とするクライアント側ネットワークサーバが得られる。
本発明の第２７の態様によれば、
前記複数のクライアントの一つからある情報識別子に対する情報のアクセス要求を始めて受信した場合は、前記情報識別子に関するサブスクライブリクエストを生成して、これを、コントローラネットワークサーバから割り当てられたコンテンツ発行者側ネットワークサーバに送信することを特徴とする第２６の態様に記載のクライアント側ネットワークサーバが得られる。
本発明の第２８の態様によれば、
第２６の態様に記載のクライアント側ネットワークサーバにおいて、前記複数のクライアントの一つからある情報識別子関するサブスクライブリクエストを始めて受信した場合は、自らを要求者とするサブスクライブリクエストを、コントローラネットワークサーバから割り当てられたコンテンツ発行者側ネットワークサーバに転送することを特徴とするクライアント側ネットワークサーバが得られる。
本発明の第２９の態様によれば、
関心をもつ更新された情報の配信を受けるクライアントにおいて、当該クライアントが配信を要求する情報に関する情報識別子及び割り当てられたクライアント側ネットワークサーバのサーバ識別子を登録するサブスクリプションテーブルを備え、
当該クライアントのユーザによって新たに情報識別子が前記サブスクリプションテーブルに登録されたら、前記情報識別子に関して、コントローラネットワークサーバからクライアント側ネットワークサーバの割り当てを要求する手段と、
前記クライアント側ネットワークサーバの割り当てを受けたら、そのサーバ識別子を関連する前記情報識別子に対して前記サブスクリプションテーブルに登録し、サブスクライブリクエストを前記クライアント側ネットワークサーバに送出する手段と、
前記割り当てられたクライアント側ネットワークサーバに対して、更新される情報を取得するために周期的にアクセスする手段とを有していることを特徴とするクライアントが得られる。
本発明の第３０の態様によれば、
更新される情報に関心を持つ複数のクライアントと通信して更新される情報を前記クライアントに配信する複数の第１のネットワークサーバと、コンテンツ発行者と通信して更新される情報の取得を行う複数の第２のネットワークサーバとを含むコンテンツ配信ネットワークにおいて使用されるコントローラネットワークサーバであって、
あるクライアントからある情報識別子に関する、第１のネットワークサーバの割り当て要求を受けたら、前記複数の第１のネットワークサーバの中から、特定の第１のネットワークサーバを選択し、そのサーバ識別子を前記クライアントに返信する手段と、
ある第１のネットワークサーバから、ある情報識別子に関する、第２のネットワークサーバの割り当て要求を受けたら、前記複数の第２のネットワークサーバの中から、特定の第２のネットワークサーバを選択し、そのサーバ識別子を前記第１のネットワークサーバに返信する手段と
を有することを特徴とすることを特徴とするコントローラーネットワークサーバが得られる。
本発明の第３１の態様によれば、
前記特定の第１及び第２のネットワークサーバのサーバ識別子、及び、配信される情報の情報識別子を保存するサブスクリプションデータベースを有することを特徴とする第３０の態様に記載のコントローラネットワークサーバが得られる。
本発明の第３２の態様によれば、
ネットワークサーバと所定のメッセージを交換してネットワークサーバの負荷および障害状況を監視する手段と
前記状況を記憶する手段とを有し、
第１のネットワークサーバの選択は複数の第１のネットワークサーバの負荷および障害状況に基づいて行い、第２のネットワークサーバの選択は複数の第２のネットワークサーバの負荷および障害状況に基づいて行うことを特徴とする第３０、および３１の態様のいずれかに記載のコントローラネットワークサーバが得られる。
本発明の第３３の態様によれば、
第１のネットワークサーバは、各クライアントにユーザが登録した情報識別子毎に割り当てられるのではなく、クライアント毎に割り当てられることを特徴とする第９，１０，１１，１２、２２、２３の態様のいずれかに記載のコンテンツ配信ネットワークおよび第１７、１８，１９，２０、２１の態様のいずれかに記載のネットワークが得られる。
本発明の第３４の態様によれば、
前記複数の第１のネットワークサーバは、新たに更新された情報を指定されたクライアントに配信したデータの総量もしくは配信回数の総和を所定の期間に測定する機能を有し、測定結果を課金情報としてネットワーク全体で集計する手段を有する第９，１０，１１、１２、２２、２３、３３の態様のいずれかに記載のコンテンツ配信ネットワークおよび第１７、１８、１９、２０、２１、３３の態様のいずれかに記載のネットワークが得られる。
【発明の効果】
【０００５】
本発明に従えば、多数のクライアントがあらかじめサブスクライブしたコンテンツ発行者から、内容が更新される情報を同時に獲得しようとしても、コンテンツ発行者に大きな負荷をかけることがない改良された方法およびネットワークを得ることができる。
【図面の簡単な説明】
【０００６】
図１はネットワークコンテンツ配信におけるＲＳＳモデルを示す図である。
図２は本発明の一実施例によるネットワーク・アーキテクチャを示す図である。
図３は図２に示した実施例による動作シナリオを説明するための図である。
図４は本発明の別の実施例によるネットワーク・アーキテクチャを示す図である。
図５は図２及び図４の実施例におけるネットワーク・ノードを実施するために使用し得るコンピュータのハイレベル・ブロック図である。
【符号の説明】
【０００７】
１０２    ウェブサーバ
１０４    ＲＳＳメタコンテンツ（ＸＭＬ）
１０６    コンテンツ
１０８    アグリゲータ
１１０    更新リクエスト
１１２    ＲＳＳ更新
１１４    コンテンツ・リクエスト
１１６    コンテンツ
２２６    ネットワーク
２２８    第１ＦＰＳ
２３２    第２ＦＰＳ
２３６    第３ＦＰＳ
２４０    第１ＲＰＳ
２４４    第２ＲＰＳ
２４８    コンテンツ発行者Ａ
２５０    コンテンツ発行者Ｃ
２５２    コンテンツ発行者Ｂ
２５４    マップサーバ
【発明を実施するための最良の形態】
【０００８】
次に本発明の実施例について図面を参照して説明する。
本発明によるネットワーク・アーキテクチャは２種類のエッジサーバを備えるが、ここではこれらをそれぞれフォーワード・プロキシサーバ（ＦＰＳ）とリバース・プロキシサーバ（ＲＰＳ）と呼ぶ。ＦＰＳは特定の情報に関するサービスを特定のクライアントに対して行うように割当てられ、ＲＰＳは特定の情報に関するサービスを特定のＦＰＳに対して行うように割当てられる。本発明の好適な実施例においては、ＦＰＳはネットワークのクライアント側エッジに配置され、ＲＰＳはネットワークのコンテンツ発行者側エッジに配置される。
本発明の一実施例においては、おのおののＦＰＳは、ある更新される情報を少なくとも１つのクライアントに配信するサービスをすべくそのクライアントに割当てられ、その際、前記の更新される情報の識別子を保存する。また、おのおのＲＰＳは、ある更新される情報をＦＰＳに配信するサービスをすべくＦＰＳに割り当てられ、その際、前記の更新される情報の識別子と前記ＦＰＳの識別子を保持する。
更新されたコンテンツを受信すると、ＲＰＳは、受信した更新されたコンテンツに関するサービスを行う対象としてのＦＰＳに対して、更新されたコンテンツを送信する。次に、ＦＰＳは、更新されたコンテンツに関するサービスを行う対象としてのクライアントに対して更新されたコンテンツを提供する。この場合、クライアントからのリクエストに応答する形で送信する場合と、クライアントに対して情報をプッシュ（強制送信）する場合がある。
好適な実施例では、ＦＰＳに対するクライアントの割当て、およびＲＰＳに対するＦＰＳの割当てを制御するマップサーバにより負荷分散が行われる。マップサーバはデータベースにこれらの割り当てを保持して本システムの負荷分散のポリシーを実行する。
当業者であれば、以下の詳細な説明と添付図面を参照することにより、本発明の上記以外の利点についても明らかとなろう。
図２は本発明の一実施例によるネットワーク・アーキテクチャの概略を示す図である。４台のクライアント（第１クライアント２０２、第２クライアント２０８、第３クライアント２１４、第４クライアント２２０）が示されており、クライアントがアグリゲータ（例えばＲＳＳアグリゲータ）のアプリケーション・プログラム２０４，２１０，２１６，２２２をそれぞれ実行している。クライアントを構成する装置は、アグリゲータ・アプリケーション・プログラムを実行でき、かつネットワークを介して通信可能なものであれば、どのような形式の装置でも良い。例えば、当技術分野で周知のように、アグリゲータをアプリケーション・プログラムとして実行する汎用コンピュータとすることができる。クライアントとネットワーク２２６との接続は、モデム・ダイアルアップ、ケーブル・モデム、ＤＳＬ（Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）、Ｗｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ  Ｆｉｄｅｌｉｔｙ）ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等、周知の各種接続技術を用いて行うことができる。また、クライアントとして、アグリゲータ・アプリケーション・プログラムを実行し、かつ無線ネットワークを介して通信可能な無線電話等を用いることもできる。当業者であれば、ここに挙げた他にも、アグリゲータ・アプリケーション・プログラムを実行し、かつネットワークを介して通信可能な装置がいろいろと存在することは理解できるであろう。
ネットワーク２２６は、インターネット等、どのような種類のデータネットワークでも良い。図示を容易にするために、ネットワーク２２６を単一のネットワークの雲として示しているが、ネットワーク２２６は１つ以上のネットワークを相互接続したものとしても良い。当業者には明らかなように、ネットワーク２２６の各種ノードは周知のデータネットワークの通信リンクおよび技術を用いて相互に通信する。図２において各ノードを結んでいる線は論理的関係を表したものであるが、これについては以下の説明より明らかとなろう。
図２には、Ａに関する情報を発行する発行者２４８、Ｃに関する情報を発行する発行者２５０、Ｂに関する情報を発行する発行者２５２の３つの発行者も示されている。発行者２４８，２５０，２５２は当技術分野で周知のとおり、ウェブサーバとして実施することができる。好適な実施例では、発行者２４８，２５０，２５２が上記のようなＲＳＳモデルを用いてコンテンツの発行を行う。従来技術では、上述のように、クライアント２０２，２０８，２１４，２２０が情報Ａ，Ｂ，Ｃに関する更新されたコンテンツを受信しようとした場合、個々のクライアントが発行者２４８，２５０，２５２に対して直接にリクエストを送信する必要があった。多くのクライアントと多くの発行者を抱える典型的なネットワークでは、拡張性に関して重大な問題が生じ、ウェブサーバやアクセス回線が過負荷となり、輻輳する結果となる。本発明は新規なネットワーク・アーキテクチャを用いてこの問題を解決する。
本発明の一実施例によるネットワーク・アーキテクチャは、フォーワード・プロキシサーバ（ＦＰＳ）とリバース・プロキシサーバ（ＲＰＳ）と呼ばれる二種類のエッジ・プロキシサーバを備える。図２に示す例では、第１ＦＰＳ２２８、第２ＦＰＳ２３２、第３ＦＰＳ２３６の３台のＦＰＳを備える。ＦＰＳはクライアントに最も近いネットワーク・エッジに配置されており、クライアントに所望の情報を提供するために使用される。ＦＰＳは、特定の情報（例えば特定のＲＳＳ情報チャネルやＲＳＳフィード）に関して、その情報が発行者から入手可能となった時点で複数のクライアントの各々に更新された情報を提供する働きをする。ＲＰＳはネットワークの他方のエッジ、すなわち発行者に最も近いエッジに配置されるものである。図では第１ＲＰＳ２４０と第２ＲＰＳ２４４の２つが設けられている。ＲＰＳは発行者からＦＰＳに対してデータ（例えばＲＳＳデータファイル）をプッシュするのに使用される。ＦＰＳとＲＰＳの動作は、マップサーバ２５４によって調整される。マップサーバ２５４はＩＰネーム解決、複数のＦＰＳおよびＲＰＳの上で負荷分散を行うこと、およびＦＰＳとＲＰＳの障害対処などの働きをする。ＦＰＳとＲＰＳとが連携することで、発行者からクライアントへ情報を提供するのに効果的なネットワーク・アーキテクチャが実現される。本明細書において、ＦＰＳは第１ネットワークサーバとも呼ばれ、ＲＰＳは第２ネットワークサーバとも呼ばれ、マップサーバはコントローラネットワークサーバとも呼ばれる。
次に、図２を参照して、クライアント、ＦＰＳ、ＲＰＳ、発行者の間の相互関係について説明する。ここでは、これら構成体の中に一定の構成のデータテーブルが保存されていることを前提とするが、ここではデータテーブルの構成手順に関する説明は行わない。これらのデータテーブルの構成手順に関する詳細な説明は、後に図３に関連して行うこととする。
まずクライアントに関して述べると、各々のクライアントのアグリゲータ・アプリケーション・プログラムは、特定のクライアントがサブスクライブしている情報チャネルと対応するＦＰＳの一覧表を保存している。例えば、第１クライアント２０２は、サブスクリプションテーブル２０６に示されるようにチャネルＡとＢにサブスクライブしており、第２クライアント２０８は、サブスクリプションテーブル２１２に示されるようにチャネルＢとＣにサブスクライブしており、第３クライアント２１４は、サブスクリプションテーブル２１８に示されるようにチャネルＣにサブスクライブしており、第４クライアント２２０は、サブスクリプションテーブル２２４に示されるようにチャネルＢにサブスクライブしている。クライアントがサブスクライブしている各チャネルは、特定のクライアントが様々な発行者から受信したいと考えている情報（例えばＲＳＳファイル）を示すものである。
本発明の一態様によると、クライアントの各々は特定の情報チャネルに関して１つのＦＰＳに割当てられる。例えば、図２では、第１クライアント２０２は、線２５５と２５６で表されるように、情報チャネルＡとＢの両方に関して第１ＦＰＳ２２８に割当てられている。第２クライアント２０８は、線２５８で表されるように情報チャネルＢに関して第１ＦＰＳ２２８に割当てられると共に、線２６０で表されるように情報チャネルＣに関して第２ＦＰＳ２３２に割当てられている。第３クライアント２１４は、線２６２で表されるように情報チャネルＣに関して第２ＦＰＳ２３２に割当てられている。第４クライアント２２０は、線２６４で表されるように情報チャネルＢに関して第３ＦＰＳ２３６に割当てられている。図２に示すように、情報チャネルは同じでも、クライアントに割当てられるＦＰＳは異なるものになる場合がある。例えば、第１ＦＰＳ２２８は情報チャネルＢに関するサービスを第１クライアント２０２に対して行うが、第３ＦＰＳ２３６は情報チャネルＢに関するサービスを第４クライアント２２０に対して行う。このことは、例えば第１クライアント２０２と第４クライアント２２０が地理的に遠く離れており、１台のエッジサーバを共有するのが難しい場合などに有効である。また、特定のチャネルに対して多数のユーザが偏る場合などに、その負荷を複数のＦＰＳ上に分散するのに有効である。
尚、図示された接続関係は、メタコンテンツ配信の場合における接続関係を示しており、コンテンツ全体を取得する場合には、別の接続経路を通して、配信が行われても良い。
ＦＰＳの各々は、該ＦＰＳに少なくとも１つのクライアントが或る情報に関して割当てられている場合、その或る情報の情報識別子を含むサブスクリプションテーブルを保存している。例えば、第１ＦＰＳ２２８には、情報チャネルＡとＢの両方にサブスクライブしているクライアントが割当てられているため、第１ＦＰＳ２２８は、情報チャネルＡとＢを識別する情報識別子を含むサブスクリプションテーブル２３０を備えている。第２ＦＰＳ２３２には情報チャネルＣにサブスクライブしているクライアントが割当てられているため、第２ＦＰＳ２３２は、情報チャネルＣを識別する情報識別子を含むサブスクリプションテーブル２３４を備えている。第３ＦＰＳ２３６には、情報チャネルＢにサブスクライブしているクライアントが割当てられているため、第３ＦＰＳ２３６は、情報チャネルＢを識別する情報識別子を含むサブスクリプションテーブル２３８を備えている。なお、各ＦＰＳは特定チャネルに関して該ＦＰＳに割当てられているクライアントが複数であっても、そのサブスクリプションテーブルへの記入項目は１つしかない。例えば、第１ＦＰＳ２２８の場合、第１クライアント２０２と第２クライアント２０８が情報チャネルＢに関して第１ＦＰＳ２２８に割当てられているが、サブスクリプションテーブル２３０の情報チャネルＢへの記入項目は１つしかない。これは、ＲＰＳからＦＰＳに到着した情報は、アグリゲータのほうから、サブスクライブしたＦＰＳにアクセスして取得するので、ＦＰＳはどのチャネルはどのクライアントに情報を転送すべきかを保持している必要はないからである。なお、ここで、本発明の説明のために使用する「情報チャネル」という用語は、ＲＳＳデータ配信モデルの用語に合わせたものである。本発明の原理を実施する上で有利な形態の一つがＲＳＳモデルであることも事実であるが、本発明がいかなる種類のデータネットワーク情報配信システムにも適用可能であることは言うまでもない。従って、クライアントが受信を希望する情報の種類によっては、その情報の識別に使用される識別子の説明を行う際に、情報チャネルという用語より情報識別子という用語を用いた方がより広い意味での説明となる場合もあろう。本明細書では、ＲＳＳの用語に合わせて情報チャネルという用語を使用するが、本発明がＲＳＳの例に限定されるものでないことは当然である。
ＦＰＳに保存されているチャネルサブスクリプションの各々が、ネットワークの発行者側エッジにあるＲＰＳに割当てられており、この割り当てはＲＰＳのサブスクリプションテーブルに保存される。例えば、線２６４で表されるように、第１ＦＰＳ２２８のサブスクリプションチャネルＡは第１ＲＰＳ２４０に割当てられており、この割当てがＲＰＳサブスクリプションテーブル２４２に保存される。このサブスクリプションテーブル２４２に、第１ＲＰＳ２４０は情報チャネルＡの割当てと共に、情報チャネルＡに関連付けされた第１ＦＰＳ（の識別子）も保存する。同様に、線２６６で表されるように、第１ＦＰＳ２２８のサブスクリプションチャネルＢは第２ＲＰＳ２４４に割当てられており、この割当てがＲＰＳサブスクリプションテーブル２４６に保存される。このサブスクリプションテーブル２４６に、第２ＲＰＳ２４４は情報チャネルＢの割当てと共に、情報チャネルＢに関連付けされた第１ＦＰＳ（の識別子）も保存する。なお、第２ＲＰＳ２４４のサブスクリプションテーブル２４６に関しては、第３ＦＰＳ２３６の識別子も情報チャネルＢと関連付けされて保存されているが、これは線２７０で表されるように、情報チャネルＢに関しては第２ＲＰＳ２４４が第３ＦＰＳ２３６にも割当てられているためである。最後に、図２に線２６８で表されるように、第２ＦＰＳ２３２のサブスクリプションチャネルＣは第１ＲＰＳ２４０に割当てられており、この割当てが第１ＲＰＳサブスクリプションテーブル２４２に保存される。このサブスクリプションテーブル２４２に、第１ＲＰＳ２４０は情報チャネルＣの割当てと共に、情報チャネルＣに関連付けされた第２ＦＰＳの識別子（即ち、サーバ識別子）も保存する。
ＲＰＳはサブスクリプションテーブルに保持されているコンテンツ発行者に周期的にアクセスして（コンテンツのリクエストを送信して）、更新された情報を取得し、その情報をサブスクリプションテーブルに保持されているＦＰＳにプッシュする。この場合、更新されたコンテンツが発行されてからそれを取得するまでの遅延時間は前述の周期で与えられることがわかる。ここで同一のウェブサーバ上に複数のコンテンツ発行者がある場合は、ＲＰＳはそれぞれの発行者に連続してアクセスせずに、アクセスする間隔を一定時間以上あけてもよい。これにより、複数のコンテンツ発行者を同時に収容するウェブサーバに対する瞬間的な負荷を削減することができる。また、同一のコンテンツ発行者に対してアクセスする間隔を示す周期は、アクセスした際に、更新された情報が得られた場合は小さくし、得られなかった場合は大きくするようにしてもよい。これによっても、ウェブサーバに対する負荷を削減することができる。またＲＰＳはウェブログサイトのようにコンテンツ全体が更新された事実のみを通知する機能があるコンテンツ発行者に対しては、周期的にアクセスするのではなく、コンテンツ発行者から更新事実を通知するメッセージを受け取ったら、初めて、そのメタコンテンツ（ウェブログサイトの場合はＲＳＳファイル）を取得するためにてアクセスしてもよい。あるいは、情報が更新されたらその更新された情報をＲＰＳにプッシュする能力のあるコンテンツ発行者に対しては、その情報を当該ＲＰＳへプッシュすることをあらかじめコンテンツ発行者に登録しておけば、ＲＰＳの方からコンテンツ発行者に対してアクセスする必要もない。上記２つの場合は、コンテンツ発行者で情報が更新されてからＲＰＳがその情報を取得するまでの遅延時間は周期的にアクセスするよりも更に削減される。ＲＳＳモデルの好適な実施例によると、発行者から取得される更新された情報は、該発行者から入手可能な追加コンテンツについて説明するメタデータを含むＲＳＳファイルである。例えば、第１ＲＰＳ２４０はそのサブスクリプションテーブル２４２に情報チャネルＡとＣの２つの情報チャネルを保存している。第１ＲＰＳ２４０は発行者２４８に対して周期的に情報のリクエストを送信して、チャネルＡに関する更新された情報を取得する。更新された情報を取得すると、第１ＲＰＳ２４０は、サブスクリプションテーブル２４２に第１ＦＰＳ２２８が情報チャネルＡに関連付けされているので、この更新された情報を第１ＦＰＳ２２８にプッシュする。同様に、第１ＲＰＳ２４０は発行者２５０にも周期的に情報のリクエストを送信して、チャネルＣに関する更新された情報を取得する。更新された情報を取得すると、第１ＲＰＳ２４０は、サブスクリプションテーブル２４２に第２ＦＰＳ２３２が情報チャネルＣに関連付けされているので、この更新された情報を第２ＦＰＳ２３２にプッシュする。第２ＲＰＳ２４４はそのサブスクリプションテーブルに情報チャネルＢのみしか保存していない。第２ＲＰＳ２４４は発行者２５２に対して周期的に情報のリクエストを送信して、チャネルＢに関する更新された情報を取得する。更新された情報を取得すると、第２ＲＰＳ２４４は、サブスクリプションテーブル２４６に第１ＦＰＳと第３ＦＰＳが情報チャネルＢに関連付けされているので、この更新された情報を第２ＦＰＳ２２８と第３ＦＰＳ２３６にプッシュする。
ＲＰＳからＦＰＳにプッシュされた情報は、すくなくともＲＰＳから次に更新された情報をプッシュされるまでは、ＦＰＳに保存されたままとなる。クライアントは、特定の情報チャネルに関して割当てられたＦＰＳに対して、周期的に更新された情報を要求する。例えば、第１クライアント２０２のアグリゲータ２０４は、情報チャネルＡとＢの両方に関する更新された情報を第１ＦＰＳ２２８に対して周期的に要求する。これは、第１クライアント２０２がこれら両情報チャネルに関して第１ＦＰＳに割当てられているためである。第２クライアント２０８のアグリゲータ２１０は、情報チャネルＢに関する更新された情報を第１ＦＰＳ２２８に対して周期的に要求すると共に、情報チャネルＣに関する更新された情報を第２ＦＰＳ２３２に対して周期的に要求する。これは、第２クライアント２０８は情報チャネルＢに関して第１ＦＰＳ２２８に割当てられ、情報チャネルＣに関して第２ＦＰＳ２３２に割当てられているためである。同様に、第３クライアント２１４は、情報チャネルＣに関する更新された情報を第２ＦＰＳ２３２に対して要求し、第４クライアント２２０は情報チャネルＢに関する更新された情報を第３ＦＰＳ２３６に対して要求する。
ＲＳＳモデルの実施例では、更新された情報（すなわちＲＳＳファイル）をクライアント側で受信すると、クライアントのユーザがＲＳＳファイル内のメタデータにより識別されるコンテンツの全部を取得するかどうかを判断する。
図２に示すネットワークにはマップサーバ２５４も含まれる。マップサーバ２５４はクライアント、ＦＰＳ、ＲＰＳの動作を調整し、様々なサービスを提供することにより、これらの間の調停役としての働きをする。マップサーバ２５４はまた、下記のように負荷分散を行うと共にシステム障害への対処も行う。負荷分散については、マップサーバ２５４は特定の情報チャネルに関するクライアントへのＦＰＳ割当てを決定する。クライアントはまず特定の情報チャネルにサブスクリプションを行い、マップサーバに対してＦＰＳの割当てを要求する。マップサーバは、このＦＰＳ割当ての要求に対して、正常に動作しているＦＰＳのなかで負荷の最も小さいものを割当てると負荷分散をとる上で有利である。ただし、以下、負荷とは、サーバそのものにかかるもの、もしくはサーバがインターネットにつながるアクセス回線に加わるものをさす。同様に、マップサーバは、特定の情報チャネルに関してＲＰＳをＦＰＳに割当てる。この場合も、マップサーバは、正常に動作しているＲＰＳの中で負荷の最も小さいものを割当てると負荷分散を行う上で有利である。他に負荷分散を行う他の方法としては、ラウンドロビン割当てがある。これをおこなうために、マップサーバは上記全ての割り当てをデータベースに保存している。
マップサーバ２５４は、システム障害への対処も行う。一実施例によると、ＦＰＳ及びＲＰＳの各々は、マップサーバ２５４に対して周期的にキープアライブメッセージを送信するソフトウェア・エージェントを実行する。このキープアライブメッセージは、メッセージを送信したネットワーク・ノードが適正に機能していることを示すものである。所定の時間内に特定のノードからキープアライブメッセージを受信しなかった場合、マップサーバ２５４はそのノードが障害をおこしていると判断する。ＦＰＳもしくはＲＰＳに障害があると判断した場合、マップサーバ２５４は、クライアントへのＦＰＳの割り当て、もしくはＦＰＳへのＲＰＳの割当てをし直して、このコンテンツ配信システムが動作を継続できるようにする。
データネットワークのクライアント側エッジに配置されたＦＰＳ、およびデータネットワークの発行者側エッジに配置されたＲＰＳを使用することによって、コンテンツ配信システムを実施する上で拡張性のあるネットワーク・アーキテクチャが提供され、多数のクライアントからの更新された情報に対する要求に対処することが可能となる。更に、各ＦＰＳ、ＲＰＳ、及び、マップサーバのサブスクリプションテーブル、データベース上に保存された接続関係を示す情報識別子、サーバ識別子は、メタコンテンツの配信後も、アンサブスクライブ（登録解除）されるまで継続的に維持される。
なお、図２において、各ＦＰＳに、それぞれ更新された情報をクライアントに配信したデータ量の総和もしくは回数の総和を一定時間毎に測定する機能を持たせ、各ＦＰＳで測定された結果を、マップサーバ、あるいは別途設けられた課金サーバに送信することにより、マップサーバあるいは課金サーバが課金情報を処理するように構成しても良い。この場合、ネットワーク２２６の運用者から、一定時間内における前記複数のＦＰＳで測定された、コンテンツ発行者毎の配信データ量の総和もしくは配信データ回数等の課金情報が、コンテンツ発行者２４８，２５０，２５２のそれぞれに対して与えられることになる。
本発明により構成された図２のネットワークの動作について、またサブスクリプションおよびコンテンツ配信の手順についてさらに説明するために、図３を用いながら、動作シナリオの一例について説明することにする。
図３は、特定のＲＳＳ情報チャネルにサブスクライブしようとしているクライアント２０２を示している。ここで、クライアント２０２がサブスクライブしようとしている情報チャネルはＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）、具体的には”ＵＲＬ１”で識別されるものとする。まず、クライアント２０２のアグリゲータ２０４がマップサーバ２５４に「ＧＥＴ  ＦＰＳ」リクエスト３０６を送信する。「ＧＥＴ  ＦＰＳ」リクエストとは、リクエストのパラメータとしてクライアントから送られたＵＲＬによって特定される特定の情報チャネルに関して該クライアントにＦＰＳを割当てるようにマップサーバ２５４に要求するリクエストである。このように、クライアント２０２はマップサーバ２５４に対するリクエスト３０６として、クライアント２０２がＵＲＬ１で識別される情報チャネルにサブスクリプションを希望していることを示すＧＥＴ  ＦＰＳ（ＵＲＬ１）を送信する。マップサーバ２５４は、種々のＦＰＳに対する種々の負荷を考慮に入れて、クライアント２０２に割当てるのに適切なＦＰＳを決定する。割当てＦＰＳが決まると、マップサーバ２５４は応答メッセージ３１０で割当てＦＰＳをクライアント２０２に送信する。この例では、応答メッセージ３１０の中に、この情報チャネルに関して割当てられたＦＰＳとして第１ＦＰＳ（２２８）の識別子が含まれているものとする。
割当てられたＦＰＳを受信すると、アグリゲータ２０４は、ＵＲＬ１で識別される情報チャネルと前記割り当てられたＦＰＳの組をサブスクリプションテーブルにサブスクライブし、次にＵＲＬ１で識別される情報チャネルのサブスクリプションを要求するサブスクライブリクエスト３１４を、割当てられたＦＰＳ２２８に送信する。なお、上記の手順はクライアント２０２のユーザには見えないものとして、ユーザはアグリゲータ２０４に対して特定の情報チャネルにサブスクライブしたい旨を示すだけで良いようにしても良い。このように、アグリゲータ２０４は自動的に「ＧＥＴ  ＦＰＳ」メッセージを生成して送信し、ＦＰＳの割当てを受けると、割当てられたＦＰＳにサブスクライブリクエストを送信する。
次に、第１ＦＰＳ２２８はサブスクライブリクエスト３１４を受信して第１ＦＰＳ２２８のサブスクリプションテーブル２３０にＵＲＬ１を追加する。第１ＦＰＳ２２８は次に「ＧＥＴ  ＲＰＳ」リクエスト３１６をマップサーバ２５４に送信して、リクエストに示された情報チャネルに関してＲＰＳを割当てるようにマップサーバ２５４に対して要求する。この場合の「ＧＥＴ  ＲＰＳ」リクエスト３１６は「ＧＥＴ  ＲＰＳ（ＵＲＬ１）」となる。マップサーバ２５４はその時点での割当て状況および負荷分散ポリシーに基づいて割当てＲＰＳを決定し、割当てＲＰＳの識別子（即ち、サーバ識別子）をメッセージ３１８として第１ＦＰＳ２２８に送信する。マップサーバ２５４は、また、ＵＲＬ１，第１ＦＰＳ，第１ＲＰＳの割当てを示す記録３２２をそのサブスクリプションデータベース３２４に追加する。
メッセージ３１８を受信した第１ＦＰＳ２２８は、ＵＲＬ１を含み、要求者を自らすなわち第１ＦＰＳ２２８とするサブスクライブリクエスト３２６を第１ＲＰＳ２４０に転送する。第１ＲＰＳ２４０は、サブスクライブリクエスト３２６を受信すると、ＵＲＬ１で識別される情報チャネルに関して第１ＲＰＳ２４０が第１ＦＰＳ２２８に割当てられたことを示すために、ＵＲＬ１及び第１ＦＰＳをそのサブスクリプションテーブル２４２に登録する。次に第１ＲＰＳ２４０は、ＵＲＬ１で識別されるコンテンツに関して周期的に条件付ＧＥＴコマンドを実行する。条件付ＧＥＴは、周知のＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）の一部である。「条件付ＧＥＴ（ＵＲＬ）」リクエストとは、条件付ＧＥＴコマンドのパラメータとして特定された期間内にコンテンツが変更されている場合にのみ、ＵＲＬで識別される情報を返送するように、受け手に対して要求するリクエストである。このように、第１ＲＰＳ２４０は発行者ウェブサーバ２４８に対して、周期的に条件付ＧＥＴリクエストとして条件付ＧＥＴ（ＵＲＬ１）３３０を送信する。
条件付ＧＥＴリクエストのパラメータが満足されると（すなわち、新しいコンテンツが入手可能になっていると）、発行者ウェブサーバ２４８は図中３３４で表されるように、ＵＲＬ１と関連する新コンテンツ３３４を第１ＲＰＳ２４０に送信する。ＲＳＳの実施例においては、この新コンテンツ３３４の代りに、発行者２４８から入手可能な追加コンテンツを説明するメタデータを含む更新されたＲＳＳファイルが返信される。新コンテンツ３３４（或いはＲＳＳファイル）を受信すると、第１ＲＰＳ２４０はそのコンテンツ（或いはＲＳＳファイル）がＵＲＬ１で識別されることを認識し、サブスクリプションテーブル２４２において検索を行って、ＵＲＬ１に関して該ＲＰＳ２４０がどのＦＰＳに割当てられているかを決定する。サブスクリプションテーブル２４２に示されるように、第１ＲＰＳ２４０はＵＲＬ１に関して第１ＦＰＳに割当てられている。第１ＲＰＳ２４０は「プッシュコンテンツ（ＵＲＬ１）」メッセージ３３６によって新情報コンテンツ（或いはＲＳＳファイル）を第１ＦＰＳ２２８にプッシュする。
クライアント側では、更新されたコンテンツ（或いはＲＳＳファイル）があるかどうか確認するために、クライアント２０２のアグリゲータ２０４が条件付ＧＥＴ（ＵＲＬ１）コマンド３３８によって第１ＦＰＳ２２８を周期的にアクセスする。更新されたコンテンツ（或いはＲＳＳファイル）がある場合は、アグリゲータ２０４はメッセージ３４０によってその新コンテンツ（或いはＲＳＳファイル）を第１ＦＰＳ２２８から取得する。
代りに、第１ＦＰＳ２２８が第１ＲＰＳ２４０から更新されたコンテンツ（或いはＲＳＳファイル）を取得したら、直ちにクライアント２０２にこれをプッシュするようにしても良い。この場合、第１ＦＰＳ２２８はサブスクリプションテーブル２３０にクライアント２０２の識別子をＵＲＬ１と関連付けて記憶しておく。
以下には、クライアント２０２のアグリゲータ２０４として、特にサブスクライブリクエスト３１４をＦＰＳに送信する能力をもたないアグリゲータを利用した場合を説明する。
図３において、マップサーバ２５４は、アグリゲータ２０４が動いているクライアント２０２からの、指定されたＵＲＬ１に対するＩＰアドレスの解決要求を受けると、その要求に対して、適切なＦＰＳ２２８を一つ選んで、そのＦＰＳ２２８のＩＰアドレスを返答し、クライアント２０２に該ＩＰアドレスに対してアクセスさせる。ＦＰＳ２２８はアグリゲータ２０４が動いているクライアント２０２から前記ＵＲＬ１へのアクセスを初めて受けたら、それを配信すべきチャネルとしてサブスクリプションテーブル２３０に登録する。次にＦＰＳ２２８は、マップサーバ２５４に問い合わせて、ＲＰＳ２４０の割り当てを受け、その後にそのＲＰＳ２４０にサブスクライブリクエスト３２６を送る。これ以降の動作は上述した動作と同様であるので、省略する。
上記した一連の動作は、クライアントから、関心のある情報に関する情報識別子を始めて受信した場合に行われる動作であり、この動作によって得られた更新情報は、次の更新情報が転送されるまで、ＦＰＳに保持される。このことは、後述する実施例においても同様である。尚、ここで言う更新情報は、メタコンテンツをあらわす情報であり、ここでは、ユーザの要求により配信されるコンテンツ全体の配信は別の経路を介して行われるものとする。
図４を参照すると、本発明の別の実施例によるネットワーク・アーキテクチャが示されている。この実施例の図２の実施例とは異なる点を以下に説明する。まず、第２クライアント２０８は、線２５８’で表されるように情報チャネルＢに関して第２ＦＰＳ２３２に割当てられる。（図２では、第２クライアント２０８は、線２５８で表されるように情報チャネルＢに関して第１ＦＰＳ２２８に割当てられている。）第２ＦＰＳ２３２には情報チャネルＢにサブスクライブしているクライアント２０８が割当てられているため、第２ＦＰＳ２３２は、情報チャネルＢを識別する情報識別子を含むサブスクリプションテーブル２３４を備えている。また、線２６６’で表されるように、第２ＦＰＳ２３２のサブスクリプションチャネルＢは第２ＲＰＳ２４４に割当てられており、この割当てがＲＰＳサブスクリプションテーブル２４６に保存される。
この実施例では、第１クライアント２０２は第１ＦＰＳ２２８に割当てられ、第２クライアント２０２は第２ＦＰＳ２３２に割当てられ、第３クライアント２１４は第２ＦＰＳ３２に割当てられ、第４クライアント２２０は第３ＦＰＳ２３６に割当てられる。すなわち、本実施例でのＦＰＳのクライアントに対する割り当ては、クライアントから見ると、一つのクライアントは一つのＦＰＳに接続するように行われている。換言すれば、ＦＰＳのクライアントへの割当ては、クライアントのチャネル毎にＦＰＳを割当てるのではなく、クライアント毎にＦＰＳを割当てる。クライアントは特定の情報に関してではなく、アグリゲータに関して、複数のＦＰＳのなかから一つを割当てられる。各々のＦＰＳは、特定の情報に関してではなく、アグリゲータに関してクライアントにサービスを実行するように割り当てられる。
例えば、クライアント２０２上でアグリゲータ２０４のアプリケーションプログラムが立ち上がったとき、クライアント２０２はマップサーバ２５４からＦＰＳ２２８の割り当てを受ける。その後、クライアント２０２が新たにチャネルをサブスクライブしたときは、クライアント２０２はこの割当てられた同一のＦＰＳ２２８に対してアクセスを行う。
これにより、クライアントはＦＰＳと接続したひとつのＴＣＰコネクション上で、サブスクライブされたチャネルに対するアクセスを行うならば、ＦＰＳが終端するＴＣＰコネクションの数は収容するアグリゲータの数だけで決まり、チャネル数に依存しなくなるので、ＦＰＳの処理負荷が減る。
このように、本実施例においては、ＦＰＳのクライアントへのサービスの提供は、情報識別子に関してではなく、クライアントで実行されているアグリゲータに関して行うものである。
図２、図３、および図４に示した各要素は、周知のネットワーク構成要素を用いて実現することができる。例えば、クライアント、マップサーバ、ＦＰＳ、ＲＰＳ、発行者ウェブサーバは、適切にプログラムされた汎用コンピュータを用いて実現することができる。また、ＦＰＳ、ＲＰＳ、マップサーバはプログラムによって構成されても良く、この場合、物理的に同一のコンピュータ内に、ＦＰＳ、ＲＰＳ、マップサーバが存在することもある。
このようなコンピュータは当技術分野で周知であり、例えば周知のコンピュータ・プロセッサ、メモリ装置、記憶装置、コンピュータ用ソフトウェア等の構成要素を用いて実現することができる。このようなコンピュータのハイレベル・ブロック図を示したのが図５である。コンピュータ４０２はプロセッサ４０４を備え、プロセッサ４０４はコンピュータの動作を定義するコンピュータプログラムの命令を実行することによって、コンピュータ４０２の動作全般を制御する。コンピュータプログラムの命令を記憶装置４１２（磁気ディスク等）に記憶させ、コンピュータプログラムの命令を実行させたいときにメモリ４１０にロードするようにしても良い。この場合、コンピュータ４０２の動作はメモリ４１０および／または記憶装置４１２に記憶されたコンピュータプログラムの命令によって定義されることになり、コンピュータプログラムの命令を実行するプロセッサ４０４によって動作制御されることになる。コンピュータ４０２はまた、ネットワークを介して他の装置と通信するためネットワークインタフェイス４０６を１つ以上備える。コンピュータ４０２はさらに、ユーザに対してコンピュータ４０２とのやり取りを可能にする装置（表示装置、キーボード、マウス、スピーカ、ボタン等）である入出力部４０２も備える。当業者であれば、実際のコンピュータを構成する上で、その他の構成要素も含まれることを理解されよう。図５はこのようなコンピュータの構成要素のいくつかを例示したハイレベル・ブロック図である。
当業者には明らかなとおり、ネットワークのどの部分を実現するかによって、適切な装置のハードウェアおよびソフトウェアの構成が変るのは当然である。一実施例では、ＦＰＳはウェブサービスを用いてクライアントとの通信を行い、ＴＣＰ／ＩＰソケットを用いてＲＰＳとの通信を行う。各ＦＰＳがサーバを実行して、これによりクライアントからのサブスクリプションメッセージやＲＰＳからのコンテンツメッセージを待つ。同様に、ＲＰＳはＴＣＰ／ＩＰソケットを使用してＦＰＳおよびマップサーバと通信する。各ＲＰＳもサーバを実行して、これによりＦＰＳからのサブスクリプションメッセージを待つ。マップサーバもまたウェブサービスを用いてクライアントと通信すると共に、ＴＣＰ／ＩＰソケットを用いてＦＰＳおよびＲＰＳと通信する。
以上の詳細な説明はあくまでも例示的に示したものであり、本発明を何ら限定するものではない。本発明の範囲を決定するのは以上の詳細な説明ではなく、特許法で許される限りの範囲において解釈される請求項である。また、ここに本発明の原理を特定の実施例に基づいて図示し説明したが、これらの実施例は例示的に示したものに過ぎず、当業者には本発明の要旨を逸脱することなく様々な変更が可能であることは言うまでもない。また、当業者であれば、ここ記載した以外にも本発明の要旨を逸脱することなく、様々な機能を組合せて実施ことができるであろう。例えば、以上の説明は大部分がＲＳＳデータ配信方式に関連するものであったが、本発明はこれに限定されるものではなく、ネットワークのいかなる種類のコンテンツ配信にも適用することができる。
【図１】
0004753052.tif 000002
【図２】
0004753052.tif 000003
【図３】
0004753052.tif 000004
【図４】
0004753052.tif 000005
【図５】
0004753052.tif 000006