DE10160126A1 - Sprachdialogverfahren und Sprachdialogsystem für Datenbankzugriffe - Google Patents

Abstract

Sprachdialogverfahren für Datenbankzugriffe zur Erreichung von benutzerdefinierten Dialogzielen, wobei ein Dialog-Manager den Dialogverlauf verwaltet. Der Dialog-Manager hat hierzu Zugriff auf die Anwendungsparameter, die eine Anwendung und damit einen Datenbankzugriff definieren, und welche durch den Benutzer zu konkretisieren sind. DOLLAR A Der Dialog-Manager steuert den Dialogverlauf anhand der von ihm beeinflussbaren Abarbeitungsreihenfolge der Anwendungsparameter. Er erkennt, wenn ein Anwendungsparamter vom Benutzer konkretisiert wird, der im Dialogverlauf nicht zur gegenwärtigen Bearbeitung an der Reihe ist, und passt den Dialogverlauf entsprechend an. Sind alle erforderlichen Anwendungsparameter konkretisiert, wird der entsprechende Datenbankzugriff veranlasst.

Description

• Die Erfindung betrifft ein Sprachdialogverfahren und für Datenbankzugriffe zur Erreichung von anwendungsspezifischen Dialogzielen, wobei ein Dialog-Manager den Dialogverlauf verwaltet, sowie ein Sprachdialogsystem für Zugriffe auf eine Datenbankeinrichtung mit einem Dialog-Manager zur Verwaltung des Dialogverlaufs.
• Call Center und Internet bilden heute den Schlüssel zu einem modernen Kundenbeziehungsmanagement.
• Viele Unternehmen versuchen schon seit längerem, telefonische Kundenkontakte für ihre Mitarbeiter so effizient wie möglich zu gestalten. So besteht neben der Möglichkeit zum Online-Banking bei vielen Banken auch die Möglichkeit, Abfragen und Buchungen per Telefon vorzunehmen. Bei Versicherungs-Unternehmen versucht beispielsweise ein automatisches Sprachdialogsystem möglichst viel Auskunft über den Kunden und sein Anliegen zu erhalten, so dass der Sachbearbeiter anschließend auf seinem PC bereits die wichtigsten, den Fall betreffenden Unterlagen zur Verfügung hat.
• Und das Informationsangebot im Internet ist, gerade auch für Menschen, die unterwegs oder auf Reisen sind, so attraktiv geworden, dass man heute nicht mehr auf den im wesentlichen stationären Zugriff per PC beschränkt sein möchte.
• Informationszugriffe per Sprachkommunikation auf Informationen im Internet oder auf andere Datenbanken ermöglichen die Abfrage aktueller Verkehrsmeldungen, der eigenen e-Mails, der neuesten Nachrichten oder des Kinoprogramms sowie die Buchungen von Tickets, sei es für das Kino oder die nächste Reise. Aber auch Geräte, wie z. B. ein Navigationssystem, lassen sich durch ein Sprachdialogsystem auch im Kraftfahrzeug komfortabel und sicher bedienen.
• Sprachdialogsysteme als Schnittstelle zu vielen Anwendungen sind daher aus modernen Vermarktungskonzepten künftig nicht mehr wegzudenken.
• Da einerseits beispielsweise die im Internet angebotenen Dienste zur Erhaltung der Attraktivität des Angebots an die ständig sich ändernden Informationen angepasst werden müssen, und andererseits auch ständig neue Anwendungen entstehen, ist eine schnelle Bereitstellung von anwendungsspezifischen Sprachdialogen für die Sprachdialogsysteme erforderlich.
• Eine geeignete Möglichkeit, um anwendungsspezifische Sprachdialoge schnell und sicher zu erstellen, ist die Verwendung eines Sprachdialog-Baukastens. Ein Sprachdialog- Baukasten ist eine Programmbibliothek für Anwendungsprogrammierer, die Sprachdialoganwendungen für die erwähnten Dienste erstellen. Die Programm-Module des Sprachdialog- Baukastens sind sogenannte Dialogbausteine, in denen elementare Dialogschritte zu kleinsten sinnvollen Sprachdialogeinheiten zusammengefasst sind, wobei die verschiedensten Anwendungszusammenhänge immer wieder gleich ablaufen, also anwendungsunabhängig sind.
• Die Dialogbausteine besitzen Schnittstellen, mit denen ein Anwendungsprogrammierer in die Lage versetzt wird, das für eine Anwendung spezifische Vokabular zu definieren, das der Dialogbaustein zur Laufzeit des Sprachdialogs erkennen und verarbeiten soll. Auf diese Weise werden aus den anwendungsunabhängigen Dialogbausteinen anwendungsspezifische Dialogbausteine.
• Solche Dialogbausteine umfassen beispielsweise Programm-Module für die Ziffernerkennung, für die Eingabe von Namen, für die Eingabe von Buchstaben, für einen Bestätigungsdialog, für eine Ja/Nein-Abfrage oder eine Auswahl aus einem Menü.
• Diese Dialogbausteine können vom Anwendungsprogrammierer als Zwischenkasten unbekannten Aufbaus bzw. Black Box verwendet werden; die interne Realisierung ist für ihn damit nicht von Bedeutung. Er muss lediglich die für die spezifische Anwendung notwendigen Dialogbausteine auswählen, in eine geeignete Reihenfolge bringen und die Schnittstellen der Dialogbausteine mit den anwendungsspezifischen Eingabe- und Ausgabeparametern ausstatten.
• Ein Eingabeparameter für einen Dialogbaustein, der zur Eingabe von Namen dient, soll in einer speziellen Anwendung, z. B. einem Navigationsassistenten beispielsweise den Straßennamen des Zielorts erfassen. Dazu wird er beispielsweise mit einem Verweis auf alle in Deutschland möglichen Straßennamen verbunden. Damit kennt der Dialogbaustein das anwendungsabhängige Vokabular, auf das er im Dialogverlauf bei Benutzeräußerungen reagieren muss. Ein Dialogbaustein kann auch wiederholt in einer Anwendung vorkommen, wie hier für den Navigationsassistenten der Baustein für die Namenseingabe noch für die Eingabe von Start- und Zielort, wie auch den Straßennamen des Startortes gebraucht wird.
• Ausgabeparameter sind beispielsweise Texte, die sich an den Benutzer richten: eine Begrüßung, eine gewünschte Information oder eine Aufforderung, bestimmte Angaben zu machen.
• Die Programmierung neuer Sprachdialoganwendungen aus Dialogbausteinen hat neben der schnellen, unkomplizierten und übersichtlichen Programmiermöglichkeit auch den Vorzug, dass die vorprogrammierten Dialogbausteine fehlerfrei funktionieren, und dass Fehler, die später innerhalb der Sprachdialoge auftreten, außerhalb dieser Programmteile zu suchen sind. Damit wird die Erstellung von anwendungsspezifischen Sprachdialogen nicht nur effizienter, sondern auch robuster.
• Solche Sprachdialog-Baukästen sind beispielsweise im US Patent No. 6,173,266 B1 und in der PCT Offenlegungsschrift WO 00/65814 beschrieben.
• Die Verwendung von Dialogbausteinen bedingt allerdings einen fest vorgegebenen Dialogverlauf, dessen Verzweigungslogik strikt eingehalten werden muss. Da die Strukturierung solcher Sprachdialoge hierarchisch in Baumstruktur organisiert ist - d. h. Verzweigungen sind die Alternativen, die dem Benutzer auf dem Weg durch den Dialog angeboten werden -, ist es bei einer viele Möglichkeiten umfassenden Anwendung für einen Benutzer oft sehr mühsam, sich von einer bestimmten Anwendungsmöglichkeit zur einer anderen Anwendungsmöglichkeit auf einer anderen Dialog-Ebene oder auf einen anderen Dialog-Zweig zu bewegen.
• Das ist nicht sehr benutzer- oder bedienfreundlich. In der Theorie findet man deshalb Überlegungen zu gemischtinitiativen Dialogkonzepten, die idealerweise davon ausgehen, dass der Benutzer innerhalb eines Sprachdialogs bei jedem Dialogschritt frei sein soll, den Dialogverlauf abzuändern. D. h. der Benutzer soll jederzeit die Initiative übernehmen können, den Dialogverlauf in eine andere Richtung zu lenken.
• Ein Sprachdialogverfahren mit gemischter Initiative ist in der europäischen Patentanmeldung EP 0 895 396 A2 beschrieben.
• Dabei ist das Sprachdialogverfahren für einen fest definierten Datenbankzugriff so organisiert, dass ein Dialog-Manager jede eingehende Benutzeräußerung in einem ersten Verfahrensteil nacheinander auf sieben verschiedene Fehlerarten hin überprüft, um in folgender Reihenfolge festzustellen,
  
