JP2009059051A - 画像形成装置、情報処理方法、及び、画像形成システム - Google Patents

Abstract

【課題】複数の画像形成装置がサポートするリクエストが互いに異なる形式の場合に、そのリクエストの内容を解析して好適に処理する画像形成装置、画像形成システム、及び、情報処理方法を提供すること。
【解決手段】 クライアント装置からの所定の記述形式によるリクエストを受信する通信手段と、前記リクエストを解析して該リクエストに含まれる要求項目を取得して出力するリクエスト解析手段と、前記リクエスト解析手段からの出力に基づいて、前記要求項目に対応する処理内容を取得し、前記要求項目に対応する処理内容がない場合には、前記リクエスト解析手段からの次の出力を受け付ける処理内容取得手段と、前記要求項目に対応する処理を実行する実行手段と、を有する画像形成装置。
【選択図】図９

Description

本発明は、画像形成装置、情報処理方法、及び、画像形成システムに関する。

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

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

しかしながら、上記特許文献１及び２に開示の技術では、ファームウェア等のソフトウェアの更新のみでは対応できないバージョン間の相違は考慮されていない。例えば、新バージョンを有する装置に搭載された新機能を含む形式の要求が、その機能を持たない旧バージョンの装置に対して送信された場合に、旧バージョンの装置では、新機能に係る要求は当然のことながら、新機能を除く部分の要求までも処理することができないという不具合があった。

そこで、これを解消するために、装置のバージョン毎に対応する形式により要求を生成することが考えられる。しかしながら、例えば、画像形成装置のように、一のオフィスで複数のバージョンの画像形成装置が使用されることがあるものについて、それぞれのバージョンに対応して要求を生成するクライアント装置を設けることは、コストの増加や管理の煩雑さが問題になる。

本発明は、上記の点に鑑みて、これらの問題を解消するために発明されたものであり、複数の画像形成装置がサポートするリクエストが互いに異なる形式の場合に、そのリクエストの内容を解析して好適に処理する画像形成装置、画像形成システム、及び、情報処理方法を提供することを目的としている。

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

本発明の画像形成装置は、クライアント装置からの所定の記述形式によるリクエストを受信する通信手段と、前記リクエストを解析して該リクエストに含まれる要求項目を取得して出力するリクエスト解析手段と、前記リクエスト解析手段からの出力に基づいて、前記要求項目に対応する処理内容を取得し、前記要求項目に対応する処理内容がない場合には、前記リクエスト解析手段からの次の出力を受け付ける処理内容取得手段と、前記要求項目に対応する処理を実行する実行手段と、を有する構成とすることができる。

これにより、複数の画像形成装置がサポートするリクエストが互いに異なる形式の場合に、そのリクエストの内容を解析して好適に処理する画像形成装置を提供することができる。

なお、上記課題を解決するため、本発明は、さらに、上記画像形成装置を有する画像形成システム、又は、その画像形成装置若しくは画像形成システムが備える各手段を実行する情報処理方法としてもよい。

本発明の画像形成装置、画像形成システム、及び、情報処理方法によれば、複数の画像形成装置がサポートするリクエストが互いに異なる形式の場合に、そのリクエストの内容を解析して好適に処理する画像形成装置、画像形成システム、情報処理方法を提供することが可能になる。

以下、本発明の実施の形態を図面に基づき説明する。
〔本発明の実施の形態〕
（従来の画像形成システムによるリクエストの例）
図１及び図２は、本発明の実施の形態により解決しようとする課題を説明する図である。図１の画像形成システムでは、ネットワークを介してレーザプリンタ（以下、「ＬＰ」という。）２０、ＭＦＰ３１、ＭＦＰ３２、印刷機４０、及び、クライアント装置であるＰＣ１０が接続されている。ＭＦＰ３１とＭＦＰ３２とは、バージョンが異なるために、インタフェース及びリクエストのパラメータ等が異なる。また、ＬＰ２０、ＭＰＰ３１、及び、印刷機４０は、プラットフォームが異なるために、通信のプロトコル及びインタフェースが異なる。

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

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

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

