JP5453772B2 - リクエスト処理装置 - Google Patents

Description

本発明は、リクエスト処理装置に関する。

従来、スキャナ及びプリンタを備えたデジタル複合機が知られている。このデジタル複合機では、スキャナが画像を取り込むスキャナ機能、プリンタが印刷を行う印刷機能、スキャナが読み取った画像をプリンタが印刷するコピー機能、電話回線を介して画像の送受信を行うファクシミリ機能などを備えている（特許文献１）。こうしたデジタル複合機は、ネットワークを介して接続されたコンピュータからの指令に基づいて動作する。
特開２００７−７２７７１号公報

ところで、特許文献１に記載されたデジタル複合機では、ネットワークに接続する通信インタフェースを１つしか有していないため、こうした通信インタフェースを複数有している場合には、リクエストの競合が発生する可能性がある。こうした競合については、適切に対応する必要がある。

本発明は、このような課題に鑑みなされたものであり、複数の通信手段に接続された外部機器からのリクエストが競合したとしても適切に対応することができるリクエスト処理装置を提供することを主目的とする。

本発明は、上述の目的を達成するために以下の手段を採った。

本発明のリクエスト処理装置は、
第１通信手段と、
第２通信手段と、
前記第１通信手段で受信されたリクエストを保存可能な第１バッファと、
前記第２通信手段で受信されたリクエストを保存可能な第２バッファと、
前記第１及び第２通信手段で受信されたリクエストに対する所定の処理を実行可能な共通のアプリケーションが格納されたアプリケーション格納手段と、
前記第１及び第２バッファのいずれかにリクエストが保存されているか否かを判定し、リクエストが保存されていたならば前記アプリケーション格納手段から前記共通のアプリケーションを呼び出して該共通のアプリケーションに前記リクエストに対する所定の処理を実行させると共に、該所定の処理が終了するまでは前記第１及び第２バッファのいずれかに次のリクエストが格納されたとしても放置する調停手段と、
を備えたものである。

このリクエスト処理装置では、第１及び第２バッファのいずれかにリクエストが保存されているか否かを判定し、リクエストが保存されていたならば共通のアプリケーションを呼び出して該共通のアプリケーションにそのリクエストに対する所定の処理を実行させると共に、該所定の処理が終了するまでは第１及び第２バッファのいずれかに次のリクエストが格納されたとしても放置する。つまり、第１通信手段に接続された外部機器からのリクエストと第２通信手段に接続された外部機器からのリクエストが競合したとしても、実行中の処理が終了するまでは次のリクエストに対する処理を実行しない。もちろん、実行中の処理が終了したならば、次のリクエストの処理を開始する。したがって、複数の通信手段に接続された外部機器からのリクエストが競合したとしても適切に対応することができる。

なお、「所定の処理」は、特に限定されるものではないが、例えば、ファクシミリ送信処理、印刷処理、電子データ保存処理などが挙げられる。

本発明のリクエスト処理装置において、前記第１通信手段は、所定のプロトコルに従って通信する手段であり、前記第２通信手段は、前記第１通信手段とは異なるプロトコルに従って通信する手段であってもよい。このように互いに異なる通信手段を複数備える場合には、プロトコルスタック（物理層からアプリケーション層まで）の特性が各々異なるため、プロトコルスタックの一部を共通化しようとする思想がなかったが、ここではアプリケーションを共通化したため、各プロトコルごとに個別にアプリケーションを開発する場合に比べてコストの低減化を図ることができる。例えば、前記第１通信手段は、ネットワークプロトコルに従って通信する手段であり、前記第２通信手段は、ＵＳＢプロトコルに従って通信する手段であってもよい。

本発明のリクエスト処理装置において、前記調停手段は、前記所定の処理が終了したあと、該所定の処理が前記第１及び第２バッファの一方のリクエストに対する処理だったときには、前記第１及び第２バッファの他方に保存されているリクエストを優先的に処理してもよい。こうすれば、各通信手段に接続された外部機器からのリクエストを平等に処理することができる。