• - ob der Benutzer den Dialog beenden möchte,
• - ob der Benutzer Hilfe möchte,
• - ob die Benutzeräußerung anwendungsfremd ist,
• - ob die Äußerung bereits bekannte Information zur Spezifikation des Datenbankzugriffs liefert,
• - ob die Benutzeräußerung hinsichtlich des Datenbankzugriff vieldeutig ist,
• - ob die Benutzeräußerung hinsichtlich des Datenbankzugriffs inkonsistent ist und schließlich,
• - ob der Benutzer einen Erkennungsfehler korrigieren möchte.
• Spricht im zyklischen Verlauf von Benutzeräußerungen und Prüfungen keine Fehlerabfrage mehr an, und sind die Informationen für die Spezifikation des definierten Datenbankzugriffs seitens des Benutzers vollständig eingegeben, wird der Datenbankzugriff veranlasst.
• Die Abfragen, die den ersten Verfahrensteil des soeben beschriebenen Sprachdialogverfahrens ausmachen, haben den Vorteil, dass sie, wie die vorgenannten Dialogbausteine, für beliebige Datenbankzugriffe auf die gleiche Weise eingesetzt werden können. Damit die für den Datenbankzugriff erforderlichen Informationen im Dialogverlauf gesammelt werden können, müssen diese Abfragen - wie die Dialogbausteine -, nur noch mit den anwendungsspezifischen Ein- und Ausgabeparametern ausgestattet werden.
• Im zweiten Verfahrensteil des beschriebenen Sprachdialogverfahrens, d. h. nach einem Datenbankzugriff, wird dem Benutzer die Ausführung geeigneter, zur Anwendung passender Operationen angeboten. Ist der Datenbankzugriff beispielsweise eine Kontostandsabfrage, so wird der Benutzer anschließend beispielsweise die Möglichkeit zu einer Transaktion erhalten. Diese, nach einem erfolgten Datenbankzugriff mit dem Sprachdialog zu realisierenden Anwendungen, können dabei, wenn es sich um einen einfachen Datenbankzugriff handelt, analog dem ersten Teil des Verfahrens wieder anwendungsunabhängig programmiert sein.
• Dieses Sprachdialogverfahren hat insgesamt den Vorteil, dass der Benutzer in den Teilen des Dialogs, die so strukturiert sind, wie im ersten Teil dieses Verfahrens beschrieben, jederzeit die Initiative ergreifen kann. Dabei wird jede seiner Äußerungen auf sieben verschiedene Bedeutungsmöglichkeiten hin untersucht, worauf entsprechende Reaktionen des Sprachdialogs erfolgen.
• Es ist dem Benutzer allerdings nicht möglich, auf die beschriebene Weise unmittelbar ein gegenüber dem bisherigen Dialogziel geändertes Dialogziel zu definieren, ohne zuvor den Korrekturmodus des Sprachdialogs aufzurufen. Wenn der Benutzer eines Vorlesesystems sich beispielsweise entschließt, statt der Sportnachrichten nun die Veranstaltungshinweise hören zu wollen, so genügt nicht die Angabe "Veranstaltungshinweise", sondern das Sprachdialogsystem muss erst durch Korrekturschritte an die Stelle im Sprachdialog geführt werden, wo es diese Information sinnvoll verarbeiten kann.
• Damit Sprachdialoganwendungen auf Dauer von einem breiten Benutzerkreis akzeptiert werden, sind neben einer sicheren Spracherkennung aber auch Sprachdialoge erforderlich, die den Benutzer nicht unnötige Zeit damit verbringen lassen, auf die "richtige Frage" des Sprachdialogs zu warten oder die richtige Frage durch etwaige Manipulationen zu erzwingen.
• Die Aufgabe der Erfindung besteht daher darin, ein Sprachdialogverfahren für Datenbankzugriffe sowie ein zugehöriges Sprachdialogsystem so zu organisieren, dass es sich bedienfreundlich mit geringstem Benutzeraufwand an eine vom Benutzer gewünschte Änderung des Dialogziels anpasst.
• Diese Aufgabe wird gelöst durch ein Sprachdialogverfahren mit den in Patentanspruch 1 angegebenen Merkmalen und durch ein Sprachdialogsystem mit den in Patentanspruch 10 angegebenen Merkmalen. Vorteilhafte Ausgestaltungen und/oder Weiterbildungen der Erfindung sind den Unteransprüchen zu entnehmen.
• Im Folgenden wird die Erfindung anhand eines bevorzugten Ausführungsbeispiels unter Bezugnahme auf die Zeichnung beschrieben.
• Es zeigen:
• Fig. 1 ein Ablaufdiagramm des erfindungsgemäßen Sprachdialogverfahrens und
• Fig. 2 ein Blockschaltbild des erfindungsgemäßen Sprachdialogsystems.
• Einleitend werden zunächst die Bestandteile bzw. Verfahrensschritte des erfindungsgemäßen Verfahrens sowie die verwendeten Begriffe genauer erläutert.
• Soll in einem Sprachdialog Benutzerinitiative zugelassen werden, so ist ein Modul erforderlich, welches für die Verwaltung des Dialogverlaufes verantwortlich ist, da Benutzerinitiative eine Änderung eines ansonsten vom Sprachdialogsystem gesteuerten vordefinierten Dialogverlaufs bedingt. Diese Verwaltung wird durch einen sogenannten Dialog-Manager 4 realisiert.
• Der Dialog-Manager kennt den vordefinierten Dialogverlauf, d. h. den Dialogverlauf, der vorgegeben ist, falls keine Benutzerinitiative stattfindet. Der Dialogverlauf wird durch Anwendungsparameter bestimmt, die innerhalb einer Dialoganwendung, bearbeitet werden müssen, damit ein Dialogziel erreicht werden kann. Eine Dialoganwendung, kurz Anwendung, zielt immer auf einen bestimmten Datenbankzugriff, im weiteren auch Dialogziel genannt.
• Das Dialogziel für jede Anwendung ist somit dann erreicht, wenn alle für die Erreichung des Ziels notwendigen Anwendungsparameter, kurz Parameter, durch den Sprachdialog abgearbeitet wurden, d. h. vom Benutzer mit konkreten Informationen gefüllt wurden. Im Folgenden wird dies als Konkretisierung eines Anwendungsparameters bezeichnet.
• Die zu einer Anwendung gehörenden Parameter werden innerhalb des Dialog-Managers durch einen Kellerspeicher 7, kurz Keller, verwaltet, wobei die Parameter im Verlauf einer Anwendung durch den Sprachdialog, bildlich gesprochen "von oben nach unten" abgearbeitet werden. Dabei ist der zuoberst befindliche Parameter immer der, der gerade vom Sprachdialog bearbeitet wird. Wenn dieser Parameter vom Benutzer konkretisiert wurde, wird er aus dem Keller "geschoben", und der ihm folgende Parameter rückt an die oberste Stelle im Keller zur Bearbeitung nach. Der Sprachdialog ist erfolgreich abgeschlossen, wenn alle Parameter aus dem Keller geschoben wurden bzw. der Kellerspeicher leer ist.
• Benutzerinitiative bedeutet, dass ein Benutzer in den Dialogverlauf eingreift, in dem er etwas äußert, das keine Konkretisierung des gegenwärtig bearbeiteten Anwendungsparameter betrifft, also nicht gerade betrachteten Anwendungsparameter "passt". Dies impliziert, dass der Kellerspeicher nicht mehr in der vorgegebenen Reihenfolge abgearbeitet werden kann, sondern ein Anwendungsparameter als nächstes betrachtet werden muss, für den die erfolgte Benutzeräußerung eine Konkretisierung darstellt, zu dem die Äußerung also "passt".
• Dabei gibt es verschiedene Möglichkeiten, wie durch die Initiative des Benutzers der Dialogverlauf verändert werden kann. Formal kann dies durch Relationen beschrieben werden, die zwischen dem aktuell betrachteten Anwendungsparameter und dem bereits geführten Dialog bestehen. Derartige Relationen sind in der Literatur als Diskurs-Relationen bekannt.
• Damit der Dialog-Manager über den weiteren Dialogverlauf entscheiden kann, werden die in der Literatur beschriebenen Diskurs-Relationen erfindungsgemäß dahingehend erweitert, dass die Relationen nicht nur den aktuell betrachteten Parameter berücksichtigen, sondern auch abhängige Parameter mit einbeziehen. Abhängigkeiten sind beispielsweise dadurch gegeben, dass zur Bearbeitung einer Adresse, nach der Ortsangabe, üblicherweise eine Straßenangabe und die Angabe einer Hausnummer folgen müssen. Die Einbeziehung abhängiger Parameter in die Dialogbetrachtung wird realisiert, indem der Dialog-Manager auf Informationen über die anwendungsspezifischen Abhängigkeiten der Parameter Zugriff erhält.
• Eine derartige Verarbeitung abhängiger Parameter durch den Dialog-Manager wird im Folgenden beschrieben.
• Eine Benutzerinitiative ist erfindungsgemäß dadurch erkennbar, dass im Dialogverlauf ein Parameter betrachtet wird, der nicht der oberste auf dem Kellerspeicher ist. Also ändert der Dialog- Manager den Dialogverlauf dahingehend, dass dieser Parameter als nächster vom Sprachdialog betrachtet wird. Ist dieser Parameter noch im Keller, so wird er ganz nach oben verlagert. Ist der Parameter bereits bearbeitet worden, also nicht mehr im Keller zu finden, wird er erneut dort eingestellt; ebenfalls an oberster Stelle.
• Dabei ist zu beachten, dass es Parameter geben kann, die von diesem betrachteten Parameter abhängig sind. Ein sinnvoller Dialogverlauf ist aber nur dann gegeben, wenn die abhängigen Parameter im Anschluss an den aktuell betrachteten Parameter verarbeitet werden. Dies bedeutet, dass diese Parameter - sei es durch Umsortieren des Kellerinhalts, oder durch erneutes Einschreiben in den Keller -, in direkter Folge hinter den neu betrachteten Parameter an den Anfang des Kellers gebracht werden müssen.
• Wie vorstehend bereits erwähnt, kann eine Benutzerinitiative auch dazu führen, dass ein Parameter angesprochen wird, der bereits verarbeitet wurde. Dies impliziert eine Korrektur des bereits verarbeiteten Parameters. Sind andere Parameter von diesem Parameter abhängig, so müssen auch die abhängigen Parameter korrigiert werden.
• Will der Benutzer beispielsweise den Zielort für sein Navigationssystem ändern, und gibt dafür den Namen der Stadt ein, so müssen normalerweise nachfolgend auch die Straße und Hausnummer seines Ziels neu bestimmt werden. Dies bedeutet, dass diese Parameter durch eine erneute Benutzereingabe wieder gefüllt werden müssen. Um dies zu erreichen, werden die Parameter, wie zuvor beschrieben, erneut "eingekellert", nachdem sie bereits "ausgekellert" waren, damit sie vom Benutzer im weiteren Dialogverlauf neu konkretisiert werden können.
• Die Funktionsweise des erfindungsgemäßen Dialog-Managers basiert also auf einem Kellerspeicher und einem strukturierten Lexikon 5, in dem die Abhängigkeiten der Parameter untereinander spezifiziert sind.
• Ein erfindungsgemäßer Dialog-Manager für eine Anwendung lässt sich somit dadurch realisieren, dass ein vordefinierter Dialogverlauf durch die Reihenfolge der Parameter im Kellerspeicher vorgegeben wird. Die Abhängigkeiten der Parameter für eine bestimmte Anwendung sind im Lexikon definiert. Bei einer Implementierung des erfindungsgemäßen Sprachdialogs mit Dialogbausteinen aus einer Programmbibliothek 6, ergibt sich durch die Reihenfolge der Parameter im Keller automatisch die Abarbeitungsreihenfolge der die entsprechenden Parameter verarbeitenden Dialogbausteine.
• Wird ein Parameter vom erfindungsgemäßen Sprachdialog verarbeitet, so wird er, wenn es sich um den Parameter am Anfang des Kellers handelt, nach seiner Konkretisierung "ausgekellert". Bei Benutzerinitiative ist entweder ein Parameter weiter unten im Keller oder außerhalb des Kellers betroffen. In diesem Fall wird der betroffene Parameter an den Anfang des Kellers gebracht und gegebenenfalls von ihm abhängige Parameter auf die Plätze darunter einsortiert.
• Die schon im Stand der Technik geschilderten wiederverwendbaren Dialogbausteine werden mittels ihrer Schnittstellen mit anwendungsspezifischem Wissen, den Anwendungsparametern, ausgestattet. Dies muss nicht unbedingt in einem eigenständigen Schritt von einem Anwendungsprogrammierer durchgeführt werden. Es ist auch möglich, den Sprachdialog-Baukasten der Sprachdialoganwendung als Programm-Bibliothek 6 zur Verfügung zu stellen und die Bausteine zur Laufzeit der Anwendung jeweils unter Angabe der aktuellen anwendungsspezifischen Parameter aufzurufen.
• Das anwendungsspezifische Wissen besteht dabei jeweils aus den Anwendungsparametern, die innerhalb des Dialogbausteines verarbeitet werden. Explizit "kennt" der wiederverwendbare Dialogbaustein damit den Teil der Anwendung - die Untermenge von Anwendungsparametern -, für die er verantwortlich ist. Implizit kennt der wiederverwendbare Dialogbaustein damit auch alle Anwendungsparameter, für die er nicht verantwortlich ist.
• Betrifft eine Benutzereingabe einen Parameter, der nicht als Eingabeparameter für den wiederverwendbaren Dialogbaustein definiert ist, so übergibt der wiederverwendbare Dialogbaustein die Dialogkontrolle an den Dialog-Manager. Dieser entscheidet dann, ob dieser Parameter überhaupt ein gültiger Anwendungsparameter ist. Handelt es sich um einen der Anwendung bekannten Parameter, so bestimmt der Dialog-Manager, wie der Dialogverlauf im weiteren, beginnend mit der Verarbeitung dieses Parameters, angepasst werden muss. Handelt es sich bei einer Benutzeräußerung um keinen Anwendungsparameter, so ruft der Dialog-Manager eine Hilferoutine auf.
• Die Gesamtarchitektur eines Sprachdialogs mit zulässiger Benutzerinitiative, der durch Dialogbausteine implementiert ist, lässt sich somit in zwei Schichten aufteilen. Die anwendungsspezifische Schicht - das ist der Dialog-Manager - und die applikationsunabhängige Schicht - repräsentiert durch die Dialogbausteine, die Wissen über die Anwendung nur soweit besitzen, wie es durch die Eingabeparameter spezifiziert ist.
• Die Kontrolle über den Dialogverlauf liegt dabei ausschließlich bei der anwendungsspezifischen Schicht, d. h. dem Dialog- Manager. Der Dialog-Manager entscheidet, sobald eine Benutzerinitiative erkennbar ist, welches der nächste zu bearbeitende Parameter ist, und welcher Dialogschritt folglich der nächste ist. Damit ist zugleich festgelegt welcher Dialogbaustein als nächster für den Dialogverlauf aktiviert werden muss und der Dialogverlauf insgesamt neu definiert.
• Nachfolgend wird der erfindungsgemäße Dialog-Manager in Verbindung mit wiederverwendbaren Dialogbausteinen zu am Beispiel eines Nachrichtenvorlesers und eines Navigationsassistenten beschrieben. Dies ist jedoch nicht einschränkend zu sehen, da für den Fachmann zahlreiche weitere Anwendungsmöglichkeiten ersichtlich sind, bei einen bisher herkömmliche Sprachdialogsysteme verwendet werden.
• Zum einem wird im Folgenden gezeigt, dass der Dialog-Manager die selben Bausteine in verschiedenen Anwendungen verwalten kann, zum anderen, dass der Dialog-Manager für beliebige Bausteine erweiterbar ist. Damit wird verdeutlicht, dass das Konzept "Dialog-Manager" flexibel portierbar ist.
• Zunächst wird als erstes Ausführungsbeispiel ein erfindungsgemäßer Nachrichtenvorleser genauer beschrieben. Der erfindungsgemäße Nachrichtenvorleser basiert auf zwei wiederverwendbaren Dialogbausteinen: einer "Menüauswahl" und einer "freinavigierbaren Auswahlliste".
• Die Menüauswahl erlaubt dem Benutzer, aus einer Liste von Menüpunkten einen Menüpunkt auszuwählen. Im Nachrichtenvorleser wird dieser Baustein eingesetzt, um aus einer Liste angebotener Themen ein Thema auszuwählen. Der wiederverwendbare Dialogbaustein zur Menüauswahl benötigt als Eingabeparameter die Liste der Menüpunkte, z. B. die Liste der Nachrichtenthemen: Sport, Politik, Wirtschaft, . . . und eine Aufforderung, die nach diesen Menüpunkten fragen soll, z. B.: "Wählen Sie eine der folgenden Rubriken: Sport, Politik, Kultur, Wirtschaft." Als Rückgabewert liefert der Dialogbaustein den vom Benutzer ausgewählten Menüpunkt. Damit ist ein Anwendungsparameter "Nachrichtenthema" konkretisiert worden.
• Die freinavigierbare Auswahlliste stellt dem Benutzer, ähnlich der Menüauswahl, eine Liste von Einträgen zur Verfügung, durch die er mit Sprachkommandos wie "weiter", "zurück" oder "stopp" navigieren und einen der Einträge auswählen kann. Sagt der Benutzer nichts, so werden die Inhalte der Einträge der Reihe nach vorgelesen.
• Beim Nachrichtenvorleser wird dieser Baustein benutzt, um dem Benutzer eine Liste von Schlagzeilen und Nachrichten anzubieten. Der Benutzer kann dann durch diese Liste navigieren und bei den Schlagzeilen, die ihn interessieren, die Nachrichten vorlesen lassen. Sagt der Benutzer nichts, so werden erst alle Schlagzeilen und dann die Nachrichten der Reihe nach vorgelesen.
• Um Benutzerinitiative innerhalb des erfindungsgemäßen Nachrichtenvorlesers realisieren zu können, muss der Dialog dem Benutzer die Freiheit lassen, jederzeit in den Dialogverlauf eingreifen, und ihn nach seinen Wünschen ändern zu können. Dies beinhaltet, dass insbesondere der Dialogverlauf durch die Initiative des Benutzers innerhalb der Abarbeitung eines Dialogbausteines änderbar sein muss.
• Für den Nachrichtenvorleser bedeutet dies, dass der Benutzer jederzeit zwischen den Bereichen Rubrik, Schlagzeilen- und Nachrichtenauswahl wechseln kann.
• Die Aufgabe des erfindungsgemäßen Dialog-Managers besteht dann darin, zu erkennen, an welcher Stelle, d. h. an welcher Verzweigung der Dialog durch die Initiative des Benutzers fortgesetzt werden muss. Möchte der Benutzer innerhalb des Schlagzeilen- und Nachrichtenvorlesens einen Wechsel der Nachrichtenrubrik initiieren, so führt der Wechsel der Rubrik zum Verlassen des wiederverwendbaren Dialogbausteins "freinavigierbare Auswahlliste" und zur Änderung des Dialogverlaufs.
• Der nächste Dialogschritt wird durch den Dialog-Manager aufgrund der bereits konkretisierten Anwendungsparameter, die in einer Speichereinrichtung 8 abgespeichert sind, entschieden.
• Die Parameter, die innerhalb des Nachrichtenvorlesers existieren, sind die Rubriken und die jeweils zugehörigen Schlagzeilen und Nachrichten. Der vordefinierte Dialogverlauf behandelt die Parameter in dieser Reihenfolge. Erst wird die Nachrichtenrubrik bestimmt, dann die dazugehörigen Schlagzeilen vorgelesen und zum Schluss folgen die Nachrichten.
• Wird der Benutzer initiativ und gibt während des Nachrichtenvorlesens eine neue Rubrik an, so ist der aktuelle Parameterzustand der, dass der Parameter Rubrik gesetzt ist, aber die Parameter für die Schlagzeilen und die Nachrichten noch leer ist.
• Aufgrund dieser Parameterkonstellation kann der erfindungsgemäße Dialog-Manager entscheiden, an welche Stelle der Dialog fortgesetzt werden soll. Da der Parameter "Rubrik" gefüllt ist, braucht dieser Parameter nicht mehr behandelt zu werden. Der nächste zu konkretisierende Parameter betrifft die Schlagzeilen, also setzt der Dialog-Manager den Dialog an dieser Stelle fort und folgt ab dieser Stelle wieder dem bisher definierten Dialogverlauf.
• In einem zweiten Ausführungsbeispiel der Erfindung, einem erfindungsgemäßen Navigationsassistenten, werden ebenfalls die beim Nachrichtenvorleser verwendeten Dialogbausteine neben zwei weiteren Dialogbausteinen eingesetzt. Dieser erfindungsgemäße Navigationsassistent wird nachstehend weiter erläutert.
• In der Menüauswahl wird dem Benutzer eine Auswahl möglicher Routen angeboten, z. B. "die kürzeste Route" oder "die schnellste Route".
• Eine freinavigierbare Auswahlliste wird benötigt, falls ein eingegebener Ort nicht eindeutig zugeordnet werden kann. Dann werden dem Benutzer in Frage kommende Orte vorgeschlagen. So kann der Benutzer aus der Liste der angebotenen Ortsnamen den richtigen auswählen.
• Für die Eingabe von Start- und Zielort müssen Adressen angegeben werden. Dazu müssen Bestandteile einer Adresse wie Straßennamen, Ortsnamen, Postleitzahlen und Hausnummern verarbeitet werden. Adresseingaben sind somit aus Dialogbausteinen für die Eingabe von Namen und für die Eingebe von Ziffern zusammengesetzt. Dabei werden die Bausteine im Navigationsassistenten mehrfach verwendet. Die Namenseingabe verarbeitet Orts- und Straßennamen von Start- und Zielort, die Zifferneingabe verarbeitet die Postleitzahlen und Hausnummern.
• Merkt der Benutzer z. B. bei der Adresseingabe, dass er einen falschen Ortsnamen angegeben hat, so kann er auch innerhalb der Straßennameneingabe den Ortsnamen korrigieren, denn der Dialogbaustein für die Namenseingabe bemerkt, dass diese Benutzereingabe keinen zulässigen Straßennamen darstellt, und übergibt die Benutzeräußerung an den Dialog-Manager. Dieser prüft anhand des Lexikons, ob die Eingabe für die Anwendung relevant ist. Wenn der Dialog-Manager feststellt, dass dies der Fall ist, weil er erkennt, dass es sich um einen Ortsnamen handelt, setzt er beispielsweise den zuletzt bearbeiteten Anwendungsparameter für Ortsnamen - was bei dieser Anwendung der "Ziel-Ortsname" oder der "Start-Ortsname" sein kann -, an die oberste Stelle im Kellerspeicher, wobei im weiteren davon ausgegangen werden soll, dass es sich um den Parameter "Ziel- Ortsname" handelt. Die vom Parameter "Ziel-Ortsnamen" abhängigen Parameter "Ziel-Straßenname" und "Ziel-Hausnummer" werden daraufhin im Kellerspeicher hinter dem Parameter "Ziel- Ortsname" einsortiert.
• Da der Kellerspeicher den Dialogverlauf repräsentiert, wird für den nächsten Dialogschritt der Dialogbaustein für die Eingabe von Namen aktiviert, wobei der Baustein über seine Schnittstelle für die Eingabeparameter mit dem Anwendungsparameter "Ziel-Ortsname" für die Anwendung spezifiziert wird und der vom Benutzer eingegebene Ortsname anwendungsgemäß weiterverarbeitet wird und der Parameter aus dem Kellerspeicher des Dialog-Managers, mit dem er die noch abzuarbeitenden Anwendungsparameter verwaltet, gelöscht wird.
• Im nächsten Dialogschritt wird wiederum der Dialogbaustein für die Eingabe von Namen aktiviert, diesmal zusammen mit dem Anwendungsparameter "Ziel-Straßenname". Erfolgt die Eingabe eines Straßennamens, so wird auch dieser anwendungsgemäß weiterverarbeitet und der entsprechende Anwendungsparameter aus dem Keller gelöscht. Als nächstes würde dann ein Dialogbaustein für die Eingabe von Zahlen aktiviert, weil sich jetzt der Parameter "Hausnummer" im Keller zuoberst befindet. Im weiteren werden alle Parameter in ihrer vordefinierten Reihenfolge abgearbeitet, bis entweder der Benutzer wieder initiativ wird oder der Kellerspeicher geleert ist, womit sichergestellt ist, dass alle für den beabsichtigten Datenbankzugriff notwendigen Parameter konkretisiert sind und der Datenbankzugriff auf eine Datenbankeinrichtung 9 erfolgen kann.