図２の画像形成システムは、ネットワークを介して、ＭＦＰ３３、ＭＦＰ３４、及び、クライアントＰＣであるＰＣ１１とＰＣ１２が接続されている。ＭＦＰ３３とＰＣ１１とは、旧バージョンであるバージョン１に対応し、ＭＦＰ３４とＰＣ１２とは、新バージョンであるバージョン２に対応している。

図２において、ＰＣ１２は、過去の製品であるＭＦＰ３３のインタフェースにも対応しているため、ＭＦＰ３４に加えてＭＦＰ３３の情報にアクセスすることができる。一方、ＰＣ１１は、後の製品であるＭＦＰ３４のインタフェースには対応していないため、ＭＦＰ３３の情報にはアクセスすることができるが、ＭＦＰ３３の情報にはアクセスすることができない。

（本実施の形態による画像形成システムによるリクエストとレスポンスの例）
図３から図６は、本実施の形態による画像形成システムを説明する図である。図３及び図４の画像形成システムは、クライアント装置であるＰＣ１５が、ＬＰ２５、ＭＦＰ３５、ＭＦＰ３６及び印刷機４５と、ネットワークを介して接続されている。

図３では、ＬＰ２５、ＭＦＰ３５、ＭＦＰ３６及び印刷機４５は、同一のインタフェースであり、リクエスト及びそのレスポンスの送受信に用いられるプロトコルは同一である。

図４は、図３の画像形成システムにおいて、各装置が、ＰＣ１５から送信されるリクエストを解析する処理を説明する図である。図４では、リクエストのデータフォーマットは、例えば、ＸＭＬの形式を有し、リクエストに含まれる要求項目のうち、各装置が有する機能に対応する要求項目のみが、各装置において処理される。

すなわち、ＰＣ１５から送信されるリクエストａのうち、ＬＰ２５は、自身が有する機能に対応する箇所であるａ１の部分の要求項目に対する処理を行う。同様に、ＭＦＰ３６は、自身が有する機能に対応する箇所であるａ２の部分の要求項目に対する処理を行う。ＭＦＰ３５と印刷機４５とは、リクエストａに含まれる全ての要求項目に対応する機能を有するので、それらに対応する処理を行う。

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

図５は、バージョンが異なる２つのクライアントＰＣを有する画像形成システムの例を説明する図である。図５の画像形成システムは、ＰＣ１６とＰＣ１７とが、ネットワークを介して、ＭＦＰ３５とＭＦＰ３６と接続されている。ＰＣ１６とＭＦＰ３５とは、旧バージョンであるバージョン１に対応し、ＰＣ１７とＭＦＰ３６とは、新バージョンであるバージョン２に対応している。

そこで、ＰＣ１６からＭＦＰ３６及びＭＦＰ３７に対しては、旧バージョンに対応するデータフォーマットのリクエストｂが出力される。一方、ＰＣ１７からＭＦＰ３６及びＭＦＰ３７に対しては、新バージョンに対応するデータフォーマットのリクエストｃが出力される。

ＭＦＰ３７は、リクエストｂ及びリクエストｃの何れのリクエストについても、含まれる要求項目の全てを処理する。一方、ＭＦＰ３６は、リクエストｂに含まれる要求項目は全て処理することができるが、リクエストｃに含まれる要求項目のうち、バージョン２に対応するリクエストであるｃ２の部分の要求項目の処理は行わず、バージョン１に対応するリクエストであるｃ１の部分の要求項目の処理のみを行う。

図５より、リクエストの表記形式が統一されていることにより、クライアントＰＣが、ＭＦＰとクライアントＰＣ自身のバージョンを考慮することなく、リクエストを送信し、ＭＦＰがそのリクエストに含まれる処理を行うことができる。

図６は、装置からのレスポンスを受信するクライアントＰＣを説明する図である。図６のＰＣ１８は、ネットワークを介して、ＬＰ２５、ＭＦＰ３５、ＭＦＰ３６、及び、印刷機４５と接続されている。各装置からは、リクエストに対応した処理の後に出力するレスポンスが、ＰＣ１８に対して出力される。

