WO2006046445A1

WO2006046445A1 - ファイル転送システム、送信機器及び受信装置

Info

Publication number: WO2006046445A1
Application number: PCT/JP2005/019188
Authority: WO
Inventors: Monta Nakatsuka; Hideaki Takechi; Toshiharu Koshino
Original assignee: Matsushita Electric Industrial Co., Ltd.
Priority date: 2004-10-29
Filing date: 2005-10-19
Publication date: 2006-05-04
Also published as: EP1811391A1; US20080126517A1; JPWO2006046445A1

Abstract

　ＨＴＴＰのＰＯＳＴメソッドを用いて、ネットワークを介して送信機器から受信機器に対して自発的にファイル転送を行う場合において、送信機器が受信機器のファイル転送能力を確認して効率的なファイル転送を可能とするファイル転送システムを提供するために、ソース機器からシンク機器のファイル転送の再開・中断が可能かどうかを確認する際に、UPnP-AV規格で規定されるCDS:CreateObjectアクションリクエスト時にインプットされるメタデータ情報４００に、シンク機器側におけるファイル転送中断・再開能力を尋ねるための情報（４０１及び４０２）を記載する。

Description

明細書

ファイル転送システム、送信機器及び受信装置

技術分野

[0001] 本発明は、ネットワークを介してファイル転送を行うためのファイル転送システム、送信機器及び受信装置に関し、特に、ファイルに付随する情報 (メタデータ)の管理を行ヽファイル転送を行うファイル転送システム、送信機器及び受信装置に関する。背景技術

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

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

[0004] この様なファイル転送を行うプロトコルでは一般的に、ファイルの転送が誤り無く行われることが要求され、その一方リアルタイムの転送は必ずしも要求されない。 IP(Inte rnet Protocol)においてファイル転送を行う代表的なプロトコルとしては、 RFC2616で定義される HTTP (Hyper Text Transfer Protocol)や、 RFC959で定義される FTP(Fil e Transfer Protocol)等が存在する。これらのプロトコルはいずれも RFC793で定義される TCP(Transmission Control Protocol)プロトコルの再送機能によって転送の信頼性を確保している。

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

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

[0007] 図 1は、従来のソース機器及びシンク機器により構成されるファイル転送システムにおけるファイル転送の再開に係る通信シーケンスの一例を示す図である。なお、図 1 は、シンク機器 1002からの「HTTP GETリクエスト」の要求に基づいて、ソース機器 1001からシンク機器 1002にファイル転送を行うものである。

[0008] 本手順では、最初に、シンク機器 1002はソース機器 1001に対し、「HTTP GET リクエスト」を発行する（S 101)。次に、ソース機器 1001は本リクエストに対し、「200 OK」を応答し（S102)、 1000バイトのファイルの送信を開始する（S 103)。本図においては、ここで通信障害が発生し (S 104)、 TCP接続が切断され、それまでにシンク機器 1002には 500バイトのデータが保存できていたとする（S105)。この場合、シンク機器 1002は、通信障害が回復するのを待ち、任意の時点で TCPの再接続を行い、転送を再開することができる。転送の再開はシンク機器 1002がソース機器 1001に対し、 Rangeヘッダを追加した「HTTP GETリクエスト」により、 500バイト以降目の部分のファイルを要求することにより行われる（S106)。

[0009] そして、ソース機器 1001は、シンク機器 1002から指定された Range (ここでは 500 -999バイト目）に従ってファイルを送信し（S107及び S108)、シンク機器 1002がこれを保存することで (S 109)、転送済みのデータを再送することなぐ未転送のデータのみを転送の再開によって取得することが可能である。このように、本図に示すファィル転送システムにお、ては、ファイル転送を再開するブロックをシンク機器 1002側が記憶しておくことで、不足データ部分を確実に配信することが可能となる。そして、この様な手順力例えばインターネット上のサーバに配置される数メガバイト以上もの大きなファイルのダウンロードが失敗した際に、続き力も取得することで効率よくフアイルを取得するアプリケーションなどで使用されている。

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

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

発明の開示

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

[0011] しかしながら、この様な従来のファイル転送システムにおける HTTPの中断、再開手順は、クライアント手動等で受信機器側カゝらファイル転送を要求する HTTPの GE Tメソッドには使用できる一方、 HTTPの POSTメソッドは使用できないという問題がある。

