JP2009224923A - データ送信装置 - Google Patents

Abstract

【課題】ローカルエリアネットワークを介して複数の端末に遅滞なくデータを送信することのできるデータ送信装置を提供する。
【解決手段】データ送信装置（ＭＦＤ１０）は、一の端末へのデータ送信に失敗した場合（Ｓ１２：ＮＯ）、他の端末へのデータ送信を試みた後に、一の端末へのデータ送信をリトライする（Ｓ１４）。リトライは、データ送信に失敗した場合に直ちに実行されることがなく、他の端末へのデータ送信を試みた後に実行される。従ってこのデータ送信装置は、一の端末へのデータ送信に失敗したとしても、他の端末へ遅滞なくデータを送信することができる。
【選択図】図２

Description

本発明は、ローカルエリアネットワークを介して複数の端末に同一のデータを順次に送信するデータ送信装置に関する。

画像を読み取ることによって作成されたスキャンデータを端末に送信する読取装置が知られている（例えば特許文献１）。例えば、このようにデータを端末に送信する装置（データ送信装置）において、複数の端末に同一のデータを同時配信する機能を備えたものもある。複数の端末がデータ送信先に指定された場合、データ送信装置は、まず送信先のひとつの端末とコネクションを確立し、データ送信の完了を確認した後に、そのコネクションを解除する。データ送信装置は、ひとつの端末へのデータ送信が完了した後に、次の送信先端末とコネクションを確立する。

特開２００６−６０４９９号公報

ローカルエリアネットワークを介してデータを送信する場合、データ送信に失敗する場合がある。データ送信に失敗する場合とは、例えば、データ送信先の端末の電源がオフの場合、データ送信先の端末の記憶容量が不足している場合、あるいは、データ送信先へのデータ転送ルートが不通の場合がある。また、コネクションを確立した端末から応答がない場合にはしばらく待機したり、データ送信に失敗した場合にはその端末に対してデータ送信をリトライ（再送信）する。しかし、同一の端末に対して待機したり、複数回リトライすると、他の端末へのデータ送信が遅れてしまう。本発明は、上記課題に鑑みて創作されたものであり、ローカルエリアネットワークを介して複数の端末に速やかにデータを送信することのできるデータ送信装置を提供する。

本明細書は、ローカルエリアネットワークを介して複数の端末に同一のデータを順次に送信するデータ送信装置を開示する。本明細書に開示されるデータ送信装置は、一の端末へのデータ送信に失敗した場合、他の端末へのデータ送信を試みた後に、一の端末へのデータ送信をリトライする。リトライは、データ送信に失敗した場合に直ちに実行されることがなく、他の端末へのデータ送信を試みた後に実行される。従ってこのデータ送信装置は、一の端末へのデータ送信に失敗したとしても、他の端末へ遅滞なくデータを送信することができる。

本明細書に開示するデータ送信は、典型的にはローカルネットワークに接続可能なコピー機、プリンタ、スキャナ、ファクス機、あるいはそれらの機能のいくつかを備えるＭＦＤ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｄｅｖｉｃｅ）であってよい。

データ送信装置は、データ送信に失敗したときの送信方法と異なる送信方法でリトライする。「異なる送信方法」とは例えば、送信プロトコルとデータ転送ルートの少なくとも一方が、データ送信に失敗したときと異なる送信方法がよい。送信プロトコルには、ＴＣＰ／ＩＰ規格で定義されているＦＴＰ、ＨＴＴＰ、メールプロトコル、ＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ）プロトコルが含まれる。データ転送ルートには、サーバを経由する送信方法がある。異なる送信方法でリトライすることによって、少ないリトライ回数でデータ送信に成功する確率を高めることができる。

初回のデータ送信が失敗した場合に、次のリトライを必ずしも異なる送信方法で実行する必要はない。データ送信装置は、データ送信に失敗したときの送信方法と同じ送信方法で少なくとも１回リトライし、同じ送信方法によるリトライが成功しなかった場合に、異なる送信方法でリトライしてもよい。

端末毎に様々なデータ送信方法が想定され得る。端末毎に、成功する可能性の高い送信方法が異なる場合もある。データ送信装置は、端末ごとに複数の送信方法を優先順位付きで記憶しており、優先順位の高い順に、リトライ時の送信方法を選択することが好ましい。

必ずしも優先順位に従わない例外ケースがあってもよい。例外ケースには次の場合がある。データ送信装置は、認証を必要とする複数の送信方法を記憶しており、データ送信に失敗したときの送信方法が認証を必要とするいずれかの送信方法であった場合、優先順位に関わらずに認証を必要とする他の送信方法を採用しなくてよい。他の例外ケースとして、データ送信先端末の容量不足が原因でデータ送信が失敗した場合、データ送信装置は、優先順位に関わらずに、予め決められた時間間隔の後に同じ送信方法でリトライしてよい。

データ送信装置は、送信に成功した送信方法の優先順位を最高位に変更することが好ましい。成功する確率の高い送信方法で、次回の他のデータの送信を開始することができる。

データ送信装置は、送信タスクへ端末の宛先を渡すためのキューを備えており、データの送信に失敗した端末の宛先をキューに格納された最後の宛先の次の位置でキューに追加することが好ましい。そして、データ送信装置は、データ送信に失敗したことを条件として次回の送信方法を決定し、データ送信に失敗した端末の宛先とともに、決定した送信方法をキューに格納された最後の宛先の次の位置でキューに追加することが好ましい。次回の送信方法をキューに格納しておくことで、データ送信装置は、次回のリトライを速やかに実行することができる。送信タスクはマルチタスクで実行されることが好ましい。

データ送信装置は、全ての端末へのデータ送信を試みた後に、予め指定されている端末へ送信結果を通知するとよい。「予め指定されている端末」は、データ送信を指示したユーザが指定すればよい。典型的には、「予め指定されている端末」は、データ送信を指示したユーザの端末であってよい。「送信結果」には、送信の日時、送信に成功したか否かの通知、送信先名、送信が失敗したときのエラーコードなどが含まれてよい。

本発明は、ローカルエリアネットワークを介して複数の端末に速やかにデータを送信することのできるデータ送信装置を提供する。

１．第１実施例
図面を参照して実施例のデータ送信装置を説明する。実施例のデータ送信装置は、ＭＦＤ１０である。ＭＦＤ１０は、ファクシミリ機能、コピー機能、プリンタ機能、及びスキャナ機能を兼ね備えた複合機である。

１−１．システム構成
図１は、ＭＦＤ１０のブロック図である。図１にはまた、ローカルエリアネットワーク５０を介してＭＦＤ１０と接続されている他の装置も描かれている。以下では、「ローカルエリアネットワーク５０」を「ＬＡＮ５０」と称する。ＬＡＮ５０にはＭＦＤ１０の他に、４つの端末（ＰＣ１、ＰＣ２、ＰＣ３、及びＰＣ４）と２つのサーバ（サーバＡ、及びサーバＢ）が接続されている。サーバＡやサーバＢは、広域ネットワークに接続されていてもよい。

