(57)【要約】【課題】  未処理のファイルへ上書きすることなく簡易にファイルの送受信を行なうことのできる送信装置及び受信装置を提供する。【解決手段】  受信装置２０にデータファイルを送信する送信装置１０であって、データファイルに対応付けられたフラグファイルが受信装置２０に存在するか否かを確認する送信先フラグ確認部１７と、フラグファイルが存在しないと確認された場合に、データファイルを受信装置２０に送信する送信部１２と、データファイルの送信が正常に完了したか否かを確認する送信完了判定部１５とを備え、送信部１２はデータファイルの送信が正常に完了したと判定された場合に、データファイルに対応付けられたフラグファイルを受信装置２０に送信する。【選択図】      図３
2006209380.tif 000002
【特許請求の範囲】
【請求項１】
受信装置にデータファイルを送信する送信装置であって、
前記データファイルに対応付けられた制御ファイルが前記受信装置に存在するか否かを確認する制御ファイル確認手段と、
前記制御ファイルが存在しないと確認された場合に、前記データファイルを前記受信装置に送信するデータファイル送信手段と、
前記データファイルの送信が正常に完了したか否かを判定する送信完了判定手段と、
前記データファイルの送信が正常に完了したと判定された場合に、前記データファイルに対応付けられた制御ファイルを前記受信装置に送信する制御ファイル送信手段と
を備えることを特徴とする送信装置。
【請求項２】
前記制御ファイル確認手段は、前記受信装置から前記制御ファイルの取得を試み、前記制御ファイルを取得することができない場合に、前記制御ファイルが前記受信装置に存在しないと判断する
ことを特徴とする請求項１記載の送信装置。
【請求項３】
前記送信完了判定手段は、前記データファイル送信手段によって前記データファイルが前記受信装置に送信された後に前記受信装置から前記データファイルを取得し、取得したデータファイルと前記データファイル送信手段によって送信される前のデータファイルとを比較し、それらデータファイルの内容が一致する場合に、前記データファイルの送信が正常に完了したと判定する
ことを特徴とする請求項１記載の送信装置。
【請求項４】
前記制御ファイル送信手段は、前記データファイルの送信が正常に完了したと判定された場合に、前記データファイルと識別名が同一で、かつ、拡張子が異なるファイル名の制御ファイルを生成し、生成した制御ファイルを前記受信装置に送信し、
前記制御ファイル確認手段は、前記データファイルと識別名が同一で、かつ、拡張子が異なるファイル名の制御ファイルが存在するか否かを確認する
ことを特徴とする請求項１記載の送信装置。
【請求項５】
前記制御ファイル送信手段は、前記データファイルの送信が正常に完了したと判定された場合に、ファイル容量が予め定められた一定サイズの制御ファイルを生成し、生成した制御ファイルを前記受信装置に送信し、
前記制御ファイル確認手段は、前記制御ファイルが存在し、かつ、ファイル容量が前記一定サイズである場合に、前記制御ファイルが前記受信装置に存在すると判断する
ことを特徴とする請求項１記載の送信装置。
【請求項６】
送信装置からデータファイルを受信する受信装置であって、
前記データファイルを受信するデータファイル受信手段と、
前記データファイルに対応付けられた制御ファイルを受信する制御ファイル受信手段と、
前記制御ファイルが前記受信装置に存在するか否かを確認する制御ファイル確認手段と、
前記制御ファイルが存在すると確認された場合に、前記データファイルに対する処理を実行する処理実行手段と、
前記処理が終了した後に前記制御ファイルを消去する制御ファイル消去手段と
を備えることを特徴とする受信装置。
【請求項７】
前記処理実行手段は、前記制御ファイルと識別名が同一で、かつ、拡張子が異なるファイル名のデータファイルに対する処理を実行する
ことを特徴とする請求項６記載の受信装置。
【請求項８】
前記制御ファイル確認手段は、更に、前記制御ファイルのファイル容量が予め定められた一定サイズであるか否かを確認し、前記制御ファイルが存在し、かつ、前記一定サイズである場合に、前記制御ファイルが存在すると判断する
ことを特徴とする請求項６記載の受信装置。
【請求項９】
更に、前記送信装置から受信したデータファイルを、前記送信装置以外の第３の装置に送信するデータファイル中継手段
を備えることを特徴とする請求項６記載の受信装置。
【請求項１０】
更に、前記データファイルを保持するためのデータファイル記憶手段を備え、
前記処理実行手段は、前記データファイル受信手段が前記データファイルを受信するたびに、当該データファイルを前記データファイル記憶手段に格納し、
前記データファイル中継手段は、前記データファイル格納手段に格納された前記データファイルを古いデータファイルから読み出して前記第３の装置に送信する
ことを特徴とする請求項９記載の受信装置。
【請求項１１】
請求項１記載の送信装置と、請求項６記載の受信装置とを備える
ことを特徴とするファイル送受信システム。
【請求項１２】
受信装置にデータファイルを送信する送信方法であって、
前記データファイルに対応付けられた制御ファイルが前記受信装置に存在するか否かを確認する制御ファイル確認ステップと、
前記制御ファイルが存在しないと確認された場合に、前記データファイルを前記受信装置に送信するデータファイル送信ステップと、
前記データファイルの送信が正常に完了したか否かを判定する送信完了判定ステップと、
前記データファイルの送信が正常に完了したと判定された場合に、前記データファイルに対応付けられた制御ファイルを前記受信装置に送信する制御ファイル送信ステップと
を含むことを特徴とする送信方法。
【請求項１３】
送信装置からデータファイルを受信する受信方法であって、
前記データファイルを受信するデータファイル受信ステップと、
前記データファイルに対応付けられた制御ファイルを受信する制御ファイル受信ステップと、
前記制御ファイルが前記受信装置に存在するか否かを確認する制御ファイル確認ステップと、
前記制御ファイルが存在すると確認された場合に、前記データファイルに対する処理を実行する処理実行ステップと、
前記処理が終了した後に前記制御ファイルを消去する制御ファイル消去ステップと
を含むことを特徴とする受信方法。
【請求項１４】
受信装置にデータファイルを送信するためのプログラムであって、
前記データファイルに対応付けられた制御ファイルが前記受信装置に存在するか否かを確認する制御ファイル確認ステップと、
前記制御ファイルが存在しないと確認された場合に、前記データファイルを前記受信装置に送信するデータファイル送信ステップと、
前記データファイルの送信が正常に完了したか否かを判定する送信完了判定ステップと、
前記データファイルの送信が正常に完了したと判定された場合に、前記データファイルに対応付けられた制御ファイルを前記受信装置に送信する制御ファイル送信ステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項１５】
送信装置からデータファイルを受信するためのプログラムであって、
前記データファイルを受信するデータファイル受信ステップと、
前記データファイルに対応付けられた制御ファイルを受信する制御ファイル受信ステップと、
前記制御ファイルが前記受信装置に存在するか否かを確認する制御ファイル確認ステップと、
前記制御ファイルが存在すると確認された場合に、前記データファイルに対する処理を実行する処理実行ステップと、
前記処理が終了した後に前記制御ファイルを消去する制御ファイル消去ステップと
をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイルを送信する送信装置、及びファイルを受信する受信装置に関する。
【背景技術】
【０００２】
近年、複数のコンピュータ装置（以下、単に「装置」と称する。）によりネットワークが形成され、様々な目的で使用されている。例えば、生産実績管理などのデータ処理においては、ネットワークを利用することで、データ処理の対象となるデータファイルの生成と、データ処理の実行とが別の装置によって行なわれている。
【０００３】
つまり、処理が必要なデータファイルは、データファイルの生成が行なわれる送信側の装置（以下「送信装置」と称する。）からデータファイルの処理が実行される受信側の装置（以下「受信装置」と称する。）に送信される。
【０００４】
ここで、ある処理の対象となるデータファイルは、特定の起動プロセスにより同一の処理が繰り返し行なわれるなどの理由から、常に同一のファイル名が付されており、処理済のデータファイルは新規なデータファイルにより上書きされる。そのため、送信装置は、未処理のデータファイルの上書き防止のために、データファイルの送信前に、受信装置にあるデータファイルが処理済であるか否かの判断を行なう必要がある。
【０００５】
そこで、ファイル転送用のプロトコルであるＦＴＰ（File Transfer Protocol）を応用し、未処理のデータファイルを上書きすることなくデータファイルの送信を行なうファイル送信技術が開示されている（例えば特許文献１参照）。
【０００６】
上記従来のファイル送信技術では、送信装置は、データファイルを送信し、データファイルの正常な送信の完了を検出した場合、受信装置に管理ファイルと呼ばれるファイル容量０バイトのファイルを受信装置に送信する。受信装置では、管理ファイルの受信を確認後、データファイルの処理を行ない、処理の完了後、データファイル及び管理ファイルのファイル名をリネームする。
【０００７】
送信装置は、その後にデータファイルを送信する場合、受信装置にリネームされていないデータファイル及び管理ファイルがあるか否かを確認し、それら２つのファイルが存在しない場合に、データファイルを送信する。
【特許文献１】特開２００３−２９６１８０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記従来のファイル送信技術では、未処理のデータファイルの上書きを防止するためには、データファイルの送信前に、送信装置が、該当するデータファイル及び管理ファイルの２つのファイルが受信装置に存在するか否かを確認する必要があり、送信装置側の処理が煩雑である。
【０００９】
そこで、本発明は、上記課題を考慮し、未処理のファイルへ上書きすることなく簡易にファイルの送受信を行なうことのできる送信装置及び受信装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本発明に係る送信装置は、受信装置にデータファイルを送信する送信装置であって、前記データファイルに対応付けられた制御ファイルが前記受信装置に存在するか否かを確認する制御ファイル確認手段と、前記制御ファイルが存在しないと確認された場合に、前記データファイルを前記受信装置に送信するデータファイル送信手段と、前記データファイルの送信が正常に完了したか否かを判定する送信完了判定手段と、前記データファイルの送信が正常に完了したと判定された場合に、前記データファイルに対応付けられた制御ファイルを前記受信装置に送信する制御ファイル送信手段と
を備えることを特徴とする。
【００１１】
また、本発明に係わる受信装置は、送信装置からデータファイルを受信する受信装置であって、前記データファイルを受信するデータファイル受信手段と、前記データファイルに対応付けられた制御ファイルを受信する制御ファイル受信手段と、前記制御ファイルが前記受信装置に存在するか否かを確認する制御ファイル確認手段と、前記制御ファイルが存在すると確認された場合に、前記データファイルに対する処理を実行する処理実行手段と、前記処理が終了した後に前記制御ファイルを消去する制御ファイル消去手段とを備えることを特徴とする。
【００１２】
これによって、受信装置はデータファイルの処理が終了した後に制御ファイルを消去するため、送信装置は、制御ファイルが受信装置に存在しないことを確認するのみで、データファイルの処理が終了したことを知ることができる。
【００１３】
つまり、送信装置は、一つのファイルが受信装置に存在しないことを確認するのみで、未処理のデータファイルへ上書きすることなく、データファイルと同名のファイルを受信装置へ送信することができる。
【発明の効果】
【００１４】
本発明は、未処理のファイルへ上書きすることなく簡易にファイルの送受信を行なうことのできる送信装置及び受信装置を提供することができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
先ず、本発明の実施の形態の送信装置及び受信装置の構成を、図１〜図３を用いて説明する。
【００１６】
図１は、本発明の実施の形態の送信装置１０及び受信装置２０のハードウェア構成図である。図１は本発明に係る送信装置１０と本発明に係る受信装置２０とが通信回線５０を介して互いに接続されている様子を示している。
【００１７】
送信装置１０は、データファイルを生成し、受信装置２０に送信する装置である。受信装置２０は、データファイルを受信し、受信したデータファイルを対象にデータ処理を行なう装置である。なお、ファイルの送受信に使用するプロトコルはＦＴＰである。
【００１８】
送信装置１０は、データファイルの送信完了後に、送信の完了を受信装置２０に通知するために、データファイルと対応付けられたファイルを受信装置２０へ送信する。
【００１９】
上述の、データファイルと対応付けられたファイルを、以下「フラグファイル」と呼ぶ。フラグファイルは本発明に係る制御ファイルの一例である。
【００２０】
フラグファイルは、上述のように、送信装置１０がデータファイルの送信の完了を受信装置２０に通知するためのファイルであり、何ら実体的な内容を含まない。つまり受信装置２０は、フラグファイルの受信装置２０での存在を確認することで、そのフラグファイルに対応するデータファイルの処理を開始することができる。
【００２１】
また、受信装置２０は、データファイルの処理が正常に終了した後にフラグファイルを消去する。つまり、送信装置１０は、受信装置２０にフラグファイルが存在しないことを確認することで、そのフラグファイルに対応するデータファイルの処理が正常に終了したことを知ることができる。
【００２２】
結果として、一つのフラグファイルは、その受信装置２０での存否により、送信装置１０に対してと、受信装置２０に対してとで異なる２つの役割を果たすこととなる。各装置のフラグファイルの扱いついては、後述の送信装置１０及び受信装置２０の動作の説明の中で行なう。なお、データファイルとフラグファイルとは、図２に示すようにそれらのファイル名により対応付けられる。
【００２３】
図２は、データファイル及びデータファイルと対応付けられたフラグファイルのファイル名の構成を示す図である。図２（Ａ）は、データファイルのファイル名の構成を示す図であり、データファイルのファイル名は、識別名と拡張子とで構成される。図２（Ａ）に示す例では、識別名が「ＡＡＡ」であり、拡張子が「．ｄａｔ」である。
【００２４】
なお、データファイルは、受信装置２０によって行なわれるデータ処理の対象となるファイルであり、送信装置１０において新たに生成された場合においても、ファイル名は一定のままである。
【００２５】
図２（Ｂ）は、図２（Ａ）に示したファイル名を持つデータファイルに対応するフラグファイルのファイル名の構成を示す図である。フラグファイルのファイル名は、データファイルと同じ識別名とデータファイルとは異なる拡張子とで構成される。
【００２６】
図２（Ｂ）に示すように、識別名はデータファイルと同じ「ＡＡＡ」であり、拡張子はデータファイルとは異なる「．ｆｌｇ」である。
【００２７】
図２（Ａ）及び図２（Ｂ）に示すように、ファイル名の識別名部分は同一であるため、データファイルとフラグファイルとは、一方のファイル名により他方のファイルを特定することができる。
【００２８】
図３は、送信装置１０及び受信装置２０の機能的な構成を示す機能ブロック図である。
送信装置１０は、上述のように、データファイルを生成し受信装置２０へ送信する装置であり、送信装置側インターフェイス（Ｉ／Ｆ）１１と、送信部１２と、取得情報振分部１３と、データファイル格納部１４と、送信完了判定部１５と、フラグファイル生成部１６と、送信先フラグ確認部１７と、データ生成部１８とを備える。
【００２９】
送信装置側Ｉ／Ｆ１１は、通信回線５０を介して受信装置２０との間で情報のやり取りを行なうための処理部である。送信部１２は、データファイル等の送信を行なう処理部である。
【００３０】
取得情報振分部１３は、受信装置２０から取得した情報を、その内容に応じて必要な処理部に振り分ける処理部である。
【００３１】
データファイル格納部１４は、データファイルを格納する記憶装置であり、データファイル格納部１４に格納されているデータファイルは送信部１２によって受信装置２０へ送信される。
【００３２】
送信完了判定部１５は、送信部１２により行なわれるデータファイルの送信が正常に完了したか否かを判定する処理部である。
【００３３】
フラグファイル生成部１６は、フラグファイルを生成する処理部であり、送信完了判定部１５がデータファイルの送信が正常に完了したと判定した場合に、その送信されたデータファイルに対応するフラグファイルを生成する。生成されたフラグファイルは、送信部１２によって受信装置２０へ送信される。
【００３４】
送信先フラグ確認部１７は、受信装置２０にフラグファイルが存在するか否かを確認する処理部である。データ生成部１８は、データファイル格納部１４に格納されているデータファイルの生成を行なう処理部である。
【００３５】
受信装置２０は、受信装置側Ｉ／Ｆ２１と、受信部２２と、受信ファイル格納部２３と、要求応答部２４と、受信フラグ確認部２５と、アプリケーション部２６と、受信フラグ消去部２７とを備える。
【００３６】
受信装置側Ｉ／Ｆ２１は、通信回線５０を介して送信装置１０との間で情報のやり取りを行なうための処理部である。受信部２２は、送信装置１０から送信されるデータファイル等の受信を行なう処理部である。
【００３７】
ファイル格納部２３は、受信部２２が受信したデータファイル及びフラグファイルを格納する記憶装置である。要求応答部２４は、送信装置１０から送信される、ファイルの取得要求等に応答する処理部である。
【００３８】
受信フラグ確認部２５は、受信ファイル格納部２３に格納されているデータファイルに対応するフラグファイルが、受信ファイル格納部２３に存在するか否かを確認する処理部である。
【００３９】
アプリケーション部２６は、所定のアプリケーションソフトウェアにより、受信ファイル格納部２３に格納されているデータファイルの処理を実行する処理部である。
【００４０】
受信フラグ消去部２７は、アプリケーション部２６により処理されたデータファイルに対応するフラグファイルを、受信ファイル格納部２３から消去する処理部である。
【００４１】
次に、以上のように構成された本発明の実施の形態における送信装置１０及び受信装置２０の動作について図４〜図６を用いて説明する。
【００４２】
先ず、送信装置１０がデータファイルを送信する際の送信装置１０及び受信装置２０の動作を、図４と図５とを用いて説明する。
【００４３】
図４は、送信装置１０が受信装置２０へデータファイルを送信する際の、送信装置１０の動作を示すフロー図である。図５は、送信装置１０と受信装置２０との間で行なわれるデータファイル及びフラグファイルの送受信の概要を示す模式図である。図５は、図の簡潔化のため、各装置について、データファイルの送受信の説明に必要な構成部のみ図示している。
【００４４】
なお、送信装置１０が送信するデータファイルは「ＡＡＡ．ｄａｔ」であるとする。また、送信装置１０と受信装置２０との間で行なわれるファイル等の送受信はすべて送信装置側Ｉ／Ｆ１１及び受信装置側Ｉ／Ｆ２１を介して行なわれるが、説明の簡潔化のため、送信装置側Ｉ／Ｆ１１及び受信装置側Ｉ／Ｆ２１に関する記述は省略する。
【００４５】
送信装置１０は受信装置２０へデータファイル「ＡＡＡ．ｄａｔ」及びフラグファイル「ＡＡＡ．ｆｌｇ」を送信するが、受信装置２０では、受信したデータファイル「ＡＡＡ．ｄａｔ」の処理が行なわれた後に、フラグファイル「ＡＡＡ．ｆｌｇ」が消去される。なお、受信装置２０のデータファイルの処理に関する動作は図６を用いて後述する。
【００４６】
つまり、フラグファイル「ＡＡＡ．ｆｌｇ」が受信装置２０に存在している間は、データファイル「ＡＡＡ．ｄａｔ」の処理が終了していないことを意味する。この場合、上書き防止のために、送信装置１０は新たなデータファイル「ＡＡＡ．ｄａｔ」を送信することができない。
【００４７】
よって、送信装置１０はデータファイル「ＡＡＡ．ｄａｔ」を送信する前に、データファイル「ＡＡＡ．ｄａｔ」に対応するフラグファイルである「ＡＡＡ．ｆｌｇ」が受信装置２０に存在するか否かを確認する（Ｓ１０）。
【００４８】
具体的には、送信先フラグ確認部１７が送信部１２に「ＡＡＡ．ｆｌｇ」の取得要求であるＧＥＴコマンドを受信装置２０対して送信させる。
【００４９】
送信先フラグ確認部１７は、受信装置２０に「ＡＡＡ．ｆｌｇ」が存在しない場合、取得情報振分部１３を介し受信装置２０から「ＡＡＡ．ｆｌｇ」を取得できない旨の情報を取得する。この情報は、受信装置２０の要求応答部２４が上記ＧＥＴコマンドに対応して生成した情報である。この情報により、受信装置２０に「ＡＡＡ．ｆｌｇ」が存在しないことを確認する（Ｓ１１でＹＥＳ）。
【００５０】
図５（Ａ）は、送信装置１０が「ＡＡＡ．ｆｌｇ」を要求するＧＥＴコマンドを送信し、受信装置２０から「ＡＡＡ．ｆｌｇ」が存在しない旨の情報を取得する様子を示している。
【００５１】
送信先フラグ確認部１７は、「ＡＡＡ．ｆｌｇ」を取得できた場合、受信装置２０に「ＡＡＡ．ｆｌｇ」が存在することを確認する（Ｓ１１でＮＯ）。
【００５２】
送信先フラグ確認部１７は、受信装置２０に「ＡＡＡ．ｆｌｇ」が存在することを確認した場合、所定の間隔を置いて、フラグファイル「ＡＡＡ．ｆｌｇ」の存否確認（Ｓ１０）を行なう。送信先フラグ確認部１７は、送信先フラグ確認部１７が受信装置２０に「ＡＡＡ．ｆｌｇ」が存在しないことを確認する（Ｓ１１でＹＥＳ）まで存否確認を繰り返す。
【００５３】
受信装置２０に「ＡＡＡ．ｆｌｇ」が存在しないことを確認した送信先フラグ確認部１７は、送信部１２に、「ＡＡＡ．ｆｌｇ」に対応するデータファイルである「ＡＡＡ．ｄａｔ」を送信させる。具体的には、送信部１２は、データファイル格納部１４から「ＡＡＡ．ｄａｔ」を読み出し、受信装置２０に送信する（Ｓ１２）。
【００５４】
送信部１２が「ＡＡＡ．ｄａｔ」を送信した後、送信完了判定部１５が取得情報振分部１３を介して受信装置２０から受信装置２０が受信した「ＡＡＡ．ｄａｔ」を取得し（Ｓ１３）、データファイル格納部１４に格納されている「ＡＡＡ．ｄａｔ」と、受信装置２０から取得した「ＡＡＡ．ｄａｔ」とを比較する（Ｓ１４）。
【００５５】
図５（Ｂ）は、送信装置１０が「ＡＡＡ．ｄａｔ」を送信し、受信装置２０が受信した「ＡＡＡ．ｄａｔ」を受信ファイル格納部２３に格納した後に、送信装置１０が、受信装置２０から「ＡＡＡ．ｄａｔ」を取得する様子を示している。
【００５６】
上記比較により、データファイル格納部１４に格納されている「ＡＡＡ．ｄａｔ」と、受信装置２０から取得した「ＡＡＡ．ｄａｔ」とが完全に一致した場合（Ｓ１５でＹＥＳ）、送信完了判定部１５は、「ＡＡＡ．ｄａｔ」の送信が正常に完了した、つまり、データエラーを発生することなく「ＡＡＡ．ｄａｔ」が正常に受信装置２０へ転送されたと判定する。
【００５７】
判定後、送信完了判定部１５は、フラグファイル生成部１６に「ＡＡＡ．ｄａｔ」に対応するフラグファイルである「ＡＡＡ．ｆｌｇ」を生成させる（Ｓ１６）。
【００５８】
なお、上記比較により上記２つのファイルが一致しなかった場合（Ｓ１５でＮＯ）、送信完了判定部１５は「ＡＡＡ．ｄａｔ」の送信が完了していない、つまり、何らかのエラーが発生し、「ＡＡＡ．ｄａｔ」が正常に転送されなかったと判定し、送信部１２は「ＡＡＡ．ｄａｔ」を再度送信する（Ｓ１２）。
【００５９】
送信装置１０は、上記２つのファイルが完全に一致する（Ｓ１５でＹＥＳ）まで、「ＡＡＡ．ｄａｔ」の送信（Ｓ１２）から上記２つのファイルの比較（Ｓ１４）までを繰り返す。
【００６０】
「ＡＡＡ．ｄａｔ」の送信完了後、送信完了を受信装置２０に通知するために、フラグファイルが送信装置１０から受信装置２０へ送信される。具体的には、フラグファイル生成部１６は、送信部１２に、生成したフラグファイル「ＡＡＡ．ｆｌｇ」を受信装置２０に対して送信させる（Ｓ１７）。
【００６１】
図５（Ｃ）は、送信装置１０が「ＡＡＡ．ｆｌｇ」を送信し、受信装置２０が受信した「ＡＡＡ．ｆｌｇ」を受信ファイル格納部２３に格納する様子を示している。
【００６２】
上述のように、送信装置１０は、送信完了判定部１５がデータファイル「ＡＡＡ．ｄａｔ」の送信が正常に完了したと判定した後に、フラグファイル「ＡＡＡ．ｆｌｇ」を受信装置２０に送信する。つまり、フラグファイル「ＡＡＡ．ｆｌｇ」は、送信装置１０がデータファイル「ＡＡＡ．ｄａｔ」の正常な送信の完了を受信装置２０に通知するものとして送信される。
【００６３】
受信装置２０から見ると、フラグファイル「ＡＡＡ．ｆｌｇ」は、データファイル「ＡＡＡ．ｄａｔ」の正常な受信が完了したことを示すことになり、受信装置２０は先に受信したデータファイル「ＡＡＡ．ｄａｔ」の処理を開始することができる。
【００６４】
送信装置１０は、フラグファイル「ＡＡＡ．ｆｌｇ」の送信後、データ生成部１８により、データファイル「ＡＡＡ．ｄａｔ」が生成されると、上述の一連の動作を再び行なう。
【００６５】
次に、上述の送信装置１０の動作の後、つまり、受信装置２０がデータファイル「ＡＡＡ．ｄａｔ」及びフラグファイル「ＡＡＡ．ｆｌｇ」を受信した後の、受信装置２０の動作の説明を行なう。
【００６６】
図６は、受信装置２０が受信したデータファイルを処理する際の動作を示すフロー図である。図６を用い、受信装置２０が受信したデータファイルを処理する際の動作の説明を行なう。
【００６７】
上述のように、フラグファイル「ＡＡＡ．ｆｌｇ」は受信装置２０から見ると、データファイル「ＡＡＡ．ｄａｔ」の正常な受信が完了したことを意味する。よって、データファイル「ＡＡＡ．ｄａｔ」の処理を行なう前に、受信フラグ確認部２５が受信ファイル格納部２３に「ＡＡＡ．ｆｌｇ」が存在しているか否かの確認を行なう（Ｓ２０）。
【００６８】
フラグファイル「ＡＡＡ．ｆｌｇ」が存在している場合（Ｓ２１でＹＥＳ）、受信フラグ確認部２５は、アプリケーション部２６にデータファイル「ＡＡＡ．ｄａｔ」の処理を指示する。
【００６９】
フラグファイル「ＡＡＡ．ｆｌｇ」が存在しない場合（Ｓ２１でＮＯ）、受信フラグ確認部２５は「ＡＡＡ．ｆｌｇ」が存在することを確認する（Ｓ２１でＹＥＳ）まで、「ＡＡＡ．ｆｌｇ」の存否確認（Ｓ２０）を繰り返す。
【００７０】
アプリケーション部２６は、受信ファイル格納部２３に格納されているデータファイル「ＡＡＡ．ｄａｔ」を読み出し、集計等の必要な処理を行ない（Ｓ２２）、全ての処理が正常に終了（Ｓ２３でＹＥＳ）すると受信フラグ消去部２７に処理の正常な終了を通知する。
【００７１】
アプリケーション部２６は、全ての処理が正常に終了しない（Ｓ２３でＮＯ）間は、全ての処理が終了する（Ｓ２３でＹＥＳ）まで、データファイル「ＡＡＡ．ｄａｔ」の処理（Ｓ２２）を行なう。
【００７２】
受信フラグ消去部２７は、全ての処理の正常な終了の通知を受け、フラグファイル「ＡＡＡ．ｆｌｇ」を受信ファイル格納部２３から消去する（Ｓ２４）。
【００７３】
上述したように、本実施の形態の送信装置１０及び受信装置２０は、フラグファイルの受信装置２０での存否により、データファイルの状態を確認する。
【００７４】
送信装置１０においては、受信装置２０にフラグファイルが存在しないことを確認し、データファイルの受信装置２０への送信を行なう。これは受信装置２０でフラグファイルが存在しないということは、データファイルの処理が全て正常に終了した、つまりデータファイルが使い尽くされたことを意味し、受信装置２０に存在するデータファイルへの上書きが許容されるためである。
【００７５】
結果的に、送信装置１０は、未処理のデータファイルへの上書き防止のためには、受信装置２０にフラグファイルが存在しないことのみを確認すればよく、データファイルの送信に係わる処理手順が簡素化される。また、そのために受信装置２０が行なうことはフラグファイルの消去のみであり、受信装置２０にかかる負荷は非常に軽微である。
【００７６】
また、受信装置２０は、受信装置２０にフラグファイルが存在することを確認し、データファイルの処理を開始する。これは、フラグファイルは、データファイルの送信が正常に完了したことの証として、送信装置１０が生成し受信装置２０に送信するものであり、受信装置２０から見ると、フラグファイルはデータファイルの正常な受信が完了したことを示すものになるからである。
【００７７】
つまり、一つのフラグファイルは、（１）受信装置２０に存在しないことにより、送信装置１０に、そのフラグファイルに対応する新たなデータファイルの送信が可能であることを知らせ、（２）受信装置２０に存在することにより、受信装置２０に、そのフラグファイルに対応するデータファイルの処理が可能であることを知らせるという２つの役割を果たしている。
【００７８】
また、上述のように、フラグファイル生成は、送信装置１０がデータファイルの送信の正常な完了を判断した後に行なわれる。この、データファイル送信の正常な完了の判断は、送信したデータファイルと受信装置２０が受信したデータファイルとの比較により行なわれる。
【００７９】
つまり、実際にデータ処理の対象となる、受信装置２０によって受信されたデータファイルが、送信前のデータファイルと完全に一致した場合にのみ、データファイルの送信が正常に完了したと判定する。この判定により、より確実なデータ処理が行なえることとなる。
【００８０】
なお、上述の実施の形態の説明では、送信装置１０及び受信装置２０の２つの装置間でファイルのやり取りを行なう形態について説明した。しかしながら、送信装置１０と受信装置２０との間に、ファイルの送受信を中継する中継装置を接続し、送信装置１０と受信装置２０とが、中継装置を介してファイルの送受信を行なってもよい。
【００８１】
図７は、送信装置１０と受信装置２０とが中継装置３０を介してデータファイルの送受信を行なう場合のハードウェア構成図である。
【００８２】
送信装置１０と受信装置２０との間に中継装置３０が設置されており、送信装置１０が送信するデータファイルは中継装置３０を経由し、受信装置２０に送信される。
【００８３】
図８は、送信装置１０と受信装置２０とが中継装置３０を介してデータファイルの送受信を行なう場合のデータファイルの移動を示す模式図である。図８は、送信装置１０から送信されたデータファイル「ＡＡＡ．ｄａｔ」が、中継装置３０を介し、受信装置２０に受信された様子を示している。
【００８４】
中継装置３０は、受信装置２０が備える、データファイル及びフラグファイルの受信や確認等に関する機能と、送信装置１０が備える、データファイル及びフラグファイルの送信や確認等に関する機能と、受信したデータファイルを複製、リネームし保持する機能とを備える。つまり、中継装置３０は、例えば受信装置２０がファイルの中継に必要な機能を具備することにより実現できる。
【００８５】
図８では、図示の簡潔化のため、データファイルの移動の説明に必要な各装置の構成部のみ記載している。中継装置３０については、中継装置３０が備える構成部のうち、キューファイル格納部３１のみが図示されている。キューファイル格納部３１は、複製、リネームされたデータファイルを保持する記憶装置である。また、キューファイル格納部３１は本発明の受信装置におけるデータファイル記憶手段の一例である。
【００８６】
送信装置１０が行なうデータファイル及びフラグファイルの中継装置３０への送信時の動作は、上述の、図４を用いて説明したデータファイル及びフラグファイルを受信装置２０へ送信する場合の動作と同様である。データファイル及びフラグファイルの送信先が受信装置２０から中継装置３０へ変更されただけである。
【００８７】
つまり、送信装置１０は、中継装置３０にフラグファイルが存在しないことを確認し、中継装置３０へデータファイルを送信する。また、送信したデータファイルと中継装置３０が受信したデータファイルとが完全に一致することを確認し、フラグファイルを生成し、中継装置３０へ送信する。
【００８８】
中継装置３０は、受信したデータファイルを複製及びリネームすることで複数のデータファイルを順序付けて格納しておくことができる。データファイルを受信装置２０に送信する際は、その複数のデータファイルの中から最も古いデータファイルを選択し、受信装置２０に送信する。
【００８９】
中継装置３０は、図８に示すように、送信装置１０から送信されるデータファイル「ＡＡＡ．ｄａｔ」を受信する。さらに、受信した「ＡＡＡ．ｄａｔ」を複製し、「ＡＡＡ１．ｄａｔ」のように、ファイル名の識別名部分に番号を付すことにより、格納順が判別できるようにリネームする。リネームしたファイルをキューファイル格納部３１に格納する。
【００９０】
図９は、中継装置３０が、送信装置１０から受信したデータファイルを複製しリネームし格納する際の動作を示すフロー図である。
【００９１】
図６に示した受信装置２０の動作と同様に、中継装置３０は、データファイル「ＡＡＡ．ｄａｔ」の受信後、フラグファイル「ＡＡＡ．ｆｌｇ」の自装置内での存否を確認し（Ｓ３０）、存在することを確認した場合（Ｓ３１でＹＥＳ）、データファイル「ＡＡＡ．ｄａｔ」を複製し、複製したデータファイルのファイル名を「ＡＡＡ１．ｄａｔ」とリネームする（Ｓ３２）。
【００９２】
フラグファイル「ＡＡＡ．ｆｌｇ」が存在しない場合（Ｓ３１でＮＯ）、「ＡＡＡ．ｆｌｇ」の存在を確認する（Ｓ３１でＹＥＳ）まで、「ＡＡＡ．ｆｌｇ」の存否確認（Ｓ３０）を繰り返す。
【００９３】
中継装置３０は、リネームした「ＡＡＡ１．ｄａｔ」をキューファイル格納部３１に格納し（Ｓ３３）、フラグファイル「ＡＡＡ．ｆｌｇ」を消去する（Ｓ３４）。
【００９４】
上述の動作の結果、中継装置３０は、送信装置１０から受信したデータファイル「ＡＡＡ．ｄａｔ」を「ＡＡＡ１．ｄａｔ」というファイル名で格納しておくことができる。また、上述の動作の後に送信装置１０から新たな「ＡＡＡ．ｄａｔ」を受信した場合は、図８に示すように、格納順が判別できるように「ＡＡＡ２．ｄａｔ」というファイル名でキューファイル格納部３１に格納する。
【００９５】
中継装置３０は、キューファイル格納部３１に格納されているデータファイルの中からファイル名等に基づいて、一番古いデータファイルを選択し、受信装置２０へ送信する。
【００９６】
図８に示す例の場合、中継装置３０は、「ＡＡＡ１．ｄａｔ」を選択し、ファイル名を元のファイル名、つまり「ＡＡＡ．ｄａｔ」にリネームし、受信装置２０へ送信する。なお、中継装置３０が受信装置２０へデータファイル「ＡＡＡ．ｄａｔ」を送信する際の動作は、図４に示した、送信装置１０が受信装置２０にデータファイルを送信する際の動作と同様に、受信装置２０でのフラグファイルの存否確認と、送信の正常な完了の確認と、フラグファイルの生成及び送信とを行なう。
【００９７】
受信装置２０は、データファイル「ＡＡＡ．ｄａｔ」の受信後、フラグファイル「ＡＡＡ．ｆｌｇ」を受信し、図６に示したデータファイルを処理する際の動作と同じ動作を行なう。つまり、アプリケーション部２６がデータファイル「ＡＡＡ．ｄａｔ」の処理を行ない、処理が正常に終了した後、受信フラグ消去部２７が、フラグファイル「ＡＡＡ．ｆｌｇ」の消去を行なう。
【００９８】
上述のように、中継装置３０は、受信したデータファイルを複製、リネームし、キューファイル格納部３１に格納する。その後、受信したファイルフラグを消去する。送信装置１０は、中継装置３０においてフラグファイルが存在しないことを確認した後に、生成された新たなデータファイルを中継装置３０に送信することができる。
【００９９】
つまり、送信装置１０が、データファイルの送信を行なうことができない時間は、中継装置３０が行なう、データファイルの複製、リネーム及び格納に必要な時間だけであり非常に短い時間である。
【０１００】
よって、送信装置１０は、データファイルがデータ生成部１８により生成された場合、実質上、即座にデータファイルを中継装置３０へ送信することができる。
【０１０１】
こうすることで、送信装置１０は、データファイルの生成後、即座に、データファイルを保持及び送信する義務から解放され、データファイルの生成等に係わる処理のみを行なえばよく送信装置１０の処理効率が向上する。
【０１０２】
また、例えば、受信装置２０がメンテナンス等の理由により全ての処理が停止した場合であっても、送信装置１０は、受信装置２０の状態に関係なく、データファイルの生成と送信とが行なえる。つまり、送信装置１０と受信装置２０とを非同期に運用することができ、データ処理全体に係わる処理効率が向上する。
【０１０３】
さらに、受信装置２０は、データファイル等の送受信をすべて中継装置３０を介して行なうため、送信装置１０から直接アクセスされることがない。このことにより受信装置２０に対するセキュリティが向上する。
【０１０４】
また、上述の図１の説明の中で、フラグファイルは何ら実体的な内容を含まず、その存否により対応するデータファイルの状態を示すファイルであるとしたが、その存否以外に、フラグファイルに意味を持たせて使用してもよい。
【０１０５】
例えば、フラグファイルのファイル容量を一定のものとし、受信装置２０で、フラグファイルの正当性の基準としてファイル容量を用いてもよい。
【０１０６】
図１０は、フラグファイルのファイル容量を８０バイトとした場合の、フラグファイルのデータ構成の一例を示す図である。図１０に示すように、送信装置１０のフラグファイル生成部１６が、フラグファイルのファイル名とスペースとでファイル容量が８０バイトとなるように、フラグファイルを生成する。
【０１０７】
受信装置２０はデータファイルの処理前に、フラグファイルの存否の確認だけでなく、受信したフラグファイルのファイル容量が８０バイトであるか否の確認も行なう。
【０１０８】
受信したフラグファイルのファイル容量が８０バイトである場合は、正当なフラグファイルであると認知し、データファイルの処理を行なう。８０バイトでない場合は、エラーとして、例えば、送信装置１０にその旨を通知し、再度フラグファイルを送信することを促す。
【０１０９】
この場合、受信装置２０において受信フラグ確認部２５が、フラグファイルのファイル容量を確認する機能を持ち、要求応答部２４が送信装置１０にエラーを通知する機能を持てばよい。送信装置１０においては、エラーが通知された場合、フラグファイル生成部１６が再度フラグファイルを生成し、送信部１２が受信装置２０に送信すればよい。
【０１１０】
こうすることで、受信装置２０におけるフラグファイルの確認がより厳密なものとなり、例えば、偶然に、受信すべきフラグファイルと同名のファイルを受信した場合において、誤ってデータファイルの処理を開始してしまうことを防ぐことができる。
【０１１１】
また、送信装置１０においても、フラグファイルの受信装置２０での存否の確認の際に、フラグファイルのファイル容量が８０バイトであるか否かの確認を行なってもよい。
【０１１２】
図５を用いて述べたように、送信装置１０は、受信装置２０でのフラグファイルの存否の確認のために、受信装置２０にフラグファイルの取得要求であるＧＥＴコマンドを送信する。そのＧＥＴコマンドによりフラグファイルを取得できた場合は、受信装置２０にフラグファイルが存在していると確認する。
【０１１３】
しかしながら、受信装置２０にフラグファイルが存在しないのにも係わらずＧＥＴコマンドの応答として、空のフラグファイル、例えば１バイト（ＥＯＦ）のフラグファイルを取得することがある。つまり、受信装置２０にフラグファイルが存在すると誤判定してしまうことがある。
【０１１４】
そこで、送信装置１０がフラグファイルを取得した場合に、フラグファイルのファイル容量が８０バイトであるか否かを確認し、８０バイトである場合のみ、受信装置２０にフラグファイルが存在しているとすればよい。こうすることで、上記誤判定を回避できることとなる。この場合、送信装置１０の送信先フラグ確認部１７が、フラグファイルの容量を確認する機能をもてばよい。
【０１１５】
なお、フラグファイルのファイル容量は８０バイト以外でもよく、一定の値であればよい。また、フラグファイルの内容も、ファイル名とスペースでなくてもよく、例えば、データファイルの生成を行なったユーザ名など実体的に意味のある内容を含ませてもよい。さらに、その実体的に意味のある内容を、受信装置２０で利用してもよい。
【産業上の利用可能性】
【０１１６】
本発明に係わる送信装置及び受信装置は、データの入力及び生成と、データの処理とを別の装置で行なうデータ処理システムとして利用できる。
【図面の簡単な説明】
【０１１７】
【図１】本発明の実施の形態の送信装置及び受信装置のハードウェア構成図である。
【図２】データファイル及びデータファイルと対応付けられたフラグファイルのファイル名の構成を示す図である。
【図３】送信装置及び受信装置の機能的な構成を示す機能ブロック図である。
【図４】送信装置が受信装置にデータファイルを送信する際の動作を示すフロー図である。
【図５】送信装置と受信装置との間で行なわれるファイルの送受信の様子を示す模式図である。
【図６】受信装置が受信したデータファイルを処理する際の動作を示すフロー図である。
【図７】送信装置と受信装置とが中継装置を介してデータファイルの送受信を行なう場合のハードウェア構成図である。
【図８】送信装置と受信装置とが中継装置を介してデータファイルの送受信を行なう場合のデータファイルの移動を示す模式図である。
【図９】中継装置が受信したデータファイルを複製しリネームし格納する際の動作を示すフロー図である。
【図１０】フラグファイルのファイル容量を８０バイトとした場合のフラグファイルのデータ構成の一例を示す図である。
【符号の説明】
【０１１８】
１０    送信装置
１１    送信装置側Ｉ／Ｆ
１２    送信部
１３    取得情報振分部
１４    データファイル格納部
１５    送信完了判定部
１６    フラグファイル生成部
１７    送信先フラグ確認部
１８    データ生成部
２０    受信装置
２１    受信装置側Ｉ／Ｆ
２２    受信部
２３    受信ファイル格納部
２４    要求応答部
２５    受信フラグ確認部
２６    アプリケーション部
２７    受信フラグ消去部
３０    中継装置
３１    キューファイル格納部
【図１】
2006209380.tif 000003
【図２】
2006209380.tif 000004
【図３】
2006209380.tif 000005
【図４】
2006209380.tif 000006
【図５】
2006209380.tif 000007
【図６】
2006209380.tif 000008
【図７】
2006209380.tif 000009
【図８】
2006209380.tif 000010
【図９】
2006209380.tif 000011
【図１０】
2006209380.tif 000012