DE69937962T2

DE69937962T2 - Vorrichtung und verfahren zur bereitstellung von netzwerk-koordinierten konversationsdiensten

Info

Publication number: DE69937962T2
Application number: DE69937962T
Authority: DE
Inventors: Stephane H. Danbury MAES; Ponani Yorktown Heights Gopalakrishnan
Original assignee: International Business Machines Corp
Current assignee: Nuance Communications Inc
Priority date: 1998-10-02
Filing date: 1999-10-01
Publication date: 2008-12-24
Anticipated expiration: 2019-10-02
Also published as: CA2345665C; EP1163576A2; WO2000021075A1; CN1171200C; WO2000021232A3; IL142364A0; EP1133734A2; CA2345661A1; IL142366A; EP1163576A4; US7137126B1; EP1125279A1; WO2000021075A9; IL140805A0; CN1321296A; CN1160700C; WO2000020962A2; KR20020004931A; EP1125279B1; KR100431972B1

Description

HINTERGRUND
1. Technisches Gebiet
Die vorliegende Anmeldung betrifft im Allgemeinen Konversationssysteme und insbesondere ein System und ein Verfahren zur automatischen und koordinierten gemeinsamen Nutzung von Konversationsfunktionen/-ressourcen zwischen Einheiten, Servern und Anwendungen, die mit einem Netzwerk verbunden sind.
2. Beschreibung der verwandten Technik
Herkömmliche Konversationssysteme (d. h. Systeme mit reiner Spracheingabe/-ausgabe oder Mehrmodensysteme mit Spracheingabe/-ausgabe) sind typischerweise auf Personal Computer (PCs) und lokale Rechner, die eine geeignete Architektur und eine ausreichende Verarbeitungsleistung besitzen, beschränkt. Für Telefonanwendungen sind Konversationssysteme dagegen typischerweise bei einem Server (z. B. der IVR-Server) angeordnet, und auf sie kann über herkömmliche oder Zellentelefone zugegriffen werden. Obwohl derartige herkömmliche Systeme immer populärer werden, wird typischerweise die gesamte herkömmliche Verarbeitung entweder beim Client oder beim Server ausgeführt (d. h., alle Konfigurationen erfolgen entweder vollständig lokal oder vollständig beim Client/Server). Ein Beispiel ist im Dokument EP-A-450 610 angegeben.
Angesichts der mittlerweile weltweit verbreiteten Datenverarbeitung wird erwartet, dass Milliarden von Client-Einheiten mit geringen Ressourcen (z. B. PDAs, Smartphones usw.) untereinander vernetzt werden. Infolge der abnehmenden Größe dieser Client-Einheiten und der zunehmenden Komplexität ihrer Aufgaben, deren Ausführung der Benutzer von diesen Einheiten erwartet, wird die Benutzerschnittstelle (UI) ein kritisches Problem, da herkömmliche grafische Benutzeroberflächen (GUI) bei derartigen kleinen Client-Einheiten nicht möglich wären. Aus diesem Grund wird erwartet, dass Konversationssysteme das wesentliche Element der Benutzerschnittstelle sein werden, um reine Sprach-/Audiosignal-Eingabe/Ausgabeeinheiten oder Mehrmoden-Eingabe-/Ausgabeeinheiten mit Sprach-/Audiosignal-Eingaben/Ausgaben zu schaffen.
Demzufolge werden Konversationsanwendungen mit eingebetteter Sprachverarbeitung in tragbaren Client-Einheiten entwickelt und erreichen Serienreife. Wegen eingeschränkter Ressourcen ist leider zu erwarten, dass derartige Client-Einheiten keine komplexen Konversationsdienste wie z. B. Spracherkennung (insbesondere dann, wenn die Wortschatzgröße umfangreich oder spezialisiert ist oder domänenspezifische/anwendungsspezifische Sprachmodelle oder Grammatik benötigt werden), NLU (Verstehen natürlicher Sprache), NLG (Erzeugen natürlicher Sprache), TTS (Text-zu-Sprache-Synthese), Audioerfassungs- und Kompression-/Dekompression, Wiedergabe, Dialogerzeugung, Dialogverwaltung, Sprechererkennung, Themengebiet-Erkennung, Audio-/Multimedia- Indexierung und Suche usw. ausführen können. Die Einschränkungen bei Speicher und CPU (und anderen Ressourcen) einer Einheit können die Konversationsmöglichkeiten, die diese Einheit bieten kann, begrenzen.
Selbst wenn eine vernetzte Einheit in ausreichendem Maße "leistungsfähig" ist (in Bezug auf CPU und Speicher), um sämtliche Konversationsaufgaben auszuführen, kann die Einheit darüber hinaus nicht die geeigneten Konversationsressourcen (z. B. Maschinen) oder Konversationsargumente (d. h. die Dateien, die von den Maschinen verwendet werden) (wie etwa Grammatikdateien, Sprachmodelle, Vokabulardateien, Analysedateien, Kennzeichnungen, Stimmenausdrucke, TTS-Regeln usw.) haben, um die geeignete Aufgabe auszuführen. Stattdessen können einige Konversationsfunktionen für einen bestimmten Dienst zu spezifisch und eigen sein, wodurch sie nachgeordnete Informationen erfordern, die nur von anderen Einheiten oder Maschinen im Netzwerk zur Verfügung stehen. NLU- und NLG-Dienste bei einer Client-Einheit erfordern z. B. typischerweise eine serverseitige Unterstützung, da die vollständige Gruppe von Konversationsargumenten oder Funktionen, die zum Erzeugen des Dialogs benötigt werden (z. B. Parser, Kennzeichnungseinrichtung, Übersetzer usw.), entweder einen großen Speicherumfang zum Speichern (steht in den Client-Einheiten nicht zur Verfügung) erfordern oder zu teuer sind (in Bezug auf Kommunikationsbandbreite) für eine Übertragung zur Client-Seite. Dieses Problem wird bei mehrspracheigen Anwendungen noch weiter verstärkt, wenn eine Client-Einheit oder eine lokale Anwendung einen unzureichenden Speicher oder eine unzureichende Verarbeitungsleistung hat, um die Argumente zu speichern und zu verarbeiten, die zum Verarbeiten von Sprache und zum Ausführen von Konversationsfunktionen in mehreren Sprachen benötigt werden. Der Benutzer muss sich stattdessen mit einem entfernten Server verbinden, um derartige Aufgaben auszuführen.
Außerdem erfordern die Probleme, die mit einer verteilten Architektur und einer verteilten Verarbeitung zwischen Client und Servern verbunden sind, neue Verfahren für eine Konversationsvernetzung. Derartige Verfahren umfassen die Verwaltung von Verkehr und Ressourcen, die über das Netzwerk verteilt sind, um einen geeigneten Dialogfluss für alle Benutzer, die an einer Konversationswechselwirkung über das Netzwerk beteiligt sind, zu gewährleisten.
Demzufolge sind ein System und ein Verfahren höchst erwünscht, die ermöglichen, dass eine Netzwerkeinheit mit eingeschränkten Ressourcen komplexe spezifische Konversationsaufgaben unter Verwendung von vernetzten Ressourcen in einer Weise automatisch ausführt, die für einen Benutzer automatisch und transparent ist.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung betrifft ein System und ein Verfahren zum Bereitstellen einer automatischen und koordinierten gemeinsamen Nutzung von Konversationsressourcen zwischen Servern, die mit einem Netzwerk verbunden sind, und Einheiten (und ihren entsprechenden Anwendungen). Ein System gemäß einer Ausführungsform der vorliegenden Erfindung umfasst eine Vielzahl von vernetzten Servern, Einheiten und/oder Anwendungen, die durch den Austausch von Nachrichten unter Verwendung von Konversationsnetzwerkprotokollen (oder Verfahren), die es jeder auf Konversation ausgerichteten Netzwerkeinheit ermöglichen, Konversationsressourcen automatisch sowie koordiniert und synchron gemeinsam zu nutzen, um eine nahtlose Konversationsschnittstelle durch eine Schnittstelle einer der Netzwerkeinheiten zu schaffen, gegenseitig "auf Konversation ausgerichtet" werden. Die Erfindung ist in den Ansprüchen 1, 12, 13 und 19 dargestellt.
Gemäß einem Aspekt der vorliegenden Erfindung umfasst ein System zum Bereitstellen einer automatischen und koordinierten gemeinsamen Nutzung von Konversationsressourcen:
ein Netzwerk, das wenigstens eine erste Netzwerkeinheit und eine zweite Netzwerkeinheit umfasst;
wobei die erste Netzwerkeinheit und die zweite Netzwerkeinheit jeweils Folgendes umfassen:
eine Gruppe von Konversationsressourcen;
einen Dialogmanager für das Verwalten einer Konversation und zum Ausführen von Anrufen, die einen Konversationsdienst anfordern; und
ein Kommunikationspaket zum Übermitteln von Nachrichten unter Verwendung von Konversationsprotokollen über das Netzwerk, wobei die durch die Konversationsprotokolle übermittelten Nachrichten eine koordinierte Netzwerkkommunikation zwischen den Dialogmanagern der ersten und der zweiten Einheit herstellen, um die Gruppe von Konversationsressourcen der ersten und der zweiten Netzwerkeinheit automatisch gemeinsam zu nutzen, um gegebenenfalls ihren entsprechenden angeforderten Konversationsdienst auszuführen.
Die vorliegende Erfindung ermöglicht, dass eine Client-Einheit mit geringen Ressourcen lokal einfache Aufgaben sowie komplexe Aufgaben in binärer oder analoger Verbindung mit einem Server (oder einer anderen Einheit), der komplexere Konversationsmöglichkeiten besitzt, transparent ausführt. Die serverseitigen Funktionen (wie z. B. Spracherkennung) können durch ein normales IP-Netzwerk oder ein LAN-Netzwerk sowie mittels einer digitalen Übertragung über eine herkömmliche Telefonleitung oder ein paketvermitteltes Netzwerk oder über ein beliebiges herkömmliches drahtloses Datenprotokoll über ein Drahtlos-Netzwerk ausgeführt werden.
Die vorliegende Erfindung bietet vorteilhaft eine vollwertige Konversations-Benutzerschnittstelle bei einer beliebigen Einheit (wie z. B. eine überall vorhandene eingebettete Einheit) mit eingeschränkten CPU-, Speicher- und Leistungsmöglichkeiten (sowie eingeschränkten Konversationsressourcen), die komplexe Konversationsdienste unter Verwendung einer Client-Einheit mit geringen Ressourcen bereitstellt ohne die Notwendigkeit, z. B. die benötigten Konversationsargumente von einem Netzserver herunterzuladen. Die lokalen Möglichkeiten ermöglichen dem Benutzer, die lokale Einheit zu nutzen, ohne dass eine Verbindung erforderlich ist, z. B. außerhalb des Versorgungsgebiets eines Anbieters eines Drahtlos-Telefons. Außerdem sind die Kosten einer Standleitungsverbindung geringer und die Schwierigkeiten der Wiederherstellung, wenn derartige Standleitungsverbindungen verloren gehen, können gemindert werden.
Diese sowie weitere Aspekte, Merkmale und Vorteile der vorliegenden Erfindung werden beschrieben und werden aus der folgenden Beschreibung bevorzugter Ausführungsformen deutlich, die in Verbindung mit den beigefügten Zeichnungen zu lesen ist.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Übersichtsschaubild eines Systems zum Bereitstellen von Konversationsdiensten über eine automatische und koordinierte Nutzung von Konversationsressourcen zwischen vernetzten Einheiten gemäß einer Ausführungsform der vorliegenden Erfindung;
2 ist ein Ablaufplan eines Verfahrens zum Bereitstellen von Konversationsdiensten über eine automatische und koordinierte Nutzung von Konversationsressourcen zwischen vernetzten Einheiten gemäß einem Aspekt der vorliegenden Erfindung;
3 ist ein Ablaufplan eines Verfahrens zum Bereitstellen von Konversationsdiensten über eine automatische und koordinierte Nutzung von Konversationsressourcen zwischen vernetzten Einheiten gemäß einem weiteren Aspekt der vorliegenden Erfindung;
4 ist ein Übersichtsschaubild eines verteilten Systems zum Bereitstellen von Konversationsdiensten gemäß einer weiteren Ausführungsform der vorliegenden Erfindung, die einen herkömmlichen Browser verwendet; und
5 ist ein Übersichtsschaubild eines verteilten Systems zum Bereitstellen von Konversationsdiensten gemäß einer weiteren Ausführungsform der vorliegenden Erfindung, die einen herkömmlichen Browser verwendet.
GENAUE BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
Es ist klar, dass die vorliegende Erfindung in verschiedenen Formen von Hardware, Software, Firmware, speziellen Prozessoren oder einer Kombination hiervon realisiert werden kann. Die vorliegende Erfindung wird vorzugsweise in Software als eine Anwendung realisiert, die Programmbefehle umfasst, die körperlich auf einer Programmspeichereinrichtung (z. B. magnetische Diskette, RAM, CD-ROM, ROM und Flash-Speicher) enthalten und durch irgendeine Einheit oder Maschine, die eine geeignete Architektur wie etwa eine oder mehrere zentrale Verarbeitungseinheiten (CPU), einen Arbeitsspeicher (RAM) und eine (oder mehrere) Audiosignal-Eingabe/Ausgabe-(E/A-)Schnittstellen umfasst.
Es sollte ferner klar sein, dass sich die tatsächlichen Verbindungen zwischen den Systemkomponenten (oder den Prozessschritten) in Abhängigkeit von der Programmierung der vorliegenden Erfindung unterscheiden können, da einige der das System bildenden Komponenten und Verfahrensschritte, die in den beigefügten Figuren dargestellt sind, vorzugsweise in Software realisiert sind. Mit den hier angegebenen Lehren ist ein Fachmann in der Lage, diese sowie weitere Realisierungsmöglichkeiten oder Konfigurationen der vorliegenden Erfindung vorzusehen.
In 1 veranschaulicht ein Übersichtsschaubild ein System zum Bereitstellen von Konversationsdiensten durch die automatische und koordinierte gemeinsame Nutzung von Konversationsressourcen und Konversationsargumenten (Datendateien) zwischen vernetzten Einheiten gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung. Das System umfasst eine lokale Client-Einheit 100, die eine akustische Eingangsstufe 101 zum Verarbeiten von Tonsignal-/Spracheingaben und zum Ausgeben von Tonsignalen/Sprache, die durch die Client-Einheit 100 erzeugt werden, umfasst. Die Client-Einheit 100 kann z. B. ein Smartphone oder irgendein sprachaktiver PDA (persönlicher digitaler Assistent) sein. Die Client-Einheit 100 umfasst ferner eine oder mehrere lokale Konversationsmaschinen 102 zum Verarbeiten der akustischen Merkmale und/oder Signalformen, die von der akustischen Eingangsstufe 101 erzeugt und/oder aufgenommen werden, und zum Erzeugen eines Dialogs für die Ausgabe an den Benutzer. Die lokale Konversationsmaschine 102 kann z. B. eine eingebettete Spracherkennung, eine Sprechererkennungsmaschine, eine TTS-Maschine, eine NLU- und eine NLG-Maschine und eine Tonsignal-Aufnahme- und Kompressions-/Dekompressionsmaschine sowie einen beliebigen weiteren Typ der Konversationsmaschine enthalten.
Die Client-Einheit 100 umfasst ferner einen lokalen Dialogmanager 103, der eine Aufgabenverwaltung ausführt und die Ausführung eines Konversationsdienstes, der über einen Systemanruf angefordert wird, (entweder lokal oder über eine Netzwerkeinheit) steuert und koordiniert sowie den Dialog lokal und mit vernetzten Einheiten verwaltet. Wie im Folgenden genauer erläutert wird, ermittelt der Dialogverwalter 103, ob ein bestimmter Konversationsdienst verarbeitet werden soll und lokal bei dem Client 100 oder bei einem entfernten mit dem Netzwerk verbundenen Server (oder Einheit) ausgeführt werden soll. Diese Bestimmung beruht auf Faktoren wie etwa den Konversationsmöglichkeiten des Client 100 im Vergleich zu den Möglichkeiten der anderen vernetzten Einheiten sowie der verfügbaren Ressourcen und der Konversationsargumente, die zum Verarbeiten eines angeforderten Konversationsdienstes erforderlich sein können. Zu weiteren Funktionen gehören Netzwerkverkehr und erwartete Verzögerungen beim Empfangen von Ergebnissen von vernetzten Einheiten. Der Dialogmanager 103 führt eine Aufgabenverwaltung und Aufgaben der Ressourcenverwaltung wie etwa eine Lastverwaltung und eine Ressourcenzuweisung sowie das Verwalten des Dialogs zwischen den lokalen Konversationsmaschinen 102 und sprachfähigen lokalen Anwendungen 104 aus.
Wie in 1 beispielhaft gezeigt ist, ist die Client-Einheit 100 über das Netzwerk 105 mit einem Server 106, der Serveranwendungen 109 enthält, sowie mit Server-Konversationsmaschinen 107, die gegebenenfalls Konversationsdienste für die Client-Einheit 100 (oder eine beliebige andere Netzwerkeinheit oder Anwendung) bereitstellen, vernetzt. Wie bei den lokalen Maschinen 102 können die Servermaschinen 107 z. B. eine eingebettete Spracherkennung, eine TTS-Maschine, eine NLU- und NLG-Maschine, eine Audioaufnahme- und Kompressions-/Dekompressionsmaschine sowie einen beliebigen anderen Typ der Konversationsmaschine enthalten. Der Server 106 umfasst einen Server-Dialogmanager 108, der in ähnlicher Weise wie der oben beschriebene lokale Dialogmanager 103 arbeitet. Der Server-Dialogmanager 108 stellt z. B. fest, ob eine Anforderung eines Konversationsdiensts von dem lokalen Dialogmanager 103 durch den Server 106 oder an einem anderen entfernten vernetzten Server oder einer anderen Einheit verarbeitet und ausgeführt werden soll. Der Server-Dialogmanager 108 verwaltet außerdem den Dialog zwischen den Server-Konversationsmaschinen 107 und den sprachfähigen Server-Anwendungen 109.
Das System von 1 veranschaulicht des Weiteren die Client-Einheit 100 und den entfernten Server 106, der mit einem Server 110 vernetzt ist, der Konversationsmaschinen und/oder Konversationsargumente aufweist, auf die durch den Client 100 und den Server 106 bei Bedarf zugegriffen werden kann. Bei dem Netzwerk 105 kann es sich z. B. um das Internet, ein LAN (lokales Netzwerk) und ein privates Netzwerk sowie ein PSTN (öffentliches Fernsprechwählnetz) oder ein Drahtlos-Netzwerk (für eine drahtlose Datenübertragung über HF (Hochfrequenz) oder IR (Infrarot)) handeln. Obwohl 1 ein Client/Server-System darstellt, ist klar, dass dieser Ausdruck von einem Fachmann in der Weise zu verstehen ist, dass das System von 1 eine Vielzahl von Netzwerkservern, Einheiten und Anwendungen enthalten kann, die untereinander "auf Konversation ausgerichtet" sind, um eine automatische und koordinierte gemeinsame Nutzung von Konversationsfunktionen, -argumenten und -ressourcen bereitzustellen. Wie im Folgenden genauer erläutert wird, kann eine derartige "Ausrichtung auf Konversation" unter Verwendung von Konversationsnetzwerkprotokollen (oder -verfahren) erreicht werden, um Nachrichten zu übertragen, die durch die entsprechenden Dialogmanager verarbeitet werden, um zu ermöglichen, dass die vernetzten Einheiten Konversationsressourcen und -funktionen automatisch und synchron gemeinsam nutzen. Eine derartige Konversationskoordination schafft eine nahtlose Konversationsschnittstelle für den Zugriff auf entfernte Server, Einheiten und Anwendungen über die Schnittstelle einer Netzwerkeinheit.
Um eine Konversationskoordination zwischen den vernetzten Einheiten zu schaffen, damit sie ihre Konversationsfunktionen, -ressourcen und -argumente gemeinsam nutzen, überträgt insbesondere jede der vernetzten Einheiten Nachrichten unter Verwendung von Konversationsprotokollen (oder -verfahren), um Informationen in Bezug auf ihre Konversationsmöglichkeiten und -anforderungen auszutauschen. Wie in 1 gezeigt ist, umfasst z. B. die Client-Einheit 100 ein Kommunikationspaket 111 zum Senden und Empfangen von Nachrichten unter Verwendung von Konversationsprotokollen 112, Konversationsermittlungs-, -registrierungs- und -verhandlungsprotokollen 113 und Sprachübertragungsprotokollen 114 (oder Konversationscodierungsprotokollen). Der Server 106 umfasst gleichfalls ein Server-Kommunikationspaket 115, das Konversationsprotokolle 116, Konversationsermittlungs-, -registrierungs- und -verhandlungsprotokolle 117 und Sprachübertragungsprotokolle 118 umfasst. Diese Protokolle (Verfahren) werden in Bezug auf eine CVM (virtuelle Konversationsmaschine) in der Patentanmeldung von IBM mit dem Aktenzeichen YO999-111P genau erläutert, die mit dem Titel "Conversational Computing Via Conversational Virtual Machine" gleichzeitig mit dieser Patentanmeldung eingereicht, gemeinsam übertragen und als US-B-7 137 126 veröffentlicht wurde.
Kurz gesagt, die Konversationsprotokolle 112, 116 (oder das, was in YO999-111P als "verteilte Konversationsprotokolle" bezeichnet wird) sind Protokolle (oder Verfahren), die ermöglichen, dass die vernetzten Einheiten (z. B. Client 100 und Server 106) oder Anwendungen Nachrichten zum Registrieren ihres Konversationszustands, der Argumente und des Kontexts bei den Dialogmanagern anderer Netzwerkeinheiten senden. Die Konversationsprotokolle 112, 116 ermöglichen außerdem, dass die Einheiten andere Informationen austauschen wie z. B. Applets, ActiveX-Komponenten und anderen ausführbaren Code, die ermöglichen, dass die Einheiten oder zugeordnete Anwendungen eine Konversation zwischen derartigen Einheiten z. B. in einer Master/Slave- oder Peer-zu-Peer-Konversationsnetzwerk-Konfiguration austauschen. Die verteilten Konversationsprotokolle 112, 116 ermöglichen den Austausch von Informationen, um die Konversation unter Beteiligung mehrerer Einheiten und Anwendungen, die ein Master/Slave-Konversationsnetzwerk, Peer-Konversationsnetzwerk und stille Partner enthalten, zu koordinieren. Die Informationen, die unter Verwendung der verteilten Konversationsprotokolle zwischen vernetzten Einheiten ausgetauscht werden können, umfassen Zeiger auf Datendateien (Argumente), (gegebenenfalls) Übertragungen von Datendateien und anderen Konversationsargumenten, Benachrichtigung über Eingabe-/Ausgabeereignisse und Erkennungsergebnisse, Konversationsmaschinen-API-Anrufe und Ergebnisse, Benachrichtigung über den Zustand und Kontextänderungen und andere Systemereignisse, Registrierungsaktualisierungen: Quittung für Registrierung, Verhandlungsaktualisierungen: Quittung für Verhandlungen und Feststellungsaktualisierungen, wenn eine angeforderte Ressource verloren gegangen ist.
Die (verteilten) Konversationsprotokolle umfassen außerdem Dialogmanagerprotokolle (DM-Protokolle), die es dem Dialogmanager ermöglichen, Dienste, Verhaltens- und Konversationsanwendungen, E/A- und Maschinen-APIs, die z. B. im Dokument von IBM mit dem Aktenzeichen Y0999-111P beschrieben sind, zu verteilen. Das DM-Protokoll ermöglicht z. B. den Austausch folgender Informationen: (1) DM-Architekturregistrierung (z. B. jeder DM kann eine Sammlung lokaler DMs sein); (2) Zeiger auf zugehörige Metainformationen (Benutzer, Fähigkeiten der Einheiten, Erfordernisse der Anwendungen usw.); (3) Verhandlungen der DM-Netzwerktopologie (z. B. Master/Slave, Peer-zu-Peer); (4) gegebenenfalls Datendateien (Konversationsargumente), d. h., wenn Maschinen verwendet werden, die durch einen Master-DM gesteuert werden; (5) Benachrichtigungen über E/A-Ereignisse wie z. B. Benutzer-Eingaben/Ausgaben an Benutzer zur Übertragung an Maschinen und/oder zusätzlich zu Kontexten; (6) Benachrichtigungen über Erkennungsereignisse; (7) Übertragung einer verarbeiteten Eingabe an einen Master-DM; (8) Übertragung der Verantwortlichkeit des Master-DM an registrierte DMs; (9) DM-Verarbeitungsergebnis-Ereignisse; (10) DM-Erwartungen; (11) Übertragung von Vertraulichkeits- und Mehrdeutigkeitsergebnissen, vorgeschlagene Rückmeldung und Ausgabe, vorgeschlagener Erwartungszustand, vorgeschlagene Aktion, vorgeschlagene Kontextänderungen, vorgeschlagener neuer Dialogzustand; (12) Entscheidungsbenachrichtigung, Kontextaktualisierung, Aktionsaktualisierung, Zustandsaktualisierung usw.; (13) Benachrichtigung über abgeschlossene, fehlgeschlagene oder unterbrochene Aktionen; (14) Benachrichtigung über Kontextänderungen; und/oder (15) Datendateien, Kontext- und Zustandsaktualisierungen infolge einer Aktion.
Bei einer Master/Slave-Netzwerkkonfiguration steuert z. B. lediglich eine der vernetzten Einheiten die Konversation zu einem Zeitpunkt. Im Einzelnen verwaltet und koordiniert die Master-Einheit (d. h. der Dialogmanager der Master-Einheit) die Konversation zwischen den Netzwerkeinheiten und entscheidet, an welche Einheit ein vorgegebener Konversationsdienst oder eine vorgegebene Konversationsfunktion vergeben wird. Diese Entscheidung kann auf Informationen beruhen, die durch jede der Einheiten oder Anwendungen in Bezug auf ihre Konversationsfähigkeiten bereitgestellt werden. Diese Entscheidung kann außerdem auf dem Master beruhen, der festlegt, welche Slave-Einheit (mit den erforderlichen Konversationsfähigkeiten) die vorgegebene Konversationsfunktion am besten ausführen kann. Der Master kann z. B. eine Vielzahl von Slaves anfordern, um eine Spracherkennung auszuführen und die Ergebnisse an den Master bereitzustellen. Der Master kann dann die optimalen Ergebnisse auswählen. Es ist klar, dass es sich hier bei dem auf der Ebene der Spracherkennung Beschriebenen um den Mechanismus auf der Ebene der DM-Protokolle (Dialogmanager-Protokolle) zwischen verteilten Dialogmanagern handeln kann (wie in Y0999-111P beschrieben ist). In der Tat wird der Master dann, wenn ein Dialog zwischen mehreren Dialogmanagern auftritt, eine Maßzahl der Bewertung der Ergebnisse jedes Dialogmanagers erhalten, und es erfolgt eine dementsprechende Entscheidung, um festzustellen, welcher Dialogmanager mit der Eingabe weitermacht, und zwar nicht nur auf der Grundlage der Genauigkeit der Spracherkennung, sondern anhand des Dialogs (Bedeutung), des Kontexts und der Vorgeschichte (sowie weiterer Elemente, die berücksichtigt werden wie z. B. Präferenzen des Benutzers, die Vorgeschichte und Präferenzen der Anwendung).
Bei Peer-zu-Peer-Verbindungen versucht jede Einheit die Funktionen zu bestimmen, die sie ausführen kann, und zeichnet eine Anforderung auf, dies zu tun. Die Einheit, die die Aufgabe akzeptiert hat, wird diese Aufgabe ausführen und anschließend ihre Leistungsfähigkeit bewerten. Die Einheiten verhandeln dann anhand ihrer Bewertungszahlen, welche Einheit die Aufgabe ausführt.
In einer Ausführungsform werden die verteilten Konversationsprotokolle 112, 116 über RMI-(Fernverfahrensaufruf) oder RPC-(Fernprozeduranruf) Systemanrufe realisiert, um die Anrufe zwischen den Anwendungen und den unterschiedlichen Konversationsmaschinen über das Netzwerk zu realisieren. Wie in der Technik bekannt ist, ist RPC ein Protokoll, das ermöglicht, dass eine Anwendung einen Dienst von einer anderen Anwendung über das Netzwerk anfordert. Gleichfalls ist RMI ein Verfahren, durch welches Objekte in einem verteilten Netzwerk in Wechselwirkung treten können. RMI ermöglicht, dass ein oder mehrere Objekte zusammen mit der Anforderung übergeben werden können. Außerdem können die Informationen in einem Objekt gespeichert werden, das über CORBA oder DCOM ausgetauscht wird, oder erklärend dargestellt werden (wie z. B. über XML). Wie in der oben eingeschlossenen Patentanmeldung von IBM mit dem Aktenzeichen YO999-111P erläutert wurde, können Konversationsprotokolle (Verfahren) (oder die verteilten Protokolle) verwendet werden, um eine verteilte Realisierung der Konversationsfunktionen, die durch ein CVM-Gerüst unterstützt werden, zwischen Konversationsanwendungen und dem CVM-Gerüst über APIs oder zwischen der CVM und Konversationsmaschinen über Konversationsmaschinen-APIs zu erreichen. Die Konversationsmaschinen-APIs sind Schnittstellen zwischen den Kernmaschinen und Anwendungen, die sie benutzen, und Protokollen, um mit (lokalen oder vernetzten) Kernmaschinen Daten auszutauschen. Die Konversations-APIs stellen eine API-Schicht bereit, um auf Konversation gerichtete Anwendungen einzubinden oder zu entwickeln, die Basisklassen und Komponenten zum Bilden von Konversationsbenutzerschnittstellen enthalten.
Ein Dialogmanager gemäß der vorliegenden Erfindung kann gleichfalls über APIs mit Anwendungen und (lokalen oder vernetzten) Maschinen Daten austauschen. Auf diese Weise kann ein Dialogmanager auf die Ergebnisse und die Rückrufe von allen entfernten Prozeduren (Prozeduranrufe an entfernte Maschinen und Anwendungen) reagieren, als ob es sich um eine lokale Anwendung handelt, um z. B. zwischen den Anwendungen und (lokalen oder vernetzten) Ressourcen zu entscheiden, um der aktiven Anwendung Priorität zuzuweisen und die aktive Anwendung zu ermitteln und um festzulegen, welches Ergebnis als aktiv betrachtet werden soll.
Die Konversationsfeststellungs-, Registrierungs- und Verhandlungsprotokolle 113, 117 sind Netzwerkprotokolle (oder -verfahren), die verwendet werden, um lokale oder vernetzte auf Konversation gerichtete Systeme (d. h. Anwendungen oder Einheiten, die Konversationsprotokolle "sprechen"). Die Registrierungsprotokolle ermöglichen Einheiten oder Anwendungen, ihre Konversationsfähigkeiten, ihren Zustand und ihre Argumente zu registrieren. Die Verhandlungsprotokolle ermöglichen, dass Einheiten über Master/Slave-, Peer-zu-Peer- oder Netzwerke mit stillem Partner verhandeln.
In einer Ausführungsform realisieren die Feststellungsprotokolle einen Lösungsansatz "Rundsenden und Hören", um eine Reaktion von anderen Einheiten des Typs "Rundsenden und Hören" auszulösen. Dies kann z. B. die Erzeugung von dynamischen und spontanen Netzwerken (wie z. B. Bluetooth- und Hopping-Netzwerke, die später erläutert werden) ermöglichen. In einer weiteren Ausführungsform kann eine Standardservereinstellung (möglicherweise der Master) verwendet werden, die die "Adresse" der unterschiedlichen Netzwerkeinheiten registriert. In dieser Ausführungsform beläuft sich die Feststellung auf alle Einheiten im Netzwerk, die mit dem Server Daten austauschen, um die Liste von registrierten Einheiten zu prüfen, um zu ermitteln, welche Einheiten mit derartigen Einheiten verbunden sind. Die Informationen, die über die Feststellungsprotokolle übertragen werden, umfassen das Folgende: (1) Rundsendeanforderungen zur Quittierung oder zum Lauschen auf Anforderungen; (2) Austausch von Einheitenkennungen; (3) Austausch von Kennziffern/Zeigern zur ersten Registrierung; und (4) Austausch von Kennziffern zur ersten Verhandlung.
In einer Ausführungsform zum Realisieren der Registrierungsprotokolle können die Einheiten bei einer Verbindung Informationen über ihre Konversationsfähigkeiten mit einem im Voraus eingerichteten Protokoll (z. B. TTS-English, beliebiger Text, Spracherkennung, 500 Wörter + FSG-Grammatik, keine Sprechererkennung usw.) austauschen, indem eine Gruppe von Merkern oder ein Einheiteneigenschaftsobjekt ausgetauscht wird. Anwendungen können gleichfalls Maschinenanforderungslisten austauschen. Bei einer Master/Slave-Netzwerkkonfiguration kann der Master-Dialogmanager sämtliche Listen kompilieren und die Funktionen und Erfordernissen mit den Konversationsfähigkeiten in Übereinstimmung bringen. Beim Fehlen einer Master-Einheit (Dialogmanagers) kann ein gemeinsamer Server verwendet werden, um die Konversationsinformationen an alle Maschinen oder Einheiten im Netzwerk zu übertragen. Die Registrierungsprotokolle ermöglichen der Austausch folgender Informationen: (1) Fähigkeiten und Belastungsnachrichten, einschließlich Definition und Aktualisierungsereignisse; (2) Maschinenressourcen (ob eine vorhandene Einheit NLU, DM, NLG, TTS, Sprechererkennung, Spracherkennung, Kompression, Codierung, Speicherung usw. enthält); (3) E/A-Fähigkeiten; (4) CPU-, Speicher- und Belastungsfähigkeiten; (5) Datendateitypen (domänenspezifisch, Wörterbuch, Sprachmodelle, Sprachen usw.); (6) Netzwerkadressen und Merkmale; (7) Informationen über einen Benutzer (Definition und Aktualisierungsereignisse); (8) Benutzerpräferenzen für die Einheit, Anwendung oder Dialog; (9) kundenspezifische Anpassung; (10) Benutzererfahrung; (11) Hilfe; (12) Fähigkeitsanforderungen pro Anwendung (und Anwendungszustand) (Definition und Aktualisierungsereignisse); (13) Metainformationen für CUI-Dienste und Verhaltensweisen (Hilfedateien, Kategorien, Konversationsprioritäten usw.) (Definition und Aktualisierungsereignisse, typischerweise über Zeiger auf eine Tabelle); (14) Protokollquittungen; und/oder (15) Topologieverhandlungen.
Eine Registrierung kann unter Verwendung eines herkömmlichen Kommunikationsprotokolls wie z. B. TCP/IP, TCP/IP 29, X-10 oder CEBus und einer Basiskommunikation zwischen Einheiten ausgeführt werden. Die Einheiten verwenden eine verteilte Konversationsarchitektur, um ihre Konversationsargumente (z. B. aktives Vokabular, Grammatik- und Sprachmodelle, Analyse- und Übersetzungs-/Identifizierungsmodelle, Sprachausdrücke, Syntheseregeln, Grundformen (Ausspracheregeln) und Spracharten) mit ihrer zugeordneten Konversationsmaschine und dem Dialogmanager auszutauschen. Diese Informationen werden entweder als Dateien oder Datenströme zu dem Dialogmanager und dem Konversationsmaschinen oder als URLs geleitet. Außerdem können Kontextinformationen übertragen werden, indem das Weiterleiten oder Zeigen auf das Kontextpaket/die Vorgeschichte der Einheit oder der Anwendung, auf die die Steuereinheit zugreifen kann, angegeben wird und ihrem Kontextpaket hinzugefügt wird. Einheiten leiten außerdem Informationen über ihre Mehrmoden-E/A- und UI-Fähigkeiten (Bildschirm/kein Bildschirm, Audio-Ein/Aus-Fähigkeiten, Tastatur usw.) weiter. Die Konversationsargumente ermöglichen einer Dialogmaschine, die Relevanz einer neuen Abfrage durch die NLU-Maschine anhand des momentanen Zustands und Kontextes abzuschätzen.
In Bezug auf die Verhandlungsprotokolle können die Netzwerkeinheiten und Anwendungen bei der Registrierung von Erfordernissen und Fähigkeiten jeder der Netzwerkeinheiten während der Verhandlung für eine vorgegebene vorübergehende Konfiguration stimmen. Wenn eine Anwendung die Konfiguration (d. h. die Topologie) einführt, wird die Entscheidung automatisch eingeführt. Andernfalls kann sie fordern, Master oder Slave oder Peer zu sein. Anhand des Kennzeichens der Anforderungen erfolgt die Entscheidung für eine spezielle Konfiguration und diese wird an alle Einheiten und Anwendungen übertragen (in der Tabelle von verfügbaren Ressourcen, die jede Einheit/Anwendung führt). Immer dann, wenn ein System seinen Zustand und die Anforderung ändert, tauscht es mit den anderen vernetzten Dialogmanagern/Ressourcen Daten aus, um eine neue Verhandlung auszulösen und neue Zustands- und Kontextinformationen auszutauschen.
Die Sprachübertragungsprotokolle 114, 118 ermöglichen den Einheiten, komprimierte Sprache oder lokale Verarbeitungsergebnisse an andere Einheiten und Anwendungen im Netzwerk zu senden bzw. von diesen zu empfangen. Die Konversationsmaschinen 102, 107 enthalten vorzugsweise Kompressions-/Dekompressionsmaschinen zum Komprimieren von Sprache (Ergebnissen) zum Übertragen und zum Dekomprimieren von komprimierter Sprache (oder Ergebnissen), die über das Netzwerk von anderen Einheiten oder Anwendungen für eine lokale Verarbeitung erhalten werden. Die Sprachübertragungsprotokolle werden durch Sprachübertragungs-Clients genutzt, die in den Einheiten Systeme oder Anwendungen zur Verarbeitung ausführen, um komprimierte Sprache an andere vernetzte Einheiten zu senden bzw. von diesen zu empfangen. Die Sprachübertragungs-Clients der Einheiten arbeiten in Verbindung mit Kompressions-, Dekompressions- und Rekonstruktionsmaschinen unter Verwendung von geeigneter Kompressionshardware zur Verarbeitung von Sprache, die über das Netzwerk übertragen wird. Die Sprachcodierer stellen eine für die Wahrnehmung annehmbare oder verständliche Rekonstruktion der komprimierten Sprache und eine optimierte Konversationsleistung (z. B. Wortfehlerrate) bereit. Die Sprache wird in den entsprechenden vernetzten Einheiten unter Verwendung von Maschinen zur Verarbeitung von Akustiksignalen (Audioteilsysteme) und geeigneter Audiohardware aufgenommen (und in Merkmale umgewandelt). Außerdem können Dateiformate komprimierter Sprache zwischen Einheiten zur Verarbeitung von Sprache gesendet und empfangen werden. Im Einzelnen ermöglichen Sprachübertragungsprotokolle, dass die Einheiten komprimierte Sprache oder Ergebnisse einer lokalen Verarbeitung zu anderen Einheiten und Anwendungen im Netzwerk senden bzw. von diesen empfangen. In einer Ausführungsform wird nach dem Quittierungsprozess zwischen einer sendenden Einheit und einer empfangenden Einheit ein (paketgestützter) Datenstrom an den Empfänger gesendet. Die Paketvorsätze geben vorzugsweise das Codierschema und Codierargumente an (d. h. die Abtastfrequenz, Merkmalcharakteristiken, Dimensionen, Transformationen, die am Eingangssignal ausgeführt werden, Wesen des Eingangssignals usw.), die zum Codieren der Sprache (oder Ergebnisse) verwendet werden. Außerdem können Fehlerkorrekturinformationen (z. B. der letzte Merkmalvektor des vorherigen Pakets, um den Differentialdecodierer zu korrigieren, wenn das vorherige Paket verloren gegangen oder verzögert ist) oder eine geeignete Nachrichtengebung, um die verloren gegangenen Pakete wiederherzustellen (erneut zu senden) eingeführt werden.
Außerdem können die Dialogmanager über die Dialogmanagerprotokolle oder DM-Protokolle Daten austauschen (wie in dem oben einbezogenen Dokument von IBM mit dem Aktenzeichen YO999-111P erläutert ist). Die DM-Protokolle werden verwendet, um zwischen mehreren Dialogmanagern zu verhandeln, welcher Dialogmanager aktiv ist und welcher Dialogmanager die Eingabe empfangen sollte. Da im vorliegenden Fall die Serverressource nur dann "abgefragt" wird, wenn dies tatsächlich erforderlich ist, stellen die DM-Protokolle eine Variation bereit: der lokale Dialogmanager versucht a priori zu ermitteln, ob die Funktion entfernt ausgeführt werden sollte. In Situationen, in denen ein Fehler gemacht wird oder Zweifel bestehen, kann der Dialogmanager auf die Frage von der lokalen Maschine warten und sich entscheiden, bei verbleibenden Zweifeln einen Server zum Vergleich abzufragen.
Auf der Grundlage der obigen Erläuterung sollte deswegen klar sein, dass die Netzwerkprotokolle zur Koordinierung (oder für eine koordinierte Schnittstelle) zwischen vernetzten Einheiten zur gemeinsamen Nutzung von Konversationsdiensten und Funktionen dienen. Der Ausdruck "koordinierte Schnittstelle" bedeutet, dass eine einzelne Konversation zwischen den unterschiedlichen Akteuren (Einheiten/Anwendungen) in der Weise geführt werden kann, als ob sie die gesamte Konversation vollständig verstehen und in geeigneter Weise wissen, wer zu einem bestimmten Zeitpunkt angesprochen ist. Das Verhalten jedes Konversationssystems oder jeder Anwendung kann durch einen Dialogmanager (d. h. ein Master in der Master/Slave-Betriebsart), die Anwendungen (die festlegen kann, wer Master, Slawe oder Peer ist), einen System-Dialogmanager (falls vorhanden), die Architektur und die Verhandlung (in der Peer-zu-Peer-Betriebsart) gesteuert/verwaltet werden, um jede Konversationsfunktion an dem geeigneten System transparent für den Benutzer auszuführen. Für den Benutzer einer Client-Einheit wird eine nahtlose Konversationsschnittstelle bereitgestellt (d. h., es erscheint so, dass alle Konversationswechselwirkungen über ein einzelnes Konversationssystem erfolgen), ungeachtet dessen, dass bestimmte Konversationsfunktionen, Systeme und Ressourcen mehrere vernetzte Einheiten darstellen können (z. B. ein Zellentelefon, eine Personenrufanlage und einen PDA).
Bei dem Beispiel eines koordinierten Konversationssystems (das oben in dem oben aufgenommenen Dokument von IBM mit dem Aktenzeichen YO999-111P beschrieben wurde) handelt es sich um eine Fernsteuerung, die als UCA (universelles Konversationsgerät) bezeichnet wird. Das UCA erkennt Gerate, die auf Konversation ausgerichtet sind. Jedes auf Konversation ausgerichtetes Gerat sendet seine Konversationsargumente (Vokabular und Grammatik) an das UCA. Das UCA wirkt als ein Master für derartige Gerate und aktualisiert das geeignete Gerät, wenn eine Konversationswechselwirkung mit dem Benutzer einen Befehl an das Gerät zur Folge hat. Umgekehrt sendet sie bei der Ausführung des Befehls oder immer dann, wenn sich der Gerätezustand ändert, eine Aktualisierung an die Fernsteuerung. Ein Konversationsgerät, das keine weiteren Konversationsmöglichkeiten (andere als die entsprechenden Argumente) besitzt, wird als ein "stiller Partner" bezeichnet.
In einer weiteren Ausführungsform kann ein Server oder eine Basisstation sämtliche Konversationsfunktionen ausführen außer der Kompression der Audioaufnahme und des Versendens, was durch die Fernsteuerung (oder das UCA) ausgeführt wird. Die Fernsteuerung kann außerdem eine bestimmte UI für den Benutzer bereitstellen, um ihn über den Zustand der unterschiedlichen Geräte zu benachrichtigen. Dies kann über Sprache, eine grafische Benutzeroberfläche oder irgendeine konversationsbezogene Kombination dieser (oder anderer) Modalitäten erfolgen.
Obwohl herkömmliche Netzwerktopologien in Verbindung mit dem System von 1 verwendet werden können, ist eine bevorzugte Netzwerktopologie eine Topologie, die eine spontane dynamische Vernetzung erzeugt (d. h. ein Netzwerk, das spontan zwischen Einheiten gebildet wird, die sich in einem bestimmten Kommunikationsbereich befinden). Eine derartige spontane Vernetzung kann unter Verwendung des kürzlich aufgekommenen "Bluetooth"-Vernetzungsprotokolls realisiert werden, das z. B. auf der Webseite http://www.bluetooth.com beschrieben wird. Kurz gesagt, Bluetooth ist eine Codebezeichnung für ein Netzwerkprotokoll, das ad hoc eine Verbindungsfähigkeit für ein Drahtlos-Netzwerk schafft. Bluetooth ist im Einzelnen ein Protokoll zum Bereitstellen von drahtlosen Kurzstrecken- Funkverbindungen zwischen Einheiten (wie etwa Smartphones, Zellentelefone, Personenrufanlagen, PDAs, Laptop-Computer, mobile Einheiten usw.), die sich in einem bestimmten Bereich befinden, um ein Netzwerk (oder das auch als ein "Piconet" bekannt ist) zwischen derartigen Einheiten aufzubauen. Ein Piconet bezeichnet eine Sammlung von Bluetooth-fähigen Einheiten (Knoten), die ad hoc mit einem Knoten verbunden sind, der in dem Piconet während der restlichen Netzwerkverbindung als ein Master wirkt. Zwei oder mehr Piconets können vernetzt sein, um ein so genanntes Scatternet zu bilden.
Es ist klar, dass irgendein Protokoll zur spontanen dynamischen Vernetzung gemäß der vorliegenden Erfindung realisiert werden kann. Die Netzwerktopologie von 1 kann z. B. gemäß dem "Frequenzsprung"-Kommunikationsnetzwerk ("Hopping"-Kommunikationsnetzwerk) realisiert sein, das in der US-Patentschrift Nr. 6 150 961 beschrieben ist, das am 24. November 1998 mit dem Titel "Automated Traffic Mapping" eingereicht wurde und gemeinsam übertragen wurde.
In 2 veranschaulicht nun einen Ablaufplan ein Verfahren zum Bereitstellen einer automatischen und koordinierten gemeinsamen Nutzung von Konversationsfunktionen zwischen vernetzten Einheiten gemäß einem Aspekt der vorliegenden Erfindung. Im Einzelnen veranschaulicht 2 ein Verfahren des Betriebs des Systems von 1 genauer. Anfangs äußert der Benutzer einen gesprochenen Befehl gegenüber der lokalen Client-Einheit (oder gibt eine Abfrage auf andere Weise aus), der vorverarbeitet wird, indem er z. B. digitalisiert wird und die relevanten Merkmale des digitalisierten Sprachsignals extrahiert werden (Schritt 200). Alternativ kann der lokale Dialogmanager eine Anforderung von einer lokalen Anwendung 104 empfangen, um synthetische Sprache (TTS) zur Ausgabe an den Benutzer zu erzeugen (Schritt 200).
Es erfolgt eine Feststellung (über den lokalen Dialogmanager 103), ob eine lokale Verarbeitung zur Verfügung steht (Schritt 201), z. B. ob eine Spracherkennung oder eine Sprachanalyse lokal ausgeführt werden kann. Es sollte klar sein, dass der lokale Dialogmanager 103 für diese Feststellung einen entfernten Server im Voraus definieren kann, wo die Erkennung/Synthese erfolgen muss (z. B. eine IP-Adresse für eine Basisverbindung, eine URL-Adresse für eine servergestützte Aufzeichnung über ein Servlet oder eine Telefonnummer für Direktverbindungen oder eine Verbindung zu einem IVR). Außerdem kann die Feststellung, dass die lokale Einheit keine verfügbaren Ressourcen oder Argumente besitzt, um eine Aufgabe auszuführen (oder wirksam auszuführen), auch durch den Dialogmanager 103 bei der Ausführung der lokalen Anwendung 104 anhand der Ressourcenanforderungen, die durch die Anwendung in einer Vorsatzdatei angegeben werden, getroffen werden. Außerdem können bestimmte Befehle oder angeforderte Funktionen bewirken, dass der Dialogmanager automatisch mit einem entfernten Server verbunden wird. Sicherheitsanwendungen (z. B. Sprecherüberprüfung) können z. B. automatisch zur serverseitigen Verarbeitung umgeschaltet werden, so dass die Spracheindrücke nicht an die Clients verteilt werden. Des Weiteren können Systems zur lokalen Fahrzeugnavigation unter Verwendung eines Telefons oder eines basisgestützten Servers automatisch zu entfernten Servern umgeschaltet werden, so dass die lokale Einheit keinen großen Umfang an Navigationsinformationen speichern muss.
Wenn festgestellt wird, dass eine lokale Verarbeitung zur Verfügung steht (eine positive Feststellung im Schritt 201), wird die Verarbeitung über lokale Maschinen 102 lokal ausgeführt (Schritt 202). Wenn dagegen festgestellt wird, dass keine lokale Verarbeitung zur Verfügung steht (negative Feststellung im Schritt 201), werden die relevanten Merkmale/Signalformen/Informationen automatisch an einen entfernten mit dem Netzwerk verbundenen Server übertragen (Schritt 204) (über IP, LAN, Bluetooth, IP, HF oder über Telefon oder IP-Telefon), wobei die entfernte Verarbeitung (z. B. Spracherkennung/Synthese) ausgeführt wird (Schritt 205) (möglicherweise mit einer bestimmten Benutzer/Server-Wechselwirkung).
Es sollte klar sein, dass die Übertragung von Sprache vom lokalen Client zu einem entfernten mit dem Netzwerk verbundenen Server (oder umgekehrt) unter Verwendung verschiedener Techniken ausgeführt werden kann. Eine Direktübertragung der Signalform kann z. B. als eine Datei, als ein Strom oder als ein Strom von Paketen ausgeführt werden. Außerdem kann eine komprimierte Signalform unter Verwendung herkömmlicher Verfahren wie z. B. ADPCM und APC gesendet werden. Des Weiteren kann ein Strom von Merkmalen gemäß dem Verfahren gesendet werden, das im Dokument "Compression Of Acoustic Features For Speech Recognition In Network Environments" von G. Ramaswamy u. a., Bd. 2, S. 977 bis 980, Proc. ICASSP, 1998 beschrieben ist. Dieses Verfahren ermöglicht eine Erkennung (Spracherkennung, Sprechererkennung oder NLU) auf der Empfängerseite, jedoch keine Rekonstruktion des Signals. Außerdem kann die Übertragung von Sprache unter Verwendung eines Codierverfahrens oder Codierschemas anhand von komprimierten Merkmalen und einer Tonlagenschätzung ausgeführt werden, wodurch das Sprachsignal mit einer angemessenen Qualität für eine verständliche und sogar angenehme Wiedergabe (zur Wiedergabe, Korrektur, weiteren menschlichen Verarbeitung oder Archivierung) rekonstruiert werden kann. Derartige Codierschemen sollten Datenraten mit niedrigen Werten zwischen 4 und 5 kBit/s ohne Verschlechterung der Erkennungsleistung bereitstellen. Folglich kann ein interaktiver Austausch mit nachgeordneten Ressourcen (Server-Ressourcen) sogar über drahtlose Modems oder drahtlose Datenverbindungen in Echtzeit ausgeführt werden. Es sollte klar sein, dass andere Schemen unter Verwendung ähnlicher Codierschemen verwendet werden könnten, die eine sehr hohe Wiedergabequalität bereitstellen würden. Außerdem kann ein beliebiges Verfahren, das eine Kompression der Cepstra-Merkmale und der Tonlage ermöglicht und eine Erkennung (Sprache, Sprecher, NLU) auf der Serverseite ohne Verschlechterung auf der empfangenen Seite und die Rekonstruktion des Signals ermöglicht, in Verbindung mit der vorliegenden Erfindung verwendet werden. Diese Rekonstruktion ist nützlich für eine spätere Wiedergabe vom Server oder Wiedergabe vom Client (falls lokal gespeichert) oder zum anschließenden Korrekturlesen der Übersetzung, zur Fehlerkorrektur oder zur persönlichen Überwachung des Prozesses. Es sollte klar sein, dass jedes geeignete Kompressionsschema (Kompressionsprotokoll) verwendet werden kann.
Es sollte klar sein, dass das Kompressions- oder Codierschema (Übertragungsprotokolle oder Codierprotokolle) sich zwischen Einheiten unterscheiden kann. Die Codierung, um Eingabesprache von dem Audioaufnahmesystem (des Client) zu einer vernetzten Ressource zu versenden, kann z. B. von dem Codierprotokoll verschieden sein, das verwendet wird, um die Ausgabesprache (z. B. Eingabeaufforderungen, Wiedergabesignale oder TTS) von der vernetzten Ressource (Server) zu dem Audioausgang (Client) zu versenden. In dem ersten Fall sollte die Codierung tatsächlich optimiert sein, um eine gute Erkennungsleistung auf der Serverseite zu gewährleisten, wobei die Rekonstruktion zur Wiedergabe zwar wichtig, jedoch nicht so dramatisch ist. Die Bitrate (das Kompressionsverhältnis) ist natürlich wichtig. Ein Kompromiss bei der Kompressionsrate kann zwischen der Robustheit (Fehlerrate-Merkmalverzerrung) und der Wahrnehmungsqualität angepasst werden, um eine Soll-Bitrate zu erreichen und aufrechtzuerhalten. Außerdem können bestimmte Schemen ausgewählt werden, um die Robustheit gegenüber einigen Kanal- oder Hintergrundverzerrungen zu vergrößern. Für die zuletzt genannte Aufgabe (Ausgangssignal) sollte dagegen die Codierung für eine Verständlichkeit oder eine Wahrnehmungsqualität und zur Annehmlichkeit oder um bestimmte spezielle Merkmale der Sprache oder das Tonsignals zu bewahren, optimiert sein.
Nach der lokalen Verarbeitung (Schritt 202) oder der entfernten Verarbeitung (Schritt 205) wird festgestellt (über den lokalen Dialogmanager 103 oder den Server-Dialogmanager 108), ob die Ergebnisse der Verarbeitung annehmbar sind (Schritte 203 und 206). Wenn festgestellt wird, dass die Verarbeitungsergebnisse nicht annehmbar sind (negative Feststellung im Schritt 203 oder Schritt 206) leitet der lokale Client oder der entfernte Server die Merkmale oder die Signalform (über IP, LAN, Bluetooth, IR, HF oder eine Verbindung über Telefon oder IP-Telefon) automatisch an einen Server weiter, der eine derartige Verarbeitung ausführen kann (Schritt 204 oder Schritt 207). Die Rückweisung der Ergebnisse für Spracherkennung und NLU kann z. B. auftreten, wenn derartige Ergebnisse unbekannt sind oder fehlerhaft erkannt werden oder mehrdeutig sind (oder anhand eines Zuverlässigkeitsmaßes, das dem Dialogmanager jeder Ressource (lokal oder entfernt) zugeordnet ist). Die automatische Verbindung von dem lokalen oder entfernten System zu einem Serversystem kann vorzugsweise auf der Grundlage des Pegels der akustischen oder der LM-(Sprachmodell-)Bewertungszahlen erfolgen, die durch den lokalen Sprachdecodierer z. B. unter Verwendung der Techniken, die in dem US-Patent Nr. 5 937 383 an Ittycheriah u. a. mit dem Titel "Apparatus and Methods For Speech Recognition Including Individual or Speaker Class Dependant Decoding History Caches For Fast Word Acceptance or Rejection" gelehrt werden, das gemeinsam übertragen wurde, zurückgeführt werden (der entfernte Server wird z. B. dann kontaktiert, wenn festgestellt wird, dass diese Bewertungszahlen unter einen vorgegebenen Schwellenwert fallen). Es sollte klar sein, dass jedes geeignete Maß oder jeder geeignete Lösungsansatz zum Schätzen des Vertraulichkeitsgrads oder der erkannten Äußerung oder Abfrage (während und nach dem Dialog) zur Feststellung verwendet werden kann, wenn die Ergebnisse, die durch ein herkömmliches System erhalten werden, annehmbar sind oder nicht (wobei in diesem Fall ein anderes System betrachtet wird).
Für TTS können in ähnlicher Weise der lokale und der entfernte Dialogmanager 103, 108 die Komplexität des Texts prüfen, um festzustellen, ob das TTS lokal oder entfernt ausgeführt wird. TTS wird z. B. entfernt ausgeführt, wenn die Ausspracheregeln für ein Wort nicht bekannt sind oder der Text eine komplexe Analyse erfordert. Ein weiteres Beispiel ist der Fall, bei dem die TTS mit einem anderen Akzent, Dialekt oder in einer anderen Sprache betont werden muss oder wenn ein bestimmter Ausspruch einer Person imitiert werden soll.
Nachdem die Verarbeitung entfernt ausgeführt wurde, werden die Ergebnisse (Schritt 208) (über Telefon, IP-Adresse, MAC-(Media Access Control-)Adresse usw.) zurück zum lokalen Client gesendet. Es sollte klar sein, dass die Ausgabe (d. h. die Sprache, die an den Benutzer ausgegeben wird) lokal oder am Server synthetisiert werden kann. Wenn die Synthese am Server erfolgt, kann die Sprache in komprimierter Form (unter Verwendung der Sprachübertragungsprotokolle, die oben erläutert wurden) an den Client zur lokalen Dekomprimierung gesendet werden. Es sollte klar sein, dass das Codierschema gleich dem Schema sein kann, das zum Senden der Sprachmerkmale vom Client an den Server verwendet wurde, oder von diesem verschieden sein kann. Alternativ kann die Sprache durch den Server z. B. über eine andere analoge PSTN-Leitung direkt "rundgesendet" werden, wobei die Verbindung über einen Telefonanruf vom Client an den Server (Rückruf) hergestellt werden kann.
In letzter Zeit sind Bemühungen ausgelöst worden, um ein geeignetes Zuverlässigkeitsmaß für die erkannte Sprache zu entwickeln. Im Dokument "LVCSR Hub5 Workshop", 29. April bis 1. Mai 1996, MITAGS, MD, organisiert durch NIST und DARPA, werden unterschiedliche Lösungsansätze vorgeschlagen, um jedem Wort einen Zuverlässigkeitsgrad zuzuweisen. Ein Verfahren verwendet einen Entscheidungsbaum, der auf wortabhängige Merkmale trainiert ist (Anzahl von Trainingsäußerungen, minimales und durchschnittliches Auftreten von Triphonen, Auftreten im Sprachmodelltraining, Anzahl von Phonemen/Lefemen, Dauer, akustische Bewertungszahl (schnelle Übereinstimmung und detaillierte Übereinstimmung), Sprache-Nichtsprache), satzabhängige Merkmale (Störabstand, Schätzwerte der Sprechraten: Anzahl von Wörtern oder Lefemen oder Vokalen pro Stunde, Satzwahrscheinlichkeit, die durch das Sprachmodell bereitgestellt wird, Wahrscheinlichkeitsraten, normierte mittlere Wahrscheinlichkeit pro Rahmen, Trigramm-Auftreten im Sprachmodell), Wort in Kontextmerkmalen (das Trigramm-Auftreten im Sprachmodell) sowie Sprechernaturmerkmale (Akzent, Dialekt, Geschlecht, Alter, Sprechrate, Identität, Audioqualität, SNR usw.). Eine Fehlerwahrscheinlichkeit wird aus den Trainingsdaten für jedes der Blätter des Baums berechnet. Algorithmen zum Bilden derartiger Bäume werden durch Breimau u. a. im Dokument "Classifikation and Regression Trees", Chapman & Hal, 1993 erläutert. Bei einer Erkennung werden alle oder einige dieser Merkmale während der Erkennung gemessen, und für jedes Wort wird der Entscheidungsbaum bis zu einem Blatt durchgegangen, das einen Zuverlässigkeitsgrad schafft. Außerdem ist in dem Referenzdokument von Neti u. a. mit dem Titel "Word Based Confidence Measures As A Guide For Stack Search In Speech Recognition", ICASSP97, Munch, Germany, April 1997 ein Verfahren beschrieben, das vollständig auf Bewertungspunktzahlen beruht, die durch einen IBM Paketdecodierer (unter Verwendung einer Aufzeichnungs-Wahrscheinlichkeit, tatsächlich die durchschnittliche inkrementale Aufzeichnungs-Wahrscheinlichkeit, genaue Übereinstimmung, schnelle Übereinstimmung) zurückgeführt werden.
Bei dem LVCSR-Ablauf wird ein anderes Verfahren zum Schätzen des Zuverlässigkeitsgrades unter Verwendung von Prädiktoren über eine lineare Regression ausgeführt. Die verwendeten Prädiktoren sind: die Wortdauer, die Bewertungszahl des Sprachmodells, die durchschnittliche akustische Bewertungszahl (beste Bewertungszahl) pro Rahmen und der Teil der NBEST-Liste mit dem gleichen Wort als erste Wahl. Es sollte klar sein, dass gemäß einer Ausführungsform der vorliegenden Erfindung die beiden Lösungsansätze (Zuverlässigkeitsgrad gemessen über Entscheidungsbäume und über lineare Prädiktoren) kombiniert werden, um den Zuverlässigkeitsgrad in jedem Übersetzungsprozess, nicht auf die Spracherkennung beschränkt, systematisch zu extrahieren.
Anhand des Fortschritts in der Vergangenheit und der Geschwindigkeit der Fortentwicklung in diesem Bereich, kann man nun sagen, dass man für verschiedene Arten von Übersetzungen einen Zuverlässigkeitswert, z. B. von 0 bis 1, zuordnen kann, wobei 0 bedeutet, dass keine Übersetzung ausgeführt wird, und 1 Bestimmtheit für Komponenten, die übersetzt werden, bedeutet, wobei die Komponenten Texte, Satzteile, Wörter und allgemeiner ein beliebiger logischer Block aus zu übersetzendem Material bedeuten. Die oben beschriebene Kombination aus linearen Prädiktoren und Entscheidungsbäumen ist ein Verfahren, das vorzugsweise für die vorliegende Erfindung verwendet wird. Die Akkumulation von Bewertungszahlen, die durch eine Spracherkennungsmaschine zurückgegeben werden (Bewertungszahl der schnellen Übereinstimmung und Bewertungszahl der detaillierten Übereinstimmung sowie Bewertungszahlen der Hintergrundmodelle und Gruppen), kann tatsächlich beispielhaft verwendet werden, um einen Entscheidungsbaum und/oder einen linearen Prädiktor des Zuverlässigkeitsgrades zu bilden, der den Sprecher tatsächlich korrekt identifiziert. Bei der Sprecheridentifikation läuft das tatsächlich darauf hinaus, eine Überprüfung anhand der Identität auszuführen, die durch die Identifikationsstufe erhalten wird.
Es sollte klar sein, dass die entfernten Server Informationen wie z. B. TTS-Regeln oder Basisformulare, Grammatikinformationen usw. an den lokalen Client für eine Speicherung in einem Cache-Speicher senden können, so dass die lokale Einheit anschließend eine ähnliche Anforderung unter Verwendung dieser Informationen lokal verarbeiten kann. Da eine lokale Einheit möglicherweise nicht in der Lage ist, eine bestimmte Aufgabe infolge des Mangels an erforderlichen Ressourcen zu verarbeiten, kann die Entscheidung durch den Server-Dialogmanager 108, diese Verarbeitungsinformationen an den lokalen Client zu senden, durch die lokale Einheit beim Verbinden mit dem entfernten Server in Übereinstimmung mit der Registrierung (über die oben erläuterten Registrierungsprotokolle) über ihre Konversationsfähigkeiten mit dem entfernten Server getroffen werden.
Es sollte klar sein, dass die vorliegende Erfindung in Situationen realisiert werden kann, bei denen der Umfang von Konversationsfunktionen, die durch eine Einheit (über ihren Dialogmanager) ausgeführt werden, derart ist, dass die Einheit nicht in der Lage ist, die erforderlichen Ressourcen für eine rechtzeitige Ausführung der Funktion bereitzustellen (z. B. ein IVR mit einer zu großen Anzahl gleichzeitiger Anschlüsse, die durch das System verwendet werden). Deswegen kann der Dialogmanager so realisiert sein, dass er eine Verwaltung des Konversationssystems und eine Verwaltung der Belastung ausführt, wodurch der Dialogmanager während der Ausführung einer bestimmten Funktion entscheiden kann, ein anderes Konversationssystem zu verwenden, um die Verarbeitung der angeforderten Funktion fortzusetzen. Insbesondere in 3 richtet der Benutzer einen gesprochenen Befehl an die lokale Client-Einheit, der vorverarbeitet wird, indem z. B. die relevanten Merkmale des digitalisierten Sprachsignals digitalisiert und extrahiert werden (Schritt 300). Alternativ kann der lokale Dialogmanager eine Anforderung von einer lokalen Anwendung 104 empfangen, um synthetische Sprache (TTS) zur Ausgabe an den Benutzer zu erzeugen (Schritt 300). Der Dialogmanager stellt fest, ob eine lokale Verarbeitung ausgeführt werden sollte (Schritt 301) (ob es sich z. B. um Spracherkennung, Dialogverwaltung oder Sprachsynthese handelt). Diese Entscheidung kann nicht nur auf der Grundlage der lokalen Konversationsfähigkeiten, Argumente und Ressourcen erfolgen (wie oben erläutert wurde), sondern auch auf der Grundlage von Schätzwerten der Verzögerung, die das Netzwerk infolge von Netzwerk-Verkehrsstau einführt im Vergleich zu den möglichen Verzögerung, die bei der Ausführung der Konversationsfunktion unter Verwendung von verfügbaren, jedoch beschränkten lokalen Ressourcen eingeführt wird (wenn angenommen wird, dass die lokale und die entfernte Einheit die gleichen Funktionen ausführen können). Deswegen können z. B. Befehls- und Steuerfunktionen, bei denen die Gefahr der lokalen Verzögerung bzw. einer Verzögerung über das Netzwerk besteht, entfernt/lokal ausgeführt werden, um die Verzögerung so gering wie möglich zu machen. Dagegen können Anfragen, die eine längere Verzögerung vertragen (z. B. deswegen, weil sie mit nachgeordneten Funktionen verbunden sind, die Verzögerungen wie z. B. Internet- oder audiovisuelle Suchen beinhalten können), auf einem System (lokal oder vernetzt) ausgeführt werden, das die Ressourcen oder Kosten optimiert.
Außerdem werden dann, wenn die Netzwerkverbindung vorübergehend nicht zur Verfügung steht, oder beim Fehlen von vernetzten Ressourcen alle Funktionen, die lokal ausgeführt werden können, ausgeführt. Die anderen Funktionen können in Funktionen, die in einer Aufschub-Betriebsart ausgeführt werden können (später, wenn die Verbindung wiederhergestellt wurde), und in nichtkompatible Funktionen unterteilt werden. Typische Beispiele sind Aktualisierungen des Adressbuchs, Antworten auf eMails oder Nachrichten durch Diktieren oder das Diktieren allgemein. Die Anwendung kann wiederum vorzugsweise festlegen, ob der Befehl lokal oder verschoben ist. Es ist außerdem möglich, eine Peer-zu-Peer-Verbindung als Aufschub-Betriebsart zu betrachten, wobei ein Manager der Aufschub-Betriebsart und eine lokale Maschine festlegen, ob die Funktion lokal oder verschoben erfolgt.
Wenn in 3 der Dialogmanager feststellt, dass eine lokale Verarbeitung geeignet ist (positive Feststellung im Schritt 301), ordnet der Dialogmanager die erforderliche Konversationsmaschine dem Anschluss zu (Schritt 302). Nachdem die Konversationsmaschine dem Anschluss zugeordnet wurde, kann der Dialogmanager diese Maschine anderen Anschlüssen zuordnen, wenn die Konversationsmaschine gegenwärtig nicht durch den ursprünglich zugeordneten Anschluss verwendet wird (Schritt 303) (z. B. dann, wenn der Sprecher momentan nicht spricht, sondern hört). Wenn die lokale Maschine wieder durch den ursprünglich zugewiesenen Anschluss benötigt wird und die lokale Maschine nicht verfügbar ist, kann eine andere verfügbare Maschine (lokal verfügbare Maschine oder eine entfernte Einheit) verwendet werden (Schritt 304). Dieser dynamische Zuweisungsprozess steht im Gegensatz zur herkömmlichen Belastungsverwaltung, bei der ein Dialogmanager entscheidet und eine oder mehrere Konversationsmaschinen jedem Anschluss für die gesamte Dauer eines Funktionsanrufs zuweist.
Es sollte klar sein, dass die Verwaltung und Entscheidung zum Übertragen von Sprache z. B. an einen Netzwerkserver oder eine Einheit nicht nur auf dem Grad an Systemverwaltung/Lastausgleich (durch den Dialogmanager bei einem Client oder Server), sondern auch auf dem Verkehr des Netzwerks beruhen kann. Wenn z. B. eine Verbindung (insbesondere für TCP/IP-gestützte Verbindungen über das Internet) als überlastet angesehen wird, kann ein neuer Server oder eine neue Einheit anhand des Verkehrs ausgewählt werden (Schritt 306). Diese Entscheidung kann an der Spitze von herkömmlichen Protokollen wie etwa VoIP-Protokollen (Voice over Internet Protocol) wie z. B. RSVP (Ressource Reservation Protocol) getroffen werden, wodurch dann, wenn ein Kanal benötigt wird, die Verbindung gemeinsam mit einer geeigneten Reservierung der zugehörigen Dienstqualität hergestellt werden kann. Andernfalls wird eine entfernte Verarbeitung ausgeführt (Schritt 307) und die Ergebnisse in der oben erläuterten Weise zurückgeleitet.
Es sollte klar sein, dass das System und die Verfahren, die hier beschrieben wurden, für verschiedene sprachaktive und Konversationsanwendungen realisiert werden können. Die vorliegende Erfindung ist insbesondere nützlich, um den steigenden Bedarf auf dem Gebiet der eingebetteten und der weltweit eingesetzten Datenverarbeitung sowie der NLU/NLG-Dialogsysteme zu decken. Es sollte jedoch klar sein, dass die vorliegende Erfindung für eine Vielfalt von Anwendungen, die nicht auf eingebettete Systeme beschränkt sind, verwendet werden kann. Die folgenden beispielhaften Ausführungsformen veranschaulichen die Vorteile der vorliegenden Erfindung.
Handelsüblich verfügbare eingebettete Namenwähleinrichtungen zur Verwendung bei einem Smartphone (z. B. ein Drahtlostelefon mit PDA-Fähigkeiten (PDA – persönlicher digitaler Assistent)) sind eine typische Anwendungsmöglichkeit. Es wird z. B. angenommen, dass die Client-Einheit 100 ein Smartphone mit einer lokalen Anwendung einer Namenwähleinrichtung ist. Der Benutzer speichert lokal eine Liste von gewünschten Namen und Adressen im elektronischen Telefonbuch des Smartphone. Der Benutzer kann dann einen Befehl aussprechen wie z. B. "Wähle Vorname Nachname im ..." mögliches Abfragekriterium (zuhause, Büro, Zellentelefon), und bei Erkennung/Verständnis des Befehls (über die lokalen Konversationsmaschinen 102) wird das Smartphone automatisch die Telefonnummer wählen, die der Person im Adressbuch zugeordnet ist (über die lokale Anwendung 104). Wenn dagegen ein Name ausgesprochen wird, der sich nicht im Adressbuch befindet (und deshalb nicht erkannt/verstanden wird), der sich aber in einer größeren gemeinsamen (oder öffentlichen) Datei befindet (die im entfernten Server 106 vorhanden ist), kann die Anforderung (als Merkmale oder als Signalform) gespeichert werden und zu einem entfernten Server 106 zur Erkennung gesendet werden. Das Wählen kann dann durch den entfernten Server oder durch das Smartphone beim Empfang der geeigneten Informationen direkt ausgeführt werden. Der Benutzer kann alternativ zunächst mit dem entfernten Server verbunden werden und einen Dialog herstellen, um entweder den zu wählenden Namen erneut anzufordern oder um weitere Informationen zu bitten (bei einem Diensttyp der weißen oder gelben Seiten).
Eine weitere nützliche Anwendungsmöglichkeit der vorliegenden Erfindung betrifft ein persönliches Informationssystem wie z. B. das handelüblich verfügbare System PointCast (siehe http://www.pointcast.com), das es einem Benutzer ermöglicht, z. B. Aktienwerte, spezielle Neuigkeiten zu einem Thema und Informationen über die letzte Veröffentlichung zu dem Thema anhand von im Voraus festgelegten Benutzerpräferenzen zu erhalten. Bei einem persönlichen Informationssystem, das gemäß der vorliegenden Erfindung aufgebaut ist, wird der Benutzer dann, wenn er Informationen über eine Aktie (z. B. IBM) oder über ein Thema (z. B. die Vorhersage für die Produktion von grünen Erbsen in Kent) erhalten möchte, eine Sprachanforderung an die Client-Einheit 100 richten. Falls "IBM" sich im lokalen Wortschatz (Benutzerprofil) befindet, wird es sofort decodiert, und der Benutzer erhält die neueste Quote, die z. B. als letzte Aktualisierung (PointCast) erhalten wurde. Wenn dagegen die Benutzeranforderung in Bezug auf "grüne Erbsen" von der lokalen Client-Einheit 100 nicht verstanden wurde, wird die Anforderung automatisch als ein Merkmalstrom an einen entfernten Server 106 (des Inhaltanbieters) weitergeleitet, wobei der Server beim Decodieren dieser Anforderung mehr Ressourcen einsetzen und die zugehörigen Informationen abrufen (was sowieso gemacht werden musste) und anschließend diese Informationen an das lokale System übertragen kann. Wenn das entfernte Serversystem einem "Push-Ansatz" folgt, kann dies bei der nächsten Aktualisierung geschehen (z. B. PointCast).
Die Client-Einheit 100 kann außerdem ein sprachaktiver PVA (persönlicher Fahrzeugassistent) sein, um z. B. eine Konversationsfahrzeugnavigation bereitzustellen. Wenn der Benutzer z. B. keine CD-ROM mit dem System verwenden möchte (wegen Raummangel, Leistungsanforderungen, Gewicht, Kosten, Stoßfestigkeit usw.), könnte sich der Benutzer entscheiden, begrenzte Informationen wie z. B. das Vokabular und die Karten, die Regionen/Orten zugeordnet sind, an denen sich der Benutzer gegenwärtig befindet, an denen er sich kürzlich aufhielt und zu denen der fahren möchte, zu speichern. Immer dann, wenn in diesem Beispiel eine Benutzeranforderung nicht mit dem lokalen Vokabular und den Kartengruppen übereinstimmt, kann die Anforderung automatisch zu einem entfernten Server 106 gesendet und decodiert werden (selbst dann, wenn Eingabeaufforderungen zurück an den Benutzer die Suche einengen), damit die Fahrtroute, die Karten (oder die aktualisierten Karten) zum Fahrzeug heruntergeladen werden. Eine derartige Aktion wäre wiederum für den Benutzer im Wesentlichen transparent (selbst wenn das Herunterladen kostspielig ist), da anfangs lediglich die lokale Straße benötigt wird.
Des Weiteren kann ein NLU/FSG-System gemäß der vorliegenden Erfindung so gestaltet sein, dass dann, wenn die Anforderung des Benutzers FSG (vollständige Grammatik) benötigt, die Anforderung lokal verarbeitet werden kann, es sei denn, die Anforderung ist komplexer und elementar, wodurch eine Weiterleitung an einen entfernten Server zur Erkennung erforderlich ist.
Der Namenwählerdienst in einer Firma bietet ein weiteres interessantes Merkmal. Ein Unternehmen führt eine aktive Datenbank von Telefonnummern für seine Beschäftigten. Diese Datenbank ist stets aktuell. Der Benutzer kann periodisch entscheiden, seine lokalen Daten mit denen der Firmendatenbank zu synchronisieren. Dies stellt ein klassisches Konzept dar. Wenn jedoch der Benutzer die Namenwähleinrichtung verwendet und über TCP/IP mit dem Server verbunden werden soll, kann die Synchronisation erfolgen (während der Spracherkennungsphase), so dass die lokale Wählinformation stets aktualisiert ist. Gleichfalls kann das System dann, wenn der Benutzer Informationen für die Navigation zu einem neuen Ort, der nicht in der lokalen Karte des Benutzers enthalten ist, anfordert, die akustischen Informationen sowie eine Gruppe von Navigationsinformationen für die Region, in die der Benutzer reisen möchte, auf den lokalen PVA herunterladen.
Das System von 1 kann außerdem mit dem Konversationsbrowsersystem realisiert werden, das im Dokument von IBM mit dem Aktenzeichen YO998-392P beschrieben ist, das mit dieser Anmeldung eingereicht wurde und den Titel "Conversational Browser and Conversational Systems" trägt, das gemeinsam übertragen wurde und als EP-A-1 133 734 veröffentlicht wurde, wobei eine CML-Seite (Konversations-Markup Language), die konzeptionell einer HTML-Seite (Hypertext-Markup Language) für eine visuelle Anzeige ähnlich ist und von einem Inhaltanbieter (Server) übertragen wird (und durch den Konversationsbrowser verarbeitet wird), verwendet wird, um eine Konversations-UI zu beschreiben, die dem Benutzer präsentiert wird. In diesem Beispiel kann es sich bei dem Konversationsbrowser um die lokale Anwendung 104 der Client-Einheit 100 und/oder die Serveranwendung 109 in dem entfernten (IVR) Server 106 handeln. Der Inhaltanbieter oder der Anwendungsentwickler (oder der Proxy/Transcoder) kann entscheiden, dass ein gegebenes Element, das der Benutzer bereitstellen sollte (z. B. eine NLU- oder FSG-Eingabe eines Formulars oder ein leeres Formular, das durch Diktieren auszufüllen ist) am Server 106 erkannt werden muss, anstelle der Lieferung sämtlicher Daten an die Client-Einheit 100 zur lokalen Erkennung (da die Aufgabe für die lokalen Ressourcen zu komplex ist oder da zu viele Informationen durch das Netzwerk gesendet werden müssten). Dies erfolgt z. B. durch Bereitstellen einer URL (Verweisadresse) und Kennzeichen in einer CML-Datei, um einen Server anzugeben, in dem die Verarbeitung erfolgen wird, oder indem ein Applet, eine ActiveX-Komponente oder ein Plug-In (oder irgendeine Variation hiervon) in die CML-Seite geladen wird, das das Audiosignal aufnimmt, möglicherweise einige Konversationsfunktionen ausführt und sie für weitere Funktionen an andere Einheiten versendet (dies ist typischerweise eine Entscheidung, die durch den Autor der Seite getroffen wird). Diese Entscheidung kann durch einen Transcoder und einen Registrierungsmechanismus automatisch ausgeführt werden, wie im Dokument von IBM mit dem Aktenzeichen YO998-392P beschrieben ist, wodurch der Browser seine Fähigkeiten dem Server explizit beschreibt, bei dem die CML-Seite abgerufen wird. Wenn der Transcoder verwendet wird, um die Fähigkeiten des Browsers zusätzlich zu berücksichtigen und den Inhalt an diese Fähigkeiten anzupassen (diese Fähigkeit wird als ein Konversationsproxy bezeichnet), kann der Transcoder die eine oder die mehreren Server-URLs anfügen, um den Server nun auf der Grundlage der Browserfähigkeiten neu zu lenken. In diesen Fällen kann die durch die Client-Einheit 100 erfasste Sprache als eine (gegebenenfalls komprimierte) Signalform oder als ein Strom von Merkmalen zum entfernten Server 106 oder dem vernetzten Server 110 senden, wo die Erkennung erfolgt (oder NLU/NLG). Das Erkennungsergebnis kann dann zurück zur Client-Einheit 100 oder zum Server des CML-Anbieters (entfernter Server 106) gesendet werden, um über den nächsten Verlauf von Aktionen oder die Weiterverarbeitung zu entscheiden. Wie oben erwähnt wurde, kann dies wiederum durch die Anwendung entschieden werden, die die URL der Ressource/Maschine/des Servers oder der lokalen Einheit, die für die Erkennung einer vorgegebenen Eingabe, eines Menüformulars oder Dialogs verwendet werden soll, direkt enthalten kann. Außerdem ist die vorliegende Erfindung unter den Umständen nützlich, wenn eine CML-Seite Ton oder Text wiedergeben/synthetisieren muss, der für die lokalen Konversationsmaschinen 102 der lokalen Einheit 102 zu komplex ist. Die Abschnitte, die zu komplex sind, können als Ströme von Merkmalen oder komprimierten Signalformen von einem speziellen Server erhalten werden (der möglicherweise der Server ist, der die CML-Seite bereitstellte). Des Weiteren kann die lokale Client-Einheit 100, die die geeignete Fähigkeit nicht besitzt, in Bezug auf ein Mehrsprachensystem dann, wenn eine CML-Seite eine andere Sprache enthält, einen entfernten Server anfordern, um die Konversationsfunktionen in dieser Sprache auszuführen.
Es sollte klar sein, dass die Konversationskoordination in verteilten Anwendungen mit einem Konversationsbrowser verwendet werden kann. In 4 sind z. B. ein verteiltes System mit einem Präsentationsserver 400, ein Maschinenserver 401 und ein Client 402 mit einem Konversationsbrowser 403 dargestellt (wie in der oben genannten Referenz YO998-392P erläutert ist). Der Browser 403 empfängt Seiten mit CML von dem Präsentationsserver 400 und verarbeitet die CML-Seiten. Die CML-Seite kann Informationen enthalten, die dem Browser 403 die Feststellung ermöglichen, wohin Sprache zur Verarbeitung zu senden ist. Ein Sprachserver befindet sich im Maschinenserver 401. Wird angenommen, dass die CML-Seite eine Verarbeitung der Sprache durch den Maschinenserver 401 anfordert, kann der Browser 403 mit dem Sprachserver über HTTP (oder Sockets oder RMI) Daten austauschen (Anrufe übertragen), um Audiosignale an den Sprachserver zu versenden und die geeigneten Datendateibefehle und Maschinenanrufe senden. Es wird angenommen, dass der Browser 403 des Client bestimmte lokale Verarbeitungsfähigkeiten besitzt, um eine Sprachverarbeitung (über Sprach-API und die Spracherkennungsmaschine 405) auszuführen. Wie oben angemerkt wurde, wird die Verschiebung zwischen der lokalen Sprachverarbeitung und der serverseitigen Sprachverarbeitung durch die CML-Seite bestimmt, die vom Präsentationsserver 400 empfangen wird. Diese Bestimmung kann durch den Inhaltanbieter oder die Anpassung an die Einheit codiert werden (der Client 402 entscheidet, dass er die Aufgabe nicht ausführen kann und sendet sie an einen bekannten oder entdeckten Server oder Transcoder).
In 5 befindet sich der Browser 403 an einem Browserserver 404, auf den durch den Client 402 zugegriffen wird (der Browserserver 404 wirkt als ein Zwischenglied zwischen dem Client 402 und dem Präsentationsserver 400). Der Browser 403 legt wiederum fest, ob eine lokale oder eine serverseitige Verarbeitung ausgeführt wird. Die Audiosignale können unter Verwendung einer Konversationscodierung versendet werden, wie oben beschrieben wurde.
Die vorliegende Erfindung ermöglicht, dass eine Client-Einheit mit geringen Ressourcen einfache Aufgaben lokal sowie komplexe Aufgaben in binärer oder analoger Verbindung mit einem Server (oder einer anderen Einheit), die komplexere Konversationsfähigkeiten besitzen, transparent ausführt. Die serverseitigen Funktionen (wie etwa die Spracherkennung) können über ein reguläres IP-Netzwerk oder ein LAN-Netzwerk sowie über eine digitale Übertragung über eine herkömmliche Telefonleitung oder ein paketvermitteltes Netzwerk oder über ein herkömmliches drahtloses Datenprotokoll über ein Drahtlos-Netzwerk ausgeführt werden. Die Ausführungsform mit analoger/digitaler Verbindung beschreibt wenigstens zwei Szenarien. Erstens wird eine binäre Verbindung mit einer modemähnlichen Einheit realisiert, und sämtliche Funktionen sind Datenübertragungsfunktionen. Wenn ein Server/eine verteilte Ressource beteiligt ist, kann das System außerdem einen Telefonserver als Ressource anrufen, und Sprache wird über das Netzwerk gesendet (anstelle von Daten der Signalform oder einer Transformation hiervon, wie etwa Cepstra). Ein Beispiel eines derartigen Szenarios ist eine drahtlose Verbindung mit lokalen Spracherkennungsfunktionen (Namenwähleinrichtung und Ziffernwähleinrichtung), die über eine reguläre drahtlose Verbindung mit einem Telefonserver mit einer IVR oder anderen Funktionen wie z. B. Sprachbrowsen im Internet, das Erhalten von Aktien-/Anlagefondkursen und das Ausführen von Banktransaktionen über Sprache, verbindet. Dieser Mechanismus kann heutzutage mit vorhandenen Zellentelefonen verwendet werden, die mit bestimmten Spracherkennungsfähigkeiten in der Einheit ausgerüstet sind.
Außerdem können verschiedene Mechanismen verwendet werden, um Verkehr und Ressourcen zu verwalten, die über das Netzwerk verteilt sind, um einen geeigneten Dialogfluss einer Konversationswechselwirkung über das Netzwerk zu garantieren. Zu derartige Mechanismen gehören: Konversationsprotokolle (die oben erläutert wurden), Audio: RecoVC (Erkennung mit kompatiblem VoCoder) (das Codierprotokoll mit Tonlage, das eine Rekonstruktion zur Wiedergabe ermöglicht), Anwendungen und Metainformationen: verteiltes Anwendungsprotokoll, Erkennung, Registrierung, Verhandlung, Serverbelastungs- Verwaltung, um einen Dialogfluss aufrechtzuerhalten, Verkehrsausgleich und Leiten, um einen Dialogfluss aufrechtzuerhalten, Maschinenserverauswahl anhand von Aufgabenmerkmalen und Fähigkeitsanforderungen und Verfügbarkeit von Konversationsargumenten (Datendateien), Konversationsargument-Verteilung: Speicherung, Verkehr/Lenkung und Cache-Speicherung.
Obwohl veranschaulichende Ausführungsformen hier unter Bezugnahme auf die beigefügten Zeichnungen beschrieben wurden, sollte klar sein, dass das vorliegende System und das Verfahren nicht auf diese genauen Ausführungsformen beschränkt sind und verschiedene weitere Änderungen und Modifikationen durch einen Fachmann bewirkt werden können, ohne vom Umfang der Erfindung abzuweichen. Alle derartigen Änderungen und Modifikationen sollen im Umfang der Erfindung eingeschlossen sein, der durch die beigefügten Ansprüche definiert ist.

Claims

System zum Bereitstellen einer automatischen und koordinierten gemeinsamen Nutzung von Konversationsressourcen, wobei das System Folgendes umfasst: ein Netzwerk, das wenigstens eine erste lokale Netzwerkeinheit und eine zweite Netzwerkeinheit umfasst; wobei die erste lokale Netzwerkeinheit und die zweite Netzwerkeinheit jeweils Folgendes umfassen: eine Gruppe von Konversationsressourcen; einen Dialogmanager für das Verwalten einer Konversation und zum Ausführen von Anrufen, die einen Konversationsdienst anfordern; und ein Kommunikationspaket zum Kommunizieren von Nachrichten unter Verwendung von Konversationsprotokollen über das Netzwerk und das so beschaffen ist, dass es bewirkt, dass die unter Verwendung von Konversationsprotokollen übertragenen Nachrichten einen koordinierten Netzwerkdatenaustausch zwischen den Dialogmanagern der ersten lokalen Netzwerkeinheit und der zweiten Einheit herstellen, um gegebenenfalls ihren entsprechenden angeforderten Konversationsdienst auszuführen.
System nach Anspruch 2, bei dem die Gruppe von Konversationsressourcen der ersten lokalen Netzwerkeinheit und der zweiten Einheit wenigstens eine Spracherkennungsmaschine, eine Sprechererkennungsmaschine, eine TTS-Maschine (Text-zu-Sprache-Synthesemaschine), eine NLU-Maschine (Maschine zum Verstehen natürlicher Sprache) eine NLG-Maschine (Maschine zum Erzeugen natürlicher Sprache), eine Audioerfassungs- und Kompressions-/Dekompressionsmaschine, eine Themengebiet-Erkennungsmaschine, eine Audio-/Multimedia-Indexierungs- und Suchmaschine oder eine Kombination hiervon umfasst.
System nach Anspruch 1, bei dem die Konversationsprotokolle Koordinatenprotokolle umfassen, die den Dialogmanagern der ersten lokalen Netzwerkeinheit und der zweiten Einheit den Austausch von Daten ermöglichen, die ihren entsprechenden Konversationszustand, Argumente und Kontext- und Austausch-Dialogkomponenten umfassen.
System nach Anspruch 3, wobei die Koordinatenprotokolle eine Master/Slave-Kommunikation oder eine Peer-zu-Peer-Kommunikation zwischen den Dialogmanagern der ersten lokalen Netzwerkeinheit und der zweiten Einheit koordinieren.
System nach Anspruch 1, bei dem die Konversationsprotokolle Discovery Protocols umfassen, die der ersten lokalen Netzwerkeinheit und der zweiten Einheit ermöglichen, dialogbewusste Einheiten und Anwendungen im Netzwerk zu finden.
System nach Anspruch 5, bei dem durch die Discovery Protocols eine "Rundsende- und Abhör-Methodologie" realisiert wird.
System nach Anspruch 6, bei dem die Discovery Protocols eingesetzt werden, um ein dynamisches und spontanes Netzwerk wenigstens zwischen der ersten lokalen Netzwerkeinheit und der zweiten Netzwerkeinheit aufzubauen.
System nach Anspruch 1, bei dem die Konversationsprotokolle Registrierungsprotokolle umfassen, um Daten in Bezug auf Konversationsressourcen, Möglichkeiten und Anforderungen auszutauschen.
System nach Anspruch 8, bei dem die Konversationsprotokolle Verhandlungsprotokolle zum Datenaustausch umfassen, um eine Netzwerkkonfiguration zwischen der ersten lokalen Netzwerkeinheit und der zweiten Netzwerkeinheit anhand ihrer entsprechenden Konversationsressourcen und Möglichkeiten aufzubauen.
System nach Anspruch 9, bei dem die Netzwerkkonfiguration ein Master/Slave-Netzwerk umfasst, wobei der Dialogmanager der ersten lokalen Netzwerkeinheit oder der zweiten Einheit die Konversationsressourcen sowohl der ersten lokalen Netzwerkeinheit als auch der zweiten Einheit und ein Peer-zu-Peer-Netzwerk steuert, wobei die Dialogmanager der ersten und der zweiten Einheit über die Steuerung von Konversationsressourcen verhandeln.
System nach Anspruch 1, bei dem die Konversationsprotokolle Sprachübertragungsprotokolle umfassen, um Signalformen komprimierter Sprache, Merkmale komprimierter Sprache oder komprimierte Ergebnisse zwischen der ersten und der zweiten Einheit zu übertragen.
System zum Bereitstellen einer automatischen und koordinierten gemeinsamen Nutzung von Konversationsressourcen, wobei das System Folgendes umfasst: einen Client, der lokale Konversationsressourcen und einen Dialogmanager zum Verwalten der lokalen Konversationsressourcen, zum Verarbeiten einer Anforderung nach einem Konversationsdienst und zum Feststellen, ob eine Anforderung nach einem Konversationsdienst unter Verwendung der lokalen Konversationsressourcen ausgeführt werden kann, umfasst; und einen Server, der Server-Konversationsressourcen umfasst, wobei der Dialogmanager des Client so beschaffen ist, dass er automatisch auf den Server zugreift, um die Anforderung unter Verwendung der Server-Konversationsressourcen zu verarbeiten, wenn der angeforderte Konversationsdienst nicht unter Verwendung der lokalen Konversationsressourcen ausgeführt werden kann.
Verfahren zum Bereitstellen einer automatischen und koordinierten gemeinsamen Nutzung von Konversationsressourcen zwischen Netzwerkeinheiten, das die folgenden Schritte umfasst: Empfangen einer Anforderung nach einem Konversationsdienst durch eine erste lokale Netzwerkeinheit; Feststellen durch die erste lokale Netzwerkeinheit, ob der angeforderte Konversationsdienst lokal unter Verwendung von Konversationsressourcen der ersten lokalen Netzwerkeinheit, entfernt unter Verwendung von Konversationsressourcen wenigstens einer zweiten Netzwerkeinheit oder lokal und entfernt unter Verwendung sowohl lokaler als auch entfernter Konversationsressourcen verarbeitet wird; und automatischer Datenaustausch mit der wenigstens einen zweiten Netzwerkeinheit, wenn festgestellt wird, dass der Konversationsdienst wenigstens teilweise unter Verwendung der Konversationsressourcen der wenigstens einen zweiten Netzwerkeinheit verarbeitet wird.
Verfahren nach Anspruch 13, das ferner den Schritt des Übertragens von Nachrichten unter Verwendung von Konversationsprotokollen umfasst, um einen koordinierten Netzwerkdatenaustausch zwischen der ersten lokalen Netzwerkeinheit und der wenigstens einen zweiten Netzwerkeinheit aufzubauen, um die Konversationsressourcen gemeinsam zu nutzen.
Verfahren nach Anspruch 13, bei dem der Schritt des Feststellens die Schritte zum Feststellen umfasst, ob lokale Konversationsressourcen zum Verarbeiten des angeforderten Konversationsdienstes zur Verfügung stehen; und wobei das Verfahren ferner die folgenden Schritte umfasst: Ausführen des angeforderten Konversationsdienstes unter Verwendung der lokalen Konversationsressourcen, wenn festgestellt wird, dass lokale Konversationsressourcen zum Verarbeiten des angeforderten Konversationsdienstes zur Verfügung stehen; Feststellen, ob Ergebnisse der lokalen Verarbeitung annehmbar sind; und automatisches Zugreifen auf die wenigstens eine zweite Netzwerkeinheit, um den angeforderten Konversationsdienst entfernt zu verarbeiten, wenn festgestellt wird, dass die Ergebnisse der lokalen Verarbeitung nicht annehmbar sind.
Verfahren nach Anspruch 13, bei dem der Schritt des Feststellens den Schritt zum Feststellen umfasst, ob die wenigstens eine zweite Netzwerkeinheit durch die erste lokale Netzwerkeinheit im Voraus für die Verarbeitung des Konversationsdienstes festgelegt wurde.
Verfahren nach Anspruch 13, bei dem der Schritt des Feststellens auf der Verfügbarkeit der Netzwerkverbindung oder auf dem Netzwerkverkehr zwischen der ersten lokalen Netzwerkeinheit und der wenigstens einen zweiten Netzwerkeinheit beruht.
Verfahren nach Anspruch 14, bei dem der Schritt des automatischen Zugreifens die folgenden Schritte umfasst: automatisches Herstellen einer Netzwerkverbindung mit der wenigstens einen zweiten Netzwerkeinheit durch das Übertragen von Nachrichten unter Verwendung der Konversationsprotokolle; und Übertragen von Merkmalen komprimierter Sprache oder komprimierten Signalformen an die wenigstens eine zweite Netzwerkeinheit.
Programmspeichereinheit, die maschinenlesbar ist, die ein Programm von Befehlen, die durch die Maschine ausführbar sind, konkret beinhaltet, um Verfahrensschritte zum Bereitstellen einer automatischen und koordinierten gemeinsamen Nutzung von Konversationsressourcen zwischen Netzwerkeinheiten auszuführen, wobei die Verfahrensschritte Folgendes umfassen: Empfangen einer Anforderung nach einem Konversationsdienst durch eine erste lokale Netzwerkeinheit; Feststellen durch die erste lokale Netzwerkeinheit, ob der angeforderte Konversationsdienst lokal unter Verwendung von Konversationsressourcen der ersten lokalen Netzwerkeinheit, entfernt unter Verwendung von Konversationsressourcen der wenigstens einen zweiten Netzwerkeinheit oder lokal und entfernt unter Verwendung sowohl der lokalen als auch der entfernten Konversationsressourcen verarbeitet wird; und automatischer Datenaustausch mit der wenigstens einen zweiten Netzwerkeinheit, wenn festgestellt wird, dass der Konversationsdienst wenigstens teilweise entfernt unter Verwendung der Konversationsressourcen der wenigstens einen zweiten Netzwerkeinheit verarbeitet wird.
Programmspeichereinheit nach Anspruch 19, die ferner Befehle zum Ausführen des Schritts zum Übertragen von Nachrichten in Übereinstimmung mit Konversationsprotokollen umfasst, um einen koordinierten Netzwerkdatenaustausch zwischen der ersten lokalen Netzwerkeinheit und der wenigstens einen zweiten Netzwerkeinheit aufzubauen, um die Konversationsressourcen gemeinsam zu nutzen.
Programmspeichereinheit nach Anspruch 19, bei der die Befehle zum Ausführens des Feststellungsschritts Befehle zum Ausführen der Schritte zum Feststellen umfassen, ob lokale Konversationsressourcen zum Verarbeiten des angeforderten Konversationsdienstes zur Verfügung stehen; und wobei die Programmspeichereinheit ferner Befehle zum Ausführen der folgenden Schritte umfasst: Ausführen des angeforderten Konversationsdienstes unter Verwendung lokaler Konversationsressourcen, wenn festgestellt wird, dass lokale Konversationsressourcen zum Verarbeiten des angeforderten Konversationsdienstes zur Verfügung stehen; Feststellen, ob Ergebnisse der lokalen Verarbeitung annehmbar sind; und automatisches Zugreifen auf die wenigstens eine zweite Netzwerkeinheit, um den angeforderten Konversationsdienst entfernt zu verarbeiten, wenn festgestellt wird, dass die Ergebnisse der lokalen Verarbeitung nicht annehmbar sind.
Programmspeichereinheit nach Anspruch 19, bei der die Befehle zum Ausführen des Feststellungsschritts Befehle zum Ausführen des Schritts zum Feststellen umfassen, ob die wenigstens eine zweite Netzwerkeinheit durch die erste lokale Netzwerkeinheit im Voraus für die Verarbeitung des Konversationsdienstes festgelegt wurde.
Programmspeichereinheit nach Anspruch 19, bei der der Schritt des Feststellens auf der Verfügbarkeit der Netzwerkverbindung oder dem Netzwerkverkehr zwischen der ersten lokalen Netzwerkeinheit und der wenigstens einen zweiten Netzwerkeinheit beruht.
Programmspeichereinheit nach Anspruch 20, bei der die Befehle zum Ausführen des Schritts des automatischen Zugreifens Befehle zum Ausführen der folgenden Schritte umfassen: automatisches Herstellen einer Netzwerkverbindung mit der wenigstens einen zweiten Netzwerkeinheit unter Verwendung der Konversationsprotokolle; und Übertragen von Merkmalen komprimierter Sprache oder einer komprimierten Signalform an die wenigstens eine zweite Netzwerkeinheit.