ＭＦＤ１０は、ＣＰＵ１２、ストレージ１４、コンソール２２、ディスプレイ２４、ネットワークインタフェイス２６、ＰＳＴＮ（Public Switched Telephone Networks）インタフェイス２８、プリントエンジン３０、ファクシミリエンジン３２、及びスキャナエンジン３４を備えている。図１に記された「Ｉ／Ｆ」、「Ｅ／Ｇ］の文字は、それぞれ、「インタフェイス」、「エンジン」を意味する。また、図１に記された「ＭＤＬ」の文字は、「モジュール」を意味する。

ＣＰＵ１２は、ストレージ１４に格納された各種のプログラムに従ってＭＦＤ１０を制御する。ストレージ１４に格納されているプログラムには、メインモジュール１６と通信制御モジュール１８がある。メインモジュール１６は、ＭＦＤ１０全体を統括的に制御するプログラムである。通信制御モジュール１８が果す機能については後述する。ストレージ１４にはまた、各種のデータ２０が格納されている。コンソール２２は、ユーザが操作するためのハードウエアである。ユーザは、コンソール２２を操作することによって、ＭＦＤ１０に所望の指示を入力する。

ネットワークインタフェイス２６は、ＬＡＮ５０を介して、端末やサーバと通信するためのハードウエアウエアである。ＰＳＴＮインタフェイス２８は、ＭＦＤ１０を公衆回線（不図示）に接続しているハードウエアである。ＭＦＤ１０は、公衆回線を通じてファクシミリのデータを授受する。プリントエンジン３０は印刷機能のためのハードウエアである。ファクシミリエンジン３２はファクシミリ機能のためのハードウエアである。スキャナエンジン３４はスキャナ機能（画像読取機能）のためのハードウエアである。

１−２．データ送信方法の種類
ＭＦＤ１０は、読み取った画像データ、受信したファクシミリデータ、コピーしたデータ、或いはプリントしたデータを、ネットワーク５０を介して複数の端末へ送信することができる。ＭＦＤ１０は、以下の送信方法で、端末へデータを送信することができる。
・ＦＴＰ
・ＨＴＴＰ
・ＣＩＦＳ
・電子メール
・サーバ経由
ＦＴＰ、ＨＴＴＰ、及び電子メールは、ＴＣＰ／ＩＰで規定されている送信方法である。ＣＩＦＳは、ＴＣＰ／ＩＰに基づいて構築された、インタネット上でのファイル共有のプロトコルである。ＦＴＰ、ＨＴＴＰ、電子メール、及びＣＩＦＳは、それぞれプロトコルが異なるデータ送信方法である。ＦＴＰ、ＨＴＴＰ、ＣＩＦＳの送信方法を用いる場合は、端末に割り当てられたＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）と呼ばれる識別子を指定することによって、データの送信先の端末を特定する。「サーバ経由」とは、指定したサーバにデータを送信するとともに、指定サーバにデータを送信したことを端末に伝える送信方法である。端末は、指定したサーバからデータを受け取ることで、結果的にＭＦＤ１０からデータを受信する。「サーバ経由」の送信方法の場合、異なるサーバを指定することによって、異なるルートでデータを転送することができる。例えば、ＭＦＤ１０は、異なる電子メールサーバを指定することによって、電子メールという同一の送信方法であっても異なるルートでデータを転送することができる。

ＭＦＤ１０は、データの送信先の端末毎に、「Ｐｒｏｆｉｌｅ」と呼ばれるデータを記憶している。Ｐｒｏｆｉｌｅは、ストレージ１４に格納されたデータ２０のひとつである。Ｐｒｏｆｉｌｅは、データを端末へ送信する際の送信方法に関する情報が記述されている。Ｐｒｏｆｉｌｅに記述されている情報には次のものがある。
・端末の名称：端末の名称は、例えばＩＰアドレスやＩＰアドレスに割り当てられた別名などである。端末の名称によって、各端末を特定することができる。
・端末に割り当てられたＵＲＬ：ＦＴＰ、ＨＴＴＰ、ＣＩＦＳの送信方法を用いるときにデータ送信先を特定するための情報である。
・サーバＵＲＬ：「サーバ経由」の送信方法を用いるときにデータ中継用のサーバを特定するための情報である。例えば、図１のサーバＡのＵＲＬを指定すると、サーバＡを経由して端末にデータが送信される。サーバＢを指定すると、サーバＢを経由して端末にデータが送信される。即ち、異なるサーバのサーバＵＲＬを指定することによって、データの転送ルートが異なる複数の送信方法をＰｒｏｆｉｌｅに記述することができる。
・電子メールアドレス：送信方法のひとつである電子メールを用いるときにデータ送信先を特定するための情報である。
端末の名称、端末に割り当てられたＵＲＬ、サーバＵＲＬ、電子メールアドレスは、データ送信先の端末の宛先として利用される。
・優先順位：データを送信する際に採用する送信方法の順位を示す。ＭＦＤ１０が端末にデータを送信する際、最も高い優先順位が割り当てられた送信方法が、最初に採用される。最初に選択された送信方法によるデータ送信が失敗した場合、ＭＦＤ１０は、次の優先順位が割り当てられた送信方法を採用してデータ送信をリトライする。ただし、ＭＦＤ１０は、常に優先順位に従って送信方法を選択するわけではない。ＭＦＤ１０が送信方法を選択する際のルールについては後述する。
・ユーザ名及びパスワード：認証を必要とする送信方法を採用した場合のユーザ名とパスワードである。データ送信に先立って、送信先の端末と通信を確立する際に認証が必要な場合がある。例えば、ＦＴＰ、ＨＴＴＰ、ＣＩＦＳなどのプロトコルは、パスワードを設定することが可能である。パスワードが設定されているデータ送信方法を採用する場合に、このユーザ名とパスワードが必要となる。
・送信するデータに付するファイル名：送信するデータにＭＦＤ１０が自動的にファイル名を付するか、或いは、ユーザが指定するファイル名を採用するかを選択するスイッチである。
・送信するデータのフォーマット
・データ送信結果を通知する通知先の情報（結果通知先情報）：ＭＦＤ１０は、データ送信の結果を予め指定した端末に通知する。「データ送信の結果」とは、送信先、送信日時、送信データに関する情報、送信が成功したか否かの情報、送信に失敗したときにはその原因を示すエラーコードなどである。結果通知先情報には、通知先を特定する識別子（ＩＰアドレスや電子メールアドレスなど）、通知方法、パスワードなども含まれる。通知方法として、ＦＴＰ、ＨＴＴＰ、電子データなどが指定され得る。ユーザは、上記の情報を予め指定することができる。

