JP2006203654A - 画像形成装置、サービス機能分割統治方法およびサービス機能分割統治プログラム - Google Patents

Abstract

【課題】 複合機の構成に応じたジョブ管理サービス機能を容易に実現可能な画像形成装置、サービス機能分割統治方法およびサービス機能分割統治プログラムを提供することを目的とする。
【解決手段】 ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段１０１およびサブサービスファンクション手段１０２とに分け、サブサービスファンクション手段１０２は、動作状態となったときにマスタサービスファンクション手段１０１に登録要求を行うと共に、マスタサービスファンクション手段１０１から分配されるリクエストに応じた処理を行い、マスタサービスファンクション手段１０１は、リクエストのジョブ種別に対応付けられたサブサービスファンクション手段１０２にリクエストを分配することにより上記課題を解決する。
【選択図】 図６

Description

本発明は、画像形成装置、サービス機能分割統治方法およびサービス機能分割統治プログラムに係り、特に１つ以上のジョブを同時に処理する画像形成装置、サービス機能分割統治方法およびサービス機能分割統治プログラムに関する。

近年、プリンタ，コピー，ファクシミリ，スキャナ等の各装置の機能を１つの筐体内に収納した画像形成装置（以下、複合機という）が知られるようになった。複合機は１つの筐体内にプロッタ，スキャナ等を設けると共に、プリンタ，コピー，ファクシミリ，スキャナ等にそれぞれ対応するソフトウェアを設け、それらのソフトウェアを切り替えることより、プリンタ，コピー，ファクシミリ，スキャナ等として動作させるものである（例えば、特許文献１参照）。

複合機は、プリンタ，コピー，ファクシミリ，スキャナ等の各装置の機能を有しているため、同時に複数のジョブ（作業ジョブ）を管理する必要がある。これら複数のジョブを個別の機能毎に管理すると、ジョブの管理機構が分散し、複雑になる傾向があった。そこで、複合機ではジョブの処理および管理を行うサービスファンクション（以下、ＳＦという）を用意し、そのＳＦにより一括してジョブ管理サービス機能を提供していた。特許文献２及び３には、複数のアプリケーション又はドライバを統括して管理する内容が開示されている。
特開２００３−３４１１７５号公報 特開２０００−２５０７２１号公報 特開２００２−３３０２４６号公報

しかしながら、複合機におけるジョブは、ジョブ種別により管理の可能な管理対象が異なる。また、ジョブ種別は機器の構成に応じて変化する。この為、ＳＦは機器の全ての構成に対処できるように、使用される可能性のある全ての管理対象にジョブ及びジョブ種別を予め対応させておかなければならない。例えば蓄積機能の無い複合機であっても蓄積機能を追加する可能性があれば、ＳＦは蓄積ジョブに応じた処理及び管理を行うようにしておかなければならなかった。

本発明は、上記の点に鑑みなされたもので、複合機の構成に応じたジョブ管理サービス機能を容易に実現可能な画像形成装置、サービス機能分割統治方法およびサービス機能分割統治プログラムを提供することを目的とする。

上記の課題を解決するため、本発明の画像形成装置は、ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段およびサブサービスファンクション手段に分け、前記サブサービスファンクション手段は、動作状態となったときに前記マスタサービスファンクション手段に登録要求を行うと共に、前記マスタサービスファンクション手段から分配される前記リクエストに応じた処理を行い、前記マスタサービスファンクション手段は、前記リクエストのジョブ種別に対応付けられている前記サブサービスファンクション手段に前記リクエストを分配することを特徴とする。

また、本発明の画像形成装置は、ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段およびサブサービスファンクション手段に分け、前記サブサービスファンクション手段は、動作状態となったときに前記マスタサービスファンクション手段に登録要求を行うと共に、前記マスタサービスファンクション手段から分配される前記リクエストに応じた処理を行い、前記マスタサービスファンクション手段は、前記登録要求により登録されている前記前記サブサービスファンクション手段に前記リクエストを分配することを特徴とする。

また、本発明は、ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段およびサブサービスファンクション手段とに分けた画像形成装置のサービス機能分割統治方法であって、動作状態となったときに前記サブサービスファンクション手段が前記マスタサービスファンクション手段に登録要求を行う段階と、前記マスタサービスファンクション手段がリクエストのジョブ種別に対応付けられている前記サブサービスファンクション手段に前記リクエストを分配する段階と、前記サブサービスファンクション手段が前記マスタサービスファンクション手段から分配された前記リクエストに応じた処理を行う段階とを有することを特徴とする。

また、本発明は、ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段およびサブサービスファンクション手段とに分けた画像形成装置のサービス機能分割統治方法であって、動作状態となったときに前記サブサービスファンクション手段が前記マスタサービスファンクション手段に登録要求を行う段階と、前記マスタサービスファンクション手段が前記登録要求により登録されている前記サブサービスファンクション手段に前記リクエストを分配する段階と、前記サブサービスファンクション手段が前記マスタサービスファンクション手段から分配された前記リクエストに応じた処理を行う段階とを有することを特徴とする。

また、本発明は、ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段およびサブサービスファンクション手段とに分けた画像形成装置に、動作状態となったときに前記サブサービスファンクション手段が前記マスタサービスファンクション手段に登録要求を行う手順と、前記マスタサービスファンクション手段がリクエストのジョブ種別に対応付けられている前記サブサービスファンクション手段に前記リクエストを分配する手順と、前記サブサービスファンクション手段が前記マスタサービスファンクション手段から分配された前記リクエストに応じた処理を行う手順とを実行させるためのサービス機能分割統治プログラムであることを特徴とする。

また、本発明は、ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段およびサブサービスファンクション手段とに分けた画像形成装置に、動作状態となったときに前記サブサービスファンクション手段が前記マスタサービスファンクション手段に登録要求を行う手順と、前記マスタサービスファンクション手段が前記登録要求により登録されている前記サブサービスファンクション手段に前記リクエストを分配する手順と、前記サブサービスファンクション手段が前記マスタサービスファンクション手段から分配された前記リクエストに応じた処理を行う手順とを実行させるためのサービス機能分割統治プログラムであることを特徴とする。

本発明では、ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段およびサブサービスファンクション手段に分け、動作状態となったサブサービスファンクション手段をマスタサービスファンクション手段に登録することができるので、画像形成装置の構成に応じたジョブ管理サービス機能を実現できる。

また、本発明ではマスタサービスファンクション手段が、ジョブ種別に応じてリクエストをサブサービスファンクション手段に分配し、サブサービスファンクション手段がリクエストの処理を実行できる。また、本発明では、マスタサービスファンクション手段が登録されているサブサービスファンクションにリクエストを分配し、サブサービスファンクションで前記リクエストに応じた処理を行うか否かを判断することもできる。

本発明によれば、複合機の構成に応じたジョブ管理サービス機能を容易に実現可能な画像形成装置、サービス機能分割統治方法およびサービス機能分割統治プログラムを提供可能である。

