DE19746393A1 - Dynamisches Mustererkennungssystem - Google Patents

Description

Die Erfindung betrifft allgemein Mustererkennungssysteme und ins­ besondere ein System zum dynamischen Erkennen von Mustern im Zu­ sammenhang mit einem Kommunikationssystem.

Die Verwendung von Kommunikationsprogrammen war und ist derzeit weit verbreitet. Sie werden dafür verwendet, um es zwei Geräten zu gestatten, Daten untereinander zu übertragen und voneinander zu empfangen. Diese Programme verwenden Kommunikationsleitungen, um Daten zwischen jedem Gerät an den beiden Enden der Verbindung zu übertragen und zu empfangen. Ein Beispiel eines solchen Kommunika­ tionsprogramms ist das Programm "TERMINAL", welches als Zusatzpro­ gramm bei jeder Kopie des Windows-Betriebssystems angebunden ist und von der Microsoft Corp. Redmond, Washington hergestellt wird.

Typischerweise empfängt ein Kommunikationsprogramm eine Eingabe von hauptsächlich zwei verschiedenen Quellen. Die erste Quelle kommt von dem Gerät an dem anderen Ende der Kommunikationsleitung (z. B. dem externen Hostrechner (remote host)). Die zweite Haupt­ quelle von Daten kommt von dem Benutzer über die Tastatur, eine Zeigervorrichtung (z. B. eine Maus) oder ein anderes Eingabegerät. Die Hauptausgabeziele eines typischen Kommunikationsprogramms sind der Bildschirm oder ein Anzeigeterminal, Kommunikationsleitung(en), der Drucker und Betriebssystemaufrufe.

Der Datenfluß bei herkömmlichen Kommunikationsprogrammen hat typi­ scherweise die folgenden zwei Formen. Die erste sind Daten, welche von dem externen Hostrechner über die Kommunikationsleitung emp­ fangen werden und durch einen Befehlsprozessor in dem Kommunika­ tionsprogramm verarbeitet werden. Die meisten dieser Daten werden zu dem Bildschirm oder dem Anzeigegerät geleitet. Die zweite Form sind Daten, welche von der Tastatur empfangen werden. Diese Daten werden durch den Tastaturprozessor in den Kommunikationsprogrammen verarbeitet und die meisten dieser Daten werden zu dem externen Hostrechner über die Kommunikationsleitung geleitet.

Ein Blockdiagramm auf einer hohen Ebene ("High-Level-Blockdia­ gramm"), welches die relevanten Komponenten eines lokalen Compu­ tersystems 12 nach dem Stand der Technik illustriert, welches mit einem externen Hostrechner 30 kommuniziert, ist in Fig. 1 gezeigt. Der lokale Computer 12 weist ein Kommunikationsprogramm 14, eine lokale Computerkommunikationsschnittstelle 26, ein Eingabegerät 28 (z. B. eine Tastatur, eine Maus usw.), einen Bildschirm 16, einen Drucker 18 und ein Betriebssystem 20 auf. Das Kommunikationspro­ gramm 14 weist einen herkömmlichen Befehlsprozessor 22 und einen Tastaturprozessor 24 auf. Der externe Hostrechner 30 sendet Befeh­ le zu dem Kommunikationsprogramm 14 über die lokale Computerkom­ munikationsschnittstelle 26 und die Kommunikationsverbindung 34 (durch die Ellipse in der Zeichnung dargestellt), welche von dem Befehlsprozessor 22 interpretiert werden. Der Befehlsprozessor gibt Daten zu dem externen Hostrechner über denselben Weg, jedoch in umgekehrter Richtung ab. Ein Benutzer 32 gibt Befehle ein und tippt Zeichen, welche in das Kommunikationsprogramm über das Ein­ gabegerät 28 eingegeben werden sollen. Die Eingabedaten werden von dem Tastaturprozessor 24 interpretiert.

Der Befehlsprozessor 22 besitzt die Fähigkeit, Kommunikationspro­ grammbefehle und ihre zugeordneten Parameter zu identifizieren. Der Befehlsprozessor besitzt auch die Fähigkeit, hierauf entspre­ chend zu reagieren. Typischerweise werden Zeichen, welche Befehle enthalten, nicht auf dem Bildschirm angezeigt. Wenn z. B. ein Be­ fehlsprozessor für ein VT100, ein verbreitetes Terminalgerät, als Eingabe die Zeichenkette "<(ESC<[3;5H" empfängt, wird diese Zei­ chenkette als Cursorpositionierungsbefehl erkannt und nicht als Eingabedaten angesehen. Die "3" wird als ein Zeilenparameter und die "s" wird als Spaltenparameter erkannt. Als Ergebnis leitet der Befehlsprozessor eine Prozedur ein, welche den Cursor veranlaßt, sich zu der Zeile 3, Spalte 5 zu bewegen.

Ein Hauptnachteil von herkömmlichen Befehlsprozessoren besteht darin, daß ihr Repertoire von Befehlen und zugehörigen Antworten festgelegt ist und in dem Kommunikationsprogramm hart codiert (hard coded) ist. Sie gestatten keinerlei Flexibilität beim Modi­ fizieren des Befehlssatzes oder einer der Antworten auf einen Be­ fehl. In vielen Fällen wäre es sehr günstig, wenn es möglich wäre, den Satz von Befehlen und deren Antworten eines Befehlsprozessors zu modifizieren.

