JP3695758B2 - 多重プロトコル画像形成装置間で画像情報を送受信するためのシステム - Google Patents

Description

技術分野
本発明は画像形成システムに関し、特に、画像形成システムの入力画像形成装置と出力画像形成装置との間で画像情報を送受信するのためのシステムに関する。
従来技術の説明
一般に、画像形成システムは、画像情報を生成する入力画像形成装置と画像情報に基づいて画像を可視化する出力画像形成装置とを有する。例えば医療用の画像形成システムでは、磁気共鳴（ＭＲ）装置や断層撮影（ＣＴ）装置、従来の放射線撮影（Ｘ線）装置または超音波装置などの診断装置が入力画像形成装置に含まれる。また、入力画像形成装置には、医療用画像情報を生成することのできるキーパッドやマウス、トラックボールなどのユーザインタフェース装置も含まれる。医療用画像形成システムにおいて一般的に用いられる出力画像形成装置としては、連続階調デジタルレーザ画像生成器が挙げられる。このレーザ画像生成器は、画像情報に応答して画像形成メディアを露光し、可視画像を形成する。
入力画像形成装置によって生成された画像情報には、画像を表すデジタル画像値を持つ画像データと、レーザ画像生成器によって実行されるべき動作を指定する画像形成要求とが含まれる。各デジタル画像値は、原画像に含まれる複数の画素１個１個に対応し、それぞれの画素と関連した光学密度を表している。画像形成要求に応答して、レーザ画像生成器はデジタル画像値を変換し、走査用レーザの強度を調整するのに用いられるレーザ駆動値を生成する。これらのレーザ駆動値は、画像形成メディアへの露光レベルを決定するために算出され、湿式化学処理または乾式化学処理のいずれかによって原画像を現像する際に原画像の画素と関連した光学密度を再生する上で必要なものである。また、入力画像形成装置によって生成される画像形成要求に応答して、レーザ画像生成器をその他様々な形で動作させることもできる。例えばレーザ駆動値の生成前にレーザ画像生成器によって画像データを操作し、異なるフォーマットおよび／または見た目の特徴を様々な形で生成することもできる。
レーザ画像生成器によって処理された画像情報のフォーマットは、個人の入力画像形成装置の入力プロトコルによって決まる。医療用画像形成システムは、多種多様な入力プロトコルに基づいて生成される画像情報に対応できるものであることが好ましい。入力プロトコルは、特定の入力画像形成装置との通信に必要な要件を決定する入力ドライバプロトコルや、入力画像形成装置によって生成された画像情報を解釈するための入力インタプリタプロトコルを含むものとして特徴付けできるものである。異なる入力プロトコルが多数存在する理由の一つには、異なるプロトコルに基づいて画像情報を生成するＭＲ装置やＣＴ装置、Ｘ線装置、超音波装置など様々な入力画像形成装置が用いられているということが挙げられる。しかしながら、これらの様々な入力プロトコルの主な原因はモジュール性が異なりすぎていることにある。すなわち、異なる製造業者によってそれぞれ独自の製造業者固有の入力プロトコルを用いた入力画像形成装置が製造されていることが原因なのである。例えば、シーメンスや東芝、ＧＥ、Pickerなどの製造業者は、似たような機能を持つＣＴタイプの入力画像形成装置を製造しているが、これらの画像形成装置から生成される画像情報は、異なる様式に準拠した入力プロトコルに基づくものとなっている。
複数の入力プロトコルに対応できることに加え、医療用画像形成システムは、複数の出力プロトコルに基づく出力画像形成装置に対して画像情報を送信することのできるものであると好ましい。入力プロトコルと同様に、出力プロトコルについても、特定の出力画像形成装置との通信に必要な要件を決定する出力ドライバプロトコルや、画像情報を出力画像形成装置によって解釈できる形式に翻訳するためのフォーマットを決定する出力インタプリタプロトコルを含むものとして特徴付けすることができる。複数の出力プロトコルが存在する背景には、主に機能面で異なるレーザ画像形成出力装置が利用可能であるということが挙げられる。機能面で様々な組み合わせが可能であるがゆえに一層複雑さが増し、出力プロトコルを異なるものとせざるをえなくなるのである。例えば、ミネソタ州St. PaulのMinnesota Mining & Manufacturing Company（３Ｍ）では、設定によって特定される出力プロトコルと関連した「８３１」、「９５２」および「Super Set」設定値と呼ばれる機能面で異なるレーザ画像生成器を提供している。
既存の医療用画像生成装置は、個々の用途に合わせて複数の入力プロトコルおよび出力プロトコルを用いて動作する。これらのプロトコルは、特定入力プロトコルおよび特定出力プロトコル用のハードウェアおよび／またはソフトウェアのインタフェースを設計する際に定義される。受注製作されたインタフェースを使用することは特に柔軟性を欠くことになる。異なる入力画像形成装置との通信が後になって必要になったような場合、インタフェース全体を再設計して新たな入力プロトコルと旧出力プロトコルとの関係に対応できるようにしなければならない。出力画像形成装置を変更する場合も同様に、新たな出力プロトコルと旧入力プロトコルとの関係に対応できるようにインタフェースを再設計する必要がある。残念なことに、インタフェースの再設計は手間を要する作業であり、ハードウェアおよび／またはソフトウェアの開発に多大なる投資をしなければならないことも多々ある。些細なことのように思える入力画像形成装置または出力画像形成装置の機能変更ですら、費用をかけてインタフェース全体に影響する大幅な設計変更をしなければならないことがある。
しかしながら、複数のプロトコルを利用する様々な入力画像形成装置と出力画像形成装置との間で通信を可能にする柔軟性の高い医療用画像形成システムに対する需要は高まる一方である。このような医療用画像形成システムは、すでにあるプロトコルに対する柔軟性を持つだけでなく、今後定義される可能性のあるプロトコルに対してもコスト効率のいい形で適応できるものであると望ましい。既存の医療用画像形成システムは一般に、こういった重要に応えることができずにある。
発明の開示
既存の医療用画像形成システムの制約を考慮し、本発明は、使用する入力プロトコルの異なる複数種の入力画像形成装置と使用する出力プロトコルの異なる複数種の出力画像形成装置との間で画像情報を送受信するための医療用画像形成システムに関する。
本発明によるシステムは、機能面で独立した複数のコンポーネントを有する再利用可能なソフトウェアアーキテクチャを有効利用する。個々のコンポーネントを、所望のプロトコルに基づいて入力画像形成装置と出力画像形成装置との間で画像情報を送受信するための通信パイプラインとして構成することができる。各コンポーネントを別の形で構成されたコンポーネントと入れ換えてパイプラインの構成を変えて柔軟性を高くし、異なるプロトコルを用いた画像情報の送受信を簡略化することもできる。さらに、通信パイプラインを動的に構成し、既存の環境に適したコンポーネントを利用するようにできるという利点もある。
また、複数のソフトウェアアーキテクチャをそれぞれ所望のプロトコルに基づいて構成し、複数の通信パイプラインを生成するようその規模を変えることもできる。このように、本発明のシステムは、コンポーネントを交換して１本の通信パイプラインを再構成するか、あるいは規模の変更が可能なアーキテクチャにおいて異なる形で構成された複数の通信パイプラインから他のものを選択することによって、異なるプロトコルをサポートすることができる。
さらに、各コンポーネントは別個で機能的に独立しているため、コンポーネントを再設計する必要が生じても、オーバーヘッドをさほど増やすことなく複数のプログラマを割り当てることができるため、時間と費用の節約になる。アーキテクチャのモジュール性自体も、システム全体に対してほとんど影響せずに１個のコンポーネントを変更または修正できるようなものになっている。
本発明の他の特徴および利点につていは以下に述べるが、これらの説明から明らかになるものもあり、本発明を実施する際に分かるものもあると思われる。本発明の利点は、明細書および請求の範囲ならびに添付の図面において示される手段によって特に実現され、達成されるものであろう。
【図面の簡単な説明】
添付の図面は、本発明に対する理解を深めるために提供されているものであり、本願明細書に引用されてその一部を構成するものである。これらの図面は、本発明の一例としての実施例を例示するためのものであり、明細書の記載内容と併せて本発明の原理を説明する上で役立つ。
第１図は、複数のプロトコル画像形成装置間で画像情報を送受信するための、本発明による医療用画像形成システムの機能ブロック図である。
第２図は、本発明による複数の異なるプロトコルと一組のベースクラスプロトコルとの間の関係を示す図である。
第３図は、本発明による医療用画像形成システムに適用可能なクライアント-サーバ関係を示す機能ブロック図である。
好ましい実施例の詳細な説明
第１図は、複数のプロトコル画像形成装置間で画像情報を送受信するための、本発明による医療用画像形成システム１０の機能ブロック図である。この医療用画像形成システム１０は、複数の入力画像形成装置１２と、１個以上の入力インタフェースコンポーネント１４と、１個以上の出力インタフェースコンポーネント１６と、１個以上の出力画像形成装置１８とを含む。各入力インタフェースコンポーネント１４は、入力ドライバコンポーネント２０と入力インタプリタコンポーネント２２とを含む。各出力インタフェースコンポーネント１６は、出力インタプリタコンポーネント２４と出力ドライバコンポーネント２６とを含む。インタフェース監視コンポーネント２８は、１個以上（１〜Ｎ）の通信パイプライン３０を定義する。各通信パイプライン３０は、入力画像形成装置１２のうちの１つと、入力ドライバコンポーネント２０のうちの１つと、入力インタプリタコンポーネント２２のうちの１つと、出力インタプリタコンポーネント２４のうちの１つと、出力ドライバコンポーネント２６のうちの１つと、出力画像形成装置１８のうちの１つと、双方向通信可能な形で接続されている。出力画像形成装置１８は、互いにシェアする形でパイプライン３０のいずれとも通信することができる。あるいは、複数の出力画像形成装置１８を設け、各々を特定のパイプライン３０に対して相互に通信接続することも可能である。
入力インタフェースコンポーネント１４と、出力インタフェースコンポーネント１６と、インタフェース監視コンポーネント２８は、入力画像形成装置１２および出力画像形成装置１８との間をインタフェースするソフトウェアシステムとして実現されている。このソフトウェアシステムは、連続階調デジタルレーザ画像生成器などの出力画像形成装置１８の一部として、あるいは入力画像形成装置１２と出力画像形成装置１８との間での画像情報の通信を制御する離散的な装置の一部として実現することもできるものである。入力画像形成装置１２によって生成される画像情報には、画像形成動作要求と、出力画像形成装置１８によって処理されるべき画像を表すデジタル画像値を有する画像データとを含む。説明しやすくするために、画像を表すデジタル画像値の形の画像情報は別々の通信路で送受信され、パイプライン３０では画像要求の形の画像情報を送受信するものとして説明する。しかしながら、画像情報に対する要求とデジタル画像値を有する画像データの両方の画像情報を送受信するようパイプライン３０を構成することも可能である。
各入力インタフェースコンポーネント１４は、入力ドライバコンポーネント２０のうちの１つを介し、複数の異なる入力インタフェースプロトコルのうちの１つを使用して入力画像形成装置１２からの画像情報を受信するよう構成されている。各入力インタフェースプロトコルは入力画像形成装置１２のうちの１つと特に関連しており、特定の入力画像形成装置と通信するためのモジュール性毎の要件も反映している。各入力インタフェースコンポーネント１４も、受信された画像情報の内容に基づいて、入力インタプリタコンポーネント２２のうちの１つを介し、入力インタフェースプロトコルのうちの１つを使用して第１の画像形成要求を生成するよう構成されている。第１の画像形成要求は、出力インタフェースコンポーネント１６と通信するための入力インタプリタコンポーネント２２によって変換されるものと同様に、入力画像形成装置１２によって生成される指示を表している。
各出力インタフェースコンポーネント１６は、第１の画像形成要求の内容に基づいて、出力インタプリタコンポーネント２４のうちの１つを介し、複数の異なる出力プロトコルのうちの１つを使用して第２の画像形成要求を生成するよう構成されている。第２の画像形成要求は、出力画像形成装置１８と通信するための出力インタプリタコンポーネント２４によって変換されるものと同様に、第１の画像形成要求の内容を表している。各出力インタフェースプロトコルは、出力画像形成装置１８の種類に特に関連しており、入力インタフェースプロトコルと同様に特定の出力画像形成装置と通信を行うために必要な要件を反映している。さらに、各出力インタフェースコンポーネント１６は、出力インタフェースプロトコルを使用し、出力ドライバコンポーネント２６を介して出力画像形成装置との間で第２の画像形成要求を送受信するよう構成されている。
入力インタフェースコンポーネント１４および出力インタフェースコンポーネント１６のサブコンポーネントすなわち、入力ドライバコンポーネント２０、入力インタプリタコンポーネント２２、出力インタプリタコンポーネント２４および出力ドライバコンポーネント２６について、ここでは入力インタフェースコンポーネントならびに出力インタフェースコンポーネントを一体に形成された１個のソフトウェアモジュールとしてみなすことにする。しかしながら、入力インタフェースコンポーネント１４を離散的な入力ドライバコンポーネント２０および離散的な入力インタプリタコンポーネント２２によって実現し、同様に、出力インタフェースコンポーネント１６を離散的な出力インタプリタコンポーネント２４および離散的な出力ドライバコンポーネント２６によって実現することが好ましい。サブコンポーネントを離散的にすることで、各インタフェースコンポーネント１４および１６の機能をモジュール性の高い小さなパッケージに分割することができる。一例として、モジュール性を高めると、入力画像形成装置１２用のハードウェアのインタフェース仕様を変更する際にも、入力インタフェースコンポーネント１４全体を構成しなおすのではなく入力ドライバコンポーネント２０を再構成するだけですむ。
各入力インタフェースプロトコルには、入力ドライバコンポーネント２０に対して適用可能な入力ドライバプロトコルと、入力インタプリタコンポーネント２２に対して適用可能な入力インタプリタプロトコルの両方が含まれる。個々の入力画像形成装置１２の通信要件に応じて適当な入力ドライバプロトコルを求め、個々の入力画像形成装置の画像情報のフォーマットに応じて適当な入力インタプリタプロトコルを求める。画像情報のフォーマットは、特定の入力画像形成装置１２のプロトコルを使用して生成される画像形成要求の種類を表す。入力ドライバプロトコルは、入力ドライバコンポーネント２０が入力画像形成装置１２からの画像情報をどのように転送すべきかを指定する。入力インタプリタプロトコルは、入力インタプリタコンポーネント２２が第１の画像形成要求を生成するための画像情報をどのように解釈すべきかを指定する。入力ドライバプロトコルおよび入力インタプリタプロトコルは、例えばＭＲ、ＣＴ、従来のＸ線、超音波など入力画像形成装置１２の種類の違いならびにシーメンスや東芝、ＧＥ、Pickerなどの製造業者の違いによって大幅に異なることがある。
各出力インタフェースプロトコルには、出力インタプリタコンポーネント２４に対して適用可能な出力インタプリタプロトコルと、出力ドライバコンポーネント２６に対して適用可能な出力ドライバプロトコルの両方が含まれている。出力ドライバプロトコルは出力画像形成装置１８の通信要件に応じて定められ、出力画像形成装置の画像情報のフォーマットに応じて適当な出力インタプリタプロトコルが決められる。出力インタプリタプロトコルは、出力画像形成装置１８が理解できる形で第２の画像形成要求を生成するための第１の画像形成要求を、出力インタプリタコンポーネント２４がどのように解釈すべきかを指定する。入力ドライバプロトコルは、出力ドライバコンポーネント２０が出力画像形成装置１８に対して第２の画像形成要求をどのように転送すべきかを指定する。入力インタフェースプロトコルの場合と同様に、出力インタフェースプロトコルも変化することがある。例えば、出力ドライバプロトコルと出力インタプリタプロトコルはいずれも、３Ｍ製レーザ画像生成器の場合で例えば８３１、９５２またはSupersetなどの出力画像形成装置１８によって得られる機能の種類によって異なることがある。
特定のプロトコルを機能面で特定するにもかかわらず、例えば全てが入力ドライバコンポーネントであるなど、同じような種類のコンポーネント２０、２２、２４、２６を構成して複数の共通のタスクを実行する。例えば、入力ドライバコンポーネント２０は特定の入力画像形成装置１２との通信に必要な一組の共通のタスクをシェアする。入力ドライバコンポーネント２０は、特定の入力画像形成装置１２との間で画像情報を送受信するのに必要な割込、バッファ、ハンドシェーキングなどのハードウェア仕様に対処するよう構成されている。入力ドライバコンポーネント２０を、パケット化や初期化などの入力画像形成装置１２の特定の要求に対処するよう構成してもよい。入力ドライバコンポーネント２０は、シリアルインタフェース、パラレルインタフェース、ネットワークインタフェースまたはその他の機構を介して通信を実施する知識からパイプライン３０の残りを分離して、必要な通信タスクを全て実行する。要約すると、入力ドライバコンポーネント２０の責任は２倍である。第１に、入力ドライバコンポーネント２０は、入力画像形成装置１２から画像情報を受信し、パイプライン３０の次段すなわち入力インタプリタコンポーネント２２用の画像情報を準備する。第２に、入力ドライバコンポーネント２０は、双方向パイプライン３０から送出されるあらゆる応答を、後述するように入力画像形成装置１２に送信する。
入力インタプリタコンポーネント２２すなわちパイプライン３０における次のコンポーネントもまた、特定の入力インタプリタプロトコルを考慮することなく他の入力インタプリタコンポーネントと共通の一組のタスクをシェアする。主に、入力ドライバコンポーネント２０から画像情報を得た後、入力インタプリタコンポーネント２２はその画像情報に含まれている要求を分析し、これらの要求を変換して、出力画像形成装置１８によって実行される動作に対応する第１の画像形成要求を生成する。第１の画像形成要求には、出力画像形成装置１８によって実行される様々な共通の画像形成処理に対する要求が含まれている。一般的な医療用画像形成システムでは、これらの要求に、例えば出力画像形成装置１８によって画像印刷ジョブを開始する要求や、既に開始されている画像印刷ジョブを中止する要求、印刷対象となる画像のフォーマットを定義または修正する要求、既に得られている画像を表す画像データセットを削除する要求、特定の画像位置に画像データを格納するための要求などを含ませることができる。
入力インタプリタコンポーネント２２が入力画像形成装置１２によって生成された要求をどのように解釈するかについては、特定の入力インタプリタプロトコルによって異なることがある。入力インタプリタコンポーネント２２は、特定の入力画像形成装置１２によって生成される画像情報に固有の正確なフォーマット、指示およびタイミングに関する制約を理解する。しかしながら、入力インタプリタコンポーネント２２は全て第１の画像形成要求を生成する共通かつ基本的な機能を提供する。入力インタプリタコンポーネント２２は第１の画像形成要求をパイプライン３０に沿って送信する。第１の画像形成要求を双方向パイプライン３０の下流にあるコンポーネントによって処理し、応答が受信された後は、入力インタプリタコンポーネント２０が入力画像形成装置１２用の適当な応答を形成する。入力インタプリタコンポーネント２２は、パイプライン３０に沿って入力ドライバコンポーネント２０を介して上記の応答を入力画像形成装置１２まで送信する。入力ドライバコンポーネント２０は、応答を入力画像形成装置に送信するのに必要な通信要件に対応している。
出力インタプリタコンポーネント２４は、パイプライン３０における第３のコンポーネントである。出力画像形成装置１８は、３Ｍ製のレーザ画像生成器の場合だと８３１、９５２またはSupersetなどの多くの異なるプロトコルのうちの１つと会話をすることができる。出力インタプリタコンポーネント２４は、パイプライン３０を介して、入力インタプリタコンポーネント２２によって生成された第１の画像形成要求を受信するとともに、第１の画像形成要求を解釈して第２の画像形成要求を生成し、これによって出力画像形成装置１８に必要な特定のプロトコルを確認するよう構成されている。第２の画像形成要求は、実質的には第１の画像形成要求に相当するが、出力画像形成装置１８によって理解される出力プロトコルを用いて構成されている。このため、第２の画像形成要求は、第１の画像形成要求によって指定される同一の画像形成処理用の要求として機能する。出力インタプリタコンポーネント２４がどのように指示を解釈するかについては、出力画像形成装置１８によって示される特定の出力インタプリタプロトコルに基づいて変化させることができるが、出力インタプリタコンポーネント２４は全て、出力画像形成装置によって理解されるプロトコルにおける第２の画像形成要求を生成する共通のタスクをシェアする。出力インタプリタコンポーネント２４は、第２の画像形成要求をパイプライン３０に沿って送信する。出力画像形成装置１８が第２の画像形成要求を処理し、パイプライン３０を介して受信される応答を公式化すると、出力インタプリタコンポーネント２４は出力プロトコルによって特定されるあらゆる情報を除去して入力インタプリタコンポーネント２２に適した応答を形成する。
出力ドライバコンポーネント２６は、パイプライン３０における第４のコンポーネントである。入力ドライバコンポーネント２０と同様に、全ての出力ドライバコンポーネント２６は共通の一組の通信タスクを実施する。具体的には、出力ドライバコンポーネント２６は、特定の出力画像形成装置１８との間で画像情報を送受信するのに必要な割込、バッファ、ハンドシェーキングなどのハードウェア仕様に対処するよう構成されている。出力ドライバコンポーネント２６は、シリアルインタフェース、パラレルインタフェースまたはデュアルポートＲＡＭなどを介して出力画像形成装置１８と通信を行う知識からパイプライン３０の残りを分離する。出力ドライバコンポーネント２６は、あらゆる通信要件を維持したまま出力インタプリタコンポーネント２４によって生成された第２の画像形成要求を出力画像形成装置１８に送信する。さらに、出力ドライバコンポーネント２６は出力画像形成装置１８からの応答を受信し、双方向パイプライン３０を介して出力インタプリタコンポーネント２４に送信するための応答を生成する。
インタフェース監視コンポーネント２８は、パイプライン３０の構造を定義するものであり、本ソフトウェアシステムの第５のコンポーネントである。インタフェース監視コンポーネント２８は、プロトコルの異なる多数のコンポーネント２０、２２、２４、２６と選択的に相互に接続されて通信を行い、大きな柔軟性を提供するよう構成されている。このような柔軟性が得られることで、医療用画像形成システム１０は多種多様な入力画像形成装置１２と様々な機能を有する１個以上の出力画像形成装置１８との間で通信を行うことができるようになる。このように、インタフェース監視コンポーネント２８は、機能的に独立した各コンポーネント２０、２２、２４、２６を責任が明確に定められインタフェースが定義されたブロックとして処理する。インタフェース監視コンポーネント２８は、環境に基づいて適当な一連のブラックボックスを選択し、これらのブラックボックス同士を結合して完全かパイプライン３０を形成する。さらに別の利点として、インタフェース監視コンポーネント２８はこれらのコンポーネントを動的に結合して既存の画像形成環境に適した通信パイプライン３０を形成するよう構成されたものであると好ましい。さらに、インタフェース監視コンポーネントは、異なるプロトコルを仕様して構成された複数（１〜Ｎ）の通信パイプライン３０を有する、規模の変更が可能なソフトウェアアーキテクチャを生成するよう構成されている。このような規模の変更が可能なアーキテクチャを用いることで、出力画像形成装置１８は、各パイプライン３０によって提供されるものと同様の必要なプロトコルを用いてシェアする形で複数の入力画像形成装置１２と同時に通信することができるようになる。あるいは、複数の出力画像形成装置１８を提供し、それぞれ特定のパイプライン３０と接続して通信できるようにしておくことも可能である。
インタフェース監視コンポーネント２８は、ソフトウェアアーキテクチャの規模を変更して環境要件に合わせ、出力画像形成装置１８とのインタフェースを要求している入力画像形成装置１２にできるだけ多くのパイプライン３０を構築する。インタフェース監視コンポーネント２８は、特定の入力画像形成装置１２、特定の出力画像形成装置１８および所望のハードウェアインタフェースと適合させるのに必要な特定のプロトコルを有する一連のコンポーネント２０、２２、２４、２６を選択的に結合する。コンポーネント２０、２２、２４、２６の性質上、これらのコンポーネントは、インタフェース監視コンポーネント２８によってモジュール的にパイプライン３０の内外で選択的に交換される。コンポーネント２０、２２、２４、２６は各々、一組のソフトウェアインタフェースによって種類は似ているがプロトコルは異なる同種の他のコンポーネントと交換可能なように作られている。具体的には、各コンポーネントは特定のプロトコルに基づいて構成されているが、プロトコルを同種の各コンポーネント用の汎用ベースクラスプロトコルに変換する「ベースクラス」ソフトウェアインタフェースを含んでいる。パイプラインの他のコンポーネントの構成に影響することなくパイプライン３０におけるコンポーネント２０、２２、２４、２６のどれでも交換することができるように、ベースクラスインタフェースを各コンポーネントに構成すると好ましい。このように、個々のコンポーネント２０、２２、２４、２６を再利用することができ、かつては再設計作業にかかっていたコストが大幅に削減される。
例えば、パイプライン３０をシーメンスの入力画像形成装置１２と３ＭのSuperSet機能を用いた出力画像形成装置１８との間でシリアルデータ通信できるよう構成すると、インタフェース監視コンポーネント２８は、（１）シーメンスの入力画像形成装置と関連したシリアルハードウェアインタフェースを介して画像形成情報を受信するのに適した入力ドライバプロトコルを有する入力ドライバコンポーネント２０、（２）シーメンスの入力画像形成装置から受信する画像情報のフォーマットに基づいて第１の画像形成要求を生成するのに適した入力インタプリタプロトコルを有する入力インタプリタコンポーネント２２、（２）３ＭのSuperSet出力画像形成装置によって理解される第２の画像形成要求を生成するのに適した出力インタプリタプロトコルを有する出力インタプリタコンポーネント２４および（４）３ＭのSuperSet出力画像形成装置と関連したシリアルハードウェアインタフェースを介して第２の画像形成要求を送受信するのに適した出力ドライバプロトコルを有する出力ドライバコンポーネント２６を通信的に結合する。あるいは、東芝の入力画像形成装置１２と３ＭのSuperSet出力画像形成装置１８との間でシリアルデータ通信を行うために上述したパイプライン３０に変更を加える場合、入力ドライバコンポーネント２０および入力インタプリタコンポーネント２２を東芝のモジュール性に適した入力ドライバプロトコルおよび入力インタプリタプロトコルに基づいて構成されたコンポーネントと交換しさえすればよい。出力インタフェースコンポーネント１６は、３ＭのSuperset構成の出力インタプリタコンポーネント２４と３ＭのSupersetシリアル構成の出力ドライバコンポーネント２６とを含むものであるが、これはすでに入力画像形成装置１２とは無関係に出力画像形成装置１８の要件に基づいて構成されているため、変更に影響されることはない。このように、インタフェース監視コンポーネント２８は、（１）東芝の入力画像形成装置と関連したシリアルハードウェアインタフェースを介して画像形成情報を受信するのに適した入力ドライバプロトコルを有する入力ドライバコンポーネント２０、（２）東芝の入力画像形成装置から受信する画像情報のフォーマットに基づいて第１の画像形成要求を生成するのに適した入力インタプリタプロトコルを有する入力インタプリタコンポーネント２２、（２）３ＭのSuperSet出力画像形成装置によって理解される第２の画像形成要求を生成するのに適した出力インタプリタプロトコルを有する出力インタプリタコンポーネント２４および（４）３ＭのSuperSet出力画像形成装置と関連したシリアルハードウェアインタフェースを介して第２の画像形成要求を送受信するのに適した出力ドライバプロトコルを有する出力ドライバコンポーネント２６を通信的に結合する。
もう１つの例として、東芝の入力画像形成装置１２と３Ｍの９５２出力画像形成装置１８との間でシリアルデータ通信を行うために上述したパイプライン３０に変更を加える場合、出力インタフェースコンポーネント１６に変更を加えるだけでよい。具体的には、インタフェース監視コンポーネント２８は、（１）東芝の入力画像形成装置と関連したシリアルハードウェアインタフェースを介して画像形成情報を受信するのに適した入力ドライバプロトコルを有する入力ドライバコンポーネント２０、（２）東芝の入力画像形成装置から受信する画像情報のフォーマットに基づいて第１の画像形成要求を生成するのに適した入力インタプリタプロトコルを有する入力インタプリタコンポーネント２２、（２）３Ｍの９５２出力画像形成装置によって理解される第２の画像形成要求を生成するのに適した出力インタプリタプロトコルを有する出力インタプリタコンポーネント２４および（４）３Ｍの９５２出力画像形成装置と関連したシリアルハードウェアインタフェースを介して第２の画像形成要求を送受信するのに適した出力ドライバプロトコルを有する出力ドライバコンポーネント２６を通信的に結合する。このように、汎用シリアル構成の入力ドライバコンポーネント２０と東芝製の入力インタプリタコンポーネント２２とを含む入力インタフェースコンポーネント１４には、変更による影響が及ぶことはない。
最後に、シリアルハードウェアインタフェースを有する東芝の入力画像形成装置１２と３ＭのデュアルポートＲＡＭを有する９５２出力画像形成装置１８との間でシリアルデータ通信を行うために上述したパイプライン３０に変更を加える場合、出力インタフェースコンポーネント１６に変更を加えるだけでよい。具体的には、インタフェース監視コンポーネント２８は、（１）東芝の入力画像形成装置と関連したシリアルハードウェアインタフェースを介して画像形成情報を受信するのに適した入力ドライバプロトコルを有する入力ドライバコンポーネント２０、（２）東芝の入力画像形成装置から受信する画像情報のフォーマットに基づいて第１の画像形成要求を生成するのに適した入力インタプリタプロトコルを有する入力インタプリタコンポーネント２２、（２）３Ｍの９５２出力画像形成装置によって理解される第２の画像形成要求を生成するのに適した出力インタプリタプロトコルを有する出力インタプリタコンポーネント２４および（４）３Ｍの９５２出力画像形成装置と関連したデュアルポートＲＡＭハードウェアインタフェースを介して第２の画像形成要求を送受信するのに適した出力ドライバプロトコルを有する出力ドライバコンポーネント２６を通信的に結合する。このように、汎用シリアル構成の入力ドライバコンポーネント２０と東芝製の入力インタプリタコンポーネント２２とを含む入力インタフェースコンポーネント１４には、変更による影響が及ぶことはない。
上述したような互換性を高めるために、コンポーネント２０、２２、２４、２６間のソフトウェアインタフェースを予め定義し、各種コンポーネントを汎用的なものとしておかなければならない。しかしながら、同時に個々のコンポーネント２０、２２、２４、２６を、特定のプロトコルに対して指定された機能を実施できるように構成しなければならない。本発明によれば、これについての解決策は、例えば入力ドライバコンポーネント２０などの各種コンポーネント用の汎用ベースクラスプロトコルを開発するのに用いられているオブジェクト指向技術にある。汎用ベースクラスプロトコルは、コンポーネントによって提供される関数およびこのような関数を呼び出すための手順を指定する。特定のプロトコルコンポーネントは各々対応するベースプロトコルから「継承」され、環境に適合するようインタフェースを実施する。本願明細書において、「インヘリタンス（継承）」という用語は、抽象的なデータ型を拡張してクラス／サブクラス関係を実現するためのオブジェクト指向プログラミング概念を意味する。クラスは、共有している特徴を再利用するのではなく、選択されたデータメンバと複数のクラスのメンバ関数とを継承することができる。
クラスを引き継ぐことで、１つのクラスのメンバをあたかも第２のクラスのメンバであるかのようにして使用することができるようになる。他のクラスから継承されたメンバを拡張または交換する操作以外は、サブクラスを利用するのにプログラムを追加する必要はない。オブジェクト指向システムを開発する際、サブクラスは適当な機能が得られるまで既存のクラスから導出される。サブクラスを導出することで、クラス階層が形成される。クラス階層は、ベースクラスと呼ばれる特定の１つのクラスから派生している。ベースクラスは、全てのサブクラスに共通の最低限の動作を含む。本発明によれば、各コンポーネント２０、２２、２４、２６は特定のプロトコルに基づいて構成されるが、ベースクラスプロトコルのサブクラスとしても機能する。各コンポーネント２０、２２、２４、２６はベースクラスプロトコルを継承し、最低限の関数がベースクラス要件を満たすようこれらの関数を利用するため、各コンポーネントを、同一のベースクラスプロトコルを継承している類似のコンポーネントと直接入れ換えることができる。オブジェクト指向技術によって達成される互換性から、インタフェースを別途開発することなくパイプライン３０に各コンポーネントを効率よくプラグインする「ダイレクトコネクト（direct connect）」ソフトウェアアーキテクチャが得られる。
第２図は、コンポーネント２０、２２、２４、２６の互換性を高めるオブジェクト指向プロトコル階層の一例である。プロトコル階層は、各々汎用的なベースクラスプロトコルから「継承」される特定のプロトコル用のコンポーネント２０、２２、２４、２６を利用することを示している。例えば、入力ドライバのベースプロトコル３２は、汎用的なシリアル入力ドライバプロトコル３４，ＳＣＳＩ入力ドライバプロトコル３６、シーメンスのシリアル入力ドライバプロトコル３８またはパラレル入力ドライバプロトコル３９などの入力画像形成装置１２に関連した異なるハードウェアインタフェース要件に対する「継承」入力ドライバプロトコルを複数個含むことができる。ベースクラスの入力インタプリタプロトコル４０は、ＧＥの入力インタプリタプロトコル４２、東芝の入力インタプリタプロトコル４４、シーメンスの入力インタプリタプロトコル４６またはPickerの入力インタプリタプロトコル４８などの種類または製造業者の異なる入力画像形成装置１２用の継承入力インタプリタプロトコルを複数個含むことができる。第２図に示されるように、ベースクラスの入力インタプリタプロトコル４０は、キーパッドプロトコル５０などのユーザインタフェース装置用の継承プロトコルを含むこともできる。
同様に、ベースクラスの出力インタプリタプロトコル５２は、３ＭのSuperSet出力インタプリタプロトコル５４、３Ｍの８３１出力インタプリタプロトコル５６または３Ｍの９５２出力インタプリタプロトコル５８などの種類の異なる出力画像形成装置１８用の継承出力インタプリタプロトコルを複数個含むことができる。最後に、ベースクラスの出力ドライバプロトコル６０は、デュアルポートＲＡＭ出力ドライバプロトコル６２、シリアル出力ドライバプロトコル６４またはパラレル出力ドライバプロトコル６５などの出力画像形成装置１８に関連した異なるハードウェアインタフェース要件に対する継承出力ドライバプロトコルを複数個含むことができる。上述した各継承プロトコルには、コンポーネント２０、２２、２４、２６によって提供される、プロトコル毎の関数が含まれるが、これらの継承プロトコルは対応するベースクラスプロトコル３２、４０、５２、６０から継承される関数を汎用インタフェースを介して利用する。上述したベースクラスプロトコル３２、４０、５２、６０の各々について、医療用画像形成システム環境における要件に応じて様々な他の継承プロトコルも利用できる。
第３図に示されるように、インタフェース監視コンポーネント２８は、クライアント-サーバアーキテクチャに基づいてパイプライン３０を定義するものであると好ましい。第３図において、コンポーネントＡからコンポーネントＢを指している矢印は、コンポーネントＡがサーバコンポーネントＢのクライアントコンポーネントであるということを示している。入力ドライバコンポーネント２０と入力画像形成装置１２との間の両頭矢印および出力ドライバコンポーネント２６と出力画像形成装置１８との間の両頭矢印は、クライアント-サーバ関係を示すものではなく、医療用画像形成システム１０のハードウェア／ソフトウェアインタフェースを示すものである。第３図において矢印で示されるように、インタフェース監視２８は、入力インタプリタコンポーネント２２が入力ドライバコンポーネント２０および出力インタプリタコンポーネント２４の両方のクライアントコンポーネントになり、出力インタプリタコンポーネント２４が出力ドライバコンポーネント２６のクライアントコンポーネントになるようにクライアント-サーバ関係を定義するものであると好ましい。この結果、入力ドライバコンポーネント２０および出力インタプリタコンポーネント２４が入力インタプリタコンポーネント２２のサーバコンポーネントになり、出力ドライバコンポーネント２６が出力インタプリタコンポーネント２４にとってのサーバコンポーネントになる。インタフェース監視コンポーネント２８自体、入力ドライバコンポーネント２０と、入力インタプリタコンポーネント２２と、出力インタプリタコンポーネント２４と、出力ドライバコンポーネント２６とのクライアントコンポーネントである。
上述したクライアント-サーバ関係では、入力ドライバコンポーネント２０および出力ドライバコンポーネント２６はいずれも、それぞれ純粋に入力インタプリタコンポーネント２２および出力インタプリタコンポーネント２４にとってのサーバコンポーネントである。入力ドライバコンポーネント２０および出力ドライバコンポーネント２６は、低水準のハードウェア要件に影響し、それぞれ高水準の入力インタプリタコンポーネント２２および出力インタプリタコンポーネント２４の制御下にある。入力インタプリタコンポーネント２２は、出力インタプリタコンポーネント２４のクライアントコンポーネントであり、入力インタプリタコンポーネントが出力画像形成装置１８を制御するための関数を提供する。出力インタプリタコンポーネント２４は、入力インタプリタコンポーネント２２との間で通信を開始することはなく、入力インタプリタコンポーネントからの要求時にサービスを提供する。最後に、各コンポーネント２０、２２、２４、２６は、インタフェース監視コンポーネント２８にとってのサーバコンポーネントになる。このように、インタフェース監視コンポーネント２８は最終的にはソフトウェアシステム全体を制御する。
クライアント-サーバ関係にあるコンポーネント２０、２２、２４、２６間での通信は、遠隔手続き呼出し（ＲＰＣ）を行うことによって実施される。遠隔手続き呼出しは、複雑に分散されたソフトウェアシステムにおいて用いられることの多い一般的な通信機構である。クライアントコンポーネントは、対応するサーバコンポーネントに対して遠隔手続き呼出しを行うことによって個々の関数を実行する。遠隔手続き呼出しを使用することで、個々のコンポーネントの詳細および従属性、すなわちプロトコル毎に指定される特徴が隠蔽化される。遠隔手続き呼出しは、コンポーネント内通信に必要な全ての機構に対処する。この結果、通信機構は汎用的なまま維持され、プロトコル毎に指定される機構をコンポーネント毎に設計する必要はなくなる。各コンポーネント２０、２２、２４、２６は、クライアントコンポーネントに対してサービスを行うように構成されているが、そのクライアントコンポーネントをどのコンポーネントあるいは何個のコンポーネントがサーバコンポーネントとして実際に利用しているかについては把握していない。コンポーネント２０、２２、２４、２６は、プロトコル毎に指定される従属性を呈することなく単純にクライアントコンポーネントの要求を実行しているだけである。
遠隔手続き呼出しを使用して以下のように関数を実行する。まず、クライアントコンポーネントによって実施されるソフトウェアプロセスで個々の関数を実行する必要がある場合、このプロセスは識別子によって関数を呼び出すだけである。一般に「クライアントスタブ」と呼ばれる、クライアントコンポーネント内に常駐しているソフトウェアの層は、関数呼出しをトラップする。クライアントスタブが他のサーバコンポーネント内に実際に存在する関数を呼び出してこれを実施するのに必要なソフトウェアコードを求める場合、このクライアントスタブは、関数呼出しによって実行されるデータならびに必要なパケット化およびアドレス指定を全て含むメッセージを生成する。次に、クライアントスタブはソフトウェアシステム内に存在するリアルタイムオペレーティングシステムを介してサーバコンポーネントにメッセージを送信する。サーバモジュールは、メッセージを受信するサーバスタブとして知られるソフトウェアコードの層を含んでいる。サーバスタブはメッセージを抽出し、実際にメッセージから取り出されたデータを用いて正しいローカル関数を呼び出す。要求された情報を返しながら、あたかも最初に呼び出されたローカルなものであるかのようにローカル関数が実行される。サーバスタブは、返された情報に基づいて応答を生成し、オペレーティングシステムを介してこの応答をクライアントコンポーネントに送信する。応答を受信すると、クライアントスタブは返された情報を取り出し、その関数を最初に呼び出したローカルソフトウェアプロセスにこの情報を送信する。ローカルソフトウェアプロセスは、モジュール内通信が起こっても気づかないままである。
以下のセクションでは、本発明による医療用画像形成システム１０の一例としての実施例において各ベースクラスプロトコルを利用する方法について詳細に説明する。特に、セクションＡ〜Ｄでは、Ｃ＋＋オブジェクト指向プログラム言語における例示の目的で示されるコンポーネント２０、２２、２４、２６を用いて得られるサービスの定義および要件の例を述べる。ここで、コメントが適用可能な場合にはコメントも含む形とする。以下、個々のコンポーネントの機能を例示するためにＣ＋＋コードを使用するが、「ホスト」というラベルについては入力画像形成装置１２を表し、「レーザ画像生成器」または「ＬＩ」というラベルは出力画像形成装置１８を表すものとする。
Ａ． 入力ドライバのベースクラスプロトコル
ここに開示する一例としての実施例において、入力ドライバのベースクラスプロトコルには、入力ドライバコンポーネント２０がそのクライアントコンポーネントすなわちインタフェース監視コンポーネント２８および入力インタプリタコンポーネント２２に提供するのに必要な遠隔手続き呼出しが７回含まれる。遠隔手続き呼出しを利用して、クライアントコンポーネントは入力ドライバコンポーネント２０を介して外部の入力画像形成装置１２との間を直接インタフェースすることができる。以下、７回の遠隔手続き呼出しについて、処理されるパラメータのタイプおよび実行される関数の点から説明する。
１． xmit_message（送信メッセージ）
パラメータ タイプ
message（メッセージ） char *（文字型）
返り値 タイプ
Driver return code（ドライバリターンコード） DRIVER_RC
上述したＲＰＣは、メッセージを入力ドライバコンポーネントに渡し、入力画像形成装置１２に送信する。入力画像形成装置１２へのメッセージの送信に必要な全ての通信は、入力ドライバコンポーネント２０によって処理される。
２． receive_message（受信メッセージ）
パラメータ タイプ
message（メッセージ） char *（文字型）
返り値 タイプ
Driver return code（ドライバリターンコード） DRIVER_RC
上述したＲＰＣは、ホストから送信された入力ドライバコンポーネント２０からのメッセージを検索する。繰り返すが、入力画像形成装置１２へのメッセージの送信に必要な全ての通信は、入力ドライバコンポーネント２０によって処理される。
３． set_xmit_timeout（送信タイムアウト設定）
パラメータ タイプ
timeout（タイムアウト） int（整数型）
返り値 タイプ
Driver return code（ドライバリターンコード） DRIVER_RC
上記ＲＰＣは、入力画像形成装置１２にメッセージを送信する際に入力ドライバコンポーネント２０によって使用されるタイムアウト値を設定する。
４． set_async_func
パラメータ タイプ
client ptr（クライアントポインタ） FE_CLIENT_PTR
method ptr（メソッドポインタ） FE_METHOD_PTR
返り値 タイプ
Driver return code（ドライバリターンコード） DRIVER_RC
上記ＲＰＣは、クライアントコンポーネントに関連した非同期ハンドラに対する処理を入力ドライバコンポーネント２０に渡す。上記ＲＰＣは、入力ドライバコンポーネント２０がクライアントコンポーネントに対して既に起こった非同期イベントを通知するための手段となる。入力ドライバコンポーネント２０に対して相対的に起こる唯一の非同期イベントはMSG_PENDINGである。これは、入力画像形成装置１２から入力ドライバコンポーネントへのメッセージの送信が完全に終了し、入力インタプリタコンポーネント２２への送信の準備ができていることを示す。
５． set_debug_level
パラメータ タイプ
debug level（デバッグレベル） DEBUG_LEVEL
返り値 タイプ
Driver return code（ドライバリターンコード） DRIVER_RC
上記ＲＰＣは、クライアントコンポーネントで入力ドライバコンポーネントのデバッグレベルを設定できるようにする。デバッグレベルは、NO_DEBUG、LOW_DEBUG、MEDIUM_DEBUGおよびHIGH_DEBUGである。このパラメータは、デバッグ中に表示される情報に影響する。
６． start_comm（通信開始）
パラメータ タイプ
none（なし）
返り値 タイプ
Driver return code（ドライバリターンコード） DRIVER_RC
上記ＲＰＣは、入力ドライバコンポーネント２０と入力画像形成装置１２との間の通信を開始させる。
７． stop_comm（通信終了）
パラメータ タイプ
none（なし）
返り値 タイプ
Driver return code（ドライバリターンコード） DRIVER_RC
上記ＲＰＣは、入力ドライバコンポーネント２０と入力画像形成装置１２との間の通信を不能にする。
上述したように、各ＲＰＣは、入力ドライバコンポーネント２０から３つのドライバリターンコードすなわち（１）RPC_OK、（２）PORT_BUSYおよび（３）NO_MESSAGEのうちの１つを返す。ドライバリターンコードは、Ｃ＋＋では以下のように定義される。

