JP2008084314A - 合併企業のリモートデバイスのベンダー識別情報を取得するためのシステム、方法、及びコンピュータプログラム - Google Patents

合併企業のリモートデバイスのベンダー識別情報を取得するためのシステム、方法、及びコンピュータプログラム Download PDF

Info

Publication number
JP2008084314A
JP2008084314A JP2007233214A JP2007233214A JP2008084314A JP 2008084314 A JP2008084314 A JP 2008084314A JP 2007233214 A JP2007233214 A JP 2007233214A JP 2007233214 A JP2007233214 A JP 2007233214A JP 2008084314 A JP2008084314 A JP 2008084314A
Authority
JP
Japan
Prior art keywords
information
vendor
protocol
name
vendor name
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007233214A
Other languages
English (en)
Other versions
JP5114137B2 (ja
Inventor
Tetsuro Motoyama
モトヤマ テツロウ
Avery Curtis Fong
カーティス フォング アヴェリー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ricoh Co Ltd
Original Assignee
Ricoh Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ricoh Co Ltd filed Critical Ricoh Co Ltd
Publication of JP2008084314A publication Critical patent/JP2008084314A/ja
Application granted granted Critical
Publication of JP5114137B2 publication Critical patent/JP5114137B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03—Credit; Loans; Processing thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Technology Law (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Facsimiles In General (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】ベンダー名及び／または製品モデル名が異なる場合に、一様なベンダー名及び／または製品モデル名を取得する必要性がある。
【解決手段】被監視デバイスのベンダー名の変換方法である。該方法は、前記被監視デバイスから情報を取得するために第１の通信プロトコルを用いて前記被監視デバイスにアクセスする段階と、前記被監視デバイスから取得した前記情報に基づいて前記被監視デバイスのベンダー名を決定する段階と、前記被監視デバイスの標準化ベンダー名を前記決定したベンダー名を用いて決定する段階とを有する。
【選択図】図３４

Description

発明の詳細な説明
（関連出願との相互参照）
この出願は以下の共有に係る同時係属中の米国特許出願に関連している。
１. 第０９／４５３，９３７号、発明の名称「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ストラクチャに加えることができる。
Figure 2008084314
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）するために使用されるＳＮＭＰパッケージのデータ構造を示す図である。 デバイスのベンダー名、モデル名、及び一意的ＩＤを取得するプロセスを示すフローチャートである。
符号の説明
２４ デジタルコピー／プリンタ
２７ オフィス機器
２８ ファクシミリマシン
３２ プリンタ
５０ ファイアウォール
１６０ ＣＰＵ
１６２ ＲＡＭ
１６４ ＲＯＭ
１６６ マルチポートネットワークＩ／Ｆ
１７１ ローカル接続
１７２ Ｉ／Ｆコントローラ
１７４ 操作パネル
１７６ 記憶装置Ｉ／Ｆ
１７８ フラッシュメモリ
１８４ オプションＩ／Ｆ
１８７ クロック／タイマー
１８８ オプショナルユニットインターフェイス
１９０ フューザ
１９２ プリンタ／イメージャ
１９４ スキャナ
１９６ 用紙送りコントローラ
１９８ 大容量トレイユニット
２００ デュプレクサ
２０２ ソータ
２２７ 携帯電話インターフェイス
２２８ 無線インターフェイス
２３０ イーサネット(登録商標)インターフェイス
２５４ サービスマシン
２５６ データ
２６０ イントラネット
２６２ プリンタ
２６４ インターネットサービスプロバイダ
２６６ コンピュータ
２６８ ビジネスオフィスデバイス
２７２ コンピュータ
２７４ ネットワーク
２７６ コンピュータ
２７８ ビジネスオフィスデバイス
２８５ ビジネスオフィス機器
２８２ コンピュータ
２８６ コピー機
３００ デバイス／機器
３０１ コンピュータ
３０２ デバイス／機器とのコンピュータインターフェイス
３０４ メールエージェント
３０６ 送信メールのキュー
３０８ メッセージ転送エージェント
３１０ ＴＣＰ／ＩＰ接続
３１２ メッセージ転送エージェント
３１４ ユーザメールボックス
３１６ メールエージェント
３１８ 端末のユーザ
３２０ 送信ホスト
３２２ ローカルＭＴＡ
３２８ リレーＭＴＡ
３４２ 受信ホスト
３６０ コンピュータ
３６２ ＣＰＵ
３６４ ＲＡＭ
３６６ 無線インターフェイス
３６８ 無線デバイス
３７０ ＲＯＭ
３７１ フラッシュメモリ(登録商標)
３７２ 入力コントローラ
３７４ キーボード
３７６ マウス
３７８ シリアルインターフェイス
３８０ シリアルデバイス
３８２ パラレルインターフェイス
３８４ パラレルデバイス
３８６ ＵＳＢインターフェイス
３８８ ＵＳＢデバイス
３９０ システムバス
３９４ フロッピー(登録商標)デバイス
３９６ ディスクコントローラ
３９８ ＩＥＥＥ１３９４インターフェイス
４００ ＩＥＥＥ１３９４デバイス
４０４ ネットワーク
４０６ 通信コントローラ
４０８ Ｉ／Ｏコントローラ
４１０ プリンタ
４１２ ハードディスク
４１４ ＣＲＴ
４１６ ディスプレイコントローラ
９０２ 監視ステーション
９０４ サポートデバイス情報
９０６ データベース
９０８ リコーレーザプリンタ
９１０ ネットワークスキャナ
９１２ ベンダー１ネットワークデバイス
９１４ リコーＭＦＰ
９２４ アクセスポイント
９３０ メールサーバＰＯＰ３
９４０ ワークステーション
９６０ データベース

Claims (18)

  1. 被監視デバイスのベンダー名の変換方法であって、
    前記被監視デバイスから情報を取得するために第１の通信プロトコルを用いて前記被監視デバイスにアクセスする段階と、
    前記被監視デバイスから取得した前記情報に基づいて前記被監視デバイスのベンダー名を決定する段階と、
    前記被監視デバイスの標準化ベンダー名を前記決定したベンダー名を用いて決定する段階とを有する方法。
  2. 前記標準化ベンダー名を決定する段階は、
    前記決定したベンダー名を前記標準化ベンダー名にマップするデータベースにアクセスする段階を有する、請求項１に記載の方法。
  3. 前記標準化ベンダー名を決定する段階は、さらに、
    前記標準化ベンダー名が少なくとも２つの会社名の組合せであると判断する段階と、
    前記少なくとも２つの会社名の個々の名前を前記標準化ベンダー名にマップするデータベースにアクセスする段階とを有する、請求項１に記載の方法。
  4. 前記標準化ベンダー名を決定する段階は、さらに、
    前記標準化ベンダー名が少なくとも２つの会社名の組合せであると判断する段階と、
    前記少なくとも２つの会社の名前の複数の組合せを前記標準化ベンダー名にマップするデータベースにアクセスする段階とを有する、請求項１に記載の方法。
  5. 前記被監視デバイスのベンダー名を取得するために第２の通信プロトコルを用いて前記被監視デバイスにアクセスする段階をさらに有し、
    前記第１の通信プロトコルと前記第２の通信プロトコルにより取得されるベンダー名は、大文字化、スペース、句読点、ハイフンのうちの１つにおいて異なる、請求項１に記載の方法。
  6. 前記第１と第２の通信プロトコルにより取得される前記決定されたベンダー名を、前記標準化ベンダー名に対応させて格納したデータベースにアクセスする段階をさらに有する、請求項５に記載の方法。
  7. 被監視デバイスのベンダー名を変換するコンピュータ読み取り可能媒体を有するコンピュータプログラムであって、
    前記被監視デバイスから情報を取得するために第１の通信プロトコルを用いて前記被監視デバイスにアクセスする命令と、
    前記被監視デバイスから取得した前記情報に基づいて前記被監視デバイスのベンダー名を決定する命令と、
    前記被監視デバイスの標準化ベンダー名を前記決定したベンダー名を用いて決定する命令とを有するコンピュータプログラム。
  8. 前記標準化ベンダー名を決定する命令は、
    前記決定したベンダー名を前記標準化ベンダー名にマップするデータベースにアクセスする命令を有する、請求項７に記載のコンピュータプログラム。
  9. 前記標準化ベンダー名を決定する命令は、
    前記標準化ベンダー名が少なくとも２つの会社名の組合せであると判断する命令と、
    前記少なくとも２つの会社名の個々の名前を前記標準化ベンダー名にマップするデータベースにアクセスする命令とを有する、請求項７に記載のコンピュータプログラム。
  10. 前記標準化ベンダー名を決定する命令は、
    前記標準化ベンダー名が少なくとも２つの会社名の組合せであると判断する命令と、
    前記少なくとも２つの会社の名前の複数の組合せを前記標準化ベンダー名にマップするデータベースにアクセスする命令とを有する、請求項７に記載のコンピュータプログラム。
  11. 前記被監視デバイスのベンダー名を取得するために第２の通信プロトコルを用いて前記被監視デバイスにアクセスする命令をさらに有し、
    前記第１の通信プロトコルと前記第２の通信プロトコルにより取得されるベンダー名は、大文字化、スペース、句読点、ハイフンのうちの１つにおいて異なる、請求項７に記載のコンピュータプログラム。
  12. 前記第１と第２の通信プロトコルにより取得される前記決定されたベンダー名を、前記標準化ベンダー名に対応させて格納したデータベースにアクセスする命令をさらに有する、請求項１１に記載のコンピュータプログラム。
  13. 被監視デバイスのベンダー名の変換システムであって、
    前記被監視デバイスから情報を取得するために第１の通信プロトコルを用いて前記被監視デバイスにアクセスする手段と、
    前記被監視デバイスから取得した前記情報に基づいて前記被監視デバイスのベンダー名を決定する手段と、
    前記被監視デバイスの標準化ベンダー名を前記決定したベンダー名を用いて決定する手段とを有するシステム。
  14. 前記標準化ベンダー名を決定する手段は、
    前記決定したベンダー名を前記標準化ベンダー名にマップするデータベースにアクセスする手段を有する、請求項１３に記載のシステム。
  15. 前記標準化ベンダー名を決定する手段は、さらに、
    前記標準化ベンダー名が少なくとも２つの会社名の組合せであると判断する手段と、
    前記少なくとも２つの会社名の個々の名前を前記標準化ベンダー名にマップするデータベースにアクセスする手段とを有する、請求項１３に記載の装置。
  16. 前記標準化ベンダー名を決定する手段は、さらに、
    前記標準化ベンダー名が少なくとも２つの会社名の組合せであると判断する手段と、
    前記少なくとも２つの会社の名前の複数の組合せを前記標準化ベンダー名にマップするデータベースにアクセスする手段とを有する、請求項１３に記載のシステム。
  17. 前記被監視デバイスのベンダー名を取得するために第２の通信プロトコルを用いて前記被監視デバイスにアクセスする手段を有し、
    前記第１の通信プロトコルと前記第２の通信プロトコルにより取得されるベンダー名は、大文字化、スペース、句読点、ハイフンのうちの１つにおいて異なる、請求項１３に記載のシステム。
  18. 前記第１と第２の通信プロトコルにより取得される前記決定されたベンダー名を、前記標準化ベンダー名に対応させて格納したデータベースにアクセスする手段をさらに有する、請求項１３に記載のシステム。
JP2007233214A 2006-09-08 2007-09-07 合併企業のリモートデバイスのベンダー識別情報を取得するためのシステム、方法、及びコンピュータプログラム Expired - Fee Related JP5114137B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/517,378 US7533086B2 (en) 2006-09-08 2006-09-08 System, method, and computer program product for obtaining vendor identification of a remote device of merged companies
US11/517,378 2006-09-08

Publications (2)

Publication Number Publication Date
JP2008084314A true JP2008084314A (ja) 2008-04-10
JP5114137B2 JP5114137B2 (ja) 2013-01-09

Family

ID=39170977

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007233214A Expired - Fee Related JP5114137B2 (ja) 2006-09-08 2007-09-07 合併企業のリモートデバイスのベンダー識別情報を取得するためのシステム、方法、及びコンピュータプログラム

Country Status (2)

Country Link
US (1) US7533086B2 (ja)
JP (1) JP5114137B2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012066652A1 (ja) * 2010-11-17 2012-05-24 株式会社日立製作所 通信ネットワークに接続されている通信装置を発見する方法及び管理装置
JP2013120428A (ja) * 2011-12-06 2013-06-17 Ricoh Co Ltd 情報処理装置、情報管理システム、情報処理プログラム

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6988141B1 (en) 2000-05-17 2006-01-17 Ricoh Company, Ltd. Method and system of remote diagnostic, control and information collection using a dynamic linked library of multiple formats and multiple protocols with restriction on protocol
US7392310B2 (en) * 2002-12-26 2008-06-24 Ricoh Company, Ltd. Method and system for using data structures to store database information for multiple vendors and model support for remotely monitored devices
US8595242B2 (en) 2003-06-13 2013-11-26 Ricoh Company, Ltd. 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
US8812629B2 (en) * 2008-04-18 2014-08-19 Universal Electronics Inc. System and method for configuring the remote control functionality of a portable device
US7533086B2 (en) 2006-09-08 2009-05-12 Ricoh Co., Ltd. System, method, and computer program product for obtaining vendor identification of a remote device of merged companies
JP5125330B2 (ja) * 2007-08-31 2013-01-23 ダイキン工業株式会社 空気調和システム
US8438273B2 (en) 2010-09-22 2013-05-07 Ricoh Company, Ltd. Network device management with self learning capability to extract information from a device
JP5929921B2 (ja) * 2012-01-12 2016-06-08 ソニー株式会社 情報記憶装置、情報処理システム、および情報処理方法、並びにプログラム
CN110851086A (zh) * 2019-10-11 2020-02-28 杭州珐珞斯科技有限公司 打印设备的数据读取方法、装置、系统及设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004326617A (ja) * 2003-04-25 2004-11-18 Takenaka Komuten Co Ltd 顧客情報整理プログラムおよび顧客情報整理方法
JP2006209754A (ja) * 2005-01-11 2006-08-10 Ricoh Co Ltd ネットワークを介して接続された被監視装置関連情報を抽出する方法、システム及びコンピュータプログラム

Family Cites Families (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6437692B1 (en) 1998-06-22 2002-08-20 Statsignal Systems, Inc. System and method for monitoring and controlling remote devices
US6317848B1 (en) 1998-09-24 2001-11-13 Xerox Corporation System for tracking and automatically communicating printer failures and usage profile aspects
US6421608B1 (en) 2000-07-12 2002-07-16 Ricoh Company Limited Method and system of remote position reporting device
US6961659B2 (en) 2000-07-12 2005-11-01 Ricoh Company Limited Method and system of remote position reporting device
US20020152292A1 (en) 2001-01-09 2002-10-17 Ricoh Company Limited Method and system of remote support of device using e-mail
US7389265B2 (en) * 2001-01-30 2008-06-17 Goldman Sachs & Co. Systems and methods for automated political risk management
US7533333B2 (en) 2001-02-14 2009-05-12 Ricoh Co., Ltd. Object-oriented method and system of remote diagnostic, control and information collection using multiple formats and multiple protocols
US20020133365A1 (en) * 2001-03-19 2002-09-19 William Grey System and method for aggregating reputational information
US7136914B2 (en) 2001-08-06 2006-11-14 Ricoh Company, Ltd. System, computer program product and method for managing and controlling a local network of electronic devices
US7536450B2 (en) 2001-09-17 2009-05-19 Ricoh Company, Ltd. System, method, and computer program product for sending remote device configuration information to a monitor using e-mail
US7302469B2 (en) 2001-09-17 2007-11-27 Ricoh Company, Ltd. System, method, and computer program product for transferring remote device support data to a monitor using e-mail
US6839717B1 (en) 2001-10-15 2005-01-04 Ricoh Company, Ltd. 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
US6925571B1 (en) 2001-10-15 2005-08-02 Ricoh Company, Ltd. Method and system of remote monitoring and support of devices, using POP3 and decryption using virtual function
US6702024B2 (en) * 2001-12-14 2004-03-09 Cilmore Valve Co., Ltd. Dual energized hydroseal
US7392310B2 (en) 2002-12-26 2008-06-24 Ricoh Company, Ltd. Method and system for using data structures to store database information for multiple vendors and model support for remotely monitored devices
US7647397B2 (en) 2002-02-27 2010-01-12 Ricoh Company Ltd. Method and apparatus for modifying remote devices monitored by a monitoring system
US7519729B2 (en) 2002-02-27 2009-04-14 Ricoh Co. Ltd. Method and apparatus for monitoring remote devices through a local monitoring station and communicating with a central station supporting multiple manufacturers
US7194537B2 (en) 2002-05-13 2007-03-20 Ricoh Co. Ltd. Method for scrambling information about network devices that is placed in email message
US7421474B2 (en) 2002-05-13 2008-09-02 Ricoh Co. Ltd. Verification scheme for email message containing information about remotely monitored devices
CA2398049A1 (en) * 2002-08-27 2004-02-27 Kevin W. Jameson Collection shortcut reference expander
US6889264B2 (en) 2002-10-09 2005-05-03 Hewlett-Packard Development Company, L.P. Imposing a delay for indication of a status board to provide a time for self-rectification of a service event detected from peripheral status information
US7500003B2 (en) * 2002-12-26 2009-03-03 Ricoh Company, Ltd. Method and system for using vectors of data structures for extracting information from web pages of remotely monitored devices
US7289995B2 (en) 2002-12-26 2007-10-30 Ricoh Company, Ltd. Method and system for using internal data structures for storing information related to remotely monitored devices
US8595242B2 (en) 2003-06-13 2013-11-26 Ricoh Company, Ltd. 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
US7447766B2 (en) 2003-06-13 2008-11-04 Ricoh Company, Ltd. Method for efficiently storing information used to extract status information from a device coupled to a network in a multi-protocol remote monitoring system
US7533167B2 (en) 2003-06-13 2009-05-12 Ricoh Company, Ltd. Method for efficiently extracting status information related to a device coupled to a network in a multi-protocol remote monitoring system
US20040255023A1 (en) 2003-06-13 2004-12-16 Tetsuro Motoyama Method and system for extracting vendor and model information in a multi-protocol remote monitoring system
US20050071483A1 (en) 2003-09-26 2005-03-31 Tetsuro Motoyama Method and system for supporting multiple protocols used to monitor networked devices in a remote monitoring system
US7519698B2 (en) 2003-09-26 2009-04-14 Ricoh Co., Ltd. Method and system for extracting information from networked devices in a multi-protocol remote monitoring system
US7610372B2 (en) 2004-01-27 2009-10-27 Ricoh Company, Ltd. Method and system for managing vendor and model information in a multi-protocol remote monitoring system
US7296079B2 (en) 2004-01-27 2007-11-13 Ricoh Company, Ltd. Method and system for initializing protocol information used to extract status information from networked devices
US7606894B2 (en) 2004-01-27 2009-10-20 Ricoh Company, Ltd. Method and system for determining the type of status information to extract from networked devices in a multi-protocol remote monitoring system
US20050177642A1 (en) 2004-01-27 2005-08-11 Tetsuro Motoyama Method and system for managing protocols used to obtain status information from a network device
US7519587B2 (en) * 2004-07-02 2009-04-14 Goldman Sachs & Co. Method, system, apparatus, program code, and means for determining a relevancy of information
US7502848B2 (en) 2004-08-27 2009-03-10 Ricoh Company Ltd. Method of creating a data processing object associated with a communication protocol used to extract status information related to a monitored device
US7610374B2 (en) 2004-08-27 2009-10-27 Ricoh Company Ltd. Method of initializing a data processing object associated with a communication protocol used to extract status information related to a monitored device
US7574503B2 (en) 2004-08-27 2009-08-11 Ricoh Company Ltd. Method and system for using abstract classes to extract status information from networked devices
US7581000B2 (en) 2005-01-11 2009-08-25 Ricoh Company, Ltd. 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
US7467195B2 (en) 2005-01-11 2008-12-16 Ricoh Company, Ltd. Method and system for extracting status information from networked devices using the SNMP protocol
US20060155845A1 (en) 2005-01-11 2006-07-13 Tetsuro Motoyama Method and system for initializing an internal storage table containing access information used by multiple implementations of protocol access functions to extract information from networked devices
US20060184659A1 (en) 2005-01-11 2006-08-17 Tetsuro Motoyama Method and system for extracting information from networked devices using multiple implementations of protocol access functions
US7533086B2 (en) 2006-09-08 2009-05-12 Ricoh Co., Ltd. System, method, and computer program product for obtaining vendor identification of a remote device of merged companies

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004326617A (ja) * 2003-04-25 2004-11-18 Takenaka Komuten Co Ltd 顧客情報整理プログラムおよび顧客情報整理方法
JP2006209754A (ja) * 2005-01-11 2006-08-10 Ricoh Co Ltd ネットワークを介して接続された被監視装置関連情報を抽出する方法、システム及びコンピュータプログラム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012066652A1 (ja) * 2010-11-17 2012-05-24 株式会社日立製作所 通信ネットワークに接続されている通信装置を発見する方法及び管理装置
JP5383927B2 (ja) * 2010-11-17 2014-01-08 株式会社日立製作所 通信ネットワークに接続されている通信装置を発見する方法及び管理装置
US8656011B2 (en) 2010-11-17 2014-02-18 Hitachi, Ltd. Method and management apparatus for detecting communication apparatus coupled to communication network
JP2013120428A (ja) * 2011-12-06 2013-06-17 Ricoh Co Ltd 情報処理装置、情報管理システム、情報処理プログラム

Also Published As

Publication number Publication date
US7533086B2 (en) 2009-05-12
US20080065584A1 (en) 2008-03-13
JP5114137B2 (ja) 2013-01-09

Similar Documents

Publication Publication Date Title
JP5060221B2 (ja) Ｈｔｔｐプロトコルを用いてリモートデバイスから情報を取得するシステム、方法、及びコンピュータプログラム製品
JP5114138B2 (ja) 複数のネットワークプログラムでリモートデバイスのベンダーとモデル名とを特定するシステム、方法、及びコンピュータプログラム製品
JP5114137B2 (ja) 合併企業のリモートデバイスのベンダー識別情報を取得するためのシステム、方法、及びコンピュータプログラム
JP2008065831A (ja) リモートデバイスからベンダー情報を取得するｓｎｍｐを使用するシステム、方法、及びコンピュータプログラム製品
US7296079B2 (en) Method and system for initializing protocol information used to extract status information from networked devices
US7610372B2 (en) Method and system for managing vendor and model information in a multi-protocol remote monitoring system
JP4728069B2 (ja) 被監視デバイスに関するステータス情報を抽出するための通信プロトコルに関連したデータ処理オブジェクトの生成方法
JP4925668B2 (ja) ネットワークを介して被監視装置を監視する監視装置、システム、方法、及びコンピュータプログラム
JP5090562B2 (ja) 機器のステータス情報を取得する監視装置、監視システム、方法、及びコンピュータプログラム
JP4728070B2 (ja) ネットワークデバイスからステータス情報を抽出するための抽象型クラス使用方法およびシステム
JP4925626B2 (ja) 被監視デバイスに関するステータス情報を抽出するための通信プロトコルと関連するデータ処理オブジェクトの初期化方法
JP4891019B2 (ja) 被監視装置のステータス情報を抽出する方法、コンピュータシステム及びコンピュータプログラム
EP1679822A1 (en) Method and system for extracting information from networked devices using multiple implementations of protocol access functions
EP1898556B1 (en) System, method and computer program product for extracting information from remote devices through the HTTP protocol
EP1679823A1 (en) Method and system for extracting information from networked devices using the HTTP protocol and precondition information
US20050177642A1 (en) Method and system for managing protocols used to obtain status information from a network device
JP2007095055A (ja) 被監視装置に格納されたウェブページからステータス情報を抽出するための方法、システム及びコンピュータプログラム
US20050165926A1 (en) Method and system for determining the type of status information to extract from networked devices in a multi-protocol remote monitoring system
EP1679824A1 (en) Method and system for extracting information from network devices using multiple protocol access functions
JP2007095057A (ja) 被監視装置に格納されたウェブページからステータス情報を抽出するための方法、システム及びコンピュータプログラム
JP2007095058A (ja) 被監視装置に格納されたウェブページからステータス情報を抽出するための方法、システム及びコンピュータプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100603

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20111214

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120104

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120305

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120918

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20121015

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151019

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5114137

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees