JP2009104254A - 情報配信装置、情報配信方法及び情報配信システム - Google Patents

Abstract

【課題】リソースの更新情報をリアルタイムでユーザに提供する。
【解決手段】端末２−１が指定した所定のリソースに関する更新情報を、端末２−１に配信する情報配信装置１００において、端末２−１から、所定のリソースの更新情報の配信要求を受け付けるとともに、所定のリソースに関する更新情報を端末に配信する配信部１０２と、所定のリソースの更新を検知してリソースの更新情報を生成し、生成した更新情報を配信部１０２に出力する更新情報生成部１０１とを備えた。そして、配信部１０２において、更新情報生成部１０１から出力された更新情報を取得した時点で取得した更新情報を端末に配信するようにした。
【選択図】図１

Description

本発明は、情報配信装置、情報配信方法及び情報配信システムに関し、特に端末が指定した所定のリソースに関する更新情報を配信する情報配信装置及び情報配信方法、情報配信システムに関する。

ウェブサイト（以下、Ｗｅｂサイトと称する）の更新情報を公開又は配信するための手段として、ＲＳＳ（Really Simple Syndication/RDF Site Summary）やＡｔｏｍが知られている。ＲＳＳ又はＡｔｏｍ（以下、ＲＳＳ／Ａｔｏｍと称する）とは、ウェブページ（以下Ｗｅｂページと称する）上に記載されたデータの属性情報を構造化して表現するためのフォーマットであり、ＸＭＬ（Extensible Markup Language）で記載される。ＲＳＳ／Ａｔｏｍで記載されたデータはフィードと呼ばれ、ＲＳＳ／Ａｔｏｍフィードには、Ｗｅｂサイトの見出しや要約、更新時刻情報などを記載することができる。

近年では、ＲＳＳ／Ａｔｏｍフィードを使用して、更新情報のみならず、プレスリリースや新製品情報、サポート情報等を配信することも行われている。また、音声データファイルを公開するための方法としても、ＲＳＳ／Ａｔｏｍフィードが使用されている。そしてユーザは、ＲＳＳ／Ａｔｏｍ対応のブラウザやＲＳＳ／Ａｔｏｍリーダと呼ばれる専用のソフトウェアもしくは、リーダが組み込まれたウェブブラウザを用いて、ＲＳＳ／Ａｔｏｍフィードを取得することができる。これにより、実際にＷｅｂページ等の情報提供元にアクセスしなくても、更新情報を取得することができるようになる。

特許文献１には、ＲＳＳを用いてＷｅｂサイトの更新情報を配信することについて記載してある。
特開２００５−２８４３３４号公報

ところで、ＲＳＳ／Ａｔｏｍフィードは、Ｗｅｂサイト等で情報が更新されたタイミング等に自動的に生成され、生成されたフィードはＷｅｂサーバ内に記憶される。そして、クライアント（ＲＳＳ／Ａｔｏｍ対応ブラウザ又はＲＳＳ／Ａｔｏｍリーダ）から送信されたフィード取得要求を受信したタイミングで、クライアントにＲＳＳ／Ａｔｏｍフィードが配信される。

つまり、クライアント側からＲＳＳ／Ａｔｏｍフィードに定期的にアクセスし、ＲＳＳ／Ａｔｏｍフィードを取得するという、いわゆるクライアントプル型配信が行われる。ＲＳＳ／Ａｔｏｍフィードの取得にはＧＥＴメソッドやＰＯＳＴメソッド等が用いられる。そして、ユーザ等によって設定された所定の間隔おきに、クライアントからサーバに対して、ＲＳＳ／Ａｔｏｍフィードの取得を要求するＧＥＴ／ＰＯＳＴコマンドが送信され、これらのコマンドを受信したＲＳＳ／Ａｔｏｍサーバから、都度ＲＳＳ／Ａｔｏｍフィードが返信される。

ところが、クライアントからのフィード取得要求は、ＲＳＳ／Ａｔｏｍフィードが更新されているか否かに係わらず行われるものであり、ＲＳＳ／Ａｔｏｍフィードが更新されていない場合でも、ＲＳＳ／Ａｔｏｍフィードの送信が行われることになる。このような方式では、クライアントからサーバに対して不要なアクセスが行われることになり、サーバや回線に大きな負担がかかってしまうという問題があった。

また、このようなクライアントプル型配信においては、サーバにおいて実際に情報が更新されたタイミングと、クライアントからサーバに対して行われるＲＳＳ／Ａｔｏｍフィード取得要求のタイミングとが異なる場合がほとんどである。よって、ユーザは、Ｗｅｂサイト等の更新情報等をリアルタイムで取得することができないという問題があった。

本発明はかかる点に鑑みてなされたものであり、データ（リソース）の更新がされた場合に、更新情報をリアルタイムでユーザに提供することを目的とする。

本発明は、端末（クライアント）が指定した所定のリソースに関する更新情報を端末に配信する情報配信装置（サーバ）において、端末から、所定のリソースの更新情報の配信要求を受け付けるとともに、所定のリソースに関する更新情報を端末に配信する配信部と、所定のリソースの更新を検知してリソースの更新情報を生成し、生成した更新情報を配信部に出力する更新情報生成部とを備えた。そして、配信部において、更新情報生成部から出力された更新情報を取得した時点で取得した更新情報を端末に配信するようにしたものである。

このようにしたことで、リソースの更新の検知からリソース更新の情報通知までの処理がすべて情報配信装置において行われるようになるとともに、リソースの更新が行われるとすぐに、リソースの更新情報がクライアントに配信されるようになる。

本発明によると、リソース更新が検知された段階でリソースの更新情報が生成され、生成された更新情報が即座にクライアントに配信されるため、クライアントのユーザはリソースの更新情報をリアルタイムで取得することができるようになる。

また、リソースの更新の検知からリソース更新の情報通知までの処理がすべて情報配信装置において行われるため、クライアントから情報配信装置に対して、更新の確認を目的とした問い合わせが行われなくなり、情報配信装置や通信にかかる負担が軽減される。

以下、本発明の第１の実施の形態について、図１〜図８を参照して説明する。本実施の形態は、本発明の情報配信システムを、ＩＰ（Internet Protocol）ネットワークを通じて、テレビ番組や映画などの映像を配信するＩＰＴＶに適用した場合の例としてある。ＩＰＴＶの実現手段としては、パケット網上でマルチメディアサービスを実現させる技術であるＩＭＳ（IP Multimedia Subsystem）を利用する。よって本例における「リソース」は、ＩＰＴＶで配信される映像等のコンテンツとなる。

図１は、本実施の形態によるシステムの構成図である。図１において、ＳＩＰサーバ１００とクライアント１−１とクライアント２−１は、互いにネットワーク５を介して接続されている。クライアント１−１のユーザは、ＩＰＴＶの映像コンテンツを生成又は更新するリソース保有者であり、クライアント２−１のユーザは、リソース保有者が生成又は更新したコンテンツを受信して視聴するユーザである。

ＳＩＰサーバ１００は、更新情報生成部としてのフィード生成部１０１と、フィード配信部１０２と、ロケーション管理部１０３とで構成される。フィード生成部１０１は、リソース保有者１−１から送られた更新の通知を受信したタイミングで、コンテンツの更新情報を含むフィードを生成し、生成したフィードをフィード配信部１０２に送信する。フィード配信部１０２は、クライアント２−１からフィードの購読要求を受け付けた場合に、フィードの購読が要求されているコンテンツの種類と、購読要求元のクライアントの情報とをロケーション管理部１０３に送信する。またフィード配信部１０２は、フィード生成部１０１から送信されたフィードを、フィードの購読要求元であるクライアント２−１に配信する。