次に、本発明を実施するための最良の形態を、以下の実施例に基づき図面を参照しつつ説明していく。なお、本実施例では画像形成装置の一例としてプリンタ，コピー，ファクシミリ，スキャナ等の各装置の機能を１つの筐体内に収納した複合機を一例として説明していくが、画像形成に係る処理を行う如何なる画像形成装置であってもよい。また、本実施例ではＳＦの一例としてジョブ管理サービス機能を提供するジョブ管理サービスのＳＦについて説明していくが、他のＳＦであってもよい。

図１は、本発明による複合機のソフトウェア構成について説明するための一実施例の構成図である。複合機１は、ソフトウェア群２と，起動部３と，ハードウェア資源４とを含むように構成される。

ハードウェア資源４は、プロッタ１１と，スキャナ１２と，ファクシミリなどのその他のハードウェアリソース１３とを含む。ソフトウェア群２は、ＵＮＩＸ（登録商標）などのオペレーティングシステム（以下、ＯＳという）上に起動されているアプリケーション層５とプラットフォーム６とを含む。

アプリケーション層５は、プリンタ，コピー，ファックスおよびスキャナなどの画像形成にかかる処理またはウェブサービスにかかる処理を行うプログラムを含む。図１のアプリケーション層５は、プリンタアプリ２１と，コピーアプリ２２と，ファックスアプリ２３と，スキャナアプリ２４と，ウェブサービスアプリ２５と，ウェブサービスファンクション（以下、ＷＳＦという）２６と，ＳＦ２７ａ〜２７ｎとを含む。ＳＦ２７ａ〜２７ｎのうちの何れかのＳＦを示す場合は、単に符号２７を用いる。

ＷＳＦ２６は、予め定義されている関数によりウェブサービスアプリ２５からのリクエストを受信可能とするアプリケーションプログラムインターフェース（以下、ＡＰＩという）２８を有する。また、ＳＦ２７は予め定義されている関数によりＷＳＦ２６からのリクエストを受信可能とするＡＰＩ２９を有する。

ＷＳＦ２６は、ウェブサービスアプリ２５からのリクエストを受信すると、そのリクエストをＳＦ２７に対するリクエストに変換する。ＷＳＦ２６はリクエストに応じて一つのＳＦ２７を選択し、選択したＳＦ２７にＡＰＩ２９経由でリクエストを送信する。ＳＦ２７はリクエストを受信すると、そのリクエストに応じた処理を行う。

プラットフォーム６は、アプリケーション層５からのリクエストを解釈してハードウェア資源４の獲得要求を発生するコントロールサービス層７と、ハードウェア資源４の管理を行ってコントロールサービス層７からの獲得要求を調停するＳＲＭ（システムリソースマネージャ）８とを含む。

コントロールサービス層７は、ＮＣＳ３１，ＤＣＳ３２，ＬＣＳ３３，ＦＣＳ３４，ＥＣＳ３５，ＭＣＳ３６，ＵＣＳ３７，ＳＣＳ３８など、一つ以上のサービスモジュールを含む。なお、プラットフォーム６は予め定義されている関数により、アプリケーション層５からのリクエストを受信するＡＰＩ５１を有するように構成されている。ＯＳは、アプリケーション層５およびプラットフォーム６の各ソフトウェアをプロセスとして並列実行する。

ＮＣＳ（ネットワークコントロールサービス）３１のプロセスは、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分ける際の仲介、又は各アプリケーションからのデータをネットワーク側に送信する際の仲介を行う。

ＤＣＳ（デリバリーコントロールサービス）３２のプロセスは、複合機１に蓄積されている文書データの配送などの制御を行う。ＬＣＳ（ログコントロールサービス）３３のプロセスは、操作履歴の記録等の操作を制御する。

ＦＣＳ（ファックスコントロールサービス）３４のプロセスは、アプリケーション層５からＰＳＴＮまたはＩＳＤＮ網を利用したファックスの送受信，バックアップ用のメモリで管理されている各種ファックスデータの登録又は引用，ファックスの読み取り，ファックスの受信印刷などを行うためのＡＰＩを提供する。

ＥＣＳ（エンジンコントロールサービス）３５のプロセスは、プロッタ１１，スキャナ１２，ハードウェアリソース１３などのエンジン部の制御を行う。ＭＣＳ（メモリコントロールサービス）３６のプロセスは、メモリの取得及び解放，ＨＤＤの利用，画像データの圧縮および伸張などの制御を行う。ＵＣＳ（ユーザ情報コントロールサービス）３７のプロセスは、ユーザ情報の管理を行うものである。

ＳＣＳ（システムコントロールサービス）３８のプロセスは、操作部の制御，システム画面の表示，ＬＥＤの表示，ハードウェア資源の管理，アプリケーションの管理，割り込みアプリケーションの制御などの処理を行う。

ＳＲＭ８のプロセスは、ＳＣＳ３８と共にシステムの制御およびハードウェア資源４の管理を行うものである。例えばＳＲＭ８のプロセスは、プロッタ１１やスキャナ１２などのハードウェア資源４を利用する上位層からの獲得要求に従って調停を行い、ハードウェア資源４の実行を制御する。

具体的に、ＳＲＭ８のプロセスは獲得要求されたハードウェア資源４が利用可能であるか（他の獲得要求により利用されていないか）を判定し、利用可能であれば獲得要求されたハードウェア資源４が利用可能である旨を上位層に通知する。ＳＲＭ８のプロセスは上位層からの獲得要求に対してハードウェア資源４を利用するためのスケジューリングを行い、リクエストの処理（プリンタエンジンによる紙搬送と作像動作，メモリの確保，ファイル生成など）を直接行っている。ＳＲＭ８は、予め定義されている関数によりハードウェア資源４に対するリクエストを送信するエンジンＩ／Ｆ５２を利用して、ハードウェア資源４に対するリクエストを行う。

図１の構成により、複合機１は各アプリケーションで共通的に必要な処理をプラットフォーム６で一元的に処理することができる。次に、複合機１のハードウェア構成について説明する。

図２は、本発明による複合機のハードウェア構成について説明するための一実施例の構成図である。図２の複合機１は、コントローラ６０，操作パネル８０，ＦＣＵ８１，エンジン部８２を有する。

コントローラ６０は、ＣＰＵ６１，システムメモリ６２，ＮＢ６３，ＳＢ６４，ＡＳＩＣ６６，ローカルメモリ６７，ＨＤＤ６８、ＮＩＣ６９，ＵＳＢ Ｉ／Ｆ７０，ＩＥＥＥ１３９４ Ｉ／Ｆ７１，セントロニクス Ｉ／Ｆ７２を有する。操作パネル８０は、コントローラ６０のＡＳＩＣ６６に接続されている。また、ＦＣＵ８１およびエンジン部８２はコントローラ６０のＡＳＩＣ６６にＰＣＩバス８３を介して接続されている。

コントローラ６０は、ＡＳＩＣ６６にローカルメモリ６７，ＨＤＤ６８などが接続されると共に、ＣＰＵ６１とＡＳＩＣ６６とがＣＰＵチップセットのＮＢ６３を介して接続されている。なお、ＡＳＩＣ６６とＮＢ６３とはＡＧＰ（Accelerated Graphics Port）６５を介して接続されている。

