JP5792850B2 - ネットワーク上でのファイルフォルダ送信 - Google Patents

Description

本開示は通信分野に関し、特に、インスタントメッセージングシステムなどの通信アプリケーションを用いたネットワーク上でのファイル送信のためのシステム、装置および方法に関する。

インターネットの発展と共に、電子情報が世界中のインターネットユーザ間で共有されている。人々は、自身の学習および他の生活局面の利益のために、多様な種類の情報をいつでもインターネットから入手することができる。特定のインターネット通信ソフトウェアおよびサービス（例えば、ＱＱおよびＭＳＮ）が、インターネットユーザの、仕事、学習および娯楽を含む生活の一部となっている。インターネット通信においてはファイル送信が必要となる場合が頻繁にあるため、ファイル送信は、インターネットにおいて最も重要なアプリケーションの１つとなっている。

インターネットアプリケーションのコアアプリケーションとしてのファイル送信も、ウィンドウズ（登録商標）などのオペレーティングシステムによってサポートされている。ウィンドウズなどの主流のオペレーティングシステムにおいては、その多様なバージョンにおけるネットワーク共有により、ファイルおよびファイルフォルダの送信を既にサポートしている。しかし、このようなファイルおよびファイルフォルダ送信は、ローカルエリアネットワーク内においてしか効率的に実施することができない。それと同時に、インターネットユーザからの要求を満たすために、インスタントメッセージングソフトウェアアプリケーションにおいて、Ｐ２Ｐ（ピアツーピアネットワーキング）およびファイルリレー技術を用いたより強力なファイル送信機能により、インターネット上の任意の２つの端間またはさらには複数の端間でのファイル送信が実現されている。しかし、ファイルフォルダの送信はより複雑であるため、既存のインスタントメッセージングソフトウェアにおいては、現在のところファイルフォルダ送信機能は提供されていない。

実際のアプリケーションでは、インターネットユーザは、特定のファイルフォルダ下の全ファイルを送信しなければならない場合が頻繁にある。既存のインスタントメッセージングツールは高速かつ簡単なファイルフォルダ送信機能を提供できていないため、ユーザは、以下のアプローチのうちの１つを用いて、ファイルフォルダ送信を完了することが多い。

第１のアプローチにおいて、送信者は、送信すべきファイルフォルダを選択し、ジップソフトウェアを用いて、前記ファイルフォルダ中の全ファイルを圧縮する。圧縮完了後、単一のジップファイルが受信者へと送られる。前記ジップファイルを受信すると、前記受信者は、前記ファイルを解凍して、前記ファイルフォルダを回復させる。

具体的には、中国特許出願第２００３１０１１２５７１．６号において、ファイル送信のためのプロキシシステムおよび方法についての開示がある。同特許出願中に開示されている方法では、プロキシサーバがＦＴＰ（ファイル転送プロトコル）サーバから情報をダウンロードし、クライアントコンピュータから送られたユーザリクエストに基づいて、情報をＦＴＰサーバにアップロードすることが可能である。図１に示すように、ファイル送信プロキシシステムは、プロキシサーバ１０１と、複数のクライアントコンピュータ１０３と、ネットワーク１０４と、ＦＴＰサーバ１０２とを含む。図２に示すように、プロキシサーバ２０１（１０１）は、送信モジュール２１０と、圧縮モジュール２１１と、解凍モジュール２１２と、接続モジュール２１３とを含む。送信モジュール２１０は、クライアントコンピュータ１０３とＦＴＰサーバ１０２との間の情報の送信のために用いられる。圧縮モジュール２１１は、クライアントコンピュータ１０３に送られている情報を圧縮するために用いられる。解凍モジュール２１２は、ＦＴＰサーバ１０２に送られている情報を解凍するために用いられる。接続モジュール２１３は、ユーザからのリクエストに従ったＦＴＰサーバ１０２との接続のために、用いられる。同特許文献中に開示されているシステムを用いた場合、ファイル送信速度およびファイル送信セキュリティを向上させることができる。

ファイルフォルダ中のファイルを送信前にジッピングおよび圧縮することにより、上述したシステムおよび方法は、高速の送信速度を有するだけでなく、技術的実装コストもより低下させている。しかし、大型のファイルフォルダの場合、ジッピングおよび解凍に時間がかかる。その結果、ユーザコンピュータの大量のＣＰＵ、ハードディスクおよびメモリリソースが処理時に占領され、ユーザの作業状態が悪くなる。

代替のアプローチにおいて、送信者は、ファイルフォルダ中のファイルを１つずつ選択および送信し、受信者は、前記ファイル全ての送信が完了するまで、前記ファイルを１つずつ受信する。この送信方法の場合、ジッピングは不要であり、技術的実装コストも低いものの、送信者および受信者双方のユーザとしての作業が極めて面倒になり得る。ファイルフォルダ中に多数のファイルが含まれる場合、大量の時間およびエネルギーが無駄になり得る。その上、ユーザのネットワーク環境が複雑であり、送信プロセスにおけるユーザの作業が不確実である場合（例えば、インターネットに突然不具合が発生したり、ユーザが誤ったファイルを選択した場合）、この方法では困難が発生する。さらに、ウィンドウズオペレーティングシステムのディレクトリ長さの文字数の最大限度は２６０文字であるため、送られているファイルフォルダのサブディレクトリの深さ（すなわち、前記ファイルフォルダ中のファイルの最大経路長さ）が深すぎる場合、受信者に対して保存不具合が発生する。２つのファイル送信端のネットワーク条件が貧弱である場合、データ送信ルートの頻繁な変動に起因して接続が終了され得、再接続後に前回の送信を回復させるのが困難である場合がある。