本発明のリクエスト処理装置は、前記第１及び第２バッファとの間でデータの移動が可能であり前記共通のアプリケーションがアクセス可能な共有バッファを備え、前記調停手段は、前記第１及び第２バッファのいずれかにリクエストが保存されているか否かを判定し、リクエストが保存されていたならば該リクエストを前記共有バッファへ移動し、該共有バッファへのリクエストの移動をきっかけとして前記アプリケーション格納手段から前記共通のアプリケーションを呼び出して該共通のアプリケーションに前記リクエストに対する所定の処理を実行させてもよい。こうすれば、アプリケーションは第１及び第２通信手段のいずれで受信されたリクエストかを意識することなく処理を実行することができる。なお、共有バッファへのリクエストの移動をきっかけとしてアプリケーション格納手段から前記共通のアプリケーションを呼び出すには、例えば、共有バッファへリクエストが移動したか否かを絶えず監視し共有バッファへリクエストが移動したとき共通のアプリケーションを呼び出すようにしてもよいし、共有バッファへリクエストが移動すると事前に登録されているコールバック関数をコールして共通のアプリケーションを呼び出すようにしてもよい。

このような共有バッファを備えた本発明のリクエスト処理装置において、前記第１バッファは、前記第１通信手段へ送信すべきレスポンスも保存可能であり、前記第２バッファは、前記第２通信手段へ送信すべきレスポンスも保存可能であり、前記共通のアプリケーションは、前記所定の処理を実行したあとレスポンスを生成し前記リクエストに付された情報と共に前記共有バッファへ保存する機能を有し、前記調停手段は、前記第１及び第２バッファのいずれかにリクエストが保存されているか否かを判定し、前記第１及び第２通信手段のいずれのリクエストかを識別可能な識別情報を付して前記リクエストに付けて前記共有バッファへ移動し、該共有バッファへのリクエストの移動をきっかけとして前記アプリケーション格納手段から前記共通のアプリケーションを呼び出して該共通のアプリケーションに前記リクエストに対する所定の処理を実行させると共に、前記リクエストに対するレスポンスが前記識別情報を付されて前記共有バッファに保存されるまでは前記第１及び第２バッファのいずれかに次のリクエストが格納されたとしても放置し、前記共有バッファに前記レスポンスが前記識別情報を付されて前記共有バッファに保存されたあとは該識別情報に基づいてリクエストの送信元が前記第１及び第２通信手段のいずれであるかを判定し、該判定の結果に基づいて前記レスポンスを前記第１及び第２バッファのいずれかに保存してもよい。こうすれば、リクエストの送信元へ第１及び第２通信手段を介してレスポンスを返すことが可能となる。

次に、本発明を実施するための最良の形態を図面を用いて説明する。図１は、本発明を具現化した一実施形態であるマルチファンクションプリンタ（ＭＦＰ）１０の構成の概略を示す構成図である。

ＭＦＰ１０は、プリンタ機能、スキャナ機能、ファックス機能を有している。このＭＦＰ１０は、印刷を実行する印刷モジュール２０と、書類を読み取る読取モジュール２２と、ファックス情報を送受信するファックスモデム２４と、外部に設置されたコンピュータＰＣ１との間でネットワークを介してデータを送受信するネットワークインタフェース２６と、外部に設置されたコンピュータＰＣ２との間でＵＳＢケーブルを介してデータを送受信するＵＳＢインタフェース２８と、各種情報を表示したりユーザの指示を入力したりする操作パネル５０と、装置全体の制御を司るメインコントローラ６０とを備えている。なお、本明細書では、ネットワークを「ＮＷ」、インタフェースを「Ｉ／Ｆ」と表記することがある。

印刷モジュール２０は、メインコントローラ６０から印刷指令を受けると、その印刷指令の対象である印刷ジョブに基づいて、印刷ヘッドから記録紙Ｓへインクを吐出することにより印刷を実行する周知のインクジェット方式のカラープリンタ機構として構成されている。

読取モジュール２２は、メインコントローラ６０からの読取指令を受けると、ガラス台３６に載置された書類を画像データとして読み取る周知のフラットベッド型のフルカラースキャナ機構として構成されている。この読取モジュール２２は、書類に向かって発光したあとの反射光をレッド（Ｒ）、グリーン（Ｇ）、ブルー（Ｂ）の各色に分解して読取データとする周知のカラーイメージセンサを備えている。

