DE602006000826T2 - Verfahren und System zum Extrahieren von Informationen von Netzwerkgeräten unter Verwendung mehrerer Protokollzugriffsfunktionen - Google Patents

Verfahren und System zum Extrahieren von Informationen von Netzwerkgeräten unter Verwendung mehrerer Protokollzugriffsfunktionen Download PDF

Info

Publication number
DE602006000826T2
DE602006000826T2 DE602006000826T DE602006000826T DE602006000826T2 DE 602006000826 T2 DE602006000826 T2 DE 602006000826T2 DE 602006000826 T DE602006000826 T DE 602006000826T DE 602006000826 T DE602006000826 T DE 602006000826T DE 602006000826 T2 DE602006000826 T2 DE 602006000826T2
Authority
DE
Germany
Prior art keywords
information
monitored device
protocol
network
model
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.)
Active
Application number
DE602006000826T
Other languages
English (en)
Other versions
DE602006000826D1 (de
Inventor
Tetsuro Motoyama
Avery 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 DE602006000826D1 publication Critical patent/DE602006000826D1/de
Application granted granted Critical
Publication of DE602006000826T2 publication Critical patent/DE602006000826T2/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • H04L43/045—Processing captured monitoring data, e.g. for logfile generation for graphical visualisation of monitoring data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

  • HINTERGRUND DER ERFINDUNG
  • GEBIET DER ERFINDUNG
  • Diese Erfindung bezieht sich auf die Überwachung von Vorrichtungen, die mit einem Netz verbunden sind. Insbesondere bezieht sie sich auf ein Verfahren, ein System und ein Computerprogrammprodukt für die Fernüberwachung von mit einem Netz verbundenen Vorrichtungen unter Verwendung von mehreren Protokollen.
  • ERÖRTERUNG DES HINTERGRUNDES
  • Wie allgemein bekannt ist, umfassen Computersysteme Hardware und Software. Software umfasst eine Liste von Befehlen, die erzeugt werden, um Hardwarekomponenten, die ein Computersystem bilden, zu betreiben und zu managen. Typischerweise umfassen Computersysteme eine Vielfalt von Hardwarekomponenten/Vorrichtungen, die miteinander eine Schnittstelle bilden. Das Computersystem kann ein eigenständiger Typ oder ein vernetzter Typ sein. In einem Computersystem vom vernetzten Typ sind mehrere verschiedene Vorrichtungen mit einem Netz verbunden und folglich wird die Kommunikation zwischen diesen verschiedenen Vorrichtungen über das Netz ermöglicht.
  • Ferner muss eine Software zum Betreiben der Hardwarevorrichtungen konfiguriert sein, um eine Kommunikation zwischen den Hardwarevorrichtungen zu ermöglichen, so dass ermöglicht wird, dass die die Hardwarevorrichtungen gemeinsam funktionieren. Um eine solche Kommunikation zu erleichtern, ist es ferner auch erwünscht, dass Hardwarevorrichtungen überwacht werden und der Status jeder Hardwarevorrichtung identifiziert wird, um sicherzustellen, dass jede Hardwarevorrichtung in einer effizienten Weise funktioniert.
  • Für die Zwecke dieser Patentanmeldung hat der Erfindung festgestellt, dass eine Hardwarevorrichtung, die die mehreren verschiedenen Vorrichtungen oder Hardwarevorrichtungen steuert, konfiguriert oder überwacht, als Überwachungsvorrichtung bezeichnet werden würde, und die Hardwarevorrichtungen, die durch die Überwachungsvorrichtung gesteuert, konfiguriert oder überwacht werden, als "überwachte Vorrichtungen" bezeichnet werden würden.
  • Für Hardwarevorrichtungen, die sich in einem Netz befinden, ist es erwünscht, dass diese Vorrichtungen für die Wartung, Verwendung oder andere Zwecke überwacht werden. Angesichts von Herstellerunterschieden in Bezug auf Hardwarevorrichtungen und Schnittstellen kann es jedoch schwierig sein, dass eine Überwachungsvorrichtung mit verschiedenen anderen Vorrichtungen, die mit einem Netz verbunden sind, kommuniziert. Ein solcher Nachteil verhindert sehr wahrscheinlich, dass Netzadministratoren entscheidende Informationen über die Leistung und Effizienz der mit dem Netz verbundenen Vorrichtungen erhalten.
  • Das Simple Network Management Protocol (SNMP) ist heute ein tatsächlicher Industriestandard für die Überwachung und das Management von Vorrichtungen in Datenkommunikationsnetzen, Telekommunikationssystemen und anderen global erreichbaren Vorrichtungen. Praktisch jede Organisation, die mit Computern und zugehörigen Vorrichtungen umgeht, erwartet, jede solche Vorrichtung über lokale und weiträumige Netze zentral überwachen, diagnostizieren und konfigurieren zu können. SNMP ist das Protokoll, das diese Wechselwirkung ermöglicht.
  • Damit eine Vorrichtung auf SNMP-Anforderungen antwortet, ist es erwünscht, die Vorrichtung mit der Software auszustatten, die ihr ermöglicht, eine SNMP-Anforderung korrekt zu interpretieren, die von dieser Anforderung angeforderten Handlungen durchzuführen und eine SNMP-Antwort zu erzeugen. Die SNMP-Agentensoftware ist typischerweise ein Untersystem-Softwaremodul, das sich in einer Netzentität befindet.
  • Die Sammlung von Objekten, die von einem System implementiert werden, wird im Allgemeinen als Managementinformationsbasis (MIB) bezeichnet. Eine MIB kann auch eine Datenbank mit Informationen in Bezug auf die Überwachung von Vorrichtungen sein. Beispiele von anderen MIBs umfassen eine Ethernet-MIB, die sich auf Ethernet-Schnittstellen konzentriert; eine Brücken-MIB, die Objekte für das Management von 802.1D-Brücken definiert, um einige zu nennen.
  • Die Verwendung von SNMP für die Überwachung von Vorrichtungen ist schwierig, da private MIBs Werte umfassen, die ohne einen gültigen Schlüssel schwierig zu entschlüsseln sind. Eine Firma, die SNMP zum Überwachen von verschiedenen Vorrichtungen, die mit ihrem Netz verbunden sind, verwendet, erzeugt einen eindeutigen Identifizierer/Schlüssel, der als firmeneigene Information der Firma verwaltet wird. Größtenteils werden die Ergebnisse als binäre oder ganzzahlige Werte angezeigt. Folglich misslingt es unter Verwendung von SNMP Ergebnissen, die von den Vorrichtungen, die überwacht werden ("überwachte Vorrichtungen") empfangen werden, einen Benutzer mit dem Status der überwachten Vorrichtungen in einer für den Benutzer verständlichen Weise zu versehen.
  • Ferner ist es unter Verwendung von SNMP schwierig, detaillierte Informationen über eine überwachte Vorrichtung ohne einen gültigen Schlüssel oder Zugriff auf eine private MIB zu erhalten, um die als binäre oder ganzzahlige Werte erhaltenen Ergebnisse zu entschlüsseln. Außerdem kann ein gegebenes Protokoll (z. B. SNMP oder HTTP/HTML) aus verschiedenen Gründen, wie z. B. Zeitablauf oder verlorenen Paketen, versagen. Einige von einer gegebenen Vorrichtung unter Verwendung der mehreren Protokolle extrahierten Informationen können auch für jedes Protokoll dupliziert werden. Wenn die Extraktion von Daten von der Vorrichtung in solchen Situationen nicht korrekt gemanagt wird, ergeben sich folglich Zeit- und Speicherineffizienzen, da einige Protokolle mehr Ressourcen erfordern als andere Protokolle. Außerdem kann die Informationsextraktion unter Verwendung von einigen Protokollen viel weniger Verarbeitung und Speicher erfordern als unter Verwendung von anderen. Ferner können einige durch ein Protokoll erhaltenen Informationen für die Überwachungsvorrichtung nützlicher sein als die durch ein anderes Protokoll erhaltenen.
  • 38A–38C zeigen Beispiele von HTML-Dateien, von denen Informationen in Bezug auf überwachte Vorrichtungen extrahiert werden. 38A ist eine Webseite einer Vorrichtung, die den Status der verschiedenen Farbtoner zeigt. Einige Überwachungssysteme erhalten die Statusinformationen durch Tasten auf speziellen Text. Um beispielsweise den Status der Kassette mit schwarzem Toner zu erhalten, tastet ein System auf den Text "Schwarzer Toner". 38B ist die Webseite einer Vorrichtung, die ein Problem für einige Überwachungssysteme darstellt. Um den Status der Abbildungseinheit für irgendeine Farbe zu erhalten, würde ein System auf einen des Texts für die Farbe (d. h. Schwarz, Zyan, Magenta und Gelb) tasten. Das System würde jedoch auf einen der Texte vom Tonerkassettenstatus tasten, so dass die Statusinformationen für die Farbabbildungseinheiten falsch erhalten werden. Das Problem besteht darin, dass derselbe Text verwendet wird, um verschiedene Statusinformationen auf derselben Webseite zu erhalten. Die Statusinformationen werden gewöhnlich für das erste Auftreten des Texts erhalten. 38C ist eine weitere Webseite einer Vorrichtung, bei der ein System auf den Text "Gesamt" tasten würde, um die Statusinformationen für die Gesamtseitenzahl, die gesamten gedruckten Aufträge und das gesamte verwendete Papier zu erhalten. Das System würde auf das erste "Gesamt", das es antrifft, tasten und die Statusinformationen, die es für die gesamten gedruckten Aufträge und das gesamte verwendete Papier erhält, falsch zuweisen.
  • Folglich sind verschiedene Verfahren erforderlich, um Informationen von z. B. den HTML-Dateien verschiedener Vorrichtungen zu extrahieren.
  • US 2004/255023 und US 2004/205207 beziehen sich auf Verfahren zum Extrahieren erforderlicher Informationen, die einer fernüberwachten Vorrichtung, die über ein Netz angeschlossen ist, zugeordnet sind.
  • US 2004/254915 bezieht sich auf eine Verfahren und ein System zum Parsen eines Informationsstring, um erforderliche Informationen zu extrahieren, die mit einer fernüberwachten Vorrichtung in Beziehung stehen, die über ein Netz angeschlossen ist.
  • Es ist eine Aufgabe der vorliegenden Erfindung, Informationen von Webseiten einer überwachten Vorrichtung zuverlässiger zu erhalten.
  • Diese Aufgabe wird gelöst durch das Verfahren von Anspruch 1, das System von Anspruch 7 und das Computerprogrammprodukt von Anspruch 12. Bevorzugte Ausführungsformen der vorliegenden Erfindung sind in den abhängigen Ansprüchen festgelegt.
  • Das System und Verfahren der vorliegenden Erfindung wenden sich Lösungen für die vorstehend identifizierten Probleme zu, indem die Überwachung von Vorrichtungen, die mit einem Netz verbunden sind, ermöglicht wird. Folglich wird ein Verfahren zur Überwachung einer Vorrichtung unter verschiedenen Vorrichtungen, die mit einem Netz kommunikativ gekoppelt sind, beschrieben.
  • Das Verfahren umfasst das Zugreifen auf eine erste Datenbank über ein Hardwarezugriffsmodul, wobei die erste Datenbank dazu konfiguriert ist, mehrere Kommunikationsprotokolle zu unterstützen. In der ersten Datenbank sind Informationen gespeichert, die von den mehreren Kommunikationsprotokollen verwendet werden, um verschiedene Informationen, wie z. B. Hersteller- und Modellinformationen einer überwachten Vorrichtung, zu erhalten. Ein Kommunikationsprotokoll wird unter mehreren Kommunikationsprotokollen ausgewählt und das ausgewählte Kommunikationsprotokoll ist dazu konfiguriert, Statusinformationen von der überwachten Vorrichtung zu empfangen. Das Verfahren umfasst ferner das Zugreifen auf die überwachte Vorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls und auf Informationen von der ersten Datenbank, wobei Statusinformationen von der Vorrichtung, auf die zugegriffen wird, empfangen werden und die empfangenen Statusinformationen in einer zweiten Datenbank (DeviceODBC) gespeichert werden.
  • In einer anderen Ausführungsform schafft die vorliegende Erfindung ein Verfahren zur Überwachung einer Vorrichtung unter verschiedenen Vorrichtungen, die mit einem Netz kommunikativ gekoppelt sind. Mehrere Kommunikationsprotokolle können verwendet werden, um Informationen von einer überwachten Vorrichtung abzurufen. Ein SNMP-Protokoll wird beispielsweise zuerst ausgewählt, um auf eine überwachte Vorrichtung zuzugreifen, und Vorrichtungsinformationen, die so konfiguriert sind, dass sie unter Verwendung des SNMP-Protokoll effizient abgerufen werden, werden erhalten. Anschließend werden HTTP- und FTP-Protokolle ausgewählt, um Informationen zu erhalten, die zu einer effizienten Wiedergewinnung unter Verwendung des SNMP-Protokolls außerstande waren, wenn die Vorrichtung die zusätzlichen Protokolle unterstützt. Die Auswahl von Protokollen wird von einem Protokollmanager in Verbindung mit in einer Datenbank gespeicherten Unterstützungsinformationen durchgeführt.
  • In der vorliegenden Erfindung ermöglicht ein Überwachungssystem die Überwachung von mindestens einer Vorrichtung (überwachten Vorrichtung), die mit einem Netz wie beispielsweise einem LAN oder einem WAN verbunden ist. Die überwachte Vorrichtung ist so konfiguriert, dass sie eine eindeutige IP-Adresse besitzt. Die der überwachten Vorrichtung zugeordnete IP-Adresse und die Details des Verkäufers/Herstellers für die überwachte Vorrichtung werden in einer Datenbank gespeichert. Durch Abtasten des Netzes und Abfragen der Vorrichtungen können die IP-Adressen der Vorrichtungen erhalten werden. Solche Verfahren sind bekannt. Daher wird angenommen, dass die IP-Adressen der zu überwachenden Vorrichtungen bereits erfasst und in einer Datenbank gespeichert sind.
  • Die vorliegende Erfindung legt fest, wie erforderliche Informationen von den HTML-Informationen zu extrahieren sind, die von einer überwachten Vorrichtung empfangen werden. Sobald auf einen Webseitenort der überwachten Vorrichtung zugegriffen wird (d. h. über die IP-Adresse und den festgelegten Port), wird eine der überwachten Vorrichtung entsprechende spezielle Webseite angezeigt. Informationen in der Webseite liegen in Form von Schlüssel- und Wertpaaren vor. Der Tonerpegel kann beispielsweise als "Schwarz 100%" auf der Farbdrucker-Webseite gezeigt werden. Ein HTML/XML-Parser wird verwendet, um die Seite zu analysieren, um erforderliche Informationen von den Informationen auf der Webseite wiederzugewinnen. Die erforderlichen Informationen und Parameterwerte, die von der Webseite unter Verwendung des HTML/XML-Parsers extrahiert werden, werden in der Unterstützungsdatenbank gespeichert.
  • Die vorliegende Erfindung identifiziert auch verschiedene Verkäufer von überwachten Vorrichtungen und die Vorrichtungsmodelle, die vom Überwachungssystem unterstützt werden, wie hierin beschrieben. Da verschiedene Verkäufer der überwachten Vorrichtungen Informationen über eine überwachte Vorrichtung in einer für den Verkäufer spezifischen Weise darstellen, ermöglicht die vorliegende Erfindung die Identifikation des Verkäufers und des Modells der überwachten Vorrichtung, um den Betriebsstatus der überwachten Vorrichtung zu bestimmen.
  • Gemäß einem Aspekt der vorliegenden Erfindung werden ein Verfahren, ein System und ein Computerprogrammprodukt zum Initialisieren von mehreren Protokollobjekten geschaffen, die jeweiligen Kommunikationsprotokollen zugeordnet sind, die verwendet werden, um Statusinformationen in Bezug auf eine überwachte Vorrichtung zu extrahieren, die mit einem Netz kommunikativ gekoppelt ist, umfassend: (1) Auswählen eines Kommunikationsprotokolls aus den jeweiligen Kommunikationsprotokollen; (2) Abrufen von Informationen zum Zugreifen auf die Vorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls aus einem ersten Speicher; (3) Zugreifen auf die Vorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls und der vom ersten Speicher abgerufenen Informationen, um zu versuchen, Verkäuferinformationen in Bezug auf die Vorrichtung zu erhalten; (4) Feststellen, ob die Verkäuferinformationen von der Vorrichtung erhalten wurden; (5) wenn die Verkäuferinformationen von der Vorrichtung erhalten wurden, Erhalten von Unterstützungsinformationen zum Extrahieren der Statusinformationen unter Verwendung von jedem der jeweiligen Kommunikationsprotokolle von einem zweiten Speicher und Speichern der Verkäuferinformationen und der jeweiligen Unterstützungsinformationen in jedem Protokollobjekt der mehreren Protokollobjekte; und (6), wenn die Verkäuferinformationen nicht von der Vorrichtung erhalten wurden, Wiederholen der vorangehenden Schritte, bis die Verkäuferinformationen erhalten werden oder bis jedes Kommunikationsprotokoll der jeweiligen Kommunikationsprotokolle ausgewählt wurde.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden ein Verfahren, ein System und ein Computerprogrammprodukt zum Feststellen, welche Arten von Statusinformationen von einer überwachten Vorrichtung zu extrahieren sind, die mit einem Netz kommunikativ gekoppelt ist, geschaffen, umfassend: (1) Auswählen eines Kommunikationsprotokolls aus mehreren Kommunikationsprotokollen, die verwendet werden, um Statusinformationen von der Vorrichtung zu extrahieren; (2) Abrufen eines Protokollobjekts, das dem ausgewählten Kommunikationsprotokoll zugeordnet ist, von einem ersten Speicher, wobei das Protokollobjekt mindestens einen Typ von Statusinformationen, ein Gewicht der Statusinformationen und Informationen zum Extrahieren des Typs von Statusinformationen von der Vorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls umfasst; (3) Feststellen, ob der Typ von Statusinformationen in einem zweiten Speicher vorliegt, wobei der zweite Speicher vorher von der Vorrichtung extrahierte Statusinformationen umfasst; (4) wenn der Feststellungsschritt feststellt, dass der Typ von Statusinformationen im zweiten Speicher vorhanden ist, Prüfen, ob das Gewicht der im Protokollobjekt gespeicherten Statusinformationen größer ist als ein entsprechendes Gewicht, das den Statusinformationen desselben Typs, die im zweiten Speicher gespeichert sind, zugeordnet ist; (5) wenn (a) der Feststellungsschritt feststellt, dass der Typ von Statusinformationen nicht im zweiten Speicher vorhanden ist, oder (b) wenn der Feststellungsschritt feststellt, dass der Typ von Statusinformationen im zweiten Speicher vorhanden ist, aber der Prüfungsschritt feststellt, dass das Gewicht der Statusinformationen größer ist als das entsprechende Gewicht, das den Statusinformationen desselben Typs, die im zweiten Speicher gespeichert sind, zugeordnet ist, Zugreifen auf die Vorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls und der Informationen zum Extrahieren der Vorrichtung, die im Protokollobjekt enthalten sind, um die Statusinformationen zu erhalten.
  • Gemäß noch einem weiteren Aspekt der vorliegenden Erfindung werden ein Verfahren, ein System und ein Computerprogrammprodukt zum Mangen von Informationen in Bezug auf mindestens eine überwachte Vorrichtung, die mit einem Netz kommunikativ gekoppelt ist, geschaffen, umfassend: (1) Auswählen eines Kommunikationsprotokolls aus mehreren Kommunikationsprotokollen, die verwendet werden, um Statusinformationen von der mindestens einen überwachten Vorrichtung zu extrahieren; (2) Abrufen eines Protokollobjekts, das dem ausgewählten Kommunikationsprotokoll zugeordnet ist, von einem ersten Speicher, wobei das Protokollobjekt Verkäufer- und Modellinformationen der mindestens einen überwachten Vorrichtung umfasst; (3) Erhalten eines Verkäufernamens der überwachten Vorrichtung der mindestens einen überwachten Vorrichtung, die vom ausgewählten Kommunikationsprotokoll unterstützt wird, vom Protokollobjekt; (4) Erhalten eines dem erhaltenen Verkäufernamen entsprechenden Modellnamens vom Protokollobjekt; (5) Erzeugen eines beschreibenden String unter Verwendung des erhaltenen Verkäufernamens und des erhaltenen Modellnamens; (6) Feststellen, ob der beschreibende String in einem zweiten Speicher vorhanden ist; und (7) wenn der Feststellungsschritt feststellt, dass der beschreibende String nicht im zweiten Speicher vorhanden ist, Speichern des beschreibenden String im zweiten Speicher in Zusammenhang mit dem Protokollobjekt.
  • Gemäß noch einem weiteren Aspekt der vorliegenden Erfindung werden ein Verfahren, ein System und ein Computerprogrammprodukt zum Managen von Informationen, die zum Extrahieren von Statusinformationen von einer überwachten Vorrichtung erforderlich sind, die mit einem Netz kommunikativ gekoppelt ist, geschaffen, umfassend: (1) Auswählen eines Kommunikationsprotokolls aus mehreren Kommunikationsprotokollen, die verwendet werden, um die Statusinformationen von der überwachten Vorrichtung zu extrahieren; (2) Abrufen eines beschreibenden String aus einem ersten Speicher, wobei der beschreibende String einen Verkäufernamen und einen entsprechenden Modellnamen umfasst, die vom ausgewählten Kommunikationsprotokoll unterstützt werden; (3) Extrahieren des Verkäufernamens und des entsprechenden Modellnamens vom beschreibenden String; (4) Feststellen, ob der extrahierte Verkäufername und der extrahierte Modellname einem Verkäufernamen bzw. Modellnamen der überwachten Vorrichtung entsprechen; und (5), wenn der Feststellungsschritt feststellt, dass der extrahierte Verkäufername und der extrahierte Modellname dem Verkäufernamen bzw. dem Modellnamen der überwachten Vorrichtung entsprechen, Zugreifen auf die Vorrichtung, um die Statusinformationen zu erhalten, unter Verwendung des ausgewählten Protokolls.
  • Gemäß noch einem weiteren Aspekt der vorliegenden Erfindung werden ein Verfahren, ein System und ein Computerprogrammprodukt zum Feststellen, welche, falls überhaupt, Kommunikationsprotokolle verwendet werden können, um Statusinformationen in Bezug auf eine Netzvorrichtung zu extrahieren, geschaffen, umfassend: (1) Auswählen eines Kommunikationsprotokolls aus mehreren Kommunikationsprotokollen; (2) Erhalten von Informationen zum Zugreifen auf die Netzvorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls von einem Vorrichtungsobjekt, das der Netzvorrichtung zugeordnet ist; (3) Feststellen, ob auf die Netzvorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls und der Informationen zum Zugreifen auf die Netzvorrichtung, die vom Vorrichtungsobjekt erhalten werden, zugegriffen werden kann; (4) wenn der Feststellungsschritt feststellt, dass auf die Netzvorrichtung nicht unter Verwendung des ausgewählten Kommunikationsprotokolls zugegriffen werden kann, Entfernen der Informationen zum Zugreifen auf die Netzvorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls vom Vorrichtungsobjekt; und (5) wenn der Feststellungsschritt feststellt, dass auf die Netzvorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls zugegriffen werden kann, Durchführen von weiteren Tests, um festzustellen, ob das ausgewählte Kommunikationsprotokoll verwendet werden kann, um die Statusinformationen von der Netzvorrichtung zu extrahieren.
  • Ferner umfasst der Schritt zum Durchführen von weiteren Tests: (1) Feststellen, ob ein Verkäufer der Netzvorrichtung von der Netzvorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls erhalten werden kann; (2) wenn der vorangehende Feststellungsschritt feststellt, dass der Verkäufer nicht unter Verwendung des ausgewählten Kommunikationsprotokolls erhalten werden kann, Prüfen, ob das ausgewählte Kommunikationsprotokoll einen allgemeinen Verkäufer unterstützt, und wenn das ausgewählte Kommunikationsprotokoll den allgemeinen Verkäufer nicht unterstützt, Entfernen der Informationen zum Zugreifen auf die Netzvorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls vom Vorrichtungsobjekt; (3) wenn der vorangehende Feststellungsschritt feststellt, dass der Verkäufer unter Verwendung des ausgewählten Kommunikationsprotokolls erhalten werden kann, Erhalten des Verkäufers von der Netzvorrichtung und Feststellen, ob der erhaltene Verkäufer vom ausgewählten Kommunikationsprotokoll unterstützt wird; (4) wenn der erhaltene Verkäufer nicht vom ausgewählten Kommunikationsprotokoll unterstützt wird, Prüfen, ob das ausgewählte Kommunikationsprotokoll den allgemeinen Verkäufer unterstützt, und wenn das ausgewählte Kommunikationsprotokoll den allgemeinen Verkäufer nicht unterstützt, Entfernen der Informationen zum Zugreifen auf die Netzvorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls vom Vorrichtungsobjekt; und (5) wenn der erhaltene Verkäufer vom ausgewählten Kommunikationsprotokoll unterstützt wird, Durchführen von weiteren Tests in Bezug auf die Modellinformationen.
  • Außerdem umfasst der Schritt zum Durchführen von weiteren Tests in Bezug auf die Modellinformationen: (1) Feststellen, ob ein Modell der Netzvorrichtung von der Netzvorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls erhalten werden kann; (2) wenn der vorangehende Feststellungsschritt feststellt, dass das Modell nicht unter Verwendung des ausgewählten Kommunikationsprotokolls erhalten werden kann, Prüfen, ob das ausgewählte Kommunikationsprotokoll ein allgemeines Modell unterstützt, und wenn das ausgewählte Kommunikationsprotokoll das allgemeine Modell nicht unterstützt, Entfernen der Informationen zum Zugreifen auf die Netzvorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls vom Vorrichtungsobjekt; (3) wenn der vorangehende Feststellungsschritt feststellt, dass das Modell unter Verwendung des ausgewählten Kommunikationsprotokolls erhalten werden kann, Erhalten des Modells von der Netzvorrichtung und Feststellen, ob das erhaltene Modell vom ausgewählten Kommunikationsprotokoll unterstützt wird; und (4) wenn das erhaltene Modell vom ausgewählten Kommunikationsprotokoll nicht unterstützt wird, Prüfen, ob das ausgewählte Kommunikationsprotokoll das allgemeine Modell unterstützt, und wenn das ausgewählte Kommunikationsprotokoll das allgemeine Modell nicht unterstützt, Entfernen der Informationen zum Zugreifen auf die Netzvorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls aus dem Vorrichtungsobjekt.
  • Außerdem werden gemäß einem weiteren Aspekt der vorliegenden Erfindung ein Verfahren, ein System und ein Computerprogrammprodukt zum Extrahieren von Statusinformationen in Bezug auf eine überwachte Vorrichtung, die mit einem Netz kommunikativ gekoppelt ist, unter Verwendung eines ausgewählten Kommunikationsprotokolls geschaffen, umfassend: (1) Abrufen von mehreren Implementierungsidentifizierern von einem ersten Speicher, wobei jeder Implementierungsidentifizierer eine erste Zugriffsfunktion, die dazu konfiguriert ist, auf die überwachte Vorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls zuzugreifen, um Verkäufer- und Modellinformationen der überwachten Vorrichtung zu erhalten, und eine zweite Zugriffsfunktion, die dazu konfiguriert ist, auf die überwachte Vorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls zuzugreifen, um Statusinformationen der überwachten Vorrichtung zu erhalten, identifiziert; (2) Auswählen eines Implementierungsidentifizierers aus den mehreren Implementierungsidentifizierern; (3) Zugreifen auf die Vorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls und der ersten Zugriffsfunktion, die dem ausgewählten Implementierungsidentifizierer zugeordnet ist, um zu versuchen, Verkäufer- und Modellinformationen in Bezug auf die Vorrichtung zu erhalten; (4) Feststellen, ob die Verkäufer- und Modellinformationen von der Vorrichtung erhalten wurden; (5) wenn die Verkäufer- und Modellinformationen von der Vorrichtung erhalten wurden, Speichern des ausgewählten Implementierungsidentifizierers in Zusammenhang mit den erhaltenen Verkäufer- und Modellinformationen in einem zweiten Speicher; und (6) wenn die Verkäufer- und Modellinformationen nicht von der Vorrichtung erhalten wurden, Wiederholen der Auswahl-, Zugriffs- und Feststellungsschritte, bis die Verkäufer- und Modellinformationen erhalten werden oder bis jeder Implementierungsidentifizierer in den mehreren Implementierungsidentifizierern ausgewählt wurde.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden überdies ein Verfahren, ein System und ein Computerprogrammprodukt zum Extrahieren von Informationen in Bezug auf eine überwachte Vorrichtung, die kommunikativ mit einem Netz gekoppelt ist, unter Verwendung eines ausgewählten Kommunikationsprotokolls geschaffen, umfassend: (1) Abrufen von mehreren Implementierungsidentifizierern von einem ersten Speicher, wobei jeder Implementierungsidentifizierer (a) eine erste Zugriffsfunktion, die dazu konfiguriert ist, auf die überwachte Vorrichtung unter Ver wendung des ausgewählten Kommunikationsprotokolls zuzugreifen, um Verkäufer- und Modellinformationen der überwachten Vorrichtung zu erhalten, und (b) eine zweite Zugriffsfunktion, die dazu konfiguriert ist, auf die überwachte Vorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls zuzugreifen, um Statusinformationen der überwachten Vorrichtung zu erhalten, identifiziert; (2) Auswählen eines Implementierungsidentifizierers aus den mehreren Implementierungsidentifizierern; (3) Zugreifen auf die Vorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls und der ersten Zugriffsfunktion, die dem ausgewählten Implementierungsidentifizierer zugeordnet ist, um zu versuchen, Verkäufer- und Modellinformationen in Bezug auf die Vorrichtung zu erhalten; (4) Feststellen, ob die Verkäufer- und Modellinformationen von der Vorrichtung erhalten wurden; (5) wenn der Feststellungsschritt feststellt, dass die Verkäufer- und Modellinformationen von der Vorrichtung erhalten wurden, Speichern des ausgewählten Implementierungsidentifizierers in Zusammenhang mit den erhaltenen Verkäufer- und Modellinformationen in einem zweiten Speicher; und (6) wenn der Feststellungsschritt feststellt, dass die Verkäufer- und Modellinformationen nicht von der Vorrichtung erhalten wurden, Wiederholen der Auswahl-, Zugriffs- und Feststellungsschritte, bis die Verkäufer- und Modellinformationen erhalten werden oder bis jeder Implementierungsidentifizierer in den mehreren Implementierungsidentifizierern ausgewählt wurde.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden überdies ein Verfahren, ein System und ein Computerprogrammprodukt zum Managen von Informationen geschaffen, die dazu konfiguriert sind, von einem ausgewählten Kommunikationsprotokoll verwendet zu werden, um Informationen in Bezug auf eine überwachte Vorrichtung unter verschiedenen Vorrichtungen, die kommunikativ mit einem Netz gekoppelt sind, zu extrahieren, umfassend: (1) Abrufen von mehreren Implementierungsidentifizierern von einem ersten Speicher, wobei jeder Implementierungsidentifizierer (a) eine erste Zugriffsfunktion, die dazu konfiguriert ist, auf die überwachte Vorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls zuzugreifen, um Verkäufer- und Modellinformationen der überwachten Vorrichtung zu erhalten, und (b) eine zweite Zugriffsfunktion, die dazu konfiguriert ist, auf die überwachte Vorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls zuzugreifen, um Statusinformationen der überwachten Vorrichtung zu erhalten, identifiziert; (2) Auswählen eines Implementierungsidentifizierers aus den mehreren Implementierungsidentifizierern; (3) Zugreifen auf eine externe Informationsspeichereinheit, um Unterstützungsinformationen zum Zugreifen auf die überwachte Vorrichtung zu erhalten, unter Verwendung von mindestens einer der ersten Zugriffsfunktion und der zweiten Zugriffsfunktion unter Verwendung des ausgewählten Kommunikationsprotokolls, wobei die Unterstützungsinformationen Vorbedingungsinformationen umfassen, die zum Erhalten der Status- oder der Verkäufer- und Modellinformationen von der überwachten Vorrichtung verwendet werden; und (4) Speichern der Unterstützungsinformationen in mindestens einer internen Speichertabelle, wobei die Vorbedingungsinformationen einen Ort eines Typs von interessierenden Informationen, die von der überwachten Vorrichtung erhältlich sind, einschränken.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden überdies ein Verfahren, ein System und ein Computerprogrammprodukt zum Extrahieren von Informationen, die einer überwachten Vorrichtung zugeordnet sind, die mit einem Netz kommunikativ gekoppelt ist, geschaffen, umfassend: (1) Zugreifen auf einen ersten Speicher, um Zugriffsinformationen zum Zugreifen auf die überwachte Vorrichtung zu erhalten, wobei die Zugriffsinformationen einen Typ von Statusinformationen, die von der überwachten Vorrichtung zu erhalten sind, und Vorbedingungsinformationen, die verwendet werden, um den Typ von Statusinformationen von der überwachten Vorrichtung zu erhalten, umfassen, wobei die Vorbedingungsinformationen einen Ort des Typs von Statusinformationen, die von der überwachten Vorrichtung erhältlich sind, einschränken; (2) Zugreifen auf die Vorrichtung unter Verwendung eines HTTP-Protokolls und einer IP-Adresse der überwachten Vorrichtung, um einen informationsstring zu erhalten, der der überwachten Vorrichtung zugeordnet ist; (3) Extrahieren von Informationen, die dem Typ von Statusinformationen entsprechen, aus dem Informationsstring unter Verwendung der Vorbedingungsinformationen; und (4) Speichern der extrahierten Informationen in Zusammenhang mit der IP-Adresse der überwachten Vorrichtung.
  • Überdies werden gemäß einem weiteren Aspekt der vorliegenden Erfindung ein Verfahren, ein System und ein Computerprogrammprodukt zum Extrahieren von Informationen, die einer überwachten Vorrichtung zugeordnet sind, die mit einem Netz kommunikativ gekoppelt ist, unter Verwendung eines SNMP-Protokolls geschaffen, umfassend: (1) Zugreifen auf einen ersten Speicher, um Zugriffsinformationen zum Zugreifen auf die überwachte Vorrichtung zu erhalten, wobei die Zugriffsinformationen (a) einen Typen von Statusinformationen, die von der überwachten Vorrichtung zu erhalten sind, und (b) einen Zugriffsstring, der zum Erhalten des Typs von Statusinformationen von der überwachten Vorrichtung verwendet wird, umfassen; (2) Analysieren des Zugriffsstrings, um festzustellen, ob der Zugriffsstring leer ist, und um festzustellen, ob der Zugriffsstring einen ersten vorbestimmten String umfasst, wenn der Zugriffsstring nicht leer ist; (3) wenn der Analyseschritt feststellt, dass der Zugriffsstring nicht leer ist und dass der Zugriffsstring den ersten vorbestimmten String umfasst, Zugreifen auf die Vorrichtung unter Verwendung einer ersten SNMP-Zugriffsfunktion, um einen Wert zu erhalten, der dem Typ von Statusinformationen zugeordnet ist; und (4) wenn der Analyseschritt feststellt, dass der Zugriffsstring leer ist oder dass der Zugriffsstring nicht den ersten vorbestimmten String umfasst, Zugreifen auf die Vorrichtung unter Verwendung einer zweiten SNMP-Zugriffsfunktion, um den Wert zu erhalten, der dem Typ von Statusinformationen zugeordnet ist.
  • Überdies werden gemäß einem weiteren Aspekt der vorliegenden Erfindung ein Verfahren, ein System und ein Computerprogrammprodukt zum Codieren von Daten, die Zugriffsinformationen darstellen, die dazu konfiguriert sind, von einem ausgewählten Kommunikationsprotokoll verwendet zu werden, um Zusammenfassungsinformation in Bezug auf eine überwachte Vorrichtung unter verschiedenen Vorrichtungen zu extrahieren, die mit einem Netz kommunikativ gekoppelt sind, geschaffen, umfassend: (1) Reservieren von Speicherstellen für Verkäuferinformationen der überwachten Vorrichtung in einem Speicherpuffer; (2) Schreiben der Verkäuferinformationen in den Speicherpuffer; (3) Reservieren von Speicherstellen für Modellinformationen der überwachten Vorrichtung in einem Speicherpuffer, wobei die Speicherstellen für Modellinformationen den Speicherstellen für Verkäuferinformationen zugeordnet sind; (4) Schreiben der Modellinformationen in den Speicherpuffer; (5) Reservieren von Speicherstellen für Unterstützungsinformationen zum Zugreifen auf die überwachte Vorrichtung in einem Speicherpuffer, einschließlich Vorbedingungsinformationen, die zum Erhalten der Statusinformationen von der überwachten Vorrichtung verwendet werden, wobei die Speicherstellen für Unterstützungsinformationen den Speicherstellen für Verkäuferinformationen und den Speicherstellen für Modellinformationen zugeordnet sind; und (6) Schreiben der Unterstützungsinformationen in den Speicherpuffer, wobei die Vorbedingungsinformationen einen Ort eines Typs von interessierenden Informationen, die von der überwachten Vorrichtung erhältlich sind, einschränken.
  • Überdies wird gemäß einem weiteren Aspekt der vorliegenden Erfindung eine Überwachungsvorrichtung mit einem Speicher, der Daten enthält, die Zugriffsinformationen darstellen, die dazu konfiguriert sind, von einem ausgewählten Kommunikationsprotokoll verwendet zu werden, um Informationen in Bezug auf eine überwachte Vorrichtung unter verschiedenen Vorrichtungen, die kommunikativ mit einem Netz gekoppelt sind, zu extrahieren, geschaffen, wobei die Zugriffsinformationen durch ein Verfahren erzeugt werden, das umfasst: (1) Abrufen von mehreren Implementierungsidentifizierern von einer externen Speichervorrichtung, wobei jeder Implementie rungsidentifizierer mindestens eine Zugriffsfunktion identifiziert, die dazu konfiguriert ist, auf die überwachte Vorrichtung unter Verwendung des ausgewählten Kommunikationsprotokolls zuzugreifen, um mindestens eine von Modellinformationen, eines eindeutigen Identifizierers und Statusinformationen der überwachten Vorrichtung zu erhalten; (2) Auswählen eines Implementierungsidentifizierers aus den mehreren Implementierungsidentifizierern; (3) Zugreifen auf eine externe Informationsspeichereinheit, um Unterstützungsinformationen zum Zugreifen auf die überwachte Vorrichtung unter Verwendung mindestens einer Zugriffsfunktion zu erhalten, wobei die Unterstützungsinformationen Vorbedingungsinformationen umfassen, die zum Erhalten der mindestens einen der Modellinformationen, des eindeutigen Identifizierers und der Statusinformationen von der überwachten Vorrichtung verwendet werden, wobei die Vorbedingungsinformationen einen Ort eines Typs von interessierenden Informationen, die von der überwachten Vorrichtung erhältlich sind, einschränken; und (4) Speichern der Unterstützungsinformationen in Zusammenhang mit dem Implementierungsidentifizierer und den Verkäuferinformationen der überwachten Vorrichtung als Daten, die die Zugriffsinformationen darstellen.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Eine vollständigere Einschätzung der Erfindung und von vielen von den zugehörigen Vorteilen derselben wird leicht erhalten, wenn dieselbe mit Bezug auf die folgende ausführliche Beschreibung besser verständlich wird, wenn sie in Verbindung mit den zugehörigen Zeichnungen betrachtet wird, in denen:
  • 1 drei vernetzte Geschäftsbürovorrichtungen darstellt, die mit einem Netz von Computern und Datenbanken über das Internet verbunden sind;
  • 2 die Komponenten einer digitalen Bilderzeugungsvorrichtung darstellt;
  • 3 die elektronischen Komponenten der in 2 dargestellten digitalen Bilderzeugungsvorrichtung darstellt;
  • 4 die Details einer Kommunikationsschnittstelle mit mehreren Ports, die in 3 dargestellt ist, darstellt;
  • 5 eine alternative Systemkonfiguration darstellt, in der Geschäftsbürovorrichtungen entweder direkt mit dem Netz verbunden sind oder mit einem Computer verbunden sind, der mit dem Netz verbunden ist;
  • 6A ein Blockdiagramm ist, das einen Fluss von Informationen zu und von einer Anwendungseinheit unter Verwendung von elektronischer Post darstellt;
  • 6B eine alternative Weise zur Kommunikation unter Verwendung von elektronischer Post darstellt, in der ein Computer, der mit der Anwendungseinheit verbunden ist, auch als Nachrichtenübertragungsagent (MTA) dient;
  • 6C eine alternative Weise zur Kommunikation unter Verwendung von elektronischer Post darstellt, in der eine Anwendungseinheit einen Nachrichtenübertragungsagenten zum Austauschen von elektronischer Post umfasst;
  • 6D eine alternative Weise zur Kommunikation unter Verwendung von elektronischer Post darstellt, in der ein Postserver als POP3-Server zum Empfangen von Post von einem Gerät/einer Vorrichtung und als Server für Simple Mail Transfer Protocol (SMTP) zum Senden von Post für das Gerät/die Vorrichtung wirkt;
  • 7 eine alternative Weise zum Senden von Nachrichten über das Internet darstellt;
  • 8 einen beispielhaften Computer darstellt, der mit einem Gerät/einer Vorrichtung verbunden sein kann und verwendet wird, um Nachrichten von elektronischer Post zu übertragen;
  • 9 eine schematische Darstellung des Gesamtsystems gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung ist;
  • 10 Module darstellt, die bei der Überwachung der Daten und ihrer Schnittstellenfunktionen gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung darstellt;
  • 11 Details innerhalb des Überwachungsmoduls und ihrer Anruffunktionen zwischen den Untermodulen zeigt;
  • 12 eine Datenstruktur zeigt, die vom HWaccess-Untermodul verwendet wird, wie in 11 dargestellt;
  • 13 die Sequenz der init-Funktion des Überwachungsmoduls, das in 10 dargestellt ist, zeigt;
  • 14 eine beispielhafte Sequenz der Statusüberwachungsfunktion zeigt, um den Status einer überwachten Vorrichtung durch den MonitorManager zu bestimmen, wie in 11 gezeigt;
  • 15 einen Vektor der Referenz zu den Vorrichtungen zeigt, der durch CDevice-Factory erzeugt wird und vom MonitorManager verwendet wird, wie in 13 dargestellt,
  • 16 die Klassenstruktur des DeviceODBC-Moduls mit der abstrakten Klasse CAbsProtocolParameters zeigt;
  • 17 die SParameter-Datenstruktur, die zum Speichern von Parameterwerten verwendet wird, die erforderlich sind, um auf überwachte Vorrichtungen zuzugreifen, gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
  • 18 eine Abbildungsstruktur, die verwendet wird, um Parameterwerte zu speichern, die erforderlich sind, um auf überwachte Vorrichtungen zuzugreifen, gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
  • 19 die Organisation der Überwachungsdatenbank darstellt, die in einer Ausführungsform der vorliegenden Erfindung verwendet wird;
  • 20–22 die Organisation einer Unterstützungsdatenbank, die gemäß dem Kommunikationsprotokoll beschaffen ist, gemäß einer Ausführungsform der vorliegenden Erfindung darstellen;
  • 23 die Klassenstruktur des HWaccess-Moduls gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
  • 24 die Klassenstruktur des SNMP-Moduls gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
  • 25 die Klassenstruktur des HTTP-Moduls gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
  • 26 die Klassenstruktur des FTP-Moduls gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
  • 27A–27D die Datenstrukturen, die im HWaccess-Modul von 23 verwendet werden, um Informationen zu verwalten, die erforderlich sind, um auf die überwachten Vorrichtungen zuzugreifen und um Statusinformationen von den überwachten Vorrichtungen zu erhalten, gemäß einer Ausführungsform der vorliegenden Erfindung darstellen;
  • 28 einen Ablaufplan zeigt, der den Prozess der Initialisierung der Protokollobjekte mit Verkäuferinformationen einer überwachten Vorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
  • 29A–29D die Datenstrukturen, die verwendet werden, um die Statusinformationen einer überwachten Vorrichtung eines speziellen Verkäufers und Modells für jedes Protokollobjekt zu erhalten, gemäß einer Ausführungsform der vorliegenden Erfindung darstellen;
  • 30 ein Beispiel von Musterdaten für die Datenstrukturen von 27D, 29C und 29D, die verwendet werden, um Statusinformationen von einer überwachten Vorrichtung unter Verwendung des FTP-Protokolls zu erhalten, gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
  • 31A einen Ablaufplan, der den Prozess des Erhaltens von Statusinformationen von einer überwachten Vorrichtung für ein Kommunikationsprotokoll beschreibt, gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 31B einen Ablaufplan, der den Prozess des Erhaltens von Statusinformationen von einer überwachten Vorrichtung unter Verwendung von allen Kommunikationsprotokollen beschreibt, gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 32A die Datenstruktur, die zum Verwalten von Informationen über die Verkäufer und Modelle von überwachten Vorrichtungen, die von einem gegebenen Protokoll unterstützt werden, verwendet wird, gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 32B ein Beispiel der in 32A gezeigten Datenstruktur zeigt;
  • 33 einen Ablaufplan, der das Verfahren zum Hinzufügen von unterstützten Verkäufern und Modellen zu der Datenstruktur von 32A beschreibt, gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 34 einen Ablaufplan, der das Verfahren zum Erhalten des unterstützten Verkäufers und Modells durch ein Protokoll von der Datenstruktur von 32A beschreibt, gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 35 die Klassenstruktur des Device-Moduls gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 36A die Datenstruktur, die von den Softwareobjekten verwendet wird, die die überwachten Vorrichtungen darstellen, um festzustellen, welche Protokolle verwendet werden, um auf eine überwachte Vorrichtung zuzugreifen, gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 36B Musterdaten in der Datenstruktur von 36A zeigt; und
  • 37 einen Ablaufplan, der beschreibt, wie die Datenstruktur von 36A aktualisiert wird, um festzustellen, welche Protokolle verwendet werden, um Statusinformationen für eine überwachte Vorrichtung zu erhalten, gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
  • 38A–38C Beispiele von HTML-Dateien darstellen, die an überwachten Vorrichtungen erhältlich sind;
  • 39 ein Paketdiagramm für jedes der Protokollpakete von 23 darstellt, wobei sich "XXX" auf beispielsweise HTTP, FTP oder SNMP bezieht;
  • 40 ein alternatives Paketdiagramm für jedes der Protokollpakete von 23 darstellt, wobei sich "XXX" auf HTTP, FTP oder SNMP bezieht;
  • 41 ein Paketdiagramm für das HTTP-Protokoll gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 42 die Klassenspezifikation für die abstrakte Klasse cAbsHTTPImplementation zeigt;
  • 43 die Datenstruktur m_ImplementationMap der CHTTPProtocol-Klasse von 41 darstellt;
  • 44 die Datenstruktur m_VendorModelSupportMap der CHTTPProtocol-Klasse von 41 darstellt;
  • 45 ein Ablaufplan der Funktion canAccesslP() der CHTTPProtocol-Klasse ist;
  • 46 ein Ablaufplan der Funktion obtainStatus() der CHTTPProtocol-Klasse ist;
  • 47 das Paketdiagramm des FirstHTTPImplementation-Pakets darstellt;
  • 48 das Paketdiagramm des SecondHTTPImplementation-Pakets darstellt;
  • 49 Tabellen in der Unterstützungsdatenbank darstellt, die von der ersten Implementierung von HTTP verwendet werden;
  • 50 Tabellen in der Unterstützungsdatenbank darstellt, die von der zweiten Implementierung von HTTP verwendet werden;
  • 51 die Klassenstruktur des FirstHTTPODBC-Pakets darstellt;
  • 52 die Klassenstruktur des SecondHTTPODBC-Pakets darstellt;
  • 53 die Abbildungsstruktur m_VendorModelWebInfoMap der CSecondHTTPImplementation-Klasse darstellt;
  • 54 die Abbildungsstruktur m_ModelWebInfoForVendorMap der CSecondHTT-PImplementation-Klasse darstellt;
  • 55 die Abbildungsstruktur m_VendorModelUniqueIDInfoMap der CSecondHTT-PImplementation-Klasse zeigt;
  • 56 ein Ablaufplan der Funktion obtainStatus() der CSecondHTTPImplementation-Klasse ist;
  • 57 und 58 die Vektorstrukturen m_KeyValueVector bzw. m_LocateValueVector darstellen, die von der CSecondHTMLProcessor-Klasse verwendet werden;
  • 59 die Vektorstrukturen m_KeyValueVector und m_LocateValueVector darstellt, die in der ersten Implementierung von HTTP verwendet werden und die von der CFirstHTMLProcessor-Klasse verwendet werden;
  • 60 ein Ablaufplan der Funktion initDataSearchInfo() der CSecondHTMLProcessor-Klasse ist;
  • 61 ein Ablaufplan für die Verarbeitung von Text durch die Funktion searchAndObtainDataFromValue() der CSecondHTMLProcessor-Klasse ist;
  • 62 Mustereinträge in einer Unterstützungsdatenbanktabelle darstellt, die verwendet wird, um Statusinformationen unter Verwendung des SNMP-Protokolls zu erhalten;
  • 63 die Klassenstruktur des SNMP-Pakets darstellt;
  • 64 die Klassenstruktur des SNMPaccess-Pakets darstellt; und
  • 65 ein Ablaufplan zur Verarbeitung einer SNMP-Anforderung für einen String, der Informationen des SNMP-Anforderungstyps und des Objektidentifizierers enthält, ist.
  • AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • 1 stellt ein Diagramm mit verschiedenen Vorrichtungen und Computern zum Überwachen, Diagnostizieren und Steuern des Betriebs der Vorrichtungen dar. Insbesondere umfasst 1 ein erstes Netz 16 wie z. B. ein lokales Netz (LAN), das mit Computerarbeitsplatzrechnern 17, 18, 20 und 22 verbunden ist. Die Arbeitsplatzrechner können eine beliebige Art von Computern sein, einschließlich, z. B. Personalcomputervorrichtungen, Computern auf Unix-Basis, Computern auf Linux-Basis oder Apple Macintoshs. Mit dem Netz 16 sind auch eine digitale Bilderzeugungsvorrichtung 24, ein Faxgerät 28 und ein Drucker 32 verbunden. Wie von einem üblichen Fachmann erkannt werden würde, können zwei oder mehr der Komponenten des digitalen Kopierers/Druckers 24 und des Faxgeräts 28 zu einer vereinheitlichten "Bilderzeugungsvorrichtung" kombiniert sein. Der Kopierer/Drucker 24, das Faxgerät 28, der Drucker 32 und die Arbeitsplatzrechner 17, 18, 20 und 22 können beispielsweise als Maschinen oder überwachte Vorrichtungen bezeichnet werden. In einigen Konfigurationen können ein oder mehrere Arbeitsplatzrechner in Geschäftsbürogeräte umgewandelt werden. Außerdem kann irgendein Netz-Geschäftsbürogerät/irgendeine Netz-Geschäftsbürovorrichtung am Netz 16 angebracht werden. Irgendein Arbeitsplatzrechner 17, 18, 20 und 22 und ein Bürogerät 27 können auch als Zwischenüberwachungsvorrichtung fungieren, um die überwachten Vorrichtungen im Netz 16 abzufragen und die gesammelten Daten zur Überwachungsvorrichtung zu senden.
  • Ein Beispiel eines solchen Geschäftsbürogeräts ist eCabinet® von Ricoh Corporation. Ein Faxserver (nicht dargestellt) kann auch mit dem Netz 16 verbunden sein und eine Telephon-, Kabel- oder drahtlose Verbindung aufweisen. Jeder des digitalen Kopierers/Druckers 24, des Faxgeräts 28 und des Druckers 32 kann zusätzlich dazu, dass er mit dem Netz 16 verbunden ist, auch herkömmliche Telephon- und/oder Kabel- und/oder drahtlose Verbindungen 26, 30 bzw. 34 umfassen. Wie nachstehend erläutert, kommunizieren die überwachten Vorrichtungen 24, 28 und 32 mit einer entfernten Überwachungs-, Diagnose- und Steuerstation, die auch als Überwachungsvorrichtung bezeichnet wird, über beispielsweise das Internet über das Netz 16 oder durch eine direkte Telephon-, drahtlose oder Kabelverbindung.
  • In einer weiteren beispielhaften Geschäftsumgebung können überwachte Vorrichtungen solche Vorrichtungen wie eine Multifunktions-Abbildungsvorrichtung, einen Scanner, einen Projektor, ein Konferenzsystem und einen Aktenvernichter umfassen. In einer weiteren Anwendung kann das Netz 16 ein Heimnetz sein, in dem überwachte Vorrichtung Messgeräte (Elektrizität, Gas, Wasser) oder Geräte wie beispielsweise ein Mikrowellenofen, eine Waschmaschine, ein Trockner, ein Geschirrspüler, ein Heimunterhaltungssystem, ein Kühlschrank, ein Reiskocher, eine Heizvorrichtung, eine Klimaanlage, ein Wassererhitzer, eine Sicherheitskamera sind.
  • In 1 ist ein weiträumiges Netz (WAN) (z. B. das Internet oder sein Nachfolger) im Allgemeinen mit 10 bezeichnet. Das WAN 10 kann entweder ein privates WAN, ein öffentliches WAN oder ein Hybridtyp sein. Das WAN 10 umfasst mehrere miteinander verbundene Computer und Router, die mit 12A–12I bezeichnet sind. Die Weise der Kommunikation über ein WAN ist durch eine Reihe von Dokumenten von Request for Comments (RFC) bekannt, die von der Internet Engineering Task Force (IETF) auf www.ietf.org/rfc.html erhältlich sind, einschließlich RFC 821 mit dem Titel "Simple Mail Transfer Protocol"; RFC 822 mit dem Titel "Standard for the Format of ARPA Internet Text Message"; RFC 959 mit dem Titel "File Transfer Protocol (FTP"); RFC 2045 mit dem Titel "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"; RFC 1894 mit dem Titel "An Extensible Message Format for Delivery Status Notifications"; RFC 1939 mit dem Titel "Post Office protocol – Version 3"; RFC 2068, "Hypertext Transfer Protocol – HTTP/1.1"; und RFC 2298 mit dem Titel "An Extensible Message Format for Message Disposition Notifications". Die Inhalte von jeder dieser Referenzen werden durch den Hinweis hierin aufgenommen.
  • Die mit dem Transmission Control Protocol/Internet Protocol (TCP/IP) in Beziehung stehende Kommunikation ist beispielsweise in dem Buch "TCP/IP" Illustrated", Band 1, The Protocols, von W. R. Stevens, von Addison-Wesley Publishing Company, 1994, beschrieben, dessen gesamte Inhalte durch den Hinweis hierin aufgenommen werden. Die Bände 1–3 von "Internetworking with TCP/IP" von Corner und Stevens werden auch durch den Hinweis in ihrer Gesamtheit hierin aufgenommen.
  • Mit weiterem Bezug auf 1 ist eine Firewall 50A zwischen das WAN 10 und das Netz 16 geschaltet. Eine Firewall ist eine Vorrichtung, die nur berechtigten Computern auf einer Seite der Firewall erlaubt, auf das Netz, Computer oder individuelle Teile auf der anderen Seite der Firewall zuzugreifen. Firewalls sind bekannte und kommerziell erhältliche Vorrichtungen und/oder Software (z. B. ZoneAlarm von Zone Labs). Ebenso trennen die Firewalls 50B und 50C das WAN 10 von einem Netz 52 bzw. einem Arbeitsplatzrechner 42. Zusätzliche Details über Firewalls sind in "Firewalls and Internet Security" von W. R. Cheswick und S. M. Bellovin, 1994, Addison Wesley Publishing, und "Building Internet Firewalls", von D. B. Chapman und E. D. Zwicky, 1995, O'Reilly & Associates, Inc., zu finden. Die gesamten Inhalte dieser zwei Referenzen werden durch den Hinweis hierin aufgenommen.
  • Das Netz 52 ist ein herkömmliches Netz und umfasst mehrere Arbeitsplatzrechner 56, 62, 68 und 74. Diese Arbeitsplatzrechner können in verteilter Weise innerhalb verschiedener Abteilungen (z. B. Verkaufs-, Bestellungsverarbeitungs-, Buchhaltungs-, Abrechnungs-, Vermarktungs-, Fertigungs-, Konstruktionstechnik- und Kundendienstabteilungen) innerhalb einer einzelnen Firma angeordnet sein. Zusätzlich zu den über das Netz 52 verbundenen Arbeitsplatzrechnern ist auch ein Arbeitsplatzrechner 42, der nicht direkt mit dem Netz 52 verbunden ist, vorgesehen. Informationen in einer Datenbank, die auf einer Platte 46 gespeichert ist, die mit dem Arbeitsplatzrechner 42 verbunden ist, können unter Verwendung von geeigneter Verschlüsselung und Protokollen über das WAN 10 von den Arbeitsplatzrechnern, die direkt mit dem Netz 52 verbunden sind, gemeinsam genutzt werden. Der Arbeitsplatzrech ner 42 umfasst auch eine direkte Verbindung mit einer Telephonleitung und/oder einem Kabelnetz und/oder einem drahtlosen Netz 44 und auf die Datenbank auf der Platte 46 kann über die Telephonleitung, das Kabelnetz oder über das drahtlose Netz 44 zugegriffen werden. Das von dieser Erfindung verwendete Kabelnetz kann unter Verwendung eines Kabelnetzes, das typischerweise verwendet wird, um ein Fernsehprogramm zu übertragen, eines Kabels, das eine Hochgeschwindigkeitskommunikation von digitalen Daten bereitstellt, die typischerweise bei Computern oder dergleichen verwendet werden, oder irgendeines anderen gewünschten Typs von Kabel implementiert werden.
  • In einer weiteren Ausführungsform kann der Arbeitsplatzrechner 42 ein Laptopcomputer, ein PDA, ein Palmtop-Computer oder ein Mobiltelephon mit Netzfähigkeit sein. Diese Vorrichtungen können verwendet werden, um auf Informationen, die in der auf der Platte 46 gespeicherten Datenbank gespeichert sind, zuzugreifen.
  • Informationen in Bezug auf den digitalen Kopierer/Drucker 24, das Bürogerät 27, das Faxgerät 28 bzw. den Drucker 32 können in einer oder mehreren der Datenbanken, die auf den Platten 46, 54, 58, 64, 70 und 76 gespeichert sind, gespeichert sein. Bekannte Datenbanken umfassen (1) SQL-Datenbanken von Microsoft, IBM, Oracle und Sybase; (2) andere relationale Datenbanken; und (3) nicht relationale Datenbanken (einschließlich objektorientierter Datenbanken von Objectivity, JYD Software Engineering und Orient Technologies). Jede der Verkaufs-, Bestellungsverarbeitungs-, Buchhaltungs-, Abrechnungs-, Kundendienst-, Vermarktungs-, Fertigungs- und Konstruktionsabteilungen kann ihre eigene Datenbank besitzen oder kann sich eine oder mehrere Datenbanken teilen. Jede der Platten, die zum Speichern von Datenbanken verwendet werden, ist ein nicht flüchtiger Speicher wie z. B. eine Festplatte oder optische Platte. Alternativ können die Datenbanken in irgendeiner Speichervorrichtung gespeichert werden, einschließlich Festkörper- und/oder Halbleiterspeichervorrichtungen. Auf der Platte 64 kann beispielsweise eine Vermarktungsdatenbank gespeichert werden, auf der Platte 58 kann eine Fertigungsdatenbank gespeichert werden, auf der Platte 70 kann eine Konstruktionsdatenbank gespeichert werden und auf der Platte 76 kann eine Kundendienstdatenbank gespeichert werden. Alternativ können auf den Platten 54 und 46 eine oder mehrere der Datenbanken gespeichert werden.
  • Zusätzlich zu den Arbeitsplatzrechnern 56, 62, 68, 74 und 42, die mit dem WAN 10 verbunden sind, können diese Arbeitsplatzrechner auch eine Verbindung mit einer Telephonleitung, einem Kabel oder drahtlosen Netzen umfassen, um eine sichere Verbindung mit der Maschine/Vorrichtung, die überwacht, diagnostiziert und/oder gesteuert wird, zu schaffen. Wenn eines der Kommunikationsmedien nicht korrekt arbeitet, kann außerdem eines der anderen automatisch als Reserve für die Kommunikation verwendet werden.
  • Ein Merkmal der vorliegenden Erfindung ist die Verwendung einer Kommunikationsbetriebsart "Speichern und Weiterleiten" (z. B. elektronische Internetpost, hierin auch als E-Mail bezeichnet) oder die Übertragung zwischen einer Maschine und einem Computer/Überwachungssystem zum Diagnostizieren und Steuern der Maschine. Alternativ kann die Nachricht, die übertragen wird, unter Verwendung einer Kommunikationsbetriebsart implementiert werden, die direkte Ende-zu-Ende-Verbindungen herstellt (z. B. unter Verwendung einer Buchsenverbindung mit dem letztlichen Ziel) wie z. B. FTP und Hyper Text Transfer Protocol (HTTP).
  • 2 stellt die mechanische Anordnung des digitalen Kopierers/Druckers 24 dar, der in 1 dargestellt ist. In 2 ist 101 ein Gebläse für den Scanner, 102 ist ein Polygonspiegel, der mit einem Laserdrucker verwendet wird, und 103 bezeichnet eine F-θ-Linse, die verwendet wird, um Licht von einem Laser (nicht dargestellt) zu kollimieren. Das Bezugszeichen 104 bezeichnet einen Sensor zum Erfassen von Licht vom Scanner. Das Bezugszeichen 105 bezeichnet eine Linse zum Fokussieren von Licht vom Scanner auf den Sensor 104 und das Bezugszeichen 106 bezeichnet eine Löschlampe, die verwendet wird, um Bilder auf der photoleitenden Trommel 132 zu löschen. Es ist eine Aufladungskoronaeinheit 107 und eine Entwicklungswalze 108 vorhanden. Das Bezugszeichen 109 bezeichnet eine Lampe, die verwendet wird, um ein zu scannendes Dokument darzustellen, und Elemente 110, 111 und 112 bezeichnen Spiegel zum Reflektieren von Licht auf den Sensor 104. Ein Trommelspiegel 113 ist vorgesehen, um Licht auf die photoleitende Trommel 132 zu reflektieren, das vom Polygonspiegel 102 stammt. Ein Gebläse 114 wird verwendet, um den Aufladungsbereich der digitalen Bilderzeugungsvorrichtung zu kühlen, und eine erste Papiervorschubwalze 115 wird zum Vorschieben von Papier von der ersten Papierkassette 117 verwendet und ein Bezugszeichen 116 bezeichnet einen Tisch zum manuellen Vorschub. Ebenso wird eine zweite Papiervorschubwalze 118 in Verbindung mit der zweiten Kassette 119 verwendet. Das Bezugszeichen 120 bezeichnet eine Vermittlungswalze, 121 bezeichnet eine Deckungswalze, 122 bezeichnet einen Bilddichtesensor und 123 bezeichnet eine Übertragungs-/Trennkoronaeinheit. Das Bezugszeichen 124 bezeichnet eine Reinigungseinheit, 125 bezeichnet ein Vakuumgebläse, 126 bezeichnet einen Transportriemen, 127 bezeichnet eine Druckwalze und 128 bezeichnet eine Austrittswalze. Eine heiße Walze 129 wird verwendet, um Toner auf dem Papier zu fixieren. 130 bezeichnet ein Auslassgebläse und ein Hauptmotor 131 wird verwendet, um den digitalen Kopierer/Drucker 24 anzutreiben.
  • 3 ist ein Blockdiagramm, das die elektronischen Komponenten des digitalen Kopierers/Druckers 24 von 2 darstellt, wobei die CPU 160 ein Mikroprozessor ist, der als Steuereinheit der Vorrichtung wirkt. Ein Direktzugriffsspeicher (RAM) 162 speichert sich dynamisch ändernde Informationen, einschließlich Betriebsparametern des digitalen Kopierers/Druckers 24. Ein nicht flüchtiger Speicher (z. B. ein Festwertspeicher (ROM) 164 oder ein Flash-Speicher) speichert einen Programmcode, der verwendet wird, um den digitalen Kopierer/Drucker zu betreiben, sowie Daten im statischen Zustand, die den Kopierer/Drucker 24 beschreiben (z. B. den Modellnamen, die Modellnummer, die Seriennummer der Vorrichtung und Vorgabeparameter).
  • Eine Netzschnittstelle 166 mit mehreren Ports ist vorgesehen, um zu ermöglichen, dass der digitale Kopierer/Drucker 24 mit externen Vorrichtungen über mindestens ein Kommunikationsnetz kommuniziert. Das Bezugszeichen 168 stellt eine Telephon, eine drahtlose oder eine Kabelleitung dar und das Zeichen 170 stellt eine andere Art von Netz dar, das von dem bei 168 identifizierten Netz verschieden ist. Zusätzliche Details der Netzschnittstelle mit mehreren Ports werden mit Bezug auf 4 dargelegt. Eine Schnittstellensteuereinheit 172 wird verwendet, um ein Bedienfeld 174 mit einem Systembus 186 zu verbinden. Das Bedienfeld 174 umfasst Standard-Eingabe- und Ausgabevorrichtungen, die an einem digitalen Kopierer/Drucker 24 zu finden sind, einschließlich einer Kopiertaste, Tasten zum Steuern des Betriebs der Bilderzeugungsvorrichtung, wie beispielsweise der Anzahl von Kopien, Verkleinerung/Vergrößerung, Dunkelheit/Helligkeit usw. Außerdem kann eine Flüssigkristallanzeige innerhalb des Bedienfeldes 174 enthalten sein, um Parameter und Nachrichten des digitalen Kopierers/Druckers 24 für einen Benutzer anzuzeigen.
  • Eine lokale Verbindungsschnittstelle 171 ist eine Verbindung durch lokale Ports wie z. B. RS232, den parallelen Druckerport, USB und IEEE 1394. FireWire (IEEE 1394) ist in Wickelgren, I., "The Facts About "FireWire", IEEE Spectrum, April 1997, Band 34, Nummer 4, S. 19–25, beschrieben, dessen gesamte Inhalte durch den Hinweis hierin aufgenommen wird. Vorzugsweise wird ein "zuverlässiges" Kommunikationsprotokoll verwendet, das eine Fehlererkennung und Neuübertragung umfasst.
  • Eine Speicherschnittstelle 176 verbindet Speichervorrichtungen mit dem Systembus 186. Die Speichervorrichtungen umfassen beispielsweise einen Flash-Speicher 178, der gegen einen herkömmlichen elektrisch löschbaren programmierbaren Festwert speicher (EEPROM) ausgetauscht werden kann, und eine Platte 182. Die Platte 182 kann eine Festplatte, eine optische Platte und/oder ein Diskettenlaufwerk sein. Zusätzliche Speichervorrichtungen können über die Verbindung 180 mit dem digitalen Kopierer/Drucker 24 verbunden werden. Der Flash-Speicher 178 wird verwendet, um Daten im halbstatischen Zustand zu speichern, die Parameter des digitalen Kopierers/Druckers 24 beschreiben, die sich über die Lebensdauer der Vorrichtung 24 selten ändern. Solche Parameter umfassen beispielsweise die Optionen und Konfiguration des digitalen Kopierers/Druckers. Eine Optionsschnittstelle 184 ermöglicht, dass zusätzliche Hardware wie z. B. eine externe Schnittstelle mit dem digitalen Kopierer/Drucker 24 verbunden wird. Ein Takt/Zeitgeber 187 wird verwendet, um sowohl die Zeit als auch das Datum zu verfolgen und auch um die abgelaufene Zeit zu messen.
  • 3 stellt auch die verschiedenen Abschnitte dar, die den digitalen Kopierer/Drucker 24 bilden. Das Bezugszeichen 202 bezeichnet einen Sortiere und enthält Sensoren und Stellglieder, die verwendet werden, um die Ausgabe des digitalen Kopierers/Druckers 24 zu sortieren. Eine Doppelseitenvorrichtung 200 ermöglicht das Durchführen eines Doppelseitenvorgangs. Die Doppelseitenvorrichtung 200 umfasst herkömmliche Sensoren und Stellglieder. Eine Tabletteinheit 198 mit großem Fassungsvermögen ist vorgesehen, um zu ermöglichen, dass Papiertabletts eine große Anzahl von Blättern halten. Wie bei der Doppelseitenvorrichtung 200 umfasst die Tabletteinheit 198 ebenso herkömmliche Sensoren und Stellglieder.
  • Eine Papiervorschubsteuereinheit 196 wird verwendet, um den Vorgang des Vorschubs von Papier in und durch die digitale Bilderzeugungsvorrichtung zu steuern. Ein Scanner 194 wird verwendet, um Bilder in die digitale Bilderzeugungsvorrichtung zu scannen, und umfasst herkömmliche Scannelemente wie z. B. ein Licht, einen Spiegel usw. Außerdem werden Scannersensoren verwendet, wie z. B. ein Ruhepositionssensor, um festzustellen, dass sich der Scanner in der Ruheposition befindet, und ein Lampenthermistor wird verwendet, um einen korrekten Betrieb der Scannlampe sicherzustellen. Ein Drucker/eine Abbildungsvorrichtung 192 druckt die Ausgabe der digitalen Bilderzeugungsvorrichtung und umfasst einen herkömmlichen Laserdruckmechanismus, einen Tonersensor und einen Bilddichtesensor. Der Fixierer 190 wird verwendet, um den Toner auf die Seite unter Verwendung einer Hochtemperaturwalze zu fixieren, und umfasst einen Austrittssensor, einen Thermistor, um sicherzustellen, dass sich der Fixierer 190 nicht überhitzt, und einen Ölsensor. Außerdem ist eine Schnittstelle 188 einer optionalen Einheit vorhanden, die verwendet wird, um optionale Elemente der digitalen Bilderzeugungsvorrichtung anzuschließen, wie z. B. eine automatische Dokumentenvorschubeinrichtung, eine andere Art von Sortierer/Prüfer oder andere Elemente, die zur digitalen Bilderzeugungsvorrichtung hinzugefügt werden können. Andere Elemente umfassen eine GPS-Einheit, die den Ort der Vorrichtung identifizieren kann.
  • 4 stellt Details der Netzschnittstelle 166 mit mehreren Ports dar. Die digitale Bilderzeugungsvorrichtung kann mit externen Vorrichtungen über eine Token-Ring-Schnittstelle 220, eine Kabelmodemeinheit 222, die eine Hochgeschwindigkeitsverbindung über ein Kabel aufweist, eine herkömmliche Telephonschnittstelle 224, die mit einer Telephonleitung 168A verbindet, eine drahtlose Schnittstelle 228 oder eine Ethernet-Schnittstelle 230, die mit einem LAN 170 verbindet, kommunizieren. Andere Schnittstellen können umfassen, sind jedoch nicht begrenzt auf eine digitale Teilnehmerleitung (DSL) (ursprüngliche DSL, konzentrische DSL und asymmetrische DSL). Eine einzelne Vorrichtung, die mit sowohl einem lokalen Netz als auch einer Telephonleitung verbindet, ist von Intel kommerziell erhältlich und ist als Intel Pro 10/100+ Modem bekannt.
  • Die CPU oder ein anderer Mikroprozessor oder eine andere Schaltungsanordnung führt einen Überwachungsprozess aus, um den Zustand von jedem der Sensoren der digitalen Bilderzeugungsvorrichtung zu überwachen, und ein Ablaufsteuerungsprozess wird verwendet, um die Befehle des Codes auszuführen, der zum Steuern und Betreiben der digitalen Bilderzeugungsvorrichtung verwendet wird. Außerdem wird (1) ein Zentralsystem-Steuerprozess ausgeführt, um den Gesamtbetrieb der digitalen Bilderzeugungsvorrichtung zu steuern, und (2) ein Kommunikationsprozess wird verwendet, um eine zuverlässige Kommunikation mit externen Vorrichtungen, die mit der digitalen Bilderzeugungsvorrichtung verbunden sind, sicherzustellen. Der Systemsteuerprozess überwacht und steuert die Datenspeicherung in einem statischen Zustandsspeicher (z. B. dem ROM 164 in 2), einem halbstatischen Speicher (z. B. dem Flash-Speicher 178 oder der Platte 182) oder dem dynamischen Zustandsspeicher (z. B. einem flüchtigen oder nicht flüchtigen Speicher (z. B. dem RAM 162, dem Flash-Speicher 178 oder der Platte 182.). Außerdem kann der statische Zustandsspeicher eine andere Vorrichtung als der ROM 164 wie z. B. ein nicht flüchtiger Speicher, einschließlich eines des Flash-Speichers 178 oder der Platte 182, sein.
  • Die obigen Details wurden in Bezug auf eine digitale Bilderzeugungsvorrichtung beschrieben, aber die vorliegende Erfindung ist gleichermaßen auf andere Geschäftsbüromaschinen oder -vorrichtungen wie z. B. einen analogen Kopierer, ein Faxgerät, einen Scanner, einen Drucker, einen Faxserver, einen Projektor, eine Konferenzan tage, einen Aktenvernichter oder andere Geschäftsbüromaschinen, ein Geschäftsbürogerät oder andere Geräte (z. B. einen Mikrowellenofen, einen VCR, eine DVD, eine Digitalkamera, digitale Camcorder, ein Mobiltelephon, einen Palmtop-Computer) anwendbar. Außerdem umfasst die vorliegende Erfindung andere Arten von Vorrichtungen, die unter Verwendung einer Speicher- und Weiterleitungs-Kommunikation oder einer Kommunikation auf der Basis einer direkten Verbindung arbeiten. Solche Vorrichtungen umfassen, Messsysteme (einschließlich Gas-, Wasser- oder Elektrizitätsmesssystemen), Verkaufautomaten, oder eine beliebige mechanische Vorrichtung (z. B. Kraftfahrzeuge, Motorräder, Waschmaschine, Trockner), die während des Betriebs oder einer Ferndiagnose überwacht werden muss. Zusätzlich zur Überwachung von Spezialmaschinen und Computern kann die Erfindung verwendet werden, um einen Universalcomputer zu überwachen, zu steuern und zu diagnostizieren, der die überwachte und/oder gesteuerte Vorrichtung wäre.
  • 5 stellt ein alternatives Systemdiagramm der vorliegenden Erfindung dar, in dem verschiedene Vorrichtungen und Untersysteme mit dem WAN 10 verbunden sind. Es besteht jedoch keine Anforderung, dass jede dieser Vorrichtungen oder jedes dieser Untersysteme als Teil der Erfindung vorliegt. Jede Komponente oder jedes Untersystem, das in 5 dargestellt ist, ist individuell ein Teil der Erfindung. Ferner können die in 1 dargestellten Elemente mit dem WAN 10 verbunden sein, das in 5 dargestellt ist. In 5 ist eine Firewall 50-1 dargestellt, die mit einem Intranet 260-1 verbunden ist. Eine Dienstmaschine 254, die mit dem Intranet 260-1 verbunden ist, umfasst darin Daten 256, die in einem Datenbankformat gespeichert sein können, oder ist mit diesen verbunden. Die Daten 256 umfassen eine Geschichte, Leistung, Funktionsstörung und beliebige andere Informationen, wie z. B. statistische Informationen des Betriebs oder Ausfalls oder der Einrichtung der überwachten Vorrichtungen, oder Konfigurationsinformationen, wie z. B. welche Komponenten oder optionale Anlage in den überwachten Vorrichtungen enthalten ist. Die Dienstmaschine 254 kann als Vorrichtung oder Computer implementiert werden, der die überwachten Vorrichtungen auffordert, Daten zu übertragen, oder der anfordert, dass eine Fernsteuerung und/oder Diagnosetests an den überwachten Vorrichtungen durchgeführt werden. Die Dienstmaschine 254 kann als beliebige Art von Vorrichtung implementiert werden und wird vorzugsweise unter Verwendung einer computerisierten Vorrichtung wie z. B. eines Universalcomputers implementiert. Die Dienstmaschine 254 kann auch aus mehreren Computern über das Netz mit einer unterschiedlichen Datenbank, einschließlich Abrechnung, Buchhaltung, Dienstverarbeitung, Teileverfolgung und Berichten, bestehen.
  • Ein weiteres Untersystem von 5 umfasst eine Firewall 50-2, ein Intranet 260-2 und einen Drucker 262, der damit verbunden ist. In diesem Untersystem werden die Funktionen des Sendens und Empfangens von elektronischen Nachrichten durch den Drucker 262 (und ebenso durch einen Kopierer 286) durch (1) eine Schaltungsanordnung, (2) einen Mikroprozessor oder (3) irgendeine andere Art von Hardware, die in dem Drucker 262 enthalten oder an diesem angebracht ist (d. h. ohne Verwendung eines separaten Universalcomputers), durchgeführt.
  • Eine alternative Art von Untersystem umfasst die Verwendung eines Internet-Dienstanbieters 264, der eine beliebige Art von Internet-Dienstanbieter (ISP) sein kann, einschließlich bekannter kommerzieller Gesellschaften, wie z. B. America Online, Earthlink und Niftyserve. In diesem Untersystem ist ein Computer 266 mit dem ISP 264 über ein digitales oder analoges Modem (z. B. ein Telephonleitungsmodem, ein Kabelmodem, Modems, die eine beliebige Art von Drähten verwenden, wie z. B. Modems, die über einer asymmetrischen digitalen Teilnehmerleitung (ADSL) verwendet werden, Modems, die eine Rahmenweiterleitungskommunikation verwenden, drahtlose Modems wie z. B. ein Hochfrequenzmodem, ein faseroptisches Modem oder eine Vorrichtung, die Infrarotlichtwellen verwendet) verbunden. Ferner ist eine Geschäftsbürovorrichtung 268 mit dem Computer 266 verbunden. Als Alternative zur Geschäftsbürovorrichtung 268 (oder irgendeiner anderen Vorrichtung, die in 5 dargestellt ist), kann eine andere Art von Maschine überwacht oder gesteuert werden, wie z. B. ein digitaler Kopierer, eine beliebige Art von Gerät, ein Sicherheitssystem oder ein Versorgungsmessgerät, wie z. B. ein elektrisches, Wasser- oder Gasversorgungsmessgerät, oder irgendeine andere hierin erörterte Vorrichtung.
  • In 5 ist auch eine Firewall 50-3, die mit einem Netz 274 verbunden ist, dargestellt. Das Netz 274 kann als beliebige Art von Computernetz (z. B. ein Ethernet oder Token-Ring-Netz) implementiert werden. Eine Vernetzungssoftware, die verwendet werden kann, um das Netz zu steuern, umfasst eine beliebige gewünschte Vernetzungssoftware, einschließlich einer Software, die von Novell oder Microsoft kommerziell erhältlich ist. Das Netz 274 kann als Intranet implementiert werden, falls erwünscht. Ein mit dem Netz 274 verbundener Computer 272 kann verwendet werden, um Informationen von einer Geschäftsbürovorrichtung 278 zu erhalten und Berichte wie z. B. Berichte, die Probleme zeigen, die in verschiedenen mit dem Netz verbundenen Maschinen aufgetreten sind, und einen monatlichen Nutzungsbericht der mit dem Netz 274 verbundenen Vorrichtungen zu erzeugen. In dieser Ausführungsform ist ein Computer 276 zwischen die Geschäftsbürovorrichtung 278 und das Netz 274 geschaltet. Dieser Computer empfängt Kommunikationen vom Netz und leitet die geeigneten Befehle oder Daten oder beliebige andere Informationen zur Geschäftsbürovorrichtung 278 weiter.
  • Die Kommunikation zwischen der Geschäftsbürovorrichtung 278 und dem Computer 276 kann unter Verwendung von Verfahren auf Drahtbasis oder drahtlosen Verfahren bewerkstelligt werden, einschließlich, jedoch nicht begrenzt auf Hochfrequenzverbindungen, elektrische Verbindungen und Lichtverbindungen (z. B. eine Infrarotverbindung oder eine faseroptische Verbindung). Ebenso kann jedes der verschiedenen Netze und Intranets, die in 5 dargestellt sind, unter Verwendung einer beliebigen gewünschten Weise aufgebaut werden, einschließlich durch den Aufbau von drahtlosen Netzen wie z. B. Hochfrequenznetzen. Die hierin beschriebene drahtlose Kommunikation kann unter Verwendung von Streuspektrumverfahren aufgebaut werden, einschließlich Verfahren, die einen Streucode und Frequenzsprungverfahren verwenden, wie z. B. das drahtlose Frequenzsprungverfahren, das in der Bluetooth-Spezifikation offenbart ist (erhältlich auf der Site des Word Wide Web www.bluetooth.com), die durch den Hinweis hierin aufgenommen wird.
  • Ein weiteres Untersystem, das in 5 dargestellt ist, umfasst eine Firewall 50-4, ein Intranet 260-4, einen Computer 282, der damit verbunden ist, ein Geschäftsbürogerät 285 und einen Kopierer 286. Der Computer 282 kann verwendet werden, um Berichte zu erzeugen und Diagnose- oder Steuerprozeduren anzufordern. Diese Diagnose- und Steuerprozeduren können in Bezug auf das Geschäftsbürogerät 285 und den Kopierer 286 oder irgendeine der anderen Vorrichtungen, die in 5 dargestellt sind oder verwendet werden, durchgeführt werden. Obwohl 5 mehrere Firewalls darstellt, sind die Firewalls eine bevorzugte, aber optionale Ausrüstung und daher kann die Erfindung ohne Verwendung von Firewalls betrieben werden, falls erwünscht. Für die Überwachung und Steuerung der vernetzten Anlage können anstelle von 254 beliebige Computer (266, 272 oder 282) verwendet werden. Außerdem kann irgendein Computer auf 254 zugreifen, um erforderliche Vorrichtungsinformationen oder Verwendungsinformationen über das Web abzurufen.
  • 6A stellt eine Vorrichtung/ein Gerät 300 dar, das mit einem typischen E-Mail-Austauschsystem verbunden ist, das die Komponenten 302, 304, 306, 308, 310, 312, 314, 316 und 318 umfasst, die in einer herkömmlichen Weise implementiert werden können und von 28.1 von Stevens, vorstehend, angepasst sind. Eine Computerschnittstelle 302 bildet mit irgendeiner der Anwendungseinheiten oder Vorrichtungen/Geräten 300, die hierin beschrieben sind, eine Schnittstelle. Obwohl 6A darstellt, dass die Vorrichtung/das Gerät 300 der Sender ist, können die Sende- und Empfangsfunktionen in 6A umgekehrt werden. Ferner kann der Benutzer, falls erwünscht, mit der Vorrichtung/dem Gerät 300 überhaupt keine Schnittstelle bilden müssen. Die Computerschnittstelle 302 wirkt dann mit einem Postagenten 304 zusammen. Populäre Postagenten für Unix umfassen MH, Berkeley Mail, Elm und Mush. Postagenten für die Windows-Familie von Betriebssystemen umfassen Microsoft Gutlook und Microsoft Gutlook Express. Bei der Anforderung der Computerschnittstelle 302 erzeugt der Postagent 304 zu sendende E-Mail-Nachrichten und setzt, falls erwünscht, diese zu sendenden Nachrichten in eine Warteschlange 306. Die zu sendende Post wird zu einem Nachrichtenübertragungsagenten (MTA) 308 weitergeleitet. Ein üblicher MTA für Unix-Systeme ist Sendmail. Typischerweise tauschen die Nachrichtenübertragungsagenten 308 und 312 Kommunikationen unter Verwendung einer TCP/IP-Verbindung 310 aus. Beachtenswerterweise kann die Kommunikation zwischen den Nachrichtenübertragungsagenten 308 und 312 über ein Netz mit beliebiger Größe (z. B. WAN oder LAN) stattfinden. Ferner können die Nachrichtenübertragungsagenten 308 und 312 ein beliebiges Kommunikationsprotokoll verwenden. In einer Ausführungsform der vorliegenden Erfindung befinden sich die Elemente 302 und 304 von 6A in der Bibliothek, um die Verwendung der Anwendungseinheit zu überwachen.
  • Vom Nachrichtenübertragungsagenten 312 werden E-Mail-Nachrichten in Benutzerbriefkästen 314 gespeichert, die zum Postagenten 316 übertragen und schließlich zum Benutzer an einem Endgerät 318 übertragen werden, das als Empfangsendgerät fungiert.
  • Dieser Prozess zum "Speichern und Weiterleiten" entlastet den Sendepostagenten 304 davon, dass er warten muss, bis eine direkte Verbindung mit dem Postempfänger aufgebaut ist. Aufgrund von Netzverzögerungen könnte die Kommunikation eine beträchtliche Menge an Zeit erfordern, während der die Anwendung nicht reagieren würde. Solche Verzögerungen im Ansprechvermögen könnten für Benutzer der Anwendungseinheit im Allgemeinen unannehmbar sein. Unter Verwendung von E-Mail als Prozess zum Speichern und Weiterleiten geschehen Neuübertragungsversuche nach Ausfällen automatisch für einen festgelegten Zeitraum (z. B. drei Tage). In einer alternativen Ausführungsform kann die Anwendung das Warten vermeiden, indem sie Kommunikationsanforderungen zu einem oder mehreren separaten Teilprozessen leitet. Diese Teilprozesse können dann die Kommunikation mit dem Empfangsendgerät 318 steuern, während die Anwendung beginnt, wieder auf die Benutzerschnittstelle zu reagieren. In noch einer weiteren Ausführungsform, in der ein Benutzer wünscht, dass die Kommunikation vor der Fortsetzung beendet wird, wird eine direkte Kommunikation mit dem Empfangsendgerät verwendet. Eine solche direkte Kommunikation kann ein beliebiges Protokoll verwenden, das nicht durch eine Firewall zwischen dem Sende- und dem Empfangsendgerät blockiert wird. Beispiele solcher Protokolle umfassen Telnet, File Transfer Protocol (FTP) und Hyper Text Transfer Protocol (HTTP).
  • Öffentliche WANs wie z. B. das Internet werden im Allgemeinen nicht als sicher betrachtet. Wenn es erwünscht ist, Nachrichten vertraulich zu halten, können daher Nachrichten, die über die öffentlichen WANs (und private WANs mehrerer Firmen) übertragen werden, verschlüsselt werden. Verschlüsselungsmechanismen sind bekannt und kommerziell erhältlich und können bei der vorliegenden Erfindung verwendet werden. Eine C++-Bibliotheksfunktion, crypt(), steht beispielsweise von Sun Microsystems zur Verwendung beim Unix-Betriebssystem zur Verfügung. Verschlüsselungs- und Entschlüsselungs-Softwarepakete sind bekannt und kommerziell erhältlich und können auch bei dieser Erfindung verwendet werden. Ein solches Paket ist PGP, das von PGP Corporation erhältlich ist.
  • Als Alternative zur allgemeinen Struktur von 6A kann ein einzelner Computer, der als Computerschnittstelle 302, als Postagent 304, als Postwarteschlange 306 und als Nachrichtenübertragungsagent 308 funktioniert, verwendet werden. Wie in 6B dargestellt, ist die Vorrichtung/das Gerät 300 mit einem Computer 301 verbunden, der den Nachrichtenübertragungsagenten 308 umfasst.
  • Eine weitere alternative Struktur ist in 6C gezeigt, in der der Nachrichtenübertragungsagent 308 als Teil der Vorrichtung/des Geräts 300 gebildet ist. Ferner ist der Nachrichtenübertragungsagent 308 mit dem Nachrichtenübertragungsagenten 312 durch eine TCP/IP-Verbindung 310 verbunden. In der Ausführungsform von 6C ist die Vorrichtung/das Gerät 300 direkt mit der TCP/IP-Verbindung 310 mit einer E-Mail-Fähigkeit verbunden. Eine Verwendung der Ausführungsform von 6C umfasst die Verwendung eines Faxgeräts mit einer E-Mail-Fähigkeit (z. B. wie in RFC 2305 (eine einfache Betriebsart von Fax unter Verwendung von Internet-Post) definiert) als Vorrichtung/Gerät 300.
  • 6D stellt ein System dar, in dem die Vorrichtung/das Gerät 300 nicht selbst die Fähigkeit hat, E-Mail direkt zu empfangen, sondern eine Verbindung 310 mit einem Postserver/POP3-Server mit einem Nachrichtenübertragungsagenten 308 und einem Briefkasten 314 aufweist, so dass die Vorrichtung/das Gerät 300 das POP3-Protokoll verwendet, um empfangene Post vom Postserver abzurufen.
  • 7 stellt eine alternative Implementierung der Übertragung von Post dar und ist von 28.3 von Stevens angepasst, auf das vorher Bezug genommen wurde. 7 stellt ein elektronisches Postsystem mit einem Weiterleitungssystem an jedem Ende dar. Die Anordnung von 7 ermöglicht, dass ein System in einer Organisation als Post-Hub wirkt. In 7 sind vier MTAs zwischen die zwei Postagenten 304 und 316 geschaltet. Diese MTAs umfassen einen lokalen MTA 332A, einen Weiterleitungs-MTA 328A, einen Weiterleitungs-MTA 328B und einen lokalen MTA 322D. Das üblichste Protokoll, das für Postnachrichten verwendet wird, ist SMTP (Simple Mail Transfer Protocol), das bei dieser Erfindung verwendet werden kann, obwohl ein beliebiges gewünschtes Postprotokoll verwendet werden kann. In 7 bezeichnet 320 einen sendenden Host, der die Computerschnittstelle 302, den Postagenten 304 und den lokalen MTA 322A umfasst. Die Vorrichtung/das Gerät 300 ist mit dem sendenden Host 320 verbunden oder alternativ in diesem enthalten. Als weiterer Fall können sich die Vorrichtung/das Gerät 300 und der Host 320 in einer Maschine befinden, wobei die Host-Fähigkeit in die Vorrichtung/das Gerät 300 eingebaut ist. Andere lokale MTAs 3228, 322C, 322E und 322F können auch enthalten sein. Zu sendende und zu empfangende Post kann in eine Postwarteschlange 306B des Weiterleitungs-MTA 328A gestellt werden. Die Nachrichten werden über die TCP/IP-Verbindung 310 (z. B. eine Internet-Verbindung oder eine Verbindung über irgendeine andere Art von Netz) übertragen.
  • Die übertragenen Nachrichten werden vom Weiterleitungs-MTA 328B empfangen und, falls erwünscht, in einer Postwarteschlange 306C gespeichert. Die Post wird dann zum lokalen MTA 322D eines empfangenden Host 342 weitergeleitet. Die Post kann in einen oder mehrere der Benutzerbriefkästen 314 gegeben und anschließend zum Postagenten 316 weitergeleitet und schließlich zum Benutzer an einem Endgerät 318 weitergeleitet werden. Falls erwünscht, kann die Post ohne Benutzereingriff direkt zum Endgerät weitergeleitet werden.
  • Die in der vorliegenden Erfindung verwendeten verschiedenen Computer, einschließlich der Computer 266 und 276 von 5, können wie in 8 dargestellt implementiert werden. Ferner kann irgendein anderer Computer, der in dieser Erfindung verwendet wird, in einer ähnlichen Weise zu dem in 8 dargestellten Computer implementiert werden, falls erwünscht, einschließlich der Dienstmaschine 254, des Computers 272 und des Computers 282 von 5. Nicht jedes in 8 dargestellte Element ist jedoch in jedem dieser Computer erforderlich.
  • In 8 umfasst der Computer 360 eine CPU 362, die als beliebige Art von Prozessor implementiert werden kann, einschließlich kommerziell erhältlicher Mikroprozessoren von Firmen wie z. B. Intel, AMD, Motorola, Hitachi und NEC. Es ist ein Arbeitsspeicher wie z. B. ein RAM 364 und eine drahtlose Schnittstelle 366, die mit einer drahtlosen Vorrichtung 368 kommuniziert, vorhanden. Die Kommunikation zwischen der Schnittstelle 366 und der Vorrichtung 368 kann ein beliebiges drahtloses Medium (z. B. Funkwellen oder Lichtwellen) verwenden. Die Funkwellen können unter Verwendung eines Streuspektrumverfahrens wie z. B. einer Kommunikation mit Code Division Multiple Access (CDMA) oder unter Verwendung eines Frequenzsprungverfahrens wie z. B. des in der Bluetooth-Spezifikation offenbarten implementiert werden.
  • Der Computer 360 umfasst einen ROM 370 und einen Flash-Speicher 371, obwohl eine beliebige andere Art von nicht flüchtigem Speicher (z. B. ein löschbarer programmierbarer ROM oder ein EEPROM) zusätzlich zu oder anstelle von dem Flash-Speicher 371 verwendet werden kann. Mit einer Eingabesteuereinheit 372 ist eine Tastatur 374 und eine Maus 376 verbunden. Eine serielle Schnittstelle 378 ist mit einer seriellen Vorrichtung 380 verbunden. Außerdem ist eine parallele Schnittstelle 382 mit einer parallelen Vorrichtung 384 verbunden, eine Schnittstelle 386 eines universellen seriellen Busses (USB) ist mit einer Vorrichtung 388 eines universellen seriellen Busses verbunden, und es ist auch eine Vorrichtung 400 für IEEE 1394 vorhanden, die üblicherweise als Firewire-Vorrichtung bezeichnet wird, die mit einer Schnittstelle 398 für IEEE 1394 verbunden ist. Ein Systembus 390 verbindet die verschiedenen Elemente des Computers 360. Eine Plattensteuereinheit 396 ist mit einem Diskettenlaufwerk 394 und einem Festplattenlaufwerk 392 verbunden. Eine Kommunikationssteuereinheit 406 ermöglicht, dass der Computer 360 mit anderen Computern (z. B. durch Senden von E-Mail-Nachrichten) über ein Netz 404 kommuniziert. Eine E/A-Steuereinheit (Eingabe/Ausgabe-Steuereinheit) 408 ist mit einem Drucker 410 und einer Festplatte 412 beispielsweise unter Verwendung eines SCSI-Busses (Bus einer Schnittstelle für ein kleines Computersystem) verbunden. Eine Anzeigesteuereinheit 416 ist auch mit einer CRT (Kathodenstrahlröhre) 414 verbunden, obwohl irgendeine andere Art von Anzeige verwendet werden kann, einschließlich einer Flüssigkristallanzeige, einer Leuchtdiodenanzeige, einer Plasmaanzeige usw.
  • Mit Bezug nun auf 9 ist eine schematische Darstellung des Gesamtsystems 900 gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung gezeigt. Es ist gezeigt, dass das System 900 mehrere Vorrichtungen umfasst, beispielsweise einen Laserdrucker 908, einen Scanner 910, eine Netzvorrichtung 912 und einen Multifunktionsdrucker 914, die alle mit einem Netz 100 verbunden sind. Diese mehreren Vorrichtungen werden hierin im Allgemeinen als "überwachte Vorrichtungen" bezeichnet. Das System 900 umfasst auch ein Arbeitsplatzrechner-/Überwachungssystem 902 (nachstehend als Steuereinheit 902 bezeichnet), das mit dem Netz 100 zur Überwachung und Steuerung der überwachten Vorrichtungen 908, 910, 912 und 914 verbunden ist. Jeder der überwachten Vorrichtungen 908, 910, 912 und 914 ist eine eindeutige Adresse gegeben. Beispielsweise dient eine einer Vorrichtung zugewiesene IP-Adresse als eindeutige Adresse für die Vorrichtung. Folglich kann ein Benutzer an der Steuereinheit 902 auf eine jeweilige Vorrichtung unter den überwachten Vorrichtungen 908–914 zugreifen, indem er auf die eindeutige IP-Adresse, die der jeweiligen überwachten Vorrichtung zugewiesen ist, zugreift. Es ist zu erkennen, dass die vorliegende Erfindung nicht auf die Verwendung von IP-Adressen zum eindeutigen Identifizieren von Vorrichtungen, die mit einem Netz verbunden sind, begrenzt ist.
  • Die Steuereinheit 902 erhält beim Zugreifen auf eine Vorrichtung unter den überwachten Vorrichtungen 908–914 verschiedene Informationen über SNMP- und/oder HTTP-Protokolle. Solche Informationen umfassen detaillierte Informationen über den Betriebsstatus der Vorrichtung, einschließlich einer Fehlersuchinformation. Die Steuereinheit 902 greift beispielsweise auf den Stauort einer speziellen Vorrichtung zu und erhält diesen und sendet eine Nachricht zu der Person, die für die Vorrichtung verantwortlich ist, um den Stau zu beseitigen. Der Betriebsstatus/die Details des Laserdruckers 908 umfassen solche Details wie Tonerpegel, Angabe von Papierstau, Menge von Druckpapier in den Druckertabletts usw.
  • Es ist zu erkennen, dass die Steuereinheit 902 mit dem Netz 100 entweder physikalisch verbunden oder drahtlos gekoppelt sein kann. Ein persönlicher digitaler Assistent (PDA) 920 oder ein Laptopcomputer 922, die als drahtlos mit dem Netz 100 gekoppelt gezeigt sind, kann beispielsweise auch als Steuereinheit 902 verwendet werden. Ein Zugriffspunkt 924 wirkt als Schnittstelle, um drahtlose Kommunikationen zwischen dem Netz 100 und dem PDA 922 oder Laptopcomputer 922 zu ermöglichen. Von nun an wird die vorliegende Erfindung unter der Annahme beschrieben, dass die Steuereinheit 902 den Status der mit dem Netz verbundenen überwachten Vorrichtungen steuert und überwacht.
  • Das Netz 100 erleichtert die Kommunikation zwischen der Steuereinheit 902 und den überwachten Vorrichtungen 908–914, um die Überwachung und Steuerung von solchen überwachten Vorrichtungen zu ermöglichen. Die Anzahl von Vorrichtungen, die mit dem Netz verbunden sind, ist keine Begrenzung der vorliegenden Erfindung. Es ist zu erkennen, dass das Netz 100 ein lokales Netz (LAN) oder ein weiträumiges Netz (WAN) sein kann. Ebenso sind die überwachten Vorrichtungen 908, 910, 912 und 914 als lediglich beispielhaft gezeigt.
  • Die Steuereinheit 902 ist mit einer Speichervorrichtung 904 und einer Datenbank 906 kommunikativ gekoppelt. Die Speichervorrichtung 904 umfasst eine Festplatte, eine optische Platte und/oder ein externes Plattenlaufwerk. Die Datenbank 906 ist mit der Speichervorrichtung 904 kommunikativ gekoppelt und umfasst ein Managementsystem für eine relationale Datenbank (RDBMS) für eine leichte Suche und ein leichtes Abrufen von Daten, die in der Speichervorrichtung 904 gespeichert sind. Die Speichervorrichtung 904 speichert vorzugsweise detaillierte Informationen über jede der überwachten Vorrichtungen 908–914. Detaillierte Informationen wie z. B. Herstellung, Modell und verschiedene Funktionen und Fehlersuchdetails des Laserdruckers 908 werden beispielsweise in der Speichervorrichtung 904 gespeichert. Abweichungswerte über den Betriebsstatus des Laserdruckers im Vergleich zu vorbestimmten Referenzwerten können auch in der Speichervorrichtung 904 gespeichert werden. Obwohl die Datenverarbeitung 906 und die Speichervorrichtung 904 als mit der Steuereinheit 902 kommunikativ gekoppelt beschrieben werden, ist zu erkennen, dass die Steuereinheit 902 so aufgebaut sein kann, dass die Speichervorrichtung und die Datenbank darin installiert sind. In einem solchen Fall würden die Speichervorrichtung 906 und die Datenbank 904 als innerhalb der Steuereinheit 902 dargestellt werden.
  • In der Steuereinheit 902 ist eine Software installiert, um die Überwachung und Steuerung der mehreren Vorrichtungen 908–914 zu erleichtern. Ein Simple Network Management Protocol (SNMP), File Transfer Protocol (FTP) und Hyper Text Transfer Protocol (HTTP) werden von der Steuereinheit 902 zur Überwachung der mehreren Vorrichtungen 908–914 verwendet und die von den mehreren Vorrichtungen 908–914 empfangenen Daten werden in Form des ASN.1 Binärformats oder HTML- oder XML-Formaten dargestellt, wie in 950 gezeigt.
  • Obwohl 9 nur die Abbildungsvorrichtungen darstellt, kann das Netz für die Kommunikation von Informationen zwischen der Überwachungsvorrichtung und den mehreren überwachten Vorrichtungen das Heimnetz umfassen, wobei die Geräte und Messgeräte mit dem Netz verbunden sind. Es ist zu erkennen, dass die von der Steuereinheit/vom Arbeitsplatzrechner 902 gesammelten Daten über E-Mail, FTP oder irgendein anderes Kommunikationsprotokollmittel zu einer entfernten Vorrichtung zur Weiterverarbeitung gesandt werden können. Obwohl der Arbeitsplatzrech ner 902, der PDA 920 oder der Laptop 922 die Steuereinheit sein kann, die die Daten sammelt und die Daten speichert oder die Daten über ein Kommunikationsprotokoll sendet, ist zu erkennen, dass die Steuereinheit eine beliebige der mit dem Netz verbundenen Vorrichtungen sein kann. Beliebige der Netzvorrichtungen (z. B. Drucker) können das Überwachungssystem enthalten, das in der Lage ist, den Status anderer Vorrichtungen im Netz zu überwachen, die gesammelten Daten zu speichern und/oder die gesammelten Daten über irgendein anderes Kommunikationsprotokollmittel (z. B. E-Mail, FTP) zu senden. Verschiedene Modelle von einigen Verkäufern sind in der Lage, E-Mail zu senden.
  • Überwachungssystemarchitektur
  • 10 stellt ein Überwachungssystem 1000 (und zugehörige Schnittstellenfunktionen), die bei der Überwachung von Daten verwendet werden, die entfernten Vorrichtungen zugeordnet sind, gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung dar. Das Überwachungssystem 1000 umfasst das Softwaremodul MonitorService 1004, das ein im Computer befindliches Programm wie z. B. Service in NT oder Windows 2000 und Daemon in Unix ist. In einer bevorzugten Ausführungsform wird das Überwachungssystem unter Verwendung einer objektorientierten Softwareumgebung implementiert. Im Überwachungssystem 1000 sind auch ein Zeitgebermodul 1002 und ein Überwachungsmodul 1006 enthalten. Das Zeitgebermodul 1002 und das Überwachungsmodul 1006 sind Bibliotheksfunktionen, die vom MonitorService-Modul 1004 aufgerufen werden sollen. MonitorService 1004 initialisiert beispielsweise das Zeitgebermodul 1002 durch Aufrufen der Funktion InitTimer 1003 und erhält Verzögerungs- und Handlungsparameter durch Aufrufen der Funktion obtainDelayAndAction (int &, int &). Die init()-Funktion wird auch vom MonitorService-Modul 1004 aufgerufen, um verschiedene Module im Überwachungsmodul 1006 zu initialisieren, wie in 13 dargestellt. Die finit()-Funktion kann verwendet werden, um die IP-Adresse und einen Parameterwert, die einer überwachten Vorrichtung zugewiesen sind, über eine externe Quelle, die IP-Adressen, Parameternamen und Werte, die durch bekannte Verfahren gesammelt werden, enthält, zu erhalten. Das Überwachungsmodul 1006 ist mit einer Unterstützungsdatenbank 1024 und mit einer Überwachungsdatenbank 1014, die nachstehend genauer beschrieben werden, kommunikativ gekoppelt.
  • Sobald die IP-Adresse einer überwachten Vorrichtung erhalten ist, wird die IP-Adresse vom Überwachungssystem verwendet, um die überwachte Vorrichtung zu kontaktieren, um Informationen wie z. B. Herstellerinformationen (Verkäuferinformati onen) und Modellinformationen zu erhalten. Einige der vom Überwachungssystem 1000 ausgeführten Funktionen umfassen:
  • void initTimer(void)
  • Diese Funktion initialisiert den Zeitgeber. Insbesondere löst diese Funktion das Zeitgeberobjekt aus, um die Zeitablaufinformationen von der Registrierdatenbank zu erhalten.
  • void obtainDelayAndAction(int & out_nDelay, int & out_nAction)
  • Diese Funktion gibt die Verzögerungszeit in Sekunden für die ::Sleep-Funktion (muss 1000 multiplizieren) und den Handlungsindikator zurück. Der Handlungsindikator ist folgendermaßen definiert: 0 = Ereignisprüfung; 1 = Senden der überwachten Daten; und 2 = Überwachen und Speichern der Daten in der lokalen Datenbank.
  • int init(void)
  • Diese Funktion initialisiert die Überwachungseinrichtung. Außerdem erzeugt sie die zu überwachenden Vorrichtungen. Die Rückgabe int ist der Fehlercode, in dem Null als kein Fehler definiert ist.
  • int monitorStatus(int in_nAction)
  • Diese Funktion überwacht die vorgegebenen Informationen. Die Rückgabe int ist der Fehlercode, in dem Null als kein Fehler definiert ist.
  • int end(void)
  • Diese Funktion bereinigt die Überwachungseinrichtung, bevor die Objekte geschlossen werden. Die Rückgabe int ist der Fehlercode, in dem Null als kein Fehler definiert ist.
  • Überwachungsmodul
  • 11 zeigt die Strukturdetails des Überwachungsmoduls 1006, einschließlich der verschiedenen Softwareuntermodule, und die Aufruffunktionen zwischen den Untermodulen des Überwachungsmoduls 1006. Das Überwachungsmodul 1006 umfasst ein Common-Modul 1101, das Klassen enthält, die von vielen Modulen verwendet werden, ein MonitorManager-Modul 1102, das die anderen Untermodule managt (einschließlich des DeviceODBC-Moduls 1004, des Device-Moduls 1110 und des HWaccess-Moduls 1116), um die durch die Schnittstellenfunktionen definierten Auf gaben zu vollenden, wie in 10 dargestellt. Insbesondere wird auf das Device-ODBC-Modul 1104 zugegriffen, um auf externe Vorrichtungsinformationen über die Standardschnittstelle zuzugreifen. Das HWaccess-Modul 1116 enthält Verkäuferinformationen, Modellinformationen, Informationen der eindeutigen ID und Statusinformationen von den überwachten Vorrichtungen unter Verwendung eines ausgewählten Kommunikationsprotokolls unter mehreren Kommunikationsprotokollen (z. B. HTTP, SNMP und FTP). Jedes der Überwachungssoftwaremodule wird nachstehend genauer beschrieben.
  • Das Folgende ist eine teilweise Auflistung und Beschreibung der Schnittstellen zwischen den vorstehend erörterten Überwachungsmodulen. Einige Module können beispielsweise "init"-Funktionen oder zusätzliche Funktionen aufweisen müssen, um die Informationen in zweckmäßigen Formaten zu erhalten.
  • void updateConfig(std::map<infoType, std::string> &)
  • Bevor diese Funktion aufgerufen wird, ist es bevorzugt, dass die Aufruffunktion die Verkäufer- und Modelleinträge nicht ersetzt, wenn die Erhaltungsfunktionen einen Nullstring zurückgeben. Diese Funktion aktualisiert die Vorrichtungsinformationsdatenbank des aktuellen Datensatzes in DeviceODBC 1104. Diese Funktion ist am effizientesten, wenn das nachstehende ObtainConfig anfänglich aufgerufen wird. Zuerst prüft diese Funktion, ob die IP-Adresse dieselbe in DeviceODBC 1104 ist. Wenn die IP-Adressen-Felder nicht gleich sind, wird der Datensatz mit der korrekten IP-Adresse von der Datenbank erhalten. Dann werden die anderen Felder kopiert und der Datensatz wird aktualisiert.
  • bool obtainConfig(std::map<infoType, std::string> &, std::map<std::string, std::vector<SParameter>> &)
  • Diese Funktion erhält die Abbildung von DeviceODBC 1104 für die Vorrichtungsinformationen im gegebenen Format und die Abbildung von Protokollen und zugeordneten Parametern. Die Funktion gibt wahr zurück, wenn Daten zurückgegeben werden, falsch wenn keine weiteren Daten vorhanden sind.
  • bool saveStatus(std::map<infoType, std::string> &)
  • Diese Funktion speichert die Statusinformationen in der DeviceODBC 1104. Die Funktion gibt wahr zurück, wenn das Speichern erfolgreich ist, ansonsten falsch.
  • CDevice*createDevice(const std::string & in_sIP, CHWaccess & in_HWaccess, std::map<std::string, std::vector<SParameter>> & in_ProtocolParameters)
  • Diese Funktion erzeugt die Vorrichtung auf der Basis von in_sIP und in_ProtocolParameters. Die erzeugte Vorrichtung wird über CHWaccess mit der Hardware verbunden. Wenn die Vorrichtung nicht erzeugt werden kann, gibt die Funktion 0 zurück. Daher sollte das aufrufende Objekt prüfen, ob der Rückgabeobjektzeiger 0 ist oder nicht.
  • bool canAccessHW(void)
  • Diese Funktion gibt wahr zurück, wenn auf die Hardware über das Netz zugegriffen werden kann, ansonsten falsch.
  • bool getVendor(std::string & out_sVendor)
  • Diese Funktion gibt den Verkäufernamen zurück. Wenn die Vorrichtung vom System nicht unterstützt wird, aber auf diese über eines der Protokolle zugegriffen werden kann, soll der String "ALLGEMEIN" enthalten. Wenn der Fehler im Prozess erfasst wird, gibt die Funktion falsch mit einem Nullstring zurück. Ansonsten gibt die Funktion wahr zurück.
  • bool getModel(std::string & out_sModel)
  • Diese Funktion erhält das Modell der Vorrichtung. Wenn das Modell erhalten wird, gibt die Funktion wahr zurück. Wenn der Fehler im Prozess erfasst wird, gibt die Funktion falsch mit einem Nullstring zurück.
  • bool getUniqueID(std::string & out_sUniqueID)
  • Diese Funktion gibt die eindeutige ID der Vorrichtung zurück. Wenn die eindeutige ID erhalten wird, gibt die Funktion wahr zurück. Wenn der Fehler im Prozess erfasst wird, gibt die Funktion falsch mit einem Nullstring zurück.
  • bool obtainStatus(map<infoType, std::string> & out StatusMap)
  • Diese Funktion gibt die Statusabbildung zurück. Die Funktion gibt wahr zurück, wenn der Status zurückgegeben wird, falsch, wenn der Status nicht erhalten werden konnte. Es ist zu beachten, dass diese Funktion die verschiedenen Abbildungen von den HWaccess- und Device-Modulen zurückgibt. Im Device-Modul werden Ereignisstatusinformationen zu der von HWaccess zurückgegebenen Abbildung hinzugefügt und werden gelöscht.
  • enum checkEventStatus(void)
  • Diese Funktion löst das Erhalten des Ereignisses der Netzvorrichtung aus. Der enum-Typ und Werte sollten in den Klassen definiert sein. Die enum-Werte sollten Werte eNoEventSinceClearAndNoEventDetected, eNoEventSinceClearAndEventDetected, eEventSinceClearAndNoEventDetected, eEventSinceClearAndEventDetected umfassen.
  • bool obtainEventStatus(std::mapinfoType, std::string> & out-EventStatusMap)
  • Diese Funktion erhält Ereignisstatusinformationen. Die Funktion gibt wahr zurück, wenn der Status zurückgegeben wird, falsch, wenn der Status nicht erhalten werden konnte.
  • void clearEventStatus(void)
  • Diese Funktion löscht den Ereignisstatus, der seit dem letzten obtainStatus-Funktionsaufruf oder clearEventStatus erhalten wurde.
  • void initBegin(void)
  • Diese Funktion startet den Initialisierungsprozess durch HWaccess, insbesondere um die Softwarevorrichtungsobjekte zu erzeugen.
  • void initEnd(void)
  • Diese Funktion beendet den Initialisierungsprozess durch HWaccess, was bedeutet, dass die Vorrichtungsobjekterzeugung beendet ist.
  • bool canAccessIP(const std::string & in_sIP, std::map<std::string, std::vector<SParameter>> & in_ProtocolParameters)
  • Diese Funktion gibt wahr zurück, wenn auf die Vorrichtung an der IP-Adresse zugegriffen werden kann, ansonsten falsch.
  • bool obtainVendor(std::string & out_sVendor, std::map<std::string, std::vector<SParameter>> & inOut_ProtocolParameters, const std::string & in_sIP)
  • Diese Funktion erhält den Verkäufer. Die Funktion gibt wahr zurück, wenn die Operation erfolgreich ist, ansonsten falsch mit dem leeren String. Während dieses Funktionsaufrufs werden die Protokolle untersucht, und wenn ein spezielles Protokoll für die Statusüberwachung nicht verwendet werden kann, soll das Protokoll aus den inOut_ProtocolParameters gelöscht werden.
  • bool obtainModel(std::string & out_sModelName, std::map<std::string, std::vector<SParameter>> & Out_ProtocolParameters, const std::string & in_sIP)
  • Diese Funktion erhält den Modellnamen. Die Funktion gibt wahr zurück, wenn die Operation erfolgreich ist, ansonsten falsch mit dem leeren String. Während dieses Funktionsaufrufs werden die Protokolle untersucht, und wenn ein spezielles Protokoll nicht für die Statusüberwachung verwendet werden kann, soll das Protokoll aus den inOut_ProtocolParameters gelöscht werden.
  • bool obtainUniqueID(std::string & out_sUniqueID, std::map<std::string, std::vector<SParameter>> & inOut_ProtocolParameters, const std::string in_sIP)
  • Diese Funktion erhält die eindeutige ID. Die Funktion gibt wahr zurück, wenn die Operation erfolgreich ist, ansonsten falsch mit dem leeren String. Während dieses Funktionsaufrufs werden die Protokolle untersucht, und wenn ein spezielles Protokoll nicht für die Statusüberwachung verwendet werden kann, soll das Protokoll aus den inOut_ProtocolParameters gelöscht werden.
  • EerrorCode obtainEventStatus(std::map<infoType, std::string> & out_StatusMap, const std::string & in_sIP, std::map<std::string, std::vector<SParameter>> & in_ProtocolParameters) Diese Funktion erhält den Ereignisstatus. Der EerrorCode ist nachstehend definiert.
  • 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)
  • Diese Funktion erhält den Status der Vorrichtung. Die Funktion gibt wahr zurück, wenn die Operation erfolgreich ist, ansonsten falsch mit der leeren Abbildung.
  • 12 zeigt die Datenstruktur, die vom HWaccess-Modul 1116 verwendet wird, wie in 11 dargestellt, um Informationen für das Abrufen von Werten auszutauschen, die Schlüsselwerten zugeordnet sind, die vom HWaccess-Modul 1116 empfangen werden. Die skeyValueInfo-Datenstruktur, wie in 12 gezeigt, wird beispielsweise verwendet, um zu bestimmen, wie Informationen, die einem speziellen Informationstyp (entsprechend m_infoType 1202) entsprechen, innerhalb einer gegebenen Webseite zu erhalten sind. Typischerweise verwenden eine Mehrzahl von Verkäufern verkäuferspezifische Identifizierer und eine verkäuferspezifische Nomenklatur, um Schlüsselinformationen zu identifizieren, die auf ihren jeweiligen Webseiten angezeigt werden, die mit einer überwachten Vorrichtung in Beziehung stehen. Um beispielsweise die Anzahl von Seiten, die von einer Druckervorrichtung gedruckt werden, zu bestimmen, verwendet ein Verkäufer das "Seitenzahl"-Merkmal, während ein anderer Verkäufer dieselbe unter Verwendung eines Merkmals "gelieferte gesamte Blätter identifiziert. Ein Merkmal der vorliegenden Erfindung besteht darin, die Varianzen von Verkäufer zu Verkäufer zu beseitigen und dadurch ein standardisiertes und einheitliches Verfahren zum Identifizieren von vorrichtungsspezifischen Informationen bereitzustellen und den Wert, der den Informationen entspricht, unter Verwendung einer Datenstruktur/SKeyValueInfo-Struktur 1200 zu extrahieren. Die SKeyValueInfo-Datenstruktur 1200 umfasst Attribute, die öffentlich sind.
  • SKeyValueInfo ist typischerweise eine Datenstruktur, die erzeugt wird, um Wertinformationen aus Informationen zu identifizieren, die von einer überwachten Vorrichtung in Form eines Datenstrings oder eines Schlüsselstrings empfangen werden. SKeyValueInfo umfasst mehrere Felder, wobei jedes Feld durch in 12 dargestellte Informationen dargestellt wird. Die SKeyValueInfo-Struktur 1200 umfasst ein m_sKey-Feld 1204, das einen Stringschlüssel darstellt, ein m_nPosition-Feld 1206, das vorzugsweise ein Wert auf Tag-Basis ist, der die Anzahl von Positionen im String angibt, in denen eine Wertinformation angeordnet sein könnte, und ein m_nIn_inePosition-Feld 1212. Die Seitenzahl einer Druckervorrichtung, die einer Überwachung unterliegt, kann beispielsweise in einer zweiten Position, die einem Schlüsselwort fort, gefunden werden. m_sType 1208 stellt den Typ von Informationen dar, die von einer angezeigten Webseite einer überwachten Vorrichtung abgerufen werden können.
  • Wenn der Wert, wie beispielsweise der Modellname der überwachten Vorrichtung, innerhalb derselben Datenzeile des Schlüssels (Produktname) zu finden ist, ist das m_nPositon-Feld "0". m_sDelimiter 1210 gibt einen speziellen Begrenzer an, der verwendet wird, um den dem Schlüssel zugeordneten Wert zu extrahieren. Die SKeyValueInfo-Datenstruktur gibt an, wie die Wertinformationen von Informationen zu extrahieren sind, die von einer überwachten Vorrichtung in einem HTML-Format empfangen werden.
  • 13 zeigt die Sequenz der init()-Funktion, um die Aufrufsequenz des Überwachungsmoduls 1006 zu beschreiben, wie in 10 dargestellt. Der MonitorManager 1102 intialisiert das HWaccess-Modul 1116, um die Initialisierungsfunktion zu starten. Anschließend erhält der MonitorManager 1102 Informationen über eine über wachte Vorrichtung und verwendet eine IP-Adresse, die der überwachten Vorrichtung zugewiesen ist, um mit der überwachten Vorrichtung zu kommunizieren. Der MonitorManager 1102 greift auf DeviceODBC 1104 zu, um Konfigurationsinformationen der überwachten Vorrichtung zu erhalten. Die zum MonitorManager 1102 zurückgegebenen Konfigurationsinformationen umfassen beispielsweise eine IP-Adresse der überwachten Vorrichtung, Parameternamen und zugehörige Werte für jedes Protokoll und Verkäufer/Hersteller- und Modellinformationen der überwachten Vorrichtung. Sobald die IP-Adresse erhalten ist, legt der MonitorManager 1102 die IP-Adresse, Parameternamen und zugehörigen Werte für jedes Protokoll fest, um ein Softwareobjekt auf der Basis der Klassenstruktur des Device-Moduls 1110 durch die CDeviceFactory-Klasse 1302 von 35 zu erzeugen. Wenn das Vorrichtungssoftwareobjekt erfolgreich erzeugt wird, wird das HWaccess-Modul 1116 verwendet, um den Verkäufer, das Modell und die eindeutige ID von der überwachten Vorrichtung zu erhalten, damit sie in dem erzeugten Vorrichtungssoftwareobjekt gespeichert werden.
  • Sobald der Verkäufer, die Modellinformationen und die eindeutige ID vom Vorrichtungssoftwareobjekt erhalten sind, aktualisiert der MonitorManager 1102 die Datenbank (beispielsweise DeviceODBC 1104) mit Informationen, die von der überwachten Vorrichtung empfangen werden. Obwohl 13 eine Vorrichtung zeigt, werden die Schritte von obtainConfig bis updateConfig wiederholt, um alle Vorrichtungen, die in der externen Quelle festgelegt sind, abzudecken. Außerdem wird jedes in 23, 24, 25 und 26 festgelegte Protokoll initialisiert. Auf die Datenbanktabellen, die ODBC in 24, 25 und 26 entsprechen, wird zugegriffen und erforderliche Informationen für Vorrichtungen, auf die zugegriffen wird, werden vom externen Speicher zur internen Datenstruktur übertragen, so dass die Statusinformationssammlung von den Vorrichtungen, auf die zugegriffen wird, schneller ist.
  • 14 zeigt die Sequenz der Statusüberwachungsfunktion, um den Status einer überwachten Vorrichtung durch das MonitorManager-Modul 1102 zu bestimmen, wie in 11 dargestellt. Wenn die obtainStatus-Funktion von Device an HWaccess ausgegeben wird, gibt die CHWaccess-Klasse wiederum einen obtainStatus-Funktionsaufruf an jedes in 23, 24, 25 und 26 beschriebene Protokoll durch die abstrakte Klasse mit verschiedenen Parametern aus, wie nachstehend beschrieben. Jedes Protokollmodul hat bereits Informationen im Cache gespeichert, die zum Extrahieren der Statusinformationen von den überwachten Vorrichtungen erforderlich sind, auf die bereits einmal während der in 13 beschriebenen Initialisierungszeit zugegriffen wurde. Daher können die Statusinformationen schnell von den überwach ten Vorrichtungen extrahiert werden, ohne während der Statusüberwachung auf die externe Quelle zuzugreifen. Dieser Prozess wird über alle überwachten Vorrichtungen, die im Vektor gespeichert sind, wiederholt, wie in 15 gezeigt.
  • Mit Bezug auf 15 ist ein Vektor 1500 mit Referenz auf die Vorrichtungen, der von CDeviceFactory 1302 von 35 erzeugt und vom MonitorManager 1102 verwendet wird, wie in 13 und 14 dargestellt, gezeigt. Der MonitorManager 1102 speichert Vorrichtungszeiger, wie beispielsweise einen Zeiger auf CDeviceObject 1502 und einen Zeiger auf CDevice Object 1504, die von CDeviceFactory 1302 von 35 erzeugt werden, im Vektor. Die Vektorsequenz wird iteriert, um den Status einer überwachten Vorrichtung zu erhalten. Das Abfragen von überwachten Vorrichtungen wird über das Vorrichtungsobjekt durch Ausgeben eines obtainStatus-Befehls durchgeführt. Sobald der Status von jedem der Softwareobjekte erhalten ist, wird ein solcher Status durch DeviceODBC 1104 aktualisiert. Die Statusüberwachungssequenz wurde vorstehend bei 14 beschrieben und wird hierin nicht wiederholt.
  • Die in Tabelle 1 gezeigte DeviceInfo-Struktur stellt die Informationen hinsichtlich einer überwachten Beispielvorrichtung dar. Die DeviceInfo-Struktur umfasst die E-Mail-Adresse der Kontaktperson zusätzlich zur Telephonnummer. Tabelle 1
    Typ Name Beschreibung
    std::string m_sVendor Ein String, der den Verkäufer, des Netzdruckers darstellt.
    std::string m_sModel Ein String, der das Modell des Netzdruckers darstellt.
    std::string m_sUniqueID Ein String, der die eindeutige ID des Netzdruckers darstellt. Diese ID kann eine Seriennummer oder MAC-Adresse oder irgendeine eindeutige ID, die vom Netzdrucker erhältlich ist, sein.
    std::string m_sIPAddress Ein String, der die IP-Adresse des Netzdruckers darstellt.
    std::string m_sCompanyName Ein String, der den Namen der Firma darstellt, die den Netzdrucker besitzt.
    std::string m_sStreet Ein String, der die Straßenadresse der Firma darstellt.
    std::string m_sCity Ein String, der die Stadt darstellt, in der sich die
    std::string m_sState Ein String, der den Staat darstellt, in dem sich die Firma befindet.
    std::string m_sZipCode Ein String, der die Postleitzahl der Firma darstellt.
    std::string m_sLocation Ein String, der den Ort des Netzdruckers innerhalb der Firma darstellt.
    std::string m_sContactPerson Ein String, der den Namen der Kontaktperson darstellt, die für den Netzdrucker verantwortlich ist.
    std::string m_sPhoneNumber Ein String, der die Telephonnummer der Kontaktperson darstellt.
    std::string m_sEMailAddress Ein String, der die E-Mail-Adresse der Kontaktperson darstellt.
  • Überwachungsdatenbank
  • 19 stellt die Organisation der Überwachungsdatenbank dar, die die Vorrichtungsinformationen für jede überwachte Vorrichtung umfasst (siehe auch Tabelle I). Wie in
  • 19 gezeigt, ist ein Satz von Parametern, ein Satz für jedes Kommunikationsprotokoll (z. B. SNMP, HTTP und FTP), den Vorrichtungsinformationen DeviceInfo 1902 für jede überwachte Vorrichtung zugeordnet. Überdies ist jeder Satz von Parametern für ein spezielles Protokoll (z. B. SNMP 1908, HTTP 1910 und FTP 1912) als Liste von Parameternamen- und Wertpaaren organisiert, z. B. sPar1Name und sPar1Wert. Es ist zu beachten, dass die Anzahl von Parametern für jedes Protokoll kürzer oder länger sein kann als die in 19 gezeigte Anzahl. Ein Benutzername und ein Passwort können beispielsweise als FTP-Parameter gespeichert werden, während ein Gemeinschaftsname und ein Passwort als SNMP-Parameter für eine gegebene überwachte Vorrichtung gespeichert werden können. Wie in 19 gezeigt, umfasst die Überwachungsdatenbank auch Informationen in Bezug auf DeviceHistory 1904 und EnumCorrespondence 1906.
  • 17 stellt die SParameter-Datenstruktur 1700 dar, die verwendet wird, um die von den verschiedenen Kommunikationsprotokollen verwendeten Parameter zu übergeben. SParameter umfasst zwei Felder: m_sParName 1702 und m_sParValue 1704, die den Namen bzw. Wert des Parameters darstellen.
  • 18 stellt die Abbildungsstruktur 1800 dar, die verwendet wird, um einen Vektor von Parametern für jedes Protokoll, der von der Überwachungsdatenbank erhalten wird, an ein Softwareobjekt zu übergeben, das jeder überwachten Vorrichtung zugeordnet ist. Die Abbildungsstruktur 1800 ordnet jedes Protokoll/Schlüssel-Feld 1802, 1804 und 1806 einem entsprechenden Vektor von Parametern 1808, 1810 bzw. 1812 zu, die gemäß dem in 17 gezeigten SParameter-Format angeordnet sind. Für das SNMP-Protokoll 1802 kann der Vektor von Parametern 1808 beispielsweise eine Liste von Parameternamen-, Parameterwertpaaren umfassen, die verwendet werden, um auf die überwachte Vorrichtung mit dem SNMP-Protokoll zuzugreifen. Die im Vektor 1808 gespeicherten SNMP-Parameternamen könnten beispielsweise "Gemeinschaftsname" und "Passwort" zusammen mit den entsprechenden Parameterwerten umfassen. Es ist jedoch zu beachten, dass die Organisation der Abbildungsstruktur 1800 eine beliebige Anzahl von Protokollen und zugeordneten Parametervektoren ermöglicht und nicht auf die in 18 gezeigten SNMP-, HTTP- und FTP-Protokolle begrenzt ist.
  • Unterstützungsdatenbank
  • 20–22 stellen die Organisation der Unterstützungsdatenbank 1024 dar, die in 10 gezeigt ist. Die Unterstützungsdatenbank, die Informationen umfasst, die erforderlich sind, um Statusinformationen von jeder überwachten Vorrichtung zu extrahieren, wird durch ein Kommunikationsprotokoll organisiert. 20, die die Organisation der Unterstützungsdatenbank für mit SNMP in Beziehung stehende Unterstützungsinformationen darstellt, die verwendet werden, um Informationen von einer überwachten Vorrichtung zu extrahieren, umfasst beispielsweise Datenstrukturen SNMPVendor 2002, SNMPComVendorStatus 2004, EnumCorrespondence 2006 und SNMPVendorModelStatus 2008. Eine gegebene Datenstruktur in der Unterstützungsdatenbank kann Parameter, die den Typ von zu extrahierenden Statusinformationen eindeutig identifizieren, zusammen mit Parametern, die die Extraktion steuern, umfassen. Die SNMPComVendorStatus-Datenstruktur 2004 umfasst beispielsweise ein nENUM-Feld 2009, das den Typ von zu extrahierenden Informationen (z. B. Tonerpegel) identifiziert, und ein nRelativePriority-Feld 2010, das das Gewicht oder die Bedeutung der extrahierten Informationen relativ zu anderen Protokollen angibt. Wenn dieselben Informationen von der überwachten Vorrichtung unter Verwendung von mehr als einem Protokoll extrahiert werden können, gibt folglich der nRelativePriority-Wert eine relative Angabe dessen, welcher extrahierte Wert welches Protokolls verwendet werden sollte. Wenn beispielsweise HTTP nur Informationen extrahieren kann, die angeben, ob der Tonerpegel "hoch" oder "niedrig" ist, während das SNMP-Protokoll den Prozentsatzpegel von restlichem Toner extrahieren kann, wäre das Prioritätsniveau für den Tonerpegel für SNMP höher als der entsprechende Wert für HTTP. Außerdem kann die Unterstützungsdatenbank Vorgabeprioritätswerte für ein ganzes Protokoll vorsehen. In einer Ausführungsform wird dem SNMP-Protokoll ein Prioritätswert von 10000 in einem System gegeben, in dem Protokollwerte im Bereich von 0 bis 32000 liegen können.
  • 21 und 22 stellen die Datenstrukturen dar, die in den HTTP- und FTP-Abschnitten der Unterstützungsdatenbank 1024 enthalten sind, und umfassen Datenstrukturen, die zu den vorstehend mit Bezug auf 20 beschriebenen Datenstrukturen analog sind.
  • Beispielhafte enum-Typen, die von der vorliegenden Erfindung verwendet werden, ist der nachstehend definierte infoType. (Die enum-Typen sind nur beispielhaft und sollten daher nicht als Begrenzung der vorliegenden Erfindung aufgefasst werden.)
  • infoType(typedef int info Type)
  • Dieser Abschnitt beschreibt die Definition des infoType (int). Der Wertebereich 0 bis 99 ist dem Datentyp zugewiesen. Der Wertebereich 100 bis 499 ist den Vorrichtungsinformationen zugewiesen. Der Wertebereich 500 bis 1999 ist den allgemeinen Parametern, einschließlich Standard-MIB-Parametern, zugewiesen. Der Bereich 2000 bis 3999 ist Ricoh-spezifischen Informationen zugewiesen. Der Bereich 4000 bis 4999 ist dem Verkäufer 1 zugewiesen. Der Bereich 5000 bis 5999 ist dem Verkäufer 2 zugewiesen. Der Bereich 6000 bis 6999 ist dem Verkäufer 3 zugewiesen. Die Werte sind wie folgt definiert:
    • infoType {eNotDefine = 0, eDeviceInformation = 1, eStatusInformation = 2, eVendor = 100, eModel, eUniqueID, eIPAddress, eCompanyName, eStreet, eCity, eState, eZipCode, eLocation, eContactPerson, ePhoneNumber, eEMailAddress, eDateTime = 500, eHrDeviceErrors, eLowPaper, eNoPaper, eLowToner, eNoToner, eDoorOpen, eJammed, eOffline, eServiceRequested, ePrtGeneralConfigChanges = 600, ePrtLifeCount, ePrtAlertDesc1, ePrtAlertDesc2, ePrtAlertDesc3, ePrtAlertDesc4, ePrtAlertDesc5, eBlack = 700, eMagenta, eCyan, eVellow, eTonerCollector = 800, eBlack-Developer = 810, eColorDeveloper, eFuser = 820, eDrum = 830, eTransfer = 840, eMaintenanceKit = 850, eOilKit = 860, eStationInfo1 = 901, eStationInfo2, eStationInfo3, eStationInfo4, eStationInfo5, eRicohEngineCounterTotal = 2000, eRicohEngineCounter-Printer, eRicohEngineCounterFax, eRicohEngineCounterCopier}.
  • EerrorCode
  • Die folgenden Codes sind lediglich beispielhaft und mehr Codes können zum existierenden Satz hinzugefügt werden. Der Bereich 0–99 ist reserviert. Der Bereich 100–199 ist für SMTP, 200–299 ist für POP3, 300–399 ist für Socket und 400–499 ist für HTTP und 500–599 ist für FTP. Andere Bereiche, die nicht festgelegt sind, können von einem Benutzer definiert werden, falls erforderlich.
    • enum EerrorCode (eNoError = 0, eUnknownError = 1, eSomeError, eCompleteFailure, eSomeDeviceCreationError = 20, eCreateDeviceError, eNoDeviceCreated, eObtainConfigError, eSaveStatusError, eObtainUniqueIDError, eObtainStatusError, eStartSendErorr, eSomeDataSendError, eCompleteDataSendFailure, eEndSendError, eSendHeloCommandFailed = 100, eSendMailCommandFailed, eSendRcptCommandFailed, eSendDataCommandFailed, eSendDataFailed, eSendQuitCommandFailed, eSendUserCommandFailed = 200, eSendPassCommandFailed, eSendStatCommandFailed, eSendRetrCommandFailed, eSendDeleCommandFailed, eSendQuitPop3CommandFailed, eCreateSocketFailed = 300, eConnectSocketFailed, eBadRequest = 400, eUnauthorized, ePaymentRequired, eForbidden, eNotFound, eMethodNotAllowed, eNotAcceptable, eProxyAuthenticationRequired, eRequestTimeOut, eConflict, eGone, eLengthRequired, ePreconditionFailed, eRequestEntityTooLarge, eRequestURITooLarge, eUnsupportedMediaType, eRequestedRangeNotSatisfiable, eExpectationFailed, elnternalServerError = 450, eNotImplemented, eBadGateway, eServiceUnavailable, eGatewayTimeOut, eHTTPVersionNotSupported, eMultipleChoices = 480, eMovedPermanently, eFound, eSeeOther, eNotModified, eUseProxy, eTemporaryRedirect).
  • Abstrakte Klassen im DeviceODBC-Modul
  • 16 stellt die DeviceODBC-Modul-Klassenstruktur gemäß der vorliegenden Erfindung dar und zeigt, wie die CAbsProtocolParameters-Klassenstruktur innerhalb des DeviceODBC-Moduls verwendet wird. Die CAbsProtocolParameters-Klasse ist dazu ausgelegt, mit der Überwachungsdatenbank 1014 eine Schnittstelle zu bilden und Informationen zum Zugreifen auf die überwachten Vorrichtungen unter Verwendung eines speziellen Kommunikationsprotokolls zu erhalten. Die CAbsProtocolParameters-Klasse besitzt zwei virtuelle Funktionen, die vom Protokoll abhängen:
    • (1) std::string obtainProtocolName(void); und
    • (2) bool obtainParameterVector(std::vector<SParameter> & out_ParameterVector, const std::string in_sIP).
  • Unter Verwendung dieser Funktionen kann die CDeviceODBC-Klasse so viele Protokolle und ihre zugehörigen Parameternamen und Werte durch den Zeiger auf den CAbsProtocolParameter-Typ handhaben, ohne das Protokoll zu identifizieren. Die erhaltenen Informationen für jede Vorrichtung (z. B. IP-Adresse) werden in der Datenstruktur von 18 gespeichert und zum MonitorManager-Modul 1102 durch die obtainConfig-Funktion geleitet. Aus der CDeviceODBC-Perspektive werden alle Objekte, die verwendet werden, um den Protokollnamen und die zugehörigen Parameternamen und Werte zu erhalten, als Typ von CAbsProtocol-Parametern betrachtet. Wenn ein neues Protokoll hinzugefügt wird, sollte daher das neue Objekt erzeugt und im Vektor von Zeigern auf die CAbsProtocolParameters-Klasse gespeichert werden. Die anderen Funktionen müssen nicht geändert werden.
  • Abstrakte Klassen im HWaccess-Modul
  • 23 zeigt das Paketdiagramm für das HWaccess-Paket. Dieses Paket ist für das Identifizieren der zu überwachenden Netzvorrichtungen und für das Erhalten von Informationen über die Netzvorrichtungen unter Verwendung von verschiedenen Netzprotokollen (z. B. SNMP, HTTP und FTP) verantwortlich. Das Paket enthält die Pakete HTTP 2302, SNMP 2304 und FTP 2306 und die Klassen CHWaccess 2300, CAbsProtocol 2308 und CRecordSet 2310. Die Pakete HTTP 2302, SNMP 2304 und FTP 2306 implementieren die Netzprotokolle zum Zugreifen auf die Netzvorrichtungen, um Informationen von ihnen zu erhalten. Das HTTP-Paket 2302 implementiert beispielsweise das HTTP-Protokoll, um auf Webseiten der Netzvorrichtungen zuzugreifen, um Informationen von den Webseiten zu erhalten. Die Klasse CHWaccess 2300 managt alle Protokollpakete, um die erforderlichen Informationen von den Netzvorrichtungen zu erhalten. Die Klasse CAbsProtocol 2308 ist eine abstrakte Klasse, die irgendein Protokoll darstellt. Diese Klasse stellt die Schnittstelle zwischen CHWaccess 2300 und den Protokollpaketen bereit. Die Klasse CAbsProtocol 2308 stellt einen Satz von gemeinsamen Funktionen, wie in 23 gezeigt, für CHWaccess 2300 bereit, wobei alle Protokolle für CHWaccess 2300 die erforderlichen Informationen bereitstellen. Die von CAbsProtocol 2308 abgeleiteten Klassen, wie in späteren Fig. beschrieben, stellen das Verfahren für jede der Funktionen für die geeigneten Protokolle bereit. Die Klasse CRecordSet 2310 ist eine Klasse der Microsoft Foundation Class, die jedem Protokollpaket Zugriff auf die Datenbank gewährt, um Informationen darüber, welcher Verkäufer und welches Modell von Netzvorrichtun gen unterstützt werden und welche Informationen von diesen Netzvorrichtungen zu erhalten sind, zu erhalten.
  • 24 zeigt das Paketdiagramm für eine erste Ausführungsform des SNMP-Pakets 2304. Es ist zu beachten, dass viele der in 24 gezeigten Komponenten in die zweite Ausführungsform des SNMP-Pakets, das in 63 gezeigt ist, integriert sind. Diese Paket ist für das Bestimmen des Verkäufers und Modells von Netzvorrichtungen, die vom SNMP-Protokoll unterstützt werden, und der von den Netzvorrichtungen durch das SNMP-Protokoll zu erhaltenden Informationen und zum Zugreifen auf die Netzvorrichtung durch das SNMP-Protokoll, um Informationen von den Netzvorrichtungen zu erhalten, verantwortlich. Das Paket enthält die Pakete SNMPaccess 2404 und SNMPODBC 2406 und die Klasse CSNMPProtocol 2402 und verwendet die Klassen CAbsProtocol 2400 und CRecordSet 2408, wie in 23 beschrieben. Das SNMPaccess-Paket 2404 implementiert das SNMP-Protokoll, um auf die Netzvorrichtungen zuzugreifen und um Informationen von den Netzvorrichtungen zu erhalten. Das SNMPODBC-Paket 2406 greift auf Informationen von der Datenbank über den Verkäufer und das Modell von Netzvorrichtungen, die vom SNMP-Protokoll unterstützt werden, und die von den Netzvorrichtungen durch das SNMP-Protokoll zu erhaltenden Informationen zu und erhält diese. Die CSNMPProtocol-Klasse 2402 ist eine Klasse, die von der CAbsProtocol-Klasse 2400 abgeleitet ist. CSNMPProtocol 2402 erhält die erforderlichen Informationen von den Netzvorrichtungen unter Verwendung des SNMP-Protokolls. CSNMPProtocol 2402 stellt das Verfahren für alle Schnittstellenfunktionen von CAbsProtocol 2400 bereit, wie in 23 beschrieben. 24 zeigt auch die Funktionen der Pakete SNMPaccess 2404 und SNMPODBC 2406, die CSNMPProtocol 2402 verwendet. Das SNMPODBC-Paket 2406 verwendet die Klasse CRecordSet 2408, um Informationen von der Datenbank zu erhalten.
  • 25 zeigt das Paketdiagramm für eine erste Ausführungsform des HTTP-Pakets 2302. Es ist zu beachten, dass viele der in 25 gezeigten Komponenten in die zweite Ausführungsform des HTTP-Pakets, das in 41 gezeigt ist, integriert sind. Dieses Paket ist für das Bestimmen des Verkäufers und Modells von Netzvorrichtungen, die vom HTTP-Protokoll unterstützt werden, und der von den Netzvorrichtungen durch das HTTP-Protokoll zu erhaltenden Informationen und zum Zugreifen auf die Netzvorrichtungen durch das HTTP-Protokoll, um Informationen von den Netzvorrichtungen zu erhalten, verantwortlich. Das Paket enthält die Pakete HTTPaccess 2504 und HTTPODBC 2506 und die Klasse CHTTPProtocol 2502 und verwendet die Klassen CAbsProtocol 2500 und CRecordSet 2508, wie in 23 beschrieben. Das HTTPaccess-Paket 2504 implementiert das HTTP-Protokoll, um auf die Netzvorrich tungen zuzugreifen und um Informationen von den Netzvorrichtungen zu erhalten. Das HTTPODBC-Paket 2506 greift auf Informationen von der Datenbank über den Verkäufer und das Modell von Netzvorrichtungen, die vom HTTP-Protokoll unterstützt werden, und die von den Netzvorrichtungen durch das HTTP-Protokoll zu erhaltenden Informationen zu und erhält diese. Die CHTTPProtocol-Klasse 2502 ist eine Klasse, die von der CAbsProtocol-Klasse 2500 abgeleitet ist. CHTTPProtocol 2502 erhält die erforderlichen Informationen von den Netzvorrichtungen unter Verwendung des HTTP-Protokolls. CHTTPProtocol 2502 stellt das Verfahren für alle Schnittstellenfunktionen von CAbsProtocol 2500 bereit, wie in 23 beschrieben. 25 zeigt auch die Funktionen der Pakete HTTPaccess 2504 und HTTPODBC 2506, die das CHTTPProtocol 2502 verwendet. Das HTTPODBC-Paket 2506 verwendet die Klasse CRecordSet 2508, um Informationen von der Datenbank zu erhalten.
  • 26 zeigt das Paketdiagramm für das FTP-Paket 2306. Dieses Paket ist für das Bestimmen des Verkäufers und Modells von Netzvorrichtungen, die vom FTP-Protokoll unterstützt werden, und der von den Netzvorrichtungen durch das FTP-Protokoll zu erhaltenden Informationen und zum Zugreifen auf die Netzvorrichtungen durch das FTP-Protokoll, um Informationen von den Netzvorrichtungen zu erhalten, verantwortlich. Das Paket enthält die Pakete FTPaccess 2604 und FTPODBC 2606 und die Klasse CFTPProtocol 2602 und verwendet die Klassen CAbsProtocol 2600 und CRecordSet 2608, wie in 23 beschrieben. Das FTPaccess-Paket 2604 implementiert das FTP-Protokoll, um auf die Netzvorrichtungen zuzugreifen und um Informationen von den Netzvorrichtungen zu erhalten. Das FTPODBC-Paket 2606 greift auf Informationen von der Datenbank über den Verkäufer und das Modell von Netzvorrichtungen, die vom FTP-Protokoll unterstützt werden, und die von den Netzvorrichtungen durch das FTP-Protokoll zu erhaltenden Informationen zu und erhält diese. Die CFTPProtocol-Klasse 2602 ist eine Klasse, die von der CAbsProtocol-Klasse 2600 abgeleitet ist. CFTPProtocol 2602 erhält die erforderlichen Informationen von den Netzvorrichtungen unter Verwendung des FTP-Protokolls. CFTPProtocol 2602 stellt das Verfahren für alle Schnittstellenfunktionen von CAbsProtocol 2600 bereit, wie in 23 beschrieben. 26 zeigt auch die Funktionen der Pakete FTPaccess 2604 und FTPODBC 2606, die CFTPProtocol 2602 verwendet. Das FTPODBC-Paket 2606 verwendet die Klasse CRecordSet 2608, um Informationen von der Datenbank zu erhalten.
  • Jedes der Protokollpakete HTTP 2302, SNMP 2304 und FTP 2306, wie in 23 bis 26 beschrieben, enthält eine Klasse, die den Zugriff auf die Netzvorrichtung managt, um Informationen von der Vorrichtung zu erhalten. Die Klasse wird von der abstrakten Klasse CAbsProtocol 2308 abgeleitet, die das Verfahren zum Implementieren der Protokolle zum Zugreifen auf Informationen von der Netzvorrichtung bereitstellt. Eine abstrakte Klasse stellt nur die Schnittstellenfunktionen bereit, aber führt irgendeinen Prozess durch. Die von der abstrakten Klasse abgeleiteten Klassen sehen das Verfahren zum Durchführen des Prozesses für die Schnittstellenfunktionen vor. Es können viele abgeleitete Klassen der abstrakten Klasse vorhanden sein, so dass die verschiedenen abgeleiteten Klassen den Prozess der Schnittstellenfunktion unterschiedlich durchführen können. Eine Schnittstellenfunktion von CAbsProtocol ist beispielsweise obtainStatus(). Die abgeleitete Klasse CSNMPProtocol 2402 enthält die Funktion obtainStatus(), die das Verfahren zum Erhalten der Statusinformationen einer Netzvorrichtung unter Verwendung von SNMP bereitstellt, während die abgeleitete Klasse CHTTPProtocol 2502 die Funktion obtainStatus() enthält, die das Verfahren zum Erhalten der Statusinformationen einer Netzvorrichtung unter Verwendung von HTTP bereitstellt. Aus der Konstruktion des HWaccess-Pakets kann ein neues Protokoll zum System hinzugefügt werden, indem ein neues Paket hinzugefügt wird, das eine abgeleitete Klasse von CAbsProtocol enthält, das das neue Paket managt, um auf die Netzvorrichtung unter Verwendung des neuen Protokolls zuzugreifen. Die abstrakte Klasse ermöglicht die Merkmalserweiterung des Systems.
  • 27A–27D zeigen die Datenstrukturen, die im HWaccess-Paket von 23 verwendet werden, um alle Protokolle zum Zugreifen auf und Erhalten von Informationen von den Netzvorrichtungen zu verwalten. In 27A ist die Datenstruktur ein Vektor 500 von Zeigern auf CAbsProtocol 2308. Die Klasse CHWaccess 2300 enthält und verwendet diese Datenstruktur. Selbst wenn der Vektor 500 Zeiger auf Klassen enthält, die von CAbsProtocol 2308 abgeleitet sind, sieht CHWaccess 2300 den Vektor als Zeiger auf CAbsProtocol 2308 enthaltend und ruft die Schnittstellenfunktionen von CAbsProtocol 2308 durch den virtuellen Funktionsaufrufmechanismus auf. Tatsächlich ruft CHWaccess 2300 die Schnittstellenfunktionen der abgeleiteten Klassen von CAbsProtocol 2308 auf. Der Zeiger auf CAbsProtocol 502 im ersten Eintrag im Vektor kann beispielsweise ein Zeiger auf die abgeleitete Klasse CSNMPProtocol 2402 sein, der Zeiger auf CAbsProtocol 504 im zweiten Eintrag des Vektors kann ein Zeiger auf die abgeleitete Klasse CHTTPProtocol 2502 sein und der Zeiger auf CAbsProtocol 506 im dritten Eintrag im Vektor kann ein Zeiger auf die abgeleitete Klasse CFTPProtocol 2602 sein. Wenn CHWaccess 2300 die Schnittstellenfunktionen von CAbsProtocol 2308 im Vektor aufruft, ruft es somit tatsächlich die Schnittstellenfunktionen von CSNMPProtocol 2402, CHTTPProtocol 2502 und CFTPProtocol 2602 auf. Die Verwendung der abstrakten Klasse CAbsProtocol 2308 im Vektor 500 ermöglicht, dass irgendein Protokoll verwendet wird, um auf Informationen von den Netzvorrichtungen zuzugreifen und diese zu erhalten. Die abstrakte Klasse CAbsProtocol 2308 verbirgt das Detail dessen, welches Protokoll verwendet wird.
  • 27B zeigt die Datenstruktur, die von CSNMPProtocol verwendet wird, um Informationen über den Verkäufer und das Modell von Netzvorrichtungen, die durch SNMP überwacht werden, und Informationen, die verwendet werden, um Statusinformationen von ihnen zu erhalten, zu verwalten. Die Datenstruktur ist eine Abbildung 510. Der Schlüssel für die Abbildung 510 ist ein String 512, der den Verkäufernamen der Netzvorrichtung darstellt. Der Wert für die Abbildung 510 ist eine weitere Abbildung 514. Der Schlüssel für die Abbildung 514 ist ein String 516, der den Modellnamen der Netzvorrichtung darstellt. Der Wert für die Abbildung 514 ist ein Vektor 518 von Paaren. Die Paare enthalten die Struktur SOIDinfoType und eine ganze Zahl. Die Struktur SOIDinfoType enthält Informationen, die verwendet werden, um eine einzelne Statusinformation von der Netzvorrichtung unter Verwendung von SNMP zu erhalten. Daher enthält der Vektor 518 von Paaren Informationen, um alle Statusinformationen für die Netzvorrichtung für einen speziellen Verkäufer und ein spezielles Modell zu erhalten. Die Abbildung 510 wird mit Informationen unter Verwendung des in 28 beschriebenen Prozesses initialisiert. Die Abbildung 510 zeigt Mustereinträge für den String 512 für den Verkäufer und den String 516 für das Modell.
  • 27C zeigt die Datenstruktur, die von CHTTPProtocol verwendet wird, um Informationen über den Verkäufer und das Modell von Netzvorrichtungen, die durch HTTP überwacht werden, und der Informationen, die verwendet werden, um Statusinformationen von ihnen zu erhalten, zu verwalten. Die Datenstruktur ist eine Abbildung 520. Der Schlüssel für die Abbildung 520 ist ein String 522, der den Verkäufernamen der Netzvorrichtung darstellt. Der Wert für die Abbildung 520 ist eine weitere Abbildung 524. Der Schlüssel für die Abbildung 524 ist ein String 526, der den Modellnamen der Netzvorrichtung darstellt. Der Wert für die Abbildung 524 ist ein Vektor 528 von SWebPageInfo. Die Struktur SWebPageInfo enthält Informationen, die verwendet werden, um alle Statusinformationen von einer Webseite der Netzvorrichtung unter Verwendung von HTTP zu erhalten. Daher enthält der Vektor 528 von SWeb-PageInfo Informationen, um alle Statusinformationen für die Netzvorrichtung für einen speziellen Verkäufer und ein spezielles Modell von allen ihren Webseiten zu erhalten. Die Abbildung 520 wird mit Informationen unter Verwendung des in 28 beschriebenen Prozesses initialisiert. Die Abbildung 520 zeigt Mustereinträge für den String 522 für den Verkäufer und den String 526 für das Modell.
  • 27D zeigt die Datenstruktur, die von CFTTPProtocol verwendet wird, um Informationen über den Verkäufer und das Modell von Netzvorrichtungen, die von FTP überwacht werden, und die Informationen, die verwendet werden, um Statusinformationen von ihnen zu erhalten, zu verwalten. Die Datenstruktur ist eine Abbildung 530. Der Schlüssel für die Abbildung 530 ist ein String 532, der den Verkäufernamen der Netzvorrichtung darstellt. Der Wert für die Abbildung 530 ist eine weitere Abbildung 534. Der Schlüssel für die Abbildung 534 ist ein String 536, der den Modellnamen der Netzvorrichtung darstellt. Der Wert für die Abbildung 534 ist ein Vektor 538 von SDirFileStatusInfo. Die Struktur SDirFileStatusInfo enthält Informationen, die verwendet werden, um alle Statusinformationen von einer FTP-Datei der Netzvorrichtung unter Verwendung von FTP zu erhalten. Daher enthält der Vektor 538 von SDirFileStatusInfo Informationen, die verwendet werden, um alle Statusinformationen für die Netzvorrichtung für einen speziellen Verkäufer und ein spezielles Modell von allen ihren FTP-Dateien zu erhalten. Die Abbildung 530 wird mit Informationen unter Verwendung des in 28 beschriebenen Prozesses initialisiert. Die Abbildung 530 zeigt Mustereinträge für den String 532 für den Verkäufer und den String 536 für das Modell.
  • 28 zeigt einen Ablaufplan, der den Prozess der Initialisierung aller Protokollobjekte mit Informationen über den Verkäufer einer durch das System überwachten Netzvorrichtung beschreibt. Ein ähnlicher Prozess wird für die Initialisierung aller Protokollobjekte mit Informationen über das Modell einer durch das System überwachten Netzvorrichtung verwendet. Für eine überwachte gegebene Netzvorrichtung können der Verkäufer und das Modell der Netzvorrichtung bekannt sein müssen, um festzustellen, welche Informationen von der Netzvorrichtung erhalten werden müssen. Jedes zum Zugreifen auf und Erhalten von Informationen von der Netzvorrichtung verwendete Protokollobjekt kann den Verkäufer und das Modell kennen müssen, um festzustellen, welche Informationen und wie die Informationen von der Netzvorrichtung zu erhalten sind. Die Protokollobjekte, die eine Initialisierung erfordern, sind jene, die den Klassen entsprechen, die von CAbsProtocol 2308 abgeleitet sind, die CSNMPProtocol, CHTTPProtocol und CFTPProtocol sind. Die Initialisierung des Protokollobjekts beinhaltet das Hinzufügen von Informationen zu den in 27B, 27C und 27D beschriebenen Datenstrukturen, die den Protokollen entsprechen. Die Konstruktion des Systems zeigt, dass Informationen, die zu den Datenstrukturen von 27B, 27C und 27D hinzugefügt werden, von einer Datenbank stammen, aber sie können von anderen externen Quellen wie z. B. einer Textdatei oder einer Tabellenkalkulation stammen. Der Vektor von Zeigern auf CAbsProtocol 2308, der in 27A beschrieben ist, wird verwendet, um alle Protokollobjekte zu initialisieren. Der Prozess des Ablaufplans durchschreitet den Vektor zweimal. Das erste Mal, wenn er den Vektor durchschreitet, werden die Protokollobjekte verwendet, um den Verkäufer der Netzvorrichtung zu finden. Wenn der Verkäufername von einem der Protokollobjekte erhalten wird, werden alle Protokollobjekte mit dem Verkäufernamen initialisiert, wenn der Vektor ein zweites Mal durchschritten wird. In Schritt 602 wird ein Protokollobjekt vom Vektor von Zeigern auf CAbsProtocol erhalten. Das Protokollobjekt entspricht einem der Protokolle zum Zugreifen auf die Netzvorrichtung (z. B. SNMP, HTTP und FTP). In Schritt 604 wird eine Prüfung durchgeführt, um festzustellen, ob weitere Protokollobjekte vorliegen, die vom Vektor erhalten werden können. Diese Prüfung wird durch Feststellen, ob das Ende des Vektors erreicht wurde, durchgeführt. Wenn keine weiteren Protokollobjekte erhalten werden können, dann misslingt es dem System, den Verkäufernamen der Netzvorrichtung zu erhalten. Allen Protokollobjekten ist es misslungen, den Verkäufernamen zu erhalten, und die Initialisierung der Protokollobjekte für die Netzvorrichtung wird in Schritt 606 vollendet. Wenn ein Protokollobjekt vom Vektor erhalten wird, dann wird das Protokollobjekt verwendet, um den Verkäufernamen der Netzvorrichtung in Schritt 608 zu erhalten. In Schritt 610 wird eine Prüfung durchgeführt, um festzustellen, ob das Protokollobjekt den Verkäufernamen der Netzvorrichtung erhalten kann. Die Protokollobjekte erhalten Informationen von der Datenbank, die zum Bestimmen des Verkäufers der Netzvorrichtung verwendet werden. Wenn der Verkäufername nicht vom Protokollobjekt erhalten werden kann, dann versucht der Prozess, den Verkäufernamen unter Verwendung eines anderen Protokollobjekts in dem Vektor zu erhalten, indem er zu Schritt 602 zurückgeht. Wenn der Verkäufername vom Protokollobjekt erhalten werden kann, dann initialisiert der Prozess das Protokollobjekt mit dem Verkäufernamen in Schritt 612. Das Protokollobjekt wird mit Informationen darüber initialisiert, wie Statusinformationen von der Netzvorrichtung des erhaltenen Verkäufernamens zu erhalten sind. Informationen werden zu den Datenstrukturen hinzugefügt, wie in 27B, 27C und 27D beschrieben. In Schritt 614 wird ein Protokollobjekt vom Vektor von Zeigern auf CAbsProtocol erhalten. In Schritt 616 wird eine Prüfung durchgeführt, um festzustellen, ob weitere Protokollobjekte vorhanden sind, die vom Vektor erhalten werden können. Wenn keine weiteren Protokollobjekte erhalten werden können, dann wurden alle Protokollobjekte mit dem Verkäufernamen initialisiert und die Initialisierung aller Protokollobjekte ist in Schritt 606 vollständig. Alle Protokollobjekte besitzen aktualisierte Informationen über den Verkäufer. Wenn ein Protokollobjekt vorhanden ist, das vom Vektor erhalten wird, dann wird das Protokollobjekt mit dem Verkäufernamen in Schritt 618 initialisiert. Genau wie in Schritt 612 wird das Protokollobjekt mit Informationen darüber initialisiert, wie Statusinformationen von der Netzvorrichtung des erhaltenen Verkäufernamens zu erhalten sind. Nach der Initialisierung des Protokollobjekts mit dem Verkäufernamen initialisiert der Prozess ein anderes Protokollobjekt mit dem Verkäufernamen, indem er zu Schritt 614 zurückgeht.
  • In Schritt 608 von 28 erhält das Protokollobjekt den Verkäufernamen der Netzvorrichtung. Die SNMP-, HTTP- und FTP-Protokollobjekte können auf die Netzvorrichtung zugreifen, um den Verkäufernamen zu erhalten. Informationen darüber, wo der Verkäufername gefunden werden kann, werden von der Datenbank erhalten. Zusammen mit den Informationen über den Verkäufer der Netzvorrichtung, die von einem Protokoll unterstützt wird, liefert die Datenbank die Informationen, um den Verkäufernamen einer Netzvorrichtung aufzufinden. Für SNMP werden Informationen über den Unternehmensobjektidentifizierer, der einem Verkäufernamen zugeordnet ist, und den Objektidentifizierer, der verwendet wird, um den Unternehmensobjektidentifizierer innerhalb der MIB einer Netzvorrichtung aufzufinden, vom SNMP-Protokollobjekt verwendet, um den Verkäufernamen zu erhalten. Für HTTP werden Informationen über die Webseiten und den Ort innerhalb der Webseiten vom HTTP-Protokollobjekt verwendet, um den Verkäufernamen zu erhalten. Für FTP werden Informationen über die FTP-Dateien und den Ort innerhalb der FTP-Dateien vom FTP-Protokollobjekt verwendet, um den Verkäufernamen zu erhalten.
  • 29A–29D zeigen die verschiedenen Datenstrukturen, die verwendet werden, um die Statusinformationen einer Netzvorrichtung eines speziellen Verkäufers und Modells für die verschiedenen Protokolle zu erhalten. Verschiedene Protokolle können verwendet werden, um dieselben Statusinformationen zu erhalten. Die von einem Protokoll erhaltenen Statusinformationen können jedoch mehr Informationen als ein anderes bereitstellen, so dass die Statusinformationen, die von dem Protokoll erhalten werden, das mehr Informationen bereitstellt, verwendet werden sollten. Der Tonerpegel einer Druckerkassette kann beispielsweise von einem Netzdrucker unter Verwendung von SNMP und HTTP erhalten werden. Die Statusinformationen für den Tonerpegel, die von SNMP erhalten werden, können "VOLL", "OK" oder "LEER" sein, während dieselben Statusinformationen, die von HTTP erhalten werden, der Prozentsatz des restlichen Toners sein können. In diesem Beispiel sind die unter Verwendung von HTTP erhaltenen Statusinformationen informativer, so dass die von HTTP erhaltenen Statusinformationen verwendet werden sollten. Die Datenstrukturen von 29A bis 29D stellen sicher, dass die informativsten Statusinformationen erhalten werden. 29A zeigt die Datenstruktur, die verwendet wird, um die Statusinformationen für eine Netzvorrichtung eines speziellen Verkäufers und Modells unter Verwendung des SNMP-Protokolls zu erhalten. Die Datenstruktur ist ein Vektor 700 von Paaren (z. B. 702 und 704), wobei die Paare aus der Struktur SOIDinfoType 706 und einer ganzen Zahl bestehen. Die Struktur SOIDinfoType 706 enthält Informationen, die verwendet werden, um spezielle Statusinformationen von der Netzvorrichtung unter Verwendung von SNMP zu erhalten. Die Struktur von SOIDinfoType 706 ist in 29A gezeigt. Die ganze Zahl in dem Paar bestimmt das Gewicht oder die Priorität der Statusinformationen. Je größer der Wert für die ganze Zahl ist, desto wahrscheinlicher werden die erhaltenen Statusinformationen behalten, da sie informativer sind. Je niedriger der Wert für die ganze Zahl ist, desto wahrscheinlicher werden dieselben Statusinformationen, die von anderen Protokollen erhalten werden, behalten. CSNMPProtocol 2402 verwendet den Vektor 700, um zu bestimmen, welche Statusinformationen von der Netzvorrichtung zu erhalten sind. Die in den Vektor 700 gesetzten Informationen werden von der Datenstruktur in 27B für einen speziellen Verkäufer und ein spezielles Modell erhalten.
  • 29B zeigt die Datenstruktur, die verwendet wird, um die Statusinformationen für eine Netzvorrichtung eines speziellen Verkäufers und Modells unter Verwendung des HTTP-Protokolls zu erhalten. Die Datenstruktur ist ein Vektor 708 von Paaren (z. B. 710 und 712), wobei die Paare aus der Struktur SkeyValueInfo 714 und einer ganzen Zahl bestehen. Die Struktur SkeyValueInfo 714 enthält Informationen, die verwendet werden, um spezielle Statusinformationen von einer Webseite einer Netzvorrichtung unter Verwendung von HTTP zu erhalten. Die Struktur von SkeyValueInfo 714 ist in 29B gezeigt. Die ganze Zahl in dem Paar bestimmt das Gewicht oder die Priorität der Statusinformationen. CHTTPProtocol 2502 verwendet den Vektor 708, um zu bestimmen, welche Statusinformationen von der Netzvorrichtung zu erhalten sind. Die in den Vektor 708 gesetzten Informationen werden von der Datenstruktur in 27C für einen speziellen Verkäufer und ein spezielles Modell erhalten.
  • 29C zeigt die Datenstruktur, die verwendet wird, um die Statusinformationen für eine Netzvorrichtung eines speziellen Verkäufers und Modells unter Verwendung des FTP-Protokolls zu erhalten. Die Datenstruktur ist ein Vektor 716 von Paaren (z. B. 718 und 720), wobei die Paare aus der Struktur SKeyInfoType 722 und einer ganzen Zahl bestehen. Die Struktur SKeyInfoType 722 enthält Informationen, die verwendet werden, um spezielle Statusinformationen von einer FTP-Datei einer Netzvorrichtung unter Verwendung von FTP zu erhalten. Die Struktur von SKeyInfoType 722 ist in 29C gezeigt. Die ganze Zahl in dem Paar bestimmt das Gewicht oder die Priorität der Statusinformationen. CFTPProtocol 2602 verwendet den Vektor 716, um zu bestimmen, welche Statusinformationen von der Netzvorrichtung zu erhalten sind.
  • Die in den Vektor 716 gesetzten Informationen werden von der Datenstruktur in 27D für einen speziellen Verkäufer und ein spezielles Modell erhalten.
  • 29D zeigt die Datenstruktur, die verwendet wird, um die durch die verschiedenen Protokolle erhaltenen Statusinformationen zu verwalten. Sie verwaltet keine Informationen darüber, welches Protokoll verwendet wurde, um die Statusinformationen zu erhalten. Die Datenstruktur ist eine Abbildung 724. Der Schlüssel 726 für die Abbildung 724 ist ein infoType. infoType ist eine Zahl, die einen Typ von Informationen darstellt. Der Wert 728 für die Abbildung 724 ist ein Paar. Das Paar besteht aus einem String und einer ganzen Zahl. Der String in dem Paar ist die Statusinformationen, die von der Netzvorrichtung erhalten werden, die dem infoType entspricht. Die ganze Zahl in dem Paar ist das Gewicht oder die Priorität der Statusinformationen, wie von einem Protokoll erhalten. Als Beispiel für den infoType von 700, der den Pegel von schwarzem Toner in der Druckerkassette darstellen kann, kann das Paar den String "75%" und die ganze Zahl 10000 enthalten. Der String "75%" gibt an, dass 75% des Toners in der Kassette verbleiben, und die ganze Zahl 10000 ist das Gewicht oder die Priorität der Statusinformationen. CSNMPProtocol 2402, CHTTPProtocol 2502 und CFTPProtocol 2602 fügt Statusinformationen, die es von den Netzvorrichtungen erhält, zur Abbildung 724 hinzu.
  • 30 zeigt ein Beispiel dessen, wie die Datenstrukturen von 27D, 29C und 29D verwendet werden, um Statusinformationen von einer Netzvorrichtung unter Verwendung des FTP-Protokolls zu erhalten. Die Abbildung 800, die Musterdaten enthält, entspricht der Datenstruktur, wie in 27D beschrieben. Die Musterdaten in der Abbildung 800 liefern Informationen zum Zugreifen auf Statusinformationen für die Netzvorrichtung für den Verkäufer Ricoh und das Modell Aficio 120 unter Verwendung von FTP. Jede der Strukturen in dem Vektor, SDirFileStatusInfo1, SdirFileStatusInfo2 und SDirFileStatusInfo3, liefert Informationen zum Zugreifen auf Statusinformationen von einer FTP-Datei in der Netzvorrichtung. SDirFileStatusInfo1 802 enthält Informationen zum Zugreifen auf Statusinformationen von der Netzvorrichtung von der FTP-Datei status.txt im Verzeichnis/pub. Fünf Statusinformationswerte können von der FTP-Datei unter Verwendung des Vektors der Paare von SKeyInfoType und der ganzen Zahl erhalten werden. Jeder des SKeyInfoType in den Vektorpaaren entspricht verschiedenen Statusinformationen entsprechend dem info-Type, wie in 30 gezeigt. Die Abbildung 804 enthält Musterdaten, die der Datenstruktur entsprechen, wie in 29D beschrieben. Die Abbildung 804 enthält Statusinformationen, die vorher von anderen Protokollen erhalten wurden. Die Abbildung 804 enthält drei Typen von Statusinformationen, die dem infoType 600, 610 und 700 entsprechen. Die Statusinformationen für infoType 600 sind "Papier niedrig" mit dem Gewicht von 500. Die Statusinformationen für infoType 610 sind "24321" mit dem Gewicht von 10000.
  • Die Statusinformationen für infoType 70 sind "OK" mit dem Gewicht von 2500. Um festzustellen, welche Statusinformationen unter Verwendung des FTP-Protokolls erhalten werden, wird ein Vektor 806 erzeugt, um die zu erhaltenden Statusinformationen zu enthalten. Die zum Vektor 806 hinzuzufügenden Informationen werden durch die Informationen in der Abbildung 800 (insbesondere den Vektor von Paaren in der Struktur SDirFileStatusInfo1 802) und die Statusinformationen in der Abbildung 804 bestimmt. Wenn die von der Abbildung 800 zu erhaltenden Statusinformationen noch nicht in der Abbildung 804 erhalten wurden, dann fügt der Prozess die zum Erhalten der Statusinformationen erforderlichen Informationen im Vektor 806 hinzu. Wenn die von der Abbildung 800 zu erhaltenden Statusinformationen bereits in der Abbildung 804 erhalten wurden, dann wird geprüft, ob die durch das FTP-Protokoll zu erhaltenden Statusinformationen informativer sind als die Statusinformationen in der Abbildung 804, indem das Gewicht verglichen wird. Informationen zum Erhalten der Statusinformationen werden zum Vektor 806 nur dann hinzugefügt, wenn das Gewicht der Statusinformationen, die durch FTP erhalten werden, größer ist als das Gewicht der Statusinformationen, die sich bereits in der Abbildung 804 befinden. Die durch FTP zu erhaltenden Statusinformationen entsprechend SDirFileStatusInfo1 802 sind der infoType 600, 610, 620, 700 und 710. Der InfoType 620 und 710 befinden sich nicht in der Statusinformationsabbildung 804, so dass die Statusinformationen unter Verwendung von FTP erhalten werden müssen. Daher werden die Informationen, die verwendet werden, um die Statusinformationen zu erhalten, die 620 (SKeyInfoType3) und 710 (SKeyInfoType5) entsprechen, zum Vektor 806 hinzugefügt. Der infoType 600 und 700 befinden sich in der Statusinformationsabbildung 804. Das Gewicht der durch FTP erhaltenen Statusinformationen für diese infoTypes, wie in 802 gezeigt, ist größer als ihr Gewicht in der Statusinformationsabbildung 804. Somit sind die für diese zwei infoTypes durch FTP erhaltenen Statusinformationen informativer als die Statusinformationen, die in der Abbildung 804 existieren. Daher werden Informationen zum Erhalten der Statusinformationen für infoType 600 (SKeyInfoType1) und 700 (SKeylnfoType4) zum Vektor 806 hinzufügt. Der infoType 610 befindet sich in der Statusinformationsabbildung 804. Das Gewicht der durch FTP erhaltenen Statusinformationen für diesen infoType, wie in 802 gezeigt, ist geringer als sein Gewicht in der Statusinformationsabbildung 804. Somit sind die für diesen infoType durch FTP erhaltenen Statusinformationen weniger informativ als die Statusinformationen, die in der Abbildung 804 existieren. Daher werden Informationen zum Erhalten der Status informationen für infoType 610 (SKeyInfoType2) nicht zum Vektor 806 hinzugefügt. Dieser Vektor 806 wird vom FTP-Protokoll verwendet, um die Statusinformationen für infoType 600, 620, 700 und 710 zu erhalten. Zwei Statusinformationswerte werden zur Statusinformationsabbildung 804 hinzugefügt und zwei Statusinformationswerte werden in der Statusinformationsabbildung 804 überschrieben, wenn FTP beim Erhalten der Statusinformationen erfolgreich ist. 30 zeigt ein Beispiel dessen, wie die Datenstrukturen verwendet werden, um die Statusinformationen für das FTP-Protokoll zu erhalten. Ein ähnlicher Prozess bei der Verwendung der Datenstrukturen von 27B, 27C, 29A und 29B wird verwendet, um die Statusinformationen für SNMP und HTTP zu erhalten.
  • 31A ist ein Ablaufplan, der das Verfahren zum Erhalten von Statusinformationen beschreibt. Alle Protokolle verwenden dasselbe hierin beschriebene Verfahren. Bevor ein Protokollobjekt verwendet wird, um spezielle Statusinformationen zu erhalten, prüft das Protokollobjekt, um festzustellen, ob die Statusinformationen bereits von einem anderen Protokollobjekt erhalten wurden. Wenn die Statusinformationen bereits erhalten wurden, muss es prüfen, um festzustellen, ob die Statusinformationen, die es erhält, informativer sind als das, was bereits von einem anderen Protokollobjekt erhalten wurde. Die informativsten Statusinformationen werden behalten. Das Verfahren des Ablaufplans stellt sicher, dass die informativsten Statusinformationen erhalten werden. Die Datenstrukturen 510, 520 und 530 von 27B, 27C und 27D werden von ihrem entsprechenden Protokoll verwendet, um festzustellen, welche Statusinformationen zu erhalten sind. In Schritt 3102 wird ein Vektor von Paaren, der Informationen enthält, die verwendet werden, um Statusinformationen von der Netzvorrichtung zu erhalten, ohne Einträge erzeugt. Der Vektor von Paaren entspricht einer der Datenstrukturen 700, 708 oder 716 von 29A bis 29C in Abhängigkeit von dem verwendeten Protokoll. In Schritt 3104 werden Informationen erhalten, die verwendet werden, um einen Typ von Statusinformationen von der Netzvorrichtung eines gegebenen Verkäufers und Modells zu erhalten. Alle Protokollobjekte verwalten Informationen darüber, welche Statusinformationen für jeden Verkäufer und jedes Modell, die es unterstützt, zu erhalten sind. Alle Protokollobjekte werden mit diesen Informationen durch den in 28 beschriebenen Initialisierungsprozess initialisiert. Die Informationen, die verwendet werden, um eine Statusinformation zu erhalten, werden in einer der Strukturen SOIDinfoType 706, SKeyValueInfo 714 oder SKeyInfoType 722 von 29A, 29B und 29C in Abhängigkeit von dem verwendeten Protokoll gespeichert. In Schritt 3106 wird eine Prüfung durchgeführt, um festzustellen, ob weitere Informationen vorhanden sind, die verwendet werden, um Statusinformationen von der Netzvorrichtung zu erhalten. Wenn keine weiteren Informationen vor handen sind, dann enthält der Vektor von Paaren, der in Schritt 3102 erzeugt wird, alle Informationen, die erforderlich sind, um alle Statusinformationen von der Netzvorrichtung für das Protokoll zu erhalten. in Schritt 3108 verwendet das Protokollobjekt den Vektor von Paaren, um die Statusinformationen von der Netzvorrichtung zu erhalten, und die Statusinformationen werden in die Statusinformationsabbildung 724, die in 29D beschrieben ist, gegeben. Das Erhalten von Statusinformationen durch ein Protokoll ist in Schritt 3110 vollendet. Wenn weitere Informationen vorliegen, die verwendet werden, um Statusinformationen von der Netzvorrichtung zu erhalten, dann wird in Schritt 3112 geprüft, um festzustellen, ob die Statusinformationen bereits erhalten wurden. Dies wird durch Betrachten der Abbildung, die die Statusinformationen enthält, wie in 29D beschrieben, um festzustellen, ob die Statusinformationen in der Abbildung bereits existieren, durchgeführt. Wenn die Statusinformationen nicht in der Abbildung existieren, dann werden die Informationen, die verwendet werden, um die Statusinformationen zu erhalten, zum Vektor von Paaren in Schritt 3114 hinzugefügt. Nach dem Hinzufügen der Informationen zum Vektor von Paaren wird zu Schritt 3104 zurückgegangen, um weitere Informationen zu erhalten, die verwendet werden, um Statusinformationen zu erhalten. Wenn die Statusinformationen bereits erhalten wurden, dann wird das Gewicht der Statusinformationen, die bereits erhalten wurden, mit dem Gewicht oder der Priorität der Statusinformationen, die durch das Protokoll erhalten werden können, in Schritt 3116 verglichen. Wenn das Gewicht oder die Priorität der Statusinformationen in der Abbildung für die Statusinformationen der Netzvorrichtung größer ist als das Gewicht oder die Priorität der vom Protokoll zu erhaltenden Statusinformationen, dann werden die Informationen, die zum Erhalten der Statusinformationen verwendet werden, nicht zum Vektor von Paaren hinzugefügt. Statt dessen wird zu Schritt 3104 zurückgegangen, um weitere Informationen zu erhalten, die zum Erhalten von Statusinformationen verwendet werden. Wenn das Gewicht oder die Priorität der Statusinformationen in der Abbildung nicht größer ist als das Gewicht oder die Priorität der durch das Protokoll zu erhaltenden Statusinformationen, dann werden die Informationen, die verwendet werden, um die Statusinformationen zu erhalten, zum Vektor von Paaren in Schritt 3114 hinzugefügt. Nach dem Hinzufügen der Informationen zum Vektor von Paaren wird zu Schritt 3104 zurückgegangen, um weitere Informationen zu erhalten, die zum Erhalten von Statusinformationen verwendet werden.
  • 31B zeigt einen Ablaufplan, der den Prozess zum Erhalten von Statusinformationen über die Netzvorrichtungen unter Verwendung aller Protokolle beschreibt. Nachdem die Protokollobjekte mit Informationen über den Verkäufer und das Modell von Netzvorrichtungen, die es unterstützt, initialisiert wurden, wie in 28 beschrie ben, können die Protokollobjekte verwendet werden, um Statusinformationen von den Netzvorrichtungen zu erhalten. Die Protokollobjekte enthalten Informationen darüber, wie Statusinformationen für gegebene Verkäufer und Modelle unter Verwendung der Datenstrukturen, wie in 27B, 27C und 27D beschrieben, zu erhalten sind. Der Vektor von Zeigern auf CAbsProtocol 2308, der in 27A beschrieben ist, wird verwendet, um die Statusinformationen für alle Protokollobjekte zu erhalten. Der Prozess des Ablaufplans durchschreitet den Vektor einmal. In Schritt 3122 wird ein Protokollobjekt vom Vektor von Zeigern auf CAbsProtocol erhalten. Das Protokollobjekt entspricht einem der Netzprotokolle zum Zugreifen auf die Netzvorrichtung (z. B. SNMP, HTTP und FTP). In Schritt 3124 wird eine Prüfung durchgeführt, um festzustellen, ob weitere Protokollobjekte vorhanden sind, die vom Vektor erhalten werden können. Diese Prüfung wird durch Feststellen, ob das Ende des Vektors erreicht wurde, durchgeführt. Wenn keine weiteren Protokollobjekte erhalten werden können, dann ist das System mit dem Erhalten der Statusinformationen von der Netzvorrichtung unter Verwendung aller Protokollobjekte in Schritt 3126 fertig. Wenn ein Protokollobjekt, das vom Vektor erhalten wird, vorliegt, dann wird das Protokollobjekt verwendet, um die Statusinformationen der Netzvorrichtung in Schritt 3128 zu erhalten. Nach dem Erhalten der Statusinformationen unter Verwendung des Protokollobjekts werden weitere Statusinformationen unter Verwendung eines anderen Protokollobjekts erhalten, indem zu Schritt 3122 zurückgegangen wird.
  • 32A zeigt die Datenstruktur, die verwendet wird, um Informationen über die Verkäufer und Modelle von Netzvorrichtungen, die von einem gegebenen Protokoll unterstützt werden, zu verwalten, während 32B ein Beispiel von Informationen, die in der Datenstruktur verwendet werden, zeigt. Die Organisation von Informationen in der Datenbank über die unterstützten Verkäufer und Modelle und, wie die Statusinformationen von ihnen zu erhalten sind, variiert unter den Protokollen. Daher unterscheidet sich das Erhalten der unterstützten Verkäufer und Modelle von der Datenbank für verschiedene Protokolle voneinander. Um den Zugriff auf unterstützte Verkäufer und Modelle zu vereinfachen, kann eine Abbildungsstruktur verwendet werden, um diese Informationen für alle Protokolle zu speichern und auf diese zuzugreifen. 32A zeigt die Verkäufer-Modell-Unterstützungsabbildung 3200. Der Schlüssel 3202 für die Abbildung 3200 ist ein String, der Informationen über den Verkäufer und das Modell, die von einem Protokoll unterstützt werden, enthält. Der Wert 3204 für die Abbildung 3200 ist eine ganze Zahl, die verwendet werden kann, um Informationen in Bezug auf den Verkäufer und das Modell darzustellen, wie z. B. eine Verkäufer-Modell-Identifikationsnummer. Der Grund dafür, dass eine Abbildungsstruktur zum Enthalten von Informationen über die Verkäufer und Modelle, die von einem Protokoll unterstützt werden, gewählt wurde, bestand darin, dass eine Abbildungsstruktur einen Nachschlagemechanismus aufweist, um leicht einen Schlüssel in einer Abbildung zu finden. Folglich ist es leicht festzustellen, ob ein Verkäufer und ein Modell in der Abbildung gespeichert ist. Obwohl die Erörterung von 32A angegeben hat, dass die Informationen über den Verkäufer und das Modell für verschiedene Protokolle von der Datenbank stammen, können die Informationen von irgendeiner externen Quelle wie z. B. einer Textdatei oder einer Tabellenkalkulation stammen.
  • 32B zeigt eine Verkäufer-Modell-Unterstützungsabbildung 3206 mit Mustereinträgen in der Abbildung. Der Schlüssel 3208 für die Abbildung 3206 ist ein String, der den Verkäufernamen, ein Trennzeichen "%%%%%" und den Modellnamen enthält. Für den Verkäufer "Verkäufer 1" und das Modell "Modell 1" ist beispielsweise der String für den Schlüssel 3208 für die Abbildung 3206 "Verkäufer1%%%%%Modelll". Obwohl das Trennzeichen "%%%%%" in dem Beispiel verwendet wurde, kann ein beliebiges Trennzeichen verwendet werden, das nicht als Teil des Verkäufernamens oder Modellnamens betrachtet werden würde, wie z. B. "@@@@@". Der Grund dafür, dass ein Trennzeichen verwendet wird, besteht darin, den Verkäufer vom Modell zu unterscheiden, so dass der Verkäufer und das Modell leicht aus dem String erhalten werden können. Der Wert 3210 für die Abbildung 3206 ist die ganze Zahl 1. Der Wert 3210 für die Abbildung 3206 kann eine beliebige ganze Zahl sein. Jedes Protokoll verwaltet eine Verkäufer-Modell-Unterstützungsabbildung 3200.
  • 33 ist ein Ablaufplan, der das Verfahren zum Hinzufügen von unterstützten Verkäufern und Modellen zur Verkäufer-Modell-Unterstützungsabbildung 3200 von 32A beschreibt, so dass alle Verkäufer und Modelle, die von einem Protokoll unterstützt werden, enthalten sind. In Schritt 3302 werden der Verkäufer und das Modell von der Datenbank erhalten. Wie der Verkäufer und das Modell von der Datenbank erhalten werden, unterscheidet sich unter den Protokollen. Dies hängt von den Tabellen in der Datenbank ab, die die unterstützten Verkäufer und Modelle enthalten. In Schritt 3304 wird eine Prüfung durchgeführt, um festzustellen, ob weitere Verkäufer- und Modellinformationen von der Datenbank zu erhalten sind. Wenn keine weiteren zu erhalten sind, dann wird das Verfahren zum Belegen der Verkäufer-Modell-Unterstützungsabbildung 3200 mit unterstützten Verkäufern und Modellen in Schritt 3306 vollendet. Die Verkäufer-Modell-Unterstützungsabbildung 3200 enthält alle Verkäufer und Modelle, die von einem Protokoll unterstützt werden. Kein weiterer Zugriff auf die Datenbank ist erforderlich, um die Informationen von unterstützten Verkäufern und Modellen zu erhalten. Wenn ein Verkäufer und Modell vorliegen, die von der Datenbank erhalten werden, dann wird ein String, der als Schlüssel für die Verkäufer-Modell-Unterstützungsabbildung 3200 verwendet werden soll, in Schritt 3308 erzeugt. Der String besteht aus dem Verkäufernamen, einem Trennzeichen und dem Modellnamen. Wie vorher beschrieben, kann das Trennzeichen ein beliebiger String sein, der nicht als Teil des Verkäufernamens oder Modellnamens betrachtet werden würde. In Schritt 3310 wird eine Prüfung durchgeführt, um festzustellen, ob der String, der aus dem Verkäufernamen, dem Trennzeichen und dem Modellnamen besteht, bereits in der Verkäufer-Modell-Unterstützungsabbildung 3200 existiert. Wenn der String bereits in der Abbildung 3200 existiert, dann wird ein anderer Verkäufer und ein anderes Modell aus der Datenbank in Schritt 3302 erhalten. Wenn der String in der Abbildung 3200 nicht existiert, dann werden der String und eine ganze Zahl zur Abbildung 3200 hinzugefügt. Nachdem der String zur Abbildung 3200 hinzugefügt wurde, dann wird ein weiterer Verkäufer und ein weiteres Modell von der Datenbank in Schritt 3302 erhalten.
  • 34 ist ein Ablaufplan, der das Verfahren zum Erhalten des Verkäufers und Modells, die von einem Protokoll unterstützt werden, von der Verkäufer-Modell-Unterstützungsabbildung 3200 von 32A beschreibt. In Schritt 3402 wird ein String für den Schlüssel von der Verkäufer-Modell-Unterstützungsabbildung 3200 erhalten. In Schritt 3404 wird eine Prüfung durchgeführt, um festzustellen, ob weitere Schlüssel von der Abbildung 3200 zu erhalten sind. Wenn keine weiteren Schlüssel vorhanden sind, dann wurden alle von einem Protokoll unterstützten Verkäufer und Modelle erhalten und das Erhalten des Verkäufers und Modells ist in Schritt 3406 vollständig. Wenn ein String für den Schlüssel von der Abbildung 3200 erhalten wurde, dann wird der Teilstring vor dem Trennzeichen erhalten, um den Verkäufernamen in Schritt 3408 zu erhalten. In Schritt 3410 wird der Teilstring nach dem Trennzeichen erhalten, um den Modellnamen zu erhalten. Dann ist in Schritt 3406 das Erhalten des Verkäufers und Modells vollendet. Indem alle Einträge in der Abbildung 3200 durchlaufen werden, können alle von einem Protokoll unterstützten Verkäufer und Modelle erhalten werden.
  • 35 zeigt das Paketdiagramm des Vorrichtungspakets. Das Paket ist für das Erzeugen der Softwareobjekte, die die Netzvorrichtungen darstellen, verantwortlich. Das Vorrichtungspaket 1300 besteht aus zwei Klassen, CDeviceFactory 1302 und CDevice 1304. Die Klasse CDeviceFactory 1302 ist für das Erzeugen und Initialisieren des Softwareobjekts für eine Netzvorrichtung verantwortlich. Das Initialisieren des Softwareobjekts umfasst das Bestimmen des Verkäufers, Modells und des eindeutigen Identifizierers der Netzvorrichtung und das Festlegen der Protokolle, die verwendet werden können, um auf die Netzvorrichtungen zuzugreifen. Wenn auf die Netzvorrichtung nicht zugegriffen werden kann, dann wird kein Softwareobjekt für die Netzvorrichtung erzeugt. Die Klasse CDevice 1304 stellt das Softwareobjekt für eine Netzvorrichtung dar. CDevice 1304 verwaltet Informationen über die Netzvorrichtung und erhält Statusinformationen über die Netzvorrichtung. CDevice 1304 verwendet das HWaccess-Paket 1304, das in 23 beschrieben ist, um auf die Netzvorrichtung durch verschiedene Protokolle zuzugreifen, um Informationen von der Vorrichtung zu erhalten.
  • 36A zeigt eine Datenstruktur, die von den Softwareobjekten verwendet wird, die die Netzvorrichtungen darstellen, CDevice 1304, wie in 35 beschrieben, um festzustellen, welche Protokolle verwendet werden, um auf die Netzvorrichtung zuzugreifen. CDevice 1304 enthält die Protokollparameterabbildung 1400. Der Schlüssel 1402 für die Abbildung 1400 ist ein String, der das Protokoll (z. B. SNMP, HTTP, FTP) darstellt. Der Wert 1404 für die Abbildung 1400 ist ein Vektor der Struktur SParameter. Die Struktur SParameter 1406 enthält Informationen, die verwendet werden, um auf die Netzvorrichtung für ein gegebenes Protokoll zuzugreifen. Der SParameter 1406 enthält Informationen, die vielmehr für die Netzvorrichtung charakteristisch sind als für den Verkäufer und das Modell der Vorrichtung charakteristisch sind. Die Informationen können beispielsweise der Gemeinschaftsname sein, um auf die Netzvorrichtung durch SNMP zuzugreifen, oder die Informationen können der Benutzername und das Passwort sein, um auf die Netzvorrichtung durch FTP zuzugreifen. Diese sind gemeinsame Informationswerte, die verwendet werden, um auf irgendeine Netzvorrichtung durch SNMP oder FTP zuzugreifen. Informationen von der Datenbank, die durch das DeviceODBC-Paket erhalten werden, werden zu der Abbildung hinzugefügt, so dass auf die Netzvorrichtung durch die verschiedenen Protokolle zugegriffen werden kann. Einträge in der Abbildung werden für ein Protokoll entfernt, wenn das Protokoll nicht auf die Netzvorrichtung unter Verwendung des Protokolls zugreifen kann und wenn der Verkäufer und das Modell vom Protokoll nicht unterstützt werden. Einige Protokolle greifen auf die Netzvorrichtung zu, selbst wenn der Verkäufer und das Modell nicht vom Protokoll unterstützt werden können. Ein solches Protokoll ist SNMP.
  • 36B zeigt Musterdaten in der Protokollparameterabbildung 1400 von 36A für eine Netzvorrichtung. Die Netzvorrichtung verwendet zwei Protokolle, um Statusinformationen zu erhalten – SNMP und FTP. Daher enthält die Abbildung 1410 für die Netzvorrichtung zwei Einträge für den Schlüssel "SNMP" und "FTP". Um auf die Netzvorrichtung unter Verwendung von SNMP zuzugreifen, ist der Gemeinschaftsname erforderlich. Der Vektor von SParameter für SNMP enthält Informationen über den Gemeinschaftsnamen. Der Parametername von GEMEINSCHAFT und ein Parameterwert von "privat" wird für einen SParameter verwendet, um den Zugriff auf die Netzvorrichtung zu ermöglichen. Um auf die Netzvorrichtung unter Verwendung von FTP zuzugreifen, sind der Benutzername und das Passwort erforderlich. Der Vektor von SParameter für FTP enthält Informationen über den Benutzernamen und das Passwort. Der Parametername von BENUTZERNAME mit einem Parameterwert von "abc" wird für einen SParameter verwendet und der Parameter von PASSWORT mit einem Parameterwert von "xyz" wird für einen anderen SParameter verwendet, um den Zugriff auf die Netzvorrichtung zu ermöglichen.
  • 37 zeigt einen Ablaufplan, der beschreibt, wie die Protokollparameterabbildung 1400 von 36A aktualisiert wird, um festzustellen, welche Protokolle verwendet werden, um die Statusinformationen von einer Netzvorrichtung zu erhalten. Die Schritte in 37 werden durchgeführt, um den Verkäufernamen und den Modellnamen einer Netzvorrichtung für ein Protokoll zu erhalten. In Schritt 3702 wird eine Prüfung durchgeführt, um festzustellen, ob auf die Netzvorrichtung unter Verwendung eines Protokolls zugegriffen werden kann. Auf die Netzvorrichtung wird durch das Protokoll unter Verwendung der Informationen in der Abbildung 1400 zugegriffen. Wenn auf die Netzvorrichtung nicht durch das Protokoll zugegriffen werden kann, wird das Protokoll aus der Protokollparameterabbildung 1400 in Schritt 3704 entfernt und die Aktualisierung der Abbildung 1400 wird in Schritt 3714 vollendet. Wenn auf die Netzvorrichtung durch das Protokoll zugegriffen werden kann, dann wird in Schritt 3706 eine Prüfung durchgeführt, um festzustellen, ob der Verkäufer der Netzvorrichtung unter Verwendung des Protokolls erhalten werden kann. Wenn der Verkäufer nicht erhalten werden kann, dann wird in Schritt 3707 eine Prüfung durchgeführt, ob der ALLGEMEINE Verkäufer vom Protokoll unterstützt wird. Die Unterstützung für den ALLGEMEINEN Verkäufer für ein Protokoll bedeutet, dass ein Protokoll Statusinformationen erhalten kann, die allen Vorrichtungen gemeinsam sind (gemeinsame Statusinformationen), selbst wenn es nicht den Verkäufer der Vorrichtungen erhalten kann oder diesen unterstützt. Wenn der ALLGEMEINE Verkäufer vom Protokoll nicht unterstützt wird, dann wird das Protokoll aus der Protokollparameterabbildung 1400 in Schritt 3704 entfernt und die Aktualisierung der Abbildung 1400 wird in Schritt 3714 vollendet. Wenn der ALLGEMEINE Verkäufer vom Protokoll unterstützt wird, dann bleibt das Protokoll in der Protokollparameterabbildung 1400 und die Aktualisierung der Abbildung wird in Schritt 3714 vollendet. Wenn der Verkäufer in Schritt 3706 erhalten werden kann, dann wird in Schritt 3708 eine Prüfung durchgeführt, um festzustellen, ob der Verkäufer der Netzvorrichtung vom Protokoll unterstützt wird. Wenn der Verkäufer nicht vom Protokoll unterstützt wird, dann wird in Schritt 3707 eine Prüfung durchgeführt, um festzustellen, ob der ALLGEMEINE Verkäufer vom Protokoll unterstützt wird. Die Sequenz von Schritten, die Schritt 3707 folgt, ist vorstehend erörtert.
  • Wenn der Verkäufer vom Protokoll unterstützt wird, dann wird in Schritt 3710 eine Prüfung durchgeführt, um festzustellen, ob das Modell der Netzvorrichtung unter Verwendung des Protokolls erhalten werden kann. Wenn das Modell nicht erhalten werden kann, dann wird in Schritt 3711 eine Prüfung durchgeführt, ob das ALLGEMEINE Modell vom Protokoll unterstützt wird. Die Unterstützung für das ALLGEMEINE Modell für ein Protokoll bedeutet, dass ein Protokoll Statusinformationen erhalten kann, die allen Vorrichtungen eines Verkäufers gemeinsam sind (verkäuferspezifische Statusinformationen), selbst wenn es nicht das Modell der Vorrichtungen erhalten kann oder dieses nicht unterstützt. Wenn das ALLGEMEINE Modell vom Protokoll nicht unterstützt wird, dann wird das Protokoll aus der Protokollparameterabbildung 1400 in Schritt 3704 entfernt und die Aktualisierung der Abbildung 1400 wird in Schritt 3714 vollendet. Wenn das ALLGEMEINE Modell vom Protokoll unterstützt wird, dann bleibt das Protokoll in der Protokollparameterabbildung 1400 und die Aktualisierung der Abbildung wird in Schritt 3714 vollendet. Wenn das Modell in Schritt 3710 erhalten werden kann, dann wird in Schritt 3712 eine Prüfung durchgeführt, um festzustellen, ob das Modell der Netzvorrichtung vom Protokoll unterstützt wird. Wenn das Modell vom Protokoll nicht unterstützt wird, dann wird in Schritt 3711 eine Prüfung durchgeführt, ob das ALLGEMEINE Modell vom Protokoll unterstützt wird. Die Sequenz von Schritten, die 3711 folgt, ist vorstehend erörtert. Wenn das Modell vom Protokoll unterstützt wird, dann kann das Protokoll verwendet werden, um Statusinformationen für die Netzvorrichtung zu erhalten, und die Aktualisierung der Protokollparameterabbildung 1400 wird in Schritt 3714 vollendet. Wenn der Verkäufer und das Modell nicht erhalten werden oder nicht unterstützt werden, dann wird das Protokoll aus der Protokollparameterabbildung 1400 entfernt und das Protokoll wird nicht verwendet, um Statusinformationen zu erhalten. Es gibt Veränderungen an dem in 37 gezeigten Prozess in Abhängigkeit von dem Protokoll. Während HTTP und FTP der Beschreibung im Ablaufplan folgen, wird SNMP unterstützt und verwendet, um die Statusinformationen zu erhalten, selbst wenn der Verkäufer unterstützt wird, aber das Modell und allgemeine Modell nicht unterstützt werden.
  • Wie vorstehend erörtert, können Statusinformationen durch SNMP von der Netzvorrichtung erhalten werden, selbst wenn der Verkäufer und das Modell nicht erhalten oder unterstützt werden. Solange die Netzvorrichtung SNMP unterstützt und auf diese durch SNMP zugegriffen werden kann, können Informationen von der Manage mentinformationsbasis (MIB) der Netzvorrichtung erhalten werden. Wenn in Schritt 3702 auf die Netzvorrichtung nicht durch SNMP zugegriffen werden kann, dann kann das SNMP-Protokoll aus der Protokollparameterabbildung 1400 in Schritt 3704 entfernt werden. Wenn jedoch auf die Netzvorrichtung durch SNMP zugegriffen werden kann, dann bleibt das SNMP-Protokoll in der Protokollparameterabbildung 1400, ob der Verkäufer oder das Modell erhalten und unterstützt wird oder nicht. Netzvorrichtungen, die SNMP unterstützen, sehen eine MIB vor, so dass das entfernte System immer Informationen von den Vorrichtungen erhalten kann. Die Art und Anzahl von Informationen, die von der Netzvorrichtung erhalten werden können, hängen jedoch davon ab, ob der Verkäufer und das Modell erhalten und unterstützt werden. Mehr Informationen können von der Netzvorrichtung durch SNMP erhalten werden, wenn der Verkäufer und das Modell erhalten werden und bekannt sind. Wenn der Verkäufer und das Modell nicht erhalten werden können, kann SNMP dennoch Informationen erhalten, die alle Vorrichtungen bereitstellen können, wie z. B. die Systembeschreibung oder die Zeit, die das System gelaufen ist. SNMP kann verwendet werden, um Informationen von der Netzvorrichtung zu erhalten, unter den drei Bedingungen: (1) Der Verkäufer und das Modell werden unterstützt, (2) der Verkäufer wird unterstützt, aber das Modell wird nicht unterstützt, und (3) der Verkäufer und das Modell werden nicht unterstützt. HTTP und FTP besitzen nicht die Eigenschaften wie SNMP. Wenn SNMP eine Standard-MIB aufweist, der alle Netzvorrichtungen folgen können, so dass Informationen erhalten werden können, variieren Webseiten und FTP-Dateien unter Netzvorrichtungen verschiedener Verkäufer und Modelle. Es besteht kein Standard für Webseiten und FTP-Dateien, denen Netzvorrichtungen folgen, um Informationen zu erhalten.
  • Um das vorstehend mit Bezug auf 38A–38C beschriebene Problem anzugehen, wurden Ausführungsformen der vorliegenden Erfindung so ausgelegt, dass sie mehrere Verfahren zum Extrahieren von Informationen von HTML-Dateien von überwachten Vorrichtungen ermöglichen und die Erweiterung von zukünftigen Verfahren in Abhängigkeit vom Format der HTML-Dateien ermöglichen. Die hierin beschriebenen Verfahren können auf andere Protokolle angewendet werden, selbst wenn das HTTP-Protokoll als Beispiel verwendet wird.
  • 39 zeigt das Paketdiagramm, das innerhalb jedes der Protokollpakete von 23 verwendet wird, wobei XXX entweder SNMP, HTTP oder FTP ist. Die abstrakte Klasse CAbsProtocol stellt die Schnittstellenfunktionen zum Erhalten von Informationen von den Vorrichtungen bereit, stellt jedoch nicht das Verfahren zum Erhalten der Informationen bereit. Klassen, die von CAbsProtocol abgeleitet sind, stellen das Ver fahren bereit, das es zweckmäßig macht, neue Protokolle zum Erhaltenen von Informationen von Vorrichtungen hinzuzufügen. Die CXXXProtocollmp1-Klasse ist die Schnittstelle für das XXX-Paket und managt alle anderen Klassen/Pakete innerhalb des Pakets. Da CXXXProtocollmp1 von CAbsProtocol abgeleitet ist, stellt diese Klasse das Verfahren zum Erhalten von Informationen von den Vorrichtungen für ein gegebenes Protokoll bereit. Das XXXaccess-Paket implementiert das Protokoll zum Zugreifen auf die Vorrichtung und zum Erhalten von Informationen von der Vorrichtung. Das XXXODBC-Paket erhält die Protokollunterstützungsinformationen von der Unterstützungsdatenbank. Diese Informationen umfassen die Verkäufer- und Modellinformationen, die das Protokoll unterstützt, wie Informationen über den Verkäufer, das Modell und den eindeutigen Identifizierer von der Vorrichtung zu erhalten sind und wie die Statusinformationen von der Vorrichtung zu erhalten sind. 24, 25 und 26 sind spezielle Verwendungen dieses Paketdiagramms für SNMP, HTTP und FTP. Irgendwelche neuen Protokolle, die verwendet werden, um Statusinformationen von der Vorrichtung zu erhalten, folgen dieser Struktur für ihr Paketdiagramm. Ein solches neues Protokoll kann Web Services sein. Verschiedene Implementierungen eines Protokolls können auch dieser Struktur für ihr Paketdiagramm folgen.
  • 40 zeigt ein alternatives Paketdiagramm, das innerhalb jedes der Protokollpakete von 23 verwendet werden kann, wobei wieder XXX entweder SNMP, HTTP oder FTP ist. Selbst wenn dieses Paketdiagramm auf irgendeines der Protokolle angewendet werden kann, wird das HTTP-Protokoll als Beispiel verwendet. Diese Paketstruktur ermöglicht die Erweiterung von neuen Implementierungen eines Protokolls, um Informationen von einer Vorrichtung zu erhalten. Dies ist erforderlich, wenn die existierenden Implementierungen der Protokolle zum Erhalten von Informationen für neue Formate der Informationen nicht arbeiten, wie z. B. die Beispielwebseiten von 38B und 38C. Die abstrakte Klasse CAbsProtocol wird auch von diesem Paketdiagramm verwendet, wie in 39 gezeigt. Die CXXXProtocol-Klasse ist von CAbsProtocol abgeleitet. CXXXProtocol stellt eine Schnittstelle für das XXX-Paket bereit und managt alle Klassen, die verschiedenen Verfahren beim Erhalten von Informationen von den Vorrichtungen entsprechen.
  • Die Klassen CXXXProtocollmp1 und CXXXProtocollmp2 implementieren zwei verschiedene Verfahren zum Erhalten von Informationen unter Verwendung desselben Protokolls. Die CXXXProtocollmp1-Klasse stellt eine Implementierung zum Erhalten von Informationen von einer Vorrichtung bereit und verwendet die Pakete XXXaccess1 und XXXODBC1. Das XXXaccess1-Paket implementiert das Protokoll zum Zugreifen auf die Vorrichtung und zum Erhalten von Informationen von der Vorrich tung. Das XXXODBC1-Paket erhält die Protokollunterstützungsinformationen von der Datenbank. Diese Informationen umfassen den Verkäufer und das Modell, die das Protokoll unterstützt, wie die Informationen des Verkäufers, des Modells und des eindeutigen Identifizierers von der Vorrichtung zu erhalten sind und wie die Statusinformationen von der Vorrichtung zu erhalten sind. Die CXXXProtocollmp2-Klasse stellt eine weitere Implementierung zum Erhalten von Informationen von der Vorrichtung unter Verwendung desselben Protokolls wie CXXXProtocollmp1 bereit. CXXXProtocollmp2 verwendet die Pakete XXXaccess2 und XXXODBC2. Das XXXaccess2-Paket implementiert das Protokoll zum Zugreifen auf die Vorrichtung und zum Erhalten von Informationen von der Vorrichtung. Das XXXODBC2-Paket erhält die Protokollunterstützungsinformationen von der Datenbank genau wie XXXODBC1. Die Konstruktion dieses Pakets ermöglicht neue Implementierungen des Protokolls. Wenn eine neue Implementierung erforderlich ist, wird eine weitere Implementierungsklasse zusammen mit ihrem Unterstützungspaket zum Zugreifen auf die Vorrichtung unter Verwendung des Protokolls und zum Erhalten von Informationen von der Unterstützungsdatenbank hinzugefügt. Ausführungsformen des vorliegenden Systems arbeiten mit den existierenden Implementierungen, um Informationen von Vorrichtungen, die es bereits unterstützt, zusammen mit den neuen Vorrichtungen mit den neuen Implementierungen zu erhalten.
  • Die Paketdiagramme für SNMP und FTP folgen der Paketstruktur von 39 und sind in 24 und 26 gezeigt. Das Paketdiagramm für HTTP dieses Systems folgt der Paketstruktur von 40.
  • 41 zeigt eine zweite Ausführungsform des Paketdiagramms für HTTP, das auf den in 25 und 40 gezeigten Paketdiagrammen basiert. Das Paket enthält zwei Implementierungen von HTTP, um Informationen von den Webseiten zu erhalten, wie in 38A–C gezeigt. Dieses Paket verwendet die abstrakte Klasse CAbsProtocol, wie in 39 vorstehend beschrieben. Die CHTTPProtocol-Klasse ist von CAbsProtocol abgeleitet. CHTTPProtocol ist die Schnittstelle für das HTTP-Paket und managt die Pakete, die zwei verschiedenen Implementierungen von HTTP entsprechen, um Informationen von den Vorrichtungen zu erhalten. Das FirstHTTPImplementation-Paket ist die Implementierung von HTTP, um Informationen von der Webseite einer Vorrichtung zu erhalten, wie in 38A gezeigt. Das FirstHTTPImplementation-Paket entspricht der Implementierung von HTTP, um Informationen zu erhalten, wie vorstehend beschrieben. Das FirstHTTPImplementation-Paket verwendet das FirstHTTPODBC-Paket, um Unterstützungsinformationen von der Datenbank über die unterstützten Vorrichtungen und, wie die Informationen von der Vorrichtung zu erhalten sind, zu erhalten. Das SecondHTTPImplementation-Paket stellt eine weitere Implementierung von HTTP bereit, um Informationen von der Webseite einer Vorrichtung zu erhalten, wie z. B. in 38B und 38C gezeigt. Das SecondHTTPImplementation-Paket verwendet das SecondHTTPODBC-Paket, um Unterstützungsinformationen von der Datenbank über die unterstützten Vorrichtungen und, wie die Informationen von der Vorrichtung zu erhalten sind, zu erhalten. Die zweite Implementierung von HTTP durch das SecondHTTPImplementation-Paket behandelt das Problem des Erhaltens von Informationen von einer Vorrichtung, wenn derselbe Schlüssel verwendet wird, um verschiedene Statusinformationen zu erhalten, wie vorstehend in 38B und 38C beschrieben. HTTP_HTMLTool ist als Paket gezeigt, aber es ist ein Namensraum, der Objekte enthält, die von den zwei Implementierungspaketen verwendet werden. Unter Verwendung eines Namensraums können die Objekte, die er enthält, innerhalb des HTTP-Pakets verwendet werden. Dies ermöglicht, dass alle Klassen und Pakete von HTTP sich die Objekte des Namensraums teilen. Das HTTP-Paket enthält die abstrakte Klasse CAbsHTTPImplementation, die die Schnittstelle zum Erhalten von Informationen über die Vorrichtung durch HTTP bereitstellt. Klassen, die von CAbsHTTPImplementation abgeleitet sind, stellen das Verfahren zum tatsächlichen Erhalten der Informationen bereit. Das FirstHTTPImplementation- und SecondHTTPImplementation-Paket enthalten eine Klasse, die von CAbsHTTPImplementation abgeleitet ist, die das Verfahren definiert, um die Informationen zu erhalten. Die Konstruktion des HTTP-Pakets ermöglicht die zukünftige Erweiterung. Wenn die aktuellen Implementierungen Informationen nicht von den Webseiten einer Vorrichtung erhalten können, dann kann die Konstruktion für eine neue Implementierung hinzugefügt werden, indem eine Implementierung und das ODBC-Paket hinzugefügt werden.
  • 42 zeigt die Klassenspezifikation für die abstrakte Klasse CAbsHTTPImplementation. Diese abstrakte Klasse stellt die Schnittstelle zum Erhalten von Informationen von einer Vorrichtung, d. h. Statusinformationen, Verkäufername, Modellname und eindeutigen Identifizierer, bereit. Die abstrakte Klasse stellt jedoch nicht das tatsächliche Verfahren zum Erhalten der Informationen bereit. Klassen, die von CAbsHTTPImplementation abgeleitet sind, stellen das Verfahren zum Erhalten dieser Informationen bereit. Daher kann jede von CAbsHTTPImplementation abgeleitete Klasse ein anderes Verfahren zum Erhalten dieser Informationen bereitstellen. Die Verwendung von abstrakten Klassen ermöglicht folglich Flexibilität in der Konstruktion.
  • 43 und 44 beschreiben die Datenstrukturen m_ImplementationMap und m_VendorModelSupportMap der CHTTPProtocol-Klasse von 41. In 43 ist der Schlüssel für die Abbildungsstruktur m_ImplementationMap ein Zeiger auf die CAbsHTTPImplementation-Klasse. Obwohl der Schlüssel ein Zeiger auf die abstrakte Klasse CAbsHTTPImplementation ist, zeigt der Zeiger tatsächlich auf eine abgeleitete Klasse von CAbsHTTPImplementation. 43 zeigt zwei Mustereinträge in der Abbildung, die den zwei abgeleiteten Klassen von CAbsHTTPImplementation entsprechen, CFirstHTTPImplementation und CSecondHTTPImplementation. Der Wert für die Abbildung ist ein boolescher Ausdruck, der angibt, ob die Implementierungsklasse, auf die im Schlüssel gezeigt wird, verwendet wird. Diese Abbildung wird initialisiert, wenn der Konstruktor von CHTTPProtocol die private Funktion initImplementationMap() aufruft, wenn das System startet. Diese private Funktion belegt die Abbildung mit allen verschiedenen Implementierungen von HTTP, das Informationen erhält und ihren Booleschen Wert auf falsch setzt. Während des Entdeckungsprozesses (Initialisierung) zum Bestimmen, welche Vorrichtungen überwacht werden, wird festgestellt, welche Implementierungen erforderlich sind. Wenn eine Implementierung erforderlich ist, um Informationen von den Vorrichtungen zu erhalten, dann wird der Boolesche Wert auf wahr gesetzt. Nachdem der Entdeckungsprozess vollendet ist und wenn der Boolesche Wert, der einer Implementierung entspricht, falsch ist, wird die Implementierung aus der Abbildung entfernt.
  • 44 zeigt die Abbildungsstruktur m_VendorModelSupportMap mit Mustereinträgen. Diese Abbildung wird verwendet, um festzustellen, welche Implementierung von HTTP zu verwenden ist, um Informationen für einen speziellen Verkäufer und ein spezielles Modell einer überwachten Vorrichtung zu erhalten. Der Schlüssel für die Abbildung ist ein String für den Namen des Verkäufers der Vorrichtung. Der Wert, der dem Schlüssel entspricht, ist eine weitere Abbildung. In der inneren Abbildung ist der Schlüssel ein String für den Namen des Modells der Vorrichtung und der Wert ist ein Zeiger auf die abstrakte Klasse CAbsHTTPImplementation. Genau wie für m_ImplementationMap zeigt der Zeiger tatsächlich auf eine abgeleitete Klasse von CAbsHTTPImplementation, die die Implementierung von HTTP für das Modell der Vorrichtung bereitstellt. Tatsächlich entspricht der Zeiger einem der Zeiger in der Abbildung m_ImplementationMap. Die Abbildung m_VendorModelSupportMap wird während der Initialisierung des Systems belegt, wenn das System feststellt, welche Vorrichtungen überwacht werden.
  • 45 zeigt den Ablaufplan der Funktion canAccessIP() von CHTTPProtocol, die eine Implementierung zur Abbildung m_VendorModelSupportMap hinzufügen kann, wenn der Verkäufer und Modellname erhalten werden können und wenn der Verkäufer und das Modell HTTP unterstützen. Diese Funktion wird für jede Vorrichtung auf gerufen, die vom System überwacht wird, um festzustellen, ob die Vorrichtung durch HTTP unterstützt wird. Diese Funktion bestimmt, welche Implementierung von HTTP verwendet wird, um Informationen von der Vorrichtung zu erhalten. Die Funktion läuft in einer Schleife über die Abbildung m_ImplementationMap und verwendet die Implementierung, auf die vom Schlüssel der Abbildung gezeigt wird, bis der Verkäufer, das Modell und der eindeutige Identifizierer der Vorrichtung unter Verwendung einer gegebenen Implementierung erhalten sind.
  • 46 zeigt den Ablaufplan der Funktion obtainStatus() von CHTTPProtocol, die die Abbildung m_VendorModelSupportMap verwendet. Die geeignete Implementierung von HTTP wird auf der Basis des eingegebenen Verkäufers und Modells verwendet.
  • 47 zeigt das Paketdiagramm des FirstHTTPImplementation-Pakets. Dieses Paket implementiert HTTP, um Informationen von der Webseite einer Vorrichtung zu erhalten, wie z. B. der Webseite von 38A. Die Klasse CFirstHTTPImplementation ist die Schnittstelle für dieses Paket und managt die anderen Klassen und Pakete, um ein Verfahren zum Erhalten von Informationen von den Webseiten einer Vorrichtung zu implementieren. CFirstHTTPImplementation ist eine Klasse, die von CAbsHTTPImplementation abgeleitet ist. Der Anhang 1 zeigt die Funktionen, definierten Typen und Klassenattribute von CFirstHTTPImplementation. Das FirstHTTPODBC-Paket und HTTP HTMLTool-Paket ist vorstehend im Hinblick auf 41 beschrieben. Die Klasse CFirstHTMLProcessor verarbeitet die Webseite einer Vorrichtung, um die gewünschten Informationen zu erhalten. CFirstHTMLProcessor enthält ein Verfahren zum Verarbeiten des Texts der Webseiten eines speziellen Formats, um die gewünschten Informationen zu erhalten. Der Anhang 3 zeigt die Funktionen, definierten Typen und Klassenattribute von CFirstHTMLProcessor.
  • 48 zeigt das Paketdiagramm des SecondHTTPImplementation-Pakets. Dieses Paket implementiert HTTP, um Informationen von der Webseite einer Vorrichtung zu erhalten, wie z. B. der Webseite von 38B und 38C. Insbesondere behandelt dieses Paket Webseiten, in denen das Schlüsselwort zum Auffinden der Informationen mehrere Male in einer Webseite vorkommt. Die Klasse CSecondHTTPImplementation ist die Schnittstelle für dieses Paket und managt die anderen Klassen und Pakete, um ein anderes Verfahren zum Erhalten von Informationen von den Webseiten einer Vorrichtung zu implementieren. CSecondHTTPImplementation ist eine Klasse, die von CAbsHTTPImplementation abgeleitet ist. Der Anhang 2 zeigt die Funktionen, definierten Typen und Klassenattribute von CSecondHTTPImplementation. Das SecondHTTPODBC-Paket und HTTP HTMLTool-Paket ist vorstehend im Hinblick auf 41 beschrieben. Die Klasse CSecondHTMLProcessor verarbeitet die Webseite einer Vorrichtung, um die gewünschten Informationen zu erhalten. Diese Klasse enthält ein Verfahren zum Verarbeiten des Texts der Webseiten eines speziellen Formats, um die gewünschten Informationen zu erhalten. Insbesondere behandelt diese Klasse Webseiten, in denen das Schlüsselwort zum Auffinden der Informationen an mehreren Stellen auf den Webseiten vorkommt. Der Anhang 4 zeigt die Funktionen, definierten Typen und Klassenattribute von CSecondHTMLProcessor.
  • 49 zeigt die Tabellen der Unterstützungsdatenbank für die erste Implementierung von HTTP, um Informationen von den Webseiten von Vorrichtungen wie z. B. der Webseite von 38A zu erhalten. Diese Tabellen entsprechen den in 21 gezeigten Tabellen mit zwei Änderungen. Erstens wurden alle Tabellennamen außer EnumCorrespondence von 21 so geändert, dass "_1" an ihren Namen angehängt ist. Das "_1" wird verwendet, um anzugeben, dass die Tabellen der ersten Implementierung von HTTP, um Informationen von den Vorrichtungen zu erhalten, entsprechen. Zweitens ist die HTTPVendorModel_1-Tabelle nicht eindeutig anderen Tabellen zugeordnet, da dieselben Verkäufer mehr als eine Webseite für das Modell haben können.
  • 50 zeigt die Tabellen der Unterstützungsdatenbank für die zweite Implementierung von HTTP, um Informationen von den Webseiten von Vorrichtungen wie z. B. den Webseiten von 38B und 38C zu erhalten. Diese Tabellen besitzen dieselben Namen wie die Tabellen der Unterstützungsdatenbank von 49, außer dass sich 2 am Ende des Namens anstelle von 1 befindet, und des Zusatzes von "Vorbedingung" zum HTTPStatusKeyValue-Tabellennamen. Eine "2" wird verwendet, um anzugeben, dass die Tabellen der zweiten Implementierung von HTTP entsprechen. Die Tabellen der zweiten Implementierung unterscheiden sich von den Tabellen der ersten Implementierung mit dem Zusatz des sPrecondition-Eintrages zu drei Tabellen, HTTPVendorModel_2, HTTPUniqueIDWebPage_2 und HTTPPreconditionStatusKeyValue_2. Der sPrecondition-Eintrag wird zum Erhalten der Informationen von der Webseite verwendet, wenn das Schlüsselwort zum Auffinden der gewünschten Informationen mehr als einmal auf der Webseite erscheint. Die Verwendung von sPrecondition wird nachstehend genauer beschrieben. Wenn sPrecondition leer ist, dann ist der Prozess der zweiten Implementierung zum Erhalten der gewünschten Informationen derselbe wie der Prozess der ersten Implementierung zum Erhalten der gewünschten Informationen.
  • Eine Beschreibung von "Vorbedingung" wird gegeben. Wie mit Bezug auf 38B beschrieben, wird in dem Fall, in dem die restliche Lebensdauer der Abbildungseinheit "Schwarz" als Statusinformationen erhalten werden soll, gemäß dem Stand der Technik ein Wort "Schwarz" einfach auf einer Webseite gesucht. Wenn das System das erste "Schwarz" von "Tonerkassette" findet, erhält das System irrtümlich einen Wert "Ok", der dem ersten "Schwarz" der "Tonerkassette" entspricht. Wenn ein Wort "Schwarz" mit den Worten "Abbildungseinheiten" als Vorbedingung gesucht wird, kann das System die gewünschten Statusinformationen "100%" erhalten.
  • 51 zeigt das Klassendiagramm für das FirstHTTPODBC-Paket. Dieses Paket gewährt einen Zugriff auf Informationen in der Unterstützungsdatenbank, die vom FirstHTTPImplementation-Paket von 47 verwendet werden, um Informationen von den Webseiten einer Vorrichtung zu erhalten. Die CHTTODBC_1-Klasse ist die Schnittstelle für dieses Paket und managt die anderen Klassen, um die geeigneten Informationen von den Tabellen der Unterstützungsdatenbank zu erhalten. Die CXXXData_1-Klasse und ihre entsprechende CXXXTable_1-Klasse gewähren einen Zugriff auf die XXX-Tabelle der Unterstützungsdatenbank von 49, um Informationen von der Tabelle zu erhalten.
  • 52 zeigt das Klassendiagramm für das SecondHTTPODBC-Paket. Dieses Paket gewährt einen Zugriff auf Informationen in der Unterstützungsdatenbank, die vom SecondHTTPIMplementation-Paket von 48 verwendet werden, um Informationen von den Webseiten einer Vorrichtung zu erhalten. Die CHTTPODBC_2-Klasse ist die Schnittstelle zu diesem Paket und managt die anderen Klassen, um die geeigneten Informationen von den Tabellen der Unterstützungsdatenbank zu erhalten. Die CXXXData_2-Klasse und ihre entsprechende CXXXTable_2-Klasse gewähren Zugriff auf die XXX-Tabelle der Unterstützungsdatenbank von 50, um Informationen von der Tabelle zu erhalten.
  • Das vom FirstHTTPImplementation-Paket verwendete Verfahren, um die gewünschten Informationen von den Webseiten einer Vorrichtung zu erhalten, ist in der verwandten Anmeldung Seriennr. 10/328 026 mit dem Titel "Method of using Vectors of Structures for Extracting Information from the Web Pages of Remotely Monitored Devices", eingereicht am 26. Dezember 2002, beschrieben, deren Inhalte durch den Hinweis hierin aufgenommen werden. Das Verfahren des FirsthTTPImplementation-Pakets verwendet das erste Auftreten des Schlüsselworts, um die gewünschten Informationen aufzufinden, was für einige der gewünschten Informationen falsch sein könnte.
  • Wie vorstehend erörtert, wurde zum Angehen von Problemen, die die erste HTTP-Implementierung nicht handhaben konnte, ein neues System entworfen, um das Folgende durchzuführen: (1) Hinzufügen eines neuen Verfahrens zum korrekten Erhalten der gewünschten Informationen von den Webseiten, auf denen mehr als ein Auftreten des Schlüsselworts besteht, das verwendet wird, um die gewünschten Informationen aufzufinden; (2) Ermöglichen des Hinzufügens von neuen Verfahren, wenn neue Webseiten vorhanden sind, in denen die zwei Verfahren (FirstHTTPImplementation und SecondHTTPImplementation) die gewünschten Informationen nicht erhalten können; und (3) Abwärtskompatibilität, so dass das System immer noch die gewünschten Informationen von den Webseiten von Vorrichtungen erhalten können sollte, von denen das System sie vorher erhielt.
  • Die Konstruktion des HTTP-Pakets gemäß 40 und 41 führt diese gewünschten Merkmale durch. Das Hinzufügen des SecondHTTPImplementation-Pakets in 41 und das Hinzufügen der Tabellen in 50 zur Unterstützungsdatenbank, fügte eine Implementierung von HTTP hinzu, um Informationen von den Webseiten einer Vorrichtung zu erhalten, auf denen mehrere Vorkommnisse des Schlüsselworts waren, um die gewünschten Informationen aufzufinden. Die abstrakte Klasse CAbsHTT-PImplementation von 41 und die Paketstruktur von 40 ermöglichen das Hinzufügen von neuen Implementierungen von HTTP, um Informationen von den Webseiten einer Vorrichtung zu erhalten. Neue Tabellen werden zur Datenbank hinzugefügt, um Informationen darüber vorzusehen, wie Informationen von den Webseiten zu erhalten sind. Das CHTTPProtocol, wie in 41 gezeigt, managt und verwendet die geeignete Implementierung von HTTP, um Informationen von den Webseiten zu erhalten. Die Ablaufpläne in 45 und 46 beschreiben, wie CHTTPProtocol die verschiedenen Implementierungen von HTTP managt und verwendet, um Informationen zu erhalten. Ausführungsformen des vorliegenden Systems enthalten und verwenden verschiedene Implementierungen von HTTP, so dass sie Informationen von vorherigen Webseiten erhalten können, zusammen mit neuen Implementierungen von HTTP für neue Webseiten.
  • 53 zeigt die Abbildungsstruktur m_VendorModelWebInfoMap von CSecondHTTPImplementation, die von der zweiten Implementierung von HTTP verwendet wird, um Statusinformationen einer Vorrichtung von den Vorrichtungswebseiten zu erhalten. Der Schlüssel der Abbildung ist ein String des Namens des Verkäufers der Vorrichtung. Der Wert der Abbildung ist eine andere Abbildung, die Informationen enthält, die verwendet werden, um Statusinformationen von den Webseiten der Vor richtung eines gegebenen Modells zu erhalten. Der Schlüssel der inneren Abbildung ist ein String für den Namen des Modells der Vorrichtung und sein Wert ist ein Vektor von Strukturen, SWebPageInfo, der Informationen über die Webseiten und, wie Statusinformationen von den Webseiten zu erhalten sind, enthält. Die Struktur SWebPageInfo enthält die Struktur SPreconKeyValueInfo, die alle Informationen bereitstellt, die erforderlich sind, um einen einzelnen Informationsteil von einer Webseite zu erhalten. SPreconKeyValueInfo ist ähnlich zur Struktur SKeyValueInfo, die verwendet wird, um einen einzelnen Informationsteil von einer Webseite unter Verwendung der ersten Implementierung von HTTP zu erhalten, mit dem Zusatz des Stringattributs SPrecondition. Der Anhang 5 zeigt die Strukturspezifikation von SPreconKeyValueInfo. Es ist zu beachten, dass die erste Implementierung von HTTP die Struktur SKeyValueInfo verwendet und die zweite Implementierung von HTTP die Struktur SPreconKeyValueInfo verwendet. Die Abbildungsstruktur ist mit Informationen von den Tabellen der Unterstützungsdatenbank für die zweite Implementierung von HTTP belegt, wie in 50 beschrieben. Die CSecondHTTPImplementation verwendet das SecondHTTPODBC-Paket, um Informationen von den Tabellen der Datenbank zu erhalten.
  • 54 zeigt die Abbildungsstruktur m_ModelWebInfoForVendorMap von CSecondHTTPImplementation, die von der zweiten Implementierung von HTTP verwendet wird, um das Modell der Vorrichtung von den Vorrichtungswebseiten zu erhalten. Der Schlüssel für die Abbildung ist ein String für den Namen des Verkäufers der Vorrichtung. Der Wert ist ein Vektor von Paaren, die Informationen für alle unterstützten Modelle des Verkäufers über die Webseite, die den Modellnamen enthält, und wie der Modellname zu erhalten ist, enthält. Die Abbildungsstruktur ist mit Informationen von den Tabellen der Unterstützungsdatenbank für die zweite Implementierung von HTTP belegt, wie in 50 beschrieben.
  • 55 zeigt die Abbildungsstruktur m_VendorModelUniqueIDInfoMap von CSecondHTTPImplementation, die von der zweiten Implementierung von HTTP verwendet wird, um den eindeutigen Identifizierer der Vorrichtung von der Vorrichtungswebseite zu erhalten. Der eindeutige Identifizierer ist ein String, der die Vorrichtung identifiziert, z. B. die Seriennummer oder MAC-Adresse. Der Schlüssel für die Abbildung ist ein String für den Namen des Verkäufers der Vorrichtung. Der Wert ist eine andere Abbildung, die Informationen enthält, die verwendet werden, um den eindeutigen Identifizierer für das Modell der Vorrichtung zu erhalten. Der Schlüssel für die innere Abbildung ist ein String für den Namen des Modells und der Wert ist die Struktur SWebPageInfo, die Informationen über die Webseite und, wie der eindeutige Identifi zierer von der Webseite zu erhalten ist, enthält. Die Abbildungsstruktur ist mit Informationen von den Tabellen der Unterstützungsdatenbank für die zweite Implementierung von HTTP belegt, wie in 50 beschrieben.
  • 56 ist ein Ablaufplan der Funktion obtainStatus() von CSecondHTTPImplementation, die verwendet wird, um Statusinformationen von den Webseiten einer Vorrichtung unter Verwendung der Abbildungsstruktur m_VendorModelWebInfoMap zu erhalten. Die Funktion selectEntries(), die in obtainStatus() aufgerufen wird, bestimmt, welche Statusinformationen von der Vorrichtung über HTTP zu erhalten sind. Bestimmte Informationen werden entsprechend dem Verkäufer und Modell der Vorrichtung erhalten. selectEntries() gibt einen Vektor loc_InputVector zurück, der Informationen darüber enthält, welche Informationen zu erhalten sind. Einige Informationen können bereits in der Statusabbildung inOut_Data existieren. Wenn in diesem Fall die Statusinformationen, die durch HTTP erhalten werden, eine höhere Priorität (oder ein höheres Gewicht) besitzen als das, was sich in der Statusabbildung befindet, setzt selectEntries() diese Informationen in den Vektor loc_inputVector, um sicherzustellen, dass die Statusinformationen durch HTTP erhalten werden. obtainDataFromHTMLFile(), das in obtainStatus() aufgerufen wird, erhält alle Statusinformationen für die Webseite. obtainDataFromHTMLFile() verwendet ein Objekt der Klasse CSecondHTMLProcessor, um die Daten von der Webseite zu verarbeiten, um die Statusinformationen zu erhalten. Das von dieser Funktion verwendete Verfahren ist ähnlich zu dem von der ersten Implementierung von HTTP verwendeten. Es unterscheidet sich darin, dass die zweite Implementierung die Struktur SPreconKeyValueInfo verwendet, wohingegen die erste Implementierung die Struktur SKeyValueInfo verwendet.
  • 57 und 58 zeigen die Vektorstrukturen m_KeyValueVector und m_LocateValueVector, die in CSecondHTMLProcessor verwendet werden, um die Daten von den Webseiten zu verarbeiten, um die gewünschten Informationen unter Verwendung der zweiten Implementierung von HTTP zu erhalten. In 57 enthält der Vektor m_KeyValueVector Informationen darüber, wie jeder Typ von Statusinformationen von der Webseite einer überwachten Vorrichtung zu erhalten ist. Die Struktur SPreconkeyValueInfo stellt Informationen bereit, die verwendet werden, um die Statusinformationen aufzufinden und von der Webseite zu extrahieren. In 58 wird der Vektor m_LocateValueVector bei der Verarbeitung der von den Webseiten erhaltenen Informationen zum Extrahieren der Statusinformationen verwendet. Die zwei Vektoren werden zusammen im Prozess des Extrahierens der Statusinformationen verwendet. Es besteht eine Eins-zu-Eins-Entsprechung zwischen m_KeyValueVector und m_LocateValueVector. Der erste Eintrag in m_KeyValueVector wird zusammen mit dem ersten Eintrag in m_LocateValueVector verwendet, um die Statusinformationen zu erhalten, und so weiter mit den restlichen Einträgen in den zwei Vektoren.
  • Die Vektorstrukturen von 57 und 58 sind zu den Vektorstrukturen ähnlich, die für die erste Implementierung von HTTP verwendet werden, die in der verwandten Anmeldung Nr. 10/328 026 ("der '026-Anmeldung") beschrieben ist. 59 ist eine modifizierte Version von 26 der '026-Anmeldung. Einige der Änderungen von der '026-Anmeldung sind Änderungen im Namen der Struktur (unter Verwendung von S anstelle von C) und Änderungen an den Namen der Attributelemente von SKeyValueInfo. CFirstHTMLProcessor verwendet diese zwei Vektorstrukturen zum Erhalten der Statusinformationen von der Webseite unter Verwendung des in der '026-Anmeldung beschriebenen Verfahrens, deren Inhalte durch den Hinweis hierin aufgenommen werden.
  • 60 zeigt den Ablaufplan der Funktion initDataSearchInfo() von CSecondHTMLProcessor, die zum Festlegen der Vektorstrukturen von 57 und 58 verwendet wird. Diese Funktion wird durch die Funktion obtainDataFromHTMLFile() von CSecondHTMLProcessor aufgerufen, bevor die Statusinformationen von der Webseite erhalten werden.
  • Für jedes SPreconKeyValueInfo im Vektor m_KeyValueVector ist ein SLocateValueInfo in den Vektor m_LocateValueVector gesetzt. Das m_bPreconditionOK-Attribut von SLocateValueInfo wird auf wahr gesetzt, wenn der m_sPrecondition-Attributstring von SPreconKeyValueInfo leer ist, wodurch angegeben wird, dass keine Vorbedingung besteht, um die Statusinformationen aufzufinden. Wenn der m_sPrecondition-String nicht leer ist, dann wird m_bPreconditionOK auf falsch gesetzt.
  • Analog zur ersten Implementierung von HTTP erhält die zweite Implementierung von HTTP Statusinformationen vom Text (Nicht-Tag-Elemente) des HTML-Dokuments. Der Anhang 6 zeigt einen Teil des HTML-Dokuments für die Webseite entsprechend 38B. Der Text des HTML-Dokuments ist fett. 61 ist ein Ablaufplan zur Verarbeitung des Texts durch die Funktion searchAndObtainDataFromValue() von CSecondHTMLProcessor zum Erhalten der Statusinformationen. Diese Funktion verwendet die Vektorstrukturen von 57 und 58. Diese Funktion wird durch die Funktion obtainDataFormatHTMLFile() von CSecondHTMLProcessor aufgerufen, wenn Text (ein Nicht-Tag-Element) von der Webseite erhalten wird. Der Prozess von searchAndObtainDataFromValue() behandelt die Situation, in der der Schlüsselwert zum Auffinden der Statusinformationen mehrere Male vorkommt. Wenn dies der Fall ist, wird ein Vorbedingungsstring verwendet. Der Prozess sucht zuerst nach einem Vorbedingungsstring. Sobald der Vorbedingungsstring gefunden ist, wird eine Suche nach dem Schlüsselwert durchgeführt. Sobald der Schlüsselwert gefunden ist, können die Statusinformationen extrahiert werden. Jeder Typ von Statusinformationen für denselben Schlüsselwert auf einer Webseite weist einen eindeutigen Vorbedingungsstring auf. Unter Verwendung des Beispiels im Anhang 6 wird der Schlüsselwert von "Schwarz" verwendet, um den Status der Kassette für schwarzen Toner und der schwarzen Abbildungseinheit zu finden. Ohne Verwendung einer Vorbedingung wäre "Ok" der Status für sowohl die Kassette für schwarzen Toner als auch die schwarze Abbildungseinheit. Unter Verwendung einer Vorbedingung von "Tonerkassetten" für den Status der Kassette für schwarzen Toner und "Abbildungseinheiten" für den Status der schwarzen Abbildungseinheit werden die korrekten Statusinformationen für beide erhalten.
  • Wenn m_sPrecondition von SPreconKeyValueInfo leer ist, dann ist sein entsprechendes m_bPreconditionOK wahr und der Prozess des Erhaltens der Statusinformationen für SPreconKeyValueInfo ist exakt derselbe wie für das Erhalten der Statusinformationen unter Verwendung der ersten Implementierung von HTTP.
  • Eine Ausführungsform des vorliegenden Systems implementiert sowohl die SNMP-Get- als auch -GetNext-Anforderung, um alle Informationen in der MIB der Vorrichtung zu erhalten. Eine vorherige Ausführungsform durch die vorliegenden Erfinder verwendete nur die SNMP-GetNext-Anforderung, die die Fähigkeit des Systems auf den Zugriff auf alle Informationen in der MIB der Vorrichtung begrenzte. Im vorherigen System enthielt die Datenbank den String für den Objektidentifizierer, um festzustellen, welche Informationen von der MIB der Vorrichtung zu extrahieren sind. In einer bevorzugten Ausführungsform enthält der String für den Objektidentifizierer Informationen über den Typ der zu stellenden SNMP-Anforderung zusammen mit dem Objektidentifizierer. Dem Objektidentifizierer im String geht ein "G" voran, um anzugeben, dass die Get-Anforderung gestellt werden soll, und ein "N", um anzugeben, dass die GetNext-Anforderung gestellt werden soll. Wenn sich kein Buchstabe vor dem Objektidentifizierer befindet, dann wird die Vorgabe-GetNext-Anforderung gestellt. Wenn irgendein anderer Buchstabe als "G" oder "N" vor dem Objektidentifizierer liegt, dann wird keine Anforderung gestellt. Wenn der String für den Objektidenti fizierer leer ist oder nur den Buchstaben "N" enthält, dann wird die GetNext-Anforderung gestellt.
  • 62 zeigt Mustereinträge in einer Tabelle der Unterstützungsdatenbank, die verwendet wird, um Informationen von Vorrichtungen von verschiedenen Verkäufern und Modellen unter Verwendung von SNMP zu erhalten.
  • 63 zeigt das Klassendiagramm des SNMP-Pakets, das auf dem in 24 gezeigten Paketdiagramm basiert. Es ist zu beachten, dass der Typ von Anforderung in den String für den Objektidentifizierer eingebettet ist.
  • 64 zeigt das Klassendiagramm des SNMPaccess-Pakets. Die CSNMPaccess-Klasse ist die Schnittstelle für dieses Paket und bestimmt den Typ von zu verwendender SNMP-Anforderung, um die Daten zu erhalten. Die Klassen CSNMP, CSnmpSession und CSnmpUtility implementieren das SNMP-Protokoll, um Informationen von der MIB der Vorrichtung zu erhalten.
  • 65 ist ein Ablaufplan zur Verarbeitung der SNMP-Anforderung für einen String, der Informationen über den SNMP-Anforderungstyp und den Objektidentifizierer enthält. Der Prozess folgt der Funktion obtainValue() von CSNMPaccess. obtainValueFromXXXRequest() weist einen Wert out_sValue zu, wenn die SNMP-Anforderung erfolgreich ist, wobei XXX Get oder GetNext ist. Es ist möglich, dass ein leerer String für out_sValue zurückgegeben wird.
  • Obwohl gezeigt ist, dass die vorliegende Erfindung wenige Vorrichtungen umfasst, die eine Überwachung erfordern und die mit einem Netz verbunden sind, ist zu erkennen, dass eine beliebige Anzahl von Vorrichtungen mit dem Netz verbunden sein kann, ohne vom Schutzbereich der Erfindung abzuweichen. Die vorliegende Erfindung kann auch in einer Heimumgebung angewendet werden, in der verschiedene Vorrichtungen überwacht und gesteuert werden müssen.
  • Ausführungsformen der vorliegenden Erfindung ermöglichen die Überwachung der verschiedenen Vorrichtungen in einer Umgebung mehrerer Verkäufer und erleichtern ferner das Abrufen und Anzeigen von detaillierten Informationen in einer für den Benutzer verständlichen oder benutzerfreundlichen Weise selbst ohne spezielle Informationen einer privaten Managementinformationsbasis (MIB). Ferner können die Informationen unter Verwendung von verschiedenen Verfahren wie z. B. SMTP, FTP oder Web Services umverteilt werden.
  • Die Steuereinheit der vorliegenden Erfindung kann unter Verwendung eines herkömmlichen digitalen Universalcomputers oder eines Mikroprozessors, der gemäß den Lehren der vorliegenden Spezifikation programmiert ist, zweckmäßig implementiert werden, wie für Computerfachleute zu erkennen ist. Eine geeignete Softwarecodierung kann von geschulten Programmierern leicht auf der Basis der Lehren der vorliegenden Offenbarung hergestellt werden, wie für Softwarefachleute ersichtlich ist. Die Erfindung kann auch durch die Vorbereitung von anwendungsspezifischen integrierten Schaltungen oder durch Verbinden eines geeigneten Netzes von herkömmlichen Komponentenschaltungen miteinander implementiert werden, wie für Fachleute leicht ersichtlich ist.
  • Die vorliegende Erfindung umfasst ein Computerprogrammprodukt, das sich auf einem Speichermedium befindet, mit Befehlen, die verwendet werden können, um einen Computer zu programmieren, um einen Prozess der Erfindung durchzuführen. Das Speichermedium kann umfassen, ist jedoch nicht begrenzt auf eine beliebige Art von Platte, einschließlich Disketten, optischen Platten, CD-ROMs und magnetooptischen Platten, ROMs, RAMs, EPROMs, EEPROMs, magnetische oder optische Karten oder eine beliebige Art von Medien, die zum Speichern von elektronischen Befehlen geeignet sind.
  • Zahlreiche Modifikationen und Veränderungen der vorliegenden Erfindung sind angesichts der obigen Lehren möglich. Daher soll es selbstverständlich sein, dass innerhalb des Schutzbereichs der beigefügten Ansprüche die Erfindung anders als speziell hierin beschriebenen ausgeführt werden kann. Anhang 1. CFirstHTTPImplementation-Klassenspezifikation
    Figure 00840001
    Figure 00850001
    Appendix 2. CSecondHTTPImplementation-Klassenspezifikation
    Figure 00860001
    Figure 00870001
    Figure 00880001
    Appendix 3. CFirstHTMLProcessor-Klassenspezifikation
    Figure 00890001
    Figure 00900001
    Appendix 4. CSecondHTMLProcessor-Klassenspezifikation
    Figure 00900002
    Figure 00910001
    Appendix 5. SPreconKeyValueInfo-Strukturspezifikation
    Figure 00920001
    Appendix 6. Teil des HTML-Dokuments für die Webseite von Fig. 38B
    Figure 00930001
    Figure 00940001