１−３．ＭＦＤの処理
ＭＦＤ１０は、ひとつのデータを複数の端末に順次に送信することができる。ＭＦＤ１０がデータを送信する際のフローチャートを図２と図３に示す。図２は、データ送信におけるメイン処理のフローチャートを示す。図３は、図２に示した「送信タスク」（Ｓ１４）のフローチャートを示す。図２と図３の処理は、通信制御モジュール１８（図１を参照）に記述されている。ＭＦＤ１０の処理を具体的に説明するために、ユーザが、ＭＦＤ１０に画像を読み取らせ、読み取った画像データをＰＣ１、ＰＣ２、ＰＣ３、及びＰＣ４に順次に送信させる指示を入力したケースを想定する。ユーザは、ＭＦＤ１０のコンソール２２とディスプレイ２４を用いて上記の指示を入力する。ユーザは画像データの送信先として、ＰＣ１、ＰＣ２、ＰＣ３、及びＰＣ４を指定する。文字列「ＰＣ１」、「ＰＣ２」、「ＰＣ３」、及び「ＰＣ４」は、宛先を示す端末名である。

ＭＦＤ１０は、ユーザの指示に従って画像データを読み取る（Ｓ２）。ＭＦＤ１０は、読み取った画像データを記憶する（Ｓ４）。読み取った画像データは、ストレージ１４に記憶される。

ＭＦＤ１０は次いで、ユーザによって指定された複数の宛先（端末名）を送信処理のキューに積む（Ｓ６）。「キュー」は、コンピュータの基本的なデータ構造の一つであり、「待ち行列」とも呼ばれる。「キューに積む」とは、待ち行列の最後にデータを追加することを意味する。キューに入れられた順序に従って、その宛先への画像データの送信が順次に試行される。ＭＦＤ１０は、宛先の後に、文字列「Ｎｏｔｉｆｙ」をキューに積む（Ｓ８）。「Ｎｏｔｉｆｙ」は、データ送信の結果を定められた端末に送信する処理を起動するための予約である。すなわち、「Ｎｏｔｉｆｙ」がキューから取り出されると、データ送信の結果が定められた端末に送信される。

ＭＦＤ１０は、キューの先頭に格納されたデータを読み出す（Ｓ１０）。なお、読み出されたデータはキューから削除される。読み出したデータが宛先の場合（Ｓ１２：ＹＥＳ）、ＭＦＤ１０は、読み出した宛先（送信先端末名）を指定して送信タスクを起動する（Ｓ１４）。送信タスクでは、指定された宛先へ画像データの送信を試みる。送信タスクの概要は図３を参照して後述する。データ送信に失敗した場合（Ｓ１６：ＮＯ）、ＭＦＤ１０は、宛先を「Ｎｏｔｉｆｙ」の前のキューに挿入する（Ｓ１８）。すなわち、キューに積まれた最後の宛先の次の位置で、データ送信に失敗した端末の宛先をキューに追加する。そしてステップＳ１０へ戻る。データ送信に成功した場合（Ｓ１６：ＹＥＳ）、ステップＳ１８をスキップしてステップＳ１０へ戻る。ＭＦＤ１０は、先頭のキューのデータが「宛先」の場合、ステップＳ１２からＳ１８までの処理を繰り返す。先頭のキューのデータが「宛先」でない場合（Ｓ１２：ＮＯ）、即ち、先頭のキューのデータが「Ｎｏｔｉｆｙ」の場合、送信結果のレポートをユーザの端末へ送信する（Ｓ２０）。ＭＦＤ１０は、前述したＰｒｏｆｉｌｅに記述された結果通知先情報に従ってレポートを送信する。

ＭＦＤ１０は、データ送信に失敗すると、宛先の端末名を「Ｎｏｔｉｆｙ」が格納されたキューの前（キューに積まれた最後の宛先の次）に追加する（Ｓ１６：ＮＯ、Ｓ１８）。この処理により、ＭＦＤ１０は、データ送信に失敗した場合、他の端末へデータ送信を試行した後に、失敗した端末へのデータ送信をリトライする。厳密には、ＭＦＤ１０は、データ送信に失敗した場合、残りの全ての端末へのデータ送信を試行した後に、失敗した端末へデータ送信をリトライする。一の端末へのデータ送信が失敗した場合、速やかに他の端末へのデータ送信が開始される。一の端末へのデータ送信に失敗しても、他の端末へのデータ送信が遅れることがない。

１−４．データ送信タスク
図３を参照してデータ送信タスクを説明する。ステップＳ５８、Ｓ６２の処理を先に説明する。ＭＦＤ１０は、データ送信を試行する毎にその結果を記録する。データ送信に成功した場合はその旨を記録し（Ｓ５８）、データ送信に失敗した場合は失敗の原因を特定するエラーコードを宛先に対応付けて記録する（Ｓ６２）。これらの記録を送信履歴と称する。送信履歴を参照することによって、リトライの回数が判明する。送信タスクでは、ＭＦＤ１０はまず指定された宛先（データ送信先の端末名）の送信履歴を参照する。ＭＦＤ１０は、送信履歴を参照して、過去に送信を試行したか否か、即ち、その宛先へのデータ送信が初回の送信かリトライであるかを判断する（Ｓ５０）。初回の送信である場合（Ｓ５０：ＮＯ）、送信方法を選択する（Ｓ５２）。ステップＳ５２では、ＭＦＤ１０は、受け取った送信先端末のＰｒｏｆｉｌｅを参照し、最高位の優先順位が割り当てられている送信方法を選択する。そしてＭＦＤ１０は、選択した送信方法で画像データの送信を試行する（Ｓ５４）。送信に成功した場合（Ｓ５６：ＹＥＳ）、ＭＦＤ１０は、成功した旨（成功情報）を記録する（Ｓ５８）。そして、ＭＦＤ１０は、Ｐｒｏｆｉｌｅを編集し、採用した送信方法の優先順位を最高位に書き換える（Ｓ６０）。送信が失敗した場合（Ｓ５６：ＮＯ）、ＭＦＤ１０は、失敗の原因を特定するエラーコードを記録する（Ｓ６２）。そして送信処理を終了してメイン処理に戻る。なお、Ｓ５２の「送信方法を選択」の処理と、後述するＳ９０の「送信方法を選択」、Ｓ８４の「送信方法の選択」、及び、Ｓ７８の「送信方法の選択」の処理では、送信方法を選択するためのルールが異なる。そこで図３では、選択のルールが異なることを明確にするために、ステップＳ５２、Ｓ７８、Ｓ８４、及びＳ９０の夫々に「（１）」、「（２）」、「（３）」、「（４）」の記号を付している。