ロケーション管理部１０３では、ＳＩＰ ＵＲＩ（Uniform Resource Identifier）で記載された各クライアントのＩＤとトランスポート・アドレス（ＩＰアドレスとポート番号）との対応情報や、同じくＳＩＰ ＵＲＩで記載された、リソース保有者の所有するコンテンツの保存場所情報等の登録を受け付ける。また、フィードの購読要求が出されているリソースの種類と、購読要求の送信元のクライアントとの対応情報等の登録も受け付ける。

また、図１には図示していないが、ＳＩＰサーバ１００は、クライアント１−１と２−１との間でのＳＩＰメッセージを仲介するプロキシ・サーバの機能も有する。

なお、図１にはクライアントとして１−１と２−１の２台のみを図示してあるが、クライアントの台数は２台に限定されるものではない。また、図１では、説明を分かりやすくするため、リソース保有者とユーザとの役割をクライアントによって固定してあるが、実際には、それらの役割はユーザの操作等に応じて切り替わるものとする。例えばクライアントが、リソースの更新情報の配信（フィードの購読）要求をＳＩＰサーバ１００に送信したり、ネットワーク５を介してコンテンツを取得した場合には、そのクライアントはユーザとなる。また、そのクライアントにおいて、コンテンツの視聴と同時にリソースの生成や更新も行うこともあり、その場合には、ひとつのクライアントが、リソース保有者であると同時にユーザでもあることになる。

次に、図２を参照して、ＳＩＰサーバ１００の構成例について説明する。ＳＩＰサーバ１００は、制御部１１０と、ＲＯＭ（Read Only Memory）１１１、ＲＡＭ（Random Access Memory）１１２、ハードディスクなどより構成される記憶部１１３、キーボードやマウスなどより構成される操作部１１５、通信部１１７とで構成される。

制御部１１０は、ＲＯＭ１１１に記憶されているプログラム、またはＲＡＭ１１２にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１１２には、制御部１１０が各種の処理を実行する上において必要なデータなども記憶される。図１を参照して説明したフィード生成部１０１やフィード配信部１０２は、制御部１１０の制御に基づいて動作するものであり、同じく図１で説明したロケーション管理部１０３は、記憶部１１２の内部などに構築される。フィード配信部１０２から出力されるフィードは、通信部１１７とネットワーク５を介してクライアント２−１に伝送される。

上述した各部は、バス１２０を介して互いに接続してあり、記憶部１１３はインタフェース（Ｉ／Ｆ）部１１４を介して、操作部１１５はＩ／Ｆ部１１６を介してバス１２０に接続してある。

次に、図３を参照して、クライアント１−１と２−１の構成例について説明する。本例においては、クライアント１−１もクライアント２−１も、同一の構成としてあるものとする。クライアント１―１（又は２−１）は、制御部１２と、ＲＯＭ１３、ＲＡＭ１４、記憶部１５、操作部１７、マイクロフォン１９、音声処理部２０、音声出力部２１、音声処理部２２、表示部２３、表示制御部２４、通信部２５とで構成される。これらの各部は、バス１１を介して互いに接続してあり、記憶部１５はＩ／Ｆ部１６を介して、操作部１７はＩ／Ｆ部１８を介してバス１１に接続してある。

制御部１２と、ＲＯＭ１３、ＲＡＭ１４、記憶部１５、操作部１７、表示部２３、表示制御部２４、通信部２５については、ＳＩＰサーバ１００と同様の構成であるため、説明を省略する。音声処理部２０は、マイクロフォン１９からのアナログ音声信号をデジタル音声データに変換し、必要に応じて圧縮する。音声処理部２２は、バス１１に送出されたデジタル音声データを、圧縮されているものについては伸長して、アナログ音声信号に変換する。音声出力部２１は、スピーカやヘッドフォン等で構成される。

このように構成されたクライアント２−１において、ＳＩＰサーバ１００から送信されたフィードが通信部２５を介して受信されると、受信されたフィードはバス１１を通して制御部１２に送られる。制御部１２では、フィードの構文解析等が行われ、解析されたフィードは、制御部１２によってＨＴＭＬ（Hyper Text Markup Language）等のデータに変換されて、更新情報として表示制御部２４に出力される。そして、表示制御部２４の制御に基づいて表示部２３上に更新情報が表示される。なお、ここではフィードをＨＴＭＬ文書に変換する例を挙げているが、表示部２３での表示形式に合わせて、他のデータフォーマットに変換するようにしてもよい。

表示部２３に表示される更新情報の中には、コンテンツの保存場所情報がリンクとして張ってあり、そのリンクがユーザによって操作部１７を通して選択されると、通信部２５を通して、コンテンツの所有者であるクライアント１−１に対して接続要求が送信される。クライアント１−１によって接続要求が受け入れられ、クライアント１−１との接続（メディアセッション）が確立した後は、先ほどユーザによって選択されたコンテンツがクライアント１−１から２−１に伝送される。

クライアント１−１から伝送されたコンテンツに映像データが含まれている場合には、映像データはバス１１を通して表示制御部２４に送信される。そして、表示制御部２４で復号等の処理が行われた後に表示部２３に出力され、表示部２３上に映像として表示される。コンテンツに音声データが含まれている場合には、音声データはバス１１を通して音声処理部２２に送信され、音声処理部２２でデータ伸張等の処理が行われた後に、音声出力部２１から出力される。

次に、図４を参照して、クライアント２−１からフィードの購読要求がＳＩＰサーバ１００に送信されてから、コンテンツ更新情報としてのフィードがＳＩＰサーバ１００からクライアント２−１に配信され、その情報を基にクライアント２−１において、実際にコンテンツが取得されるまでの処理の例について説明する。図４においては、クライアント２−１が通知を希望する更新情報は、ＩＰＴＶで放映されるプログラムの番組表（ＥＰＧ（Electric Program Guide））に関する更新情報であるものとする。

まずユーザとしてのクライアント２−１は、更新情報を配信して欲しいコンテンツの種類をＳＵＢＳＣＲＩＢＥリクエストのリクエストライン部分に記述して、フィード購読要求としてＳＩＰサーバ１００のフィード配信部１０２に送信する（ステップＳ１）。 ここで配信されるＳＵＢＳＣＲＩＢＥリクエストの記述例を、図５（ａ）に示してある。図５（ａ）の先頭行Ｌｎ１はリクエストラインであり、リクエストライン内のＲｅｑｅｓｔ−ＵＲＩには“sip:media-epg-p1@sip.media.server.example”が指定されている。つまりクライアント２−１のユーザは、“sip:media-epg-p1@sip.media.server.example”というＵＲＩで管理されるリソースに関する更新情報の購読を、要求していることが示されている。

また、行Ｌｎ２に記載されたＥｖｅｎｔヘッダにおいて、イベント名に“ｆｅｅｄ”が指定してある。これにより、ユーザが通知を希望するイベントの種類が、「フィード」に特定される。さらに行Ｌｎ３には、Ａｃｃｅｐｔヘッダとして“application/atom+xml”が指定されている。つまり、クライアント２−１によって受け入れ可能な形式は「Ａｔｏｍ」であることが示されている。ここで「受け入れ可能な形式」として指定しているは、ＳＵＢＳＣＲＩＢＥリクエストの返信として送信される、ＮＯＴＩＦＹメッセージのボディフォーマットのコンテントタイプである。

なお本例では、フィードのリンク先情報としてＳＩＰ ＵＲＩを使用するため、ＵＲＬ以外の情報を含めることができるＡｔｏｍを採用している。今後、ＲＳＳでもリンク先にＵＲＬ以外のＵＲＩを含めることができるようになった場合には、ＲＳＳを使用するようにしてもよい。もしくは、それ以外のデータ形式を用いるようにしてもよい。

