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

Description

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

従来、画像形成装置（ＭＦＰ）の機能を拡張した際に同時にＷｅｂサービスとして利用できるようにするには、新しく追加した機能に対応するＷＳＤＬ（Web Services Description Language）を作成しクライアントに対してそのＷＳＤＬを通じてＩ／Ｆを提供する必要があった。この場合、
１．クライアントが新機能に対応するＷＳＤＬを見つけ、
２．そのＷＳＤＬ内にあるＩ／Ｆに対応するクライアント側のコードを作成し、
３．新しいＷｅｂサービスで定義されている動作に対応
というステップが必要であった。これらそれぞれに対して、次に説明するような提案が成されている。

一つ目の「クライアントが新機能に対応するＷＳＤＬを見つける」については、ＷＳＤＬを管理する外部サーバを用意し、予めそのサーバに対してＷＳＤＬを登録しておく、という方法がある。この外部サーバは、ＵＤＤＩと呼ばれる一般的なものである。また、特開２００５−０５５９８３号公報（特許文献１）には、サービス管理装置を別で用意して解決する提案もなされている。

二つ目の「ＷＳＤＬ内にあるＩ／Ｆに対応するクライアント側のコードを作成」については、様々な手法が提案されている。特開２００４−２７２３１７号公報（特許文献２）には、サーバ側のＩ／Ｆに変更が入っていた場合にクライアント側で動的に対応する提案がなされている。これは、変更されているＩ／Ｆにアクセスした際のエラーをクライアント側で検出し、そのエラーがＩ／Ｆ変更によるものであれば、エラー回避プログラムを動作させる、というものである。また、特開２００５−０５５９８３号公報（特許文献１）には、Ｗｅｂサービス管理用の仲介装置を用意し、サービス提供側は予めこちらに登録をしておき、利用者はこの仲介装置に対してアクセスをすることで提供側のＩ／Ｆとの差分を吸収しようとするものである。

三つ目の「新しいＷｅｂサービスで定義されている動作に対応」については、特開２００６−０７２９１０号公報（特許文献３）には、予めＷｅｂサービスを利用する動作を定義したシナリオを外部サーバに登録しておき、Ｗｅｂサービス利用時にはそのサーバからシナリオを取得してアクセスする、といった手法が提案されている。
特開２００５−０５５９８３号公報 特開２００４−２７２３１７号公報 特開２００６−０７２９１０号公報

しかしながら、上記特許文献１の技術では、ＷＳＤＬを管理する外部の何らかの装置が必要であり、クライアントが新しい機能をＷｅｂサービスとして利用するにはそこからＷＳＤＬを取得する必要があった。また、上記特許文献２の技術では、予めエラー検出やエラー回避用のプログラムを組み込んでおく必要があり、またクライアント側で対応する際には、コードのコンパイル処理なども必要であった。また、特許文献３の技術では、予め外部サーバを用意して、そちらにシナリオを登録しておく必要がある。

本発明は、上記の点に鑑みて、これらの問題を解消するために発明されたものであり、I／Fを統一してＷｅｂサービスの機能拡張を動的に行うことができる画像形成装置、情報処理方法、及び、画像形成システムを提供することを目的としている。

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

本発明の一局面の画像形成装置は、クライアント装置からの第一の記述形式によるリクエストを受信する通信手段と、該リクエストに含まれる要求項目に対応する処理内容のデータ形式がある場合は、前記要求項目を前記データ形式に変換し、前記データ形式がない場合は、前記要求項目を第二の記述形式に変換するデータ処理手段とを備える画像形成装置であってリクエストに含まれる要求項目に対し、前記データ処理手段により変換された形式で処理を実行する機能実現手段であって、画像形成装置に備えられた該機能実現手段の識別情報とロジック名とを関連付けて記憶手段に記憶して管理する管理手段と、複数の前記機能実現手段に共通して必要な処理を定義する共通処理手段と、を備え、前記管理手段は、新たに受信されたリクエストに含まれる要求項目に対する前記機能実現手段の識別情報が、前記記憶手段に記憶されている場合、前記識別情報と前記ロジック名とに基づいて、前記機能実現手段に処理を行なわせるためのロジック部を生成し、前記共通処理手段は、前記管理手段により生成されたロジック部に対し、前記リクエストに含まれる要求項目の処理依頼を行う。

また、本発明の他の局面の情報処理方法は、クライアント装置からの第一の記述形式によるリクエストを受信する通信手段と、該リクエストに含まれる要求項目に対応する処理内容のデータ形式がある場合は、前記要求項目を前記データ形式に変換し、前記データ形式がない場合は、前記要求項目を第二の記述形式に変換するデータ処理手段と、リクエストに含まれる要求項目に対し、前記データ処理手段により変換された形式で処理を実行する機能実現手段であって、画像形成装置に備えられた該機能実現手段の識別情報とロジック名とを関連付けて記憶手段に記憶して管理する管理手段と、複数の前記機能実現手段に共通して必要な処理を定義する共通処理手段とを備える画像形成装置における情報処理方法であって、前記管理手段が、新たに受信されたリクエストに含まれる要求項目に対する前記機能実現手段の識別情報が、前記記憶手段に記憶されている場合、前記識別情報と前記ロジック名とに基づいて、前記機能実現手段に処理を行わせるためのロジック部を生成する生成ステップと、前記共通処理手段が、前記生成ステップにより生成されたロジック部に対し、前記リクエストに含まれる要求項目の処理依頼を行う依頼ステップと、を有する。

