JP5041972B2 - 画像形成装置、画像形成システム、情報処理装置、コンピュータプログラム、及び情報記録媒体 - Google Patents

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（要求項目を取捨選択することにより生じる課題）
図２は、ＷＳ部において要求項目を取捨選択することにより生じる課題を説明する図である。図２の画像形成装置３７は、ＷＳ部３７１と一以上の機能実現部３７２を有する。ＷＳ部３７１がリクエストに含まれている要求項目のうち、予め登録されている要求項目を取得して、機能実現部３７２に振り分けている。

しかしながら、機能実現部３７２が後から追加された場合には、その機能実現部に対応する要求項目が登録されていない場合も生じる。そのような場合に、要求項目がＷＳ部３７１によって読み飛ばされてしまうと、機能実現部３７２が実装されているにも関わらず、要求項目が伝達されないために、その機能が実現されないという不具合が生じる。

（未知の要求項目を伝達する例）
図３では、リクエストに含まれている要求項目のうち、予め登録されていない要求項目をも振り分けることを説明する図である。図３の画像形成装置３８は、ＷＳ部３８１と機能実現部３８２を有する。図３では、リクエストａのうち、予め登録されている要求項目に係る部分ａ２と、登録されていない要求項目に係る部分ａ１の双方が、ＷＳ部３８１により、機能実現部３８２に振り分けられる。これにより、要求項目に対応する処理内容を、機能実現部３８２が実行することができる。

予め登録されていない要求項目とは、例えば、ＷＳ部３８１が、その要求項目に対応するデータ形式を取得できない要求項目である。このような状態は、例えば、その機能実現部３８２が、画像形成装置３８に新たに追加された機能に係る機能実現部である場合に生じる。

（未知の応答項目を伝達する例）
図４は、予め登録されていない応答項目を含むメッセージを生成する処理を説明する図である。図４では、画像形成装置３８が有する各機能実現部３８２から、ＷＳ部３８１に対し、応答項目が出力される。これらの応答項目は、機能実現部毎に対応する所定のデータ形式でもよい。しかし、ＷＳ部３８１が、その機能実現部に対応するデータ形式を取得できない場合には、予め定められる所定の記述形式により、応答項目が取得される。

なお、ＷＳ部３８１が、応答項目のデータ形式を取得できない機能実現部３８２とは、例えば、画像形成装置３８に対して新たに追加された機能に係る機能実現部であり、また例えば、その機能実現部に対する要求項目のデータ形式が取得できなかった機能実現部である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これにより、画像形成装置５００が有する新たに追加された機能実現手段が出力する応答項目に対応するレスポンスを生成することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ステップＳ５０９に続くステップＳ５１０からステップＳ５１３では、独自形式によって記述される応答項目のデータがなくなるまで、レスポンス生成手段５１３によってその応答項目を独自形式によって記述する処理が繰り返される。ステップＳ５１１において、レスポンス生成手段５１３が、その応答項目が未知のデータであるか否かを判断する。未知のデータとは、例えば、その応答項目が予め登録されたデータ形式を有さないデータである。未知のデータは、例えば、第二の記述形式により記述される。第二の記述形式とは、例えば、名前空間名、変数名又はタグ名、及び、値を有する。

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

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

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

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

図１７は、図１２のリクエストに対応して生成されるレスポンスの例であって、図１６とは異なるレスポンスの例である。図１７のレスポンスは、ｆａｘＡｄｄｒｅｓｓとｆａｘＮｕｍｂｅｒとに係る応答項目が含まれていない。これは、このレスポンスを生成した画像形成装置が有する機能が、これらの情報をアドレス帳に含ませる機能を有していないためである。

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

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

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

（画像形成装置の他の実施の形態）
図１９から図２１は、画像形成装置の他の装置における本実施の形態を説明する図である。図１９及び図２０は、画像形成装置３９から、情報収集サーバ７０に対して送信されるデータを介する仲介機器を説明する図である。

図１９では、画像形成装置３９から情報収集サーバ７０に対し、データａが出力される。画像形成装置３９と情報収集サーバ７０との間のデータを介する仲介機器８０では、データａのうち、拡張部分であるａ１を読み飛ばし、残りの部分であるａ２を、情報収集サーバ７０に対応する記述形式に変換して出力する。これにより、読み飛ばされた部分であるａ１の情報が、情報収集サーバ７０に伝達されない。

図２０は、図１９の不具合を解消することを説明する図である。図２０では、仲介機器８１は、画像形成装置３９から出力されるデータａを、情報収集サーバ７０に対応する記述形式ａ'に変換して出力する。この際、未知のデータの部分については、例えば、第二の記述形式に変換することにより、情報収集サーバ７０に対応するデータ形式ではないものの、汎用的なデータ形式として情報収集サーバ７０に伝達することができる。これにより、情報収集サーバ７０が、画像形成装置３９から出力された情報を、全て取得することができる。

図２１は、画像形成装置３９からのメッセージ等を取得して処理するクライアント装置を説明する図である。図２１のクライアント装置１６は、通信部１６１、機能実現部１６２、及び、機能実現部１６３を有する。通信部１６１は、画像形成装置３９からのメッセージｍを取得する。