図４の説明に戻ると、フィード配信部１０２は、クライアント２−１からのリクエストを受け入れる場合には、応答コード２００を用いて返信する（ステップＳ２）。ここで、シーケンスには記載していないが、クライアント２−１がフィードの購読を希望するコンテンツの種類と、購読要求元のクライアント２−１とが対応付けられて、ＳＩＰサーバ１００のロケーション管理部１０３（図１参照）に登録される。

次に、フィード配信部１０２からクライアント２−１に対して、この時点での最新の更新情報が記載されたフィードＦ１が、ＮＯＴＩＦＹリクエストのボディ部分に格納されて配信される（ステップＳ３）。ここで配信されるＮＯＴＩＦＹリクエストの記述例を、図５（ｂ）に示してある。図５（ｂ）に示されたリクエストでは、行Ｌｎ４のイベントヘッダに“ｆｅｅｄ”が指定してあり、行Ｌ５のＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダに、“application/atom+xml”と指定してある。つまり、今回通知するイベントの種類は「フィード」であり、ボディ部分に含めたデータのフォーマット（ボディフォーマット）のコンテントタイプは「Ａｔｏｍ」であることが示されている。そして、行Ｌｎ６に示したボディの部分に、今回配信するフィードＦ１を格納してある。もし、ＡｔｏｍでなくＲＳＳを使用する場合には、Ｃｏｎｔｅｎｔ−ＴｙｐｅヘッダにはＭＩＭＥタイプを指定するようにする。

ここで配信されるフィードＦ１は、番組表の更新情報に関するフィードを購読している他のユーザには既に配信済みのものであるが、新規に購読を希望したクライアント２−１にとっては最新の内容となるため、この時点でクライアント２−１にフィードＦ１が配信される。フィードＦ１を受信したクライアント２−１からは、応答コード２００を用いた返信が行われる（ステップＳ４）。なお、フィード生成部１０１で生成されたフィードは、図示せぬメモリ等に記憶させてあり、フィード配信部１０２は、必要に応じて記憶されたフィードを読み出して配信するものとする。

図６に、フィードＦ１の記述例を示してある。図６において、要素Ｅ１と示した部分のうち、＜title＞のタグで挟まれた部分はフィードのタイトル（“SIP EPG”）を示しており、＜id＞のタグで挟まれた部分には、フィードに付与されたＩＤが記載されている。＜updated＞のタグで挟まれた部分には、フィードの更新日時（Sun, 10 Jun 2007 11:23:45）が記されており、その下の、＜subtitle＞のタグで囲まれた部分には、フィードのサブタイトル（“A list of media contents info”）を記載してある。個々の番組の情報は、要素２やＥ３として示された＜entry＞要素の中に記載されている。

要素Ｅ２には、“Program 02”の更新情報が記載されており、要素Ｅ３には、“Program 03”の更新情報が記載されている。要素Ｅ２及びＥ３において、＜pubDate＞のタグで囲まれた部分には、個々のプログラムが更新された日時が示されている。“Program 02”の更新日時は“Sun, 10 Jun2007 11:00:00”であるのに対して、“Program 03”の更新日時は“Sun, 10 Jun2007 10:00:00”と記載してある。つまり、このフィードＦ１には、更新日時が古いプログラムから順に下から記載されている。＜link＞として示されているのは、プログラムの実際の保存場所情報であり、“sip:media-epg-p1@sip.media.server.example”のように、ＳＩＰ ＵＲＩで記述してある。また、＜author＞として、リソース（この場合はプログラム）の更新者の名前（Program03はCarol、Program02はBob）も記載してある。

つまり、図６に示したフィードＦ１には、＜entry＞のタグで囲まれたボディ部分に、Ｃａｒｏｌによって２００７年６月１０日（日）の１０：００に更新された「Ｐｒｏｇｒａｍ０３」の情報と、Ｂｏｂによって２００７年６月１０日（日）の１１：００に更新された「Ｐｒｏｇｒａｍ０２」の情報とが記載されていることになる。

再び図４に戻って説明を続けると、リソース保有者であるクライアント１−１において、プログラム（リソース）の更新がされると（ステップＳ５）、クライアント１−１からＳＩＰサーバ１００のフィード生成部１０１に対して、ＰＵＢＬＩＳＨリクエストを用いてリソース更新の通知がされる（ステップＳ６）。ＳＩＰサーバ１００のフィード生成部１０１では、クライアント１−１に対して“２００ ＯＫ”の返信をすると（ステップＳ７）、クライアント１−１から受信したＰＵＢＬＩＳＨリクエストに記載の内容を基に、フィードＦ１を更新して、フィードＦ２とする（ステップＳ８）。生成されたフィードＦ２は、フィード配信部１０２に送信される（ステップＳ９）。

フィード配信部１０２では、フィードＦ２を受信すると、その内容をＮＯＴＩＦＹリクエストのボディに含めてクライアント２−１に送信する（ステップＳ１０）。そして、ＮＯＴＩＦＹリクエストを受信したクライアント２−１からフィード配信部１０２に対して、“２００ ＯＫ”のレスポンスが返される（ステップＳ１１）。

図７には、フィードＦ２の記述例を示してある。フィードＦ２において、要素Ｅ６、Ｅ７と示した部分は、それぞれフィードＦ１の要素Ｅ２とＥ３に対応している。つまり、前回配信されたフィードの中に記載されていた各プログラムの更新情報が、そのまま記載されている。そして、要素Ｅ６の上部に位置する要素Ｅ５の部分に、最新の更新情報が記載されている。

要素Ｅ５には、Ａｌｉｃｅによって２００７年６月１０日（日）の１２：００：００に更新された「Ｐｒｏｇｒａｍ０１」の情報が記載されている。フィードＦ２は、図４のシーケンス図のステップＳ８で更新されたものであり、フィードＦ２は、図４のステップＳ７でクライアント１−１から送信されたリソースの更新情報を元に、フィード生成部１０１で生成されたものである。よって、クライアント１−１（のユーザ）はＡｌｉｃｅであることになる。

またフィードＦ２には、要素Ｅ４の＜updated＞タグに囲まれた部分の日時（＝フィードの生成日時）と、要素Ｅ５の、＜pubDate＞タグに囲まれた部分の日時とが、同じ“Sun, 10 Jun2007 12:00:00”であることが示されている。これは、要素Ｅ５に記載されたニュースが更新されると同時に、リソースの更新情報を含むフィードが生成されたことを意味する。図４における、リソースの更新が行われるステップＳ５から、フィードがクライアント２−１に配信されるステップＳ１０までの処理が、一連の時間の流れで行われるためであり、本例によれば、リソースの更新情報がリアルタイムでユーザに通知されるようになる。

なお、ここでは説明を分かりやすくするため、リソースの更新時刻とフィードの生成時刻とフィードの配信時刻とを同一の時刻としてあるが、実際には、リソースが更新されてからフィードが配信されるまでの間に、フィードの更新（ステップＳ８）に要する時間や、フィード生成部１０１とフィード配信部１０２との間でのフィード受け渡しに要する時間等が含まれるものとする。よって、フィードの配信時刻は、リソースの更新時刻にこれらの時間を足した時間となる。

図４のステップＳ１２以降には、ステップＳ１０でフィード配信部１０２から配信されたフィードの情報を基に、クライアント２−１によって実際にコンテンツが取得されるまでの間の処理を示してある。図３を参照して行った説明で述べたように、クライアント２−１に配信されたフィードは、ＨＴＭＬ形式等の書式に変換されて表示部２３（図３参照）に表示され、表示部２３には、リソースの保存場所情報がリンクとして表示される。

