JP4824390B2

JP4824390B2 - 動的なコンテンツ変更通知

Info

Publication number: JP4824390B2
Application number: JP2005318522A
Authority: JP
Inventors: エム．デイディエッテ; ゼット．アクセルロッドエーヤル; エー．ジルジャーマン; シー．フリューゲルジェイソン; アイ．トーレスマイケル; ピー．ロサトステファン; エー．ジェヤシーラントーマス
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2004-11-01
Filing date: 2005-11-01
Publication date: 2011-11-30
Anticipated expiration: 2025-11-01
Also published as: KR20060052358A; JP2006139778A; US20060095397A1; MXPA05011614A; KR101152997B1; EP1653703A3; CA2525000A1; EP1653703A2; CA2525000C; CN1783792A; US8090776B2

Description

本発明は、ネットワークを介した、通知および関連するコンテンツの動的な提供を対象とする。

インターネットの発展に伴い、人々が互いに通信することを可能にするいくつかのツールが発展した。こうしたツールにより、人々は、自分の考えを表現（express）し、データを体系化（organize）し、エクスペリエンス（experience）を共有し、ウェブへのアクセスを使用して他の人達にコンテンツを提供することが可能になる。

ウェブを介して通信を行うこれらのツールは、デジタル・コンタクト・カードおよびウェブ・ページを含む。デジタル・コンタクト・カード、またはコンタクト・カードとは、ある人またはエンティティに関するコンタクト情報を含むイメージである。コンタクト・カードは通常、無地の背景に氏名、役職、会社名、電話番号、ファックス番号、ｅメール、および住所を含む、紙の名刺と同じコンタクト情報を含む。こうしたカードは通常、カードへのリンクを含むｅメール・メッセージを介して配送される。ｅメールを受け取り、ｅメールを開き、コンタクト・カード・リンクをクリックした後、閲覧者は、カード上の情報を見ることができる。カードの所有者に関するコンタクト情報または他の情報に変更があった場合、カードの所有者は、情報を手作業で変更しなければならない。このカードは、カードの所有者について非常に平易で、一般的で、かつ旧式な表現を提供する。

ウェブ・ページは、ウェブにふさわしい最も人気のある通信ツールの１つである。ウェブ・ページは一般に、インターネットに個人的なコンテンツを投稿するのに使われる。ウェブ・ページは、フォーマットされたテキスト、ウェブ・ログ、イメージ、写真、および他のウェブ・ページへのリンクを含むことができる。所有者は、コンテンツ、フォーマット、バックグラウンド、フォント、色、および他のデザイン要素を構成することによって、ウェブ・ページを自分用に設定することができる。ローカル・マシン上で実行されるウェブ・ブラウザは、インターネットを介してウェブ・サーバに所与のウェブ・ページを要求し、そのページをローカル・マシンにロードし、動的または静的なウェブ・ページを、ユーザに提供するように変換する。所有者は、コンテンツを追加し、削除し、または変更することによって、ページに変更を加えることができる。閲覧者は、次回そのページを訪れたときに、所有者によって行われた変更を見ることができる。

ウェブ・サイトのコンテンツへの変更または変更自体を、信頼されるコンタクト・リストに自動的に公開する好都合な機構がない。ウェブ・ページにおける変更の通知を提供するために、ウェブ・ページの所有者は、閲覧者に手作業で（例えば、グループｅメールや口頭で）通知しなければならない。さらに、ウェブ・ページ上のコンテンツは通常、閲覧する人全員に公開される。このことは、ウェブ・サイトの所有者が、全員が見るには適切でない可能性があるコンテンツを投稿する意欲を減退させる。特定のインターネットページは、パスワードによって保護されるが、パスワードをもたないユーザは、そのコンテンツをまったく閲覧することができない。パスワードによって保護されたコンテンツの所有者は、パスワードの入手について閲覧者を援助し、または支援する必要がある。

ブログ、写真共有、およびインスタント・メッセージ（ＩＭ）ウェブ・サービスなどの従来のウェブ・サービスは、何らかのタイプの通知プロセスの提供を計画した。一般的なブログは、ブログ所有者による、１ページ分のエントリである。エントリ・コンテンツは、大抵はテキストであるが、写真および他のコンテンツへのリンクも含むことができる。このエントリは大抵、逆の時系列順形態の意識の流れ、すなわち「その日思ったこと」である。閲覧者は、ある特定のエントリへの応答としてコメントを投稿することができ、こうしたコメントは大抵、別個のページで閲覧される。ブログは、見る人全員に利用可能であるという点でウェブ・サイトと同様であるが、それらは、パスワードを使用して実装される。従来のいくつかのブログ・システムは、新しいエントリが投稿されると配信先リストにｅメール通知を提供しており、この機能性を可能にするために既存のブログ・アプリケーションに統合することができる、実用化されているシステムもある。ただし、受信者は通常、所有者による招待ではなく、それをホストするウェブ・サーバに受信者が要求することによって、配信先リストに追加される。しばしば、ブログ所有者にとってまったく知らない人が、自分のブログ用通知リストに載ることになる。この結果、所有者と信頼関係のない閲覧者に新しいブログ・エントリが配信される。さらに、提供される情報は通常、ｅメール・アドレスの中にあるリンクである。したがって、情報を取り出すために、ユーザは、ｅメール・アドレスにログオンし、そのインボックス（受信トレイ）にアクセスし、メール・メッセージを開き、リンクをクリックしなければならない。

写真を共有するウェブ・サービス（Photo sharing web services）は、ユーザがデジタル写真をアップロードし、共有し、プリントを注文することを可能にする。写真を共有するには、写真を共有する受信者のリストを生成し、そのリストにｅメール通知を送るようウェブ・サービスに要求することが必要である。これは、１組の新しい写真がアップロードされる度に、手間のかかるプロセスとなり得る。アップロードされた写真は、受信者リストにない人には入手不可能である。

ＩＭアプリケーションは、ログインしている複数のユーザが、テキスト・メッセージおよび他のコンテンツを互いに瞬時に送ることを可能にする。各ユーザが、対話したいと望むコンタクトのリストを保持することができる。ユーザは、しばしばバディー（buddy）リストと呼ばれる、自分のリストにあるコンタクトの誰とでも、そのコンタクトがネットワークにサインインしている限り「チャット」することができる。いくつかのＩＭアプリケーションは、ウェブ・ベースのｅメール・サービスと統合されている。ユーザが、統合ｅメール・サービスでアカウントを取得し、その後そのＩＭにログオンすると、ｅメール・サーバで新しいｅメールが受信された際に、そのＩＭを介して通知が提供されることになる。

従来のインターネット通信ツールは、信頼されるコンタクト・グループへのコンテンツ変更についての自動通知を提供せず、便利な方法で、コンテンツへの制御されたアクセスも十分に提供していない。

本明細書に記載する技術は、概説すると、ネットワークを介した通知およびコンテンツ要約の提供に関連する。コンテンツ・ページの所有者が、ネットワーク上のコンテンツ・ページを構成する。この所有者は、そのコンテンツ・ページのコンテンツを、自分が望むように構成することができる。そのコンテンツ・ページに対して変更が行われると、通知が自動的に生成され、所有者と信頼関係のある既存のコンタクトのグループに経路指定される。そのコンテンツ・ページ、または変更された特定のコンテンツを閲覧する許可を有するコンタクトのみが、その通知を受け取ることになり、その変更コンテンツを閲覧することができる。

ユーザ・インターフェース中の視覚インジケータ（visual indicator）が、ユーザのコンタクトの１つによって所有されるコンテンツ・ページまたはそのページのサブセクション（コンポーネント）が変更されたことをユーザに通知する。ユーザによって視覚インジケータが選択されると、要約モジュールを提供することができる。要約モジュールは、ネットワーク・コンテンツへのポータル（入り口）である。ネットワーク・コンテンツは、インターネット上のコンテンツ・ページおよび他のコンテンツを含むことができる。要約モジュールのコンテンツは、コンテンツ・ページの所有者によって構成される。コンテンツ・ページとともに使われる場合、要約モジュールは、コンテンツ・ページから直接生成することができる。

通知は、コンテンツ・ページ中のコンテンツ変更を検出すること、そのコンテンツ変更に関連付けられた通知を自動的に生成すること、その通知をメッセンジャー・サーバに自動的に送信すること、その通知に関連付けられた視覚インジケータをメッセンジャー・ユーザ・インターフェースに表示することによって、提供することができる。ここで、この視覚インジケータは、コンテンツ変更に関連付けられている。

ユーザによって選択されたコンテンツを公開するのに、動的な要約モジュールを使うことができる。要約モジュールのコンテンツは、コンテンツ・ページを含めて、ネットワーク上に置くことができる。要約モジュールは、コンテンツ・ページとともに使われる場合、コンテンツ・ページ変更が検出されると自動的にアップデートされる。

ネットワークを介して通知を提供するシステムは、コンテンツ・ページを含む１つまたは複数のサーバと、１つまたは複数のユーザ・リストおよび１つまたは複数のコンタクト・リストを含む１つまたは複数のサーバに接続された１つまたは複数のデータベースと、１つまたは複数のサーバおよび１つまたは複数のデータベースに接続されたメッセンジャー・サーバとを含むことができ、メッセンジャー・サーバは、１つまたは複数のコンタクトに通知を提供するように構成され、この通知は、コンテンツ・ページのコンテンツに関連付けられる。

コンテンツ・ページとは、ネットワーク上に置かれたコンテンツの、体系化された動的な集合体である。コンテンツ・ページは、１つまたは複数のコンポーネントを含むことができる。一実施形態では、コンテンツ・ページ・コンポーネントは、ブログ、フォト・アルバム、音楽リスト、ネットワーク・リンク・リスト、コンタクト情報、カレンダ、プロファイル情報、ポーリング、メッセージ・ボード、ビデオ、ウェブ・カメラ、およびゲスト・ブックなどのコンテンツを含むことができる。他のコンテンツを同様にコンテンツ・ページに実装することもできる。一実施形態では、コンテンツ・ページはウェブ・サイトであり、インターネットを介してアクセス可能である。この場合、コンテンツ・ページの所有者は、どこにいても、コンテンツ・ページを構成しページにアクセスすることができる。

一実施形態では、コンテンツ・ページは、他の複数のコンテンツ・ページの部分を含むことができる。例えば、他のコンテンツ・ページのブログ、イメージ、歌、および他のコンテンツの集合体を、その所有者のコンテンツ・ページに追加することができる。その結果、所有者は、自身のコンテンツ・ページを訪れて、他のコンテンツ・ページのコンテンツにおける変更を見ることができる。

コンテンツ・ページのコンテンツは、様々なフォント、色、およびスタイルで構成して、カスタマイズされたルック・アンド・フィールを作成することができる。パーソナライズされたコンテンツも、個人的なメッセージまたは引用、パーソナライズされたサムネイル、名前およびコンタクト情報、ならびにインスタント・メッセージング・サービスまたはｅメールへのコンタクト・リンク、を含むコンテンツ・ページを構成するのに使うことができる。個人的なメッセージまたは引用は、所有者が自分のページに表示したいと望むテキスト、イメージ、ビデオ、または他のコンテンツからなる任意のメッセージとすることができる。サムネイルは、人の写真イメージ、アバター、または所有者によって選択された他の何らかのイメージでよい。コンテンツ・ページは、コンテンツ・ページの所有者によっていつでも構成し変更することができる。

図１は、コンテンツ・ページ１００の一実施形態を示す。コンテンツ・ページ１００は、ブログ・コンポーネント１２０、ブログ・コンポーネント１２０の下のフォト・アルバム・コンポーネント１３０、フォト・アルバム・コンポーネント１３０の隣のリンク・コンポーネント１４０、リンク・コンポーネント１４０の上の音楽コンポーネント１５０、音楽コンポーネント１５０の上のプロファイル・コンポーネント１６０、コンポーネント１２０〜１６０の上の個人のメッセージ１７０、プロファイル・コンポーネント１６０の上の個人のイメージ１８０、および個人のイメージ１８０の隣のオンライン・インジケータ１９０を含み、これらはすべてユーザ・インターフェース・ウィンドウ１１０に含まれる。ブログ１２０は、エントリ・タイトル１２１、エントリ・タイトル１２１の下のエントリ・イメージ１２２、エントリ・イメージ１２２の下の第１のブログ・エントリ１２３、およびブログ・エントリ１２３の下のブログ・ツール・バー１２４を含む。ブログ・ツール・バー１２４の下には、第２のブログ・エントリ１２５がある。第２のブログ・エントリ１２５は、第１のブログ・エントリ１２３の下にあり、より最新のブログ・エントリ１２３より以前に投稿されたことを示す。フォト・アルバム・コンポーネント１３０は、イメージ１３１、第１のフォト・アルバム部分１３２、および第２のフォト・アルバム部分１３３を含む。第１のアルバム部分１３２および第２のアルバム部分１３３はそれぞれ、別個のアルバムを表し、代表的なサムネイル、アルバム・タイトル、およびアルバムの説明を含む。イメージ１３１は、最新のアルバム１３２のうちの代表的なイメージである。リンク・コンポーネント１４０は、コンテンツ・ページの所有者によって選択された他のウェブ・サイトへのリンクのリストを含む。音楽コンポーネント１５０は、所有者によって選択され、または最近再生された歌のタイトルおよびアーティストのリスト１５１を含む。リスト中の各歌の隣に、購入ボタンが配置される。このボタンは、閲覧者が特定の歌を購入することができるウェブ・サービスへのリンクである。プロファイル・コンポーネント１６０は、ｅメール・リンク１６１と、ＩＭリンク１６２と、コンテンツ・ページの所有者の興味、趣味、および嗜好を示すテキストとを含む。所有者は、プロファイル・コンポーネントにカテゴリを追加することができる。個人のイメージ１８０は、所有者が選びまたは提供することができるイメージである。オンライン・インジケータ１９０は、所有者が現在、コンテンツ・ページと通信中のネットワークにログオンしているかどうかを示す。

