JP6208225B2 - 汎用デバイスにおけるファイル送受信装置及び方法 - Google Patents

Description

本発明は一般に汎用デバイスにおけるファイル送受信装置及び方法に関するもので、特にファイルコンテナ構造を維持する間にファイルを送受信する装置及び方法に関する。

通常、汎用デバイスは、特定目的に使用されるものでなく、多くの一般的な目的のために使用され、他のデバイスとの連動が自由なデバイスを意味する。このような汎用デバイスは、例えばファイル共有のために、他の汎用デバイスとファイルを自由に交換できる。

汎用デバイスにおいて、ファイルは、ツリー構造のようなコンテナ構造に基づいて格納又は記録される。汎用デバイスで読み出し、格納し、編集されるコンテンツがますます多様化されることによって、ファイルが格納されるコンテナ構造がますます重要になっている。そのため、汎用デバイス間のファイル伝送の際に、受信側汎用デバイスは、受信した任意のファイルを、このファイルが送信側デバイスに格納される正確なコンテナ構造により格納しなければならない。

図１は、ファイルを格納するコンテナ構造の一例を示す。

図１に示すコンテナ構造は、ルートディレクトリ‘/’１１０、及びそのサブディレクトリ‘Ａ’１１２，‘Ｂ’１１４、‘Ｃ’１１６で構成される。ディレクトリ‘Ａ’１１２は、その親ディレクトリとしてルートディレクトリ１１０を有する子ディレクトリである。ディレクトリ‘Ｂ’１１４は、親ディレクトリとしてディレクトリ‘Ａ’１１２を有する子ディレクトリである。ディレクトリ‘Ｃ’１１６は、親ディレクトリとしてディレクトリ‘Ｂ’１１４を有する子ディレクトリである。

図１では、各親ディレクトリが一つの子ディレクトリに結合されているが、コンテナ構造は、例えば一つの親ディレクトリに複数の子ディレクトリが結合される多様な形態で構成することができる。

図１において、ファイル１ １２０はルートディレクトリ１１０に記録され、ファイル２ １２２はディレクトリ‘Ａ’１１２に記録され、ファイル３ １２４は、ディレクトリ‘Ｂ’１１４に記録される。

汎用デバイスが図１のようなコンテナ構造に格納されているファイルを他の汎用デバイスに伝送するために、送信側汎用デバイスは、受信側デバイスにコンテナ構造に関する情報とコンテナ構造に格納されているファイル両方ともを送信しなければならない。

受信側汎用デバイスは、送信側汎用デバイスから受信したコンテナ構造に関する情報に基づき、ファイルを格納するコンテナを構成し、受信したファイルに関するデータを構成したコンテナ構造で該当ディレクトリに格納する。このように、受信側汎用デバイスは、送信側デバイスと同一のコンテナ構造でファイルを格納する。

図２は、汎用デバイス間のファイル伝送のための従来の信号処理手順の一例を示す。図２に示す信号処理手順の例では、図１に示したコンテナ構造に格納されたファイルが伝送される。

図２を参照すると、送信汎用デバイス(‘送信器’)１０は、各ディレクトリに記録されたファイルを受信汎用デバイス(‘受信器’)２０に伝送する(ステップ２１０のファイル１、ステップ２２０のファイル２、及びステップ２３０のファイル３の送信)。各ファイルを送信した後、送信器１０は、伝送したファイルが格納されるディレクトリの生成のための制御情報を伝送し(ステップ２１２，２２２，２３２でコマンド‘ｍｋｄｉｒ’の伝送を参照)、伝送したファイルが格納されるディレクトリへの変更又は移動のための制御情報を伝送する(ステップ２１４，２２４，２３４でコマンド‘ｃｋｄｉｒ’の伝送を参照)。

したがって、送信器１０は、一つのファイルを伝送するたびに、受信器２０が生成するディレクトリに関する制御情報、及び受信器２０が送信したファイルを格納するディレクトリに移動及び変更する制御情報を伝送しなければならない。

図１に具体的に示したように、送信器１０は、ファイル１ １２０、ファイル２ １２２、及びファイル３ １２４を順次に伝送する。