本発明の他の局面の画像形成システムは、クライアント装置と画像形成装置が接続された画像形成システムであって、前記クライアント装置は、前記画像形成装置に対する要求項目を有するリクエストを第一の記述形式により生成するリクエスト生成手段と、前記リクエストを送信する第一の通信手段と、を備え、前記画像形成装置は、クライアント装置からの第一の記述形式によるリクエストを受信する第二の通信手段と、該リクエストに含まれる要求項目に対応する処理内容のデータ形式がある場合は、前記要求項目を前記データ形式に変換し、前記データ形式がない場合は、前記要求項目を第二の記述形式に変換するデータ処理手段とを備える画像形成装置であって、リクエストに含まれる要求項目に対し、前記データ処理手段により変換された形式で処理を実行する機能実現手段であって、画像形成装置に備えられた該機能実現手段の識別情報とロジック名とを関連付けて記憶手段に記憶して管理する管理手段と、複数の前記機能実現手段に共通して必要な処理を定義する共通処理手段とを備え、前記管理手段は、新たに受信されたリクエストに含まれる要求項目に対する前記機能実現手段の識別情報が、前記記憶手段に記憶されている場合、前記識別情報と前記ロジック名とに基づいて、前記機能実現手段に処理を行わせるためのロジック部を生成し、前記共通処理手段は、前記管理手段により生成されたロジック部に対し、前記リクエストに含まれる要求項目の処理依頼を行う。

I／Fを統一してＷｅｂサービスの機能拡張を動的に行うことができる画像形成装置、情報処理方法、及び、画像形成システムを提供することが可能になる。

以下、本発明の実施の形態を図面に基づき説明する。

＜画像形成システムの概略構成＞
図１は、本実施例による画像形成システムの概略構成の例を示す図である。図５の画像形成システムは、ＰＣ（パーソナルコンピュータ、以下、クライアントＰＣともいう）１、ＰＣ２、ＰＣ３・・・と、ＭＦＰ（画像形成装置）４、ＭＦＰ５、ＭＦＰ６・・・とが、ＬＡＮに接続されている。これにより、各ＰＣが、それぞれのＭＦＰに対してリクエストを出力し、また各ＭＦＰからのレスポンスを受信する。

＜画像形成システムの概要＞
図２は、実施例１に係る画像形成システムの概要を示す図である。本発明に係る画像形成システムでは、Ｉ／Ｆ部分を統一しているため、従来のＷＳＤＬを利用してその都度Ｉ／Ｆを記載し、クライアントＰＣ２０１がそれを利用する、といった課題がなくなる。Ｉ／Ｆを統一しているといってもアクセスする情報の識別子は指定する必要があるが、クライアントＰＣ２０１が変えないといけないのはその識別子のみであり、Ｗｅｂサービスを利用する際のコードは変更する必要がない。Ｉ／Ｆを統一させたまま、Ｗｅｂサービスの機能拡張を動的に行うことができるフレームワークについて後ほど説明する。

また、本発明に係る画像形成システムでは、クライアントＰＣ２０１とサーバ（ＭＦＰ）２０２間のやり取りは１回で済むようにリクエスト又はレスポンスの中に、機器の設定に必要なパラメータなど全てのデータを記述するようにしており、外部サーバに登録されたある手順に従って実行しないといけないということがなくなる。また、データの内容については後述するとおり、機能を拡張することが容易な作りになっている。このため、クライアントＰＣ２０１側では、機能拡張における修正を必ずしもする必要がなく、最低限の動作を行うことができるようになる。この点については、後ほど説明する。

＜画像形成システムの詳細な構成＞
図３は、画像形成システムの詳細な構成を示す図である。図３に示すようにＭＦＰ３００とクライアントＰＣ３５０とがＬＡＮを介して接続されているが、直接接続されてもよい。まず、ＭＦＰ３００について説明する。

図３に示すＭＦＰ３００は、例えば、ネットワークインタフェース（以下、ネットワークＩ／Ｆという）３０１、Ｗｅｂサービス・フレームワーク３０２、情報処理ロジック部３０６、情報アクセス部３０７、情報保持部３０８、新機能３０９を含む。

ネットワークＩ／Ｆ３０１は、画像形成装置３００とＬＡＮとを接続するためのインタフェースである。Ｗｅｂサービス・フレームワーク３０２は、通信クライアント部３０３と通信サーバ部３０４とデータ処理部３０５とを含む。

通信クライアント部３０３と通信サーバ部３０４とは、クライアントＰＣ３５０に対して通信を行う手段である。データ処理部３０５は、クライアントＰＣ３５０等からのリクエストを解析し、また、クライアントＰＣ３５０へのレスポンスを生成する。例えば、データ処理部３０５は、ＸＭＬで記述されるリクエストをパースし、またＸＭＬで記述されるレスポンスを生成する。データ処理部３０５の詳細については後述する。

情報処理ロジック部３０６は、機器内で完結するロジックを保持し、機器内で完結するリクエストを解析したり、レスポンスを生成したりする。情報アクセス部３０７は、情報処理ロジック部３０７によって解析されたリクエストに含まれる要求項目に基づいて、情報保持部３０８に保持されている情報を取得し、またその情報を編集して置き換え、または情報を生成して情報保持部３０８に格納させる。情報保持部３０７は、ＭＦＰ３００の状態や操作者毎の識別情報、画像データ等を格納する。

新機能３０９は、新機能ロジック部３１０、新機能拡張データ部３１１、新機能管理部３１２、新機能処理部３１３を含む。新機能ロジック部３１０は、Ｗｅｂサービスがリクエストされる度に生成され、リクエストに含まれる要求項目のデータを解析する必要があれば、データ処理部３０５に解析依頼を行ったり、解析が不要であれば、Ｗｅｂサービスの処理依頼を新機能処理部３１３に行ったりする。

新機能拡張データ部３１１は、新機能３０９により拡張されたデータを保持する。新機能管理部３１２は、新機能３０９がＭＦＰ３００に追加されたときに、後述するロジック管理部１２０３に対し、新機能３０９の識別子であるＵＲＩとロジック名とを出力する。ここで、ロジック名は、ＪＡＶＡ（登録商標）のクラス名などである。新機能処理部３１３は、新機能３０９の処理を行い、後述する機能実現手段４０５に相当する。

次に、クライアントＰＣ３５０側について説明する。クライアントＰＣ３５０は、例えば、ネットワークＩ／Ｆ３５１、Ｗｅｂサービス・フレームワーク３５２、情報アクセス部３５６、ビュー生成部３５７、ユーザーインタフェース（以下、ＵＩという）３５８を含む。ここで、ネットワークＩ／Ｆ３５１、Ｗｅｂサービス・フレームワーク３５２、情報アクセス部３５６は、ＭＦＰ３００と同様の処理を行うので、説明を省略する。

