JP2012104063A - サービス処理装置、サービス処理システム及びプログラム - Google Patents

Abstract

【課題】サービスを処理する際に利用するモジュールのうち、自装置及び自装置と連携して動作可能な画像処理装置のいずれにも搭載されていないモジュールを、処理負荷並びに当該サービス以外のサービスの処理まで考慮してサービス処理装置に配置する。
【解決手段】処理要求のあったサービスを処理する際に利用するモジュールのうち画像処理装置１，６のいずれにも搭載されていないモジュールが存在する場合、そのモジュールを利用するサービスについて、当該モジュールを搭載可能な画像処理装置６に搭載したときの処理コストを算出する処理コスト算出部１５と、処理コストが最小となる画像処理装置６を、当該モジュールを利用した処理の実行依頼先として決定する依頼先決定部１３と、実行依頼先の画像処理装置６に当該モジュールが搭載されていない場合に当該画像処理装置６に当該モジュールを搭載するモジュール配置部１６と、を有する。
【選択図】図３

Description

本発明は、サービス処理装置、サービス処理システム及びプログラムに関する。

ネットワークを介して互いに通信可能なデータ処理装置が連携し、データ処理を行う技術が知られている。

例えば、特許文献１には、自コンピュータから他のコンピュータへ処理対象のデータを転送し、他のコンピュータでデータ処理を実施させ、その処理の結果を受け取るか、あるいは他のコンピュータからデータ処理を行うためのプログラムを取得して自コンピュータでデータ処理を行うかを、各コンピュータの稼働状況から決定する技術が開示されている。

また特許文献２には、プログラムのようなサービス資源を、サーバの処理能力や通信網の輻輳を考慮して複数サーバに配置する技術が開示されている。

特開２００２−９９５２１号公報 特開平９−２４４９７９号公報

本発明は、サービスを処理する際に利用するモジュールのうち、自装置及び自装置と連携して動作可能なサービス処理装置のいずれにも搭載されていないモジュールを、処理負荷並びに当該サービス以外のサービスの処理まで考慮してサービス処理装置に配置することを目的とする。

本発明に係るサービス処理装置は、サービスの処理要求を受け付ける受付手段と、要求されたサービスを処理する際に必要な１又は複数の処理機能を実現する１又は複数のモジュールを識別する情報を少なくとも含むサービス構成情報を取得する手段と、自装置及びサービスを処理する際に自装置と連携して動作可能な１又は複数の他のサービス処理装置それぞれについて、搭載されたモジュールを識別する情報と処理能力を表す情報とを少なくとも含む処理能力管理情報を取得する手段と、搭載されたモジュールを利用してサービスを処理する処理手段と、前記サービス構成情報を参照して、処理要求のあったサービスを処理する際に利用するモジュールのうち自他を含む前記サービス処理装置のいずれにも搭載されていないモジュールが存在する場合、前記処理能力管理情報を参照することによって、自他を含む前記サービス処理装置の中から当該いずれにも搭載されていないモジュールを搭載可能なサービス処理装置を選出する選出手段と、前記サービス構成情報を参照することにより、当該いずれにも搭載されていないモジュールを利用するサービスを選出し、その選出した各サービスを処理する際に利用されるモジュールの前記自他を含む前記サービス処理装置への搭載状況に応じてその抽出したサービスの中から処理負荷の算出対象とするサービスを絞り込み、その絞り込んだサービスを処理する際に前記選出手段により選出されたサービス処理装置それぞれに当該いずれにも搭載されていないモジュールを搭載した場合における処理負荷を算出し、その処理負荷を算出した結果、処理負荷が最小となるサービス処理装置を、当該いずれにも搭載されていないモジュールを利用した処理の依頼先として決定する決定手段と、前記決定手段により決定されたサービス処理装置に当該いずれにも搭載されていないモジュールが搭載されていない場合には当該サービス処理装置に当該モジュールを搭載すると共に、当該サービス処理装置に搭載したモジュールを識別する情報を設定することで前記処理能力管理情報を更新する搭載手段と、を有することを特徴とする。

また、前記決定手段は、自装置に搭載されていないモジュールが前記他のサービス処理装置のいずれかに搭載されている場合、当該モジュールが搭載されている前記他のサービス処理装置を、当該自装置に搭載されていないモジュールを利用した処理の依頼先として決定することを特徴とする。

また、モジュール毎に、当該モジュールの取得先を特定する情報を少なくとも含むモジュール管理情報を取得する手段を有し、前記搭載手段は、前記決定手段により決定されたサービス処理装置に搭載モジュールを、前記モジュール管理情報により特定される取得先から取得することを特徴とする。

本発明に係るサービス処理システムは、複数のサービス処理装置と、サービスを処理する際に必要な１又は複数の処理機能を実現する１又は複数のモジュールを識別する情報を少なくとも含むサービス構成情報を記憶するサービス構成情報記憶装置と、前記サービス処理装置毎に、当該サービス処理装置に搭載されたモジュールを識別する情報と処理能力を表す情報とを少なくとも含む処理能力管理情報を記憶する処理能力管理情報記憶装置と、を有し、前記各サービス処理装置は、サービスの処理要求を受け付ける受付手段と、前記サービス構成情報記憶装置からサービス構成情報を取得する手段と、前記処理能力管理情報記憶装置から処理能力管理情報を取得する手段と、処理要求のあったサービスを実行する際に利用するモジュールが搭載された他の前記サービス処理装置と連携しながら要求されたサービスを処理する処理手段と、前記サービス構成情報を参照して、処理要求のあったサービスを処理する際に利用するモジュールのうち前記サービス処理装置のいずれにも搭載されていないモジュールが存在する場合、前記処理能力管理情報を参照することによって、前記サービス処理装置の中から当該いずれにも搭載されていないモジュールを搭載可能なサービス処理装置を選出する選出手段と、前記サービス構成情報を参照して当該いずれにも搭載されていないモジュールを利用するサービスを選出し、その選出した各サービスを処理する際に利用されるモジュールの前記サービス処理装置への搭載状況に応じてその抽出したサービスの中から処理負荷を算出対象とするサービスを絞り込み、その絞り込んだサービスを処理する際に前記選出手段により選出されたサービス処理装置それぞれに当該いずれにも搭載されていないモジュールを搭載した場合における処理負荷を算出し、その処理負荷を算出した結果、処理負荷が最小となるサービス処理装置を、当該いずれにも搭載されていないモジュールを利用した処理の依頼先として決定する決定手段と、前記決定手段により決定されたサービス処理装置に当該いずれにも搭載されていないモジュールが搭載されていない場合には当該サービス処理装置に当該モジュールを搭載すると共に、当該サービス処理装置に搭載したモジュールを識別する情報を設定することで前記処理能力管理情報を更新する搭載手段と、を有することを特徴とする。

また、前記サービス処理装置からの要求に応じて前記各記憶装置を記憶された各情報の読み出し、及び書き込みを一括して行う管理装置を有することを特徴とする。

本発明に係るプログラムは、サービス処理装置に搭載されるコンピュータを、サービスの処理要求を受け付ける受付手段、要求されたサービスを処理する際に必要な１又は複数の処理機能を実現する１又は複数のモジュールを識別する情報を少なくとも含むサービス構成情報を取得する手段、自装置及びサービスを処理する際に自装置と連携して動作可能な１又は複数の他のサービス処理装置それぞれについて、搭載されたモジュールを識別する情報と処理能力を表す情報とを少なくとも含む処理能力管理情報を取得する手段、搭載されたモジュールを利用してサービスを処理する処理手段、前記サービス構成情報を参照して、処理要求のあったサービスを処理する際に利用するモジュールのうち自他を含む前記サービス処理装置のいずれにも搭載されていないモジュールが存在する場合、前記処理能力管理情報を参照することによって、自他を含む前記サービス処理装置の中から当該いずれにも搭載されていないモジュールを搭載可能なサービス処理装置を選出する選出手段、前記サービス構成情報を参照することにより、当該いずれにも搭載されていないモジュールを利用するサービスを選出し、その選出した各サービスを処理する際に利用されるモジュールの前記自他を含む前記サービス処理装置への搭載状況に応じてその抽出したサービスの中から処理負荷の算出対象とするサービスを絞り込み、その絞り込んだサービスを処理する際に前記選出手段により選出されたサービス処理装置それぞれに当該いずれにも搭載されていないモジュールを搭載した場合における処理負荷を算出し、その処理負荷を算出した結果、処理負荷が最小となるサービス処理装置を、当該いずれにも搭載されていないモジュールを利用した処理の依頼先として決定する決定手段、前記決定手段により決定されたサービス処理装置に当該いずれにも搭載されていないモジュールが搭載されていない場合には当該サービス処理装置に当該モジュールを搭載すると共に、当該サービス処理装置に搭載したモジュールを識別する情報を設定することで前記処理能力管理情報を更新する搭載手段、として機能させるためのものである。