Claims (16)

  1. Ein Verfahren zum Handhaben von Information, die konfiguriert ist, um mit einem ausgewählten Kommunikationsprotokoll verwendet zu werden, zum Extrahieren von Information, die sich auf ein überwachtes Gerät (908, 910, 912, 914) unter voneinander verschiedenen Geräten bezieht, die über ein Netzwerk (100) verbunden sind, das Verfahren umfassend die Schritte von: Abrufen von einem ersten Speicher, einer Vielzahl von Implementationsbezeichnern (500), wobei jeder Implementationsbezeichner eine erste Zugriffsfunktion bezeichnet, die dazu konfiguriert ist, auf das überwachte Gerät zuzugreifen unter Verwendung des ausgewählten Kommunikationsprotokolls, um Anbieter- und Modellinformation des überwachten Geräts zu erhalten, und eine zweite Zugriffsfunktion, die konfiguriert ist, um auf das überwachte Gerät zuzugreifen unter Verwendung des ausgewählten Kommunikationsprotokolls, um Statusinformation des überwachten Geräts zu erhalten; Auswählen (602) eines Implementationsbezeichners (502, 504, 506) unter der Vielzahl von Implementationsbezeichnern (500); Zugreifen auf eine externe Informationsspeichereinheit (904), um Supportinformation zu erhalten, um auf das überwachte Gerät zuzugreifen unter Verwendung von mindestens einer der ersten Zugriffsfunktion und der zweiten Zugriffsfunktion unter Verwendung des ausgewählten Kommunikationsprotokolls, und Speichern (512) der Supportinformation in mindestens einer internen Speichertabelle, dadurch gekennzeichnet, dass die Supportinformation Vorbehandlungsinformation umfasst, die verwendet wird, um die Status- oder die Anbieter- und Modellinformation vom überwachten Gerät zu erhalten, und wobei in der Information, die vom überwachten Gerät erhalten werden kann, eine Ortsangabe der Vorbehandlungsinformation eine Ortsangabe einschränkt vom Typ von interessierender Operation, die vom überwachten Gerät erhalten werden kann.
  2. Verfahren nach Anspruch 1, wobei das Zugreifen auf die externe Speichereinheit (904) die Verwendung einer Datenbasis (906) umfasst.
  3. Verfahren nach Anspruch 1 oder 2, wobei der Speicherschritt umfasst: Speichern der Vorbedingungsinformation in Verbindung mit der Anbieter- und Modellinformation in einer internen Speichertabelle, die konfiguriert ist, um zum Erhalten eines eindeutigen Bezeichners vom überwachten Gerät verwendet zu werden.
  4. Verfahren nach Anspruch 1 oder 2, wobei der Speicherschritt umfasst: Speichern der Vorbedingungsinformation in Verbindung mit der Anbieter- und Modellinformation in einer internen Speichertabelle, die dazu konfiguriert ist, Statusinformationen vom überwachten Gerät zu erhalten.
  5. Verfahren nach Anspruch 1 oder 2, wobei der Speicherschritt umfasst: Speichern der Vorbedingungsinformation in Verbindung mit der Anbieterinformation in einer internen Speichertabelle, die dazu konfiguriert ist, um zum Erhalten der Modellinformation vom überwachten Gerät verwendet zu werden.
  6. Verfahren nach Anspruch 1 oder 2, weiter gekennzeichnet durch: Zugreifen auf das überwachte Gerät unter Verwendung der ersten Zugriffsfunktion in Verbindung mit dem ausgewählten Implementationsbezeichner, unter Verwendung der Vorbedingungsinformation, die in der internen Speichertabelle gespeichert ist, um Anbieter- und Modellinformation zu erhalten, die sich auf das überwachte Gerät bezieht.
  7. System zum Handhaben von Information, die konfiguriert ist, um von einem ausgewählten Kommunikationsprotokoll verwendet zu werden, um Information zu extrahieren, die sich auf ein überwachtes Gerät (908, 910, 912, 914) bezieht unter voneinander verschiedenen Geräten, die über ein Netzwerk (100) verbunden sind, das System umfassend: Mittel zum Abrufen, von einem ersten Speicher, einer Vielzahl vom Implementationsbezeichnern (500), wobei jeder Implementationsbezeichner eine erste Zugriffsfunktion bezeichnet, die konfiguriert ist, um auf das überwachte Gerät zuzugreifen unter Verwendung des ausgewählten Kommunikationsprotokolls, um Anbieter- und Modellinformation des überwachten Geräts zu erhalten, und eine zweite Zugriffsfunktion, die konfiguriert ist, um auf das überwachte Gerät zuzugreifen unter Verwendung des ausgewählten Kommunikationsprotokolls um Statusinformation des überwachten Geräts zu erhalten; Mittel zum Auswählen (602) eines Implementationsbezeichners (502, 504, 506) unter der Vielzahl von Implementationsbezeichnern (500); Mittel zum Zugreifen auf eine externe Informationsspeichereinheit (904), um Supportinformation zu erhalten, um auf das überwachte Gerät zuzugreifen unter Verwendung von mindestens einer der ersten Zugriffsfunktion und der zweiten Zugriffsfunktion unter Verwendung des ausgewählten Kommunikationsprotokolls; und Mittel zum Speichern (512) der Supportinformation in mindestens einer internen Speichertabelle, dadurch gekennzeichnet, dass die Supportinformation Vorbedingungsinformation umfasst, die verwendet wird, um die Status- oder Anbieter- und Modellinformation vom überwachten Gerät zu erhalten, und wobei in der Information, die vom überwachten Gerät erhalten werden kann, eine Ortsangabe der Vorbedingungsinformation eine Ortsangabe einschränkt vom Typ von interessierender Information, die vom überwachten Gerät erhalten werden kann.
  8. System nach Anspruch 7, wobei das Mittel zum Speichern (512) umfasst: Mittel zum Speichern der Vorbedingungsinformation in Verbindung mit der Anbieter- und Modellinformation in einer internen Speichertabelle, die konfiguriert ist, um zum Erhalten eines eindeutigen Bezeichners vom überwachten Gerät verwendet zu werden.
  9. System nach Anspruch 7, wobei das Mittel zum Speichern (512) umfasst: Speichern der Vorbedingungsinformation in Verbindung mit der Anbieter- und Modellinformation in einer internen Speichertabelle, die konfiguriert ist, um zum Erhalten der Statusinformation vom überwachten Gerät verwendet zu werden.
  10. System nach Anspruch 7, wobei das Mittel zum Speichern (512) umfasst: Mittel zum Speichern der Vorbedingungsinformation in Verbindung mit der Anbieterinformation in einer internen Speichertabelle, die konfiguriert ist, um zum Erhalten der Modellinformation vom überwachten Gerät verwendet zu werden.
  11. System nach Anspruch 7, weiter gekennzeichnet durch: Mittel zum Zugreifen auf das überwachte Geräte unter Verwendung der ersten Zugriffsfunktion, die assoziiert ist mit dem ausgewählten Implementationsbezeichner, unter Verwendung der Vorbedingungsinformation, die in der internen Speichertabelle gespeichert ist, um Anbieter- und Modellinformation zu erhalten, die sich auf das überwachte Gerät bezieht.
  12. Computerprogramm-Erzeugnis zum Speichern von Instruktionen zur Ausführung auf einem Computersystem, die wenn sie von dem Computersystem ausgeführt werden, das Computersystem veranlassen, Information zu handhaben, die konfiguriert ist, um von einem ausgewählten Kommunikationsprotokoll verwendet zu werden, um Information zu extrahieren, die sich auf ein überwachtes Gerät (908, 910, 912, 914) bezieht unter voneinander verschiedenen Geräten, die über ein Netzwerk (100) verbunden sind, das Computerprogramm-Erzeugnis umfassend: Instruktionen zum Abrufen, von einem ersten Speicher, einer Vielzahl von Implementationsbezeichnern, wobei jeder Implementationsbezeichner eine erste Zugriffsfunktion bezeichnet, die konfiguriert ist, um auf das überwachte Gerät zuzugreifen unter Verwendung des ausgewählten Kommunikationsprotokolls, um Anbieter- und Modellinformation des überwachten Geräts zu erhalten, und eine zweite Zugriffsfunktion, die konfiguriert ist, um auf das überwachte Gerät zuzugreifen unter Verwendung des ausgewählten Kommunikationsprotokolls, um Statusinformation des überwachten Geräts zu erhalten; Instruktionen zum Auswählen eines Implementationsbezeichners (502, 504, 506) unter der Vielzahl von Implementationsbezeichnern; Instruktionen zum Zugreifen auf eine externe Informationsspeichereinheit (904), um Supportinformation zu erhalten zum Zugreifen auf das überwachte Gerät unter Verwendung von mindestens einer der ersten Zugriffsfunktion und der zweiten Zugriffsfunktion unter Verwendung des ausgewählten Kommunikationsprotokolls; und Instruktionen zum Speichern (512) der Supportinformation in mindestens einer internen Speichertabelle, dadurch gekennzeichnet, dass die Supportinformation Vorbedingungsinformation umfasst, die verwendet wird, um die Status- oder die Anbieter- und Modellinformation vom überwachten Gerät zu erhalten, und wobei in der Information, die vom überwachten Gerät erhalten werden kann, eine Ortsangabe der Vorbedingungsinformation eine Ortsangabe einschränkt vom Typ von interessierender Information, die vom überwachten Gerät erhalten werden kann.
  13. Computerprogramm-Erzeugnis gemäß Anspruch 12, wobei die Instruktionen zum Speichern (512) umfassen: Instruktionen zum Speichern der Vorbedingungsinformation in Verbindung mit der Anbieter- und Modellinformation in einer internen Speichertabelle, die konfiguriert ist, um zum Erhalten eines eindeutigen Bezeichners vom überwachten Gerät verwendet zu werden.
  14. Computerprogramm-Erzeugnis gemäß Anspruch 12, wobei die Instruktionen zum Speichern (512) umfassen: Instruktionen zum Speichern der Vorbedingungsinformation in Verbindung mit der Anbieter- und Modellinformation in einer internen Speichertabelle, die konfiguriert ist, um zum Erhalten der Statusinformation vom überwachten Gerät verwendet zu werden.
  15. Computerprogramm-Erzeugnis, wobei die Instruktionen zum Speichern (512) umfassen: Informationen zum Speichern der Vorbedingungsinformation in Verbindung mit der Anbieterinformation in einer internen Speichertabelle, die konfiguriert ist, um zum Erhalten der Modellinformation vom überwachten Gerät verwendet zu werden.
  16. Computerprogramm-Erzeugnis gemäß Anspruch 12, weiter gekennzeichnet durch: Instruktionen zum Zugreifen auf das überwachte Gerät unter Verwendung der ersten Zugriffsfunktion, die assoziiert ist, mit dem ausgewählten Implementationsbezeichner, unter Verwendung der Vorbedingungsinformation, die in der internen Speichertabelle gespeichert ist, um Anbieter- und Modellinformation zu erhalten, die sich auf das überwachte Gerät bezieht.