ＣＰＵ６１は、複合機１の全体制御を行うものである。図１の複合機１では、ＣＰＵ６１がコントロールサービス層７を形成する１つ以上のサービスモジュール、ＳＲＭ８をＯＳ上に起動させる。また、ＣＰＵ６１はアプリケーション層５を形成するプリンタアプリ２１，コピーアプリ２２，ファックスアプリ２３，スキャナアプリ２４，ウェブサービスアプリ２５，ＷＳＦ２６，ＳＦ２７ａ〜２７ｎを起動して実行させる。

ＮＢ（ノースブリッジ）６３は、ＣＰＵ６１，システムメモリ６２，ＳＢ６４，ＡＳＩＣ６６，ＮＩＣ６９，ＵＳＢ Ｉ／Ｆ７０，ＩＥＥＥ１３９４ Ｉ／Ｆ７１及びセントロニクス Ｉ／Ｆ７２を接続するためのブリッジである。ＮＢ６３は、ＳＢ６４，ＮＩＣ６９，ＵＳＢ Ｉ／Ｆ７０，ＩＥＥＥ１３９４ Ｉ／Ｆ７１及びセントロニクス Ｉ／Ｆ７２とＰＣＩバス７３を介して接続されている。なお、ＳＢ（サウスブリッジ）６４は、ＰＣＩバス７３とＲＯＭや周辺デバイス等とを接続するためのブリッジである。

システムメモリ６２は、描画用メモリ等として用いるメモリである。ローカルメモリ６７は、コピー用画像バッファ，符号バッファ等として用いるメモリである。ＡＳＩＣ６６は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。また、ＨＤＤ６８は画像データの蓄積，文書データの蓄積，プログラムの蓄積，フォントデータの蓄積，フォームの蓄積などを行うストレージ（補助記憶装置）の一例である。

ＮＩＣ（ネットワークインターフェースカード）６９は、複合機１をインターネットやＬＡＮ等のネットワークに接続するインターフェース機器である。また、ＵＳＢ Ｉ／Ｆ７０，ＩＥＥＥ１３９４ Ｉ／Ｆ７１およびセントロニクス Ｉ／Ｆ７２は、夫々の規格に準じたインターフェースである。操作パネル８０は、ユーザからの入力操作を受け付けると共に、ユーザに向けた表示を行う操作部である。なお、ＦＣＵ８１はバックアップ用のメモリを有している。ＦＣＵ８１が有するメモリは、例えば複合機１の電源がＯＦＦのときに受信したファクシミリデータを一時的に格納するために利用される。

図３は、ＳＦの一例の構成図である。図３のＳＦ２７は、一つのマスタＳＦ１０１，１つ以上のサブＳＦ１０２ａ〜１０２ｎを含む。サブＳＦ１０２ａ〜１０２ｎのうちの何れかのサブＳＦを示す場合は、単に符号１０２を用いる。ここでは、ジョブ管理サービスのＳＦ２７の例を説明する。

マスタＳＦ１０１は、ジョブ管理サービス機能に対するリクエストを受信する。マスタＳＦ１０１が受信するリクエストには、ジョブ種別やジョブが特定されたリクエストが含まれる。マスタＳＦ１０１は、ジョブ種別の全リスト、ジョブ種別とサブＳＦ１０２との対応を管理している。マスタＳＦ１０１は、ジョブ種別や特定のジョブ（以下、ジョブ種別と総称する）が対応する一つのサブＳＦ１０２に、受信したリクエストを分配する。なおマスタＳＦ１０１は、受信したリクエストがジョブ管理サービス全体に対するリクエストの場合、そのリクエストに応じた処理を行うこともある。

サブＳＦ１０２は、マスタＳＦ１０１からリクエストを受信すると、そのリクエストに応じた処理を行う。つまり、サブＳＦ１０２はジョブ管理サービスの処理を実装する。例えばジョブ管理サービスのＳＦ２７の場合、ジョブ種別のリストは図４のようになる。図４は、ジョブ種別と可能な操作との対応を表した一例の説明図である。また、図５はジョブの操作について説明する一例の説明図である。

例えば図４の「プリントジョブ」，「蓄積ジョブ」，「配信ジョブ」は、ジョブ種別を表している。プリントジョブは、印刷を行なうジョブ種別である。蓄積ジョブは、画像を装置内に格納する際の変換などを伴うジョブ種別である。配信ジョブは、装置の外部の適切な場所へ画像を転送するためのジョブ種別である。これらのジョブは、図１におけるアプリケーション層５あるいはコントロールサービス層７の適切なモジュールが保持する。

また、図４の「プリントジョブ」は、可能な操作として「生成」、「停止」、「再開」などが対応付けられている。図４に表されている操作は、図５のような内容である。例えば図５の「ジョブの生成」は、新たなジョブを生成する操作である。

図３のマスタＳＦ１０１及びサブＳＦ１０２について、図６を参照しつつ詳細に説明していく。図６は、マスタＳＦおよびサブＳＦの一例の構成図である。図６のマスタＳＦ１０１は、ＳＦ登録サーバ２０１と，ハンドラ処理部２０２と，ＳＦ管理オブジェクト２０３と，ＳＦ処理クライアント２０６と，リクエスト分配処理部２０７とを有する。ＳＦ管理オブジェクト２０３は、ＳＦプロセス管理リスト２０４と，サブＳＦ管理リスト２０５とを有する構成である。また、サブＳＦ１０２はＳＦ登録クライアント２１１と，ジョブ種別処理部２１２，２１３と，メソッド固有処理部２１４と，ＳＦ処理サーバ２１５とを有する。

例えば図４の「プリントジョブ」、「蓄積ジョブ」、「配信ジョブ」等は、ジョブ種別を表している。即ち、ジョブ管理サービスのＳＦ２７はジョブをジョブ種別毎に分類し、ジョブ種別毎にサブＳＦ１０２を対応付けている。

マスタＳＦ１０１とサブＳＦ１０２とは、プロセス間通信を利用して相互制御を行っている。マスタＳＦ１０１とサブＳＦ１０２との間のプロセス間通信には、登録用通信と処理用通信とが存在している。登録用通信は、サブＳＦ１０２のＳＦ登録クライアント２１１とマスタＳＦ１０１のＳＦ登録サーバ２０１との間で行われる。また、処理用通信はマスタＳＦ１０１のＳＦ処理クライアント２０６とサブＳＦ１０２のＳＦ処理サーバ２１５との間で行われる。

サブＳＦ１０２は、１つ以上のジョブ種別処理部２１２，２１３を実装できる。例えば登録用通信では、動作状態となったサブＳＦ１０２のＳＦ登録クライアント２１１がＳＦ登録サーバ２０１に対して、サポートするジョブ種別処理部２１２，２１３の数だけ登録要求を送信する。

