JP2003177931A

JP2003177931A - 画像形成装置

Info

Publication number: JP2003177931A
Application number: JP2002244000A
Authority: JP
Inventors: Shigeya Senda; 滋也千田
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2001-08-27
Filing date: 2002-08-23
Publication date: 2003-06-27

Abstract

(57)【要約】【課題】可変性のあるアーキテクチャおよび多種多様な
機能を実現できる画像形成装置を得ることを目的とす
る。【解決手段】画像形成に係るユーザサービスおよびコン
トロールサービスの処理を行う一または複数のプログラ
ムとを有する画像形成装置であって、ユーザサービスお
よびコントロールサービスのそれぞれは、サーバプロセ
ス２０２またはクライアントプロセス２０１として動作
するプロセスであり、サーバプロセス２０２は、クライ
アントプロセス２０１に提供する一または複数のサービ
スを定義した関数を有しており、クライアントプロセス
２０１は、サーバプロセス２０２にサービスの提供を要
求する際に関数呼び出しを行うことにより上記課題を解
決する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、画像形成装置に
係り、特に複数のプロセスがプロセス間通信を行う画像
形成装置に関する。

【０００２】

【従来の技術】近年、プリンタ、コピー、ファクシミ
リ、スキャナなどの各装置の機能を１つの筐体内に収納
した画像形成装置（以下、「複合機」という。）が一般
的に知られている。

【０００３】この複合機は、１つの筐体内に表示部、印
刷部および撮像部などを設けるとともに、プリンタ、コ
ピーおよびファクシミリ装置にそれぞれ対応する３種類
のソフトウェアを設け、ソフトウェアの切り替えによっ
て、当該装置をプリンタ、コピー、スキャナまたはファ
クシミリ装置として動作させるものである。

【０００４】従来の複合機では、内部にプリンタ、コピ
ー、スキャナおよびファクシミリ装置に対応するソフト
ウェア（汎用ＯＳを含む）をそれぞれ別個に設ける構成
となっており、各ソフトウェアの開発に多大の時間を要
する。

【０００５】このため、出願人は、ハードウェア・イン
ターフェースをドライブするドライバと呼ばれるソフト
ウェア群と、メモリ／タイマなどの共通なハードウェア
資産を効率良く使用するためのマネージャ・ソフトウェ
ア群や各アプリケーションで共通に使用できるシステム
・ユーティリティ・ソフトウェア群と、これらのドライ
バ・ソフトウェア群，マネージャ・ソフトウェア群，ユ
ーティリティ・ソフトウェア群を使用するプリンタ／ス
キャナ／ＦＡＸ送信／ＦＡＸ受信などの実アプリケーシ
ョンとを備えた複合機（特開平９−５１３９８号公報，
特開平９−９１１０２号公報参照）を発明した。

【０００６】しかしながら、特開平９−５１３９８号公
報，特開平９−９１１０２号公報に記載されている複合
機は、ドライバ・ソフトウェア群，マネージャ・ソフト
ウェア群，ユーティリティ・ソフトウェア群がライブラ
リで構成されており、ハードウェア資源を実行制御する
主体となり得なかった。

【０００７】そこで、出願人は、表示部、印刷部および
撮像部などの画像形成処理で使用されるハードウェア資
源を有し、プリンタ、コピーまたはファクシミリなどの
各ユーザサービスにそれぞれ固有の処理を行うアプリケ
ーションを複数搭載し、これらのアプリケーションとハ
ードウェア資源との間に介在して、ユーザサービスを提
供する際に、アプリケーションの少なくとも２つが共通
的に必要とするハードウェア資源の管理、実行制御並び
に画像形成処理を行う各種コントロールサービスからな
るプラットホームを備えた複合機（特開２００２−８２
８０６号公報参照）を発明した。

【０００８】なお、ユーザサービスとはユーザに提供す
る画像形成に係るサービスをいう。また、コントロール
サービスとはアプリケーションに画像形成に係るハード
ウェア資源を提供するサービスをいう。

【０００９】この複合機によれば、アプリケーションの
少なくとも２つが共通的に必要とするハードウェア資源
の管理、実行制御並びに画像形成処理を行うプラットホ
ームを備えた構成とすることによって、ソフトウェア開
発の効率化を図るとともに、装置全体としての生産性を
向上させることが可能となる。

【００１０】

【発明が解決しようとする課題】このような複合機で
は、アプリケーションの少なくとも２つが共通的に必要
とするサービスを提供するコントロールサービスを有す
る構成となっているため、機能変更、機能追加、または
将来的なハードウェア資源の追加、変更などに柔軟に対
応すべく、アプリケーションごとあるいはコントロール
サービスごとの追加、変更を容易に行えることが望まれ
る。また、複合サービスを提供する際に、各アプリケー
ションと各コントロールサービス間、あるいは各コント
ロールサービス間でサービスやデータの授受を円滑に行
うことが必要となってくる。

【００１１】すなわち、複合機は、プリンタ、コピー、
ファクシミリ、スキャナなど多種の機能を備えたもので
あるが、その一部の機能に故障あるいは仕様変更などが
生じた場合に、全てのアプリケーションまたは全てのコ
ントロールサービスのモジュールを修正しなければなら
ないと、作業の労力が過大となる。

【００１２】また、将来的に、複合機に新たな機能を追
加する場合でも一部の機能の追加のために全てのコント
ロールサービスや全てのアプリケーションのモジュール
変更が必要となると、プログラム開発の労力が過大とな
ってしまう。このため、複合機上で動作する各アプリケ
ーションやコントロールサービスのモジュールは互いに
サービスやデータの送受信を実現としながらも、モジュ
ール間の独立性を維持していることが必要となってく
る。

【００１３】すなわち、アプリケーションや各コントロ
ールサービスごとに独立性がないと、必要なアプリケー
ションや必要なコントロールサービスのみを提供するこ
とが困難となり、機能変更や機能追加などに柔軟に対応
できるような複合機の構成に可変性を持たせることがで
きない。

【００１４】また、各アプリケーションや各コントロー
ルサービスごとに独立性がないと、アプリケーションや
コントロールサービスごとの設計および構築が困難にな
り、多種多様な機能を提供することができない。

【００１５】この発明は上記に鑑みてなされたもので、
可変性のあるアーキテクチャおよび多種多様な機能を実
現できる画像形成装置を得ることを目的とする。

【００１６】

【課題を解決するための手段】上記目的を達成するた
め、請求項１にかかる発明は、画像形成処理で使用され
るハードウェア資源と、画像形成に係るユーザサービス
およびコントロールサービスの処理を行う一または複数
のプログラムとを有する画像形成装置であって、前記ユ
ーザサービスおよびコントロールサービスのそれぞれ
は、サーバプロセスまたはクライアントプロセスとして
動作するプロセスであり、前記サーバプロセスは、前記
クライアントプロセスに提供する一または複数のサービ
スを定義した関数を有しており、前記クライアントプロ
セスは、前記サーバプロセスにサービスの提供を要求す
る際に関数呼び出しを行うことを特徴とする。

【００１７】この請求項１にかかる発明によれば、一ま
たは複数のユーザサービスおよびコントロールサービス
の相互間で、関数呼び出しによるプロセス間通信を実現
することができる。

【００１８】このため、ユーザサービスおよびコントロ
ールサービスに共通するサービスを提供するコントロー
ルサービスを有する画像形成装置において、各ユーザサ
ービスおよび各コントロールサービスの間の独立性を維
持しながら互いにサービスやデータの授受をプロセス間
通信によって実現することができ、機能的に多様性のあ
る画像形成装置を提供することができる。

【００１９】また、ユーザサービスやコントロールサー
ビスの一部のモジュールにのみ変更がある場合や、必要
に応じてユーザサービスまたはコントロールサービスを
追加する場合でも、サーバプロセスとなるモジュール側
で関数を実装し、クライアントプロセスとなるモジュー
ル側で関数呼び出しを行うというインタフェースを確保
しておけば、サービスやデータの授受が可能となる。

【００２０】このため、ユーザサービスやコントロール
サービスの追加または変更を容易に実現することがで
き、可変性を持った画像形成装置を構成することができ
る。

【００２１】さらに、ユーザサービスおよびコントロー
ルサービスのそれぞれは、サーバプロセスまたはクライ
アントプロセスとして動作するプロセスであるため、複
数のユーザサービスや複数のコントロールサービスをそ
れぞれ別個のプロセスとして動作させることにより、他
のユーザサービスまたは他のコントロールサービスのプ
ロセスが停止した場合でも動作中の他のプロセスは影響
を受けない。

【００２２】このため、一部のプロセスが停止した場合
でも他の複合サービスを続行して提供することができ、
すべての複合サービスが提供不可能になることを防止す
ることができる。

【００２３】ここで、「サーバプロセス」とは、他のプ
ロセスからの要求により、要求されたサービスを提供す
るプロセスをいい、サービスを提供する限り、ユーザサ
ービスおよびコントロールサービスのいずれもサーバプ
ロセスとして動作することができる。

【００２４】また、「クライアントプロセス」とは、こ
のようなサーバプロセスからサービスの提供を受けるプ
ロセスをいい、サービスの提供を受ける限り、ユーザサ
ービスおよびコントロールサービスのいずれもクライア
ントプロセスとして動作することができる。

【００２５】「関数」とは、サーバプロセスに対するサ
ービスの処理要求やサーバプロセスによる所定の設定値
の設定要求に対し、サーバプロセス側で要求された処理
や設定を実行するものである。

【００２６】また、請求項２にかかる発明は、前記コン
トロールサービスは、前記ユーザサービスをクライアン
トプロセスとしたサーバプロセスとして動作して、前記
ユーザサービスの少なくとも２つが共通的に必要とする
サービスを定義した関数を有し、前記ユーザサービス
は、前記コントロールサービスにサービスの提供を要求
する際に関数呼び出しを行うことを特徴とする。

【００２７】この請求項２にかかる発明によれば、ユー
ザサービスに対するコントロールサービスからのサービ
スの提供を関数呼び出しによるプロセス間通信によって
実現することができ、アプリケーションを用いた可変性
および多様性のある画像形成装置の提供が可能となる。

【００２８】また、請求項３にかかる発明は、前記コン
トロールサービスは、他のコントロールサービスをクラ
イアントプロセスとしたサーバプロセスとして動作し
て、前記他のコントロールサービスの少なくとも２つが
共通的に必要とするサービスを定義した関数を有してお
り、前記他のコントロールサービスは、前記コントロー
ルサービスにサービスの提供を要求する際に関数呼び出
しを行うことを特徴とする。

【００２９】この請求項３にかかる発明によれば、コン
トロールサービス間のサービスの提供を関数呼び出しに
よるプロセス間通信によって実現することができ、コン
トロールサービスを用いた可変性および多様性のある画
像形成装置の提供が可能となる。

【００３０】また、請求項４にかかる発明は、前記コン
トロールサービスは、前記サーバプロセスとして動作す
るとともに前記クライアントプロセスとして動作するこ
とを特徴とする。

【００３１】この請求項４にかかる発明によれば、ユー
ザサービスとコントロールサービス間の双方向のサービ
スの提供、およびコントロールサービス間の双方向のサ
ービスの提供を関数呼び出しによるプロセス間通信によ
って実現することができ、より可変性および多様性のあ
る画像形成装置の提供が可能となる。

【００３２】また、請求項５にかかる発明は、前記ユー
ザサービスおよび前記コントロールサービスの各プロセ
スは、一または複数のスレッドを含むことを特徴とす
る。

【００３３】この請求項５にかかる発明によれば、独立
して動作する必要のない機能を同一プロセス内の複数ス
レッドに割り当てて並列に実行させることが可能とな
る。また、スレッド単位での実行制御の切り替えは、主
記憶空間を共有し主記憶空間の切り替えが不要で、カウ
ンタやレジスタの切り替えというオーバヘッドの少ない
切り替えのみで実現できるため、別個の主記憶空間を使
用して主記憶空間の切り替えが必要なプロセス単位の切
り替えに比べて、切り替え時のオーバヘッドが少ない。

【００３４】このため、ユーザサービスおよびコントロ
ールサービスの各プロセス内に一または複数のスレッド
を起動して並列実行を行うことにより、コピー、プリン
タなどの複合サービスの並列実行時の処理速度を向上さ
せることができる。

【００３５】また、請求項６にかかる発明は、前記ユー
ザサービスおよび前記コントロールサービスは、前記ク
ライアントプロセスとして動作するときに、前記サーバ
プロセスへの関数呼び出しに対する関数戻り値の受信を
監視し、受信した関数戻り値を前記関数呼び出しを行っ
たスレッドに受け渡すクライアント監視手段を備えたこ
とを特徴とする。

【００３６】この請求項６にかかる発明によれば、クラ
イアントプロセスから関数呼び出しを行ったスレッド
は、クライアント監視手段によって関数戻り値が受け渡
されるまで、次の命令実行を待機することによりプロセ
ス内の他のスレッドが実行権を得ることができ、並列動
作を行うことができる。

【００３７】このため、プロセス内に複数のスレッドを
起動してプロセス間通信を行いながら、関数呼び出しに
伴う戻り値待ちによってプロセスの他のスレッドが動作
でき並列性を保証する。

【００３８】また、請求項７にかかる発明は、前記クラ
イアント監視手段は、スレッドで実現されることを特徴
とする。

【００３９】この請求項７にかかる発明によれば、クラ
イアント監視手段の機能を一または複数のスレッドで実
現することができる。

【００４０】また、請求項８にかかる発明は、前記クラ
イアント監視手段は、関数の呼び出し後に関数戻り値待
ち状態のスレッドの識別子を一時的に格納する関数戻り
待ちキューをさらに備え、前記サーバプロセスから前記
関数戻り値を受信したときに、受信した関数戻り値を、
前記関数戻り待ちキューに格納された識別子の前記スレ
ッドに送信することを特徴とする。

【００４１】この請求項８にかかる発明によれば、プロ
セス内部の複数スレッドが単一サーバに対して関数呼び
出しを行い、独立して関数の戻りを待つことができ、関
数戻り値のスレッドへの送信を確実に行い、スレッドの
並列動作をより確実かつ容易に実現することができる。

【００４２】また、請求項９にかかる発明は、前記サー
バプロセスおよび前記クライアントプロセスは、さらに
イベントまたは通知に関するメッセージの送信，受信ま
たは送受信の何れかを行うことを特徴とする。

【００４３】この請求項９にかかる発明において、「メ
ッセージ」とは、サーバプロセスとクライアントプロセ
スとの間でイベントや通知を行う際に送信するものであ
り、関数のように戻り値を必要としないものをいう。

【００４４】この請求項９にかかる発明によれば、画像
形成装置におけるプロセス間通信を関数呼び出しの他メ
ッセージによっても可能とし、機能的に多様性のある画
像形成装置を提供することができる。また、スレッド間
で同期をとる必要のないプロセス間通信をメッセージに
よって実現することにより、画像形成装置におけるプロ
セス間通信の処理速度を向上させることができる。

【００４５】また、請求項１０にかかる発明は、前記ク
ライアント監視手段は、さらにサーバプロセスからのメ
ッセージの受信を監視するものであることを特徴とす
る。

【００４６】この請求項１０にかかる発明によれば、サ
ーバプロセスから送信されたメッセージをクライアント
監視手段で一括して受信することができ、画像形成装置
におけるプロセス間通信の処理効率を向上させることが
できる。

【００４７】また、請求項１１にかかる発明は、前記ク
ライアント監視手段は、受信したメッセージに基づいた
処理を実行するメッセージハンドラをさらに備えたこと
を特徴とする。

【００４８】この請求項１１にかかる発明によれば、受
信メッセージを対応するメッセージハンドラに委ねるこ
とができ、メッセージを利用したプロセス間通信の処理
効率の向上を図ることができる。

【００４９】本発明における「メッセージハンドラ」
は、受信したメッセージをスレッドに受け渡すものであ
ればよく、メッセージごとに別個のメッセージハンドラ
を設ける他、受信可能なすべてのメッセージの受け渡し
処理を行う単一モジュールとすることもできる。

【００５０】また、請求項１２にかかる発明は、前記サ
ーバプロセスは、前記クライアントプロセスからの関数
呼び出しを監視するサーバ監視手段を備えたことを特徴
とする。

【００５１】この請求項１２にかかる発明によれば、ク
ライアントプロセスからの関数呼び出しをサーバ監視手
段により一括して受信して、画像形成装置におけるプロ
セス間通信の処理効率を向上させることができる。

【００５２】また、請求項１３にかかる発明は、前記サ
ーバ監視手段は、複数のクライアントプロセスからの関
数呼び出しを監視することを特徴とする。

【００５３】この請求項１３にかかる発明によれば、サ
ーバプロセスは複数のクライアントプロセスに対するサ
ーバプロセスとして動作することが可能となり、複数の
アプリケーション、複数のコントロールサービスをクラ
イアントプロセスとして種々の機能を単一のサーバプロ
セスで提供することができ、機能的に多種多様な画像形
成装置を提供することができる。

【００５４】また、請求項１４にかかる発明は、前記サ
ーバ監視手段は、前記クライアントプロセスから関数呼
び出しを受信したときに、呼び出された関数に対応した
処理を実行する関数ハンドラを備えたことを特徴とす
る。

【００５５】この請求項１４にかかる発明によれば、サ
ーバプロセスは提供するサービスを関数ハンドラを利用
したプロセス間通信によってクライアントプロセスに提
供することができ、機能的に多様性のある画像形成装置
を提供することができる。

【００５６】また、関数に対応した処理を関数ハンドラ
に委ねることができ、サーバプロセスとして提供する機
能を実行する関数ハンドラを予め設けておけばクライア
ントプロセスにサービスを提供することができる。この
ため、提供する機能に追加や変更が生じた場合でも、関
数ハンドラを追加、変更するだけでサーバ監視手段の機
能の大きな変更は必要なくなるので、容易に可変性のあ
る画像形成装置を提供することができる。

【００５７】本発明における「関数ハンドラ」は、クラ
イアントプロセスから呼び出した関数に対応した処理を
実行するものであればよく、関数ハンドラをサーバプロ
セス側で提供する関数のすべてを関数ごとに実行する単
一モジュールとする他、関数ごとに別個の関数ハンドラ
を設ける構成とすることができる。この場合には、より
画像形成装置の可変性を高めることが可能である。

【００５８】また、請求項１５にかかる発明は、前記サ
ーバ監視手段は、さらにクライアントプロセスからのメ
ッセージの受信を監視することを特徴とする。

【００５９】この請求項１５にかかる発明によれば、ク
ライアントプロセスから送信されたメッセージをサーバ
監視手段で一括して受信することができ、画像形成装置
におけるプロセス間通信の処理効率を向上させることが
できる。

【００６０】また、請求項１６にかかる発明は、前記サ
ーバ監視手段は、受信したメッセージに基づいた処理を
実行するメッセージハンドラをさらに備えたことを特徴
とする。

【００６１】この請求項１６にかかる発明によれば、受
信メッセージに関する処理をメッセージハンドラに委ね
ることができ、メッセージを利用したプロセス間通信の
処理効率の向上を図ることができる。

【００６２】本発明における「メッセージハンドラ」
も、受信したメッセージをスレッドに受け渡すものであ
ればよく、メッセージごとに別個のメッセージハンドラ
を設ける他、受信可能なすべてのメッセージの受け渡し
処理を行う単一モジュールとすることもできる。

【００６３】また、本発明のつぎの態様は、上記発明の
いずれか一つに記載の画像形成装置において、前記コン
トロールサービスは、ジョブまたはエンジンの制御を行
うエンジンコントロールサービスを有し、前記エンジン
コントロールサービスは、クライアントプロセスから関
数呼び出しを受信したときに、ジョブ制御処理またはエ
ンジン制御処理を実行する関数ハンドラを備えたことを
特徴とする。

【００６４】この発明によれば、エンジンコントロール
サービスがクライアントプロセスから関数呼び出しを受
信したときに、ジョブ制御処理またはエンジン制御処理
を実行する関数ハンドラを備えたことで、エンジンコン
トロールサービスが提供するジョブ制御処理またはエン
ジン制御処理に関するサービスを関数ハンドラを利用し
たプロセス間通信によってクライアントプロセスに提供
することができ、機能的に多様性のある画像形成装置を
提供することができる。