ファックスモデム２４は、メインコントローラ６０からのファックス送信指令を受けると、ファックス送信する元のデータを送信先の通信方式に合わせた形式の送信データへと変換し、図示しない電話回線を介して接続された送信先の機器へその送信データを送信したり、電話回線を介して接続された機器から受信した受信データを画像データへと変換したりするよう構成されている。

ネットワークＩ／Ｆ２６は、ネットワークに接続された外部の機器（例えばコンピュータＰＣ１）との間でデータの送受信が可能なように構成されている。

ＵＳＢＩ／Ｆ２８は、ＵＳＢケーブルを介して接続されたＵＳＢホスト（例えばコンピュータＰＣ２）との間でデータの送受信が可能なように構成されている。この場合、ＭＦＰ１０はＵＳＢデバイスとして機能する。

操作パネル５０は、液晶ディスプレイである表示部５２と、コピーボタンや印刷ボタン、ファックス送信ボタン、スキャンボタン、電源ボタン、テンキーなどを含むボタン群５４とを備えている。この操作パネル５０は、各種情報を表示部５２に表示したりユーザの指示をボタン群５４の操作を介して入力したりする。

メインコントローラ６０は、ＣＰＵを中心とするマイクロプロセッサとして構成されており、各種処理プログラムや各種データ、各種テーブルなどを記憶したＲＯＭや一時的に印刷データ等を記憶するＲＡＭなどを備えている。このメインコントローラ６０は、印刷モジュール２０や読取モジュール２２、ファックスモデム２４、ネットワークＩ／Ｆ２６、ＵＳＢＩ／Ｆ２８からの各種動作信号や各種検出信号、各種データを入力したり、操作パネル５０のボタン群５４の操作に応じて発生する操作信号を入力したりする。また、印刷を実行するよう印刷モジュール２０に指令を出力したり、読取モジュール２２へ各種制御信号を出力したり、操作パネル５０の表示部５２に制御信号を出力したりする。

こうして構成されたＭＦＰ１０は、印刷処理やスキャン処理、コピー処理、ファックス送受信処理などの各種処理を実行する。印刷処理は、ネットワークＩ／Ｆ２６又はＵＳＢＩ／Ｆ２８を介して入力された印刷ジョブに基づいて印刷モジュール２０により記録紙Ｓへの印刷を行う処理である。スキャン処理は、ガラス台３６に載置された原稿の画像を読取モジュール２２により読み取る処理である。コピー処理は、読取モジュール２２により読み取った画像データに基づいて印刷モジュール２０により印刷を行う処理である。ファックス送受信処理は、読取モジュール２２により読み取った画像データ又はネットワークＩ／Ｆ２６かＵＳＢＩ／Ｆ２８を介して入力された画像データをファックスモデム２４及び図示しない電話回線を介して外部の機器へ送信したり、ファックスモデム２４及び電話回線を介して外部の機器から受信した画像データを印刷モジュール２０により印刷したりする処理である。

