DE69130766T2

DE69130766T2 - Intelligentes hilfssystem

Info

Publication number: DE69130766T2
Application number: DE69130766T
Authority: DE
Inventors: Charles Lanier; Leticia Villegas; Richard Wolf
Original assignee: AST Research Inc
Current assignee: Samsung Electronics Co Ltd
Priority date: 1990-08-02
Filing date: 1991-07-17
Publication date: 1999-09-02
Anticipated expiration: 2011-07-18
Also published as: DE69130766D1; USRE39302E1; EP0541712B1; AU8401991A; HK1012102A1; WO1992002880A1; US5103498A; EP0541712A1; EP0541712A4; SG48223A1

Description

GEBIET DER ERFINDUNG

Diese Erfindung betrifft Hilfssysteme für Computer; spezifischer betrifft sie Hilfssysteme, die einen Anwender eines Computers durch Bereitstellung kontextsensitiver Hilfe unterstützen.

HINTERGRUND DER ERFINDUNG

Um einen Computer effektiv zu betreiben, muß ein Anwender eine Anzahl von Befehlen und Datenformaten beherrschen. Man erreicht dies gewöhnlich durch Einsatz von Stunden zum Lesen gedruckter Anwenderdokumentation und/oder durch Anwendung von trial and error-Techniken.
Es sind bereits computerunterstützte Hilfssysteme entwickelt worden, die eine on-line Unterstützung für Computeranwender ermöglichen. Als Antwort auf eine Anforderung durch einen Anwender zeigen diese Systeme Hilfsinformation auf dem Anzeigeschirm des Computers an. Einfache Hilfssysteme starten unabhängig von den Umständen stets mit der gleichen Anzeige und der Anwender muß spezifische Informationen eingeben, um Hilfe für seine oder ihre besondere Situation zu finden. Fortgeschrittenere Hilfssysteme zeigen kontextsensitive Hilfe an. Kontextsensitive Hilfssysteme ermitteln, in welchem speziellen Teil eines Anwendungsprogramms sich der Anwender befindet. Es wird dann Hilfsinformation angezeigt, die relevant für diesen Anwenderstandort ist.
Während solche kontextsensitiven Hilfssysteme eine Verbesserung gegenüber einfachen Hilfssystemen darstellen, weisen sie zahlreiche Beschränkungen auf. Derartige Systeme sind üblicherweise eng an ein Anwendungsprogramm gekoppelt; sie müssen sich auf das Anwendungsprogramm stützen, um den Kontext zu verfolgen und zu speichern. Da diese Systeme auf die Anzeige von Hilfsinformation auf Basis des Programmstandortes limitiert sind, liefern diese des weiteren stets die gleiche Hilfsinformation für einen gegebenen Standort unabhängig davon, wie der Anwender dorthin gelangte. Während solche Systeme die. Annehmlichkeit einer on-line Hilfe ermöglichen, ist die Hilfsinformation, die sie erbringen, nicht mehr als ein Anwenderhandbuch, welches auf einen gegebenen Programmbildschirm oder eine Funktion bezogen ist. Im Ergebnis neigen diese Hilfssysteme dazu, von begrenzter Nützlichkeit für den Anwender zu sein, der nicht spezifisch das Problem, identifizieren kann oder der "seinen Weg verloren" hat.
Die EP-A-0436459 beschreibt ein intelligentes Hilfssystem, welches Hilfsinformation bereitstellt, nachdem ein Anwender ein fehlerhaftes Kommando oder eine Frage eingibt.

ZUSAMMENFASSUNG DER ERFINDUNG

Die Erfindung erkennt einen Bedarf an einem intelligenten Hilfssystem, welches Informationen, die spezifisch für die Anwendervorgeschichte sind, wie Tasks, die er oder sie erfolgreich ausgeführt hat (und wie oft) oder vorangehend Hilfe dazu hatte, und Informationen, die einen Status einer Maschine und einen Status einer programmierten Anwendung definieren, verarbeitet.
Gemäß der Erfindung wird ein intelligentes Hilfssystem zur Unterstützung eines Anwenders eines Computerprogramms mittels Pflege einer historischen Schlange und Verwendung von Techniken der künstlichen Intelligenz vorgeschlagen, um Hilfsinformation, die auf anwendergesteuerten Ereignissen und dem gegenwärtigen Status des Systems basiert, auszuwählen. Insbesondere werden anwendergesteuerte Aktivitäten überwacht und in der historischen Schlange innerhalb einer Wissensbank gespeichert. Systemzustände werden ebenfalls überwacht und gespeichert. Die Wissensbank wird dann von einer Folgerungsmaschine eingesetzt, um die spezifische Art von Hilfe, die der Anwender benötigt, zu isolieren. Somit wird dem Anwender auf Anfrage Unterstützung gegeben, die passend für den Level dieses Anwenders im Verständnis oder der Erfahrung und für die gegenwärtigen Aktivitäten, die er oder sie ausgeführt hat, ist.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 ist ein Blockdiagramm eines Computersystems, in welchem die Erfindung verkörpert sein kann.
Fig. 2 ist ein Blockdiagramm eines Computersoftwaresystems, das in der bevorzugten Ausführungsform verwendet wird.
Fig. 3a illustriert die Verarbeitung von anwendergesteuerten Ereignissen und Systemzuständen zu Hilfsinformation.
Fig. 3b ist ein Flußdiagramm der generellen Verfahren des Hilfssystems.
Fig. 4 ist ein Flußdiagramm einer Anfrage durch die Überprüfungseinheit.
Fig. 5A-B zeigen ein Flußdiagramm der Verfahren der Ereignisinterpreter.
Fig. 6 ist ein Flußdiagramm der Verfahren zum Verarbeiten von Ereignissen.
Fig. 7 ist ein Flußdiagramm der Verfahren zur Identifizierung von Tasks.
Fig. 8 illustriert die Regeltaxonomie der Erfindung.
Fig. 9 illustriert Frames und Slots für die Speicherung von Wissen.
Fig. 10A-B zeigen ein Flußdiagramm der Verfahren zum Überprüfen von Regeln.
Fig. 11 illustriert den Betrieb der Anzeigemaschine.

DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM

