(57)【特許請求の範囲】
【請求項１】
コンテンツ・ディレクトリ・サービスを提供する送信側のＵＰｎＰデバイス及び受信側のＵＰｎＰデバイスの間においてコンテンツを同期化させる際にリソースの重複保存を防止するための方法において、
（ａ）前記受信側のＵＰｎＰデバイスが、前記送信側のＵＰｎＰデバイスから、変更されたリソースに固有のリソース識別子と変更されたリソースについてのメタデータとが少なくとも含まれている変更ログを受信する段階と、
（ｂ１）前記リソース識別子と受信した送信側のＵＰｎＰデバイスの経路情報とを前記変更ログから読み出し、前記リソース識別子及び前記経路情報から、同一のリソースが存在するか否かを判断する段階と、
（ｂ２）前記判断の結果、前記リソース識別子と前記経路情報が示す保存経路とが同一であるリソースが存在する場合、前記変更されたリソースの保存経路として、前記受信側のＵＰｎＰデバイスで既に設定されている保存経路を指定する一方、前記リソース識別子は同一であるが保存経路は異なる場合、前記変更されたリソースの保存経路として、前記送信側のＵＰｎＰデバイスで設定された保存経路を指定する段階と
（ｃ）前記受信側のＵＰｎＰデバイスで前記変更されたリソースを受信し、前記指定された保存経路によって保存する段階と
を含むことを特徴とする方法。
【請求項２】
前記方法は、
前記段階（ｂ２）の後に、前記送信側のＵＰｎＰが前記保存経路によるメタデータを生成する段階をさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記（ｂ２）段階は、
前記判断の結果、前記リソース識別子が異なっていた場合、変更されたリソースを保存する新しい保存経路を指定する段階をさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記リソース識別子は、
変更されたリソースに対してハッシュ関数を利用して生成されることを特徴とする請求項１に記載の方法。
【請求項５】
前記リソースの変更は、
前記リソースの追加、修正、削除、保存経路のうち、少なくともいずれか一つであることを特徴とする請求項１に記載の方法。
【請求項６】
コンテンツ・ディレクトリ・サービスを提供する送信側のＵＰｎＰデバイス及び受信側のＵＰｎＰデバイスの間においてコンテンツを同期化させる際にリソースの重複保存を防止するための方法をコンピュータに実行させる命令を保存するコンピュータで読取可能な記録媒体において、前記方法は、
（ａ）前記受信側のＵＰｎＰデバイスが、前記送信側のＵＰｎＰデバイスから、変更されたリソースに固有のリソース識別子と変更されたリソースについてのメタデータとが少なくとも含まれている変更ログを受信する段階と、
（ｂ１）前記リソース識別子と受信した送信側のＵＰｎＰデバイスの経路情報とを前記変更ログから読み出し、前記リソース識別子及び前記経路情報から、同一のリソースが存在するか否かを判断する段階と、
（ｂ２）前記判断の結果、前記リソース識別子と前記経路情報が示す保存経路とが同一であるリソースが存在する場合、前記変更されたリソースの保存経路として、前記受信側のＵＰｎＰデバイスで既に設定されている保存経路を指定する一方、前記リソース識別子は同一であるが保存経路は異なる場合、前記変更されたリソースの保存経路として、前記送信側のＵＰｎＰデバイスで設定された保存経路を指定する段階と
（ｃ）前記受信側のＵＰｎＰデバイスで前記変更されたリソースを受信し、前記指定された保存経路によって保存する段階と
を含むことを特徴とするコンピュータで読み取り可能な記録媒体。
【請求項７】
コンテンツ・ディレクトリ・サービスを提供する送信側のＵＰｎＰデバイス及び受信側のＵＰｎＰデバイスの間においてコンテンツを同期化させる際にリソースの重複保存を防止するための装置において、
（ａ）前記受信側のＵＰｎＰデバイスが、前記送信側のＵＰｎＰデバイスから、変更されたリソースに固有のリソース識別子と変更されたリソースについてのメタデータとが少なくとも含まれている変更ログを受信する手段と、
（ｂ１）前記リソース識別子と受信した送信側のＵＰｎＰデバイスの経路情報とを前記変更ログから読み出し、前記リソース識別子及び前記経路情報から、同一のリソースが存在するか否かを判断する手段と、
（ｂ２）前記判断の結果、前記リソース識別子と前記経路情報が示す保存経路とが同一であるリソースが存在する場合、前記変更されたリソースの保存経路として、前記受信側のＵＰｎＰデバイスで既に設定されている保存経路を指定する一方、前記リソース識別子は同一であるが保存経路は異なる場合、前記変更されたリソースの保存経路として、前記送信側のＵＰｎＰデバイスで設定された保存経路を指定する手段と、
（ｃ）前記受信側のＵＰｎＰデバイスで前記変更されたリソースを受信し、前記指定された保存経路によって保存する手段と
を含むことを特徴とする装置。
【請求項８】
前記リソース管理部は、
前記変更されたリソースの保存経路によるメタデータを生成することを特徴とする請求項７に記載の装置。
【請求項９】
前記リソース管理部は、
前記判断の結果、前記リソース識別子が異なる場合、前記変更されたリソースを保存する新しい保存経路を指定することを特徴とする請求項７に記載の装置。
【請求項１０】
前記リソース識別子は、
変更されたリソースに対してハッシュ関数を利用して生成されることを特徴とする請求項７に記載の装置。
【請求項１１】
前記リソースの変更は、
前記リソースの追加、修正、削除、保存経路のうち、少なくともいずれか一つであることを特徴とする請求項７に記載のリソースの重複保存防止装置。
【請求項１２】
前記リソース管理部によって保存された前記変更されたリソースを保存するコンテンツ・データベースをさらに含むことを特徴とする請求項７に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ホームネットワークに係り、さらに詳細には、コンテンツ同期化時にコンテンツ・ディレクトリ・サービスを提供するＵＰｎＰデバイス間のリソース重複保存を防止するための方法及び装置に関する。
【背景技術】
【０００２】
ＵＰｎＰ（Universal  Plug  and  Play）技術は、ネットワークに連結されたデバイス間で複雑な設定手順なしにも通信を可能にする技術であり、１つのデバイスが提供するサービスを他のデバイスが自動的に検索できるようにする。従って、ユーザがデバイスをＵＰｎＰネットワークに連結しさえすれば、ネットワークに連結された任意のデバイスで提供するサービスを容易に利用できる。
【０００３】
図１は、コンテンツ・ディレクトリ・サービスを提供するＵＰｎＰデバイス間でコンテンツを同期化する方法について簡略に説明するための概念図である。図１を参照するに、ユーザは、コントロール・ポイント１００を利用し、同期化を行うことを望むデバイスを選択し、当該デバイスがそれぞれ提供するコンテンツ・ディレクトリ・サービス１０１，１０２を利用し、デバイス間でリソースを伝送することによって、コンテンツ同期化を行う。
【０００４】
前記コンテンツ・ディレクトリ・サービスを介して提供される情報は、アイテムに係るメタデータであり、前記メタデータには、リソースの保存経路を含む。例えば、自身が好んで聞くリソース、すなわちＭＰＥＧ−１オーディオレイヤ（ＭＰ３）という音楽ファイルが音楽ファイル目録に含まれると同時に、ミュージシャン別の目録に含まれており、ＭＰ３というリソースの保存経路は同一であると仮定する。この場合、関連技術によるコンテンツ同期化過程によれば、受信側のコンテンツ・ディレクトリ・サービスは、音楽ファイル目録に含まれた経路と、ミュージシャン別目録に含まれた経路とに保存されたＭＰ３リソースをそれぞれ受信し、受信されたリソースをそれぞれ新しい経路に保存する。従って、送信側のデバイスで１つのリソースとして管理されたリソースが、受信側デバイスでは重複保存される問題点がある。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の実施形態は、前記のような問題点及び前述されていない問題点を解決する。また、本発明は、前記のような問題点を克服することを要求せずに、前記の問題点のいかなるものも克服しない本発明の実施形態もある。
【０００６】
本発明は、コンテンツ・ディレクトリ・サービスを提供するデバイス間でコンテンツを同期化するとき、リソース識別子及び／または保存経路を考慮することによって、同一のリソースが重複保存されることを防止する方法及び装置を提供する。
【課題を解決するための手段】
【０００７】
本発明の第１実施形態によれば、コンテンツ・ディレクトリ・サービスを提供する送信側のＵＰｎＰデバイス及び受信側のＵＰｎＰデバイス間のコンテンツ同期化時に、リソースの重複保存を防止するための方法は、（ａ）前記送信側のＵＰｎＰデバイスから変更されたリソースについてのメタデータが含まれた変更ログを受信する段階と、（ｂ）前記受信された変更ログに基づいて、前記変更されたリソースの重複いかんを判断し、前記判断結果によって保存経路を指定する段階と、（ｃ）前記受信側のＵＰｎＰデバイスで前記変更されたリソースを受信し、前記指定された保存経路によって保存する段階とを含み、前記保存経路は、前記送信側のＵＰｎＰデバイス、または前記受信側のＵＰｎＰデバイスのうち、いずれか一つによって与えられることを特徴とする。
【０００８】
本発明の第２実施形態によれば、前記方法を実行させるためのプログラムを記録したコンピュータで読み取り可能な記録媒体が提供される。
【０００９】
本発明の第３実施形態によれば、コンテンツ・ディレクトリ・サービスを提供する送信側のＵＰｎＰデバイス及び受信側のＵＰｎＰデバイス間のコンテンツ同期化時に、リソースの重複保存を防止するための装置が提供されるが、前記装置は、送信側のＵＰｎＰデバイスから変更されたリソースについてのメタデータが含まれた変更ログと変更されたリソースとを受信する変更ログ／リソース受信部と、リソースに対して固有なリソース識別子と、前記リソース識別子に対応した保存経路とを保存するリソース識別子−経路マッピング部と、前記受信された変更ログに基づいて、前記変更されたリソースの重複いかんを判断し、前記判断結果によって保存経路を指定し、前記変更されたリソースを前記指定された保存経路によって保存するリソース管理部とを備え、前記保存経路は、前記送信側のＵＰｎＰデバイス、または前記受信側のＵＰｎＰデバイスのうち、いずれか一つによって与えられることを特徴とする。
【００１０】
本発明の第４実施形態によれば、コンテンツ・ディレクトリ・サービスを提供する送信側のＵＰｎＰデバイス及び受信側のＵＰｎＰデバイス間のコンテンツ同期化時に、リソースの重複保存を防止するための方法が提供されるが、前記方法は、（ａ）前記送信側のＵＰｎＰデバイスのリソースが変更されたことを感知する段階と、（ｂ）前記変更されたリソースについてのメタデータが含まれた変更ログを生成する段階と、（ｃ）前記生成された変更ログをＵＰｎＰネットワークを介して受信側のＵＰｎＰデバイスに伝送する段階とを含み、前記変更ログは、前記変更されたリソースに固有なリソース識別子と、前記変更されたリソース保存経路の変更いかんについての情報とを含むことを特徴とする。
【００１１】
本発明の第５実施形態によれば、前記方法を実行させるためのプログラムを記録したコンピュータで読み取り可能な記録媒体が提供される。
【００１２】
本発明の第６実施形態によれば、コンテンツ・ディレクトリ・サービスを提供する送信側のＵＰｎＰデバイス及び受信側のＵＰｎＰデバイス間のコンテンツ同期化時に、リソースの重複保存を防止するための装置が提供されるが、前記装置は、リソースが変更されたことを感知するリソース変更モニタ部と、前記変更されたリソースについてのメタデータが含まれた変更ログを生成する変更ログ生成部と、前記変更されたリソースと前記生成された変更ログとをＵＰｎＰネットワークを介して前記受信側のＵＰｎＰデバイスに伝送する変更ログ／リソース伝送部とを備え、前記変更ログは、前記変更されたリソースに固有なリソース識別子と、前記変更されたリソース保存経路の変更いかんについての情報とを含むことを特徴とする。
【発明の効果】
【００１３】
本発明の実施形態によれば、伝送側デバイスで変更されたリソースに対するリソース識別子と、リソースの保存経路が変更された否かについての情報とを変更ログに含めて伝送し、受信側デバイスでは、前記変更ログを利用し、同一のリソースについては１つの保存経路に保存することによって、不要にリソースが重複保存されることを防止できる。また、これを介して、デバイスの保存空間を効率的に活用可能である。
【図面の簡単な説明】
【００１４】
【図１】コンテンツ・ディレクトリ・サービスを提供するＵＰｎＰデバイス間でコンテンツを同期化する方法について簡略に説明するための概念図である。
【図２】本発明の一実施形態によって、コンテンツ・ディレクトリ・サービスを提供するＵＰｎＰデバイス間のコンテンツ同期化時に、変更されたリソースの重複保存を防止するための方法について説明するためのフローチャートである。
【図３】本発明の一実施形態によるＵＰｎＰデバイスの構造図である。
【図４】本発明の一実施形態によって、コンテンツ・ディレクトリ・サービスを提供する送信側のＵＰｎＰデバイスが、変更されたリソースに対する変更ログを生成及び伝送する過程を示したフローチャートである。
【図５】本発明の一実施形態によって、コンテンツ同期化時にコンテンツ・ディレクトリ・サービスを提供する受信側のＵＰｎＰデバイスが、リソースの重複保存を防止するための過程を示したフローチャートである。
【図６Ａ】本発明の他の実施形態によって、コンテンツ同期化時にコンテンツ・ディレクトリ・サービスを提供する受信側のＵＰｎＰデバイスが、リソースの重複保存を防止するための過程を示したフローチャートである。
【図６Ｂ】本発明の他の実施形態によって、コンテンツ同期化時にコンテンツ・ディレクトリ・サービスを提供する受信側のＵＰｎＰデバイスが、リソースの重複保存を防止するための過程を示したフローチャートである。
【発明を実施するための形態】
【００１５】
以下、添付した図面を参照しつつ、本発明による、コンテンツ同期化時にコンテンツ・ディレクトリ・サービスを提供するＵＰｎＰデバイス間のリソース重複保存を防止するための方法及び装置の望ましい実施形態について詳細に説明する。各図面の構成要素に参照符号を加えるにおいて、同じ構成要素に限っては、たとえ他の図面上に表示されていても、可能な限り同じ符号で表記されていることに留意せねばならない。また、下記の説明では、具体的な回路の構成素子のような多くの特定事項が図示されているが、それらは、本発明のさらに全般的な理解を助けるために提供されたものであり、かような特定事項なしにも本発明が実施されうることは、本技術分野の当業者には自明であろう。そして、本発明を説明するにおいて、関連した公知機能または構成についての具体的な説明が本発明の要旨をぼやかす恐れがあると判断される場合には、その詳細な説明を省略する。
【００１６】
図２は、本発明の一実施形態によって、コンテンツ・ディレクトリ・サービスを提供するＵＰｎＰ（Universal  Plug  and  Play）デバイス間のコンテンツ同期化時に、変更されたリソースの重複保存を防止するための方法を説明するためのフローチャートである。ここでは、２つのＵＰｎＰデバイスを仮定する。また以下で、コンテンツ・ディレクトリ・サービス（ＣＤＳ：Content  Directory  Service）という用語は、ＵＰｎＰデバイスが提供するサービスまたはコンテンツ・ディレクトリ・サービスを提供するモジュールの概念として使われる。
【００１７】
図２を参照するに、段階２０１の初期化作業が行われた後、段階２０２及び段階２０３で各ＣＤＳは、それまで変更されたアイテムについてのメタデータが含まれた変更ログ（Change  Log）を交換する。すなわち、Browse()アクションまたはＣＤＳ同期化のために、新たに設けられうるGetSyncObjectURI()のようなＵＰｎＰアクションを介して前記変更ログを持ってくる。かような変更ログには、デジタルアイテム宣言言語（ＤＩＤＬ−Lite：Digital  Item  Declaration  Language）形式からなるＣＤＳアイテム情報が含まれ、前記ＣＤＳアイテム情報は、各ＣＤＳアイテムの属性情報とリソースの保存経路とからなる。
【００１８】
本発明の一実施形態によれば、リソースの重複保存を防止するために、前記変更ログには、リソースに固有なリソース識別子と、リソース保存経路の変更いかんについての情報とがさらに含まれる。前記リソース識別子は、例えば、リソースファイルの最初の１０バイト、後ろの１０バイト及びリソースファイルの大きさ２バイトを合わせ、ハッシュ関数（hash  function）を利用して作ることができ、それ以外にも、多様な方式で固有な値を作ることができる。また、リソース保存経路の変更いかんは、例えばＴＲＵＥ（リソースの保存経路が変更される）またはＦＡＬＳＥ（リソースの保存経路が変更されない）のようなブーリーン（boolean）値で表現したり、または保存経路を利用した値を利用できる。
【００１９】
その後、段階２０３では各ＣＤＳは、変更ログに基づいて変更されたリソースを受信及び保存する。本発明によるコンテンツ同期化方法によれば、リソースを受信及び保存する過程で受信側デバイスは、すでに同一のリソースが保存されているか否かを判断し、判断結果、同一のリソースがすでに保存されているならば、重複保存しないようにする。その後、各ＣＤＳは、リソースの保存経路によってメタデータを更新する。その後、段階２０４で同期化段階は終了する。
【００２０】
図３は、本発明の一実施形態によるＵＰｎＰデバイス３００の構造図であり、前記デバイス３００は、コンテンツ・ディレクトリ・サービスモジュール３１０及びコンテンツ・データベース（ＤＢ）３０１を含み、前記コンテンツ・ディレクトリ・サービスモジュールは、リソース変更モニタ部３０２、変更ログ生成部３０３、変更ログ／リソース伝送部３０４、リソース識別子−経路マッピング部３０５、変更ログ／リソース受信部３０６、及びリソース管理部３０７を備える。本発明の一実施形態で、コンテンツが同期化されるということは、複数個のコンテンツ・ディレクトリ・サービスが提供するコンテンツの目録を一致させることを意味する。ただし、具現例によって、ある１つのコンテンツ・ディレクトリ・サービスが提供する同期化される客体（object）の範囲は、特定コンテナ（container）に限定することもできるのである。すなわち、例えばユーザは、ホームメディアセンターの特定ホルダと自身のＭＰ３プレーヤーを同期化できるのである。また、同期化されるコンテンツの範囲は、デバイスの能力によって変わりもするが、例えば、ホームメディアセンターの特定ホルダにオーディオ・コンテンツ及びビデオ・コンテンツが保存されている場合、ユーザが自身のＭＰ３プレーヤとその特定ホルダとを同期化させれば、ＭＰ３プレーヤが支援できるオーディオ・コンテンツについてのみ同期化される。本実施形態では、コンテンツが同期化される場合を仮定する。
【００２１】
コンテンツＤＢ  ３０１は、ＵＰｎＰデバイス３００がコンテンツ・ディレクトリ・サービスを介して提供するコンテンツの目録及びリソースを保存する。前記コンテンツＤＢ  ３０１は、ＵＰｎＰデバイス３００内部に内蔵されている。
【００２２】
リソース変更モニタ部３０２は、コンテンツＤＢ  ３０１をモニタリングしてリソースの変更が発生しているか否かを監視し、リソースの変更が発生すれば、変更ログ生成部３０３にこれを知らせる。望ましくは、リソースの変更とは、リソースの追加、修正、削除、保存経路の変更のうち、少なくともいずれか一つであることを特徴とする。
【００２３】
変更ログ生成部３０３は、リソースの変更が発生すれば、変更されたリソースについてのメタデータを含む変更ログを生成し、変更ログ／リソース伝送部３０４は、生成された変更ログをＵＰｎＰネットワーク３１０に伝送する。望ましくは、前記変更ログには、リソースに固有な識別子（ＩＤ：Identification）と、リソース保存経路の変更いかんについての情報とを含む。また、変更ログ生成部３０３は、リソースの変更が発生すれば、変更されたリソースに対して、リソース識別子と、それに対応する保存経路とを生成する。
【００２４】
リソース識別子−経路マッピング部３０５は、変更ログ生成部３０３で生成したリソース識別子と、それに対応する保存経路とをテーブルの形態で保存する。
【００２５】
以上で述べたリソース変更モニタ部３０２、変更ログ生成部３０３、変更ログ／リソース伝送部３０４、リソース識別子−経路マッピング部３０５は、ＵＰｎＰデバイス３００のリソースが変更された場合、リソースの変更と関連した情報をＵＰｎＰネットワーク３２０に知らせるための構成要素である一方、リソース識別子−経路マッピング部３０５、変更ログ／リソース受信部３０６、リソース管理部３０７は、ネットワーク内の他のコンテンツ・ディレクトリ・サービスが提供するリソースが変更されたとき、その変更された情報をＵＰｎＰデバイス３００のコンテンツ・ディレクトリ・サービスに反映するための構成要素である。
【００２６】
変更ログ／リソース受信部３０６は、第３のＵＰｎＰデバイスから変更されたリソースについてのメタデータが含まれた変更ログを受信し、リソース管理部３０７に伝達し、リソース管理部３０７は、変更ログに含まれた情報を利用して、変更されたリソースを、経路情報によってコンテンツＤＢ
３０１に保存する。
【００２７】
また、リソース管理部３０７は、前記経路情報によって、前記変更されたリソースについてのメタデータを生成し、変更されたリソースに対してリソース識別子−経路マッピング部３０５を更新する。望ましくは、前記経路情報は、伝送側のＵＰｎＰデバイス、または受信側のＵＰｎＰデバイスのうち、いずれか一つによって与えられる。
【００２８】
図４は、本発明の一実施形態によって、コンテンツ・ディレクトリ・サービスを提供する送信側のＵＰｎＰデバイスが変更されたリソースに係る変更ログを生成及び伝送する過程を示したフローチャートである。図４を参照するに、段階４００で、リソースが変更されたと判断すれば、段階４０１では、変更されたリソースについてのメタデータを含む変更ログを生成する。生成された変更ログは、段階４０２でＵＰｎＰネットワークを介して受信側ＵＰｎＰデバイスに伝送される。望ましくは、前記変更ログには、リソースに固有なリソース識別子と、リソース保存経路の変更いかんについての情報とを含み、リソースの変更とは、リソースの追加、修正、削除、保存経路の変更のうち、少なくともいずれか一つであることを特徴とする。
【００２９】
図５は、本発明の一実施形態によって、コンテンツ同期化時にコンテンツ・ディレクトリ・サービスを提供する受信側のＵＰｎＰデバイスが、リソースの重複保存を防止するための過程を示したフローチャートである。後述の図６と異なり、リソース識別子のみでリソースの重複保存を防止するための実施形態である。
【００３０】
図５に示されている通り、段階５００で、変更されたリソースについてのメタデータを含む変更ログを受信すれば、まず段階５０１で、変更ログに含まれた保存経路の変更いかんについての情報からリソースが変更された否かを確認する。
【００３１】
段階５０２での判断結果、リソースが変更されたならば、段階５０３で、受信された変更ログからリソース識別子を読み出す。
【００３２】
段階５０４での判断結果、リソース識別子−経路マッピング部３０５に同一のリソース識別子が存在するならば、段階５０５では、受信側デバイスのリソース識別子−経路マッピング部３０５にすでに保存された既存の保存経路によってメタデータを生成する。
【００３３】
段階５０４での判断結果、リソース識別子−経路マッピング部３０５に同一のリソース識別子が存在しないならば、段階５０６では、当該リソースを受信してリソース識別子を生成する一方、対応する保存経路を指定し、新たな経路によってメタデータを生成する。前記リソース識別子及び対応する保存経路は、リソース識別子−経路マッピング部３０５に登録する。
【００３４】
もし段階５０２での判断結果、リソースが変更された場合ではないならば、リソース以外のコンテンツ、例えばメタデータに含まれる題目、再生時間、再生回数などが変更された場合であるので、段階５０８では、これを反映してメタデータを更新する。
【００３５】
段階５０７で前記段階は、変更ログに含まれた項目全てに係る処理を反復して行う。
【００３６】
図６は、本発明の他の実施形態によって、コンテンツ同期化時にコンテンツ・ディレクトリ・サービスを提供する受信側のＵＰｎＰデバイスが、リソースの重複保存を防止するための過程を示したフローチャートである。前述の通り図５では、リソース識別子だけを考慮するが、図６は、リソースの重複保存を防止するために、リソース識別子及び保存経路いずれもを考慮する。
【００３７】
図６で示されている通り、段階６００で、変更されたリソースについてのメタデータを含む変更ログを受信すれば、まず段階６０１で、受信された変更ログに含まれた保存経路の変更いかんについての情報からリソースが変更された否かを確認する。
【００３８】
段階６０２での判断結果、リソースが変更されたとすれば、段階６０３で、受信された変更ログからリソース識別子を読み出す。
【００３９】
段階６０４での判断結果、受信側のリソース識別子−経路マッピング部３０５に同一のリソース識別子が存在するならば、段階６０５では、受信された変更ログから送信側の経路情報を読み出す。
【００４０】
段階６０６での判断結果、受信側リソース識別子−経路マッピング部３０５に保存された保存経路と同一ならば、段階６０７では、受信側に保存された既存の受信側経路によってメタデータを生成する。
【００４１】
段階６０６での判断結果、受信側リソース識別子−経路マッピング部３０５に保存された保存経路と同一ではないならば、段階６１１では、変更ログに含まれた送信側のリソースを受信側コンテンツＤＢに保存し、送信側経路と受信側経路とをリソース−識別子経路マッピング部３０５に登録する。また、受信側経路によってメタデータを生成する。
【００４２】
段階６０４での判断結果、受信側のリソース識別子−経路マッピング部３０５に同一のリソース識別子が存在しないならば、段階６１０では、当該リソースを受信してリソース識別子を生成する一方、対応する保存経路を指定する。そして、指定された経路によってメタデータを生成する。前記リソース識別子及び対応する保存経路は、リソース識別子−経路マッピング部３０５に登録する。
【００４３】
段階６０２での判断結果、リソースが変更されていないならば、リソース以外のコンテンツ、例えばメタデータに含まれる題目、再生時間、再生回数などが変更された場合であるので、段階６１１では、これを反映してメタデータを更新する。
【００４４】
段階６０８で、前記段階は、変更ログに含まれた項目全てに係る処理を反復的に行う。
【００４５】
以上、本発明の望ましい実施形態について詳細に技術したが、本発明が属する技術分野において当業者ならば、添付された請求範囲に定義された本発明の精神及び範囲を外れずに、本発明をさまざまに変形または変更して実施できるということが分かるであろう。よって、本発明の今後の実施形態の変更は、本発明の技術を外れるものではない。
【図１】
0004828636.tif 000002
【図２】
0004828636.tif 000003
【図３】
0004828636.tif 000004
【図４】
0004828636.tif 000005
【図５】
0004828636.tif 000006
【図６Ａ】
0004828636.tif 000007
【図６Ｂ】
0004828636.tif 000008