コンテンツ・ページ１００は、コンテンツ・ページの一構成の例に過ぎない。コンテンツ・ページの精神は、コンテンツ・ページの所有者が、コンテンツ・ページの外見およびエクスペリエンス（experience）を、所有者の個人的な趣味を反映するようにカスタマイズすることができることである。図１に示すものとは異なるモジュール・タイトル、コンテンツ、オリエンテーション、およびルック・アンド・フィール特徴を有する構成を含む他の構成も可能である。

一実施形態では、ネットワーク上に置かれたコンテンツ・ページおよび他のページのコンテンツは、要約モジュールを使って共有することができる。要約モジュールとは、所有者のコンテンツ・ページへのポータル（入り口）を提供することによって、所有者によって選択された情報を公開するのに使われるインターフェースである。その情報は、プロファイル情報、通信リンク、およびネットワークを介して置かれた、コンテンツ・ページのコンテンツなど、他のコンテンツを含むことができる。プロファイル情報は、所有者の名前、アドレス、電話番号、および他の情報を含むことができる。通信リンクは、所有者と通信するためのｅメール、ＩＭリンク、および他のリンクを含むことができる。要約モジュール・コンテンツは、所有者がいる場所の天気またはニュース、所有者の仕事に関する最近のニュース記事、スケジュール情報、コンテンツ・ページの所有者がネットワークまたはサーバにサインインしているかどうか、あるいはネットワークを介して提供される他の情報、を含むことができる。一実施形態では、要約モジュールは、所有者の完全なコンテンツ・ページにある情報のサブセット（すなわち要約）を含む。

要約モジュールの一実施形態を図２Ａ〜２Ｂに示す。図２Ａは、要約モジュールのフロント・イメージ２００を示し、図２Ｂは、要約モジュールのバック・イメージ２５０を示す。フロント・イメージ２００は、カード２１０、ユーザ識別子２１２、カード反転インジケータ２１４、カード・クローズ・アイコン２１６、ニックネーム２２０、コンテンツ・タイトル２２２、フォト・アルバム・タイトル２３０、フォト・アルバムの説明２３２、サムネイル２３４、追加コンテンツ・リンク２４０、ｅメール・リンク２４２、ＩＭリンク２４４、コンテンツ・ページリンク２４６、およびプロファイル・イメージ２４８を含む。ユーザ識別子２１２は、所有者のコンテンツ・ページを含むネットワーク上で所有者を一意に識別する名前でもｅメール（アドレス）でもよい。カード反転インジケータ（card flip indicator）２１４が選択されると、カードのフロント・イメージが移動され、図２Ｂのバック・イメージ２５０がユーザに表示される。ニックネーム２２０は、テキスト文字列である。コンテンツ・タイトル２２２は、要約モジュールによって表示されるコンテンツのソースである。図２Ａの実施形態において、コンテンツ・ソースは、所有者のコンテンツ・ページであり、要約モジュールの各項目は、そのコンテンツ・ページの中に見つけ出すことができる。

要約モジュール・コンテンツ項目２３０〜２３４は、図１に示すコンテンツ・ページ１００のブログ・モジュール１２０に対応する。フォト・アルバム・タイトル２３０、フォト・アルバム説明２３２、およびサムネイル２３４が、所有者のコンテンツ・ページから取り出される。追加コンテンツ・リンク２４０は、所有者のコンテンツ・ページのＵＲＬへのリンクである。ｅメール・リンク２４２が選択されると、所有者へのｅメールが用意される。ＩＭリンク２４４は、所有者とのＩＭセッションを開始する。ＩＭリンク２４４が選択されたときに所有者がオンラインになっていない場合、閲覧者は、所有者にオフライン・メッセージを送ることができる。一部の実施形態では、所有者がオフラインのとき、所有者が通信可能でないことを示すメッセージが表示され、オフライン・メッセージは送られない。リンク２４６は、そのコンテンツ・ページを取り出し、新規ウィンドウで開く。プロファイル・イメージ２４８は、タイトル、アバター、または所有者がプロファイルに含めるように選択することができる他のどのイメージとすることができる。

図２Ｂのバック・イメージ２５０は、要約カード２６０、要約カード反転インジケータ２６４、要約カード・クローズ・アイコン２６６、およびコンタクト情報２７０を含む。バック・イメージ２５０は、所有者のコンタクト情報を、フロント・イメージ２００よりもより形式的に示す。

一実施形態では、要約モジュールは、関連付けられたコンテンツ・ページのコンテンツが変更されたことを示すことができる。通知プロセスが、動的かつ自動的に、コンテンツ・ページの変更を要約モジュールに組み込む。通知プロセスについては、後でより詳しく論じる。要約モジュールに関連付けられたコンテンツ・ページに変更が起こると、要約モジュール上に視覚インジケータが提供される。この視覚インジケータは、ハイライト、マーカ、または変更されたコンテンツに対応してもしなくてもよい他の何らかのインジケータを含むことができる。一部の実施形態では、各新規項目に対応する視覚インジケータがある。他の実施形態では、要約モジュールは、どのデータが新しいかにかかわらず、１つの視覚インジケータのみを持つことがある。

図２Ｃ〜２Ｄは、コンテンツ・ページへの変更を表す視覚インジケータを有する要約モジュールの実施形態を示す。図２Ｃは、１つまたは複数の視覚インジケータを有する要約モジュールのフロント・ビュー２８０の一実施形態を示す。図２Ｃは、要約モジュール２８５、サムネイル行２８７、および「もっと見る」というコンテンツ・インジケータ２８８を含む。図２Ａの要約モジュール２１０のサムネイル２３４は、１、２、３、４、５というコンテンツを含む。この数字は、対応するコンテンツ・ページに写真が追加された順序を示す。サムネイル「１」は最初に追加され、サムネイル「５」は最後に追加された。サムネイルは、新しいものが追加されると、要約モジュールにおいて左から右にシフトする。カード２８５のサムネイルは、２、３、４、５、６というコンテンツを含む。新しいサムネイル「６」が、サムネイルの行に追加される。以前からあったすべてのサムネイルが、右にシフトされ、サムネイル「１」はカードの外にシフトされる。また、サムネイル「６」は、新しいものであることを示す枠でハイライトされる。要約モジュール２８５は、「もっと見る」というリンクの隣にアイコン２８８（アスタリスク「＊」）も含む。アイコン２８８は、コンテンツ・ページに新しいコンテンツが追加され、関連付けられたリンクを選択することによってアクセス可能であることを示す。一実施形態では、要約モジュール上でどの項目を選択しても、ユーザは、要約モジュールに関連付けられたコンテンツ・ページにたどり着くことになる。図２Ｄは、要約モジュール２９５のバック・イメージ２９０を含む。要約モジュール２９５は、コンタクト情報２９７を含む。携帯電話エントリの隣の視覚インジケータ２９８（アスタリスク「＊」）は、このデータ項目が、要約モジュールの最終閲覧以降に変更されたことを示す。以上は、コンテンツ・ページに新しいコンテンツが追加されたことを、要約モジュールがどのように示すことができるかという例である。

一実施形態では、コンテンツ・ページの所有者は、コンテンツ・ページのどのコンテンツが、所有者用の対応する要約モジュールに提供されるかを決定する。したがって、コンテンツ・ページに変更を行うことはできるが、要約モジュールは、コンテンツ・ページの選択されたモジュールからのコンテンツを提供するだけであるように構成することが可能である。要約モジュールに含まれるモジュールは、コンテンツ・ページの所有者によって手作業で、アルゴリズム（最も頻繁に閲覧される、など）によって、または他の何らかのやり方で、選択することができる。さらに、要約モジュールのコンテンツおよびレイアウトは、ユーザによって所望通りに編成することができる。例えば、要約モジュールは、様々な形で、その形のままで異なるエリアに配置されているコンポーネント情報を使用して提示することができる。

図３Ａ〜３Ｃは、閲覧者によって選択される要約モジュールの実施形態を示す。図３Ａは、要約モジュール３１０、要約モジュール３１０内部のブログ・コンテンツ３２０、ブログ・コンテンツ３２０の上のカーソル３１５、および要約モジュール３１０に重なっているブログ・コンテンツ・ウィンドウ３２５を含む。ブログ・コンテンツ３２０は、「ＭｏｕｎｔａｉｎＢｉｋｉｎｇａｔ３８００ｆｔ．．．」と書かれたブログ・タイトルの一部分、および「Did you hear that Matt went over the bars as Woodline」で始まるブログ・エントリの一部分を含む。カーソル３１５が、ブログ・コンテンツ３２０のブログ・エントリの上に置かれると、ブログ・コンテンツ・ウィンドウ３２５が生成される。ブログ・コンテンツ・ウィンドウ３２５は、最初の行にあるブログ・タイトルで始まるブログ・エントリ、次の３行にあるブログ・エントリ、および最後の行に「１２ｃｏｍｍｅｎｔｓ」と書かれた指示（indication）を含む。ブログ・コンテンツ３２０およびブログ・コンテンツ・ウィンドウ３２５のブログ・タイトルおよびブログ・エントリは両方とも、要約モジュールに関連付けられたコンテンツ・ページのブログ・コンポーネントに対応する。カーソルがブログ・エントリの上にあり、現在ブログ・コンテンツ・ウィンドウを表示している間に、閲覧者がマウス・クリックなどの入力を提供した場合、クライアントは、コンテンツ・ページ・サーバに対して、ブログ・コンポーネントを含むコンテンツ・ページのコンテンツを要求し、コンテンツをローカル・マシンに表示する。

図３Ｂは、要約モジュール３３０、要約モジュール３３０内部の写真コンテンツ３３５、写真コンテンツ３３５の上のカーソル３４０、および要約モジュール３３０に重なっている写真コンテンツ・ウィンドウ３５０を含む。写真コンテンツ３３５は、６個のサムネイル・イメージを含む。カーソル３４０が写真コンテンツ３４０のサムネイルの上に置かれると、写真コンテンツ・ウィンドウ３５０が生成される。写真コンテンツ・ウィンドウ３５０の最初の行は、「ＨａｗａｉｉＶａｃａｔｉｏｎ」と書かれた、イメージが属すフォト・アルバムのタイトルを含む。写真コンテンツ・ウィンドウ３５０の第２行は、「Ｍｅ＆Ｐａｔ」と書かれた、選択されているイメージの説明を含む。フォト・アルバムのタイトルおよび写真コンテンツ・ウィンドウ３５０のイメージ説明は両方とも、要約モジュールに関連付けられたコンテンツ・ページ中のフォト・アルバム・コンポーネントに対応する。カーソル３４０がサムネイルの上にあり、現在写真コンテンツ・ウィンドウ３５０を表示している間に、閲覧者がマウス・クリックなどの入力を提供すると、クライアントは、コンテンツ・ページ・サーバに対して、写真コンポーネントを含むコンテンツ・ページのコンテンツを要求し、そのコンテンツをローカル・マシンに表示する。

