JP5257142B2 - 画像形成装置、画像形成システム、情報処理方法、及び、コンピュータプログラム - Google Patents

Description

本発明は、画像形成装置、画像形成システム、情報処理方法、及び、コンピュータプログラムに関する。

従来から、ネットワークを介して接続された装置のファームウェアを更新してバージョンアップを行う技術がある。例えば、特開２００４−１３９５７２号公報（特許文献１）には、画像形成装置のファームウェア更新を、所定の日時に行わせることにより、画像形成装置の稼働率の低下を回避する遠隔管理システム等の技術が開示されている。

また例えば、特開２００４−２５２７０４号公報（特許文献２）には、ネットワークを介して接続されたネットワーク接続機器間において、インストールされているソフトウェアのバージョン等をあわせるようにする機器管理装置の技術が開示されている。

しかしながら、上記特許文献１及び２に開示の技術では、画像形成装置に新機能を追加する際の容易性については考慮されていない。例えば、新機能を追加した画像形成装置において、その機能に係る処理を実行させるために、機能を実現する手段であるファームウェアの他に、各機能に対する指示を出力する中心的な制御を行うファームウェアも更新すると、機能の追加毎や機能の組合せが変更される毎にバージョンアップするファームウェアの管理や開発が煩雑になる。

本発明は、上記の点に鑑みて、これらの問題を解消するために発明されたものであり、新機能が追加された画像形成装置において、リクエストの内容を解析して好適に処理する画像形成装置、画像形成システム、情報処理方法、及び、コンピュータプログラムを提供することを目的としている。

上記目的を達成するために、本発明の画像形成装置は次の如き構成を採用した。

本発明の画像形成装置は、当該画像形成装置に接続された機能実現手段の一覧を管理する一覧管理手段と、クライアント装置からの第一の記述形式によるリクエストを受信する通信手段と、前記リクエストを解析して該リクエストに含まれる機能実現手段の識別情報と要求項目とを取得して出力するリクエスト解析手段と、前記機能実現手段毎に、前記要求項目に対応する処理内容のデータ形式及び前記処理内容に対応する応答項目のデータ形式を保持するデータ形式保持手段と、前記リクエスト解析手段からの出力に基づいて、前記要求項目を前記処理内容のデータ形式にして前記機能実現手段に対して出力し、前記機能実現手段に対応する処理内容が無い場合には、前記要求項目を第二の記述形式にして前記機能実現手段に対して出力する処理内容取得手段と、前記機能実現手段により処理済の前記応答項目のデータ形式による応答項目、及び／又は、前記機能実現手段により未処理の前記第二の記述形式による応答項目に基づいて、前記応答項目が、前記処理済と前記未処理と区別されて前記第一の記述形式により記述されたレスポンスを生成するレスポンス生成手段と、を有する構成とすることができる。

これにより、新機能が追加された画像形成装置において、リクエストの内容を解析して好適に処理する画像形成装置を提供することができる。

なお、上記課題を解決するため、本発明は、さらに、上記画像形成装置を有する画像形成システム、上記画像形成装置又は上記画像形成システムにおける情報処理方法、及び、その情報処理方法をコンピュータに実行させるためのコンピュータプログラムとしてもよい。

本発明の画像形成装置、画像形成システム、情報処理方法、及び、コンピュータプログラムによれば、新機能が追加された画像形成装置において、リクエストの内容を解析して好適に処理する画像形成装置、画像形成システム、情報処理方法、及び、コンピュータプログラムを提供することが可能になる。

一のリクエストをそれぞれの装置が処理することを説明する図。 レスポンスにおける課題を説明する図。 レスポンスデータの中に未処理のデータを含めることを説明する図。 本実施の形態による画像形成システムの例を説明する図。 本実施の形態に係る画像形成装置であるＭＦＰの装置構成の例を説明する図。 本実施の形態に係る画像形成システムの機能構成の例を説明する図。 クライアントからのリクエストに基づく処理の例のシーケンス図。 クライアントからのリクエストに基づく処理とレスポンスを送信する処理の例のシーケンス図。 イベントに基づくメッセージが送信される場合の処理の例のシーケンス図。 リクエストが解析される処理の例のフロー図。 リクエストの例。 要求項目を第二の記述形式に変換することを説明する図。 未処理データとなるデータを含むリクエストの例を示す図。 レスポンス又はメッセージが生成される処理の例のフロー図。 第二の記述形式による応答項目から第一の記述形式によるレスポンスが生成されることを説明する図。 不要データリストによる応答項目から、第一の記述形式によるレスポンスが生成されることを説明する図。 未対応データリストによる応答項目から、第一の記述形式によるレスポンスが生成されることを説明する図。 レスポンスの例（その１）。 レスポンスの例（その２）。 メッセージの例。 本実施形態の画像形成装置又はクライアント装置を実現するコンピュータの構成図。

以下、本発明の実施の形態を図面に基づき説明する。
〔実施の形態〕
（一のリクエストをそれぞれの装置が処理することを説明する図）
図１は、一のリクエストをそれぞれの装置が処理することを説明する図である。図１の画像形成システムは、クライアント装置であるＰＣ１５が、レーザプリンタ（以下、「ＬＰ」という。）２５、複合機（以下、「ＭＦＰ」という。）３５、ＭＦＰ３６及び印刷機４５と、ネットワークを介して接続されている。図１では、ＬＰ２５、ＭＦＰ３５、ＭＦＰ３６及び印刷機４５は、同一のインタフェースであり、リクエスト及びそのレスポンスの送受信に用いられるプロトコルは同一である。

図１の画像形成システムにおいて、リクエストのデータフォーマットは、例えば、ＸＭＬの形式を有し、リクエストに含まれる要求項目のうち、各装置が有する機能実現部に対応する要求項目のみが、各装置において処理される。

すなわち、ＰＣ１５から送信されるリクエストａのうち、ＬＰ２５は、自身が有する機能実現部に対応する箇所であるａ１の部分の要求項目に対する処理を行う。同様に、ＭＦＰ３６は、自身が有する機能実現部に対応する箇所であるａ２の部分の要求項目に対する処理を行う。ＭＦＰ３５と印刷機４５とは、リクエストａに含まれる全ての要求項目に対応する機能実現部を有するので、それらに対応する処理を行う。このような要求項目の取捨選択は、例えば、各機器が有するＷｅｂＳｅｒｖｉｃｅ（以下、「ＷＳ」という。）部において行われる。

図１より、ＰＣ１５は、装置毎の機能実現部を考慮することなく、リクエストを出力することができる。これにより、装置毎の機能実現部やバージョンに対応してクライアントの機能実現部を変更する手間を省くことができる。