図８に、表示部２３に表示される更新情報の例を示してある。図８にＡ１として示した領域には、フィードＦ２（図７参照）の要素Ｅ５に記載された内容が記述してある。つまり、Ａｌｉｃｅによって更新された“Program03”の情報が記載されている。“Program03”と記載された部分にはリンクを張ってあり、フィードＦ２の要素Ｅ５の中に＜link＞として記載された“sip:media-epg-p1@sip.media.server.example”が埋め込まれている。図８でＡ２と示した領域は、フィードＦ２の要素Ｅ６の部分と対応しており、Ａ３と示した領域は、フィードＦ２の要素Ｅ７の部分と対応している。

これらのリンクのうちのいずれか、もしくはすべてが、クライアント２−１のユーザによって選択されることにより、クライアント２−１からリソース保有者であるクライアント１−１に対して、ＩＮＶＩＴＥリクエストを用いたセッションの確立要求が送信される（図４のステップＳ１２）。

ここで送信されるＩＮＶＩＴＥリクエストには、ＳＤＰ(Session Description Protocol)が添付され、ＳＤＰの中には、クライアント２−１が希望する帯域（ＱｏＳ（Quality of Service））やコーデックの情報等が記載される。ＩＮＶＩＴＥリクエストを受信したクライアント１−１において、要求が受け入れられた場合には、クライアント２−１に対して“２００ ＯＫ”のレスポンスが返される（ステップＳ１３）。そして、クライアント１−１とクライアント２−１との間でメディアセッションが確立される（ステップＳ１４）。クライアント２−１は、メディアセッションの確立後に行われるリアルタイム通信を通して、コンテンツを取得する。リアルタイム通信の実現には、例えばＲＴＳＰ（Real-time Streaming Protocol）が使用される。

以上説明した本実施の形態の構成及び処理によれば、リソースの更新が行われたタイミングでその更新情報を含むフィードが生成され、生成されたフィードが、フィードの購読を希望するクライアント（ユーザ）に即座に送信されるため、ユーザが、リソースの更新情報等をリアルタイムで取得することができるようになる。

また、上述した本実施の形態の構成及び処理によれば、リソース更新の検知からフィードの配信までの処理がＳＩＰサーバ１００によって行われるため、クライアント側からサーバに対するポーリング処理が不要となる。よって、サーバに対して不要なアクセスが行われることがなくなり、サーバ及び回線の負担を軽減することができるようになる。

また、上述した本実施の形態の構成及び処理によれば、リソースの更新情報を通知するためのフィードに、リソースの作成者情報やサブタイトル等のメタデータも記述されるため、リソースの更新情報とその属性情報とをユーザ側で一度に確認することができるようになる。この場合、テレビジョン放送の複数のチャンネルの情報を１つのフィードにまとめて記載して配信するようにしてもよい。

また、上述した本実施の形態の構成及び処理によると、フィードにリソースの保存場所情報も記載されるため、ユーザは、表示部等に表示されたリンクをクリックする等の簡単な操作を行うだけで、リソースを取得することができるようになる。

また、上述した本実施の形態の構成及び処理によると、ＳＵＢＳＣＲＩＢＥリクエストを用いてフィードの購読要求を行ったユーザに対して、ユーザが通知を希望するリソースの更新情報がＮＯＴＩＦＹリクエストを用いて配信されるようになるため、ユーザが必要とする情報のみが、必要なタイミングで提供されるようになる。

なお、上述した実施の形態では、リソース保有者であるクライアント１−１がＳＩＰサーバ１００に対して、ＳＩＰのＰＵＢＬＩＳＨメソッドを用いてリソースの更新情報を通知するようにしたが、ＳＵＢＳＣＲＩＢＥリクエストとＮＯＴＩＦＹリクエストによって、リソース保有者とＳＩＰサーバ１００との間で、リソース更新情報のやりとりを行うようにしてもよい。

この場合は、予めＳＩＰサーバ１００からリソース保有者であるクライアント１−１に対して、ＳＵＢＳＣＲＩＢＥリクエストを用いてイベント・ステート（この場合はリソースの更新）の通知要求を行っておく。このようにすれば、リソースの更新がある毎に、リソース更新者からＳＩＰサーバ１００に対してＮＯＴＩＦＹメッセージが送信されるようになる。もしくは、ＨＴＴＰ等の別のプロトコルを用いて、リソース保有者からＳＩＰサーバ１００に対してリソースの更新を通知するようにしてもよい。

また、上述した実施の形態では、フィード生成部１０１からフィード配信部１０２に対して、フィードの受け渡し（送信）が行われる構成としたが、フィードの実体はやりとりせず、フィードの更新情報とフィードの保存場所情報のみを通知するようにしてもよい。この場合は、フィードファイルを管理するファイルシステム等を別途設けて、フィード生成部１０１が生成したフィードをそこに保存するようにする。そして、フィードを保存したタイミングで、例えば“/xml/feed/new.xml”等のフィードの保存場所情報を含む更新の通知を、フィード生成部１０１からフィード配信部１０２に送信するようにすればよい。

また、上述した実施の形態では、ＩＰＴＶを通して提供されるプログラムの番組表をフィードとして配信する例を挙げたが、ＳＩＰ ＵＲＩで管理されるリソースの情報であれば、他の情報をフィードとして配信するようにしてもよい。図９には、ＩＰ電話端末の電話帳の更新情報をフィードにした場合の例を示してある。

要素Ｅ８と示した箇所には、タイトルやフィードのＩＤ情報、フィードの更新日時情報等が記載されており、要素Ｅ９やＥ１０として示したボディの部分に、ＳＩＰ ＵＲＩで表現される電話番号が記載されている。要素Ｅ９には、Ｂｏｂの電話番号が“sip:bob@sip.example”のように記載されており、＜pubDate＞には、“Sun, 10 Jun 2007 12:00:00”のように、電話番号の更新日時が記載されている。要素Ｅ１０には、Ｃａｒｏｌの電話番号の更新情報が記載されている。このように、電話帳に関する更新情報を、メタデータと一緒にフィードとして配信するようにしてもよい。

＜第２の実施の形態＞
次に、図１０〜図１４を参照して、本発明の第２の実施の形態について説明する。本実施の形態では、テキストデータや画像データ等で構成されるニュースの更新情報を、フィードとして配信する形態に適用したものである。ニュースを構成するテキストデータや画像データには、ＳＩＰ ＵＲＩで管理されているものと、Ｗｅｂサーバで管理されているものが両方含まれているものとする。なお、以下の説明においてはＳＩＰ ＵＲＩで管理されるリソースをＳＩＰリソース、Ｗｅｂサーバで管理されるリソースをＷｅｂリソースと称する。

図１０は、本実施の形態によるシステムの構成図である。図１０に示すクライアント１−１〜１−３と、クライアント２−１と２−２は、ネットワーク５を介してアプリケーションサーバ２００と接続している。図１０に示すクライアント１−１のユーザは、ＳＩＰ ＵＲＩで管理されるリソースの生成や更新を行うリソース保持者であり、クライアント１−２のユーザは、Ｗｅｂサーバで管理されるリソースの生成や更新を行うリソース保持者であり、クライアント１−３のユーザは、ＳＩＰ ＵＲＩで管理されるリソースとＷｅｂサーバで管理されるリソースの両方を生成又は更新するリソース保持者である。クライアント２−１と２−２のユーザは、これらのリソースを利用するユーザである。アプリケーションサーバ２００は、ＳＩＰサーバとＷｅｂサーバの両方の機能を有する構成としてある。