図３Ｃは、要約モジュール３６０、要約モジュール３６０内部のリスト・コンテンツ３７０、リスト・コンテンツ３７０の上のカーソル３６５、および要約モジュール３６０に重なっているリスト・コンテンツ・ウィンドウ３８０を含む。リスト・コンテンツ３７０は、「ＢｒａｎｄｉＣａｒｌｉｌｅ：Ｔｕｒｐｅｎｔｉｎｅ」と書かれた第１の歌のアイテムおよび第１の歌のアイテムの下にある、「ＤａｍｉａｎＲｉｃｅ：Ｃａｎｎｏｎｂａｌｌ」と書かれた第２の歌のアイテムを含む。カーソル３６５が、リスト・コンテンツ３７０の歌のアイテムの上に置かれると、リスト・コンテンツ・ウィンドウ３８０が生成される。リスト・コンテンツ・ウィンドウ３８０の第１行は、「Ｃａｎｎｏｎｂａｌｌ」と書かれた歌のタイトルを含み、第２行は、「Ａｒｔｉｓｔ：ＤａｍｉａｎＲｉｃｅ」と書かれたアーティストを含み、第３行は、「Ｐｌａｙｌｉｓｔ：Ｔｏｐ１０Ｆａｖｏｒｉｔｅｓ」と書かれたリストタイトルを含む。リスト・コンテンツ・ウィンドウ３８０の歌項目タイトル、アーティスト、およびプレイ・リストは、要約モジュールに関連付けられたコンテンツ・ページ中の歌リスト・コンポーネントに対応する。カーソル３６５がリスト項目の上にあり、現在リスト・コンテンツ・ウィンドウ３８０を表示している間に、閲覧者がマウス・クリックなどの入力を提供すると、クライアントは、コンテンツ・ページ・サーバに対して、歌リスト・コンポーネントを含むコンテンツ・ページのコンテンツを要求し、コンテンツをローカル・マシンに表示する。

コンテンツ・ページに関連付けられると、要約モジュールは、そのコンテンツ・ページの所有者によって構成することができる。要約モジュールを構成する一方法を、図４の方法４００に示す。そのページ・コンテンツを変更する認可（authorization）を有する、コンテンツ・ページへのアクセスが、ステップ４１０で所有者に与えられる。一実施形態では、認可は、所有者が識別（ＩＤ）およびパスワード情報を提供した後で与えられる。コンテンツ・ページにアクセスしている間、そのユーザは、コンテンツ・ページのコンポーネントを選択し、そのコンポーネントを所有者の要約モジュールに含めるべきであると指示することができる。ステップ４２０で、システムは、ユーザが要約モジュールに追加するためのコンテンツ・ページ・コンポーネントを選択したことを示す入力を受け取る。コンテンツ・ページが、コンポーネントを選択する入力を受け取った後、コンテンツ・ページは、ステップ４３０で、格納サーバ８２０（図８を参照）中のアップデート・メソッドをコールする。このコールは、選択されたコンポーネント用のコンポーネント識別子およびコンテンツ・ページ用のコンテンツ・ページ識別子を含む。格納サーバ８２０は次いで、ステップ４４０で、どのようにしてそのコンポーネントを要約モジュール・データ要求に含めるかを示す、そのコンポーネント用のフィルタを作成する。一実施形態では、フィルタ・パラメータは、バイナリ・ビットを含み、ビット中で、値１は、コンポーネントが要約モジュールに含まれることを示す。フィルタ・パラメータは、また、どのようにしてコンポーネント・コンテンツを要約モジュールに含めるべきかを示すコンポーネント項目パラメータも含むことができる。例えば、ブログ・コンポーネント・フィルタは、ブログ・エントリ・タイトルおよびブログ・エントリの最初の２０文字が含まれることを示す場合があり、フォト・アルバム・フィルタは、フォト・アルバム・タイトルおよび最大５個のサムネイルが含まれることを示す場合があり、プレイ・リスト・コンポーネント・フィルタは、プレイ・リストのタイトルならびに最大限の歌のタイトルおよびアーティストを表示することができると示す場合がある。フィルタ・パラメータは、要約モジュール・コンテンツ要求を送る際に、メッセンジャー・クライアントによって、および通知プロセス中に発生するコンポーネントを決定するのに格納サーバ（storage server）８２０によって使うことができる。メッセンジャー・クライアント・コンテンツ・クエリ要求および通知プロセスについては、以下でより詳しく論じる。

一実施形態では、コンテンツ・ページおよび要約モジュールへのアクセスを決定するのに、許可を使うことができる。コンテンツ・ページの所有者は、自分のコンテンツ・ページのアップデートを受け取る許可リスト上に１つあるいは複数のコンタクトを指定することができる。許可リストに載っていない人は、コンテンツ・ページ、要約モジュール、およびこれらに関連した通知を閲覧するためのアクセス権を与えられないことになる。許可を与えられるコンタクトは、ユーザとの信頼された関係をもつエンティティでよい。一実施形態では、コンタクトは、ネットワークを介してユーザと既に関係を築いているエンティティでよい。例えば、コンタクトは、インスタント・メッセージサービスにおいて保持されているコンタクトのリストへの参照でもよく、そのリストから選択されてもよい。

一実施形態では、ユーザは、ユーザのコンタクトのコンテンツ・ページへの変更に対する通知を、スタンド・アロン・アプリケーション・クライアントを介して受け取ることができる。スタンド・アロン・クライアントとは、ローカル・マシン・メモリに存在するソフトウェア・プログラムである。スタンド・アロン・クライアントの一例は、インスタント・メッセージ（ＩＭ）クライアントである。ＩＭクライアントについては、以下の説明で例示のために参照する。

ＩＭユーザ・インターフェース５００の一実施形態を、図５に示す。ＩＭインターフェース５００は、ウィンドウ５１０、ウィンドウ５１０内のユーザ状況インジケータ５１２、メッセンジャー・コンタクト・リスト５１４、視覚インジケータ５２０、および各コンタクトごとに、コンタクト・インジケータ５３０およびオンライン・インジケータ５３２を含む。ユーザがＩＭサービスにログオンする度に、メッセンジャー・サーバは、メッセンジャー・コンタクト・リスト５１４のメンバを、メッセンジャー・クライアントに提供し、どのメンバがコンテンツ・ページに関連付けられるかを示す。ユーザは通常、メッセンジャー・コンタクト・リスト５１４に列挙される１つまたは複数のコンタクトを有する。ユーザ状況（status）インジケータ５１２は、ユーザが現在、メッセンジャー・サーバにログインしているかどうかを示す。メッセンジャー・コンタクト・リスト５１４上のコンタクトそれぞれに対するオンライン・インジケータ５３２は、コンタクトが現在、メッセンジャー・サーバにログインしているかどうか示す。

一実施形態では、視覚インジケータ５３０は、コンタクト向けのコンテンツ・ページが変更されたことをユーザに通知する役目を有する。視覚インジケータ５３０は、コンタクト用オンライン・インジケータ周囲の色の変更として実装することができる。メッセンジャー・リスト５１４にあるコンタクトがコンテンツ・ページをもっていない場合、コンタクト識別子「Ｊａｍｅｓ」に関連付けられたオンライン・インジケータ５３２によって示されるような視覚指示（visual indication）は示されない。一部の実施形態では、視覚インジケータを、図５で示すものとは異なるやり方、例えばコンタクト名またはオンライン・インジケータの近くに表示されるコンタクト識別子のハイライト、視覚アイコン、影、特殊文字などで提供することができる。

メッセンジャー・クライアント内部から、ユーザは、要約モジュールを、対応するコンタクトを選択するための入力を与えることによって閲覧することができる。選択されると、メッセンジャー・クライアントは、その要約モジュールを取り出し表示する。図６および７は、要約モジュールを提供することができるメッセンジャー・クライアント・インターフェースを示す。図６は、クライアント・インターフェース・ウィンドウ６１０、ユーザ・ニックネーム６１５、メッセンジャー・コンタクト・リスト６２０、コンタクト・ニックネーム６３０、コンタクト存在インジケータ６３５、メッセージ・ウィンドウ・ポインタ６４０、およびメッセージ・ウィンドウ６５０を含む。クライアント・インターフェース・ウィンドウ６１０は、ユーザがアラートを受け取り、メッセージ・セッションで複数のコンタクトと関わり合いを有することを可能にし、コンテンツカードを閲覧するための入力を与えるインターフェースである。ユーザ・ニックネーム６１５「ＢｏａｒｄＭｏｎｋｅｙ」に関連付けられたユーザは、メッセンジャー・クライアント・インターフェースを介してメッセンジャー・サーバにサインインしている。メッセンジャー・コンタクト・リスト６２０は、サインインしているユーザに関連付けられたいくつかのコンタクトを含む。コンタクト存在インジケータは、コンタクトが現在、コンテンツ・ページにサインインしているかどうか、およびコンテンツ・ページをもっているかどうかを示す。コンタクトが現在、サインインしており、そのコンタクトがコンテンツ・ページをもっている場合、コンタクト存在インジケータは、コンテンツ・ページにあるイメージを含むことができる。図６に示す実施形態では、そのイメージはアバター（ネット上での仮の像）である。一実施形態では、コンタクト・ニックネーム６３０、つまり「ＢｉｌｌｙＷｒｉｔｉｎｇＲｅｐｏｒｔｓ」に関連付けられたコンタクト存在インジケータ６３５の上にカーソルを置く、すなわち「静止する（hover）」ことができる。カーソルをコンタクト存在インジケータの上に移動した結果として、メッセージ・ウィンドウ６５０が表示される。メッセージ・ウィンドウは、要約モジュールを含むことができ、かつ／またはユーザがコンテンツを閲覧するために取ることができるそれ以上のステップに関するユーザ情報を提供することができる。メッセージ・ウィンドウ６５０は、「Ｃｌｉｃｋｈｅｒｅｔｏｏｐｅｎ」と書かれたテキストを提供する。メッセージ・ウィンドウ・ポインタ６４０は、メッセージ・ウィンドウ６５０に関連付けられたコンタクト存在識別子６３５を指す。

図７は、要約モジュールが提供されているメッセンジャー・ユーザ・インターフェースを示す。一実施形態では、要約モジュール７４０は、図７のインターフェース７１０が、コンタクト存在インジケータ７３５を選択する入力を受け取った結果として表示される。図７は、インターフェース・ウィンドウ７１０、メッセンジャー・コンタクト・リスト７２０、コンタクト・ニックネーム７３０、コンタクト存在インジケータ７３５、要約モジュール７４０、コンタクト識別子７４１、要約モジュール・コンタクト・ニックネーム７４２、および要約モジュール・コンテンツ７４４、７４６を含む。要約モジュール７４０は、コンタクト・ニックネーム７３０、つまり「ＢｉｌｌｙＷｒｉｔｉｎｇＲｅｐｏｒｔｓ」に関連付けられたコンタクトに対応する。要約モジュール７４０内のコンタクト・ニックネーム７４２は、メッセンジャー・ユーザ・インターフェース７１０内のコンタクト・ニックネーム７３０と同一である。一部の実施形態では、要約モジュールは、マウスの右ボタン・クリック、コンタクト存在インジケータの選択、コンタクト識別子、またはコンタクト向けのコンテンツ・ページに関連付けられた他の何らかの視覚インジケータなどの入力を受け取ることによって表示することができる。

コンテンツ・ページ、要約モジュール、自動通知プロセス、およびこれらの間の動的な同期化は、図８に示すようなシステムによって実装することができる。図８のシステム８００は、コンテンツ・ページ・サーバ８１０、格納サーバ８２０、アドレス帳クリアリング・ハウス（ＡＢＣＨ）８３０、アラート・サーバ８４０、メッセンジャー・サーバ８５０、メッセンジャー・ウェブ・サービス８６０、クライアント・ウェブ・ブラウザ８７０、ｅメール・サーバ８７２、メッセンジャー・クライアント８８０、インスタントメッセンジャー・ユーザ・インターフェース８８２、および要約モジュール８８４を含む。図８のサーバおよびクライアント・デバイスはそれぞれ、当該分野において公知のコンピュータとして実装することができる。例えば、こうしたデバイスは、１つまたは複数の格納デバイス（メモリ、ディスク・ドライブなど）と通信中の１つまたは複数のプロセッサ、および１つまたは複数の周辺装置（モニタ、キーボード、マウス、プリンタ）を含むことができる。こうした１つまたは複数の格納デバイスは、本明細書に記載するプロセスを実装するデータおよびコードを格納する。

コンテンツ・ページ・サーバ８１０は、格納サーバ８２０、メッセンジャー・クライアント８８０、およびｅメール・サーバ８７２とデータの送受信を行い、任意選択で、アラート・サーバ８４０に情報を送る（図示せず）ことができる。ＡＢＣＨ８３０は、格納サーバ８２０およびメッセンジャー・サーバ８５０との間で情報を送受信する。メッセンジャー・サーバ８５０は、アラート・サーバ８４０から情報を受け取り、メッセンジャー・クライアント８８０、格納サーバ８２０、およびメッセンジャー・ウェブ・サービス８６０との間で情報を送受信する。メッセンジャー・クライアント８８０は、格納サーバ８２０、コンテンツ・ページ・サーバ８１０、メッセンジャー・サーバ８５０、コンタクト・カード８８４、およびインスタント・メッセンジャー・ユーザ・インターフェース８８２との間で情報を送受信する。クライアント・ウェブ・ブラウザ８７０は、メッセンジャー・ウェブ・サーバ８６０およびｅメール・サーバ８７２との間で情報を送受信する。図８のデバイスの間の通信については、後でさらに説明する。