【００６５】また、エンジンコントロールサービスがサ
ーバプロセスとして提供するジョブ制御またはエンジン
制御の機能に追加や変更が生じた場合でも、関数ハンド
ラを追加、変更するだけでエンジンコントロールサービ
ス側の大きな変更は必要なくなり、容易に可変性のある
画像形成装置を提供することができる。

【００６６】また、本発明のつぎの態様は、上記発明に
記載の画像形成装置において、前記エンジンコントロー
ルサービスは、さらに、ジョブ制御またはエンジン制御
に関するメッセージを送信することを特徴とする。

【００６７】この発明によれば、エンジンコントロール
サービスがさらに、ジョブ制御またはエンジン制御に関
するメッセージを送信することで、関数の他ジョブ制御
またはエンジン制御に関するイベントまたは通知など戻
り値を必要としない処理をメッセージによって実現し、
機能的に多様性のある画像形成装置を提供することがで
きる。

【００６８】また、本発明のつぎの態様は、上記発明の
いずれか一つに記載の画像形成装置において、前記コン
トロールサービスは、メモリまたはハードディスク装置
の制御を行うメモリコントロールサービスを有し、前記
メモリコントロールサービスは、クライアントプロセス
からの関数呼び出しを受信したときに、メモリ制御処理
またはハードディスク制御処理を実行する関数ハンドラ
を備えたことを特徴とする。

【００６９】この発明によれば、メモリコントロールサ
ービスがクライアントプロセスから関数呼び出しを受信
したときに、メモリ制御処理またはハードディスク制御
処理を実行する関数ハンドラを備えたことで、メモリコ
ントロールサービスが提供するメモリ制御処理またはハ
ードディスク制御処理に関するサービスを関数ハンドラ
を利用したプロセス間通信によってクライアントプロセ
スに提供することができ、機能的に多様性のある画像形
成装置を提供することができる。

【００７０】また、メモリコントロールサービスがサー
バプロセスとして提供するメモリ制御またはハードディ
スク制御の機能に追加や変更が生じた場合でも、関数ハ
ンドラを追加、変更するだけでメモリコントロールサー
ビス側の機能の大きな変更は必要なくなり、容易に可変
性のある画像形成装置を提供することができる。

【００７１】また、本発明のつぎの態様は、上記発明に
記載の画像形成装置において、前記メモリコントロール
サービスは、さらに、メモリ制御またはハードディスク
制御に関するメッセージを送信することを特徴とする。

【００７２】この発明によれば、メモリコントロールサ
ービスがさらに、メモリ制御またはハードディスク制御
に関するメッセージを送信することで、関数の他メモリ
制御またはハードディスク制御に関するイベントまたは
通知など戻り値を必要としない処理をメッセージによっ
て実現し、機能的に多様性のある画像形成装置を提供す
ることができる。

【００７３】また、本発明のつぎの態様は、上記発明の
いずれか一つに記載の画像形成装置において、前記コン
トロールサービスは、ファックス通信の制御を行うファ
ックスコントロールサービスを有し、前記ファックスコ
ントロールサービスは、クライアントプロセスからの関
数呼び出しを受信したときに、ファックス通信制御処理
を実行する関数ハンドラを備えたことを特徴とする。

【００７４】この発明によれば、ファックスコントロー
ルサービスがクライアントプロセスからの関数呼び出し
を受信したときに、ファックス通信制御処理を実行する
関数ハンドラを備えたことで、ファックスコントロール
サービスが提供するファックス通信制御処理に関するサ
ービスを関数ハンドラを利用したプロセス間通信によっ
てクライアントプロセスに提供することができ、機能的
に多様性のある画像形成装置を提供することができる。

【００７５】また、ファックスコントロールサービスが
サーバプロセスとして提供するファックス通信制御の機
能に追加や変更が生じた場合でも、関数ハンドラを追
加、変更するだけでファックスコントロールサービス側
の機能の大きな変更は必要なくなり、容易に可変性のあ
る画像形成装置を提供することができる。

【００７６】また、本発明のつぎの態様は、上記発明の
画像形成装置において、前記ファックスコントロールサ
ービスは、さらにファックス通信制御に関するメッセー
ジを送信することを特徴とする。

【００７７】この発明によれば、ファックスコントロー
ルサービスがさらに、ファックス通信制御に関するメッ
セージを送信することで、関数の他ファックス通信制御
に関するイベントまたは通知など戻り値を必要としない
処理をメッセージによって実現し、機能的に多様性のあ
る画像形成装置を提供することができる。

【００７８】また、請求項１７にかかる発明は、画像形
成処理で使用されるハードウェア資源と、画像形成に係
るユーザサービスおよびコントロールサービスの処理を
行う一または複数のプログラムとを有する画像形成装置
であって、前記コントロールサービスは、ネットワーク
に接続された他の画像形成装置で動作するクライアント
プロセスに対するサーバプロセスとして動作し、サーバ
プロセスとして前記他の画像形成装置のクライアントプ
ロセスに提供する一または複数のサービスを定義した関
数を有していることを特徴とする。

【００７９】この請求項１７にかかる発明によれば、コ
ントロールサービスはネットワーク上の他の画像形成装
置で動作するプロセスをクライアントとしたサーバプロ
セスとして関数呼び出しを利用したプロセス間通信を実
現することができ、同一の画像形成装置内のプロセスだ
けでなく、ネットワーク上の画像形成装置に対してもサ
ービスの提供が可能となり、多種多様な機能を実現する
ことができる。

【００８０】この請求項１７にかかる発明において、サ
ーバプロセスとなるコントロールサービスが動作してい
る画像形成装置は、ユーザサービスおよびコントロール
サービスを搭載可能であればその構成は限定されるもの
ではない。すなわち、当該画像形成装置は、サービスを
提供するコントロールサービスが１つでも搭載されてい
れば良く、ユーザサービスが未搭載の画像形成装置や、
コントロールサービスが１個のみ搭載されている画像形
成装置も含まれる。

【００８１】また、請求項１８にかかる発明は、前記コ
ントロールサービスの各プロセスは、前記他の画像形成
装置のクライアントプロセスに提供するサービスを実行
する一または複数のスレッドを備えたことを特徴とす
る。

【００８２】この請求項１８にかかる発明によれば、ネ
ットワーク上の他の画像形成装置で動作するアプリケー
ションなどのユーザサービスのプロセスに提供するサー
ビスを並列実行させることができる。

【００８３】このため、例えば、ネットワーク上の異な
る複数の画像形成装置のクライアントプロセスから同時
に関数呼び出しを受けた場合でも、実行制御の切り替え
の速いスレッドでサービスを並列実行させるので、ネッ
トワーク上の複数の画像形成装置へのサービスの提供を
迅速に行うことが可能となる。

【００８４】また、請求項１９にかかる発明は、前記コ
ントロールサービスは、前記他の画像形成装置のクライ
アントプロセスからの関数呼び出しを監視するサーバ監
視手段を備えたことを特徴とする。

【００８５】この請求項１９にかかる発明によれば、他
の画像形成装置のクライアントプロセスからの関数呼び
出しをサーバ監視手段により一括して受信して、ネット
ワーク上の画像形成装置とのプロセス間通信の処理効率
を向上させることができる。

【００８６】また、請求項２０にかかる発明は、前記サ
ーバ監視手段は、さらに前記他の画像形成装置のクライ
アントプロセスからのメッセージの受信を監視すること
を特徴とする。

【００８７】この請求項２０にかかる発明によれば、コ
ントロールサービスはネットワークに接続された他の画
像形成装置で動作するプロセスからのメッセージの一括
した受信が可能となり、ネットワーク上の画像形成装置
とのプロセス間通信の処理効率を向上させることができ
る。

【００８８】また、請求項２１にかかる発明は、前記コ
ントロールサービスは、さらに前記他の画像形成装置の
クライアントプロセスに対しメッセージを送信すること
を特徴とする。

【００８９】この請求項２１にかかる発明によれば、コ
ントロールサービスはネットワークに接続された他の画
像形成装置で動作するプロセスをクライアントとしたサ
ーバプロセスとして関数の他メッセージを利用したプロ
セス間通信を行うことができ、ネットワーク上の画像形
成装置に対して多種多様な機能を実現することができ
る。

【００９０】また、請求項２２にかかる発明は、前記コ
ントロールサービスは、前記他の画像形成装置で動作す
るユーザサービスをクライアントプロセスとしたサーバ
プロセスとして動作することを特徴とする。

【００９１】この請求項２２にかかる発明によれば、ネ
ットワーク上の他の画像形成装置で動作するアプリケー
ションのプロセスに対してコントロールサービスの機能
を提供することができる。

【００９２】また、コントロールサービスがネットワー
ク上の画像形成装置内に存在しない場合や使用できない
場合でも、プロセス間通信によって、当該ネットワーク
上の画像形成装置にコントロールサービスの機能を提供
できるので、ネットワークを利用した複数の画像形成装
置間でコントロールサービスの機能の共有化を実現する
ことが可能となる。

【００９３】また、請求項２３にかかる発明は、前記コ
ントロールサービスは、前記他の画像形成装置で動作す
るコントロールサービスをクライアントプロセスとした
サーバプロセスとして動作することを特徴とする。

【００９４】この請求項２３にかかる発明によれば、ネ
ットワーク上の他の画像形成装置で動作するコントロー
ルサービスに対してコントロールサービスの機能を提供
することができる。

【００９５】また、あるコントロールサービスがネット
ワーク上の画像形成装置内に存在しない場合や使用でき
ない場合でも、プロセス間通信によって、当該ネットワ
ーク上の画像形成装置にコントロールサービスの機能を
提供できるので、ネットワークを利用した複数の画像形
成装置間でコントロールサービスの機能の共有化を実現
することが可能となる。

【００９６】また、請求項２４にかかる発明は、前記ユ
ーザサービスは、前記他の画像形成装置で動作するコン
トロールサービスをサーバプロセスとしたクライアント
プロセスとして動作することを特徴とする。

【００９７】この請求項２４にかかる発明によれば、ユ
ーザサービスはネットワーク上のコントロールサービス
からサービスの提供を受けることができる。また、ネッ
トワーク上の画像形成装置でユーザサービスが使用でき
ない状況にあっても、プロセス間通信によって、ネット
ワーク上の画像形成装置のコントロールサービスからの
サービスの提供を受けることができるので、ネットワー
クを利用した複数の画像形成装置間でコントロールサー
ビスの機能の共有化を実現することが可能となる。

【００９８】また、請求項２５にかかる発明は、前記コ
ントロールサービスは、前記他の画像形成装置で動作す
るコントロールサービスをサーバプロセスとしたクライ
アントプロセスとして動作することを特徴とする。

【００９９】この請求項２５にかかる発明によれば、コ
ントロールサービスはネットワーク上のコントロールサ
ービスからサービスの提供を受けることができる。ま
た、ネットワーク上の画像形成装置でコントロールサー
ビスが使用できない場合でも、プロセス間通信によっ
て、ネットワーク上の画像形成装置のコントロールサー
ビスからのサービスの提供を受けることができるので、
ネットワークを利用した複数の画像形成装置間でコント
ロールサービスの機能の共有化を実現することが可能と
なる。

【０１００】

【発明の実施の形態】以下に添付図面を参照して、この
発明にかかる画像形成装置の好適な実施の形態を詳細に
説明する。（実施の形態１）図１は、この発明の実施の形態１であ
る画像形成装置（以下、「複合機」という）の構成を示
すブロック図である。図１に示すように、複合機は、白
黒ラインプリンタ（B&W LP）１０１と、カラーラインプ
リンタ（Color LP）１０２と、スキャナ１０３と、ファ
クシミリ１０４などのハードウェアリソースなどを有す
るとともに、プラットホーム１２０とアプリケーション
１３０とから構成されるソフトウェア群１１０を備えて
いる。

【０１０１】プラットホーム１２０は、アプリケーショ
ン１３０からの処理要求を解釈してハードウェア資源の
獲得要求を発生させるコントロールサービスと、一また
は複数のハードウェア資源の管理を行い、コントロール
サービスからの獲得要求を調停するシステムリソースマ
ネージャ（ＳＲＭ）１２３と、汎用ＯＳ１２１とを有す
る。

【０１０２】コントロールサービスは、複数のサービス
モジュールから形成され、ＳＣＳ（システムコントロー
ルサービス）１２２と、ＥＣＳ（エンジンコントロール
サービス）１２４と、ＭＣＳ（メモリコントロールサー
ビス）１２５と、ＯＣＳ（オペレーションパネルコント
ロールサービス）１２６と、ＦＣＳ（ファックスコント
ロールサービス）１２７と、ＮＣＳ（ネットワークコン
トロールサービス）１２８とから構成される。なお、こ
のプラットホーム１２０は、あらかじめ定義された関数
により前記アプリケーション１３０から処理要求を受信
可能とするアプリケーションプログラムインタフェース
（ＡＰＩ）を有する。

【０１０３】汎用ＯＳ１２１は、ＵＮＩＸ（登録商標）
などの汎用オペレーティングシステムであり、プラット
ホーム１２０並びにアプリケーション１３０の各ソフト
ウェアをそれぞれプロセスとして並列実行する。

【０１０４】ＳＲＭ１２３は、ＳＣＳ１２２とともにシ
ステムの制御およびリソースの管理を行うものであり、
スキャナ部やプリンタ部などのエンジン、メモリ、ＨＤ
Ｄファイル、ホストＩ／Ｏ（セントロＩ／Ｆ、ネットワ
ークＩ／Ｆ、ＩＥＥＥ１３９４Ｉ／Ｆ、ＲＳ２３２Ｃ
Ｉ／Ｆなど）のハードウェア資源を利用する上位層か
らの要求にしたがって調停を行い、実行制御する。

【０１０５】具体的には、このＳＲＭ１２３は、要求さ
れたハードウェア資源が利用可能であるか（他の要求に
より利用されていないかどうか）を判断し、利用可能で
あれば要求されたハードウェア資源が利用可能である旨
を上位層に伝える。また、ＳＲＭ１２３は、上位層から
の要求に対してハードウェア資源の利用スケジューリン
グを行い、要求内容（たとえば、プリンタエンジンによ
り紙搬送と作像動作、メモリ確保、ファイル生成など）
を直接実施している。

【０１０６】ＳＣＳ１２２はアプリ管理、操作部制御、
システム画面表示、ＬＥＤ表示、リソース管理、割り込
みアプリ制御を行うものである。ＥＣＳ１２４は、白黒
ラインプリンタ（B&W LP）１０１、カラーラインプリン
タ（Color LP）１０２、スキャナ１０３、ファクシミリ
１０４からなるハードウェアリソースのエンジンを制御
するものである。

【０１０７】ＭＣＳ１２５は、画像メモリの取得および
解放、ハードディスク装置（ＨＤＤ）の利用、画像デー
タの圧縮および伸張などを行うものである。ＯＣＳ１２
６は、オペレータと本体制御間の情報伝達手段となる操
作パネルを制御するモジュールである。

【０１０８】ＦＣＳ１２７は、システムコントローラの
各アプリ層からＰＳＴＮ／ＩＳＤＮ網を利用したファク
シミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理
されている各種ファクシミリデータの登録／引用、ファ
クシミリ読みとり、ファクシミリ受信印刷、融合送受信
を行うためのＡＰＩを提供するものである。ＦＣＳ１２
７では、そのサブプロセスであるＦＣＵハンドラ１２９
（ＦＣＵＨ）が起動される。このＦＣＵＨ１２９は、Ｆ
ＣＳ１２７からの指令によりファクシミリ送受信の際に
ファクシミリエンジンのデバイスドライバを制御するも
のである。

【０１０９】ＮＣＳ１２８は、ネットワークＩ／Ｏを必
要とするアプリケーションに対して共通に利用できるサ
ービスを提供するためのモジュール群であり、ネットワ
ーク側から各プロトコルによって受信したデータを各ア
プリケーションに振り分けたり、アプリケーションから
データをネットワーク側に送信する際の仲介を行うもの
である。

【０１１０】アプリケーション１３０は、ページ記述言
語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）
を有するプリンタ用のアプリケーションであるプリンタ
アプリ１１１と、コピー用アプリケーションであるコピ
ーアプリ１１２と、ファクシミリ用アプリケーションで
あるファックスアプリ１１３と、スキャナ用アプリケー
ションであるスキャナアプリ１１４と、ネットワークフ
ァイル用アプリケーションであるネットファイルアプリ
１１５と、工程検査用アプリケーションである工程検査
アプリ１１６とを有している。

【０１１１】これらの各コントロールサービスとＳＲＭ
１２３と各アプリとは、それぞれプロセスとして汎用Ｏ
Ｓ上に生成されて実行される。各プロセス内部では、複
数のスレッドが起動され、汎用ＯＳの管理下でこれらの
スレッドのＣＰＵ占有時間を切り替えることにより並列
実行が実現されている。各アプリプロセスと各コントロ
ールサービスプロセスとは、後述するプロセス間通信に
よって各種メッセージやデータの送受信および関数呼び
出しを行う。

【０１１２】図２は、実施の形態１の複合機上で動作す
るサーバプロセスとクライアントプロセスの関係を示す
ブロック図である。ここで、サーバプロセス２０２と
は、クライアントプロセス２０１からの要求によりクラ
イアントプロセス２０１に対しサービスを提供するプロ
セスをいう。クライアントプロセス２０１とは、サーバ
プロセス２０２に対して要求を行うことにより、サーバ
プロセス２０２からサービスの提供を受けるプロセスを
いう。

【０１１３】実施の形態１の複合機では、上述のコピー
アプリ１１２、プリンタアプリ１１１、スキャナアプリ
１１４、ファックスアプリ１１３などのアプリケーショ
ンプロセス、およびＥＣＳ１２４、ＭＣＳ１２５、ＦＣ
Ｓ１２７、ＮＣＳ１２８などのコントロールサービスの
プロセスが主としてクライアントプロセス２０１とな
り、コントロールサービスおよびＳＲＭ１２３のプロセ
スが主としてサーバプロセス２０２となる。

【０１１４】すなわち、各アプリがコントロールサービ
スからサービスの提供を受ける場合には、各アプリのプ
ロセスがクライアントプロセス２０１として動作し、コ
ントロールサービスがサーバプロセス２０２として動作
する。また、コントロールサービス間でサービスの要求
と提供を行う場合には、サービスの要求を行うコントロ
ールサービスがクライアントプロセス２０１として動作
し、サービスの提供を行うコントロールサービスがサー
バプロセス２０２として動作する。

【０１１５】なお、これらの例に限られず、各アプリの
プロセス、コントロールサービスのプロセス、ＳＲＭプ
ロセスは、いずれもサーバプロセス２０２およびクライ
アントプロセス２０１となることができる。すなわち、
これらのプロセスが、他のいずれかのプロセスに対しサ
ービスを要求する場合にはクライアントプロセス２０１
として動作する一方、他のプロセスからの要求によりサ
ービスを提供する場合にはサーバプロセス２０２として
動作することになる。

【０１１６】図２に示すとおり、これらのアプリ、コン
トロールサービスおよびＳＲＭ１２３のプロセスには、
いずれも複数のスレッドが起動している。そして、各プ
ロセスは、複数のスレッドを有することから、他のプロ
セスからの要求を受けた場合に、当該他のプロセスをク
ライアントプロセス２０１としたサーバプロセス２０２
として動作するが、これと同時に、他のプロセスに対し
てサービスを要求する場合に当該他のプロセスをサーバ
プロセス２０２としたクライアントプロセス２０１とし
て動作する。

【０１１７】また、各プロセスは、同時に複数のプロセ
スをクライアントプロセス２０１としたサーバプロセス
２０２となることも可能である。さらに、各プロセス
は、同時に複数のサーバプロセス２０２からのサービス
の提供を受けるクライアントプロセス２０１となること
も可能である。

【０１１８】図２に示す通り、クライアントプロセス２
０１は、サーバプロセス２０２のサービスを要求するた
めに、クライアントプロセス内のスレッドからサーバプ
ロセス２０２に対して関数コールを行い、その関数戻り
値を受信することによってプロセス間通信を行う。

【０１１９】また、クライアントプロセス２０１の各ス
レッドはメッセージをサーバプロセス２０２に送信する
ことによってプロセス間通信を行う。一方、サーバプロ
セス２０２からクライアントプロセス２０１に対するプ
ロセス間通信は、メッセージの送信のみで行われ、関数
コールは行えないようになっている。

