(57)【要約】ＨＴＴＰのＰＯＳＴメソッドを用いて、ネットワークを介して送信機器から受信機器に対して自発的にファイル転送を行う場合において、送信機器が受信機器のファイル転送能力を確認して効率的なファイル転送を可能とするファイル転送システムを提供するために、ソース機器からシンク機器のファイル転送の再開・中断が可能かどうかを確認する際に、ＵＰｎＰ−ＡＶ規格で規定されるＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションリクエスト時にインプットされるメタデータ情報４００に、シンク機器側におけるファイル転送中断・再開能力を尋ねるための情報（４０１及び４０２）を記載する。【特許請求の範囲】
【請求項１】
ネットワークを介して、ファイルを送信する送信機器と、ファイルを受信する受信機器との間でファイルを転送するファイル転送システムであって、
前記送信機器は、
前記受信機器のファイル転送の能力を確認する能力確認手段と、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の能力に応じて、前記ファイルデータを前記送信手段に送信させる送信制御手段とを備え、
前記受信機器は、
前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答手段と、
前記ファイルを構成するファイルデータを受信する受信手段と、
前記能力に応じて、前記ファイルデータを前記受信手段に受信させる受信制御手段とを備える
ことを特徴とするファイル転送システム。
【請求項２】
前記能力返答手段は、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）のＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する能力に関して返答し、
前記能力確認手段は、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する前記受信機器の能力確認を行うことで、前記受信機器のファイル転送の能力を確認する
ことを特徴とする請求項１記載のファイル転送システム。
【請求項３】
前記送信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記ファイルデータを前記受信機器に送信し、
前記受信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記送信機器から送信される前記ファイルデータを受信する
ことを特徴とする請求項１記載のファイル転送システム。
【請求項４】
前記能力確認手段において前記受信機器がファイル転送の中断・再開が可能であると確認される場合には、前記送信制御手段は、前記ファイル転送の中断・再開を許容するプッシュ型のファイル転送を実行するシーケンスへ移行させる一方、前記能力確認手段において前記受信機器がファイル転送の中断・再開が不可能であると確認される場合には、前記送信制御手段は、前記ファイル転送の中断・再開を許容しないプッシュ型のファイル転送を実行するシーケンスへ移行させる
ことを特徴とする請求項１記載のファイル転送システム。
【請求項５】
前記送信機器は、さらに、
前記受信機器でのファイル転送に関する情報を取得するための情報取得コマンドを生成するコマンド生成手段を備え、
前記送信手段は、前記情報取得コマンドを前記受信機器に送信し、
前記受信機器は、さらに、
ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドのレンジヘッダに、受信した前記ファイルデータの元となる前記ファイルの総サイズ及び前記ファイルデータの実転送完了サイズを記録する記録手段を備え、
前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、前記記録手段において記録された情報を返答する
ことを特徴とする請求項１記載のファイル転送システム。
【請求項６】
前記記録手段は、さらに、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドにおいてファイル転送状況を記録し、
前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、記録された前記ファイル転送状況を返答する
ことを特徴とする請求項５記載のファイル転送システム。
【請求項７】
前記ファイル転送状況は、アップロード中、送信機器側からのサスペンド要求による中断、ネットワーク切断による中断、又は受信機器側からのディスク容量オーバのいずれか１つであり、
前記受信機器は、さらに、
受信した前記ファイルを格納する格納手段を備え、
前記ファイル転送情報が、前記ネットワーク切断による中断である場合には、前記格納手段に格納され、前記中断前に受信したファイルデータは消去可能である
ことを特徴とする請求項６記載のファイル転送システム。
【請求項８】
前記送信手段は、さらに、ＵＰｎＰ−ＡＶ規格で規定されるＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションリクエストとして、少なくとも前記ファイル転送の中断又は再開が可能かを確認する情報を含むメタデータ情報を前記受信機器に送信し、
前記受信手段は、さらに、前記メタデータ情報を受信し、
前記能力返答手段は、前記メタデータ情報に基づいて、ＵＰｎＰ−ＡＶ規格で規定されるＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションレスポンスとして、前記送信機器に対して前記ファイル転送の中断又は再開が可能であるか否かの能力を返答し、
前記能力確認手段は、前記返答に基づいて、前記受信機器の前記ファイル転送の能力を確認する
ことを特徴とする請求項１記載のファイル転送システム。
【請求項９】
ネットワークを介して受信機器に対してファイルを送信する送信機器であって、
前記受信機器のファイル転送の能力を確認する能力確認手段と、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の能力に応じて、前記ファイルデータを前記送信手段に送信させる送信制御手段とを備える
ことを特徴とする送信機器。
【請求項１０】
前記能力確認手段は、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する前記受信機器の能力確認を行うことで、前記受信機器のファイル転送の能力を確認する
ことを特徴とする請求項９記載の送信機器。
【請求項１１】
前記送信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記ファイルデータを前記受信機器に送信する
ことを特徴とする請求項９記載の送信機器。
【請求項１２】
前記送信機器は、さらに、
前記受信機器に送信される前記ファイルを複数に分割する分割手段を備え、
前記送信制御手段は、前記能力確認手段において前記受信機器がファイル転送の中断・再開が可能であると確認される場合において、前記ファイルを前記分割手段において分割された分割ファイルデータの単位で前記送信手段に送信させ、
前記送信手段は、前記分割ファイルデータを前記受信機器に送信する
ことを特徴とする請求項９記載の送信機器。
【請求項１３】
前記送信機器は、さらに、
ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドのレンジヘッダに、前記分割ファイルデータの元となるファイルにおけるデータ範囲、及び前記元となるファイルの総サイズの少なくとも一方を格納する格納手段を備える
ことを特徴とする請求項１２記載の送信機器。
【請求項１４】
ネットワークを介して、送信機器から送信されるファイルを受信する受信機器であって、
前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答手段と、
前記ファイルを構成するファイルデータを受信する受信手段と、
前記能力に応じて、前記ファイルデータを前記受信手段に受信させる受信制御手段とを備える
ことを特徴とする受信機器。
【請求項１５】
前記能力返答手段は、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する能力に関して返答する
ことを特徴とする請求項１４記載の受信機器。
【請求項１６】
前記受信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記送信機器から送信される前記ファイルデータを受信する
ことを特徴とする請求項１４記載の受信機器。
【請求項１７】
ネットワークを介して受信機器に対してファイルを送信する送信方法であって、
前記受信機器のファイル転送の能力を確認する能力確認ステップと、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと、
前記ファイル転送の能力に応じて、前記ファイルデータを前記送信ステップにおいて送信させる送信制御ステップとを含む
ことを特徴とする送信方法。
【請求項１８】
ネットワークを介して、送信機器から送信されるファイルを受信する受信方法であって、
前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答ステップと、
前記ファイルを構成するファイルデータを受信する受信ステップと、
前記能力に応じて、前記ファイルデータを前記受信ステップにおいて受信させる受信制御ステップとを含む
ことを特徴とする受信方法。
【請求項１９】
ネットワークを介して受信機器に対してファイルを送信する送信機器に用いるプログラムであって、
前記受信機器のファイル転送の能力を確認する能力確認ステップと、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと、
前記ファイル転送の能力に応じて、前記ファイルデータを前記送信ステップにおいて送信させる送信制御ステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項２０】
ネットワークを介して、送信機器から送信されるファイルを受信する受信機器に用いるプログラムであって、
前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答ステップと、
前記ファイルを構成するファイルデータを受信する受信ステップと、
前記能力に応じて、前記ファイルデータを前記受信ステップにおいて受信させる受信制御ステップと
をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、ネットワークを介してファイル転送を行うためのファイル転送システム、送信機器及び受信装置に関し、特に、ファイルに付随する情報（メタデータ）の管理を行いファイル転送を行うファイル転送システム、送信機器及び受信装置に関する。
【背景技術】
【０００２】  近年、ｘＤＳＬや光ファイバーなどのブロードバンド環境が整ったことにより、企業、一般家庭を問わずインターネット接続が急速に普及してきている。また、家庭内のＰＣや家電機器をＥｔｈｅｒｎｅｔ（登録商標）や無線ＬＡＮなどで接続するホームネットワーク環境も一般化してきている。この様な中で、パーソナルコンピュータ（ＰＣ）だけでなく、テレビやＤＶＤレコーダ、エアコン、冷蔵庫のような家電もＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）により定義されるＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）により相互に接続できるようになってきている。【０００３】  インターネットやホームネットワークにおけるアプリケーションの１つとして、家電機器、ＰＣ間でファイルを転送するアプリケーションがある。例えば、ＤＶＤレコーダに録画したＴＶ番組をＰＣに転送して編集を行ったり、ＤＶＤレコーダ間で録画したＭＰＥＧ２ファイルを転送することによりダビング機能を提供する例などがある。【０００４】  この様なファイル転送を行うプロトコルでは一般的に、ファイルの転送が誤り無く行われることが要求され、その一方リアルタイムの転送は必ずしも要求されない。ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）においてファイル転送を行う代表的なプロトコルとしては、ＲＦＣ２６１６で定義されるＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）や、ＲＦＣ９５９で定義されるＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）等が存在する。これらのプロトコルはいずれもＲＦＣ７９３で定義されるＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）プロトコルの再送機能によって転送の信頼性を確保している。【０００５】  すなわち、ＴＣＰはパケットのエラーを検出して再送する手順と、欠落したパケットを検出して再送する手順を含んでおり、そのために伝送路上でエラーやパケット欠落が起こっても正しいファイルの転送が保障できる。一方でＴＣＰの再送手順には限界もあり、例えば伝送路の障害や、送信元の機器（以下ではソース機器と呼ぶ）や、受信先の機器（以下ではシンク機器と呼ぶ）の都合により転送の中断が長時間に渡った場合、ＴＣＰ接続がタイムアウトにより切断されてしまい、それ以後のファイル転送が行えなくなるという課題が存在する。ここでの機器都合には障害のほか、機器の他の機能を実行するためにファイル転送を中断せざるを得ない場合、例えば、ＤＶＤレコーダがタイマー録画を実行するためにファイル転送を中断する例などが挙げられる。【０００６】  ＨＴＴＰには前記課題を解決するための手順が既に含まれており、転送の中断が任意の長時間に渡った場合でも、再度ＴＣＰ接続を行って、中断前に転送した位置の直後からファイル転送を再開できるシーケンスが定義されている。本シーケンスを図１に従って説明する。【０００７】  図１は、従来のソース機器及びシンク機器により構成されるファイル転送システムにおけるファイル転送の再開に係る通信シーケンスの一例を示す図である。なお、図１は、シンク機器１００２からの「ＨＴＴＰ  ＧＥＴリクエスト」の要求に基づいて、ソース機器１００１からシンク機器１���０２にファイル転送を行うものである。【０００８】  本手順では、最初に、シンク機器１００２はソース機器１００１に対し、「ＨＴＴＰ  ＧＥＴリクエスト」を発行する（Ｓ１０１）。次に、ソース機器１００１は本リクエストに対し、「２００  ＯＫ」を応答し（Ｓ１０２）、１０００バイトのファイルの送信を開始する（Ｓ１０３）。本図においては、ここで通信障害が発生し（Ｓ１０４）、ＴＣＰ接続が切断され、それまでにシンク機器１００２には５００バイトのデータが保存できていたとする（Ｓ１０５）。この場合、シンク機器１００２は、通信障害が回復するのを待ち、任意の時点でＴＣＰの再接続を行い、転送を再開することができる。転送の再開はシンク機器１００２がソース機器１００１に対し、Ｒａｎｇｅヘッダを追加した「ＨＴＴＰ  ＧＥＴリクエスト」により、５００バイト以降目の部分のファイルを要求することにより行われる（Ｓ１０６）。【０００９】  そして、ソース機器１００１は、シンク機器１００２から指定されたＲａｎｇｅ（ここでは５００−９９９バイト目）に従ってファイルを送信し（Ｓ１０７及びＳ１０８）、シンク機器１００２がこれを保存することで（Ｓ１０９）、転送済みのデータを再送することなく、未転送のデータのみを転送の再開によって取得することが可能である。このように、本図に示すファイル転送システムにおいては、ファイル転送を再開するブロックをシンク機器１００２側が記憶しておくことで、不足データ部分を確実に配信することが可能となる。そして、この様な手順が、例えばインターネット上のサーバに配置される数メガバイト以上もの大きなファイルのダウンロードが失敗した際に、続きから取得することで効率よくファイルを取得するアプリケーションなどで使用されている。【００１０】  また、このようなＨＴＴＰのＧＥＴメソッドを利用し、データの提供を行う技術についても開示されている（例えば、特許文献１参照）。
【特許文献１】特開２００２−２８８１６２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】  しかしながら、この様な従来のファイル転送システムにおけるＨＴＴＰの中断、再開手順は、クライアント手動等で受信機器側からファイル転送を要求するＨＴＴＰのＧＥＴメソッドには使用できる一方、ＨＴＴＰのＰＯＳＴメソッドは使用できないという問題がある。【００１２】  そして、インターネット上のサーバからＰＣにファイルをダウンロードする場合はＨＴＴＰのＧＥＴメソッドが使用されるためこの様な制約は問題にはならないが、ネットワークに接続される任意の機器間でファイルを転送する場合において、ソース機器（例えば宅内のＤＶＤレコーダ）が任意のファイルを自発的にシンク機器（例えば宅内のＰＣ）に送りつけようとする場合においては通常ＨＴＴＰのＰＯＳＴメソッドが用いられるため、この様な場合にはファイル転送の中断、再開を行うことができないという課題がある。【００１３】  この課題は、より一般的にいうと、従来の送信機器側から受信機器側にデータを送りつけることをトリガとしてプッシュ型のフロー制御を行うファイル転送プロトコルにおいては、受信機器側から送信機器側にリクエストを発行するプル型のフロー制御と異なり、送信機器側からの受信機器側のファイル転送能力の確認の手順や、ファイル転送の中断、再開を行う手順が存在しないことに起因している。【００１４】  また、ＨＴＴＰのＰＯＳＴメソッド等を用いて送信機器から受信機器に自発的にデータを送りつけるファイル転送プロトコルにおいては、送信機器から受信機器のファイル転送の再開・中断等の能力を確認する手順も存在していない。【００１５】  本発明は、上記課題を考慮し、ＨＴＴＰのＰＯＳＴメソッド等を用いて送信機器側から受信機器側に自発的にデータを送りつけるプッシュ型のフロー制御を行うファイル転送プロトコルにおいても、送信機器が受信機器のファイル転送の中断・再開能力の確認ができ、また、ソース機器、シンク機器の都合や、ＴＣＰ接続のタイムアウトなどでネットワーク切断された場合にも、効率的に残りのファイル転送の再開を可能にするファイル転送システム、送信機器及び受信装置を提供することを目的とする。
【課題を解決するための手段】
【００１６】  上記目的を達成するために、本発明に係るファイル転送システムは、ネットワークを介して、ファイルを送信する送信機器と、ファイルを受信する受信機器との間でファイルを転送するファイル転送システムであって、前記送信機器は、前記受信機器のファイル転送の能力を確認する能力確認手段と、前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、前記ファイル転送の能力に応じて、前記ファイルデータを前記送信手段に送信させる送信制御手段とを備え、前記受信機器は、前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答手段と、前記ファイルを構成するファイルデータを受信する受信手段と、前記能力に応じて、前記ファイルデータを前記受信手段に受信させる受信制御手段とを備えることを特徴とする。【００１７】  また、前記能力返答手段は、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）のＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する能力に関して返答し、前記能力確認手段は、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する前記受信機器の能力確認を行うことで、前記受信機器のファイル転送の能力を確認することを特徴とする。【００１８】  また、前記送信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記ファイルデータを前記受信機器に送信し、前記受信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記送信機器から送信される前記ファイルデータを受信することを特徴とする。【００１９】  これらの構成により、本発明に係るファイル転送システムにおいては、ＨＴＴＰのＰＯＳＴメソッド等を用いて送信機器から受信機器に自発的にデータを送りつけるファイル転送プロトコルにおいても、返信機器の能力確認手段において受信機器のＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する能力を確認することにより、受信機器のファイル転送に関する能力を確認でき、送信制御手段で受信機器のファイル転送の能力に合わせてファイルデータの送信を制御することが可能となる。【００２０】  また、本発明に係るファイル転送システムにおいて、前記送信機器は、さらに、前記受信機器でのファイル転送に関する情報を取得するための情報取得コマンドを生成するコマンド生成手段を備え、前記送信手段は、前記情報取得コマンドを前記受信機器に送信し、前記受信機器は、さらに、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドのレンジヘッダに、受信した前記ファイルデータの元となる前記ファイルの総サイズ及び前記ファイルデータの実転送完了サイズを記録する記録手段を備え、前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、前記記録手段において記録された情報を返答することを特徴とする。【００２１】  さらに、前記記録手段は、さらに、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドにおいてファイル転送状況を記録し、前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、記録された前記ファイル転送状況を返答することを特徴とする。【００２２】  これらの構成によ���、本発明に係るファイル転送システムにおいては、送信機器から受信機器に対して情報取得コマンドを送信して受信機器側でのファイルデータの実転送完了サイズやファイル転送状況といったファイル転送に関する情報を取得することができるため、ＨＴＴＰのＰＯＳＴメソッドによるプッシュ型のフロー制御を行うファイル転送プロトコルを用いる場合にも、送信機器側から受信機器側のファイル転送の中断・再開能力の確認、未転送のデータのみを転送する等、より効率的なファイル転送の再開を可能とする。【００２３】  さらに、本発明の送信機器及び受信機器それぞれの特徴的な構成部をステップとする送信方法及び受信方法として実現したり、コンピュータに各ステップを実行させるためのプログラムとして実現することもできる。そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を通じて配信することができるのは言うまでもない。
【発明の効果】
【００２４】  本発明に係るファイル転送システムによれば、特にＨＴＴＰのＰＯＳＴメソッドによるプッシュ型のフロー制御を行うファイル転送プロトコルを用いる場合にも、送信機器側から受信機器側のファイル転送の中断・再開能力の確認ができ、また、未転送のデータのみを転送する効率的なファイル転送の再開を可能とする。
【図面の簡単な説明】
【００２５】
【図１】図１は、従来例に係るファイル転送システムの通信シーケンス図である。
【図２】図２は、本発明の第１の実施例に係るファイル転送システムの通信シーケンス図である。
【図３】図３は、ＣｒｅａｔｅＯｂｊｅｃｔアクションリクエスト時に入力される通常のメタデータ情報の参考図である。
【図４】図４は、本発明の第１の実施例に係るＣｒｅａｔｅＯｂｊｅｃｔアクションリクエスト時に入力されるメタデータ情報の参考図である。
【図５】図５は、本発明の第１の実施例に係るシンク機器において生成されるメタデータ情報の参考図である。
【図６】図６は、本発明の第１の実施例に係るシンク機器において生成されるメタデータ情報の参考図である。
【図７】図７は、本発明に係るソース機器の機能ブロック図である。
【図８】図８は、本発明に係るシンク機器の機能ブロック図である。
【図９】図９は、本発明の第２の実施例に係るファイル転送の中断シーケンス図である。
【図１０】図１０は、本発明の第３の実施例に係るファイル転送の中断シーケンス図である。
【図１１】図１１は、本発明の第３の実施例に係るファイル転送の中断シーケンス図である。
【図１２】図１２は、本発明の第３の実施例に係るファイル転送の中断シーケンス図である。
【図１３】図１３は、本発明の第２の実施例に係るシンク機器において管理されるメタデータ情報の参考図である。
【図１４】図１４は、本発明の第３の実施例に係るシンク機器において管理されるメタデータ情報の参考図である。
【符号の説明】
【００２６】  １０１  ソース機器
１０２  シンク機器
３００，４００，５００，６００，１３００，１４００  メタデータ情報
７０１  ユーザインタフェース
７０２  ファイル送信制御部
７０３  ファイル制御部
７０４  通信制御部
７０５  ファイル蓄積部
７０６  ネットワークインタフェース
７０７  転送するファイル
７０８  ファイルの付随情報（メタデータ）
８０１  ファイル受信制御部
８０２  ファイル制御部
８０３  通信制御部
８０４  ファイル蓄積部
８０５  ネットワークインタフェース
８０６  転送されたファイル
８０７  転送されたファイルの付随情報（メタデータ）
【発明を実施するための最良の形態】
【００２７】  以下、本発明を実施するための最良の形態について図面を用いて説明する。
（実施の形態１）
以下で、本発明に係るファイル転送システムの第１の実施例について、図面を参照しながら説明する。【００２８】  図２において送信機器としてのソース機器１０１と受信機器としてのシンク機器１０２は各々蓄積メディアを内蔵し、ファイルを蓄積することができる。この様な機器の例としてネットワーク接続端子を備えたＤＶＤ／ＨＤＤハイブリッドレコーダなどが上げられる。本実施例の初期状態ではソース機器１０１が転送したいファイルを蓄積しており、ネットワークを介してシンク機器１０２に転送して蓄積するものとする。なお、シンク機器１０２、ソース機器１０１ともにユニバーサルプラグアンドプレイフォーラムの発行するＵＰｎＰ−ＡＶ規格に準拠しており、シンク機器１０２はＣＤＳ（Ｃｏｎｔｅｎｔｓ  Ｄｉｒｅｃｔｏｒｙ  Ｓｅｒｖｉｃｅ）サーバ機能を実装しており、ソース機器１０１はＣＤＳサーバにアクセスするＣｏｎｔｒｏｌ  Ｐｏｉｎｔ機能を実装しているものとする。【００２９】  ソース機器１０１の詳細構成を別の図を用いて説明する。図７、図８はそれぞれソース機器１０１とシンク機器１０２の機能ブロック図である。【００３０】  図７において、ソース機器１０１は、ユーザインタフェース７０１、ファイル送信制御部７０２、ファイル蓄積部７０５からのファイル読出し制御を実行するファイル制御部７０３、ネットワークインタフェース７０６を制御してネットワークを介した通信制御を実行する通信制御部７０４、実体ファイル７０７と共に、実体ファイルの付随情報（メタデータ）であるファイルｏｂｊｅｃｔ７０８が格納されているファイル蓄積部７０５、及びネットワークインターフェース７０６を備えるものである。【００３１】  また、ソース機器１０１は、ユーザインタフェース部７０１を制御してファイル蓄積部７０５に蓄積したファイルの一覧リストを表示する。ユーザが一覧リストの中から選択したファイルを、ファイル蓄積部７０５から読出し、ネットワークインタフェース７０６を制御して、シンク機器１０２に送付する。【００３２】  図８において、シンク機器１０２は、ファイル受信制御部８０１、ファイル蓄積部８０４に対するファイル書込み制御を実行するファイル制御部８０２、ネットワークインタフェース８０５を制御してネットワークを介した通信制御を実行する通信制御部８０３、ソース側からのファイル転送完了後に、実体ファイル８０６及びファイル付随情報（メタデータ）８０７が生成及び蓄積するファイル蓄積部８０４、及びネットワークインターフェース８０５を備えるものである。【００３３】  以上のような構成において、図４に示すように、ソース機器１０１は実体ファイル７０７の転送に先立って、シンク機器１０２に対しＵＰｎＰ−ＡＶ規格で規定されるＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションリクエストを発行する（Ｓ２０３）。【００３４】  このＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションリクエストには、ファイルの付随情報（メタデータ）であるファイルｏｂｊｅｃｔ７０８から生成されたファイルｏｂｊｅｃｔ８０７が記述されており、本実施の形態１におけるファイルｏｂｊｅｃｔ８０７は、図４に示すようなＸＭＬデータ形式であり、シンク機器１０２がファイル転送の再開・中断���可能かどうかを確認する際に、Ｓ２０３のＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションリクエスト時にインプットされるメタデータ情報４００を示し、図３に示す従来のＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションリクエスト時にインプットされる通常のメタデータ情報３００に加え、本実施例においては、シンク側におけるファイル転送中断・再開能力を尋ねるための情報（４０１及び４０２）が加えられている。【００３５】  図４では「ｅｘｔ：ＰＯＳＴＲｅｑｕｅｓｔ＝“１”（４０２）」と記載しているが、これら文字列及び数値を本実施例において特定するものではない。ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションリクエストを受信したシンク機器１０２では、ファイルｏｂｊｅｃｔ８０７をファイル蓄積部８０４に格納した上で、ディレクトリの位置や、ファイル名等のメタデータをファイルｏｂｊｅｃｔ８０７に追記する。この際のメタデータには特にファイル実体を保存すべきシンク機器１０２上のＵＲＬが含まれており、追記されたファイルｏｂｊｅｃｔ８０７はＳ１０４に示すＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションレスポンスによりソース機器１０１に通知される。【００３６】  また、本実施例においては、図５のソース機器１０１からのファイル転送の再開・中断確認要求に対するＯＫの場合のＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションレスポンスにインプットするメタデータ情報５００に示すように、シンク機器１０２におけるファイル転送中断・再開能力を通知するための情報として、「ｅｘｔ：ＰＯＳＴＲｅｑｕｅｓｔ＝“１”（５０１）」が記されている。シンク機器１０２においてファイル転送中断・再開能力がない場合は、図６のメタデータ情報６００に示すように「ｅｘｔ：ＰＯＳＴＲｅｑｕｅｓｔ＝“１”」を記さないようにするか、「ｅｘｔ：ＰＯＳＴＲｅｑｕｅｓｔ＝“０”」と返答する（Ｓ２０４）。【００３７】  そして、シンク機器１０２からＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションレスポンスを受信したソース機器１０１は、ファイル転送の再開・中断が可能と判断した上で、ファイルを分割転送するサイズを決定する。分割転送のサイズは転送の中断、再開の頻度、中断時に無駄になる転送サイズ、分割によるオーバヘッド等を勘案して任意に決定することができる。ここでは１０００Ｂｙｔｅのファイルを、最初の０−４９９ｂｙｔｅ、次の５００−９９９Ｂｙｔｅに分割して送信するものとし、ソース機器はＨＴＴＰのＰＯＳＴメソッドを送信する（Ｓ２０５）。【００３８】  また、ＰＯＳＴメソッドには本発明で独自に定義したヘッダである、Ｕｐｌｏａｄ  Ｒａｎｇｅ：［ｂｙｔｅ−ＲａｎｇｅＴｏｔａｌ  ｓｉｚｅ］が含まれる。ここでの「ｂｙｔｅ−Ｒａｎｇｅ」は、続くＨＴＴＰのＥｎｔｉｔｙ  Ｂｏｄｙ部に含まれるデータの範囲を示し、「ｔｏｔａｌ  ｓｉｚｅ」ではＨＴＴＰのＰＯＳＴメソッドにおいて最終的に転送するファイルの総サイズ１０００ｂｙｔｅを示す。Ｓ２０５では最初の分割転送単位である、０−４９９ｂｙｔｅが指定される。ＰＯＳＴメソッドで指定するＵＲＬには、ＣｒｅａｔｅＯｂｊｅｃｔアクションレスポンスに記述されるファイルＯｂｊｅｃｔ８０７に含まれるＵＲＬを記述する。これにより、シンク機器１０２は特定のファイルＯｂｊｅｃｔと、受信したファイルの実体を対応させることができる。さらに、Ｓ２０５においてはヘッダとしてさらに、Ｅｘｐｅｃｔ：１００−ｃｏｎｔｉｎｕｅが記述されているため、シンク機器はＲＦＣ２６１６に従って、Ｓ２０５におけるＰＯＳＴリクエストをそのＵＲＬで受け入れることができるかのチェックを行い、可能であれば１００  Ｃｏｎｔｉｎｕｅレスポンスを返す（Ｓ２０６）。この動作により、Ｓ２０５のＰＯＳＴリクエストを受け入れたり、解釈することができない場合にはデータの転送の前にソース機器に通知することができ、無駄なデータ送信を回避することができる。【００３９】  そして、ソース機器１０１は、ＨＴＴＰのＰＯＳＴのＥｎｔｉｔｙ  Ｂｏｄｙ送信を開始する（Ｓ２０７）。「Ｅｎｔｉｔｙ  Ｂｏｄｙ」に含まれるファイルの範囲は、０−４９９ｂｙｔｅ範囲のみである。シンク機器１０２はこの５００ｂｙｔｅ分を受信すると内蔵するファイル蓄積部８０７へ保存を行う（Ｓ２０８）。【００４０】  次に、本実施の形態においては、Ｓ２０４において受信した「ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションレスポンス」に基づきソース機器１０１は、シンク機器１０２がファイル転送の再開・中断が可能と判断したために、ソース機器１０１は、次の５００−９９９Ｂｙｔｅに分割して送信するためのＨＴＴＰのＰＯＳＴメソッドを送信する（Ｓ２０９）。なお、このＰＯＳＴメソッドのＵｐｌｏａｄ  Ｒａｎｇｅ：［ｂｙｔｅ−ＲａｎｇｅＴｏｔａｌ  ｓｉｚｅ］に含まれる「ｂｙｔｅ−Ｒａｎｇｅ」には、最後の分割転送単位である、５００−９９９ｂｙｔｅが指定され、「ｔｏｔａｌ  ｓｉｚｅ」ではＨＴＴＰのＰＯＳＴメソッドにおいて最終的に転送するファイルの総サイズ１０００ｂｙｔｅを示す。【００４１】  また、ＰＯＳＴメソッドで指定するＵＲＬには、「ＣｒｅａｔｅＯｂｊｅｃｔアクションレスポンス」に記述されるファイルＯｂｊｅｃｔ８０７に含まれるＵＲＬを記述され、また、Ｓ２０９においてはヘッダとしてさらに、「Ｅｘｐｅｃｔ：１００−ｃｏｎｔｉｎｕｅ」が記述されているため、シンク機器はＲＦＣ２６１６に従って、Ｓ２０９におけるＰＯＳＴリクエストをそのＵＲＬで受け入れることができるかのチェックを行い、可能であれば「１００  Ｃｏｎｔｉｎｕｅレスポンス」を返す（Ｓ２１０）。【００４２】  そして、ソース機器１０１は、ＨＴＴＰのＰＯＳＴのＥｎｔｉｔｙ  Ｂｏｄｙ送信を開始する（Ｓ２１１）。「Ｅｎｔｉｔｙ  Ｂｏｄｙ」に含まれるファイルの範囲は、５００−９９９ｂｙｔｅ範囲のみである。シンク機器１０２はこの５００ｂｙｔｅ分を受信すると内蔵するファイル蓄積部８０７へ保存を行い、一連のファイル転送の処理を終了する（Ｓ２１２）。【００４３】  このように、本実施の形態１に係るファイル転送システムにおいては、ＨＴＴＰのＰＯＳＴメソッドを用いてファイルを送りつけるプッシュ型のフロー制御でもファイルを分割して送信を行うことが可能になる。なお、ＨＴＴＰで当然使用されるその他のヘッダについては本発明の動作に関係しないので記載を省略する。また、ここで定義したヘッダ名は別のヘッダ名でもかまわない。【００４４】  以上のように、本実施の形態１に係るファイル転送システムにおいては、ＨＴＴＰのＰＯＳＴメソッド等を用いてソース機器１０１からシンク機器１０２に自発的にデータを送りつけるファイル転送プロトコルを用いる場合においても、ファイルに付随するメタデータ情報に新たなファイル転送のための情報を付加することにより、ソース機器１０１が自発的にシンク機器１０２のファイル転送能力の確認を行うことが可能となる。【００４５】  このため、ソース機器１０１は、シンク機器１０２がファイル転送の中断・再開が不可能であれば、中断・再開を許容しない通常のプッシュ型のファイル転送を実行するシーケンスへ移行させ、シンク機器１０２が中断・再開が可能であれば、中断・再開を許容するプッシュ型のファイル転送を実行するシーケンスへ移行させることができ、この場合には、ファイルを任意のサイズに分割して分割ファイルの転送を行うことができる。【００４６】  また、ＨＴＴＰのＰＯＳＴメソッドを用い、ファイル送信を行うソース機器１０１でファイルを分割し、拡張されたヘッダにより転送範囲を明示して送信できるため、シンク機器１０２がファイル転送の再開が可能であると確認できる場合には、分割したファイル転送の中断・再開が可能となる。【００４７】（実施の形態２）
以下で、本発明に係るファイル転送システムの第２の実施例について、図面を参照しながら説明する。なお、本実施の形態２に係るファイル転送システムは、ファイル転送の途中でソース機器側の都合によりファイル転送を中断する場合において、ソース機器からシンク機器に対してＣＤＳ：Ｂｒｏｗｓｅリクエストを送信することを特徴とするものである。また、本実施の形態２に係るソース機器及びシンク機器の内部構成そのものは、実施の形態１の図７、図８で説明した通りであり、また、ソース機器とシンク機器間において任意のサイズでのファイル転送を行うまでの手順も実施の形態１の図２で説明した通りであるために、これらの詳細な説明を省略する。【００４８】  図９は、本実施の形態２に係るファイル転送システムにおいて、何らかの事情によりＰＯＳＴメソッドによるファイル転送が中断した状態からの再開シーケンスを説明する。なお、図９におけるＳ２０１からＳ２０８までの処理は、上述した実施の形態１の図２で説明したものと同じである。【００４９】  この状態において、何らかの事情によりＰＯＳＴメソッドによるファイル転送が中断した場合、ソース機器１０１は、再開すべきファイルサイズを特定するために、ＣＤＳ：Ｂｒｏｗｓｅアクションリクエストをシンク機器１０２に対して送信し（Ｓ９０１）、ＣＤＳ：Ｂｒｏｗｓｅアクションレスポンスによってシンク機器が保有しているファイルｏｂｊｃｅｔ８０７を取得する（Ｓ９０２）。なお、上記の何らかの理由とは、例えばソース機器としてのＤＶＤレコーダを用いて転送途中に、このＤＶＤレコーダを介してテレビを視聴し始めてファイル転送が中断されたような場合である。【００５０】  そして、ソース機器１０１は、ファイルＯｂｊｅｃｔ８０７に記述されている「ｅｘｔ：ＰＯＳＴｅｄＳｉｚｅ＝“４９９／１０００”」を取得することで、シンク機器１０２がファイル転送中断前までに取得したファイルサイズ（本実施の形態２においては４９９ｂｙｔｅ）を特定することができる。なお、以後の残りとなる５００−９９９Ｂｙｔｅのファイル転送の再開の処理は、図２の説明におけるＳ２０９からＳ２１２と同じとなる。【００５１】  そして、本発明の第２の実施例においては、図２のＳ２０５に示すＰＯＳＴメソッドを受信したシンク機器１０２は、ネットワークインタフェース８０５を介して通信制御部８０３がパケットを受け取り、ファイル受信制御部８０１はＰＯＳＴメソッドで受け取るサイズを“Ｕｐｌｏａｄ  Ｒａｎｇｅ：［ｂｙｔｅ−Ｒａｎｇｅ  Ｔｏｔａｌ  ｓｉｚｅ］”の「ｂｙｔｅ−Ｒａｎｇｅ」から読み取り、更に最終的に受け取る総サイズを読み取り、ファイル制御部８０２を通じて一旦メモリ上に保持しておく。【００５２】  そして、図９のＳ２０７において実際のデータ転送が完了し次第、ファイル蓄積部８０４に格納されているファイルｏｂｊｅｃｔ８０７に追記する。追記された状態のファイルｏｂｊｅｃｔ８０７の詳細を図１３にて説明する。図１３は、シンク機器１０２側で管理されているメタデータ情報１３００を示し、図９のＳ２０４のＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションリクエスト受信時に生成された図５に示すファイルＯｂｊｅｃｔに比べ、図１３のファイ��Ｏｂｊｅｃｔでは、「ｅｘｔ：ＰＯＳＴｅｄＳｉｚｅ＝“４９９／１０００”（１３０１）」が追記されている。ここで示している“４９９”は、ＰＯＳＴメソッドでの実転送サイズであり、“１０００”は総サイズ数を示す。【００５３】  この処理を繰り返し、実転送サイズ＝総サイズになった時点でＰＯＳＴメソッドにおけるファイル転送が完了したと見なす。【００５４】  以上のように、本実施の形態２に係るファイル転送システムにおいては、ＨＴＴＰのＰＯＳＴメソッドによるファイル転送時において、ソース機器側の何らかの都合により中断した残りのファイル転送を、正確に継続して再開することが可能となる。【００５５】（実施の形態３）
以下、本発明に係るファイル転送システムの第３の実施例について、図面を参照しながら説明する。なお、本実施の形態３に係るファイル転送システムは、ＰＯＳＴメソッドによるファイル転送時において、ファイル転送の中断理由に応じて、その後のファイル転送を管理することを特徴とするものである。また、本実施の形態３におけるソース機器及びシンク機器の内部構成そのものは、第１の実施例の図７、図８で説明した通りであり、また、ソース機器とシンク機器間において任意のサイズでのファイル転送を行うまでの手順も実施の形態１の図２で説明した通りである。【００５６】  本発明の第３の実施例においては、中断理由により再開動作が異なる場合について特徴を述べている。ＰＯＳＴメソッドによるファイル転送が開始されるシーケンスは図１の通りであるが、シンク機器１０２において最初のＰＯＳＴメソッドをネットワークインタフェース８０５を介して通信制御部８０３がパケットを受け取ると、ファイル受信制御部８０１はファイル蓄積部８０４に格納されているファイルｏｂｊｅｃｔ  ８０７に「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ＝“ｕｐｌｏａｄｉｎｇ”」を追記する。追記された状態のファイルｏｂｊｅｃｔ  ８０７の詳細は、図１４にて説明する。【００５７】  この図１４は、シンク機器１０２側で管理されているメタデータ情報１４００を示し、図２のＳ２０４におけるＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションリクエスト受信時に生成された図５に示すファイルＯｂｊｅｃｔに比べ、図１３で説明した「ｅｘｔ：ｐｏｓｔｅｄＳｉｚｅ＝“４９９／１０００”（１３０１）」の他に、「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ＝“ｕｐｌｏａｄｉｎｇ”（１４０１）」が追記されている。この「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ」には、シンク機器におけるファイル転送状態を記述しており、ファイル転送が完了すると同時に、「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ」そのものを削除する。【００５８】  図１０ではソース機器１０１のユーザ又はプロセッサ処理の判断においてＰＯＳＴメソッドにおけるファイル転送を中断した場合のシーケンスを説明する。【００５９】  ソース機器１０１からファイル転送を中断する場合には、ソース機器１０１は、ヘッダにＵｐｌｏａｄ  Ｃｏｎｔｒｏｌ：ｓｕｓｐｅｎｄを付与したＰＯＳＴメソッドを送信することでシンク機器１０２に中断通知を行う（Ｓ１００１）。シンク機器１０２においては、ネットワークインタフェース８０５を介して通信制御部８０３がパケットを受け取り、ファイル受信制御部８０１はＰＯＳＴメソッドで受け取るサイズを“Ｕｐｌｏａｄ  Ｃｏｎｔｒｏｌ：ｓｕｓｐｅｎｄ”を読み取り、ファイル蓄積部８０４に格納されているファイルｏｂｊｅｃｔ  ８０７の内容において、「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ＝“ｓｕｓｐｅｎｄｅｄ”」に修正する（Ｓ１００２）。次に、シンク機器１０２は、ソース機器１０１側に「２００  ＯＫ」の返信を行う（Ｓ１００３）。【００６０】  そして、シンク機器１０２のファイル受信制御部８０１は、定期的又は一定の判断基準に基づいてｅｘｔ：ｐｏｓｔＳｔａｔｕｓの値をチェックし、“ｓｕｓｐｅｎｄｅｄ”であった場合はソース側の理由により故意にファイル転送が中断されてい��と判断し、ファイル８０６及びファイルＯｂｊｅｃｔ８０７を削除しないなどの処理を行うことが可能となる。また、シンク機器１０２におけるユーザインタフェースにファイルの状態を出力した上で、ユーザにファイル操作させることも可能である。【００６１】  図１１では、ネットワーク障害によりファイル転送を中断した場合のシーケンスを説明する。なお、Ｓ２０３からＳ２０８までの処理は図２で説明した通りである。【００６２】  ここでネットワーク障害が発生し（Ｓ１１０１）、ＰＯＳＴメソッドによるファイル転送は中断され、ある一定時間にシンク機器１０２においてファイル受信が行われない場合は、ファイル受信制御部８０１がファイル蓄積部８０４に格納されているファイルｏｂｊｅｃｔ  ８０７の内容において、「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ＝“ｄｉｓｃｏｎｎｅｃｔｅｄ”」に修正する。【００６３】  そして、シンク機器１０２のファイル受信制御部８０１は、定期的又は一定の判断基準に基づいてｅｘｔ：ｐｏｓｔＳｔａｔｕｓの値をチェックし、“ｄｉｓｃｏｎｎｅｃｔｅｄ”であった場合は、ネットワーク障害によるファイル転送切断であると解釈し、ファイル蓄積部８０５に蓄積されているファイル８０６及びファイルＯｂｊｅｃｔ８０７を削除するなどの処理を行うことが可能となる。また、シンク機器１０２におけるユーザインタフェースにファイルの状態を出力した上で、ユーザにファイル操作させることも可能である。【００６４】  図１２では、シンク機器１０２の都合によりファイル転送を中断した場合のシーケンスを説明する。Ｓ２０３からＳ２０８までの処理は図１で説明した通りである。【００６５】  ここで、ＰＯＳＴメソッドにおけるファイル転送要求に対して（Ｓ１２０１）、シンク機器１０２側において、例えばディスク容量オーバーなどの理由でファイル転送を中断したい場合には、ソース機器１０１側に「５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ」を返信し（Ｓ１２０２）、シンク機器１０２のファイル受信制御部８０１がファイル蓄積部８０４に格納されているファイルｏｂｊｅｃｔ  ８０７の内容において、「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ＝“ｄｉｓｋ  ｆｕｌｌ”」に修正する（Ｓ１２０３）。【００６６】  そして、シンク機器１０２のファイル受信制御部８０１は、定期的又は一定の判断基準に基づいてｅｘｔ：ｐｏｓｔＳｔａｔｕｓの値をチェックし、“ｄｉｓｋ  ｆｕｌｌ”であった場合は、シンク機器１０２のディスク容量オーバとしてファイル蓄積不可によるファイル転送切断であると解釈し、時にはファイル８０６及びファイルＯｂｊｅｃｔ８０７を削除するなどの処理を行う。またシンク機器１０２におけるユーザインタフェースにファイルの状態を出力した上で、ユーザにファイル操作させることも可能である。【００６７】  以上のように、本実施の形態３に係るファイル転送システムにおいては、ＰＯＳＴメソッドによるファイル転送時において、ソース機器１０１が任意のタイミングでファイル転送を中断・再開できるほか、シンク機器１０２が任意のタイミングでファイル転送を中断した際においても、ファイル転送の中断理由毎に、ファイル操作及び効率的なファイル転送の再開が可能となる。
【産業上の利用可能性】
【００６８】  本発明に係るファイル転送システムは、ＨＴＴＰのＰＯＳＴメソッド等を用いてネットワークに接続される任意の機器間でファイルを転送する場合において一般的に用いることができ、特にファイルのサイズが大きく、転送を中断して再開する際に、転送を初めからやり直すと無駄が多い場合に効果を発揮する。
【図１】
2006046445.tif 000002
【図２】
2006046445.tif 000003
【図３】
2006046445.tif 000004
【図４】
2006046445.tif 000005
【図５】
2006046445.tif 000006
【図６】
2006046445.tif 000007
【図７】
2006046445.tif 000008
【図８】
2006046445.tif 000009
【図９】
2006046445.tif 000010
【図１０】
2006046445.tif 000011
【図１１】
2006046445.tif 000012
【図１２】
2006046445.tif 000013
【図１３】
2006046445.tif 000014
【図１４】
2006046445.tif 000015
【手続補正書】
【提出日】平成18年3月20日(2006.3.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求の範囲
【補正方法】変更
【補正の内容】
【書類名】請求の範囲
【請求項１】（補正後）ネットワークを介して、ファイルを送信する送信機器と、ファイルを受信する受信機器との間でファイルを転送するファイル転送システムであって、
前記送信機器は、
前記受信機器のファイル転送の能力を確認する能力確認手段と、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の能力に応じて、前記ファイルデータを前記送信手段に送信させる送信制御手段とを備え、
前記受信機器は、
前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答手段と、
前記ファイルを構成するファイルデータを受信する受信手段と、
前記能力に応じて、前記ファイルデータを前記受信手段に受信させる受信制御手段とを備え、
前記能力確認手段において前記受信機器がファイル転送の中断・再開が可能であると確認される場合には、前記送信制御手段は、前記ファイル転送の中断・再開を許容するプッシュ型のファイル転送を実行するシーケンスへ移行させる一方、前記能力確認手段において前記受信機器がファイル転送の中断・再開が不可能であると確認される場合には、前記送信制御手段は、前記ファイル転送の中断・再開を許容しないプッシュ型のファイル転送を実行するシーケンスへ移行させる
ことを特徴とするファイル転送システム。
【請求項２】前記能力返答手段は、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）のＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する能力に関して返答し、
前記能力確認手段は、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する前記受信機器の能力確認を行うことで、前記受信機器のファイル転送の能力を確認する
ことを特徴とする請求項１記載のファイル転送システム。
【請求項３】前記送信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記ファイルデータを前記受信機器に送信し、
前記受信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記送信機器から送信される前記ファイルデータを受信する
ことを特徴とする請求項１記載のファイル転送システム。
【請求項４】（削除）
【請求項５】前記送信機器は、さらに、
前記受信機器でのファイル転送に関する情報を取得するための情報取得コマンドを生成するコマンド生成手段を備え、
前記送信手段は、前記情報取得コマンドを前記受信機器に送信し、
前記受信機器は、さらに、
ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドのレンジヘッダに、受信した前記ファイルデータの元となる前記ファイルの総サイズ及び前記ファイルデータの実転送完了サイズを記録する記録手段を備え、
前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、前記記録手段において記録された情報を返答する
ことを特徴とする請求項１記載のファイル転送システム。
【請求項６】前記記録手段は、さらに、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドにおいてファイル転送状況を記録し、
前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、記録された前記ファイル転送状況を返答する
ことを特徴とする請求項５記載のファイル転送システム。
【請求項７】前記ファイル転送状況は、アップロード中、送信機器側からのサスペンド要求による中断、ネットワーク切断による中断、又は受信機器側からのディスク容量オーバのいずれか１つであり、
前記受信機器は、さらに、
受信した前記ファイルを格納する格納手段を備え、
前記ファイル転送情報が、前記ネットワーク切断による中断である場合には、前記格納手段に格納され、前記中断前に受信したファイルデータは消去可能である
ことを特徴とする請求項６記載のファイル転送システム。
【請求項８】前記送信手段は、さらに、ＵＰｎＰ−ＡＶ規格で規定されるＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションリクエストとして、少なくとも前記ファイル転送の中断又は再開が可能かを確認する情報を含むメタデータ情報を前記受信機器に送信し、
前記受信手段は、さらに、前記メタデータ情報を受信し、
前記能力返答手段は、前記メタデータ情報に基づいて、ＵＰｎＰ−ＡＶ規格で規定されるＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔアクションレスポンスとして、前記送信機器に対して前記ファイル転送の中断又は再開が可能であるか否かの能力を返答し、
前記能力確認手段は、前記返答に基づいて、前記受信機器の前記ファイル転送の能力を確認する
ことを特徴とする請求項１記載のファイル転送システム。
【請求項９】（補正後）ネットワークを介して受信機器に対してファイルを送信する送信機器であって、
前記受信機器のファイル転送の能力を確認する能力確認手段と、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の能力に応じて、前記ファイルデータを前記送信手段に送信させる送信制御手段と、
前記受信機器に送信される前記ファイルを複数に分割する分割手段とを備え、
前記送信制御手段は、前記能力確認手段において前記受信機器がファイル転送の中断・再開が可能であると確認される場合において、前記ファイルを前記分割手段において分割された分割ファイルデータの単位で前記送信手段に送信させ、
前記送信手段は、前記分割ファイルデータを前記受信機器に送信する
ことを特徴とする送信機器。
【請求項１０】前記能力確認手段は、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する前記受信機器の能力確認を行うことで、前記受信機器のファイル転送の能力を確認する
ことを特徴とする請求項９記載の送信機器。
【請求項１１】前記送信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記ファイルデータを前記受信機器に送信する
ことを特徴とする請求項９記載の送信機器。
【請求項１２】（削除）
【請求項１３】前記送信機器は、さらに、
ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドのレンジヘッダに、前記分割ファイルデータの元となるファイルにおけるデータ範囲、及び前記元となるファイルの総サイズの少なくとも一方を格納する格納手段を備える
ことを特徴とする請求項１２記載の送信機器。
【請求項１４】ネットワークを介して、送信機器から送信されるファイルを受信する受信機器であって、
前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答手段と、
前記ファイルを構成するファイルデータを受信する受信手段と、
前記能力に応じて、前記ファイルデータを前記受信手段に受信させる受信制御手段とを備える
ことを特徴とする受信機器。
【請求項１５】前記能力返答手段は、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する能力に関して返答する
ことを特徴とする請求項１４記載の受信機器。
【請求項１６】前記受信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記送信機器から送信される前記ファイルデータを受信する
ことを特徴とする請求項１４記載の受信機器。
【請求項１７】（補正後）ネットワークを介して受信機器に対してファイルを送信する送信方法であって、
前記受信機器のファイル転送の能力を確認する能力確認ステップと、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと、
前記ファイル転送の能力に応じて、前記ファイルデータを前記送信ステップにおいて送信させる送信制御ステップと、
前記受信機器に送信される前記ファイルを複数に分割する分割ステップとを含み、
前記送信制御ステップにおいては、前記能力確認ステップにおいて前記受信機器がファイル転送の中断・再開が可能であると確認される場合において、前記ファイルを前記分割手段において分割された分割ファイルデータの単位で前記送信ステップにおいて送信させ、
前記送信ステップにおいては、前記分割ファイルデータを前記受信機器に送信する
ことを特徴とする送信方法。
【請求項１８】ネットワークを介して、送信機器から送信されるファイルを受信する受信方法であって、
前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答ステップと、
前記ファイルを構成するファイルデータを受信する受信ステップと、
前記能力に応じて、前記ファイルデータを前記受信ステップにおいて受信させる受信制御ステップとを含む
ことを特徴とする受信方法。
【請求項１９】（補正後）ネットワークを介して受信機器に対してファイルを送信する送信機器に用いるプログラムであって、
前記受信機器のファイル転送の能力を確認する能力確認ステップと、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと、
前記ファイル転送の能力に応じて、前記ファイルデータを前記送信ステップにおいて送信させる送信制御ステップと、
前記受信機器に送信される前記ファイルを複数に分割する分割ステップとを含み、
前記送信制御ステップにおいては、前記能力確認ステップにおいて前記受信機器がファイル転送の中断・再開が可能であると確認される場合において、前記ファイルを前記分割手段において分割された分割ファイルデータの単位で前記送信ステップにおいて送信させ、
前記送信ステップにおいては、前記分割ファイルデータを前記受信機器に送信する
ことをコンピュータに実行させるプログラム。
【請求項２０】ネットワークを介して、送信機器から送信されるファイルを受信する受信機器に用いるプログラムであって、
前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答ステップと、
前記ファイルを構成するファイルデータを受信する受信ステップと、
前記能力に応じて、前記ファイルデータを前記受信ステップにおいて受信させる受信制御ステップと
をコンピュータに実行させることを特徴とするプログラム。
２６
【手続補正書】
【提出日】平成19年3月7日(2007.3.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークを介して、ファイルを送信する送信機器と、ファイルを受信する受信機器との間でファイルを転送するファイル転送システムであって、
前記送信機器は、
前記受信機器のファイル転送の能力を確認する能力確認手段と、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の能力に応じて、前記ファイルデータを前記送信手段に送信させる送信制御手段とを備え、
前記受信機器は、
前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答手段と、
前記ファイルを構成するファイルデータを受信する受信手段と、
前記能力に応じて、前記ファイルデータを前記受信手段に受信させる受信制御手段とを備え、
前記能力確認手段において前記受信機器がファイル転送の中断・再開が可能であると確認される場合には、前記送信制御手段は、前記ファイル転送の中断・再開を許容するプッシュ型のファイル転送を実行するシーケンスへ移行させる一方、前記能力確認手段において前記受信機器がファイル転送の中断・再開が不可能であると確認される場合には、前記送信制御手段は、前記ファイル転送の中断・再開を許容しないプッシュ型のファイル転送を実行するシーケンスへ移行させる
ことを特徴とするファイル転送システム。
【請求項２】
前記能力返答手段は、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）のＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する能力に関して返答し、
前記能力確認手段は、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する前記受信機器の能力確認を行うことで、前記受信機器のファイル転送の能力を確認する
ことを特徴とする請求項１記載のファイル転送システム。
【請求項３】
前記送信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記ファイルデータを前記受信機器に送信し、
前記受信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記送信機器から送信される前記ファイルデータを受信する
ことを特徴とする請求項１記載のファイル転送システム。
【請求項４】
前記送信機器は、さらに、
前記受信機器でのファイル転送に関する情報を取得するための情報取得コマンドを生成するコマンド生成手段を備え、
前記送信手段は、前記情報取得コマンドを前記受信機器に送信し、
前記受信機器は、さらに、
ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドのレンジヘッダに、受信した前記ファイルデータの元となる前記ファイルの総サイズ及び前記ファイルデータの実転送完了サイズを記録する記録手段を備え、
前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、前記記録手段において記録された情報を返答する
ことを特徴とする請求項１記載のファイル転送システム。
【請求項５】
前記記録手段は、さらに、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドにおいてファイル転送状況を記録し、
前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、記録された前記ファイル転送状況を返答する
ことを特徴とする請求項４記載のファイル転送システム。
【請求項６】
前記ファイル転送状況は、アップロード中、送信機器側からのサスペンド要求による中断、ネットワーク切断による中断、又は受信機器側からのディスク容量オーバのいずれか１つであり、
前記受信機器は、さらに、
受信した前記ファイルを格納する格納手段を備え、
前記ファイル転送情報が、前記ネットワーク切断による中断である場合には、前記格納手段に格納され、前記中断前に受信したファイルデータは消去可能である
ことを特徴とする請求項５記載のファイル転送システム。
【請求項７】
前記送信手段は、さらに、UPnP-AV規格で規定されるCDS:CreateObjectアクションリクエストとして、少なくとも前記ファイル転送の中断又は再開が可能かを確認する情報を含むメタデータ情報を前記受信機器に送信し、
前記受信手段は、さらに、前記メタデータ情報を受信し、
前記能力返答手段は、前記メタデータ情報に基づいて、UPnP-AV規格で規定されるCDS:CreateObjectアクションレスポンスとして、前記送信機器に対して前記ファイル転送の中断又は再開が可能であるか否かの能力を返答し、
前記能力確認手段は、前記返答に基づいて、前記受信機器の前記ファイル転送の能力を確認する
ことを特徴とする請求項１記載のファイル転送システム。
【請求項８】
ネットワークを介して受信機器に対してファイルを送信する送信機器であって、
前記受信機器のファイル転送の能力を確認する能力確認手段と、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の能力に応じて、前記ファイルデータを前記送信手段に送信させる送信制御手段と、
前記受信機器に送信される前記ファイルを複数に分割する分割手段とを備え、
前記送信制御手段は、前記能力確認手段において前記受信機器がファイル転送の中断・再開が可能であると確認される場合において、前記ファイルを前記分割手段において分割された分割ファイルデータの単位で前記送信手段に送信させ、
前記送信手段は、前記分割ファイルデータを前記受信機器に送信する
ことを特徴とする送信機器。
【請求項９】
前記能力確認手段は、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する前記受信機器の能力確認を行うことで、前記受信機器のファイル転送の能力を確認する
ことを特徴とする請求項８記載の送信機器。
【請求項１０】
前記送信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記ファイルデータを前記受信機器に送信する
ことを特徴とする請求項８記載の送信機器。
【請求項１１】
前記送信機器は、さらに、
ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドのレンジヘッダに、前記分割ファイルデータの元となるファイルにおけるデータ範囲、及び前記元となるファイルの総サイズの少なくとも一方を格納する格納手段を備える
ことを特徴とする請求項８記載の送信機器。
【請求項１２】
ネットワークを介して、送信機器から送信されるファイルを受信する受信機器であって、
前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答手段と、
前記ファイルを構成するファイルデータを受信する受信手段と、
前記能力に応じて、前記ファイルデータを前記受信手段に受信させる受信制御手段とを備える
ことを特徴とする受信機器。
【請求項１３】
前記能力返答手段は、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する能力に関して返答する
ことを特徴とする請求項１２記載の受信機器。
【請求項１４】
前記受信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記送信機器から送信される前記ファイルデータを受信する
ことを特徴とする請求項１２記載の受信機器。
【請求項１５】
ネットワークを介して受信機器に対してファイルを送信する送信方法であって、
前記受信機器のファイル転送の能力を確認する能力確認ステップと、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと、
前記ファイル転送の能力に応じて、前記ファイルデータを前記送信ステップにおいて送信させる送信制御ステップと、
前記受信機器に送信される前記ファイルを複数に分割する分割ステップとを含み、
前記送信制御ステップにおいては、前記能力確認ステップにおいて前記受信機器がファイル転送の中断・再開が可能であると確認される場合において、前記ファイルを前記分割手段において分割された分割ファイルデータの単位で前記送信ステップにおいて送信させ、
前記送信ステップにおいては、前記分割ファイルデータを前記受信機器に送信する
ことを特徴とする送信方法。
【請求項１６】
ネットワークを介して、送信機器から送信されるファイルを受信する受信方法であって、
前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答ステップと、
前記ファイルを構成するファイルデータを受信する受信ステップと、
前記能力に応じて、前記ファイルデータを前記受信ステップにおいて受信させる受信制御ステップとを含む
ことを特徴とする受信方法。
【請求項１７】
ネットワークを介して受信機器に対してファイルを送信する送信機器に用いるプログラムであって、
前記受信機器のファイル転送の能力を確認する能力確認ステップと、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと、
前記ファイル転送の能力に応じて、前記ファイルデータを前記送信ステップにおいて送信させる送信制御ステップと、
前記受信機器に送信される前記ファイルを複数に分割する分割ステップとを含み、
前記送信制御ステップにおいては、前記能力確認ステップにおいて前記受信機器がファイル転送の中断・再開が可能であると確認される場合において、前記ファイルを前記分割手段において分割された分割ファイルデータの単位で前記送信ステップにおいて送信させ、
前記送信ステップにおいては、前記分割ファイルデータを前記受信機器に送信する
ことをコンピュータに実行させるプログラム。
【請求項１８】
ネットワークを介して、送信機器から送信されるファイルを受信する受信機器に用いるプログラムであって、
前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答ステップと、
前記ファイルを構成するファイルデータを受信する受信ステップと、
前記能力に応じて、前記ファイルデータを前記受信ステップにおいて受信させる受信制御ステップと
をコンピュータに実行させることを特徴とするプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介してファイル転送を行うためのファイル転送システム、送信機器及び受信装置に関し、特に、ファイルに付随する情報（メタデータ）の管理を行いファイル転送を行うファイル転送システム、送信機器及び受信装置に関する。
【背景技術】
【０００２】
近年、ｘＤＳＬや光ファイバーなどのブロードバンド環境が整ったことにより、企業、一般家庭を問わずインターネット接続が急速に普及してきている。また、家庭内のＰＣや家電機器をEthernet（登録商標）や無線ＬＡＮなどで接続するホームネットワーク環境も一般化してきている。この様な中で、パーソナルコンピュータ（ＰＣ）だけでなく、テレビやＤＶＤレコーダ、エアコン、冷蔵庫のような家電もIETF（Internet Engineering Task Force）により定義されるIP(Internet Protocol)により相互に接続できるようになってきている。
【０００３】
インターネットやホームネットワークにおけるアプリケーションの１つとして、家電機器、ＰＣ間でファイルを転送するアプリケーションがある。例えば、ＤＶＤレコーダに録画したＴＶ番組をＰＣに転送して編集を行ったり、ＤＶＤレコーダ間で録画したMPEG２ファイルを転送することによりダビング機能を提供する例などがある。
【０００４】
この様なファイル転送を行うプロトコルでは一般的に、ファイルの転送が誤り無く行われることが要求され、その一方リアルタイムの転送は必ずしも要求されない。IP(Internet Protocol)においてファイル転送を行う代表的なプロトコルとしては、RFC２６１６で定義されるＨＴＴＰ（Hyper Text Transfer Protocol）や、RFC９５９で定義されるFTP(File Transfer Protocol)等が存在する。これらのプロトコルはいずれもRFC７９３で定義されるＴＣＰ(Transmission Control Protocol)プロトコルの再送機能によって転送の信頼性を確保している。
【０００５】
すなわち、ＴＣＰはパケットのエラーを検出して再送する手順と、欠落したパケットを検出して再送する手順を含んでおり、そのために伝送路上でエラーやパケット欠落が起こっても正しいファイルの転送が保障できる。一方でＴＣＰの再送手順には限界もあり、例えば伝送路の障害や、送信元の機器（以下ではソース機器と呼ぶ）や、受信先の機器（以下ではシンク機器と呼ぶ）の都合により転送の中断が長時間に渡った場合、ＴＣＰ接続がタイムアウトにより切断されてしまい、それ以後のファイル転送が行えなくなるという課題が存在する。ここでの機器都合には障害のほか、機器の他の機能を実行するためにファイル転送を中断せざるを得ない場合、例えば、ＤＶＤレコーダがタイマー録画を実行するためにファイル転送を中断する例などが挙げられる。
【０００６】
ＨＴＴＰには前記課題を解決するための手順が既に含まれており、転送の中断が任意の長時間に渡った場合でも、再度ＴＣＰ接続を行って、中断前に転送した位置の直後からファイル転送を再開できるシーケンスが定義されている。本シーケンスを図１に従って説明する。
【０００７】
図１は、従来のソース機器及びシンク機器により構成されるファイル転送システムにおけるファイル転送の再開に係る通信シーケンスの一例を示す図である。なお、図１は、シンク機器１００２からの「ＨＴＴＰ  ＧＥＴリクエスト」の要求に基づいて、ソース機器１００１からシンク機器１００２にファイル転送を行うものである。
【０００８】
本手順では、最初に、シンク機器１００２はソース機器１００１に対し、「ＨＴＴＰ  ＧＥＴリクエスト」を発行する（Ｓ１０１）。次に、ソース機器１００１は本リクエストに対し、「２００  ＯＫ」を応答し（Ｓ１０２）、１０００バイトのファイルの送信を開始する（Ｓ１０３）。本図においては、ここで通信障害が発生し（Ｓ１０４）、ＴＣＰ接続が切断され、それまでにシンク機器１００２には５００バイトのデータが保存できていたとする（Ｓ１０５）。この場合、シンク機器１００２は、通信障害が回復するのを待ち、任意の時点でＴＣＰの再接続を行い、転送を再開することができる。転送の再開はシンク機器１００２がソース機器１００１に対し、Ｒａｎｇｅヘッダを追加した「ＨＴＴＰ  ＧＥＴリクエスト」により、５００バイト以降目の部分のファイルを要求することにより行われる（Ｓ１０６）。
【０００９】
そして、ソース機器１００１は、シンク機器１００２から指定されたＲａｎｇｅ（ここでは５００-９９９バイト目）に従ってファイルを送信し（Ｓ１０７及びＳ１０８）、シンク機器１００２がこれを保存することで（Ｓ１０９）、転送済みのデータを再送することなく、未転送のデータのみを転送の再開によって取得することが可能である。このように、本図に示すファイル転送システムにおいては、ファイル転送を再開するブロックをシンク機器１００２側が記憶しておくことで、不足データ部分を確実に配信することが可能となる。そして、この様な手順が、例えばインターネット上のサーバに配置される数メガバイト以上もの大きなファイルのダウンロードが失敗した際に、続きから取得することで効率よくファイルを取得するアプリケーションなどで使用されている。
【００１０】
また、このようなＨＴＴＰのＧＥＴメソッドを利用し、データの提供を行う技術についても開示されている（例えば、特許文献１参照）。
【特許文献１】特開２００２−２８８１６２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、この様な従来のファイル転送システムにおけるＨＴＴＰの中断、再開手順は、クライアント手動等で受信機器側からファイル転送を要求するＨＴＴＰのＧＥＴメソッドには使用できる一方、ＨＴＴＰのＰＯＳＴメソッドは使用できないという問題がある。
【００１２】
そして、インターネット上のサーバからＰＣにファイルをダウンロードする場合はＨＴＴＰのＧＥＴメソッドが使用されるためこの様な制約は問題にはならないが、ネットワークに接続される任意の機器間でファイルを転送する場合において、ソース機器（例えば宅内のＤＶＤレコーダ）が任意のファイルを自発的にシンク機器（例えば宅内のＰＣ）に送りつけようとする場合においては通常ＨＴＴＰのＰＯＳＴメソッドが用いられるため、この様な場合にはファイル転送の中断、再開を行うことができないという課題がある。
【００１３】
この課題は、より一般的にいうと、従来の送信機器側から受信機器側にデータを送りつけることをトリガとしてプッシュ型のフロー制御を行うファイル転送プロトコルにおいては、受信機器側から送信機器側にリクエストを発行するプル型のフロー制御と異なり、送信機器側からの受信機器側のファイル転送能力の確認の手順や、ファイル転送の中断、再開を行う手順が存在しないことに起因している。
【００１４】
また、ＨＴＴＰのＰＯＳＴメソッド等を用いて送信機器から受信機器に自発的にデータを送りつけるファイル転送プロトコルにおいては、送信機器から受信機器のファイル転送の再開・中断等の能力を確認する手順も存在していない。
【００１５】
本発明は、上記課題を考慮し、ＨＴＴＰのＰＯＳＴメソッド等を用いて送信機器側から受信機器側に自発的にデータを送りつけるプッシュ型のフロー制御を行うファイル転送プロトコルにおいても、送信機器が受信機器のファイル転送の中断・再開能力の確認ができ、また、ソース機器、シンク機器の都合や、ＴＣＰ接続のタイムアウトなどでネットワーク切断された場合にも、効率的に残りのファイル転送の再開を可能にするファイル転送システム、送信機器及び受信装置を提供することを目的とする。
【課題を解決するための手段】
【００１６】
上記目的を達成するために、本発明に係るファイル転送システムは、ネットワークを介して、ファイルを送信する送信機器と、ファイルを受信する受信機器との間でファイルを転送するファイル転送システムであって、前記送信機器は、前記受信機器のファイル転送の能力を確認する能力確認手段と、前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、前記ファイル転送の能力に応じて、前記ファイルデータを前記送信手段に送信させる送信制御手段とを備え、前記受信機器は、前記送信機器からのファイル転送に関する能力確認に対して返答する能力返答手段と、前記ファイルを構成するファイルデータを受信する受信手段と、前記能力に応じて、前記ファイルデータを前記受信手段に受信させる受信制御手段とを備えることを特徴とする。
【００１７】
また、前記能力返答手段は、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）のＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する能力に関して返答し、前記能力確認手段は、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する前記受信機器の能力確認を行うことで、前記受信機器のファイル転送の能力を確認することを特徴とする。
【００１８】
また、前記送信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記ファイルデータを前記受信機器に送信し、前記受信手段は、ＨＴＴＰのＰＯＳＴメソッド又はＰＵＴメソッドを使用して前記送信機器から送信される前記ファイルデータを受信することを特徴とする。
【００１９】
これらの構成により、本発明に係るファイル転送システムにおいては、ＨＴＴＰのＰＯＳＴメソッド等を用いて送信機器から受信機器に自発的にデータを送りつけるファイル転送プロトコルにおいても、返信機器の能力確認手段において受信機器のＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドの独自のレンジヘッダ拡張に対する能力を確認することにより、受信機器のファイル転送に関する能力を確認でき、送信制御手段で受信機器のファイル転送の能力に合わせてファイルデータの送信を制御することが可能となる。
【００２０】
また、本発明に係るファイル転送システムにおいて、前記送信機器は、さらに、前記受信機器でのファイル転送に関する情報を取得するための情報取得コマンドを生成するコマンド生成手段を備え、前記送信手段は、前記情報取得コマンドを前記受信機器に送信し、前記受信機器は、さらに、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドのレンジヘッダに、受信した前記ファイルデータの元となる前記ファイルの総サイズ及び前記ファイルデータの実転送完了サイズを記録する記録手段を備え、前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、前記記録手段において記録された情報を返答することを特徴とする。
【００２１】
さらに、前記記録手段は、さらに、ＨＴＴＰのＰＯＳＴメソッド或いはＰＵＴメソッドにおいてファイル転送状況を記録し、前記能力返答手段は、前記送信機器からの前記情報取得コマンドに対して、記録された前記ファイル転送状況を返答することを特徴とする。
【００２２】
これらの構成により、本発明に係るファイル転送システムにおいては、送信機器から受信機器に対して情報取得コマンドを送信して受信機器側でのファイルデータの実転送完了サイズやファイル転送状況といったファイル転送に関する情報を取得することができるため、ＨＴＴＰのＰＯＳＴメソッドによるプッシュ型のフロー制御を行うファイル転送プロトコルを用いる場合にも、送信機器側から受信機器側のファイル転送の中断・再開能力の確認、未転送のデータのみを転送する等、より効率的なファイル転送の再開を可能とする。
【００２３】
さらに、本発明の送信機器及び受信機器それぞれの特徴的な構成部をステップとする送信方法及び受信方法として実現したり、コンピュータに各ステップを実行させるためのプログラムとして実現することもできる。そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を通じて配信することができるのは言うまでもない。
【発明の効果】
【００２４】
本発明に係るファイル転送システムによれば、特にＨＴＴＰのＰＯＳＴメソッドによるプッシュ型のフロー制御を行うファイル転送プロトコルを用いる場合にも、送信機器側から受信機器側のファイル転送の中断・再開能力の確認ができ、また、未転送のデータのみを転送する効率的なファイル転送の再開を可能とする。
【発明を実施するための最良の形態】
【００２５】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
（実施の形態１）
以下で、本発明に係るファイル転送システムの第１の実施例について、図面を参照しながら説明する。
【００２６】
図２において送信機器としてのソース機器１０１と受信機器としてのシンク機器１０２は各々蓄積メディアを内蔵し、ファイルを蓄積することができる。この様な機器の例としてネットワーク接続端子を備えたＤＶＤ／ＨＤＤハイブリッドレコーダなどが上げられる。本実施例の初期状態ではソース機器１０１が転送したいファイルを蓄積しており、ネットワークを介してシンク機器１０２に転送して蓄積するものとする。なお、シンク機器１０２、ソース機器１０１ともにユニバーサルプラグアンドプレイフォーラムの発行するUPnP-AV規格に準拠しており、シンク機器１０２はCDS（Contents Directory Service）サーバ機能を実装しており、ソース機器１０１はCDSサーバにアクセスするControl Point機能を実装しているものとする。
【００２７】
ソース機器１０１の詳細構成を別の図を用いて説明する。図７、図８はそれぞれソース機器１０１とシンク機器１０２の機能ブロック図である。
【００２８】
図７において、ソース機器１０１は、ユーザインタフェース７０１、ファイル送信制御部７０２、ファイル蓄積部７０５からのファイル読出し制御を実行するファイル制御部７０３、ネットワークインタフェース７０６を制御してネットワークを介した通信制御を実行する通信制御部７０４、実体ファイル７０７と共に、実体ファイルの付随情報（メタデータ）であるファイルobject７０８が格納されているファイル蓄積部７０５、及びネットワークインターフェース７０６を備えるものである。
【００２９】
また、ソース機器１０１は、ユーザインタフェース部７０１を制御してファイル蓄積部７０５に蓄積したファイルの一覧リストを表示する。ユーザが一覧リストの中から選択したファイルを、ファイル蓄積部７０５から読出し、ネットワークインタフェース７０６を制御して、シンク機器１０２に送付する。
【００３０】
図８において、シンク機器１０２は、ファイル受信制御部８０１、ファイル蓄積部８０４に対するファイル書込み制御を実行するファイル制御部８０２、ネットワークインタフェース８０５を制御してネットワークを介した通信制御を実行する通信制御部８０３、ソース側からのファイル転送完了後に、実体ファイル８０６及びファイル付随情報（メタデータ）８０７が生成及び蓄積するファイル蓄積部８０４、及びネットワークインターフェース８０５を備えるものである。
【００３１】
以上のような構成において、図４に示すように、ソース機器１０１は実体ファイル７０７の転送に先立って、シンク機器１０２に対しUPnP-AV規格で規定されるCDS:CreateObjectアクションリクエストを発行する（Ｓ２０３）。
【００３２】
このCDS:CreateObjectアクションリクエストには、ファイルの付随情報（メタデータ）であるファイルobject７０８から生成されたファイルobject８０７が記述されており、本実施の形態１におけるファイルobject８０７は、図４に示すようなXMLデータ形式であり、シンク機器１０２がファイル転送の再開・中断が可能かどうかを確認する際に、Ｓ２０３のCDS:CreateObjectアクションリクエスト時にインプットされるメタデータ情報４００を示し、図３に示す従来のCDS:CreateObjectアクションリクエスト時にインプットされる通常のメタデータ情報３００に加え、本実施例においては、シンク側におけるファイル転送中断・再開能力を尋ねるための情報（４０１及び４０２）が加えられている。
【００３３】
図４では「ｅｘｔ：ＰＯＳＴＲｅｑｕｅｓｔ＝“１”（４０２）」と記載しているが、これら文字列及び数値を本実施例において特定するものではない。CDS:CreateObjectアクションリクエストを受信したシンク機器１０２では、ファイルobject８０７をファイル蓄積部８０４に格納した上で、ディレクトリの位置や、ファイル名等のメタデータをファイルobject８０７に追記する。この際のメタデータには特にファイル実体を保存すべきシンク機器１０２上のURLが含まれており、追記されたファイルobject８０７はＳ１０４に示すCDS:CreateObjectアクションレスポンスによりソース機器１０１に通知される。
【００３４】
また、本実施例においては、図５のソース機器１０１からのファイル転送の再開・中断確認要求に対するＯＫの場合のCDS:CreateObjectアクションレスポンスにインプットするメタデータ情報５００に示すように、シンク機器１０２におけるファイル転送中断・再開能力を通知するための情報として、「ｅｘｔ：ＰＯＳＴＲｅｑｕｅｓｔ＝“１”（５０１）」が記されている。シンク機器１０２においてファイル転送中断・再開能力がない場合は、図６のメタデータ情報６００に示すように「ｅｘｔ：ＰＯＳＴＲｅｑｕｅｓｔ＝“１”」を記さないようにするか、「ｅｘｔ：ＰＯＳＴＲｅｑｕｅｓｔ＝“０”」と返答する（Ｓ２０４）。
【００３５】
そして、シンク機器１０２からCDS:CreateObjectアクションレスポンスを受信したソース機器１０１は、ファイル転送の再開・中断が可能と判断した上で、ファイルを分割転送するサイズを決定する。分割転送のサイズは転送の中断、再開の頻度、中断時に無駄になる転送サイズ、分割によるオーバヘッド等を勘案して任意に決定することができる。ここでは１０００Byteのファイルを、最初の０-４９９byte、次の５００-９９９Byteに分割して送信するものとし、ソース機器はＨＴＴＰのＰＯＳＴメソッドを送信する（Ｓ２０５）。
【００３６】
また、ＰＯＳＴメソッドには本発明で独自に定義したヘッダである、Upload Range:[byte-RangeＴotal size]が含まれる。ここでの「byte-Range」は、続くＨＴＴＰのEntity Body部に含まれるデータの範囲を示し、「total size」ではＨＴＴＰのＰＯＳＴメソッドにおいて最終的に転送するファイルの総サイズ１０００byteを示す。Ｓ２０５では最初の分割転送単位である、０-４９９byteが指定される。ＰＯＳＴメソッドで指定するURLには、CreateObjectアクションレスポンスに記述されるファイルObject８０７に含まれるURLを記述する。これにより、シンク機器１０２は特定のファイルObjectと、受信したファイルの実体を対応させることができる。さらに、Ｓ２０５においてはヘッダとしてさらに、Expect: １００-continueが記述されているため、シンク機器はRFC２６１６に従って、Ｓ２０５におけるＰＯＳＴリクエストをそのURLで受け入れることができるかのチェックを行い、可能であれば１００ Continueレスポンスを返す（Ｓ２０６）。この動作により、Ｓ２０５のＰＯＳＴリクエストを受け入れたり、解釈することができない場合にはデータの転送の前にソース機器に通知することができ、無駄なデータ送信を回避することができる。
【００３７】
そして、ソース機器１０１は、ＨＴＴＰのＰＯＳＴのEntity Body送信を開始する（Ｓ２０７）。「Entity Body」に含まれるファイルの範囲は、０-４９９byte範囲のみである。シンク機器１０２はこの５００byte分を受信すると内蔵するファイル蓄積部８０７へ保存を行う（Ｓ２０８）。
【００３８】
次に、本実施の形態においては、Ｓ２０４において受信した「CDS:CreateObjectアクションレスポンス」に基づきソース機器１０１は、シンク機器１０２がファイル転送の再開・中断が可能と判断したために、ソース機器１０１は、次の５００-９９９Byteに分割して送信するためのＨＴＴＰのＰＯＳＴメソッドを送信する（Ｓ２０９）。なお、このＰＯＳＴメソッドのUpload Range:[byte-RangeＴotal size]に含まれる「byte-Range」には、最後の分割転送単位である、５００-９９９ byteが指定され、「total size」ではＨＴＴＰのＰＯＳＴメソッドにおいて最終的に転送するファイルの総サイズ１０００byteを示す。
【００３９】
また、ＰＯＳＴメソッドで指定するURLには、「CreateObjectアクションレスポンス」に記述されるファイルObject８０７に含まれるURLを記述され、また、Ｓ２０９においてはヘッダとしてさらに、「Expect: １００-continue」が記述されているため、シンク機器はRFC２６１６に従って、Ｓ２０９におけるＰＯＳＴリクエストをそのURLで受け入れることができるかのチェックを行い、可能であれば「１００ Continueレスポンス」を返す（Ｓ２１０）。
【００４０】
そして、ソース機器１０１は、ＨＴＴＰのＰＯＳＴのEntity Body送信を開始する（Ｓ２１１）。「Entity Body」に含まれるファイルの範囲は、５００-９９９byte範囲のみである。シンク機器１０２はこの５００byte分を受信すると内蔵するファイル蓄積部８０７へ保存を行い、一連のファイル転送の処理を終了する（Ｓ２１２）。
【００４１】
このように、本実施の形態１に係るファイル転送システムにおいては、ＨＴＴＰのＰＯＳＴメソッドを用いてファイルを送りつけるプッシュ型のフロー制御でもファイルを分割して送信を行うことが可能になる。なお、ＨＴＴＰで当然使用されるその他のヘッダについては本発明の動作に関係しないので記載を省略する。また、ここで定義したヘッダ名は別のヘッダ名でもかまわない。
【００４２】
以上のように、本実施の形態１に係るファイル転送システムにおいては、ＨＴＴＰのＰＯＳＴメソッド等を用いてソース機器１０１からシンク機器１０２に自発的にデータを送りつけるファイル転送プロトコルを用いる場合においても、ファイルに付随するメタデータ情報に新たなファイル転送のための情報を付加することにより、ソース機器１０１が自発的にシンク機器１０２のファイル転送能力の確認を行うことが可能となる。
【００４３】
このため、ソース機器１０１は、シンク機器１０２がファイル転送の中断・再開が不可能であれば、中断・再開を許容しない通常のプッシュ型のファイル転送を実行するシーケンスへ移行させ、シンク機器１０２が中断・再開が可能であれば、中断・再開を許容するプッシュ型のファイル転送を実行するシーケンスへ移行させることができ、この場合には、ファイルを任意のサイズに分割して分割ファイルの転送を行うことができる。
【００４４】
また、ＨＴＴＰのＰＯＳＴメソッドを用い、ファイル送信を行うソース機器１０１でファイルを分割し、拡張されたヘッダにより転送範囲を明示して送信できるため、シンク機器１０２がファイル転送の再開が可能であると確認できる場合には、分割したファイル転送の中断・再開が可能となる。
【００４５】
（実施の形態２）
以下で、本発明に係るファイル転送システムの第２の実施例について、図面を参照しながら説明する。なお、本実施の形態２に係るファイル転送システムは、ファイル転送の途中でソース機器側の都合によりファイル転送を中断する場合において、ソース機器からシンク機器に対してＣＤＳ：Ｂｒｏｗｓｅリクエストを送信することを特徴とするものである。また、本実施の形態２に係るソース機器及びシンク機器の内部構成そのものは、実施の形態１の図７、図８で説明した通りであり、また、ソース機器とシンク機器間において任意のサイズでのファイル転送を行うまでの手順も実施の形態１の図２で説明した通りであるために、これらの詳細な説明を省略する。
【００４６】
図９は、本実施の形態２に係るファイル転送システムにおいて、何らかの事情によりＰＯＳＴメソッドによるファイル転送が中断した状態からの再開シーケンスを説明する。なお、図９におけるＳ２０１からＳ２０８までの処理は、上述した実施の形態１の図２で説明したものと同じである。
【００４７】
この状態において、何らかの事情によりＰＯＳＴメソッドによるファイル転送が中断した場合、ソース機器１０１は、再開すべきファイルサイズを特定するために、CDS:Browseアクションリクエストをシンク機器１０２に対して送信し（Ｓ９０１）、CDS:Browseアクションレスポンスによってシンク機器が保有しているファイルobjcet８０７を取得する（Ｓ９０２）。なお、上記の何らかの理由とは、例えばソース機器としてのＤＶＤレコーダを用いて転送途中に、このＤＶＤレコーダを介してテレビを視聴し始めてファイル転送が中断されたような場合である。
【００４８】
そして、ソース機器１０１は、ファイルObject８０７に記述されている「ｅｘｔ：ＰＯＳＴｅｄＳｉｚｅ＝“４９９／１０００”」を取得することで、シンク機器１０２がファイル転送中断前までに取得したファイルサイズ（本実施の形態２においては４９９byte）を特定することができる。なお、以後の残りとなる５００-９９９Byteのファイル転送の再開の処理は、図２の説明におけるＳ２０９からＳ２１２と同じとなる。
【００４９】
そして、本発明の第２の実施例においては、図２のＳ２０５に示すＰＯＳＴメソッドを受信したシンク機器１０２は、ネットワークインタフェース８０５を介して通信制御部８０３がパケットを受け取り、ファイル受信制御部８０１はＰＯＳＴメソッドで受け取るサイズを“Upload Range:[byte- Range Ｔotal size]”の「byte-Range」から読み取り、更に最終的に受け取る総サイズを読み取り、ファイル制御部８０２を通じて一旦メモリ上に保持しておく。
【００５０】
そして、図９のＳ２０７において実際のデータ転送が完了し次第、ファイル蓄積部８０４に格納されているファイルobject８０７に追記する。追記された状態のファイルobject８０７の詳細を図１３にて説明する。図１３は、シンク機器１０２側で管理されているメタデータ情報１３００を示し、図９のＳ２０４のCDS:CreateObjectアクションリクエスト受信時に生成された図５に示すファイルObjectに比べ、図１３のファイルObjectでは、「ｅｘｔ：ＰＯＳＴｅｄＳｉｚｅ＝“４９９／１０００”（１３０１）」が追記されている。ここで示している“４９９”は、ＰＯＳＴメソッドでの実転送サイズであり、“１０００”は総サイズ数を示す。
【００５１】
この処理を繰り返し、実転送サイズ＝総サイズになった時点でＰＯＳＴメソッドにおけるファイル転送が完了したと見なす。
【００５２】
以上のように、本実施の形態２に係るファイル転送システムにおいては、ＨＴＴＰのＰＯＳＴメソッドによるファイル転送時において、ソース機器側の何らかの都合により中断した残りのファイル転送を、正確に継続して再開することが可能となる。
【００５３】
（実施の形態３）
以下、本発明に係るファイル転送システムの第３の実施例について、図面を参照しながら説明する。なお、本実施の形態３に係るファイル転送システムは、ＰＯＳＴメソッドによるファイル転送時において、ファイル転送の中断理由に応じて、その後のファイル転送を管理することを特徴とするものである。また、本実施の形態３におけるソース機器及びシンク機器の内部構成そのものは、第１の実施例の図７、図８で説明した通りであり、また、ソース機器とシンク機器間において任意のサイズでのファイル転送を行うまでの手順も実施の形態１の図２で説明した通りである。
【００５４】
本発明の第３の実施例においては、中断理由により再開動作が異なる場合について特徴を述べている。ＰＯＳＴメソッドによるファイル転送が開始されるシーケンスは図１の通りであるが、シンク機器１０２において最初のＰＯＳＴメソッドをネットワークインタフェース８０５を介して通信制御部８０３がパケットを受け取ると、ファイル受信制御部８０１はファイル蓄積部８０４に格納されているファイルobject ８０７に「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ＝“ｕｐｌｏａｄｉｎｇ”」を追記する。追記された状態のファイルobject ８０７の詳細は、図１４にて説明する。
【００５５】
この図１４は、シンク機器１０２側で管理されているメタデータ情報１４００を示し、図２のＳ２０４におけるCDS:CreateObjectアクションリクエスト受信時に生成された図５に示すファイルObjectに比べ、図１３で説明した「ｅｘｔ：ｐｏｓｔｅｄＳｉｚｅ＝“４９９／１０００”（１３０１）」の他に、「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ＝“ｕｐｌｏａｄｉｎｇ”（１４０１）」が追記されている。この「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ」には、シンク機器におけるファイル転送状態を記述しており、ファイル転送が完了すると同時に、「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ」そのものを削除する。
【００５６】
図１０ではソース機器１０１のユーザ又はプロセッサ処理の判断においてＰＯＳＴメソッドにおけるファイル転送を中断した場合のシーケンスを説明する。
【００５７】
ソース機器１０１からファイル転送を中断する場合には、ソース機器１０１は、ヘッダにUpload Control:suspendを付与したＰＯＳＴメソッドを送信することでシンク機器１０２に中断通知を行う（Ｓ１００１）。シンク機器１０２においては、ネットワークインタフェース８０５を介して通信制御部８０３がパケットを受け取り、ファイル受信制御部８０１はＰＯＳＴメソッドで受け取るサイズを“Upload Control:suspend”を読み取り、ファイル蓄積部８０４に格納されているファイルobject ８０７の内容において、「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ＝“ｓｕｓｐｅｎｄｅｄ”」に修正する（Ｓ１００２）。次に、シンク機器１０２は、ソース機器１０１側に「２００  ＯＫ」の返信を行う（Ｓ１００３）。
【００５８】
そして、シンク機器１０２のファイル受信制御部８０１は、定期的又は一定の判断基準に基づいてｅｘｔ：ｐｏｓｔＳｔａｔｕｓの値をチェックし、“ｓｕｓｐｅｎｄｅｄ”であった場合はソース側の理由により故意にファイル転送が中断されていると判断し、ファイル８０６及びファイルObject８０７を削除しないなどの処理を行うことが可能となる。また、シンク機器１０２におけるユーザインタフェースにファイルの状態を出力した上で、ユーザにファイル操作させることも可能である。
【００５９】
図１１では、ネットワーク障害によりファイル転送を中断した場合のシーケンスを説明する。なお、Ｓ２０３からＳ２０８までの処理は図２で説明した通りである。
【００６０】
ここでネットワーク障害が発生し（Ｓ１１０１）、ＰＯＳＴメソッドによるファイル転送は中断され、ある一定時間にシンク機器１０２においてファイル受信が行われない場合は、ファイル受信制御部８０１がファイル蓄積部８０４に格納されているファイルobject ８０７の内容において、「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ＝“ｄｉｓｃｏｎｎｅｃｔｅｄ”」に修正する。
【００６１】
そして、シンク機器１０２のファイル受信制御部８０１は、定期的又は一定の判断基準に基づいてｅｘｔ：ｐｏｓｔＳｔａｔｕｓの値をチェックし、“ｄｉｓｃｏｎｎｅｃｔｅｄ”であった場合は、ネットワーク障害によるファイル転送切断であると解釈し、ファイル蓄積部８０５に蓄積されているファイル８０６及びファイルObject８０７を削除するなどの処理を行うことが可能となる。また、シンク機器１０２におけるユーザインタフェースにファイルの状態を出力した上で、ユーザにファイル操作させることも可能である。
【００６２】
図１２では、シンク機器１０２の都合によりファイル転送を中断した場合のシーケンスを説明する。Ｓ２０３からＳ２０８までの処理は図１で説明した通りである。
【００６３】
ここで、ＰＯＳＴメソッドにおけるファイル転送要求に対して（Ｓ１２０１）、シンク機器１０２側において、例えばディスク容量オーバーなどの理由でファイル転送を中断したい場合には、ソース機器１０１側に「５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ」を返信し（Ｓ１２０２）、シンク機器１０２のファイル受信制御部８０１がファイル蓄積部８０４に格納されているファイルobject ８０７の内容において、「ｅｘｔ：ｐｏｓｔＳｔａｔｕｓ＝“ｄｉｓｋ  ｆｕｌｌ”」に修正する（Ｓ１２０３）。
【００６４】
そして、シンク機器１０２のファイル受信制御部８０１は、定期的又は一定の判断基準に基づいてｅｘｔ：ｐｏｓｔＳｔａｔｕｓの値をチェックし、“ｄｉｓｋ  ｆｕｌｌ”であった場合は、シンク機器１０２のディスク容量オーバとしてファイル蓄積不可によるファイル転送切断であると解釈し、時にはファイル８０６及びファイルObject８０７を削除するなどの処理を行う。またシンク機器１０２におけるユーザインタフェースにファイルの状態を出力した上で、ユーザにファイル操作させることも可能である。
【００６５】
以上のように、本実施の形態３に係るファイル転送システムにおいては、ＰＯＳＴメソッドによるファイル転送時において、ソース機器１０１が任意のタイミングでファイル転送を中断・再開できるほか、シンク機器１０２が任意のタイミングでファイル転送を中断した際においても、ファイル転送の中断理由毎に、ファイル操作及び効率的なファイル転送の再開が可能となる。
【産業上の利用可能性】
【００６６】
本発明に係るファイル転送システムは、ＨＴＴＰのＰＯＳＴメソッド等を用いてネットワークに接続される任意の機器間でファイルを転送する場合において一般的に用いることができ、特にファイルのサイズが大きく、転送を中断して再開する際に、転送を初めからやり直すと無駄が多い場合に効果を発揮する。
【図面の簡単な説明】
【００６７】
【図１】図１は、従来例に係るファイル転送システムの通信シーケンス図である。
【図２】図２は、本発明の第１の実施例に係るファイル転送システムの通信シーケンス図である。
【図３】図３は、ＣｒｅａｔｅＯｂｊｅｃｔアクションリクエスト時に入力される通常のメタデータ情報の参考図である。
【図４】図４は、本発明の第１の実施例に係るＣｒｅａｔｅＯｂｊｅｃｔアクションリクエスト時に入力されるメタデータ情報の参考図である。
【図５】図５は、本発明の第１の実施例に係るシンク機器において生成されるメタデータ情報の参考図である。
【図６】図６は、本発明の第１の実施例に係るシンク機器において生成されるメタデータ情報の参考図である。
【図７】図７は、本発明に係るソース機器の機能ブロック図である。
【図８】図８は、本発明に係るシンク機器の機能ブロック図である。
【図９】図９は、本発明の第２の実施例に係るファイル転送の中断シーケンス図である。
【図１０】図１０は、本発明の第３の実施例に係るファイル転送の中断シーケンス図である。
【図１１】図１１は、本発明の第３の実施例に係るファイル転送の中断シーケンス図である。
【図１２】図１２は、本発明の第３の実施例に係るファイル転送の中断シーケンス図である。
【図１３】図１３は、本発明の第２の実施例に係るシンク機器において管理されるメタデータ情報の参考図である。
【図１４】図１４は、本発明の第３の実施例に係るシンク機器において管理されるメタデータ情報の参考図である。
【符号の説明】
【００６８】
１０１  ソース機器
１０２  シンク機器
３００，４００，５００，６００，１３００，１４００  メタデータ情報
７０１  ユーザインタフェース
７０２  ファイル送信制御部
７０３  ファイル制御部
７０４  通信制御部
７０５  ファイル蓄積部
７０６  ネットワークインタフェース
７０７  転送するファイル
７０８  ファイルの付随情報（メタデータ）
８０１  ファイル受信制御部
８０２  ファイル制御部
８０３  通信制御部
８０４  ファイル蓄積部
８０５  ネットワークインタフェース
８０６  転送されたファイル
８０７  転送されたファイルの付随情報（メタデータ）
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2006046445.tif 000016
【図２】
2006046445.tif 000017
【図３】
2006046445.tif 000018
【図４】
2006046445.tif 000019
【図５】
2006046445.tif 000020
【図６】
2006046445.tif 000021
【図７】
2006046445.tif 000022
【図８】
2006046445.tif 000023
【図９】
2006046445.tif 000024
【図１０】
2006046445.tif 000025
【図１１】
2006046445.tif 000026
【図１２】
2006046445.tif 000027
【図１３】
2006046445.tif 000028
【図１４】
2006046445.tif 000029
【国際調査報告】
2006046445.tif 000030
2006046445.tif 000031
2006046445.tif 000032
2006046445.tif 000033