Claims (7)

1. Sprachdialogverfahren für Datenbankzugriffe zur Erreichung von benutzerdefinierten Dialogzielen, wobei ein Dialog- Manager den Dialogverlauf verwaltet dadurch gekennzeichnet,
dass der Dialog-Manager
Anwendungsparameter verwaltet, die eine Anwendung, und damit einen Datenbankzugriff definieren, und die durch einen Benutzer zu konkretisieren sind, damit ein entsprechender Datenbankzugriff veranlasst werden kann,
den Dialogverlauf entsprechend einer von ihm beeinflussbaren gegenwärtigen Abarbeitungsreihenfolge dieser Anwendungsparameter steuert,
erkennt, wenn ein Anwendungsparameter vom Benutzer konkretisiert wird, der im Dialogverlauf nicht zur gegenwärtigen Bearbeitung an der Reihe ist, und
den Dialogverlauf entsprechend anpasst.

2. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass der Dialogverlauf durch Zugriff des Dialog-Managers auf wiederverwendbare, vorstrukturierte Dialogbausteine realisiert wird, wobei jedem Dialogbaustein im Hinblick auf das ausgewählte Dialogziel nur eine bestimmte Teilmenge von Anwendungsparametern bekannt ist, und ein in Abarbeitung befindlicher Dialogbaustein erkennen kann, wenn eine Benutzeräußerung keinen ihm bekannten Anwendungsparameter betrifft, und die ihm unbekannte Benutzeräußerung dem Dialog-Manager übermittelt.

