DE69814114T2

DE69814114T2 - Natürliche sprache verstehendes verfahren und verstehende vorrichung zur sprachsteuerung einer anwendung

Info

Publication number: DE69814114T2
Application number: DE69814114T
Authority: DE
Inventors: Wilmer Karl SCHOLZ; Victor Reginald BLUE; Alan Raymond DIEDRICHS; Patrick Joseph WALSH
Original assignee: Unisys Corp
Current assignee: Unisys Corp
Priority date: 1997-09-17
Filing date: 1998-09-17
Publication date: 2004-03-18
Anticipated expiration: 2018-09-18
Also published as: CA2304057C; EP1016076A1; EP1016076B1; JP4112171B2; JP2001516905A; US6094635A; ATE239289T1; DE69814114D1; CA2304057A1; WO1999014743A1

Description

Erfindungsgebiet
Diese Erfindung betrifft allgemein computerisierte natürliche Sprachsysteme. Insbesondere betrifft sie ein Computersystem und ein Verfahren zum Bereitstellen von Sprachverständnisfähigkeiten für ein Dialog-Sprachantwortsystem. Es betrifft weiterhin ein Computersystem und ein Verfahren zum Interpretieren von Äußerungen in einer mit Randbedingungen versehenen Spracherkennungsanwendung.
Beschreibung des Standes der Technik
Computer sind in unserem täglichen Leben eine Hauptstütze geworden. Viele von uns verbringen Stunden am Tag für die Verwendung der Vorrichtungen bei der Arbeit, zuhause und sogar beim Einkaufen. Die Verwendung des Computers erfolgte jedoch immer unter den Bedingungen der Machine. Eine Mouse, Druckknöpfe und Tastaturen waren irgendwie immer ein unnatürlicher Weg, dem Computer zu vermitteln, was wir wollen. Da jedoch die Computertechnologie fortfährt sich zu entwickeln, neigt der Computer zur Kommunikation mit dem Menschen auf der Grundlage von unseren Bedingungen: dem gesprochenen Wort.
Es gibt im Wesentlichen zwei Schritte zum Erzeugen eines Computers, der mit Menschen sprechen kann. Als erstes braucht der Computer eine automatische Spracherkennung, um die gesprochenen Worte zu erfassen und sie in irgendeine Form von für den Computer lesbare Daten wie beispielsweise einen einfachen Text zu konvertieren. Als zweites benötigt der Computer irgendeinen Weg zum Analysieren der vom Computer lesbaren Daten und zum Bestimmen der Bedeutung dieser Worte, wie sie verwendet wurden. Dieser zweite Schritt benutzt für gewöhnlich irgendeine Form künstlicher Intelligenz, und es gibt mehrere grundlegende Vorgehensweisen, die die Erfinder eingeschlagen haben, um ein System zu entwickeln, das die Bedeutung aus Worten extrahieren kann.
Eine solche Vorgehensweise beinhaltet eine statistische Computerlinguistik. Diese Vorgehensweise verlässt sich auf die relativ vorhersagbare Natur der menschlichen Sprache. Statistische Computerlinguistiken beginnen mit einem Corpus, der eine Liste von Test-Äußerungen darstellt, die in der Grammatik enthalten sind. Dieser Corpus wird analysiert und die statistischen Eigenschaften der Grammatik werden extrahiert. Diese statistischen Eigenschaften werden in Regeln implementiert, die dann in einem Versuch, die Bedeutung dessen, was gesagt wurde, statistisch zu "erraten", auf die neu gesprochene Äußerung angewandt wird.
Aufgrund der großen Zahl an möglichen Äußerungen in irgendeiner Sprache (Englisch, Deutsch, Chinesisch, usw.) versucht kein Sprachsystem, dem ein Corpus zugrunde liegt, die vollständige Gruppe an gültigen Äußerungen in dieser Sprache aufzulisten. Einige Systeme haben jedoch versucht, die Zahl der möglichen Ausdrücke zu reduzieren, indem die Gültigen auf diejenigen in einer vorbestimmten Grammatik begrenzt oder eingeschränkt werden. Zum Beispiel unterrichtet das US-Patent 5 652 897, Linebarger et al. erteilt und an die Unisys Corporation, Blue Bell, Pa. übertragen, von einem Sprachprozessor, der nur Flugsicherungsbefehle versteht. Dort wurde ein Satz des Fluglotsens in einzelne Befehle aufgeteilt, die dann einzeln verarbeitet wurden, um ihre Bedeutung zu bestimmen. Leider kann diese Art der Verarbeitung schnell Computerleistung verbrauchen, wenn die gültige Grammatik vom relativ begrenzten Vokabular der Flugsicherung auf beispielsweise ein automatisches Bankenterminal erweitert wird, das alle Arten von Transaktionen abwickeln kann.
Andere natürliche Sprachsysteme können einen vollen Bereich an Äußerungen erlauben, jedoch erfordert dieser hohe Allgemeingültigkeitsgrad eine große Computerleistung. Was benötigt wird, ist ein Sprachverständnissystem, das die Sprache in einer eingeschränkten Grammatik interpretieren kann, die nicht die vollständige Allgemeingültigkeit eines natürlichen Sprachsystems benötigt.
US-A-5 390 279 betrifft die Partitionierung von Sprachregeln durch den Kontext für die Spracherkennung. Zu diesem Zweck erfasst US-A-5 390 279 gesprochene Worte. Wie in den 1 und 2 von US-A-5 390 279 gezeigt, werden 279 digitalisierte Klangsignale auf der Leitung 201 in einem Verfahren, das Merkmalsextraktion heißt, von einem ersten Computer 108 verarbeitet, um das Hintergrundrauschen von der Sprache zu trennen. Die Merkmale auf der Leitung 211 sind noch keine Worte oder Buchstaben. Ein zweites Verfahren 220 versucht, die Worte in den Klangmerkmalen zu erkennen, indem es "Sprachmodelle" sucht, die über die Leitung 222 zugeführt werden. Die Sprachmodelle sind in Wirklichkeit das zu suchende Vokabular. Abhängig von den Merkmalen auf der Leitung 211 ruft der Sprachmodell-Generator/ Interpreter unter der Steuerung des zweiten Prozessors 102 das Vokabular und die Regeln aus den Anwendungsprogrammen 1 bis N auf, und sein Betriebssystem wird als Block 244 gezeigt.
Gemäß US-A-5 390 279 gibt es zwei Verfahren zum Erzeugen eines Sprachmodells. Das erste Verfahren verwendet einfach alle Sprachregeln, um ein statisches Einmal-Sprachmodell aufzubauen. Das Problem in Zusammenhang mit diesem Versuch liegt darin, dass das Sprachmodell so groß ist, dass der Erkenner 220 durch die Computerprobleme verlangsamt wird und "fehleranfälliger" ist.
Weiterhin schlägt US-A-5 390 279 vor, dass das Sprachmodell während der Verarbeitung oder dynamisch aufgebaut wird. Im Anschluss an die Analyse sendet der Erkenner 220 die erkannten Worte 221 für Aktionen an ein Interpreterverfahren 230. Solchermaßen erzeugen die Prozessoren 210, 220 und 230, wenn kombiniert, Worte, die den kommerziell erhältlichen ASR-Systemen ähneln.
JP-A-08-194600 beschreibt eine Sprachterminalausstattung, die einen Block 204 einschließt, der Spracherkenner genannt wird. Der Block 201 empfängt die Sprachausgabe und konvertiert sie in einen im Puffer 208 gespeicherten zurückholbaren Befehl. War der Befehl eine Anfrage, konvertiert der Block 203 die Anfrage mittels der Verwendung einer Antworttabelle 207 und eines Synthetisiererblocks in eine Antwortausgabe.
WO-A-97/10589 lehrt von einem automatischen Rufumleitungs system und -verfahren, das einen Block 15, "Spracherkenner" genannt, und einen Block 20, "Interpretationsmodul" genannt, einschließt. Dieses System und und dieses Verfahren verwenden ein e) uneingeschränktes) Vokabular und Grammatik, die sofort erlernt werden. Das System sucht eine bedeutungsvolle Antwort aus, wenn es eine bedeutungsvollen Satz in seinem uneingeschränkten Vokabular identifizieren kann.
Zusammenfassung der Erfindung
Ein allgemeiner Zweck der vorliegenden Erfindung liegt darin, für ein System und ein Verfahren zu sorgen, um einem Dialogspracherkennungssystem eingeschränkte Sprachverständnisfähigkeiten bereitzustellen.
Eine weitere Aufgabe der vorliegenden Erfindung ist es, ein System und ein Verfahren bereitzustellen, um die Aufgabe der Interpretation der Bedeutung hinter einer gesprochenen Äußerung zu vereinfachen.
Eine weitere Aufgabe der vorliegenden Erfindung ist es, ein System und ein Verfahren bereitzustellen, um ein Spracherkennungssystem bereitzustellen, dem ein Corpus zugrunde liegt und das in seiner Interpretation der Bedeutung hinter einer gesprochenen Äußerung sehr genau ist.
Noch eine weitere Aufgabe der vorliegenden Erfindung ist es, ein System und ein Verfahren bereitzustellen, um eine Vielzahl an Laufzeit-Interpretern zu benutzen, die durch ein Computernetzwerk mit dem Dialogspracherkennungssystem verbunden sind.
Diese und weitere Aufgaben werden durch die vorliegend Erfindung erfüllt, die ein System und ein Verfahren, wie in den Ansprüchen 1 und 10 definiert, bereitstellt. Ein Laufzeit-Interpreter empfängt als Eingabe einen kommentierten Corpus, der eine Liste von gültigen Äußerungen, Kontext-Bezeichner für jede gültige Äußerung und Token-Daten für jede gültige Äußerung, die die Bedeutung hinter der Äußerung darstellt, ist. Der Laufzeit-Interpreter empfängt als Eingabe auch eine Äußerung in der Textform, die im Corpus gefunden werden soll.
Wenn dem Laufzeit-Interpreter eine zu interpretierende Äußerung gegeben wird, sucht der Laufzeit-Interpreter im Corpus, lokalisiert die gesuchte gültige Äußerung und kehrt das Token zurück, das die Bedeutung der gültigen Äußerung darstellt.
Der Laufzeit-Interpreter unterstützt auch die Verwendung von Variablen, um die Corpusgröße zu reduzieren. Einige Äußerungen können Nummern, Daten, Zeiten oder andere Elemente einschließen, die zu viele Kombinationen haben, um im Corpus aufgezählt zu werden. Zum Beispiel könnte die Äußerung "Mein Geburtstag ist xxx", worin 'xxx' der Tag des Jahres ist, zu 366 Corpuseinträgen führen, einer für jeden möglichen Tag des Jahres (einschließlich des Schaltjahrs). In der vorliegenden Erfindung könnte jedoch eine Variable verwendet werden, um das Datum darzustellen. Solchermaßen würde ein reduzierter Corpus nur einen Eintrag für diese Äußerung einschließen: "Mein Geburtstag ist (DATUM)". Der Laufzeit-Interpreter ist in der Lage, diese Variablen im Corpus zu identifizieren, und führt während der Laufzeit die zusätzliche Verarbeitung durch, um die Variablen zu interpretieren. Die variablen Werte werden, wenn einmal interpretiert, in einer vorbestimmten Datenstruktur gespeichert, die mit dem Token verknüpft ist, dessen Äußerung die Variable einschloss. Dieser variable Wert kann dann vom interaktiven Sprachantwortsystem zurückgeholt werden.
Die vorliegende Erfindung stellt auch eine kundenspezifische Prozessorschnittstelle bereit, die dem Entwickler des interaktiven Sprachantwortsystems die Fähigkeit gestattet, den Betrieb des Betriebs des Laufzeit-Interpreters kundenspezifisch zu machen, ohne eigentlich den Interpreter selbst zu modifizieren.
Darüber hinaus stellt die vorliegende Erfindung ein System bereit, um eine Vielzahl an Interpretern zu verwenden, die mit einem Computernetzwerk verbunden sind. Verteilte Interpreter werden bereitgestellt, die die oben erwähnte selbe kundenspezifische Prozessorschnittstelle und denselben Laufzeit-Interpreter einschließen. Die verteilten Interpreter schließen jedoch einen zusätzlichen Verwalter ein, um die Mitteilungsübermittlung zwischen dem verteilten Interpreter und dem Computernetzwerk zu steuern. Ein resourcenverwalter wird ebenfalls bereitgestellt, der die verteilten Interpreter verfolgt, die mit dem Netzwerk verbunden sind, und der ihre Verwendung durch ein interaktives Sprachantwortsystem verwaltet.
Kurze Beschreibung der Zeichnungen
1 beschreibt eine Übersicht eines eingebetteten natürlichen Sprachverständnissystems.
2 ist eine Tabelle, die die in der bevorzugten Ausführungsform unterstützten variablen Typen zeigt.
3 beschreibt Testformate für die kommentierten ASR-Corpusdateien und die Verkäufer-spezifische ASP-Grammatikdatei.
4 ist ein Flussdiagramm, das den Betrieb des IVR beschreibt, wenn es auf den Laufzeit-Interpreter zugreift.
5 beschreibt eine verteilte Systemarchitektur.
Beschreibung der Bevorzugten Ausführungsform
Bevor die vorliegende Erfindung beschrieben wird, müssen mehrere Begriffe definiert werden. Diese Begriffe und ihre Definitionen schließen ein:
kommentierte ASR-Corpusdatei – Datendatei, die eine Auflistung gültiger Äußerungen in einer Grammatik sowie von Token-Daten für jede gültige Äußerung enthält, die dem Dialogspracherkennungssystem (IVR 130) die Bedeutung der gültigen Äußerung darlegen.
automatische Spracherkennung (ASR) – generischer Begriff für die Computerhardware und -software, die in der Lage ist, gesprochene Worte zu identifizieren und sie in einem Computerlesbaren Format wie beispielsweise einen Text (Buchstaben) zu berichten.
Zellen – diskrete Elemente innerhalb der Tabelle (die Tabelle ist aus Zeilen und Spalten von Zellen aufgebaut). In der mit der Definition der 'Regeln' unten abgegebenen Beispielregel würden "Ich will", "Ich brauche" und "Essen" jeweils in eine Zelle gesetzt werden. Darüber hinaus grenzen in der bevorzugten Ausführungsform die Zellen, die "Ich will" und "Ich brauche" enthalten, senkrecht aneinander an (selbe Spalte). Senkrecht angrenzende Zellen werden allgemein ODER-verknüpft. Die Zelle, die "Essen" enthält, würde in der Spalte rechts von der Spalte "Ich will" und "Ich brauche" auftreten, wobei es auf die Tatsache hinweist, dass "Essen" entweder nach "Ich will" oder "Ich brauche" kommen muss, und solchermaßen wird die Zelle, die "Essen" enthält, UND-verknüpft, um nach der Zelle zu kommen, die "Ich will" und "Ich brauche" enthält.
eingeschränkte Grammatik – eine Grammatik, die nicht jeden und alle möglichen Aussagen in der Sprache des Sprechenden einschließt; begrenzt den Umfang der akzeptablen Aussagen.
Corpus – eine große Liste.
Grammatik – die gesamte Sprache, die verstanden werden muss. Grammatiken können mittels Verwendung einer Reihe von Regeln oder durch die Auflistung einer jeden und aller Aussagen ausgedrückt werden, die innerhalb der Grammatik erlaubt sind.
Grammatikentwicklungs-Programmierwerkzeug (104) – verwendete Software für die Erzeugung einer Grammatik und einer Reihe an Regeln, die die Grammatik darstellen.
natürliches Sprachverständnis – die Erkennung der Bedeutung hinter gesprochenen Aussagen, die auf normale Weise gesagt werden.
Satz – die "aufbauenden Blöcke" der Grammatik; ein Satz ist ein Wort, eine Gruppe von Worten oder eine Variable, die eine ganze Zelle innerhalb der Tabelle besetzt.
Regeln – diese bestimmen die Logik der Grammatik. Eine Beispielregel ist: ("Ich will" 1 "Ich brauche") ("Essen"), was eine Grammatik bestimmt, die nur aus Aussagen besteht, die mit "Ich will" ODER "Ich brauche" beginnen UND nach denen unmittelbar "Essen" kommt.
Laufzeit-Interpreter (124) – Software, die nach dem kommentierten Corpus (122) sucht, wann auch immer eine gültige Äußerung gehört wird, und die ein Token zurückführt, das die Bedeutung der gültigen Äußerung darstellt.
Laufzeit-Interpreter-Anwendungsprogrammschnittstelle (RIAPI) – Reihe an Softwarefunktionen, die als Schnittstelle dienen, mittels der das Schnittstellen-Sprachantwortsystem (130) den Laufzeit-Interpreter verwendet.
Spracherkenner (116) – Kombination aus Hardware und Soft ware, die in der Lage ist, gesprochene Worte zu erfassen und zu erkennen.
Spracherkenner-Compiler (114) – mit einem Spracherkenner (116) eingeschlossene Software, die als Eingabe eine Verkäuferspezifische ASR-Grammatikdatei (112) annimmt und die Datei (112) zur Verwendung in einem Spracherkenner (116) während der Laufzeit verarbeitet.
Tabelle – zweidimensionales Raster, das verwendet wird, um eine Grammatik darzustellen. Die Inhalte einer Tabelle werden in der bevorzugten Ausführungsform von links nach rechts gelesen.
Token – jeder gültigen Äußerung in der Tabelle folgt eine Zelle, die ein Token enthält, worin das Token ein eindeutiger Datenwert ist (vom Entwicker erzeugt, wenn er bzw. sie die Grammatik entwickelt), der dem interaktiven Sprachantwortsystem (130) die Bedeutung der gültigen Äußerung darlegen wird.
Äußerung – eine Aussage
Äußerung, gesprochen – eine Äußerung, die laut gesagt wurde. Die gesprochene Äußerung könnte auch eine gültige Äußerung sein, wenn die gesprochene Äußerung den Regeln der Grammatik nachkommt.
Äußerung, gültig – eine Äußerung, die innerhalb der Grammatik gefunden wird. Eine gültige Äußerung folgt den Regeln, die die Grammatik bestimmen.
Variable – "Platzhalter", der im Corpus (122) verwendet wird, um einen Satz darzustellen, der zu viele Möglichkeiten hat, um sie vollständig aufzuzählen. Zum Beispiel könnte die Äußerung "Meine Lieblingszahl zwischen 1 und 1 Millionen ist xxx" zu 999.998 Corpuseinträgen, einen für jede mögliche Zahl, führen. In der vorliegenden Erfindung würde jedoch eine Variable verwendet werden, um die Zahl im Corpus (122) darzustellen. Solchermaßen würde ein reduzierter Corpus (122) nur einen Eintrag für diese Äußerung einschließen: "Meine Lieblingszahl zwischen 1 und 1 Millionen ist (GANZZAHL)". Der Laufzeit-Interpreter (124) ist in der Lage, diese Variable im Corpus zu erkennen, und führt während der Laufzeit eine zusätzliche Verarbeitung durch, um die Zahl zu interpretieren.
Verkäufer-spezifische ASR-Grammatikdatei (112) – eine Datendatei, die die Reihe an Regeln enthält, die eine Grammatik darstellen, und die in einem Format geschrieben ist, das vom Spracherkennung-Compiler (114) erkannt werden wird.
Nimmt man jetzt auf die Zeichnungen Bezug, worin Elementen, die in mehreren Zeichnungen erscheinen, mit denselben Bezugszeichen in den Zeichnungen bezeichnet sind, werden in der 1 die Strukturen gezeigt, die nötig sind, um eine bevorzugte Ausführungsform eines eingebetteten natürlichen Sprachverständnissystems (100) zu implementieren. Die Grundelemente umfassen:
ein interaktives Sprachantwortsystem (130) oder IVR;
das Grammatik-Entwicklung-Programmierwerkzeug (104);
einen Compiler (114) und einen Spracherkenner (116), die Teil eines automatischen Spracherkennung-(ASR)-Systems (118) sind;
eine kommentierte automatische Spracherkennung-(ASR)-Corpusdatei (122);
eine Verkäufer-spezifische ASR-Grammatikdatei (112);
den Laufzeit-Interpreter (124); und
die Kunden-Prozessorschnittstelle (126) oder CP; und
die Laufzeit-Interpreter-Anwendungsprogramm-Schnittstelle (128) oder RIAPI. Diese Elemente werden unten weiter detailliert erörtert; jedoch wird ein anfänglicher Überblick über die eingebettete Architektur für ein volles Verständnis der Elemente und ihrer Regeln nützlich sein.
1. Überblick über die eingebettete Architektur
Die folgende Übersicht erörtert die eingebettete Architektur, die einen einzelnen Laufzeit-Interpreter (124) benutzt. Es gibt eine zweite verteilte Architektur, die eine Vielzahl an Laufzeit-Interpretern benutzt. Die verteilte Architektur wird weiter unten erörtert.
Der erste Schritt bei der Implementierung eines natürlichen Sprachsystems ist die Erzeugung einer Reihe an Regeln, die die gültigen Äußerungen in der Grammatik leiten. Als Beispiel könnte eine Grammatik für die Antwort auf die Frage: "Was willst du zum Abendessen" dargestellt sein als:
<Antworte (("Ich will" 1 "Ich möchte") ("Hotdogs" 1 "Hamburger"));
Unter dieser Regelreihe bestehen alle gültigen Antworten aus zwei Teilen: 1) entweder "Ich will" oder "Ich möchte", gefolgt von 2) entweder "Hotdogs" oder "Hamburger". Auf diese Schreibweise wird als Backus-Naur-Form (BNF) Bezug genommen, die eine Grammatikform ist, die logische UNDs und ODERs verwendet. Die bevorzugte Ausführungsform der vorliegenden Erfindung erzeugt diese Art an Grammatik.
Nimmt man auf die 1 Bezug, wird die Grammatik durch einen Entwickler erzeugt, der das Grammatik-Entwicklung-Programmierwerkzeug (104) verwendet. In der bevorzugten Ausführungsform wird das Werkzeug (104) mittels Verwendung eines Computers entwickelt, der eine Intel-basierte Zentralverarbeitungseinheit (CPU 102) hat (beispielsweise der Intel Pentium mit Microsoft Visual Basic als Softwareentwicklungsprogramm). Der Computer enthält auch einen Direktzugriffspeicher (RAM 106), im Systemspeicher gespeicherte Speicherdateien (108) und eine Tastatur (110).
Das Programmierwerkzeug (104) ist ein neuartiges Tabellenkalkulations-ausgerichtetes Softwarepaket, das dem Entwickler einer natürlichen Sprachanwendung einen einfacheren Weg zum Erzeugen einer Grammatik bereitstellt.
Wenn der Entwickler mittels Verwendung des Programmierwerkzeugs (104) die Grammatik beendet hat, werden vom Programmierwerkzeug (104) zwei Ausgaben für die Verwendung im natürlichen Sprachsystem erzeugt. Die erste dieser Ausgaben ist eine Verkäufer-spezifische ASR-Grammatikdatei (112), die in einem Format gesichert wird, das vom automatischen Spracherkennungssystem oder ASR (118) erkannt werden wird. Das ASR-System (118) schließt zwei Teile ein, einen Compiler (114) und den eigentlichen Spracherkenner (116). In der bevorzugten Ausführungsform ist ein Spracherkenner (116) ein Sprecher-unabhängiger Spracherkenner für kontinuierliches Sprechen. Im Handel erhältliche Spracherkenner (116) schließen den ASR-1500, von Lernout & Hauspie hergestellt; Watso 2,0 von AT&T hergestellt, und den Nuance 5,0 von Nuance ein. Die bevorzugte Ausführungsform des Programmierwerkzeugs (104) ist in der Lage, Grammatikdateien für jeden dieser Erkenner zu erzeugen.
Die Verkäufer-spezifische ASR-Grammatikdatei (112) enthält eine Information, die die Worte und Sätze betrifft, die der Spracherkenner (116) zum Erkennen benötigen wird, und zwar in einer Form geschrieben, die mit dem Erkenner kompatibel ist. Die Datei ist auch optimiert, um von den Besonderheiten zu profitieren, die den ausgesuchten Spracherkenner (116) betreffen. Zum Beispiel hat die Erfahrung mit den L&H-Erkennern gezeigt, dass L&N-Grammatiken gut durchführen, wenn die Grammatik vermeidet, in Zusammenhang mit demselben Anfang (drei Regeln, die mit "Ich will" beginnen) mehrere Regeln zu haben. Die Optimierung einer Grammatik für einen L&H-Erkenner würde eine Reihe an Regeln von <Regel1>:(ab)|(ac)|(ad) auf <Rege12>:a(b|c|d) umschreiben. Hier wurden die drei Regeln der 'Regel1' neugeschrieben und in einer Regel der 'Regel2' vereint.
Um mit Sprache zu arbeiten und sie zu erkennen, wird der Spracherkenner die Verkäufer-spezifische ASR-Grammatikdatei (112) kompilieren müssen, indem er ein Compiler-Programmierwerkzeug (114) verwendet, das vom ASR-System-(118)-Verkäufer geliefert wird. Die bevorzugte Ausführungsform des Programmierwerkzeugs (104) weiß, wann die Grammatik als erstes erzeugt wird, welcher Spracherkenner (116) verwendet werden wird, und ist in der Lage, die Verkäufer-spezifische ASR-Grammatikdatei (112) entsprechend zu formatieren.
Die zweite Ausgabe aus dem Programmierwerkzeug (104) ist ein kommentierter ASR-Corpus (122), der eigentlich ein Paar an Flat-Files darstellt. Ein Testformat für diese Dateien wird in der 3 gezeigt. Das erste Paar ist eine Corpusdatei und enthält die Auflistung aller möglichen logischen Sätze oder Wortverbindungen in der Grammatik (mit Ausnahme der Variablen, unten erörtert), die Fächer (Gruppen der Tabellen), in denen sie erscheinen, und einen Wert, der die Klasse der gehörten Äußerung (Satz) darstellt. Das zweite ist eine Antwortdatei, die jede Äußerungsklasse mit einem Token oder Datenwert abbildet, das bzw. der die Bedeutung der Äußerung darstellt. Diese zwei Dateien werden vom Laufzeit-Interpreter (124) verwendet.
Während der Laufzeit spricht ein Sprecher in das am Spracherkenner (116) angebrachte Mikrophon (oder Telefon) (120). Der Erkenner (116) erkennt die Worte und Sätze, die er hört, und meldet dem IVR (130), wenn eine gültige Äußerung gehört wurde. Das IVR (130) ist das System, das die Sprachverständnisfähigkeiten braucht, und schließt die erforderlichen externen Anschlüsse und die Hardware ein, um zu funktionieren (z. B. könnte ein Bankwesen-IVR – 130 eine Verbindung mit der Bankdatenbank, eine Tastatur zur Eingabe der Daten, eine visuelle Anzeige zum Anzeigen der Information, eine Ausgabe zum Ausgeben des Geldes und einen Lautsprecher zum Zurücksprechen an den Benutzer einschließen). Diese gültige Äußerung wird in einer vom Computer lesbaren Form wie beispielsweise einem Text an das IVR (130) geleitet, das dem Laufzeit-Interpreter (124) dann die Äußerung meldet, die gehört wurde. Der Laufzeit-Interpreter (124) zieht den kommentierten ASR-Corpus (122) zu Rate und gibt für den vom Erkenner (116) gehörten gültigen Satz ein richtiges Token an das IVR (130) zurück. Dieses Token stellt die Bedeutung der Äußerung dar, die vom Erkenner (116) gehört wurde, und das IVR (130) ist daraufhin in der Lage, die Äußerung richtig zu beantworten. Die CP (126) und RIAPI (128) dienen als Softwareschnittstellen, mittels derer das IVR (130) auf den Laufzeit-Interpreter (124) zugreifen kann. Es ist das IVR (130), das letztlich die Sprachfähigkeiten verwendet, um während der Laufzeit mit dem Sprechenden zusammenzuwirken.
3. Der Laufzeit-Interpreter
Der Laufzeit-Interpreter (124) ist eine Softwarekomponente, die in Textform eine gültige gesprochene Äußerung, die gehört wurde, und eine Kontextinformation empfängt, die die zu suchenden Fächer erkennt. Der Laufzeit-Interpreter (124) führt dann mittels der Corpusdatei (122) (die für die schnellere Suche in den RAM geladen wurde) eine Suche durch, um die gültige Äußerung zu finden. Ist einmal eine gültige Äußerung im Corpus gefunden, wird das dazugehörige Token im Speicher gespeichert, um vom IVR (130) zurückgeholt zu werden. In einer eingebetteten Anwendung werden an den Laufzeit-Interpreter (124) gemachte An fragen durch Funktionen innerhalb des kundenspezifischen Prozessors (126) oder CP vorgenommen. Der CP (126) ist eine weitere Softwarekomponente, die ursprünglich ein transparenter "Vermittler" zwischen dem Laufzeit-Interpreter (124) und der RIAPI (128) ist. Das IVR (130), das vom Entwickler erzeugt wird, greift nur auf die Funktionen innerhalb der RIAPI (128) zu. Die RIAPI (128) wird die erforderlichen CP (126)-Aufrufe machen, die wiederum die erforderlichen Laufzeit-Interpreter(124)-Aufrufe machen.
Der Zweck des Verfügens über den CP (126) liegt in der Ermöglichung einer Kundenspezifizität. Der CP (126) kann vom Entwickler kundenspezifisch hergestellt werden, um die Verarbeitung der Äußerungen zu verbessern. Der Entwickler kann z. B. wünschen, eine Verarbeitungsform an der Äußerung durchzuführen, bevor sie tatsächlich vom Laufzeit-Interpreter (124) verarbeitet wird. Diese Vorverarbeitung kann vom Entwickler zum CP (126) hinzugegeben werden, ohne eigentlich den Laufzeit-Interpreter (124) zu modifizieren. Die Verwendung des CP (126) ist besonders angebracht, wenn das unterliegende IVR (130) in einer niedrigeren Skiptsprache wie beispielsweise Vos (von Parity) oder BlaBla (von MediaSoft) gemacht wird, die die Vorverarbeitung des geäußerten Texts nicht direkt unterstützt. Wenn das IVR (130) in einer höheren Sprache wie beispielsweise C++ geschrieben ist, dann kann die Vorverarbeitung des geäußerten Texts im Code des IVR (130) selbst, ohne den Bedarf nach dem CP (126) gemacht werden.
Der Laufzeit-Interpreter (124) stellt auch eine Funktion bereit, um Variable aus den Äußerungen zu extrahieren. Wenn die Corpusdatei als erstes geladen wird, werden Corpus-Gegenstände, die Variable enthalten, markiert. Wenn eine anfängliche binäre Suche mittels des Corpus zum Finden der genauen Äußerung fehlschlägt, wird eine zweite Suche durchgeführt, um eine Teilübereinstimmung der Äußerung zu finden. Dieses Mal werden nur markierte Corpus-Gegenstände gesucht, und die Teilübereinstimmung wird gefunden, wenn die Äußerung mindestens die nicht variablen Abschnitte eines Corpus-Gegenstände enthält.
Das Corpusdateiformat (122) der bevorzugten Ausführungsform verwendet eckige Klammern ('[' und ']'), um die Variablen von normalen Worten in die gültigen Äußerungen zu unterscheiden. Solchermaßen könnte die Äußerung "Ich möchte [WÄHRUNG!, Geld] auf mein Sparkonto überweisen" in der Corpusdatei gefunden werden. Wenn die vom Erkenner (116) gehörte gesprochene Äußerung "Ich will zehn Dollar auf mein Sparbuch überweisen" ist, würde es einer anfänglichen Binärsuche wahrscheinlich misslingen, die gesprochene Äußerung mit irgendeinem der Corpus-Gegenstände in Übereinstimmung zu bringen. Wenn diese anfängliche Suche misslingt, dann führt der Interpreter (124) eine zweite Suche von allen markierten Corpus-Gegenstände durch. Die gesprochene Äußerung, die gehört wurde, enthielt wenigstens "Ich will überweisen... auf Sparkonto" und eine Teilübereinstimmung würde vorgenommen werden. Die nicht im Übereinstimmung gebrachten Worte "zehn Dollar" würden dann von einem anderen Algorithmus als eine Variable der Art [WÄHRUNG!, Geld] verarbeitet werden, die den Wortlaut "zehn Dollar" auf 10,00 konvertieren und die 10,00 als mit dem Token "Geld" assoziierte Variable zurückführen. Diese variablen Daten werden in einer vorbestimmten Datenstruktur gespeichert, die mit der Stelle im Speicher verknüpft ist, an der das Token gespeichert wurde. Wenn das IVR (130) das Token verarbeitet, weiß es, dass die variablen Daten ebenfalls zurückgeführt wurden, und holt sich die variablen Daten aus dem Speicher.
Der Algorithmus zum Konvertieren der Variablen in den Äußerungen auf variable Daten hängt von der innerhalb des Variablen enthaltenen Datentyps ab. 2 zeigt Variable-Typen, die von der bevorzugten Ausführungsform unterstützt werden. Der folgende Pseudocode veranschaulicht die in der bevorzugten Ausführungsform verwendeten Schritte zum Konvertieren des Variablenabschnitts der Äußerung (in Textform) auf die variablen Daten (in Zahlenform).
INTEGER1: ("Einhunderttausend und Zehn")
Setze TEMP Ergebnispuffer = 0;
Trenne Variablenabschnitt der Äußerung auf der Grundlage der Leerstellen zwischen den Worten in einzelne Worte (d. h. "ein" "hundert" "tausend" "und" "zehn"). Für jedes einzelne Wort (von links nach rechts gelesen):
INTEGER2: ("Eins Zwei Drei Vier")
Wie in Zusammenhang mit der INTEGER1, breche variable Äußerung in einzelne Worte auf und setze einen TEMP-Puffer = 0;
FÜR jedes einzelne Wort (von links nach rechts gelesen), multipliziere TEMP mit 10
WÄHRUNG1: ("Dreiundzwanzig Dollar und fünfzehn Cents")
Wie in Zusammenhang mit der INTEGER1, breche variable Äußerung in einzelne Worte auf und setze einen TEMP-Puffer = 0;
FÜR jedes einzelne Wort (von links nach rechts gelesen):
WÄHRUNG2: ("zwei drei Dollar und ein fünf Cents")
Wie in der INTEGER1, breche variable Äußerung in einzelne Worte auf und setze TEMP-Puffer = 0;
FÜR jedes einzelne Wort (von links nach rechts gelesen)
ZEIT: ("one o'clock p.m.", "thirteen hundred hours")
Wie in der INTEGER1, breche variable Äußerung in einzelne Worte auf und setze die Puffer STUNDE, MIN. = 0)
Lösche ("Uhr", "Minuten", "Stunden")
DATUM1: ("März Eins neunzehn neunundsiebzig", "Erster März")
Wie in INTEGER1, breche variable Äußerung in einzelne Worte auf und setze Puffer MONAT, TAG, JAHR, UNBEKANNT = 0 und setze Flag getan = N)
FÜR jedes Wort
Der grundlegende Betrieb des Laufzeit-Interpreters (124), wie vom interaktiven Sprachantwortsystem (IVR) gezeigt und verwendet, wird in der 4 gezeigt. In der folgenden Beschreibung sind die verwendeten spezifischen Funktionsnamen die in der bevorzugten Ausführungsform gefundenen. Als erstes muss das IVR (130) im Schritt 400 gestartet werden. Das IVR (130) ist ein Softwaresystem zum Durchführen anderer Pflichten wie beispielsweise das Steuern eines Bankautomatens, der von den Sprachverständnisfähigkeiten der vorliegenden Erfindung profitiert. Zum Beispiel kann eine Bank ein IVR (130) entwickeln, um für einen sprechenden Bankautomaten zu sorgen. In der bevorzugten Ausführungsform ist das IVR (130) zur Verwaltung des Spracherkenners (116) während der Laufzeit verantwortlich.
Eines der ersten Dinge, die das IVR (130) zu tun gewillt sein wird, ist das Initialisieren des Spracherkenners im Schritt 402. Die genauen Schritte, die für die Initialisierung eines Spracherkenners erforderlich sind, werden davon abhängen, welcher kommerzielle Spracherkenner verwendet wird; jedoch werden die allgemeinen Schritte das Kompilieren der Verkäuferspezifischen ASR-Grammatik (112), die mittels Verwendung des Programmierwerkzeugs (104) erzeugt wurde, und das Laden der kompilierten Version in irgendeine Form des lokalen Speichers beinhalten, auf den der Spracherkenner (116) zugreifen kann.
Als nächstes wird im Schritt 404 der Laufzeit-Interpreter (124) initialisiert werden müssen. Dies wird getan, wenn das IVR (130) die NL Init-Funktion abruft. Diese Funktion empfängt im Wesentlichen als Eingabe einen Dateipfad und -namen für den kommentierten ASR-Corpus (122), der für die aktuelle Anwendung verwendet werden wird, und speichert diesen Dateipfad und -namen im Speicher.
Im Schritt 406 beendet das IVR (130) die Errichtung des Laufzeit-Interpreters (124), indem es die NL_OpenApp-Funktion abruft. Diese Funktion greift auf die Corpusdatei zu, deren Namen und Dateipfad im Schritt 404 von der NL_Init-Funktion gespeichert wurden, und lädt den Corpus in den Systemspeicher (RAM) in Vorbereitung für die Durchsuchung. Um die Suche zu optimieren, werden die Inhalte der Corpusdatei (der verschiedenen gültigen Äußerungen) alphabetisch geordnet, wenn sie in den RAM geladen werden. Das alphabetische Ordnen der gültigen Äußerungen wird die Suchleistung verbessern, da in der bevorzugten Ausführungsform eine Binärsuche verwendet wird, um eine Äußerung mit einem Token in Übereinstimmung zu bringen. Binärsuchen sind ein gebräuchliches Verfahren für die Suche in sortierten Listen zum Finden eines Ziel-Elements und beinhalten grundsätzlich das progressive Halbieren des Bereichs der Listen-Gegenstände, die durchsucht werden, bis der Ziel-Genestand gefunden wird.
Während dieses Ladevorgangs werden die Corpusdaten ebenfalls optimiert durch 1) das Markieren der Corpus-Gegenstände, die die Variablen enthalten und 2) das Erzeugen der Liste (von groß zu klein), die die Reihenfolge bestimmt, in der die Corpus-Gegenstände für die zweite Suche verarbeitet werden. Diese letzte Optimierung ist wichtig, da, wenn die zweite Suche nach Fragmenten sucht, kleinere Fragmente (weniger Worte) unbeabsichtigt in Übereinstimmung gebracht können, wenn ein größeres Fragment geeigneter ist. Z. B. der Gegenstand: "Ich will... auf Sparkonto überweisen" ist kleiner als der Gegenstand "Ich will... britische Pfund aufs Sparkonto überweisen". Wenn die gesprochene Äußerung "Ich will zehn britische Pfund aufs Sparkonto überweisen" ist, und der kleinere Gegenstand zuerst verarbeitet wird, wird es falsch in Übereinstimmung bringen ("Ich will... auf Sparkonto überweisen" wird gefunden) und die übrigen Worte ("zehn britische Pfund") zur Verarbeitung als ein Variable im ersten Gegenstand übertragen, wenn "zehn" eigentlich als eine Variable im zweiten Gegenstand verarbeitet werden sollte. Es ist wichtig, dass zuerst größere Gegenstände verarbeitet werden, wenn die zweite Suche geführt wird, und diese Reihenfolge wird gemacht, wenn der Corpus anfänglich in den RAM-Speicher geladen wird. Eine getrennte Liste an Zeigern wird erzeugt und im Speicher gespeichert, wenn der Corpus geladen wird, und diese Liste bezeichnet die Reihenfolge (groß nach klein), in der Gegenstände mit Variablen verarbeitet werden sollten. Eine Liste von markierten Corpus-Gegenstände wird ebenfalls im Speicher gespeichert.
Wenn einmal sowohl der Spracherkenner (116) als auch der Laufzeit-Interpreter (124) initialisiert wurden, und nachdem der Laufzeit-Interpreter (124) den Corpus geladen hat, ist der Laufzeit-Interpreter bereit, die Arbeit zu machen. Zu diesem Zeitpunkt kann das IVR (130) mit anderen Verarbeitungen beschäftigt sein, und der Laufzeit-Interpreter (124) wartet.
Zu irgendeinem zukünftigen Zeitpunkt wird das IVR (130) erfassen, dass eine Konversation mit einem Sprecher im Begriff ist zu beginnen. Wenn dies geschieht, wird das IVR (130) eine Sitzung innerhalb des Laufzeit-Interpreters (124) öffnen müssen (eine Sitzung ist ein Dialogaustausch mit dem Sprecher). Das IVR (130) tut dies, indem es die NL_OpenSession-Funktion im Schritt 406 abruft. Diese Funktion erzeugt eine Sitzungsabwicklung und verknüpft die Sitzungsabwicklung mit der Sitzung, die geöffnet wurde. Zukünftige Funktionsabrufe, die diese Sitzung betreffen, werden die Sitzungsabwicklung verwenden, um auf die Sitzung Bezug zu nehmen.
Dann informiert der Spracherkenner (116) den IVR (130) im Schritt 408, dass eine vollständige Äußerung gehört worden sein kann. In der bevorzugten Ausführungsform sind die Spracherkenner (116) der Art, die Daten in NBest-Form zurückgeben. NBest-Form ist einfach ein Ausgabedatenformat, das eine Liste an vom Spracherkenner (116) gehörten möglichen gültigen Äußerungen (in Textform) zusammen mit einer Vertrauenszahl, die auf die Wahrscheinlichkeit deutet, dass jede gültige Äußerung gehört wurde, einschließt.
Das NBest-Format ist dienlich, wenn es mehrere gültige Äußerungen gibt, die gleich klingen. Wenn z. B. die gültige Grammatik "I want honey" und "I want money" einschließt, und der Sprecher "I want mfhoney" murmelt, wird der Spracherkenner eher die beiden gültigen Äußerungen als Möglichkeiten zurückgeben, als einfach die einzelne gültige Äußerung zurückzugeben, von der er annimmt, dass sie am korrektesten klang. Eine Vertrauenszahl ist ebenso für jede gültige Äußerung eingeschlossen, die auf das Vertrauen des Spracherkenners hinweist, dass diese besonders gültige Äußerung tatsächlich diejenige war, die er hörte. Diese Vielzahl an Möglichkeiten ist nützlich, wenn der Laufzeit-Interpreter (124) auch den Kontext der aktuellen Diskussion kennt und die Kontextinformation verwenden kann, um genauer zu bestimmen, welche gültige Äußerung gemeint war. Wie unten beschrieben werden wird, wird die bevorzugte Ausführungsform des Laufzeit-Interpreters (124) in seiner Bestimmung, was gemeint war, eine solche Kontextinformation verwenden.
Nachdem das IVR (130) die Ausgabe vom Spracherkenner (116) empfängt, wird dann die Ausgabe im Schritt 410 zur Interpretation an den Laufzeit-Interpreter (124) gereicht. Um dies zu tun, wird das IVR (130) in der bevorzugten Ausführungsform die NL-AnalyzeNbest-Funktion abrufen. Diese Funktion nimmt als Eingabe die vom IVR (130) empfangenen NBest-Daten, eine Sitzungsabwicklung und einen Kontextzeiger an, der auf das Fach deutet, das gesucht werden soll.
Wenn die NL AnalyzeNbest-Funktion ausgeführt wird, sucht der Laufzeit-Interpreter (124) im Corpus (122), der in den Speicher geladen wurde, um die gültige Äußerung zu finden. Wenn eine Übereinstimmung gefunden wird, wird das Rückkehr-Token im Speicher gespeichert. Wenn keine Übereinstimmung gefunden wird, wird das Rückkehr-Token im Speicher gespeichert. Wenn keine Übereinstimmung gefunden ist, wird die oben erörterte Variablensuche durchgeführt werden und die variablen Daten werden in einer vorbestimmten Datenstruktur gespeichert werden. Diese Suche wird im Schritt 412 gezeigt.
Nachdem NL_AnalyzeNbest abgerufen wird, wird das IVR (130) das NL_GetResult im Schritt 416 abrufen müssen, um aus dem Speicher das von der NL-AnalyzeNbest-Funktion gespeicherte Token zurückzuholen. Wenn das Token anzeigt, dass in der Äußerung eine Variable eingeschlossen war, dann wird das IVR (130) im Schritt 416 die NL_GetVariable abrufen, um die vom NL_AnalyzeNbest verwendeten Variablenwerte aus der vorbestimmten Datenstruktur im Speicher zurückzuholen, um die Variablendaten zu speichern.
Wurden das Token und irgendwelche nötigen Daten einmal im Speicher gespeichert, wird der Laufzeit-Interpreter (124) für die Sitzung beendet (für jetzt). Im Schritt 418 wartet der Laufzeit-Interpreter (124) entweder auf eine andere Äußerung oder ein Ende für die Sitzung.
Wenn eine weitere Äußerung erfolgt, wird der Spracherkenner (116) dies dem IVR (130) im Schritt 408 erneut melden, der IVR (130) wird NL_AnalyzeNbest im Schritt 410 abrufen und das Verfahren fährt wie zuvor fort.
Wenn die Sitzung zu beenden ist, wird das IVR (130) im Schritt 420 die NL_CloseSession abrufen. Das Schließen der Sitzung löst die Sitzungsabwicklung auf.
Zu diesem Zeitpunkt wartet im Schritt 422 der Laufzeit-Interpreter (124) entweder darauf, eine neue Sitzung zu starten, oder auf den Befehl zum Schließen der aktuellen Applikation. Wenn eine neue Sitzung anfängt, wird das IVR (130) im Schritt 404 neuerlich die NL_OpenSession abrufen, und die Verarbeitung setzt sich wie zuvor vom Schritt 404 an fort. Wenn die aktuelle Applikation geschlossen werden soll, dann wird das IVR (130) im Schritt 424 die NL_CloseApp abrufen, um den Speicher freizugeben, der zugeordnet wurde, als die Applikation geöffnet wurde.
Dann ruft das IVR (130) in dem Schritt 426 NL-Shutdown (NL_Abschalte) ab, um die Auswirkungen des NL_Init aufzuheben.
Schließlich ist in den Schritten 428 und 430 das IVR (130) für das Schließen des Spracherkenners (116) als auch des IVR (130) selbst verantwortlich. Die erforderlichen eigentlichen Schritte werden sowohl vom ausgesuchten Spracherkenner (116) als auch vom IVR-Entwickler abhängen.
Der Laufzeit-Interpreter (124) stellt auch die Funktion für den Entwickler bereit, der wünscht, die vom CP (126) gereichten Nbest-Daten zu verwalten. Funktionen sind erhältlich, um Nbest-Puffer (NB_CreateBuffer) zu erzeugen, einen Nbest-Puffer mit nur einer Äußerung (NB_GetOneBest) zu erzeugen; eine Äußerung in einen Nbest-Puffer zu setzen (NB_SetUtterance); einen Treffer für eine Äußerung in einen Nbest-Puffer zu setzen (NB_SetScore); ein Äußerungs/Trefferpaar in einen Nbest-Puffer zu setzen (NB_SetUtteranceScore); die Zahl der Äußerungen zu bestimmen, die im Nbest-Puffer gespeichert werden können (NB_GetNumResponses); eine Äußerung aus einem Nbest-Puffer zu erhalten (NB_GetUtterance); einen Treffer aus einem Nbest-Puffer zu erhalten (NB_GetScore) und den für einen bestimmten Nbest-Puffer zugeordneten Speicher freizugeben (NB_DestroyBuffer).
4. Die Laufzeit-Interpreter-Applikationsprogramm-Schnittstelle
Die Laufzeit-Interpreter-Applikationsprogramm-Schnittstelle (128) oder RIAPI ist die Gruppe an Softwarefunktionen, die eigentlich vom Entwickler des IVR (130) verwendet wird, um mit dem Laufzeit-Interpreter (124) zusammenzuwirken. Die Funktionen, die in der bevorzugten Ausführungsform der RIAPI (128) eingeschlossen sind, umfassen: NL_Init(), NL_OpenApp(), NL_Open-Session(), NL_AnalyzeNbest(), NL_GetResult(), N_GetVariable(), NL_CloseSession(), NL_CloseApp() und NL_Shutdown().
NL-Init ist eine Initialisierungsfunktion, die während des Aufwärmens einmal abgerufen wird, um die Startinformation zu verarbeiten und den Speicher für die Sitzungen zuzuordnen. Die Startinformation kann einen Namen für eine lokale Logdatei, die Höchstzahl an Sitzungen und den Routingmodus einschließen (eingebettet oder verteilt – die verteilte Architektur wird weiter unten erörtert werden). Ein Abruf für NL_Init in der beispielhaften Ausführungsform führt zu einem Abruf für CP_Init (die CP-Entsprechung), die dann SAI_Init abruft (die Laufzeit-Interpreter-124-Entsprechung). Die meisten der anschließenden RIAPI-(128)-Funktionen werden auch zu Funktionsabrufen für den CP (126) führen, der dann die entsprechende Laufzeit-Interpreter-(124)-Funktion abruft. Zwei Ausnahmen in der bevorzugten Ausführungsform sind die NL_GetVariable- und die NL_GetResult- Funktion, die direkt auf den Speicher zugreifen, um die Variable oder das Ergebnis zurückholen.
NL_OpenApp wird abgerufen, um eine Applikation im Interpreter (124) zu errichten. Wie oben geschildert, ist eine Applikation ein Fall oder eine Implementierung eines Projekts. Das Öffnen einer Applikation veranlasst, dass der Interpreter (124) die mit der Applikation verknüpfte Corpusdatei (122) lädt.
Die NL_OpenSession wird abgerufen, wenn eine Sitzung unter einer offenen Applikation erwünscht ist. Eine Sitzung ist im Wesentlichen eine Konversation mit einem Sprecher, und es ist für mehrere Sitzungen möglich, für dieselbe Applikation zu existieren (wenn z. B. das IVR 130 mehrere Spracherkenner verwaltet).
NL_AnalyzeNbest wird vom IVR (130) abgerufen, wenn der Spracherkenner angezeigt hat, dass er die Nbest-Ausgabe bereit hat. Das IVR (130) ruft diese Funktion ab, um die Nbest-Ausgabe sowie die Kontextinformation zur Analyse an den Laufzeit-Interpreter (124) zu senden.
Das NL_GetResult wird vom IVR (130) abgerufen, um das Token zu lesen, das vom Laufzeit-Interpreter (124) im Speicher gespeichert wurde.
Die NL_GetVariable wird abgerufen, wenn das vom Interpreter (124) gespeicherte Token einer Art ist, die über damit verknüpfte Variablendaten verfügt. Der Abruf nach NL_GetVariable holt diese Variablendaten aus der vom Interpreter (124) verwendeten Speicherdatenstruktur zurück, um die Daten zu speichern.
Die NL_CloseSession wird abgerufen, um die bestimmte Sitzung zu schließen und irgendwelche zugeordneten Resourcen, die mit der Sitzung assoziiert waren, zurückzugeben. Das Abrufen dieser Funktion kann zum Abruf weiterer Funktionen führen, die zum Schließen der Sitzung ebenfalls nötig sind. In der eingebetteten Architektur ruft die NL_CloseSession z. B. die CP_CloseSession auf, um dem CP (126) und dem Laufzeit-Interpreter (124) eine Gelegenheit zu erlauben, ihre jeweiligen Sitzungen zu schließen und die zugeordneten Resourcen zurückzugeben, die sie nicht länger brauchen.
Die NL-CloseApp wird abgerufen, um die bestimmte Applika tion zu schließen. Diese Funktion prüft, um sicherzustellen, dass alle Sitzungen geschlossen wurden, und kann auch andere Funktionen wie beispielsweise CP_CloseApp abrufen, um dem CP (126) und dem Interpreter (124) die Gelegenheit zu geben, auch "sich selbst zu leeren".
NL Shutdown wird abgerufen, um das System allgemein in den Zustand zurückzuführen, der bestand, bevor NL-Init abgerufen wurde. CP_Shutdown kann ebenfalls abgerufen werden, damit der CP (126) und der Interpreter (124) die Zuordnung ihrer resources aufheben.
Zusätzlich zu diesen Grundfunktionen wird die RIAPI (128) auch mit Inter/Intranet-Fähigkeiten bereitgestellt. Wenn das natürliche Sprachsystem über TCP/IP mit einem Netzwerk verbunden ist, kann die TopCallback-Funktion verwendet werden, um asynchrone TCP/IP-Steckereignisse zu verarbeiten. Die folgenden RIAPI-Abrufe, die aufgebaut sind, um mittels des Server-Schnittstellenprozesses (SIP) Verbindungen mit Internet zu unterstützen, sind ebenfalls verfügbar (obwohl für Nicht-SIP-Systeme nicht erforderlich): NL_WEBConnnect (um eine Sitzung mit einem entfernten Web-Browser-User zu öffnen), NL_ReportWEBText (um Textantworten an den Interpreter 124 zu reichen), NL_WEBPlay (um dem entfernten User Dateiinhalte anzuzeigen), NL_WEBListen (um eine Sitzung dahin zu führen, die Eingabe aus dem durch NL_WEBConnnect verbundenen SIP-Fall anzunehmen), NL_GetWEBResult (um Ergebnisse eines NL_WEBListen-Abrufs zurückzuholen) und NL_CloseWEBSession (um eine Sitzung zu schließen).
Als Schnittstelle zwischen dem IVR (130) und (letztendlich) dem Laufzeit-Interpreter (124) werden die an di e RIAPI (128) gemachten spezifischen Abrufe von den Erfordernissen des IVR (130) für die Funktionalität des Laufzeit-Interpreter (124) diktiert.
5. Überblick über die verteilte Architektur
Soweit hat diese Beschreibung die Elemente einer eingebetteten Architektur beschrieben. In einer eingebetteten Architektur sind sowohl der Laufzeit-Interpreter (124) als auch die RIAPI (128) Softwareelemente, die im selben Computer resi dieren.
In einer verteilten Architektur befindet sich eine Vielzahl an verteilten Laufzeit-Interpretern (508) zwischen einer Vielzahl an Stellen innerhalb eines Computernetzes (in der bevorzugten Ausführungsform werden sowohl das Unix- als auch das Windows NT-Netz unterstützt). Indem man über diese Vielzahl an Interpretern (508) verfügt, ist das IVR (130) in der Lage, eine Reihe an gleichzeitig verarbeiteten Äußerungen zu haben. Der deutlichste Vorteil diesbezüglich ist die Fähigkeit, mehrere Sitzungen zur selben Zeit zu bearbeiten.
5 zeigt die Elemente einer verteilten Systemarchitektur. Die meisten Elemente sind dieselben wie die in der eingebetteten Architektur gefundenen. Sowohl die Grammatik (112) als auch der Corpus (122) sind dieselben wie jene in der eingebetteten Architektur verwendeten. Der Unterschied liegt in den vielen verteilten Interpretern (508), dem Resourcen-Verwalter (510 – RM), Datenerfasser (512), der Bedieneranzeige (514) und dem Log-Anzeiger (516). Die verteilten Interpreter (508) und der RM (506) werden weiter unten erörtert.
Der Datenerfasser (512) ist einfach eine Softwarevorrichtung, die die unterschiedlichen Nachrichten aufzeichnet, die zwischen dem Resourcen-Verwalter (510) und den verschiedenen Interpretern (508) übertragen werden. Die Bedieneranzeige (514) und der Log-Anzeiger (516) sind Mittel, mit denen der Entwickler den Betrieb des IVR (130) und die mit dem System verknüpften unterschiedlichen Interpreter überwachen kann. In der bevorzugten Ausführungsform erlauben der Datenerfasser (512), die Bedieneranzeige (514) und der Log-Anzeiger (516) dem Benutzer oder Bediener keine Steuerung über die IVR-(130)-Applikation. Diese Vorrichtungen stellen bloß eine Information über den Betrieb der Applikation bereit.
6. Der verteilte Interpreter
In einer alternativen Ausführungsform der vorliegenden Erfindung wird ein verteiltes System verwendet. Das verteilte System arbeitet an einem vernetzten Computersystem. Ein vernetztes Computersystem bedeutet ganz einfach eine Vielzahl an Computern oder Knoten, die über ein Nachrichtennetz miteinander verbunden werden.
In einem verteilten System hat jeder Knoten, der Interpretierpflichten durchführt, einen DI-Verwalter (504), einen DICP (506) und einen DI-Laufzeit-Interpreter (508). Der DICP (506) und der DI-Laufzeit-Interpreter (508) haben dieselbe Funktion wie der in der oben erörterten Architektur gefundene CP (126) und Laufzeit-Interpreter (124). Der DI-Verwalter (504) ist ein weiteres Stück der Software, die für die Nachrichtenverarbeitung und die Koordination der Interpretierpflichten der Knoten verantwortlich ist. Die Nachrichtenverarbeitung hängt von der Art des Netzes ab, das verwendet wird, um die Knoten mit dem Resourcen-Verwalter (510) zu verbinden. Jedoch werden dieselben allgemeinen Nachrichtentypen verwendet. Die Nachrichtentypen und – zwecke werden unten erörtert.
Der Verwalter (504) selbst ist eine Softwarekomponente, und bevor er irgendwelche Nachrichten verarbeiten kann, muss er zunächst am Interpretierknoten ausführen. Wenn der Verwalter (504) gestartet wird, wird er in einer Initialisierungsdatei nach einer Information suchen, die die vom Verwalter (504) unterstützte Applikation betrifft. Diese Information schließt den Namen der unterstützten Applikation und den Dateipfad zur Stelle des kommentierten Corpus (122) ein, der für die unterstützte Applikation verwendet werden soll.
Die <Initialize> Nachricht veranlasst den DI-Verwalter (504), durch das Abrufen von CP_Init den DICP (506) zu starten, und der DICP (506) startet durch das Abrufen von SAI_Init den DI-Laufzeit-Interpreter (508). Diese Nachricht veranlasst den DI-Verwalter (504) auch, die zu unterstützende Applikation zu initialisieren, indem CP_OpenApp und SAI_OpenApp abgerufen werden, um die Applikation zu öffnen. Wie oben erörtert, erfordert das Öffnen einer Applikation das Laden des Corpus (122). Die Stelle des zu ladenden Corpus (122) wird an den DI-Laufzeit-Interpreter (508) weitergereicht. Wenn der DI-Laufzeit-Interpreter (508) seine Initialisierung beendet (und der Corpus 122 geladen ist), erzeugt er ein Applikations-Handle (nachstehend Applikationsabwicklung), das ein Datenobjekt darstellt, das die aktuelle Applikation betrifft. Diese Abwicklung (Handle) wird an den DICP (506) zurückgeführt, der sie wiederum zum DI-Verwalter (504) weiterleitet. Wann auch immer ein Fehler innerhalb der DI (502) auftritt, stellt der DI-Verwalter (504) eine <tell error> Nachricht auf, die den Fehler beschreibt und ihn zum RM (510) zurückführt.
Eine Sitzung wird geöffnet werden, wenn der DI-Verwalter (504) eine <start session> Nachricht empfängt. Diese Nachricht schießt eine Resourcen-Adresse ein, die das Sende-IVR (130) und einen Sitzungsbezeichner bezeichnet. Der DI-Verwalter (504) prüft, um sicherzustellen, dass es nicht bereits eine geöffnete Sitzung mit derselben Resourcen-Adresse gibt, und falls nicht, erzeugt er ein Sitzungsobjekt, das die Sitzung darstellen wird. Ein Sitzungsobjekt ist im Wesentlichen eines der oben erörterten Applikationsabwicklung gleichende Abwicklung, die diese Sitzung betrifft. Der DI-Verwalter (504) öffnet dann die Sitzung im DICP (506) und den DI-Laufzeit-Interpreter (508), indem er die CP_ OpenSession-Funktion abruft, die die SAI_OpenSession-Funktion abruft. Der Rückführungswert der SAI_OpenSession wird zurück an die CP_OpenSession geführt, die ihn zum DI-Verwalter (504) zurückführt. Neuerlich werden Fehler mit einer <tell error> Nachricht vom DI-Verwalter (504) gemeldet.
Wurde die Sitzung einmal geöffnet, ist die DI (502) zum Interpretieren bereit. Es gibt zwei Nachrichten, die den Vorgang der Interpretation starten. Als erstes könnte der DI-Verwalter (504) eine <analyze> Nachricht empfangen. Eine <analyze> Nachricht enthält die gesamte Kontext- und Nbest-Information, die für gewöhnlich für CP_AnalyzeNbest gebraucht wird. Der DI-Verwalter (504) ruft dann die DI-Laufzeit-Interpreter(508)-Angemessenheitsfunktionen NB_CreateBuffer und NB-SetUtteranceScore ab, um eine Struktur mit den Kontext- und Nbest-Daten vorzubereiten. Der DI-Verwalter (504) stellt dann die Datenstruktur als Eingabe für die CP_AnalyzeNbest-Funktion bereit, die die SAI_AnalyzeNbest-Funktion abruft, die die oben beschriebene Suche nach der eingebetteten Architektur durchführt. Wenn diese Funktionen abgeschlossen sind, breiten sich ihre Rückkehrwerte zurück zum DI-Verwalter (504) aus, der eine <reply> Nachricht zurück an den RM (510) sendet.
Das Empfangen der <analyze>Nachricht war lediglich ein Weg, wie die Interpretration gestartet werden konnte. Der andere Weg erfolgt, wenn die Kontext- und Nbest-Daten in getrennten Nachrichten übertragen werden. Wenn dies geschieht, sendet der RM (510) eine erste Nachricht oder <state> Nachricht, die den Kontext und eine Resourcen-Adresse enthält, die die Sitzung bezeichnet, in der die Äußerung gehört wurde. Beim Empfang dieser Nachricht bestätigt der DI-Verwalter (504) als erstes, dass die Resourcen-Adresse in der Tat die einer bestehenden Sitzung ist. Wenn sie es ist, holt der DI-Verwalter (504) die mit der Resourcen-Adresse verknüpfte Sitzungsabwicklung zurück und speichert die Kontextinformation von der Nachricht in einem vorübergehenden Speicherbereich, um auf die weitere Verarbeitung zu warten.
Diese weitere Verarbeitung wird erfolgen, wenn die zweite Nachricht vom DI-Verwalter (504) empfangen wird. Die zweite Nachricht oder <Nbest> Nachricht enthält eine Resourcen-Adresse und einige NBest-Daten. Wenn die <Nbest> Nachricht empfangen wird, prüft der DI-Verwalter (504) erneut, um sicherzustellen, dass die in der <Nbest> Nachricht eingeschlossene Resourcen-Adresse die einer bestehenden Sitzung ist. Wenn dem so ist, sucht der DI-Verwalter (504) dann nach dem mit der Sitzung verknüpften vorübergehenden Speicherbereich und findet die zuvor gespeicherte Kontextinformation. Nimmt man die Nbest-Daten und Kontextdaten, dann macht der DI-Verwalter (504) einen Abruf für CP_AnalyzeNbest, das dann SAI_AnalyzeNbest abruft, worin der Corpus (122) gesucht wird, um das mit der Äußerung in den Nbest-Daten verknüpfte Token zu finden.
Eine Sitzung wird beendet, wenn der DI-Verwalter (504) die <lost call> Nachricht empfängt. Diese Nachricht schließt eine Resourcen-Adresse ein, und der DI-Verwalter (504) prüft, um sicherzustellen, dass die Resourcen-Adresse tatsächlich auf eine offene Sitzung Bezug nimmt. Wenn dem so ist, ruft der DI-Verwalter (504) CP_CloseSession ab, die dann SAI_CloseSession abruft, und die Sitzung wird auf dieselbe Weise geschlossen, wie eine Sitzung in der eingebetteten Architektur geschlossen wird.
Wenn die gesamte Applikation geschlossen werden soll, wird der DI-Verwalter (504) eine <terminate> Nachricht empfangen. Da jeder Verwalter (504) nur eine Applikation gleichzeitig unterstützen kann, bedeutet das Schließen einer Applikation dasselbe wie das Schließen des Verwalters (504). Wenn der DI-Verwalter (504) diese Nachricht empfängt, macht er die erforderlichen Abfragen für die CP_CloseSession, um irgendwelche übrigen Sitzungen zu schließen, die offen sind, und ruft schließlich CP_Shutdown ab, das SAI_Shutdown abruft, und alle Resourcens, die dem Verwalter (504), DICP (506) und DI-Laufzeit-Interpreter (508) zugeordnet sind, werden freigegeben.
7. Der Resourcen-Verwalter
Der Resourcen-Verwalter (510) überwacht den Betrieb der mit dem Netzwerk verbundenen verschiedenen verteilten Interpretern (508) und verteilt RIAPI-(128)-Anfragen unter den Interpretern (508). In der bevorzugten Ausführungsform empfängt der RM (510) immer dann eine Nachricht, wenn ein verteilter Interpreter (508) gestartet wird, und zeichnet die Applikation auf, die vom verteilten Interpreter (508) unterstützt wird. Wenn dann der Resourcen-Verwalter die Anfragen von den IVR(n) (130) bis RIAPI (128) empfängt, prüft er, um zu sehen, welcher verteilte Interpreter (508) die Anfragen abwickeln kann (die Applikation unterstützt), und formuliert eine Nachricht, die die IVR(130)-Anfrage enthält, und sendet sie zur Verarbeitung dem richtigen Verwalter (504) zu. Der Resourcen-Verwalter (510) steht mittels Verwendung der oben beschriebenen Nachrichten mit den Verwaltern (504) in Verbindung.
Im Lichte der obigen Lehren ist es verständlich, dass Änderungen möglich sind, ohne sich vom Schutzumfang der Erfindung, wie in diesen Lehren verkörpert, zu lösen. Irgendwelche Beispiele, die als Teil der bevorzugten Ausführungsform der Erfinder bereitgestellt sind, werden nur beispielhaft dargelegt und sind nicht dazu gedacht, den Schutzumfang der Erfindung einzuschränken. Eher sollte der Schutzumfang der Erfindung mittels Verwendung der Ansprüche unten bestimmt werden.
Wenn in irgendeinem der Ansprüche erwähnte technische Merkmale mit einem Bezugszeichen versehen sind, wurden diese Bezugszeichen lediglich eingeschlossen, um die Verständlichkeit der Ansprüche zu erhöhen. Entsprechend haben diese Bezugszeichen keine einschränkende Auswirkung auf den Schutzumfang eines jeden Elements, das exemplarisch durch solche Bezugszeichen bezeichnet wird.