[0012] そして、インターネット上のサーバから PCにファイルをダウンロードする場合は HTT Pの GETメソッドが使用されるためこの様な制約は問題にはならないが、ネットワークに接続される任意の機器間でファイルを転送する場合にぉヽて、ソース機器 (例えば宅内の DVDレコーダ）が任意のファイルを自発的にシンク機器 (例えば宅内の PC) に送りつけようとする場合においては通常 HTTPの POSTメソッドが用いられるため、この様な場合にはファイル転送の中断、再開を行うことができな、と、う課題がある。

[0013] この課題は、より一般的にいうと、従来の送信機器側力も受信機器側にデータを送りつけることをトリガとしてプッシュ型のフロー制御を行うファイル転送プロトコルにおいては、受信機器側カゝら送信機器側にリクエストを発行するプル型のフロー制御と異なり、送信機器側からの受信機器側のファイル転送能力の確認の手順や、ファイル転送の中断、再開を行う手順が存在しな、ことに起因して、る。

[0014] また、 HTTPの POSTメソッド等を用いて送信機器カゝら受信機器に自発的にデータを送りつけるファイル転送プロトコルにおいては、送信機器カゝら受信機器のファイル転送の再開 ·中断等の能力を確認する手順も存在して、な、。 [0015] 本発明は、上記課題を考慮し、 HTTPの POSTメソッド等を用いて送信機器側から受信機器側に自発的にデータを送りつけるプッシュ型のフロー制御を行うファイル転送プロトコルにおいても、送信機器が受信機器のファイル転送の中断 ·再開能力の確認ができ、また、ソース機器、シンク機器の都合や、 TCP接続のタイムアウトなどでネットワーク切断された場合にも、効率的に残りのファイル転送の再開を可能にするファイル転送システム、送信機器及び受信装置を提供することを目的とする。

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

[0016] 上記目的を達成するために、本発明に係るファイル転送システムは、ネットワークを介して、ファイルを送信する送信機器と、ファイルを受信する受信機器との間でフアイルを転送するファイル転送システムであって、前記送信機器は、前記受信機器のファィル転送の能力を確認する能力確認手段と、前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、前記ファイル転送の能力に応じて、前記フアイルデータを前記送信手段に送信させる送信制御手段とを備え、前記受信機器は、前記送信機器力のファイル転送に関する能力確認に対して返答する能力返答手段と、前記ファイルを構成するファイルデータを受信する受信手段と、前記能力に応じて、前記ファイルデータを前記受信手段に受信させる受信制御手段とを備えることを特徴とする。

[0017] また、前記能力返答手段は、 HTTP (Hyper Text Transfer Protocol)の PO STメソッド或いは PUTメソッドの独自のレンジヘッダ拡張に対する能力に関して返答し、前記能力確認手段は、 HTTPの POSTメソッド或いは PUTメソッドの独自のレンジヘッダ拡張に対する前記受信機器の能力確認を行うことで、前記受信機器のファィル転送の能力を確認することを特徴とする。

[0018] また、前記送信手段は、 HTTPの POSTメソッド又は PUTメソッドを使用して前記フアイルデータを前記受信機器に送信し、前記受信手段は、 HTTPの POSTメソッド又は PUTメソッドを使用して前記送信機器から送信される前記ファイルデータを受信することを特徴とする。

[0019] これらの構成により、本発明に係るファイル転送システムにおいては、 HTTPの PO STメソッド等を用いて送信機器カゝら受信機器に自発的にデータを送りつけるファイル転送プロトコルにお、ても、

、て受信機器の HTTPの POSTメソッド或いは PUTメソッドの独自のレンジヘッダ拡張に対する能力を確認することにより、受信機器のファイル転送に関する能力を確認でき、送信制御手段で受信機器のファイル転送の能力に合わせてファイルデータの送信を制御することが可能となる。

[0020] また、本発明に係るファイル転送システムにお 1、て、前記送信機器は、さらに、前記受信機器でのファイル転送に関する情報を取得するための情報取得コマンドを生成するコマンド生成手段を備え、前記送信手段は、前記情報取得コマンドを前記受信機器に送信し、前記受信機器は、さらに、 HTTPの POSTメソッド或いは PUTメソッドのレンジヘッダに、受信した前記ファイルデータの元となる前記ファイルの総サイズ及び前記ファイルデータの実転送完了サイズを記録する記録手段を備え、前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、前記記録手段にお Vヽて記録された情報を返答することを特徴とする。

[0021] さらに、前記記録手段は、さらに、 HTTPの POSTメソッド或いは PUTメソッドにおいてファイル転送状況を記録し、前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、記録された前記ファイル転送状況を返答することを特徴とする。

[0022] これらの構成により、本発明に係るファイル転送システムにおいては、送信機器から受信機器に対して情報取得コマンドを送信して受信機器側でのファイルデータの実転送完了サイズやファイル転送状況といったファイル転送に関する情報を取得することができるため、 HTTPの POSTメソッドによるプッシュ型のフロー制御を行うファイル転送プロトコルを用いる場合にも、送信機器側から受信機器側のファイル転送の中断'再開能力の確認、未転送のデータのみを転送する等、より効率的なファイル転送の再開を可能とする。

[0023] さらに、本発明の送信機器及び受信機器それぞれの特徴的な構成部をステップとする送信方法及び受信方法として実現したり、コンピュータに各ステップを実行させるためのプログラムとして実現することもできる。そのようなプログラムは、 CD-ROM 等の記録媒体やインターネット等の伝送媒体を通じて配信することができるのは言うまでもない。

発明の効果

[0024] 本発明に係るファイル転送システムによれば、特に HTTPの POSTメソッドによるプッシュ型のフロー制御を行うファイル転送プロトコルを用いる場合にも、送信機器側から受信機器側のファイル転送の中断'再開能力の確認ができ、また、未転送のデータのみを転送する効率的なファイル転送の再開を可能とする。

図面の簡単な説明

[0025] [図 1]図 1は、従来例に係るファイル転送システムの通信シーケンス図である。

[図 2]図 2は、本発明の第 1の実施例に係るファイル転送システムの通信シーケンス図である。

[図 3]図 3は、 CreateObjectアクションリクエスト時に入力される通常のメタデータ情報の参考図である。

[図 4]図 4は、本発明の第 1の実施例に係る CreateObjectアクションリクエスト時に入力されるメタデータ情報の参考図である。

[図 5]図 5は、本発明の第 1の実施例に係るシンク機器において生成されるメタデータ情報の参考図である。

[図 6]図 6は、本発明の第 1の実施例に係るシンク機器において生成されるメタデータ情報の参考図である。

[図 7]図 7は、本発明に係るソース機器の機能ブロック図である。

[図 8]図 8は、本発明に係るシンク機器の機能ブロック図である。

[図 9]図 9は、本発明の第 2の実施例に係るファイル転送の中断シーケンス図である。

[図 10]図 10は、本発明の第 3の実施例に係るファイル転送の中断シーケンス図である。

[図 11]図 11は、本発明の第 3の実施例に係るファイル転送の中断シーケンス図である。

[図 12]図 12は、本発明の第 3の実施例に係るファイル転送の中断シーケンス図である。

[図 13]図 13は、本発明の第 2の実施例に係るシンク機器において管理されるメタデータ情報の参考図である。

[図 14]図 14は、本発明の第 3の実施例に係るシンク機器において管理されるメタデータ情報の参考図である。

符号の説明

[0026] 101 ソース機器

102 シンク機器

300, 400, 500, 600, 1300, 1400 メタデータ情報

701 ユーザインタフェース

702 ファイル送信制御部

703 ファイル制御部

704 通信制御部

705 ファイル蓄積部

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

707 転送するファイル

708 ファイルの付随情報 (メタデータ）

801 ファイル受信制御部

802 ファイル制御部

803 通信制御部

804 ファイル蓄積部

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

806 転送されたファイル

807 転送されたファイルの付随情報 (メタデータ）

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

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

(実施の形態 1)

以下で、本発明に係るファイル転送システムの第 1の実施例について、図面を参照しながら説明する。

[0028] 図 2において送信機器としてのソース機器 101と受信機器としてのシンク機器 102 は各々蓄積メディアを内蔵し、ファイルを蓄積することができる。この様な機器の例としてネットワーク接続端子を備えた DVDZHDDノヽイブリツドレコーダなどが上げられる。本実施例の初期状態ではソース機器 101が転送したいファイルを蓄積しており、ネットワークを介してシンク機器 102に転送して蓄積するものとする。なお、シンク機器 102、ソース機器 101ともにユニバーサルプラグアンドプレイフォーラムの発行する UPnP- AV規格に準拠しており、シンク機器 102は CDS (Contents Directory Service) サーバ機能を実装しており、ソース機器 101は CDSサーバにアクセスする Control Poi nt機能を実装して、るものとする。

[0029] ソース機器 101の詳細構成を別の図を用いて説明する。図 7、図 8はそれぞれソース機器 101とシンク機器 102の機能ブロック図である。

[0030] 図 7において、ソース機器 101は、ユーザインタフェース 701、ファイル送信制御部 702、ファイル蓄積部 705からのファイル読出し制御を実行するファイル制御部 703 、ネットワークインタフェース 706を制御してネットワークを介した通信制御を実行する通信制御部 704、実体ファイル 707と共に、実体ファイルの付随情報 (メタデータ）であるファイル object708が格納されて!、るファイル蓄積部 705、及びネットワークインタ一フェース 706を備えるものである。

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

[0032] 図 8において、シンク機器 102は、ファイル受信制御部 801、ファイル蓄積部 804に対するファイル書込み制御を実行するファイル制御部 802、ネットワークインタフエ一ス 805を制御してネットワークを介した通信制御を実行する通信制御部 803、ソース側からのファイル転送完了後に、実体ファイル 806及びファイル付随情報 (メタデータ ) 807が生成及び蓄積するファイル蓄積部 804、及びネットワークインターフェース 80 5を備えるものである。

[0033] 以上のような構成において、図 4に示すように、ソース機器 101は実体ファイル 707 の転送に先立って、シンク機器 102に対し UPnP-AV規格で規定される CDS:CreateO bjectアクションリクエストを発行する（S203)。

[0034] この CDS:CreateObjectアクションリクエストには、ファイルの付随情報（メタデータ）であるファイル object708力生成されたファイル object807が記述されており、本実施の形態 1におけるファイル object807は、図 4に示すような XMLデータ形式であり、シンク機器 102がファイル転送の再開 ·中断が可能力どうかを確認する際に、 S203の CDS:CreateObjectアクションリクエスト時にインプットされるメタデータ情報 400を示し、図 3に示す従来の CDS:CreateObjectアクションリクエスト時にインプットされる通常のメタデータ情報 300に加え、本実施例においては、シンク側におけるファイル転送中断 ·再開能力を尋ねるための情報 (401及び 402)が加えられている。

[0035] 図 4では「ext： POSTRequest = "1" (402)」と記載して!/、るが、これら文字列及び数値を本実施例にぉ、て特定するものではな、。 CDS:CreateObjectアクションリクェストを受信したシンク機器 102では、ファイル object807をファイル蓄積部 804に格納した上で、ディレクトリの位置や、ファイル名等のメタデータをファイル object807に追記する。この際のメタデータには特にファイル実体を保存すべきシンク機器 102上の URLが含まれており、追記されたファイル object807は S104に示す CDS:CreateObje ctアクションレスポンスによりソース機器 101に通知される。

[0036] また、本実施例においては、図 5のソース機器 101からのファイル転送の再開 '中断確認要求に対する OKの場合の CDS:CreateObjectアクションレスポンスにインプットするメタデータ情報 500に示すように、シンク機器 102におけるファイル転送中断'再開能力を通知するための情報として、「ext : POSTRequest = "l" (501)」が記されている。シンク機器 102においてファイル転送中断'再開能力がない場合は、図 6のメタデータ情報 600に示すように「ext： POSTRequest = "l"jを記さな!/、ようにする力「ext： POSTRequest = "0"jと返答する（S204)。

[0037] そして、シンク機器 102から CDS:CreateObjectアクションレスポンスを受信したソース機器 101は、ファイル転送の再開'中断が可能と判断した上で、ファイルを分割転送するサイズを決定する。分割転送のサイズは転送の中断、再開の頻度、中断時に無駄になる転送サイズ、分割によるオーバヘッド等を勘案して任意に決定することができる。ここでは lOOOByteのファイルを、最初の 0 - 499byte、次の 500 - 999Byteに分割して送信するものとし、ソース機器は HTTPの POSTメソッドを送信する（S205)

[0038] また、 POSTメソッドには本発明で独自に定義したヘッダである、 Upload Range: [byt e- RangeTotal size]が含まれる。ここでの「byte- Range」は、続く HTTPの Entity Body 部に含まれるデータの範囲を示し、 rtotal size」では HTTPの POSTメソッドにおいて最終的に転送するファイルの総サイズ lOOObyteを示す。 S205では最初の分割転送単位である、 0- 499byteが指定される。 POSTメソッドで指定する URLには、 CreateO bjectアクションレスポンスに記述されるファイル Object807に含まれる URLを記述する。これにより、シンク機器 102は特定のファイル Objectと、受信したファイルの実体を対応させることができる。さらに、 S205においてはヘッダとしてさらに、 Expect: 100- continueが記述されているため、シンク機器は RFC2616に従って、 S205における P OSTリクエストをその URLで受け入れることができるかのチェックを行、、可能であれば 100 Continueレスポンスを返す（S206)。この動作により、 S205の POSTリクエストを受け入れたり、解釈することができない場合にはデータの転送の前にソース機器に通知することができ、無駄なデータ送信を回避することができる。

[0039] そして、ソース機器 101は、 HTTPの POSTの Entity Body送信を開始する（S207) 。「Entity Body」に含まれるファイルの範囲は、 0- 499byte範囲のみである。シンク機器 102はこの 500byte分を受信すると内蔵するファイル蓄積部 807へ保存を行う（S2 08)。