Dementsprechend ist eine Aufgabe der Erfindung, ein Kommunika­ tionssystem zur Verfügung zu stellen, bei dem der Satz von Befeh­ len und zugehörigen Antworten des Befehlsprozessors nicht fest ist.

Es ist eine weitere Aufgabe der Erfindung, ein Kommunikationssystem zur Verfügung zu stellen, welches einen flexiblen Befehlspro­ zessor enthält und in der Lage ist, Befehle während der Laufzeit zu definieren.

Eine weitere Aufgabe der Erfindung besteht darin, ein Kommunika­ tionssystem zur Verfügung zu stellen, welches einen flexiblen Be­ fehlsprozessor enthält und in der Lage ist, Antworten während der Laufzeit zu definieren.

Ein dynamisches Mustervergleichssystem (DPRS (Dynamic Pattern Mat­ ching System)) für ein Kommunikationssystem wird offenbart. Das DPRS ermöglicht es dem Befehlsprozessor in dem Kommunikationssystem, flexibel zu sein, und ermöglicht, daß Befehle und ihre zu­ gehörigen Antworten on-the-fly hinzugefügt, gelöscht und verändert werden, während das Kommunikationssystem arbeitet. Ein Benutzer gestaltet einen Befehlssatz und konstruiert eine Trapdefini­ tionsdatei. Diese Trapdefinitionsdatei wird von dem DPRS während der Initialisierung gelesen und eine Trapkette wird konstruiert. Die Trapkette ist eine Liste aller Traps, welche den Befehlssatz bilden. Traps können jedoch on-the-fly durch Befehle von dem ex­ ternen Hostrechner hinzugefügt oder gelöscht oder von einem Benut­ zer über die Tastatur oder über Menüs eingegeben werden. Das DPRS kann als ein Werkzeug (Tool) verwendet werden, um dynamisch das Verhalten eines vorhandenen Hostapplikations-Kommunikationssystems zu verändern. Das DPRS kann als selbständiger (stand alone) fle­ xibler Befehlsprozessor arbeiten oder parallel oder seriell zu einem herkömmlichen Befehlsprozessor arbeiten.

Es wird daher ein dynamisches Mustervergleichssystem (DPRS) zur Verwendung in einem Kommunikationssystem, das mit einer Kommunika­ tionsverbindung gekoppelt ist, zur Verfügung gestellt, welches eine mit der Kommunikationsverbindung gekoppelte Kommunikations­ schnittstelle, welche das DPRS mit der Kommunikationsverbindung koppelt, eine mit der Kommunikationsschnittstelle gekoppelte Ver­ arbeitungseinrichtung zum Verarbeiten von Eingabedaten, welche über die Kommunikationsverbindung empfangen werden und eine Trap­ kette aufweist, welche aus mehreren Traps besteht. Die Traps be­ stehen aus einem Satz von Befehlen, welche die Funktionalität des DPRS definieren, wobei jedes Trap einem eindeutigen Befehl ent­ spricht.

Zusätzlich enthält gemäß einer Ausführungsform der Erfindung das System weiterhin eine Einrichtung zum Hinzufügen von zusätzlichen Traps zu der Trapkette entsprechend Befehlen, welche über die Kom­ munikationsverbindung empfangen werden, und/oder auch eine Ausga­ beschnittstelleneinrichtung, welche mit zumindest einem Ausgabe­ gerät gekoppelt ist, wobei die Ausgabeschnittstelleneinrichtung zum Ausgeben von Zeichen- und/oder Bytedaten von dem DPRS zu dem einen Ausgabegerät dient, das wenigstens vorhanden ist.

Weiterhin verarbeitet gemäß einer Ausführungsform der Erfindung die Verarbeitungseinrichtung Eingabedaten, welche von einem Benut­ zer empfangen werden. Die Verarbeitungseinrichtung verarbeitet Eingabedaten, welche von einem Betriebssystem empfangen werden.

Weiterhin werden gemäß einer Ausführungsform der Erfindung weitere Traps zu der Trapkette entsprechend Befehlen hinzugefügt, welche über den Benutzer empfangen werden.

Darüber hinaus enthält gemäß einer Ausführungsform der Erfindung das System weiterhin eine Einrichtung zum Löschen von Traps aus der Trapkette entsprechend Befehlen, welche über die Kommunika­ tionsverbindung empfangen werden. Die Trapkette enthält eine ver­ kettete Liste von Traps oder ein Feld von Traps.

Weiterhin enthält gemäß einer Ausführungsform der Erfindung jedes Trap innerhalb der Trapkette ein Befehlsdefinitionsfeld, ein Be­ fehlsvergleichsroutinenfeld, ein Antwortroutinenfeld und ein Para­ meterfeld.

Weiterhin enthält gemäß einer Ausführungsform der Erfindung jedes Trap innerhalb der Trapkette ein Objekt. Jedes Objekt enthält eine Musterdefinition, eine Vergleichsroutine, eine Antwortroutine und null oder mehr Parameter für die Antwortroutine.

Weiterhin wird gemäß einer Ausführungsform der Erfindung ein Ver­ fahren zum dynamischen Vergleichen von Mustern in einem Kommunika­ tionssystem, welches mit einer Kommunikationsverbindung gekoppelt ist, zur Verfügung gestellt, wobei das Kommunikationssystem mehre­ re Trapdefinitionen enthält. Das Verfahren enthält die folgenden Schritte:

• a) Konstruieren einer Trapkette aus dem Inhalt von mehreren Trapdefinitionen,
• b) Suchen nach einer Entsprechung eines Trap unter den Zei­ chen, welche über die Kommunikationsverbindung empfangen werden, und jeder der Trapdefinitionen und
• c) für jede aufgefundene Trapübereinstimmung, Ausführen einer Antwortroutine, welche dem übereinstimmenden Trap zugeord­ net ist.

Weiterhin enthält gemäß einer Ausführungsform der Erfindung das Verfahren den Schritt des Ladens der Trapdefinitionen.

Weiterhin umfaßt gemäß einer Ausführungsform der Erfindung der Schritt des Konstruierens einer Trapkette den Schritt des Konstru­ ierens einer Liste von individuellen Traps oder den Schritt des Konstruierens eines Felds von individuellen Traps. Jedes Trap in­ nerhalb der Trapkette enthält ein Befehlsdefinitionsfeld, ein Be­ fehlsvergleichsroutinenfeld, ein Antwortroutinenfeld und ein Para­ meterfeld.

Weiterhin enthält gemäß einer Ausführungsform der Erfindung jedes Trap innerhalb der Trapkette ein Objekt. Das Objekt enthält eine Musterdefinition, eine Vergleichsroutine, eine Antwortroutine und null oder mehr Parameter für die Antwortroutine.

Die Erfindung wird nachfolgend lediglich beispielhaft mit Bezug auf die beigefügten Zeichnungen beschrieben.

Fig. 1 ist ein Blockdiagramm auf einer hohen Ebene, welches die relevanten Komponenten eines lokalen Computersystems nach dem Stand der Technik illustriert, welches mit einem ex­ ternen Hostrechner kommuniziert.

Fig. 2 ist ein Blockdiagramm auf einer hohen Ebene, welches einen lokalen Computer illustriert, in dem ein dynamisches Mu­ stererkennungssystem inkorporiert ist, welches entspre­ chend einer bevorzugten Ausführungsform der Erfindung kon­ struiert ist.

Fig. 3 ist ein Blockdiagramm auf einer hohen Ebene, welches das dynamische Mustererkennungssystem der Fig. 2 detaillierter zeigt.

Fig. 4 ist ein Blockdiagramm auf einer hohen Ebene, welches den Trapkettenteil des dynamischen Mustererkennungssystems il­ lustriert,

Fig. 5 illustriert detaillierter die Elemente eines der Traps, welche in der Trapkette der Fig. 4 enthalten sind.

Fig. 6 ist ein Flußdiagramm auf einer hohen Ebene, welches den Prozeß illustriert, welcher von dem dynamischen Musterer­ kennungssystem der Erfindung ausgeführt wird.

Fig. 7A illustriert das Format jedes Datensatzes in der Trapdefi­ nitionsdatei und

Fig. 7B ist ein Beispiel einer Implementierung des Inhalts einer Trapdefinitionsdatei.

Die Erfindung überwindet die Nachteile des Standes der Technik, indem ein dynamisches Mustererkennungssystem (DPRS) verwendet wird, um die Eingabe von dem externen Hostrechner zu handhaben. Das DPRS erzeugt auch eine Ausgabe an ähnliche Ziele, wie die Kom­ munikationsleitung, den Bildschirm, den Drucker und das Be­ triebssystem. Eine Hauptkomponente des DPRS ist ein flexibler Be­ fehlsprozessor. Der Befehlsprozessor dient dazu, eine über eine Kommunikationsverbindung empfangene Eingabe zu verarbeiten. Zu­ sätzlich hat er die Funktion, die Befehle zu definieren, welche während der Laufzeit erkannt werden. Der Befehlsprozessor defi­ niert auch ebenso die Antworten auf diese Befehle während der Laufzeit. Eine Definition eines Befehls und die zugehörige Antwort wird Trap genannt. Der erfindungsgemäße flexible Befehlsprozessor verwendet ein Ensemble solcher Traps, um seine Funktionalität zu definieren.

Fig. 2 zeigt ein Blockdiagramm auf einer hohen Ebene, welches ei­ nen lokalen Computer illustriert, in dem ein dynamisches Muster­ erkennungssystem inkorporiert ist, das entsprechend einer bevor­ zugten Ausführungsform der Erfindung konstruiert ist. Der lokale Computer 12 enthält ein dynamisches Mustererkennungssystem (DPRS) 10. Das DPRS 10 ist mit einer lokalen Computerkommunikations­ schnittstelle 26, einem Eingabegerät 28 (z. B. einer Tastatur, ei­ ner Maus usw.), einem Bildschirm (d. h. einem Anzeigeterminal) 16, einem Drucker 18 und einem Betriebssystem 20 gekoppelt. Ein exter­ ner Hostrechner 30 sendet Befehle und Daten zu dem DPRS über die Kommunikationsleitung 34 und die Kommunikationsschnittstelle 26 des lokalen Computers. Die Ausgabe des DPRS wird zu dem externen Hostrechner über die Kommunikationsschnittstelle des lokalen Com­ puters und die Kommunikationsleitung 34 geleitet. Ein Benutzer 32 sendet Eingabebefehle und Eingabedaten zu dem DPRS über das Ein­ gabegerät 28.

