(57)【要約】【課題】  接続されたコンピュータから転送される画像に表紙をつけて送信するファクシミリ装置において、表紙と本文が宛先ごとにＰＣから渡されていた。【解決手段】  送信時にＰＣからファクシミリ装置へ、複数の表紙情報と１つの画像ファイルを転送し、ファクシミリ装置からそれぞれの宛先へそれぞれの表紙を送信し、画像ファイルは、宛先の分だけ複数回送信する。【選択図】  図１
2005210254.tif 000002
【特許請求の範囲】
【請求項１】
外部コンピュータから、ファクシミリ送信ジョブを投入する際に
（１）複数の宛先データを指示する手段
（２）複数の表紙データを転送する手段
（３）（２）の表紙と（１）の宛先データとを関連づける手段
（４）すべての宛先に共通な画像データ（本文）を転送する手段
以上の（１）〜（４）を１ジョブとして指示することができるファクシミリ。
そのあと、ファクシミリは宛先ごとに指示された表紙と本文とを送信する。
【請求項２】
請求項１において、宛先データに対する表紙がないことを指定できる手段を持つことを特徴とするファクシミリ。
【発明の詳細な説明】
【技術分野】
【０００１】
コンピュータから画像データと宛先データとを受信し、その指示に従ってファクシミリ手順で送信するファクシミリ装置に関するものである。
【背景技術】
【０００２】
最近、コンピュータから画像データと宛先データとを受信し、その指示に従ってファクシミリ手順で送信するファクシミリが販売されている。これらのファクシミリに対して、１文書を複数の宛先に送信する場合で、各宛先ごとに宛先に応じた表紙を添付を指示することができる。
【０００３】
接続されたコンピュータから転送される画像に表紙をつけて送信するものはある（例えば特許文献１および特許文献２）。
【特許文献１】特開平０５−０９５３７１号公報
【特許文献２】特開平０９−２４７４１６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記の場合図２に示すように１宛先、表紙、本文を１ジョブとして宛先数分ジョブを送信していた。そのため、ファクシミリ本体内には同一の本文（画像）が宛先数分転送されていた。本体内の画像を蓄積するメモリの制約上、大量の本文でかつ宛先件数が大量の場合には、すべてジョブを受付けることができなかった。また受け付けることができても、画像メモリの大部分を占有してしまうため、操作部からの送信ジョブや受信ジョブが制約されてしまった。
【課題を解決するための手段】
【０００５】
本発明では、図３に示すように複数宛先、複数の表紙、１つの本文をまとめて１ジョブとして扱うことで上記欠点を解決する。
【０００６】
すなわち、外部コンピュータから、ファクシミリ送信ジョブを投入する際に
（１）複数の宛先データを指示する手段
（２）複数の表紙を転送する手段
（３）（２）の表紙と（１）の宛先データとを関連づける手段
（４）すべての宛先に共通な画像データ（本文）を転送する手段
（５）以上の（１）〜（４）を１ジョブとして指示することができるファクシミリ。そのあと、ファクシミリは宛先ごとに指示された表紙と本文とを送信する。
【発明の効果】
【０００７】
以上説明したように本発明によれば、ファクシミリ内のメモリを大幅に節約することができる。このことにより従来メモリ容量の制約により投入できなかったジョブが、投入できるようになる。また、ホストとファクシミリ間の通信においても本文の転送分が短くなり、短時間でジョブの投入が可能となる。
【発明を実施するための最良の形態】
【０００８】
（実施例１）
図１は本発明を実現するための構成図である。
【０００９】
１−ａ：１０キー、各種ファンクションキー、ＬＣＤで構成される操作部である。
【００１０】
１−ｂ：原稿を読取り、白黒に２値し１−ｄの画像メモリに蓄積する読取部である。
【００１１】
１−ｃ：１−ｄの画像メモリからデーを取り出しプリントする記録部である。
【００１２】
１−ｄ：読取部で読み取られた画像や受信した画像を蓄積する画像メモリである。
【００１３】
１−ｅ：ＮＣＵ（ネットワーク制御ユニット）、モデム、画像の符号化・復号化を行うコーデックから構成される通信制御部である。これは回線１の制御を行う。
【００１４】
１−ｆ：ＣＰＵ、ＲＯＭ、ＲＡＭで構成され、１−ａ〜１−ｇまでを制御する制御部である。
【００１５】
図４は本発明を実施するために使用される本体内で管理されるデータ構造である。
【００１６】
４−ａ：１回に指定されたジョブを管理するテーブルである。この中には、複数の宛先情報と本文情報が格納される。ジョブが終了するとこのテーブルは解放される。
【００１７】
４−ｂ：１件分宛先に関する情報を格納する。ここでは２件分用意している。１件分の宛先情報には、発信に関する電話番号（４−ｃ）と表紙ページに関するページ情報（４−ｄ）が格納される。
【００１８】
４−ｃ：電話番号の他に、発信すべき電話番号が登録されているか否か、送信は既に終了しているか否か等の情報も合わせて格納される。
【００１９】
４−ｄ：ページ情報の中には、画像の有無や紙サイズ、解像度、格納されている画像メモリアドレス等がある。なお、表紙を付けない場合には、画像の無しを設定する。
【００２０】
４−ｅ：本文に関する情報テーブルである。ここでは５ページ分のテーブルを用意している。ページ情報の中身は表紙の場合と同一である。
【００２１】
図５は、本発明におけるホストコンピュータからのジョブ投入からジョブ開始までのフローチャートである。
【００２２】
５−ａ：コマンドを解析して開始コマンドならば５−ｅへ、そうでなければ５−ｂへ進む。
【００２３】
５−ｂ：コマンド解析して宛先データならば５−ｆへ、そうでなければ５−ｃへ進む。
【００２４】
５−ｃ：コマンドを解析して本文データなら５−ｉへ、そうでなければすなわち終了コマンドならば５−ｄへ進む。
【００２５】
５−ｄ：ジョブテーブルの設定が完了しているので、送信開始する。
【００２６】
５−ｅ：ジョブテーブルから１ジョブ分のテーブルを確保する。
【００２７】
５−ｆ：宛先データを４−ｂに格納する。既に１件目が登録されていれば２件めの宛先情報領域に格納する。
【００２８】
５−ｇ：コマンドを解析して表紙データの有無を確認する。表紙がなければ表紙のページ情報の画像の有無に「無し」を登録し５−ａへ戻る。表紙があれば表紙のページ情報の画像の有無に「有り」を登録し５−ｈへ進む。
【００２９】
５−ｈ：表紙データを画像メモリに格納する。格納が終了したら、表紙のページ情報の画像メモリアドレスに格納したアドレスを登録する。また紙サイズや解像度も合わせて登録しておく。
【００３０】
５−ｉ：本文データを画像メモリに格納する。格納が終了したら、ページ情報の中を５−ｈと同様に更新する。複数の本文データを受信したら、その都度、次のページ情報領域に格納していく。
【００３１】
図６は、本発明における発信からすべての宛先送信終了までのフローチャートである。
【００３２】
６−ａ：発信する宛先を検索する。ジョブテーブルの宛先情報（４−ｂ）の中から未発信宛先の電話番号を検出する。その電話番号で発信する。
【００３３】
６−ｂ：発信した宛先に対応されたページ情報（４−ｄ）の画像の有無すなわち表紙の有無を確認する。表紙があれば６−ｃへ、なければ６−ｄへ進む。
【００３４】
６−ｃ：表紙のページ情報から画像メモリアドレスを抜き出し、その画像を送信する。
【００３５】
６−ｄ：ジョブテーブルの本文（４−ｅ）のページ情報を順次取り出し、送信する。全ページ送信終了したら、その旨を発信した宛先情報の電話番号（４−ｃ）のテーブルに書き込む。
【００３６】
６−ｅ：すべての宛先に送信したら終了する。まだ未発信の宛先が残っていたら、６−ａに戻る。
【００３７】
（他の実施例）
前述の例では、すべての宛先に対してそれぞれ異なった表紙を付けて送信するようにしている。ただし、宛先データコマンドを通知時に表紙データが無いことも指定できる。言い換えれば、宛先毎に表紙データを付けたり付けなかったりの指定ができることになる。
【図面の簡単な説明】
【００３８】
【図１】本発明を実現するための構成図
【図２】従来ホストシーケンス
【図３】本発明ホストシーケンス
【図４】本発明を実施するために使用される本体内で管理されるデータ構造
【図５】本発明におけるホストコンピュータからのジョブ投入からジョブ開始までのフローチャート
【図６】本発明における発信からすべての宛先送信終了までのフローチャート
【図１】
2005210254.tif 000003
【図２】
2005210254.tif 000004
【図３】
2005210254.tif 000005
【図４】
2005210254.tif 000006
【図５】
2005210254.tif 000007
【図６】
2005210254.tif 000008