[0040] 次に、本実施の形態にお!、ては、 S204にお!/、て受信した「CDS:CreateObjectァクシヨンレスポンス」に基づきソース機器 101は、シンク機器 102がファイル転送の再開 •中断が可能と判断したために、ソース機器 101は、次の 500-999Byteに分割して送信するための HTTPの POSTメソッドを送信する（S209)。なお、この POSTメソッドの Upload Range: [byte- RangeTotal size]に含まれる「byte- Range」には、最後の分割転送単位である、 500-999 byteが指定され、「total size」では HTTPの POSTメソッドにおいて最終的に転送するファイルの総サイズ lOOObyteを示す。

[0041] また、 POSTメソッドで指定する URLには、「CreateObjectアクションレスポンス」に記述されるファイル Obiect807に含まれる URLを記述され、また、 S209においてはへッダとしてさらに、「Expect: 100- continue」が記述されているため、シンク機器は RFC2 616に従って、 S209における POSTリクエストをその URLで受け入れることができるかのチェックを行い、可能であれば「100 Continueレスポンス」を返す（S210)。

[0042] そして、ソース機器 101は、 HTTPの POSTの Entity Body送信を開始する（S211) 。「Entity Body」に含まれるファイルの範囲は、 500-999byte範囲のみである。シンク機器 102はこの 500byte分を受信すると内蔵するファイル蓄積部 807へ保存を行い、一連のファイル転送の処理を終了する（S212)。

