-
Hintergrund der Erfindung
-
Gebiet der Erfindung
-
Die
Erfindung bezieht sich auf Techniken zur Bereitstellung eines verteilten
multimodalen Dialogsystems, in welchem multimodale Kommunikations- und/oder
Dialogtypen in einen Dialogprozess oder in mehrere parallele Dialogprozesse
wie gewünscht
integriert werden können.
-
Diskussion
des Standes der Technik
-
Voice
Extensible Markup Language oder Voice-XML ist ein Standard, der
vom World Wide Web-Komitee (W3C) gesetzt wurde und es Nutzern erlaubt
mit dem Web über
Spracherkennungsanwendungen zusammenzuwirken. Durch Verwendung von Voice-XML kann ein Nutzer
das Web oder die Anwendung durch Sprechen bestimmter Befehle über einen
Sprach-Browser oder einen Telefonanschluss aufrufen. Der Nutzer
wirkt mit dem Web oder der Anwendung durch Eingabe von Befehlen
oder Daten zusammen unter Verwendung der natürlichen Stimme des Nutzers.
Die Interaktion oder der Dialog zwischen dem Nutzer und dem System
erfolgt über
einen Einkanal-Sprachkanal. Eine der Annahmen, denen solche Voice-XML-basierten
Systeme unterliegen ist, dass eine Verbindung zwischen einem Nutzer und
dem System über
einen Telefonanschluss einem Einzelmodalitätskommunikationsmodell folgt,
bei dem Ereignisse oder Übertragungen
zeitlich aufeinander folgend auftreten wie in einem rationalisierten synchronisierten
Prozess.
-
Konventionelle
Voice-XML-Systeme, die das Einzelmodalitätskommunikationsmodell nutzen
sind jedoch nicht für
multimodale Interaktionen geeignet, bei denen mehrere Kommunikationsprozesse über verschiedene Übertragungsarten
(Modalitätskanäle) wie Sprache,
Email, Fax, Web-Formular usw. auftreten müssen. Genauer gesagt ist das
Einzelmodalitätskommunikationsmodell
der konventionellen Voice-XML-Systeme nicht länger angemessen zur Verwendung
bei einer multimodalen Interaktion, weil es einem rationalisierten
synchronen Kommunikationsmodell folgt.
-
In
einem multimodalen Interaktionssystem sind die folgenden vier Hierarchielevels
verschiedener Arten multimodaler Interaktionen, die nicht durch eine
einzelne rationalisierte Modalitätskommunikation
gemäß dem Stand
der Technik bereitgestellt werden können, gewünscht:
(Level 1) Sequentielle
multimodale Interaktion: Obwohl das System mehrere Modalitäten oder
Arten der Übertragung
erlaubt, ist zu jedem Zeitpunkt nur eine Modalität aktiv, und zwei oder mehr
Modalitäten
sind nie gleichzeitig aktiv.
(Level 2) Unkoordinierte simultane
multimodale Interaktion: Das System erlaubt eine gleichzeitige Aktivierung
von mehr als einer Modalität.
Wenn jedoch eine Eingabe von mehr als einer Modalität bereitgestellt werden
muss, werden solche Eingaben nicht integriert sondern werden einzeln
in zufälliger
oder festgelegter Reihenfolge abgearbeitet.
(Level 3) Koordinierte
simultane multimodale Interaktion: Das System erlaubt eine gleichzeitige
Aktivierung von mehr als einer Modalität zur Integration und bildet
gemeinsame Abläufe
basierend auf Zeitstempel oder andere Prozesssynchronisationsinformationen,
um mehrere Eingaben von mehreren Modalitäten zu verbinden.
(Level
4) Gemeinschaftliche auf Informationsüberlagerung basierende multimodale
Interaktionen: Zusätzlich
zu oben genanntem Level 3 verwendet die durch das System bereitgestellte
Interaktion eine gemeinsam genutzte multimodale Umgebung (zum Beispiel
White-Board, gemeinsame
Webseite und Spielkonsole) zur multimodalen Zusammenarbeit, wodurch
ermöglicht
wird, gemeinschaftliche Interaktionen gemeinsam zu nutzen und übereinander
zu überlagern
mit der gemeinsam zusammenwirkenden Umgebung.
-
Jedes
höher in
der Hierarchie liegende Level stellt eine neue Herausforderung an
ein Dialogsystemdesign dar und entfernt sich weiter von der Einzelmodalitätsübertragung
eines existierenden Sprachmodells. Daher werden neue Ansätze benötigt, wenn
eine multimodale Übertragung
gewünscht ist,
zum Beispiel wenn eine Interaktion über mehrere Kommunikationsarten
gewünscht
ist.
-
Darstellung der Erfindung
-
Die
vorliegende Erfindung stellt ein Verfahren und ein System bereit,
um eine verteilte multimodale Interaktion bereitzustellen, welche
die oben genannten Probleme und Begrenzungen des Standes der Technik
bewältigen.
Das System der vorliegenden Erfindung ist ein Hybrid-Voice-XML-Dialogsystem
und umfasst eine Anwendungsschnittstelle, die eine multimodale Interaktionsanfrage
zur Durchführung
einer multimodalen Interaktion über
mindestens zwei unterschiedliche Modalitätskanäle empfängt; und mindestens ein Hybridkonstrukt,
der mit multimodalen Servern entsprechend den mehreren Modalitätskanälen kommuniziert,
um die multimodale Interaktionsanfrage auszuführen.
-
Vorteile
der vorliegenden Erfindung werden durch die nachfolgend gegebene
detaillierte Beschreibung ersichtlicher. Es sollte sich jedoch verstehen,
dass die detaillierte Beschreibung und die spezifischen Beispiele,
obwohl diese bevorzugte Ausführungsformen
der Erfindung zeigen, nur zur Veranschaulichung gegeben sind, da
verschiedene Änderungen
und Modifikationen im Sinne und im Umfang der Erfindung dem Fachmann
aus der detaillierten Beschreibung offensichtlich sind.
-
Kurze Beschreibung der
Zeichnung
-
Die
vorliegende Erfindung wird durch die nachfolgende detaillierte Beschreibung
und die beiliegenden Figuren, die nur zur Veranschaulichung gegeben
sind und somit die vorliegende Erfindung nicht einschränken, besser
verstanden.
-
1 zeigt
ein Funktionsblockschaltbild eines Systems zur Bereitstellung verteilter
multimodaler Übertragungen
gemäß einer
Ausführungsform
der vorliegenden Erfindung;
-
2 zeigt
ein detaillierteres Blockschaltbild eines Teils des Systems nach 1 gemäß einer Ausführungsform
der vorliegenden Erfindung; und
-
3 zeigt
ein Funktionsblockschaltbild eines Systems zur Bereitstellung verteilter
multimodaler Übertragungen
gemäß einer
Ausführungsform
der vorliegenden Erfindung, wobei dieses angepasst ist zur Integrierung
von Endzustandsdialog und natürlichem
Sprachdialog.
-
Detaillierte Beschreibung
der bevorzugten Ausführungsform
-
Die
Verwendung des Ausdrucks „Dialog" hierin ist nicht
auf Sprachdialog begrenzt sondern ist vorgesehen, einen Dialog oder
eine Interaktion zwischen mehreren Dateneinheiten abzudecken, unter Verwendung
beliebiger Modalitätskanäle, umfassend Sprache,
Email, Fax, Web-Formulare, Dokumente, Web-Chat usw. In den Figuren
werden gleiche Bezugszeichen zur Darstellung gleicher oder ähnlicher Teile
verwendet.
-
Im
Allgemeinen folgt ein verteiltes multimodales Dialogsystem gemäß der vorliegenden
Erfindung einer bekannten dreistufigen Client-Server-Architektur.
Die erste Lage des Systems ist die physische Betriebsmittelstufe
wie ein Telefonserver, Internetprotokoll (IP) Terminal usw. Die
zweite Lage des Systems ist die Anwendungsprogrammschnittstellenstufe
(API), welche alle physischen Betriebsmittel der ersten Stufe als
APIs umhüllt.
Diese APIs werden der dritten, Top-Level-Anwendungsstufe für Dialoganwendungen
ausgesetzt. Die vorliegende Erfindung richtet sich auf die oberste
Anwendungsebene durch Modifizierung derselben, um multimodale Interaktion zu
unterstützen.
Diese Anordnung erlaubt eine erweiterbare und flexible Umgebung
zur Anwendungsentwicklung, so dass jegliche neue Sachverhalte, gegenwärtige und
mögliche
zukünftige,
bearbeitet werden können,
ohne beträchtliche
Modifizierungen der existierenden Infrastruktur zu erfordern. Sie
stellt weiterhin gemeinsam nutzbare übergreifende Mehrfachplattformen
mit wieder verwendbaren und verteilten Komponenten bereit, die nicht
an spezifische Plattformen gebunden sind. In diesem Prozess kann Voice-XML,
obwohl nicht notwendigerweise, als Sprachmodalität genutzt werden, wenn Sprachdialog als
eine der mehreren eingebundenen Modalitäten eingebunden ist.
-
1 zeigt
ein Funktionsblockschaltbild eines Dialogsystems 100 zur
Bereitstellung verteilter multimodaler Übertragungen gemäß einer
Ausführungsform
der vorliegenden Erfindung. Wie in 1 gezeigt,
verwendet das Dialogsystem 100 Komponenten für multimodale
Interaktion, umfassend Hybrid-Voice-XML basierte Dialoganwendungen 10 zur Steuerung
multimodaler Interaktionen, einen Voice-XML-Interpreter 20,
Anwendungsprogrammschnittstellen (APIs) 60, Sprachtechnologie-Integrationsplattform
(Speech Technology Integration Plattform, STIP) Serverbetriebsmittel 62 und
eine Mitteilungswarteschlange 64 sowie einen Server wie
einen Hyper Text Transfer Protokoll (HTTP) Server 66. Die STIP
Serverbetriebsmittel 62, die Nachrichtenwarteschlange 64 und
das HTTP 66 empfangen Eingaben 68 von verschiedenen
Modalitäten,
wie Sprache, Dokumente, Emails, Faxe, Web-Formulare usw. Die Hybrid-Voice-XML
basierten Dialoganwendungen 10 sind multimodale Multimediadialoganwendungen, wie
multimodale Interaktion für
Direktionsassistenz, Kundenbeziehungsmanagement usw. und der Voice-XML-Interpreter 20 ist
ein Sprach-Browser wie er aus dem Stand der Technik bekannt ist. Voice-XML-Produkte wie das
Voice-XML 2.0 System (Interactive Voice Response 9.0) von Avaya
Inc. können
diese bekannten Komponenten bereitstellen.
-
Der
Betrieb jeder der Komponenten 20, 60, 62, 64 und 66 ist
aus dem Stand der Technik bekannt. Zum Beispiel werden die Betriebsmittel,
die zur Unterstützung
von Sprachdialoginteraktionen benötigt werden, in den STIP Serverbetriebsmitteln 62 bereitgestellt.
Solche Betriebsmittel umfassen, sind aber nicht darauf begrenzt,
mehrere Anschlüsse
automatischer Spracherkennung (automatic speak recognition, ASR),
Text-zu-Sprach-Maschine (text-to-speak-engine,
TTS) usw. Daher wird ein Sprachbefehl von einem Nutzer, wenn ein
Sprachdialog einbezogen ist, durch die STIP Serverbetriebsmittel 62 verarbeitet,
das heißt
in Textinformation gewandelt. Die verarbeitete Information wird
dann (unter der Dialoganwendungssteuerung und Verwaltung, die durch
die Dialoganwendung 10 bereitgestellt wird) durch die APIs 60 und
den Voice-XML-Interpreter 20 verarbeitet. Die Nachrichtenwarteschlange 64,
HTTP 66 und Sockel- oder andere Verbindungen werden verwendet,
um eine Schnittstellenübertragungsstufe
zu bilden, um mit externen Geräten
zu kommunizieren. Diese multimodalen Betriebsmittel werden durch
die APIs 60 der Anwendungsstufe des Systems (Plattform)
ausgesetzt, um mit dem Voice-XML-Interpreter 20 und den
multimodalen Hybrid-Voice-XML Dialoganwendungen 10 zu kommunizieren.
-
Wichtiger
ist, dass das Dialogsystem 100 weiterhin einen Webserver 30,
ein Hybridkonstrukt 40 und einen (oder mehrere) multimodale(n)
Server 50 umfasst. Der Hybridkonstrukt 40 ist
ein wichtiger Teil des Dialogsystems 100 und ermöglicht es,
dass die Plattform verteilte multimodale Betriebsmittel umfasst,
die sich nicht physisch auf der Plattform befinden. In einer anderen
Ausführungsform
können
mehrere Hybridkonstrukte 40 bereitgestellt sein, um Gruppen
von mehreren multimodalen Interaktionen entweder parallel oder aufeinander
folgend, wie gewünscht,
zu verarbeiten. Diese Komponenten des Systems 100, umfassend
den (die) Hybridkonstrukte 40, sind als Computersoftware
unter Verwendung bekannter Programmiersprachen implementiert.
-
2 zeigt
ein detaillierteres Blockschaltbild, welches den Hybridkonstrukt 40 zeigt.
Wie in 2 dargestellt, umfasst der Hybridkonstrukt 40 eine
Serverseite 42, die mit dem Webserver 30 zusammenwirkt,
eine Vielzahl Synchronisationsmodule 44 und eine Vielzahl
von Dialogagenten (DAs) 46, die mit einer Vielzahl von
multimodalen Servern 50 kommunizieren. Die Serverseite 42 kann
eine bekannte Serverseite wie eine aktive Serverseite (active server page;
ASP) oder Java Serverseite (java server page; JSP) sein. Die Synchronisierungsmodule 44 können bekannte
Nachrichtenwarteschlangen (zum Beispiel Synchronisationsfäden (sync
threads) usw.), verwendet für
Synchronisation asynchroner Art wie für Email-Verarbeitung, oder
können
Funktionsaufrufe sein, die für
Synchronisation nicht asynchroner Art bekannt sind, wie zur Sprachverarbeitung.
-
Die
multimodalen Server 50 umfassen Server, die geeignet sind
zur Kommunikation über
unterschiedliche Arten der Kommunikation (Modalitätskanäle). Die
multimodalen Server 50 können umfassen, sind aber nicht
darauf begrenzt, eine oder mehrere Email-Server, ein oder mehrere Fax-Server,
ein oder mehrere Web-Formularserver, einen oder mehrere Stimmserver
usw. Die Synchronisierungsmodule 44 und die DAs 46 sind
bestimmt, um mit den Multimodalservern 50 zu kommunizieren,
so dass die Serverseite 42 Informationen dazu hat, welches
Synchronisierungsmodul und/oder DA verwendet werden sollte, um bei
einer bestimmten Art des Multimodalservers 50 anzukommen.
Die Serverseite 42 speichert diese Information vor und/oder
weist diese Information vorab zu.
-
Das
Dialogsystem 100 wird wie folgt betrieben.
-
Das
System 100 kann verschiedene multiple modale Kommunikationsanfragen
entweder gleichzeitig oder aufeinander folgend in zufälliger oder
aufeinanderfolgender Meise, wie gewünscht empfangen und verarbeiten.
Das System 100 kann zum Beispiel modale Interaktion durchführen unter
gleichzeitiger Verwendung dreier Modalitäten (drei Modalitätskanäle)-Stimmkanal,
Email-Kanal und Web-Kanal. In diesem Fall kann ein Nutzer die Stimme
(Stimmkanal) zur Aktivierung anderer Modalitätsübertragungen wie Email und
Web-Kanal nutzen, so dass der Nutzer Dialoghandlungen über die
drei (Stimme, Email und Web) Modalitätskanäle in paralleler, aufeinanderfolgender
oder zusammenwirkender Ablaufart beginnen kann.
-
Das
System 100 kann ebenfalls Kreuzkanal-, Multimedia multimodale
Interaktion ermöglichen. Zum
Beispiel kann eine Stimminteraktionsantwort, die den Stimmkanal
nutzt, in Text umgewandelt werden, durch Verwendung bekannter automatischer Spracherkennungstechniken
(zum Beispiel über
den ASR des STIP Serverbetriebsmittel 62) und kann an einen
Web- oder Email-Kanal über
den Webserver 30 für
eine Web/Email-Kanalinteraktion übertragen werden.
Die Web/Email-Kanalinteraktion kann auch leicht durch Verwendung
des TTS der STIP Serverbetriebsmittel 62 für die Stimmkanalinteraktion
in Stimme konvertiert werden. Diese multimodalen Interaktionen,
umfassend die Kreuzkanal- und Nicht-Kreuzkanalinteraktion können gleichzeitig
oder auf andere Art wie vom Nutzer angefordert, oder entsprechend
voreingestellter Kriterien auftreten.
-
Obwohl
ein Stimmkanal einer der Hauptmodalitätskanäle ist, die oft durch Endnutzer
verwendet werden, ist auch multimodale Interaktion möglich, die die
Verwendung des Stimmkanals nicht einschließt. In solch einem Fall benötigt das
System 100 die Verwendung des Stimmkanales und der den
Stimmkanal zugeordneten STIP Serverbetriebsmittel 62 nicht
und der Hybridkonstrukt 40 kommuniziert direkt mit den APIs 60.
-
Beim
Betrieb des Systems 100 gemäß einem Anwendungsbeispiel,
sobald das System 100 eine Vielzahl verschiedener Modalitätsübertragungsanfragen
entweder gleichzeitig oder auf andere Art empfängt, werden diese durch ein
oder mehrere der STIP Serverbetriebsmittel 62, Nachrichtenwarteschlangen 64,
HTTP 66, APIs 60 und Voice-XML Interpreter 20 verarbeitet
und die multimodalen Dialoganwendungen 10 werden gestartet,
um die Multimodalinteraktionen zu steuern. Wenn eine der Modalitäten dieser Interaktion
Stimme einschließt
(Stimmkanal), dann werden die STIP Serverbetriebsmittel 62 und
der Voice-XML-Interpreter 20 durch Steuerung der Dialoganwendung 10 zusätzlich zu
den anderen Komponenten, wie benötigt,
verwendet. Auf der anderen Seite, wenn keine der Modalitäten dieser
Interaktion Stimme einschließt,
werden die Komponenten 20 und 62 nicht benötigt.
-
Die
multimodalen Dialoganwendungen 10 können Interaktionsanfragen zum
Hybridkonstrukt 40 entweder über die Voice-XML-Interpreter 20 oder durch
den Web-Server 30 (zum Beispiel wenn der Stimmkanal nicht
verwendet wird) übertragen.
Dann wird die Serverseite 42 des Hybridkonstrukts 40 aktiviert,
so dass es diese Anfragen in „Nachrichten" formatiert oder
packt, die durch die angefragten Multimodalserver 50 verarbeitet
werden. Eine „Nachricht" hier ist ein speziell
formatiertes informationstragendes Datenpaket und das Formatieren/Packen
der Anfrage umfasst das Einbetten der entsprechenden Anfrage in
ein spezielles Datenpaket. Die Serverseite 42 sendet diese
Nachrichten dann gleichzeitig an die entsprechenden Synchronisationsmodule 44,
abhängig
von der Information, die anzeigt, welches Synchronisationsmodul 44 bestimmt
ist, einen bestimmten Modalitätskanal
zu bedienen. Dann können
die Synchronisationsmodule 44 zeitweilig die Nachrichten
speichern und die Nachrichten an die entsprechenden DAs 46 senden
wenn diese bereit sind.
-
Wenn
jedes der korrespondierenden DAs 46 die entsprechende Nachricht
empfängt,
entpackt es die Nachricht, um auf die Anfrage zuzugreifen, übersetzt
die Anfrage in ein vorbestimmtes geeignetes Format, das durch den
korrespondierenden Multimodalserver 50 erkennbar ist und
sendet die Anfrage in dem geeigneten Format an den entsprechenden
Server 50 zur Interaktion. Dann empfängt jeder der korrespondierenden
Server 50 die Anfrage und erzeugt eine Antwort auf die
Anfrage. Nur als Beispiel, wenn ein Nutzer vom System mündlich verlangt,
eine Liste der empfangenen Emails zu einem bestimmten Thema zu erhalten,
generiert der Multimodalserver 50, der ein Email-Server
ist, eine Liste der empfangen Emails über das angefragte Thema als
Antwort.
-
Jedes
der korrespondierenden DAs 46 empfängt die Antwort von dem korrespondierenden
Multimodalserver 50 und wandelt die Antwort in eine XML-Seite
unter Verwendung bekannter Techniken zur Erzeugung von XML-Seiten
um. Dann übermittelt jedes
der korrespondierenden DAs 46 die XML-Seite mit Kanalidentifikations
(ID)-Informationen an die Serverseite 42 über die
entsprechenden Nachrichtenwarteschlangen 44. Die Kanal-ID-Information identifiziert
den Kanaltyp oder Modalitätstyp,
der in dem entsprechenden DA 46 verarbeitet wird. Die Kanal-ID-Information
identifiziert eine Kanal-ID jeder Modalität, welche jedem DA zugeordnet
ist, wie die Serverseitenbetriebsmittel. Sie identifiziert auch
den Modalitätstyp,
zu welchem der DA zugeordnet ist. Der Modalitätstyp kann vorweg bestimmt
sein und die Kanal ID-Nummerierung kann entweder vorab zugeordnet
sein oder dynamisch sein, solange die Serverseite 42 einen
aktuellen Satz der Kanal ID-Information
bereithält.
-
Die
Serverseite 42 empfängt
alle zurückgesandten
Informationen als Antwort auf die multimodale Interaktion von allen
zugeordneten DAs 46. Diese Teile der Interaktionsantwortinformation,
welche im Format von XML-Seiten dargestellt werden können, werden
mit der Kanal-ID-Information und der Art der Modalität zu der
diese gehört
empfangen. Die Serverseite 42 integriert oder kompiliert
dann alle empfangenen Interaktionsantworten in eine gemeinsame Antwort
oder ein gemeinsames Ereignis, welches auch die Form einer gemeinsamen
XML-Seite haben kann. Dies kann erreicht werden, indem Serverseiten-Skripterstellung
oder -Programmierung verwendet wird, um die von den mehreren DAs 46 empfangene
Information zu verbinden und zu filtern, oder durch Integration
dieser Antworten, um ein gemeinsames multimodales Interaktionsereignis,
basierend auf mehrere Eingaben von den verschiedenen Multimodalservern 50,
zu bilden. Gemäß einer anderen
Ausführungsform
kann das gemeinsame Ereignis im Voice-XML-Interpreter 20 gebildet
werden.
-
Die
verbundene Antwort wird dann an den Nutzer oder eine andere ausgewählte Vorrichtung entsprechend
der Anfrage des Nutzers durch bekannte Techniken, zum Beispiel über die
APIs 60, Nachrichtenwarteschlangen, HTTP 66, Server
des Clients usw., übermittelt
werden.
-
Die
Serverseite 42 kommuniziert auch mit den Dialoganwendungen 10 (zum
Beispiel über
den Webserver 30) um neue Anweisungen für eine nachfolgende Interaktion,
die die Antwort begleiten kann, zu generieren. Wenn die nachfolgende
Interaktion den Stimmkanal einschließt, generiert die Serverseite 42 eine
neue Voice-XML-Seite und macht diese dem Voice-XML-Interpreter 20 durch
den Webserver 30 zugänglich,
in welchem die gewünschte
Interaktion durch den Stimmkanal geeignet beschrieben ist, durch
Verwendung der entsprechenden Voice-XML-Sprache. Der Voice-XML-Interpreter 20 interpretiert
die neue Voice-XML-Seite und instruiert die Plattform, die gewünschte Stimmkanalinteraktion auszuführen. Wenn
die folgende Interaktion den Stimmkanal nicht umfasst, wird diese
durch andere Komponenten verarbeitet, wie die Nachrichtenwarteschlange 64 und
das HTTP 66.
-
Wegen
des spezifischen Layouts des Systems 100 oder 100a ist
eine der wichtigen Merkmale des Hybridkonstrukts 40, dass
dieses als ein verteiltes Multimodalinteraktionsbetriebsmittel ausgelegt sein
kann und nicht an eine spezifische Plattform gebunden ist. Sobald
es einmal konstruiert ist, kann es zentral gespeichert werden und
gemeinsam von verschiedenen Prozessen oder unterschiedlichen Plattformen
genutzt werden.
-
Nur
als Beispiel, ist nachfolgend eine Anwendung des Systems 100 beschrieben,
um eine Email-Verwaltung durchzuführen, wenn zwei Modalitätskanäle verwendet
werden. In diesem Beispiel sind die zwei Modalitätskanäle Stimme und Email. Wenn ein
Nutzer einen Stimmbefehl spricht, wie „Bitte öffne und lies meine Email", in eine bekannte
Client-Einrichtung,
wird diese Anfrage vom Stimmkanal am Anwendungs-API 60 verarbeitet,
welcher im Gegenzug diese Anfrage an den Voice-XML-Interpreter 20 übermittelt.
Der Voice-XML-Interpreter 20 unter Steuerung der Dialoganwendungen 10 erkennt
dann, dass die vorliegende Anfrage das Öffnen eines zweiten Modalitätskanals
(Email-Kanal) umfasst und übermittelt
die Email-Kanalanfrage an den Webserver 30.
-
Die
Serverseite 42 wird dann aktiviert und packt die Anfrage
mit zugehörigen
Informationen (zum Beispiel Email-Account-Name usw.) in eine Nachricht
und sendet die Nachricht über
das Synchronisationsmodul 44 zu einem ihrer Email-Kanal DAs 46 um
diese auszuführen.
Der Email-Kanal DA 46 wirkt mit dem entsprechenden Email-Server 50 zusammen
und greift auf den angeforderten Email-Inhalt des Email-Servers 50 zu.
Wenn der Email-Inhalt durch den Email-Kanal DA 46 entnommen
worden ist, als Ergebnis der Email-Kanalinteraktion, wird der entnommene
Email-Inhalt an die Serverseite 42 durch das Synchronisationsmodul 44 übermittelt.
Die Serverseite 42 generiert im Gegenzug eine Voice-XML-Seite,
welche den Email-Inhalt und auch die Anweisungen an den Voice-XML-Interpreter 20,
wie der Email-Inhalt durch den Stimmkanal zu lesen ist, als eine
nachfolgende Stimmkanalinteraktion enthält. Es ist offensichtlich,
dass dieses Beispiel modifiziert oder erweitert werden kann, um Kreuzkanalmultimodalinteraktion
bereitzustellen. In solch einem Fall stellt die Serverseite 42,
anstelle Instruktionen an den Voice-XML-Interpreter 20, wie der Email-Inhalt
durch den Stimmkanal zu lesen ist, bereitzustellen, Anweisungen
bereit, eine Email an die vorbestimmte Email-Adresse zu senden,
welche den entnommenen Email-Inhalt trägt. Entsprechend können bei
Verwendung einer einzelnen Modalität (Stimmkanal in diesem Beispiel)
mehrere Modalitätskanäle aktiviert
und verwendet werden, um multimodale Interaktionen unterschiedlicher
Typen durchzuführen.
-
3 zeigt
ein Diagramm eines Dialogsystems 100a welches dem Dialogsystem 100 nach 1 entspricht
das angewendet wurde, um natürlichen
Sprachdialog und Endzustandsdialog als zwei Modalitäten gemäß einer
Ausführungsform
der vorliegenden Erfindung zu integrieren. Natürlicher Sprachdialog und Endzustandsdialog
sind zwei unterschiedliche Arten von Dialog. Existierende Voice-XML-Programme
sind so konfiguriert, dass diese nur den Endzustandsdialog unterstützen. Endzustandsdialog
ist ein begrenzter computererkennbarer Dialog, der bestimmten grammatikalischen
Sequenzen oder Regeln folgen muss, damit der Computer diesen erkennt.
Auf der anderen Seite ist natürlicher
Sprachdialog ein auf natürlicher
Weise jeden Tag gesprochener Dialog durch einen Nutzer. Es wird ein
komplexeres Computersystem und Programm benötigt, damit Maschinen den natürlichen
Sprachdialog erkennen.
-
Gemäß 3 enthält das System 100a Komponenten
des Systems 100 wie durch die gleichen Bezugszeichen gekennzeichnet
und diese Komponenten werden daher nicht detailliert diskutiert.
-
Das
System 100a kann nicht nur mehrere unterschiedliche physische
Modalitäten
integrieren sondern kann auch unterschiedliche Interaktionen oder
Prozesse als spezielle Modalitäten
in einer gemeinsamen multimodalen Dialoginteraktion integrieren.
In dieser Ausführungsform
werden zwei Arten von Stimmdialog (das heißt Endzustandsdialog wie in
Voice-XML definiert und natürlicher
Sprachdialog, welcher nicht in Voice-XML definiert ist) als zwei
unterschiedliche Modalitäten
behandelt. Die Interaktion erfolgt über den Stimmkanal, ist aber
eine Mischung aus zwei unterschiedlichen Typen (oder Arten) von Dialog.
Wenn der natürliche
Sprachdialog aufgerufen wird (zum Beispiel durch mündliche
Kommunikation des Nutzers), erkennt das System 100a dass
ein zweiter Modalitätskanal
(natürlicher
Sprachdialog) aktiviert werden muss. Diese Anfrage wird für den natürlichen
Sprachdialog an den Webserver 30 über den Voice-XML-Interpreter 20 über den
gleichen Kanal übermittelt,
der auch für
den Endzustandsdialog verwendet wird.
-
Die
Serverseite 42 eines Hybridkonstrukts 40a packt
die Anfrage und sendet diese als Nachricht an einen Aufrufleitwerks-DA
für natürliche Sprache (natural
language call routing; NLCR DA) 46a. Ein NLCR-Dialogserver 50a empfängt eine
Antwort von dem bezeichneten NLCR DA 46a mit nachfolgenden Interaktionsanweisungen.
Danach wird eine neue Voice-XML-Seite erzeugt, die den Voice-XML-Interpreter 20 anweist,
gemäß dem NLCR
DA 46a zu interagieren. Wenn dieser Prozess fortschreitet,
wird die Dialogsteuerung vom Voice-XML zum NLCR DA 46a verlagert.
Derselbe Sprachkanal und derselbe Voice-XML-Interpreter 20 werden
verwendet, um sowohl natürliche
Sprachdialog- und Endzustandsdialog-Interaktionen bereitzustellen.
Jedoch hat sich die Rolle geändert
und der Interpreter 20 arbeitet als abhängiger Prozess (slave process),
der gesteuert und abgewickelt wird durch den NLCR DA 46a.
Bei einer ähnlichen
Ausgestaltung umfasst derselbe Ansatz, angewendet auf andere allgemeine
Fälle,
mehrere Modalitäten
und mehrere Prozesse.
-
Als
ein Anwendungsbeispiel können <object>tag-Erweiterungen verwendet
werden, um dem Voice-XML-Interpreter 20 zu ermöglichen,
die natürlich
gesprochene Sprache zu erkennen. Die <object>tag-Erweiterungen sind bekannte Werkzeuge zur
Voice-XML-Programmierung,
die verwendet werden können,
um neue Plattformfunktionen zu einem existierenden Voice-XML-System
hinzuzufügen.
-
Das
System 100a kann so konfiguriert werden, dass die Endzustandsdialoginteraktion
Standard ist zur alternativen Interaktion mit natürlichem Sprachdialog.
In diesem Fall würde
das System zuerst automatisch den Endzustandsdialoginteraktionsmodus
einstellen, bis es feststellt, dass der empfangene Dialog natürlichem
Sprachdialog entspricht und die Aktivierung des natürlichen
Sprachdialoginteraktionsmodusses erfordert.
-
Es
sollte festgehalten werden, dass das System 100a auch in
das Dialogsystem 100 nach 1 integriert
werden kann, so dass die natürliche Sprachdialoginteraktion
eine von vielen möglichen multimodalen
Interaktionen durch das System 100 sein kann. Zum Beispiel
kann der NLCR DA 46a einer der DAs 46 im System 100 sein
und der NLCR Dialogserver 50a kann einer der Multimodalserver 50 im
System 100 sein. Es können
andere Modifikationen durchgeführt
werden, um diese Konfiguration bereitzustellen.
-
Die
Komponenten des in den 1 und 3 gezeigten
Dialogsystems können
sich alle auf der Seite eines Clients oder alle auf der Seite eines Servers
befinden oder auf die Seiten des Servers oder Clients verteilt sein.
Weiterhin können
diese Komponenten mit jeder anderen kommunizieren und/oder mit anderen
Geräten über bekannte
Netze wie Internet, Intranet, Extranet, verkabelte Netzwerke, drahtlose
Netzwerke usw. und über
jede Kombination der bekannten Netzwerke kommunizieren.
-
Die
vorliegende Erfindung kann unter Verwendung jeder bekannten Hardware
und/oder Software implementiert werden. Solche Software kann auf
jedem computerlesbaren Medium enthalten sein. Jede bekannte Computerprogrammiersprache
kann verwendet werden, um die vorliegende Erfindung zu implementieren.
-
Es
ist nahe liegend, dass die so beschriebene Erfindung auf viele verschiedene
Arten variiert werden kann. Solche Variationen werden nicht als entfernt
liegend vom Sinn und Inhalt der Erfindung betrachtet und all solche
Modifikationen, die dem Fachmann nahe liegend sind, sollen im Umfang
der folgenden Ansprüche
enthalten sein.
-
Zusammenfassung
-
Es
werden ein System und ein Verfahren bereitgestellt, um verteilte
multimodale Interaktionen bereitzustellen. Das System ist ein Hybridmultimodaldialogsystem,
das ein oder mehrere Hybridkonstrukte umfasst, um aufeinanderfolgende
und gemeinsame Ereignisse in multimodaler Interaktion zu bilden.
Es umfasst eine Anwendungsschnittstelle, die eine multimodale Interaktionsanfrage
empfängt,
um eine multimodale Interaktion über
mindestens zwei unterschiedliche Modalitätskanäle durchzuführen; und mindestens einen
Hybridkonstrukt, der mit Multimodalservern entsprechend den mehreren
Modalitätskanälen kommuniziert,
um die multimodale Interaktionsanfrage auszuführen.
(1)