(57)【特許請求の範囲】
【請求項１】
サービスごとに、コンテンツもしくはコンテンツのメタデータの更新情報もしくはこの更新情報への参照が格納された更新報知メッセージを生成する更新報知メッセージ生成手段と、
前記サービスごとの更新報知メッセージ生成手段より引き渡された前記更新報知メッセージにこのメッセージを分類するフィルタ属性を設定するフィルタ属性設定手段と、
前記フィルタ属性設定手段により前記フィルタ属性が設定された前記更新報知メッセージを蓄積する更新報知メッセージ蓄積部と、
ホームネットワーク上の機器に設けられ、特定のサービスの前記コンテンツもしくは前記メタデータを格納するローカルコンテンツ／メタデータ格納部と、
前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記更新情報を用いて更新する、前記特定のサービスに対応するアプリケーションによって実現される更新手段と、
予め前記アプリケーションと前記フィルタ属性との対応関係を管理し、前記更新報知メッセージ蓄積部よりネットワークを介して取得した前記更新報知メッセージに設定された前記フィルタ属性と前記対応関係とをもとに、前記更新報知メッセージ内の更新情報を提供するアプリケーションを特定し、このアプリケーションを起動して前記更新情報を提供する更新情報提供手段と
を具備することを特徴とするネットワークシステム。
【請求項２】
請求項１に記載のネットワークシステムであって、
前記フィルタ属性は、前記サービスを特定する情報であることを特徴とするネットワークシステム。
【請求項３】
請求項１に記載のネットワークシステムであって、
前記フィルタ属性は、前記コンテンツのカテゴリを特定する情報であることを特徴とするネットワークシステム。
【請求項４】
請求項１に記載のネットワークシステムであって、
前記更新報知メッセージ生成手段は、前記更新情報として、前記コンテンツもしくは前記メタデータの全体の更新内容である全体更新情報と、更新による差分のみの更新内容である差分更新情報とを定期的に切り替えて生成し、この更新報知メッセージごとの前記更新情報の更新方法を示す属性情報を前記更新報知メッセージに設定し、
前記更新情報提供手段は、前記更新報知メッセージ蓄積部に蓄積された前記更新報知メッセージに設定された前記属性情報をもとに、前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記サービスの提供者側の前記コンテンツもしくは前記メタデータと同期させるために必要な前記更新報知メッセージを前記更新報知メッセージ蓄積部から前記ネットワークを介して取得することを特徴とするネットワークシステム。
【請求項５】
請求項１に記載のネットワークシステムであって、
前記更新報知メッセージには前記更新情報として前記コンテンツもしくは前記メタデータの更新情報が格納され、
前記更新情報提供手段によって前記更新報知メッセージ蓄積部よりネットワークを介して取得した前記更新報知メッセージを蓄積する第２の更新報知メッセージ蓄積部をさらに有し、
前記更新情報提供手段は、前記第２の更新報知メッセージ蓄積部から前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記サービスの提供者側の前記コンテンツもしくは前記メタデータと同期させるために必要な前記更新報知メッセージを取得することを特徴とするネットワークシステム。
【請求項６】
コンテンツもしくはコンテンツのメタデータの更新情報もしくはこの更新情報への参照が格納された更新報知メッセージであって、この更新報知メッセージを分類するフィルタ属性が設定された更新報知メッセージを蓄積する更新報知メッセージ蓄積部からネットワークを介して前記更新報知メッセージを取得可能なネットワーク家電機器であって、
特定のサービスのコンテンツもしくはコンテンツのメタデータを格納するローカルコンテンツ／メタデータ格納部と、
前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記更新情報を用いて更新する、前記特定のサービスに対応するアプリケーションによって実現される更新手段と、
予め前記アプリケーションと前記フィルタ属性との対応関係を管理し、前記更新報知メッセージ蓄積部より前記ネットワークを介して取得した前記更新報知メッセージに設定された前記フィルタ属性と前記対応関係とをもとに、前記更新報知メッセージ内の更新情報を提供するアプリケーションを特定し、このアプリケーションを起動して前記更新情報を提供する更新情報提供手段と
を具備することを特徴とするネットワーク家電機器。
【請求項７】
請求項６に記載のネットワーク家電機器であって、
前記フィルタ属性は、前記サービスを特定する情報であることを特徴とするネットワーク家電機器。
【請求項８】
請求項６に記載のネットワーク家電機器であって、
前記フィルタ属性は、前記コンテンツのカテゴリを特定する情報であることを特徴とするネットワーク家電機器。
【請求項９】
請求項６に記載のネットワーク家電機器であって、
前記更新報知メッセージには、前記更新情報として、前記コンテンツもしくは前記メタデータの全体の更新内容である全体更新情報と、更新による差分のみの更新内容である差分更新情報とが定期的に切り替えて格納され、かつ、この更新報知メッセージごとの前記更新情報の更新方法を示す属性情報が前記更新報知メッセージに設定され、
前記更新情報提供手段は、前記更新報知メッセージ蓄積部に蓄積された前記更新報知メッセージに設定された前記属性情報をもとに、前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記サービスの提供者側の前記コンテンツもしくは前記メタデータと同期させるために必要な前記更新報知メッセージを前記更新報知メッセージ蓄積部から前記ネットワークを介して取得することを特徴とするネットワーク家電機器。
【請求項１０】
請求項６に記載のネットワーク家電機器であって、
前記更新報知メッセージには前記更新情報として前記コンテンツもしくは前記メタデータの更新情報が格納され、
前記更新情報提供手段によって前記更新報知メッセージ蓄積部より前記ネットワークを介して取得した前記更新報知メッセージを蓄積する第２の更新報知メッセージ蓄積部をさらに有し、
前記更新情報提供手段は、前記第２の更新報知メッセージ蓄積部から前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記サービスの提供者側の前記コンテンツもしくは前記メタデータと同期させるために必要な前記更新報知メッセージを取得することを特徴とするネットワーク家電機器。
【請求項１１】
更新報知メッセージ生成手段により、サービスごとに、コンテンツもしくはコンテンツのメタデータの更新情報もしくはこの更新情報への参照が格納された更新報知メッセージを生成するステップと、
フィルタ属性設定手段により、前記サービスごとの更新報知メッセージ生成手段より引き渡された前記更新報知メッセージにこのメッセージを分類するフィルタ属性を設定するステップと、
前記フィルタ属性が設定された前記更新報知メッセージを更新報知メッセージ蓄積部に蓄積するステップと、
ホームネットワーク上の機器に設けられ、特定のサービスの前記コンテンツもしくは前記メタデータを格納するローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを、前記特定のサービスに対応するアプリケーションによって実現される更新手段により、前記更新情報を用いて更新するステップと、
更新情報提供手段により、予め前記アプリケーションと前記フィルタ属性との対応関係を管理しておき、前記更新報知メッセージ蓄積部よりネットワークを介して取得した前記更新報知メッセージに設定された前記フィルタ属性と前記対応関係とをもとに、前記更新報知メッセージ内の更新情報を提供するアプリケーションを特定し、このアプリケーションを起動して前記更新情報を提供するステップと
を具備することを特徴とするコンテンツ／メタデータの同期処理方法。
【請求項１２】
コンピュータを、コンテンツもしくはコンテンツのメタデータの更新情報もしくはこの更新情報への参照が格納された更新報知メッセージであって、この更新報知メッセージを分類するフィルタ属性が設定された更新報知メッセージを蓄積する更新報知メッセージ蓄積部からネットワークを介して前記更新報知メッセージを取得可能なネットワーク家電機器として動作させるコンピュータ・プログラムであって、
特定のサービスのコンテンツもしくはコンテンツのメタデータを格納するローカルコンテンツ／メタデータ格納部と、
前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記更新情報を用いて更新する、前記特定のサービスに対応するアプリケーションによって実現される更新手段と、
予め前記アプリケーションと前記フィルタ属性との対応関係を管理し、前記更新報知メッセージ蓄積部より前記ネットワークを介して取得した前記更新報知メッセージに設定された前記フィルタ属性と前記対応関係とをもとに、前記更新報知メッセージ内の更新情報を提供するアプリケーションを特定し、このアプリケーションを起動して前記更新情報を提供する更新情報提供手段と
を具備することを特徴とするコンピュータ・プログラム。
【請求項１３】
請求項１に記載のネットワークシステムであって、
前記メタデータの更新情報が、前記メタデータの要素を単位とする更新に関する情報であることを特徴とするネットワークシステム。
【請求項１４】
請求項１に記載のネットワークシステムであって、
前記メタデータの更新情報が、フラグメント単位のメタデータであることを特徴とするネットワークシステム。
【請求項１５】
請求項１４に記載のネットワークシステムであって、
前記フラグメント単位のメタデータが、TV-ＡnytimeのServiceInformationメタデータであり、階層関係を有する上位のフラグメントのメタデータと下位のフラグメントのメタデータで構成され、前記下位のフラグメントのメタデータは、上位のメタデータへの参照を定義するための要素を含むことを特徴とするネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークシステム、ネットワーク家電機器、コンテンツ／メタデータの同期処理方法、及びコンピュータ・プログラムに関する。
【背景技術】
【０００２】
放送サービス、IPTV（Internet Protocol Television）サービスや、DVD（DVD:Digital Versatile Disc）、BD（Blu-ray Disc）、HDDVD（High Definition DVD）等のパッケージ配信サービス等の複数のサービスを受けるホームネットワーク機器（単体もしくは複数）においては、これら複数のメディア、ネットワークにまたがって配信されるコンテンツもしくはコンテンツのメタデータがそれぞれのメディアに依存したプロトコルで配信される。また、メディア、サービスに依存したプロトコルにて配信されたコンテンツやそのメタデータが更新されるようなとき、それぞれのプロトコルが更新機能をサポートしている場合には、そのプロトコル依存の方式で更新処理が行われる。したがって、プロバイダ側でコンテンツやメタデータの更新が起こったときに、これらの更新事象を検知できるアプリケーションがクライアント側で起動されていれば、更新の検知と更新処理を行うことができる。
【０００３】
特許文献１には、コンテンツ及びこのコンテンツのメタデータを提供するコンテンツ配信サーバに対して、利用者端末が、メタデータの更新があった否かを定期的にポーリングして、メタデータの更新があった場合には、更新後のメタデータをコンテンツ配信サーバに要求して取得する技術が開示されている。
【特許文献１】特開２００６−０５３６３３号公報（段落００８３）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
放送通信融合環境が進展するにつれて、このような複数メディア、ネットワークを経由して配信されるコンテンツやメタデータが、ホームネットワーク内のデバイスに蓄積される機会は増大の一途にある。同じ内容のコンテンツやメタデータが、異なる複数のメディアやネットワーク／サービスを介して、ホームネットワークに蓄積されるような場合、それらのどれか一つについて更新が起こった場合に、異なる他のメディア、ネットワーク／サービスを介して配信、蓄積された同じ内容のコンテンツやメタデータについても同様な更新が起こっている可能性がある。
【０００５】
異なるメディア、ネットワーク／サービス毎のドメインで管理されるコンテンツやメタデータの識別子の間で、相互の対応関係（同一もしくは類似内容であることが判断できる対応関係）を解決できる機構があると、一方のコンテンツやメタデータの更新により、それと対応関係にある他のコンテンツやメタデータの更新事象を検知（類推）することができ、検知された場合には、更新プロトコル（配信プロトコル）による処理を行うことができる。ただ、一般に、異なるメディア、ネットワーク／サービスの間で、それぞれのドメインで管理されているコンテンツやメタデータの対応関係を解決できる識別子管理体系が保証されていることはなく、このような同期管理が自動化されることは期待できない。
【０００６】
同期管理の不整合が問題となる例として、例えば、図２８にサービスプロバイダ−Ａから提供された暗号化されたコンテンツ−αについてのメタデータ−１があり、その中に価格の情報があるとものとする。同様に、サービスプロバイダ−Ｂから提供される暗号化されたコンテンツ−βについてのメタデータ−２があり、その中にも価格情報があるとものとする。コンテンツ−αとコンテンツ−βは、同じタイトルＸのコンテンツである。サービスプロバイダ−Ａからの提供価格は、サービスプロバイダ−Ｂからの提供価格よりも高いこととする。つまり、「メタデータ−１の価格情報の値＞メタデータ−２の価格情報の値」の関係があるものとする。
【０００７】
通常、ホームネットワーク内での検索処理のパフォーマンスを上げるため、ホームネットワーク内にダウンロードされて蓄積されたコンテンツを管理するデータベースに、それぞれのメタデータの内容を格納する。ここで、あるとき（封切期間が終了する時等）、サービスプロバイダ−Ａとサービスプロバイダ−Ｂで、それぞれの価格戦略の変更で、どちらのプロバイダもこのタイトルＸの価格を下げるものとする。サービスプロバイダ−Ａやサービスプロバイダ−Ｂは、それぞれが管理するメタデータ−１やメタデータ−２の価格の内容を更新する。新しい価格は、サービスプロバイダ−Ａからの提供価格の方が、サービスプロバイダ−Ｂからの提供価格よりも安くなるとする。つまり、「メタデータ−１の価格情報の値 < メタデータ−２の価格情報の値」の関係に変化したとする。
【０００８】
ホームネットワーク内のとあるデバイスで、たまたま、サービスプロバイダ−Ｂの配信アプリケーションが稼動しており、メタデータ−２の価格情報の更新が検知されるが、サービスプロバイダ−Ａの配信アプリケーションについては起動されずに、データベースの内容のうち、メタデータ−２に対応する内容だけが更新されるものとする。この状態で、このホームネットワーク内のとあるデバイスで、コンテンツ購入ナビゲーションのアプリケーションが起動され、データベースを照会して、このタイトルＸの視聴ライセンス取得における各サービスプロバイダからの提供価格を比較する処理が実行されると、メタデータ−１の価格が更新されていないため、「メタデータ−１の価格情報の値 > メタデータ−２の価格情報の値」となり、ユーザは、サービスプロバイダ−Ｂからのコンテンツを視聴するライセンスを購入してしまい、サービスプロバイダ−Ａは商機を逸し、ユーザは安い方を購入する機会を失う。
【０００９】
以上のような問題を鑑みて、本発明は、コンテンツやメタデータの更新内容をホームネットワーク内のネットワーク家電機器に確実に通知して同期処理を効率良く行うことのできるネットワークシステム、ネットワーク家電機器、コンテンツ／メタデータの同期処理方法、及びコンピュータ・プログラムを提供しようとするものである。
【課題を解決するための手段】
【００１０】
上記の課題を解決するために、本発明のネットワークシステムは、サービスごとに、コンテンツもしくはコンテンツのメタデータの更新情報もしくはこの更新情報への参照が格納された更新報知メッセージを生成する更新報知メッセージ生成手段と、前記サービスごとの更新報知メッセージ生成手段より引き渡された前記更新報知メッセージにこのメッセージを分類するフィルタ属性を設定するフィルタ属性設定手段と、前記フィルタ属性設定手段により前記フィルタ属性が設定された前記更新報知メッセージを蓄積する更新報知メッセージ蓄積部と、ホームネットワーク上の機器に設けられ、特定のサービスの前記コンテンツもしくは前記メタデータを格納するローカルコンテンツ／メタデータ格納部と、前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記更新情報を用いて更新する、前記特定のサービスに対応するアプリケーションによって実現される更新手段と、予め前記アプリケーションと前記フィルタ属性との対応関係を管理し、前記更新報知メッセージ蓄積部よりネットワークを介して取得した前記更新報知メッセージに設定された前記フィルタ属性と前記対応関係とをもとに、前記更新報知メッセージ内の更新情報を提供するアプリケーションを特定し、このアプリケーションを起動して前記更新情報を提供する更新情報提供手段とを具備する。
【００１１】
本発明のネットワークシステムによれば、サービスに対応するアプリケーションが起動していない場合であっても、取得した更新報知メッセージに設定されたフィルタ属性と、予め設定されたアプリケーションとフィルタ属性との対応関係とをもとに、更新報知メッセージ内の更新情報を提供するアプリケーションを特定することができ、さらに、そのアプリケーションを起動させて、ローカルコンテンツ／メタデータ格納部のコンテンツもしくはメタデータを更新情報を用いて更新することができる。これにより、コンテンツやメタデータの更新内容をホームネットワーク内のネットワーク家電機器に確実に通知して同期処理を良好に行うことができる。
【００１２】
本発明のネットワークシステムにおいて、フィルタ属性は、前記サービスを特定する情報であることとする。これにより、サービスに対応するアプリケーションを効率的に特定することができる。
【００１３】
また、本発明のネットワークシステムにおいて、フィルタ属性は、前記コンテンツのカテゴリを特定する情報であることとしてもよい。これにより、コンテンツのカテゴリごとに、対応するアプリケーションを効率的に特定して起動させることができる。
【００１４】
さらに、本発明のネットワークシステムにおいて、前記更新報知メッセージ生成手段は、前記更新情報として、前記コンテンツもしくは前記メタデータの全体の更新内容である全体更新情報と、更新による差分のみの更新内容である差分更新情報とを定期的に切り替えて生成し、この更新報知メッセージごとの前記更新情報の更新方法を示す属性情報を前記更新報知メッセージに設定し、前記更新情報提供手段は、前記更新報知メッセージ蓄積部に蓄積された前記更新報知メッセージに設定された前記属性情報をもとに、前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記サービスの提供者側の前記コンテンツもしくは前記メタデータと同期させるために必要な前記更新報知メッセージを前記更新報知メッセージ蓄積部から前記ネットワークを介して取得することとしてもよい。このように全体更新と差分更新を併用したことによって、更新処理を効率良くことが可能になるとともに、万が一、更新情報の取りこぼしが発生した場合であっても、効率良く回復処理を行うことができる。
【００１５】
また、本発明のネットワークシステムにおいて、前記更新報知メッセージには前記更新情報として前記コンテンツもしくは前記メタデータの更新情報が格納され、前記更新情報提供手段によって前記更新報知メッセージ蓄積部よりネットワークを介して取得した前記更新報知メッセージを蓄積する第２の更新報知メッセージ蓄積部をさらに有し、前記更新情報提供手段は、前記第２の更新報知メッセージ蓄積部から前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記サービスの提供者側の前記コンテンツもしくは前記メタデータと同期させるために必要な前記更新報知メッセージを取得することとしてもよい。このような構成により、ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータの、前記サービスの提供者側の前記コンテンツもしくは前記メタデータとの同期を回復するために、ネットワークを介して更新報知メッセージを取得する必要がなくなり、効率良く同期処理を行うことができる。
【００１６】
本発明の別の観点に基づくネットワーク家電機器は、コンテンツもしくはコンテンツのメタデータの更新情報もしくはこの更新情報への参照が格納された更新報知メッセージであって、この更新報知メッセージを分類するフィルタ属性が設定された更新報知メッセージを蓄積する更新報知メッセージ蓄積部からネットワークを介して前記更新報知メッセージを取得可能なネットワーク家電機器であって、特定のサービスのコンテンツもしくはコンテンツのメタデータを格納するローカルコンテンツ／メタデータ格納部と、前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記更新情報を用いて更新する、前記特定のサービスに対応するアプリケーションによって実現される更新手段と、予め前記アプリケーションと前記フィルタ属性との対応関係を管理し、前記更新報知メッセージ蓄積部より前記ネットワークを介して取得した前記更新報知メッセージに設定された前記フィルタ属性と前記対応関係とをもとに、前記更新報知メッセージ内の更新情報を提供するアプリケーションを特定し、このアプリケーションを起動して前記更新情報を提供する更新情報提供手段とを具備する。
【００１７】
本発明のネットワーク家電機器によれば、サービスに対応するアプリケーションが起動していない場合であっても、取得した更新報知メッセージに設定されたフィルタ属性と、予め設定されたアプリケーションとフィルタ属性との対応関係とをもとに、更新報知メッセージ内の更新情報を提供するアプリケーションを特定することができ、さらに、そのアプリケーションを起動させて、ローカルコンテンツ／メタデータ格納部のコンテンツもしくはメタデータを更新情報を用いて更新することができる。これにより、コンテンツやメタデータの更新内容をホームネットワーク内のネットワーク家電機器に確実に通知して同期処理を良好に行うことができる。
【００１８】
本発明のネットワーク家電機器において、フィルタ属性は、前記サービスを特定する情報であることとする。これにより、サービスに対応するアプリケーションを効率的に特定することができる。
【００１９】
また、本発明のネットワーク家電機器において、フィルタ属性は、前記コンテンツのカテゴリを特定する情報であることとしてもよい。これにより、コンテンツのカテゴリごとに、対応するアプリケーションを効率的に特定して起動させることができる。
【００２０】
また、本発明のネットワーク家電機器において、前記更新報知メッセージには、前記更新情報として、前記コンテンツもしくは前記メタデータの全体の更新内容である全体更新情報と、更新による差分のみの更新内容である差分更新情報とが定期的に切り替えて格納され、かつ、この更新報知メッセージごとの前記更新情報の更新方法を示す属性情報が前記更新報知メッセージに設定され、前記更新情報提供手段は、前記更新報知メッセージ蓄積部に蓄積された前記更新報知メッセージに設定された前記属性情報をもとに、前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記サービスの提供者側の前記コンテンツもしくは前記メタデータと同期させるために必要な前記更新報知メッセージを前記更新報知メッセージ蓄積部から前記ネットワークを介して取得することとしてもよい。このように全体更新と差分更新を併用したことによって、更新処理を効率良くことが可能になるとともに、万が一、更新情報の取りこぼしが発生した場合であっても、効率良く回復処理を行うことができる。
【００２１】
また、本発明のネットワーク家電機器において、前記更新報知メッセージには前記更新情報として前記コンテンツもしくは前記メタデータの更新情報が格納され、前記更新情報提供手段によって前記更新報知メッセージ蓄積部より前記ネットワークを介して取得した前記更新報知メッセージを蓄積する第２の更新報知メッセージ蓄積部をさらに有し、前記更新情報提供手段は、前記第２の更新報知メッセージ蓄積部から前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記サービスの提供者側の前記コンテンツもしくは前記メタデータと同期させるために必要な前記更新報知メッセージを取得することとしてもよい。このような構成により、ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータの、前記サービスの提供者側の前記コンテンツもしくは前記メタデータとの同期を回復するために、ネットワークを介して更新報知メッセージを取得する必要がなくなり、効率良く同期処理を行うことができる。
【００２２】
本発明の別の観点に基づくコンテンツ／メタデータの同期処理方法は、更新報知メッセージ生成手段により、サービスごとに、コンテンツもしくはコンテンツのメタデータの更新情報もしくはこの更新情報への参照が格納された更新報知メッセージを生成するステップと、フィルタ属性設定手段により、前記サービスごとの更新報知メッセージ生成手段より引き渡された前記更新報知メッセージにこのメッセージを分類するフィルタ属性を設定するステップと、前記フィルタ属性が設定された前記更新報知メッセージを更新報知メッセージ蓄積部に蓄積するステップと、ホームネットワーク上の機器に設けられ、特定のサービスの前記コンテンツもしくは前記メタデータを格納するローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを、前記特定のサービスに対応するアプリケーションによって実現される更新手段により、前記更新情報を用いて更新するステップと、更新情報提供手段により、予め前記アプリケーションと前記フィルタ属性との対応関係を管理しておき、前記更新報知メッセージ蓄積部よりネットワークを介して取得した前記更新報知メッセージに設定された前記フィルタ属性と前記対応関係とをもとに、前記更新報知メッセージ内の更新情報を提供するアプリケーションを特定し、このアプリケーションを起動して前記更新情報を提供するステップとを具備する。
【００２３】
本発明のコンテンツ／メタデータの同期処理方法によれば、サービスに対応するアプリケーションが起動していない場合であっても、取得した更新報知メッセージに設定されたフィルタ属性と、予め設定されたアプリケーションとフィルタ属性との対応関係とをもとに、更新報知メッセージ内の更新情報を提供するアプリケーションを特定することができ、さらに、そのアプリケーションを起動させて、ローカルコンテンツ／メタデータ格納部のコンテンツもしくはメタデータを更新情報を用いて更新することができる。これにより、コンテンツやメタデータの更新内容をホームネットワーク内のネットワーク家電機器に確実に通知して同期処理を良好に行うことができる。
【００２４】
本発明の別の観点に基づくコンピュータ・プログラムは、コンピュータを、コンテンツもしくはコンテンツのメタデータの更新情報もしくはこの更新情報への参照が格納された更新報知メッセージであって、この更新報知メッセージを分類するフィルタ属性が設定された更新報知メッセージを蓄積する更新報知メッセージ蓄積部からネットワークを介して前記更新報知メッセージを取得可能なネットワーク家電機器として動作させるコンピュータ・プログラムであって、特定のサービスのコンテンツもしくはコンテンツのメタデータを格納するローカルコンテンツ／メタデータ格納部と、前記ローカルコンテンツ／メタデータ格納部の前記コンテンツもしくは前記メタデータを前記更新情報を用いて更新する、前記特定のサービスに対応するアプリケーションによって実現される更新手段と、予め前記アプリケーションと前記フィルタ属性との対応関係を管理し、前記更新報知メッセージ蓄積部より前記ネットワークを介して取得した前記更新報知メッセージに設定された前記フィルタ属性と前記対応関係とをもとに、前記更新報知メッセージ内の更新情報を提供するアプリケーションを特定し、このアプリケーションを起動して前記更新情報を提供する更新情報提供手段とを具備する。
【００２５】
本発明のコンピュータ・プログラムによれば、サービスに対応するアプリケーションが起動していない場合であっても、取得した更新報知メッセージに設定されたフィルタ属性と、予め設定されたアプリケーションとフィルタ属性との対応関係とをもとに、更新報知メッセージ内の更新情報を提供するアプリケーションを特定することができ、さらに、そのアプリケーションを起動させて、ローカルコンテンツ／メタデータ格納部のコンテンツもしくはメタデータを更新情報を用いて更新することができる。これにより、コンテンツやメタデータの更新内容をホームネットワーク内のネットワーク家電機器に確実に通知して同期処理を良好に行うことができる。
【発明の効果】
【００２６】
本発明によれば、コンテンツやメタデータの更新内容をホームネットワーク内のネットワーク家電機器に確実に通知して同期処理を効率良く行うことができる。
【発明を実施するための最良の形態】
【００２７】
以下、本発明の実施の形態を図面を用いて詳細に説明する。
【００２８】
［更新報知配信モデル］
図１は、本発明の実施の形態にかかるコンテンツもしくはコンテンツのメタデータの更新報知配信方式のモデルを示す図である。
【００２９】
同図に示すように、この実施形態の更新配信報知方式では、パブリッシャ１０がコンテンツもしくはコンテンツのメタデータの更新情報を格納した更新報知メッセージ１を生成し、キュー／チャネル２０に公開し、サブスクライバ３０が更新報知メッセージ１を消費する。パブリッシャ１０は、サービスプロバイダ側で稼動するエンティティであり、サブスクライバ３０はホームネットワーク側で実行されるエンティティである。サブスクライバ３０は、キュー／チャネル２０に公開された更新報知メッセージ１を取得し、ホームネットワーク内のサービスクライアントに通知することで、サービスクライアントでは、その更新報知メッセージ１に格納された更新情報を用いて、ローカルのデータベースに格納されたコンテンツもしくはコンテンツのメタデータの更新を行うことで、サービスプロバイダ側が保有するコンテンツもしくはコンテンツのメタデータに対する同期処理を行う。キュー／チャネル２０に公開された個々の更新報知メッセージ１は、このサブスクライバ３０によってサービスクライアントに通知されることをもって削除される。
【００３０】
［更新報知メッセージの構成］
更新報知メッセージ１は、XMLスキーマで定義されるフォーマットを持つ。図２は、このXMLスキーマの例である。図４４は更新報知メッセージ１のデータ構造を示す図である。以下にこのXMLスキーマにおける各要素と属性の定義を示す。
【００３１】
event:更新報知メッセージの本体、
eventCategory:更新報知メッセージの分類情報（この更新報知メッセージを取得する際のフィルタ属性）、
publisher:更新報知メッセージの発行者名、
transaction:アトミックな更新処理単位（ここに含まれる複数の更新フラグメント全体がアトミックとなる）、
transactionID:publisher内でユニークな、更新処理単位に対するシーケンス番号、
updateType:全体更新（full）か、差分更新（delta）かを示すフラグ、
updateInfo:更新フラグメント、
dateOfEvent:更新フラグメントの更新時刻（更新が起こった日時、規定値はこのメッセージの発行日時）、
validFrom:更新フラグメントが有効となる日時（更新が予定されている日時、規定値は現在日時）、
validTo:更新フラグメントが無効となる日時（次の更新が予定されている日時、規定値は無期限）、
updateUnit:フラグメント単位（更新内容の単位）、
update Detail:更新内容の詳細、
updateReference:更新内容の詳細を参照するURI（更新内容をこのメッセージに格納しない場合）。
但し、dateOfEventとvalidFromはいずれかのみが指定されるものとする。また、validFrom＜validToかつメッセージの発行日時＜validToであるものとする。
【００３２】
［フィルタの構成］
更新報知メッセージのフォーマットにおいて、eventCategory属性は、サブスクライバ３０による更新報知メッセージのフィルタリングに利用される。フィルタリングのクラスの分類は、eventCategory属性のURIで表現される。例えば、サービスプロバイダ−Ａのコンテンツ配信サービスにおけるメタデータの更新報知のクラス、コンテンツの更新報知のクラスは、それぞれ、以下のように指定できる。
【００３３】
（メタデータデータベースの場合）
eventCategory:"urn:ServiceProvider-A:contentDisributionService:metadataDatabase"
（コンテンツデータベースの場合）
eventCategory:"urn:ServiceProvider-A:contentDisributionService:contentDatabase"
【００３４】
また、後述のSNS（Social Networking Service）サイトで管理されているブログ等のコンテンツのカテゴリデータベースに格納されるカテゴリを表現する場合、例えば、以下のような表記が考えられる。
【００３５】
（SNSサイトで定義されるあるカテゴリの場合）
eventCategory:"urn:SNS-Name:category:categoryName1:categoryName2:…"
ここで、categoryName1、categoryName2には、例えば、それぞれ、"スポーツ（sport）"、"野球（baseball）"のように、カテゴリの上位概念（降順）の順に命名されるカテゴリの名前が用いられる。この場合、eventCategory属性の値は、"urn:SNS-X:category:sport:baseball:majorLeague"となる。
【００３６】
eventCategory属性は複数格納することができる。すなわち、１つの更新報知メッセージに対して複数のフィルタリングのクラスを指定することができる。
【００３７】
例えば、更新報知メッセージが、あるサービスプロバイダのコンテンツ配信サービスにおけるメタデータの更新報知であり、かつ、その内容が、図３に示すように、SNSサイト"SNS-X"のカテゴリ階層の"sport:baseball:majorLeague"に相当する内容である場合、eventCategory属性は、
<eventCategory>urn:ServiceProvider-A:contentDisributionService:metadataDatabase</eventCategory>
<eventCategory>urn:SNS-X:category:sport:baseball:majorLeague</eventCategory>
となる。
【００３８】
［全体更新と差分更新］
更新報知メッセージに含まれる更新情報は、全体更新か、差分更新かに分類される。全体更新は、更新対象のデータ全体を更新（上書き、置き換え）するもので、差分更新は、更新対象のデータの一部を更新するものである。一般に、コンテンツやメタデータのデータベースは非常に大きくなる可能性があるため、更新情報として全体更新のみとすると、メッセージ本体に格納できないばかりでなく、更新内容の参照によりアウトバンドで取得して更新処理をするとしても、毎回の更新処理に大きな負荷、オーバヘッドがかかってしまう。したがって、本実施形態の更新報知方式では、全体更新ばかりでなく、データベースのうち更新が起こった箇所のみを選択的に更新する差分更新を可能とする。全体更新（full）か差分更新（delta）かを示すフラグは、アトミックな更新処理単位であるtransaction要素の属性であるupdateTypeに指定される。このtransactionId属性は、更新報知メッセージのシーケンスを時系列に一意に識別する識別子である。サブスクライバ３０はこのtransactionIDをもとに更新事象の時系列上の順序を知ることができる。
【００３９】
パブリッシャ１０の更新対象のデータ（コンテンツもしくはメタデータ）が更新される都度、パブリッシャ１０はその更新情報を格納した更新報知メッセージを生成するが、サブスクライバ３０が一連の更新報知メッセージをすべて取りこぼしなく取得することができれば、パブリッシャ１０側のデータベースに蓄積されているコンテンツもしくはメタデータを常に正しく更新することができるが、UDP（User Datagram Protocol）パケットにて更新報知メッセージを搬送するような、高信頼なメッセージングプロトコルを利用することができない場合には、その保証は困難である。更新報知メッセージの取りこぼしはトランザクション識別子の連続性をモニタすることにより検知できるため、取りこぼしを検知する都度、取りこぼした更新報知メッセージを取得するというような、サブスクライバ３０側からの補完取得処理を併用する方式が考えられる。ただし、完全な一方向／同報型を前提とする場合にはこの補完取得処理ができないため、以下のような全体更新と差分更新を併用して更新効率を上げるようにしている。
【００４０】
図４は、この全体更新と差分更新を併用した更新処理のシーケンス図である。
同図において、上半分は差分更新のシーケンス、下半分は全体更新のシーケンスの例を示している。水平方向の各区間は、パブリッシャ１０側で更新報知メッセージが生成されるタイミングにより分割されている。全体更新シーケンスは、パブリッシャ１０側が保有しているコンテンツもしくはメタデータの全体のスナップショットを回復するための適当な周期での更新シーケンスである。差分更新情報を格納した更新報知メッセージ（以下「差分更新報知メッセージ」と呼ぶ。）が生成される時、その１つ前の差分更新報知メッセージが生成されてから、今回の差分更新報知メッセージが生成されるまでの、すべての更新がその更新内容の記述に反映される。一方、全体更新情報を格納した更新報知メッセージ（以下「全体更新報知メッセージ」と呼ぶ。）が生成される時、transactionIdは、その１つ前の差分更新報知メッセージと同じものとし、かつ、その更新内容の記述は、その１つ前の差分更新報知メッセージが生成された時までの全ての更新を反映したものとなる。
【００４１】
新規にサブスクライバ３０がデータ全体の同期処理を行う場合、例えば、図４のtransactionId=104とtransactionId=105との間のタイミングＴＭから新たに更新報知メッセージを取得して更新を行う場合には、サブスクライバ３０が、双方向ネットワークを介して、まず、キュー／チャネル２０に保存された、タイミングＴＭより以前の直近の全体更新情報であるtransactionId=101の全体更新報知メッセージを取得し、続いて、それ以降のtransactionId=102,103,104の差分更新報知メッセージを取得し、ホームネットワークを介してサービスクライアントへ更新依頼を行う。
【００４２】
このサブスクライバ３０の処理を、図５のサブスクライバ３０の処理フローを用いてさらに詳細に説明する。まず、サブスクライバ３０は、キュー／チャネル２０から、最新の更新報知メッセージつまりタイミングＴＭの以前に直近の更新報知メッセージ、例えば、図４の場合にはtransactionId=104の更新報知メッセージを取得する（ステップＳ１０１）。サブスクライバ３０は、取得した更新報知メッセージのtransaction要素のupdateType属性をもとに、その更新報知メッセージに格納された更新情報が全体更新情報であるか差分更新情報であるかを判断し（ステップＳ１０２）、全体更新情報であれば、サービスクライアントに対して、その全体更新情報による更新を依頼する（ステップＳ１０３）。サービスクライアントは、サブスクライバ３０より更新依頼を受けると、ローカルなデータベースに蓄積されたコンテンツもしくはメタデータを全体更新情報をもとに更新して同期処理を行う。
【００４３】
一方、ステップＳ１０２で、取得した最新の更新報知メッセージに格納された更新情報が差分更新情報である場合には、タイミングＴＭの以前の直近の最新の全体更新情報を格納した全体更新報知メッセージ、例えば、図４の場合にはtransactionId=101の更新報知メッセージをキュー／チャネル２０から取得し、サービスクライアントに対して、その全体更新情報による更新を依頼する（ステップＳ１０４）。
【００４４】
続いて、サブスクライバ３０は、ステップＳ１０４で取得した全体更新報知メッセージのtransactionId（図４の例ではtransactionId=101）からステップＳ１０１で取得した差分更新報知メッセージのtransactionId（図４の例ではtransactionId=104）の１つ前までの差分更新報知メッセージをキュー／チャネル２０から取得し、サービスクライアントに対して、それらの差分更新報知による更新を依頼する（ステップＳ１０５）。
【００４５】
以降、サブスクライバ３０は、一方向ネットワークにより、キュー／チャネル２０から差分更新報知メッセージを受信するごとに、サービスクライアントに対して、その差分更新情報による更新を依頼する（ステップＳ１０６）。
【００４６】
また、双方向ネットワークを利用できない環境下つまり一方向ネットワークしか利用できない環境下では、図６に示すように、サブスクライバ３０は、一方向ネットワークを介して、次の全体更新報知メッセージが受信されるタイミング（図４の例ではtransactionId=105）まで待って、全体更新報知メッセージを取得し（ステップＳ２０１，Ｓ２０２）、サービスクライアントに、この全体更新報知メッセージに格納された全体更新情報による更新を依頼する（ステップＳ２０３）。以降、サブスクライバ３０は、一方向ネットワークにより、キュー／チャネル２０から差分更新報知メッセージを受信するごとに、サービスクライアントに対して、その差分更新情報による更新を依頼する（ステップＳ２０４）。これにより、一方向ネットワークしか利用できない環境下でサービスクライアントのローカルなデータベースに格納されたコンテンツもしくはメタデータの同期処理が行われる。
【００４７】
いずれのネットワーク環境においても、以降、差分更新報知メッセージをサブスクライバ３０が漏れなく取得できる場合には、全体更新報知メッセージを取得する必要は無い。何らかの事故で差分更新報知メッセージを取りこぼしたことがサブスクライバ３０側で検知された場合には、図５または図６に示した同期処理と同様の手順で回復処理が行われる。
【００４８】
［サービスクライアントでの更新処理の時刻の制御］
次に、サービスクライアントでの更新処理の時刻の制御について説明する。
サービスクライアントでの更新処理は、更新報知メッセージのupdateInfo要素のdateOfEvent属性、validFrom属性、validTo属性等に指定された情報をもとに、次のように行われる。
【００４９】
図７は、このサービスクライアントでの更新処理の時刻制御に関するフローチャートである。
サービスクライアントは、サブスクライバ３０からの更新依頼を受けると、現在時刻を取得した後（ステップＳ３０１）、更新報知メッセージにdateOfEvent属性が指定されているかどうかを判断する（ステップＳ３０２）。dateOfEvent属性が指定されていれば、サービスクライアントは、更新報知メッセージにvalidTo属性として指定された更新フラグメントが無効となる日時と現在時刻とを比較し（ステップＳ３０９）、現在時刻が更新フラグメント無効日時を超えていなければ、すなわち更新情報が有効期限内であれば、更新報知メッセージの更新情報をもとに更新処理を行い（ステップＳ３０８）、現在時刻が更新フラグメント無効日時を超えているなら更新処理を中止する（ステップＳ３１０）。
【００５０】
また、更新報知メッセージには、dateOfEvent属性かvalidFrom属性のいずれかのみが指定されているので、ステップＳ３０２の判断で、更新報知メッセージ内にdateOfEvent属性が指定されていないことを判断した場合には、更新報知メッセージ内にvalidFrom属性が指定されているかどうかを判断する（ステップＳ３０３）。指定されていなければ、上記と同様に、サービスクライアントは、validTo属性の値として指定された更新フラグメントが無効となる日時と現在時刻とを比較し（ステップＳ３０９）、この比較結果に応じて更新処理または更新処理を行う（ステップＳ３０８、Ｓ３１０）。
【００５１】
ステップＳ３０３の判断で、validFrom属性が指定されている場合、サービスクライアントは、validFrom属性の値である更新フラグメントが有効となる日時と現在時刻とを比較し（ステップＳ３０４）、現在時刻が更新フラグメントが有効となる日時に達しているならば、上記と同様に、サービスクライアントは、validTo属性の値として指定された更新フラグメントが無効となる日時と現在時刻とを比較して（ステップＳ３０９）、この比較結果に応じてデータの更新処理または更新処理を行う。
【００５２】
ステップＳ３０４の判断で、現在時刻が更新フラグメントが有効となる日時に達していない場合、サービスクライアントは、その更新フラグメントが有効となる日時になるのを待って（ステップＳ３０５、Ｓ３０６、Ｓ３０７）、更新処理を行う（ステップＳ３０８）。
【００５３】
［更新処理の具体例］
次に、更新処理の具体例として、サブスクライバ３０側のデータ構造が、XMLノードの階層構造で表現される場合の更新シーケンスを示す。
【００５４】
図８はtransactionId=01(初期状態)の全体更新報知メッセージと、この全体更新を反映したデータおよびそのモデルを示す図である。更新の種別（全体更新／差分更新）を示すupdateType属性の値は"full"で、更新内容の詳細を示すupdateDetail要素の内容は"ルート要素Aの追加(初期状態)[add<A>]"である。すなわち、初期状態として、ルート要素Ａが追加されたという全体更新情報が発生したことを示している。
【００５５】
図９はtransactionId=02の差分更新報知メッセージと、この差分更新を反映したデータおよびそのモデルを示す図である。ここでは、更新の種別（全体更新／差分更新）を示すupdateType属性の値は"delta"で、更新内容の詳細を示すupdateDetail要素の内容は"要素Bの追加[add<B>to<A>]"である。すなわち、ルート要素Ａの下に要素Ｂが追加されたという差分更新が発生したこととしている。
【００５６】
図１０はtransactionId=03の差分更新報知メッセージと、この差分更新を反映したデータおよびそのモデルを示す図である。更新の種別（全体更新／差分更新）を示すupdateType属性の値は"delta"で、更新内容の詳細を示すupdateDetail要素の内容は"要素Bの削除と要素Cの追加[[remove<B>from<A>]and[add<C>to<A>]]"である。これは、ルート要素Ａの下から要素Ｂが削除され、要素Ｃが追加された差分更新が発生したことを示している。
【００５７】
図１１はtransactionId=04の差分更新報知メッセージと、この差分更新を反映したデータおよびそのモデルを示す図である。ここでは、更新の種別（全体更新／差分更新）を示すupdateType属性の値は"delta"で、更新内容の詳細を示すupdateDetail要素の内容は"要素Dの追加[add<D>to<C>]"となっている。すなわち、要素Ｃの下に要素Ｄが追加された更新が発生したことを示している。
【００５８】
図１２はtransactionId=04の全体更新報知メッセージと、この全体更新を反映したデータおよびそのモデルを示す図である。更新の種別（全体更新／差分更新）を示すupdateType属性の値は"full"で、更新内容の詳細を示すupdateDetail要素の内容は"要素AとCとDの追加[[add<A>]and[add<C>to<A>]and[add<D>to<C>]]"である。すなわち、ここでは、要素Ａ、要素Ｃ、要素Ｄの全ての更新が発生したこととしている。
【００５９】
［更新内容の詳細の表現方式］
次に、更新内容の詳細の表現方式について説明する。
updateDetail要素に記述される、あるいは、updateReference要素から参照されるファイルに記述される、更新内容の詳細についての表現方式はパブリッシャに依存する。例えば、あるパブリッシャは、更新の表現にXSLT（XML Stylesheet Language Transformations）、あるいは、XQuery(XQuery Update Facility)を利用するかもしれないし、他のパブリッシャは、SQL（Structured Query Language）、あるは、他のデータベース操作言語を利用するかもしれない。更新内容を更新報知メッセージに格納する場合は、全てテキストエンコードされるものとする。updateReference要素から参照されるファイルに記述される場合は、バイナリデータでもかまわない。それぞれのパブリッシャが管理する対象のデータベースに依存した表現形式、あるいは、更新処理を担うサービスクライアントのみが解釈できる表現形式となる。
【００６０】
［更新報知メッセージ配信プロトコル］
次に、更新報知メッセージの配信プロトコルについて説明する。
更新報知メッセージの配信プロトコルには、ユニキャストプロトコルとマルチキャストプロトコルがある。
【００６１】
まず、ユニキャストプロトコルの場合を説明する。
サブスクライバ３０は、HTTP（Hyper Text Transfer Protocol）により、キュー／チャネル２０側で実行されるサーバサイドスクリプトに対して、更新報知メッセージの取得要求を送り、サーバサイドスクリプトは、その取得要求に応じて更新報知メッセージを返信する。サブスクライバ３０は、この取得要求を短い周期で定期的に実行する。この場合のURLシンタクスは以下のように定義される。
http://<serverSideScript>?<queryParameter>
serverSideScriptは、パブリッシャ１０毎のスクリプトのファイル名である。queryParameterは、そのスクリプトに渡される引数のパラメタである。
【００６２】
queryParameterは、以下のいずれかのパターンとなる。
パターン1)
p=lastDelta
最新のtransactionIdを持つ差分更新報知メッセージを要求するパターン。
パターン2)
p=lastFull
最新のtransactionIdを持つ全体更新報知メッセージを要求するパターン。
パターン3)
transactionId=<tansactionId>を’&’をセパレータとしたシーケンス
指定される一連のtransactionIdを持つ差分更新報知メッセージのすべてを要求するパターン。
パターン4)
fromTransactionId=<transactionId_1>&endTransactionId=<transactionId_2>
transactionId_1からtransactionId_2までの更新報知メッセージのすべてを要求するパターン。
【００６３】
次に、マルチキャストプロトコルの場合を説明する。
パブリッシャ１０は、IPマルチキャストを利用し、UDPパケットに更新報知メッセージを格納する。更新報知メッセージは周期的に繰り返して送出される。更新報知メッセージのサイズの上限が、それをIPパケットに格納した際に下位レイヤのMTU(Maximum Transmission Unit)に収まるように制限を設ける（IPフラグメンテーションが起こらないように）。マルチキャストアドレスとポート番号や、周期と繰り返し回数は、http://<コンフィギュレーションファイル>等に記述される。サブスクライバ３０側がそのファイルを事前に取得することにより、あらかじめクライアント側に通知されるものとする。
【００６４】
［ネットワークシステムの例］
次に、上記の更新報知方式を採用したネッワークシステムの構成を説明する。
【００６５】
図１３は、このネッワークシステムの構成を示すブロック図である。
同図に示すように、このネッワークシステム１００は、サービスごとのコンテンツもしくはコンテンツのメタデータを配信する複数のサービスプロバイダ４０Ａ，４０Ｂ，４０Ｃと、それらコンテンツやメタデータの配信サービスを受けるデバイスやアプリケーションが存在するホームネットワーク側の機器５０とで構成される。それぞれのサービスプロバイダ４０Ａ，４０Ｂ，４０Ｃには更新報知メッセージの生成を行うパブリッシャ１０Ａ，１０Ｂ，１０Ｃと、パブリッシャ１０Ａ，１０Ｂ，１０Ｃにより生成された更新報知メッセージをネットワーク９０に公開するキュー／チャネル２０Ａ，２０Ｂ，２０Ｃとを有する。一方、ホームネットワーク側の機器５０は、サービスプロバイダ４０Ａ，４０Ｂ，４０Ｃのキュー／チャネル２０Ａ，２０Ｂ，２０Ｃからネットワーク９０を介して更新報知メッセージを取得するサブスクライバ３０と、ローカルなデータベースに格納されるサービスごとのコンテンツもしくはメタデータの更新処理を担う、サービスごとに対応するアプリケーションである複数のサービスクライアント６０ａ，６０ｂ，６０ｃとを有する。サブスクライバ３０とサービスクライアント６０ａ，６０ｂ，６０ｃとはホームネットワーク７０を介して接続可能とされている。
【００６６】
サブスクライバ３０は、サービスプロバイダ４０Ａ，４０Ｂ，４０Ｃのキュー／チャネル２０Ａ，２０Ｂ，２０Ｃよりネットワーク９０を介して更新報知メッセージを取得し、フィルタリングを通じて選択的にサービスクライアント６０ａ，６０ｂ，６０ｃに、更新報知メッセージ内の更新情報(updateDetail要素の内容)、もしくは、更新情報への参照(updateReference要素の内容)である更新情報を提供する。サービスクライアント６０ａ，６０ｂ，６０ｃは、取得した更新情報で、ローカルコンテンツ／メタデータデータベース６１ａ，６１ｂ，６１ｃに格納されているコンテンツ／メタデータの更新を行う。
【００６７】
また、サブスクライバ３０は、更新情報の提供先であるサービスクライアント６０ａ，６０ｂ，６０ｃが起動していない場合、そのサービスクライアント６０ａ，６０ｂ，６０ｃを起動して更新情報もしくは更新情報への参照を提供する。サービスクライアント６０ａ，６０ｂ，６０ｃは、提供された更新情報もしくは更新情報への参照をもとに得た更新情報をもとに、ローカルコンテンツ／メタデータデータベース６１ａ，６１ｂ，６１ｃのコンテンツもしくはメタデータを更新して同期処理を行う。ここで、サブスクライバ３０からサービスクライアント６０ａ，６０ｂ，６０ｃに更新情報を渡す際のプロトコルは、それぞれのサービスクライアント６０ａ，６０ｂ，６０ｃ毎に実装されるものとする。
【００６８】
各サービスプロバイダ４０Ａ，４０Ｂ，４０Ｃのキュー／チャネル２０Ａ，２０Ｂ，２０Ｃは、複数のSNSサイト８０で管理されているカテゴリデータベースから、各SNSサイト８０で定義されているカテゴリを取得して、このカテゴリを更新報知メッセージのフィルタ属性であるeventCategoryに設定することが可能である。
【００６９】
次に、サービスプロバイダ４０Ａ，４０Ｂ，４０Ｃの構成と処理シーケンスを説明する。
【００７０】
図１４はサービスプロバイダ４０Ａ，４０Ｂ，４０Ｃの構成を示す図、図１５はサービスプロバイダ４０Ａ，４０Ｂ，４０Ｃの処理シーケンスを示す図である。
パブリッシャ１０Ａ，１０Ｂ，１０Ｃは、コンテンツ／メタデータ管理サーバ１１、コンテンツ／メタデータマスタデータベース１２、更新報知ジェネレータ１３を備える。
【００７１】
コンテンツ／メタデータ管理サーバ１１は、ユーザインターフェイスを介したユーザからの指示もしくはアプリケーションからの指示に応じて、コンテンツもしくはコンテンツのメタデータ（以下「コンテンツ／メタデータ」と記述する。）の生成及び更新を行う（Ｓ４０１）。
【００７２】
コンテンツ／メタデータマスタデータベース１２は、コンテンツ／メタデータ管理サーバ１１により生成及び更新されたコンテンツ／メタデータを格納するデータベースである。
【００７３】
更新報知ジェネレータ１３は、コンテンツ／メタデータマスタデータベース１２に格納されたコンテンツ／メタデータについて、定期的な更新の検出を行い、更新が検出された場合にはその更新情報を格納した更新報知メッセージの生成と、生成した更新報知メッセージをキュー／チャネル２０Ａ，２０Ｂ，２０Ｃのフィルタマネジャ２１へ引き渡す処理を行う（S４０２）。
【００７４】
一方、キュー／チャネル２０Ａ，２０Ｂ，２０Ｃは、フィルタマネジャ２１、更新報知メッセージデータベース２２、SNSカテゴリアグリゲータ２３、メッセージ配布サーバ２４を備える。
【００７５】
SNSカテゴリアグリゲータ２３は、SNSサイト８０のカテゴリデータベースからのカテゴリの収集と、収集したカテゴリのフィルタマネジャ２１への通知を行う（Ｓ４０３）。
【００７６】
フィルタマネジャ２１は、更新報知ジェネレータ１３から引き渡された更新報知メッセージのeventCategory属性を、SNSカテゴリアグリゲータ２３より通知されたカテゴリをもとに設定して更新報知メッセージデータベース２２へ格納する処理を行う（Ｓ４０４）。
【００７７】
更新報知メッセージデータベース２２は、フィルタマネジャ２１によりeventCategory属性が設定された更新報知メッセージを格納するデータベースである。
【００７８】
メッセージ配布サーバ２４は、更新報知メッセージデータベース２２に格納された更新報知メッセージのネットワーク９０を介したサブスクライバ３０へのマルチキャスト転送、もしくは、サブスクライバ３０からのリクエストに応じた、更新報知メッセージデータベース２２からの更新報知メッセージの検索と、検索した更新報知メッセージのユニキャスト転送を行う（Ｓ４０５）。
【００７９】
図１６はSNSカテゴリアグリゲータ２３とSNSサイト８０の構成を示す図、図１７はSNSカテゴリアグリゲータ２３によるSNSサイト８０のカテゴリデータベースからのカテゴリの収集の処理シーケンスを示す図である。
【００８０】
SNSサイト８０は、カテゴリ管理アプリケーション８１とカテゴリデータベース８２を備える。カテゴリ管理アプリケーション８１は、当該SNSサイト８０を利用しているユーザが登録したブログ等の内容に対応して定義したカテゴリを、カテゴリデータベース８２に格納する処理を行う（Ｓ５０１）。カテゴリデータベース８２は、カテゴリを格納するデータベースである。そしてSNSカテゴリアグリゲータ２３は、前述したようにSNSサイト８０のカテゴリデータベース８２からカテゴリを収集し、フィルタマネジャ２１へ通知する処理を行う（Ｓ５０２）。
【００８１】
次に、ホームネットワーク側の機器（ネットワーク家電機器）５０の構成と処理シーケンスを説明する。
【００８２】
図１８はホームネットワーク側の機器５０の構成を示す図、図１９はホームネットワーク側の機器５０の処理シーケンスを示す図である。
サブスクライバ３０は、メッセージ配布クライアント３１、レジデンシャルメッセージデータベース３２、レジデンシャルメッセージ配布サーバ３３を備える。
【００８３】
メッセージ配布クライアント３１は、Ｓ６０１にてユーザインターフェイスを介してユーザより入力された、更新報知メッセージのフィルタ属性、もしくは、サービスクライアント６０ａ，６０ｂ，６０ｃからの更新報知メッセージのフィルタ登録要求をもとに与えられた、更新報知メッセージのフィルタ属性をレジデンシャルメッセージデータベース３２に格納する処理を行う（Ｓ６０２）。例えば、サービスクライアント６０ａ，６０ｂ，６０ｃごとに、どのサービスのどんなカテゴリの更新情報を取得するかが、レジデンシャルメッセージデータベース３２に登録される。また、メッセージ配布クライアント３１は、キュー／チャネル２０Ａ，２０Ｂ，２０Ｃのメッセージ配布サーバ２４からマルチキャストで送信された更新報知メッセージ、もしくは、メッセージ取得リクエストの送信に対してキュー／チャネル２０Ａ，２０Ｂ，２０Ｃから応答された更新報知メッセージを、レジデンシャルメッセージデータベース３２に格納する（Ｓ６０３）。
【００８４】
レジデンシャルメッセージ配布サーバ３３は、レジデンシャルメッセージデータベース３２から定期的に更新報知メッセージを検索し、この更新報知メッセージ内の更新情報(updateDetail要素の内容)、もしくは、更新情報への参照(updateReference要素の内容)を、レジデンシャルメッセージデータベース３２に登録された各サービスクライアント６０ａ，６０ｂ，６０ｃのフィルタ属性をもとに、対応するサービスクライアント６０ａ，６０ｂ，６０ｃにホームネットワーク７０を介して提供する。この際、対応するサービスクライアント６０ａ，６０ｂ，６０ｃが起動されていない場合には、そのサービスクライアント６０ａ，６０ｂ，６０ｃを起動して更新情報もしくは更新情報への参照を提供する（Ｓ６０４）。
【００８５】
例えば、サービスクライアント６０に、サービスプロバイダ４０Ａの配信サービスにおける、カテゴリが、"スポーツ"のメタデータの更新報知メッセージが届くようにフィルタ属性がレジデンシャルメッセージデータベース３２に登録されている場合を考える。この場合、レジデンシャルメッセージ配布サーバ３３は、レジデンシャルメッセージデータベース３２から検索された更新報知メッセージの、eventCategory属性が"サービスプロバイダ４０Ａのコンテンツ配信サービスにおける、カテゴリが"スポーツ"のメタデータの更新報知"であれば、この更新報知メッセージ内の更新情報もしくは更新情報への参照をサービスクライアント６０ａに通知するためにサービスクライアント６０ａを起動させる。
【００８６】
サービスクライアント６０ａ，６０ｂ，６０ｃは、レジデンシャルメッセージ配布サーバ３３より更新情報もしくは更新情報への参照を取得すると、この更新情報もしくは更新情報への参照をもとに、ローカルコンテンツ／メタデータデータベース６１ａ，６１ｂ，６１ｃに格納されているコンテンツ／メタデータの更新を行う（Ｓ６０５）。
【００８７】
図２０は、複数のサービスプロバイダ４０Ａ，４０Ｂ，４０Ｃと複数のサービスクライアント６０ａ，６０ｂ，６０ｃとの間での更新報知メッセージの通知の例を示す図である。
【００８８】
ここで、サービスクライアント６０ａはサービスプロバイダ４０Ａの更新情報を取得し、サービスクライアント６０ｂはサービスプロバイダ４０Ｂの更新情報を取得し、サービスクライアント６０ｃはサービスプロバイダ４０Ｃの更新情報を取得するように、サブスクライバ３０が更新情報のフィルタリングを行うこととする。なお、コンテンツ／メタデータのカテゴリ属性は指定されていないこととする。
【００８９】
まず、サービスプロバイダ４０ＡからのtransactionId=100の更新報知メッセージがサブスクライバ３０のレジデンシャルメッセージデータベース３２に格納され、レジデンシャルメッセージ配布サーバ３３は、レジデンシャルメッセージデータベース３２から、その更新報知メッセージを検出し、その更新報知メッセージ内の更新情報もしくは更新情報への参照をサービスクライアント６０ａに通知する。なお、レジデンシャルメッセージ配布サーバ３３からサービスクライアント６０ａ，６０ｂ，６０ｃへの更新情報もしくは更新情報への参照の通知は、サービスクライアント６０ａ，６０ｂ，６０ｃごとのプロトコルに従って行われる。
【００９０】
次に、サービスプロバイダ４０ＣからのtransactionId=67の更新報知メッセージがサブスクライバ３０のレジデンシャルメッセージデータベース３２に格納されると、レジデンシャルメッセージ配布サーバ３３は、レジデンシャルメッセージデータベース３２から、その更新報知メッセージを検出し、その更新報知メッセージ内の更新情報もしくは更新情報への参照をサービスクライアント６０ｃに通知する。
【００９１】
続いて、サービスプロバイダ４０ＢからのtransactionId=988の更新報知メッセージがサブスクライバ３０のレジデンシャルメッセージデータベース３２に格納されると、レジデンシャルメッセージ配布サーバ３３は、レジデンシャルメッセージデータベース３２から、その更新報知メッセージを検出し、その更新報知メッセージ内の更新情報もしくは更新情報への参照をサービスクライアント６０ｂに通知する。
【００９２】
この後、サービスプロバイダ４０ＢからのtransactionId=989の更新報知メッセージ、サービスプロバイダ４０ＣからのtransactionId=98の更新報知メッセージ、サービスプロバイダ４０ＡからのtransactionId=98の更新報知メッセージが順にサブスクライバ３０のレジデンシャルメッセージデータベース３２に格納され、レジデンシャルメッセージ配布サーバ３３は、これらの更新報知メッセージを検出して、サービスプロバイダ４０ＢからのtransactionId=989の更新報知メッセージ内の更新情報もしくは更新情報への参照をサービスクライアント６０ｂに、サービスプロバイダ４０ＣからのtransactionId=98の更新報知メッセージ内の更新情報もしくは更新情報への参照をサービスクライアント６０ｃに、サービスプロバイダ４０ＡからのtransactionId=98の更新報知メッセージ内の更新情報もしくは更新情報への参照をサービスクライアント６０ａに順に通知する。
【００９３】
このように、サブスクライバ３０は、フィルタ属性の登録内容をもとに、各サービスプロバイダ４０Ａ，４０Ｂ，４０Ｃで生成された更新報知メッセージ内の更新情報もしくは更新情報への参照を、対応するサービスクライアント６０ａ，６０ｂ，６０ｃに提供することができる。
【００９４】
次に、更新報知メッセージ内の更新情報への参照をもとにしたコンテンツ／メタデータの更新処理シーケンスを説明する。
【００９５】
図２１は更新報知メッセージ内の更新情報への参照をもとにしたコンテンツ／メタデータの更新処理のための構成を示す図、図２２はこの更新報知メッセージ内の更新情報への参照をもとにしたコンテンツ／メタデータの更新処理のシーケンス図である。
【００９６】
サービスプロバイダ４０側には、サービスクライアント６０ａ，６０ｂ，６０ｃからの更新情報の参照要求を受け付けて、対応するコンテンツ／メタデータをサービスクライアント６０ａ，６０ｂ，６０ｃに応答するデータベース同期情報提供サーバ２５が設けられている。データベース同期情報提供サーバ２５は、サービスクライアント６０ａ，６０ｂ，６０ｃからの更新情報の参照要求を受けると、コンテンツ／メタデータマスタデータベース１２に格納されている、対応する参照先のコンテンツ／メタデータの更新情報を検索し、参照要求元であるサービスクライアント６０ａ，６０ｂ，６０ｃに、その更新情報を返信する（Ｓ７０１）。サービスクライアント６０ａ，６０ｂ，６０ｃは、データベース同期情報提供サーバ２５から応答された更新情報を受信し、この更新情報を用いて、ローカルコンテンツ／メタデータデータベース６１ａ，６１ｂ，６１ｃに格納されているコンテンツ／メタデータの更新を行う（Ｓ７０２）。
【００９７】
このように、更新報知メッセージに更新情報の実データではなく更新情報への参照を格納し、更新報知メッセージを取得したサービスクライアント６０ａ，６０ｂ，６０ｃは、この更新情報への参照をもとに更新情報を取得するようにすることで、サービスプロバイダ４０Ａ，４０Ｂ，４０Ｃ側から複数のサービスクライアント６０ａ，６０ｂ，６０ｃへ向けて更新情報の実データが送信される時間帯をずらすことができ、サービスプロバイダ４０Ａ，４０Ｂ，４０Ｃ側の負荷を時間分散することができ、効率良く更新の処理を行うことができる。
【００９８】
次に、サービスクライアント６０ａ，６０ｂ，６０ｃにおけるローカルコンテンツ／メタデータデータベース６１ａ，６１ｂ，６１ｃの障害回復処理を説明する。
【００９９】
図２３はサービスクライアント６０ａのローカルコンテンツ／メタデータデータベース６１ａに障害が発生した場合の障害回復処理のための構成を示す図、図２４はこの障害回復処理のシーケンス図である。
【０１００】
各サービスプロバイダ４０Ａ，４０Ｂ，４０Ｃは、サービスクライアント６０ａ，６０ｂ，６０ｃからの、障害回復更新情報の参照要求を受けたとき、コンテンツ／メタデータマスタデータベース１２に格納されている、対応するコンテンツ／メタデータの全ての更新情報を検索して、リクエスト元であるサービスクライアント６０ａに、その更新情報を返信するデータベース同期情報提供サーバ２５を有する。
【０１０１】
サービスクライアント６０ａのローカルコンテンツ／メタデータデータベース６１ａの障害が検知されると障害回復処理を開始する（Ｓ８０１）。この障害回復処理において、まず、サービスクライアント６０ａは、サブスクライバ３０内のレジデンシャルメッセージ配布サーバ３３に対して、更新報知メッセージの取得要求をホームネットワーク７０を介して送信する。レジデンシャルメッセージ配布サーバ３３は、更新報知メッセージの取得要求を受けると、レジデンシャルメッセージデータベース３２に格納されている更新報知メッセージのうち、レジデンシャルメッセージデータベース３２に登録されているサービスクライアント６０ａのフィルタ属性をもとに、該当するすべての更新報知メッセージを抽出して、サービスクライアント６０ａに返信する（Ｓ８０２）。
【０１０２】
ここで、更新報知メッセージに更新情報の実データが格納されている場合には、サービスクライアント６０ａは、Ｓ８０３で取得した更新報知メッセージ内の更新情報を用いて、ローカルコンテンツ／メタデータデータベース６１ａの障害回復処理を行う（Ｓ８０４）。また、更新報知メッセージに更新情報への参照だけが格納されている場合には、サービスクライアント６０ａは、この更新情報への参照先であるサービスプロバイダ（仮にサービスプロバイダ４０Ａとする。）のデータベース同期情報提供サーバ２５に、ホームネットワーク７０及びネットワーク９０を介して、障害回復更新情報の参照要求を送信する。データベース同期情報提供サーバ２５は、サービスクライアント６０ａからの更新情報の参照リクエストを受けると、コンテンツ／メタデータマスタデータベース１２に格納されている、対応するコンテンツ／メタデータの更新情報を検索して、リクエスト元であるサービスクライアント６０ａに、その更新情報を返信する（Ｓ８０５）。サービスクライアント６０ａは、データベース同期情報提供サーバ２５からの更新情報を取得すると、この更新情報を用いて、ローカルコンテンツ／メタデータデータベース６１ａの障害回復処理を行う（Ｓ８０４）。
【０１０３】
なお、以上の障害回復処理は、他のサービスクライアントのローカルコンテンツ／メタデータデータベースに障害が発生した場合も同様であり、更新情報への参照先であるサービスプロバイダが他のサービスプロバイダである場合も同様である。
【０１０４】
この方式によると、サービスクライアント６０ａ，６０ｂ，６０ｃのローカルコンテンツ／メタデータデータベース６１ａ，６１ｂ，６１ｃが何らかの障害により回復処理が必要になった場合に、必ずしもサービスプロバイダ４０Ａ，４０Ｂ，４０Ｃにアクセスしなくとも、ホームネットワーク内のレジデンシャルメッセージデータベース３２に格納されている更新報知メッセージを用いてローカルコンテンツ／メタデータデータベース６１ａ，６１ｂ，６１ｃの障害回復処理を行うことが可能となる。これにより、ローカルコンテンツ／メタデータデータベース６１ａ，６１ｂ，６１ｃの障害回復処理に伴うトランザクションを処理するための負荷を軽減することができる。
【０１０５】
以上の構成では、サブスクライバ３０とサービスクライアント６０ａ，６０ｂ，６０ｃがホームネットワーク７０の中にある例を示したが、本発明の方式は、サービスクライアント６０ａ，６０ｂ，６０ｃがホームネットワーク７０の外にある場合においても応用することが可能である。次に、この例を示す。
【０１０６】
PSP（登録商標）やPlayStation（登録商標）等のパッケージメディアをベースとするゲームデバイスは、常時ネットワーク９０に接続されているとは限らない。また、旅行先にゲームデバイスを持っていった場合等には、ホームネットワーク７０上のサブスクライバ３０、もしくは、直接サービスプロバイダ４０Ａ，４０Ｂ，４０Ｃのキュー／チャネル２０Ａ，２０Ｂ，２０Ｃから更新情報を取得するために、ゲームデバイスをネットワーク９０に接続しなければならない。この場合、ゲームデバイスに携帯電話を装着して（bluetooth（登録商標）により近距離で接続するような形態も含まれる)、携帯電話網やホットスポット（登録商標）(携帯電話に無線LAN機能がある場合)を介して更新情報を取得する。
【０１０７】
図２５は、携帯電話１２０上に実装されるサービスクライアント６０ｄが、ゲームデバイス１１０に格納されているコンテンツやメタデータの更新処理を代行する形態における更新シーケンスを示す図である。
【０１０８】
携帯電話１２０上のサービスクライアント６０ｄが起動され（Ｓ９０１）、ゲームデバイス１１０に（物理的に接触・非接触を問わず）ローカルチャネル接続されると、携帯電話１２０上のサービスクライアント６０ｄがサービスプロバイダ４０のキュー／チャネル２０内の更新報知メッセージデータベース２２から最新の更新報知メッセージを取得する（Ｓ９０２）。携帯電話１２０上のサービスクライアント６０ｄは、取得した更新報知メッセージに含まれるtransaction要素の属性をもとに、その最新の更新情報が全体更新情報であるか差分更新情報であるかを判断し、全体更新情報であれば、ローカルチャネル接続を介して、ゲームデバイス１１０上のアプリケーションに、この全体更新情報による更新を依頼する（Ｓ９０３）。
【０１０９】
また、取得した最新の更新情報が差分更新情報である場合には、過去の直近の全体更新情報を含む更新報知メッセージをサービスプロバイダ４０のキュー／チャネル２０から取得し、さらに、Ｓ９０３で取得した更新報知メッセージからS９０２で取得した更新報知メッセージの１つ前までの差分更新情報をキュー／チャネルから取得し、ローカルチャネル接続を介してゲームデバイス１１０上のアプリケーションに、これら取得した差分更新情報による更新を依頼する（Ｓ９０４）。
【０１１０】
以降、携帯電話１２０上のサービスクライアント６０ｄは、キュー／チャネル２０から差分更新報知メッセージを受信するごとに、ローカルチャネル接続されたゲームデバイス１１０上のアプリケーションに対して、その差分更新情報による更新を依頼する（Ｓ９０６）。
【０１１１】
なお、携帯電話１２０上のサービスクライアント６０ｄからゲームデバイス１１０上のアプリケーションへの更新情報の伝送は、SD（登録商標）メモリーカードやメモリースティック（登録商標）等のメモリデバイスを介して提供されることとしてもよい。
【０１１２】
ところで、以上説明したネットワークシステム１００において、個々のサービスプロバイダ４０Ａ，４０Ｂ，４０Ｃは、例えば、図２６に示すように、ＰＣ等のコンピュータのハードウェアとプログラム等とで実現される。
【０１１３】
すなわち、CPU６０１には、システムバス６０９を介して、ROM６０２と、RAM６０３と、ネットワーク９０インタフェース部６０４と、キーボード、マウスなどよりなる入力部６０５と、CRT（Cathode Ray Tube）、LCDなどよりなるディスプレイとスピーカなどよりなる出力部６０６と、メディアインタフェース部６０７と、ハードディスクドライブや不揮発性メモリなどよりなる記憶部６０８とが接続されている。
【０１１４】
ネットワークインタフェース部６０４は、ネットワーク９０との有線または無線での接続を処理する。記憶部６０８には、特定のサーバとしての機能をコンピュータに実行させるためのプログラムと、各種のデータなどが格納されている。CPU６０１は、ROM６０２や記憶部６０８から、コンピュータを、サービスプロバイダにおけるパブリッシャやキュー／チャネルとして機能させるためのプログラムをRAM６０２へロードして、解釈実行するための演算処理を行う。メディアインタフェース部６０７には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア２が適宜装着され、それらから読み出されたプログラムが、必要に応じて記憶部６０８にインストールされる。
【０１１５】
また、サービスプロバイダにおいて、パブリッシャとキュー／チャネルとは別々のコンピュータ上で動作するプログラムであってもよいし、１つのコンピュータ上で動作するプログラムであってもよい。
【０１１６】
また、ホームネットワーク側の機器５０において、サブスクライバ、サービスクライアントは、例えばＴＶに実装されたプログラムや、ＰＣにインストールされたアプリケーション・プログラムとして動作するものであってもよい。また、サブスクライバと各サービスクライアントは、それぞれ異なる機器に組み込まれたプログラムによって動作するものであってもよい。
【０１１７】
図２７はサブスクライバ、サービスクライアントを実装したネットワーク家電機器のハードウェア構成を示すブロック図である。同図に示すように、CPU（Central Processing Unit）５０１には、システムバス５０２を介して、ROM（Read Only Memory）５０３と、RAM（Random Access Memory）５０４と、入力操作部５０５と、表示部５０６と、音声出力部５０７と、ネットワークインタフェース部５０８と、光通信部５１１と、記憶部５１２とが接続されている。
【０１１８】
入力操作部５０５は、各種のキーなどを備え、ユーザからの各種の命令やデータの入力を処理する。入力操作部５０５によってユーザより入力された命令は、図示しない入力インタフェース部によってシステムバス５０２を通じてCPU５０１に供給される。表示部５０６は、例えば、LCD（Liquid Crystal Display）などの表示器と、表示器を駆動する表示制御回路よりなる。音声出力部５０７は、デジタルの音声信号をアナログの音声信号に変換する回路と、スピーカなどよりなる。ネットワークインタフェース部５０８は、ネットワーク９０との有線または無線での接続を処理する。
【０１１９】
光通信部５１１は、リモートコントローラやその他の外部機器との間での通信を処理するためのインタフェースであり、具体的には、赤外線などの光を無線媒体として外部機器との通信を行うものである。また、光の他に、電波、音波、電磁波などの他の無線媒体を用いてもよい。記憶部５１２は、例えば、ハードディスクドライブや半導体メモリ等の記憶装置である。
【０１２０】
ROM５０３は、サブスクライバ、サービスクライアントとしての機能をコンピュータに実行させるためのプログラムやデータなどが恒久的に格納された読み出し専用メモリである。なお、プログラムは記憶部５１２に格納されていてもよい。RAM５０４は、ROM５０３や記憶部５１２からロードされたプログラムやプログラムの作業データ等を書き込むために使用されるメモリである。CPU５０１は、ROM５０３に格納されたプログラムやRAM５０４にロードされたプログラムを解釈実行するための演算処理を行う。
【０１２１】
（第２の実施形態）
以上説明した実施形態では、要素を単位としてメタデータを更新する場合について説明したが、次に、フラグメントを単位として階層化されたTV-Ａnytimeメタデータをフラグメントを単位に更新する方法について説明する。
【０１２２】
フラグメントとは、全体のTV-Ａnytimeなどのメタデータの中の一部のことをいう。一部とは、１以上の要素で構成されるメタデータの部分とも言える。図２９はTV-Ａnytimeメタデータのフラグメントとして、放送チャンネルのサービスに関する情報を記述したServiceInformationメタデータの例である。
【０１２３】
図２９で、ServiceInformation-A，-B，-Cをそれぞれ放送チャンネル-A，-B，-CのServiceInformationメタデータとする。これらのServiceInformationメタデータには、放送チャンネルのサービスに関する情報として、例えば、サービス識別子、親サービスへの参照、サービス名、所有者、サービスジャンルなどの情報を記述することができる。この実施形態では、ServiceInformationに、チャンネルを購入する際に必要となる価格を記述できるPurchaseItem要素を拡張により導入している。この例では、例えば、放送チャンネル-Aは月額３００円、放送チャンネル-Bは月額４００円、放送チャンネル-Cは月額５００円である。
【０１２４】
放送チャンネルの価格の変更や放送チャンネルの購入の単位の変更などが発生した場合のServiceInformationメタデータの更新について説明する。図３０は放送チャンネル-Bと放送チャンネル-Cとを１つにまとめて価格を月額６００円とした場合のServiceInformationメタデータの更新例である。この例では、放送チャンネル-Bと放送チャンネル-Cとを１つの「チャンネルパック」として包含し、このチャンネルパックのServiceInformationメタデータであるServiceInformation-Dが新たに作成される。そしてServiceInformation-D内のPurchaseItem要素に、放送チャンネル-Bと放送チャンネル-Cとを１つにまとめた価格に関する情報が記述される。
【０１２５】
ところで、現行のTV-Anytimeの規格では、ServiceInformationにおいて、上記のように複数の放送チャンネルを包含したチャンネルパックの構成のように、フラグメントの単位で階層化された構成を記述することができない。そこで、本実施形態では、複数の放送チャンネルを包含したチャンネルパックの構成を定義するためにServicePackRef要素が新たに導入されている。このServicePackRef要素は、包含される子のServiceInformation（この例ではServiceInformation-ＡとServiceInformation-Ｂ）から見て親のServiceInformation（この例ではServiceInformation-Ｄ）への参照を定義するための要素である。
【０１２６】
図４１は図３０に示したServiceInformationメタデータの更新処理を説明するための図、図３１は図３０に示す変更前の放送チャンネル-B，-CのServiceInformationメタデータの具体例、図３２は図３０に示す変更後のServiceInformationメタデータの具体例を示す図である。
【０１２７】
変更前のServiceInformationメタデータにはServiceInformationTable要素７１が含まれている。このServiceInformationTable要素７１には、複数の放送チャンネルのServiceInformation要素７２，７３、すなわち本例では放送チャンネル-Bと放送チャンネル-CのそれそれのServiceInformation要素７２，７３が含まれている。ServiceInformation要素７２，７３には、サービスを識別するserviceId属性７４、フラグメントを識別するfragmentId属性７５、フラグメントのバージョンを示すfragmentVersion属性７６、放送チャンネルの名前が記述されるName要素７７、そして価格に関する情報が記述されるPurchaseItem要素７８が含まれている。PurchaseItem要素７８には、価格が記述されるPrice要素７９と、例えば月額であるなどの価格に関する情報が記述されるPurchase要素９１が含まれている。
【０１２８】
一方、変更後のServiceInformationメタデータにはServiceInformationTable要素７１ａが含まれている。このServiceInformationTable要素７１ａには、複数の放送チャンネルとチャンネルパックのそれぞれのServiceInformation要素７２ａ，７３ａ，９２が含まれている。包含される各々の放送チャンネルのServiceInformation要素７２ａ，７３ａには、サービスを識別するserviceId属性７４、フラグメントを識別するfragmentId属性７５、フラグメントのバージョンを示すfragmentVersion属性７６、放送チャンネルの名前が記述されるName要素７７、そしてServicePackRef要素９３が含まれている。チャンネルパックのServiceInformation要素９２には、サービスを識別するserviceId属性７４、fragmentId属性７５、fragmentVersion属性７６、チャンネルパックの名前が記述されるName要素７７、価格に関する情報が記述されるPurchaseItem要素９４が含まれている。PurchaseItem要素９４には、価格が記述されるPrice要素９５と、例えば月額であるなどの価格に関する情報が記述されるPurchase要素９６が含まれている。
【０１２９】
次に、メタデータを配信するIPTVサーバとそのメタデータを取得するIPTVクライアント端末とを含むIPTVシステムにおいて、フラグメントの単位でのServiceInformationメタデータの更新が行われる場合の動作を説明する。
【０１３０】
図３３はこのIPTVシステム１００の構成を示す図である。同図に示すように、このIPTVシステム１００は、IPTVサーバ１１０とIPTVクライアント端末１２０と、これらを接続可能なインターネットなどのネットワーク１３０とを含む。
【０１３１】
IPTVサーバ１１０は、メタデータ生成部１１１、メタデータサーバデータベース１１２、メタデータ配信部１１３、およびIPTVメディアサーバ１１４などを有している。
【０１３２】
メタデータ生成部１１１は、メタデータを生成する。メタデータサーバデータベース１１２はメタデータ生成部１１１により生成されたメタデータを保持する。メタデータ配信部１１３は、メタデータサーバデータベース１１２に保持されているメタデータをネットワーク１３０を介してIPTVクライアント端末１２０に配信する。IPTVメディアサーバ１１４は、コンテンツをネットワーク１３０を介してIPTVクライアント端末１２０に伝送する。
【０１３３】
IPTVクライアント端末１２０は、メタデータ受信部１２１、メタデータクライアントデータベース１２２、ユーザインターフェース処理部１２３、およびIPTVメディアクライアント１２４を有している。
【０１３４】
メタデータ受信部１２１は、ネットワーク１３０を介してIPTVサーバ１１０から送信されてくるメタデータを受信する。メタデータクライアントデータベース２２２は、メタデータ受信部１２１が受信したメタデータを保持する。ユーザインターフェース処理部１２３は、ユーザからの指示を入力する。IPTVメディアクライアント１２４は、ユーザインターフェース処理部１２３からの指示に基づいて、ネットワーク１３０を介してIPTVサーバ１１０から伝送されてくるコンテンツを受信し、再生する。
【０１３５】
次に、図３４のフローチャートを参照して、IPTVサーバ１１０からIPTVクライアント端末１２０へのServiceInformationメタデータの配信と更新の処理について説明する。
【０１３６】
まず、IPTVサーバ１１０において、メタデータ生成部１１１は、放送チャンネルの ServiceInformationメタデータを生成する（ステップＳ１）。生成された放送チャンネルの ServiceInformationメタデータはメタデータサーバデータベース１１２に保存される。
【０１３７】
メタデータ配信部１１３は、メタデータサーバデータベース１１２からServiceInformationメタデータを読み出し、このServiceInformationメタデータを含む更新報知メッセージを生成し（ステップＳ２）、この更新報知メッセージをネットワーク１３０を介してIPTVクライアント端末１２０に配信する（ステップＳ３）。
【０１３８】
IPTVクライアント端末１２０内のメタデータ受信部１２１は、ネットワーク１３０を介してIPTVサーバ１１０から伝送されてくる更新報知メッセージを受信し（ステップＳ４）、受信した更新報知メッセージに含まれるServiceInformationメタデータをメタデータクライアントデータベース１２２に登録する（ステップＳ５）。
【０１３９】
その後、IPTVサーバ１１０内のメタデータ生成部１１１により、更新されたServiceInformationメタデータが生成された場合（ステップＳ６）、この更新されたServiceInformationメタデータはメタデータサーバデータベース１１２に保存される。
【０１４０】
メタデータ配信部１１３は、メタデータサーバデータベース１１２から更新されたServiceInformationメタデータを読み出し、この更新されたServiceInformationメタデータを含む更新報知メッセージを生成し（ステップＳ７）、ネットワーク１３０を介してIPTVクライアント端末１２０に配信する（ステップＳ８）。
【０１４１】
IPTVクライアント端末１２０内のメタデータ受信部１２１は、ネットワーク１３０を介してIPTVサーバ１１０から伝送されてくる更新されたServiceInformationメタデータを含む更新報知メッセージを受信すると（ステップＳ９）、メタデータクライアントデータベース１２２に登録されている既存のServiceInformationメタデータの中で、受信した更新報知メッセージに含まれるServiceInformationメタデータに対してfragmentIDが一致するServiceInformationメタデータを検索し、この既存のServiceInformationメタデータを、更新報知メッセージに含まれるServiceInformationメタデータで更新する（ステップＳ１０）。
【０１４２】
次に、上記ServiceInformationメタデータの配信と更新の処理を、図３１および図３２に示した更新前後のServiceInformationメタデータを例に、より詳細に説明する。
【０１４３】
図３５はIPTVサーバ１１０での処理のシーケンス、図３６はIPTVクライアント端末１２０での処理シーケンスである。
【０１４４】
まず、メタデータ生成部１１１は、チャンネル-BのServiceInformationメタデータを生成する（図３５：ステップＳ１１）。このチャンネル-BのServiceInformationメタデータは図３１においてserviceId属性７４の値が"Channel-B"であるServiceInformation要素７２以下の階層部分である。続いて、メタデータ生成部１１１により生成されたチャンネル-BのServiceInformationメタデータ３４がメタデータサーバデータベース１１２に登録される。また、このときメタデータサーバデータベース１１２には、チャンネル-BのServiceInformationメタデータ内に含まれるfragmentId属性７５の値"1234"とfragmentVersion属性７６の値"1001"が更新管理情報３５として格納される。
【０１４５】
さらに、メタデータ生成部１１１は、チャンネル-ＣのServiceInformationメタデータを生成する（図３５：ステップＳ１２）。このチャンネル-ＣのServiceInformationメタデータは図３１においてserviceId属性７４の値が"Channel-C"であるServiceInformation要素７３以下の階層部分である。続いて、メタデータ生成部１１１により生成されたチャンネル-ＣのServiceInformationメタデータ３６がメタデータサーバデータベース１１２に登録される。また、このときメタデータサーバデータベース１１２には、チャンネル-ＣのServiceInformationメタデータ内に含まれるfragmentId属性７５の値"5678"とfragmentVersion属性７６の値"1010"が更新管理情報３７として格納される。
【０１４６】
次に、メタデータ配信部１１３は、メタデータサーバデータベース１１２からチャンネル-BのServiceInformationメタデータ３４とチャンネル-ＣのServiceInformationメタデータ３６を読み出し、これらのServiceInformationメタデータ３４，３６をupdate Detailとして格納した更新報知メッセージ３８を作成し、ネットワーク１３０を介してIPTVクライアント端末１２０に配信する（図３５：ステップＳ１３）。
【０１４７】
IPTVクライアント端末１２０において、メタデータ受信部１２１は、ネットワーク１３０を通じてIPTVサーバ１１０より送信されてくる更新報知メッセージ３８を受信する（図３６：ステップＳ１４）。メタデータ受信部１２１は、受信した更新報知メッセージ３８にupdate Detailとして格納されたチャンネル-BのServiceInformationメタデータ３４とチャンネル-ＣのServiceInformationメタデータ３６をメタデータクライアントデータベース１２２に登録する。この際、チャンネル-BのServiceInformationメタデータ内に含まれるfragmentId属性７５の値"1234"とfragmentVersion属性７６の値"1001"がクライアント側の更新管理情報３９として格納され、チャンネル-ＣのServiceInformationメタデータ内に含まれるfragmentId属性７５の値"5678"とfragmentVersion属性７６の値"1010"がクライアント側の更新管理情報４１として格納される。
【０１４８】
この後、チャンネル-Bとチャンネル-Cとを１つのチャンネルパック-Ｄとして包含し、価格を合わせて月額６００円とする変更が発生した場合の動作は次の通りである。
【０１４９】
メタデータ生成部１１１は、上記の変更内容を反映したチャンネル-BのServiceInformationメタデータを生成する（図３５：ステップＳ１５）。この変更されたチャンネル-ＢのServiceInformationメタデータは図３２においてserviceId属性７４の値が"Channel-B"であるServiceInformation要素７２ａ以下の階層部分である。すなわち、図４１に示したように、この変更されたチャンネル-ＢのServiceInformationメタデータにおいて、fragmentId属性７５、Name要素７７の値は変更前と同じである。fragmentVersion属性７６の値は更新後に最新のバージョンを示す値に更新される。更新前に存在していたPurchaseItem要素９１は変更時に削除され、代わりに、親のServiceInformation（チャンネルパック-DのServiceInformationメタデータ）への参照を定義するためServicePackRef要素９３が追加される。
【０１５０】
続いて、この更新されたチャンネル-BのServiceInformationメタデータ３４´がメタデータサーバデータベース１１２に登録される。このときメタデータサーバデータベース１１２には、チャンネル-BのServiceInformationメタデータ３４´に含まれるfragmentId属性７５の値"1234"と、fragmentVersion属性７６の値"1011"がサーバ側の更新管理情報３５´として格納される。
【０１５１】
さらに、メタデータ生成部１１１は、上記の変更内容を反映したチャンネル-ＣのServiceInformationメタデータを生成する（図３５：ステップＳ１６）。この更新されたチャンネル-ＣのServiceInformationメタデータは図３２においてserviceId属性７４の値が"Channel-C"であるServiceInformation要素７３ａ以下の階層部分である。すなわち、図４１に示したように、この変更されたチャンネル-ＣのServiceInformationメタデータにおいて、fragmentId属性７５、Name要素７７の値は変更前の値と同じである。fragmentVersion属性７６の値は更新後に最新のバージョンを示す値に更新される。以前に存在していたPurchaseItem要素９１は変更時に削除され、代わりに、親のServiceInformation（チャンネルパック-DのServiceInformationメタデータ）への参照を定義するためServicePackRef要素９３が追加される。
【０１５２】
続いて、メタデータ生成部１１１により生成されたチャンネル-ＣのServiceInformationメタデータ３６´がメタデータサーバデータベース１１２に登録される。また、このときメタデータサーバデータベース１１２には、チャンネル-ＣのServiceInformationメタデータ３６´内に含まれるfragmentId属性７５の値"5678"と、更新されたfragmentVersion属性の値"1011"がサーバ側の更新管理情報３７´として格納される。
【０１５３】
この後、メタデータ生成部１１１は、チャンネル-Bとチャンネル-Cとを包含するチャンネルパック-ＤのServiceInformationメタデータを生成する（図３５：ステップＳ１７）。このチャンネルパック-ＤのServiceInformationメタデータは、図３２においてserviceId属性の値が"ServicePack-D"であるServiceInformation要素９２以下の階層部分である。すなわち、このチャンネルパック-ＤのServiceInformationメタデータの作成において、メタデータ生成部１１１は、serviceId属性７４の値"ServicePack-D"、fragmentId属性７５の値"1375"、fragmentVersion属性７６の値"1011"、Name要素７７、PurchaseItem要素９４を新規に生成する。
【０１５４】
続いて、メタデータ生成部１１１により生成されたチャンネルパック-ＤのServiceInformationメタデータ４２がメタデータサーバデータベース１１２に登録される。また、このときメタデータサーバデータベース１１２には、チャンネルパック-ＤのServiceInformationメタデータ４２に含まれるfragmentId属性７５の値"1375"と、fragmentVersion属性７６の値"1011"がサーバ側の更新管理情報４３として格納される。
【０１５５】
次に、メタデータ配信部１１３は、メタデータサーバデータベース１１２から、更新されたチャンネル-BのServiceInformationメタデータ３４´、更新されたチャンネル-ＣのServiceInformationメタデータ３６´、チャンネルパック-ＤのServiceInformationメタデータ４２を読み出し、これらのServiceInformationメタデータ３４´，３６´４２，をupdate Detailとして格納した更新報知メッセージ４４を作成し、ネットワーク１３０を介してIPTVクライアント端末１２０に配信する（図３５：ステップＳ１８）。
【０１５６】
IPTVクライアント端末１２０において、メタデータ受信部１２１は、ネットワーク１３０を通じてIPTVサーバ１１０より送信されてくる更新報知メッセージ４４を受信する（図３６：ステップＳ１９）。メタデータ受信部１２１は、メタデータクライアントデータベース１２２に既に登録されているチャンネル-BのServiceInformationメタデータ３４およびチャンネル-ＣのServiceInformationメタデータ３６を、更新報知メッセージ４４にupdate Detailとして格納されたチャンネル-BのServiceInformationメタデータ３４´およびチャンネル-ＣのServiceInformationメタデータ３６´でそれぞれ置き換えるとともに、更新報知メッセージ４４にupdate Detailとして格納されたチャンネルパック-ＤのServiceInformationメタデータ４２をメタデータクライアントデータベース１２２に新規に登録する。
【０１５７】
これに伴い、メタデータクライアントデータベース１２２に保存されているチャンネル-BのServiceInformationメタデータの更新管理情報３９のうちfragmentVersion属性７６の値を"1001"から"1011"に更新したものが更新管理情報３９´として保存される。さらに、メタデータクライアントデータベース１２２に保存されているチャンネル-ＣのServiceInformationメタデータの更新管理情報４１のうちfragmentVersion属性７６の値を"1010"から"1011"に更新したものが更新管理情報４１´として保存される。さらに、チャンネルパック-ＤのServiceInformationメタデータの更新管理情報４５がメタデータクライアントデータベース１２２に新規に保存される。
【０１５８】
以上のメタデータクライアントデータベース１２２の更新は、より具体的には次のようにして行われる。
【０１５９】
チャンネル-BのServiceInformationメタデータの更新を例に説明することする。メタデータ受信部１２１は、更新報知メッセージ４４にupdate Detailとして格納されたチャンネル-BのServiceInformationメタデータ３４´に含まれるfragmentId属性７５の値"1234"を取得する。メタデータ受信部１２１は、次に、このfragmentId属性７５の値とメタデータクライアントデータベース１２２に格納されている更新管理情報３９，４１とを突き合わせ、更新報知メッセージ４４から取得したチャンネル-BのServiceInformationメタデータと同じfragmentId属性７５を有するServiceInformationメタデータがメタデータクライアントデータベース１２２に保存されているかどうかを判定する。該当するServiceInformationメタデータがメタデータクライアントデータベース１２２に存在しない場合、メタデータ受信部１２１は更新報知メッセージ４４から取得したチャンネル-BのServiceInformationメタデータを新規のチャンネルのServiceInformationメタデータとして、メタデータクライアントデータベース１２２に新規に登録するとともに、更新管理情報を格納する。
【０１６０】
該当するServiceInformationメタデータがメタデータクライアントデータベース１２２に存在する場合、メタデータ受信部１２１は、両者のfragmentVersion属性７６の値を比較する。メタデータ受信部１２１は、更新報知メッセージ４４から取得したチャンネル-BのServiceInformationメタデータ３４´のバージョンの方が新しいことを判定すると、既に登録されているチャンネル-BのServiceInformationメタデータ３４を、更新報知メッセージ４４から取得したチャンネル-BのServiceInformationメタデータ３４´で置き換える。そして、メタデータ受信部１２１は、更新報知メッセージ４４から取得したチャンネル-BのServiceInformationメタデータ３４´に含まれるfragmentVersion属性７６の値"1011"で、既存の更新管理情報３９を新しい更新管理情報３９´に書き換える。
【０１６１】
この動作は、チャンネル-ＣのServiceInformationメタデータの更新を行う場合も同様である。また、チャンネルパック-ＤのServiceInformationメタデータの更新を行う場合も同様である。
【０１６２】
（第３の実施形態）
上記の第２の実施形態では、更新報知メッセージのupdateDetailに更新されたServiceInformationメタデータを格納して、IPTVクライアント端末１２０にメタデータの更新を報知することとしたが、ServiceInformationメタデータを配信する別の方法として次のようなものがある。例えば、更新報知メッセージのupdateDetailに、ServiceInformationメタデータそのものではなくServiceInformationメタデータを対象とするクエリー（データベースに対する検索要求文）を格納してIPTVクライアント端末１２０にメタデータの更新を報知するようにしてもよい。この場合、IPTVクライアント端末１２０は、そのクエリーを用いた検索要求をIPTVサーバ１１０に送信することで、ServiceInformationメタデータを取得することができる。以下、これを第３の実施形態として説明する。
【０１６３】
図３７は第３の実施形態のIPTVシステム１００の構成を示す図である。同図に示すように、このIPTVシステム１００は、第２の実施形態に比較して、IPTVサーバ１１０にメタデータクエリー処理部１１５が追加された点で異なる。メタデータクエリー処理部１１５は、IPTVクライアント端末１２０より受信したクエリー要求をもとにメタデータサーバデータベース１１２から該当するServiceInformationメタデータを検索し、IPTVクライアント端末１２０に応答する処理を行うものである。
【０１６４】
次に、図３８のフローチャートを参照して、IPTVサーバ１１０からIPTVクライアント端末１２０へのServiceInformationメタデータのクエリーを用いた配信処理と更新処理について説明する。
【０１６５】
まず、IPTVサーバ１１０において、メタデータ生成部１１１は、放送チャンネルの ServiceInformationメタデータを生成する（ステップＳ２１）。生成された放送チャンネルの ServiceInformationメタデータはメタデータサーバデータベース１１２に保存される。
【０１６６】
メタデータ配信部１１３は、メタデータサーバデータベース１１２に保存されたServiceInformationメタデータを対象とするクエリーの生成に続いて、このクエリーを含む更新報知メッセージを生成し（ステップＳ２２）、この更新報知メッセージをネットワーク１３０を介してIPTVクライアント端末１２０に配信する（ステップＳ２３）。
【０１６７】
IPTVクライアント端末１２０内のメタデータ受信部１２１は、ネットワーク１３０を介してIPTVサーバ１１０から伝送されてくる更新報知メッセージを受信し（ステップＳ２４）、受信した更新報知メッセージに含まれるクエリーを抽出する（ステップＳ２５）。次に、メタデータ受信部１２１は、抽出したクエリーを含むメタデータ検索要求をIPTVサーバ１１０に送信する（ステップＳ２５）。
【０１６８】
IPTVクライアント端末１２０から送信されたメタデータ検索要求はメタデータクエリー処理部１１５にて受信される。メタデータクエリー処理部１１５は、このメタデータ検索要求に含まれるクエリーをメタデータサーバデータベース１１２に送信し、メタデータサーバデータベース１１２から、該当するServiceInformationメタデータを取得する（ステップＳ２６）。メタデータクエリー処理部１１５は、この取得したServiceInformationメタデータをメタデータ検索要求に対する応答としてIPTVクライアント端末１２０に配信する（ステップＳ２７）。
【０１６９】
IPTVクライアント端末１２０内のメタデータ受信部１２１は、メタデータ検索要求に対する応答であるServiceInformationメタデータを取得すると、これをメタデータクライアントデータベース１２２に登録する（ステップＳ２８）。
【０１７０】
IPTVサーバ１１０内のメタデータ生成部１１１により、更新されたServiceInformationメタデータが生成された場合（ステップＳ２９）、この更新されたServiceInformationメタデータはメタデータサーバデータベース１１２に保存される。
【０１７１】
メタデータ配信部１１３は、メタデータサーバデータベース１１２に保存された、更新されたServiceInformationメタデータを対象とするクエリーの生成に続いて、このクエリーを含む更新報知メッセージを生成し（ステップＳ３０）、この更新報知メッセージをネットワーク１３０を介してIPTVクライアント端末１２０に配信する（ステップＳ３１）。
【０１７２】
IPTVクライアント端末１２０内のメタデータ受信部１２１は、ネットワーク１３０を介してIPTVサーバ１１０から伝送されてくる更新報知メッセージを受信し、受信した更新報知メッセージに含まれるクエリーを抽出する（ステップＳ３２）。次に、メタデータ受信部１２１は、抽出したクエリーを含むメタデータ検索要求をIPTVサーバ１１０に送信する（ステップＳ３３）。
【０１７３】
IPTVクライアント端末１２０から送信されたメタデータ検索要求はメタデータクエリー処理部１１５にて受信される。メタデータクエリー処理部１１５は、このメタデータ検索要求に含まれるクエリーをメタデータサーバデータベース１１２に送信し、メタデータサーバデータベース１１２から、更新されたServiceInformationメタデータを取得する（ステップＳ３４）。メタデータクエリー処理部１１５は、この取得したServiceInformationメタデータをメタデータ検索要求に対する応答としてIPTVクライアント端末１２０に配信する（ステップＳ３５）。
【０１７４】
IPTVクライアント端末１２０内のメタデータ受信部１２１は、メタデータ検索要求に対する応答である、更新されたServiceInformationメタデータを取得すると、メタデータクライアントデータベース１２２に登録されているServiceInformationメタデータの中で、取得したServiceInformationメタデータに対してfragmentIDが一致するServiceInformationメタデータを検索し、この既存のServiceInformationメタデータを、取得したServiceInformationメタデータで更新する（ステップＳ３６）。
【０１７５】
次に、上記ServiceInformationメタデータの配信と更新の処理を、図３９および図４０に示した更新前後のServiceInformationメタデータを例に、より詳細に説明する。
【０１７６】
図３９はIPTVサーバ１１０での処理のシーケンス、図４０はIPTVクライアント端末１２０での処理シーケンスである。
【０１７７】
まず、メタデータ生成部１１１は、チャンネル-BのServiceInformationメタデータを生成する（図３９：ステップＳ４１）。このチャンネル-BのServiceInformationメタデータは図３１においてserviceId属性７４の値が"Channel-B"であるServiceInformation要素７２以下の階層部分である。続いて、メタデータ生成部１１１により生成されたチャンネル-BのServiceInformationメタデータ３４がメタデータサーバデータベース１１２に登録される。また、このときメタデータサーバデータベース１１２には、チャンネル-BのServiceInformationメタデータ内に含まれるfragmentId属性７５の値"1234"とfragmentVersion属性７６の値"1001"が更新管理情報３５として格納される。
【０１７８】
さらに、メタデータ生成部１１１は、チャンネル-ＣのServiceInformationメタデータを生成する（図３９：ステップＳ４２）。このチャンネル-ＣのServiceInformationメタデータは図３１においてserviceId属性７４の値が"Channel-C"であるServiceInformation要素７３以下の階層部分である。続いて、メタデータ生成部１１１により生成されたチャンネル-ＣのServiceInformationメタデータ３６がメタデータサーバデータベース１１２に登録される。また、このときメタデータサーバデータベース１１２には、チャンネル-ＣのServiceInformationメタデータ内に含まれるfragmentId属性７５の値"5678"とfragmentVersion属性７６の値"1010"が更新管理情報３７として格納される。
【０１７９】
次に、メタデータ配信部１１３は、メタデータサーバデータベース１１２からチャンネル-BのServiceInformationメタデータ３４とチャンネル-ＣのServiceInformationメタデータ３６を対象とするクエリーを生成し、これらのクエリーをupdate Detailとして格納した更新報知メッセージ３８ａを作成し、この更新報知メッセージ３８ａをネットワーク１３０を介してIPTVクライアント端末１２０に配信する（図３９：ステップＳ４３）。
【０１８０】
IPTVクライアント端末１２０において、メタデータ受信部１２１は、ネットワーク１３０を通じてIPTVサーバ１１０より送信されてくる更新報知メッセージ３８ａを受信する（図４０：ステップＳ４４）。メタデータ受信部１２１は、受信した更新報知メッセージ３８ａにupdate Detailとして格納された各クエリーを抽出し、これらのクエリーを含むメタデータ検索要求をIPTVサーバ１１０に送信する（図４０：ステップＳ４５）。
【０１８１】
IPTVクライアント端末１２０から送信されたメタデータ検索要求はメタデータクエリー処理部１１５にて受信される。メタデータクエリー処理部１１５は、このメタデータ検索要求に含まれる各クエリーをメタデータサーバデータベース１１２に送信し、メタデータサーバデータベース１１２から、チャンネル-BのServiceInformationメタデータ３４とチャンネル-ＣのServiceInformationメタデータ３６をそれぞれ取得する。メタデータクエリー処理部１１５は、取得したチャンネル-BのServiceInformationメタデータ３４とチャンネル-ＣのServiceInformationメタデータ３６をメタデータ検索要求に対する応答としてIPTVクライアント端末１２０に配信する。
【０１８２】
IPTVクライアント端末１２０において、メタデータ受信部１２１は、メタデータ検索要求に対する応答としてチャンネル-BのServiceInformationメタデータ３４とチャンネル-ＣのServiceInformationメタデータ３６を受信すると（図４０：ステップＳ４６）、これらのServiceInformationメタデータ３４，３６をメタデータクライアントデータベース１２２に登録する。この際、チャンネル-BのServiceInformationメタデータ内に含まれるfragmentId属性７５の値"1234"とfragmentVersion属性７６の値"1001"がクライアント側の更新管理情報３９として格納され、チャンネル-ＣのServiceInformationメタデータ内に含まれるfragmentId属性７５の値"5678"とfragmentVersion属性７６の値"1010"がクライアント側の更新管理情報４１として格納される。
【０１８３】
この後、チャンネル-Bとチャンネル-Cとを１つのチャンネルパック-Ｄとして包含し、価格を合わせて月額６００円とする変更が発生した場合の動作は次の通りである。
【０１８４】
メタデータ生成部１１１は、上記の変更内容を反映したチャンネル-BのServiceInformationメタデータを生成する（図３９：ステップＳ４７）。この変更されたチャンネル-ＢのServiceInformationメタデータは図３２においてserviceId属性７４の値が"Channel-B"であるServiceInformation要素７２ａ以下の階層部分である。すなわち、図４１に示したように、この変更されたチャンネル-ＢのServiceInformationメタデータにおいて、fragmentId属性７５、Name要素７７の値は変更前の値と同じである。fragmentVersion属性７６の値は更新後に最新のバージョンを示す値に更新される。以前に存在していたPurchaseItem要素９１は変更時に削除され、代わりに、親のServiceInformation（チャンネルパック-DのServiceInformationメタデータ）への参照を定義するためServicePackRef要素９３が追加される。
【０１８５】
続いて、この更新されたチャンネル-BのServiceInformationメタデータ３４´がメタデータサーバデータベース１１２に登録される。このときメタデータサーバデータベース１１２には、チャンネル-BのServiceInformationメタデータ３４´に含まれるfragmentId属性７５の値"1234"と、fragmentVersion属性７６の値"1011"がサーバ側の更新管理情報３５´として格納される。
【０１８６】
さらに、メタデータ生成部１１１は、上記の変更内容を反映したチャンネル-ＣのServiceInformationメタデータを生成する（図３９：ステップＳ４８）。この変更されたチャンネル-ＣのServiceInformationメタデータは図３２においてserviceId属性７４の値が"Channel-C"であるServiceInformation要素７３ａ以下の階層部分である。すなわち、図４１に示したように、この変更されたチャンネル-ＣのServiceInformationメタデータにおいて、fragmentId属性７５、Name要素７７の値は変更前の値と同じである。fragmentVersion属性７６の値は更新後に最新のバージョンを示す値に更新される。以前に存在していたPurchaseItem要素９１は変更時に削除され、代わりに、親のServiceInformation（チャンネルパック-DのServiceInformationメタデータ）への参照を定義するためServicePackRef要素９３が追加される。
【０１８７】
続いて、メタデータ生成部１１１により生成されたチャンネル-ＣのServiceInformationメタデータ３６´がメタデータサーバデータベース１１２に登録される。また、このときメタデータサーバデータベース１１２には、チャンネル-ＣのServiceInformationメタデータ３６´内に含まれるfragmentId属性７５の値"5678"と、更新されたfragmentVersion属性７６の値"1011"がサーバ側の更新管理情報３７´として格納される。
【０１８８】
この後、メタデータ生成部１１１は、チャンネル-Bとチャンネル-Cとを包含するチャンネルパック-ＤのServiceInformationメタデータを生成する（図３９：ステップＳ４９）。このチャンネルパック-ＤのServiceInformationメタデータは、図３２においてserviceId属性７４の値が"ServicePack-D"であるServiceInformation要素９２以下の階層部分である。すなわち、このチャンネルパック-ＤのServiceInformationメタデータの作成において、メタデータ生成部１１１は、serviceId属性７４の値"ServicePack-D"、fragmentId属性７５の値"1375"、fragmentVersion属性７６の値"1011"、Name要素７７、PurchaseItem要素９４を新規に生成する。
【０１８９】
続いて、メタデータ生成部１１１により生成されたチャンネルパック-ＤのServiceInformationメタデータ４２がメタデータサーバデータベース１１２に登録される。また、このときメタデータサーバデータベース１１２には、チャンネルパック-ＤのServiceInformationメタデータ４２に含まれるfragmentId属性７５の値"1375"と、fragmentVersion属性７６の値"1011"がサーバ側の更新管理情報４３として格納される。
【０１９０】
次に、メタデータ配信部１１３は、メタデータサーバデータベース１１２に保存された、更新されたチャンネル-BのServiceInformationメタデータ３４´を対象とするクエリー、更新されたチャンネル-ＣのServiceInformationメタデータ３６´を対象とするクエリー、チャンネルパック-ＤのServiceInformationメタデータ４２を対象とするクエリーをそれぞれ生成し、これらのクエリーをupdate Detailとして格納した更新報知メッセージ４４ａを作成し、この更新報知メッセージ４４ａをネットワーク１３０を介してIPTVクライアント端末１２０に配信する（図３９：ステップＳ５０）。
【０１９１】
IPTVクライアント端末１２０において、メタデータ受信部１２１は、ネットワーク１３０を通じてIPTVサーバ１１０より送信されてくる更新報知メッセージ４４ａを受信する（ステップＳ５１）。メタデータ受信部１２１は、受信した更新報知メッセージ４４ａにupdate Detailとして格納された各クエリーを抽出し、これらのクエリーを含むメタデータ検索要求をIPTVサーバ１１０に送信する（図４０：ステップＳ５２）。
【０１９２】
IPTVクライアント端末１２０から送信されたメタデータ検索要求はメタデータクエリー処理部１１５にて受信される。メタデータクエリー処理部１１５は、このメタデータ検索要求に含まれる各クエリーをメタデータサーバデータベース１１２に送信し、メタデータサーバデータベース１１２から、更新されたチャンネル-BのServiceInformationメタデータ３４´、更新されたチャンネル-ＣのServiceInformationメタデータ３６´、チャンネルパック-ＤのServiceInformationメタデータ４２を取得する。メタデータクエリー処理部１１５は、取得した各ServiceInformationメタデータ３４´，３６´，４２をメタデータ検索要求に対する応答としてIPTVクライアント端末１２０に送信する。
【０１９３】
IPTVクライアント端末１２０において、メタデータ受信部１２１は、メタデータ検索要求に対する応答として、更新されたチャンネル-BのServiceInformationメタデータ３４´、更新されたチャンネル-ＣのServiceInformationメタデータ３６´、チャンネルパック-ＤのServiceInformationメタデータ４２を受信すると（図４０：ステップＳ５３）、メタデータクライアントデータベース１２２に既に登録されているチャンネル-BのServiceInformationメタデータ３４およびチャンネル-ＣのServiceInformationメタデータ３６を、受信したチャンネル-Bおよびチャンネル-ＣのServiceInformationメタデータ３４´，３６´でそれぞれ置き換えるとともに、受信したチャンネルパック-ＤのServiceInformationメタデータ４２をメタデータクライアントデータベース１２２に新規に登録する。
【０１９４】
これに伴い、メタデータクライアントデータベース１２２に保存されているチャンネル-BのServiceInformationメタデータの更新管理情報３９のうちfragmentVersion属性７６の値を"1001"から"1011"に更新したものが更新管理情報３９´として保存される。さらに、メタデータクライアントデータベース１２２に保存されているチャンネル-ＣのServiceInformationメタデータの更新管理情報４１のうちfragmentVersion属性７６の値を"1010"から"1011"に更新したものが更新管理情報４１´として保存される。さらに、チャンネルパック-ＤのServiceInformationメタデータの更新管理情報４５がメタデータクライアントデータベース１２２に新規に保存される。
【０１９５】
（第２の実施形態の変形例２）
第２の実施形態では、ServiceInformationにおいて、複数の放送チャンネルを包含したチャンネルパックの構成を記述するためにPurchaseItem要素、ServicePackRef要素を新たに導入することとしたが、次のようにしても同様の構成を記述することが可能である。
【０１９６】
図４２はチャンネルパックの構成をServiceInformationメタデータではなく、GroupInformationメタデータで置き換えた場合の例を示す図である。
【０１９７】
GroupInformationは、本来、複数のProgramInformationにより記述されるプログラム（コンテンツ）をグループ化してそのグループの属性を記述する場合に用いたり、もしくは、プログラムのグループを記述するGroupInformationを複数まとめてグループを作り、このようなグループに関する情報を記述するために設計されたものである。GroupInformationには、価格に関する情報を記述するためのPurchaseItem要素がもともと含まれているため、このGroupInformationを用いれば、ServiceInformationを用いた場合のようにPurchaseItem要素を新たに導入する必要がなくなる。そこで、チャンネルパックの構成の記述にGroupInformationを用いることができる。ただし、TV-AnytimeにおけるGroupInformationの定義に従うと、GroupInformationの子は、通常はProgramInformationもしくはGroupInformationである。これらは、自分の親のGroupInformationを参照するポインタを格納する要素としてmemberOf要素（ProgramInformation/memberOfやGroupInformation/memberOf）を持っている。そこで、放送チャンネルのメタデータにはServiceInformationを採用し、親となるチャンネルパックのGroupInformationメタデータへの参照をmemberOf要素の値として記述するようにすることによって、複数の放送チャンネルを包含したチャンネルパックの構成を第２の実施形態と同様に記述することができる。
【０１９８】
図４３は図３２と等価なメタデータをGroupInformationメタデータを用いて記述した場合の具体例を示す図である。
【０１９９】
同図に示すように、変更後のServiceInformationメタデータにはServiceInformationTable要素７１ａとGroupInformationTable要素９７とが含まれている。このServiceInformationTable要素７１ａには、複数の放送チャンネルそれぞれのServiceInformation要素７２ａ，７３ａが含まれている。各々の放送チャンネルのServiceInformation要素７２ａ，７３ａには、サービスを識別するserviceId属性７４、フラグメントを識別するfragmentId属性７５、フラグメントのバージョンを示すfragmentVersion属性７６、放送チャンネルの名前が記述されるName要素７７、そしてmemberOf要素９３が含まれている。
【０２００】
一方、GroupInformationTable要素９７にはGroupInformation要素９８が含まれている。GroupInformation要素９８には、グループを識別するgroupId属性１５１、フラグメントを識別するfragmentId属性１５２、フラグメントのバージョンを示すfragmentVersion属性１５３、グループのタイプが記述されるGroupType要素９９、BasicDescription要素１４１が含まれている。BasicDescription要素１４１にはPurchaseList要素１４２が含まれている。PurchaseList要素１４２にはPurchaseItem要素１４２が含まれている。PurchaseItem要素１４２には、価格が記述されるPrice要素１４３と、例えば月額であるなどの価格に関する情報が記述されるPurchase要素１４４が含まれている。
【０２０１】
本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々更新を加え得ることは勿論である。
【図面の簡単な説明】
【０２０２】
【図１】本発明の実施の形態にかかるコンテンツもしくはコンテンツのメタデータの更新報知配信方式のモデルを示す図である。
【図２】更新報知メッセージのフォーマットを定義するXMLスキーマの例を示す図である。
【図３】SNS-Xサイトのカテゴリ階層の例を示す図である。
【図４】全体更新と差分更新を併用した更新処理のシーケンス図である。
【図５】データ同期を行う場合のサブスクライバの処理シーケンスを示す図である。
【図６】一方向ネットワークしか利用できない環境下でデータ同期を行う場合のサブスクライバの処理シーケンスを示す図である。
【図７】サービスクライアントでの更新処理の時刻制御に関するフローチャートである。
【図８】transactionId=01(初期状態)の全体更新報知メッセージと、この全体更新情報を反映したデータおよびそのモデルを示す図である。
【図９】transactionId=02の差分更新報知メッセージと、この差分更新を反映したデータとそのモデルを示す図である。
【図１０】transactionId=03の差分更新報知メッセージと、この差分更新を反映したデータとそのモデルを示す図である。
【図１１】transactionId=04の差分更新報知メッセージと、この差分更新を反映したデータおよびそのモデルを示す図である。
【図１２】transactionId=04の全体更新報知メッセージと、この全体更新を反映したデータおよびそのモデルを示す図である。
【図１３】本発明の実施形態であるネッワークシステムの構成を示すブロック図である。
【図１４】サービスプロバイダの構成を示す図である。
【図１５】サービスプロバイダの処理シーケンス図である。
【図１６】SNSカテゴリアグリゲータとSNSサイトの構成を示す図である。
【図１７】SNSカテゴリアグリゲータによるSNSサイトのカテゴリデータベースからのカテゴリの収集の処理シーケンス図である。
【図１８】ホームネットワーク側の機器の構成を示す図である。
【図１９】ホームネットワーク側の機器の処理シーケンスを示す図である。
【図２０】複数のサービスプロバイダと複数のサービスクライアントとの間での更新報知メッセージの通知の例を示す図である。
【図２１】更新報知メッセージ内の更新情報への参照をもとにしたコンテンツ／メタデータの更新処理のための構成を示す図である。
【図２２】更新報知メッセージ内の更新情報への参照をもとにしたコンテンツ／メタデータの更新処理のシーケンス図である。
【図２３】サービスクライアントのローカルコンテンツ／メタデータデータベースに障害が発生した場合の障害回復処理のための構成を示す図である。
【図２４】その障害回復処理のシーケンス図である。
【図２５】携帯電話上に実装されるサービスクライアントがゲームデバイスに格納されているコンテンツやメタデータの更新処理を代行する形態における更新シーケンスを示す図である。
【図２６】サービスプロバイダを実現するハードウェアの構成を示す図である。
【図２７】サブスクライバあるいはサービスクライアントを実装したネットワーク家電機器のハードウェア構成を示すブロック図である。
【図２８】コンテンツ／メタデータの同期管理における不整合の問題に関する図である。
【図２９】TV-Ａnytimeメタデータのフラグメントとして、放送チャンネルのサービスに関する情報を記述したService Informationメタデータの例である。
【図３０】複数の放送チャンネルを１つにまとめて価格を変更した場合のServiceInformationメタデータの例である。
【図３１】更新前のServiceInformationメタデータの例を示す図である。
【図３２】図３１に対して更新後のServiceInformationメタデータの例を示す図である。
【図３３】第２の実施形態のIPTVシステムの構成を示す図である。
【図３４】第２の実施形態のIPTVシステムにおいて、IPTVサーバからIPTVクライアント端末へのServiceInformationメタデータの配信と更新の処理を示すシーケンス図である。
【図３５】図３４においてIPTVサーバの処理の具体例を示すシーケンス図である。
【図３６】図３４においてIPTVクライアント端末の処理の具体例を示すシーケンス図である。
【図３７】第３の実施形態のIPTVシステムの構成を示す図である。
【図３８】第３の実施形態のIPTVシステムにおいて、IPTVサーバからIPTVクライアント端末へのServiceInformationメタデータの配信と更新の処理を示すシーケンス図である。
【図３９】図３８においてIPTVサーバの処理の具体例を示すシーケンス図である。
【図４０】図３４においてIPTVクライアント端末の処理の具体例を示すシーケンス図である。
【図４１】図３０に示したServiceInformationメタデータの更新処理を説明するための図である。
【図４２】チャンネルパックの構成をGroupInformationメタデータで置き換えた場合のServiceInformationメタデータの例を示す図である。
【図４３】図３２と等価なメタデータをGroupInformationメタデータを用いて記述した場合の具体例を示す図である。
【図４４】更新報知メッセージのデータ構造を示す図である。
【符号の説明】
【０２０３】
１      更新報知メッセージ
１０Ａ，１０Ｂ，１０Ｃ    パブリッシャ
１１    コンテンツ／メタデータ管理サーバ
１２    コンテンツ／メタデータ管理サーバ
１３    更新報知ジェネレータ
２０Ａ，２０Ｂ，２０Ｃ    キュー／チャネル
２１    フィルタマネジャ
２２    更新報知メッセージデータベース
２３    SNSカテゴリアグリゲータ
２４    メッセージ配布サーバ
２５    データベース同期情報提供サーバ
３０    サブスクライバ
３１    メッセージ配布クライアント
３２    レジデンシャルメッセージデータベース
３３    レジデンシャルメッセージ配布サーバ
４０Ａ，４０Ｂ，４０Ｃ    サービスプロバイダ
５０    ホームネットワーク側の機器
６０ａ，６０ｂ，６０ｃ    サービスクライアント
６１ａ，６１ｂ，６１ｃ    ローカルコンテンツ／メタデータデータベース
７０    ホームネットワーク
８０    SNSサイト
９０    ネットワーク
１００    ネットワークシステム
１１０    ゲームデバイス
１２０    携帯電話
【図１】
0005298626.tif 000002
【図２】
0005298626.tif 000003
【図３】
0005298626.tif 000004
【図４】
0005298626.tif 000005
【図５】
0005298626.tif 000006
【図６】
0005298626.tif 000007
【図７】
0005298626.tif 000008
【図８】
0005298626.tif 000009
【図９】
0005298626.tif 000010
【図１０】
0005298626.tif 000011
【図１１】
0005298626.tif 000012
【図１２】
0005298626.tif 000013
【図１３】
0005298626.tif 000014
【図１４】
0005298626.tif 000015
【図１５】
0005298626.tif 000016
【図１６】
0005298626.tif 000017
【図１７】
0005298626.tif 000018
【図１８】
0005298626.tif 000019
【図１９】
0005298626.tif 000020
【図２０】
0005298626.tif 000021
【図２１】
0005298626.tif 000022
【図２２】
0005298626.tif 000023
【図２３】
0005298626.tif 000024
【図２４】
0005298626.tif 000025
【図２５】
0005298626.tif 000026
【図２６】
0005298626.tif 000027
【図２７】
0005298626.tif 000028
【図２８】
0005298626.tif 000029
【図２９】
0005298626.tif 000030
【図３０】
0005298626.tif 000031
【図３１】
0005298626.tif 000032
【図３２】
0005298626.tif 000033
【図３３】
0005298626.tif 000034
【図３４】
0005298626.tif 000035
【図３５】
0005298626.tif 000036
【図３６】
0005298626.tif 000037
【図３７】
0005298626.tif 000038
【図３８】
0005298626.tif 000039
【図３９】
0005298626.tif 000040
【図４０】
0005298626.tif 000041
【図４１】
0005298626.tif 000042
【図４２】
0005298626.tif 000043
【図４３】
0005298626.tif 000044
【図４４】
0005298626.tif 000045