[0043] このように、本実施の形態 1に係るファイル転送システムにおいては、 HTTPの PO STメソッドを用いてファイルを送りつけるプッシュ型のフロー制御でもファイルを分割して送信を行うことが可能になる。なお、 HTTPで当然使用されるその他のヘッダについては本発明の動作に関係しないので記載を省略する。また、ここで定義したへッダ名は別のヘッダ名でもかまわな!/、。

[0044] 以上のように、本実施の形態 1に係るファイル転送システムにおいては、 HTTPの P OSTメソッド等を用いてソース機器 101からシンク機器 102に自発的にデータを送りつけるファイル転送プロトコルを用いる場合においても、ファイルに付随するメタデータ情報に新たなファイル転送のための情報を付加することにより、ソース機器 101が自発的にシンク機器 102のファイル転送能力の確認を行うことが可能となる。

[0045] このため、ソース機器 101は、シンク機器 102がファイル転送の中断'再開が不可能であれば、中断'再開を許容しない通常のプッシュ型のファイル転送を実行するシ一ケンスへ移行させ、シンク機器 102が中断'再開が可能であれば、中断'再開を許容するプッシュ型のファイル転送を実行するシーケンスへ移行させることができ、この場合には、ファイルを任意のサイズに分割して分割ファイルの転送を行うことができる