開示されるのは、ファイルフォルダを送信端から受信端へと送るための方法およびシステムである。前記方法は、前記送信端側においてファイルフォルダ送信ユニットを用いて、先ず前記ファイルフォルダのディレクトリ構造ファイルを生成する。前記ディレクトリ構造ファイルは、特性（例えば、前記ファイルフォルダのサイズ、前記ファイルフォルダ中のファイルの経路および経路長さ）を持ち得る。その後、前記送信端は、前記ファイルフォルダ送信ユニットを通じて前記ディレクトリ構造ファイルを前記受信端へと送り、これにより、前記システムは、前記ファイルフォルダ中のいずれのファイルを送信すべきかを決定することができる。その後、前記決定に従って、前記ファイルを前記受信端へと送る。前記開示される方法およびシステムにより、より高速かつより簡便なファイルフォルダネットワーク送信が可能となり、既存のファイルフォルダ送信方法特有の面倒な作業および高いリソース占有度の問題の解消が支援される。

前記ディレクトリ構造ファイルは、前記ファイルフォルダを横断し、前記ディレクトリ構造ファイルの特性を計算することにより、生成され得る。前記ディレクトリ構造ファイルの特性はまた、前記ファイルフォルダ中のサブフォルダのサイズと、前記サブフォルダ中のファイルの経路および経路長さとを含み得る。

一実施形態において、ファイルフォルダ中の送信すべきファイルは、受信端におけるディレクトリ構造ファイルを分析することにより、決定することができる。前記受信端は、ファイル取得リクエストを送信端へと送って、前記ファイルフォルダ中の送信すべきファイルをリクエストすることができる。

一実施形態において、前記送信端および前記受信端は、インスタントメッセージングツールを通じて通信する。前記送信端は、インスタントメッセージングチャンネルを通じて、ファイルフォルダ送信リクエストを前記受信端へと送る。前記ファイルフォルダ中のファイルを送るために、前記ディレクトリ構造ファイルを前記送信端から前記受信端へと送る前に、前記送信端と受信端との間のネットワーク状態に基づいてネットワークデータ送信チャンネルを開くことができる。

一実施形態において、前記システムは、前記ディレクトリ構造ファイルを送る前に、前記受信端が前記ディレクトリ構造ファイルを既に有するか否かを決定する。これを行うために、前記システムは、前記ディレクトリ構造ファイルのインデックス識別子を生成し、前記インデックス識別子を前記受信端へと送って、前記インデックス識別子を用いて、前記受信端が既に前記ディレクトリ構造ファイルを有するか否かを決定することができる。前記インデックス識別子は、１６ビットの一意の識別子であり得、メッセージダイジェストアルゴリズムを用いて前記ディレクトリ構造ファイルから抽出される。

前記受信端と前記送信端との間にネットワーク接続割り込みが発生した場合、前記方法は、前記ディレクトリ構造ファイルまたは前記ファイルフォルダの送信割り込みのブレイクポイント情報を取得し、前記送信が通常に戻った後に、前記ブレイクポイント情報によって示される位置から送信を再開することができる。

本開示の一態様は、送信端とファイルフォルダ送信との間でファイルフォルダを送信する装置である。前記装置は前記送信端と接続しており、前記受信端は、ネットワーク接続を通じて前記送信端と接続して、前記送信端から前記ファイルフォルダ送信デバイスを通じて前記ファイルフォルダを送る。前記ファイルフォルダ送信装置は、前記ファイルフォルダのディレクトリ構造ファイルを生成するように適合されたファイルフォルダディレクトリ管理モジュールと、前記送信端から前記受信側へと送信すべきファイルフォルダ中のファイルを前記ディレクトリ構造ファイルに従って決定するように適合されたファイルフォルダ送信動作論理モジュールと、前記受信端へと送るべき前記ファイルフォルダ中のファイルを送るように適合された任意のネットワーク送信モジュールとを有する。前記ディレクトリ構造ファイルが含む特性としては、前記ファイルフォルダのサイズ、前記ファイルフォルダ中のファイルの経路および経路長さを挙げることができる。

一実施形態において、前記ファイルフォルダ送信動作論理モジュールは、ファイル取得リクエストを前記受信端から受信するようにさらに適合され、前記ファイル取得リクエストは、前記ファイルフォルダ中の送信すべきファイルをリクエストする。

本開示の別の態様によれば、１つ以上のコンピュータ可読媒体は、複数の命令であって、これらの命令は、プロセッサによって実行されると、ファイルフォルダのディレクトリ構造ファイルをプロセッサに生成させる、命令を自身の上に保存する。これら１つ以上のコンピュータ可読媒体はまた、前記ディレクトリ構造ファイルを送信端から受信端へと送り、前記送信端から前記受信側へと送るべき前記ファイルフォルダ中のファイルを前記ディレクトリ構造ファイルに従って決定し、前記受信端へ送るべき前記ファイルフォルダ中の前記ファイルを送信する。一実施形態において、前記プロセッサは、前記受信端から受信されたファイル送信リクエストに従って、前記ファイルフォルダ中の前記ファイルを決定する。

前記開示される方法は、ファイルフォルダ送信ユニットを用いてファイルフォルダ送信を管理し、送信端と受信端との間のファイルフォルダの送信を簡単なワンクリック動作だけで達成することができる。このようなファイルフォルダ送信における容易かつ簡便な動作に加えて、前記開示される方法はまた、ファイルフォルダのジッピングおよび圧縮に起因してシステムリソースが高い割合で占有されるという不利点も回避する。さらに、前記開示される方法およびシステムは、ブレイクポイント送信再開メカニズムを採用し得る。ネットワーク状態が悪い環境においてまたはネットワーク割り込み時において、前記開示される方法およびシステムにより、再接続時における前回の送信状態への素早い回復が可能になり、これにより、ファイルフォルダ送信がより安定しかつより信頼性のあるものになる。