【０１２０】このため、サーバプロセス２０２となりう
るＥＣＳ１２４、ＭＣＳ１２５、ＦＣＳ１２７、ＮＣＳ
１２８などコントロールサービスおよびＳＲＭ１２３に
は、クライアントプロセス２０１に対して提供するサー
ビスが、サービスごとの後述する関数ハンドラ４０３と
してあらかじめ実装されている。これらのサービスの要
求をクライアントプロセス２０１から行う場合には、サ
ーバプロセス２０２に対して、サービスごとに関数を呼
び出すことにより（関数コールを行うことにより）、サ
ービスの提供を受けることが可能となっている。

【０１２１】ここで、「メッセージ」とは、主としてサ
ーバプロセス２０２とクライアントプロセス２０１との
間でイベントや通知を行う際に送信するものであり、一
意的なメッセージＩＤ、メッセージ名、メッセージ方
向、メッセージ内容を含むデータである。

【０１２２】メッセージ方向には、「ＩＮ」、「ＯＵ
Ｔ」、「ＳＥＬＦ」があり、「ＩＮ」がクライアントプ
ロセス２０１からサーバプロセス２０２に対して送信す
るメッセージを意味し、「ＯＵＴ」がサーバプロセス２
０２からクライアントプロセス２０１に対して送信する
メッセージを意味する。また、「ＳＥＬＦ」は、自分自
身のプロセスに対して送信するメッセージを意味する。

【０１２３】また、「関数」とは、クライアントプロセ
ス２０１からサーバプロセス２０２に対して所定の処理
要求を行ったり、所定の設定要求を行う際に発行するも
のであり、関数コールに対し戻り値を返すものである。

【０１２４】クライアントプロセス２０１のスレッド
は、あらかじめサーバプロセス２０２から提供されてい
る関数をコールする。関数コールを受けたサーバプロセ
ス２０２は要求された関数に対応する処理を実行してそ
の実行結果を関数戻り値としてクライアントプロセス２
０１のクライアントディスパッチャ２０３へ送信する。
また、関数戻り値は構造体となっており、かかる構造体
に戻り値の他、関数を識別する関数ＩＤが含まれてい
る。

【０１２５】クライアントディスパッチャ２０３は、サ
ーバプロセス２０２からのＯＵＴ方向のメッセージまた
は関数戻り値の受信を監視するスレッドである。クライ
アントプロセス２０１は、一つのサーバプロセス２０２
につき一つのクライアントディスパッチャ２０３を起動
してサーバプロセス２０２と通信する。クライアントプ
ロセス２０１が複数のサーバプロセス２０２と通信する
場合には、サーバプロセス２０２ごとに一つのクライア
ントディスパッチャ２０３を起動する。

【０１２６】図３はクライアントディスパッチャの詳細
な構成を示す説明図である。クライアントディスパッチ
ャ２０３は、そのスレッド上でメッセージハンドラ３０
２、エラーハンドラ３０１およびデフォルトハンドラ３
０３を起動する。

【０１２７】メッセージハンドラ３０２は、受信したメ
ッセージに対する処理を行うものであり、メッセージＩ
Ｄごとに別個のメッセージハンドラ３０２が複数存在す
る。このためクライアントディスパッチャ２０３がメッ
セージを受信すると、受信したメッセージに含まれるメ
ッセージＩＤを判断し、対応するメッセージＩＤのメッ
セージハンドラ３０２を呼び出すようになっている。メ
ッセージハンドラ３０２の処理内容としては、例えば、
メッセージの内容を関数コールを行ったスレッドに通知
するなどの処理があるが、メッセージごとに異なった処
理内容が定義されている。

【０１２８】エラーハンドラ３０１は、クライアントデ
ィスパッチャ２０３の実行中にエラーが発生した場合に
呼び出され、ユーザにエラー通知を行うなどのエラー処
理を行う。デフォルトハンドラ３０３は、対応するメッ
セージハンドラ３０２が登録されていないメッセージＩ
Ｄのメッセージを受信した時に呼び出され、メッセージ
をスレッドに通知するなどの処理を行う。

【０１２９】また、クライアントディスパッチャ２０３
は、関数戻り待ちキュー３０４を保持しており、この関
数戻り待ちキュー３０４を利用することによって関数戻
り値および関数戻り待ち状態のスレッド３０５の管理を
行っている。すなわち、クライアントプロセス２０１の
スレッドは、サーバプロセス２０２に対し関数コールを
行うが、関数コール後、関数戻り値を受信するまで関数
戻り待ち状態となり以降の処理が中断される。

【０１３０】クライアントディスパッチャ２０３は、ス
レッド３０５から関数コールが行われると、そのスレッ
ド３０５の識別子（スレッドＩＤなど）を関数の関数Ｉ
Ｄとともに関数戻り待ちキュー３０４に登録する。そし
て、クライアントディスパッチャ２０３は、サーバプロ
セス２０２から関数戻り値を受信すると、その関数ＩＤ
をキーとして関数戻り待ちキュー３０４を検索し、受信
した関数戻り値の受信を待って処理が中断されているス
レッド３０５の識別子（スレッドＩＤなど）を検出す
る。そして、クライアントディスパッチャ２０３は検出
された識別子（スレッドＩＤ）のスレッドに受信した関
数戻り値を送信する。関数戻り値を受信したスレッドは
戻り待ち状態を抜け、関数コール後の処理の続行が可能
となる。クライアントディスパッチャ２０３は、このよ
うな戻り値の通知を、関数戻り値を受信するごとに行
う。

【０１３１】サーバディスパッチャ２０４は、クライア
ントプロセス２０１のスレッドからの関数コールおよび
ＩＮ方向のメッセージを監視するスレッドである。１つ
のサーバディスパッチャ２０４は、クライアントディス
パッチャ２０３と異なり、複数のクライアントプロセス
２０１からの関数コールおよびメッセージを受信するこ
とができる。

【０１３２】図４はサーバディスパッチャ２０４の詳細
な構成を示す説明図である。サーバディスパッチャ２０
４は、そのスレッド上で、関数ハンドラ４０３、メッセ
ージハンドラ４０２、エラーハンドラ４０１およびデフ
ォルトハンドラ４０４を起動する。

【０１３３】関数ハンドラ４０３は、関数の具体的な処
理を実行するものであり、関数ごとに複数存在する。サ
ーバディスパッチャ２０４は、クライアントプロセス２
０１から関数コールを受信すると、受信した関数に対応
する関数ハンドラ４０３を起動し、関数ハンドラ４０３
によってクライアントプロセス２０１が要求した処理を
実行し、その関数戻り値をクライアントプロセス２０１
のクライアントディスパッチャ２０３へ送信する。

【０１３４】メッセージハンドラ４０２は、受信したメ
ッセージに対する処理を行うものであり、メッセージＩ
Ｄごとに複数存在する。サーバディスパッチャ２０４
は、メッセージを受信すると受信したメッセージに含ま
れるメッセージＩＤを判断し、対応するメッセージＩＤ
のメッセージハンドラ４０２を呼び出すようになってい
る。メッセージハンドラ４０２の処理内容としては、例
えば、メッセージの内容をスレッドに通知するなどの処
理があるが、メッセージごとに異なった処理内容が定義
されている。

【０１３５】エラーハンドラ４０１は、サーバディスパ
ッチャ２０４の実行中にエラーが発生した場合に呼び出
され、エラー通知などのエラー処理を行う。デフォルト
ハンドラ４０４は、対応するメッセージハンドラ４０２
が登録されていないメッセージＩＤのメッセージを受信
した時に呼び出され、メッセージをスレッドに通知する
などの処理を行う。

【０１３６】つぎに、実施の形態１の複合機１００で実
際に行われるプリンタ動作、スキャナ動作、コピー動作
およびファクシミリ送信動作におけるプロセス間通信に
ついて具体的に説明する。

【０１３７】まず、プリンタ動作におけるプリンタアプ
リ１１１、ＥＣＳ１２４、ＭＣＳ１２５、ＳＲＭ１２３
のプロセス間通信について説明する。図５は、実施の形
態１の複合機でプリンタ動作を行う場合のプリンタアプ
リ、ＥＣＳ、ＭＣＳ、ＳＲＭの各プロセス間のデータシ
ーケンスを示す説明図である。図６は、各プロセス間の
関数およびメッセージの送受信の関係を示す説明図であ
る。

【０１３８】図６に示すように、複合機１００にはプリ
ンタアプリプロセス１１１、ＥＣＳプロセス１２４、Ｍ
ＣＳプロセス１２５およびＳＲＭプロセス１２３が動作
している。これらプロセスは、複合機１００の起動時に
生成される。なお、図６にはプリンタ動作において使用
されるプロセスのみを図示しており、実際には他のアプ
リプロセスおよび他のコントロールサービスのプロセス
も複合機１００の起動時に生成される。

【０１３９】プリンタアプリプロセス１１１は、複合機
の起動時に起動され、図６に示すようにプロセス内に複
数のスレッドが起動している。プリンタアプリプロセス
１１１は、ＥＣＳプロセス１２４をサーバプロセスとし
たクライアントプロセスとなっており、このためＥＣＳ
プロセス１２４からのメッセージや関数戻り値を受信し
てプロセス内のスレッドに通知するクライアントディス
パッチャがスレッドとして起動される。

【０１４０】ＥＣＳプロセス１２４は、プリンタ動作時
には、プリンタアプリプロセス１１１をクライアントプ
ロセスとしたサーバプロセスとなるとともに、ＭＣＳプ
ロセス１２５およびＳＲＭプロセス１２３をそれぞれサ
ーバプロセスとしたクライアントプロセスとなる。この
ため、ＥＣＳプロセス１２４内にはプリンタアプリプロ
セス１１１からの関数コールおよびメッセージの受信と
プリンタアプリプロセス１１１に対するメッセージおよ
び関数戻り値の送信を行うサーバディスパッチャのスレ
ッドと、ＭＣＳプロセス１２５またはＳＲＭプロセス１
２３からのメッセージおよび関数戻り値の受信および戻
り値の管理を行うクライアントディスパッチャと、その
他ジョブ制御およびエンジン制御に関する処理を行う複
数のスレッドが動作している。

【０１４１】ＭＣＳプロセス１２５は、プリンタ動作時
には、ＥＣＳプロセス１２４をクライアントプロセスと
したサーバプロセスとなるとともに、ＳＲＭプロセス１
２３をサーバプロセスとしたクライアントプロセスとな
る。このため、ＭＣＳプロセス１２５内にはＥＣＳプロ
セス１２４からの関数コールおよびメッセージの受信と
ＥＣＳプロセス１２４に対するメッセージおよび関数戻
り値の送信を行うサーバディスパッチャのスレッドと、
ＳＲＭプロセス１２３からのメッセージおよび関数戻り
値の受信および戻り値の管理を行うクライアントディス
パッチャと、その他、メモリ制御またはハードディスク
制御に関する処理を行う複数のスレッドが動作してい
る。

【０１４２】ＳＲＭプロセス１２３は、プリンタ動作時
には、ＥＣＳプロセス１２４またはＭＣＳプロセス１２
５をクライアントプロセスとしたサーバプロセスとなっ
ている。ＳＲＭプロセス１２３内にはＥＣＳプロセス１
２４またはＭＣＳプロセス１２５からの関数コールおよ
びメッセージの受信とＥＣＳプロセス１２４またはＭＣ
Ｓプロセス１２５に対するメッセージおよび関数戻り値
の送信を行うサーバディスパッチャのスレッドと、その
他、エンジン資源制御に関する種々の処理を行う複数の
スレッドが動作している。

【０１４３】実施の形態１におけるプリンタアプリプロ
セス１１１では、ジョブ動作モード設定とジョブスター
ト要求の各関数コールを行う処理を一スレッドとしてい
る。また、ＥＣＳプロセス１２４では、印刷枚数分繰り
返しメモリ画像情報要求関数コールを行う処理を一スレ
ッドとし、また資源獲得要求関数コールを行う処理を一
スレッドとしている。ＭＣＳプロセス１２５では、メモ
リ取得要求関数コールを行う処理を一スレッドとしてい
る。ただし、これらの各スレッドにおける処理は一例で
あり、各プログラムで任意に定めることができる。

【０１４４】ＰＣなどのホストからセントロＩ／Ｆ、Ｕ
ＳＢＩ／Ｆ、ネットワークＩ／Ｆなど経由して印刷要
求１があると、その印刷要求１をＮＣＳプロセスが受け
プリンタアプリプロセスに転送する（ステップＳ５０
１）。プリンタアプリプロセス１１１は、ＮＣＳプロセ
スから印刷要求を受信すると新たなプリントジョブを生
成し、スレッド１においてＥＣＳプロセス１２４に対し
てジョブ動作モード設定要求関数コールを行う（ステッ
プＳ５０２）。

【０１４５】その後このスレッド１は関数戻り値の受信
待ちとなり、クライアントディスパッチャによりスレッ
ド１の識別子（スレッドＩＤ）が関数戻り待ちキューに
登録される。ここで、ジョブ動作モードとは、スキャ
ナ、プロッタ、フィニッシャなどを動作させるために必
要なパラメータ群であり、印刷用紙サイズ、印刷部数、
給紙トレイなどのプリンタ条件から生成されるジョブの
動作条件を定めたものである。

【０１４６】なお、以降では説明の簡略化のため、サー
バプロセスに関数コールを行って関数戻り待ち状態とな
ったスレッドの識別子（スレッドＩＤ）が、クライアン
トディスパッチャによって、関数ＩＤとともに関数戻り
待ちキューに登録されることを、単に「スレッドが関数
戻り待ち状態になる」と表現する。

【０１４７】ＥＣＳプロセス１２４では、サーバディス
パッチャがプリンタアプリプロセスからジョブ動作モー
ド設定関数コールを受信して、ジョブ動作モード設定関
数ハンドラをサーバディスパッチャのスレッド上で起動
する。そして、ジョブ動作モード設定関数ハンドラによ
り新たに生成されたプリンタジョブに対して上述のジョ
ブ動作モードを設定し、関数戻り値（例えば、正常また
はエラー発生）をプリンタアプリプロセス１１１のクラ
イアントディスパッチャへ送信する。

【０１４８】プリンタアプリプロセス１１１のクライア
ントディスパッチャは、ＥＣＳプロセス１２４からジョ
ブ動作モード設定関数の関数戻り値を受信して、関数戻
り待ちキューから関数戻り値待ちのスレッド１を検索し
て、ジョブ動作モード設定関数の戻り値を抽出してスレ
ッド１に送信する。

【０１４９】なお、以降では説明の簡略化のため、クラ
イアントディスパッチャによって、関数戻り待ち状態の
スレッドの識別子（スレッドＩＤ）が関数戻り待ちキュ
ーから検索され、検索された識別子（スレッドＩＤ）の
スレッドがクライアントディスパッチャから関数戻り値
を受信することを、単に「スレッドがクライアントディ
スパッチャ経由で関数戻り値を受信する」と表現する。

【０１５０】スレッド１では、クライアントディスパッ
チャからジョブ動作モード設定の関数戻り値を受信する
と、戻り待ち状態を抜け、ジョブの開始要求を行うた
め、ＥＣＳプロセス１２４に対しジョブスタート要求関
数を呼び出し（ステップＳ５０３）、関数戻り待ち状態
となる。

【０１５１】ＥＣＳプロセス１２４では、サーバディス
パッチャがプリンタアプリプロセス１１１からジョブス
タート要求関数コールを受信して、ジョブスタート要求
関数ハンドラをサーバディスパッチャのスレッド上で起
動し、ジョブスタート要求関数ハンドラによってジョブ
の開始処理を行って関数戻り値をプリンタアプリプロセ
ス１１１のクライアントディスパッチャへ送信する。

【０１５２】プリンタアプリプロセス１１１のクライア
ントディスパッチャは、ＥＣＳプロセス１２４からジョ
ブスタート要求関数の戻り値を受信して、スレッド１が
クライアントディスパッチャ経由でジョブスタート要求
関数の戻り値を受信する。

【０１５３】つぎに、ＥＣＳプロセス１２４では、メモ
リに格納されている印刷データを取得するためにスレッ
ド３においてＭＣＳプロセス１２５に対してメモリ画像
情報要求メッセージを送信する（ステップＳ５０４）。

【０１５４】ＭＣＳプロセス１２５では、サーバディス
パッチャがＥＣＳプロセス１２４からメモリ画像情報要
求メッセージを受信して、メモリ画像情報要求メッセー
ジハンドラを起動する。そして、このメモリ画像情報要
求メッセージハンドラによってメモリに格納されている
画像データを取得して、画像データをＥＣＳプロセス１
２４へ送信する（ステップＳ５０５）。

【０１５５】ＥＣＳプロセス１２４のクライアントディ
スパッチャは、ＭＣＳプロセス１２５から画像データを
受信して、スレッド３へ受け渡す。かかるメモリ画像情
報要求メッセージの送信および画像データの受信処理
は、印刷ページが終了するまで繰り返し行われる（ステ
ップＳ５０８、Ｓ５０９）。

【０１５６】一方、ＭＣＳプロセス１２５では、画像デ
ータのＥＣＳプロセス１２４への送信後、画像メモリを
確保するためにスレッド５においてＳＲＭプロセス１２
３に対してメモリ取得要求関数コールを行って（ステッ
プＳ５０６）、戻り待ち状態となる。ＳＲＭプロセス１
２３では、サーバディスパッチャがＭＣＳプロセス１２
５からメモリ取得要求関数コールを受信し、メモリ取得
要求関数ハンドラを起動して、このメモリ取得要求関数
ハンドラによってプリント用に画像メモリを確保し、関
数戻り値をＭＣＳプロセス１２５へ送信する。

【０１５７】ＭＣＳプロセス１２５のクライアントディ
スパッチャは、ＳＲＭプロセス１２３からメモリ取得要
求関数の戻り値を受信して、スレッド５がクライアント
ディスパッチャ経由でこのメモリ取得要求関数の戻り値
を受信する。

【０１５８】ＥＣＳプロセス１２４では、１ページ目の
印刷データをＭＣＳプロセス１２５から受信した後、プ
リンタエンジン資源を取得するためにスレッド４におい
て、ＳＲＭプロセス１２３に対して資源獲得要求関数コ
ールを行って（ステップＳ５０７）、関数戻り待ち状態
となる。ＳＲＭプロセス１２３では、サーバディスパッ
チャがＥＣＳプロセス１２４から資源獲得要求関数コー
ルを受信して資源獲得要求関数ハンドラを起動し、資源
獲得要求関数ハンドラによってプリンタエンジンを占有
し、関数戻り値をＥＣＳプロセス１２４へ送信する。Ｅ
ＣＳプロセス１２４のクライアントディスパッチャは、
ＳＲＭプロセス１２３から資源獲得要求関数の戻り値を
受信して、スレッド４がクライアントディスパッチャ経
由で資源獲得要求関数の戻り値を受信する。

【０１５９】ＥＣＳプロセス１２４のスレッド３では、
メモリ画像情報要求メッセージ（ステップＳ５１１）に
対する通知メッセージとして「画像なし」の応答メッセ
ージを受信した場合には（ステップＳ５１２）、すべて
の印刷ページのプリントが終了したものと判断し、プリ
ンタアプリプロセス１１１に対し、ジョブエンド通知メ
ッセージを送信する（ステップＳ５１３）。プリンタア
プリプロセス１１１では、クライアントディスパッチャ
がこのメッセージを受信してメッセージハンドラを起動
し、メッセージハンドラによってジョブエンド通知メッ
セージをスレッド１へ通知する。

【０１６０】このようにプリンタ動作のプロセス間通信
が行われるが、ここで、図５に示すように、印刷要求１
に対するプリント処理中に、別の印刷要求２がＮＣＳか
らプリンタアプリプロセス１１１へ送信された場合につ
いて説明する。（ステップＳ５２１）。

【０１６１】このとき、プリンタアプリプロセス１１
１、ＥＣＳプロセス１２４、ＭＣＳプロセス１２５およ
びＳＲＭプロセス１２３で、上述した関数コールと同様
のプロセス間通信が行われる（ステップＳ５２２、Ｓ５
２３、Ｓ５２４）。