請求項１記載の発明によれば、自装置及び自装置と連携して動作可能なサービス処理装置のいずれにも搭載されていないモジュールを、処理負荷並びに当該サービス以外のサービスの処理まで考慮してサービス処理装置に配置することができる。

請求項２記載の発明によれば、他のサービス処理装置に搭載されているモジュールを有効利用することができる。

請求項３記載の発明によれば、自装置に搭載されていないモジュールを、指定された取得先から取得させることができる。

請求項４記載の発明によれば、自装置及び自装置と連携して動作可能なサービス処理装置のいずれにも搭載されていないモジュールを、処理負荷並びに当該サービス以外のサービスの処理まで考慮してサービス処理装置に配置することができる。

請求項５記載の発明によれば、管理装置を用いてサービス処理システムで用いる情報を集約して管理することができる。

請求項６記載の発明によれば、自装置及び自装置と連携して動作可能なサービス処理装置のいずれにも搭載されていないモジュールを、処理負荷並びに当該サービス以外のサービスの処理まで考慮してサービス処理装置に配置することができる。

本発明に係るサービス処理システムの一実施の形態を示した全体構成図である。 実施の形態１における画像処理装置のハードウェア構成の一例を示した図である。 実施の形態１における画像処理装置のブロック構成図である。 実施の形態１におけるサービス構成情報のデータ構成の一例を示した図である。 実施の形態１における処理能力管理情報のデータ構成の一例を示した図である。 実施の形態１におけるモジュール管理情報のデータ構成の一例を示した図である。 実施の形態１における実行コスト情報のデータ構成の一例を示した図である。 実施の形態１における通信コスト情報のデータ構成の一例を示した図である。 実施の形態１においてサービスを実行する処理を示したフローチャートである。 実施の形態１における処理コストの算出処理を示したフローチャートである。 実施の形態１において画像データの種類ごとに予め用意した実行コスト計算関数を管理する管理テーブルを示した図である。 実施の形態１においてサービスの処理の実行要求を受け付けた時点の各画像処理装置の状態を示した概念図である。 図１２に示した状態からサービス依頼を受け付けて処理するために必要なモジュールをダウンロードした時点の各画像処理装置の状態を示した概念図である。 実施の形態２におけるサービス処理システムの全体構成図である。 実施の形態３においてサービスを実行する処理を示したフローチャートである。

以下、図面に基づいて、本発明の好適な実施の形態について説明する。

実施の形態１．
図１は、本発明に係るサービス処理システムの一実施の形態を示した全体構成図である。図１には、画像処理装置１とクラウド２とがファイアウォール（FW）３及びネットワーク４を介して接続された構成が示されている。画像処理装置１は、データ処理装置のうち、主に画像データを取り扱うデータ処理装置の一形態であり、本発明のサービス処理装置の一例として示されている。本実施の形態における画像処理装置１は、スキャナ機能、印刷機能等複数の機能を有する装置であり、受け付けたサービスを提供する際に実行する処理機能の全部又は一部を自ら実行し、あるいは他の画像処理装置１に実行を依頼する。クラウド２は、クラウド・コンピューティングを省略した呼称であり、画像処理装置１からのダウンロード要求に応じてサービスをする際に利用するモジュールを指定された画像処理装置１にダウンロードする。クラウド２には、モジュールを搭載した図示しない複数のサーバ等が含まれている。画像処理装置１は、また他の画像処理装置１とネットワーク５を介して相互に通信可能に接続されている。ネットワーク５は、イントラネットのようにセキュアな通信を行うことができるネットワークであることが望ましいが、これに限られるものではない。また、ネットワーク４は、一般的な商用クラウドサービスとの接続を想定していることから、インターネットを想定しているが、これに限られるものではない。なお、ネットワーク４，５は、便宜的に１つで構成しているが、画像処理装置１がクラウド２にアクセス可能であれば、ネットワーク４の接続形態も図１に示した例に限定されるものではない。

ここで、モジュールとは、一般的に論理的に分離可能なソフトウェア（コンピュータ・プログラム）、ハードウェア等の部品を指す。したがって、本実施の形態におけるモジュールは、コンピュータ・プログラムにおけるモジュールのことだけでなく、ハードウェア構成におけるモジュールも指す。ただ、後述する説明から明らかなように、本実施の形態では、サービスを処理する際に利用するモジュールをクラウド２からダウンロードにより取得する。つまり、本実施の形態では、コンピュータ・プログラムにおけるモジュールを例にして説明している。モジュールは、機能に１対１に対応していてもよいが、実装においては、１モジュールを１プログラムで構成してもよいし、複数のモジュールを１プログラムで構成してもよいし、１モジュールを複数のプログラムで構成してもよい。

また、サービスとは、ソフトウェアやハードウェアによって提供される何らかの情報処理機能を意味し、サービスを処理する際に必要な１又は複数の処理機能は１以上のモジュール（ソフトウェア部品であってもハードウェア部品であっても構わない）を用いて実現される。実装においては、１サービスは１又は複数のモジュールで構成される。本実施の形態においては、サービスを処理する際に１又は複数のモジュールにより１又は複数の処理機能を実行することを「サービス処理の実行」と称したりする。

図２は、本実施の形態における画像処理装置１のハードウェア構成の一例を示した図である。画像処理装置１は、上記の通り各種機能を搭載した装置であり、コンピュータを内蔵した装置である。図２において、ＣＰＵ２１は、ＲＯＭ２６に格納されたプログラムにしたがってＩＩＴ（Ｉｍａｇｅ Ｉｎｐｕｔ Ｔｅｒｍｉｎａｌ）２３やＩＯＴ（Ｉｍａｇｅ Ｏｕｔｐｕｔ Ｔｅｒｍｉｎａｌ）２４等本装置に搭載された各種機構の動作制御を行う。ＩＩＴ２３は、画像入力装置のことをいい、ユーザがセットした原稿を読み取り、電子データとしてＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）２８等に蓄積する。ＩＩＴ２３は、例えばスキャナにより実現してもよい。ＩＯＴ２４は、画像出力装置のことをいい、ＣＰＵ２１で実行される制御プログラムからの指示に従い出力用紙上に画像を印字する。ＩＯＴ２４は、例えばプリンタにより実現してもよい。アドレスデータバス３０は、ＣＰＵ２１の制御対象となる各種機構と接続してデータの通信を行う。操作パネル２２は、ユーザからの指示の受け付け、情報の表示を行う。本実施の形態では、操作パネル２２からの入力に応じてサービスの内容が設定され、所定の操作に応じてサービスの処理要求が発せられる。ＩＰＳ（Ｉｍａｇｅ Ｐｒｏｃｅｓｓｉｎｇ Ｓｙｓｔｅｍ）２５は、画像処理装置のことをいい、受け付けられたサービスに画像処理を含むサービスが含まれていた場合にはその画像処理を実行する。ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２６は、本装置の制御やサービスに関する各種プログラムが格納されている。各種プログラムが実行されることで後述する各構成要素が所定の処理機能を発揮する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２７は、プログラム実行時のワークメモリや電子データ送受信時の通信バッファとして利用される。ＨＤＤ２８は、ＩＩＴ２３を使用して読み取った電子文書などを格納する。ネットワークインタフェース（Ｉ／Ｆ）２９は、ネットワーク５を接続し、本装置からのモジュールのダウンロード要求や実行要求の送信、ダウンロードされてきたモジュールの受信、またブラウザ経由による本装置へのアクセスなどに利用される。本実施の形態では、他の画像処理装置１やクラウド２との間で情報交換を行う際に用いられる。

図３は、本実施の形態における画像処理装置１のブロック構成図である。なお、図３において、画像処理装置６は、画像処理装置１と同様の構成を有する装置であるが、画像処理装置１と連携して動作する「他の」画像処理装置であることを明確にするために異なる符号を付けている。また、画像処理装置１と連携して動作する他の画像処理装置６は、１又は複数台存在しうるが、ここでは、１台の画像処理装置６のみを代表させて図示している。