ＳＦ登録サーバ２０１は、ライブラリから呼び出されるハンドラ処理部２０２で、登録要求を受信したサブＳＦ１０２の管理情報をＳＦ管理オブジェクト２０３に登録する。具体的に、ハンドラ処理部２０２はＳＦプロセス管理リスト２０４にサーバ名およびクライアント情報構造体を登録すると共に、そのＳＦプロセス管理リスト２０４に対応付けられたサブＳＦ管理リスト２０５にクライアントＩＤ，ジョブ種別，プロセスＩＤ，共有メモリサイズ，ジョブＩＤ，アクティブ状態を登録する。

例えば図６のサブＳＦ１０２から登録要求を送信すると、ハンドラ処理部２０２はＳＦプロセス管理リスト２０４にサーバ名「Ｓｅｒｖｅｒ１」、ＳＦ処理クライアント２０６のクライアント情報構造体を登録し、サブＳＦ管理リスト２０５にＳＦ処理クライアント２０６のクライアントＩＤ、ジョブ種別「ジョブ種別Ａ」，「ジョブ種別Ｂ」、サブＳＦ１０２のプロセスＩＤ，処理用通信で利用する共有メモリサイズ，ジョブ種別処理部２１２，２１３のジョブＩＤ及びアクティブ状態（有効又は無効）を登録する。

また、ハンドラ処理部２０２は処理用通信が可能となるようにＳＦ処理クライアント２０６を起動し、サブＳＦ１０２のＳＦ処理サーバ２１５に対してプロセス間通信のクライアント登録を行う。

一方、リクエスト分配処理部２０７はウェブサービスアプリ２５等のクライアントからＷＳＦ２６経由でジョブ管理サービスに対するリクエストを受信する。リクエスト分配処理部２０７は、ジョブＩＤやジョブ種別をキー情報としてＳＦ管理オブジェクト２０３に照会し、ＳＦ処理クライアント２０６のサーバ名を取得する。ここでは、リクエストに対応するサブＳＦ１０２とプロセス間通信が可能なＳＦ処理クライアント２０６のサーバ名を取得している。

リクエスト分配処理部２０７は、取得したサーバ名で特定されるＳＦ処理クライアント２０６とサブＳＦ１０２のＳＦ処理サーバ２１５とのプロセス間通信により、クライアントから受信したリクエストをＳＦ処理サーバ２１５に送信する。ＳＦ処理サーバ２１５は受信したリクエストをメソッド固有処理部２１４に送信する。メソッド固有処理部２１４はリクエストに応じた処理をジョブ種別処理部２１２又は２１３に行わせる。

図７は、リクエストがマスタＳＦからサブＳＦに送信される様子を表した一例の概念図である。マスタＳＦ１０１では、前述したＳＦ処理クライアント２０６，リクエスト分配処理部２０７から成る振り分け処理機能が、クライアントから受信したリクエストをサブＳＦ１０２ａ〜１０２ｎに振り分ける。サブＳＦ１０２ａ〜１０２ｎは、１つ以上のジョブ種別に応じた処理及び管理が可能である。例えばサブＳＦ１０２ａは、ジョブ種別Ａ及びジョブ種別Ｂに応じた処理及び管理が可能である。

具体的に、ジョブ種別Ａ，ジョブ種別Ｂ，ジョブ種別Ｙ１，ジョブ種別Ｚ１はコピー蓄積ジョブ，コピージョブ，スキャナジョブ，メール配信ジョブ等である。なお、図７中のジョブ種別Ａ，ジョブ種別Ｂ，ジョブ種別Ｙ１，ジョブ種別Ｚ１は、可能な操作に対応する１つ以上のジョブを含んでいる。

図８は、一つのマスタＳＦおよび複数のサブＳＦの一例の構成図である。図８では、マスタＳＦ１０１が３つのサブＳＦ１０２ａ〜１０２ｃとプロセス間通信を行うため、それぞれのサブＳＦ１０２ａ〜１０２ｃに対応したＳＦ処理クライアント２０６ａ〜２０６ｃを有している。

なお、ＳＦ処理クライアント２０６ａはサブＳＦ１０２ａのＳＦ処理サーバ２１５ａに対してプロセス間通信のクライアント登録がされている。ＳＦ処理クライアント２０６ｂはサブＳＦ１０２ｂのＳＦ処理サーバ２１５ｂに対してプロセス間通信のクライアント登録がされている。ＳＦ処理クライアント２０６ｃはサブＳＦ１０２ｃのＳＦ処理サーバ２１５ｃに対してプロセス間通信のクライアント登録がされている。

リクエスト分配処理部２０７はクライアントからＷＳＦ２６経由でジョブ管理サービスに対するリクエストを受信する。リクエスト分配処理部２０７は、ジョブＩＤやジョブ種別をキー情報としてＳＦ管理オブジェクト２０３に照会し、ＳＦ処理クライアント２０６ａ〜２０６ｃの何れかのサーバ名を取得する。ここでは、リクエストに対応するサブＳＦ１０２ａ〜１０２ｃの何れかとプロセス間通信が可能なＳＦ処理クライアント２０６ａ〜２０６ｃの何れかのサーバ名を取得している。

リクエスト分配処理部２０７は、取得したサーバ名で特定されるＳＦ処理クライアント２０６ａ〜２０６ｃの何れかと、ＳＦ処理サーバ２１５ａ〜２１５ｃの何れかとのプロセス間通信により、クライアントから受信したリクエストをＳＦ処理サーバ２１５ａ〜２１５ｃの何れかに送信する。メソッド固有処理部はＳＦ処理サーバ２１５ａ〜２１５ｃの何れかからリクエストを受信し、リクエストに応じた処理を前述したジョブ種別処理部２１２，２１３等に行わせる。

図９は、サブＳＦ登録要求のイベントに対するハンドラ処理の一例の構成図である。マスタＳＦ１０１では、ＳＦ登録サーバ２０１へのサブＳＦ登録要求のイベントに対するハンドラ処理で次のような処理を行う。

最初に、ハンドラ処理部２０２はＳＦ管理オブジェクト２０３をロックする。ここでロックとは、ハンドラ処理部２０２以外からのＳＦ管理オブジェクト２０３の照会及び更新を禁止することを言う。ハンドラ処理部２０２は、ＳＦ管理オブジェクト２０３のＳＦプロセス管理リスト２０４に、該当するジョブ種別のＳＦ処理クライアント２０６が存在するか否かを照会する。

該当するジョブ種別のＳＦ処理クライアント２０６がＳＦプロセス管理リスト２０４に存在し、ＳＦ処理クライアント２０６が未起動の場合、ハンドラ処理部２０２はＳＦ処理クライアント２０６を初期化した後、起動する。ＳＦ処理クライアント２０６の初期化に成功すると、ハンドラ処理部２０２はＳＦ管理オブジェクト２０３にＳＦプロセス管理リスト２０４およびサブＳＦ管理リスト２０５の追加とサブＳＦ１０２のジョブ種別処理部２１２，２１３の有効化を依頼する。