DE602006000826T 2005-01-11 2006-01-11 Verfahren und System zum Extrahieren von Informationen von Netzwerkgeräten unter Verwendung mehrerer Protokollzugriffsfunktionen Active DE602006000826T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/032,063 US20060155845A1 (en) 2005-01-11 2005-01-11 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
US32063 2005-01-11

Publications (2)

Publication Number Publication Date
DE602006000826D1 DE602006000826D1 (de) 2008-05-15
DE602006000826T2 true DE602006000826T2 (de) 2009-05-07

Family

ID=36242053

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602006000826T Active DE602006000826T2 (de) 2005-01-11 2006-01-11 Verfahren und System zum Extrahieren von Informationen von Netzwerkgeräten unter Verwendung mehrerer Protokollzugriffsfunktionen

Country Status (4)

Country Link
US (1) US20060155845A1 (de)
EP (1) EP1679824B1 (de)
JP (1) JP2006244464A (de)
DE (1) DE602006000826T2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015121737A1 (de) * 2015-12-14 2017-06-14 HIM solutions UG Adaptervorrichtung für eine Netzwerkvorrichtung

Families Citing this family (16)

* 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
US7287085B1 (en) * 2000-05-17 2007-10-23 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 intelligent formatter
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
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
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
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
US7359969B2 (en) * 2004-08-09 2008-04-15 Ricoh Company, Ltd. System and method to provide integrated device, user, and account information to users
US7552111B2 (en) * 2006-09-08 2009-06-23 Ricoh Co., Ltd. System, method, and computer program product for identification of vendor and model name of a remote device among multiple network protocols
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
US7664886B2 (en) * 2006-09-08 2010-02-16 Ricoh Co., Ltd. System, method, and computer program product using an SNMP implementation to obtain vendor information from remote devices
US7574489B2 (en) * 2006-09-08 2009-08-11 Ricoh Co., Ltd. System, method, and computer program product for extracting information from remote devices through the HTTP protocol
WO2008078192A2 (en) * 2006-12-22 2008-07-03 Clear Blue Security, Llc Agent management system
US20090204702A1 (en) * 2008-02-08 2009-08-13 Autiq As System and method for network management using self-discovering thin agents
JP2010282610A (ja) * 2009-05-07 2010-12-16 Canon Inc ネットワークシステム及びその管理方法
CA2826047C (en) 2011-01-28 2016-08-30 The Dun And Bradstreet Corporation Inventory data access layer