【０１６２】しかし、ＥＣＳプロセス１２４のスレッド
７からＳＲＭプロセス１２３に対して資源獲得要求関数
コールを行った場合（ステップＳ５２７）、現在プリン
タエンジンが印刷要求１に対するプリント処理に占有さ
れているため、ＳＲＭプロセス１２３は直ちに資源獲得
要求関数の戻り値を返さない。このため、このスレッド
７はしばらく関数戻り値待ちの状態となり、関数戻り待
ちキューに登録された状態となる。そして、印刷要求１
による占有からプリンタエンジンが解放された時点で、
ＳＲＭプロセス１２３は資源獲得要求関数の戻り値をＥ
ＣＳプロセス１２４に返し（ステップＳ５２８）、これ
により、ＥＣＳプロセス１２４のスレッド７が、印刷要
求２に対する処理を続行することになる。

【０１６３】なお、ここでは印刷要求２に対するプリン
タジョブにおいて、プリンタエンジンの獲得ができない
場合の例を説明した。この他、ＥＣＳプロセス１２４か
らＳＲＭプロセス１２３に対してメモリ取得要求関数コ
ールを行ったときに、すでに印刷要求１に対するプリン
トジョブが原因でメモリ不足が生じ、印刷要求２のプリ
ントジョブでメモリを取得できない場合には、メモリ取
得要求関数コールを行ったスレッドが印刷要求１のプリ
ンタ動作完了まで関数戻り待ち状態のまま待機し、印刷
要求２に対するプリンタ動作が中断する。

【０１６４】次に、実施の形態１の複合機１００で行わ
れるスキャナ動作において、スキャナアプリ１１４、Ｅ
ＣＳ１２４、ＭＣＳ１２５、ＳＲＭ１２３のプロセス間
通信について具体的に説明する。図７は、実施の形態１
の複合機でスキャナ動作を行う場合のスキャナアプリ、
ＥＣＳ、ＭＣＳ、ＳＲＭの各プロセス間のデータシーケ
ンスを示す説明図である。また、図８は、各プロセス間
の関数およびメッセージの送受信の関係を示す説明図で
ある。

【０１６５】図８に示すように、複合機１００にはスキ
ャナアプリプロセス１１４、ＥＣＳプロセス１２４、Ｍ
ＣＳプロセス１２５およびＳＲＭプロセス１２３が動作
している。これらのプロセスは、複合機１００の起動時
に生成される。なお、図８にはスキャナ動作において使
用されるプロセスのみを図示しており、実際には他のア
プリプロセスおよび他のコントロールサービスのプロセ
スも複合機１００の起動時に生成される。

【０１６６】スキャナアプリプロセス１１４は、複合機
の起動時に起動され、図８に示すようにプロセス内に複
数のスレッドが起動している。スキャナアプリプロセス
１１４は、ＥＣＳプロセス１２４をサーバプロセスとし
たクライアントプロセスとなっており、このためＥＣＳ
プロセス１２４に対するクライアントディスパッチャの
スレッドが起動している。

【０１６７】ＥＣＳプロセス１２４は、スキャナ動作時
には、スキャナアプリプロセス１１４をクライアントプ
ロセスとしたサーバプロセスとなるとともに、ＭＣＳプ
ロセス１２５およびＳＲＭプロセス１２４をそれぞれサ
ーバプロセスとしたクライアントプロセスとなる。この
ため、ＥＣＳプロセス１２４内にはスキャナアプリプロ
セス１１４に対するサーバディスパッチャのスレッド
と、ＭＣＳプロセス１２５に対するクライアントディス
パッチャのスレッドと、ＳＲＭプロセス１２３に対する
クライアントディスパッチャのスレッドとその他ジョブ
制御またはエンジン制御に関する処理を行う複数のスレ
ッドが動作している。

【０１６８】ＭＣＳプロセス１２５は、スキャナ動作時
には、スキャナアプリプロセス１１４およびＥＣＳプロ
セス１２４をクライアントプロセスとしたサーバプロセ
スとなる。このため、ＭＣＳプロセス１２５内にはスキ
ャナアプリプロセス１１４およびＥＣＳプロセス１２４
に対するサーバディスパッチャのスレッドとその他メモ
リ制御またはハードディスク制御に関する処理を行う複
数のスレッドが動作している。

【０１６９】ＳＲＭプロセス１２３は、ＥＣＳプロセス
１２４をクライアントプロセスとしたサーバプロセスと
なり、このため、ＳＲＭプロセス１２３内にはＥＣＳプ
ロセス１２４に対するサーバディスパッチャのスレッド
とその他エンジン資源制御に関する処理を行う複数のス
レッドが動作している。

【０１７０】実施の形態１におけるスキャナアプリプロ
セス１１４では、スキャナ動作時におけるジョブオープ
ン要求関数とジョブ動作モード設定要求とジョブスター
ト要求の各関数コールを行う一連の処理、ファイル生成
要求関数コールを行う処理、ファイル情報登録要求関数
コールおよびファイルクローズ要求関数コールを行う処
理をそれぞれ一スレッドとしている。

【０１７１】また、スキャナアプリプロセス１１４で
は、スキャンした画像の読み出し時におけるファイルオ
ープン要求関数コール、作業領域確保要求関数コールお
よびページオープン要求関数コールを行う処理、読み出
し要求関数コールを行う処理、ページクローズ要求関数
コールとページ削除要求関数コールと作業領域削除要求
関数コールとファイルクローズ要求関数コールとファイ
ル削除要求関数コールを行う一連の処理をそれぞれ一ス
レッドとしている。

【０１７２】ＥＣＳプロセス１２４では、資源獲得要求
関数コールを行う処理、原稿枚数分繰り返してページ生
成要求関数コールと原稿フィードインおよびページクロ
ーズ要求関数コールを行う一連の処理をそれぞれ一スレ
ッドとしている。ただし、これらの各スレッドにおける
処理は一例であり、各プログラムで任意に定めることが
できる。

【０１７３】スキャナアプリプロセス１１４に対しスキ
ャン要求があると、スキャナアプリプロセス１１４は、
新たなスキャナジョブを生成し、スレッド１においてＥ
ＣＳプロセス１２４に対してジョブオープン要求関数コ
ールを行う（ステップＳ７０１）。その後このスレッド
１は関数戻り待ち状態となり、クライアントディスパッ
チャによってスレッド１の識別子（スレッドＩＤ）が呼
び出した関数の関数ＩＤとともに関数戻り待ちキューに
登録される。

【０１７４】また、スキャナアプリプロセス１１４で
は、これと並行してスレッド２によりＭＣＳプロセス１
２５に対しファイル生成要求関数コールを行う（ステッ
プＳ７０２）。その後このスレッド２は関数戻り待ち状
態となり、同様にスレッド２の識別子（スレッドＩＤ）
が関数戻り待ちキューに登録される。

【０１７５】ＥＣＳプロセス１２４では、サーバディス
パッチャがスキャナアプリプロセス１１４からジョブオ
ープン要求関数コールを受信して、ジョブオープン要求
関数ハンドラをサーバディスパッチャのスレッド上で起
動する。そして、ジョブオープン要求関数ハンドラによ
りジョブをオープンして、関数戻り値をスキャナアプリ
プロセス１１４のクライアントディスパッチャへ送信す
る。

【０１７６】一方、ＭＣＳプロセス１２５では、サーバ
ディスパッチャがスキャナアプリプロセス１１４からフ
ァイル生成要求関数コールを受信して、ファイル生成要
求関数ハンドラによって、スキャンした画像を一時的に
格納するファイルをハードディスク上に生成して、関数
戻り値をスキャナアプリプロセス１１４のクライアント
ディスパッチャへ送信する。

【０１７７】スキャナアプリプロセス１１４のクライア
ントディスパッチャは、ＥＣＳプロセス１２４からジョ
ブオープン要求関数の関数戻り値を受信するとともに、
ＭＣＳプロセス１２５からファイル生成要求関数の戻り
値を受信して、関数戻り値キューからジョブオープン要
求関数戻り待ち状態のスレッド１とファイル生成要求関
数戻り待ち状態のスレッド２を検出し、ジョブオープン
要求関数の戻り値をスレッド１に送信し、ファイル生成
要求関数の戻り値をスレッド２に送信する。

【０１７８】スレッド１は、クライアントディスパッチ
ャからジョブオープン要求関数の戻り値を受信すると戻
り待ち状態を抜け、ジョブ動作モードの設定を行うた
め、ＥＣＳプロセス１２４に対しジョブ動作モード設定
要求関数を呼び出し（ステップＳ７０３）、スレッド１
は関数戻り待ち状態となる。

【０１７９】ＥＣＳプロセス１２４では、サーバディス
パッチャがスキャナアプリプロセス１１４からジョブ動
作モード設定要求関数コールを受信して、ジョブ動作モ
ード設定要求関数ハンドラによってスキャナジョブに上
述のジョブ動作モードを設定して関数戻り値をスキャナ
アプリプロセス１１４のクライアントディスパッチャへ
送信する。

【０１８０】スキャナアプリプロセス１１４のクライア
ントディスパッチャは、ＥＣＳプロセス１２４からジョ
ブ動作モード設定要求関数の戻り値を受信する。スレッ
ド１はクライアントディスパッチャ経由でジョブ動作モ
ード設定要求関数の戻り値を受信し、関数戻り待ち状態
を抜ける。

【０１８１】関数戻り待ち状態を抜けたスレッド１で
は、ジョブスタート要求関数コールをＥＣＳプロセス１
２４に対して行い（ステップＳ７０４）、スレッド１が
関数戻り待ち状態となる。ＥＣＳプロセス１２４では、
サーバディスパッチャがジョブスタート要求関数コール
を受信して、ジョブスタート要求関数ハンドラによって
ジョブの開始処理を行い、関数戻り値をスキャナアプリ
プロセス１１４のクライアントディスパッチャへ送信す
る。スキャナアプリプロセス１１４のクライアントディ
スパッチャは、ＥＣＳプロセス１２４からジョブスター
ト要求関数の戻り値を受信し、スレッド１がクライアン
トディスパッチャ経由でジョブスタート要求関数の関数
戻り値を受信する。

【０１８２】このとき、ＥＣＳプロセス１２４では、ス
キャナエンジンの資源格闘のため、スレッド３において
ＳＲＭプロセス１２３に対して資源獲得要求関数コール
を行い（ステップＳ７０５）、関数戻り待ち状態とな
る。またＥＣＳプロセス１２４では、これと並行してス
キャン画像をページ単位で格納するメモリを確保するた
めに、スレッド４においてＭＣＳプロセス１２５に対し
ページ生成要求関数コールを行い（ステップＳ７０
６）、関数戻り待ち状態となる。この時点で、関数戻り
待ちキューには、スレッド３とスレッド４の識別子（ス
レッドＩＤ）が呼び出した関数の関数ＩＤとともに格納
される。

【０１８３】ＳＲＭプロセス１２３では、サーバディス
パッチャが資源獲得要求関数コールを受信して資源獲得
要求関数ハンドラにより、スキャナエンジンを占有し関
数戻り値をＥＣＳプロセス１２４へ送信する。ＭＣＳプ
ロセス１２５では、サーバディスパッチャがページ生成
要求関数コールを受信してページ生成要求関数ハンドラ
により、１ページ分のメモリを確保し、確保したページ
をオープンし、関数戻り値をＥＣＳプロセス１２４へ送
信する。

【０１８４】ＥＣＳプロセス１２４のクライアントディ
スパッチャは、ＳＲＭプロセス１２３から資源獲得要求
関数の戻り値を受信し、またＭＣＳプロセス１２５から
ページ生成要求関数の戻り値を受信する。そして、関数
戻り待ち状態のスレッド３はクライアントディスパッチ
ャ経由で資源獲得要求関数の戻り値を受信し、スレッド
４もクライアントディスパッチャ経由でページ生成要求
関数の戻り値を受信する。

【０１８５】スレッド４は、関数戻り値を受信すること
によって戻り待ち状態を抜け、つぎにスキャナエンジン
に対して原稿フィードインの指示メッセージを送信して
（ステップＳ７０７）、スキャナによる原稿の読み取り
動作を開始させる。１ページ分の原稿読み動作が終了す
ると、ＥＣＳプロセス１２４に対しスキャナエンジンか
らスキャン完了通知メッセージが送信されるので（ステ
ップＳ７０８）、ＥＣＳプロセス１２４のスレッド４は
このスキャン完了通知メッセージを受信してＭＣＳプロ
セス１２５に対しページクローズ要求関数コールを行っ
て（ステップＳ７０９）、戻り待ち状態となる。

【０１８６】ＭＣＳプロセス１２５では、ページクロー
ズ要求関数コールを受信すると、ページクローズ要求関
数ハンドラによってメモリ上でオープンされている１ペ
ージ分の画像メモリをクローズして関数戻り値をＥＣＳ
プロセス１２４のクライアントディスパッチャへ送信す
る。

【０１８７】ＥＣＳプロセス１２４のクライアントディ
スパッチャは、ページクローズ要求関数の戻り値を受信
し、関数戻り待ち状態のスレッド４がクライアントディ
スパッチャ経由でページクローズ要求関数の戻り値を受
信する。スレッド４では、これにより関数戻り待ち状態
を抜け、上述のページ生成要求関数コールからページク
ローズ要求関数コールまでの処理（ステップＳ７０６〜
Ｓ７０９）を原稿枚数分だけ繰り返し行う。

【０１８８】原稿の最終ページのスキャンが終了する
と、スキャナエンジンはスレッド４に対しスキャン処理
完了通知メッセージを送信する（ステップＳ７１０）。
スレッド４ではこのスキャン処理完了通知メッセージを
スキャナアプリプロセス１１４に対して送信し（ステッ
プＳ７１１）、さらにジョブエンド通知メッセージも送
信する（ステップＳ７１２）。

【０１８９】スキャナアプリプロセス１１４のクライア
ントディスパッチャは、スキャン処理完了通知メッセー
ジとジョブエンド通知メッセージとを順にＥＣＳプロセ
ス１２４から受信し、スレッド１に通知する。一方、ス
キャナアプリプロセス１１４のスレッド５は、ＭＣＳプ
ロセス１２５に対してファイル情報登録要求関数コール
を行って（ステップＳ７１３）、関数戻り待ち状態とな
る。

【０１９０】ＭＣＳプロセス１２５では、サーバディス
パッチャがファイル情報登録要求関数コールを受信する
と、ファイル情報登録要求関数ハンドラによって、一時
的に生成されたすべての原稿のスキャン画像が格納され
ているファイルに対し、ファイル名、格納先等のファイ
ル情報を登録し、関数戻り値をスキャナアプリプロセス
１１４のクライアントディスパッチャへ送信する。

【０１９１】スキャナアプリプロセス１１４のスレッド
５は、ファイル情報登録要求関数の戻り値をクライアン
トディスパッチャ経由で受信すると、ＭＣＳプロセス１
２５に対しファイルクローズ要求関数コールを行って
（ステップＳ７１４）、関数戻り待ち状態となる。ＭＣ
Ｓプロセス１２５では、サーバディスパッチャでこのフ
ァイルクローズ要求関数コールを受信し、ファイルクロ
ーズ要求関数ハンドラによってスキャン画像のファイル
をクローズして関数戻り値をスキャナアプリプロセス１
１４に送信する。スキャナアプリプロセス１１４は、こ
のファイルクローズ要求関数の戻り値を受信することに
より、スキャン処理が終了する。

【０１９２】ついで、スキャナアプリプロセス１１４で
は、格納されているスキャン画像を読み出すため、次の
処理を行う。まず、スレッド６において、ＭＣＳプロセ
ス１２５に対し、スキャン画像のファイルをオープンす
るためのファイルオープン要求関数コール、作業メモリ
の確保のための作業領域確保要求関数コール、ページオ
ープン要求関数コールを順次に行う（ステップＳ７１５
〜Ｓ７１７）。なお、スレッド６は、上述と同様に、そ
れぞれの関数コールを行った後、関数戻り待ち状態にな
り、関数戻り値の通知により、戻り待ち状態を抜け、次
の関数コールを行う。

【０１９３】ＭＣＳプロセス１２５のサーバディスパッ
チャは、スキャナアプリプロセス１１４のスレッド６か
らファイルオープン要求関数コール、作業領域確保要求
関数コール、ページオープン要求関数コールを順に受信
して、スキャン画像ファイルのオープン処理、作業メモ
リの確保処理、ページオープン処理をそれぞれ各関数ハ
ンドラによって行って、各関数戻り値をスキャナアプリ
プロセス１１４に送信する。スキャナアプリプロセス１
１４では、クライアントディスパッチャによりファイル
オープン要求関数、作業領域確保要求関数、ページオー
プン要求関数の各戻り値を順に受信して、スレッド６が
クライアントディスパッチャ経由で関数戻り値を受信す
る。

【０１９４】また、スキャナアプリプロセス１１４で
は、スレッド７において、スキャン画像ファイルからの
画像データの読み出しのために読み出し要求関数コール
を行い（ステップＳ７１８）、スレッド７が関数戻り待
ち状態になる。さらに、スレッド８において、ＭＣＳプ
ロセス１２５に対しページクローズ要求関数コールを行
い（ステップＳ７１９）、スレッド８は関数戻り待ち状
態になる。

【０１９５】ＭＣＳプロセス１２５では、スレッド６か
らの要求であるページオープン処理の終了後に、スキャ
ナアプリプロセス１１４のスレッド７から読み出し要求
関数コールを受信し、読み出し要求関数ハンドラによっ
てスキャナ画像ファイルから画像データを読み出し、画
像データとともに関数戻り値をスキャナアプリプロセス
１１４へ送信する。スキャナアプリプロセス１１４で
は、スレッド７が読み出し要求関数の戻り値をクライア
ントディスパッチャ経由で受信することにより、関数戻
り待ち状態を抜け、次の読み出し要求関数コールを行
い、同様に関数戻り値を受信する。

【０１９６】ＭＣＳプロセス１２５では、スレッド７か
らの要求である最後の読み出し要求処理が終了すると、
スキャナアプリプロセス１１４のスレッド８から受信し
たページクローズ要求関数の関数ハンドラを起動して、
オープンしているページデータのクローズ処理を行い、
関数戻り値をスキャナアプリプロセス１１４へ送信す
る。スキャナアプリプロセス１１４では、スレッド８が
ページクローズ要求関数の戻り値をクライアントディス
パッチャ経由で受信し、関数戻り待ち状態を抜ける。こ
れにより、スレッド８では、ページ削除要求関数コー
ル、作業領域削除要求関数コール、ファイルクローズ要
求関数コール、ファイル削除要求関数コールを順に行う
（ステップＳ７２０〜Ｓ７２３）。

【０１９７】ＭＣＳプロセス１２５は、これらの関数コ
ールを順に受信して、受信した関数コールに対応する関
数ハンドラによってそれぞれ、ページデータの削除、作
業メモリの削除、スキャン画像ファイルのクローズ、ス
キャン画像ファイルの削除の各処理を行って、各関数戻
り値をスキャナアプリプロセス１１４に送信する。

【０１９８】スキャナアプリプロセス１１４のスレッド
８では、ＭＣＳプロセス１２５からの各関数戻り値をク
ライアントディスパッチャ経由で受信することにより、
スキャン画像の読み出し処理が完了する。

【０１９９】次に、実施の形態１の複合機１００で行わ
れるコピー動作において、コピーアプリ１１２、ＥＣＳ
１２４、ＭＣＳ１２５、ＳＲＭ１２３のプロセス間通信
について具体的に説明する。図９は、実施の形態１の複
合機でコピー動作を行う場合のコピーアプリ、ＥＣＳ、
ＭＣＳ、ＳＲＭの各プロセス間のデータシーケンスを示
す説明図である。また、図１０は、各プロセス間の関数
およびメッセージの送受信の関係を示す説明図である。

【０２００】図１０に示すように、複合機１００にはコ
ピーアプリプロセス１１２、ＥＣＳプロセス１２４、Ｍ
ＣＳプロセス１２５およびＳＲＭプロセス１２３が動作
している。これらプロセスは、複合機１００の起動時に
生成される。なお、図１０にはコピー動作において使用
されるプロセスのみを図示しており、実際には他のアプ
リプロセスおよび他のコントロールサービスのプロセス
も複合機の起動時に生成される。

【０２０１】コピーアプリプロセス１１２は、複合機１
００の起動時に起動され、図１０に示すようにプロセス
内に複数のスレッドが起動している。コピーアプリプロ
セス１１２は、ＥＣＳプロセス１２４をサーバプロセス
としたクライアントプロセスとなっており、このためＥ
ＣＳプロセス１２４に対するクライアントディスパッチ
ャのスレッドが起動している。