Während des normalen Betriebs des erfindungsgemäßen Kommunika­ tionssystems lädt das DPRS einen Satz von Traps als Teil des In­ itialisierungsprozesses. Der flexible Befehlsprozessor innerhalb des DPRS besitzt die Fähigkeit, den Satz von Befehlen und ihre Parameter zu identifizieren und darauf zu reagieren. Zu jeder Zeit kann das DPRS neue Traps laden, um den aktuellen Befehlsprozessor zu erweitern. Weiterhin kann das DPRS jederzeit Traps löschen, um die Funktionalität des Befehlsprozessors zu verringern, oder einen bestehenden Satz von Traps ändern, um die Funktionalität des Be­ fehlsprozessors zu modifizieren. Zusätzlich zu benutzerdefinierten Traps kann der Satz von Traps feste oder vordefinierte Traps ent­ halten.

Alternativ kann das DPRS initialisiert werden, ohne einen Satz von Traps zu laden. In diesem Fall bleibt das DPRS inaktiv, bis ein oder mehrere Traps zu einem späteren Zeitpunkt geladen werden. Die Traps können über eine Trapdatei, das Betriebssystem oder durch den Benutzer geladen werden.

Der Vorgang des Hinzufügens, Löschens und Änderns von Traps findet als Folge der Interpretation eines Befehls statt, der von einer von drei Quellen empfangen wird. Die erste Quelle ist der Host­ rechner, mit dem das DPRS kommuniziert. Die zweite Quelle sind explizite Befehle, welche von dem Benutzer als Folge einer Menü­ auswahl, des Niederdrückens eines Knopfes, einer definierten Taste (shortcut key) usw. eingegeben wird. Man beachte, daß ein empfan­ gener Befehl nur interpretiert werden kann, wenn es ein aktuell definierter Befehl ist. Die dritte Quelle ist das Betriebssystem in der Form des Aufrufs einer Applikationsprogrammierschnittstelle (API), der Kommunikation zwischen Prozessen, wie dynamischer Da­ tenaustausch (DDE), Binden und Einbetten von Objekten (OLE (object linking and embedding)), eine Fensternachricht usw. .
Das DPRS ist also ein Werkzeug, welches dem Endbenutzer die Fähig­ keit verleiht, das Verhalten einer vorhandenen Hostapplikation durch Interpretieren von deren Ausgabe zu ändern. Durch das Ver­ wenden des DPRS kann ein Benutzer bei bestimmten Anforderungen das Verhalten einer vorhandenen Hostapplikation modifizieren, um sie an diese speziellen Anforderungen anzupassen. Es ist wichtig, zu beachten, daß das DPRS als selbständiger "flexibler Befehlsprozes­ sor" arbeiten kann oder parallel oder seriell zu einem herkömmli­ chen Befehlsprozessor arbeiten kann, welchem die Fähigkeiten des DPRS fehlen. In dem parallelen Fall empfangen und verarbeiten so­ wohl das DPRS als auch der herkömmliche Prozessor für feste Befeh­ le jedes Eingabezeichen oder -byte. In dem seriellen Fall, in dem das DPRS dem Befehlsprozessor nachgeschaltet ist, empfängt das DPRS nicht erkannte Daten, die von dem Befehlsprozessor nicht ver­ arbeitet wurden.

Fig. 3 zeigt ein Blockdiagramm auf einer hohen Ebene, welches das dynamische Mustererkennungssystem der Fig. 2 genauer zeigt. Das DPRS 10 umfaßt eine Kommunikationsschnittstelle 40, einen flexi­ blen Befehlsprozessor 42, ein Wartungsmodul 44, ein Ausgabe­ schnittstellenmodul 48 und eine Trapkette 50. Die Kommunikations­ schnittstelle bildet die Schnittstelle zwischen dem DPRS und der Kommunikationsschnittstelle 26 des lokalen Computers (Fig. 2) und dem Eingabegerät 28. Das DPRS kommuniziert auch mit dem Bildschirm 16 (Fig. 2), dem Drucker 18 und dem Betriebssystem 20.

Der flexible Befehlsprozessor empfängt, interpretiert und antwor­ tet auf Befehle, welche von dem externen Hostrechner über die Kom­ munikationsschnittstelle 40 empfangen wurden, und solche von der Tastatur, welche von dem Benutzer eingegeben wurden. Man beachte jedoch, daß der größte Teil der Verarbeitung, welche durch den Befehlsprozessor geschieht, darin besteht, Daten zu verarbeiten, welche über die Kommunikationsverbindung empfangen wurden. Der größte Teil der über die Tastatur von dem Benutzer empfangenen Daten wird zu dem externen Hostrechner übermittelt.

Das Wartungsmodul 44 hat die Funktion, das Hinzufügen, Löschen und Modifizieren von Traps auszuführen. Die Trapkette kann durch Be­ fehle modifiziert werden, welche von dem DPRS empfangen und dann durch das Wartungsmodul 44 ausgeführt werden. Weiterhin können dem Wartungsmodul weitere Dienste hinzugefügt werden, um Funktionen außer dem Hinzufügen, Löschen oder Ändern von Traps auszuführen.

Das Ausgabeschnittstellenmodul 48 leitet die Ausgabe zu dem rich­ tigen Ziel, welches z. B. der Bildschirm, der Drucker, das Be­ triebssystem (z. B. Betriebssystemaufrufe) und die Kommunikations­ leitung über die Kommunikationsschnittstelle 40 sein können. Die Trapkette 50 enthält den Satz von Traps, welche zu dem jeweils gegenwärtigen Zeitpunkt die Funktionalität des Befehlsprozessors definieren.