ＬＰ２５はレスポンスｄ１を、ＭＦＰ３５はレスポンスｄ１を含むレスポンスｄ２を、ＭＦＰ３６はレスポンスｄ２を、印刷機４５はレスポンスｄ３を含むレスポンスｄ２を、それぞれ出力している。これらのレスポンスに記載されている内容は異なるが、その記述形式は統一されている。ＰＣ１８は、レスポンスｄ１からｄ３の全てを含むレスポンスｄを処理することにより、各装置のステータスを管理することができる。

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

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

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

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

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

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

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

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

処理内容取得手段５１２は、リクエスト解析手段５１１によって解析された内容に基づいて、要求項目に対応する処理内容を取得する。処理内容取得手段５１２は、要求項目に対応する処理内容が取得できない場合には、その要求項目に係る処理は行わず、次の要求項目に係る処理を行う。

これにより、異なるバージョンに基づくリクエストであっても、その表記形式が同一であれば、画像形成装置５００は、リクエストに含まれている要求項目のうち、自身が処理することのできる要求項目に対応する処理を行い、他の要求項目に係る処理は行わないようにすることができる。

レスポンス生成手段５１３は、処理した要求項目に対応するレスポンスを生成する。レスポンス生成手段５１３が生成するレスポンスは、例えば、画像形成装置５００の属するバージョンに基づいている。

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

実行手段５３０は、処理内容取得手段５１２が取得した要求項目に基づいて、対応する処理を実行する。実行手段５３０は、例えば、情報保持手段５４０に格納されている情報を取得して出力し、また情報保持手段５４０に格納されている情報を編集して置き換え、また要求項目に基づいて新たな情報を生成して情報保持手段５４０に格納させる。実行手段５３０は、情報保持手段５４０に格納されている情報に係る処理を行う他に、画像形成装置５００が有する画像形成機能、通信機能、ファクシミリ機能等に係る処理を行ってもよい。

情報保持手段５４０は、画像形成装置５００の状態に係る情報を保持し、また画像形成装置５００によって処理される画像の画像データ、画像形成装置５００を使用する操作者の情報等を保持する。通信手段５５０は、クライアントＰＣ６００との通信を行い、例えば、リクエストを受信し、レスポンスやメッセージを送信する。

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

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

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

レスポンス解析手段６１２は、画像形成装置５００から送信されるレスポンスを解析する。レスポンス解析手段６１２は、例えば、レスポンスがＸＭＬによって記述される場合に、ＸＭＬパーサとして構成される。ステータス取得手段６１３は、レスポンス解析手段６１２によって解析された応答項目に基づいて、画像形成装置５００のステータスを取得する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（リクエストを解析する処理の例）
図１３は、情報処理ロジック部３１０及びデータ処理部３１１において、リクエストが解析される処理の例のフロー図である。図１３の処理は、例えば、図１０のステップＳ１０４又は図１１のステップＳ２０４において、リクエスト解析手段５１１によって実行される。図１３のステップＳ４０１では、データ処理部３１１に対してリクエストが入力される。ステップＳ４０１に続いてステップＳ４０２に進み、リクエスト解析手段５１１が、リクエストを先頭から解析することにより、標準形式の部分の判定を行う。ここでは、標準形式がＡ形式とＢ形式との何れであるかを判定し、Ａ形式である場合には、ステップＳ４０３に進み、Ｂ形式である場合には、ステップＳ４０６に進む。

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

ステップＳ４０２に続くステップＳ４０３からステップＳ４０５では、Ａ形式で記述されている箇所について、リクエスト解析手段５１１が要求項目を取得し、処理内容取得手段５１２がその要求項目に対応する処理内容を取得する。この処理は、Ａ形式で記述されている箇所が全て処理されるまで繰り返される。なお、要求項目に対応する処理内容がない場合には、処理内容取得手段５１２は、その要求項目については何も処理を行わず、次の要求項目の処理へ進む。

これにより、リクエストの中に、画像形成装置５００が有する機能に対応していない要求項目がある場合でも、画像形成装置５００が有する機能に係る処理の要求項目のみを実行することができる。したがって、リクエストを生成するクライアント装置等が、複数のバージョンの異なる画像形成装置に対して、同一のリクエストを出力することができる。

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

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

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

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

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

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

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

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

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

ステップＳ５０９に続くステップＳ５１０からステップＳ５１２では、独自形式によって記述される応答項目のデータがなくなるまで、レスポンス生成手段５１３によってその応答項目を独自形式によって記述する処理が繰り返される。

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