ここで、ＭＦＰ１０のファックス送信処理を実行する際の機能ブロックを図２を用いて説明する。図２は、ＭＦＰ１０のメインコントローラ６０を機能ブロックで表した説明図である。メインコントローラ６０は、ネットワーク通信の際にプロトコルを制御するＮＷドメイン６２と、ＵＳＢ通信及びネットワーク通信のいずれにおいても動作する共通ドメイン６８とを備えている。ＮＷドメイン６２は、コンピュータＰＣ１との間でネットワークを介してデータのやり取りを行うためのＮＷ通信ドライバ６４と、共通ドメイン６８との間でドメインコミュニケーションを介してデータのやり取りを行うためのＮＷドメイン間通信ドライバ６６とを備えている。このＮＷドメイン６２は、下層から上層に向かって、物理層（有線又は無線）、ＴＣＰ／ＩＰ、ＨＴＴＰ、ＭＩＭＥ、ＳＯＡＰヘッダ、ＷＳＡがこの順で積層されたプロトコルスタックにしたがってデータのやり取りを行う。なお、ＴＣＰ／ＩＰはTransmission Control Protocol/Internet Protocol、ＨＴＴＰはHyperText Transfer Protocol、ＭＩＭＥはMultipurpose Internet Mail Extension、ＳＯＡＰはSimple Object Access Protocol、ＷＳＡはWebservice-addressingの略である。共通ドメイン６８は、ＮＷドメイン６２との間でドメインコミュニケーションを介してデータのやり取りを行うＮＷドメイン間通信ドライバ７０と、コンピュータＰＣ２との間でＵＳＢケーブルを介してデータのやり取りを行うＵＳＢ通信ドライバ７４とを備えている。ＮＷドメイン間通信ドライバ７０は、ＮＷドメイン間通信バッファ７２を利用しながら、前述したプロトコルスタックにしたがってＮＷドメイン６２のＮＷドメイン間通信ドライバ７０とデータのやり取りを行う。ＮＷドメイン間通信バッファ７２には、受信用領域７２ａと送信用領域７２ｂとが設けられている。一方、ＵＳＢ通信ドライバ７４は、ＵＳＢ通信バッファ７６を利用しながら、双方向パラレル通信を定義しているＩＥＥＥ１２８４．４に準拠してＵＳＢの通信を行う。ＵＳＢ通信バッファ７６には、受信用領域７６ａと送信用領域７６ｂとが設けられている。また、共通ドメイン６８は、ネットワーク通信とＵＳＢ通信との調停を行うアービタ７８と、このアービタ７８により両通信バッファ７２，７６との間でデータの移動が行われる共有バッファ８０と、ＮＷ通信及びＵＳＢ通信のいずれによって取得したリクエストかに依存することなくファックス送信処理を実行するアプリケーション８２とを備えている。共有バッファ８０には、受信用領域８０ａと送信用領域８０ｂとが設けられている。また、アプリケーション８２は、メインコントローラ６０のＲＯＭに格納されている。

次に、ＭＦＰ１０の動作、特に、コンピュータＰＣ１，ＰＣ２からのファックス送信処理を実行するときのＭＦＰ１０の動作について説明する。コンピュータＰＣ１，ＰＣ２がＭＦＰ１０にファックス送信処理を実行させる場合、（１）プリンタ状態取得のリクエスト、（２）ファックス送信のリクエスト、（３）ファックスデータ送信のリクエスト、（４）ジョブステータス確認のリクエストを順次送信する。各リクエストは、直前に送信したリクエストに対するレスポンスを受信したあとに送信される。また、これらのリクエストは、ＳＯＡＰメッセージとして送信される。

ＳＯＡＰメッセージは、図３に示すように、通信プロトコルに依存するヘッダと、ＳＯＡＰヘッダ（任意の要素）及びＳＯＡＰボディ（必須の要素）を含むＳＯＡＰエンベロープとで構成されている。ＳＯＡＰヘッダには、ＳＯＡＰメッセージの宛先が記述され、ＳＯＡＰボディには、最終的なメッセージの受信者が処理を行う情報が記述される。コンピュータＰＣ１やＭＦＰ１０がネットワークを介して相手へ送信するＳＯＡＰメッセージを作成する場合、ＳＯＡＰボディを作成し、ＷＳＡを管理するためのオペレーションやメッセージを決定し、それらをＳＯＡＰヘッダとすることによりＳＯＡＰエンベロープを作成し、ＨＴＴＰに関するヘッダを追加する。こうすることにより、ネットワーク用のＳＯＡＰメッセージが完成する。一方、コンピュータＰＣ２やＭＦＰ１０がＵＳＢを介して相手へ送信するＳＯＡＰメッセージを作成する場合、ＳＯＡＰボディを作成し、ＳＯＡＰヘッダのないＳＯＡＰエンベロープを作成し、ＵＳＢに関するヘッダを追加する。こうすることにより、ＵＳＢ用のＳＯＡＰメッセージを作成する。ここで、ＳＯＡＰメッセージの一例として、ファックス状態取得のリクエスト（前出の（１）参照）のＳＯＡＰメッセージの一例を図４及び図５に示す。図４はネットワーク用、図５はＵＳＢ用である。図４及び図５から明らかなように、いずれのＳＯＡＰメッセージもＳＯＡＰボディの内容は同じである。なお、「ＦＡＸｏｕｔ」はファックス送信を意味する。