Fig. 4 zeigt ein Blockdiagramm auf einer hohen Ebene, welches den Trapkettenteil des dynamischen Mustererkennungssystems illu­ striert. Die Trapkette 50 umfaßt eine Liste von individuellen Traps. Die Kette kann jede geeignete Art einer Liste sein, wie eine einfach verkettete Liste, eine doppelt verkettete Liste usw.; sie ist jedoch hierauf nicht beschränkt. Die Trapkette kann auch als ein Feld von Traps, ein Feld von Zeigern (Pointer) zu Traps oder als irgendeine andere geeignete Datenstruktur konstruiert sein. In Fig. 4 ist eine beispielhafte Trapkette dargestellt, wel­ che mehrere Traps 52 enthält, welche mit TRAP#1, TRAP#2, . . . TRAP#N bezeichnet sind.

Fig. 5 illustriert detaillierter die Elemente eines der Traps 52, welche in der Trapkette 50 enthalten sind. Wie vorangehend ausge­ führt wurde, ist die Trapkette eine Struktur aus individuellen Traps (z. B. eine verkettete Liste oder ein Feld). Jedes Trap 52 enthält seinerseits vier Elemente oder Komponenten. Das erste Ele­ ment ist eine Befehlsformatbeschreibung 54, welche den Befehl be­ schreibt. Die Befehlsformatbeschreibung wird von einer Vergleichs­ routine verwendet, um festzustellen, welcher der Befehle empfangen wurde. Das zweite Element ist eine Befehlserkennungsroutine 56, welche ein Zeiger zu einer Vergleichsroutine ist, welche verwendet wird, um diesen besonderen Befehl zu erkennen. Wenn Daten empfan­ gen werden, wird die Vergleichsroutine (d. h. die Befehlserken­ nungsroutine) jedes Traps aufgerufen, um zu versuchen, eine Ent­ sprechung zwischen den empfangenen Daten und einem der Trapbefehle zu finden. Alternativ kann ein Code anstelle eines Zeigers verwen­ det werden. Das dritte Element ist eine Antwortroutine 58. Dieses Element ist tatsächlich ein Zeiger zu der Routine, welche aufgeru­ fen wird, wenn die Vergleichsroutine 56 eine Entsprechung zwischen dem empfangenen Befehl und der Befehlsformatbeschreibung 54 fin­ det. Dieser Parameter kann auch als ein Code statt als Zeiger im­ plementiert werden. Das vierte Element sind null oder mehr Para­ meter für die Antwortroutine 60. Diese Parameter werden von der Antwortroutine verwendet, wenn sie ausgeführt wird (d. h. wenn eine Entsprechung gefunden wurde) . Man beachte, daß manche Antwortrou­ tinen möglicherweise keine Parameter erfordern.

Die Trapkette ist aus mehreren Traps aufgebaut. Die Traps werden zu Beginn aus einer "Trapdatei" genannten Datei geladen. Die Trapdatei enthält mehrere Datensätze, wobei jeder Datensatz ent­ hält:

• - eine Befehlsdefinition, welche der Befehlsformatbeschrei­ bung 54 entspricht und eine Zeichenkette ist, welche das Muster des Befehls definiert,
• - einen Code für eine Befehlserkennungsroutine, welches ein Code ist, der verwendet wird, um die Vergleichsroutine für dieses spezielle Trap zu identifizieren,
• - einen Code für eine Antwortroutine, der verwendet wird, um die Antwortroutine für dieses spezielle Trap zu identifi­ zieren, und
• - einen Satz von Parametern für die Antwortroutine.

In einer bevorzugten Ausführungsform der Erfindung werden Zeichen und Zeichenketten verwendet, um die vier vorangehend beschriebenen Trapelemente in jedem Datensatz der Trapdatei darzustellen. In einer alternativen Ausführungsform können die Elemente in der Trapdatei in binärer Form oder in einer Kombination von binären Daten und Textdaten dargestellt werden.

Man beachte, daß die Reihenfolge der Felder in einem Trapdatensatz nicht wichtig ist. Die Felder können in jeder gewünschten Reihen­ folge implementiert werden. Weiterhin kann bei der Trapimplemen­ tierung auf das Parameterfeld verzichtet oder es können weitere Felder hinzugefügt werden, um irgendeinem Zweck der tatsächlichen Implementierung zu entsprechen. Das Befehlsmusterfeld eines Trap kann z. B. als Zeichenkette, als Feld, als Datensatz irgendeiner Art, als Speicherzuordnung oder als Datensatz von der Art einer Varianten implementiert werden. Die Erkennungs- und Antwortfelder können in irgendeiner geeigneten Weise implementiert werden, was Zeiger zu Prozeduren, Prozedurcodeziffern (procedure code numbers) usw. einschließt, jedoch hierauf nicht beschränkt ist. Das Parame­ terfeld eines Traps kann als Zeichenkette, Feld oder Datensatz irgendeiner Art implementiert sein, was einen Datensatz nach Art einer Varianten oder eine Speicherzuordnung einschließt, auf wel­ che jeweils direkt oder indirekt Bezug genommen werden kann.