[0046] また、 HTTPの POSTメソッドを用い、ファイル送信を行うソース機器 101でファイルを分割し、拡張されたヘッダにより転送範囲を明示して送信できるため、シンク機器 1 02がファイル転送の再開が可能であると確認できる場合には、分割したファイル転送の中断'再開が可能となる。

[0047] (実施の形態 2) 以下で、本発明に係るファイル転送システムの第 2の実施例について、図面を参照しながら説明する。なお、本実施の形態 2に係るファイル転送システムは、ファイル転送の途中でソース機器側の都合によりファイル転送を中断する場合において、ソース機器カゝらシンク機器に対して CDS： Browseリクエストを送信することを特徴とするものである。また、本実施の形態 2に係るソース機器及びシンク機器の内部構成そのものは、実施の形態 1の図 7、図 8で説明した通りであり、また、ソース機器とシンク機器間にお、て任意のサイズでのファイル転送を行うまでの手順も実施の形態 1の図 2で説明した通りであるために、これらの詳細な説明を省略する。

[0048] 図 9は、本実施の形態 2に係るファイル転送システムにおいて、何らかの事情により POSTメソッドによるファイル転送が中断した状態からの再開シーケンスを説明する。なお、図 9における S201から S208までの処理は、上述した実施の形態 1の図 2で説明したものと同じである。

[0049] この状態において、何らかの事情により POSTメソッドによるファイル転送が中断した場合、ソース機器 101は、再開すべきファイルサイズを特定するために、 CDS:Brow seアクションリクエストをシンク機器 102に対して送信し（S901)、 CDS:Browseァクションレスポンスによってシンク機器が保有して、るファイル objcet807を取得する（S902 ) oなお、上記の何らかの理由とは、例えばソース機器としての DVDレコーダを用いて転送途中に、この DVDレコーダを介してテレビを視聴し始めてファイル転送が中断されたような場合である。

[0050] そして、ソース機器 101は、ファイル Object807に記述されている「ext: POSTedSi ze = "499Zl000"」を取得することで、シンク機器 102がファイル転送中断前までに取得したファイルサイズ (本実施の形態 2においては 499byte)を特定することができる。なお、以後の残りとなる 500-999Byteのファイル転送の再開の処理は、図 2の説明〖こおける S209力ら S212と同じとなる。

[0051] そして、本発明の第 2の実施例においては、図 2の S205に示す POSTメソッドを受信したシンク機器 102は、ネットワークインタフェース 805を介して通信制御部 803がパケットを受け取り、ファイル受信制御部 801は POSTメソッドで受け取るサイズを" U pload Range: [byte- Range Total size]"の「bvte- Range」から読み取り、更に最終的に受け取る総サイズを読み取り、ファイル制御部 802を通じてー且メモリ上に保持しておく。