ビュー生成手段３５７は、例えば、ＭＦＰからのレスポンスを表示画面に表示するための表示画面データを生成する。ＵＩ３５８は、クライアントＰＣ３５０を操作するためのユーザーインタフェースである。次に、Ｉ／Ｆを統一するためのデータ処理部３０５、３５５について説明する。

＜Ｉ／Ｆ統一について＞
本発明では、Ｉ／Ｆを統一していることが前提となるが、その役割を担うのがデータ処理部３０５、３５５である。以下、データ処理部３０５、３５５を含むＭＦＰとＰＣの主要機能について説明する。

図４は、Ｉ／Ｆ統一に係るＭＦＰ４００とクライアントＰＣ４５０との主要機能構成の例を示す図である。図４に示すように、ＭＦＰ４００は、例えば、データ処理部３０５、機能実現手段４０５、一覧管理手段４０６、データ形式保持手段４０７、及び、通信手段４０４を有する。データ処理部３０５は、クライアントＰＣ４５０から送信されるリクエストを解析してその中に含まれる要求項目を取得する。データ処理部３０５は、また、要求項目に対応するレスポンスを生成する。

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

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

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

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

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

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

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

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

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

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

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

一覧管理手段４０６は、ＭＦＰ４００が有する機能実現手段４０５の一覧を保持し管理する。新たに機能実現手段４０５が追加された場合には、一覧管理手段４０６によって管理される一覧が更新される。

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

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

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

クライアントＰＣ４５０は、例えば、データ処理部３５５、通信手段４５４、機能実現手段４５５、一覧管理手段４５６、データ形式保持手段４５７を有する。データ処理部３５５は、ＭＦＰ４００に対して送信するリクエストを生成し、また、ＭＦＰ４００から送信されるレスポンスを解析する。これにより、ＭＦＰ４００のステータスを取得することができる。なお、ステータスとは、ＭＦＰ４００の状態の他に、ＭＦＰ４００が保持する情報でもよい。

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

レスポンス解析手段４５２は、ＭＦＰ４００から送信されるレスポンスを解析する。また、レスポンス解析手段４５２は、例えば、レスポンスがＸＭＬによって記述される場合に、ＸＭＬパーサとして構成される。

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

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

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

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

＜リクエストを解析する処理の例＞
図５は、データ処理部３０５において、リクエストが解析される処理の例を示すフローチャートである。図５の処理は、例えば、リクエスト解析手段４０１によって実行される。図５のステップＳ１０１では、データ処理部３０５に対してリクエストが入力される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＜レスポンスを生成する処理の例＞
図８は、データ処理部３０５において、レスポンスが生成される処理の例を示すフローチャートである。図８の処理は、例えば、レスポンス生成手段４０３によって実行される。

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

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

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

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

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

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

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

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

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

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

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

以上より、Ｉ／Ｆを統一させることでＷｅｂサービスの機能拡張を動的に行うことができる。

＜Ｗｅｂサービス・フレームワークの内部構成＞
図１２は、Ｗｅｂサービス・フレームワークの内部構成を示す図である。図３と同様の構成要素には、同じ符号を付し、その説明を省略する。通信サーバ部３０４は、共通Ｉ／Ｆ１２０１、共通処理部１２０２、ロジック管理部１２０３を含む。

共通Ｉ／Ｆ１２０１は、共通して用いられる複数のＩ／Ｆが規定されているＩ／Ｆ部である。共通処理部１２０２は、共通Ｉ／Ｆの各Ｉ／Ｆに対応する共通の処理が規定されている処理部である。このとき、フレームワークの利用者（ロジック部）は、共通処理部１２０２で規定される処理の中から、自らの機能を満たす上で必要な処理（Ｉ／Ｆ）のみ実装する。

ロジック管理部１２０３は、Ｗｅｂサービスで用いられる各機能の識別子であるＵＲＩ（Uniform Resource Identifier）とロジック名とを関連付けて記憶手段に記憶して管理する。ここで、ロジック名とは例えば、ＪＡＶＡ（登録商標）のクラス名などを言う。また、リクエスト内に、管理する識別子が含まれている場合、この識別子とクラス名とに基づいて新機能ロジック部３１０を生成する。

ここで、図１３は、共通Ｉ／Ｆ１２０１と共通処理部１２０２との例を示す図である。図１３に示すように、共通Ｉ／Ｆ１２０１にはＡ〜ＤのＩ／Ｆが規定され、共通処理部１２０２には、Ａ〜ＤのＩ／Ｆに対応する処理が規定されている。このＡ〜Ｄは、例えば、ＧＥＴやＤＥＬＥＴＥなどを示す。

また、図１３に示す例によると、情報処理ロジック部３０６では、共通処理部１２０２内にあるＡ〜Ｄ全ての処理を必要とし、新機能ロジック部３１０では、Ｃ、Ｄの処理のみで機能を満たすことができる。このように、本発明では、共通Ｉ／Ｆ（Ａ〜Ｄ）に対して共通の処理をフレームワーク内で規定する。

＜ロジック管理部の内部構成＞
図１４は、ロジック管理部の内部構成を示す図である。図１４に示すように、ロジック管理部１２０３は、判定手段１４０１、記憶手段１４０２、生成手段１４０３を含む。判定手段１４０１は、リクエストに含まれる識別子（ＵＲＩ）を取得し、取得した識別子が、記憶手段１４０２に記憶されている識別子か否かを判定する。

記憶手段１４０２は、Ｗｅｂサービスの機能の識別子（ＵＲＩ）とロジック名とを関連付けて記憶する。図１５は、記憶手段１４０２に格納される管理テーブルの例を示す図である。図１５に示すように、識別子１とロジック名１とが関連付けられて記憶されている。

このとき、管理テーブルは、従来機能と新機能とを区別することなく、取得した識別子とロジック名との情報だけを格納する。これより、新機能、従来機能に関係なく、機能毎の追加、削除を容易に行うことができる。