【０２０２】ＥＣＳプロセス１２４は、コピー動作時に
は、コピーアプリプロセス１１２をクライアントプロセ
スとしたサーバプロセスとなるとともに、ＭＣＳプロセ
ス１２５およびＳＲＭプロセス１２３をそれぞれサーバ
プロセスとしたクライアントプロセスとなる。このた
め、ＥＣＳプロセス１２４内にはコピーアプリプロセス
１１２に対するサーバディスパッチャのスレッドと、Ｍ
ＣＳプロセス１２５に対するクライアントディスパッチ
ャのスレッドと、ＳＲＭプロセス１２３に対するクライ
アントディスパッチャのスレッドとその他ジョブ制御お
よびエンジン制御に関する処理を行う複数のスレッドが
動作している。

【０２０３】ＭＣＳプロセス１２５は、コピー動作時に
は、ＥＣＳプロセス１２４をクライアントプロセスとし
たサーバプロセスとなるとともに、ＳＲＭプロセス１２
３をサーバプロセスとしたクライアントプロセスとな
る。このため、ＭＣＳプロセス１２５内にはＥＣＳプロ
セス１２４に対するサーバディスパッチャのスレッド
と、ＳＲＭプロセス１２３に対するクライアントディス
パッチャのスレッドと、その他メモリ制御およびハード
ディスク制御に関する種々の処理を行う複数のスレッド
が動作している。

【０２０４】ＳＲＭプロセス１２３は、ＥＣＳプロセス
１２４およびＭＣＳプロセス１２５をクライアントプロ
セスとしたサーバプロセスとなり、このため、ＳＲＭプ
ロセス１２３内にはＥＣＳプロセス１２４およびＭＣＳ
プロセス１２５に対するサーバディスパッチャのスレッ
ドとその他エンジンの資源制御に関する処理を行う複数
のスレッドが動作している。

【０２０５】実施の形態１におけるコピーアプリプロセ
ス１１２では、コピー時におけるジョブオープン要求関
数コールとジョブ動作モード設定関数コールとジョブス
タート要求関数コールを行う一連の処理、ジョブクロー
ズ要求関数コールを行う処理をそれぞれ一スレッドとし
ている。

【０２０６】ＥＣＳプロセス１２４では、メモリ確保要
求関数コールを行う処理、資源獲得要求関数コールを行
う処理、原稿フィードイン処理をそれぞれ一スレッドと
している。ＭＣＳプロセス１２５では、メモリ取得要求
関数コールを行う処理を一スレッドとしている。なお、
コピー動作時においても、これら各スレッドにおける処
理は一例であり、各プログラムで任意に定めることがで
きる。

【０２０７】コピー要求があると、コピーアプリプロセ
ス１１２は、新たなコピージョブを生成し、スレッド１
においてＥＣＳプロセス１２４に対してジョブオープン
要求関数コールを行う（ステップＳ９０１）。これによ
り、スレッド１は関数戻り待ち状態となり、クライアン
トディスパッチャによってスレッド１の識別子（スレッ
ドＩＤ）が呼び出したジョブオープン要求関数の関数Ｉ
Ｄとともに関数戻り待ちキューに登録される。

【０２０８】ＥＣＳプロセス１２４では、サーバディス
パッチャがコピーアプリプロセス１１２からジョブオー
プン要求関数コールを受信して、ジョブオープン要求関
数ハンドラをサーバディスパッチャのスレッド上で起動
する。そして、ジョブオープン要求関数ハンドラにより
コピージョブをオープンして、関数戻り値をコピーアプ
リプロセス１１２のクライアントディスパッチャへ送信
する。

【０２０９】コピーアプリプロセス１１２のクライアン
トディスパッチャは、ＥＣＳプロセス１２４からジョブ
オープン要求関数の戻り値を受信し、関数戻り値待ちキ
ューから関数戻り待ち状態のスレッドを検索する。そし
て、検索されたスレッド１にジョブオープン要求関数の
戻り値を送信する。

【０２１０】スレッド１は、クライアントディスパッチ
ャからジョブオープン要求関数の戻り値を受信すると、
戻り待ち状態を抜け、ジョブ動作モードの設定を行うた
め、ＥＣＳプロセス１２４に対しジョブ動作モード設定
関数コールを行い（ステップＳ９０２）、関数戻り待ち
状態となる。

【０２１１】一方、スレッド２はジョブスタート要求関
数コールをＥＣＳプロセス１２４に対して行い（ステッ
プＳ９０３）、関数戻り待ち状態となる。この時点で
は、関数戻り待ちキューにはスレッド１の識別子（スレ
ッドＩＤ）がジョブ動作モード設定関数の関数ＩＤとと
もに登録され、またスレッド２の識別子（スレッドＩ
Ｄ）がジョブスタート要求関数の関数ＩＤとともにクラ
イアントディスパッチャにより登録される。

【０２１２】ＥＣＳプロセス１２４では、サーバディス
パッチャがコピーアプリプロセス１１２からジョブ動作
モード設定関数コールを受信して、ジョブ動作モード設
定関数ハンドラによってコピージョブに上述のジョブ動
作モードを設定して関数戻り値をコピーアプリプロセス
１１２のクライアントディスパッチャへ送信する。ま
た、サーバディスパッチャはジョブスタート要求関数コ
ールを受信して、ジョブスタート要求関数ハンドラによ
ってジョブの開始処理を行って関数戻り値をコピーアプ
リプロセス１１２のクライアントディスパッチャへ送信
する。

【０２１３】コピーアプリプロセス１１２のクライアン
トディスパッチャは、ＥＣＳプロセス１２４からジョブ
動作モード設定関数とジョブスタート要求関数の戻り値
をそれぞれ受信し、スレッド１がクライアントディスパ
ッチャ経由でジョブ動作モード設定関数の戻り値を受信
し、スレッド２もクライアントディスパッチャ経由でジ
ョブスタート要求関数の戻り値を受信する。

【０２１４】ＥＣＳプロセス１２４では、ジョブスター
ト要求関数の戻り値をコピーアプリプロセス１１２に送
信すると、つぎにスキャン画像を格納するためのメモリ
を確保するために、スレッド３においてＭＣＳプロセス
１２５に対し必要なサイズを指定したメモリ確保要求関
数コールを行い（ステップＳ９０４）、関数戻り待ち状
態となる。また、これと並行してスレッド４において、
スキャナエンジンとプリンタエンジンの資源獲得のた
め、ＳＲＭプロセス１２３に対して資源獲得要求関数コ
ールを行い（ステップＳ９０６）、関数戻り待ち状態と
なる。

【０２１５】ＭＣＳプロセス１２５では、サーバディス
パッチャがメモリ確保要求関数コールを受信すると、メ
モリ確保要求関数ハンドラによって指定されたサイズの
メモリ上の領域を確保し、関数戻り値をＥＣＳプロセス
１２４に送信する。一方、ＳＲＭプロセス１２３では、
サーバディスパッチャが資源獲得要求関数コールを受信
して資源獲得要求関数ハンドラにより、スキャナエンジ
ンとプリンタエンジンとを占有し、関数戻り値をＥＣＳ
プロセス１２４へ送信する。

【０２１６】ＥＣＳプロセス１２４のクライアントディ
スパッチャは、ＭＣＳプロセス１２５からメモリ確保要
求関数の戻り値を受信するとともに、ＳＲＭプロセス１
２３から資源獲得要求関数の戻り値を受信する。そし
て、スレッド３はクライアントディスパッチャ経由でメ
モリ確保要求関数の戻り値を受信し、スレッド４もクラ
イアントディスパッチャ経由で資源獲得要求関数の戻り
値を受信する。これにより、スレッド３とスレッド４は
関数戻り待ち状態を抜ける。

【０２１７】資源獲得要求関数の戻り値を受信してスキ
ャナエンジンとプリンタエンジンとをコピージョブで占
有すると、ＥＣＳプロセス１２４では、スレッド５にお
いてスキャナエンジンに対して原稿フィードインを行い
（ステップＳ９０７）、これによりコピー動作の原稿ス
キャン処理を開始する。

【０２１８】スキャナエンジンでは原稿のスキャン処理
が終了するとスキャン終了通知メッセージをＥＣＳプロ
セス１２４のスレッド５に送信し（ステップＳ９０
８）、プリンタエンジンによってスキャン画像のプリン
ト処理を開始する。そして、プリンタエンジンではスキ
ャン画像のプリント処理が終了すると、ＥＣＳプロセス
１２４のスレッド５に印刷終了通知メッセージを送信す
る（ステップＳ９１０）。

【０２１９】ＥＣＳプロセス１２４では、スレッド５が
スキャナエンジンからスキャン終了通知メッセージを受
信すると、コピーアプリプロセス１１２に対しスキャン
終了の旨のジョブエンド通知メッセージを送信する（ス
テップＳ９０９）。また、スレッド５がプリンタエンジ
ンから印刷終了通知メッセージを受信すると、コピーア
プリプロセス１１２に対し印刷終了の旨のジョブエンド
通知メッセージを送信する（ステップＳ９１１）。

【０２２０】コピーアプリプロセス１１２では、クライ
アントディスパッチャが２つのジョブエンド通知メッセ
ージを受信して、メッセージハンドラを起動してスレッ
ド２に各ジョブエンド通知メッセージを通知する。これ
により、原稿１ページ分のコピー動作が完了する。

【０２２１】複数枚の原稿のコピーを行う場合には、さ
らにＥＣＳプロセス１２４に対しジョブスタート要求関
数コールを行うと（ステップＳ９１２）、上述と同様の
動作がＥＣＳプロセス１２４、ＭＣＳプロセス１２５、
ＳＲＭプロセス１２３、スキャナエンジンおよびプリン
タエンジンで行われる（ステップＳ９１３〜Ｓ９１
６）。すべての原稿のコピーが終了し、コピーアプリプ
ロセス１１２が最後のジョブエンド通知メッセージを受
信すると（ステップＳ９１７）、スレッド１はＥＣＳプ
ロセス１２４に対しジョブクローズ要求関数コールを行
う（ステップＳ９１８）。

【０２２２】ＥＣＳプロセス１２４では、サーバディス
パッチャによりこのジョブクローズ要求関数コールを受
信してジョブクローズ要求関数ハンドラによってオープ
ン状態にあるコピージョブをクローズし、その関数戻り
値をコピーアプリプロセス１１２に送信する。

【０２２３】コピーアプリプロセス１１２では、クライ
アントディスパッチャによって、ジョブクローズ要求関
数の戻り値を受信し、戻り待ち状態となっているスレッ
ド２がクライアントディスパッチャ経由でジョブクロー
ズ要求関数の戻り値を受信し、コピー動作が完了する。

【０２２４】ここで、上述したコピー動作中に、スキャ
ン要求をスキャナアプリプロセス１１４が受信した場合
には、次のような処理が行われる。たとえば、コピー動
作においてＥＣＳプロセス１２４からＳＲＭプロセス１
２３に対しスキャナエンジンとプリンタエンジンの資源
獲得要求関数コールを行った後に、スキャナアプリプロ
セス１１４にスキャン要求があった場合を考える。

【０２２５】この場合、上述した図７におけるスキャナ
動作において、ＥＣＳプロセス１２４からＳＲＭプロセ
ス１２３に対しスキャナエンジンの資源獲得要求関数コ
ールが行われるが、スキャナエンジンがコピージョブで
占有されているため、スキャナジョブで獲得することが
できない。

【０２２６】このためスキャナジョブでは資源獲得要求
関数の戻り値のＥＣＳプロセス１２４に対する送信を、
コピージョブが完了し、スキャナエンジンが解放された
後で行う。この間、スキャナジョブにおいて資源獲得要
求関数コールを行ったスレッドは、関数戻り待ち状態と
なって待機していることになり、スキャナ動作がコピー
動作完了まで中断されることになる。また、コピー動作
中に、コピージョブでプリンタエンジンの占有がされた
後に、プリンタアプリプロセス１１１にプリント要求が
あった場合にも、同様に、コピー動作完了までプリント
動作は中断されることになる。

【０２２７】なお、コピー動作中のスキャナ動作につい
て、スキャナジョブでスキャナエンジンの獲得ができな
い場合の例をあげて説明したが、この他、スキャナジョ
ブにおいてＥＣＳプロセス１２４からＭＣＳプロセス１
２５に対し、ページ生成要求関数コールを行ったとき
に、コピージョブにおいてメモリ使用中のため、メモリ
不足でぺージ生成をできないような場合にも、ページ生
成要求関数コールを行ったスレッドが関数戻り待ち状態
となって、コピー動作完了までスキャナ動作が中断す
る。

【０２２８】次に、実施の形態１の複合機で行われるフ
ァクシミリ送信動作において、ファックスアプリ１１
３、ＦＣＳ１２７、ＥＣＳ１２４、ＭＣＳ１２５、ＳＲ
Ｍ１２３のプロセス間通信について具体的に説明する。
図１１は、実施の形態１の複合機でコピー動作を行う場
合のファックスアプリ、ＦＣＳ、ＥＣＳ、ＭＣＳ、ＳＲ
Ｍの各プロセス間のデータシーケンスを示す説明図であ
る。また、図１２は、各プロセス間の関数およびメッセ
ージの送受信の関係を示す説明図である。

【０２２９】図１２に示すように、複合機１００にはフ
ァックスアプリプロセス１１３、ＦＣＳプロセス１２
７、ＦＣＵＨプロセス１２９、ＥＣＳプロセス１２４、
ＭＣＳプロセス１２５およびＳＲＭプロセス１２３が動
作している。これらプロセスは、複合機１００の起動時
に生成されるようになっている。なお、図１２にはファ
ックス送信動作において使用されるプロセスのみを図示
しており、実際には他のアプリプロセスおよび他のコン
トロールサービスのプロセスも複合機の起動時に生成さ
れる。

【０２３０】ファックスアプリプロセス１１３は、複合
機１００の起動時に起動され、図１２に示すようにプロ
セス内に複数のスレッドが起動している。ファックスア
プリプロセス１１３は、ＦＣＳプロセス１２７をサーバ
プロセスとしたクライアントプロセスとなっており、こ
のためＦＣＳプロセス１２７に対するクライアントディ
スパッチャのスレッドが起動している。

【０２３１】ＦＣＳプロセス１２７は、ファクシミリ送
信動作時には、ファックスアプリプロセス１１３をクラ
イアントプロセスとしたサーバプロセスとなるととも
に、ＥＣＳプロセス１２４およびＦＣＵＨプロセス１２
９をサーバプロセスとしたクライアントプロセスとな
る。このため、ＦＣＳプロセス１２７内にはファックス
アプリプロセス１１３に対するサーバディスパッチャの
スレッドと、ＥＣＳプロセス１２４に対するクライアン
トディスパッチャのスレッドと、ＦＣＵＳプロセス１２
９に対するクライアントディスパッチャのスレッドと、
その他ファクシミリ通信制御に関する処理を行う複数の
スレッドが動作している。

【０２３２】ＦＣＵＨプロセス１２９は、ＦＣＳプロセ
ス１２７のサブプロセスであり、ファクシミリ送信動作
時に、ＳＲＭプロセス１２３およびＦＣＳ１２７をクラ
イアントプロセスとしたサーバプロセスとなる。このた
め、ＦＣＵＨプロセス１２９内にはＳＲＭプロセス１２
３およびＦＣＳ１２７に対するサーバディスパッチャの
スレッドと、その他ファクシミリデバイスドライバに対
する指令などの処理を行う複数のスレッドが動作してい
る。

【０２３３】ＥＣＳプロセス１２４は、ファクシミリ送
信動作時には、ＦＣＳプロセス１２７をクライアントプ
ロセスとしたサーバプロセスとなるとともに、ＭＣＳプ
ロセス１２５およびＳＲＭプロセス１２３をそれぞれサ
ーバプロセスとしたクライアントプロセスとなる。この
ため、ＥＣＳプロセス１２４内にはＦＣＳプロセス１２
７に対するサーバディスパッチャのスレッドと、ＭＣＳ
プロセス１２５に対するクライアントディスパッチャの
スレッドと、ＳＲＭプロセス１２３に対するクライアン
トディスパッチャのスレッドとその他ジョブ制御および
エンジン制御に関する処理を行う複数のスレッドが動作
している。

【０２３４】ＭＣＳプロセス１２５は、ファクシミリ送
信動作時には、ＥＣＳプロセス１２４をクライアントプ
ロセスとしたサーバプロセスとなるとともに、ＳＲＭプ
ロセス１２３をサーバプロセスとしたクライアントプロ
セスとなる。このため、ＭＣＳプロセス１２５内にはＥ
ＣＳプロセス１２４に対するサーバディスパッチャのス
レッドと、ＳＲＭプロセス１２３に対するクライアント
ディスパッチャのスレッドと、その他メモリ制御および
ハードディスク制御に関する処理を行う複数のスレッド
が動作している。

【０２３５】ＳＲＭプロセス１２３は、ＥＣＳプロセス
１２４およびＭＣＳプロセス１２５をクライアントプロ
セスとしたサーバプロセスとなるとともに、ＦＣＵＨプ
ロセス１２９をサーバプロセスとしたクライアントプロ
セスとなる。このため、ＳＲＭプロセス１２３内にはＥ
ＣＳプロセス１２４およびＭＣＳプロセス１２５に対す
るサーバディスパッチャのスレッドと、ＦＣＵＨプロセ
ス１２９をサーバプロセスとしたクライアントディスパ
ッチャと、その他エンジン資源制御に関する処理を行う
複数のスレッドが動作している。

【０２３６】実施の形態１におけるファックスアプリ１
１３では、送信スタート要求関数コールを行う処理、送
信モード変更要求を行う処理をそれぞれ一スレッドとし
ている。ＦＳＣプロセス１２７では、ファックス送信動
作時におけるジョブ動作モード設定関数コールとジョブ
スタート要求関数コールを行う一連の処理、スキャンパ
ラメータ要求メッセージを受信してスキャンパラメータ
を送信する処理、ＥＯＭ（次ページ有り），ＥＯＦ（次
ページ無し）などの次ページ情報メッセージを通知する
処理をそれぞれ一スレッドとしている。

【０２３７】ＥＣＳプロセス１２４では、メモリ確保要
求関数コールと資源獲得要求関数コールを行う一連の処
理、スキャン・フィードインプロセス生成指示メッセー
ジを送信する処理をそれぞれ一スレッドとしている。Ｍ
ＣＳプロセス１２５では、メモリ確保要求関数コールを
行う処理、その他メッセージを送信する処理を一スレッ
ドとしている。

【０２３８】ＳＲＭプロセス１２３では、フィードスタ
ートメッセージとフィードイン終了メッセージとスタン
プ実行指示メッセージを送信する一連の処理、スキャン
・フィードインプロセス実行処理をそれぞれ一スレッド
としている。ＦＣＵＨ１２９では、ＥＯＭ，ＥＯＦなど
の次ページ情報メッセージを送信する処理を一スレッド
としている。なお、ファクシミリ送信動作時において
も、これら各スレッドにおける処理は一例であり、各プ
ログラムで任意に定めることができる。

【０２３９】ファクシミリ送信要求があると、ファック
スアプリプロセス１１３は、新たなファクシミリ送信ジ
ョブを生成し、スレッド１からＦＣＳプロセス１２７に
対して送信スタート要求関数コールを行い（ステップＳ
１１０１）、スレッド１が関数戻り待ち状態となる。Ｆ
ＣＳプロセス１２７では、サーバディスパッチャがファ
ックスアプリプロセス１１３から送信スタート要求関数
コールを受信して、送信スタート要求関数ハンドラを起
動し、送信スタート要求関数ハンドラのスレッド３によ
ってＭＣＳプロセス１２５に対してジョブ動作モード設
定要求関数コールを行い（ステップＳ１１０２）、スレ
ッド３が関数戻り待ち状態となる。

【０２４０】ＥＣＳプロセス１２４では、サーバディス
パッチャがＦＣＳプロセス１２７からジョブ動作モード
設定要求関数コールを受信して、ジョブ動作モード設定
要求関数ハンドラによってファクシミリ送信ジョブに上
述の動作モードを設定して関数戻り値をＦＣＳプロセス
１２７のクライアントディスパッチャへ送信する。