ここで、ＰＣ１５は、例えば、次の２つの方法によって各機器にアクセスすることが考えられる。
１． ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）を利用してＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）の情報にアクセスする。
２． ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）上でＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）やＸＭＬデータを利用する。

上記１．では、ＭＩＢで定められている情報については、全ての装置からアクセスして取得することができるが、ＭＩＢ以外の情報については、取得できない。一方、上記２．では、装置毎にインタフェースを定義して装置が有する情報にアクセスでき、その際に、ＳＯＡＰやＸＭＬが用いられる。しかしながら、２．では、プラットフォームやバージョンの違いにより、インタフェースが異なる場合には、ＰＣ１５側でその違いに応じた処理が必要になる。

なお、本実施の形態において、インタフェースとは、特に明記しない限り「ネットワークインタフェース」であり、例えば、ＳＯＡＰにおけるＵＲＬ等の装置を識別して呼びかけるための情報である。

（レスポンスに生じる課題）
図２は、レスポンスにおける課題を説明する図である。従来の手法では、図２の画像形成装置３８内のＷＳ部３８１は未知のデータａ２を各機能部３８２へ伝達する。各機能部３８２ではデータａ２に対して未対応であったり、データａ２が不要であったりした場合には、各機能部３８２は、データａ２を削除する。この場合の機器からのレスポンスｂのデータには処理された情報しか含まれておらず、レスポンスｂだけを見ても、ａ２部分のデータが処理されたのかどうかの判断がクライアント１５にはできない。クライアント１５は複数の機器に対して同じリクエストを一括で行うため、どの機器でどのデータが処理されたのかがレスポンスを見ただけでは分からないという課題がある。

図３は、レスポンスデータの中に未処理のデータを含めることを説明する図である。各機能部３８２に伝達された未知のデータａ２に対して、各機能部３８２は未対応／不要として処理をしなかったとする。この場合ＷＳ部３８１へのレスポンスデータ生成依頼の際に未処理のデータａ３も一緒に渡すようにする。ＷＳ部３８１では、未処理データはレスポンスデータｂ１生成時に未処理データｂ２として生成するようにすることで、クライアント１５はレスポンスデータを見てどのデータが処理されなかったかを判断することができる。

ここで、未対応データとは、リクエストのバージョンと機器のバージョンが異なることにより各機能部３８が処理できないデータのことを言う。新しいバージョンでは新規項目が追加されているとする。このとき、リクエストでは新規項目のデータを含んでいるが、リクエストを受けた画像形成装置３８が旧バージョン対応の場合、新規項目を処理できない。また、不要データとは、画像形成装置３８がリクエストに含まれるデータを処理する機能を有していないことにより、リクエストに含まれるデータを処理できず、そもそも画像形成装置３８には不要であったデータのことを言う。

（システム構成の例）
図４は、本実施の形態による画像形成システムの構成の例を説明する図である。図４の画像形成システムは、ＰＣ１、ＰＣ２、ＰＣ３・・・と、ＭＦＰ４、ＭＦＰ５、ＭＦＰ６・・・とが、ＬＡＮに接続されている。これにより、各ＰＣが、それぞれのＭＦＰに対してリクエストを出力し、また各ＭＦＰからのレスポンスを受信する。

（ＭＦＰの装置構成の例）
図５は、本実施の形態に係る画像形成装置であるＭＦＰの装置構成の例を説明する図である。図５のＭＦＰ３００は、例えば、情報処理ロジック部３１０、情報アクセス部３３０、情報保持部３４０、通信サーバ部３５１、通信クライアント部３５２、及び、ネットワークインタフェース（以下、「Ｉ／Ｆ」という。）３９０を有する。

情報処理ロジック部３１０は、クライアント装置等からのリクエストを解析し、また、クライアント装置へのレスポンスを生成する。情報処理ロジック部３１０は、例えば、データ処理部３１１を有する。データ処理部３１１は、ＸＭＬで記述されるリクエストをパースし、またＸＭＬで記述されるレスポンスを生成する。

情報アクセス部３３０は、情報処理ロジック部３１０によって解析されたリクエストに含まれる要求項目に基づいて、情報保持部３４０に保持されている情報を取得し、またその情報を編集して置き換え、または情報を生成して情報保持部３４０に格納させる。情報保持部３４０は、画像形成装置３００の状態や操作者毎の識別情報、画像データ等を格納する。

通信サーバ部３５１と通信クライアント部３５２とは、クライアント装置に対して通信を行う手段である。ネットワークＩ／Ｆ３９０は、画像形成装置３００とＬＡＮとを接続するためのインタフェースである。

（本実施の形態の画像形成システムの機能構成の例）
図６は、本実施の形態による画像形成システムの機能構成の例を説明する図である。図６の画像形成システムは、画像形成装置５００とクライアントＰＣ６００とが接続されている。なお、画像形成装置５００とクライアントＰＣ６００とは、ネットワークを介して接続されてもよく、また直接接続されてもよい。

画像形成装置５００は、例えば、情報処理ロジック部５１０、機能実現手段５３０、一覧管理手段５４１、データ形式保持手段５４２、及び、通信手段５５０を有する。情報処理ロジック部５１０は、クライアントＰＣ６００から送信されるリクエストを解析してその中に含まれる要求項目を取得する。情報処理ロジック部５１０は、また、要求項目に対応するレスポンスを生成する。

情報処理ロジック部５１０は、例えば、リクエスト解析手段５１１、処理内容取得手段５１２、未処理データリスト作成手段５１５、レスポンス生成手段５１３、及び、メッセージ生成手段５１４を有する。リクエスト解析手段５１１は、第一の記述形式によって記述されるリクエストをその構文にしたがって解析する。第一の記述形式とは、例えば、ＸＭＬによって表記され、名前空間によって項目群が識別される記述形式である。リクエスト解析手段５１１は、例えば、ＸＭＬパーサとして構成される。これにより、リクエストに含まれる要求項目を取得することができる。

処理内容取得手段５１２は、リクエスト解析手段５１１によって解析された内容に基づいて、機能実現手段の識別情報と要求項目に対応する処理内容とを取得する。処理内容取得手段５１２は、例えば、データ形式保持手段５４２に保持されている機能実現手段毎のデータ形式に基づいて、要求項目をそのデータ形式による処理内容に変換する。

処理内容取得手段５１２は、要求項目に対応するデータ形式が取得できない場合には、その要求項目を所定の記述形式に変換する。所定の記述形式とは、例えば、第二の記述形式であり、名前空間名、変数又はタグ名、及び、値を有する、クラスとして構成されてよい。