Zumindest das Befehlsformat 54 (Fig. 5) und die Parameter für die Antwort müssen in jedem Trap enthalten sein. Die Vergleichsroutine und die Antwort können feststehend sein. Die Parameter für die Antwort können z. B. den Namen einer Datei enthalten, welche ausge­ führt wird, wenn eine Entsprechung des Befehlsmusters gefunden wird.

Fig. 6 zeigt ein Flußdiagramm auf einer hohen Ebene, welches den Prozeß illustriert, welcher von dem dynamischen Mustererkennungs­ system der Erfindung ausgeführt wird. Bevor das DPRS verwendet werden kann, um Befehle zu interpretieren, muß ein Benutzer zu­ nächst einen Satz von Traps entwerfen und konstruieren (d. h. einen Befehlssatz aufbauen), welcher die gewünschten Funktionen aus­ führt. Der Satz von Traps, welcher von dem Benutzer aufgebaut wor­ den ist, wird dann in eine Trapdefinitionsdatei überführt, welche dann verwendet wird, wenn das DPRS initialisiert wird.

Während des Initialisierungsprozesses lädt das DPRS die Trapdefi­ nitionen von der Trapdefinitionsdatei (Schritt 70). Man beachte, daß das DPRS Trapdefinitionen direkt von einer Datei oder in ir­ gendeiner anderen Weise laden kann, z. B. über eine Scriptdatei, welche einen Befehl zum Laden von Traps enthält. Weiterhin können Traps von dem externen Hostrechner über die Kommunikationsleitung, von dem Benutzer über Menüs oder Eingabedialogboxen oder über das Betriebssystem geladen werden. Das DPRS verwendet dann die Trapde­ finitionen in der Trapdefinitionsdatei, um die Trapkette zu defi­ nieren (Schritt 72). Die ADD-Trapfunktion wird verwendet, um jeden Datensatz der Trapkette hinzuzufügen. Während des Betriebs des DPRS wird jedes Zeichen oder Byte, welches von dem externen Host­ rechner gesendet wird, von dem DPRS über die Kommunikations­ schnittstelle 40 (Fig. 3) empfangen. Das DPRS geht die Trapkette einzeln auf die Suche nach einem Befehl durch, welcher den empfan­ genen Zeichen entspricht. Die Steuerung wird der Befehlserken­ nungsroutine 56 (Fig. 5) in jedem einzelnen Trap übergeben, um zu versuchen, eine Entsprechung zwischen dem Eingabezeichen/Eingabe­ byte und der Befehlsdefinition 54 zu finden (Schritt 74). Wenn die Eingabezeichen/Eingabebytes dem "Befehl" eines bestimmten Traps entsprechen, wird die Antwortroutine für dieses spezielle Trap aufgerufen, um die Funktion des Befehls unter Verwendung der Para­ meter auszuführen, welche in dem Parameterfeld 60 des Traps ge­ speichert sind (Schritt 76). Der Schritt des Suchens nach einer Entsprechung und des Ausführens der entsprechenden Antwortroutine wird immer wieder wiederholt, bis der DPRS-Prozeß beendet wird (Schritt 77).

Die Befehle oder Dienste zum Hinzufügen, Löschen oder Ändern von Traps sind Teil des Befehlsrepertoires des Wartungsmoduls 44 (Fig. 3). Dies gestattet es einem Benutzer, Befehle zum Ändern der Traps während des Betriebs des DPRS zu definieren. Die ADD-Trapfunktion hat die Wirkung, neue Traps der Trapkette hinzuzufügen. Ein Spei­ cher wird dem Trapdatensatz zugeordnet, seine Felder werden mit den Trapdaten aufgefüllt und der neue Datensatz wird der Trapkette hinzugefügt.

Die DELETE-Trapfunktion hat die Wirkung, daß sie ein vorhandenes Trap löscht. Unter Verwendung eines Trapdatensatzes als Parameter geht sie die Liste nach einer Entsprechung mit einem identischen Datensatz durch. Wenn eine Entsprechung gefunden wird, wird der Datensatz aus der Liste genommen und der von dem Datensatz verwen­ dete Speicherplatz wird dem Betriebssystem zurückgegeben.

Die CHANGE-Trapfunktion hat die Wirkung, ein bestimmtes Trap zu ändern. Die Eingabeparameter definieren einen neuen Trapdatensatz, welcher einen bestehenden Datensatz ersetzen soll.

Weiterhin kann eine CLEAR ALL genannte Funktion definiert werden, um alle vorhandenen Traps zu beseitigen. Wenn die Liste nicht leer ist, entfernt die Funktion CLEAR ALL alle Datensätze aus der Liste und gibt den Speicherplatz, welcher von der gesamten Liste in An­ spruch genommen wurde, an das Betriebssystem zurück.

Das Wartungsmodul innerhalb des DPRS muß zumindest die ADD-Trap­ funktion aufweisen, so daß es in der Lage ist, neue Traps hinzuzu­ fügen oder zu erzeugen. In einer bevorzugten Ausführungsform weist das Wartungsmodul jedoch auch die Trapfunktionen DELETE, CHANGE, und CLEAR ALL auf. In einer alternativen Ausführungsform können dem Wartungsmodul weitere Funktionen hinzugefügt werden.