Unter Bezugnahme auf Fig. 1 ist die bevorzugte Ausführungsform der Erfindung auf einem Computersystem 100 implementiert, welches einen Zentralprozessor 102, einen Systemspeicher 103, eine Anzeigeeinheit 105, eine Tastatur 106, eine Maus 107, einen Plattenspeicher 108, einen I/O-Controller 101 und Verbindungsmittel 110, wie einen Systembus aufweist. In der bevorzugten Ausführungsform wird ein Tandy 1000 Series Computer (Tandy Corporation of Ft. Worth, Texas) als System 100 verwendet.
Unter Bezugnahme auf Fig. 2 wird ein Computersoftwaresystem 200 gezeigt, um das Computersystem gemäß Fig. 1 zu programmieren. Das Softwaresystem 200 ist im Systemspeicher 103 und auf dem Plattenprozessor 108 abgespeichert. Das System 200 programmiert den Zentralprozessor 102, um ein grafisches Anwenderinterface (GUI) auf dem Anzeigemonitor 105 anzuzeigen. In der bevorzugten Ausführungsform ist das Hilfssystem 204 in die Tandy DeskMate Umgebung 203 implementiert, die ein Softwareinterface 205 zwischen einem Anwender 206, einer Computeranwendung 202 und einem Betriebssystem 201 darstellt. Hinsichtlich der DeskMate Umgebung 203 ist hinreichend Detail angefügt, um ein Verständnis der Erfindung zu ermöglichen. (Anhang, DeskMate Systemübersicht und DeskMate Systemarchitektur). Es wird jedoch augenscheinlich, daß ein durch diese Spezifikation informierter Fachmann die Erfindung in anderen Betriebsumgebungen implementieren könnte.
In der bevorzugten Ausführungsform wird ein Paradigma künstlicher Intelligenz (Al) verwendet, um mit Wissen umzugehen, welches weitläufig und unbestimmt sein kann und zu mehreren Lösungen für eine gegebene Situation führt. Ein Al Modell besitzt die Fähigkeit, aus dem, was es bereits kennt, mehr Wissen zu erlernen oder zu folgern. Somit kann das System, wenn ein Anwender Hilfe anfordert und das Hilfssystem keine Lösung erhalten kann, weitere Informationen vom Anwender erhalten und sich dann an die Situation erinnern; beim nächsten Mal, wenn diese Situation auftritt, kann eine Lösung ohne erneutes Befragen des Anwenders angegeben werden.
Unter Bezugnahme auf Fig. 3A umfaßt das Hilfssystem 300 der bevorzugten Ausführungsform eine Überprüfungseinheit 320 zum Sammeln von Daten, die in Antwort auf anwendergesteuerte Ereignisse und Systemzustände 310 erzeugt werden, eine Wissenbank 330 zum Speichern von Daten 331 zusammen mit einer Hilfsinformationsdatenbank 335, die zur Ermittlung der besten zu gebenden Hilfe verwendet wird, eine Folgerungsmaschine 340 zum Interpretieren von Daten 331 und der Hilfsinformationsdatenbank 335 in der Wissensbank 330, und einer Anzeigemaschine 350 zum. Präsentieren geeigneter Hilfsinformation 360 auf einer Anzeigeeinheit 105. Die Daten 331 umfassen eine historische Schlange 332 und ein Statusdata 333, während die Hilfsinformationsdatenbank 335 eine Vielzahl von Regeln 334 und Text 336 enthält.
Fig. 3B ist ein Flußdiagramm, welches die generellen Verfahren des Hilfssystems 300 illustriert. Im Schritt 351 werden anwendergesteuerte Ereignisse und Systemzustände überprüft. Anwendergesteuerte Ereignisse sind die Aktivitäten, die ein Anwender in einem Anwendungsprogramm durchführt, z. B. Speichern einer Datei in einer Zeichenanwendung oder Kopieren eines Textblocks in einer Textverarbeitungsanwendung. Der Systemstatus enthält einen Maschinenstatus und einen anwendungsspezifischen Status. Im Schritt 352 wird die im Schritt 351 gesammelte Information als Fakt oder Daten 331 der Wissensbank 330 gespeichert. Spezifisch werden sequentielle anwendergesteuerte Ereignisse in der historischen Schlange 332 gespeichert und Wissen über das System wird als Statusdaten 333 gespeichert. Falls in Schritt 353 der Anwender Hilfe anfordert (z. B. Drücken der F1 Taste), dann prüft in Schritt 355 die Folgerungsmaschine 340 bekannte Daten 331 gegen Hilfssystemregeln 334. Falls jedoch keine Hilfe im Schritt 353 angefordert wird, springt die Routine zurück zum Überprüfungsschritt 351.
Die Wissensbank 330 speichert Heuristik in Form von Regeln. Die Regeln 334, wie die im Schritt 355 verwendeten, sind Prämisse-Ergebnis-Aussagen, die von einem Anwendungsentwickler vordefiniert sind und die Folgerungsmaschine 340 bei der Auswahl einer Ausgabe führen. Zum Beispiel angenommen, ein Anwender befindet sich in einer Text-Listbox (Textverarbeitung) und keine Daten sind ausgewählt. Eine Regel, die dieses prüfen würde, ist:
if
no files
running.listbox TEXT
then
help running text
Diese Regel versucht durch Bestätigen ihrer Prämisse "no files." zu "greifen". Zuerst prüft sie die bekannten Daten 331 in der Wissensbank 330. Falls diese nicht in den Daten 331 enthalten ist, prüft sie nach anderen Regeln mit dieser Prämisse als deren Ergebnis. Falls im Schritt 356 eine Übereinstimmung gefunden wird, greift die entsprechende Regel als nächstes in Schrift 357. Im Schritt 358 wird als Antwort auf die spezielle Regel, die greift, ein Ergebnis angegeben und geeignete Hilfsinformation 360 angezeigt. Das Format der Regeln in dieser Ausführungsform wird nachfolgend unter Bezugnahme auf Fig. 8 beschrieben.
Die Überprüfungseinheit 320 und ihre Funktionen werden nun im Detail beschrieben. Da die Überprüfungseinheit 320 Anwendereingaben verfolgt oder überprüft, hat sie Verarbeitungsfähigkeiten. Sie kann Daten in der Wissensbasis 330 nach Indentifizieren einer Sequenz von einem oder mehreren Ergebnissen oder Zuständen angeben. Sie kann Daten betreffend Zustände, die nicht länger wahr sind, entfernen oder widerrufen oder einen neuen Wert für alte Daten erneut angeben. Sie verfolgt die Anzahl, in der eine Aktivität von einem Anwender erfolgreich abgeschlossen worden ist.
Die Überprüfungseinheit 320 überprüft verschiedene Typen von Information, einschließlich Maschinenzustände, anwendungsspezifische Zustände und historische Information. Der Maschinenstatus beinhaltet den gegenwärtigen Systemlevel, wie etwa innerhalb einer Anwendung oder Zubehör, Betrieb einer Komponente, oder auf dem Desktopinterface. Ein Zubehör ist eine Anwendung, die über einer anderen Anwendung "aufgeklappt" werden kann. Beispiele von Zubehör beinhalten einen Aufklapp-Rechner, Kalender oder Wecker. Eine Komponente ist ein grafisches Element, das mit einem Anwender zur Anzeige und zur Annahme von Information vom Anwender zusammenwirkt. Zum Beispiel beinhalten die Komponenten in einer Dialogbox Radioknöpfe, Druckknöpfe und Eingabefelder. Die Menüleiste ist ebenfalls eine Komponente.
Die Überprüfungseinheit 320 überprüft auch anwendungsspezifische Zustände (application specifics) einschließlich einmalige Information zu einer Anwendung und Komponentenzustände einschließlich Information innerhalb des gegenwärtigen Maschinenstatus, der entweder anwendungsspezifisch oder allgemein ist, aber in der gleichen Weise in jeder Anwendung erzeugt wird. Zum Beispiel werden in allen Anwendungen, die eine Menüleiste aufweisen, Auswahlen durch Selektieren eines Items aus dem Menü getroffen.
Die Überprüfungseinheit 320 verfolgt auch historische Information, die den Abschluß eines Tasks, für den Hilfe definiert wurde, indiziert. Diese Daten werden in der historischen Schlange 332 gespeichert. Ein erfolgreicher Abschluß indiziert, daß der Anwendung nicht länger Hilfe bei der Durchführung dieses Tasks benötigt. Es kann spezifischere Hilfsinformation anstelle allgemeiner Information gegeben werden, je mehr Erfahrung der Anwender mit einem Programm erwirbt.
Die Struktur der historischen Schlange 332 wird nun im Detail beschrieben. Für jeden Zugang wird ein Zugangstyp gespeichert. Zum Beispiel fügt die Überprüfungseinheit 320, wenn der Anwender eine Dialogbox betreibt, einen Dialogboxzugang (CMP_DLG_BOX) der historischen Schlange 332 hinzu und speichert dann das zugehörige Eingabefeld, Listbox, Radioknopf, Iconknopf und Checkbox-Information. Jeder Zugang in die historische Schlange 332 kann in Abhängigkeit vom Typ des erfolgten Zugangs von variabler Länge sein. Ein einmaliger "return code" wird jeder Komponente zugewiesen, um die Unterscheidung zwischen den Komponenten zu erleichtern. Ein Fernzeiger auf eine Zugangsstruktur (z. B. Dialogbox, Komponente und/oder Menüleistenstrukturen) wird gespeichert, um direkten Zugriff auf diese Struktur zu ermöglichen. Hierauf folgend wird Dialog und Komponenteninformation kopiert. Das verwendete Format kann eine variable Länge aufweisen. Ein Unterzugangsflag wird definiert, um anzuzeigen, ob dort ein Unterzugang vorhanden ist. Zum Beispiel kann eine Komponente nach wie vor laufen, während die Menüleiste verarbeitet wird, so daß die Menüleiste Teil eines einzelnen Zugangs ist. Falls der Flag auf einen Wert wahr gesetzt wird, werden sämtliche Unterzugangsdaten gespeichert. Ein weiteres Flag wird definiert, um Tastendrucke des Anwenders, die während des Zugangs erfolgten, zu indizieren. Dies ermöglicht dem System z. B. zu ermitteln, ob der Anwender begonnen hat, Daten in eine Dialogbox einzugeben oder ob er unverzüglich Hilfe gewählt hat. Der Name der Box und Menüzugänge, wie DLGBOX, MSG BOX, LISTBOX oder MENU wird gespeichert, um eine Box von anderen zu unterscheiden. Ein drittes Flag wird definiert, um Tastendrucke des Anwenders, die vor dem Aufruf von Hilfe erfolgten, zu indizieren. Dies ermöglicht dem System zu ermitteln, was der Anwender in der Anwendung machte.
Variablen, die eine historische Schlange 332 manipulieren, sind wie folgt definiert:
ihm_HelpQ: Die 500 byte Schlange, eine ist in jedem Task-Datenbereich der Core Service Routine (CSR) vorhanden.
ihm_TOP: Der physikalische Start des HelpQ-Puffers.
ihm ENDQ: Das physikalische Ende des HelpQ-Puffers.
ihm_start_ptr: Zeiger auf den ersten Zugang in die Schlange (welcher historisch der letzte ist).
ihm_cur_ptr: Zeiger auf das erste Byte des letzten Zugangs in der HelpQ.
ihm_end_ptr: Zeiger auf das letzte Byte der in die HelpQ eingegebenen Daten.
ihm_save_ptr: Der ptr Wert des letzten erstellten Zugangs, gespeichert da ein ungültiger ptr in die HelpQ als eine NULL eingegebenen wurde.
ihm_menu_ptr1: Doppelwortzeiger auf die gegenwärtige Menüleiste. Aktualisiert jedesmal, wenn mb_draw aufgerufen wird.
Die Datenstruktur der Schlange kann wie folgt zusammengefaßt werden:
dw - offset des vorangehenden Zugangs
dw - typ
dw - return code
dw - struct ptr-offset
dw - struct ptr-Segment
db - # Unterzugänge
db - Länge des Namens
db(?) - Name von dlg box, msg box, Menu, Listbox
db - keyflag - irgendwelche Maus- oder Tastenereignisse vor Zugang?
db(?) - Unterzugangsdaten
db - keyflag - irgendwelche Maus- oder Tastenereignisse während Zugang?
dw - Länge der kopierten Information oder 0
In der bevorzugten Ausführungsform tritt die Überprüfung von Information an verschiedenen Stellen im Softwaresystem 200 auf. Alle Statusveränderungen, die in einer Ausführung von Dialog und Mitteilungsboxen resultieren, werden überprüft. In der DeskMate Umgebung 203 werden Befehle vom Anwender über eine Menüleiste eingegeben und von Ereignisinterpretern, die auf Menüleistenveränderungen prüfen, verarbeitet. Zusätzlich können die Anwendungsprogramme selber Statusveränderungen in ihren jeweiligen Arbeitsbereichen indizieren.
Die DeskMate Umgebung 203 ist in die folgende Hierarchie von Levelveränderungen unterteilt, um die Aufgabe des Überprüfers, Information zu aktualisieren, zu vereinfachen:
1. Top level zu Anwendung/Zubehör oder Menüleiste/Komponente;
2. Anwendung zu Zubehör oder Menüleiste/Komponente oder Rückkehr zu Top level;
3. Zubehör zu Menüleiste/Komponente oder Rückkehr zu Anwendung oder Top level.
Zu den folgenden Zuständen wird spezifische Information benötigt: Anwendung läuft oder wurde geschlossen; welche Anwendung läuft; Zubehör läuft oder wurde geschlossen; welches Zubehör läuft; Dialogbox läuft oder wurde geschlossen; Mitteilungsbox läuft oder wurde geschlossen; Komponente läuft oder wurde geschlossen; Menüleiste wurde heruntergezogen oder zurückgegeben; Anwender auf Desktop; falls Anwender nicht im Top level, der erreichte Level vor dem gegenwärtigen. Die Variable; "level" nimmt die Werte von DeskTop, Menüleiste, Dlg_box, Message_box, Info_box oder Komponente an. Die Überprüfung kann die Statusänderung durch Erhalt der Adressaufrufe aus der DeskMate Umgebung 203 erhalten, die einen Funktionsaufruf für ein Anwendungsprogramm oder eine Ressource indizieren.
Die Fig. 4 illustriert, wie die Überprüfungseinheit 320 nach der Adresse von Aufrufen, an denen sie interessiert ist, anfragt. In der DeskMate Umgebung 203 rufen Anwendungen Core Service Routinen (CSR) auf, um Komponenten und Dialog-, Informations- und Mitteilungsboxen laufen zu lassen. Ein Menüleisteninterpreter handhabt die Verarbeitung der Menüleiste. Deshalb können unabhängig von einer Anwendung, die Aufrufe, die die Strukturen verändern, welche die Anwendung verwendet, überprüft werden, um Informationsveränderungen zu verfolgen.
Somit sind die Schritte wie folgt. Im Schritt 401 wird ein Zugangsaufruf zu einer Core Service Routine getätigt. In Schritt 402 wird der Komponententyp identifiziert und dann mit einer Liste von Komponenten, an denen die Überprüfungseinheit 320 interessiert ist, verglichen. Falls im Schritt 403 die Komponente in der Tafel gelistet ist, nimmt dann im Schritt 404 die Überprüfungseinheit 320 die Anwendungsparameter und ihren Strukturzeiger auf, um Daten aus den Anwendungsstrukturen zu kopieren. Die Strukturen werden nicht modifiziert. Beim Ausstieg des Dienstes und bevor die Steuerung der Anwendung zurückgegeben wird, greift die Überprüfungseinheit 320 im Schritt 405 erneut auf Daten in den Strukturen zu, dieses Mal zum Zweck von Aktualisierungen der historischen Information.
Da eine Unterscheidung zwischen Anwendungen und Zubehör gemacht wird, wird eine Variable "program" definiert, um zu indizieren, welches spezielle Programm läuft. Programm nimmt den Wert des Programmnamens, welcher das gleiche Identifizierungsmittel für die Hilfsinformationsdatenbank 335 im Zusammenhang mit der Anwendung oder Zubehör ist, an.
Zwei Ereignisinterpreter nehmen Menüleistenveränderungen auf. Das ausgewählte Menü ist wichtig für den Status, während das zurückgegebene Item wichtig für die Historie ist. Ein Ereignisinterpreter hoher Priorität nimmt die Menüleistenveränderungen auf, wenn Hilfe angefordert wird und ein Ereignisinterpreter niedriger Priorität erledigt alle Veränderungen aus dem Menüleisten-Returncode. Der Interpreter hoher Priorität prüft Ereignisse zuerst vor jeglicher weiterer Verarbeitung durch das DeskMate System. Auf der anderen Seite prüft der Interpreter niedriger Priorität Ereignisse, nachdem sie durch das DeskMate System verarbeitet worden sind.
Die Figuren 5A-B illustrieren das Verfahren der Ereignisinterpreter. Im Schritt 501 registriert die Anwendung die Menüleiste mit der Überprüfungseinheit 320. Falls der Anwender bei Schritt 502 die F1 (Hilfe) Taste ausgewählt hat, wird dann bei Schritt 503 die Statusinformation gemäß in welchem Level das System betrieben wird (indiziert durch die Variable "level") aktualisiert. Falls level im Schritt SO&sub4; null entspricht, ist dann die Menüleiste das letzte veränderte Element, von daher wird eine Menüleistenaktualisierung benötigt. Bei Schritt 505 führt der Menüleisteninterpreter eine Aktualisierung durch. Jedoch wird, falls "level" nicht null ist, der Schritt 505 übersprungen. Bei Schritt 506 prüft der Interpreter niedriger Priorität den Ereignistyp. Falls dieser im Schritt 507 die Menüleiste ist (level = menubar), dann führt im Schritt 508 der Interpreter niedriger Priorität eine Historie-Aktualisierung durch, die durch Aufnahme des Returncode und Vergleich seines Wertes mit den Menüleisten-Menüs durchgeführt wird. Der mit dem Returncode korrespondierende String ist das interessierende Item. Bei Schritt 509 springt die Routine zurück auf Schritt 501, um einen anderen F1-Tastendruck zu erwarten.
Die mit den Funktionen der obigen Komponenten assoziierten Regeln sind in der Weise geschrieben, daß falls eine Komponente einen Titelstring aufweist, dieser String verwendet wird, um ihre Hilfequelle zu identifizieren. Falls eine Komponente keinen Titelstring aufweist, wird dann der Name der Komponente als ihr Identifikationsmerkmal verwendet.
Da alle Anwendungen die Merkmale der DeskMate Umgebung 203 nutzen, ist eine Standard-Wiedergabe von Daten 331 und Regeln 334 möglich: Zum Beispiel können die folgenden Variablen verwendet werden, um Ereignisse und Zustände zu indizieren:
menu.selected
menu.item.selected
dlg.box.running
dlg.box.focus
msg.box.running
cmp.running
listbox.item.selected
checkbox.item.selected
Anwendungsspezifische Information wird erhalten, indem die Anwendung Daten in den gegenwärtigen Statusdaten 333 in der Wissensbank 330 angibt. Die Anwendung vollbringt dies durch Durchführen eines Aufrufs zu einer "Assert"-Funktion mit den Parametern "Variable" und "Wert", die Zeiger auf Strings sind. Die Variable sollte eine Variable in der Regelprämisse erfüllen, d. h. die Regel muß im voraus definiert sein. Eine Anwendung sollte jegliche historische Information in Bezug auf ihre einmalige Statuskonfiguration angeben. Anwendungsdaten werden aus den gegenwärtigen Statusdaten 333 von der Anwendung durch Aufrufen einer "Retract"-Funktion entfernt, da diese Daten nicht länger wahr sind. Obwohl die Anwendungen direkt Daten in der Wissensbank 330 angeben können, ermitteln sie nicht, welche Hilfe zu geben ist. Statt dessen liefern sie die Eingaben für diese Ermittlung.
Historische Information wird durch Verwendung einer Anwender I. D. zur Identifikation der einmaligen historischen Information des Anwenders erhalten. Diese historische Information wird am Ende eines Taskabschlusses aktualisiert. Wenn der Anwender z. B. erfolgreich eine Kopierfunktion ausgeführt hat, erkennt die Überprüfungseinheit 320 dies durch Überprüfung, daß der Anwender "text" ausgewählt hat und dann "kopieren" aus dem Dateimenü ausgewählt hat. Nachdem sie ermittelt hat, daß der Anwender diesen Task beherrscht, aktualisiert die Überprüfungseinheit 320 die historische Information des Anwenders. Für historische Information, die mit den spezifischen Daten der Anwendung assoziiert sind, aktualisiert die Anwendung selbst die Information durch Aufruf der Funktion UpdateHistory mit einem Parameter, der auf einen die gerade abgeschlossene Aktivität repräsentierenden String zeigt.
Fig. 6 faßt das Verfahren zur Verarbeitung der Ereignisse von den Ereignisinterpretern zusammen. Bei Schritt 601 werden Ereignisse durch Prüfung der Mauskoordinaten und des Ereignistyps und Werts verarbeitet. Im Schritt 602 werden Ereignisse durch Versuche, eine Regel, die eine Dateneingabe oder einen Widerruf in der Wissensbank 330 durchführen würde, greifen zu lassen oder auszulösen, identifiziert. Diese Regeln repräsentieren alle Bedingungen, die zum Angeben oder Widerrufen von Daten wahr sein müssen. Falls eine Regel im Schritt 603 greift, dann ist das Ergebnis identifiziert, Schritt 604. Falls die Regel nicht greift, dann ist das Ereignis nicht identifiziert, Schritt 605.
Fig. 7 illustriert den in Schritt 602 (Fig. 6) verwendeten Ansatz zum Identifizieren eines Tasks (Sequenz von Ereignissen). In Schritt 701 wird ein Tasten- oder Mausereignis geprüft. Im Schritt 702 wird dann, falls das Ergebnis nicht mit der ersten Prämissenlinie in allen mit dem Systemlevel assoziierten Regeln übereinstimmt, das Ereignis in Schritt 704 verworfen. Andernfalls werden im Schritt 703 alle Regeln, die greifen, auf einer Agenda plaziert, die den/die wahrscheinlichsten Task(s) repräsentiert. Bei Schritt 705 werden die Regeln durch Prüfung der nächsten Tasten oder Mausereignisse, die hereinkommen, bestätigt oder widerlegt. Falls alle Regeln in der Agenda bei Schritt 706 fehlgehen, wird dann die erste analysierte Taste verworfen und die nächste Taste zur Suche nach neuen Regeln verwendet, Schritt 708; anderenfalls wird in Schritt 707 die Agenda gelöscht und die Prozedur springt zurück zu Schritt 701, um das nächste Tasten/Mausereignis zu prüfen.
Da die überprüfte Information abhängig vom Maschinenstatuslevel ist, werden die generierten Daten gemäß diesen Levels unterteilt. Die Überprüfungseinheit 320 versucht Daten anzugeben, die für einen gegebenen Level gelten. Jede Anwendung oder jedes Zubehör kann als ein selbständiges Objekt (als ein Level) aufgefaßt werden, das bestimmte Aktivitäten durchführt, von denen einige gleich mit anderen Objekten sind. Daher ist es günstig, die Überprüfungsdatenstruktur in "Frames" zu unterteilen. Ein Frame enthält die Aktivitäten, die jede Anwendung beherrscht, mit gegenwärtigen Werten und historischer Information. Die Frames weisen Slots zum Speichern der von den Regeln verwendeten Daten oder einem Zeiger auf einen anderen Frame auf.
In der bevorzugten Ausführungsform werden die Anwendereingabe und der Systemstatus durch, die Überprüfungseinheit 320 zur Weitergabe als Daten an die Wissensbank 330 zwecks Speichern analysiert. Befehle zum Steuern dieses Datenflusses zu und von der Wissensbank 330 sind definiert. Daten werden durch den Befehl Assert in Frames gespeichert. Alte Information wird durch den Befehl Retract gelöscht. Eine Abfrage an die Wissensbank 330, um Information zu erlangen, wird durch einen Befehl Query durchgeführt. Vorangehende Daten werden durch einen Befehl Reassert erneut angegeben.
Die Wissensbank 330 enthält formelles (tradionelle Datenbankinformation) und informelles (heuristisches) Wissen, das regelbasiert ist. Fig. 8 demonstriert die Regeltaxonomie. Am unteren Level der Regelhierarchie 800 steht eine einzelne Regel 804, die ein Muster-zu-Handlungs-Ziel definiert. Das Muster ist als die linke Seite einer Regel bekannt, während die Handlung die rechte Seite ist. Die Regeln verwenden die üblichen logischen Operatoren AND, OR und NOT, ebenso wie boolsche Operatoren wie IF, THEN und ELSE. Zusätzlich indiziert das Schlüsselwort TEST, daß ein Vergleich durchzuführen ist. Die rechte Seite einer Regel kann eine ELSE-Bedingung aufweisen, eine Angabe, einen Widerruf, eine andere Regel oder einen Prozeduraufruf. Zum Beispiel könnte in der Regel:
IF a THEN b, ELSE c
b eine Angabe, die Daten b den Daten 331 hinzufügen würde, sein; mehrfache Datenangaben sind möglich. Ein Widerruf würde Daten b aus den Daten 331 löschen:
IF a THEN (RETRACT b).
"Eine andere Regel" könnte wie folgt eingebettet sein:
IF a THEN b, IF (TEST (= bc)) THEN d.
Ein Beispiel eines Prozeduraufrufs würde sein:
IF a THEN (CALL HelpTutorial (a)).
Verknüpfte-Regeln 803 sind eine Verknüpfung zwischen Regeln, die das gleiche Ergebnis teilen. Dies ist eine Gestaltungsausführung, die dazu gedacht ist, den Folgerungsprozeß durch Kennen von alternativen Lösungswegen einfacher zu machen. Regelgruppen 802 gruppieren Regeln mit einem gemeinsamen Zweck. Regeln z. B. mit einem Ergebnis, das indiziert, welche spezifische Hilfe zu geben ist, sind alle Regeln, die den Zielstatus ermitteln. Eine Gruppe kann ein (optionales) Prioritätsidentifikationsmerkmal aufweisen, so daß die wichtigsten oder spezifischen Regeln bei der Suche zuerst ausprobiert werden können. Dies impliziert nicht, daß eine Regelgruppe bei einer Suche ausgelassen wird. Regelklassen 801 sind eine weitere Konzeptualisierung von Regeln. Sie separieren individuelle Wissensbanken, die jeweils ein eigenes Identifikationsmerkmal aufweisen, durch welches sie unterschieden werden. Dieses Idenfikationsmerkmal kann von einem Satz Steuerungsregeln verwendet werden, die die Maschinenstatusinformationen zum Indizieren von Wissensbankzugriff verwenden.
Die Prämisse jeder Regel enthält ebenfalls formelles oder informelles Wissen. Das informelle Wissen wird formell, wenn eine Regel erfolgreich greift. Das formelle Wissen wird in Framestrukturen in der Wissensbank 330 gespeichert und hierauf aus dieser zugegriffen. Frames können aus anderen Frames erstellt werden, die auch geteilt werden können. Mit dieser Datenstruktur ist es möglich, nur auf den mit der gegenwärtigen Statusinformation assoziierten Frame zuzugreifen, wenn die Überprüfungseinheit 320 die historischen Informationen des Anwenders aktualisiert. Die Frameslots sind ähnlich jedweder verknüpfter Liste, ausgenommen sie repräsentieren Handlungen und Attribute eines Objekts oder Konzepte, die die Frames repräsentieren. Da Frames die Beziehung zwischen einer Anwenderaktivität und der assoziierten Heuristik indizieren, die zum interpretieren dieser Aktivität verwendet wird, ist es einfach, nur auf relevante Information zuzugreifen. Fig. 9 illustriert einen Frame 901 mit seinen zugehörigen Slots 902.
Regelklassen 801 sind aufgebaut aus Zeigern auf die Variablen und Werte in den Frames. Die Slots, die einen anderen Frame enthalten, stellen tatsächlich eine andere Gruppe innerhalb einer Regelklasse dar. In einem framebasierten Schlußfolgerungssystem wählt man den zu bestätigenden Frame durch Auffüllen von Slotwerten aus: Die Slots enthalten die Regeln. Der erfolgreiche Abschluß eines Frames ergibt eine Lösung.
Die Syntax zum Schreiben der Regeln lautet:
BEGIN.RULECLASS
< id>
BEGIN.RULEGROUP
< id>
IF
(< Variable> IS < Wert> )
(< Wert> )
(NOT (< Variable> IS < Wert> ))
(TEST (< Variable> EQ < #> ))
THEN
(< Wert> )
END.RULEGROUP
END.RULECLASS
Zum Zwecke der Illustration und nicht zur Beschränkung, können die Regeln als Datenstrukturen codiert werden (dargestellt in der Sprache C):
Die Eingaben in die Wissensbank 330 sind die von der Überprüfungseinheit 320 gesammelten Daten. Die Ausgaben der Wissensbank 330 sind Daten 331 und Regeln 334, die die Folgerungsmaschine 340 zur Prüfung auswählt und Hilfsinformationstext 336, den die Anzeigemaschine 350 verarbeitet. Die Regeln 334 sind vom Anwendungsentwickler vordefiniert. Die Frames indizieren die Beziehung zwischen der Anwenderaktivität und der assoziierten Heuristik, die zur Interpretation der Aktivität verwendet wird, so daß es einfacher gemacht wird, nur auf die benötigte Information zuzugreifen. Die wissensbasierten Regeln sind so strukturiert, daß offensichtliche Assoziationen zwischen Regeln in der Wissensbank 330 eingebunden werden können, um die Gestaltung und die Folgerungen aus diesen Regeln zu vereinfachen.
Die Folgerungsmaschine 340 interpretiert Daten 331 und Regeln 334 in der Wissensbank 330, um dem Anwender eine Hilfslösung zu geben, oder sie fragt intelligent nach weiterer Information, um eine Lösung zu finden. In der bevorzugten Ausführungsform arbeitet die Folgerungsmaschine 340 unter Einsatz eines rückwärtsverkettenden Verfahrens. Dieses Verfahren beginnt mit einem Zielstatus (eine spezielle Art von Hilfe) und versucht, diesen durch Erreichen von ursprünglichen bekannten Daten zu bestätigen.
Wie die Fig. 10A-B illustrieren, sind die von der Folgerungsmaschine 340 befolgten Schritte die folgenden. Im Schritt 1001 wird auf die Wissensbank 330 gemäß dem Systemstatuslevel zugegriffen. Im Schritt 1002 wird eine Gruppe von Regeln (Ziel) in Abhängigkeit vom Systemstatus aus der Wissensbank 330 ausgewählt und als eine Hypothese verwendet. Als nächstes wird im Schritt 1003 ein Versuch unternommen, das Ergebnis jeder Regel durch Bestätigung ihrer Prämisse zu bestätigen. Falls im Schritt 1004 die geprüfte Prämisse das Ergebnis einer anderen Regel ist, wird sie auf einen Stack geschoben (last-in first-out Struktur des Systemspeichers 103) und es wird ein Versuch unternommen, die andere Regelprämisse im Schritt 1005 zu belegen. Im Schritt 1006 wird, falls eine Prämisse bestätigt ist, diese in einer Arbeitstatsache oder Datenliste bei Schritt 1007 angegeben. Anderenfalls, falls die Prämisse fehlgeht, wird in Schritt 1008 eine Suche nach einer Regel mit dem gleichen Ergebnis durchgeführt, welche die Folgerungsmaschine 340 dann zu bestätigen versucht. Im Schritt 1009 hat, wenn alle Prämissen in der Regel bestätigt sind, die Regel gegriffen und das Ergebnis kann in Schritt 1010 angegeben werden. In Schritt 1011 wird dieses Verfahren wiederholt, bis dort keine Zielzustände zum Analysieren mehr vorhanden sind oder keine Lösung gefunden wird. Im letzteren Fall ist die Wissensbank 330 unvollständig und von daher fragt die Folgerungsmaschine 340 beim Anwender nach weiteren Informationen an oder erläutert statt dessen dem Anwender, daß für das spezielle Szenario keine Hilfe definiert ist.
Die Eingaben in die Folgerungsmaschine 340 sind Daten 331 und Regeln 334, die in der Wissensbank 330 enthalten sind. Einige der Regeln 334 steuern andere Wissensbanken, die ausgewählt werden können. Die Folgerungsmaschine 340 prüft zuerst die Regeln 334, um die passende Regelklasse 801 auszuwählen. Da die Gruppen 802 unter der Klasse 801 indizieren, ob sie Zielzustände sind, kann die Maschine 340 auch indizieren, welche Regeln als Hypothesen eingesetzt werden. Die abschließende Ausgabe aus der Folgerungsmaschine 340 ist ein Hilfs-"Kennzeichen", welches eine spezielle Hilfslösung indiziert. Zusätzlich erstellt die Maschine eine temporäre Ausgabe von Daten, die während der Bestätigung der Regeln angegeben werden.
Die Anzeigemaschine 350 ist ein Interface zwischen der Ausgabe der Folgerungsmaschine 340 und dem Hilfstext 336, welche dem Anwender einen einfachen Zugriff auf die hilfreichsten Hilfethemen ermöglicht. Die Anzeigemaschine 350 bietet allgemeine bis in die Tiefe gehende Hilfe für einen Anwender an. Sie verarbeitet das Hilfekennzeichen der Folgerungsmaschine, um kontextsensitive Hilfe anzubieten. Zusätzlich besitzt die Hilfsinformation selbst Kennzeichen, die von der Anzeigemaschine 350 dazu verwendet werden, weitere Hilfsinformation zu lokalisieren. Dies ermöglicht einem Anwender, spezifische Hilfe aus einer Unterauswahl von Hilfsinformation auszuwählen.
Die von der Anzeigemaschine 350 genutzte Hilfsinformationsdatenstruktur ist für jede Anwendung/Zubehör und Systemressourceinterfaces definiert. Hilfe, die über mehrere Anwendungen wiederholt wird, ist in Gruppen unterteilt. Die Hilfsinformation, die angegeben wird, ist für novice-, intermediate- und advanced-Anwender individualisiert. Es wird ein Anzeigeformat eingesetzt, welches einem Anwender ermöglicht, ein einzelnes Item an Hilfe aus einer vorgeschlagenen Liste auszuwählen, es dem Anmelder ermöglicht, die Auswahl von Hilfe fortzusetzen, bis er abbrechen möchte und es dem Anwender ermöglicht, die Hilfethemen nach einem speziellen Thema zu durchsuchen.
Die Struktur, in welcher auf die Hilfsinformation zugegriffen und diese gespeichert wird, ist nach Anwendung/Zubehör oder Systemkomponente (benötigt spezifische Namensidentifikation, kein Typ), Erfahrungslevel des Anwenders, Art (automatisch ermittelt oder vom Anwender aufgerufen) und Themenidentifikationsmerkmal klassifiziert. Eine Hilfsstruktur (in der Sprache C) kann z. B. sein:
struct Help Source {
int Subject;
int Kind;
int HelpLevel;
char *pTopicString };
die aufgefüllt werden kann durch:
Subject gleich TEXT_SUBSTITUTION
Kind gleich AUTO
HelpLevel gleich NOVICE
und pTopicString zeigt auf "Text Subsitution."
Unter Bezugnahme auf Fig. 11 wird nun die Verarbeitung der Hilfsinformation in Anzeigemaschine 350 im Detail beschrieben. Die Hilfsinformationsdatenbank 335 ist eine Text 336 und Regeln 334 - Felder enthaltende Datenbank, d. h. Hilfsinformationstext 336 ist mit Hilfsinformationsregeln 334 verknüpft. Zusätzlich ist ein Kennzeichen 1102 zur Wiedergabe der Lösung, die eine Regel erzeugt, vorgesehen. Die Anzeigemaschine 350 verbindet das Kennzeichen 1102 mit einem Lösungskennzeichen 1101 der Folgerungsmaschine 340. Der korrespondierende Text (aus Text 336) ist der aktuelle Text, der als Hilfsinformation 360 zur Anzeigeeinheit 105 geschickt wird.
Die Organisation der Regeln 334 ist wie folgt. Sie enthält die folgenden Felder: Grp, Rule#, PorC#, Var#, Var, Val, Bind, KeyW, and Q#. Grp ist eine Regelgruppe. Gruppe 0 ist stets die Gruppe, in der die Regeln plaziert sind, die eine Lösung angeben. Wenn diese Regeln irgendeine andere Regel zum Greifen veranlassen, sind diese Regeln in einer anderen Gruppe. Rule# ist die Nummer der Regel. Die Regeln sind durch eine Regelnummer sortiert, da man wünschen könnte, eine Regel vor einer anderen auf Greifen auszuprobieren. PorC# ist eine Prämissen oder Ergebnisnummer. Die Records auf der Tafel sind ebenfalls nach PorC# sortiert. Das Ergebnis ist Nummer 0, weil es das erste aus der Tafel gezogene Element ist, wenn die Folgerungsmaschine 340 beginnt, Regeln greifen zu lassen. (Dies deshalb, weil sie rückwärts- verkettend vorgeht - Start mit dem Ergebnis und dann Bestätigen der Prämissen). Var# ist ein Identifikationsmerkmal für die Maschine, eine schnellere Suche durchzuführen. Jede neue zur Tafel hinzugefügte Variable besitzt ein einziges Identifikationsmerkmal. Die Variablen sind DeskMate Komponenten, wie eine Dialogbox. Var, das Variablenfeld, ist ein String, der eine Variable repräsentiert, für die ein Wert erwartet wird, wie etwa "running.cmp" (INAKTIVES FELD). Value ist das Stringfeld, welches einen Wert enthält. Falls der Wert der gegenwärtige für die Variable ist, dann trifft die Prämissenlinie zu. Bind ist eine Bindevariable. Falls eine Regel eine Bindung aufweist, wird die Variable an den gegenwärtig bekannten Wert der Variable gebunden. Dies eliminiert die Wiederholung von Regeln, die exakt das Gleiche tun. Nur Prämissen können binden. KeyW ist eine Nummer, die die Negation (NOT) einer Prämisse oder einen TEST oder CALL indiziert. TEST führt Nummernvergleiche aus und setzt voraus, daß das Wertstringfeld ein numerischer Wert ist. CALL wird zum Ausführen einer vordefinierten Funktion verwendet. Die Parameter der Funktion sind im Wertfeld plaziert. Q# ist die Nummer in der Schlange 332, für die ein Prämissentest angewendet wird. Falls die Schlangennummer 0 entspricht, wird angenommen, daß die Prämisse keine vordefinierten Daten verwendet.
Obwohl die Erfindung in einigen Details mit spezifischem Bezug zu einer einzelnen bevorzugten Ausführungsform und gewissen Alternativen beschrieben wurde, ist nicht die Absicht vorhanden, die Erfindung auf diese spezielle Ausführungsform oder diese spezifischen Alternativen zu beschränken. Zum Beispiel könnte ein Fachmann ein solches Hilfssystem in einer anderen Interfaceumgebung oder ohne jegliche Interfaceumgebung implementieren. Rückwärts-verkettend ist nur eine von vielen möglichen Al-Techniken, die zur Verarbeitung von Daten und Regeln verwendbar sind, andere mögliche Techniken schließen vorwärts-verkettende und Regel-Wert-Verfahren ein. Die Eingabeeinheit ist nicht auf eine Tastatur und eine Zeigeeinheit beschränkt, sondern erwägt jegliche Mittel, durch die Daten in einen Computer gelangen, wie etwa durch Spracherkennung. Die Hilfsinformation ist nicht auf ein spezifisches Medium beschränkt, sondern schließt statt dessen jegliche Übermittlung von Hilfsinformation, wie grafische Darstellungen, ein. Der tatsächliche Umfang der Erfindung ist nicht durch die vorangegangene Beschreibung, sondern durch die nachfolgenden Ansprüche definiert.

Claims

1. Verfahren zur Unterstützung eines Anwenders eines Computerprogramms in einem Computersystem, wobei das Verfahren unabhängig vom Computerprogramm arbeitet, umfassend die Schritte:

speichern einer Hilfsinformations-Datenbank;

überprüfen einer Reihe von anwendergesteuerten Ereignissen an einer Eingabeeinheit;

erzeugen von Daten, die die Reihe von anwendergesteuerten Daten indizieren;

speichern der erzeugten Daten in einer Wissensbank;

speichern einer Vielzahl von Regeln zum Analysieren der erzeugten Daten, um eine geeignete Hilfsinformation zu ermitteln;

feststellen einer Anforderung von Hilfsinformation durch den Anwender;

prüfen der Regeln gegen die erzeugten Daten unter Verwendung einer Folgerungsmaschine;

auswählen der geeigneten Hilfsinformation aus der Hilfsinformations-Datenbank als Antwort auf den Prüfschritt; und

anzeigen der ausgewählten Hilfsinformation an den Anwender.

2. Verfahren nach Anspruch 1, wobei der Überprüfungsschritt ferner ein Überprüfen eines Systemzustandes umfaßt.

3. Verfahren nach Anspruch 2, wobei der Schritt des Überprüfens eines Systemzustandes ferner ein Überprüfen eines Maschinenzustandes, eines Anwendungszustandes, eines Zubehörzustandes und eines Komponentenzustandes umfaßt.

4. Verfahren nach Anspruch 1, wobei der Überprüfungsschritt ferner die Schritte umfaßt:

registrieren einer Anwendungsmenüleiste;

überprüfen, ob der Anwender Hilfe angefordert hat;

aktualisieren einer Zustandsinformation; und

aktualisieren einer Menüleiste.

5. Verfahren nach Anspruch 1, wobei der Prüfschritt die Schritte umfaßt:

(a) auswählen einer ersten Gruppe von Regeln aus der Vielzahl von Regeln, die mit einer ersten Vielzahl von anwendergesteuerten Ereignissen korrespondieren;

(b) prüfen jeder Regel in der ersten Gruppe von Regeln;

(c) falls eine Regel bestätigt ist, abspeichern der Regel als eine bestätigte Regel zusammen mit einer Vielzahl von bestätigten Regeln; und

(d) wiederholen der Schritte in (a)-(c) für eine nachfolgende Gruppe von Regeln, bis eine Regel bestätigt ist.

6. Verfahren nach Anspruch 5, wobei Schritt (b) ein Vergleichen einer Prämisse aus jeder der ersten Gruppe von Regeln mit den erzeugten Daten umfaßt.

7. Verfahren nach Anspruch 5, wobei Schritt (c) umfaßt: falls eine Regel bestätigt ist, speichern dieser Regel als eine bestätigte Regel zusammen mit einer Vielzahl von verknüpften bestätigten Regeln.

8. Verfahren nach Anspruch 1, wobei der Schritt des Erzeugens der Daten ein Erzeugen einer historischen Schlange der anwendergesteuerten Ereignisse umfaßt.

9. Verfahren nach Anspruch 1, wobei der Schritt des Regelspeicherns ein Speichern von Prämisse-Ergebnis-Aussagen aus der Hilfsinformations-Datenbank umfaßt.

10. Verfahren nach Anspruch 1, wobei der Anzeigeschritt ein Anzeigen von textlichen Hilfsinformationen an den Anwender umfaßt.

11. Verfahren nach Anspruch 1, wobei der Anzeigeschritt ein Anzeigen von grafischen Hilfsinformationen an den Anwender umfaßt.

12. Verfahren nach Anspruch 1, wobei der Prüfschritt ein Prüfen der Regeln gegen die erzeugten Daten unter Verwendung einer rückwärtsverkettenden Folgerungsmaschine umfaßt.

13. Verfahren nach Anspruch 1, wobei der Prüfschritt ein Prüfen der Regeln gegen die erzeugten Daten unter Verwendung einer vorwärts-verkettenden Folgerungsmaschine umfaßt.

14. Verfahren nach Anspruch 1, umfassend die weiteren Schritte: falls die überprüfte Reihe von Ereignissen der Wissensbank unbekannt ist, angeben von Daten in der Wissensbank, um die unbekannte Reihe zu indizieren; falls die überprüfte Reihe von Ereignissen der Wissensbank widerspricht, widerrufen von Daten in der Wissensbank, die der Reihe widersprechen; und, falls die überprüfte Reihe von Ereignissen bereits der Wissensbank bekannt ist, erneutes angeben von Daten in der Wissensbank, um die bereits bekannte Reihe zu indizieren.

15. Hilfsinformationssystem zur Unterstützung eines Anwenders, umfassend:

einen Computer, der einen Prozessor und einen Speicher aufweist;

eine mit dem Computer verbundene Anzeigeeinheit;

eine mit dem Computer verbundene Eingabeeinheit;

mit der Eingabeeinheit verbundene Überprüfungsmittel zum Überprüfen einer Abfolge von anwendergesteuerten Ereignissen und zum Erzeugen von Daten, die die Ereignisse indizieren;

eine Wissensbank, die mit den Überprüfungsmitteln verbunden und im Speicher gespeichert ist, wobei die Wissensbank die erzeugten Daten, eine Vielzahl von Regeln zum Analysieren der erzeugten Daten, um geeignete Hilfsinformation zu ermitteln, und eine Hilfsinformations-Datenbank zum Speichern der geeigneten Hilfsinformation umfaßt;

Folgerungsmaschinenmittel, die mit der Wissensbank verbunden sind, um die Regeln auf die Daten anzuwenden und eine Folgerungsmaschinenausgabe zu erzeugen; und

Anzeigemaschinenmittel, die mit der Folgerungsmaschine und mit der Hilfsinformations-Datenbank verbunden sind, um die Folgerungsmaschinenausgabe zu interpretieren und um geeignete Hilfsinformation zur Anzeige durch die Anzeigeeinheit an den Anwender als Antwort auf eine Anforderung durch den Anwender auszuwählen.

16. System nach Anspruch 15, wobei die Überprüfungsmittel ferner Mittel zum Überprüfen eines Systemzustandes umfassen.

17. System nach Anspruch 16, wobei die Mittel zum Überprüfen eines Systemzustandes Mittel zum Überprüfen eines Maschinenzustandes, eines Anwendungszustandes, eines Zubehörzustandes und eines Komponentenzustandes umfassen.

18. System nach Anspruch 15, wobei die Überprüfungsmittel eine Vielzahl von Ereignisinterpretern umfassen.

19. System nach Anspruch 15, wobei die Wissensbank ferner eine historische Schlange umfaßt.

20. System nach Anspruch 15, wobei die Folgerungsmaschinenmittel rückwärtsverkettende Folgerungsmaschinenmittel umfassen.

21. System nach Anspruch 15, wobei die Folgerungsmaschinenmittel vorwärtsverkettende Folgerungsmaschinenmittel umfassen.

22. System nach Anspruch. 15, wobei die Hilfsinformation textliche Hilfsinformation umfaßt.

23. System nach Anspruch 15, wobei die Hilfsinformation grafische Hilfsinformation umfaßt.

24. System nach Anspruch 15, ferner umfassend: mit dem Speicher verbundene Mittel zum Aktualisieren der Wissensbank mit der überprüften Reihe von Ereignissen.

25. System nach Anspruch 24, wobei die Mittel zum Aktualisieren der Wissensbank Programm-Mittel zum Anweisen des Prozessors umfassen, um die Schritte durchzuführen:

falls die überprüfte Reihe von Ereignissen der Wissensbank unbekannt ist, angeben von Daten in der Wissensbank, um die unbekannte Reihe zu indizieren;

falls die überprüfte Reihe von Ereignissen der Wissensbank widerspricht, widerrufen von Daten in der Wissensbank, die der Reihe widersprechen; und

falls die überprüfte Reihe von Ereignissen bereits der Wissensbank bekannt ist, erneutes angeben von Daten in der Wissensbank; um die bereits bekannte Reihe zu indizieren.