本実施の形態における画像処理装置１は、サービス処理要求受付部１１、情報管理部１２、処理依頼先決定部１３、装置連携動作制御部１４、処理コスト算出部１５、モジュール配置部１６、クラウド連携動作制御部１７、サービス処理部１８及び情報記憶部１９を有している。

サービス処理要求受付部１１は、画像処理装置１に対して処理を要求するサービスの実行要求を受け付ける。サービスの実行要求（「サービス処理要求」ともいう）は、操作者が画像処理装置１の操作パネル２２から所望のサービスを選択することで発生したり、ネットワーク４またはネットワーク５を介して図示しないクライアントコンピュータから送信されてくる。

情報管理部１２は、情報記憶部１９に記憶されている各種情報の管理を行う。具体的には、サービス構成情報、処理能力管理情報、モジュール管理情報、実行コスト情報及び通信コスト情報などであるが、これらの情報については追って説明する。また、その他にも画像処理装置間のデータ通信速度等、後述する処理において必要な情報を情報記憶部１９を用いて管理する。なお、データ通信速度に関する情報は、予め設定した値でもよいし、特開２００４−３８９７２号公報に開示された技術を用いて測定した値でもよい。

処理依頼先決定部１３は、情報管理部１２が管理する情報を参照することによってサービス処理要求受付部１１が受け付けたサービスを処理する際に利用されるモジュールが搭載されている画像処理装置１，６を特定する。また、サービス処理の実行に必要なモジュールのうち、画像処理装置１及び画像処理装置６のいずれにも搭載されていないモジュールが存在する場合、後述するモジュール配置部１６によってモジュールをダウンロードし起動可能とした画像処理装置を当該モジュールの処理依頼先として決定する。

装置連携動作制御部１４は、ネットワーク５に接続されている他の画像処理装置６への処理依頼やモジュールのダウンロードを実行する。ここでいう処理依頼は、サービス処理要求受付部１１が受け付けたサービスそのものの処理依頼であったり、当該受け付けたサービスを処理するために必要なモジュールのうち、画像処理装置１に搭載されていないモジュールを用いた当該受け付けたサービスの一部、つまり当該モジュールに対する処理依頼である。また、装置連携動作制御部１４は、画像処理装置６から処理依頼やモジュールのダウンロード依頼を受け付ける。

処理コスト算出部１５は、情報管理部１２が管理するコストに関する情報を参照して処理コストを算出する。ここでいうコストに関する情報とは、実行コスト情報及び通信コスト情報のことであり、処理コストは、サービス処理要求受付部１１が受け付けたサービスを構成する各モジュールの演算量に基づいて算出するモジュールの実行コストと、画像処理装置間（この場合は画像処理装置１と画像処理装置６の間）のデータ通信速度に基づいて算出する通信コストとの和により求められる。なお、本実施の形態では、「コスト」を「負荷」と同義の語として用いている。

ここで、データ通信速度を考慮するのは、複数のモジュールで順次処理を行うことで機能を提供するサービスでは、当該サービスを構成する複数のモジュールを所定の順序で実行する必要があり、当該サービスを構成する複数のモジュールが複数の画像処理装置に分散して搭載されている可能性がある場合には、一のモジュールによる処理結果をネットワーク５を介して他の画像処理装置に送信する必要が生じるからである。したがって、サービスが複数のモジュールから構成され、かつこれら複数のモジュールが複数の画像処理装置に分散して搭載されているときは、モジュール間の通信経路を考慮して通信コストを計算する必要がある。なお、処理コストの具体的な計算については後述する。

モジュール配置部１６は、後述する特定の条件を満たし、サービス処理要求受付部１１が受け付けたサービスを処理するために必要でありかつ画像処理装置１に搭載されていないモジュールを配置可能な画像処理装置（ここでは画像処理装置１または画像処理装置６、もしくはその両方）に対し、当該必要なモジュールをクラウド２等からダウンロードすることで、当該画像処理装置において当該モジュールを利用可能な状態にする。当該必要なモジュールが配置可能な画像処理装置が複数存在する場合、処理コスト算出部１５により算出された処理コストが最小となる画像処理装置に決定する。

クラウド連携動作制御部１７は、クラウド２から必要なモジュールをダウンロードする機能を実現する。本実施の形態では、クラウド２は、ファイルサーバとして機能するものとして説明をしているが、クラウド２が計算資源を提供する場合には、連携動作可能な画像処理装置１に搭載されていないモジュールの処理の実行をクラウド２に依頼するようにしてもよい。

サービス処理部１８は、画像処理装置１において実行すべきサービス処理を実行する。具体的には、要求されたサービスのうち、画像処理装置１に搭載されているモジュールを利用して実行すべきサービスの全部又は一部分を実行する。

画像処理装置１における各構成要素１１〜１８は、画像処理装置１に内蔵されているコンピュータと、コンピュータに搭載されたＣＰＵ２１で動作するプログラムとの協調動作により実現される。また、情報記憶部１９は、画像処理装置１に搭載されたＨＤＤ２８にて実現される。なお、情報記憶部１９は、複数台のＨＤＤ２８で実現してもよい。あるいは、画像処理装置１の内部に持たせずに、ネットワーク経由でアクセス可能なコンピュータに搭載し、これをアクセスするように構成してもよい。

また、本実施の形態で用いるプログラムは、通信手段により提供することはもちろん、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体に格納して提供することも可能である。通信手段や記録媒体から提供されたプログラムはコンピュータにインストールされ、コンピュータのＣＰＵがインストールプログラムを順次実行することで各種処理が実現される。

図４は、本実施の形態におけるサービス構成情報のデータ構成の一例を示した図である。サービス構成情報は、サービス毎に、当該サービスを識別する情報としてのサービス名と当該サービスを処理する際に利用されるモジュールとを対応して構成される。本実施の形態では、各サービスにおいて、モジュールの実行順も管理可能なようにテーブル形式にて情報が管理されている。なお、管理テーブル上、サービスが利用しないモジュールに対応する位置は“−”にて図示している。図４に示したデータ設定例によると、例えば、サービスＳＶ１を処理するためにはモジュールＡが必要であることを示している。また、サービスＳＶ４を処理するためにはモジュールＣ，Ｅ，Ｆを必要とし、そして、モジュールＣ→Ｆ→Ｅの順番で実行されることを示している。サービス構成情報は、本実施の形態を動作させる前に予め設定されている。

図５は、本実施の形態における処理能力管理情報のデータ構成の一例を示した図である。処理能力管理情報は、連携して動作可能な画像処理装置群に含まれている画像処理装置毎に、当該画像処理装置を識別する情報（図５では“α”，“β”，“γ”，“δ”）、当該画像処理装置におけるＨＤＤ２８（ＲＡＭ２７でもよい）の空き容量［ＭＢ］、処理能力を表す指標データ及び当該画像処理装置に搭載されているモジュールを識別する情報としてのモジュール名を対応して構成される。なお、画像処理装置にモジュールが何も搭載されていない場合には、“−”にて図示している。なお、画像処理装置には、複数のモジュールが搭載可能である。処理能力管理情報において、空き容量と処理能力は、当該画像処理装置にＨＤＤ２８及びＣＰＵ２１の仕様に基づき初期値が予め設定され、搭載モジュールには、予めダウンロードされているモジュールが予め設定される。そして、後述するように、各画像処理装置の利用状況によって、各値が更新される。

図６は、本実施の形態におけるモジュール管理情報のデータ構成の一例を示した図である。モジュール管理情報は、モジュール毎に、当該モジュールを識別する情報としてのモジュール名、当該モジュールの大きさを表すプログラム容量、演算の数量を表す演算量、当該モジュールが搭載されダウンロードの要求先となる画像処理装置を識別するための搭載先画像処理装置及び当該モジュールが格納されている場所を特定する格納先情報を対応して構成される。このうち、搭載先画像処理装置は、当該モジュールが実際に搭載されている画像処理装置の識別情報ではなく、上記の通り当該モジュールのダウンロードの要求先となる画像処理装置を識別するための情報であり、ただ１つの識別情報が設定される。もちろん、ダウンロードの要求先として複数の画像処理装置を用意しておくならば、複数の画像処理装置の識別情報を設定するようにしてもよい。格納先情報は、本実施の形態においてはＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を指定するようにしており、このＵＲＬで特定される場所は、搭載先画像処理装置における当該モジュールの格納場所である。なお、搭載先画像処理装置において、ダウンロードの要求先となる画像処理装置が存在しない場合には、“−”にて図示している。従って、搭載先画像処理装置が存在せずに格納先情報に設定されているＵＲＬは、クラウド２に含まれているサーバにおける当該モジュールの格納先を特定するための情報である。つまり、当該モジュールのダウンロード先としてクラウド２が指定されていることを意味している。モジュール管理情報において、プログラム容量と演算量は、予め設定される情報であり、搭載先画像処理装置には、モジュールが予めダウンロードされダウンロードの要求先と指定可能であれば、その画像処理装置の識別情報が予め設定される。また、格納先情報には、クラウド２又は画像処理装置における当該モジュールのＵＲＬが予め設定される。そして、後述するように、搭載先画像処理装置及び格納先情報は、当該モジュールがダウンロードされることで更新されうる情報である。

