JP4314178B2

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

Info

Publication number: JP4314178B2
Application number: JP2004279661A
Authority: JP
Inventors: 透松田; 幸子三平
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2004-09-27
Filing date: 2004-09-27
Publication date: 2009-08-12
Anticipated expiration: 2024-09-27
Also published as: US20060066898A1; US7760383B2; EP1643753B1; EP1643753A1; CN1754704B; JP2006094322A; CN1754704A

Description

本発明は、画像形成装置、サービス機能分割統治方法およびサービス機能分割統治プログラムに係り、特に所定のサービス機能に対するリクエストを処理するサービスファンクション手段を備えた画像形成装置、サービス機能分割統治方法およびサービス機能分割統治プログラムに関する。

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

複合機は、プリンタ，コピー，ファクシミリ，スキャナ等の各装置の機能を有しているため、機器管理の対象（以下、管理対象という）が多かった。そこで、複合機では管理対象に応じた処理を行うサービスファンクション（以下、ＳＦという）を用意し、そのＳＦにより機器管理サービス機能を提供していた。
特開２００３−３４１１７５号公報

しかしながら、複合機における管理対象は機器の構成に応じて変化する。この為、ＳＦは機器の全ての構成に対処できるように、使用される可能性のある全ての管理対象に予め対応させておかなければならない。例えばファックス機能の無い複合機であってもファックス機能を追加する可能性があれば、ＳＦはファックスの管理対象に応じた処理を行うようにしておかなければならなかった。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、ハンドラ層９は後述するＦＣＵ（ファックスコントロールユニット）の管理を行うＦＣＵＨ（ファックスコントロールユニットハンドラ）４１と、プロセスに対するメモリの割り振り及びプロセスに割り振ったメモリの管理を行うＩＭＨ（イメージメモリハンドラ）４２とを含む。

ＳＲＭ８及びＦＣＵＨ４１は、予め定義されている関数によりハードウェア資源４に対するリクエストを送信するエンジンＩ／Ｆ５２を利用して、ハードウェア資源４に対するリクエストを行う。図１の構成により、複合機１は各アプリケーションで共通的に必要な処理をプラットフォーム６で一元的に処理することができる。次に、複合機１のハードウェア構成について説明する。

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

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

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

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

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

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

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

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

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

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

例えば図４の「システム」，「ネットワーク」，「プリンタ」，「ファックス」及び「スキャナ」等は、管理対象種別を表す。また、図４の項目名「ｔｉｍｅ」，「ｓｎｔｐＳｅｒｖｅｒ」及び「ｔｉｍｅｚｏｎｅ」は管理対象を表す。即ち、機器管理サービスのＳＦ２７では管理対象を種別ごとに分類し、管理対象種別ごとにサブＳＦ１０２を設けている。図５は管理対象の詳細を表した一例の説明図である。例えば図５のオブジェクト名は管理対象を表している。さらに、項目名は管理対象を構成する項目を表している。
図３のマスタＳＦ１０１及びサブＳＦ１０２について、図６を参照しつつ詳細に説明していく。図６は、マスタＳＦおよびサブＳＦの一例の構成図である。図６のマスタＳＦ１０１は、ＳＦ登録サーバ２０１と，ハンドラ処理部２０２と，ＳＦ管理オブジェクト２０３と，ＳＦ処理クライアント２０６と，リクエスト分配処理部２０７とを有する。ＳＦ管理オブジェクト２０３は、ＳＦプロセス管理リスト２０４と，サブＳＦ管理リスト２０５とを有する構成である。また、サブＳＦ１０２はＳＦ登録クライアント２１１と，オブジェクト２１２，２１３と，メソッド固有処理部２１４と，ＳＦ処理サーバ２１５とを有する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最初に、ハンドラ処理部２０２はＳＦ管理オブジェクト２０３をロックする。ハンドラ処理部２０２は、ＳＦ管理オブジェクト２０３にサブＳＦ１０２のオブジェクトの無効化を依頼する。ただし、ＳＦ処理クライアント２０６は停止させない。そして、ハンドラ処理部２０２はＳＦ管理オブジェクト２０３のロックを解除する。

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

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

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

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

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