なお、データ形式が取得できない場合とは、例えば、その要求項目に対応する機能実現手段が、新たに追加されたものであるため、一覧管理手段５４１によって識別情報は管理されているものの、データ形式保持手段５４２には、その機能実現手段とのデータのインタフェースとなるデータ形式が登録されていない場合等である。

これにより、画像形成装置５００が有する新たに追加された機能実現手段に対しても、要求項目を出力して処理を指示することができる。

未処理データリスト作成手段５１５は、機能実現手段５３０により処理されなかった未処理データをリスト化する。未処理データリストには、前述したように未対応データと不要データとを含む。未処理データリスト作成手段５１５は、バージョンが異なることなどを理由に機能実現手段５３０により処理されなかったデータを未対応データとしてリスト化する。また、未処理データリスト作成手段５１５は、機能実現手段５３０と対応がとれなかった要求項目を処理内容取得手段５１２から取得し、不要データとしてリスト化する。生成されたリストはレスポンス生成手段５１３に出力される。

レスポンス生成手段５１３は、機能実現手段５３０によって処理された要求項目に対応するレスポンスを生成する。レスポンス生成手段５１３が生成するレスポンスは、例えば、画像形成装置５００の属するバージョンに基づいている。レスポンス生成手段５１３によって生成されるレスポンスは、機能実現手段５３０から出力される応答項目を含む。

レスポンス生成手段５１３は、機能実現手段５３０から出力される機能実現手段毎に対応するデータ形式の応答項目を変換し、第一の記述形式によるレスポンスを生成する。レスポンス生成手段５１３は、またさらに、機能実現手段５３０から出力される応答項目が、第二の記述形式による場合には、その応答項目から必要な情報を取り出して、第一の記述形式によるレスポンスにその情報を含ませる。

なお、応答項目が第二の記述形式による場合とは、その機能実現手段が、画像形成装置５００に対して後から追加されたものであり、一覧管理手段５４１に識別情報が登録されているものの、データ形式保持手段５４２には、その機能実現手段とのデータのインタフェースとなるデータ形式が登録されていない場合等である。これにより、画像形成装置５００が有する新たに追加された機能実現手段が出力する応答項目に対応するレスポンスを生成することができる。

また、レスポンス生成手段５１３は、未処理データリスト作成手段５１５から取得した未処理データリストに基づいて未処理データをレスポンスに含める。このとき、レスポンス生成手段５１３は、未処理データであることが分かるように、タグなどを用いて未処理であることを明確にする。これにより、画像形成装置５００が処理できなかったデータをレスポンスに含めることができ、レスポンスを受けた管理者などは、どのデータが処理済で、どのデータが未処理かを判別することができる。

メッセージ生成手段５１４は、画像形成装置５００における所定のイベントに基づいて、画像形成装置５００の状態に係る情報が、所定の記述形式によって記述されたメッセージを生成する。所定のイベントとは、例えば、画像形成装置５００におけるエラーの発生であり、より詳細には、ドアが開いた状態、用紙がない状態等の発生である。メッセージ生成手段５１４によって生成されるメッセージは、機能実現手段５３０から出力される状況項目を含む。

メッセージ生成手段５１４は、機能実現手段５３０から出力される機能実現手段毎に対応するデータ形式の状況項目を変換し、第一の記述形式によるメッセージを生成する。メッセージ生成手段５１４は、またさらに、機能実現手段５３０から出力される状況項目が、第二の記述形式による場合には、その状況項目から必要な情報を取り出して、第一の記述形式によるメッセージにその情報を含ませる。

なお、状況項目が第二の記述形式による場合とは、応答項目が第二の記述形式による場合と同様のケースである。これにより、画像形成装置５００が有する新たに追加された機能実現手段が出力する状況項目に対応するメッセージを生成することができる。

機能実現手段５３０は、処理内容取得手段５１２が取得した要求項目に基づいて、対応する処理を実行する。機能実現手段５３０は、例えば、図示しない記憶手段に格納されている情報を取得して出力し、また記憶手段に格納されている情報を編集して置き換え、また要求項目に基づいて新たな情報を生成して記憶手段に格納させる。なお、記憶手段には、上記の他、画像形成装置５００の状態に係る情報を保持し、また画像形成装置５００によって処理される画像の画像データ、画像形成装置５００を使用する操作者の情報等を保持されてよい。

機能実現手段５３０は、記憶手段に格納されている情報に係る処理を行う他に、画像形成装置５００が有する画像形成機能、通信機能、ファクシミリ機能等に係る処理を行ってもよい。機能実現手段５３０は、また、画像形成装置５００が有する構成の他に、画像形成装置５００に接続される構成でもよい。

一覧管理手段５４１は、画像形成装置５００が有する機能実現手段の一覧を保持し管理する。新たに機能実現手段５３０が追加された場合には、一覧管理手段５４１によって管理される一覧が更新される。

データ形式保持手段５４２は、機能実現手段毎に対応する、要求項目、応答項目、及び／又は、状況項目のデータ形式を保持する。これにより、処理内容取得手段５１２等が、第一の記述形式と、機能実現手段毎に対応するデータ形式との間の変換を行うことができる。

通信手段５５０は、クライアントＰＣ６００との通信を行い、例えば、リクエストを受信し、レスポンスやメッセージを送信する。

クライアントＰＣ６００は、画像形成装置５００に対して、リクエストを送信し、またその応答であるレスポンスを受信する。これにより、クライアントＰＣ６００は、画像形成装置５００の制御や画像形成装置５００が有する情報の管理を行う。

クライアントＰＣ６００は、例えば、情報処理ロジック部６１０と通信手段６５０とを有する。情報処理ロジック部６１０は、画像形成装置５００に対して送信するリクエストを生成し、また、画像形成装置５００から送信されるレスポンスを解析する。これにより、画像形成装置５００のステータスを取得することができる。なお、ステータスとは、画像形成装置５００の状態の他に、画像形成装置５００が保持する情報でもよい。

情報処理ロジック部６１０は、例えば、リクエスト生成手段６１１、レスポンス解析手段６１２、ステータス取得手段６１３を有する。リクエスト生成手段６１１は、画像形成装置５００に対して要求する要求項目を含むリクエストを生成する。リクエスト生成手段６１１によって生成されるリクエストは、例えば、第一の記述形式で表記される。

レスポンス解析手段６１２は、画像形成装置５００から送信されるレスポンス又はメッセージを解析する。以下、レスポンスを例に説明するが、メッセージの場合も同様に処理される。レスポンス解析手段６１２は、例えば、レスポンスがＸＭＬによって記述される場合に、ＸＭＬパーサとして構成される。

