WO2006046446A1

WO2006046446A1 - 送信機器、受信機器、およびファイル転送システム

Info

Publication number: WO2006046446A1
Application number: PCT/JP2005/019189
Authority: WO
Inventors: Toshiharu Koshino; Hideaki Takechi; Takumi Tanabe; Yousuke Suzuki; Naonori Kato
Original assignee: Matsushita Electric Industrial Co., Ltd.
Priority date: 2004-10-26
Filing date: 2005-10-19
Publication date: 2006-05-04
Also published as: JPWO2006046446A1; EP1806877A1; US20080091830A1; CN101048989A; KR20070083649A

Abstract

　本発明は、送信機器から自発的に受信機器へファイルを転送するファイル転送システムにおいて、ファイル転送が長時間にわたり中断される場合であっても、ファイル転送に係る処理を効率的に実行するための送信機器、受信機器およびファイル転送システムを提供する。　本発明のファイル転送システムにおいて、受信機器であるシンク機器は、送信機器であるソース機器から受信する、ファイルを構成するファイルデータを保存し、ソース機器から保存済サイズを問い合わせられると、保存済サイズをソース機器に送信する。また、ソース機器は、ファイル転送の中断を検出し、ファイル転送を中断が検出した後に、シンク機器に保存済データサイズを問い合わせる。更に、その問い合わせに応じてシンク機器が応答した保存済データサイズに基づき、ファイルを構成する残りのファイルデータを送信する。

Description

明細書

送信機器、受信機器、およびファイル転送システム

技術分野

[0001] 本発明はネットワークを介してファイル転送を行うための送信機器、受信機器およびフアイル転送システムに関する。

背景技術

[0002] 近年、 xDSLや光ファイバ一などのブロードバンド環境が整ったことにより、企業、一般家庭を問わずインターネット接続が急速に普及してきている。また、家庭内のパ一ソナルコンピュータ（PC)や家電機器を Ethernet (登録商標）や無線 LANなどで接続するホームネットワーク環境も一般ィ匕してきている。この様な状況の中で、 PCだけでなく、テレビや DVDレコーダ、エアコン、冷蔵庫のような家電も Internet Engin eering Task Force (IETF)により定義される Internet Protocol (IP)により相互に接続できるようになつてきて、る。

[0003] インターネットやホームネットワークにおけるアプリケーションプログラムの 1つとして、家電機器、 PC間でファイルを転送するアプリケーションプログラムがある。ファイルを転送するアプリケーションプログラムの例として、 DVDレコーダに録画した TV番組を編集するために PCに転送したり、 DVDレコーダ間で録画した MPEG2ファイルを転送するなどのダビング機能を提供するアプリケーションプログラムがある。

[0004] この様なファイル転送を行うプロトコルでは一般的に、ファイルの転送が誤り無く行われることが要求される一方で、リアルタイムの転送は必ずしも要求されない。 IPにおいてファイル転送を行う代表的なプロトコルとしては、 RFC2616で定義される Hyper

Text Transfer Protocol (HTTP)や、 RFC959で定義される File Transfer Protocol (FTP)等が存在する。これらのプロトコルは!、ずれも RFC793で定義される Transmission Control Protocol (TCP)の再送機能によって転送の信頼性を確保している。

[0005] すなわち、 TCPはパケットのエラーを検出して再送する手順と、欠落したパケットを検出して再送する手順を含んでおり、そのために伝送路上でエラーやパケット欠落が起こっても正し、ファイルの転送が保障できる。一方で TCPの再送手順には限界もあり、例えば伝送路の障害や、送信元の機器 (以下、「ソース機器」という。）や、受信先の機器 (以下、「シンク機器」という。）の都合により転送の中断が長時間に渡つた場合、 TCP接続力タイムアウトにより切断されてしまい、それ以後のファイル転送が行えなくなるという課題が存在した。ここでの機器の都合には障害のほか、機器の他の機能を実行するためにファイル転送を中断せざるを得ない場合を含む。例えば、 D VDレコーダがタイマー録画を実行するためにファイル転送を中断する場合などが挙げられる。

[0006] HTTPには上述の課題を解決するための手順が含まれており、転送の中断が任意の長時間に渡った場合でも、再度 TCP接続を行って、中断前に転送した位置の直後からファイル転送を再開できるシーケンスが定義されている。本シーケンスを図 1を用いて説明する。

[0007] 図 1は、従来のソース機器およびシンク機器により構成されるファイル転送システムにおけるファイル転送の再開に係る通信シーケンスの一例を示す図である。

[0008] 図 1に示す通信シーケンスは、ソース機器 1001からシンク機器 1002に対してファィル転送を行うためのファイル転送システムにおける通信シーケンスである。また、フアイル転送の途中で TCP接続が切断される場合を想定している。

[0009] まず、シンク機器 1002はソース機器 1001に対し、 HTTP GETリクエストを発行する（S101)。ソース機器 1001は本リクエストに対し、 "200 OK"を応答し（S102) 、 1000バイトのファイルを送信する（S103)。その後、通信障害が発生し、 TCP接続が切断される（S 104)。

[0010] ここで、 TCP接続が切断されるまでにシンク機器 1002には 500バイトのデータが保存できていたと想定する（S105)。シンク機器 1002は、通信障害が回復するのを待ち、任意の時点で TCPの再接続を行い、転送を再開することができる。転送の再開はシンク機器 1002がソース機器 1001に対し、 Rangeヘッダを追加した HTTP GE Tリクエストを送信し（S 106)、転送対象のファイルの先頭から 500バイト目以降のデータを要求することにより行われる。

[0011] ソース機器 1001は、シンク機器 1002から指定された Range (ここでは 500— 999 バイト目である。）に従ってデータを送信し (S 107、 S 108)、シンク機器 1002は受信したデータを保存する（S 109)。これにより、転送済みのデータを再送することなぐ未転送のデータのみを転送の再開によって取得することが可能である。この様な手順力例えばインターネット上のサーバに配置される数メガノイト以上もの大きなファィルのダウンロードが失敗した場合に、取得済みのデータの続きから取得することで効率よくファイルを取得するアプリケーションプログラムで使用されている。

[0012] HTTPの GETメソッドを利用し、データの提供を行う技術につ!ヽても開示されて!ヽる (例えば、特許文献 1参照)。

特許文献 1 :特開 2002— 288162号公報

発明の開示

発明が解決しょうとする課題

[0013] しかしながら、上記従来の HTTPのファイル転送の中断、再開手順は、 HTTPの G ETメソッドでは使用できるが POSTメソッドでは使用できなヽと、う課題が存在する。インターネット上のサーバから PCにファイルをダウンロードする場合は HTTPの GET メソッドが使用されるためこの様な制約は問題にはならない。

[0014] しかし、ネットワークに接続される任意の機器間でファイルを転送する場合において、ソース機器が任意のファイルをシンク機器の要求なしに自発的に送信しょうとする場合は通常 HTTP POSTメソッドが用いられる。そのため、ソース機器とシンク機器との間の通信が中断した場合には、通信の再開後にファイルの送信を最初力も行わなければならず、ファイル転送のためのリソースや時間を無駄に消費するという課題がある。

[0015] この課題はより一般的にいうと、ソース側力自発的にデータを送信することをトリガとしてプッシュ型のフロー制御を行うファイル転送プロトコルにお、ては、シンク側からリクエストを発行するプル型のフロー制御と異なり、通信の中断があった場合に、効率的なファイル転送を行う手順が存在しなカゝつたという課題である。

[0016] さらに、前述の HTTPの GETメソッドにおけるファイル転送の中断、再開手順においても、再開の可能な期間が規定されておらず、従ってサーバ上に長期間公開されるファイルを不特定多数の PCがダウンロードする用途には適する力ネットワークに接続される任意の機器間でファイルを転送する場合にぉヽて、ソース機器およびシンク機器がいつまで再開を可能な状態に維持すべきか明確で無い。そのため、ソース機器およびシンク機器においてリソースの無駄が生じることとなる。

[0017] 本発明は、上記課題を考慮し、送信機器から自発的に受信機器へファイルを転送するファイル転送システムにおいて、ファイル転送が長時間にわたり中断される場合であっても、ファイル転送に係る処理を効率的に実行するための送信機器、受信機器およびファイル転送システムを提供することを目的とする。

課題を解決するための手段

[0018] 上記目的を達成するために、本発明のファイル転送システムは、ネットワークを介し、ファイルを送信する送信機器カゝら前記ファイルを受信する受信機器へのファイル転送を行うファイル転送システムであって、前記受信機器は、前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、前記送信機器力前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備え、前記送信機器は、ファイルデータを前記受信機器に送信する送信手段と、前記ファイル転送の中断を検出する検出手段と、前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に前記保存済データサイズを問い合わせる問合せ手段と、前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済データサイズに基づき、前記ファイルを構成する残りのファィルデータを前記送信手段に送信させる送信制御手段とを備える。

[0019] また、本発明の送信機器は、ネットワークを介し、受信機器へファイルを転送するフアイル転送を行う送信機器であって、前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、前記ファイル転送の中断を検出する検出手段と、前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に保存されて!/ヽるファイルデータのサイズである保存済データサイズを問ヽ合わせる問合せ手段と、前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済データサイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備える。