入力ドライバコンポーネント２０用の実際のベースクラスプロトコルは、Ｃ＋＋では以下のように定義される。

Ｂ． 入力インタプリタのベースクラスプロトコル
本実施例では、入力インタプリタのベースクラスプロトコルには、入力インタプリタコンポーネント２２がそのクライアントコンポーネントすなわちインタフェース監視コンポーネント２８に提供するのに必要な遠隔手続き呼出しが４回含まれる。遠隔手続き呼出しを利用して、インタフェース監視コンポーネント２８は入力インタプリタコンポーネント２２と通信することができる。以下、４回の遠隔手続き呼出しについて、処理されるパラメータのタイプおよび実行される関数の点から説明する。
１． rcvConfiguration（受信コンフィギュレーション）
パラメータ タイプ
pointer to parameters（パラメータへのポインタ） Param_Blk
返り値 タイプ
void（なし） n/a（なし）
上記ＲＰＣは、コンポーネントに対するコンフィギュレーションパラメータを指すポインタを入力インタプリタコンポーネント２２に渡す。このパラメータは、システム１０が最後にパワーダウンシーケンスに入って以来格納されている。このパラメータは、出力画像形成装置１８に接続されたメモリの読み出し専用ブロックに格納されている。このように、入力インタプリタコンポーネント２２によってなされる変更は、いかなるものであっても次のパワーアップに影響することはない。
２． li_event_handler（レーザ画像生成器のハンドラ）
パラメータ タイプ
laser imager event（レーザ画像生成器のハンドラ） IO_EVENT
返り値 タイプ
void（なし） n/a（なし）
上記ＲＰＣは、入力ドライバコンポーネント２０から非同期イベントを受信する。非同期イベントは、入力画像形成装置１２からのメッセージの受信を含み、入力ドライバコンポーネント２０について上述したものである。
３． io_event_handler（入出力イベントのハンドラ）
パラメータ タイプ
io event（入出力イベント） LI_INTERFACE_EVENT
返り値 タイプ
void（なし） n/a（なし）
上記ＲＰＣは、出力インタプリタコンポーネント２４および出力ドライバコンポーネント２６を介して出力画像形成装置１８から非同期イベントを受信する。出力画像形成装置１８から送信されてくる同期イベントについては、出力インタプリタコンポーネント２４を例に挙げて詳細に後述する。
４． set_debug_level（デバッグレベル設定）
パラメータ タイプ
debug level（デバッグレベル） DEBUG_LEVEL
返り値 タイプ
Driver return code（ドライバリターンコード） DRIVER_RC
上記ＲＰＣは、入力インタプリタコンポーネント２２用のデバッグレベルをクライアントコンポーネントすなわちインタフェース監視コンポーネント２８で設定できるようにする。デバッグレベルは、NO_DEBUG、LOW_DEBUG、MEDIUM_DEBUGおよびHIGH_DEBUGである。このパラメータは、デバッグ中に表示される情報に影響する。
上述したように、入力インタプリタコンポーネント２２は、出力画像形成装置１８から送信されてくる非同期イベントを処理するための機構を提供する。このイベントは、入力インタプリタコンポーネント２２に出力画像形成装置１８における状態の変化を通知するよう作用する。出力画像形成装置１８の状態を示すイベントには様々なものがあり、例えば以下のものが挙げられる。（１）出力画像形成装置に関連しているフィルムプロセッサの状態が変化したことを示すFP_status、（２）出力画像形成装置に関連した画像形成ハードウェアの状態が変化したことを示すPR_status_change、（３）出力画像形成装置内で画像データをフォーマットすることに関与する画像管理システムの状態が変化したことを示すIMS_status_change、（４）画像形成ジョブの状態が変化したことを示すJOB_status_changeおよび（５）画像データのバックグラウンド転送に必要な転送ジョブの状態が変化したことを示すXFR_status_change。上記の状態イベントの機能は、入力インタプリタコンポーネント２２が出力画像形成装置１８を連続的にポーリングしなくてもよいようにすることである。
実際の入力インタプリタコンポーネント２２用のベースクラスプロトコルは、Ｃ＋＋では以下のように定義される。

