(57)【要約】本発明は、送信機器から自発的に受信機器へファイルを転送するファイル転送システムにおいて、ファイル転送が長時間にわたり中断される場合であっても、ファイル転送に係る処理を効率的に実行するための送信機器、受信機器およびファイル転送システムを提供する。  本発明のファイル転送システムにおいて、受信機器であるシンク機器は、送信機器であるソース機器から受信する、ファイルを構成するファイルデータを保存し、ソース機器から保存済サイズを問い合わせられると、保存済サイズをソース機器に送信する。また、ソース機器は、ファイル転送の中断を検出し、ファイル転送を中断が検出した後に、シンク機器に保存済データサイズを問い合わせる。更に、その問い合わせに応じてシンク機器が応答した保存済データサイズに基づき、ファイルを構成する残りのファイルデータを送信する。【特許請求の範囲】
【請求項１】
ネットワークを介し、ファイルを送信する送信機器から前記ファイルを受信する受信機器へのファイル転送を行うファイル転送システムであって、
前記受信機器は、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備え、
前記送信機器は、
ファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の中断を検出する検出手段と、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に  前記保存済データサイズを問い合わせる問合せ手段と、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済データサイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備える
ファイル転送システム。
【請求項２】
前記送信手段は、Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）のＰＯＳＴメソッドまたはＰＵＴメソッドを使用して前記ファイルを前記受信機器に送信する
請求項１記載のファイル転送システム。
【請求項３】
前記送信制御手段は、更に、前記送信手段がファイルデータを送信する前に、前記ファイルデータの前記ファイルにおける範囲であるデータ範囲を前記受信機器に通知し、
前記受信機器は、更に、前記データ範囲に基づき、前記保存手段に保存されているファイルデータと、前記データ範囲が通知された後に受信したファイルデータとを結合するファイル制御手段を備える
請求項１記載のファイル転送システム。
【請求項４】
前記送信制御手段は、前記データ範囲とともに前記ファイルの総サイズを前記受信機器に通知する
請求項３記載のファイル転送システム。
【請求項５】
前記送信制御手段は、更に、前記ファイルを所定のサイズのファイルデータに分割し、
前記送信手段は、前記送信制御手段により分割されたファイルデータを前記受信機器に送信する
請求項４記載のファイル転送システム。
【請求項６】
前記受信制御手段は、更に、ファイル転送の中断を要求する中断要求を前記送信機器へ送信し、
前記中断要求は、前記受信機器が前記ファイル転送を再開する始期を示す始期情報と、前記受信機器が前記ファイル転送を受け入れる終期を示す期間情報とを含み、
前記検出手段は、前記中断要求を受信することで前記ファイル転送の中断を検出し、
前記送信制御手段は、前記始期から前記許可期間の間に前記残りのファイルデータを前記送信手段に送信させる
請求項１記載のファイル転送システム。
【請求項７】
前記送信制御手段は、更に、前記送信手段がファイルデータを送信する前に、前記ファイルデータの前記受信機器における保持期間を前記受信機器に通知し、
前記受信制御手段は、更に、前記ファイルデータが前記保存手段に保存され、かつ、前記ファイルデータの保持期間が経過する前に、前記ファイルを構成する全てのファイルデータを前記送信機器から受信しない場合、前記保存手段に保存されている前記ファイルデータを削除する
請求項１記載のファイル転送システム。
【請求項８】
前記送信機器と前記受信機器とはＴｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続によりファイル転送を行い、
前記検出手段は、前記送信制御手段が、ファイルデータの送信中に前記ＴＣＰ接続を切断したことを検出することで前記ファイル転送の中断を検出し、
前記送信制御手段は、更に、前記ＴＣＰ接続の切断後に、ファイルデータの前記受信機器における保持期間を前記受信機器に通知し、
前記受信制御手段は、更に、前記送信機器から通知された前記保持期間が経過する前に、前記ファイルを構成する全てのファイルデータを前記送信機器から受信しない場合、前記保存手段に保存されているファイルデータを削除する
請求項１記載のファイル転送システム。
【請求項９】
前記送信機器と前記受信機器とはＴｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続によりファイル転送を行い、
前記送信制御手段は、更に、前記ＴＣＰ接続が前記受信機器により切断されると、ファイル転送の許可を得るための転送要求を前記受信機器に送信し、
前記受信制御手段は、更に、前記転送要求への応答として前記ファイル転送の中断を要求する中断要求を前記送信機器に送信し、
前記検出手段は、前記中断要求を受信することにより前記ファイル転送の中断を検出する
請求項１記載のファイル転送システム。
【請求項１０】
ネットワークを介し、受信機器へファイルを転送するファイル転送を行う送信機器であって、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の中断を検出する検出手段と、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に保存されているファイルデータのサイズである保存済データサイズを問い合わせる問合せ手段と、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済データサイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段と
を備える送信機器。
【請求項１１】
ネットワークを介し、送信機器から送信されるファイルを受信する受信機器であって、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段と
を備える受信機器。
【請求項１２】
ネットワークを介し、受信機器へファイルを転送するファイル転送を行うための送信方法であって、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと、
前記ファイル転送の中断を検出する検出ステップと、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に保存されているファイルデータのサイズである保存済データサイズを問い合わせる問合せステップと、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済データサイズに基づき、前記ファイルを構成する残りのファイルデータを前記受信機器に送信する送信制御ステップと
を含む送信方法。
【請求項１３】
ネットワークを介し、送信機器から送信されるファイルを受信するための受信方法であって、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存手段に保存する保存ステップと、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得ステップと、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御ステップと
を含む受信方法。
【請求項１４】
ネットワークを介し、受信機器へファイルを転送するファイル転送を行うためのプログラムであって、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと、
前記ファイル転送の中断を検出する検出ステップと、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に保存されているファイルデータのサイズである保存済データサイズを問い合わせる問合せステップと、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済データサイズに基づき、前記ファイルを構成する残りのファイルデータを前記受信機器に送信する送信制御ステップと
をコンピュータに実行させるためのプログラム。
【請求項１５】
ネットワークを介し、送信機器から送信されるファイルを受信するためのプログラムであって、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存手段に保存する保存ステップと、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得ステップと、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御ステップと
をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明はネットワークを介してファイル転送を行うための送信機器、受信機器およびファイル転送システムに関する。
【背景技術】
【０００２】  近年、ｘＤＳＬや光ファイバーなどのブロードバンド環境が整ったことにより、企業、一般家庭を問わずインターネット接続が急速に普及してきている。また、家庭内のパーソナルコンピュータ（ＰＣ）や家電機器をＥｔｈｅｒｎｅｔ（登録商標）や無線ＬＡＮなどで接続するホームネットワーク環境も一般化してきている。この様な状況の中で、ＰＣだけでなく、テレビやＤＶＤレコーダ、エアコン、冷蔵庫のような家電もＩｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）により定義されるＩｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ（ＩＰ）により相互に接続できるようになってきている。【０００３】  インターネットやホームネットワークにおけるアプリケーションプログラムの１つとして、家電機器、ＰＣ間でファイルを転送するアプリケーションプログラムがある。ファイルを転送するアプリケーションプログラムの例として、ＤＶＤレコーダに録画したＴＶ番組を編集するためにＰＣに転送したり、ＤＶＤレコーダ間で録画したＭＰＥＧ２ファイルを転送するなどのダビング機能を提供するアプリケーションプログラムがある。【０００４】  この様なファイル転送を行うプロトコルでは一般的に、ファイルの転送が誤り無く行われることが要求される一方で、リアルタイムの転送は必ずしも要求されない。ＩＰにおいてファイル転送を行う代表的なプロトコルとしては、ＲＦＣ２６１６で定義されるＨｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）や、ＲＦＣ９５９で定義されるＦｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＦＴＰ）等が存在する。これらのプロトコルはいずれもＲＦＣ７９３で定義されるＴｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ（ＴＣＰ）の再送機能によって転送の信頼性を確保している。【０００５】  すなわち、ＴＣＰはパケットのエラーを検出して再送する手順と、欠落したパケットを検出して再送する手順を含んでおり、そのために伝送路上でエラーやパケット欠落が起こっても正しいファイルの転送が保障できる。一方でＴＣＰの再送手順には限界もあり、例えば伝送路の障害や、送信元の機器（以下、「ソース機器」という。）や、受信先の機器（以下、「シンク機器」という。）の都合により転送の中断が長時間に渡った場合、ＴＣＰ接続がタイムアウトにより切断されてしまい、それ以後のファイル転送が行えなくなるという課題が存在した。ここでの機器の都合には障害のほか、機器の他の機能を実行するためにファイル転送を中断せざるを得ない場合を含む。例えば、ＤＶＤレコーダがタイマー録画を実行するためにファイル転送を中断する場合などが挙げられる。【０００６】  ＨＴＴＰには上述の課題を解決するための手順が含まれており、転送の中断が任意の長時間に渡った場合でも、再度ＴＣＰ接続を行って、中断前に転送した位置の直後からファイル転送を再開できるシーケンスが定義されている。本シーケンスを図１を用いて説明する。【０００７】  図１は、従来のソース機器およびシンク機器により構成されるファイル転送システムにおけるファイル転送の再開に係る通信シーケンスの一例を示す図である。【０００８】  図１に示す通信シーケンスは、ソース機器１００１からシンク機器１００２に対してファイル転送を行うためのファイル転送システムにおける通信シーケンスである。また、ファイル転送の途中でＴＣＰ接続が切断される場合を想定している。【０００９】  まず、シンク機器１００２はソース機器１００１に対し、ＨＴＴＰ  ＧＥＴリクエストを発行する（Ｓ１０１）。ソース機器１００１は本リクエストに対し、“２００  ＯＫ”を応答し（Ｓ１０２）、１０００バイトのファイルを送信する（Ｓ１０３）。その後、通信障害が発生し、ＴＣＰ接続が切断される（Ｓ１０４）。【００１０】  ここで、ＴＣＰ接続が切断されるまでにシンク機器１００２には５００バイトのデータが保存できていたと想定する（Ｓ１０５）。シンク機器１００２は、通信障害が回復するのを待ち、任意の時点でＴＣＰの再接続を行い、転送を再開することができる。転送の再開はシンク機器１００２がソース機器１００１に対し、Ｒａｎｇｅヘッダを追加したＨＴＴＰ  ＧＥＴリクエストを送信し（Ｓ１０６）、転送対象のファイルの先頭から５００バイト目以降のデータを要求することにより行われる。【００１１】  ソース機器１００１は、シンク機器１００２から指定されたＲａｎｇｅ（ここでは５００−９９９バイト目である。）に従ってデータを送信し（Ｓ１０７、Ｓ１０８）、シンク機器１００２は受信したデータを保存する（Ｓ１０９）。これにより、転送済みのデータを再送することなく、未転送のデータのみを転送の再開によって取得することが可能である。この様な手順が、例えばインターネット上のサーバに配置される数メガバイト以上もの大きなファイルのダウンロードが失敗した場合に、取得済みのデータの続きから取得することで効率よくファイルを取得するアプリケーションプログラムで使用されている。【００１２】  ＨＴＴＰのＧＥＴメソッドを利用し、データの提供を行う技術についても開示されている（例えば、特許文献１参照）。
【特許文献１】特開２００２−２８８１６２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】  しかしながら、上記従来のＨＴＴＰのファイル転送の中断、再開手順は、ＨＴＴＰのＧＥＴメソッドでは使用できるがＰＯＳＴメソッドでは使用できないという課題が存在する。インターネット上のサーバからＰＣにファイルをダウンロードする場合はＨＴＴＰのＧＥＴメソッドが使用されるためこの様な制約は問題にはならない。【００１４】  しかし、ネットワークに接続される任意の機器間でファイルを転送する場合において、ソース機器が任意のファイルをシンク機器の要求なしに自発的に送信しようとする場合は通常ＨＴＴＰ  ＰＯＳＴメソッドが用いられる。そのため、ソース機器とシンク機器との間の通信が中断した場合には、通信の再開後にファイルの送信を最初から行わなければならず、ファイル転送のためのリソースや時間を無駄に消費するという課題がある。【００１５】  この課題はより一般的にいうと、ソース側から自発的にデータを送信することをトリガとしてプッシュ型のフロー制御を行うファイル転送プロトコルにおいては、シンク側からリクエストを発行するプル型のフロー制御と異なり、通信の中断があった場合に、効率的なファイル転送を行う手順が存在しなかったという課題である。【００１６】  さらに、前述のＨＴＴＰのＧＥＴメソッドにおけるファイル転送の中断、再開手順においても、再開の可能な期間が規定されておらず、従ってサーバ上に長期間公開されるファイルを不特定多数のＰＣがダウンロードする用途には適するが、ネットワークに接続される任意の機器間でファイルを転送する場合において、ソース機器およびシンク機器がいつまで再開を可能な状態に維持すべきか明確で無い。そのため、ソース機器およびシンク機器においてリソースの無駄が生じることとなる。【００１７】  本発明は、上記課題を考慮し、送信機器から自発的に受信機器へファイルを転送するファイル転送システムにおいて、ファイル転送が長時間にわたり中断される場合であっても、ファイル転送に係る処理を効率的に実行するための送信機器、受信機器およびファイル転送システムを提供することを目的とする。
【課題を解決するための手段】
【００１８】  上記目的を達成するために、本発明のファイル転送システムは、ネットワークを介し、ファイルを送信する送信機器から前記ファイルを受信する受信機器へのファイル転送を行うファイル転送システムであって、前記受信機器は、前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備え、前記送信機器は、ファイルデータを前記受信機器に送信する送信手段と、前記ファイル転送の中断を検出する検出手段と、前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に前記保存済データサイズを問い合わせる問合せ手段と、前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済データサイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備える。【００１９】  また、本発明の送信機器は、ネットワークを介し、受信機器へファイルを転送するファイル転送を行う送信機器であって、前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、前記ファイル転送の中断を検出する検出手段と、前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に保存されているファイルデータのサイズである保存済データサイズを問い合わせる問合せ手段と、前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済データサイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備える。【００２０】  また、本発明の受信機器は、ネットワークを介し、送信機器から送信されるファイルを受信する受信機器であって、前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備える。【００２１】  このように、本発明によれば、送信機器は、ファイル転送の中断後、受信機器に保存済サイズを問い合わせることができる。また受信機器は、その問い合わせへの応答として保存済サイズを送信機器に送信することができる。送信機器は、保存済サイズを知らされることにより、受信機器に送信すべき残りのファイルデータのみを送信することができる。【００２２】  つまり、中断されたファイル転送の再開に際し、送信機器は、ファイルデータの送信を最初から行う必要がなく、受信機器にとって必要な残りのファイルデータのみを送信すればよい。また、受信機器は、重複する無駄なファイルデータを受信することがない。従って、送信機器および受信機器におけるファイル転送に係る処理において、長時間にわたる中断が発生した場合においても、無駄な処理やリソースの無駄な消��が発生することがなく、ファイル転送に係る処理を効率的に実行することができる。【００２３】  また、本発明のファイル転送システムにおいて、前記受信制御手段は、更に、ファイル転送の中断を要求する中断要求を前記送信機器へ送信し、前記中断要求は、前記受信機器が前記ファイル転送を再開する始期を示す始期情報と、前記受信機器が前記ファイル転送を受け入れる終期を示す期間情報とを含み、前記検出手段は、前記中断要求を受信することで前記ファイル転送の中断を検出し、前記送信制御手段は、前記始期から前記許可期間の間に前記残りのファイルデータを前記送信手段に送信させるとしてもよく、また、本発明のファイル転送システムにおいて、前記送信制御手段は、更に、前記送信手段がファイルデータを送信する前に、前記ファイルデータの前記受信機器における保持期間を前記受信機器に通知し、前記受信制御手段は、更に、前記ファイルデータが前記保存手段に保存され、かつ、前記ファイルデータの保持期間が経過する前に、前記ファイルを構成する全てのファイルデータを前記送信機器から受信しない場合、前記保存手段に保存されている前記ファイルデータを削除するとしてもよい。【００２４】  このように、送信機器と受信機器とは互いに、ファイル転送を行う期間についての情報をやりとりすることができる。これにより、送信機器および受信機器のそれぞれは、相手機器によりファイル転送が中断された場合、いつまでもファイル転送の再開に備えておく必要がなく、それぞれの機器のリソースを無駄に消費することがない。つまり、ファイル転送に係る処理を効率的に実行することができる。【００２５】  更に、本発明は、本発明のファイル転送システム、送信機器および受信機器それぞれの特徴的な構成部をステップとする方法として実現したり、それらのステップを含むプログラムとして実現したり、そのプログラムが格納された、ＣＤ−ＲＯＭ等の記録媒体として実現したり、集積回路として実現することもできる。プログラムは、通信ネットワーク等の伝送媒体を介して流通させることもできる。
【発明の効果】
【００２６】  本発明は、送信機器から自発的に受信機器へファイルを転送するファイル転送システムにおいて、ファイル転送が長時間にわたり中断される場合であっても、ファイル転送に係る処理を効率的に実行するための送信機器、受信機器およびファイル転送システムを提供することができる。【００２７】  例えば、ファイルをＨＴＴＰのＰＯＳＴメソッドを用いて送信するソース機器と、ソース機器からファイルを受信するシンク機器とにより構成されるファイル転送システムにおいて、ファイル転送の中断が発生し、ＴＣＰ接続がタイムアウトした後であっても、送信機器は保存済みのデータサイズを知ることができる。従って、送信機器は、受信機器おいて保存済みのデータに続くデータを受信機器に転送することができる。【００２８】  つまり、あるファイルを転送する場合、送信機器においては、無駄なデータ送信を行うことがなく、受信機器においては、無駄なデータを受信することがない。【００２９】  結果として、ソース側からデータを送送信することをトリガとしてプッシュ型のフロー制御を行うファイル転送プロトコルにおいても、リソースや時間などの無駄を発生させることなく、ファイル転送に係る処理を効率的に実行することができる。【００３０】  更に、中断、再開手順において再開の可能な期間をハンドシェイクする方法および手段を提供し、ソース機器およびシンク機器がいつまで再開を可能な状態に維持すべきか明確にすることができる。これにより、ファイル転送におけるソース機器およびシンク機器のメモリやメディア等のリソースにおける無駄を無くすことができる。このことによってもファイル転送に係る処理を効率的に実行することができる。
【図面の簡単な説明】
【００３１】
【図１】図１は、従来のソース機器およびシンク機器により構成されるファイル転送システムにおけるファイル転送の再開に係る通信シーケンスの一例を示す図
【図２】図２は、本発明の実施の形態のファイル転送システムの機器構成を示す図
【図３】図３は、本発明の実施の形態のソース機器の機能的な構成を示す機能ブロック図
【図４】図４は、本発明の実施の形態のシンク機器の機能的な構成を示す機能ブロック図
【図５】図５は、本発明の実施の形態のファイル転送システムにおける基本の通信シーケンスを示す図
【図６】図６は、ソース機器からシンク機器に送付される各パラメータの内容を示す図
【図７】図７は、実施の形態のファイル転送システムにおいて、ソース機器の都合によりファイル転送が中断される際の通信シーケンスの一例を示す図
【図８】図８は、実施の形態のファイル転送システムにおいて、シンク機器の都合によりファイル転送が中断される際の通信シーケンスの一例を示す図
【図９】図９は、実施の形態のファイル転送システムにおいて、シンク機器の都合によりファイル転送が中断される際の通信シーケンスの別の一例を示す図
【図１０】図１０は、実施の形態のファイル転送システムにおいて、ファイル転送を再開する際の通信シーケンスを示す図
【図１１】図１１は、実施の形態のファイル転送システムにおいて、ファイルデータの送信が開始される前に、ソース機器の都合によりファイル転送が中止される際の通信シーケンスの一例を示す図
【図１２】図１２は、実施の形態のファイル転送システムにおいて、ファイルデータの送信中に、ソース機器の都合によりファイル転送が中止される際の通信シーケンスの一例を示す図
【図１３】図１３は、実施の形態のファイル転送システムにおいて、ファイルデータの送信が開始される前に、シンク機器の都合によりファイル転送が中止される際の通信シーケンスの一例示す図
【図１４】図１４は、実施の形態のファイル転送システムにおいて、ファイルデータの送信中に、シンク機器の都合によりファイル転送が中止される際の通信シーケンスの一例示す図
【図１５】図１５は、ソース機器がシンク機器にファイルを分割して転送するファイル転送システムの通信シーケンスを示す図
【図１６】図１６は、ファイルを分割して転送するファイル転送システムにおいて、分割後の１つのファイルデータの送信前に、ソース機器の都合によりファイル転送が中断される場合の通信シーケンスを示す図
【図１７】図１７は、ファイルを分割して転送するファイル転送システムにおいて、シンク機器がＰＯＳＴリクエストを受信した際に、シンク機器の都合により転送が中断される場合の通信シーケンスを示す図
【図１８】図１８は、ファイルを分割して転送するファイル転送システムにおいて、シンク機器の都合によりファイル転送が中止される場合の通信シーケンスを示す図
【符号の説明】
【００３２】  １０１  ソース機器
１０２  シンク機器
７０１  ユーザインターフェース
７０２  ファイル送信制御部
７０３、８０２  ファイル制御部
７０４、８０３  通信制御部
７０５、８０４  ファイル蓄積部
７０６  、８０５  ネットワークインターフェース
７０７  中断検出部
７０８  問合せ部
８０１  ファイル受信制御部
８０６  保存済サイズ取得部
【発明を実施するための最良の形態】
【００３３】  以下、本発明を実施するための最良の形態について図面を用いて説明する。
まず、本発明の実施の形態のファイル転送システムの構成を図２〜図４を用いて説明する。【００３４】  図２は、本発明の実施の形態のファイル転送システムの機器構成を示す図である。本発明の実施の形態のファイル転送システムは、ソース機器１０１からシンク機器１０２へファイルを転送するためのシステムである。【００３５】  図２に示すように、ソース機器１０１およびシンク機器１０２はブロードバンドルータ３０１に接続されてホームネットワークを構成する。ブロードバンドルータ３０１はインターネット３０２に接続されていても良い。【００３６】  ソース機器１０１とシンク機器１０２は各々蓄積メディアを内蔵し、Ａｕｄｉｏ  Ｖｉｓｕａｌ（ＡＶ）コンテンツ等のファイルを蓄積することができる。具体的には、ソース機器１０１は、ファイル蓄積部７０５を備え、シンク機器１０２は、ファイル蓄積部８０４を備える。【００３７】  この様な機器の例としてネットワーク接続端子を備えたＤＶＤ／ＨＤＤハイブリッドレコーダなどが上げられる。本実施の形態の初期状態ではソース機器１０１がファイル蓄積部７０５にファイル３０３を蓄積しており、本ファイルをホームネットワークを介してシンク機器１０２に転送する。シンク機器１０２はソース機器から受信したファイル３０３をファイル蓄積部８０４に蓄積する。【００３８】  なお、本実施の形態ではシンク機器１０２、ソース機器１０１ともにユニバーサルプラグアンドプレイフォーラムの発行するＵＰｎＰ−ＡＶ規格に準拠しており、シンク機器１０２はＣｏｎｔｅｎｔｓ  Ｄｉｒｅｃｔｏｒｙ  Ｓｅｒｖｉｃｅ（ＣＤＳ）サーバ機能を実装しており、ソース機器１０１はＣＤＳサーバにアクセスするＣｏｎｔｒｏｌ  Ｐｏｉｎｔ機能を実装しているものとする。【００３９】  図３は、本発明の実施の形態のソース機器１０１の機能的な構成を示す機能ブロック図である。ソース機器１０１は、本発明の送信機器の一例である。なお、ソース機器１０１について、本来備えられているＣｏｎｔｒｏｌ  Ｐｏｉｎｔ機能等の図示および説明は省略し、ソース機器１０１において特徴的な構成部についてのみ図示および説明を行なう。【００４０】  図３に示すように、ソース機器１０１は、ユーザインターフェース７０１、ファイル送信制御部７０２、ファイル制御部７０３、通信制御部７０４、ファイル蓄積部７０５、およびネットワークインターフェース７０６を備える。図中の点線で囲まれた領域にある構成部は、ファイル転送に係る主要な処理を行う構成部である。【００４１】  ユーザインターフェース７０１は、ユーザからの指示等の入力を受け付け、また、ユーザに映像等で情報を提供するインターフェースである。ネットワークインターフェース７０６は、ホームネットワークを介してシンク機器１０２との情報のやり取りを行うインターフェースである。【００４２】  ファイル蓄積部７０５は、上述のように、ＡＶコンテンツ等のファイルを蓄積する記憶装置である。【００４３】  ファイル送信制御部７０２は、ファイルのシンク機器１０２への送信を制御する制御部であり、問合せ部７０８を有する。問合せ部７０８は、中断されたファイル転送を再開する際に、シンク機器１０２に、保存済データサイズを問い合わせる処理部である。【００４４】  なお、上記の保存済データサイズとは、ソース機器１０１からシンク機器１０２へのファイル転送において、シンク機器１０２が受信し保存した、当該ファイルを構成するファイルデータ（以下、単に「データ」ともいう。）の容量のことを指す。つまり、ファイルサイズが１０００バイトである場合、保存済データサイズは０バイトから１０００バイトの間の値となる。【００４５】  また、「ファイル転送の中断」とは、ファイルデータの送信が開始されて以降にファイルデータの送信または受信が中断される場合だけでなく、ファイル転送に必要な処理が中断される場合も含む。【００４６】  ファイル制御部７０３は、ファイル蓄積部７０５からのファイルの読出しを制御する制御部である。【００４７】  通信制御部７０４は、ネットワークインターフェース７０６を制御することでホームネットワークを介した通信を制御する制御部である。通信制御部７０４とネットワークインターフェース７０６とにより本発明の送信機器における送信手段が有する、情報を送信する機能が実現される。また、通信制御部７０４は、中断検出部７０７を有する。中断検出部７０７は、ファイル転送の中断を検出する処理部である。【００４８】  ソース機器１０１は、ユーザインターフェース７０１を制御して７０５に蓄積したファイルの一覧リストを表示する。ユーザが一覧リストの中から選択したファイルを、ファイル蓄積部７０５から読出し、ネットワークインターフェース７０６を制御して、シンク機器１０２に送付する。【００４９】  図４は、本発明の実施の形態のシンク機器１０２の機能的な構成を示す機能ブロック図である。シンク機器１０２は、本発明の受信機器の一例である。なお、シンク機器１０２について、本来備えられているＣＤＳサーバ機能等の図示および説明は省略し、シンク機器１０２において特徴的な構成部についてのみ図示および説明を行なう。【００５０】  図４に示すように、シンク機器１０２は、ファイル受信制御部８０１、ファイル制御部８０２、通信制御部８０３、ファイル蓄積部８０４、およびネットワークインターフェース８０５を備える。図中の点線で囲まれた領域にある構成部は、ファイル転送に係る主要な処理を行う構成部である。【００５１】  ネットワークインターフェース８０５は、ホームネットワークを介してソース機器１０１との情報のやり取りを行うインターフェースである。【００５２】  ファイル蓄積部８０４は、本発明の受信機器における保存手段の一例であり、上述のように、ソース機器１０１から受信するファイルを蓄積する記憶装置である。【００５３】  ファイル受信制御部８０１は、ソース機器１０１から送信されるファイルの受信を制御する制御部である。【００５４】  ファイル制御部８０２は、ファイル蓄積部８０４からのファイルの読出しを制御する制御部であり、保存済サイズ取得部８０６を有する。保存済サイズ取得部８０６は、ファイル蓄積部８０４から保存済データサイズを取得する処理部である。取得された保存済データサイズは、ファイル受信制御部８０１の制御により、ソース機器１０１へ送信される。【００５５】  通信制御部８０３は、ネットワークインターフェース８０５を制御することでホームネットワークを介した通信を制御する制御部である。【００５６】  次に、以上のように構成されたソース機器１０１およびシンク機器１０２により構成されるファイル転送システムにおけるソース機器１０１およびシンク機器１０２の動作を図５から図１４を参照して説明する。【００５７】  まず、基本の通信シーケンスにおける各機器の動作を図５および図６を用いて説明する。【００５８】  図５は、本発明の実施の形態のファイル転送システムにおける基本の通信シーケンスを示す図である。図５に示すように、本実施の形態では、ソース機器１０１からシンク機器１０２への通信によりファイル転送が開始される。つまり、図５は、ソース機器１０１からの自発的なファイル転送における通信シーケンス図である。【００５９】  なお、ソース機器１０１とシンク機器１０２との間の通信は、ブロードバンドルータ３０１により中継される。しかしながら、ブロードバンドルータ３０１の動作は本発明の特徴に関与しないため、以下、その図示および動作の説明は省略する。【００６０】  ソース機器１０１は、ＵＰｎＰ−ＡＶ規格で規定されたＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを送付する（Ｓ５０１）。ここでＣｒｅａｔｅＯｂｊｅｃｔリクエストは論理的なファイルを示すｏｂｊｅｃｔを生成するリクエストであり、これによってシンク機器１０２のファイル蓄積部８０４内に、新規にｏｂｊｅｃｔが生成される。その際、生成されるｏｂｊｅｃｔのディレクトリ構造上の位置や、そのｏｂｊｅｃｔを示すファイル名等のメタデータが決定される。このメタデータにはファイル実体を保存すべきシンク機器１０２上のＵｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒｓ（ＵＲＩ）が含まれている。シンク機器１０２は、ファイルの転送先アドレスとして、このＵＲＩを含んだＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスをソース機器に送信する（Ｓ５０２）。【００６１】  ソース機器１０１は、ＰＯＳＴメソッドのＨＴＴＰリクエスト（以下、「ＰＯＳＴリクエスト」という。）をシンク機器１０２に送付する（Ｓ５０３）。この際、ソース機器１０１は、ファイル転送が中断した場合にシンク機器１０２が参照すべきパラメータとして、図６に示すパラメータをＰＯＳＴリクエストに付加して送付する。具体的には、パラメータとして［ｂｙｔｅ−ｒａｎｇｅ］、［ｒｅｓｔａｒｔ−ｔｉｍｅ］、および［ｌｉｆｅｔｉｍｅ］の３つを送付する。【００６２】  図６は、ソース機器１０１からシンク機器１０２に送付される各パラメータの内容を示す図である。【００６３】  図６に示すように、［ｂｙｔｅ−ｒａｎｇｅ］は送信するデータのバイトレンジである。バイトレンジとは、送信するファイルデータの範囲であるデータ範囲の先頭位置と終端位置を示す情報、およびファイルの総サイズであるファイルサイズを示す情報である。また、単位はそれぞれバイトである。【００６４】  つまり、シンク機器１０２は、ソース機器から送信されるデータの範囲だけでなくファイルの総サイズも通知される。そのため、受信したファイルデータが、あるファイルを構成する一部のファイルデータであるのか、または、あるファイルを構成する全てのファイルデータであるのか��判断することができる。なお、本実施の形態においては、１つのファイルをシンク機器１０２に送信する場合、分割せずに一括して送信する。ファイルを分割して送信する場合については図１５を用いて後述する。【００６５】  ［ｒｅｓｔａｒｔ−ｔｉｍｅ］は、送信再開許可時間である。送信再開許可時間とは、中断後にファイル転送動作を再開するまでの一時停止時間を示す情報であり、単位は秒である。【００６６】  ［ｌｉｆｅｔｉｍｅ］は、ファイル保持期間である。ファイル保持期間とは、シンク機器１０２がｏｂｊｅｃｔまたはファイルデータを保持しておくべき時間を示す情報であり、単位は秒である。シンク機器１０２は、［ｌｉｆｅｔｉｍｅ］に示される期間が経過するまでに、ファイルデータを受信しない場合、作成したｏｂｊｅｃｔを保持しておく義務が無い。また、［ｌｉｆｅｔｉｍｅ］を通知され、完結していないファイルデータを受信した場合、［ｌｉｆｅｔｉｍｅ］に示される期間が経過するまでに、残りのファイルデータを受信しない場合、完結していないファイルデータを保持しておく義務がない。【００６７】  これにより、ソース機器１０１が接続不能になったり転送対象のファイルを消失してしまったような場合でも、シンク機器１０２は、完了できないファイル転送のための無駄なリソースを保持しておく必要が無い。そのため、シンク機器１０２においてリソースを効率よく管理でき、ユーザの手による不要なｏｂｊｅｃｔの削除などのメンテナンスも不要である。【００６８】  図５の通信シーケンスでは、ソース機器１０１は、送信するデータの先頭位置：０バイト目、終端位置：９９９バイト目およびファイルサイズ：１０００バイトを指定している。これは、上述のように、１つのファイルを一括して送信することを意味する。さらに、一時停止時間：１２００秒（２０分）、ファイル保持期間：１８００秒（３０分）も指定している。【００６９】  なお、転送中断要求を示す［ｓｕｓｐｅｎｄ−ｒｅｑ］は、図５の通信シーケンスにおいては使用されていない。［ｓｕｓｐｅｎｄ−ｒｅｑ］をシンク機器１０２に送付する場合については、図７を用いて後述する。【００７０】  また、ソース機器１０１からシンク機器１０２に送信されるＰＯＳＴリクエストで指定するＵＲＩとして、シンク機器１０２から受信したＣｒｅａｔｅＯｂｊｅｃｔレスポンスに含まれていたＵＲＩが記述される。これにより、シンク機器１０２は特定のｏｂｊｅｃｔと、受信したファイルデータを対応させることができる。【００７１】  さらに、ＰＯＳＴリクエストにはＥｘｐｅｃｔ：１００−ｃｏｎｔｉｎｕｅが付加される。これにより、シンク機器はＲＦＣ２６１６に従い、送信されたＰＯＳＴリクエストを上記ＵＲＩで受け入れることができるかのチェックを行う。【００７２】  チェックの結果、受け入れ可能であれば応答として“１００  Ｃｏｎｔｉｎｕｅ”を返す（Ｓ５０４）。なお、ソース機器１０１からのＰＯＳＴリクエストを受け入れることができない場合や、ＰＯＳＴリクエストを解釈することができない場合にはデータの転送の前にソース機器に通知することができる。従ってソース機器１０１は、無駄なデータ送信を回避することができる。【００７３】  ソース機器１０１は“１００  Ｃｏｎｔｉｎｕｅ”ステータスをシンク機器１０２から受信することにより、ファイルをシンク機器１０２に送信する（Ｓ５０５）。なお、ファイルデータはＰＯＳＴリクエストのＥｎｔｉｔｙ  Ｂｏｄｙに格納されて送信される。【００７４】  シンク機器１０２は、受信したファイルデータをファイル蓄積部８０４に蓄積する。シンク機器１０２は、ファイルの受信完了後に、ファイル蓄積部８０４へのファイル蓄積処理に時間を要する場合、例えば２０秒以内に蓄積が完了しない場合、ＲＦＣ２５１８で規定される“１０２  Ｐｒｏｃｅｓｓｉｎｇ”を送信し（Ｓ５０６）、蓄積処理中である旨をソース機器１０１に通知する。シンク機器１０２は、蓄積を完了すると“２０１  Ｃｒｅａｔｅｄ”を送信し、ソース機器１０１に蓄積完了である旨を通知する（Ｓ５０７）。【００７５】  以上の各機器の動作により、ソース機器１０１からシンク機器１０２へのファイル転送が完了する。【００７６】  なお、図５に示す通信シーケンスは、ファイル転送の途中で中断が発生しない基本の通信シーケンスであるが、ソース機器１０１またはシンク機器１０２の都合によりファイル転送の中断が生じる場合もある。そこで、以下に、ファイル転送の途中で中断が発生する場合の通信シーケンスおよび各機器の動作を、図７〜図９を用いて説明する。また、ファイル転送を再開する際の通信シーケンスおよび各機器の動作を図１０を用いて説明する。【００７７】  図７は、実施の形態のファイル転送システムにおいて、ソース機器１０１の都合によりファイル転送が中断される際の通信シーケンスの一例を示す図である。図７を用いて、ソース機器１０１からシンク機器１０２へのファイルデータの送信中に、ソース機器１０１の都合によりファイル転送が中断される際の各機器の動作を説明する。【００７８】  ソース機器１０１およびシンク機器１０２は、図５の通信シーケンスと同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う。この後、ソース機器１０１は、ＰＯＳＴリクエストをシンク機器１０２に送付する（Ｓ５０３）。シンク機器１０２は、ＰＯＳＴリクエストの応答として“１００  Ｃｏｎｔｉｎｕｅ”ステータスをソース機器１０１に送信する（Ｓ５０４）。ソース機器１０１は、ファイルデータのシンク機器１０２への送信を開始する（Ｓ５０５）。シンク機器１０２は、受信したファイルデータをファイル蓄積部８０４に蓄積する。ここまでの動作は、図５に示す通信シーケンスと同様である。【００７９】  ここでソース機器１０１において、ファイル転送を中断する要因が発生し、ＴＣＰ接続を切断するためのＲＳＴパケットを送付する。これにより、ファイル転送に利用しているＴＣＰ接続は切断される（Ｓ７０６）。【００８０】  ファイル転送を中断する要因とは、例えば、ユーザの操作により、転送中のファイルがファイル蓄積部７０５から削除されたなどである。【００８１】  ソース機器１０１は、さらに、［ｓｕｓｐｅｎｄ−ｒｅｑ］および［ｌｉｆｅｔｉｍｅ］を含めたＰＯＳＴリクエストパケットをシンク機器１０２に送信する（Ｓ７０７）。［ｓｕｓｐｅｎｄ−ｒｅｑ］は図６に示すように、ファイル転送の中断要求を示す情報で���る。つまり、シンク機器１０２は［ｓｕｓｐｅｎｄ−ｒｅｑ］を受信することにより、ファイル転送が中断されることを知ることができる。また、［ｌｉｆｅｔｉｍｅ］は、上述のようにシンク機器１０２がファイルデータを保持しておくべき時間を示す情報であり、この場合は、ソース機器１０１が、その時間内にファイル転送を再開することをも意味する。シンク機器１０２は、ファイル保持期間が経過した後は、受信し保存済みの当該ファイルデータを削除してもよい。【００８２】  なお、上述のファイル転送の中断に係る処理において、ＲＳＴパケットおよびＰＯＳＴリクエストパケットはファイル送信制御部７０２により生成されシンク機器１０２に送信される。以下、単に「ＰＯＳＴリクエスト」という場合、実体としてはＰＯＳＴリクエストパケットのことを指す。【００８３】  また、中断検出部７０７は、ＴＣＰ接続が切断されたことを検出することで、ファイル転送が中断されたことを検出する。【００８４】  シンク機器１０２は、上記ＰＯＳＴリクエストを受け取ると“２００  ＯＫ”を返信する（Ｓ７０８）。ソース機器１０１は、ファイル転送を中断する要因がなくなった後に、図１１を用いて後述するファイル転送の再開動作を実行する。【００８５】  このようにして、本実施の形態のファイル転送システムにおいて、ファイルデータの送信の開始後かつファイル転送が完了する前に、ソース機器１０１の都合によりファイル転送が中断される。【００８６】  次に、シンク機器１０２がＰＯＳＴリクエストを受信した際に、シンク機器１０２の都合によりファイル転送が中断される場合の各機器の動作を図８を用いて説明する。【００８７】  図８は、実施の形態のファイル転送システムにおいて、シンク機器１０２の都合によりファイル転送が中断される際の通信シーケンスの一例を示す図である。【００８８】  ソース機器１０１およびシンク機器１０２は、図５の通信シーケンスと同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う。この後、ソース機器１０１は、ＰＯＳＴリクエストをシンク機器１０２に送付する（Ｓ５０３）。ここまでの動作は、図５に示す通信シーケンスと同様である。【００８９】  ここで、シンク機器１０２は、ファイルの受信処理を行えない状態であり、ＰＯＳＴリクエストに対する応答として“５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ”ステータスを送信する。ファイルの受信処理を行えない状態とは、例えば、ファイル蓄積部８０４の空き容量がない状態などである。【００９０】  シンク機器１０２は、ステータスパケットにファイル転送を再開する始期を示す“ｒｅｔｒｙ−ａｆｔｅｒ”を含めて応答する（Ｓ８０４）。ソース機器１０１は、“ｒｅｔｒｙ−ａｆｔｅｒ”に示される時間を経過した後に、図１１を用いて後述するファイル転送の再開動作を実行する。【００９１】  このようにして、本実施の形態のファイル転送システムにおいて、ソース機器１０１からシンク機器１０２に、ＰＯＳＴリクエストにより転送されるファイルのサイズ等が通知された後、かつファイルデータの送信が開始される前に、シンク機器１０２の都合によりファイル転送が中断される。【００９２】  次に、ソース機器１０１からシンク機器１０２へのファイルデータの送信中に、シンク機器１０２側の要因によりファイル転送を中断する際の各機器の動作を図９を用いて説明する。【００９３】  図９は、実施の形態のファイル転送システムにおいて、シンク機器１０２の都合によりファイル転送が中断される際の通信シーケンスの別の一例を示す図である。【００９４】  ソース機器１０１およびシンク機器１０２は、図５の通信シーケンスと同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う。この後、ソース機器１０１は、ＰＯＳＴメソッドのＨＴＴＰリクエストをシンク機器１０２に送付する（Ｓ５０３）。シンク機器１０２は、ＨＴＴＰリクエストの応答として“１００  Ｃｏｎｔｉｎｕｅ”ステータスをソース機器１０１に送信する（Ｓ５０４）。ソース機器１０１は、ファイルデータのシンク機器１０２への送信を開始する（Ｓ５０５）。シンク機器１０２は、受信したファイルデータをファイル蓄積部８０４に蓄積する。ここまでの動作は、図５に示す通信シーケンスと同様である。【００９５】  ここでシンク機器１０２において、ファイル転送を中断する要因が発生し、ＲＳＴパケットを送付する。これにより、ファイル転送に利用しているＴＣＰ接続は切断される（Ｓ９０６）。ファイル転送を中断する要因とは、例えば、ファイル蓄積部８０４から別のファイルを読み出す必要が生じ、受信するファイルデータを蓄積できないなどである。【００９６】  ＴＣＰ接続がシンク機器により切断されると、ソース機器１０１のファイル送信制御部７０２は、再びＰＯＳＴリクエストをシンク機器１０２に送信する（Ｓ９０７）。【００９７】  シンク機器１０２は、ＰＯＳＴリクエストへの応答として“５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ”ステータスをソース機器１０１へ送信する（Ｓ９０８）。ステータスパケットには上述の［ｒｅｔｒｙ−ａｆｔｅｒ］が含められる。【００９８】  この［ｒｅｔｒｙ−ａｆｔｅｒ］を伴う“５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ”は、シンク機器１０２からのファイル転送の中断要求である。【００９９】  ソース機器１０１の中断検出部７０７は、この中断要求を検出することで、ファイル転送の中断を検出する。ソース機器１０１は、“ｒｅｔｒｙ−ａｆｔｅｒ”に示される時間を経過した後に、図１１を用いて後述するファイル転送の再開動作を実行する。【０１００】  このようにして、本実施の形態のファイル転送システムにおいて、ファイルデータの送信の開始後かつ送信が完了する前に、シンク機器１０２側の要因によりファイル転送が中断される。【０１０１】  次に、図７〜図９を用いて説明したファイル転送の中断後に、ファイル転送を再開する際の各機器の動作を図１０を用いて説明する。【０１０２】  図１０は、実施の形態のファイル転送システムにおいて、ファイル転送を再開する際の通信シーケンスを示す図である。【０１０３】  ソース機器１０１の中断検出部７０７は、ファイル転送が中断されたことを検出する（Ｓ１０００）。なお、中断検出部７０７は、ファイル転送の中断がソース機器１０１の都合によるものか、シンク機器１０２の都合によるものかを問わず、送受信するパケットの種類お���び内容等から、ファイル転送が中断されたことを検出することができる。【０１０４】  ソース機器１０１は、自身の都合によりファイル転送を中断した場合は、その中断の要因がなくなった後で、また、シンク機器１０２の都合によりファイル転送が中断された場合は、中断の際にシンク機器１０２から送信された［ｒｅｔｒｙ−ａｆｔｅｒ］に示される時間が経過した後で、以下の動作を行う。【０１０５】  ソース機器１０１は、ＣＤＳ：Ｂｒｏｗｓｅリクエストをシンク機器１０２に送信し（Ｓ１００１）、シンク機器１０２に対してファイルの保存サイズを問い合わせる。【０１０６】  具体的には、ソース機器１０１のファイル送信制御部７０２により生成されるＣＤＳ：Ｂｒｏｗｓｅリクエストに、問合せ部７０８によって、保存済データサイズの通知要求が含められる。そのＣＤＳ：Ｂｒｏｗｓｅリクエストは、ネットワークインターフェース７０６を介しシンク機器１０２へ送信される。【０１０７】  シンク機器１０２は、上記ＣＤＳ：Ｂｒｏｗｓｅリクエストを受け取ると保存済データサイズを含めたＣＤＳ：Ｂｒｏｗｓｅレスポンスをソース機器１０１に送信する（Ｓ１００２）。【０１０８】  具体的には、保存済サイズ取得部８０６が、ファイル蓄積部８０４に保存されている、当該ファイルを構成するファイルデータのデータサイズを取得する。更に、ファイル受信制御部８０１が、保存済サイズ取得部８０６により取得されたデータサイズを含めたＣＤＳ：Ｂｒｏｗｓｅレスポンスを生成する。生成されたＣＤＳ：Ｂｒｏｗｓｅレスポンスは、ネットワークインターフェース８０５を介しソース機器１０１に送信される。【０１０９】  ソース機器１０１のファイル送信制御部７０２は、受信した保存済データサイズに応じて転送すべきファイルの先頭位置を決定し、ファイル蓄積部７０５からファイルデータを読み出す。【０１１０】  例えば、ファイルサイズが１０００バイトであり、シンク機器１０２から通知された保存済データサイズが４００バイトである場合を想定する。この場合、シンク機器１０２に保存されているファイルデータは、０バイト目から３９９バイト目までのファイルデータである。従って、ファイル送信制御部７０２は、残りの４００バイト目から９９９バイト目までのファイルデータを、ファイル制御部７０３を介しファイル蓄積部７０５から読み出す。以下、「残りのファイルデータ」という場合、上述のように、転送対象のファイルデータから、シンク機器１０２に保存済みのファイルデータを除いた、残りのファイルデータのことを指す。【０１１１】  ソース機器１０１は、データ範囲とファイルサイズとを示す［ｂｙｔｅ−ｒａｎｇｅ］等を含むＰＯＳＴリクエストをシンク機器１０２に送信する（Ｓ１００３）。シンク機器１０２は、ＰＯＳＴリクエストへの応答として“１００  Ｃｏｎｔｉｎｕｅ”ステータスをソース機器１０１に送信する（Ｓ１００４）。【０１１２】  ソース機器１０１のファイル送信制御部７０２は、ファイル蓄積部７０５から読み出した残りのファイルデータを通信制御部７０４に送信させる。（Ｓ１００５）。シンク機器１０２のファイル制御部８０２は、［ｂｙｔｅ−ｒａｎｇｅ］に示されるデータ範囲に基づき、受信した��ァイルデータと中断前に保存済みのファイルデータとを結合し、元のファイルに再構築する。【０１１３】  このように、本発明の実施の形態のソース機器１０１は、中断されたファイル転送を再開する際に、シンク機器１０２に保存済データサイズを問い合わせることができる。また、本発明の実施の形態のシンク機器１０２はその問合せに応じ、保存済データサイズをソース機器１０１に通知することができる。【０１１４】  これにより、ソース機器１０１は、ファイル転送を最初からやり直す必要がなく、残りのファイルデータのみを送信するのみでよい。またシンク機器１０２は、ファイルデータを重複して受信することがない。【０１１５】  つまり、本発明の実施の形態のソース機器１０１、シンク機器１０２およびファイル転送システムにより、ソース機器１０１からの自発的なファイル転送において、規定されたＴＣＰ接続のタイムアウト時間より長い中断が生じた場合であっても、ファイル転送に係る処理を効率的に実行することができる。【０１１６】  さらに、転送を再開可能な時間を機器間で通知できるので、不要な転送再開試行動作を抑制でき、機器の通信負荷を低減できるという効果を有する。【０１１７】  なお、ファイル転送途中でネットワークの通信経路が断絶した場合、ソース機器１０１の中断検出部７０７が通信経路の断絶を検出すると、図１０の通信シーケンスに示すファイル転送の再開動作が開始される。【０１１８】  また、図７〜図９を用いてファイル転送が中断される場合の通信シーケンスおよび各機器の動作を説明したが、ソース機器１０１またはシンク機器１０２の都合により、ファイル転送を中断ではなく、中止する必要が生じる場合もある。本発明の実施の形態のソース機器１０１およびシンク機器１０２のそれぞれは、ファイル転送を中止する場合、互いの機器に通知することができる。以下に、ファイル転送の中止に係る通信シーケンスおよび各機器の動作を、図１１〜図１４を用いて説明する。【０１１９】  図１１は、実施の形態のファイル転送システムにおいて、ファイルデータの送信が開始される前に、ソース機器１０１の都合によりファイル転送が中止される際の通信シーケンスの一例を示す図である。図１１を用いて、ファイル転送が開始される前に、ソース機器１０１の都合によりファイル転送の実行が中止される際の各機器の動作を説明する。【０１２０】  ソース機器１０１およびシンク機器１０２は、図５の通信シーケンスと同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う（Ｓ５０１、Ｓ５０２）。この後、ソース機器１０１がＰＯＳＴリクエストを送信する前に、ソース機器１０１において、ユーザによりファイル転送のキャンセル指示がなされる、または、転送対象のファイルが削除されるなどの事象が発生したと想定する。【０１２１】  この場合、ソース機器１０１は、ファイル転送を中止するために、ＰＯＳＴリクエストに替えてＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔリクエストをシンク機器１０２に送信する（Ｓ１１０３）。シンク機器１０２は、ＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔを受信すると、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエスト（Ｓ５０１）に応じて作成したｏｂｊｅｃｔを削��する。更に、ｏｂｊｅｃｔを削除した旨を通知するために、ソース機器１０１にＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔレスポンスを応答する（Ｓ１１０４）。【０１２２】  このように、ファイル転送が開始される前に、ソース機器１０１の都合により、ファイル転送が中止された場合、シンク機器１０２では、ファイルを保存するために作成されたｏｂｊｅｃｔが削除される。つまり、シンク機器１０２において無駄となるｏｂｊｅｃｔは速やかに削除される。【０１２３】  次に、ソース機器１０１からシンク機器１０２へのファイルデータの送信中にソース機器１０１の都合によりファイル転送が中止される際の各機器の動作を図１２を用いて説明する。【０１２４】  図１２は、実施の形態のファイル転送システムにおいて、ファイルデータの送信中に、ソース機器１０１の都合によりファイル転送が中止される際の通信シーケンスの一例を示す図である。【０１２５】  ソース機器１０１およびシンク機器１０２は、図５の通信シーケンスと同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う。この後、ソース機器１０１は、ＰＯＳＴリクエストをシンク機器１０２に送付する（Ｓ５０３）。シンク機器１０２は、ＰＯＳＴリクエストの応答として“１００  Ｃｏｎｔｉｎｕｅ”ステータスをソース機器１０１に送信する（Ｓ５０４）。ソース機器１０１は、ファイルデータのシンク機器１０２への送信を開始する（Ｓ５０５）。シンク機器１０２は、受信したファイルデータをファイル蓄積部８０４に蓄積する。ここまでの動作は、図５に示す通信シーケンスと同様である。【０１２６】  ここで、ソース機器１０１がＰＯＳＴリクエストを送信する前に、ソース機器１０１において、ユーザによりファイル転送のキャンセル指示がなされる、または、転送対象のファイルが削除されるなどの事象が発生したと想定する。【０１２７】  ソース機器１０１は、ファイル転送を中止するために、ＴＣＰのＲＳＴパケットを送信する（Ｓ１２０６）。これにより、ファイル転送に利用しているＴＣＰ接続が切断される。ソース機器１０１は、さらに、ＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔリクエストをシンク機器１０２に送信する（Ｓ１２０７）。シンク機器１０２は、ＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔリクエストに応じて、受信済みのファイルデータを削除し、ＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔレスポンスをソース機器１０１へ送信する（Ｓ１２０８）。【０１２８】  このように、ファイルデータの送信が開始された後に、ソース機器１０１の都合により、ファイル転送が中止された場合、シンク機器１０２では、受信し保存済みのファイルデータは削除される。つまり、シンク機器１０２において無駄となる、完結していないファイルデータは速やかに削除される。【０１２９】  次に、シンク機器１０２がＰＯＳＴリクエストを受信した際に、シンク機器１０２の都合によりファイル転送が中止される際の各機器の動作を図１３を用いて説明する。【０１３０】  図１３は、実施の形態のファイル転送システムにおいて、ファイルデータの送信が開始される前に、シンク機器１０２の都合によりファイル転送が中止される際の通信シーケンスの一例示す図である。【０１３１】  ソ���ス機器１０１およびシンク機器１０２は、図５の通信シーケンスと同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う。この後、ソース機器１０１は、ＰＯＳＴリクエストをシンク機器１０２に送信する（Ｓ５０３）。ここまでの動作は、図５と同様である。【０１３２】  ここで、シンク機器１０２において、ソース機器１０１からのＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストに応じて作成されたｏｂｊｅｃｔが消失したなどの理由により、ファイル転送を中止する必要が生じた場合を想定する。【０１３３】  この場合、シンク機器１０２は、ＰＯＳＴリクエストへの応答として“４０４  Ｎｏｔ  Ｆｏｕｎｄ”ステータスをソース機器１０１へ送信する（Ｓ１３０４）。ソース機器１０１は、“４０４  Ｎｏｔ  Ｆｏｕｎｄ”に応じてファイル転送に係る処理を中止する。【０１３４】  このように、ソース機器１０１からシンク機器１０２に、ＰＯＳＴリクエストによりファイルサイズ等が通知された後、かつファイルデータの送信が開始される前に、シンク機器１０２の都合により、ファイル転送が中止された場合、ソース機器１０１は、シンク機器１０２からの通知によりファイル転送に係る処理を中止する。つまり、ソース機器１０１は不要な処理を継続することがない。【０１３５】  次に、シンク機器１０２の都合により、ソース機器１０１からシンク機器１０２へのファイルデータの送信中にファイル転送が中止される際の各機器の動作を図１４を用いて説明する。【０１３６】  図１４は、実施の形態のファイル転送システムにおいて、ファイルデータの送信中に、シンク機器の都合によりファイル転送が中止される際の通信シーケンスの一例示す図である。【０１３７】  ソース機器１０１およびシンク機器１０２は、図５と同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う。この後、ソース機器１０１は、ＰＯＳＴリクエストをシンク機器１０２に送付する（Ｓ５０３）。シンク機器１０２は、ＰＯＳＴリクエストへの応答として“１００  Ｃｏｎｔｉｎｕｅ”ステータスをソース機器１０１へ送信する（Ｓ５０４）。ソース機器１０１は、ファイルデータのシンク機器１０２への送信を開始する（Ｓ５０５）。シンク機器１０２は、受信したファイルデータをファイル蓄積部８０４に蓄積する。ここまでの動作は、図５に示す通信シーケンスと同様である。【０１３８】  ここで、シンク機器１０２において、ファイル転送を中止する要因が発生し、ＴＣＰのＲＳＴパケットを送信する（Ｓ１４０６）。これにより、ファイル転送に利用しているＴＣＰ接続が切断される。ソース機器１０１は、ＴＣＰ接続の切断を検出すると、再びＰＯＳＴリクエストをシンク機器１０２に送信する（Ｓ１４０７）。シンク機器は、ＰＯＳＴリクエストへの応答として“４０４  Ｎｏｔ  Ｆｏｕｎｄ”ステータスをソース機器１０１へ送信する（Ｓ１４０８）。ソース機器１０１は“４０４  Ｎｏｔ  Ｆｏｕｎｄ”に応じてファイル転送に係る処理を中止する。【０１３９】  このように、ソース機器１０１からシンク機器１０２へのファイルデータの送信が開始された後に、シンク機器１０２の都合により、ファイル転送が中止された場合、ソース機器１０１は、シンク機器１０２からの通知によりファイル転送に係る処理を中止する。つまり、ソース機器１０１は不要な処理を継続することがない。【０１４０】  このように、本発明の実施の形態のソース機器１０１およびシンク機器１０２は、ファイル転送を中止する場合、その中止がどちらの機器の都合によるものであっても、無駄なリソースの消費および無駄な処理が発生しないように、ファイル転送の中止のための処理が行われる。【０１４１】  なお、上述の実施の形態において、プッシュ型のフロー制御を行うファイル転送プロトコルとしてＨＴＴＰのＰＯＳＴメソッドによりファイル転送を行う場合を説明した。しかしながら、ＰＯＳＴメソッド以外であってもよく、例えば、ＰＵＴメソッドであっても上記効果が失われるものではない。【０１４２】  また、ソース機器１０１は、ファイル転送が中断した場合にシンク機器１０２が参照すべきパラメータとして、図６に示すパラメータをＨＴＴＰリクエストパケットに付加して送付するとした。【０１４３】  このパラメータを付与する具体的な方法として、独自に定義したヘッダをＰＯＳＴリクエストのメッセージヘッダとして含ませる方法がある。【０１４４】  例えば、ＰＯＳＴリクエストに、独自に定義したヘッダであるＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ：［ｂｙｔｅ−ｒａｎｇｅ］を付与し、ＨＴＴＰのＥｎｔｉｔｙ  Ｂｏｄｙ部に含まれるデータの範囲および総サイズを格納する。また、［ｌｉｆｅｔｉｍｅ］等の必要な情報を含ませる。シンク機器１０２は、ソース機器１０１から送信されたＰＯＳＴリクエストのメッセージヘッダから、これらの情報を取得することができる。【０１４５】  また、上述の実施の形態においては、ＰＯＳＴリクエストに［ｂｙｔｅ−ｒａｎｇｅ］、［ｒｅｓｔａｒｔ−ｔｉｍｅ］、および［ｌｉｆｅｔｉｍｅ］の３つのパラメータを付加して送付する構成を説明した。しかしながら［ｒｅｓｔａｒｔ−ｔｉｍｅ］のみを付加してもよい。【０１４６】  なお、ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ以外の、ＨＴＴＰで当然使用されるその他のヘッダについては本発明の特徴に関係しないため図示および説明を省略する。【０１４７】  また、上述の実施の形態において、ソース機器１０１は、ファイルをシンク機器１０２に転送する場合、一括して転送するとした。しかしながら、ソース機器１０１は、ファイルを分割し、分割単位毎にシンク機器１０２に送付することもできる。シンク機器１０２が１回のＰＯＳＴリクエストで受信可能なデータサイズに制限がある場合など、ソース機器１０１が分割単位毎にファイルデータを送信する方法は有効である。【０１４８】  図１５は、ソース機器１０１がシンク機器１０２にファイルを分割して転送するファイル転送システムの通信シーケンスを示す図である。図１５を用いて、ソース機器１０１がファイルを分割して転送する際の各機器の動作を説明する。なお、ソース機器１０１は、送信するファイルデータの範囲等をシンク機器１０２に通知するために、上述の、独自に定義したヘッダＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇを使用すると想定する。【０１４９】  ソース機器１０１はフ��イルの転送に先立って、シンク機器１０２に対しＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを送信する（Ｓ１５０３）。シンク機器１０２は、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストに従い、ｏｂｊｅｃｔを作成し、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスをソース機器１０１に送信する（Ｓ１５０４）。【０１５０】  ソース機器１０１はファイルを分割転送するサイズを決定する。分割転送のサイズは転送の中断、再開の頻度、中断時に無駄になる転送サイズ、分割によるオーバヘッド等を勘案して任意に決定することができる。ここでは１０００バイトのファイルを、最初の０バイト目から４９９バイト目までのファイルデータと、次の５００バイト目から９９９バイト目のファイルデータとに分割する（Ｓ１５０５）。このファイルの分割はソース機器のファイル送信制御部７０２が行う。【０１５１】  ソース機器１０１はファイル転送を開始する。具体的には、ソース機器１０１はＰＯＳＴリクエストを送信する（Ｓ１５０６）。ＰＯＳＴリクエストには、独自に定義したヘッダである、ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ：［ｂｙｔｅ−ｒａｎｇｅ］、［ｌｉｆｅｔｉｍｅ］が含まれる。ここでの［ｂｙｔｅ−ｒａｎｇｅ］は、ヘッダ以下に続くＨＴＴＰのＥｎｔｉｔｙ  Ｂｏｄｙ部に含まれるデータの範囲と、ファイルの総サイズを示す情報であり、データの範囲“０−４９９”とファイルの総サイズである“１０００”が指定される。［ｌｉｆｅｔｉｍｅ］ではコンテンツの保持期間を指定しており、ここでは秒単位で“１８００”つまり、３０分を指定している。【０１５２】  シンク機器１０２は、上記ＰＯＳＴリクエストへの応答として“１００  Ｃｏｎｔｉｎｕｅ”をソース機器１０１へ送信する（Ｓ１５０７）。【０１５３】  ソース機器１０１は、シンク機器１０２に通知したデータ範囲のファイルデータを送信する（Ｓ１５０８）。具体的にはＰＯＳＴリクエストのＥｎｔｉｔｙ  Ｂｏｄｙに当該ファイルデータを格納して送信する。Ｅｎｔｉｔｙ  Ｂｏｄｙに含まれるファイルの範囲は、上述のように“０−４９９”の５００バイト分のみである。【０１５４】  シンク機器１０２はこの５００バイト分のファイルデータを受信するとファイル蓄積部８０４への保存を開始する。保存の開始後、ファイル蓄積部８０４への書き込み速度が遅いなど、概ね２０秒以内に保存を完了できない場合、“１０２  Ｐｒｏｃｅｓｓｉｎｇ”を送信する（Ｓ１５０９）。その後、受信したファイルデータの保存が完了すると（Ｓ１５１０）、“２０１  Ｃｒｅａｔｅｄ”をソース機器１０１へ送信し（Ｓ１５１１）、転送データが保存されたことを通知する。【０１５５】  次に、ソース機器１０１とシンク機器１０２は、上述のソース機器１０１からシンク機器１０２へのＰＯＳＴリクエストの送信（Ｓ１５０６）から、シンク機器１０２からソース機器１０１への保存完了の通知（Ｓ１５１１）と同様の動作シーケンスにより、次の分割単位である５００バイト目から９９９バイト目までのファイルデータの転送を行う（Ｓ１５１２〜Ｓ１５１７）。【０１５６】  即ち、ソース機器１０１は、ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇヘッダの［ｂｙｔｅ−ｒａｎｇｅ］に“５００−９９９／１０００”を格納しシンク機器１０２に通知する。シンク機器１０２はこれを解釈し、その後に受信するファイルデータ（Ｓ１５１５）を、すでに保存されている０バイト目から４９９Ｂｙｔｅ目のファイルデータにアペンドしてファイル蓄積部８０４に保存する。【０１５７】  このようにして、ＰＯＳＴメソッドを用いてファイルを送信するプッシュ型のフロー制御でもファイルを分割して送信を行うことが可能となる。【０１５８】  なお、このようにファイルが分割して転送される場合においても、ファイル転送が中断された場合、ソース機器１０１は、図１０の通信シーケンスに示すように、シンク機器１０２に保存済データサイズを問い合わせることで、送信すべき残りのファイルデータのみを送信する。例えば、図１５の通信シーケンスにおいて、最初の５００バイトの送信中にファイル転送が中断され、それまでにシンク機器１０２に２００バイトが保存されていた場合を想定する。この場合、ソース機器１０１は、シンク機器１０２に問い合わせることにより保存済データサイズが“２００”であることを取得する。その後、ソース機器１０１は残りの３００バイトをシンク機器１０２に送信する。【０１５９】  また、伝送路上のエラー等により、保存済データサイズを取得できなかった場合、送信途中であったファイルデータを再送信する。例えば、図１５の通信シーケンスにおいて、後の５００バイトの送信中にファイル転送が中断され、ソース機器１０１がシンク機器１０２から保存済データサイズを取得できなかった場合、後の５００バイトを最初から送信する。【０１６０】  つまり、最初の５００バイトは、シンク機器１０２からの“２０１  Ｃｒｅａｔｅｄ”によりシンク機器１０２に保存済みであることが確認できているため、ソース機器１０１は、後の５００バイトのみを再送信すればよい。【０１６１】  このように、転送対象のファイルを分割して送信する方法は、上述のように、シンク機器１０２が１回のＰＯＳＴリクエストで受信可能なデータサイズに制限がある場合のみならず、ファイル転送の効率化に対しても有効である。【０１６２】  また、分割されたファイルデータがシンク機器１０２に送信される前にＰＯＳＴリクエストでファイルの総サイズがシンク機器１０２に通知される。そのため、シンク機器１０２は、受信したファイルデータが、あるファイルを構成する一部のファイルデータであるのか、または、あるファイルを構成する全てのファイルデータであるのかが判断できる。【０１６３】  例えば、ファイルデータの送信に先立って通知される［ｂｙｔｅ−ｒａｎｇｅ］が“０−４９９／１０００”であれば、その後に受信したファイルデータはあるファイルを構成する一部のファイルデータであると判断できる。また、［ｂｙｔｅ−ｒａｎｇｅ］が“０−９９９／１０００”であれば、その後に受信したファイルデータはあるファイルを構成する全てのファイルデータであると判断できる。【０１６４】  これにより、例えば、［ｂｙｔｅ−ｒａｎｇｅ］が“０−４９９／１０００”と指定されたファイルデータを受信し保存した後に、残りのファイルデータを受信しない場合、保存済みのファイルデータは完結していないファイルデータであると判断できる。そこで、所定の期間後に削除、またはユーザに保存を継続するかを確認するなどの処置を行うことができる。【０１６５】  受信したファイルデータについては、上述のように、ソース機器１０１から指定される［ｌｉｆｅｔｉｍｅ］に示される保持期間を越えることをもって削除することも可能である。そこで、シンク機器１０２は、［ｌｉｆｅｔｉｍｅ］が指定されていない場合に、上記の［ｂｙｔｅ−ｒａｎｇｅ］に基づく判断により、所定期間の経過後に削除してもよい。また、［ｌｉｆｅｔｉｍｅ］に示される保持期間を越え、かつ、［ｂｙｔｅ−ｒａｎｇｅ］に示される情報から、当該ファイルデータが完結していないファイルデータであると判断できる場合、そのファイルデータを削除してもよい。【０１６６】  なお、これら［ｂｙｔｅ−ｒａｎｇｅ］および［ｌｉｆｅｔｉｍｅ］等をシンク機器１０２へ通知するためのヘッダの名前は、ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ以外のヘッダ名でもかまわない。さらに本実施の形態ではＤｉｇｉｔａｌ  Ｌｉｖｉｎｇ  Ｎｅｔｗｏｒｋ  Ａｌｌｉａｎｃｅ（ＤＬＮＡ）で定義するヘッダ命名手法に従い“．ｄｌｎａ．ｏｒｇ”を接尾語として用い、他の任意のヘッダ名との偶然の一致を回避している。しかしながら、これに限らず、例えばＨＴＴＰの独自拡張ヘッダであることを示す接頭語“Ｘ−”を用いて、“Ｘ−ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ”等と定義してもかまわない。【０１６７】  また、図１５に示す通信シーケンスにおいては１０００バイトのファイルを５００バイトずつ２分割したが、当然にその分割単位に限定されるものではなく、任意の分割が可能である。【０１６８】  また、ソース機器１０１からシンク機器１０２へファイルを分割して転送するファイル転送システムにおいても、ソース機器１０１またはシンク機器１０２の都合によりファイル転送が中断または中止される場合がある。そこで、以下に、分割された１つの断片であるファイルデータの送信前にファイル転送が中断される場合の通信シーケンスおよび各機器の動作を、図１６および図１７を用いて説明する。また、ファイル転送が中止される場合の通信シーケンスおよび各機器の動作を図１８を用いて説明する。【０１６９】  図１６は、ファイルを分割して転送するファイル転送システムにおいて、分割後の１つのファイルデータの送信前に、ソース機器１０１の都合によりファイル転送が中断される場合の通信シーケンスを示す図である。【０１７０】  図１６の通信シーケンスにおいてＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを送信（Ｓ１５０３）してから、転送対象のファイルを分割（Ｓ１５０５）までは、図１５を用いて説明した通りであり説明を省略する。【０１７１】  ここで、ソース機器１０１において、ユーザのキャンセル指示等によりファイルの転送を中断する場合を想定する。この場合、ソース機器１０１は、ＰＯＳＴリクエストのメッセージヘッダに、処理の保留を示す［ｓｕｓｐｅｎｄ］を含むＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇヘッダを格納しシンク機器１０２に送信する（Ｓ１６０６）。【０１７２】  ソース機器１０１は、このＵｐｌｏ��ｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ヘッダに含まれるキーワードである［ｓｕｓｐｅｎｄ］を示すフィールド値によってシンク機器１０２に明示的に中断を通知することができる。なお、この場合、ＰＯＳＴリクエストのＥｎｔｉｔｙ  Ｂｏｄｙは送信されない。また、図１５の通信シーケンスと同様に、［ｌｉｆｅｔｉｍｅ］も上記ヘッダに含まれ、例えば、秒単位で“１８００”、つまり３０分が指定される。【０１７３】  シンク機器１０２は“２００  ＯＫ”を送信し（Ｓ１６０７）、中断を了解したことを示す。【０１７４】  本手順によれば単にＴＣＰ切断などにより中断した場合と比較すると、シンク機器１０２で不要な転送プロセスをスリープさせるなど、適切な対処を行うことができるため、無駄な処理の発生を抑止する効果がある。【０１７５】  なお、転送の再開はＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ヘッダの［ｌｉｆｅｔｉｍｅ］で指定した３０分以内にソース機器１０１が任意に行うことができる。なお、３０分以内にソース機器１０１が転送の再開を行えないような場合、再度ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ｓｕｓｐｅｎｄを送信することにより、転送再開期間の再延長を行うことも可能である。【０１７６】  次に、ファイルを分割して転送するファイル転送システムにおいて、シンク機器１０２がＰＯＳＴリクエストを受信した際に、シンク機器１０２の都合によりファイル転送が中断される場合の各機器の動作を図１７を用いて説明する。【０１７７】  図１７は、ファイルを分割して転送するファイル転送システムにおいて、シンク機器１０２がＰＯＳＴリクエストを受信した際に、シンク機器１０２の都合によりファイル転送が中断される場合の通信シーケンスを示す図である。【０１７８】  図１７の通信シーケンスにおいて、ソース機器１０１が、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを送信（Ｓ１５０３）してから、送信するファイルデータの範囲等をＰＯＳＴリクエストにより通知する（Ｓ１５０６）までは、図１５を用いて説明した通りであり説明を省略する。【０１７９】  ここで、上記ＰＯＳＴリクエスト（Ｓ１５０６）を受信したシンク機器１０２が、ファイル蓄積部８０４からデータを読出し中であるなどの理由により、ファイル転送を行える状態に無い場合を想定する。【０１８０】  この場合、シンク機器１０２は、ＰＯＳＴリクエストへの応答として“５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ”をソース機器１０１へ送信し（Ｓ１７０７）、ファイル転送を行える状態に無いことをソース機器１０１に通知する。【０１８１】  また、シンク機器１０２は、“５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ”を含むレスポンスメッセージにＲｅｔｒｙ−Ａｆｔｅｒ：ヘッダを格納することによって転送を開始できる見込みの時間を通知する。つまり、Ｒｅｔｒｙ−Ａｆｔｅｒ：ヘッダは、ファイル転送を再開する始期を示す情報である。さらに、独自に定義したヘッダであるＵｐｌｏａｄＴｒａｎｓｐｏｒｔＥｘｐｉｒｅＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ヘッダを格納することによって、再開が可能である期間を通知する。【０１８２】  ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＥｘｐｉｒｅＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ヘッダは、ファイル転送を受け入れる終期を示すためのヘッダである。図１７の通信シーケンスでは秒単位で“１８００”、つまり３０分が指定されている。この場合、シンク機器１０２が上記レスポンスメッセージを送信（Ｓ１７０７）してから３０分後まではファイル転送を受け入れることを示す。具体的には、３０分が経過すると、ソース機器１０１からのＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエスト（Ｓ１５０３）に応じて作成されたｏｂｊｅｃｔが削除される。なお、すでに一部のファイルデータを受信し保存した後に、ファイル転送を中断した場合、完結していないファイルデータがファイル蓄積部８０４に保存されているため、そのファイルデータが削除される。【０１８３】  ここで、ＲＦＣ２６１６で定義されるＲｅｔｒｙ−Ａｆｔｅｒ：ヘッダは一般にサービスの再開を保障するものではなく、Ｒｅｔｒｙ−Ａｆｔｅｒ：ヘッダに示される期間より短い間隔でリトライを行ってもサービスが再開できる見込みが薄いことを通知して相手機器のポーリング負荷を抑制するためのものである。【０１８４】  従って、ソース機器１０１はシンク機器１０２に対し、Ｒｅｔｒｙ−Ａｆｔｅｒ：ヘッダにより示される２０分以降、ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＥｘｐｉｒｅＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ヘッダにより示される３０分以内にリトライを行って、転送の再開が可能であるか確認を行い、可能であれば続きのファイルデータの送信を行う。【０１８５】  このように、シンク機器１０２が自身の都合によりファイル転送を中断する場合、Ｒｅｔｒｙ−Ａｆｔｅｒ：ヘッダと、ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＥｘｐｉｒｅＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ヘッダとにより、ソース機器１０１がファイル転送をリトライすべき始期と終期とがソース機器１０１に通知される。【０１８６】  これにより、ソース機器１０１は、無駄なリトライをすることがない。結果として、ソース機器１０１内および伝送路上でのリソースの無駄な使用を防ぐことができる。【０１８７】  次に、ファイルを分割して転送するファイル転送システムにおいて、ファイル転送が中止される場合の一例として、シンク機器１０２の都合によりファイル転送が中止される場合の通信シーケンスおよび各機器の動作を図１８を用いて説明する。【０１８８】  図１８は、ファイルを分割して転送するファイル転送システムにおいて、シンク機器１０２の都合によりファイル転送が中止される場合の通信シーケンスを示す図である。【０１８９】  図１８の通信シーケンスにおいて、ソース機器１０１が、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを送信（Ｓ１５０３）してから、シンク機器１０２が、ファイル転送を行える状態に無いこと等をソース機器１０１に通知する（Ｓ１７０７）までは、図１５および図１７を用いて説明した通りであり説明を省略する。【０１９０】  図１８の通信シーケンスにおいて、シンク機器１０２は、一旦、ファイル転送を中断するための通知（Ｓ１７０７）を行っているが、ソース機器１０１がファイル転送のリトライ（Ｓ１８０８）を行った際に、シンク機器１０２がファイル転送を再開せずに中止したい理由あったと想定する。【０１９１】  この様な理由としては、例えばファイル蓄積部８０４の空き容量がなくなったため、当面転送を再開できる見込みが無い場合や、転送を行うとシンク機器１０２の動作自体に支障をきたす場合などがあげられる。【０１９２】  このような場合、シンク機器１０２は“４０４  Ｎｏｔ  Ｆｏｕｎｄ”を応答として送信し（Ｓ１８０９）、送信先のＵＲＩリソース、つまり、送信されるファイルデータを保存するためのｏｂｊｅｃｔが削除されて最早使用可能で無いことを示す。なお、ソース機器１０１とシンク機器１０２とのタイマーの違いにより、ソース機器１０１が既にシンク機器１０２から削除されたＵＲＩに対してリトライを行った場合にも同様のシーケンスとなる場合がある。【０１９３】  なお、ソース機器１０１からファイル転送を中止する場合、タイムアウトするまで所定のＵＲＩにリトライを行わない方法や、ＵＰｎＰ−ＡＶのＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔを発行してシンク機器１０２から明示的にオブジェクトとそれに関連するＵＲＩを削除する方法などがある。【０１９４】  以上ＵＰｎＰ−ＡＶのオブジェクト単位でファイル転送を管理する例で説明したが、これに限らず、単に所定のＵＲＩに対してファイル送信を行う場合にも適用可能である。【０１９５】  このように、ファイルを分割して転送するファイル転送システムであっても、ファイル転送が中断または中止された場合には、ソース機器１０１またはシンク機器１０２が中断または中止を相手機器に通知することができる。これにより、中断または中止を通知された機器は、無駄となるファイル転送のための処理を継続することがない。【０１９６】  なお、ＨＴＴＰのＰＯＳＴメソッドによりファイルを送信する場合を説明したが、これに限らず、ＰＵＴメソッド、さらには同様のハンドシェイクシーケンスが適用可能なＨＴＴＰ以外のファイル転送プロトコルへも適用が可能である。【０１９７】  また、図１６〜図１８では、分割後のファイルデータが１回も送信されることなく、ファイル転送が中断または中止される場合の通信シーケンスを示している。しかしながら、図１６〜図１８を用いて説明したファイル転送の中断または中止の際の各機器の動作は、１回以上ファイルデータが送信された後、かつ、次のファイルデータが送信される前に中断または中止される場合でも同じである。
【産業上の利用可能性】
【０１９８】  本発明の送信機器、受信機器、およびファイル転送システム、は、ネットワークに接続される任意の機器間でファイルを転送するファイル転送システムにおいて有用である。特にファイルのサイズが大きく、転送を中断して再開する際に、転送を初めからやり直すと無駄が多い場合に効果を発揮する。
【図１】
2006046446.tif 000002
【図２】
2006046446.tif 000003
【図３】
2006046446.tif 000004
【図４】
2006046446.tif 000005
【図５】
2006046446.tif 000006
【図６】
2006046446.tif 000007
【図７】
2006046446.tif 000008
【図８】
2006046446.tif 000009
【図９】
2006046446.tif 000010
【図１０】
2006046446.tif 000011
【図１１】
2006046446.tif 000012
【図１２】
2006046446.tif 000013
【図１３】
2006046446.tif 000014
【図１４】
2006046446.tif 000015
【図１５】
2006046446.tif 000016
【図１６】
2006046446.tif 000017
【図１７】
2006046446.tif 000018
【図１８】
2006046446.tif 000019
【手続補正書】
【提出日】平成18年3月30日(2006.3.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求の範囲
【補正方法】変更
【補正の内容】
【書類名】請求の範囲
【請求項１】（削除）
【請求項２】（削除）
【請求項３】（補正後）ネットワークを介し、ファイルを送信する送信機器から前記ファイルを受信する受信機器へのファイル転送を行うファイル転送システムであって、
前記受信機器は、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備え、
前記送信機器は、
ファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の中断を検出する検出手段と、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に前記保存済サイズを問い合わせる問合せ手段と、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備え、
前記送信制御手段は、更に、前記送信手段がファイルデータを送信する前に、前記ファイルデータの前記ファイルにおける範囲であるデータ範囲を前記受信機器に通知し、
前記受信機器は、更に、前記データ範囲に基づき、前記保存手段に保存されているファイルデータと、前記データ範囲が通知された後に受信したファイルデータとを結合するファイル制御手段を備える
ファイル転送システム。
【請求項４】（補正後）前記送信制御手段は、前記データ範囲とともに前記ファイルの総サイズを前記受信機器に通知する
請求項３記載のファイル転送システム。
【請求項５】前記送信制御手段は、更に、前記ファイルを所定のサイズのファイルデータに分割し、
前記送信手段は、前記送信制御手段により分割されたファイルデータを前記受信機器に送信する
請求項４記載のファイル転送システム。
【請求項６】（補正後）ネットワークを介し、ファイルを送信する送信機器から前記ファイルを受信する受信機器へのファイル転送を行うファイル転送システムであって、
前記受信機器は、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備え、
前記送信機器は、
ファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の中断を検出する検出手段と、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に前記保存済サイズを問い合わせる問合せ手段と、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備え、
前記受信制御手段は、更に、ファイル転送の中断を要求する中断要求を前記送信機器へ送信し、
前記中断要求は、前記受信機器が前記ファイル転送を再開する始期を示す始期情報と、前記受信機器が前記ファイル転送を受け入れる終期を示す期間情報とを含み、
前記検出手段は、前記中断要求を受信することで前記ファイル転送の中断を検出し、
前記送信制御手段は、前記始期から前記終期の間に前記残りのファイルデータを前記送信手段に送信させる
ファイル転送システム。
【請求項７】（補正後）ネットワークを介し、ファイルを送信する送信機器から前記ファイルを受信する受信機器へのファイル転送を行うファイル転送システムであって、
前記受信機器は、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備え、
前記送信機器は、
ファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の中断を検出する検出手段と、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に前記保存済サイズを問い合わせる問合せ手段と、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備え、
前記送信制御手段は、更に、前記送信手段がファイルデータを送信する前に、前記ファイルデータの前記受信機器における保持期間を前記受信機器に通知し、
前記受信制御手段は、更に、前記ファイルデータが前記保存手段に保存され、かつ、前記ファイルデータの保持期間が経過する前に、前記ファイルを構成する全てのファイルデータを前記送信機器から受信しない場合、前記保存手段に保存されている前記ファイルデータを削除する
ファイル転送システム。
【請求項８】（削除）
【請求項９】（補正後）ネットワークを介し、ファイルを送信する送信機器から前記ファイルを受信する受信機器へのファイル転送を行うファイル転送システムであって、
前記受信機器は、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備え、
前記送信機器は、
ファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の中断を検出する検出手段と、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に前記保存済サイズを問い合わせる問合せ手段と、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備え、
前記送信機器と前記受信機器とはＴｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続によりファイル転送を行い、
前記送信制御手段は、更に、前記ＴＣＰ接続が前記受信機器により切断されると、ファイル転送の許可を得るための転送要求を前記受信機器に送信し、
前記受信制御手段は、更に、前記転送要求への応答として前記ファイル転送の中断を要求する中断要求を前記送信機器に送信し、
前記検出手段は、前記中断要求を受信することにより前記ファイル転送の中断を検出する
ファイル転送システム。
【請求項１０】（補正後）ネットワークを介し、受信機器へファイルを転送するファイル転送を行う送信機器であって、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の中断を検出する検出手段と、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に保存されているファイルデータのサイズである保存済サイズを問い合わせる問合せ手段と、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備え、
前記送信制御手段は、更に、前記送信手段がファイルデータを送信する前に、前記ファイルデータの前記ファイルにおける範囲であるデータ範囲を前記受信機器に通知する
送信機器。
【請求項１１】（補正後）ネットワークを介し、送信機器から送信されるファイルを受信する受信機器であって、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段と、
前記送信機器からファイルデータの前記ファイルにおける範囲であるデータ範囲を受信し、受信した前記データ範囲に基づき、前記保存手段に保存されているファイルデータと、前記データ範囲が通知された後に受信したファイルデータとを結合するファイル制御手段と
を備える受信機器。
【請求項１２】（補正後）ネットワークを介し、受信機器へファイルを転送するファイル転送を行うための送信方法であって、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと、
前記ファイル転送の中断を検出する検出ステップと、
前記検出ステップにおいて前記ファイル転送の中断が検出された後に、前記受信機器に保存されているファイルデータのサイズである保存済サイズを問い合わせる問合せステップと、
前記問合せステップにおける問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記受信機器に送信する送信制御ステップと、
前記送信ステップにおいて前記ファイルデータが送信される前に、前記ファイルデータの前記ファイルにおける範囲であるデータ範囲を前記受信機器に通知する通知ステップと、
を含む送信方法。
【請求項１３】（補正後）ネットワークを介し、送信機器から送信されるファイルを受信するための受信方法であって、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存手段に保存する保存ステップと、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得ステップと、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得ステップにおいて取得された前記保存済サイズを前記送信機器に送信する受信制御ステップと、
前記送信機器からファイルデータの前記ファイルにおける範囲であるデータ範囲を受信し、受信した前記データ範囲に基づき、前記保存手段に保存されているファイルデータと、前記データ範囲が通知された後に受信したファイルデータとを結合する結合ステップと
を含む受信方法。
【請求項１４】（補正後）ネットワークを介し、受信機器へファイルを転送するファイル転送を行うためのプログラムであって、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと、
前記ファイル転送の中断を検出する検出ステップと、
前記検出ステップにおいて前記ファイル転送の中断が検出された後に、前記受信機器に保存されているファイルデータのサイズである保存済サイズを問い合わせる問合せステップと、
前記問合せステップにおける問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記受信機器に送信する送信制御ステップと、
前記送信ステップにおいて前記ファイルデータが送信される前に、前記ファイルデータの前記ファイルにおける範囲であるデータ範囲を前記受信機器に通知する通知ステップと、
をコンピュータに実行させるためのプログラム。
【請求項１５】（補正後）ネットワークを介し、送信機器から送信されるファイルを受信するためのプログラムであって、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存手段に保存する保存ステップと、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得ステップと、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得ステップにおいて取得された前記保存済サイズを前記送信機器に送信する受信制御ステップと
前記送信機器からファイルデータの前記ファイルにおける範囲であるデータ範囲を受信し、受信した前記データ範囲に基づき、前記保存手段に保存されているファイルデータと、前記データ範囲が通知された後に受信したファイルデータとを結合する結合ステップと
をコンピュータに実行させるためのプログラム。
４４
【手続補正書】
【提出日】平成19年3月12日(2007.3.12)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークを介し、ファイルを送信する送信機器から前記ファイルを受信する受信機器へのファイル転送を行うファイル転送システムであって、
前記受信機器は、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備え、
前記送信機器は、
ファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の中断を検出する検出手段と、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に前記保存済サイズを問い合わせる問合せ手段と、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備え、
前記送信制御手段は、更に、前記送信手段がファイルデータを送信する前に、前記ファイルデータの前記ファイルにおける範囲であるデータ範囲を前記受信機器に通知し、
前記受信機器は、更に、前記データ範囲に基づき、前記保存手段に保存されているファイルデータと、前記データ範囲が通知された後に受信したファイルデータとを結合するファイル制御手段を備える
ファイル転送システム。
【請求項２】
前記送信制御手段は、前記データ範囲とともに前記ファイルの総サイズを前記受信機器に通知する
請求項１記載のファイル転送システム。
【請求項３】
前記送信制御手段は、更に、前記ファイルを所定のサイズのファイルデータに分割し、
前記送信手段は、前記送信制御手段により分割されたファイルデータを前記受信機器に送信する
請求項２記載のファイル転送システム。
【請求項４】
ネットワークを介し、ファイルを送信する送信機器から前記ファイルを受信する受信機器へのファイル転送を行うファイル転送システムであって、
前記受信機器は、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備え、
前記送信機器は、
ファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の中断を検出する検出手段と、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に前記保存済サイズを問い合わせる問合せ手段と、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備え、
前記受信制御手段は、更に、ファイル転送の中断を要求する中断要求を前記送信機器へ送信し、
前記中断要求は、前記受信機器が前記ファイル転送を再開する始期を示す始期情報と、前記受信機器が前記ファイル転送を受け入れる終期を示す期間情報とを含み、
前記検出手段は、前記中断要求を受信することで前記ファイル転送の中断を検出し、
前記送信制御手段は、前記始期から前記終期の間に前記残りのファイルデータを前記送信手段に送信させる
ファイル転送システム。
【請求項５】
ネットワークを介し、ファイルを送信する送信機器から前記ファイルを受信する受信機器へのファイル転送を行うファイル転送システムであって、
前記受信機器は、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備え、
前記送信機器は、
ファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の中断を検出する検出手段と、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に前記保存済サイズを問い合わせる問合せ手段と、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備え、
前記送信制御手段は、更に、前記送信手段がファイルデータを送信する前に、前記ファイルデータの前記受信機器における保持期間を前記受信機器に通知し、
前記受信制御手段は、更に、前記ファイルデータが前記保存手段に保存され、かつ、前記ファイルデータの保持期間が経過する前に、前記ファイルを構成する全てのファイルデータを前記送信機器から受信しない場合、前記保存手段に保存されている前記ファイルデータを削除する
ファイル転送システム。
【請求項６】
ネットワークを介し、ファイルを送信する送信機器から前記ファイルを受信する受信機器へのファイル転送を行うファイル転送システムであって、
前記受信機器は、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備え、
前記送信機器は、
ファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の中断を検出する検出手段と、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に前記保存済サイズを問い合わせる問合せ手段と、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備え、
前記送信機器と前記受信機器とはＴｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ（ＴＣＰ）接続によりファイル転送を行い、
前記送信制御手段は、更に、前記ＴＣＰ接続が前記受信機器により切断されると、ファイル転送の許可を得るための転送要求を前記受信機器に送信し、
前記受信制御手段は、更に、前記転送要求への応答として前記ファイル転送の中断を要求する中断要求を前記送信機器に送信し、
前記検出手段は、前記中断要求を受信することにより前記ファイル転送の中断を検出する
ファイル転送システム。
【請求項７】
ネットワークを介し、受信機器へファイルを転送するファイル転送を行う送信機器であって、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、
前記ファイル転送の中断を検出する検出手段と、
前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に保存されているファイルデータのサイズである保存済サイズを問い合わせる問合せ手段と、
前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備え、
前記送信制御手段は、更に、前記送信手段がファイルデータを送信する前に、前記ファイルデータの前記ファイルにおける範囲であるデータ範囲を前記受信機器に通知する
送信機器。
【請求項８】
ネットワークを介し、送信機器から送信されるファイルを受信する受信機器であって、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段と、
前記送信機器からファイルデータの前記ファイルにおける範囲であるデータ範囲を受信し、受信した前記データ範囲に基づき、前記保存手段に保存されているファイルデータと、前記データ範囲が通知された後に受信したファイルデータとを結合するファイル制御手段と
を備える受信機器。
【請求項９】
ネットワークを介し、受信機器へファイルを転送するファイル転送を行うための送信方法であって、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと、
前記ファイル転送の中断を検出する検出ステップと、
前記検出ステップにおいて前記ファイル転送の中断が検出された後に、前記受信機器に保存されているファイルデータのサイズである保存済サイズを問い合わせる問合せステップと、
前記問合せステップにおける問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記受信機器に送信する送信制御ステップと、
前記送信ステップにおいて前記ファイルデータが送信される前に、前記ファイルデータの前記ファイルにおける範囲であるデータ範囲を前記受信機器に通知する通知ステップと、
を含む送信方法。
【請求項１０】
ネットワークを介し、送信機器から送信されるファイルを受信するための受信方法であって、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存手段に保存する保存ステップと、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得ステップと、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得ステップにおいて取得された前記保存済サイズを前記送信機器に送信する受信制御ステップと、
前記送信機器からファイルデータの前記ファイルにおける範囲であるデータ範囲を受信し、受信した前記データ範囲に基づき、前記保存手段に保存されているファイルデータと、前記データ範囲が通知された後に受信したファイルデータとを結合する結合ステップと
を含む受信方法。
【請求項１１】
ネットワークを介し、受信機器へファイルを転送するファイル転送を行うためのプログラムであって、
前記ファイルを構成するファイルデータを前記受信機器に送信する送信ステップと、
前記ファイル転送の中断を検出する検出ステップと、
前記検出ステップにおいて前記ファイル転送の中断が検出された後に、前記受信機器に保存されているファイルデータのサイズである保存済サイズを問い合わせる問合せステップと、
前記問合せステップにおける問い合わせに応じて前記受信機器が応答した保存済サイズに基づき、前記ファイルを構成する残りのファイルデータを前記受信機器に送信する送信制御ステップと、
前記送信ステップにおいて前記ファイルデータが送信される前に、前記ファイルデータの前記ファイルにおける範囲であるデータ範囲を前記受信機器に通知する通知ステップと、
をコンピュータに実行させるためのプログラム。
【請求項１２】
ネットワークを介し、送信機器から送信されるファイルを受信するためのプログラムであって、
前記送信機器から受信する、前記ファイルを構成するファイルデータを保存手段に保存する保存ステップと、
前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得ステップと、
前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得ステップにおいて取得された前記保存済サイズを前記送信機器に送信する受信制御ステップと
前記送信機器からファイルデータの前記ファイルにおける範囲であるデータ範囲を受信し、受信した前記データ範囲に基づき、前記保存手段に保存されているファイルデータと、前記データ範囲が通知された後に受信したファイルデータとを結合する結合ステップと
をコンピュータに実行させるためのプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワークを介してファイル転送を行うための送信機器、受信機器およびファイル転送システムに関する。
【背景技術】
【０００２】
近年、ｘＤＳＬや光ファイバーなどのブロードバンド環境が整ったことにより、企業、一般家庭を問わずインターネット接続が急速に普及してきている。また、家庭内のパーソナルコンピュータ（ＰＣ）や家電機器をＥｔｈｅｒｎｅｔ（登録商標）や無線ＬＡＮなどで接続するホームネットワーク環境も一般化してきている。この様な状況の中で、ＰＣだけでなく、テレビやＤＶＤレコーダ、エアコン、冷蔵庫のような家電もＩｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）により定義されるＩｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ（ＩＰ）により相互に接続できるようになってきている。
【０００３】
インターネットやホームネットワークにおけるアプリケーションプログラムの１つとして、家電機器、ＰＣ間でファイルを転送するアプリケーションプログラムがある。ファイルを転送するアプリケーションプログラムの例として、ＤＶＤレコーダに録画したＴＶ番組を編集するためにＰＣに転送したり、ＤＶＤレコーダ間で録画したＭＰＥＧ２ファイルを転送するなどのダビング機能を提供するアプリケーションプログラムがある。
【０００４】
この様なファイル転送を行うプロトコルでは一般的に、ファイルの転送が誤り無く行われることが要求される一方で、リアルタイムの転送は必ずしも要求されない。ＩＰにおいてファイル転送を行う代表的なプロトコルとしては、ＲＦＣ２６１６で定義されるＨｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）や、ＲＦＣ９５９で定義されるＦｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＦＴＰ）等が存在する。これらのプロトコルはいずれもＲＦＣ７９３で定義されるＴｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ（ＴＣＰ）の再送機能によって転送の信頼性を確保している。
【０００５】
すなわち、ＴＣＰはパケットのエラーを検出して再送する手順と、欠落したパケットを検出して再送する手順を含んでおり、そのために伝送路上でエラーやパケット欠落が起こっても正しいファイルの転送が保障できる。一方でＴＣＰの再送手順には限界もあり、例えば伝送路の障害や、送信元の機器（以下、「ソース機器」という。）や、受信先の機器（以下、「シンク機器」という。）の都合により転送の中断が長時間に渡った場合、ＴＣＰ接続がタイムアウトにより切断されてしまい、それ以後のファイル転送が行えなくなるという課題が存在した。ここでの機器の都合には障害のほか、機器の他の機能を実行するためにファイル転送を中断せざるを得ない場合を含む。例えば、ＤＶＤレコーダがタイマー録画を実行するためにファイル転送を中断する場合などが挙げられる。
【０００６】
ＨＴＴＰには上述の課題を解決するための手順が含まれており、転送の中断が任意の長時間に渡った場合でも、再度ＴＣＰ接続を行って、中断前に転送した位置の直後からファイル転送を再開できるシーケンスが定義されている。本シーケンスを図１を用いて説明する。
【０００７】
図１は、従来のソース機器およびシンク機器により構成されるファイル転送システムにおけるファイル転送の再開に係る通信シーケンスの一例を示す図である。
【０００８】
図１に示す通信シーケンスは、ソース機器１００１からシンク機器１００２に対してファイル転送を行うためのファイル転送システムにおける通信シーケンスである。また、ファイル転送の途中でＴＣＰ接続が切断される場合を想定している。
【０００９】
まず、シンク機器１００２はソース機器１００１に対し、ＨＴＴＰ  ＧＥＴリクエストを発行する（Ｓ１０１）。ソース機器１００１は本リクエストに対し、“２００  ＯＫ”を応答し（Ｓ１０２）、１０００バイトのファイルを送信する（Ｓ１０３）。その後、通信障害が発生し、ＴＣＰ接続が切断される（Ｓ１０４）。
【００１０】
ここで、ＴＣＰ接続が切断されるまでにシンク機器１００２には５００バイトのデータが保存できていたと想定する（Ｓ１０５）。シンク機器１００２は、通信障害が回復するのを待ち、任意の時点でＴＣＰの再接続を行い、転送を再開することができる。転送の再開はシンク機器１００２がソース機器１００１に対し、Ｒａｎｇｅヘッダを追加したＨＴＴＰ  ＧＥＴリクエストを送信し（Ｓ１０６）、転送対象のファイルの先頭から５００バイト目以降のデータを要求することにより行われる。
【００１１】
ソース機器１００１は、シンク機器１００２から指定されたＲａｎｇｅ（ここでは５００−９９９バイト目である。）に従ってデータを送信し（Ｓ１０７、Ｓ１０８）、シンク機器１００２は受信したデータを保存する（Ｓ１０９）。これにより、転送済みのデータを再送することなく、未転送のデータのみを転送の再開によって取得することが可能である。この様な手順が、例えばインターネット上のサーバに配置される数メガバイト以上もの大きなファイルのダウンロードが失敗した場合に、取得済みのデータの続きから取得することで効率よくファイルを取得するアプリケーションプログラムで使用されている。
【００１２】
ＨＴＴＰのＧＥＴメソッドを利用し、データの提供を行う技術についても開示されている（例えば、特許文献１参照）。
【特許文献１】特開２００２−２８８１６２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
しかしながら、上記従来のＨＴＴＰのファイル転送の中断、再開手順は、ＨＴＴＰのＧＥＴメソッドでは使用できるがＰＯＳＴメソッドでは使用できないという課題が存在する。インターネット上のサーバからＰＣにファイルをダウンロードする場合はＨＴＴＰのＧＥＴメソッドが使用されるためこの様な制約は問題にはならない。
【００１４】
しかし、ネットワークに接続される任意の機器間でファイルを転送する場合において、ソース機器が任意のファイルをシンク機器の要求なしに自発的に送信しようとする場合は通常ＨＴＴＰ  ＰＯＳＴメソッドが用いられる。そのため、ソース機器とシンク機器との間の通信が中断した場合には、通信の再開後にファイルの送信を最初から行わなければならず、ファイル転送のためのリソースや時間を無駄に消費するという課題がある。
【００１５】
この課題はより一般的にいうと、ソース側から自発的にデータを送信することをトリガとしてプッシュ型のフロー制御を行うファイル転送プロトコルにおいては、シンク側からリクエストを発行するプル型のフロー制御と異なり、通信の中断があった場合に、効率的なファイル転送を行う手順が存在しなかったという課題である。
【００１６】
さらに、前述のＨＴＴＰのＧＥＴメソッドにおけるファイル転送の中断、再開手順においても、再開の可能な期間が規定されておらず、従ってサーバ上に長期間公開されるファイルを不特定多数のＰＣがダウンロードする用途には適するが、ネットワークに接続される任意の機器間でファイルを転送する場合において、ソース機器およびシンク機器がいつまで再開を可能な状態に維持すべきか明確で無い。そのため、ソース機器およびシンク機器においてリソースの無駄が生じることとなる。
【００１７】
本発明は、上記課題を考慮し、送信機器から自発的に受信機器へファイルを転送するファイル転送システムにおいて、ファイル転送が長時間にわたり中断される場合であっても、ファイル転送に係る処理を効率的に実行するための送信機器、受信機器およびファイル転送システムを提供することを目的とする。
【課題を解決するための手段】
【００１８】
上記目的を達成するために、本発明のファイル転送システムは、ネットワークを介し、ファイルを送信する送信機器から前記ファイルを受信する受信機器へのファイル転送を行うファイル転送システムであって、前記受信機器は、前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備え、前記送信機器は、ファイルデータを前記受信機器に送信する送信手段と、前記ファイル転送の中断を検出する検出手段と、前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に前記保存済データサイズを問い合わせる問合せ手段と、前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済データサイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備える。
【００１９】
また、本発明の送信機器は、ネットワークを介し、受信機器へファイルを転送するファイル転送を行う送信機器であって、前記ファイルを構成するファイルデータを前記受信機器に送信する送信手段と、前記ファイル転送の中断を検出する検出手段と、前記検出手段により前記ファイル転送の中断が検出された後に、前記受信機器に保存されているファイルデータのサイズである保存済データサイズを問い合わせる問合せ手段と、前記問合せ手段による問い合わせに応じて前記受信機器が応答した保存済データサイズに基づき、前記ファイルを構成する残りのファイルデータを前記送信手段に送信させる送信制御手段とを備える。
【００２０】
また、本発明の受信機器は、ネットワークを介し、送信機器から送信されるファイルを受信する受信機器であって、前記送信機器から受信する、前記ファイルを構成するファイルデータを保存する保存手段と、前記保存手段に保存済みのファイルデータのサイズである保存済サイズを取得する保存済サイズ取得手段と、前記送信機器から前記保存済サイズを問い合わせられると、前記保存済サイズ取得手段により取得された前記保存済サイズを前記送信機器に送信する受信制御手段とを備える。
【００２１】
このように、本発明によれば、送信機器は、ファイル転送の中断後、受信機器に保存済サイズを問い合わせることができる。また受信機器は、その問い合わせへの応答として保存済サイズを送信機器に送信することができる。送信機器は、保存済サイズを知らされることにより、受信機器に送信すべき残りのファイルデータのみを送信することができる。
【００２２】
つまり、中断されたファイル転送の再開に際し、送信機器は、ファイルデータの送信を最初から行う必要がなく、受信機器にとって必要な残りのファイルデータのみを送信すればよい。また、受信機器は、重複する無駄なファイルデータを受信することがない。従って、送信機器および受信機器におけるファイル転送に係る処理において、長時間にわたる中断が発生した場合においても、無駄な処理やリソースの無駄な消費が発生することがなく、ファイル転送に係る処理を効率的に実行することができる。
【００２３】
また、本発明のファイル転送システムにおいて、前記受信制御手段は、更に、ファイル転送の中断を要求する中断要求を前記送信機器へ送信し、前記中断要求は、前記受信機器が前記ファイル転送を再開する始期を示す始期情報と、前記受信機器が前記ファイル転送を受け入れる終期を示す期間情報とを含み、前記検出手段は、前記中断要求を受信することで前記ファイル転送の中断を検出し、前記送信制御手段は、前記始期から前記許可期間の間に前記残りのファイルデータを前記送信手段に送信させるとしてもよく、また、本発明のファイル転送システムにおいて、前記送信制御手段は、更に、前記送信手段がファイルデータを送信する前に、前記ファイルデータの前記受信機器における保持期間を前記受信機器に通知し、前記受信制御手段は、更に、前記ファイルデータが前記保存手段に保存され、かつ、前記ファイルデータの保持期間が経過する前に、前記ファイルを構成する全てのファイルデータを前記送信機器から受信しない場合、前記保存手段に保存されている前記ファイルデータを削除するとしてもよい。
【００２４】
このように、送信機器と受信機器とは互いに、ファイル転送を行う期間についての情報をやりとりすることができる。これにより、送信機器および受信機器のそれぞれは、相手機器によりファイル転送が中断された場合、いつまでもファイル転送の再開に備えておく必要がなく、それぞれの機器のリソースを無駄に消費することがない。つまり、ファイル転送に係る処理を効率的に実行することができる。
【００２５】
更に、本発明は、本発明のファイル転送システム、送信機器および受信機器それぞれの特徴的な構成部をステップとする方法として実現したり、それらのステップを含むプログラムとして実現したり、そのプログラムが格納された、ＣＤ−ＲＯＭ等の記録媒体として実現したり、集積回路として実現することもできる。プログラムは、通信ネットワーク等の伝送媒体を介して流通させることもできる。
【発明の効果】
【００２６】
本発明は、送信機器から自発的に受信機器へファイルを転送するファイル転送システムにおいて、ファイル転送が長時間にわたり中断される場合であっても、ファイル転送に係る処理を効率的に実行するための送信機器、受信機器およびファイル転送システムを提供することができる。
【００２７】
例えば、ファイルをＨＴＴＰのＰＯＳＴメソッドを用いて送信するソース機器と、ソース機器からファイルを受信するシンク機器とにより構成されるファイル転送システムにおいて、ファイル転送の中断が発生し、ＴＣＰ接続がタイムアウトした後であっても、送信機器は保存済みのデータサイズを知ることができる。従って、送信機器は、受信機器おいて保存済みのデータに続くデータを受信機器に転送することができる。
【００２８】
つまり、あるファイルを転送する場合、送信機器においては、無駄なデータ送信を行うことがなく、受信機器においては、無駄なデータを受信することがない。
【００２９】
結果として、ソース側からデータを送送信することをトリガとしてプッシュ型のフロー制御を行うファイル転送プロトコルにおいても、リソースや時間などの無駄を発生させることなく、ファイル転送に係る処理を効率的に実行することができる。
【００３０】
更に、中断、再開手順において再開の可能な期間をハンドシェイクする方法および手段を提供し、ソース機器およびシンク機器がいつまで再開を可能な状態に維持すべきか明確にすることができる。これにより、ファイル転送におけるソース機器およびシンク機器のメモリやメディア等のリソースにおける無駄を無くすことができる。このことによってもファイル転送に係る処理を効率的に実行することができる。
【発明を実施するための最良の形態】
【００３１】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
まず、本発明の実施の形態のファイル転送システムの構成を図２〜図４を用いて説明する。
【００３２】
図２は、本発明の実施の形態のファイル転送システムの機器構成を示す図である。本発明の実施の形態のファイル転送システムは、ソース機器１０１からシンク機器１０２へファイルを転送するためのシステムである。
【００３３】
図２に示すように、ソース機器１０１およびシンク機器１０２はブロードバンドルータ３０１に接続されてホームネットワークを構成する。ブロードバンドルータ３０１はインターネット３０２に接続されていても良い。
【００３４】
ソース機器１０１とシンク機器１０２は各々蓄積メディアを内蔵し、Ａｕｄｉｏ  Ｖｉｓｕａｌ（ＡＶ）コンテンツ等のファイルを蓄積することができる。具体的には、ソース機器１０１は、ファイル蓄積部７０５を備え、シンク機器１０２は、ファイル蓄積部８０４を備える。
【００３５】
この様な機器の例としてネットワーク接続端子を備えたＤＶＤ／ＨＤＤハイブリッドレコーダなどが上げられる。本実施の形態の初期状態ではソース機器１０１がファイル蓄積部７０５にファイル３０３を蓄積しており、本ファイルをホームネットワークを介してシンク機器１０２に転送する。シンク機器１０２はソース機器から受信したファイル３０３をファイル蓄積部８０４に蓄積する。
【００３６】
なお、本実施の形態ではシンク機器１０２、ソース機器１０１ともにユニバーサルプラグアンドプレイフォーラムの発行するＵＰｎＰ−ＡＶ規格に準拠しており、シンク機器１０２はＣｏｎｔｅｎｔｓ  Ｄｉｒｅｃｔｏｒｙ  Ｓｅｒｖｉｃｅ（ＣＤＳ）サーバ機能を実装しており、ソース機器１０１はＣＤＳサーバにアクセスするＣｏｎｔｒｏｌ  Ｐｏｉｎｔ機能を実装しているものとする。
【００３７】
図３は、本発明の実施の形態のソース機器１０１の機能的な構成を示す機能ブロック図である。ソース機器１０１は、本発明の送信機器の一例である。なお、ソース機器１０１について、本来備えられているＣｏｎｔｒｏｌ  Ｐｏｉｎｔ機能等の図示および説明は省略し、ソース機器１０１において特徴的な構成部についてのみ図示および説明を行なう。
【００３８】
図３に示すように、ソース機器１０１は、ユーザインターフェース７０１、ファイル送信制御部７０２、ファイル制御部７０３、通信制御部７０４、ファイル蓄積部７０５、およびネットワークインターフェース７０６を備える。図中の点線で囲まれた領域にある構成部は、ファイル転送に係る主要な処理を行う構成部である。
【００３９】
ユーザインターフェース７０１は、ユーザからの指示等の入力を受け付け、また、ユーザに映像等で情報を提供するインターフェースである。ネットワークインターフェース７０６は、ホームネットワークを介してシンク機器１０２との情報のやり取りを行うインターフェースである。
【００４０】
ファイル蓄積部７０５は、上述のように、ＡＶコンテンツ等のファイルを蓄積する記憶装置である。
【００４１】
ファイル送信制御部７０２は、ファイルのシンク機器１０２への送信を制御する制御部であり、問合せ部７０８を有する。問合せ部７０８は、中断されたファイル転送を再開する際に、シンク機器１０２に、保存済データサイズを問い合わせる処理部である。
【００４２】
なお、上記の保存済データサイズとは、ソース機器１０１からシンク機器１０２へのファイル転送において、シンク機器１０２が受信し保存した、当該ファイルを構成するファイルデータ（以下、単に「データ」ともいう。）の容量のことを指す。つまり、ファイルサイズが１０００バイトである場合、保存済データサイズは０バイトから１０００バイトの間の値となる。
【００４３】
また、「ファイル転送の中断」とは、ファイルデータの送信が開始されて以降にファイルデータの送信または受信が中断される場合だけでなく、ファイル転送に必要な処理が中断される場合も含む。
【００４４】
ファイル制御部７０３は、ファイル蓄積部７０５からのファイルの読出しを制御する制御部である。
【００４５】
通信制御部７０４は、ネットワークインターフェース７０６を制御することでホームネットワークを介した通信を制御する制御部である。通信制御部７０４とネットワークインターフェース７０６とにより本発明の送信機器における送信手段が有する、情報を送信する機能が実現される。また、通信制御部７０４は、中断検出部７０７を有する。中断検出部７０７は、ファイル転送の中断を検出する処理部である。
【００４６】
ソース機器１０１は、ユーザインターフェース７０１を制御して７０５に蓄積したファイルの一覧リストを表示する。ユーザが一覧リストの中から選択したファイルを、ファイル蓄積部７０５から読出し、ネットワークインターフェース７０６を制御して、シンク機器１０２に送付する。
【００４７】
図４は、本発明の実施の形態のシンク機器１０２の機能的な構成を示す機能ブロック図である。シンク機器１０２は、本発明の受信機器の一例である。なお、シンク機器１０２について、本来備えられているＣＤＳサーバ機能等の図示および説明は省略し、シンク機器１０２において特徴的な構成部についてのみ図示および説明を行なう。
【００４８】
図４に示すように、シンク機器１０２は、ファイル受信制御部８０１、ファイル制御部８０２、通信制御部８０３、ファイル蓄積部８０４、およびネットワークインターフェース８０５を備える。図中の点線で囲まれた領域にある構成部は、ファイル転送に係る主要な処理を行う構成部である。
【００４９】
ネットワークインターフェース８０５は、ホームネットワークを介してソース機器１０１との情報のやり取りを行うインターフェースである。
【００５０】
ファイル蓄積部８０４は、本発明の受信機器における保存手段の一例であり、上述のように、ソース機器１０１から受信するファイルを蓄積する記憶装置である。
【００５１】
ファイル受信制御部８０１は、ソース機器１０１から送信されるファイルの受信を制御する制御部である。
【００５２】
ファイル制御部８０２は、ファイル蓄積部８０４からのファイルの読出しを制御する制御部であり、保存済サイズ取得部８０６を有する。保存済サイズ取得部８０６は、ファイル蓄積部８０４から保存済データサイズを取得する処理部である。取得された保存済データサイズは、ファイル受信制御部８０１の制御により、ソース機器１０１へ送信される。
【００５３】
通信制御部８０３は、ネットワークインターフェース８０５を制御することでホームネットワークを介した通信を制御する制御部である。
【００５４】
次に、以上のように構成されたソース機器１０１およびシンク機器１０２により構成されるファイル転送システムにおけるソース機器１０１およびシンク機器１０２の動作を図５から図１４を参照して説明する。
【００５５】
まず、基本の通信シーケンスにおける各機器の動作を図５および図６を用いて説明する。
【００５６】
図５は、本発明の実施の形態のファイル転送システムにおける基本の通信シーケンスを示す図である。図５に示すように、本実施の形態では、ソース機器１０１からシンク機器１０２への通信によりファイル転送が開始される。つまり、図５は、ソース機器１０１からの自発的なファイル転送における通信シーケンス図である。
【００５７】
なお、ソース機器１０１とシンク機器１０２との間の通信は、ブロードバンドルータ３０１により中継される。しかしながら、ブロードバンドルータ３０１の動作は本発明の特徴に関与しないため、以下、その図示および動作の説明は省略する。
【００５８】
ソース機器１０１は、ＵＰｎＰ−ＡＶ規格で規定されたＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを送付する（Ｓ５０１）。ここでＣｒｅａｔｅＯｂｊｅｃｔリクエストは論理的なファイルを示すｏｂｊｅｃｔを生成するリクエストであり、これによってシンク機器１０２のファイル蓄積部８０４内に、新規にｏｂｊｅｃｔが生成される。その際、生成されるｏｂｊｅｃｔのディレクトリ構造上の位置や、そのｏｂｊｅｃｔを示すファイル名等のメタデータが決定される。このメタデータにはファイル実体を保存すべきシンク機器１０２上のＵｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒｓ（ＵＲＩ）が含まれている。シンク機器１０２は、ファイルの転送先アドレスとして、このＵＲＩを含んだＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスをソース機器に送信する（Ｓ５０２）。
【００５９】
ソース機器１０１は、ＰＯＳＴメソッドのＨＴＴＰリクエスト（以下、「ＰＯＳＴリクエスト」という。）をシンク機器１０２に送付する（Ｓ５０３）。この際、ソース機器１０１は、ファイル転送が中断した場合にシンク機器１０２が参照すべきパラメータとして、図６に示すパラメータをＰＯＳＴリクエストに付加して送付する。具体的には、パラメータとして［ｂｙｔｅ−ｒａｎｇｅ］、［ｒｅｓｔａｒｔ−ｔｉｍｅ］、および［ｌｉｆｅｔｉｍｅ］の３つを送付する。
【００６０】
図６は、ソース機器１０１からシンク機器１０２に送付される各パラメータの内容を示す図である。
【００６１】
図６に示すように、［ｂｙｔｅ−ｒａｎｇｅ］は送信するデータのバイトレンジである。バイトレンジとは、送信するファイルデータの範囲であるデータ範囲の先頭位置と終端位置を示す情報、およびファイルの総サイズであるファイルサイズを示す情報である。また、単位はそれぞれバイトである。
【００６２】
つまり、シンク機器１０２は、ソース機器から送信されるデータの範囲だけでなくファイルの総サイズも通知される。そのため、受信したファイルデータが、あるファイルを構成する一部のファイルデータであるのか、または、あるファイルを構成する全てのファイルデータであるのかを判断することができる。なお、本実施の形態においては、１つのファイルをシンク機器１０２に送信する場合、分割せずに一括して送信する。ファイルを分割して送信する場合については図１５を用いて後述する。
【００６３】
［ｒｅｓｔａｒｔ−ｔｉｍｅ］は、送信再開許可時間である。送信再開許可時間とは、中断後にファイル転送動作を再開するまでの一時停止時間を示す情報であり、単位は秒である。
【００６４】
［ｌｉｆｅｔｉｍｅ］は、ファイル保持期間である。ファイル保持期間とは、シンク機器１０２がｏｂｊｅｃｔまたはファイルデータを保持しておくべき時間を示す情報であり、単位は秒である。シンク機器１０２は、［ｌｉｆｅｔｉｍｅ］に示される期間が経過するまでに、ファイルデータを受信しない場合、作成したｏｂｊｅｃｔを保持しておく義務が無い。また、［ｌｉｆｅｔｉｍｅ］を通知され、完結していないファイルデータを受信した場合、［ｌｉｆｅｔｉｍｅ］に示される期間が経過するまでに、残りのファイルデータを受信しない場合、完結していないファイルデータを保持しておく義務がない。
【００６５】
これにより、ソース機器１０１が接続不能になったり転送対象のファイルを消失してしまったような場合でも、シンク機器１０２は、完了できないファイル転送のための無駄なリソースを保持しておく必要が無い。そのため、シンク機器１０２においてリソースを効率よく管理でき、ユーザの手による不要なｏｂｊｅｃｔの削除などのメンテナンスも不要である。
【００６６】
図５の通信シーケンスでは、ソース機器１０１は、送信するデータの先頭位置：０バイト目、終端位置：９９９バイト目およびファイルサイズ：１０００バイトを指定している。これは、上述のように、１つのファイルを一括して送信することを意味する。さらに、一時停止時間：１２００秒（２０分）、ファイル保持期間：１８００秒（３０分）も指定している。
【００６７】
なお、転送中断要求を示す［ｓｕｓｐｅｎｄ−ｒｅｑ］は、図５の通信シーケンスにおいては使用されていない。［ｓｕｓｐｅｎｄ−ｒｅｑ］をシンク機器１０２に送付する場合については、図７を用いて後述する。
【００６８】
また、ソース機器１０１からシンク機器１０２に送信されるＰＯＳＴリクエストで指定するＵＲＩとして、シンク機器１０２から受信したＣｒｅａｔｅＯｂｊｅｃｔレスポンスに含まれていたＵＲＩが記述される。これにより、シンク機器１０２は特定のｏｂｊｅｃｔと、受信したファイルデータを対応させることができる。
【００６９】
さらに、ＰＯＳＴリクエストにはＥｘｐｅｃｔ：  １００−ｃｏｎｔｉｎｕｅが付加される。これにより、シンク機器はＲＦＣ２６１６に従い、送信されたＰＯＳＴリクエストを上記ＵＲＩで受け入れることができるかのチェックを行う。
【００７０】
チェックの結果、受け入れ可能であれば応答として“１００  Ｃｏｎｔｉｎｕｅ”を返す（Ｓ５０４）。なお、ソース機器１０１からのＰＯＳＴリクエストを受け入れることができない場合や、ＰＯＳＴリクエストを解釈することができない場合にはデータの転送の前にソース機器に通知することができる。従ってソース機器１０１は、無駄なデータ送信を回避することができる。
【００７１】
ソース機器１０１は“１００  Ｃｏｎｔｉｎｕｅ”ステータスをシンク機器１０２から受信することにより、ファイルをシンク機器１０２に送信する（Ｓ５０５）。なお、ファイルデータはＰＯＳＴリクエストのＥｎｔｉｔｙ  Ｂｏｄｙに格納されて送信される。
【００７２】
シンク機器１０２は、受信したファイルデータをファイル蓄積部８０４に蓄積する。シンク機器１０２は、ファイルの受信完了後に、ファイル蓄積部８０４へのファイル蓄積処理に時間を要する場合、例えば２０秒以内に蓄積が完了しない場合、ＲＦＣ２５１８で規定される“１０２  Ｐｒｏｃｅｓｓｉｎｇ”を送信し（Ｓ５０６）、蓄積処理中である旨をソース機器１０１に通知する。シンク機器１０２は、蓄積を完了すると“２０１  Ｃｒｅａｔｅｄ”を送信し、ソース機器１０１に蓄積完了である旨を通知する（Ｓ５０７）。
【００７３】
以上の各機器の動作により、ソース機器１０１からシンク機器１０２へのファイル転送が完了する。
【００７４】
なお、図５に示す通信シーケンスは、ファイル転送の途中で中断が発生しない基本の通信シーケンスであるが、ソース機器１０１またはシンク機器１０２の都合によりファイル転送の中断が生じる場合もある。そこで、以下に、ファイル転送の途中で中断が発生する場合の通信シーケンスおよび各機器の動作を、図７〜図９を用いて説明する。また、ファイル転送を再開する際の通信シーケンスおよび各機器の動作を図１０を用いて説明する。
【００７５】
図７は、実施の形態のファイル転送システムにおいて、ソース機器１０１の都合によりファイル転送が中断される際の通信シーケンスの一例を示す図である。図７を用いて、ソース機器１０１からシンク機器１０２へのファイルデータの送信中に、ソース機器１０１の都合によりファイル転送が中断される際の各機器の動作を説明する。
【００７６】
ソース機器１０１およびシンク機器１０２は、図５の通信シーケンスと同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う。この後、ソース機器１０１は、ＰＯＳＴリクエストをシンク機器１０２に送付する（Ｓ５０３）。シンク機器１０２は、ＰＯＳＴリクエストの応答として“１００  Ｃｏｎｔｉｎｕｅ”ステータスをソース機器１０１に送信する（Ｓ５０４）。ソース機器１０１は、ファイルデータのシンク機器１０２への送信を開始する（Ｓ５０５）。シンク機器１０２は、受信したファイルデータをファイル蓄積部８０４に蓄積する。ここまでの動作は、図５に示す通信シーケンスと同様である。
【００７７】
ここでソース機器１０１において、ファイル転送を中断する要因が発生し、ＴＣＰ接続を切断するためのＲＳＴパケットを送付する。これにより、ファイル転送に利用しているＴＣＰ接続は切断される（Ｓ７０６）。
【００７８】
ファイル転送を中断する要因とは、例えば、ユーザの操作により、転送中のファイルがファイル蓄積部７０５から削除されたなどである。
【００７９】
ソース機器１０１は、さらに、［ｓｕｓｐｅｎｄ−ｒｅｑ］および［ｌｉｆｅｔｉｍｅ］を含めたＰＯＳＴリクエストパケットをシンク機器１０２に送信する（Ｓ７０７）。［ｓｕｓｐｅｎｄ−ｒｅｑ］は図６に示すように、ファイル転送の中断要求を示す情報である。つまり、シンク機器１０２は［ｓｕｓｐｅｎｄ−ｒｅｑ］を受信することにより、ファイル転送が中断されることを知ることができる。また、［ｌｉｆｅｔｉｍｅ］は、上述のようにシンク機器１０２がファイルデータを保持しておくべき時間を示す情報であり、この場合は、ソース機器１０１が、その時間内にファイル転送を再開することをも意味する。シンク機器１０２は、ファイル保持期間が経過した後は、受信し保存済みの当該ファイルデータを削除してもよい。
【００８０】
なお、上述のファイル転送の中断に係る処理において、ＲＳＴパケットおよびＰＯＳＴリクエストパケットはファイル送信制御部７０２により生成されシンク機器１０２に送信される。以下、単に「ＰＯＳＴリクエスト」という場合、実体としてはＰＯＳＴリクエストパケットのことを指す。
【００８１】
また、中断検出部７０７は、ＴＣＰ接続が切断されたことを検出することで、ファイル転送が中断されたことを検出する。
【００８２】
シンク機器１０２は、上記ＰＯＳＴリクエストを受け取ると“２００  ＯＫ”を返信する（Ｓ７０８）。ソース機器１０１は、ファイル転送を中断する要因がなくなった後に、図１１を用いて後述するファイル転送の再開動作を実行する。
【００８３】
このようにして、本実施の形態のファイル転送システムにおいて、ファイルデータの送信の開始後かつファイル転送が完了する前に、ソース機器１０１の都合によりファイル転送が中断される。
【００８４】
次に、シンク機器１０２がＰＯＳＴリクエストを受信した際に、シンク機器１０２の都合によりファイル転送が中断される場合の各機器の動作を図８を用いて説明する。
【００８５】
図８は、実施の形態のファイル転送システムにおいて、シンク機器１０２の都合によりファイル転送が中断される際の通信シーケンスの一例を示す図である。
【００８６】
ソース機器１０１およびシンク機器１０２は、図５の通信シーケンスと同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う。この後、ソース機器１０１は、ＰＯＳＴリクエストをシンク機器１０２に送付する（Ｓ５０３）。ここまでの動作は、図５に示す通信シーケンスと同様である。
【００８７】
ここで、シンク機器１０２は、ファイルの受信処理を行えない状態であり、ＰＯＳＴリクエストに対する応答として“５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ”ステータスを送信する。ファイルの受信処理を行えない状態とは、例えば、ファイル蓄積部８０４の空き容量がない状態などである。
【００８８】
シンク機器１０２は、ステータスパケットにファイル転送を再開する始期を示す“ｒｅｔｒｙ−ａｆｔｅｒ”を含めて応答する（Ｓ８０４）。ソース機器１０１は、“ｒｅｔｒｙ−ａｆｔｅｒ”に示される時間を経過した後に、図１１を用いて後述するファイル転送の再開動作を実行する。
【００８９】
このようにして、本実施の形態のファイル転送システムにおいて、ソース機器１０１からシンク機器１０２に、ＰＯＳＴリクエストにより転送されるファイルのサイズ等が通知された後、かつファイルデータの送信が開始される前に、シンク機器１０２の都合によりファイル転送が中断される。
【００９０】
次に、ソース機器１０１からシンク機器１０２へのファイルデータの送信中に、シンク機器１０２側の要因によりファイル転送を中断する際の各機器の動作を図９を用いて説明する。
【００９１】
図９は、実施の形態のファイル転送システムにおいて、シンク機器１０２の都合によりファイル転送が中断される際の通信シーケンスの別の一例を示す図である。
【００９２】
ソース機器１０１およびシンク機器１０２は、図５の通信シーケンスと同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う。この後、ソース機器１０１は、ＰＯＳＴメソッドのＨＴＴＰリクエストをシンク機器１０２に送付する（Ｓ５０３）。シンク機器１０２は、ＨＴＴＰリクエストの応答として“１００  Ｃｏｎｔｉｎｕｅ”ステータスをソース機器１０１に送信する（Ｓ５０４）。ソース機器１０１は、ファイルデータのシンク機器１０２への送信を開始する（Ｓ５０５）。シンク機器１０２は、受信したファイルデータをファイル蓄積部８０４に蓄積する。ここまでの動作は、図５に示す通信シーケンスと同様である。
【００９３】
ここでシンク機器１０２において、ファイル転送を中断する要因が発生し、ＲＳＴパケットを送付する。これにより、ファイル転送に利用しているＴＣＰ接続は切断される（Ｓ９０６）。ファイル転送を中断する要因とは、例えば、ファイル蓄積部８０４から別のファイルを読み出す必要が生じ、受信するファイルデータを蓄積できないなどである。
【００９４】
ＴＣＰ接続がシンク機器により切断されると、ソース機器１０１のファイル送信制御部７０２は、再びＰＯＳＴリクエストをシンク機器１０２に送信する（Ｓ９０７）。
【００９５】
シンク機器１０２は、ＰＯＳＴリクエストへの応答として“５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ”ステータスをソース機器１０１へ送信する（Ｓ９０８）。ステータスパケットには 上述の［ｒｅｔｒｙ−ａｆｔｅｒ］が含められる。
【００９６】
この［ｒｅｔｒｙ−ａｆｔｅｒ］を伴う“５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ”は、シンク機器１０２からのファイル転送の中断要求である。
【００９７】
ソース機器１０１の中断検出部７０７は、この中断要求を検出することで、ファイル転送の中断を検出する。ソース機器１０１は、“ｒｅｔｒｙ−ａｆｔｅｒ”に示される時間を経過した後に、図１１を用いて後述するファイル転送の再開動作を実行する。
【００９８】
このようにして、本実施の形態のファイル転送システムにおいて、ファイルデータの送信の開始後かつ送信が完了する前に、シンク機器１０２側の要因によりファイル転送が中断される。
【００９９】
次に、図７〜図９を用いて説明したファイル転送の中断後に、ファイル転送を再開する際の各機器の動作を図１０を用いて説明する。
【０１００】
図１０は、実施の形態のファイル転送システムにおいて、ファイル転送を再開する際の通信シーケンスを示す図である。
【０１０１】
ソース機器１０１の中断検出部７０７は、ファイル転送が中断されたことを検出する（Ｓ１０００）。なお、中断検出部７０７は、ファイル転送の中断がソース機器１０１の都合によるものか、シンク機器１０２の都合によるものかを問わず、送受信するパケットの種類および内容等から、ファイル転送が中断されたことを検出することができる。
【０１０２】
ソース機器１０１は、自身の都合によりファイル転送を中断した場合は、その中断の要因がなくなった後で、また、シンク機器１０２の都合によりファイル転送が中断された場合は、中断の際にシンク機器１０２から送信された［ｒｅｔｒｙ−ａｆｔｅｒ］に示される時間が経過した後で、以下の動作を行う。
【０１０３】
ソース機器１０１は、ＣＤＳ：Ｂｒｏｗｓｅリクエストをシンク機器１０２に送信し（Ｓ１００１）、シンク機器１０２に対してファイルの保存サイズを問い合わせる。
【０１０４】
具体的には、ソース機器１０１のファイル送信制御部７０２により生成されるＣＤＳ：Ｂｒｏｗｓｅリクエストに、問合せ部７０８によって、保存済データサイズの通知要求が含められる。そのＣＤＳ：Ｂｒｏｗｓｅリクエストは、ネットワークインターフェース７０６を介しシンク機器１０２へ送信される。
【０１０５】
シンク機器１０２は、上記ＣＤＳ：Ｂｒｏｗｓｅリクエストを受け取ると保存済データサイズを含めたＣＤＳ：Ｂｒｏｗｓｅレスポンスをソース機器１０１に送信する（Ｓ１００２）。
【０１０６】
具体的には、保存済サイズ取得部８０６が、ファイル蓄積部８０４に保存されている、当該ファイルを構成するファイルデータのデータサイズを取得する。更に、ファイル受信制御部８０１が、保存済サイズ取得部８０６により取得されたデータサイズを含めたＣＤＳ：Ｂｒｏｗｓｅレスポンスを生成する。生成されたＣＤＳ：Ｂｒｏｗｓｅレスポンスは、ネットワークインターフェース８０５を介しソース機器１０１に送信される。
【０１０７】
ソース機器１０１のファイル送信制御部７０２は、受信した保存済データサイズに応じて転送すべきファイルの先頭位置を決定し、ファイル蓄積部７０５からファイルデータを読み出す。
【０１０８】
例えば、ファイルサイズが１０００バイトであり、シンク機器１０２から通知された保存済データサイズが４００バイトである場合を想定する。この場合、シンク機器１０２に保存されているファイルデータは、０バイト目から３９９バイト目までのファイルデータである。従って、ファイル送信制御部７０２は、残りの４００バイト目から９９９バイト目までのファイルデータを、ファイル制御部７０３を介しファイル蓄積部７０５から読み出す。以下、「残りのファイルデータ」という場合、上述のように、転送対象のファイルデータから、シンク機器１０２に保存済みのファイルデータを除いた、残りのファイルデータのことを指す。
【０１０９】
ソース機器１０１は、データ範囲とファイルサイズとを示す［ｂｙｔｅ−ｒａｎｇｅ］等を含むＰＯＳＴリクエストをシンク機器１０２に送信する（Ｓ１００３）。シンク機器１０２は、ＰＯＳＴリクエストへの応答として“１００  Ｃｏｎｔｉｎｕｅ”ステータスをソース機器１０１に送信する（Ｓ１００４）。
【０１１０】
ソース機器１０１のファイル送信制御部７０２は、ファイル蓄積部７０５から読み出した残りのファイルデータを通信制御部７０４に送信させる。（Ｓ１００５）。シンク機器１０２のファイル制御部８０２は、［ｂｙｔｅ−ｒａｎｇｅ］に示されるデータ範囲に基づき、受信したファイルデータと中断前に保存済みのファイルデータとを結合し、元のファイルに再構築する。
【０１１１】
このように、本発明の実施の形態のソース機器１０１は、中断されたファイル転送を再開する際に、シンク機器１０２に保存済データサイズを問い合わせることができる。また、本発明の実施の形態のシンク機器１０２はその問合せに応じ、保存済データサイズをソース機器１０１に通知することができる。
【０１１２】
これにより、ソース機器１０１は、ファイル転送を最初からやり直す必要がなく、残りのファイルデータのみを送信するのみでよい。またシンク機器１０２は、ファイルデータを重複して受信することがない。
【０１１３】
つまり、本発明の実施の形態のソース機器１０１、シンク機器１０２およびファイル転送システムにより、ソース機器１０１からの自発的なファイル転送において、規定されたＴＣＰ接続のタイムアウト時間より長い中断が生じた場合であっても、ファイル転送に係る処理を効率的に実行することができる。
【０１１４】
さらに、転送を再開可能な時間を機器間で通知できるので、不要な転送再開試行動作を抑制でき、機器の通信負荷を低減できるという効果を有する。
【０１１５】
なお、ファイル転送途中でネットワークの通信経路が断絶した場合、ソース機器１０１の中断検出部７０７が通信経路の断絶を検出すると、図１０の通信シーケンスに示すファイル転送の再開動作が開始される。
【０１１６】
また、図７〜図９を用いてファイル転送が中断される場合の通信シーケンスおよび各機器の動作を説明したが、ソース機器１０１またはシンク機器１０２の都合により、ファイル転送を中断ではなく、中止する必要が生じる場合もある。本発明の実施の形態のソース機器１０１およびシンク機器１０２のそれぞれは、ファイル転送を中止する場合、互いの機器に通知することができる。以下に、ファイル転送の中止に係る通信シーケンスおよび各機器の動作を、図１１〜図１４を用いて説明する。
【０１１７】
図１１は、実施の形態のファイル転送システムにおいて、ファイルデータの送信が開始される前に、ソース機器１０１の都合によりファイル転送が中止される際の通信シーケンスの一例を示す図である。図１１を用いて、ファイル転送が開始される前に、ソース機器１０１の都合によりファイル転送の実行が中止される際の各機器の動作を説明する。
【０１１８】
ソース機器１０１およびシンク機器１０２は、図５の通信シーケンスと同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う（Ｓ５０１、Ｓ５０２）。この後、ソース機器１０１がＰＯＳＴリクエストを送信する前に、ソース機器１０１において、ユーザによりファイル転送のキャンセル指示がなされる、または、転送対象のファイルが削除されるなどの事象が発生したと想定する。
【０１１９】
この場合、ソース機器１０１は、ファイル転送を中止するために、ＰＯＳＴリクエストに替えてＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔリクエストをシンク機器１０２に送信する（Ｓ１１０３）。シンク機器１０２は、ＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔを受信すると、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエスト（Ｓ５０１）に応じて作成したｏｂｊｅｃｔを削除する。更に、ｏｂｊｅｃｔを削除した旨を通知するために、ソース機器１０１にＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔレスポンスを応答する（Ｓ１１０４）。
【０１２０】
このように、ファイル転送が開始される前に、ソース機器１０１の都合により、ファイル転送が中止された場合、シンク機器１０２では、ファイルを保存するために作成されたｏｂｊｅｃｔが削除される。つまり、シンク機器１０２において無駄となるｏｂｊｅｃｔは速やかに削除される。
【０１２１】
次に、ソース機器１０１からシンク機器１０２へのファイルデータの送信中にソース機器１０１の都合によりファイル転送が中止される際の各機器の動作を図１２を用いて説明する。
【０１２２】
図１２は、実施の形態のファイル転送システムにおいて、ファイルデータの送信中に、ソース機器１０１の都合によりファイル転送が中止される際の通信シーケンスの一例を示す図である。
【０１２３】
ソース機器１０１およびシンク機器１０２は、図５の通信シーケンスと同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う。この後、ソース機器１０１は、ＰＯＳＴリクエストをシンク機器１０２に送付する（Ｓ５０３）。シンク機器１０２は、ＰＯＳＴリクエストの応答として“１００  Ｃｏｎｔｉｎｕｅ”ステータスをソース機器１０１に送信する（Ｓ５０４）。ソース機器１０１は、ファイルデータのシンク機器１０２への送信を開始する（Ｓ５０５）。シンク機器１０２は、受信したファイルデータをファイル蓄積部８０４に蓄積する。ここまでの動作は、図５に示す通信シーケンスと同様である。
【０１２４】
ここで、ソース機器１０１がＰＯＳＴリクエストを送信する前に、ソース機器１０１において、ユーザによりファイル転送のキャンセル指示がなされる、または、転送対象のファイルが削除されるなどの事象が発生したと想定する。
【０１２５】
ソース機器１０１は、ファイル転送を中止するために、ＴＣＰのＲＳＴパケットを送信する（Ｓ１２０６）。これにより、ファイル転送に利用しているＴＣＰ接続が切断される。ソース機器１０１は、さらに、ＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔリクエストをシンク機器１０２に送信する（Ｓ１２０７）。シンク機器１０２は、ＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔリクエストに応じて、受信済みのファイルデータを削除し、ＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔレスポンスをソース機器１０１へ送信する（Ｓ１２０８）。
【０１２６】
このように、ファイルデータの送信が開始された後に、ソース機器１０１の都合により、ファイル転送が中止された場合、シンク機器１０２では、受信し保存済みのファイルデータは削除される。つまり、シンク機器１０２において無駄となる、完結していないファイルデータは速やかに削除される。
【０１２７】
次に、シンク機器１０２がＰＯＳＴリクエストを受信した際に、シンク機器１０２の都合によりファイル転送が中止される際の各機器の動作を図１３を用いて説明する。
【０１２８】
図１３は、実施の形態のファイル転送システムにおいて、ファイルデータの送信が開始される前に、シンク機器１０２の都合によりファイル転送が中止される際の通信シーケンスの一例示す図である。
【０１２９】
ソース機器１０１およびシンク機器１０２は、図５の通信シーケンスと同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う。この後、ソース機器１０１は、ＰＯＳＴリクエストをシンク機器１０２に送信する（Ｓ５０３）。ここまでの動作は、図５と同様である。
【０１３０】
ここで、シンク機器１０２において、ソース機器１０１からのＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストに応じて作成されたｏｂｊｅｃｔが消失したなどの理由により、ファイル転送を中止する必要が生じた場合を想定する。
【０１３１】
この場合、シンク機器１０２は、ＰＯＳＴリクエストへの応答として“４０４  Ｎｏｔ  Ｆｏｕｎｄ”ステータスをソース機器１０１へ送信する（Ｓ１３０４）。ソース機器１０１は、“４０４  Ｎｏｔ  Ｆｏｕｎｄ”に応じてファイル転送に係る処理を中止する。
【０１３２】
このように、ソース機器１０１からシンク機器１０２に、ＰＯＳＴリクエストによりファイルサイズ等が通知された後、かつファイルデータの送信が開始される前に、シンク機器１０２の都合により、ファイル転送が中止された場合、ソース機器１０１は、シンク機器１０２からの通知によりファイル転送に係る処理を中止する。つまり、ソース機器１０１は不要な処理を継続することがない。
【０１３３】
次に、シンク機器１０２の都合により、ソース機器１０１からシンク機器１０２へのファイルデータの送信中にファイル転送が中止される際の各機器の動作を図１４を用いて説明する。
【０１３４】
図１４は、実施の形態のファイル転送システムにおいて、ファイルデータの送信中に、シンク機器の都合によりファイル転送が中止される際の通信シーケンスの一例示す図である。
【０１３５】
ソース機器１０１およびシンク機器１０２は、図５と同様に、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストおよびレスポンス通信を行う。この後、ソース機器１０１は、ＰＯＳＴリクエストをシンク機器１０２に送付する（Ｓ５０３）。シンク機器１０２は、ＰＯＳＴリクエストへの応答として“１００  Ｃｏｎｔｉｎｕｅ”ステータスをソース機器１０１へ送信する（Ｓ５０４）。ソース機器１０１は、ファイルデータのシンク機器１０２への送信を開始する（Ｓ５０５）。シンク機器１０２は、受信したファイルデータをファイル蓄積部８０４に蓄積する。ここまでの動作は、図５に示す通信シーケンスと同様である。
【０１３６】
ここで、シンク機器１０２において、ファイル転送を中止する要因が発生し、ＴＣＰのＲＳＴパケットを送信する（Ｓ１４０６）。これにより、ファイル転送に利用しているＴＣＰ接続が切断される。ソース機器１０１は、ＴＣＰ接続の切断を検出すると、再びＰＯＳＴリクエストをシンク機器１０２に送信する（Ｓ１４０７）。シンク機器は、ＰＯＳＴリクエストへの応答として“４０４  Ｎｏｔ  Ｆｏｕｎｄ”ステータスをソース機器１０１へ送信する（Ｓ１４０８）。ソース機器１０１は“４０４  Ｎｏｔ  Ｆｏｕｎｄ”に応じてファイル転送に係る処理を中止する。
【０１３７】
このように、ソース機器１０１からシンク機器１０２へのファイルデータの送信が開始された後に、シンク機器１０２の都合により、ファイル転送が中止された場合、ソース機器１０１は、シンク機器１０２からの通知によりファイル転送に係る処理を中止する。つまり、ソース機器１０１は不要な処理を継続することがない。
【０１３８】
このように、本発明の実施の形態のソース機器１０１およびシンク機器１０２は、ファイル転送を中止する場合、その中止がどちらの機器の都合によるものであっても、無駄なリソースの消費および無駄な処理が発生しないように、ファイル転送の中止のための処理が行われる。
【０１３９】
なお、上述の実施の形態において、プッシュ型のフロー制御を行うファイル転送プロトコルとしてＨＴＴＰのＰＯＳＴメソッドによりファイル転送を行う場合を説明した。しかしながら、ＰＯＳＴメソッド以外であってもよく、例えば、ＰＵＴメソッドであっても上記効果が失われるものではない。
【０１４０】
また、ソース機器１０１は、ファイル転送が中断した場合にシンク機器１０２が参照すべきパラメータとして、図６に示すパラメータをＨＴＴＰリクエストパケットに付加して送付するとした。
【０１４１】
このパラメータを付与する具体的な方法として、独自に定義したヘッダをＰＯＳＴリクエストのメッセージヘッダとして含ませる方法がある。
【０１４２】
例えば、ＰＯＳＴリクエストに、独自に定義したヘッダであるＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ：［ｂｙｔｅ−ｒａｎｇｅ］を付与し、ＨＴＴＰのＥｎｔｉｔｙ  Ｂｏｄｙ部に含まれるデータの範囲および総サイズを格納する。また、［ｌｉｆｅｔｉｍｅ］等の必要な情報を含ませる。シンク機器１０２は、ソース機器１０１から送信されたＰＯＳＴリクエストのメッセージヘッダから、これらの情報を取得することができる。
【０１４３】
また、上述の実施の形態においては、ＰＯＳＴリクエストに［ｂｙｔｅ−ｒａｎｇｅ］、［ｒｅｓｔａｒｔ−ｔｉｍｅ］、および［ｌｉｆｅｔｉｍｅ］の３つのパラメータを付加して送付する構成を説明した。しかしながら［ｒｅｓｔａｒｔ−ｔｉｍｅ］のみを付加してもよい。
【０１４４】
なお、ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ以外の、ＨＴＴＰで当然使用されるその他のヘッダについては本発明の特徴に関係しないため図示および説明を省略する。
【０１４５】
また、上述の実施の形態において、ソース機器１０１は、ファイルをシンク機器１０２に転送する場合、一括して転送するとした。しかしながら、ソース機器１０１は、ファイルを分割し、分割単位毎にシンク機器１０２に送付することもできる。シンク機器１０２が１回のＰＯＳＴリクエストで受信可能なデータサイズに制限がある場合など、ソース機器１０１が分割単位毎にファイルデータを送信する方法は有効である。
【０１４６】
図１５は、ソース機器１０１がシンク機器１０２にファイルを分割して転送するファイル転送システムの通信シーケンスを示す図である。図１５を用いて、ソース機器１０１がファイルを分割して転送する際の各機器の動作を説明する。なお、ソース機器１０１は、送信するファイルデータの範囲等をシンク機器１０２に通知するために、上述の、独自に定義したヘッダＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇを使用すると想定する。
【０１４７】
ソース機器１０１はファイルの転送に先立って、シンク機器１０２に対しＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを送信する（Ｓ１５０３）。シンク機器１０２は、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストに従い、ｏｂｊｅｃｔを作成し、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスをソース機器１０１に送信する（Ｓ１５０４）。
【０１４８】
ソース機器１０１はファイルを分割転送するサイズを決定する。分割転送のサイズは転送の中断、再開の頻度、中断時に無駄になる転送サイズ、分割によるオーバヘッド等を勘案して任意に決定することができる。ここでは１０００バイトのファイルを、最初の０バイト目から４９９バイト目までのファイルデータと、次の５００バイト目から９９９バイト目のファイルデータとに分割する（Ｓ１５０５）。このファイルの分割はソース機器のファイル送信制御部７０２が行う。
【０１４９】
ソース機器１０１はファイル転送を開始する。具体的には、ソース機器１０１はＰＯＳＴリクエストを送信する（Ｓ１５０６）。ＰＯＳＴリクエストには、独自に定義したヘッダである、ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ：  ［ｂｙｔｅ−ｒａｎｇｅ］、［ｌｉｆｅｔｉｍｅ］が含まれる。ここでの［ｂｙｔｅ−ｒａｎｇｅ］は、ヘッダ以下に続くＨＴＴＰのＥｎｔｉｔｙ  Ｂｏｄｙ部に含まれるデータの範囲と、ファイルの総サイズを示す情報であり、データの範囲“０−４９９”とファイルの総サイズである“１０００”が指定される。［ｌｉｆｅｔｉｍｅ］ではコンテンツの保持期間を指定しており、ここでは秒単位で“１８００”つまり、３０分を指定している。
【０１５０】
シンク機器１０２は、上記ＰＯＳＴリクエストへの応答として“１００  Ｃｏｎｔｉｎｕｅ”をソース機器１０１へ送信する（Ｓ１５０７）。
【０１５１】
ソース機器１０１は、シンク機器１０２に通知したデータ範囲のファイルデータを送信する（Ｓ１５０８）。具体的にはＰＯＳＴリクエストのＥｎｔｉｔｙ  Ｂｏｄｙに当該ファイルデータを格納して送信する。Ｅｎｔｉｔｙ  Ｂｏｄｙに含まれるファイルの範囲は、上述のように“０−４９９”の５００バイト分のみである。
【０１５２】
シンク機器１０２はこの５００バイト分のファイルデータを受信するとファイル蓄積部８０４への保存を開始する。保存の開始後、ファイル蓄積部８０４への書き込み速度が遅いなど、概ね２０秒以内に保存を完了できない場合、“１０２  Ｐｒｏｃｅｓｓｉｎｇ”を送信する（Ｓ１５０９）。その後、受信したファイルデータの保存が完了すると（Ｓ１５１０）、“２０１  Ｃｒｅａｔｅｄ”をソース機器１０１へ送信し（Ｓ１５１１）、転送データが保存されたことを通知する。
【０１５３】
次に、ソース機器１０１とシンク機器１０２は、上述のソース機器１０１からシンク機器１０２へのＰＯＳＴリクエストの送信（Ｓ１５０６）から、シンク機器１０２からソース機器１０１への保存完了の通知（Ｓ１５１１）と同様の動作シーケンスにより、次の分割単位である５００バイト目から９９９バイト目までのファイルデータの転送を行う（Ｓ１５１２〜Ｓ１５１７）。
【０１５４】
即ち、ソース機器１０１は、ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇヘッダの  ［ｂｙｔｅ−ｒａｎｇｅ］に“５００−９９９／１０００”を格納しシンク機器１０２に通知する。シンク機器１０２はこれを解釈し、その後に受信するファイルデータ（Ｓ１５１５）を、すでに保存されている０バイト目から４９９Ｂｙｔｅ目のファイルデータにアペンドしてファイル蓄積部８０４に保存する。
【０１５５】
このようにして、ＰＯＳＴメソッドを用いてファイルを送信するプッシュ型のフロー制御でもファイルを分割して送信を行うことが可能となる。
【０１５６】
なお、このようにファイルが分割して転送される場合においても、ファイル転送が中断された場合、ソース機器１０１は、図１０の通信シーケンスに示すように、シンク機器１０２に保存済データサイズを問い合わせることで、送信すべき残りのファイルデータのみを送信する。例えば、図１５の通信シーケンスにおいて、最初の５００バイトの送信中にファイル転送が中断され、それまでにシンク機器１０２に２００バイトが保存されていた場合を想定する。この場合、ソース機器１０１は、シンク機器１０２に問い合わせることにより保存済データサイズが“２００”であることを取得する。その後、ソース機器１０１は残りの３００バイトをシンク機器１０２に送信する。
【０１５７】
また、伝送路上のエラー等により、保存済データサイズを取得できなかった場合、送信途中であったファイルデータを再送信する。例えば、図１５の通信シーケンスにおいて、後の５００バイトの送信中にファイル転送が中断され、ソース機器１０１がシンク機器１０２から保存済データサイズを取得できなかった場合、後の５００バイトを最初から送信する。
【０１５８】
つまり、最初の５００バイトは、シンク機器１０２からの“２０１  Ｃｒｅａｔｅｄ”によりシンク機器１０２に保存済みであることが確認できているため、ソース機器１０１は、後の５００バイトのみを再送信すればよい。
【０１５９】
このように、転送対象のファイルを分割して送信する方法は、上述のように、シンク機器１０２が１回のＰＯＳＴリクエストで受信可能なデータサイズに制限がある場合のみならず、ファイル転送の効率化に対しても有効である。
【０１６０】
また、分割されたファイルデータがシンク機器１０２に送信される前にＰＯＳＴリクエストでファイルの総サイズがシンク機器１０２に通知される。そのため、シンク機器１０２は、受信したファイルデータが、あるファイルを構成する一部のファイルデータであるのか、または、あるファイルを構成する全てのファイルデータであるのかが判断できる。
【０１６１】
例えば、ファイルデータの送信に先立って通知される［ｂｙｔｅ−ｒａｎｇｅ］が“０−４９９／１０００”であれば、その後に受信したファイルデータはあるファイルを構成する一部のファイルデータであると判断できる。また、［ｂｙｔｅ−ｒａｎｇｅ］が“０−９９９／１０００”であれば、その後に受信したファイルデータはあるファイルを構成する全てのファイルデータであると判断できる。
【０１６２】
これにより、例えば、［ｂｙｔｅ−ｒａｎｇｅ］が“０−４９９／１０００”と指定されたファイルデータを受信し保存した後に、残りのファイルデータを受信しない場合、保存済みのファイルデータは完結していないファイルデータであると判断できる。そこで、所定の期間後に削除、またはユーザに保存を継続するかを確認するなどの処置を行うことができる。
【０１６３】
受信したファイルデータについては、上述のように、ソース機器１０１から指定される［ｌｉｆｅｔｉｍｅ］に示される保持期間を越えることをもって削除することも可能である。そこで、シンク機器１０２は、［ｌｉｆｅｔｉｍｅ］が指定されていない場合に、上記の［ｂｙｔｅ−ｒａｎｇｅ］に基づく判断により、所定期間の経過後に削除してもよい。また、［ｌｉｆｅｔｉｍｅ］に示される保持期間を越え、かつ、［ｂｙｔｅ−ｒａｎｇｅ］に示される情報から、当該ファイルデータが完結していないファイルデータであると判断できる場合、そのファイルデータを削除してもよい。
【０１６４】
なお、これら［ｂｙｔｅ−ｒａｎｇｅ］および［ｌｉｆｅｔｉｍｅ］等をシンク機器１０２へ通知するためのヘッダの名前は、ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ以外のヘッダ名でもかまわない。さらに本実施の形態ではＤｉｇｉｔａｌ  Ｌｉｖｉｎｇ  Ｎｅｔｗｏｒｋ  Ａｌｌｉａｎｃｅ（ＤＬＮＡ）で定義するヘッダ命名手法に従い“．ｄｌｎａ．ｏｒｇ”を接尾語として用い、他の任意のヘッダ名との偶然の一致を回避している。しかしながら、これに限らず、例えばＨＴＴＰの独自拡張ヘッダであることを示す接頭語“Ｘ−”を用いて、“Ｘ−ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ”等と定義してもかまわない。
【０１６５】
また、図１５に示す通信シーケンスにおいては１０００バイトのファイルを５００バイトずつ２分割したが、当然にその分割単位に限定されるものではなく、任意の分割が可能である。
【０１６６】
また、ソース機器１０１からシンク機器１０２へファイルを分割して転送するファイル転送システムにおいても、ソース機器１０１またはシンク機器１０２の都合によりファイル転送が中断または中止される場合がある。そこで、以下に、分割された１つの断片であるファイルデータの送信前にファイル転送が中断される場合の通信シーケンスおよび各機器の動作を、図１６および図１７を用いて説明する。また、ファイル転送が中止される場合の通信シーケンスおよび各機器の動作を図１８を用いて説明する。
【０１６７】
図１６は、ファイルを分割して転送するファイル転送システムにおいて、分割後の１つのファイルデータの送信前に、ソース機器１０１の都合によりファイル転送が中断される場合の通信シーケンスを示す図である。
【０１６８】
図１６の通信シーケンスにおいてＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを送信（Ｓ１５０３）してから、転送対象のファイルを分割（Ｓ１５０５）までは、図１５を用いて説明した通りであり説明を省略する。
【０１６９】
ここで、ソース機器１０１において、ユーザのキャンセル指示等によりファイルの転送を中断する場合を想定する。この場合、ソース機器１０１は、ＰＯＳＴリクエストのメッセージヘッダに、処理の保留を示す［ｓｕｓｐｅｎｄ］を含むＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇヘッダを格納しシンク機器１０２に送信する（Ｓ１６０６）。
【０１７０】
ソース機器１０１は、このＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ヘッダに含まれるキーワードである［ｓｕｓｐｅｎｄ］を示すフィールド値によってシンク機器１０２に明示的に中断を通知することができる。なお、この場合、ＰＯＳＴリクエストのＥｎｔｉｔｙ  Ｂｏｄｙは送信されない。また、図１５の通信シーケンスと同様に、［ｌｉｆｅｔｉｍｅ］も上記ヘッダに含まれ、例えば、秒単位で“１８００”、つまり３０分が指定される。
【０１７１】
シンク機器１０２は“２００  ＯＫ”を送信し（Ｓ１６０７）、中断を了解したことを示す。
【０１７２】
本手順によれば単にＴＣＰ切断などにより中断した場合と比較すると、シンク機器１０２で不要な転送プロセスをスリープさせるなど、適切な対処を行うことができるため、無駄な処理の発生を抑止する効果がある。
【０１７３】
なお、転送の再開はＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ヘッダの［ｌｉｆｅｔｉｍｅ］で指定した３０分以内にソース機器１０１が任意に行うことができる。なお、３０分以内にソース機器１０１が転送の再開を行えないような場合、再度ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ｓｕｓｐｅｎｄを送信することにより、転送再開期間の再延長を行うことも可能である。
【０１７４】
次に、ファイルを分割して転送するファイル転送システムにおいて、シンク機器１０２がＰＯＳＴリクエストを受信した際に、シンク機器１０２の都合によりファイル転送が中断される場合の各機器の動作を図１７を用いて説明する。
【０１７５】
図１７は、ファイルを分割して転送するファイル転送システムにおいて、シンク機器１０２がＰＯＳＴリクエストを受信した際に、シンク機器１０２の都合によりファイル転送が中断される場合の通信シーケンスを示す図である。
【０１７６】
図１７の通信シーケンスにおいて、ソース機器１０１が、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを送信（Ｓ１５０３）してから、送信するファイルデータの範囲等をＰＯＳＴリクエストにより通知する（Ｓ１５０６）までは、図１５を用いて説明した通りであり説明を省略する。
【０１７７】
ここで、上記ＰＯＳＴリクエスト（Ｓ１５０６）を受信したシンク機器１０２が、ファイル蓄積部８０４からデータを読出し中であるなどの理由により、ファイル転送を行える状態に無い場合を想定する。
【０１７８】
この場合、シンク機器１０２は、ＰＯＳＴリクエストへの応答として“５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ”をソース機器１０１へ送信し（Ｓ１７０７）、ファイル転送を行える状態に無いことをソース機器１０１に通知する。
【０１７９】
また、シンク機器１０２は、“５０３  Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ”を含むレスポンスメッセージにＲｅｔｒｙ−Ａｆｔｅｒ：ヘッダを格納することによって転送を開始できる見込みの時間を通知する。つまり、Ｒｅｔｒｙ−Ａｆｔｅｒ：ヘッダは、ファイル転送を再開する始期を示す情報である。さらに、独自に定義したヘッダであるＵｐｌｏａｄＴｒａｎｓｐｏｒｔＥｘｐｉｒｅＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ヘッダを格納することによって、再開が可能である期間を通知する。
【０１８０】
ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＥｘｐｉｒｅＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ヘッダは、ファイル転送を受け入れる終期を示すためのヘッダである。図１７の通信シーケンスでは秒単位で“１８００”、つまり３０分が指定されている。この場合、シンク機器１０２が上記レスポンスメッセージを送信（Ｓ１７０７）してから３０分後まではファイル転送を受け入れることを示す。具体的には、３０分が経過すると、ソース機器１０１からのＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエスト（Ｓ１５０３）に応じて作成されたｏｂｊｅｃｔが削除される。なお、すでに一部のファイルデータを受信し保存した後に、ファイル転送を中断した場合、完結していないファイルデータがファイル蓄積部８０４に保存されているため、そのファイルデータが削除される。
【０１８１】
ここで、ＲＦＣ２６１６で定義されるＲｅｔｒｙ−Ａｆｔｅｒ：ヘッダは一般にサービスの再開を保障するものではなく、Ｒｅｔｒｙ−Ａｆｔｅｒ：ヘッダに示される期間より短い間隔でリトライを行ってもサービスが再開できる見込みが薄いことを通知して相手機器のポーリング負荷を抑制するためのものである。
【０１８２】
従って、ソース機器１０１はシンク機器１０２に対し、Ｒｅｔｒｙ−Ａｆｔｅｒ：ヘッダにより示される２０分以降、ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＥｘｐｉｒｅＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ヘッダにより示される３０分以内にリトライを行って、転送の再開が可能であるか確認を行い、可能であれば続きのファイルデータの送信を行う。
【０１８３】
このように、シンク機器１０２が自身の都合によりファイル転送を中断する場合、Ｒｅｔｒｙ−Ａｆｔｅｒ：ヘッダと、ＵｐｌｏａｄＴｒａｎｓｐｏｒｔＥｘｐｉｒｅＩｎｆｏ．ｄｌｎａ．ｏｒｇ：ヘッダとにより、ソース機器１０１がファイル転送をリトライすべき始期と終期とがソース機器１０１に通知される。
【０１８４】
これにより、ソース機器１０１は、無駄なリトライをすることがない。結果として、ソース機器１０１内および伝送路上でのリソースの無駄な使用を防ぐことができる。
【０１８５】
次に、ファイルを分割して転送するファイル転送システムにおいて、ファイル転送が中止される場合の一例として、シンク機器１０２の都合によりファイル転送が中止される場合の通信シーケンスおよび各機器の動作を図１８を用いて説明する。
【０１８６】
図１８は、ファイルを分割して転送するファイル転送システムにおいて、シンク機器１０２の都合によりファイル転送が中止される場合の通信シーケンスを示す図である。
【０１８７】
図１８の通信シーケンスにおいて、ソース機器１０１が、ＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを送信（Ｓ１５０３）してから、シンク機器１０２が、ファイル転送を行える状態に無いこと等をソース機器１０１に通知する（Ｓ１７０７）までは、図１５および図１７を用いて説明した通りであり説明を省略する。
【０１８８】
図１８の通信シーケンスにおいて、シンク機器１０２は、一旦、ファイル転送を中断するための通知（Ｓ１７０７）を行っているが、ソース機器１０１がファイル転送のリトライ（Ｓ１８０８）を行った際に、シンク機器１０２がファイル転送を再開せずに中止したい理由あったと想定する。
【０１８９】
この様な理由としては、例えばファイル蓄積部８０４の空き容量がなくなったため、当面転送を再開できる見込みが無い場合や、転送を行うとシンク機器１０２の動作自体に支障をきたす場合などがあげられる。
【０１９０】
このような場合、シンク機器１０２は“４０４  Ｎｏｔ  Ｆｏｕｎｄ”を応答として送信し（Ｓ１８０９）、送信先のＵＲＩリソース、つまり、送信されるファイルデータを保存するためのｏｂｊｅｃｔが削除されて最早使用可能で無いことを示す。なお、ソース機器１０１とシンク機器１０２とのタイマーの違いにより、ソース機器１０１が既にシンク機器１０２から削除されたＵＲＩに対してリトライを行った場合にも同様のシーケンスとなる場合がある。
【０１９１】
なお、ソース機器１０１からファイル転送を中止する場合、タイムアウトするまで所定のＵＲＩにリトライを行わない方法や、ＵＰｎＰ−ＡＶのＣＤＳ：ＤｅｓｔｒｏｙＯｂｊｅｃｔを発行してシンク機器１０２から明示的にオブジェクトとそれに関連するＵＲＩを削除する方法などがある。
【０１９２】
以上ＵＰｎＰ−ＡＶのオブジェクト単位でファイル転送を管理する例で説明したが、これに限らず、単に所定のＵＲＩに対してファイル送信を行う場合にも適用可能である。
【０１９３】
このように、ファイルを分割して転送するファイル転送システムであっても、ファイル転送が中断または中止された場合には、ソース機器１０１またはシンク機器１０２が中断または中止を相手機器に通知することができる。これにより、中断または中止を通知された機器は、無駄となるファイル転送のための処理を継続することがない。
【０１９４】
なお、ＨＴＴＰのＰＯＳＴメソッドによりファイルを送信する場合を説明したが、これに限らず、ＰＵＴメソッド、さらには同様のハンドシェイクシーケンスが適用可能なＨＴＴＰ以外のファイル転送プロトコルへも適用が可能である。
【０１９５】
また、図１６〜図１８では、分割後のファイルデータが１回も送信されることなく、ファイル転送が中断または中止される場合の通信シーケンスを示している。しかしながら、図１６〜図１８を用いて説明したファイル転送の中断または中止の際の各機器の動作は、１回以上ファイルデータが送信された後、かつ、次のファイルデータが送信される前に中断または中止される場合でも同じである。
【産業上の利用可能性】
【０１９６】
本発明の送信機器、受信機器、およびファイル転送システムは、ネットワークに接続される任意の機器間でファイルを転送するファイル転送システムにおいて有用である。特にファイルのサイズが大きく、転送を中断して再開する際に、転送を初めからやり直すと無駄が多い場合に効果を発揮する。
【図面の簡単な説明】
【０１９７】
【図１】図１は、従来のソース機器およびシンク機器により構成されるファイル転送システムにおけるファイル転送の再開に係る通信シーケンスの一例を示す図
【図２】図２は、本発明の実施の形態のファイル転送システムの機器構成を示す図
【図３】図３は、本発明の実施の形態のソース機器の機能的な構成を示す機能ブロック図
【図４】図４は、本発明の実施の形態のシンク機器の機能的な構成を示す機能ブロック図
【図５】図５は、本発明の実施の形態のファイル転送システムにおける基本の通信シーケンスを示す図
【図６】図６は、ソース機器からシンク機器に送付される各パラメータの内容を示す図
【図７】図７は、実施の形態のファイル転送システムにおいて、ソース機器の都合によりファイル転送が中断される際の通信シーケンスの一例を示す図
【図８】図８は、実施の形態のファイル転送システムにおいて、シンク機器の都合によりファイル転送が中断される際の通信シーケンスの一例を示す図
【図９】図９は、実施の形態のファイル転送システムにおいて、シンク機器の都合によりファイル転送が中断される際の通信シーケンスの別の一例を示す図
【図１０】図１０は、実施の形態のファイル転送システムにおいて、ファイル転送を再開する際の通信シーケンスを示す図
【図１１】図１１は、実施の形態のファイル転送システムにおいて、ファイルデータの送信が開始される前に、ソース機器の都合によりファイル転送が中止される際の通信シーケンスの一例を示す図
【図１２】図１２は、実施の形態のファイル転送システムにおいて、ファイルデータの送信中に、ソース機器の都合によりファイル転送が中止される際の通信シーケンスの一例を示す図
【図１３】図１３は、実施の形態のファイル転送システムにおいて、ファイルデータの送信が開始される前に、シンク機器の都合によりファイル転送が中止される際の通信シーケンスの一例示す図
【図１４】図１４は、実施の形態のファイル転送システムにおいて、ファイルデータの送信中に、シンク機器の都合によりファイル転送が中止される際の通信シーケンスの一例示す図
【図１５】図１５は、ソース機器がシンク機器にファイルを分割して転送するファイル転送システムの通信シーケンスを示す図
【図１６】図１６は、ファイルを分割して転送するファイル転送システムにおいて、分割後の１つのファイルデータの送信前に、ソース機器の都合によりファイル転送が中断される場合の通信シーケンスを示す図
【図１７】図１７は、ファイルを分割して転送するファイル転送システムにおいて、シンク機器がＰＯＳＴリクエストを受信した際に、シンク機器の都合により転送が中断される場合の通信シーケンスを示す図
【図１８】図１８は、ファイルを分割して転送するファイル転送システムにおいて、シンク機器の都合によりファイル転送が中止される場合の通信シーケンスを示す図
【符号の説明】
【０１９８】
１０１    ソース機器
１０２    シンク機器
７０１    ユーザインターフェース
７０２    ファイル送信制御部
７０３、８０２    ファイル制御部
７０４、８０３    通信制御部
７０５、８０４    ファイル蓄積部
７０６、８０５    ネットワークインターフェース
７０７    中断検出部
７０８    問合せ部
８０１    ファイル受信制御部
８０６    保存済サイズ取得部
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2006046446.tif 000020
【図２】
2006046446.tif 000021
【図３】
2006046446.tif 000022
【図４】
2006046446.tif 000023
【図５】
2006046446.tif 000024
【図６】
2006046446.tif 000025
【図７】
2006046446.tif 000026
【図８】
2006046446.tif 000027
【図９】
2006046446.tif 000028
【図１０】
2006046446.tif 000029
【図１１】
2006046446.tif 000030
【図１２】
2006046446.tif 000031
【図１３】
2006046446.tif 000032
【図１４】
2006046446.tif 000033
【図１５】
2006046446.tif 000034
【図１６】
2006046446.tif 000035
【図１７】
2006046446.tif 000036
【図１８】
2006046446.tif 000037
【国際調査報告】
2006046446.tif 000038
2006046446.tif 000039
2006046446.tif 000040
2006046446.tif 000041