[0052] そして、図 9の S207において実際のデータ転送が完了し次第、ファイル蓄積部 80 4に格納されて!、るファイル object807に追記する。追記された状態のファイル object 807の詳細を図 13にて説明する。図 13は、シンク機器 102側で管理されているメタデータ情報 1300を示し、図 9の S204の CDS:CreateObjectアクションリクエスト受信時に生成された図 5に示すファイル Objectに比べ、図 13のファイル Objectでは、「ext ： POSTedSize = "499/1000" (1301) Jが追記されて、る。ここで示して!/、る" 49 9"は、 POSTメソッドでの実転送サイズであり、 "1000"は総サイズ数を示す。

[0053] この処理を繰り返し、実転送サイズ =総サイズになった時点で POSTメソッドにおけるファイル転送が完了したと見なす。

[0054] 以上のように、本実施の形態 2に係るファイル転送システムにおいては、 HTTPの P OSTメソッドによるファイル転送時にぉ、て、ソース機器側の何らかの都合により中断した残りのファイル転送を、正確に継続して再開することが可能となる。

[0055] (実施の形態 3)

以下、本発明に係るファイル転送システムの第 3の実施例について、図面を参照しながら説明する。なお、本実施の形態 3に係るファイル転送システムは、 POSTメソッドによるファイル転送時において、ファイル転送の中断理由に応じて、その後のフアイル転送を管理することを特徴とするものである。また、本実施の形態 3におけるソース機器及びシンク機器の内部構成そのものは、第 1の実施例の図 7、図 8で説明した通りであり、また、ソース機器とシンク機器間において任意のサイズでのファイル転送を行うまでの手順も実施の形態 1の図 2で説明した通りである。

[0056] 本発明の第 3の実施例においては、中断理由により再開動作が異なる場合について特徴を述べている。 POSTメソッドによるファイル転送が開始されるシーケンスは図 1の通りであるが、シンク機器 102において最初の POSTメソッドをネットワークインタフェース 805を介して通信制御部 803がパケットを受け取ると、ファイル受信制御部 8 01はファイル蓄積部 804に格納されているファイル object 807に「ext:postStatus = "uploading"」を追記する。追記された状態のファイル object 807の詳細は、図 14 にて説明する。

[0057] この図 14は、シンク機器 102側で管理されているメタデータ情報 1400を示し、図 2 の S204における CDS:CreateObjectアクションリクエスト受信時に生成された図 5に示すファイル Objectに比べ、図 13で説明した「ext : postedSize = "499ZlOOO，，（13 01)」の他に、「ext : postStatus = "uploading，，（1401)」が追記されている。この「e xt : postStatusJには、シンク機器におけるファイル転送状態を記述しており、フアイル転送が完了すると同時に、「ext : postStatus」そのものを削除する。

[0058] 図 10ではソース機器 101のユーザ又はプロセッサ処理の判断において POSTメソッドにおけるファイル転送を中断した場合のシーケンスを説明する。

[0059] ソース機器 101からファイル転送を中断する場合には、ソース機器 101は、ヘッダに Upload Control:suspendを付与した POSTメソッドを送信することでシンク機器 102 に中断通知を行う（S1001)。シンク機器 102においては、ネットワークインタフェース 805を介して通信制御部 803がパケットを受け取り、ファイル受信制御部 801は POS Tメソッドで受け取るサイズを" Upload Control:suspend"を読み取り、ファイル蓄積部 8 04に格納されているファイル object 807の内容において、「ext : postStatus = "sus pended"」に修正する（S1002)。次に、シンク機器 102は、ソース機器 101側に「20 0 OK」の返信を行う（S1003)。

[0060] そして、シンク機器 102のファイル受信制御部 801は、定期的又は一定の判断基準に基づいて ext : postStatusの値をチェックし、 "suspended"であった場合はソース側の理由により故意にファイル転送が中断されていると判断し、ファイル 806及びファイル Object807を削除しないなどの処理を行うことが可能となる。また、シンク機器 102におけるユーザインタフェースにファイルの状態を出力した上で、ユーザにフアイル操作させることも可能である。

[0061] 図 11では、ネットワーク障害によりファイル転送を中断した場合のシーケンスを説明する。なお、 S203から S208までの処理は図 2で説明した通りである。

[0062] ここでネットワーク障害が発生し（S 1101)、 POSTメソッドによるファイル転送は中断され、ある一定時間にシンク機器 102においてファイル受信が行われない場合は、ファイル受信制御部 801がファイル蓄積部 804に格納されて!、るファイル object 807 の内容において、「ext : postStatus = "disconnected"」に修正する。

[0063] そして、シンク機器 102のファイル受信制御部 801は、定期的又は一定の判断基準に基づいて ext : postStatusの値をチェックし、 "disconnected"であった場合は、ネットワーク障害によるファイル転送切断であると解釈し、ファイル蓄積部 805に蓄積されているファイル 806及びファイル Object807を削除するなどの処理を行うことが可能となる。また、シンク機器 102におけるユーザインタフェースにファイルの状態を出力した上で、ユーザにファイル操作させることも可能である。