Ｃ． 出力インタプリタのベースクラスプロトコル
入力インタプリタコンポーネント２２は、一組の画像形成オブジェクトを介して出力インタプリタコンポーネント２４との間をインタフェースする。画像形成オブジェクトは、遠隔手続き呼出し用のパラメータとして機能し、出力画像形成装置１８および画像形成プロセスの特徴に関して利用できる全ての情報を含んでいる。入力インタプリタコンポーネント２２は、情報の任意の部分を利用して残りを無視することができる。ここでは、（１）ボックスオブジェクト、（２）フォーマットオブジェクト、（３）画像オブジェクト、（４）テスト画像オブジェクト、５）ストリングオブジェクトおよび６）様々な汎用画像形成パラメータオブジェクトを含む６個の画像形成オブジェクト定義がある。
フォーマットオブジェクトは、出力画像形成装置１８が画像を形成する画像形成メディアのシート全体について記述するために使用される。フォーマットオブジェクトは、フィルムタイプ、フィルムサイズ、ボーダーカラー、ボーダー密度などに関する情報を保持する。フォーマットオブジェクトの特徴は、Ｃ＋＋では以下のように定義される。

ボックスは、画像を保持するよう指定されたフィルムシート上の矩形領域である。ボックスは、位置、サイズ、コントラスト、色などの多くの特徴を有する。ボックス定義は個々のフォーマットと関連している。すなわち、個々のフォーマットに関して複数のボックスが使用される。以下のＣ＋＋コードは、ボックスオブジェクトおよびその特徴を記述したものである。

