DE60311183T2 - Methode und Vorrichtung zur Unterstützung fernüberwachter Geräte verschiedener Hersteller - Google Patents

Methode und Vorrichtung zur Unterstützung fernüberwachter Geräte verschiedener Hersteller Download PDF

Info

Publication number
DE60311183T2
DE60311183T2 DE60311183T DE60311183T DE60311183T2 DE 60311183 T2 DE60311183 T2 DE 60311183T2 DE 60311183 T DE60311183 T DE 60311183T DE 60311183 T DE60311183 T DE 60311183T DE 60311183 T2 DE60311183 T2 DE 60311183T2
Authority
DE
Germany
Prior art keywords
monitored device
database
monitoring system
monitored
information
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.)
Expired - Lifetime
Application number
DE60311183T
Other languages
English (en)
Other versions
DE60311183D1 (de
Inventor
Tetsuro San Jose Motoyama
Avery San Jose 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 DE60311183D1 publication Critical patent/DE60311183D1/de
Application granted granted Critical
Publication of DE60311183T2 publication Critical patent/DE60311183T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0213Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/022Multivendor or multi-standard integration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks

Description

  • Die vorliegende Erfindung bezieht sich auf die Überwachung, Konfiguration oder Installation von Hardware auf einem Computersystem.
  • Computersysteme enthalten im Allgemeinen Hardware und Software. Die Hardware ist der eigentliche physikalische Berechnungsmechanismus, während die Software die Liste von Anweisungen ist, mit denen die Hardware betrieben wird. Üblicherweise enthalten Computersysteme eine Vielfalt von Hardwarevorrichtungen, die miteinander eine Schnittstelle bilden. Wenn Hardwarevorrichtungen miteinander eine Schnittstelle bilden, muss die Software, die die Hardware betreibt, so konfiguriert sein, dass sie eine Kommunikation zwischen den Hardwarevorrichtungen ermöglicht, damit die Hardwarevorrichtungen kooperativ arbeiten können. Außerdem ist es wünschenswert, dass Hardwarevorrichtungen überwacht werden. Für die Zwecke der Besprechung wird eine Hardwarevorrichtung, die konfiguriert oder überwacht, als Steuervorrichtung bezeichnet. Ebenso wird für die Zwecke der Besprechung die Hardwarevorrichtung, die konfiguriert wird, um kooperativ zu arbeiten oder um durch die Steuervorrichtung überwacht zu werden, als Kopplungsvorrichtung bezeichnet.
  • Wenn Hardwarevorrichtungen zu Beginn miteinander eine Schnittstelle bilden, ist es bei der Software, die die Vorrichtungen betreibt, häufig der Fall, dass sie unkonfiguriert bleibt, um einen kooperativen Betrieb zu ermöglichen. Dementsprechend konfiguriert ein erheblicher Teil von installierenden Computerhardware-Vorrichtungen die Software kollektiv. Bei einigen Anordnungen muss ein Anwender die Computerhardware von Hand konfigurieren, indem er die Computerhardware öffnet und Steckbrücken oder DIP-Schalter physikalisch einstellt. Bei einigen weiteren Anordnungen umfasst der Installationsprozess, dass der Anwender von einer Diskette Software lädt, um die Hardwarevorrichtungen zu konfigurieren. Es gab bei Computerhardware-Vorrichtungen auch Versuche, Software in sie zu integrieren, die Hardwarevorrichtungen automatisch konfigurieren kann. Jedoch bestehen im Hinblick auf die oben angegebenen Ansätze einige offenkundige Nachteile und Mängel.
  • Ein Nachteil besteht darin, dass eine automatische Hardwareinstallations-Software in ihrer Fähigkeit begrenzt ist, sich an neue Vorrichtungen oder neue Hersteller anzupassen, die in der Software nicht speziell programmiert wurden. Nach dem Stand der Technik ist eine automatische Konfiguration nicht möglich, falls die Steuervorrichtung das bestimmte Modell der Kopplungsvorrichtung nicht erkennt. Mit anderen Worten: Falls die Steuervorrichtung nicht so programmiert ist, dass sie das Modell einer Kopplungsvorrichtung antizipiert, dann ist eine automatische Hardwarekonfiguration nicht erfolgreich. In einem solchen Fall muss ein Anwender die Konfigurations-Kommunikationsmittel für die Hardwarevorrichtungen von Hand installieren.
  • Ein weiterer Nachteil nach dem Stand der Technik liegt darin, dass die Steuervorrichtung nicht in der Lage ist, Hardwarevorrichtungen teilweise zu konfigurieren, falls das bestimmte Modell der Kopplungsvorrichtung nicht identifiziert werden kann. Mit anderen Worten: Falls eine Steuervorrichtung ein bestimmtes Modell der Kopplungsvorrichtung nicht identifizieren kann, dann wird die Kopplungsvorrichtung nicht so konfiguriert, dass sie kooperativ arbeitet. Dies führt dazu, dass die unkonfigurierte Kopplungsvorrichtung nicht betriebsfähig und im Wesentlichen nutzlos ist.
  • Für Hardwarevorrichtungen, die sich in einem Netz befinden, ist es wünschenswert, dass sie für die Wartung, die Nutzung oder andere Zwecke überwacht werden. Jedoch war es angesichts der zwischen Herstellern und Modellen von Kopplungsvorrichtungen unterschiedlichen Kommunikationsmittel für eine Steuervorrichtung schwierig, mit verschiedenen Kopplungsvorrichtungen in einem Netz zu kommunizieren. Diese Nachteile hindern Netzadministratoren daran, entscheidende Informationen über das Verhalten und die Effizienz von Kopplungsvorrichtungen in einem Netz zu erhalten.
  • US 6.122.639 offenbart ein Netz, in dem Informationen über Vorrichtungen in dem Netz gesammelt werden.
  • US 6.349.306 offenbart eine Vorrichtung und ein Verfahren zum Überwachen von Parametern, die die Betriebseigenschaften einer Netzvorrichtung bestimmen.
  • Die vorliegende Erfindung bezieht sich auf ein Verfahren und ein System, um wenigstens eine an ein Netz angeschlossene Vorrichtung (überwachte Vorrichtung) unter Verwendung einer Steuereinheit zu überwachen.
  • In Übereinstimmung mit der vorliegenden Erfindung wird ein Verfahren geschaffen, um zu bestimmen, ob eine überwachte Vorrichtung durch ein Überwachungssystem in einem netzbasierten System, das das Überwachungssystem und mehrere überwachte Vorrichtungen, die über ein Netz kommunikativ gekoppelt sind, umfasst, unterstützt wird, wobei das Überwachungssystem mit einer ersten und einer zweiten Datenbank kommunikativ gekoppelt ist, wobei das Verfahren die folgenden Schritte umfasst:
    • (a) Abfragen der überwachten Vorrichtung, um einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten;
    • (b) Bestimmen, ob das Überwachungssystem so konfiguriert ist, dass es mit der überwachten Vorrichtung eine Schnittstelle bildet, unter Verwendung von in der ersten Datenbank gespeicherten Informationen;
    • (c) Bestimmen, ob die überwachte Vorrichtung durch das Überwachungssystem unterstützt wird, unter Verwendung von in der zweiten Datenbank, gespeicherten Informationen durch:
    • (i) Bestimmen, ob ein Hersteller der überwachten Vorrichtung durch das Überwachungssystem unterstützt wird,
    • (ii) Erhalten einer Seriennummer und/oder einer eindeutigen Kennung von der überwachten Vorrichtung, falls der Hersteller durch das Überwachungssystem unterstützt wird;
    • (iii) Erhalten einer MAC-Adresse der überwachten Vorrichtung, falls der Hersteller durch das Überwachungssystem nicht unterstützt wird; und
    • (iv) Zuweisen einer Zufallszahl zu der eindeutigen Kennung, falls die MAC-Adresse von der überwachten Vorrichtung nicht erhalten werden kann.
  • Gemäß einem weiteren Aspekt der Erfindung wird eine Vorrichtung zum Überwachen wenigstens einer überwachten Vorrichtung unter mehreren überwachten Vorrichtungen in einem netzbasierten System, die mit einem Netz kommunikativ gekoppelt sind, geschaffen, wobei die Vorrichtung umfasst:
    ein Überwachungssystem, das mit dem Netz kommunikativ gekoppelt ist;
    eine erste Datenbank und eine zweite Datenbank, die mit dem Überwachungssystem kommunikativ gekoppelt sind;
    Mittel, um die überwachte Vorrichtung abzufragen, um einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten;
    Mittel, um zu bestimmen, ob das Überwachungssystem so konfiguriert ist, dass es mit der überwachten Vorrichtung eine Schnittstelle bildet, unter Verwendung von in der ersten Datenbank gespeicherten Informationen;
    Mittel, um zu bestimmen, ob die überwachte Vorrichtung durch das Überwachungssystem unterstützt wird, unter Verwendung von in der zweiten Datenbank gespeicherten Informationen;
    Mittel, um zu bestimmen, ob ein Hersteller der überwachten Vorrichtung durch das Überwachungssystem unterstützt wird;
    Mittel, um eine Seriennummer und/oder eine eindeutige Kennung von der überwachten Vorrichtung zu erhalten, falls der Hersteller durch das Überwachungssystem unterstützt wird;
    Mittel, um eine MAC-Adresse der überwachten Vorrichtung zu erhalten, falls der Hersteller nicht durch das Überwachungssystem unterstützt wird; und
    Mittel, um der eindeutigen Kennung eine Zufallszahl zuzuweisen, falls die MAC-Adresse von der überwachten Vorrichtung nicht erhalten werden kann.
  • Gemäß einem weiteren Aspekt der Erfindung wird ein netzbasiertes System geschaffen, das eine überwachte Vorrichtung unter mehreren an ein Netz angeschlossenen Vorrichtungen besitzt, wobei das System umfasst:
    eine erste Datenbank und eine zweite Datenbank, die mit der Steuereinheit kommunikativ gekoppelt sind, wobei die zweite Datenbank Informationen speichert, um zu bestimmen, ob die überwachte Vorrichtung durch die Steuereinheit unterstützt wird;
    eine Steuereinheit, um die überwachte Vorrichtung zu überwachen, wobei die Steuereinheit eine Logik besitzt, um:
    die überwachte Vorrichtung abzufragen, um einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten;
    unter Verwendung eines hierarchischen Verfahrens zu bestimmen, ob das Überwachungssystem so konfiguriert ist, dass es mit der überwachten Vorrichtung eine Schnittstelle bildet, indem in der ersten Datenbank gespeicherte Informationen verwendet werden; und
    zu bestimmen, ob die überwachte Vorrichtung durch das Überwachungssystem unterstützt wird, unter Verwendung von in der zweiten Datenbank gespeicherten Informationen durch:
    • (i) Bestimmen, ob ein Hersteller der überwachten Vorrichtung durch das Überwachungssystem unterstützt wird,
    • (ii) Erhalten einer Seriennummer und/oder einer eindeutigen Kennung von der überwachten Vorrichtung, falls der Hersteller durch das Überwachungssystem unterstützt wird;
    • (iii) Erhalten einer MAC-Adresse der überwachten Vorrichtung, falls der Hersteller durch das Überwachungssystem nicht unterstützt wird; und
    • (iv) Zuweisen einer Zufallszahl zu der eindeutigen Kennung, falls die MAC-Adresse von der überwachten Vorrichtung nicht erhalten werden kann,
    wobei Konfigurationsinformationen in der ersten Datenbank mit in der zweiten Datenbank gespeicherten Informationen aktualisiert werden, um die Steuereinheit in die Lage zu versetzen, mit der überwachten Vorrichtung eine Schnittstelle zu bilden, um dadurch eine Flexibilität bei der Aktualisierung von durch das Überwachungssystem überwachten Vorrichtungen unter mehreren Vorrichtungen zu ermöglichen.
  • Es werden ein Verfahren und eine Vorrichtung zum Bereitstellen einer Mehrfach-Anbieter-Unterstützung für fernüberwachte Vorrichtungen beschrieben. Das Verfahren umfasst das Abfragen einer überwachten Vorrichtung, um einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten; die Verwendung eines hierarchischen Verfahrens, um unter Verwendung von in einer ersten Datenbank gespeicherten Informationen zu bestimmen, ob das Überwachungssystem so konfiguriert ist, dass es mit der überwachten Vorrichtung eine Schnittstelle bildet; und das Bestimmen, unter Verwendung von in einer zweiten Datenbank gespeicherten Informationen, ob die überwachte Vorrichtung durch das Überwachungssystem unterstützt wird. Das hierarchische Verfahren umfasst das erste Bestimmen, ob der Hersteller der überwachten Vorrichtung durch das Überwachungssystem unterstützt wird, und dann das nachfolgende Bestimmen, ob das Modell der Vorrichtung durch das Überwachungssystem unterstützt wird.
  • In beispielhaften Ausführungsformen der vorliegenden Erfindung werden mehrere Datenbanken dazu verwendet, Vorrichtungen mit Systemen zu konfigurieren. Diese Ausführungsformen sind vorteilhaft, da während der Initialisierung der Vorrichtungen mit einem System wertvolle Computerressourcen verwendet werden, während die Computerressourcen während des Systembetriebs bewahrt werden. Beispielsweise kann ein System zwei separate Datenbanken verwenden, wenn eine Vorrichtung konfiguriert wird. Die erste Datenbank (d. h. eine Systemkonfigurations-Datenbank) speichert Vorrichtungsinformationen für Vorrichtungen, die bereits für das System konfiguriert sind und wobei betriebsbezogene Statusinformationen der Vorrichtungen gespeichert werden, während die Vorrichtungen durch das System überwacht werden. Derartige Vorrichtungsinformationen können den Herstellernamen und den Modellnamen umfassen, während betriebsbezogene Statusinformationen die Seitenzählung und den Tonerfüllstand umfassen können.
  • Die in der ersten Datenbank gespeicherten Vorrichtungsinformationen werden im Lauf der Initialisierung des Systems verwendet, während die in der ersten Datenbank gespeicherten Statusinformationen während des Systembetriebs gesammelt werden. Daher ist die erste Datenbank groß, da sie Statusinformationen aufnimmt. Der Bedarf an Computerressourcen ist jedoch geringer, da die Vorrichtungsinformationen im Lauf der Initialisierung verwendet werden, während Statusinformationen nur hinzugefügt werden, wenn das System in Betrieb ist.
  • Bei einer beispielhaften Ausführungsform der vorliegenden Erfindung verwendet das System der vorliegenden Erfindung auch eine zweite Datenbank (d. h. eine Systemunterstützungs-Datenbank). Diese zweite Datenbank kann relativ groß sein, da sie Daten enthält, die sich auf mehrere Vorrichtungen beziehen. Wenn eine Vorrichtung mit einem System initialisiert wird und das System noch nicht so konfiguriert ist, dass es mit der Vorrichtung eine Schnittstelle bildet, dann kann die erste Datenbank (d. h. die Systemkonfigurations-Datenbank) unter Verwendung der Informationen aus der zweiten Datenbank (d. h. der Systemunterstützungs-Datenbank) aktualisiert werden, sodass die Vorrichtung mit dem System eine Schnittstelle bilden kann. Auf Grund der großen Menge an gespeicherten Informationen ist das Abfragen der zweiten Datenbank nicht nur zeitraubend, sondern verwendet auch eine große Menge an wertvollen Computerressourcen. Sobald die kritischen Informationen (d. h. das Protokoll), die sich auf die Vorrichtung beziehen, in der ersten Datenbank mit Informationen aus der zweiten Datenbank aktualisiert sind, wird nur die erste Datenbank verwendet.
  • Bei einem Aspekt schafft die vorliegende Erfindung in einem netzbasierten System, das ein Überwachungssystem und mehrere über ein Netz kommunikativ gekoppelte überwachte Vorrichtungen aufweist, wobei das Überwachungssystem mit der ersten und der zweiten Datenbank kommunikativ gekoppelt ist, ein Verfahren zum Bestimmen, ob eine überwachte Vorrichtung durch das Überwachungssystem unterstützt wird, wobei das Verfahren umfasst: Abfragen der überwachten Vorrichtung, um einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten; Bestimmen, ob das Überwachungssystem so konfiguriert ist, dass es unter Verwendung von in der ersten Datenbank gespeicherten Informationen mit der überwachten Vorrichtung eine Schnittstelle bildet; und Bestimmen, ob die überwachte Vorrichtung unter Verwendung von in der zweiten Datenbank gespeicherten Informationen durch das Überwachungssystem unterstützt wird.
  • Der Schritt des Bestimmens, ob das Überwachungssystem so konfiguriert ist, dass es mit der überwachten Vorrichtung eine Schnittstelle bildet, erfolgt durch Abfragen der ersten Datenbank mit einem Hersteller und/oder einem Modell und/oder einer eindeutigen Kennung, die von der überwachten Vorrichtung erhalten werden. Der Schritt des Bestimmens, ob die überwachte Vorrichtung durch das Überwachungssystem unterstützt wird, umfasst das Bestimmen, ob ein Hersteller der überwachten Vorrichtung durch das Überwachungssystem unterstützt wird, und falls dies zutrifft: Bestimmen, ob ein Modell der überwachten Vorrichtung durch das Überwachungssystem unterstützt wird; und Aktualisieren der ersten Datenbank mit Hersteller- und Modellinformationen, falls die überwachte Vorrichtung durch das Überwachungssystem unter Verwendung von in der zweiten Datenbank gespeicherten Informationen unterstützt wird.
  • Das oben erwähnte Verfahren umfasst ferner das Erhalten einer Seriennummer und/oder einer eindeutigen Kennung von der überwachten Vorrichtung, falls der Hersteller durch das Überwachungssystem unterstützt wird; das Erhalten einer MAC-Adresse der überwachten Vorrichtung, falls der Hersteller durch das Überwachungssystem nicht unterstützt wird; und das Zuweisen einer Zufallszahl zur eindeutigen Kennung, falls die MAC-Adresse von der überwachten Vorrichtung nicht erhalten werden kann. Das Verfahren umfasst ferner das Auflisten der überwachten Vorrichtung als namenlos, falls der Hersteller der überwachten Vorrichtung durch das Überwachungssystem nicht unterstützt wird; das Erhalten von Informationen, die den mehreren überwachten Vorrichtungen gemeinsam sind, von der überwachten Vorrichtung; und das Erhalten von Informationen, die mehreren überwachten Vorrichtungen von dem allgemeinen Hersteller gemeinsam sind.
  • Das Verfahren umfasst ferner das Erhalten von Informationen, die für die überwachte Vorrichtung eindeutig sind, falls das Modell der überwachten Vorrichtung durch das Überwachungssystem unterstützt wird; und das Erhalten von Informationen, die überwachten Vorrichtungen gemeinsam sind, die durch den allgemeinen Hersteller hergestellt werden. Die erste Datenbank ist eine Systemkonfigurations-Datenbank, die umfasst: Informationen zum Freigeben einer Kommunikation zwischen dem Überwachungssystem und der überwachten Vorrichtung; und Statusinformationen, die auf die überwachte Vorrichtung bezogen sind, wobei die Statusinformationen nach der Initialisierung des Überwachungssystems hinzugefügt werden.
  • Der Schritt des Bestimmens, ob das Überwachungssystem so konfiguriert ist, dass es mit der überwachten Vorrichtung eine Schnittstelle bildet, umfasst das Abfragen der überwachten Vorrichtung mit in der ersten Datenbank gespeicherten Daten. Die erste Datenbank ist eine Systemkonfigurations-Datenbank und umfasst: Informationen, um eine Kommunikation zwischen dem Überwachungssystem und der überwachten Vorrichtung freizugeben; und Statusinformationen, die auf die überwachte Vorrichtung bezogen sind, wobei die Statusinformationen nach der Initialisierung des Überwachungssystems hinzugefügt werden, um die überwachte Vorrichtung zu überwachen. Die zweite Datenbank ist eine Systemunterstützungs-Datenbank und umfasst Informationen über verschiedene Her steller und Vorrichtungsmodelle, die durch das Überwachungssystem unterstützt werden.
  • Bei einem weiteren Aspekt schafft die vorliegende Erfindung in einem netzbasierten System, das mehrere mit einem Netz kommunikativ gekoppelte überwachte Vorrichtungen aufweist, eine Vorrichtung zum Überwachen wenigstens einer überwachten Vorrichtung unter den mehreren überwachten Vorrichtungen, wobei die Vorrichtung umfasst: ein Überwachungssystem, das mit dem Netz kommunikativ gekoppelt ist; eine erste Datenbank und eine zweite Datenbank, die mit dem Überwachungssystem kommunikativ gekoppelt sind; Mittel, um die überwachte Vorrichtung abzufragen, um einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten; Mittel, um zu bestimmen, ob das Überwachungssystem so konfiguriert ist, dass es mit der überwachten Vorrichtung eine Schnittstelle bildet, unter Verwendung von in der ersten Datenbank gespeicherten Informationen; und Mittel, um zu bestimmen, ob die überwachte Vorrichtung durch das Überwachungssystem unterstützt wird, unter Verwendung von in der zweiten Datenbank gespeicherten Informationen.
  • Bei einem wiederum weiteren Aspekt schafft die vorliegende Erfindung ein netzbasiertes System, das ein Überwachungssystem und mehrere über ein Netz kommunikativ gekoppelte überwachte Vorrichtungen aufweist, wobei das Überwachungssystem mit einer ersten und einer zweiten Datenbank und einem Computerprogrammprodukt innerhalb eines computernutzbaren Mediums kommunikativ gekoppelt ist, das umfasst: Anweisungen zum Abfragen der überwachten Vorrichtung, um einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten; Anweisungen zum Bestimmen, ob das Überwachungssystem so konfiguriert ist, dass es mit der überwachten Vorrichtung eine Schnittstelle bildet, unter Verwendung von in der ersten Datenbank gespeicherten Informationen; und Anweisungen zum Bestimmen, ob die überwachte Vorrichtung durch das Überwachungssystem unterstützt wird, unter Verwendung von in der zweiten Datenbank gespeicherten Informationen.
  • Bei einem zusätzlichen Aspekt schafft die vorliegende Erfindung ein netzbasiertes System, das eine überwachte Vorrichtung unter mehreren an ein Netz angeschlossenen Vorrichtungen aufweist, wobei das System umfasst: eine erste Datenbank und eine zweite Datenbank, die mit der Steuereinheit kommunikativ gekoppelt sind, wobei die zweite Datenbank Informationen speichert, um zu bestimmen, ob die überwachte Vorrichtung durch die Steuereinheit unterstützt wird; eine Steuereinheit, um die überwachte Vorrichtung zu überwachen, wobei die Steuereinheit eine Logik besitzt, um: die überwachte Vorrichtung abzufragen, um einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten; unter Verwendung eines hierarchischen Verfahrens zu bestimmen, ob das Überwachungssystem so konfiguriert ist, dass es mit der überwachten Vorrichtung eine Schnittstelle bildet, indem in der ersten Datenbank gespeicherte Informationen verwendet werden; und zu bestimmen, ob die überwachte Vorrichtung durch das Überwachungssystem unterstützt wird, unter Verwendung von in der zweiten Datenbank gespeicherten Informationen; und wobei Konfigurationsinformationen in der ersten Datenbank mit in der zweiten Datenbank gespeicherten Informationen aktualisiert werden, um die Steuereinheit in die Lage zu versetzen, mit der überwachten Vorrichtung eine Schnittstelle zu bilden, um dadurch eine Flexibilität bei der Aktualisierung von durch das Überwachungssystem überwachten Vorrichtungen unter mehreren Vorrichtungen zu ermöglichen.
  • Ein Vorteil der vorliegenden Erfindung umfasst die Leichtigkeit, mit der die Vorrichtungen zu verändern sind, die das System unterstützt, indem die Datenbank anstatt das System modifiziert wird.
  • Ein vollständigeres Verständnis der vorliegenden Erfindung und vieler der mit ihr verknüpften Vorteile ist leicht zu erhalten, wenn sie mit Bezug auf die nachfolgende ausführliche Beschreibung besser verstanden wird, wobei sie im Zusammenhang mit der beigefügten Zeichnung betrachtet wird.
  • 1 ist ein Schaltbild, das die Netzverknüpfung der Vorrichtung 2 und des Systems 8 bei einer beispielhaften Ausführungsform der vorliegenden Erfindung veranschaulicht;
  • 2 ist ein beispielhafter Ablaufplan, der die erforderlichen Schritte beim Bestimmen veranschaulicht, ob das System 8 so konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet;
  • 3 ist ein beispielhafter Ablaufplan, der die erforderlichen Schritte beim Bestimmen, unter Verwendung der Systemkonfigurations-Datenbank 6, veranschaulicht, ob das System 8 so konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet;
  • 4 ist eine beispielhafte Veranschaulichung eines hierarchischen Ansatzes zum Bestimmen, ob die Vorrichtung 2 durch das System 8 unterstützt wird;
  • 5 veranschaulicht Softwareobjekte in einer beispielhaften Ausführungsform der vorliegenden Erfindung;
  • 6 veranschaulicht ein beispielhaftes Sequenzdiagramm beim Initialisieren des Systems, um Informationen über Objektkennungen zu erhalten, die dazu dienen, den Hersteller, das Modell und eine eindeutige Kennung zu identifizieren, und um Informationen über die durch das System unterstützten Hersteller und Modelle zu erhalten;
  • 7 veranschaulicht ein beispielhaftes Sequenzdiagramm zum Erzeugen von Vorrichtungsobjekten, um die überwachten Vorrichtungen während der Initialisierung darzustellen;
  • 8 zeigt das Sequenzdiagramm zum Ausführen der Funktion setAgent() 122 von VendorModel 118;
  • 9 ist ein beispielhafter Ablaufplan für die Funktion setAgent() von VendorModel;
  • 10 erläutert beispielhaft ein Sequenzdiagramm, wenn das System Informationen erhält, die dazu dienen, die Statusinformationen für den bestimmten Hersteller und das bestimmte Modell der überwachten Vorrichtungen zu erhalten;
  • 11 zeigt den Ablaufplan für die Funktion createDevice() von DeviceFactory;
  • 12 zeigt das Sequenzdiagramm zum Ausführen der Funktion monitor-Status();
  • 13 zeigt das Sequenzdiagramm zum Ausführen der Funktion getStatus() 214 von Device 210;
  • 14 zeigt die Tabellen einer Datenbank, die Informationen über die durch das System unterstützten Hersteller und Modelle enthält;
  • 15 zeigt ein Beispiel für die Inhalte in den Tabellen der Datenbank, wie sie in 14 beschrieben ist; und
  • 16 zeigt das Klassendiagramm für das ODBC2-Paket.
  • 1 ist ein Schaltbild, das die Netzverknüpfung der Vorrichtung 2 und des Systems 8 veranschaulicht. Die Vorrichtung 2 bildet mit dem System 8 über das Netz 4 eine Schnittstelle. Das System 8 ist mit der Systemkonfigurations-Datenbank (SCD) 6 und der Systemunterstützungs-Datenbank (SSD) 10 gekoppelt. Das Netz 4 kann irgendein Typ von Kommunikationsstruktur sein, der es der Vorrichtung 2 und dem System 8 ermöglicht, Daten auszutauschen. Beispielsweise kann das Netz 4 entweder ein Weitverkehrsnetz (WAN), ein lokales Netz (LAN) oder ein einfaches Kabel sein, das die Vorrichtung 2 und das System 8 physikalisch verbindet. Es ist klar, dass die vorliegende Erfindung nicht durch den Typ von Netzen beschränkt ist und dass andere Netze verwendet werden können, um eine Kommunikation zwischen der Vorrichtung 2 und dem System 8 zu ermöglichen.
  • Die Systemkonfigurations-Datenbank 6 enthält Informationen eines ersten und eines zweiten Typs. Der erste Typ von Informationen sind Konfigurations- oder Vorrichtungsinformationen, wie beispielsweise Herstellername, Modellname, IP-Adresse, Firmenname, Name der Kontaktperson und E-Mail-Adresse der Kontaktperson, um nur einige zu nennen. Die Konfigurationsinformationen werden nur während der Initialisierung des Systems 8 verwendet, um zu bestimmen, welche Vorrichtungen überwacht werden müssen. Die Systemkonfigurations-Datenbank 6 enthält jedoch keine Informationen darüber, welches Protokoll zu verwenden ist, um mit der Vorrichtung 2 zu kommunizieren. Die SCD 6 enthält jedoch für die Kommunikation notwendige Informationen wie beispielsweise die IP-Adresse. Daher enthält die SCD 6 Informationen, die der Bestimmung dienen, ob das System 8 so konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet. Der zweite Typ von in der SCD 6 gespeicherten Informationen sind Statusinformationen. Beispiele für Statusinformationen umfassen Seitenzählung, Fehlerstatus und Tonerfüllstand. Statusinformationen werden nach der Initialisierung des Systems 8 zur Datenbank (SCD 6) hinzugefügt, wenn das System 8 Vorrichtungen überwacht, die am Netz 4 angeschlossen sind. Die Systemkonfigurations-Datenbank (SCD 6) ist nicht direkt von der Systemunterstützungs-Datenbank (SSD 10) abhängig.
  • Die SSD 10 enthält Informationen über Hersteller und Modelle, die durch das System 8 unterstützt werden. Obwohl dieses System alle Vorrichtungen, ungeachtet des Herstellers oder des Modells, unterstützen kann, hängt die Menge von Statusinformationen, die von der Vorrichtung 2 erhalten werden, von Herstellern und Modellen ab, die durch die SSD 10 unterstützt werden. Wenn der Hersteller und das Modell durch die SSD 10 unterstützt werden, dann können von der Vorrichtung 2 detaillierte Statusinformationen erhalten werden. Dadurch bestimmt die SSD 10, welcher Typ von Statusinformationen in der Systemkonfigurations-Datenbank (SCD 6) gespeichert ist.
  • Informationen sowohl von der SCD 6 als auch von der SSD 10 dienen dazu, Vorrichtungsobjekte zu erzeugen, um die Vorrichtungen darzustellen, die überwacht werden. Obwohl eine einzelne Vorrichtung 2 als am Netz 4 angeschlossen gezeigt ist, ist es klar, dass am Netz 4 mehrere Vorrichtungen angeschlossen sein können, die überwacht werden müssen. Die Vorrichtungsobjekte ermöglichen es dem System 8, mit der Vorrichtung 2 zu kommunizieren und zu bestimmen, welche Informationen von den Vorrichtungen zu erhalten sind.
  • 2 ist ein beispielhafter Ablaufplan, der veranschaulicht, wie bestimmt wird, ob das System 8 so konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet. Im Block 12 bestimmt das System 8 oder irgendeine andere Vorrichtung, die Teil des Netzes 4 ist, ob das System 8 so konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet. Beispielsweise wird bestimmt, ob das System 8 mit Software programmiert ist, die es dem System 8 ermöglicht, mit der Vorrichtung 2 zu kommunizieren. Mit anderen Worten: Das System 8 verwendet ein Protokoll, das mit der Vorrichtung 2 kompatibel ist, sodass das System 8 und die Vorrichtung 2 Daten austauschen und kooperativ arbeiten können. Beim Bestimmen, ob das System 8 so konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet, erhält das System 8 auch Konfigurationsinformationen von der Vorrichtung 2 und bestimmt, ob die Vorrichtung 2 durch das System 8 unterstützt wird.
  • Wenn im Block 14 bestimmt wird, dass das System 8 so konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet, dann wird im Block 20 zwischen dem System 8 und der Vorrichtung 2 ein Kommunikationsprotokoll aufgebaut, das auf Informationen beruht, die in der Systemunterstützungs-Datenbank 10 gespeichert sind. Im Block 22 wird die Systemkonfigurations-Datenbank (SCD 6) mit den Konfigurationsdaten aktualisiert, die erhalten wurden, als bestimmt wurde, ob das System 8 so konfiguriert wurde, dass es mit der Vorrichtung 2 eine Schnittstelle bildet. Wenn im Block 14 jedoch bestimmt wird, dass das System 8 nicht so konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet, dann endet der Prozess, und die Vorrichtung 2 bildet mit dem System 8 keine Schnittstelle.
  • 3 ist ein beispielhafter Ablaufplan, der veranschaulicht, wie unter Verwendung der Systemkonfigurations-Datenbank (SCD 6) bestimmt wird, ob das System 8 so konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet. Im Block 24 wird die Vorrichtung 2 unter Verwendung eines üblichen Kommunikationsprotokolls abgefragt, um ihren Hersteller, das Modell und/oder die eindeutige Kennung zu bestimmen.
  • Wenn im Block 26 der Hersteller, das Modell oder die eindeutige Kennung der Vorrichtung bestimmt wird, dann geht der Prozess zum Block 36 über, andernfalls geht der Prozess zum Block 28 über. Im Block 36 wird bestimmt, dass das System so konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet.
  • Im Block 28 wird die Vorrichtung 2 unter Verwendung von in der Systemkonfigurations-Datenbank 6 gespeicherten Daten abgefragt, um den Hersteller, das Modell und/oder die eindeutige Kennung der Vorrichtung 2 zu bestimmen. Im Block 34 wird bestimmt, ob der Hersteller, das Modell und/oder die eindeutige Kennung der Vorrichtung 2 im Block 28 identifiziert wurden. Wenn die Bestimmung im Block 34 ein positives Ergebnis hat, dann wird im Block 36 bestimmt, dass das System so konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet. Wenn die Bestimmung im Block 34 ein negatives Ergebnis hat, dann wird im Block 38 bestimmt, dass das System nicht so konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet.
  • Beim Abfragen der Vorrichtung 2 nach den Hersteller- und Modellinformationen in den Blöcken 24 und 28 werden der Hersteller und das Modell der Vor richtung mit der Systemunterstützungs-Datenbank 10 überprüft, um zu bestimmen, ob der Hersteller und das Modell durch das System 8 unterstützt werden. Dies hat aber keinen Einfluss darauf, ob das System 8 so konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet, oder nicht.
  • Das Systemunterstützungs-Datenbank 10 dient zum Bestimmen, welche Statusinformationen von der Vorrichtung 2 zu erhalten sind, wenn sie durch das System 8 überwacht wird. Ein Vorrichtungsobjekt für die Vorrichtung 2 enthält Informationen aus der SSD 10 darüber, welche Statusinformationen zu erhalten sind. Wenn der Hersteller und das Modell der Vorrichtung in der SSD 10 nicht unterstützt werden, dann erhält das Vorrichtungsobjekt Statusinformationen, die allen am Netz 4 angeschlossenen Vorrichtungen zur Verfügung stehen. Wenn der Hersteller in der SSD 10 unterstützt wird, aber das Modell der Vorrichtung nicht unterstützt wird, dann erhält das Vorrichtungsobjekt Statusinformationen, die allen Vorrichtungen eines Herstellers zur Verfügung stehen. Wenn der Hersteller und das Modell unterstützt werden, dann erhält das Vorrichtungsobjekt Statusinformationen, die allen Vorrichtungen des Modells zur Verfügung stehen.
  • 4 ist eine beispielhafte Veranschaulichung eines hierarchischen Ansatzes zum Bestimmen, ob die Vorrichtung 2 durch das System 8 unterstützt wird. In den Blöcken 56 und 58 wird bestimmt, ob der Hersteller der Vorrichtung 2 durch das System 8 unterstützt wird. Wenn der Hersteller nicht unterstützt wird, dann wird im Block 60 bestimmt, dass die Vorrichtung so konfiguriert ist, dass sie ein namenloses Protokoll verwendet. Wenn der Hersteller unterstützt wird, dann geht der Prozess zum Block 62 über.
  • In den Blöcken 62 und 64 wird bestimmt, ob das Modell der Vorrichtung 2 durch das System 8 unterstützt wird. Wenn das Modell nicht unterstützt wird, dann wird im Block 66 bestimmt, dass die Vorrichtung 2 unter Verwendung eines herstellerspezifischen Protokolls zu konfigurieren ist. Wenn das Modell unterstützt wird, dann wird im Block 68 bestimmt, dass die Vorrichtung 2 unter Verwendung eines modellspezifischen Protokolls zu konfigurieren ist.
  • 5 veranschaulicht Softwareobjekte in einer beispielhaften Ausführungsform der vorliegenden Erfindung. Das Softwareobjekt SendInterfaceManager 70 bildet direkt oder indirekt Schnittstellen mit den Softwareobjekten DataTransfer 74, ODBC-1 72, DeviceFactory 76, VenderModel 78, ODBC-2 84, SNMP 80 und Device 82.
  • Tabelle 1 veranschaulicht die Funktionen der ODBC-1 72.
  • TABELLE 1
    Figure 00160001
  • Tabelle 2 veranschaulicht die Funktionen von DeviceFactory 76.
  • TABELLE 2
    Figure 00160002
  • Tabelle 3 veranschaulicht die Funktionen von DataTransfer 74.
  • TABELLE 3
    Figure 00170001
  • Tabelle 4 veranschaulicht die Funktionen von Device 82.
  • TABELLE 4
    Figure 00170002
  • Tabelle 5 veranschaulicht die Funktionen von ODBC-2 84.
  • TABELLE 5
    Figure 00180001
  • Tabelle 6 veranschaulicht die Funktionen von SNMP 80.
  • TABELLE 6
    Figure 00190001
  • VendorModel 78 ist für das Erhalten von Informationen über den Hersteller und das Modell der überwachten Vorrichtung verantwortlich. Dieses Softwareobjekt erhält den Hersteller, das Modell und die eindeutige Kennung der überwachten Vorrichtung. Die Klasse CVendorModel von VendorModel 78 verwendet Informationen aus der Datenbank, um die durch das System unterstützten Hersteller und Modelle zu bestimmen. Die Klasse verwendet auch Informationen aus der Datenbank, die erforderlich sind, um das Modell und die eindeutige Kennung von der überwachten Vorrichtung zu erhalten. Die öffentlichen und die privaten Funktionen von CVendorModel sind in der nachstehenden Tabelle 7 gezeigt.
  • TABELLE 7
    Figure 00200001
  • Figure 00210001
  • Die nachstehende Tabelle 8 zeigt die in den oben erwähnten Funktionen verwendeten Attribute der Klasse CVendorModel.
  • TABELLE 8
    Figure 00210002
  • Figure 00220001
  • ManufacturerAndModelInfo in m_ManufacturerAndModelInfoVector hat die folgende Struktur:

    struct ManufacturerAndModelInfo {
    std::string m_sManufacturer;
    std::string m_sEnterpriseOID;
    std::string m_sModelOID;
    std::string m_sUniqueOID;
    };
  • m_sManufacturer ist der Name des Herstellers. m_sEnterpriseOID ist die dem Hersteller zugeordnete Unternehmensobjekt-Kennung. Die Unternehmensobjekt-Kennung ist für einen Hersteller eindeutig. m_sModelOID ist die Objektkennung, die dazu dienen kann, den Modellnamen der Vorrichtung zu finden. m_sUniqueOID ist die Objektkennung, die dazu dienen kann, die eindeutige Kennung der Vorrichtung zu finden. Die eindeutige Kennung kann die Seriennummer oder die MAC-Adresse der Vorrichtung sein.
  • DeviceFactory 76 ist für das Erzeugen eines Vorrichtungsobjekts, das die überwachte Vorrichtung darstellt, verantwortlich. DeviceFactory 76 stellt sicher, dass dem Vorrichtungsobjekt bekannt ist, welche Statusinformationen es erhalten muss. CDeviceFactory ist die einzige Klasse im Paket DeviceFactory 76. Die öffentlichen und die privaten Funktionen von CDeviceFactory sind in der nachstehenden Tabelle 9 gezeigt.
  • TABELLE 9
    Figure 00240001
  • Die nachstehende Tabelle 10 zeigt die in den oben erwähnten Funktionen verwendeten Attribute der Klasse CDeviceFactory.
  • TABELLE 10
    Figure 00250001
  • infoType ist eine Zahl, die in m_GenericDeviceVector und in m_ManufacturerVectorMap verwendet wird, die dazu dienen, einen bestimmten Typ von Statusinformationen darzustellen. Beispielsweise stellt 503 einen NoPaper-Zustand für die überwachte Vorrichtung dar, und 601 stellt die Seitenlebensdauer-Zählung der überwachten Vorrichtung dar.
  • Device 82 stellt eine überwachte Vorrichtung dar. Dies greift auf Statusinformationen der überwachten Vorrichtung zu. Statusinformationen enthalten Informationen wie etwa Fehlerstatus, Seitenzählung, Tonerkartuschenfüllstand und Warnungen. CDevice ist die einzige Klasse im Paket Device 82. Die öffentlichen Funktionen von CDevice sind in der nachstehenden Tabelle 11 gezeigt.
  • TABELLE 11
    Figure 00260001
  • Die nachstehende Tabelle 12 zeigt die in den oben erwähnten Funktionen verwendeten Attribute der Klasse CDevice.
  • TABELLE 12
    Figure 00270001
  • 6 veranschaulicht ein beispielhaftes Sequenzdiagramm beim Initialisieren des Systems, um Informationen über die Objektkennungen zu erhalten, die dazu dienen, den Hersteller, das Modell und die eindeutige Kennung zu identifizieren und Informationen über die durch das System unterstützten Hersteller und Modelle zu erhalten. VendorModel 86 wirkt mit ODBC2 88 zusammen, um diese Informationen zu erhalten. ODBC2 88 stellt eine Schnittstelle zur Datenbank bereit, um Informationen zu erhalten, die von VendorModel 86 aus ihr angefordert werden. VendorModel 86 ruft die Funktion getManufInfo() 90 von ODBC2 88 auf, um aus der Datenbank die Objektkennungen zu erhalten, die dazu dienen, den Hersteller, das Modell und die eindeutige Kennung der überwachten Vorrichtungen zu identifizieren. Diese Informationen werden im Vektor m_ManufacturerAndModelInfoVector gespeichert, der in der obigen Tabelle 8 beschrieben ist. getManufInfo() 90 wird mehrere Male aufgerufen, bis alle Objektkennungen für alle durch das System unterstützten Hersteller aus der Datenbank eingelesen sind. Dann ruft VendorModel 86 die Funktion getSupportedModel() 92 von ODBC2 88 auf, um den Hersteller und das Modell, die durch das System unterstützt werden, aus der Datenbank zu erhalten. Diese Informationen werden im Kennfeld m_ManufacturerModelMap gespeichert, das in der obigen Tabelle 8 beschrieben ist. getSupportedModel() wird mehrere Male aufgerufen, bis alle durch das System unterstützten Modelle aus der Datenbank eingelesen sind. Um die durch das System unterstützten Hersteller und Modelle zu entfernen, zu modifizieren oder hinzuzufügen, ist lediglich eine Änderung in der Datenbank notwendig, die Informationen über die unterstützten Hersteller und Modelle speichert. Es muss keine Änderung am System vorgenommen werden, wenn sich die durch das System unterstützten Hersteller und Modelle ändern. Die Informationen werden während der Initialisierung aus der Datenbank eingelesen.
  • 7 veranschaulicht ein beispielhaftes Sequenzdiagramm zum Erzeugen von Vorrichtungsobjekten, um die überwachten Vorrichtungen während der Initialisierung darzustellen. Zu Beginn versucht das System 8 (1), eine Kommunikation mit der Vorrichtung 2 aufzubauen. Wenn das System 8 nicht so konfiguriert werden kann, dass es mit der Vorrichtung 2 eine Schnittstelle bildet, werden Konfigurationsinformationen, wie etwa Hersteller, Modell und eine eindeutige Kennung, von der Vorrichtung 2 erhalten. Beim Prozess des Bestimmens der Konfigurationsinformationen erfolgt unter Verwendung von Informationen aus der Systemunterstützungs-Datenbank (SSD 10) eine Bestimmung, um festzustellen, ob die Vorrichtung 2 durch das System 8 unterstützt wird. Unter Verwendung von Informationen aus der SSD 10 wird ein Vorrichtungsobjekt erzeugt, wodurch ein Kommunikationsprotokoll zwischen dem System 8 und der Vorrichtung 2 aufgebaut wird – unabhängig davon, ob die Vorrichtung durch das System 8 unterstützt wird oder nicht. Anschließend werden in der Systemkonfigurations-Datenbank (SCD 6) Konfigurationsinformationen für die Vorrichtung 2 aktualisiert. SendIn terfaceManager 94 ruft getConfig() 102 von ODBC 96 auf. ODBC 96 stellt eine Schnittstelle zur Datenbank bereit, um Konfigurationsinformationen der überwachten Vorrichtungen zu erhalten. Die Konfigurationsinformationen umfassen Herstellernamen, Modellnamen und IP-Adresse der überwachten Vorrichtung sowie Namen, Telephonnummer und E-Mail-Adresse der Kontaktperson, die für die überwachte Vorrichtung verantwortlich ist. Die Datenbank enthält die Konfigurationsinformationen aller Vorrichtungen, die überwacht werden. Jedoch können nicht alle Vorrichtungen in dieser Datenbank durch das System unterstützt werden, wie in der Datenbank angegeben ist, die der ODBC2 84 von 5 zugeordnet ist.
  • SendInterfaceManager 94 ruft setAgent() 104 auf, wobei eine SNMP-Sitzung mit der überwachten Vorrichtung aufgebaut wird, um den Hersteller, das Modell und die eindeutige Kennung der Vorrichtung zu erhalten. Weitere Einzelheiten dieser Funktion sind in 8 angegeben. SendInterfaceManager 94 ruft getManufacturer() 106, getModel() 108 und getUniqueID() 110 von VendorModel 98 auf, um den Herstellernamen, den Modellnamen und die eindeutige Kennung der überwachten Vorrichtung zu erhalten. SendInterfaceManager 94 ruft createDevice() 112 von DeviceFactory 100 auf, um ein Vorrichtungsobjekt für die überwachte Vorrichtung zu erzeugen. Das Vorrichtungsobjekt wird von SendInterfaceManager 94 verwendet, um Statusinformationen der überwachten Vorrichtung zu erhalten. SendInterfaceManager 94 ruft updateConfig() von ODBC 96 auf, um die Konfigurationsinformationen in der Datenbank zu aktualisieren.
  • Sämtliche Schritte in der Sequenz werden wiederholt, bis alle überwachten Vorrichtungen in der Datenbank erhalten wurden. Für jede der überwachten Vorrichtungen wird ein Vorrichtungsobjekt erzeugt. SendInterfaceManager 94 bewahrt jedes der Vorrichtungsobjekte.
  • 8 zeigt das Sequenzdiagramm zum Ausführen der Funktion setAgent() 122 von VendorModel 118. SendInterfaceManager 116 ruft setAgent() 122 von VendorModel 118 auf. VendorModel 118 ruft setAgent() 124 von SNMP 120 auf. Diese Funktion baut eine SNMP-Sitzung zwischen dem System und der überwachten Vorrichtung auf. VendorModel 118 ruft seine eigene Funktion obtainManufacturer() 126 auf, um den Herstellernamen der überwachten Vorrichtung zu erhalten. In der Funktion obtainManufacturer() 126 ruft VendorModel 118 get- NetStringValueForOID() 128 von SNMP 120 auf, um die Unternehmensobjekt-Kennung über SNMP von der überwachten Vorrichtung zu erhalten. Die Unternehmensobjekt-Kennung dient dazu, den Hersteller der überwachten Vorrichtung zu identifizieren. VendorModel 118 ruft seine eigene Funktion obtainModel() 130 auf, um den Modellnamen der überwachten Vorrichtung zu erhalten. In der Funktion obtainModel() 130 ruft VendorModel 118 getNextStringValueForOID() 132 von SNMP 120 auf, um über SNMP den Modellnamen der überwachten Vorrichtung zu erhalten. VendorModel 118 ruft seine eigene Funktion obtainUniqueID() 134 auf, um die eindeutige Kennung der überwachten Vorrichtung zu erhalten. In der Funktion obtainUniqueID() 134 ruft VendorModel 118 getNextStringValueForOID() 136 von SNMP 120 auf, um über SNMP die eindeutige Kennung der überwachten Vorrichtung zu erhalten.
  • 9 ist ein beispielhafter Ablaufplan für die Funktion setAgent() von VendorModel. Im Schritt 140 werden die Variablen, die den Herstellernamen, den Modellnamen und die eindeutige Kennung darstellen, auf eine leere Zeichenfolge gesetzt. Diese Variablen sind m_sManufacturer, m_sModel und m_sUniqueID, wie in Tabelle 8 beispielhaft erläutert. Im Schritt 142 wird über SNMTP die Unternehmensobjekt-Kennung der überwachten Vorrichtung erhalten. Im Schritt 144 wird die von der überwachten Vorrichtung erhaltene Unternehmensobjekt-Kennung mit denjenigen verglichen, die durch das System unterstützt werden. Die Unternehmensobjekt-Kennung und der ihr entsprechende durch das System unterstützte Hersteller werden im Vektor m_ManufacturerAndModelInfoVector gespeichert, wie in Tabelle 8 beschrieben. Der Vektor wird durchsucht, um zu bestimmen, ob die Unternehmensobjekt-Kennung der überwachten Vorrichtung gefunden wird. Wenn die Unternehmensobjekt-Kennung im Vektor nicht gefunden werden kann, dann wird Schritt 156 als nächster abgearbeitet. Wenn die Unternehmensobjekt-Kennung im Vektor gefunden wird, dann wird der Hersteller der überwachten Vorrichtung durch das System unterstützt, und Schritt 146 wird als nächster abgearbeitet. Im Schritt 146 wird die Variable m_sManufacturer für den Herstellernamen auf den Herstellernamen gesetzt, der der Unternehmensobjekt-Kennung im Vektor entspricht. Im Schritt 148 werden die Variablen m_sCurrentModelOID und m_sCurrentUniqueOID für die Objektkennung, die dazu dienen, den Modellnamen und die eindeutige Kennung der überwachten Vorrichtung zu finden, auf die Objektkennungen gesetzt, die der Unternehmens objekt-Kennung im Vektor entsprechen. Im Schritt 150 wird der Modellname über SNMP unter Verwendung der Objektkennung m_sCurrentModelOID von der überwachten Vorrichtung erhalten.
  • Im Schritt 152 wird der von der überwachten Vorrichtung erhaltene Modellname mit denjenigen verglichen, die durch das System unterstützt werden. Der Hersteller und das Modell, die durch das System unterstützt werden, werden im Kennfeld m_ManufacturerModelMap gespeichert, wie in Tabelle 8 beschrieben. Das Kennfeld wird durchsucht, um zu bestimmen, ob das Modell im Kennfeld gefunden wird. Wenn das Modell nicht im Kennfeld gefunden werden kann, dann wird Schritt 156 als nächster abgearbeitet. Wenn das Modell im Kennfeld gefunden werden kann, dann wird das Modell der überwachten Vorrichtung durch das System unterstützt, und Schritt 154 wird als nächster abgearbeitet. Im Schritt 154 wird die Variable m_sModel für den Modellnamen auf den für die überwachte Vorrichtung erhaltenen Modellnamen gesetzt. Im Schritt 156 wird über SNMP unter Verwendung der Objektkennung m_sCurrentUniqueOID von der überwachten Vorrichtung die eindeutige Kennung erhalten. Dann wird die Variable m_sUniqueID für die eindeutige Kennung auf die von der überwachten Vorrichtung erhaltene eindeutige Kennung gesetzt.
  • Die Funktion setAgent() von VendorModel ermöglicht es dem System, über SNMP den Herstellernamen und den Modellnamen der überwachten Vorrichtung zu erhalten, um zu bestimmen, ob sie durch das System unterstützt wird. Außerdem ermöglicht sie es dem System, den Herstellernamen und den Modellnamen zu verifizieren.
  • 10 erläutert beispielhaft ein Sequenzdiagramm, wenn das System Informationen erhält, die dazu dienen, die Statusinformationen für den bestimmten Hersteller und das bestimmte Modell der überwachten Vorrichtungen zu erhalten. DeviceFactory 160 wirkt mit ODBC2 162 zusammen, um diese Informationen zu erhalten. ODBC2 162 stellt eine Schnittstelle zur Datenbank bereit, um Informationen zu erhalten, die von DeviceFactory 160 aus ihr angefordert werden. DeviceFactory 160 ruft die Funktion getManufStatusInfo() 164 von ODBC2 162 auf, um Informationen zu erhalten, die erforderlich sind, um über SNMP von überwachten Vorrichtungen die Statusinformationen für einen bestimmten Hersteller zu erhalten. Die Informationen enthalten eine Zahl (infoType), die irgend einen Typ von Statusinformationen und eine Objektkennung darstellt, die dazu dienen, über SNMP die Statusinformationen zu erhalten. getManufStatusInfo() 166 wird mehrere Male aufgerufen, bis aus der Datenbank die Informationen eingelesen sind, die erforderlich sind, um alle Statusinformationen für einen bestimmten Hersteller zu erhalten. Dann ruft DeviceFactory 160 die Funktion getModelStatusInfo() 168 von ODBC2 162 auf, um Informationen zu erhalten, die erforderlich sind, um über SNMP von überwachten Vorrichtungen Statusinformationen für ein bestimmtes Modell zu erhalten. Die Informationen enthalten eine Zahl (infoType), die irgendeinen Typ von Statusinformationen und eine Objektkennung darstellt, die dazu dienen, die Statusinformationen über SNMP zu erhalten. getModelStatusInfo() 170 wird mehrere Male aufgerufen, bis die Informationen, die erforderlich sind, um alle Statusinformationen für ein bestimmtes Modell zu erhalten, aus der Datenbank eingelesen sind. Diese Sequenz wird innerhalb der Funktion createDevice() von DeviceFactory aufgerufen, wenn ein Vorrichtungsobjekt für die überwachte Vorrichtung erzeugt wird. Diese Informationen werden zum Vorrichtungsobjekt hinzugefügt, wie in 11 beschrieben ist.
  • Durch Verwendung der Datenbank zum Speichern von Informationen, die dazu dienen, die zum Hersteller gehörenden Statusinformationen und die zum Modell gehörenden Statusinformationen zu erhalten, können Statusinformationen, die von den überwachten Vorrichtungen zu erhalten sind, ohne irgendwelche Änderungen am System leicht modifiziert, entfernt oder zur Datenbank hinzugefügt werden.
  • 11 zeigt den Ablaufplan für die Funktion createDevice() von DeviceFactory. Im Schritt 174 wird ein Vorrichtungsobjekt erzeugt, um die überwachten Vorrichtungen darzustellen. Im Schritt 176 wird ein Vektor, der Informationen enthält, die erforderlich sind, um Statusinformationen von Vorrichtungen von allen Herstellern zu erhalten, einem lokalen Vektor zugewiesen. Dieser Vektor entspricht dem in Tabelle 10 beschriebenen m_GenericDeviceVector. Im Schritt 178 wird der Herstellername der überwachten Vorrichtung überprüft, um festzustellen, ob er durch das System unterstützt wird (der Herstellername ist eine leere Zeichenfolge, wenn er durch das System nicht unterstützt wird). Wenn der Herstellername nicht unterstützt wird, dann wird Schritt 186 als nächster abgearbeitet. Wenn der Herstellername unterstützt wird, dann wird Schritt 180 als nächster abgearbeitet.
  • Im Schritt 180 werden Informationen, die erforderlich sind, um Statusinformationen von der überwachten Vorrichtung eines bestimmten Herstellers zu erhalten, aus einem Kennfeld erhalten und zu dem lokalen Vektor hinzugefügt. Das Kennfeld entspricht dem in Tabelle 10 beschriebenen ManufacturerVectorMap. Im Schritt 182 wird der Modellname der überwachten Vorrichtung überprüft, um festzustellen, ob er durch das System unterstützt wird (der Modellname ist eine leere Zeichenfolge, wenn er durch das System nicht unterstützt wird). Wenn der Modellname nicht unterstützt wird, dann wird Schritt 186 als nächster abgearbeitet. Wenn der Modellname unterstützt wird, dann wird Schritt 184 als nächster abgearbeitet.
  • Im Schritt 184 werden Informationen, die erforderlich sind, um Statusinformationen von der überwachten Vorrichtung eines bestimmten Modells zu erhalten, aus der Datenbank erhalten und zu dem lokalen Vektor hinzugefügt. Im Schritt 186 wird der lokale Vektor, der die Informationen enthält, die erforderlich sind, um alle Statusinformationen der überwachten Vorrichtung zu erhalten, im Vorrichtungsobjekt gesetzt. Das Vorrichtungsobjekt verfügt über Informationen darüber, welche Statusinformationen es von der überwachten Vorrichtung erhalten muss.
  • DeviceFactory erzeugt und initialisiert alle Vorrichtungsobjekte, sodass ihm bekannt ist, welche Statusinformationen es erhalten muss.
  • 12 zeigt das Sequenzdiagramm zum Ausführen der Funktion monitor-Status(). Der Prozess sendet die Statusinformationen der überwachten Vorrichtungen an einen gewünschten Ort. SendInterfaceManager 190 ruft startSend() 198 von DataTransfer 196 auf, um das System darauf vorzubereiten, die Statusinformationen der überwachten Vorrichtungen über E-Mail (SMTP) zu senden. SendInterfaceManager 190 ruft getStatus() 200 von Device 194 auf, um die Statusinformationen der überwachten Vorrichtung zu erhalten. Device 194 entspricht der überwachten Vorrichtung und ist darüber informiert, welche Statusinformationen es erhalten muss. SendInterfaceManager 190 ruft saveStatus() 202 von ODBC 192 auf, um die Statusinformationen der überwachten Vorrichtung in der Datenbank zu speichern. SendInterfaceManager 194 ruft dataSend() 204 von DataTransfer 196 auf, um die Statusinformationen der überwachten Vorrichtung über E-Mail (SMTP) zu senden. Die Schritte des Aufrufens von getStatus() 200, saveStatus() 202 und dataSend() 204 werden für jede überwachte Vorrichtung wiederholt. Für jede überwachte Vorrichtung liegt ein Vorrichtungsobjekt vor. SendInterfaceManager 190 ruft endSend() 206 von DataTransfer 196 auf, um das Senden der Statusinformationen über E-Mail abzuschließen.
  • 13 zeigt das Sequenzdiagramm zum Ausführen der Funktion getStatus() 214 von Device 210. SendInterfaceManager 208 ruft getStatus() 214 von Device 210 auf, um die Statusinformationen der überwachten Vorrichtung zu erhalten. Device 210 stellt eine überwachte Vorrichtung eines bestimmten Herstellers und Modells dar. Die Statusinformationen werden von den überwachten Vorrichtungen über SNMP erhalten. Wenn die überwachte Vorrichtung durch das System nicht unterstützt wird, dann sind die von der überwachten Vorrichtung erhaltenen Statusinformationen die Statusinformationen, die für alle überwachten Vorrichtungen erhältlich sind (Statusinformationen des gesamten Systems), wie etwa ein Fehlerstatus. Wenn der Hersteller, nicht aber das Modell der überwachten Vorrichtung durch das System unterstützt wird, dann sind die von der überwachten Vorrichtung erhaltenen Statusinformationen die Statusinformationen des gesamten Systems und die für alle überwachten Vorrichtungen des bestimmten Herstellers erhältlichen Statusinformationen (herstellerspezifischen Statusinformationen). Wenn der Hersteller und das Modell der überwachten Vorrichtung durch das System unterstützt werden, dann sind die von der überwachten Vorrichtung erhaltenen Statusinformationen die Statusinformationen des gesamten Systems, die herstellerspezifischen Informationen und die für alle überwachten Vorrichtungen des bestimmten Modells erhältlichen Statusinformationen (modellspezifischen Statusinformationen). Device 210 enthält einen Vektor, sodass ihm bekannt ist, welche Informationen es erhalten muss. Device 210 ruft getNextStringValueForOID() von Snmp 212 auf, sodass das System über SNMP die Statusinformationen von der überwachten Vorrichtung erhalten kann. getNextStringValueForOID() 218 wird mehrere Male aufgerufen, um von der überwachten Vorrichtung alle Statusinformationen zu erhalten.
  • 14 zeigt die Tabellen einer Datenbank, die Informationen über die durch das System unterstützten Hersteller und Modelle enthält. Die Tabelle enthält auch Informationen darüber, welche Informationen für jeden Hersteller und jedes Modell zu erhalten sind. Manufacturer 230 ist die Tabelle, die Informationen über die durch das System unterstützten Hersteller enthält. Manufacturer 230 enthält außerdem die folgenden Informationen: eine Unternehmensobjekt-Kennung für den Hersteller, eine Objektkennung, die dazu dient, den Modellnamen der überwachten Vorrichtung zu finden, und eine Objektkennung, die dazu dient, die eindeutige Kennung der überwachten Vorrichtung zu finden. SupportedModelByManufacturer 220 ist die Tabelle, die die durch das System unterstützten Modelle mit ihrem entsprechenden Hersteller enthält. Um durch das System unterstützte Hersteller und Modelle hinzuzufügen oder zu entfernen, müssen nur die Tabellen Manufacturer 230 und SupportedModelByManufacturer 220 modifiziert werden. Am Code des Systems muss keine Modifikation vorgenommen werden. Das System liest die Informationen aus diesen Tabellen der Datenbank aus.
  • ComManufStatus 226 ist die Tabelle, die Informationen darüber enthält, welche Informationen von der überwachten Vorrichtung auf der Grundlage ihres Herstellernamens erhalten werden. Die Tabelle enthält den Herstellernamen und eine Zahl, die den Typ von Informationen darstellt. ModelStatus 222 ist die Tabelle, die Informationen darüber enthält, welche Informationen von der überwachten Vorrichtung auf der Grundlage ihres Modellnamens erhalten werden. Die Tabelle enthält den Herstellernamen, den Modellnamen und eine Zahl, die den Typ von Informationen darstellt. Um Informationen, die von der überwachten Vorrichtung zu erhalten sind, hinzuzufügen oder zu entfernen, müssen nur die Tabellen ComManufStatus 226 und ModelStatus 222 modifiziert werden. Am Code des Systems muss keine Modifikation vorgenommen werden. Das System liest die Informationen aus diesen Tabellen der Datenbank aus.
  • EnumOID 224 ist die Tabelle, die Informationen über die Objektkennung enthält, die dazu dienen, die der Zahl entsprechenden Informationen zu finden. Die Objektkennung wird vom System dazu verwendet, über SNMP von der überwachten Vorrichtung einen bestimmten Typ von Informationen zu finden. EnumCorrespondence 228 ist die Tabelle, die eine Beschreibung der Zahlen enthält, die dazu dienen, einen Typ von Informationen darzustellen. Diese Tabelle wird vom System nicht verwendet, sondern liefert dem Anwender des Systems Informationen darüber, was die Zahlen darstellen.
  • 15 zeigt ein Beispiel für die Inhalte in den Tabellen der Datenbank, wie sie in 14 beschrieben ist. Microsoft Access ist die Datenbank, mit deren Hilfe Informationen über die durch das System unterstützten Hersteller und Modelle gespeichert werden.
  • 16 zeigt das Klassendiagramm für das ODBC2-Paket. Die Klasse CSupportODBC 232 ist die Schnittstelle zu diesem Paket für den Zugriff auf Informationen in der Datenbank. Die Klasse CManufactuerData 240 greift auf Informationen aus der Datenbank zu, die erforderlich sind, um den Hersteller, das Modell und die eindeutige ID der überwachten Vorrichtung zu erhalten. Die Klasse CSupportedModelData 234 greift auf Informationen aus der Datenbank über den Hersteller und das Modell der durch das System unterstützten überwachten Vorrichtung zu. Die Klasse CComManufStatusData 236 greift auf Informationen aus der Datenbank zu, die erforderlich sind, um Hersteller-Statusinformationen zu erhalten, die der überwachten Vorrichtung zugeordnet sind. Die Klasse CModelStatusData 238 greift auf Informationen aus der Datenbank zu, die erforderlich sind, um Modell-Statusinformationen zu erhalten, die der überwachten Vorrichtung zugeordnet sind. Die Klasse CManufacturerDatabase 242 stellt eine Schnittstelle zur Tabelle in der Datenbank bereit, die die Herstellerinformationen enthält. Die Klasse CSupportedModelDDatabase 244 stellt eine Schnittstelle zur Tabelle in der Datenbank bereit, die Informationen über unterstützte Modelle enthält. Die Klasse CComManufStatusDatabase 246 stellt eine Schnittstelle zur Tabelle in der Datenbank bereit, die die Hersteller-Statusinformationen enthält. Die Klasse CModelStatusDatabase 250 stellt eine Schnittstelle zur Tabelle in der Datenbank bereit, die die Modell-Statusinformationen enthält. Die Klasse CInfoTypeOIDDatabase 248 stellt eine Schnittstelle zur Tabelle in der Datenbank bereit, die die Entsprechung zwischen der infoType-Nummerierung und der Objektkennung enthält.
  • CManufacturerDatabase 242, CSupportedModelDatabase 244, CComManufStatusDatabase 246, CModelStatusDatabase 250 und CInfoTypeOIDDDatabase 248 sind sämtlich Klassen, die vom CRecordset 252 der Microsoft-Foundation-Class-(MFC-)Bibliothek abgeleitet sind.
  • Die obige Beschreibung der bevorzugten Ausführungsform der vorliegenden Erfindung wurde für Zwecke der Veranschaulichung und der Beschreibung geboten. Sie ist nicht dazu bestimmt, erschöpfend zu sein oder die Erfindung auf die präzise offenbarte Form einzuschränken, und es sind angesichts der obigen Lehren zahlreiche Abwandlungen oder Änderungen möglich. Beispielsweise können irgendeine oder mehrere der hierin beschriebenen oder gezeigten Konzeptionen auf das System und/oder auf das Verfahren angewandt werden, die im verwandten Dokument US 2002/52292 unter dem Titel "Method and System of Remote Support of Device Using Email" offenbart sind. Außerdem kann jegliches Konzept oder Merkmal, das in US 2002/152292 beschrieben ist, auf die hierin offenbarten Systeme oder Verfahren angewandt werden. Die Ausführungsformen wurden ausgewählt und beschrieben, um auf bestmögliche Weise die Prinzipien der Erfindung und ihre praktischen Anwendungen zu beschreiben, wodurch es einem anderen Fachmann auf dem Gebiet ermöglicht wird, die Erfindung und verschiedene Ausführungsformen zu verwenden, auch mit verschiedenen Abwandlungen, wie sie für die jeweils vorgesehene besondere Anwendung geeignet sind. Es ist beabsichtigt, dass der Umfang der vorliegenden Erfindung lediglich durch die hier beigefügten Ansprüche definiert ist.

Claims (16)

  1. Verfahren zum Bestimmen, ob eine überwachte Vorrichtung (2) durch ein Überwachungssystem in einem netzbasierten System, das das Überwachungssystem (8) und mehrere überwachte Vorrichtungen, die über ein Netz kommunikativ gekoppelt sind, umfasst, unterstützt wird, wobei das Überwachungssystem mit einer ersten und einer zweiten Datenbank kommunikativ gekoppelt ist, wobei das Verfahren die folgenden Schritte umfasst: (a) Abfragen der überwachten Vorrichtung (2), um einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten; (b) Bestimmen, ob das Überwachungssystem (8) so konfiguriert ist, dass es mit der überwachten Vorrichtung eine Schnittstelle bildet, unter Verwendung von in der ersten Datenbank (6) gespeicherten Informationen; (c) Bestimmen, ob die überwachte Vorrichtung (2) durch das Überwachungssystem unterstützt wird, unter Verwendung von in der zweiten Datenbank (10) gespeicherten Informationen durch: (i) Bestimmen, ob ein Hersteller der überwachten Vorrichtung durch das Überwachungssystem (8) unterstützt wird, (ii) Erhalten einer Seriennummer und/oder einer eindeutigen Kennung von der überwachten Vorrichtung, falls der Hersteller durch das Überwachungssystem (8) unterstützt wird; (iii) Erhalten einer MAC-Adresse der überwachten Vorrichtung (2), falls der Hersteller durch das Überwachungssystem nicht unterstützt wird; und (iv) Zuweisen einer Zufallszahl zu der eindeutigen Kennung, falls die MAC-Adresse von der überwachten Vorrichtung nicht erhalten werden kann.
  2. Verfahren nach Anspruch 1, bei dem der Schritt (b) durch Abfragen der ersten Datenbank (6) nach dem Hersteller und/oder dem Modell und/oder einer eindeutigen Kennung, die von der überwachten Vorrichtung erhalten werden, ausgeführt wird.
  3. Verfahren nach Anspruch 1 oder 2, bei dem der Schritt (c) ferner umfasst: Bestimmen, ob ein Modell der überwachten Vorrichtung (2) durch das Überwachungssystem unterstützt wird; und Aktualisieren der ersten Datenbank (6) mit Hersteller- und Modellinformationen, falls die überwachte Vorrichtung durch das Überwachungssystem unterstützt wird, unter Verwendung von in der zweiten Datenbank gespeicherten Informationen.
  4. Verfahren nach Anspruch 3, das ferner umfasst: Auflisten der überwachten Vorrichtung (2) als namenlos, falls der Hersteller der überwachten Vorrichtung durch das Überwachungssystem nicht unterstützt wird; und Erhalten von Informationen, die den mehreren überwachten Vorrichtungen gemeinsam sind, von der überwachten Vorrichtung.
  5. Verfahren nach Anspruch 4, das ferner umfasst: Auflisten der überwachten Vorrichtung (2) als durch einen allgemeinen Hersteller hergestellt; Erhalten von Informationen, die den mehreren überwachten Vorrichtungen gemeinsam sind; und Erhalten von Informationen, die mehreren überwachten Vorrichtungen von dem allgemeinen Hersteller gemeinsam sind.
  6. Verfahren nach Anspruch 5, das ferner umfasst: Erhalten von Informationen, die für die überwachte Vorrichtung (2) eindeutig sind, falls das Modell der überwachten Vorrichtung durch das Überwachungssystem unterstützt wird; und Erhalten von Informationen, die überwachten Vorrichtungen gemeinsam sind, die durch den allgemeinen Hersteller hergestellt werden.
  7. Verfahren nach einem der Ansprüche 1 bis 6, bei dem die erste Datenbank eine Systemkonfigurations-Datenbank ist, die umfasst: Informationen zum Freigeben einer Kommunikation zwischen dem Überwachungssystem (8) und der überwachten Vorrichtung (2); und Statusinformationen, die auf die überwachte Vorrichtung bezogen sind, wobei die Statusinformationen nach der Initialisierung des Überwachungssystems hinzugefügt werden.
  8. Verfahren nach einem der Ansprüche 1 bis 7, bei dem der Schritt des Bestimmens, ob das Überwachungssystem (8) so konfiguriert ist, dass es mit der überwachten Vorrichtung (2) eine Schnittstelle bildet, das Abfragen der überwachten Vorrichtung mit in der ersten Datenbank (6) gespeicherten Daten umfasst.
  9. Verfahren nach Anspruch 8, bei dem die erste Datenbank eine Systemkonfigurations-Datenbank ist und umfasst: Informationen, um eine Kommunikation zwischen dem Überwachungssystem (8) und der überwachten Vorrichtung (2) freizugeben; und Statusinformationen, die auf die überwachte Vorrichtung bezogen sind, wobei die Statusinformationen nach der Initialisierung des Überwachungssystems hinzugefügt werden, um die überwachte Vorrichtung zu überwachen.
  10. Verfahren nach einem der Ansprüche 1 bis 9, bei dem die zweite Datenbank (10) eine Systemunterstützungs-Datenbank ist und Informationen über verschiedene Hersteller und Vorrichtungsmodelle, die durch das Überwachungssystem (8) unterstützt werden, enthält.
  11. Vorrichtung zum Überwachen wenigstens einer überwachten Vorrichtung unter mehreren überwachten Vorrichtungen (2) in einem netzbasierten System, die mit einem Netz kommunikativ gekoppelt sind, wobei die Vorrichtung umfasst: ein Überwachungssystem, das mit dem Netz kommunikativ gekoppelt ist; eine erste Datenbank (6) und eine zweite Datenbank (10), die mit dem Überwachungssystem (8) kommunikativ gekoppelt sind; Mittel, um die überwachte Vorrichtung (2) abzufragen, um einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten; Mittel, um zu bestimmen, ob das Überwachungssystem (8) so konfiguriert ist, dass es mit der überwachten Vorrichtung eine Schnittstelle bildet, unter Verwendung von in der ersten Datenbank gespeicherten Informationen; Mittel, um zu bestimmen, ob die überwachte Vorrichtung (2) durch das Überwachungssystem unterstützt wird, unter Verwendung von in der zweiten Datenbank gespeicherten Informationen; Mittel, um zu bestimmen, ob ein Hersteller der überwachten Vorrichtung (2) durch das Überwachungssystem (8) unterstützt wird; Mittel, um eine Seriennummer und/oder eine eindeutige Kennung von der überwachten Vorrichtung zu erhalten, falls der Hersteller durch das Überwachungssystem (8) unterstützt wird; Mittel, um eine MAC-Adresse der überwachten Vorrichtung (2) zu erhalten, falls der Hersteller nicht durch das Überwachungssystem unterstützt wird; und Mittel, um der eindeutigen Kennung eine Zufallszahl zuzuweisen, falls die MAC-Adresse von der überwachten Vorrichtung nicht erhalten werden kann.
  12. Vorrichtung nach Anspruch 11, bei der die erste Datenbank eine Systemkonfigurations-Datenbank ist, die umfasst: Informationen, um eine Kommunikation zwischen dem Überwachungssystem (8) und der überwachten Vorrichtung (2) freizugeben; und Statusinformationen, die mit der überwachten Vorrichtung in Beziehung stehen, wobei die Statusinformationen nach der Initialisierung des Überwachungssystems hinzugefügt werden.
  13. Vorrichtung nach Anspruch 11 oder 12, bei der die erste Datenbank eine Systemkonfigurations-Datenbank ist und umfasst: Informationen, um eine Kommunikation zwischen dem Überwachungssystem (8) und der überwachten Vorrichtung (2) freizugeben; und Statusinformationen, die mit der überwachten Vorrichtung in Beziehung stehen, wobei die Statusinformationen nach der Initialisierung des Überwachungssystems hinzugefügt werden, um die überwachte Vorrichtung zu überwachen.
  14. Vorrichtung nach Anspruch 11, 12 oder 13, bei der die zweite Datenbank (10) eine Systemunterstützungs-Datenbank ist und Informationen über verschiedene Hersteller und Vorrichtungsmodelle, die durch das Überwachungssystem (8) unterstützt werden, umfasst.
  15. Computerprogramm, das Codemittel umfasst, die, wenn sie auf einem Computersystem ausgeführt werden, das Computersystem anweisen, ein Verfahren nach einem der Ansprüche 1 bis 10 auszuführen.
  16. Netzbasiertes System, das eine überwachte Vorrichtung (2) unter mehreren an ein Netz angeschlossenen Vorrichtungen besitzt, wobei das System umfasst: eine erste Datenbank (6) und eine zweite Datenbank (10), die mit der Steuereinheit kommunikativ gekoppelt sind, wobei die zweite Datenbank Informationen speichert, um zu bestimmen, ob die überwachte Vorrichtung (2) durch die Steuereinheit unterstützt wird; eine Steuereinheit, um die überwachte Vorrichtung (2) zu überwachen, wobei die Steuereinheit eine Logik besitzt, um: die überwachte Vorrichtung (2) abzufragen, um einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten; unter Verwendung eines hierarchischen Verfahrens zu bestimmen, ob das Überwachungssystem (8) so konfiguriert ist, dass es mit der überwachten Vorrichtung (2) eine Schnittstelle bildet, indem in der ersten Datenbank gespeicherte Informationen verwendet werden; und zu bestimmen, ob die überwachte Vorrichtung (2) durch das Überwachungssystem unterstützt wird, unter Verwendung von in der zweiten Datenbank gespeicherten Informationen durch: (i) Bestimmen, ob ein Hersteller der überwachten Vorrichtung durch das Überwachungssystem (8) unterstützt wird, (ii) Erhalten einer Seriennummer und/oder einer eindeutigen Kennung von der überwachten Vorrichtung, falls der Hersteller durch das Überwachungssystem (8) unterstützt wird; (iii) Erhalten einer MAC-Adresse der überwachten Vorrichtung (2), falls der Hersteller durch das Überwachungssystem nicht unterstützt wird; und (iv) Zuweisen einer Zufallszahl zu der eindeutigen Kennung, falls die MAC-Adresse von der überwachten Vorrichtung nicht erhalten werden kann, wobei Konfigurationsinformationen in der ersten Datenbank (6) mit in der zweiten Datenbank (10) gespeicherten Informationen aktualisiert werden, um die Steuereinheit in die Lage zu versetzen, mit der überwachten Vorrichtung eine Schnittstelle zu bilden, um dadurch eine Flexibilität bei der Aktualisierung von durch das Überwachungssystem überwachten Vorrichtungen unter mehreren Vorrichtungen zu ermöglichen.
DE60311183T 2002-05-31 2003-05-15 Methode und Vorrichtung zur Unterstützung fernüberwachter Geräte verschiedener Hersteller Expired - Lifetime DE60311183T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/157,904 US7359965B2 (en) 2002-02-27 2002-05-31 Method and apparatus for providing multiple vendor support to remotely monitored devices
US157904 2002-05-31

Publications (2)

Publication Number Publication Date
DE60311183D1 DE60311183D1 (de) 2007-03-08
DE60311183T2 true DE60311183T2 (de) 2007-11-08

Family

ID=29419660

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60311183T Expired - Lifetime DE60311183T2 (de) 2002-05-31 2003-05-15 Methode und Vorrichtung zur Unterstützung fernüberwachter Geräte verschiedener Hersteller

Country Status (5)

Country Link
US (1) US7359965B2 (de)
EP (1) EP1367768B1 (de)
JP (1) JP4210154B2 (de)
DE (1) DE60311183T2 (de)
ES (1) ES2279062T3 (de)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2403270C (en) 2000-03-14 2011-05-17 Joseph Robert Marchese Digital video system using networked cameras
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
US7337242B1 (en) * 2002-02-11 2008-02-26 Ricoh Company, Limited Method and apparatus utilizing communication means hierarchy to configure or monitor an interface device
US7519729B2 (en) * 2002-02-27 2009-04-14 Ricoh Co. Ltd. Method and apparatus for monitoring remote devices through a local monitoring station and communicating with a central station supporting multiple manufacturers
US7899900B1 (en) * 2002-08-22 2011-03-01 Ricoh Company, Ltd. Method and system for monitoring network connected devices with multiple protocols
JP4279538B2 (ja) * 2002-10-30 2009-06-17 富士ゼロックス株式会社 機器設定方法、機器設定システム、情報処理装置及びコンピュータプログラム
US7496492B2 (en) * 2003-08-29 2009-02-24 Microsoft Corporation Software-aided storage device emulation in a physical storage device
JP4616622B2 (ja) * 2003-12-16 2011-01-19 株式会社リコー 通信装置、通信制御方法、通信制御プログラム及び記録媒体
JP4723868B2 (ja) * 2004-01-27 2011-07-13 株式会社リコー ネットワーク装置から状態情報を得るために用いられるプロトコルを管理するための方法及びシステム
US7792147B1 (en) * 2004-02-09 2010-09-07 Symantec Corporation Efficient assembly of fragmented network traffic for data security
US7574503B2 (en) * 2004-08-27 2009-08-11 Ricoh Company Ltd. Method and system for using abstract classes to extract status information from networked devices
US7502848B2 (en) * 2004-08-27 2009-03-10 Ricoh Company Ltd. Method of creating a data processing object associated with a communication protocol used to extract status information related to a monitored device
JP4725066B2 (ja) * 2004-09-30 2011-07-13 セイコーエプソン株式会社 印刷装置監視システム、ネットワークボード、印刷装置監視方法
US7895308B2 (en) * 2005-05-11 2011-02-22 Tindall Steven J Messaging system configurator
US20070129014A1 (en) * 2005-11-18 2007-06-07 Bertorello, Inc. Information synchronization
US9166883B2 (en) * 2006-04-05 2015-10-20 Joseph Robert Marchese Network device detection, identification, and management
JP6035704B2 (ja) 2011-03-18 2016-11-30 セイコーエプソン株式会社 周辺装置、管理装置及び機種情報送信方法
WO2018205170A1 (zh) * 2017-05-10 2018-11-15 深圳中兴力维技术有限公司 一种接入私有化协议设备的方法、服务器及监控系统

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6108782A (en) * 1996-12-13 2000-08-22 3Com Corporation Distributed remote monitoring (dRMON) for networks
US6170005B1 (en) * 1997-11-04 2001-01-02 Motorola, Inc. Synchronization and information exchange between communication components using a network management operations and control paradigm
US6122639A (en) * 1997-12-23 2000-09-19 Cisco Technology, Inc. Network device information collection and change detection
US6437692B1 (en) * 1998-06-22 2002-08-20 Statsignal Systems, Inc. System and method for monitoring and controlling remote devices
US6317848B1 (en) * 1998-09-24 2001-11-13 Xerox Corporation System for tracking and automatically communicating printer failures and usage profile aspects
US6349306B1 (en) * 1998-10-30 2002-02-19 Aprisma Management Technologies, Inc. Method and apparatus for configuration management in communications networks
US20030088574A1 (en) * 2001-11-07 2003-05-08 White Andrew Edward Method and machine for validating an identifier as unique

Also Published As

Publication number Publication date
EP1367768A2 (de) 2003-12-03
JP4210154B2 (ja) 2009-01-14
EP1367768A8 (de) 2004-03-31
US20070124455A1 (en) 2007-05-31
DE60311183D1 (de) 2007-03-08
EP1367768A3 (de) 2005-06-08
ES2279062T3 (es) 2007-08-16
EP1367768B1 (de) 2007-01-17
US7359965B2 (en) 2008-04-15
JP2004005692A (ja) 2004-01-08

Similar Documents

Publication Publication Date Title
DE60304768T2 (de) Verfahren und Vorrichtung zum Überwachen entfernter Geräte durch Erzeugen von Geräteobjekten für die zu überwachenden Geräte
DE60316220T2 (de) Verfahren und Vorrichtung zur Konfigurierung eines Überwachungssystems
DE60311183T2 (de) Methode und Vorrichtung zur Unterstützung fernüberwachter Geräte verschiedener Hersteller
DE60205539T2 (de) Verfahren und Vorrichtung zum Verwalten von mehreren Netzwerkgeräten
DE69734373T2 (de) Anpassbare automatische Verwaltung von Netzwerkgeräten
DE69927929T2 (de) Verfahren und System zur Netzwerkverwaltung
DE69834566T2 (de) Integrierte kommunikationsarchitektur in einer mobilen vorrichtung
DE69628718T2 (de) Netzwerk - Topologie-Verwaltungssystem
DE60020633T2 (de) Geräteverwaltungsnetzwerksystem, Verwaltungsserver, und Rechner
DE60308755T2 (de) Verfahren und Vorrichtung zur Überwachung von vernetzten Geräten und zur Anzeige des Gerätestatuses
DE69634762T2 (de) Gerät zur Erzeugung und Übertragung einer verwalteten Gerätbeschreibungsdatei
DE69329743T9 (de) Computerverwaltungssystem und entsprechende Datenbank für Verwaltungsinformationen
DE60222544T2 (de) Verwaltungssystem umd Methode zur Erbringung von Abonnementdienstleistungen
DE69637142T2 (de) Netzwerkverwaltung mit Erfassung von formatierten Abzugdaten aus einem Fernprozess
DE60220375T2 (de) Spezifischer Datenregistrierungsserver in einem Bedien- und Verwaltungszentrum für ein Telekommunikationssystem
DE69826298T2 (de) Verfahren und Vorrichtung zur Klassifikation von Netzwerkeinheiten in virtuellen LANs
DE19839577C2 (de) Verfahren und Vorrichtung zum Anfertigen einer Karte der physischen Topologie eines Teilnetzes
DE60219335T2 (de) System und Verfahren zum Konfigurieren von Netzvorrichtungen
DE112012003778T5 (de) Computernetzwerk-Management-Tools
WO2007144300A1 (de) Flexible änderung des zuständigkeitsbereiches eines operators für das netzwerkmanagement
DE10051022B4 (de) Verfahren, System und Computerprogrammprodukt für die Neukonfiguration logischer Drucker in einem Druckernetzsystem beim Wechsel von einem Überwachungsprogramm zu einem zweiten Überwachungsprogramm
DE19924261B4 (de) Netzmanagementverfahren und System
DE10251911B4 (de) Verfahren für das Konfigurationsmanagement und Netzwerk
EP1282991B1 (de) Aktualisierung von hersteller-spezifischen hardware-informationen an der hersteller-unabhängigen omc-nmc-schnittstelle im mobilfunk
DE69633448T2 (de) Universeller objekt-übersetzungsagent

Legal Events

Date Code Title Description
8381 Inventor (new situation)

Inventor name: MOTOYAMA, TETSURO, SAN JOSE, CA 95131-1817, US

Inventor name: FONG, AVERY, SAN JOSE, CA 95131-1817, US

8364 No opposition during term of opposition