(57)【特許請求の範囲】
【請求項１】
ネットワークを介して送信依頼元クライアント装置からの付帯情報と文書データ本体とからなる送信依頼ジョブを受信し、受信した送信依頼ジョブに係る文書データを前記付帯情報として通知された宛先に送信する通信装置において、
前記送信依頼ジョブの受信を開始する前に、前記送信依頼ジョブに対応したログ情報のためのメモリ領域を確保できるか否かを判断している判断手段と、
前記判断手段が前記メモリ領域を確保できないと判断している場合には、送信依頼の受付けを行えなかった旨の通知を、受信した前記送信依頼ジョブに含まれる前記付帯情報にて通知された送信依頼元クライアント装置へ送信し、前記判断手段が前記メモリ領域を確保できると判断した場合には、前記送信依頼ジョブの全ての依頼データの受信を行い、その受信を完了すると、受信した送信依頼ジョブにかかる送信依頼を処理する送信手段とを備えたことを特徴とする通信装置。
【請求項２】
ネットワークを介して送信依頼元クライアント装置からの付帯情報と文書データ本体とからなる送信依頼ジョブを受信し、受信した送信依頼ジョブに係る文書データを前記付帯情報として通知された宛先に送信する通信装置において、
前記送信依頼ジョブの受信を開始する前に、前記送信依頼ジョブに対応したログ情報のためのメモリ領域を確保できるか否かを判断している判断手段と、
前記判断手段が前記メモリ領域を確保できないと判断している場合には、送信依頼ジョブ受信に係る前記送信依頼元クライアント装置との前記ネットワークを介した通信を強制中断する通信強制中断手段とを備えたことを特徴とする通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置に関し、特にクライアント装置からの送信依頼ジョブの受付け処理に関する。
【背景技術】
【０００２】
ネットワークを介して、クライアント装置から送信依頼に係る文書データの転送を受けて、その送信依頼文書データを指定さた宛先に送信する通信装置においては、送信依頼文書データの指定された宛先への送信の完了後にその送信結果（正常に送信完了、送信エラー等）を依頼元クライアント装置に通知するようにしたものがある（特許文献１ないし３等）。オペパネ表示のように、送信依頼に対してのエラーをユーザーインタフェースに表示できるものもある。
【特許文献１】特開2000-354146号公報
【特許文献２】特開2002-281229号公報
【特許文献３】特開2001-285561平号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ここで、クライアント装置側からみた場合、送信依頼に係る文書データが通信装置により正しく受け付けられ、更に、指定した宛先に正しく送信されて初めて、送信依頼が成功裏に処理されたといえる。
【０００４】
しかしながら、従来は、通信装置における送信依頼文書データの指定した宛先への送信に関しての結果が依頼元クライアント装置に通知されていなかった。
【０００５】
つまり、クライアント装置が通信装置に対して行った送信依頼が通信装置において正常に受け付けられない場合も、クライアント装置から見れば送信依頼の失敗といえるのに、そのことをクライアント装置側が知ることができなかった。
【０００６】
本発明は係る事情に鑑みてなされたものであり、クライアント装置が通信装置に対して行った送信依頼が通信装置において正常に受け付けられないことを理由に、クライアント装置からの送信依頼が失敗した場合に、そのことをクライアント装置側に知らせることができる利便性の高い通信装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の通信装置は、ネットワークを介して送信依頼元クライアント装置からの付帯情報と文書データ本体とからなる送信依頼ジョブを受信し、受信した送信依頼ジョブに係る文書データを上記付帯情報として通知された宛先に送信する通信装置において、ネットワークを介して送信依頼元クライアント装置からの付帯情報と文書データ本体とからなる送信依頼ジョブを受信し、受信した送信依頼ジョブに係る文書データを前記付帯情報として通知された宛先に送信する通信装置において、上記送信依頼ジョブの受信を開始する前に、上記送信依頼ジョブに対応したログ情報のためのメモリ領域を確保できるか否かを判断している判断手段と、上記判断手段が上記メモリ領域を確保できないと判断している場合には、送信依頼の受付けを行えなかった旨の通知を、受信した上記送信依頼ジョブに含まれる上記付帯情報にて通知された送信依頼元クライアント装置へ送信し、上記判断手段が上記メモリ領域を確保できると判断した場合には、上記送信依頼ジョブの全ての依頼データの受信を行い、その受信を完了すると、受信した送信依頼ジョブにかかる送信依頼を処理する送信手段とを備えたものである。
【０００８】
また、本発明の他の通信装置は、ネットワークを介して送信依頼元クライアント装置からの付帯情報と文書データ本体とからなる送信依頼ジョブを受信し、受信した送信依頼ジョブに係る文書データを上記付帯情報として通知された宛先に送信する通信装置において、上記送信依頼ジョブの受信を開始する前に、上記送信依頼ジョブに対応したログ情報のためのメモリ領域を確保できるか否かを判断している判断手段と、上記判断手段が上記メモリ領域を確保できないと判断している場合には、送信依頼ジョブ受信に係る上記送信依頼元クライアント装置との上記ネットワークを介した通信を強制中断する通信強制中断手段とを備えたものである。
【発明の効果】
【０００９】
以上の本発明の通信装置によれば、送信依頼受付けの段階で送信依頼が失敗したことを依頼元に電子メールにより通知することが可能となる効果が得られる。
【００１０】
また、送信依頼受付けの段階で送信依頼が失敗したことを送信依頼に係る通信を強制中断することで依頼元に認識させることが可能となる効果も得られる。
【発明を実施するための最良の形態】
【００１１】
以下、添付図面を参照しながら、本発明を実施するための最良の形態について説明する。
【００１３】
図１に、本発明を実施するための最良の形態に係る通信装置１を含むシステム構成について示す。
【００１４】
同図において、通信装置１は、ＰＳＴＮ２００を介してＰＳＴＮ２００上の通信装置２０１との間で文書データの送受信を行うことができる。また、通信装置１は、もしＩＳＤＮ３００とのインターフェースを備えればＩＳＤＮ３００上の通信装置３０１との間での文書データの送受信も可能である（本発明を実施するための最良の形態では備えていない）。また、通信装置１は、ＬＡＮ５００に接続され、パケット変換を行うルータ装置５０２を介してインターネット４００に接続され、インターネット４００上のパーソナルコンピュータ４０２との間で電子メールによる画像データの送受信や、インターネット４００上のネットワーク通信装置４０１との電子メールやＩＴＵ−Ｔ勧告Ｔ．３８などに基づくリアルタイムネットワークファクシミリ通信による文書データの送受信を行うことができる。また、通信装置１は、ＬＡＮ５００上のパーソナルコンピュータ（ＰＣ）５０１ａ、５０１ｂ、５０１ｃ等との間で文書データのやりとりを行うことができ、依頼元クライアント装置としての各ＰＣからの送信依頼に係る文書データの転送を受けて、併せて指定された宛先（ＰＳＴＮ２００上の通信装置２０１やインターネット４００上のネットワーク通信装置４０１，ＰＣ４０２等）に対して送信依頼に係る文書データを送信する送信依頼受付機能を備えている。
【００１５】
つまり、通信装置１は、公衆回線を介した通常の通信装置、ネットワーク通信装置、ＰＣ５０１ａ等にとってのスキャナ装置、ＰＣ５０１ａ等にとってのプリンタ装置、複写機、送信代行装置等としての機能を複合的に備えたものである。
【００１６】
図２に、通信装置１のブロック構成について示す。
【００１７】
同図において、ＣＰＵ２は、ＲＡＭ４を作業領域として使用しつつ、ＲＯＭ３に書き込まれた制御プログラムに基づいて装置各部を制御したり、各種データ処理をしたり、プロトコル制御を行う中央演算処理装置である。
【００１８】
ＲＯＭ３は、ＣＰＵ２が装置各部を制御するための制御プログラムや、各文字コードに対応するフォントデータなどの制御に必要な各種データが記憶されるリードオンリメモリである。
【００１９】
ＲＡＭ４は、前述したようにＣＰＵ２の作業領域として使用されるランダムアクセスメモリである。
【００２０】
ＥＥＰＲＯＭ（電気的に書き換え可能な読み出し専用メモリ）５は、装置動作に必要な各種情報が記憶されると共に、装置の電源がオフされた状態でもその記憶内容を保持するためのメモリであり、バッテリバックアップされたＳＲＡＭ（スタティックＲＡＭ）や磁気ディスク装置への置き換えも可能である。
【００２１】
時計回路６は、現在の日付及び時刻を常に計時しているもので、ＣＰＵ２は、システムバス１４を介して時計回路６を読み出すことで、現在の日時（日付と時刻）を知ることができる。
【００２２】
操作表示部７は、ユーザからの操作入力を受け入れるための各種キーが配設される一方、液晶表示装置等の表示器を備え、ユーザに知らせるべき装置の動作状態や、各種メッセージを表示するものである。
【００２３】
読取部８は、原稿を読み取って画データを得るためのものである。この読取部８の構成については、後に詳細に説明する。
【００２４】
画像形成部９は、画像データを記録紙に印刷出力するためのものである。
【００２５】
画像処理部１０は、生の画像データの符号化圧縮、及び、符号化された圧縮データの復号伸張の符号化復号化処理や、２値化処理、変倍処理、縮小拡大処理、画像補正処理、画データを構成する各主走査ラインにおける画素順番の並べ替え処理、送信日時や受信日時の文字列情報などの付加情報の付加処理などの、通信装置１において扱う画データに関する各種処理を行う。
【００２６】
ＬＡＮ通信制御部１０は、いわゆるＮＩＣ（Network Interface Card）であり、ＬＡＮ５００に接続され、ＬＡＮプロトコル上でのＣＰＵ２によるＴＣＰ／ＩＰプロトコルのやりとりにより、その上位のプロトコルにより各種情報のやりとりなどを行えるようにするためのものである。
【００２７】
通信制御部１２は、ＮＣＵ部１３を介してＰＳＴＮ２００と接続され、相手側通信端末との通信の制御を行う。その通信制御部１２は、ＮＣＵ部１３を制御し、ＮＣＵ部１３にて検出されたリンギング電圧のパルスの検出や、ＤＴＭＦ信号の検出、トーン信号の検出、送信時の発呼を行う。また、通信制御部１２は、モデムを有しており、相手側通信端末より受信した受信データ（変調されている）を復調したり、逆に、送信時の送信データを変調し送信したりする。具体的には、ＩＴＵ−Ｔ勧告Ｔ．３０に基づくＧ３ファクシミリ制御信号をやりとりするための低速モデム機能能（Ｖ．２１モデム）、及び、主に文書画像データをやりとりするための高速モデム機能である、Ｖ．１７、Ｖ．３３、Ｖ．３４、Ｖ．２９、Ｖ．２７ｔｅｒの各モデム機能を備えている。
【００２８】
ＮＣＵ部１３はＰＳＴＮ２００に接続され、回線の閉結や、呼び出し信号（リンギング）の検出などをおこなう。
【００２９】
システムバス１４は、上記各部がデータをやり取りするためのデータバス・アドレスバス・制御バス、割り込み信号ラインなどにより構成される信号ラインである。
【００３０】
図３に通信装置１のＥＥＰＲＯＭ５の記憶内容について示す。
【００３１】
同図において、記憶領域５ａには、送信依頼ジョブログ群が記憶される。
【００３２】
送信依頼ジョブログ群は、ＰＣ１０１ａ等の各送信依頼元クライアント装置からの送信依頼ジョブに係る文書データに付帯して通知される各種情報やジョブの処理に関連して付加される各種情報の集まりである。
【００３３】
具体的には、各ログを互いに識別するためのログ番号に対応する、送信依頼元から通知される分の情報である、ジョブエントリ日時、ジョブ識別ＩＤ、ユーザ識別ＩＤ、メールアドレスを記憶する。また、送信依頼ジョブの処理に関連して付加される情報として、送信結果情報、メール通知済みフラグを記憶する。送信結果情報及びメール通知済みフラグは、ログ生成時にはクリアされるが、送信結果が判明したりメール通知完了すると内容変更されて、処理過程の履歴を管理できるようにする。
【００３４】
各ログは、送信依頼があるごとにメモリ領域が確保されて生成されるものであり、メモリ容量不足などによりログのためのメモリ領域が確保できないと、送信依頼に係る文書データの指定された宛先への送信以前の送信依頼受付け段階で、依頼元のクライアント装置からみれば送信依頼が失敗したことになるが、従来は、そのことを依頼元のクライアント装置（のユーザ）が知ることはできなかった。
【００３５】
しかし、本発明を実施するための最良の形態に係る通信装置１では、図４に示す送信依頼受付処理を行うことで、依頼元のクライアント装置に対して、送信依頼を受け付けられない場合もその旨通知するようにする。
【００３６】
つまり、図４において、ＰＣ１０１ａ等の送信依頼元クライアント端末からの送信依頼の到来を待ち（判断Ｓ１０１のＮｏのループ）、送信依頼ジョブが到来すると（判断Ｓ１０１のＹｅｓ）、当該送信依頼ジョブに係るデータ（依頼データ）の受信を（処理Ｓ１０２）、依頼受付不可事態、つまり、送信依頼に係る文書データの転送を受けて指定された宛先に送信することを行う以前に、送信依頼自体を受け付けられない事態、具体的には、ログのためのメモリ領域の確保に失敗したりする事態の発生の有無を判断し（判断Ｓ１０３）、発生した場合には（判断Ｓ１０３のＹｅｓ）、依頼受付不可事態発生対応処理（処理Ｓ１０６）を行う。
【００３７】
発生しない場合には（判断Ｓ１０３のＮｏ）、全ての依頼データ（ジョブ識別ＩＤ、ユーザ識別ＩＤ、メールアドレスとそれに続く文書データ本体及び送信宛先情報）の受信が完了したかを判断し（判断Ｓ１０４）、未完の場合には処理Ｓ１０２に戻り、完了した場合には（判断Ｓ１０４のＹｅｓ）、送信依頼を処理する。つまり、指定された宛先へ送信依頼に係る文書データを送信する処理を行う（処理Ｓ１０５）。その処理は、文書データの送信結果を、通知された依頼元「メールアドレス」宛てに電子メールにより送信する従来相当の処理を含む。
【００３８】
処理Ｓ１０６の依頼受付不可事態発生対応処理の具体的な処理手順としては、図５または図６に示す手順を適用できる。
【００３９】
つまり、図５の手順においては、送信依頼元クライアント装置との「依頼データ受信」に係る通信を継続して依頼元クライアント装置側での「依頼データ送信」を表向きには正常に完了したことにした上で、通知された依頼元メールアドレス宛てに送信依頼の受付け自体を行えなかった旨を内容とする電子メールを送信する（処理Ｓ２０１）。
【００４０】
それにより、依頼元クライアント装置（のユーザ）は、自分の送信依頼が受付け段階で失敗に終わってしまったことを明確に認識でき、時間をおいて再依頼したりする等適切な対応をとることができる。送信依頼に係る文書データと比較して、それに先立ち付帯データとして通知されてくるその送信依頼元メールアドレス等のログ情報はデータ量が大きくないため、送信依頼元メールアドレスの通知を受けるところまでは「依頼データ受信」を必ず行うようにすることで、それ以後受付できない事態（文書データがサイズが大きくてこれ以上受信できない等）が発生しても確実にエラー通知できる。
【００４１】
また、図６の手順においては、依頼元クライアント装置との依頼データ受信（処理Ｓ１０２）に係る通信を強制中断する（処理Ｓ３０１）。
【００４２】
それにより、依頼元クライアント装置（のユーザ）は、自分の送信依頼に係る通信装置１との通信が途中で異常終了してしまったことをもって、自分のした送信依頼が受付け段階で失敗に終わってしまったことを明確に認識でき、時間をおいて再依頼したりする等適切な対応をとることができる。
【００４３】
なお、以上本発明を実施するための最良の形態について説明したが、本発明は上記のものに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【図面の簡単な説明】
【００４４】
【図１】本発明を実施するための最良の形態に係る通信装置を含むシステム構成について示す図である。
【図２】本発明を実施するための最良の形態に係る通信装置のブロック構成について示す図である。
【図３】本発明を実施するための最良の形態に係る通信装置のＥＥＰＲＯＭの記憶内容について示す図である。
【図４】本発明を実施するための最良の形態に係る通信装置における送信依頼受付処理手順について示すフローチャートである。
【図５】依頼受付不可事態発生対応処理の具体的な処理手順について示すフローチャートである。
【図６】依頼受付不可事態発生対応処理の具体的な処理手順について示すフローチャートである。
【符号の説明】
【００４５】
１  通信装置
【図１】
0004456023.tif 000002
【図２】
0004456023.tif 000003
【図３】
0004456023.tif 000004
【図４】
0004456023.tif 000005
【図５】
0004456023.tif 000006
【図６】
0004456023.tif 000007