図２の共通ドメイン６８のＮＷドメイン間通信ドライバ７０は、コンピュータＰＣ１からネットワーク、ＮＷドメイン６２及びドメインコミュニケーションを介してＳＯＡＰメッセージを受信すると、ＳＯＡＰヘッダを解読したあと、ＮＷドメイン間通信バッファ７２の受信用領域７２ａにＳＯＡＰボディのみを保存する。また、共通ドメイン６８のＵＳＢ通信ドライバ７４は、コンピュータＰＣ２からＵＳＢを介してＳＯＡＰメッセージを受信すると、ＵＳＢ通信バッファ７６の受信用領域７６ａにＳＯＡＰボディのみを保存する。

共通ドメイン６８のアービタ７８は、ＭＦＰ１０の図示しないメインスイッチがオンされたあと、図６に示す調停ルーチンを実行する。この調停ルーチンが開始されると、アービタ７８は、監視対象のＩ／ＦがネットワークＩ／Ｆ２６かＵＳＢＩ／Ｆ２８かを判定する（ステップＳ１００）。初期設定では、ネットワークＩ／Ｆ２６が監視対象として設定される。続いて、監視対象のＩ／Ｆの通信バッファの受信用領域にリクエストが保存されているか否かを判定する（ステップＳ１１０）。具体的には、監視対象のＩ／ＦがネットワークＩ／Ｆ２６の場合には、ＮＷドメイン間通信バッファ７２の受信用領域７２ａにリクエストが保存されているか否かを判定し、監視対象のＩ／ＦがＵＳＢＩ／Ｆ２８の場合には、ＵＳＢ通信バッファ７６の受信用領域７２ａにリクエストが保存されているか否かを判定する。そして、ステップＳ１１０でリクエストが保存されていたならば、アービタ７８はそのリクエストにＩ／Ｆ情報を付けて共有バッファ８０の受信用領域８０ａへ移す（ステップＳ１２０）。ここで、Ｉ／Ｆ情報とは、監視対象となっているＩ／Ｆを表す情報である。

ここで、共有バッファ８０の受信用領域８０ａにリクエストが格納されると、コールバックが発生してファックス送信用のアプリケーション８２が共有バッファ８０の受信用領域８０ａのリクエストとＩ／Ｆ情報を取りに行く。リクエストを取得したアプリケーション８２は、そのリクエストの内容つまりＳＯＡＰボディの内容にしたがって処理を実行する。例えば、プリンタ状態取得のリクエスト（前出の（１）参照）の場合には、アプリケーション８２は、ＭＦＰ１０の状態（待機状態、印刷実行中、読取実行中、ファックス送信中、ファックス受信中）を把握し、その結果を表すレスポンスを作成する処理を実行する。このとき、アプリケーション８２は、そのリクエストがネットワークＩ／Ｆ２６を介して受信したものかＵＳＢＩ／Ｆ２８を介して受信したものかを意識せずに処理を実行する。つまり、アプリケーション８２は、リクエストと共にＩ／Ｆ情報も取得するが、そのＩ／Ｆ情報はそのまま保持しているだけである。その後、アプリケーション８２は、作成したレスポンスをＩ／Ｆ情報と合わせて共有バッファ８０の送信用領域８０ｂへ書き込む。