Family Cites Families (24)

* 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
JP3760362B2 (ja) * 1998-08-28 2006-03-29 株式会社リコー サーバ装置
US6317848B1 (en) * 1998-09-24 2001-11-13 Xerox Corporation System for tracking and automatically communicating printer failures and usage profile aspects
US6658586B1 (en) * 1999-10-07 2003-12-02 Andrew E. Levi Method and system for device status tracking
US6571285B1 (en) * 1999-12-23 2003-05-27 Accenture Llp Providing an integrated service assurance environment for a network
US6415277B1 (en) * 2000-01-10 2002-07-02 Imagex, Inc. Method of generating print production tasks using information extracted from enterprise databases
US7640334B2 (en) * 2000-01-18 2009-12-29 Frontrange Solutions Network resource location detection probe apparatus and method
US6757714B1 (en) * 2000-07-28 2004-06-29 Axeda Systems Operating Company, Inc. Reporting the state of an apparatus to a remote computer
EP1206088B1 (de) * 2000-10-24 2010-03-31 Ricoh Company, Ltd. Vorrichtung, Verfahren und Programmprodukt zur Erfassung und Bereitstellung von Information
US20020152292A1 (en) * 2001-01-09 2002-10-17 Ricoh Company Limited Method and system of remote support of device using e-mail
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
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
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
US20030084176A1 (en) * 2001-10-30 2003-05-01 Vtel Corporation System and method for discovering devices in a video network
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
JP3814587B2 (ja) * 2002-04-22 2006-08-30 キヤノン株式会社 情報処理装置及び情報処理方法及びプログラム及び記憶媒体
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
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
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
US7437452B2 (en) * 2003-02-26 2008-10-14 Ricoh Company, Ltd. Method and system for monitoring network connected devices with multiple protocols
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
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

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015121737A1 (de) * 2015-12-14 2017-06-14 HIM solutions UG Adaptervorrichtung für eine Netzwerkvorrichtung
DE102015121737B4 (de) 2015-12-14 2019-04-25 HIM solutions UG Adaptervorrichtung für eine Netzwerkvorrichtung