画像は、デジタル画像値を含む画像データによって表される。画像データは、出力画像形成装置１８に接続された画像メモリに格納されている。画像オブジェクトは、特定の特徴と画像とを関連付けるために使用される。上記のコードに示されるように、特徴には、画素長、画素幅、画素深さ、カラーフォーマットなどが含まれる。印刷時、使用するフォーマットについて定義されたボックスを画像で埋める。以下のＣ＋＋コードは、画像オブジェクトおよびその特徴を記述したものである。

テスト画像オブジェクトは、試験用に用いられる画像をシンボル化するのに用いられる。これらの画像はソフトウェア的に生成され、１枚の画像とは属性が異なる。以下のＣ＋＋コードは、テストイメージオブジェクトおよびその特徴を記述したものである。

ストリングオブジェクトは、画像メモリ内にＡＳＣＩＩテキストを保持するために使用される。また、ストリングオブジェクトは、長さ、強度、タイプなどのパラメータの使用を可能にする。以下のＣ＋＋コードは、ストリングオブジェクトおよびその特徴を記述したものである。

汎用パラメータオブジェクトは、全てのプロセスコンフィギュレーションパラメータを保持するのに使用される。このオブジェクトを用いて、レーザ画像生成器のパラメータを設定したり、あるいはパラメータの現在の設定を検索したりすることができる。いくつかのパラメータの例として、デフォルトベータテーブル、デフォルトカラーコントラスト、デフォルト出力先、デフォルトフィルムサイズおよびタイプなどが挙げられる。利用できるメモリ量、現在のソフトウェアリビジョン、全体の印刷待ち数などのいくつかのパラメータは読み出し専用であるため、設定することはできない。以下のＣ＋＋コードは、汎用パラメータオブジェクトおよびその特徴を記述したものである。