[0020] また、本発明の受信機器は、ネットワークを介し、送信機器から送信されるファイルを受信する受信機器であって、前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、前記送信機器力前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備える。

[0021] このように、本発明によれば、送信機器は、ファイル転送の中断後、受信機器に保存済サイズを問い合わせることができる。また受信機器は、その問い合わせへの応答として保存済サイズを送信機器に送信することができる。送信機器は、保存済サイズを知らされることにより、受信機器に送信すべき残りのファイルデータのみを送信することができる。

[0022] つまり、中断されたファイル転送の再開に際し、送信機器は、ファイルデータの送信を最初力行う必要がなぐ受信機器にとって必要な残りのファイルデータのみを送信すればよい。また、受信機器は、重複する無駄なファイルデータを受信することがない。従って、送信機器および受信機器におけるファイル転送に係る処理において、長時間にわたる中断が発生した場合においても、無駄な処理やリソースの無駄な消費が発生することがなぐファイル転送に係る処理を効率的に実行することができる。

[0023] また、本発明のファイル転送システムにおいて、前記受信制御手段は、更に、フアイル転送の中断を要求する中断要求を前記送信機器へ送信し、前記中断要求は、前記受信機器が前記ファイル転送を再開する始期を示す始期情報と、前記受信機器が前記ファイル転送を受け入れる終期を示す期間情報とを含み、前記検出手段は、前記中断要求を受信することで前記ファイル転送の中断を検出し、前記送信制御手段は、前記始期から前記許可期間の間に前記残りのファイルデータを前記送信手段に送信させるとしてもよぐまた、本発明のファイル転送システムにおいて、前記送信制御手段は、更に、前記送信手段がファイルデータを送信する前に、前記ファイルデータの前記受信機器における保持期間を前記受信機器に通知し、前記受信制御手段は、更に、前記ファイルデータが前記保存手段に保存され、かつ、前記ファイルデータの保持期間が経過する前に、前記ファイルを構成する全てのファイルデータを前記送信機器から受信しな、場合、前記保存手段に保存されて!ヽる前記ファイルデータを削除するとしてもよい。

[0024] このように、送信機器と受信機器とは互いに、ファイル転送を行う期間についての情報をやりとりすることができる。これにより、送信機器および受信機器のそれぞれは、相手機器によりファイル転送が中断された場合、いつまでもファイル転送の再開に備えておく必要がなぐそれぞれの機器のリソースを無駄に消費することがない。つまり、ファイル転送に係る処理を効率的に実行することができる。

[0025] 更に、本発明は、本発明のファイル転送システム、送信機器および受信機器それぞれの特徴的な構成部をステップとする方法として実現したり、それらのステップを含むプログラムとして実現したり、そのプログラムが格納された、 CD— ROM等の記録媒体として実現したり、集積回路として実現することもできる。プログラムは、通信ネットワーク等の伝送媒体を介して流通させることもできる。発明の効果

[0026] 本発明は、送信機器から自発的に受信機器へファイルを転送するファイル転送システムにおいて、ファイル転送が長時間にわたり中断される場合であっても、ファイル転送に係る処理を効率的に実行するための送信機器、受信機器およびファイル転送システムを提供することができる。

[0027] 例えば、ファイルを HTTPの POSTメソッドを用いて送信するソース機器と、ソース機器カゝらファイルを受信するシンク機器とにより構成されるファイル転送システムにおいて、ファイル転送の中断が発生し、 TCP接続力タイムアウトした後であっても、送信機器は保存済みのデータサイズを知ることができる。従って、送信機器は、受信機器おいて保存済みのデータに続くデータを受信機器に転送することができる。

[0028] つまり、あるファイルを転送する場合、送信機器にお!ヽては、無駄なデータ送信を行うことがなぐ受信機器においては、無駄なデータを受信することがない。

[0029] 結果として、ソース側力データを送送信することをトリガとしてプッシュ型のフロー制御を行うファイル転送プロトコルにお、ても、リソースや時間などの無駄を発生させることなぐファイル転送に係る処理を効率的に実行することができる。 [0030] 更に、中断、再開手順において再開の可能な期間をノヽンドシェイクする方法および手段を提供し、ソース機器およびシンク機器カ^、つまで再開を可能な状態に維持すべきか明確にすることができる。これにより、ファイル転送におけるソース機器およびシンク機器のメモリやメディア等のリソースにおける無駄を無くすことができる。このことによってもファイル転送に係る処理を効率的に実行することができる。

図面の簡単な説明

[0031] [図 1]図 1は、従来のソース機器およびシンク機器により構成されるファイル転送システムにおけるファイル転送の再開に係る通信シーケンスの一例を示す図

[図 2]図 2は、本発明の実施の形態のファイル転送システムの機器構成を示す図 [図 3]図 3は、本発明の実施の形態のソース機器の機能的な構成を示す機能ブロック図

[図 4]図 4は、本発明の実施の形態のシンク機器の機能的な構成を示す機能ブロック図

[図 5]図 5は、本発明の実施の形態のファイル転送システムにおける基本の通信シーケンスを示す図

[図 6]図 6は、ソース機器カゝらシンク機器に送付される各パラメータの内容を示す図 [図 7]図 7は、実施の形態のファイル転送システムにおいて、ソース機器の都合によりファイル転送が中断される際の通信シーケンスの一例を示す図

[図 8]図 8は、実施の形態のファイル転送システムにおいて、シンク機器の都合によりファイル転送が中断される際の通信シーケンスの一例を示す図

[図 9]図 9は、実施の形態のファイル転送システムにおいて、シンク機器の都合によりファイル転送が中断される際の通信シーケンスの別の一例を示す図

[図 10]図 10は、実施の形態のファイル転送システムにおいて、ファイル転送を再開する際の通信シーケンスを示す図

[図 11]図 11は、実施の形態のファイル転送システムにおいて、ファイルデータの送信が開始される前に、ソース機器の都合によりファイル転送が中止される際の通信シーケンスの一例を示す図

[図 12]図 12は、実施の形態のファイル転送システムにおいて、ファイルデータの送信中に、ソース機器の都合によりファイル転送が中止される際の通信シーケンスの一例を示す図

[図 13]図 13は、実施の形態のファイル転送システムにおいて、ファイルデータの送信が開始される前に、シンク機器の都合によりファイル転送が中止される際の通信シーケンスの一例示す図

[図 14]図 14は、実施の形態のファイル転送システムにおいて、ファイルデータの送信中に、シンク機器の都合によりファイル転送が中止される際の通信シーケンスの一例示す図

[図 15]図 15は、ソース機器がシンク機器にファイルを分割して転送するファイル転送システムの通信シーケンスを示す図

[図 16]図 16は、ファイルを分割して転送するファイル転送システムにおいて、分割後の 1つのファイルデータの送信前に、ソース機器の都合によりファイル転送が中断される場合の通信シーケンスを示す図

[図 17]図 17は、ファイルを分割して転送するファイル転送システムにおいて、シンク機器が POSTリクエストを受信した際に、シンク機器の都合により転送が中断される場合の通信シーケンスを示す図

[図 18]図 18は、ファイルを分割して転送するファイル転送システムにおいて、シンク機器の都合によりファイル転送が中止される場合の通信シーケンスを示す図符号の説明

101 ソース機器

102 シンク機器

701 ユーザインターフェース

702 ファイル送信制御部

703、 802 ファイル制御部

704、 803 通信制御部

705、 804 ファイル蓄積部

706 、 805 ネットワークインターフェース

707 中断検出部 708 問合せ部

801 ファイル受信制御部

806 保存済サイズ取得部

発明を実施するための最良の形態

[0033] 以下、本発明を実施するための最良の形態について図面を用いて説明する。

まず、本発明の実施の形態のファイル転送システムの構成を図 2〜図 4を用ヽて説明する。

[0034] 図 2は、本発明の実施の形態のファイル転送システムの機器構成を示す図である。

本発明の実施の形態のファイル転送システムは、ソース機器 101からシンク機器 102 へファイルを転送するためのシステムである。

[0035] 図 2に示すように、ソース機器 101およびシンク機器 102はブロードバンドルータ 30 1に接続されてホームネットワークを構成する。ブロードバンドルータ 301はインターネット 302に接続されて、ても良ヽ。

[0036] ソース機器 101とシンク機器 102は各々蓄積メディアを内蔵し、 Audio Visual (A V)コンテンツ等のファイルを蓄積することができる。具体的には、ソース機器 101は、ファイル蓄積部 705を備え、シンク機器 102は、ファイル蓄積部 804を備える。

[0037] この様な機器の例としてネットワーク接続端子を備えた DVDZHDDノヽイブリツドレコーダなどが上げられる。本実施の形態の初期状態ではソース機器 101がファイル蓄積部 705にファイル 303を蓄積しており、本ファイルをホームネットワークを介してシンク機器 102に転送する。シンク機器 102はソース機器カゝら受信したファイル 303 をファイル蓄積部 804に蓄積する。