図７は、本実施の形態における実行コスト情報のデータ構成の一例を示した図である。実行コスト情報には、連携して動作可能な画像処理装置群に含まれている画像処理装置毎に、当該画像処理装置（図７では“α”，“β”，“γ”，“δ”）で各モジュール（図７では“Ａ”，“Ｂ”，“Ｃ”）を実行させたときの処理時間の比率が実行コストとして予め設定されている。あるいは、実行コストを、図６に示したモジュール管理情報に含まれるモジュールごとの演算量を参照して、各モジュールの演算量データを取得するとともに、図５に示した処理装置能力管理情報を参照して各モジュールを搭載する画像処理装置の処理能力に関する処理能力データを取得し、演算量データを処理能力データで除することによって求めてもよい。

図８は、本実施の形態における通信コスト情報のデータ構成の一例を示した図である。通信コスト情報には、連携して動作可能な画像処理装置群に含まれている画像処理装置毎に、各画像処理装置（図７では“α”，“β”，“γ”，“δ”）間を接続するネットワークのデータ通信速度の最大値で正規化した値が通信コストとして予め設定されている。データ通信速度は、予め設定した固定値とする必要はなく、データ通信試験を行って得られた実測値としてもよい。

次に、本実施の形態における動作について説明する。まず、本実施の形態においてサービスを実行する処理について図９に示したフローチャートを用いて説明する。

画像処理装置１におけるサービス処理要求受付部１１によってサービス処理要求を受け付けると（ステップ１０１）、処理依頼先決定部１３は、受け付けたサービスを処理するために必要なモジュールを認識するために図４に示したサービス構成情報を情報管理部１２から取得する（ステップ１０２）。

続いて、処理依頼先決定部１３は、画像処理装置１及び画像処理装置１と連携して動作可能な画像処理装置６に搭載されているモジュールを識別するモジュール識別情報を情報管理部１２から取得する。具体的には、図５に示した“搭載モジュール”に設定されているモジュールの識別情報を取得する。そして、サービス構成情報と照らし合わせることにより、当該サービスを受け付けた画像処理装置１において、当該サービスを処理するために不足するモジュール、すなわち受け付けたサービスを処理する際に利用するモジュールのうち画像処理装置１に搭載されていないモジュールがあるかどうかを判定する。

搭載されていないモジュール（以下、「不足モジュール」ともいう）がない場合（ステップＳ１０３でＮ）、受け付けたサービスを処理する際に利用するモジュールの全てが画像処理装置１に搭載されており、画像処理装置１は、クラウド２からモジュールを新たにダウンロードする必要がないので、処理依頼先決定部１３は、サービス処理の実行依頼先を画像処理装置１、すなわち自装置と特定する。そして、サービス処理部１８は、受け付けたサービス処理を単独で実行する（ステップ１１１）。

一方、不足モジュールがある場合（ステップＳ１０３でＹ）、モジュール配置部１６は、サービス依頼を受け付けている画像処理装置１以外の画像処理装置６に搭載されているモジュールの識別情報（図５に示した“搭載モジュール”に設定されている情報）を参照して特定する（ステップ１０４）。

画像処理装置６に不足モジュールが搭載されている場合（ステップ１０５でＹ）、処理依頼先決定部１３は、サービス処理のうち当該モジュールの実行依頼先を画像処理装置６と特定する。この結果、画像処理装置１は、画像処理装置６と連携してサービス処理を実行する（ステップ１１１）。

不足モジュールが画像処理装置６にも搭載されていない場合（ステップ１０５でＮ）、処理コスト算出部１５は、モジュール識別情報に示された画像処理装置１と画像処理装置６に搭載されているモジュールと、新たにダウンロードすべき不足モジュールを加えることで対応可能となるサービスを構成する各モジュールとを、順次処理を実行していく場合の処理時間に関する実行コストと、各モジュールの処理結果を次に処理を実行すべきモジュールを搭載した画像処理装置に送信する場合の通信時間に関する通信コストをそれぞれ算出し、実行コストと通信コストとの和を求めることで処理コストを算出する（ステップ１０６）。なお、処理コストの計算の詳細については後述する。そして、モジュール配置部１６は、処理コストが最小となる場合の当該不足モジュール配置先に当たる画像処理装置を、当該不足モジュールの搭載先として決定する（ステップ１０７）。

続いて、装置連携動作制御部１４は、モジュール配置部１６からの指示に従い、不足モジュールの搭載先として決定した画像処理装置６に対し、図６に示したモジュール管理情報の格納先情報により特定される格納先に格納されている当該不足モジュールをダウンロードするとともに利用可能とするよう、依頼する（ステップ１０８）。これにより、処理依頼先決定部１３は、当該画像処理装置６を当該モジュールの実行依頼先として特定する。

以上のようにして、画像処理装置６に不足モジュールが搭載されると、モジュール配置部１６は、情報管理部１２に指示することで、図５に示した処理能力管理情報において画像処理装置６に対応する搭載モジュールに、搭載したモジュールの識別情報を登録すると共に（ステップ１０９）、図６に示したモジュール管理情報の搭載先画像処理装置に画像処理装置６の識別情報を、格納先情報に不足モジュールが格納された場所を特定するＵＲＬを登録する（ステップ１１０）。

なお、ステップ１０９と１１０は逆の順番に実施してもよい。また、ステップ１１０は、例えば、ライセンスの関係上、画像処理装置に格納されたモジュールプログラムを更に他の画像処理装置にダウンロードできないような場合も想定できるので、このような場合は、当該モジュールをクラウド２から常にダウンロードするためにモジュール管理情報の搭載先画像処理装置及び格納先情報には情報を登録しない。

以上のようにして、受け付けたサービスを処理するモジュールの処理実行先が決定されると、画像処理装置１は、画像処理装置６と連携してサービス処理を実行する（ステップ１１１）。

ここで、処理コストの計算処理についてさらに詳しく説明する。ここで説明する内容は、図９におけるステップ１０７の処理の詳細な説明に相当する。

図１０は、処理コスト算出部１５における処理コストの計算処理を示したフローチャートである。この処理は、図９におけるステップ１０６の処理の詳細に相当する。

まず、処理コスト算出部１５は、サービス依頼を受け付けている画像処理装置１以外の連携動作可能な画像処理装置６について、処理能力管理情報を参照するので、不足モジュールをダウンロードして保存するためのＨＤＤ２８の空き容量があるかどうかを調べることで、ダウンロード先候補を選択する（ステップ１２１）。

次に、処理コスト算出部１５は、サービス依頼を受け付けている画像処理装置１と画像処理装置１と連携動作可能な画像処理装置６とに搭載されているモジュールと、新たにダウンロードすべき不足モジュールを加えることで、他のモジュールをダウンロードすることなく処理可能となるサービスが他にあるかどうか、図４に例示するサービス構成情報を参照して判定する。

処理可能となるサービスが受け付けたサービスの他にある場合（ステップ１２２でＹ）、サービス構成情報をさらに参照し、当該処理可能となるサービスを処理する際に必要となるモジュールの実行順序を特定する。そして図５に示す処理能力管理情報を参照することで、当該処理可能となるサービスを処理する際の、各モジュールの処理結果がどのような順序で画像処理装置間を流れるかを表す実行パスを、不足モジュールのダウンロード候補先ごとに特定する（ステップ１２３）。

一方、対応可能となるサービスがない場合（ステップ１２２でＮ）、サービス処理要求受付部１１が受け付けたサービスを処理する際の、各モジュールの処理結果がどのような順序で画像処理装置間を流れるかを表す実行パスを、不足モジュールのダウンロード先候補ごとに特定する（ステップ１２４）。