【０２４１】ＦＣＳプロセス１２７のクライアントディ
スパッチャは、ＥＣＳプロセス１２４からジョブ動作モ
ード設定要求関数の戻り値を受信し、スレッド３はクラ
イアントディスパッチャ経由でこの戻り値を受信する。
これにより、スレッド３は関数戻り待ち状態を抜け、つ
いでＥＣＳプロセス１２４に対しジョブスタート要求関
数コールを行い（ステップＳ１１０３）、スレッド３は
関数戻り待ち状態となる。

【０２４２】このジョブスタート要求関数コールを受信
したＭＣＳプロセス１２５は、ジョブスタート要求関数
ハンドラによって、ＭＣＳ１２５に対しメモリ確保要求
関数コールを行い（ステップＳ１１０４）、ＳＲＭプロ
セス１２３に対し資源獲得要求関数コールを行う（ステ
ップＳ１１０６）。これらの関数コールを受信したＭＣ
Ｓプロセス１２５、ＳＲＭプロセス１２３の処理および
ＥＣＳプロセス１２４における各関数の戻り値の受信に
伴う処理は、コピー動作時の処理と同様であるので説明
を省略する。

【０２４３】ＥＣＳプロセス１２４では、スキャナエン
ジンの資源獲得関数の戻り値を受信したら、スレッド７
においてＦＣＳプロセス１２７に対しスキャナパラメー
タ確定要求メッセージを送信する（ステップＳ１１０
７）。ここで、スキャナパラメータとは、たとえばファ
イン、ノーマルなどのスキャン濃度や原稿サイズ等であ
る。ＦＣＳプロセス１２７では、このスキャナパラメー
タ確定要求メッセージを受信すると、スレッド４におい
てスキャナパラメータをＥＣＳプロセス１２４に対して
メッセージとして送信する（ステップＳ１１０８）。

【０２４４】ＥＣＳプロセス１２４では、スキャナパラ
メータメッセージをサーバディスパッチャが受信して、
スキャンパラメータ確定要求メッセージを送信したスレ
ッド７に通知し、スレッド７はＳＲＭプロセス１２３に
対してスキャン・フィードインプロセスの生成指示メッ
セージを送信する（ステップＳ１１０９）。ＳＲＭプロ
セス１２３は、スキャン・フィードインプロセスの生成
指示メッセージを受信すると、スレッド１１によりスキ
ャン・フィードインプロセスを生成して実行させる（ス
テップＳ１１１０）。

【０２４５】ついでＦＣＵＨプロセス１２９に対して原
稿のフィードインスタートメッセージを送信する（ステ
ップＳ１１１１）。ＦＣＵＨプロセス１２９がフィード
インスタートメッセージを受信して、原稿フィードイン
が開始され、これにより原稿のスキャンおよび指定宛先
への送信が開始する。

【０２４６】原稿のスキャンが開始されると、次ページ
の原稿があるか否かを示す、次ページ原稿有無通知メッ
セージがスキャナエンジンからＥＣＳプロセスに対して
送信される。図１１の例では、次ページ原稿有通知メッ
セージが通知されている（ステップＳ１１１２）。そし
て、原稿のスキャンを終了すると、スキャナエンジンか
らＥＣＳプロセス１２４に対してスキャン終了メッセー
ジが送信される（ステップＳ１１１３）。

【０２４７】ＥＣＳプロセス１２４は、受信したスキャ
ン終了メッセージを次ページ原稿有の旨とともにＦＣＳ
プロセス１２７へ送信する（ステップＳ１１１４）。一
方、原稿スキャンが終了すると、ＳＲＭプロセス１２３
はＦＣＵＨプロセス１２９に対してフィードイン終了を
指示し（ステップＳ１１１５）、これにより原稿フィー
ドインが終了する。

【０２４８】ここで、ファックスアプリプロセス１１３
がＦＣＳプロセス１２７に対して送信モード変更要求関
数コールを行った場合には（ステップＳ１１０５）、Ｅ
ＣＳプロセス１２４は、スレッド６においてスキャンパ
ラメータ確定要求メッセージをＦＣＳプロセス１２７に
対して送信し、これに対し上述のようにＦＣＳプロセス
１２７は、スキャンパラメータメッセージをＥＣＳプロ
セス１２４に送信する（ステップＳ１１１８）。ＥＣＳ
プロセス１２４では、スキャンパラメータメッセージを
受信すると、次ページ目のスキャン・フィードインプロ
セスの実行をＳＲＭプロセス１２３に指示して、実行が
開始する（ステップＳ１１１９、Ｓ１１２０）。

【０２４９】一方、１ページの指定宛先へのファクシミ
リ送信が完了すると、ＦＣＳプロセス１２７は、スレッ
ド５においてＥＯＭメッセージ（異なる送信モードで次
ページ有り）をＦＣＵＨプロセス１２９へ送信し（ステ
ップＳ１１２１）、これを受信したＦＣＵＨプロセス１
２９はスレッド１３によりＥＯＭを指定宛先へ送信する
（ステップＳ１１２２）。

【０２５０】ＦＣＵＨプロセス１２９が指定宛先から受
信正常の通知を受けた場合には（ステップＳ１１２
３）、ＳＲＭプロセス１２３に対して送信成功メッセー
ジを送信し（ステップＳ１１２４）、これを受信したＳ
ＲＭプロセス１２３はＥＣＳプロセス１２４に対してプ
ロセス正常終了メッセージを送信する（ステップＳ１１
２５）。さらにこれを受信したＥＣＳプロセス１２４は
ＦＣＳプロセス１２７に対し１ページ目のスキャン処理
完了通知メッセージを送信する（ステップＳ１１２
６）。そして、送信成功メッセージを受信したＳＲＭプ
ロセス１２３は指示により、送信日時、発信元等のスタ
ンプを指定宛先へ送信する旨をスキャナエンジンに指示
する（ステップＳ１１２７）。

【０２５１】ＳＲＭプロセス１２３は、２ページ目の原
稿のフィードインを開始するため、ＦＣＵＨプロセス１
２９に対して原稿のフィードインスタートメッセージを
送信する（ステップＳ１１２８）。ＦＣＵＨプロセス１
２９はフィードインスタートメッセージを受信して、原
稿フィードインが開始され、これにより２ページ目の原
稿のスキャンおよび指定宛先への送信が開始する。

【０２５２】原稿のスキャンが開始されると、次ページ
原稿有無通知メッセージがスキャナエンジンからＥＣＳ
プロセスに対して送信され、図１１の例では、次ページ
原稿有無通知メッセージが通知され、ＥＣＳプロセス１
２４のスレッド９に通知されている（ステップＳ１１２
９）。そして、原稿のスキャンが終了すると、スキャナ
エンジンからＥＣＳプロセス１２４に対してスキャン終
了メッセージが送信される（ステップＳ１１３０）。

【０２５３】ＥＣＳプロセス１２４のスレッド９は、受
信したスキャン終了メッセージを次ページ原稿無の旨と
ともにＦＣＳプロセス１２７へ送信する（ステップＳ１
１３１）。一方、スキャンが終了すると、ＳＲＭプロセ
ス１２３ではスレッド１３がＦＣＵＨプロセス１２９に
対してフィードイン終了を指示し（ステップＳ１１３
２）、これにより原稿フィードインが終了する。

【０２５４】２ページの指定宛先へのファクシミリ送信
が完了すると、ＦＣＳプロセス１２７では、スレッド５
がＥＯＦメッセージ（次ページ無し）をＦＣＵＨプロセ
ス１２９へ送信し（ステップＳ１１２４）、これを受信
したＦＣＵＨプロセス１２９はスレッド１３によりＥＯ
Ｆを指定宛先へ送信する。

【０２５５】ＦＣＵＨプロセス１２９が指定宛先から受
信正常の通知を受けた場合には（ステップＳ１１３
５）、スレッド１３によりＳＲＭプロセス１２３に対し
て送信成功メッセージを送信し（ステップＳ１１３
６）、これを受信したＳＲＭプロセス１２３は、スレッ
ド１２によりＥＣＳプロセス１２４に対してプロセス正
常終了メッセージを送信する（ステップＳ１１３７）。

【０２５６】さらにこれを受信したＥＣＳプロセス１２
４は、スレッド９によりＦＣＳプロセス１２７に対し２
ページ目のスキャン処理完了通知メッセージを送信する
（ステップＳ１１３８）。また、送信成功メッセージを
受信したＳＲＭプロセス１２３は、スレッド１２によ
り、送信日時、発信元等のスタンプの指定宛先へ送信の
指示を行う（ステップＳ１１３９）。

【０２５７】そして、ＥＣＳプロセス１２４は、ＦＣＳ
プロセス１２７にジョブエンド通知メッセージを送信し
（ステップＳ１１４０）、ＦＣＳプロセス１２７では、
このジョブエンド通知メッセージをクライアントディス
パッチャで受信することにより全ての原稿のファックス
送信動作が完了する。

【０２５８】このように、実施の形態１の複合機では、
各アプリプロセスなどクライアントとなるプロセスが、
ＥＣＳプロセス、ＭＣＳプロセス、ＳＲＭプロセスなど
のサーバとなるプロセスに対し、関数コールによってサ
ービスを要求し、またメッセージの送受信を行うことで
プロセス間通信を実現することができる。このため、ア
プリケーション１３０とプラットホーム１２０という特
殊な構成を有する複合機において、複合サービスという
多種多様な機能を実現することができる。

【０２５９】また、実施の形態１の複合機では、関数コ
ールによるサービス要求の結果としての関数戻り値をク
ライアントディスパッチャにより監視して受信すること
により、プロセス内のスレッド間の同期制御を容易に行
うことができる。このため、アプリプロセス、複数のコ
ントロールサービスの一部のモジュールのみに変更があ
る場合でも、関数コールとその関数戻り値の制御を確実
に設計しておけば他のプロセスとのインタフェースの変
更は不要となるので、各アプリごと、各コントロールサ
ービスごとの機能変更などに対応することが容易に行
え、複合機の構成に可変性を持たせることが可能とな
る。

【０２６０】さらに、実施の形態１の複合機では、スレ
ッドにより並列実行を可能としながら、スレッドに親和
性のある関数コールとその関数戻り値の制御によりプロ
セス間通信におけるスレッド間の同期制御を行っている
ので、並列処理の切り替え時のオーバヘッドを極力少な
くして、複合サービス提供時の処理速度を向上させるこ
とができる。（実施の形態２）実施の形態１にかかる複合機１００で
は、サーバプロセスとクライアントプロセスとの関係を
概念的に説明した。そこで、この実施の形態２では、サ
ーバプロセスおよびクライアントプロセスをより具体的
に説明する。なお、実施の形態２にかかる複合機１００
の構成は、図１と同様であるため説明を省略する。

【０２６１】図１３は、実施の形態２の複合機１００上
で動作するサーバプロセスとクライアントプロセスの関
係を詳細に示すブロック図である。ここで、クライアン
トプロセス１６００は、サーバプロセス１６１０，１６
２０に対して要求を行うことにより、サーバプロセス１
６１０，１６２０からサービスの提供を受ける例えばＳ
ＣＳ１２２などのプロセスをいう。また、サーバプロセ
ス１６１０，１６２０は、クライアントプロセス１６０
０からの要求によりクライアントプロセス１６００に対
しサービスを提供する例えばＥＣＳ１２４などのプロセ
スをいう。

【０２６２】図１３に示すとおり、クライアントプロセ
ス１６００には複数のスレッド１６０１が起動してい
る。クライアントプロセス１６００は、複数のスレッド
１６０１を有することから、複数のサーバプロセス１６
１０，１６２０に対して同時にサービスを要求できる。

【０２６３】また、クライアントプロセス１６００は、
サーバプロセス１６１０，１６２０のサービスを要求す
るために、スレッド１６０１からサーバプロセス１６１
０，１６２０に対して関数コールを行い、その関数戻り
値を受信することによってプロセス間通信を行う。

【０２６４】クライアントプロセス１６００のスレッド
１６０１は、あらかじめサーバプロセス１６１０，１６
２０から提供されている関数をコールする。関数は、ク
ライアントスタブ１６０２に定義されている。また、ク
ライアントディスパッチャ１６０３は関数戻り値の受信
を監視するスレッドである。

【０２６５】クライアントプロセス１６００は、サーバ
プロセス１６１０，１６２０ごとにクライアントディス
パッチャ１６０３を起動してサーバプロセス１６１０，
１６２０と通信する。そして、関数コールを受けたサー
バプロセス１６１０，１６２０は要求された関数に対応
する処理を以下のように実行する。

【０２６６】例えばサーバプロセス１６１０のサーバデ
ィスパッチャ１６１１は、サーバスケルトン１６１２に
コーディングされている複数のスレッド１６１３から、
要求された関数に対応するスレッド１６１３を選択す
る。ここで選択されるスレッド１６１３は、実施の形態
１で説明した関数ハンドラ４０３に相当する。サーバプ
ロセス１６１０のスレッド１６１３は、要求された処理
を実行してその実行結果を関数戻り値としてクライアン
トプロセス１６００に送信する。

【０２６７】次に、実施の形態２にかかるクライアント
プロセス１６００と、サーバプロセス１６１０，１６２
０とを生成する生成方法について説明する。図１４は、
実施の形態２のクライアントプロセスとサーバプロセス
とを生成する画像形成装置用通信プログラム生成装置
（以下、「スタブジェネレータ」という。）の機能的構
成を示すブロック図である。スタブジェネレータは、メ
ッセージファイルからヘッダと、クライアントスタブ
と、サーバスケルトンを自動生成するものである。

【０２６８】図１４に示すように、スタブジェネレータ
は、メッセージファイル１７０１を入力する入力部１７
０２と、メッセージファイル１７０１に記述された内容
の構文チェックを行う構文解析部１７０３と、メッセー
ジファイル１７０１の記述内容から、ヘッダ１７０６と
クライアントスタブ１７０７と、サーバスケルトン１７
０５とを生成してハードディスク等の記憶媒体に格納す
るコード生成部１７０４とを備えている。

【０２６９】まず、スタブジェネレータに入力されるメ
ッセージファイル１７０１と、スタブジェネレータで生
成されるヘッダ１７０６、クライアントスタブ１７０７
およびサーバスケルトン１７０５について説明する。

【０２７０】メッセージファイル１７０１は、プロセス
間通信の通信内容をＣ言語などのソースコードで記述し
たソースファイルである。図１５は、メッセージファイ
ルの記述例を示す説明図である。図１５に示すように、
メッセージファイル１７０１には、別のメッセージファ
イルや、Ｃ言語記述のインクルードヘッダを宣言するイ
ンクルード宣言と、サーバプロセスとクライアントプロ
セスの間で送受信するメッセージを記述したメッセージ
記述と、クライアントプロセスからサーバプロセスに対
して発行する関数の宣言などが記述されている。

【０２７１】メッセージは、主としてサーバプロセスと
クライアントプロセスとの間でイベントや通知を行う際
に発行するものであり、メッセージファイル１７０１の
メッセージ記述としては、メッセージ名と、メッセージ
ＩＤと、メッセージ方向、メッセージ内容を記述するよ
うになっている。

【０２７２】メッセージ方向には、「ＩＮ」、「ＯＵ
Ｔ」、「ＳＥＬＦ」がある。「ＩＮ」は、クライアント
プロセスからサーバプロセスに対して送信するメッセー
ジを意味する。「ＯＵＴ」は、サーバプロセスからクラ
イアントプロセスに対して送信するメッセージを意味す
る。また、「ＳＥＬＦ」は自分自身のプロセスに対して
送信するメッセージを意味する。

【０２７３】関数は、クライアントプロセスからサーバ
プロセスに処理要求や設定要求を行う際に発行するもの
である。メッセージファイル１７０１の関数宣言には、
関数名と、関数の型と、引数のみを記述し、関数の処理
内容は記述しないようになっている。

【０２７４】クライアントスタブ１７０７は、クライア
ントプログラムから呼び出される関数のサーバプロセス
に対する発行を記述したソースファイルである。クライ
アントスタブ１７０７をコンパイルしてライブラリ化
し、クライアントプログラムとリンクすることにより、
クライアントプログラムからの関数コールがクライアン
トスタブ１７０７を介してサーバプロセスへ発行される
ようになっている。

【０２７５】図１６はスタブジェネレータにより生成さ
れるクライアントスタブ１７０７の一例を示す説明図で
ある。図１６に示すように、クライアントスタブ１７０
７には、後述するサーバスケルトン１７０５に登録され
た関数ハンドラを呼び出すことにより、関数コールが行
われるようになっている。サーバスケルトン１７０５
は、クライアントスタブ１７０７から呼び出された関数
ハンドラとメッセージハンドラを登録したソースファイ
ルである。

【０２７６】図１７は、スタブジェネレータにより生成
されるサーバスケルトン１７０５の一例を示す説明図で
ある。図１７に示すように、サーバスケルトン１７０５
にはクライアントスタブ１７０７に記述された関数に対
応した関数ハンドラが登録されている。

【０２７７】関数ハンドラでは引数の受け渡し部のみが
記述され、処理内容を記述する実装記述部は空欄の状態
で生成されている。この実装記述部には、クライアント
プログラムからクライアントスタブ１７０７を介して発
行される関数の処理内容を、サーバプログラムの開発者
が自在に記述できるようになっている。ヘッダ１７０６
は、サーバスケルトン１７０５とクライアントスタブ１
７０７で共通の定義、宣言などを記述したソースファイ
ルである。

【０２７８】図１８はスタブジェネレータにより生成さ
れるヘッダ１７０６の一例を示す説明図である。図１８
に示すように、ヘッダ１７０６には、メッセージファイ
ル１７０１に記述されたインクルード宣言、メッセージ
ＩＤ、メッセージの構造体などのメッセージ宣言、関数
宣言および関数ハンドラ宣言などが記述された状態で生
成されるようになっている。

【０２７９】次に、スタブジェネレータによるサーバス
ケルトン１７０５、クライアントスタブ１７０７および
ヘッダ１７０６の生成処理について説明する。図１９
は、サーバスケルトン、クライアントスタブおよびヘッ
ダの生成処理のフローチャートである。

【０２８０】スタブジェネレータの構文解析部１７０３
は、メッセージファイル１７０１に記述された関数宣
言、メッセージ定義、インクルード宣言、Ｃ言語記述の
文法チェックを行い（ステップＳ１８０１）、さらにメ
ッセージファイル１７０１に定義されている関数名およ
びメッセージ定義の中のメッセージＩＤ、メッセージ名
の一意性の判断を行う（ステップＳ１８０２）。

【０２８１】そして、関数宣言、メッセージ定義、イン
クルード宣言の記述に文法エラーがあった場合、あるい
は関数名、メッセージＩＤ、メッセージ名のいずれかが
重複している場合には、ユーザに構文エラーである旨の
メッセージを通知し処理を終了する（ステップＳ１８０
３、Ｓ１８０４）。

【０２８２】構文解析後、コード生成部１７０４は、メ
ッセージファイル１７０１の記述内容から、ヘッダ１７
０６と、サーバスケルトン１７０５と、クライアントス
タブ１７０７を生成する。具体的には、メッセージファ
イル１７０１のインクルード宣言とＣ言語記述とをヘッ
ダ１７０６にそのまま転記し、メッセージファイル１７
０１のメッセージ定義に記述されているメッセージ構造
体をヘッダ１７０６にコピーする（ステップＳ１８０
５）。

【０２８３】また、コード生成部１７０４は、メッセー
ジファイル１７０１の関数宣言から関数ハンドラ名を自
動生成し（例えば、関数名ａｂｃの場合、関数ハンドラ
名をａｂｃ＿ｈａｎｄｌｅｒとして生成する）、生成さ
れた関数ハンドラ名をサーバスケルトン１７０５内に登
録する。

【０２８４】そして、関数ハンドラの処理内に、引数受
け渡しの記述を行うとともに、戻り値領域の生成システ
ムコールの発行を記述する。関数ハンドラの実際の処理
内容を記述する実装記述部の欄を空欄とし、その実装記
述部の後に、戻り値送信と戻り値領域解放の各システム
コールの発行を記述する（ステップＳ１８０６）。

【０２８５】また、コード生成部１７０４は、メッセー
ジファイル１７０１に記述された関数宣言ごとに、関数
名と引数の記述をクライアントスタブ１７０７に登録
し、その関数の処理内に、関数コールメッセージ生成コ
ールと関数ハンドラの呼び出しと戻り値解放の各システ
ムコールを記述する（ステップＳ１８０７）。なお、関
数ハンドラ呼び出しには、発行した関数の戻り値の待ち
受ける関数戻り値待ちシステムコールが内部的に発行さ
れるようになっている。