ステータス取得手段６１３は、レスポンス解析手段６１２によって解析された応答項目又は状況項目に基づいて、画像形成装置５００のステータスを取得する。ステータス取得手段６１３は、またさらに、取得したステータスに基づいて、機能実現手段６３０に対して応答項目を振り分ける。これにより、各機能実現手段が、その応答項目に対応する処理を実行することができる。

ステータス取得手段６１３は、応答項目を、機能実現手段毎に対応するデータ形式に変換する。ステータス取得手段６１３は、またさらに、その応答項目に対応するデータ形式がデータ形式保持手段６４２に保持されていない場合には、その応答項目を第二の記述形式に変換して出力する。

なお、応答項目が第二の記述形式による場合とは、画像形成装置５００における場合と同様のケースであって、例えば、クライアント装置６００に、新たに追加された機能実現手段６３０に対応する応答項目の場合である。これにより、クライアント装置が有する新たに追加された機能実現手段に対しても、応答項目又は状況項目を出力し、それらに対応する処理を実行させることができる。

機能実現手段６３０、一覧管理手段６４１、データ形式保持手段６４２、及び、通信手段６５０の機能及び構成は、画像形成装置５００が有する同名の手段と同様であり、容易に理解できるので、ここでは説明を省略する。

（クライアントからのリクエストに基づく処理の例（その１））
図７は、画像形成装置３００における、クライアントからのリクエストに基づく処理の例のシーケンス図である。図７のステップＳ１０１では、ＰＣ１００から通信サーバ部３５１に対し、リクエストが送信される。リクエストは、例えば、条件を設定すること、情報を参照、変更、又は、削除することの要求項目を含む。リクエストは、また例えば、ｈｔｔｐリクエストとして送信されてもよい。リクエストは、例えば、ＸＭＬ等の記述言語による第一の記述形式によって記述される。

ステップＳ１０１に続いてステップＳ１０２に進み、通信サーバ部３５１から情報処理ロジック部３１０に対し、ステップＳ１０１で受信されたリクエストを処理する依頼が出力される。リクエストは、例えば、画像形成装置５００が有する情報保持部３４０に保持されているアドレス帳のデータを操作する処理の要求である。

ステップＳ１０２に続いてステップＳ１０３に進み、情報処理ロジック部３１０からデータ処理部３１１に対し、リクエストのデータを解析する依頼が出力される。

ステップＳ１０３に続いてステップＳ１０４に進み、データ処理部３１１がリクエストを解析することにより、リクエストに含まれている要求項目を取得する。リクエストは、例えば、Ａｔｏｍ Ｐｕｂｌｉｓｈｉｎｇ Ｐｒｏｔｏｃｏｌ（以下、「ＡＰＰ」という。）
、Ａｔｏｍ、又は、その他の拡張形式の記述形式によって表記されている。そこで、データ処理部３１１は、それぞれの記述形式に応じて、要求項目と要求先の機能実現部の識別情報とを取得する。ここでは、例えば、情報アクセス部３３０の識別情報が取得される。

データ処理部３１１は、取得された機能実現部の識別情報に基づいて、その機能実現部に対応するデータ形式に要求項目を変換して処理内容とする。機能実現部に対応するデータ形式が無い場合には、その要求項目を、予め定められている第二の記述形式に変換する。

第二の記述形式とは、例えば、リクエストがＸＭＬによって記述される場合に、その要求項目の属する名前空間名、変数名又はタグ名、及び、値を含むとよい。

ステップＳ１０４に続いてステップＳ１０５に進み、データ処理部３１１から情報処理ロジック部３１０に対し、取得された処理内容又は第二の記述形式に変換された要求項目と、リクエストの解析が終了した通知が出力される。これに基づいて、情報処理ロジック部３１０は、要求項目毎に対応する処理内容又は第二の記述形式に変換された要求項目を取得する。

ステップＳ１０５に続いてステップＳ１０６に進み、情報処理ロジック部３１０から情報アクセス部３３０に対し、処理内容を実行する要求が出力される。ステップＳ１０６に続いてステップＳ１０７に進み、情報アクセス部３３０が情報保持部３４０にアクセスすることにより、ステップＳ１０１で受信されたリクエストに基づく処理が行われる。

ステップＳ１０７に続いてステップＳ１０８に進み、情報保持部３４０から情報アクセス部３３０に対し、処理が終了したことの通知が出力される。ステップＳ１０８に続いてステップＳ１０９に進み、情報アクセス部３３０から情報処理ロジック部３１０に対し、処理が終了したことの通知が出力される。ステップＳ１０９に続いてステップＳ１１０に進み、情報処理ロジック部３１０から通信サーバ部３５１に対し、処理が終了したことをＰＣ１００に通知する要求が出力される。ステップＳ１１０に続いてステップＳ１１１に進み、通信サーバ部３５１からＰＣ１００に対し、処理が終了したことの通知が送信される。ここでは、例えば、ｈｔｔｐレスポンスとして送信される。

（クライアントからのリクエストに基づく処理の例（その２））
図８は、画像形成装置３００における、クライアントからのリクエストに基づく処理の例のシーケンス図であって、画像形成装置３００からＰＣ１００に対してレスポンスが送信される処理の例である。図８のステップＳ２０１からステップＳ２０８は、図７のステップＳ１０１からステップＳ１０８と同一であるので、ここでは説明を省略する。

ステップＳ２０８に続くステップＳ２０９では、情報アクセス部３３０から情報処理ロジック部３１０に対し、処理が終了した旨の応答項目が出力される。応答項目は、情報処理ロジック部３１０に対応する所定のデータ形式でもよく、また例えば、第二の記述形式によるものでもよい。なお、第二の記述形式とは、例えば、レスポンスがＸＭＬによって記述される場合に、その応答項目の属する名前空間名、変数名又はタグ名、及び、値を含むとよい。

ステップＳ２０９に続くステップＳ２１０では、情報処理ロジック部３１０からデータ処理部３１１に対し、レスポンスを生成する依頼が出力される。このとき、情報処理ロジック部３１０は、未処理データリストがあればデータ処理部３１１へ出力する。

ステップＳ２１０に続いてステップＳ２１１に進み、データ処理部３１１が、ステップＳ２０４等で処理された処理内容毎に対応する応答項目を含むレスポンスを生成する。レスポンスは、第一の記述形式によって記述されており、例えば、ＸＭＬによって表記される。より詳細には、ＡＰＰ、Ａｔｏｍ、又は、その他の拡張形式によって表記される。どの形式によって表記されるかは、例えば、どの形式でレスポンスを返して欲しいというリクエストの記述内容や、画像形成装置の形式のサポート状況によって異なる。また、データ処理部３１１は、情報処理ロジック部３１０から未処理データリストを取得した場合は、未処理データリストに基づいて未処理データ（応答項目）をレスポンスに含める。