第１に、送信器１０は、ステップ２１０でファイル１ １２０を伝送し、ステップ２１２で、ファイル１ １２０が格納されるルートディレクトリ‘/’１１０を生成(‘ｍｋｄｉｒ/’)するために制御情報を伝送し、ステップ２１４で、ファイル１ １２０が格納されるルートディレクトリ‘/’１１０へ移動(‘ｃｈｄｉｒ/’）するように受信器２０に対する制御情報を伝送する。逆に、受信器２０は、ステップ２１０でファイル１ １２０を受信し、ステップ２１２で、受信したファイル１ １２０を格納するルートディレクトリ‘/’１１０を生成し、ステップ２１４で、ルートディレクトリ‘/’１１０へ移動して受信したファイル１ １２０を格納する。

第２に、送信器１０は、ステップ２２０で、ファイル２ １２２を伝送し、ステップ２２２で、ファイル２ １２２を格納するために制御情報をディレクトリ‘Ａ’ １１２を生成(‘ｍｋｄｉｒ Ａ’)するように伝送し、ステップ２２４で、ファイル２ １２２を格納するためにディレクトリ‘Ａ’ １１２へ移動(‘ｃｈｄｉｒ Ａ’）するように受信器２０のための制御情報を伝送する。

反対に、受信器２０は、ステップ２２０でファイル２ １２２を受信し、ステップ２２２で、受信したファイル２ １２２を格納するディレクトリ‘Ａ’ １１２を生成し、ステップ２２４で、ディレクトリ‘Ａ’ １１２に移動して受信したファイル２ １２２を格納する。

第３に、送信器１０は、ステップ２３０でファイル３ １２４を伝送し、ステップ２３２で、ファイル３ １２４を格納するディレクトリ‘Ｂ’１１４を生成(‘ｍｋｄｉｒ Ｂ’)するように制御情報を伝送し、ステップ２３４で、ファイル３ １２４を格納するディレクトリ‘Ｂ’１１４へ移動(‘ｃｈｄｉｒ Ｂ’）するように制御情報を伝送する。

一方、受信器２０は、ステップ２３０でファイル３ １２４を受信し、ステップ２３２で受信したファイル３ １２４を格納するディレクトリ‘Ｂ’１１４を生成し、ステップ２３４で、ディレクトリ‘Ｂ’１１４に移動して受信したファイル３ １２４を格納する。

図２に示す手順によりファイルの送受信に使用されるプロトコルは、ファイル転送プロトコル(ＦＴＰ)(ＩＥＴＦ ＲＦＣ７６５)である。

コンテナ構造がさらに複雑になる場合、図２に示す手順で、送信器が受信器に提供すべき制御情報の量が増加するようになる。

図３は、従来の汎用デバイス間のファイル伝送のための信号処理手順の他の例を示す。図３に、図１に示したコンテナ構造に格納されたファイルが伝送されることを示す。

図３に示した実施形態では、送信器は、伝送するコンテンツを獲得できる位置(例えば、ＵＲＬ(Uniform Resource Locator))に関する情報及びコンテナ構造に関する情報を予め受信器に提供し、受信器は、予め受信した情報を用いて受信したファイルを複製したコンテナ構造により記録するための手順を示す。

図３を参照すると、送信器１０は、ステップ３１０で、送信されるコンテンツ及びコンテナ構造に関する情報を含むメタデータファイルを構成し、構成したメタデータファイルを受信器２０に伝送する。メタデータファイルは、伝送されるコンテンツに対応する少なくとも一つのファイルが格納される位置情報(例えば、ＵＲＬ)及びコンテナ構造に関する情報を含む。

受信器２０は、送信器１０から受信したメタデータファイルから伝送される３個のファイル、すなわちファイル１ １２０、ファイル２ １２２、ファイル３ １２４の各々に対応する位置情報と、ファイルが格納されるコンテナ構造に関する情報を獲得する。

第１に、受信器２０は、ステップ３１２で、獲得した位置情報を用いてファイル１ １２０を読み出し、コンテナ構造に関する情報に基づいてルートディレクトリ‘/’１１０に格納する。

第２に、受信器２０は、ステップ３１４で、獲得した位置情報を用いてファイル２ １２２を読み出し、コンテナ構造に関する情報に基づいてディレクトリ‘Ａ’１１２に格納する。

第３に、受信器２０は、ステップ３１６で、獲得した位置情報を用いてファイル３ １２４を読み出し、コンテナ構造に関する情報に基づいてディレクトリ‘Ｂ’１１４に格納する。

図３で受信器２０がファイルを送信器１０から読み出すが、受信器２０が送信器１０側の他の位置、すなわち他の汎用デバイスから所望のファイルを読み出すことができることは、当業者にとっては明らかである。

あるいは、受信器２０の実現方法に従って、送信器１０が伝送されるコンテナ構造に関する情報を無視し、受信器２０は、他のコンテナ構造により受信したファイルを格納することができる。

図３に示す手順では、実際にファイルが伝送される前に、受信器２０は、どのコンテナ構造でファイルが伝送されるかを決定し、それによってユーザーが実際ファイル伝送の開始前にファイルを確認して伝送を許可するか否かを判定できるようにする。

しかしながら、図３に示す従来方式では、送信されるコンテンツのコンテナ構造が複雑になり、及び/又はコンテンツが多い場合に、送信器１０は、コンテンツの生成とそのコンテナ構造に関する情報の生成両方ともに処理リソースを使用しなければならない。このような別の処理により、不要な時間遅延が発生するという問題点があった。

したがって、本発明は、上記した従来技術の問題点に鑑みてなされたものであって、その目的は、汎用デバイス間のファイル送受信による制御手順を短縮させるファイル送受信装置及び方法を提供することにある。

本発明の他の目的は、汎用デバイス間に要求されるファイル送受信時間を短縮させるファイル送受信装置及び方法を提供することにある。

また、本発明の目的は、汎用デバイス間のファイル送受信の際に、送信側汎用デバイス(又は送信器)により伝送されるコンテンツのファイルコンテナ構造が受信側汎用デバイス(又は受信器)で維持されるファイル送受信装置及び方法を提供することにある。

さらに、本発明の目的は、送信側汎用デバイスが特定コンテンツのための伝送ファイルが伝送ファイルのヘッダー情報と共に格納される位置に関する情報を伝送する装置及び方法を提供することにある。

本発明の他の目的は、受信側汎用デバイスが受信したファイルのヘッダーから獲得した位置情報により該当ファイルを格納する装置及び方法を提供することにある。

また、本発明の目的は、送信側汎用デバイスが、所定のコンテナ構造により伝送されるファイルを受信側汎用デバイスが格納可能にする一部制御情報を、メタデータファイルを用いて分散方式で伝送する装置及び方法を提供することにある。

さらに、本発明の目的は、汎用デバイス間に伝送されるファイルを所定のコンテナ構造により格納するために提供される制御情報を、メタデータファイルと共に伝送されるファイルのヘッダーに分散方式で伝送する装置及び方法を提供することにある。

さらなる本発明の目的は、汎用デバイス間に伝送されるファイルが所定のコンテナ構造により格納させるために使用される制御情報のうち一部を含むメタデータファイルの伝送のための信号処理手順を提供することにある。

上記のような目的を達成するために、本発明の一態様によれば、第１のデバイスで所定のコンテナ構造に格納されるファイルを第２のデバイスに伝送する方法が提供される。その方法は、格納されるファイルのうち伝送されるファイルの一部又は全部を識別するステップと、識別したファイルに関する伝送情報を生成するステップと、伝送情報を第２のデバイスに伝送するステップと、識別したファイルが格納されるディレクトリの位置に関する情報を含む識別したファイルの各々のためのヘッダーを構成するステップと、構成したヘッダーの各々を対応する識別したファイルに付加するステップと、第２のデバイスにヘッダー付加ファイルを伝送するステップとを有する。

本発明の他の態様によれば、ファイルを伝送する装置が提供される。その装置は、所定のコンテナ構造によってファイルを格納するように構成される格納部と、格納部に格納されたファイルのうち伝送されるファイルの一部又は全部を識別し、識別したファイルの伝送情報を生成し、識別したファイルを格納するディレクトリの位置に関する情報を含む識別したファイルの各々のためのヘッダーを構成し、識別したファイルの各々に構成したヘッダーを付加して伝送メッセージを生成するメッセージ生成部と、メッセージ生成部により生成される伝送情報を受信デバイスに伝送し、メッセージ生成部により生成された伝送メッセージを受信デバイスに送信する送信部とを含む。

また、本発明の他の態様によれば、所定のコンテナ構造によりファイルを受信及び格納する方法が提供される。その方法は、所定のコンテナ構造により配置された一つ以上のディレクトリにファイルを格納するために要求される制御情報の一部を含むメタデータを受信するステップと、ファイルの一部又は全部を受信するステップと、メタデータを通じて受信した一部制御情報と受信したファイルそれぞれのヘッダーに含まれる制御情報に基づき、所定のコンテナ構造により配置される一つ以上のディレクトリに受信したファイルを格納するステップとを有し、各ヘッダーに含まれる制御情報は、対応するファイルのために所定のコンテナ構造により配置された一つ以上のディレクトリの選択に使用される格納位置に関する情報である。

さらに、本発明の他の態様によれば、所定のコンテナ構造によりファイルを受信及び格納する装置が提供される。その装置は、所定のコンテナ構造により配置されたファイルを格納するために要求される制御情報の一部を含むメタデータを受信し、ファイルの一部または全部を受信する受信部と、メタデータを通じて受信した一部制御情報と受信したファイルそれぞれのヘッダーに含まれている制御情報に基づき、所定のコンテナ構造により配置される受信したファイルを各々格納するディレクトリを決定するメッセージ処理部と、受信したファイルの各々を所定のコンテナ構造により配置されたディレクトリのうちメッセージ処理部により決定されたディレクトリに格納する格納部とを含み、各ヘッダーに含まれる制御情報は、対応するファイルを格納するために所定のコンテナ構造により配置されたディレクトリの決定に使用されるファイルの格納位置に関する情報を含む。

本発明による実施形態の上記及び他の態様、特徴、及び利点は、添付の図面と共に述べる以下の詳細な説明から、一層明らかになるはずである。

ファイルが格納されるコンテナ構造の一例を示す図である。 従来の汎用デバイス間のファイル伝送のための信号処理の一例を示す図である。 従来の汎用デバイス間のファイル伝送のため(の)信号処理手順の他の例を示す図である。 本発明の一実施形態による汎用デバイス間のファイル伝送のための信号処理手順の一例を示す図である。 本発明の実施形態による汎用デバイス間のファイル伝送のための信号処理手順の他の例を示す図である。 本発明の実施形態による汎用デバイス間のファイル伝送のための信号処理手順の他の例を示す図である。 本発明の実施形態による汎用デバイスの間でコンテナ構造情報を交換する一例を示す図である。 本発明の実施形態による汎用デバイスの間でコンテナ構造情報を交換する他の例を示す図である。 図８に示すメタデータファイルの伝送のための具体的な信号処理手順の一例を示す図である。 本発明の実施形態による汎用デバイスの間でコンテナ構造情報を交換する他の例を示す図である。 本発明の実施形態による汎用デバイスでファイルを送信するための送信装置の構成を示す図である。 本発明の実施形態による汎用デバイスでファイルを受信するための受信装置の構成を示す図である。 本発明の実施形態による汎用デバイスでファイルの送受信を制御する方法を示すフローチャートである。

以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。

添付の図面を参照した下記の説明は、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるような本発明の実施形態の包括的な理解を助けるために提供するものである。この理解を助けるための様々な特定の詳細を含むが、単なる一つの実施形態に過ぎない。したがって、本発明の範囲及び趣旨を逸脱することなく、ここに説明する実施形態の多様な変更及び修正が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能及び構成に関する具体的な説明は、省略する。

次の説明及び請求項に使用する用語及び単語は、辞典的意味に限定されるものではなく、発明者により本発明の理解を明確且つ一貫性があるようにするために使用する。従って、特許請求の範囲とこれと均等なものに基づいて定義されるものであり、本発明の実施形態の説明が単に実例を提供するためのものであって、本発明の目的を限定するものでないことは、本発明の技術分野における通常の知識を持つ者には明らかである。

本願明細書に記載の各要素は、文脈中に特に明示しない限り、複数形を含むことは、当業者には理解できるものである。したがって、例えば、コンポーネント表面（a component surface）”との記載は、１つ又は複数の表面を含む。

以下の実施形態では、送信側汎用デバイスがコンテナ構造により格納されるファイルを受信側汎用デバイスに伝送することについて具体的に説明する。

このために、送信側汎用デバイスと受信側汎用デバイスとの間のコンテンツ送受信による効果的な手順が新たに定義される。新たに定義される手順により、送信側汎用デバイスが、コンテンツ送受信による制御情報を、受信側汎用デバイスに簡素化したステップで、時間損失を防止するように效率的に伝送する多様な実施形態が提供される。

本発明の一実施形態において、ファイルを格納するコンテナ構造に関する情報が各ファイルで伝送され、必要な場合、一部の制御情報は、メタデータファイルを用いて予め伝送される。このため、メタデータファイルを通じて伝送される制御情報に対する定義だけでなく、メタデータファイルを伝送するための手順が提供されなければならない。

以下の説明では、用語‘汎用デバイス’が便宜のために使用されるが、多様な実施形態がファイル伝送が可能な他のデバイスに適用されることは、当該技術分野における通常の知識を持った者には明らかである。

図４は、本発明の実施形態による汎用デバイス間のファイル伝送のための信号処理手順の一例を示す。図４に示す信号処理手順は、図１に示したコンテナ構造に格納されているファイルを伝送することを示す。

図４を参照すると、送信側汎用デバイス(‘送信器’)１０は、受信側汎用デバイス(‘受信器’)２０にディレクトリ別に記録されたファイルを伝送する(ステップ４１０，４２０，４３０を参照)。送信器１０は、伝送されるファイル各々に該当ファイルを記録する位置情報を含めて伝送する。例えば、ファイルが格納される位置に関する情報は、ファイルのヘッダーに含まれる。

図４に示す実施形態において、送信器１０は、ファイル１ １２０、ファイル２ １２２、及びファイル３ １２４を順次に送信する。

ファイル１ １２０が伝送される場合、送信器１０は、ファイル１ １２０が格納される位置に関する情報としてファイル１ １２０のヘッダーにルートディレクトリ‘/’１１０を示す情報を含む。この場合、受信器２０は、ファイル１ １２０を受信し、この受信したファイル１ １２０のヘッダーに含まれた位置情報を確認することによって、受信したファイル１ １２０をルートディレクトリ‘/’１１０に格納する。

ファイル２ １２２を伝送する場合、送信器１０は、ファイル２ １２２が格納される位置に関する情報としてファイル２ １２２のヘッダーにディレクトリ‘Ａ’１１２を示す情報を含む。この場合、受信器２０は、ファイル２ １２２を受信し、受信したファイル２ １２２のヘッダーに含まれている位置情報を確認し、それによってディレクトリ‘Ａ’１１２に受信したファイル２ １２２を格納する。

他の実施形態において、ディレクトリ‘Ａ’１１２を示す位置情報はディレクトリ‘Ａ’を示す情報だけでなくその親ディレクトリに関する情報も含むことができる。すなわち、ファイル１ １２０のヘッダー情報に含まれた位置情報は、ディレクトリ‘Ａ’１１２がルートディレクトリ‘/’１１０を親ディレクトリとして有する子ディレクトリであることを示すことができる。

ファイル３ １２４を伝送する場合、送信器１０は、ファイル３ １２４が格納される位置情報としてディレクトリＢ １１４を示す情報をファイル３ １２４のヘッダーに含む。この場合、受信器２０は、ファイル３ １２４を受信し、受信したファイル３ １２４のヘッダーに含まれる位置情報を確認し、それによって受信したファイル３ １２４をディレクトリ‘Ｂ’１１４に格納する。

これら実施形態において、ディレクトリ‘Ｂ’１１４を示す位置情報は、ディレクトリ‘Ｂ’を示す情報だけでなくその親ディレクトリに関する情報も含むことができる。言い換えれば、ファイル２ １２２のヘッダー情報に含まれる位置情報は、ディレクトリ‘Ｂ’１１４が親ディレクトリとしてディレクトリ‘Ａ’１１２を有する子ディレクトリであり、ディレクトリ‘Ａ’１１２が親ディレクトリとしてルートディレクトリ‘/’１１０を有する子ディレクトリであることを示すことができる。

図４に示す実施形態を要約すれば、コンテンツファイル(又はコンテンツ関連ファイル)の送信中に、各ファイルは、ファイルが格納されるコンテナ構造に関する情報を含むように構成される。本発明の一部実施形態において、この追加情報は、ＨＴＴＰ(Hypertext Transfer Protocol)ＰＯＳＴメッセージのヘッダーに定義され、例えばファイルの関連経路情報を含むことができる。

図４に示す実施形態において、伝送されるファイルの格納位置を示すために、ＨＴＴＰ ＰＯＳＴヘッダーは、ホスト情報‘Ｈｏｓｔ’、コンテンツ長情報‘Ｃｏｎｔｅｎｔ-Ｌｅｎｇｔｈ’、コンテンツタイプ情報‘Ｃｏｎｔｅｎｔ−Ｔｙｐｅ’、ファイル位置情報‘ＳＥＮＤＥＲ_ＬｏｃａｔｉｏｎＵＲＬ’、及びファイルタイプ情報‘Ｏｂｊｅｃｔ_Ｔｙｐｅ’のような追加情報を含む。

その結果、受信器は、関連経路情報に基づいて受信したファイルを適当な位置に格納することによって、送信器で使用されるコンテナ構造を維持する。

上記した多様な実施形態では、コンテナ構造情報は、メタデータファイルを用いて伝送されない。したがって、後述するように、メタデータを用いたコンテナ構造情報のための伝送方式を定義する必要がある。

図５は、本発明の実施形態による汎用デバイス間のファイル伝送のための信号処理手順の他の例を示す。図５に示す実施形態では、メタデータファイルで予め送信される制御情報を最小化し、コンテンツファイルの伝送時に制御情報の大部分を送信するハイブリッド伝送方式である。図５に示す信号処理手順により伝送されるファイルは、図１に示すコンテナ構造で格納される。

図５を参照すると、送信器１０は、ステップ５１０で、コンテンツファイルの受信に使用される最小の制御情報を含むようにメタデータファイルを構成し、構成したメタデータファイルを受信器２０に伝送する。

例えば、メタデータファイルに含まれる最小の制御情報は、コンテンツファイルを受信するために共通に要求される制御情報を含むことができる。図５に示す実施形態において、メタデータファイルは、伝送されるファイルの総数‘ＴｏｔａｌＦｉｌｅＮｕｍｂｅｒ’、全体ファイルサイズ‘ＴｏｔａｌＳｉｚｅＭＢ’、代表ファイル名‘ＲｅｐｒｅｓｅｎｔａｔｉｖｅＦｉｌｅＮａｍｅ’、ファイルリスト記録位置‘ＬｉｓｔｏｆＦｉｌｅｓＵＲＬ’で構成される。図示のように、メタデータファイルが伝送される全体コンテンツファイルに共通に適用される制御情報で構成されることを確認することができる。

メタデータファイルの伝送後に、送信器１０は、各ディレクトリに格納されたファイルを受信器２０に伝送する(ステップ５１２，５１４，５１６を参照)。送信器１０により伝送される各ファイルのヘッダーは、ファイルが格納される位置に関する情報を含む。

図５に示す実施形態において、送信器１０は、ファイル１ １２０、ファイル２ １２２、及びファイル３ １２４を順次に伝送する。

ファイル１ １２０を伝送する場合、送信器１０は、ステップ５１２で、ファイル１ １２０が格納される位置情報としてルートディレクトリ‘/’１１０を示す情報をヘッダーに含める。この場合、受信器２０は、ファイル１ １２０を受信し、受信したファイル１ １２０のヘッダーに含まれる位置情報を確認し、それによって受信したファイル１ １２０をルートディレクトリ‘/’１１０に格納する。

ファイル２ １２２を伝送する場合、送信器１０は、ステップ５１４で、ファイル２ １２２が格納される位置情報としてディレクトリ‘Ａ’１１２を示す情報をヘッダーに含める。この場合、受信器２０は、ファイル２ １２２を受信し、受信したファイル２ １２２のヘッダーに含まれる位置情報を確認し、それによって受信したファイル２ １２２をディレクトリ‘Ａ’１１２に格納する。

実施形態において、ディレクトリ‘Ａ’１１２を示す位置情報は、ディレクトリ‘Ａ’を示す情報だけでなく、その親ディレクトリに関する情報も含まれ得る。言い換えれば、ファイル１ １２０のヘッダーに含まれる位置情報は、ディレクトリ‘Ａ’１１２が親ディレクトリとしてルートディレクトリ‘/’１１０を有する子ディレクトリであることを示すことができる。

ファイル３ １２４を伝送する場合、送信器１０は、ステップ５１６で、ファイル３ １２４が格納される位置情報としてディレクトリ‘Ｂ’１１４を示す情報をヘッダーに含める。この場合、受信器２０は、ファイル３ １２４を受信し、受信したファイル３ １２４のヘッダーに含まれる位置情報を確認し、それによって受信したファイル３ １２４をディレクトリ‘Ｂ’１１４に格納する。

実施形態において、ディレクトリ‘Ｂ’１１４を示す位置情報は、ディレクトリ‘Ｂ’を示す情報だけでなく、その親ディレクトリに関する情報も含まれ得る。言い換えれば、ファイル２ １２２のヘッダーに含まれる位置情報は、ディレクトリ‘Ｂ’１１４が、親ディレクトリとしてディレクトリ‘Ａ’１１２を有する子ディレクトリであり、ディレクトリ‘Ａ’が親ディレクトリとしてルートディレクトリ‘/’１１０を有する子ディレクトリであることを示すことができる。

図５に示す実施形態を要約すると、コンテンツファイルの送信時に、各ファイルは、コンテンツが格納されるコンテナ構造に関する情報を含むように構成される。図５の実施形態に示すように、伝送されるファイルを格納するための位置情報に対して、そのヘッダーは、ホスト情報‘Ｈｏｓｔ’、コンテンツ長情報‘Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ’、コンテンツタイプ情報‘Ｃｏｎｔｅｎｔ−Ｔｙｐｅ’、ファイル位置情報‘ＳＥＮＤＥＲ_ＬｏｃａｔｉｏｎＵＲＬ’、及びファイルタイプ情報‘Ｏｂｊｅｃｔ_Ｔｙｐｅ’のような追加情報が含まれ得る。

図５の実施形態では、送信器は伝送されるファイルのリストが獲得できる位置情報(例えば、ＵＲＬ)を含むように構成されるメタデータファイルを伝送する場合、受信器は、追加的なファイルリスト情報が要求される場合、ＵＲＬを用いてファイルの全体リストを獲得できる。

図６は、本発明の実施形態による汎用デバイス間のファイル伝送のための信号処理手順の他の例を示す。

図６に示す実施形態では、メタデータファイルで予め送信される制御情報を最小化し、コンテンツファイルの伝送時に制御情報の大部分を送信するハイブリッド伝送方式に基づく。図６のステップ６１０〜６１６は、図５のステップ５１０〜５１６に対応する。

しかしながら、図５に示した手順とは異なり、図６に示す手順は、初期メタデータファイルにより伝送される制御情報をアップデートするためのアップデートメタデータファイルを伝送する手順を追加に示す。

図６を参照すると、送信器１０は、ステップ６２０で、アップデートメタデータファイルを受信器２０に伝送する。伝送されるアップデートメタデータファイルを構成する制御情報のタイプは、初期伝送されるメタデータファイルを構成する制御情報のタイプと同一であり得る。しかしながら、アップデートメタデータファイルを構成する制御情報のタイプのうち少なくとも一つは、初期伝送されるメタデータファイルを構成する制御情報とは異なる値を有する。

アップデートメタデータファイルが伝送された後(例えば、ステップ６２０)、追加ファイル（例えば、ファイル４，５）は、アップデートメタデータファイルを構成する制御情報に基づき、送信器１０により伝送され(例えば、ステップ６２２)、受信器２０により受信される(例えば、ステップ６２４)。

図５において、受信器２０は、送信器１０により順次に伝送されるファイル１ １２０、ファイル２ １２２、及びファイル３ １２４を初期伝送されるメタデータファイルを、構成する制御情報と各ファイルのヘッダーに含まれる制御情報により受信して格納する。

追加ファイル４，５を送信するために、アップデートメタデータファイルは、ステップ６２０で送信される。アップデートメタデータファイルを構成する制御情報と各ファイルのヘッダーに含まれる制御情報に基づき、受信器２０は、送信器１０により順次に伝送されるファイル４，５を受信して定義されたコンテナ構造によって格納する。

ファイル４，５を伝送する場合、送信器１０は、ステップ６２２，６２４で、ファイル４，５が格納される位置情報としてディレクトリ‘Ｃ’１１６を示す情報をヘッダーに含む。この場合、受信器２０は、ファイル４，５を受信し、受信したファイル４，５のヘッダーに含まれる位置情報を確認することによって、受信したファイル４，５をディレクトリ‘Ｃ’１１６に格納する。

本実施形態では、ディレクトリ‘Ｃ’１１６を示す位置情報は、ディレクトリ‘Ｃ’を示す情報だけでなく、その親ディレクトリに関する情報も含むことができる。すなわち、ファイル４，５のヘッダーに含まれる位置情報は、ディレクトリ‘Ｃ’１１６がその親ディレクトリとしてディレクトリ‘Ｂ’１１４を有する子ディレクトリであり、ディレクトリ‘Ｂ’１１４がその親ディレクトリとしてディレクトリ‘Ａ’１１２を有する子ディレクトリであり、ディレクトリ‘Ａ’１１２がその親ディレクトリとしてルートディレクトリ‘/’１１０を有する子ディレクトリであることを示す。

図６に示す実施形態を要約よれば、コンテンツファイルの送信時に、各ファイルは、コンテンツが格納されるコンテナ構造に関する情報を含むように構成される。図６に示す実施形態において、伝送されるファイルの格納位置に関する位置情報に対して、ヘッダーは、ホスト情報‘Ｈｏｓｔ’、コンテンツ長情報‘Ｃｏｎｔｅｎｔ-Ｌｅｎｇｔｈ’、コンテンツタイプ情報‘Ｃｏｎｔｅｎｔ-Ｔｙｐｅ’、ファイル位置情報‘ＳＥＮＤＥＲ_ＬｏｃａｔｉｏｎＵＲＬ’、及びファイルタイプ情報‘Ｏｂｊｅｃｔ_Ｔｙｐｅ’のような追加情報を含む。

上記した実施形態において、最初に伝送された初期メタデータファイルと追加に伝送されたアップデートメタデータファイルは、伝送される全体ファイルの個数及び全体ファイルサイズに関する情報を含む。また、ファイルリストの一部を表現するために、これらは、全体ファイルのうちメタデータファイルに含まれるファイルリストのインデックス及び個数と、各ファイルの名称及びサイズ情報をさらに含むことができる。この情報は、各ファイルが獲得されるリソースＵＲＬをさらに含むことができる。この実施形態では、受信器２０は、ＨＴＴＰ ＧＥＴ方法を使用してコンテンツを獲得する。

以下、本発明の実施形態によりコンテナ構造情報を伝送する多様な実施形態について説明する。

図７は、本発明の実施形態による汎用デバイスの間でコンテナ構造情報を交換する一例を示す。図７の実施形態では、グループ形成前にコンテナ構造情報を伝送する。

図７を参照すると、送信器１０と受信器２０は、ステップ７１０，７１２で、周辺汎用デバイスを発見するためのプローブ要求メッセージを周期的又は非周期的に送信する。

送信器１０により送信されたプローブ要求メッセージを受信すると、受信器２０は、ステップ７１４で、プローブ応答メッセージを送信器１０に送信する。送信器１０は、受信器２０により送信されたプローブ応答メッセージを受信することによって受信器２０を認知する。

受信器２０により送信されたプローブ要求メッセージを受信する場合、送信器１０は、 ステップ７１６で、プローブ応答メッセージを受信器２０に送信する。受信器２０は、送信器１０により送信されたプローブ応答メッセージを受信することによって送信器１０を認知する。

上記した動作により、送信器１０と受信器２０は、相互に認知する。

相互に認知した後に、送信器１０と受信器２０は、ステップ７１８で、相互にサービス情報を交換するサービス発見交換手順を遂行する。例えば、サービス発見交換手順は、送信器１０が、自身が提供するサービスを受信器２０がサポートするか否かを判定する。サービス発見交換手順は、受信器２０が送信器１０のクエリに対応する場合に遂行することができる。

その後、送信器１０と受信器２０は、ステップ７２０で、Ｐ２Ｐ(Peer-to-Peer)サービスのための初期設定手順を遂行する。送信器１０は、Ｐ２Ｐサービスのための初期設定手順で、ファイル伝送のためのメタデータファイルを受信器２０に伝送する。

図７の実施形態において、送信器１０は、Ｐ２Ｐサービスを要求するＰ２Ｐサービス要求メッセージを受信器２０に送信する。Ｐ２Ｐサービス要求メッセージを送信する場合、送信器１０は、Ｐ２Ｐサービス要求メッセージにメタデータファイルを含む。

受信器２０は、Ｐ２Ｐサービス要求メッセージを受信する場合、送信器１０により要求されるＰ２Ｐサービスを受け入れるか否かを判定する。受信器２０は、Ｐ２Ｐサービス要求メッセージからメタデータファイルを獲得する。

受信器２０は、送信器１０により要求されるＰ２Ｐサービスの許可を判定する場合、Ｐ２Ｐサービス要求メッセージに対応するＰ２Ｐサービス応答メッセージ及びＰ２Ｐサービスを承認及び許可するＰ２Ｐサービス承認メッセージを送信器１０に送信する。

上記した動作で、送信器１０によりメタデータファイルが受信器２０に伝送された後、グループ形成手順は、ステップ７２２，７２４で遂行される。

グループ形成手順は、Ｐ２Ｐサービスのために、グループオーナー(ＧＯ)を決定する手順を含む。例えば、送信器１０は、グループ形成のために、ＧＯに対する交渉を要請するＧＯ交渉要求メッセージを受信器２０に送信する。これに応答して、受信器２０は、ＧＯ交渉応答メッセージを送信器１０に伝送する。これら２つのステップは、図７のステップ７２２からなされる。

同様に、受信器２０は、グループ形成のために、ＧＯに対する交渉を要請するＧＯ交渉要求メッセージを送信器１０に送信する。これに応答して、送信器１０は、ＧＯ交渉応答メッセージとＧＯを承認及び許可するためのＧＯ交渉承認メッセージを受信器２０に送信する。これら２つのステップは、図７のステップ７２４からなされる。

図７に示す実施形態では、送信器１０はＧＯであると決定される。

ＧＯが決定されると、送信器１０と受信器２０は、ステップ７２８で、ＷＳＣ(Wi-Fi Simple Configure)交換手順を遂行する。ＷＳＣ交換手順以後に、送信器１０は、ステップ７３０で、受信器２０にコンテンツファイルを伝送する。伝送されるファイルの各々のヘッダーは、該当ファイルが格納されるコンテナ構造による位置情報を含む。

この動作では、グループ形成のためのＧＯを決定する前に、送信器１０は、受信器２０にメタデータファイルを伝送する。

図８は、本発明の実施形態による汎用デバイスの間でコンテナ構造情報を交換する他の例を示す。図８の実施形態では、グループ形成後にコンテナ構造情報が伝送される。

図８を参照すると、送信器１０と受信器２０は、ステップ８１０，８１２で、周辺汎用デバイスを発見するためのプローブ要求メッセージを周期的又は非周期的に送信する。

送信器１０により送信されたプローブ要求メッセージを受信すると、受信器２０は、ステップ８１４で、プローブ応答メッセージを送信器１０に送信する。送信器１０は、受信器２０により送信されたプローブ応答メッセージを受信することによって、受信器２０を認知する。

受信器２０により送信されたプローブ要求メッセージを受信すると、送信器１０は、ステップ８１６で、プローブ応答メッセージを受信器２０に送信する。受信器２０は、送信器１０により送信されたプローブ応答メッセージを受信することによって送信器１０を認知する。

この動作により、送信器１０と受信器２０は、相互に認知する。

相互に認知した後に、送信器１０と受信器２０は、ステップ８１８で、相互にサービス情報を交換するサービス発見交換手順を遂行する。

図示されていないが、送信器１０と受信器２０は、Ｐ２Ｐサービスのための初期設定手順を遂行する。初期設定に対して、送信器１０は、Ｐ２Ｐサービスを要請するＰ２Ｐサービス要求メッセージを受信器２０に送信する。受信器２０は、Ｐ２Ｐサービス要求メッセージが受信される場合、送信器１０により要請されるＰ２Ｐサービスを受け入れるか否かを判定する。受信器２０は、送信器１０により要請されたＰ２Ｐサービスが許可されると判定した場合、Ｐ２Ｐサービス要求メッセージに対応するＰ２Ｐサービス応答メッセージ及びＰ２Ｐサービスを承認及び許可するＰ２Ｐサービス承認メッセージを送信器１０に送信する。

Ｐ２Ｐサービスのための初期設定が遂行された後に、送信器１０及び受信器２０は、ステップ８２０で、グループ形成手順を遂行する。図８でのグループ形成手順は、図７のステップ７２２，７２４，７２６と同一の手順により遂行される。図７と同様に、図８では送信器１０がＧＯであると決定されると仮定する。

ＧＯと決定された送信器１０は、ステップ８２２，８２６で、受信器２０に対する認証及び結合手順を遂行する。このような手順において、送信器１０は、特定周波数を用いて無指向性断続形信号であるビーコン(beacon）を周期的に送信する。その後、送信器１０は、受信したビーコンを有する受信器２０の要請により、所定の認証手順によって受信器２０に対する認証を遂行する。送信器１０は、受信器２０に対する認証が成功する場合、受信器２０との結合を遂行する。

上記の認証及び結合以後に、送信器１０と受信器２０は、ステップ８２４で、ＷＳＣ交換手順を遂行する。

ＷＳＣ交換手順を遂行する場合、送信器１０は、ファイル伝送のための一部制御情報を含むように構成されるメタデータファイルを受信器２０に伝送する。グループ形成手順で遂行されるＷＳＣ交換時にメタデータファイルを伝送する一例を、図９に示す。これに関する具体的な説明は、後述する。

認証及び結合が遂行される送信器１０及び受信器２０は、ファイル伝送のための物理的接続を初期化する。例えば、４ウェイハンドシェイク手順により、送信器１０及び受信器２０は、ファイル伝送のための経路であるＴＣＰ(Transmission Control Protocol)接続を初期化する。４ウェイハンドシェイク手順により、送信器１０及び受信器２０は、実際にファイルの送受信前に、ファイルの送受信を遂行する準備ができることを認知する。

４ウェイハンドシェイク手順において、受信器２０は、ＧＯとして決定される送信器１０から接続を要請する。この場合、受信器２０は、送信器１０に任意の同期(ＳＹＮ)パケットを送信することができる。受信器２０から同期パケットを受信する場合、送信器１０は、これに応答してＡＣＫ信号とその同期パケットを受信器２０に送信する。送信器１０から同期信号を受信する場合、受信器２０は、これに対応してＡＣＫ信号を送信器１０に送信する。

この４ウェイハンドシェイク手順が完了すると、送信器１０及び受信器２０は、正常にファイルを相互に交換することができる。

したがって、送信器１０は、ステップ８３０で、受信器２０にコンテンツファイルを伝送する。伝送される各ファイルのヘッダーは、該当ファイルが格納されるコンテナ構造による位置情報を含む。

この動作では、送信器１０は、グループ形成プロセスで、受信器２０にメタデータファイルを伝送する。

図９は、図８で提案するメタデータファイルの伝送のための具体的な信号処理手順の一例を示す。図９に示す信号処理手順は、ＷＳＣの交換時にＭ８メッセージにメタデータファイルを含めて伝送する一例を示す。

図９を参照すると、受信器２０は、ステップ９１０で、拡張認証プロトコル(ＥＡＰ)によりアクセスを要求するＥＡＰＯＬ-Ｓｔａｒｔメッセージを送信器１０に送信する。

ＥＡＰＯＬ-Ｓｔａｒｔメッセージを受信する場合、送信器１０は、ステップ９１２で、受信器２０にＥＡＰ識別を要求するＥＡＰＯＬ-Ｒｅｑｕｅｓｔ/Ｉｄｅｎｔｉｔｙメッセージを送信し、受信器２０は、ステップ９１４で、そのアイデンティティを伝送するＥＡＰＯＬ-Ｒｅｓｐｏｎｓｅ/Ｉｄｅｎｔｉｔｙメッセージを送信器１０に送信する。

その後、送信器１０及び受信器２０は、所定の認証キー（例えば、ＰＩＮ）に対する検証手順を遂行する。ＰＩＮに対して、ユーザーは、図９に示す手順の開始前に汎用デバイス別に予め設定できる。

送信器１０は、ステップ９１６で、ＰＩＮに対する検証手順の開始を要請するＥＡＰ-Ｒｅｑｕｅｓｔ(Ｓｔａｒｔ)メッセージを受信器２０に送信する。ＰＩＮに対する検証が完了する場合、受信器２０は、ステップ９３４で、ＰＩＮ検証手順の終了を要請するＥＡＰ-Ｒｅｓｐｏｎｓｅ(Ｄｏｎｅ)メッセージを送信器１０に送信する。

ＰＩＮに対する検証手順で、受信器２０は、ステップ９１８，９２２，９２６，９３０で、予め設定されたＰＩＮ Ｍ１，Ｍ３，Ｍ５，Ｍ７を所定のメッセージＥＡＰ-Ｒｅｓｐｏｎｓｅ(Ｍ＃)を用いて送信器１０に伝送する。送信器１０は、ステップ９１８，９２２，９２６，９３０で、予め設定されたＰＩＮ Ｍ２，Ｍ４，Ｍ６，Ｍ８を所定のメッセージＥＡＰ-Ｒｅｓｐｏｎｓｅ（Ｍ＃)を用いて受信器２０に伝送する。

送信器１０は、受信器２０に所定のメッセージＥＡＰ-Ｒｅｓｐｏｎｓｅ(Ｍ８)を用いてメタデータファイルを伝送する。

送信器１０は、ステップ９３６で、受信器２０からＰＩＮ検証手順の終了を要請するＥＡＰ-Ｒｅｓｐｏｎｓｅ(Ｄｏｎｅ)メッセージを受信する場合、すべての手順を終了するように指示するＥＡＰ-Ｆａｉｌメッセージを受信器２０に送信する。

図９に示す実施形態において、送信器１０は、ＷＳＣセキュリティチャンネルを介してメタデータファイルを伝送することで、より安全に伝送ファイル及びコンテナ構造情報を受信器２０に伝送することが可能になる。

図１０は、本発明の実施形態による汎用デバイスの間でコンテナ構造情報を交換するもう一つの例を示す。図１０に示す実施形態では、インターネットプロトコル(ＩＰ）の割り当て以後にコンテナ構造情報が伝送される。

図１０に示す信号処理手順でステップ１０１０〜１０２８は、図８に示したステップ８１０〜８２８に対応する。したがって、後述するステップ１０１０〜１０２８に関する具体的な説明は省略する。

図１０を参照すると、送信器１０は、ステップ１０３０で、４ウェイハンドシェイク手順を通じて受信器２０とのＩＰ接続を生成する。ＩＰ接続が生成される送信器１０と受信器２０は、ステップ１０３２で、コンテンツファイル伝送に関する一部の制御情報を共有するための手順を遂行する。

送信器１０は、受信器２０とのＩＰ接続に基づいてメタデータファイルを伝送する。送信器１０により伝送されるメタデータファイルは、コンテンツファイル伝送のための一部の制御情報を含む。メタデータファイルに含まれるファイル伝送に関する一部制御情報については、上記したようである。

受信器２０は、送信器１０からメタデータファイルを受信すると、これに対応して応答メッセージを送信器１０に送信する。

送信器１０は、ステップ１０３４で、受信器２０にコンテンツファイルを伝送する。伝送される各ファイルのヘッダーは、該当ファイルが記録されるコンテナ構造による位置情報を含む。

この動作では、送信器２０は、送信器１０と受信器２０との間のＩＰ割り当てがなされた後に、受信器２０にメタデータファイルを伝送する。

図１１は、本発明の実施形態による送信汎用デバイスでファイルを伝送するための送信装置の構成を示す。

図１１を参照すると、格納部１１１０は、送信装置で使用可能な特定コンテンツに対応するファイルを固有なコンテナ構造を有する一つ以上のディレクトリに格納する。格納部１１１０は、例えば制御器の制御により、特定コンテンツに対応するコンテナ構造に関する情報及び特定コンテンツによりディレクトリ別に格納されるファイルを出力する。格納部１１１０に特定コンテンツに対応するファイルが格納される実施形態について、図１の実施形態に関連して説明する。

メッセージ生成部１１１２は、格納部１１１０から必要な情報を読み取って伝送メッセージを生成する。メッセージ生成部１１１２は、特定コンテンツに対応してファイル伝送に対して要求される場合に伝送メッセージを生成してもよい。メッセージ生成部１１１２は、本発明の実施形態によりメタデータファイル又は特定のコンテンツに対応するファイルを含む。実施形態別にメタデータファイル又は特定のコンテンツに対応するファイルのヘッダー情報として含まれるコンテナ構造情報については上記したので、ここでは、その追加説明は省略する。

メッセージ生成部１１１２が必要なメッセージを生成する時点は、適用される実施形態に従って変わる。例えば、ファイル伝送のための一部制御情報を含むメタデータファイルは、グループ形成手順以前又はグループ形成手順中に生成及び伝送され、あるいはＩＰ割り当て以後に生成され得る。

一方、メッセージ生成部１１１２は、同一の時点でメタデータファイルを生成し、各実施形態により、これを実際に伝送する送信器により伝送時点が別々に適用することができる。

送信部１１１４は、メッセージ生成部１１１２により生成されたメッセージを受信側デバイスに送信する。送信部１１１４は、生成されたメッセージを受信器に伝送する動作は、図４〜図１０に示す信号処理手順によって遂行される。送信部１１１４による代表的なメッセージは、メタデータファイルを有するメッセージとコンテンツファイルを有するメッセージを含む。さらに、代表的なメッセージが図７〜図１０に示す信号処理手順で伝送されるメッセージを含むことができることは、当該技術分野で通常の知識を有する者には明らかである。

図１２は、本発明の実施形態による汎用デバイスでファイルを受信する受信装置の構成を示す。

図１２を参照すると、受信部１２１０は、送信側汎用デバイスから送信されるメッセージを受信し、受信したメッセージをメッセージハンドラ１２１２に伝送する。受信部１２１０により受信される代表的なメッセージは、メタデータファイルを有するメッセージとコンテンツファイルを有するメッセージとを含むことができる。例えば、受信部１２１０は、図４〜図１０に定義された手順に従ってメッセージを受信する。

メッセージハンドラ１２１２は、受信部１２１０から伝送される受信メッセージに含まれているメタデータファイル又はコンテンツファイルを獲得する。メッセージハンドラ１２１２は、獲得したメタデータファイルを構成する制御情報と獲得したファイルのヘッダーに含まれた制御情報により決定されるコンテナ構造によって格納部１２１４にディレクトリを構成する。その後、メッセージハンドラ１２１２は、獲得したファイル又は制御情報に含まれた位置情報を用いて読み取るファイルを、構成されたディレクトリのうち特定のディレクトリに格納する。

例えば、図１の格納コンテンツを用いて、メッセージハンドラ１２１２は、メタデータファイル及び受信したファイルのヘッダーから獲得した制御情報に基づき、親ディレクトリとしてルートディレクトリを有するディレクトリ‘Ａ’を生成し、親ディレクトリとしてディレクトリ‘Ａ’を有するディレクトリ‘Ｂ’を生成し、ディレクトリ‘Ｂ’を親ディレクトリとして有するディレクトリ‘Ｃ’を生成する。

その後、メッセージハンドラ１２１２は、ファイル１を受信し、ルートディレクトリに格納し、ファイル２を受信してディレクトリ‘Ａ’に格納し、ファイル３を受信してディレクトリ‘Ｂ’に格納する。

上記したメッセージハンドラ１２１２によるメッセージ処理を通じて、ファイルは、図１に示したコンテナ構造による格納部１２１４に格納することができる。

図１１に示した構造を有する汎用デバイスの送信装置と図１２に示す構造を有する汎用デバイスの受信装置は、図４〜図６に示した信号処理手順のうちいずれか一つによってファイルを送受信することができる。汎用デバイス間のファイル伝送は、図７〜図１０に示した信号処理手順のうちいずれか一つにより遂行される。

図１３は、本発明の実施形態による汎用デバイスでファイルを送受信するための方法を示すフローチャートである。図１３において、汎用デバイスがグループオーナー(ＧＯ)であるか否かによって、汎用デバイスは、ファイルの伝送動作を遂行するか、あるいはファイルを受信及び記録する動作を遂行するかを判定する。図１３のステップ１３１８〜１３２８は送信動作に対応し、ステップ１３３０〜１３４０は、受信動作に対応する。

図１３を参照すると、汎用デバイスは、ステップ１３１０で、コンテンツファイルを伝送する他の汎用デバイスを発見するための手順を遂行する。例えば、Ｐ２Ｐサービスのための汎用デバイス発見手順において、汎用デバイスは、プローブ要求メッセージを周期的又は非周期的に送信し、プローブ要求メッセージに対応するプローブ応答メッセージを受信する場合に他の汎用デバイスを検索することができる。また、他の汎用デバイスは、同一の動作により、プローブ要求メッセージを送信する汎用デバイスを認知する必要がある。

コンテンツファイルを伝送する汎用デバイスが相互に認知されると、第１の汎用デバイスは、ステップ１３１２で、認知した相手汎用デバイスにより提供されるサービスを確認する。例えば、相手汎用デバイスがＷｉ-Ｆｉファイル伝送サービスをサポートする場合、第１の汎用デバイスは、以後のＷｉ-Ｆｉファイル伝送動作を遂行するために他の汎用デバイスを制御することができる。

相手汎用デバイスが第１の汎用デバイスにより所望するサービスをサポートすると判定した場合、汎用デバイスは、ステップ１３１４で、相手汎用デバイスとのＧＯ交渉(negotiation)手順を遂行する。ＧＯ交渉手順は、特定コンテンツに対するファイルを提供する汎用デバイスを決定する。

第１の汎用デバイスは、ステップ１３１６で、ＧＯ交渉手順により、自身がＧＯとして決定されるか否かを判定する。この汎用デバイスは、自身がＧＯであると決定される場合、コンテンツファイルを伝送する送信側汎用デバイスとして動作する。しかしながら、一方で、相手汎用デバイスがＧＯとして決定される場合には、第１の汎用デバイスは、相手汎用デバイスからコンテンツファイルを受信する受信側汎用デバイスとして動作する。

第１の汎用デバイスは、自身がＧＯであると決定される場合、送信動作のためにステップ１３１８に進行し、自身がＧＯであると決定されない場合には、受信動作のためにステップ１３３０に進行する。

まず、送信動作について具体的に説明する。第１の汎用デバイスは、ステップ１３１８で、相手汎用デバイスとのＷＳＣ交換手順を遂行する。ＷＳＣ交換手順は、以後相手汎用デバイスへのファイル伝送時にセキュリティのために遂行される手順である。

第１の汎用デバイスは、ＷＳＣ交換手順を遂行する間に相手汎用デバイスにメタデータファイルを伝送する。伝送されるメタデータファイルは、相手汎用デバイスが受信したファイルを所定のコンテナ構造により配置されるディレクトリ別に格納するために要求される制御情報のうちの一部を含む。メタデータファイルに含まれる一部の制御情報は、順次に伝送される全体ファイルの個数、全体ファイルサイズ、代表ファイル名、ファイルリスト記録位置、及び各ファイルの名称及びサイズのうち少なくとも一つを含むことができる。

他の実施形態において、メタデータファイルは、ＧＯを決定するための手順が遂行される前に相手汎用デバイスに提供することができる。しかしながら、この場合、汎用デバイス自身がコンテンツファイルを相手汎用デバイスに伝送することを前提としなければならない。すなわち、汎用デバイスは、相手汎用デバイスからＰ２Ｐサービスを要請する場合に、メタデータファイルを伝送し、伝送したメタデータに応答して相手汎用デバイスからＰ２Ｐサービス応答及びＰ２Ｐサービス許可を受信することができる。

汎用デバイスは、メタデータファイルに含まれる制御情報を構成するために、伝送されるファイルの全体個数及び伝送容量を測定する追加動作を遂行することができる。

ＷＳＣ交換手順の実行が完了した後、汎用デバイスは、ステップ１３２０で、４ウェイハンドシェイク手順を遂行する。４ウェイハンドシェイク手順の遂行により、汎用デバイスと相手汎用デバイスとの間にファイル伝送のための経路であるＴＣＰ接続が初期化される。４ウェイハンドシェイク手順以後に、汎用デバイスと相手汎用デバイスは、ファイル送受信の遂行を準備する。

ステップ１３２２において、汎用デバイスは、ステップ１３２０で４ウェイハンドシェイク手順により初期化されるＴＣＰ接続のＩＰ接続を生成する。

ＴＣＰ接続の初期化及びＩＰ接続の生成は、汎用デバイスが、自身が伝送するメタデータファイルに応答して相手汎用デバイスから確認を受信する場合のみに遂行される。

汎用デバイスは、ＩＰ接続を生成する場合、相手汎用デバイスにメタデータファイルを伝送する。伝送されるメタデータファイルは、他の実施形態に提案されたメタデータファイルと同一の制御情報を含む。

汎用デバイスは、ＩＰ接続が生成されると、ステップ１３２４で、メタデータファイルを生成する間に伝送するように決定されるファイルを順次に伝送する。伝送される各ファイルのヘッダーは、該当ファイルが格納される位置に関する情報を含む。また、ヘッダーは、該当ファイルが格納されるコンテナ構造で配列されるディレクトリのうちいずれか一つを示す情報を有することができる。

全体ファイルに対する伝送が完了する場合、汎用デバイスは、ステップ１３２６で、追加的なメタデータファイルの伝送が必要であるか否かを判定する。例えば、汎用デバイスは、特定コンテンツのために伝送されるファイルがさらに存在し、及び/又は汎用デバイスが最初に伝送されるメタデータファイルを用いて相手汎用デバイスに伝送される制御情報の変更が必要である場合、追加的なメタデータファイルが必要であると判定することができる。

追加的なメタデータファイルが必要である場合、汎用デバイスは、ステップ１３２８で、アップデートされたメタデータファイルを生成し、生成したメタデータファイルを相手汎用デバイスに伝送する。追加的なメタデータファイルが不要である場合、汎用デバイスは、すべての送信関連動作を完了する。

他の実施形態において、送信動作時に、汎用デバイスは、別途の基準により全体リストを生成し、提供される特定コンテンツに対するファイルを獲得できる位置情報に関する情報(例えば、ＵＲＬ)をメタデータファイルにバインディングして相手汎用デバイスに伝送することができる。この場合、汎用デバイスは、コンテンツファイルを相手汎用デバイスに伝送するための追加手順を遂行しないこともある。

しかしながら、上記した送信動作において、汎用デバイスは、提供されるコンテンツの全体ファイルに対する一部制御情報に対するメタデータファイルを生成し、生成したメタデータファイルを相手汎用デバイスに伝送すると仮定する。

次に、受信動作について詳細に説明する。汎用デバイスは、ステップ１３３０で、相手汎用デバイスとのＷＳＣ交換手順を遂行する。ＷＳＣ交換手順は、以後に相手汎用デバイスからファイル受信時にセキュリティを提供するように遂行される。

この実施形態において、汎用デバイスは、ＷＳＣ交換手順を遂行する間に、相手汎用デバイスからメタデータファイルを受信する。受信したメタデータファイルは、所定のコンテナ構造により配列されるディレクトリ別に受信したコンテンツファイルを格納するために要求される制御情報の一部を含む。メタデータファイルの一部制御情報は、順次に伝送される全体ファイルの個数、全体ファイルサイズ、代表ファイル名、ファイルリスト記録位置、及び各ファイルの名称及びサイズのうち少なくとも一つを含むことができる。

他の実施形態では、メタデータファイルは、ＧＯを決定するための手順が遂行される前に相手汎用デバイスにより提供することができる。しかしながら、この場合、相手汎用デバイス自身がコンテンツファイルを汎用デバイスに伝送することを前提としなければならない。すなわち、汎用デバイスは、相手汎用デバイスからＰ２Ｐサービスに対する要求を受信した場合、メタデータファイルを受信し、この要求に応答して相手汎用デバイスにＰ２Ｐサービス応答とＰ２Ｐサービス許可メッセージを伝送する。

ＷＳＣ交換手順の遂行が完了した後、汎用デバイスは、ステップ１３３２で、４ウェイハンドシェイク手順を遂行する。４ウェイハンドシェイク手順の実行により、汎用デバイスは、相手汎用デバイスからファイルを受信するための経路であるＴＣＰ接続を初期化する。言い換えれば、４ウェイハンドシェイク手順により、汎用デバイスは、相手汎用デバイスから実際にファイルを受信する前に、ファイル受信を遂行する準備ができることを確認できる。

汎用デバイスは、ステップ１３３４で、ステップ１３３２で４ウェイハンドシェイク手順により初期化されるＴＣＰ接続のＩＰ接続を生成する。

ＴＣＰ接続の初期化とＩＰ接続の生成は、汎用デバイスが、自身が受信されるメタデータファイルに応答して相手汎用デバイスに確認を伝送する場合のみに遂行することができる。

汎用デバイスは、ＩＰ接続を生成する場合に相手汎用デバイスからメタデータファイルを受信することができる。受信されるメタデータファイルは、他の実施形態で提案されたメタデータファイルと同一の制御情報を含む。

ＩＰ接続が生成される場合、汎用デバイスは、ステップ１３３６で、メタデータファイルに含まれる制御情報により確認した全体ファイル(又はターゲットファイル)を順次に受信する。受信したファイル各々のヘッダーは、該当ファイルが格納される位置に関する情報を含む。また、ヘッダーは、該当ファイルが格納されるコンテナ構造で配列されるディレクトリのうちいずれか一つを示す情報を有することができる。

汎用デバイスは、順次に受信したターゲットファイルを所定のコンテナ構造で配列される、ターゲットファイルのヘッダーから識別される位置に関する情報により決定される一つ以上のディレクトリに格納する。汎用デバイスは、順次に受信したすべてのファイル特定のディレクトリに格納する。

汎用デバイスは、受信したファイルの記録に使用される所定のコンテナ構造を決定し、あるいは所望するファイルを獲得するために、予め相手汎用デバイスからメタデータファイルを用いて受信される一部制御情報を使用する。

汎用デバイスは、受信したすべてのファイルを特定のディレクトリに格納した後に、ステップ１３４０で、相手汎用デバイスからアップデートメタデータファイルが受信されたか否かを判定する。

汎用デバイスは、アップデートメタデータファイルが受信された場合、ステップ１３３６〜１３３８で、アップデートメタデータファイルにより識別された少なくとも一つの追加ファイルを受信して特定のディレクトリに格納する動作を遂行する。

ステップ１３４０でアップデートメタデータファイルが受信されない場合、汎用デバイスは、すべての受信関連動作を完了する。

他の実施形態において、相手汎用デバイスは、受信動作で、別途の基準に基づいて全体リストを生成し、提供される特定のコンテンツに対するファイルが獲得される位置に関する情報(例えば、ＵＲＬ)をメタデータファイルにバインディングして相手汎用デバイスに伝送する。この場合、汎用デバイスは、メタデータファイルで受信した制御情報に基づいて、すべてのコンテンツファイルを所望のコンテナ構造により配列される特定ディレクトリに格納することができる。

以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲の記載及びこれと均等なものに基づいて定められる本発明の範囲及び趣旨を逸脱することなく、形式や細部の様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。

１０ 送信器
２０ 受信器
１１０ ルートディレクトリ‘/’
１１２ ディレクトリ‘Ａ’
１１４ ディレクトリ‘Ｂ’
１１６ ディレクトリ‘Ｃ’
１２０ ファイル１
１２２ ファイル２
１２４ ファイル３
１１１０ 格納部
１１１２ メッセージ生成部
１１１４ 送信部
１２１０ 受信部
１２１２ メッセージハンドラ
１２１４ 格納部

Claims (18)

1. ＨＴＴＰ(Hypertext transfer protocol）を用いて、第１のデバイスで所定のディレクトリ構造に格納されるファイルを第２のデバイスに伝送する方法であって、
   前記格納されるファイルのうち伝送される複数のファイルを識別するステップと、
   前記識別したファイルと関連するＵＲＬ(uniform resource locator）リストに関する情報と、前記所定のディレクトリ構造に基づく前記第２のデバイスでのディレクトリ構造に関する情報を含むマークアップ言語で構成されたメタデータファイルを生成するステップと、
   前記ＨＴＴＰを用いて、前記メタデータファイルを前記第２のデバイスに伝送するステップと、
   前記識別したファイルのうちの一つを格納するディレクトリの位置に関する情報を含むヘッダーと、前記識別したファイルのうちの一つを含むＨＴＴＰメッセージを構成するステップと、
   前記ＨＴＴＰを用いて、前記ＵＲＬリストに関連する前記識別したファイルに基づいて、前記第２のデバイスに前記ＨＴＴＰメッセージを伝送するステップと、
   を有することを特徴とする方法。
2. 前記メタデータファイルは、前記識別したファイルの全体個数、前記識別したファイルの全体サイズ、代表ファイル名、ファイルリスト記録位置、及び前記識別したファイルのそれぞれの名前及びサイズのうち少なくとも一つを含むメタデータファイルであることを特徴とする請求項１に記載の方法。
3. 前記識別したファイルは、前記第２のデバイスが前記識別したファイルを受信するか否かによって伝送されるファイルであることを特徴とする請求項１に記載の方法。
4. 前記メタデータファイルを伝送するステップは、
   前記第２のデバイスとグループ形成のための手順を遂行する中に前記メタデータファイルを前記第２のデバイスに伝送するステップであることを特徴とする請求項２に記載の方法。
5. 前記ヘッダーは、前記識別したファイルの長さ及びタイプに関する情報をさらに含むことを特徴とする請求項１〜４のいずれか１項に記載の方法。
6. ＨＴＴＰ(Hypertext transfer protocol）を用いるファイルを伝送する装置であって、
   所定のディレクトリ構造によってファイルを格納するように構成される格納部と、
   前記格納部に格納されたファイルのうち伝送される複数のファイルを識別し、
   前記識別したファイルと関連するＵＲＬ(uniform resource locator）リストに関する情報と、前記所定のディレクトリ構造に基づく受信デバイスでのディレクトリ構造に関する情報を含むマークアップ言語で構成されたメタデータファイルを生成し、前記識別したファイルのうちの一つを格納するディレクトリの位置に関する情報を含むヘッダーと、前記識別したファイルのうちの一つを含むＨＴＴＰメッセージを構成するメッセージ生成部と、
   前記メッセージ生成部により生成される前記メタデータファイルを前記受信デバイスに伝送し、前記ＵＲＬリストに関連する前記識別したファイルに基づいて、前記メッセージ生成部により構成されたＨＴＴＰメッセージを前記受信デバイスに送信する送信部と、
   を含むことを特徴とする装置。
7. 前記メタデータファイルは、前記識別したファイルの全体個数、前記識別したファイルの全体サイズ、代表ファイル名、ファイルリスト記録位置、前記識別したファイル各々の名称及びサイズのうち少なくとも一つを含むメタデータファイルであることを特徴とする請求項６に記載の装置。
8. 前記識別したファイルは、前記受信デバイスが前記識別したファイルを受信するか否かによって伝送されるファイルであることを特徴とする請求項６に記載の装置。
9. 前記送信部は、
   前記受信デバイスとグループ形成のための手順を遂行する間に前記メタデータファイルを前記受信デバイスに伝送することを特徴とする請求項７に記載の装置。
10. 前記ヘッダーは、前記識別したファイルの長さ及びタイプに関する情報を含むことを特徴とする請求項６〜９のうちいずれか１項に記載の装置。
11. ＨＴＴＰ(Hypertext transfer protocol）を用いて、所定のディレクトリ構造によりファイルを受信及び格納する方法であって、
    前記所定のディレクトリ構造により配置された一つ以上のディレクトリにファイルを格納するために要求されるＵＲＬ(uniform resource locator）リストに関する情報と、前記所定のディレクトリ構造に基づく第２のデバイスでのディレクトリ構造に関する情報を含むマークアップ言語で構成されたメタデータファイルを受信するステップと、
    前記ＨＴＴＰを用いて、ＨＴＴＰメッセージを受信するステップと、
    前記メタデータファイルを通じて受信した前記ＵＲＬリストに関する情報と、前記受信したＨＴＴＰメッセージのヘッダーに含まれるディレクトリ情報に基づいて、前記所定のディレクトリ構造により配置される一つ以上のディレクトリに前記受信したＨＴＴＰメッセージのファイルを格納するステップと、を有することを特徴とする方法。
12. 前記メタデータファイルは、前記受信されるファイルの全体個数、前記受信されるファイルの全体サイズ、代表ファイル名、ファイルリスト記録位置、前記受信されるファイル各々の名称及びサイズのうち少なくとも一つを含むことを特徴とする請求項１１に記載の方法。
13. 前記メタデータファイルを受信するステップは、
    送信デバイスとグループ形成のための手順を遂行する間に前記メタデータファイルを前記送信デバイスから受信するステップであることを特徴とする請求項１２に記載の方法。
14. 前記ヘッダーは、前記ファイルの長さ及びタイプに関する情報をさらに含むことを特徴とする請求項１１〜１３のうちいずれか１項に記載の方法。
15. ＨＴＴＰ(Hypertext transfer protocol）を用いて、所定のディレクトリ構造によりファイルを受信及び格納する装置であって、
    前記所定のディレクトリ構造により配置された前記ファイルを格納するために要求されるＵＲＬ(uniform resource locator）リストに関する情報と、前記所定のディレクトリ構造に基づく第２のデバイスでのディレクトリ構造に関する情報を含むマークアップ言語で構成されたメタデータファイルを受信し、前記ＨＴＴＰを用いて、ＨＴＴＰメッセージを受信する受信部と、
    前記メタデータファイルを通じて受信した前記ＵＲＬリストに関する情報と前記受信したＨＴＴＰメッセージのヘッダーに含まれているディレクトリ情報に基づいて前記所定のディレクトリ構造により配置される前記受信したＨＴＴＰメッセージのファイルを格納するディレクトリを決定するメッセージ処理部と、
    前記受信したＨＴＴＰメッセージのファイルを前記所定のディレクトリ構造により配置されたディレクトリのうち前記メッセージ処理部により決定されたディレクトリに格納する格納部と、を含むことを特徴とする装置。
16. 前記メタデータファイルは、前記受信されるファイルの全体個数、前記受信されるファイルの全体サイズ、代表ファイル名、ファイルリスト記録位置、前記受信されるファイル各々の名称及びサイズのうち少なくとも一つを含むことを特徴とする請求項１５に記載の装置。
17. 前記受信部は、
    送信デバイスとグループ形成のための手順を遂行する間に前記メタデータファイルを前記送信デバイスから受信することを特徴とする請求項１６に記載の装置。
18. 前記ヘッダーは、前記ファイルの長さ及びタイプに関する情報をさらに含むことを特徴とする請求項１５〜１７のうちいずれか１項に記載の装置。

Images