コンテンツ・ページ・サーバ８１０は、要求を行うエンティティのためのコンテンツ・ページ情報を構成する１つまたは複数のウェブ・サーバとして実装することができる。要求を行うエンティティは、ＩＭアプリケーション用のメッセンジャー・クライアント８８０、ウェブ・ページおよびブラウザ・ベースのｅメール用のクライアント・ウェブ・ブラウザ８７０、ならびにｅメール・アプリケーション用のｅメール・サーバ８７２を含むことができる。例えば、コンテンツ・ページ・サーバ８１０は、メッセンジャー・クライアント８８０およびｅメール・サーバ８７２に、コンテンツ・ページのコンテンツを、ユーザの地域に応じて、英語やフランス語など、該当する言語で提供する。コンテンツ・ページに関するコンテンツ情報は、メッセンジャー・クライアント８８０にＸＭＬフィードによって伝送することも、ｅメール・サーバ８７２およびクライアント・ウェブ・ブラウザ８７０用にＨＴＭＬとしてパッケージすることもできる。コンテンツ・ページ・サーバ８１０はまた、要求された要約モジュールを取り込む前に、格納サーバ８２０から受け取ったデータをフォーマットする。フォーマットは、ブログからのヘッダ情報の削除、要約モジュールに表示するための適正なサイズのサムネイル・イメージの生成、および他のフォーマット・タスクを含むことができる。

格納サーバ８２０は、コンテンツ・ページ情報が維持される１つまたは複数のデータベースを含む。格納サーバ８２０は、要約モジュール・データ、コンテンツ・ページのバージョンおよび最終更新日情報、コンテンツ・ページ・コンポーネントおよびコンポーネント項目、ならびに許可情報も含むことができる。一部の実施形態では、許可情報は、格納サーバによって動的に構築されたキャッシュに保持され、メッセンジャー・クライアントに返される。メッセンジャー・クライアントは次いで、キャッシュを維持することができる。キャッシュされた許可情報は、キャッシュされた許可リストを含むことができ、このリストは、格納サーバ８２０によって、ある特定のコンテンツ・ページへのユーザ・アクセス資格証明書をキャッシュするのに使われる不透明なデータ構造である。

ＡＢＣＨ８３０は、ユーザ情報を格納する。ユーザ情報は、電話、ｅメールおよび住所、ユーザ・コンタクト・リスト（例えば、アドレス帳、メッセンジャー・コンタクト・リストまたはバディー・リスト、および他のリスト）、利用されるサービス、グループ・メンバシップ、コンテンツ・ページ情報、ならびに許可および役割情報（roles information）などのコンタクト情報を含むことができる。コンテンツ・ページ情報は、ユーザがコンテンツ・ページをもっているかどうか、および他の情報を含むことができる。許可および役割情報は、許可リスト識別子を含むことができる。許可リスト識別子は、格納サーバ８２０がユーザ許可のキャッシュ、またはキャッシュされた許可リストを、格納サーバ８２０のデータベースから取り出すことを可能にする。許可および役割情報は、ユーザが、ユーザのメッセンジャー・コンタクト・リスト上のコンタクトによって所有されるコンテンツ・ページ上にもっている許可も含むことができる。例えば、１人のユーザが、コンテンツ・ページを有する３つのコンタクトをもつことができる。第１のコンタクトＡは、ユーザがＡのコンテンツ・ページ全体を閲覧することを認可することができ、第２のコンタクトＢは、ユーザがＢのコンテンツ・ページの選択されたモジュールを閲覧することを認可することができ、第３のコンタクトＣは、ユーザがＣのコンテンツ・ページのどれも閲覧することも認可することができない。Ａ、Ｂ、Ｃによって提供される認可は、ＡＢＣＨ８３０中のＡに関連付けられた許可リストに含めることができる。

許可リスト識別子は、ＡＢＣＨ８３０から取り出し、メッセンジャー・クライアントなどの、クライアント上にキャッシュすることができる。一実施形態では、許可リスト識別子のキャッシュされたバージョンは、限られた期間のみ有効であり、この期間の後、新しい許可リスト識別子を入手されなければならない。一実施形態では、許可リスト識別子は、２４時間有効である。

アラート・サーバ８４０は、メッセンジャー・サーバ８５０に通知を配送するのに使われる。通知は、株価情報、ｅメール配信、オークション・イベント、速報、新しいコンタクト、コンテンツ・ページ変更、およびコンテンツ・プロバイダからの他の情報を関する情報を含むことができる。アラートは、ＩＭクライアントおよびＩＭウェブ・サービスを用いて取り出すことができる。

メッセンジャー・サーバ８５０は、複数のメッセンジャー・クライアント８８０の間の接続を仲介し、初期セッション接続、存在情報、および通知の配送を扱う。メッセンジャー・サーバ８５０については、後でより詳しく論じる。メッセンジャー・ウェブ・サービス８６０は、インターネットを経由し、クライアント・ウェブ・ブラウザ８７０を介して提供されるＩＭサービスを容易にする。ｅメール・サーバ８７２は、インターネットを経由して、クライアント・ウェブ・ブラウザ８７０を介してアクセスすることができるｅメール・サービスを提供する。メッセンジャー・クライアント８８０は、ＩＭユーザ・インターフェースを提供し、受け取ったデータを対応するコンタクトに相互に関連付けるローカル・プログラムである。

コンテンツ・ページが、その所有者によってアップデートされ、または変更されると、その変更についての通知を所有者コンタクト・リストにあるコンタクトに提供することができる。一実施形態では、変更は、所有者のメッセンジャー・コンタクト・リスト中のコンタクトに提供される。図９は、ユーザのログオン時にメッセンジャー・コンタクト・リストに視覚インジケータを追加する方法９００を示す。方法９００は、ユーザが、メッセンジャー・クライアント８８０にログオンするステップ９１０で始まる。

ログオン・プロセスは、メッセンジャー・クライアント８８０を含めることができ、メッセンジャー・クライアント８８０は、ユーザ名およびパスワードなど、ログオン情報の入力をユーザに促し、ログオン情報をメッセンジャー・サーバ８５０に転送する。一実施形態では、ログオン情報を受け取ると、メッセンジャー・サーバ８５０は、ユーザから受け取ったログオン情報を含む識別確認クエリをＡＢＣＨ８３０に送る。一部の実施形態では、メッセンジャー・クライアント８８０は、識別確認クエリをＡＢＣＨ８３０に直接送る。この場合、ＡＢＣＨ８３０からのどの応答も、メッセンジャー・クライアント８８０に直接送ることができる。ＡＢＣＨ８３０は、ログオン確認クエリを受け取り、そのログオンを確認する。

一部の実施形態では、ＡＢＣＨ８３０は、そのユーザ名が存在し、そのユーザによって提供されたパスワードが、ＡＢＣＨ８３０に格納されているパスワードと一致することを確認する。別の実施形態では、メッセンジャー・クライアントまたはメッセンジャー・サーバが、ログイン情報を資格証明サーバ（図８には示さず）に送り、それに対して資格証明情報を受け取ることができる。資格証明情報は次いで、ＡＢＣＨ８３０に提供することができる。ＡＢＣＨ８３０は次いで、資格証明情報を確認し、オペレーション（operation）は継続する。

ログオン情報を確認すると、ＡＢＣＨ８３０は、メッセンジャー・サーバ８５０に識別確認返答を送る。一部の実施形態では、返答は、ユーザ名、ユーザに関連付けられたメッセージ通信コンタクト・リスト、各コンタクトがコンテンツ・ページに関連付けられるかどうかの指示（indication）、およびユーザ名に関連付けられたユーザがコンテンツ・ページをもっているかどうかの指示（indication）、を含む。一実施形態では、この指示（indication）は、ユーザがコンテンツ・ページをもっていることを示すフラグの形、例えばＨａｓＰａｇｅフラグでよい。メッセンジャー・サーバ８５０は、ＡＢＣＨ８３０から確認応答を受け取る。メッセンジャー・サーバ８５０は次いで、ユーザのメッセージ通信コンタクト・リストにあるコンタクトに対して存在情報を決定する。一部の実施形態では、メッセンジャー・サーバ８５０は、メッセージ通信コンタクト・リストにある各コンタクトが現在、メッセンジャー・サーバ８５０にサインインしているかどうか決定することによって、存在を決定する。メッセンジャー・サーバ８５０にサインインしているコンタクトは、オンラインという存在状況を有する。コンタクトがメッセンジャー・サーバ８５０にサインインしていない場合、コンタクトは、オフラインという存在状況を有する。各コンタクトに対して存在を決定した後、メッセンジャー・サーバ８５０は、ユーザ用のメッセンジャー・コンタクト・リスト、各コンタクトごとの存在情報、各コンタクトがコンテンツ・ページをもっているかどうかの指示（indication）、を含む返答をメッセンジャー・クライアント８８０に送る。

ログオンの後、メッセンジャー・クライアント８８０は、ステップ９２０で、格納サーバ８２０にコンテンツ・ページ・バージョン要求を伝送する。一実施形態では、コンテンツ・ページ・バージョン要求は、どのモジュールがそのバージョン要求に関連しているかに関するフィルタ情報と、メッセンジャー・コンタクト・リストに関連付けられたコンテンツ・ページそれぞれに対して、メッセンジャー・クライアント８８０に既知のコンテンツ・ページ識別子および最新のバージョン情報とを含むことができる。フィルタ情報は、コンテンツ・ページに関連付けられた要約モジュールに含まれるコンテンツ・ページ・コンポーネントを示す。コンテンツ・ページ・バージョン要求中のコンテンツ・ページ識別子は、コンテンツ・ページを一意に識別する。

コンテンツ・ページ・バージョン要求を受け取ると、格納サーバ８２０は、ステップ９３０で、要求された要約モジュールに関連付けられたコンテンツ・ページ識別子を取り出す。メッセンジャー・クライアント８８０が、ある特定のコンテンツ・ページのバージョン情報を初めて要求しており、そのコンテンツ・ページ識別子を知らない場合、格納サーバ８２０は、そのコンテンツ・ページ識別子を決定する必要がある。格納サーバ８２０によってコンテンツ・ページ識別子を決定する方法を、図１０に示す。ステップ１０１０で、格納サーバ８２０は、コンテンツ・ページ・バージョン要求中にあるコンタクト識別子を受け取る。コンタクト識別子を有するコンテンツ・ページ・バージョン要求を受け取った後、格納サーバ８２０は、ステップ１０２０で、コンタクト識別子が有効であることを確認するために、ＡＢＣＨ８３０に確認要求を送る。一部の実施形態では、格納サーバ８２０は、ステップ１０１０で受け取ったコンタクト識別子から、代替コンタクト識別子を決定する。代替コンタクト識別子は次いで、ステップ１０２０でＡＢＣＨ８３０に送られる。

一実施形態では、コンテンツ・ページ・バージョン要求は、メッセンジャー・クライアントが、バージョン情報が返されるべきコンテンツ・ページ・コンポーネントのサブセットを決定するフィルタを指定することを可能にする。このフィルタは、発信者が、属性／値のペア、特定のコンテンツ・タイプ、またはこれらの組合せ、を指定することを可能にする。格納サーバは、指定された基準に合致するコンテンツ・ページ・コンポーネント用のバージョン情報を収集することができる。格納サーバによって返されるバージョン情報は、同じフィルタ値を指定する将来のクエリに適用することができる。

ステップ１０３０で、そのコンタクト識別子が有効であることを確認するために、ＡＢＣＨ８３０は、コンタクトのリスト中でそのコンタクト識別子を探す。コンタクトのリスト中にコンタクト識別子が見つかった場合、コンタクト識別子は、有効であると決定され、オペレーションは、ステップ１０４０に続く。そのコンタクト識別子が見つからない場合、ＡＢＣＨ８３０は、ステップ１０３５で、格納サーバ８２０にエラー・メッセージを返す。

ＡＢＣＨ８３０は、ステップ１０４０で、格納サーバ８２０にコンテンツ・ページ識別子を送る。格納サーバ８２０は次いで、要求側ユーザがコンテンツ・ページの閲覧を許可されているかどうか決定する。この決定を行うために、格納サーバ８２０は最初に、ステップ１０５０で、コンテンツ・ページに関連付けられた許可リストを取り出す。許可リストは、コンテンツ・ページの閲覧を認可されたユーザのリストであり、許可リスト識別子およびコンテンツ・ページの閲覧を認可されたコンタクト識別子のリストを含む。格納サーバ８２０は次いで、ステップ１０６０で、ユーザがコンテンツ・ページの閲覧を許可されているかどうか決定する。ユーザ識別子が許可リストに載っている場合、ユーザは、コンテンツ・ページの閲覧を認可され、オペレーションは、ステップ１０７０に続く。許可リストに載っていない場合、格納サーバ８２０は、ステップ１０６５で、ユーザが要約モジュールの閲覧を認可されないことを示すエラーを、メッセンジャー・クライアント８８０に返す。