ステップＳ２１１に続いてステップＳ２１２に進み、データ処理部３１１から情報処理ロジック部３１０に対し、レスポンスの生成が終了した通知とレスポンスとが出力される。なお、レスポンスが出力されることが、レスポンスの生成が終了した通知を兼ねてもよい。

ステップＳ２１２に続いてステップＳ２１３に進み、情報処理ロジック部３１０から通信サーバ部３５１に対し、レスポンスとそのレスポンスを送信する依頼が出力される。ステップＳ２１３に続いてステップＳ２１４に進み、通信サーバ部３５１からＰＣ１００に対し、レスポンスが送信される。

（メッセージを生成して送信する処理の例）
図９は、画像形成装置５００からＰＣ１００に対し、所定のイベントに基づくメッセージが送信される場合の処理の例のシーケンス図である。図９のステップＳ３０１では、トリガとなるモジュールから情報処理ロジック部３１０に対し、イベントの発生が通知される。イベントとは、例えば、画像形成装置５００が有するドアが開いた等の異常の発生である。

ステップＳ３０１に続いてステップＳ３０２に進み、情報処理ロジック部３１０から情報アクセス部３３０に対し、データの取得依頼が出力される。これは、ステップＳ３０１で通知される内容が、イベントが発生したことを表す情報であって、その詳細は、情報保持部３４０によって保持されている情報を参照することにより、得られるからである。

ステップＳ３０２に続いてステップＳ３０３に進み、情報アクセス部３３０から情報保持部３４０に対し、データ取得要求が出力される。ステップＳ３０３に続いてステップＳ３０４に進み、情報保持部３４０から情報アクセス部３３０に対し、データが出力される。このデータには、イベントの詳細な情報が含まれている。ステップＳ３０４に続いてステップＳ３０５に進み、情報アクセス部３３０から情報処理ロジック部３１０に対し、ステップＳ３０４で取得されたデータが出力される。

情報アクセス部３３０から出力されるデータのデータ形式は、情報アクセス部３３０に対応するデータ形式でもよく、また例えば、第二の記述形式によって記述される形式でもよい。

ステップＳ３０５に続いてステップＳ３０６に進み、情報処理ロジック部３１０からデータ処理部３１１に対し、メッセージの生成依頼が出力される。ステップＳ３０６に続いてステップＳ３０７に進み、データ処理部３１１が、データに含まれているイベントの詳細な情報に基づいて、メッセージを生成する。メッセージは、所定の記述形式によって表される。ステップＳ３０７に続いてステップＳ３０８に進み、データ処理部３１１から情報処理ロジック部３１０に対し、メッセージ作成が終了した通知と、メッセージが出力される。なお、メッセージが出力されることにより、作成が終了した通知を兼ねてもよい。

ステップＳ３０８に続いてステップＳ３０９に進み、情報処理ロジック部３１０から通信クライアント部３５２に対し、メッセージの送信依頼が出力される。ステップＳ３０９に続いてステップＳ３１０に進み、通信クライアント部３５２からＰＣ１００に対し、メッセージが出力される。ここでは、例えば、ｈｔｔｐリクエストとして送信される。

ステップＳ３１０に続いてステップＳ３１１に進み、ＰＣ１００から通信クライアント部３５２に対し、メッセージが受信された通知が送信される。ここでは、例えば、ｈｔｔｐレスポンスとして送信される。ステップＳ３１１に続いてステップＳ３１２に進み、通信クライアント部３５２から情報処理ロジック部３１０に対し、メッセージが受信された通知が出力される。

（リクエストを解析する処理の例）
図１０は、情報処理ロジック部３１０及びデータ処理部３１１において、リクエストが解析される処理の例のフロー図である。図１０の処理は、例えば、図７のステップＳ１０４又は図８のステップＳ２０４において、リクエスト解析手段５１１によって実行される。図１０のステップＳ４０１では、データ処理部３１１に対してリクエストが入力される。

図１１に、リクエストの例を示す。図１１は、例えば、画像形成装置５００が有する図示しない記憶手段等に保持されるアドレス帳に新たなレコードを追加する要求の例である。なお、記憶手段は、例えば、データ形式保持手段５４２と一の構成でもよい。

図１１のリクエストは、ＨＴＴＰリクエストヘッダー部Ｒ１と、要求項目を含む本体であるＲ２とを含む。本体Ｒ２の内、符号ｅが付された箇所の記述により、このリクエストが、Ａｔｏｍと、名前空間ａ及び名前空間ｖｅｎｄｏｒで定義される拡張形式とで、記述されていることが示されている。名前空間ｖｅｎｄｏｒで定義される拡張形式が、本実施の形態における新たに追加された機能に対する要求項目に対応する。

Ｒ３は拡張形式で記述されている箇所である。Ｒ３には、名前「ｆｏｏ」に対応するメールアドレス、ファクシミリ番号等のレコードに係る情報、及び、それぞれ一の要求項目として含まれている。Ｒ３には、さらに、名前空間ｖｅｎｄｏｒにより識別されるタグを有する値ｇが含まれている。

図１０に戻り、ステップＳ４０１に続いてステップＳ４０２に進み、リクエスト解析手段５１１が、リクエストを先頭から解析することにより、標準形式の部分の判定を行う。ここでは、標準形式がＡ形式とＢ形式との何れであるかを判定し、Ａ形式である場合には、ステップＳ４０３に進み、Ｂ形式である場合には、ステップＳ４０６に進む。

なお、標準形式とは、例えば、リクエストがＸＭＬによって記述されている場合には、汎用的な規格であるＡＰＰ又はＡｔｏｍ等をいう。また、本発明の実施の形態は、２種類のうちの１の標準形式を処理する例に限らず、３種類以上の複数の標準形式の中から何れか一以上の標準形式を処理してもよい。

ステップＳ４０２に続くステップＳ４０３からステップＳ４０５では、Ａ形式で記述されている箇所について、リクエスト解析手段５１１が要求項目を取得する。さらに、処理内容取得手段５１２がその要求項目に対応する処理内容を取得する。ここで取得される処理内容は、機能実現手段毎に対応するデータ形式を有する。この処理は、Ａ形式で記述されている箇所が全て処理されるまで繰り返される。

なお、機能実現手段の識別情報は、リクエスト解析手段５１１によって取得される。機能実現手段の識別情報は、リクエストの中の要求項目毎に含まれてもよく、またリクエストの中の記述形式毎に対応づけられて含まれてもよい。