[0038] なお、本実施の形態ではシンク機器 102、ソース機器 101ともにユニバーサルプラグアンドプレイフォーラムの発行する UPnP— AV規格に準拠しており、シンク機器 1 02は Contents Directory Service (CDS)サーバ機能を実装しており、ソース機器 101は CDSサーバにアクセスする Control Point機能を実装しているものとする

[0039] 図 3は、本発明の実施の形態のソース機器 101の機能的な構成を示す機能ブロック図である。ソース機器 101は、本発明の送信機器の一例である。なお、ソース機器 101について、本来備えられている Control Point機能等の図示および説明は省略し、ソース機器 101にお、て特徴的な構成部にっ、てのみ図示および説明を行な

[0040] 図 3に示すように、ソース機器 101は、ユーザインターフェース 701、ファイル送信制御部 702、ファイル制御部 703、通信制御部 704、ファイル蓄積部 705、およびネットワークインターフェース 706を備える。図中の点線で囲まれた領域にある構成部は、ファイル転送に係る主要な処理を行う構成部である。

[0041] ユーザインターフェース 701は、ユーザからの指示等の入力を受け付け、また、ュ一ザに映像等で情報を提供するインターフェースである。ネットワークインターフエ一ス 706は、ホームネットワークを介してシンク機器 102との情報のやり取りを行うインタ一フェースである。

[0042] ファイル蓄積部 705は、上述のように、 AVコンテンツ等のファイルを蓄積する記憶装置である。

[0043] ファイル送信制御部 702は、ファイルのシンク機器 102への送信を制御する制御部であり、問合せ部 708を有する。問合せ部 708は、中断されたファイル転送を再開する際に、シンク機器 102に、保存済データサイズを問い合わせる処理部である。

[0044] なお、上記の保存済データサイズとは、ソース機器 101からシンク機器 102へのフアイル転送において、シンク機器 102が受信し保存した、当該ファイルを構成するフアイルデータ（以下、単に「データ」ともいう。）の容量のことを指す。つまり、ファイルサィズが 1000バイトである場合、保存済データサイズは 0バイトから 1000バイトの間の値となる。

[0045] また、「ファイル転送の中断」とは、ファイルデータの送信が開始されて以降にフアイルデータの送信または受信が中断される場合だけでなぐファイル転送に必要な処理が中断される場合も含む。

[0046] ファイル制御部 703は、ファイル蓄積部 705からのファイルの読出しを制御する制御部である。

[0047] 通信制御部 704は、ネットワークインターフェース 706を制御することでホームネットワークを介した通信を制御する制御部である。通信制御部 704とネットワークインターフェース 706とにより本発明の送信機器における送信手段が有する、情報を送信する機能が実現される。また、通信制御部 704は、中断検出部 707を有する。中断検出部 707は、ファイル転送の中断を検出する処理部である。

[0048] ソース機器 101は、ユーザインターフェース 701を制御して 705に蓄積したファイルの一覧リストを表示する。ユーザが一覧リストの中力も選択したファイルを、ファイル蓄積部 705から読出し、ネットワークインターフェース 706を制御して、シンク機器 102 に送付する。

[0049] 図 4は、本発明の実施の形態のシンク機器 102の機能的な構成を示す機能ブロック図である。シンク機器 102は、本発明の受信機器の一例である。なお、シンク機器 1 02につ、て、本来備えられて、る CDSサーノ機能等の図示および説明は省略し、シンク機器 102において特徴的な構成部についてのみ図示および説明を行なう。

[0050] 図 4に示すように、シンク機器 102は、ファイル受信制御部 801、ファイル制御部 80 2、通信制御部 803、ファイル蓄積部 804、およびネットワークインターフェース 805を備える。図中の点線で囲まれた領域にある構成部は、ファイル転送に係る主要な処理を行う構成部である。

[0051] ネットワークインターフェース 805は、ホームネットワークを介してソース機器 101との情報のやり取りを行うインターフェースである。

[0052] ファイル蓄積部 804は、本発明の受信機器における保存手段の一例であり、上述のように、ソース機器 101から受信するファイルを蓄積する記憶装置である。

[0053] ファイル受信制御部 801は、ソース機器 101から送信されるファイルの受信を制御する制御部である。

[0054] ファイル制御部 802は、ファイル蓄積部 804からのファイルの読出しを制御する制御部であり、保存済サイズ取得部 806を有する。保存済サイズ取得部 806は、フアイル蓄積部 804から保存済データサイズを取得する処理部である。取得された保存済データサイズは、ファイル受信制御部 801の制御により、ソース機器 101へ送信される。

[0055] 通信制御部 803は、ネットワークインターフェース 805を制御することでホームネットワークを介した通信を制御する制御部である。 [0056] 次に、以上のように構成されたソース機器 101およびシンク機器 102により構成されるファイル転送システムにおけるソース機器 101およびシンク機器 102の動作を図 5 力図 14を参照して説明する。

[0057] まず、基本の通信シーケンスにおける各機器の動作を図 5および図 6を用いて説明する。

[0058] 図 5は、本発明の実施の形態のファイル転送システムにおける基本の通信シーケンスを示す図である。図 5に示すように、本実施の形態では、ソース機器 101からシンク機器 102への通信によりファイル転送が開始される。つまり、図 5は、ソース機器 101 力もの自発的なファイル転送における通信シーケンス図である。

[0059] なお、ソース機器 101とシンク機器 102との間の通信は、ブロードバンドルータ 301 により中継される。し力しながら、ブロードバンドルータ 301の動作は本発明の特徴に関与しないため、以下、その図示および動作の説明は省略する。

[0060] ソース機器 101は、 UPnP—AV規格で規定された CDS : CreateObjectリクエストを送付する（S501)。ここで CreateObjectリクエストは論理的なファイルを示す obje ctを生成するリクエストであり、これによつてシンク機器 102のファイル蓄積部 804内に、新規に objectが生成される。その際、生成される objectのディレクトリ構造上の位置や、その objectを示すファイル名等のメタデータが決定される。このメタデータにはファイル実体を保存すべきシンク機器 102上の Uniform Resource Identifiers (URI)が含まれている。シンク機器 102は、ファイルの転送先アドレスとして、この UR Iを含んだ CDS： CreateObjectレスポンスをソース機器に送信する（S502)。

[0061] ソース機器 101は、 POSTメソッドの HTTPリクエスト（以下、「POSTリクエスト」 t ヽう。）をシンク機器 102に送付する（S503)。この際、ソース機器 101は、ファイル転送が中断した場合にシンク機器 102が参照すべきパラメータとして、図 6に示すパラメ一タを POSTリクエストに付加して送付する。具体的には、パラメータとして [byte— ran ge]、 [restart— time]、および [lifetime]の 3つを送付する。

[0062] 図 6は、ソース機器 101からシンク機器 102に送付される各パラメータの内容を示す図である。

[0063] 図 6に示すように、 [byte—range]は送信するデータのバイトレンジである。バイトレンジとは、送信するファイルデータの範囲であるデータ範囲の先頭位置と終端位置を示す情報、およびファイルの総サイズであるファイルサイズを示す情報である。また、単位はそれぞれバイトである。

[0064] つまり、シンク機器 102は、ソース機器力も送信されるデータの範囲だけでなくファィルの総サイズも通知される。そのため、受信したファイルデータ力あるファイルを構成する一部のファイルデータであるのカゝ、または、あるファイルを構成する全てのフアイルデータであるのかを判断することができる。なお、本実施の形態においては、 1 つのファイルをシンク機器 102に送信する場合、分割せずに一括して送信する。ファィルを分割して送信する場合にっヽては図 15を用いて後述する。

[0065] [restart -time]は、送信再開許可時間である。送信再開許可時間とは、中断後にファイル転送動作を再開するまでの一時停止時間を示す情報であり、単位は秒である。

[0066] [lifetime]は、ファイル保持期間である。ファイル保持期間とは、シンク機器 102が objectまたはファイルデータを保持しておくべき時間を示す情報であり、単位は秒である。シンク機器 102は、 [lifetime]に示される期間が経過するまでに、ファイルデータを受信しない場合、作成した objectを保持しておく義務が無い。また、 [lifetime] を通知され、完結していないファイルデータを受信した場合、 [lifetime]に示される期間が経過するまでに、残りのファイルデータを受信しない場合、完結していないフアイルデータを保持しておく義務がな、。

[0067] これにより、ソース機器 101が接続不能になったり転送対象のファイルを消失してしまったような場合でも、シンク機器 102は、完了できないファイル転送のための無駄なリソースを保持しておく必要が無い。そのため、シンク機器 102においてリソースを効率よく管理でき、ユーザの手による不要な objectの削除などのメンテナンスも不要である。

[0068] 図 5の通信シーケンスでは、ソース機器 101は、送信するデータの先頭位置： 0バイト目、終端位置： 999バイト目およびファイルサイズ： 1000バイトを指定している。これは、上述のように、 1つのファイルを一括して送信することを意味する。さらに、一時停止時間： 1200秒 (20分)、ファイル保持期間： 1800秒 (30分)も指定している。 [0069] なお、転送中断要求を示す [suspend— req]は、図 5の通信シーケンスにおいては使用されて、な、。 [suspend— req]をシンク機器 102に送付する場合にっ、ては、図 7を用いて後述する。