一実施形態では、ステップ１０３０から１０６０は、ＡＢＣＨ８３０および格納サーバ８２０ではなくＡＢＣＨ８３０によって実施される。この場合、ＡＢＣＨ８３０は、格納装置から、閲覧者がコンテンツ・ページの閲覧を許可されるかどうか決定するための要求を受け取る。ＡＢＣＨ８３０は次いで、コンテンツ・ページの所有者に関連付けられた許可リストにアクセスする。ＡＢＣＨ８３０が、ステップ１０６０で、許可リストによって閲覧者がコンテンツ・ページの閲覧を認可されると決定した場合、オペレーションはステップ１０７０に続く。閲覧を認可されないと決定した場合、オペレーションはステップ１０６５に続く。

一実施形態では、コンテンツ・ページの所有者は、異なるコンタクトに対して異なる許可を提供することができる。例えば、コンテンツ・ページの所有者は、一部のコンタクトには、コンテンツ・ページのすべてのコンポーネントを閲覧させ、他のコンタクトには、コンテンツ・ページの選択されたコンポーネント（例えば、名前およびｅメール情報またはブログ・コンポーネントのみ）を閲覧させ、一部のコンタクトには、どのコンタクト・ページ・コンテンツも閲覧させないことができる。その結果、個々のコンタクトが、同じコンテンツ・ページ（コンタクトが閲覧を許可されたコンテンツ）から、異なるコンテンツを有する要約モジュールを受け取りことができる。

方法９００に戻ると、格納サーバ８２０は、ステップ９４０で、コンテンツ・ページ・バージョン要求が１組のコンテンツ・ページ・コンポーネントを指定しているかどうか決定する。コンテンツ・ページ・コンポーネントを指定するコンテンツ・ページ・バージョン要求は、メッセンジャー・クライアント８８０にとって既知であるコンテンツ・ページおよびそのコンポーネントの最新のバージョンを含む。メッセンジャー・クライアント８８０が以前に要約モジュールに関する情報を要求したことがない場合、コンポーネント情報は、コンテンツ・ページ・バージョン要求中で指定されない可能性がある。一実施形態では、クライアントによって提供される最新のバージョン情報は、メッセンジャー・クライアント８８０がその特定のコンポーネントに関する要約モジュール・コンテンツを受け取った日付を示すタイム・スタンプである。コンテンツ・ページおよびそのコンポーネントそれぞれに関する実際の最新バージョン情報は、格納サーバ８２０に格納される。そのコンテンツ・ページに関する最新のバージョン情報は、コンテンツ・ページ・コンポーネントのいずれかに対する最新の変更の日付である。

コンテンツ・ページ・バージョン要求は、メッセンジャー・クライアントが、バージョン情報が返されるべきコンテンツ・ページ・コンポーネントのサブセットを決定するフィルタを指定することを可能にする。このフィルタは、発信者が、属性／値のペア、具体的なコンテンツ・タイプ、またはこれらの組合せを指定するのを可能にする。格納サーバは、指定された基準に合致するコンテンツ・ページ・コンポーネントのみに関するバージョン情報を収集する。格納サーバによって返されるバージョン情報は、同じフィルタ値を指定する将来のクエリに対してのみ有効である。

要求がコンポーネントを指定している場合、オペレーションは、ステップ９４２に続き、ここで、格納サーバ８２０は、指定されたコンポーネントに関するバージョン情報にアクセスする。コンポーネントが、コンテンツ・ページ・バージョン要求中で指定されていない場合、オペレーションは、ステップ９４４に続き、ここで、格納サーバ８２０は、各コンテンツ・ページ中の各コンポーネントに関するフィルタ情報にアクセスすることによって、最新のバージョンおよび／またはどのコンポーネントが含まれるべきか決定する。一実施形態では、フィルタ情報は、各コンテンツ・ページ・コンポーネントに関連付けられた注釈として実装される。例えば、ＣｏｍｐｏｎｅｎｔＦｉｌｔｅｒ注釈が、コンポーネントが要約モジュールに含まれる場合、値１となり、要約モジュールに含まれない場合、値ゼロとなり得る。コンポーネントに関するフィルタ情報が要求に含まれる場合、格納サーバ８２０は、ステップ９４２で、そうしたコンポーネントに関するコンポーネント・タイム・スタンプにアクセスし格納する。

一実施形態では、格納サーバ８２０は、ステップ９５０で、コンテンツ・ページ中のコンポーネントが、ユーザによって要約モジュールが最後に閲覧されて以降、アップデートされているかどうか決定する。この決定を行うために、格納サーバ８２０は、コンテンツ・ページ・バージョン要求中の各コンポーネントに関する最新のバージョン情報を、コンテンツ・ページに関連付けられた実際の最新バージョン情報と比較する。一実施形態では、格納装置は、ブログ中のブログ・エントリおよびフォト・アルバム中のイメージなど、各コンポーネントの子項目（child items）にアクセスし、子項目のタイム・スタンプを、メッセンジャー・クライアント８８０から受け取ったタイム・スタンプと比較する。格納コンポーネントの１つまたは複数が、メッセンジャー・サーバ８５０から受け取った最新のバージョン情報以降にアップデートされている場合、ステップ９５２で、新しい項目インジケータ（new item indicator）を、コンテンツ・ページが新しいコンテンツを有することを反映するようにセットすることができる。一実施形態では、新しい項目インジケータは、フラグ、例えばＨａｓＮｅｗＩｔｅｍフラグとして実装することができる。コンテンツ・ページが、ユーザによる最終閲覧以降に変更されていない場合、新しい項目インジケータは、ステップ９５４で、偽にセットされる。

格納サーバ８２０は、ステップ９６０で、メッセンジャー・クライアント８８０にコンテンツ・ページ・バージョン応答を送る。コンテンツ・ページ・バージョン応答は、コンテンツ・ページ識別子、コンテンツ・ページの最終更新情報、新しい項目インジケータ、許可リスト識別子、および各コンポーネントに対するコンポーネントの要約を含むことができる。コンポーネントの要約は、各コンポーネントに対するコンポーネント識別子およびコンポーネントのタイム・スタンプを含むことできる。一部の実施形態では、コンテンツ・ページ・バージョン要求は、メッセンジャー・クライアントが、最大３００までのメッセンジャー・コンタクトに対してコンテンツ・ページを要求することを可能にし、最大３００のコンテンツ・ページまでの情報を返すことができる。

メッセンジャー・クライアント８８０は、ステップ９７０で、応答を受け取り、処理する。メッセンジャー・クライアント８８０の処理は、応答情報をローカルに格納することを含むことができ、応答からのコンポーネント・バージョン情報を、ローカル・メモリに収容されたどのコンポーネント・バージョン情報とも比較する。より最新のコンポーネント・バージョンが受け取られた各コンタクトに対して、ステップ９８０で、メッセンジャー・ユーザ・インターフェース内に視覚インジケータが提供される。各視覚インジケータは、ユーザ・インターフェース内のコンタクト・インジケータに関連付けられる。一部の実施形態では、格納サーバ８２０は、どのコンポーネントが要約モジュールに含まれるかを示す１組のコンポーネント識別子を返す。この場合、メッセンジャー・クライアント８８０は、ユーザに対して許可が変更されたことを示すコンポーネント識別子の新しい組がコンテンツ・ページ・バージョン応答中で受け取られたかどうかも決定する。コンポーネント識別子の組が変更された場合、メッセンジャー・クライアント８８０は、その新しい組を格納し、次回そのコンテンツ・ページに関する情報を要求するときに、その新しい組を要求する。

一実施形態では、コンテンツ・ページの所有者が、（メッセンジャー・サーバ８５０によって提供されるような）インスタント・メッセージ（ＩＭ）システムにログインすると、ＩＭシステムは、コンテンツ・ページの所有者がオンラインであり、コンテンツ・ページに関連付けられていることを、ＩＭシステム・ユーザで、彼らのメッセンジャー・コンタクト・リスト上にそのコンテンツ・ページの所有者を有しているＩＭシステム・ユーザに、知らせることになる。例えば、コンテンツ・ページの所有者が、メッセンジャー・クライアント８８０を介してメッセンジャー・サーバ８５０にログインすると、メッセンジャー・サーバ８５０は、他のメッセンジャー・クライアント・アプリケーションに、そのコンテンツ・ページの所有者が現在オンラインであり、コンテンツ・ページに関連付けられていることを伝達する。メッセンジャー・クライアント・アプリケーションは次いで、それに従ってそのユーザ・インターフェースをアップデートすることができる。こうすることにより、コンタクトがコンテンツ・ページに関連付けられているという指示（indication）を受け取る追加手段が提供される。

一実施形態では、システム８００は、ユーザ・セッションの間、ユーザのメッセンジャー・コンタクト・リスト中のコンタクトに関連付けられたコンテンツ・ページが変更されたという通知を提供することができる。図１１の方法１１００は、ユーザがメッセンジャー・サーバ８５０にログインしている間、ユーザ・インターフェースにおいて視覚インジケータをコンタクト・インジケータに追加する方法を示す。ステップ１１１０で、コンテンツ・ページ変更が保存される。一部の実施形態では、ステップ１１１０は、変更の保存とは無関係に、コンテンツ・ページに変更が行われたことを検出することを備える。

別の実施形態では、コンテンツ・ページの所有者が、コンテンツ・ページの通知を構成することができる。例えば、コンテンツ・ページの所有者が、いつ通知が送られるか（周期的に、またはイベントの発生に基づいて）、どのモジュールおよびアクションが通知をトリガし得るか、どのコンタクトまたはグループに通知が送られるべきか、どのデバイスおよびチャネルが通知を受け取るべきか（メッセンジャー・クライアント、携帯電話、ｅメールなど）を示すことができる。

一実施形態では、コンテンツ変更の検出は、変更を保存しているコンテンツ・ページの所有者と、その変更が公開されるべきか、それともそのコンテンツ・ページの所有者を自分のメッセンジャー・コンタクト・リストに載せているコンタクトにブロードキャストされるべきか、という指示（indication）とを含む。いずれの実施形態においても、コンテンツ変更は、格納サーバ８２０に変更を伝達することによって検出されることになる。別の実施形態では、この変更は、ＡＢＣＨ８３０または他の何らかのサーバに伝達される。一実施形態では、変更は、あるコンポーネントにおける新しい項目の追加、既存の項目の変更、または項目の消去の１つまたは複数を含むことができる。例えば、ユーザによって、ブログ・エントリを追加し、写真またはアルバム全体を変更し、あるいは歌をプレイ・リストから消去することができる。

変更が行われると、格納サーバ８２０は、どのコンタクトに変更が送られるべきか決定する。一実施形態では、格納サーバ８２０は、そのコンテンツ・ページの閲覧を許可されているコンタクトおよびそのコンテンツ・ページの所有者のメッセンジャー・リバース・リストに属すコンタクトの交点（共通集合：intersection）から、リストを取り出す。コンテンツ・ページの閲覧を許可されているコンタクトは、格納サーバ８２０に格納されている許可リストから、許可リスト識別子を使って取り出される。そのページの所有者のメッセンジャー・リバース・リストに載っているコンタクトは、そのページの所有者を自分自身のメッセンジャー・コンタクト・リストに載せているコンタクトである。したがって、リバース・リスト・メンバは、そのページの所有者を、メッセンジャー・クライアント８８０のユーザ・インターフェースに表示される、自分のコンタクトの１つとして載せているメンバである。

格納サーバ８２０は、ステップ１１２０で、許可リストおよびリバース・メッセンジャー・リストを取り出す。一実施形態では、許可リスト識別子およびリバース・メッセンジャー・リストは、格納サーバ８２０によってＡＢＣＨ８３０から取り出される。格納サーバ８２０は次いで、許可識別子リストを使って、許可リストを取り出す。両方のリストが取り出されると、格納サーバ８２０は、ステップ１１３０で、許可およびリバース・メッセンジャー・リスト両方で見つかったコンタクトを含む共通コンタクト・リストを生成する。

格納サーバ８２０は、ステップ１１４０で、コンテンツ・ページに行われた変更に対して、アラートを生成する。一実施形態では、既存のコンポーネントに対する、新たに追加されたコンポーネントまたは新しいエントリを伴う変更に対してアラートが生成される。アラートのパラメータは、コンテンツ・ページ識別子と、コンポーネント識別子と、コンポーネントおよびコンテンツ・ページに関する最新のバージョンまたは最終更新日と、実施されるアクション（例えば、挿入、変更、または消去）と、変更が視覚インジケータをクライアントインターフェース内に表示させるかどうかを示す新しい項目インジケータと、変更されたコンポーネントに関するコンポーネントの要約とを含むことができる。アラート・コンポーネントの要約は、アラート・コンポーネントの要約が具体的なコンポーネントに関すること以外、コンテンツ・ページ・バージョン応答コンポーネントの要約と同様でよい。アラート・コンポーネントの要約は、コンポーネント識別子および項目識別子配列を含む。コンポーネント識別子は、コンテンツ・ページ・バージョン応答中のものと同じである。項目識別子配列は、変更されたコンポーネント中の子または項目の識別子の配列である。例えば、項目配列は、フォト・アルバム中の消去された写真、変更されたブログ・エントリ、プレイ・リスト中の新しい歌、または他の何らかの項目の識別子を含むことができる。