取得されたメッセージｍは、レスポンス解析手段６１２により解析され、ステータス取得手段６１３により、予め登録されている状況項目が取得される。ステータス取得手段６１３は、また、レスポンスに含まれている状況項目のうち登録されていない状況項目の内容がある場合には、その状況項目を、第二の記述形式に変換する。

機能実現部１６２は、機能実現部１６２に対応するデータ形式に変換された状況項目を取得して、その状況項目に対応する処理を行う。一方、機能実現部１６３は、第二の記述形式に変換された状況項目を取得して、その状況項目に対応する処理を行う。

これにより、クライアント装置１６において、新たな機能実現部が追加された場合でも、その機能に対応するデータ形式を登録することなく、汎用的な記述形式により、その機能実現部に対する入出力を行うことができる。

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

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

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

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

一のリクエストをそれぞれの装置が処理することを説明する図。 要求項目を取捨選択することにより生じる課題を説明する図。 未知の要求項目を伝達する例を説明する図。 未知の応答項目を伝達する例を説明する図。 本実施の形態による画像形成システムの例を説明する図。 本実施の形態に係る画像形成装置であるＭＦＰの装置構成の例を説明する図。 本実施の形態に係る画像形成システムの機能構成の例を説明する図。 クライアントからのリクエストに基づく処理の例のシーケンス図。 クライアントからのリクエストに基づく処理とレスポンスを送信する処理の例のシーケンス図。 イベントに基づくメッセージが送信される場合の処理の例のシーケンス図。 リクエストが解析される処理の例のフロー図。 リクエストの例。 要求項目を第二の記述形式に変換することを説明する図。 レスポンス又はメッセージが生成される処理の例のフロー図。 第二の記述形式による応答項目から第一の記述形式によるレスポンスが生成されることを説明する図。 レスポンスの例（その１）。 レスポンスの例（その２）。 メッセージの例。 画像形成装置から情報収集サーバに対して送信されるデータを介する仲介機器を説明する図（その１）。 画像形成装置から情報収集サーバに対して送信されるデータを介する仲介機器を説明する図（その２）。 画像形成装置からのメッセージ等を取得して処理するクライアント装置を説明する図。 本実施形態の画像形成装置又はクライアント装置を実現するコンピュータの構成図。

符号の説明

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

Claims (15)

1. 当該画像形成装置が有する機能実現手段の一覧を管理する一覧管理手段と、
   クライアント装置からの第一の記述形式によるリクエストを受信する通信手段と、
   機能実現手段毎に、受信するリクエストに含まれる要求項目と、該要求項目に対応する処理内容と、処理内容に対応するデータ形式との対応関係を保持するデータ形式保持手段と、
   受信した前記リクエストを解析して、要求項目と該要求項目を実現する機能実現手段とを抽出するリクエスト解析手段と、
   前記リクエスト解析手段に抽出された要求項目を、前記データ形式保持手段に保持された対応関係に従って、抽出された機能実現手段の処理内容に対応するデータ形式に変換して、前記一覧から選択した対応する機能実現手段に出力する処理内容取得手段と、
   を有し、
   前記処理内容取得手段は、前記リクエスト解析手段に抽出された要求項目が、前記データ形式保持手段に保持された対応関係に無い場合には、該要求項目を予め定められた第二の記述形式に変換して、前記一覧から選択した対応する機能実現手段に出力すること、
   を特徴とする画像形成装置。
2. 前記データ形式保持手段は、さらに、前記機能実現手段毎に、前記処理内容に対応する応答項目に対応するデータ形式との対応関係を保持し、
   前記機能実現手段から入力される応答項目が前記第二の記述形式による応答項目である場合、前記第一の記述形式により前記応答項目が記述されたレスポンスを生成するレスポンス生成手段を有し、
   前記通信手段は、さらに、前記レスポンスを前記クライアント装置に送信する請求項１記載の画像形成装置。
3. 前記データ形式保持手段は、さらに、前記機能実現手段毎に、該機能実現手段の状態に係る状況項目に対応するデータ形式との対応関係を保持し、
   前記機能実現手段から入力される状況項目が前記第二の記述形式による状況項目である場合、前記第一の記述形式により前記状況項目が記述されたメッセージを生成するメッセージ生成手段と、
   を有し、
   前記通信手段は、さらに、前記メッセージを前記クライアント装置に送信する請求項１又は２何れか一項に記載の画像形成装置。