ステップ１２２において、対応可能なサービスが複数存在する場合も想定されるが、各サービスの要求履歴情報を取得することにより、ステップ１２３においては実行要求の多いサービスについてのみ、実行パスを特定するように絞り込みを行ってもよい。サービスの要求履歴情報を取得することができなくても、例えば、必要とするモジュール数が多いサービスについてのみ、実行パスを特定するようにしてもよい。なお、要求履歴情報に関しては、後述するが、例えば、サービス処理要求受付部１１が受け付けて処理されたサービスに関し、実施されたサービスの識別情報、サービス処理要求者、実施開始日時、処理に要した時間等の処理の履歴を保存することで要求履歴情報は生成しうる。

次に、処理コスト算出部１５は、連携動作可能な画像処理装置６それぞれに搭載され、サービスを処理するために必要とされるモジュールの実行コストを計算する（ステップ１２５）。画像データを扱う画像処理装置において、実行コストは、一般に画像データの画素数や大きさ、または１画素当たりの階調数等の画像属性に依存している。一方、通信コストは、画像データのデータ量に依存する。また、モジュールの実行する画像処理の内容によってはデータ量や画像属性が変化することがある。多機能複写機のような画像処理装置では、取り扱う画像データの種類がカラー、グレイ、白黒二値の３種類であるが、これらは１画素当たりのビット数やチャネル数（色成分数）が固定されている。この点に着目すれば、画像属性が変化することによって実行コストが画像データの大きさに対して非線形となり、それぞれユニークな計算が必要な場合にも対応するために、予め画像データの大きさをパラメータとしてコスト計算を実行する関数を、画像処理装置が扱う画像データの種類ごとに用意すればよい。

図１１は、画像データの種類ごとに予め用意した実行コスト計算関数を管理する管理テーブルを示す図である。ここで示す実行コスト計算関数は、実験によって求めた近似関数であってもよいし、実験によって求めた離散的な複数の値をテーブルに管理し、中間の値は補間演算によって求めるようにしてもよい。

次に、処理コスト算出部１５は、ステップ１２３若しくはステップ１２４により特定した実行パスに従って、各モジュールの処理結果を次に処理を実行すべきモジュールを搭載している画像処理装置へ送信する場合のデータ通信時間に関する通信コストをそれぞれ計算する（ステップ１２６）。通信コストは、ネットワークのデータ通信能力が特定されていれば、画像処理装置間でやり取りされるデータの大きさに比例して増加するといえる。そこで、図８に示すような管理テーブルにて通信コスト情報を予め用意しておいてもよい。

以上のようにして、実行コストと通信コストとを算出すると、処理コスト算出部１５は、実行コストと通信コストとを合算して処理コストを求める（ステップ１２７）。処理コスト算出部１５は、処理コストをステップ１２１で絞り込んだダウンロード先候補全てについて求める（ステップＳ１２８）。

本実施の形態においては、以上のようにして、ダウンロード先候補全てに対して処理コストを算出する。そして、ダウンロード先候補全てについて処理コストを算出すると、前述したように、モジュール配置部１６は、ダウンロード先候補の中から処理コストが最小となる画像処理装置を、当該不足モジュールの搭載先として決定する。

次に、上記の通り説明した本実施の形態における画像処理装置１の具体的な動作を、図１２を参照しつつ説明する。

図１２は、サービスの処理の実行要求を受け付けた時点の各画像処理装置の状態を示した概念図である。図１２において、画像処理装置群を構成する画像処理装置１００ａ，１００ｂ，１００ｃ，１００ｄ（以下、特に断らない限り、図５乃至図８の各管理テーブルを参照する場合、画像処理装置１００ａはαと、画像処理装置１００ｂはβと、画像処理装置１００ｃはγと、画像処理装置１００ｄはδと、それぞれ対応しているものとする。）は、それぞれが図３に示した本実施の形態における画像処理装置１の構成要素を有しており、例えばイントラネットのようなネットワーク１０２に接続され、一連のデータ処理を連携して実行することができる。なお、全ての画像処理装置１００ａ，１００ｂ，１００ｃ，１００ｄに共通する内容は、「画像処理装置１００」と記することにする。他の要素についても同様に表記する。

各画像処理装置１００の内部には、外部からサービス処理を実行するためのモジュールを必要に応じてダウンロードして記憶するためのＨＤＤ２８等から構成される記憶手段１０１ａ，１０１ｂ，１０１ｃ，１０１ｄを備えている。この記憶手段は、図３に示した情報記憶部１９に相当する。

各画像処理装置１００に搭載されているモジュールの種類、記憶手段の空き容量、内蔵ＣＰＵ処理能力といった処理能力管理情報１０４ａ，１０４ｂ，１０４ｃ，１０４ｄは、各画像処理装置内で管理することができる情報であるが、図示しない外部の管理サーバに対して各画像処理装置１００が処理能力管理情報１０４を送信することにより、当該管理サーバ上で一元管理するようにしてもよい。図５に示した処理能力管理情報管理テーブルは、このような一元管理された場合の好適な例を示している。

ここで、例えば、画像処理装置１００ｄに対してサービスＳＶ３の処理を要求するサービス要求１０３が依頼されたとする（ステップ１０１）。サービスＳＶ３を処理するために必要なモジュールの種類を特定するために、画像処理装置１００ｄは、図示しない外部の管理サーバに対して図４に示したサービス構成情報の照会を要求する。なお、サービス構成情報の送信を要求して取得してもよい（ステップ１０２）。図４に示した設定例を参照すると、サービスＳＶ３を処理するにはモジュールＣが必要であることが判明する。さらに画像処理装置１００ｄは、当該管理サーバに対して図６に示したモジュール管理情報の参照を要求する。なお、モジュール管理情報の送信を要求して取得してもよい。

図６に示したモジュール管理情報の設定例を参照すると、モジュールＣのプログラム容量は、４０Ｍバイトで、演算量が「５０」単位であることが判明し、さらにモジュールＣをダウンロードする場合にアクセスすべきＵＲＬは、ｈｔｔｐ：／／５．６．７．８／ｏｐｔｉｏｎａｌ／であることが判明する。なお、このようなモジュール管理情報は、サービス要求１０３とともに、サービスを依頼する画像処理装置に対して送信するようにしてもよい。

画像処理装置１００ｄは、処理能力管理情報１０４ｄの搭載モジュールを参照することにより、サービスＳＶ３を処理するために必要なモジュールＣが自装置に搭載されていないことを確認する（ステップ１０３）。更に、画像処理装置１００ｄは、他の画像処理装置１００ａ，１００ｂ，１００ｃの処理能力管理情報１０４ａ，１０４ｂ，１０４ｃの送信を各画像処理装置１００ａ，１００ｂ，１００ｃに要求する。なお、図示しない管理サーバが連携動作可能な画像処理装置１００全ての処理能力管理情報を一元管理しているのであれば、画像処理装置１００ｄは当該管理サーバに対してモジュールＣを搭載している他の画像処理装置１００ａ，１００ｂ，１００ｃの処理能力管理情報について問い合わせるようにしてもよい。なお、処理能力管理情報の送信を要求して取得してもよい（ステップ１０４）。この例の場合、図５に示した処理能力管理テーブル、または各画像処理装置の処理能力管理情報１０４ａ，１０４ｂ，１０４ｃのいずれを参照してもモジュールＣが搭載されていないことが判明する（ステップ１０５でＮ）。

そこで、画像処理装置１００ｄは、モジュールＣをどの画像処理装置１００に配置すべきかを特定するために、各画像処理装置の処理能力管理情報１０４ａ，１０４ｂ，１０４ｃを参照してモジュールＣのプログラム容量４０Ｍバイト以上の空き容量がある画像処理装置をダウンロード先候補として特定する。この場合、画像処理装置１００ｂ，１００ｃがダウンロード先候補となる。

この例では、ダウンロード先候補が一つに絞り込めないことから、次に画像処理装置１００ｄは、モジュールＣを使用する他のサービスがないかどうかを図４に示すサービス構成情報を参照することで特定する。この例の場合、図４を参照すると、モジュールＣを利用するサービスとして、サービスＳＶ３以外にサービスＳＶ２とサービスＳＶ４が存在することが判明する。ただ、このうちサービスＳＶ４は、各画像処理装置１００ａ，１００ｂ，１００ｃ，１００ｄに搭載されていないモジュールＥとモジュールＦを必要とするので、ここでは考慮すべきサービスから除外してサービスＳＶ２の処理コストについて評価を行う。このように、各画像処理装置１００へのモジュールの搭載状況に応じて抽出したサービスＳＶ２，ＳＶ３，ＳＶ４の中から処理負荷の算出対象とするサービスＳＶ２を絞り込むようにしててもよい。

