(57)【要約】【課題】ネットワークを介して、通知および関連するコンテンツを動的に提供すること。【解決手段】コンテンツ・ページが、ユーザによって構成され、ネットワーク上に置かれる。コンテンツ・ページに対して行われた変更は、通知を用いて、そのユーザ用のコンタクトからなるグループに自動的に伝達される。コンテンツ・ページ、または変更されたコンテンツの閲覧を許可されたコンタクトのみが、その通知を受け取り、その変更を閲覧する許可を有する。視覚インジケータが、そのコンタクトのうち１つのコンタクトのコンテンツ・ページが変更されたことを複数のコンタクトに通知する。視覚インジケータまたは他の何らかのコンタクト・インジケータがユーザによって選択されると、要約モジュールが提供されることができる。要約モジュールは、コンテンツ・ページを含むネットワーク・コンテンツへのポータルである。【選択図】図８
2006139778.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して通知を提供する方法であって、
所有者のいるコンテンツ・ページ中でコンテンツ変更が起きたと決定すること、
前記所有者によって、前記コンテンツ変更の通知を受け取る許可を有する１つまたは複数のコンタクトを決定すること、および
前記１つまたは複数のコンタクトに前記通知を送信すること
を備えることを特徴とする方法。
【請求項２】
前記コンテンツ変更が起きたことを決定することは、
ユーザからコンテンツ・ページ・バージョン要求のデータを受け取ること、および
コンテンツ・ページ・データを前記コンテンツ・ページ・バージョン要求のデータと比較すること
を含み、
前記通知を前記送信することは、前記ユーザに前記通知を送信すること
を含むことを特徴とする請求項１に記載の方法。
【請求項３】
コンテンツ変更が起きたことを決定することは、
前記コンテンツ・ページ・データが前記コンテンツ・ページ・バージョン要求のデータより最新であるかどうか決定すること
を含むことを特徴とする請求項２に記載の方法。
【請求項４】
コンテンツ変更が起きたことを決定することは、
データ格納デバイスに保存されている新しいコンテンツを検出すること
を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記１つまたは複数のコンタクトに前記通知を送信することは、
前記通知をアラート・サーバに送信すること
を含むことを特徴とする請求項１に記載の方法。
【請求項６】
１つまたは複数のコンタクトを決定することは、
前記１つまたは複数のコンタクトを含む許可リストにアクセスすることを含む
ことを特徴とする請求項１に記載の方法。
【請求項７】
前記コンテンツ・ページは、１つまたは複数のコンポーネントを含み、前記１つまたは複数のコンポーネントは、コンテンツ・ページ・データおよびフィルタ・パラメータを含み、前記フィルタ・パラメータは、コンテンツ・ページ・コンポーネントにおけるコンテンツ変更に対して通知が生成されるべきかどうか決定することを特徴とする請求項１に記載の方法。
【請求項８】
ユーザ干渉の通知を受け取ること、
通知に応答して、前記ユーザ・インターフェースで視覚インジケータを提供すること
をさらに備えることを特徴とする請求項７に記載の方法。
【請求項９】
１つまたは複数のコンタクトを決定することは、
所有者によって構成される許可リスト、および前記１つまたは複数のコンタクトそれぞれのコンタクト・リストから派生されるリバース・メッセージ通信リスト、に共通の前記コンタクトを決定すること
を含むことを特徴とする請求項１に記載の方法。
【請求項１０】
使用者を含む１つまたは複数のコンタクトに関連付けられたユーザにインターフェースを提供すること、
所有者のいるコンテンツ・ページが変更されたという通知であって、前記所有者に関連付けられた許可リストに含まれる前記ユーザに対する通知、を受け取ること、および
前記インターフェース上に、前記コンタクトに対して、前記コンテンツ・ページ変更を示す視覚インジケータを提供すること
を備えることを特徴とする通知を提供する方法。
【請求項１１】
前記通知を受け取ることは、
前記１つまたは複数のコンタクトに関連付けられたコンテンツ・ページのリストを求めるコンテンツ・ページ・バージョン要求を送ること、および
前記コンテンツ・ページ・バージョン要求に応答して、コンテンツ・ページの前記リストに関するバージョン情報を受け取ること
を含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記視覚インジケータを提供することは、
コンテンツ・ページの前記リストに関する前記受け取ったバージョン情報が、コンテンツ・ページの前記リストのキャッシュされたバージョン情報より最新であるかどうか決定することを含む
ことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記通知を受け取ることは、
アラート・パッケージを受け取ることを含む
ことを特徴とする請求項１０に記載の方法。
【請求項１４】
前記視覚インジケータを提供することは、
前記通知が、前記ユーザに関連付けられた前記１つまたは複数のコンタクトの１つに対するものであるかどうか決定することを含む
ことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記コンテンツ・ページは、１つまたは複数のコンポーネントを含み、前記１つまたは複数のコンポーネントそれぞれは、コンテンツ・ページ・データおよびフィルタ・パラメータを含み、前記通知は、変更されたコンテンツ・ページのコンテンツを有する前記コンポーネントを示すことを特徴とする請求項１０に記載の方法。
【請求項１６】
視覚インジケータを提供することは、
前記通知中で示される、変更されたコンテンツを有する前記コンポーネントの１つまたは複数が、コンポーネントのキャッシュされたリストと合致すると決定すること、および
前記合致するコンポーネントを表す視覚インジケータを提供すること
を含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記インターフェースは、ネットワーク・ブラウザによって提供されることを特徴とする請求項１０に記載の方法。
【請求項１８】
前記インターフェースは、メッセージ通信インターフェースであることを特徴とする請求項１７に記載の方法。
【請求項１９】
前記インターフェースは、スタンド・アロン・クライアントによって提供されることを特徴とする請求項１０に記載の方法。
【請求項２０】
ネットワークを介して通知を提供するシステムであって、
コンテンツを有するコンテンツ・ページと、
前記コンテンツ・ページに関連付けられた、認可された閲覧者のリストを有するデータ格納デバイスと、
前記コンテンツ・ページのコンテンツにアクセスできるサーバであって、前記コンテンツ・ページのコンテンツにおける変更を決定し、認可された閲覧者の前記リストに前記通知を送るように構成されたサーバと
を備えることを特徴とするシステム。
【請求項２１】
前記コンテンツ・ページは、１つまたは複数のコンポーネントを含み、各コンポーネントは、コンテンツ・ページのコンテンツを有し、前記通知は、どのコンポーネントが、変更されたコンテンツを含むかを示すことを特徴とする請求項２０に記載のシステム。
【請求項２２】
前記サーバは、コンテンツ・ページ・バージョン情報へのアクセスを有し、前記通知は、前記コンテンツ・ページ・バージョン情報を含むことを特徴とする請求項２０に記載のシステム。
【請求項２３】
前記コンテンツ・ページは、コンテンツ・ページ・データを有する１つまたは複数のコンポーネントを含み、前記通知は、変更されたコンテンツを有する各コンポーネントにコンテンツ・ページ・バージョン情報を提供することを特徴とする請求項２２に記載のシステム。
【請求項２４】
前記リストは、認可された各閲覧者用のコンタクトのリストを含み、前記サーバは、前記通知を認可された各閲覧者に送り、前記認可された閲覧者のコンタクト・リストには所有者が列挙されていることを特徴とする請求項２０に記載のシステム。
【請求項２５】
前記通知は、新しいコンテンツ・インジケータを含み、前記新しいコンテンツ・インジケータは、前記コンテンツ・ページに関するコンテンツ変更を示すことを特徴とする請求項２０に記載のシステム。
【請求項２６】
ユーザ・インターフェースを提供するクライアントであって、前記アラートを受け取り、前記コンテンツ・ページの前記変更されたコンテンツを示す視覚インジケータを、前記ユーザ・インターフェースに表示するように構成されたクライアントをさらに備えることを特徴とする請求項２０に記載のシステム。
【請求項２７】
前記サーバは、前記クライアントによる通信セッションの初期化時に、前記クライアントに前記アラートを送るように構成されることを特徴とする請求項２６に記載のシステム。
【請求項２８】
前記サーバは、コンテンツ・ページ中でコンテンツ変更が起こったときに、前記クライアントに前記アラートを送るように構成されることを特徴とする請求項２６に記載のシステム。
【請求項２９】
プロセッサ可読格納デバイス上で実施されるプロセッサ可読コードを有する１つまたは複数のプロセッサ可読格納デバイスであって、前記プロセッサ可読コードは、
所有者のいるコンテンツ・ページ中でコンテンツ変更が起きたと決定すること、
前記コンテンツ変更の通知の閲覧を許可された１つまたは複数のコンタクトを示す許可リストにアクセスすること、および
前記認可された１つまたは複数のコンタクトに前記通知を送信すること
を備える方法を実施するように１つまたは複数のプロセッサをプログラミングすることを特徴とする１つまたは複数のプロセッサ可読格納デバイス。
【請求項３０】
前記認可されたコンタクトそれぞれは、前記所有者を含むコンタクト・リストに関連付けられることを特徴とする請求項２９に記載の１つまたは複数のプロセッサ可読格納デバイス。
【請求項３１】
前記通知は、前記コンテンツ変更がいつ起きたかを示すことを特徴とする請求項２９に記載の１つまたは複数のプロセッサ可読格納デバイス。
【請求項３２】
前記通知は、前記コンテンツ・ページが変更されたことを示すことを特徴とする請求項２９に記載の１つまたは複数のプロセッサ可読格納デバイス。
【請求項３３】
前記コンテンツ・ページは、１つまたは複数のコンポーネントを含み、前記１つまたは複数のコンポーネントは、コンテンツ・ページ・データおよびフィルタ・パラメータを含み、前記フィルタ・パラメータは、コンテンツ・ページ・コンポーネントにおけるコンテンツ変更に対して通知が生成されるべきかどうか決定することを特徴とする請求項２９に記載の１つまたは複数のプロセッサ可読格納デバイス。
【請求項３４】
前記１つまたは複数のフィルタ・パラメータは、前記所有者によって構成されることを特徴とする請求項３３に記載の１つまたは複数のプロセッサ可読格納デバイス。
【請求項３５】
１つまたは複数のコンタクトを決定することは、
所有者によって構成される許可リスト、および前記１つまたは複数のコンタクトそれぞれのコンタクト・リストから派生されるリバース・メッセージ通信リスト、に共通の前記コンタクトを決定することを含むことを特徴とする請求項２９に記載の１つまたは複数のプロセッサ可読格納デバイス。
【請求項３６】
前記通知は、メッセンジャー・サーバに送られることを特徴とする請求項２９に記載の１つまたは複数のプロセッサ可読格納デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介した、通知および関連するコンテンツの動的な提供を対象とする。
【背景技術】
【０００２】
インターネットの発展に伴い、人々が互いに通信することを可能にするいくつかのツールが発展した。こうしたツールにより、人々は、自分の考えを表現（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）から、リストを取り出す。コンテンツ・ページの閲覧を許可されているコンタクトは、格納サーバ８２０に格納されている許可リストから、許可リスト識別子を使って取り出される。そのページの所有者のメッセンジャー・リバース・リストに載っているコンタクトは、そのページの所有者を自分自身のメッセンジャー・コンタクト・リストに載せているコンタクトである。したがって、リバース・リスト・メンバは、そのページの所有者を、メッセンジャー・クライアント８８０のユーザ・インターフェースに表示される、自分のコンタクトの１つとして載せているメンバである。
【００６７】
格納サーバ８２０は、ステップ１１２０で、許可リストおよびリバース・メッセンジャー・リストを取り出す。一実施形態では、許可リスト識別子およびリバース・メッセンジャー・リストは、格納サーバ８２０によってＡＢＣＨ８３０から取り出される。格納サーバ８２０は次いで、許可識別子リストを使って、許可リストを取り出す。両方のリストが取り出されると、格納サーバ８２０は、ステップ１１３０で、許可およびリバース・メッセンジャー・リスト両方で見つかったコンタクトを含む共通コンタクト・リストを生成する。
【００６８】
格納サーバ８２０は、ステップ１１４０で、コンテンツ・ページに行われた変更に対して、アラートを生成する。一実施形態では、既存のコンポーネントに対する、新たに追加されたコンポーネントまたは新しいエントリを伴う変更に対してアラートが生成される。アラートのパラメータは、コンテンツ・ページ識別子と、コンポーネント識別子と、コンポーネントおよびコンテンツ・ページに関する最新のバージョンまたは最終更新日と、実施されるアクション（例えば、挿入、変更、または消去）と、変更が視覚インジケータをクライアントインターフェース内に表示させるかどうかを示す新しい項目インジケータと、変更されたコンポーネントに関するコンポーネントの要約とを含むことができる。アラート・コンポーネントの要約は、アラート・コンポーネントの要約が具体的なコンポーネントに関すること以外、コンテンツ・ページ・バージョン応答コンポーネントの要約と同様でよい。アラート・コンポーネントの要約は、コンポーネント識別子および項目識別子配列を含む。コンポーネント識別子は、コンテンツ・ページ・バージョン応答中のものと同じである。項目識別子配列は、変更されたコンポーネント中の子または項目の識別子の配列である。例えば、項目配列は、フォト・アルバム中の消去された写真、変更されたブログ・エントリ、プレイ・リスト中の新しい歌、または他の何らかの項目の識別子を含むことができる。
【００６９】
アラートは、ＸＭＬ形式で送ることができる。一部の実施形態では、アラートは、格納サーバ８２０によってエンコードすることができる。エンコードされていない、すなわちデコードされたＸＭＬでのアラートの例を、以下に示す。
【００７０】
【表１】
2006139778.tif 000003
【００７１】
アラート・サーバ８４０は、ステップ１１３０で派生された共通コンタクト・リストを有するアラート・パッケージを、ステップ１１５０でメッセンジャー・サーバ８５０に送る。メッセンジャー・サーバ８５０は、アラートを受け取り、ステップ１１６０で、共通コンタクトのどれがメッセンジャー・サーバ８５０にサインインしているか決定する。メッセンジャー・サーバ８５０は次いで、ステップ１１７０で、そうしたコンタクトに関連付けられたメッセンジャー・クライアント８８０のアプリケーションにアラート・パッケージを送る。一部の実施形態では、アラートは、システムに応じて、メッセンジャー・クライアント８８０、ブラウザ、モバイル・デバイス、ｅメール・サーバ８７２、または他のエンティティに経路指定することができる。アラートを受け取ることになるコンタクトがサインインしていない場合、アラート・パッケージは無視される。コンタクトは、メッセンジャー・クライアント８８０が要約モジュールキャッシュ情報をコンテンツ・ページの最新バージョン情報と比較する次のログオン時にアップデートを受け取る。
【００７２】
メッセンジャー・クライアント８８０は、ステップ１１８０でアラート・パッケージを受け取る。ステップ１１９０で、メッセンジャー・クライアント８８０は、アラートを処理し、ユーザ・インターフェースにおいて視覚指示が提供されるべきかどうか決定する。最初に、そのアラートが、メッセンジャー・クライアント８８０は、ユーザのメッセンジャー・コンタクト・リストに含まれる（例えば、メッセンジャー・コンタクト・リストから消去されていない）コンタクトに関連付けられているかどうか決定する。メッセンジャー・クライアント８８０は次いで、最終更新日情報が、ローカル・メモリに格納されているコンポーネントに関する最終更新日より最新かどうか決定する。一実施形態では、クライアントは、そのリスト中の新しい項目インジケータ（new item indicator）が、視覚インジケータが提供されるべきであると示す（そうすることによって、少なくとも１つのコンポーネントに新しいコンテンツがあることを示す）場合のみ、この決定を行う。アラートがメッセンジャー・コンタクト・リスト中のコンタクトに関連付けられており、少なくとも１つのコンポーネントに関する最終更新日が、キャッシュされたコンポーネントのものより最新である場合、メッセンジャー・クライアント８８０は、ステップ１０９２で、そのコンタクトに対応するインジケータを提供する。それ以外の場合、オペレーションは、ステップ１１９４に続き、ここでは、メッセンジャー・クライアント８８０は、この特定のコンタクトに対する視覚インジケータを提供しない。クライアントはまた、コンポーネントおよびコンポーネント項目両方に関する最終更新日情報、ならびに新しいコンポーネントによって示される要約モジュールに対する変更を含むアラート・パッケージ情報を格納する。
【００７３】
メッセンジャー・クライアント８８０は、要約モジュールが表示されるべきであることを示す入力を受け取ると、どこから要約モジュールをロードするか決定することになる。入力は、コンタクト存在インジケータ、コンタクト識別子、またはコンタクト用のコンテンツ・ページに関連付けられた他の何らかの視覚インジケータ上でのマウスの右ボタン・クリックなどの選択を含むことができる。図１２の方法１２００は、要約モジュール用のソースを決定する方法を示す。メッセンジャー・クライアント８８０は、ステップ１２１０で、要約モジュール要求を受け取る。メッセンジャー・クライアント８８０は次いで、ステップ１２２０で、要約モジュールのキャッシュされたバージョンが入手可能かどうか決定する。キャッシュされたバージョンは、メッセンジャー・クライアント８８０が要約モジュールを以前受け取ったことがある場合、利用できる可能性がある。キャッシュされたバージョンが利用可能でない場合、オペレーションは、ステップ１２６０に続く。
【００７４】
キャッシュされたバージョンが利用可能な場合、オペレーションは、ステップ１２３０に続き、ここで、システムは、ログイン時にコンテンツ・ページ・バージョン応答で受け取ったタイム・スタンプが、要約モジュールのキャッシュされたバージョンに関連付けられたタイム・スタンプより最新であるかどうか決定する。コンテンツ・ページ・バージョン応答にあるタイム・スタンプが、キャッシュされた要約モジュールのタイム・スタンプより最新である場合、オペレーションは、ステップ１２６０に続く。最新でない場合、システムは、ステップ１２４０で、コンテンツ・ページが変更されたことを示すアラートが受け取られていたかどうか決定する。一実施形態では、コンテンツ・ページが変更されたことを示すアラートが受け取られていた場合、メッセンジャー・クライアント８８０によって格納されている新しい項目インジケータがこのことを示す。したがって、メッセンジャー・クライアント８８０は、インジケータの値を取り出して、コンテンツ・ページ変更アラートが受け取られていたかどうか決定することができる。アラートがステップ１２４０で受け取られていた場合、オペレーションは、ステップ１２６０に続く。アラートがステップ１２４０で受け取られていなかった場合、オペレーションは、ステップ１２５０に続く。ステップ１２６０で、システムは、要約モジュールのキャッシュされたバージョンが古いものになっている可能性があり、要約モジュール・データの最新のバージョンが要求されるべきであると、決定する。ステップ１２５０で、メッセンジャー・クライアント８８０は、要約モジュール・データが最後にロードされて以降、コンテンツ・ページに対して変更が行われていないと決定する。したがって、要約モジュールは、キャッシュされたバージョンからロードされることになる。
【００７５】
一部の実施形態では、メッセンジャー・クライアント８８０は、コンタクトに関連付けられたコンテンツ・ページが新しい項目、例えばＨａｓＮｅｗＩｔｅｍフラグを有するかどうかを示すインジケータを保持することができる。したがって、各コンタクトに対して、コンテンツ・ページ・バージョン応答で受け取ったタイム・スタンプが、キャッシュされたタイム・スタンプより最新である場合、コンテンツ・ページが変更されたことを示すアラートが受け取られた場合、あるいはキャッシュされたバージョンがない場合、この新しいコンテンツ・フラグは、コンテンツ・ページおよび対応する要約モジュール・データが変更されたことを示す値を収容する。方法１２００を通して実行することをせずに、このシステムは、新しいコンテンツ・フラグの値を調べて、どこから要約モジュールがロードされるべきか決定する。
【００７６】
図１３は、要約モジュールを取り出す方法１３００を示す。メッセンジャー・クライアント８８０は、ステップ１３１０で、あるユーザ向けの要約モジュールを閲覧するための要求を受け取る。一部の実施形態では、メッセンジャー・クライアントは、コンテンツ・ページ・サーバ８１０または格納サーバ８２０をポーリングすることができる。この場合、要約モジュールが変更されているという指示（indication）をポーリングが返すと、要約モジュール・データに対する要求がトリガされる。要求が受け取られると、メッセンジャー・クライアント８８０は、ステップ１３２０で、その要約モジュールを求めるコンテンツ・ページ・サーバ８１０への要約モジュール・コンテンツ要求を伝送する。
【００７７】
一実施形態では、メッセンジャー・クライアント８８０は、格納サーバ８２０に直接、要約モジュール・データ要求を伝送する。この場合、格納サーバ８２０は、要約モジュール・データ応答をメッセンジャー・クライアント８８０に直接伝送することができる。要約モジュール・データ要求および要約モジュール・データ応答については、後でより詳しく論じる。
【００７８】
要約モジュール・コンテンツ要求は、コンテンツ・ページ識別子、コンテンツ・ページの最終更新日、どのコンポーネントからコンテンツを返すかを示すフィルタ、コンポーネントエントリ・タイプ、各タイプごとのエントリの数、およびコンポーネントの子を返すためのフィールドを含むパラメータを有することができる。
【００７９】
要約モジュール・コンテンツ要求の例を、以下に示す。
【００８０】
【表２】
2006139778.tif 000004
【００８１】
コンテンツ・ページ・サーバ８１０は、ステップ１３２５で、要求を受け取り、格納サーバ８２０に対して、要約モジュール・データ要求を生成する。格納サーバ８２０への要求は、メッセンジャー・クライアント８８０による要約モジュールの最終閲覧のタイム・スタンプを含む。タイム・スタンプは、要約モジュールがメッセンジャー・クライアント８８０によって以前要求されたことがない場合、ゼロ、すなわち偽の値になり得る。要求は、要約モジュールの具体的なコンポーネント、およびいくつかの子項目も示すことができる。子項目の数は、要求されたサムネイルの数、ブログ・エントリの数、歌の数、または他の何らかのデータに関連することができる。
【００８２】
コンテンツ・ページ・サーバ８１０から格納サーバ８２０への要約モジュール・データ要求用の形式の一例を、以下に示す。
【００８３】
【表３】
2006139778.tif 000005
【００８４】
【表４】
2006139778.tif 000006
【００８５】
【表５】
2006139778.tif 000007
【００８６】
【表６】
2006139778.tif 000008
【００８７】
【表７】
2006139778.tif 000009
【００８８】
【表８】
2006139778.tif 000010
【００８９】
要約モジュール・データ要求は、ステップ１３３０で格納サーバ８２０に送られる。
【００９０】
一実施形態では、要求されたデータをコンテンツ・ページ・サーバ８１０に提供する前に、格納サーバ８２０は、ステップ１３４０で、要求したユーザが要約モジュールの閲覧を許可されているかどうか確認する。格納サーバ８２０は、ステップ１３４０で、要約モジュール・データ要求が、コンテンツ・ページに関する許可リスト識別子を含むかどうか決定する。許可リスト識別子が含まれている場合、オペレーションは、ステップ１３５５に続く。含まれていない場合、格納サーバ８２０は、コンテンツ・ページ識別子を使って、ＡＢＣＨ８３０に対して許可リスト識別子を要求する。ステップ１３５０で、ＡＢＣＨ８３０は、その要求を受け取り、許可リスト識別子を取り出し、格納サーバ８２０に識別子を提供する。オペレーションは次いで、ステップ１３５５に続く。
【００９１】
格納サーバ８２０は、ステップ１３５５で、許可リスト識別子を使って許可リストを取り出し、ＡＢＣＨ内の許可リストを使って、ユーザがコンテンツ・ページの閲覧を許可されているかどうか決定する。ユーザが許可されていない場合、格納モジュールは、ステップ１３５７で、コンテンツ・ページ・サーバ８１０にエラー・メッセージで返答する。コンテンツ・ページ・サーバ８１０は次いで、ユーザが要約モジュールの閲覧を許可されていないこと、またはカードが利用可能でないことを示すメッセージを、メッセンジャー・クライアント８８０に送る。ユーザが許可リストに載っている場合、ユーザは、コンテンツ・ページの閲覧を許可され、オペレーションは、ステップ１３６０に続く。
【００９２】
格納サーバ８２０は、ステップ１３６０で、コンテンツ・ページ・サーバ８１０の要求を処理し、コンテンツ・ページ・サーバ８１０に要約モジュール・データ応答を送る。要求の処理は、要求のフィルタ情報によって指定されるとともにクライアントによって提供される最終更新日よりも最終更新日が最新である最終更新日を有する、コンポーネントおよび子項目へアクセスすることを含むことができる。コンテンツ・ページ識別子が無効であるか、または閲覧許可が拒否された場合、格納サーバ８２０は、エラーを返すことができる。
【００９３】
要約モジュール・データ応答は、コンテンツ・ページ識別子、コンテンツ・ページが最後に更新された日付、クライアントによって提供された最後に更新された日付以降にいずれかのコンポーネントが変更されたことを示す新しい項目インジケータ、および各コンポーネントに関するコンポーネント要約、を含む複数のパラメータを有することができる。コンポーネント要約は、上で論じたように識別子およびタイム・スタンプを提供する。
【００９４】
要約モジュール・データ応答形式の例を、以下に示す。
【００９５】
【表９】
2006139778.tif 000011
【００９６】
【表１０】
2006139778.tif 000012
【００９７】
要約モジュール・データ応答を受け取ると、コンテンツ・ページ要約は、ステップ１３７０で、データを処理し、処理したコンテンツをメッセンジャー・クライアント８８０に伝送する。この処理は、適正な言語でのコンテンツを貼り付けること、ブログ・エントリからのヘッダおよびフォーマット情報を削除すること、ならびに他のタスクを含むことができる。コンテンツ・ページ・サーバ８１０からメッセンジャー・クライアント８８０に送られる要約モジュール・コンテンツ応答の例を、以下に示す。
【００９８】
【表１１】
2006139778.tif 000013
【００９９】
【表１２】
2006139778.tif 000014
【０１００】
【表１３】
2006139778.tif 000015
【０１０１】
【表１４】
2006139778.tif 000016
【０１０２】
次に、ステップ１３８０で、メッセンジャー・クライアント８８０は、要約モジュール・コンテンツ応答を受け取る。メッセンジャー・クライアント８８０は、応答内の情報を格納し、要約モジュールを生成する。一部の実施形態では、クライアントによって格納される情報は、コンテンツ・ページ、コンポーネント・ページおよびコンポーネントの子の識別子およびタイム・スタンプ、ＨａｓＮｅｗＳｐａｃｅフラグ、許可リスト識別子、ならびにそれ以外のもののうち１つを含むことができる。
【０１０３】
一実施形態では、要約モジュールは、ネットワーク・ブラウザ、例えばウェブ・ブラウザ上に実装されるメッセージ・サービスを介して閲覧されることが可能である。ウェブ・サービスとして実装されるＩＭユーザ・インターフェースは、メッセンジャー・クライアント８８０と同じユーザ・インターフェースおよびユーザ・エクスペリエンスを有し得る。コンテンツ・ページ・サーバ８１０、格納サーバ８２０、およびＡＢＣＨ８３０の間の通信も同じである。唯一のプロトコル変更は、メッセンジャー・ウェブ・サービス８６０とコンテンツ・ページ・サーバ８１０の間で発生する。ネットワーク・ブラウザとして実装されるＩＭユーザ・インターフェースに視覚インジケータを追加する方法１４００を、図１４に示す。ポーリング・イベントが、ステップ１４１０でトリガされる。ウェブ・メッセンジャーには、メッセンジャー・クライアント８８０にあるような、メッセンジャー・サーバ８５０への専用の接続がない。したがって、コンテンツ・ページがアップデートされているかどうか決定するために、ウェブ・メッセンジャーは、アラートのためにメッセンジャー・サーバ８５０を周期的にポーリングすることができる。ポーリング・イベントは、期間の満了など、内部的に生成されるイベントによっても、ユーザ入力によってもトリガすることができる。ポーリング・イベントがトリガされると、ブラウザは、ステップ１４２０で、メッセンジャー・ウェブ・サーバにコンテンツ・ページ・バージョン要求を伝送する。一実施形態では、ステップ１４２０の要求は、ＨＴＴＰ要求の形で行われる。この要求を受け取ると、メッセンジャー・ウェブ・サーバは、ステップ１４３０で、ユーザのメッセンジャー・コンタクト・リストに関連付けられたコンタクト・ページに関する変更されたコンテンツ・ページ情報を求める要求を、メッセンジャー・サーバ８５０に伝送する。
【０１０４】
メッセンジャー・サーバ８５０は、ステップ１４４０で変更を決定する。一実施形態では、メッセンジャー・サーバ８５０は、メッセンジャー・コンタクト・リストに関連する、受け取ったどのアラートにもアクセスする。別の実施形態では、メッセンジャー・クライアント８８０は、該当するコンテンツ・ページに関する最新のタイム・スタンプ情報を、格納サーバ８２０から取り出す。メッセンジャー・サーバ８５０は次いで、ステップ１４５０で、メッセンジャー・ウェブ・サーバに返答を伝送する。一実施形態では、要求されたどの視覚インジケータ向けにウェブ・メッセンジャーに対して行われる変更も、ｊａｖａ（登録商標）スクリプト・イベントとして提供される。ｊａｖａ（登録商標）スクリプト・イベントは、どのようにして、ネットワーク・ブラウザが変更されたコンテンツ・ページを有するコンタクト用の視覚インジケータを含むようにアップデートされるかを示す。メッセージは次いで、ステップ１４６０でウェブ・メッセンジャーによって受け取られて、ユーザ・インターフェースがアップデートされる。
【０１０５】
ネットワーク・ブラウザにおいて視覚インジケータが提供されると、ユーザは、視覚インジケータを選択して、要約モジュールを閲覧することができる。一実施形態では、要約モジュールは、別個のネットワーク・ブラウザ内のインターフェースとして実装することができる。ネットワーク・ブラウザ内で提供されるＩＭインターフェースによって要約モジュールを提供する方法１５００を、図１５に示す。方法１５００は、ステップ１５１０で始まり、ここで、視覚インジケータを選択する入力が受け取られる。一実施形態では、視覚インジケータは、ネットワーク上の要約モジュール・ページへのリンクである。ステップ１５２０で、メッセンジャー・ウェブ・サービス８６０は、コンテンツ・ページ・サーバ８１０に要約モジュール・データを要求する。要約モジュール・データ要求は、コンテンツ・ページ・サーバ８１０によって受け取られ、ステップ１５３０で処理される。一実施形態では、要求は、図１３のステップ１３２５から１３６０を参照して論じたように処理される。格納装置が要約モジュール・データを受け取った後、データは、メッセンジャー・ウェブ・サーバ用にパッケージされ、ステップ１５４０で伝送される。メッセンジャー・ウェブ・サーバは、ステップ１５５０でパッケージを受け取り、要約モジュールを提供する。一実施形態では、要約モジュール・データは、ＨＴＭＬとしてパッケージされ、要約モジュールを別個のウェブ・ページとして提供することを可能にする。
【０１０６】
一実施形態では、要約モジュールは、ｅメール・ウェブ・サービスを介して提供することができる。図１４および１５を参照して論じたウェブ・メッセンジャー・サービスと同様、ｅメール・ウェブ・サービスは、ウェブ・ブラウザを介して実装される。したがって、要約モジュールは、ｅメール管理インターフェースと平行する別個のブラウザ内で、またはネットワーク・ブラウザ内に提供されるｅメール管理インターフェース内で、提供することができる。ｅメール・ウェブ・サービス用の視覚インジケータおよび要約モジュールを提供する方法は、ウェブ・ブラウザが、メッセンジャー・ウェブ・サービス８６０およびメッセンジャー・ウェブ・サーバではなく、ｅメール・サーバ８７２を介してコンテンツ・ページ・サーバ８１０と通信することを除いて、方法１４００および１５００のものと同じである。したがって、要約モジュールは、コンテンツ・ページ・ウェブ・サービスによって、ウェブ・サイトとして実装される。
【０１０７】
図１６〜１８は、ネットワーク・ブラウザ、例えばウェブ・ブラウザ内で提供されるｅメール管理インターフェースにおいて要約モジュールを提供する例を示す。図１６は、ネットワーク・ブラウザ１６１０、ｅメール・インターフェース・ページ１６２０、および要約モジュール１６３０を含む。ｅメール・インターフェース・ページ１６２０は、ユーザにｅメールを生成させる。要約モジュール１６３０は、ユーザによって生成されるｅメールにおいて署名として提供される。図１７は、ネットワーク・ブラウザ１７１０、ユーザ・コンタクト・ページ１７２０、および要約モジュール１７３０を含む。ユーザ・コンタクト・ページ１７２０は、ユーザがコンタクトを閲覧し、構成することを可能にする。要約モジュール１７３０は、ユーザによって構成することができるコンタクトの一部として提供される。図１８は、ネットワーク・ブラウザ１８１０、コンタクト・リスト・ページ１８２０、および要約モジュール１８３０を含む。コンタクト・リスト・ページ１８２０は、ユーザがコンタクトのリストを閲覧し、構成することを可能にする。要約モジュール１８３０は、ある特定のコンタクト用のフィールドとして提供される。
【０１０８】
本発明の上記の詳細な説明は、例示および説明のために提示したものである。網羅的であることも、開示した厳密な形に本発明を限定することも意図していない。上記の教示に鑑みて、多くの修正形態および変形形態が可能である。記載した実施形態は、本発明の原理および実際的な適用を最もよく説明するために、また、そうすることによって、他の当業者が、本発明を、企図される特定の使用に適した様々な変更を伴って様々な実施形態において最もよく使用できるように選択した。本発明の範囲は、特許請求の範囲によって定義されることを意図している。
【図面の簡単な説明】
【０１０９】
【図１】コンテンツ・ページの一実施形態を示す図である。
【図２Ａ】要約モジュールのフロント・イメージの一実施形態を示す図である。
【図２Ｂ】要約モジュールのバック・イメージの一実施形態を示す図である。
【図２Ｃ】視覚インジケータを有する要約モジュールのフロント・イメージの一実施形態を示す図である。
【図２Ｄ】視覚インジケータを有する要約モジュールのバック・イメージの一実施形態を示す図である。
【図３Ａ】ブログ・コンテンツが選択された要約モジュールの一実施形態を示す図である。
【図３Ｂ】写真コンテンツが選択された要約モジュールの一実施形態を示す図である。
【図３Ｃ】音楽コンテンツが選択された要約モジュールの一実施形態を示す図である。
【図４】要約モジュールを構成する方法の一実施形態を示す図である。
【図５】インスタント・メッセージ・ユーザ・インターフェースの一実施形態を示す図である。
【図６】要約モジュールを提供するための入力を受け取るユーザ・インターフェースの一実施形態を示す図である。
【図７】要約モジュールを提供するユーザ・インターフェースの一実施形態を示す図である。
【図８】通知システムの一実施形態を示す図である。
【図９】サービスへのログイン時に視覚インジケータを提供する方法の一実施形態を示す図である。
【図１０】コンテンツ・ページを閲覧する許可を決定する方法の一実施形態を示す図である。
【図１１】サービスへのログイン期間に、視覚インジケータを提供する方法の一実施形態を示す図である。
【図１２】要約モジュール・データが取り出されるソースを決定する方法の一実施形態を示す図である。
【図１３】要約モジュール・データを取り出す方法の一実施形態を示す図である。
【図１４】ネットワーク・ブラウザにおいて視覚インジケータを提供する方法の一実施形態を示す図である。
【図１５】ネットワーク・ブラウザにおいて要約モジュールを提供する方法の一実施形態を示す図である。
【図１６】ネットワーク・ブラウザによって提供されるｅメール生成インターフェースに統合された要約モジュールを示す図である。
【図１７】ネットワーク・ブラウザによって提供されるコンタクト管理インターフェースに統合された要約モジュールを示す図である。
【図１８】ネットワーク・ブラウザによって提供されるコンタクト・リスト・インターフェースに統合された要約モジュールを示す図である。
【符号の説明】
【０１１０】
１００    コンテンツ・ページ
１１０    ユーザ・インターフェース・ウィンドウ
１２０    ブログ・コンポーネント
１２１    エントリ・タイトル
１２３    第１のブログ・エントリ
１２４    ブログ・ツール・バー
１２５    第２のブログ・エントリ
１３０    フォト・アルバム・コンポーネント
１３１    イメージ
１３２    第１のフォト・アルバム部分
１３３    第２のフォト・アルバム部分
１４０    リンク・コンポーネント
１５０    音楽コンポーネント
１５１    最近再生された歌のタイトルおよびアーティストのリスト
１６０    プロファイル・コンポーネント
１６１    ｅメールを送る（ｅメール・リンク）
１６２    ＩＭに勧誘する（ＩＭリンク）
１７０    個人的なメッセージ
１８０    個人のイメージ
１９０    オンライン・インジケータ
２００    要約モジュールのフロント・イメージ
２１０    カード
２１２    ユーザ識別子
２１４    カード反転インジケータ
２１６    カード・クローズ・アイコン
２２０    ニックネーム
２２２    コンテンツ・タイトル
２３０    フォト・アルバム・タイトル
２３２    フォト・アルバムの説明
２３４    サムネイル
２４０    追加コンテンツ・リンク
２４２    ｅメール・リンク
２４４    ＩＭリンク
２４６    コンテンツ・ページリンク
２４８    プロファイル・イメージ
２５０    バック・イメージ
２６０    要約カード
２６４    要約カード反転インジケータ
２６６    要約カード・クローズ・アイコン
２７０    コンタクト情報
２８０    １つまたは複数の視覚インジケータを有する要約モジュールのフロント・ビュー
２８５    カード（要約モジュール）
２８７    サムネイル行
２８８    アイコン（「もっと見る」というコンテンツ・インジケータ）
２９０    バック・イメージ
２９５    要約モジュール
２９７    コンタクト情報
２９８    視覚インジケータ
３１０、３３０、３６０    要約モジュール
３１５、３４０、３６５    カーソル
３２０    要約モジュール内部のブログ・コンテンツ
３３５    写真コンテンツ
３５０    写真コンテンツ・ウィンドウ
３７０    リスト・コンテンツ
３８０    リスト・コンテンツ・ウィンドウ
５００    ＩＭユーザ・インターフェース
５１０    ウィンドウ
５１２    ユーザ状況インジケータ（オンライン）
５１４    メッセンジャー・コンタクト・リスト
５２０    視覚インジケータ
５３０    コンタクト・インジケータ
５３２    オンライン・インジケータ
６００、７００    メッセンジャー・クライアント（ユーザ）・インターフェース
６１０    クライアント・インターフェース・ウィンドウ
６１５    ユーザ・ニックネーム
６２０、７２０    メッセンジャー・コンタクト・リスト
６３０    コンタクト・ニックネーム
６３５、７３５    コンタクト存在インジケータ
６４０    メッセージ・ウィンドウ・ポインタ
６５０    メッセージ・ウィンドウ
７１０    インターフェース・ウィンドウ
７３０    コンタクト・ニックネーム
７４０    要約モジュール
７４２    要約モジュール・コンタクト・ニックネーム
７４４、７４６    要約モジュール・コンテンツ
８００    システム
８１０    コンテンツ・ページ・サーバ
８２０    格納サーバ
８３０    アドレス帳クリアリング・ハウス
８４０    アラート・サーバ
８５０    メッセンジャー・サーバ
８６０    メッセンジャー・ウェブ・サービス
８７０    クライアント・ウェブ・ブラウザ
８７２    Ｅメール・サーバ
８８０    メッセンジャー・クライアント
８８２    インスタント・メッセンジャー・ユーザ・インターフェース
８８４    コンタクト・カード
９００    ユーザのログオン時にメッセンジャー・コンタクト・リストに視覚インジケータを追加する方法
１０００    格納サーバ８２０によってコンテンツ・ページ識別子を決定する方法
１１００    視覚インジケータをコンタクト・インジケータに追加する方法
１２００    要約モジュール用のソースを決定する方法
１３００    要約モジュールを取り出す方法
１４００    ＩＭユーザ・インターフェースに視覚インジケータを追加する方法
１５００    ＩＭインターフェースによって要約モジュールを提供する方法
１６１０、１７１０    ネットワーク・ブラウザ
１６２０    ｅメール・インターフェース・ページ
１６３０、１７３０    要約モジュール
１７２０    ユーザ・コンタクト・ページ
【図１】
2006139778.tif 000017
【図２Ａ】
2006139778.tif 000018
【図２Ｂ】
2006139778.tif 000019
【図２Ｃ】
2006139778.tif 000020
【図２Ｄ】
2006139778.tif 000021
【図３Ａ】
2006139778.tif 000022
【図３Ｂ】
2006139778.tif 000023
【図３Ｃ】
2006139778.tif 000024
【図４】
2006139778.tif 000025
【図５】
2006139778.tif 000026
【図６】
2006139778.tif 000027
【図７】
2006139778.tif 000028
【図８】
2006139778.tif 000029
【図９】
2006139778.tif 000030
【図１０】
2006139778.tif 000031
【図１１】
2006139778.tif 000032
【図１２】
2006139778.tif 000033
【図１３】
2006139778.tif 000034
【図１４】
2006139778.tif 000035
【図１５】
2006139778.tif 000036
【図１６】
2006139778.tif 000037
【図１７】
2006139778.tif 000038
【図１８】
2006139778.tif 000039
【外国語明細書】
2006139778000001.pdf