（プロトコル、インタフェース、記述形式の例）
本発明の実施の形態では、クライアントＰＣと通信を行う画像形成装置のインタフェースが統一されていることが望ましい。これにより、クライアントＰＣは、画像形成装置毎にインタフェースを意識することなく、通信を行うことができる。同様に、プロトコル、及び、データの記述形式も統一されていることが望ましい。

以下は、本発明の実施の形態において、用いられるプロトコル、インタフェース、記述形式の例である。
・プロトコル：ＨＴＴＰ、ＡＰＰ
・インタフェース：ＨＴＴＰのＰＯＳＴ、ＧＥＴ、ＰＵＴ、ＤＥＬＥＴＥ。
・記述形式：ＡＰＰ、Ａｔｏｍ、その他の拡張形式。

例えば、上記以外では以下の組合せが考えられる。
（例１）
・プロトコル：ＨＴＴＰ、ＳＯＡＰ。
・インタフェース：独自形式。
・記述形式：ＳＯＡＰ、独自形式。
（例２）
・プロトコル：ＨＴＴＰ。
・インタフェース：独自形式。
・記述形式：ＸＭＬを独自に拡張したもの。

（リクエストとレスポンスの例）
図１５は、リクエストの例であって、画像形成装置５００が有する情報保持手段５４０に保持されるアドレス帳に新たなレコードを追加する要求の例である。

図１５のリクエストは、ＨＴＴＰリクエストヘッダー部Ｒ１と、要求項目を含む本体であるＲ２とを含む。本体Ｒ２の内、符号ｅが付された箇所の記述により、このリクエストが、Ａｔｏｍと、名前空間ａで定義される拡張形式とで、記述されていることが示されている。Ｒ３は拡張形式で記述されている箇所である。

Ｒ３には、名前「ｆｏｏ」に対応するメールアドレス、ファクシミリ番号等のレコードに係る情報が、それぞれ一の要求項目として含まれている。

図１６は、図１５のリクエストに対応して生成されるレスポンスの例である。図１６では、図１５のリクエストに基づいて処理された内容が含まれている。すなわち、アドレス帳に追加されたレコードの内容である、名前「ｆｏｏ」と、その名前に対応するメールアドレス、ファクシミリ番号等が、それぞれ一の応答項目として含まれている。

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

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

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

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

従来の画像形成システムによるリクエストの例（その１）。 従来の画像形成システムによるリクエストの例（その２）。 画像形成装置のインタフェースが同一であることを説明する図。 一のリクエストをそれぞれの装置が処理することを説明する図。 異なるバージョンのリクエストを処理する画像形成装置を説明する図。 異なるバージョンのレスポンスを処理するクライアントＰＣを説明する図。 本実施の形態による画像形成システムの構成の例を説明する図。 本実施の形態に係る画像形成装置であるＭＦＰの装置構成の例を説明する図。 本実施の形態による画像形成システムの機能構成の例を説明する図。 クライアントからのリクエストに基づく処理の例のシーケンス図。 クライアントからのリクエストに基づく処理とレスポンスを送信する処理の例のシーケンス図。 イベントに基づくメッセージが送信される場合の処理の例のシーケンス図。 リクエストが解析される処理の例のフロー図。 レスポンス又はメッセージが生成される処理の例のフロー図。 リクエストの例。 レスポンスの例（その１）。 レスポンスの例（その２）。 メッセージの例。

符号の説明

１、２、３、１０、１１、１２、１５、１６、１７、１８、１００ ＰＣ
２０、２５ ＬＰ
４、５、６、３１、３２、３３、３４、３５、３６ ＭＦＰ
４０、４５ 印刷機
５００ 画像形成装置
５１０ 情報処理ロジック部
５１１ リクエスト解析手段
５１２ 処理内容取得手段
５１３ レスポンス生成手段
５１４ メッセージ生成手段
５３０ 実行手段
５４０ 情報保持手段
５５０ 通信手段
６００ クライアントＰＣ
６１０ 情報処理ロジック部
６１１ リクエスト生成手段
６１２ レスポンス解析手段
６１３ ステータス取得手段

Claims (19)

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

Images