出力インタプリタコンポーネント２４の主な役目の１つは、出力画像形成装置１８の状態をクライアントコンポーネントすなわち入力インタプリタコンポーネント２２に伝達することである。状態伝達プロセスは、２つのステップを含む。出力インタプリタコンポーネント２４が出力画像形成装置１８における状態の変化を示すと、出力インタプリタコンポーネントによってクライアントコンポーネント中のイベントハンドラが直接呼び出される。イベントハンドラは、状態イベントを送る。繰り返すが、入力インタプリタのベースクラスプロトコルについて上述した考えられる状態イベントには、（１）FP_status_change、（２）PR_status_change、（３）IMS_status_change、（４）JOB_status_changeおよび（５）XFR_status_changeが含まれる。出力インタプリタコンポーネント２４は、上述した状態変化をクライアントすなわち入力インタプリタコンポーネント２２に通知するため、入力インタプリタコンポーネントはレーザ画像生成器を連続的にポーリングしなくてすむ。
状態変化を無視するか、あるいはさらに情報を要求するのは、クライアントすなわち入力インタプリタコンポーネント２２の役目である。全ての状態情報は、５個の状態オブジェクトの中に含まれている。フィルムプロセッサ、プリンタ、画像管理システム、ジョブおよびバックグラウンドジョブ（転送）についての状態オブジェクトが存在する。各状態オブジェクトは、警告やエラーが存在するか否か確認するために容易にチェックすることのできる状態フィールドを有する。警告またはエラーが存在する場合、警告構造またはエラー構造をさらに試験することができる。繰り返すが、クライアントは必要な情報のみを選択して使用することができる。以下のＣ＋＋コードは、各状態オブジェクトについての定義およびこれらのオブジェクトに含まれる構造を示すものである。