機器管理サービスに対するリクエストには、機器管理サービス全体に対するリクエストであるバージョン取得，サービス状態取得，セッション開始，セッション終了，セッション延長，機器占有開始，機器占有終了，管理対象種別一覧取得等と、管理対象種別が特定されたリクエストである管理対象一覧取得等と、管理対象が特定されたリクエストである管理対象ケーパビリティ取得，管理対象設定値取得，管理対象設定変更等がある。

また、機器管理サービスに対するリクエストには、マスタＳＦで処理したあと、サブＳＦに通知が必要なリクエストであるセッション開始，セッション終了，機器占有開始，機器占有終了等がある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。なお、特許請求の範囲に記載したリクエスト種別は、リクエストの内容（バーション取得など），リクエストの対象（ｔｉｍｅｚｏｎｅなど），リクエストを処理するサブＳＦ等によるリクエストの区別である。

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

符号の説明

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

Claims

所定のサービス機能に対するリクエストを処理するサービスファンクション手段を有する画像形成装置であって、
前記サービスファンクション手段はマスタサービスファンクション手段及びサブサービスファンクション手段を含み、
前記サブサービスファンクション手段は、動作状態となったときに前記マスタサービスファンクション手段に登録要求を行うと共に、前記マスタサービスファンクション手段から分配された前記リクエストの処理を行い、
前記マスタサービスファンクション手段は、リクエスト種別に応じて前記リクエストを前記サブサービスファンクション手段に分配する
ことを特徴とする画像形成装置。
前記サブサービスファンクション手段は、動作状態となったときに前記マスタサービスファンクション手段に処理可能な前記リクエスト種別を通知し、
前記マスタサービスファンクション手段は、前記リクエスト種別と前記サブサービスファンクション手段との対応関係を管理手段に登録する
ことを特徴とする請求項１記載の画像形成装置。
前記マスタサービスファンクション手段は、前記管理手段を参照し、前記リクエスト種別に対応する前記サブサービスファンクション手段に前記リクエストを分配することを特徴とする請求項２記載の画像形成装置。
前記マスタサービスファンクション手段は、リクエスト種別に応じて前記リクエストの処理を行うことを特徴とする請求項２又は３記載の画像形成装置。
前記マスタサービスファンクション手段は、リクエスト種別に応じて前記リクエストの処理を行ったあと、前記リクエストの処理を行った旨を前記サブサービスファンクション手段に通知することを特徴とする請求項２又は３記載の画像形成装置。
前記サブサービスファンクション手段は、前記マスタサービスファンクション手段に前記登録要求を送信する登録クライアントと、前記マスタサービスファンクション手段からのリクエストを受信する処理サーバとを有するプロセスであり、
前記マスタサービスファンクション手段は、前記サブサービスファンクション手段から前記登録要求を受信する登録サーバと、前記リクエストを前記サブサービスファンクション手段に送信する処理クライアントとを有するプロセスであり、
前記マスタサービスファンクション手段と前記サブサービスファンクション手段との間には２系統のプロセス間通信が存在することを特徴とする請求項２乃至５何れか一項記載の画像形成装置。
前記サブサービスファンクション手段は、前記マスタサービスファンクション手段に前記登録要求を送信する一方、前記マスタサービスファンクション手段からのリクエストをイベントで受信する処理クライアントを有し、
前記マスタサービスファンクション手段は、前記サブサービスファンクション手段から前記登録要求を受信する一方、前記リクエストをイベントで前記サブサービスファンクション手段に送信する処理サーバとを有し、
前記マスタサービスファンクション手段と前記サブサービスファンクション手段との間には１系統のプロセス間通信が存在することを特徴とする請求項２乃至５何れか一項記載の画像形成装置。
前記マスタサービスファンクション手段は、前記登録要求を送信した前記サブサービスファンクション手段が前記管理手段に登録されていなければ、前記マスタサービスファンクション手段の処理クライアントと前記サブサービスファンクション手段の処理サーバとを起動したあと前記管理手段に登録することを特徴とする請求項６記載の画像形成装置。
前記マスタサービスファンクション手段は、前記登録要求を送信した前記サブサービスファンクション手段が前記管理手段に登録されていれば、マスタサービスファンクション手段の処理クライアントと前記サブサービスファンクションの処理サーバとを起動させることを特徴とする請求項６記載の画像形成装置。
前記マスタサービスファンクション手段は、前記サブサービスファンクション手段から停止要求を受信すると、前記停止要求を送信した前記サブサービスファンクション手段の無効化を前記管理手段に登録することを特徴とする請求項６乃至９何れか一項記載の画像形成装置。
前記サブサービスファンクション手段は、１つ以上のオブジェクトを有しており、前記オブジェクト毎に前記登録要求を行うことを特徴とする請求項１乃至１０何れか一項記載の画像形成装置。
前記マスタサービスファンクション手段は、前記リクエストに含まれるオブジェクト識別子に応じて前記リクエストを前記サブサービスファンクション手段に分配することを特徴とする請求項１１記載の画像形成装置。
前記マスタサービスファンクション手段は、前記リクエストに含まれる前記サブサービスファンクション手段の識別子に応じて前記リクエストを前記サブサービスファンクション手段に分配することを特徴とする請求項１１記載の画像形成装置。
前記マスタサービスファンクション手段は、前記リクエストに含まれる前記リクエストの対象の識別子に応じて前記リクエストを前記サブサービスファンクション手段に分配することを特徴とする請求項１１記載の画像形成装置。
前記管理手段は、前記オブジェクト識別子，前記サブサービスファンクション手段の識別子または前記リクエストの対象の識別子と前記処理サーバとの対応関係が登録されていることを特徴とする請求項６記載の画像形成装置。
前記マスタサービスファンクション手段は、前記登録サーバのライブラリから呼び出されるハンドラ処理で前記格納手段に、前記リクエスト種別と前記サブサービスファンクション手段との対応関係を登録することを特徴とする請求項６記載の画像形成装置。
前記マスタサービスファンクション手段および前記サブサービスファンクション手段は機器管理サービス機能に対するリクエストを処理することを特徴とする請求項１乃至１６何れか一項記載の画像形成装置。
前記マスタサービスファンクション手段は、前記リクエストが前記機器管理サービス機能全体に対するリクエストであれば前記リクエストの処理を行い、前記リクエストが機器管理サービス機能の管理対象または管理対象種別を特定したリクエストであれば前記サブサービスファンクション手段に前記リクエストを分配することを特徴とする請求項１７記載の画像形成装置。
前記マスタサービスファンクション手段は、ウェブサービス層のプロセスから前記リクエストを受信することを特徴とする請求項１乃至１８何れか一項記載の画像形成装置。
所定のサービス機能に対するリクエストを処理するサービスファンクション手段を有する画像形成装置のサービス機能分割統治方法であって、
前記サービスファンクション手段はマスタサービスファンクション手段及びサブサービスファンクション手段を含み、
動作状態となったときに前記サブサービスファンクション手段が前記マスタサービスファンクション手段に登録要求を行う段階と、
前記マスタサービスファンクション手段がリクエスト種別に応じて前記リクエストを前記サブサービスファンクション手段に分配する段階と、
前記サブサービスファンクション手段が前記マスタサービスファンクション手段から分配された前記リクエストの処理を行う段階と
を有することを特徴とするサービス機能分割統治方法。
所定のサービス機能に対するリクエストを処理するサービスファンクション手段を有する画像形成装置に、
動作状態となったときに前記サービスファンクション手段に含まれるサブサービスファンクション手段が前記サービスファンクション手段に含まれるマスタサービスファンクション手段に登録要求を行う手順と、
前記マスタサービスファンクション手段がリクエスト種別に応じて前記リクエストを前記サブサービスファンクション手段に分配する手順と、
前記サブサービスファンクション手段が前記マスタサービスファンクション手段から分配された前記リクエストの処理を行う手順と
を実行させるためのサービス機能分割統治プログラム。