アラートは、ＸＭＬ形式で送ることができる。一部の実施形態では、アラートは、格納サーバ８２０によってエンコードすることができる。エンコードされていない、すなわちデコードされたＸＭＬでのアラートの例を、以下に示す。

アラート・サーバ８４０は、ステップ１１３０で派生された共通コンタクト・リストを有するアラート・パッケージを、ステップ１１５０でメッセンジャー・サーバ８５０に送る。メッセンジャー・サーバ８５０は、アラートを受け取り、ステップ１１６０で、共通コンタクトのどれがメッセンジャー・サーバ８５０にサインインしているか決定する。メッセンジャー・サーバ８５０は次いで、ステップ１１７０で、そうしたコンタクトに関連付けられたメッセンジャー・クライアント８８０のアプリケーションにアラート・パッケージを送る。一部の実施形態では、アラートは、システムに応じて、メッセンジャー・クライアント８８０、ブラウザ、モバイル・デバイス、ｅメール・サーバ８７２、または他のエンティティに経路指定することができる。アラートを受け取ることになるコンタクトがサインインしていない場合、アラート・パッケージは無視される。コンタクトは、メッセンジャー・クライアント８８０が要約モジュールキャッシュ情報をコンテンツ・ページの最新バージョン情報と比較する次のログオン時にアップデートを受け取る。

メッセンジャー・クライアント８８０は、ステップ１１８０でアラート・パッケージを受け取る。ステップ１１９０で、メッセンジャー・クライアント８８０は、アラートを処理し、ユーザ・インターフェースにおいて視覚指示が提供されるべきかどうか決定する。最初に、そのアラートが、メッセンジャー・クライアント８８０は、ユーザのメッセンジャー・コンタクト・リストに含まれる（例えば、メッセンジャー・コンタクト・リストから消去されていない）コンタクトに関連付けられているかどうか決定する。メッセンジャー・クライアント８８０は次いで、最終更新日情報が、ローカル・メモリに格納されているコンポーネントに関する最終更新日より最新かどうか決定する。一実施形態では、クライアントは、そのリスト中の新しい項目インジケータ（new item indicator）が、視覚インジケータが提供されるべきであると示す（そうすることによって、少なくとも１つのコンポーネントに新しいコンテンツがあることを示す）場合のみ、この決定を行う。アラートがメッセンジャー・コンタクト・リスト中のコンタクトに関連付けられており、少なくとも１つのコンポーネントに関する最終更新日が、キャッシュされたコンポーネントのものより最新である場合、メッセンジャー・クライアント８８０は、ステップ１０９２で、そのコンタクトに対応するインジケータを提供する。それ以外の場合、オペレーションは、ステップ１１９４に続き、ここでは、メッセンジャー・クライアント８８０は、この特定のコンタクトに対する視覚インジケータを提供しない。クライアントはまた、コンポーネントおよびコンポーネント項目両方に関する最終更新日情報、ならびに新しいコンポーネントによって示される要約モジュールに対する変更を含むアラート・パッケージ情報を格納する。

メッセンジャー・クライアント８８０は、要約モジュールが表示されるべきであることを示す入力を受け取ると、どこから要約モジュールをロードするか決定することになる。入力は、コンタクト存在インジケータ、コンタクト識別子、またはコンタクト用のコンテンツ・ページに関連付けられた他の何らかの視覚インジケータ上でのマウスの右ボタン・クリックなどの選択を含むことができる。図１２の方法１２００は、要約モジュール用のソースを決定する方法を示す。メッセンジャー・クライアント８８０は、ステップ１２１０で、要約モジュール要求を受け取る。メッセンジャー・クライアント８８０は次いで、ステップ１２２０で、要約モジュールのキャッシュされたバージョンが入手可能かどうか決定する。キャッシュされたバージョンは、メッセンジャー・クライアント８８０が要約モジュールを以前受け取ったことがある場合、利用できる可能性がある。キャッシュされたバージョンが利用可能でない場合、オペレーションは、ステップ１２６０に続く。

キャッシュされたバージョンが利用可能な場合、オペレーションは、ステップ１２３０に続き、ここで、システムは、ログイン時にコンテンツ・ページ・バージョン応答で受け取ったタイム・スタンプが、要約モジュールのキャッシュされたバージョンに関連付けられたタイム・スタンプより最新であるかどうか決定する。コンテンツ・ページ・バージョン応答にあるタイム・スタンプが、キャッシュされた要約モジュールのタイム・スタンプより最新である場合、オペレーションは、ステップ１２６０に続く。最新でない場合、システムは、ステップ１２４０で、コンテンツ・ページが変更されたことを示すアラートが受け取られていたかどうか決定する。一実施形態では、コンテンツ・ページが変更されたことを示すアラートが受け取られていた場合、メッセンジャー・クライアント８８０によって格納されている新しい項目インジケータがこのことを示す。したがって、メッセンジャー・クライアント８８０は、インジケータの値を取り出して、コンテンツ・ページ変更アラートが受け取られていたかどうか決定することができる。アラートがステップ１２４０で受け取られていた場合、オペレーションは、ステップ１２６０に続く。アラートがステップ１２４０で受け取られていなかった場合、オペレーションは、ステップ１２５０に続く。ステップ１２６０で、システムは、要約モジュールのキャッシュされたバージョンが古いものになっている可能性があり、要約モジュール・データの最新のバージョンが要求されるべきであると、決定する。ステップ１２５０で、メッセンジャー・クライアント８８０は、要約モジュール・データが最後にロードされて以降、コンテンツ・ページに対して変更が行われていないと決定する。したがって、要約モジュールは、キャッシュされたバージョンからロードされることになる。

一部の実施形態では、メッセンジャー・クライアント８８０は、コンタクトに関連付けられたコンテンツ・ページが新しい項目、例えばＨａｓＮｅｗＩｔｅｍフラグを有するかどうかを示すインジケータを保持することができる。したがって、各コンタクトに対して、コンテンツ・ページ・バージョン応答で受け取ったタイム・スタンプが、キャッシュされたタイム・スタンプより最新である場合、コンテンツ・ページが変更されたことを示すアラートが受け取られた場合、あるいはキャッシュされたバージョンがない場合、この新しいコンテンツ・フラグは、コンテンツ・ページおよび対応する要約モジュール・データが変更されたことを示す値を収容する。方法１２００を通して実行することをせずに、このシステムは、新しいコンテンツ・フラグの値を調べて、どこから要約モジュールがロードされるべきか決定する。

図１３は、要約モジュールを取り出す方法１３００を示す。メッセンジャー・クライアント８８０は、ステップ１３１０で、あるユーザ向けの要約モジュールを閲覧するための要求を受け取る。一部の実施形態では、メッセンジャー・クライアントは、コンテンツ・ページ・サーバ８１０または格納サーバ８２０をポーリングすることができる。この場合、要約モジュールが変更されているという指示（indication）をポーリングが返すと、要約モジュール・データに対する要求がトリガされる。要求が受け取られると、メッセンジャー・クライアント８８０は、ステップ１３２０で、その要約モジュールを求めるコンテンツ・ページ・サーバ８１０への要約モジュール・コンテンツ要求を伝送する。

一実施形態では、メッセンジャー・クライアント８８０は、格納サーバ８２０に直接、要約モジュール・データ要求を伝送する。この場合、格納サーバ８２０は、要約モジュール・データ応答をメッセンジャー・クライアント８８０に直接伝送することができる。要約モジュール・データ要求および要約モジュール・データ応答については、後でより詳しく論じる。

要約モジュール・コンテンツ要求は、コンテンツ・ページ識別子、コンテンツ・ページの最終更新日、どのコンポーネントからコンテンツを返すかを示すフィルタ、コンポーネントエントリ・タイプ、各タイプごとのエントリの数、およびコンポーネントの子を返すためのフィールドを含むパラメータを有することができる。

要約モジュール・コンテンツ要求の例を、以下に示す。

コンテンツ・ページ・サーバ８１０は、ステップ１３２５で、要求を受け取り、格納サーバ８２０に対して、要約モジュール・データ要求を生成する。格納サーバ８２０への要求は、メッセンジャー・クライアント８８０による要約モジュールの最終閲覧のタイム・スタンプを含む。タイム・スタンプは、要約モジュールがメッセンジャー・クライアント８８０によって以前要求されたことがない場合、ゼロ、すなわち偽の値になり得る。要求は、要約モジュールの具体的なコンポーネント、およびいくつかの子項目も示すことができる。子項目の数は、要求されたサムネイルの数、ブログ・エントリの数、歌の数、または他の何らかのデータに関連することができる。

コンテンツ・ページ・サーバ８１０から格納サーバ８２０への要約モジュール・データ要求用の形式の一例を、以下に示す。

要約モジュール・データ要求は、ステップ１３３０で格納サーバ８２０に送られる。

一実施形態では、要求されたデータをコンテンツ・ページ・サーバ８１０に提供する前に、格納サーバ８２０は、ステップ１３４０で、要求したユーザが要約モジュールの閲覧を許可されているかどうか確認する。格納サーバ８２０は、ステップ１３４０で、要約モジュール・データ要求が、コンテンツ・ページに関する許可リスト識別子を含むかどうか決定する。許可リスト識別子が含まれている場合、オペレーションは、ステップ１３５５に続く。含まれていない場合、格納サーバ８２０は、コンテンツ・ページ識別子を使って、ＡＢＣＨ８３０に対して許可リスト識別子を要求する。ステップ１３５０で、ＡＢＣＨ８３０は、その要求を受け取り、許可リスト識別子を取り出し、格納サーバ８２０に識別子を提供する。オペレーションは次いで、ステップ１３５５に続く。

格納サーバ８２０は、ステップ１３５５で、許可リスト識別子を使って許可リストを取り出し、ＡＢＣＨ内の許可リストを使って、ユーザがコンテンツ・ページの閲覧を許可されているかどうか決定する。ユーザが許可されていない場合、格納モジュールは、ステップ１３５７で、コンテンツ・ページ・サーバ８１０にエラー・メッセージで返答する。コンテンツ・ページ・サーバ８１０は次いで、ユーザが要約モジュールの閲覧を許可されていないこと、またはカードが利用可能でないことを示すメッセージを、メッセンジャー・クライアント８８０に送る。ユーザが許可リストに載っている場合、ユーザは、コンテンツ・ページの閲覧を許可され、オペレーションは、ステップ１３６０に続く。

格納サーバ８２０は、ステップ１３６０で、コンテンツ・ページ・サーバ８１０の要求を処理し、コンテンツ・ページ・サーバ８１０に要約モジュール・データ応答を送る。要求の処理は、要求のフィルタ情報によって指定されるとともにクライアントによって提供される最終更新日よりも最終更新日が最新である最終更新日を有する、コンポーネントおよび子項目へアクセスすることを含むことができる。コンテンツ・ページ識別子が無効であるか、または閲覧許可が拒否された場合、格納サーバ８２０は、エラーを返すことができる。

要約モジュール・データ応答は、コンテンツ・ページ識別子、コンテンツ・ページが最後に更新された日付、クライアントによって提供された最後に更新された日付以降にいずれかのコンポーネントが変更されたことを示す新しい項目インジケータ、および各コンポーネントに関するコンポーネント要約、を含む複数のパラメータを有することができる。コンポーネント要約は、上で論じたように識別子およびタイム・スタンプを提供する。

要約モジュール・データ応答形式の例を、以下に示す。

要約モジュール・データ応答を受け取ると、コンテンツ・ページ要約は、ステップ１３７０で、データを処理し、処理したコンテンツをメッセンジャー・クライアント８８０に伝送する。この処理は、適正な言語でのコンテンツを貼り付けること、ブログ・エントリからのヘッダおよびフォーマット情報を削除すること、ならびに他のタスクを含むことができる。コンテンツ・ページ・サーバ８１０からメッセンジャー・クライアント８８０に送られる要約モジュール・コンテンツ応答の例を、以下に示す。

次に、ステップ１３８０で、メッセンジャー・クライアント８８０は、要約モジュール・コンテンツ応答を受け取る。メッセンジャー・クライアント８８０は、応答内の情報を格納し、要約モジュールを生成する。一部の実施形態では、クライアントによって格納される情報は、コンテンツ・ページ、コンポーネント・ページおよびコンポーネントの子の識別子およびタイム・スタンプ、ＨａｓＮｅｗＳｐａｃｅフラグ、許可リスト識別子、ならびにそれ以外のもののうち１つを含むことができる。