アプリケーションサーバ２００は、ＨＴＴＰ（Hypertext Transfer Protocol）処理部２０１と、データベース（以下、ＤＢと称する）２０２と、フィード生成部２０３と、フィード配信部２０４と、ロケーション管理部２０５とで構成される。ＨＴＴＰ処理部２０１は、クライアントから送信されたＨＴＴＰリクエストの解析や応答処理を行う。例えば、クライアント１−２又は１−３からＰＯＳＴメソッドやＰＵＴメソッドを用いてリソースが送られてきた場合には、受け取ったリソースをＤＢ２０２に保存する。また、クライアント１−２又は１−３からＧＥＴコマンドが送信された場合には、コマンド内で指定されたリソースをＤＢ２０２から読み出して、要求元のクライアントに送信する。

フィード生成部２０３は、リソースの更新を検知したタイミングで、つまり、ＨＴＴＰ処理部２０１が、クライアント１−２又は１−３から送られたＰＯＳＴコマンドやＰＵＴコマンドを受信したタイミングで、コンテンツの更新情報を含むフィードを生成する。そして生成したフィードをフィード配信部２０４に送信する。フィード配信部２０４、ロケーション管理部２０５は、図１におけるフィード配信部１０２とロケーション管理部１０３と同様の処理を行うため、説明を省略する。また、アプリケーションサーバ２００の内部構成は、図２に記載のものと同様であり、クライアント１−２と１−３の内部構成は、図３に記載のものと同様であるため、説明を省略する。

次に、図１１を参照して、クライアント２−１からアプリケーションサーバ２００にフィードの購読要求が出されてから、リソースの更新情報を含むフィードがクライアント２−１に送信され、その情報を基に、クライアント２−１において実際にリソースが取得されるまでの処理の例について説明する。

まず、クライアント２−１からアプリケーションサーバ２００のフィード配信部２０４に対して、ＳＵＢＳＣＲＩＢＥリクエストを用いてフィードの購読要求が送信されると（ステップＳ２１）、フィード配信部２０４からクライアント２−１に対して、“２００ ＯＫ”のレスポンスが返される（ステップＳ２２）。この時点では、クライアント２−１が購読を希望するリソースに関するフィードがまだ一度も生成されていない（フィードがメモリ上に記憶されていない）ものとすると、次のステップＳ２３では、フィード配信部２０４からクライアント２−１に対して、ボディを含まないＮＯＴＩＦＹリクエストが送信される。そして、ＮＯＴＩＦＹリクエストを受信したクライアント２−１からフィード配信部２０４に対して、“２００ ＯＫ”のレスポンスが返される（ステップＳ２４）。

ここで、ＳＩＰリソースとＷｅｂリソースの保持者であるクライアント１−３において、ＷｅｂリソースとＳＩＰリソースの両方を含むニュースが更新されると、つまり、ＷｅｂリソースとＳＩＰリソースの両方が同時に更新されると（ステップＳ２５）、その更新情報が、ＷｅｂリソースについてはＨＴＴＰのＰＯＳＴコマンドを用いてＨＴＴＰ処理部２０１に送信され、ＳＩＰリソースについては、ＰＵＢＬＩＳＨリクエストを用いてフィード生成部２０３に送信される（ステップＳ２６）。ここで、図示はしていないが、ＨＴＴＰ処理部２０１によって、ＰＯＳＴコマンドに添付されたリソースがＤＢ２０２の所定の場所に保存される。そして次のステップＳ２７で、ＨＴＴＰ処理部２０１とフィード生成部２０３からクライアント１−３に対して、“２００ ＯＫ”のレスポンスが返される。なお、図１１では、クライアント１−３がアプリケーションサーバ２００に対して、Ｗｅｂリソースの更新を通知する手段として、ＨＴＴＰのＰＯＳＴコマンドを用いた場合を例に挙げたが、ＰＵＴコマンド等の他のコマンドを用いるようにしてもよい。

フィード生成部２０３は、ステップＳ２５でクライアント１−３から送信されたリソース更新の通知を元にフィードＦ３−１を生成し（ステップＳ２８）、生成したフィードＦ３−１をフィード配信部２０４に送信する（ステップＳ２９）。

図１２に、フィードＦ３−１の記述例を示してある。要素Ｅ１１と示した部分には、フィードのタイトル（“The Latest News”）や、フィードのＩＤ（sip:news@sip.app.server.example）、フィードの更新日時（Sun, 10 Jun2007 12:10:00）、フィードのサブタイトル（“News Headlines with Web URL and SIP URI”が記載されている。そして、要素Ｅ１２として示した＜entry＞で囲まれたボディの部分に、リソース（ニュース）の更新情報を記載してある。

要素Ｅ１２には、＜title＞のタグで囲まれた箇所に“A piece of news about entertainment”というタイトルのニュースの更新情報が記載されており、その更新日時は、＜putDate＞タグで囲まれた部分に示されるように、“Sun, 10 Jun2007 12:10:00”であることが示されている。この日時は、フィード作成日時（要素Ｅ１１の＜updated＞）と同じである。つまり、“A piece of news about entertainment”というタイトルのニュースが更新されたタイミングで、フィードが生成されたことが分かる。

また要素Ｅ１２には、＜link＞タグで囲まれた箇所が２箇所あり、１つは、
“http://www.app.server.example/entertainment/20070610121000.html”と記載されているようにＷｅｂリソースへのリンクであり、もう１つは、
“sip:news-entertainment-20070610121000@sip.app.server.example”と記載されているように、ＳＩＰリソースへのリンクである。つまり、クライアント１−２によって更新されたのは、http://www.app.server.example/entertainment/20070610121000.htmlに保存されたＷｅｂリソースと、“sip:news-entertainment-20070610121000@sip.app.server.example”に保存されたＳＩＰリソースとで構成される“A piece of news about entertainment”というタイトルのニュースであったことが分かる。

図１１のステップＳ２９で、フィード生成部２０３からフィード配信部２０４に送信されたフィードＦ３−１は、次のステップＳ３０で、フィード配信部２０４からクライアント２−１に対してＮＯＴＩＦＹリクエストによって送信される。そして、ＮＯＴＩＦＹリクエストを受信したクライアント２−１からフィード配信部２０４に対して、“２００ ＯＫ”のレスポンスが返される（ステップＳ３１）。

クライアント２−１のユーザが、フィードＦ３−１（図１２参照）の要素Ｅ１２に記載されたＷｅｂリソースを選択した場合には、クライアント２−１からアプリケーションサーバ２００のＨＴＴＰ処理部２０１に対して、リソースの取得要求としてのＨＴＴＰリクエストが送信される（ステップＳ３２）。ＨＴＴＰリクエストとしては、例えばＧＥＴコマンド等が用いられる。ＨＴＴＰリクエストを受信したＨＴＴＰ処理部２０１は、クライアント２−１に対して、ＨＴＴＰレスポンスを用いてリソースを送信する（ステップＳ３３）。

クライアント２−１のユーザが、フィードＦ３−１（図１２参照）の要素Ｅ１２に記載されたＳＩＰリソースを選択した場合には、クライアント２−１からリソース保有者であるクライアント１−３に対して、ＩＮＶＩＴＥリクエストを用いたセッションの確立要求が送信される（ステップＳ３４）。ＩＮＶＩＴＥリクエストを受信したクライアント１−３において、要求が受け入れられた場合には、クライアント２−１に対して“２００ ＯＫ”のレスポンスが返される（ステップＳ３５）。そして、メディアセッションが確立される（ステップＳ３６）。クライアント２−１は、メディアセッションの確立後に行われるリアルタイム通信を通して、コンテンツを取得する。