[0064] 図 12では、シンク機器 102の都合によりファイル転送を中断した場合のシーケンスを説明する。 S203から S208までの処理は図 1で説明した通りである。

[0065] ここで、 POSTメソッドにおけるファイル転送要求に対して（S1201)、シンク機器 10 2側にぉ、て、例えばディスク容量オーバーなどの理由でファイル転送を中断した!/ヽ場合には、ソース機器 101側に「503 Service Unavailable」を返信し（S1202)、シンク機器 102のファイル受信制御部 801がファイル蓄積部 804に格納されているフアイル object 807の内容において、「ext : postStatus = "disk full"」に修正する（S 1203)。

[0066] そして、シンク機器 102のファイル受信制御部 801は、定期的又は一定の判断基準に基づいて ext : postStatusの値をチェックし、 "disk full"であった場合は、シンク機器 102のディスク容量オーバとしてファイル蓄積不可によるファイル転送切断であると解釈し、時にはファイル 806及びファイル Object807を削除するなどの処理を行う。またシンク機器 102におけるユーザインタフェースにファイルの状態を出力した上で、ユーザにファイル操作させることも可能である。

[0067] 以上のように、本実施の形態 3に係るファイル転送システムにおいては、 POSTメソッドによるファイル転送時において、ソース機器 101が任意のタイミングでファイル転送を中断 ·再開できるほか、シンク機器 102が任意のタイミングでファイル転送を中断した際においても、ファイル転送の中断理由毎に、ファイル操作及び効率的なフアイル転送の再開が可能となる。

産業上の利用可能性

[0068] 本発明に係るファイル転送システムは、 HTTPの POSTメソッド等を用いてネットヮークに接続される任意の機器間でファイルを転送する場合にぉ、て一般的に用、ることができ、特にファイルのサイズが大きぐ転送を中断して再開する際に、転送を初めからやり直すと無駄が多い場合に効果を発揮する。

Claims

請求の範囲

[1] ネットワークを介して、ファイルを送信する送信機器と、ファイルを受信する受信機器との間でファイルを転送するファイル転送システムであって、

前記送信機器は、

前記受信機器のファイル転送の能力を確認する能力確認手段と、

前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、前記ファイル転送の能力に応じて、前記ファイルデータを前記送信手段に送信させる送信制御手段とを備え、

前記受信機器は、

前記送信機器力のファイル転送に関する能力確認に対して返答する能力返答手段と、

前記ファイルを構成するファイルデータを受信する受信手段と、

前記能力に応じて、前記ファイルデータを前記受信手段に受信させる受信制御手段とを備える

ことを特徴とするファイル転送システム。

[2] 前記能力返答手段は、 HTTP (Hyper Text Transfer Protocol)の POSTメソッド或、は PUTメソッドの独自のレンジヘッダ拡張に対する能力に関して返答し、前記能力確認手段は、 HTTPの POSTメソッド或いは PUTメソッドの独自のレンジヘッダ拡張に対する前記受信機器の能力確認を行うことで、前記受信機器のフアイル転送の能力を確認する

ことを特徴とする請求項 1記載のファイル転送システム。

[3] 前記送信手段は、 HTTPの POSTメソッド又は PUTメソッドを使用して前記フアイルデータを前記受信機器に送信し、

前記受信手段は、 HTTPの POSTメソッド又は PUTメソッドを使用して前記送信機器から送信される前記ファイルデータを受信する

ことを特徴とする請求項 1記載のファイル転送システム。

[4] 前記能力確認手段において前記受信機器がファイル転送の中断'再開が可能であると確認される場合には、前記送信制御手段は、前記ファイル転送の中断'再開を許容するプッシュ型のファイル転送を実行するシーケンスへ移行させる一方、前記能力確認手段において前記受信機器がファイル転送の中断'再開が不可能であると確認される場合には、前記送信制御手段は、前記ファイル転送の中断'再開を許容しないプッシュ型のファイル転送を実行するシーケンスへ移行させる

ことを特徴とする請求項 1記載のファイル転送システム。

[5] 前記送信機器は、さら〖こ、

前記受信機器でのファイル転送に関する情報を取得するための情報取得コマンドを生成するコマンド生成手段を備え、

前記送信手段は、前記情報取得コマンドを前記受信機器に送信し、

前記受信機器は、さらに、

HTTPの POSTメソッド或いは PUTメソッドのレンジヘッダに、受信した前記フアイルデータの元となる前記ファイルの総サイズ及び前記ファイルデータの実転送完了サイズを記録する記録手段を備え、

前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、前記記録手段にぉ、て記録された情報を返答する

ことを特徴とする請求項 1記載のファイル転送システム。