図１４に戻り、生成手段１４０３は、記憶手段１４０２に記憶される管理テーブルの識別子とロジック名とに基づいて、新機能ロジック部３１０を生成する。

＜新機能の追加処理＞
図１６は、新機能を追加したときの管理テーブルへの登録処理を示すシーケンス図である。ステップ３０１では、追加した新機能３０９に含まれる新機能管理部３１２が、ロジック管理部１２０３に対し、新機能の識別子とロジック名とを出力する。

ステップ３０１に続いてステップ３０２に進み、ロジック管理部１２０３は、新機能管理部３１２より識別子とロジック名とを取得すると、これらを関連付けて管理テーブルに登録する（格納する）。これより、追加された新機能を用いるリクエストがきたときに、追加された新機能を用いることができるようになる。

＜新機能の削除処理＞
図１７は、新機能を削除したときの管理テーブルへの削除処理を示すシーケンス図である。ステップ３０３では、追加した新機能３０９に含まれる新機能管理部３１２が、ロジック管理部１２０３に対し、追加した新機能を削除するため、新機能の識別子を出力する。

ステップ３０３に続いてステップ３０４に進み、ロジック管理部１２０３は、新機能管理部３１２より識別子を取得すると、取得した識別子とこの識別子に対応するロジック名とを削除する。これより、追加された新機能を処理する必要がなくなったときにこの新機能を削除することができるようになる。

また、図１６と図１７とに示すように、新機能の追加、削除処理はＭＦＰが動作中でも処理することが可能であり、これらの機能によりいつでも機能単位での抜き差しが可能となる。

＜クライアントＰＣからの参照要求に対する処理＞
図１８は、クライアントＰＣからの参照要求に対する処理を示すシーケンス図である。ステップ４０１では、利用者（ユーザー）が、クライアントＰＣ３５０を用いてＭＦＰ３００に参照を要求項目とするリクエストを送信する。リクエストはｈｔｔｐリクエストとして送信されてもよい。また、リクエストは、ＸＭＬ等の記述言語による第一の記述形式によって記述される。

ステップ４０１に続いてステップ４０２に進み、通信サーバ部３０４は、ロジック管理部１２０３に対し、ステップ４０１により受信したリクエストを処理する依頼を出力する。ステップ４０２に続いてステップ４０３に進み、ロジック管理部１２０３は、共通処理部１２０２に対し、共通処理の依頼を行う。

ステップ４０３に続いてステップ４０４に進み、ロジック管理部１２０３は、リクエストに含まれる識別子を取得し、取得した識別子が、自身が管理する管理テーブルに格納されているか否かの判定を行なう。次に、ロジック管理部１２０３は、取得した識別子が管理テーブルに格納されている場合は、管理テーブルに格納される識別子とロジック名とに基づいて新機能ロジック部３１０を生成する。

ステップ４０４に続いてステップ４０５に進み、共通処理部１２０２は、生成された新機能ロジック部３１０に対し、リクエストに含まれる要求項目の処理依頼を行う。ステップ４０５に続いてステップ４０６に進み、新機能ロジック部３１０は、リクエストに含まれる要求項目における処理対象のデータがあるか否かを判断する。かかる判断については後述する。

また、新機能ロジック部３１０は、新機能処理部３１３に対して処理が要求されている場合、新機能処理部３１３に対応するデータ形式に変換して処理を依頼する。

ステップ４０６に続いてステップ４０７に進み、新機能ロジック部３１０は、新機能処理部３１３から参照して取得したデータに基づいて新機能拡張データ部３１２を生成する。新機能拡張データ部３１２では、新機能の拡張データが保持される。

ステップ４０７に続いてステップ４０８に進み、新機能ロジック部３１０は、処理が終了した旨の応答項目を取得し、共通処理部１２０２に対し、応答項目を含むレスポンスを生成するよう依頼する。応答項目は、所定のデータ形式でもよく、また、第二の記述形式によるものでもよい。なお、第二の記述形式とは、例えば、レスポンスがＸＭＬによって、記述される場合に、その応答項目の属する名前空間、変数名又はタグ名、及び、値を含むとよい。

ステップ４０８に続いてステップ４０９に進み、共通処理部１２０２は、レスポンスに応答項目が含まれる場合は、データ処理部１２０２に対し、レスポンスの生成処理を依頼する。

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

ステップ４１０に続いてステップ４１１に進み、ロジック管理部１２０３は、通信サーバ部３０４に対し、レスポンスとそのレスポンスを送信する依頼を出力する。ステップ４１１に続いてステップ４１２に進み、通信サーバ部３０４は、クライアントＰＣ３５０にレスポンスを送信する。

＜クライアントＰＣからのデータ作成・変更要求に対する処理＞
次に、クライアントからデータ作成・変更要求依頼が来た場合について説明する。データ作成・要求は、参照要求と違って、要求項目における処理対象データがあるということが異なる。

図１９は、クライアントからのデータ作成・変更要求に対する処理を示すシーケンス図である。図１８と同様の処理を行うものについては、図１８と同じ符号を付し、その説明を省略する。

ステップ５０１では、利用者が、クライアントＰＣ３５０を用いてＭＦＰ３００に作成・変更を要求項目とするリクエストを送信する。ここで、リクエストには要求項目における処理対象のデータが含まれている。

共通処理部１２０２から処理依頼を受けた新機能ロジック部３１０は、ステップ５０２において、データ処理部３０５に対し、処理対象データの解析依頼を行う。ステップ５０２に続いてステップ５０３に進み、データ処理部３０５が、取得したデータを解析して、拡張すべきデータがある場合、新機能拡張データ部３１２を生成して拡張データを保持させる。

ステップ５０３に続いてステップ５０４に進み、新機能ロジック部３１０が、新機能処理部３１３に対し、要求項目を所定のデータ形式に変換し、変換した処理内容を実行する要求が出力される。

ステップ５０４に続いてステップ５０５に進み、新機能処理部３１３は、取得した処理内容に従って、処理を実行する。このとき、新機能処理部３１３は、新機能拡張データ部３１２のデータを参照して処理内容を実行する。