一実施形態では、要約モジュールは、ネットワーク・ブラウザ、例えばウェブ・ブラウザ上に実装されるメッセージ・サービスを介して閲覧されることが可能である。ウェブ・サービスとして実装されるＩＭユーザ・インターフェースは、メッセンジャー・クライアント８８０と同じユーザ・インターフェースおよびユーザ・エクスペリエンスを有し得る。コンテンツ・ページ・サーバ８１０、格納サーバ８２０、およびＡＢＣＨ８３０の間の通信も同じである。唯一のプロトコル変更は、メッセンジャー・ウェブ・サービス８６０とコンテンツ・ページ・サーバ８１０の間で発生する。ネットワーク・ブラウザとして実装されるＩＭユーザ・インターフェースに視覚インジケータを追加する方法１４００を、図１４に示す。ポーリング・イベントが、ステップ１４１０でトリガされる。ウェブ・メッセンジャーには、メッセンジャー・クライアント８８０にあるような、メッセンジャー・サーバ８５０への専用の接続がない。したがって、コンテンツ・ページがアップデートされているかどうか決定するために、ウェブ・メッセンジャーは、アラートのためにメッセンジャー・サーバ８５０を周期的にポーリングすることができる。ポーリング・イベントは、期間の満了など、内部的に生成されるイベントによっても、ユーザ入力によってもトリガすることができる。ポーリング・イベントがトリガされると、ブラウザは、ステップ１４２０で、メッセンジャー・ウェブ・サーバにコンテンツ・ページ・バージョン要求を伝送する。一実施形態では、ステップ１４２０の要求は、ＨＴＴＰ要求の形で行われる。この要求を受け取ると、メッセンジャー・ウェブ・サーバは、ステップ１４３０で、ユーザのメッセンジャー・コンタクト・リストに関連付けられたコンタクト・ページに関する変更されたコンテンツ・ページ情報を求める要求を、メッセンジャー・サーバ８５０に伝送する。

メッセンジャー・サーバ８５０は、ステップ１４４０で変更を決定する。一実施形態では、メッセンジャー・サーバ８５０は、メッセンジャー・コンタクト・リストに関連する、受け取ったどのアラートにもアクセスする。別の実施形態では、メッセンジャー・クライアント８８０は、該当するコンテンツ・ページに関する最新のタイム・スタンプ情報を、格納サーバ８２０から取り出す。メッセンジャー・サーバ８５０は次いで、ステップ１４５０で、メッセンジャー・ウェブ・サーバに返答を伝送する。一実施形態では、要求されたどの視覚インジケータ向けにウェブ・メッセンジャーに対して行われる変更も、ｊａｖａ（登録商標）スクリプト・イベントとして提供される。ｊａｖａ（登録商標）スクリプト・イベントは、どのようにして、ネットワーク・ブラウザが変更されたコンテンツ・ページを有するコンタクト用の視覚インジケータを含むようにアップデートされるかを示す。メッセージは次いで、ステップ１４６０でウェブ・メッセンジャーによって受け取られて、ユーザ・インターフェースがアップデートされる。

ネットワーク・ブラウザにおいて視覚インジケータが提供されると、ユーザは、視覚インジケータを選択して、要約モジュールを閲覧することができる。一実施形態では、要約モジュールは、別個のネットワーク・ブラウザ内のインターフェースとして実装することができる。ネットワーク・ブラウザ内で提供されるＩＭインターフェースによって要約モジュールを提供する方法１５００を、図１５に示す。方法１５００は、ステップ１５１０で始まり、ここで、視覚インジケータを選択する入力が受け取られる。一実施形態では、視覚インジケータは、ネットワーク上の要約モジュール・ページへのリンクである。ステップ１５２０で、メッセンジャー・ウェブ・サービス８６０は、コンテンツ・ページ・サーバ８１０に要約モジュール・データを要求する。要約モジュール・データ要求は、コンテンツ・ページ・サーバ８１０によって受け取られ、ステップ１５３０で処理される。一実施形態では、要求は、図１３のステップ１３２５から１３６０を参照して論じたように処理される。格納装置が要約モジュール・データを受け取った後、データは、メッセンジャー・ウェブ・サーバ用にパッケージされ、ステップ１５４０で伝送される。メッセンジャー・ウェブ・サーバは、ステップ１５５０でパッケージを受け取り、要約モジュールを提供する。一実施形態では、要約モジュール・データは、ＨＴＭＬとしてパッケージされ、要約モジュールを別個のウェブ・ページとして提供することを可能にする。

一実施形態では、要約モジュールは、ｅメール・ウェブ・サービスを介して提供することができる。図１４および１５を参照して論じたウェブ・メッセンジャー・サービスと同様、ｅメール・ウェブ・サービスは、ウェブ・ブラウザを介して実装される。したがって、要約モジュールは、ｅメール管理インターフェースと平行する別個のブラウザ内で、またはネットワーク・ブラウザ内に提供されるｅメール管理インターフェース内で、提供することができる。ｅメール・ウェブ・サービス用の視覚インジケータおよび要約モジュールを提供する方法は、ウェブ・ブラウザが、メッセンジャー・ウェブ・サービス８６０およびメッセンジャー・ウェブ・サーバではなく、ｅメール・サーバ８７２を介してコンテンツ・ページ・サーバ８１０と通信することを除いて、方法１４００および１５００のものと同じである。したがって、要約モジュールは、コンテンツ・ページ・ウェブ・サービスによって、ウェブ・サイトとして実装される。

図１６〜１８は、ネットワーク・ブラウザ、例えばウェブ・ブラウザ内で提供されるｅメール管理インターフェースにおいて要約モジュールを提供する例を示す。図１６は、ネットワーク・ブラウザ１６１０、ｅメール・インターフェース・ページ１６２０、および要約モジュール１６３０を含む。ｅメール・インターフェース・ページ１６２０は、ユーザにｅメールを生成させる。要約モジュール１６３０は、ユーザによって生成されるｅメールにおいて署名として提供される。図１７は、ネットワーク・ブラウザ１７１０、ユーザ・コンタクト・ページ１７２０、および要約モジュール１７３０を含む。ユーザ・コンタクト・ページ１７２０は、ユーザがコンタクトを閲覧し、構成することを可能にする。要約モジュール１７３０は、ユーザによって構成することができるコンタクトの一部として提供される。図１８は、ネットワーク・ブラウザ１８１０、コンタクト・リスト・ページ１８２０、および要約モジュール１８３０を含む。コンタクト・リスト・ページ１８２０は、ユーザがコンタクトのリストを閲覧し、構成することを可能にする。要約モジュール１８３０は、ある特定のコンタクト用のフィールドとして提供される。

本発明の上記の詳細な説明は、例示および説明のために提示したものである。網羅的であることも、開示した厳密な形に本発明を限定することも意図していない。上記の教示に鑑みて、多くの修正形態および変形形態が可能である。記載した実施形態は、本発明の原理および実際的な適用を最もよく説明するために、また、そうすることによって、他の当業者が、本発明を、企図される特定の使用に適した様々な変更を伴って様々な実施形態において最もよく使用できるように選択した。本発明の範囲は、特許請求の範囲によって定義されることを意図している。

コンテンツ・ページの一実施形態を示す図である。要約モジュールのフロント・イメージの一実施形態を示す図である。要約モジュールのバック・イメージの一実施形態を示す図である。視覚インジケータを有する要約モジュールのフロント・イメージの一実施形態を示す図である。視覚インジケータを有する要約モジュールのバック・イメージの一実施形態を示す図である。ブログ・コンテンツが選択された要約モジュールの一実施形態を示す図である。写真コンテンツが選択された要約モジュールの一実施形態を示す図である。音楽コンテンツが選択された要約モジュールの一実施形態を示す図である。要約モジュールを構成する方法の一実施形態を示す図である。インスタント・メッセージ・ユーザ・インターフェースの一実施形態を示す図である。要約モジュールを提供するための入力を受け取るユーザ・インターフェースの一実施形態を示す図である。要約モジュールを提供するユーザ・インターフェースの一実施形態を示す図である。通知システムの一実施形態を示す図である。サービスへのログイン時に視覚インジケータを提供する方法の一実施形態を示す図である。コンテンツ・ページを閲覧する許可を決定する方法の一実施形態を示す図である。サービスへのログイン期間に、視覚インジケータを提供する方法の一実施形態を示す図である。要約モジュール・データが取り出されるソースを決定する方法の一実施形態を示す図である。要約モジュール・データを取り出す方法の一実施形態を示す図である。ネットワーク・ブラウザにおいて視覚インジケータを提供する方法の一実施形態を示す図である。ネットワーク・ブラウザにおいて要約モジュールを提供する方法の一実施形態を示す図である。ネットワーク・ブラウザによって提供されるｅメール生成インターフェースに統合された要約モジュールを示す図である。ネットワーク・ブラウザによって提供されるコンタクト管理インターフェースに統合された要約モジュールを示す図である。ネットワーク・ブラウザによって提供されるコンタクト・リスト・インターフェースに統合された要約モジュールを示す図である。

符号の説明

１００コンテンツ・ページ
１１０ユーザ・インターフェース・ウィンドウ
１２０ブログ・コンポーネント
１２１エントリ・タイトル
１２３第１のブログ・エントリ
１２４ブログ・ツール・バー
１２５第２のブログ・エントリ
１３０フォト・アルバム・コンポーネント
１３１イメージ
１３２第１のフォト・アルバム部分
１３３第２のフォト・アルバム部分
１４０リンク・コンポーネント
１５０音楽コンポーネント
１５１最近再生された歌のタイトルおよびアーティストのリスト
１６０プロファイル・コンポーネント
１６１ｅメールを送る（ｅメール・リンク）
１６２ＩＭに勧誘する（ＩＭリンク）
１７０個人的なメッセージ
１８０個人のイメージ
１９０オンライン・インジケータ
２００要約モジュールのフロント・イメージ
２１０カード
２１２ユーザ識別子
２１４カード反転インジケータ
２１６カード・クローズ・アイコン
２２０ニックネーム
２２２コンテンツ・タイトル
２３０フォト・アルバム・タイトル
２３２フォト・アルバムの説明
２３４サムネイル
２４０追加コンテンツ・リンク
２４２ｅメール・リンク
２４４ＩＭリンク
２４６コンテンツ・ページリンク
２４８プロファイル・イメージ
２５０バック・イメージ
２６０要約カード
２６４要約カード反転インジケータ
２６６要約カード・クローズ・アイコン
２７０コンタクト情報
２８０１つまたは複数の視覚インジケータを有する要約モジュールのフロント・ビュー
２８５カード（要約モジュール）
２８７サムネイル行
２８８アイコン（「もっと見る」というコンテンツ・インジケータ）
２９０バック・イメージ
２９５要約モジュール
２９７コンタクト情報
２９８視覚インジケータ
３１０、３３０、３６０要約モジュール
３１５、３４０、３６５カーソル
３２０要約モジュール内部のブログ・コンテンツ
３３５写真コンテンツ
３５０写真コンテンツ・ウィンドウ
３７０リスト・コンテンツ
３８０リスト・コンテンツ・ウィンドウ
５００ＩＭユーザ・インターフェース
５１０ウィンドウ
５１２ユーザ状況インジケータ（オンライン）
５１４メッセンジャー・コンタクト・リスト
５２０視覚インジケータ
５３０コンタクト・インジケータ
５３２オンライン・インジケータ
６００、７００メッセンジャー・クライアント（ユーザ）・インターフェース
６１０クライアント・インターフェース・ウィンドウ
６１５ユーザ・ニックネーム
６２０、７２０メッセンジャー・コンタクト・リスト
６３０コンタクト・ニックネーム
６３５、７３５コンタクト存在インジケータ
６４０メッセージ・ウィンドウ・ポインタ
６５０メッセージ・ウィンドウ
７１０インターフェース・ウィンドウ
７３０コンタクト・ニックネーム
７４０要約モジュール
７４２要約モジュール・コンタクト・ニックネーム
７４４、７４６要約モジュール・コンテンツ
８００システム
８１０コンテンツ・ページ・サーバ
８２０格納サーバ
８３０アドレス帳クリアリング・ハウス
８４０アラート・サーバ
８５０メッセンジャー・サーバ
８６０メッセンジャー・ウェブ・サービス
８７０クライアント・ウェブ・ブラウザ
８７２Ｅメール・サーバ
８８０メッセンジャー・クライアント
８８２インスタント・メッセンジャー・ユーザ・インターフェース
８８４コンタクト・カード
９００ユーザのログオン時にメッセンジャー・コンタクト・リストに視覚インジケータを追加する方法
１０００格納サーバ８２０によってコンテンツ・ページ識別子を決定する方法
１１００視覚インジケータをコンタクト・インジケータに追加する方法
１２００要約モジュール用のソースを決定する方法
１３００要約モジュールを取り出す方法
１４００ＩＭユーザ・インターフェースに視覚インジケータを追加する方法
１５００ＩＭインターフェースによって要約モジュールを提供する方法
１６１０、１７１０ネットワーク・ブラウザ
１６２０ｅメール・インターフェース・ページ
１６３０、１７３０要約モジュール
１７２０ユーザ・コンタクト・ページ

Claims