ステップＳ５０の処理において、送信先端末へのデータ送信がリトライである場合（Ｓ５０：ＹＥＳ）、ステップ７０へ処理が移行する。ステップ５０の分岐判断がＹＥＳとなる場合は、過去にデータ送信が失敗した場合であり、Ｓ６２の処理によってエラーコードが送信履歴として記録されている。ＭＦＤ１０はエラーコードを参照して、エラーの種類に応じた処理を実行する（Ｓ７０の分岐）。エラーコードが容量不足の場合、即ち、送信先端末が容量不足であるためにデータを受け取ることができなかった場合、ステップＳ７２に処理が移る。ステップＳ７２では、ＭＦＤ１０は、前回の送信試行時刻からの経過時間を確認する。なお、前回の送信試行時刻は、ステップＳ６２においてエラー情報として送信履歴に記録されている。前回の送信試行時刻から予め決められている所定時間が経過している場合（ステップＳ７２：ＹＥＳ）、ＭＦＤ１０は、リトライの回数が予め決められた最大回数に達しているか否かを確認する（Ｓ７４）。リトライ回数が最大回数に達していない場合（Ｓ７４：ＮＯ）、ＭＦＤ１０は、前回と同じ送信方法を選択し（Ｓ７６）、ステップＳ５４へ移行する。即ち、前回と同じ送信方法でデータ送信を試みる。「前回と同じ送信方法」とは、データ送信に失敗したときの送信方法を意味する。他方、リトライ回数が最大回数に達している場合（Ｓ７４：ＹＥＳ）、ＭＦＤ１０は、Ｐｒｏｆｉｌｅに記述された送信方法の優先順位に従って、前回の送信方法（即ち、データ送信に失敗したときの送信方法）の次の順位の送信方法を選択し（Ｓ７８）、ステップＳ５４へ移行する。

他方、ステップＳ７２において、予め決められている所定時間が経過していない場合（ステップＳ７２：ＮＯ）、送信処理を終了する。ステップＳ７２の判断がＮＯの場合には、ステップＳ１６（図２参照）の分岐判断がＮＯとなり、送信先端末が「Ｎｏｔｉｆｙ」の文字列が格納されたキューの前に追加される（Ｓ１８）。そして、キューの前方に位置する他の端末への送信試行が行われた後に、再び、Ｓ１８で追加された送信先端末へのデータ送信タスクが開始する。そのデータ送信タスクでは、ステップＳ７２の処理が実行される。そして、所定の時間が経過していれば、ステップＳ７４へと移行し、データ送信が試行される（Ｓ５４）。

ステップＳ７０において、エラーコードが認証エラーを表す場合、ステップＳ９０へ処理が移行する。ステップＳ９０の処理は次の通りである。前回のデータ送信が認証エラーにより失敗した場合には、ＭＦＤ１０は次のルールで送信方法を選択する。ＭＦＤ１０は、送信先端末のＰｒｏｆｉｌｅを参照する。Ｐｒｏｆｉｌｅに記述された送信方法の優先順位に従って、ＭＦＤ１０は、前回の送信方法（即ち、データ送信に失敗したときの送信方法）の次の順位の送信方法を選択する。ステップＳ９０における送信方法選択の際、ＭＦＤ１０は、認証が必要な送信方法は無視する。すなわちＭＦＤ１０は、認証が必要な送信方法を無視しながら、前回の送信方法の次の順位の送信方法を選択する。そして、ステップＳ５４へと処理が移行する。ＭＦＤ１０は、ステップ９０で選択された送信方法でデータ送信を試みる。ステップＳ９０の処理によって、認証エラーでデータ送信が失敗した場合は、送信方法は異なるが認証が必要な送信方法は選択されない。この処理によって、認証エラーでリトライが再度失敗することが回避される。

ステップＳ７０の処理においてエラーコードが「容量不足」と「認証エラー」のいずれでもない場合は、ステップＳ８０に処理が移行する。ステップＳ８０では、ＭＦＤ１０は、リトライの回数が予め決められた最大回数に達しているか否かを確認する（Ｓ８０）。リトライの回数が最大回数に達していない場合には（Ｓ８０：ＮＯ）、ＭＦＤ１０は、前回と同じ送信方法（即ち、前回にデータ送信に失敗したときの送信方法）を選択する（Ｓ８２）。他方、リトライの回数が最大回数に達している場合には（Ｓ８０：ＹＥＳ）、ＭＦＤ１０は、Ｐｒｏｆｉｌｅに記述された送信方法の優先順位に従って、前回の送信方法（即ち、データ送信に失敗したときの送信方法）の次の順位の送信方法を選択する（Ｓ８４）。そして、ステップＳ５４へ処理が移る。ＭＦＤ１０は、ステップＳ８２、或いはＳ８４で選択された送信方法で、データ送信を試みる。

ＭＦＤ１０は、ステップＳ５８においてデータ送信に成功した旨を送信履歴に記録し、ステップＳ６２においてエラーコードを含むエラーに関する情報を送信履歴に記録する。認証エラーに関する情報は継続的に記録され、参照される。他方、容量不足エラーや通信エラーなどリトライ時に改善される可能性のあるエラー情報は、履歴として保存されるが、それらのエラーが改善された後は参照されない。

上記のデータ送信タスクでは、送信先端末名をキューに記憶していたが、データ送信に失敗した場合には、送信先端末名（宛先）の他にエラーコード（エラーの種類）などもキューに格納してよい。この場合、エラーコードは、その送信先端末名に関連付けられて格納される。キューに格納する送信履歴は、ステップＳ６２の処理とは別個に記録されてよい。
上記のデータ送信タスクでは、リトライの直前に送信方法が決定される（Ｓ５２、Ｓ７６、Ｓ７８、Ｓ８２、Ｓ８４、及びＳ９０）。ＭＦＤ１０は、次回のリトライにおける送信方法を、データ送信に失敗した直後に決定してもよい。その場合、ステップＳ１８において、データ送信に失敗した端末の宛先とともに、次回の送信方法をキューに格納してもよい。この場合、ＭＦＤ１０は、次回の方針方法を、その端末の宛先（送信先端末名）に関連付けてキューに格納する。そうすることで、ＭＦＤ１０は、リトライ時に速やかにデータ送信を試行することができる。
送信方法を決定するステップＳ７８、Ｓ８４、Ｓ９０では、次の送信方法を決定できない場合がある。例えば、今回の送信方法が最も低い優先順位が割り当てられた方法である場合、あるいは、Ｐｒｏｆｉｌｅに送信方法がひとつしか記述されていない場合である。そのような場合には、最終的にデータ送信に失敗した旨のメッセージを送信履歴に記録して処理を終了する。
また、ステップＳ７２において、所定時間経過していないと判断された場合、すなわち、容量不足でエラーと判断されてから所定時間内にリトライの順番が回ってきた場合、本実施例のＭＦＤ１０は、改めてキューの最後尾（「Ｎｏｔｉｆｙ」の前）に宛先を追加し、同じ送信方法でリトライしている。そのような処理に代えて、ＭＦＤ１０は、所定時間経過前にリトライ順が回ってきた場合に、次の優先順位が割り当てられた送信方法でリトライしてもよい。それにより、所定時間経過すれば、端末ユーザにより容量不足が解消されることが予想され、エラー発生時と同じ優先順位の高い送信方法でリトライする利点が得られる。また、所定時間経過前であれば、端末ユーザによる容量不足解消がなされていない可能性が高いため、ＭＦＤ１０は、異なる送信方法でリトライすることで、所定時間を待たずともその端末に対するデータ送信ができる可能性があり、データ送信の遅延を抑制できる。