Claims

Ein Computersystem zur Identifizierung der Bedeutung einer gültigen gesprochenen Äußerung in einer bekannten Grammatik, wobei das System folgendes umfasst: eine Zentraleinheit (CPU) (102); einen Systemspeicher, der mit der CPU (102) verbunden ist, um Speicherdateien (108) zu empfangen und zu speichern; einen Direktzugriffspeicher-(RAM)-Abschnitt (106) des Systemspeichers, um temporär Daten zu empfangen und zu speichern, während des Betriebs der CPU (102); eine vorherbestimmte feste kommentierte automatische Spracherkennung-(ASR)-Corpusdatei (122), die im Systemspeicher gespeichert ist, die eine Aufzählung aller erwarteten gültigen Äußerungen in der bekannten Grammatik enthält und damit gespeichert Zeichendaten, die die Bedeutung einer jeden der aufgelisteten erwarteten gültigen Äußerungen darstellen; ein automatisches Spracherkennung-(ASR)-System (114, 116, 118), das mit der CPU (102) verbunden ist, um gesprochene Äußerungen zu detektieren, und um digitale Ausgabesignale zu erzeugen, die die detektieren gültigen Äußerungen anzeigen; eine vorherbestimmte feste verkäuferspezifische ASR-Grammatikdatei (112), die im Systemspeicher gespeichert ist, die mit dem ASR-System (114, 116, 118) verbunden ist und die Daten enthält, die alle gültigen Äußerungen darstellen, die durch das ASR-System (114, 116, 118) detektiert werden sollen, und zwar in einer Form, die mit dem ASR-System (114, 116, 118) kompatibel ist; und ein Laufzeit-Interpreter-Mittel (124), das mit der CPU (102) und mit der kommentierten ASR-Corpusdatei (122) verbunden ist, zur Identifizierung – wenn die CPU (102) die digitalen Ausgabesignale des ASR-Systems empfängt, die eine detektierte gültige Äußerung anzeigen – der Bedeutung der detektierten gültigen Äußerung, indem durch die Inhalte der kommentierten ASR-Corpusdatei (122) gesucht wird, und um die identifizierte Bedeutung als die Zeichendaten zurückzuführen.
Das System gemäß Anspruch 1, worin das Laufzeit-Interpreter-Mittel (124) weiterhin ein Mittel einschließt, um eine Vergleichsuche durch die kommentierte ASR-Corpusdatei (122) in Systemspeicher durchzuführen, um die Zeichendaten zu finden, die das Mittel in der detektierten gültigen Äußerung identifiziert.
Das System gemäß Anspruch 2, worin das Laufzeit-Interpreter-Mittel (124) weiterhin ein Mittel einschließt, um eine partielle Übereinstimmungssuche durch die Inhalte der kommentierten ASR-Corpusdatei (122) durchzuführen beim Versagen der Vergleichsuche, worin die partielle Suche eine partielle Übereinstimmung der detektierten gültigen Äußerung in der kommentierten ASR-Corpusdatei (122) sucht.
Das System gemäß Anspruch 3, worin das Laufzeit-Interpreter-Mittel (124) weiterhin ein variables Verarbeitungsmittel einschließt, um den nicht übereinstimmenden Abschnitt der detektierten gültigen Äußerung als eine Variable zu verarbeiten, um die Bedeutung des nicht übereinstimmenden Abschnitts zu identifizieren.
Das System gemäß Anspruch 4, worin das variable Verarbeitungsmittel variable Daten erzeugt, die die Bedeutung des nicht übereinstimmenden Abschnitts der detektierten gültigen Äußerung darstellen.
Das System nach einem oder mehreren der Ansprüche 1–5, das weiterhin ein Laufzeit-Interpreter-Anwendungsprogramm-Schnittstellen-(RIAPI)-Mittel (128) umfasst, das mit dem Laufzeit-Interpreter-Mittel (124) verbunden ist, um auf das Laufzeit-Interpreter-Mittel (124) zuzugreifen.
Das System gemäß Anspruch 6, worin das RIAPI-Mittel (128) weiterhin eine kundenspezifische Prozessor-(CP)-Schnittstelle (126) umfasst, die mit dem RIAPI-Mittel (128) und dem Laufzeit-Interpreter-Mittel (124) verbunden ist, und ein inter aktives auf Sprache reagierendes (IVR)-System (130) umfasst, das durch das RIAPI-Mittel (128) verwendet wird, um auf das Laufzeit-Interpreter-Mittel (124) zuzugreifen.
Das System gemäß Anspruch 7, worin das IVR-System (130) mit dem ASR-System (114, 116, 118) und dem Laufzeit-Interpreter-Mittel (124) verbunden ist, um die kommentierte ASR-Corpusdatei (122) zu durchsuchen, um die Zeichendaten zu finden, die die Bedeutung der detektierten gesprochenen Äußerung darstellen.
Das System nach einem oder mehreren der Ansprüche 1–8, worin das Computersystem ein Netzwerksystem mit einer Vielzahl von Laufzeit-Interpreter-Mittel (508a...508n) umfasst, die auf eine Vielzahl von Computern im Computersystemnetzwerk verteilt sind.
Ein Verfahren zur Identifizierung der Bedeutung in einer gültigen gesprochenen Äußerung in einer bekannten Grammatik, das die folgenden Schritte umfasst: das Laden einer vorherbestimmten festen kommentierten automatischen Spracherkennung-(ASR)-Corpusdatei (122) in einen Systemspeicher eines Computers, worin die feste kommentierte ASR-Corpusdatei (122) eine Auflistung aller erwarteten gültigen Äußerungen in der festen Grammatik und Zeichendaten enthält, die die Bedeutung einer jeden der aufgelisteten erwarteten gültigen Äußerungen darstellen; das Laden einer vorherbestimmten festen verkäuferspezifischen (ASR)-Grammatikdatei (112) in den Systemspeicher, die Daten enthält, die alle gültige Äußerungen darstellen, die durch ein (ASR)-System (114, 116, 118) in einer Form zu detektieren sind, die mit dem ASR-System (114-116, 118) kompatibel ist; das Detektieren einer gültigen Äußerung durch das automatische Spracherkennung-(ASR)-System (114, 116, 118); das Initialisieren einer Anforderung zur Suche in der festen kommentierten ASR-Corpusdatei (122) nach dem Auftreten der detektierten gültigen Äußerung; das Durchführen einer Suche mittels eines Laufzeit-Inter preter-Mittels (124) durch die Inhalte der festen kommentierten ASR-Corpusdatei (122), die im Systemspeicher geladen sind, um eine gültige Äußerung unter den aufgelisteten erwarteten gültigen Äußerungen zu finden, die der detektierten gültigen Äußerung entsprechen, und das Identifizieren der Bedeutung in der detektierten gültigen Äußerung als die Zeichendaten, die mit der gefundenen gültigen Äußerung verknüpft sind; und das Zurückgeben der Zeichendaten, die der Bedeutung in der detektierten gültigen Äußerung in der festen kommentierten ASR-Corpusdatei (122) entsprechen, an den Anforderer.