[0070] また、ソース機器 101からシンク機器 102に送信される POSTリクエストで指定する URIとして、シンク機器 102から受信した CreateObjectレスポンスに含まれて!/、た U RIが記述される。これにより、シンク機器 102は特定の objectと、受信したファイルデータを対応させることができる。

[0071] さらに、 POSTリクエストには Expect : 100— continueが付カ卩される。これにより、シンク機器は RFC2616に従い、送信された POSTリクエストを上記 URIで受け入れることができるかのチェックを行う。

[0072] チェックの結果、受け入れ可能であれば応答として" 100 Continue"を返す（S50 4)。なお、ソース機器 101からの POSTリクエストを受け入れることができない場合や、 POSTリクエストを解釈することができな、場合にはデータの転送の前にソース機器に通知することができる。従ってソース機器 101は、無駄なデータ送信を回避することができる。

[0073] ソース機器 101は" 100 Continue"ステータスをシンク機器 102から受信することにより、ファイルをシンク機器 102に送信する（S505)。なお、ファイルデータは POS Tリクエストの Entity Bodyに格納されて送信される。

[0074] シンク機器 102は、受信したファイルデータをファイル蓄積部 804に蓄積する。シンク機器 102は、ファイルの受信完了後に、ファイル蓄積部 804へのファイル蓄積処理に時間を要する場合、例えば 20秒以内に蓄積が完了しない場合、 RFC2518で規定される" 102 Processing"を送信し (S506)、蓄積処理中である旨をソース機器 1 01に通知する。シンク機器 102は、蓄積を完了するど' 201 Created"を送信し、ソース機器 101に蓄積完了である旨を通知する（S507)。

[0075] 以上の各機器の動作により、ソース機器 101からシンク機器 102へのファイル転送が完了する。

[0076] なお、図 5に示す通信シーケンスは、ファイル転送の途中で中断が発生しない基本の通信シーケンスである力ソース機器 101またはシンク機器 102の都合によりフアイル転送の中断が生じる場合もある。そこで、以下に、ファイル転送の途中で中断が発生する場合の通信シーケンスおよび各機器の動作を、図 7〜図 9を用いて説明する。また、ファイル転送を再開する際の通信シーケンスおよび各機器の動作を図 10を用いて説明する。

[0077] 図 7は、実施の形態のファイル転送システムにおいて、ソース機器 101の都合によりファイル転送が中断される際の通信シーケンスの一例を示す図である。図 7を用いて、ソース機器 101からシンク機器 102へのファイルデータの送信中に、ソース機器 10 1の都合によりファイル転送が中断される際の各機器の動作を説明する。

[0078] ソース機器 101およびシンク機器 102は、図 5の通信シーケンスと同様に、 CDS : C reateObjectリクエストおよびレスポンス通信を行う。この後、ソース機器 101は、 PO STリクエストをシンク機器 102に送付する（S503)。シンク機器 102は、 POSTリクェストの応答として" 100 Continue"ステータスをソース機器 101に送信する（S504) 。ソース機器 101は、ファイルデータのシンク機器 102への送信を開始する（S505) 。シンク機器 102は、受信したファイルデータをファイル蓄積部 804に蓄積する。ここまでの動作は、図 5に示す通信シーケンスと同様である。

[0079] ここでソース機器 101において、ファイル転送を中断する要因が発生し、 TCP接続を切断するための RSTパケットを送付する。これにより、ファイル転送に利用している TCP接続は切断される (S706)。

[0080] ファイル転送を中断する要因とは、例えば、ユーザの操作により、転送中のファイル力 Sファイル蓄積部 705から削除されたなどである。

[0081] ソース機器 101は、さらに、 [suspend— req]および [lifetime]を含めた POSTリクェストパケットをシンク機器 102に送信する（S707)。 [suspend— req]は図 6に示すように、ファイル転送の中断要求を示す情報である。つまり、シンク機器 102は [susp end— req]を受信することにより、ファイル転送が中断されることを知ることができる。また、 [lifetime]は、上述のようにシンク機器 102がファイルデータを保持しておくべき時間を示す情報であり、この場合は、ソース機器 101が、その時間内にファイル転送を再開することをも意味する。シンク機器 102は、ファイル保持期間が経過した後は、受信し保存済みの当該ファイルデータを削除してもよい。 [0082] なお、上述のファイル転送の中断に係る処理において、 RSTパケットおよび POST リクエストパケットはファイル送信制御部 702により生成されシンク機器 102に送信される。以下、単に「POSTリクエスト」という場合、実体としては POSTリクエストパケットのことを指す。

[0083] また、中断検出部 707は、 TCP接続が切断されたことを検出することで、ファイル転送が中断されたことを検出する。

[0084] シンク機器 102は、上記 POSTリクエストを受け取ると" 200 OK"を返信する（S70

8)。ソース機器 101は、ファイル転送を中断する要因がなくなった後に、図 11を用いて後述するファイル転送の再開動作を実行する。

[0085] このようにして、本実施の形態のファイル転送システムにお、て、ファイルデータの送信の開始後かつファイル転送が完了する前に、ソース機器 101の都合によりフアイル転送が中断される。

[0086] 次に、シンク機器 102が POSTリクエストを受信した際に、シンク機器 102の都合によりファイル転送が中断される場合の各機器の動作を図 8を用いて説明する。

[0087] 図 8は、実施の形態のファイル転送システムにおいて、シンク機器 102の都合によりファイル転送が中断される際の通信シーケンスの一例を示す図である。

[0088] ソース機器 101およびシンク機器 102は、図 5の通信シーケンスと同様に、 CDS : C reateObjectリクエストおよびレスポンス通信を行う。この後、ソース機器 101は、 PO STリクエストをシンク機器 102に送付する（S503)。ここまでの動作は、図 5に示す通信シーケンスと同様である。

[0089] ここで、シンク機器 102は、ファイルの受信処理を行えな、状態であり、 POSTリクェストに対する応答として" 503 Service Unavailable"ステータスを送信する。フアイルの受信処理を行えない状態とは、例えば、ファイル蓄積部 804の空き容量がない状態などである。

[0090] シンク機器 102は、ステータスパケットにファイル転送を再開する始期を示す" retry

& 61："を含めて応答する（3804)。ソース機器 101は、 "retry— after"に示される時間を経過した後に、図 11を用いて後述するファイル転送の再開動作を実行する。

[0091] このようにして、本実施の形態のファイル転送システムにおいて、ソース機器 101からシンク機器 102に、 POSTリクエストにより転送されるファイルのサイズ等が通知された後、かつファイルデータの送信が開始される前に、シンク機器 102の都合によりフアイル転送が中断される。

[0092] 次に、ソース機器 101からシンク機器 102へのファイルデータの送信中に、シンク機器 102側の要因によりファイル転送を中断する際の各機器の動作を図 9を用いて説明する。

[0093] 図 9は、実施の形態のファイル転送システムにおいて、シンク機器 102の都合によりファイル転送が中断される際の通信シーケンスの別の一例を示す図である。

[0094] ソース機器 101およびシンク機器 102は、図 5の通信シーケンスと同様に、 CDS : C reateObjectリクエストおよびレスポンス通信を行う。この後、ソース機器 101は、 PO STメソッドの HTTPリクエストをシンク機器 102に送付する（S503)。シンク機器 102 は、 HTTPリクエストの応答として" 100 Continue"ステータスをソース機器 101に送信する（S504)。ソース機器 101は、ファイルデータのシンク機器 102への送信を開始する（S505)。シンク機器 102は、受信したファイルデータをファイル蓄積部 804 に蓄積する。ここまでの動作は、図 5に示す通信シーケンスと同様である。

[0095] ここでシンク機器 102において、ファイル転送を中断する要因が発生し、 RSTパケットを送付する。これにより、ファイル転送に利用している TCP接続は切断される（S9 06)。ファイル転送を中断する要因とは、例えば、ファイル蓄積部 804から別のフアイルを読み出す必要が生じ、受信するファイルデータを蓄積できな、などである。

[0096] TCP接続がシンク機器により切断されると、ソース機器 101のファイル送信制御部 7 02は、再び POSTリクエストをシンク機器 102に送信する（S907)。

[0097] シンク機器 102は、 POSTリクエストへの応答として" 503 Service Unavailable" ステータスをソース機器 101へ送信する（S908)。ステータスパケットには上述の [re try— after]が含められる。

[0098] この [retry— after]を伴う" 503 Service Unavailable"は、シンク機器 102からのファイル転送の中断要求である。

[0099] ソース機器 101の中断検出部 707は、この中断要求を検出することで、ファイル転送の中断を検出する。ソース機器 101は、 "retry— after"に示される時間を経過した後に、図 11を用いて後述するファイル転送の再開動作を実行する。

[0100] このようにして、本実施の形態のファイル転送システムにおいて、ファイルデータの送信の開始後かつ送信が完了する前に、シンク機器 102側の要因によりファイル転送が中断される。

[0101] 次に、図 7〜図 9を用いて説明したファイル転送の中断後に、ファイル転送を再開する際の各機器の動作を図 10を用いて説明する。