１−５．キューとマルチタスクの説明
データ送信タスクでは、さらに複数の子タスクが並列に実行される。すなわち、データ送信はいわゆるマルチタスクで実行される。キューとマルチタスクの関係を説明する。キュー内のデータの推移と子タスクの推移の事例を図４に示す。図４の上段がキューを表しており、下段が子タスクのエントリ領域を表している。図４の上段左側がキューの先頭であり、右側がキューの最後である。「エントリ領域」とは、キューから子タスクに渡されるデータを意味する。「エントリ領域」にデータが挿入されると、子タスクは、そのデータに基づいた処理を実行する。本実施例では、２つの子タスク（子タスク１、子タスク２）を仮定するが、子タスクの数はいくつでもよい。

ユーザが４つの端末（ＰＣ１、ＰＣ２、ＰＣ３、及びＰＣ４）を指定してデータ送信の指示をＭＦＤ１０に与えると、４つの端末の宛先が順次キューに積まれる（Ａ）。図４において「ＰＣ１」等の文字が端末の宛先を表す。最後の宛先「ＰＣ４」の後に、「Ｎｏｔｉｆｙ」の文字列が積まれる（Ｂ）。この時点では図４の（Ｃ）、（Ｄ）はキューに現れていない。また、子タスク１及び子タスク２のエントリ領域は空である（１）。ＭＦＤ１０は、キューの先頭のデータ「ＰＣ１」を読み出して子タスク１のエントリ領域にセットする。キューの先頭のデータは読み出されるとキューから削除される。すなわち、この時点では、キューの新たな先頭のデータは「ＰＣ２」となる。ＭＦＤ１０は、キューの新たな先頭のデータ「ＰＣ２」を読み出して子タスク２のエントリ領域にセットする（２）。子タスク１は、「ＰＣ１」へのデータ送信を試行する。子タスク２は、「ＰＣ２」へのデータ送信を試行する。子タスク１ではデータ送信が成功し、子タスク２ではデータ送信が失敗したと仮定する。子タスク２においてデータ送信に失敗した宛先「ＰＣ２」は、キューに積まれた最後の宛先「ＰＣ４」の後（「Ｎｏｔｉｆｙ」の前）に追加される（Ｃ）。「ＰＣ１」へのデータ送信が完了すると、子タスク１のエントリ領域に、キューの新たな先頭のデータ「ＰＣ３」がセットされる。読み出された「ＰＣ３」の文字列はキューから削除される。即ち、「ＰＣ３」が読み出されると、キューの先頭のデータが「ＰＣ３」から「ＰＣ４」に変化する。「ＰＣ２」へのデータ送信の試行が終了すると、子タスク２のエントリ領域に、キューの新たな先頭データ「ＰＣ４」がセットされる（４）。ここで、子タスク１ではデータ送信が失敗し、子タスク２ではデータ送信が成功したと仮定する。子タスク１においてデータ送信に失敗した宛先「ＰＣ３」は、キューに積まれた最後の宛先「ＰＣ２」の後の位置（「Ｎｏｔｉｆｙ」の前の位置）でキューに追加される（Ｄ）。「ＰＣ３」へのデータ送信の試行が終了すると、子タスク１のエントリ領域に、キューの新たな先頭データ「ＰＣ２」がセットされる。読み出された文字列「ＰＣ２」はキューから削除される。「ＰＣ４」へのデータ送信の試行が終了すると、子タスク２のエントリ領域に、キューの新たな先頭のデータ「ＰＣ３」がセットされる（４）。ここで、子タスク１と子タスク２の両方でデータ送信が成功したと仮定する。「ＰＣ２」へのデータ送信が完了すると、子タスク１のエントリ領域に、「Ｎｏｔｉｆｙ」の文字列がセットされる（５）。子タスク１では、文字列「Ｎｏｔｉｆｙ」に対応した処理（即ち、レポートの送信処理）が実行される。このように、データ送信に失敗した端末の宛先は、キューに格納された最後の宛先の次の位置であり、「Ｎｏｔｉｆｙ」の前の位置でキューに追加される。
複数の子タスクが実行されている場合、すべての子タスクにおいて「Ｎｏｔｉｆｙ」以外のデータ送信に係るキューが終了したことを条件として、いずれかの子タスクにおいて「Ｎｏｔｉｆｙ」のキューが実行される。

１−６．ＭＦＤ１０の利点
上記の処理の利点を以下に列挙する。
（１）ＭＦＤ１０は、データ送信に失敗すると、他の端末への送信を試行した後に、データ送信に失敗した端末へのデータ送信を試行する（Ｓ１８）。
（２）ＭＦＤ１０は、データ送信に失敗したときの送信方法と異なる送信方法を選択してデータ送信をリトライする（Ｓ７８、Ｓ８４、及びＳ９０）。
（３）ＭＦＤ１０は、端末毎に、異なる複数の送信方法を、優先順位を付して記憶している。ＭＦＤ１０は、優先順位の高い順に、リトライ時の送信方法を選択する（Ｓ７８、Ｓ８４、及びＳ９０）。前回と異なる送信方法でリトライすることによって、少ないリトライ回数でデータ送信に成功する確率を高めることができる。「異なる送信方法」として、送信プロトコルが異なる送信方法（例えばメールやＦＴＰやＨＴＴＰなど）とデータ転送ルートが異なる送信方法（データ中継サーバが異なる送信方法）が選択可能である。
（４）データ送信の失敗が認証エラーによる失敗でない場合、ＭＦＤ１０は、データ送信に失敗したときの送信方法と同じ送信方法で少なくとも１回リトライする（Ｓ７６、Ｓ８２）。特に、送信先端末の容量不足によってデータ送信が失敗した場合には、ＭＦＤ１０は、優先順位に関わらずに、予め決められた時間間隔の後に同じ送信方法でリトライする（Ｓ７２、Ｓ７６）。容量不足は、ある程度の時間が経過すると解消される場合があるからである。
（５）ＭＦＤ１０は、データ送信に失敗したときの送信方法が認証を必要とする送信方法であった場合、優先順位に関わらずに認証を必要とする他の送信方法を採用しない（Ｓ９０）。この処理は、認証エラーで再びリトライが失敗することを防止する。
（６）ＭＦＤ１０は、送信に成功した送信方法の優先順位を最高位に変更する（Ｓ６０）。ステップＳ６０の処理によって、ＭＦＤ１０は、次回の他のデータの送信処理において、過去に成した送信方法でまずデータ送信を試みることができる。
（７）ＭＦＤ１０は、全ての端末へのデータ送信を試みた後に、予め指定されている端末へ送信結果を通知する（Ｓ２０）。

