(57)【要約】  クライアントのために個別コンテンツを含むライブオブジェクトを，動的に更新する技法が提供される。その技法は，第１識別子及び第２識別子を含む情報源からの第１メッセージを受信するステップを含む。第１識別子はクライアント毎に唯一であってよい。第２識別子は多くのクライアントに共通であってよい。第１メッセージは第２識別子に関連付けられたライブオブジェクトの特性値を更新するための情報を含む。第１識別子によって特定されるクライアントが識別される。次に第２メッセージがネットワークを通じてクライアントへ配信される。第２メッセージは第１識別子及び第２識別子を含むことができ，また第２識別子に関連付けられたライブオブジェクトの特性値を更新するための情報を含むことができる。クライアントは第２メッセージを受信し，第２識別子に関連付けられたライブオブジェクトの特性値を更新することができる。
2008515032.tif 000002
【特許請求の範囲】
【請求項１】
クライアントのために個別情報を含むライブオブジェクトを動的に更新するための配信ネットワークであって，
第１識別子及び第２識別子を指定し，前記第２識別子に関連付けられたライブオブジェクトの特性値を更新するための個別情報を含む第１メッセージを情報源から受信し，
前記第１識別子によって特定されるクライアントを識別し，かつ
前記第１識別子によって特定される前記クライアントへ，第２メッセージをネットワークを通じて配信することができるノードを備え，
前記第２メッセージは，前記第２識別子に関連付けられた前記ライブオブジェクトの特性値を更新するための個別情報を含む，配信ネットワーク。
【請求項２】
前記クライアントが前記個別情報を用いて，前記第２識別子に関連付けられた前記ライブオブジェクトの前記特性値を更新することができる，請求項１に記載の配信ネットワーク。
【請求項３】
前記第２識別子は複数のクライアントに共通とする，請求項１に記載の配信ネットワーク。
【請求項４】
配信ネットワークであって前記ノードが更に，
第３識別子及び第２識別子を指定し，前記第２メッセージに関連付けられた第２ライブオブジェクトの第２特性値を更新させるための個別情報を含む第３メッセージを前記情報源から受信し，
前記第３識別子によって特定される第２クライアントを識別し，
前記第３識別子によって特定される前記第２クライアントへ，第４メッセージを前記ネットワークを通じて配信することができ，
前記第４メッセージは，前記第３識別子及び第２識別子を指定し，前記第２識別子に関連付けられた前記第２ライブオブジェクトの前記第２特性値を更新するための個別情報を含む，請求項１に記載の配信ネットワーク。
【請求項５】
前記ノードは，前記第２識別子を用いて１以上の追加クライアントへ前記個別情報を送信することができ，
また前記ノードは，前記個別情報を配信するために各追加クライアントに唯一の個別識別子を用いる請求項１に記載の配信ネットワーク。
【請求項６】
前記第１メッセージは，１以上の追加識別子に関連付けられた１以上のライブオブジェクトの１以上の特性値を更新するための追加情報を含み，
前記第２メッセージは，前記１以上の追加識別子を指定し，１以上の追加識別子に関連付けられた１以上のライブオブジェクトの１以上の特性値を更新するための前記追加情報を含む請求項１に記載の配信ネットワーク。
【請求項７】
前記１以上の追加識別子は，前記クライアントに特定の個別コンテンツ，又は複数のクライアントに共通のコンテンツに関連付けられる，請求項６に記載の配信ネットワーク。
【請求項８】
前記ノードは，前記第２識別子に関連付けられた情報を受信するために，前記第１識別子と共に前記第２識別子の登録要求を前記クライアントから受信することができる，請求項１に記載の配信ネットワーク。
【請求項９】
前記ライブオブジェクトは，前記クライアントにおけるデータ表現に含まれる請求項１に記載の配信ネットワーク。
【請求項１０】
前記データ表現は，ＷＥＢページ又はアプリケーションプログラムを含む請求項９に記載の配信ネットワーク。
【請求項１１】
前記第１メッセージと前記第２メッセージとがおおむね類似する請求項１に記載の配信ネットワーク。
【請求項１２】
クライアントのための個別情報を含むライブオブジェクトを動的に更新するための方法であって，
第１識別子及び第２識別子を指定し，前記第２識別子に関連付けられたライブオブジェクトの特性値を更新するための個別情報を含む第１メッセージを情報源から受信するステップと，
前記第１識別子によって特定されるクライアントを識別するステップと，
前記第１識別子によって特定される前記クライアントへ，第２メッセージをネットワークを通じて配信するステップと，を有し，
前記第２メッセージは，前記第２識別子に関連付けられた前記ライブオブジェクトの特性値を更新するための個別情報を含む方法。
【請求項１３】
前記クライアントが，前記第２識別子に関連付けられた前記ライブオブジェクトの前記特性値を，前記個別情報を用いて更新することができる，請求項１２に記載の方法。
【請求項１４】
前記第２識別子は複数のクライアントに共通とする，請求項１２に記載の方法。
【請求項１５】
第３識別子及び第２識別子を指定し，前記第２メッセージに関連付けられた第２ライブオブジェクトの第２特性値を更新させるための個別情報を含む第３メッセージを前記情報源から受信するステップと，
前記第３識別子によって特定される第２クライアントを識別するステップと，
前記ネットワークを通じて前記第３識別子によって特定される前記第２クライアントへ第４メッセージを配信するステップと，を更に有し，
前記第４メッセージは，前記第３識別子及び第２識別子を指定し，前記第２識別子に関連付けられた前記第２ライブオブジェクトの前記第２特性値を更新するための個別情報を含む，請求項１２に記載の方法。
【請求項１６】
前記ノードは，前記第２識別子を用いて１以上の追加クライアントへ前記個別情報を送信することができ，
また前記ノードは，前記個別情報を配信するために各追加クライアントに唯一の個別識別子を用いる請求項１２に記載の方法。
【請求項１７】
前記第１メッセージは，１以上の追加識別子に関連付けられた１以上のライブオブジェクトの１以上の特性値を更新するための追加情報を含み，
前記第２メッセージは前記１以上の追加識別子を識別し，１以上の追加識別子に関連付けられた１以上のライブオブジェクトの１以上の特性値を更新するための前記追加情報を含む請求項１２に記載の方法。
【請求項１８】
前記１以上の追加識別子は，前記クライアントに特定の個別コンテンツ，又は複数のクライアントに共通のコンテンツに関連付けられる，請求項１７に記載の方法。
【請求項１９】
前記第２識別子に関連付けられた情報を受信するために，前記第１識別子と共に前記第２識別子のための登録要求を前記クライアントから受信するステップを更に有する請求項１２に記載の方法。
【請求項２０】
前記ライブオブジェクトは，前記クライアントにおけるデータ表現に含まれる請求項１２に記載の方法。
【請求項２１】
前記データ表現は，ＷＥＢページ又はアプリケーションプログラムを含む請求項２０に記載の方法。
【請求項２２】
前記第１メッセージと前記第２メッセージとがおおむね類似する請求項１２に記載の方法。
【請求項２３】
クライアントのための個別情報を含むライブオブジェクトを動的に更新するための配信ネットワークを用いるための方法であって，
第１個別識別子及び共通識別子のための第１登録要求を第１クライアントから受信するステップと，
第２個別識別子及び前記共通識別子のための第２登録要求を第２クライアントから受信するステップと，
複数のクライアントのうち第１クライアントのための第１個別情報を判定するステップと，
前記第１個別情報と前記共通識別子とを関連付けるステップと，
複数のクライアントのうち第２クライアントのための第２個別情報を判定するステップと，
前記第２個別情報と前記共通識別子とを関連付けるステップと，
前記第１個別情報及び前記共通識別子を含み，前記共通識別子と関連付けられた前記第１個別情報を含む第１メッセージを生成するステップと，
前記第２個別情報及び前記共通識別子を含み，前記共通識別子と関連付けられた前記第２個別情報を含む第２メッセージを生成するステップと，
前記第１メッセージを，前記第１個別識別子を用いて前記第１クライアントに送信するステップであって，前記第１クライアントが前記第１個別情報を用いて前記共通識別子と関連付けられた第１ライブオブジェクトの特性値を更新できるステップと，
前記第２メッセージを，前記第２個別識別子を用いて前記第２クライアントに送信するステップであって，前記第２クライアントが前記第２個別情報を用いて前記共通識別子と関連付けられた第２ライブオブジェクトの特性値を更新できるステップと，を有する方法。
【請求項２４】
前記第１メッセージ及び前記第２メッセージを前記配信ネットワークを通じて送信し，
前記配信ネットワークは，前記第１個別識別子と関連付けられた前記第１クライアントを判定することができ，前記第１メッセージを前記第１クライアントへ配信し，
前記配信ネットワークは，前記第２個別識別子と関連付けられた前記第２クライアントを判定することができ，前記第２メッセージを前記第２クライアントへ配信する請求項２３に記載の方法。
【請求項２５】
個別コンテンツを含むライブオブジェクトを動的に更新できるクライアントであって，
第１識別子及び第２識別子を指定するメッセージを配信ネットワークから受信することができる論理であって，前記第１メッセージは前記第２識別子に関連付けられたライブオブジェクトの特性値を更新する個別情報を含み，前記第１識別子は前記クライアントに特定であり，前記第２識別子は前記クライアント及び１以上の追加クライアントに共通である論理と，
前記第２識別子に関連付けられた前記ライブオブジェクトの特性値を更新するための前記個別情報を識別できる論理と，
前記個別情報を用いて前記ライブオブジェクトの前記特性値を更新させることができる論理と，を有するクライアント。
【請求項２６】
前記メッセージは，１以上の追加識別子に関連付けられた１以上のライブオブジェクトの１以上の特性値を更新するための追加情報を含む請求項２５に記載のクライアント。
【請求項２７】
前記第２識別子と関連付けられた情報を受信するために，前記第１識別子と共に前記第２識別子を登録することができる論理を更に有する請求項２５に記載のクライアント。
【請求項２８】
前記第１メッセージと前記第２メッセージとがおおむね類似する請求項２５に記載のクライアント。
【請求項２９】
前記ライブオブジェクトは，前記クライアントにおけるデータ表現に含まれる請求項２５に記載のクライアント。
【請求項３０】
前記データ表現は，ＷＥＢページ又はアプリケーションプログラムを含む請求項２９に記載のクライアント。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示の実施例は概略，ネットワークを通じて情報を転送することに関連し，特にネットワークを通じてクライアントデバイスにおけるコンテンツを遠隔で更新するために，個別化した情報を転送することに関する。
【背景技術】
【０００２】
ユーザはワールドワイドウェブから多くのさまざまな種類のコンテンツをダウンロードすることができる。いくつかの場合，ユーザはウェブページに対して所望するコンテンツを送信するサービスに加入することができる。コンテンツプロバイダは，どのユーザがどのコンテンツを登録したかを追跡し続ける必要があるかもしれない。またサービスプロバイダは，どのユーザがどのコンテンツを登録したかを追跡し続けることに加えて，各ユーザが登録したコンテンツをどのように送信するかを知る必要があるかもしれない。このことは，登録したユーザと，各ユーザが所望するコンテンツと，ユーザへどうやってコンテンツを配信するかと，を追跡し続けるために膨大なリソースを必要とするかもしれない。
【発明を実施するための最良の形態】
【０００３】
本明細書及び付随する図面の残りの部分を参照することによって，ここに開示する実施例の性質及び利点の更なる理解が可能になるであろう。
【０００４】
１つの実施例において，個別コンテンツは動的コンテンツ配信ネットワークを用いて遠隔クライアントに提供することができる。最初に動的コンテンツ配信ネットワークを説明し，次にクライアントへ個別コンテンツを配信することを説明する。
【０００５】
動的コンテンツ配信ネットワーク
図１に，動的コンテンツ配信ネットワーク１１０（以降，「配信ネットワーク」と呼ぶ）を含む環境１００を示す高レベルのブロック図を示す。また環境１００は，クライアント１１４，情報プロバイダ１０８及び動的コンテンツプロバイダ１１６と通信するサーバ１１２も含む。典型的な環境１００は何百かのサーバ１１２及び情報プロバイダ１０８と，何千（又は何百万でさえあり得る）のクライアント１１４と，複数の動的コンテンツプロバイダ１１６とを有するであろうが，図１では説明を明りょうさにするために，これらのエンティティをそれぞれ１つだけ示している。
【０００６】
サーバ１１２と，クライアント１１４と，情報プロバイダ１０８と，ダイナミックコンテンツプロバイダ１１６と，配信ネットワーク１１０とは，インターネットを構成するもののような通常の通信リンク１１７を介して通信することが好ましい。通信リンク１１７は，既知の専用又は共用の，データ回線，ケーブルテレビ回線又は電話回線，及び／又は世界移動体通信システム（ＧＳＭ），符号分割多元接続（ＣＤＭＡ），時間分割多元接続（ＴＤＭＡ）などのようなプロトコルを用いる携帯電話ネットワークを介する通信のような既知の無線通信メディアである。
【０００７】
１つの実施例において各エンティティはそれぞれ，各エンティティがインターネット上のほかの計算機へ接続できるようにする１以上のインターネットサービスプロバイダ（ＩＳＰ）（図示していない）と通信することができる。更にサーバ１１２と，クライアント１１４と，情報プロバイダ１０８と，動的コンテンツプロバイダ１１６と，配信ネットワーク１１０とは，それぞれ少なくとも１つの，"66.35.209.224"のようなインターネットプロトコル（ＩＰ）アドレスによって識別されることが好ましい。またＩＰアドレスは，"bangnetworks.com"のようなそのＩＰアドレスに関連付けられた１以上のドメイン名を持つことができる。本発明の代替実施例は，ここで説明したものの代わりに，又はそれに追加して，代替のアドレス体系及び／又は命名慣習を用いてもよい。例えば１以上のクライアントが携帯電話機又はほかの可搬型デバイスである実施例は，さまざまなアドレス体系に依存してもよい。
【０００８】
情報プロバイダ１０８はウェブページ又はほかのデータ表現をサーバ１１２に提供することが好ましい。ウェブページは，リアルタイムの動的更新可能オブジェクトとして指定された１以上の「ライブオブジェクト」を含む。各ライブオブジェクトはオブジェクト識別子，すなわちオブジェクトＩＤによって識別される。サーバ１１２は，ページ１１８を複数のクライアント１１４に提供することが好ましい。クライアント１１４は配信ネットワーク１１０に接続し，ウェブページ上のオブジェクトＩＤに対して更新メッセージを登録する。次に配信ネットワーク１１０は，どのクライアントがどのオブジェクトＩＤに登録されているかを示す登録情報を維持管理することが好ましい。
【０００９】
情報プロバイダ１０８及び／又は動的コンテンツプロバイダ１１６は，配信ネットワーク１１０に更新メッセージを送信する。これらのメッセージは，情報プロバイダ１０８又は動的コンテンツプロバイダ１１６がライブオブジェクトの特性値を更新したいときいつでも送信できる。各更新メッセージはライブオブジェクトを指定し，指定されたライブオブジェクトの特性値を更新するためのデータを含むことが好ましい。配信ネットワーク１１０は登録情報を利用して，指定されたオブジェクトにどのクライアントが登録されているかを判定する。次に配信ネットワーク１１０は更新メッセージを適切なクライアントへ配信する。更新メッセージを受信すると，クライアント１１４はライブオブジェクトの指定された特性値を更新する。
【００１０】
配信ネットワーク１１０は，オブジェクトに基づく配信によって，各オブジェクトと各クライアントとの効率的な１対多の対応付けを（そして情報の推定によって，各情報プロバイダ１０８又は動的コンテンツプロバイダ１１６と各クライアントとの多対多の対応付けも）提供する。情報プロバイダ１０８及び／又は動的コンテンツプロバイダ１１６が配信ネットワーク１１０に提供するメッセージは，特定の目的地に完全に基づいては，クライアント１１４に配信されない。より明確にはそれらは，通常のＩＰ経路制御体系のようにクライアントのＩＰアドレスに従っては配信されない。代わりにメッセージは，メッセージが参照するライブオブジェクトに基づいて配信される。
【００１１】
配信ネットワーク１１０が提供する対応付け及びオブジェクトに基づく配信によって，情報プロバイダ及び動的コンテンツプロバイダがクライアント又はクライアントが見ているウェブページを追跡する必要なく，情報プロバイダ１０８及び動的コンテンツプロバイダ１１６がリアルタイムで動的に変化するクライアントのグループにおけるライブオブジェクトの特性値を更新できるようにする。次にクライアント１１４はオブジェクトＩＤについて何の事前知識も必要なく，サーバ１１２からページ１１８を受信したとき，どのＩＤを登録すべきかを「発見」する。
【００１２】
またオブジェクトに基づく配信によって，情報プロバイダ１０８はクライアント１１４がコンテンツを再要求する必要なく，また情報プロバイダ１０８又はサーバ１１２が，クライアントとコネクションを保持することなく，Ｗｅｂページ上のコンテンツを動的に更新できる。この方法によって，通常のクライアント側の要求駆動型の送信制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）によるクライアントとサーバ１１２との間のコネクションを用いて可能になるものにより非常に多くのクライアントが，特定の情報プロバイダ１０８から更新されたコンテンツを受信できる。
【００１３】
ここで図１に示した個々のエンティティに移ると，サーバ１１２は通常の計算機システムであって，ウェブサーバとして動作して，クライアント１１４にページ１１８及びほかのデータ表現を提供することが好ましい。サーバ１１２が提供するページ１１８は，１以上の情報プロバイダ１０８と関連付けられている。
【００１４】
情報プロバイダ１０８は，１以上のページ１１８，ウェブページに含まれる情報，及び／又はサーバ１１２が提供するほかのデータ表現を提供するエンティティである。情報プロバイダ１０８はインターネットに接続された通常の計算機システムを備えることが好ましい。１つの実施例においては，サーバ１１２は情報プロバイダ１０８が直接制御する。（例えばサーバは，情報プロバイダに物理的に設置されているか，及び／又は専用で情報プロバイダのウェブページだけを提供する。）この実施例においては，サーバ１１２と情報プロバイダ１０８とは同一のエンティティとして取り扱うことができる。代替実施例においては，サーバ１１２は複数の情報プロバイダのウェブページを提供する。
【００１５】
本技術においては周知のとおり，サーバ１１２上のページ１１８及びほかのコンテンツは，"service://server/path/web page"の形態をとる統一リソースロケータ（ＵＲＬ）によって規定される。典型的にはページ１１８はハイパテキスト転送プロトコル（ＨＴＴＰ）を介して取得されるので，したがってドメイン名"www.bangnetorks.com"を持つウェブサーバからウェブページ"b1.html"を取得するための例示ＵＲＬは，"http://www.bangnetworks.com/news/b1.html"となる。
【００１６】
ここで用いられているとおり，「ウェブページ」はサーバ１１２から得られるデータブロックである。最も簡単な場合，ウェブページはハイパテキストマーク付け言語（ＨＴＭＬ）で書かれたファイルである。またウェブページは，ほかのファイル，テキスト，画像，アプレット，ビデオ，及び／又はオーディオのような１以上のほかのデータブロックを含んでもよいし，参照してもよい。更にウェブページは，ＨＴＭＬタグ及びスタイルシートのようなウェブページ及びそのコンテンツを提示するための命令を含んでもよい。また命令は拡張可能マーク付け言語（ＸＭＬ）で書かれていてもよく，ＸＭＬはＨＴＭＬに関連し，ウェブページ又はウェブページにいくらかの動的コンテンツを追加するダイナミックＨＴＭＬ（ＤＨＴＭＬ）に意味的な内容を追加する。更に命令はＪＡＶＡ（登録商標），ＪＡＶＡＳＣＲＩＰＴ（登録商標）及び／又はＤＨＴＭＬスクリプトのような１以上のプログラムの形態をとってもよい。
【００１７】
またここで用いられているとおり「ウェブページ」という句は，サーバ１１２が提供するほかのデータ表現も指し，これらのデータ表現が通常のウェブページの特徴を含むかどうかにはかかわらない。例えばこれらのデータ表現は，アプリケーションプログラム及びウェブブラウザ１２０のためのデータ，若しくはクライアント１１４又は別の場所に常駐する表計算のデータ又は（例えばワープロの）テキストデータのような，ほかのアプリケーションプログラムのためのデータを含む。
【００１８】
好ましい実施例においては情報プロバイダ１０８が，ウェブページ及びウェブページの要素のようなクライアントにおけるオブジェクトを「ライブ」として指定することができる。ライブオブジェクトの特性値は，情報プロバイダ１０８又は情報プロバイダを代理するほかのエンティティが，クライアント１１４においてリアルタイムで動的に更新することができる。ここで用いられているとおり「オブジェクト」は，個別に指定又は利用できるクライアント１１４における任意のデータである。オブジェクトの例は，文字及び文字列，画像，フレーム，表，オーディオ，ビデオ，アプレット，スクリプト，ＨＴＭＬ，ＸＭＬ，並びにウェブページ，アプレットが用いる変数及びほかの情報，スクリプト及び／又はコード，ウェブページに組み込まれたＵＲＬのようなウェブページの要素である。アプリケーションとオペレーティングシステムの構成物もまたオブジェクトである。例えば表計算のセル，ワープロ文書のテキスト，並びにオペレーティングシステム又はアプリケーションが表示するタイトルバー及びメッセージもオブジェクトである。複数のオブジェクトは，１つの論理的オブジェクトにまとめることができることが好ましい。このようにオブジェクトは，任意の所望の又は役に立つ粒度レベルで定義できる。
【００１９】
ウェブページ上のコンテンツは，「オブジェクト」によって概念化され，組織化されているので，本発明は本質的にウェブページ，ウェブページコンテンツ，ほかのモジュール及び／又はクライアント１１４における機能を，ＨＴＭＬコード又はほかの通常表現から抽象化する。この抽象化によって情報プロバイダ１０８は，クライアント１１４においてデータを表現する位置，表示形式又はどのように表現するかについてのほかの仕様にかかわらず，オブジェクトの特性値を更新することができる。
【００２０】
ライブオブジェクトは，そのオブジェクトに関連した，又はそのオブジェクトに関して参照している任意の修正可能データを含む関連する「特性値」を有する。必須ではないが典型的には，情報プロバイダ１０８はクライアント１１４に提供されるライブオブジェクトの特性値を初期設定する。特性値は，ウェブページ又はほかのデータ表現内のオブジェクトの視覚的表現に影響するものであってもよいし，そうでないものでもよい。特性値はオブジェクトの内部態様に影響するものであってもよいので，したがって特性値の変更はオブジェクトを含むウェブページに直接の影響を持たないこともある。例えば特性値は，オブジェクトの特定の態様が修正可能かどうか，オブジェクトがユーザ入力又はほかの刺激にどのように応答するか，などに影響してもよい。また更に特性値は，オブジェクトがクライアント１１４においてどのように表示されるかについて，直接影響を持ってもよい。例えば特性値は，オブジェクトによって表示されるテキスト，画像又はほかのデータの内容，色，字形，大きさ，書式，又はほかの属性に影響してもよい。ほかの特性値は，オブジェクトの可視表現に全く影響を持たないものと，オブジェクトの可視表現に影響を持つものとの間の範囲の一部を占める。例えばフットボール試合の点数を示しているウェブページは，試合のリスト及びサーバ１１２がウェブページを提供した時点の試合の点数を含むことができる。試合のリストと，表示する試合のサブセットと，試合の点数とは，それぞれライブオブジェクト（又は１つのライブオブジェクトの特性値）として指定することができ，必要なとき又は所望されたときに更新することができる。
【００２１】
また特性値は，オブジェクトのインスタンスの実体化又はオブジェクトの機能の呼出しを含むことができることが好ましい。例えばブラウザウィンドウオブジェクトの特性値は，ほかのブラウザウィンドウを実体化するための機能を含んでもよい。この機能は，オブジェクトの特性値への論理的変更として呼び出される。第２ブラウザウィンドウは，元のブラウザウィンドウ（すなわちオブジェクト）を介して参照できるか，又は新しいライブオブジェクトとして指定できる。
【００２２】
情報プロバイダ１０８又はほかのエンティティは，クライアント１１４において更新メッセージを介してライブオブジェクトを更新することが好ましい。一般に更新メッセージはライブオブジェクト及び必要ならばライブオブジェクトの特性値を指定し，特性値を更新するデータを含む。１つの実施例においてデータは，特性値の実際の値であってもよいし，オブジェクトの特性値を更新するための実行可能コードであってもよい。例えばデータは，それに対して特性値を設定する単純な数字又は文字，例えば「４」であってよく，及び／又はデータはオブジェクトの特性値に所望の変化を与えるクライアントにおけるＪＡＶＡＳＣＲＩＰＴ（登録商標）コード，又はＪＡＶＡＳＣＲＩＰＴ（登録商標）機能の呼出しであってもよい。
【００２３】
更新メッセージはライブオブジェクトの特性値を更新する際に用いるクライアント１１４におけるハンドラを，暗黙に，又は明示的に指定することが好ましい。１つの実施例においてクライアント１１４は，メッセージが暗黙にハンドラを指定するとき（例えばメッセージが特定のハンドラを指定しないとき），既定のハンドラを利用する。１つの実施例においては，更新メッセージが特性値の実際の値を指定するとき，既定のハンドラは特性値を指定された値に変更するためのＪＡＶＡＳＣＲＩＰＴ（登録商標）コードを生成する。更新メッセージ内のデータがＪＡＶＡＳＣＲＩＰＴ（登録商標）であるときは，既定のハンドラはどのようなコードの処理も行わない。どちらの場合においても既定のハンドラは，クライアント１１４におけるＪａｖａ（登録商標）仮想マシン（ＪＶＭ）１２２においてＪＡＶＡＳＣＲＩＰＴ（登録商標）コードを実行するために，ＬｉｖｅＣｏｎｎｅｃｔを用い，それによってライブオブジェクトの特性値を更新することが好ましい。
【００２４】
あるオブジェクト種別及び／又はデータ種別に対しては，既定のハンドラは適当ではない。これらの場合メッセージは，明示的に更新を実行するためのハンドラを指定することが好ましい。例えばメッセージは，明示的にデータを要求する機能を規定してもよいし，又はデータが実行される環境を明示的に指定してもよい。例えば更新メッセージ内のデータは，マクロメディアフラッシュ（登録商標）のようなソフトウェア「プラグイン」によって実行されるコードを含んでもよく，またメッセージはハンドラとしてフラッシュ（登録商標）を明示的に指定してもよい。
【００２５】
情報プロバイダ１０８は，クライアント１１４に提供されるウェブページ又はほかのデータ表現において，オブジェクトの唯一の識別子，すなわちオブジェクトＩＤを含ませることによって，オブジェクトを「ライブ」として指定することが好ましい。１つの実施例において情報プロバイダ１０８は，オブジェクトＩＤを次に示すＨＴＭＬ表現を用いて，オブジェクトに対応するＨＴＭＬの「ＩＤ」属性にオブジェクトＩＤを符号化する。
ＩＤ＝”要素識別子”
ここで”要素識別子”はオブジェクトＩＤであって，文字列であることが好ましい。文字列は，情報プロバイダ１０８又はオブジェクトＩＤを確立するほかのエンティティが所望する任意の情報を符号化することができ，１つの実施例においては単純な文字及び／又は数字による識別子である。１つの実施例においては情報プロバイダ１０８は，たまたま規定されたＩＤ属性を有するほかのオブジェクトとライブオブジェクトとを識別するために，”Ｂａｎｇ＄”のような所定のトークンでオブジェクトＩＤが始まるようにする。例えばオブジェクトは，オブジェクトＩＤ”Ｂａｎｇ＄要素識別子”を有する。
【００２６】
好ましい実施例においては，各情報プロバイダ１０８はさまざまな情報プロバイダのオブジェクトＩＤ間で名称が重なるのを防ぐために，選択的にオブジェクトＩＤに唯一の情報プロバイダＩＤを符号化する。１つの実施例においては情報プロバイダＩＤは，文字及び／又は数字の識別子である。情報プロバイダ１０８は，階層的名前空間の一部に情報プロバイダＩＤ及びオブジェクトＩＤを指定することができる。例えば１つの実施例においては，オブジェクトは次のように命名される。
”＄名前空間１＄［名前空間２＄・・・＄名前空間Ｎ＄］オブジェクトＩＤ”
ここで”＄名前空間１”は情報プロバイダＩＤであり，”＄”は名称のセパレータとして機能し，名前空間階層の追加選択レベルを記述する。システム１００の１つの実施例は，典型的なディレクトリサービス機能に対応する。例えば一緒に現れる２つのドル記号”＄＄”は，名前空間階層の最上位レベルを指す。
【００２７】
このようにしてライブオブジェクトのオブジェクトＩＤは，所定のトークンと，情報プロバイダＩＤ名前空間と，情報プロバイダ１０８が指定した値との組合せによって形成されることが好ましい。例えば記号”ＢＡＮＧ”を有する株のリアルタイムの価格を表すライブオブジェクトのオブジェクトＩＤは次のようになる。
”Ｂａｎｇ＄＄情報プロバイダＩＤ＄普通株＄リアルタイム＄ｂａｎｇ”
この例において”Ｂａｎｇ＄”はライブオブジェクトを表す所定のトークンであり，”＄情報プロバイダＩＤ”は情報プロバイダを識別するＩＤであり，”普通株＄リアルタイム＄”は名前空間階層のレベルを記述し，そして”ｂａｎｇ”は特定のオブジェクトを指定する。
【００２８】
いくつかの実施例及び状況においては，オブジェクトＩＤは相対名称を用いる。例えば自分自身のオブジェクトＩＤを参照する情報プロバイダ１０８は，暗黙に自分の名前空間内にいる。したがって情報プロバイダ１０８は，内部的に用いるオブジェクトＩＤの中に情報プロバイダＩＤを含める必要はない。１つの実施例においては，情報プロバイダＩＤはオブジェクトＩＤの中に明示的に符号化されない。その代わりに情報プロバイダＩＤは，ページのオブジェクトＩＤの範囲を示すために，ウェブページのほかの場所に符号化される。
【００２９】
１つの実施例においてオブジェクトＩＤは，クライアント１１４におけるウェブページ又はほかの文書の文書オブジェクトモデル（ＤＯＭ）表現内の点（すなわち，ツリーのノード）を指定する。ＤＯＭは，文書をオブジェクトの階層として表すプラットホーム及び言語に非依存のインタフェースである。またＤＯＭは，プログラム及びスクリプトがオブジェクトの特性値を動的に利用し，更新することができるインタフェースを提供する。オブジェクトの特性値は，下位オブジェクトが継承できる。
【００３０】
本実施例においてクライアント１１４は，ＤＯＭ表現内の指定した点のコンテキストにおいて，更新メッセージを実行することが好ましい。更新メッセージは，指定された点におけるオブジェクトの特性値に対する変更を指定することができる。また更新メッセージは，指定された点におけるオブジェクトの上位オブジェクト又は下位オブジェクトに対する変更を指定することもできる。それぞれの場合更新メッセージは，ＤＯＭ表現内の指定した点に相対的に実行される。１つの実施例においてＤＯＭ表現内の点は，これらの点に位置するライブオブジェクトの特性値をどのように更新するかを指定する。このように，ＤＯＭ表現内の指定されたライブオブジェクトの位置に依存して，同一の更新メッセージは異なって解釈されることがある。
【００３１】
例えば”ウィンドウ．文書．フレーム［３］．オブジェクトＩＤ”で指定されるＤＯＭ表現内のオブジェクトがあるとしよう。またそのオブジェクトは，オブジェクトが表示するテキストを指定する，”ウィンドウ．文書．フレーム［３］．オブジェクトＩＤ．内部テキスト”に位置する”内部テキスト”特性値を有するものとしよう。更新メッセージは，”オブジェクトＩＤ”及び内部テキスト特性値の新しい値を指定することによって，オブジェクトが表示するテキストを変更することができる。
【００３２】
オブジェクトを指定するためにオブジェクトＩＤを用いる利点は，更新メッセージを提供する情報プロバイダ１０８又はほかのエンティティが，ＤＯＭ表現内のオブジェクトの実際の位置を知らなくてもオブジェクトの特性値を利用及び変更できることである。実際オブジェクトは，さまざまなＤＯＭ表現内のさまざまな位置にあってもよいし，及び／又は同一のＤＯＭ表現内の複数の位置にあってもよい。これらの場合のどれにおいても，更新メッセージは指定されたオブジェクトＩＤを有するすべてのオブジェクトの指定された特性値を変更する。
【００３３】
環境１００の特定の実施例に依存して，情報プロバイダ１０８及び／又は動的コンテンツプロバイダ１１６は配信ネットワーク１１０に更新メッセージを提供する。動的コンテンツプロバイダ１１６は，株価及び／又はスポーツの得点のようなリアルタイム情報を提供するエンティティが運用する通常の計算機システムであることが好ましい。１つの実施例において情報プロバイダ１０８は，動的コンテンツプロバイダ１１６又はほかの情報源からライブオブジェクトの更新された特性値を受信する（又は内部的に更新された特性値を生成する）。次に情報プロバイダ１０８はオブジェクトＩＤ及びオブジェクトの特性値への変更を指定する更新メッセージを，配信ネットワーク１１０へ送信する。この実施例においては，動的コンテンツプロバイダ１１６は環境１００になくてもよい。
【００３４】
もう１つの実施例において動的コンテンツプロバイダ１１６は，ライブオブジェクトのオブジェクトＩＤを１以上の情報プロバイダ１０８に提供し，情報プロバイダ１０８はライブオブジェクトをクライアント１１４に配信する。次に動的コンテンツプロバイダ１１６は，ライブオブジェクトの特性値への変更を指定するメッセージを配信ネットワーク１１０へ送信する。例えば動的コンテンツプロバイダ１１６は，特定の野球試合の得点に関係付けられたオブジェクトＩＤを情報プロバイダ１０８へ配信する。次に動的コンテンツプロバイダ１１６は，特定の野球試合の表示された得点を制御するオブジェクトのオブジェクトＩＤ及び特性値の更新を指定するメッセージを送信する。これら２つの実施例は相互に排他的ではなく，したがっていくつかの更新メッセージは情報プロバイダ１０８によって配信ネットワーク１１０へ提供され，一方でほかの更新メッセージは動的コンテンツプロバイダ１１６によって提供される。
【００３５】
クライアント１１４は，サーバ１１２からページ１１８及び／又はほかの情報を取得するデバイスである。１つの実施例においてクライアント１１４は，インターネット上の情報を利用するために人が用いる通常のパーソナル計算機である。代替実施例においては，クライアント１１４は，インターネット対応テレビ，携帯電話機，パーソナルデジタルアシスタント（ＰＤＡ），ウェブ閲覧装置，などのようなインターネット接続性を有する別の消費者向け電子デバイスである。クライアント１１４は，関連する表示デバイスを備えることが好ましいが必須ではない。
【００３６】
クライアント１１４は，ウェブページを取得して表示デバイス上に表示するために，マイクロソフトインターネットエクスプローラ（登録商標）のようなウェブブラウザ１２０を実行することが好ましい。クライアントが通常のウェブページ以外のデータ表現をサーバ１１２から受信する実施例においては，ウェブブラウザ１２０は必ずしも通常のウェブブラウザと類似性がない。好ましくは，ウェブブラウザ１２０はＪＡＶＡ（登録商標）アプレット及び／又はスクリプトを実行するＪＶＭ１２２を含む。またウェブブラウザ１２０は，ＪＡＶＡＳＣＲＩＰＴ（登録商標）（又はＶＢＳｃｒｉｐｔのようなほかのスクリプト言語）及び文書オブジェクトモデル（ＤＯＭ）への対応のようなダイナミックＨＴＭＬ能力を含み，ＪＡＶＡ（登録商標）とスクリプト言語との間の通信を可能にすることが好ましい。１つの実施例においてウェブブラウザ１２０は，ＪＡＶＡ（登録商標）アプレットと，対応するスクリプト言語で書かれたスクリプトとの間の通信を可能にするＬｉｖｅＣｏｎｎｅｃｔ標準に対応する。またウェブブラウザ１２０は，マクロメディアブラッシュ（登録商標），リアルネットワークスリアルプレイヤ（登録商標），及び／又はアップルクイックタイム（登録商標）のようなソフトウェアプラグインによって拡張することができる。代替実施例においてＪＶＭ１２２の機能及び／又はウェブブラウザ１２０のほかの態様は，クライアント１１４内の１以上のほかの機能ユニットによって提供される。「モジュール」という用語は，ここではモジュールの機能を提供するために用いられるソフトウェア計算機プログラム及び／又はハードウェア又は回路を指す。ウェブブラウザ１２０及びＪＶＭ１２２は，クライアント１１４におけるモジュールの例である。
【００３７】
いくつかの実施例においてクライアント１１４は，必ずしも表示デバイス，ウェブブラウザ１２０，及び／又は典型的な消費者向けデバイスに関連するほかのコンポーネントを備えていない。例えばクライアント１１４は，ウェブ対応装置，若しくは自動車，オーディオビデオ装置，又はあるほかのデバイスのコントローラに組み込まれたＨＴＴＰクライアントのような，ある態様のウェブ接続性を備える専用目的デバイスであってもよい。
【００３８】
サーバ１１２からクライアント１１４に提供されるページ１１８は，ウェブページ上にライブオブジェクトを実現する命令を含むことが好ましい。その命令は，クライアント１１４が自動的かつ透過的に（すなわちユーザ対話なしに）配信ネットワーク１１０に接続して，ライブオブジェクトを活性化するための活性化モジュール１２４をダウンロードするようにさせる。１つの実施例において命令は，配信ネットワーク１１０内の活性化モジュール１２４の位置を指定するＵＲＬを含む。代替実施例においては，クライアント１１４はサーバ１１２又はほかの情報源から活性化モジュール１２４を取得する。
【００３９】
活性化モジュール１２４はＪＶＭ１２２が実行するＪＡＶＡ（登録商標）命令を含むことが好ましい。しかしモジュール１２４の代替実施例は，別の言語及び／又は技法を用いてページ１１８及び／又は活性化モジュール１２４内の命令を符号化してもよい。例えば命令及び／又は活性化モジュール１２４は，ウェブブラウザ１２０又はオペレーティングシステムに，ネイティブコード又はプラグインのいずれかとして組み込むことができる。これらの代替実施例においては，ウェブブラウザ１２０は外部情報源から活性化モジュール１２４をダウンロードする必要がない。
【００４０】
活性化モジュール１２４は，クライアント１１４がダウンロードしたページ１１８のオブジェクトＩＤを配信ネットワーク１１０に登録し，ネットワークから受信する更新メッセージに応答してライブオブジェクトを更新することが好ましい。配信ネットワーク１１０は，レジストリ１２５に登録情報を記録する。クライアントの登録情報は，クライアントが関連ページ１１８を表示している限り有効であることが好ましいが，システム１００のほかの実施例では，クライアントの登録情報をいつ終了させるかについて判定するために別の基準を用いてもよい。
【００４１】
図２は，ライブオブジェクトの特性値を更新するための，サーバ１１２と，情報プロバイダ１０８又は動的コンテンツプロバイダ１１６（一般に「入力情報源２１０”と呼ばれる）と，クライアント１１４と，配信ネットワーク１１０との間の対話を示す対話ダイアグラムである。始めにクライアント１１４は，サーバ１１２にウェブページ要求を送信する（ステップ２１２）。それに応答してサーバ１１２は，１以上のライブオブジェクトを含むか又は指定するウェブページをクライアント１１４に提供する（ステップ２１４）。ウェブページに符号化された命令は，クライアント１１４が配信ネットワーク１１０に活性化モジュール１２４を透過的に要求するようにする（ステップ２１６）ことが好ましい。これに応答して配信ネットワーク１１０は活性化モジュール１２４を送信する（ステップ２１８）。クライアント１１４は活性化モジュール１２４を実行し（ステップ２２０），活性化モジュールはクライアントにおけるライブオブジェクトのオブジェクトＩＤを識別して，配信ネットワーク１１０にオブジェクトＩＤを登録する（ステップ２２２）。配信ネットワーク１１０はクライアント１１４が登録したオブジェクトＩＤを指定するために，レジストリを更新する（ステップ２２３）。
【００４２】
クライアント１１４におけるライブオブジェクトの特性値を変更するために，ある時点で入力情報源２１０は更新メッセージを配信ネットワーク１１０へ送信する（ステップ２２４）。１つの実施例において入力情報源２１０から配信ネットワーク１１０へのメッセージは，１つのオブジェクトＩＤ及び指定されたオブジェクトの特性値に対する更新値だけを含む。もう１つの実施例においては，メッセージは複数のオブジェクトＩＤ及び対応する更新値を含む。後者の実施例においてメッセージは，メッセージが複数のオブジェクトＩＤ及び更新値を有することを指定する「バッチＩＤ」を伴うことができる。情報プロバイダ１０８はオブジェクトＩＤを含ませるのと同じ方法でページ１１８にバッチＩＤを含ませることができることが好ましい。同様にクライアント１１４は，オブジェクトＩＤと同じ方法で配信ネットワーク１１０にバッチＩＤを登録できることが好ましい。実際バッチＩＤはオブジェクトＩＤと同じであってもよく，それによってクライアント１１４は１つのＩＤを登録することによってバッチメッセージ及び非バッチメッセージ双方を登録することができる。代替として，バッチメッセージを登録するために，別個の手続を確立してもよい。クライアント１１４は，バッチの各部品メッセージを各々別個に配信されたかのように処理することが好ましい。
【００４３】
次に配信ネットワーク１１０は，指定されたオブジェクトＩＤで登録されたメッセージを，ＩＰアドレスのような標準インターネット通信プロトコルを用いて，各クライアント１１４へ配信する（ステップ２２６）ことが好ましい。クライアント１１４における活性化モジュール１２４は，メッセージを処理し，指定されたライブオブジェクトの特性値を更新する（ステップ２２８）。クライアント１１４において同一のオブジェクトＩＤを有するオブジェクトが複数の場所（例えば，クライアントにおいて表示されているウェブページ上の複数の場所）に現れたとき，活性化モジュール１２４は指定されたＩＤを有するライブオブジェクトのそれぞれを更新することが好ましい。結果として配信ネットワーク１１０は，クライアント１１４におけるライブオブジェクトが動的に更新されるようにする。この配信及び更新は，入力情報源２１０の目的に照らして「リアルタイム」とみなせるだけ十分早く行われることが好ましい。
【００４４】
図２の破線で囲んだ部分２３０に示すこの更新処理は，不定の回数繰り返すことができ，入力情報源２１０及びクライアント１１４に関して完全に非同期である。例えば入力情報源２１０は，スポーツ試合の得点が変わったとき，又は株価が変動したとき，配信ネットワーク１１０に定期的な更新メッセージを送信してもよいが，スポーツ試合が終わったとき，又は株式市場が閉じたときは更新メッセージを送信することを停止してもよい。クライアント１１４がライブオブジェクトを含むウェブページの表示を終了したとき，又はもはや更新メッセージの受信を望まないとき，クライアントは配信ネットワーク１１０とのコネクションを閉じる（ステップ２３２）ことが好ましい。次に配信ネットワーク１１０はレジストリ１２５を更新し（ステップ２３４），クライアントのオブジェクト登録を削除する。もう１つの実施例においては，クライアント１１４は配信ネットワーク１１０に，ほかのオブジェクトに属する更新メッセージを受信するためにまだコネクションを開いている１以上のオブジェクトからクライアントを選択的に登録及び／又は登録削除するメッセージを送信する。
【００４５】
図３は，配信ネットワーク１１０が実行する多対多の対応付けを図示する高レベルダイアグラムである。複数の入力情報源（２１０Ａ〜２１０Ｃ）は配信ネットワーク１１０に更新メッセージを送信する。各更新メッセージは，少なくとも１つのオブジェクトＩＤ及び指定されたオブジェクトの特性値の更新値を指定することが好ましい。次に配信ネットワーク１１０は，特定の入力情報源２１０に特定のオブジェクトＩＤを登録したクライアント１１４へ，選択的に更新メッセージを配信する。図３において，例えばクライアント３１２Ａ及び３１２Ｂが，ほかのクライアントがオブジェクトＩＤを登録していないうちに特定のオブジェクトＩＤを登録したとしよう。したがって配信ネットワーク１１０は，更新メッセージをクライアント３１２Ｃ〜３１２Ｈへではなく，クライアント３１２Ａ及び３１２Ｂに配信する。
【００４６】
図４は，動的コンテンツ配信ネットワーク１１０の能力例を示している。図４は，スポーツの得点を含む２つの別のウェブページ４１０及び４１２を示している。各ウェブページは異なる書式化がされているが，各ページは２つのプログラムフットボール試合及び２つのプロ野球試合の同じ得点を含んでいる。ウェブページ４１０は見出し「地域スポーツ得点」の下に４つのすべての試合を含んでいるが，一方ウェブページ４１２は見出し「野球の得点」の下に野球試合を，見出し「フットボールの得点」の下にフットボール試合を含んでいる。
【００４７】
ライブオブジェクトを用いてウェブページ内に試合及び得点を内部表現するさまざまな方法がある。１つの実施例においては，試合にかかわる２つのチーム及び各チームの得点の特性値を有する「ゲーム」オブジェクトが定義される。ゲームオブジェクトはウェブページ内の選択された位置に置かれ，オブジェクトの特性値が試合についての情報をページ上に表示させる。もう１つの実施例においては，「チーム」オブジェクト及び「得点」オブジェクトが定義され，チームオブジェクトはチームの名前を記述する特性値を有し，得点オブジェクトは得点を記述する特性値を有する。２番目の実施例においては，チームオブジェクト及び得点オブジェクトはページ上の選択された位置に置かれ，それによってページが描画されたときに適正なチーム及び得点が並べられる。更にもう１つの実施例においては，オブジェクトは１つのチームの名前及びそのチームの得点に対する特性値を有するように定義される。そして２つのオブジェクトが，試合及び得点を示すように適正に揃えられてページ内に置かれる。もう１つの実施例においては，２つのチームの名前を指定する特性値を有する１つのオブジェクトが定義され，２つの得点を指定する特性値を有する別のオブジェクトが定義される。最後の実施例において２つのオブジェクトはチームの名前が関連する得点と揃うようにページ内に置かれる。これらの表現のほかにも変形物が存在可能であることは明白である。
【００４８】
図４の例に対して，ある試合のチームの名前は２つのチームの名前に対する特性値を有する「名前」オブジェクトによって特定され，試合における得点は，２つの得点に対する特性値を有する「得点」オブジェクトによって特定される。ウェブページ４１０において名前オブジェクト４１４は，”ＳＦ４９ｅｒｓ”及び”ＳＴＬ  Ｒａｍｓ”を指定するように設定された特性値を有し，見出し「地域スポーツ得点」の直下にある。得点オブジェクト４１６は，試合の得点を「４２」対「７」として指定するように設定された特性値を有し，名前オブジェクト４１４のすぐ右にある。ウェブページ４１２において二番目の名前オブジェクト４１８の特性値は，少し異なる用語「ＳＦ」及び「ＳＴＬ」を用いて同じ試合を指定する。しかしながらこの名前オブジェクト４１８は，ウェブページ４１０内で使われるとき，同じ得点オブジェクト４１６と揃えられる。
【００４９】
このようにして同じ得点オブジェクト４１６が，各ウェブページ４１０及び４１２内の別の位置で用いられる。双方のウェブページ上のサンフランシスコ４９ｅｒｓ対セントルイスＲａｍｓのフットボール試合の得点を更新するために，入力情報源２１０は単に，得点オブジェクト４１６のオブジェクトＩＤ及び得点特性値の更新値を指定する更新メッセージを配信ネットワーク１１０に送信すればよい。配信ネットワーク１１０は更新メッセージを適切なクライアント１１４へ配信し，そしてクライアントは特定のページ割り付けにかかわらず，適切な得点を更新する。
【００５０】
入力情報源２１０，すなわち情報プロバイダ１０８及び／又は動的コンテンツプロバイダ１１６は，更新メッセージを生成するさまざまなツールを用いることができる。図５は，入力情報源２１０及び更新メッセージを生成するために利用可能なツールを示すブロック図である。ここに説明するものに加え，又はその代わりに，ほかのツールを利用することもできる。
【００５１】
ツールは，入力情報源２１０がメッセージを受け付けるために配信ネットワーク１１０の提供するアプリケーションプログラミングインタフェース（ＡＰＩ）を利用できるようにすることが好ましい。１つの実施例においては，入力情報源２１０が送信するメッセージは，クライアント１１４における活性化モジュール１２４用いるものと同一の形式である。代替実施例においては，配信ネットワーク１１０に提供されるメッセージは別の形式であり，配信ネットワークがメッセージを活性化モジュール１２４が用いる形式に変換する。
【００５２】
１つの実施例において入力情報源２１０はＡＰＩを利用するためにデータポンプモジュール５１０を利用する。データポンプモジュール５１０は，１以上のオブジェクトＩＤ及び指定されたオブジェクトの新しい値を含む拡張可能マーク付け言語（ＸＭＬ）ファイルを定期的に読み込み，オブジェクトの特性値への変更を表すメッセージを配信ネットワーク１１０へ送信するＡＰＩ呼出しを自動的に生成する。もう１つの実施例においては，データポンプモジュール５１０はイベント駆動型であり，ファイルの変更又はあるほかの出来事に応答してＸＭＬファイルを読み込む。
【００５３】
もう１つの実施例においては，入力情報源２１０はＡＰＩを利用するために管理者コンソールモジュール５１２を利用する。管理者コンソールモジュール５１２は，管理者にページ１１８の内容を表示する図形インタフェースを提示することが好ましい。例えば管理者は，管理者コンソール５１２を用いてウェブページ上の文字データ，画像及び／又は任意のオブジェクト，若しくはオブジェクトの特性値を編集することができる。編集後管理者は，「更新を送信する」ボタン又は類似の技法を用いて，管理者コンソールモジュール５１２がＡＰＩを介して変更されたオブジェクト及び特性値のためのメッセージを配信ネットワーク１１０に送信するようにできる。
【００５４】
もう１つの実施例においては情報プロバイダ１０８及び動的コンテンツプロバイダ１１６は，ＡＰＩを利用するためにコンテンツ管理システムモジュール５１４を用いることによって共に入力情報源２１０として機能する。コンテンツ管理システムモジュール５１４は情報プロバイダ１０８に常駐し，動的コンテンツプロバイダ１１６からオブジェクト特性値の更新を受信することが好ましい。コンテンツ管理システムモジュール５１４は，サーバ１１２に格納されているページ１１８内のライブオブジェクトの特性値を更新し，また変更された特性値のためのメッセージを配信ネットワーク１１０に送信することが好ましい。この方法によってサーバ１１２におけるページ１１８及びクライアント１１４において表示されているウェブページは，ほとんど同時に更新される。１つの実施例において動的コンテンツプロバイダ１１６は，情報プロバイダ１０８の代わりに配信ネットワーク１１０に更新メッセージを送信する。またシステム１００の実施襟は，ここに記載したコンテンツ管理技法のどの組合せを用いてもよい。
【００５５】
例えば上記のツールは，得点オブジェクトが表示させたテキストを「２」に更新するために，次に示すコードを有するメッセージを生成することができる。
LiveObject score = new LiveObject("Bang$homeScoreID");
score.setProperty("innerText", "2")
このコードは，オブジェクトＩＤ"Bang$homeScoreID"を有するオブジェクトの"innerText"特性値を２に設定する。ツールはＡＰＩを用いてこのメッセージを配信ネットワーク１１０へ回送する。
【００５６】
ここでクライアント１１４において実行される操作に移る。図６は，活性化モジュール１２４の実施例によって実行されるステップを示すフローチャートである。当業者であれば，別の実施例は図６のステップを別の順序で実行できることを認識するであろう。一般に活性化モジュール１２４は，３つの機能を実行する。オブジェクトＩＤを配信ネットワーク１１０に登録する機能と，ライブオブジェクトの特性値を更新するために，ネットワークからクライアント１１４が受信したメッセージを処理する機能と，クライアントとネットワークとの間の通信を制御する機能とである。
【００５７】
オブジェクトＩＤを登録するために，活性化モジュール１２４はサーバ１１２から受信したページ１１８をパースし（ステップ６１０），ライブオブジェクトのオブジェクトＩＤを指定することが好ましい。代替実施例においては，活性化モジュール１２４はウェブブラウザ１２０が現在表示しているライブオブジェクトだけのＩＤのような，オブジェクトＩＤのサブセットだけを指定する。代替として，オブジェクト自身に加えてオブジェクトＩＤのリストをウェブページ内にあらかじめ符号化しておき，それによって活性化モジュール１２４が容易に指定できるようにしてもよい。更にもう１つの実施例においては，クライアント１１４のユーザが登録するオブジェクトＩＤを選択する。
【００５８】
活性化モジュール１２４は，クライアント１１４と配信ネットワーク１１０との間のコネクションを開く（ステップ６１２）ことが好ましい。活性化モジュールがページ１１８を受信及び／又はパースする前，又はした後，活性化モジュール１２４はこのコネクションを開くことができる（ステップ６１２）。いくつかの場合にクライアント１１４は，クライアントが要求できるコネクションの種別について制限を設けるファイヤウォールの後ろに位置する。例えばファイヤウォールは，すべてのＨＴＴＰでないトラヒックを阻止するかもしれない。このために活性化モジュール１２４は，ファイヤウォールを通じて配信ネットワーク１１０に要求を送信するために，ＨＴＴＰヘッダ内にコネクション要求を包み込むことが好ましい。
【００５９】
活性化モジュール１２４はクライアント１１４と配信ネットワーク１１０との間のコネクションを用い，指定されたオブジェクトＩＤを含むベクトル（例えばリスト又は配列）を配信ネットワーク１１０へ送ることによってオブジェクトＩＤを登録する（ステップ６１４）。ファイヤウォールを通じてこの処理を達成するために，活性化モジュール１２４はベクトルを「オブジェクトデータ」と呼ばれる文字列に入れ，そしてオブジェクトデータを配信ネットワーク１１０へ送るためにＨＴＴＰメッセージを生成することが好ましい。概略の例は次のとおりである。
ＰＯＳＴ／ＨＴＴＰ／１．１＼ｒ＼ｎ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：＜オブジェクトデータ長＞＼ｒ＼ｎ
＼ｒ＼ｎ
＜オブジェクトデータ＞
ここで＜オブジェクトデータ＞は，オブジェクトＩＤのリストである。配信ネットワーク１１０がそのようなＨＴＴＰ要求を受信すると，オブジェクトデータを抽出し，レジストリ１２５を更新して，クライアント１１４が指定されたオブジェクトを登録すたことを示す。
【００６０】
ウェブブラウザ１２０が新しいページをロードしたとき（ステップ６１６），又はそうではなく最初のページ上のオブジェクトの表示を終了したとき，最初のページに関連した活性化モジュール１２４はクライアントと配信ネットワーク１１０との間のコネクションを終了する（ステップ６１８）ことが好ましい。当業者であれば，この終了（ステップ６１８）が図６に示したほかのステップとは非同期に起きることがあることを認識するであろう。したがってステップ６１６及び６１８の位置は，終了が起きることがある一連のステップにおける１つの可能性のある位置を表すに過ぎない。
【００６１】
コネクションが終了しないときは，活性化モジュール１２４はオブジェクトＩＤ及び指定されたオブジェクトの特性値の更新値を指定したメッセージを配信ネットワーク１１０から受信する（ステップ６１８）まで待機することが好ましい。１つの実施例においては，このメッセージはＨＴＴＰデータとして受信される。メッセージを受信すると活性化モジュール１２４は，ＨＴＴＰデータからオブジェクトＩＤ及び更新値を抽出する（ステップ６２０）。次に活性化モジュール１２４はメッセージが指定するとおりに指定されたオブジェクトの特性値を更新し（ステップ６２２），又はオブジェクトを更新する。
【００６２】
メッセージの受信（ステップ６１８）と，データの抽出（ステップ６２０）と，オブジェクトの更新（ステップ６２２）との連鎖は，新しいページがロードされる（ステップ６１６）か，又はそうではなく配信ネットワーク１１０とのコネクションが終了するまで繰り返されることが好ましい。図６には示していないが，ページ１１８に関してユーザの操作が新しいライブオブジェクトを活性化するときのようなある状況においては，活性化モジュール１２４は，始めに新しいページをダウンロードし，パースすることなく配信ネットワーク１１０に新しいオブジェクトＩＤを登録してもよい。１つの実施例においては，新たにロードされたページがライブオブジェクトを含むとき，図６に示すように活性化モジュール１２４をダウンロードする処理及びオブジェクトを更新する処理が繰りかえされる。代替実施例においては，活性化モジュール１２４はクライアント１１４において活性のままであり，したがってクライアントは配信ネットワーク１１０から活性化モジュールを再ダウンロードしない。その代わりに既に存在する活性化モジュール１２４が新しいページ上のライブを可能にする処理を実行する。
【００６３】
図７は，本発明の実施例による配信ネットワーク１１０の低レベルの様子を示すブロック図である。当業者であれば，配信ネットワーク１１０の機能を実装する多くの代替方法があることを認識するであろう。図７は，情報プロバイダ７１０Ａ及び動的コンテンツプロバイダ７１０Ｂのような配信ネットワーク１１０にメッセージを提供する情報源を表す複数の入力情報源（７１０Ａ〜７１０Ｄ）を示している。また図７は，任意の時点で配信ネットワーク１１０と通信している多くのクライアントを表す複数のクライアント（７１２Ａ〜７１２Ｆ）も示している。
【００６４】
配信ネットワーク１１０は，内部的に１以上のクラスタ７１４に分割されていることが好ましい。図７において配信ネットワーク１１０は，３つのクラスタ７１４Ａ，７１４Ｂ，７１４Ｃを含むが，クラスタ数はネットワークの処理要望に応じて変えてもよい。入力側全体ロードバランサ７１６は，入力情報源７１０からクラスタ７１４へメッセージを配信することが好ましい。類似してクライアント側全体ロードバランサ７１８は，クライアント７１２からクラスタ７１４へのコネクション要求を配信することが好ましい。ロードバランサ７１６及び７１８は，所定のヒューリスティックによって負荷が各クラスタ７１４に分配されることを保証するように設計されている。例えば負荷を各クラスタ７１４に均等に分配してもよいし，より高性能なクラスタに大部分の負荷を分配してもよい。１つの実施例においては１つのロードバランサが入力側７１６ロードバランサ及び出力側７１８ロードバランサの機能を実行し，通常のドメイン名システム（ＤＮＳ）に基づく負荷バランス法を利用する。
【００６５】
クラスタ７１４Ａを代表とする各クラスタ７１４は，入力側クラスタロードバランサ７２０Ａ及びクライアント側ロードバランサ７２２Ａを含むことが好ましい。クラスタロードバランサ７２０Ａ及び７２２Ａは，対応する全体ロードバランサ７１６及び７１８に類似して機能する。すなわち入力側クラスタロードバランサ７２０Ａは，着信メッセージを１以上の各ゲートウェイ７２４Ａに振り分けて配信し，そしてクライアント側クラスタロードバランサ７２２Ａは，着信コネクション要求を１以上の各ノード７２６Ａ及び各アプリケーションサーバ７２８Ａに振り分けて配信する。
【００６６】
１つの実施例においては，２つのクライアント側クラスタロードバランサ７２０Ａ及び７２２Ａの機能は，１つのコンポーネントで提供される。この単一コンポーネントロードバランサは始めに，着信要求がメッセージをゲートウェイ７２４Ａに送信しようとしている入力情報源７１０からのものか，ノード７２６Ａへのコネクションを求めているクライアント７１２からのものか，又はアプリケーションサーバ７２８Ａへのコネクションを求めているクライアントからのものかを判定する。次にロードバランサはメッセージ又はコネクション要求を，クラスタ７１４内のゲートウェイ７２４Ａと，ノード７２６Ａと，アプリケーションサーバ７２８Ａとに配信する。１つの実施例においては，単一コンポーネントロードバランサは第７層負荷バランス（すなわちアプリケーション層における負荷バランス）を提供する。ノード７２６Ａ及びアプリケーションサーバ７２８Ａのための負荷バランスは，セキュリティのためにほとんどのクライアントウェブブラウザが，アプリケーション（例えば活性化モジュール１２４）にそれがダウンロードされた場所にだけ透過的に接続することを許可するので，同一のコンポーネントで実行することが好ましい。
【００６７】
配信ネットワーク１１０の代替実施例においては，全体ロードバランサ７１６及び７１８，並びにクラスタロードバランサ７２０Ａ及び７２２Ａを結合してもよいし，及び／又はロードバランサの機能をクラスタ７１４の内部又は外部の別のコンポーネントに組み込んでもよい。更に代替実施例はこれらロードバランサのうち１以上を省略してもよい。例えば別のクラスタ７１４が別の顧客にサービスする場合は，全体ロードバランサ７１６及び７１８の必要性がなくなる。
【００６８】
クラスタ７１４内のゲートウェイ７２４Ａは入力情報源７１０からメッセージを受信して適切なノード７２６Ａへメッセージを振り向ける。１つの実施例においては各ゲートウェイ７２４Ａが各クラスタ７１４内の各ノード７２６へ永続的なＴＣＰコネクションを維持し，各メッセージを各ノードへ振り向ける。したがってゲートウェイ７２４Ａはクラスタ７１４Ａ内にあり，入力側クラスタロードバランサ７２０Ａを介してコネクションを受信するが，ゲートウェイの対象範囲は全体の配信ネットワーク１１０にわたる。この広い対象範囲によって，任意の入力情報源からのメッセージが任意のクライアント７１２へ配信できる。
【００６９】
配信ネットワーク１１０の代替実施例においては，各ゲートウェイ７２４が同一のクラスタ７１４内のすべてのノード７２６へ永続的なＴＣＰコネクションを維持し，かつほかの各クラスタ内の少なくとも１つのゲートウェイに少なくとも１つのコネクションを維持する。この実施例は，各ゲートウェイ７２４が同時に維持するＴＣＰコネクションの数を減少させる。もう１つの代替実施例においては，各クラスタ７１４はまた，ほかのクラスタのゲートウェイ７２４とのコネクションを維持するゲートキーパ（図７には示していない）も含む。ゲートウェイ７２４はメッセージをゲートキーパに転送し，ゲートキーパは次にメッセージをほかのクラスタ７１４の各ゲートウェイに配信する。
【００７０】
ゲートウェイ７２４は入力情報源７１０からメッセージを受信する速度を制御しないので，ゲートウェイは処理できる（すなわちメッセージをノードに送信する）速度より速くメッセージを受信する可能性がある。したがって各ゲートウェイ７２４は，メッセージを失わないように受信してまだ処理していないメッセージの待ち行列７３０を維持することが好ましい。１つの実施例においては，待ち行列７３０が長すぎるようになると，ゲートウェイ７２４はメッセージを廃棄する。もう１つの実施例においてはゲートウェイ７２４はどのメッセージを廃棄するかを判定するためにあるメッセージ又は入力情報源に指定された優先度を利用する。
【００７１】
ノード７２６は，ゲートウェイ７２４から受信したメッセージを，そのメッセージによって指定されるオブジェクトＩＤで登録されているクライアント７１２へ送信することが好ましい。メッセージが指定するオブジェクトＩＤで登録されているクライアント７１２がないときは，ノードはメッセージを無視することが好ましい。ノード７２６は，そのノードに接続されているクライアント７１２が登録したオブジェクトＩＤを含むハッシュテーブル７３２として，レジストリ１２５のインスタンスを維持することが好ましい。１つの実施例においては，ハッシュテーブル７３２は各オブジェクトＩＤをリンクされたリストと関連付け，リストはそのオブジェクトＩＤで登録されているクライアント７１２ごとに１つの項目を含む。リンクされたリスト内の各項目は，対応するクライアント７１２へのコネクションを表すソケットへのポインタを含むことが好ましい。本技術においては周知のとおり，ソケットへのポインタは典型的には「ファイルディスクリプタ」と呼ばれ，ノードが対応するクライアントにメッセージを送信するために用いることができるアドレスを表す。ノード７２６は，クライアント７１２がオブジェクトへの興味を登録するたびに，ハッシュテーブル７３２及び／又はリンクされたリストに項目を加え，クライアントがノードとのコネクションを切断したか，又は特定のオブジェクトにもはや興味がなくなったことを示したとき，ハッシュテーブル及び／又はリンクされたリストから対応する項目を削除する。
【００７２】
本発明の代替実施例は，ハッシュテーブル７３２及びリンクされたリストに加えて，又はその代わりにほかのデータ構造を利用し，及び／又はデータ構造内の別のデータを用いる。例えば配信ネットワーク１１０の１つの実施例は，各クラスタ７１４内にノードの階層を備える。階層内のさまざまなノードがある入力情報源２１０から受信したメッセージを処理してもよいし，又はさまざまなクライアント７１２へ送信するメッセージを処理してもよい。この実施例においては，リンクされたリストはクライアント７１２へつながるソケットの代わりに，階層内の低位のノードを指してもよい。もう１つの実施例はノード階層がないが，それにもかかわらずあるノードをある入力情報源２１０又はクライアント７１２に指定する。
【００７３】
各クラスタ７１４内のアプリケーションサーバ７２８は，クライアントからの要求に応答してクライアント７１２に活性化モジュール１２４を提供することが好ましい。更にアプリケーションサーバ７２８は，環境１００を維持するために必要な，又は望まれるかもしれない任意のほかのモジュールを提供する。配信ネットワークの代替実施例においては，１つのアプリケーションサーバ７２８がすべてのクライアントからの要求に対応する。このアプリケーションサーバ７２８は，あるクラスタ７１４内にあってもよいし，又はクラスタとは独立に存在してもよい。しかしながら単一アプリケーションサーバの実施例は，冗長性に欠けるため，望ましくない。
【００７４】
配信ネットワーク１１０は，Ｌｉｎｕｘ（登録商標）オペレーティングシステム（ＯＳ）を実行する通常の単一プロセッサ計算機システムを利用することが好ましい。配信ネットワーク１１０の各コンポーネントは，それらコンポーネントの別個の最適化を可能にするために，別個の専用計算機システムによって実装することが好ましい。ＯＳの入出力（Ｉ／Ｏ）機能は，カリフォルニア州バークレイのカリフォルニア大学から得ることができるＮＢＩＯのような非停止ＯＳパッケージを利用することによって強化することが好ましい。ノード７２６とのコネクションは長く続くとの仮定に基づいて，ＯＳは動作していないコネクションの監視にリソースを割り当てないように構成することが好ましい。その代わり高度なソケットポーリング能力を提供するために，ＯＳによく知られた/dev/pollパッチを施すことが好ましい。
【００７５】
更にＯＳ内のＴＣＰ／ＩＰスタックは，素早くメッセージを出力するために最適化することが好ましい。１つの実施例においては，スタック内の再送信タイマを２００ｍｓから５０ｍｓに減少させる。このタイマは，スタックが送信したパケットが受信されたことを示す肯定応答（ａｃｋ）をどれだけ待つかを決める。Ｌｉｎｕｘ（登録商標）カーネルの再送信タイマ実装によって，カーネルは（たとえａｃｋが受信されても）最初の再送信タイマが時間切れになるまで，待機させている発信パケットを送信しない。再送信タイマ値を減少させることによって，この遅延の影響を最小化することができる。再送信タイマが時間切れになる前にａｃｋが受信されなかったときは，本発明の実施例は影響を受けたＴＣＰコネクションの再送信タイマ値を増加させて，肯定応答されなかったパケットを再送信する。更にＴＣＰ／ＩＰスタックは，Ｎａｇｌｅアルゴリズムを用いていくつかの小さなメッセージをより長いメッセージに連結し，それによって配信ネットワーク１１０が送信するパケット数を減少させることが好ましい。
【００７６】
図８は，クラスタ７１４内のノード７２６が，ゲートウェイ７２４を介して入力情報源から受信したメッセージのオブジェクトに基づく配信を行うために実行するステップを示すフローチャートである。始めにノード７２６が入力情報源７１０からメッセージを受信する（ステップ８１０）。ノード７２６はメッセージからオブジェクトＩＤを抽出する（ステップ８１２）。更にノード７２６は選択的に，入力情報源７１０が利用する形式からクライアント７１２における活性化モジュール１２４が用いる形式に，メッセージを変換する（ステップ８１４）。上述のように１つの実施例においては，入力情報源７１０が用いるメッセージ形式は，活性化モジュール１２４が用いるメッセージ形式と同一である。したがってこの実施例においては，ノード７２６はメッセージを変換する必要がない。入力情報源７１０と活性化モジュール１２４とが別々のメッセージ形式を用いる代替実施例においては，ノード７２６はメッセージを変換することが好ましい。ノード７２６は，メッセージが参照するオブジェクトを登録したクライアント７１２のリンクされたリストを判定するために，抽出されたオブジェクト及び情報プロバイダＩＤに対応するハッシュテーブルの項目を参照する（ステップ８１６）。最後にノード７２６は，登録されたクライアント７１２それぞれにメッセージを送信する（ステップ８１８）。代替実施例においては，ノード７２６は選択的に，前とは反対にハッシュテーブル内の登録されたクライアントを参照した後にメッセージを変換する。後段でメッセージを変換することによって，ノード７２６は登録されたクライアント７１２の特定の要求条件に従ってメッセージを変換することができる。
【００７７】
動的コンテンツ配信ネットワークを用いた個別コンテンツの配信
図９は，１つの実施例によるページ１１８の例を示す図である。１つの実施例においてはページ１１８はウェブページであってよい。ほかの実施例においてはページ１１８はワープロ，表計算，電子メールなどのようなソフトウェアアプリケーションで生成されたどのようなページであってもよい。図示されているようにページ１１８は，市場データセクション９０２−１と，ニュース見出しセクション９０２−２と，最近行った取り引きセクション９０２−３と，口座収支セクション９０２−４と，のような複数のセクション９０２を含む。これらのセクションが示されているが，ページ１１８には任意の数のセクションを表示してもよいことが理解されるであろう。
【００７８】
１つの実施例においては，ページ１１８はウェブベースアプリケーションによって提供できる。配信ネットワーク１１０を用いて，多くのクライアント１１４に株及び債権の購入価格を配信することができる。各クライアントのページ１１８は，同一のセクション９０２を含んでもよいが，あるセクション９０２の情報は，ユーザごとに個別（例えば別内容）であってもよい。例えば市場データセクション９０２−１は，すべてのユーザに同一であってもよい。しかしながら最近の取引セクション９０２−３及び口座収支セクション９０２−４は，ユーザごとに個別化されていてもよい。例えば特定ユーザが行った最近の取引及びそれらの口座収支はユーザ個別であってもよく，また特定ユーザだけに送信してもよい。したがって個別情報は，ユーザに特定のどのような情報であってもよい。別々のユーザがおおむね同一の個別情報を有してもよいが，ユーザごとの個別情報は，ユーザごとに特定になることを理解されたい。
【００７９】
１つの実施例においては，特定ユーザの取引が終わったとき，自分のページ１１８だけが（例えば最近の取引セクション９０２−３の配下で）更新されることが望ましい。したがって個別情報は，このユーザだけに送られることが望ましい。
【００８０】
１つの実施例においては，セクション９０２に対して別のコンテンツが別の入力情報源２１０によって配信されてもよい。例えばある入力情報源２１０がニュース見出しセクション９０２−２にコンテンツを提供し，もう１つの入力情報源２１０が市場データセクション９０２−１にコンテンツを提供してもよい。更にリアルタイムデータを複数の入力情報源２１０が提供してもよい。入力情報源２１０は配信ネットワーク１１０及びクライアント１１４から離れたところにあってもよいし，又は別の実施例においては配信ネットワークの一部であってもよい。
【００８１】
ページ１１８に送信されるリアルタイム情報は，配信ネットワーク１１０を用いて配信することができる。１つの実施例においては各株９０４にＩＤを付与し，そのＩＤに対して発行されたメッセージは，すべてのユーザに配信してもよい。次にライブオブジェクトを更新してもよい。ライブオブジェクトは，更新できるどのようなデータであってもよい。例えばライブオブジェクトは，ページ１１８などの上に表示されるページ１１８の要素を表示するためのソフトウェアコードのようなページ１１８のデータ表現に含まれるどのようなデータであってもよい。共通の情報に加えて個別情報を，最近の取引セクション９０２−３及び口座収支セクション９０２−４に配信してもよい。更に共通情報と個別情報との組合せをセクションに送信してもよい。例えば共通及び個別情報をニュース見出しセクション９０２−２に配信してもよい。
【００８２】
１つの実施例においては，ユーザに個別メッセージを配信するために，配信ネットワーク１１０のバッチ能力を用いてもよい。この実施例においては，各ユーザに個別ＩＤを付与することができる。個別ＩＤはユーザに対して唯一又は特定であってもよい。また以降に述べるように，個別ＩＤはユーザグループに特定であって１人のユーザだけに対してでなくてもよい。個別ＩＤは，（ページ１１８のソフトウェアコードのｂｏｄｙタグ内のように）ページ１１８のデータ表現内のどこに置いてもよい。次にデータ表現内のライブオブジェクトは共通ＩＤと関連付けることができる。ライブオブジェクトはページ１１８内で見付けることができ，個別情報をライブオブジェクトに対して表示してもよい。共通ＩＤは，複数のユーザに対して同一であってもよい。例えばウェブベースアプリケーションの最近の取引セクション９０２−３は，ＩＤ，”最近の取引ＩＤ”でしるしを付けてもよい。このＩＤは，たとえ個別情報がユーザごとに表示されても，すべてのユーザのページ１１８に対して同一であってよい。
【００８３】
１つの実施例において入力情報源２１０は，次に示す形式を用いてバッチメッセージを提供する。
［個別ＩＤ，（共通ＩＤ＃１，”個別情報＃１”），（共通ＩＤ＃２，”個別情報＃２”）］
個別ＩＤはユーザに個別化されたＩＤであってよい。共通ＩＤ＃１及び共通ＩＤ＃２は，多くのユーザに共通のＩＤであってよい。個別情報＃１及び個別情報＃２は，ページを更新するために用いることができるどのような情報であってもよい。１つの実施例においては，口座収支のためのメッセージは次のメッセージを用いて上述のバッチメッセージで送信することができる。
［個別ＩＤ，（口座収支ＩＤ，”収支情報”），・・・］
このメッセージはユーザの口座の口座収支をユーザの個別除法で更新するために用いることができる。
【００８４】
配信ネットワーク１１０は，個別ＩＤで登録されているユーザにバッチメッセージを配信する。ユーザのクライアント１１４にバッチメッセージが着信すると，メッセージ（共通ＩＤ＃１，”個別情報＃１”）及び（共通ＩＤ＃２，”個別情報＃２”）がクライアント１１４に送信されたかのように取り扱うことができる。個別ＩＤは，メッセージが受信された後は用いることができない。
【００８５】
１つの実施例においてクライアント１１４のブラウザは，ページ１１８のデータ表現を評価してＩＤ，共通ＩＤ＃１及び共通ＩＤ＃２を見付ける。ページ１１８上のライブオブジェクトは，個別情報＃１及び個別情報＃２で更新することができる。情報プロバイダは，ユーザのページ１１８の構造を知ったり，又は理解したりする必要はない。また更新メッセージはＤＯＭ情報を含むことができないので，メッセージ自身は単純である。例えばメッセージの１つが（口座収支ＩＤ，”収支情報”）であったとき，クライアントのブラウザは更新メッセージ（すなわち更新メッセージの”収支情報”）で指定されたとおりの情報で口座収支セクション９０２−４を更新することができる。
【００８６】
このようにして複数のユーザの個別情報は，複数のユーザのページ１１８上に含まれるライブオブジェクトを更新するために用いることができる共通ＩＤ宛に送信することができる。個別ＩＤは，上述のバッチメッセージ技法を用いてユーザに個別情報を送信するために用いてもよい。ライブオブジェクトは同一のＩＤを有することができるので，入力情報源２１０は複数の個別メッセージをライブオブジェクトの同一の共通ＩＤ宛に配信することができる。これによって用いるＩＤ数を減少させることができる。
【００８７】
図１０は，１つの実施例によって配信ネットワーク１１０を用いて個別メッセージを配信するためのシステム１０００を示す図である。システム１０００は，複数のクライアント１１４と，配信ネットワーク１１０と，入力情報源２１０とを含む。
【００８８】
入力情報源２１０は，配信ネットワーク１１０のバッチ能力を用いて個別メッセージを送信することができるものであってよい。図示したとおり，３つのバッチメッセージ，メッセージ＃１と，メッセージ＃２と，メッセージ＃３とが入力情報源２１０によって送信できる。メッセージ＃１と，メッセージ＃２と，メッセージ＃３とは，３つの別の個別ＩＤ，個別ＩＤ＃１と，個別ＩＤ＃２と，個別ＩＤ＃３とに宛てて送信できる。バッチメッセージは，共通ＩＤ，最近の取引ＩＤ及び口座収支ＩＤを用いて送信されたメッセージを含む。しかし個別情報は，別のユーザのＩＤ，最近の取引ＩＤ及び口座収支ＩＤを有する各メッセージに含めることができる。
【００８９】
３つのメッセージは入力情報源２１０から配信ネットワーク１１０へ送信することができる。配信ネットワーク１１０は，どのクライアント１１４が個別ＩＤを登録したかを判定する。図示したとおりクライアント１１４−１は個別ＩＤ＃１を登録し，クライアント１１４−２は個別ＩＤ＃２を登録し，クライアント１１４−３は個別ＩＤ＃３を登録している。したがってクライアント１１４−１（又はそのユーザ）が個別ＩＤ＃１を登録しているので，メッセージ＃１をクライアント１１４−１に送信することができる。更に，クライアント１１４−２及び１１４−３が対応する個別ＩＤ＃２及び＃３をそれぞれ登録しているので，メッセージ＃２及びメッセージ＃３をクライアント１１４−２及び１１４−３に送信することができる。次にクライアント１１４−１と，１１４−２と，１１４−３とはそれらのページ１１８をＩＤ，最近の取引ＩＤ及び口座収支ＩＤに対して提供された情報で更新することができる。図示したとおり，クライアント１１４−１は個別取引情報＃１及び個別収支情報＃１を表示し，クライアント１１４−２は個別取引情報＃２及び個別収支情報＃３を表示し，クライアント１１４−３は個別取引情報＃３及び個別収支情報＃３を表示している。
【００９０】
したがって共通ＩＤ，最近の取引ＩＤ宛の情報を有する３つのメッセージを送信することができる。しかしバッチメッセージを用いることによって，メッセージを３つの別のクライアント１１４へ送信することができる。このようにしてクライアント１１４は，共通ＩＤ宛の個別情報を受信することができる。
【００９１】
図１１は，１つの実施例によるバッチメッセージを生成するための簡易化されたフローチャート１１００を示す。ステップ１１０２において，入力情報源２１０はユーザの個別情報を判定する。
【００９２】
ステップ１１０４において，個別情報のための個別ＩＤ及び共通ＩＤを判定することができる。１つの実施例において入力情報源２１０は，ユーザ宛の個別情報をどこへ又はどうやって送信するかを知る必要がない。そうではなく入力情報源２１０は，個別情報を共通ＩＤと関連付け，個別ＩＤ宛に送信できるバッチメッセージを生成することができる。
【００９３】
ステップ１１０６において，個別ＩＤを有するバッチメッセージを配信ネットワーク１１０へ送信することができる。バッチメッセージは，上述のとおりの形式で，又は任意のほかの形式で送信することができる。したがって入力情報源２１０はバッチメッセージを個別ＩＤ宛に送信することができる。入力情報源２１０は，ユーザ宛の個別情報をどうやって又はどこへ配信するかを判定する必要はない。そうではなく配信ネットワーク１１０は，バッチメッセージは以降に説明するとおり配信することができる。
【００９４】
図１２は，１つの実施例によってバッチメッセージをクライアント１１４へ配信する方法の簡略化したフローチャート１２００を示す。ステップ１２０２においてバッチメッセージが入力情報源２１０から受信できる。ステップ１２０４においてクライアント１１４は，バッチメッセージ内に見つかった個別ＩＤが登録されているかどうかを判定する。１つの実施例においては，クライアント１１４は活性化モジュール１２４をダウンロードし，ＩＤを配信ネットワーク１１０に登録することができる。この処理は前に詳細に説明されている。ステップ１２０６において，個別ＩＤ宛のバッチメッセージが入力情報源２１０から受信されると，配信ネットワーク１１０はバッチメッセージを個別ＩＤを用いてクライアント１１４へ配信することができる。
【００９５】
図１３は，１つの実施例によってクライアント１１４においてバッチメッセージを処理する方法の簡略化したフローチャート１３００を示す。ステップ１３０２において，バッチメッセージが配信ネットワーク１１０から受信できる。バッチメッセージは個別ＩＤ宛に振り向けられ，個別ＩＤに関連付けられた好み設定によって配信することができる。例えば個別ＩＤはＩＰアドレスと関連付けることができ，メッセージはＩＰアドレスに対応するクライアント１１４で受信できる。
【００９６】
ステップ１３０４において，バッチメッセージ内の共通ＩＤが判定できる。この共通ＩＤは複数のユーザのページ１１８上で見つかるものと同一のＩＤであってもよい。
【００９７】
ステップ１３０６において，共通ＩＤ宛の個別情報が判定できる。例えば個別情報は，個別情報であってもよいし，またクライアント１１４に特定のものであってもよい。
【００９８】
ステップ１３０８において，ライブオブジェクトを共通ＩＤを用いて個別情報で更新することができる。例えばクライアント１１４は，共通ＩＤに関連付けることができるページ１１８上のライブオブジェクトを判定することができる。ライブオブジェクトの特性値は，個別情報で更新することができる。
【００９９】
例えば図９を参照すると，ライブオブジェクトはページ１１８の最近の取引セクション９０２−３で見付けることができる。最近の取引ＩＤはページ１１８のデータ表現内に含めることができる。このようにしてクライアント１１４は，場所に対応する個別情報を，ページ１１８のデータ表現内のＩＤ，最近の取引ＩＤで参照されるとおりに表示する。したがって配信ネットワーク１１０又は入力情報源２１０は，ユーザのページ１１８の構造又はＤＯＭを理解する必要がない。クライアント１１４は，最近の取引セクション９０２−３を，最近の取引ＩＤの個別情報が指定するとおりに更新できるものであってよい。
【０１００】
また同一の共通ＩＤは，ページ１１８のニュース見出しセクション９０２−２のように，いくつかのメッセージが広範な聴衆に向けられ（例えば個人的ではない），ほかは個別である場合にも用いることができる。例えば入力情報源２１０はユーザに，共通ＩＤと，
＜ニュース見出しＩＤ＞，＜”ニュース見出し情報”＞
のようなメッセージとを用いて標準の見出しを送信することができ，また，
［＜個別ＩＤ＞，（＜ニュース見出しＩＤ＞，＜”個別ニュース見出し情報”＞）
のようなバッチメッセージを用いて個別メッセージを送信することができる。第１のメッセージは，ＩＤ，ニュース見出しＩＤを申し込んでいるどのユーザにもニュース見出し情報を送信することができ，二番目のメッセージは，個別ＩＤと関連付けられたユーザに個別のニュース見出し情報を送信することができる。したがって，同一の共通ＩＤを，すべてのユーザへ送信することができる標準見出しを送信するために用いることができる。また共通ＩＤは，バッチメッセージをユーザの個別ＩＤへ送信することによって，個別ＩＤとしても用いることができる。個別見出しは，個別ＩＤに関連付けられたユーザに送信することができる。情報プロバイダ２１０は共通ＩＤに対して標準見出しと個別見出しとを相互に切り替えることができる。
【０１０１】
またバッチメッセージは，準個別メッセージ，すなわち個人ではなくグループに宛てたメッセージを送信するためにも用いることができる。ちょうど個人ユーザが自分のページ１１８上のどこかに個別ＩＤと関連付けられたライブオブジェクトを有することができるように，グループのメンバは，彼らのページ１１８上に位置するグループの個別ＩＤのためのライブオブジェクトを有することができる。ユーザのグループにページ１１８のニュース見出しセクション９０２−２内のメッセージを送信するために，情報プロバイダ２１４はグループの個別ＩＤ宛に送信される次のようなバッチメッセージを用いることができる。
［＜グループ個別ＩＤ＞，（＜ニュース見出しＩＤ＞，＜”個別グループ見出し情報”＞）］
このメッセージはグループ個別ＩＤと関連付けることができるので，グループのすべての（及び唯一の）メンバがこのメッセージを受信することができる。この技法は，グループのメンバが同一のページを見ていることを必要としない。そうではなくグループのメンバは，所望のどのような方法でもニュース見出しＩＤの情報を表示できる。
【０１０２】
したがってバッチメッセージは，共通ＩＤと関連付けることができる個別情報を送信するために用いることができる。しかしバッチメッセージは，ユーザに特定の個別ＩＤに送信することができる。したがってコンテンツプロバイダ２１４が用いるＩＤ数を最小化することができる。しかし個別メッセージを送信する能力は，個別ＩＤを用いることによって依然維持できる。
【０１０３】
１つの実施例においては，「及び／又は（and/or）」で接続された要素の任意の組合せを示すことができる用語「及び／又は」を用いることがある。例えば「及び／又は」を用いる句の中の２つの語又は表現は，一つ，又は他方，又は双方を意味することができる。１つの実施例においては，用語「おおむね（substantially）」は大部分であるが指定された全体ではない，又は指定された全部を意味することができる。１つの実施例においては，用語「できる（capable of）」は構成された，適応した，能力がある，などを意味することができる。例えば，「操作を実行することができる」は，要素が操作を実行するように構成された，及び／又は操作を実行するように適応させた，を意味することができる。
【０１０４】
本開示の実施例は，ソフトウェア，又はハードウェア，又は双方の組合せによる制御論理の形態で実装することができる。制御論理は，１つの実施例において開示された一組のステップを実行するように情報処理デバイスに指示するようになっている複数の命令として，情報記憶媒体に記憶することができる。ここに示した開示及び教示に基づいて，本技術の当業者であれば本開示を実装するほかのやり方及び／又は方法を認識するであろう。
【０１０５】
上述の説明は例示であって，制限ではない。本開示をレビューすれば，当業者には本開示の多くの変形物が明白になるであろう。したがって本発明の範囲は，上述の説明を参照して判定するのではなく，代わりに本願の特許請求の範囲の全範囲又はその均等物を参照して判定することが望ましい。
【図面の簡単な説明】
【０１０６】
【図１】動的コンテンツ配信ネットワークを含む環境を示す高レベルのブロック図である。
【図２】ウェブページ上のライブオブジェクトの特性値を更新するための，サーバと，情報プロバイダと，動的コンテンツプロバイダと，クライアントと，配信ネットワークとの間の対話を示す対話ダイアグラムである。
【図３】配信ネットワークが実行する多対多の対応付けを図示する高レベルのブロック図である。
【図４】スポーツの得点を含む２つの別のウェブページを示す図である。
【図５】入力情報源及び更新メッセージを生成するために利用可能なツールを示すブロック図である。
【図６】活性化モジュールの実施例によって実行されるステップを示すフローチャートである。
【図７】本発明の実施例による配信ネットワークの低レベルの様子を示すブロック図である。
【図８】クラスタ内のノードが，ゲートウェイを介して入力情報源から受信したメッセージのオブジェクトに基づく配信を行うために実行するステップを示すフローチャートである。
【図９】１つの実施例によるウェブページの例を示す図である。
【図１０】１つの実施例によって配信ネットワーク１１０を用いて個別メッセージを配信するためのシステムを示す図である。
【図１１】１つの実施例によるバッチメッセージを生成するための簡易化されたフローチャートである。
【図１２】１つの実施例によってバッチメッセージをクライアントへ配信する方法の簡略化したフローチャートである。
【図１３】１つの実施例によってクライアントにおいてバッチメッセージを処理する方法の簡略化したフローチャートである。
【図１】
2008515032.tif 000003
【図２】
2008515032.tif 000004
【図３】
2008515032.tif 000005
【図４】
2008515032.tif 000006
【図５】
2008515032.tif 000007
【図６】
2008515032.tif 000008
【図７】
2008515032.tif 000009
【図８】
2008515032.tif 000010
【図９】
2008515032.tif 000011
【図１０】
2008515032.tif 000012
【図１１】
2008515032.tif 000013
【図１２】
2008515032.tif 000014
【図１３】
2008515032.tif 000015
【国際調査報告】
2008515032.tif 000016
2008515032.tif 000017
2008515032.tif 000018
2008515032.tif 000019