一方、ステップＳ４０２に続くステップＳ４０６からステップＳ４０８では、Ｂ形式で記述されている箇所について、リクエスト解析手段５１１と処理内容取得手段５１２とが、ステップＳ４０３からステップＳ４０５と同様の処理を行う。

標準形式で記述されている箇所の処理が終了した後、独自形式の処理に進む。ステップＳ４０９では、リクエスト解析手段５１１が、リクエストの中の独自形式の有無を判断する。独自形式がある場合には、ステップＳ４１０に進み、独自形式がない場合には、ステップＳ４１４に進む。なお、ステップＳ４０９の判定は、独自形式の有無に代えて、画像形成装置５００が処理する機能に対応する要求項目の項目群の有無の判定でもよい。画像形成装置５００が処理する機能に対応する要求項目の項目群がある場合には、ステップＳ４１０に進み、ない場合には、ステップＳ４１５に進む。

ステップＳ４０９に続くステップＳ４１０からＳ４１４では、リクエスト解析手段５１１が、リクエストに含まれている要求項目を取得する処理を、全ての要求項目が取得されるまで繰り返す。要求項目が取得される毎に、ステップＳ４１１において、処理内容取得手段５１２が、その要求項目に対応する処理内容の登録の有無を判断し、処理内容が登録されている場合には、ステップＳ４１２に進み、処理内容が登録されていない場合には、ステップＳ４１３に進む。

ステップＳ４１１に続くステップＳ４１２では、処理内容取得手段５１２が、その処理内容を取得する。ここで取得される処理内容は、機能実現手段毎に対応するデータ形式を有する。一方、ステップＳ４１１に続くステップＳ４１３では、処理内容取得手段５１２が、要求項目を、第二の記述形式に変換する。

図１２は、要求項目を第二の記述形式に変換することを説明する図である。図１２では、符号ｆを付した名前空間と符号ｇ１を付した要素とから、要求項目ｈ１が形成され、符号ｆを付した名前空間と符号ｇ２を付した要素とから、要求項目ｈ２が形成される。

これにより、リクエストの中に、画像形成装置５００に登録されていない機能に対する要求項目がある場合でも、その機能を実行することができる。したがって、画像形成装置５００に対し、新たに追加された機能実現手段がある場合でも、リクエストを生成するクライアント装置等が、その機能に対するリクエストを出力することができる。

図１０に戻り、ステップＳ４０９又はステップＳ４１３の処理の後、ステップＳ４１４に進み、取得された処理内容が、情報処理ロジック部３１０に出力される。

（未処理データとなるデータを含むリクエストの例）
図１３は、未処理データとなるデータ（要求項目）を含むリクエストの例を示す図である。図１３（Ａ）に示すリクエストは、Ａｔｏｍと、名前空間ａで定義される拡張形式とで記述されている。

図１３（Ｂ）に示すリクエストは、Ａｔｏｍと、名前空間ａ及び名前空間ｖｅｎｄｏｒで定義される拡張形式とで記述されている。このとき、Ｒ４は、名前空間ｖｅｎｄｏｒで定義される拡張形式で記述されている箇所であり、このｖｅｎｄｏｒ製機能を有していない画像形成装置５００にとってＲ４は不要データとなる。

図１３（Ｃ）に示すリクエストは、Ａｔｏｍと、名前空間ａで定義される拡張形式で記述されている。このとき、Ｒ５は、バージョンアップしたことにより追加された新規項目を記述した箇所であり、旧バージョンにしか対応していない画像形成装置５００にとってＲ５は未対応データとなる。

（レスポンス又はメッセージを生成する処理の例）
図１４は、情報処理ロジック部３１０及びデータ処理部３１１において、レスポンス又はメッセージが生成される処理の例のフロー図である。図１４の処理は、例えば、図８のステップＳ２１１において、レスポンス生成手段５１３によって実行され、また例えば、図９のステップＳ３０７においてメッセージ生成手段によって実行される。ここではレスポンス生成手段５１３によって実行される例について説明する。

図１４のステップＳ５０１では、情報処理ロジック部３１０からデータ処理部３１１に対し、レスポンスに含まれる応答項目のデータが入力される。このとき、未処理データのリストがある場合は、未処理データのリストも入力される。ステップＳ５０１に続いてステップＳ５０２に進み、レスポンス生成手段５１３が、入力されたデータに基づいて、レスポンスの記述形式を選択する。ここでは、標準形式の部分を選択し、Ａ形式によって記述する場合にはステップＳ５０３に進み、Ｂ形式によって記述する場合にはステップＳ５０６に進む。

なお、本発明の実施の形態は２つの標準形式のうちの何れか一を選択する例に限らず、複数の標準形式のうちの何れか一以上を選択し、その標準形式により記述されるレスポンスを生成してよい。

ステップＳ５０２に続くステップＳ５０３からステップＳ５０５では、レスポンス生成手段が、Ａ形式によって記述される応答項目のデータがなくなるまで、その応答項目がＡ形式によって記述されるデータを生成する。一方、ステップＳ５０２に続くステップＳ５０６からステップＳ５０８では、同様にＢ形式によって記述される応答項目のデータがなくなるまで、その応答項目がＢ形式によって記述されるデータを生成する。

ステップＳ５０５又はステップＳ５０８に続くステップＳ５０９では、レスポンス生成手段５１３が、応答項目のデータのうち、独自形式によって記述されるものの有無を判断する。独自形式によって記述されるものがある場合には、ステップＳ５１０に進み、ない場合には、ステップＳ５２２に進む。

ステップＳ５０９に続くステップＳ５１０からステップＳ５２１では、独自形式、又は未知の形式によって記述される応答項目のデータがなくなるまで、レスポンス生成手段５１３によってその応答項目を独自形式、又は未知の形式によって記述する処理が繰り返される。ステップＳ５１１において、レスポンス生成手段５１３が、未処理データリスト作成手段５１５から未処理データリストを取得したか否かを判断する。未処理データリストを取得していればステップＳ５１５に進み、取得していなければステップＳ５１２に進む。

ステップＳ５１１に続いてステップＳ５１２では、その応答項目が未知のデータであるか否かを判断する。未知のデータとは、例えば、その応答項目が予め登録されたデータ形式を有さないデータである。未知のデータは、例えば、第二の記述形式により記述される。第二の記述形式とは、例えば、名前空間名、変数名又はタグ名、及び、値を有する。

既知のデータである場合には、ステップＳ５１３に進み、未知のデータである場合には、ステップＳ５１４に進む。ステップＳ５１２に続くステップＳ５１３では、レスポンス生成手段５１３が、取得された応答項目のデータ形式を参照して、第一の記述形式によるレスポンスを生成する。一方、ステップＳ５１２に続くステップＳ５１４では、レスポンス生成手段５１３が、取得された第二の記述形式による応答項目から、第一の記述形式によるレスポンスを生成する。