一例として挙げる本実施例では、出力インタプリタコンポーネント２４は１５種類の遠隔手続き呼出しを提供する。上述した画像形成オブジェクトおよび遠隔手続き呼出しを使用して、クライアントは出力画像形成装置１８を完全に動作させることができる。上述した画像形成オブジェクトに含まれるパラメータは全て「割り当て前の値」に初期化される。クライアントがパラメータを変更しなければ、出力インタプリタコンポーネント２４はこれを無視する。このような特徴があることで、クライアントは必要なパラメータのみを使用することができるようになる。出力インタプリタコンポーネント２４によって提供される各遠隔手順呼出しについては後述する。特に明示されなければ、以下の遠隔手順呼出しの各々についての返り値は、本開示において後述するLI_response型のレーザ画像生成器の応答オブジェクトである。
１． メディアプリントＲＰＣ
ａ． print（印刷）
パラメータ タイプ
copies（コピー；省略可） int（整数型）
上記ＲＰＣは、出力画像形成装置１８として機能しているレーザ画像生成器から汎用的な印刷を開始する。上記ＲＰＣは、固定フォーマットで使用されるものとして設計されている。フォーマットは現在選択されている固定フォーマットである。copiesは任意のパラメータであり、生成されるコピーの枚数を示している。最後の印刷後に得られた画像を印刷に使用する。
ｂ． print（印刷）
パラメータ タイプ
format（フォーマット） int（整数型）
image list（画像リスト） LIST
copies（コピー；省略可） int（整数型）
density（密度；省略可） int（整数型）
destination（出力先；省略可） DESTINATION
上記ＲＰＣは、レーザ画像生成器から印刷を開始する。フォーマットは、使用するフォーマットＩＤである。画像リストは、フォーマットを埋めるのにどの画像を使用するかを示す。copiesは任意のパラメータであり、生成されるコピーの枚数を示している。densityは任意の整数であり、密度テストパッチが望ましい場合に用いられる。この整数の値は画像ＩＤに対応している。destinationは任意のパラメータであり、デフォルトではなく出力先を定義している。
ｃ． print_test（印刷テスト）
パラメータ タイプ
format（フォーマット） int（整数型）
image list（画像リスト） LIST
dens_id（密度ＩＤ） IMAGE_ID
copies（コピー；省略可） int（整数型）
density（密度；省略可） int（整数型）
destination（出力先；省略可） DESTINATION
上記ＲＰＣは、レーザ画像生成器から印刷を開始する。フォーマットは使用するフォーマットＩＤである。画像リストは、フォーマットを埋めるのにどの画像を使用するかを示す。dens_idは、密度テストパッチの画像ＩＤを表す整数である。copiesは任意のパラメータであり、生成されるコピーの枚数を示している。destinationは任意のパラメータであり、デフォルトではなく出力先を定義している。
ｄ． abort（放棄）
パラメータ タイプ
job ID（ジョブＩＤ） JOB_ID
上記ＲＰＣは、対応するＩＤを有するジョブを放棄する。
ｅ． abort（放棄）
パラメータ タイプ
none（なし） n/a（なし）
上記ＲＰＣは、既に開始されている全てのジョブを放棄する。
２． ＲＰＣのフォーマット
ａ． define（定義）
パラメータ タイプ
format object FORMAT
（オブジェクトをフォーマット）
上記ＲＰＣは、フォーマットオブジェクトにおいて見いだされるものと全く同じパラメータでフォーマットを定義する。NOT_ASSIGNEDに等しいパラメータは全てこの定義には含まれない。
ｂ． define（定義）
パラメータ タイプ
box object BOX
（ボックスオブジェクト）
上記ＲＰＣは、ボックスオブジェクトにおいて見いだされるものと全く同じパラメータでフォーマットを定義する。NOT_ASSIGNEDに等しいパラメータは全てこの定義には含まれない。
ｃ． modify（変更）
パラメータ タイプ
box object BOX
（ボックスオブジェクト）
上記ＲＰＣは、ボックスオブジェクトにおいて指定されているＩＤに一致するボックスを変更する。ボックスオブジェクトのNOT_ASSIGNEDに等しいパラメータは全てこの定義には含まれない。
ｄ． modify（変更）
パラメータ タイプ
box object BOX
（ボックスオブジェクト）
x_shift（ｘシフト） LENGTH
y_shift（ｙシフト） LENGTH
上記ＲＰＣは、ボックスオブジェクトにおいて指定されているＩＤに一致するボックスを変更する。ボックスの位置は、x_shiftおよびy_shiftによって指定される量だけシフトする。ボックスオブジェクトのNOT_ASSIGNEDに等しいパラメータは全て変更されない。
e． modify（変更）
パラメータ タイプ
format object FORMAT
（フォーマットオブジェクト）
上記ＲＰＣは、ボックスオブジェクトにおいて指定されているＩＤに一致するフォーマットを変更する。フォーマットオブジェクトのNOT_ASSIGNEDに等しいパラメータは全て変更されない。
ｆ． remove（除去）
パラメータ タイプ
none（なし） n/a（なし）
上記ＲＰＣは、最後に獲得した画像を削除する。
ｇ． remove（除去）
パラメータ タイプ
box object BOX
def（委譲；省略可） Bool（二値型）
all（全て；省略可） Bool（二値型）
上記ＲＰＣは、受信したBOXオブジェクトのＩＤと同一のＩＤを使用してボックスを削除する。DEFは、TRUE（真）に設定されると、ジョブを委譲してバックグラウンドで処理させる任意のパラメータである。受信されないときは、DEFはFALSE（偽）に設定される。ALLは、TRUE（真）に設定されると、既に定義されているボックスを全て削除する任意のパラメータである。受信されないときは、ALLはFALSE（偽）に設定される。
ｈ． remove（除去）
パラメータ タイプ
format object FORMAT
def（委譲；省略可） Bool（二値型）
all（全て；省略可） Bool（二値型）
上記ＲＰＣは、受信したFORMATオブジェクトのＩＤと同一のＩＤを使用してフォーマットを削除する。DEFは、TRUE（真）に設定されると、ジョブを委譲してバックグラウンドで処理させる任意のパラメータである。受信されなければ、DEFはFALSE（偽）に設定される。ALLは、TRUE（真）に設定されると、既に定義されているボックスを全て削除する任意のパラメータである。受信されなければ、ALLはFALSE（偽）に設定される。
ｊ． remove_all（全て除去）
パラメータ タイプ
def（委譲；省略可） Bool（二値型）
上記ＲＰＣは、レーザ画像生成器に定義されている画像、ボックス、フォーマットおよびテーブルを全て削除する。DEFは、TRUE（真）に設定されると、ジョブを委譲してバックグラウンドで処理させる任意のパラメータである。受信されなければ、DEFはFALSE（偽）に設定される。
ｈ． remove_fixed_images（固定画像除去）
パラメータ タイプ
none（なし） n/a（なし）
上記ＲＰＣは、固定フォーマット格納ＲＰＣを介して格納された画像を全て削除する。
３． 画像操作ＲＰＣ
ａ． store（格納）
パラメータ タイプ
none（なし） n/a（なし）
この遠隔手順呼出しは、固定フォーマットで厳密に用いられる。この遠隔手順呼出しは、次の画像を次に利用できる固定画像位置に格納する。この位置は、１〜Ｎまでであり、Ｎはフォーマット毎に指定されている。
ｂ． store（格納）
パラメータ タイプ
id（ＩＤ） FIXED_ID
この遠隔手順呼出しは、固定フォーマットで厳密に用いられる。この遠隔手順呼出しは、次の画像を次に利用できるＩＤによって指定された位置に格納する。この位置は、１〜Ｎまでであり、Ｎはフォーマット毎に指定されている。
ｃ． store（格納）
パラメータ タイプ
image（画像） IMAGE
上記ＲＰＣは次の画像を獲得する。画像サイズに関するリターン情報はLI_responseに存在している。
ｄ． store（格納）
パラメータ タイプ
image（画像） TEST_IMAGE
上記ＲＰＣは次の画像をテストパターンとして獲得する。画像サイズに関するリターン情報はLI_responseに存在している。
ｅ． store（格納）
パラメータ タイプ
string（ストリング） STRING
上記ＲＰＣはテキストおよびＩＤをSTRINGオブジェクトに格納する。これによって、クライアントコンポーネントはＩＤによっていつでもテキストを呼び出すことができる。ストリングサイズに関するリターン情報はLI_responseに存在している。
ｆ． transfer（転送）
パラメータ タイプ
image（画像） TEST_IMAGE
上記ＲＰＣは、次の画像をバックグラウンドジョブとして転送する。画像サイズに関するリターン情報は、画像転送終了時に利用できるようになる。
ｇ． reserve（保持）
パラメータ タイプ
image（画像） TEST_IMAGE
上記ＲＰＣは、IMAGEオブジェクトによって記述された画像を保持するのに十分な画像メモリを割り当てる。
４． プロセスコンフィギュレーション／状態ＲＰＣ
ａ． set（設定）
パラメータ タイプ
parameter object PARAMETER
（パラメータオブジェクト）
上記ＲＰＣは、レーザ画像生成器用の画像形成パラメータを設定する。NOT_ASSIGNEDに設定されたパラメータは全て変更されることがない。
５． 状態ＲＰＣ
ａ． show（表示）
パラメータ タイプ
parameter object *PARAMETER
（パラメータオブジェクト）
上記ＲＰＣは、レーザ画像生成器用の画像形成パラメータを検索する。
ｂ． show_fixed（固定表示）
パラメータ タイプ
parameter object *PARAMETER
（パラメータオブジェクト）
上記ＲＰＣは、レーザ画像生成器用の固定フォーマットされた画像形成パラメータを検索する。パラメータオブジェクトのその他のメンバは全て変更されることがない。パラメータオブジェクトのその他のメンバは全て変更されることがない。
ｃ． show_mem（メモリ表示）
パラメータ タイプ
parameter object *PARAMETER
（パラメータオブジェクト）
上記ＲＰＣは、レーザ画像生成器用のメモリ条件を検索する。
ｄ． show（表示）
パラメータ タイプ
image object *IMAGE
（パラメータオブジェクト）
上記ＲＰＣは、画像オブジェクトに与えられたＩＤと一致するＩＤを有する画像の長さと幅とを検索する。画像情報はすべて画像オブジェクトに存在している。
ｅ． show（表示）
パラメータ タイプ
printer object *PRINTER
（プリンタオブジェクト）
上記ＲＰＣは、プリンタオブジェクトに与えられたＩＤと一致するＩＤを有するプリンタの状態を検索する。プリンタ情報はすべてプリンタオブジェクトに存在している。
ｆ． show（表示）
パラメータ タイプ
job object *JOB
（ジョブオブジェクト）
上記ＲＰＣは、ジョブオブジェクトに与えられたＩＤと一致するＩＤを有するジョブの状態を検索する。ジョブ情報はすべてジョブオブジェクトに存在している。
ｇ． show（表示）
パラメータ タイプ
printer object *XFR
（プリンタオブジェクト）
上記ＲＰＣは、転送ジョブオブジェクトに与えられたＩＤと一致するＩＤを有する転送ジョブの状態を検索する。転送ジョブ情報はすべて転送ジョブオブジェクトに存在している。
ｈ． show_format（フォーマット表示）
パラメータ タイプ
string（ストリング） *char（文字型）
上記ＲＰＣは、定義されたフォーマットのＩＤのストリングを検索する。
ｉ． show_images（画像表示）
パラメータ タイプ
string（ストリング） *char（文字型）
上記ＲＰＣは、獲得された画像のＩＤのストリングを検索する。
ｊ． show_con_tables（カラーテーブル表示）
パラメータ タイプ
string（ストリング） *char（文字型）
上記ＲＰＣは、定義されたコントラストテーブルのストリングを検索する。
ｋ． show_con_tables（カラーテーブル表示）
パラメータ タイプ
string（ストリング） *char（文字型）
上記ＲＰＣは、定義されたカラーコントラストテーブルのストリングを検索する。
ｌ． set_debug_level（デバッグレベル設定）
パラメータ タイプ
debug level（デバッグレベル） DEBUG_LEVEL
返り値 タイプ
Driver return code DRIVER_RC
（ドライバリターンコード）
上記ＲＰＣは、クライアントコンポーネントで入力インタプリタコンポーネント２２のデバッグレベルを設定できるようにする。デバッグレベルは、NO_DEBUG、LOW_DEBUG、MEDIUM_DEBUGおよびHIGH_DEBUGである。このパラメータは、デバッグ中に表示される情報に影響する。
出力インタプリタコンポーネント２４に対してインタフェースすることの利点の１つは、各遠隔手続き呼出しが同様のオブジェクトを返すということにある。このオブジェクトは、最も適切には上記において示したようにレーザ画像生成器の応答オブジェクトと呼ばれる。レーザ画像生成器では、応答オブジェクトは極めて多量な遠隔手続き呼出しの結果に関する情報である。しかしながら、クライアントは、必要なものに関する情報のみを選択して検討することもできる。レーザ画像生成器の応答オブジェクトは３つのメインフィールドを有する。１つ目はsuccessというの単純な論理値である。この論理値は、遠隔手続き呼出しに関する要求が終了したか失敗したかという結果を反映している。この情報は、大半のクライアントコンポーネントで必要とされているものを満たすことができる。２番目のフィールドすなわちsuccess_dataは、コマンドが成功した場合にクライアントコンポーネント側で想定する値を返す。通常、成功したコマンドに関する情報はない。しかしながら、成功したコマンドに関して返される情報の一例として、画像格納コマンドが成功した後に返ってくる画像サイズが挙げられる。３つ目のフィールドすなわちerrorsは、遠隔手続き呼出しが何故失敗したかを説明するのに用いられる。このフィールドは、実際にはレーザ画像生成器において発生し得るエラーのコンプリヘンシブビットフィールドである。繰り返すが、このフィールドはsuccessが偽である場合にのみ有効である。
以下に列挙するＣ＋＋コードは、レーザ画像生成器の応答オブジェクトについて記述したものである。クラスはコマンドの発行後にレーザ画像生成器から送信されてくる応答を定義する。コマンドの実行に成功すると、SUCCESS（成功）フラグがTRUE（真）にセットされる。無事に終了した場合に受信されるデータは全てSuccess_Dataに格納される。コマンドが失敗に終わると、SUCCESS（成功）フラグはFALSE（偽）にセットされる。失敗の芸インはFailure（失敗）構造に格納される。