本発明の概要はコンセプトの一部を簡単に導入するために示したものであり、これらのコンセプトについては、以下の発明を実施するための形態の中にさらに説明する。本発明の概要は、請求項記載の内容の主要な特徴または本質的な特徴を特定することを意図しておらず、また、請求項記載の内容の範囲の決定の支援として用いられることも意図していない。

詳細な説明について、添付図面を参照しながら記載する。図面中、参照符号の最左の桁（単数または複数）は、当該参照符号が初出する図面を示す。異なる図面において同一の参照符号が用いられている場合、当該参照符号は類似または同一のものを示す。

先行技術によるファイルフォルダ送信プロキシシステムの構造図である。 図１の先行技術のファイルフォルダ送信プロキシシステムのプロキシサーバの構造図である。 本開示の例示的実施形態によるファイルフォルダ送信システムの構造図である。 図３の例示的ファイルフォルダ送信システム中のファイルフォルダ送信ユニットの構造図である。 図３の例示的ファイルフォルダ送信システムの受信端の構造図である。 本開示によるファイルフォルダ送信の例示的方法のフローチャートである。 ファイルフォルダ送信の別の例示的方法のフローチャートである。 送信端と受信端との間のネットワーク接続の割り込み時の例示的ファイルフォルダ送信のフローチャートである。

ファイルフォルダ送信の方法およびシステムについて、添付図面を用いて詳細に説明する。

図３は、本開示の例示的実施形態によるファイルフォルダ送信システムの構造図を示す。ファイルフォルダ送信システム３００は、送信端３０１と、ファイルフォルダ送信ユニット３０３と、受信端３０５とを含む。ファイルフォルダ送信ユニット３０３は、送信端３０１と接続し、ネットワーク３０７を通じて受信端３０５に接続する。

送信端３０１および受信端３０５はそれぞれ、ユーザ端末（例えば、パーソナルコンピュータ、モバイルデバイスまたはネットワーククライアント）であり得る。ファイルフォルダ送信ユニット３０３は、スタンドアロンデバイス、サーバ（または前記サーバ上にインストールされたコンポーネント）、または送信端３０１と同一マシン上にインストールされたコンポーネント（ソフトウェア、ハードウェアまたはその組み合わせ）のいずれかであり得る。一実施形態において、送信端３０１および／または受信端２０５はそれぞれ、インスタントメッセージングクライアントを有する。

図４は、図３の例示的ファイルフォルダ送信システムにおいて用いられるファイルフォルダ送信ユニットの構造図を示す。ファイルフォルダ送信ユニット４０３（３０３）は、ディレクトリ管理モジュール４１１と、ネットワーク送信モジュール４１３と、ファイルフォルダ送信動作論理モジュール４１５とを含む。ディレクトリ管理モジュール４１１は、送信端３０１から送られるべきファイルフォルダのディレクトリ構造ファイルを生成するために用いられる。ディレクトリ構造ファイルは、特性（例えば、前記ファイルフォルダのサイズ、前記ファイルフォルダ中のファイルの経路および経路長さ、およびサブフォルダの同様の情報）を含み得る。ディレクトリ管理モジュール４１１は、前記ファイルフォルダ中のファイルを横断し、前記ディレクトリ構造ファイルの特性（例えば、前記ファイルフォルダによって占有されるハードディスク上のスペース（サイズ）（前記ファイルフォルダ中に含まれるファイルを含む）、前記ファイルフォルダ中のサブファイルフォルダおよびサブファイル（サブフォルダ中のファイル）の経路および経路長さ）を計算する。その後、ディレクトリ管理モジュール４１１は、送信端３０１を通じて前記ディレクトリ構造ファイルを受信端３０５へと送る。

ネットワーク送信モジュール４１３は、送信端３０１と受信端３０５との間のネットワーク状態に基づいて、ネットワークデータ送信チャンネルを確立するために、用いられる。ファイルフォルダ送信動作論理モジュール４１５は、前記ネットワークデータ送信チャンネルを通じて前記ファイルフォルダ中の前記ファイルを受信端３０５へと送るために、用いられる。

一実施形態において、ファイルフォルダ送信ユニット４０３（３０３）は、前記ファイルフォルダ中のファイルのうちどれを前記送信端から前記受信側へと送るべきかを決定する。これは、受信端３０５から送られたファイル取得リクエストを受け取ることにより、行われ得る。このファイル取得リクエストは、送信すべき前記ファイルフォルダ中の前記ファイルを指定する。受信端３０５は、受信されたディレクトリ構造ファイルと、受信端３０５において既に保存されているファイルとを比較して分析することにより、前記送信すべきファイルを決定することができる。

ファイルフォルダ送信ユニット３０３（４０３）は、ソフトウェアまたはハードウェアまたはその組み合わせのいずれかによって実装可能であり、スタンドアロンデバイスまたは送信端３０１と同一のマシン上にインストールされたコンポーネントのいずれかであり得る点に留意されたい。

図５は、図３の例示的ファイルフォルダ送信システムの受信端の構造図を示す。受信端５０５（３０５）は、ファイル取得リクエストモジュール５２１と、ファイル分析モジュール５２３と、ブレイクポイント情報取得モジュール５２５とを含む。ファイル取得リクエストモジュール５２１は、ファイル取得リクエストを送信端３０１に送るために用いられる。前記ファイル取得リクエストは、ディレクトリ構造ファイルに基づいており、受信端３０５が前記ディレクトリ構造ファイルを受信および分析した後に形成される。ファイル分析モジュール５２３は、ファイル取得リクエストモジュール５２１と接続され、かつ、前記ファイルフォルダ中の送信すべきファイルが受信端３０５の受信側ディレクトリ内に存在するか否かについて分析するために用いられる。前記分析は、前記受信されたディレクトリ構造ファイルと、前記受信端において保存された既存のファイルとを比較することに基づく。ファイル分析モジュール５２３は、分析結果をファイル取得リクエストモジュール５２１に送って、ファイル取得リクエストを形成する。