Ein Implementierungsbeispiel des Inhalts einer Trapdefinitionsda­ tei ist in Fig. 7B illustriert. Das folgende einfache Beispiel soll als Hilfe beim Verstehen des Funktionsprinzips der Erfindung dienen. Es wird lediglich zu Zwecken der Illustration gegeben und beschränkt in keiner Weise den Umfang oder die Anwendung der Er­ findung. Die Trapdefinitionsdatei kann jedes geeignete Format oder jede geeignete Struktur aufweisen. Das einzige Erfordernis besteht darin, daß sie ausreichend groß ist, um alle Trapdatensätze und ihre Felder aufzunehmen.

In diesem Beispiel werden die folgenden Optionen der Ver­ gleichsroutine zur Verfügung gestellt:

• 1. Zeichenkettenvergleich - fallabhängig
• 2. Zeichenkettenvergleich - nicht fallabhängig
• 3. Vergleich eines regulären Ausdrucks
• 4. VT100 - Befehlsprozessor.

Entsprechend sind die Optionen für die Antwortroutinen die folgen­ den:

• 1. Löschen des Bildschirms
• 2. Schreiben einer Nachricht
• 3. Einblenden eines Menüs
• 4. Einblenden einer Nachrichtenbox
• 5. Verlassen des Programms
• 6. Senden einer Windows-Nachricht
• 7. Starten eines Windows- oder DOS-Programms
• 8. Ausführen eines Scripts.

Eine Illustration des Formats jedes Datensatzes 80 in der Trapde­ finitionsdatei ist in Fig. 7A gezeigt. Die vier Felder des Daten­ satzes entsprechen den vier Elementen des in Fig. 5 illustrierten Traps. Das erste Feld 82 ist das Musterfeld, welches dem Befehls­ format 54 der Fig. 5 entspricht. Das zweite Feld ist das DD-Feld 84, welches zwei Ziffern enthält, welche der Befehlserkennungsrou­ tine 56 (d. h. der Vergleichsroutine) entsprechen. Das dritte Feld ist das RR-Feld 86, welches ein Zweizifferncode für die Antwort­ routine 58 ist. Das vierte Feld ist das Parameterfeld 88, welches dem Parameterfeld 60 entspricht.

Die Trapdefinitionsdatei basiert in diesem Beispiel auf ASCII und ihr Inhalt ist in Fig. 7B dargestellt. Wie vorangehend ausgeführt wurde, wird die Trapkette vorzugsweise als verkettete Liste von Traps implementiert. Jeder Trapdatensatz besitzt eine Musterzei­ chenkette, einen Code für eine Erkennungsprozedur, einen Code für Antwortroutine und eine Parameter-Zeichenkette.

Jede Zeile in der Trap-Definitionsdatei wird nun genauer erläu­ tert. Das erste Feld ist die Befehlsdefinition, gefolgt von dem Vergleichsroutinencode, dem Antwortroutinencode und den Parame­ tern. Die erste Definition oder Zeile ist ein Datensatz, welcher den Befehl "Login:" definiert, der für Vergleichszwecke nicht fallabhängig sein soll, was durch das "02" angegeben wird. Das "08" zeigt an, daß die Antwort darin besteht, ein Script auszufüh­ ren, dessen Name "Autolog.cmd" ist.

Die zweite Definition definiert den Befehl "Logged out", welcher ebenfalls für Vergleichszwecke nicht fallabhängig sein soll, was durch das "02" angegeben wird. Das "05" zeigt an, daß dann, wenn "Logged out" detektiert wird, das Programm abschließen und zu dem Betriebssystem zurückspringen soll.

Die dritte Definition implementiert jeden Befehl in dem standard­ mäßigen VT100-Befehlsprozessor. Das "" zeigt eine Nullbefehldefi­ nition an, das "04" bezeichnet den VT100-Befehlssatz, das "00" steht für keine Antwortroutine und das "" bedeutet keine Parame­ ter. In dieser Definition gibt es keine Befehle, Antworten oder Parameter, weil der VT100-Befehlsprozessor bereits verschiedene Befehlsdefinitionen und ihre zugehörigen Antworten enthält.

Alternativ kann die Erfindung unter Verwendung von Techniken der Verfahren zur objektorientierten Programmierung (OOP) konstruiert werden. In einer OOP-Implementierung würde jedes Trap seinen eige­ nen individuellen Objekttyp enthalten. Das Objekt würde das fol­ gende enthalten:

• - ein Muster,
• - Parameter für die Antwortroutine/den Antwortcode.

Weiterhin würde jedes Objekt die folgenden Routinen enthalten:

• - Erzeugen - Initialisieren des Objekts und Einsetzen in die Trapkette,
• - Überprüfen - Empfangen von Eingabedaten und Überprüfen der­ selben auf eine Entsprechung mit dem Muster
• - Antwort - Ausführen der Antwortroutine, wenn eine Entspre­ chung gefunden wird,
• - Löschen - Entfernen des Objekts aus der Trapkette und Lö­ schen desselben.

Die OOP-Implementierung selbst kann verschiedene Varianten aufwei­ sen. Sie folgen jedoch alle demselben Prinzip, welches umfaßt:

• 1. eine Kette von Objekten (d. h. Traps)
• 2. einen wohldefinierten Vergleichsalgorithmus oder eine wohldefinierte Vergleichsroutine für jedes Trap
• 3. eine wohldefinierte Antwortroutine für jedes Trap
• 4. eine Muster- oder Befehlsdefinition
• 5. null oder mehr Parameter für die Antwortroutine.