次に、ハンドラ処理部２０２はＳＦ処理クライアント２０６に、サブＳＦ１０２のＳＦ処理サーバ２１５に対するマスタＳＦ登録要求を行わせる。ただし、マスタＳＦ登録要求はＳＦ処理クライアント２０６の初回登録時のみ行う。例えば既に登録済みのサブＳＦ１０２が停止後の再開要求としてサブＳＦ登録要求を送信してきた場合、再度、マスタＳＦ登録要求をしないようにチェックする。そして、ハンドラ処理部２０２はＳＦ管理オブジェクト２０３のロックを解除する。

図１０はサブＳＦ停止要求のイベントに対するハンドラ処理の一例の構成図である。マスタＳＦ１０１では、ＳＦ登録サーバ２０１へのサブＳＦ停止要求のイベントに対するハンドラ処理で次のような処理を行う。最初に、ハンドラ処理部２０２はＳＦ管理オブジェクト２０３をロックする。ハンドラ処理部２０２は、ＳＦ管理オブジェクト２０３にサブＳＦ１０２のジョブ種別処理部２１２，２１３の無効化を依頼する。ただし、ＳＦ処理クライアント２０６は停止させない。そして、ハンドラ処理部２０２はＳＦ管理オブジェクト２０３のロックを解除する。

図１１は、マスタＳＦ及びサブＳＦ間のメッセージのシーケンス図である。ステップＳ１では、サブＳＦのＳＦ登録クライアントからマスタＳＦのＳＦ登録サーバへのサブＳＦ登録要求のメッセージ送信が行われる。サブＳＦ登録要求のメッセージを受信すると、マスタＳＦは一連のサブＳＦ登録処理を行う。ステップＳ２に進み、マスタＳＦのＳＦ処理クライアントからサブＳＦのＳＦ処理サーバへのマスタＳＦ登録要求のメッセージ送信が行われる。

なお、サブＳＦのＳＦ登録クライアントは、サブＳＦ登録要求のメッセージを送信したあと、マスタＳＦのＳＦ登録サーバに対するクライアントをいったん終了するようにしてもよい。この場合、ステップＳ５でサブＳＦ停止要求のメッセージを送信する前に、ＳＦ登録クライアントの初期化及び起動を行う。マスタＳＦは、再起動したサブＳＦのＳＦ登録クライアントに対しても、プロセスＩＤとジョブ種別とが一致すれば同一のクライアントと見なしてＳＦ管理オブジェクトを制御する。

ステップＳ３では、マスタＳＦのリクエスト分配処理部がリクエストを受信する。ステップＳ４に進み、マスタＳＦのリクエスト分配処理部はリクエストに応じたＳＦ処理クライアントとサブＳＦのＳＦ処理サーバとのプロセス間通信により、各メソッドの呼び出しを行う。

ステップＳ５では、サブＳＦのＳＦ登録クライアントからマスタＳＦのＳＦ登録サーバへのサブＳＦ停止要求のメッセージ送信が行われる。サブＳＦ停止要求のメッセージを受信すると、マスタＳＦは一連のサブＳＦ停止処理を行う。

図１２は、リクエスト分配処理部が行うリクエスト分配処理の一例のフローチャートである。リクエスト分配処理部は、クライアントからＷＳＦ経由でジョブ管理サービスに対する図１３のようなリクエストを受信する。図１３は、ジョブ管理サービスに対するリクエストの一覧表である。

ジョブ管理サービスに対するリクエストには、ジョブ管理サービス全体に対するリクエストであるバージョン取得，サービス状態取得，セッション開始，セッション終了，セッション延長，ジョブ一覧取得などと、ジョブ種別が特定されたリクエストであるジョブ停止，ジョブ再開，ジョブキャンセル，ジョブ情報取得などがある。また、ジョブ管理サービスに対するリクエストには、マスタＳＦで処理したあと、サブＳＦに通知が必要なリクエストであるセッション開始，セッション終了等がある。

図１３のようなリクエストを受信すると、リクエスト分配処理部は図１２のリクエスト分配処理を開始する。ステップＳ１１に進み、リクエスト分配処理部は受信したリクエストのタイプを判定する。

ジョブ管理サービス全体に対するリクエストであると判定すれば、リクエスト分配処理部はステップＳ１２に進み、クライアントから受信したリクエストをオブジェクト（図示せず）に処理させる。ステップＳ１３に進み、リクエスト分配処理部２０７はマスタＳＦで処理したあと、サブＳＦに通知が必要なリクエストであるか否かを判定する。

サブＳＦに通知が必要なリクエストであると判定すれば、リクエスト分配処理部２０７はステップＳ１４に進み、ＳＦ処理クライアントとサブＳＦのＳＦ処理サーバとのプロセス間通信により、マスタＳＦで処理したリクエストを通知して処理を終了する。サブＳＦに通知が必要なリクエストでないと判定すれば、リクエスト分配処理部２０７は処理を終了する。

ジョブ種別やジョブが特定されたリクエストであると判定すれば、リクエスト分配処理部はステップＳ１５に進み、例えばジョブＩＤやジョブ種別に応じてサブＳＦを特定するリクエスト振り分け処理を行う。ステップＳ１６に進み、リクエスト分配処理部２０７は特定したサブＳＦにリクエストを委譲して処理を終了する。

次に、ステップＳ１５のリクエスト振り分け処理について説明する。例えば図６の構成図の場合、リクエスト分配処理部２０７はクライアントからのリクエストに含まれるジョブＩＤをキー情報としてＳＦ管理オブジェクト２０３に照会する。

ＳＦ管理オブジェクト２０３は、ジョブＩＤをキー情報としてサブＳＦ管理リスト２０５を検索し、検索されたサブＳＦ管理リスト２０５に対応付けられているＳＦプロセス管理リスト２０４からサーバ名を読み出す。ＳＦ管理オブジェクト２０３は、ＳＦプロセス管理リスト２０４から読み出したサーバ名をリクエスト分配処理部２０７に送信する。リクエスト分配処理部２０７はリクエストに対応するサブＳＦ１０２とプロセス間通信が可能なＳＦ処理クライアント２０６のサーバ名を取得することで、リクエストを分配するサブＳＦ１０２を特定できる。

一方、リクエストに含まれるジョブＩＤを図１４に示すように、サブＳＦ１０２のプロセスＩＤを含ませて構成しておくことにより、図１５に示すようなリクエスト振り分け処理が可能となる。図１４は、ジョブＩＤの一例の構成図である。

図１５は、リクエスト振り分け処理の一実施例のフローチャートである。ステップＳ２１に進み、リクエスト分配処理部２０７はクライアントからのリクエストに含まれるジョブＩＤからサブＳＦ１０２のプロセスＩＤを取得する。ステップＳ２２に進み、リクエスト分配処理部２０７はサブＳＦ１０２のプロセスＩＤをキー情報としてＳＦ管理オブジェクト２０３に照会する。