[0102] 図 10は、実施の形態のファイル転送システムにおいて、ファイル転送を再開する際の通信シーケンスを示す図である。

[0103] ソース機器 101の中断検出部 707は、ファイル転送が中断されたことを検出する（S 1000)。なお、中断検出部 707は、ファイル転送の中断がソース機器 101の都合によるもの力、シンク機器 102の都合によるものかを問わず、送受信するパケットの種類および内容等から、ファイル転送が中断されたことを検出することができる。

[0104] ソース機器 101は、自身の都合によりファイル転送を中断した場合は、その中断の要因がなくなった後で、また、シンク機器 102の都合によりファイル転送が中断された場合は、中断の際にシンク機器 102から送信された [retry— after]に示される時間が経過した後で、以下の動作を行う。

[0105] ソース機器 101は、 CDS : Browseリクエストをシンク機器 102に送信し（S 1001)、シンク機器 102に対してファイルの保存サイズを問い合わせる。

[0106] 具体的には、ソース機器 101のファイル送信制御部 702により生成される CDS : Br owseリクエストに、問合せ部 708によって、保存済データサイズの通知要求が含められる。その CDS : Browseリクエストは、ネットワークインターフェース 706を介しシンク機器 102へ送信される。

[0107] シンク機器 102は、上記 CDS : Browseリクエストを受け取ると保存済データサイズを含めた CDS： Browseレスポンスをソース機器 101に送信する（S1002)。

[0108] 具体的には、保存済サイズ取得部 806が、ファイル蓄積部 804に保存されている、当該ファイルを構成するファイルデータのデータサイズを取得する。更に、ファイル受信制御部 801が、保存済サイズ取得部 806により取得されたデータサイズを含めた C DS : Browseレスポンスを生成する。生成された CDS : Browseレスポンスは、ネットヮ一クインターフェース 805を介しソース機器 101に送信される。

[0109] ソース機器 101のファイル送信制御部 702は、受信した保存済データサイズに応じて転送すべきファイルの先頭位置を決定し、ファイル蓄積部 705からファイルデータを読み出す。

[0110] 例えば、ファイルサイズが 1000バイトであり、シンク機器 102から通知された保存済データサイズが 400バイトである場合を想定する。この場合、シンク機器 102に保存されているファイルデータは、 0ノイト目力ら 399ノイト目までのファイルデータである。従って、ファイル送信制御部 702は、残りの 400バイト目力ら 999ノイト目までのファィルデータを、ファイル制御部 703を介しファイル蓄積部 705から読み出す。以下、「残りのファイルデータ」という場合、上述のように、転送対象のファイルデータから、シンク機器 102に保存済みのファイルデータを除いた、残りのファイルデータのことを指す。

[0111] ソース機器 101は、データ範囲とファイルサイズとを示す [byte— range]等を含む POSTリクエストをシンク機器 102に送信する（S 1003)。シンク機器 102は、 POSTリタエストへの応答として" 100 Continue"ステータスをソース機器 101に送信する（S 1004)。

[0112] ソース機器 101のファイル送信制御部 702は、ファイル蓄積部 705から読み出した残りのファイルデータを通信制御部 704に送信させる。（S1005)。シンク機器 102のファイル制御部 802は、 [byte—range]に示されるデータ範囲に基づき、受信したフアイルデータと中断前に保存済みのファイルデータとを結合し、元のファイルに再構築する。

[0113] このように、本発明の実施の形態のソース機器 101は、中断されたファイル転送を再開する際に、シンク機器 102に保存済データサイズを問い合わせることができる。また、本発明の実施の形態のシンク機器 102はその問合せに応じ、保存済データサィズをソース機器 101に通知することができる。

[0114] これにより、ソース機器 101は、ファイル転送を最初力もやり直す必要がなぐ残りのファイルデータのみを送信するのみでよい。またシンク機器 102は、ファイルデータを重複して受信することがな、。 [0115] つまり、本発明の実施の形態のソース機器 101、シンク機器 102およびファイル転送システムにより、ソース機器 101からの自発的なファイル転送において、規定された TCP接続のタイムアウト時間より長い中断が生じた場合であっても、ファイル転送に係る処理を効率的に実行することができる。

[0116] さらに、転送を再開可能な時間を機器間で通知できるので、不要な転送再開試行動作を抑制でき、機器の通信負荷を低減できると!ヽぅ効果を有する。

[0117] なお、ファイル転送途中でネットワークの通信経路が断絶した場合、ソース機器 10 1の中断検出部 707が通信経路の断絶を検出すると、図 10の通信シーケンスに示すファイル転送の再開動作が開始される。

[0118] また、図 7〜図 9を用いてファイル転送が中断される場合の通信シーケンスおよび各機器の動作を説明したが、ソース機器 101またはシンク機器 102の都合により、フアイル転送を中断ではなぐ中止する必要が生じる場合もある。本発明の実施の形態のソース機器 101およびシンク機器 102のそれぞれは、ファイル転送を中止する場合、互いの機器に通知することができる。以下に、ファイル転送の中止に係る通信シ一ケンスおよび各機器の動作を、図 11〜図 14を用いて説明する。

[0119] 図 11は、実施の形態のファイル転送システムにおいて、ファイルデータの送信が開始される前に、ソース機器 101の都合によりファイル転送が中止される際の通信シーケンスの一例を示す図である。図 11を用いて、ファイル転送が開始される前に、ソース機器 101の都合によりファイル転送の実行が中止される際の各機器の動作を説明する。

[0120] ソース機器 101およびシンク機器 102は、図 5の通信シーケンスと同様に、 CDS : C reateObjectリクエストおよびレスポンス通信を行う（S501、 S502)。この後、ソース機器 101が POSTリクエストを送信する前に、ソース機器 101において、ユーザによりファイル転送のキャンセル指示がなされる、または、転送対象のファイルが削除されるなどの事象が発生したと想定する。

[0121] この場合、ソース機器 101は、ファイル転送を中止するために、 POSTリクエストに替えて CDS： DestroyObjectリクエストをシンク機器 102に送信する（S 1103)。シンク機器 102は、 CDS : DestroyObjectを受信すると、 CDS : CreateObjectリクエスト (S501)に応じて作成した objectを削除する。更に、 objectを削除した旨を通知するために、ソース機器 101に CDS： DestroyObjectレスポンスを応答する（S 1104)。

[0122] このように、ファイル転送が開始される前に、ソース機器 101の都合により、ファイル転送が中止された場合、シンク機器 102では、ファイルを保存するために作成された objectが削除される。つまり、シンク機器 102において無駄となる objectは速やかに削除される。

[0123] 次に、ソース機器 101からシンク機器 102へのファイルデータの送信中にソース機器 101の都合によりファイル転送が中止される際の各機器の動作を図 12を用いて説明する。

[0124] 図 12は、実施の形態のファイル転送システムにおいて、ファイルデータの送信中に、ソース機器 101の都合によりファイル転送が中止される際の通信シーケンスの一例を示す図である。

[0125] ソース機器 101およびシンク機器 102は、図 5の通信シーケンスと同様に、 CDS : C reateObjectリクエストおよびレスポンス通信を行う。この後、ソース機器 101は、 PO STリクエストをシンク機器 102に送付する（S503)。シンク機器 102は、 POSTリクェストの応答として" 100 Continue"ステータスをソース機器 101に送信する（S504) 。ソース機器 101は、ファイルデータのシンク機器 102への送信を開始する（S505) 。シンク機器 102は、受信したファイルデータをファイル蓄積部 804に蓄積する。ここまでの動作は、図 5に示す通信シーケンスと同様である。

[0126] ここで、ソース機器 101が POSTリクエストを送信する前に、ソース機器 101において、ユーザによりファイル転送のキャンセル指示がなされる、または、転送対象のファィルが削除されるなどの事象が発生したと想定する。

[0127] ソース機器 101は、ファイル転送を中止するために、 TCPの RSTパケットを送信する（S1206)。これにより、ファイル転送に利用している TCP接続が切断される。ソース機器 101は、さらに、 CDS : DestroyObjectリクエストをシンク機器 102に送信する (S1207) _oシンク機器 102は、 CDS : DestroyObjectリクエストに応じて、受信済みのファイルデータを削除し、 CDS： DestroyObjectレスポンスをソース機器 101へ送信する（S 1208)。 [0128] このように、ファイルデータの送信が開始された後に、ソース機器 101の都合により、ファイル転送が中止された場合、シンク機器 102では、受信し保存済みのファイルデータは削除される。つまり、シンク機器 102において無駄となる、完結していないフアイルデータは速やかに削除される。

[0129] 次に、シンク機器 102が POSTリクエストを受信した際に、シンク機器 102の都合によりファイル転送が中止される際の各機器の動作を図 13を用いて説明する。

[0130] 図 13は、実施の形態のファイル転送システムにおいて、ファイルデータの送信が開始される前に、シンク機器 102の都合によりファイル転送が中止される際の通信シーケンスの一例示す図である。

