(57)【要約】  更新についての監視対象のコンテンツの所在を指し示す位置情報をユーザ装置（５１０）から受信する受信手段を備えるサーバ（５２０）が提供される。前記サーバ（５２０）は、前記コンテンツが更新されたか否かを定期的に判断する判断手段と、前記コンテンツが更新されたということを示すＳＩＰ要求メッセージを介して前記ユーザ装置に対して通知する通知手段と、も備える。
2010508566.tif 000002
【特許請求の範囲】
【請求項１】
更新についての監視対象のコンテンツの所在を指し示す位置情報をユーザ装置（５１０）から受信する受信手段（７０６）と、
前記コンテンツが更新されたか否かを定期的に判断する判断手段（７０８）と、
前記コンテンツが更新されたということを示すＳＩＰ要求メッセージを介して前記ユーザ装置（５１０）に対して通知する通知手段（７１２）と、
を備えることを特徴とするサーバ（５２０）。
【請求項２】
複数の前記位置情報を格納する記憶装置（７１０）を更に備え、
前記受信手段（７０６）は、前記ユーザ装置（７１０）から受信した位置情報を前記記憶装置（７１０）に格納すると共に、当該位置情報を前記ユーザ装置（７１０）に関連付け、
前記判断手段（７０８）は、前記記憶装置（７１０）に格納された前記位置情報のそれぞれに関連付けられた前記コンテンツのそれぞれが更新されたか否かを定期的に判断する
ことを特徴とする請求項１に記載のサーバ（５２０）。
【請求項３】
前記判断手段（７０８）は、前記コンテンツが最後に更新された時を示す時刻情報を定期的にダウンロードし、当該時刻情報を直近にダウンロードした時刻情報と比較することにより、前記コンテンツが更新されたか否かを判断し、
前記判断手段（７０８）は、前記コンテンツが更新されたと判断された場合に、前記位置情報によって指し示される場所から前記コンテンツをダウンロードする
ことを特徴とする請求項１又は２に記載のサーバ（５２０）。
【請求項４】
前記判断手段（７０８）は、前記位置情報によって指し示される場所から前記コンテンツを定期的にダウンロードし、当該コンテンツを直近にダウンロードしたコンテンツと比較することにより、前記コンテンツが更新されたか否かを判断する
ことを特徴とする請求項１又は２に記載のサーバ（５２０）。
【請求項５】
前記通知手段（７１２）は、前記ユーザ装置（５１０）に対して通知する際に、前記判断手段（７０８）がダウンロードした更新されたコンテンツを前記ＳＩＰ要求メッセージに含めることにより、当該コンテンツを前記ユーザ装置（５１０）に送信する
ことを特徴とする請求項３又は４に記載のサーバ（５２０）。
【請求項６】
前記通知手段（７１２）は、前記コンテンツが更新されたという判断と併せて所定の条件が満たされた場合に、前記ユーザ装置（５１０）に対して通知する
ことを特徴とする請求項１乃至５のいずれか１項に記載のサーバ（５２０）。
【請求項７】
前記所定の条件は、前記ユーザ装置（５１０）のユーザに関連付けられたユーザプロファイルに基づいて決定される
ことを特徴とする請求項６に記載のサーバ（５２０）。
【請求項８】
前記所定の条件は、
前記通知手段（７１２）による前記ユーザ装置（５１０）の直近の通知後に少なくとも所定量のコンテンツが更新されたこと、
所定のキーワードが前記更新されたコンテンツに含まれていること、及び
前記更新されたコンテンツが所定の時間内に更新されたものであること、
のうちの少なくとも１つを含む
ことを特徴とする請求項６又は７に記載のサーバ（５２０）。
【請求項９】
前記判断手段（７０８）がダウンロードした更新されたコンテンツを使用してカスタマイズされたコンテンツを生成する生成手段（７１６）
を更に備えることを特徴とする請求項３又は４に記載のサーバ（５２０）。
【請求項１０】
前記通知手段（７１２）は、前記ユーザ装置（５１０）に対して通知する際に、前記カスタマイズされたコンテンツを前記ＳＩＰ要求メッセージに含めることにより、当該カスタマイズされたコンテンツを前記ユーザ装置（５１０）に送信する
ことを特徴とする請求項９に記載のサーバ（５２０）。
【請求項１１】
前記生成手段（７１６）は、前記ユーザ装置（５１０）のユーザに関連付けられたユーザプロファイルに基づいて前記カスタマイズされたコンテンツを生成する
ことを特徴とする請求項９又は１０に記載のサーバ（５２０）。
【請求項１２】
前記ユーザ装置（５１０）、及びＩＰマルチメディア・サブシステムのホーム加入者サーバ（５４０）のうちの少なくとも一方から前記ユーザプロファイルを取得する取得手段（７１４）
を更に備えることを特徴とする請求項７、８、又は１１に記載のサーバ（５２０）。
【請求項１３】
更新についての監視対象の前記コンテンツは、ＲＤＦデータ及びＥＰＧデータのうちの少なくとも一方である
ことを特徴とする請求項１乃至１２のいずれか１項に記載のサーバ（５２０）。
【請求項１４】
更新についての監視対象のコンテンツの所在を指し示す位置情報をサーバ（５２０）に送信する位置情報送信手段（６０６）と、
更新についての監視対象の前記コンテンツが更新されたことを示すＳＩＰ要求メッセージを前記サーバ（５２０）から受信するメッセージ受信手段（６１０）と、
前記メッセージ受信手段（６１０）によって受信された通知の対象のコンテンツを受信するコンテンツ受信手段（６１２）と、
を備えることを特徴とするユーザ装置（５１０）。
【請求項１５】
前記ＳＩＰ要求メッセージに応えて、監視対象の前記コンテンツが更新されたということを前記ユーザ装置（５１０）のユーザに対して通知する通知手段（６１４）
を更に備えることを特徴とする請求項１４に記載のユーザ装置（５１０）。
【請求項１６】
前記ＳＩＰ要求メッセージは前記コンテンツを含み、
前記コンテンツ受信手段（６１２）は、前記コンテンツを前記ＳＩＰ要求メッセージから抽出することにより、当該コンテンツを受信する
ことを特徴とする請求項１４又は１５に記載のユーザ装置（５１０）。
【請求項１７】
前記サーバ（５２０）と、前記サーバ（５２０）からアクセス可能であるＩＰマルチメディア・サブシステムのホーム加入者サーバ（５４０）とのうちの少なくとも一方に、前記ユーザ装置（５１０）のユーザに関連付けられたユーザプロファイルを送信するプロファイル送信手段（６２４）を更に備え、
前記メッセージ受信手段（６１０）は、監視対象の前記コンテンツが更新されたという判断と併せて所定の条件が満たされたと前記サーバ（５２０）が判断した場合に、前記ＳＩＰ要求メッセージを受信し、
前記所定の条件は、前記ユーザプロファイルに基づいて規定される
ことを特徴とする請求項１４乃至１６のいずれか１項に記載のユーザ装置（５１０）。
【請求項１８】
監視対象の前記コンテンツは、ＲＤＦデータ及びＥＰＧデータのうちの少なくとも一方である
ことを特徴とする請求項１４乃至１７のいずれか１項に記載のユーザ装置（５１０）。
【請求項１９】
サーバ（５２０）とユーザ装置（５１０）とを含む通知システム（５００）であって、
前記サーバ（５２０）は、
更新についての監視対象のコンテンツの所在を指し示す位置情報を前記ユーザ装置（５１０）から受信する受信手段（７０６）と、
前記コンテンツが更新されたか否かを定期的に判断する判断手段（７０８）と、
更新対象の前記コンテンツが更新されたということを示すＳＩＰ要求メッセージを介して前記ユーザ装置（５１０）に対して通知する通知手段（７１２）と、
を備え、
前記ユーザ装置（５１０）は、
更新についての監視対象の前記コンテンツの所在を指し示す前記位置情報を前記サーバ（５２０）に送信する位置情報送信手段（６０６）と、
監視対象の前記コンテンツが更新されたことを示す前記ＳＩＰ要求メッセージを前記サーバ（５２０）から受信するメッセージ受信手段（６１０）と、
前記メッセージ受信手段（６１０）によって受信された通知の対象のコンテンツを受信するコンテンツ受信手段（６１２）と、
を備える
ことを特徴とする通知システム（５００）。
【請求項２０】
サーバ（５２０）の制御方法であって、
監視対象のコンテンツの所在を指し示す位置情報をユーザ装置（５１０）から受信する受信ステップ（Ｓ９０２）と、
前記コンテンツが更新されたか否かを定期的に判断する判断ステップ（Ｓ９０４）と、
前記コンテンツが更新されたということを示すＳＩＰ要求メッセージを介して前記ユーザ装置（５１０）に対して通知する通知ステップ（Ｓ９０６）と、
を備えることを特徴とする制御方法。
【請求項２１】
前記受信ステップ（Ｓ９０２）は、前記ユーザ装置（７１０）から受信した位置情報を記憶装置（７１０）に格納すると共に、当該位置情報を前記ユーザ装置（７１０）に関連付ける、格納ステップ（Ｓ９０２ａ）を含み、
前記判断ステップ（Ｓ９０４）は、前記記憶装置（７１０）に格納された前記位置情報のそれぞれに関連付けられた前記コンテンツのそれぞれが更新されたか否かを定期的に判断するステップ（Ｓ９０４）を含む
ことを特徴とする請求項２０に記載の方法。
【請求項２２】
前記判断ステップ（Ｓ９０４）は、前記コンテンツが最後に更新された時を示す時刻情報を定期的にダウンロードし、当該時刻情報を直近にダウンロードした時刻情報と比較することにより、前記コンテンツが更新されたか否かを判断するステップ（Ｓ９０４ｂ）を含み、
前記判断ステップ（Ｓ９０４）は、前記コンテンツが更新されたと判断された場合に、前記位置情報によって指し示される場所から前記コンテンツをダウンロードするステップ（Ｓ９０４ｃ）を含む
ことを特徴とする請求項２０又は２１に記載の方法。
【請求項２３】
前記判断ステップ（Ｓ９０４）は、前記位置情報によって指し示される場所から前記コンテンツを定期的にダウンロードし、当該コンテンツを直近にダウンロードしたコンテンツと比較することにより、前記コンテンツが更新されたか否かを判断するステップ（Ｓ９０４ｂ）を含む
ことを特徴とする請求項２０又は２１に記載の方法。
【請求項２４】
前記通知ステップ（Ｓ９０６）は、前記判断ステップ（Ｓ９０４）でダウンロードした更新されたコンテンツを前記ＳＩＰ要求メッセージに含めることにより、当該コンテンツを前記ユーザ装置（５１０）に送信するステップ（Ｓ９０６ａ）を含む
ことを特徴とする請求項２２又は２３に記載の方法。
【請求項２５】
前記サーバ（５２０）は、前記通知ステップ（Ｓ９０６）において、監視対象の前記コンテンツが更新されたという判断と併せて所定の条件が満たされた場合に、前記ユーザ装置（５１０）に対して通知する
ことを特徴とする請求項２０乃至２４のいずれか１項に記載の方法。
【請求項２６】
前記所定の条件は、前記ユーザ装置（５１０）のユーザに関連付けられたユーザプロファイルに基づいて決定される
ことを特徴とする請求項２５に記載の方法。
【請求項２７】
前記所定の条件は、
前記サーバ（５２０）が前記通知ステップ（Ｓ９０６）において前記ユーザ装置（５１０）に対して最後に通知した後に少なくとも所定量のコンテンツが更新されたこと、
所定のキーワードが前記更新されたコンテンツに含まれていること、及び
前記更新されたコンテンツが所定の時間内に更新されたものであること、
のうちの少なくとも１つを含む
ことを特徴とする請求項２５又は２６に記載の方法。
【請求項２８】
前記判断ステップ（９０４）でダウンロードした更新されたコンテンツを使用してカスタマイズされたコンテンツを生成する生成ステップ（Ｓ９０５）
を更に備えることを特徴とする請求項２２又は２３に記載の方法。
【請求項２９】
前記通知ステップ（Ｓ９０６）は、前記カスタマイズされたコンテンツを前記ＳＩＰ要求メッセージに含めることにより、当該カスタマイズされたコンテンツを前記ユーザ装置（５１０）に送信するステップ（Ｓ９０６ａ）を含む
ことを特徴とする請求項２８に記載の方法。
【請求項３０】
前記生成ステップ（Ｓ９０５）において、前記カスタマイズされたコンテンツは、前記ユーザ装置（５１０）のユーザに関連付けられたユーザプロファイルに基づいて生成される
ことを特徴とする請求項２８又は２９に記載の方法。
【請求項３１】
前記ユーザ装置（５１０）、及びＩＰマルチメディア・サブシステムのホーム加入者サーバ（５４０）のうちの少なくとも一方から前記ユーザプロファイルを取得する取得ステップ（Ｓ９０３）
を更に備えることを特徴とする請求項２６、２７、又は３０に記載の方法。
【請求項３２】
監視対象の前記コンテンツは、ＲＤＦデータ及びＥＰＧデータのうちの少なくとも一方である
ことを特徴とする請求項２０乃至３１のいずれか１項に記載の方法。
【請求項３３】
ユーザ装置（５１０）の制御方法であって、
監視対象のコンテンツの所在を指し示す位置情報をサーバ（５２０）に送信する位置情報送信ステップ（Ｓ８０２）と、
監視対象の前記コンテンツが更新されたことを示すＳＩＰ要求メッセージを前記サーバ（５２０）から受信するメッセージ受信ステップ（Ｓ８０４）と、
前記メッセージ受信ステップ（Ｓ８０４）において受信された通知の対象のコンテンツを受信するコンテンツ受信ステップ（Ｓ８０６）と、
を備えることを特徴とする制御方法。
【請求項３４】
前記ＳＩＰ要求メッセージに応えて、監視対象の前記コンテンツが更新されたということを前記ユーザ装置（５１０）のユーザに対して通知する通知ステップ（Ｓ８０５）
を更に備えることを特徴とする請求項３３に記載の方法。
【請求項３５】
前記ＳＩＰ要求メッセージは前記コンテンツを含み、
前記コンテンツ受信ステップ（Ｓ８０６）では、前記コンテンツを前記ＳＩＰ要求メッセージから抽出することにより、当該コンテンツが受信される
ことを特徴とする請求項３３又は３４に記載の方法。
【請求項３６】
前記サーバ（５２０）と、前記サーバ（５２０）からアクセス可能であるＩＰマルチメディア・サブシステムのホーム加入者サーバ（５４０）とのうちの少なくとも一方に、前記ユーザ装置（５１０）のユーザに関連付けられたユーザプロファイルを送信するプロファイル送信ステップ（Ｓ８０３）を更に備え、
前記メッセージ受信ステップ（Ｓ８０４）では、監視対象の前記コンテンツが更新されたという判断と併せて所定の条件が満たされたと前記サーバ（５２０）が判断した場合に、前記ＳＩＰ要求メッセージが受信され、
前記所定の条件は、前記ユーザプロファイルに基づいて規定される
ことを特徴とする請求項３３乃至３５のいずれか１項に記載の方法。
【請求項３７】
監視対象の前記コンテンツは、ＲＤＦデータ及びＥＰＧデータのうちの少なくとも一方である
ことを特徴とする請求項３３乃至３６のいずれか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブサイトのコンテンツの更新を監視し、更新に関する通知を提供する技術に関する。
【背景技術】
【０００２】
今日、多数のウェブサイトが、ニュース、天気予報、及びＴＶ番組表などの多様なコンテンツを、インターネットを介して社会一般に提供している。そのようなコンテンツは、典型的にはハイパーテキストマークアップ言語（ＨＴＭＬ）文書の形式で記述されているが、別の形式で記述されている場合もある。情報の所在は、ユニバーサル・リソース・アイデンティファイア（ＵＲＩ）によって指し示され、ＵＲＩを使用してアクセス可能である。
【０００３】
例えば、ユーザ（即ち、読者）がコンピュータ上でウェブブラウザを起動し、読みたいと思うニュースのＵＲＩ（例えば、http://www.******.com/news01.html）を入力する。すると、ウェブブラウザは入力されたＵＲＩからＨＴＭＬ文書をダウンロードし、構文解析し、ユーザ可読形式で表示する。
【０００４】
大半のコンテンツは定期的に更新される可能性が高いので、ユーザは最新状態を維持したい場合、定期的にコンテンツにアクセスしなければならない。しかしながら、極めて多数のウェブサイトが存在し、それぞれが多くのコンテンツを伴うので、そのようなコンテンツそれぞれにアクセスしてこれが更新されているか否かを判断することはユーザにとって面倒である。例えば、ウェブサイト"www.******.com"が５０個のニュースコンテンツ（即ち、news01.html, news02.html, ... ,news50.html）を提供する場合を考える。ユーザがニュースコンテンツの個々に実際にアクセスしない限り、各ニュースコンテンツが更新されたか否かを判断することはできないので、ユーザは５０個のＵＲＩに定期的にアクセスしなければならないが、これは面倒であり、また、ニュースコンテンツのいくつかが（或いは、最悪の場合は全てが）更新されていない場合は特に、時間の無駄である。
【０００５】
ＲＳＳ（ＲＤＦ／リッチ・サイト・サマリー）［１］はよく知られている技術であり、その目的は、更新されたコンテンツをユーザが追跡することを支援することにより、時間及び労力の浪費を減少させることである。ＲＳＳを実装するための重要なコンポーネントは、ウェブサイト上のコンテンツを要約する電子文書であるＲＳＳ文書である。ＲＳＳ文書は、ＸＭＬベースのリソース記述フレームワーク（ＲＤＦ）にエンコードされている。この理由により、ＲＳＳは、リッチ・サイト・サマリーよりもむしろＲＤＦサイト・サマリーの略語として扱われる場合がある。ウェブサイトと同様に、ＲＳＳ文書の所在自体もＵＲＩによって指し示される。
【０００６】
ＲＳＳ文書は、例えばウェブサイトによって提供される個々のコンテンツのタイトル及びＵＲＩなどのような、メタデータ情報のリストを含む。例えば、ウェブサイトが５０個のニュースコンテンツを提供する場合、ＲＳＳ文書は、最大５０個までの所定数のＵＲＩを、各ＵＲＩに対応する同数のタイトルなどと共に含むことができる。従って、ユーザはＲＳＳ文書をダウンロードするだけで、所与のコンテンツが更新されたか否かを認識することができる。
【０００７】
ＲＳＳ文書は、ウェブサイト上のＨＴＭＬ文書又は他のコンテンツから自動的に生成可能なので、ウェブサイト上の少なくとも１つのコンテンツが更新された場合に必ずＲＳＳ文書を生成することにより、更新されたウェブサイトの情報を容易且つ迅速に公開することができる。今日、ＲＳＳの主要な適用分野は、ニュースサイト又は「ブログ」として知られるウェブログの更新に関する情報を公開することである。
【０００８】
ＴＶ番組表に関しては、多数のネットワークが複数のチャネルを介してＴＶ番組を放送しているので、どのＴＶ番組を入手可能であるかを、いつ、又はどのチャネルでそれを入手可能であるかと共にユーザ（即ち、視聴者）が知ることは困難である。加えて、ネットワークは時々、番組スケジュールの要素を変更するように決定し、このことは、最新のＴＶ番組表を持ち続けようとするユーザの努力を更に複雑なものとする。
【０００９】
今日、最新のＴＶ番組表を迅速にユーザに提供するために、電子番組表（ＥＰＧ）がしばしば使用される。ＥＰＧデータは、或る時間（例えば、２００６年９月２７日の１５：００−１８：００、又は、２００６年９月２８日の午前０時から始まる１週間）に１以上のチャネルから入手可能なＴＶ番組に関する情報を含む。ＥＰＧデータは、主としてＴＶ受像機又はセットトップボックスのために提供されるが、コンピュータや、例えばパーソナルビデオレコーダ（ＰＶＲ）などのような他の装置にとっても入手可能である。
【００１０】
例えば、各ネットワークは、各ネットワークのＴＶ番組に関する情報を含むＥＰＧデータファイル（ＥＰＧ文書）を生成する。各ネットワークはウェブサイトを介してＥＰＧデータファイルを配信し、これらのウェブサイトは、ネットワークのローカル局によって運用され得るものであり、各局が別々のスケジュールを持つ。ネットワーク又はその放送局が放送スケジュールを変更した場合、自分達のウェブサイト上のＥＰＧデータファイルを更新する。従って、ユーザが１以上のウェブサイト（或いは、より具体的にはＥＰＧデータのＵＲＩ）を選択し、これらのＵＲＩからＥＰＧデータをダウンロードすれば、ＴＶ番組表を最新状態に維持することができる。
【００１１】
多様なＥＰＧデータ形式が存在し、例えＴＶ番組が同一であっても、ＥＰＧデータのために複数のプロバイダを持つことが可能である。それゆえ、ユーザは同一のＴＶチャネルのために複数のＵＲＩを選択することができる。
【発明の概要】
【発明が解決しようとする課題】
【００１２】
ウェブサイト上の所定のコンテンツ、又は所定のＴＶ番組表が更新されたか否かを継続的に追跡し続けるためには、ユーザは（全体的に又は部分的に）ＲＳＳ文書又はＥＰＧデータファイルを、例えそれらが実際には更新されていなくても、定期的にダウンロードしなければならない。換言すれば、ユーザはしばしば、新しい情報を何らもたらさないＲＳＳ文書又はＥＰＧデータをダウンロードする羽目になる。これらのダウンロードは、時間、帯域、及びお金を浪費する結果をもたらし得る。
【００１３】
この問題は、セルラ電話やセットトップボックスといった装置を介してダウンロードが行われる状況において、特に深刻である。その理由は、計算能力及び帯域のうちの少なくとも一方がしばしば限定されていること、又は、そのような状況ではしばしば送受信トラヒック量に基づいて料金請求が行われること、若しくはその両方である。
【課題を解決するための手段】
【００１４】
本発明の目的は、従前の課題を解決することである。
【００１５】
本発明の一態様によれば、更新についての監視対象のコンテンツの所在を指し示す位置情報をユーザ装置から受信する受信手段と、前記コンテンツが更新されたか否かを定期的に判断する判断手段と、前記コンテンツが更新されたということを示すＳＩＰ要求メッセージを介して前記ユーザ装置に対して通知する通知手段と、
を備えることを特徴とするサーバが提供される。
【００１６】
本発明の別の態様によれば、更新についての監視対象のコンテンツの所在を指し示す位置情報をサーバに送信する位置情報送信手段と、更新についての監視対象の前記コンテンツが更新されたことを示すＳＩＰ要求メッセージを前記サーバから受信するメッセージ受信手段と、前記メッセージ受信手段によって受信された通知の対象のコンテンツを受信するコンテンツ受信手段と、を備えることを特徴とするユーザ装置が提供される。
【００１７】
本発明の別の態様によれば、サーバとユーザ装置とを含む通知システムであって、前記サーバは、更新についての監視対象のコンテンツの所在を指し示す位置情報を前記ユーザ装置から受信する受信手段と、前記コンテンツが更新されたか否かを定期的に判断する判断手段と、更新対象の前記コンテンツが更新されたということを示すＳＩＰ要求メッセージを介して前記ユーザ装置に対して通知する通知手段と、を備え、前記ユーザ装置は、更新についての監視対象の前記コンテンツの所在を指し示す前記位置情報を前記サーバに送信する位置情報送信手段と、監視対象の前記コンテンツが更新されたことを示す前記ＳＩＰ要求メッセージを前記サーバから受信するメッセージ受信手段と、前記メッセージ受信手段によって受信された通知の対象のコンテンツを受信するコンテンツ受信手段と、を備えることを特徴とする通知システムが提供される。
【００１８】
本発明の別の態様によれば、サーバの制御方法であって、監視対象のコンテンツの所在を指し示す位置情報をユーザ装置から受信する受信ステップと、前記コンテンツが更新されたか否かを定期的に判断する判断ステップと、前記コンテンツが更新されたということを示すＳＩＰ要求メッセージを介して前記ユーザ装置に対して通知する通知ステップと、を備えることを特徴とする制御方法が提供される。
【００１９】
本発明の別の態様によれば、ユーザ装置の制御方法であって、監視対象のコンテンツの所在を指し示す位置情報をサーバに送信する位置情報送信ステップと、監視対象の前記コンテンツが更新されたことを示すＳＩＰ要求メッセージを前記サーバから受信するメッセージ受信ステップと、前記メッセージ受信ステップにおいて受信された通知の対象のコンテンツを受信するコンテンツ受信ステップと、を備えることを特徴とする制御方法が提供される。
【００２０】
本発明の主な利点は以下の通りである。ＳＩＰ  ＡＳは、ＵＥ（ユーザ装置）の代わりに、ウェブサイトによって提供されるコンテンツが更新されたか否かを判断する。コンテンツが実際に更新された場合にのみＵＥは通知を受ける。従って、ＵＥとウェブサイトとの間の無駄な通信、及びＵＥとＳＩＰ（セッション開始プロトコル）ＡＳ（アプリケーションサーバ）との間の無駄な通信のうちの少なくとも一方が削減される。加えて、コンテンツが更新されたということを示し且つ他のＳＩＰイベントと区別可能なＳＩＰ要求メッセージを使用してＳＩＰ  ＡＳがＵＥに通知を行うので、ＵＥのユーザは、そのＳＩＰ要求メッセージを、例えばＩＰ電話などの他のイベントと区別することができる。
【００２１】
本発明のその他の特徴は、添付図面を参照した以下の典型的な実施形態の説明により明らかになるであろう。添付図面においては、その全体を通して、類似した参照記号は同一若しくは同様の部分を示す。
【００２２】
添付図面は、本明細書に組み込まれてその一部を構成し、その説明と共に本発明の実施形態を説明し、本発明の原理を説明する役割を果たす。
【図面の簡単な説明】
【００２３】
【図１】スタンドアロン・アプリケーションのＲＳＳリーダの例を図解する。
【図２】スタンドアロン・アプリケーションのＲＳＳリーダのユーザインタフェースの例を図解する。
【図３】セルラ電話を例として用いて、スタンドアロン・アプリケーションとブラウザＲＳＳリーダとの比較を図解する。
【図４】図３に対応するＥＰＧの事例の概略図を示す。
【図５】実施形態に従う通知システムの概観を図解する。
【図６】実施形態に従うＵＥのブロック図である。
【図７】実施形態に従うＳＩＰ  ＡＳのブロック図である。
【図８】実施形態に従うＵＥによって実行される処理を示すフローチャートである。
【図９】実施形態に従うＳＩＰ  ＡＳによって実行される処理を示すフローチャートである。
【発明を実施するための形態】
【００２４】
ＲＳＳ／ＥＰＧリーダ：
典型的にはアプリケーションプログラムとして実装されるＲＳＳリーダは、１以上のウェブサイトからＲＳＳ文書（即ち、ＲＤＦデータ）を収集する。ＲＳＳリーダは、パーソナルコンピュータ、セルラ電話、又はセットトップボックスを含むがこれらに限定されないユーザ装置（ＵＥ）に搭載され得る。ＲＳＳリーダは、サーバ（ＲＳＳサーバ）に搭載されてもよい。
【００２５】
前者の場合、ＲＳＳリーダは「アプリケーションタイプのＲＳＳリーダ」と呼ばれ得る。後者の場合、ＲＳＳサーバがＵＥの代わりにＲＳＳ文書を収集し、そのＲＳＳ文書に基づいてＨＴＭＬ文書のような文書を生成する。ＵＥは生成されたＨＴＭＬ文書をダウンロードしてこれをウェブブラウザに表示する。それゆえ、後者の場合においてＲＳＳリーダは「ブラウザタイプのＲＳＳリーダ」と呼ばれ得る。
【００２６】
図１は、ＲＳＳリーダアプリケーションの例を図解する。図１において、パーソナルコンピュータ（ＰＣ）１００にインストールされているＲＳＳリーダ１０２は、インターネット１４０を介してウェブサイト１１０、１２０、及び１３０からＲＳＳ文書を定期的に収集する。ウェブサイト１１０は、例えばＨＴＭＬ文書１１２、１１３、および１１４などのコンテンツを持ち、そのコンテンツに基づいてＲＳＳ文書１１１を生成する。コンテンツの或る部分が更新された場合、ウェブサイト１１０はＲＳＳ文書１１１を再生成する。それゆえ、ＲＳＳリーダ１０２は、ＲＳＳ文書１１１を定期的にダウンロードしてこれを以前にダウンロードしたＲＳＳ文書１１１と比較した場合にのみ、ウェブサイト１１０上の何らかのコンテンツが更新されたか否かを判断することができる。ウェブサイト１２０及び１３０は、ウェブサイト１１０と同様に動作する。従って、ＲＳＳリーダは、多数のウェブサイトによって提供される大量のコンテンツについて更新を容易に監視することができる。なお、ＲＳＳリーダ１０２の振る舞いは完全にプル・ベースである。即ち、ＲＳＳ文書のダウンロード及びその処理は、ＲＳＳ文書の一部又は全部が更新されていない（即ち、再生成されていない）かもしれないにも関わらず、所定の間隔で定期的に実行される。
【００２７】
多くのＲＳＳリーダアプリケーションは、図２に示すように、今日の多くのＥメールクライアントに見られるものに類似したユーザインタフェースを持つ。図２に示す例においては、ウインドウ２００は３つのペインを持つ。即ち、ＲＳＳ文書ペイン２０２、タイトルペイン２０４、及びブラウザペイン２０６である。ＲＳＳ文書ペイン２０２は、ＲＳＳ文書を、換言すればＲＳＳリーダ１０２が更新を監視しようとするウェブサイトを、示す。タイトルペイン２０４は、選択されたＲＳＳ文書２０８に関連付けられたコンテンツのタイトルを示す。ブラウザペイン２０６は、選択されたタイトル２１０に関連付けられたコンテンツを、ユーザ可読形式で示す。典型的には、ウェブブラウザ機能がＲＳＳリーダアプリケーションに埋め込まれており、これにより、ブラウザペイン２０６におけるコンテンツの表示が達成される。
【００２８】
ＲＳＳリーダアプリケーションの中には、今日の多くのＥメールクライアントに見られるものの代わりに又はそれに加えて、ティッカーと呼ばれるユーザインタフェース要素を持つものもある。ティッカーは、コンピュータデスクトップ上の電光掲示板のように見えて、ＲＳＳ文書から獲得されたウェブコンテンツのハイライトを、ニュースヘッドラインと同様のやり方で提示する。
【００２９】
図３は、ＲＳＳリーダアプリケーション（即ち、アプリケーションタイプのＲＳＳリーダ）とＲＳＳリーダブラウザ（即ち、ブラウザタイプのＲＳＳリーダ）との比較を、セルラ電話３００及び３５０を例として用いて図解する。
【００３０】
ＲＳＳリーダアプリケーションについては、セルラ電話３００はＲＳＳリーダ３０２を備える。ＲＳＳリーダ３０２は例えば、Ｊａｖａ（登録商標）で実装されるアプリケーションプログラムである。図１に示すＲＳＳリーダ１０２と同様に、ＲＳＳリーダ３０２は移動ネットワーク３２０及びインターネット３２２を介して、１以上のウェブサイト３１０から１以上のＲＳＳ文書３１２を収集する。ＲＳＳリーダ３０２はＲＳＳ文書を解釈してそれをセルラ電話３００の表示デバイス上に表示する。
【００３１】
一方、ＲＳＳリーダブラウザについては、セルラ電話３５０はウェブブラウザ３５２を備えているので、ＲＳＳリーダを備える必要が無い。セルラ電話３５０は、移動ネットワーク３２０及びインターネット３２２を介して、セルラ電話３５０のユーザが更新を監視することを望むコンテンツのＵＲＩをＲＳＳサーバ３６０へ送信する。ＲＳＳリーダ機能を備えるＲＳＳサーバ３６０は、セルラ電話３５０から受信したＵＲＩによって指し示されるＲＳＳ文書を、インターネット３２２を介して収集する。そしてＲＳＳサーバは、収集したＲＳＳ文書を、セルラ（即ち、移動）電話に最適化された１以上のＨＴＭＬ文書に変換する。従って、ユーザは、ＲＳＳサーバ３６０からＨＴＭＬ文書を定期的にダウンロードしてそのＨＴＭＬ文書をウェブブラウザ３５２上に示すことにより、選択されたコンテンツが更新されたということを確認することができる。
【００３２】
ＲＳＳリーダアプリケーション及びＲＳＳリーダブラウザの両方の場合とも、背景技術のセクションで説明した通り、文書が更新されていないかもしれないにも関わらず、セルラ電話３００及び３５０は、ＲＳＳ文書、又はＲＳＳ文書から変換されたＨＴＭＬ文書を定期的にダウンロードしなければならない。
【００３３】
上述した説明は、最新のＴＶ番組表を継続的に取得するためにＵＥがＥＰＧを使用する状況にも、同様に当てはまる。
【００３４】
図４は、図３に対応するＥＰＧの事例の概略図を示す。図４において、セルラ電話４００及び４５０は、セルラ電話３００及び３５０に対応する。
【００３５】
ＲＳＳリーダアプリケーションについては、セルラ電話４００はＥＰＧリーダ４０２を備える。ＥＰＧリーダ４０２は例えば、Ｊａｖａ（登録商標）で実装されるアプリケーションプログラムである。ＲＳＳリーダ３０２と同様に、ＥＰＧリーダ４０２は移動ネットワーク３２０及びインターネット３２２を介して、１以上のウェブサイト４１０から１以上のＥＰＧ文書４１２を収集する。ＥＰＧリーダ４０２はＥＰＧ文書を解釈してそれをユーザ可読のＴＶ番組表の形式で表示する。ＥＰＧ文書（即ち、ＥＰＧデータ）はＲＳＳ文書がそうであってもよいのと同様にＸＭＬベースの文書であってもよいが、ＥＰＧ文書は、ＥＰＧリーダ４０２が解釈可能である限りどのような形式であってもよい。
【００３６】
ＲＳＳリーダブラウザについては、ＥＰＧリーダ機能を備え図３のＲＳＳサーバ３６０に対応するＥＰＧサーバ４６０が、セルラ電話４５０から受信したＵＲＩによって指し示されるＥＰＧ文書を、インターネット３２２を介して収集する。そしてＥＰＧサーバは、収集したＥＰＧ文書を、セルラ（即ち、移動）電話に最適化された１以上のＨＴＭＬ文書に変換する。従って、ユーザは、ＥＰＧサーバ４６０からＨＴＭＬ文書を定期的にダウンロードしてそのＨＴＭＬ文書をウェブブラウザ３５２上に示すことにより、ＴＶ番組スケジュールが更新されたということを確認することができる。
【００３７】
ＥＰＧ文書をＨＴＭＬ文書に変換する代わりに、ＥＰＧサーバ４６０は、ユーザプロファイルに基づいて複数のＥＰＧ文書を１つのＥＰＧ文書に統合してもよい。この場合、セルラ電話４５０はＥＰＧリーダ４０２を備え、統合されたＥＰＧデータをＥＰＧサーバ４６０からダウンロードする。
【００３８】
図３及び図４に示す例は、排他的ではない。換言すれば、例えば、セルラ電話３００は、ＲＳＳリーダ３０２、ウェブブラウザ３５２、及びＥＰＧリーダ４０２を備えることができる。この場合、セルラ電話３００は、アプリケーションタイプ又はブラウザタイプで適宜動作することができ、ＲＳＳ文書又はＥＰＧ文書を適宜ダウンロードすることもできる。
【００３９】
以下の説明においては、説明を簡潔にするために、図３に示すＲＳＳの事例が主として用いられる。しかしながら、以下の説明はＲＳＳ及びＥＰＧの両方に適用可能である。加えて、本発明のコンセプトは、ＨＴＭＬ文書、ＪＰＥＧ画像、又はＭＰＥＧ画像を含むがこれらに限定されないあらゆる種類のコンテンツに適用可能である。換言すれば、セルラ電話３００は、本実施形態に従い、例えばＨＴＭＬ文書を直接的に又は間接的に（即ち、ＲＳＳサーバ３６０のようなサーバを介して）ウェブサイト３１０からダウンロードすることができる。
【００４０】
通知システムの概観：
図５は、本実施形態に従う通知システム５００の概観を図解する。システム５００は、ＵＥ５１０と、ＳＩＰアプリケーションサーバ（ＳＩＰ  ＡＳ）５２０と、ＲＳＳプロバイダ５３０とを含む。いくつかの実施形態によれば、通知システム５００はＩＰマルチメディアシステム（ＩＭＳ）のホーム加入者サーバ（ＨＳＳ）５４０を含む。
【００４１】
ＵＥ５１０は、セッション開始プロトコル（ＳＩＰ）に準拠している。図５においてＵＥ５１０はセルラ電話として描写されているが、ＵＥ５１０は、ＳＩＰに準拠している限り、ＰＣ又はセットトップボックスを含むがこれらに限定されないいかなる種類のＵＥであってもよい。ＳＩＰ  ＡＳ５２０は、ＲＳＳリーダ機能を備え、ＳＩＰ  ＵＲＩによって特定される。ＲＳＳプロバイダ５３０は、１以上のＲＳＳ文書を提供するウェブサイトである。
【００４２】
本実施形態によれば、ＵＥ５１０は、ＲＳＳ文書の所在を指し示す１以上のＵＲＩ（以下、ＲＳＳ  ＵＲＩと呼ぶ）をＳＩＰ  ＡＳ５２０へ送信する。以下の説明においては例としてＳｕｂｓｃｒｉｂｅメソッドによるＳＩＰを用いるが、ＵＥ５１０は、ハイパーテキスト伝送プロトコル（ＨＴＴＰ）又はＳＩＰを含むがこれらに限定されないいかなるプロトコルを使用してＲＳＳ  ＵＲＩを送信してもよい。送信されるＵＲＩは、多様な方法で発見される。例えば、ＵＥ５１０のユーザは日常的なウェブサーフィンを通じてＵＲＩを取得することができる。
【００４３】
ＳＩＰ  ＡＳ５２０は、ＵＥ５１０に代わって、ＲＳＳ文書の更新を監視する。所与のＲＳＳ文書が更新されると、ＳＩＰ  ＡＳ５２０は、ＳＩＰ要求メッセージを介してＵＥ５１０に通知する。他のメソッドも同様に使用可能ではあるが、典型的には、Ｎｏｔｉｆｙメソッドが使用される。
【００４４】
ＲＳＳ文書が更新されていない場合はＳＩＰ  Ｎｏｔｉｆｙメソッドの通知が行われないので、ＵＥ５１０とＳＩＰ  ＡＳ５２０との間の通信（すなわち、無駄な通信）に関連する時間、帯域、及びお金のようなものの浪費を回避することができる。ＵＥ５１０は、ＲＳＳ文書が実際に更新された場合にのみ、ＳＩＰ  ＡＳ５２０を介して又はＲＳＳプロバイダ５３０から直接、ＲＳＳ文書をダウンロードするので、ＵＥ５１０とＲＳＳプロバイダ５３０との間の無駄な通信も回避することができる。
【００４５】
＜ＳＩＰイベントパッケージ＞
本実施形態によれば、ＳＩＰ  ＡＳ５２０から受信したＳＩＰ  Ｎｏｔｉｆｙメッセージが１以上のＲＳＳ文書が更新されたということを示すということをＵＥ５１０が認識可能なように、新しいＳＩＰイベントパッケージが定義される。換言すれば、ＵＥ５１０は、ＲＳＳ文書の更新に関するＳＩＰ  Ｎｏｔｉｆｙメッセージを、例えばＩＰ電話に関するもののような他のＳＩＰ要求メッセージと区別することができる。
【００４６】
新しいイベントパッケージの名前は、現存する名前と区別可能である限り、任意のものである。例えば、それは「ｒｓｓ」であってもよいし、より一般的に言って、「ｕｐｄａｔｅ」であってもよい。
【００４７】
この新しい名前は、Ｓｕｂｓｃｒｉｂｅメッセージ及びＮｏｔｉｆｙメッセージの中に存在するＥｖｅｎｔヘッダフィールド内に現れる。以下は、本実施形態に従うＳＩＰ  Ｎｏｔｉｆｙメッセージの例である。ここに示されるように、ＳＩＰ  Ｎｏｔｉｆｙメッセージは、メッセージのボディに更新されたコンテンツ（例えば、更新されたＲＳＳ文書）を含んでもよい。
【００４８】
===========================================
NOTIFY sip:user@imsop.com SIP/2.0
Via: SIP/2.0/UDP rssps.imsop.com;branch=z9hG4bKna998sk
From: <sip:service@imsop.com>;tag=ffd2
To: <sip:user@imsop.com>;tag=xfg9
Call-ID: 2010@imsop.com
Event: rss
Max-Forwards: 70
CSeq: 8775 NOTIFY
Content-Type: application/rdf+xml
Content-Length: ...
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns="http://purl.org/rss/1.0/">
<channel rdf:about="http://www.example.com">
<title>Example.com Newsdesk</title> 
<link>http://www.example.com</link> 
<dc:publisher>Example provides business intelligence </dc:publisher> 
<items>
<rdf:Seq>
<rdf:li
rdf:resource="http://www.example.com/xml_vid.asp?ttv_id=919" /> 
<rdf:li
rdf:resource="http://www.example.com/xml_vid.asp?ttv_id=918" /> 
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://www.example.com/xml_vid.asp?ttv_id=919">
<title>Newsdesk for week-ending 20/10/2006</title> 
<link>http://www.example.com/xml_vid.asp?ttv_id=919</link> 
<dc:date>2006-10-20</dc:date> 
<dc:creator>xxx</dc:creator> 
</item>
<item rdf:about="http://www.example.com/xml_vid.asp?ttv_id=918">
<title>Community WiFi</title> 
<link>http://www.example.com/xml_vid.asp?ttv_id=918</link> 
<dc:date>2006-10-19</dc:date> 
<dc:creator>xxx</dc:creator> 
</item>
</rdf:RDF>
=================================================
【００４９】
＜ユーザ装置＞
図６は、ＵＥ５１０のブロック図である。プロセッサ６０２は、ファームウェア及びオペレーティングシステムのようなコンピュータプログラムを実行し、それにより、ＵＥ５１０内に含まれる各コンポーネントを制御する。図６において、プロセッサ６０２内に含まれるコンポーネントは、典型的には、プロセッサ６０２によって実行されるコンピュータプログラムによって実装されるが、専用のハードウェアによって実装されても構わない。
【００５０】
送受信機６０４は、ＵＥ５１０と、例えばＳＩＰ  ＡＳ５２０又はＲＳＳプロバイダ５３０のような外部ノードとの間のデータの送受信を制御する。
【００５１】
位置情報送信ユニット６０６は、位置情報（典型的には、ＵＲＩ）をＳＩＰ  ＡＳ５２０へ送信する。送信されるＵＲＩは、例えばキーパッドのようなユーザインタフェース６０８から入力される。位置情報送信ユニット６０６は、ＳＩＰ  Ｓｕｂｓｃｒｉｂｅメッセージを介してＵＲＩを送信することができる。好適には、受信したＵＲＩに関連付けられたコンテンツの更新を監視しなければならないということをＳＩＰ  ＡＳ５２０が確認できるように、ＳＩＰ  Ｓｕｂｓｃｒｉｂｅメッセージは本発明のために定義されたイベント（例えば、"Event: rss"）に関連する。
【００５２】
メッセージ受信ユニット６１０は、ＳＩＰ要求メッセージ（例えば、ＳＩＰ  Ｎｏｔｉｆｙメッセージ）をＳＩＰ  ＡＳ５２０から受信する。ＳＩＰ  Ｎｏｔｉｆｙメッセージは、位置情報送信ユニット６０６によって送信されたＵＲＩに関連付けられているコンテンツが更新されたということを示す。換言すれば、ＳＩＰ  Ｎｏｔｉｆｙメッセージはここでは、本発明のために定義されたイベント（例えば、"Event: rss"）に関連する。この理由により、メッセージ受信ユニット６１０は、受信したＳＩＰ  Ｎｏｔｉｆｙメッセージがコンテンツの更新に関連するということを認識可能である。メッセージ受信ユニット６１０は、コンテンツ受信ユニット６１２及び通知ユニット６１４に対して、ＳＩＰ  Ｎｏｔｉｆｙメッセージが受信されたということを通知する。
【００５３】
コンテンツ受信ユニット６１２はＳＩＰ  ＮｏｔｉｆｙメッセージからＲＳＳ文書を抽出してＲＳＳリーダ６２０へ送信する。ＳＩＰ  ＮｏｔｉｆｙメッセージがＲＳＳ文書の代わりにＨＴＭＬ文書を含む場合は、コンテンツ受信ユニット６１２は抽出されたＨＴＭＬ文書をウェブブラウザ６２２へ送信する。ＳＩＰ  Ｎｏｔｉｆｙメッセージが更新されたコンテンツを含まない場合、コンテンツ受信ユニット６１２は、ＳＩＰ  ＡＳ５２０又はＲＳＳプロバイダ５３０から更新されたコンテンツをダウンロードする。
【００５４】
通知ユニット６１４は、例えばディスプレイ６１６にメッセージを示したりスピーカ６１８にオーディオ信号を送信したりすることにより、コンテンツが更新されたということをユーザに通知することを制御する。
【００５５】
ＲＳＳリーダ６２０は、ＲＳＳ文書を解釈し、これをユーザ可読形式でディスプレイ６１６に表示する。
【００５６】
ウェブブラウザ６２２は、ＨＴＭＬ文書を解釈し、これをユーザ可読形式でディスプレイ６１６に表示する。
【００５７】
プロファイル送信ユニット６２４は、汎用集積回路カード（ＵＩＣＣ）６２６からユーザファイルを取り出し、そのユーザプロファイルをＨＳＳ５４０へ送信する。或いは、プロファイル送信ユニット６２４は、ユーザプロファイルをＳＩＰ  ＡＳ５２０へ直接送信してもよい。
【００５８】
ＵＥ５１０は、処理されるデータに応じて他のコンポーネントを持っていてもよい。例えば、コンテンツ受信ユニット６１２がＥＰＧ文書を受信する場合、ＵＥ５１０はＥＰＧリーダを持つべきである。
【００５９】
＜ＳＩＰ  ＡＳ＞
図７は、ＳＩＰ  ＡＳ５２０のブロック図である。プロセッサ７０２は、ファームウェア及びオペレーティングシステムのようなコンピュータプログラムを実行し、それにより、ＳＩＰ  ＡＳ５２０内に含まれる各コンポーネントを制御する。図７において、プロセッサ７０２内に含まれるコンポーネントは、典型的には、プロセッサ７０２によって実行されるコンピュータプログラムによって実装されるが、専用のハードウェアによって実装されても構わない。
【００６０】
送受信機７０４は、ＳＩＰ  ＡＳ５２０と、例えばＵＥ５１０及びＲＳＳプロバイダ５３０のような外部ノードとの間のデータの送受信を制御する。
【００６１】
受信ユニット７０６は、位置情報（典型的には、ＵＲＩ）をＵＥ５１０から受信して判断ユニット７０８へ供給する。受信ユニット７０６にとって、複数のＵＲＩを一度に受信する必要は無い。判断ユニット７０８へ直接ＵＲＩを供給する代わりに、受信ユニット７０６は、記憶装置７１０へＵＲＩを送信してもよい。記憶装置７１０は、ＵＲＩを格納し、そのＵＲＩをＳＩＰ  ＡＳ５２０に送信したユーザと関連付ける。換言すれば、記憶装置７１０は、複数のユーザの各々のためにＵＲＩの複数のグループを格納することができる。判断ユニット７０８は、記憶装置７１０からＵＲＩを受信することができる。
【００６２】
判断ユニット７０８は、ＵＲＩに関連付けられたコンテンツが更新されたか否かを定期的に判断する。より具体的には、判断ユニット７０８は、ＵＲＩによって特定される場所（即ち、ＲＳＳプロバイダ５３０）からコンテンツに関する時刻情報（例えば、タイムスタンプ）を定期的にダウンロードし、以前にダウンロードしたタイムスタンプと比較する。判断ユニット７０８は、ダウンロードした時刻情報を記憶装置７１０に格納してもよい。所与のコンテンツの時刻情報が以前にダウンロードした時刻情報と異なる場合、判断ユニット７０８は、このコンテンツが更新されたと判断し、通知ユニット７１２に対して通知する。或いは、コンテンツが更新されたか否かを判断するために、判断ユニット７０８は、コンテンツ自体を定期的にダウンロードして以前にダウンロードしたコンテンツと比較してもよい。ダウンロードされたコンテンツは、記憶装置７１０に格納されてもよい。
【００６３】
コンテンツが更新された時に、通知ユニット７１２は、コンテンツが更新されたということを示すＳＩＰ  Ｎｏｔｉｆｙメッセージを介してＵＥ５１０に対して通知する。いくつかの実施形態においては、通知ユニット７１２は、ＲＳＳプロバイダ５３０又は記憶装置７１０から更新されたコンテンツを取り出してＳＩＰ  Ｎｏｔｉｆｙメッセージのボディに入れる。
【００６４】
いくつかの実施形態によれば、取得ユニット７１４が、ＵＥ５１０のユーザのユーザプロファイルをＨＳＳ５４０から取得する。或いは、取得ユニット７１４は、ＵＥ５１０から直接ユーザプロファイルを受信してもよい。取得ユニット７１４は、ユーザプロファイルを通知ユニット７１２へ供給する。この場合、コンテンツが更新されたことに加えて、ユーザプロファイルに基づいて決定された所定の条件が満たされた場合に、通知ユニット７１２はＵＥ５１０に対して通知する。所定の条件とは例えば、通知ユニット７１２によるＵＥ５１０に対する直近の通知後に少なくとも所定量のコンテンツ（例えば、３つ）が更新されたということや、所定のキーワード（例えば、「フットボール」）が更新されたコンテンツに含まれているということや、更新されたコンテンツが所定の時間（例えば、「２００５年５月２７日の午前０時以降」）に更新されたものであるということや、或いはこれらの何らかの組み合わせである。
【００６５】
いくつかの実施形態によれば、取得ユニット７１４は、ユーザプロファイルを生成ユニット７１６に供給する。生成ユニット７１６は、判断ユニット７０８及び記憶装置７１０のうちの少なくとも一方からコンテンツを受信し、カスタマイズされたコンテンツをユーザプロファイルに基づいて生成する。そして生成ユニット７１６は、カスタマイズされたコンテンツを通知ユニット７１２に供給する。従って、更新されたコンテンツをＵＥ５１０へ送信する代わりに、通知ユニット７１２は、カスタマイズされたコンテンツ（即ち、ＵＥ５１０のユーザのためにパーソナライズされたコンテンツ）をＵＥ５１０へ送信することができる。
【００６６】
いくつかの実施形態によれば、生成ユニット７１６は、コンテンツを変換する。例えば、生成ユニット７１６はＲＳＳ文書をＨＴＴＰ文書に変換する。この場合、生成ユニット７１６はＲＳＳリーダを含む。その結果、ＵＥ５１０がＲＳＳリーダ６２０を持たない場合であっても、ＵＥ５１０はウェブブラウザ６２２を使用してコンテンツを解釈することができる。
【００６７】
ＳＩＰ  ＡＳ５２０は、処理されるデータに応じて他のコンポーネントを持っていてもよい。例えば、判断ユニット７０８がＥＰＧ文書をダウンロードして生成ユニット７１２がそのＥＰＧ文書をＨＴＭＬ文書に変換する場合、生成ユニット７１２はＥＰＧリーダを含む。
【００６８】
いくつかの実施形態においては、生成ユニット７１６は、ユーザプロファイルに基づいて複数のＥＰＧ文書を１つのＥＰＧ文書に結合し、それにより、パーソナライズされたＥＰＧ文書を生成する。
【００６９】
手順：
図８は、本実施形態に従うＵＥ５１０によって実行される処理を示すフローチャートである。いくつかのステップを並行して又は逆順に実行することができよう。また、いくつかのステップは本発明にとって必須ではない。本発明の範囲は添付の請求の範囲によって規定される。
【００７０】
ステップＳ８０１で、ＵＥ５１０は、１以上のＵＲＩを含むＳＩＰ  Ｓｕｂｓｃｒｉｂｅメッセージを送信するように命令されたか否かを判断する。そのように命令された場合、処理はステップＳ８０２に進む。そのように命令されていない場合、処理はステップＳ８０４に進む。
【００７１】
ステップＳ８０２で、ＵＥ５１０は、ＳＩＰ  Ｓｕｂｓｃｒｉｂｅメッセージを介して、監視対象のコンテンツの所在を指し示すＵＲＩをＳＩＰ  ＡＳ５２０へ送信する。
【００７２】
ステップＳ８０３で、ＵＥ５１０は、ユーザプロファイルをＳＩＰ  ＡＳ５２０へ送信する。このステップは、以前に送信されたユーザプロファイルが修正されていない限りは、実行される必要が無い。或いは、例えばＵＥ５１０が通知システム５００のネットワークに参加する際に、ユーザプロファイルが事前に送信されてもよい。この場合、ユーザプロファイルはＨＳＳ５４０を介してＳＩＰ  ＡＳ５２０へ送信され得る。
【００７３】
ステップＳ８０４で、ＵＥ５１０は、ステップＳ８０２で送信されたＵＲＩに関連付けられたコンテンツが更新されたということを示すＳＩＰ  Ｎｏｔｉｆｙメッセージを受信したか否かを判断する。ＳＩＰ  Ｎｏｔｉｆｙメッセージを受信した場合、処理はステップＳ８０５に進む。ＳＩＰ  Ｎｏｔｉｆｙメッセージを受信していない場合、処理はステップＳ８０１に戻る。
【００７４】
ステップＳ８０５で、ＵＥ５１０は、ステップＳ８０２で送信されたＵＲＩに関連付けられたコンテンツが更新されたということをユーザに通知する。ステップＳ８０５における通知は、例えば、ディスプレイ６１６にメッセージを示したりスピーカ６１８にオーディオ信号を送信したりすることにより行われる。
【００７５】
ステップＳ８０６で、ＵＥ５１０は、更新されたコンテンツを受信する。更新されたコンテンツはＳＩＰ  Ｎｏｔｉｆｙメッセージから抽出されてもよいし、ＲＳＳプロバイダ５３０から受信されてもよい。いくつかの実施形態によれば、ＵＥ５１０は、更新されたコンテンツに基づいて生成された、カスタマイズされたコンテンツを受信する。いくつかの実施形態によれば、カスタマイズされたコンテンツは、更新されたコンテンツ及びステップＳ８０３で送信されたユーザプロファイルに基づいて生成される。
【００７６】
ステップＳ８０７で、ＵＥ５１０は、受信したコンテンツを解釈してこれをユーザ可読形式で表示する。そして処理はステップＳ８０１に戻る。
【００７７】
図９は、本実施形態に従うＳＩＰ  ＡＳ５２０によって実行される処理を示すフローチャートである。いくつかのステップは並行して又は逆順に実行されてもよいし、いくつかのステップは本発明にとって必須ではない。本発明の範囲は添付の請求の範囲によって規定される。
【００７８】
ステップＳ９０１で、ＳＩＰ  ＡＳ５２０は、１以上のＵＲＩを含むＳＩＰ  Ｓｕｂｓｃｒｉｂｅメッセージを受信したか否かを判断する。ＳＩＰ  Ｓｕｂｓｃｒｉｂｅメッセージを受信した場合、処理はステップＳ９０２に進む。ＳＩＰ  Ｓｕｂｓｃｒｉｂｅメッセージを受信していない場合、処理はステップＳ９０４に進む。
【００７９】
ステップＳ９０２で、ＳＩＰ  ＡＳ５２０は、ＳＩＰ  Ｓｕｂｓｃｒｉｂｅメッセージを介して、監視対象のコンテンツの所在を指し示すＵＲＩをＵＥ５１０から受信する。いくつかの実施形態によれば、ステップＳ９０２は、ステップＳ９０２ａを含み、ここでは、ＳＩＰ  ＡＳ５２０はＵＲＩを記憶装置７１０に格納する。
【００８０】
ステップＳ９０３で、ＳＩＰ  ＡＳ５２０は、ステップＳ８０３でＵＥ５１０がユーザプロファイルを送信している場合は、そのユーザプロファイルをＵＥ５１０から受信する。或いは、ユーザプロファイルは、例えばＵＥ５１０が通知システム５００のネットワークに参加する際に事前に受信されてもよい。以前に受信されたユーザプロファイルが修正されない限り、このステップは実行される必要が無い。いくつかの実施形態によれば、ＳＩＰ  ＡＳ５２０は、ＵＥ５１０ではなくＨＳＳ５４０からユーザプロファイルを受信してもよい。
【００８１】
ステップＳ９０４で、ＳＩＰ  ＡＳ５２０は、ステップＳ９０２で受信したＵＲＩに関連付けられたコンテンツが更新されたか否かを判断する。コンテンツが更新された場合、処理はステップＳ９０６に進む。コンテンツが更新されていない場合、処理はステップＳ９０１に戻る。図９に示すようにステップＳ９０４の処理は繰り返し実行されるので、ＳＩＰ  ＡＳ５２０はステップＳ９０４を通じて判断を定期的に実行する。
【００８２】
いくつかの実施形態によれば、ＳＩＰ  ＡＳ５２０はステップＳ９０４で、ユーザプロファイルに基づいて規定された所定の条件が満たされたか否かを判断する。この場合、所定の条件が満たされ且つコンテンツが更新された場合に、処理がステップＳ９０６に進む。
【００８３】
いくつかの実施形態によれば、ステップＳ９０４は３つのステップ、Ｓ９０４ａ、Ｓ９０４ｂ、Ｓ９０４ｃを含む。ステップＳ９０４ａで、ＳＩＰ  ＡＳ５２０は、ステップＳ９０２で受信したＵＲＩに関連付けられたコンテンツに関する時刻情報（例えば、タイムスタンプ）をダウンロードする。時刻情報は、コンテンツが最後に更新された時を示す。ダウンロードされた時刻情報は、例えば記憶装置７１０に格納される。ステップＳ９０４ｂで、ＳＩＰ  ＡＳ５２０は、その時刻情報を以前にダウンロードした時刻情報と比較する。それらが相互に異なる場合、処理はステップＳ９０４ｃに進む。それらが同一である場合、コンテンツは更新されていないので、処理はステップＳ９０１に戻る。ステップＳ９０４ｃで、ＳＩＰ  ＡＳ５２０は更新されたコンテンツをダウンロードして、例えば記憶装置７１０に格納する。
【００８４】
いくつかの実施形態によれば、ＳＩＰ  ＡＳ５２０は、ステップＳ９０４ａでコンテンツ自体をダウンロードし、ステップＳ９０４ｂで、そのダウンロードしたコンテンツを以前にダウンロードしたコンテンツと比較する。コンテンツが更新されている場合、更新されたコンテンツは既にダウンロードされているので、処理はステップＳ９０４ｃをスキップしてステップＳ９０４ｂからステップＳ９０６へ進む。
【００８５】
ステップＳ９０６で、ＳＩＰ  ＡＳ５２０は、コンテンツが更新されたということを示すＳＩＰ  Ｎｏｔｉｆｙメッセージを介して、ＵＥ５１０に対して通知する。いくつかの実施形態によれば、ステップＳ９０６はステップＳ９０６ａを含み、ここでは、ＳＩＰ  ＡＳ５２０は更新されたコンテンツをＳＩＰ  Ｎｏｔｉｆｙメッセージのボディに入れる。従って、ＳＩＰ  ＡＳ５２０は、ＵＥ５１０に対して通知するのと同時に、更新されたコンテンツを送信することができる。
【００８６】
いくつかの実施形態によれば、ＳＩＰ  ＡＳ５２０はステップＳ９０５で、カスタマイズされたコンテンツを生成し、ステップＳ９０６で、カスタマイズされたコンテンツを送信する。ステップＳ９０５で、ＳＩＰ  ＡＳ５２０は、コンテンツの形式を変換することによって（例えば、ＲＳＳ文書をＨＴＭＬ文書に変換することによって）、カスタマイズされたコンテンツを生成する。或いは、ＳＩＰ  ＡＳ５２０は、複数のコンテンツをユーザプロファイルに基づいて結合することによって、カスタマイズされたコンテンツを生成してもよい。
【００８７】
ステップＳ９０６の処理を実行した後、処理はステップＳ９０１に戻る。
【００８８】
他の実施形態：
いくつかの実施形態は、ＩＭＳ標準に準拠した、料金収集のための手順を含む。
【００８９】
ＳＩＰ  ＡＳ５２０がＲＳＳプロバイダ５３０から初めてＲＳＳ文書をダウンロードする際に、ＳＩＰ  ＡＳ５２０は、価格情報もダウンロードする。ＳＩＰ  ＡＳ５２０は次いで、ＲＳＳプロバイダ５３０によって認証される。
【００９０】
ＳＩＰ  ＡＳ５２０がＲＳＳプロバイダ５３０からＲＳＳ文書を受信する時はいつも、そのＲＳＳ文書に関係するあらゆる価格情報も考慮に入れられる。ＲＳＳ文書にサブスクライブしている全てのユーザ、即ちステップＳ８０２でそのＲＳＳ文書に関連するＵＲＩを送信した全てのユーザは、その価格情報に従って料金請求される。
【００９１】
価格情報は、特定の文書であってもよい。価格情報はＤｉａｍｅｔｅｒ文書であってもよいし、通信メカニズムはＲＳＳであってもよい。ＲＳＳが使用される場合、ＲＳＳ文書はＨＴＴＰＳ上で安全に送信され得る。
【００９２】
いくつかの実施形態によれば、ステップＳ８０２を通じたサブスクリプション段階においてユーザが各自のお気に入りのＵＲＩをＳＩＰ  ＡＳ５２０に登録するので、ＳＩＰ  ＡＳ５２０は、複数のＵＲＩが収集される場所となる。この立場を利用して、ＳＩＰ  ＡＳ５２０は、可能であれば専用のウェブインタフェースを介して、これらのＵＲＩを他のユーザが利用可能なようにできる。その結果、以下の関連サービスが導入され得るであろう。
【００９３】
カテゴリー化：  ＲＳＳリーダ・アプリケーションサーバは、収集したＵＲＩをカテゴリー毎にグループ化して、ユーザに提示する。これにより、ユーザは、求められているウェブサイトのＵＲＩ、特にＲＳＳ／ＥＰＧのＵＲＩを、容易に見つけることができる。
【００９４】
キーワード検索：  ＳＩＰ  ＡＳ５２０は、キーワード検索インタフェースをユーザに提供する。キーワード検索インタフェースは、キーワードに関連するコンテンツ（例えば、ＲＳＳ文書）を提供するウェブサイト・ソースのＵＲＩのリストを返す。
【００９５】
統計：  ＳＩＰ  ＡＳ５２０は、どのウェブサイトが最も人気があるかを示す統計を取る（即ち、人気のあるウェブサイトが提供しているＵＲＩにはより多くの人がサブスクライブしている）。この情報（例えば、全ての関心カテゴリーについてのトップ１０のリスト）をユーザに提示することにより、ＳＩＰ  ＡＳ５２０はユーザに有用な基準を提供する。
【００９６】
本発明の利点：
上述したように、ＳＩＰ  ＡＳは、ＵＥの代わりに、ウェブサイトによって提供されるコンテンツが更新されたか否かを判断する。コンテンツが実際に更新された場合にのみ、ＵＥは通知を受けてコンテンツをダウンロードする。
【００９７】
従って、ＵＥとウェブサイトとの間の無駄な通信、及びＵＥとＳＩＰ  ＡＳとの間の無駄な通信のうちの少なくとも一方が削減される。この削減は、ＵＥにとっての計算能力及び帯域のうちの少なくとも一方が限られている場合、又は送受信されたトラヒック量に基づいて料金請求が行われる場合、若しくはその両方の場合に、特に有利である。加えて、コンテンツが更新されたということを示し且つ他のＳＩＰイベントと区別可能なＳＩＰ要求メッセージを使用して、ＳＩＰ  ＡＳがＵＥに対して通知するので、ＵＥのユーザはそのＳＩＰ要求メッセージを、ＩＰ電話などの他のイベントと区別することができる。
【００９８】
しかしながら、ＵＥは、ＰＣ、セットトップボックス、又はセルラ電話を含むがこれらに限定されない、ＳＩＰに準拠したあらゆる種類の装置でよい。ＳＩＰ  ＡＳが更新を監視するコンテンツは、ＲＳＳ文書、ＥＰＧ文書、又はＨＴＴＰ文書を含むがこれらに限定されない、あらゆる種類のコンテンツでよい。
【００９９】
代表的な実施形態を参照して本発明を説明してきたが、本発明は開示された代表的な実施形態に限定されないということが理解されよう。以下の請求項の範囲は、変形例、及び、均等な構造及び機能を全て包含するように、最も広い解釈に合わせられるべきである。
【０１００】
参考文献：
1. RDF Site Summary (RSS) Specification 1.0,
http://web.resource.org/rss/1.0/spec
2. SIP-specific Event Notification, RFC3265
【図１】
2010508566.tif 000003
【図２】
2010508566.tif 000004
【図３】
2010508566.tif 000005
【図４】
2010508566.tif 000006
【図５】
2010508566.tif 000007
【図６】
2010508566.tif 000008
【図７】
2010508566.tif 000009
【図８】
2010508566.tif 000010
【図９】
2010508566.tif 000011
【国際調査報告】
2010508566.tif 000012
2010508566.tif 000013