図１５は、第二の記述形式による応答項目から、第一の記述形式によるレスポンスが生成されることを説明する図である。図１５では、符号ｒ１を付した応答項目から、名前空間ｓと要素ｔ１とが生成され、符号ｒ２を付した応答項目から、名前空間ｓと要素ｔ２とが生成される。

図１４に戻り、ステップＳ５１１に続くステップＳ５１５からステップＳ５１７では、レスポンス生成手段５１３によって、未対応データリスト内のデータを未対応データとして記述する処理が、未対応データがなくなるまで繰り返される。また、ステップＳ５１７に続くステップＳ５１８からステップＳ５２０では、レスポンス生成手段５１３によって、不要データリスト内のデータを不要データとして記述する処理が、不要データがなくなるまで繰り返される。なお、前述したように未処理データには、未対応データと不要データとがある。

図１６は、不要データリスト（第二の記述形式）による応答項目から、第一の記述形式によるレスポンスが生成されることを説明する図である。図１６では、符号ｒ１１を付した第二の記述形式の応答項目から第一の記述形式の要素ｔ１１が生成される。

図１７は、未対応データリスト（第二の記述形式）による応答項目から、第一の記述形式によるレスポンスが生成されることを説明する図である。図１７では、符号ｒ２１を付した第二の記述形式の応答項目から第一の記述形式の要素ｔ２１が生成される。

図１４に戻り、ステップＳ５０９又はステップＳ５２１に続いてステップＳ５２２に進み、レスポンス生成手段５１３によって生成されたレスポンスが、情報処理ロジック部３１０に対して出力される。

（レスポンスの例）
図１８及び図１９は、レスポンスの例を説明する図である。図１８は、図１１のリクエストに対応して生成されるレスポンスの例である。図１８では、図１１のリクエストに基づいて処理された内容が含まれている。すなわち、アドレス帳に追加されたレコードの内容である、名前「ｆｏｏ」と、その名前に対応するメールアドレス、ファクシミリ番号等が、それぞれ一の応答項目として含まれている。さらに、符号ｕ１を付した箇所に、名前空間ｖｅｎｄｏｒによって識別されるアドレス帳に対する操作処理の応答項目が含まれている。

図１９は、図１１のリクエストに対応して生成されるレスポンスの例であって、図１８とは異なるレスポンスの例である。図１９のレスポンスは、「ｕｎｓｕｐｐｏｒｔｅｄ」タグ内に「ｄｅｌｉｖｅｒＤｅｓｔｉｎａｔｉｏｎ」及び「ｄｅｌｉｖｅｒ＊＊＊」タグが記述されている。これは、図１９に示すレスポンスを生成した画像形成装置がｖｅｎｄｏｒの名前空間で表されるようなデータを持つ機能を有していないことにより、これらのタグが処理されなかったことを表すものである。つまり、タグ＜ｕｎｓｕｐｐｏｒｔｅｄ＞は、そもそもその機能を有していないことを示すタグである。

また、アドレス帳の中のデータを編集する場合には、ＨＴＴＰのＰＵＴを用い、リクエストが入力され、その応答であるレスポンスが出力されてもよい。また、アドレス帳の中のデータを参照する場合には、ＨＴＴＰのＧＥＴを用い、レスポンスデータが出力されてもよい。また、アドレス帳の中のデータを削除する場合には、ＨＴＴＰのＤＥＬＥＴＥを用い、リクエスト及びレスポンスのデータのやりとりがなくてもよい。

（メッセージの例）
図２０は、メッセージの例である。図２０（Ａ）は、画像形成装置に異常が発生したことを、クライアントＰＣに対して通知するメッセージの例であり、図２０（Ｂ）は、そのメッセージに対して、クライアントＰＣから出力される応答の例である。

図２０（Ａ）において、符号ｗ１を付した名前空間と、符号ｗ２を付した要素とが、第二の記述形式から変換されて得られた応答項目である。ここでは、メッセージは、ＨＴＴＰリクエストとして送信され、応答はＨＴＴＰレスポンスとして返信されている。

（コンピュータの構成）
図２１は、本実施形態の画像形成装置又はクライアント装置を実現するコンピュータの構成図である。図２１のコンピュータは、主処理部４００、入力デバイス４１０、表示装置４２０、プリンタ４３０、スキャナ４４０、及び、ＨＤＤ４９０を有する。主処理部４００は、コンピュータの機能を実現する主たる部分であり、ＣＰＵ４０１、ＲＯＭ４０８、及び、ＲＡＭ４０９を有する。ＣＰＵ４０１は、コンピュータプログラムをＲＯＭ４０８等から読み出し、ＲＡＭ４０９に展開することにより、本実施形態のコンピュータプログラムを実行する。ＲＯＭ４０８は不揮発性のメモリであり、ＣＰＵ４０１によって実行されるプログラム、及び、画像形成装置又はクライアント装置の制御に必要なパラメータ等を保持する。ＲＡＭ４０９は、ＣＰＵ４０１が処理を行う際の、ワークメモリである。

入力デバイス４１０は、例えば、キーボード等であり、操作者が指示の入力を行う際に使用する。表示装置４２０は、コンピュータの状態等の表示を行う。プリンタ４３０は、画像を媒体に形成して出力する装置であり、スキャナ４４０は、媒体上に形成された画像を光学的に読み取る装置である。ＨＤＤ４９０は、画像のデータ等の大容量のデータを格納する。

本実施形態のコンピュータプログラムは、ＨＤＤ４９０、又は、ＲＯＭ４０８に格納される他に、その他図示しないドライブ装置に挿入可能な記録媒体に格納されていてもよい。

なお、本発明は、さらに、上記画像形成装置を有する画像形成システム、上記画像形成装置又は上記画像形成システムにおける情報処理方法、及び、その情報処理方法をコンピュータに実行させるためのコンピュータプログラムとしてもよい。また、このコンピュータプログラムを記録した記録媒体をコンピュータに読み取らせて、上記処理を実行できるようにしてもよい。

以上、発明を実施するための最良の形態について説明を行ったが、本発明は、この最良の形態で述べた実施の形態に限定されるものではない。本発明の主旨をそこなわない範囲で変更することが可能である。