図４に示したサービス構成情報を参照すると、サービスＳＶ２は、モジュールＡ→モジュールＢ→モジュールＣの順番で逐次実行していけばよいことがわかる。したがって、画像処理装置１００ｄにサービスＳＶ２の依頼があった場合、画像処理装置１００ｄは、サービスＳＶ２で処理すべきデータをまずモジュールＡを搭載する画像処理装置１００ａへ送り、画像処理装置１００ａは受け取ったデータをモジュールＡを起動して処理した上で、モジュールＢを搭載する画像処理装置１００ｂへ送ることになる。このような状況における処理コストを計算してみる（ステップ１０６）。

ここまでの処理コストは、図７に示す実行コスト情報を参照して次のように求める。ここで、画像処理装置１００ａ，１００ｂ，１００ｃ，１００ｄに搭載された任意のモジュールｍの実行コストを、ＰＣ（α，ｍ）、ＰＣ（β，ｍ）、ＰＣ（γ，ｍ）、ＰＣ（δ，ｍ）と表記する。また、任意の画像処理装置ｓから他の画像処理装置ｔへ通信を行う際に生じる通信コストを、ＣＣ（ｓ，ｔ）と表記する。

（１）モジュールＡに係る実行コストおよび通信コスト
最初にサービスＳＶ２で処理すべきデータを画像処理装置１００ａに送ることで、通信コストＣＣ（δ，α）が発生し、図８の欄８１を参照してＣＣ（δ，α）＝１を得る。モジュールＡに係る実行コストＰＣ（α，Ａ）は、図７において当該モジュールＡを搭載する画像処理装置１００ａ（図７においては、画像処理装置αに対応）の欄７１を参照し、ＰＣ（α，Ａ）＝１．０を得る。

モジュールＡの処理結果は、画像処理装置１００ａから画像処理装置１００ｂへ送られることになるので、その際の通信コストＣＣ（α，β）は、図８の欄８２を参照してＣＣ（α，β）＝１を得る。なお、実行コストＰＣ（α，Ａ）は、画像処理装置１００ａの処理能力管理情報１０４ａを図５に示すような処理能力管理情報を参照し、処理能力「５０」の画像処理装置１００ａで演算量「５０」のデータを処理することから、（演算量＝５０）／（処理能力＝５０）＝１．０ のように求めてもよい。

（２）モジュールＢに係る実行コストおよび通信コスト
モジュールＢに係る実行コストＰＣ（β，Ｂ）は、図７において当該モジュールＢを搭載する画像処理装置１００ｂ（図７においては、画像処理装置βに対応）の欄７２を参照し、実行コスト＝１．０を得る。上記と同様、実行コストＰＣ（β，Ｂ）を、（演算量＝５０）／（画像処理装置１００ｂの処理能力＝５０）＝１．０のように求めてもよい。

次はモジュールＣによる処理の実行であるが、モジュールＣのダウンロード先候補は画像処理装置１００ｂ，１００ｃのいずれかであるから、それぞれにモジュールＣをダウンロードした場合について処理コストを計算することになる。

（３）画像処理装置βにモジュールＣをダウンロードした場合の実行コストおよび通信コスト
画像処理装置１００ｂにモジュールＣをダウンロードすると、モジュールＢの処理は同じ画像処理装置１００ｂで行われているため、モジュールＢの処理結果をモジュールＣを搭載する画像処理装置に送信するのに要する通信コストは発生しない。

モジュールＣに係る実行コストＰＣ（β，Ｃ）は、図７の欄７３を参照し、実行コストＰＣ（β，Ｃ）＝１．０を得る。図５に示した処理能力管理情報を参照し、処理能力「５０」の画像処理装置１００ｂで演算量「５０」のデータ処理を行うことから、実行コストＰＣ（β，Ｃ）を、（演算量＝５０）／（処理能力＝５０）＝１．０のように求めてもよい。

更に、モジュールＣによる処理結果は、画像処理装置１００ｄに戻す必要があるので、図８の欄８３を参照して通信コストＣＣ（β，δ）＝１を得る。

（４）画像処理装置γにモジュールＣをダウンロードした場合の実行コストおよび通信コスト
画像処理装置１００ｃにモジュールＣをダウンロードすると、モジュールＢの処理結果を画像処理装置１００ｂから画像処理装置１００ｃへ送る必要があるため、図８の通信コスト情報の欄８４を参照し、通信コストＣＣ（β，γ）＝１を得る。

画像処理装置１００ｃにおけるモジュールＣの実行コストは、図７に示した実行コスト情報の欄７４を参照し、実行コストＰＣ（γ，Ｃ）＝０．７を得る。図５に示した処理能力情報を参照し、処理能力「７０」の画像処理装置１００ｃで演算量「５０」のデータ処理を行うことから、実行コストＰＣ（γ，Ｃ）を、（演算量＝５０）／（処理能力＝７０）＝０．７のように求めてもよい。

更に、モジュールＣによる処理結果は、画像処理装置１００ｄに戻す必要があるので、図８に示した通信コスト情報の欄８５を参照して通信コストＣＣ（γ，δ）＝１を得る。

モジュールＣのダウンロード先ごとに、実行コストと通信コストの和として処理コストを求めると、次のようになる。

（５）画像処理装置βにモジュールＣをダウンロードする場合の処理コスト
モジュールＣのダウンロード先を画像処理装置１００ｂとしたときの処理コストは、
ＣＣ（δ，α）＋ＰＣ（α，Ａ）＋ＣＣ（α，β）＋ＰＣ（β，Ｂ）＋ＰＣ（β，Ｃ）＋ＣＣ（β，δ）＝１＋１＋１＋１＋１＋１＝６．０
となる。

（６）画像処理装置γにモジュールＣをダウンロードする場合の処理コスト
モジュールＣのダウンロード先を画像処理装置１００ｃとしたときの処理コストは、
ＣＣ（δ，α）＋ＰＣ（α，Ａ）＋ＣＣ（α，β）＋ＰＣ（β，Ｂ）＋ＣＣ（β，γ）＋ＰＣ（γ，Ｃ）＋ＣＣ（γ，δ）＝１＋１＋１＋１＋１＋０．７＋１＝６．７
となる。

以上の結果から、モジュールＣは画像処理装置１００ｂに配置したときの処理コストの方が、画像処理装置１００ｃに配置したときよりも小さいことが明らかなので、モジュールＣの配置先は画像処理装置１００ｂに決定される。

図１３は、図１２に示した状態からサービス依頼を受け付けて処理するために必要なモジュールをダウンロードした時点の各画像処理装置の状態を示した概念図である。

前述のように、サービスＳＶ３を処理するために必要なモジュールＣは、画像処理装置１００ｂに配置されることになるので、画像処理装置１００ｂの記憶手段１１１ｂに記憶されている処理能力管理情報における搭載モジュールには、モジュールＢに加えてモジュールＣが登録される。また、記憶手段１１１ｂにおける空き容量は、当初の５０Ｍバイトから、モジュールＣのプログラム容量分を減じた１０Ｍバイトになるので、これに応じて、処理能力管理情報における空き容量は、５０Ｍバイトから１０Ｍバイトに更新される。

以上の処理では、画像処理装置１００ｄがモジュールＣを利用するサービスＳＶ３の依頼を受けたことに伴い、今後のサービス処理の依頼、具体的にはモジュールＣを利用するサービスＳＶ２の依頼を将来的に受け付ける場合を想定してモジュールＣの配置処理が行われるわけである。ただ、ここでは、画像処理装置１００ｄがサービスＳＶ３の処理の実行要求を受け付け付けているので、サービスＳＶ３の依頼を受けた画像処理装置１００ｄは、画像処理装置１００ｂに対してサービスＳＶ３の処理の実行を依頼するとともに、サービスＳＶ３で処理すべきデータを引き渡す（図１３における経路１１５）。そして、画像処理装置１００ｂにおいて、当該引き渡されたデータを用いてサービスＳＶ３を処理し、そしてその処理が終了すると、その処理結果を画像処理装置１００ｄに返す（経路１１６）。