ステップ５０５に続いてステップ５０６に進み、新機能処理部３１３は、処理が終了した場合に新機能ロジック部３１０に対し、処理が終了したことの通知を出力する。ステップ５０６に続いてステップ５０７に進み、新機能ロジック部３１０は、共通処理部１２０２に対し、処理が終了したことの通知を出力する。

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

＜クライアントＰＣの処理＞
次に、クライアントＰＣ３５０がＭＦＰ３００にリクエストを送信し、ＭＦＰ３００からレスポンスを受信したときの一連の処理について説明する。図２０は、クライアントＰＣの処理を示すシーケンス図である。

ステップ６０１では、ＵＩ３５８が、ユーザーにより指示された作成、参照、変更、又は削除の要求項目を情報アクセス部３５６に出力する。ステップ６０１に続いてステップ６０２に進み、情報アクセス部３５６は、通信クライアント部３５３に対し、ユーザーにより指示された要求をＭＦＰ３００に送信するよう通信要求を出力する。

ステップ６０２に続いてステップ６０３に進み、通信クライアント部３５３は、要求項目をリクエストとしてＭＦＰ３００に送信する。このとき、リクエストは、要求項目を処理するのに用いる機能実現手段の識別子を含む。

ステップ６０３に続いてステップ６０４に進み、ＭＦＰ３００は、通信クライアント部３５３に対し、リクエストに対応するレスポンスを送信する。ステップ６０４に続いてステップ６０５に進み、通信クライアント部３５３は、取得したレスポンスをデータ処理部３５５に出力する。

このとき、データ処理部３５３では、前述したとおり、第一の記述形式で記述されたレスポンスを取得し、データの解析を行い、応答項目を取得する。

ステップ６０５に続いてステップ６０６に進み、通信クライアント部３５３は、解析された応答項目を情報アクセス部３５６に出力する。ステップ６０６に続いてステップ６０７に進み、情報アクセス部３５６は、ビュー生成部３５７に対し、応答項目に基づいて表示画面を生成するよう依頼する。次に、表示画面の生成依頼を受けたビュー生成部３５７の処理について説明する。

＜ビュー生成部の処理＞
図２１は、クライアントＰＣ側の表示画面データ生成処理を示すフローチャートである。ステップ７０１からステップ７０９まで応答項目のデータがなくなるまで、ビュー生成手段３５７によって、表示画面データを生成する処理が繰り返される。

ステップ７０２では、応答項目におけるデータが既知のデータ形式か否か判定される。ステップ７０２により既知のデータ形式であると判定された場合、ステップ７０３からステップ７０５までを繰り返すことで、既知のデータに対応した表示画面データを生成する。

ステップ７０２により新規のデータ形式であると判定された場合、ステップ７０６からステップ７０８までを繰り返すことで、新規のデータに対し、所定の規則に従って表示画面データを生成する。ここで、新規のデータ形式とは、ＭＦＰ３００側で新しく拡張された機能におけるデータのデータ形式をいう。所定の規則とは、既知のデータに対して表示画面データを生成する規則などであって、クライアントＰＣ側で表示画面データを生成することができる規則のことである。

これより、ビュー生成部３５７に対して新規のデータが入力されたとしても、所定のデータ形式（第一の記述形式）で記述されているため、新規データを既存の表示形式に従って表示画面データを生成することができる。

＜アドレス帳を新機能として追加した場合の処理＞
次に、本発明を適用した具体例について説明する。ここでは、従来ＭＦＰの機能になかった「アドレス帳機能」を新機能として追加した場合の処理について説明する。図２２は、追加したアドレス帳機能の例を示す図である。

図２２に示すように、アドレス帳ロジック部２１０１は、アドレス帳の機能として、フレームワークで定義されているＩ／Ｆの全て（ＧＥＴ：参照、ＰＵＴ：変更、ＰＯＳＴ：作成、ＤＥＬＥＴＥ：削除）に対応するよう生成されている。

アドレス帳拡張データ部２１０２は、拡張されたデータ部分を所定の記述形式で保持する。図２３は、アドレス帳拡張データ部２１０２が保持するデータの一例を示す図である。図２３の例では、アドレス帳拡張データ部２１０２には、ＸＭＬの記述に対応するようにデータが保持されている。

図２２に戻り、アドレス帳管理部２１０３は、このアドレス帳機能がＭＦＰに追加されたとき、アドレス帳機能を識別する識別子とロジック名とをロジック管理部１２０３に出力する。ここで、識別子の例としては「/addressbook」などがある。アドレス帳処理部２１０４は、アドレス帳ロジック部２１０１で規定された処理を実行する。

ここで、図２４は、アドレス帳の拡張データが表示画面に表示された例を示す図である。図２４は、図２３に示す拡張データが、表示画面に表示された例を示している。

＜追加されたアドレス帳を参照するときのＭＦＰ側の処理＞
図２５は、クライアントからの追加されたアドレス帳の参照要求に対する処理を示すシーケンス図である。ステップ８０１では、利用者（ユーザー）が、クライアントＰＣ３５０を用いてＭＦＰ３００に、アドレス帳の参照を要求項目とするリクエストを送信する。リクエストはｈｔｔｐリクエストとして送信されてもよく、ここでは、ＧＥＴ（http://sample.com/ws/addressbook）を通信サーバ３０４に出力する。

ステップ８０１に続いてステップ８０２に進み、通信サーバ部３０４は、ロジック管理部１２０３に対し、ステップ１０１で受信されたリクエストを処理する依頼を出力する。ステップ８０２に続いてステップ８０３に進み、ロジック管理部１２０３は、共通処理部１２０２に対し、共通処理の依頼を行う。

ステップ８０３に続いてステップ８０４に進み、ロジック管理部１２０３は、リクエストに含まれる識別子（/addressbook）を取得し、取得した識別子が、自身が管理する管理テーブルに格納されているか否かの判定を行なう。次に、ロジック管理部１２０３は、取得した識別子が管理テーブルに格納されている場合は、管理テーブルに格納される識別子とロジック名とに基づいてアドレス帳ロジック部２１０１を生成する。