3. Verfahren nach Anspruch 2 dadurch gekennzeichnet, dass der Dialog-Manager Zugriff auf Informationen über alle für den Sprachdialog zulässigen Anwendungsparameter hat, wobei er anhand dieser Informationen bei Übermittlung einer einem Dialogbaustein unbekannten Benutzeräußerung feststellt, ob diese Äußerung einen für den Sprachdialog zulässigen Anwendungsparameter betrifft, und, falls sie keinen zulässigen Parameter betrifft eine Fehlerbehandlung einleitet.

4. Verfahren nach Anspruch 3 dadurch gekennzeichnet, dass der Dialog-Manager im Falle einer Benutzeräußerung, die einen zulässigen Anwendungsparameter betrifft, diesen zum gegenwärtig zu bearbeitenden Anwendungsparameter macht und den Dialogverlauf mit einem für die Verarbeitung dieses Anwendungsparameters fortsetzt und eine eventuell zuvor im Dialogverlauf erfolgte Konkretisierung desselben Anwendungsparameters überschreibt.

5. Verfahren nach Anspruch 4 dadurch gekennzeichnet, dass der Dialog-Manager Zugriff auf Informationen über alle wechselseitigen Abhängigkeiten der Anwendungsparameter hat, wobei er anhand dieser Informationen Anwendungsparameter, die vom gegenwärtig zu bearbeitenden Anwendungsparameter abhängig sind, entsprechend den vorhandenen Abhängigkeiten in der Abarbeitungsreihenfolge direkt hinter den gegenwärtig zu bearbeitenden Anwendungsparameter einreiht.

