(57)【特許請求の範囲】
【請求項１】
端末と、該端末とネットワークを介して接続され、該端末から送信される要求メッセージに応じて前記端末に所定の情報を送信する情報機器とを有する機器情報配信システムにおいて、
前記端末から送信される要求メッセージが差分要求メッセージ又は全情報要求メッセージである場合に、
前記情報機器は、前記全情報要求メッセージに対して当該情報機器の全情報、又は前記差分要求メッセージに対して当該情報機器の現在の情報と前記端末が既に有する当該情報機器の情報との差分情報を前記端末に送信し、
前記端末から送信される要求メッセージが設定要求メッセージである場合に、
前記情報機器は、前記端末から要求メッセージと共に送信されたバージョン情報が当該情報機器の現在の情報のバージョン情報と一致しない場合には、前記端末からの要求メッセージと共に送信されたバージョン情報と当該情報機器の現在の情報のバージョン情報との間で変更された属性情報の項目を、属性値のバージョン毎の変更内容を記憶しているバージョン管理テーブルから取得して、前記バージョン管理テーブルにおいて管理されている前記変更された属性情報の項目に基づき前記端末に応答し、一致する場合には前記設定要求メッセージに従って当該情報機器の属性情報を設定して、設定後の属性情報のバージョン情報を前記端末に送信する
ことを特徴とする機器情報配信システム。
【請求項２】
前記端末は、前記情報機器の属性情報のバージョン情報を要求メッセージと共に送信するバージョン情報送信手段を有し、
前記情報機器は、該情報機器の属性情報のバージョンを管理するバージョン管理システムを有し、
該バージョン管理システムは、前記端末から送信されるバージョン情報に基づいて前記要求メッセージが差分要求メッセージ又は全情報要求メッセージのいずれかであることを判断することを特徴とする、請求項１記載の機器情報配信システム。
【請求項３】
前記バージョン管理テーブルは、前記バージョン管理システムによって管理されることを特徴とする、請求項２記載の機器情報配信システム。
【請求項４】
前記情報機器は、前記バージョン管理システムによって管理され、属性情報を記憶する属性値管理テーブルを更に有し、
前記端末から送信される要求メッセージが変更要求メッセージである場合に、
前記バージョン管理システムは、前記要求メッセージを受けて前記バージョン管理テーブル及び前記属性値管理テーブルを更新することを特徴とする、請求項３記載の機器情報配信システム。
【請求項５】
前記端末から送信される要求メッセージが全情報要求又は差分要求メッセージである場合に、
前記バージョン管理システムは、前記要求メッセージを受けて前記端末に送信する情報に該情報に対応するバージョン情報を付加して送信することを特徴とする、請求項２記載の機器情報配信システム。
【請求項６】
前記端末から送信される要求メッセージが全情報要求又は差分要求メッセージである場合に、
前記バージョン管理システムは、前記要求メッセージを受けて前記端末に送信する情報に当該情報機器の情報の変更内容の情報を付加して送信することを特徴とする、請求項２記載の機器情報配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末と、その要求に応じて端末に所定の情報を送信する情報機器とがネットワークによって接続されている機器情報配信システムに関する。
【背景技術】
【０００２】
図１のように、多機能プリンタ（ＭＦＰ）のような複合機１３１及び１３２、レーザプリンタ（ＬＰ）のようなプリンタ１４及びスキャナ１５等が、ネットワーク１０によって統合サーバー１１及びパーソナルコンピュータ（ＰＣ）１２１及び１２２に接続されているシステムにおいて、近年、夫々の機器間の通信手段として、ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔｅｄ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）が使用されている。ＳＯＡＰによる通信によって、複合機１３１及び１３２、プリンタ１４並びにスキャナ１５等の機器は、ＳＯＡＰサーバーとして動作し、機器の操作に関する設定項目の値及び属性値をＳＯＡＰ形式で配信することができるようになり、更に、統合サーバー１１並びにＰＣ１２１及び１２２のようなＳＯＡＰクライアントからの設定要求を受け、それに応じて設定されることができる。即ち、ユーザーは、ＳＯＡＰクライアントを介して複合機等の機器を管理することができる。
【０００３】
特開２００４−２１３６００号公報（特許文献１。）では、ＳＯＡＰを利用したネットワークにおいて、ユーザーが使用するコンピュータ端末の機種又はオペレーティングシステムに依存することなく、Ｗｅｂサービスの提供を可能とし、他の機器からの処理要求も統一的に処理することが可能となる情報処理装置が開示されている。
【特許文献１】特開２００４−２１３６００号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来のＳＯＡＰを利用したシステムにおいて、統合サーバー及びＰＣ等のＳＯＡＰクライアントは、設定画面を用意するために、設定項目に関する属性値を予め取得する。統合サーバーでは、ネットワークで接続された機器の全てを一括管理することが可能であり、ネットワーク上に同一の機器が存在する場合に、一つの機器によって属性値を取得することにより、他の同一である機器からは属性値を取得する必要がなくなる。しかし、従来技術では、機器間の属性値の同一性を認識するための方法がないため、機器の同一性を認識することができず、一つの機器より属性値を取得した場合に、それと同一である他の機器からも属性値を取得しなければならない。
【０００５】
また、ＳＯＡＰクライアント側で、通信量を減らすために、一度取得した属性値を保持することがある。しかし、属性値の新旧情報を認識する方法がないため、更新の必要性を認識することができず、ＳＯＡＰクライアントは、設定画面を用意する度に毎回属性値を取得しなければならない。更に、ＳＯＡＰクライアント側では保持した属性値を再利用することができない。
【０００６】
上述したように、従来のシステムでは、ＳＯＡＰクライアントが設定画面を表示するためには、表示の度に属性値を取得する必要があり、これによって、ＳＯＡＰクライアント及びサーバーの双方において処理が増大することとなる。また、ＳＯＡＰは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式のデータを通信するためのプロトコルであって、機器には、ＸＭＬ解析等の負担の大きな処理が存在する。
【０００７】
従って、本発明の目的は、ＳＯＡＰクライアントとサーバーとの間のデータ通信に伴う処理の回数及びデータ通信におけるデータ量を減らすことができる機器情報配信システムを提供することである。
【課題を解決するための手段】
【０００８】
上記目的を達成するために、本発明の機器情報配信システムは、端末と、該端末とネットワークを介して接続され、該端末から送信される要求メッセージに応じて前記端末に所定の情報を送信する情報機器とを有する機器情報配信システムであって、前記端末から送信される要求メッセージが差分要求メッセージ又は全情報要求メッセージである場合に、前記情報機器は、前記全情報要求メッセージに対して当該情報機器の全情報、又は前記差分要求メッセージに対して当該情報機器の現在の情報と前記端末が既に有する当該情報機器の情報との差分情報を前記端末に送信することを特徴とする。
【０００９】
これにより、ＳＯＡＰクライアントである端末が既にＳＯＡＰサーバーである情報機器の情報を有している場合に、端末は、その情報と情報機器の現在の情報との差分情報のみを得ることができるので、端末と情報機器との間のデータ通信に伴う処理の回数及びデータ通信におけるデータ量を減らすことが可能となる。
【００１０】
また、本発明の機器情報配信システムにおいて、前記端末は、前記情報機器の属性情報のバージョン情報を要求メッセージと共に送信するバージョン情報送信手段を有し、前記情報機器は、該情報機器の属性情報のバージョンを管理するバージョン管理システムを有し、該バージョン管理システムは、前記端末から送信されるバージョン情報に基づいて前記要求メッセージが差分要求メッセージ又は全情報要求メッセージのいずれかであることを判断することを特徴とする。
【００１１】
これにより、ＳＯＡＰクライアントである端末が既にＳＯＡＰサーバーである情報機器の情報を有している場合に、情報機器は、端末から要求メッセージと共に送信されたバージョン情報に基づいて端末に送信すべき情報の内容を判別することができる。即ち、バージョン情報によって端末側が既に有する情報機器の属性情報が更新される必要性を判別することができるので、結果として、端末は、更新の必要性を確認するために定期的に情報機器を監視する必要がなくなり、端末と情報機器との間のデータ通信に伴う処理を減らすことが可能となる。
【００１２】
なお、特許請求の範囲及び課題を解決するための手段における「バージョン情報」とは、情報機器の属性情報に付与され、数字で表わされるバージョンを有し、この数字は、情報機器の属性情報が端末によって変更される度に更新される。例えば、バージョンｉの属性情報が更新された場合、変更された属性情報に付与されるバージョンはｉ＋１となる。
【００１３】
また、本発明の機器情報配信システムにおいて、前記情報機器は、前記バージョン管理システムによって管理されているバージョン管理テーブルを更に有し、該バージョン管理テーブルには、バージョン毎に、直前のバージョンから変更された前記属性情報の項目が記憶されていることを特徴とする。
【００１４】
これにより、情報機器の属性情報が端末によって変更された場合に、情報機器は、属性情報の変更内容及びバージョン情報のみを記憶しておけば良く、情報機器内のリソースを必要最低限とすることが可能となる。また、情報機器から端末に送信する差分情報を作成するときに、記憶された直前のバージョンから変更された属性情報の項目を用いて差分情報を作成することができるので、作成時の処理の量を減らすことが可能となる。
【００１５】
また、本発明の機器情報配信システムにおいて、前記情報機器は、前記バージョン管理システムによって管理され、属性情報を記憶する属性値管理テーブルを更に有し、前記端末から送信される要求メッセージが変更要求メッセージである場合に、前記バージョン管理システムは、前記要求メッセージを受けて前記バージョン管理テーブル及び前記属性値管理テーブルを更新することを特徴とする。
【００１６】
これにより、情報機器の属性情報を変更する必要が生じた場合に、端末側から容易に変更することが可能となる。
【００１７】
また、本発明の機器情報配信システムにおいて、前記端末から送信される要求メッセージが全情報要求又は差分要求メッセージである場合に、前記バージョン管理システムは、前記要求メッセージを受けて前記端末に送信する情報に該情報に対応するバージョン情報を付加して送信することを特徴とする。
【００１８】
これにより、端末は、送信された情報機器の属性情報の内容を判断することが可能となるので、例えば、ネットワーク上に同一である複数台の情報機器が存在する場合に、端末は、属性情報の内容によってそれら情報機器が同一であることを認識することができ、属性情報を取得する際にいずれか一台の情報機器から取得すれば良い。従って、端末と情報機器との間のデータ通信量を減らすことができる。
【００１９】
また、本発明の機器情報配信システムにおいて、前記端末から送信される要求メッセージが全情報要求又は差分要求メッセージである場合に、前記バージョン管理システムは、前記要求メッセージを受けて前記端末に送信する情報に当該情報機器の情報の変更内容の情報を付加して送信することを特徴とする。
【００２０】
これにより、端末は、情報機器から送信された変更内容に基づいて、端末が既に有する情報機器の情報を情報機器の現在の情報に対応するように変更する場合に、その変更に関する処理の量を減らすことができる。
【００２１】
なお、特許請求の範囲及び課題を解決するための手段における「変更内容」とは、情報機器の属性情報が端末によって変更されたときの変更された属性情報の内容であって、追加、変更又は削除等の情報である。
【００２２】
また、本発明の機器情報配信システムにおいて、前記端末から送信される要求メッセージが設定要求メッセージである場合に、前記情報機器は、前記端末から要求メッセージと共に送信されたバージョン情報が当該情報機器現在の情報のバージョン情報と一致しない場合にはその旨を前記端末に通知し、一致する場合には前記設定要求メッセージに従って当該情報機器の属性情報を設定して、設定後の属性情報のバージョン情報を前記端末に送信することを特徴とする。
【００２３】
これにより、端末は、端末側で情報機器を設定するための設定画面を用意するときに、情報機器の現在の属性情報が端末が既に有する情報機器の属性情報に対して変更されているか否かを確認することができるので、端末は、そのような確認を行うために定期的に情報機器を監視する必要がなくなる。従って、端末と情報機器との間のデータ通信に伴う処理を減らすことが可能となる。
【発明の効果】
【００２４】
本発明により、機器情報配信システムにおいて、ＳＯＡＰクライアントである端末とサーバーである情報機器との間のデータ通信に伴う処理の回数及びデータ通信におけるデータ量を減らすことが可能となる。
【発明を実施するための最良の形態】
【００２５】
本発明の実施例について図を参照して説明する。
【００２６】
〔情報配信システムの構成〕
図１のように、統合サーバー１１と、パーソナルコンピュータ（ＰＣ）１２１及び１２２と、多機能プリンタ（ＭＦＰ）のような複合機１３１及び１３２と、レーザープリンタ（ＬＰ）のようなプリンタ１４と、スキャナ１５とが、イーサネット（登録商標）のようなネットワーク１０によって接続されたシステムを例として考える。統合サーバー１１並びにＰＣ１２１及び１２２は、ＳＯＡＰクライアントであって、ＳＯＡＰクライアントソフト等のようなＳＯＡＰによる通信を行うためのソフトを有する。複合機１３１及び１３２、プリンタ１４並びにスキャナ１５は、ＳＯＡＰサーバーであって、ネットワーク１０を介してＳＯＡＰクライアントからの要求を受ける。統合サーバー１１は、ネットワーク上の複数のＳＯＡＰサーバーと通信し、通信して得られた情報に基づいてＷｅｂ画面を作成し、それをＰＣ１２１及び１２２に送信する。本実施例では、統合サーバー１１とＰＣ１２１及び１２２との間の通信は、ＳＯＡＰではなく、ＨＴＭＬ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）によって行われる。従って、ＰＣ１２１及び１２２は、統合サーバー１１を介して複合機等のＳＯＡＰサーバーとＳＯＡＰによる通信を行うことができる。複合機等のＳＯＡＰサーバーは、設定項目単位でＳＯＡＰクライアントの要求を受けることができる。ここでは、設定項目単位を「クラス」と呼ぶことにする。
【００２７】
図２は、図１の複合機１２１が有するクラスの階層の例を示す図である。図２において、図の右端がクラスの最小単位であって、左に行く毎に最小単位をまとめたクラスとなる。クラスの最小単位には、時刻、タイマー、ユーザー認証管理共通プロトコル、ローカル認証、ユーザー管理者等があり、ユーザーは、この最小単位毎に設定値の参照、設定及び属性値の取得を行うことができる。
【００２８】
〔ＳＯＡＰサーバーの構成〕
次に、図３で図１の複合機１２１のＳＯＡＰサーバーの構成の例を示す。ＳＯＡＰサーバー３２は、ＮＣＳ（Ｎｅｔｗｏｒｋ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ）３３と、リクエスト分配システム（ｌｉｂｇｗｗｗ）３４と、ＷＳＦ（Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｆｒａｍｅｗｏｒｋ）機器管理サービス部３５と、プロセス部３６と、サービス層３７とを有し、イーサネット（登録商標）３０を介してＳＯＡＰクライアントと接続されている。ＮＣＳ３３は、ＳＯＡＰクライアントからの要求を受ける手段であって、Ｗｅｂサーバープログラムとしてｈｔｔｐｄ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  Ｄａｅｍｏｎ）３３１を有し、これを用いてＳＯＡＰクライアント３１からの要求を受けることができる。リクエスト分配システム３４は、ＮＣＳ３３で受けたＳＯＡＰクライアントからの要求を、要求に応じて各プロセスに分配する手段である。ＷＳＦ機器管理サービス部３５は、ネットワーク接続された当該機器を管理する手段であって、セッション情報を管理するセッション管理部３５１と、アカウントロックを管理するロック管理部３５２とを有する。プロセス部３６は、複合機１２１が有する各機能を作動させる手段であって、Ｓｙｓｔｅｍ３６１、Ｐｒｉｎｔｅｒ３６２、ＦＡＸ３６３及びＳＤＫ（Ｓｏｆｔｗａｒｅ  Ｄｅｖｅｌｏｐｍｅｎｔ  Ｋｉｔ）３６４の四つのプロセスを有し、夫々のプロセスは、ＳＯＡＰクライアントの要求に応じて対応する応答を作成する。プロセスの一つであるＳｙｓｔｅｍ３６１は、システムクラス作成部３６ａと、ネットワーククラス作成部３６ｂと、時刻クラス作成部３６ｃと、認証クラス作成部３６ｄと、設定値取得部３６ｅと、設定処理部３６ｆと、バージョン管理システム３６ｇと、バージョン管理テーブル３６ｈと、属性値管理テーブル３６ｊを有する属性値管理部３６ｉとを有する。システムクラス作成部３６ａ、ネットワーククラス作成部３６ｂ、時刻クラス作成部３６ｃ及び認証クラス作成部３６ｄの各クラス作成部は、ＳＯＡＰクライアントからの要求の種類を解析する手段である。設定値取得部３６ｅは、サービス層３７より設定値を取得し、それに基づいてＳＯＡＰクライアントへの応答を作成する手段である。設定処理部３６ｆは、属性値管理部３６ｉに記憶されている属性値を取得して、その値を確認し、値に問題がない場合にはサービス層３７の各サービスの設定を行い、設定した結果に基づいてＳＯＡＰクライアントへの応答を作成する手段である。ここで、属性値管理部３６ｉは、上述したように属性値を記憶する手段であって、属性値は属性値管理テーブル３６ｊに格納されている。バージョン管理システム３６ｇは、バージョン管理テーブル３６ｈ及び属性値管理部３６ｉを管理する手段であって、ＳＯＡＰクライアントからの要求に応じて、バージョン管理テーブル３６ｈ及び属性値管理部３６ｉの夫々で管理されている情報に基づいてＳＯＡＰクライアントへの応答を作成する。バージョン管理テーブル３６ｈでは、属性値管理部に記憶されている情報のバージョン及び属性値のバージョン毎の変更内容が記憶されている。サービス層３７は、Ｓｙｓｔｅｍプロセス３６１に夫々の機能を提供するサービス３７１から３７７と、Ｐｒｉｎｔｅｒプロセス３６２にその機能を提供するサービス３７８と、ＦＡＸプロセス３６３にその機能を提供するサービス３７９とを有する。ここで、サービス３７１から３７９は、全て異なった機能を提供するとする。
【００２９】
図３のＳＯＡＰサーバーにおいて、ＳＯＡＰクライアントから送信された要求は、まずＮＣＳ３３により受信され、要求に応じてリクエスト分配システム３４によって各プロセスに分配される。本実施例では、如何なる要求もＷＳＦ機器管理サービス３５により一度受け付けられ、ＷＳＦ機器管理サービス３５は、ＳＯＡＰクライアント側のユーザー認証等の処理を行い、要求の対象であるクラスを有するプロセスに要求を送る。次に、プロセスは、要求を受け取ると、クラス作成部で要求の種類を解析する。例えば、要求が設定値の取得要求である場合には、要求は、Ｓｙｓｔｅｍプロセス３６１の各クラス作成部３６ａ、３６ｂ、３６ｃ及び３６ｄに送られ、設定値の取得要求であると判断されて、設定値取得部３６ｅに送られる。設定値取得部３６ｅは、要求を受け取ると、サービス層３７の各サービスよりそれらの設定値を取得し、それに基づいてＳＯＡＰクライアントへの応答を作成する。作成された応答は、クラス作成部に送られる。また、例えば、要求が設定値の設定要求である場合には、要求は、Ｓｙｓｔｅｍプロセス３６１の各クラス作成部３６ａ、３６ｂ、３６ｃ及び３６ｄに送られ、設定値の設定要求であると判断されて、設定処理部３６ｆに送られる。設定処理部３６ｆは、要求を受け取ると、属性値管理部３６ｉから属性値を取得し、その値を確認する。確認した結果、値に問題がなければ、設定処理部３６ｆは、サービス層３７に対して要求を送り、要求に基づいて各サービスの設定値の設定処理を行う。次に、設定処理部３６ｆは、設定処理後の各サービスの設定値に基づいてＳＯＡＰクライアントへの応答を作成する。上述したように作成された応答は、いずれも、クラス作成部に送られる。クラス作成部は、この応答をＳＯＡＰクライアントへ返す。
【実施例１】
【００３０】
〔属性値取得要求の場合の処理シーケンス〕
図３のＳＯＡＰサーバーにおいて、ＳＯＡＰクライアントから送信された要求が属性値取得要求であった場合について説明する。
【００３１】
図４は、従来技術による属性値取得シーケンスの例を示す図である。ステップＳ４１において、ＳＯＡＰクライアント３１から属性値取得要求が送られると、ＳＯＡＰサーバー内のＮＣＳ３３は、ｈｔｔｐｄプログラムを用いてその要求を受ける。ＳＯＡＰクライアントからの要求は、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式で記述されるメッセージであり、属性値取得要求の場合には、要求が属性値取得要求であることを表わすように「ｇｅｔＯｂｊｅｃｔＣｌａｓｓＣａｐａｂｉｌｉｔｙ（）」と記述される。次に、ステップＳ４２において、ＮＣＳ３３のｈｔｔｐｄで受け取られた要求は、リクエスト分配システム（ｌｉｂｇｗｗｗ）３４に送られて各プロセスに分配されるが、要求に対してユーザー認証等の処理を行う場合にはステップＳ４３に進み、要求は、各プロセスに分配される前にＷＳＦ機器管理サービス３５（ＷＳ）により一度受け付けられ、ステップＳ４４においてクラス作成部３６ａ、３６ｂ、３６ｃ及び３６ｄに送られる。ここで、属性値取得要求は、上述したようにクラス内に存在する設定項目単位で属性値が取得されるよう要求している。従って、ステップＳ４５において、クラス作成部は、設定項目単位で属性情報を属性値管理部３６ｉに要求し、クラスの全項目の属性情報群を作成する。作成された属性情報群は、ステップＳ４６からＳ４９において、ＷＳＦ機器管理サービス３５（ＷＳ）、リクエスト分配システム（ｌｉｂｇｗｗｗ）３４及びＮＣＳ３３のｈｔｔｐｄを経由して、ＳＯＡＰクライアント３１に応答として返される。
【００３２】
一方、図５及び６は、本発明による属性値取得シーケンスの例を示す図である。図５及び６において、ＳＯＡＰクライアントから属性値取得要求が送信されて、その要求がクラス作成部に至るまでの過程は、図４で示した従来技術による属性値取得シーケンスと同じである。しかし、本発明では、ＳＯＡＰクライアントからの属性値取得要求には、バージョン情報送信手段５２によりその要求メッセージにバージョン情報の項目が加えられている。
【００３３】
図５は、ＳＯＡＰクライアント５１からの要求がサーバー側の全ての属性情報を取得するための全情報要求である場合の属性値取得シーケンスの例を示す図であって、このような場合、ＳＯＡＰクライアントからの要求にはバージョン情報が含まれない。即ち、要求メッセージのバージョン情報の項目は、「ｖｅｒｓｉｏｎ＝ＮＵＬＬ」と記述される。ステップＳ５５において、要求は、クラス作成部からバージョン管理システム３６ｇに送られ、バージョン管理システム３６ｇは、要求メッセージに付与されているバージョン情報を確認し、ステップＳ５６において、ＳＯＡＰクライアントからの要求が全情報要求である旨をクラス作成部に通知する。ＳＯＡＰクライアントからの要求が全情報要求である場合には、図４で示した従来技術による属性値取得シーケンスと同様に、ステップＳ５７において、クラス作成部は、設定項目単位で属性情報を属性値管理部３６ｉに要求し、クラスの全項目の属性情報群を作成する。作成された属性情報群は、ステップＳ５８からＳ５１１において、ＷＳＦ機器管理サービス３５（ＷＳ）、リクエスト分配システム（ｌｉｂｇｗｗｗ）３４及びＮＣＳ３３のｈｔｔｐｄを経由して、ＳＯＡＰクライアント５１に応答として返される。
【００３４】
図６は、ＳＯＡＰクライアントからの要求がサーバー側の現在の情報とクライアントが既に有するサーバーの情報との差分情報を取得するための差分要求である場合の属性値取得シーケンスの例を示す図であって、このような場合、ＳＯＡＰクライアントからの要求にはバージョン情報が含まれ、要求メッセージのバージョン情報の項目は、例えば「ｖｅｒｓｉｏｎ＝００３」と記述される。「００３」という数字は、クライアントが既に有するサーバーの情報のバージョンを表わす。ステップＳ６５において、要求は、クラス作成部からバージョン管理システム３６ｇに送られ、バージョン管理システム３６ｇは、要求メッセージに付与されているバージョン情報を確認し、それをステップＳ６６においてバージョン管理テーブル３６ｈに通知する。バージョン管理テーブル３６ｈは、バージョン毎に、直前のバージョンから変更された属性情報の項目を記憶しており、ステップＳ６７において、送られてきたバージョン情報と現在の属性情報のバージョンとの間で変更された属性情報の項目をバージョン管理システム３６ｇに送る。次に、ステップＳ６８において、バージョン管理システム３６ｇは、バージョン管理テーブル３６ｈから送られてきた属性情報の項目をクラス作成部に送り、ステップＳ６９において、クラス作成部は、この属性情報の項目を属性値管理部３６ｉに要求し、サーバーの現在の情報とクライアントが既に有するサーバーの情報との差分情報群を作成する。作成された差分情報群は、ステップＳ６１０からＳ６１３において、ＷＳＦ機器管理サービス３５（ＷＳ）、リクエスト分配システム（ｌｉｂｇｗｗｗ）３４及びＮＣＳ３３のｈｔｔｐｄを経由して、ＳＯＡＰクライアント５１に応答として返される。
【００３５】
〔バージョン管理システムによる要求判断処理〕
図３のバージョン管理システム３６ｇが、ＳＯＡＰクライアントからの属性値取得要求が全情報要求又は差分要求のいずれであるかを判断する処理について、図７を参照して更に詳細に説明する。図７は、バージョン管理システムによる要求判断処理シーケンスの例を示す図である。
【００３６】
ステップＳ７１において、バージョン管理システム３６ｇは、サーバー側の現在の情報のバージョン情報をバージョン管理テーブル３６ｈより取得する。次に、バージョン管理システム３６ｇは、ステップＳ７２において、ＳＯＡＰクライアントからの要求にバージョン情報が含まれるか否かを確認する。バージョン情報が含まれない場合、即ち、要求メッセージのバージョン情報の項目が「ｖｅｒｓｉｏｎ＝ＮＵＬＬ」と記述されている場合、ＳＯＡＰクライアントからの要求は全情報要求であると判断され、要求判断処理は終了する。一方、バージョン情報が含まれる場合、即ち、要求メッセージのバージョン情報の項目が、例えば「ｖｅｒｓｉｏｎ＝００３」と、「ＮＵＬＬ」以外の何らかの数字で記述されている場合には、ＳＯＡＰクライアントからの要求は差分要求であると判断され、処理はステップＳ７３に進む。ステップＳ７３において、バージョン管理システム３６ｇは、ＳＯＡＰクライアントからの要求に含まれていたバージョン情報と現在のサーバーの情報のバージョン情報との間の差分を確認する。ＳＯＡＰクライアントからの要求に含まれていたバージョン情報とサーバーの現在の情報のバージョン情報とが等しい場合には、サーバーは、クライアントが既に有する情報が最新であることのみを応答としてクライアントに返す。ＳＯＡＰクライアントからの要求に含まれていたバージョン情報がサーバーの現在の情報のバージョン情報と異なる場合には、次にステップＳ７４において、ＳＯＡＰクライアントからの要求に含まれていたバージョン情報とサーバーの現在の情報のバージョン情報との間で変更された属性情報の項目をバージョン管理テーブル３６ｈより取得する。取得された属性情報の項目は、上述したようにクラス作成部に送られる。
【００３７】
〔バージョン情報、変更情報及び属性情報の記述〕
また、本発明によって、夫々の情報がバージョン管理テーブル３６ｈ及び属性値管理テーブル３６ｊで如何に記憶されているかを図８から１１を参照して説明する。
【００３８】
図８は、ｔｉｍｅｚｏｎｅクラスの属性値が二度変更された場合にバージョン管理テーブル３６ｈに記憶される情報の内容を表わす図である。バージョン管理テーブル３６ｈは、上述したように、属性情報の内容が変更されたときの追加、変更又は削除等の変更情報のみを記憶する。実際には、バージョン管理テーブル３６ｈには図８のように記述されたデータが記憶される。記述８０は、その属性情報がｔｉｍｅｚｏｎｅクラスに関するものであることを表わし、変更履歴８１及び８２は、属性情報に対して実施された変更の内容を表わす。変更履歴は、属性情報に対して実施された変更の内容をバージョン毎に設定項目単位で表わす。具体的には、変更履歴８１は、記述８３で変更により属性情報のバージョンが００３となったこと、記述８４でｄａｙｌｉｇｈｔＤａｙ項目の属性値が変更されたこと、及び記述８５でｓｔａｎｄａｒｄＯｆｆ項目が削除されたことを表わしている。また、変更履歴８２は、記述８６で変更により属性情報のバージョンが００２となったこと、及び記述８７でｓｔａｎｄａｒｄＯｆｆ項目が追加されたことを表わしている。
【００３９】
図９から１１は、上述した二度の変更を成される前の元のｔｉｍｅｚｏｎｅ属性情報、一度目の変更後のｔｉｍｅｚｏｎｅ属性情報及び二度目の変更後のｔｉｍｅｚｏｎｅ属性情報を夫々表わす図である。なお、属性情報は、属性値管理テーブル３６ｊに記憶されている。図９において、ｔｉｍｅｚｏｎｅ属性情報は、記述９０でそのバージョンが００１であること、及び記述９１でその属性情報がｔｉｍｅｚｏｎｅクラスに関するものであることを表わしている。また、ｔｉｍｅｚｏｎｅ属性情報は、ｔｉｍｅｚｏｎｅ項目９２及びｄａｙｌｉｇｈｔＤａｙ項目９３を有する。図１０は、図９のｔｉｍｅｚｏｎｅ属性情報に変更を実施した例を示す図である。図１０のｔｉｍｅｚｏｎｅ属性情報は、図９と比較して、記述１００のバージョンが００２と更新され、更に、ｓｔａｎｄａｒｄＯｆｆ項目１０１が加えられている。図１１は、図１０のｔｉｍｅｚｏｎｅ属性情報に変更を実施した例を示す図である。図１１のｔｉｍｅｚｏｎｅ属性情報は、図１０と比較して、記述１１０のバージョンが００３と更新され、更に、ｓｔａｎｄａｒｄＯｆｆ項目１０１が削除され、更に、ｄａｙｌｉｇｈｔＤａｙ項目９３の記述１１２の値が３０から３１に変更されている。
【００４０】
上述した二度の変更を成されたＳＯＡＰサーバーに対して、ＳＯＡＰクライアントから差分要求が送信され、送信された要求に含まれるバージョン情報が００１であった場合、図７のステップＳ７４において、バージョン管理システム３６ｇは、バージョン管理テーブル３６ｈより図８で表わされる情報を取得することができる。バージョン管理システム３６ｇは、取得した情報を解析し、ｄａｙｌｉｇｈｔＤａｙ項目に対して変更要求があったこと、及びｓｔａｎｄａｒｄＯｆｆ項目に対して削除要求があったことを認識する。クラス作成部は、バージョン管理システム３６ｇの認識を受けて、変更要求のあったｄａｙｌｉｇｈｔＤａｙ項目の属性値のみを属性値管理部３６ｉより取得し、その結果とｓｔａｎｄａｒｄＯｆｆ項目が削除されたこととを応答としてＳＯＡＰクライアントに返す。
【００４１】
従って、ＳＯＡＰクライアントが既にＳＯＡＰサーバーの情報を有している場合に、サーバーは、本発明によって、クライアントから要求メッセージと共に送信されたバージョン情報に基づいてクライアントに送信すべき情報の内容（即ち、全情報又は差分情報のいずれかの情報。）を判別することができるので、クライアントは、必要な情報のみを得ることができる。従って、クライアントとサーバーとの間のデータ通信に伴う処理の回数及びデータ通信におけるデータ量を減らすことが可能となる。
【００４２】
また、情報機器の属性情報が端末によって変更された場合に、サーバーは、本発明によって、属性情報の変更内容及びバージョン情報のみを記憶しておけば良く、サーバー内のリソースを必要最低限とすることが可能となり、更に、サーバーからクライアントに送信する差分情報を作成するときに、記憶された直前のバージョンから変更された属性情報の項目を用いて差分情報を作成することができるので、作成時の処理の量を減らすことが可能となる。
【実施例２】
【００４３】
〔変更要求の場合の処理シーケンス〕
図３のＳＯＡＰサーバーにおいて、ＳＯＡＰクライアントから送信された要求がサーバーの情報を変更するための変更要求であった場合について説明する。このような変更要求は、ＳＯＡＰサーバーである情報機器が製品化され、市場に渡った後で、情報機器の情報に対して修正又は項目追加等を行う場合に実施される要求である。
【００４４】
図１２は、本発明による動的変更シーケンスの例を示す図である。ステップＳ１２１において、ＳＯＡＰクライアント５１から変更要求が送られると、ＳＯＡＰサーバー内のＮＣＳ３３は、ｈｔｔｐｄプログラムを用いてその要求を受ける。ＳＯＡＰクライアントからの要求は、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式で記述されるメッセージであり、変更要求の場合には、要求が変更要求であることを表わすように「ｃｈａｎｇｅＣｌａｓｓＣａｐａｂｉｌｉｔｙ（）」と記述される。次に、ステップＳ１２２において、ＮＣＳ３３のｈｔｔｐｄで受け取られた要求は、リクエスト分配システム（ｌｉｂｇｗｗｗ）３４に送られて各プロセスに分配されるが、要求に対してユーザー認証等の処理を行う場合にはステップＳ１２３に進み、要求は、各プロセスに分配される前にＷＳＦ機器管理サービス３５（ＷＳ）により一度受け付けられ、ステップＳ１２４においてバージョン管理システム３４ｇに送られる。変更要求の要求メッセージに基づいてバージョン管理テーブル３６ｈを更新するよう、バージョン管理システムは、ステップＳ１２５において、バージョン管理テーブル３６ｈに要求を送る。次に、ステップＳ１２６において、バージョン管理テーブル３６ｈは、更新した結果をバージョン管理システム３６ｇに送信する。更に、バージョン管理システムは、ステップＳ１２７において、変更要求の要求メッセージに基づいて属性値管理テーブル３６ｊを更新するよう属性値管理部３６ｉに要求を送る。次に、ステップＳ１２８において、属性値管理部３６ｉは、更新した結果をバージョン管理システム３６ｇに送信する。バージョン管理システム３６ｇに送信されたバージョン管理テーブル３６ｈ及び属性値管理テーブル３６ｊの更新結果は、ステップＳ１２９からＳ１２１２において、ＷＳＦ機器管理サービス３５（ＷＳ）、リクエスト分配システム（ｌｉｂｇｗｗｗ）３４及びＮＣＳ３３のｈｔｔｐｄを経由して、ＳＯＡＰクライアント５１に応答として返される。
【００４５】
〔変更要求の場合のメッセージ記述〕
図１３は、ＳＯＡＰクライアントから送信される変更要求の一部である動的変更要求メッセージの例を示す図である。記述１３１は、ｔｉｍｅｚｏｎｅクラスに対する要求であることを表わす。記述１３１は、変更されるべき情報のバージョンを表わし、本実施例ではバージョン「００３」の情報を変更対象としている。記述１３２は、要求する変更の内容を表わし、本実施例では「ａｄｄ」と記述されていることから「項目の追加」に関する変更であることが分かる。記述１３３は、サーバーの情報に追加される内容を表わし、冒頭の記述１３４よりｓｕｍｍｅｒｔｉｍｅ項目の追加であることが分かる。
【００４６】
このような項目の追加に関する変更要求が、実施例１で例として挙げた二度の変更を実施されたｔｉｍｅｚｏｎｅクラスに対して成された場合、バージョン管理テーブル３６ｈに記憶される情報の内容は図１４のように表わされる。記述１４０は、その属性情報がｔｉｍｅｚｏｎｅクラスに関するものであることを表わし、変更履歴１４１は、属性情報に対して実施された変更の内容を表わす。具体的には、変更履歴１４１は、記述１４２で変更により属性情報のバージョンが００４となったこと、及び記述１４３でｓｕｍｍｅｒｔｉｍｅ項目が追加されたことを表わしている。なお、以下の記述は、図８に示された記述と同じである。
【００４７】
図１５は、上述した項目の追加に関する変更を成された後のｔｉｍｅｚｏｎｅ属性情報を表わす図である。項目の追加は、図１１のｔｉｍｅｚｏｎｅ属性情報に対して成された変更であるから、図１５と図１１とを比較すると、記述１５１のバージョンが００４と更新され、更に、ｓｕｍｍｅｒｔｉｍｅ項目１５２が加えられている。
【００４８】
従って、サーバーの属性情報を変更する必要が生じた場合に、ユーザーは、本発明によりクライアントを介して容易にサーバーの属性情報を変更することが可能となる。
【実施例３】
【００４９】
〔属性値取得要求に対する応答メッセージの記述〕
上述したような如何なる要求がＳＯＡＰクライアントからＳＯＡＰサーバーに送信されたとしても、サーバーは、その要求の内容に応じた応答をクライアントに返す。属性値取得要求がクライアントからサーバーに送信された場合にサーバーからクライアントに返される応答の内容について、図１６及び１７を参照して説明する。なお、サーバーからクライアントに返される応答は、クライアントからの要求と同様にＸＭＬ形式で記述されるメッセージである。
【００５０】
図１６は、従来技術による応答メッセージの記述の例を示す図である。記述１６０は、ｔｉｍｅｚｏｎｅクラスの属性情報に関する応答であることを表わす。記述１６１、１６２及び１６３は、属性情報に含まれる項目を夫々表わす。上述したように、従来技術によるＳＯＡＰサーバーは、クラスの全項目の属性情報群を応答としてクライアントに返す。
【００５１】
図１７は、本発明による応答メッセージの記述の例を示す図である。図１７の応答メッセージは、図１６と比較して、記述１７０、１７４、１７５及び１７６が加えられている。記述１７０において、一行目の「＜ｖｅｒｓｉｏｎ＞００３＜ｖｅｒｓｉｏｎ＞」は、サーバーに記憶されている現在の属性情報全体のバージョン情報を表わし、本実施例では、ｔｉｍｅｚｏｎｅクラスのバージョンは００３となっている。また、二行目の「＜ｃｏｎｔｅｎｔｓ＞ａｌｌ＜ｃｏｎｔｅｎｔｓ＞」は、応答メッセージ全体として全情報であることを表わしている。応答メッセージが差分情報である場合には、二行目は「＜ｃｏｎｔｅｎｔｓ＞Ｄｉｆｆｅｒｅｎｃｅ＜ｃｏｎｔｅｎｔｓ＞」と記述される。記述１７４は、記述１７１で表わされる項目のバージョン情報を表わし、本実施例では、そのバージョンは００３−０１となっている。同様に、記述１７５は、記述１７２で表わされる項目のバージョン情報を表わし、本実施例では、そのバージョンは００３−０３となっている。記述１７６は、記述１７３で表わされる項目のバージョン情報を表わし、本実施例では、そのバージョンは００３−０１となっている。
【００５２】
なお、属性情報全体のバージョン情報と項目毎のバージョン情報とは、基本的には関連がない。変更要求は、属性情報の全ての項目に対して成されるとは限らず、特定の項目に対して変更が成された場合には、その項目及び属性情報全体のバージョンのみが更新されれば良く、変更を成されなかった他の項目のバージョンは更新されない。
【００５３】
また、属性値取得要求に対する応答メッセージには、図１７で示した属性情報全体のバージョン情報及び項目毎のバージョン情報のみならず、夫々の項目にその項目に成された変更の内容を表わす情報が付加されても良い。
【００５４】
図１８は、ｔｉｍｅｚｏｎｅクラスの属性情報を既に有するＳＯＡＰクライアントからＳＯＡＰサーバーに送信された属性値取得要求が差分要求である場合の応答メッセージにおいて、本発明により属性情報の夫々の項目に変更内容を表わす情報を付加した例を示す図である。記述１８０において、一行目の「＜ｖｅｒｓｉｏｎ＞００４＜ｖｅｒｓｉｏｎ＞」は、サーバーに記憶されている現在の属性情報全体のバージョン情報を表わし、本実施例では、ｔｉｍｅｚｏｎｅクラスのバージョンは００４となっている。また、二行目の「＜ｃｏｎｔｅｎｔｓ＞Ｄｉｆｆｅｒｅｎｃｅ＜ｃｏｎｔｅｎｔｓ＞」は、応答メッセージ全体として差分情報であることを表わしている。応答メッセージが全情報である場合には、二行目は「＜ｃｏｎｔｅｎｔｓ＞ａｌｌ＜ｃｏｎｔｅｎｔｓ＞」と記述される。記述１８１は、ＳＯＡＰクライアントの有する属性情報のバージョンとサーバーの現在の属性情報のバージョン００４との間の変更内容を項目毎に表わす。記述１８２は、項目の現在のバージョン及び前記変更内を表わし、本実施例では、図１８において一行目に「＜ｖｅｒｓｉｏｎ＞００４−０１＜ｖｅｒｓｉｏｎ＞」、二行目に「＜ｃｏｒｒｅｃｔｉｏｎ＞ａｄｄ＜／ｃｏｒｒｅｃｔｉｏｎ＞」と記述されているので、その項目の現在のバージョンは００４−０１であって、サーバーの現在の属性情報は、ＳＯＡＰクライアントの有する属性情報に対してその項目が加えられている。二行目のｃｏｒｒｅｃｔｉｏｎタグには、項目の追加に関する変更があった場合には「ａｄｄ」、項目の削除に関する変更があった場合には「ｄｅｌｅｔｅ」、項目内の属性値等に変更があった場合には「ｃｈａｎｇｅ」が記述される。
【００５５】
また、ＳＯＡＰクライアントは、図１８で示した応答メッセージを受け取ると、既に有するサーバーの情報に対して、応答メッセージで示された差分情報を反映させる。即ち、項目を追加することにより、既に有するサーバーの情報を更新する。
【００５６】
従って、クライアントは、本発明によって、サーバーの属性情報の内容を判断することが可能となる。結果として、端末と情報機器との間のデータ通信量を減らすことができる。
【実施例４】
【００５７】
〔設定要求のメッセージ記述〕
図３のＳＯＡＰサーバーにおいて、ＳＯＡＰクライアントから送信された要求がサーバーの設定値を設定するための設定要求であった場合について、図１９及び２０を参照して説明する。なお、設定要求は、他の要求と同様にＸＭＬ形式で記述されるメッセージである。
【００５８】
図１９は、従来技術による設定要求メッセージの例を示す図である。なお、設定要求メッセージは、ＳＯＡＰクライアントからの設定要求の一部である。記述１９０は、ｓｙｓｔｅｍ．ｌｏｇＣｏｍｍｏｎクラスの属性情報に対する要求であることを表わす。記述１９１、１９２及び１９３は、ｓｙｓｔｅｍ．ｌｏｇＣｏｍｍｏｎクラスにおいてクライアントが既に有するサーバーの属性情報の項目を夫々表わす。記述１９４は、設定要求により新たに追加される属性情報の項目を表わす。
【００５９】
図２０は、本発明による設定要求メッセージの例を示す図である。図２０の設定要求メッセージは、図１９と比較して、記述２００、２０４、２０５及び２０６が加えられている。記述２００は、クライアントが既に有するサーバーの属性情報全体のバージョンを表わし、本実施例では、そのバージョンは００３となっている。記述２０４は、記述２０１で表わされる項目のバージョン情報を表わし、本実施例では、そのバージョンは００３−００となっている。同様に、記述２０５は、記述２０２で表わされる項目のバージョン情報を表わし、本実施例では、そのバージョンは００２−０１となっている。記述２０６は、記述２０３で表わされる項目のバージョン情報を表わし、本実施例では、そのバージョンは００１−０１となっている。
【００６０】
図２０のような設定要求がＳＯＡＰクライアントから送信された場合、図３の設定処理部３６ｆは、設定要求に含まれるバージョン情報がサーバーの現在の情報と一致するか否かを属性値管理部３６ｉに問い合わせる。一致しない場合には、サーバーは、その旨をクライアントに通知する。バージョン情報の不一致に関する通知を受けたクライアントは、属性情報取得要求によりサーバーの現在の情報を取得し、その後改めて設定要求を行う。一方、バージョン情報が一致する場合には、設定処理部３６ｆは、サービス層３７に対して要求を送り、要求に基づいて各サービスの設定値の設定処理を行う。
【００６１】
従って、クライアントは、クライアント側でサーバーを設定するための設定画面を用意するときに、本発明によって、サーバーの現在の属性情報がクライアントが既に有するサーバーの属性情報に対して変更されているか否かを確認することができるようになるので、クライアントは、そのような確認を行うために定期的に情報機器を監視する必要がなくなる。従って、端末と情報機器との間のデータ通信に伴う処理を減らすことが可能となる。
【００６２】
〔変形例〕
上記実施例において、ＳＯＡＰクライアントからの要求が変更要求である場合に、この変更要求には図１３で示すような動的変更メッセージが含まれ、サーバーはこれに基づいて設定値の属性情報の変更処理を行った。しかし、変更要求は、図１５で示すような属性情報をメッセージとして含んでも良い。この場合、サーバー内のバージョン管理システムは、要求に含まれる属性情報と、属性値管理テーブルに記憶されているサーバーの現在の属性情報とを夫々比較する。比較した結果、要求に含まれる属性情報とサーバーの現在の属性情報との間の差に基づいて、バージョン管理テーブルは図１４のように更新される。
【００６３】
また、上記実施例において、属性情報全体及び項目毎のバージョンは数字で表わされていたが、数字以外のアルファベット等の文字が使用されても良い。バージョン情報により機器の種類、機器の属するネットワーク上のグループ等の情報を表わすことが可能であり、例えば、同じネットワーク上にレーザープリンタ（ＬＰ）及び多機能プリンタ（ＭＦＰ）が接続されている場合には、ＬＰの属性情報全体のバージョンを「ｌｐ＊＊＊」、ＭＦＰの属性情報全体のバージョンを「ｍｆｐ＊＊＊」と記述することにより、ＳＯＡＰクライアント側で機器の種類の判別を行うことが容易となる。
【００６４】
また、上記実施例において、属性情報全体のバージョン情報と項目毎のバージョン情報とは、基本的には関連がないとしたが、バージョン情報の利用方法によっては関連を有するようにバージョンを付与されても良い。
【００６５】
また、上記実施例において、ＳＯＡＰサーバーとして複合機、プリンタ及びスキャナ等の画像形成装置を例として説明したが、本発明は、ＳＯＡＰサーバーとして機能するその他の機器に適用されても良い。
【図面の簡単な説明】
【００６６】
【図１】端末及び情報機器のネットワーク接続の例を示す図である。
【図２】ＳＯＡＰサーバーのクラス階層の例を示す図である。
【図３】ＳＯＡＰサーバー内の構成の例を示す図である。
【図４】従来技術による属性値取得シーケンスの例を示す図である。
【図５】本発明による全情報要求の場合の属性値取得シーケンスの例を示す図である。
【図６】本発明による差分要求の場合の属性値取得シーケンスの例を示す図である。
【図７】本発明によるバージョン管理システムによる要求判断処理シーケンスの例を示す図である。
【図８】バージョン管理テーブルに記憶されている情報の例を示す図である。
【図９】ｔｉｍｅｚｏｎｅ属性情報の第一の例を示す図である。
【図１０】図９のｔｉｍｅｚｏｎｅ属性情報を変更した例を示す図である。
【図１１】図１０のｔｉｍｅｚｏｎｅ属性情報を変更した例を示す図である。
【図１２】本発明による動的変更シーケンスの例を示す図である。
【図１３】ＳＯＡＰクライアントからの変更要求の一部である動的変更要求メッセージの例を示す図である。
【図１４】図８のバージョン管理テーブルに記憶されている情報を更新した例を示す図である。
【図１５】図１０のｔｉｍｅｚｏｎｅ属性情報を変更した例を示す図である。
【図１６】従来技術による応答メッセージの記述の例を示す図である。
【図１７】本発明による応答メッセージの記述の例を示す図である。
【図１８】本発明による応答メッセージの記述の第二の例を示す図である。
【図１９】従来技術による設定要求メッセージの例を示す図である。
【図２０】本発明による設定要求メッセージの例を示す図である。
【符号の説明】
【００６７】
１０、３０  ネットワーク（イーサネット（登録商標））
１１  統合サーバー
１２１、１２２  ＰＣ
１３１、１３２  複合機
１４  プリンタ
１５  スキャナ
３１、５１  ＳＯＡＰクライアント
３２  ＳＯＡＰサーバー
３３  ＮＣＳ
３３１  ｈｔｔｐｄ
３４  リクエスト分配システム（ｌｉｂｇｗｗｗ）
３５  ＷＳＦ機器管理サービス
３５１  セッション管理部
３５２  ロック管理部
３６  プロセス部
３６１  Ｓｙｓｔｅｍプロセス
３６２  Ｐｒｉｎｔｅｒプロセス
３６３  ＦＡＸプロセス
３６４  ＳＤＫプロセス
３６ａ  システムクラス作成部
３６ｂ  ネットワーククラス作成部
３６ｃ  時刻クラス作成部
３６ｄ  認証クラス作成部
３６ｅ  設定値取得部
３６ｆ  設定処理部
３６ｇ  バージョン管理システム
３６ｈ  バージョン管理テーブル
３６ｉ  属性値管理部
３６ｊ  属性値管理テーブル
３７  サービス層
３７１〜３７９  サービス
５２  バージョン情報送信手段
８０、９１、１３０、１４０、１６０、１９０  クラス情報
８１、８２、１４１  変更履歴
８３、８６、９０、１００、１１１、１３１、１４２、１５１、１７０、１７４〜１７６、１８０、２００、２０４〜２０６  バージョン情報
８４、８５、８６、１４３  変更情報
９２、９３、１０１、１３３、１５２、１６０〜１６３、１７１〜１７３、１８１、１９１〜１９４、２０１〜２０３  属性情報の項目
１１２  属性値
１３２  変更内容
１３４  項目名
【図１】
0004843301.tif 000002
【図２】
0004843301.tif 000003
【図３】
0004843301.tif 000004
【図４】
0004843301.tif 000005
【図５】
0004843301.tif 000006
【図６】
0004843301.tif 000007
【図７】
0004843301.tif 000008
【図８】
0004843301.tif 000009
【図９】
0004843301.tif 000010
【図１０】
0004843301.tif 000011
【図１１】
0004843301.tif 000012
【図１２】
0004843301.tif 000013
【図１３】
0004843301.tif 000014
【図１４】
0004843301.tif 000015
【図１５】
0004843301.tif 000016
【図１６】
0004843301.tif 000017
【図１７】
0004843301.tif 000018
【図１８】
0004843301.tif 000019
【図１９】
0004843301.tif 000020
【図２０】
0004843301.tif 000021