以上の説明から明らかなように、本実施の形態においては、任意のサービスを処理するのに利用されるモジュールを特定するサービス構成情報（図４）、連携動作可能な画像処理装置それぞれの搭載モジュールやＣＰＵ処理能力等を示す処理能力管理情報（図５）、各モジュールのプログラム容量や演算量、格納先情報等を含むモジュール管理情報（図６）を参照しつつ、処理コストを計算する。これらの情報は、各画像処理装置で管理するようにしてもよいが、別途管理サーバを設けて一元管理してもよい。新しいモジュールを追加することで、新しいサービスの処理が可能となる場合も、管理サーバに保持管理されているこれらの情報を更新しさえすれば、各画像処理装置は、新しいサービスがサービス処理システムにおいて追加提供可能となったことを知り得る。また、当該新しいモジュール提供者や新しいサービス提供者は、各画像処理装置にその旨を通知するときの通信コストの削減にもつながる。

実施の形態２．
本実施の形態は、実施の形態１において説明した管理サーバを有するサービス処理システムを提供する。図１４は、本実施の形態におけるサービス処理システムの全体構成図であり、また連携動作可能な複数の画像処理装置と管理サーバの関係を説明するために用いる概念図である。

以下、本実施の形態の動作について説明する。なお、画像処理装置の構成は図３に示した構成でよい。あるいは、情報記憶部１９にて保持している各種情報は、管理サーバ１２４に一元管理させてもよい。

ネットワーク１２２に接続され、互いに連携動作可能な画像処理装置１２０ａ，１２０ｂ，１２０ｃ，１２０ｄの各装置内部に記憶保持されている処理能力管理情報１２１ａ，１２１ｂ，１２１ｃ，１２１ｄは、例えば、搭載モジュールや記憶手段の空き容量に変化があったタイミングで、画像処理装置１２０ａ，１２０ｂ，１２０ｃ，１２０ｄが管理サーバ１２４に対して送信する。管理サーバ１２４は、後述する各種情報を管理する情報管理部を有しており、当該処理能力管理情報を受け取ると、管理サーバ１２４が管理している処理能力管理情報管理テーブル１２５で画像処理装置１２０の処理能力管理情報１２１を集約管理する。管理サーバ１２４は、一定周期ごとに各画像処理装置１２０から処理能力管理情報１２１を受け取るようにしてもよい。

クラウド２が画像処理装置１２０ａ，１２０ｂ，１２０ｃ，１２０ｄにダウンロードすることで利用可能となる複数のモジュールを格納している場合、モジュール管理情報は、クラウド２上に保持されている。管理サーバ１２４は、クラウド２からモジュール管理情報を受け取って、モジュール管理情報管理テーブル１２８にて集約管理する。

クラウド２上に格納されたモジュールを利用することで処理可能となるサービスを示すサービス構成情報は、管理サーバ１２４で管理されているサービス構成情報管理テーブル１２７に集約管理される。なお、サービス構成情報管理テーブル１２７上で管理される情報は、管理サーバ１２４へのアクセス頻度を抑えるために画像処理装置１２０ａ，１２０ｂ，１２０ｃ，１２０ｄに対して管理サーバ１２４が適宜配信するようにしてもよい。

画像処理装置１２０ａ，１２０ｂ，１２０ｃ，１２０ｄは、それぞれが要求を受け付けたサービスの種類や受付回数などの履歴情報を生成して管理してもよい。これら画像処理装置が管理サーバ１２４と通信する際に、このようなサービス処理要求の履歴情報を合わせて送信することで、管理サーバ１２４は、管理するサービス構成情報管理テーブル１２７上で連携動作可能な画像処理装置全体に対するサービス要求履歴を一元管理するようにしてもよい。管理サーバ１２４は、各画像処理装置１２０から実施されたサービスに関する履歴情報が送られてくると、その履歴情報をサービス構成情報管理テーブル１２７における当該サービスの「要求受付回数」に登録して管理する。

なお、処理能力管理情報管理テーブル１２５における「再配置可能」については、実施の形態３において説明する。

実施の形態３．
上記実施の形態１においては、依頼を受けたサービスを処理するために必要なモジュールが搭載されていない場合に、当該必要なモジュールをダウンロードして配置した。

しかし、当該必要なモジュールを搭載している画像処理装置が存在する場合であっても、その画像処理装置が既に他のサービス依頼を受け付けていて、これから処理を依頼しようとするサービスを直ちに処理することができない場合がある。また、ライセンス契約の関係などからモジュールの利用が制限されている場合もあり得る。このような場合、１つの当該必要なモジュールが複数の画像処理装置に搭載される結果となっても当該必要なモジュールを別途ダウンロードする必要が生じてくる。

そこで、本実施の形態においては、互いに連携動作可能な複数の画像処理装置のいずれかに、依頼を受け付けたサービスを処理するために必要なモジュールがすでに搭載されていても、当該モジュールを当該依頼を受け付けたサービスの処理に利用することができない場合は、当該モジュールを搭載されている画像処理装置以外の画像処理装置に別途ダウンロードしてサービスを処理するようにしたことを特徴としている。

なお、本実施の形態は、図１４に示したシステム構成で実現してよく、また、画像処理装置の構成は図３に示した構成でよい。

以下、本実施の形態の動作について説明するが、本実施の形態におけるサービスを実行するときの処理は、基本的には実施の形態１と同様であり、図９に示したフローチャートの処理手順に従う。ただ、画像処理装置６に不足モジュールが搭載されている場合（ステップ１０５でＹ）、以降に実施する処理が実施の形態１とは異なってくる。以下、このステップ１０５以降の処理について図１５に示したフローチャートを用いて説明する。なお、図１５において、図９と同じ処理には同じ符号を付け、説明を適宜省略する。

連携動作可能な画像処理装置のいずれかに不足モジュールが搭載されている場合（ステップＳ１０５でＹ）、モジュール配置部１６は、当該モジュールを搭載している画像処理装置を特定する（ステップ２０１）。モジュール配置部１６は、続いてその特定した画像処理装置で当該モジュールが利用可能かどうかを判定する。この判定の際には、当該モジュールが他のサービスを処理するために使用されていることで利用ができない状態であるかどうかについて調べる。あるいは当該特定した画像処理装置に対して、当該モジュールが利用可能かどうかを直接問い合わせてもよい。あるいは、管理サーバ１２４が各画像処理装置が画像処理装置によって利用されているかどうかを示すステータス情報を管理している場合、モジュール配置部１６は、管理サーバ１２４に当該画像処理装置に利用可能性を問い合わせをするようにしてもよい。そして、不足モジュールの利用が可能であれば（ステップ２０２でＹ）、処理依頼先決定部１３は、不足モジュールの実行依頼先として当該画像処理装置を決定する（ステップ２０５）。そして、各モジュールが搭載された画像処理装置が連携してサービス処理が実行される（ステップ１１１）。

一方、不足モジュールの利用ができない場合（ステップ２０２でＮ）、モジュール配置部１６は、さらに当該モジュールを他の画像処理装置に再配置可能かどうかを確認する。モジュールによっては、ライセンス契約等によってコピーが制限されている場合があったり、あるいは、画像処理装置自体が搭載モジュールを他の画像処理装置の記憶手段にコピーする機能を有していないものがあるからである。これは、当該特定した画像処理装置に対して、当該モジュールが利用可能かどうかを直接問い合わせてもよい。あるいは、管理サーバ１２４が図１４に示した処理能力管理情報管理テーブル１２５に「再配置可能」の情報、すなわちモジュールの再配置の可能性について管理している場合、モジュール配置部１６は、管理サーバ１２４に問い合わせをするようにしてもよい。

この結果、当該モジュールを他の画像処理装置に再配置可能であると判断した場合（ステップ２０３でＹ）、モジュール配置部１６は、図６に示したモジュール管理情報に含まれる該モジュールの格納先情報を、当該特定した画像処理装置のＵＲＬにて更新することにより、当該特定した画像処理装置を当該モジュールの取得先として決定する（ステップ２０４）。なお、この場合、ステップ１１０は、ステップ２０４と同じ処理を行うことになるので、ステップ１１０において格納先情報の登録はしなくてもよい。そして、当該モジュールをどの画像装置装置に搭載するかということと、サービス処理を実行するまでの処理（ステップ１０６〜１１１）に関しては、説明を省略する。

一方、当該モジュールを他の画像処理装置に再配置することができない場合（ステップＳ２０３でＮ）、当該モジュールを別途ダウンロードする必要があると判断して、ステップ１０６に移行するが、移行後の処理（ステップ１０６〜１１１）に関しては、説明を省略する。