6. Sprachdialogsystem für Zugriffe auf eine Datenbankeinrichtung mit einem Dialog-Manager zur Verwaltung des Dialogverlaufs, gekennzeichnet durch,
eine Speichereinrichtung (5) für Informationen über alle für den Sprachdialog zulässigen Anwendungsparameter und ihre wechselseitigen Abhängigkeiten,
eine Speichereinrichtung (7) für Informationen über die gegenwärtige Abarbeitungsreihenfolge der Anwendungsparameter,
eine Speichereinrichtung (8) für Informationen über alle konkretisierten Anwendungsparameter,
eine Programmbibliothek (6) mit wiederverwendbaren, vorstrukturierten Dialogbausteinen und
dadurch, dass der Dialog-Manager (4)
auf die Datenbankeinrichtung (9) und die vorgenannten Speichereinrichtungen (5, 7, 8) zugreifen kann und
mit Hilfe der Inhalte der Speichereinrichtungen erkennen kann, wenn ein Anwendungsparameter vom Benutzer konkretisiert wird, der im Dialogverlauf gegenwärtig nicht zur Bearbeitung ansteht und
die Speichereinrichtungen hinsichtlich der Konkretisierung der Anwendungsparameter und der Abarbeitungsreihenfolge der Anwendungsparameter aktualisieren kann und
entsprechend dieser Reihenfolge im Dialogverlauf aus der Programmbibliothek einen zur Bearbeitung des jeweiligen Anwendungsparameters geeigneten Dialogbaustein aufruft.

7. Dialogsystem nach Anspruch 6, dadurch gekennzeichnet, dass es weiterhin eine Spracheingabevorrichtung (1) und einen Spracherkenner (1) zur Erfassung konkretisierter Anwendungsparameter aufweist, sowie eine Sprachsyntheseeinrichtung (2) und eine Sprachausgabevorrichtung (2) für Meldungen des Sprachdialogsystems.