[6] 前記記録手段は、さらに、 HTTPの POSTメソッド或いは PUTメソッドにおいてファィル転送状況を記録し、

前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、記録された前記ファイル転送状況を返答する

ことを特徴とする請求項 5記載のファイル転送システム。

[7] 前記ファイル転送状況は、アップロード中、送信機器側からのサスペンド要求による中断、ネットワーク切断による中断、又は受信機器側からのディスク容量オーバのいずれか 1つであり、

前記受信機器は、さらに、

受信した前記ファイルを格納する格納手段を備え、

前記ファイル転送情報が、前記ネットワーク切断による中断である場合には、前記格納手段に格納され、前記中断前に受信したファイルデータは消去可能であることを特徴とする請求項 6記載のファイル転送システム。

[8] 前記送信手段は、さらに、 UPnP-AV規格で規定される CDS:CreateObjectアクションリクエストとして、少なくとも前記ファイル転送の中断又は再開が可能かを確認する情報を含むメタデータ情報を前記受信機器に送信し、

前記受信手段は、さらに、前記メタデータ情報を受信し、

前記能力返答手段は、前記メタデータ情報に基づいて、 UPnP-AV規格で規定される CDS:CreateObjectアクションレスポンスとして、前記送信機器に対して前記ファイル転送の中断又は再開が可能である力否かの能力を返答し、

前記能力確認手段は、前記返答に基づいて、前記受信機器の前記ファイル転送の能力を確認する

ことを特徴とする請求項 1記載のファイル転送システム。

[9] ネットワークを介して受信機器に対してファイルを送信する送信機器であって、前記受信機器のファイル転送の能力を確認する能力確認手段と、

前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、前記ファイル転送の能力に応じて、前記ファイルデータを前記送信手段に送信させる送信制御手段とを備える

ことを特徴とする送信機器。

[10] 前記能力確認手段は、 HTTPの POSTメソッド或いは PUTメソッドの独自のレンジヘッダ拡張に対する前記受信機器の能力確認を行うことで、前記受信機器のフアイル転送の能力を確認する

ことを特徴とする請求項 9記載の送信機器。

[11] 前記送信手段は、 HTTPの POSTメソッド又は PUTメソッドを使用して前記フアイルデータを前記受信機器に送信する

ことを特徴とする請求項 9記載の送信機器。

[12] 前記送信機器は、さら〖こ、

前記受信機器に送信される前記ファイルを複数に分割する分割手段を備え、前記送信制御手段は、前記能力確認手段にぉヽて前記受信機器がファイル転送の中断'再開が可能であると確認される場合において、前記ファイルを前記分割手段において分割された分割ファイルデータの単位で前記送信手段に送信させ、前記送信手段は、前記分割ファイルデータを前記受信機器に送信することを特徴とする請求項 9記載の送信機器。

[13] 前記送信機器は、さら〖こ、

HTTPの POSTメソッド或いは PUTメソッドのレンジヘッダに、前記分割ファイルデータの元となるファイルにおけるデータ範囲、及び前記元となるファイルの総サイズの少なくとも一方を格納する格納手段を備える

ことを特徴とする請求項 12記載の送信機器。

[14] ネットワークを介して、送信機器力も送信されるファイルを受信する受信機器であつて、

ことを特徴とする受信機器。

[15] 前記能力返答手段は、 HTTPの POSTメソッド或いは PUTメソッドの独自のレンジヘッダ拡張に対する能力に関して返答する

ことを特徴とする請求項 14記載の受信機器。

[16] 前記受信手段は、 HTTPの POSTメソッド又は PUTメソッドを使用して前記送信機器から送信される前記ファイルデータを受信する

ことを特徴とする請求項 14記載の受信機器。

[17] ネットワークを介して受信機器に対してファイルを送信する送信方法であって、前記受信機器のファイル転送の能力を確認する能力確認ステップと、

前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと前記ファイル転送の能力に応じて、前記ファイルデータを前記送信ステップにおヽて送信させる送信制御ステップとを含むことを特徴とする送信方法。

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

前記送信機器力ゝらのファイル転送に関する能力確認に対して返答する能力返答ステツプと、

前記ファイルを構成するファイルデータを受信する受信ステップと、

前記能力に応じて、前記ファイルデータを前記受信ステップにお、て受信させる受信制御ステップとを含む

ことを特徴とする受信方法。

[19] ネットワークを介して受信機器に対してファイルを送信する送信機器に用いるプログラムであって、

前記受信機器のファイル転送の能力を確認する能力確認ステップと、

前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと前記ファイル転送の能力に応じて、前記ファイルデータを前記送信ステップにおヽて送信させる送信制御ステップと

をコンピュータに実行させることを特徴とするプログラム。

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

前記能力に応じて、前記ファイルデータを前記受信ステップにお、て受信させる受信制御ステップと