本実施の形態によれば、他の画像処理装置に不足モジュールが搭載されていた場合には、当該他の画像処理装置の状態によって、不足モジュールの実行先として当該他の画像処理装置、あるいは更に他の画像処理装置を選択する。

１，６，１００，１００ａ〜１００ｄ，１２０，１２０ａ〜１２０ｄ 画像処理装置、２ クラウド、３ ファイアウォール（FW）、４，５，１０２，１２２ ネットワーク、１１ サービス処理要求受付部、１２ 情報管理部、１３ 処理依頼先決定部、１４ 装置連携動作制御部、１５ 処理コスト算出部、１６ モジュール配置部、１７ クラウド連携動作制御部、１８ サービス処理部、１９ 情報記憶部、２１ ＣＰＵ、２２ 操作パネル、２３ ＩＩＴ、２４ ＩＯＴ、２５ ＩＰＳ、２６ ＲＯＭ、２７ ＲＡＭ、２８ ＨＤＤ、２９ ネットワークインタフェース（Ｉ／Ｆ）、３０ アドレスデータバス、１０１，１０１ａ〜１０１ｄ 記憶手段、１２４ 管理サーバ、１２５ 処理能力管理情報管理テーブル、１２７ サービス構成情報管理テーブル、１２８ モジュール管理情報管理テーブル。

Claims (6)

1. サービスの処理要求を受け付ける受付手段と、
   要求されたサービスを処理する際に必要な１又は複数の処理機能を実現する１又は複数のモジュールを識別する情報を少なくとも含むサービス構成情報を取得する手段と、
   自装置及びサービスを処理する際に自装置と連携して動作可能な１又は複数の他のサービス処理装置それぞれについて、搭載されたモジュールを識別する情報と処理能力を表す情報とを少なくとも含む処理能力管理情報を取得する手段と、
   搭載されたモジュールを利用してサービスを処理する処理手段と、
   前記サービス構成情報を参照して、処理要求のあったサービスを処理する際に利用するモジュールのうち自他を含む前記サービス処理装置のいずれにも搭載されていないモジュールが存在する場合、前記処理能力管理情報を参照することによって、自他を含む前記サービス処理装置の中から当該いずれにも搭載されていないモジュールを搭載可能なサービス処理装置を選出する選出手段と、
   前記サービス構成情報を参照することにより、当該いずれにも搭載されていないモジュールを利用するサービスを選出し、その選出した各サービスを処理する際に利用されるモジュールの前記自他を含む前記サービス処理装置への搭載状況に応じてその抽出したサービスの中から処理負荷の算出対象とするサービスを絞り込み、その絞り込んだサービスを処理する際に前記選出手段により選出されたサービス処理装置それぞれに当該いずれにも搭載されていないモジュールを搭載した場合における処理負荷を算出し、その処理負荷を算出した結果、処理負荷が最小となるサービス処理装置を、当該いずれにも搭載されていないモジュールを利用した処理の依頼先として決定する決定手段と、
   前記決定手段により決定されたサービス処理装置に当該いずれにも搭載されていないモジュールが搭載されていない場合には当該サービス処理装置に当該モジュールを搭載すると共に、当該サービス処理装置に搭載したモジュールを識別する情報を設定することで前記処理能力管理情報を更新する搭載手段と、
   を有することを特徴とするサービス処理装置。
2. 前記決定手段は、自装置に搭載されていないモジュールが前記他のサービス処理装置のいずれかに搭載されている場合、当該モジュールが搭載されている前記他のサービス処理装置を、当該自装置に搭載されていないモジュールを利用した処理の依頼先として決定することを特徴とする請求項１に記載のサービス処理装置。
3. モジュール毎に、当該モジュールの取得先を特定する情報を少なくとも含むモジュール管理情報を取得する手段を有し、
   前記搭載手段は、前記決定手段により決定されたサービス処理装置に搭載モジュールを、前記モジュール管理情報により特定される取得先から取得することを特徴とする請求項１に記載のサービス処理装置。
4. 複数のサービス処理装置と、
   サービスを処理する際に必要な１又は複数の処理機能を実現する１又は複数のモジュールを識別する情報を少なくとも含むサービス構成情報を記憶するサービス構成情報記憶装置と、
   前記サービス処理装置毎に、当該サービス処理装置に搭載されたモジュールを識別する情報と処理能力を表す情報とを少なくとも含む処理能力管理情報を記憶する処理能力管理情報記憶装置と、
   を有し、
   前記各サービス処理装置は、
   サービスの処理要求を受け付ける受付手段と、
   前記サービス構成情報記憶装置からサービス構成情報を取得する手段と、
   前記処理能力管理情報記憶装置から処理能力管理情報を取得する手段と、
   処理要求のあったサービスを実行する際に利用するモジュールが搭載された他の前記サービス処理装置と連携しながら要求されたサービスを処理する処理手段と、
   前記サービス構成情報を参照して、処理要求のあったサービスを処理する際に利用するモジュールのうち前記サービス処理装置のいずれにも搭載されていないモジュールが存在する場合、前記処理能力管理情報を参照することによって、前記サービス処理装置の中から当該いずれにも搭載されていないモジュールを搭載可能なサービス処理装置を選出する選出手段と、
   前記サービス構成情報を参照して当該いずれにも搭載されていないモジュールを利用するサービスを選出し、その選出した各サービスを処理する際に利用されるモジュールの前記サービス処理装置への搭載状況に応じてその抽出したサービスの中から処理負荷を算出対象とするサービスを絞り込み、その絞り込んだサービスを処理する際に前記選出手段により選出されたサービス処理装置それぞれに当該いずれにも搭載されていないモジュールを搭載した場合における処理負荷を算出し、その処理負荷を算出した結果、処理負荷が最小となるサービス処理装置を、当該いずれにも搭載されていないモジュールを利用した処理の依頼先として決定する決定手段と、
   前記決定手段により決定されたサービス処理装置に当該いずれにも搭載されていないモジュールが搭載されていない場合には当該サービス処理装置に当該モジュールを搭載すると共に、当該サービス処理装置に搭載したモジュールを識別する情報を設定することで前記処理能力管理情報を更新する搭載手段と、
   を有することを特徴とするサービス処理システム。
5. 前記サービス処理装置からの要求に応じて前記各記憶装置を記憶された各情報の読み出し、及び書き込みを一括して行う管理装置を有することを特徴とするサービス処理システム。
6. サービス処理装置に搭載されるコンピュータを、
   サービスの処理要求を受け付ける受付手段、
   要求されたサービスを処理する際に必要な１又は複数の処理機能を実現する１又は複数のモジュールを識別する情報を少なくとも含むサービス構成情報を取得する手段、
   自装置及びサービスを処理する際に自装置と連携して動作可能な１又は複数の他のサービス処理装置それぞれについて、搭載されたモジュールを識別する情報と処理能力を表す情報とを少なくとも含む処理能力管理情報を取得する手段、
   搭載されたモジュールを利用してサービスを処理する処理手段、
   前記サービス構成情報を参照して、処理要求のあったサービスを処理する際に利用するモジュールのうち自他を含む前記サービス処理装置のいずれにも搭載されていないモジュールが存在する場合、前記処理能力管理情報を参照することによって、自他を含む前記サービス処理装置の中から当該いずれにも搭載されていないモジュールを搭載可能なサービス処理装置を選出する選出手段、
   前記サービス構成情報を参照することにより、当該いずれにも搭載されていないモジュールを利用するサービスを選出し、その選出した各サービスを処理する際に利用されるモジュールの前記自他を含む前記サービス処理装置への搭載状況に応じてその抽出したサービスの中から処理負荷の算出対象とするサービスを絞り込み、その絞り込んだサービスを処理する際に前記選出手段により選出されたサービス処理装置それぞれに当該いずれにも搭載されていないモジュールを搭載した場合における処理負荷を算出し、その処理負荷を算出した結果、処理負荷が最小となるサービス処理装置を、当該いずれにも搭載されていないモジュールを利用した処理の依頼先として決定する決定手段、
   前記決定手段により決定されたサービス処理装置に当該いずれにも搭載されていないモジュールが搭載されていない場合には当該サービス処理装置に当該モジュールを搭載すると共に、当該サービス処理装置に搭載したモジュールを識別する情報を設定することで前記処理能力管理情報を更新する搭載手段、
   として機能させるためのプログラム。

Images