ＳＦ管理オブジェクト２０３は、サブＳＦ１０２のプロセスＩＤをキー情報としてサブＳＦ管理リスト２０５を検索し、検索されたサブＳＦ管理リスト２０５に対応付けられているＳＦプロセス管理リスト２０４からサーバ名を読み出す。ＳＦ管理オブジェクト２０３は、読み出したサーバ名をリクエスト分配処理部２０７に送信する。リクエスト分配処理部２０７はリクエストに対応するサブＳＦ１０２とプロセス間通信が可能なＳＦ処理クライアント２０６のサーバ名を取得することで、リクエストを分配するサブＳＦ１０２を特定できる。

また、リクエストに含まれるジョブＩＤを図１４に示すように、ジョブ種別ＩＤやジョブ固有のＩＤを含ませて構成しておくと共に、サブＳＦ１０２のプロセスＩＤとジョブ種別ＩＤ及びジョブ固有のＩＤとが対応付けられているジョブ管理テーブルを用意しておくことにより、図１６に示すようなリクエスト振り分け処理が可能となる。

図１６は、リクエスト振り分け処理の一実施例のフローチャートである。ステップＳ３１に進み、リクエスト分配処理部２０７はクライアントからのリクエストに含まれるジョブ種別ＩＤやジョブ固有のＩＤを取得する。ステップＳ３２に進み、リクエスト分配処理部２０７はジョブ管理テーブルを参照して、ジョブ種別ＩＤやジョブ固有のＩＤに対応付けられているサブＳＦ１０２のプロセスＩＤを取得する。ステップＳ３３に進み、リクエスト分配処理部２０７はサブＳＦ１０２のプロセスＩＤをキー情報としてＳＦ管理オブジェクト２０３に照会する。

ＳＦ管理オブジェクト２０３は、サブＳＦ１０２のプロセスＩＤをキー情報としてサブＳＦ管理リスト２０５を検索し、検索されたサブＳＦ管理リスト２０５に対応付けられているＳＦプロセス管理リスト２０４からサーバ名を読み出す。ＳＦ管理オブジェクト２０３は、読み出したサーバ名をリクエスト分配処理部２０７に送信する。リクエスト分配処理部２０７はリクエストに対応するサブＳＦ１０２とプロセス間通信が可能なＳＦ処理クライアント２０６のサーバ名を取得することで、リクエストを分配するサブＳＦ１０２を特定できる。

さらに、リクエストに含まれるジョブＩＤを図１４に示すように、ジョブ種別ＩＤやジョブ固有のＩＤを含ませて構成しておくと共に、ジョブ種別ＩＤとジョブ固有のＩＤとが対応付けられているジョブ種別管理テーブルおよびサブＳＦ１０２のプロセスＩＤとジョブ種別ＩＤとが対応付けられているジョブ管理テーブルを用意しておくことにより、図１７に示すようなリクエスト振り分け処理が可能となる。

図１７は、リクエスト振り分け処理の一実施例のフローチャートである。ステップＳ４１に進み、リクエスト分配処理部２０７はリクエストの対象がジョブかジョブ種別かを判定する。ジョブであると判定すると、リクエスト分配処理部２０７はステップＳ４２に進み、クライアントからのリクエストに含まれるジョブ固有のＩＤに対応付けられたジョブ種別ＩＤを取得して、ステップＳ４３に進む。ジョブ種別であると判定すると、リクエスト分配処理部２０７はステップＳ４３に進む。

ステップＳ４３では、リクエスト分配処理部２０７がジョブ管理テーブルを参照し、ジョブ種別ＩＤに対応付けられているサブＳＦ１０２のプロセスＩＤを取得する。ステップＳ４４に進み、リクエスト分配処理部２０７はサブＳＦ１０２のプロセスＩＤをキー情報としてＳＦ管理オブジェクト２０３に照会する。

ＳＦ管理オブジェクト２０３は、サブＳＦ１０２のプロセスＩＤをキー情報としてサブＳＦ管理リスト２０５を検索し、検索されたサブＳＦ管理リスト２０５に対応付けられているＳＦプロセス管理リスト２０４からサーバ名を読み出す。ＳＦ管理オブジェクト２０３は、読み出したサーバ名をリクエスト分配処理部２０７に送信する。リクエスト分配処理部２０７はリクエストに対応するサブＳＦ１０２とプロセス間通信が可能なＳＦ処理クライアント２０６のサーバ名を取得することで、リクエストを分配するサブＳＦ１０２を特定できる。

本実施例では、ジョブ管理サービスに対するリクエストを処理するＳＦ２７をマスタＳＦ１０１およびサブＳＦ１０２とに分け、動作状態となったサブＳＦ１０２をマスタＳＦ１０１に登録することができるので、画像形成装置の構成に応じたジョブ管理サービスのＳＦ２７を実現できる。また、本実施例ではマスタＳＦ１０１が、リクエストをサブＳＦ１０２に分配し、サブＳＦ１０２がリクエストの処理を実行可能である。

上記した実施例１では、マスタＳＦ１０１とサブＳＦ１０２との間に２系統のプロセス間通信が存在しているが、図１８の構成図のように１系統のプロセス間通信で実現することもできる。図１８は、マスタＳＦおよびサブＳＦの他の一例の構成図である。なお、図１８の構成図は一部を除いて図６の構成図と同様であるため、同一部分に同一符号を付して説明を適宜省略する。

図１８のマスタＳＦ１０１は、ＳＦ登録サーバ２０１と，ハンドラ処理部２０２と，ＳＦ管理オブジェクト２０３と，リクエスト分配処理部２０７と，イベント要求部２０８とを有する。ＳＦ管理オブジェクト２０３は、ＳＦプロセス管理リスト２０４と，サブＳＦ管理リスト２０５とを有する構成である。また、サブＳＦ１０２はＳＦ登録クライアント２１１と，ジョブ種別処理部２１２と，メソッド固有処理部２１４とを有する。

マスタＳＦ１０１とサブＳＦ１０２とは、プロセス間通信を利用して相互制御を行っている。マスタＳＦ１０１とサブＳＦ１０２との間には、１系統のプロセス間通信が存在している。具体的に、マスタＳＦ１０１とサブＳＦ１０２との間のプロセス間通信は、サブＳＦ１０２のＳＦ登録クライアント２１１とマスタＳＦ１０１のＳＦ登録サーバ２０１との間で行われる。なお、動作状態となったサブＳＦ１０２のＳＦ登録クライアント２１１をＳＦ登録サーバ２０１に対して登録する処理は、図６の構成図と同様である。また、ハンドラ処理部２０２はリクエストに応じたサブＳＦへのイベントが可能となるようにイベント要求部２０８を起動する。

一方、リクエスト分配処理部２０７はウェブサービスアプリ２５等のクライアントからＷＳＦ２６経由でジョブ管理サービスに対するリクエストを受信する。リクエスト分配処理部２０７は、ジョブＩＤやジョブ種別をキー情報としてＳＦ管理オブジェクト２０３に照会し、イベント要求部２０８を特定する。ここでは、リクエストに対応するサブＳＦ１０２へのイベントが可能となるイベント要求部２０８を特定している。