２．第２実施例
次に第２実施例のＭＦＤ（データ送信装置）を説明する。第２実施例のＭＦＤは、実行する処理が第１実施例のＭＦＤ１０と異なる。以下では、第２実施例のＭＦＤも第１実施例と同様にＭＦＤ１０と称する。図５に、ＭＦＤ１０が実行するメインタスクのフローチャートを示す。図６から図８に、メインタスクから起動される子タスクのフローチャートを示す。データ送信タスクは、子タスクで実行される。即ち、子タスクの処理がデータ送信タスクに相当する。図９と図１０に、メインタスク或いは子タスクからコールされるサブルーチンのフローチャートを示す。なお、本実施例のＭＦＤ１０は、図４に示したように、複数の子タスクが実行されるマルチタスクとして動作する。

図５を参照して、メインタスクを説明する。ユーザは、原稿の読み取り指示とともに、データ送信先の端末の宛先（ＰＣ１〜ＰＣ４）を指定する。ユーザが宛先を指定すると、図４の（Ａ）と（Ｂ）に示したキューが生成される。ＭＦＤ１０は、読み取り指示に従って、セットされた原稿の画像データを読み取る（Ｓ１００）。ＭＦＤ１０は、キューにデータが積まれているか否かを確認する（Ｓ１０２）。次いでＭＦＤ１０は、子タスクが起動可能あるか否かを確認する（Ｓ１０４）。起動可能な子タスクが存在する場合（Ｓ１０４：ＹＥＳ）、ＭＦＤ１０は、キューの先頭のデータを読み出す（Ｓ１０６）。キューの先頭のデータが「Ｎｏｔｉｆｙ」の場合（Ｓ１０８：ＹＥＳ）、ＭＦＤ１０は、Ｎｏｔｉｆｙ処理を実行する（Ｓ１１２）。前述したようにＮｏｔｉｆｙ処理は、データ送信の結果を予め定められた端末へ送信する処理である。Ｎｏｔｉｆｙ処理については後述する。

宛先の他にデータ送信に関する情報がその宛先に関連付けられてキューに格納される。キューに格納される情報をキューパラメータと称する。キューパラメータには、送信方法、送信方法の優先順位、送信履歴が含まれる。なお、ユーザが宛先を指定した直後は、宛先の端末のＰｒｏｆｉｌｅに記述されている最も高い優先順位の送信方法がキューパラメータとしてセットされる。

キューの先頭のデータが「Ｎｏｔｉｆｙ」でない場合（Ｓ１０８：ＮＯ）、すなわち、キューから読み出したデータが宛先の場合、ＭＦＤ１０は、その宛先を子タスクのエントリ領域にセットして子タスクを起動する（Ｓ１１０）。エントリ領域には、宛先とともにキューパラメータがセット（格納）される。すなわち、キュー内のデータがエントリ領域にコピーされる。子タスクは、宛先とキューパラメータに基づいて送信タスクを実行する。子タスクを起動した後はステップＳ１０２へ戻る。

図６から図８を参照して第２実施例における子タスク（即ち送信タスク）を説明する。子タスクではまず、エントリ領域にセットされた送信方法が「Ｗａｉｔ」であるか否かを確認する（Ｓ２００）。「Ｗａｉｔ」の文字列は、前回のデータ送信が端末の容量不足により失敗したときに、子タスク内で設定されることがある。「Ｗａｉｔ」が設定される条件については後述する。セットされた送信方法が「Ｗａｉｔ」以外の場合（Ｓ２００：ＮＯ）、ＭＦＤ１０はセットされた送信方法でデータ送信を試みる（Ｓ２０２）。送信されるデータは、ステップＳ１００において読み取った画像データである。セットされた送信方法が「Ｗａｉｔ」の場合（Ｓ２００：ＹＥＳ）、ＭＦＤ１０は、ステップＳ２５０の処理を実行する。「Ｗａｉｔ」は、送信失敗の時点から所定の時間が経過するまでリトライを延期するための処理である。ステップＳ２５０の処理については図８を参照して後述する。データ送信に成功した場合（Ｓ２０４：ＹＥＳ）、ＭＦＤ１０は、データ送信が正常に終了したことを送信履歴にセットする（Ｓ２０６）。ＭＦＤ１０はセットした履歴を保存する（Ｓ２０８）。ステップＳ２０８においてＭＦＤ１０は、送信履歴を保存する期間を計測するためにタイマをスタートする。他方、データ送信に失敗した場合（Ｓ２０４：ＮＯ）、ＭＦＤ１０は送信履歴にエラーコードなどのエラー情報をセットする（Ｓ２１０）。Ｓ２１０以降のフローチャートは図７に示されている。

データ送信失敗の原因が認証エラーの場合（Ｓ２２０：ＹＥＳ）、ＭＦＤ１０は、Ｐｒｏｆｉｌｅを参照して次回の送信方法を検索する（Ｓ２３６）。データ送信失敗の原因は、ステップＳ２１０でセットされたエラーコードから判別される。送信方法の検索処理（Ｓ２３６）では、送信先の端末のＰｒｏｆｉｌｅに記述された優先順位に従って、今回の送信方法の次の優先順位の送信方法が検索される。送信方法の検索処理では、エラーの種類に応じたルールに基づいて、次の優先順位の送信方法が検索される。すなわち、ステップＳ２３６では、今回のデータ送信が認証エラーによって失敗したことが考慮される。なお、送信方法の検索処理では、適切な送信方法が見つからない場合もある。送信方法の検索処理については図９を参照して後述する。送信方法の検索処理によって送信方法が見つかった場合（Ｓ２３８：ＹＥＳ）、検索された送信方法がセットされる（Ｓ２４２）。ステップＳ２３８で送信方法が見つからなかった場合（Ｓ２３８：ＮＯ）、ＭＦＤ１０はエラーの最終履歴をセットして（Ｓ２４４）、子タスクを終了する。