さて、アービタ７８は、ステップＳ１２０のあと、共有バッファ８０の送信用領域８０ｂにレスポンスが保存されたか否かを判定し（ステップＳ１３０）、レスポンスが保存されていなければそのまま待機する。一方、レスポンスが保存されていたならば、そのレスポンスに付いているＩ／Ｆ情報に基づいて返信先の通信バッファを認識し（ステップＳ１４０）、そのレスポンスを共有バッファ８０の送信用領域８０ｂから返信先の通信バッファの送信用領域へを移す（ステップＳ１５０）。具体的には、Ｉ／Ｆ情報がネットワークＩ／Ｆ２６を表す場合には、レスポンスをＮＷドメイン間通信バッファ７２の送信用領域７２ｂへ移し、Ｉ／Ｆ情報がＵＳＢＩ／Ｆ２８を表す場合には、レスポンスをＵＳＢ通信バッファ７６の送信用領域７２ｂへ移す。その後、監視対象のＩ／Ｆを切り替え（ステップＳ１６０）、再びステップＳ１１０に戻る。こうすることにより、一方のＩ／Ｆで受信したリクエストの処理が終了したら、次はもう一方のＩ／Ｆで受信したリクエストの処理を優先して実行することになる。なお、ステップＳ１１０で監視対象の通信バッファの受信用領域にリクエストがなかったならば、監視対象のＩ／Ｆを切り替え（ステップＳ１７０）、再びステップＳ１１０に戻る。このように、アービタ７８は、アプリケーション８２が一つのリクエストに対するレスポンスを返すまで次のリクエストを取りに行かない（つまり、リクエストに対する処理が終了するまでは次のリクエストが格納されたとしても放置する）ため、アプリケーション８２の処理におけるリクエスト−レスポンスのシリアライズが保持される。

そして、ＮＷドメイン間通信バッファ７２の送信用領域７２ｂに保存されたレスポンスは、ＮＷドメイン間通信ドライバ７０によりドメインコミュニケーション、ＮＷドメイン６２及びネットワークを介してコンピュータＰＣ１へ送信される。これにより、コンピュータＰＣ１は、ＭＦＰ１０へ送ったリクエストに対するレスポンスを受信する。一方、ＵＳＢ通信バッファ７６の送信用領域７６ｂに保存されたレスポンスは、ＵＳＢ通信ドライバ７４によりＵＳＢを介してコンピュータＰＣ２へ送信される。これにより、コンピュータＰＣ２は、ＭＦＰ１０へ送ったリクエストに対するレスポンスを受信する。

次に、ネットワークを介してコンピュータＰＣ１からリクエストを受信したときのアービタ７８及びアプリケーション８２の動作を図７を用いて説明する。図７は、ＭＦＰ１０の内部処理手順を表す説明図である。ここでは、ＮＷドメイン間通信バッファ７２の受信用領域７２ａにリクエストが保存されているものとして説明する。（ａ）アービタ７８は、ＮＷドメイン間通信バッファ７２の受信用領域７２ａにリクエストが保存されていることを見つけると、そのリクエストをＩ／Ｆ情報（ここではネットワークＩ／Ｆを表す情報）を付けて共有バッファ８０の受信用領域８０ａへ移す。（ｂ）共有バッファ８０の受信用領域８０ａにリクエストが格納されると、コールバックが発生する。（ｃ）コールバックによりアプリケーション８２が共有バッファ８０の受信用領域８０ａのリクエストとＩ／Ｆ情報を取りに行く。（ｄ）リクエストを取得したアプリケーション８２は、そのリクエストつまりＳＯＡＰボディをパースし、その内容にしたがって処理を実行する。（ｅ）アプリケーション８２は、レスポンスを作成し、そのレスポンスをＩ／Ｆ情報と合わせて共有バッファ８０の送信用領域８０ｂへ書き込む。（ｆ）アービタ７８は、共有バッファ８０の送信用領域８０ｂにレスポンスが保存されていることを見つけると、そのレスポンスに付いているＩ／Ｆ情報を基に返信先がネットワークＩ／Ｆであることを認識し、そのレスポンスを共有バッファ８０の送信用領域８０ｂからＮＷドメイン間通信バッファ７２の送信用領域７２ｂへ移す。その後、アービタ７８は、次のリクエストがＵＳＢ通信バッファ７６の受信用領域７６ａに保存されているか否かを見に行く。

ここで、本実施形態の構成要素と本発明の構成要素との対応関係を明らかにする。本実施形態のネットワークＩ／Ｆ２６が本発明の第１通信手段に相当し、ＵＳＢＩ／Ｆ２８が第２通信手段に相当し、ＮＷドメイン間通信バッファ７２が第１バッファに相当し、ＵＳＢ通信バッファ７６が第２バッファに相当し、アプリケーション８２を格納するＲＯＭがアプリケーション格納手段に相当し、アービタ７８が調停手段に相当する。