Während die Erfindung mit Bezug auf eine beschränkte Anzahl von Ausführungsformen beschrieben wurde, wird man erkennen, daß viele Varianten, Abwandlungen und andere Anwendungen der Erfindung durchgeführt werden können.

Claims (22)

1. Dynamisches Mustervergleichssystem (DPRS) zur Verwendung in einem mit einer Kommunikationsverbindung gekoppelten Kom­ munikationssystem, welches umfaßt:

• - eine Kommunikationsschnittstelle, welche mit der Kommunika­ tionsverbindung gekoppelt ist, wobei die Kommunikations­ schnittstelle das DPRS an die Kommunikationsverbindung kop­ pelt,
• - eine mit der Kommunikationsschnittstelle gekoppelte Verar­ beitungseinrichtung zum Verarbeiten von Eingabedaten, wel­ che über die Kommunikationsverbindung empfangen werden, und
• - ein Trapkette, welche aus mehreren Traps besteht, wobei die Traps einem Satz von Befehlen entsprechen, welche die Funk­ tionalität des DPRS definieren und jedes Trap einem eindeu­ tigen Befehl entspricht.

2. System nach Anspruch 1, gekennzeichnet durch eine Einrichtung zum Hinzufügen von zusätzlichen Traps zu der Trapkette entsprechend Befehlen, welche über die Kom­ munikationsverbindung empfangen werden.

3. System nach Anspruch 1 oder 2, gekennzeichnet durch eine Ausgabeschnittstelleneinrichtung, welche mit zu­ mindest einer Ausgabevorrichtung gekoppelt ist, wobei die Ausgabeschnittstelleneinrichtung zum Ausgeben von Zeichen­ daten und/oder Bytedaten von dem DPRS an die Ausgabevor­ richtung dient, die zumindest vorhanden ist.

4. System nach einem der Ansprüche 1 bis 3, dadurch ge­ kennzeichnet, daß die Verarbeitungseinrichtung von einem Benutzer erhaltene Daten verarbeitet.

5. System nach einem der Ansprüche 1 bis 4, dadurch ge­ kennzeichnet, daß die Verarbeitungseinrichtung von einem Betriebssystem erhaltene Eingabedaten verarbei­ tet.

6. System nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß zusätzliche Traps der Trapkette entsprechend Befehlen hinzugefügt werden, welche es von dem Benutzer empfängt.

7. System nach einem der vorangehenden Ansprüche, ge­ kennzeichnet durch eine Einrichtung zum Löschen von Traps aus der Trapkette entsprechend Befehlen, welche über die Kommunikationsverbindung empfangen werden.

8. System nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die Trapkette eine verket­ tete Liste von Traps enthält.

9. System nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die Trapkette ein Feld von Traps enthält.

10. System nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß jedes Trap innerhalb der Trapkette ein Befehlsdefinitionsfeld, ein Befehlsver­ gleichsroutinenfeld, ein Antwortroutinenfeld und ein Para­ meterfeld aufweist.

11. System nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß jedes Trap in der Trapket­ te ein Objekt enthält.

12. System nach Anspruch 11, dadurch gekennzeich­ net, daß jedes Objekt eine Musterdefinition, eine Ver­ gleichsroutine, eine Antwortroutine und null oder mehr Pa­ rameter für die Antwortroutine enthält.

13. Verfahren zum dynamischen Vergleichen von Mustern in einem Kommunikationssystem, welches mit einer Kommunikationsver­ bindung gekoppelt ist, wobei das Kommunikationssystem meh­ rere Trapdefinitionen enthält, welches die folgenden Schritte umfaßt:

- Konstruieren einer Trapkette aus dem Inhalt von mehreren Trapdefinitionen,

- Suchen nach einer Trapentsprechung zwischen den Zeichen, welche über die Kommunikationsverbindung empfangen wer­ den und jeder der Trapdefinitionen und

- für jede aufgefundene Trapentsprechung, Ausführen einer Antwortroutine, welche dem die Entsprechung aufweisenden Trap zugeordnet ist.

14. Verfahren nach Anspruch 13, gekennzeichnet durch den Schritt des Ladens der Trapdefinitionen.

15. Verfahren nach einem der Ansprüche 13 oder 14, dadurch ge­ kennzeichnet, daß der Schritt des Konstruierens einer Trapkette den Schritt des Konstruierens einer Liste von individuellen Traps umfaßt.

16. Verfahren nach einem der Ansprüche 13 oder 14, dadurch gekennzeichnet, daß der Schritt des Konstruie­ rens einer Trapkette den Schritt des Konstruierens eines Felds von individuellen Traps umfaßt.

17. Verfahren nach einem der Ansprüche 13 bis 16, dadurch ge­ kennzeichnet, daß jedes Trap in der Trapkette ein Befehlsdefinitionsfeld, ein Befehlsvergleichsroutinen­ feld, ein Antwortroutinenfeld und ein Parameterfeld umfaßt.

18. Verfahren nach einem der Ansprüche 13 bis 16, dadurch gekennzeichnet, daß jedes Trap in der Trapket­ te ein Objekt enthält.

19. Verfahren nach Anspruch 18, dadurch gekennzeich­ net, daß jedes Objekt eine Musterdefinition, eine Ver­ gleichsroutine, eine Antwortroutine und null oder mehr Pa­ rameter für die Antwortroutine umfaßt.