ステップ８０４に続いてステップ８０５に進み、共通処理部１２０２は、生成されたアドレス帳ロジック部２１０１に対し、リクエストに含まれる要求項目（参照）の処理依頼を行う。ステップ８０５に続いてステップ８０６に進み、アドレス帳ロジック部２１０１は、アドレス帳処理部２１０４に対し、リクエストに含まれる要求項目（参照）の処理を依頼する。

ステップ８０６に続いてステップ８０７に進み、アドレス帳ロジック部２１０１は、アドレス帳処理部２１０４から参照して取得したデータから、アドレス帳拡張データ部２１０３を生成する。アドレス帳拡張データ部２１０２では、新機能（アドレス帳機能）の拡張データが保持される。

ステップ８０７に続いてステップ８０８に進み、アドレス帳ロジック部２１０１は、処理が終了した旨の応答項目を取得し、共通処理部１２０２に対し、応答項目を含むレスポンスを生成するよう依頼する。応答項目は、所定のデータ形式でもよく、また、第二の記述形式によるものでもよい。なお、第二の記述形式とは、例えば、レスポンスがＸＭＬによって、記述される場合に、その応答項目の属する名前空間、変数名又はタグ名、及び、値を含むとよい。

ステップ８０８に続いてステップ８０９に進み、共通処理部１２０２は、レスポンスに応答項目が含まれる場合は、データ処理部１２０２に対し、レスポンスの生成処理を依頼する。

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

ステップ８１０に続いてステップ８１１に進み、ロジック管理部１２０３は、通信サーバ部３０４に対し、レスポンスとそのレスポンスを送信する依頼が出力される。ステップ４１１に続いてステップ４１２に進み、通信サーバ部３０４は、クライアントＰＣ３５０にレスポンスを送信する。

これより、追加されたアドレス帳機能について、追加されたアドレス帳に対応するＷＳＤＬを取得する必要なく、また、特別なプログラムを生成する必要なく、クライアントＰＣ３５０側は識別子を変更するのみで、ＭＦＰの新機能に対して処理できるようになる。

＜追加されたアドレス帳に変更要求を出力するクライアント側の処理＞
図２６は、ＭＦＰに追加されたアドレス帳に変更要求を出力するクライアントＰＣ側の処理を示すシーケンス図である。

ステップ９０１では、ＵＩ３５８が、ユーザーにより指示された変更の要求項目を情報アクセス部３５６に出力する。ステップ９０１に続いてステップ９０２に進み、情報アクセス部３５６は、通信クライアント部３５３に対し、ユーザーにより指示された変更要求をＭＦＰ３００に送信するよう通信要求を出力する。

ステップ９０２に続いてステップ９０３に進み、通信クライアント部３５３は、要求項目をリクエストとしてＭＦＰ３００に送信する。このとき、リクエストは、ｈｔｔｐリクエストとして表現した場合、ＨＴＴＰのＰＵＴ（http://sample.com/ws/addressbook/hoge）がＭＦＰ３００に送信される。

ステップ９０３に続いてステップ９０４に進み、ＭＦＰ３００は、通信クライアント部３５３に対し、リクエストに対応するレスポンスを送信する。ステップ９０４に続いてステップ９０５に進み、通信クライアント部３５３は、データ処理部３５５に対し、レスポンスのデータを解析するよう依頼する。

このとき、データ処理部３５５では、前述したとおり、第一の記述形式で記述されたレスポンスを取得し、データの解析を行い、応答項目を取得する。

ステップ９０５に続いてステップ９０６に進み、通信クライアント部３５３は、解析された応答項目を情報アクセス部３５６に出力する。ステップ９０６に続いてステップ９０７に進み、情報アクセス部３５６は、ビュー生成部３５７に対し、応答項目に基づいて表示画面データを生成するよう依頼する。

ここで、図２７は、アドレス帳に変更要求を出力した際のレスポンスの例を示す図である。つまり、ステップ９０４において、ＭＦＰ３００から、図２７に示すようなレスポンスが送信されたとする。

次にステップ９０５に続いて、データ処理部３５５が図２７に示すレスポンスの解析を行う。ここで、図２７に示す符号ｘの部分については、ＭＦＰ３００側で新たに追加された拡張データ（新規データ）であるため、クライアント側はこのデータを知らない。

図２８は、新規データに対して表示画面データを生成する例を示す図である。図２８（ａ）は、クライアントＰＣ側のデータ処理を示す図である。図２８（ａ）に示すように、クライアントＰＣ３５０が知らない符号ｘの新規なデータ部分に対して、クライアントＰＣ３５０で処理できるように、名前空間、要素名、値に記述形式が変換される。

次にステップ９０７に続いて、ビュー生成手段３５７は、取得した応答項目に対して表示画面データを生成する。このとき、図２７に示す符号ｘの新規なデータを図２８（ａ）に示すように変換することで、クライアントＰＣ側で決まった規則に従って処理を行い、新規なデータを表示画面に表示することが可能となる。

図２８（ｂ）は、新規なデータが表示画面に表示された例を示す図である。図２４と図２８（ｂ）とを比較すればわかるように、同じデータに対して異なる表示画面データが生成される。本来は、図２４に示す画面が表示されるところ、クライアントＰＣ側では、新規なデータに対して、クライアントＰＣ３５０の表示画面データ生成に係る規則に従って表示画面データを生成した結果、図２８（ｂ）に示すような表示画面が表示される。

これより、クライアントＰＣ側では、特にデータを知らなくても規則的に表示画面データの生成処理を行うことができるようになっている。また、表示画面データの生成処理は一例であり、データの中身を知らなくても処理が実行できるのであれば、特にクライアント側で修正を加える必要なく対応することが可能である。

また、実施例１では、クライアントＰＣとサーバ（ＭＦＰ等）間のやりとりは１回で済むようにリクエスト又はレスポンスの中に、機器の設定に必要なパラメータ等を全て記述していることにより、表示画面データの表示程度であれば１回のやりとりで処理を済ませることができる。

＜コンピュータの構成＞
図２９は、実施例１のＭＦＰ又はクライアントＰＣを実現するコンピュータの構成図である。図２９のコンピュータは、主処理部２８００、入力デバイス２８０４、表示装置２８０５、プリンタ２８０６、スキャナ２８０７、及び、ＨＤＤ２８０８を有する。