以上詳述した本実施形態のＭＦＰ２０によれば、ネットワークＩ／Ｆ２６に接続されたコンピュータＰＣ１からのリクエストとＵＳＢＩ／Ｆ２８に接続されたコンピュータＰＣ２からのリクエストが競合したとしても、アプリケーション８２は、一つのリクエストに対する処理を終了するまでは次のリクエストに対する処理を実行しない。したがって、ネットワークＩ／Ｆ２６に接続されたコンピュータＰＣ１やＵＳＢＩ／Ｆ２８に接続されたコンピュータＰＣ２からのリクエストが競合したとしても適切に対応することができる。

また、従来は、ネットワークＩ／ＦとＵＳＢＩ／Ｆといった互いに異なるインタフェースを複数備える場合には、プロトコルスタックの特性が各々異なるため、プロトコルスタックの一部を共通化しようとする思想がなかったが、本実施形態ではアプリケーション８２を共通化したため、各プロトコルごとに個別にアプリケーションを開発する場合に比べてコストの低減化を図ることができる。

更に、ネットワークＩ／Ｆ２６とＵＳＢＩ／Ｆ２８の一方で受信したリクエストに対する処理が終了したあとは、もう一方で受信したリクエストに対する処理を優先的に実行するため、各インタフェースに接続されたコンピュータＰＣ１，ＰＣ２からのリクエストを平等に処理することができる。

更にまた、インタフェースにかかわらず共通のＳＯＡＰボディを共有バッファ８０の受信用領域８０ａに移動するのをきっかけとしてアプリケーション８２がそのＳＯＡＰボディを解釈して処理を実行するため、アプリケーション８２はインタフェースの種類を意識することなく処理を実行することができる。

そしてまた、ＮＷドメイン間通信バッファ７２及びＵＳＢ通信バッファ７６はそれぞれ送信用領域７２ｂ、７６ｂを備えているため、リクエストの送信元へネットワーク又はＵＳＢを介してレスポンスを返すことが可能となる。

なお、本発明は上述した実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の態様で実施し得ることはいうまでもない。

例えば、上述した実施形態では、アプリケーション８２はファックス送信処理を実行するものとして説明したが、特にファックス送信処理に限定されるものではなく、例えば、印刷処理を実行するものであってもよいし、画像データ保存処理を実行するものであってもよい。

上述した実施形態では、共有バッファ８０の受信用領域８０ａにリクエストが保存されると、そのリクエストはコールバック形式によってアプリケーション８２に処理されるものとしたが、アプリケーション８２が受信用領域８０ａにリクエストが保存されたか否かを監視し、リクエストが保存されたならばそのリクエストを読み出して処理してもよい。

上述した実施形態では、ＭＦＰ１０にネットワークを介してコンピュータＰＣ１が接続され、ＵＳＢを介してコンピュータＰＣ２が接続されている場合を例示したが、２つの通信路は両方ともネットワークであってもよいし両方ともＵＳＢであってもよい。また、ネットワークとＵＳＢとが複数混在していてもよい。また、コンピュータＰＣ１，ＰＣ２の代わりにデジタルカメラや携帯電話などの電子機器が接続されていてもよい。

上述した実施形態では、ＭＦＰ１０を本発明のリクエスト処理装置として説明したが、複合機能を持たないプリンタやスキャナ、ファクシミリ装置などを本発明のリクエスト装置としてもよい。

マルチファンクションプリンタ（ＭＦＰ）１０の構成の概略を示す構成図。 ＭＦＰ１０のメインコントローラ６０を機能ブロックで表した説明図。 ＳＯＡＰメッセージの模式図。 ネットワーク用のＳＯＡＰメッセージの具体例を示す説明図。 ＵＳＢ用のＳＯＡＰメッセージの具体例を示す説明図。 調停ルーチンのフローチャート。 ＭＦＰ１０の内部処理手順を表す説明図。