[0131] ソース機器 101およびシンク機器 102は、図 5の通信シーケンスと同様に、 CDS : C reateObjectリクエストおよびレスポンス通信を行う。この後、ソース機器 101は、 PO STリクエストをシンク機器 102に送信する（S503)。ここまでの動作は、図 5と同様である。

[0132] ここで、シンク機器 102にお!/、て、ソース機器 101からの CDS： CreateObjectリクェストに応じて作成された objectが消失したなどの理由により、ファイル転送を中止する必要が生じた場合を想定する。

[0133] この場合、シンク機器 102は、 POSTリクエストへの応答として" 404 Not Found "ステータスをソース機器 101へ送信する（S1304)。ソース機器 101は、 "404 Not Found"に応じてファイル転送に係る処理を中止する。

[0134] このように、ソース機器 101からシンク機器 102に、 POSTリクエストによりファイルサィズ等が通知された後、かつファイルデータの送信が開始される前に、シンク機器 10 2の都合により、ファイル転送が中止された場合、ソース機器 101は、シンク機器 102 力もの通知によりファイル転送に係る処理を中止する。つまり、ソース機器 101は不要な処理を継続することがな、。

[0135] 次に、シンク機器 102の都合により、ソース機器 101からシンク機器 102へのフアイルデータの送信中にファイル転送が中止される際の各機器の動作を図 14を用いて説明する。

[0136] 図 14は、実施の形態のファイル転送システムにおいて、ファイルデータの送信中に、シンク機器の都合によりファイル転送が中止される際の通信シーケンスの一例示す図である。

[0137] ソース機器 101およびシンク機器 102は、図 5と同様に、 CDS : CreateObjectリクェストおよびレスポンス通信を行う。この後、ソース機器 101は、 POSTリクエストをシンク機器 102に送付する（S503)。シンク機器 102は、 POSTリクエストへの応答として" 100 Continue"ステータスをソース機器 101へ送信する（S504)。ソース機器 1 01は、ファイルデータのシンク機器 102への送信を開始する（S505)。シンク機器 10 2は、受信したファイルデータをファイル蓄積部 804に蓄積する。ここまでの動作は、図 5に示す通信シーケンスと同様である。

[0138] ここで、シンク機器 102において、ファイル転送を中止する要因が発生し、 TCPの R STパケットを送信する（S 1406)。これにより、ファイル転送に利用している TCP接続が切断される。ソース機器 101は、 TCP接続の切断を検出すると、再び POSTリクェストをシンク機器 102に送信する（S1407)。シンク機器は、 POSTリクエストへの応答として" 404 Not Found"ステータスをソース機器 101へ送信する（S1408)。ソース機器 101は" 404 Not Found"に応じてファイル転送に係る処理を中止する。

[0139] このように、ソース機器 101からシンク機器 102へのファイルデータの送信が開始された後に、シンク機器 102の都合により、ファイル転送が中止された場合、ソース機器 101は、シンク機器 102からの通知によりファイル転送に係る処理を中止する。つまり、ソース機器 101は不要な処理を継続することがない。

[0140] このように、本発明の実施の形態のソース機器 101およびシンク機器 102は、フアイル転送を中止する場合、その中止がどちらの機器の都合によるものであっても、無駄なリソースの消費および無駄な処理が発生しないように、ファイル転送の中止のための処理が行われる。

[0141] なお、上述の実施の形態において、プッシュ型のフロー制御を行うファイル転送プロトコルとして HTTPの POSTメソッドによりファイル転送を行う場合を説明した。しかしながら、 POSTメソッド以外であってもよぐ例えば、 PUTメソッドであっても上記効果が失われるものではな!/、。

[0142] また、ソース機器 101は、ファイル転送が中断した場合にシンク機器 102が参照すべきパラメータとして、図 6に示すパラメータを HTTPリクエストパケットに付加して送付するとした。

[0143] このパラメータを付与する具体的な方法として、独自に定義したヘッダを POSTリクェストのメッセージヘッダとして含ませる方法がある。

[0144] 例えば、 POSTリクエストに、独自に定義したヘッダである UploadTransportlnfo . dlna. org : [byte— range]を付与し、 HTTPの Entity Body部に含まれるデータの範囲および総サイズを格納する。また、 [lifetime]等の必要な情報を含ませる。シンク機器 102は、ソース機器 101から送信された POSTリクエストのメッセージヘッダから、これらの情報を取得することができる。

[0145] また、上述の実施の形態においては、 POSTリクエストに [byte— range]、 [restar t-time]、および [lifetime]の 3つのパラメータを付カ卩して送付する構成を説明した。しかしながら [restart— time]のみを付カ卩してもよ！ヽ。

[0146] なお、 UploadTransportlnfo. dlna. org以外の、 HTTPで当然使用されるその他のヘッダについては本発明の特徴に関係しないため図示および説明を省略する。

[0147] また、上述の実施の形態において、ソース機器 101は、ファイルをシンク機器 102 に転送する場合、一括して転送するとした。し力しながら、ソース機器 101は、フアイルを分割し、分割単位毎にシンク機器 102に送付することもできる。シンク機器 102 力 S1回の POSTリクエストで受信可能なデータサイズに制限がある場合など、ソース機器 101が分割単位毎にファイルデータを送信する方法は有効である。

[0148] 図 15は、ソース機器 101がシンク機器 102にファイルを分割して転送するファイル転送システムの通信シーケンスを示す図である。図 15を用いて、ソース機器 101がフアイルを分割して転送する際の各機器の動作を説明する。なお、ソース機器 101は、送信するファイルデータの範囲等をシンク機器 102に通知するために、上述の、独自に定義したヘッダ UploadTransportlnfo. dlna. orgを使用すると想定する。

[0149] ソース機器 101はファイルの転送に先立って、シンク機器 102に対し CDS： Create Objectリクエストを送信する（SI 503)。シンク機器 102は、 CDS : CreateObjectリクェストに従い、 objectを作成し、 CDS : CreateObjectレスポンスをソース機器 101に送信する（S 1504)。 [0150] ソース機器 101はファイルを分割転送するサイズを決定する。分割転送のサイズは転送の中断、再開の頻度、中断時に無駄になる転送サイズ、分割によるオーバへッド等を勘案して任意に決定することができる。ここでは 1000バイトのファイルを、最初の 0バイト目力ら 499ノイト目までのファイルデータと、次の 500ノイト目力ら 999ノィト目のファイルデータとに分割する（S1505)。このファイルの分割はソース機器のフアイル送信制御部 702が行う。

[0151] ソース機器 101はファイル転送を開始する。具体的には、ソース機器 101は POST リクエストを送信する（SI 506)。 POSTリクエストには、独自に定義したヘッダである、 UploadTransportlnf o . dlna. org : [byte— range]、 [lifetime]；¾ .まれる。ここでの [byte— range]は、ヘッダ以下に続く HTTPの Entity Body部に含まれるデータの範囲と、ファイルの総サイズを示す情報であり、データの範囲" 0—499"とファィルの総サイズである" 1000"が指定される。 [lifetime]ではコンテンツの保持期間を指定しており、ここでは秒単位で" 1800"つまり、 30分を指定している。

[0152] シンク機器 102は、上記 POSTリクエストへの応答として" 100 Continue"をソース機器 101へ送信する（S1507)。

[0153] ソース機器 101は、シンク機器 102に通知したデータ範囲のファイルデータを送信する（S1508)。具体的には POSTリクエストの Entity Bodyに当該ファイルデータを格納して送信する。 Entity Bodyに含まれるファイルの範囲は、上述のように" 0 —499"の 500バイト分のみである。

[0154] シンク機器 102はこの 500バイト分のファイルデータを受信するとファイル蓄積部 80 4への保存を開始する。保存の開始後、ファイル蓄積部 804への書き込み速度が遅いなど、概ね 20秒以内に保存を完了できない場合、 "102 Processing"を送信する（S1509)。その後、受信したファイルデータの保存が完了すると（S1510)、 "201 Created"をソース機器 101へ送信し（S1511)、転送データが保存されたことを通知する。

[0155] 次に、ソース機器 101とシンク機器 102は、上述のソース機器 101からシンク機器 1 02への POSTリクエストの送信（S1506)力ら、シンク機器 102からソース機器 101への保存完了の通知（S1511)と同様の動作シーケンスにより、次の分割単位である 5 00ノイト目力ら 999ノイト目までのフアイノレデータの転送を行う（S1512〜S1517)。

[0156] 即ち、ソース機器 101は、 UploadTransportlnfo. dlna. orgヘッダの [byte— r ange]に" 500— 999Z1000"を格納しシンク機器 102に通知する。シンク機器 102 はこれを解釈し、その後に受信するファイルデータ（S 1515)を、すでに保存されている 0ノイト目力ら 499Byte目のファイルデータにアペンドしてファイル蓄積部 804に保存する。

[0157] このようにして、 POSTメソッドを用いてファイルを送信するプッシュ型のフロー制御でもファイルを分割して送信を行うことが可能となる。