ブレイクポイント情報取得モジュール５２５は、ファイル取得モジュール５２１に接続され、前記ディレクトリ構造ファイルまたは前記ファイルフォルダの送信割り込みのブレイクポイント情報を取得するために用いられる。これは、受信端３０５と送信端３０１との間のネットワーク接続が切断および再接続された後に、行われ得る。前記ブレイクポイント情報は、前記ディレクトリ構造ファイルまたは前記ファイルフォルダ内における、ネットワーク接続が回復したときの送信再開位置として適切な位置を示す。ブレイクポイント情報取得モジュール５２５は、送信割り込みのブレイクポイント情報をファイル取得リクエストモジュール５２１へと送る。ファイル取得リクエストモジュール５２１は、送信リクエストを適宜形成して、これにより、前記ディレクトリ構造ファイルまたは前記ファイルフォルダの送信が前記ブレイクポイント情報によって示されている情報から再開されることを確実にする。

ファイルフォルダ送信システム３００を用いたファイルフォルダ送信の例示的アプリケーションにおいて、送信端３０１は、先ず、送信すべきファイルフォルダを選択する。前記ファイルフォルダを送るためのボタンがクリックされると、ファイルフォルダ送信ユニット３０３は、ディレクトリ管理モジュール４１１を開始する。ディレクトリ管理モジュール４１１は、統計スレッドを開始し、前記選択されたファイルフォルダのディレクトリ構造を横断して、ファイルおよび前記選択されたファイルフォルダ中のファイルおよびフォルダ構造を分析する。それと同時に、ディレクトリ管理モジュール４１１は、前記ファイルフォルダによって占有されるディスク中のスペース（サイズ）と、前記ファイルフォルダ中の前記ファイル、サブファイルフォルダ、およびサブファイルの経路および経路長さとを計算し、ディレクトリ構造ファイルを生成する。表１は、本開示によるディレクトリ構造ファイルの例示的フォーマットを示す。

前記ファイルフォルダ中のファイルフォルダおよびファイルのサイズは、６４ビットの整数として保存され得る。ファイルフォルダ中の最大送信可能データ量は、例えば２３４ＧＢに設定され得る。あるいは、送信すべき個々のファイルフォルダのサイズに対してキャップを設定してもよい。サイズが前記キャップ以下であるファイルフォルダは、本明細書中説明する変換方法を用いて直接送信してもよい。前記キャップよりも大きなサイズのいかなるファイルフォルダも送信可能であるが、この場合、ファイルリレーサーバを使用する必要があり得、これにより動作コストが低減する。

このようにして生成されたディレクトリ構造ファイルは、インデックスファイルを用いて特定され得る。例えば、前記ファイルフォルダの横断時において、送信端３０１は、メッセージダイジェストアルゴリズム（例えば、ｍｄ５アルゴリズム）を用いて、前記生成されたディレクトリ構造ファイルから１６ビットのハッシュコードを抽出する。この１６ビットのハッシュコードは、前記ディレクトリ構造ファイルの一意の識別子として機能する。

ファイルフォルダ送信前に、送信端３０１は、先ず、メッセージング通信チャンネル（例えば、ＱＱなどの通信ツール）を通じてファイルフォルダ送信リクエストを受信端３０５に送り得る。受信端３０５が前記ファイルフォルダの送信について同意した場合、送信端３０１は、ファイルフォルダ送信ユニット４０３（３０３）中のネットワーク送信モジュール４１３を呼び出し、指定されたネットワークデータ送信チャンネルを確立する。前記ネットワークデータ送信チャンネルは、送信端３０１および受信端３０５のネットワーク状態に応じて、Ｐ２Ｐ（ピアツーピアネットワーキング）送信チャンネルまたはサーバのリレーチャンネルのいずれかであり得る。指定されたネットワークデータ送信チャンネルにより、より高速かつより安全なファイルフォルダ送信が可能となる。

前記ネットワークデータ送信チャンネルが確立された後、送信端３０１は、先ず前記ネットワークデータ送信チャンネルを通じて前記ディレクトリ構造ファイルのハッシュコードを受信端３０５に送る。前記ディレクトリ構造ファイルの前記ハッシュコードを受信すると、受信端３０５は、この目的のために配置構成されたディレクトリ内に前記ディレクトリ構造ファイルの前記ハッシュコードが存在するか否かについて調査する。前記ディレクトリ構造ファイルの前記ハッシュコードが存在しない場合、送信端３０１は、前記ネットワークデータ送信チャンネルを通じて前記ディレクトリ構造ファイルを受信端３０５へと送る。

送信端３０１から前記ディレクトリ構造ファイルを受信すると、受信端３０５は、先ず、前記ファイルフォルダを保存するために配置構成された受信側ディレクトリが前記ファイルフォルダを保存するためのディスクスペース要求を満たすか否かについてと、前記ファイルフォルダ中のサブファイルフォルダおよびサブファイルのいずれかの経路長さが受信端３０５のオペレーティングシステムの経路長さ上限を越えるか否かについてについて決定する。前記要求が満たされる場合、ファイル分析モジュール５２３は、前記ファイルフォルダ中のいずれかのファイルが受信端３０５の受信側ディレクトリ内に既に存在するか否かについて分析し、分析結果をファイル取得リクエストモジュール５２１に送る。ファイル分析モジュール５２３によって得られた分析結果に基づいて、ファイル取得リクエストモジュール５２１は、取得リクエストを形成し、前記取得リクエストを送信端３０１に送る。前記取得リクエストは、前記ファイルフォルダ中のファイルのうち前記受信側ディレクトリ中に既に存在していないため送信する必要があるファイルを指定する。その後、送信端３０１は、前記取得リクエストに従って、前記リクエストされた前記ファイルフォルダ中のファイルを受信端３０５に送る。