符号の説明

１０ マルチファンクションプリンタ（ＭＦＰ）、２０ 印刷モジュール、２２ 読取モジュール、２４ ファックスモデム、２６ ネットワークインタフェース、２８ ＵＳＢインタフェース、３６ ガラス台、５０ 操作パネル、５２ 表示部、５４ ボタン群、６０ メインコントローラ、６２ ＮＷドメイン、６４ ＮＷ通信ドライバ、６６ ＮＷドメイン間通信ドライバ、６８ 共通ドメイン、７０ ＮＷドメイン間通信ドライバ、７２ ドメイン間通信バッファ、７２ａ 受信用領域、７２ｂ 送信用領域、７４ ＵＳＢ通信ドライバ、７６ ＵＳＢ通信バッファ、７６ａ 受信用領域、７６ｂ 送信用領域、７８ アービタ、８０ 共有バッファ、８０ａ 受信用領域、８０ｂ 送信用領域、８２ アプリケーション、ＰＣ１，ＰＣ２ コンピュータ、Ｓ 記録紙。

Claims (5)

1. 第１通信手段と、
   第２通信手段と、
   前記第１通信手段で受信されたリクエストを保存可能な第１バッファと、
   前記第２通信手段で受信されたリクエストを保存可能な第２バッファと、
   前記第１及び第２バッファとの間でデータの移動が可能な共有バッファと、
   前記第１及び第２通信手段で受信され、前記共有バッファに移動されたリクエストに対する所定の処理を実行可能な共通のアプリケーションが格納されたアプリケーション格納手段と、
   前記第１及び第２バッファのいずれかにリクエストが保存されているか否かを判定し、リクエストが保存されていたならば該リクエストを前記共有バッファへ移動し、前記アプリケーション格納手段から呼び出された前記共通のアプリケーションに該共有バッファへのリクエストの移動をきっかけとして前記リクエストに対する所定の処理を実行させると共に、該所定の処理が終了するまでは前記第１及び第２バッファのいずれかに次のリクエストが格納されたとしても放置する調停手段と、
   を備え、
   前記第１通信手段は、所定のプロトコルに従って通信する手段であり、
   前記第２通信手段は、前記第１通信手段とは異なるプロトコルに従って通信する手段である、
   リクエスト処理装置。
2. 前記第１通信手段は、ネットワークプロトコルに従って通信する手段であり、
   前記第２通信手段は、ＵＳＢプロトコルに従って通信する手段である、
   請求項１に記載のリクエスト処理装置。
3. 前記調停手段は、前記所定の処理が終了したあと、該所定の処理が前記第１及び第２バッファの一方のリクエストに対する処理だったときには、前記第１及び第２バッファの他方に保存されているリクエストを優先的に処理する、
   請求項１又は２に記載のリクエスト処理装置。
4. 前記第１バッファは、前記第１通信手段へ送信すべきレスポンスも保存可能であり、
   前記第２バッファは、前記第２通信手段へ送信すべきレスポンスも保存可能であり、
   前記共通のアプリケーションは、前記所定の処理を実行したあとレスポンスを生成し前記リクエストに付された情報と共に前記共有バッファへ保存する機能を有し、
   前記調停手段は、前記第１及び第２バッファのいずれかにリクエストが保存されているか否かを判定し、前記第１及び第２通信手段のいずれのリクエストかを識別可能な識別情報を付して前記リクエストに付けて前記共有バッファへ移動し、前記共有バッファに前記リクエストに対するレスポンスが前記識別情報を付されて前記共有バッファに保存されたあとは該識別情報に基づいて前記レスポンスを前記第１及び第２バッファのいずれかに保存する、
   請求項１〜３のいずれか１項に記載のリクエスト処理装置。
5. 前記調停手段は、前記第１及び第２バッファのいずれかに保存されているリクエストを前記共有バッファへ移動した後、前記リクエストに対するレスポンスが前記識別情報を付されて前記共有バッファに保存されるまでは前記第１及び第２バッファのいずれかに次のリクエストが格納されたとしても放置する
   請求項４に記載のリクエスト処理装置。

Images