【０２８６】このようにスタブジェネレータにより、ク
ライアントスタブ１７０７とサーバスケルトン１７０５
とヘッダ１７０６を生成したら、次にサーバオブジェク
トおよびクライアントオブジェクトを完成させる。

【０２８７】サーバプログラムの開発者は、サーバスケ
ルトン１７０５の関数ハンドラの実装記述部（空欄）
に、関数ハンドラで行うべき処理内容をエディタなどを
利用して記述し、サーバスケルトン１７０５をヘッダ１
７０６とともにコンパイルしてサーバスタブオブジェク
トを生成する。また、サーバスケルトン１７０５に登録
した関数ハンドラを宣言するとともに、クライアントプ
ロセスとの間でメッセージファイル１７０１に記述され
たメッセージの送受信を行うメッセージハンドラ、エラ
ー処理を行うエラーハンドラ、サーバの初期化、サーバ
ディスパッチャ起動等のシステムコールの発行を記述し
たサーバソースファイルを作成してコンパイルし、サー
バスタブオブジェクトとリンクして、サーバプログラム
を完成させる。

【０２８８】一方、クライアントスタブ１７０７はヘッ
ダ１７０６とともにコンパイルしてクライアントスタブ
オブジェクトを生成する。サーバプロセスごとにクライ
アントスタブオブジェクトを生成し、生成した複数のク
ライアントスタブオブジェクトをライブラリとする。

【０２８９】また、関数の発行、関数ハンドラの宣言、
エラー処理を行うエラーハンドラの宣言、クライアント
プロセスとの間でメッセージファイル１７０１に記述さ
れたメッセージの送受信を行うメッセージハンドラ、お
よびクライアントプロセスの初期化やクライアントディ
スパッチャ起動等のシステムコールの発行を記述したク
ライアントプログラムを作成してコンパイルし、スタブ
のライブラリとリンクすることによりクライアントプロ
グラムを完成させる。

【０２９０】図２０は、クライアントプログラムから関
数コールを行った場合におけるサーバプログラムとの呼
び出しおよび応答のシーケンスを示す説明図である。な
お、サーバプログラムとクライアントプログラムは実際
は実行可能形式のオブジェクトファイルであるが、図２
０では、説明の都合上いずれもソースコードで表示して
いる。

【０２９１】クライアントプログラムからサーバプログ
ラムに対して、たとえばＯｐｅｎ関数をコールすると、
クライアントスタブオブジェクトで定義されたＯｐｅｎ
が呼び出される（ステップＳ１９０１）。そして、この
スタブのＯｐｅｎの処理の中で、Ｏｐｅｎの関数ハンド
ラＯｐｅｎ＿ｈａｎｄｌｅｒがサーバプログラムに対し
てコールされる（ステップＳ１９０２）。

【０２９２】サーバプログラムでは、クライアントスタ
ブオブジェクトから関数ハンドラＯｐｅｎ＿ｈａｎｄｌ
ｅｒの発行を受け取って、サーバスタブオブジェクトに
登録されているＯｐｅｎ＿ｈａｎｄｌｅｒの実装記述部
に記述されている処理を実行し（ステップＳ１９０
３）、その実行結果をクライアントスタブへ戻り値とし
て返す（ステップＳ１９０４）。クライアントプログラ
ムでは、この戻り値をクライアントスタブから受け取っ
て（ステップＳ１９０５）、次の処理へ移行する。

【０２９３】このように実施の形態２のスタブジェネレ
ータでは、メッセージファイル１７０１に関数宣言を記
述することによりクライアントスタブ１７０７とサーバ
スケルトン１７０５を容易に生成することができる。し
かも生成されるサーバスケルトン１７０５の実装記述部
は空欄となっているので、プログラム開発者は必要に応
じて関数の処理内容を容易に変更するができる。

【０２９４】このため複合機１００に可変性をもたせる
ことができるとともに、多種多様な機能を実現させるこ
とができる。さらに、サードベンダーなどの他社がクラ
イアントプログラムの開発を行う場合でも、クライアン
トプログラムには提供される関数コールを記述するだけ
でプロセス間通信が可能となるので、内部の通信プロト
コルの隠蔽性を保つことが可能となる。

【０２９５】また、実施の形態２のスタブジェネレータ
では、プロセス間通信を関数コールで実現しているの
で、ジョブの並列実行をスレッドで実現した場合でも、
高速なプロセス間通信が可能となる。また、関数からの
戻り値によってスレッド間の同期をとることができるの
で、同期のための処理プログラムを別途作成する必要が
なくなり、プログラム開発の労力を低減することができ
る。（実施の形態３）実施の形態１にかかる複合機１０
０は、クライアントプロセスとなるアプリプロセスが、
サーバプロセスとなる各コントロールサービスと同一複
合機内部で動作していた。この実施の形態３にかかる複
合機１００は、ネットワークに接続された他の複合機の
アプリプロセスをクライアントプロセスとして各コント
ロールサービスがサービスを提供するものである。

【０２９６】図２１は、実施の形態３にかかる複合機の
構成を示すブロック図である。図２１に示すように、実
施の形態３では複数の複合機１３００ａ，１３００ｂが
ＬＡＮなどのネットワーク１３４０によって接続された
構成となっている。なお、図２１では、２台の複合機１
３００ａ，１３００ｂがネットワーク１３４０で接続さ
れた構成となっているが、３台以上の複合機をネットワ
ーク１３４０で接続した構成でもよい。

【０２９７】図２１に示すように、ネットワーク１３４
０上の各複合機１３００ａ，１３００ｂは、実施の形態
１の複合機と同様の構成となっている。このため、これ
らの構成について詳細な説明は省略する。

【０２９８】実施の形態３の複合機では、実施の形態１
と同様に、主としてコピーアプリ１３１２、プリンタア
プリ１３１１、スキャナアプリ１３１４、ファックスア
プリ１３１３などのアプリケーションのプロセス、およ
びＥＣＳ１３２４、ＭＣＳ１３２５、ＦＣＳ１３２７、
ＮＣＳ１３２８などのコントロールサービスのプロセス
が、コントロールサービスまたはＳＲＭ１３２３をサー
バプロセスとしたクライアントプロセスとなるが、さら
にネットワークに接続された他の複合機内部で動作して
いるＥＣＳ１３２４、ＭＣＳ１３２５、ＦＣＳ１３２
７、ＮＣＳ１３２８などのコントロールサービスをサー
バプロセスとしたクライアントプロセスとなる。

【０２９９】また、実施の形態３の複合機では、実施の
形態１と同様に、主としてＥＣＳ１３２４、ＭＣＳ１３
２５、ＦＣＳ１３２７、ＮＣＳ１３２８などのコントロ
ールサービスおよびＳＲＭ１３２３のプロセスが、アプ
リケーションのプロセスまたはコントロールサービスも
しくはＳＲＭ１３２３のプロセスをクライアントプロセ
スとしたサーバプロセスとなるが、さらにネットワーク
に接続された他の複合機内部で動作しているコピーアプ
リ１３１２、プリンタアプリ１３１１、スキャナアプリ
１３１４、ファックスアプリ１３１３などのアプリケー
ションのプロセスをクライアントプロセスとしたサーバ
プロセスにもなる。

【０３００】実施の形態３の複合機におけるこれらサー
バプロセスとクライアントプロセスの関係、およびサー
バプロセス、クライアントプロセスの各構成は実施の形
態１の複合機で説明した図２および図３と同様であるの
で詳細な説明は省略する。

【０３０１】各コントロールサービスとＳＲＭ１３２３
と各アプリとは、実施の形態１の複合機１００と同様
に、それぞれプロセスとして汎用ＯＳ上に生成されて実
行される。各プロセス内部には、複数のスレッドが起動
され、汎用ＯＳの管理下でこれらのスレッドのＣＰＵ占
有時間を切り替えることにより並列実行が実現されてい
る。

【０３０２】また、実施の形態３の複合機１３００ａ，
１３００ｂでは、アプリケーションなどのクライアント
プロセスは、コントロールサービスなどのサーバプロセ
スのサービスを要求するために、クライアントプロセス
内のスレッドからサーバプロセスに対して関数コールを
行い、その関数戻り値を受信すること、およびスレッド
からメッセージをサーバプロセスに送信することによっ
てプロセス間通信を行う。そして、さらにネットワーク
上の他の複合機で動作するサーバプロセスに対して関数
コールおよびメッセージの送信も行えるようになってい
る。

【０３０３】一方、コントロールサービスなどのサーバ
プロセスでは、クライアントプロセスに対するプロセス
間通信はメッセージの送信のみで行われる。さらにサー
バプロセスでは、ネットワーク上の他の複合機で動作す
るプロセスをクライアントプロセスとして、このネット
ワーク上のクライアントプロセスに対してメッセージの
送信も可能となっている。

【０３０４】クライアントプロセスで起動されるクライ
アントディスパッチャは実施の形態１の複合機１００と
同様の構成をしており、さらにネットワーク１３４０に
接続された他の複合機からの関数戻り値およびＯＵＴ方
向のメッセージの受信も監視している。

【０３０５】このため、ネットワーク上の他の複合機の
プロセスとプロセス間通信を行えるように、クライアン
トプロセスから発行する関数の形式およびメッセージの
形式は、ネットワークアドレスなどの情報を指定できる
ような形式で提供される。

【０３０６】サーバプロセスで起動されるサーバディス
パッチャも、実施の形態１の複合機１００におけるサー
バプロセスと同様の構成をしているが、さらにネットワ
ーク１３４０に接続された他の複合機で動作するクライ
アントプロセスのスレッドからの関数コールおよびＩＮ
方向のメッセージも監視している。

【０３０７】サーバプロセスでは、関数コールをサーバ
ディスパッチャで受信したときに実行される関数ハンド
ラが、ネットワーク１３４０上のクライアントプロセス
に関数戻り値を返すために、関数コールしたプロセスの
存在する複合機のネットワークアドレスなどを指定でき
るようになっている。また、サーバプロセスから送信す
るメッセージもネットワークアドレスなどを指定できる
ようになっている。

【０３０８】次に、このように構成された実施の形態３
にかかる複合機１３００ａ，１３００ｂにおいて、ネッ
トワーク１３４０上の異なる複合機を利用してプリント
動作を行う場合のプロセス間通信について説明する。図
２２は、実施の形態３のネットワークに接続された２つ
の複合機を利用してプリンタ動作を行う場合のプリンタ
アプリ、ＥＣＳのプロセス間のデータシーケンスを示す
説明図である。

【０３０９】プリンタアプリプロセス１３１１が印刷要
求を受信した場合には（ステップＳ１４０１）、実施の
形態１において図５を用いて説明したとおり、複合機１
３００ａのプリンタアプリプロセス１３１１のスレッド
がＥＣＳプロセス１３２４に対して、ジョブ動作モード
設定関数コールとジョブスタート要求関数コールを順次
行う。

【０３１０】実施の形態３では、このとき、複合機１３
００ａのプリンタアプリプロセス１３１１が、ネットワ
ーク１３４０を介して接続された他の複合機１３００ｂ
のネットワークアドレスを指定し、ジョブ動作モード設
定関数コールとジョブスタート要求関数コールを行って
いる（ステップＳ１４０２、Ｓ１４０４）。

【０３１１】これにより、ジョブ動作モード設定関数コ
ール、ジョブスタート要求関数コールは、自己の複合機
１３００ａのＥＣＳプロセス１３２４ではなく、ネット
ワークアドレスで指定された複合機１３００ｂのＥＣＳ
プロセス１３２４に対して送信される。そして、それぞ
れの関数コールを行ったスレッドは関数戻り待ち状態に
なる。

【０３１２】複合機１３００ｂのＥＣＳプロセス１３２
４では、サーバディスパッチャがネットワーク１３４０
を介してジョブ動作モード設定関数コール、ジョブスタ
ート要求関数コールをそれぞれ受信し、各関数ハンドラ
によってプリンタジョブの動作モード設定、プリンタジ
ョブの開始処理を行う。そして、ジョブ動作モード設定
関数の戻り値およびジョブオープン関数の戻り値を、複
合機１３００ａのネットワークアドレスを指定して送信
する（ステップＳ１４０３、Ｓ１４０５）。

【０３１３】複合機１３００ａのプリンタアプリプロセ
ス１３１１では、クライアントディスパッチャによって
複合機１３００ｂのＥＣＳプロセス１３２４からのジョ
ブ動作モード設定関数の戻り値およびジョブオープン関
数の戻り値を受信する。そして、実施の形態１の複合機
と同様に、関数戻り待ち状態のスレッドを関数戻り待ち
キューから抽出して、ジョブ動作モード設定関数の戻り
値とジョブオープン関数の戻り値のそれぞれを抽出され
たスレッドに送信する。

【０３１４】これ以降のＥＣＳプロセス１３２４、ＭＣ
Ｓプロセス１３２５、ＳＲＭプロセス１２３との間のプ
ロセス間通信は同一複合機内部で行われるものであり、
実施の形態１で説明したプリンタ動作と同様である。こ
れにより、複合機１３００ａにおける印刷要求に対し
て、実際のプリント処理が複合機１３００ｂで行われる
ことになる。

【０３１５】複合機１３００ｂにおけるプリント処理が
終了すると、複合機１３００ｂのＥＣＳプロセス１３２
４はジョブエンド通知メッセージをプリンタアプリプロ
セスに送信する。このとき、ＥＣＳプロセス１３２４の
サーバディスパッチャは、ネットワーク１３４０上の複
合機１３００ａのネットワークアドレスを指定してジョ
ブエンド通知メッセージを送信する（ステップＳ１４０
６）。

【０３１６】複合機１３００ａのプリンタアプリプロセ
ス１３１１では、クライアントディスパッチャによっ
て、ネットワークを介して送信されてきたジョブエンド
通知メッセージを受信し、これによりプリンタ動作を完
了する。

【０３１７】このように、実施の形態３では、ネットワ
ークに接続された複合機１３００ａで動作するアプリプ
ロセスと、複合機１３００ｂで動作するＥＣＳプロセス
１３２４との間でプロセス間通信を行って、複合機１３
００ａで発生した要求に対しネットワーク１３４０上の
他の複合機１３００ｂでプリント処理を行えるので、要
求の生じた複合機のみならずネットワーク上の複合機を
利用して多種多様な機能を実現することができる。

【０３１８】例えば、複合機１３００ａで印刷要求が生
じたときに、複合機１３００ａのプリンタエンジンが他
のジョブに占有されている場合には、プリンタアプリプ
ロセスでこれを判断してＥＣＳプロセス１３２４に対す
る関数コールをネットワーク１３４０上の他の複合機１
３００ｂのＥＣＳプロセス１３２４への関数コールへ切
り替える等の処理を行えば、プリント開始までに時間を
要することを防止でき、ユーザビリティの向上を図るこ
とができる。

【０３１９】なお、実施の形態３では、プリンタ動作の
例をあげてネットワーク１３４０に接続された２つの複
合機１３００ａ，１３００ｂにおけるプロセス間通信に
ついて説明したが、スキャナ動作、コピー動作、ファク
シミリ送信動作においても、複合機１３００ａ内のスキ
ャナアプリプロセス１３１４、コピーアプリプロセス１
３１２、ファックスアプリプリセス１３１３と、ＥＣＳ
プロセス１３２４とのプロセス間通信もプリンタ動作の
場合と同様に行われる。

【０３２０】また、実施の形態３の複合機１３００ａ，
１３００ｂでは、アプリプロセスとＥＣＳプロセス１３
２４とネットワーク１３４０を介したプロセス間通信に
説明したが、アプリプロセスとＥＣＳプロセス１３２４
以外のコントロールサービスおよびシステムリソースマ
ネージャ（ＳＲＭ）１３２３のプロセス間通信も、アプ
リプロセスとＥＣＳプロセス１３２４間の通信と同様に
行われる。

【０３２１】さらに、実施の形態３の複合機１３００
ａ，１３００ｂでは、アプリプロセスとネットワーク１
３４０上の別の複合機内のＥＣＳプロセス１３２４とが
直接プロセス間通信を行っているが、ＮＣＳ１３２８を
介して異なる複合機のアプリプロセスとＥＣＳプロセス
１３２４とが通信を行うように構成しても良い。

【０３２２】すなわち、ＮＣＳ１３２８において、アプ
リプロセスからの関数コールやメッセージを一旦受信し
て、ネットワーク１３４０上の他の複合機１３００ｂの
ネットワークアドレスを指定した上で、関数コールやメ
ッセージを複合機１３００ｂのＮＣＳプロセス１３２８
へ送信するように構成することも可能である。

【０３２３】この場合には、アプリプロセスやＥＣＳプ
ロセス１３２４において、ネットワークアドレスに関す
る処理の追加が不要となり、モジュール間の独立性がよ
り高まるので、複合機により可変性を持たせることがで
きるという利点がある。（実施の形態４）実施の形態３にかかる複合機１３００
ａ，１３００ｂでは、ネットワーク１３４０に接続され
た他の複合機のアプリプロセスをクライアントプロセス
として各コントロールサービスがサービスを提供してい
た。この実施の形態４にかかる複合機は、ネットワーク
に接続された他の複合機のコントロールサービスをクラ
イアントプロセスとして、各コントロールサービスがサ
ービスを提供するものである。

【０３２４】実施の形態４では、図２１に示す実施の形
態３の複合機１３００ａ，１３００ｂと同様に、複数の
複合機がＬＡＮなどのネットワーク１３４０によって接
続された構成となっている。実施の形態４におけるネッ
トワーク１３４０上の各複合機１３００ａ，１３００ｂ
は、実施の形態１の複合機と同様の構成であるため、こ
れらの構成について詳細な説明は省略する。

【０３２５】実施の形態４の複合機では、実施の形態１
と同様に、主としてコピーアプリ１３１２、プリンタア
プリ１３１１、スキャナアプリ１３１４、ファックスア
プリ１３１３などのアプリケーションプロセス、および
ＥＣＳ１３２４、ＭＣＳ１３２５、ＦＣＳ１３２７、Ｎ
ＣＳ１３２８などのコントロールサービスのプロセス
が、コントロールサービスまたはＳＲＭ１３２３をサー
バプロセスとしたクライアントプロセスとなるが、さら
にネットワークに接続された他の複合機内部で動作して
いるＥＣＳ１３２４、ＭＣＳ１３２５、ＦＣＳ１３２
７、ＮＣＳ１３２８などのコントロールサービスをサー
バプロセスとしたクライアントプロセスとなる。

【０３２６】また、実施の形態４の複合機では、実施の
形態１と同様に、主としてＥＣＳ１３２４、ＭＣＳ１３
２５、ＦＣＳ１３２７、ＮＣＳ１３２８などのコントロ
ールサービスおよびＳＲＭ１３２３のプロセスが、アプ
リケーションサービスまたはコントロールサービスもし
くはＳＲＭ１３２３をクライアントプロセスとしたサー
バプロセスとなるが、さらにネットワークに接続された
他の複合機内部で動作しているコントロールサービスを
クライアントプロセスとしたサーバプロセスにもなる。

【０３２７】実施の形態４の複合機１３００ａ，１３０
０ｂにおけるこれらサーバプロセスとクライアントプロ
セスの関係、およびサーバプロセス、クライアントプロ
セスの各構成は実施の形態１の複合機で説明した図２お
よび図３、および実施の形態３と同様であるので詳細な
説明は省略する。

【０３２８】実施の形態４の複合機１３００ａ，１３０
０ｂでは、コントロールサービスがクライアントプロセ
スとなる場合に、他のコントロールサービスなどのサー
バプロセスのサービスを要求するために、クライアント
プロセス内のスレッドからサーバプロセスに対して関数
コールを行い、その関数戻り値を受信すること、および
スレッドからメッセージをサーバプロセスに送信するこ
とによってプロセス間通信を行う。そして、さらにネッ
トワーク１３４０上の他の複合機で動作する他のコント
ロールサービスまたはＳＲＭ１３２３などのサーバプロ
セスに対して関数コールおよびメッセージの送信も行え
るようになっている。

【０３２９】コントロールサービスなどのクライアント
プロセスで起動されるクライアントディスパッチャは、
実施の形態３の複合機１３００ａ，１３００ｂと同様
に、ネットワーク１３４０に接続された他の複合機で動
作するコントロールサービスまたはＳＲＭ１３２３（サ
ーバプロセス）からの関数戻り値およびＯＵＴ方向のメ
ッセージの受信も監視している。