図７のステップＳ２２０に戻って説明を続ける。今回のエラーが、認証エラーでなく（Ｓ２２０：ＮＯ）、送信先の端末の容量不足の場合（Ｓ２２２：ＹＥＳ）、図８に示したフローチャートに処理が移る。容量不足の場合の処理は後述する。今回のエラーが容量不足によるエラーでもなかった場合（Ｓ２２２：ＮＯ）、即ち、データ送信失敗の原因が他の通信エラーであった場合、ＭＦＤ１０は、同じ宛先へのデータ送信のリトライの回数が予め決められた最大回数に達したか否かを確認する（Ｓ２２４）。リトライの回数が最大回数に達していない場合（Ｓ２２４：ＮＯ）、ＭＦＤ１０は、今回の送信方法を次回の送信方法としてセットする（Ｓ２２６）。次いでＭＦＤ１０は、ステップＳ２２６でセットした送信方法の優先順位を記憶する（Ｓ２２８）。そしてＭＦＤ１０は、次回のリトライのために、今回データ送信に失敗した端末の宛先とともに、キューパラメータをキューに格納する（Ｓ２３０）。ステップＳ２３０では、キューの最後の宛先の次に宛先とキューパラメータが挿入される。ステップＳ２３０では、ステップＳ２２６でセットされた次回の送信方法、ステップＳ２２８で記憶された優先順位、ステップ２１０でセットされたエラー情報がキューに格納される。この場合、キューパラメータは、宛先（送信先端末名）に関連付けられてキューに格納される。なお、エラーの種類に応じて、ステップＳ２２６の代わりにステップＳ２４０、Ｓ２４２、Ｓ２６０、又はＳ２６６いずれかが実行される場合がある。それらのステップの後にＳ２２８、Ｓ２３０が実行される場合、直前にセットされた送信方法とその優先順位がキューパラメータとしてキューに格納される。また容量不足エラーによってデータ送信が失敗した場合（Ｓ２２２：ＹＥＳ）、容量不足エラーの発生時刻がステップＳ２５２で記憶される。容量不足エラーの場合、エラー発生時刻もキューパラメータとしてキューに格納される。

ステップＳ２２４の説明に戻る。リトライの回数が最大回数に達している場合（Ｓ２２４：ＹＥＳ）、ＭＦＤ１０はＰｒｏｆｉｌｅを参照して、今回の送信方法の次の優先順位の送信方法が存在するか否かを確認する（Ｓ２３２）。次の優先順位の送信方法が存在しない場合（Ｓ２３２：ＮＯ）、エラーの最終履歴をセットして（Ｓ２４４）、子タスクを終了する。次の優先順位の送信方法が存在する場合（Ｓ２３２：ＹＥＳ）、ＭＦＤ１０は認証エラーの履歴が存在するか否かを確認する（Ｓ２３４）。ＭＦＤ１０は、データ送信履歴を参照して過去の認証エラーの存在を確認する。認証エラーの履歴が存在しない場合（Ｓ２３４：ＮＯ）、ＭＦＤ１０は、前回と同じ送信方法をセットする（Ｓ２４０）。前述したように、ステップＳ２４０が実行された場合、Ｓ２４０でセットされた送信方法が宛先に関連付けられてキューに格納される（Ｓ２３０）。他方、認証エラーの履歴が存在する場合（Ｓ２３４：ＹＥＳ）、すなわち、過去に認証エラーが発生していた場合、ステップＳ２３６に処理が移る。Ｓ２３６以降の処理は前述したとおりである。

ステップＳ２２２に戻って説明を続ける。容量不足エラーが発生していた場合（Ｓ２２２：ＹＥＳ）、図８のフローチャートに処理が移る。容量不足エラーが今回のデータ送信の試行で発生した場合（Ｓ２５０：ＹＥＳ）、ＭＦＤ１０は、エラー発生時刻を記憶する（Ｓ２５２）。そして、ＭＦＤ１０は、次回の送信方法として「Ｗａｉｔ」をセットする（Ｓ２５８）。次いでＭＦＤ１０は、セットされた「Ｗａｉｔ」をキューに格納する（Ｓ２３０）。他方、容量不足エラーが過去のデータ送信試行で発生した場合（Ｓ２５０：ＮＯ）、ＭＦＤ１０は、同じ宛先へのデータ送信のリトライの回数が予め決められた最大回数に達したか否かを確認する（Ｓ２５４）。リトライの回数が最大回数に達していない場合（Ｓ２５４：ＮＯ）、ＭＦＤ１０は、容量不足のエラーの発生時刻（ステップＳ２５２で記憶）から現在までの経過時間を算出する（Ｓ２５６）。経過時間が予め定められた閾値よりも小さい場合（Ｓ２５６：ＮＯ）、ＭＦＤ１０は、次回の送信方法として「Ｗａｉｔ」をセットし（Ｓ２５８）、次いでステップＳ２３０に移行する。「Ｗａｉｔ」がキューに格納されると、次のリトライ時にデータ送信が行われない（図６のＳ２００）。これは、容量不足エラーの場合、一定時間が経過するまでは容量不足が解消されない可能性が高いからである。容量不足エラーの発生時刻から所定の時間が経過している場合（Ｓ２５６：ＹＥＳ）、ＭＦＤ１０は、今回の送信方法をセットする（Ｓ２６０）。ステップＳ２６０でセットされた送信方法が、キューに格納される（Ｓ２３０）。

ステップＳ２５４の判断において、リトライ回数が最大回数に達している場合（Ｓ２５４：ＹＥＳ）、ＭＦＤ１０は、次の送信方法を検索する（Ｓ２６２）。ステップＳ２６２における送信方法の検索処理は、ステップＳ２３６の検索処理と同様に、送信先の端末のＰｒｏｆｉｌｅに記述された優先順位に従って、今回の送信方法の次の優先順位の送信方法が検索される。ただし、ステップＳ２６２では、前回のエラーが容量不足エラーであったことが考慮される。ステップＳ２６２の処理によって次の送信方法が発見された場合（Ｓ２６４：ＹＥＳ）、ＭＦＤ１０は、見つかった送信方法をセットする（Ｓ２６６）。ステップＳ２６６でセットされた送信方法は、次回のリトライのためにキューに格納される（Ｓ２３０）。ステップＳ２６４で送信方法が見つからなかった場合（Ｓ２６４：ＮＯ）、ＭＦＤ１０は、エラー最終履歴をセットして子タスクを終了する（Ｓ２６８）。

次に、子タスクのステップＳ２３６とＳ２６２で呼び出される送信方法検索処理について説明する。図９に、送信方法検索処理のフローチャートを示す。ＭＦＤ１０は、宛先の端末のＰｒｏｆｉｌｅを参照して、今回の送信方法の次の優先順位が割り当てられた送信方法を抽出する（Ｓ３００）。今回の送信方法が、最下位の送信方法であった場合、あるいは、Ｐｒｏｆｉｌｅにひとつの送信方法のみが記述されている場合には、ＭＦＤ１０は次の送信方法の抽出に失敗する。抽出に失敗した場合（Ｓ３０２：ＮＯ）、ＭＦＤ１０は、送信方法未発見を示すメッセージを引数にして送信方法検索処理を終了する（Ｓ３０８）。送信方法の抽出に成功した場合（Ｓ３０２：ＹＥＳ）、ＭＦＤ１０は、抽出した送信方法が有用か否かを判断する（Ｓ３０４）。ＭＦＤ１０は、データ送信履歴を参照して、データ送信失敗の原因のエラーに応じて、抽出した送信方法が有用か否かを確認する。ステップＳ３０４の判断は次の通りである。
（１）認証エラーの場合：抽出した送信方法が認証を必要とする方法の場合、ＭＦＤ１０は「有用でない」と判断する。他方、抽出した送信方法が認証を必要としない方法の場合、ＭＦＤ１０は「有用である」と判断する。これは、認証エラーが発生した後は、他の送信方法であっても認証エラーを必要とする方法は再度データ送信が失敗する可能性が高いからである。
（２）容量不足エラーの場合：抽出した送信方法が端末に直接データを送信する方法の場合、ＭＦＤ１０は「有用でない」と判断する。他方、抽出した送信方法が間接的にデータを送信する方法の場合、ＭＦＤ１０は「有用である」と判断する。間接的にデータを送信する方法とは、具体的にはサーバ経由の送信方法、或いは電子メールによる送信方法である。
抽出した送信方法が「有用である」と判断された場合（Ｓ３０４：ＹＥＳ）、ＭＦＤ１０は、抽出した送信方法を引数にして送信方法検索処理を終了する（Ｓ３０６）。抽出した送信方法が「有用でない」と判断された場合（Ｓ３０４：ＮＯ）、ＭＦＤ１０は、ステップＳ３００に戻り、次の優先順位が割り当てられた送信方法を抽出し、上記の処理を繰り返す。