Also Published As

Publication number Publication date
EP1679824A1 (de) 2006-07-12
JP2006244464A (ja) 2006-09-14
US20060155845A1 (en) 2006-07-13
DE602006000826D1 (de) 2008-05-15
EP1679824B1 (de) 2008-04-02

Similar Documents

Publication Publication Date Title
DE602006000709T2 (de) Überwachungseinrichtung mit einem Speicher,der Zugangsdaten zur Verwendung in verschiedenen Implementierungen von Protokollzugangsfunktionen für Informationsbeschaffung von vernetzten Geräten beinhaltet
DE602006000826T2 (de) Verfahren und System zum Extrahieren von Informationen von Netzwerkgeräten unter Verwendung mehrerer Protokollzugriffsfunktionen
DE602004002169T2 (de) Verfahren und System zur Unterstützung von Mehrfach-Protokollen für die Überwachung von vernetzten Geräten in einem Fernüberwachungssystem
US9674066B2 (en) 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) 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) Method for efficiently extracting status information related to a device coupled to a network in a multi-protocol remote monitoring system
US7296079B2 (en) Method and system for initializing protocol information used to extract status information from networked devices
DE60205998T2 (de) System und Verfahren zum Senden von Gerätekonfigurationsinformation an eine Überwachungseinheit über e-mail
US7610372B2 (en) Method and system for managing vendor and model information in a multi-protocol remote monitoring system
US7467195B2 (en) Method and system for extracting status information from networked devices using the SNMP protocol
US7664886B2 (en) System, method, and computer program product using an SNMP implementation to obtain vendor information from remote devices
US7606894B2 (en) Method and system for determining the type of status information to extract from networked devices in a multi-protocol remote monitoring system
US7437452B2 (en) Method and system for monitoring network connected devices with multiple protocols
US7502848B2 (en) Method of creating a data processing object associated with a communication protocol used to extract status information related to a monitored device
US20040255023A1 (en) Method and system for extracting vendor and model information in a multi-protocol remote monitoring system
US20060155824A1 (en) Method and system for extracting information from networked devices using the HTTP protocol and precondition information
US20050071483A1 (en) Method and system for supporting multiple protocols used to monitor networked devices in a remote monitoring system
US20050177642A1 (en) Method and system for managing protocols used to obtain status information from a network device
US7512681B2 (en) Database for multiple implementation of HTTP to obtain information from devices
EP1679822A1 (de) Verfahren und Vorrichtung zur Informationsextraktion von vernetzten Geräten mit Hilfe von mehreren Protokollimplementierungen auf Zugriffsfunktionen
US7552111B2 (en) System, method, and computer program product for identification of vendor and model name of a remote device among multiple network protocols
US7533086B2 (en) System, method, and computer program product for obtaining vendor identification of a remote device of merged companies
US7610374B2 (en) Method of initializing a data processing object associated with a communication protocol used to extract status information related to a monitored device
US7574503B2 (en) Method and system for using abstract classes to extract status information from networked devices
US7899900B1 (en) Method and system for monitoring network connected devices with multiple protocols

Legal Events

Date Code Title Description
8364 No opposition during term of opposition