次に、図１３を参照して、ＳＩＰリソース保有者であるクライアント１−１と、Ｗｅｂリソース保有者であるクライアント１−２によってリソースが更新されてから、その情報がクライアント２−１に配信され、クライアント２−１においてリソースが取得されるまでの処理の例について説明する。なお図１３のシーケンス図は、図１１のシーケンス図と時間的に連続しているものであり、クライアント２−１は、アプリケーションサーバ２００のフィード配信部２０４に対して既にフィードの購読要求を送信済みであるものとする。

まず、Ｗｅｂリソースの保有者であるクライアント１−２において、Ｗｅｂリソースの更新が行われると（ステップＳ３７）、アプリケーションサーバ２００のＨＴＴＰ処理部２０１に対して、ＨＴＴＰのＰＯＳＴコマンドを用いてリソースが送信される（ステップＳ３８）。ＰＯＳＴコマンドを受信したＨＴＴＰ処理部２０１は、ＰＯＳＴコマンドに含まれたリソースをＤＢ２０２に保存するとともに、クライアント１−２に対して、“２００ ＯＫ”のレスポンスを返す（ステップＳ３９）。

アプリケーションサーバ２００のフィード生成部２０３では、クライアント１−２から送信されたＰＯＳＴコマンドがＨＴＴＰ処理部２０１によって受信されたことを検知すると、ＰＯＳＴコマンドに記載の情報を基に、フィードＦ３−１（図１２参照）を更新してフィードＦ３−２とする（ステップＳ４０）。そして、生成したフィードＦ３−２をフィード配信部２０４に送信する（ステップＳ４１）。

図１４（ａ）に、フィードＦ３−２の記述例を示してある。フィードの下方の要素Ｅ１５と示された部分には、図１２の要素Ｅ１２の部分の情報がそのまま記載されており、その上段の要素Ｅ１４の部分に、今回クライアント１−２から通知されたリソースの更新情報を記載してある。要素Ｅ１４には、＜title＞のタグで囲まれた箇所に“A piece of news about sports”というタイトルのニュースの更新情報が記載されており、その更新日時は、＜putDate＞タグで囲まれた部分に示されるように、“Sun, 10 Jun2007 12:20:00”であることが示されている。この日時は、フィードの作成日時（要素Ｅ１３の＜updated＞）と同じである。つまり、“A piece of news about sports”というタイトルのニュースが更新されたタイミングで、フィードが生成されたことが分かる。

また、要素Ｅ１４の中の＜link＞で囲まれた箇所に
“http//:www.app.server.example/sports/20070610122000.html”として、ニュースを構成するデータの保存場所が記載されている。

図１３のステップＳ４１で、フィード生成部２０３からフィード配信部２０４に送信されたフィードＦ３−２は、次のステップＳ４２で、フィード配信部２０４からクライアント２−１に対してＮＯＴＩＦＹリクエストによって送信される。そして、ＮＯＴＩＦＹリクエストを受信したクライアント２−１からフィード配信部２０４に対して、“２００ ＯＫ”のレスポンスが返される（ステップＳ４３）。

クライアント２−１のユーザが、フィードＦ３−２（図１４（ａ）参照）の要素Ｅ１４に記載されたＷｅｂリソースを選択した場合には、クライアント２−１からアプリケーションサーバ２００のＨＴＴＰ処理部２０１に対して、リソースの取得要求としてのＨＴＴＰリクエストが送信される（ステップＳ４４）。ＨＴＴＰリクエストを受信したＨＴＴＰ処理部２０１は、クライアント２−１に対して、ＨＴＴＰレスポンスを用いてリソースを送信する（ステップＳ４５）。

続いて、ＳＩＰリソースの保有者であるクライアント１−１によって、ＳＩＰリソースの更新が行われると（ステップＳ４６）、クライアント１−１からアプリケーションサーバ２００のフィード生成部２０３に対して、ＰＵＢＬＩＳＨリクエストを用いてリソース更新の通知がされる（ステップＳ４７）。フィード生成部２０３では、クライアント１−１に対して“２００ ＯＫ”の返信をするとともに（ステップＳ４８）、クライアント１−１から受信したＰＵＢＬＩＳＨリクエストを基に、フィードＦ３−２を更新してフィードＦ３−３とする（ステップＳ４９）。生成されたフィードＦ２は、フィード配信部２０４に送信される（ステップＳ５０）。

フィード配信部２０４では、フィードＦ３−３を受信すると、その内容をＮＯＴＩＦＹリクエストのボディに含めてクライアント２−１に送信する（ステップＳ５１）。そして、ＮＯＴＩＦＹリクエストを受信したクライアント２−１から、“２００ ＯＫ”のレスポンスが返される（ステップＳ５２）。

図１４（ｂ）には、フィードＦ３−３の記述例を示してある。フィードＦ３−３において、要素Ｅ１８、Ｅ１９と示した部分は、それぞれフィードＦ３−２（図１４（ａ）参照）の要素Ｅ１４とＥ１５に対応している。つまり、前回配信されたフィードの中に記載されていた各ニュースの更新情報が、そのまま記載されている。そして、要素Ｅ１７として示された部分に、最新の更新情報が記載されている。

要素Ｅ１７には、＜title＞のタグで囲まれた箇所に“A piece of news about business”というタイトルのニュースの更新情報が記載されており、その更新日時は、＜putDate＞タグで囲まれた部分に示されるように、“Sun, 10 Jun2007 12:30:00”であることが示されている。この日時は、フィード作成日時（要素Ｅ１７の＜updated＞）と同じである。つまり、“A piece of news about business”というタイトルのニュースが更新されたタイミングで、フィードが生成されたことが分かる。

また要素Ｅ１７には、＜link＞タグで囲まれた箇所に
“sip:news-business-20070610123000@sip.app.server.example”とあるように、ＳＩＰリソースの保存場所情報が記載されている。つまり、クライアント１−１によって更新されたのは、“sip:news-business-20070610123000@sip.app.server.example”に保存されたＳＩＰリソースで構成される、“A piece of news about business”というニュースであったことが分かる。

フィードを受信したクライアント２−１のユーザが、フィードＦ３−３の要素Ｅ１７に記載されたＳＩＰリソースを選択した場合には、図１３のステップＳ５３で、クライアント２−１からリソース保有者であるクライアント１−１に対して、ＩＮＶＩＴＥリクエストを用いたセッションの確立要求が送信される。ＩＮＶＩＴＥリクエストを受信したクライアント１−１において、要求が受け入れられた場合には、クライアント１−１からクライアント２−１に対して“２００ ＯＫ”のレスポンスが返される（ステップＳ５４）。そして、クライアント１−１と２−１との間でメディアセッションが確立される（ステップＳ５５）。クライアント２−１は、メディアセッションの確立後に行われるリアルタイム通信を通して、コンテンツを取得する。

この段階で、クライアント２−２からアプリケーションサーバ２００に対して、ニュースに関するフィードの購読要求がＳＵＢＳＣＲＩＢＥリクエストを用いて送信されると（ステップＳ５６）、アプリケーションサーバ２００のフィード配信部２０４からクライアント２−２に対して、“２００ ＯＫ”のレスポンスが返される（ステップＳ５７）。そして、クライアント２−２が配信を希望するニュースにおける、この時点で最新のフィードはフィードＦ３−３であるため、フィード配信部２０４からクライアント２−２に対して、フィードＦ３−３がＮＯＴＩＦＹリクエストを用いて配信される（ステップＳ５８）。そして、フィードＦ３−３を受信したクライアント２−２からフィード配信部２０４に対して、“２００ ＯＫ”のレスポンスが返される（ステップＳ５９）。

クライアント２−２において、フィードＦ３−３（図１４（ｂ）参照）の要素Ｅ１７に記載のＳＩＰリソースが選択された場合には、ＳＩＰリソース保有者であるクライアント１−１との間でＳＩＰのセッションが確立され（ステップＳ６０）、このセッションを通して、クライアント２−２はリソース（この場合はニュース）の取得を行う。

