(57)【要約】【課題】ベンダー名及び／または製品モデル名が異なる場合に、一様なベンダー名及び／または製品モデル名を取得する必要性がある。【解決手段】ＨＴＴＰ通信プロトコルを用いてネットワークに通信可能に結合した被監視デバイスに関する情報を取得する方法である。該方法は、ウェブページアドレスと、対応する複数のモデル名とを取得する段階と、取得したウェブページアドレスを用いてウェブページにアクセスする段階と、複数のモデル名のうちの少なくとも１つを見つけようと、前記アクセスしたウェブページを解析する段階と、解析する段階において前記モデル名の１つが見つかったとき、見つかったモデルを被監視デバイスのモデル名として標準化する段階を有する。【選択図】図４７
2008065833.tif 000002
【特許請求の範囲】
【請求項１】
ＨＴＴＰ通信プロトコルを用いてネットワークに通信可能に結合した被監視デバイスに関する情報を取得する方法であって、
ウェブページアドレスと、対応する複数のモデル名とを取得する段階と、
前記取得したウェブページアドレスを用いてウェブページにアクセスする段階と、
前記複数のモデル名のうちの少なくとも１つを見つけようと、前記アクセスしたウェブページを解析する段階と、
前記解析する段階において前記モデル名の１つが見つかったとき、前記見つかったモデルを前記被監視デバイスのモデル名として標準化する段階を有する、
【請求項２】
前記解析する段階は、
前記複数のモデル名の少なくとも１つが見つかるか、前記ウェブページ中のすべてのラインを検索するまで前記ウェブページをラインごとに検索する段階を有する、請求項１に記載の方法。
【請求項３】
前記データベースは前記ウェブページアドレスと、対応する複数のモデル名とを、ベンダー名と対応させて格納し、
前記方法は、前記ベンダー名の前記データベース中に格納された複数のウェブページアドレスに対して、前記取得する段階、アクセスする段階、解析する段階を繰り返す段階をさらに含む、請求項１に記載の方法。
【請求項４】
前記取得する段階はデータベースにアクセスする段階を含み、前記データベースは、キーとしてのベンダー名と、前記キーに対応する値フィールドとを有し、前記値フィールドはペアのベクトルを含み、各ペアはウェブページの定義とモデル名のベクトルとを含む、請求項１に記載の方法。
【請求項５】
ＨＴＴＰ通信プロトコルを用いてネットワークに通信可能に結合した被監視デバイスに関する情報を取得するコンピュータ読み取り可能媒体を有するコンピュータプログラムであって、
ウェブページアドレスと、対応する複数のモデル名とを取得する命令と、
前記取得したウェブページアドレスを用いてウェブページにアクセスする命令と、
前記複数のモデル名のうちの少なくとも１つを見つけようと、前記アクセスしたウェブページを解析する命令と、
前記解析する段階において前記モデル名の１つが見つかったとき、前記見つかったモデルを前記被監視デバイスのモデル名として標準化する命令とを有する、
【請求項６】
前記解析する命令は、
前記複数のモデル名の少なくとも１つが見つかるか、前記ウェブページ中のすべてのラインを検索するまで前記ウェブページをラインごとに検索する命令を有する、請求項５に記載のコンピュータプログラム。
【請求項７】
前記データベースは前記ウェブページアドレスと、対応する複数のモデル名とを、ベンダー名と対応させて格納し、前記コンピュータプログラムはさらに、
前記ベンダー名の前記データベース中に格納された複数のウェブページアドレスに対して、前記取得する段階、アクセスする段階、解析する段階を繰り返す命令をさらに含む、請求項５に記載のコンピュータプログラム。
【請求項８】
前記取得する命令はデータベースにアクセスする命令を含み、前記データベースは、キーとしてのベンダー名と、前記キーに対応する値フィールドとを有し、前記値フィールドはペアのベクトルを含み、各ペアはウェブページの定義とモデル名のベクトルとを含む、請求項５に記載のコンピュータプログラム。
【請求項９】
ＨＴＴＰ通信プロトコルを用いてネットワークに通信可能に結合した被監視デバイスに関する情報を取得するシステムであって、
ウェブページアドレスと、対応する複数のモデル名とを取得する手段と、
前記取得したウェブページアドレスを用いてウェブページにアクセスする手段と、
前記複数のモデル名のうちの少なくとも１つを見つけようと、前記アクセスしたウェブページを解析する手段と、
前記解析する手段において前記モデル名の１つが見つかったとき、前記見つかったモデルを前記被監視デバイスのモデル名として標準化する手段とを有するシステム。
【請求項１０】
前記解析する手段は、
前記複数のモデル名の少なくとも１つが見つかるか、前記ウェブページ中のすべてのラインを検索するまで前記ウェブページをラインごとに検索する手段を有する、請求項９に記載のシステム。
【請求項１１】
前記データベースは前記ウェブページと、前記対応する複数のモデル名とをベンダー名と対応させて格納し、前記システムはさらに前記取得する手段と、アクセスする手段と、解析する手段とを繰り返させる手段とをさらに含む、請求項９に記載のシステム。
【請求項１２】
前記取得する手段はデータベースにアクセスする手段を含み、前記データベースは、キーとしてのベンダー名と、前記キーに対応する値フィールドとを有し、前記値フィールドはペアのベクトルを含み、各ペアはウェブページの定義とモデル名のベクトルとを含む、請求項９に記載のシステム。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
（関連出願との相互参照）
この出願は以下の共有に係る同時係属中の米国特許出願に関連している。
１.  第０９／４５３，９３７号、発明の名称「Method  and  System  of  Remote  Diagnostic,  Control,  and  Information  Collection  using  a  Dynamic  Linked  Library  of  Multiple  Formats  and  Multiple  Protocols  with  Intelligent  Formatter」、出願日２０００年５月１７日。
２.  第０９／７５６，１２０号、発明の名称「Method  and  System  of  Remote  Support  of  Device  Using  Email」、出願日２００１年１月９日。
３.  第０９／７８２，０６４号、発明の名称「Method  and  System  of  Remote  Diagnostic,  Control,  and  Information  Collection  using  a  Dynamic  Linked  Library  of  Multiple  Formats  and  Multiple  Protocols  with  Three-Level  Formatting」、出願日２００１年２月１４日。
４.  第０９／９２１，７０７号、発明の名称「Universal  Controller  in  The  Wireless  Networked  Environment」、出願日２００１年８月６日。
５.  第０９／９５３，３５７号、発明の名称「System,  Method,  and  Computer  Program  Product  for  Collecting  and  Sending  Various  Types  of  Information  to  a  Monitor  Using  Email」、出願日２００１年９月１７日。
６.  第０９／９５３，３５８号、発明の名称「Method  and  System  of  Remote  Support  of  Device  Using  Email  Through  Data  Transfer  Module」、出願日２００１年９月１７日。
７.  第１０／８３１，１８７号、発明の名称「Method  and  System  of  Remote  Monitoring  and  Support  of  Devices,  Extracting  Data  from  Different  Types  of  Email  Messages,  and  Storing  Data  According  to  Data  Structures  Determined  by  the  Message  Types」、出願日２００４年４月２６日。
８.  第０９／９５３，３５９号、発明の名称「Method  and  System  for  Remote  Support  of  Device  using  Email  for  Sending  Information  Related  to  a  Monitored  Device」、出願日２００１年９月１７日。
９.  第０９/９７５,９３８号（発明の名称「Method  and  System  of  Remote  Monitoring  and  support  of  Devices,  Including  Handling  Email  Messages  Having  Messages  Types  Specified  Within  the  Email  Message」、出願日２００１年１０月１５日）。
１０.  第１１/１５３,５４３号（発明の名称「Method  and  System  of  Remote  support  of  Device  Using  Email  Based  Upon  POP３  with  Decryption  Capability  Through  Virtual  Function」、２００５年６月１６日出願）
１１.  第１０/１５７,９０５号（発明の名称「Method  and  Apparatus  for  Monitoring  Remote  Devices  Through  a  Local  Monitoring  Station  and  Communication  With  a  Central  Station  supporting  Multiple  Manufacturers」、２００２年５月３１日出願）
１２.  第１０/１５７,９０４号（発明の名称「Method  and  Apparatus  for  Providing  Multiple  Vendor  support  to  Remotely  Monitored  Devices」２００２年５月３１日出願）
１３.  第１０/１５７,９０３号（発明の名称「Method  and  Apparatus  for  Modifying  Remote  Devices  Monitored  by  a  Monitoring  System」、２００２年５月３１日出願）
１４.  第１０/１６２,４０２号（発明の名称「Method  and  System  for  Monitoring  Network  Connected  Devices  and  Displaying  Device  Status」、２００２年６月５日出願）
１５.  第１０/６０６,８６２号（発明の名称「Method  and  System  of  Remote  Position  Reporting  Device」、２００３年６月２７日出願）
１６.  第１１/１８２,８８９号（発明の名称「Method  and  System  of  Remote  Position  Reporting  Device」、２００５年７月１８日出願）
１７.  第１１/２３４,２２４号（発明の名称「Method  and  System  for  Script  Implementation  of  HTTP  to  Obtain  Information  from  Remote  Devices」、２００５年９月２６日出願）
１８.  第０９/９７５,９３５号（発明の名称「Method  and  System  for  Remote  support  of  Device  Using  Email  Based  Upon  Pop３  With  Decryption  Capability  Through  Virtual  Function」、２００１年１０月１５日出願）
１９.  第１０/０６８,８６１号（発明の名称「Method  and  Apparatus  Utilizing  Communication  Means  Hierarchy  to  Configure  or  Monitor  an  Interface  Device」、２００２年２月１１日出願）
２０.  第１０/１４２,９８９号（発明の名称「Verification  Scheme  for  Email  Message  Containing  Information  About  Remotely  Monitored  Devices」、２００２年５月１３日出願）
２１.  第１０/１４２,９９２号（発明の名称「Method  for  Scrambling  Information  about  Network  Devices  That  is  Placed  in  Email  Message」、２００２年５月１３日出願）
２２.  第１０/１５７,９０３号（発明の名称「Method  and  Apparatus  for  Modifying  Remote  Devices  Monitored  by  a  Monitoring  System」、２００２年５月３１日出願）
２３.  第１０/１６２,４０２号（発明の名称「Method  and  System  to  Use  HTTP  and  Html/Xml  for  Monitoring  the  Devices」、２００２年６月５日出願）
２４.  第１０/１６７,４９７号（発明の名称「Method  and  System  of  Remote  Position  Reporting  Device」、２００２年６月１３日出願。この出願は、第０９/５７５,７０２（米国特許第６,４２１,６０８号）の継続出願である）
２５.  第１０/２２５,２９０号（発明の名称「Method  and  System  for  Monitoring  Network  Connected  Devices  with  Multiple  Protocols」、２００２年８月２２日出願）
２６.  第１０/３２８,００３号（発明の名称「Method  of  Accessing  Information  from  Database  to  be  used  to  Obtain  Status  Information  from  the  Web  Pages  of  Remotely  Monitored  Devices」、２００２年１２月２６日出願）
２７.  第１０/３２８,００８号（発明の名称「Method  of  using  Internal  Structure  to  Store  Database  Information  for  Multiple  Vendor  and  Model  support  for  Remotely  Monitored  Devices」、２００２年１２月２６日出願）
２８.  第１０/３２８,０２６号（発明の名称「Method  of  using  Vectors  of  Structures  for  Extracting  Information  from  the  Web  Pages  of  Remotely  Monitored  Devices」、２００２年１２月２６日）
２９.  第１０/３７２,９３９号（発明の名称「Method  and  System  for  Monitoring  Network  Connected  Devices  with  Multiple  Protocols」、２００３年２月２６日出願）
３０.  第１０/４６０,１５０号（発明の名称「Method  for  Efficiently  Storing  Information  used  to  Extract  Status  Information  from  a  Device  Coupled  to  a  Network  in  a  Multi-Protocol  Remote  Monitoring  System」、２００３年６月１３日出願）
３１.  第１０/４６０,１５１号（発明の名称「Method  for  Efficiently  Extracting  Status  Information  Related  to  a  Device  Coupled  to  a  Network  in  a  Multi-Protocol  Remote  Monitoring  System」、２００３年６月１３日出願）
３２.  第１０/４６０,４０４号（発明の名称「Method  for  Parsing  an  Information  String  to  Extract  Requested  Information  Related  to  a  Device  Coupled  to  a  Network  in  a  Multi-Protocol  Remote  Monitoring  System」、２００３年６月１３日出願）
３３.  第１０/４６０,４０８号（発明の名称「Method  and  System  for  Extracting  Vendor  and  Model  Information  in  a  Multi-Protocol  Remote  Monitoring  System」、２００３年６月１３日出願）
３４.  第１０/６７０,５０５号（発明の名称「Method  and  System  for  Extracting  Information  from  Networked  Devices  in  a  Multi-Protocol  Remote  Monitoring  System」、２００３年９月２６日出願）
３５.  第１０/６７０,６０４号（発明の名称「Method  and  System  for  supporting  Multiple  Protocols  Used  to  Monitor  Networked  Devices  in  a  Remote  Monitoring  System」、２００３年９月２６日出願）
３６.  第１０/７６４,４６７号（発明の名称「Method  and  System  for  Determining  the  Type  of  Status  Information  to  Extract  from  Networked  Devices  in  a  Multi-Protocol  Remote  Monitoring  System」、２００４年１月２７日出願）
３７.  第１０/７６４,５２７号（発明の名称「Method  and  System  for  Managing  Protocols  Used  to  Obtain  Status  Information  from  a  Network  Device」、２００４年１月２７日出願）
３８.  第１０/７６４,５６９号（発明の名称「Method  and  System  for  Managing  Vendor  and  Model  Information  in  a  Multi-Protocol  Remote  Monitoring  System」、２００４年１月２７日出願）
３９.  第１０/７６４,５８２号（発明の名称「Method  and  System  for  Initializing  Protocol  Information  Used  to  Extract  Status  Information  from  Networked  Devices」、２００４年１月２７日出願）
４０.  第１０/９２７,１５８号（発明の名称「Method  and  System  for  Using  Abstract  Classes  to  Extract  Status  Information  From  Networked  Devices」、２００４年８月２７日出願）
４１.  第１０/９２７,２５７号（発明の名称「Method  and  System  for  Using  Abstract  Classes  to  Extract  Status  Information  from  Networked  Devices」、２００４年８月２７日出願）
４２.  第１０/９２７,２８３号（発明の名称「Method  of  Initializing  a  Data  Processing  Object  Associated  with  a  Communication  Protocol  Used  to  Extract  Status  Information  Related  to  a  Monitored  device」、２００４年８月２７日出願）
４３.  第１１/０３２,０３９号（発明の名称「Method  and  System  for  Extracting  Information  from  Networked  Devices  Using  Multiple  Implementations  of  Protocol  Access  Functions」、２００５年１月１１日出願）
４４.  第１１/０３２,０１６号（発明の名称「Monitoring  Device  Having  a  Memory  Containing  Data  Representing  Access  Information  Configured  to  be  Used  by  Multiple  Implementations  of  Protocol  Access  Functions  to  Extract  Information  From  Networked  Devices」、２００５年１月１１日出願）
４５.  第１１/０３２,０６３号（発明の名称「Monitoring  Device  Having  a  Memory  Containing  Data  Representing  Access  Information  Configured  to  be  Used  by  Multiple  Implementations  of  Protocol  Access  Functions  to  Extract  Information  From  Networked  Devices」、２００５年１月１１日出願）
４６.  第１１/０３２,０８８号（発明の名称「Method  and  System  for  Extracting  Information  From  Networked  Devices  Using  the  HTTP  Protocol  and  Precondition  Information」、２００５年１月１１日出願）
４７.  第１１/０３２,１９２号（発明の名称「Method  and  System  For  Extracting  Status  Information  From  Networked  Devices  Using  the  SNMP  Protocol」、２００５年１月１１日出願）
４８.  第１１/２３４,３２２号（発明の名称「Method  and  System  for  Use  of  Abstract  Classes  for  Script  Implementation  of  HTTP  to  Obtain  Information  from  Devices」、２００５年９月２６日出願）
４９.  第１１/２３４,３１９号（発明の名称「Database  for  Multiple  Implementation  of  HTTP  to  Obtain  Information  from  Devices」、２００５年９月２６日出願）  
５０.  第１１/２３４,３２３号（発明の名称「Method  and  System  for  Script  Processing  in  Script  Implementation  of  HTTP  to  Obtain  Information  from  Devices」、２００５年９月２６日出願）
５１.  代理人事件整理番号第２８８００８US  (RSID  １-４９４)号（発明の名称「Vendor  Identification  of  Remote  Device  of  Merged  Companies」、本願と同時出願）
５２.  代理人事件整理番号第２８７９７７US  (RSID  １-４９５)号（発明の名称「System  for  Identification  of  Vendor  and  Model  Name  of  Remote  Device  Among  Multiple  Network  Protocols」、本願と同時出願）
５３.  代理人事件整理番号第２８７９７０US  (RSID  １-４９７)号（発明の名称「Data  Used  with  the  HTTP  Protocol  for  Extracting  Information  from  Remote  Devices」、本発明と同時出願）
５４.  代理人事件整理番号第２８８００５US  (RSID  １-４９６)号（発明の名称「System  for  Extracting  Information  from  Remote  Devices  Through  the  HTTP  Protocol」、本願と同時出願）
５５.  代理人事件整理番号第２８８０２１US  (RSID  １-４９３)号（発明の名称「SNMP  Implementation  to  Obtain  Vendor  Information  From  Remote  Devices」、本願と同時出願）
上記の米国特許及び米国特許出願は、ここにその全体を参照援用する。
本発明は著者と出版年ごとに下記の参照文献リストに掲げた参照文献で参照され、記載された様々な技術を含む。
［参考文献リスト］
[１]  Goldfart,  C.,  The  SGML  Handbook.  Clarendon  Press  (１９９０);
[２]  Castro,  E.,  HTML  for  the  World  Wide  Web,  Peachpit  Press,  Berkeley  (１９９６);
[３]  Megginson,  D.,  Structuring  XML  Documents,  Prentice  Hall,  NJ  (１９９８).
参考文献リストに挙げた各参照文献の全内容はここに参照援用する。
【技術分野】
【０００２】
本発明はネットワークに接続されたデバイスの監視に関する。より具体的には、複数のプロトコルを用いてネットワーク接続されたデバイスの遠隔監視をするための方法とシステムとコンピュータプログラム製品とに関する。
【背景技術】
【０００３】
一般的に知られているように、コンピュータシステムはハードウェアとソフトウェアとを含む。ソフトウェアは、コンピュータシステムを構成するハードウェアコンポーネントを動作させ管理するように作られた命令のリストを含む。一般的に、コンピュータシステムは、相互にインターフェイスしている様々なハードウェアコンポーネントやデバイスを含む。コンピュータシステムには、スタンドアロン型とネットワーク型とがある。ネットワーク型のコンピュータシステムでは、区別できる複数のデバイスがネットワークに接続されており、そのデバイス間での通信がそのネットワークを介して可能となっている。
【０００４】
さらに、ハードウェアデバイスを動作させるソフトウェアは、そのハードウェアデバイスがその間で通信し、協力的に機能するように構成されなければならない。さらに、かかる通信を容易にするため、ハードウェアデバイスを監視して、各ハードウェアデバイスを確実に効率的に機能させるように、各ハードウェアデバイスのステータス（status）を知っておくことが望ましい。
【０００５】
この特許出願では、区別できる複数のデバイスを制御、設定、または監視するハードウェア装置を「監視デバイス」と呼び、その監視デバイスにより制御、設定、または監視されるハードウェアデバイスを「被監視デバイス」と呼ぶことにする。
【０００６】
ネットワーク中にあるハードウェアデバイスの場合、そのデバイスをメンテナンス、使用、その他を目的として監視することが望ましい。しかし、ハードウェアデバイスやインターフェイスの製造者が異なる点を考慮すると、監視デバイスが、ネットワークに接続されている他の様々なデバイスと通信することは困難な場合がある。かかる不都合によりネットワーク管理者は、そのネットワークに接続されたデバイスの性能と効率に関する不可欠な情報を得られないことが多い。
【０００７】
簡易ネットワーク管理プロトコル（ＳＮＭＰ、Simple  Network  Management  Protocol）は、今日、データ通信ネットワーク、電気通信システム、及びその他の世界的に到達可能なデバイスにおいてデバイスの監視と管理をするための業界のデファクトスタンダードである。実際に、コンピュータやその関連デバイスを取り扱っている組織はすべて、ローカルエリアネットワークやワイドエリアネットワークを介してかかる装置を集中的に監視、診断、設定できることを期待している。ＳＮＭＰはこうしたインターラクション（interaction）を可能にするプロトコルである。
【０００８】
デバイスがＳＮＭＰリクエストに応答するためには、そのデバイスにＳＮＭＰリクエスト（request）を正しく解釈し、そのリクエストが要求する動作を実行し、ＳＮＭＰリプライ（reply）を生成させるソフトウェアを、そのデバイスに備えることが望ましい。ＳＮＭＰエージェントソフトウェアは、一般的にはネットワークエンティティに常駐（reside）するサブシステムソフトウェアモジュールである。
【０００９】
システムが実装するオブジェクトの集まり（collection  of  objects）は、一般的にＭＩＢ（Management  Information  Base）と呼ばれる。ＭＩＢはデバイスの監視に関する情報を有するデータベースであってもよい。その他のＭＩＢの例としては、２〜３の例を挙げると、イーサネット（登録商標）インターフェイスにフォーカスしたイーサネット(登録商標)ＭＩＢや、８０２．１Ｄブリッジの管理用オブジェクトを規定するブリッジＭＩＢなどがある。
【００１０】
デバイスの監視にＳＮＭＰを使用することは困難である。有効鍵（valid  key）がないと復号が困難な値をプライベートＭＩＢが含むからである。ネットワークに接続された様々なデバイスの監視にＳＮＭＰを使用する会社は、その会社の独自情報として保持されている一意的な識別子／鍵を作っている。結果は大部分、二値または整数値として表示される。このように、ＳＮＭＰを使用すると、監視中のデバイス（「被監視デバイス」）から受信する結果では、ユーザが理解できるように被監視デバイスのステータスをユーザに提供することはできない。
【００１１】
さらに、ＳＮＭＰを使用すると、有効鍵やプライベートＭＩＢへのアクセスなしに被監視デバイスに関する詳細情報を取得して、二値または整数値として取得した結果を復号することは困難である。また、所定のプロトコル（例えば、ＳＮＭＰやＨＴＴＰ／ＨＴＭＬ）は、タイムアウト（time  out）やロストパケット（lost  packet）等の理由によりうまく行かないこともある。また、複数のプロトコルを用いてあるデバイスから取得した情報は、その一部が各プロトコルで重複していることもある。従って、かかる状況においてそのデバイスからのデータの取得（extraction）をうまく管理しないと、時間やメモリの非効率が生じる。プロトコルによってはより多くのリソースを必要とするからである。また、あるプロトコルを用いれば、他のプロトコルを用いるよりも情報の取得に必要な処理とメモリが非常に少なくて済む。さらに、あるプロトコルにより取得した被監視デバイスに関する情報は、他のプロトコルにより取得した情報よりも有用であることもある。
【００１２】
ＳＮＭＰには、エンタープライズオブジェクト識別子（ＯＩＤ、Enterprise  Object  Identifier）とシステム記述（System  Description）を読み出す標準コマンドを有する。しかし、多数のプリンタのＯＩＤは正しくなく、そのベンダーを特定することができない。例えば、本願発明者は、三星社及びブラザー社が一部のモデルにＨＰ社のＯＩＤを使用していることを知っている。また、会社が合併または買収されたとき、一部のマシンでは古いＯＩＤがまだ使用されている。
【００１３】
ベンダーを特定するその他の方法として、システム記述（system  description）を使用する方法がある。しかし、ある場合、本願発明者は、システム記述はベンダー名を含んでいないが、エンタープライズＯＩＤはベンダー名を含んでいることが分かっている。例えば、本願発明者は、コニカミノルタ社の一部のモデルがベンダー名を含まないことを知っている。
【００１４】
多数のデジタルコピー機、プリンタ、及び多機能（ＭＦ）マシンは、ベンダー名をブラウザを用いて取得できるウェブサーバを有する。ＨＴＭＬを使用して取得した情報は人間が読むことができるので、ＨＴＭＬはＳＮＭＰよりも都合がよい。ＳＮＭＰのプライベートＭＩＢ情報とは異なり、ＨＴＭＬにより取得した情報は人間が理解することができる。それゆえ、ＨＴＴＰ通信プロトコルを用いてマシンから意味のある情報を取得することができる。
【００１５】
さらに、マシンのベンダー名及び／またはモデル名は、異なるプロトコルを使用して取得すると、異なることがある。例えば、ＳＮＭＰエンタープライズＯＩＤはミノルタと示されているが、ＨＴＴＰではコニカミノルタと示される。この齟齬の理由はコニカ社とミノルタ社が合併したことにある。いくつかの場合には、ベンダー名及び／またはモデル名が大文字・小文字に関して相違することがある。例えば、ＳＮＭＰでは「ＨＰ」と示されているが、ＨＴＴＰでは「ｈｐ」と示される。他の場合には、あるプロトコルでは会社のイニシァル（例えば、ＨＰ）が使用されているが、他のプロトコルでは会社のフルネームが使用されている。本願発明者は、ベンダー名及び／または製品モデル名が異なる場合の問題があり、一様なベンダー名及び／または製品モデル名を取得する必要性があることを認識した。
【００１６】
ＨＴＴＰ／ＨＴＭＬ処理を用いてマシン（machines）から人間が読める情報を取得（extract）することはできるが、必要な情報を取得するためにブラウザの機能を実行する必要はない。本願の発明者は、ＨＴＴＰ／ＨＴＭＬ処理を用いた情報取得プロセスを簡略化する必要があることを認識した。
【発明の開示】
【課題を解決するための手段】
【００１７】
本発明のシステムと方法とは、ネットワークに接続されたデバイスの監視を可能とすることにより、上記問題に対する解決策を提供するものである。従って、ネットワークに通信可能に結合した区別できるデバイス中の一デバイスを監視する方法を説明する。
【００１８】
本方法は、ハードウェアアクセスモジュールを介して第１のデータベースにアクセスにアクセスする段階を含む。第１のデータベースは複数の通信プロトコルをサポートするように構成されている。第１のデータベースは、被監視デバイスの製造者情報とモデル情報等の様々な情報を取得するために、複数の通信プロトコルにより使用される情報を格納している。通信プロトコルは複数の通信プロトコルから選択され、選択された通信プロトコルを被監視デバイスから状態情報（state  information）を受け取るように構成する。本方法は、さらに、選択された通信プロトコルと第１のデータベースからの情報とを用いて前記被監視デバイスにアクセスする段階と、アクセスしたデバイスから状態情報を受信する段階と、第２のデータベース（DeviceODBC）に受信した状態情報を格納する段階とを含む。状態情報は動的状態情報、準静的状態情報、及び静的状態情報を含む。動的状態情報は、ページカウント、トナーレベル、自動車のオイルレベルやガソリンレベル等の、頻繁に変化する状態情報を言う。準静的状態情報は、頻繁ではないが変化する状態情報を言い、ＩＰアドレス、時間帯（time  zone）、被監視装置のオプションなどである。静的状態情報は、マシンの寿命にわたって変化しない状態情報を言う。「ステータス（status）」という言葉を使うとき、ステータスとは本願で規定する状態情報を言う。
【００１９】
他の実施形態では、本発明は、ネットワークに通信可能に結合された区別できるデバイス間の一デバイスを監視する方法を提供する。複数の通信プロトコルを使用して被監視デバイスから情報を読み出し得る。例えば、ＳＮＭＰプロトコルを最初に選択して被監視デバイスにアクセスし、ＳＮＭＰを用いて効率的に読み出せるように設定されたデバイス情報を取得する。その後、デバイスが別のプロトコルをサポートしているとき、ＨＴＴＰプロトコルとＦＴＰプロトコルを選択して、ＳＮＭＰプロトコルを用いて効率的に読み出せない情報を取得する。プロトコルの選択は、データベースに格納されているサポート情報と共に、プロトコルマネージャにより実行される。
【００２０】
本発明では、監視システム（monitoring  system）により、ネットワーク（例えば、ＬＡＮやＷＡＮ）に接続された少なくとも１つのデバイス（被監視デバイス、monitored  device）の監視が可能となる。被監視デバイスは一意的なＩＰアドレスを有するように構成されている。被監視デバイスに割り当てられたＩＰアドレスと、その被監視デバイスのベンダー／製造者の詳細情報はデータベースに格納される。ネットワークをスキャンしてデバイスに問い合わせをすることにより、そのデバイスのＩＰアドレスを取得することができる。かかる方法は既知である。それゆえ、監視されるデバイスのＩＰアドレスはすでに取得され、データベースに格納されているものと仮定する。
【００２１】
本発明は、被監視デバイスから受信したＨＴＭＬ情報から必要な情報をいかに取得するか特定するものである。被監視デバイスのウェブページロケーションに（すなわち、ＩＰアドレス及び特定ポートにより）アクセスすると、被監視デバイスに対応するウェブページが得られる。ウェブページ中の情報には様々な状態情報が含まれている。例えば、カラープリンタのウェブページには、トナーレベルが「黒１００％」などと示されている。ストリングマッチングを用いてウェブページから取得した必要情報やパラメータ値はデータベースに格納される。
【００２２】
本発明は、ここに説明するように、被監視デバイスのベンダーと、監視システムによりサポートされるデバイスモデルを特定するものでもある。被監視デバイスのベンダーは被監視デバイスに関する情報をベンダー固有のやり方で提供するので、本発明によりベンダーの識別情報（identification）と被監視デバイスのモデル情報とにより被監視デバイスの動作状態を決定するができる。
【００２３】
本発明の一態様によると、ＨＴＴＰ通信プロトコルを用いて、ネットワークに通信可能に結合した被監視デバイスに関する情報を取得する方法及びコンピュータプログラム製品を提供する。本方法は、前記被監視デバイスのベンダー及びモデル情報を第１のメモリから読み出す段階と、前記被監視デバイスから前記ウェブページによりベンダーとモデルを判断する段階と、前記デバイス状態情報を取得する段階と、前記ベンダーとモデル情報に関連して、前記アクセスする段階で取得した前記デバイス情報を第２のメモリに格納する段階とを有する。
【００２４】
本発明の他の態様によると、様々なプロトコルからベンダー及びモデル情報を取得して、標準化されたベンダー及びモデル情報に同期させる方法、システム、及びコンピュータプログラム製品が提供される。
【００２５】
本発明の他の実施形態では、ＳＮＭＰ通信プロトコルを用いてネットワークに通信可能に結合された被監視デバイスに関する情報を取得する方法は、前記被監視デバイスから第１の情報を取得するためにＳＮＭＰ通信プロトコルを用いて前記被監視デバイスにアクセスする段階と、前記取得した第１の情報からベンダー情報の取得を試みる段階と、前記第１の情報から前記ベンダー情報が取得されたとき、前記ベンダー情報を記憶デバイスに格納する段階と、前記ベンダー情報が前記第１の情報から取得できなかったとき、前記ＳＮＭＰ通信プロトコルを用いて前記被監視デバイスにアクセスして、前記被監視デバイスから前記第１の情報とは異なる第２の情報を取得する段階と、前記第１の情報と第２の情報の一方からベンダー情報の取得を試みる段階と、前記第２の情報から前記ベンダー情報が取得されたとき、前記ベンダー情報を前記記憶デバイスに格納する段階とを有する。
【００２６】
本発明の他の実施形態では、被監視デバイスのベンダー名を変換する方法は、前記被監視デバイスから情報を取得するために第１の通信プロトコルを用いて前記被監視デバイスにアクセスする段階と、前記被監視デバイスから取得した前記情報に基づいて前記被監視デバイスのベンダー名を決定する段階と、前記被監視デバイスの標準化ベンダー名を前記決定したベンダー名を用いて決定する段階とを有する。
【００２７】
本発明の他の実施形態では、被監視デバイスから取得した情報が使用する通信プロトコルに応じて変わる、被監視デバイスの標準ベンダー名と標準モデル名を決定する方法は、前記被監視デバイスから情報を取得するために第１の通信プロトコルを用いて前記被監視デバイスにアクセスする段階と、前記被監視デバイスから取得した前記情報にから前記被監視デバイスのベンダー名とモデル名を決定する段階と、前記被監視デバイスの標準化ベンダー名を、前記ベンダー名を用いて決定する段階と、前記被監視デバイスの標準化モデル名を、前記標準化ベンダー名と決定したモデル名を用いて決定する段階とを有する。
【００２８】
本発明の他の実施形態では、ＨＴＴＰ通信プロトコルを用いてネットワークに通信可能に結合された被監視デバイスに関する情報を取得する方法は、ウェブページアドレスと、対応する複数のモデル名とを取得する段階と、前記取得したウェブページアドレスを用いてウェブページにアクセスする段階と、前記複数のモデル名のうちの少なくとも１つを見つけようと、前記アクセスしたウェブページを解析する段階と、前記解析する段階において前記モデル名の１つが見つかったとき、前記見つかったモデルを前記被監視デバイスのモデル名として標準化する段階を有する。
【００２９】
本発明の他の実施形態では、ＨＴＴＰ通信プロトコルを用いてネットワークに通信可能に結合された被監視デバイスに関する情報を取得する方法は、前記被監視デバイスのベンダー名を第１のメモリから読み出す段階と、データベースにアクセスして前記被監視デバイスの前記ベンダー名に対応するベクトルであって、取得する前記情報と関連するウェブページアドレスと少なくとも１つのキーストリングとを含むベクトルを取得する段階と、前記取得したウェブページアドレスを用いて前記ウェブページから１行を取得する段階と、前記行を解析して前記行に前記少なくとも１つのキーストリング中の第１のキーストリングが含まれているか判断する段階と、前記少なくとも１つのキーストリング中の１つのキーストリングが見つかるまで、前記少なくとも１つのキーストリング中の各キーストリングに対して前記取得する段階と前記解析する段階とを繰り返す段階と、前記少なくとも１つのキーストリングの最後を含むと決定された行に続く前記ウェブページの行から前記情報を取得する段階とを有する。
【発明を実施するための最良の形態】
【００３０】
添付した図面を参照して以下の詳細な説明を読めば、本発明をよりよく理解できるであろう。
【００３１】
図１は、様々なデバイスと、そのデバイスの動作を監視、診断、及び制御するコンピュータとを有するシステムを示す。具体的に、図１は、第１のネットワーク１６（例えば、ローカルエリアネットワーク（ＬＡＮ）など）を含み、これにはコンピュータワークステーション１７、１８、２０、２２が接続されている。これらのワークステーションはいかなるタイプのコンピュータでもよく、例えば、パーソナルコンピュータ、Ｕｎｉｘ(登録商標)ベースコンピュータ、Ｌｉｎｕｘベースコンピュータ、アップル社のマッキントッシュなどである。また、ネットワーク１６には、デジタル画像形成装置２４、ファクシミリマシン２８、プリンタ３２も接続されている。当業者には言うまでもなく、デジタルコピー機／プリンタ／多機能機（ＭＦ）２４とファクシミリ機２８の２つ以上のコンポーネントは結合して一体的な「画像形成装置」となる。例えば、コピー機／プリンタ／ＭＦ２４、ファクシミリ機２８、プリンタ３２、ワークステーション１７、１８、２０、２２は、マシンや被監視装置と呼ばれることもある。いくつかの構成では、１つ以上のワークステーションはビジネスオフィス機器になることもある。また、いかなるネットワークビジネスオフィス機器／デバイスをネットワーク１６に接続してもよい。また、ワークステーション１７、１８、２０、２２、及びオフィス機器２７のいずれかが、ネットワーク１６上の被監視デバイスを調べて（poll）、集めたデータを監視デバイス（monitoring  device）に送ってもよい。
【００３２】
かかるビジネスオフィス機器の一例としては、株式会社リコーのeCabinet（登録商標）がある。また、ファクシミリサーバ（図示せず）をネットワーク１６に接続して、（携帯または固定）電話接続、ケーブル接続、または無線接続をしてもよい。デジタルコピー機／プリンタ／ＭＦ２４、ファクシミリ機２８、プリンタ３２はそれぞれ、ネットワーク１６に接続されているのに加えて、（携帯または固定）電話、ケーブル、及び／または無線による接続２６、３０、３４を有していてもよい。以下に説明するように、被監視デバイス２４、２８、３２は、ネットワーク１６を介してインターネット等により、または直接的に（携帯または固定）電話、無線、またはケーブル接続により、リモート監視、診断、制御ステーション（監視デバイスとも呼ぶ）と通信する。
【００３３】
他のビジネス環境の例では、被監視デバイスには、多機能画像化デバイス、スキャナ、プロジェクタ、会議システム、シュレッダー（shredder）等のデバイスが含まれる。他のアプリケーションでは、ネットワーク１６はホームネットワークであってもよい。この場合、被監視デバイスは、（電気、ガス、水道の）メータや、電子レンジ、洗濯機、乾燥機、食器洗い機、ホームエンターテイメントシステム、冷蔵庫、炊飯器、ヒータ、空調機、温水器、セキュリティカメラ等である。
【００３４】
図１において、ワイドエリアネットワーク（ＷＡＮ）（例えば、インターネットまたはその後継システム）を参照数字１０で一般的に示した。ＷＡＮ１０は、プライベートＷＡＮでも、パブリックＷＡＮでも、ハイブリッドＷＡＮでもよい。ＷＡＮ１０は、相互接続された複数のコンピュータとルータ（参照数字１２Ａ−１２Ｉで示した）を含む。ＷＡＮを介した通信方法は、ＩＥＴＦ（Internet  Engineering  Task  Force）（www.ietf.org/rfc.html）で入手できる一連のＲＦＣ（Request  for  Comments）で知ることができる。その文書には、ＲＦＣ８２１「Simple  Mail  Transfer  Protocol」、ＲＦＣ８２２「Standard  for  the  Format  of  ARPA  Internet  Text  Message」、ＲＦＣ９５９「File  Transfer  Protocol  (FTP)」、ＲＦＣ２０４５「Multipurpose  Internet  Mail  Extensions  (MIME)  Part  One:  Format  of  Internet  Message  Bodies」、ＲＦＣ１８９４「An  Extensible  Message  Format  for  Delivery  Status  Notifications」、ＲＦＣ１９３９「Post  Office  protocol  −  Version  ３」、ＲＦＣ２０６８「Hypertext  Transfer  Protocol  −  HTTP/１.１」、及びＲＦＣ２２９８「An  Extensible  Message  Format  for  Message  Disposition  Notifications」等がある。これらの参照文献の内容はここに参照援用する。
【００３５】
ＴＣＰ／ＩＰ（Transmission  Control  Protocol  /  Internet  Protocol）に関係する通信は、W.  R.  Stevens著「TCP/IP  Illustrated」、Vol.  １,  The  Protocols（Addison-Wesley  Publishing  Company,  １９９４）に記載されている。この文献の内容はここにすべて参照援用する。Comer及びStevens著「Internetworking  with  TCP/IP」の第１巻乃至第３巻もここにその全体を参照援用する。
【００３６】
引き続き図１を参照して、ファイヤウォール５０ＡがＷＡＮ１０とネットワーク１６の間に接続されている。ファイヤウォールは、そのファイヤウォールの一方側にあるコンピュータのうち許可されたものだけに、そのファイヤウォールの反対側にあるネットワーク、コンピュータ、個別パーツ（individual  parts）等にアクセスさせるデバイスである。ファイヤウォールは既知の市販されているデバイス及び／またはソフトウェアである。同様に、ファイヤウォール５０Ｂ、５０Ｃは、ＷＡＮ１０をネットワーク５２とワークステーション４２から分離している。ファイヤウォールに関するさらに詳細事項は、W.R.Cheswick及びS.M.Bellovin著「Firewalls  and  Internet  Security」（１９９４,  AddisonWesley  Publishing）と、D.  B.  Chapman及びE.  D.  Zwicky著「Building  Internet  Firewalls」（１９９５,  O'Reilly  &  Associates,  Inc）とに記載されている。これらの参照文献の内容はすべてここに参照援用する。
【００３７】
ネットワーク５２は従来のネットワークであり、複数のワークステーション５６、６２、６８及び７４を含んでいる。これらのワークステーションは、１つの会社の異なる部所（例えば、営業、受注処理、経理、請求、マーケティング、製造、設計エンジニアリング、顧客サービス等の部所）に分散して配置されていてもよい。ネットワーク５２を介して接続されたワークステーションに加えて、ネットワーク５２に直接接続されていないワークステーション４２もある。ワークステーション４２に接続されたディスク４６に格納されたデータベース内の情報は、ネットワーク５２に直接接続されたワークステーションにより、ＷＡＮ１０上でバーチャルプライベートネットワーク（ＶＰＮ）等の適当な暗号とプロトコルを用いて、共有されてもよい。また、ワークステーション４２は、プライベートネットワークと直接接続されていてもよく、ディスク４６中のデータベースはプライベートネットワーク４４を通じてアクセスできる。本発明により使用されるケーブルネットワークは、一般的にはテレビジョン番組を搬送するために使用されるケーブルネットワークや、一般的にはコンピュータ等で使用されるデジタルデータの高速通信を提供するケーブルや、その他の好ましいタイプのケーブルを用いて実施することができる。
【００３８】
他の実施形態では、ワークステーション４２は、ラップトップコンピュータ、ＰＤＡ、パームトップコンピュータ、ネットワーク機能を有する携帯電話などである。これらのデバイスは、ディスク４６に格納されたデータベースに格納された情報にアクセスするために使用できる。
【００３９】
デジタルコピー機／プリンタ／ＭＦ２４、オフィス機器２７、ファクシミリ機２８、またはプリンタ３２に関する情報は、それぞれ、ディスク４６、５４、５８、６４、７０及び７６に格納された１つ以上のデータベースに格納できる。既知のデータベースには、（１）マイクロソフト、ＩＢＭ、及びオラクルのデータベース、（２）その他のリレーショナルデータベース、及び（３）非リレーショナルデータベース（オブジェクト指向データベースを含む）がある。営業、受注処理、経理、請求、カスタマーサービス、マーケティング、製造、及びエンジニアリングの各部門は、自部門のデータベースを有し、または１つ以上のデータベースを共有している。データベースを格納するために使用されるディスクは、それぞれハードディスクや光ディスク等の不揮発性メモリである。あるいは、データベースは、固体メモリデバイス及び／または半導体メモリデバイスを含むいかなる記憶デバイスに格納してもよい。例えば、ディスク６４にはマーケティングのデータベースが格納され、ディスク５８には製造のデータベースが格納され、ディスク７０にはエンジニアリングのデータベースが格納され、ディスク７６にはカスタマーサービスのデータベースが格納されている。あるいは、ディスク５４と４６に、上記のデータベースのうちの１つ以上のデータベースが格納されてもよい。
【００４０】
ワークステーション５６、６２、６８、７４、及び４２は、ＷＡＮ１０に接続されているのに加えて、監視、診断、及び／または制御されるマシン／デバイスへのセキュアな接続を提供するプライベートネットワークへの接続を含んでいてもよい。また、通信媒体のうちの１つが正しく動作していないとき、その他のものが予備として自動的に通信に使用される。
【００４１】
本発明の特徴は、マシンとそのマシンの診断・制御をするコンピュータ／監視システムとの間で、「ストア・アンド・フォワード（store-and-forward）」モードの通信（例えば、インターネット電子メール）または伝送を使用することである。あるいは、送信されるメッセージは、ＦＴＰやＨＴＴＰ（Hyper  Text  Transfer  Protocol）等の直接的、エンド・ツー・エンドの接続（例えば、最終宛先とのソケット接続を用いる）をする通信モードを用いて実施してもよい。
【００４２】
図２は、図１に示したデジタルコピー機／プリンタ２４の機械的レイアウトを示す。図２において、１０１はスキャナのファンであり、１０２はレーザプリンタで使用するポリゴンミラーであり、１０３はレーザ（図示せず）からの光を平行にするために使用するＦθレンズを指す。参照数字１０４はスキャナからの光を検出するセンサを指す。参照数字１０５はスキャナからの光をセンサにフォーカスするためのレンズを指し、参照数字１０６は感光ドラム１３２上の画像を消去するために使用する消去ランプ（quenching  lamp）を指す。帯電コロナユニット１０７と現像ローラ１０８がある。参照数字１０９はスキャンする文書を照射するために使用するランプを指し、１１０、１１１、１１２は光をセンサ１０４上に反射するミラーを指す。ドラムミラー１１３は、ポリゴンミラー１０２からの光を感光ドラム１３２に反射するように設けられている。ファン１１４を使用してデジタル画像形成装置の帯電エリアを冷却し、第１の紙送りローラ１１５を使用して第１のペーパーカセット１１７から用紙を送る。参照数字１１６は手差しテーブルを指している。同様に、第２の紙送りローラ１１８は第２のカセット１１９とともに使用される。参照数字１２０はリレーローラを指し、１２１はレジストレーションローラを指し、１２２は画像濃度センサを指し、１２３は転送／分離コロナユニットを指す。参照数字１２４はクリーニングユニットを指し、１２５はバキュームファンを指し、１２６は転送ベルトを指し、１２７は圧力ローラを指し、１２８は出口ローラを指す。ホットローラ１２９は用紙にトナーを定着（fix）するために使用され、１３０は排気ファンを指し、主モータ１３１はデジタルコピー機／プリンタ２４を駆動するために使用される。
【００４３】
図３は、図２のデジタルコピー機／プリンタ／ＭＦ２４の電子的コンポーネントを示すブロック図である。ＣＰＵ１６０は本装置のコントローラとして動作するマイクロプロセッサである。ランダムアクセスメモリ（ＲＡＭ）１６２は、デジタルコピー機／プリンタ／ＭＦ２４の動的状態データ等の動作パラメータを含む動的に変化する情報を格納する。不揮発性メモリ（例えば、読出専用メモリ（ＲＯＭ）１６４やフラッシュメモリ）は、デジタルコピー機／プリンタ／ＭＦを動作させるために使用されるプログラムと、コピー機／プリンタ／ＭＦ２４を記述する静的状態データ（例えば、本装置のモデル名、モデルナンバ、シリアルナンバ、及びデフォルトパラメータ）を格納する。また、フラッシュメモリやハードディスク等の不揮発性メモリの一部は、動的状態データや準静的状態データを格納してもよい。
【００４４】
マルチポートネットワークインターフェイス１６６が設けられており、デジタルコピー機／プリンタ／ＭＦ２４は少なくとも１つの通信ネットワークにより外部デバイスと通信することができる。参照数字１６８は無線または携帯電話のネットワークを表し、参照数字１７０は１６８のネットワークとは異なる種類のネットワークを表す。マルチポートネットワークインターフェイスの詳細は図４を参照して説明する。インターフェイスコントローラ１７２は、操作パネル１７４をシステムバス１８６に接続するために使用される。操作パネル１７４は、デジタルコピー機／プリンタ／ＭＦ２４にあるような標準的な入出力デバイスを含み、それにはコピーボタンや、コピー枚数、拡大／縮小、明暗等の画像形成装置の動作を制御するためのキーが含まれる。また、操作パネル１７４には液晶ディスプレイが含まれてもよく、ユーザにデジタルコピー機／プリンタ／ＭＦ２４のパラメータやメッセージを表示する。
【００４５】
ローカル接続インターフェイス１７１は、ＲＳ２３２、パラレルプリンタポート、ＵＳＢ、ＩＥＥＥ１３９４等のローカルポートによる接続である。ファイヤワイヤ（ＩＥＥＥ１３９４）は、Wickelgren,  I著「The  Facts  About  “FireWire”」（IEEE  Spectrum,  April  １９９７,  Vol.  ３４,  Number  ４,  pp.  １９-２５）に記載されている。この文献の全内容はここに参照援用する。好ましくは、エラー検出と再送信を含む「信頼性の高い」通信プロトコルを使用する。
【００４６】
記憶装置インターフェイス１７６は記憶デバイスをシステムバス１８６に接続する。例えば、記憶デバイスには、フラッシュメモリ１７８やディスク１８２が含まれる。フラッシュメモリ１７８は従来のＥＥＰＲＯＭ（Electrically  Erasable  Programmable  Read  Only  Memory）で置き換えることもできる。ディスク１８２はハードディスクドライブ、光ディスクドライブ、及び／またはフロッピー(登録商標)ディスクドライブ等である。別のメモリデバイスを接続１８０によりデジタルコピー機／プリンタ／ＭＦ２４に接続してもよい。フラッシュメモリ１７８は、デジタルコピー機／プリンタ／ＭＦ２４のパラメータ（その装置２４の寿命中に頻繁には変化しないもの）を記述する準静的状態データを格納するために使用される。かかるパラメータには、例えば、デジタルコピー機／プリンタ／ＭＦ２４のオプションや設定が含まれる。オプションインターフェイス１８４により、外部インターフェイス等の追加的ハードウェアをデジタルコピー機／プリンタ／ＭＦ２４に接続することができる。クロック／タイマー１８７は時間と日付の両方の経過を追い、経過時間の計測もする。
【００４７】
図３は、デジタルコピー機／プリンタ／ＭＦ２４を構成する様々なセクションも示している。参照数字２０２はソータを指し、デジタルコピー機／プリンタ／ＭＦ２４の出力をソートするために使用するセンサとアクチュエータを含む。両面印刷器（duplexer）２００により両面印刷動作（duplex  operation）の実行が可能である。両面印刷器２００は従来のセンサとアクチュエータとを含む。大容量トレイユニット１９８が設けられ、用紙トレイは多数の用紙を保持できる。両面印刷器２００と同様に、トレイユニット１９８も従来のセンサとアクチュエータとを含む。
【００４８】
紙送りコントローラ（paper  feed  controller）１９６は、デジタル画像形成装置に用紙を送る動作を制御するために使用される。スキャナ１９４は、デジタルコピー画像形成装置に画像をスキャンするために使用され、光源、鏡等の従来のスキャナ要素が含んでいる。また、スキャナセンサが使用される。例えば、ホームポジションセンサはスキャナがホームポジションにあるかどうか判断し、ランプサーミスタはスキャナランプが正しく動作していることを確認する。プリンタ／イメージャ１９２は、デジタルコピー画像形成装置の出力を印刷するものであり、従来のレーザ印刷メカニズム、トナーセンサ、及び画像濃度センサ等を含む。フューザ１９０は、高温ローラを用いてページ上でトナーを溶かすために使用され、出口センサ、フューザ１９０がオーバーヒートしていないか確認するサーミスタ、オイルセンサ等を含む。また、オプションユニットインターフェイス１８８があり、自動文書フィーダ、異なる種類のソータ／コレータ（sorter/collator）、デジタル画像形成装置に追加できるその他の要素を接続するために使用される。他の要素には、本装置の位置を特定するためのＧＰＳユニットが含まれる。
【００４９】
図４は、マルチポートネットワークインターフェイス１６６の詳細を示す図である。デジタル画像形成装置は、ＬＡＮ１７０とつながっている携帯電話インターフェイス２２７、無線インターフェイス２２８、またはイーサネット（登録商標）インターフェイス２３０により外部デバイスと通信することができる。その他のインターフェイスとしては、デジタルサブスクライバライン（ＤＳＬ）（元のＤＳＬ、コンセントリックＤＳＬ、ＡＤＳＬ等）があるが、これに限定はされない。
【００５０】
ＣＰＵ、その他のマイクロプロセッサや回路は、デジタル画像形成装置の各センサの状態を監視する監視プロセスを実行し、シーケンシングプロセス（sequencing  process）を使用して、デジタル画像形成装置を制御し動作させるために使用されるコードの命令を実行する。また、（１）デジタル画像形成装置の全体動作を制御する中央システム制御プロセスと、（２）デジタル画像形成装置に接続された外部デバイスと信頼性の高い通信を確保するために使用される通信プロセスとがある。システム制御プロセスは、静的状態メモリ（例えば、図３のＲＯＭ１６４）、準静的状態メモリ（例えば、フラッシュメモリ１７８またはディスク１８２）、または動的状態メモリ（例えば、揮発性または不揮発性メモリ（例えば、ＲＡＭ１６２、フラッシュメモリ１７８、またはディスク１８２等））中のデータ記憶を監視及び制御する。また、静的状態メモリは、ＲＯＭ１６４以外の不揮発性メモリ等のデバイスであり、フラッシュメモリ１７８やディスク１８２が含まれてもよい。
【００５１】
デジタル画像形成装置に関して詳細を上記したが、本発明は次に挙げるその他のビジネスオフィスマシンやデバイスにも同様に適用することができる：アナログコピー機、ファクシミリマシン、スキャナ、プリンタ、ファクシミリサーバ、プロジェクタ、テレビ会議機器、シュレッダ、その他のビジネスオフィスマシン、ビジネスオフィス機器、その他の機器（例えば、電子レンジ、ＶＣＲ、ＤＶＤ、デジタルカメラ、デジタルビデオ、携帯電話、パームトップコンピュータ）。また、本発明は、ストア・アンド・フォワードまたはダイレクトコネクションベースの通信を用いて動作するその他のタイプのデバイスも含み得る。かかるデバイスには、（ガス、水道、電気等を含む）メータシステム、自動販売機、動作中の監視やリモート診断が必要な任意のメカニカルデバイス（例えば、自動車、オートバイ、洗濯機、乾燥機等）が含まれる。特殊目的のマシン及びコンピュータに加えて、被監視デバイス及び／または被制御デバイス（controlled  device）である汎用コンピュータを監視、制御、及び診断するために本発明を使用することができる。
【００５２】
図５は、本発明を示す別のシステム図であり、異なるデバイスとサブシステムがＷＡＮ１０に接続されている。しかし、これらのデバイスやサブシステムがすべて本発明の一部である必要はない。図５に示した各コンポーネントやサブシステムは、それぞれが本発明の一部である。さらに、図１に示した要素を図５に示したＷＡＮ１０に接続してもよい。図５において、イントラネット２６０−１に接続されたファイヤウォール５０−１が示されている。イントラネット２６０−１に接続されたサービスマシン２５４は、データベースフォーマットで格納されたデータ２５６を含むか、またはデータ２５６が接続されている。データ２５６は、履歴情報、実行情報、故障情報、その他の情報を含む。その他の情報には、被監視デバイスの動作や故障や設定に関する統計情報、どのコンポーネントまたはオプション機器が被監視デバイスに含まれているか等の設定情報が含まれる。サービスマシン２５４は、被監視デバイスにデータ送信を要求するデバイスまたはコンピュータとして、または被監視デバイスにリモート制御及び／またはリモート診断テストを実行するように要求するデバイスまたはコンピュータとして実施され得る。サービスマシン２５４は、いかなる種類のデバイスでもよいが、好ましくは汎用コンピュータ等のコンピュータ化されたデバイスを用いて実施される。また、サービスマシン２５４は、請求、経理、サービス処理、部品トラッキング及びレポート等を含む様々なデータベースを有するネットワーク上の複数のコンピュータにより構成され得る。
【００５３】
図５の他のサブシステムには、ファイヤウォール５０−２、イントラネット２６０−２、及びプリンタ２６２が接続されている。このサブシステムにおいて、プリンタ２６２（及び同様にコピー機２８６）が電子的メッセージを送受信する機能は、（１）回路、（２）マイクロプロセッサ、（３）プリンタ２６２に含まれるか、または取り付けられたその他のタイプのハードウェア（すなわち、別の汎用コンピュータを使用せずに）により実行される。
【００５４】
別のタイプのサブシステムには、インターネットサービスプロバイダ２６４の使用が含まれる。このインターネットサービスプロバイダは任意のタイプのインターネットサービスプロバイダ（ＩＳＰ）でよく、アメリカオンライン、イーサリンク、ニフティサーブ社等の既存の会社を含む。このサブシステムにおいて、コンピュータ２６６はデジタルまたはアナログのモデムによりＩＳＰ２６４に接続されている（このモデムは、例えば、電話回線用モデム、ケーブルモデム、ＡＤＳＬモデム、フレームリレー通信を使用するモデム、無線周波数を使用するワイヤレスモデム、光ファイバモデム、赤外線を使用するモデム等がある）。さらに、ビジネスオフィスデバイス２６８はコンピュータ２６６に接続されている。ビジネスオフィスデバイス２６８（または、図５に示した他のいずれかのデバイス）の替わりとして、他の種類のマシンを監視または制御してもよい。例えば、デジタルコピー機、いずれかのタイプの機器、セキュリティシステム、（電気メータ、水道メータ、ガスメータ等の）ユーティリティメータ、ここで説明するその他の任意のデバイスを監視または制御してもよい。
【００５５】
図５に示したように、ネットワーク２７４に接続されたファイヤウォール５０−３がある。ネットワーク２７４はいかなるタイプのコンピュータネットワーク（例えば、イーサネット（登録商標）またはトークンリングネットワーク等）として実施してもよい。ネットワークを管理するために使用されるネットワーキングソフトウェアには、ノベル社やマイクロソフト社が市販しているソフトウェアを含む所望のいかなるネットワーキングソフトウェアが含まれる。ネットワーク２７４は、必要に応じてイントラネットとして実施してもよい。ネットワーク２７４に接続されたコンピュータ２７２を使用して、ビジネスオフィスデバイス２７８から情報を取得し、ネットワークに接続された様々なマシンで生じた問題を示すレポートや、ネットワーク２７４に接続されたデバイスの月間使用レポートを生成することができる。この実施形態では、コンピュータ２７６はビジネスオフィスデバイス２７８とネットワーク２７４との間に接続されている。このコンピュータは、ネットワークから通信を受信して、ビジネスオフィスデバイス２７８に適当なコマンド、データ、その他の情報を転送する。
【００５６】
ビジネスオフィスデバイス２７８とコンピュータ２７６との間の通信を行うのは、有線でも無線でもよく、例えば、無線通信周波数による接続、電気的接続、及び光による接続（例えば、赤外線接続や光ファイバ接続）で行うことができる。同様に、図５に示した様々なネットワークやイントラネットは所望のいかなる方法で確立してもよく、例えば、無線周波数ネットワーク等の無線ネットワークを使用してもよい。ここに説明した無線通信は、（ワールドワイドウェブサイトwww.bluetooth.comから入手できる）ブルートゥースの仕様書で開示された、周波数ホッピング無線技術等の拡散コードと周波数ホッピングの技術を使用する技術を含む拡散スペクトル技術を用いて行うことができる。上記仕様書はここに参照援用する。
【００５７】
図５に示した他のサブシステムには、ファイヤウォール５０−４、イントラネット２６０−４、それに接続されたコンピュータ２８２、ビジネスオフィス機器２８５、及びコピー機２８６が含まれる。コンピュータ２８２を使用して、レポートを作成し、診断または制御の手続を要求することもできる。これらの診断及び制御の手続は、ビジネスオフィス機器２８５やコピー機２８６や図５に示したその他のいずれかのデバイスに対して行うことができる。図５には複数のファイヤウォールを示したが、ファイヤウォールは備えることが好ましいが、任意的な機器であり、本発明は所望によりファイヤウォールなしでも機能する。ネットワークされた機器の監視と制御の場合、サービスマシン２５４の替わりにどのコンピュータ（２６６、２７２、または２８２）を使用することもできる。また、いずれかのコンピュータがサービスマシン２５４にアクセスして、ウェブを通じて必要なデバイス情報や使用情報を読み出すことができる。
【００５８】
図６Ａは、一般的な電子メール交換システムに接続されたデバイス／機器３００を示す。このシステムは、コンポーネント３０２、３０４、３０６、３０８、３１０、３１２、３１４、３１６及び３１８を含み、従来のやり方で実施することができ、上記のStevensによる文献の図２８．１から受け入れたものである。コンピュータインターフェイス３０２は、ここに説明するアプリケーションユニットまたはデバイス／機器３００のいずれともインターフェイスしている。図６Ａではデバイス／機器３００が送信側であるとしたが、送受信機能は図６Ａと逆であってもよい。さらに、必要に応じて、ユーザはデバイス／機器３００とインターフェイスする必要は必ずしもない。コンピュータインターフェイス３０２はメールエージェント３０４とインターフェイスしている。Ｕｎｉｘ(登録商標)用によく使われているメールエージェントにはバークレーメール（Berkeley  Mail）がある。ウィンドウズ(登録商標)ファミリーのオペレーティングシステム用のメールエージェントには、マイクロソフト社のアウトルック及びアウトルックエクスプレスがある。コンピュータインターフェイス３０２の要求に応じて、メールエージェント３０４は、送信すべき電子メールメッセージを生成して、必要に応じて、そのメッセージをキュー３０６に送る。送信すべきメールはメッセージトランスファエージェント（ＭＴＡ）３０８に転送される。Ｕｎｉｘ(登録商標)用に一般的なＭＴＡはSendmailである。一般的に、メッセージトランスファエージェント３０８と３１２は、ＴＣＰ／ＩＰ接続３１０を用いて通信する。とりわけ、メッセージトランスファエージェント３０８と３１２の間の通信が行われるネットワークのサイズは問わない（例えば、ＷＡＮでもＬＡＮでもよい）。さらに、メッセージトランスファエージェント３０８と３１２はいかなる通信プロトコルを使用してもよい。本発明の一実施形態では、図６Ａの要素３０２と３０４は、アプリケーションユニットの使用を監視するライブラリにある。
【００５９】
電子メールメッセージは、メッセージトランスファエージェント３１２からユーザメールボックス３１４に格納され、メールエージェント３１６に転送され、端末３１８のユーザに最終的に送信される。端末３１８は受信端末として機能する。
【００６０】
この「ストア・アンド・フォワード」プロセスにより、送信メールエージェント３０４は、メール受信者との直接接続が確立されるまで待つ必要がなくなる。ネットワーク遅延により、通信にはかなり長い時間がかかり、その間アプリケーションは応答しない。かかる応答遅延は、一般的にアプリケーションユニットのユーザには受け入れがたいことがある。電子メールをストア・アンド・フォワードプロセスとして使用することにより、失敗後の再送信の試行は一定時間（例えば、３日間）自動的に行われる。別の実施形態では、アプリケーションは、通信要求を１つ以上の別々のスレッド（threads）に送ることにより、待ちを回避することができる。これらのスレッドは、受信端末３１８との通信を制御でき、一方、アプリケーションはユーザインターフェイスに対してまた応答できる。さらに別の実施形態では、ユーザは継続する前に通信を完了することを望む場合、受信端末との直接通信を使用する。かかる直接通信では、送受信端末間のファイヤウォールによりブロックされていないいかなるプロトコルを使用することもできる。かかるプロトコルの例としては、Ｔｅｌｎｅｔ、ＦＴＰ（File  Transfer  Protocol）、ＨＴＴＰ（Hyper  Text  Transfer  Protocol）等がある。
【００６１】
インターネット等の公衆ＷＡＮは、一般的には安全（secure）であるとは考えられない。よって、メッセージを秘密にしておきたい場合、公衆ＷＡＮ（及び、複数の会社のプライベートＷＡＮ）を送信されるメッセージは暗号化されてもよい。暗号メカニズムは既知であり、市販されている製品もあり、本発明とともに使用することができる。例えば、Ｃ＋＋ライブラリ関数crypt()が、サンマイクロシステムズ社から入手でき、Ｕｎｉｘ(登録商標)オペレーティングシステムで使用できる。暗号化及び復号のソフトウェアパッケージは既知であり、販売されているものがあり、本発明とともに使用することもできる。かかるパッケージの１つは、ＰＧＰ社（PGP  Corporation）のＰＧＰである。
【００６２】
図６Ａの一般的な構成に替えて、コンピュータインターフェイス３０２として機能する単一のコンピュータ、メールエージェント３０４、メールキュー３０６、及びメッセージトランスファエージェント３０８を使用してもよい。図６Ｂに示したように、デバイス／機器３００はコンピュータ３０１に接続される。コンピュータ３０１はメッセージトランスファエージェント３０８を含む。
【００６３】
さらに別の構成を図６Ｃに示した。図６Ｃでは、メッセージトランスファエージェント３０８はデバイス／機器３００の一部となっている。さらに、メッセージトランスファエージェント３０８は、ＴＣＰ／ＩＰ接続３１０によりメッセージトランスファエージェント３１２に接続されている。図６Ｃの実施形態において、デバイス／機器３００は電子メール機能によりＴＣＰ／ＩＰ接続３１０に直接接続されている。図６Ｃの実施形態の使用では、電子メール機能を有するファクシミリマシン（例えば、ＲＦＣ２３０５で規定された（インターネットメールを使用する単純ファクシミリモード））をデバイス／機器３００として使用する。ネットワークに接続できる最近の多くのプリンタは、様々な状態情報を報告する電子メールを送信する機能を有する。
【００６４】
図６Ｄは、デバイス／機器３００自体は、電子メールを直接受信する能力はないが、メッセージトランスファエージェント３０８とメールボックス３１４を含むメールサーバ／ＰＯＰ３サーバとの接続３１０を有し、ＰＯＰ３プロトコルを使用して、受信メールをメールサーバから読み出すシステムを示している。
【００６５】
図７は、メール転送の別の実施形態を示し、前掲のStevensによる文献の図２８．３から受け入れたものである。図７は各端にリレー（relay）システムを有する電子メールシステムを示している。図７の構成により、一組織の一システムがメールハブとして動作することができる。図７には、４つのＭＴＡがあり、２つのメールエージェント３０４と３１６の間に接続されている。ＭＴＡには、ローカルＭＴＡ３２２Ａ、リレーＭＴＡ３２８Ａ、リレーＭＴＡ３２８Ｂ、及びローカルＭＴＡ３２２Ｄがある。メールメッセージ用に使用される最も一般的なプロトコルはＳＭＴＰ（Simple  Mail  Transfer  Protocol）であり、ＳＭＴＰを本発明で使用することができるが、所望のいかなるメールプロトコルを利用してもよい。図７において、３２０はコンピュータインターフェイス３０２、メールエージェント３０４、及びローカルＭＴＡ３２２Ａを含む送信ホストを指す。デバイス／機器３００は送信ホスト３２０に接続されているか、あるいはそれに含まれている。別の場合として、デバイス／機器３００とホスト３２０を１つのマシンとし、ホスト機能をデバイス／機器３００に組み込むことができる。他のローカルＭＴＡ３２２Ｂ、３２２Ｃ、３２２Ｅ、及び３２２Ｆを含んでいてもよい。送受信すべきメールはリレーＭＴＡ３２８Ａのメールキュー３０６Ｂに入れてもよい。メッセージはＴＣＰ／ＩＰ接続３１０（例えば、インターネット接続またはその他のタイプのネットワークによる接続）により転送される
【００６６】
送信されたメッセージはリレーＭＴＡ３２８Ｂが受信し、必要に応じてメールキュー３０６Ｃに格納される。メールは受信ホスト３４２のローカルＭＴＡ３２２Ｄに転送される。メールは１つ以上のユーザメールボックス３１４に入れられ、その後メールエージェント３１６に転送され、最終的に端末３１８のユーザに転送される。必要なら、メールはユーザによる介入なしに端末に直接転送されてもよい。
【００６７】
本発明で使用される様々なコンピュータは、図５のコンピュータ２６６と２７６を含め、図８に示したように実施することができる。さらに、本発明で使用される他のコンピュータは、必要であれば、図５のサービスマシン２５４、コンピュータ２７２、及びコンピュータ２８２も含め、図８に示したコンピュータと同様に実施することができる。しかし、図８に示したすべての要素が各コンピュータに必要というわけではない。
【００６８】
図８では、コンピュータ３６０はＣＰＵ３６２を含む。このＣＰＵ３６２は、インテル、ＡＭＤ、モトローラ、日立、及びＮＥＣ等の企業が販売しているマイクロプロセッサを含むいかなる種類のプロセッサで実施してもよい。ＲＡＭ３６４等の作業メモリと、無線デバイス３６８と通信する無線インターフェイス３６６とがある。インターフェイス３６６とデバイス３６８との間の通信には、いかなる無線媒体（例えば、ラジオ波や光波）を使用してもよい。ラジオ波はＣＤＭＡ（Code  Division  Multiple  Access）等のスペクトル拡散技術を用いて実施してもよいし、ブルートゥース仕様書に開示されているような周波数ホッピング技術を使用して実施してもよい。
【００６９】
コンピュータ３６０は、ＲＯＭ３７０とフラッシュメモリ３７１とを含むが、フラッシュメモリ３７１に加えて、またはその替わりに他の種類の不揮発性メモリ（例えば、消去可能プログラマブルＲＯＭやＥＥＰＲＯＭ）を使用してもよい。入力コントローラ３７２にはキーボード３７４とマウス３７６が接続されている。シリアルインターフェイス３７８があり、シリアルデバイス３８０が接続されている。また、パラレルインターフェイス３８２はパラレルデバイス３８４に接続され、ユニバーサルシリアルバス（ＵＳＢ）インターフェイス３８６はユニバーサルシリアルバスデバイス３８８に接続されている。また、（一般的にはファイヤワイヤデバイスと呼ばれる）ＩＥＥＥ１３９４デバイス４００があり、ＩＥＥＥ１３９４インターフェイス３９８に接続されている。システムバス３９０はコンピュータ３６０の様々な要素を接続している。ディスクコントローラ３９６はフレキシブルディスクドライブ３９４とハードディスクドライブ３９２に接続されている。また、ディスクコントローラ３９６はＣＤ／ＤＶＤドライブに接続されている。通信コントローラ４０６により、コンピュータ３６０はネットワーク４０４により、他のコンピュータ（例えば、電子メールメッセージを送信することにより）と通信することができる。Ｉ／Ｏ（Input/Output）コントローラ４０８はローカルプリンタ４１０に接続され、例えばＳＣＳＩ（Small  Computer  System  Interface）バスを用いてハードディスク４１２に接続される。ディスプレイコントローラ４１６がありＣＲＴ（Cathode  Ray  Tube）４１４と接続されているが、他のタイプのディスプレイ、例えば、液晶ディスプレイ、発行ダイオードディスプレイ、プラズマディスプレイ等を使用してもよい。
【００７０】
本発明の一実施形態によるシステム９００全体を示す概略図である図９を参照する。システム９００は、例えば、レーザプリンタ９０８、スキャナ９１０、ネットワークデバイス９１２、多機能機９１４等の複数のデバイスを含み、これらはすべてネットワーク１００に接続されている。これらの複数のデバイスはここでは一般的に「被監視デバイス」と呼ぶ。システム９００はワークステーション／監視システム９０２（以下、コントローラ９０２と呼ぶ）も含む。ワークステーション／監視システム９０２はネットワークに１００に接続され、被監視装置９０８、９１０、９１２、及び９１４を監視及び制御する。各被監視デバイス９０８、９１０、９１２、及び９１４には一意的なアドレスが与えられている。例えば、デバイスに割り当てられたＩＰアドレスはそのデバイスの一意的アドレスとして機能する。コントローラ９０２のユーザは、各被監視デバイスに割り当てられた一意的なＩＰアドレスにアクセスすることにより、被監視装置９０８−９１４中の各デバイスにアクセスすることができる。言うまでもなく、本発明は、ＩＰアドレスを使用してネットワークに接続されているデバイスを一意的に特定することに限定はされない。
【００７１】
コントローラ９０２は、被監視デバイス９０８−９１４のうちの１つのデバイスにアクセスするとき、ＳＮＭＰプロトコル及び／またはＨＴＴＰプロトコルにより様々な情報を取得する。かかる情報には、そのデバイスの（トラブルシューティング情報を含む）動作状態に関する詳細情報が含まれる。例えば、コントローラ９０２はデバイスにアクセスしてその紙詰まり箇所（jam  location）を取得し、そのデバイスの担当者に紙詰まりを解消するようメッセージを送信する。レーザプリンタ９０８の動作ステータス／詳細には、トナーレベル、紙詰まり（paper  jam）の表示、プリンタトレイ中の印刷用紙数等の詳細を含む。
【００７２】
言うまでもなく、コントローラ９０２はネットワーク１００に有線または無線で接続されている。例えば、パーソナルデジタルアシスタント（ＰＤＡ）９２０またはノートブックコンピュータ９２２は、ネットワーク１００に無線で結合しているように示したが、コントローラ９０２として使用してもよい。アクセスポイント９２４は、ネットワーク１００とＰＤＡ９２２またはノートブックコンピュータ９２２との間の無線通信をするインターフェイスとして動作する。以下、コントローラ９０２がネットワークに接続された被監視デバイスを制御し、そのステータスを監視するものとして、本発明を説明する。
【００７３】
ネットワーク１００によりコントローラ９０２と被監視デバイス９０８−９１４との間の通信が行われ、かかる被監視デバイスの監視と制御が可能となる。ネットワークに接続されるデバイス数は、本発明では制限、はない。言うまでもなく、ネットワーク１００はローカルエリアネットワーク（ＬＡＮ）でもワイドエリアネットワーク（ＷＡＮ）でもよい。同様に、被監視デバイス９０８、９１０、９１２、及び９１４は単なる例として示したものである。
【００７４】
コントローラ９０２は記憶デバイス９０４及びデータベース９０６に通信可能に結合している。記憶デバイス９０４は、ハードディスクドライブ、光ディスクドライブ、及び／またはフロッピー(登録商標)ディスクドライブ等である。データベース９０６は記憶デバイス９０４に通信可能にリンクし、記憶デバイス９０４に格納されたデータを容易に検索・読み出しするためのリレーショナルデータベース管理システム（ＲＤＢＭＳ）を含んでいる。記憶デバイス９０４は、好ましくは、各被監視デバイス９０８−９１４に関する詳細情報を格納している。例えば、レーザプリンタ９０８のメーカ、モデル、機能、及びトラブルシューティングに関する詳細情報が記憶デバイス９０４に格納されている。また、所定基準値と比較したレーザプリンタの動作ステータスに関する偏差値も記憶デバイス９０４に格納されている。データベース９０６と記憶デバイス９０４はコントローラ９０２と通信可能に結合していると説明したが、言うまでもなくコントローラ９０２にはその記憶デバイスとデータベースが組み込まれていてもよい。かかる場合、記憶デバイス９０６とデータベース９０４はコントローラ９０２の内部にあるものとして示したであろう。
【００７５】
コントローラ９０２は複数のデバイス９０８−９１４を監視・制御するためのソフトウェアが実装されている。コントローラ９０２は、複数のデバイス９０８−９１４を監視するために、ＳＮＭＰ（Simple  Network  Management  Protocol）、ＦＴＰ（File  Transfer  Protocol）、ＨＴＴＰ（Hyper  Text  Transfer  Protocol）を使用して、その複数のデバイス９０８−９１４から受信したデータを、ＡＳＮ．１バイナリフォーマットまたはＨＴＭＬフォーマットまたはＸＭＬフォーマットで提示する（参照数字９５０で示した）。
【００７６】
図９には画像化デバイスのみを示したが、監視デバイスと複数の被監視デバイス間の情報通信用のネットワークには、機器とメータがネットワークに接続されたホームネットワークを含んでいてもよい。言うまでもなく、コントローラ／ワークステーション９０２により収集されたデータは、電子メール、ＦＴＰ、その他の通信プロトコル手段によりリモートデバイスに送信され、さらに処理される。監視ステーション９０２、ＰＤＡ９２０、ノートブック９２２はデータを収集してそのデータを記憶または通信プロトコルを通して送信するコントローラとなり得るが、コントローラはネットワークに接続されたどのデバイスがなってもよい。いずれのネットワークデバイス（例えば、プリンタ）も、ネットワーク中の他のデバイスのステータス（status）を監視し、収集したデータを格納し、その収集したデータを通信プロトコル手段により送信できる監視システムを含み得る。ゼロックス社のDocuPrint４０２５とＨＰ社のLaserJet９０００はいずれも電子メールの送信機能を有する。
【００７７】
監視ステーション９０２は収集した情報をＳＭＴＰその他のプロトコルを介して電子メールで遠隔地（remote  location）に送信することができる。図９に示したように、監視ステーション９０２は情報を電子メールでＳＭＴＰサーバ９２６を介して遠隔地またはリモートネットワークに送信する。遠隔地にはＰＯＰ３サーバ９３０がありその電子メールを受信する。ワークステーション９４０はＰＯＰ３サーバ９３０と通信し、ステータス情報を含む電子メールを読み出す。ワークステーション９４０はデータベース９６０にステータス情報を格納する。電子メールにより情報を遠隔地に容易に送信できる。情報は電子メールメッセージまたは添付ファイルに入っている。情報は符号化されデータを安全に送信できる。ＦＴＰ、ＨＴＴＰ、またはウェブサービス等のプロトコルを使用して情報を遠隔地（remote  location）に送信することもできる。
監視システムアーキテクチャ
図１０は、本発明の一実施形態によるリモートデバイスに関するデータの監視に使用する監視システム１０００（及び付属するインターフェイス機能）を示す。監視システム１０００はソフトウェアモジュールMonitorService１００４を含む。このモジュールはＮＴやＷｉｎｄｏｗｓ(登録商標)２０００のサービス（Service）やＵｎｉｘ(登録商標)のデーモン（Daemon）等のコンピュータ常駐プログラムである。好ましい実施形態では、監視システムはオブジェクト指向ソフトウェア環境を用いて実施される。また、監視システム１０００にはタイマーモジュール１００２とMonitorモジュール１００６が含まれている。Timerモジュール１００２とMonitorモジュール１００６はMonitorServiceモジュール１００４により呼び出されるライブラリ関数である。例えば、MonitorService１００４は、InitTimer１００３を呼び出してTimerモジュール１００２を初期化し、obtainDelayAndAction（int&,int&）関数を呼び出して遅延パラメータとアクションパラメータを取得する。init()関数がMonitorServiceモジュール１００４により呼び出され、Monitorモジュール１００６の様々なモジュールを初期化するが、これについては後述する。init()関数を使用して、既知の方法により収集したＩＰアドレス、パラメータ名、及び値を含む外部情報源（external  source）により、被監視デバイスに割り当てられたＩＰアドレスとパラメータ値とを取得することができる。Monitorモジュール１００６はsupportデータベース１０２４とMonitorデータベース１０１４に通信可能に結合している。これらのデータベースは後で詳述する。
【００７８】
被監視デバイスのＩＰアドレスを取得すると、監視システムはそのＩＰアドレスを使用して被監視デバイスにコンタクトして、製造者（ベンダー）やモデル等に関する情報を取得する。監視システム１０００により実行される機能には次のものが含まれる：
void  initTimer(void)
この関数はTimerを初期化する。特に、Timerオブジェクトをトリガー（trigger）し、レジストリからタイミング情報を取得する。
【００７９】
void  obtainDelayAndAction(int  &  out_nDelay,  int  &  out_nAction)
この関数はSleep関数（１０００倍する必要がある）の遅延時間（秒）とアクションインジケータ（action  indicator）とを返す。アクションインジケータは次のように定義される：０＝イベントチェッキング、１＝監視データの送信、２＝監視及びデータのローカルデータベースへの格納。
【００８０】
int  init(void)
この関数はMonitorを初期化する。また、監視すべきデバイスを生成する。戻り値（return  int）はエラーコードであり、ゼロはエラーが発生していないことを示す。
【００８１】
int  monitorStatus(int  in_nAction)
この関数はプリセット情報を監視する。戻り値はエラーコードであり、ゼロはエラーが発生していないことを示す。
【００８２】
int  end(void)
この関数は、オブジェクトをクローズする前にMonitorをクリーンアップする。戻り値（return  int）はエラーコードであり、ゼロはエラーが発生していないことを示す。
Monitorモジュール
図１１は、Monitorモジュール１００６（様々なソフトウェアサブモジュールを含む）の詳細構成と、Monitorモジュール１００６のサブモジュール間の呼び出し関数の詳細構成とを示している。Monitorモジュール１００６は、多数のモジュールにより使用されるクラスを含むCommonモジュール１１０１と、他のサブモジュール（DeviceODBCモジュール１１０４、Deviceモジュール１１１０、及びHwaccessモジュール１１１６を含む）がインターフェイス関数により定義されたタスクを完了するのを管理するMonitorManagerモジュール１１０２とを含む。具体的に、DeviceODBCモジュール１１０４には、標準インターフェイスにより外部デバイス情報にアクセスするために、アクセスする。HWaccessモジュール１１１６は、複数の通信プロトコル（例えば、ＨＴＴＰ、ＳＮＭＰ、及びＦＴＰ）から選択した通信プロトコルを用いて、被監視デバイスから、ベンダー、モデル、一意的ＩＤ、及びステータス情報を取得する。各Monitorソフトウェアモジュールは以下により詳しく説明する。
【００８３】
以下に、上記のMonitorモジュール間のインターフェイスの一部を挙げて説明する。例えば、いくつかのモジュールは、従来のフォーマット中の情報を取得するために、init関数または別の関数を有する必要がある。
【００８４】
void  updateConfig(std::map<infoType,  std::string>  &)
この関数を呼び出す前に、obtain関数がヌルストリングを返した場合、呼び出す関数はベンダーとモデルのエントリを書き換えないことが好ましい。この関数は、DeviceODBC１１０４中のカレントレコード（current  record）のデバイス情報データベースを更新する。この関数は、最初にObtainConfigを呼び出したときが最も効率的である。最初に、この関数はＩＰアドレスがDeviceODBC１１０４のものと同じであるかチェックする。ＩＰアドレスフィールドが同じでなければ、正しいＩＰアドレスのレコードをデータベースから取得する。次に、他のフィールドをコピーしてレコードを更新する。
【００８５】
bool  obtainConfig(std::map<infoType,  std::string>  &,  std::map<std::string,  std::vector<SParameter>>  &)
この関数は、所定フォーマットのデバイス情報のマップと、プロトコル及び関連パラメータのマップとをDeviceODBCモジュール１１０４から取得する。この関数は、データが返されれば真（true）を返し、データがなければ偽（false）を返す。
【００８６】
bool  saveStatus(std::map<infoType,  std::string>  &)
この関数はステータス情報をDeviceODBCモジュール１１０４に保存する。この関数は、うまく保存できたときには真を返し、保存が失敗したときには偽を返す。
【００８７】
CDevice  *  createDevice(const  std::string  &  in_sIP,  CHWaccess  &  in_HWaccess,  std::map<std::string,  std::vector<SParameter>>  &  in_ProtocolParameters)
この関数は、in_sIPとin_ProtocolParameterに基づいてデバイスを生成する。生成されたデバイスはCHWaccessによりハードウェアに接続される。デバイスを生成できない場合、この関数は０を返す。それゆえ、呼び出しオブジェクトは、帰りオブジェクトポインタ（return  object  pointer）が０かどうかチェックしなければならない。
【００８８】
bool  canAccessHW(void)
この関数は、ハードウェアがネットワークを通じてアクセス可能であれば真を返し、その他の場合には偽を返す。
【００８９】
bool  getVendor(std::string  &  out_sVendor)
この関数はベンダー名を返す。デバイスがシステムによりサポートされていないが、プロトコルの１つによりアクセス可能であれば、ストリングには「GENERIC」という言葉を含む。プロセスでエラーが検出されると、この関数はヌルストリング（null  string）と偽（false）を返す。そうでなければ、この関数は真（true）を返す。
【００９０】
bool  getModel(std::string  &  out_sModel)
この関数はデバイスのモデルを取得する。モデルを取得すると、この関数は真を返す。プロセスでエラーが検出されると、この関数はヌルストリング（null  string）と偽を返す。
【００９１】
bool  getUniqueID(std::string  &  out_sUniqueID)
この関数はデバイスの一意的ＩＤを返す。一意的ＩＤを取得すると、この関数は真を返す。プロセスでエラーが検出されると、この関数はヌルストリング（null  string）と偽を返す。
【００９２】
bool  obtainStatus(map<infoType,  std::string>  &  out_StatusMap)
この関数はステータスマップを返す。この関数は、ステータスが返されると真を返し、ステータスを取得できないと偽を返す。この関数はHWaccessモジュールとDeviceモジュールとは異なるマップを返す。Deviceモジュールでは、イベントステータス情報はHWaccessから返されたマップに追加され、クリアされる。
【００９３】
enum  checkEventStatus(void)
この関数はネットワークデバイスのイベントの取得をトリガー（trigger）する。enum  typeと値はクラスで定義しなければならない。enum値は次の値を含む：eNoEventSinceClearAndNoEventDetected,  eNoEventSinceClearAndEventDetected,  eEventSinceClearAndNoEventDetected,  eEventSinceClearAndEventDetected。
【００９４】
bool  obtainEventStatus(std::map<infoType,  std::  string>  &  out_EventStatusMap)
この関数はイベントステータス情報を取得する。この関数は、ステータスが返されると真を返し、ステータスを取得できないと偽を返す。
【００９５】
void  clearEventStatus(void)
この関数は、最後のobtainStatus関数コールまたはclearEventStatusから集積されたイベントステータスをクリアする。
【００９６】
void  initBegin(void)
この関数はHWaccessによる初期化プロセスを開始し、特にソフトウェアデバイスオブジェクトを生成する。
【００９７】
void  initEnd(void)
この関数はHWaccessがデバイスオブジェクト生成が終了したことを示すと、初期化プロセスを終了する。
【００９８】
bool  canAccessIP(const  std::string  &  in_sIP,  std::map<std::string,  std::vector<SParameter>>  &  in_ProtocolParameters)
この関数は、デバイスがそのＩＰアドレスでアクセス可能であれば真を返し、そうでなければ偽を返す。
【００９９】
bool  obtainVendor(std::string  &  out_sVendor,  std::map<std::string,  std::vector<SParameter>>  &  inOut_ProtocolParameters,  const  std::string  &  in_sIP)
この関数はベンダーを取得する。この関数は動作が正しく行われれば真を返し、空のストリングの場合には偽を返す。この関数呼び出しの間に、プロトコルを調べ、あるプロトコルがステータス監視に使用できないとき、そのプロトコルをinOut_ProtocolParametersから削除する。
【０１００】
bool  obtainModel(std::string  &  out_sModelName,  std::map<std::string,  std::vector<SParameter>>  &  inOut_ProtocolParameters,  const  std::string  &  in_sIP)
この関数はモデル名を取得する。この関数は動作が正しく行われれば真を返し、空のストリングの場合には偽を返す。この関数呼び出しの間に、プロトコルを調べ、あるプロトコルがステータス監視に使用できないとき、そのプロトコルをinOut_ProtocolParametersから削除する。
【０１０１】
bool  obtainUniqueID(std::string  &  out_sUniqueID,  std::map<std::string,  std::vector<SParameter>>  &  inOut_ProtocolParameters,  const  std::string  &  in_sIP)
この関数は一意的ＩＤを取得する。この関数は動作が正しく行われれば真を返し、空のストリングの場合には偽を返す。この関数呼び出しの間に、プロトコルを調べ、あるプロトコルがステータス監視に使用できないとき、そのプロトコルをinOut_ProtocolParametersから削除する。
【０１０２】
EerrorCode  obtainEventStatus(std::map<infoType,  std::string>  &  out_StatusMap,  const  std::string  &  in_sIP,  std::map<std::string,  std::vector<SParameter>>  &  in_ProtocolParameters)
この関数はイベントステータスを取得する。EerrorCodeは以下に定義する。
【０１０３】
bool  obtainStatus(std::map<infoType,  std::string>  &  out_StatusMap,  const  std::string  &  in_sIP,  const  std::string  &  in_sVendor,  const  std::string  &  in_sModel,  std::map<std::string,  std::vector<SParameter>>  &  in_ProtocolParameters)
この関数はデバイスのステータスを取得する。この関数は動作が正しく行われれば真を返し、空のマップの場合には偽を返す。
【０１０４】
図１２は、図１０に示したMonitorモジュール１００６の呼び出しシーケンスを説明するinit()関数のシーケンスを示す図である。MonitorManager１１０２は、初期化関数を開始するために、HWaccessモジュール１１１６を初期化する。その後、MonitorManager１１０２は、被監視デバイスに関する情報を取得して、その被監視デバイスに割り当てられたＩＰアドレスを使用して被監視デバイスと通信する。MonitorManager１１０２は、DeviceODBCモジュール１１０４にアクセスして、被監視デバイスの設定情報を取得する。MonitorManager１１０２に返される設定情報には、例えば、その被監視デバイスのＩＰアドレス、各プロトコルのパラメータ名とその値、被監視デバイスのベンダー／製造者及びモデルについての情報が含まれる。ＩＰアドレスを取得すると、MonitorManager１１０２はＩＰアドレス、各プロトコルのパラメータ名とその値を設定し、Deviceモジュール１１１０にデバイスのソフトウェアオブジェクトを生成する。デバイスソフトウェアオブジェクトが成功裏に生成されると、HWaccessモジュール１１１６を使用して被監視デバイスからベンダー、モデル、及び一意的ＩＤを取得し、生成したデバイスソフトウェアオブジェクトに格納する。
【０１０５】
ベンダー、モデル情報、及び一意的ＩＤをデバイスソフトウェアオブジェクトから取得すると、MonitorManager１１０２は被監視デバイスから受信した情報でデータベース（例えば、DeviceODBC１１０４）を更新する。図１２には１つのデバイスを示したが、obtainConfigからupdateConfigまでのステップを繰り返して、外部情報源で特定されたすべてのデバイスをカバーする。また、図１８、１９、２０、及び２２に示した各プロトコルを初期化する。図１７、１８、１９、２０、２１のＯＤＢＣに対応するデータベーステーブルにアクセスし、アクセスしたデバイスに必要な情報を外部記憶装置から内部データ構造に転送し、アクセスしたデバイスからのステータス情報の収集を速くする。
【０１０６】
図１３は、図１１に示したように、MonitorManagerモジュール１１０２により被監視デバイスのステータスを決定するステータスモニタ関数のシーケンスを示す図である。obtainStatus関数がDeviceからHWaccessに出されると、CHWaccessクラスは以下に説明するように、次に抽象クラスにより図２２に示した各プロトコルにパラメータが異なるobtainStatus関数呼び出しをする。各プロトコルモジュールは、すでに被監視デバイスからステータス情報を取得（extract）するのに必要な情報をキャッシュしている。被監視デバイスは、図１２に示した初期化時に１回はアクセスされている。よって、ステータス監視の際は外部情報源にアクセスしなくても被監視デバイスからステータス情報をすばやく取得することができる。このプロセスは、図１４に示したベクトルに格納した被監視デバイスすべてにわたって繰り返される。
【０１０７】
図１４を参照する。図１１のDeviceモジュール１１１０内に生成され、図１２、１３に示したMonitorManager１１０２により使用されるデバイスへの参照を有するベクトル１５００が示されている。MonitorManager１１０２は、ベクトル中に、Deviceモジュール１１１０内に生成されたCDeviceオブジェクトへのポインタ（Pointer  to  CDevice  Object）１５０２やCDeviceオブジェクトへのポインタ（Pointer  to  CDevice  Object）１５０４等のデバイスポインタを有する。ベクトルシーケンスを繰り返して被監視デバイスのステータスを取得する。obtainStatusコマンドを出して、デバイスオブジェクトに対して被監視デバイスのポーリング（polling）を実行する。ステータス監視シーケンスは図１３を参照して上で説明したので、ここでは繰り返さない。ステータス監視シーケンスは図１３を参照して上で説明したので、ここでは繰り返さない。
【０１０８】
表１に示したDeviceInfoストラクチャ（structure）は被監視デバイスの一例に関する情報を示している。DeviceInfoストラクチャは、電話番号に加えて担当者の電子メールアドレスも含んでいる。表１は情報の一例であり、表の全ての要素は必ずしも必要ではない。また、被監視デバイスに関する有用情報をデータベースとDeviceInfoストラクチャに加えることができる。
【表１】
2008065833.tif 000003
【０１０９】
Monitorデータベース
図１７はmonitorデータベースの構成を示している。このデータベースには各被監視デバイスのデバイス情報が含まれている（表１も参照）。図１７に示したように、一組のパラメータが、各通信プロトコル（例えば、ＳＮＭＰ、ＨＴＴＰ、ＦＴＰ）に対して一組ずつ、各被監視デバイスのデバイス情報DeviceInfo１９０２と関連づけられている。さらに、あるプロトコル（例えば、ＳＮＭＰ１９０８、ＨＴＴＰ１９１０、及びＦＴＰ１９１２）の一組のパラメータはそれぞれパラメータ名と値のペア（例えば、sPar１NameとsPar１Value）のリストとして構成されている。各プロトコルのパラメータ数は、図１７に示した数よりも多くても少なくてもよいことに留意せよ。例えば、ある被監視デバイスでは、ユーザ名とパスワードはＦＴＰパラメータとして格納し、コミュニティ名とパスワードはＳＮＭＰパラメータとして格納してもよい。図１７に示したように、monitorデータベースは、（被監視デバイスのステータス情報を含む）DeviceHistory１９０４と、EnumCorrespondence１９０６とに関する情報も含む。
【０１１０】
図１５は、様々な通信プロトコルにより使用されるパラメータを渡すために使用されるSparameterデータ構造１７００を示す。Sparameterは２つのフィールドを含む：m_sParName１７０２とm_sParValue１７０４である。これらは、それぞれパラメータの名称と値を表す。
【０１１１】
図１６は、monitorデータベースから取得した各プロトコルのパラメータのベクトルを各被監視デバイスのソフトウェアオブジェクトに渡すために使用されるマップストラクチャ１８００を示している。マップストラクチャ１８００は、各プロトコル／キーフィールド１８０２、１８０４、及び１８０６を、それぞれ、図１５に示したSParameterフォーマットに従って構成された対応するパラメータベクトル１８０８、１８１０、及び１８１２に関連付ける。例えば、ＳＮＭＰプロトコル１８０２の場合、パラメータベクトル１８０８は、ＳＮＭＰプロトコルで被監視デバイスにアクセスするために使用されるパラメータ名、パラメータ値のペアのリストを含み得る。例えば、ベクトル１８０８に格納されたＳＮＭＰパラメータ名は、対応するパラメータ値とともに、「コミュニティ名」と「パスワード」が含まれる。しかし、マップストラクチャ１８００の構成では、プロトコル数とそのパラメータの数はいくつでもよく、図１６に示したようにＳＮＭＰ、ＨＴＴＰ、及びＦＴＰに限定されるものではない。
supportデータベース
図１８−２０は、図１０に示したsupportデータベース１０２４の構成を示している。supportデータベースは、各被監視デバイスからステータス情報を取得するために必要な情報を含み、通信プロトコルごとに構成されている。さらに、supportデータベースは、あるベンダーとモデルによりどのプロトコルがサポートされているか決定するための情報を含む。例えば、図１８は、被監視デバイスから情報を取得するために使用するＳＮＭＰ関連のサポート情報のsupportデータベースの構成を示しており、SNMPVendor２００２、SNMPComVendorStatus２００４、EnumCorrespondence２００６、及びSNMPVendorModelStatus２００８データストラクチャを含む。supportデータベース中のデータストラクチャには、取得するステータス情報の種類を一意的に特定するパラメータが、取得を制御するパラメータとともに含まれている。例えば、SNMPComVendorStatusデータストラクチャ２００４は、nENUMフィールド２００９とnRelativePriorityフィールド２０１０が含まれる。nENUMフィールド２００９は取得する情報の種類（例えば、トナーレベル）を特定し、nRelativePriorityフィールド２０１０は他のプロトコルに対する取得する情報の重みまたは重要度を示す。このように、２つ以上のプロトコルを用いて被監視デバイスから同じ情報を取得した場合、nRelativePriorityの値はどのプロトコルで取得した値を使用すべきかの相対的な目安を与える。例えば、ＨＴＴＰはトナーレベルが「高」か「低」かを示す情報しか取得できず、一方ＳＮＭＰプロトコルは残りトナーのレベルをパーセンテージで取得できる場合、ＳＮＭＰのトナーレベルの優先度（priority）レベルはＨＴＴＰの対応する値よりも高い。また、supportデータベースは全プロトコルのデフォルトの優先度の値を提供する。一実施形態では、プロトコルの優先度の値が０から３２，０００の範囲にあるシステムにおいて、ＳＮＭＰプロトコルは優先度の値が１０，０００である。
【０１１２】
図１９と図２０は、supportデータベースのＨＴＴＰ及びＦＴＰの部分に含まれるデータストラクチャを示し、図１８を参照して説明したデータストラクチャと同様のデータストラクチャを含む。図１８−２０に示したEnumCorrespondenceデータストラクチャは、supportデータベース中のプロトコルのすべてのデータストラクチャで共通であり、図１７に示したのと同じデータストラクチャである。
【０１１３】
図１９はＨＴＴＰプロトコルにより使用されるsupportデータベースのテーブルを示す。テーブルHTTPVendorModelWebPageとHTTPWebPageModelは、どのベンダーとモデルがＨＴＴＰプロトコルでサポートされているかを示している。２つのテーブルはデバイスのウェブページからモデル名を取得（extract）するために使用される情報も含む。テーブルHTTPVendorModelUniqueIDは、あるベンダーとモデルの一意的ＩＤを含む、デバイスのウェブページに関する情報を含む。テーブルHTTPVendorModelStatusWebPageは、あるベンダーとモデルのステータス情報を含む、デバイスのウェブページに関する情報を含む。テーブルHTTPWebPageExtractFromLineとHTTPWebPagePreconditionsは、デバイスのウェブページの一意的ＩＤまたはステータス情報を見つけて取得するために使用される情報を含む。
【０１１４】
図２０は、被監視デバイスのＦＴＰファイルから情報を取得するために使用するサポート情報を含むデータストラクチャを示している。
本発明で使用するenumタイプの例は以下に定義するinfoTypeである。（enumタイプは単なる例であり、本発明を限定するものと介してはならない。）
【０１１５】
infoType  (typedef  int  infoType)
このセクションはinfoType(int)の定義を記載している。値の範囲として０乃至９９がデータタイプに割り当てられている。値の範囲１００乃至４９９はDevice情報に割り当てられている。値の範囲５００乃至１９９９は標準的ＭＩＢパラメータを含む一般的にパラメータに割り当てられている。値の範囲２０００乃至３９９９はリコー特有の情報に割り当てられている。範囲４０００乃至４９９９はゼロックスに割り当てられている。範囲５０００乃至５９９９はレックスマークに割り当てられている。範囲６０００乃至６９９９はＨＰに割り当てられている。７０００以上の値はブラザー、三星、京セラ三田、デル、及びコニカミノルタに割り当てられている。値は次の通り決められている：infoType  {  eNotDefine  =  ０,  eDeviceInformation=１,  eStatusInformation=２,  eVendor=１００,  eModel,  eUniqueID,  eIPAddress,  eCompanyName,  eStreet,  eCity,  eState,  eZipCode,  eLocation,  eContactPerson,  ePhoneNumber,  eEMailAddress,  eDateTime=５００,  eHrDeviceErrors,  eLowPaper,  eNoPaper,  eLowToner,  eNoToner,  eDoorOpen,  eJammed,  eOffline,  eServiceRequested,  ePrtGeneralConfigChanges=６００,  ePrtLifeCount,  ePrtAlertDesc１,  ePrtAlertDesc２,  ePrtAlertDesc３,  ePrtAlertDesc４,  ePrtAlertDesc５,  eBlack=７００,  eMagenta,  eCyan,  eYellow,  eTonerCollector=８００,  eBlackDeveloper=８１０,  eColorDeveloper,  eFuser=８２０,  eDrum=８３０,  eTransfer=８４０,  eMaintenanceKit=８５０,  eOilKit=８６０,  eStationInfo１=９０１,  eStationInfo２,  eStationInfo３,  eStationInfo４,  eStationInfo５,  eRicohEngineCounterTotal=２０００,    eRicohEngineCounterPrinter,  eRicohEngineCounterFax,  eRicohEngineCounterCopier}.
【０１１６】
エラーコード
以下のコードは単なる例であり、より多くのコードを既存のコードに追加してもよい。範囲０乃至９９は予約されている。範囲１００−４９９はＳＭＴＰであり、２００−２９９はＰＯＰ３であり、３００−３９９はＳｏｃｋｅｔであり、４００−４９９はＨＴＴＰであり、５００−５９９はＦＴＰである。まだ決まっていない範囲は必要に応じてユーザが決めてよい。
enum  EerrorCode(eNoError  =  ０,  eUnknownError  =  １,  eSomeError,  eCompleteFailure,  eSomeDeviceCreationError  =  ２０,  eCreateDeviceError,  eNoDeviceCreated,  eObtainConfigError,  eSaveStatusError,  eObtainUniqueIDError,  eObtainStatusError,  eStartSendError,  eSomeDataSendError,  eCompleteDataSendFailure,  eEndSendError,  eSendHeloCommandFailed  =  １００,  eSendMailCommandFailed,  eSendRcptCommandFailed,  eSendDataCommandFailed,  eSendDataFailed,  eSendQuitCommandFailed,  eSendUserCommandFailed  =  ２００,  eSendPassCommandFailed,  eSendStatCommandFailed,  eSendRetrCommandFailed,  eSendDeleCommandFailed,  eSendQuitPop３CommandFailed,  eCreateSocketFailed  =  ３００,  eConnectSocketFailed,  eBadRequest=４００,  eUnauthorized,  ePaymentRequired,  eForbidden,  eNotFound,  eMethodNotAllowed,  eNotAcceptable,  eProxyAuthenticationRequired,  eRequestTimeOut,  eConflict,  eGone,  eLengthRequired,  ePreconditionFailed,  eRequestEntityTooLarge,  eRequestURITooLarge,  eUnsupportedMediaType,  eRequestedRangeNotSatisfiable,  eExpectationFailed,  eInternalServerError=４５０,  eNotImplemented,  eBadGateway,  eServiceUnavailable,  eGatewayTimeOut,  eHTTPVersionNotsupported,  eMultipleChoices=４８０,  eMovedPermanently,  eFound,  eSeeOther,  eNotModified,  eUseProxy,  eTemporaryRedirect).
【０１１７】
図２１は、システムがサポートする標準化ベンダーとモデルを決定するために使用されるsupportデータベースのテーブルを示している。テーブルNormalizedVendorは、すべてのプロトコルが使用する全てのベンダー名の共通のベンダー名へのマッピングを含む。テーブルNormalizedVendorModelは、全てのプロトコルが使用する全てのモデル名の共通のモデル名へのマッピングと、標準化ベンダーとモデルのＩＤへのマッピングとを含む。
【０１１８】
HWaccessモジュール中の抽象クラス
図２２は、HWaccessパッケージのパッケージ図を示す。このパッケージは監視すべきネットワークデバイスを特定し、様々なネットワークプロトコル（例えば、ＳＮＭＰ、ＨＴＴＰ、及びＦＴＰ）を用いたネットワークデバイスに関する情報の取得に役立つ。このパッケージはパッケージHTTP  ２３０２,  SNMP  ２３０４,  FTP  ２３０６,  NormalizedVendorModelODBC  ２３１２,  及びクラスCHWaccess  ２３００,  CAbsProtocol  ２３０８,  CRecordset  ２３１０,  及びCNormalizedVendorModel  ２３１４を含む。パッケージＨＴＴＰ２３０２、ＳＮＭＰ２３０４、ＦＴＰ２３０６は、ネットワークデバイスにアクセスして情報を取得するネットワークプロトコルを実施する。例えば、ＨＴＴＰパッケージ２３０２はＨＴＴＰプロトコルを実施し、ネットワークデバイスのウェブページにアクセスして、そのウェブページから情報を取得する。クラスCHWaccess２３００は、すべてのプロトコルパッケージを管理し、ネットワークデバイスから必要な情報を取得する。クラスCabsProtocol２３０８はいずれのプロトコルも表す抽象クラスである。このクラスはCHWaccess２３００とプロトコルパッケージとの間のインターフェイスを提供する。クラスCabsProtocol２３０８は、CHWaccess２３００に、図２２に示した一組の共通関数を提供する。すべてのプロトコルはCHWaccess２３００に必要な情報を提供する。後の図面に示したように、CAbsProtocol２３０８から求めたクラスは、適当なプロトコルの関数の各々に対して方法（the  method）を提供する。クラスCRecordset２３１０はマイクロソフトファウンデーションクラスのクラスであって、各プロトコルパッケージにデータベースへアクセスして、どのベンダーとモデルのネットワークデバイスがサポートされ、それらのネットワークデバイスから何の情報を取得するかに関する情報を取得させる。クラスCnormalizedVendorModel２３１４は名前空間のメンバーであり、このクラスのオブジェクトをすべてのプロトコルパッケージで共有できる。クラス２３１４は、プロトコルが標準化ベンダー、標準化モデル、及びそのベンダーとモデルのＩＤを取得できるように情報を有する。標準化ベンダーとモデル名はすべてのプロトコルが使用できる共通の名前を提供する。クラス２３１４は、NormalizedVendorModelODBC２３１２パッケージによりsupportデータベースから標準ベンダーとモデルとＩＤに関する情報を取得する。２３１２パッケージは、標準化ベンダーとモデルとＩＤとを取得するためにsupportデータベース中のテーブルへのアクセスを提供する。
【０１１９】
各プロトコルパッケージＨＴＴＰ２３０２、ＳＮＭＰ２３０４、ＦＴＰ２３０６は、図２２に示したように、ネットワークデバイスから情報を取得するためのネットワークデバイスへのアクセスを管理するクラスを含む。クラスは抽象クラスCAbsProtocol２３０８から作られる。この抽象クラスCAbsProtocol２３０８は、ネットワークデバイスの情報にアクセスするプロトコルを実施する方法を提供する。抽象クラスはインターフェイス関数を提供するが、プロセスは実行しない。抽象クラスから派生するクラスは、インターフェイス関数のプロセスを実行する方法を提供する。抽象クラスから派生するクラスは多数あるので、派生クラスによってインターフェイス機能のプロセスの実行の仕方がことなる。HWaccessパッケージの設計により、新しいプロトコルをシステムに追加することができるが、それは新しいパッケージを管理し新しいプロトコルを用いてネットワークデバイスにアクセスするCAbsProtocol２３０８の派生クラスを含む新しいパッケージを追加することにより行う。抽象クラスによりシステムを将来的に拡張することができる。
【０１２０】
図２３は、ネットワークデバイスにアクセスしてそれから情報を取得するすべてのプロトコルを維持（maintain）する、図２２のHWaccessパッケージで使用されるデータストラクチャを示す。図２３において、データストラクチャはCAbsProtocol２３０８へのポインタのベクトル５００である。クラスCHWaccess２３００はこのデータストラクチャを含み、使用する。ベクトル５００はCAbsProtocol２３０８から派生するクラスへのポインタを含むが、CHWaccess２３００はそのベクトルをCAbsProtocol２３０８へのポインタを含むとして、仮想関数呼び出しメカニズムによりCAbsProtocol２３０８のインターフェイス関数を呼び出す。実際には、CHWaccess２３００はCAbsProtocol２３０８の派生クラスのインターフェイス関数を呼び出す。例えば、ベクトル中の第１のエントリのCAbsProtocolへのポインタ５０２は派生クラスCSNMPProtocolへのポインタであり、ベクトル中の第２のエントリのCAbsProtocolへのポインタ５０４は派生クラスCHTTPProtocolへのポインタであり、ベクトル中の第３のエントリのCAbsProtocolへのポインタ５０６は派生クラスCFTProtocolへのポインタである。そこで、CHWaccess２３００がベクトル中のCAbsProtocol２３０８のインターフェイス関数を呼ぶと、実際にはCSNMPProtocol、CHTTPProtocol、及びCFTPProtocolのインターフェイス関数を呼んでいることになる。ベクトル５００中の抽象クラスCAbsProtocol２３０８の使用により、ネットワークデバイスにアクセスして情報を取得するために、どのプロトコルを使用することもできるようになる。抽象クラスCAbsProtocol２３０８により、どのプロトコルを使用しているかという詳細を隠すことができる。
【０１２１】
図２４は、Monitorパッケージのinit()が呼び出された時のHWaccessパッケージの初期化を示すシーケンス図である。CNormalizedVendorModelオブジェクトが生成され、初期化され、すべてのプロトコルオブジェクトがベンダーとモデルの標準化（または共通）名称とＩＤとを取得することができる。すべてのプロトコルオブジェクトが、監視されるデバイスからの情報にアクセスするために生成され、初期化される。CHWaccessの関数initBegin()の呼び出しによりCNormalizedVendorModelオブジェクトが生成され、すべてのプロトコルオブジェクトにアクセス可能となる。CNormalizedVendorModelのinitBegin()が呼び出され、そのデータストラクチャを、全てのベンダー及びその標準化ベンダーと、すべてのモデル及びその標準化モデルと、標準化ベンダー及びモデルのＩＤとに関する情報で初期化する。次に、すべてのプロトコルオブジェクト（CAbsProtocolから派生する）を、createProtocols()関数において生成する。各プロトコルオブジェクトのinitBegin()が、被監視デバイスのベンダー、モデル、及び一意的ＩＤを決定するために使用されるサポート情報を初期化するために呼ばれる。CHWaccessのinitEnd()を呼ぶ前に、CHWaccessとプロトコルオブジェクトの関数を呼んでデバイスにアクセスし、すべてのプロトコルでデバイスのベンダー、モデル、及び一意的ＩＤの情報を取得し、初期化する。CHWaccessのinitEnd()を呼ぶ時までに、各プロトコルオブジェクトは、そのプロトコルがサポートする被監視デバイスのステータス情報を取得するために、必要な情報をすべて有する。各プロトコルオブジェクトのinitEnd()は、初期化後に不要となるすべてのデータストラクチャをクリア（clean  up）する。CNormalizedVendorModelのinitEnd()は、CNormalizedVendorModelが削除される前にそれが有するすべてのデータストラクチャをクリアする。
【０１２２】
図２５は、デバイスがいずれかのプロトコルでアクセス可能であるかどうか決定する、HwaccessパッケージのcanAccessIP()を示すシーケンス図である。CHWaccessは、プロトコルオブジェクトの１つがＩＰアドレスに対応するデバイスにアクセスできるまで、各プロトコルオブジェクトのcanAccessIP()を呼び出す。どのプロトコルオブジェクトもデバイスにアクセスできないとき、CHWaccessのcanAccessIP()は偽（false）を返し、そのデバイスは監視されない。
【０１２３】
図２６は、プロトコルオブジェクトからデバイスのベンダー、モデル、及び一意的ＩＤを取得し、他のプロトコルオブジェクトをベンダー及びモデルの情報で初期化するシナリオを示すシーケンス図である。プロトコルオブジェクトがデバイスのベンダー及びモデルの情報を取得すると、そのプロトコルオブジェクトはCNormalizedVendorModelオブジェクトからそのデバイスの標準化したベンダー及びモデルの名称を取得し、デバイスからステータス情報を取得できるように、そのデバイスのサポートを更新する。CNormalizedVendorModelは、標準化したベンダーとモデルの名称（及び、必要であればベンダーモデルＩＤ）を返すために、図３０乃至３３に示したデータストラクチャを使用する。他のプロトコルオブジェクトはデバイスのベンダーとモデルに関する情報を受信して、そのデバイスに対するそのプロトコルオブジェクトのサポートを更新して、そのデバイスからステータス情報を取得できるようにする必要がある。CHWaccessは、デバイスのベンダー、モデル、一意的ＩＤを取得するのに必要なだけ多くのプロトコルオブジェクトを使用して、他のすべてのプロトコルオブジェクトをベンダーとモデルの情報で初期化する。CDevice（１１１０）オブジェクトは、デバイスの所定のＩＰアドレスの標準化ベンダー、標準化モデル、及び一意的ＩＤの情報を保持する。このシーケンス図において、CHWaccessはプロトコルオブジェクトのVendorModelUniqueID()を呼び、プロトコルオブジェクトからすべての情報を取得する。プロトコルオブジェクトは、CNormalizedVendorModelのobtainNormalizedVendorModelID()を呼び、標準化ベンダー名、モデル名、及びＩＤを取得する。CHWaccessは、その他すべてのプロトコルオブジェクトのinitWithVendorModel()を呼び、標準化ベンダー及びモデルの情報でその他のすべてのプロトコルオブジェクトを初期化する。プロトコルオブジェクトは、ＩＤをしようする必要があれば、CNOrmalizedVendorModelのobtainIDForNormalizedVendorModel()を呼んでもよい。
【０１２４】
シーケンス図において、他のデバイスのベンダー、モデル、及び一意的ＩＤを取得する場合、CHWaccessはプロトコルオブジェクトのobtainVendorModelUniqueID()を呼ぶが、ベンダー名しか取得できないこともある。プロトコルオブジェクトは、CNormalizedVendorModelのobtainNormalizedVendor()を呼び、標準化ベンダー名を取得する。CHWaccessは、モデルと一意的ＩＤを取得するために、他のプロトコルオブジェクトのobtainModel()とobtainUniqueID()を呼ぶ。プロトコルオブジェクトは、デバイスからベンダー、モデル、及び一意的ＩＤの情報を取得し、CNormalizedVendorModelのobtainNormalizedVendorModelID()を呼ぶことにより、標準化したベンダーとモデル名とＩＤとを取得する。CHWaccessは、その他すべてのプロトコルオブジェクトのinitWithVendorModel()を呼び、標準化ベンダー及びモデルの情報でその他のすべてのプロトコルオブジェクトを初期化する。プロトコルオブジェクトは、ＩＤをしようする必要があれば、CNOrmalizedVendorModelのobtainIDForNormalizedVendorModel()を呼んでもよい。
【０１２５】
図２７は、図１６のプロトコルパラメータマップ１８００をいかに更新して、ネットワークデバイスからステータス情報を取得するためにどのプロトコルを使用するか決定するかを示すフローチャートである。図２６のステップは、一プロトコルにおいて、ネットワークデバイスのベンダー名とモデル名を取得するために実行される。ステップ３７０２において、一プロトコルを用いてネットワークデバイスにアクセスできるか、チェックする。ネットワークデバイスは、マップ１８００中の情報を用いてそのプロトコルによりアクセスされる。ネットワークデバイスがそのプロトコルによりアクセスできないとき、ステップ３７０４においてそのプロトコルをプロトコルパラメータマップ１８００から削除し、ステップ３７１４においてマップ１８００の更新を完了する。そのプロトコルによりそのネットワークデバイスにアクセスできるとき、ステップ３７０６において、そのネットワークデバイスのベンダーをそのプロトコルを用いて取得できるかチェックする。ベンダーを取得できないとき、ステップ３７０７において、そのプロトコルがGENERICベンダーをサポートしているかチェックする。一プロトコルに対してGENERICベンダーがサポートされているとは、一プロトコルが、デバイスのベンダーを取得できないかサポートしていなくても、いくつかの標準により全てのデバイスに共通なステータス情報を取得できることを意味する。GENERICベンダーがそのプロトコルによりサポートされていないとき、ステップ３７０４においてそのプロトコルをプロトコルパラメータマップ１８００から削除し、ステップ３７１４においてマップ１８００の更新を完了する。GENERICベンダーがそのプロトコルによりサポートされているとき、プロトコルはプロトコルパラメータマップ１８００に残され、ステップ３７１４においてマップの更新は完了する。ベンダーがステップ３７０６で取得できたとき、ステップ３７０８において、ネットワークデバイスのベンダーがサポートされているかチェックする。そのプロトコルによりベンダーがサポートされていないとき、ステップ３７０７において、そのプロトコルがGENERICベンダーをサポートしているかチェックする。ステップ３７０７以降のステップは上で説明した。
【０１２６】
ベンダーがそのプロトコルによりサポートされているとき、ステップ３７１０において、そのネットワークデバイスのモデルをそのプロトコルを用いて取得できるかチェックする。モデルを取得できないとき、ステップ３７１１において、そのプロトコルがGENERICモデルをサポートしているかチェックする。一プロトコルに対してGENERICモデルがサポートされているとは、一プロトコルが、デバイスのモデルを取得できないかサポートしていなくても、一ベンダーの全てのデバイスに共通なステータス情報（ベンダー固有ステータス情報）を取得できることを意味する。GENERICモデルがそのプロトコルによりサポートされていないとき、ステップ３７０４においてそのプロトコルをプロトコルパラメータマップ１８００から削除し、ステップ３７０４においてマップ１８０Oの更新を完了する。GENERICモデルがそのプロトコルによりサポートされているとき、プロトコルはプロトコルパラメータマップ１８００に残され、ステップ３７１４においてマップの更新は完了する。モデルがステップ３７１０で取得できたとき、ステップ３７１２において、ネットワークデバイスのモデルがサポートされているかチェックする。そのプロトコルによりモデルがサポートされていないとき、ステップ３７１１において、そのプロトコルがGENERICモデルをサポートしているかチェックする。ステップ３７１１以降のステップは上で説明した。そのモデルがそのプロトコルによりサポートされている場合、そのプロトコルを使用して、ネットワークデバイスのステータス情報を取得し、プロトコルパラメータマップ１８００の更新はステップ３７１４で完了する。ベンダーとモデルが取得できないかサポートされていない場合、そのプロトコルはプロトコルパラメータマップ１８００から削除され、そのプロトコルはステータス情報を取得するためには使用されない。プロトコルに応じて、図２７に示したプロセスにはバリエーションがある。
【０１２７】
上記のように、ステータス情報は、例えベンダーとモデルが取得できないかサポートされていなくても、ネットワークデバイスからＳＮＭＰにより取得できる。ネットワークデバイスがＳＮＭＰをサポートし、ＳＮＭＰによりアクセスできる限り、そのネットワークデバイスの標準ＭＩＢ（Management  Information  Base）を用いて取得することができる。ステップ３７０２において、ネットワークデバイスにＳＮＭＰによりアクセスできない場合、ステップ３７０４において、ＳＮＭＰプロトコルはプロトコルパラメータマップ１８００から削除される。しかし、ネットワークデバイスにＳＮＭＰによりアクセスできる場合、ベンダーまたはモデルが取得できサポートされているか否かにかかわらず、ＳＮＭＰプロトコルはプロトコルパラメータマップ１８００に残される。ＳＮＭＰをサポートするネットワークデバイスはＭＩＢを提供するので、リモートシステムは常にそのデバイスから情報を取得することができる。しかし、ネットワークデバイスから取得できる情報の種類と数は、ベンダーとモデルが取得できサポートされているかどうかに依存する。ベンダーとモデルを取得でき、知っていれば、ＳＮＭＰによりネットワークデバイスからより多くの情報を取得できる。ベンダーとモデルが取得できなくても、ＳＮＭＰはシステム説明（description）やシステムの動作時間等のすべてのデバイスが提供できる情報を取得することができる。ＳＮＭＰは３つの状態下でネットワークデバイスから情報を取得することができる：（１）ベンダーとモデルがサポートされている状態、（２）ベンダーがサポートされているが、モデルはサポートされていない状態、及び（３）ベンダーもモデルもサポートされていない状態。ＨＴＴＰとＦＴＰはＳＮＭＰのような特徴は有していない。ＳＮＭＰは標準的ＭＩＢを有し、すべてのネットワークデバイスがそれに従い、情報を取得することができるが、ウェブページやＦＴＰファイルはネットワークデバイスのベンダーやモデルごとに変化する。ウェブページやＦＴＰファイルには、ネットワークデバイスがそれに従って情報を取得できるような標準的なものはない。
【０１２８】
図２８は、すべてのプロトコルを用いてネットワークデバイスに関するステータス情報を取得するプロセスを説明するフローチャートである。プロトコルオブジェクトは、サポートしているネットワークデバイスのベンダーとモデルに関する情報で初期化されると、ネットワークデバイスからステータス情報を取得するために使用することができる。プロトコルオブジェクトは、図１８、１９、２０のsupportデータベースからの情報を含むデータストラクチャを用いて、あるベンダーとモデルのステータス情報をいかに取得するかに関する情報を含む。図２２に示したCAbsProtocolへのポインタ２３０８のベクトルを使用して、すべてのプロトコルオブジェクトのステータス情報を取得する。フローチャートのプロセスはそのベクトルを１回通過する。ステップ３１２２において、プロトコルオブジェクトがCAbsProtocolへのポインタのベクトルから取得される。プロトコルオブジェクトはネットワークデバイスにアクセスするためのネットワークプロトコル（例えば、ＳＮＭＰ、ＨＴＴＰ、及びＦＴＰ）の１つに対応する。ステップ３１２４において、ベクトルから取得できるプロトコルオブジェクトがまだあるかチェックする。このチェックは、ベクトルの終わりに到達したか判断することにより行う。これ以上プロトコルオブジェクトを取得できないとき、ステップ３１２６においてすべてのプロトコルオブジェクトを用いてネットワークオブジェクトからステータス情報の取得は終了する。ベクトルから取得されるプロトコルオブジェクトがあれば、そのプロトコルオブジェクトを使用してステップ３１２８においてネットワークデバイスのステータス情報を取得する。プロトコルオブジェクトを用いてステータス情報を取得した後、ステップ３１２２に戻り、他のプロトコルオブジェクトを用いてより多くのステータス情報を取得する。
【０１２９】
図２９は、様々なプロトコルにより取得されたステータス情報を維持するために使用するデータストラクチャを示す。このデータストラクチャは、どのプロトコルがそのステータス情報を取得するために使用されたかに関する情報は維持していない。データストラクチャはマップ７２４である。マップ７２４のキー７２６はinfoTypeである。infoTypeは情報の種類を表す数である。マップ７２４の値７２８はペア（pair）である。ペアはストリングと整数から構成されている。ペア中のストリングは、infoTypeに対応する、ネットワークデバイスから取得したステータス情報である。ペア中の整数はプロトコルで取得したステータス情報の重みまたは優先度（priority）である。一例として、プリンタカートリッジ中の黒トナーのレベルを表すinfoTypeが７００の場合、ペアにはストリング「７５％」と整数１００００が含まれる。ストリング「７５％」は７５％のトナーがカートリッジ中に残っており、整数１００００はそのステータス情報の重みまたは優先度である。CNSMPProtocol２４０２、CHTTPProtocol２５０２、及びCFTPProtocol２６０２は、それがネットワークデバイスから取得したステータス情報をマップ７２４に追加する。マップ中にすでに同じinfoTypeがあれば、優先度が高いペアの値がマップ中に保持される。
【０１３０】
図３０は、図２２のHWaccessモジュールにあるクラスCNormalizedVendorModelのマップストラクチャ属性メンバーm_NormalizedVendorMapである。図３０のマップストラクチャ属性メンバーは、システムによりサポートされたベンダーに関する情報を含み、ベンダー名を標準化したベンダー名にマップ（map）する。マップのキーはシステムがサポートするベンダーの様々な名前であり、マップの値は標準化されたベンダーである。ベンダーに対してすべてのプロトコルがまったく同じ名前を必ずしも取得しないので、キーは異なるプロトコルが取得するベンダー名を含んでいる。また、吸収や合併により、会社名が変わることもある。値には、すべてのプロトコルが使用できる、ベンダーの異なる名前に対する標準化したベンダー名を含む。これにより、様々なプロトコルにより取得された異なるベンダー名を１つの一意的なベンダー名にマッピング（mapping）することができる。例えば、ＳＮＭＰプロトコルはデバイスからベンダー名ｈｐを取得する。ＨＴＴＰプロトコルは、同じデバイスからベンダー名Hewlett-Packardを取得する。そのデバイスに対して全てのプロトコルが使用するそのデバイスの標準化したベンダー名はＨＰである。マップは標準化したベンダー名を合併会社のベンダー名とする目的も果たす。合併会社の異なるすべてのベンダーは、１つのベンダー名またはベンダー名の１つの組合せである単一のベンダー名にマップされる。例えば、ＨＴＴＰプロトコルはデバイスからベンダー名Ｍｉｎｏｌｔａを取得する。ＳＮＭＰプロトコルは、同じデバイスからベンダー名ＱＭＳを取得する。そのデバイスに対して全てのプロトコルが使用するその合併会社に対応するデバイスの標準化したベンダー名はＫｏｎｉｃａＭｉｎｏｌｔａである。このマップには、図２１のsupportデータベースのテーブルからの情報がエントリされる（populated）。
【０１３１】
図３１は、図２２のHWaccessモジュールにあるクラスCNormalizedVendorModel（２３１４）のマップストラクチャ属性メンバーm_NormalizedModelMapである。このマップストラクチャを使用して、図３０に示したマップストラクチャを用いて標準化ベンダー名を取得した後に、標準化モデル名を取得する。図３１のマップストラクチャ属性メンバーは、システムによりサポートされたモデルに関する情報を含み、モデル名を標準化したモデル名にマップ（map）する。マップのキーは、標準化ベンダー名と、システムがサポートする様々なモデル名とを続けたものであり、間にセパレータ（「％」）が入っている。マップの値は標準化モデル名である。モデルに対してすべてのプロトコルがまったく同じ名前を必ずしも取得しないので、キーは異なるプロトコルが取得するモデル名を含んでいる。値には、すべてのプロトコルが使用でき共通に有する、モデルの異なる名前に対する名前を含む。これにより、様々なプロトコルにより取得された異なるモデル名を１つの一意的なモデル名にマッピング（mapping）することができる。例えば、ＳＮＭＰプロトコルは三星社のプリンタの一モデルからモデル「ＣＬＰ  ５５０」を取得する。ＨＴＴＰプロトコルは、同じプリンタからモデル名「ＣＬＰ−５５０」を取得する。そのデバイスに対して全てのプロトコルが使用するそのデバイスの標準化したモデル名はＣＬＰ５５０である。このマップには、図２１のsupportデータベースのテーブルからの情報がエントリされる（populated）。
【０１３２】
図３２は、図２２のHWaccessモジュールにあるクラスCNormalizedVendorModelのマップストラクチャ属性メンバーm_VendorModelIDMapである。図３２のマップストラクチャ属性メンバーは、標準化ベンダー名及びモデル名と関連するＩＤに関する情報を含む。マップのキーは、標準化ベンダー名と、標準化モデル名とを続けたものであり、間にセパレータ（「％」）が入っている。マップの値はベンダーモデルＩＤの数字である。このＩＤはベンダーモデルを一意的に特定する。プロトコルはこのＩＤを使用することもできる。例えば、ＨＴＴＰプロトコルは、あるベンダーとモデルのデバイスの一意的ＩＤを取得するために使用される、図４０のマップストラクチャ中のベンダーモデルＩＤを使用する。このマップm_VendorModelIDMapには、図２１のsupportデータベースのテーブルからの情報がエントリされる。
【０１３３】
図３３は、NormalizedVendorModelODBCパッケージのクラス図である。このパッケージは、ベンダー名を標準化したベンダー名にマップし、モデル名を標準化したモデル名にマップし、ベンダー名とモデル名をＩＤにマップする情報を取得するために、supportデータベースとインターフェイスしている。CNormalizedVendorModelODBCクラス３３００はこのパッケージのインターフェイスであり、他のクラスを管理して、supportデータベースのテーブルから適当な情報を取得する。CXXXDataクラス３３０６と３３０２と、それに対応するCXXXTableクラス３３０８と３３０４とは、図２１に示したsupportデータベースのＸＸＸテーブルにアクセスしてそのテーブルから情報を取得する。
【０１３４】
図３４は、デバイスからプロトコルにより取得したベンダー名とモデル名から、標準化したベンダー名と標準化したモデル名とを決定するプロセスを示すフローチャートである。標準化ベンダー名と標準化モデル名を取得するプロセスは、図２２に示したCNormalizedVendorModelのインターフェイス関数の呼び出しに対応する。プロセスはステップ３４０２で始まり、プロトコルがデバイスからベンダー名とモデル名を取得する。取得したベンダー名とモデル名は、標準化された名前であってもなくても、プロトコルが知っている名前に対応する。ステップ３４０４において、取得したベンダー名から、そのベンダー名が標準化ベンダーのルックアップテーブルにあるか判断する。このプロセスは、ベンダー名が図３０のマップm_NormalizedVendorMapのキーの１つであるかチェックする。そうでなければ、プロセスは、標準化ベンダー名とモデル名を取得せずに完了する。キーの１つであれば、プロセスはステップ３４０６に進む。ステップ３４０６において、標準化ベンダー名のキーに対応するマップの値を取得する。ステップ３４０８において、標準化ベンダー名とプロトコルにより取得したモデル名とにより、標準化ベンダー名とモデル名が％で分離されたストリングを生成する。ステップ３４１０において、ストリングを使用して、モデル名が標準化モデルルックアップテーブルにあるかチェックする。このプロセスは、ストリングが図３１のマップm_NormalizedModelMapのキーの１つであるかチェックする。そうでなければ、プロセスは、標準化ベンダー名を取得するだけで完了する。キーの１つであれば、プロセスはステップ３４１２に進む。ステップ３４１２において、標準化モデル名のキーに対応するマップの値を取得する。プロセスは、取得した標準化ベンダー名と標準化モデル名で完了する。
【０１３５】
図３４のフローチャートは、プロトコルが標準化ベンダーとモデルを取得する一例である。プロトコルがベンダーモデルＩＤを必要であれば、プロセスには、標準化ベンダー名とモデル名を使用して、図３２のマップm_VendorModelIDMapからＩＤを取得するステップが入る。すべてのプロトコルが標準化した情報を取得する必要はない。プロトコルはクラスCNormalizedVendorModelから欲しい情報で変わるので、図３４のフローチャートは可能性のある多数のプロセスのうちの１つである。
【０１３６】
図３５は、ＨＴＴＰパッケージのパッケージ図である。このパッケージはデバイスのウェブページからの情報取得をサポートする。このパッケージは、上で図２２に示した抽象クラスCAbsProtocolを使用する。CHTTPProtocolクラスはCAbsProtocolから作られる。CHTTPProtocolはＨＴＴＰパッケージのインターフェイスであり、デバイスから情報を取得するために図３７と３８に示したパッケージHTTPaccessとHTTPODBCを管理する。ＨＴＴＰパッケージは、標準化ベンダー名と標準化モデル名とベンダーモデルＩＤとに関する情報を得るため、図２２に示したクラスCNormalizedVEndorModelを使用する。ＨＴＴＰパッケージは、デバイスのウェブページの情報を見つけてそれを取得するために、図３６に示すストラクチャ（structure）SKeyValueInfoを含み、使用する。SKeyValueInfoのデータ要素は、図１９に示したデータベースのテーブルから取得される。
【０１３７】
図３６は、ウェブページの情報を見つけてそれを取得する、図３５のＨＴＴＰパッケージで使用されるストラクチャSKeyValueInfoを示す図である。m_infoTypeは情報の種類を表す数である。例えば、m_infoType値の６０１はネットワークデバイスにより印刷されたトータルページを表し、m_infoType値の７００は残りの黒トナーレベルを表す。m_nRelativePriorityはＨＴＴＰプロトコルにより取得される情報の重み（weight）を表す。m_nRelativePriorityが他のプロトコルよりも高いと、ＨＴＴＰで取得した情報がより情報量が多く望ましいということを示す。m_nRelativePriorityが他のプロトコルよりも低いと、他のプロトコルですでにその情報を取得できていればＨＴＴＰプロトコルで取得する情報は使用しないことを示す。sKeyのベクトルはウェブページから所望の情報を見つけるために使用するストリングのベクトルである。このストリングにより、ＨＴＴＰプロトコルが所望の情報を含むラインへナビゲート（navigate）する。ストリングはベクトル中にある順序で配置され、各々が検索されウェブページ中に見つかれば見つかるほど、ＨＴＴＰプロトコルが所望の情報を含むラインに近い。ベクトル中の最後のストリングがウェブページのラインで特定されると、次のラインは所望の情報を含む。ストリングは、目的のラインの前の最終ラインを特定するシーケンス番号とともに、図１９のHTTPWebPagePreconditionsテーブルから取得される。ストリングは、図１９のHTTPWebPageExtractFromLine、m_sFrontDelete１、m_sFrontDelete２、及びm_sBackDeleteから取得され、所望の情報を含むラインからその情報を取得（extract）するために使用される。m_sFrontDelete１とm_sFrontDelete２は、所望の情報の前のストリングを削除するために使用され、m_sBackDeleteは、所望の情報の後のストリングを削除するために使用される。
【０１３８】
図３７は、HTTPaccessパッケージのパッケージ図である。このパッケージはネットワークデバイスとのＨＴＴＰセッションの開始と終了、及びデバイスのウェブページからの情報の取得に使用される。クラスCHTTPaccessは、このパッケージのインターフェイスであり、パッケージのタスクを実行する他のクラスを管理する。クラスCHTTPSessionはデバイスとのＨＴＴＰセッションの開始と終了、及びそのデバイスのウェブページへのアクセスを行う。クラスCHTMLProcessorはデバイスのウェブページのラインを処理して、所望の情報を見つけて取得する。クラスCextractValueFromLineは所望の情報を含むウェブページのラインを処理し、情報を取得する。クラスCinternetSession、ChttpConnection、及びChttpFileはマイクロソフトファウンデーションクラス（ＭＦＣ）のクラスであり、CHTTPSessionにより使用されデバイスのウェブページにアクセスする。
【０１３９】
図３８は、HTTPODBCパッケージのパッケージ図である。このパッケージは、supportデータベースとインターフェイスして、デバイスのウェブページからモデル名、一意的識別子、及びステータス情報を取得するために使用する情報を取得する。CHTTPODBCクラス３８００はこのパッケージのインターフェイスであり、他のクラスを管理して、supportデータベースのテーブルから適当な情報を取得する。CHTTPXXXDataクラス３８０２、３８０６、３８１０、３８１４、３８１８、及び３８２２と、それに対応するCHTTPXXXTableクラス３８０４、３８０８、３８１２、３８１６、３８２０、３８２４とは、図１９に示したsupportデータベースのＸＸＸテーブルにアクセスしてそのテーブルから情報を取得する。
【０１４０】
図３９は、ウェブページからモデル名を取得する、図３５のＨＴＴＰパッケージで使用されるマップストラクチャを示す図である。マップストラクチャm_VendorModelSearchMapは、CHTTPProtocolの属性メンバーである。マップのキーは標準化モデル名のストリングである。マップの値はペア（pair）のベクトルである。ペアの第１の要素は、モデル名を含むウェブページの名前であり、ペアの第２の要素はウェブページで見つかるモデル名全てのストリングのベクトルである。あるベンダー名に対して、マップストラクチャはそのデバイスのモデル名を含むだろうすべてのウェブページを含む。各ウェブページはそれで見つかる少なくとも１つのモデル名を含む。ウェブページにアクセス可能なら、そのウェブページの各ラインを検索してモデルストリングの１つが見つかるか調べる。見つかれば、デバイスのベンダーとモデルが見つかる。モデルが見つからなければ、ウェブページがアクセス可能なのでベンダーが分かるが、モデルはサポートされていない。しかし、ＨＴＴＰプロトコルは、ベンダー名しか分からなければ、デバイスのステータス情報の取得はサポートしない。ウェブページで見つかるベンダー名よりも標準化ベンダー名をマップで使用する。その理由は、ウェブページにアクセスできるなら、そのウェブページはベンダーと関連づけられており、標準化ベンダーを使用することができる。このマップストラクチャはsupportデータベースからの情報がエントリされる。このマップをどう使用するかは図４４から４６を参照して説明する。
【０１４１】
図４０は、デバイスのウェブページから一意的ＩＤを取得する、図３５のＨＴＴＰパッケージで使用されるマップストラクチャを示す図である。マップストラクチャm_UniqueIDSearchMapは、CHTTPProtocolの属性メンバーである。マップへのキーは、ベンダーモデルＩＤである整数である。このＩＤは、図３２のマップm_VendorModelIDMapの標準化されたベンダーと標準化されたモデルに対応する。マップの値はペア（pair）である。ペアの第１の要素は一意的ＩＤを含むウェブページの名前である。ペアの第２の要素は、ストラクチャSKeyValueInfoのベクトルである。ベクトルは１つのSKeyValueInfoストラクチャのみを含む。ウェブページから一意的ＩＤを取得するには１つだけでよいからである。デバイスのベンダーとモデルが分かると、一意的ＩＤがこのマップストラクチャからの情報を用いて取得される。このマップストラクチャは、supportデータベース中の、図１９のテーブルからの情報がエントリされる（populated）。
【０１４２】
図４１は、監視されるすべてのデバイスのウェブページからステータス情報を取得する、図３５のＨＴＴＰパッケージで使用されるデータ構造を示す図である。マップストラクチャm_VendorModelSearchMapは、CHTTPProtocolの属性メンバーである。マップのキーは標準化ベンダーと標準化モデル名とが％で分離されたストリングである。マップの値はペア（pair）のベクトルである。ペアの第１の要素は１つ以上のステータス情報を含むウェブページの名前である。ペアの第２の要素は、ストラクチャSKeyValueInfoのベクトルである。ベクトルは、ウェブページからすべてのステータス情報を取得するSKeyValueInfoストラクチャを含む。あるベンダーとモデルに対して、ベクトルはステータス情報を取得できるすべてのウェブページのペアを含む。デバイスについてベンダーとモデルが決定されると、そのデバイスからのステータス情報の取得に関する情報をsupportデータベースから取得して、マップストラクチャに追加する。このマップをどう使用するかは図４７から５０を参照して説明する。
【０１４３】
図４２は、デバイスのウェブページからステータス情報を取得する、図３５のＨＴＴＰパッケージで使用されるベクトルストラクチャを示す図である。ベクトルストラクチャm_ExtractionStateVectorはCHTMLProcessorの属性メンバーである。ベクトルストラクチャはストラクチャSextractionStateのベクトルである。ストラクチャSExtractionStateeはウェブページからステータス情報を取得するための情報を含む。  図４７は、ステータス情報を取得するために使用するためにストラクチャをいかに使用するかを示すフローチャートである。ベクトルストラクチャはウェブページから、ベンダーとモデルを除くすべての情報を取得するための情報を含む。ストラクチャSExtractionStateはストラクチャSKeyValueInfoからの情報を使用して、ウェブページからステータス情報を取得する。SExtractionStateのm_infoType、m_nRelativePriority、m_sFrontDelete１、m_sFrontDelete２、及びm_sBackDeleteは、ストラクチャSKeyValueInfoのものと同じである。反復子（iterator）m_CurrentPreconditionItrを使用して、SKeyValueInfoのsKeyのベクトル中のキーストリングにわたって繰り返し、一方、反復子m_EndItrを使用してsKeyのベクトルの終わりを指す。反復子m_CurrentPreconditionItrはsKeyを指し、最初にsKeyのベクトルの最初の要素を指すように設定される。ウェブページのラインがsKeyを含む場合、反復子（iterator）はインクリメントされ、検索される次のsKeyを指す。反復子が終わりに到達すると（m_EndItrに等しくなると）、ウェブページの次のラインは所望のステータス情報を含む。m_LineStateは、値ePreTargetLine、eTargetLine、及びeFinishedを有する一覧ELいねStatusである。m_LineStateの値は、ステータス情報を見つけた状態を維持する。m_LineStateがePreTargetLineであるとき、システムは、まだステータス情報を見つけるためにベクトルのsKeyを検索している。反復子m_CurrentPreconditionItrがベクトルの終わりでない限り、m_LineStateはePreTargetLineである。反復子m_CurrentPreconditionItrがベクトルの終わりに到達すると、ベクトルのsKeyはすべて見つかっており、m_LineStateはeTargetLineになり、ステータス情報はウェブページの次のラインから取得される。ステータス情報がウェブページの次のラインから取得されると、m_LineStateはeFinishedになる。
【０１４４】
図４３は、デバイスのウェブページからのベンダー名、モデル名、及び一意的識別子の取得を示すシーケンス図である。CHTTPProtocolのobtainXXX()関数（ここで、ＸＸＸはベンダー、モデル、一意的ＩＤ、またはベンダーモデル一意的ＩＤである）はデバイスに関する情報を取得するシーケンスを開始する。関数obtainXXX()は自分の関数obtainDeviceInfo()を呼ぶ。この関数はベンダー名、モデル名、及び一意的ＩＤを取得する。図のobtainDeviceInfor()に続くシーケンスはすべてその関数内で実行される。ＨＴＴＰセッションはCHTTPaccessのinitiateHTTP()関数の呼び出しにより開始される。次に、CHTTPaccessのobtainVendorModel()が呼び出され、デバイスのウェブサイトからモデル名を所得する。この関数は、モデルが取得されるまで、異なるウェブページを入力して複数回呼ばれる。モデル名が所得されると、図３９のマップストラクチャm_VendorModelSearchMapに基づき標準化ベンダー名が分かる。モデル名が取得されると、CNormalizedVendorModelの関数obtainNormalizedModelID()が標準化モデル名とベンダーモデルＩＤを求めるために呼ばれる。次に、デバイスの一意的ＩＤが自分の関数obtainUniqueIDInDevice()を呼ぶことにより求められる。この関数において、図４０のマップストラクチャm_UniqueIDSearchMapを使用して、一意的ＩＤを含むウェブページを求め、CHTTPaccessの関数obtainDataFromHTTPFile()を呼んで、ウェブページから一意的ＩＤを取得する。ベンダーとモデル名が分かると、自分の関数populateVendorModelStatusMap()を呼んで、デバイスのウェブページから得られるステータス情報に関する情報を、図４１のマップストラクチャm_VendorModelStatusMapにエントリ（populate）する。populateVendorModelStatusMap()は、CHTTPODBCのobtainHTTPWebPageKeyValueInfo()を呼んで、マップストラクチャに、supportデータベースの図１９のテーブルからの情報を入れる（populate）。ＨＴＴＰセッションはCHTTPaccessのcloseHTTP()関数の呼び出しにより終了（close）される。
【０１４５】
図４４は、図３９のマップ構造を使用するデバイスのウェブページからモデル名を取得するプロセスを示すフローチャートである。マップストラクチャは、あるベンダーに対して、モデル名を取得できる異なるモデルに対応する複数のウェブページがあることを示している。ウェブページにアクセスできると、そのウェブページに関連付けられているので、ベンダー名が分かる。多数のモデルがモデル名を示すために同じウェブページを使用することもあるので、モデル名が見つかるまで、ウェブページの各ラインのすべてのモデル名を検索する。フローチャートでは、ウェブページからラインが取得される。もうラインが取得できない場合、ウェブページにはアクセスできベンダー名も分かったが、モデル名を取得するプロセスは失敗する。ラインが取得されると、そのラインをチェックして、そこにどれかのモデル名があるかチェックする。なければ、ウェブページの次のラインを取得する。そうでなければ、ライン中に見つかったモデル名から、標準化モデル名を求め、プロセスを完了する。
【０１４６】
図４５は、デバイスのモデル名を含むそのデバイスのウェブページの一部の例を示す図である。この部分はウェブページのＨＴＭＬソースであり、ウェブブラウザでは見ることができない。ウェブページから分かるように、デバイスのモデル名はLaserJet９０００である。図４４のプロセスは、このモデル名を含むウェブページの最初のラインを読む。このウェブページから見つかるかも知れない各モデル名をこのライン中で検索する。LaserJet９０００がＨＴＴＰプロトコルでサポートされていないとき、モデル名を見つからず、このデバイスはＨＴＴＰプロトコルではサポートされておらず、監視されない。そうでなければ、デバイスの一意的ＩＤを求め、デバイスからステータス情報を取得する情報を求め、デバイスからステータス情報を取得する。
【０１４７】
図４６は、図４５に示したウェブページからモデル名を取得するために使用される、図３９のマップストラクチャのサンプル値を示す図である。モデル名を取得するため、システムは、一度に１ベンダーずつマップストラクチャに当たり、ベクトルペア中のウェブページにアクセスを試み、ウェブページにアクセスできたら、ベクトルベア中のモデル名の１つが見つかるか判断（determine）する。同じ値に対して、ベンダーＨＰが最初に使用される。ペアのベクトルから、システムはウェブページ“/hp/device/this.LCDispatcher?dispatch=html&cat=０&pos=１”へのアクセスを試みる。ウェブページにアクセスできると、システムはウェブページのラインを読み、次のモデル名の１つを見つける：“HP  Color  LaserJet  ４５５０”、“HP  LaserJet  ９０００  Series”、または“hp  color  LaserJet  ５５０”。どれかが見つかれば、そのモデル名が所得される。見つからなければ、システムはＨＰに対応する次のウェブページ“/hp/device/this.LCDispatcher?nav=hp.Config”をチェックし、モデル名“hp  LaserJet  ４３４５  mfp”が見つかるか調べる。ＨＰに対応するウェブページのどれにもアクセスできなければ、プロセスはＸｅｒｏｘに対して繰り返される。
【０１４８】
図４７は、図４０、４１、及び４２のデータストラクチャを使用する、デバイスのウェブページからステータス情報を取得するプロセスを示すフローチャートである。図４１のマップストラクチャは、あるベンダーとモデルに対して、異なるステータス情報が得られる複数のウェブページがあることを示している。各ウェブページにアクセスしてステータス情報を取得する。フローチャート中、図４２のSExtractionStateのコンポーネントを使用する。このフローチャートはウェブページから１つのステータス情報を取得するプロセスを示す。しかし、同時にそのウェブページから２つ以上のステータス情報を取得することもでき、そこでフローチャートのプロセスは一意的ＩＤとウェブページから得られたすべてのステータス情報を使用する。左がわのテスト、すなわち図４７のステップ４７００−４７１０は、図４２に示したSextract状態のベクトルの各々に対して行われる。SExtractionStateの反復子m_CurrentPreconditionItrをチェックして、ステータス情報を含むラインを見つけるために使用されるsKeyのベクトルのいずれかのsKeyがあるか調べる。まだsKeyがあれば、ウェブページからラインを取得する。そのラインがsKeyを含まなければ、他のラインをウェブページから取得する。ラインがsKeyを含む場合、次のsKeyに反復子をインクリメントする。sKeyがもうなければ（m_CurrentPreconditionItrがm_EndItrと等しければ）、ステータス情報は次のラインにある。次のラインがあればウェブページから取得する。m_sFrontDelete１を含みそれまでのすべてのストリングを、ステータス情報を含むウェブページのラインをストリングから削除する。次に、m_sFrontDelete２を含みそれまでのストリングをラインから削除する。次に、m_sBackDeleteを含みそれ以降のすべてのストリングをラインから削除する。&nbsp等のラインのスペースを表すすべてのＨＴＭＬをブランクスペースに変換する。ライン中のすべての先行または後続のスペースをステータス情報から削除する。図４７に示したフローチャートの右側（ステップ４７２０−４７３２）は、図３７のCExtractValueFromLineにより実行される。
【０１４９】
図４８は、ステータス情報を含むデバイスのウェブページの一部の例を示す図である。ステータス情報は異なる色のトナーレベルである。ステータス情報はウェブページのjavaスクリプト内にある。すべてのカラートナーレベルのステータス情報を取得するため、情報を含むラインを見つけるために、sKeyストリングを特定しなければならない。例えば、黒トナーレベルを含むラインを見つけるため、そのラインを見つけるために必要なsKeyストリングは“var  YellowTonerPer”のみである。シアントナーレベルを含むラインを見つける他の例では、必要なsKeyストリングは“function  RemainTonerOption()”、“else”、及び“{“である。
【０１５０】
図４９は、図４８に示したウェブページからステータス情報を取得するために使用される、図４１のマップストラクチャのサンプル値を示す図である。マップストラクチャを用いてステータス情報を取得するため、ベンダーとモデル名のマップのペアのベクトルを取得する。ペアのベクトルは、ベンダーとモデルのステータス情報を含むすべてのウェブページと、そのウェブページから何のステータス情報を取得できるかに関する情報を含む。サンプル値は、三星社ＣＬＰ５５０の一ウェブページのみを示し、それから４つのステータス情報（カラートナーレベル）を取得することができる。三星ＣＬＰ５５０からステータス情報を取得するため、システムはペアのベクトルに当たる（go  through）。各ペアに対して、システムは、ウェブページにアクセスし、取得できるすべてのステータス情報を取得するまで、ウェブページからラインを読み出す。サンプル値の場合、システムは三星ＣＬＰ５５０プリンタのウェブページ“/panel/setup.htm”にアクセスする。システムは、各ステータス情報に関連するsKeyストリングを探すウェブページのすべてのラインを読む。ステータス情報のsKeyストリングがすべて見つかると、前削除（front  delete）と後削除（back  delete）を用いて次のラインからステータス情報を取得する。すべてのステータス情報を取得すると、システムはベクトルの次のペアのウェブページにアクセスして、その（次の）ウェブページからステータス情報を取得する。このプロセスはすべてのウェブページに対して繰り返される。
【０１５１】
図５０は、図４８に示したウェブページからステータス情報を取得するために使用される、図４２のベクトルストラクチャのサンプル値を示す図である。あるウェブページに対して、ベクトルストラクチャは各ステータス情報のストラクチャSExtractionStateを含む。各ストラクチャを使用して、ステータス情報を含むラインを見つけ、そのラインから所望の情報を取得する。最初、m_LineStateの値はePreTArgetLineである。各ラインをウェブページから読み出すにつれ、各m_CurrentPreconditionItrが指すベクトル中のsKeyがチェックされ、読み込まれたラインにそのsKeyがあるか調べる。あれば、m_CurrentPreconditionItrは次のキーに移る。これはsKeyがなくなるまで（m_CurrentPreconditonItrがm_EndItrと等しくなるまで）繰り返される。sKeyがない場合、m_LineStateは、ウェブページから読み出される次のラインがステータス情報を含むことを示すeTargetLineになり、SExtractionStateの前削除ストリングと後削除ストリングを用いて情報を取得する。
【０１５２】
図５１は、デバイスのＭＩＢから情報を取得するために使用されるＳＮＭＰパッケージを示すパッケージ図である。図５１はＳＮＭＰパッケージ２３０４の第１の実施形態を示すパッケージ図である。このパッケージは、ＳＮＭＰプロトコルによりサポートされたネットワークデバイスのベンダーとモデル、及びＳＮＭＰプロトコルによりネットワークデバイスから取得される情報を決定し、ＳＮＭＰプロトコルによりネットワークデバイスにアクセスしてそのネットワークデバイスから情報を取得する。このパッケージはパッケージSNMPaccess、SNMPODBC、クラスCSNMPProtocolを含み、図２２に示したように、クラスCnormalizedVendorModel２３１４、CAbsProtocol２３０８、及びCRecordset２３１０を使用する。SNMPaccessパッケージはＳＮＭＰプロトコルを実施し、ネットワークデバイスにアクセスし、そのネットワークデバイスから情報を取得する。SNMPODBCパッケージは、データベースにアクセスして、ＳＮＭＰプロトコルによりサポートされたネットワークデバイスのベンダーとモデルに関する情報と、ＳＮＭＰプロトコルによりネットワークデバイスから取得する情報とを取得する。CSNMPProtocolクラスはCAbsProtocolクラス２３０８から得られるクラスである。CSNMPProtocolは、ＳＮＭＰプロトコルを用いてネットワークデバイスから必要な情報を取得する。CSNMPProtocolは、図２２に示したように、CAbsProtocol２３０８のすべてのインターフェイス関数のメソッドを提供する。図５１は、CSNMPProtocolが使用するパッケージSNMPaccessとSNMPODBCの関数も示している。SNMPODBCパッケージは、クラスCRecordsetを使用してデータベースから情報を取得する。ＳＮＭＰプロトコルは、CNoromalizedVendorModelから標準化ベンダー名と標準化モデル名を取得して、すべてのプロトコルに対して共通な名前を使用することができる。
【０１５３】
図５２は、ＭＩＢからモデル名を取得する、図５１のＳＮＭＰパッケージで使用されるマップストラクチャを示す図である。マップストラクチャm_VendorModelsupportは、CSNMPProtocolの属性メンバーである。マップのキーはベンダー名のストリングである。マップの値はサポートされているすべてのモデルのストリングのベクトルである。ベンダー名は大文字化され、標準化ベンダー名には対応していない。モデル名はデバイスのＭＩＢにある名前であり、標準化モデル名には対応しない。ＳＮＭＰパッケージはあるベンダーのＭＩＢからそのデバイスのモデル名を含むストリングを取得する。次に、ＳＮＭＰパッケージは、そのモデル名を決定するため、ベクトル中のどのモデル名がストリングにあるかチェックする。このマップストラクチャは、supportデータベース中の、図１８のテーブルからの情報がエントリされる（populated）。
【０１５４】
図５３は、デバイスのＭＩＢからベンダー名、モデル名、一意的ＩＤを決定する、図５１のＳＮＭＰパッケージで使用されるマップストラクチャを示す図である。マップストラクチャm_VendorOIDInfoMapは、CSNMPProtocolの属性メンバーである。マップのキーはベンダー名のストリングである。マップの値は、オブジェクト識別子を表す３つのストリングよりなるストラクチャSVendorOIDInfoである。m_sEnterpriseOIDはベンダーに対応するエンタープライズオブジェクト識別子である。エンタープライズオブジェクト識別子はデバイスのベンダーを一意的に特定する。m_sOIDForModelは、モデル名を含むデバイスのＭＩＢからストリングを取得するために使用されるオブジェクト識別子である。このストリングは、図５２のデータストラクチャ中のモデル名のベクトルとともに、デバイスのモデル名を決定する。m_sOIDForUniqueIDは、デバイスの一意的ＩＤを含むデバイスのＭＩＢからストリングを取得するために使用されるオブジェクト識別子である。ベンダー名は大文字化され、標準化ベンダー名には対応していない。このマップストラクチャは、supportデータベース中の図１８のテーブルからの情報で満たされる（populated）。
【０１５５】
図５４は、監視されるすべてのデバイスのウェブページからステータス情報を取得する、図５１のＳＮＭＰパッケージで使用されるマップストラクチャを示す図である。マップストラクチャm_VendorModelOIDInfoは、CSNMPProtocolの属性メンバーである。マップのキーは標準化ベンダー名である。マップの値は他の内部マップ（inner  map）である。内部マップのキーは（GENERIC以外は）標準化ベンダー名である。あるベンダーに対して、GENERICモデルエントリは、あるステータス情報があるベンダーのすべてのモデルに対してそのデバイスから取得できることを示している。内部マップの値は、デバイスのＭＩＢからステータス情報を取得するために使用するペアのベクトルである。デバイスについてベンダーとモデルが決定されると、そのデバイスからのステータス情報の取得に関する情報をsupportデータベースから取得して、マップストラクチャに追加する。
【０１５６】
図５５は、標準化したベンダーとモデル名をＳＮＭＰにより分かるベンダーとモデル名にマッピング（mapping）するための、図５１のＳＮＭＰパッケージで使用されるマップストラクチャを示す図である。マップのキーは標準化ベンダー名とモデル名とが％で分離されたストリングである。マップの値はペア（pair）であり、その第１の要素はベンダー名であり、第２の要素はモデル名である。ペア中のベンダー名とモデル名はＳＮＭＰプロトコルで分かるデバイスの名前である。
【０１５７】
図５２と５３のマップストラクチャを、デバイスのベンダー名、モデル名、一意的ＩＤを発見する際のみに、反復プロセスで使用する。図５５のマップストラクチャは、図５４のマップストラクチャを満たすために使用され、初期化プロセス中に発見されたすべてのデバイスから集めるステータス情報を決定する。
【０１５８】
図５６は、ＳＮＭＰプロトコルにより、デバイスのベンダー名、モデル名、及び一意的ＩＤを取得するプロセスを示すフローチャートである。システムはデバイスとＳＮＭＰセッションを開始する。システムがＳＮＭＰセッションの開始を失敗すると、プロセスは終了し、ＳＮＭＰプロトコルはそのデバイスから情報を取得するには使用されない。システムは、そのデバイスとＳＮＭＰセッションを開始すると、そのデバイスのＭＩＢからシステム記述（description）を取得して、システム記述のストリングをすべて大文字に変換する。多くの場合、システム記述はベンダー名を含む。図５３のマップストラクチャの各ベンダー名をチェックして、ベンダー名がシステム記述中にあるか調べる。システムは、システム記述の取得に失敗するか、システム記述がマップストラクチャのいずれのベンダー名も含まないとき、デバイスからエンタープライズＯＩＤを取得する。コニカミノルタMagicolor３３００プリンタ等の一部のデバイスでは、システム記述中にベンダー名を含まない。図５３のマップストラクチャの各エンタープライズＯＩＤをチェックして、取得したエンタープライズＯＩＤにベンダー名が見つかるか調べる。マップ（図５３）中のエンタープライズＯＩＤの１つが見つかると、ベンダーが取得される。コニカミノルタMagicolor３３００プリンタの場合、エンタープライズＯＩＤを使用してベンダーを特定する。システムがエンタープライズＯＩＤの取得を失敗するか、エンタープライズＯＩＤが図５３のマップストラクチャのエンタープライズＯＩＤのどれも含まない場合、プロセスは終了する。しかし、ＳＮＭＰプロトコルを使用して、デバイスから一般情報を取得することはできる。ＳＮＭＰセッションを開始できるからである。ベンダー名を取得するシーケンスは反転できない。システム記述はエンタープライズＯＩＤの前にまずチェックしなければならない。多くの場合、システム記述はベンダー名を取得するのに十分である。ベンダーを特定するのにエンタープライズＯＩＤを必要とするケースは少ない。ベンダー名は、システム記述より前にエンタープライズＯＩＤをチェックすると、正しく特定できない。その理由は、多くのベンダーはＨＰのＯＩＤを使用しているので、ベンダーを特定するためにエンタープライズＯＩＤを使用すると、ＨＰとして認識されてしまう。しかし、システム記述では三星とブラザーのモデルは正しく特定される。ベンダー名がシステム記述かエンタープライズＯＩＤのいずれかで取得される場合、システムはそのデバイスのモデル名を取得しようと試みる。システムは、図５３のマップストラクチャから取得したベンダー名に対応するm_sOIDForModelのオブジェクト識別子を使用し、モデル名を含むデバイスのＭＩＢからストリングを取得する。図５２のマップストラクチャから取得したベンダー名に対応するベクトルの各モデル名をチェックして、デバイスから取得したストリングにあるか調べる。モデル名が取得できたかどうかにかかわらず、システムは次にデバイスの一意的ＩＤを取得しようと試みる。システムは、図５３のマップストラクチャから取得したベンダー名に対応するm_sOIDForUniqueIDのオブジェクト識別子を使用し、一意的ＩＤを含むデバイスのＭＩＢからストリングを取得する。システムは、ストリングを取得するか否かにかかわらず、デバイスのＳＮＭＰサポートを更新する。ＳＮＭＰサポートの更新により、図５４のマップストラクチャがデバイスのベンダーとモデルのステータス情報を取得するための情報で満たされる（populate）。ベンダーのみが分かると、一般的なステータス情報がマップストラクチャに追加される。ベンダーとモデルが分かると、一般的ステータスとモデル固有ステータス情報がマップストラクチャに追加される。ＳＮＭＰにより取得したベンダーとモデル名は、supportデータベースにある図１８のＳＮＭＰテーブルにある名前である。ベンダーとモデル名を決定するため、デバイスから取得した名前をマッチさせるためこれらの名前を使用する。これらの名前は、他のプロトコルにおいてベンダーとモデル名を特定するために使用する名前に対応する。しかし、ＳＮＭＰプロトコルにより取得されたベンダーとモデル名が他のすべてのプロトコルで取得されるようにするため、標準化したベンダー名とモデル名を用いる。標準化したベンダー名とモデル名はプロトコル間で共有される共通名である。それゆえ、ＳＮＭＰプロトコルにより取得されたベンダー名の標準化ベンダー名は図３０に示したルックアップテーブルを用いて取得し、ＳＮＭＰプロトコルにより取得されたモデル名の標準化モデル名は図３１に示したルックアップテーブルを用いて取得する。
【０１５９】
本発明は、ネットワーク中に少数のデバイスを含み、そのデバイスが監視を必要とするとして示したが、言うまでもなく、ネットワークに接続されるデバイスの数はいくつでもよく、そうしても本発明の精神と範囲から逸脱するものではない。また、本発明を適用するのは、家庭における環境のように、様々なデバイスを監視及び制御する必要がある環境であってもよい。
【０１６０】
本発明の実施形態によりマルチベンダー環境における様々なデバイスの監視が可能となり、プライベート管理情報ベース（ＭＩＢ）情報がなくてもユーザが理解できユーザフレンドリなやり方で詳細情報を読み出したり表示したりしやすくなる。さらに、情報をＳＭＴＰ、ＦＴＰ、ウェブサービス等の方法を用いて監視ステーション（９０２）から他のコンピュータ（９４０）に再配信ことができる。
【０１６１】
本発明のコントローラは、この明細書の教示に従ってプログラムされた既存の汎用デジタルコンピュータやマイクロプロセッサを用いて便利に実施することができ、このことはコンピュータ分野の当業者には明らかである。適当なソフトウェアコーディングは、この開示の教示に基づき技能のあるプログラマが容易に準備することができ、このことはソフトウェア分野の当業者には明らかである。本発明は、また、特定用途向け集積回路（ＡＳＩＣ）を作ることや、既存のコンポーネント回路を適当に相互接続することにより実施することもでき、このことは当業者には明らかである。
【０１６２】
本発明は、命令を含む記憶媒体上にあるコンピュータプログラム製品も含む。その命令は、コンピュータを本発明のプロセスを実行するようにプログラムするために使用できる。この記憶媒体には次のもの含むが、これに限定はされない：フロッピー（登録商標）ディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスク等のあらゆる種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、磁気カード、光カードその他の電気的命令を格納するのに好適なあらゆる媒体。
【０１６３】
上記の教示を考慮して、本発明の多くの修正と変形が可能である。それゆえ、言うまでもなく、添付した請求項の範囲内において、ここで具体的に説明していなければ本発明を実施できる。
【図面の簡単な説明】
【０１６４】
【図１】インターネットを通じてコンピュータとデータベースのネットワークと接続された、ネットワークビジネルオフィスデバイスを示す図である。
【図２】デジタル画像形成装置のコンポーネントを示す図である。
【図３】図２に示したデジタル画像形成装置の電気的コンポーネントを示す図である。
【図４】図３に示したマルチポート通信インターフェイスの詳細を示す図である。
【図５】ビジネスオフィスデバイスが、ネットワークに直接接続されているか、ネットワークに接続されているコンピュータに接続されている別のシステム構成を示す図である。
【図６Ａ】電子メールを用いてアプリケーションユニットとの間の情報のフローを示すブロック図である。
【図６Ｂ】アプリケーションユニットに接続されたコンピュータがメッセージトランスファエージェント（ＭＴＡ、Message  Transfer  Agent）としても機能する、電子メールを用いた別の通信方法を示す図である。
【図６Ｃ】アプリケーションユニットが電子メールを交換するメッセージトランスファエージェントを含む、電子メールを用いた別の通信方法を示す図である。
【図６Ｄ】メールサーバが、機器／デバイスのためにメールを受信するＰＯＰ３サーバ、及びその機器／デバイスのためにメールを送信するＳＭＴＰ（Simple  Mail  Transfer  Protocol）サーバとして動作する、電子メールを用いた別の通信方法を示す図である。
【図７】インターネットによりメッセージを送信する別の方法を示す図である。
【図８】機器／デバイスに接続され通信のために使用されるコンピュータの例を示す図である。
【図９】本発明の一実施形態によるシステム全体を示す概略図である。
【図１０】本発明の一実施形態によるデータ監視に使用するモジュールとそのインターフェイス機能とを示す。
【図１１Ａ】モニター（Monitor）モジュール内の詳細と、サブモジュール間の関数の呼び出しを示す図である。
【図１１Ｂ】図１１Ａに続く、モニター（Monitor）モジュール内の詳細と、サブモジュール間の関数の呼び出しを示す図である。
【図１２】図１０に示したモニターモジュールのinit関数を示すシーケンス図である。
【図１３】図１１に示した、MonitorManagerにより被監視デバイスのステータスを決定するステータスモニタ関数のシーケンス例を示す図である。
【図１４】図１２に示した、CdeviceFactoryにより生成されMonitorManagerにより使用されるデバイスを参照するベクトルを示す図である。
【図１５】本発明の一実施形態による被監視デバイスにアクセスするために必要なパラメータ値を記憶するために使用されるSparameterデータ構造を示す図である。
【図１６】本発明の一実施形態による被監視デバイスにアクセスするために必要なパラメータ値を記憶するために使用されるマップ構造を示す図である。
【図１７】本発明の一実施形態で使用されるモニター（monitor）データベースの構成を示す図である。
【図１８】本発明の一実施形態による通信プロトコルにより構成されたサポート（support）データベースの構成を示す図である。
【図１９】本発明の一実施形態によるＨＴＴＰプロトコルのサポート（support）データベースの構成を示す図である。
【図２０】本発明の一実施形態による通信プロトコルにより構成されたサポート（support）データベースの構成を示す図である。
【図２１】本発明の一実施形態によるベンダーとモデルとを規格化するためのサポート（support）データベースの構成を示す図である。
【図２２Ａ】本発明の一実施形態によるHwaccessパッケージ（package）を示すパッケージ図である。
【図２２Ｂ】図２２Ａに続く、本発明の一実施形態によるHwaccessパッケージ（package）を示すパッケージ図である。
【図２３】本発明の一実施形態による、被監視デバイスにアクセスしてその被監視デバイスからステータス（status）情報を取得するために必要な情報を維持するために、図２２のHwaccessモジュールで使用されるデータ構造を示す図である。
【図２４】Monitorパッケージのinit()が呼び出された時のクラスオブジェクトの初期化を示すシーケンス図である。
【図２５】デバイスがいずれかのプロトコルでアクセス可能であるかどうか決定する、HwaccessパッケージのcanAccessIP()を示すシーケンス図である。
【図２６】CHWaccessオブジェクトによる被監視デバイスからのベンダー情報、モデル情報、及び一意的ＩＤの取得を示すシーケンス図である。
【図２７】本発明の一実施形態による、被監視デバイスのステータス情報を取得するためにどのプロトコルを使用するか決定するために、被監視デバイスを表すソフトウェアオブジェクトにより使用されるデータ構造がいかに更新されるかを示すフローチャートである。
【図２８】本発明の一実施形態による、すべての通信プロトコルを用いて被監視デバイスからステータス情報を取得するプロセスを示すフローチャートである。
【図２９】本発明の一実施形態による、各プロトコルに対して、特定のベンダーとモデルの被監視デバイスのステータス情報を記憶し維持するために使用されるデータ構造を示す図である。
【図３０】被監視デバイスで見つけたベンダーに関する情報と標準化したベンダー名とを維持する、図２２のCNormalizedVendorModelオブジェクトで使用されるデータ構造を示す図である。
【図３１】システムによりサポートされるモデルに関する情報と使用される標準化したモデル名とを維持する、図２２のCNormalizedVendorModelオブジェクトで使用されるデータ構造を示す図である。
【図３２】システムによりサポートされるモデルの識別子に関する情報を維持する、図２２のCnormalizedVendorModelオブジェクトで使用されるデータ構造を示す図である。
【図３３】データベースの標準化したベンダーとモデルの情報にアクセスするための、NormalizedVendorModelODBCパッケージを示すクラス図である。
【図３４】デバイスからプロトコルにより取得したベンダー名とモデル名から、標準化したベンダー名と標準化したモデル名とを決定するプロセスを示すフローチャートである。
【図３５】ウェブページからの情報の取得をサポートするＨＴＴＰパッケージを示すパッケージ図である。
【図３６】ウェブページから情報を取得する、図３５のＨＴＴＰパッケージで使用されるデータ構造を示す図である。
【図３７】情報を取得するためにウェブページへのアクセスと処理をサポートする、図３５のHTTPaccessパッケージを示すパッケージ図である。
【図３８】様々なベンダーとモデルのデバイスのウェブページから情報を取得（extract）するための情報を取得（obtain）するためのデータベースへのアクセスをサポートする、図３５のHTTPODBCパッケージを示すパッケージ図である。
【図３９】ウェブページからモデル名を取得する、図３５のＨＴＴＰパッケージで使用されるデータ構造を示す図である。
【図４０】ウェブページから一意的識別子を取得する、図３５のＨＴＴＰパッケージで使用されるデータ構造を示す図である。
【図４１】監視されるすべてのデバイスのウェブページからステータス情報を取得する、図３５のＨＴＴＰパッケージで使用されるデータ構造を示す図である。
【図４２】デバイスのウェブページからステータス情報を取得する、図３５のＨＴＴＰパッケージで使用されるデータ構造を示す図である。
【図４３】デバイスのウェブページからのベンダー名、モデル名、及び一意的識別子の取得を示すシーケンス図である。
【図４４】図３９のデータ構造を使用するデバイスのウェブページからモデル名を取得するプロセスを示すフローチャートである。
【図４５】デバイスのモデル名を含むそのデバイスのウェブページの一部の例を示す図である。
【図４６】図４５に示したウェブページからモデル名を取得するために使用される、図３９のデータ構造のサンプル値を示す図である。
【図４７】図４１と図４２のデータ構造を使用する、デバイスのウェブページからステータス情報を取得するプロセスを示すフローチャートである。
【図４８Ａ】ステータス情報を含むデバイスのウェブページの一部の例を示す図である。
【図４８Ｂ】図４８Ａに続く、ステータス情報を含むデバイスのウェブページの一部の例を示す図である。
【図４８Ｃ】図４８Ｂに続く、ステータス情報を含むデバイスのウェブページの一部の例を示す図である。
【図４９】図４８に示したウェブページからステータス情報を取得するために使用される、図４１のデータ構造のサンプル値を示す図である。
【図５０】図４８に示したウェブページからステータス情報を取得するために使用される、図４２のデータ構造のサンプル値を示す図である。
【図５１】デバイスのＭＩＢから情報を取得するために使用されるＳＮＭＰパッケージを示すパッケージ図である。
【図５２】デバイスのＭＩＢからモデル名、一意的ＩＤ、及びステータス情報を取得するために使用されるＳＮＭＰパッケージのデータ構造を示す図である。
【図５３】デバイスのＭＩＢからモデル名、一意的ＩＤ、及びステータス情報を取得するために使用されるＳＮＭＰパッケージのデータ構造を示す図である。
【図５４】デバイスのＭＩＢからモデル名、一意的ＩＤ、及びステータス情報を取得するために使用されるＳＮＭＰパッケージのデータ構造を示す図である。
【図５５】標準化したベンダー名とモデル名をＳＮＭＰにより分かるベンダー名とモデル名にマッピング（mapping）するために使用されるＳＮＭＰパッケージのデータ構造を示す図である。
【図５６】デバイスのベンダー名、モデル名、及び一意的ＩＤを取得するプロセスを示すフローチャートである。
【符号の説明】
【０１６５】
２４  デジタルコピー／プリンタ
２７  オフィス機器
２８  ファクシミリマシン
３２  プリンタ
５０  ファイアウォール
１６０  ＣＰＵ
１６２  ＲＡＭ
１６４  ＲＯＭ
１６６  マルチポートネットワークＩ／Ｆ
１７１  ローカル接続
１７２  Ｉ／Ｆコントローラ
１７４  操作パネル
１７６  記憶装置Ｉ／Ｆ
１７８  フラッシュメモリ
１８４  オプションＩ／Ｆ
１８７  クロック／タイマー
１８８  オプショナルユニットインターフェイス
１９０  フューザ
１９２  プリンタ／イメージャ
１９４  スキャナ
１９６  用紙送りコントローラ
１９８  大容量トレイユニット
２００  デュプレクサ
２０２  ソータ
２２７  携帯電話インターフェイス
２２８  無線インターフェイス
２３０  イーサネット(登録商標)インターフェイス
２５４  サービスマシン
２５６  データ
２６０  イントラネット
２６２  プリンタ
２６４  インターネットサービスプロバイダ
２６６  コンピュータ
２６８  ビジネスオフィスデバイス
２７２  コンピュータ
２７４  ネットワーク
２７６  コンピュータ
２７８  ビジネスオフィスデバイス
２８５  ビジネスオフィス機器
２８２  コンピュータ
２８６  コピー機
３００  デバイス／機器
３０１  コンピュータ
３０２  デバイス／機器とのコンピュータインターフェイス
３０４  メールエージェント
３０６  送信メールのキュー
３０８  メッセージ転送エージェント
３１０  ＴＣＰ／ＩＰ接続
３１２  メッセージ転送エージェント
３１４  ユーザメールボックス
３１６  メールエージェント
３１８  端末のユーザ
３２０  送信ホスト
３２２  ローカルＭＴＡ
３２８  リレーＭＴＡ
３４２  受信ホスト
３６０  コンピュータ
３６２  ＣＰＵ
３６４  ＲＡＭ
３６６  無線インターフェイス
３６８  無線デバイス
３７０  ＲＯＭ
３７１  フラッシュメモリ(登録商標)
３７２  入力コントローラ
３７４  キーボード
３７６  マウス
３７８  シリアルインターフェイス
３８０  シリアルデバイス
３８２  パラレルインターフェイス
３８４  パラレルデバイス
３８６  ＵＳＢインターフェイス
３８８  ＵＳＢデバイス
３９０  システムバス
３９４  フロッピー(登録商標)デバイス
３９６  ディスクコントローラ
３９８  ＩＥＥＥ１３９４インターフェイス
４００  ＩＥＥＥ１３９４デバイス
４０４  ネットワーク
４０６  通信コントローラ
４０８  Ｉ／Ｏコントローラ
４１０  プリンタ
４１２  ハードディスク
４１４  ＣＲＴ
４１６  ディスプレイコントローラ
９０２  監視ステーション
９０４  サポートデバイス情報
９０６  データベース
９０８  リコーレーザプリンタ
９１０  ネットワークスキャナ
９１２  ベンダー１ネットワークデバイス
９１４  リコーＭＦＰ
９２４  アクセスポイント
９３０  メールサーバＰＯＰ３
９４０  ワークステーション
９６０  データベース
【図１】
2008065833.tif 000004
【図２】
2008065833.tif 000005
【図３】
2008065833.tif 000006
【図４】
2008065833.tif 000007
【図５】
2008065833.tif 000008
【図６Ａ】
2008065833.tif 000009
【図６Ｂ】
2008065833.tif 000010
【図６Ｃ】
2008065833.tif 000011
【図６Ｄ】
2008065833.tif 000012
【図７】
2008065833.tif 000013
【図８】
2008065833.tif 000014
【図９】
2008065833.tif 000015
【図１０】
2008065833.tif 000016
【図１１Ａ】
2008065833.tif 000017
【図１１Ｂ】
2008065833.tif 000018
【図１２】
2008065833.tif 000019
【図１３】
2008065833.tif 000020
【図１４】
2008065833.tif 000021
【図１５】
2008065833.tif 000022
【図１６】
2008065833.tif 000023
【図１７】
2008065833.tif 000024
【図１８】
2008065833.tif 000025
【図１９】
2008065833.tif 000026
【図２０】
2008065833.tif 000027
【図２１】
2008065833.tif 000028
【図２２Ａ】
2008065833.tif 000029
【図２２Ｂ】
2008065833.tif 000030
【図２３】
2008065833.tif 000031
【図２４】
2008065833.tif 000032
【図２５】
2008065833.tif 000033
【図２６】
2008065833.tif 000034
【図２７】
2008065833.tif 000035
【図２８】
2008065833.tif 000036
【図２９】
2008065833.tif 000037
【図３０】
2008065833.tif 000038
【図３１】
2008065833.tif 000039
【図３２】
2008065833.tif 000040
【図３３】
2008065833.tif 000041
【図３４】
2008065833.tif 000042
【図３５】
2008065833.tif 000043
【図３６】
2008065833.tif 000044
【図３７】
2008065833.tif 000045
【図３８】
2008065833.tif 000046
【図３９】
2008065833.tif 000047
【図４０】
2008065833.tif 000048
【図４１】
2008065833.tif 000049
【図４２】
2008065833.tif 000050
【図４３】
2008065833.tif 000051
【図４４】
2008065833.tif 000052
【図４５】
2008065833.tif 000053
【図４６】
2008065833.tif 000054
【図４７】
2008065833.tif 000055
【図４８Ａ】
2008065833.tif 000056
【図４８Ｂ】
2008065833.tif 000057
【図４８Ｃ】
2008065833.tif 000058
【図４９】
2008065833.tif 000059
【図５０】
2008065833.tif 000060
【図５１】
2008065833.tif 000061
【図５２】
2008065833.tif 000062
【図５３】
2008065833.tif 000063
【図５４】
2008065833.tif 000064
【図５５】
2008065833.tif 000065
【図５６】
2008065833.tif 000066