Ｄ． 出力ドライバのベースクラスプロトコル
ここに開示する一例としての実施例において、出力ドライバのベースクラスプロトコルは、入力ドライバのベースクラスプロトコルと実質的に同一である。出力ドライバコンポーネント２６は、出力インタプリタコンポーネント２４用の遠隔手続き呼出しを５回行う。５回の遠隔手続き呼出しを利用して、出力インタプリタコンポーネント２４は、レーザ画像生成器などの出力画像形成装置１８との間を直接インタフェースすることができる。以下、５回の遠隔手続き呼出しについて説明する。
１． xmit_message（送信メッセージ）
パラメータ タイプ
message（メッセージ） char *（文字型）
返り値 タイプ
Driver return code（ドライバリターンコード） DRIVER_RC
上述したＲＰＣは、メッセージを出力ドライバコンポーネント２４に渡し、パイプライン３０を介して入力画像形成装置１２に送信する。出力画像形成装置１８との通信に必要な全ての要件は、出力ドライバコンポーネント２６によって処理される。
２． receive_message（受信メッセージ）
パラメータ タイプ
message（メッセージ） char *（文字型）
返り値 タイプ
Driver return code（ドライバリターンコード） DRIVER_RC
上述したＲＰＣは、出力画像形成装置１８から送信された出力ドライバコンポーネント２６からのメッセージを検索する。繰り返すが、出力画像形成装置との通信に必要な全ての要件は、出力ドライバコンポーネント２６によって処理される。
３． set_xmit_timeout（送信タイムアウト設定）
パラメータ タイプ
timeout（タイムアウト） int（整数型）
返り値 タイプ
Driver return code（ドライバリターンコード） DRIVER_RC
上記ＲＰＣは、出力画像形成装置１８にメッセージを送信する際に出力ドライバコンポーネント２６によって使用されるタイムアウト値を設定する。
４． set_async_func
パラメータ タイプ
client ptr（クライアントポインタ） FE_CLIENT_PTR
method ptr（メソッドポインタ） FE_METHOD_PTR
返り値 タイプ
Driver return code（ドライバリターンコード） DRIVER_RC
上記ＲＰＣは、クライアントコンポーネントすなわち出力インタプリタコンポーネント２４の非同期ハンドラに対する処理を出力ドライバコンポーネント２６に渡す。上記ＲＰＣは、クライアントコンポーネントに対して既に起こった非同期イベントを通知するために使用される。唯一の非同期イベントはMSG_PENDINGである。これは、出力画像形成装置１８からのメッセージの送信が完全に終了し、出力インタプリタコンポーネント２４への送信の準備ができていることを示す。
５． set_debug_level
パラメータ タイプ
debug level（デバッグレベル） DEBUG_LEVEL
返り値 タイプ
Driver return code（ドライバリターンコード） DRIVER_RC
上記ＲＰＣは、クライアントコンポーネントで出力ドライバコンポーネントのデバッグレベルを設定できるようにする。デバッグレベルは、NO_DEBUG、LOW_DEBUG、MEDIUM_DEBUGおよびHIGH_DEBUGである。このパラメータは、デバッグ中に表示される情報に影響する。
上述したように、各ＲＰＣは３種類のドライバリターンコードすなわち（１）RPC_OK、（２）PORT_BUSYおよび（３）NO_MESSAGEのうち１つを返す。ドライバリターンコードは、Ｃ＋＋では以下のように定義される。