クライアント２−２において、フィードＦ３−３（図１４（ｂ）参照）の要素Ｅ１８に記載のＷｅｂリソースが選択された場合には、クライアント２−２とアプリケーションサーバ２００のＨＴＴＰ処理部２０１との間でＨＴＴＰ（Ｗｅｂ）のセッションが確立され（ステップＳ６１）、このセッションを通して、クライアント２−２はリソースの取得を行う。

上述した実施の形態の構成及び処理によれば、第１の実施の形態と第２の実施の形態における効果に加えて、さらに以下の効果を得ることができる。例えば、上述した第３の実施の形態の構成及び処理によると、１つのニュースを構成する複数のリソースが、ＳＩＰ ＵＲＩとＷｅｂ ＵＲＬのように異なる形態で管理されている場合であっても、それらの更新情報が１つのフィードにまとめられてクライアントに配信されるようになる。よって、クライアントは、リソースの保管場所の違いを意識することなくリソースを取得することができるようになる。

＜第３の実施の形態＞
次に、図１５〜図１７を参照して、本発明の第３の実施の形態について説明する。本実施の形態では、第２の実施例と同様に、ニュースの更新情報をフィードとして配信する形態に適用してあるが、ニュースを構成するテキストデータや画像データが、すべてＷｅｂサーバで管理されている場合に適用してある。

図１５において、Ｗｅｂサーバ３００とＳＩＰサーバ１００′とクライアント１−１とクライアント２−１は、互いにネットワーク５を介して接続されている。クライアント１−１のユーザはＷｅｂリソースの保有者であり、クライアント２−１のユーザは、リソース保有者が生成又は更新したニュースを購読するユーザである。

Ｗｅｂサーバ３００は、ＨＴＴＰ処理部３０１とＤＢ３０２とフィード生成部３０３とで構成され、ＳＩＰサーバ１００′は、フィード配信部１０２′とロケーション管理部１０３′とで構成される。本例におけるシステムの構成の特徴は、フィードの生成はＷｅｂサーバ３００側で行い、生成されたフィードの配信はＳＩＰサーバ１００′側で行う点にある。ＨＴＴＰ処理部３０１とＤＢ３０２とフィード生成部３０３は、それぞれ図１０のＨＴＴＰ処理部２０１、ＤＢ２０２、フィード生成部２０３と同様の処理を行うものであり、説明は省略する。フィード配信部１０２′とロケーション管理部１０３′も、それぞれ図１のフィード配信部１０２とロケーション管理部１０３、図１０のフィード配信部２０４とロケーション管理部２０５と同様の処理を行うものであるため、説明は省略する。また、Ｗｅｂサーバ３００とＳＩＰサーバ１００′の内部構成は、図２に記載のものと同様であり、クライアント１−１と２−１の内部構成は、図３に記載のものと同様であるため、説明を省略する。

次に、図１６を参照して、クライアント２−１からＳＩＰサーバ１００′にフィードの購読要求が出されてから、リソースの更新情報を含むフィードがクライアント２−１に送信され、その情報を基に、クライアント２−１において実際にリソースが取得されるまでの処理の例について説明する。

まず、クライアント２−１からＳＩＰサーバ１００′のフィード配信部１０２′に対して、ＳＵＢＳＣＲＩＢＥリクエストを用いてフィードの購読要求が送信されると（ステップＳ７１）、フィード配信部１０２′からクライアント２−１に対して、“２００ ＯＫ”のレスポンスが返される（ステップＳ７２）。次のステップＳ７３では、フィード配信部１０２′からクライアント２−１に対して、この時点での最新の更新情報が記載されたフィードがＮＯＴＩＦＹメッセージを用いて配信される。そして、ＮＯＴＩＦＹリクエストを受信したクライアント２−１からフィード配信部１０２′に対して、“２００ ＯＫ”のレスポンスが返される（ステップＳ７４）。

ここで、Ｗｅｂリソースの保持者であるクライアント１−３において、Ｗｅｂリソースで構成されるニュースが更新されると（ステップＳ７５）、そのニュースが、ＨＴＴＰのＰＯＳＴコマンドを用いて、Ｗｅｂサーバ３００のＨＴＴＰ処理部３０１に送信される（ステップＳ７６）。ここで、図示はしていないが、ＨＴＴＰ処理部３０１によって、ＰＯＳＴコマンドに添付されたリソースがＤＢ３０２の所定の場所に保存される。そして次のステップＳ７７で、ＨＴＴＰ処理部３０１からクライアント１−１に対して、“２００ ＯＫ”のレスポンスが返される。

フィード生成部３０３は、ステップＳ７６でＨＴＴＰ処理部３０１が受信したＰＯＳＴコマンドに記載の内容を元にフィードを更新し、フィードＦ４を生成する。（ステップＳ７８）、生成したフィードＦ４は、ＤＢ３０２（図１５参照）の所定の場所等に記憶させるようにし、次のステップＳ７９で、フィードＦ４の保存場所情報を含めたフィードの更新情報を、ＳＩＰサーバ１００′のフィード配信部１０２′に送信する。フィード配信部１０２′は、受信したフィードの更新情報を基にＤＢ３０２からフィードＦ４を取得すると（ステップＳ８０）、取得したフィードＦ４を、ＮＯＴＩＦＹリクエストのボディ部分に含めて、クライアント２−１に送信する（ステップＳ８１）。そして、ＮＯＴＩＦＹリクエストを受信したクライアント２−１からフィード配信部１０２′に対して、“２００ ＯＫ”のレスポンスが返される（ステップＳ８２）。

図１７に、フィードＦ４の記述例を示してある。要素Ｅ２０と示した部分には、フィードのタイトル（“The Latest News”）や、フィードのＩＤ（http://www.news.com.example）、フィードの更新日時（Sun, 10 Jun2007 12:30:00）、フィードのサブタイトル（“News Headlines”が記載されている。そして、要素Ｅ２１〜Ｅ２３として示した＜entry＞で囲まれたボディの部分に、各ニュースの更新情報を記載してある。＜pubDate＞として示された各ニュースの更新日時は、最下段の要素Ｅ２３が一番古く、続いて要素Ｅ２２、要素Ｅ２１の順に新しくなっている。

つまり、要素Ｅ２１に記載されたニュースの更新日時が一番新しく、＜putDate＞タグで囲まれた部分に示されるように、“Sun, 10 Jun2007 12:30:00”であることが示されている。この日時は、フィード作成日時（要素Ｅ２０の＜updated＞）と同じであり、要素Ｅ２１に記載されたニュースが、クライアント１−１によって更新されたタイミングで、フィードＦ４が生成されたことが分かる。

また要素Ｅ２１〜Ｅ２３には、＜link＞タグで囲まれた箇所にリソースの保存場所情報を記載してある。例えば要素Ｅ２１には、
“http://www.news.com/business/2007061012300.html”のように記載されている。

フィードを受信したクライアント２−１のユーザが、フィードＦ４の要素Ｅ２１に記載されたＷｅｂリソースを選択した場合には、図１６のステップＳ８３で、クライアント２−１からＷｅｂサーバ３００のＨＴＴＰ処理部３０１に対して、ＨＴＴＰリクエストが送信される。そして、ＨＴＴＰリクエストを受信したＨＴＴＰ処理部３０１は、クライアント２−１に対して、ＨＴＴＰレスポンスを用いてリソースを送信する（ステップＳ８４）。