ファイル経路およびファイル名に加えて、同一ファイルの異なるバージョンをさらに特定するためにタイムスタンプを用いることができる。ファイル取得リクエストは、受信端３０５の受信側ディレクトリ内により古いバージョンのファイルが既に存在している場合でも、より新規のバージョンのファイルを送信する必要があることを示し得る。

送信端３０１と受信端３０５との間のネットワーク接続に割り込みが発生し、ファイルフォルダの送信中に切断および再接続された場合、受信端３０５内のブレイクポイント情報取得モジュール５２５は、前記ファイルフォルダの送信割り込みのブレイクポイント情報を取得する。前記ブレイクポイント情報は、前記ネットワークが切断されたときの前記ファイルフォルダの送信位置を示す。ブレイクポイント情報取得モジュール５２５は、前記ブレイクポイント情報をファイル取得リクエストモジュール５２１へ送り、その後、ファイル取得リクエストモジュール５２１は、前記ブレイクポイント情報に基づいて、ファイル取得リクエストを送信端５０１に送る。前記ブレイクポイント情報により、前記ブレイクポイント情報によって示されている適切な位置から前記ファイルフォルダの送信が開始されることが確実になる。ディレクトリ構造ファイルの送信中に送信端３０１と受信端３０５との間のネットワーク接続が切断および再接続された場合、ブレイクポイント情報取得モジュール５２５は、前記ディレクトリ構造ファイルの送信割り込みのブレイクポイント情報も取得し得る。バックボーン情報も同様に受信端３０５によって送信端３０１に送られ、これにより、前記ブレイクポイント情報によって示されている適切な位置から前記ディレクトリ構造ファイルの送信が開始されることが確実になる。

本開示は、ファイルフォルダ送信の装置をさらに提供する。前記ファイルフォルダ送信のための装置の構造および機能は上記ファイルフォルダ送信システム内のファイルフォルダ送信ユニット４０３（３０３）と同一であるため、説明を省略する。本記載において、「ユニット」とは、特定のタスクまたは機能を行うように設計されたデバイス、ツールまたはマシンであり得る。ユニットまたはデバイスは、前記特定のタスクまたは機能に関連する目的を実施するための、ハードウェア、ソフトウェア、計画またはスキームあるいはその組み合わせの一つであり得る。

本開示は、ファイルフォルダ送信のための方法をさらに提供する。前記方法の例示的実施形態について、プロセスのフローチャートを用いて以下に詳細に説明する。本説明において、プロセスを説明する順序は限定として解釈されることを意図しておらず、任意の数の以下に説明するプロセスブロックを任意の順序で組み合わせて、前記方法または別の方法を実施することができる。

図６は、本開示による例示的なファイルフォルダ送信方法のフローチャートを示す。ファイルフォルダ送信のための例示的プロセスは、以下の手順を含む。

ブロックＳ６０１において、ファイルフォルダのディレクトリ構造ファイルを生成する。前記ディレクトリ構造ファイルは、前記ファイルフォルダのサイズ、前記ファイルフォルダ中のファイルの経路および経路長さを含む特性を有する。前記ディレクトリ構造ファイルの特性は、前記ファイルフォルダ中のサブフォルダのサイズならびに前記サブフォルダ中のファイルの経路および経路長さをさらに含み得る。前記ディレクトリ構造ファイルは、前記ファイルフォルダを横断し、前記ディレクトリ構造ファイルの前記特性を計算することにより、生成され得る。表１は、ディレクトリ構造ファイルの例示的フォーマットを示す。

ファイルフォルダおよび前記ファイルフォルダ中のファイルのサイズは、６４ビットの整数を用いて記述される。ファイルフォルダに対する最大データ送信量が設定され得る（例えば、２３４ＧＢ）。あるいは、ファイルフォルダのサイズに対してキャップを設定してもよい。

ブロック６０２において、前記ディレクトリ構造ファイルを送信端から受信端へと送る。

前記ディレクトリ構造ファイルを送る前に、前記送信端は、メッセージング通信チャンネル（例えば、インスタントメッセージング通信ツール）を通じて、ファイルフォルダ送信リクエストを受信端に送り得る。

前記ディレクトリ構造ファイルを送る前に、前記受信端は、先ず、前記受信端が既に前記ディレクトリ構造ファイルを有するか否かについて決定することもできる。前記受信端が既に前記ディレクトリ構造ファイルを有するか否かについて決定するための例示的方法として、本明細書中記載されるインデックス識別子の使用がある。

前記ディレクトリ構造ファイルの送信およびその後の前記ファイルフォルダの送信を容易化するために、前記送信端および受信端のネットワーク状態に応じて、ネットワークデータ送信チャンネルが確立され得る。前記ネットワークデータ送信チャンネルは、前記送信端および前記受信端のネットワーク状態に応じて、Ｐ２Ｐ（ピアツーピアネットワーキング）送信チャンネルまたはサーバのリレーチャンネルのいずれかであり得る。指定されたネットワークデータ送信チャンネルにより、より高速かつより安全なファイルフォルダ送信が可能となる。

前記ディレクトリ構造ファイルを前記送信端から受信すると、前記受信端は、先ず、前記ファイルフォルダを保存するための受信側ディレクトリの配置構成がディスクを占有するための前記ファイルフォルダのスペース要求を満たすかと、前記ファイルフォルダ中のサブファイルフォルダおよびサブファイルのいずれかの経路長さが前記受信端のオペレーティングシステムの経路長さ上限を越えるか否かについて決定し得る。前記要求が満たされる場合、前記方法は、次の段階に進み得る。

ブロック６０３において、前記送信端から前記受信側へと送信すべき前記ファイルフォルダ中のファイルを前記ディレクトリ構造ファイルに従って決定する。前記決定は、前記受信端における前記ディレクトリ構造ファイルを分析することにより、行われ得る。例えば、前記受信端は、前記ディレクトリ構造ファイルと、前記受信端における受信側ディレクトリにおいて既に保存されているファイルとを比較して、どのファイルを送信すべきか否かを決定することができる。この後、前記受信端は、ファイル取得リクエストを送って、前記送信すべきファイルをリクエストすることができる。