以上、本発明の一例としての実施例にいて説明したが、当業者であればここに開示の明細書の内容を検討および本発明を実施することで、さらに他の利点および変更について容易に理解できよう。したがって、明細書および実施例は一例を示すにすぎないものであると解されるべきであり、本発明の真の範囲および趣旨については以下の請求の範囲に示されるものとする。

Claims (8)

1. 異なる複数の入力画像形成装置と異なる複数の出力画像形成装置との間で画像情報を伝送するためのソフトウェアシステムであって、
   前記ソフトウェアシステムは、複数の入力ドライバコンポーネントと、複数の入力インタプリタコンポーネントと、複数の出力インタプリタコンポーネントと、複数の出力ドライバコンポーネントと、インタフェース監視制御コンポーネントとを備え、
   前記各入力ドライバコンポーネントは、前記入力画像形成装置のうちの１つから画像情報を異なる複数の入力ドライバプロトコルのうちの１つに従って受信するように構成され、前記各入力ドライバプロトコルは、前記入力画像形成装置のうちの特定の１つと関連付けられ、前記各入力ドライバコンポーネントは、前記各入力ドライバコンポーネントにとって汎用的でありかつ前記各入力インタプリタコンポーネントに理解される第１のベースクラスプロトコルに従って、前記画像情報を前記入力インタプリタコンポーネントのうちの１つに伝送する第１のインタフェースを含み、
   前記各入力インタプリタコンポーネントは、前記入力ドライバコンポーネントのうちの１つによって受信された画像情報に基づいて第１の画像形成要求を異なる複数の入力インタプリタプロトコルのうちの１つに従って生成するように構成され、前記各入力インタプリタプロトコルは、前記入力画像形成装置のうちの特定の１つと関連付けられ、前記各入力インタプリタコンポーネントは、前記各入力インタプリタコンポーネントにとって汎用的でありかつ前記各出力インタプリタコンポーネントに理解される第２のベースクラスプロトコルに従って、前記第１の画像形成要求を前記出力インタプリタコンポーネントのうちの１つに伝送する第２のインタフェースを含み、
   前記各出力インタプリタコンポーネントは、前記入力インタプリタコンポーネントのうちの１つによって生成された第１の画像形成要求に基づいて第２の画像形成要求を異なる複数の出力インタプリタプロトコルのうちの１つに従って生成するように構成され、前記各出力インタプリタプロトコルは、前記出力画像形成装置のうちの特定の１つと関連付けられ、前記各出力インタプリタコンポーネントは、前記各出力インタプリタコンポーネントにとって汎用的でありかつ前記各出力ドライバコンポーネントに理解される第３のベースクラスプロトコルに従って、前記第２の画像形成要求を前記出力ドライバコンポーネントのうちの１つに伝送する第３のインタフェースを含み、
   前記各出力ドライバコンポーネントは、前記出力インタプリタコンポーネントのうちの１つによって生成された第２の画像形成要求を、異なる複数の出力ドライバプロトコルのうちの１つに従って前記出力画像形成装置のうちの１つに伝送するように構成され、前記各出力ドライバプロトコルは、前記出力画像形成装置のうちの特定の１つと関連付けられ、前記各出力ドライバコンポーネントは、前記各出力ドライバコンポーネントにとって汎用的でありかつ前記各出力インタプリタコンポーネントに理解される第４のベースクラスプロトコルに従って、前記出力画像形成装置のうちの１つから前記第２の画像形成要求に対する第１の応答を伝送する第４のインタフェースを含み、
   前記インタフェース監視制御コンポーネントは、複数の通信パイプラインを有しかつ規模の変更が可能な通信アーキテクチャを生成するように構成され、前記各通信パイプラインは、前記入力画像形成装置のうちの１つと、前記入力ドライバコンポーネントのうちの１つと、前記入力インタプリタコンポーネントのうちの１つと、前記出力インタプリタコンポーネントのうちの１つと、前記出力ドライバコンポーネントのうちの１つと、前記出力画像形成装置のうちの１つとを通信可能であるように相互接続し、前記規模の変更が可能なソフトウェアアーキテクチャによって、１つの出力画像形成装置は、各通信パイプラインによって提供される必要なプロトコルを用いて、共用して複数の入力画像形成装置と同時に通信する能力を備え、あるいは、複数の出力画像形成装置は、それぞれ特定の通信パイプラインを介して１つの入力画像形成装置と相互接続されて当該入力画像形成装置と通信する能力を備えたことを特徴とするソフトウェアシステム。
2. 前記第１のベースクラスプロトコル、前記第２のベースクラスプロトコル、前記第３のベースクラスプロトコルおよび前記第４のベースクラスプロトコルの各々は、オブジェクト指向階層に従って定義されることを特徴とする請求項１記載のソフトウェアシステム。
3. 前記各出力インタプリタコンポーネントはさらに、前記出力ドライバコンポーネントのうちの１つによって受信される前記第１の応答に基づいて、前記出力インタプリタプロトコルのうちの１つに従って第２の応答を生成するように構成され、
   前記各入力インタプリタコンポーネントはさらに、前記出力インタプリタコンポーネントのうちの１つによって生成される前記第２の応答に基づいて、前記入力インタプリタプロトコルのうちの１つに従って第３の応答を生成するように構成され、
   前記各出力ドライバコンポーネントはさらに、前記出力インタプリタコンポーネントのうちの１つによって生成される第２の画像形成要求に対する第２の応答を、前記出力ドライバプロトコルのうちの１つに従って生成するように構成され、前記各入力ドライバコンポーネントはさらに、前記入力インタプリタコンポーネントのうちの１つによって生成される前記第３の応答を、前記入力ドライバプロトコルのうちの１つに従って前記入力画像形成装置のうちの１つに伝送するように構成され、
   前記インタフェース監視制御コンポーネントによって定義された前記各通信パイプラインは、前記入力画像形成装置のうちの１つと、前記入力ドライバコンポーネントのうちの１つと、前記入力インタプリタコンポーネントのうちの１つと、前記出力インタプリタコンポーネントのうちの１つと、前記出力ドライバコンポーネントのうちの１つと、前記出力画像形成装置のうちの１つとを通信可能であるように相互接続し、前記入力画像形成装置のうちの１つと前記出力画像形成装置のうちの１つとの間で双方向通信するための双方向通信パイプラインであることを特徴とする請求項１記載のソフトウェアシステム。
4. 前記各出力インタプリタコンポーネントの第３のインタフェースは、前記各出力インタプリタコンポーネントにとって汎用的でありかつ前記各入力インタプリタコンポーネントに理解される前記第３のベースクラスプロトコルに従って、前記第２の応答を前記入力インタプリタコンポーネントのうちの１つに伝送するように構成され、
   前記各入力インタプリタコンポーネントの第２のインタフェースは、前記各入力インタプリタコンポーネントにとって汎用的でありかつ前記各入力ドライバコンポーネントに理解される前記第２のベースクラスプロトコルに従って、前記第１の応答を前記入力ドライバコンポーネントのうちの１つに伝送するように構成されていることを特徴とする請求項３記載のソフトウェアシステム。
5. 前記入力画像形成装置のうちの少なくとも１つは医療用画像形成装置を含み、前記出力画像形成装置のうちの少なくとも１つはレーザ画像生成器を含むことを特徴とする請求項４記載のソフトウェアシステム。
6. 前記インタフェース監視制御コンポーネントは、前記各入力インタプリタコンポーネントが前記入力ドライバコンポーネントのうちの１つのクライアントであり、前記各入力インタプリタコンポーネントが前記出力インタプリタコンポーネントのうちの１つのクライアントであり、前記各出力インタプリタコンポーネントが前記出力ドライバコンポーネントのうちの１つのクライアントであり、前記インタフェース監視制御コンポーネントが、前記各入力ドライバコンポーネントと、前記各入力インタプリタコンポーネントと、前記各出力インタプリタコンポーネントと、前記各出力ドライバコンポーネントとのクライアントであるように、クライアント-サーバ関係に従って前記各通信パイプラインを定義することを特徴とする請求項５記載のソフトウェアシステム。
7. 前記入力インタプリタコンポーネントと、前記入力ドライバコンポーネントと、前記出力インタプリタコンポーネントとの間の通信は、前記入力インタプリタコンポーネントによって生成されると共に前記入力ドライバコンポーネントおよび前記出力インタプリタコンポーネントによって実行される遠隔手続き呼出しによって達成され、
   前記出力インタプリタコンポーネントと前記出力ドライバコンポーネントとの間の通信は、前記出力インタプリタコンポーネントによって生成されると共に前記出力ドライバコンポーネントによって実行される遠隔手続き呼出しによって達成され、
   前記インタフェース監視制御コンポーネントと、前記入力ドライバコンポーネントと、前記入力インタプリタコンポーネントと、前記出力インタプリタコンポーネントと、前記出力ドライバコンポーネントの間の通信は、前記インタフェース監視制御コンポーネントによって生成されると共に、前記入力ドライバコンポーネントと、前記入力インタプリタコンポーネントと、前記出力インタプリタコンポーネントと、前記出力ドライバコンポーネントとによって実行される遠隔手続き呼出しによって達成されることを特徴とする請求項６記載のソフトウェアシステム。
8. 前記ソフトウェアシステムは、画像形成システム内に常駐していることを特徴とする請求項１記載のソフトウェアシステム。

Images