上述した実施の形態の構成及び処理によれば、Ｗｅｂサーバで管理されるリソースの情報であっても、ＳＩＰのＮＯＴＩＦＹリクエストによってその更新情報がクライアントに配信されるようになるため、ユーザが、リソースの更新情報等をリアルタイムで取得することができるようになる。

なお、上述した実施の形態では、フィード生成部２０３からフィード配信部１０２′に対して、フィードの更新情報を通知する構成としたが、フィード配信部１０２′がフィードファイルの生成時刻を常に監視し、更新があったと判断した場合にフィードファイルを取得する構成に適用してもよい。

また、上述した本発明の第１〜第３の実施の形態では、フィード生成部とフィード配信部とを別々の構成としたが、統合するようにしてもよい。つまり、フィード生成部とフィード配信部とを、同一プロセスのマルチスレッドという形態や、それぞれ異なるプロセスとして形成してもよい。

同一プロセスのマルチスレッドとして構成した場合には、フィード生成部とフィード配信部とでメモリを共有することができる。よって、フィード生成部が生成したフィードをメモリに保存するようにすれば、フィード生成部とフィード配信部との間でフィードの受け渡し（例えば、図４のステップＳ９）を行う必要がなくなる。また、異なるプロセスで実現する場合にも、フィード生成部が使用するメモリに記憶させた内容を、フィード配信部が使用するメモリにコピーすることができるため、マルチスレッドで実現時と同様に、フィードの受け渡し処理を行う必要がなくなる。

本発明の第１の実施の形態によるシステムの構成例を示す説明図である。 本発明の第１の実施の形態によるＳＩＰサーバの内部構成例を示すブロック図である。 本発明の第１の実施の形態によるクライアントの内部構成例を示すブロック図である。 本発明の第１の実施の形態によるフィードの購読要求が行われてからリソースが取得されるまでの処理の例を示すシーケンス図である。 本発明の第１の実施の形態によるＳＩＰメッセージの記述例を示す説明図であり、（ａ）は、ＳＵＢＳＣＲＩＢＥメッセージの記述例を示し、（ｂ）はＮＯＴＩＦＹメッセージの記述例を示す。 本発明の第１の実施の形態によるフィードの記述例を示す説明図である。 本発明の第１の実施の形態によるフィードの記述例を示す説明図である。 本発明の第１の実施の形態によるリソース更新情報の表示例を示す説明図である。 本発明の第１の実施の形態の他の形態によるフィードの記述例を示す説明図である。 本発明の第２の実施の形態によるシステムの構成例を示す説明図である。 本発明の第２の実施の形態によるフィードの購読要求が行われてからリソースが取得されるまでの処理の例を示すシーケンス図である。 本発明の第２の実施の形態によるフィードの記述例を示す説明図である。 本発明の第２の実施の形態によるフィードの購読要求が行われてからリソースが取得されるまでの処理の例を示すシーケンス図である。 本発明の第２の実施の形態によるフィードの記述例を示す説明図である。 本発明の第３の実施の形態によるシステムの構成例を示す説明図である。 本発明の第３の実施の形態によるフィードの購読要求が行われてからリソースが取得されるまでの処理の例を示すシーケンス図である。 本発明の第３の実施の形態によるフィードの記述例を示す説明図である。

符号の説明

１−１、１−２、１−３、２−１、２−２…クライアント、１２…制御部、１３…ＲＯＭ、１４…ＲＡＭ、１５…記憶部、１６…Ｉ／Ｆ部、１７…操作部、１８…Ｉ／Ｆ部、１９…マイクロフォン、２０…音声処理部、２１…音声出力部、２２…音声処理部、２３…表示部、２４…表示制御部、２５…通信部、１００…ＳＩＰサーバ、１０１…フィード生成部、１０２…フィード配信部、１０３…ロケーション管理部、１１０…制御部、１１１…ＲＯＭ、１１２…ＲＡＭ、１１３…記憶部、１１４…Ｉ／Ｆ部、１１５…操作部、１１６…Ｉ／Ｆ部、１１７…通信部、１２０…バス、２００…アプリケーションサーバ、３００…Ｗｅｂサーバ

Claims (11)

1. 端末から指定された所定のリソースに関する更新情報を前記端末に配信する情報配信装置において、
   前記端末から前記所定のリソースの更新情報の配信要求を受け付けるとともに、前記所定のリソースに関する更新情報を前記端末に配信する配信部と、
   前記所定のリソースの更新を検知して前記リソースの更新情報を生成し、生成した更新情報を前記配信部に出力する更新情報生成部とを備え、
   前記配信部は、前記更新情報生成部から出力された前記更新情報を取得した時点で前記取得した更新情報を前記端末に配信することを特徴とする
   情報配信装置。
2. 請求項１記載の情報配信装置において、
   前記更新情報生成部は、更新を検知した前記所定のリソースの更新情報をフィードに記述することを特徴とする
   情報配信装置。
3. 請求項２記載の情報配信装置において、
   前記配信部は、ＳＩＰのメソッドを用いて前記端末に前記フィードを配信することを特徴とする
   情報配信装置。
4. 請求項３記載の情報配信装置において、
   前記配信部は、ＳＵＢＳＣＲＩＢＥリクエストを用いて配信要求を送信してきた前記端末に対して、前記フィードを、ＮＯＴＩＦＹリクエストに含めて配信することを特徴とする
   情報配信装置。
5. 請求項４記載の情報配信装置において、
   前記更新情報生成部は、前記端末から送信されたＳＵＢＳＣＲＩＢＥリクエストの中で指定されたリソースの更新を、検知することを特徴とする
   情報配信装置。
6. 請求項５記載の情報配信装置において、
   前記リソースの保存場所は、ＵＲＩで管理されることを特徴とする
   情報配信装置。
7. 請求項２記載の情報配信装置において、
   前記更新情報生成部は、前記フィードに前記所定のリソースの属性情報を記載することを特徴とする
   情報配信装置。
8. 請求項７記載の情報配信装置において、
   前記リソースの属性情報には、前記リソースの保存場所情報が含まれることを特徴とする
   情報配信装置。
9. 請求項４記載の情報配信装置において、
   前記配信部は、前記ＮＯＴＩＦＹリクエストのヘッダ部分のイベントフィールドで、イベントの種類としてフィードを指定し、前記ＮＯＴＩＦＹリクエストのボディ部分に前記フィードを含めることを特徴とする
   情報配信装置。
10. 端末から指定された所定のリソースに関する更新情報を前記端末に配信する情報配信装置における情報配信方法において、
    前記端末から前記所定のリソースに関する更新情報の配信要求を受け付ける手順と、
    前記所定のリソースの更新を検知して前記所定のリソースに関する更新情報を生成する手順と、
    前記生成した更新情報を前記端末に配信する手順とを備えたことを特徴とする
    情報配信方法。
11. 端末から指定された所定のリソースに関する更新情報を前記端末に配信する情報配信装置と、前記端末で構成される情報配信システムにおいて、
    前記端末は、
    前記情報配信装置に対して前記所定のリソースに関する更新情報の配信要求を送信するとともに、前記情報配信装置から送信された更新情報を受信する通信部を備え、
    前記情報配信装置は、
    前記端末から、前記所定のリソースの更新情報の配信要求を受け付けるとともに、前記所定のリソースに関する更新情報を前記端末に配信する配信部と、
    前記所定のリソースの更新を検知して前記リソースの更新情報を生成し、生成した更新情報を前記配信部に出力する更新情報生成部とを備え、
    前記情報配信装置の配信部は、前記更新情報生成部から出力された前記更新情報を取得した時点で前記取得した更新情報を前記端末に配信し、
    前記端末は、前記通信部を通して受信した前記リソースの保存場所情報を基に、前記リソースを取得することを備えたことを特徴とする
    情報配信システム。

Images