[0158] なお、このようにファイルが分割して転送される場合にぉ、ても、ファイル転送が中断された場合、ソース機器 101は、図 10の通信シーケンスに示すように、シンク機器 102に保存済データサイズを問い合わせることで、送信すべき残りのファイルデータのみを送信する。例えば、図 15の通信シーケンスにおいて、最初の 500バイトの送信中にファイル転送が中断され、それまでにシンク機器 102に 200バイトが保存されていた場合を想定する。この場合、ソース機器 101は、シンク機器 102に問い合わせることにより保存済データサイズが" 200"であることを取得する。その後、ソース機器 101は残りの 300バイトをシンク機器 102に送信する。

[0159] また、伝送路上のエラー等により、保存済データサイズを取得できな力つた場合、送信途中であったファイルデータを再送信する。例えば、図 15の通信シーケンスにおいて、後の 500バイトの送信中にファイル転送が中断され、ソース機器 101がシンク機器 102から保存済データサイズを取得できな力つた場合、後の 500バイトを最初から送信する。

[0160] つまり、最初の 500バイトは、シンク機器 102からの" 201 Created"によりシンク機器 102に保存済みであることが確認できているため、ソース機器 101は、後の 500バイトのみを再送信すればよ、。

[0161] このように、転送対象のファイルを分割して送信する方法は、上述のように、シンク機器 102が 1回の POSTリクエストで受信可能なデータサイズに制限がある場合のみならず、ファイル転送の効率化に対しても有効である。

[0162] また、分割されたファイルデータがシンク機器 102に送信される前に POSTリクエストでファイルの総サイズがシンク機器 102に通知される。そのため、シンク機器 102は、受信したファイルデータ力あるファイルを構成する一部のファイルデータであるの力または、あるファイルを構成する全てのファイルデータであるのかが判断できる。

[0163] 例えば、ファイルデータの送信に先立って通知される [byte— range]が" 0—499 Z1000"であれば、その後に受信したファイルデータはあるファイルを構成する一部のファイルデータであると判断できる。また、 [byte— range]が" 0— 999/1000"であれば、その後に受信したファイルデータはあるファイルを構成する全てのファイルデータであると判断できる。

[0164] これにより、例えば、 [byte—range]が" 0—499Z1000"と指定されたファイルデータを受信し保存した後に、残りのファイルデータを受信しない場合、保存済みのフアイルデータは完結していないファイルデータであると判断できる。そこで、所定の期間後に削除、またはユーザに保存を継続するかを確認するなどの処置を行うことができる。

[0165] 受信したファイルデータについては、上述のように、ソース機器 101から指定される

[lifetime]に示される保持期間を越えることをもって削除することも可能である。そこで、シンク機器 102は、 [lifetime]が指定されていない場合に、上記の [byte—rang e]に基づく判断により、所定期間の経過後に削除してもよい。また、 [lifetime]に示される保持期間を越え、かつ、 [byte— range]に示される情報から、当該ファイルデータが完結してヽな、ファイルデータであると判断できる場合、そのファイルデータを削除してもよい。

[0166] なお、これら [byte— range]および [lifetime]等をシンク機器 102へ通知するためのヘッダの名前は、 UploadTransportlnfo. dlna. org以外のヘッダ名でもかまわない。さらに本実施の形態では Digital Living Network Alliance (DLNA)で定義するヘッダ命名手法に従い". dlna. org"を接尾語として用い、他の任意のへッダ名との偶然の一致を回避している。し力しながら、これに限らず、例えば HTTPの独自拡張ヘッダであることを示す接頭語" X—"を用いて、 "X— UploadTransportl nfo"等と定義しても力まわな、。

[0167] また、図 15に示す通信シーケンスにおいては 1000バイトのファイルを 500バイトずつ 2分割したが、当然にその分割単位に限定されるものではなぐ任意の分割が可能である。

[0168] また、ソース機器 101からシンク機器 102へファイルを分割して転送するファイル転送システムにおいても、ソース機器 101またはシンク機器 102の都合によりファイル転送が中断または中止される場合がある。そこで、以下に、分割された 1つの断片であるファイルデータの送信前にファイル転送が中断される場合の通信シーケンスおよび各機器の動作を、図 16および図 17を用いて説明する。また、ファイル転送が中止される場合の通信シーケンスおよび各機器の動作を図 18を用いて説明する。

[0169] 図 16は、ファイルを分割して転送するファイル転送システムにおいて、分割後の 1 つのファイルデータの送信前に、ソース機器 101の都合によりファイル転送が中断される場合の通信シーケンスを示す図である。

[0170] 図 16の通信シーケンスにおいて CDS : CreateObjectリクエストを送信（S1503)してから、転送対象のファイルを分割（S 1505)までは、図 15を用いて説明した通りであり説明を省略する。

[0171] ここで、ソース機器 101において、ユーザのキャンセル指示等によりファイルの転送を中断する場合を想定する。この場合、ソース機器 101は、 POSTリクエストのメッセージヘッダに、処理の保留を示す [suspend]を含む UploadTransportlnfo. dlna . orgヘッダを格納しシンク機器 102に送信する（S1606)。

[0172] ソース機器 101は、この UploadTransportlnfo. dlna. org :ヘッダに含まれるキーワードである [suspend]を示すフィールド値によってシンク機器 102に明示的に中断を通知することができる。なお、この場合、 POSTリクエストの Entity Bodyは送信されない。また、図 15の通信シーケンスと同様に、 [lifetime]も上記ヘッダに含まれ、例えば、秒単位で" 1800"、つまり 30分が指定される。

[0173] シンク機器 102は" 200 OK"を送信し（S1607)、中断を了解したことを示す。

[0174] 本手順によれば単に TCP切断などにより中断した場合と比較すると、シンク機器 10 2で不要な転送プロセスをスリープさせるなど、適切な対処を行うことができるため、無駄な処理の発生を抑止する効果がある。

[0175] なお、転送の再開は UploadTransportlnfo. dlna. org :ヘッダの [lifetime]で指定した 30分以内にソース機器 101が任意に行うことができる。なお、 30分以内にソース機器 101が転送の再開を行えないような場合、再度 UploadTmnsportlnfo. dlna . org : suspendを送信することにより、転送再開期間の再延長を行うことも可能である

[0176] 次に、ファイルを分割して転送するファイル転送システムにおいて、シンク機器 102 力 SPOSTリクエストを受信した際に、シンク機器 102の都合によりファイル転送が中断される場合の各機器の動作を図 17を用いて説明する。

[0177] 図 17は、ファイルを分割して転送するファイル転送システムにおいて、シンク機器 1

02が POSTリクエストを受信した際に、シンク機器 102の都合によりファイル転送が中断される場合の通信シーケンスを示す図である。

[0178] 図 17の通信シーケンスにおいて、ソース機器 101が、 CDS : CreateObjectリクェストを送信（S 1503)してから、送信するファイルデータの範囲等を POSTリクエストにより通知する（S1506)までは、図 15を用いて説明した通りであり説明を省略する。

[0179] ここで、上記 POSTリクエスト（S1506)を受信したシンク機器 102が、ファイル蓄積部 804からデータを読出し中であるなどの理由により、ファイル転送を行える状態に無い場合を想定する。

[0180] この場合、シンク機器 102は、 POSTリクエストへの応答として" 503 Service Un available"をソース機器 101へ送信し（S1707)、ファイル転送を行える状態に無いことをソース機器 101に通知する。

[0181] また、シンク機器 102は、 "503 Service Unavailable"を含むレスポンスメッセ一ジに Retry— After:ヘッダを格納することによって転送を開始できる見込みの時間を通知する。つまり、 Retry— After:ヘッダは、ファイル転送を再開する始期を示す情報である。さらに、独自に定義したヘッダである UploadTransportExpirelnfo. d lna. org :ヘッダを格納することによって、再開が可能である期間を通知する。

[0182] UploadTransportExpirelnfo . dlna. org :ヘッダは、ファイル転送を受け入れる終期を示すためのヘッダである。図 17の通信シーケンスでは秒単位で" 1800"、つまり 30分が指定されている。この場合、シンク機器 102が上記レスポンスメッセージを送信 (S1707)してから 30分後まではファイル転送を受け入れることを示す。具体的には、 30分が経過すると、ソース機器 101からの CDS : CreateObjectリクエスト（S1 503)に応じて作成された objectが削除される。なお、すでに一部のファイルデータを受信し保存した後に、ファイル転送を中断した場合、完結していないファイルデータがファイル蓄積部 804に保存されているため、そのファイルデータが削除される。

[0183] ここで、 RFC2616で定義される Retry— After:ヘッダは一般にサービスの再開を保障するものではなぐ Retry— After:ヘッダに示される期間より短い間隔でリトライを行ってもサービスが再開できる見込みが薄いことを通知して相手機器のポーリング負荷を抑制するためのものである。

[0184] 従って、ソース機器 101はシンク機器 102に対し、 Retry— After:ヘッダにより示される 20分以降、 UploadTransportExpirelnfo. dlna. org :ヘッダにより示される 3 0分以内にリトライを行って、転送の再開が可能である力確認を行い、可能であれば続きのファイルデータの送信を行う。

[0185] このように、シンク機器 102が自身の都合によりファイル転送を中断する場合、 Retr y— After:へッタと、 UploadTransportExpirelnfo. dlna. org :へッタとにより、ソース機器 101がファイル転送をリトライすべき始期と終期とがソース機器 101に通知される。