ブロック６０４において、前記ファイルフォルダ中の送信すべきファイルを前記受信端に送る。ネットワーク接続割り込みが発生した場合、前記ディレクトリ構造ファイルまたは前記ファイルフォルダの送信割り込みのブレイクポイント情報を得ることで、前記ブレイクポイント情報によって示されている位置から前記送信が再開されることを確実にすることができる。

図７は、本開示による別の例示的ファイルフォルダ送信方法のフローチャートを示す。

ブロック７０１において、前記システムは、送信端によって送られるべきファイルフォルダ中のファイルを横断し、前記ファイルフォルダのサイズ、前記ファイルフォルダ中のサブファイルフォルダおよびサブファイルの経路および経路長さを計算して、前記システムが示すディレクトリ構造ファイルを生成する。表１は、前記ディレクトリ構造ファイルの例示的フォーマットを示す。

ブロック７０３において、前記送信端は、メッセージング通信チャンネル（例えば、インスタントメッセージング通信ツール）を通じて、ファイルフォルダ送信リクエストを受信端に送る。利用可能なインスタントメッセージング通信ツールとしては、ＱＱ、ＭＳＮおよびＡｌｉＷａｎｇＷａｎｇが挙げられる。

ブロック７０５において、前記受信端が前記ファイルフォルダ送信リクエストに同意した場合、前記送信端および受信端のネットワーク状態に従って、ネットワークデータ送信チャンネルを確立する。前記ネットワークデータ送信チャンネルは、前記送信端および前記受信端のネットワーク状態に応じて、Ｐ２Ｐ（ピアツーピアネットワーキング）送信チャンネルまたはサーバのリレーチャンネルのいずれかであり得る。前記指定されたネットワークデータ送信チャンネルにより、より高速かつより安全なファイルフォルダ送信が可能となる。

ブロック７０７において、前記ネットワークデータ送信チャンネルを通じて前記ディレクトリ構造ファイルのインデックス識別子を前記受信端に送り、前記ディレクトリ構造ファイルが既に前記受信端に存在するか否かを決定する。前記インデックス識別子は、メッセージダイジェストアルゴリズム（例えば、ｍｄ５アルゴリズム）を用いて前記ディレクトリ構造ファイルから抽出された１６ビットの一意の識別子（ハッシュコード）であり得る。前記ディレクトリ構造ファイルの前記ハッシュコードを受信すると、前記受信端は、事前同意されたディレクトリに前記ディレクトリ構造ファイルの前記ハッシュコードが既に存在するかについて調査する。同一ハッシュコードの存在は、前記受信端が既に前記ディレクトリ構造ファイルを受信していることを示す。

７０９において、前記ディレクトリ構造ファイルの前記ハッシュコードが前記受信端の前記事前同意されたディレクトリ内に存在しない場合、前記送信端は、前記ネットワークデータ送信チャンネルを通じて前記ディレクトリ構造ファイルを前記受信端へと送る。

７１１において、前記ディレクトリ構造ファイルを受信および分析した後、前記受信端はファイル取得リクエストを前記送信端に送る。前記ファイル取得リクエストは、前記ディレクトリ構造ファイルの分析結果に基づいて形成される。

例えば、前記ディレクトリ構造ファイルを前記送信端から受信した後、前記受信端は、先ず、前記ファイルフォルダを保存先としての受信側ディレクトリが前記ファイルフォルダを保存するためのサイズ（スペース）要求を満たすかについてと、前記ファイルフォルダ中のサブファイルフォルダおよびサブファイルのいずれかの経路長さが前記受信端のオペレーティングシステムの経路長さ上限を越えるかに否かについて決定する。要求が満たされる場合、前記受信端は、前記ファイルフォルダ中のいずれかのファイルが既に前記受信端の前記受信側ディレクトリ内に存在するかについて分析する。前記分析結果に基づいて、前記受信端は、取得リクエストを形成し、前記取得リクエストを前記送信端に送る。前記取得リクエストは、前記受信側ディレクトリに既に存在していないため送信されるべきファイルを示す。

７１３において、前記送信端は、前記受信したファイル取得リクエストに従って、前記ファイルフォルダ中の前記ファイルを前記ネットワークデータ送信チャンネルを通じて前記受信端に送る。

本開示におけるファイルフォルダ送信のための方法は、ブレイクポイント再送信のメカニズムも採用し得る。送信端と受信端との間のネットワーク接続が切断および再接続された場合、送信割り込みのブレイクポイント情報を得ることができる。前記ブレイクポイント情報は、送信されているデータ（ディレクトリ構造ファイルまたはファイルフォルダのいずれか）中の前記ネットワーク切断時のポイントを規定する。前記ブレイクポイント情報により、前記ディレクトリ構造ファイルまたは前記ファイルフォルダの送信を前記ブレイクポイント情報によって示される適切な位置から開始することが確実になる。

図８は、送信端と受信端との間のネットワーク接続が切断および再接続された後の例示的ファイルフォルダ送信のフローチャートを示す。

ブロック８０１において、前記受信端は、ファイルダイジェスト情報を前記送信端から入手する。

ブロック８０３において、前記受信端は、前記ファイルダイジェスト情報に基づいてブレイクポイント付きのファイルが存在するかについて調査し、このようなファイルが存在する場合、ブレイクポイント情報を入手する。

ブロック８０５において、前記受信端は、前記ブレイクポイント情報を含むファイル取得リクエストを前記送信端に送る。

ブロック８０７において、前記送信端は、前記ブレイクポイント情報によって示されている位置から開始する前記ファイルフォルダを送信する。