4. 前記通信手段は、所定のプロトコルにより前記リクエストの受信を行う請求項１ないし３何れか一項に記載の画像形成装置。
5. 前記通信手段は、所定のインタフェースにより前記クライアント装置との通信を行う請求項１ないし４何れか一項に記載の画像形成装置。
6. クライアント装置と画像形成装置とが接続された画像形成システムであって、
   前記クライアント装置は、
   前記画像形成装置に対する要求項目を有するリクエストを第一の記述形式により生成するリクエスト生成手段と、
   前記リクエストを送信する第一の通信手段と、
   を有し、
   前記画像形成装置は、
   当該画像形成装置が有する機能実現手段の一覧を管理する一覧管理手段と、
   前記クライアント装置からの第一の記述形式によるリクエストを受信する第二の通信手段と、
   機能実現手段毎に、受信するリクエストに含まれる要求項目と、該要求項目に対応する処理内容と、処理内容に対応するデータ形式との対応関係を保持するデータ形式保持手段と、
   受信した前記リクエストを解析して、要求項目と該要求項目を実現する機能実現手段とを抽出するリクエスト解析手段と、
   前記リクエスト解析手段に抽出された要求項目を、前記データ形式保持手段に保持された対応関係に従って、抽出された機能実現手段の処理内容に対応するデータ形式に変換して、前記一覧から選択した対応する機能実現手段に出力する処理内容取得手段と、
   を有し、
   前記処理内容取得手段は、前記リクエスト解析手段に抽出された要求項目が、前記データ形式保持手段に保持された対応関係に無い場合には、該要求項目を予め定められた第二の記述形式に変換して、前記一覧から選択した対応する機能実現手段に出力すること、
   を特徴とする画像形成システム。
7. 前記画像形成装置において、
   前記データ形式保持手段は、さらに、前記機能実現手段毎に、前記処理内容に対応する応答項目に対応するデータ形式との対応関係を保持し、
   前記機能実現手段から入力される応答項目が前記第二の記述形式による応答項目である場合、前記第一の記述形式により前記応答項目が記述されたレスポンスを生成するレスポンス生成手段を有し、
   前記第二の通信手段は、さらに、前記レスポンスを前記クライアント装置に送信する請求項６記載の画像形成システム。
8. 前記画像形成装置において、
   前記データ形式保持手段は、さらに、前記機能実現手段毎に、該機能実現手段の状態に係る状況項目に対応するデータ形式との対応関係を保持し、
   前記機能実現手段から入力される状況項目が前記第二の記述形式による状況項目である場合、前記第一の記述形式により前記状況項目が記述されたメッセージを生成するメッセージ生成手段と、
   を有し、
   前記二の通信手段は、さらに、前記メッセージを前記クライアント装置に送信する請求項６又は７何れか一項に記載の画像形成システム。
9. 前記第一の通信手段による前記リクエストの送信と、前記第二の通信手段による前記レスポンスの送信とは、所定のプロトコルにより行われる請求項６ないし８何れか一項に記載の画像形成システム。
10. 前記第二の通信手段は、所定のインタフェースにより前記クライアント装置との通信を行う請求項６ないし１０何れか一項に記載の画像形成システム。
11. 画像形成装置における情報処理方法であって、
    当該画像形成装置が有する機能実現手段の一覧を管理する一覧管理ステップと、
    クライアント装置からの第一の記述形式によるリクエストを受信する受信ステップと、
    機能実現手段毎に、受信するリクエストに含まれる要求項目と、該要求項目に対応する処理内容と、処理内容に対応するデータ形式との対応関係を保持するデータ形式保持ステップと、
    受信した前記リクエストを解析して、要求項目と該要求項目を実現する機能実現手段とを抽出するリクエスト解析ステップと、
    前記リクエスト解析ステップで抽出された要求項目を、前記保持された対応関係に従って、抽出された機能実現手段の処理内容に対応するデータ形式に変換して、前記一覧から選択した対応する機能実現手段に出力する処理内容取得ステップと、
    を有し、
    前記処理内容取得ステップは、前記リクエスト解析ステップで抽出された要求項目が、前記保持された対応関係に無い場合には、該要求項目を予め定められた第二の記述形式に変換して、前記一覧から選択した対応する機能実現手段に出力すること、
    を特徴とする情報処理方法。
12. 前記データ形式保持ステップは、さらに、前記機能実現手段毎に、前記処理内容に対応する応答項目に対応するデータ形式との対応関係を保持し、
    前記機能実現手段から入力される応答項目が前記第二の記述形式による応答項目である場合、前記第一の記述形式により前記応答項目が記述されたレスポンスを生成するレスポンス生成ステップと、
    前記レスポンスを前記クライアント装置に送信する送信ステップと、
    を有する請求項１１記載の情報処理方法。
13. 前記データ形式保持ステップは、さらに、前記機能実現手段毎に、該機能実現手段の状態に係る状況項目に対応するデータ形式との対応関係を保持し、
    前記機能実現手段から入力される入力される状況項目が前記第二の記述形式による状況項目である場合、前記第一の記述形式により前記状況項目が記述されたメッセージを生成するメッセージ生成手段と、
    を有し、
    前記メッセージを前記クライアント装置に送信するステップと、
    を有する請求項１１又は１２記載の情報処理方法。
14. 請求項１１ないし１３何れか一項に記載の情報処理方法を、コンピュータに実行させるコンピュータプログラム。
15. 請求項１４記載のコンピュータプログラムを格納したコンピュータ読み取り可能な情報記録媒体。

Images