[0186] これにより、ソース機器 101は、無駄なリトライをすることがない。結果として、ソース機器 101内および伝送路上でのリソースの無駄な使用を防ぐことができる。

[0187] 次に、ファイルを分割して転送するファイル転送システムにお、て、ファイル転送が中止される場合の一例として、シンク機器 102の都合によりファイル転送が中止される場合の通信シーケンスおよび各機器の動作を図 18を用いて説明する。

[0188] 図 18は、ファイルを分割して転送するファイル転送システムにおいて、シンク機器 1 02の都合によりファイル転送が中止される場合の通信シーケンスを示す図である。

[0189] 図 18の通信シーケンスにおいて、ソース機器 101が、 CDS : CreateObjectリクェストを送信（S1503)してから、シンク機器 102が、ファイル転送を行える状態に無いこと等をソース機器 101に通知する（S 1707)までは、図 15および図 17を用、て説明した通りであり説明を省略する。

[0190] 図 18の通信シーケンスにおいて、シンク機器 102は、ー且、ファイル転送を中断するための通知（S1707)を行っている力ソース機器 101がファイル転送のリトライ（S 1808)を行った際に、シンク機器 102がファイル転送を再開せずに中止したい理由あつたと想定する。

[0191] この様な理由としては、例えばファイル蓄積部 804の空き容量がなくなつたため、当面転送を再開できる見込みが無い場合や、転送を行うとシンク機器 102の動作自体に支障をきたす場合などがあげられる。

[0192] このような場合、シンク機器 102は" 404 Not Found"を応答として送信し（S 180 9)、送信先の URIリソース、つまり、送信されるファイルデータを保存するための obje ctが削除されて最早使用可能で無いことを示す。なお、ソース機器 101とシンク機器 102とのタイマーの違いにより、ソース機器 101が既にシンク機器 102から削除された URIに対してリトライを行った場合にも同様のシーケンスとなる場合がある。

[0193] なお、ソース機器 101からファイル転送を中止する場合、タイムアウトするまで所定の URIにリトライを行わない方法や、 UPnP—AVの CDS : DestroyObjectを発行してシンク機器 102から明示的にオブジェクトとそれに関連する URIを削除する方法などがある。

[0194] 以上 UPnP—AVのオブジェクト単位でファイル転送を管理する例で説明した力これに限らず、単に所定の URIに対してファイル送信を行う場合にも適用可能である。

[0195] このように、ファイルを分割して転送するファイル転送システムであっても、ファイル転送が中断または中止された場合には、ソース機器 101またはシンク機器 102が中断または中止を相手機器に通知することができる。これにより、中断または中止を通知された機器は、無駄となるファイル転送のための処理を継続することがな、。

[0196] なお、 HTTPの POSTメソッドによりファイルを送信する場合を説明した力これに限らず、 PUTメソッド、さらには同様のハンドシェイクシーケンスが適用可能な HTTP 以外のファイル転送プロトコルへも適用が可能である。

[0197] また、図 16〜図 18では、分割後のファイルデータが 1回も送信されることなぐファィル転送が中断または中止される場合の通信シーケンスを示している。しかしながら、図 16〜図 18を用いて説明したファイル転送の中断または中止の際の各機器の動作は、 1回以上ファイルデータが送信された後、かつ、次のファイルデータが送信される前に中断または中止される場合でも同じである。

産業上の利用可能性

本発明の送信機器、受信機器、およびファイル転送システム、は、ネットワークに接続される任意の機器間でファイルを転送するファイル転送システムにおいて有用である。特にファイルのサイズが大きぐ転送を中断して再開する際に、転送を初めからやり直すと無駄が多い場合に効果を発揮する。

Claims

請求の範囲

[1] ネットワークを介し、ファイルを送信する送信機器から前記ファイルを受信する受信機器へのファイル転送を行うファイル転送システムであって、

前記受信機器は、

前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、

前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、

前記送信機器から前記保存済サイズを問!ヽ合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備え、

前記送信機器は、

ファイルデータを前記受信機器に送信する送信手段と、

前記ファイル転送の中断を検出する検出手段と、

前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に前記保存済データサイズを問い合わせる問合せ手段と、

前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済データサイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備える

ファイル転送システム。

[2] 前記送信手段は、 Hyper Text Transfer Protocol (HTTP)の POSTメソッドまたは PUTメソッドを使用して前記ファイルを前記受信機器に送信する

請求項 1記載のファイル転送システム。

[3] 前記送信制御手段は、更に、前記送信手段がファイルデータを送信する前に、前記ファイルデータの前記ファイルにおける範囲であるデータ範囲を前記受信機器に通知し、

前記受信機器は、更に、前記データ範囲に基づき、前記保存手段に保存されているファイルデータと、前記データ範囲が通知された後に受信したファイルデータとを結合するファイル制御手段を備える

請求項 1記載のファイル転送システム。

[4] 前記送信制御手段は、前記データ範囲とともに前記ファイルの総サイズを前記受信機器に通知する

請求項 3記載のファイル転送システム。

[5] 前記送信制御手段は、更に、前記ファイルを所定のサイズのファイルデータに分割し、

前記送信手段は、前記送信制御手段により分割されたファイルデータを前記受信機器に送信する

請求項 4記載のファイル転送システム。

[6] 前記受信制御手段は、更に、ファイル転送の中断を要求する中断要求を前記送信機器へ送信し、

前記中断要求は、前記受信機器が前記ファイル転送を再開する始期を示す始期情報と、前記受信機器が前記ファイル転送を受け入れる終期を示す期間情報とを含み、

前記検出手段は、前記中断要求を受信することで前記ファイル転送の中断を検出し、

前記送信制御手段は、前記始期から前記許可期間の間に前記残りのファイルデータを前記送信手段に送信させる

請求項 1記載のファイル転送システム。

[7] 前記送信制御手段は、更に、前記送信手段がファイルデータを送信する前に、前記ファイルデータの前記受信機器における保持期間を前記受信機器に通知し、前記受信制御手段は、更に、前記ファイルデータが前記保存手段に保存され、かつ、前記ファイルデータの保持期間が経過する前に、前記ファイルを構成する全てのファイルデータを前記送信機器から受信しなヽ場合、前記保存手段に保存されて、る前記ファイルデータを削除する

請求項 1記載のファイル転送システム。

[8] 前記送信機器と前記受信機器とは Transmission Control Protocol (TCP)接続によりファイル転送を行、、

前記検出手段は、前記送信制御手段が、ファイルデータの送信中に前記 TCP接続を切断したことを検出することで前記ファイル転送の中断を検出し、

前記送信制御手段は、更に、前記 TCP接続の切断後に、ファイルデータの前記受信機器における保持期間を前記受信機器に通知し、

前記受信制御手段は、更に、前記送信機器から通知された前記保持期間が経過する前に、前記ファイルを構成する全てのファイルデータを前記送信機器から受信しない場合、前記保存手段に保存されているファイルデータを削除する

請求項 1記載のファイル転送システム。

[9] 前記送信機器と前記受信機器とは Transmission Control Protocol (TCP)接続によりファイル転送を行、、

前記送信制御手段は、更に、前記 TCP接続が前記受信機器により切断されると、ファイル転送の許可を得るための転送要求を前記受信機器に送信し、

前記受信制御手段は、更に、前記転送要求への応答として前記ファイル転送の中断を要求する中断要求を前記送信機器に送信し、

前記検出手段は、前記中断要求を受信することにより前記ファイル転送の中断を検出する

請求項 1記載のファイル転送システム。

[10] ネットワークを介し、受信機器へファイルを転送するファイル転送を行う送信機器であって、

前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、前記ファイル転送の中断を検出する検出手段と、

前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に保存されてヽるファイルデータのサイズである保存済データサイズを問ヽ合わせる問合せ手段と、

前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済データサイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備える送信機器。

[11] ネットワークを介し、送信機器カゝら送信されるファイルを受信する受信機器であって前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、

前記送信機器から前記保存済サイズを問!ヽ合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段と

を備える受信機器。

[12] ネットワークを介し、受信機器へファイルを転送するファイル転送を行うための送信方法であって、

前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと前記ファイル転送の中断を検出する検出ステップと、

前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に保存されてヽるファイルデータのサイズである保存済データサイズを問ヽ合わせる問合せステップと、

前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済データサイズに基づき、前記ファイルを構成する残りのファイルデータを前記受信機器に送信する送信制御ステップと

を含む送信方法。

[13] ネットワークを介し、送信機器から送信されるファイルを受信するための受信方法であって、

前記送信機器から受信する、前記ファイルを構成するファイルデータを保存手段に保存する保存ステップと、

前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得ステップと、

前記送信機器から前記保存済サイズを問!ヽ合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御ステツプと

を含む受信方法。

[14] ネットワークを介し、受信機器へファイルを転送するファイル転送を行うためのプログラムであって、

をコンピュータに実行させるためのプログラム。

[15] ネットワークを介し、送信機器から送信されるファイルを受信するためのプログラムであって、

をコンピュータに実行させるためのプログラム。