コンテンツ・ページにおけるコンテンツ変更の通知を、ネットワークを介して提供するために、インスタント・メッセージング・サービスを提供するサーバによって実行される方法であって、
コンテンツ・ページの少なくとも一部分にコンテンツ変更が行われたと決定することと、
前記コンテンツ・ページの所有者に関連付けられた、前記コンテンツ変更の通知を送信すべき１または複数のコンタクトを選択することであって、該選択された１または複数のコンタクトは、それぞれ、（ｉ）前記所有者によって前記コンテンツ・ページの閲覧が許可されたコンタクトをリストしている許可リストにおいて、前記コンテンツ変更が行われた前記コンテンツ・ページの閲覧が許可されたコンタクトであり、かつ（ｉｉ）前記所有者がコンタクトとして追加されているメッセンジャー・コンタクト・リストを有するコンタクトであることと、
前記選択された１つまたは複数のコンタクトの各々のメッセンジャー・クライアントに前記通知を送信することと
を備え、前記選択された１つまたは複数のコンタクトのうちいずれかのコンタクトが、前記インスタント・メッセージング・サービスにログインしているとき、
前記コンテンツ・ページの前記所有者の名前と、
前記所有者の名前の近くに表示される前記コンテンツ・ページからのイメージと、
前記通知に基づいて、前記所有者の前記コンテンツ・ページの前記少なくとも一部分において前記コンテンツ変更が行われたことを示し、前記所有者の名前の近くに表示される視覚インジケータであって、前記所有者の前記コンテンツ・ページのデータを要求するのに選択可能な視覚インジケータと
を含む、前記メッセンジャー・コンタクト・リストを、前記ログインしているコンタクトの前記メッセンジャー・クライアントに提供させることを特徴とする方法。
前記コンテンツ変更が行われたと判断することは、
特定のコンタクトのメッセンジャー・クライアントから、前記コンテンツ・ページに対するコンテンツ・ページ・バージョン要求を受け取ることであって、前記コンテンツ・ページ・バージョン要求は、前記特定のコンタクトの前記メッセンジャー・クライアントが有する前記コンテンツ・ページのバージョン情報を含むことと、
前記サーバが有する前記コンテンツ・ページのバージョン情報と前記コンテンツ・ページ・バージョン要求内の前記バージョン情報とを比較することによって、前記サーバが有する前記コンテンツ・ページのバージョン情報が、前記コンテンツ・ページ・バージョン要求内のバージョン情報よりも新しいかどうか決定すること
を含み、
前記通知を前記送信することは、前記特定のコンタクトが前記コンテンツ変更の通知を送信すべき前記１または複数のコンタクトとして選択されたときに、前記特定のコンタクトに前記通知を送信すること
を含むことを特徴とする請求項１に記載の方法。
前記コンテンツ変更が行われたと判断することは、
前記サーバが有するデータ格納デバイスに保存されている新しいコンテンツを検出すること
を含むことを特徴とする請求項１に記載の方法。
前記通知を送信することは、
アラート・サーバを介して前記通知を前記選択された１または複数のコンタクトの各々のメッセンジャー・クライアントに送信すること
を含むことを特徴とする請求項１に記載の方法。
前記コンテンツ・ページは、１つまたは複数のコンポーネントを含み、前記１つまたは複数のコンポーネントは、コンテンツ・ページ・データおよびフィルタ・パラメータを含み、前記フィルタ・パラメータは、前記コンテンツ・ページの各コンポーネントにおけるコンテンツ変更に対して通知を生成すべきかどうか指示することを特徴とする請求項１に記載の方法。
インスタント・メッセージング・サービスを提供するサーバとネットワークを介して接続されるメッセンジャー・クライアントによって実行される方法において、
ユーザに、該ユーザによってコンタクトとして指定された１または複数のコンタクトをリストした、メッセンジャー・コンタクト・リストを提供することであって、前記メッセンジャー・コンタクト・リストは、該リスト内のコンタクトのうちコンテンツ・ページを有する各コンタクトについて、各コンタクトのコンテンツ・ページからのイメージを、前記コンタクトを識別する名前の近くに表示することと、
前記メッセンジャー・コンタクト・リスト内の特定のコンタクトに関連付けられたコンテンツ・ページに対するコンテンツ・ページ・バージョン要求を、前記サーバに送信することであって、前記コンテンツ・ページ・バージョン要求は、前記メッセンジャー・クライアントが有する前記コンテンツ・ページのバージョン情報を含むことと、
前記メッセンジャー・サーバが有する前記コンテンツ・ページのバージョン情報が、前記コンテンツ・ページ・バージョン要求に含まれる前記バージョン情報よりも新しいとき、前記メッセンジャー・サーバから送信された、前記コンテンツ・ページの少なくとも一部分においてコンテンツ変更が行われたことを示す通知を受け取ることであって、前記通知は、前記特定のコンタクトによって前記コンテンツ・ページの閲覧が許可されたコンタクトをリストしている許可リストにおいて、前記ユーザが、前記コンテンツ変更が行われた前記コンテンツ・ページの閲覧が許可されているときにのみ送信されることと、
前記通知に基づいて、前記ユーザの前記メッセンジャー・コンタクト・リスト上に、前記特定のコンタクトの前記コンテンツ・ページにおいて前記コンテンツ変更が行われたことを示す視覚インジケータであって、前記特定のコンタクトの前記コンテンツ・ページのデータを要求するのに選択可能な視覚インジケータを提供すること
を備えることを特徴とする方法。
前記視覚インジケータを提供することは、
前記ユーザの前記メッセンジャー・コンタクト・リスト内に表示された前記イメージと前記名前の近くに、前記視覚インジケータを提供することを含むことを特徴とする請求項６に記載の方法。
前記通知を受け取ることは、
アラート・パッケージを受け取ることを含む
ことを特徴とする請求項６に記載の方法。
前記視覚インジケータを提供することは、
前記コンテンツ・ページ・バージョン要求を前記メッセンジャー・サーバに送信した後に前記通知を受け取るまでの間に、前記特定のコンタクトが前記メッセンジャー・コンタクト・リストから削除されていないかどうかを判断することを含み、削除されていないときにのみ前記視覚インジケータを提供することを特徴とする請求項６に記載の方法。
前記コンテンツ・ページは、１つまたは複数のコンポーネントを含み、前記１つまたは複数のコンポーネントのそれぞれは、コンテンツ・ページ・データおよびフィルタ・パラメータを含み、前記通知は、前記コンテンツ・ページの前記１つまたは複数のコンポーネントのうち、変更されたコンテンツを有するコンポーネントを示すことを特徴とする請求項６に記載の方法。
前記視覚インジケータを提供することは、
前記通知において示される前記変更されたコンテンツを有するコンポーネントが、前記メッセンジャー・クライアントにキャッシュされているコンポーネントのリスト内のいずれかのコンポーネントと合致すると決定すること、および
前記合致するコンポーネントを表す視覚インジケータを提供すること
を含むことを特徴とする請求項１０に記載の方法。
前記メッセンジャー・コンタクト・リストは、ネットワーク・ブラウザによって提供されることを特徴とする請求項６に記載の方法。
前記メッセンジャー・コンタクト・リストは、メッセージングインターフェースであることを特徴とする請求項１２に記載の方法。
前記メッセンジャー・コンタクト・リストは、スタンド・アロンのクライアントによって提供されることを特徴とする請求項６に記載の方法。
インスタント・メッセージング・サービスを提供するためのシステムであって、
各コンポーネントが異なる種類のコンテンツ・ページ・データを含む１つまたは複数のコンポーネントで構成される、コンテンツを有するコンテンツ・ページと、
各ユーザについて、該ユーザによってコンタクトとして指定された１または複数のコンタクトをリストしたメッセンジャー・コンタクト・リストと、前記コンテンツ・ページの所有者によって前記コンテンツ・ページの閲覧が認可されたユーザをリストした許可リストとを有するデータ格納デバイスと、
前記コンテンツ・ページのコンテンツへのアクセスを有するサーバであって、前記コンテンツ・ページにおいてコンテンツ変更が行われたかどうかを判断し、前記コンテンツ・ページに前記コンテンツ変更が行われたとき、前記コンテンツ・ページの前記１つまたは複数のコンポーネントのうち前記コンテンツ変更が行われたコンポーネントを示すアラート・パッケージを生成し、該アラート・パッケージを、（ｉ）前記許可リストにおいて、前記コンテンツ変更が行われた前記コンテンツ・ページの閲覧が許可されているユーザであり、（ｉｉ）前記所有者がコンタクトとして追加されているメッセンジャー・コンタクト・リストを有する、特定のユーザのクライアントに、前記通知として送信するように構成されたサーバと、
前記アラート・パッケージを受信する前記特定のユーザのクライアントであって、前記特定のユーザが前記インスタント・メッセージング・サービスにログインしているとき、
前記コンテンツ・ページの前記所有者の名前と、
前記所有者の名前の近くに表示される、前記所有者のコンテンツ・ページからのイメージと、
前記所有者の名前の近くに表示され、前記アラート・パッケージに従って前記所有者の前記コンテンツ・ページの少なくとも一部分において前記コンテンツ変更が行われたことを示す視覚インジケータであって、前記所有者の前記コンテンツ・ページのデータを要求するのに選択可能な視覚インジケータと
を含む、前記特定のユーザの前記メッセンジャー・コンタクト・リストを提供するクライアントと
を備えたことを特徴とするシステム。
前記サーバは、コンテンツ・ページ・バージョン情報へのアクセスを有し、前記通知は、前記コンテンツ・ページ・バージョン情報を含むことを特徴とする請求項１５に記載のシステム。
前記通知は、変更されたコンテンツを有する各コンポーネントのコンテンツ・ページ・バージョン情報を提供することを特徴とする請求項１６に記載のシステム。
前記通知は、新しいコンテンツ・インジケータを含み、前記新しいコンテンツ・インジケータは、前記コンテンツ・ページの変更されたコンテンツを有するコンポーネントを示すことを特徴とする請求項１５に記載のシステム。
前記サーバは、前記クライアントによる通信セッションの初期化時に、前記クライアントに前記アラート・パッケージを送るように構成されることを特徴とする請求項１５に記載のシステム。
前記サーバは、前記コンテンツ・ページ中でコンテンツ変更が起こったときに、前記クライアントに前記アラート・パッケージを送るように構成されることを特徴とする請求項１５に記載のシステム。
コンテンツ・ページにおけるコンテンツ変更の通知を、ネットワークを介して提供するための方法を、インスタント・メッセージング・サービスを提供するサーバに実行させるプロセッサ可読プログラムを記録したプロセッサ可読記憶媒体であって、前記方法は、
コンテンツ・ページの少なくとも一部分にコンテンツ変更が行われたと決定することと、
前記コンテンツ・ページの所有者に関連付けられた、前記コンテンツ変更の通知を送信すべき１または複数のコンタクトを選択することであって、該選択された１または複数のコンタクトは、それぞれ、（ｉ）前記所有者によって前記コンテンツ・ページの閲覧が許可されたコンタクトをリストしている許可リストにおいて、前記コンテンツ変更が行われた前記コンテンツ・ページの閲覧が許可されており、かつ（ｉｉ）前記所有者がコンタクトとして追加されているメッセンジャー・コンタクト・リストを有するコンタクトであることと、
前記選択された１つまたは複数のコンタクトの各々のメッセンジャー・クライアントに前記通知を送信することと
を備え、前記通信を送信することにより、前記選択された１つまたは複数のコンタクトのうちいずれかのコンタクトが、前記インスタント・メッセージング・サービスにログインしているとき、
前記コンテンツ・ページの前記所有者の名前と、
前記所有者の名前の近くに表示される前記コンテンツ・ページからのイメージと、
前記通知に基づいて、前記所有者の前記コンテンツ・ページの前記少なくとも一部分において前記コンテンツ変更が行われたことを示し、前記所有者の名前の近くに表示される視覚インジケータであって、前記所有者の前記コンテンツ・ページのデータを要求するのに選択可能な視覚インジケータと
を含む、前記メッセンジャー・コンタクト・リストを、前記ログインしているコンタクトの前記メッセンジャー・クライアントに提供させることを特徴とするプロセッサ可読記憶媒体。
前記通知は、前記コンテンツ変更が行われたときを示すことを特徴とする請求項２１に記載のプロセッサ可読記憶媒体。
前記コンテンツ・ページは、１つまたは複数のコンポーネントを含み、前記１つまたは複数のコンポーネントは、コンテンツ・ページ・データおよびフィルタ・パラメータを含み、前記フィルタ・パラメータは、前記コンテンツ・ページの各コンポーネントにおけるコンテンツ変更に対して通知を生成すべきかどうか指示することを特徴とする請求項２１に記載のプロセッサ可読記憶媒体。
前記１つまたは複数のコンポーネントの各々に対する前記フィルタ・パラメータは、前記所有者によって構成されることを特徴とする請求項２３に記載のプロセッサ可読記憶媒体。