主処理部２８００は、コンピュータの機能を実現する主たる部分であり、ＣＰＵ２８０１、ＲＯＭ２８０２、及び、ＲＡＭ２８０３を有する。ＣＰＵ２８０１は、コンピュータプログラムをＲＯＭ２８０２等から読み出し、ＲＡＭ２８０３に展開することにより、実施例１の処理に係るコンピュータプログラムを実行する。ＲＯＭ２８０２は不揮発性のメモリであり、ＣＰＵ２８０１によって実行されるプログラム、及び、ＭＦＰ又はクライアントＰＣの制御に必要なパラメータ等を保持する。ＲＡＭ２８０３は、ＣＰＵ２８０１が処理を行う際の、ワークメモリである。

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

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

以上、本発明の実施例について詳述したが、本発明は係る特定の実施例に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、上記以外にも種々の変形・変更が可能である。また、図４に示すように、ＭＦＰとクライアントＰＣとを接続して画像形成システムとしても、本願発明の目的を達成することができる。

本実施例による画像形成システムの概略構成の例を示す図。 実施例１に係る画像形成システムの概要を示す図。 実施例１に係る画像形成システムの詳細な構成を示す図。 実施例１に係るＭＦＰとＰＣとの主要機能構成の例を示す図。 リクエストが解析される処理の例を示すフローチャート。 リクエストの例を示す図。 要求項目を第二の記述形式に変換する例を示す図。 レスポンスが生成される処理の例を示すフローチャート。 第二の記述形式による応答項目から第一の記述形式によるレスポンスが生成されることを示す図。 レスポンスの例を示す図。 レスポンスの例を示す図。 Ｗｅｂサービス・フレームワークの内部構成を示す図。 共通Ｉ／Ｆと共通処理部との例を示す図。 ロジック管理部の内部構成を示す図。 記憶手段に格納される管理テーブルの例を示す図。 新機能を追加したときの管理テーブルへの登録処理を示すシーケンス図。 新機能を削除したときの管理テーブルへの削除処理を示すシーケンス図。 クライアントからの参照要求に対する処理を示すシーケンス図。 クライアントからのデータ作成・変更要求に対する処理を示すシーケンス図。 クライアントＰＣの処理を示すシーケンス図。 クライアントＰＣ側の表示画面生成処理を示すフローチャート。 追加したアドレス帳機能の例を示す図。 アドレス帳拡張データ部が保持するデータの一例を示す図。 アドレス帳の拡張データが表示画面に表示された例を示す図。 クライアントからの追加されたアドレス帳の参照要求に対する処理を示すシーケンス図。 ＭＦＰに追加されたアドレス帳に変更要求を出力するクライアントＰＣ側の処理を示すシーケンス図。 アドレス帳に変更要求を出力した際のレスポンスの例を示す図。 新規データに対して表示画面データを生成する例を示す図。 実施例１のＭＦＰ又はクライアントＰＣを実現するコンピュータの構成図。

符号の説明

１、２、３、２０１、３５０、４５０ クライアントＰＣ
４、５、６、２０２、３００、４００ ＭＦＰ
３０１，３５１ ネットワークインタフェース
３０２、３５２ Ｗｅｂサービス・フレームワーク
３０３、３５３ 通信クライアント部
３０４、３５４ 通信サーバ部
３０５、３５５ データ処理部
３０６ 情報処理ロジック部
３０７、３５６ 情報アクセス部
３０８ 情報保持部
３０９ 新機能
３１０ 新機能ロジック部
３１１ 新機能拡張データ部
３１２ 機能管理部
３１３ 機能処理部
３５７ ビュー生成部
３５８ ＵＩ
４０１ リクエスト解析手段
４０２ 処理内容取得手段
４０３ レスポンス生成手段
４０４、４５４ 通信手段
４０５、４５５ 機能実現手段
４０６、４５６ 一覧管理手段
４０７、４５７ データ形式保持手段
４５１ リクエスト生成手段
４５２ レスポンス解析手段
４５３ ステータス取得手段
１２０１ 共通Ｉ／Ｆ
１２０２ 共通処理部
１２０３ ロジック管理部
１４０１ 判定手段
１４０２ 記憶手段
１４０３ 生成手段
２１００ アドレス帳機能
２１０１ アドレス帳ロジック部
２１０２ アドレス帳拡張データ部
２１０３ アドレス帳管理部
２１０４ アドレス帳処理部

Claims (13)

1. クライアント装置からの第一の記述形式によるリクエストを受信する通信手段と、該リクエストに含まれる要求項目に対応する処理内容のデータ形式がある場合は、前記要求項目を前記データ形式に変換し、前記データ形式がない場合は、前記要求項目を第二の記述形式に変換するデータ処理手段とを備える画像形成装置であって、
   リクエストに含まれる要求項目に対し、前記データ処理手段により変換された形式で処理を実行する機能実現手段であって、画像形成装置に備えられた該機能実現手段の識別情報とロジック名とを関連付けて記憶手段に記憶して管理する管理手段と、
   複数の前記機能実現手段に共通して必要な処理を定義する共通処理手段と、を備え、
   前記管理手段は、
   新たに受信されたリクエストに含まれる要求項目に対する前記機能実現手段の識別情報が、前記記憶手段に記憶されている場合、前記識別情報と前記ロジック名とに基づいて、前記機能実現手段に処理を行なわせるためのロジック部を生成し、
   前記共通処理手段は、
   前記管理手段により生成されたロジック部に対し、前記リクエストに含まれる要求項目の処理依頼を行う画像形成装置。
2. 当該画像形成装置に新規な機能実現手段が追加された場合、
   前記管理手段は、前記新規な機能実現手段の識別情報とロジック名とをさらに前記記憶手段に記憶して管理し、
   前記データ処理手段は、
   前記新規な機能実現手段に対する要求項目を含むリクエストが受信された場合、該リクエストに含まれる要求項目を前記第二の記述形式に変換する請求項１記載の画像形成装置。