リクエスト分配処理部２０７は、特定したイベント要求部２０８にクライアントから受信したリクエストを送信する。イベント要求部２０８は、ＳＦ登録サーバ２０１からＳＦ登録クライアント２１１にイベントを行わせる。サブＳＦ１０２のＳＦ登録クライアント２１１は、イベントによりＳＦ登録サーバ２０１から受信したリクエストをメソッド固有処理部２１４に送信する。メソッド固有処理部２１４はリクエストに応じた処理をジョブ種別処理部２１２に行わせる。

本実施例では、実施例１が２系統のプロセス間通信で行っていた処理を、１系統のプロセス間通信で実現できる。即ち、本実施例ではマスタＳＦ１０１に対するサブＳＦ１０２の登録とサブＳＦ１０２に対するリクエストの分配とを１系統のプロセス間通信で実行可能である。

上記した実施例１および実施例２ではマスタＳＦ１０１が特定のサブＳＦ１０２に対して選択的にリクエストの分配を行っているが、図１９の構成図のようにリクエストの選択的な分配を行わずに実現することもできる。図１９は、マスタＳＦおよびサブＳＦの他の一例の構成図である。なお、図１９の構成図は図１８と同様、一部を除いて図６の構成図と同様であるため、同一部分に同一符号を付して説明を適宜省略する。

図１９のマスタＳＦ１０１は、ＳＦ登録サーバ２０１と，ＳＦ管理オブジェクト２０３と，リクエスト分配処理部２０７と，イベント要求部２０８とを有する。ＳＦ管理オブジェクト２０３は、ＳＦプロセス管理リスト２０４と，サブＳＦ管理リスト２０５とを有する構成である。また、サブＳＦ１０２はハンドラ処理部２０２と，ＳＦ登録クライアント２１１と，ジョブ種別処理部２１２と，メソッド固有処理部２１４とを有する。

マスタＳＦ１０１とサブＳＦ１０２とは、プロセス間通信を利用して相互制御を行っている。マスタＳＦ１０１とサブＳＦ１０２との間には、２系統のプロセス間通信が存在している。具体的に、マスタＳＦ１０１とサブＳＦ１０２との間のプロセス間通信は、サブＳＦ１０２のＳＦ登録クライアント２１１及びマスタＳＦ１０１のＳＦ登録サーバ２０１の間と、サブＳＦ１０２のハンドラ処理部２０２及びマスタＳＦ１０１のイベント要求部２０８の間とで行われる。なお、動作状態となったサブＳＦ１０２のＳＦ登録クライアント２１１をＳＦ登録サーバ２０１に対して登録する処理は、サブＳＦ１０２のプロセスＩＤおよび共有メモリ等のリソースの情報を登録するだけでよい。

一方、リクエスト分配処理部２０７はウェブサービスアプリ２５等のクライアントからＷＳＦ２６経由でジョブ管理サービスに対するリクエストを受信する。リクエスト分配処理部２０７は、ジョブＩＤやジョブ種別を識別せずに、イベント要求部２０８を通じてＳＦ管理オブジェクト２０３に登録されている全てのサブＳＦ１０２のハンドラ処理部２０２へ、クライアントから受信したリクエストをイベントにより送信する。

サブＳＦ１０２のハンドラ処理部２０２は、それぞれマスタＳＦ１０１から受信したイベントの中味を調べ、対応可否を決めることができる。メソッド固有処理部２１４は、ハンドラ処理部２０２から受信したリクエストに応じた処理を、ジョブ種別処理部２１２に行わせる。

本実施例では、マスタＳＦ１０１がクライアントから受信したリクエストをジョブＩＤやジョブ種別を識別せず、イベントによりサブＳＦへ送信する為、マスタＳＦ１０１の処理手順およびＳＦ管理オブジェクト２０３の構造をシンプルに保つことができる。

上記した実施例１〜実施例３ではマスタＳＦ１０１がＳＦ管理オブジェクト２０３を保持しているが、ＳＦ管理オブジェクト２０３をマスタＳＦ１０１の外部に保持させるようにしてもよい。例えばＳＦ管理オブジェクト２０３は、マスタＳＦ１０１以外の外部プロセスに保持させることができる。

本実施例では、マスタＳＦ１０１のＳＦ登録サーバ２０１及びリクエスト分配処理部２０７が、ＳＦ管理オブジェクト２０３を保持している外部プロセスにサブＳＦ管理リスト２０５の照会を依頼する点で上記した実施例１〜実施例３と異なっている。

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

本発明による複合機のソフトウェア構成について説明するための一実施例の構成図である。 本発明による複合機のハードウェア構成について説明するための一実施例の構成図である。 ＳＦの一例の構成図である。 ジョブ種別と可能な操作との対応を表した一例の説明図である。 ジョブの操作について説明する一例の説明図である。 マスタＳＦおよびサブＳＦの一例の構成図である。 リクエストがマスタＳＦからサブＳＦに送信される様子を表した一例の概念図である。 一つのマスタＳＦおよび複数のサブＳＦの一例の構成図である。 サブＳＦ停止要求のイベントに対するハンドラ処理の一例の構成図である。 サブＳＦ停止要求のイベントに対するハンドラ処理の一例の構成図である。 マスタＳＦ及びサブＳＦ間のメッセージのシーケンス図である。 リクエスト分配処理部が行うリクエスト分配処理の一例のフローチャートである。 ジョブ管理サービスに対するリクエストの一覧表である。 ジョブＩＤの一例の構成図である。 リクエスト振り分け処理の一実施例のフローチャートである。 リクエスト振り分け処理の一実施例のフローチャートである。 リクエスト振り分け処理の一実施例のフローチャートである。 マスタＳＦおよびサブＳＦの他の一例の構成図である。 マスタＳＦおよびサブＳＦの他の一例の構成図である。

符号の説明

１ 複合機
２ ソフトウェア群
３ 起動部
４ ハードウェア資源
５ アプリケーション層
６ プラットフォーム
２５ ウェブサービスアプリ
２６ ウェブサービスファンクション（ＷＳＦ）
２７，２７ａ〜２７ｎ サービスファンクション（ＳＦ）
１０１ マスタＳＦ
１０２，１０２ａ〜１０２ｎ サブＳＦ
２０１ ＳＦ登録サーバ
２０２ ハンドラ処理部
２０３ ＳＦ管理オブジェクト
２０４ ＳＦプロセス管理リスト
２０５ サブＳＦ管理リスト
２０６，２０６ａ〜２０６ｃ ＳＦ処理クライアント
２０７ リクエスト分配処理部
２０８ イベント要求部
２１１ ＳＦ登録クライアント
２１２，２１３ ジョブ種別処理部
２１４ メソッド固有処理部
２１５ ＳＦ処理サーバ

Claims (19)

1. ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段およびサブサービスファンクション手段に分け、
   前記サブサービスファンクション手段は、動作状態となったときに前記マスタサービスファンクション手段に登録要求を行うと共に、前記マスタサービスファンクション手段から分配される前記リクエストに応じた処理を行い、
   前記マスタサービスファンクション手段は、前記リクエストのジョブ種別に対応付けられている前記サブサービスファンクション手段に前記リクエストを分配することを特徴とする画像形成装置。