最後に、図５のＮｏｔｉｆｙ処理について説明する。図１０にＮｏｔｉｆｙ処理のフローチャートを示す。ＭＦＤ１０は、Ｐｒｏｆｉｌｅを参照して、送信結果レポート（送信履歴）の送信先の情報を取得する（Ｓ３２０）。送信先の情報には、レポートの宛先と送信方法が記述されている。レポート送信リトライ回数が最大回数に達していない場合（Ｓ３２２：ＮＯ）、ＭＦＤ１０は、ステップＳ３２０で取得した送信方法でレポートを送信する（Ｓ３２４）。レポートのリトライ回数が最大回数に達している場合（Ｓ３２２：ＹＥＳ）、ＭＦＤ１０は、レポートが送信できなかった旨のメッセージを最終履歴としてセットする（Ｓ３２６）。ＭＦＤ１０は最後に、セットした最終履歴を保存する（Ｓ３２８）。ステップＳ３２８においてＭＦＤ１０は、最終履歴を保存する期間を計測するためのタイマをスタートする。

第２実施例のＭＦＤ１０（データ送信装置）は、次の利点を有している。
（１）データ送信に失敗した端末の宛先をキューに追加する処理が、データ送信を実行する子タスクの中で実行される（Ｓ２３０）。子タスクは、メインタスクから次々と起動されることができる（Ｓ１１０）。従って、ＭＦＤ１０は、エラー時の処理と平行して、次の宛先へのデータ送信の試行を実行できる。これによって送信処理が効率化する。
（２）データ送信に失敗した子タスク内で、次の送信方法が決定される（Ｓ２２６、Ｓ２４０．Ｓ２４２、Ｓ２６０、及びＳ２６６）。別言すればＭＦＤ１０は、データ送信に失敗したときに、キューの新たな先頭に格納された宛先へのデータ送信に先立ってリトライ時の送信方法を決定する。従って、リトライ時に送信方法を決定する必要がなく、データ送信のリトライが迅速に行われる。
（３）データ送信に失敗した端末の宛先をキューに追加する際に、ＭＦＤ１０は、次の送信方法を宛先に関連付けてキューに格納する（Ｓ２３０）。子タスクは、キューに格納されたデータを参照するだけでリトライを実行できる。子タスクは、他にデータを参照する必要がないので、処理が迅速化する。

以上、本発明の具体例を詳細に説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。例えば、実施例では、読み取った画像データを送信する場合を説明した。データ送信は画像データに限られない。

また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。

ＭＦＤのブロック図を示す。 第１実施例のＭＦＤのメイン処理のフローチャートを示す。 第１実施例のデータ送信処理のフローチャートを示す。 キュー内のデータの推移と子タスクの推移を説明する図である。 第２実施例のＭＦＤのメイン処理のフローチャートを示す。 子タスクのフローチャートを示す（１）。 子タスクのフローチャートを示す（２）。 子タスクのフローチャートを示す（３）。 送信方法検索処理のフローチャートを示す。 Ｎｏｔｉｆｙ処理のフローチャートを示す。

符号の説明

１０：ＭＦＤ（データ送信装置）
１２：ＣＰＵ
１４：ストレージ
１６：メインモジュール
１８：通信制御モジュール
２２：コンソール
２４：ディスプレイ
５０：ローカルエリアネットワーク

Claims (10)

1. ローカルエリアネットワークを介して複数の端末に同一のデータを順次に送信するデータ送信装置であり、
   一の端末へのデータ送信に失敗した場合、他の端末へのデータ送信を試みたことを条件として、前記一の端末へのデータ送信を、データ送信に失敗したときの送信方法と異なる送信方法でリトライすることを特徴とするデータ送信装置。
2. 前記異なる送信方法は、送信プロトコルとデータ転送ルートの少なくとも一方が、データ送信に失敗したときと異なることを特徴とする請求項１に記載のデータ送信装置。
3. データ送信に失敗したときの送信方法と同じ送信方法で少なくとも１回リトライし、同じ送信方法によるリトライが成功しなかった場合に、異なる送信方法でリトライすることを特徴とする請求項１又は２に記載のデータ送信装置。
4. 端末ごとに複数の送信方法を優先順位付きで記憶しており、優先順位の高い順に、リトライ時の送信方法を選択することを特徴とする請求項１から３のいずれか１項に記載のデータ送信装置。
5. 認証を必要とする複数の送信方法を記憶しており、データ送信に失敗したときの送信方法が認証を必要とするいずれかの送信方法であった場合、優先順位に関わらずに認証を必要とする他の送信方法を採用しないことを特徴とする請求項４に記載のデータ送信装置。
6. データ送信先端末の容量不足が原因でデータ送信が失敗した場合、優先順位に関わらずに、予め決められた時間間隔の後に同じ送信方法でリトライすることを特徴とする請求項４に記載のデータ送信装置。
7. 送信に成功した送信方法の優先順位を最高位に変更することを特徴とする請求項４から６のいずれか１項に記載のデータ送信装置。
8. データ送信装置は、データを送信する送信タスクへ端末の宛先を渡すためのキューを備えており、データの送信に失敗した端末の宛先を、キューに格納された最後の宛先の次の位置でキューに追加することを特徴とする請求項１から７のいずれか１項に記載のデータ送信装置。
9. データ送信装置は、データ送信に失敗したことを条件として次回の送信方法を決定し、データ送信に失敗した端末の宛先とともに、決定した送信方法をキューに格納された最後の宛先の次の位置でキューに追加することを特徴とする請求項８に記載のデータ送信装置。
10. 全ての端末へのデータ送信を試みた後に、予め指定されている端末へ送信結果を通知することを特徴とする請求項１から９のいずれか１項に記載のデータ送信装置。
    

Images