3. 前記管理手段は、
   前記ロジック部を生成する場合、前記共通処理手段で定義される複数の処理のうち、前記識別情報に対応する機能実現手段に必要な処理のみを規定する請求項１又は２記載の画像形成装置。
4. 前記リクエスト中に、前記要求項目における処理対象のデータが含まれている場合、
   前記ロジック部は前記データ処理手段に前記処理対象のデータの解析依頼を行う請求項１乃至３何れか一項に記載の画像形成装置。
5. 前記機能実現手段毎に、前記処理内容に対応する応答項目のデータ形式を保持するデータ形式保持手段と、
   前記機能実現手段から、前記応答項目のデータ形式による応答項目、及び／又は、前記第二の記述形式による応答項目を取得して、前記第一の記述形式により前記応答項目が記述されたレスポンスを生成するレスポンス生成手段と、を備え、
   前記通信手段は、さらに、前記レスポンスを前記クライアント装置に送信する請求項１乃至４何れか一項に記載の画像形成装置。
6. クライアント装置からの第一の記述形式によるリクエストを受信する通信手段と、該リクエストに含まれる要求項目に対応する処理内容のデータ形式がある場合は、前記要求項目を前記データ形式に変換し、前記データ形式がない場合は、前記要求項目を第二の記述形式に変換するデータ処理手段と、リクエストに含まれる要求項目に対し、前記データ処理手段により変換された形式で処理を実行する機能実現手段であって、画像形成装置に備えられた該機能実現手段の識別情報とロジック名とを関連付けて記憶手段に記憶して管理する管理手段と、複数の前記機能実現手段に共通して必要な処理を定義する共通処理手段とを備える画像形成装置における情報処理方法であって、
   前記管理手段が、新たに受信されたリクエストに含まれる要求項目に対する前記機能実現手段の識別情報が、前記記憶手段に記憶されている場合、前記識別情報と前記ロジック名とに基づいて、前記機能実現手段に処理を行わせるためのロジック部を生成する生成ステップと、
   前記共通処理手段が、前記生成ステップにより生成されたロジック部に対し、前記リクエストに含まれる要求項目の処理依頼を行う依頼ステップと、
   を有する情報処理方法。
7. 当該画像形成装置に新規な機能実現手段が追加された場合、
   前記管理手段が、前記新規な機能実現手段の識別情報とロジック名とをさらに前記記憶手段に記憶する記憶ステップと、
   前記データ処理手段が、前記新規な機能実現手段に対する要求項目を含むリクエストが受信された場合、該リクエストに含まれる要求項目を前記第二の記述形式に変換する変換ステップとを有する請求項６記載の情報処理方法。
8. 前記生成ステップは、前記共通処理手段で定義される複数の処理のうち、前記識別情報に対応する機能実現手段に必要な処理のみを規定して前記ロジック部を生成する請求項６又は７記載の情報処理方法。
9. 前記リクエスト中に、前記要求項目における処理対象のデータが含まれている場合、
   前記ロジック部は、前記データ処理部手段に前記データの解析依頼を行う依頼ステップを有する請求項６乃至８何れか一項に記載の情報処理方法。
10. 前記画像形成装置は、前記機能実現手段毎に、前記処理内容に対応する応答項目のデータ形式を保持するデータ形式保持手段を備え、
    レスポンス生成手段が、前記機能実現手段から、前記応答項目のデータ形式による応答項目、及び／又は、前記第二の記述形式による応答項目を取得して、前記第一の記述形式により前記応答項目が記述されたレスポンスを生成するレスポンス生成ステップと、
    前記通信手段が、前記レスポンスを前記クライアント装置に送信する送信ステップと
    を有する請求項６乃至９何れか一項に記載の情報処理方法。
11. クライアント装置と画像形成装置が接続された画像形成システムであって、
    前記クライアント装置は、
    前記画像形成装置に対する要求項目を有するリクエストを第一の記述形式により生成するリクエスト生成手段と、
    前記リクエストを送信する第一の通信手段と、を備え、
    前記画像形成装置は、クライアント装置からの第一の記述形式によるリクエストを受信する第二の通信手段と、該リクエストに含まれる要求項目に対応する処理内容のデータ形式がある場合は、前記要求項目を前記データ形式に変換し、前記データ形式がない場合は、前記要求項目を第二の記述形式に変換するデータ処理手段とを備える画像形成装置であって、
    リクエストに含まれる要求項目に対し、前記データ処理手段により変換された形式で処理を実行する機能実現手段であって、画像形成装置に備えられた該機能実現手段の識別情報とロジック名とを関連付けて記憶手段に記憶して管理する管理手段と、
    複数の前記機能実現手段に共通して必要な処理を定義する共通処理手段とを備え、
    前記管理手段は、
    新たに受信されたリクエストに含まれる要求項目に対する前記機能実現手段の識別情報が、前記記憶手段に記憶されている場合、前記識別情報と前記ロジック名とに基づいて、前記機能実現手段に処理を行わせるためのロジック部を生成し、
    前記共通処理手段は、
    前記管理手段により生成されたロジック部に対し、前記リクエストに含まれる要求項目の処理依頼を行う画像形成システム。
12. 前記画像形成装置において、
    前記機能実現手段毎に、前記処理内容に対応する応答項目のデータ形式を保持するデータ形式保持手段と、
    前記機能実現手段から、前記応答項目のデータ形式による応答項目、及び／又は、前記第二の記述形式による応答項目を取得して、前記第一の記述形式により前記応答項目が記述されたレスポンスを生成するレスポンス生成手段とを備え、
    前記第二の通信手段は、さらに、前記レスポンスを前記クライアント装置に送信する請求項１１に記載の画像形成システム。
13. 前記クライアント装置は、さらに、
    前記第一の通信手段より受信されたレスポンスに基づいて表示画面データを生成する表示画面生成手段を備え、
    前記表示画面生成手段は、
    前記第二の記述形式による応答項目に基づいて前記レスポンスが生成された場合、該応答項目のデータに対して、前記クライアント装置により表示可能な表示規則に従って前記表示画面データを生成する請求項１２に記載の画像形成システム。

Images