１、２、３ ＰＣ
４、５、６、３５、３６、３００ＭＦＰ
１５ クライアント装置
２５ ＬＰ
３７、３８ 画像形成装置
４５ 印刷機
３１０、５１０、６１０ 情報処理ロジック部
３１１ データ処理部
３３０ 情報アクセス部
３４０ 情報保持部
３５１ 通信サーバ部
３５２ 通信クライアント部
３９０ ネットワークインタフェース
４００ コンピュータの主処理部
４０１ ＣＰＵ
４０８ ＲＯＭ
４０９ ＲＡＭ
４１０ 入力デバイス
４２０ 表示装置
４３０ プリンタ
４４０ スキャナ
４９０ ＨＤＤ
５００ 画像形成装置
５１１ リクエスト解析手段
５１２ 処理内容取得手段
５１３ レスポンス生成手段
５１４ メッセージ生成手段
５１５ 未処理データリスト作成手段
５３０、６３０ 機能実現手段
５４１、６４１ 一覧管理手段
５４２、６４２ データ形式保持手段
５５０、６５０ 通信手段
６１１ リクエスト生成手段
６１２ レスポンス解析手段
６１３ ステータス取得手段

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

Claims (11)

1. 当該画像形成装置に接続された機能実現手段の一覧を管理する一覧管理手段と、
   クライアント装置からの第一の記述形式によるリクエストを受信する通信手段と、
   前記リクエストを解析して該リクエストに含まれる機能実現手段の識別情報と要求項目とを取得して出力するリクエスト解析手段と、
   前記機能実現手段毎に、前記要求項目に対応する処理内容のデータ形式及び前記処理内容に対応する応答項目のデータ形式を保持するデータ形式保持手段と、
   前記リクエスト解析手段からの出力に基づいて、前記要求項目を前記処理内容のデータ形式にして前記機能実現手段に対して出力し、前記機能実現手段に対応する処理内容が無い場合には、前記要求項目を第二の記述形式にして前記機能実現手段に対して出力する処理内容取得手段と、
   前記機能実現手段により処理済の前記応答項目のデータ形式による応答項目、及び／又は、前記機能実現手段により未処理の前記第二の記述形式による応答項目に基づいて、前記応答項目が、前記処理済と前記未処理と区別されて前記第一の記述形式により記述されたレスポンスを生成するレスポンス生成手段と、
   を有する画像形成装置。
2. 前記未処理の応答項目は、前記要求項目に対応する機能実現手段がないことによる第１応答項目と、前記要求項目に対応する機能実現手段が処理できないことによる第２応答項目を含み、
   前記レスポンス生成手段は、
   前記第１応答項目と前記第２応答項目と区別されて記述されたレスポンスを生成する請求項１記載の画像形成装置。
3. 前記要求項目のそれぞれは、複数の項目群の何れか一に属し、
   前記リクエストは前記項目群のうちの何れか一以上の項目群の要求項目を有する請求項１又は２記載の画像形成装置。
4. 前記処理内容取得手段は、前記要求項目が属する項目群に基づいて、前記要求項目に対応する処理内容の有無を判断する請求項３記載の画像形成装置。
5. 前記応答項目は、該応答項目に対応する処理内容の要求項目が属する項目群に属する請求項１ないし３いずれか一項に記載の画像形成装置。
6. 前記データ形式保持手段は、さらに、前記機能実現手段毎に、該機能実現手段の状態に係る状況項目のデータ形式を保持し、
   前記機能実現手段から、前記状況項目のデータ形式、及び／又は、前記第二の記述形式による状況項目を取得して、前記第一の記述形式により前記状況項目が記述されたメッセージを生成するメッセージ生成手段と、
   を有し、
   前記通信手段は、さらに、前記メッセージを前記クライアント装置に送信する請求項１ないし５何れか一項に記載の画像形成装置。
7. 前記第一の記述形式はＸＭＬよって表される記述形式であり、
   前記項目群は名前空間によって識別される請求項３又は４記載の画像形成装置。
8. 前記通信手段は、所定のプロトコルにより前記リクエストの受信を行う請求項１ないし７何れか一項に記載の画像形成装置。
9. 前記通信手段は、所定のインタフェースにより前記クライアント装置との通信を行う請求項１ないし８何れか一項に記載の画像形成装置。
10. クライアント装置と画像形成装置とが接続された画像形成システムであって、
    前記クライアント装置は、
    前記画像形成装置に対する要求項目を有するリクエストを第一の記述形式により生成するリクエスト生成手段と、
    前記リクエストを送信する第一の通信手段と、
    を有し、
    前記画像形成装置は、
    当該画像形成装置に接続された第二の機能実現手段の一覧を管理する第二の一覧管理手段と、
    クライアント装置からの第一の記述形式によるリクエストを受信する第二の通信手段と、
    前記リクエストを解析して該リクエストに含まれる第二の機能実現手段の識別情報と要求項目とを取得して出力するリクエスト解析手段と、
    前記第二の機能実現手段毎に、前記要求項目に対応する処理内容のデータ形式及び前記処理内容に対応する応答項目のデータ形式を保持する第二のデータ形式保持手段と、
    前記リクエスト解析手段からの出力に基づいて、前記要求項目を前記処理内容のデータ形式にして前記第二の機能実現手段に対して出力し、前記第二の機能実現手段に対応する処理内容が無い場合には、前記要求項目を第二の記述形式にして前記第二の機能実現手段に対して出力する処理内容取得手段と、
    前記機能実現手段により処理済の前記応答項目のデータ形式による応答項目、及び／又は、前記機能実現手段により未処理の前記第二の記述形式による応答項目に基づいて、前記応答項目が、前記処理済と前記未処理と区別されて前記第一の記述形式により記述されたレスポンスを生成するレスポンス生成手段と、
    を有する画像形成システム。
11. 当該画像形成装置に接続された機能実現手段毎に、リクエストに含まれる要求項目に対応する処理内容のデータ形式及び前記処理内容に対応する応答項目のデータ形式を保持するデータ形式保持手段を備える画像形成装置における情報処理方法であって、
    クライアント装置からの第一の記述形式による前記リクエストを受信する受信ステップと、
    前記リクエストを解析して該リクエストに含まれる機能実現手段の識別情報と要求項目とを取得して出力するリクエスト解析ステップと、
    前記リクエスト解析ステップからの出力に基づいて、前記要求項目を前記処理内容のデータ形式にして前記機能実現手段に対して出力し、前記機能実現手段に対応する処理内容が無い場合には、前記要求項目を第二の記述形式にして前記機能実現手段に対して出力する処理内容取得ステップと、
    前記機能実現手段により処理済の前記応答項目のデータ形式による応答項目、及び／又は、前記機能実現手段により未処理の前記第二の記述形式による応答項目に基づいて、前記応答項目が、前記処理済と前記未処理と区別されて前記第一の記述形式により記述されたレスポンスを生成するレスポンス生成ステップと、
    を有する情報処理方法。

Images