2. 前記サブサービスファンクション手段は、動作状態となったときに前記マスタサービスファンクション手段に処理可能な前記リクエストのジョブ種別を通知し、
   前記マスタサービスファンクション手段は、前記ジョブ種別と前記サブサービスファンクション手段との対応関係を管理手段に登録する
   ことを特徴とする請求項１記載の画像形成装置。
3. 前記マスタサービスファンクション手段は、前記管理手段を参照し、前記ジョブ種別に対応する前記サブサービスファンクション手段に前記リクエストを分配することを特徴とする請求項２記載の画像形成装置。
4. 前記マスタサービスファンクション手段は、ジョブ管理サービス全体に対する前記リクエストの処理を自ら行うことを特徴とする請求項２又は３記載の画像形成装置。
5. 前記マスタサービスファンクション手段は、前記ジョブ種別に応じて前記リクエストの処理を行ったあと、前記リクエストの処理を行った旨を前記サブサービスファンクション手段に通知することを特徴とする請求項２又は３記載の画像形成装置。
6. 前記サブサービスファンクション手段は、前記マスタサービスファンクション手段に前記登録要求を送信する登録クライアントと、前記マスタサービスファンクション手段からのリクエストを受信する処理サーバとを有し、
   前記マスタサービスファンクション手段は、前記サブサービスファンクション手段から前記登録要求を受信する登録サーバと、前記リクエストを前記サブサービスファンクション手段に送信する処理クライアントとを有し、
   前記マスタサービスファンクション手段と前記サブサービスファンクション手段との間には２系統のプロセス間通信が存在することを特徴とする請求項２乃至５何れか一項記載の画像形成装置。
7. 前記サブサービスファンクション手段は、前記マスタサービスファンクション手段に前記登録要求を送信する一方、前記マスタサービスファンクション手段からのリクエストをイベントで受信する登録クライアントを有し、
   前記マスタサービスファンクション手段は、前記サブサービスファンクション手段から前記登録要求を受信する一方、前記リクエストをイベントで前記サブサービスファンクション手段に送信する登録サーバとを有し、
   前記マスタサービスファンクション手段と前記サブサービスファンクション手段との間には１系統のプロセス間通信が存在することを特徴とする請求項２乃至５何れか一項記載の画像形成装置。
8. 前記マスタサービスファンクション手段は、前記登録要求を送信した前記サブサービスファンクション手段が前記管理手段に登録されていなければ、前記マスタサービスファンクション手段の処理クライアントと前記サブサービスファンクション手段の処理サーバとを起動したあと前記管理手段に登録し、
   前記登録要求を送信した前記サブサービスファンクション手段が前記管理手段に登録されていれば、マスタサービスファンクション手段の処理クライアントと前記サブサービスファンクションの処理サーバとを起動させることを特徴とする請求項６記載の画像形成装置。
9. 前記マスタサービスファンクション手段は、前記サブサービスファンクション手段から停止要求を受信すると、前記停止要求を送信した前記サブサービスファンクション手段の無効化を前記管理手段に依頼することを特徴とする請求項６乃至８何れか一項記載の画像形成装置。
10. 前記サブサービスファンクション手段は、前記リクエストに応じた処理をジョブ種別毎に行う１つ以上のジョブ種別処理手段を有しており、前記ジョブ種別処理手段毎に前記登録要求を行うことを特徴とする請求項１乃至９何れか一項記載の画像形成装置。
11. 前記マスタサービスファンクション手段は、前記リクエストに含まれるジョブ，ジョブ種別の何れかの識別子に応じて前記リクエストを前記サブサービスファンクション手段に分配することを特徴とする請求項１０記載の画像形成装置。
12. 前記マスタサービスファンクション手段は、前記リクエストに含まれる前記サブサービスファンクション手段のプロセスの識別子に応じて前記リクエストを前記サブサービスファンクション手段に分配することを特徴とする請求項１０記載の画像形成装置。
13. 前記管理手段は、前記ジョブ，ジョブ種別，サブサービスファンクション手段のプロセスの識別子と前記処理サーバとの対応関係が登録されていることを特徴とする請求項６記載の画像形成装置。
14. ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段およびサブサービスファンクション手段に分け、
    前記サブサービスファンクション手段は、動作状態となったときに前記マスタサービスファンクション手段に登録要求を行うと共に、前記マスタサービスファンクション手段から分配される前記リクエストに応じた処理を行い、
    前記マスタサービスファンクション手段は、前記登録要求により登録されている前記前記サブサービスファンクション手段に前記リクエストを分配することを特徴とする画像形成装置。
15. 前記サブサービスファンクション手段は、前記リクエストのジョブ種別に応じて前記リクエストに応じた処理を行うか否かを判断することを特徴とする請求項１４記載の画像形成装置。
16. ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段およびサブサービスファンクション手段とに分けた画像形成装置のサービス機能分割統治方法であって、
    動作状態となったときに前記サブサービスファンクション手段が前記マスタサービスファンクション手段に登録要求を行う段階と、
    前記マスタサービスファンクション手段がリクエストのジョブ種別に対応付けられている前記サブサービスファンクション手段に前記リクエストを分配する段階と、
    前記サブサービスファンクション手段が前記マスタサービスファンクション手段から分配された前記リクエストに応じた処理を行う段階と
    を有することを特徴とするサービス機能分割統治方法。
17. ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段およびサブサービスファンクション手段とに分けた画像形成装置のサービス機能分割統治方法であって、
    動作状態となったときに前記サブサービスファンクション手段が前記マスタサービスファンクション手段に登録要求を行う段階と、
    前記マスタサービスファンクション手段が前記登録要求により登録されている前記サブサービスファンクション手段に前記リクエストを分配する段階と、
    前記サブサービスファンクション手段が前記マスタサービスファンクション手段から分配された前記リクエストに応じた処理を行う段階と
    を有することを特徴とするサービス機能分割統治方法。
18. ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段およびサブサービスファンクション手段とに分けた画像形成装置に、
    動作状態となったときに前記サブサービスファンクション手段が前記マスタサービスファンクション手段に登録要求を行う手順と、
    前記マスタサービスファンクション手段がリクエストのジョブ種別に対応付けられている前記サブサービスファンクション手段に前記リクエストを分配する手順と、
    前記サブサービスファンクション手段が前記マスタサービスファンクション手段から分配された前記リクエストに応じた処理を行う手順と
    を実行させるためのサービス機能分割統治プログラム。
19. ジョブ管理サービス機能に対するリクエストを処理するサービスファンクション手段をマスタサービスファンクション手段およびサブサービスファンクション手段とに分けた画像形成装置に、
    動作状態となったときに前記サブサービスファンクション手段が前記マスタサービスファンクション手段に登録要求を行う手順と、
    前記マスタサービスファンクション手段が前記登録要求により登録されている前記サブサービスファンクション手段に前記リクエストを分配する手順と、
    前記サブサービスファンクション手段が前記マスタサービスファンクション手段から分配された前記リクエストに応じた処理を行う手順と
    を実行させるためのサービス機能分割統治プログラム。

Images