ファイルフォルダ送信のためにファイルフォルダ送信ユニットを用いることで、前記開示される方法では、簡単なワンクリック動作だけで、送信端と受信端との間のファイルフォルダ送信を達成することができる。動作の簡単さおよび簡便さに加え、前記開示される方法は、ファイルフォルダのジッピングおよび圧縮に起因してシステムリソースが高い割合で占有されるという不利点も回避する。さらに、前記開示される方法およびシステムは、送信のためのブレイクポイント再開メカニズムと共に用いることができる。貧弱なネットワーク条件下でまたは何らかの理由に起因してネットワーク接続が停止した場合、前記開示される方法およびシステムにより、再接続時に以前の送信状態へ素早く回復させることが可能になり、これにより、ファイルフォルダ送信がより安定かつより信頼性のあるものとなる。

実装環境
前記開示される方法およびシステムは、ハードウェアのみを用いて実装可能であるが、好ましくはソフトウェアおよびハードウェアの組み合わせを用いて実装すべきである点に留意されたい。前記開示される方法そのものは、保存媒体中に保存されたソフトウェア製品の形態で実装可能である。前記ソフトウェアは、本開示の例示的実施形態中に記載の方法を実行するための、コンピュータデバイス（スタンドアロン型またはネットワーク型のいずれか）に対する命令を含む。

具体的には、上記した技術は、コンピュータデバイス（例えば、サーバまたはパーソナルコンピュータ（ＰＣ））の支援により、実行され得る。コンピュータデバイスは、プロセッサ（単数または複数）、Ｉ／Ｏデバイス、コンピュータ可読媒体、およびネットワークインターフェースを含み得る。前記コンピュータデバイスは、クライアント側またはサーバ側に接続することができる。クライアント側のコンピュータデバイスはそれぞれ、ユーザ端末として用いられるコンピュータまたはポータブルデバイスであってもよい。

前記コンピュータ可読媒体は、アプリケーションプログラムモジュールおよびデータを保存していてもよい。アプリケーションプログラムモジュールは、プロセッサ（単数または複数）によって実行されると、前記プロセッサ（単数または複数）が、本明細書中記載のプロセスのアクション（例えば、図５〜図７の図示のプロセス）を行う命令を含む。コンピュータ可読媒体内に保存されている命令を実行することにより実行可能な例示的プロセスは、
前記ファイルフォルダのディレクトリ構造ファイルを生成するステップであって、前記ディレクトリ構造ファイルは、前記ファイルフォルダのサイズ、前記ファイルフォルダ中のファイルの経路および経路長さなどの特性を有する、ステップと、
前記ディレクトリ構造ファイルを前記送信端から前記受信端へと送るステップと、
前記ディレクトリ構造ファイルに従って、前記送信端から前記受信側へと送信すべき前記ファイルフォルダ中のファイルを決定するステップと、
前記受信端に送信すべき前記ファイルフォルダ中の前記ファイルを送信するステップである。

前記コンピュータ可読媒体は、コンピュータデータを保存するための任意の適切な記憶装置またはメモリデバイスでよいことが理解される。このような記憶装置またはメモリデバイスとしては、ハードディスク、フラッシュメモリデバイス、光学的データ記憶装置およびフロッピー（登録商標）ディスクが挙げられるが、これらに限定されない。さらに、コンピュータ実行可能な命令を含むコンピュータ可読媒体は、ローカルシステム内のコンポーネント（単数または複数）または複数のリモートシステムのネットワーク上に分散したコンポーネントからなり得る。前記コンピュータ実行可能な命令のデータは、有形の物理的メモリデバイスに入れて供給されてもよいし、あるいは電子的に送信されてもよい。

本明細書中記載される潜在的な恩恵および利点は、添付の特許請求の範囲の限定または制限として解釈されるべきではないことが理解される。

本内容について構造的特徴および／または方法論的動作に特有の用語で説明してきたが、添付の特許請求の範囲中に定義される本内容は必ずしも上記した特定の特徴または動作に限定されないことが理解される。むしろ、前記特定の特徴または動作は、これらの請求項の実施の例示的形態として開示されるものである。

Claims (17)

1. 受信端がファイルフォルダのディレクトリ構造ファイルを含むかどうかを決定するステップであって、前記ディレクトリ構造ファイルは、前記ファイルフォルダに関する特性を含み、前記ファイルフォルダを横断して前記ディレクトリ構造ファイルの前記特性を計算することによって生成され、
   前記ファイルフォルダの前記ディレクトリ構造ファイルのインデックス識別子を生成することと、
   前記インデックス識別子を前記受信端に送信することであって、前記インデックス識別子は、前記受信端が前記ディレクトリ構造ファイルを含むかどうかを、前記受信端が決定することを可能にすることと、を含む前記決定するステップと、
   前記受信端が前記ファイルフォルダのディレクトリ構造ファイルを含まないと決定すると、前記ファイルフォルダの前記ディレクトリ構造ファイルを前記受信端に送信するステップと、
   前記受信端に送信されるべき前記ファイルフォルダ中のファイルを決定するステップと、
   前記受信端に送信されるべき前記ファイルフォルダ中の前記ファイルを送信するステップと
   を含むことを特徴とする方法。