【０３３０】このため、ネットワーク１３４０上の他の
複合機のプロセスとプロセス間通信を行えるように、ク
ライアントプロセスから発行する関数の形式およびメッ
セージの形式は、ネットワークアドレスなどの情報を指
定できるような形式で提供される。

【０３３１】サーバプロセスで起動されるサーバディス
パッチャも、実施の形態３の複合機１３００ａ，１３０
０ｂにおけるサーバプロセスと同様に、ネットワーク１
３４０に接続された他の複合機で動作するクライアント
プロセスのスレッドからの関数コールおよびＩＮ方向の
メッセージも監視している。

【０３３２】実施の形態４においても、サーバプロセス
およびクライアントプロセスとなるＥＣＳ１３２４、Ｍ
ＣＳ１３２５、ＦＣＳ１３２７、ＮＣＳ１３２８などの
コントロールサービスおよびＳＲＭ１３２３では、関数
コールをサーバディスパッチャで受信したときに実行さ
れる関数ハンドラが、関数コールしたクライアントプロ
セスの存在する複合機のネットワークアドレスなどを指
定できるようになっている。また、サーバプロセスから
送信するメッセージもネットワークアドレスなどを指定
できるようになっている。

【０３３３】次に、このように構成された実施の形態４
にかかる複合機１３００ａ，１３００ｂにおいて、ネッ
トワーク１３４０上の異なる複合機を利用してファクシ
ミリ送信動作を行う場合のプロセス間通信について説明
する。図２３は、実施の形態４のネットワークに接続さ
れた２つの複合機を利用してファクシミリ送信動作を行
う場合のＦＣＳとＥＣＳとＭＣＳのプロセス間のデータ
シーケンスを示す説明図である。

【０３３４】ＦＣＳプロセス１３２７がファックスアプ
リプロセス１３１３から送信スタート要求を受信した場
合には（ステップＳ１５０１）、複合機１３００ａのＦ
ＣＳプロセス１３２７のスレッドが、ネットワーク１３
４０に接続された他の複合機１３００ｂのネットワーク
アドレスを指定して、ジョブ動作モード設定関数コール
とジョブスタート要求関数コールを順次行う（ステップ
Ｓ１５０２、Ｓ１５０４）。

【０３３５】これにより、ジョブ動作モード設定関数コ
ール、ジョブスタート要求関数コールは、ネットワーク
アドレスで指定された複合機１３００ｂで動作するＥＣ
Ｓプロセス１３２４に対してネットワークを介して送信
される。

【０３３６】複合機１３００ｂのＥＣＳプロセス１３２
４では、サーバディスパッチャがネットワーク１３４０
を介してジョブ動作モード設定関数コール、ジョブスタ
ート要求関数コールをそれぞれ受信し、各関数ハンドラ
によってプリンタジョブの動作モード設定、プリンタジ
ョブの開始処理を行う。そして、ジョブ動作モード設定
関数の戻り値およびジョブオープン関数の戻り値を、複
合機１３００ａのネットワークアドレスを指定して送信
する（ステップＳ１５０３、Ｓ１５０５）。

【０３３７】複合機１３００ａのＦＣＳプロセス１３２
７では、クライアントディスパッチャによって複合機１
３００ｂのＥＣＳプロセス１３２４からのジョブ動作モ
ード設定関数の戻り値およびジョブオープン関数の戻り
値を受信する。そして、実施の形態１の複合機と同様
に、関数戻り待ち状態のスレッドを関数戻り待ちキュー
から抽出して、ジョブ動作モード設定関数の戻り値とジ
ョブオープン関数の戻り値のそれぞれを抽出されたスレ
ッドに送信する。

【０３３８】複合機１３００ｂのＥＣＳプロセス１３２
４は、ＭＣＳプロセス１３２５に対してメモリ確保要求
関数コールを行い（ステップＳ１５０５）、またＳＲＭ
プロセス１２３に対してスキャナエンジンの資源獲得要
求関数コールを行う（ステップＳ１５０６）。かかる関
数コールに対するＭＣＳプロセス１３２５およびＳＲＭ
プロセス１３２３の処理は、実施の形態１で説明したと
おりである。

【０３３９】複合機１３００ｂのＥＣＳプロセス１３２
４では、スキャナエンジンの資源獲得関数の戻り値を受
信したら、複合機１３００ａのネットワークアドレスを
指定したスキャンパラメータ要求メッセージを、複合機
１３００ａのＦＣＳプロセス１３２７にネットワークを
介して送信する（ステップＳ１５０７）。

【０３４０】複合機１３００ａのＦＣＳプロセス１３２
７では、このスキャナパラメータ確定要求メッセージを
受信すると、スキャナパラメータのメッセージを、複合
機１３００ｂのネットワークアドレスを指定することに
より、複合機１３００ｂのＥＣＳプロセス１３２４に対
してネットワークを介して送信する（ステップＳ１５０
８）。ＥＣＳプロセス１３２４では、サーバディスパッ
チャがスキャナパラメータメッセージをネットワークを
介して受信する。

【０３４１】これ以降のプロセス間通信は、同一複合機
１３００ｂ内部で行われるものであり、実施の形態１で
説明したファクシミリ送信と同様である。これにより、
複合機１３００ａにおけるファクシミリ送信スタート要
求に対して、複合機１３００ｂでファクシミリ送信が行
われることになる。複合機１３００ｂにおけるスキャン
およびファクシミリ送信処理が終了すると、複合機１３
００ｂのＥＣＳプロセス１３２４のサーバディスパッチ
ャは、ネットワーク１３４０上の複合機１３００ａのネ
ットワークアドレスを指定してスキャン終了通知メッセ
ージを複合機１３００ａのＦＣＳプロセス１３２７に送
信する（ステップＳ１５０９）。

【０３４２】複合機１３００ａのＦＣＳプロセス１３２
７では、クライアントディスパッチャによって、ネット
ワーク１３４０を介して送信されてきたスキャン終了通
知メッセージを受信し、これによりファクシミリ送信動
作を完了する。

【０３４３】このように、実施の形態４の複合機では、
ネットワークに接続された複合機１３００ａで動作する
ＦＣＳプロセス１３２７と、複合機１３００ｂで動作す
るＥＣＳプロセス１３２４との間でプロセス間通信を行
って、複合機１３００ａで発生した要求に対しネットワ
ーク１３４０上の他の複合機１３００ｂでファクシミリ
送信処理を行えるので、要求の生じた複合機のみならず
ネットワーク１３４０上の複合機を利用して多種多様な
機能を実現することができる。

【０３４４】例えば、複合機１３００ａでファクシミリ
送信要求が生じたときに、複合機１３００ａのファクシ
ミリエンジンがファクシミリ受信ジョブに占有されてい
る場合には、ＦＣＳプロセス１３２７でこれを判断して
ＥＣＳプロセス１３２４に対する関数コールをネットワ
ーク１３４０上の他の複合機１３００ｂのＥＣＳプロセ
ス１３２４への関数コールへ切り替える等の処理を行え
ば、ファクシミリ送信を直ちに行うことができ、複合機
のユーザビリティの向上を図ることができる。

【０３４５】なお、実施の形態４では、ファクシミリ送
信動作の例をあげてネットワーク１３４０に接続された
２つの複合機１３００ａ，１３００ｂにおけるプロセス
間通信について説明したが、スキャナ動作、コピー動
作、プリント動作においても、複合機１３００ａ内のコ
ントロールサービスと複合機１３００ｂ内のコントロー
ルサービスのプロセス間通信も同様に行われる。

【０３４６】また、実施の形態４の複合機では、ＦＣＳ
プロセス１３２７とＥＣＳプロセス１３２４とのネット
ワーク１３４０を介したプロセス間通信に説明したが、
他のコントロールサービス間のネットワーク１３４０を
介したプロセス間通信も、ＦＣＳプロセス１３２７とＥ
ＣＳプロセス１３２４の通信と同様に行われる。

【０３４７】さらに、実施の形態４の複合機では、ＦＣ
Ｓアプリプロセス１３２７とネットワーク１３４０上の
別の複合機内のＥＣＳプロセス１３２４とが直接プロセ
ス間通信を行っているが、この場合も、ＮＣＳプロセス
１３２８を介して異なる複合機のコントロールサービス
間の通信を行うように構成しても良い。

【０３４８】以上、実施の形態１〜４の複合機において
使用した関数、メッセージはすべて一例であり、とくに
これらに限定されるものではなく、任意の関数やメッセ
ージを定義して使用することができる。

【０３４９】

【発明の効果】以上説明したように、発明によれば、ユ
ーザサービス及びコントロールサービスの間の独立性を
維持しながら互いにサービスやデータの授受をプロセス
間通信によって行うことができ、多種多様な機能を実現
することが可能である。

【図面の簡単な説明】

【図１】この発明の実施の形態の画像形成装置（複合
機）の構成を示すブロック図である。

【図２】実施の形態１の複合機におけるサーバプロセス
とクライアントプロセスの関係を示すブロック図であ
る。

【図３】実施の形態１の複合機で動作するクライアント
プロセスの構成を示すブロック図である。

【図４】実施の形態１の複合機で動作するサーバプロセ
スの構成を示すブロック図である。

【図５】実施の形態１の複合機でプリンタ動作を行う場
合のアプリケーション、コントロールサービスおよびシ
ステムリソースサービスの各プロセス間のデータシーケ
ンスを示す説明図である。

【図６】実施の形態１の複合機でプリンタ動作を行う場
合のアプリケーション、コントロールサービスおよびシ
ステムリソースサービスの各プロセス間の関数およびメ
ッセージの送受信の関係を示す説明図である。

【図７】実施の形態１の複合機でスキャナ動作を行う場
合のアプリケーション、コントロールサービスおよびシ
ステムリソースサービスの各プロセス間のデータシーケ
ンスを示す説明図である。

【図８】実施の形態１の複合機でスキャナ動作を行う場
合のアプリケーション、コントロールサービスおよびシ
ステムリソースサービスの各プロセス間の関数およびメ
ッセージの送受信の関係を示す説明図である。

【図９】実施の形態１の複合機でコピー動作を行う場合
のアプリケーション、コントロールサービスおよびシス
テムリソースサービスの各プロセス間のデータシーケン
スを示す説明図である。

【図１０】実施の形態１の複合機でコピー動作を行う場
合のアプリケーション、コントロールサービスおよびシ
ステムリソースサービスの各プロセス間の関数およびメ
ッセージの送受信の関係を示す説明図である。

【図１１】実施の形態１の複合機でファクシミリ送信動
作を行う場合のアプリケーション、コントロールサービ
スおよびシステムリソースサービスの各プロセス間のデ
ータシーケンスを示す説明図である。

【図１２】実施の形態１の複合機でファックス送信動作
を行う場合のアプリケーション、コントロールサービス
およびシステムリソースサービスの各プロセス間の関数
およびメッセージの送受信の関係を示す説明図である。

【図１３】実施の形態２の複合機１００上で動作するサ
ーバプロセスとクライアントプロセスの関係を詳細に示
すブロック図である。

【図１４】実施の形態２のクライアントプロセスとサー
バプロセスとを生成する画像形成装置用通信プログラム
生成装置（スタブジェネレータ）の機能的構成を示すブ
ロック図である。

【図１５】メッセージファイルの記述例を示す説明図で
ある。

【図１６】スタブジェネレータにより生成されるクライ
アントスタブの一例を示す説明図である。

【図１７】スタブジェネレータにより生成されるサーバ
スケルトンの一例を示す説明図である。

【図１８】スタブジェネレータにより生成されるヘッダ
の一例を示す説明図である。

【図１９】サーバスケルトン、クライアントスタブおよ
びヘッダの生成処理のフローチャートである。

【図２０】クライアントプログラムから関数コールを行
った場合におけるサーバプログラムとの呼び出しおよび
応答のシーケンスを示す説明図である。

【図２１】実施の形態２にかかる複合機の構成を示すブ
ロック図である。

【図２２】実施の形態２のネットワークに接続された２
つの複合機を利用してプリンタ動作を行う場合のプリン
タアプリとＥＣＳプロセス間のデータシーケンスを示す
説明図である。

【図２３】実施の形態３のネットワークに接続された２
つの複合機を利用してファクシミリ送信動作を行う場合
のＦＣＳとＥＣＳとＭＣＳのプロセス間のデータシーケ
ンスを示す説明図である。

【符号の説明】

１００，１３００ａ，１３００ｂ複合機１０１，１３０１白黒ラインプリンタ１０２，１３０２カラーラインプリンタ１０３，１３０３スキャナ１０４，１３０４ファクシミリ１１０，１３１０ソフトウェア群１１１，１３１１プリンタアプリ１１２，１３１２コピーアプリ１１３，１３１３ファックスアプリ１１４，１３１４スキャナアプリ１１５，１３１５ネットファイルアプリ１１６，１３１６工程検査アプリ１２０，１３２０プラットホーム１２１，１３２１汎用ＯＳ１２２，１３２２ＳＣＳ１２３，１３２３ＳＲＭ１２４，１３２４ＥＣＳ１２５，１３２５ＭＣＳ１２６，１３２６ＯＣＳ１２７，１３２７ＦＣＳ１２８，１３２８ＮＣＳ１２９，１３２９ＦＣＵＨ１３０，１３３０アプリケーション２０１，１６００クライアントプロセス２０２，１６１０，１６２０サーバプロセス２０３，１６０３クライアントディスパッチャ２０４，１６１１サーバディスパッチャ１６０１，１６１３，１６２３スレッド１６０２クライアントスタブ１６１２，１６２２サーバスケルトン

Claims

【特許請求の範囲】

【請求項１】画像形成処理で使用されるハードウェア
資源と、画像形成に係るユーザサービスおよびコントロ
ールサービスの処理を行う一または複数のプログラムと
を有する画像形成装置であって、前記ユーザサービスおよびコントロールサービスのそれ
ぞれは、サーバプロセスまたはクライアントプロセスと
して動作するプロセスであり、前記サーバプロセスは、前記クライアントプロセスに提
供する一または複数のサービスを定義した関数を有して
おり、前記クライアントプロセスは、前記サーバプロセスにサ
ービスの提供を要求する際に関数呼び出しを行うことを
特徴とする画像形成装置。
【請求項２】前記コントロールサービスは、前記ユー
ザサービスをクライアントプロセスとしたサーバプロセ
スとして動作して、前記ユーザサービスの少なくとも２
つが共通的に必要とするサービスを定義した関数を有
し、前記ユーザサービスは、前記コントロールサービスにサ
ービスの提供を要求する際に関数呼び出しを行うことを
特徴とする請求項１記載の画像形成装置。
【請求項３】前記コントロールサービスは、他のコン
トロールサービスをクライアントプロセスとしたサーバ
プロセスとして動作して、前記他のコントロールサービ
スの少なくとも２つが共通的に必要とするサービスを定
義した関数を有しており、前記他のコントロールサービスは、前記コントロールサ
ービスにサービスの提供を要求する際に関数呼び出しを
行うことを特徴とする請求項１又は２記載の画像形成装
置。
【請求項４】前記コントロールサービスは、前記サー
バプロセスとして動作するとともに前記クライアントプ
ロセスとして動作することを特徴とする請求項１乃至３
いずれか一項記載の画像形成装置。
【請求項５】前記ユーザサービスおよび前記コントロ
ールサービスの各プロセスは、一または複数のスレッド
を含むことを特徴とする請求項１乃至４いずれか一項記
載の画像形成装置。
【請求項６】前記ユーザサービスおよび前記コントロ
ールサービスは、前記クライアントプロセスとして動作
するときに、前記サーバプロセスへの関数呼び出しに対
する関数戻り値の受信を監視し、受信した関数戻り値を
前記関数呼び出しを行ったスレッドに受け渡すクライア
ント監視手段を備えたことを特徴とする請求項５記載の
画像形成装置。
【請求項７】前記クライアント監視手段は、スレッド
で実現されることを特徴とする請求項６記載の画像形成
装置。
【請求項８】前記クライアント監視手段は、関数の呼
び出し後に関数戻り値待ち状態のスレッドの識別子を一
時的に格納する関数戻り待ちキューをさらに備え、前記
サーバプロセスから前記関数戻り値を受信したときに、
受信した関数戻り値を、前記関数戻り待ちキューに格納
された識別子の前記スレッドに送信することを特徴とす
る請求項６又は７記載の画像形成装置。
【請求項９】前記サーバプロセスおよび前記クライア
ントプロセスは、さらにイベントまたは通知に関するメ
ッセージの送信，受信または送受信の何れかを行うこと
を特徴とする請求項１乃至８いずれか一項記載の画像形
成装置。
【請求項１０】前記クライアント監視手段は、さらに
サーバプロセスからのメッセージの受信を監視するもの
であることを特徴とする請求項９記載の画像形成装置。
【請求項１１】前記クライアント監視手段は、受信し
たメッセージに基づいた処理を実行するメッセージハン
ドラをさらに備えたことを特徴とする請求項１０記載の
画像形成装置。
【請求項１２】前記サーバプロセスは、前記クライア
ントプロセスからの関数呼び出しを監視するサーバ監視
手段を備えたことを特徴とする請求項１乃至１１いずれ
か一項記載の画像形成装置。
【請求項１３】前記サーバ監視手段は、複数のクライ
アントプロセスからの関数呼び出しを監視することを特
徴とする請求項１２に記載の画像形成装置。
【請求項１４】前記サーバ監視手段は、前記クライア
ントプロセスから関数呼び出しを受信したときに、呼び
出された関数に対応した処理を実行する関数ハンドラを
備えたことを特徴とする請求項１２又は１３記載の画像
形成装置。
【請求項１５】前記サーバ監視手段は、さらにクライ
アントプロセスからのメッセージの受信を監視すること
を特徴とする請求項１２乃至１４いずれか一項記載の画
像形成装置。
【請求項１６】前記サーバ監視手段は、受信したメッ
セージに基づいた処理を実行するメッセージハンドラを
さらに備えたことを特徴とする請求項１５記載の画像形
成装置。
【請求項１７】画像形成処理で使用されるハードウェ
ア資源と、画像形成に係るユーザサービスおよびコント
ロールサービスの処理を行う一または複数のプログラム
とを有する画像形成装置であって、前記コントロールサービスは、ネットワークに接続され
た他の画像形成装置で動作するクライアントプロセスに
対するサーバプロセスとして動作し、サーバプロセスと
して前記他の画像形成装置のクライアントプロセスに提
供する一または複数のサービスを定義した関数を有して
いることを特徴とする画像形成装置。
【請求項１８】前記コントロールサービスの各プロセ
スは、前記他の画像形成装置のクライアントプロセスに
提供するサービスを実行する一または複数のスレッドを
備えたことを特徴とする請求項１７記載の画像形成装
置。
【請求項１９】前記コントロールサービスは、前記他
の画像形成装置のクライアントプロセスからの関数呼び
出しを監視するサーバ監視手段を備えたことを特徴とす
る請求項１７又は１８記載の画像形成装置。
【請求項２０】前記サーバ監視手段は、さらに前記他
の画像形成装置のクライアントプロセスからのメッセー
ジの受信を監視することを特徴とする請求項１９記載の
画像形成装置。
【請求項２１】前記コントロールサービスは、さらに
前記他の画像形成装置のクライアントプロセスに対しメ
ッセージを送信することを特徴とする請求項１７乃至２
０いずれか一項記載の画像形成装置。
【請求項２２】前記コントロールサービスは、前記他
の画像形成装置で動作するユーザサービスをクライアン
トプロセスとしたサーバプロセスとして動作することを
特徴とする請求項１７乃至２１いずれか一項記載の画像
形成装置。
【請求項２３】前記コントロールサービスは、前記他
の画像形成装置で動作するコントロールサービスをクラ
イアントプロセスとしたサーバプロセスとして動作する
ことを特徴とする請求項１７乃至２２いずれか一項記載
の画像形成装置。
【請求項２４】前記ユーザサービスは、前記他の画像
形成装置で動作するコントロールサービスをサーバプロ
セスとしたクライアントプロセスとして動作することを
特徴とする請求項１７乃至２３いずれか一項記載の画像
形成装置。
【請求項２５】前記コントロールサービスは、前記他
の画像形成装置で動作するコントロールサービスをサー
バプロセスとしたクライアントプロセスとして動作する
ことを特徴とする請求項１７乃至２４いずれか一項記載
の画像形成装置。