2. 前記ディレクトリ構造ファイルの前記特性は、前記ファイルフォルダのサイズ、前記ファイルフォルダ中のファイルの経路、および／または前記ファイルの経路長さを含むことを特徴とする請求項１に記載の方法。
3. 前記ディレクトリ構造ファイルの前記特性は、前記ファイルフォルダ中のサブフォルダのサイズ、前記サブフォルダ中のファイルの経路、および／または前記サブフォルダ中の前記ファイルの経路長さを含むことを特徴とする請求項１または２に記載の方法。
4. 前記送信されるべき前記ファイルフォルダ中の前記ファイルを決定するステップは、前記受信端から前記ディレクトリ構造ファイルの分析結果を受信するステップを含むことを特徴とする請求項１ないし３のいずれか１項に記載の方法。
5. ファイル取得リクエストを前記受信端から受信するステップであって、前記ファイル取得リクエストは、送信されるべき前記ファイルフォルダ中の前記ファイルのリクエストを含む、ステップをさらに含むことを特徴とする請求項１ないし４のいずれか１項に記載の方法。
6. ファイルフォルダ送信リクエストをインスタントメッセージングチャンネルを通じて前記受信端に送信するステップをさらに含むことを特徴とする請求項１ないし５のいずれか１項に記載の方法。
7. 前記受信端とのネットワークの状態に基づいてネットワークデータ送信チャンネルを確立するステップをさらに含むことを特徴とする請求項１ないし６のいずれか１項に記載の方法。
8. 前記インデックス識別子は、メッセージダイジェストアルゴリズムを用いて前記ディレクトリ構造ファイルから抽出された１６ビットの一意の識別子であることを特徴とする請求項１ないし７のいずれか１項に記載の方法。
9. 前記受信端とのネットワーク接続の割り込みが発生した場合、前記方法は、
   前記ディレクトリ構造ファイルまたは前記ファイルフォルダの送信割り込みのブレイクポイント情報を取得するステップと、
   前記ブレイクポイント情報によって示された位置から前記送信を再開するステップと
   をさらに含むことを特徴とする請求項１ないし８のいずれか１項に記載の方法。
10. 前記ファイルフォルダのサイズは、６４ビットの整数を用いて記述されることを特徴とする請求項１ないし９のいずれか１項に記載の方法。
11. １つまたは複数のプロセッサと、
    メモリと、
    前記メモリに保存され、受信端がファイルフォルダのディレクトリ構造ファイルを含むかどうかを決定するように適合される前記１つまたは複数のプロセッサによって実行可能なファイルディレクトリ管理モジュールであって、前記ディレクトリ構造ファイルは、前記ファイルフォルダに関する特性を含み、前記ファイルフォルダを横断して前記ディレクトリ構造ファイルの前記特性を計算することによって生成され、前記ファイルディレクトリ管理モジュールは、前記ファイルフォルダの前記ディレクトリ構造ファイルのインデックス識別子を生成して、前記インデックス識別子を前記受信端に送信することによって、前記受信端が、前記ファイルフォルダの前記ディレクトリ構造ファイルを含むかどうかを決定し、前記インデックス識別子は、前記受信端が前記ディレクトリ構造ファイルを含むかどうかを、前記受信端が決定することを可能にする、ファイルディレクトリ管理モジュールと、
    前記メモリに保存され、前記ディレクトリ構造ファイルに従って、前記受信端に送信されるべき前記ファイルフォルダ中のファイルを決定するように適合される前記１つまたは複数のプロセッサによって実行可能なファイルフォルダ送信動作論理モジュールと、
    前記メモリに保存され、前記ファイルディレクトリ管理モジュールが、前記受信端が前記ファイルフォルダのディレクトリ構造ファイルを含まないと決定すると、前記ディレクトリ構造ファイルを前記受信端に送信し、前記受信端に送信されるべき前記ファイルフォルダ中の前記ファイルを送信するように適合される前記１つまたは複数のプロセッサによって実行可能なネットワーク送信モジュールと
    を含むことを特徴とする装置。
12. 前記ファイルフォルダ送信動作論理モジュールは、ファイル取得リクエストを前記受信端から受信するようにさらに適合され、前記ファイル取得リクエストは、前記送信されるべきファイルフォルダ中の前記ファイルをリクエストすることを特徴とする請求項１１に記載の装置。
13. 前記装置は、ファイルフォルダ送信リクエストをインスタントメッセージングチャンネルを通じて前記受信端に送信するように適合されることを特徴とする請求項１１または１２に記載の装置。
14. 前記ネットワーク送信モジュールは、前記受信端におけるネットワーク状態に基づいてネットワークデータ送信チャンネルを確立するようにさらに適合されることを特徴とする請求項１１ないし１３のいずれか１項に記載の装置。
15. 前記ディレクトリ構造ファイルの前記特性は、前記ファイルフォルダのサイズ、前記ファイルフォルダ中のファイルの経路、および／または前記ファイルの経路長さを含むことを特徴とする請求項１１ないし１４のいずれか１項に記載の装置。
16. 複数の命令を保存している１つまたは複数の記憶装置であって、前記命令がプロセッサによって実行されると、前記プロセッサは、
    受信端がファイルフォルダのディレクトリ構造ファイルを含むかどうかを決定するステップであって、前記ディレクトリ構造ファイルは、前記ファイルフォルダに関連付けられた特性を含み、前記ファイルフォルダを横断して前記ディレクトリ構造ファイルの前記特性を計算することによって生成され、
    前記ファイルフォルダの前記ディレクトリ構造ファイルのインデックス識別子を生成することと、
    前記インデックス識別子を前記受信端に送信することであって、前記インデックス識別子は、前記受信端が前記ディレクトリ構造ファイルを含むかどうかを、前記受信端が決定することを可能にすることと、を含む前記決定するステップと、
    前記受信端が前記ファイルフォルダのディレクトリ構造ファイルを含まないと決定すると、前記ファイルフォルダの前記ディレクトリ構造ファイルを前記受信端に送信するステップと、
    前記ディレクトリ構造ファイルに従って、前記受信端に送信されるべき前記ファイルフォルダ中のファイルを決定するステップと、
    前記受信端に送信されるべき前記ファイルフォルダ中の前記ファイルを送信するステップと
    の動作を実行することを特徴とする１つまたは複数の記憶装置。
17. 前記送信されるべき前記ファイルフォルダ中の前記ファイルを決定するステップは、前記受信端から受信されたファイル送信リクエストに従って、送信されるべき前記ファイルフォルダ中の前記ファイルを決定することを特徴とする請求項１６に記載の１つまたは複数の記憶装置。